U.S. patent application number 12/722564 was filed with the patent office on 2012-02-23 for sparse profile augmentation using a mobile aggregate profiling system.
This patent application is currently assigned to Waldeck Technology LLC. Invention is credited to Ravi Reddy Katpelly, Steven L. Petersen.
Application Number | 20120047143 12/722564 |
Document ID | / |
Family ID | 45565580 |
Filed Date | 2012-02-23 |
United States Patent
Application |
20120047143 |
Kind Code |
A1 |
Petersen; Steven L. ; et
al. |
February 23, 2012 |
SPARSE PROFILE AUGMENTATION USING A MOBILE AGGREGATE PROFILING
SYSTEM
Abstract
Systems and methods are provided for augmenting a user profile
of a subject user. In general, the user profile of the subject user
is augmented based on aggregate profile data for a group of users
relevant to a current location of the subject user. In one
embodiment, the group of users is a crowd of users currently
located at a location that is relevant to the current location of
the subject user. In another embodiment, the group of users is a
number of users historically, or previously, located at locations
relevant to the current location of the subject user.
Inventors: |
Petersen; Steven L.; (Los
Gatos, CA) ; Katpelly; Ravi Reddy; (Durham,
NC) |
Assignee: |
Waldeck Technology LLC
Wilmington
DE
|
Family ID: |
45565580 |
Appl. No.: |
12/722564 |
Filed: |
March 12, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61163091 |
Mar 25, 2009 |
|
|
|
Current U.S.
Class: |
707/738 ;
707/E17.059; 707/E17.089; 709/229; 715/745 |
Current CPC
Class: |
G01C 21/34 20130101;
H04W 4/02 20130101; G06N 5/04 20130101; G06Q 30/0282 20130101; H04W
4/029 20180201; H04W 12/02 20130101; G01C 21/00 20130101 |
Class at
Publication: |
707/738 ;
715/745; 709/229; 707/E17.059; 707/E17.089 |
International
Class: |
G06F 17/30 20060101
G06F017/30; G06F 3/00 20060101 G06F003/00 |
Claims
1. A computer-implemented method comprising: obtaining aggregate
profile data for a group of users relevant to a current location of
a subject user; and augmenting a user profile of the subject user
based on the aggregate profile data for the group of users relevant
to the current location of the subject user.
2. The method of claim 1 wherein the group of users is a crowd of
users that is currently located at a location that is relevant to
the current location of the subject user.
3. The method of claim 2 wherein the aggregate profile data for the
group of users is an aggregate profile of the crowd of users that
includes a plurality of keywords from user profiles of the users in
the crowd and, for each keyword of the plurality of keywords, a
number of occurrences of the keyword in the user profiles of the
users in the crowd.
4. The method of claim 3 wherein augmenting the user profile of the
subject user comprises augmenting the user profile of the subject
user based on the aggregate profile of the crowd of users such that
one or more keywords from the aggregate profile of the crowd of
users are added to the user profile of the subject user.
5. The method of claim 4 wherein augmenting the user profile of the
subject user further comprises, for each of the one or more
keywords from the aggregate profile added to the user profile of
the subject user: computing a probability for the keyword as a
function of the number of occurrences of the keyword in the user
profiles of the users in the crowd; and adding the probability for
the keyword to the user profile of the subject user.
6. The method of claim 3 wherein augmenting the user profile of the
subject user comprises: selecting one or more keywords from the
plurality of keywords in the aggregate profile of the crowd of
users based on the number of occurrences of each of the plurality
of keywords in the aggregate profile of the crowd of users;
generating a question for each of the one or more keywords;
providing the question for each of the one or more keywords to the
subject user; receiving an answer from the subject user for the
question for at least one of the one or more keywords that is
indicative of whether the subject user has an interest in the at
least one of the one or more keywords; and updating the user
profile of the subject user based on the answer from the subject
user for the question for the at least one of the one or more
keywords.
7. The method of claim 6 wherein updating the user profile of the
subject user comprises, for each keyword of the one or more
keywords for which questions were provided to the subject user and
for which an answer was received, updating the user profile of the
subject user such that the user profile of the subject user
includes the keyword and a fixed probability that reflects the
answer from the subject user.
8. The method of claim 7 wherein updating the user profile of the
subject user comprises, for each keyword of the plurality of
keywords in the aggregate profile of the crowd of users for which a
question was provided to the subject user but an answer was not
received from the subject user: determining whether the keyword is
already included in the user profile of the subject user; and if
the keyword is not already included in the user profile of the
subject user: computing a probability for the keyword as a function
of the number of occurrences for the keyword from the aggregate
profile of the crowd of users; and adding the keyword and the
probability for the keyword to the user profile of the subject
user.
9. The method of claim 8 wherein updating the user profile of the
subject user further comprises, if the keyword is already included
in the user profile of the subject user: computing a new
probability for the keyword as a function of an old probability for
the keyword from the user profile of the subject user and the
number of occurrences for the keyword from the aggregate profile of
the crowd of users; and updating the user profile of the subject
user to include the new probability for the keyword.
10. The method of claim 7 wherein updating the user profile of the
subject user comprises, for each keyword of the plurality of
keywords in the aggregate profile of the crowd of users for which a
question was not provided to the subject user: determining whether
the keyword is already included in the user profile of the subject
user; and if the keyword is not already included in the user
profile of the subject user: computing a probability for the
keyword as a function of the number of occurrences for the keyword
from the aggregate profile of the crowd of users; and adding the
keyword and the probability for the keyword to the user profile of
the subject user.
11. The method of claim 10 wherein updating the user profile of the
subject user further comprises, if the keyword is already included
in the user profile of the subject user: computing a new
probability for the keyword as a function of an old probability for
the keyword from the user profile of the subject user and the
number of occurrences for the keyword from the aggregate profile of
the crowd of users; and updating the user profile of the subject
user to include the new probability for the keyword.
12. The method of claim 6 wherein augmenting the user profile of
the subject user further comprises: providing a preliminary
question to the subject user that asks the subject user for a topic
of interest; and receiving an answer to the preliminary question
from the subject user that includes the topic of interest; wherein
selecting the one or more keywords from the plurality of keywords
in the aggregate profile of the crowd of users comprises selecting
the one or more keywords from the plurality of keywords in the
aggregate profile of the crowd of users based on the number of
occurrences of each of the plurality of keywords from the aggregate
profile of the crowd of users and the topic of interest provided by
the subject user.
13. The method of claim 1 wherein the group of users is a plurality
of users historically located at locations that are relevant to the
current location of the subject user.
14. The method of claim 13 wherein obtaining the aggregate profile
data comprises obtaining a historical aggregate profile for the
plurality of users historically located at locations that are
relevant to the current location of the subject user during one or
more previous time windows.
15. The method of claim 13 wherein the aggregate profile data for
the group of users is a historical aggregate profile for the
plurality of users historically located at locations that are
relevant to the current location of the subject user, the
historical aggregate profile comprising a plurality of keywords
and, for each keyword of the plurality of keywords, a number of
occurrences of the keyword in user profiles of the plurality of
users.
16. The method of claim 15 wherein augmenting the user profile of
the subject user comprises augmenting the user profile of the
subject user based on the historical aggregate profile such that
one or more keywords from the historical aggregate profile are
added to the user profile of the subject user.
17. The method of claim 16 wherein augmenting the user profile of
the subject user further comprises, for each keyword of the one or
more keywords from the historical aggregate profile added to the
user profile of the subject user: computing a probability for the
keyword as a function of the number of occurrences of the keyword
in the user profiles of the plurality of users; and adding the
probability for the keyword to the user profile of the subject
user.
18. The method of claim 15 wherein augmenting the user profile of
the subject user comprises: selecting one or more keywords from the
plurality of keywords in the historical aggregate profile based on
the number of occurrences of each of the plurality of keywords in
the historical aggregate profile; generating a question for each of
the one or more keywords; providing the question for each of the
one or more keywords to the subject user; receiving an answer from
the subject user for the question for at least one of the one or
more keywords that is indicative of whether the subject user has an
interest in the at least one of the one or more keywords; and
updating the user profile of the subject user based on the answer
from the subject user for the question for the at least one of the
one or more keywords.
19. The method of claim 18 wherein updating the user profile of the
subject user comprises, for each keyword of the one or more
keywords for which questions were provided to the subject user and
for which an answer was received, updating the user profile of the
subject user such that the user profile of the subject user
includes the keyword and a fixed probability that reflects the
answer from the subject user.
20. The method of claim 19 wherein updating the user profile of the
subject user comprises, for each keyword of the plurality of
keywords in the historical aggregate profile for which a question
was provided to the subject user but an answer was not received
from the subject user: determining whether the keyword is already
included in the user profile of the subject user; and if the
keyword is not already included in the user profile of the subject
user: computing a probability for the keyword as a function of the
number of occurrences for the keyword from the historical aggregate
profile; and adding the keyword and the probability for the keyword
to the user profile of the subject user.
21. The method of claim 20 wherein updating the user profile of the
subject user further comprises, if the keyword is already included
in the user profile of the subject user: computing a new
probability for the keyword as a function of an old probability for
the keyword from the user profile of the subject user and the
number of occurrences for the keyword from the historical aggregate
profile; and updating the user profile of the subject user to
include the new probability for the keyword.
22. The method of claim 19 wherein updating the user profile of the
subject user comprises, for each keyword of the plurality of
keywords in the historical aggregate profile for which a question
was provided to the subject user but an answer was not received
from the subject user: determining whether the keyword is already
included in the user profile of the subject user; and if the
keyword is not already included in the user profile of the subject
user: computing a probability for the keyword as a function of the
number of occurrences for the keyword from the historical aggregate
profile; and adding the keyword and the probability for the keyword
to the user profile of the subject user.
23. The method of claim 22 wherein updating the user profile of the
subject user further comprises, if the keyword is already included
in the user profile of the subject user: computing a new
probability for the keyword as a function of an old probability for
the keyword from the user profile of the subject user and the
number of occurrences for the keyword from the historical aggregate
profile; and updating the user profile of the subject user to
include the new probability for the keyword.
24. The method of claim 18 wherein augmenting the user profile of
the subject user further comprises: providing a preliminary
question to the subject user that asks the subject user for a topic
of interest; and receiving an answer to the preliminary question
from the subject user that includes the topic of interest; wherein
selecting the one or more keywords from the plurality of keywords
in the historical aggregate profile comprises selecting the one or
more keywords from the plurality of keywords in the historical
aggregate profile based on the number of occurrences of each of the
plurality of keywords from the historical aggregate profile and the
topic of interest provided by the subject user.
25. The method of claim 1 further comprising repeating the steps of
obtaining aggregate profile data and augmenting the user profile of
the subject user based on the aggregate profile data for each of
one or more subsequent locations of the subject user.
26. A computing device comprising: a communication interface
communicatively coupling the computing device to a network; and a
controller associated with the communication interface and adapted
to: obtain aggregate profile data for a group of users relevant to
a current location of a subject user; and augment a user profile of
the subject user based on the aggregate profile data for the group
of users relevant to the current location of the subject user.
27. A computer-readable medium storing software for instructing a
controller of a computing device to: obtain aggregate profile data
for a group of users relevant to a current location of a subject
user; and augment a user profile of the subject user based on the
aggregate profile data for the group of users relevant to the
current location of the subject user.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit of provisional patent
application Ser. No. 61/163,091, filed Mar. 25, 2009, the
disclosure of which is hereby incorporated by reference in its
entirety.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates to augmenting a sparse user
profile.
BACKGROUND
[0003] Many systems and services rely on user profiles of their
users. However, oftentimes, users fail to adequately complete their
user profiles, thereby resulting in incomplete or sparse user
profiles. In order to increase the effectiveness of systems and
services that rely on user profiles, there is a need for a system
and method for augmenting sparse user profiles.
SUMMARY
[0004] Systems and methods are provided for augmenting a user
profile of a subject user. In general, the user profile of the
subject user is augmented based on aggregate profile data for a
group of users relevant to a current location of the subject user.
In one embodiment, the group of users is a crowd of users currently
located at a location that is relevant to the current location of
the subject user. In another embodiment, the group of users is a
number of users historically, or previously, located at locations
relevant to the current location of the subject user.
[0005] In one embodiment, a profile augmentation function obtains
an aggregate profile of a crowd of users currently located at or
near the current location of the subject user. The aggregate
profile of the crowd includes a number of keywords and a number of
user matches, or occurrences, of each of the keywords in user
profiles of the users in the crowd. The profile augmentation
function then augments the user profile of the subject user based
on the keywords and the number of user matches for the keywords in
the aggregate profile of the crowd.
[0006] In another embodiment, the profile augmentation function
obtains a historical aggregate profile for users previously, or
historically, located at or near the current location of the
subject user. In one embodiment, the historical aggregate profile
includes a number of keywords and a number of user matches, or
occurrences, of each of the keywords in user profiles of the users
historically located at or near the current location of the subject
user. The profile augmentation function then augments the user
profile of the subject user based on the keywords and the number of
user matches for the keywords in the historical aggregate
profile.
[0007] Those skilled in the art will appreciate the scope of the
present invention and realize additional aspects thereof after
reading the following detailed description in association with the
accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The accompanying drawings incorporated in and forming a part
of this specification illustrate several aspects of the invention,
and together with the description serve to explain the principles
of the invention.
[0009] FIG. 1A illustrates a system providing sparse profile
augmentation according to a first embodiment of the present
disclosure;
[0010] FIG. 1B illustrates a system providing sparse profile
augmentation according to a second exemplary embodiment of the
present disclosure;
[0011] FIG. 2 is a block diagram of the MAP server of FIGS. 1A and
1B according to one embodiment of the present disclosure;
[0012] FIG. 3 is a block diagram of the MAP client of one of the
mobile devices of FIGS. 1A and 1B according to one embodiment of
the present disclosure;
[0013] FIG. 4 illustrates the operation of the system of FIGS. 1A
and 1B to provide user profiles and current locations of the users
of the mobile devices to the MAP server according to one embodiment
of the present disclosure;
[0014] FIG. 5 illustrates the operation of the system of FIGS. 1A
and 1B to provide user profiles and current locations of the users
of the mobile devices to the MAP server according to another
embodiment of the present disclosure;
[0015] FIGS. 6 and 7 graphically illustrate bucketization of users
according to location for purposes of maintaining a historical
record of anonymized user profile data by location according to one
embodiment of the present disclosure;
[0016] FIG. 8 is a flow chart illustrating the operation of a
foreground bucketization process performed by the MAP server to
maintain the lists of users for location buckets for purposes of
maintaining a historical record of anonymized user profile data by
location according to one embodiment of the present disclosure;
[0017] FIG. 9 is a flow chart illustrating the anonymization and
storage process performed by the MAP server for the location
buckets in order to maintain a historical record of anonymized user
profile data by location according to one embodiment of the present
disclosure;
[0018] FIG. 10 graphically illustrates anonymization of a user
record according to one embodiment of the present disclosure;
[0019] FIG. 11 is a flow chart for a quadtree based storage process
that may be used to store anonymized user profile data for location
buckets according to one embodiment of the present disclosure;
[0020] FIG. 12 is a flow chart illustrating a quadtree algorithm
that may be used to process the location buckets for storage of the
anonymized user profile data according to one embodiment of the
present disclosure;
[0021] FIGS. 13A through 13E graphically illustrate the process of
FIG. 12 for the generation of a quadtree data structure for one
exemplary base quadtree region;
[0022] FIG. 14 illustrates the operation of the system of FIGS. 1A
and 1B wherein a mobile device is enabled to request and receive
historical data from the MAP server according to one embodiment of
the present disclosure;
[0023] FIG. 15 is a flow chart for a spatial crowd formation
process according to one embodiment of the present disclosure;
[0024] FIGS. 16A through 16D graphically illustrate the crowd
formation process of FIG. 15 for an exemplary bounding box;
[0025] FIGS. 17A through 17D illustrate a flow chart for a spatial
crowd formation process according to another embodiment of the
present disclosure;
[0026] FIGS. 18A through 18D graphically illustrate the crowd
formation process of FIGS. 17A through 17D for a scenario where the
crowd formation process is triggered by a location update for a
user having no old location;
[0027] FIGS. 19A through 19F graphically illustrate the crowd
formation process of FIGS. 17A through 17D for a scenario where the
new and old bounding boxes overlap;
[0028] FIGS. 20A through 20E graphically illustrate the crowd
formation process of FIGS. 17A through 17D in a scenario where the
new and old bounding boxes do not overlap;
[0029] FIG. 21 illustrates the operation of the MAP server to
process a crowd request according to one embodiment of the present
disclosure;
[0030] FIG. 22 is a flow chart illustrating the operation of the
profile augmentation function of FIGS. 1A and 1B to augment a user
profile of a subject user based on an aggregate profile of a crowd
at or near a current location of the subject user according to one
embodiment of the present disclosure;
[0031] FIG. 23 is a more detailed illustration of the augmenting
step of FIG. 22 according to one embodiment of the present
disclosure;
[0032] FIG. 24 is a flow chart illustrating the operation of the
profile augmentation to update a user profile of a subject user
according to one embodiment of the present disclosure;
[0033] FIG. 25 is a more detailed illustration of the augmenting
step of FIG. 22 according to another embodiment of the present
disclosure;
[0034] FIG. 26 is a flow chart illustrating the operation of the
profile augmentation function of FIG. 1A to augment a user profile
of a subject user based on an aggregate profile of a crowd at or
near a current location of the subject user according to one
embodiment of the present disclosure;
[0035] FIG. 27 is a flow chart illustrating the operation of the
profile augmentation function of FIG. 1B to augment a user profile
of a subject user based on an aggregate profile of a crowd at or
near a current location of the subject user according to one
embodiment of the present disclosure;
[0036] FIG. 28 is a flow chart illustrating the operation of the
profile augmentation function of FIGS. 1A and 1B to augment a user
profile of a subject user based on a historical aggregate profile
for a current location of the subject user according to another
embodiment of the present disclosure;
[0037] FIG. 29 is more detailed illustration of the augmenting step
of FIG. 28 according to one embodiment of the present
disclosure;
[0038] FIG. 30 is more detailed illustration of the augmenting step
of FIG. 28 according to another embodiment of the present
disclosure;
[0039] FIG. 31 is a flow chart illustrating the operation of the
profile augmentation function of FIG. 1A to augment a user profile
of a subject user based on a historical aggregate profile for a
current location of the subject user according to one embodiment of
the present disclosure;
[0040] FIG. 32 is a flow chart illustrating the operation of the
profile augmentation function of FIG. 1B to augment a user profile
of a subject user based on a historical aggregate profile for a
current location of the subject user according to another
embodiment of the present disclosure;
[0041] FIG. 33 is a flow chart illustrating the operation of the
MAP server to generate a historical aggregate profile for a current
location of a subject user in response to a request from the
profile augmentation function according to one embodiment of the
present disclosure;
[0042] FIG. 34 is a block diagram of the MAP server of FIG. 1
according to one embodiment of the present disclosure;
[0043] FIG. 35 is a block diagram of one of the mobile devices of
FIG. 1 according to one embodiment of the present disclosure;
[0044] FIG. 36 is a block diagram of the subscriber device of FIG.
1 according to one embodiment of the present disclosure;
[0045] FIG. 37 is a block diagram of the third-party server of FIG.
1 according to one embodiment of the present disclosure; and
[0046] FIG. 38 is a block diagram of the profile server of FIG. 1
according to one embodiment of the present disclosure.
DETAILED DESCRIPTION
[0047] The embodiments set forth below represent the necessary
information to enable those skilled in the art to practice the
invention and illustrate the best mode of practicing the invention.
Upon reading the following description in light of the accompanying
drawings, those skilled in the art will understand the concepts of
the invention and will recognize applications of these concepts not
particularly addressed herein. It should be understood that these
concepts and applications fall within the scope of the disclosure
and the accompanying claims.
[0048] FIG. 1A illustrates a system 10 providing sparse profile
augmentation according to a first exemplary embodiment of the
present disclosure. In this embodiment, the system 10 includes a
MAP server 12, one or more profile servers 14, a location server
16, a number of mobile devices 18-1 through 18-N having associated
users 20-1 through 20-N, a subscriber device 22 having an
associated subscriber 24, and a third-party server 26
communicatively coupled via a network 28. The network 28 may be any
type of network or any combination of networks. Specifically, the
network 28 may include wired components, wireless components, or
both wired and wireless components. In one exemplary embodiment,
the network 28 is a distributed public network such as the
Internet, where the mobile devices 18-1 through 18-N are enabled to
connect to the network 28 via local wireless connections (e.g.,
WiFi or IEEE 802.11 connections) or wireless telecommunications
connections (e.g., 3G or 4G telecommunications connections such as
GSM, LTE, W-CDMA, or WiMAX connections).
[0049] As discussed below in detail, the MAP server 12 operates to
obtain current locations, including location updates, and user
profiles of the users 20-1 through 20-N of the mobile devices 18-1
through 18-N. The current locations of the users 20-1 through 20-N
can be expressed as positional geographic coordinates such as
latitude-longitude pairs, and a height vector (if applicable), or
any other similar information capable of identifying a given
physical point in space in a two-dimensional or three-dimensional
coordinate system. Using the current locations and user profiles of
the users 20-1 through 20-N, the MAP server 12 is enabled to
provide a number of features such as, but not limited to,
maintaining a historical record of anonymized user profile data by
location, generating aggregate profile data over time for a Point
of Interest (POI) or Area of Interest (AOI) using the historical
record of anonymized user profile data, identifying crowds of users
using current locations and/or user profiles of the users 20-1
through 20-N, and generating aggregate profiles for crowds of users
at a POI or in an AOI using the current user profiles of users in
the crowds. While not essential, for additional information
regarding the MAP server 12, the interested reader is directed to
U.S. patent application Ser. No. 12/645,535 entitled MAINTAINING A
HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA BY LOCATION FOR
USERS IN A MOBILE ENVIRONMENT, U.S. patent application Ser. No.
12/645,532 entitled FORMING CROWDS AND PROVIDING ACCESS TO CROWD
DATA IN A MOBILE ENVIRONMENT, U.S. patent application Ser. No.
12/645,539 entitled ANONYMOUS CROWD TRACKING, U.S. patent
application Ser. No. 12/645,544 entitled MODIFYING A USER'S
CONTRIBUTION TO AN AGGREGATE PROFILE BASED ON TIME BETWEEN LOCATION
UPDATES AND EXTERNAL EVENTS, U.S. patent application Ser. No.
12/645,546 entitled CROWD FORMATION FOR MOBILE DEVICE USERS, U.S.
patent application Ser. No. 12/645,556 entitled SERVING A REQUEST
FOR DATA FROM A HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA
IN A MOBILE ENVIRONMENT, and U.S. patent application Ser. No.
12/645,560 entitled HANDLING CROWD REQUESTS FOR LARGE GEOGRAPHIC
AREAS, all of which were filed on Dec. 23, 2009 and are hereby
incorporated herein by reference in their entireties. Note that
while the MAP server 12 is illustrated as a single server for
simplicity and ease of discussion, it should be appreciated that
the MAP server 12 may be implemented as a single physical server or
multiple physical servers operating in a collaborative manner for
purposes of redundancy and/or load sharing.
[0050] In general, the one or more profile servers 14 operate to
store user profiles for a number of persons including the users
20-1 through 20-N of the mobile devices 18-1 through 18-N. For
example, the one or more profile servers 14 may be servers
providing social network services such as the Facebook.RTM. social
networking service, the MySpace.RTM. social networking service, the
LinkedIN.RTM. social networking service, and/or the like. As
discussed below, using the one or more profile servers 14, the MAP
server 12 is enabled to directly or indirectly obtain the user
profiles of the users 20-1 through 20-N of the mobile devices 18-1
through 18-N. The location server 16 generally operates to receive
location updates from the mobile devices 18-1 through 18-N and make
the location updates available to entities such as, for instance,
the MAP server 12. In one exemplary embodiment, the location server
16 is a server operating to provide Yahoo!'s FireEagle service.
Before proceeding, it should be noted that while the system 10 of
FIG. 1A illustrates an embodiment where the one or more profile
servers 14 and the location server 16 are separate from the MAP
server 12, the present disclosure is not limited thereto. In an
alternative embodiment, the functionality of the one or more
profile servers 14 and/or the location server 16 may be implemented
within the MAP server 12.
[0051] The mobile devices 18-1 through 18-N may be mobile smart
phones, portable media player devices, mobile gaming devices, or
the like. Some exemplary mobile devices that may be programmed or
otherwise configured to operate as the mobile devices 18-1 through
18-N are the Apple.RTM. iPhone, the Palm Pre, the Samsung Rogue,
the Blackberry Storm, and the Apple.RTM. iPod Touch.RTM. device.
However, this list of exemplary mobile devices is not exhaustive
and is not intended to limit the scope of the present
disclosure.
[0052] The mobile devices 18-1 through 18-N include MAP clients
30-1 through 30-N, MAP applications 32-1 through 32-N, third-party
applications 34-1 through 34-N, and location functions 36-1 through
36-N, respectively. Using the mobile device 18-1 as an example, the
MAP client 30-1 is preferably implemented in software. In general,
in the preferred embodiment, the MAP client 30-1 is a middleware
layer operating to interface an application layer (i.e., the MAP
application 32-1 and the third-party applications 34-1) to the MAP
server 12. More specifically, the MAP client 30-1 enables the MAP
application 32-1 and the third-party applications 34-1 to request
and receive data from the MAP server 12. In addition, the MAP
client 30-1 enables applications, such as the MAP application 32-1
and the third-party applications 34-1, to access data from the MAP
server 12.
[0053] The MAP application 32-1 is also preferably implemented in
software. The MAP application 32-1 generally provides a user
interface component between the user 20-1 and the MAP server 12.
More specifically, among other things, the MAP application 32-1
enables the user 20-1 to initiate historical requests for
historical data (e.g., historical aggregate profile data) or crowd
requests for crowd data (e.g., aggregate profile data and/or crowd
characteristics data) from the MAP server 12 for a POI or AOI. The
MAP application 32-1 also enables the user 20-1 to configure
various settings. For example, the MAP application 32-1 may enable
the user 20-1 to select a desired social networking service (e.g.,
Facebook, MySpace, LinkedIN, etc.) from which to obtain the user
profile of the user 20-1 and provide any necessary credentials
(e.g., username and password) needed to access the user profile
from the social networking service.
[0054] The third-party applications 34-1 are preferably implemented
in software. The third-party applications 34-1 operate to access
the MAP server 12 via the MAP client 30-1. The third-party
applications 34-1 may utilize data obtained from the MAP server 12
in any desired manner. As an example, one of the third party
applications 34-1 may be a gaming application that utilizes
historical aggregate profile data to notify the user 20-1 of POIs
or AOIs where persons having an interest in the game have
historically congregated.
[0055] The location function 36-1 may be implemented in hardware,
software, or a combination thereof. In general, the location
function 36-1 operates to determine or otherwise obtain the
location of the mobile device 18-1. For example, the location
function 36-1 may be or include a Global Positioning System (GPS)
receiver.
[0056] The subscriber device 22 is a physical device such as a
personal computer, a mobile computer (e.g., a notebook computer, a
netbook computer, a tablet computer, etc.), a mobile smart phone,
or the like. The subscriber 24 associated with the subscriber
device 22 is a person or entity. In general, the subscriber device
22 enables the subscriber 24 to access the MAP server 12 via a web
browser 38 to obtain various types of data, preferably for a fee.
For example, the subscriber 24 may pay a fee to have access to
historical aggregate profile data for one or more POIs and/or one
or more AOIs, pay a fee to have access to crowd data such as
aggregate profiles for crowds located at one or more POIs and/or
located in one or more AOIs, pay a fee to track crowds, or the
like. Note that the web browser 38 is exemplary. In another
embodiment, the subscriber device 22 is enabled to access the MAP
server 12 via a custom application.
[0057] The third-party server 26 is a physical server that has
access to data from the MAP server 12 such as historical aggregate
profile data for one or more POIs or one or more AOIs or crowd data
such as aggregate profiles for one or more crowds at one or more
POIs or within one or more AOIs. Based on the data from the MAP
server 12, the third-party server 26 operates to provide a service
such as, for example, targeted advertising. For example, the
third-party server 26 may obtain anonymous aggregate profile data
for one or more crowds located at a POI and then provide targeted
advertising to known users located at the POI based on the
anonymous aggregate profile data. Note that while targeted
advertising is mentioned as an exemplary service provided by the
third-party server 26, other types of services may additionally or
alternatively be provided. Other types of services that may be
provided by the third-party server 26 will be apparent to one of
ordinary skill in the art upon reading this disclosure.
[0058] Lastly, in this embodiment, the MAP server 12 includes a
profile augmentation function 40. The profile augmentation function
40 is preferably implemented in software, but is not limited
thereto. As discussed below in detail, the profile augmentation
function 40 operates to augment user profiles of users, such as but
not limited to the users 20-1 through 20-N, based on aggregate
profile data for crowds of users and/or historical aggregate
profile data. Using the user 20-1 as an example, the profile
augmentation function 40 operates to augment the user profile of
the user 20-1 based on aggregate profiles of crowds of users in
which the user 20-1 is included, aggregate profiles of crowds of
users 20-1 that are nearby to the user 20-1, and/or historical
aggregate profile data for locations visited by the user 20-1.
[0059] FIG. 1B illustrates the system 10 providing sparse profile
augmentation according to a second exemplary embodiment of the
present disclosure. In this embodiment, the system 10 includes a
MAP server 12, one or more profile servers 14, a location server
16, a number of mobile devices 18-1 through 18-N having associated
users 20-1 through 20-N, a subscriber device 22 having an
associated subscriber 24, and a third-party server 26
communicatively coupled via a network 28. However, in this
embodiment, the profile augmentation function 40 is implemented
apart from the MAP server 12. Specifically, the profile
augmentation function 40 may be implemented on any network device
that is enabled to communicate with the MAP server 12 via the
network 28. For example, the profile augmentation function 40 may
be implemented on the profile server 14, one or more of the mobile
devices 18-1 through 18-N, the subscriber device 22, and/or the
third-party server 26.
[0060] As discussed below in detail, in this embodiment, the
profile augmentation function 40 operates to augment user profiles
of system users (i.e., one or more of the users 20-1 through 20-N),
third-party users (e.g., one or more users associated with the
profile server 14 other than the users 20-1 through 20-N, the
subscriber 24, and/or one or more users associated with the
third-party server 26), or a combination thereof. More
specifically, for a particular user, the profile augmentation
function 40 augments the user profile of the user based on
aggregate profile data for crowds located at or near the current
location of the user and/or historical aggregate profile data for
the current location of the user.
[0061] Before describing the operation of the profile augmentation
function 40 in detail, FIGS. 2 through 22 provide a description of
some of the features of the MAP server 12 that may be utilized
directly or indirectly by the profile augmentation function 40.
FIG. 2 is a block diagram of the MAP server 12 of FIGS. 1A and 1B
according to one embodiment of the present disclosure. As
illustrated, the MAP server 12 includes an application layer 42, a
business logic layer 44, and a persistence layer 46. The
application layer 42 includes a user web application 48, a mobile
client/server protocol component 50, and one or more data
Application Programming Interfaces (APIs) 52. The user web
application 48 is preferably implemented in software and operates
to provide a web interface for users, such as the subscriber 24, to
access the MAP server 12 via a web browser. The mobile
client/server protocol component 50 is preferably implemented in
software and operates to provide an interface between the MAP
server 12 and the MAP clients 30-1 through 30-N hosted by the
mobile devices 18-1 through 18-N. The data APIs 52 enable
third-party services, such as the third-party server 26, to access
the MAP server 12.
[0062] The business logic layer 44 includes a profile manager 54, a
location manager 56, a history manager 58, a crowd analyzer 60, and
an aggregation engine 62, each of which is preferably implemented
in software. In addition, in the embodiment of FIG. 1A, the
business logic layer 44 also includes the profile augmentation
function 40. Note, however, that in the embodiment of FIG. 1B, the
business logic layer 44 does not include the profile augmentation
function 40. The profile manager 54 generally operates to obtain
the user profiles of the users 20-1 through 20-N directly or
indirectly from the one or more profile servers 14 and store the
user profiles in the persistence layer 46. The location manager 56
operates to obtain the current locations of the users 20-1 through
20-N including location updates. As discussed below, the current
locations of the users 20-1 through 20-N may be obtained directly
from the mobile devices 18-1 through 18-N and/or obtained from the
location server 16.
[0063] The history manager 58 generally operates to maintain a
historical record of anonymized user profile data by location. The
crowd analyzer 60 operates to form crowds of users. In one
embodiment, the crowd analyzer 60 utilizes a spatial crowd
formation algorithm. However, the present disclosure is not limited
thereto. In addition, the crowd analyzer 60 may further
characterize crowds to reflect degree of fragmentation, best-case
and worst-case degree of separation (DOS), and/or degree of
bi-directionality of relationships. Still further, the crowd
analyzer 60 may also operate to track crowds. The aggregation
engine 62 generally operates to provide aggregate profile data in
response to requests from the mobile devices 18-1 through 18-N, the
subscriber device 22, the profile server 14, and/or the third-party
server 26. The aggregate profile data may be historical aggregate
profile data for one or more geographic locations (e.g., one or
more POIs) or one or more geographic areas (e.g., one or more AOIs)
or aggregate profile data for crowd(s) currently at one or more
geographic locations or in one or more geographic areas.
[0064] The persistence layer 46 includes an object mapping layer 64
and a datastore 66. The object mapping layer 64 is preferably
implemented in software. The datastore 66 is preferably a
relational database, which is implemented in a combination of
hardware (i.e., physical data storage hardware) and software (i.e.,
relational database software). In this embodiment, the business
logic layer 44 is implemented in an object-oriented programming
language such as, for example, Java. As such, the object mapping
layer 64 operates to map objects used in the business logic layer
44 to relational database entities stored in the datastore 66. Note
that, in one embodiment, data is stored in the datastore 66 in a
Resource Description Framework (RDF) compatible format.
[0065] In an alternative embodiment, rather than being a relational
database, the datastore 66 may be implemented as an RDF datastore.
More specifically, the RDF datastore may be compatible with RDF
technology adopted by Semantic Web activities. Namely, the RDF
datastore may use the Friend-Of-A-Friend (FOAF) vocabulary for
describing people, their social networks, and their interests. In
this embodiment, the MAP server 12 may be designed to accept raw
FOAF files describing persons, their friends, and their interests.
These FOAF files are currently output by some social networking
services such as Livejournal and Facebook. The MAP server 12 may
then persist RDF descriptions of the users 20-1 through 20-N as a
proprietary extension of the FOAF vocabulary that includes
additional properties desired for the system 10.
[0066] FIG. 3 illustrates the MAP client 30-1 of FIGS. 1A and 1B in
more detail according to one embodiment of the present disclosure.
This discussion is equally applicable to the other MAP clients 30-2
through 30-N. As illustrated, in this embodiment, the MAP client
30-1 includes a MAP access API 68, a MAP middleware component 70,
and a mobile client/server protocol component 72. The MAP access
API 68 is implemented in software and provides an interface by
which the MAP client 30-1 and the third-party applications 34-1 are
enabled to access the MAP server 12. The MAP middleware component
70 is implemented in software and performs the operations needed
for the MAP client 30-1 to operate as an interface between the MAP
application 32-1 and the third-party applications 34-1 at the
mobile device 18-1 and the MAP server 12. The mobile client/server
protocol component 72 enables communication between the MAP client
30-1 and the MAP server 12 via a defined protocol.
[0067] FIG. 4 illustrates the operation of the system 10 of FIGS.
1A and 1B to provide the user profile of the user 20-1 of the
mobile device 18-1 to the MAP server 12 according to one embodiment
of the present disclosure. This discussion is equally applicable to
user profiles of the other users 20-2 through 20-N of the other
mobile devices 18-2 through 18-N. First, an authentication process
is performed (step 1000). For authentication, in this embodiment,
the mobile device 18-1 authenticates with the profile server 14
(step 1000A) and the MAP server 12 (step 1000B). In addition, the
MAP server 12 authenticates with the profile server 14 (step
1000C). Preferably, authentication is performed using OpenID or
similar technology. However, authentication may alternatively be
performed using separate credentials (e.g., username and password)
of the user 20-1 for access to the MAP server 12 and the profile
server 14. Assuming that authentication is successful, the profile
server 14 returns an authentication succeeded message to the MAP
server 12 (step 1000D), and the profile server 14 returns an
authentication succeeded message to the MAP client 30-1 of the
mobile device 18-1 (step 1000E).
[0068] At some point after authentication is complete, a user
profile process is performed such that a user profile of the user
20-1 is obtained from the profile server 14 and delivered to the
MAP server 12 (step 1002). In this embodiment, the MAP client 30-1
of the mobile device 18-1 sends a profile request to the profile
server 14 (step 1002A). In response, the profile server 14 returns
the user profile of the user 20-1 to the mobile device 18-1 (step
1002B). The MAP client 30-1 of the mobile device 18-1 then sends
the user profile of the user 20-1 to the MAP server 12 (step
1002C). Note that while in this embodiment the MAP client 30-1
sends the complete user profile of the user 20-1 to the MAP server
12, in an alternative embodiment, the MAP client 30-1 may filter
the user profile of the user 20-1 according to criteria specified
by the user 20-1. For example, the user profile of the user 20-1
may include demographic information, general interests, music
interests, and movie interests, and the user 20-1 may specify that
the demographic information or some subset thereof is to be
filtered, or removed, before sending the user profile to the MAP
server 12.
[0069] Upon receiving the user profile of the user 20-1 from the
MAP client 30-1 of the mobile device 18-1, the profile manager 54
of the MAP server 12 processes the user profile (step 1002D). More
specifically, in the preferred embodiment, the profile manager 54
includes social network handlers for the social network services
supported by the MAP server 12. Thus, for example, if the MAP
server 12 supports user profiles from Facebook.RTM., MySpace.RTM.,
and LinkedIN.RTM., the profile manager 54 may include a Facebook
handler, a MySpace handler, and a LinkedIN handler. The social
network handlers process user profiles to generate user profiles
for the MAP server 12 that include lists of keywords for each of a
number of profile categories. The profile categories may be the
same for each of the social network handlers or different for each
of the social network handlers. Thus, for this example assume that
the user profile of the user 20-1 is from Facebook. The profile
manager 54 uses a Facebook handler to process the user profile of
the user 20-1 to map the user profile of the user 20-1 from
Facebook to a user profile for the MAP server 12 including lists of
keywords for a number of predefined profile categories. For
example, for the Facebook handler, the profile categories may be a
demographic profile category, a social interaction profile
category, a general interests profile category, a music interests
profile category, and a movie interests profile category. As such,
the user profile of the user 20-1 from Facebook may be processed by
the Facebook handler of the profile manager 54 to create a list of
keywords such as, for example, liberal, High School Graduate,
35-44, College Graduate, etc. for the demographic profile category,
a list of keywords such as Seeking Friendship for the social
interaction profile category, a list of keywords such as politics,
technology, photography, books, etc. for the general interests
profile category, a list of keywords including music genres, artist
names, album names, or the like for the music interests profile
category, and a list of keywords including movie titles, actor or
actress names, director names, movie genres, or the like for the
movie interests profile category. In one embodiment, the profile
manager 54 may use natural language processing or semantic
analysis. For example, if the Facebook user profile of the user
20-1 states that the user 20-1 is 20 years old, semantic analysis
may result in the keyword of 18-24 years old being stored in the
user profile of the user 20-1 for the MAP server 12.
[0070] After processing the user profile of the user 20-1, the
profile manager 54 of the MAP server 12 stores the resulting user
profile for the user 20-1 (step 1002E). More specifically, in one
embodiment, the MAP server 12 stores user records for the users
20-1 through 20-N in the datastore 66 (FIG. 2). The user profile of
the user 20-1 is stored in the user record of the user 20-1. The
user record of the user 20-1 includes a unique identifier of the
user 20-1, the user profile of the user 20-1, and, as discussed
below, a current location of the user 20-1. Note that the user
profile of the user 20-1 may be updated as desired. For example, in
one embodiment, the user profile of the user 20-1 is updated by
repeating step 1002 each time the user 20-1 activates the MAP
application 32-1.
[0071] Note that the while the discussion herein focuses on an
embodiment where the user profiles of the users 20-1 through 20-N
are obtained from the one or more profile servers 14, the user
profiles of the users 20-1 through 20-N may be obtained in any
desired manner. For example, in one alternative embodiment, the
user 20-1 may identify one or more favorite websites. The profile
manager 54 of the MAP server 12 may then crawl the one or more
favorite websites of the user 20-1 to obtain keywords appearing in
the one or more favorite websites of the user 20-1. These keywords
may then be stored as the user profile of the user 20-1.
[0072] At some point, a process is performed such that a current
location of the mobile device 18-1 and thus a current location of
the user 20-1 is obtained by the MAP server 12 (step 1004). In this
embodiment, the MAP application 32-1 of the mobile device 18-1
obtains the current location of the mobile device 18-1 from the
location function 36-1 of the mobile device 18-1. The MAP
application 32-1 then provides the current location of the mobile
device 18-1 to the MAP client 30-1, and the MAP client 30-1 then
provides the current location of the mobile device 18-1 to the MAP
server 12 (step 1004A). Note that step 1004A may be repeated
periodically or in response to a change in the current location of
the mobile device 18-1 in order for the MAP application 32-1 to
provide location updates for the user 20-1 to the MAP server
12.
[0073] In response to receiving the current location of the mobile
device 18-1, the location manager 56 of the MAP server 12 stores
the current location of the mobile device 18-1 as the current
location of the user 20-1 (step 1004B). More specifically, in one
embodiment, the current location of the user 20-1 is stored in the
user record of the user 20-1 maintained in the datastore 66 of the
MAP server 12. Note that in the preferred embodiment only the
current location of the user 20-1 is stored in the user record of
the user 20-1. In this manner, the MAP server 12 maintains privacy
for the user 20-1 since the MAP server 12 does not maintain a
historical record of the location of the user 20-1. As discussed
below in detail, historical data maintained by the MAP server 12 is
anonymized in order to maintain the privacy of the users 20-1
through 20-N.
[0074] In addition to storing the current location of the user
20-1, the location manager 56 sends the current location of the
user 20-1 to the location server 16 (step 1004C). In this
embodiment, by providing location updates to the location server
16, the MAP server 12 in return receives location updates for the
user 20-1 from the location server 16. This is particularly
beneficial when the mobile device 18-1 does not permit background
processes, which is the case for the Apple.RTM. iPhone. As such, if
the mobile device 18-1 is an Apple.RTM. iPhone or similar device
that does not permit background processes, the MAP application 32-1
will not be able to provide location updates for the user 20-1 to
the MAP server 12 unless the MAP application 32-1 is active.
[0075] Therefore, when the MAP application 32-1 is not active,
other applications running on the mobile device 18-1 (or some other
device of the user 20-1) may directly or indirectly provide
location updates to the location server 16 for the user 20-1. This
is illustrated in step 1006 where the location server 16 receives a
location update for the user 20-1 directly or indirectly from
another application running on the mobile device 18-1 or an
application running on another device of the user 20-1 (step
1006A). The location server 16 then provides the location update
for the user 20-1 to the MAP server 12 (step 1006B). In response,
the location manager 56 updates and stores the current location of
the user 20-1 in the user record of the user 20-1 (step 1006C). In
this manner, the MAP server 12 is enabled to obtain location
updates for the user 20-1 even when the MAP application 32-1 is not
active at the mobile device 18-1.
[0076] FIG. 5 illustrates the operation of the system 10 of FIGS.
1A and 1B to provide the user profile of the user 20-1 of the
mobile device 18-1 according to another embodiment of the present
disclosure. This discussion is equally applicable to user profiles
of the other users 20-2 through 20-N of the other mobile devices
18-2 through 18-N. First, an authentication process is performed
(step 1100). For authentication, in this embodiment, the mobile
device 18-1 authenticates with the MAP server 12 (step 1100A), and
the MAP server 12 authenticates with the profile server 14 (step
1100B). Preferably, authentication is performed using OpenID or
similar technology. However, authentication may alternatively be
performed using separate credentials (e.g., username and password)
of the user 20-1 for access to the MAP server 12 and the profile
server 14. Assuming that authentication is successful, the profile
server 14 returns an authentication succeeded message to the MAP
server 12 (step 1100C), and the MAP server 12 returns an
authentication succeeded message to the MAP client 30-1 of the
mobile device 18-1 (step 1100D).
[0077] At some point after authentication is complete, a user
profile process is performed such that a user profile of the user
20-1 is obtained from the profile server 14 and delivered to the
MAP server 12 (step 1102). In this embodiment, the profile manager
54 of the MAP server 12 sends a profile request to the profile
server 14 (step 1102A). In response, the profile server 14 returns
the user profile of the user 20-1 to the profile manager 54 of the
MAP server 12 (step 1102B). Note that while in this embodiment the
profile server 14 returns the complete user profile of the user
20-1 to the MAP server 12, in an alternative embodiment, the
profile server 14 may return a filtered version of the user profile
of the user 20-1 to the MAP server 12. The profile server 14 may
filter the user profile of the user 20-1 according to criteria
specified by the user 20-1. For example, the user profile of the
user 20-1 may include demographic information, general interests,
music interests, and movie interests, and the user 20-1 may specify
that the demographic information or some subset thereof is to be
filtered, or removed, before sending the user profile to the MAP
server 12.
[0078] Upon receiving the user profile of the user 20-1, the
profile manager 54 of the MAP server 12 processes the user profile
(step 1102C). More specifically, as discussed above, in the
preferred embodiment, the profile manager 54 includes social
network handlers for the social network services supported by the
MAP server 12. The social network handlers process user profiles to
generate user profiles for the MAP server 12 that include lists of
keywords for each of a number of profile categories. The profile
categories may be the same for each of the social network handlers
or different for each of the social network handlers.
[0079] After processing the user profile of the user 20-1, the
profile manager 54 of the MAP server 12 stores the resulting user
profile for the user 20-1 (step 1102D). More specifically, in one
embodiment, the MAP server 12 stores user records for the users
20-1 through 20-N in the datastore 66 (FIG. 2). The user profile of
the user 20-1 is stored in the user record of the user 20-1. The
user record of the user 20-1 includes a unique identifier of the
user 20-1, the user profile of the user 20-1, and, as discussed
below, a current location of the user 20-1. Note that the user
profile of the user 20-1 may be updated as desired. For example, in
one embodiment, the user profile of the user 20-1 is updated by
repeating step 1102 each time the user 20-1 activates the MAP
application 32-1.
[0080] Note that while the discussion herein focuses on an
embodiment where the user profiles of the users 20-1 through 20-N
are obtained from the one or more profile servers 14, the user
profiles of the users 20-1 through 20-N may be obtained in any
desired manner. For example, in one alternative embodiment, the
user 20-1 may identify one or more favorite websites. The profile
manager 54 of the MAP server 12 may then crawl the one or more
favorite websites of the user 20-1 to obtain keywords appearing in
the one or more favorite websites of the user 20-1. These keywords
may then be stored as the user profile of the user 20-1.
[0081] At some point, a process is performed such that a current
location of the mobile device 18-1 and thus a current location of
the user 20-1 is obtained by the MAP server 12 (step 1104). In this
embodiment, the MAP application 32-1 of the mobile device 18-1
obtains the current location of the mobile device 18-1 from the
location function 36-1 of the mobile device 18-1. The MAP
application 32-1 then provides the current location of the user
20-1 of the mobile device 18-1 to the location server 16 (step
1104A). Note that step 1104A may be repeated periodically or in
response to changes in the location of the mobile device 18-1 in
order to provide location updates for the user 20-1 to the MAP
server 12. The location server 16 then provides the current
location of the user 20-1 to the MAP server 12 (step 1104B). The
location server 16 may provide the current location of the user
20-1 to the MAP server 12 automatically in response to receiving
the current location of the user 20-1 from the mobile device 18-1
or in response to a request from the MAP server 12.
[0082] In response to receiving the current location of the mobile
device 18-1, the location manager 56 of the MAP server 12 stores
the current location of the mobile device 18-1 as the current
location of the user 20-1 (step 1104C). More specifically, in one
embodiment, the current location of the user 20-1 is stored in the
user record of the user 20-1 maintained in the datastore 66 of the
MAP server 12. Note that in the preferred embodiment only the
current location of the user 20-1 is stored in the user record of
the user 20-1. In this manner, the MAP server 12 maintains privacy
for the user 20-1 since the MAP server 12 does not maintain a
historical record of the location of the user 20-1. As discussed
below in detail, historical data maintained by the MAP server 12 is
anonymized in order to maintain the privacy of the users 20-1
through 20-N.
[0083] As discussed above, the use of the location server 16 is
particularly beneficial when the mobile device 18-1 does not permit
background processes, which is the case for the Apple.RTM. iPhone.
As such, if the mobile device 18-1 is an Apple.RTM. iPhone or
similar device that does not permit background processes, the MAP
application 32-1 will not provide location updates for the user
20-1 to the location server 16 unless the MAP application 32-1 is
active. However, other applications running on the mobile device
18-1 (or some other device of the user 20-1) may provide location
updates to the location server 16 for the user 20-1 when the MAP
application 32-1 is not active. This is illustrated in step 1106
where the location server 16 receives a location update for the
user 20-1 from another application running on the mobile device
18-1 or an application running on another device of the user 20-1
(step 1106A). The location server 16 then provides the location
update for the user 20-1 to the MAP server 12 (step 1106B). In
response, the location manager 56 updates and stores the current
location of the user 20-1 in the user record of the user 20-1 (step
1106C). In this manner, the MAP server 12 is enabled to obtain
location updates for the user 20-1 even when the MAP application
32-1 is not active at the mobile device 18-1.
[0084] Using the current locations of the users 20-1 through 20-N
and the user profiles of the users 20-1 through 20-N, the MAP
server 12 can provide a number of features. A first feature that
may be provided by the MAP server 12 is historical storage of
anonymized user profile data by location. This historical storage
of anonymized user profile data by location is performed by the
history manager 58 of the MAP server 12. More specifically, as
illustrated in FIG. 6, in the preferred embodiment, the history
manager 58 maintains lists of users located in a number of
geographic regions, or "location buckets." Preferably, the location
buckets are defined by floor(latitude, longitude) to a desired
resolution. The higher the resolution, the smaller the size of the
location buckets. For example, in one embodiment, the location
buckets are defined by floor(latitude, longitude) to a resolution
of 1/10,000.sup.th of a degree such that the lower left-hand
corners of the squares illustrated in FIG. 6 are defined by the
floor(latitude, longitude) values at a resolution of
1/10,000.sup.th of a degree. In the example of FIG. 6, users are
represented as dots, and location buckets 74 through 90 have lists
of 1, 3, 2, 1, 1, 2, 1, 2, and 3 users, respectively.
[0085] As discussed below in detail, at a predetermined time
interval such as, for example, 15 minutes, the history manager 58
makes a copy of the lists of users in the location buckets,
anonymizes the user profiles of the users in the lists to provide
anonymized user profile data for the corresponding location
buckets, and stores the anonymized user profile data in a number of
history objects. In one embodiment, a history object is stored for
each location bucket having at least one user. In another
embodiment, a quadtree algorithm is used to efficiently create
history objects for geographic regions (i.e., groups of one or more
adjoining location buckets).
[0086] FIG. 7 graphically illustrates a scenario where a user moves
from one location bucket to another, namely, from the location
bucket 76 to the location bucket 78. As discussed below in detail,
assuming that the movement occurs during the time interval between
persistence of the historical data by the history manager 58, the
user is included on both the list for the location bucket 76 and
the list for the location bucket 78. However, the user is flagged
or otherwise marked as inactive for the location bucket 76 and
active for the location bucket 78. As discussed below, after making
a copy of the lists for the location buckets to be used to persist
the historical data, users flagged as inactive are removed from the
lists of users for the location buckets. Thus, in sum, once a user
moves from the location bucket 76 to the location bucket 78, the
user remains in the list for the location bucket 76 until the
predetermined time interval has expired and the anonymized user
profile data is persisted. The user is then removed from the list
for the location bucket 76.
[0087] FIG. 8 is a flow chart illustrating the operation of a
foreground "bucketization" process performed by the history manager
58 to maintain the lists of users for location buckets according to
one embodiment of the present disclosure. First, the history
manager 58 receives a location update for a user (step 1200). For
this discussion, assume that the location update is received for
the user 20-1. The history manager 58 then determines a location
bucket corresponding to the updated location (i.e., the current
location) of the user 20-1 (step 1202). In the preferred
embodiment, the location of the user 20-1 is expressed as latitude
and longitude coordinates, and the history manager 58 determines
the location bucket by determining floor values of the latitude and
longitude coordinates, which can be written as floor(latitude,
longitude) at a desired resolution. As an example, if the latitude
and longitude coordinates for the location of the user 20-1 are
32.24267381553987 and -111.9249213502935, respectively, and the
floor values are to be computed to a resolution of 1/10,000.sup.th
of a degree, then the floor values for the latitude and longitude
coordinates are 32.2426 and -111.9249. The floor values for the
latitude and longitude coordinates correspond to a particular
location bucket.
[0088] After determining the location bucket for the location of
the user 20-1, the history manager 58 determines whether the user
20-1 is new to the location bucket (step 1204). In other words, the
history manager 58 determines whether the user 20-1 is already on
the list of users for the location bucket. If the user 20-1 is new
to the location bucket, the history manager 58 creates an entry for
the user 20-1 in the list of users for the location bucket (step
1206). Returning to step 1204, if the user 20-1 is not new to the
location bucket, the history manager 58 updates the entry for the
user 20-1 in the list of users for the location bucket (step 1208).
At this point, whether proceeding from step 1206 or 1208, the user
20-1 is flagged as active in the list of users for the location
bucket (step 1210).
[0089] The history manager 58 then determines whether the user 20-1
has moved from another location bucket (step 1212). More
specifically, the history manager 58 determines whether the user
20-1 is included in the list of users for another location bucket
and is currently flagged as active in that list. If the user 20-1
has not moved from another location bucket, the process proceeds to
step 1216. If the user 20-1 has moved from another location bucket,
the history manager 58 flags the user 20-1 as inactive in the list
of users for the other location bucket from which the user 20-1 has
moved (step 1214).
[0090] At this point, whether proceeding from step 1212 or 1214,
the history manager 58 determines whether it is time to persist
(step 1216). More specifically, as mentioned above, the history
manager 58 operates to persist history objects at a predetermined
time interval such as, for example, every 15 minutes. Thus, the
history manager 58 determines that it is time to persist if the
predetermined time interval has expired. If it is not time to
persist, the process returns to step 1200 and is repeated for a
next received location update, which will typically be for another
user. If it is time to persist, the history manager 58 creates a
copy of the lists of users for the location buckets and passes the
copy of the lists to an anonymization and storage process (step
1218). In this embodiment, the anonymization and storage process is
a separate process performed by the history manager 58. The history
manager 58 then removes inactive users from the lists of users for
the location buckets (step 1220). The process then returns to step
1200 and is repeated for a next received location update, which
will typically be for another user.
[0091] FIG. 9 is a flow chart illustrating the anonymization and
storage process performed by the history manager 58 at the
predetermined time interval according to one embodiment of the
present disclosure. First, the anonymization and storage process
receives the copy of the lists of users for the location buckets
passed to the anonymization and storage process by the
bucketization process of FIG. 8 (step 1300). Next, anonymization is
performed for each of the location buckets having at least one user
in order to provide anonymized user profile data for the location
buckets (step 1302). Anonymization prevents connecting information
stored in the history objects stored by the history manager 58 back
to the users 20-1 through 20-N or at least substantially increases
a difficulty of connecting information stored in the history
objects stored by the history manager 58 back to the users 20-1
through 20-N. Lastly, the anonymized user profile data for the
location buckets is stored in a number of history objects (step
1304). In one embodiment, a separate history object is stored for
each of the location buckets, where the history object of a
location bucket includes the anonymized user profile data for the
location bucket. In another embodiment, as discussed below, a
quadtree algorithm is used to efficiently store the anonymized user
profile data in a number of history objects such that each history
object stores the anonymized user profile data for one or more
location buckets.
[0092] FIG. 10 graphically illustrates one embodiment of the
anonymization process of step 1302 of FIG. 9. In this embodiment,
anonymization is performed by creating anonymous user records for
the users in the lists of users for the location buckets. The
anonymous user records are not connected back to the users 20-1
through 20-N. More specifically, as illustrated in FIG. 10, each
user in the lists of users for the location buckets has a
corresponding user record 92. The user record 92 includes a unique
user identifier (ID) for the user, the current location of the
user, and the user profile of the user. The user profile includes
keywords for each of a number of profile categories, which are
stored in corresponding profile category records 94-1 through 94-M.
Each of the profile category records 94-1 through 94-M includes a
user ID for the corresponding user which may be the same user ID
used in the user record 92, a category ID, and a list of keywords
for the profile category.
[0093] For anonymization, an anonymous user record 96 is created
from the user record 92. In the anonymous user record 96, the user
ID is replaced with a new user ID that is not connected back to the
user, which is also referred to herein as an anonymous user ID.
This new user ID is different than any other user ID used for
anonymous user records created from the user record of the user for
any previous or subsequent time periods. In this manner, anonymous
user records for a single user created over time cannot be linked
to one another.
[0094] In addition, anonymous profile category records 98-1 through
98-M are created for the profile category records 94-1 through
94-M. In the anonymous profile category records 98-1 through 98-M,
the user ID is replaced with a new user ID, which may be the same
new user ID included in the anonymous user record 96. The anonymous
profile category records 98-1 through 98-M include the same
category IDs and lists of keywords as the corresponding profile
category records 94-1 through 94-M. Note that the location of the
user is not stored in the anonymous user record 96. With respect to
location, it is sufficient that the anonymous user record 96 is
linked to a location bucket.
[0095] In another embodiment, the history manager 58 performs
anonymization in a manner similar to that described above with
respect to FIG. 10. However, in this embodiment, the profile
category records for the group of users in a location bucket, or
the group of users in a number of location buckets representing a
node in a quadtree data structure (see below), may be selectively
randomized among the anonymous user records of those users. In
other words, each anonymous user record would have a user profile
including a selectively randomized set of profile category records
(including keywords) from a cumulative list of profile category
records for all of the users in the group.
[0096] In yet another embodiment, rather than creating anonymous
user records 96 for the users in the lists maintained for the
location buckets, the history manager 58 may perform anonymization
by storing an aggregate user profile for each location bucket, or
each group of location buckets representing a node in a quadtree
data structure (see below). The aggregate user profile may include
a list of all keywords and potentially the number of occurrences of
each keyword in the user profiles of the corresponding group of
users. In this manner, the data stored by the history manager 58 is
not connected back to the users 20-1 through 20-N.
[0097] FIG. 11 is a flow chart illustrating the storing step (step
1304) of FIG. 9 in more detail according to one embodiment of the
present disclosure. First, the history manager 58 processes the
location buckets using a quadtree algorithm to produce a quadtree
data structure, where each node of the quadtree data structure
includes one or more of the location buckets having a combined
number of users that is at most a predefined maximum number of
users (step 1400). The history manager 58 then stores a history
object for each node in the quadtree data structure having at least
one user (step 1402).
[0098] Each history object includes location information, timing
information, data, and quadtree data structure information. The
location information included in the history object defines a
combined geographic area of the location bucket(s) forming the
corresponding node of the quadtree data structure. For example, the
location information may be latitude and longitude coordinates for
a northeast corner of the combined geographic area of the node of
the quadtree data structure and a southwest corner of the combined
geographic area for the node of the quadtree data structure. The
timing information includes information defining a time window for
the history object, which may be, for example, a start time for the
corresponding time interval and an end time for the corresponding
time interval. The data includes the anonymized user profile data
for the users in the list(s) maintained for the location bucket(s)
forming the node of the quadtree data structure for which the
history object is stored. In addition, the data may include a total
number of users in the location bucket(s) forming the node of the
quadtree data structure. Lastly, the quadtree data structure
information includes information defining a quadtree depth of the
node in the quadtree data structure.
[0099] FIG. 12 is a flow chart illustrating a quadtree algorithm
that may be used to process the location buckets to form the
quadtree data structure in step 1400 of FIG. 11 according to one
embodiment of the present disclosure. Initially, a geographic area
served by the MAP server 12 is divided into a number of geographic
regions, each including multiple location buckets. These geographic
regions are also referred to herein as base quadtree regions. The
geographic area served by the MAP server 12 may be, for example, a
city, a state, a country, or the like. Further, the geographic area
may be the only geographic area served by the MAP server 12 or one
of a number of geographic areas served by the MAP server 12.
Preferably, the base quadtree regions have a size of
2.sup.n.times.2.sup.n location buckets, where n is an integer
greater than or equal to 1.
[0100] In order to form the quadtree data structure, the history
manager 58 determines whether there are any more base quadtree
regions to process (step 1500). If there are more base quadtree
regions to process, the history manager 58 sets a current node to
the next base quadtree region to process, which for the first
iteration is the first base quadtree region (step 1502). The
history manager 58 then determines whether the number of users in
the current node is greater than a predefined maximum number of
users and whether a current quadtree depth is less than a maximum
quadtree depth (step 1504). In one embodiment, the maximum quadtree
depth may be reached when the current node corresponds to a single
location bucket. However, the maximum quadtree depth may be set
such that the maximum quadtree depth is reached before the current
node reaches a single location bucket.
[0101] If the number of users in the current node is greater than
the predefined maximum number of users and the current quadtree
depth is less than a maximum quadtree depth, the history manager 58
creates a number of child nodes for the current node (step 1506).
More specifically, the history manager 58 creates a child node for
each quadrant of the current node. The users in the current node
are then assigned to the appropriate child nodes based on the
location buckets in which the users are located (step 1508), and
the current node is then set to the first child node (step 1510).
At this point, the process returns to step 1504 and is
repeated.
[0102] Once the number of users in the current node is not greater
than the predefined maximum number of users or the maximum quadtree
depth has been reached, the history manager 58 determines whether
the current node has any more sibling nodes (step 1512). Sibling
nodes are child nodes of the same parent node. If so, the history
manager 58 sets the current node to the next sibling node of the
current node (step 1514), and the process returns to step 1504 and
is repeated. Once there are no more sibling nodes to process, the
history manager 58 determines whether the current node has a parent
node (step 1516). If so, since the parent node has already been
processed, the history manager 58 determines whether the parent
node has any sibling nodes that need to be processed (step 1518).
If the parent node has any sibling nodes that need to be processed,
the history manager 58 sets the next sibling node of the parent
node to be processed as the current node (step 1520). From this
point, the process returns to step 1504 and is repeated. Returning
to step 1516, if the current node does not have a parent node, the
process returns to step 1500 and is repeated until there are no
more base quadtree regions to process. Once there are no more base
quadtree regions to process, the finished quadtree data structure
is returned to the process of FIG. 11 such that the history manager
58 can then store the history objects for nodes in the quadtree
data structure having at least one user (step 1522).
[0103] FIGS. 13A through 13E graphically illustrate the process of
FIG. 12 for the generation of the quadtree data structure for one
exemplary base quadtree region 100. FIG. 13A illustrates the base
quadtree region 100. As illustrated, the base quadtree region 100
is an 8.times.8 square of location buckets, where each of the small
squares represents a location bucket. First, the history manager 58
determines whether the number of users in the base quadtree region
100 is greater than the predetermined maximum number of users. In
this example, the predetermined maximum number of users is 3. Since
the number of users in the base quadtree region 100 is greater than
3, the history manager 58 divides the base quadtree region 100 into
four child nodes 102-1 through 102-4, as illustrated in FIG.
13B.
[0104] Next, the history manager 58 determines whether the number
of users in the child node 102-1 is greater than the predetermined
maximum, which again for this example is 3. Since the number of
users in the child node 102-1 is greater than 3, the history
manager 58 divides the child node 102-1 into four child nodes 104-1
through 104-4, as illustrated in FIG. 13C. The child nodes 104-1
through 104-4 are children of the child node 102-1. The history
manager 58 then determines whether the number of users in the child
node 104-1 is greater than the predetermined maximum number of
users, which again is 3. Since there are more than 3 users in the
child node 104-1, the history manager 58 further divides the child
node 104-1 into four child nodes 106-1 through 106-N, as
illustrated in FIG. 13D.
[0105] The history manager 58 then determines whether the number of
users in the child node 106-1 is greater than the predetermined
maximum number of users, which again is 3. Since the number of
users in the child node 106-1 is not greater than the predetermined
maximum number of users, the child node 106-1 is identified as a
node for the finished quadtree data structure, and the history
manager 58 proceeds to process the sibling nodes of the child node
106-1, which are the child nodes 106-2 through 106-4. Since the
number of users in each of the child nodes 106-2 through 106-4 is
less than the predetermined maximum number of users, the child
nodes 106-2 through 106-4 are also identified as nodes for the
finished quadtree data structure.
[0106] Once the history manager 58 has finished processing the
child nodes 106-1 through 106-4, the history manager 58 identifies
the parent node of the child nodes 106-1 through 106-4, which in
this case is the child node 104-1. The history manager 58 then
processes the sibling nodes of the child node 104-1, which are the
child nodes 104-2 through 104-4. In this example, the number of
users in each of the child nodes 104-2 through 104-4 is less than
the predetermined maximum number of users. As such, the child nodes
104-2 through 104-4 are identified as nodes for the finished
quadtree data structure.
[0107] Once the history manager 58 has finished processing the
child nodes 104-1 through 104-4, the history manager 58 identifies
the parent node of the child nodes 104-1 through 104-4, which in
this case is the child node 102-1. The history manager 58 then
processes the sibling nodes of the child node 102-1, which are the
child nodes 102-2 through 102-4. More specifically, the history
manager 58 determines that the child node 102-2 includes more than
the predetermined maximum number of users and, as such, divides the
child node 102-2 into four child nodes 108-1 through 108-4, as
illustrated in FIG. 13E. Because the number of users in each of the
child nodes 108-1 through 108-4 is not greater than the
predetermined maximum number of users, the child nodes 108-1
through 108-4 are identified as nodes for the finished quadtree
data structure. Then, the history manager 58 proceeds to process
the child nodes 102-3 and 102-4. Since the number of users in each
of the child nodes 102-3 and 102-4 is not greater than the
predetermined maximum number of users, the child nodes 102-3 and
102-4 are identified as nodes for the finished quadtree data
structure. Thus, at completion, the quadtree data structure for the
base quadtree region 100 includes the child nodes 106-1 through
106-4, the child nodes 104-2 through 104-4, the child nodes 108-1
through 108-4, and the child nodes 102-3 and 102-4, as illustrated
in FIG. 13E.
[0108] As discussed above, the history manager 58 stores a history
object for each of the nodes in the quadtree data structure
including at least one user. As such, in this example, the history
manager 58 stores history objects for the child nodes 106-2 and
106-3, the child nodes 104-2 and 104-4, the child nodes 108-1 and
108-4, and the child node 102-3. However, no history objects are
stored for the nodes that do not have any users (i.e., the child
nodes 106-1 and 106-4, the child node 104-3, the child nodes 108-2
and 108-3, and the child node 102-4).
[0109] FIG. 14 illustrates the operation of the system 10 of FIGS.
1A and 1B wherein a mobile device is enabled to request and receive
historical data from the MAP server 12 according to one embodiment
of the present disclosure. Note that the MAP server 12 may operate
in a similar manner to process requests for historical data from
other devices such as the subscriber device 22, the third-party
server 26, and/or the profile server 14. As illustrated, in this
embodiment, the MAP application 32-1 of the mobile device 18-1
sends a historical request to the MAP client 30-1 of the mobile
device 18-1 (step 1600). In one embodiment, the historical request
identifies either a POI or an AOI and a time window. A POI is a
geographic point whereas an AOI is a geographic area. In one
embodiment, the historical request is for a POI and a time window,
where the POI is a POI corresponding to the current location of the
user 20-1, a POI selected from a list of POIs defined by the user
20-1 of the mobile device 18-1, a POI selected from a list of POIs
defined by the MAP application 32-1 or the MAP server 12, a POI
selected by the user 20-1 from a map, a POI implicitly defined via
a separate application (e.g., POI is implicitly defined as the
location of the nearest Starbucks coffee house in response to the
user 20-1 performing a Google search for "Starbucks"), or the like.
If the POI is selected from a list of POIs, the list of POIs may
include static POIs which may be defined by street addresses or
latitude and longitude coordinates, dynamic POIs which may be
defined as the current locations of one or more friends of the user
20-1, or both.
[0110] In another embodiment, the historical request is for an AOI
and a time window, where the AOI may be an AOI of a geographic area
of a predefined shape and size centered at the current location of
the user 20-1, an AOI selected from a list of AOIs defined by the
user 20-1, an AOI selected from a list of AOIs defined by the MAP
application 32-1 or the MAP server 12, an AOI selected by the user
20-1 from a map, an AOI implicitly defined via a separate
application (e.g., AOI is implicitly defined as an area of a
predefined shape and size centered at the location of the nearest
Starbucks coffee house in response to the user 20-1 performing a
Google search for "Starbucks"), or the like. If the AOI is selected
from a list of AOIs, the list of AOIs may include static AOIs,
dynamic AOIs which may be defined as areas of a predefined shape
and size centered at the current locations of one or more friends
of the user 20-1, or both. Note that the POI or AOI of the
historical request may be selected by the user 20-1 via the MAP
application 32-1. In yet another embodiment, the MAP application
32-1 automatically uses the current location of the user 20-1 as
the POI or as a center point for an AOI of a predefined shape and
size.
[0111] The time window for the historical request may be relative
to the current time. For example, the time window may be the last
hour, the last day, the last week, the last month, or the like.
Alternatively, the time window may be an arbitrary time window
selected by the user 20-1 such as, for example, yesterday from 7
pm-9 pm, last Friday, last week, or the like. Note that while in
this example the historical request includes a single POI or AOI
and a single time window, the historical request may include
multiple POIs or AOIs and/or multiple time windows.
[0112] In one embodiment, the historical request is made in
response to user input from the user 20-1 of the mobile device
18-1. For instance, in one embodiment, the user 20-1 selects either
a POI or an AOI and a time window and then instructs the MAP
application 32-1 to make the historical request by, for example,
selecting a corresponding button on a graphical user interface. In
another embodiment, the historical request is made automatically in
response to some event such as, for example, opening the MAP
application 32-1.
[0113] Upon receiving the historical request from the MAP
application 32-1, the MAP client 30-1 forwards the historical
request to the MAP server 12 (step 1602). Note that the MAP client
30-1 may, in some cases, process the historical request from the
MAP application 32-1 before forwarding the historical request to
the MAP server 12. For example, if the historical request from the
MAP application 32-1 is for multiple POIs/AOIs and/or for multiple
time windows, the MAP client 30-1 may process the historical
request from the MAP application 32-1 to produce multiple
historical requests to be sent to the MAP server 12. For instance,
a separate historical request may be produced for each POI/AOI and
time window combination. However, for this discussion, the
historical request is for a single POI or AOI for a single time
window.
[0114] Upon receiving the historical request from the MAP client
30-1, the MAP server 12 processes the historical request (step
1604). More specifically, the historical request is processed by
the history manager 58 of the MAP server 12. First, the history
manager 58 obtains history objects that are relevant to the
historical request from the datastore 66 of the MAP server 12. The
relevant history objects are those recorded for locations relevant
to the POI or AOI and the time window for the historical request.
The history manager 58 then processes the relevant history objects
to provide historical aggregate profile data for the POI or AOI. In
this embodiment, the historical aggregate profile data is based on
the user profiles of the anonymous user records in the relevant
history objects as compared to the user profile of the user 20-1 or
a select subset thereof. In another embodiment, the historical
aggregate profile data is based on the user profiles of the
anonymous user records in the relevant history objects as compared
to a target user profile defined or otherwise specified by the user
20-1 or as compared to one another. Once the MAP server 12 has
processed the historical request, the MAP server 12 returns the
resulting historical aggregate profile data to the MAP client 30-1
(step 1606). Upon receiving the historical aggregate profile data,
the MAP client 30-1 passes the historical aggregate profile data to
the MAP application 32-1 (step 1608). The MAP application 32-1 then
presents the historical aggregate profile data to the user 20-1
(step 1610).
[0115] FIG. 15 begins a discussion of the operation of the crowd
analyzer 60 to form crowds of users according to one embodiment of
the present disclosure. Specifically, FIG. 15 is a flow chart for a
spatial crowd formation process according to one embodiment of the
present disclosure. Note that, in one embodiment, this process is
performed in response to a request for crowd data for a POI or an
AOI. In another embodiment, this process may be performed
proactively by the crowd analyzer 60 as, for example, a background
process.
[0116] First, the crowd analyzer 60 establishes a bounding box for
the crowd formation process (step 1700). Note that while a bounding
box is used in this example, other geographic shapes may be used to
define a bounding region for the crowd formation process (e.g., a
bounding circle). In one embodiment, if crowd formation is
performed in response to a specific request, the bounding box is
established based on the POI or the AOI of the request. If the
request is for a POI, then the bounding box is a geographic area of
a predetermined size centered at the POI. If the request is for an
AOI, the bounding box is the AOI. Alternatively, if the crowd
formation process is performed proactively, the bounding box is a
bounding box of a predefined size.
[0117] The crowd analyzer 60 then creates a crowd for each
individual user in the bounding box (step 1702). More specifically,
the crowd analyzer 60 queries the datastore 66 of the MAP server 12
to identify users currently located within the bounding box. Then,
a crowd of one user is created for each user currently located
within the bounding box. Next, the crowd analyzer 60 determines the
two closest crowds in the bounding box (step 1704) and determines a
distance between the two crowds (step 1706). The distance between
the two crowds is a distance between crowd centers of the two
crowds. Note that the crowd center of a crowd of one is the current
location of the user in the crowd. The crowd analyzer 60 then
determines whether the distance between the two crowds is less than
an optimal inclusion distance (step 1708). In this embodiment, the
optimal inclusion distance is a predefined static distance. If the
distance between the two crowds is less than the optimal inclusion
distance, the crowd analyzer 60 combines the two crowds (step 1710)
and computes a new crowd center for the resulting crowd (step
1712). The crowd center may be computed based on the current
locations of the users in the crowd using a center of mass
algorithm. At this point the process returns to step 1704 and is
repeated until the distance between the two closest crowds is not
less than the optimal inclusion distance. At that point, the crowd
analyzer 60 discards any crowds with less than three users (step
1714). Note that throughout this disclosure crowds are only
maintained if the crowds include three or more users. However,
while three users is the preferred minimum number of users in a
crowd, the present disclosure is not limited thereto. The minimum
number of users in a crowd may be defined as any number greater
than or equal to two users.
[0118] FIGS. 16A through 16D graphically illustrate the crowd
formation process of FIG. 15 for an exemplary bounding box 110. In
FIGS. 16A through 16D, crowds are noted by dashed circles, and the
crowd centers are noted by cross-hairs (+). As illustrated in FIG.
16A, initially, the crowd analyzer 60 creates crowds 112 through
120 for the users in the geographic area, where, at this point,
each of the crowds 112 through 120 includes one user. The current
locations of the users are the crowd centers of the crowds 112
through 120. Next, the crowd analyzer 60 determines the two closest
crowds and a distance between the two closest crowds. In this
example, at this point, the two closest crowds are crowds 114 and
116, and the distance between the two closest crowds 114 and 116 is
less than the optimal inclusion distance. As such, the two closest
crowds 114 and 116 are combined by merging crowd 116 into crowd
114, and a new crowd center (+) is computed for the crowd 114, as
illustrated in FIG. 16B. Next, the crowd analyzer 60 again
determines the two closest crowds, which are now crowds 112 and
114. The crowd analyzer 60 then determines a distance between the
crowds 112 and 114. Since the distance is less than the optimal
inclusion distance, the crowd analyzer 60 combines the two crowds
112 and 114 by merging the crowd 112 into the crowd 114, and a new
crowd center (+) is computed for the crowd 114, as illustrated in
FIG. 16C. At this point, there are no more crowds separated by less
than the optimal inclusion distance. As such, the crowd analyzer 60
discards crowds having less than three users, which in this example
are crowds 118 and 120. As a result, at the end of the crowd
formation process, the crowd 114 has been formed with three users,
as illustrated in FIG. 16D.
[0119] FIGS. 17A through 17D illustrate a flow chart for a spatial
crowd formation process according to another embodiment of the
present disclosure. In this embodiment, the spatial crowd formation
process is triggered in response to receiving a location update for
one of the users 20-1 through 20-N and is preferably repeated for
each location update received for the users 20-1 through 20-N. As
such, first, the crowd analyzer 60 receives a location update, or a
new location, for a user (step 1800). Assume that, for this
example, the location update is received for the user 20-1. In
response, the crowd analyzer 60 retrieves an old location of the
user 20-1, if any (step 1802). The old location is the current
location of the user 20-1 prior to receiving the new location. The
crowd analyzer 60 then creates a new bounding box of a
predetermined size centered at the new location of the user 20-1
(step 1804) and an old bounding box of a predetermined size
centered at the old location of the user 20-1, if any (step 1806).
The predetermined size of the new and old bounding boxes may be any
desired size. As one example, the predetermined size of the new and
old bounding boxes is 40 meters by 40 meters. Note that if the user
20-1 does not have an old location (i.e., the location received in
step 1800 is the first location received for the user 20-1), then
the old bounding box is essentially null. Also note that while
bounding "boxes" are used in this example, the bounding areas may
be of any desired shape.
[0120] Next, the crowd analyzer 60 determines whether the new and
old bounding boxes overlap (step 1808). If so, the crowd analyzer
60 creates a bounding box encompassing the new and old bounding
boxes (step 1810). For example, if the new and old bounding boxes
are 40.times.40 meter regions and a 1.times.1 meter square at the
northeast corner of the new bounding box overlaps a 1.times.1 meter
square at the southwest corner of the old bounding box, the crowd
analyzer 60 may create a 79.times.79 meter square bounding box
encompassing both the new and old bounding boxes.
[0121] The crowd analyzer 60 then determines the individual users
and crowds relevant to the bounding box created in step 1810 (step
1812). The crowds relevant to the bounding box are crowds that are
within or overlap the bounding box (e.g., have at least one user
located within the bounding box). The individual users relevant to
the bounding box are users that are currently located within the
bounding box and not already part of a crowd. Next, the crowd
analyzer 60 computes an optimal inclusion distance for individual
users based on user density within the bounding box (step 1814).
More specifically, in one embodiment, the optimal inclusion
distance for individuals, which is also referred to herein as an
initial optimal inclusion distance, is set according to the
following equation:
initial_optimal _inclusion _dist = a A BoundingBox number_of _users
, ##EQU00001##
where a is a number between 0 and 1, A.sub.BoundingBox is an area
of the bounding box, and number_of_users is the total number of
users in the bounding box. The total number of users in the
bounding box includes both individual users that are not already in
a crowd and users that are already in a crowd. In one embodiment, a
is 2/3.
[0122] The crowd analyzer 60 then creates a crowd for each
individual user within the bounding box that is not already
included in a crowd and sets the optimal inclusion distance for the
crowds to the initial optimal inclusion distance (step 1816). At
this point, the process proceeds to FIG. 17B where the crowd
analyzer 60 analyzes the crowds relevant to the bounding box to
determine whether any of the crowd members (i.e., users in the
crowds) violate the optimal inclusion distance of their crowds
(step 1818). Any crowd member that violates the optimal inclusion
distance of his or her crowd is then removed from that crowd (step
1820). The crowd analyzer 60 then creates a crowd of one user for
each of the users removed from their crowds in step 1820 and sets
the optimal inclusion distance for the newly created crowds to the
initial optimal inclusion distance (step 1822).
[0123] Next, the crowd analyzer 60 determines the two closest
crowds for the bounding box (step 1824) and a distance between the
two closest crowds (step 1826). The distance between the two
closest crowds is the distance between the crowd centers of the two
closest crowds. The crowd analyzer 60 then determines whether the
distance between the two closest crowds is less than the optimal
inclusion distance of a larger of the two closest crowds (step
1828). If the two closest crowds are of the same size (i.e., have
the same number of users), then the optimal inclusion distance of
either of the two closest crowds may be used. Alternatively, if the
two closest crowds are of the same size, the optimal inclusion
distances of both of the two closest crowds may be used such that
the crowd analyzer 60 determines whether the distance between the
two closest crowds is less than the optimal inclusion distances of
both of the two closest crowds. As another alternative, if the two
closest crowds are of the same size, the crowd analyzer 60 may
compare the distance between the two closest crowds to an average
of the optimal inclusion distances of the two closest crowds.
[0124] If the distance between the two closest crowds is not less
than the optimal inclusion distance, the process proceeds to step
1838. If the distance between the two closest crowds is less than
the optimal inclusion distance, the two closest crowds are combined
or merged (step 1830), and a new crowd center for the resulting
crowd is computed (step 1832). Again, a center of mass algorithm
may be used to compute the crowd center of a crowd. In addition, a
new optimal inclusion distance for the resulting crowd is computed
(step 1834). In one embodiment, the new optimal inclusion distance
for the resulting crowd is computed as:
average = 1 n + 1 ( initial_optimal _inclusion _dist + i = 1 n d i
) , optimal_inclusion _dist = average + ( 1 n i = 1 n ( d i -
average ) 2 ) , ##EQU00002##
where n is the number of users in the crowd and d.sub.i is a
distance between the ith user and the crowd center. In other words,
the new optimal inclusion distance is computed as the average of
the initial optimal inclusion distance and the distances between
the users in the crowd and the crowd center plus one standard
deviation.
[0125] At this point, the crowd analyzer 60 determines whether a
maximum number of iterations have been performed (step 1836). The
maximum number of iterations is a predefined number that ensures
that the crowd formation process does not indefinitely loop over
steps 1818 through 1834 or loop over steps 1818 through 1834 more
than a desired maximum number of times. If the maximum number of
iterations has not been reached, the process returns to step 1818
and is repeated until either the distance between the two closest
crowds is not less than the optimal inclusion distance of the
larger crowd or the maximum number of iterations has been reached.
At that point, the crowd analyzer 60 discards crowds with less than
three users, or members (step 1838) and the process ends.
[0126] Returning to step 1808 in FIG. 17A, if the new and old
bounding boxes do not overlap, the process proceeds to FIG. 17C and
the bounding box to be processed is set to the old bounding box
(step 1840). In general, the crowd analyzer 60 then processes the
old bounding box in much the same manner as described above with
respect to steps 1812 through 1838. More specifically, the crowd
analyzer 60 determines the individual users and crowds relevant to
the bounding box (step 1842). The crowds relevant to the bounding
box are crowds that are within or overlap the bounding box (e.g.,
have at least one user located within the bounding box). The
individual users relevant to the bounding box are users that are
currently located within the bounding box and not already part of a
crowd. Next, the crowd analyzer 60 computes an optimal inclusion
distance for individual users based on user density within the
bounding box (step 1844). More specifically, in one embodiment, the
optimal inclusion distance for individuals, which is also referred
to herein as an initial optimal inclusion distance, is set
according to the following equation:
initial_optimal _inclusion _dist = a A BoundingBox number_of _users
, ##EQU00003##
where a is a number between 0 and 1, A.sub.BoundingBox is an area
of the bounding box, and number_of_users is the total number of
users in the bounding box. The total number of users in the
bounding box includes both individual users that are not already in
a crowd and users that are already in a crowd. In one embodiment, a
is 2/3.
[0127] The crowd analyzer 60 then creates a crowd of one user for
each individual user within the bounding box that is not already
included in a crowd and sets the optimal inclusion distance for the
crowds to the initial optimal inclusion distance (step 1846). At
this point, the crowd analyzer 60 analyzes the crowds for the
bounding box to determine whether any crowd members (i.e., users in
the crowds) violate the optimal inclusion distance of their crowds
(step 1848). Any crowd member that violates the optimal inclusion
distance of his or her crowd is then removed from that crowd (step
1850). The crowd analyzer 60 then creates a crowd of one user for
each of the users removed from their crowds in step 1850 and sets
the optimal inclusion distance for the newly created crowds to the
initial optimal inclusion distance (step 1852).
[0128] Next, the crowd analyzer 60 determines the two closest
crowds in the bounding box (step 1854) and a distance between the
two closest crowds (step 1856). The distance between the two
closest crowds is the distance between the crowd centers of the two
closest crowds. The crowd analyzer 60 then determines whether the
distance between the two closest crowds is less than the optimal
inclusion distance of a larger of the two closest crowds (step
1858). If the two closest crowds are of the same size (i.e., have
the same number of users), then the optimal inclusion distance of
either of the two closest crowds may be used. Alternatively, if the
two closest crowds are of the same size, the optimal inclusion
distances of both of the two closest crowds may be used such that
the crowd analyzer 60 determines whether the distance between the
two closest crowds is less than the optimal inclusion distances of
both of the two closest crowds. As another alternative, if the two
closest crowds are of the same size, the crowd analyzer 60 may
compare the distance between the two closest crowds to an average
of the optimal inclusion distances of the two closest crowds.
[0129] If the distance between the two closest crowds is less than
the optimal inclusion distance, the two closest crowds are combined
or merged (step 1860), and a new crowd center for the resulting
crowd is computed (step 1862). Again, a center of mass algorithm
may be used to compute the crowd center of a crowd. In addition, a
new optimal inclusion distance for the resulting crowd is computed
(step 1864). As discussed above, in one embodiment, the new optimal
inclusion distance for the resulting crowd is computed as:
average = 1 n + 1 ( initial_optimal _inclusion _dist + i = 1 n d i
) , optimal_inclusion _dist = average + ( 1 n i = 1 n ( d i -
average ) 2 ) , ##EQU00004##
where n is the number of users in the crowd and d.sub.i is a
distance between the ith user and the crowd center. In other words,
the new optimal inclusion distance is computed as the average of
the initial optimal inclusion distance and the distances between
the users in the crowd and the crowd center plus one standard
deviation.
[0130] At this point, the crowd analyzer 60 determines whether a
maximum number of iterations have been performed (step 1866). If
the maximum number of iterations has not been reached, the process
returns to step 1848 and is repeated until either the distance
between the two closest crowds is not less than the optimal
inclusion distance of the larger crowd or the maximum number of
iterations has been reached. At that point, the crowd analyzer 60
discards crowds with less than three users, or members (step 1868).
The crowd analyzer 60 then determines whether the crowd formation
process for the new and old bounding boxes is done (step 1870). In
other words, the crowd analyzer 60 determines whether both the new
and old bounding boxes have been processed. If not, the bounding
box is set to the new bounding box (step 1872), and the process
returns to step 1842 and is repeated for the new bounding box. Once
both the new and old bounding box have been processed, the crowd
formation process ends.
[0131] FIGS. 18A through 18D graphically illustrate the crowd
formation process of FIGS. 17A through 17D for a scenario where the
crowd formation process is triggered by a location update for a
user having no old location. In this scenario, the crowd analyzer
60 creates a new bounding box 122 for the new location of the user,
and the new bounding box 122 is set as the bounding box to be
processed for crowd formation. Then, as illustrated in FIG. 18A,
the crowd analyzer 60 identifies all individual users currently
located within the bounding box 122 and all crowds located within
or overlapping the bounding box. In this example, crowd 124 is an
existing crowd relevant to the bounding box 122. Crowds are
indicated by dashed circles, crowd centers are indicated by
cross-hairs (+), and users are indicated as dots. Next, as
illustrated in FIG. 18B, the crowd analyzer 60 creates crowds 126
through 130 of one user for the individual users, and the optional
inclusion distances of the crowds 126 through 130 are set to the
initial optimal inclusion distance. As discussed above, the initial
optimal inclusion distance is computed by the crowd analyzer 60
based on a density of users within the bounding box 122.
[0132] The crowd analyzer 60 then identifies the two closest crowds
126 and 128 in the bounding box 122 and determines a distance
between the two closest crowds 126 and 128. In this example, the
distance between the two closest crowds 126 and 128 is less than
the optimal inclusion distance. As such, the two closest crowds 126
and 128 are merged and a new crowd center and new optimal inclusion
distance are computed, as illustrated in FIG. 18C. The crowd
analyzer 60 then repeats the process such that the two closest
crowds 126 and 130 in the bounding box 122 are again merged, as
illustrated in FIG. 18D. At this point, the distance between the
two closest crowds 124 and 126 is greater than the appropriate
optimal inclusion distance. As such, the crowd formation process is
complete.
[0133] FIGS. 19A through 19F graphically illustrate the crowd
formation process of FIGS. 17A through 17D for a scenario where the
new and old bounding boxes overlap. As illustrated in FIG. 19A, a
user moves from an old location to a new location, as indicated by
an arrow. The crowd analyzer 60 receives a location update for the
user giving the new location of the user. In response, the crowd
analyzer 60 creates an old bounding box 132 for the old location of
the user and a new bounding box 134 for the new location of the
user. Crowd 136 exists in the old bounding box 132, and crowd 138
exists in the new bounding box 134.
[0134] Since the old bounding box 132 and the new bounding box 134
overlap, the crowd analyzer 60 creates a bounding box 140 that
encompasses both the old bounding box 132 and the new bounding box
134, as illustrated in FIG. 19B. In addition, the crowd analyzer 60
creates crowds 142 through 148 for individual users currently
located within the bounding box 140. The optimal inclusion
distances of the crowds 142 through 148 are set to the initial
optimal inclusion distance computed by the crowd analyzer 60 based
on the density of users in the bounding box 140.
[0135] Next, the crowd analyzer 60 analyzes the crowds 136, 138,
and 142 through 148 to determine whether any members of the crowds
136, 138, and 142 through 148 violate the optimal inclusion
distances of the crowds 136, 138, and 142 through 148. In this
example, as a result of the user leaving the crowd 136 and moving
to his new location, both of the remaining members of the crowd 136
violate the optimal inclusion distance of the crowd 136. As such,
the crowd analyzer 60 removes the remaining users from the crowd
136 and creates crowds 150 and 152 of one user each for those
users, as illustrated in FIG. 19C.
[0136] The crowd analyzer 60 then identifies the two closest crowds
in the bounding box 140, which in this example are the crowds 146
and 148. Next, the crowd analyzer 60 computes a distance between
the two crowds 146 and 148. In this example, the distance between
the two crowds 146 and 148 is less than the initial optimal
inclusion distance and, as such, the two crowds 146 and 148 are
combined. In this example, crowds are combined by merging the
smaller crowd into the larger crowd. Since the two crowds 146 and
148 are of the same size, the crowd analyzer 60 merges the crowd
148 into the crowd 146, as illustrated in FIG. 19D. A new crowd
center and new optimal inclusion distance are then computed for the
crowd 146.
[0137] At this point, the crowd analyzer 60 repeats the process and
determines that the crowds 138 and 144 are now the two closest
crowds. In this example, the distance between the two crowds 138
and 144 is less than the optimal inclusion distance of the larger
of the two crowds 138 and 144, which is the crowd 138. As such, the
crowd 144 is merged into the crowd 138 and a new crowd center and
optimal inclusion distance are computed for the crowd 138, as
illustrated in FIG. 19E. At this point, there are no two crowds
closer than the optimal inclusion distance of the larger of the two
crowds. As such, the crowd analyzer 60 discards any crowds having
less than three members, as illustrated in FIG. 19F. In this
example, the crowds 142, 146, 150, and 152 have less than three
members and are therefore removed. The crowd 138 has three or more
members and, as such, is not removed. At this point, the crowd
formation process is complete.
[0138] FIGS. 20A through 20E graphically illustrate the crowd
formation process of FIGS. 17A through 17D in a scenario where the
new and old bounding boxes do not overlap. As illustrated in FIG.
20A, in this example, the user moves from an old location to a new
location. The crowd analyzer 60 creates an old bounding box 154 for
the old location of the user and a new bounding box 156 for the new
location of the user. Crowds 158 and 160 exist in the old bounding
box 154, and crowd 162 exists in the new bounding box 156. In this
example, since the old and new bounding boxes 154 and 156 do not
overlap, the crowd analyzer 60 processes the old and new bounding
boxes 154 and 156 separately.
[0139] More specifically, as illustrated in FIG. 20B, as a result
of the movement of the user from the old location to the new
location, the remaining users in the crowd 158 no longer satisfy
the optimal inclusion distance for the crowd 158. As such, the
remaining users in the crowd 158 are removed from the crowd 158,
and crowds 164 and 166 of one user each are created for the removed
users as shown in FIG. 20C. In this example, no two crowds in the
old bounding box 154 are close enough to be combined. As such,
processing of the old bounding box 154 is complete, and the crowd
analyzer 60 proceeds to process the new bounding box 156.
[0140] As illustrated in FIG. 20D, processing of the new bounding
box 156 begins by the crowd analyzer 60 creating a crowd 168 of one
user for the user. The crowd analyzer 60 then identifies the crowds
162 and 168 as the two closest crowds in the new bounding box 156
and determines a distance between the two crowds 162 and 168. In
this example, the distance between the two crowds 162 and 168 is
less than the optimal inclusion distance of the larger crowd, which
is the crowd 162. As such, the crowd analyzer 60 combines the
crowds 162 and 168 by merging the crowd 168 into the crowd 162, as
illustrated in FIG. 20E. A new crowd center and new optimal
inclusion distance are then computed for the crowd 162. At this
point, the crowd formation process is complete.
[0141] Before proceeding, a variation of the spatial formation
process discussed above with respect to FIGS. 17A through 17D, 18A
through 18D, 19A through 19F, and 20A through 20E will be
described. In this alternative embodiment, a location accuracy of
the location update from the user received in step 1800 is
considered. More specifically, in step 1800, the location update
received by the MAP server 12 includes the updated location of the
user 20-1 as well as a location accuracy for the location of the
user 20-1, which may be expressed as, for example, a radius in
meters from the location of the user 20-1. In the embodiment where
the location of the user 20-1 is obtained from a GPS receiver of
the mobile device 18-1, the location accuracy of the location of
the user 20-1 may be provided by the GPS receiver or derived from
data from the GPS receiver as will be appreciated by one having
ordinary skill in the art.
[0142] Then, in steps 1802 and 1804, sizes of the new and old
bounding boxes centered at the new and old locations of the user
20-1 are set as a function of the location accuracy of the new and
old locations of the user 20-1. If the new location of the user
20-1 is inaccurate, then the new bounding box will be large. If the
new location of the user 20-1 is accurate, then the new bounding
box will be small. For example, the length and width of the new
bounding box may be set to M times the location accuracy of the new
location of the user 20-1, where the location accuracy is expressed
as a radius in meters from the new location of the user 20-1. The
number M may be any desired number. For example, the number M may
be 5. In a similar manner, the location accuracy of the old
location of the user 20-1 may be used to set the length and width
of the old bounding box.
[0143] In addition, the location accuracy may be considered when
computing the initial optimal inclusion distances used for crowds
of one user in steps 1814 and 1844. As discussed above, the initial
optimal inclusion distance is computed based on the following
equation:
initial_optimal _inclusion _dist = a A BoundingBox number_of _users
, ##EQU00005##
where a is a number between 0 and 1, A.sub.BoundingBox is an area
of the bounding box, and number_of_users is the total number of
users in the bounding box. The total number of users in the
bounding box includes both individual users that are not already in
a crowd and users that are already in a crowd. In one embodiment, a
is 2/3. However, if the computed initial optimal inclusion distance
is less than the location accuracy of the current location of the
individual user in a crowd, then the location accuracy, rather than
the computed value, is used for the initial optimal inclusion
distance for that crowd. As such, as location accuracy decreases,
crowds become larger and more inclusive. In contrast, as location
accuracy increases, crowds become smaller and less inclusive. In
other words, the granularity with which crowds are formed is a
function of the location accuracy.
[0144] Likewise, when new optimal inclusion distances for crowds
are recomputed in steps 1834 and 1864, location accuracy may also
be considered. As discussed above, the new optimal inclusion
distance may first be computed based on the following equation:
average = 1 n + 1 ( initial_optimal _inclusion _dist + i = 1 n d i
) , optimial_inclusion _dist = average + ( 1 n i = 1 n ( d i -
average ) 2 ) , ##EQU00006##
where n is the number of users in the crowd and d.sub.i is a
distance between the ith user and the crowd center. In other words,
the new optimal inclusion distance is computed as the average of
the initial optimal inclusion distance and the distances between
the users in the crowd and the crowd center plus one standard
deviation. However, if the computed value for the new optimal
inclusion distance is less than an average location accuracy of the
users in the crowd, the average location accuracy of the users in
the crowd, rather than the computed value, is used as the new
optimal inclusion distance.
[0145] FIG. 21 illustrates the operation of the system 10 of FIGS.
1A and 1B to enable the mobile devices 18-1 through 18-N to request
crowd data for currently formed crowds according to one embodiment
of the present disclosure. Note that while in this example the
request is initiated by the MAP application 32-1 of the mobile
device 18-1, this discussion is equally applicable to the MAP
applications 32-2 through 32-N of the other mobile devices 18-2
through 18-N. In addition, in a similar manner, requests may be
received from the third-party applications 34-1 through 34-N. Still
further, the MAP server 12 may process crowd requests from other
devices such as the subscriber device 22, the third-party server
26, and/or the profile server 14.
[0146] First, the MAP application 32-1 sends a crowd request to the
MAP client 30-1 (step 1900). The crowd request is a request for
crowd data for crowds currently formed near a specified POI or
within a specified AOI. The crowd request may be initiated by the
user 20-1 of the mobile device 18-1 via the MAP application 32-1 or
may be initiated automatically by the MAP application 32-1 in
response to an event such as, for example, start-up of the MAP
application 32-1, movement of the user 20-1, or the like. In one
embodiment, the crowd request is for a POI, where the POI is a POI
corresponding to the current location of the user 20-1, a POI
selected from a list of POIs defined by the user 20-1, a POI
selected from a list of POIs defined by the MAP application 32-1 or
the MAP server 12, a POI selected by the user 20-1 from a map, a
POI implicitly defined via a separate application (e.g., POI is
implicitly defined as the location of the nearest Starbucks coffee
house in response to the user 20-1 performing a Google search for
"Starbucks"), or the like. If the POI is selected from a list of
POIs, the list of POIs may include static POIs which may be defined
by street addresses or latitude and longitude coordinates, dynamic
POIs which may be defined as the current locations of one or more
friends of the user 20-1, or both. Note that in some embodiments,
the user 20-1 may be enabled to define a POI by selecting a crowd
center of a crowd as a POI, where the POI would thereafter remain
static at that point and would not follow the crowd.
[0147] In another embodiment, the crowd request is for an AOI,
where the AOI may be an AOI of a predefined shape and size centered
at the current location of the user 20-1, an AOI selected from a
list of AOIs defined by the user 20-1, an AOI selected from a list
of AOIs defined by the MAP application 32-1 or the MAP server 12,
an AOI selected by the user 20-1 from a map, an AOI implicitly
defined via a separate application (e.g., AOI is implicitly defined
as an area of a predefined shape and size centered at the location
of the nearest Starbucks coffee house in response to the user 20-1
performing a Google search for "Starbucks"), or the like. If the
AOI is selected from a list of AOIs, the list of AOIs may include
static AOIs, dynamic AOIs which may be defined as areas of a
predefined shape and size centered at the current locations of one
or more friends of the user 20-1, or both. Note that in some
embodiments, the user 20-1 may be enabled to define an AOI by
selecting a crowd such that an AOI is created of a predefined shape
and size centered at the crowd center of the selected crowd. The
AOI would thereafter remain static and would not follow the crowd.
The POI or the AOI of the crowd request may be selected by the user
20-1 via the MAP application 32-1. In yet another embodiment, the
MAP application 32-1 automatically uses the current location of the
user 20-1 as the POI or as a center point for an AOI of a
predefined shape and size.
[0148] Upon receiving the crowd request, the MAP client 30-1
forwards the crowd request to the MAP server 12 (step 1902). Note
that in some embodiments, the MAP client 30-1 may process the crowd
request before forwarding the crowd request to the MAP server 12.
For example, in some embodiments, the crowd request may include
more than one POI or more than one AOI. As such, the MAP client
30-1 may generate a separate crowd request for each POI or each
AOI.
[0149] In response to receiving the crowd request from the MAP
client 30-1, the MAP server 12 identifies one or more crowds
relevant to the crowd request (step 1904). More specifically, in
one embodiment, the crowd analyzer 60 performs a crowd formation
process such as that described above in FIG. 15 to form one or more
crowds relevant to the POI or the AOI of the crowd request. In
another embodiment, the crowd analyzer 60 proactively forms crowds
using a process such as that described above in FIGS. 17A through
17D and stores corresponding crowd records in the datastore 66 of
the MAP server 12. Then, rather than forming the relevant crowds in
response to the crowd request, the crowd analyzer 60 queries the
datastore 66 to identify the crowds that are relevant to the crowd
request. The crowds relevant to the crowd request may be those
crowds within or intersecting a bounding region, such as a bounding
box, for the crowd request. If the crowd request is for a POI, the
bounding region is a geographic region of a predefined shape and
size centered at the POI. If the crowd request is for an AOI, the
bounding region is the AOI.
[0150] Once the crowd analyzer 60 has identified the crowds
relevant to the crowd request, the MAP server 12 generates crowd
data for the identified crowds (step 1906). As discussed below in
detail, the crowd data for the identified crowds may include
aggregate profiles for the crowds, information characterizing the
crowds, or both. In addition, the crowd data may include spatial
information defining the locations of the crowds, the number of
users in the crowds, the amount of time the crowds have been
located at or near the POI or within the AOI of the crowd request,
or the like. The MAP server 12 then returns the crowd data to the
MAP client 30-1 (step 1908).
[0151] Upon receiving the crowd data, the MAP client 30-1 forwards
the crowd data to the MAP application 32-1 (step 1910). Note that
in some embodiments the MAP client 30-1 may process the crowd data
before sending the crowd data to the MAP application 32-1. The MAP
application 32-1 then presents the crowd data to the user 20-1
(step 1912). The manner in which the crowd data is presented
depends on the particular implementation of the MAP application
32-1. In one embodiment, the crowd data is overlaid upon a map. For
example, the crowds may be represented by corresponding indicators
overlaid on a map. The user 20-1 may then select a crowd in order
to view additional crowd data regarding that crowd such as, for
example, the aggregate profile of that crowd, characteristics of
that crowd, or the like.
[0152] Note that in one embodiment, the MAP application 32-1 may
operate to roll-up the aggregate profiles for multiple crowds into
a rolled-up aggregate profile for those crowds. The rolled-up
aggregate profile may be the average of the aggregate profiles of
the crowds. For example, the MAP application 32-1 may roll-up the
aggregate profiles for multiple crowds at a POI and present the
rolled-up aggregate profile for the multiple crowds at the POI to
the user 20-1. In a similar manner, the MAP application 32-1 may
provide a rolled-up aggregate profile for an AOI. In another
embodiment, the MAP server 12 may roll-up crowds for a POI or an
AOI and provide the rolled-up aggregate profile in addition to or
as an alternative to the aggregate profiles for the individual
crowds.
[0153] FIGS. 22 through 31 describe the operation of the profile
augmentation function 40 of FIGS. 1A and 1B according to several
different embodiments of the present disclosure. More specifically,
FIG. 22 illustrates the operation of the profile augmentation
function 40 to augment a user profile of a subject user based on
aggregate profile data for a crowd of users located at or near a
current location of the subject user according to one embodiment of
the present disclosure. First, the profile augmentation function 40
gets, or obtains, a current location of a subject user (step 2000).
Depending on the particular embodiment, the subject user may be a
system-user, which is one of the users 20-1 through 20-N of the
mobile devices 18-1 through 18-N or the subscriber 24 of the
subscriber device 22, or a third-party user, which may be a user
associated with the profile server 14 or the third-party server 26
that is not one of the system-users. The current location of the
subject user may be obtained using any suitable technique. For
example, if the subject user is user 20-1, the current location of
the user 20-1 is preferably obtained from the mobile device 18-1 or
the location server 16. As another example, if the subject user is
a third-party user, the current location of the third-party user
may be obtained from a location-aware device of the third-party
user.
[0154] Next, the profile augmentation function 40 obtains an
aggregate profile for a crowd of users currently located at or near
the current location of the subject user (step 2002). Crowds of
users currently located at or near the current location of the
subject user are referred to herein as crowds that are currently
located at locations that are relevant to the current location of
the subject user. More specifically, depending on the particular
implementation, the crowd currently located at or near the current
location of the subject user is a crowd in which the subject user
is included, a crowd closest to the current location of the subject
user, or a crowd that is within a geographic region of a predefined
shape and size encompassing (e.g., centered at) the current
location of the subject user. The aggregate profile of the crowd is
preferably generated by comparing the user profiles of the users in
the crowd to one another, and the aggregate profile of the crowd
preferably includes a number of keywords and, for each keyword, a
number of user matches, or occurrences, for that keyword in the
user profiles of the users in the crowd. The profile augmentation
function 40 then augments a user profile of the subject user based
on the aggregate profile of the crowd (step 2004).
[0155] FIG. 23 illustrates step 2004 of FIG. 22 in more detail
according to one embodiment of the present disclosure. In this
embodiment, the user profile of the subject user includes a number
of keywords and a probability assigned to each of the keywords. The
probability assigned to a keyword in the user profile of the
subject user is a probability that the subject user has an interest
in the keyword. Initially, the user profile of the subject user
includes zero or more keywords entered by the subject user, where
each of these keywords is assigned a fixed probability of 100%.
Over time, as a number of iterations of the profile augmentation
process of FIG. 22 are performed, additional keywords are added to
the user profile of the subject user and probabilities are assigned
to those keywords. As discussed below, the probabilities of these
additional keywords are determined based on questions asked of the
subject user and/or the number of user matches, or occurrences, for
the keywords from one or more aggregate profiles of crowds located
at or near the subject user.
[0156] More specifically, in order to augment the user profile of
the subject user based on the aggregate profile of the crowd at or
near the current location of the subject user, the profile
augmentation function 40 identifies, or selects, a predetermined
number (N.sub.MAX) of keywords from the aggregate profile of the
crowd having the highest number of user matches and not having a
fixed probability in the user profile of the subject user (step
2100). Keywords in the user profile of the subject user having
fixed probabilities are keywords that have been entered by the
subject user into the user profile. In addition, as discussed
below, the keywords having fixed probabilities may also include
keywords in which the subject user has expressed an interest or
disinterest in response to questions from the profile augmentation
function 40.
[0157] For example, assume that the user profile of the subject
user is:
TABLE-US-00001 Keyword Probability (%) Tennis 100 (fixed) Politics
100 (fixed)
Also, assume that the aggregate profile for the crowd is:
TABLE-US-00002 Keyword User Matches Tennis 5 Sports 3 China 2
Coffee 2 Photography 1
As such, the profile augmentation function 40 selects, at most, the
predetermined number (N.sub.MAX) of the keywords from the aggregate
profile having the highest number of user matches and not having a
fixed probability in the user profile of the subject user. In this
example, assume that N.sub.MAX is three (3). Here, the three
keywords having the highest number of user matches and not having
fixed probabilities in the user profile of the subject user are the
keywords Sports, China, and Coffee. Note that the keyword Tennis
has a fixed probability in the user profile of the subject user and
as such is not selected by the profile augmentation function
40.
[0158] Next, the profile augmentation function 40 generates a
question for each of the keywords identified in step 2100 (step
2102). In general, the questions are automatically generated in
order to determine whether the subject user is interested in the
identified keywords. Returning to our example, if the identified
keywords are Sports, China, and Coffee, the profile augmentation
function 40 may generate the following questions: "Do you have an
interest in sports?," "Do you have an interest in China?," and "Do
you like coffee?." Alternatively, the questions for the identified
keywords may be a list of the identified keywords where the subject
user will be enabled to select "Yes" or "No" for each of the
identified keywords, or the like. The profile augmentation function
40 then provides the questions for the identified keywords to the
subject user (step 2104), and receives answers to the questions
from the subject user (2106). Note that the subject user may choose
to answer all, some, or none of the questions. Lastly, the profile
augmentation function 40 updates the user profile of the subject
user based on any answers received from the subject user and, in
this embodiment, the number of user matches for the keywords in the
aggregate profile of the crowd (step 2108).
[0159] FIG. 24 illustrates step 2108 of FIG. 23 in more detail
according to one embodiment of the present disclosure.
Specifically, FIG. 24 illustrates the operation of the profile
augmentation function 40 to update the user profile of the subject
user based on any answers received from the subject user and the
number of user matches for the keywords in the aggregate profile of
the crowd. First, the profile augmentation function 40 gets the
next keyword from the aggregate profile (step 2200). Note that for
the first iteration, the next keyword is the first keyword in the
aggregate profile. Next, the profile augmentation function 40
determines whether a question was asked for the keyword and whether
an answer to the question was received from the subject user (step
2202). If not, the profile augmentation function 40 determines
whether the keyword is already in the user profile of the subject
user (step 2204). The keyword may already be in the user profile if
the subject user entered the keyword into the user profile or if
the keyword was added to the user profile of the subject user
during a previous iteration of the profile augmentation process. If
the keyword is not already in the user profile of the subject user,
the profile augmentation function 40 computes a probability for the
keyword based on the number of user matches for the keyword in the
aggregate profile (step 2206). In one embodiment, the probability
score is computed based on the following equation:
PROBABILITY = USER_MATCHES TOTAL_USER _MATCHES .times. 100 ,
##EQU00007##
where PROBABILITY is the probability of the keyword, USER_MATCHES
is the number of user matches for the keyword from the aggregate
profile, and TOTAL_USER_MATCHES is the sum of the number of user
matches for all of the keywords in the aggregate profile. Note that
the equation above is exemplary and is not intended to limit the
scope of the present disclosure. The profile augmentation function
40 then adds the keyword and the probability computed for the
keyword to the user profile of the subject user (step 2208). At
this point, the process proceeds to step 2222, which is described
below.
[0160] Returning to step 2204, if the keyword is already in the
user profile of the subject user, the profile augmentation function
40 determines whether the keyword has a fixed probability in the
user profile of the subject user (step 2210).
[0161] In this embodiment, the keyword will have a fixed
probability if the subject user added the keyword to the user
profile or if the subject user previously answered a question for
the keyword. More specifically, in this embodiment, the keyword
will have a fixed probability of 100% if the subject user
previously added the keyword to the user profile, a fixed
probability of 100% if the subject user answered a question for the
keyword in a previous iteration of the profile augmentation process
in a manner that indicated that the subject user has an interest in
the keyword, or a fixed probability of 0% if the subject user
answered a question for the keyword in a previous iteration of the
profile augmentation process in a manner that indicated that the
subject user does not have an interest in the keyword. If the
keyword does not have a fixed probability, the profile augmentation
function 40 computes a new probability for the keyword based on the
probability for the keyword in the user profile (i.e., the old
probability for the keyword) and the number of user matches for the
keyword in the aggregate profile (step 2212). In one embodiment,
the new probability is computed based on the following
equation:
PROBABILITY.sub.NEW=AVG(PROBABILITY.sub.OLD,PROBABILITY.sub.TEMP),
where
PROBABILITY TEMP = USER_MATCHES TOTAL_USER _MATCHES .times. 100 ,
##EQU00008##
and PROBABILITY.sub.NEW is the new probability for the keyword,
PROBABILITY.sub.OLD is the old probability for the keyword,
PROBABILITY.sub.TEMP is a temporary probability used for purposes
of this exemplary calculation, USER_MATCHES is the number of user
matches for the keyword from the aggregate profile, and
TOTAL_USER_MATCHES is the sum of the number of user matches for all
of the keywords in the aggregate profile. The function AVG(x,y) is
the average of the values x and y. Note that other techniques may
be used to combine the old probability and the temporary
probability to provide the new probability (e.g., summing, weighted
averaging, or the like). The profile augmentation function 40 then
updates the user profile of the subject user to include the new
probability for the keyword (step 2214). At this point, the process
proceeds to step 2222, which is described below.
[0162] Returning to step 2202, if a question was asked for the
keyword and an answer was received from the subject user for the
question asked for the keyword, the profile augmentation function
40 determines whether the keyword is already in the user profile of
the subject user (step 2216). If not, the profile augmentation
function 40 adds the keyword to the user profile of the subject
user along with a fixed probability for the keyword that reflects
the answer given by the subject user to the corresponding question
(step 2218). In this example, the fixed probability for the keyword
is 100% if the subject user gave a positive answer indicating that
the subject user has an interest in the keyword. In contrast, the
fixed probability for the keyword is 0% if the subject user gave a
negative answer indicating that the subject user does not have an
interest in the keyword. At this point, the process proceeds to
step 2222, which is described below.
[0163] Returning to step 2216, if the keyword is already in the
user profile of the subject user, then the profile augmentation
function 40 updates the user profile of the subject user with a
fixed probability for the keyword that reflects the answer given by
the subject user to the corresponding question (step 2220). Again,
in this example, the fixed probability for the keyword is 100% if
the subject user gave a positive answer indicating that the subject
user has an interest in the keyword. In contrast, the fixed
probability for the keyword is 0% if the subject user gave a
negative answer indicating that the subject user does not have an
interest in the keyword. The process then proceeds to step 2222,
which is described below.
[0164] At this point, whether proceeding from step 2208, step 2210,
step 2214, step 2218, or step 2220, the profile augmentation
function 40 determines whether that last keyword in the aggregate
profile has been processed (step 2222). If not, the process returns
to step 2200 and is repeated for the next keyword in the aggregate
profile. Once all of the keywords in the aggregate profile have
been processed, the process is complete.
[0165] Again, as an example, assume that the user profile of the
subject user is:
TABLE-US-00003 Keyword Probability (%) Tennis 100 (fixed) Politics
100 (fixed)
Also, assume that the aggregate profile is:
TABLE-US-00004 Keyword User Matches Tennis 5 Sports 3 China 2
Coffee 2 Photography 1
and that questions were asked for the keywords Sports, China, and
Coffee from the aggregate profile. Further assume, that the subject
user answered the question for Sports in a manner that indicated
that the subject user has an interest in sports, answered the
question for Coffee in a manner that indicated that the subject
user is not interested in Coffee, and did not answer the question
for China. As such, using the process described above, the user
profile of the subject user is updated as follows:
TABLE-US-00005 Keyword Probability Tennis 100 (fixed) Politics 100
(fixed) Sports 100 (fixed) China 15 Photography 8 Coffee 0
(fixed)
Note that future iterations of the profile augmentation process may
be performed in order to further augment the user profile of the
subject user.
[0166] For instance, if the subject user thereafter moves to a new
location and the process is repeated, an aggregate profile for a
new crowd that is at or near the new location of the subject user
may be:
TABLE-US-00006 Keyword User Matches Sports 5 Photography 3 Hiking 2
Technology 2 Farming 1
In this example, assuming again that N.sub.MAX is 3, then
Photography, Hiking, and Technology are selected and corresponding
questions are provided to the subject user. For this example,
assume that the subject user does not respond to any of the
questions. As such, since the keyword Photography is already in the
user profile of the subject user, a new probability is computed for
the keyword Photography based on the old probability which in this
case is 8 and the number of user matches for the keyword
Photography in the aggregate profile for the new crowd. The
keywords Hiking and Technology are not already in the user profile
of the subject user. As such, the keywords Hiking and Technology
are added to the user profile of the subject user along with
corresponding probabilities computed based on the number of user
matches for those keywords in the aggregate profile of the new
crowd. As such, the updated user profile of the subject user may
then be:
TABLE-US-00007 Keyword Probability Tennis 100 (fixed) Politics 100
(fixed) Sports 100 (fixed) China 15 Photography 15 Hiking 15
Technology 15 Farming 8 Coffee 0 (fixed)
[0167] FIG. 25 illustrates step 2004 of FIG. 22 in more detail
according to another embodiment of the present disclosure. In this
embodiment, the user profile of the subject user includes a number
of keywords and a probability assigned to each of the keywords.
Initially, the user profile of the subject user includes zero or
more keywords entered by the subject user, where each of these
keywords is assigned a fixed probability of 100%. Over time, as a
number of iterations of the profile augmentation process of FIG. 22
are performed, additional keywords are added to the user profile of
the subject user. As discussed below, the probabilities of these
additional keywords are determined based on questions asked of the
subject user and/or the number of user matches for the keywords for
aggregate profiles of crowds located at or near the subject
user.
[0168] More specifically, in order to augment the user profile of
the subject user based on the aggregate profile of the crowd at or
near the current location of the subject user, the profile
augmentation function 40 first provides a preliminary question to
the subject user (step 2300). The preliminary question is
preferably an open-ended question regarding the interests of the
subject user. For example, the preliminary question may be "What is
one of your current topics of interest?." The profile augmentation
function 40 then receives an answer from the subject user (step
2302). The answer from the subject user is referred to herein as a
topic of interest. The profile augmentation function 40 then
selects a desired number of keywords from the aggregate profile
that have the highest number of user matches, do not have fixed
probabilities in the user profile of the subject user, and have the
highest affinity to the topic of interest provided by the subject
user (step 2304). Affinity between the topic of interest and the
keywords in the aggregate profile may be determined using any
suitable technique for determining the affinity between two
keywords. For example, an ontology or similar data structure that
defines relationships between words and topics may be used to
determine the degree of relationship between two keywords (e.g.,
degrees of separation of the two keywords in the ontology), where
the degree of relationship is utilized as the affinity of the two
keywords.
[0169] For example, assume that the user profile of the subject
user is:
TABLE-US-00008 Keyword Probability (%) Tennis 100 (fixed) Politics
100 (fixed)
Also, assume that the aggregate profile is:
TABLE-US-00009 Keyword User Matches Tennis 5 Sports 3 China 2
Coffee 2 Europe 2 Photography 1
Further assume that topic of interest provided by the subject user
is History and that the desired number of keywords to be selected
is three (3). As such, the profile augmentation function 40 selects
the Sports keyword because it has the highest number of user
matches and is not already included in the user profile of the
subject user with a fixed probability. The profile augmentation
function 40 then selects two more keywords from the keywords China,
Coffee, and Europe based on the affinities of those keywords to the
topic of interest, which is History. As such, in this example, the
profile augmentation function 40 selects the keywords China and
Europe because they have higher affinities with the topic of
interest than the keyword Coffee.
[0170] Next, the profile augmentation function 40 generates a
question for each of the selected keywords (step 2306). In general,
the questions are automatically generated in order to determine
whether the subject user is interested in the identified keywords.
Returning to our example, if the identified keywords are Sports,
China, and Europe, the profile augmentation function 40 may
generate the following questions: "Do you have an interest in
sports?," "Do you have an interest in China?," and "Do you have an
interest in Europe?." Alternatively, the questions for the
identified keywords may be a list of the identified keywords where
the subject user will be enabled to select "Yes" or "No" for each
of the identified keywords, or the like. The profile augmentation
function 40 then provides the questions for the identified keywords
to the subject user (step 2308), and receives answers to the
questions from the subject user (2310). Note that the subject user
may choose to answer all, some, or none of the questions. Lastly,
the profile augmentation function 40 updates the user profile of
the subject user based on any answers received from the subject
user and, in this embodiment, the number of user matches for the
keywords in the aggregate profile of the crowd (step 2312). More
specifically, in one embodiment, the profile augmentation function
40 updates the user profile of the subject user using the process
of FIG. 24 described above.
[0171] FIG. 26 illustrates the operation of the profile
augmentation function 40 to augment a user profile of a user based
on an aggregate profile of a crowd for the embodiment of FIG. 1A
wherein the profile augmentation function 40 is implemented on the
MAP server 12. First, the MAP server 12 obtains a user profile of a
system user (step 2400). The system user is one of the users 20-1
through 20-N. As discussed above, the MAP server 12 may obtain the
user profile of the system user from the profile server 14, but is
not limited thereto. Next, the MAP server 12 obtains the current
location of the system user in the manner described above and
identifies a crowd at or near the current location of the system
user (steps 2402 and 2404). The MAP server 12 may identify the
crowd by reactively performing the crowd formation process of FIG.
15 for a geographic region encompassing the current location of the
system user. Alternatively, the MAP server 12 may proactively form
crowds using the process of FIG. 15 or FIGS. 17A through 17D. In
this case, the MAP server 12 identifies the crowd at or near the
current location of the system user by querying the datastore 66 of
the MAP server 12. For example, the crowd at or near the current
location of the system user may be a crowd in which the system user
is currently included or a crowd that is closest to the current
location of the system user.
[0172] Next, the MAP server 12 obtains an aggregate profile for the
crowd (step 2406). More specifically, the MAP server 12 compares
the user profiles of the users in the crowd to one another to
generate the aggregate profile of the crowd. As discussed above, in
this embodiment, the aggregate profile of the crowd preferably
includes a number of keywords and, for each keyword, a number of
user matches for the keyword in the user profiles of the users in
the crowd. The profile augmentation function 40, which for this
embodiment is implemented on the MAP server 12, then augments the
user profile of the system user based on the aggregate profile of
the crowd in the manner described above (step 2408). Preferably,
the process returns to step 2402 and is periodically or otherwise
repeated to further augment the user profile of the system user
over time.
[0173] FIG. 27 illustrates the operation of the profile
augmentation function 40 for the embodiment of FIG. 1B. In this
embodiment, the profile augmentation function 40 is implemented on
the profile server 14, one of the mobile devices 18-1 through 18-N,
the subscriber device 22, or the third-party server 26. First, the
profile augmentation function 40 sends an aggregate profile request
to the MAP server 12 that includes the current location of the
subject user (step 2500). Alternatively, if the subject user is a
system user (i.e., one of the users 20-1 through 20-N), the
aggregate profile request may identify the subject user, where the
MAP server 12 then obtains the current location of the subject
user. In this embodiment, the subject user may be a system user or
a third-party user depending on the particular implementation. In
response, the MAP server 12 identifies a crowd that is at or near
the current location of the subject user (step 2502). Again, the
crowd may be formed proactively or reactively, as described above.
The crowd that is at or near the current location of the subject
user is preferably a crowd that is at or closest to the current
location of the subject user. If the subject user is a system user,
the crowd that is at or near the current location of the subject
user may be a crowd in which the subject user is included. The MAP
server 12 then obtains an aggregate profile for the crowd (step
2504). More specifically, the MAP server 12 compares the user
profiles of the users in the crowd to one another to generate the
aggregate profile of the crowd. As discussed above, in this
embodiment, the aggregate profile of the crowd preferably includes
a number of keywords and, for each keyword, a number of user
matches for the keyword in the user profiles of the users in the
crowd. Next, the MAP server returns the aggregate profile of the
crowd to the profile augmentation function 40 (step 2506). The
profile augmentation function 40 then augments the user profile of
the subject user based on the aggregate profile of the crowd in the
manner described above (step 2508).
[0174] FIGS. 28 through 32 illustrate the operation of the profile
augmentation function 40 according to another embodiment of the
present disclosure. In this embodiment, the profile augmentation
function 40 augments a user profile of a subject user based on a
historical aggregate profile for users historically located at
locations relevant to the current location of the subject user. The
locations relevant to the current location of the subject user are
locations that are at or near the current location of the subject
user. Note that while described separately herein, the profile
augmentation function 40 may augment the user profile of a subject
user based on both an aggregate profile of a crowd at or near the
current location of the subject user and a historical aggregate
profile for users historically located at or near the current
location of the subject user.
[0175] FIG. 28 illustrates the operation of the profile
augmentation function 40 to augment a user profile of a subject
user based on a historical aggregate profile data for users
historically, or previously, located at or near a current location
of the subject user according to another embodiment of the present
disclosure. First, the profile augmentation function 40 gets, or
obtains, a current location of a subject user (step 2600).
Depending on the particular embodiment, the subject user may be a
system-user, which is one of the users 20-1 through 20-N of the
mobile devices 18-1 through 18-N or the subscriber 24 of the
subscriber device 22, or a third-party user, which may be a user
associated with the profile server 14 or the third-party server 26
that is not one of the system-users. The current location of the
subject user may be obtained using any suitable technique. For
example, if the subject user is user 20-1, the current location of
the user 20-1 is preferably obtained from the mobile device 18-1 or
the location server 16. As another example, if the subject user is
a third-party user, the current location of the third-party user
may be obtained from a location-aware device of the third-party
user.
[0176] Next, the profile augmentation function 40 obtains a
historical aggregate profile for users historically located at or
near the current location of the subject user (step 2602). In one
embodiment, the users historically located at or near the current
location of the subject user are users that were located at or near
the current location of the subject user within one or more defined
time windows. Each time window may be a relative time window that
is relative to the current time (e.g., past 6 months, past 2 years,
or the like) or an absolute time window (e.g., Friday, Feb. 12,
2010 or the like). In general, the users historically located at or
near the current location of the subject user are users that were
historically located within a defined geographic region
encompassing (e.g., centered at) the current location of the
subject user. In the preferred embodiment, the historical aggregate
profile includes a number of keywords and, for each keyword, a
number of user matches, or occurrences, of the keyword in the user
profiles of the users historically located at or near the current
location of the subject user. The profile augmentation function 40
then augments a user profile of the subject user based on the
historical aggregate profile (step 2604).
[0177] FIG. 29 illustrates step 2604 of FIG. 28 in more detail
according to one embodiment of the present disclosure. In this
embodiment, the user profile of the subject user includes a number
of keywords and a probability assigned to each of the keywords.
Initially, the user profile of the subject user includes zero or
more keywords entered by the subject user, where each of these
keywords is assigned a fixed probability of 100%. Over time, as a
number of iterations of the profile augmentation process of FIG. 28
are performed, additional keywords are added to the user profile of
the subject user. As discussed below, the probabilities of these
additional keywords are determined based on questions asked of the
subject user and/or the number of user matches for the keywords
from a historical aggregate profile obtained for the current
location of the subject user.
[0178] More specifically, in order to augment the user profile of
the subject user based on the historical aggregate profile for the
current location of the subject user, the profile augmentation
function 40 identifies, or selects, a predetermined number
(N.sub.MAX) of keywords from the historical aggregate profile
having the highest number of user matches and not having a fixed
probability in the user profile of the subject user (step 2700).
Keywords in the user profile of the subject user having fixed
probabilities are keywords that have been entered by the subject
user into the user profile. In addition, as discussed below, the
keywords having fixed probabilities may also include keywords in
which the subject user has expressed an interest or disinterest in
response to questions from the profile augmentation function
40.
[0179] For example, assume that the user profile of the subject
user is:
TABLE-US-00010 Keyword Probability (%) Tennis 100 (fixed) Politics
100 (fixed)
Also, assume that the historical aggregate profile is:
TABLE-US-00011 Keyword User Matches Tennis 19 Books 8 Photography 7
Fishing 4 Sports 3 China 3 Coffee 2 Skiing 2 Europe 1 Farm Animals
1
As such, the profile augmentation function 40 selects, at most, the
predetermined number (N.sub.MAX) of the keywords from the
historical aggregate profile having the highest number of user
matches and not having a fixed probability in the user profile of
the subject user. In this example, assume that N.sub.MAX is three
(3). Here, the three keywords having the highest number of user
matches and not having fixed probabilities in the user profile of
the subject user are the keywords Books, Photography, and Fishing.
Note that the keyword Tennis has a fixed probability in the user
profile of the subject user.
[0180] Next, the profile augmentation function 40 generates a
question for each of the identified keywords (step 2702). In
general, the questions are automatically generated in order to
determine whether the subject user is interested in the identified
keywords. Returning to our example, if the identified keywords are
Books, Photography, and Fishing, the profile augmentation function
40 may generate the following questions: "Do you have an interest
in books?," "Do you have an interest in photography?," and "Do you
like fishing?." Alternatively, the questions for the identified
keywords may be a list of the identified keywords where the subject
user will be enabled to select "Yes" or "No" for each of the
identified keywords, or the like. The profile augmentation function
40 then provides the questions for the identified keywords to the
subject user (step 2704), and receives answers to the questions
from the subject user (2706). Note that the subject user may choose
to answer all, some, or none of the questions. Lastly, the profile
augmentation function 40 updates the user profile of the subject
user based on any answers received from the subject user and, in
this embodiment, the number of user matches for the keywords in the
historical aggregate profile (step 2708). In one embodiment, the
profile augmentation function 40 updates the user profile of the
subject user using the process of FIG. 24 described above.
[0181] Continuing our example, assume that the subject user
responds positively to the question for the keyword Books, responds
negatively to the question for the keyword Photography, and does
not respond to the question for the keyword Fishing. After the
process of FIG. 24 has been performed, the updated user profile of
the subject user would be:
TABLE-US-00012 Keyword Probability Tennis 100 (fixed) Politics 100
(fixed) Books 100 (fixed) Fishing 8 Sports 6 China 6 Coffee 4
Skiing 4 Europe 2 Farm Animals 2 Photography 0 (fixed)
Note that future iterations of the profile augmentation process may
be performed in order to further augment the user profile of the
subject user.
[0182] FIG. 30 illustrates step 2604 of FIG. 28 in more detail
according to another embodiment of the present disclosure. In this
embodiment, the user profile of the subject user includes a number
of keywords and a probability assigned to each of the keywords.
Initially, the user profile of the subject user includes zero or
more keywords entered by the subject user, where each of these
keywords is assigned a fixed probability of 100%. Over time, as a
number of iterations of the profile augmentation process of FIG. 28
are performed, additional keywords are added to the user profile of
the subject user. As discussed below, the probabilities of these
additional keywords are determined based on questions asked of the
subject user and/or the number of user matches for the keywords in
historical aggregate profiles.
[0183] More specifically, in order to augment the user profile of
the subject user based on the historical aggregate profile of users
historically located at or near the current location of the subject
user, the profile augmentation function 40 first provides a
preliminary question to the subject user (step 2800). The
preliminary question is preferably an open-ended question regarding
the interests of the subject user. For example, the preliminary
question may be "What is one of your current topics of interest?."
The profile augmentation function 40 then receives an answer from
the subject user (step 2802). The answer from the subject user is
referred to herein as a topic of interest. The profile augmentation
function 40 then selects a desired number of keywords from the
historical aggregate profile that have the highest number of user
matches, do not have fixed probabilities in the user profile of the
subject user, and have the highest affinity to the topic of
interest provided by the subject user (step 2804). Affinity between
the topic of interest and the keywords in the historical aggregate
profile may be determined using any suitable technique for
determining the affinity between two keywords. For example, an
ontology or similar data structure that defines relationships
between words and topics may be used to determine the degree of
relationship between two keywords (e.g., degrees of separation of
the two keywords in the ontology), where the degree of relationship
is utilized as the affinity of the two keywords.
[0184] For example, assume that the user profile of the subject
user is:
TABLE-US-00013 Keyword Probability (%) Sports 100 (fixed) Politics
100 (fixed)
Also, assume that the historical aggregate profile is:
TABLE-US-00014 Keyword User Matches Sports 15 Books 10 Photography
7 Coffee 5 China 5 Skiing 5 Europe 5 Fishing 5
Further assume that the topic of interest provided by the subject
user is the Winter Olympics and that the desired number of keywords
to be selected is three (3). As such, the profile augmentation
function 40 selects Books and Photography because they have the
highest number of user matches for keywords that do not have fixed
probabilities in the user profile of the subject user. The profile
augmentation function 40 then selects one more keyword from the
keywords Coffee, China, Skiing, Europe, and Fishing based on the
affinities of those keywords to the topic of interest, which is the
Winter Olympics. As such, in this example, the profile augmentation
function 40 selects the keyword Skiing because it has a higher
affinity with the topic of interest than the other keywords.
[0185] Next, the profile augmentation function 40 generates a
question for each of the selected keywords (step 2806). In general,
the questions are automatically generated in order to determine
whether the subject user is interested in the identified keywords.
Returning to our example, if the identified keywords are Books,
Photography, and Skiing, the profile augmentation function 40 may
generate the following questions: "Do you have an interest in
books?," "Do you have an interest in photography?," and "Do you
have an interest in skiing?." Alternatively, the questions for the
identified keywords may be a list of the identified keywords where
the subject user will be enabled to select "Yes" or "No" for each
of the identified keywords, or the like. The profile augmentation
function 40 then provides the questions for the identified keywords
to the subject user (step 2808), and receives answers to the
questions from the subject user (step 2810). Note that the subject
user may choose to answer all, some, or none of the questions.
Lastly, the profile augmentation function 40 updates the user
profile of the subject user based on any answers received from the
subject user and, in this embodiment, the number of user matches
for the keywords in the historical aggregate profile for the
current location of the subject user (step 2812). More
specifically, in one embodiment, the profile augmentation function
40 updates the user profile of the subject user using the process
of FIG. 24 described above.
[0186] FIG. 31 illustrates the operation of the profile
augmentation function 40 to augment a user profile of a subject
user based on a historical aggregate profile for the embodiment of
FIG. 1A wherein the profile augmentation function 40 is implemented
on the MAP server 12. First, the MAP server 12 obtains a user
profile of a system user (step 2900). The system user is one of the
users 20-1 through 20-N. As discussed above, the MAP server 12 may
obtain the user profile of the system user from the profile server
14, but is not limited thereto. Next, the MAP server 12 obtains the
current location of the system user in the manner described above
(step 2902). Next, the MAP server 12 obtains a historical aggregate
profile for the current location of the system user (step 2904).
The manner in which the historical aggregate profile is preferably
obtained by the MAP server 12 is described below. In general, user
profiles of users historically located at or near the current
location of the system user during one or more defined time windows
are combined to provide the historical aggregate profile. Again,
the historical aggregate profile preferably includes a number of
keywords and, for each keyword, a number of user matches for that
keyword in the user profiles of the users historically located at
or near the current location of the system user. The profile
augmentation function 40, which for this embodiment is implemented
on the MAP server 12, then augments the user profile of the system
user based on the historical aggregate profile in the manner
described above (step 2906). Preferably, the process returns to
step 2902 and is periodically or otherwise repeated to further
augment the user profile of the system user over time.
[0187] FIG. 32 illustrates the operation of the profile
augmentation function 40 to perform the profile augmentation
process of FIG. 28 for the embodiment of FIG. 1B. In this
embodiment, the profile augmentation function 40 is implemented on
the profile server 14, one of the mobile devices 18-1 through 18-N,
the subscriber device 22, or the third-party server 26. First, the
profile augmentation function 40 sends a historical aggregate
profile request to the MAP server 12 that includes the current
location of the subject user (step 3000). Alternatively, if the
subject user is a system user (i.e., one of the users 20-1 through
20-N), the historical aggregate profile request may identify the
subject user, where the MAP server 12 then obtains the current
location of the subject user. In this embodiment, the subject user
may be a system user or a third-party user depending on the
particular implementation details. In response, the MAP server 12
generates or otherwise obtains a historical aggregate profile for
the current location of the subject user (step 3002). Again, the
manner in which the historical aggregate profile is preferably
generated is described below. Next, the MAP server returns the
historical aggregate profile to the profile augmentation function
40 (step 3004). The profile augmentation function 40 then augments
the user profile of the subject user based on the historical
aggregate profile in the manner described above (step 3006).
[0188] FIG. 33 illustrates the operation of the MAP server 12 to
generate a historical aggregate profile for a current location of a
subject user according to one embodiment of the present disclosure.
First, the history manager 58 of the MAP server 12 establishes a
bounding box for the historical aggregate profile request based on
the current location of the subject user (step 3100). Note that
while a bounding box is used in this example, other geographic
shapes may be used to define a bounding region for the historical
request (e.g., a bounding circle). In this embodiment, the bounding
box is a bounding box of a predefined size centered at the current
location of the subject user. In addition to establishing the
bounding box, the history manager 58 establishes a time window for
the historical aggregate profile request (step 3102). The time
window is preferably identified in the historical aggregate profile
request, but is not limited thereto. For example, if the historical
aggregate profile request is for the last week and the current date
and time are Sep. 17, 2009 at 10:00 pm, the history manager 58 may
generate the time window as Sep. 10, 2009 at 10:00 pm through Sep.
17, 2009 at 10:00 pm. Note that while a single time window is used
for this example, any number of one or more time windows may be
defined and processed accordingly.
[0189] Next, the history manager 58 obtains history objects
relevant to the bounding box and the time window for the historical
aggregate profile request from the datastore 66 of the MAP server
12 (step 3104). The relevant history objects are history objects
recorded for time periods within or intersecting the time window
and for locations, or geographic areas, within or intersecting the
bounding box for the historical aggregate profile request. At this
point, the history manager 58 gets the next history object from the
relevant history objects identified in step 3104 (step 3106). The
history manager 58 then generates an aggregate profile for the
history object (step 3108). In order to generate the aggregate
profile for the history object, the history manager 58 compares the
user profiles of the anonymous user records stored in the history
object to one another. The resulting aggregate profile for the
history object includes a number of keywords and, for each keyword,
a number of user matches for that keyword. The history manager 58
then determines whether there are more history objects to be
processed (step 3110). If so, the process returns to step 3106 and
is repeated until all of the history objects that are relevant to
the historical aggregate profile request have been processed. Once
all of the history objects have been processed, the history manager
58 combines the aggregate profiles of the history objects to
provide the historical aggregate profile for the current location
of the subject user (step 3112). More specifically, in this
embodiment, the history manager 58 combines the aggregate profiles
of the history objects to provide a list of keywords and, for each
keyword, a number of user matches for that keyword over all of the
history objects.
[0190] Before proceeding, it should be noted that, in the
embodiments described above, the profile augmentation function 40
utilizes questions asked of the subject user. However, the profile
augmentation function 40 is not limited thereto. In another
embodiment, no questions are asked of the subject user. Rather, the
profile augmentation function 40 operates to update the user
profile of the subject user based on the aggregate profile date
(i.e., the aggregate profile of the crowd at or near the current
location of the subject user or the historical aggregate profile
for the current location of the subject user) according to steps
2200, 2204-2214, and 2222 of FIG. 24.
[0191] It should also be noted that the profile augmentation
function 40 may utilize things in addition to the aggregate profile
data when augmenting a user profile of a subject user. For example,
in the embodiments of FIGS. 25 and 30, the topic of interest
provided by the subject user may be used to identify other keywords
identified as being of interest by other users that also provided
the same topic of interest. The other users may be other users in
general or other users currently or previously located at or near
the current location of the subject user.
[0192] FIG. 34 is a block diagram of the MAP server 12 according to
one embodiment of the present disclosure. As illustrated, the MAP
server 12 includes a controller 170 connected to memory 172, one or
more secondary storage devices 174, and a communication interface
176 by a bus 178 or similar mechanism. The controller 170 is a
microprocessor, digital Application Specific Integrated Circuit
(ASIC), Field Programmable Gate Array (FPGA), or the like. In this
embodiment, the controller 170 is a microprocessor, and the
application layer 42, the business logic layer 44, and the object
mapping layer 64 (FIG. 2) are implemented in software and stored in
the memory 172 for execution by the controller 170. Further, the
datastore 66 (FIG. 2) may be implemented in the one or more
secondary storage devices 174. The secondary storage devices 174
are digital data storage devices such as, for example, one or more
hard disk drives. The communication interface 176 is a wired or
wireless communication interface that communicatively couples the
MAP server 12 to the network 28 (FIGS. 1A and 1B). For example, the
communication interface 176 may be an Ethernet interface, local
wireless interface such as a wireless interface operating according
to one of the suite of IEEE 802.11 standards, or the like.
[0193] FIG. 35 is a block diagram of the mobile device 18-1
according to one embodiment of the present disclosure. This
discussion is equally applicable to the other mobile devices 18-2
through 18-N. As illustrated, the mobile device 18-1 includes a
controller 180 connected to memory 182, a communication interface
184, one or more user interface components 186, and the location
function 36-1 by a bus 188 or similar mechanism. The controller 180
is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 180 is a microprocessor, and the MAP
client 30-1, the MAP application 32-1, and the third-party
applications 34-1 are implemented in software and stored in the
memory 182 for execution by the controller 180. In addition, if
implemented on the mobile device 18-1, the profile augmentation
function 40 is also preferably implemented in software and stored
in the memory 182 for execution by the controller 180. In this
embodiment, the location function 36-1 is a hardware component such
as, for example, a GPS receiver. The communication interface 184 is
a wireless communication interface that communicatively couples the
mobile device 18-1 to the network 28 (FIGS. 1A and 1B). For
example, the communication interface 184 may be a local wireless
interface such as a wireless interface operating according to one
of the suite of IEEE 802.11 standards, a mobile communications
interface such as a cellular telecommunications interface, or the
like. The one or more user interface components 186 include, for
example, a touchscreen, a display, one or more user input
components (e.g., a keypad), a speaker, or the like, or any
combination thereof.
[0194] FIG. 36 is a block diagram of the subscriber device 22
according to one embodiment of the present disclosure. As
illustrated, the subscriber device 22 includes a controller 190
connected to memory 192, one or more secondary storage devices 194,
a communication interface 196, and one or more user interface
components 198 by a bus 200 or similar mechanism. The controller
190 is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 190 is a microprocessor, and the web
browser 38 (FIGS. 1A and 1B) is implemented in software and stored
in the memory 192 for execution by the controller 190. In addition,
if implemented on the subscriber device 22, the profile
augmentation function 40 is also preferably implemented in software
and stored in the memory 192 for execution by the controller 190.
The one or more secondary storage devices 194 are digital storage
devices such as, for example, one or more hard disk drives. The
communication interface 196 is a wired or wireless communication
interface that communicatively couples the subscriber device 22 to
the network 28 (FIGS. 1A and 1B). For example, the communication
interface 196 may be an Ethernet interface, local wireless
interface such as a wireless interface operating according to one
of the suite of IEEE 802.11 standards, a mobile communications
interface such as a cellular telecommunications interface, or the
like. The one or more user interface components 198 include, for
example, a touchscreen, a display, one or more user input
components (e.g., a keypad), a speaker, or the like, or any
combination thereof.
[0195] FIG. 37 is a block diagram of the third-party server 26
according to one embodiment of the present disclosure. As
illustrated, the third-party server 26 includes a controller 202
connected to memory 204, one or more secondary storage devices 206,
a communication interface 208, and one or more user interface
components 210 by a bus 212 or similar mechanism. The controller
202 is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 202 is a microprocessor, and one or more
services provided by the third-party server 26 are implemented in
software and stored in the memory 204 for execution by the
controller 202. For instance, if implemented on the third-party
server 26, the profile augmentation function 40 is also preferably
implemented in software and stored in the memory 204 for execution
by the controller 202. The one or more secondary storage devices
206 are digital storage devices such as, for example, one or more
hard disk drives. The communication interface 208 is a wired or
wireless communication interface that communicatively couples the
third-party server 26 to the network 28 (FIGS. 1A and 1B). For
example, the communication interface 208 may be an Ethernet
interface, local wireless interface such as a wireless interface
operating according to one of the suite of IEEE 802.11 standards, a
mobile communications interface such as a cellular
telecommunications interface, or the like. The one or more user
interface components 210 include, for example, a touchscreen, a
display, one or more user input components (e.g., a keypad), a
speaker, or the like, or any combination thereof.
[0196] FIG. 38 is a block diagram of the profile server 14
according to one embodiment of the present disclosure. As
illustrated, the profile server 14 includes a controller 214
connected to memory 216, one or more secondary storage devices 218,
a communication interface 220, and one or more user interface
components 222 by a bus 224 or similar mechanism. The controller
214 is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 214 is a microprocessor, and one or more
services provided by the profile server 14 are implemented in
software and stored in the memory 216 for execution by the
controller 214. For instance, if implemented on the profile server
14, the profile augmentation function 40 is also preferably
implemented in software and stored in the memory 216 for execution
by the controller 214. The one or more secondary storage devices
218 are digital storage devices such as, for example, one or more
hard disk drives. The communication interface 220 is a wired or
wireless communication interface that communicatively couples the
profile server 14 to the network 28 (FIGS. 1A and 1B). For example,
the communication interface 220 may be an Ethernet interface, local
wireless interface such as a wireless interface operating according
to one of the suite of IEEE 802.11 standards, a mobile
communications interface such as a cellular telecommunications
interface, or the like. The one or more user interface components
222 include, for example, a touchscreen, a display, one or more
user input components (e.g., a keypad), a speaker, or the like, or
any combination thereof.
[0197] Those skilled in the art will recognize improvements and
modifications to the embodiments of the present invention. All such
improvements and modifications are considered within the scope of
the concepts disclosed herein and the claims that follow.
* * * * *