U.S. patent application number 12/268905 was filed with the patent office on 2009-05-14 for method and system for user profile match indication in a mobile environment.
This patent application is currently assigned to QUALCOMM Incorporated. Invention is credited to Pooja Aggarwal, Robert S. Daley, Dilip Krishnaswamy, Patrik Lundqvist, Martin Renschler.
Application Number | 20090124241 12/268905 |
Document ID | / |
Family ID | 40624182 |
Filed Date | 2009-05-14 |
United States Patent
Application |
20090124241 |
Kind Code |
A1 |
Krishnaswamy; Dilip ; et
al. |
May 14, 2009 |
METHOD AND SYSTEM FOR USER PROFILE MATCH INDICATION IN A MOBILE
ENVIRONMENT
Abstract
Methods and systems for determining a suitability for a mobile
client to display information are disclosed. For example, a method
for determining a suitability for a mobile client to receive a
targeted content message includes generating user profile data by
the mobile client, receiving a set of target profile data
associated with the targeted content message, the set of target
profile data being descriptive of the targeted content message,
comparing the user profile data with the target set of profile data
to produce a set of confidence-level data, a target set of profile
data describing the content of a respective targeted-content
message, and storing the targeted content message in the mobile
client based upon the set of confidence-level data.
Inventors: |
Krishnaswamy; Dilip; (San
Diego, CA) ; Aggarwal; Pooja; (Dublin, CA) ;
Daley; Robert S.; (Del Mar, CA) ; Renschler;
Martin; (San Diego, CA) ; Lundqvist; Patrik;
(Encinitas, CA) |
Correspondence
Address: |
QUALCOMM INCORPORATED
5775 MOREHOUSE DR.
SAN DIEGO
CA
92121
US
|
Assignee: |
QUALCOMM Incorporated
San Diego
CA
|
Family ID: |
40624182 |
Appl. No.: |
12/268905 |
Filed: |
November 11, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60988029 |
Nov 14, 2007 |
|
|
|
60988033 |
Nov 14, 2007 |
|
|
|
60988037 |
Nov 14, 2007 |
|
|
|
60988045 |
Nov 14, 2007 |
|
|
|
Current U.S.
Class: |
455/414.2 |
Current CPC
Class: |
G06N 20/00 20190101;
H04W 4/21 20180201; H04L 67/04 20130101; G06F 40/10 20200101; H04L
67/22 20130101; H04M 3/4878 20130101; H04L 69/08 20130101; H04L
51/38 20130101; H04L 67/306 20130101; H04L 12/189 20130101; H04W
4/12 20130101; G06Q 30/02 20130101; H04L 51/12 20130101; H04L 51/14
20130101; H04L 12/1859 20130101; H04L 67/18 20130101; H04L 67/20
20130101; H04W 8/18 20130101; H04L 67/26 20130101; H04L 67/322
20130101; G06N 3/004 20130101 |
Class at
Publication: |
455/414.2 |
International
Class: |
H04W 4/00 20090101
H04W004/00 |
Claims
1. A method for determining a suitability for a mobile client to
receive a targeted content message, comprising: generating user
profile data by the mobile client; receiving a set of target
profile data associated with the targeted content message, the set
of target profile data being descriptive of the targeted content
message; comparing the user profile data with the target set of
profile data to produce a set of confidence-level data, a target
set of profile data describing the content of a respective
targeted-content message; and storing the targeted content message
in the mobile client based upon the set of confidence-level
data.
2. The method according to claim 1, wherein the comparing involves
an implementation of a fuzzy logic algorithm.
3. The method according to claim 1, wherein the comparing involves
an implementation of a neural net algorithm.
4. The method according to claim 1, wherein the comparing involves
an implementation of a dot-product algorithm.
5. The method according to claim 1, wherein the comparing involves
an implementation of a maximum-minimum qualification.
6. The method according to claim 1, wherein the comparing
confidence-level data includes at least one of statistical
averaging, curve fitting and regression analysis.
7. The method according to claim 1, wherein the comparing
confidence-level data includes at least scalar manipulation of an
n-dimensional vector
8. The method according to claim 1, wherein the confidence-level
data includes a likely age range of a user of the mobile
client.
9. The method according to claim 1, wherein the confidence-level
data includes a likelihood for a location of interest of a user of
the mobile client.
10. The method according to claim 9, wherein the confidence-level
data includes a likelihood for a home location for the user of the
mobile client.
11. The method according to claim 9, wherein the confidence-level
data includes likelihood for a work location for the user of the
mobile client.
12. The method according to claim 9, wherein the confidence-level
data includes a likelihood for a recreational location for the user
of the mobile client.
13. The method according to claim 1, wherein the confidence-level
data includes a likely range of income for a user of the mobile
client.
14. The method according to claim 1, wherein the set of target
profile data include a set of words that are substantially
non-overlapping conceptually to one another.
15. A mobile client capable of determining a suitability for a
mobile client to receive a targeted content message, comprising:
profile generation circuitry configured to generate user profile
data; receiving circuitry configured to receive a set of target
profile data associated with the targeted content message, the set
of target profile data being descriptive of the targeted content
message; comparing circuitry configured to compare the user profile
data with the set of target profile data to produce a set of
confidence-level data, a target set of profile data describing the
content of a respective targeted-content message; and cache
controlling circuitry configured to store the targeted content
message in the mobile client based upon the set of confidence-level
data.
16. The mobile client according to claim 15, wherein the comparing
circuitry implements of a fuzzy logic algorithm to compare user
profile with target profile data.
17. The mobile client according to claim 15, wherein the comparing
circuitry implements of a neural net algorithm to compare user
profile with target profile data.
18. The mobile client according to claim 15, wherein the comparing
circuitry implements of a dot-product algorithm to compare user
profile with target profile data.
19. The mobile client according to claim 15, wherein the comparing
circuitry implements of a maximum-minimum qualification to compare
user profile with target profile data.
20. The mobile client according to claim 15, wherein the
confidence-level data includes a likely age range of a user of the
mobile client.
21. The mobile client according to claim 15, wherein the
confidence-level data includes a likelihood for a location of
interest of a user of the mobile client.
22. The mobile client according to claim 21, wherein the
confidence-level data includes a likelihood for a home location for
the user of the mobile client.
23. The mobile client according to claim 21, wherein the
confidence-level data includes likelihood for a work location for
the user of the mobile client.
24. The mobile client according to claim 21, wherein the
confidence-level data includes a likelihood for a recreational
location for the user of the mobile client.
25. The mobile client according to claim 15, wherein the
confidence-level data includes a likely range of income for a user
of the mobile client.
26. The mobile client according to claim 15, wherein the circuitry
for comparing confidence-level data includes circuitry for
performing at least one of statistical averaging, curve fitting,
regression analysis, processing data through an artificial neural
network and scalar manipulation.
27. The mobile client according to claim 26, wherein the circuitry
for comparing confidence-level data includes circuitry for
performing at least scalar manipulation of an n-dimensional
vector.
28. The mobile client according to claim 15, wherein the set of
target profile data include a set of words that are substantially
non-overlapping conceptually to one another.
29. A mobile client capable of determining a suitability for a
mobile client to receive a targeted content message, comprising:
means for generating user profile data by the mobile client; means
for receiving a set of target profile data associated with the
targeted content message, the set of target profile data being
descriptive of the targeted content message; means for comparing
the user profile data with the target set of profile data to
produce a set of confidence-level data, a target set of profile
data describing the content of a respective targeted-content
message; and means for storing the targeted content message in the
mobile client based upon the set of confidence-level data.
30. The mobile client according to claim 29, wherein the means for
comparing uses at least one of a fuzzy logic algorithm, a neural
net algorithm, a dot-product algorithm, a maximum-minimum
qualification, a statistical averaging algorithm, a curve fitting
algorithm and a regression analysis algorithm.
31. The mobile client according to claim 29, wherein the means for
comparing uses at least at least scalar manipulation of an
n-dimensional vector
32. The mobile client according to claim 29, wherein the
confidence-level data includes a likely age range of a user of the
mobile client.
33. The mobile client according to claim 29, wherein the
confidence-level data includes a likelihood for a location of
interest of a user of the mobile client.
34. The mobile client according to claim 33, wherein the
confidence-level data includes at least one of a likelihood for a
home location for the user of the mobile client, a work location
for the user of the mobile client, and a recreational location for
the user of the mobile client.
35. The mobile client according to claim 29, wherein the
confidence-level data includes a likely range of income for a user
of the mobile client.
36. The mobile client according to claim 29, wherein the set of
target profile data include a set of words that are substantially
non-overlapping conceptually to one another.
37. A mobile client, comprising: a memory; a transceiver; a
processor coupled to the memory and operable to: generate user
profile data by the mobile client; receive a set of target profile
data associated with the targeted content message, the set of
target profile data being descriptive of the targeted content
message; compare the user profile data with the target set of
profile data to produce a set of confidence-level data, a target
set of profile data describing the content of a respective
targeted-content message; and store the targeted content message in
the memory based upon the set of confidence-level data.
38. A computer program product, comprising: a computer-readable
medium comprising: a first instruction for generating user profile
data by a mobile client; a second instruction for receiving a set
of target profile data associated with the targeted content
message, the set of target profile data being descriptive of the
targeted content message; a third instruction for comparing the
user profile data with the target set of profile data to produce a
set of confidence-level data, a target set of profile data
describing the content of a respective targeted-content message;
and a fourth instruction for storing the targeted content message
in the mobile client based upon the set of confidence-level data.
Description
[0001] This Application both claims to priority, and incorporates
the entire content of, United States Provisional Patent Application
Nos. 60/988,029 entitled "METHOD AND SYSTEM FOR USER PROFILE MATCH
INDICATION IN A MOBILE ENVIRONMENT" and filed on Nov. 14, 2007;
60/988,033 entitled "METHOD AND SYSTEM FOR KEYWORD CORRELATION IN A
MOBILE ENVIRONMENT" and filed on Nov. 14, 2007; 60/988,037 entitled
"METHOD AND SYSTEM FOR USER PROFILE MATCH INDICATION IN A MOBILE
ENVIRONMENT" and filed on Nov. 14, 2007, and 60/988,045 entitled
"METHOD AND SYSTEM FOR MESSAGE VALUE CALCULATION IN A MOBILE
ENVIRONMENT" and filed on Nov. 14, 2007. This Application also
incorporates the entire content of United States Non-Provisional
Patent Application Nos. ______ (Qualcomm Attorney Docket No.
071913U1) entitled "USER PROFILE MATCH INDICATION IN A MOBILE
ENVIRONMENT METHODS AND SYSTEMS" and filed on ______; ______
(Qualcomm Attorney Docket No. 071913U2) entitled "METHOD AND SYSTEM
USING KEYWORD VECTORS AND ASSOCIATED METRICS FOR LEARNING AND
PREDICTION OF USER CORRELATION OF TARGETED CONTENT MESSAGES IN A
MOBILE ENVIRONMENT" and filed on ______; ______ (Qualcomm Attorney
Docket No. 071913U3) entitled "METHOD AND SYSTEM FOR USING A CACHE
MISS STATE MATCH INDICATOR TO DETERMINE USER SUITABILITY OF
TARGETED CONTENT MESSAGES IN A MOBILE ENVIRONMENT" and filed on
______; ______ (Qualcomm Attorney Docket No. 071913U4) entitled
"METHOD AND SYSTEM FOR MESSAGE VALUE CALCULATION IN A MOBILE
ENVIRONMENT" and filed on ______; ______ (Qualcomm Attorney Docket
No. 071913U5) entitled "METHOD AND SYSTEM USING KEYWORD VECTORS AND
ASSOCIATED METRICS FOR LEARNING AND PREDICTION OF USER CORRELATION
OF TARGETED CONTENT MESSAGES IN A MOBILE ENVIRONMENT" and filed on
______.
FIELD OF THE DISCLOSURE
[0002] This disclosure relates to wireless communications. In
particular, the present disclosure relates to wireless
communications systems usable for targeted-content-message
processing and related transactions.
BACKGROUND
[0003] Mobile Targeted-Content-Message (TCM)-enabled systems can be
described as systems capable of delivering targeted content
information, such as local weather reports and advertisements
targeted to a particular demographic, to wireless communication
devices (WCDs), such as cellular telephones or other forms of
wireless access terminals (W-ATs). Such systems may also provide a
better user experience by presenting non-intrusive
targeted-content-messages that are likely to be of interest to a
user.
[0004] An example of a mobile TCM-enabled system is a mobile
targeted advertisement system (MAS) capable of delivering
advertisements to wireless communication devices (WCDs). Generally,
a MAS can provide such things as an advertisement sales conduit for
a cellular provider to provide advertisements on a W-AT, as well as
some form of analytical interface to report back on the performance
of various advertisement campaigns. A particular consumer benefit
of mobile advertising is that it can provide alternate/additional
revenue models for wireless services so as to allow more economical
access to the wireless services to those consumers willing to
accept advertisements. For example, the revenue generated through
advertising may allow W-AT users to enjoy various services without
paying the full subscription price usually associated with such
services.
[0005] In order to increase the effectiveness of TCMs on W-ATs, it
can be beneficial to provide targeted information, i.e., TCMs which
are deemed likely to be well received by, and/or of likely interest
to, a particular person or a designated group of people.
[0006] Targeted-Content-Message (TCM) information can be based on
immediate needs or circumstances, such as a need to find emergency
roadside service or the need for information about a travel route.
Targeted-Content-Message information can also be based on specific
products or services (e.g., games) for which a user has
demonstrated past interest, and/or based on demographics, for
example, a determination of an age and income group likely to be
interested in a particular product. Targeted Advertisements are an
example of TCMs.
[0007] Targeted advertisements can provide a number of advantages
(over general advertisements) including: (1) in an economic
structure based on cost per view, an advertiser may be able to
increase the value of his advertising budget by limiting paid
advertising to a smaller set of prospects; and (2) as targeted
advertisements are likely to represent areas of interest for a
particular user, the likelihood that users will respond positively
to targeted advertisements increases substantially.
[0008] Unfortunately, the information that makes some forms of
targeted advertising possible may be restricted due to government
regulations and the desire of people to limit the dissemination of
their personal information. For example, in the US, such government
restrictions include the Graham-Leach-Bliley Act (GLBA), Title 47
of the United States Code, Section 222--"Privacy of Customer
Information." Common carriers also may be restricted from using
personal information about their subscribers for marketing
purposes. For example, the GLBA prohibits access to individually
identifiable customer information, as well as the disclosure of
location information, without the express prior authorization of
the customer.
[0009] Thus, new technology for delivering targeted advertising in
a wireless communication environment is desirable.
SUMMARY OF THE DISCLOSURE
[0010] In an exemplary embodiment, a method for determining a
suitability for a mobile client to receive a targeted content
message includes generating user profile data by the mobile client,
receiving a set of target profile data associated with the targeted
content message, the set of target profile data being descriptive
of the targeted content message, comparing the user profile data
with the target set of profile data to produce a set of
confidence-level data, a target set of profile data describing the
content of a respective targeted-content message, and storing the
targeted content message in the mobile client based upon the set of
confidence-level data.
[0011] In another exemplary embodiment, a mobile client capable of
determining a suitability for a mobile client to receive a targeted
content message includes profile generation circuitry configured to
generate user profile data; receiving circuitry configured to
receive a set of target profile data associated with the targeted
content message, the set of target profile data being descriptive
of the targeted content message; comparing circuitry configured to
compare the user profile data with the set of target profile data
to produce a set of confidence-level data, a target set of profile
data describing the content of a respective targeted-content
message; and cache controlling circuitry configured to store the
targeted content message in the mobile client based upon the set of
confidence-level data.
[0012] In yet another exemplary embodiment, a mobile client capable
of determining a suitability for a mobile client to receive a
targeted content message includes a generating means for generating
user profile data by the mobile client, a receiving means for
receiving a set of target profile data associated with the targeted
content message, the set of target profile data being descriptive
of the targeted content message, a comparing means for comparing
the user profile data with the target set of profile data to
produce a set of confidence-level data, a target set of profile
data describing the content of a respective targeted-content
message, and a storing means for storing the targeted content
message in the mobile client based upon the set of confidence-level
data.
[0013] In yet another exemplary embodiment, a mobile client
includes one or more processors and one or more computer-readable
memories accessible to the processors and containing instructions
for: generating user profile data by the mobile client, receiving a
set of target profile data associated with the targeted content
message, the set of target profile data being descriptive of the
targeted content message, comparing the user profile data with the
target set of profile data to produce a set of confidence-level
data, a target set of profile data describing the content of a
respective targeted-content message, and storing the targeted
content message in the mobile client based upon the set of
confidence-level data.
[0014] In still another exemplary embodiment, a computer program
product includes a computer-readable medium that in turn includes a
first set of instructions for generating user profile data by the
mobile client, a second set of instructions for receiving a set of
target profile data associated with the targeted content message,
the set of target profile data being descriptive of the targeted
content message, a third set of instructions for comparing the user
profile data with the target set of profile data to produce a set
of confidence-level data, a target set of profile data describing
the content of a respective targeted-content message, and a fourth
set of instructions for storing the targeted content message in the
mobile client based upon the set of confidence-level data.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The features and nature of the present disclosure will
become more apparent from the detailed description set forth below
when taken in conjunction with the drawings in which reference
characters identify corresponding items and processes
throughout.
[0016] FIG. 1 is a diagram showing the interaction between an
exemplary wireless access terminal (W-AT) and an advertising
infrastructure. An advertising infrastructure is an example of a
targeted-content-message-processing infrastructure.
[0017] FIG. 2 is schematic block diagram showing the operation of
an exemplary W-AT having an on-board user profile generation
agent.
[0018] FIG. 3 is a schematic block diagram showing an exemplary
operation of a data transfer of a user profile generation
agent.
[0019] FIG. 4 is a schematic block diagram handling an exemplary
request for profile data processing.
[0020] FIG. 5 is a schematic block diagram showing an exemplary
operation of a user profile generation agent.
[0021] FIG. 6 is a flowchart outlining an exemplary operation for
generating and using a user profile.
[0022] FIG. 7 is a flowchart outlining another exemplary operation
for generating and using a user profile.
[0023] FIG. 8 is a diagram illustrating the use of a one-way hash
function for client identity protection when identifiable data is
transferred to a mobile advertising/mobile targeted-content-message
processing server.
[0024] FIG. 9 is a diagram illustrating data flow implemented by a
proxy server for anonymizing identifiable data transferred to a
mobile advertising server/mobile targeted-content-message
processing server.
[0025] FIG. 10 is a diagram illustrating a second data flow
implemented by a proxy server for anonymizing identifiable data
transferred to a mobile advertising server mobile
targeted-content-message processing server.
[0026] FIG. 11 depicts a communication protocol for advertisement
distribution in a mobile targeted content message-enabled
network.
[0027] FIG. 12 depicts another communication protocol for
targeted-content-message distribution in a mobile message
delivery-enabled network.
[0028] FIG. 13 depicts another communication protocol for
targeted-content-message distribution in a mobile message
delivery-enabled network.
[0029] FIG. 14 depicts another communication protocol for
targeted-content-message distribution in a mobile message
delivery-enabled network.
[0030] FIG. 15 depicts a timeline for a first communication
protocol for downloading advertising content according to "contact
windows" approach.
[0031] FIG. 16 depicts an alternate timeline for a communication
protocol for downloading advertising content according to a defined
time schedule.
[0032] FIG. 17 depicts an alternate timeline for a first
communication protocol for downloading content according to a
defined time schedule.
[0033] FIG. 18 is an illustration of a message filtering
process.
[0034] FIG. 19 is an illustration of message filtering process
components.
[0035] FIG. 20 is an illustration of a gating process.
[0036] FIG. 21 is an illustration of a random sampling logic
diagram.
[0037] FIG. 22 is an illustration of a one-way function based
sampling logic diagram.
[0038] FIG. 23 is an illustration of selection process flow
diagram.
[0039] FIGS. 24A and 24B depict a flowchart of a message selection
process.
[0040] FIG. 25 is a flow chart illustrating an exemplary User
Profile Match Indicator (MI) process.
[0041] FIG. 26 is a block diagram illustrating an exemplary user
profile match indicator.
[0042] FIG. 27 is a flow chart of an exemplary keyword correlation
process.
[0043] FIG. 28 block diagram illustrating an exemplary learning and
prediction engine.
[0044] FIG. 29 block diagram illustrating an exemplary learning and
prediction engine in context with other elements of a mobile
client.
[0045] FIG. 30A depicts an exemplary hierarchical keyword
organization.
[0046] FIG. 30B depicts an exemplary non-hierarchical/flattened
keyword organization.
[0047] FIG. 31 depicts a series of graphs representing the expected
performance of an exemplary learning process for enabling a mobile
client to adapt to user preferences.
[0048] FIGS. 32A and 32B depict a block diagram illustrating an
exemplary process for enabling a mobile client to adapt to user
preferences.
[0049] FIG. 33 is an illustration of a multicast/broadcast message
distribution.
[0050] FIG. 34 is an illustration of an exemplary unicast message
distribution protocol.
[0051] FIG. 35 is an illustration of another exemplary unicast
message distribution protocol.
[0052] FIG. 36 is an illustration of yet another exemplary unicast
message distribution protocol.
[0053] FIG. 37 is an illustration of still another exemplary
unicast message distribution protocol.
[0054] FIGS. 38A-38H depict various captured location data with
historical information for a particular user.
[0055] FIG. 39 and FIG. 40 depict an exemplary set of locations and
paths for a user.
[0056] FIG. 41 is an exemplary Markov Model for the set of
locations and paths of FIGS. 39 and 40.
[0057] FIG. 42 is diagram of a process flow outlining an exemplary
operation for updating the user profile based captured location
information.
DETAILED DESCRIPTION
[0058] The disclosed methods and systems below may be described
generally, as well as in terms of specific examples and/or specific
embodiments. For instances where references are made to detailed
examples and/or embodiments, it should be appreciated that any of
the underlying principals described are not to be limited to a
single embodiment, but may be expanded for use with any of the
other methods and systems described herein as will be understood by
one of ordinary skill in the art unless otherwise stated
specifically.
[0059] The word "exemplary" is used herein to mean "serving as an
example, instance, or illustration." Any aspect described herein as
"exemplary" is not necessarily to be construed as preferred or
advantageous over other aspects.
[0060] For the purpose of example, the present disclosure is often
depicted as being implemented in (or used with) a cellular
telephone. However, it is to be appreciated that the methods and
systems disclosed below may relate to both mobile and non-mobile
systems including mobile phones, PDAs and lap-top PCs, as well as
any number of specially equipped/modified music players (e.g., a
modified Apple iPOD.RTM.), video players, multimedia players,
televisions (both stationary, portable and/or installed in a
vehicle), electronic game systems, digital cameras and video
camcorders.
[0061] The terms and respective definitions/descriptions below are
provided as a reference to the following disclosure. Note, however,
that when applied to certain embodiments, some of the applied
definitions/descriptions may be expanded or may otherwise differ
with some of the specific language provided below as may be
apparent to one of ordinary skill and in light of the particular
circumstances.
[0062] TCM--Targeted-Content-Message. An advertisement can be an
example of a Targeted-Content-Message.
[0063] M-TCM-PS--Mobile Targeted-Content-Message Processing
System
[0064] MAS--Mobile advertising system, which may be considered a
form of M-TCM-PS.
[0065] UPG--User Profile Generation Agent
[0066] M-TCM--Mobile TCM-Enabled Client
[0067] MAEC--Mobile advertising enabled client. This can be an
example of a Mobile
[0068] TCM--Enabled Client Mobile TCM Provider (M-TCM-P)--A person
or an entity that may want to display a targeted-content-message
through a targeted-content-message processing system.
[0069] Advertiser--A person or an entity that may want to display
advertisements through a mobile advertising system (MAS). An
advertiser may provide the advertisement data along with respective
targeting and playback rules, which may in some instances form
advertisement metadata to a MAS. An advertiser is an example of a
Mobile TCM Provider.
[0070] TCM Metadata--A term used to identify data that can be used
to provide additional information about a respective
Targeted-Content-Message (TCM).
[0071] Advertisement Metadata--A term used to identify data that
may be used to provide additional information about a respective
advertisement. This may include, but is not limited to, mime type,
advertisement duration, advertisement viewing start time,
advertisement viewing end time, etc. Respective advertisement
targeting and playback rules provided by the advertiser may also
get attached to an advertisement as metadata for the advertisement.
Advertisement Metadata is an example of TCM metadata.
[0072] Application Developer--A person who or an entity that
develops an application for the mobile advertising enabled client
(MAEC) that can feature advertisements.
[0073] System Operator--A person who or entity that operates a
MAS.
[0074] Third Party Inference Rule Provider--A third party (other
than a system operator) who may provide user profile inference
rules to be used by a User Profile Generation Agent
[0075] User Profile Generation Agent--A functional unit at the
client that may receive various pertinent data, such as
advertisement inference rules, user behavior from a metric
collection agent, location data from a GPS, explicit user
preferences entered by a user (if any) and/or user behavior from
other client applications, then generate various user profile
elements. A User Profile Generation Agent may continuously update a
profile based upon information gathered that may be used to
characterize user behavior.
[0076] User Behavior Synthesizer--A functional device or agent
within a User Profile Generation Agent that may be used to receive
a variety of data, such as user behavior information, location
information and user profile inference rules to generate
synthesized profile attributes.
[0077] Profile Element Refiner--A functional device or agent within
a User Profile Generation Agent that may receive profile attributes
generated by a user behavior synthesizer as well as a number of
user profile inference rules. A Profile Element Refiner may refine
profile attributes, process them through queries sent to a profile
attribute processor, and generate user profile elements.
[0078] Profile Attribute Processor--A server and/or resident agent
of a server that may process profile attribute requests that may
require data-intensive lookups, and then respond with refined
profile attributes.
[0079] TCM Filtering Agent--A client agent that may receive a
number of TCMs with their respective meta-data, TCM targeting rules
and TCM filtering rules, then store some or all of the TCMs in a
TCM-cache memory. The filtering agent may also take a user profile
as input from the User Profile Generation Agent.
[0080] Advertisement Filtering Agent--A client agent that may
receive a number of advertisements with their respective metadata,
advertisement targeting rules and advertisement filter rules, then
store some or all of the received advertisements in an
advertisement cache memory. The filtering agent may also take a
user profile as input from the User Profile Generation Agent. An
advertising filtering agent is an example of a TCM filtering
agent.
[0081] TCM Cache Manager--A client agent that can maintain a
targeted content-message cache. A cache manager may take cached
targeted content-messages from a filtering agent, and respond to
content-message requests from other applications on the access
terminal. Note that, for the present disclosure, the term `cache`
can refer to a very broad set of memory configurations, include a
single storage device, a set of distributed storage devices (local
and/or not local) and so on. Generally, it should be appreciated
that the term `cache` can refer to any memory usable to speed up
information display, processing or data transfer.
[0082] Advertisement Cache Manager--A client agent that can
maintain an advertisement cache. A cache manager may take cached
advertisements from a filtering agent and respond to advertisement
requests from other applications on the access terminal. An
advertisement cache manager is an example of a TCM cache
manager.
[0083] User Profile Attributes--User behavior, interests,
demographic information, and so on that may be synthesized by a
user behavior synthesizer to form profile attributes, which may be
viewed as intermediate pre-synthesized forms of data that may be
further processed and refined by a profile element refiner into
more refined user profile elements.
[0084] User Profile Elements--Items of information used to maintain
a user profile, which may include various types of data useful to
categorize or define the user's interests, behavior, demographic,
etc.
[0085] TCM Targeting Rules--These may include rules related to the
presentation of a targeted-content-message specified by a Mobile
TCM Provider.
[0086] Advertisement Targeting Rules--These may include rules
specified by advertisers to impose rules/restrictions on how
advertisements may be displayed and/or rules to target an
advertisement towards a particular segment of users. They may be
specific to a number of criteria, such as an advertisement campaign
or advertisement group. Advertisement Targeting Rules are an
example of TCM Targeting Rules.
[0087] TCM Playback Rules--These can include display rules
specified by a client application while querying a TCM Cache
Manager for TCMs to display in the context of their
application.
[0088] Advertisement Playback Rules--These can include display
rules specified by a client application while querying an
Advertisement Cache Manager for advertisements to display in the
context of their application. Advertisement Playback Rules are an
example of TCM Playback Rules.
[0089] TCM Filter Rules--These can include rules upon which TCMs
may be filtered. Typically, a system operator may specify these
rules.
[0090] Advertisement Filter Rules--These can include rules upon
which advertisements may be filtered. Typically, a system operator
may specify these rules. Advertisement Filter Rules are an example
of TCM-Filter-Rules.
[0091] User Profile Element Inference Rules--These can include
rules, specified by a system operator (and/or a third party), that
may be used to determine one or more processes usable to build a
user profile from demographic and behavioral data.
[0092] TCM Telescoping--A display or presentation function for a
TCM whereby additional presentation material may presented to a
user in response to a user request.
[0093] Advertisement Telescoping--An advertisement display or
presentation function whereby additional presentation material may
be presented to a user in response to a user request. Advertisement
Telescoping is an example of TCM telescoping.
[0094] As mentioned above, various regulations regarding
telecommunications and privacy can make the delivery of messages
with targeted content difficult. However, the present disclosure
can provide a variety of solutions to deliver targeted content to
wireless access terminals (W-ATs), e.g., cellular phones, while
paying attention to privacy concerns.
[0095] One of the many approaches of this disclosure used to
alleviate privacy issues includes offloading a variety of processes
onto a user's W-AT that may, in turn, be used to generate a set of
information that likely characterizes the user, i.e., it can create
a "user profile" of the user on the W-AT itself. Accordingly,
targeted-content-messages, such as advertisements and other media,
may be directed to the user's W-AT based on the user's profiles
without exposing potentially sensitive customer information to the
outside world.
[0096] The various disclosed methods and systems may be used in a
Mobile TCM Processing System (M-TCM-PS) (and, in particular, in a
Mobile Advertising System (MAS)), which for the present disclosure
may include an end-to-end communication system usable to deliver
targeted-content-messages (or in particular, advertisements) to
TCM-Enabled W-ATs (or in particular Mobile Advertising Enabled
W-ATs). A M-TCM-PS may also provide an analytical interface capable
of reporting on the performance of a particular advertisement
campaign. Accordingly, an appropriately constructed M-TCM-PS may
provide a better consumer experience by presenting only
non-intrusive advertisements that are likely to be of interest to
consumers.
[0097] While the following examples are generally directed to
content, such as commercial advertising, a broader scope of
directed content is envisioned. For example, instead of directed
advertisements, content such as stock reports, weather reports,
religious information, news and sports information specific to a
user's interests, and so on is envisioned within the bounds of this
disclosure. For example, while directed content may be an
advertisement, a score for a sports event and a weather report may
just as easily be directed content. Accordingly, devices such as
advertising servers may be viewed as more general content servers,
and advertising-related agents and devices may be more generally
thought of as content-related agents and servers. All further
discussion is provided in the context of advertisements as an
example of a TCM (Targeted Content Message), and it should be noted
that such discussion is applicable to Targeted-Content-Messages in
general.
[0098] FIG. 1 is a diagram of some of the various functional
elements of an M-TCM-PS showing the interaction between a
TCM-enabled W-AT 100 with a communication network having an
advertising infrastructure. As shown in FIG. 1, the exemplary
M-TCM-PS includes the TCM-enabled mobile client/W-AT 100, a
radio-enabled network (RAN) 190 and an advertising infrastructure
150 embedded in the network associated with the wireless WAN
infrastructure (not shown in FIG. 1). For example, the messaging
infrastructure could be available at a remote server not
geographically co-located with a cellular base station in the
wireless WAN.
[0099] As shown in FIG. 1, the W-AT can include a client
applications device 110, a client message delivery interface 112, a
metric collection agent 120, a message caching manager 122, a
message filtering agent 124, a metric reporting agent 126, a
message reception agent 120 and a data service layer device 130.
The message delivery infrastructure 150 can include a TCM sales
agent 160, an analytics agent 162, a message delivery server
interface 164, a message ingestion agent 170, a message bundling
agent 174, a message distribution agent 176, a metric database 172,
a metric collection agent 178, and having a proxy server 182.
[0100] In operation, the "client side" of the M-TCM-PS can be
handled by the W-AT 100 (depicted on the left-hand side of FIG. 1).
In addition to traditional applications associated with W-ATs, the
present W-AT 100 may have TCM-related applications at the
applications level 110, which in turn may be linked to the rest of
the M-TCM-PS via a client advertisement interface 112. In various
embodiments, the client message delivery interface 112 may provide
for metrics/data collection and management. Some of the collected
metrics/data may be transferred to the metric reporting agent 126
and/or to the W-AT's data service layer 130 (via the metric
collection agent 120), without exposing individually identifiable
customer information, for further distribution to the rest of the
M-TCM-PS.
[0101] The transferred metrics/data may be provided through the RAN
190 to the message delivery infrastructure 150 (depicted on the
right-hand side of FIG. 1), which for the present example includes
a variety of TCM-related and privacy-protecting servers. The
message delivery infrastructure 150 can receive the metrics/data at
a data service layer 180, which in turn may communicate the
received metrics/data to a number of metrics/data collection
servers (here metric collection agent 178) and/or software modules.
The metrics/data may be stored in the metric database 172, and
provided to the message delivery server interface 164 where the
stored metrics/data may be used for marketing purposes, e.g.,
advertising, sales and analytics. Note that information of interest
may include, among other things, user selections at a W-AT and
requests for advertisements executed by the W-AT in response to
instructions provided by the message delivery infrastructure
150.
[0102] The message delivery server interface 164 can provide a
conduit for supplying advertisements (advertising ingestion),
bundling advertisements, determining a distribution of
advertisements and sending advertising through the data service
layer 180 of the message delivery infrastructure 150 to the rest of
the M-TCM-PS network. The a message delivery infrastructure 150 can
provide the W-AT 100 with the appropriate TCMs, and metadata for
the TCMs. The W-AT 100 can be instructed by the message delivery
infrastructure 150 to select TCMs based on any available metadata
according to rules provided by the message infrastructure 150.
[0103] As mentioned above, the exemplary W-AT 100 may be enabled to
generate, in whole or in part, a user profile for the W-AT's user
that, in turn, may be useful to enable the M-TCM-PS to deliver TCMs
of likely interest to the user. This may result in better
"click-through rates" for various advertisement campaigns and other
TCM delivery campaigns. However, as mentioned above, generating a
user profile may raise privacy concerns because of the potentially
sensitive nature of data that may reside in the user profile.
[0104] Nevertheless, as will be shown below in the various device
and system embodiments, privacy concerns may be alleviated by
enabling a user's W-AT to generate a user profile while
subsequently limiting the user profile to the confines of the
user's W-AT except in very limited (and controlled)
circumstances.
[0105] FIG. 2 is a block diagram showing operational details of the
exemplary W-AT of FIG. 1 configured to generate and use a user
profile. As shown in FIG. 2, the exemplary W-AT includes a
processing system capable of processing a number of applications
including a number of core client applications and a client message
delivery interface. Note that some components, such as the message
reception agent 128 and data service layer 130, are omitted from
FIG. 2 for simplicity of explanation for the functions relevant to
FIG. 2. The exemplary W-AT 100 of FIG. 2 is shown having a platform
specific adaptation interface 111 between the client message
delivery interface 112 and the client applications device 110, and
a message filtering agent 124 having a user profile generation
agent 210 and a client message filtering agent 220 responsive to
the user profile generation agent 210. A cache memory 240 is shown
in communication with the cache manager 122. External devices,
e.g., profile attribute processor 270, system operator (or 3.sup.rd
party) 280 and message sales interface 164, are shown in
communication with the client message filtering agent 124. Devices
270, 280 and 164 are generally not part of a W-AT, but likely to
reside in another portion of a M-TCM-PS network.
[0106] While the various components 110-240 of the W-AT 100 are
depicted as separate functional blocks, it should be appreciated
that each of these functional blocks may take a variety of forms
including separate pieces of dedicated logic, separate processors
running separate pieces of software/firmware, collections of
software/firmware residing in a memory and being operated upon by a
single processor, and so on.
[0107] In operation, the client applications device 110 may perform
any number of functional applications useful for telecommunications
(e.g., calls and text messaging) or other tasks (e.g., games) using
the platform specific adaptation interface 111 to interface with
the client message delivery interface 112. The client message
delivery interface 112, in turn, can be used to allow the W-AT 100
to perform a number of useful processes, such as monitor user
behavior and pass user-related information to the user profile
generation agent 210.
[0108] In addition to receiving information directly from the
client applications interface, the user profile generation agent
210 may accrue user behavior information from the metrics
collection agent 120, which itself may receive the same or
different information from the client message delivery interface
112. Examples of user behavior may include TCM-related responses,
such as advertisement clicks and other metrics indicating types and
frequency of usage. Other user behavior information may include
direct user preferences or authorizations.
[0109] The metrics collection agent 120 may provide metrics/data to
the metrics reporting agent 126, which in turn may provide the
metrics/data information to other components of M-TCM-PS (discussed
below) that may be internal or external to a W-AT.
[0110] The profile attribute processor 270 can process incoming
profile attribute processing requests from the W-AT 100 that
require (or can otherwise benefit from) data-intensive lookups and
respond with refined profile attributes to the user profile
generation agent 210.
[0111] One function of the user profile generation agent 210 may
include providing TCMs that may be provided to the W-AT's user in
accordance with relevant filter rules, as well as TCM data and TCM
metadata from the sales interface 164. The filtering agent 220 may
also provide filtered messages to the cache manager 122, which in
turn may store and later provide such messages (via cache memory
240) for presentation to the user.
[0112] A user profile generation agent can be any collection of
hardware and/or software residing in a Mobile Advertising Enabled
W-AT that can be used to collect user behavior information.
Potential information sources may include, but are not limited to,
applications residing on the user's W-AT, public information
available in various accessible databases, previous user responses
to advertisements, location data from a resident GPS radio and
explicit user preferences entered by the user (if any). Any user
profile information gathered may then be processed/synthesized to
generate user profile attributes or elements, which may better
characterize the user while using less memory resources.
[0113] In various embodiments, user profile inference rules
provided by a system operator (and/or a third party) may drive the
particular actions of a W-AT's user profile generation agent. Note
that these rules may be of a number of types, including: (1) Basic
Rules, which include actions to be performed by a user profile
generation agent on a pre-determined schedule associated with each
action; and (2) Qualified Rules, which include "action(s)" that are
qualified by a "condition", where the "condition" may define a
behavior that needs to be true, and the "action" may define an
action taken by a rule engine of the user profile generation agent
when the condition is detected to be true. Such rules may be useful
in inferring information from specific user actions or
behavior.
[0114] For example, a simple rule for a user profile generation
agent might be to store GPS derived location information for the
user's W-AT every five minutes. An associated rule could be that
the location most frequented within a 09:00-17:00 time range in the
day be marked as the user's likely work location.
[0115] By way of a second example, a rule qualified by a condition
might be to add a "game" category to the user's list of interests
if the user often spends more than 30 minutes a day in the gaming
applications on his W-AT.
[0116] Also note that the user profile generation agent may also
take as input user preferences including user selection concerning
express authorization of the user to derive a profile using
location data, other authorizations made by the user and other
specific information entered by the user. For example, the user
might input his preference to view travel-related
advertisements.
[0117] Various rule-driven approaches incorporated in a user's W-AT
usable to gather and refine/categorize behavior data may alleviate
some of the privacy concerns users might have. For example, by
mining data and synthesizing raw data into more meaningful/useful
forms within the W-AT (as opposed to using an external server),
sensitive or personal information can be developed and later used
for targeted advertising without exposing this information to the
rest of the W-AT's communication network.
[0118] In various embodiments, particular aspects of a user's
profile may control portions of the user's W-AT. For example, a
user profile generation agent may utilize any retrieved W-AT
information to tailor information content in a manner best suited
for the W-AT, including the choice of menu layout, such as linear,
hierarchical, animated, popup and softkeys.
[0119] As mentioned above, while most profile generation rules can
be interpreted by the W-AT's embedded user profile generation
agent, there might be some rules that require large database
lookups, e.g., government census data. Since memory on the W-AT may
be too limited to accommodate large databases, it may be possible
to further refine the already synthesized user behavior and
demographic data by offloading the appropriate refinement tasks to
a specially configured server at the W-AP side of the M-TCM-PS
network. For the present disclosure, any such external server
capable of assisting in user profile generation may be referred to
as a "profile attribute processor." Additional discussion of
profile attribute processors is provided below with respect to FIG.
4.
[0120] FIG. 3 is a schematic block diagram of the previously
presented user profile generation agent 210 shown in the context of
interacting with other devices 312 and 280. Various capabilities of
the user profile generation agent 210 (in addition to those
discussed above) are provided in part below.
[0121] One of the features of a mobile phone is that it can be
carried by a user wherever he/she goes. Utilizing the GPS
capabilities of a W-AT, the W-AT can determine where the user is
periodically or a-periodically spending some or most of his/her
time. As there is often demographic data associated with locations,
the use of GPS information and demographic data associated with
locations that the user frequents may allow the development of at
least some portions of a demographic profile associated with the
user. Typical demographic profile elements associated with the
user's profile using the location information may include, but are
not limited to:
[0122] Location ZIP code
[0123] Gender
[0124] Median age for the frequented location
[0125] Age distribution and associated probability
[0126] Mean travel time to work
[0127] Household income or household income range
[0128] Household size
[0129] Family income or family income range
[0130] Family size
[0131] Marital status
[0132] Probability of owning a house
[0133] Probability of renting a house
[0134] Life-stage group/classification
[0135] Note that multiple demographic user profiles can be
maintained at the W-AT for the user. For example, an M-TCM Enabled
Client might be configured by the network to maintain two
demographic profiles for the user--one for his "home" location
(most frequented location between, say, 21:00-06:00) and one for
his "work" location (most frequented location between, say
09:00-17:00).
[0136] In addition to general demographics, a user profile may be
further developed using any of a W-AT's numerous applications.
Which applications, e.g., games, a user tends to spend most of his
time with or how he interacts with the various applications on the
phone may provide an opportunity to build a profile for the user
based on his behavior and preferences. Most of the data mining and
user behavior profile determination of this sort can be done on the
W-AT itself, being driven by user profile inference rules fed to
the user profile generation agent 210. Typical behavioral profile
elements associated with a user may include, but are not limited
to, the following:
[0137] Application ID and time spent in the application
[0138] Interest categorization
[0139] Favorite keywords
[0140] Favorite websites
[0141] Advertisements of interest
[0142] Music album
[0143] Games of interest
[0144] Many profile elements (including demographics) can be
inferred from behavior mined by adding hooks to observe application
behavior through a native user interface application on a W-AT. It
is through such applications that the user may launch other
applications. Applications of interest to the user and time spent
in these applications can be inferred by monitoring when the user
launches and exits a particular application.
[0145] Rules fed to the user profile generation agent 210 can
associate interest categories for a user based on the user's
interactions with applications. Interest categories can also be
assigned to the user profile using server assisted collaborative
filtering on the behavior data collected at the W-AT.
[0146] Rules that may get downloaded to the user profile generation
agent 210 may allow a server to control the functioning of the user
profile generation agent 210 in a dynamic fashion. By mining raw
data on the incumbent W-AT and synthesizing it into more meaningful
information (profile attributes), particular sensitive user
behavior information can be transformed into advertisement behavior
categories and user profile elements versus maintaining data in raw
form.
[0147] An exemplary W-AT can keep track of the messages of interest
to the user and the keywords associated with such messages. For
example, multiple clicks on the same advertisement may indicate to
a user profile agent an interest level associated with the
associated keywords and advertisement. On the same lines, games and
music of interest to the user can be maintained at the W-AT.
Server-assisted mode can also be used to associate user interest
categories with the user's profile based on the user's music and
game play-lists.
[0148] As a user profile is developed and maintained, such a
profile can take a variety of forms, e.g., synthesized profile
attributes and elements.
[0149] Note that some or all data attributes and elements in a user
profile may have some confidence level associated with them. That
is, because certain elements and attributes are based upon
inferences and rules, their results may not be certain and have
"fuzziness" associated with them. This fuzziness may be expressed
as a confidence level associated with a user profile attribute and
element.
[0150] By way of example, noting that a user is sending more that
five-hundred SMS messages per month, the profile generator might
say that the user is likely to be in the age group from 15-24 with
a confidence level of 60%. That means that if 100 users sending
more than five-hundred SMS messages per month were to be polled for
their age, about 60 of them are likely to fall within the age group
of 15-24.
[0151] Similarly, when a demographic profile is inferred for a user
based on his/her home location, there may be a confidence level
associated with the profile attributes. The confidence level here
may indicate the number of times the profile attribute is expected
to be accurate in a sample of one-hundred users with the same home
location.
[0152] The exemplary user profile generation agent 210 can also be
fed rules to combine confidence levels on the same profile
attribute from multiple sources to come up with a unified
confidence level for the attribute. For example, if the SMS usage
rate indicates that the user is within the age group of 15-24 years
with a 60% confidence level and demographic profile for the home
location indicates that the user is in age group of 15-24 years
with a 20% confidence level, then these two items can be combined
with fuzzy logic rules to come up with a unified confidence level
for the user lying in the same age group.
[0153] In contrast, if a user enters his interest preferences into
the client, then such values might be given a confidence level of
close to 100% since they are coming directly from the user.
Similarly if the carrier specifies any user profile
attributes/elements based on the user data it has (billing data or
optional profile data collected from the user during service
sign-up), then that too will have a higher confidence level
associated with it.
[0154] As more user behavior data is collected on a W-AT and
inferences made based on that, subsequent confidence level, in the
profile attribute and element values, is expected to increase.
[0155] FIG. 4 is a schematic block diagram for a profile attribute
processor 270 handling a request by a W-AT for profile attribute
processing. As discussed above, while a W-AT may be able to handle
most processing, there may be cases where huge database lookups are
required to determine portions of a behavior or demographic
profile. An example of such cases includes instances where census
databases, which may require gigabytes of storage, are useful.
Accordingly, a profile attribute processor (or other assisting
server) may be used to process user information to provide more
refined forms of user profile information.
[0156] Before a request is received by a profile attribute
processor 270, synthesized profile attributes may be gathered at
the relevant W-AT, and sent to the profile attribute processor 270
noting that the use of synthesized profile attributes can result in
better use of bandwidth. Some of the user profile attributes, which
require data-intensive lookups, can be processed by the profile
attribute processor 270 optionally by anonymously querying
techniques to protect user identities. The profile attribute
processor 270 may further refine any received attributes, and
provide the refined data to the appropriate W-AT in what may be
referred to as a set of refined user profile attributes.
[0157] When activated by a request from a W-AT, the profile
attribute processor 270 may process various types of specific and
non-specific synthesized data regarding a user's behavior and
demographics (e.g., profile attributes) and respond with the
appropriate refined profile information. In order to maintain user
privacy, some form of data scrambling, e.g., a hashing function and
a number of other tools may be employed via a device, such as the
one-way hash function generator 810 of FIG. 8. In operation, it is
possible to use a hash function at a W-AT to hide the user's
identity from the rest of the M-TCM-PS network.
[0158] In various operations, a hashing function employed in a W-AT
can generate a predictable and unique, but anonymous, value
associated with a particular user. Such an approach can enable the
W-AT to query external servers without compromising on the privacy
of the user. In various embodiments, a hashing function may be
based on a primary identifier of the W-AT, e.g. a serial number
associated with the W-AT, as well as a random value, a
pseudo-random value, and a time-based value. Further, the hashing
function may be calculated to provide a low probability of
collision with other generated values.
[0159] The W-AT may use the same random number for subsequent
queries to allow external servers to associate multiple queries
from the same client. The use of the random number can help to
prevent external servers (or unauthorized agents) from doing a
reverse lookup on a subscriber base to determine a user's
identity.
[0160] Once a hashed value is generated, the hashed value may be
used as an alternate user identifier for the W-AT and provided,
along with geographic information or some or items of information
from a user profile, and provided to a remote apparatus.
[0161] Subsequently, one or more targeted content messages can be
received from the remote apparatus based on the alternate user
identifier and first advertisement-related information to the
remote apparatus and/or other information capable of supplementing
a user profile. Such information can be incorporated into the user
profile of the W-AT.
[0162] In order to further maintain user privacy, a proxy server at
the wireless access point (W-AP) side (see, e.g., FIG. 1) may be
used. FIG. 9 depicts a particular communication scheme employing a
proxy server for securely communicating in a mobile
advertising-enabled network. As shown in FIG. 9, a W-AT 910 (the
"M-TCM-Enabled Client") can send a request (or other message, such
as a report or reply) related to a number of services, such as for
refinement of user profile information or a request for advertising
content, to a wireless application protocol (WAP) proxy 920. The
WAP proxy 920, in turn, can forward the request to a secure proxy
server 930, which may then create a transaction ID, change out the
header to remove the W-AT's identification information in favor of
the transaction ID, and forward the request to a mobile message
delivery server 940 while creating a look-up table containing that
information, e.g., the W-AT's IP address, useful to relay a
reply.
[0163] Once the mobile message delivery server 940 receives and
replies to the request, the proxy server 930 may use the
appropriate transaction ID to forward the mobile message delivery
server's reply. Later, the proxy server 930 may delete the look up
table entry.
[0164] Note that the scheme depicted in FIG. 9 can be employed to
disallow the mobile message delivery server 940 access to the
user's W-AT IP address, which in turn has a number of benefits,
such as allowing the delivery of targeted content, e.g., targeted
ads, without compromising user identity.
[0165] In order to alleviate concerns of users that their location
is possibly being tracked in real-time by their W-ATs, such W-ATs
may elect not to query the server for refinement of location data
in real-time. Note that such queries can be sent anonymously and
sparsely over an extended period of time (e.g., once a month). A
typical schedule could be, for example, to collect location
information every 5 minutes for 72 hours. The most frequented
location during this time frame or during specific time frames can
be used to query the demographic profile of the user from the
server at a randomly selected time between 30 and 40 days or by
some other schedule specified by a the system operator.
[0166] The above case is an example of a hybrid approach using both
the rule driven operation of the user profile generation agent
along with the server-assisted mode to generate profile elements
for the user while maintaining the user's privacy.
[0167] FIG. 5 is a schematic block diagram shown depicting an
exemplary operation of such a hybrid approach using a user profile
generation agent 210 having a user behavior synthesizer 522 and a
profile element refiner 524. While the majority of functionality of
the various devices of FIG. 5 has already been discussed above,
further functionality will be described below with respect to the
following flowcharts.
[0168] FIG. 6 is a flowchart outlining an exemplary operation for
generating and using a user profile. The operation starts in step
602 as a number of user profile inference rules (basic and/or
qualified rules) can be received (and subsequently stored) by a
W-AT from a system operator or other party.
[0169] As discussed above, basic rules may include pre-scheduled
events, e.g., performing a query of the user at a specific time.
Similarly, a respective qualified rule might require the same query
to be preceded by a condition and/or event, such as physical status
information or operational status information.
[0170] Next, in step 604, the received rules can be used to collect
raw data, and in step 606 the raw data may be processed/synthesized
into user profile elements or attributes noting that while all such
processing/synthesizing may occur on board the W-AT, some
refinement may occur using external devices, such as the profile
attribute processors discussed above. That is, as discussed above
raw data and/or synthesized data may be incorporated to form a user
profile for the W-AT's user. For example, a rule relating to
monitoring SMS messages may be used to change a dynamic property of
a user profile when applied to collect raw data and synthesize
profile attributes/elements regarding SMS messages. Static data,
e.g., a user's birth date, may be likewise collected using a rule
to query the user, and then applied as an element in a user
profile.
[0171] Then, in step 608, confidence levels for user profile data
can be determined. Note that confidence levels can have a variety
of forms, such as a range of numbers, variance statistic, or
distribution profile.
[0172] In step 610, various received rules plus raw data and
synthesized data relating to various user profile elements and
attributes, which may form all of a user profile, may be used to
receive TCMs. That is, as discussed above, in various embodiments a
used/usable rule on a W-AT may be used to generate a user
profile--along with collected raw data and synthesized data--to
provide any number of static or dynamic properties of the user
profile, and such information may be used to receive content, such
as advertisements, sports scores, weather reports and news directed
to subjects of likely interest.
[0173] Note that in various embodiments where user profile data can
have confidence levels associated with them, rules may be applied
to the confidence levels and targeted content messages may be
received and displayed based on such confidence information.
[0174] Continuing, control of the operation may jump back to step
602 where new/more rules may be received and used to collect data
and modify the user's profile.
[0175] Note that, as referenced above rules may be used based on
physical configuration of an W-AT so as to utilize W-AT information
to tailor content display in a manner suited for the W-AT to create
suitable displays, such as menu layouts having linear,
hierarchical, animated, popup and/or softkey attributes.
[0176] FIG. 7 is a flowchart outlining another exemplary operation
for generating and using a user profile. The operation starts in
step 702 as a number of user profile inference rules are received
by a W-AT from a system operator or other party. Next, in step 704,
the received rules can be used to collect raw data, and in step 706
the raw data may be processed/synthesized into user profile
elements or attributes using onboard resources. Again note that any
item of user profile information may have confidence level
information processed and synthesized along with the basic
data.
[0177] Continuing to step 710, a determination may be made as to
whether further information or processing is required that may not
be practical on a W-AT. For example, assuming that a W-AT has
accrued a series of locations for which the W-AT regularly has
visited using a GPS, a software agent on the W-AT using one or more
rules may determine the need to query a large external database,
such as a geographic information service or a national census
database on a remote server, to determine a likely ethnicity (or
other demographics) of the user. If further information or
processing is required, control continues to step 712; otherwise,
control of the operation may jump to step 720 where profile
attributes are used to generate/modify the user's profile.
[0178] For instances where further information or processing is
required, a request may be made of an external device (step 712),
such as by the profile attribute processor discussed above
(optionally using hashing functions and/or proxy servers) to
protect user information.
[0179] Next, in step 714, the external device can perform any
number of refinement steps, such as query large databases, to
produce refined user profile attributes. Then, in step 718, refined
user profile attributes may then be provided to the appropriate
W-AT, where (in step 720) they may be used to generate, modify or
otherwise incorporated in a user profile. Note that when confidence
levels are available for processing, unified confidence levels may
be determined based on individual confidence levels. Control of the
operation may then jump back to the step 702 where new/more rules
may be received and used to collect data and modify the user's
profile.
[0180] Jumping forward to FIG. 11, a first communication protocol
for TCMs distribution in a M-TCM-enabled network is depicted. This
exemplary figure illustrates a possible data flow during a
multicast "push" of messages from a message distribution
infrastructure. Note that the User Profile Generation Agent (in the
Mobile Device (W-AT) 100 of FIG. 10) can retrieve messages, then
select one or more of the received the messages by internal
filtering.
[0181] In operation, a network system operator 280 (and/or a third
party) may provide profile attribute processing rules to the
profile attribute processor 270. The profile attribute processor
270 may also receive a profile attribute process request from
modules on the W-AT 100 and provide an appropriate response through
modules on the W-AT 100.
[0182] Additionally, multicast or broadcast advertisements may be
received by the W-AT 100 by a multicast/broadcast distribution
server 1110. In this configuration, the W-AT 100 (or other Mobile
Device) can be able to receive all messages and determine which
messages are to be stored and presented to the user in accordance
with the user profile generated at the W-AT 100 and the filter
rules also received from the multicast/broadcast distribution
server 1110 of FIG. 11.
[0183] FIG. 12 depicts a second communication protocol for message
distribution in a M-TCM-enabled network. As with the example of
FIG. 11, a network system operator 280 (and/or a third party) may
provide profile attribute processing rules to the profile attribute
processor 270, and the profile attribute processor 270 may also
receive a profile attribute process request from modules on the
W-AT 100 to provide an appropriate response through modules on the
W-AT 100.
[0184] However, in this embodiment unicast messages may be
requested by the W-AT 100 from the unicast message distribution
server 1210. The W-AT 100 may be able to receive all messages over
a unicast communication link and determine which messages are to be
stored and presented to the user in accordance with the user
profile generated at the W-AT 100 and the filter rules also
received from the unicast message distribution server 1210.
[0185] FIG. 13 depicts another communication protocol for message
distribution in a M-TCM-enabled network. Again, as with the
previous examples, a network system operator 280 (and/or a third
party) may provide profile attribute processing rules to the
profile attribute processor 270, and the profile attribute
processor 270 may also receive a profile attribute process request
from modules on the W-AT 100 to provide an appropriate response
through modules on the W-AT 100.
[0186] However, in this embodiment, the unicast messages
distribution server 1310 may receive user profile information
provided by the W-AT 100, process the received user profile
information, and then provide the appropriate TCMs to the W-AT
100.
[0187] FIG. 14 depicts yet another communication protocol for
message distribution in a M-TCM-enabled network. This example may
work much the same as the previous examples with respect to the
profile attribute processor side of operation. However, message
retrieval over the unicast communication link is substantially
different.
[0188] In operation, the W-AT 100 may send a request for messages
where after the W-AT 100 can receive a set of metadata
representative of the various messages available in the message
distribution server 1410. The W-AT 100 may then select a number of
messages based on the metadata and on the filtering rules within
the W-AT 100, and provide the selection information to the message
distribution server 1410. Accordingly, the selected messages can
then be provided to the W-AT 100 and presented to the user in
accordance with the user profile rules.
[0189] The above approach keeps the user profile local on the W-AT
while using optimal network bandwidth when delivering
advertisements to the W-AT over the unicast communication link.
[0190] FIG. 15 depicts a timeline for a first communication
protocol for downloading message content according to "contact
windows" (see exemplary windows 1510-1516) approach. This may be
used to permit downloading of TCMs at an opportune time without
burdening other functions of the W-AT. In various embodiments, the
W-AT may be able to adjust its sleep mode, if engaged, to the
contact windows. In operation, a W-AT can be put into a sleep mode
to optimize energy consumption on the platform during content
message delivery. It is possible that in a sleep mode, the W-AT may
be engaged in other useful operations. That is, a W-AT may be able
to be put into a sleep mode while various timing circuitry (not
shown) may be programmed or otherwise manipulated to respond to the
sleep mode and a contact window or other schedule by disengaging
the sleep mode before and/or during the contact window, and
possibly re-engaging sleep mode subsequent to receiving TCMs or at
the end of the relative contact window.
[0191] FIG. 16 depicts an alternate timeline for a first
communication protocol for downloading targeted-content-message
information according to a defined time schedule. Referring to
exemplary windows 1610-1620, this approach may be used to permit
downloading of TCMs at an opportune time without burdening other
functions of the W-AT. The defined time schedule permits the W-AT
to remain in sleep mode except during the defined time schedule.
Again, various timing/clock circuitry may be employed to engage and
disengage a W-AT to/from sleep mode. Additionally, it is possible
that when the W-AT wakes up to receive TCM information, it can
receive targeting meta-data and reception times for future TCMs,
which can then be used to determine whether to receive a future TCM
based on the user profile and the targeting meta-data, and to
schedule an appropriate wakeup time prior to the reception time for
a future TCM delivery.
[0192] FIG. 17 illustrates some of the cache modeling scenarios
based on exemplary information streams 1702, 1722 and 1732. As
shown in FIG. 17, the cache modeling scenarios are based on various
listed classifications. Note that a message cache can be a store
house for the messages at a M-TCM-enabled client. Messages may be
cached locally to enable immediate play-out of the messages when
there is an opportunity to serve a TCM.
[0193] The actual storage space in a cache may be divided into
multiple categories based on different types of classifications.
These classifications can be defined by System Operator using
filter rules. The amount of space allocated to each category within
a classification may be fixed or may be dynamic based on some
defined criterion, again defined through a filter rule by the
System Operator. Some categories of interest include:
[0194] Default messages (1710, 1720 and 1730): These may be thought
of as "fallback" messages that can be marked such by the System
Operator. They are shown when no other message satisfying the
message type requested by a device application is available for
display.
[0195] Default messages can be candidates for a cache as long as
there is at least one message delivery-capable application
subscribed with the respective client message delivery engine with
the same message type as the candidate default message. In
addition, default messages may be made to satisfy the minimum
gating criteria of device and application capability
compliance.
[0196] Based on the value calculated for a default message, a
previously stored default message may be replaced by a new one as
long as the "normalized" value of the new message is greater than
the value of previously stored default messages under the same
message type.
[0197] The maximum number of default messages allowed on a client
for each message type may be defined by the system operator through
a filtering rule. In various embodiments there may be a fixed
number of messages or message memory, or message number and/or
memory may be determined dynamically based on a particular message
capable application, usage, etc. Typically, in a number of
embodiments, the maximum number of default message allowed for each
message type is 1.
[0198] Messages that are marked as default messages primarily serve
two purposes: (1) they serve as "fallback" messages in each
category and help the system to take advantage of each opportunity
to present a message to a user; and (2) they allow a System
Operator to offer "tiered pricing" and (optionally) charge more for
default messages.
[0199] Targeted messages (1712, 1722, 1724 and 1738) and
non-targeted messages (1714, 1726 and 1740): One classification
scheme would be to divide a cache store into space for targeted and
non-targeted messages. The targeted message cache space can be used
to store only messages for which the user profile for the user of
the M-TCM-enabled client matches the target user profile contained
in the relevant metadata.
[0200] For messages where the target user profile does not match
the device user's profile, as long as the messages are not marked
as "targeted-display-only", such messages can be candidates to be
placed in the non-targeted message cache space. Having non-targeted
messages for display can allow a system to gauge change in user
interest with time, and modify the respective user profile and
cache accordingly.
[0201] Impression-based messages (1722) and action-based messages
(1724): Another classification would be to divide the targeted or
non-targeted portion of a cache space based on whether a message is
an impression type of TCM delivery campaign or the message is one
which solicits a user action to gauge user interest. Partition
sizes or ratios for such a sub-classification might be defined by a
System Operator or might be dynamically decided by the capabilities
and usage rate of message delivery capable applications onboard a
respective W-AT.
[0202] User Interest Based classification (1732-1736): A
sub-classification under the targeted message classification could
be based on a user interest classification. For example, most of a
particular cache space within a targeted message section of a cache
could be reserved for the top three user interest categories while
any remaining cache resources may be devoted to other categories
matching a user's profile. Again the actual ratios or number of
interest based categories within such a classification may be
defined by a System Operator and/or may be dynamic based on the
relative click-through rates for ads (or other messages) within
each interest category.
[0203] FIG. 18 is an illustration of a message filtering process
context. One purpose of a message filtering process within a mobile
targeted content message delivery system can be to decide which of
any available new messages entering the system should be cached at
a particular mobile client.
[0204] In operation, a filtering process 1810 may use a number of
inputs, such as a user profile of the user maintained within the
system, the device and application capabilities on the mobile
client, the current cache state on the mobile client and filtering
rules defined by a System Operator or some 3.sup.rd party 280 to
determine which new messages to cache. Upon processing each
received messages, a number of selected messages may be determined
and stored in cache 1820 along with the respective metadata.
[0205] FIG. 19 is a data flow diagram for a TCM filtering process
within a TCM delivery system in the context of various exemplary
functional components. As shown in FIG. 19, message filtering may
be a multi-step process. New messages entering a filtering agent
220 from sales interface 164 may first pass through a gating
sub-process 220-1 that may determine which received messages are
possible candidates for an message cache. Note that the exemplary
gating sub-process 220-1 may use device and capabilities
information from an appropriate storage device 1910 associated with
the mobile client, as well as filter rules by the System Operator
or some 3.sup.rd party 280 and user profile information from an
appropriate agent 210 or storage device.
[0206] Continuing, the possible candidates of the gating
sub-process 220-1 may then be processed by a selection sub-process
220-2 that may determine which candidate messages may be replaced
in case of message space contention. Note that the selection
sub-process 220-2 may use filter rules by the System Operator or
some 3.sup.rd party 280, user profile information from an
appropriate agent 210 or storage device and feedback cache
information from a cache manager 122.
[0207] FIG. 20 shows an exemplary data flow within the gating
process of FIG. 19. One purpose of this process is to ensure that
targeted content messages, such as targeted ads, meet certain
requirements before they are forwarded to a selection process. The
present process starts in step 2002 where messages and respective
metadata may be provided from a sales interface 164 or other
device. Next, in step 2004, a determination is made as to whether
the messages of step 2002 are within the capabilities of the mobile
client. That is, messages should be such that they can be supported
by the physical plant of a mobile device. For example, if a message
is meant only for the secondary device screen but the mobile device
at issue does not have one, the message is not suitable. Should the
message match device capabilities, control continues to step 2006;
otherwise, control jumps to step 2020 where the message is rejected
for use.
[0208] In step 2006, a determination is made as to whether the
messages of step 2002 are within the applications capabilities of
the mobile client. That is, messages should be such that they can
be supported by the various software/firmware registered for use
with the mobile device. For example, if a message includes a video
of 15 seconds but there is no CODEC facility within any of the
device applications to show such a video, the message not suitable.
Should the message match applications capabilities, control
continues to step 2008; otherwise, control jumps to step 2020 where
the message is rejected for use.
[0209] In step 2008, a determination is made as to whether the
messages of step 2002 pass a system operator specified gating
criteria match within the applications capabilities of the mobile
client. For example, if a message is suitable for adult audiences
only, such message would be likely best filtered out for any user
that is identified as a minor. Should the message match the
specified system operator specified gating criteria, control
continues to step 2010; otherwise, control jumps to step 2020 where
the message is rejected for use.
[0210] In step 2010, a determination is made as to whether the
messages of step 2002 pass a sampling criteria match. For example,
if a particular advertisement is slated to be provided to only 30%
of a demographic, a random number generator (RNG) having a range of
1 to 100 and seeded with its own ESN and a server specified seed
may qualify the advertisement if the resultant random number is
less than 30%. If the ad/message passes the sampling criteria,
control continues to step 2030 where message selection may be
performed; otherwise, control jumps to step 2020 where the message
is rejected for use.
[0211] FIG. 21 is a flowchart depicting a random sampling scheme,
which is presented for situations where an operator might want to
divide the users into mutually exclusive sets and target different
messages to each set. For example, the operator might be under
contractual obligation not to show any Pepsi ad and any Coke ad to
the same user. Accordingly, the operator might want to target the
Pepsi ad to 50% of the subscriber base and Coke ad to the remaining
50% of the subscriber base, making sure that both ads are not shown
to the same user.
[0212] The process starts in step 2102 where a random number
generator seed and ESN (electronic serial number) are provided to a
mobile client/W-AT. Next, in step 2104, a random number generation
process is performed to generate a random number between 1 and
100--or between any other range of numbers. Control continues to
step 2110.
[0213] In step 2110, a determination is made as to whether a match
is made between the random number of step 2104 and a defined range,
e.g., 1 to 50 or 51 to 100 out of a total range of 1 to 100. If a
match is made, then control jumps to step 2112 where the message at
issue is accepted, or if there are competing ads as with the
Coke/Pepsi example above, the first of two messages is accepted;
otherwise, control jumps to step 2114 where the message at issue is
rejected, or if there are competing ads as with the Coke/Pepsi
example above, the first of two ads is rejected while the second ad
is accepted.
[0214] Continuing to FIG. 22, it should be appreciated that
mutually exclusive message targeting within the subscriber base can
be done using a one-way function like a hashing scheme on some
unique ID, such as a user ID or device ID. In operation, an
operator can specify different target user segments based on the
result of the hashing calculations. Such a sampling might be done
to target a section of users defined by a range of the hash values
for their respective ESNs.
[0215] The process starts in step 2202 where unique ID is provided
to a mobile client/W-AT. Next, in step 2204, a one-way hashing
process may be performed to generate a value between any range of
numbers. Control continues to step 2210.
[0216] In step 2210, a determination is made as to whether a match
is made between the hashed value of step 2204 and a defined range.
If a match is made, then control jumps to step 2212 where the
message at issue is accepted, or if there are competing ads as with
the Coke/Pepsi example above, the first of two messages is
accepted; otherwise, control jumps to step 2214 where the message
at issue is rejected, or if there are competing ads as with the
Coke/Pepsi example above, the first of two ads is rejected while
the second ad is accepted.
[0217] Note that when a client's hash value does not fall in a
sampling range specified by the system operator, the message may be
rejected; otherwise, message processing may continue to the next
gating criteria or selection phase. Also note that an operator
might also choose a hybrid approach to sampling users for a
particular ad/message distribution campaign by targeting randomly
within mutually exclusive sets. As an example, a particular ad
campaign might be targeted to a random 20% of the subscriber base
that did not get a first ad. This would be achieved by first using
a one-way function based sampling to come up with a mutually
exclusive set and then to target randomly within the mutually
exclusive set.
[0218] Continuing, FIG. 23 shows an exemplary data flow within a
message selection process 2300. A purpose of the selection process
can be to select messages from a pool of messages that are
forwarded to a mobile client/W-AT by a gating process, and store
the selected messages in a memory, such as a special client
ad/message cache. In case of message space contention, the
selection process 2300 may also be employed to select previously
cached-messages that need to be replaced from the cache.
[0219] Message selection may come into play when there is
contention over cache space, i.e., there is not enough space in the
cache to accommodate all the new messages and the previously cached
messages. Message selection may be a multi-step process, and
because a cache may be divided into among different categories
(dynamically or statically), contention and selection may happen in
each message category.
[0220] In operation, a message selector 2310 may receive new
messages from a gating device 220 or other instrument performing a
gating process, as well as a number of message filter rules from a
system operator or 3.sup.rd party 280. The message selector 2310
may then apply the various filter rules to each new message to
determine whether each new message passes some basic criteria, such
as whether the new message is age or gender appropriate. Should a
particular message not comply with the filter rules, it may be
categorized as a rejected new message and discarded.
[0221] Messages not discarded under the filter rules may be further
processed by the message selector 2310 to derive a "target user
profile" for each received message to a match indicator calculator
2320, which may then compare the target user profile(s) to a user
profile provided by a user profile generation agent 210 or some
other device storing information on a user. In turn, the match
indicator calculator 2320 may perform a match between each target
user profile and the user profile associated with the user or
mobile client/W-AT, and provide a match indication "score" to the
message selector 2310 that quantizes how well a particular
incoming/new message is compatible with the user profile.
[0222] If the match indication "score" ranks well enough, the
respective message can be further considered; otherwise, it may
become a rejected new message.
[0223] Messages that are further processed by the message selector
2310 may provide the match indication "score", along with other
message value attributes, such as the message size, duration,
memory and display requirements and so on, to a message value
calculator 2330, which in turn can provide a "message value" for
such messages back to the message selector 2310.
[0224] Continuing, the message selector 2310 may receive
information from a cache manager 122 about the state of an
available cache (or portion of a cache devoted to a particular
message category), along with cache hit/miss information and the
message value for each message in the cache (or relevant portion).
Depending on the hit/miss information for a particular message, a
message value for a given message may optionally be adjusted.
[0225] The message selector 2310 may then determine whether a newly
received message is to replace one or more existing messages in the
cache based on relative message values, and any newly selected
messages may then be sent to the cache manager 122 along with the
respective message IDs and respective message values, and any
replaced messages may be discarded/rejected for further use.
[0226] FIGS. 24A and 24B depict a flowchart outlining a message
selection process for one or more new messages received at a mobile
device, such as a W-AT. The exemplary process flowchart shows the
high level flow of actions that take place during message selection
to determine which new messages to add to a cache and which
previously cached message are to be replaced/discarded.
[0227] The process starts in step 2400 where a determination is
made for a first new message whether the size of the message is
less than or equal to some maximum message size for a particular
cache memory and (optionally) for a particular message category,
e.g., movie trailers, baseball highlights, weather reports and
clothing sales. If the new message size conforms with the cache
memory requirements of step 2400, control jumps to step 2402;
otherwise, control continues to step 2408.
[0228] In step 2402, the new message is placed in cache memory.
Next, in step 2404, a message value for the new message is
calculated, and a "priority queue" for various messages in the
cache--and optionally for a message category of the cache--is
updated with the message value of the new message. Then, in step
2406, the available cache size is updated (again with an optional
updating for the particular message category) based on the new
message. Note that such message values may used to maintain a
priority queue for each category within the cache. Periodically (on
a pre-defined schedule), an engine may recalculate the various
message values in the cache and re-adjusts the priority queues
based on the new values. Such periodic updates to the value based
priority queues may result in lesser time being spent when new
messages are being considered as cache replacement candidates,
since the values in the queue are a good approximation of what the
current values would be. The process then continues to step 2430
(discussed below).
[0229] In step 2408, a message value for the new message is
calculated. Next, in step 2410, a determination is made as to
whether the new message is to be a default message. If the new
message is to be a default message, control jumps to step 2412;
otherwise, control continues to step 2420.
[0230] In step 2412, a determination is made as to whether the
value of the new message is greater than the value of a default
message of the same type already existing in the cache. New
messages marked as default messages and having value greater than
one or more of already stored messages can be given priority. The
additional size (if they are greater in size than the message(s) to
be replaced--of if the new message(s) are catering to a new message
type for which there are no previous default messages of such
category can be calculated since these messages can be accommodated
in the cache. Old default messages that are of lower value than the
new ones may be marked for replacement. Each message type may
typically have a fixed number (typically 1) of default candidates.
If the new message value is greater, control jumps to step 2414;
otherwise, control continues to step 2422.
[0231] In step 2414, the total size for all default messages is
updated, and in step 2424, existing cached message(s) to be
replaced are marked for deletion while the new message is marked
for addition to the cache. Note that based on how the cache is
divided or allocated to the various categories of messages, new
space allocations can be calculated for each category. Control
continues to step 2430.
[0232] In step 2422, the new message is marked for deletion, and
control continues to step 2430.
[0233] In step 2420, a new message value for each new non-default
message may be added to a respective priority queue for various
message categories, and control continues to step 2430.
[0234] In step 2430, a determination is made as to whether there
are any more message candidates to be considered. If more message
candidates are available, control jumps back to step 2440 where a
next message is selected for consideration, and then back up to
step 2400 where the next message is made available for processing;
otherwise, control continues to step 2450.
[0235] In step 2450, the available size for all new non-default
messages can be determined based on the difference between the
total cache size and the amount of memory taken up by default
messages. Next, in step 2452, the available memory for each
category of messages can be calculated based on some "category
ratio", parametric equation, or by some other set of rules and/or
equations. Control continues to step 2454.
[0236] In step 2454, various messages having the lowest associated
value can be marked for deletion for each message category in order
to conform with the available memory for each respective category
of messages. Next, in step 2456, those messages marked for deletion
can be removed from the cache, and their respective value entries
may also be removed from the respective priority queue. Then, in
step 2458, those new messages marked for deletion can be requested,
and their respective value entries may also be removed from the
respective priority queue. Control continues to step 2460.
[0237] In step 2460, those new messages not marked for deletion can
be added to the cache, and their respective value entries may be
retained in the respective priority queue. Control continues to
step 2470 where the process stops.
[0238] With respect to determining message values and message value
attributes, the following may be considered:
[0239] Message Value Attributes: Calculating a value for a message
may consider a number of attributes, based on the type of message.
While a number of these attributes may be defined by a server to
maintain centralized control over a message delivery scheme, e.g.,
an advertising campaign, across a message-enabled communication
system, some of the attributes that go into message value
calculation may be determined on the mobile client/W-AT based on
how the respective user interacts with the message.
[0240] Server Based Value Attributes:
[0241] Revenue indicator (RI): A value in the range of 1 to N
(e.g., 100) indicative of the revenue earned per serving/clicking
of the message/ad. Higher values indicate higher revenue.
[0242] Priority indicator (PI): A value in the range of 1 to M
(e.g., 10) indicative of the priority level the system operator has
scheduled for the message based on some measure of performance,
e.g., the effectiveness of an advertiser's ad campaign, over a
mobile message delivery system. This number may be increased by an
operator to increase the priority of a given message delivery
campaign.
[0243] Start and end time of message delivery campaign (T.sub.START
and T.sub.END): UTC time for the message delivery campaign viewing
start time and message campaign viewing end time. After the message
campaign viewing end time, the message can expire and may be no
longer shown within the mobile message delivery system. It also may
be removed from the respective cache at this time.
[0244] Overall system click-through rate (CTR): This is an optional
attribute included by a server to indicate the overall click
through rate of a message campaign across all clients with the
target user profile that were served the message within the mobile
message delivery system. CTR may be applicable only for user-action
or click based messages/ads. The CTR also may have a confidence
level (CTR.sub.CONFIDENCE) associated with it that is indicative of
the accuracy of the CTR. If CTR.sub.CONFIDENCE is below a certain
threshold, a random CTR in the range of 1 to P (e.g., 100) may be
generated to be alternatively used in the respective value
calculation. This can allow the system to test how a particular new
message/ad campaign would do with a subscriber segment.
[0245] Target message serve count (MAX.sub.SERVE): This is an
attribute that defines the maximum number of times the same message
can be shown to the same user.
[0246] Target user actions count (MAX.sub.USERACTION): This is an
attribute that defines the maximum number of times a user acts upon
a served message after which the message can be expired from the
respective cache. In various embodiments, this attribute may be
applicable only for user-action or click-based messages/ads.
[0247] Max message serve count per day (DAILYMAX.sub.SERVE): This
is an attribute that defines the maximum number of times the same
message can be shown to the same user within a single day.
[0248] Max user action count per day
(DAILYMAX.sub.USER.sub.--.sub.ACTION): This is an attribute that
defines the maximum number of times a user acts upon a served
message after which the message is not served to the user for that
day. In various embodiments, this attribute may be applicable only
for user-action or click-based messages/ads.
[0249] Client Based Value Attributes:
[0250] Cumulative message served count (CUM.sub.SERVE): The number
of times an existing message has already been served to a
particular user.
[0251] Cumulative user action count
(CUM.sub.USER.sub.--.sub.ACTION): The number of times an existing
message has invoked a user action. Together with the cumulative
message served count, the cumulative user action count can be used
to calculate a local client click-through rate (LCTR) for the
message. In various embodiments, this attribute may be applicable
only for user-action or click-based messages/ads.
[0252] Cumulative message served count per day
(DAILYCUM.sub.SERVE): The number of times an existing message has
already been served to the user in a given day. This value may be
reset to 0 at the beginning of each 24 hour period.
[0253] Cumulative user action count per day
(DAILYCUM.sub.USER.sub.--.sub.ACTION): The number of times an
existing message has invoked a user action in a given day. This
value can be reset to 0 at the beginning of each 24 hour period. In
various embodiments, this attribute may be applicable only for
user-action or click-based ads.
[0254] User Profile match indicator (MI): This number, typically
between 1 and 100, may be indicative of how well the target user
profile matches the user profile of the user of the mobile message
distribution enabled client.
[0255] Cache miss state match indicator
(FLAG.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI) There may be cases
where applications ask for messages from the cache manager but none
of the messages in the cache match the application gating criteria.
Such instances can be recorded by the cache manager. This attribute
determines whether the new message matches the most recent recorded
cache misses. It can be a logical "1" if it matches one of the
recent cache misses and a logical "0" otherwise. The flag can be
reset once the message is accessed by an application from the
cache. If the new message is selected for cache entry, the cache
miss entry can be removed from the list of recorded cache
misses.
[0256] Playback Probability Indicator (PPI): This number, between 0
to P (e.g., 100), can be indicative of the playback probability of
the message, based on the number applications subscribed with the
filtering agent capable of playing back the particular message
type, the relative usage of the applications by the device user,
and so on.
[0257] Since some of the value attributes are applicable for only
certain kind of messages, the value calculation can be different
for different categories of messages. A separate priority queue can
be maintained for each category based on the values calculated
using the formula for that particular category.
[0258] Message Value Calculation Formulae: The filter rules from
the System Operator may determine the value calculation formula for
each category and any weights that go into the calculation. An
exemplary generic representation of a formula used to calculate a
message value (V) in each category is:
V=(.PI..sub.a=1 to mMULT.sub.--ATTR.sub.a*(.SIGMA..sub.b=1 to
nADD.sub.--ATTR.sub.b/MAX_ADD.sub.--ATTR.sub.b*WT.sub.b))/(.SIGMA..sub.b=-
1 to nWT.sub.b*Size.sub.AD)
with the normalized message value being:
Normalized V=.SIGMA..sub.i-k to
NV*(MAX.sub.SERVEi-CUM.sub.SERVEi)*f(.tau.)
where MULT_ATTR.sub.a is the a.sup.th multiplicative value
attribute, ADD_ATTR.sub.b is the b.sup.th additive value attribute,
MAX_ADD_ATTR.sub.b is the max value for the b.sup.th additive value
attribute, WT.sub.b is the weight assigned to the b.sup.th additive
attribute in the formula, .tau.=t.sub.ELAPSEDi/T.sub.INTERVALi, and
f(.tau.) is a time-based value decay function, T.sub.INTERVALi is
the i.sup.th interval duration during which the message will be
shown, t.sub.ELAPSEDi is the time that has already elapsed in the
i.sup.th interval, MAX.sub.SERVEi is the maximum number of times
the same message can be shown to the same user within the i.sup.th
interval, and CUM.sub.SERVEi is the number of times an existing
message has already been served to the user within the i.sup.th
interval.
[0259] Following are some examples of value calculation formulae
for different categories.
[0260] Value calculation for impression based targeted
messages:
VAL=(PI/10*[(RI/100*WT.sub.RI)+(MI/100*WT.sub.MI)+(FLAG.sub.CACHE.sub.---
.sub.MISS.sub.--.sub.MI*WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI)+(PPI/1-
00*WT.sub.PPI)])/((WT.sub.RI+WT.sub.MI+WT.sub.CACHE.sub.--.sub.MISS.sub.---
.sub.MI+WT.sub.PPI)*Size.sub.MSG)
[0261] Value calculation for impression based non-targeted
messages:
VAL=(PI/10*[(RI/100*WT.sub.RI)+(FLAG.sub.CACHE.sub.--.sub.MISS.sub.--.su-
b.MI*WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI)+(PPI/100*WT.sub.PPI)])/((-
WT.sub.RI+WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI+WT.sub.PPI)*Size.sub.-
AD)
[0262] Value calculation for user-action based targeted
messages:
VAL=(PI/10*[(RI/100*WT.sub.RI)+(MI/100*WT.sub.MI)+(FLAG.sub.CACHE.sub.---
.sub.MISS.sub.--.sub.MI*WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI)+(PPI/1-
00*WT.sub.PPI)+(CTR*WT.sub.CTR)+(LCTR*WT.sub.LCTR)])/((WT.sub.RI+WT.sub.MI-
+WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI+WT.sub.CTR+WT.sub.LCTR+WT.sub.-
PPI)*Size.sub.MSG)
[0263] Value calculation for user-action based non-targeted
messages:
VAL=(PI/10*[(RI/100*WT.sub.RI)+(FLAG.sub.CACHE.sub.--.sub.MISS.sub.--.su-
b.MI*WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI)+(PPI/100*WT.sub.PPI)+(CTR-
*WT.sub.CTR)+(LCTR*WT.sub.LCTR)])/(WT.sub.RI+WT.sub.CACHE.sub.--.sub.MISS.-
sub.--.sub.MI+WT.sub.CTR+WT.sub.LCTR+WT.sub.PPI)*Size.sub.MSG)
where RI is the revenue indicator value on a scale of 1 to 100, PI
is the priority indicator value on a scale of 1 to 10, CTR is the
click-through rate for the message within the system for the given
user profile, LCTR is the click-through rate for the message for
the specific client, MI is the match indicator between the target
user profile and the user's profile on a scale of 1 to 100,
FLAG.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI is the match indicator
between the message type and the cache miss state with a value of
either 0 or 1, PPI is the message playback probability indicator on
a scale of 1 to 100, WT.sub.RI is the weight for the revenue
indicator in the calculation, WT.sub.MI is the weight for the match
indicator in the calculation,
WT.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI is the weight for the
cache miss state match flag in the calculation, WT.sub.CTR is the
weight for the user profile specific system click-through rate in
the calculation, WT.sub.LCTR is the weight for the client specific
click-through rate for the message in the calculation, and
WT.sub.PPI is the weight for the message playback probability
indicator in the value calculation.
[0264] Examples for f(.tau.):
[0265] Linear decay: f(.tau.)=(1-.tau.)*u(1-.tau.)
[0266] Faster exponential decay bounded by linear decay:
f(.tau.)=(1-.tau.)e.sup.-.lamda.t*u(1-.tau.) noting that when
.lamda.=0 linear decay occurs; when .tau.=0, f(.tau.)=1; and when
.tau.=1, f (.tau.)=0.
[0267] Slower sigmoid decay bounded by linear decay:
f(.tau.)=(1-.tau.)[(1+{acute over (.alpha.)})/(1+{acute over
(.alpha.)}e.sup..lamda..tau.)]*u(1-.tau.) noting that when
.lamda.=0 linear decay occurs; when .tau.=0, f(.tau.)=1; and when
.tau.=1, f(.tau.)=0, and further noting that u(x)=1 when x>0;
and u(x)=0 when x<=0. Also, .lamda. and {acute over (.alpha.)}
are value decay rate constants specified by the system operator
based on time
[0268] Message Match Indicator Calculation: As briefly alluded
above, the User Profile Match Indicator (MI) may be a number, and
not necessarily between 0 and 100, which is indicative of how well
the target user profile matches the user profile of the user of the
Mobile Message Delivery Enabled Client and either his past
message/advertisement viewing history or some metric of the his
message/advertisement preference(s). Though the MI can be described
as a scalar numerical quantity, it should be appreciated that one
or more alternative "weighting" schemes can be devised, for
example, using a polynomial function or vectors, according to
design preference. Thus, other values (scalar or non-scalar, single
valued or multi-valued, for example) can be assigned without
departing from the spirit and scope of this disclosure.
[0269] For illustrative purposes, several implementations of a
advertisement match indication calculation is described, using a
scale quantity between 0 and 100, since this is one of the simplest
ranges that can be given. Other ranges may used as desired. One
such implementation utilizes fuzzy logic which can be used to
generate confidence level values for each of the independent target
rule groups specified by the advertiser. From these confidence
levels, a weighted summation of these confidence levels can be used
to arrive at the match indicator value for the advertisement to the
user's profile. The following, non-limiting equation, may be used
as an example of one type of fuzzy logic,
MI=(.SIGMA..sub.b=1 to nCONF_LEVEL.sub.b*WT.sub.b)/(.SIGMA..sub.b=1
to nWT.sub.b)
[0270] where the overall match indicator for the message to the
user's profile (MI) is related to the sum of confidence levels
(CONF_LEVEL) times a weight (WT) corresponding to an attribute
value (b) divided by the sum of the weight (WT) corresponding to
the b.sup.th additive attribute.
[0271] As an example of confidence level calculation, presume an
advertiser who desires to target his advertisement(s) towards
females, to females who are in the age range of 15-24 and with an
income above 40K, or who are in the age range of 25-34 and with an
income greater than 70K. Knowing the values of the user profile
elements of interest and presuming the associated confidence levels
are:
TABLE-US-00001 User Profile Element Value Confidence Female 50%
Age: 15-24 40% Age: 25-34 35% Income: >40K 65% Income: >70K
45%
[0272] The confidence level for the rule groups are: Female=50%
[0273] For the composite rule group of age 15-24 and with income
above 40K, or age 25-34 and with income greater than 70K, a
maximum/minimum approach can be used. For example, taking the
maximum value of the minimum of the two groupings (e.g., MAX (MIN
(40, 65), MIN (35, 45)) results in MAX (40, 35), which is a 40%
confidence level for this grouping.
[0274] The overall MI for the entire rule groups would be the
combination of the "female" confidence level 50% and the composite
confidence level 40%, factored by the associated WT.sub.b and
divided by the sum of the associated WT.sub.b's. As stated above,
other forms of fuzzy logic may be used without departing from the
spirit and scope of this invention.
[0275] While this demonstrates one approach to determining the User
Profile Match Indicator value, other approaches such as statistical
averaging, curve fitting, regression analysis, and so forth may be
used to arrive at a reasoned indication of the match between the
advertisement's target profile and the user's profile. Though the
above approaches are understood to be primarily scalar approaches,
non-scalar approaches using vector representations (e.g.,
dot-product), artificial neural net topologies, etc. may be
used.
[0276] For example, the confidence levels each attribute for an
individual rule group may be represented by an n-dimensional
vector. The n-dimensional vector may be a dot-product with other
m-dimensional individual groups, if necessary (for example, if the
different individual rule groups are separately vectorized), to
result in an overall intersection or projection of the advertising
rule group confidence. This value can then be scalar manipulated or
"dot-product ed" (depending on the projection space) with a
mathematical representation of the user's profile, to generate a
match indication confidence level.
[0277] Other match-type algorithms such as a bubble or hierarchal
approach may be used. Of course, it should be understood that
various forms of these and other approaches may be used, if so
desired to arrive at a more precise and/or efficient determination
of the advertisement match. Match algorithms may be resident on the
mobile message delivery system or on the mobile message delivery
enabled client, if so desired. Additionally, depending on a chosen
configuration and resources, portions of these algorithms may be
parsed between the message delivery system or the message delivery
enabled client.
[0278] FIG. 25 is a flow chart illustrating an exemplary User
Profile Match Indicator (MI) process 2500 according to an
embodiment of this invention. The exemplary process 2500 embodies
any one or more of the algorithms/schemes discussed above. The
exemplary process 2500 is initiated at step 2510, and continues to
step 2520 whereupon message target parameters, e.g., an
advertiser's advertisement target parameters, are compiled or
characterized.
[0279] Next, in step 2530, the exemplary process can proceeds to
generating a metric or mathematical representation of the target
parameters. In various embodiments, this step may simply entail a
conversion of the parameter characteristics into a manageable
number, such as a scalar value having a range between 0 to 100. Of
course, any range, whether positive and/or negative may be used,
depending on design preference. Step 2530 can enable an
advertisement's target parameters to be represented by a
mathematical expression or value. For example, if an advertiser
desires to target all females and is not privy to the
female-to-male subscriber ratio, then his request would be
converted according to the provider's subscriber population
breakdown. That is, presuming a 1:1 female-to-male ratio in the
provider's subscriber population, this would be a value of 50% or
0.50. Alternately, if the respective subscriber gender ratio for a
particular provider is 1:2, then this would translate to an
approximate 33.3% subscriber population, or an approximate value of
0.333.
[0280] It should be understood that other manipulations may be
performed on the target parameters, such as a conversion to a
vector or a parameterized expression. Also, depending on the
initial format in which that the target parameters are presented,
step 2530 may simply consists of forwarding the parameters to the
next step with little or no manipulation. That is, target
parameters may already be in a form amenable for processing by the
subsequent steps and may not necessitate any conversion. Control
continues to step 2540.
[0281] In step 2540, an optional conditioning or transformation of
the formulated mathematical expression or metric may take place.
For example, depending on the complexity of a message's target
parameters and the definition space allocated to the message's
target parameters, further processing and manipulation may need to
be performed. For example, a correlation between different
advertisement target parameters may be performed. For instance, if
an advertiser desires a female target profile having an age range
of between 18-24 years within a particular area code who are new
subscribers, confidence levels or other types of mathematical
inferences can be made, to provide a simpler or more efficient
representation of the entire advertisement target parameter set. It
should be appreciated that other forms of correlation or
manipulation may be used as deemed appropriate. Additionally, based
on the processing capabilities of the mobile client and/or other
practical considerations, it may be desired to refine the metric or
reduce the complexity of the metric for more effective or more
efficient matching. Control continues to step 2540.
[0282] In step 2550, a message match algorithm may be performed to
determine a match metric or suitability of fit for the message
target profile to the user profile. It should be apparent that this
process may use any one of several possible matching algorithms
described herein or known in the arts. Non-limiting examples are
fuzzy logic, statistical methods, neural nets, bubble, hierarchal,
and so forth. Next, in step 2560, an overall user match indication
value, overall confidence level or other metric of indicating the
level of suitability of the message to the user's profile can be
generated. Upon a determination of the user match profile
indication, which may, for example, simply be a scalar number or a
"yes" or "no" value, control continues to step 2570 where the
process is terminated.
[0283] Based on the above exemplary process 2500, advertisements
and other messages designated for target populations can be matched
with a user's profile to determine the suitability of the
message/advertisement to the user's profile. Thus, if a high or
acceptable match indication is given, the message/advertisement can
be forwarded to the user in the expectation that the user will
respond favorably to the message, or as per arrangements made with
the user. Accordingly, advertisements/messages that are "tailored"
to the user can be efficiently disseminated to the user.
[0284] FIG. 26 is a block diagram illustrating an exemplary user
profile match indicator 2600, according to an embodiment of this
invention. The exemplary user profile match indicator 2600 includes
a target profile generator 2610, an advertisement server 2620, a
user profile generator 2630, a profile-to-profile comparer 2640,
and a storage system 2660.
[0285] In operation, the comparer 2640 may be housed in a user
system (not shown) and can compare information forwarded by the
target profile generator 2610 against information forwarded by the
user profile generator 2630. The target profile generator 2610 may
forward attributes related to the advertisements provided by the
advertising server 2620, wherein the information/attributes can be
compared to the information/attributes of the user's profile, as
provided by the user profile generator 2630. Based on algorithms
contained in the comparer 2640, a match indication can be
formulated designating the level of suitability or confidence level
of the target profile to the user profile. Based on the match
indication, advertisements and/or information from the
advertisement server that are consistent with the attributes of the
target profile may be forwarded to storage system 2660. The storage
system 2660 may be resident on the user system. Accordingly,
"tailored" advertisements and/or information may be forwarded to a
user without compromising the privacy of the user's profile.
[0286] Keyword Correlation based on past viewing history: One of
the potential inputs in a match indicator calculation described
above may be a correlation value derived between the previous
messages viewed, i.e. a "viewing history" of the user and new
messages. In this context, or messages may be associated with
keywords from a dictionary at the advertisement sales interface,
according to design preference. With respect to FIG. 27, a process
is described that describes an exemplary generation and use of
keyword associated message delivery.
[0287] The process starts in step 2710 and continues to step 2720
where keywords can be assigned to various messages. For example, an
advertisement directed to women's apparel may have four keywords
including "fashion", "female", "clothing" and "expensive". The
keyword(s) may be broadly associated with a genre of
advertisements/messages or may be individually associated with a
particular species of advertisement(s)/message(s). Thus, depending
on the level of resolution or discrimination desired, more than one
keyword may be associated with a particular advertisement/message
or vice versus. In various embodiments, keywords may be limited to
an advertisement/message dictionary or index.
[0288] Continuing, such keywords can be given weights (e.g., a
number between 0 and 1) to help describe the strength of
association between a particular message and the meaning of the
keyword. If keywords are determined to not have an associated or
impressed weight, their weights can be assumed to be 1/n where n is
the total number of keywords associated with a message. In this
manner, a gross averaging weight can be applied by the 1/n factor,
in some sense to normalize the overall keyword values to within a
desired range.
[0289] Assigned weights can provide some degree of normalization,
especially in the context of multiple keywords (for example, 1/n,
given n keywords, with each keyword having a maximum value of 1),
or can be used to "value" the keyword or the advertisement/message
according a predetermined threshold or estimation. For example,
some keywords may have a higher or lower relevance depending on
current events or some other factor. Thus, emphasis or de-emphasis
can be imposed on these particular keywords via the weighting, as
deemed appropriate. Step 2720 is presumed to have the measure of
assigning a weight to the keyword as part of the keyword
association for a fixed keyword value estimation. However, in some
instances a weight may not have been pre-assigned or the weight
valuation is undetermined. In those instances, an arbitrary value
can be assigned to the keyword, for example, a weight of 1. It is
presumed that these keywords are forwarded to a mobile client.
Control continues to step 2730.
[0290] In step 2730, user response to messages may be monitored. In
operation, messages can be presented to users whereupon the users
may choose to "click" on them or not. As should be apparent in this
technology, the term "click" can be assumed to mean any form of
user response to the presence of the message or as part of an
operational message sequence. In some user embodiments, a lack of
response may be construed as an affirmative non-click or click-away
response, analogous in some contexts to a de-selection. Thus, a
mobile client user's response to various advertisements/messages
can be historically gauged.
[0291] By monitoring the user's "click" response in relation to a
general population or even a targeted population of
advertisements/messages, an initial assessment of the user's
interests can be obtained.
[0292] In various embodiments, a user's response time for a given
advertisement/message or a series of advertisements/messages can
also be used to gauge the user's interest therein. For example, a
user may click through several advertisements/messages, each having
different degrees of relevance or keywords, and the rate of click
through or tunneling can be understood to be indicative of user
interest. Control continues to step 2740.
[0293] In step 2740, a comparison of the user selection (for
example, click) of a particular advertisement/message and its
corresponding keyword(s) can be performed to establish at least a
"baseline" correlation metric. Again, it may be noted that the
selection of and/or rate of selection can be used in determining
the user's interest in a keyword-associated advertisement/message.
By this comparison, a correlation between the various keyword and
the user's advertisement/message preference may be provided. This
correlation can be accomplished using any one of several methods,
such as, for example, statistical methods, fuzzy logic, neural
techniques, vector mapping, principal components analysis, and so
forth. From step 2740, a correlation metric of the user's response
to an advertisement/message can be generated.
[0294] In various exemplary embodiments, a "keyword correlation
engine" embedded on a message delivery system and/or W-AT may track
the total number of times a particular message/advertisement may
presented (or forwarded) to a user with a particular keyword (for
example, N_total-keyword) along with the total number of clicks for
that keyword (for example, N_click-keyword). The ratio of
N_click-keyword/N_total-keyword may be computed to determine the
correlation of the keyword to the user's response. The weight for a
keyword for a message may be assumed to be 1 if the keyword is
specified without an associated weight for a given message. By
formulating a ratio as described above, a metric for gauging the
reaction or interest of the user to a keyword tagged advertisement
can be generated, and refinements or improvements to the match can
be devised accordingly. In the above example, affirmative clicks
can be used to indicate a user's interest. However, again it should
also be appreciated that in some embodiments, a non-click or lack
of direct response also may be used to infer an interest level or
match relevance.
[0295] As an illustration of one exemplary implementation, assume
that there are N keywords for a given advertisement(s). An
N-dimensional vector A can be created based on the associated
keyword weights. An N-dimensional correlation vector B can be
created with the correlation measure of each keyword for the
advertisement(s) to the user in each dimension. A scalar
correlation measure C, to establish the correlation of the
advertisement to the user, can then be created which is a function
of the vectors A and B. The correlation measure C may be, in some
embodiments, simply a dot product of the vectors A and B (C=AB as
C=(1/N)AB). This scalar correlation measure C offers a very simple
and direct measure of how well the advertisement is targeted to the
specific user based on his previous advertisement viewing history.
Of course, other methods may be used to correlate the A-to-B
correspondence, such as parameterization, non-scalar
transformations, and so forth.
[0296] The above approach assumes that the keyword dictionary has
keywords that are independent of each other. Should the keywords be
inter-related, fuzzy logic can be used to come up with a combined
weight for the set of inter-related keywords. Other forms of logic
or correlation can be implemented, such as polynomial fitting,
vector space analysis, principal components analysis, statistical
matching, artificial neural nets, and so forth. Therefore, the
exemplary embodiments described herein may use any form of matching
or keyword-to-user correlation algorithm as deemed necessary.
Control continues to step 2750.
[0297] In step 2750, the mobile client or user may receive "target
keyword(s)" associated with various prospective targeted
messages/advertisements. Next, in step 2760, the received target
keyword(s) may be evaluated to determine if there is a match or if
the keyword(s) meet an acceptable threshold. In various
embodiments, a matching evaluation can involve higher algorithms,
such as statistical methods, fuzzy logic, neural techniques, vector
mapping, principal components analysis, and so forth, if so
desired. It should be appreciated that the correlation process of
step 2740 and the matching process of step 2760 may be
complementary. That is, different algorithms may be used with the
respect processes, depending on design preference or depending on
the type of advertisement/message keyword forwarded. Control
continues to step 2770.
[0298] In step 2770, those targeted messages deemed to match within
a threshold of acceptance may be forward and/or displayed to the
user. The forwarding of the advertisement/message may take any one
of several forms, one such form, for example, being simply
permitting the matching advertisement/message to be received and
viewed by the user's device. In some embodiments, a non-match
advertisement/message may be forwarded to the user, but is disabled
so as to prevent instantiation or viewing. Thus, in the event that
the user's preferences or profile is subsequently modified, a prior
non-acceptable advertisement/message but now acceptable
advertisement/message may be resident on the user's device and
appropriately viewed. Of course, other schemes for making available
advertisements/messages that are deemed to be "matching" or
"non-matching" may be devised without departing from the spirit and
scope of this invention. After step 2770, the exemplary process
2700 proceeds to step 2780 where the process is terminated.
[0299] By use of the above exemplary process 2700, targeted
advertising/messages can be filtered to be apropos to the user's
interests. The user's interests can be initially established by
historically monitoring the user's "click" response on the user's
mobile client against a set of advertisements/messages via keyword
assignment and matching. Dynamic monitoring can then also be
accomplished by updating the user's interest profile, based on
currently observed user response(s). Accordingly, a more direct or
more efficient dissemination of targeted advertisements/messages
can be obtained, resulting in a more satisfying mobile client
experience.
[0300] Continuing, note that a significant amount of information
can flow through a mobile device associated with a user during the
lifetime of the device. The user may interact with some fraction of
the information that is presented to it. Due to memory constraints,
it may be impossible to store all such information on the mobile
device itself. It may not even be feasible to store all the
meta-data and the user responses associated with all such
information flowing through the device as well. Thus, it may be
desirable to create a user model that captures user preferences
based on user behavior, so that relevant content/information can be
presented to the user, without having to store all past information
related to the user.
[0301] Accordingly, as shown in FIG. 28, it may be desirable to
create a "keyword learning engine" 2810 capable of capturing user
preferences and presented information. Along with the keyword
learning engine, it may be desirable to have a "keyword prediction
engine" 2820 based on a learned model, to suggest the likelihood of
user interest for new information that is presented to the user.
This could help in filtering new content as it arrives on a mobile
device, so that relevant information can be presented to the
user.
[0302] In operation, meta-data associated with information arriving
at a mobile device can be used in the learning and prediction
engines 2810 and 2820. Any user responses associated with presented
information can be also used in the learning engine 2820. During
operation, the learning engine 2810 may use all past information,
e.g., meta-data and the user behavior associated with the
respective presented information. Based on the input, the learn
engine 2810 can refine such input to provide a learned user
preference model. This user preference model may then be used in a
prediction engine, which can receive meta-data related to new
information, then correlate the meta-data with the user preference
model to provide a predicted user match indicator/indication for
the new information. This user match indicator/indication can then
be used to determine whether or not the information is presented to
the user.
[0303] It is to be appreciated that user preferences can be
contextual with respect to the activity that is being learned. For
example, a user may have different preferences with regard to
advertisements that the user would like to see, and a different set
of preferences with regard to web pages that the user would like to
browse. For example, a user may read news on the web about crime in
the local community news to be aware of such activity from a safety
standpoint; however, that should not imply that the user would be
interested in purchasing a gun through an advertisement. Therefore
a message presentation engine on the platform could reflect
different user preferences relative to the web browser preferences
of the user. Other contexts could include user preferences related
to a music application on the platform or a sports application on
the platform. In general, learning and prediction engines may be
required for every context.
[0304] In this document, an exemplary architecture and algorithm
for learning and prediction for a given context, such as processing
targeted-content-messages/advertisements, is provided. The
suggested architecture and algorithms can be applied to different
contexts without loss of generality.
[0305] One task at issue is to learn user preferences from a user's
phone usage habits in the given context, such as learning their
likes and dislikes from their response to targeted-content-messages
(such as an advertisements) that are presented to the user. The
goal is to provide a solution with a learning algorithm that is
fast and that does not scale with amount of data presented.
[0306] Additionally, based on a model that is learned by the
system, when a new message/information arrives at a mobile device,
the available prediction engine may present a match indicator for
the information relative to the learned preferences of the given
user. This match indicator can be used along with other system
constraints (such as revenue or size information optionally) to
take a decision on whether to present the information real-time to
the user, or to take a decision on whether to store the information
on the user's mobile device such as in a space-constrained
targeted-content-message cache on the mobile device.
[0307] An exemplary architectural flow is depicted in FIG. 29. As
shown in FIG. 29, a message server 2620 may deliver a single
message, such as a Starbucks coffee ad, to a user's mobile device
100 in real-time when the user 2990 is either walking past or
driving past a Starbucks store. Based on the prediction model, it
may be useful for the mobile device 100 to take a decision on
whether to present this message to the user 2990 based on a match
indicator value that is generated related to this information.
[0308] Alternatively, a stream of meta-data information related to
various messages may arrive at the mobile device 100, and a
resident prediction algorithm may provide the relative values of
match indicators for each message, so that the mobile device 100
may take a decision on which messages to store in a
space-constrained cache 240 on the mobile device 100.
[0309] A selection function on the mobile device 100 may optionally
use additional indictors, such as associated revenue (message value
calculation criteria) and size (gating and/or message value
calculation criteria), in addition to a match indicator calculation
using commands and information from the prediction engine 2820 to
take a decision on whether to present a given message to the user
2990.
[0310] With regard to the learning engine 2810, for information
that is presented to the user 2990, if there is a user response
associated with the presented information, then both the meta-data
associated with the user information and the user response may used
by the learning engine 2810 to generate a learned user preference
model. In addition, for the mobile device 100 of FIG. 29 individual
actions on a per-message basis may or may not be stored in the
mobile device 100. That is, user actions, along with meta-data for
a given message may be used to refine the learned user preference
model and subsequently the inputs related to the user action and
the ad-meta-data are discarded from the system.
[0311] In various embodiments and as discussed above, it can be
useful to generate and use a keyword dictionary that describes
different possible preferences of a user for a given context. In
operation, the creator of a targeted-content-message may specify
those keywords that are relevant to a targeted-content-message in
the meta-data for a targeted-content-message. When the meta-data
associated with the targeted-content-message is presented to the
user 2990, the learning engine 2810 may update the user's
preferences related to the keywords based on the response of the
user 2990 to the information. Additionally, when the meta-data
(including the keywords associated with the
targeted-content-message) is presented to the mobile device 100,
the prediction engine 2820 may compute the match indicator for the
user that can be used to determine whether or not to present the
targeted-content-message to the user 2990.
[0312] In practical operation, one can assume that a keyword
dictionary is a flat representation for the purpose of learning.
Note that a keyword dictionary that is exposed to the
targeted-content-message provider may either be flat or
hierarchical in nature.
[0313] In a hierarchical representation, nodes at a higher-level in
the keyword tree may represent coarse-grain preference categories
such as sports, music, movies or restaurants. Nodes lower in the
keyword tree hierarchy may be specify finer-grain preferences of
the user such as music sub-categories rock, country-music, pop,
rap, etc.
[0314] While a given keyword dictionary may be hierarchical, the
keyword tree may be flattened starting with the bottom of the tree
for the purpose of learning. For example a music node in the tree
with four children {rock, country-music, pop, and rap} can be
flattened to a five node representation with music (general) and
the 4 sub-categories. If there are L leaves for a parent node, then
the flattened representation translates to (1+L) leaves for the
root of the parent node in the keyword hierarchy. Thus, the
flattening of the tree can be recursively accomplished starting
with the leaves of the tree all the way to the top of the hierarchy
such that all intermediate nodes of the tree are connected directly
to the root of the tree. For example a quad-tree representation
with k levels would consist of a root node along with
4+4.sup.2+4.sup.3+4.sup.(k-1) nodes. Flattening such a tree would
result in a keyword dictionary tree consisting of
4+4.sup.2+4.sup.3+ . . .
+4.sup.(k-1)=(4.sup.k-1)/(4-1)-1=4/3*(4.sup.(k-1)-1) nodes directly
connected to the root node. Note that K=1 would correspond to 0
keywords, K=2 would correspond to 4 keywords, K=3 would correspond
to 20 keywords, etc.
[0315] FIGS. 30A and 30B depict an exemplary flattening process at
an intermediate parent node in the tree for a hierarchical
representation. The learning and prediction algorithms may work on
a weighted summation metric which effectively results in learning
based on a flattened version of a hierarchical tree, if the
decision making is done at the top of the tree.
[0316] Continuing, techniques for learning and prediction engines
on mobile devices are presented. For notation purposes, let there
be n keywords, each corresponding to a preference one may want to
capture with regard to a user. One may abstractly represent a
user's preferences as a vector P=(p.sub.1, . . . , p.sub.n), where
the value p.sub.i corresponds to the user's preference level for
the category i. Similarly, one can abstractly represent a message
based on its relevance to the keywords as a vector A=(a.sub.1, . .
. , a.sub.n), where the value a.sub.i corresponds to how relevant
the message is to the keyword i. One may assume that messages are
presented sequentially to the learning algorithm.
[0317] It should be noted that typically a large number (possibly
several hundreds) of keywords may be used, though most of them
would be irrelevant to a particular message. It may be expected
that users will have strong preferences on only a few keywords.
Mathematically such vectors are called "sparse vectors". One can
assume that input training message keyword vectors are sparse. One
may also assume that the desired user preference vector P is also
sparse. The current estimated guess of the user's preferences based
on the user model can represented as {circumflex over (P)}.
[0318] The algorithms for the learning and prediction engines are
described below.
[0319] Learning Engine:
[0320] Input: Message (represented as a vector): A [0321] User
response: `click occurred`
[0322] Persistent: Current guess of user preferences (as a vector):
P (initially 0)
[0323] Decay parameter: D
[0324] Counter: C (initially 0)
.alpha. := { 1 C if C .ltoreq. D 1 D otherwise Eq . ( 1 ) P ^ := (
1 - .alpha. ) P ^ + .alpha. A Eq . ( 2 ) C := C + 1 Eq . ( 3 )
##EQU00001##
[0325] The estimate {circumflex over (P)} may start at initial
value 0. However, in the presence of available information, one can
opt to use a different starting seed. For instance, knowing the
local demographics can help to seed the profile of a new mobile
user to some average or amalgam. If a seed vector S is available,
the initial value of {circumflex over (P)} may be set equal to the
seed S with no changes to other steps.
[0326] Additionally it is possible that one may use a constant
decay parameter .alpha., in which case .alpha.:=1/D in Eq (2) where
D is a constant.
[0327] Prediction Engine:
[0328] Input: Message (represented as a vector): A [0329] Current
guess of user preferences (as a vector): {circumflex over (P)}
[0330] Return: {circumflex over (P)}A
[0331] In operation, one may provide the following operational
guarantees:
[0332] (1) If the messages and user preferences are sparse, then
the learning engine can quickly learn the user preferences from
user responses, e.g., the user's "clicking behavior". That is, the
rate of learning can be proportional to the sparseness of the
messages and/or user preferences
[0333] (2) The learning engine is robust to high noise. That is,
even if user clicks on a large number of irrelevant messages, as
long as she is clicking on a small percentage of relevant messages,
a learning engine should be able to learn the underlying
preferences.
[0334] (3) If the underlying user preferences change over time,
then the learning engine can adapt to the new preferences well.
[0335] Besides information-space sparseness, note that the rate of
learning for the user selection rates can be determined based on
rate of presentation of information, value of an initial seed, and
aspects of a user profile.
[0336] Results from a Matlab simulation for a possible keyword
learning scenario are provided in FIG. 31, which depicts a modeled
learning engine in action with the horizontal axes representing the
different keywords (total 500), and the vertical axes represents
the strength of an individual's preference--positive implies user
like, negative implies dislike. The top graph 3102 shows the
underlying user preferences, while the subsequent four graphs
3104-3110 show the algorithm's best guess after receiving 50, 100,
500 and 1000 messages respectively.
[0337] For the simulation represented in FIG. 31, a sparse vector
is randomly chosen to represent the underlying preference vector.
As messages are randomly selected, the user's behavior can be
simulated as follows: The user clicks on a truly relevant message
about 25% of the time and rest 75% of the time the user clicks on
an irrelevant message. The decay parameter D is set to 3000.
Information regarding which messages were clicked is passed to a
learning engine. It should be noted that for the simulation of the
present example, the learning engine is not given any information
about whether each message is truly relevant to the user.
[0338] In view of FIG. 31, it is apparent that a keyword-based user
preference representation for individual learning contexts can be
desirable and useful on a mobile platform. It should be appreciated
that the example of FIG. 31 may be improved by a number of classic
adaptive techniques. For example, it may be useful to introduce
small degrees of randomness to the prediction model to refine the
user's model by further exploring the user's interests in effect
performing an "annealing" process characteristic of classic neural
network learning.
[0339] Additionally, the central learning/adaptive algorithm of Eq.
(2) may be modified by varying the decay parameter over time or
based on the type of user response (e.g., strong positive, weak
positive, neutral, weak negative, strong negative). A strong
positive response may contribute positively (A/D(t)) to the
estimate {circumflex over (P)} (step 6 in the learning engine).
However, if a user displays some form of strong negative behavior
to certain information, then the response may contribute negatively
(-A/D(t)) to the estimate {circumflex over (P)}. If the user
displays some form of weak positive response, then the response may
contribute fractionally (.alpha. A/D(t)) to the estimate
{circumflex over (P)} where 0.ltoreq..alpha..ltoreq.1. Similarly, a
weak negative response may contribute negatively and fractionally
(-.alpha.A/D(t)) to the estimate {circumflex over (P)} where
0.ltoreq..alpha..ltoreq.1.
[0340] Alternatively, the central learning/adaptive algorithm of
Eq. (2) may be modified by imposing estimate {circumflex over (P)}
limits, i.e., ceilings and floors, for particular keywords, either
by a system operator or in response to certain user behavior. For
example, a strong negative user reaction, e.g., some instruction to
never show such type of message again, may impose a ceiling for one
or more keywords.
[0341] Still further, it should be appreciated that, in various
embodiments, training parameters and/or learning rules can be
embedded in a given message, which can reflect the correlation
strength of the message to the keyword. For example, a first
advertisement having three related keywords KW1, KW2 and KW3,
Keyword KW1 may be far more closely coupled to the content of the
advertisement compared to keywords KW2 and KW3. Assuming that
respective decay parameters of 500, 2500 and 3000 are transmitted
with the advertisement, selection of the advertisement may cause a
prediction model to change the respective estimate {circumflex over
(P)}.sub.KW1 far faster than for {circumflex over (P)}.sub.KW2 and
{circumflex over (P)}.sub.KW3.
[0342] Note that the prediction engine may be designed to require
that a baseline correlation metric exceed a threshold value to
determine relevancy of the target message to the user. For example,
in lieu of FIG. 31 it may be desirable to only use keywords
associated with estimates that exceed 0.25 and/or are below -0.20
to select messages.
[0343] Similarly/alternatively, it may be desirable to only use the
top 10 values keywords and/or the bottom 5 keywords to select
messages. Such simplification of prediction models may improve
performance and reliability of a mobile message delivery device by
eliminating the effects of user selection "noise."
[0344] Finally, while Eqs (1)-(3) are representative of what is
known as an "LMS steepest descent" adaptive/learning algorithm, it
should be appreciated that other learning algorithms may be used,
such as a Newtonian algorithm or any other known or later-developed
learning technique.
[0345] FIG. 32A and FIG. 32B outline an exemplary operation for a
mobile client to perform various learning and predictive processes.
The process starts in step 3204 where a set of keywords are
assigned. As discussed above, the set of available keywords may be
sparse or not sparse and/or arranged in a hierarchical or
non-hierarchical/flat relationship. Next, in step 3206, the set of
keywords may be downloaded to a mobile client, e.g., a cellular
phone or wireless-capable PDA. Then, in step 3208, a set of seed
values may be downloaded onto the mobile client. In various
embodiments, such seed values may include a set of zero values, a
set of values determined based upon known demographics of the user,
or a set of values determined by any of the other processes
discussed above with regard to initial/seed values. Control
continues to step 3210.
[0346] In step 3210, a set of first messages may be downloaded onto
the mobile client, along with the appropriate meta-data, e.g.,
keywords and (possibly) keyword weights, and/or any number of
learning models, e.g., a modified steepest descent algorithm,
and/or any number of learning parameters, such as the decay
parameter discussed above, ceiling limits, floor limits, context
constraints, and so on. Note that while the present set of
operations allow for messages to be downloaded at the same time as
meta-data and other information, in various embodiments messages
may be downloaded after the mobile client determines that such
messages are suitable via any number of gating or valuation
operations. Control continues to step 3212.
[0347] In step 3212, a number of prediction operations may be
performed to predict messages, such as targeted advertisements,
that would likely be of interest to a user noting that such a
prediction operation could be based on a learned model constructed
from the seed values of step 3208. Next, in step 3214, the
desirable message(s) could be displayed (or otherwise presented) on
the mobile device. Then, in step 3216, the mobile device could
monitor user responses, e.g., observe and possibly store
click-through rates, to the displayed message(s). Control continues
to step 3220.
[0348] In step 3220, a set of one or more learning algorithms may
be performed to update (or otherwise determine) the various learned
models to establish one or more sets of learned user preference
weights. Note that, as discussed above, learned models may be
provided for a variety of context, may use any number of adaptive
processes, such as an LMS operation, may incorporate algorithms and
learning parameters for particular messages and so on. Control
continues to step 3222.
[0349] In step 3222, a set of second/target messages may be
downloaded onto the mobile client, along with the appropriate
meta-data, and/or any number of learning models, and/or any number
of learning parameters. Again, note that while the present set of
operations allow for messages to be downloaded at the same time as
meta-data and other information, in various embodiments, messages
may be downloaded after the mobile client determines that such
messages are suitable via any number of gating or
valuation/prediction operations. Control continues to step
3224.
[0350] In step 3224, a number of prediction operations may be
performed to predict messages, such as targeted advertisements,
that would likely be of interest to a user noting that such a
prediction operation could be based on the learned model of step
3220. Next, in step 3226, the desirable message(s) could be
displayed (or otherwise presented) on the mobile device. Then, in
step 3228, the mobile device could monitor user responses, e.g.,
observe and possibly store click-through rates, to the displayed
message(s). Control then jumps back to step 3220 where after steps
3220-3228 may be repeated as necessary or otherwise desirable.
[0351] Application to Statistics Generation--in various exemplary
embodiments, a user preference vector may have N dimensions, but
only some subset of M dimensions may be relevant to the user. A
sparse set of K dimensions can be randomly selected from the N
dimensions, and the user preference values associated with the
chosen K dimensions may be transmitted. Assume that there are U
users in the population for a certain demographic type (such as
teenagers). If all U users transmitted all N dimensional values to
a server, then each dimension may have available U samples to
determine statistics associated with the dimension (such as a mean
or variance). However, if only sparse (K-dimensional) components
are transmitted, then, on an average, Uk/N samples may be available
for each dimension. As long as U>>N, then there are
sufficient samples available to compute statistics for each
dimension, without requiring each user to transmit all N components
of its preference vector. Additionally, if only a fraction r of
users transmit information, then on an average Ukr/N samples may be
available for each dimension. Thus, one can maintain a sufficient
degree of privacy of information for each user while gathering
statistics over an entire population of users.
[0352] Cache Miss History Attribute: Every time a particular
message/ad is requested from a cache and there is no message/ad in
the cache satisfying the message/ad type requested, it is a missed
opportunity to show an appropriate message/ad to the user. Thus,
there is a need to give more weighted value to message that are of
the type for which the cache has recorded misses in the recent
past. In various embodiments, a parameter, such as the cache miss
state match indicator
(FLAG.sub.CACHE.sub.--.sub.MISS.sub.--.sub.MI) discussed above, can
work to avoid such missed opportunities by aiding message/ad value
calculation. In various embodiments, this attribute works to
determine whether a new prospective message matches the most recent
recorded cache misses. It may be a logical "1" (or equivalent) if
it matches one of the recent cache misses and a logical "0" (or
equivalent) otherwise. This flag may be reset once the message is
accessed by an application from the cache and served to the user.
If a new message is selected for cache entry, the cache miss entry
can be removed from the list of recorded cache misses.
[0353] Filter rules: Filter rules may be used by a System Operator
to drive the operation of a filtering agent. This allows the System
Operator to control the functionality of the filtering agent in a
dynamic fashion. Filter rules may be of different types and used to
drive different functionalities of the filtering subsystem. Some
typical use cases may include:
[0354] Filter rules that may determine message cache ratios used to
divide a cache space into different categories based on different
classifications. The cache ratios may be fixed or dynamic based on
some defined criteria.
[0355] Filter rules that may determine the value calculation
formula for each category.
[0356] Filter rules that may define .lamda. which is the value
decay rate based on time for messages.
[0357] Filter rules that may be used to specify any of the
coefficients/weights that go into the calculation of a final
message value from the message value attributes within a
category.
[0358] Filter rules that may define the match indicator calculation
formula.
[0359] Filter rules that may define a cache miss state match
indicator calculation formula.
[0360] Filter rules that may define a message playback probability
indicator calculation formula.
[0361] Filter rules that may define the minimum confidence level
threshold below which random CTR are calculated on the device.
[0362] Filter rules that may define the number of default messages
to be stored for each message type.
[0363] Architecture: Depending upon different message distribution
models, gating and message selection sub-processes might be
implemented by different agents that exist either on a server or on
a client. The following sections below discuss the possible
architectures for message filtering based on different ad
distribution mechanisms.
[0364] Multicast/Broadcast Message Distribution: FIG. 33 is an
illustration of a Multicast/Broadcast Message Distribution scenario
using a W-AT 100 and a multicast/broadcast message distribution
server 150-A. In case of multicast distribution, messages (e.g.,
ads), respective metadata and messages filtering rules can be
distributed by a message delivery network over a broadcast or
multicast channel to a number of users. Consequently, the filtering
and caching of messages targeted to the user profile of the user
may take place on the W-AT 100 along with any gating and selection
sub-processes of the filtering process.
[0365] Unicast Message Distribution: There are a number of
different protocols that can be used to implement unicast fetch of
messages from a message distribution server. Based on the
information available at such a server, the gating and selection
process can reside on either the server or the various mobile
devices. The following is a discussion on some of the protocols and
the corresponding message filtering architecture that may be
implemented in each case.
[0366] Unicast Message Distribution--Protocol 1: FIG. 34
illustrates a first exemplary unicast message distribution scenario
using W-AT 100 and a unicast message distribution server 150-B. In
operation, the W-AT 100 can send a "message pull" request to the
server 150-B whereby the server 150-B can respond with all the
messages available within the system. This approach can hide the
mobile device's user profile from the server 150-B by generating
and maintaining the profile on the W-AT 100. However it could be
expensive to deliver messages to a client over a unicast session if
there is a likelihood of a significant portion of the messages
being rejected because of non-match with the mobile device's user
profile. As in the multicast distribution case, the filtering and
caching of messages targeted to the user profile of the W-AT 100
may take place on the W-AT 100 along with the gating and selection
sub-processes of the filtering process.
[0367] Unicast Message Distribution--Protocol 2: FIG. 35
illustrates a second unicast distribution scenario using W-AT 100
and unicast message distribution server 150-C. In this scenario a
user profile can be generated on the W-AT 100 but can be in-sync
with server 150-C in that identical copies of the user profile can
reside on both devices 100 and 150-C. The device profile of W-AT
100 may also be in-sync with the server 150-C and hence, upon
receiving a message pull request from the W-AT 100, the server
150-C can readily push only targeted messages to the device. The
gating process--as well as parts of the selection process based on
determining whether the messages can be targeted towards the user
profile of the W-AT 100--can be implemented on the server 150-C.
The message value determination and replacement of old messages by
higher-valued new messages can be implemented on the W-AT 100.
[0368] In operation, any syncing procedures of the user and device
profile between the W-AT 100 and the server 150-C may take place
out-of-band using a separate protocol, or in certain embodiments
the profiles might be included in the message pull request from the
client.
[0369] Unicast Message Distribution--Protocol 3: FIG. 36
illustrates a third exemplary unicast message distribution scenario
using W-AT 100 and unicast message distribution server 150-D. In
operation, a user profile can be maintained on the W-AT 100, but
only the device profile is synced with the server 150-D while the
user profile remains only within W-AT 100. Correspondingly, the
gating process can be implemented on the server 150-D, and the
server 150-D may push only messages to the W-AT 100 that have
cleared the gating process. Part of the gating process, based on
system operator specified filters (if any) that require the user's
profile, can be implemented at the W-AT 100. Further, the selection
process can be implemented completely at the W-AT 100.
[0370] As with Protocol 2, the sync of the device profile between
the W-AT 100 and the server 150-D might take place out-of-band
using a separate protocol or the profile might be included in the
ad pull request from the client.
[0371] Unicast Message Distribution--Protocol 4: FIG. 37
illustrates a fourth unicast message distribution scenario using
W-AT 100 and unicast message distribution server 150-E. In this
scenario, upon receiving a message pull request from the W-AT 100,
the server 150-E can respond back with metadata for messages that
clear the appropriate gating process. Hence, the gating process can
be implemented on the server 150-E. Continuing, the selection
process can be implemented at the W-AT 100 using the metadata
provided by the server 150-E. Part of the gating process, based on
system operator specified filters (if any) that require the user's
profile, can be implemented at the W-AT 100. Next, the W-AT 100 may
respond to server 150-E with a message selection requests for those
messages that the W-AT 100 decides to display or store in its cache
based upon the selection process, and the server 150-E may provide
those selected messages to the W-AT 100.
[0372] Again, the device profile or the gating parameters might be
included in an initial message pull request by the W-AT 100, or
alternatively might be synchronized between the W-AT 100 and the
server 150-E out-of-band using a separate protocol.
[0373] Processing/Synthesizing Captured Location Data to Affect a
User Profile
[0374] Location information may often be used to derive indicators
of personal demographics. In the case of mobile communication
devices, location data may sometimes be a better indication of
demographic data concerning the user than billing information. In
addition to constraints on the use of billing information, the
billing information may not include sufficient data to indicate the
desired demographics. Further, home demographics may be only
partially indicative of the message-related interests of the user.
If, for example, the user maintains two residences, or tends to
frequent particular locations, this may not be indicated by home
demographics. Thus, for example, services and products related to a
particular work or recreational location may not be reflected by
the home-location derived demographics of a user, but still be very
useful.
[0375] It is understandable that a user may not wish to release
his/her location information in order to preserve privacy or may
consider it overly intrusive. However, by retaining the capability
to gather location information and perform location-based matching
by a mobile client, it is possible to attain the information
required for demographic targeting within the mobile device and
still preserve privacy. Thus, for example, if the user frequents a
particular recreational area with an appropriately enabled mobile
device, such as a cell phone with access to GPS information, the
appropriate information for the user's recreational interest may be
derived and/or synthesized without bothering the user and/or
breaching the user's privacy. This information may then be used to
derive and/or update a user profile resident to the mobile device,
which in turn may be used to determine which targeted content
messages may be downloaded and/ore displayed on the mobile device.
Conceptually, this can result in placement of advertising and other
information in a manner appropriate to the location information
associated with a user, based on actual detected locations, but
without providing the location information to an external
agent.
[0376] In operation, location information may be stored using a
database resident to a mobile device. The stored data may include
raw location data, but also in various embodiments include data
regarding: specific locations area locations, clusters of
locations, path information from various locations to other
locations, location-types in combination with values associated
with time intervals, and time probability distributions of specific
location types.
[0377] Continuing, in many cases, user action may be insufficient
to indicate a particular activity, but user actions may be relevant
if such actions can be linked with one or more various sets of
location data. Taking the example of a person who frequents a
recreation area, but usually enters the recreation area by entering
a particular roadway. Data concerning use of that roadway would not
by itself be indicative of much beyond the use and existence of the
roadway, and would not by itself have any associations with the
recreation area. However, by coupling/correlating the individual's
location history and the present action of entering the roadway, it
is possible to establish a statistically significant probability
that the individual is en route to the recreational area. Thus,
particular location information can be correlated with activities
associated with other particular locations. Continued examples
include recreational areas, parts of a city, entertainment
locations (especially in combination with time-of-day information),
geographical location in combination with time-of-day associated
with work, and locations associated with shopping. These can be
combined with identification of clusters of locations and time
intervals. The locations can be used in combination with path
analysis, which can be useful in establishing an association of
present location (or movement) with other stored data, e.g.,
present location, location history and path activity can be used to
identify a likelihood of a particular activity, and thus enable a
message provider to target messages before a user engages in a
particular activity. For example, by measuring various locations on
a GPS-enabled mobile client, the mobile client may determine that
the user has left work and is on-route to a shopping center the
user frequents. In response, a MAS (or other targeted content
delivery system) may automatically forward information relating to
products in which the user may be interested, as well as provide
advanced traffic information for various routes to the shopping
center.
[0378] Continuing, in various embodiments, it may be useful to
identify various businesses, for example those based on a
particular highway, to a user traversing the highway. In such
instances, targeted advertisements or other information based on
determination of the consumer's activities may be provided. This
approach is particularly advantageous in circumstances where the
customer has limited access to his mobile device, but authorizes
the particular business or genre of businesses to provide
information.
[0379] In various embodiments, a significant aspect of the system
may include that tracking of an individual may be performed within
the mobile device and retained within the mobile device. In one
configuration, no external party is privy to the tracking
information. Taken further, the profiling necessary to match the
tracking information associated with various targeted content can
be performed within the mobile device. Again, by limiting personal
information to a user's mobile device, it is likely that the user
may find this form of profiling acceptable because it is not
performed externally.
[0380] Note that, in various embodiments where circumstances
permit, it may be possible and/or advantageous to mesh a mobile
client with resources available in other devices, such as a
GPS-based navigation device of many automobiles. Thus, with little
more than software modification(s) (depending on the particular
embodiments) enabling a mobile device to communicate to one or more
of an automobile's systems, GPS and other information may be
shared. Generally, such an automobile and mobile client may
communicate using a Bluetooth or similar wireless interface
commonly found in such devices. Thus, as location information for
the mobile client is provided by the automobile's GPS/navigation
device, the mobile device's resident user profile may be updated
without the expense of a GPS system built in to the mobile
device.
[0381] Note that, in addition to automobiles, a particular mobile
device may derive location information from a variety of alternate
sources, such as a remote server or other nearby device, to receive
location information. For example, a mobile client may come into
contact with an 802.11 network residing in a coffee shop, or
perhaps a string of local wireless networks within a city whose
locations are known or capable of being derived, to determine
location information.
[0382] Note that, in various embodiments, a mobile client can
choose the source of information based on the energy level of the
mobile client/device, e.g., a low battery charge. Also note that
location history can be obtained based on periodic measurements
where the period of measurements is allowed to vary, or based on
random measurements, or a combination of random and periodic
measurements. A mobile client may also chose to change the rate of
GPS capture based on available energy, e.g., slow the GPS capture
rate with intermittent power down on low battery conditions, as
well as change the rate that it might tap into other available data
sources, e.g., the accelerometer and/or speedometer of an
automobile to which the mobile client has access.
[0383] FIGS. 38A-38H depict information screens 3800-A . . . 3800-H
captured by a GPS-enabled cellular phone of a particular user
displayed with various points of interest. As shown in these
figures, each information screens 3800-A . . . 3800-H includes a
map 3810, a set of controls 3820, a calendar display 3830, a daily
histogram 3840 and a weekly histogram 3850.
[0384] In operation, a user (or automated program) may set each
control in the set of controls 3820 for establish GPS sampling
times and the display of GPS information for the map 3810, the
calendar 3820 and the histograms 3840 and 3850 noting that while
histogram 3840 is a daily histogram divided into time slots of one
hour and the weekly histogram 3850 is divided into slots of one
day, such captured location data may be organized into any number
of histograms including a daily histogram showing particular
locations, areas, clusters of locations and even information
representing past paths taken that the user had experienced over
the course of various time periods, e.g., weekdays, weekends,
individual days, whole weeks, whole months and so on. Note that the
calendar 3830 may also be considered a histogram.
[0385] Also note that, by selecting a particular location icon,
such as location 3850 or 3852 of FIG. 38A, the data of histograms
3840 and 3842, as well as the numbers populating the calendar 3830,
can change to reflect GPS data commensurate with collected GPS
data. Continuing to FIG. 38C, a particular location may be
identified (either by a mobile client's user or by some estimation
software in the mobile client) as a user's residence 3854, and
similarly in FIG. 38E a particular location may be identified as
the user's workplace 3856.
[0386] In view of FIGS. 41A-41H, it should be apparent that
location information captured by a GPS-enabled cellular phone may
be used to generate user profile information enabling resident
software to determine both: (1) the likelihood that a user will be
at a particular location or traveling along a particular path at a
given time frame, e.g., an employee be at a work location at 4:00
pm; (2) the likely timeframe that the user will leave a particular
starting location at a given time, e.g., the employee leave a work
location at 5:00 pm, and (3) the likely timeframe that the user
will be at a particular second location or use a path (or set of
locations or paths), e.g., the employee use a particular road at
5:30 pm and reach his residence between 6:00 pm and 6:30 pm.
[0387] Note that likelihood information may be expressed in a large
variety of ways. For example, a time likelihood may be expressed as
a particular point in time, a Gaussian distribution centered on
particular point in time and with a particular variance; a
continuous probability distribution function (PDF) having a unique
form based on past user activity; a discrete PDF measured in
contiguous time periods ("time buckets") with the time buckets
being of equal or unequal size, and so on.
[0388] Using such information, an appropriately enabled mobile
client may also determine points of interest for the user, such as
the user's likely location for his home, work, hobbies, place of
religious worship and so on, as well as the likely times that the
user will be at such locations and other likelihood information for
such points of interest (e.g., likely times of arrival and
departure). Such information may then be used to shape or modify
user profile information in his mobile client, and as mentioned
above, the resultant user profile may be used to determine what
information (e.g., advertisements, coupons, etc.) would most likely
interest the user, which in turn may lead to specific target
information being stored and/or displayed on the mobile client.
[0389] Continuing, FIG. 39 and FIG. 40 depict an exemplary number
of operations for an example of a user leaving a work location
L.sub.W at the end of a work day. The probabilities concerning the
various locations, i.e., starting location L.sub.W and prospective
destination locations L.sub.1-L.sub.8, along with the probabilities
of using the respective paths/roads R1-R8 between locations
L.sub.1-L.sub.8, can be assumed to be developed using past behavior
of the user, sensed using GPS and other technology, and
incorporated into the user's mobile client.
[0390] Starting with FIG. 39, the user is assumed to be at
starting/work location L.sub.W shortly before the end of his work
day. Based on the user's past behavior, a user profile in his
mobile client can determine that the user is likely to leave work
at 5:00-5:15 pm and head to any of prospective destination
locations L.sub.1-L.sub.8 noting that in the present example the
probability of heading to locations L.sub.7-L.sub.8 falls below a
particular threshold and should not be considered.
[0391] Assuming that the probability of the user heading to
location L.sub.1 and L.sub.6 are both 0.1, the probability of the
user using roads R7 and R8 are also both 0.1. Assuming that the
probability of the user's final destination for the remaining
destinations of interest are L.sub.2=0.1, L.sub.3=0.1, L.sub.4=0.4,
and L.sub.5=0.2, (which assumes a 0.1 probability that the user
stays at work), the probability that the user uses road R1 is 0.7.
Thus, it is apparent that likely routes of the mobile client's user
may be based on spatial relationships of the mobile client's
current location L.sub.W in relation to the most likely destination
locations L.sub.1-L.sub.8, as well as the spatial relationships
between the most likely destination locations L.sub.1-L.sub.8.
[0392] Note that the user profile of the user's mobile client may
be formed and updated by correlating past time data of the user's
location history to form a time probability distribution of the
user's past presence and movement for the work location L.sub.W
and/or any other location to which the user may have visited; the
result being a probability density function (or facsimile thereof)
of the presence of the user at a given location as a function of
time. Such a user profile may determine any and all of the current
most likely probable destinations L.sub.1-L.sub.6 under
consideration by the user as a function of time and/or present
location.
[0393] Also note that any of the most probable current destinations
may be an amalgam or cluster of a plurality of past identified
destinations of the user. For example, location L.sub.5 may
actually consist of three separate locations closely spaced
together with the assumed location inform being a centroid (based
on a weighted geographical average) or general area of the three
location. Similarly, locations L.sub.3-L.sub.5 might be combined
into an amalgam location assuming locations L.sub.3-L.sub.5 are
reasonable proximate/clustered relative to one another.
[0394] Returning to FIG. 39, again the user's mobile client may
determine the most probable destinations based on the time of day,
the user's present location and other current observations taken by
the mobile client, as well as those past observations incorporated
into the user profile. Such "other current observations" may
include things such as recent phone and texting activity. For
example, if the user receives a call from his wife at 4:30 pm, it
may indicate an increase likelihood that the user may need to go to
a store before heading home, thus changing the probabilities for
the current likely destinations L.sub.1-L.sub.6. Similarly, if the
user shows no interaction with his mobile client, it may indicate a
likelihood that the user may delay his departure from location
L.sub.W.
[0395] Continuing to FIG. 40, note that the probability of heading
to any of the various current likely destinations L.sub.1-L.sub.6
may be updated based on "en route" accumulated measures of location
change by the mobile client after leaving the first location
L.sub.W. That is, as new data is received, the various
probabilities may need to be re-assessed. For the example of FIG.
40, this is reflected in changes in the probabilities of going to
destinations L.sub.1 and L.sub.6, as well as the probability of the
user staying at location L.sub.W, becomes negligible given that the
user is determined to be on road R1 by his mobile client. Thus, the
probabilities of going to destinations L.sub.1 and L.sub.6 or
staying at location L.sub.W may be discounted from further
consideration. Meanwhile, the probability of reaching any of
locations L.sub.2, L.sub.3, L.sub.4, L.sub.5, L.sub.8 and L.sub.8
may increase noting that the likelihood of the user reaching
location L.sub.2 is near unity (due to its spatial relationship
with both the user and the other current destination locations
L.sub.3, L.sub.4, L.sub.5, L.sub.8 and L.sub.8) even if the user
makes no stop at location L.sub.2. Thus, determining a likely
transition time, e.g., the time of leaving a first location or
arriving at another location, may be accomplished using an adaptive
weighted allocation based on other en route events.
[0396] Note that, in various embodiments, a k.sup.th order Markov
model (where k is an integer greater than 1) incorporated into the
mobile client may be used to determine any of the probabilities
discussed above. Continuing to FIG. 41, an exemplary Markov model
4100 is depicted for the user's starting location L.sub.W and
prospective destination locations L.sub.1-L.sub.8 of FIG. 39 and
FIG. 40. As shown in FIG. 41, the locations L.sub.W and
L.sub.1-L.sub.8 are interconnected with paths, and each path has a
probability P.sub.N-M. Again, note that each probability P.sub.N-M
can be derived from a user profile and vary as a function of the
current location of a user, a transition event and/or time of day.
Also note that there may be time-varying probabilities P.sub.N-N of
the user staying at location L.sub.N for a given period, e.g., the
likelihood of the user remaining at a grocery store (upon reaching
it) may have a Gaussian distribution centered at 20 minutes with a
10 minute variance.
[0397] FIG. 42 is diagram of a process flow outlining an exemplary
operation for updating the user profile based on an NFC
transaction. The process starts in step 4202 where a mobile client
may be programmed to sample location information using an available
GPS (or other suitable location finding device) and/or any of local
wireless cellular networks, local available LANs, and so on,
according to predetermined or adaptive sampling frequencies and
periods. Next, in step 4204, the captured information may be
processed/synthesized to identify points, areas of interest, paths
taken or any other location and/or path data. Then, in step 4206,
the information may be further processed/synthesized to determine
likely locations and/or likely paths for particular time
periods--as well as complementary information of likely time
periods for a given location or path. Control continues to step
4208.
[0398] In step 4208, a user profile residing in the mobile client
can be updated using special software resident in the mobile
client. In various embodiments, such user profile information,
which includes information derived from past observations of the
user, may be used to create some form of probability model of the
user's likely behavior for a given time of day and current
location.
[0399] Next, in step 4210, the mobile client may derive (directly
or using secondary resources, e.g., an automobile's GPS) any and
all of the recent/current observation data discussed above, such as
location, time, transition/movement, sensor (e.g., speedometer)
data, as well as information related to the user's current and/or
recent behavior, e.g., the mobile client observes the user sending
text messages. Next, in step 4512, the mobile client may process
the information of step 4210 and the information within the user
profile using any of the techniques discussed above, to identify
likely destinations, transition times and/or paths (or changes to
previously determined probabilities) that the user will likely take
based on the user's current location and time. Then, in step 4214,
the mobile client may select and/or display information, e.g.,
advertisements, coupons etc, based on the user profile, the data
collected in the previous steps and any probability data derived.
Control then jumps back to step 4210 where any or all of steps
4210-4214 may be repeated as may be found necessary or
desirable.
[0400] The techniques and modules described herein may be
implemented by various means. For example, these techniques may be
implemented in hardware, software, or a combination thereof. For a
hardware implementation, the processing units within an access
point or an access terminal may be implemented within one or more
application specific integrated circuits (ASICs), digital signal
processors (DSPs), digital signal processing W-ATs (DSPDs),
programmable logic W-ATs (PLDs), field programmable gate arrays
(FPGAs), processors, controllers, micro-controllers,
microprocessors, other electronic units designed to perform the
functions described herein, or a combination thereof.
[0401] For a software implementation, the techniques described
herein may be implemented with modules (e.g., procedures,
functions, and so on) that perform the functions described herein.
The software codes may be stored in memory units and executed by
processors or demodulators. The memory unit may be implemented
within the processor or external to the processor, in which case it
can be communicatively coupled to the processor via various
means.
[0402] In one or more exemplary embodiments, the functions
described may be implemented in hardware, software, firmware, or
any combination thereof. If implemented in software, the functions
may be stored on or transmitted over as one or more instructions or
code on a computer-readable medium. Computer-readable media
includes both computer storage media and communication media
including any medium that facilitates transfer of a computer
program from one place to another. A storage media may be any
available media that may be accessed by a computer. By way of
example, and not limitation, such computer-readable media may
comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,
magnetic disk storage or other magnetic storage devices, or any
other medium that may be used to carry or store desired program
code in the form of instructions or data structures and that may be
accessed by a computer. Also, any connection is properly termed a
computer-readable medium. For example, if the software is
transmitted from a website, server, or other remote source using a
coaxial cable, fiber optic cable, twisted pair, digital subscriber
line ("DSL"), or wireless technologies such as infrared, radio, and
microwave, then the coaxial cable, fiber optic cable, twisted pair,
DSL, or wireless technologies such as infrared, radio, and
microwave are included in the definition of medium. Disk and disc,
as used herein, includes compact disc ("CD"), laser disc, optical
disc, digital versatile disc ("DVD"), floppy disk, High Definition
DVD ("HD-DVD") and Blu-ray disc where disks usually reproduce data
magnetically, while discs reproduce data optically with lasers.
Combinations of the above should also be included within the scope
of computer-readable media.
[0403] The previous description of the disclosed embodiments is
provided to enable any person skilled in the art to make or use the
features, functions, operations, and embodiments disclosed herein.
Various modifications to these embodiments may be readily apparent
to those skilled in the art, and the generic principles defined
herein may be applied to other embodiments without departing from
their spirit or scope. Thus, the present disclosure is not intended
to be limited to the embodiments shown herein but is to be accorded
the widest scope consistent with the principles and novel features
disclosed herein.
* * * * *