U.S. patent application number 12/698265 was filed with the patent office on 2012-02-16 for automated social routing.
This patent application is currently assigned to Waldeck Technology LLC. Invention is credited to Scott Curtis, Ravi Reddy Katpelly, Steven L. Petersen.
Application Number | 20120041672 12/698265 |
Document ID | / |
Family ID | 42398091 |
Filed Date | 2012-02-16 |
United States Patent
Application |
20120041672 |
Kind Code |
A1 |
Curtis; Scott ; et
al. |
February 16, 2012 |
AUTOMATED SOCIAL ROUTING
Abstract
Systems and methods are disclosed for providing automated social
routing. In general, a starting point and a stopping point are
obtained from a requesting user. A desired number of recommended
routes from the starting point to the stopping point are then
programmatically generated for the requesting user by dynamically
selecting physical waypoints for the recommended routes based on
one or more routing factors including one or more social routing
factors.
Inventors: |
Curtis; Scott; (Durham,
NC) ; Petersen; Steven L.; (Los Gatos, CA) ;
Katpelly; Ravi Reddy; (Durham, NC) |
Assignee: |
Waldeck Technology LLC
Wilmington
DE
|
Family ID: |
42398091 |
Appl. No.: |
12/698265 |
Filed: |
February 2, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61149205 |
Feb 2, 2009 |
|
|
|
Current U.S.
Class: |
701/426 |
Current CPC
Class: |
H04H 20/91 20130101;
H04W 4/023 20130101; H04W 4/029 20180201; H04H 60/53 20130101; H04H
20/61 20130101; H04H 60/51 20130101; H04H 20/57 20130101; H04W 4/60
20180201 |
Class at
Publication: |
701/426 |
International
Class: |
G01C 21/00 20060101
G01C021/00 |
Claims
1. A method of operation of a computing device, comprising:
obtaining a starting point and a stopping point; and generating one
or more recommended routes from the starting point to the stopping
point such that, for each recommended route of the one or more
recommended routes, one or more physical waypoints are selected for
the recommended route based on one or more routing factors
including one or more social routing factors.
2. The method of claim 1 wherein the one or more social routing
factors include an aggregate profile routing factor such that, for
each recommended route of the one or more recommended routes, the
one or more physical waypoints for the recommended route are
selected based on historical aggregate profile data for the one or
more physical waypoints.
3. The method of claim 2 wherein, for each recommended route of the
one or more recommended routes, the historical aggregate profile
data for the one or more physical waypoints selected for the
recommended route comprises data indicative of aggregate interests
of users historically located at the one or more physical
waypoints.
4. The method of claim 1 wherein the one or more social routing
factors include an aggregate profile routing factor such that, for
each recommended route of the one or more recommended routes, the
one or more physical waypoints for the recommended route are
selected based on aggregate profile data for crowds of users
currently located at the one or more physical waypoints.
5. The method of claim 4 wherein, for each recommended route of the
one or more recommended routes, the aggregate profile data for the
crowds of users currently located at the one or more physical
waypoints selected for the recommended route comprises data
indicative of aggregate interests of the users in the crowds
currently located at the one or more physical waypoints.
6. The method of claim 1 wherein the one or more recommended routes
are generated for a requesting user, and the one or more social
routing factors include an implicit rating factor such that, for
each recommended route of the one or more recommended routes, the
one or more physical waypoints for the recommended route are
selected based on implicit ratings for the one or more physical
waypoints obtained based on degrees to which other users in a
social network of the requesting user have previously visited the
one or more physical waypoints.
7. The method of claim 1 wherein the one or more recommended routes
are generated for a requesting user, and the one or more social
routing factors include an explicit rating factor such that, for
each recommended route of the one or more recommended routes, the
one or more physical waypoints for the recommended route are
selected based on explicit ratings for the one or more physical
waypoints made by other users.
8. The method of claim 7 wherein the other users are other users
for which explicit ratings for the one or more physical locations
are known.
9. The method of claim 7 wherein the other users are other users in
a social network of the requesting user for which explicit ratings
for the one or more physical locations are known.
10. The method of claim 7 wherein the other users are other users
that are like the requesting user and for which explicit ratings
for the one or more physical locations are known.
11. The method of claim 10 wherein the other users that are like
the requesting user are other users having user profiles that match
a user profile of the requesting user at least to a predefined
threshold degree.
12. The method of claim 1 further comprising obtaining one or more
abstract waypoints to be used for generating the one or more
recommended routes from the starting point to the stopping point,
wherein generating the one or more recommended routes comprises
generating the one or more recommended routes from the starting
point to the stopping point such that, for each recommended route
of the one or more recommended routes, the one or more physical
waypoints are selected based on the one or more abstract waypoints
and the one or more routing factors.
13. The method of claim 12 wherein the one or more abstract
waypoints comprise a plurality of abstract waypoints, and
generating the one or more recommended routes from the starting
point to the stopping point comprises, for each recommended route
of the one or more recommended routes: generating a random ordering
of the plurality of abstract waypoints for the recommended route,
the random ordering defining an order in which the plurality of
abstract waypoints are to occur in recommended route; selecting a
physical waypoint for each of at least a subset of the plurality of
abstract waypoints in the random ordering of the plurality of
abstract waypoints for the recommended route based on the routing
factors; and generating the recommended route from the starting
point to the stopping point through the physical waypoints.
14. The method of claim 12 wherein the one or more abstract
waypoints comprises a plurality of abstract waypoints, and
generating the one or more recommended routes from the starting
point to the stopping point comprises, for each recommended route
of the one or more recommended routes: generating a random ordering
of the plurality of abstract waypoints for the recommended route,
the random ordering defining an order in which the plurality of
abstract waypoints are to occur in recommended route; initializing
the recommended route to an optimal base route from the starting
point to the stopping point; for each abstract waypoint in the
random ordering of the plurality of abstract waypoints for the
recommended route: identifying a plurality of potential physical
waypoints for the abstract waypoint that are within a predefined
divergence distance from the recommended route; scoring each of the
plurality of physical waypoints based on the routing factors to
provide scores for the plurality of potential physical waypoints;
selecting a physical waypoint for the abstract waypoint in the
recommended route from the plurality of physical waypoints based on
the scores of the plurality of physical waypoints; and updating the
recommended route to include the physical waypoint selected for the
abstract waypoint.
15. The method of claim 14 wherein scoring each of the plurality of
potential physical waypoints comprises, for each potential physical
waypoint of the plurality of potential physical waypoints, scoring
the potential physical waypoint based on scores obtained for the
one or more routing factors and weightings assigned to the one or
more routing factors by a requesting user for which the one or more
recommended routes are generated.
16. The method of claim 14 wherein selecting the physical waypoint
for the abstract waypoint in the recommended route comprises
selecting a highest scored potential waypoint from the plurality of
potential physical waypoints as the physical waypoint.
17. The method of claim 12 wherein the one or more abstract
waypoints comprises a plurality of abstract waypoints, and
generating the one or more recommended routes from the starting
point to the stopping point comprises, for each recommended route
of the one or more recommended routes: iteratively selecting one of
the plurality of abstract waypoints and a physical waypoint for the
one of the plurality of abstract waypoints based on the routing
factors until physical waypoints have been selected for at least a
subset of the plurality of abstract waypoints; and generating the
recommended route from the starting point to the stopping point
through the physical waypoints selected for the at least a subset
of the plurality of abstract waypoints.
18. The method of claim 12 wherein the one or more abstract
waypoints comprises a plurality of abstract waypoints, and
generating the one or more recommended routes from the starting
point to the stopping point comprises, for each recommended route
of the one or more recommended routes: initializing the recommended
route to an optimal base route from the starting point to the
stopping point; marking each of the plurality of abstract waypoints
as incomplete; identifying potential physical waypoints for
abstract waypoints in the plurality of abstract waypoints marked as
incomplete that are within a predefined divergence distance from
the recommended route; scoring the potential physical waypoints
identified for the abstract waypoints marked as incomplete based on
the routing factors to provides scores for the potential physical
waypoints; identifying a select abstract waypoint from the abstract
waypoints marked as incomplete based on the scores of ones of the
potential physical waypoints identified for the select abstract
waypoint; selecting a physical waypoint for the recommended route
from the ones of the potential physical waypoints identified for
the select abstract waypoint based on the scores of the ones of the
potential physical waypoints identified for the select abstract
waypoint; updating the recommended route to include the physical
waypoint; marking the select abstract waypoint as complete; and
repeating the steps of identifying potential physical waypoints,
scoring the potential physical waypoints, combining the scores,
identifying a select abstract waypoint, selecting a physical
waypoint, updating the recommended route, and marking the select
abstract waypoint as complete for the abstract waypoints that
remain marked as incomplete.
19. The method of claim 18 wherein scoring the potential physical
waypoints comprises, for each potential physical waypoint of the
potential physical waypoints, scoring the potential physical
waypoint based on scores obtained for the one or more routing
factors and weightings assigned to the one or more routing factors
by a requesting user for which the one or more recommended routes
are generated.
20. The method of claim 1 wherein the one or more routing factors
further comprise at least one additional routing factor.
21. The method of claim 1 wherein the computing device is a
server.
22. The method of claim 1 wherein the computing device is a user
device.
23. The method of claim 22 wherein the user device is a device
selected from a group consisting of: a mobile device, a personal
navigation device, and a personal computer.
24. A computing device comprising: a communication interface; and a
controller associated with the communication interface and adapted
to: obtain a starting point and a stopping point; and generate one
or more recommended routes from the starting point to the stopping
point such that, for each recommended route of the one or more
recommended routes, one or more physical waypoints are selected for
the recommended route based on one or more routing factors
including one or more social routing factors.
25. A computer readable medium storing software for instructing a
controller of a computing device to: obtain a starting point and a
stopping point; and generate one or more recommended routes from
the starting point to the stopping point such that, for each
recommended route of the one or more recommended routes, one or
more physical waypoints are selected for the recommended route
based on one or more routing factors including one or more social
routing factors.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit of provisional patent
application Ser. No. 61/149,205, filed Feb. 2, 2009, the disclosure
of which is hereby incorporated herein by reference in its
entirety.
FIELD OF THE INVENTION
[0002] The present invention relates to routing from one geographic
location to another geographic location and more particularly
relates to an automated process for generating a recommended route
from one geographic location to another geographic location based
on one or more social routing factors.
BACKGROUND
[0003] Routes generated by traditional portable navigation devices
and Internet-based routing services such as Google.RTM. Maps do not
account for social factors. For instance, when routing a user from
one location to another, traditional personal navigation devices do
not take into account any type of social factor. As such, there is
a need for an improved routing system and method of operation
thereof that intelligently routes users based not only on where
they want to go, but also on social factors.
SUMMARY OF THE DISCLOSURE
[0004] Systems and methods are disclosed for providing automated
social routing. In general, a starting point and a stopping point
are obtained from a requesting user. A desired number of
recommended routes from the starting point to the stopping point
are then programmatically generated for the requesting user by
dynamically selecting physical waypoints for the recommended routes
based on one or more routing factors including one or more social
routing factors. The social routing factors may include an
aggregate profile routing factor, an implicit rating routing
factor, and/or an explicit rating routing factor. An aggregate
profile routing factor is a routing factor that considers
historical aggregate profile data for users previously located at
or near the potential physical waypoints, aggregate profile data
for crowds of users currently located at or near the potential
physical waypoints, or both. An implicit rating routing factor is a
routing factor that considers implicit ratings of the potential
physical waypoints by other users in a social network of the
requesting user, where the implicit ratings are generated based on
a degree to which the other users have previously visited the
potential physical waypoints. An explicit rating routing factor
considers explicit ratings of the potential physical waypoints by
other users such as other users for which explicit ratings are
known, other users in a social network of the requesting user for
which explicit ratings are known, or other users that are like the
requesting user and for which explicit ratings are known.
[0005] In one embodiment, a starting point, a stopping point, and
one or more abstract waypoints to be used for automated social
routing are obtained. For each of a desired number of recommended
routes, potential physical waypoints are identified for the
abstract waypoints and scored based on one or more social routing
factors. For each abstract waypoint, a physical waypoint is
selected for the recommended route based on the scores of the
potential physical waypoints identified for the abstract waypoint.
However, if no potential physical waypoints are identified for an
abstract waypoint, then no physical waypoint is selected for that
abstract waypoint. The recommended route is generated to include
the selected physical waypoints for the abstract waypoints for the
recommended route.
[0006] More specifically, in one embodiment, a starting point, a
stopping point, and one or more abstract waypoints to be used for
automated social routing are obtained. For each of a desired number
of recommended routes, a random ordering of the abstract waypoints
is generated. Then, for each recommended route, the abstract
waypoints are processed according to the random ordering of the
abstract waypoints generated for the recommended route to identify
potential physical waypoints for the abstract waypoints and select
physical waypoints for the abstract waypoints from the potential
physical waypoints based on the routing factors. The recommended
routes are generated using the starting point, the stopping point,
and the physical waypoints selected for the abstract waypoints for
the corresponding random ordering.
[0007] In another embodiment, a starting point, a stopping point,
and one or more abstract waypoints to be used for automated social
routing are obtained. For each recommended route of a desired
number of recommended routes, an iterative process is performed to
select one of the abstract waypoints and a physical waypoint for
that abstract waypoint based on the routing factors until physical
waypoints have been selected for the one or more abstract waypoints
obtained for the automated social routing process. The recommended
route is generated from the starting point to the stopping point
through the physical waypoints selected for the one or more
abstract waypoints for the recommended route.
[0008] Those skilled in the art will appreciate the scope of the
present invention and realize additional aspects thereof after
reading the following detailed description of the preferred
embodiments in association with the accompanying drawing
figures.
BRIEF DESCRIPTION OF THE DRAWING FIGURES
[0009] The accompanying drawing figures 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.
[0010] FIG. 1 illustrates a Mobile Aggregate Profile (MAP) system
enabling automated social routing according to one embodiment of
the present disclosure;
[0011] FIG. 2 is a block diagram of the MAP server of FIG. 1
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 FIG. 1 according to one embodiment of the present
disclosure;
[0013] FIG. 4 illustrates the operation of the system of FIG. 1 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 FIG. 1 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 FIG. 1
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 illustrates the operation of the system of FIG. 1
wherein the subscriber device is enabled to request and receive
historical data from the MAP server according to one embodiment of
the present disclosure;
[0024] FIG. 16 is a flow chart for a spatial crowd formation
process according to one embodiment of the present disclosure;
[0025] FIGS. 17A through 17D graphically illustrate the crowd
formation process of FIG. 16 for an exemplary bounding box;
[0026] FIGS. 18A through 18D illustrate a flow chart for a spatial
crowd formation process according to another embodiment of the
present disclosure;
[0027] FIGS. 19A through 19D graphically illustrate the crowd
formation process of FIGS. 18A through 18D for a scenario where the
crowd formation process is triggered by a location update for a
user having no old location;
[0028] FIGS. 20A through 20F graphically illustrate the crowd
formation process of FIGS. 18A through 18D for a scenario where the
new and old bounding boxes overlap;
[0029] FIGS. 21A through 21E graphically illustrate the crowd
formation process of FIGS. 18A through 18D in a scenario where the
new and old bounding boxes do not overlap;
[0030] FIG. 22 illustrates the operation the system of FIG. 1 to
enable the mobile devices to request crowd data for currently
formed crowds according to one embodiment of the present
disclosure;
[0031] FIG. 23 illustrates the operation of the system of FIG. 1 to
enable a subscriber device to request crowd data for current crowds
according to one embodiment of the present disclosure;
[0032] FIG. 24 illustrates the operation of the system of FIG. 1 to
provide automated social routing according to one embodiment of the
present disclosure;
[0033] FIG. 25 is a flow chart illustrating the operation of the
route-generation service of FIG. 24 to generate recommended routes
for the automated social routing process according to one
embodiment of the present disclosure;
[0034] FIG. 26 illustrates a process for scoring potential physical
waypoints based on social routing factors when generating the
recommended routes according to the process of FIG. 25 according to
one embodiment of the present disclosure;
[0035] FIG. 27 illustrates the operation of the MAP server to
generate historical aggregate profile data in response to a request
from the route-generation service of FIG. 1 as part of the
automated social routing process according to one embodiment of the
present disclosure;
[0036] FIG. 28 illustrates the operation of the MAP server to
generate aggregate profile data for current crowds in response to a
request from the route-generation service of FIG. 1 as part of the
automated social routing process according to one embodiment of the
present disclosure;
[0037] FIGS. 29A and 29B provide a flow chart illustrating the
operation of the route-generation service of FIG. 24 to generate
recommended routes for the automated social routing process
according to another embodiment of the present disclosure;
[0038] FIGS. 30-34 illustrate a Graphical User Interface (GUI) of
the navigation client of FIG. 1 according to one embodiment of the
present disclosure;
[0039] FIG. 35 illustrates a MAP system enabling automated social
routing according to another embodiment of the present
disclosure;
[0040] FIG. 36 is a block diagram of the MAP server of FIG. 1
according to one embodiment of the present disclosure;
[0041] FIG. 37 is a block diagram of one of the mobile devices of
FIG. 1 according to one embodiment of the present disclosure;
[0042] FIG. 38 is a block diagram of the subscriber device of FIG.
1 according to one embodiment of the present disclosure; and
[0043] FIG. 39 is a block diagram of the third-party server of FIG.
1 according to one embodiment of the present disclosure.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0044] 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
drawing figures, 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.
[0045] FIG. 1 illustrates a Mobile Aggregate Profile (MAP) system
10 according to one 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).
[0046] 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. 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.
[0047] 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 the Facebook.RTM. social
networking service, the MySpace.RTM. social networking service, the
LinkedIN.RTM. social networking service, 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.
[0048] 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.
[0049] 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. For example, as discussed below in detail, the MAP
client 30-1 enables the MAP application 32-1 to request anonymized
aggregate profiles for crowds of users located at a POI or within
an AOI and/or request anonymized historical user profile data for a
POI or AOI.
[0050] 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 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] Lastly, the third-party server 26 is a physical server
hosting route-generation service 40. The route-generation service
40 is preferably implemented in software and operates to provide
automated social routing. More specifically, as discussed below in
detail, the route-generation service 40 uses data obtained from the
MAP server 12 to provide automated social routing for users via
corresponding navigation clients. In this embodiment, the
route-generation service 40 provides automated social routing for
the user 20-1 via a navigation client 42 implemented on the mobile
device 18-1. The navigation client 42 is preferably implemented in
software, but is not limited thereto. Note that while the
navigation client 42 of the mobile device 18-1 of the user 20-1 is
used in this exemplary embodiment, the route-generation service 40
may additionally or alternatively provide automated social routing
for users of user devices (e.g., personal computers, personal
navigation devices, or the like) that are not registered with the
MAP server 12.
[0055] It should be noted that while the system 10 of FIG. 1
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.
[0056] Before proceeding, the focus of the present disclosure is
automated social routing which, in this embodiment, is provided by
the route-generation service 40 and navigation client 42. However,
before discussing the details of the automated social routing
process, a discussion of the other components of the system 10 is
beneficial and is provided with respect to FIGS. 2 through 23.
[0057] FIG. 2 is a block diagram of the MAP server 12 of FIG. 1
according to one embodiment of the present disclosure. As
illustrated, the MAP server 12 includes an application layer 44, a
business logic layer 46, and a persistence layer 48. The
application layer 44 includes a user web application 50, a mobile
client/server protocol component 52, and one or more data
Application Programming Interfaces (APIs) 54. The user web
application 50 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 52 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 54 enable
third-party services, such as the route-generation service 40, to
access the MAP server 12.
[0058] The business logic layer 46 includes a profile manager 56, a
location manager 58, a history manager 60, a crowd analyzer 62, and
an aggregation engine 64, each of which is preferably implemented
in software. The profile manager 56 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 48. The location manager 58
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.
[0059] The history manager 60 generally operates to maintain a
historical record of anonymized user profile data by location. The
crowd analyzer 62 operates to form crowds of users. In one
embodiment, the crowd analyzer 62 utilizes a spatial crowd
formation algorithm. However, the present disclosure is not limited
thereto. In addition, the crowd analyzer 62 may further
characterize crowds to reflect degree of fragmentation, best-case
and worst-case degree of separation (DOS), and/or degree of
bi-directionality. Still further, the crowd analyzer 62 may also
operate to track crowds. The aggregation engine 64 generally
operates to provide aggregate profile data in response to requests
from the mobile devices 18-1 through 18-N, the subscriber device
22, and the route-generation service 40. The aggregate profile data
may be historical aggregate profile data for one or more POIs or
one or more AOIs or aggregate profile data for crowd(s) currently
at one or more POIs or within one or more AOIs.
[0060] The persistence layer 48 includes an object mapping layer 66
and a datastore 68. The object mapping layer 66 is preferably
implemented in software. The datastore 68 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 46 is implemented in an object-oriented programming
language such as, for example, Java. As such, the object mapping
layer 66 operates to map objects used in the business logic layer
46 to relational database entities stored in the datastore 68. Note
that, in one embodiment, data is stored in the datastore 68 in a
Resource Description Framework (RDF) compatible format.
[0061] In an alternative embodiment, rather than being a relational
database, the datastore 68 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.
[0062] FIG. 3 illustrates the MAP client 30-1 of FIG. 1 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 70, a MAP middleware component 72,
and a mobile client/server protocol component 74. The MAP access
API 70 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 client 30-1. The MAP middleware component
72 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 74 enables communication between the MAP client
30-1 and the MAP server 12 via a defined protocol.
[0063] FIG. 4 illustrates the operation of the system 10 of FIG. 1
to provide the user profile and location 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 and locations 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 preformed 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).
[0064] 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.
[0065] 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 56
of the MAP server 12 processes the user profile (step 1002D). More
specifically, in the preferred embodiment, the profile manager 56
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, MySpace, and
LinkedIN, the profile manager 56 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
56 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 56 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, move genres, or the like for the movie
interests profile category. In one embodiment, the profile manager
56 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.
[0066] After processing the user profile of the user 20-1, the
profile manager 56 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 68 (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. In addition, as
discussed below, if the user 20-1 opts-in to an implicit, or
ambient, rating process, the user record of the user 20-1 may
include a historical record of the 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.
[0067] 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 56 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. As another
example, the users 20-1 may manually create the user profile of the
user 20-1.
[0068] 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.
[0069] In response to receiving the current location of the mobile
device 18-1, the location manager 58 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 68 of the
MAP server 12. In one 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. However, in
another embodiment, the user 20-1 may opt-in to an implicit, or
ambient, ratings process, where a historical record of the location
of the user 20-1 is included in the user record of the user 20-1 in
order to enable implicit ratings to be determined. This implicit
ratings process is described in detail below.
[0070] In addition to storing the current location of the user
20-1, the location manager 58 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.
[0071] 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 58 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.
[0072] FIG. 5 illustrates the operation of the system 10 of FIG. 1
to provide the user profile and current location of the user 20-1
of the mobile device 18-1 to the MAP server 12 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).
[0073] 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
56 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 56 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.
[0074] Upon receiving the user profile of the user 20-1, the
profile manager 56 of the MAP server 12 processes to the user
profile (step 1102C). More specifically, as discussed above, in the
preferred embodiment, the profile manager 56 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.
[0075] After processing the user profile of the user 20-1, the
profile manager 56 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 68 (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. In addition, as
discussed below, if the user 20-1 opts-in to an implicit, or
ambient, rating process, the user record of the user 20-1 may
include a historical record of the 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.
[0076] 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 56 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. As another
example, the users 20-1 may manually create the user profile of the
user 20-1.
[0077] 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.
[0078] In response to receiving the current location of the mobile
device 18-1, the location manager 58 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 68 of the
MAP server 12. In one 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. However, in
another embodiment, the user 20-1 may opt-in to an implicit, or
ambient, ratings process, where a historical record of the location
of the user 20-1 is included in the user record of the user 20-1 in
order to enable implicit ratings to be determined. This implicit
ratings process is described in detail below.
[0079] 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 58 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.
[0080] 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 60 of the MAP server 12. More specifically, as
illustrated in FIG. 6, in the preferred embodiment, the history
manager 60 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 76 through 92 have lists
of 1, 3, 2, 1, 1, 2, 1, 2, and 3 users, respectively.
[0081] As discussed below in detail, at a predetermined time
interval such as, for example, 15 minutes, the history manager 60
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).
[0082] FIG. 7 graphically illustrates a scenario where a user moves
from one location bucket to another, namely, from the location
bucket 78 to the location bucket 80. As discussed below in detail,
assuming that the movement occurs during the time interval between
persistence of the historical data by the history manager 60, the
user is included on both the list for the location bucket 78 and
the list for the location bucket 80. However, the user is flagged
or otherwise marked as inactive for the location bucket 78 and
active for the location bucket 80. 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 78 to the location bucket 80, the
user remains in the list for the location bucket 78 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 78.
[0083] FIG. 8 is a flow chart illustrating the operation of a
foreground "bucketization" process performed by the history manager
60 to maintain the lists of users for location buckets according to
one embodiment of the present disclosure. First, the history
manager 60 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 60 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 60 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.
[0084] After determining the location bucket for the location of
the user 20-1, the history manager 60 determines whether the user
20-1 is new to the location bucket (step 1204). In other words, the
history manager 60 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 60 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 60 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).
[0085] The history manager 60 then determines whether the user 20-1
has moved from another location bucket (step 1212). More
specifically, the history manager 60 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 60 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).
[0086] At this point, whether proceeding from step 1212 or 1214,
the history manager 60 determines whether it is time to persist
(step 1216). More specifically, as mentioned above, the history
manager 60 operates to persist history objects at a predetermined
time interval such as, for example, every 15 minutes. Thus, the
history manager 60 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 60 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 60. The history
manager 60 then removes inactive users from the lists of users for
the location buckets (step 1220). The process then returns to step
300 and is repeated for a next received location update, which will
typically be for another user.
[0087] FIG. 9 is a flow chart illustrating the anonymization and
storage process performed by the history manager 60 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 60 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 60 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.
[0088] 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 94. The user record 94 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 96-1 through 96-M.
Each of the profile category records 96-1 through 96-M includes a
user ID for the corresponding user which may be the same user ID
used in the user record 94, a category ID, and a list of keywords
for the profile category. Further, while not illustrated, if the
user 20-1 has opted-in to the implicit rating process, the user
record 94 may include a historical record of the location of the
user 20-1. The historical record of the location of the user 20-1
may include previous locations of the user 20-1 along with
timestamps indicating when the user 20-1 was at those
locations.
[0089] For anonymization, an anonymous user record 98 is created
from the user record 94. In the anonymous user record 98, 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.
[0090] In addition, anonymous profile category records 100-1
through 100-M are created for the profile category records 96-1
through 96-M. In the anonymous profile category records 100-1
through 100-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
98. The anonymous profile category records 100-1 through 100-M
include the same category IDs and lists of keywords as the
corresponding profile category records 96-1 through 96-M. Note that
the location of the user is not stored in the anonymous user record
98. With respect to location, it is sufficient that the anonymous
user record 98 is linked to a location bucket.
[0091] In another embodiment, the history manager 60 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.
[0092] In yet another embodiment, rather than creating anonymous
user records 98 for the users in the lists maintained for the
location buckets, the history manager 60 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 60 is
not connected back to the users 20-1 through 20-N.
[0093] 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 60 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 60 then stores a history
object for each node in the quadtree data structure having at least
one user (step 1402).
[0094] 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.
[0095] 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.
[0096] In order to form the quadtree data structure, the history
manager 60 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 60 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 60 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.
[0097] 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 60
creates a number of child nodes for the current node (step 1506).
More specifically, the history manager 60 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.
[0098] 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 60 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 60 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 60 determines whether the current node has a parent
node (step 1516). If so, since the parent node has already been
processed, the history manager 60 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 60 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
60 can then store the history objects for nodes in the quadtree
data structure having at least one user (step 1522).
[0099] 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 102. FIG. 13A illustrates the base
quadtree region 102. As illustrated, the base quadtree region 102
is an 8.times.8 square of location buckets, where each of the small
squares represents a location bucket. First, the history manager 60
determines whether the number of users in the base quadtree region
102 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 102 is greater than
3, the history manager 60 divides the base quadtree region 102 into
four child nodes 104-1 through 104-4, as illustrated in FIG.
13B.
[0100] Next, the history manager 60 determines whether the number
of users in the child node 104-1 is greater than the predetermined
maximum, which again for this example is 3. Since the number of
users in the child node 104-1 is greater than 3, the history
manager 60 divides the child node 104-1 into four child nodes 106-1
through 106-4, as illustrated in FIG. 13C. The child nodes 106-1
through 106-4 are children of the child node 104-1. The history
manager 60 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 there are more than 3 users in the
child node 106-1, the history manager 60 further divides the child
node 106-1 into four child nodes 108-1 through 108-N, as
illustrated in FIG. 13D.
[0101] The history manager 60 then determines whether the number of
users in the child node 108-1 is greater than the predetermined
maximum number of users, which again is 3. Since the number of
users in the child node 108-1 is not greater than the predetermined
maximum number of users, the child node 108-1 is identified as a
node for the finished quadtree data structure, and the history
manager 60 proceeds to process the sibling nodes of the child node
108-1, which are the child nodes 108-2 through 108-4. Since the
number of users in each of the child nodes 108-2 through 108-4 is
less than the predetermined maximum number of users, the child
nodes 108-2 through 108-4 are also identified as nodes for the
finished quadtree data structure.
[0102] Once the history manager 60 has finished processing the
child nodes 108-1 through 108-4, the history manager 60 identifies
the parent node of the child nodes 108-1 through 108-4, which in
this case is the child node 106-1. The history manager 60 then
processes the sibling nodes of the child node 106-1, which are the
child nodes 106-2 through 106-4. In this example, the number of
users in each of the child nodes 106-2 through 106-4 is less than
the predetermined maximum number of users. As such, the child nodes
106-2 through 106-4 are identified as nodes for the finished
quadtree data structure.
[0103] Once the history manager 60 has finished processing the
child nodes 106-1 through 106-4, the history manager 60 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 60 then
processes the sibling nodes of the child node 104-1, which are the
child nodes 104-2 through 104-4. More specifically, the history
manager 60 determines that the child node 104-2 includes more than
the predetermined maximum number of users and, as such, divides the
child node 104-2 into four child nodes 110-1 through 110-4, as
illustrated in FIG. 13E. Because the number of users in each of the
child nodes 110-1 through 110-4 is not greater than the
predetermined maximum number of users, the child nodes 110-1
through 110-4 are identified as nodes for the finished quadtree
data structure. Then, the history manager 60 proceeds to process
the child nodes 104-3 and 104-4. Since the number of users in each
of the child nodes 104-3 and 104-4 is not greater than the
predetermined maximum number of users, the child nodes 104-3 and
104-4 are identified as nodes for the finished quadtree data
structure. Thus, at completion, the quadtree data structure for the
base quadtree region 102 includes the child nodes 108-1 through
108-4, the child nodes 106-2 through 106-4, the child nodes 110-1
through 110-4, and the child nodes 104-3 and 104-4, as illustrated
in FIG. 13E.
[0104] As discussed above, the history manager 60 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 60 stores history objects for the child nodes 108-2 and
108-3, the child nodes 106-2 and 106-4, the child nodes 110-1 and
110-4, and the child node 104-3. However, no history objects are
stored for the nodes that do not have any users (i.e., the child
nodes 108-1 and 108-4, the child node 106-3, the child nodes 110-2
and 110-3, and the child node 104-4).
[0105] FIG. 14 illustrates the operation of the system 10 of FIG. 1
wherein a mobile device is enabled to request and receive
historical aggregate profile data from the MAP server 12 according
to one embodiment of the present disclosure. 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.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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.
[0110] 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 60 of the MAP server 12. First, the history
manager 60 obtains history objects that are relevant to the
historical request from the datastore 68 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 60 then processes the relevant history objects
to provide historical aggregate profile data for the POI or AOI in
a time context and/or a geographic context. 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.
[0111] For the time context, the history manager 60 divides the
time window for the historical request into a number of time bands.
Each time band is a fragment of the time window. Then, for each
time band, the history manager 60 identifies a subset of the
relevant history objects that are relevant to the time band (i.e.,
history objects recorded for time periods within the time band or
that overlap the time band) and generates an aggregate profile for
each of those history objects based on the user profiles of the
anonymous user records in the history objects and the user profile,
or a select subset of the user profile, of the user 20-1. Then, the
history manager 60 averages or otherwise combines the aggregate
profiles for the history objects relevant to the time band. The
resulting data for the time bands forms historical aggregate
profile data that is to be returned to the MAP client 30-1, as
discussed below.
[0112] For the geographic context, the history manager 60 generates
an average aggregate profile for each of a number of grids
surrounding the POI or within the AOI. More specifically, history
objects relevant to the POI or the AOI and the time window of the
historical request are obtained. Then, the user profiles of the
anonymous users in the relevant history objects are used to
generate average aggregate profiles for a number of grids, or
geographic regions, at or surrounding the POI or the AOI. These
average aggregate profiles for the grids form historical aggregate
profile data that is to be returned to the MAP client 30-1, as
discussed below.
[0113] 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). As discussed
above, the historical aggregate profile data may be in a time
context or a geographic context. In an alternative embodiment, the
data returned to the MAP client 30-1 may be raw historical data.
The raw historical data may be the relevant history objects or data
from the relevant history objects such as, for example, the user
records in the relevant history objects, the user profiles of the
anonymous user records in the relevant history objects, or the
like.
[0114] 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). Note that in an alternative
embodiment where the data returned by the MAP server 12 is raw
historical data, the MAP client 30-1 may process the raw historical
data to provide desired data. For example, the MAP client 30-1 may
process the raw historical data in order to generate average
aggregate profiles for time bands within the time window of the
historical request and/or to generate average aggregate profiles
for regions near the POI or within the AOI of the historical
request in a manner similar to that described above. The MAP
application 32-1 then presents the historical aggregate profile
data to the user 20-1 (step 1610).
[0115] While not essential for understanding the present
disclosure, for more information regarding generating the
historical aggregate profile data in the time context and/or the
geographic context, 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.
[0116] FIG. 15 illustrates the operation of the system 10 of FIG. 1
wherein the subscriber device 22 is enabled to request and receive
historical aggregate profile data from the MAP server 12 according
to one embodiment of the present disclosure. As illustrated, in
this embodiment, the subscriber device 22 sends a historical
request to the MAP server 12 (step 1700). The subscriber device 22
sends the historical request to the MAP server 12 via the web
browser 38. In one embodiment, the historical request identifies
either a POI or an AOI and a time window. The historical request
may be made in response to user input from the subscriber 24 of the
subscriber device 22 or made automatically in response to an event
such as, for example, navigation to a website associated with a POI
(e.g., navigation to a website of a restaurant).
[0117] Upon receiving the historical request, the MAP server 12
processes the historical request (step 1702). More specifically, as
discussed above, the historical request is processed by the history
manager 60 of the MAP server 12. First, the history manager 60
obtains history objects that are relevant to the historical request
from the datastore 68 of the MAP server 12. The relevant history
objects are those relevant to the POI or the AOI and the time
window for the historical request. The history manager 60 then
processes the relevant history objects to provide historical
aggregate profile data for the POI or the AOI in a time context
and/or a geographic context. In this embodiment, the historical
aggregate profile data is based on comparisons of the user profiles
of the anonymous user records in the relevant history objects to
one another. In another embodiment, the aggregate profile data is
based on comparisons of the user profiles of the anonymous user
records in the relevant history objects and a target user
profile.
[0118] Once the MAP server 12 has processed the historical request,
the MAP server 12 returns the resulting historical aggregate
profile data to the subscriber device 22 (step 1704). The
historical aggregate profile data may be in the time context or the
geographic context. In this embodiment where the historical
aggregate profile data is to be presented via the web browser 38 of
the subscriber device 22, the MAP server 12 formats the historical
aggregate profile data in a suitable format before sending the
historical aggregate profile data to the web browser 38 of the
subscriber device 22. Upon receiving the historical aggregate
profile data, the web browser 38 of the subscriber device 22
presents the historical aggregate profile data to the user 20-1
(step 1706).
[0119] FIG. 16 begins a discussion of the operation of the crowd
analyzer 62 to form crowds of users according to one embodiment of
the present disclosure. Specifically, FIG. 16 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 62 as, for example, a background
process.
[0120] First, the crowd analyzer 62 establishes a bounding box for
the crowd formation process (step 1800). 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.
[0121] The crowd analyzer 62 then creates a crowd for each
individual user in the bounding box (step 1802). More specifically,
the crowd analyzer 62 queries the datastore 68 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 62 determines the
two closest crowds in the bounding box (step 1804) and determines a
distance between the two crowds (step 1806). 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 user is the
current location of the user in the crowd. The crowd analyzer 62
then determines whether the distance between the two crowds is less
than an optimal inclusion distance (step 1808). 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 62 combines the two crowds
(step 1810) and computes a new crowd center for the resulting crowd
(step 1812). 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 1804 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 62 discards any crowds with less than three users (step
1814). 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.
[0122] FIGS. 17A through 17D graphically illustrate the crowd
formation process of FIG. 16 for an exemplary bounding box 112. In
FIGS. 17A through 17D, crowds are noted by dashed circles, and the
crowd centers are noted by cross-hairs (+). As illustrated in FIG.
17A, initially, the crowd analyzer 62 creates crowds 114 through
122 for the users in the geographic area, where, at this point,
each of the crowds 114 through 122 includes one user. The current
locations of the users are the crowd centers of the crowds 114
through 122. Next, the crowd analyzer 62 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 116 and
118, and the distance between the two closest crowds 116 and 118 is
less than the optimal inclusion distance. As such, the two closest
crowds 116 and 118 are combined by merging crowd 118 into crowd
116, and a new crowd center (+) is computed for the crowd 116, as
illustrated in FIG. 17B. Next, the crowd analyzer 62 again
determines the two closest crowds, which are now crowds 114 and
116. The crowd analyzer 62 then determines a distance between the
crowds 114 and 116. Since the distance is less than the optimal
inclusion distance, the crowd analyzer 62 combines the two crowds
114 and 116 by merging the crowd 114 into the crowd 116, and a new
crowd center (+) is computed for the crowd 116, as illustrated in
FIG. 17C. At this point, there are no more crowds separated by less
than the optimal inclusion distance. As such, the crowd analyzer 62
discards crowds having less than three users, which in this example
are crowds 120 and 122. As a result, at the end of the crowd
formation process, the crowd 116 has been formed with three users,
as illustrated in FIG. 17D.
[0123] FIGS. 18A through 18D 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 62 receives a location update, or a
new location, for a user (step 1900). Assume that, for this
example, the location update is received for the user 20-1. In
response, the crowd analyzer 62 retrieves an old location of the
user 20-1, if any (step 1902). The old location is the current
location of the user 20-1 prior to receiving the new location. The
crowd analyzer 62 then creates a new bounding box of a
predetermined size centered at the new location of the user 20-1
(step 1904) and an old bounding box of a predetermined size
centered at the old location of the user 20-1, if any (step 1906).
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 1900 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.
[0124] Next, the crowd analyzer 62 determines whether the new and
old bounding boxes overlap (step 1908). If so, the crowd analyzer
62 creates a bounding box encompassing the new and old bounding
boxes (step 1910). 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 62 may create a 79.times.79 meter square bounding box
encompassing both the new and old bounding boxes.
[0125] The crowd analyzer 62 then determines the individual users
and crowds relevant to the bounding box created in step 1910 (step
1912). 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 62 computes an optimal inclusion distance for individual
users based on user density within the bounding box (step 1914).
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.
[0126] The crowd analyzer 62 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 1916). At
this point, the process proceeds to FIG. 18B where the crowd
analyzer 62 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 1918). Any crowd member that violates the optimal inclusion
distance of his or her crowd is then removed from that crowd (step
1920). The crowd analyzer 62 then creates a crowd of one user for
each of the users removed from their crowds in step 1920 and sets
the optimal inclusion distance for the newly created crowds to the
initial optimal inclusion distance (step 1922).
[0127] Next, the crowd analyzer 62 determines the two closest
crowds for the bounding box (step 1924) and a distance between the
two closest crowds (step 1926). The distance between the two
closest crowds is the distance between the crowd centers of the two
closest crowds. The crowd analyzer 62 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
1928). 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 62 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 62 may
compare the distance between the two closest crowds to an average
of the optimal inclusion distances of the two closest crowds.
[0128] If the distance between the two closest crowds is less than
the optimal inclusion distance, the two closest crowds are combined
or merged (step 1930), and a new crowd center for the resulting
crowd is computed (step 1932). 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 1934). 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
) , optimial_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, 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.
[0129] At this point, the crowd analyzer 62 determines whether a
maximum number of iterations have been performed (step 1936). The
maximum number of iterations is a predefined number that ensures
that the crowd formation process does not indefinitely loop over
steps 1918 through 1934 or loop over steps 1918 through 1934 more
than a desired maximum number of times. If the maximum number of
iterations has not been reached, the process returns to step 1918
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 62 discards crowds with less than
three users, or members (step 1938) and the process ends.
[0130] Returning to step 1908 in FIG. 18A, if the new and old
bounding boxes do not overlap, the process proceeds to FIG. 18C and
the bounding box to be processed is set to the old bounding box
(step 1940). In general, the crowd analyzer 62 then processes the
old bounding box in much the same manner as described above with
respect to steps 1912 through 1938. More specifically, the crowd
analyzer 62 determines the individual users and crowds relevant to
the bounding box (step 1942). 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 62 computes an optimal inclusion
distance for individual users based on user density within the
bounding box (step 1944). 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.
[0131] The crowd analyzer 62 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 1946). At
this point, the crowd analyzer 62 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 1948). Any crowd member that violates the optimal inclusion
distance of his or her crowd is then removed from that crowd (step
1950). The crowd analyzer 62 then creates a crowd of one user for
each of the users removed from their crowds in step 1950 and sets
the optimal inclusion distance for the newly created crowds to the
initial optimal inclusion distance (step 1952).
[0132] Next, the crowd analyzer 62 determines the two closest
crowds in the bounding box (step 1954) and a distance between the
two closest crowds (step 1956). The distance between the two
closest crowds is the distance between the crowd centers of the two
closest crowds. The crowd analyzer 62 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
1958). 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 62 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 62 may
compare the distance between the two closest crowds to an average
of the optimal inclusion distances of the two closest crowds.
[0133] If the distance between the two closest crowds is less than
the optimal inclusion distance, the two closest crowds are combined
or merged (step 1960), and a new crowd center for the resulting
crowd is computed (step 1962). 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 1964). 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
) , optimial_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, 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.
[0134] At this point, the crowd analyzer 62 determines whether a
maximum number of iterations have been performed (step 1966). If
the maximum number of iterations has not been reached, the process
returns to step 1948 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 62
discards crowds with less than three users, or members (step 1968).
The crowd analyzer 62 then determines whether the crowd formation
process for the new and old bounding boxes is done (step 1970). In
other words, the crowd analyzer 62 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 1972), and the process
returns to step 1942 and is repeated for the new bounding box. Once
both the new and old bounding box have been processed, the crowd
formation process ends.
[0135] FIGS. 19A through 19D graphically illustrate the crowd
formation process of FIGS. 18A through 18D 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
62 creates a new bounding box 124 for the new location of the user,
and the new bounding box 124 is set as the bounding box to be
processed for crowd formation. Then, as illustrated in FIG. 19A,
the crowd analyzer 62 identifies all individual users currently
located within the bounding box 124 and all crowds located within
or overlapping the bounding box. In this example, crowd 126 is an
existing crowd relevant to the bounding box 124. Crowds are
indicated by dashed circles, crowd centers are indicated by
cross-hairs (+), and users are indicated as dots. Next, as
illustrated in FIG. 19B, the crowd analyzer 62 creates crowds 128
through 132 of one user for the individual users, and the optional
inclusion distances of the crowds 128 through 132 are set to the
initial optimal inclusion distance. As discussed above, the initial
optimal inclusion distance is computed by the crowd analyzer 62
based on a density of users within the bounding box 124.
[0136] The crowd analyzer 62 then identifies the two closest crowds
128 and 130 in the bounding box 124 and determines a distance
between the two closest crowds 128 and 130. In this example, the
distance between the two closest crowds 128 and 130 is less than
the optimal inclusion distance. As such, the two closest crowds 128
and 130 are merged and a new crowd center and new optimal inclusion
distance are computed, as illustrated in FIG. 19C. The crowd
analyzer 62 then repeats the process such that the two closest
crowds 128 and 132 in the bounding box 124 are again merged, as
illustrated in FIG. 19D. At this point, the distance between the
two closest crowds 126 and 128 is greater than the appropriate
optimal inclusion distance. As such, the crowd formation process is
complete.
[0137] FIGS. 20A through 20F graphically illustrate the crowd
formation process of FIGS. 18A through 18D for a scenario where the
new and old bounding boxes overlap. As illustrated in FIG. 20A, a
user moves from an old location to a new location, as indicated by
an arrow. The crowd analyzer 62 receives a location update for the
user giving the new location of the user. In response, the crowd
analyzer 62 creates an old bounding box 134 for the old location of
the user and a new bounding box 136 for the new location of the
user. Crowd 138 exists in the old bounding box 134, and crowd 140
exists in the new bounding box 136.
[0138] Since the old bounding box 134 and the new bounding box 136
overlap, the crowd analyzer 62 creates a bounding box 142 that
encompasses both the old bounding box 134 and the new bounding box
136, as illustrated in FIG. 20B. In addition, the crowd analyzer 62
creates crowds 144 through 150 for individual users currently
located within the bounding box 142. The optimal inclusion
distances of the crowds 144 through 150 are set to the initial
optimal inclusion distance computed by the crowd analyzer 62 based
on the density of users in the bounding box 142.
[0139] Next, the crowd analyzer 62 analyzes the crowds 138, 140,
and 144 through 150 to determine whether any members of the crowds
138, 140, and 144 through 150 violate the optimal inclusion
distances of the crowds 138, 140, and 144 through 150. In this
example, as a result of the user leaving the crowd 138 and moving
to his new location, both of the remaining members of the crowd 138
violate the optimal inclusion distance of the crowd 138. As such,
the crowd analyzer 62 removes the remaining users from the crowd
138 and creates crowds 152 and 154 of one user each for those
users, as illustrated in FIG. 20C.
[0140] The crowd analyzer 62 then identifies the two closest crowds
in the bounding box 142, which in this example are the crowds 148
and 150. Next, the crowd analyzer 62 computes a distance between
the two crowds 148 and 150. In this example, the distance between
the two crowds 148 and 150 is less than the initial optimal
inclusion distance and, as such, the two crowds 148 and 150 are
combined. In this example, crowds are combined by merging the
smaller crowd into the larger crowd. Since the two crowds 148 and
150 are of the same size, the crowd analyzer 62 merges the crowd
150 into the crowd 148, as illustrated in FIG. 20D. A new crowd
center and new optimal inclusion distance are then computed for the
crowd 148.
[0141] At this point, the crowd analyzer 62 repeats the process and
determines that the crowds 140 and 146 are now the two closest
crowds. In this example, the distance between the two crowds 140
and 146 is less than the optimal inclusion distance of the larger
of the two crowds 140 and 146, which is the crowd 140. As such, the
crowd 146 is merged into the crowd 140 and a new crowd center and
optimal inclusion distance are computed for the crowd 140, as
illustrated in FIG. 20E. 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 62 discards any crowds having
less than three members, as illustrated in FIG. 20F. In this
example, the crowds 144, 148, 152, and 154 have less than three
members and are therefore removed. The crowd 140 has three or more
members and, as such, is not removed. At this point, the crowd
formation process is complete.
[0142] FIGS. 21A through 21E graphically illustrate the crowd
formation process of FIGS. 18A through 18D in a scenario where the
new and old bounding boxes do not overlap. As illustrated in FIG.
21A, in this example, the user moves from an old location to a new
location. The crowd analyzer 62 creates an old bounding box 156 for
the old location of the user and a new bounding box 158 for the new
location of the user. Crowds 160 and 162 exist in the old bounding
box 156, and crowd 164 exists in the new bounding box 158. In this
example, since the old and new bounding boxes 156 and 158 do not
overlap, the crowd analyzer 62 processes the old and new bounding
boxes 156 and 158 separately.
[0143] More specifically, as illustrated in FIG. 21B, as a result
of the movement of the user from the old location to the new
location, the remaining users in the crowd 160 no longer satisfy
the optimal inclusion distance for the crowd 160. As such, the
remaining users in the crowd 160 are removed from the crowd 160,
and crowds 166 and 168 of one user each are created for the removed
users as shown in FIG. 21C. In this example, no two crowds in the
old bounding box 156 are close enough to be combined. As such,
processing of the old bounding box 156 is complete, and the crowd
analyzer 62 proceeds to process the new bounding box 158.
[0144] As illustrated in FIG. 21D, processing of the new bounding
box 158 begins by the crowd analyzer 62 creating a crowd 170 of one
user for the user. The crowd analyzer 62 then identifies the crowds
164 and 170 as the two closest crowds in the new bounding box 158
and determines a distance between the two crowds 164 and 170. In
this example, the distance between the two crowds 164 and 170 is
less than the optimal inclusion distance of the larger crowd, which
is the crowd 164. As such, the crowd analyzer 62 combines the
crowds 164 and 170 by merging the crowd 170 into the crowd 164, as
illustrated in FIG. 21E. A new crowd center and new optimal
inclusion distance are then computed for the crowd 164. At this
point, the crowd formation process is complete.
[0145] Before proceeding, a variation of the spatial formation
process discussed above with respect to FIGS. 18A through 18D, 19A
through 19D, 20A through 20F, and 21A through 21E will be
described. In this alternative embodiment, a location accuracy of
the location update from the user received in step 1900 is
considered. More specifically, in step 1900, 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 well be appreciated by one having
ordinary skill in the art.
[0146] Then, in steps 1902 and 1904, 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.
[0147] In addition, the location accuracy may be considered when
computing the initial optimal inclusion distances used for crowds
of one user in steps 1914 and 1944. 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.
[0148] Likewise, when new optimal inclusion distances for crowds
are recomputed in steps 1934 and 1964, 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, 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.
[0149] FIG. 22 illustrates the operation the system 10 of FIG. 1 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.
[0150] First, the MAP application 32-1 sends a crowd request to the
MAP client 30-1 (step 2000). 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.
[0151] 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.
[0152] Upon receiving the crowd request, the MAP client 30-1
forwards the crowd request to the MAP server 12 (step 2002). 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.
[0153] 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 2004). More specifically, in
one embodiment, the crowd analyzer 62 performs a crowd formation
process such as that described above in FIG. 16 to form one or more
crowds relevant to the POI or the AOI of the crowd request. In
another embodiment, the crowd analyzer 62 proactively forms crowds
using a process such as that described above in FIGS. 18A through
18D and stores corresponding crowd records in the datastore 68 of
the MAP server 12. Then, rather than forming the relevant crowds in
response to the crowd request, the crowd analyzer 62 queries the
datastore 68 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.
[0154] Once the crowd analyzer 62 has identified the crowds
relevant to the crowd request, the MAP server 12 generates crowd
data for the identified crowds (step 2006). 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 2008).
[0155] Upon receiving the crowd data, the MAP client 30-1 forwards
the crowd data to the MAP application 32-1 (step 2010). 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 2012). 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.
[0156] 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.
[0157] FIG. 23 illustrates the operation of the system 10 of FIG. 1
to enable the subscriber device 22 to request information regarding
current crowds according to one embodiment of the present
disclosure. First, subscriber device 22 sends a crowd request to
the MAP client 30-1 (step 2100). The crowd request is a request for
current crowds at a specified POI or AOI. The crowd request may be
initiated by the subscriber 24 at the subscriber device 22 via the
web browser 38 or a custom application enabled to access the MAP
server 12. Preferably, the subscriber 24 is enabled to identify the
POI or the AOI for the crowd request by, for example, selecting the
POI or the AOI on a map, selecting a crowd center of an existing
crowd as a POI, selecting a crowd location of an existing crowd as
a center of an AOI, selecting the POI or the AOI from a predefined
list of POIs and/or AOIs, or the like. The predefined list of POIs
and/or AOIs may be defined by, for example, the subscriber 24
and/or the MAP server 12.
[0158] In response to receiving the crowd request from the
subscriber device 22, the MAP server 12 identifies one or more
crowds relevant to the crowd request (step 2102). More
specifically, in one embodiment, the crowd analyzer 62 performs a
crowd formation process such as that described above in FIG. 16 to
form one or more crowds relevant to the POI or the AOI of the crowd
request. In another embodiment, the crowd analyzer 62 proactively
forms crowds using a process such as that described above in FIGS.
18A through 18D and stores corresponding crowd records in the
datastore 68 of the MAP server 12. Then, rather than forming the
relevant crowds in response to the crowd request, the crowd
analyzer 62 queries the datastore 68 to identify the crowds that
are relevant to the crowd request. The crowds relevant to the crowd
request may be those crowds within or overlapping 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.
[0159] Once the crowd analyzer 62 has identified the crowds
relevant to the crowd request, the MAP server 12 generates crowd
data for the identified crowds (step 2104). 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 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, or the like. The MAP
server 12 then returns the crowd data to the MAP client 30-1 (step
2106). In the embodiment where the subscriber 24 accesses the MAP
server 12 via the web browser 38 at the subscriber device 22, the
MAP server 12 formats the crowd data into a suitable web format
before sending the crowd data to the subscriber device 22. The
manner in which the crowd data is formatted depends on the
particular implementation. In one embodiment, the crowd data is
overlaid upon a map. For example, in one embodiment, the MAP server
12 may provide the crowd data to the subscriber device 22 via one
or more web pages. Using the one or more web pages, crowd
indicators representative of the locations of the crowds may be
overlaid on a map. The subscriber 24 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. Upon receiving the crowd data, the
subscriber device 22 presents the crowd data to the subscriber 24
(step 2108). Note that in one embodiment, the MAP server 12 may
roll-up the aggregate profiles for multiple crowds at a POI or in
an AOI to provide a rolled-up aggregate profile that may be
returned in addition to or as an alternative to the aggregate
profiles of the individual crowds.
[0160] It should be noted that in some embodiments, the subscriber
24 may be enabled to specify filtering criteria via the web browser
38 or a custom application for interacting with the MAP server 12.
For example, the subscriber 24 may specify filtering criteria
regarding types of crowds in which the subscriber 24 is or is not
interested. For instance, the crowd data may be presented to the
subscriber 24 via one or more web pages that enable the subscriber
24 to select a filtering feature. In response, a list of keywords
appearing in the user profiles of the crowds identified as being
relevant to the current request may be presented to the subscriber
24. The subscriber 24 may then specify one or more keywords from
the list such that crowds having users with user profiles that do
not include any of the specified keywords are filtered, or removed,
and are therefore not considered when generating the crowd data in
response to a crowd request.
[0161] While not essential for understanding the present
disclosure, for more information regarding generation of the crowd
data in steps 2006 and 2104 of FIGS. 22 and 23, respectively, the
interested reader is directed to U.S. patent application Ser. Nos.
12/645,535, 12/645,532, 12/645,539, 12/645,544, 12/645,546,
12/645,556, 12/645,560, all of which were filed on Dec. 23, 2009
and have been incorporated herein by reference in their
entireties.
[0162] FIG. 24 illustrates the operation of the route-generation
service 40 and the navigation client 42 of FIG. 1 to provide
automated social routing according to one embodiment of the present
disclosure. First, the navigation client 42 obtains weightings for
one or more routing factors, which are referred to herein as
routing factor weightings (step 2200). More specifically, the
route-generation service 40 performs automated social routing based
on one or more routing factors including one or more social routing
factors. The social routing factors include an aggregate profile
routing factor, an implicit rating factor, an explicit rating
factor, or a combination thereof. As discussed below in detail, the
aggregate profile routing factor uses historical aggregate profile
data for potential physical waypoints and/or aggregate profile data
for crowds currently located at potential physical waypoints when
selecting physical waypoints for recommended routes generated via
the automated social routing process. The implicit rating factor
uses implicit ratings of potential physical waypoints implicitly
made by other users in a requesting user's social network when
selecting physical waypoints for recommended routes generated via
the automated social routing process. In general, the implicit
ratings are determined based on a degree to which other users in
the requesting user's social network have visited the potential
physical waypoints in the past. Lastly, the explicit rating factor
uses explicit ratings of potential physical waypoints explicitly
made by other users when selecting physical waypoints for
recommended routes generated via the automated social routing
process. The other users for which explicit ratings are considered
may be all other users for which explicit ratings for the potential
physical waypoints are known, other users having user profiles
similar to that of the requesting user (i.e., other users like the
requesting user) for which explicit ratings for the potential
physical waypoints are known, or other users in a social network of
the requesting user for which explicit ratings for the potential
physical waypoints are known.
[0163] In addition to the social routing factors, the routing
factors used for the automated social routing process may include
additional factors such as travel time, travel distance, ease of
parking (e.g., whether nearby parking is available), travel costs
(e.g., gas costs for driving and/or cost of any toll roads),
ambiance, adventure, or the like. As discussed below, potential
physical waypoints for recommended routes are scored or otherwise
ranked based on the routing factors including the one or more
social routing factors and, optionally, one or more of these
additional routing factors when selecting physical waypoints for
recommended routes.
[0164] Thus, in step 2200, the navigation client 42 obtains
weightings for the routing factors to be used for the automated
social routing process. The weightings are preferably obtained from
an associated user, which in this embodiment is the user 20-1 of
the mobile device 18-1 on which the navigation client 42 is
implemented. In one embodiment, the user 20-1 assigns a weighting
of 1-10 to each of the routing factors. In the preferred
embodiment, the routing factors include one or more primary routing
factors (e.g., primary social routing factor, primary time factor,
etc.) each having a corresponding weighting assigned by the user
20-1. In addition, each of the primary routing factors preferably
includes one or more secondary routing factors having corresponding
weightings assigned by the user 20-1. For example, secondary social
routing factors may include an aggregate profile routing factor, an
implicit rating routing factor, and/or an explicit rating routing
factor, each of which has a corresponding weighting assigned by the
user 20-1. The navigation client 42 sends the routing factor
weightings to the route-generation service 40 (step 2202), and the
route-generation service 40 stores the routing factor weightings
(step 2204).
[0165] Next, the navigation client 42 obtains a starting point and
a stopping point for which the user 20-1 desires recommended routes
(step 2206). The navigation client 42 enables the user 20-1 to
enter the starting point and the stopping point using any suitable
technique such as, for example, entering street addresses
corresponding to the starting point and the stopping point,
selecting the starting point and the stopping point from a map, or
the like.
[0166] In this embodiment, the navigation client 42 also obtains
one or more abstract waypoints for the recommended routes from the
starting point to the stopping point (step 2208). As used herein,
an abstract waypoint is a descriptor that defines or can be used to
identify a desired class of physical, or actual, waypoints. For
example, an abstract waypoint may be "Grocery Store," which may be
used to identify physical, or actual, grocery stores (i.e.,
physical, or actual, waypoints) that may be used for the
recommended routes. As another example, an abstract waypoint may be
"Bicycle Light," which may be used to identify physical, or actual,
bicycle or sporting goods stores where the user 20-1 may find a
bicycle light. The navigation client 42 may obtain the abstract
waypoints by enabling the user 20-1 to manually enter the abstract
waypoints, enabling the user 20-1 to manually select the abstract
waypoints from user-defined list of abstract waypoints predefined
by the user 20-1, enabling the user 20-1 to manually select the
abstract waypoints from a system-defined list of abstract
waypoints, enabling the user 20-1 to manually select the abstract
waypoints from list of abstract waypoints imported from another
application such as a calendar of the user 20-1, or the like.
[0167] The navigation client 42 then generates and sends a route
recommendation request to the route-generation service 40 (step
2210). The route recommendation request includes the starting
point, the stopping point, and the abstract waypoints. The
route-generation service 40 then generates one or more recommended
routes from the starting point to the stopping point based on the
routing factors for the automated social routing process, the
routing factor weightings, and the abstract waypoints (step 2212).
While generation of the one or more recommended routes is discussed
in detail below, in general, the route-generation service 40
dynamically selects physical waypoints for the abstract waypoints
for each of a desired number of recommended routes based on the
routing factors and their corresponding weightings. For each
recommended route, the recommended route is generated from the
starting point to the stopping point through the physical waypoints
selected for the recommended route. The recommended routes are
returned to the navigation client (step 2214) where the recommended
routes are presented to the user 20-1 (step 2216).
[0168] At this point, the recommended routes are utilized by the
navigation client 42 (step 2218). The manner in which the
recommended routes are utilized may vary depending on the
particular implementation. In one embodiment, the navigation client
42 enables the user 20-1 to select one of the recommended routes
and then provides turn-by-turn directions to navigate the user 20-1
from the starting point to the stopping point in a manner similar
to that done by services such as Google.RTM. Maps or in a manner
similar to that done by portable or personal navigation devices. In
addition or alternatively, the navigation client 42 may enable the
user 20-1 to select and edit one of the recommended routes by, for
example, selecting a different physical waypoint for one of the
abstract waypoints, adding a new abstract or physical waypoint,
removing an abstract or physical waypoint, or the like. In some
cases, editing of one of the recommended routes may require
additional interaction with the route-generation service 40. Still
further, the navigation client 42 may enable the user 20-1 to
select one of the recommended routes and share that recommended
route with another user via e-mail, text messaging, or the like. In
a similar manner, the navigation client 42 may enable the user 20-1
to select one of the recommended routes and send that recommended
route to an associated personal navigation device connected to the
mobile device 18-1 via a local wireless connection (e.g.,
Bluetooth.RTM. connection) or a wired connection (e.g., a Universal
Serial Bus (USB) connection). Also, if the navigation client 42
were to be implemented on a static device such as, for example, a
personal computer of the user 20-1 rather than the mobile device
18-1 of the user 20-1, the user 20-1 may be enabled to select and
send one of the recommended routes to the mobile device 18-1 via a
wired or wireless connection. Note that the aforementioned uses of
the recommended routes are exemplary and are not intended to limit
the scope of the present disclosure.
[0169] FIG. 25 is a flow chart illustrating step 2212 of FIG. 24 in
more detail according to one embodiment of the present disclosure.
In this embodiment, in order to generate the recommended routes,
the route-generation service 40 first obtains an optimal base route
from the starting point to the stopping point identified by the
user 20-1 (i.e., the requestor) and included in the route
recommendation request (step 2300). The optimal base route may be
obtained using any suitable technique. In one embodiment, the
route-generation service 40 generates the optimal base route from
the starting point to the stopping point using an algorithm similar
to that employed by conventional routing services such as, for
example, Google.RTM. Maps. The optimal base route is preferably a
shortest route in distance and/or time between the starting point
and the stopping point. In another embodiment, the route-generation
service 40 uses a remote service such as, for example, Google.RTM.
Maps to obtain the optimal base route from the starting point to
the stopping point.
[0170] Next, the route-generation service 40 generates a random
ordering of the abstract waypoints for each of a desired number of
recommended routes (step 2302). In other words, if the desired
number of recommended routes is four (4), the route-generation
service 40 generates four different random orderings of the
abstract waypoints for the four recommended routes. Each of the
recommended routes has a different random ordering of the abstract
waypoints. For example, if the abstract waypoints are dry cleaner,
fish market, bicycle shop, and wine shop, then a first random
ordering of the abstract waypoints for a first recommended route
may be fish market, wine shop, dry cleaner, and bicycle shop; a
second random ordering of the abstract waypoints for a second
recommended route may be bicycle shop, wine shop, fish market, and
dry cleaner; etc.
[0171] The route-generation service 40 gets, or obtains, a first
random ordering of the abstract waypoints generated for a first
recommended route (step 2304). The route-generation service 40 then
initializes the recommended route, which for this iteration is the
first recommended route, to the optimal base route from the
starting point to the stopping point (step 2306). Next, the
route-generation service 40 gets the first abstract waypoint from
the random ordering of the abstract waypoints being processed,
which for this iteration is the first random ordering of the
abstract waypoints for the first recommended route (step 2308).
[0172] The route-generation service 40 then identifies potential
physical waypoints for the abstract waypoint (step 2310). In the
preferred embodiment, the route-generation service 40 identifies
potential physical waypoints for the abstract waypoint that are
within a predefined divergence distance from the recommended route.
For the first iteration, the recommended route is the optimal base
route. As such, the route-generation service 40 identifies
potential physical waypoints for the abstract waypoint that are
within the predefined divergence distance from the optimal base
route. However, for subsequent iterations, physical waypoints have
been selected for the recommended route and the recommended route
has been updated accordingly. Since the divergence distance is
relative to the recommended route, the geographic area about the
recommended route in which potential physical waypoints for the
recommended route are identified will change as the recommended
route changes due to the selection of physical waypoints.
[0173] The divergence distance may be an absolute divergence
distance such as, for example, one mile from the recommended route.
Alternatively, the divergence distance may be a relative distance
that is a function of a total distance of the recommended route.
For example, the divergence distance may be five percent (5%) of
the total distance of the recommended route. So, if the total
distance of the recommended route is ten miles, the divergence
distance would be a half of a mile. As another alternative, the
divergence distance may be a combination of a static distance and a
relative distance. For example, the divergence distance may be five
percent of the total distance of the recommended route up to a
maximum divergence distance of three miles. So, if the total
distance of the recommended route is fifty miles, the divergence
distance would be two and a half miles. However, if the total
distance of the recommended route is one-hundred miles, the
divergence distance would be capped at the three mile maximum.
[0174] In the preferred embodiment, the route-generation service 40
maintains or has access to a local or remote database of known
physical waypoints. The known physical waypoints are POIs such as,
for example, restaurants, gas stations, grocery stores, shopping
malls, golf courses, movie theaters, movie rental stores, Automatic
Teller Machine (ATM) locations, and the like. For each known
physical waypoint, the database of physical waypoints includes a
location of the known physical waypoint and metadata describing the
known physical waypoint. For example, for a particular restaurant
(e.g., Mike's Pizza Shop), the database of physical waypoints
stores an entry for the restaurant that includes the location of
the restaurant and metadata describing the restaurant such as a
type of cuisine served at the restaurant (e.g., pizza), hours of
operation, parking availability, cost (e.g., $10 per person), or
the like. The location of a physical waypoint may be expressed as a
street address, a pair of latitude and longitude coordinates, or
the like. The route-generation service 40 then queries the physical
waypoints database to identify potential physical waypoints that
match the abstract waypoint and are within the divergence distance
from the recommended route.
[0175] Next, the route-generation service 40 scores or otherwise
ranks the potential physical waypoints identified for the abstract
waypoint based on the routing factors and the corresponding routing
factor weightings obtained for the user 20-1 associated with the
navigation client 42 (step 2312). The route-generation service 40
then selects a physical waypoint for the recommended route from the
potential physical waypoints identified for the abstract waypoint
based on the scores of the potential physical waypoints (step
2314). In one embodiment, the potential physical waypoint selected
as the physical waypoint for the recommended route is the potential
physical waypoint having the highest score. The route-generation
service 40 then updates the recommended route to include the
selected physical waypoint (step 2316). Note that in some cases,
there may be no potential physical waypoints identified for the
abstract waypoint within the divergence distance from the
recommended route. When there are no potential physical waypoints
for an abstract waypoint, steps 2312 through 2316 may be skipped
and processing may proceed to step 2318.
[0176] At this point, the route-generation service 40 determines
whether the last abstract waypoint in the random ordering of
waypoints for the recommended route has been processed (step 2318).
If not, the route-generation service 40 gets the next abstract
waypoint in random ordering of abstract waypoints for the
recommended route (step 2320) and the process returns to step 2310.
Once all of the abstract waypoints in the random ordering of the
abstract waypoints for the recommended route have been processed,
the route-generation service 40 determines whether the last
recommended route has been generated (step 2322). If not, the
route-generation service 40 gets the next random ordering of the
abstract waypoints for the next recommended route (step 2324) and
then the process returns to step 2306 and is repeated to generate
the next recommended route. Once the desired number of recommended
routes have been generated, the process ends.
[0177] FIG. 26 illustrates the operation of the route-generation
service 40 to score each of the potential physical waypoints in
step 2312 of FIG. 25 according to one embodiment of the present
disclosure. In this embodiment, in order to score a potential
physical waypoint, the route-generation service 40 sends an
aggregate profile data request to the MAP server 12 for the
potential physical waypoint (step 2400). The aggregate profile data
request identifies the location of the potential physical waypoint
as a POI for the aggregate profile data request or identifies an
AOI centered at the location of the potential physical waypoint as
an AOI for the aggregate profile data request. In response to the
aggregate profile data request, the MAP server 12 generates or
otherwise obtains aggregate profile data for the potential physical
waypoint (step 2402) and returns the aggregate profile data to the
route-generation service (step 2404).
[0178] In one embodiment, the aggregate profile data request is a
request for historical aggregate profile data for the potential
physical waypoint for a defined time window. As such, as discussed
below in detail, the aggregate profile data returned to the
route-generation service 40 for the potential physical waypoint
preferably includes data indicative of aggregate interests of users
historically located at the potential physical waypoint during the
defined time window. In another embodiment, the aggregate profile
data request is a request for aggregate profile(s) for crowd(s)
currently located at the potential physical waypoint. The aggregate
profile data returned to the route-generation service 40 for the
potential physical waypoint preferably includes data indicative of
aggregate interests of users in crowds currently located at the
potential physical waypoint. In yet another embodiment, the
aggregate profile data request is a request for both historical
aggregate profile data for the potential physical waypoint and
aggregate profile data for crowd(s) currently located at the
potential physical waypoint. In this case, the aggregate profile
data returned to the route-generation service 40 for the potential
physical waypoint preferably includes data indicative of aggregate
interests of users historically located at the potential physical
waypoint during the defined time window and data indicative of
aggregate interests of users in crowds currently located at the
potential physical waypoint.
[0179] In this embodiment, in additional to requesting aggregate
profile data, the route-generation service 40 requests an implicit
rating for the potential physical waypoint to the MAP server 12
(step 2406). In response, the MAP server 12 obtains an implicit
rating for the potential physical waypoint by other users in a
social network of the requesting user, which in this example is the
user 20-1, and returns the implicit rating to the route-generation
service 40 (steps 2408 and 2410). Information identifying users in
the social network of the user 20-1 is preferably obtained from the
profile server 14 and stored in the user record of the user 20-1 at
the MAP server 12. More specifically, in one embodiment, users are
enabled to opt-in to the implicit rating process. For any of the
users 20-1 through 20-N that have opted-in to the implicit rating
process, the user records of those users includes location
histories of those users. Using the user 20-N as an example, if the
user 20-N opts-in to the implicit rating process, the user record
of the user 20-N includes a location history of the user 20-N. The
location history of the user 20-N includes information defining
where the user 20-N has been located in the past. For example, the
location history of the user 20-N may include past locations of the
user 20-N along with corresponding timestamps defining when the
user 20-N was at those locations.
[0180] In order to obtain the implicit rating of the potential
physical waypoint, the MAP server 12 examines the location
histories of users from the users 20-2 through 20-N that are in the
social network of the user 20-1 and have opted-in to the implicit
rating process to determine a degree to which those users have
visited the potential physical waypoint in the past. More
specifically, in one embodiment, the MAP server 12 determines the
number of times those users have been located at the potential
physical waypoint and, optionally, the amount of time that those
users have been located at the potential physical waypoint. Based
on this information, the MAP server 12 establishes the implicit
rating for the potential physical waypoint. For example, the
implicit rating may be a value of 0 to 10 calculated as a function
of the number of times the users in the social network of the user
20-1 have been located at the potential physical waypoint and/or
the amount of time that the users in the social network of the user
20-1 have been located at the potential physical waypoint. As a
more specific example, the implicit rating may be set according to
Table 1 below.
TABLE-US-00001 TABLE 1 Percentage of Users Implicit Rating <5% 0
5%-15% 1 15%-25% 2 25%-35% 3 35%-45% 4 45%-55% 5 55%-65% 6 65%-75%
7 75%-85% 8 85%-95% 9 >95% 10
In Table 1, "Percentage of Users" is the percentage of the users in
the social network of the user 20-1 that have been located at the
potential physical waypoint within a predetermined previous amount
of time (e.g., within the last month). Note that the aforementioned
embodiments for obtaining the implicit rating of the potential
physical waypoint are exemplary and not intended to limit the scope
of the present disclosure.
[0181] While in this embodiment the MAP server 12 returns a single
implicit rating for the potential physical waypoint, in an
alternative embodiment, the MAP server 12 may return an individual
implicit rating for the potential physical waypoint for each user
in the social network of the user 20-1 (or at least those users in
the social network of the user 20-1 that have visited the potential
physical waypoint). The route-generation service 40 may then
combine the individual implicit ratings of the users in the social
network of the user 20-1 to provide the implicit rating for the
potential physical waypoint. Further, in one embodiment, the user
20-1 may be enabled to assign weightings to the users in the social
network of the user 20-1 such that the implicit ratings of the
users are combined according to their weightings (e.g., using a
weighted average).
[0182] Still further, in this embodiment, the route-generation
service 40 requests explicit ratings for the potential physical
waypoint (step 2412). In order to accommodate this request, in this
embodiment, the MAP server 12 further operates to maintain a
database of explicit ratings for POIs made by the users 20-1
through 20-N. Thus, in response to receiving the explicit rating
request for the potential physical waypoint, the MAP server 12
obtains an explicit rating for the potential physical waypoint and
returns the explicit rating to the route-generation service 40
(steps 2414 and 2416). In one embodiment, the MAP server 12 returns
an explicit rating for the potential physical waypoint that results
from all explicit ratings made for the potential physical waypoint
by any of the users 20-1 through 20-N. For example, the explicit
rating returned to the route-generation service may be an average
or weighted average of all explicit ratings for the potential
physical waypoint made by the users 20-1 through 20-N.
[0183] In another embodiment, the MAP server 12 returns an explicit
rating for the potential physical waypoint that results from only
those explicit ratings for the potential physical waypoint made by
other users from the users 20-2 through 20-N that are in the social
network of the user 20-1. For example, the explicit rating returned
to the route-generation service may be an average or weighted
average of all explicit ratings for the potential physical waypoint
made by those users from the users 20-2 through 20-N that are in
the social network of the user 20-1. In yet another embodiment, the
MAP server 12 returns only those explicit ratings for the potential
physical waypoint made by other users from the users 20-2 through
20-N that that are like the user 20-1. The other users 20-2 through
20-N are like the user 20-1 if the user profiles of the other users
20-2 through 20-N match the user profile of the user 20-1 to a
predefined threshold degree. For example, the explicit rating
returned to the route-generation service may be an average or
weighted average of all explicit ratings for the potential physical
waypoint made by any of the users 20-2 through 20-N that are like
the user 20-1. It should be noted that in an alternative embodiment
the explicit ratings for the potential waypoint are obtained by the
route-generation service 40 from a service such as Yelp, Urban
Spoon, or the like.
[0184] While in this embodiment the MAP server 12 returns a single
explicit rating for the potential physical waypoint, in an
alternative embodiment, the MAP server 12 may return an individual
explicit rating for the potential physical waypoint for each user
in the social network of the user 20-1 (or at least those users in
the social network of the user 20-1 that have visited the potential
physical waypoint). The route-generation service 40 may then
combine the individual explicit ratings of the users in the social
network of the user 20-1 to provide the explicit rating for the
potential physical waypoint. Further, in one embodiment, the user
20-1 may be enabled to assign weightings to the users in the social
network of the user 20-1 such that the explicit ratings of the
users are combined according to their weightings (e.g., using a
weighted average).
[0185] Lastly, the route-generation service 40 generates the score
for the potential physical waypoint based on the aggregate profile
data, the implicit rating, and the explicit rating for the
potential physical waypoint (step 2418). More specifically, in the
preferred embodiment, the score for the potential physical waypoint
is computed as:
Score = Social WEIGHT Social SCORE + i = 1 NF ( Additional_Factor
WEIGHT , i Additional_Factor SCORE , i ) Social WEIGHT + i = 1 NF
Additional_Factor WEIGHT , i , ##EQU00007##
where Score is the score of the potential physical waypoint,
Social.sub.WEIGHT is the social weighting factor for the user 20-1,
and Social.sub.SCORE is a score generated for the potential
physical waypoint based on the social routing factors.
Additional_Factor.sub.WEIGHT,I is the routing factor weighting for
the user 20-1 for the ith additional routing factor (i.e., routing
factor in addition to the social routing factor),
Additional_Factor.sub.SCORE, is a score generated for the potential
physical waypoint for the ith additional routing factor, and NF is
the number of additional routing factors. Note, however, that
additional routing factors are not required.
[0186] In another embodiment, the score may be computed based only
on the social routing factor weighting and the score generated for
the potential physical waypoint for the social routing factor.
Preferably, Score, Social.sub.SCORE, and
Additional_Factor.sub.SCORE are values in the range of 0-10, and
Social.sub.WEIGHT and Additional_Factor.sub.WEIGHT are values in
the range of 1-10.
[0187] In one embodiment, the score for the potential physical
waypoint for the social factor is computed as:
Social SCORE = AP WEIGHT AP SCORE + IR WEIGHT IR + ER WEIGHT ER AP
WEIGHT + IR WEIGHT + ER WEIGHT , ##EQU00008##
where AP.sub.WEIGHT is a weighting assigned to the aggregate
profile routing factor (which is a secondary factor under the
primary social routing factor) for the user 20-1, AP.sub.SCORE is a
score generated for the potential physical waypoint based on the
aggregate profile data obtained from the MAP server 12 for the
potential physical waypoint, IR.sub.WEIGHT is a weighting assigned
to the implicit rating routing factor (which is a secondary factor
under the primary social routing factor) for the user 20-1, IR is
the implicit rating obtained from the route-generation service 40
for the potential physical waypoint, ER.sub.WEIGHT is a weighting
assigned to the explicit rating routing factor (which is a
secondary factor under the primary social routing factor) for the
user 20-1, and ER is the explicit rating obtained for the potential
physical waypoint. Preferably, Social.sub.SCORE, AP.sub.SCORE, IR,
and ER are values in the range of 0-10, and AP.sub.WEIGHT,
IR.sub.WEIGHT, and ER.sub.WEIGHT are values in the range of
1-10.
[0188] The aggregate profile score (AP.sub.SCORE) is generated
based on the aggregate profile data obtained from the MAP server
12. In one embodiment, the aggregate profile data includes
historical aggregate profile data where the historical aggregate
profile data includes a weighted average of a number of user
matches (user_matches.sub.AVG) for all history objects relevant to
the potential physical waypoint and a weighted average of a total
number of users (total_users.sub.AVG) for all history objects
relevant to the potential physical waypoint, as discussed below.
Using this information, the aggregate profile score (AP.sub.SCORE)
may be computed as:
AP SCORE = user_matches AVG total_users AVG 10. ##EQU00009##
[0189] Alternatively, the historical aggregate profile data
includes the ratio of the weighted average of a number of user
matches (user_matches.sub.AVG) for all history objects relevant to
the potential physical waypoint and the weighted average of a total
number of users (total_users.sub.AVG) for all history objects
relevant to the potential physical waypoint, as discussed below. In
this case, the aggregate profile score (AP.sub.SCORE) may be
computed as that ratio multiplied by ten (10).
[0190] In another embodiment, the historical aggregate profile data
includes a weighted average of a number of user matches for each of
a number of keywords
(user_matches.sub.keyword.sub.--.sub.i.sub.--.sub.AVG) for all
history objects relevant to the potential physical waypoint and a
weighted average of a total number of users for each of a number of
keywords (total_users.sub.keyword.sub.--.sub.i.sub.--.sub.AVG) for
all history objects relevant to the potential physical waypoint, as
discussed below. Using this information, the aggregate profile
score (AP.sub.SCORE) may be computed as:
AP SCORE = j ( weight keyword _ j user_matches keyword _ j _ AVG
total_users keyword _ j _ AVG 10 ) j weight keyword _ j .
##EQU00010##
where weight.sub.keyword.sub.--.sub.i is a weighting assigned to a
jth keyword in the user profile of the requestor, which for this
example is the user 20-1. Note that weightings for the individual
keywords are not required. For implementations where weightings for
individual keywords are not enabled or provided, the aggregate
profile score (AP.sub.SCORE) may be computed based on the equation
above using weightings of ten (10) for all of the individual
keywords.
[0191] In another embodiment, the aggregate profile data includes
aggregate profile data for crowds currently at the potential
physical waypoint, and the aggregate profile data includes a total
number of user matches and a total number of users for each crowd
relevant to the potential physical waypoint, as discussed below.
Using this information, the aggregate profile score (AP.sub.SCORE)
may be computed as:
AP SCORE = i ( user_matches crowd _ i total_users crowd _ i ) 10 ,
##EQU00011##
where user_matches.sub.crowd.sub.--.sub.i is the total number of
user matches for the ith crowd and
total_users.sub.crowd.sub.--.sub.i is the total number of users for
the ith crowd. Note that, in an alternative embodiment, the
aggregate profile data may include the ratio of user matches to
total users for each of the crowds in which case the aggregate
profile score (AP.sub.SCORE) may be computed by summing these
ratios and then multiplying the sum by ten (10).
[0192] In yet another embodiment, the aggregate profile data
includes aggregate profile data for crowds currently at the
potential physical waypoint, and the aggregate profile data
includes a total number of user matches and a total number of users
for each of a number of keywords for each crowd relevant to the
potential physical waypoint, as discussed below. Using this
information, the aggregate profile score (AP.sub.SCORE) may be
computed as:
AP SCORE = j ( weight keyword _ j i ( user_matches crowd _ i ,
keyword _ j total_users crowd _ i ) 10 ) j weight keyword _ j ,
##EQU00012##
where user_matches.sub.crowd.sub.--.sub.i,keyword.sub.--.sub.i is
the total number of user matches for the ith crowd for the jth
keyword, total_users.sub.crowd.sub.--.sub.i is the total number of
users for the ith crowd, and weight.sub.keyword.sub.--.sub.i is a
weighting assigned to the jth keyword by the requesting user, which
for this example is the user 20-1. Note that in an alternative
embodiment, the aggregate profile data may include the ratio of
user matches to total users for each keyword for each crowd.
[0193] In yet another embodiment, the aggregate profile data
includes both historical aggregate profile data for the potential
physical waypoint and aggregate profile data for crowds currently
at the potential physical waypoint. In this case, aggregate profile
scores may be computed separately for the historical aggregate
profile data and the aggregate profile data for the crowds
currently at the potential physical waypoint using any of the
embodiments described above. Then, these aggregate profile scores
may be averaged or otherwise combined to provide the aggregate
profile score (AP.sub.SCORE) for the potential physical
waypoint.
[0194] It should be noted that while the discussion herein
primarily focuses on computing the aggregate profile score
(AP.sub.SCORE) at the route-generation service 40, the present
disclosure is not limited thereto. In an alternative embodiment,
the aggregate profile score (AP.sub.SCORE) for the potential
physical waypoint may be computed by the MAP server 12 and returned
as, or as part of, the aggregate profile data for the potential
physical waypoint. This may be particularly beneficial where the
user profile used to generate the aggregate profile data is the
user profile of the user 20-1 stored in the datastore 68 of the MAP
server 12 and weightings are defined for each of a number of
keywords in the user profile of the user 20-1.
[0195] FIG. 27 illustrates the operation of the MAP server 12 to
generate historical aggregate profile data in response to the
aggregate profile data request of step 2400 of FIG. 26 according to
one embodiment of the present disclosure. In this embodiment, the
aggregate profile data request includes a historical request for
historical aggregate profile data for the potential physical
waypoint. First, upon receiving the historical request from the
route-generation service 40, the history manager 60 establishes a
bounding box for the historical request based on the potential
physical waypoint (step 2500). 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). If the potential physical waypoint is expressed as a POI,
the bounding box is a geographic region corresponding to or
surrounding the potential physical waypoint. For example, the
bounding box may be a square geographic region of a predefined size
centered at the potential physical waypoint. If the potential
physical waypoint is expressed as an AOI, the bounding box is the
AOI.
[0196] In addition to establishing the bounding box, the history
manager 60 establishes a time window for the historical request
(step 2502). For example, if the historical request is for the last
week and the current date and time are Sep. 17, 2009 at 10:00 pm,
the history manager 60 may generate the time window as Sep. 10,
2009 at 10:00 pm through Sep. 17, 2009 at 10:00 pm. Next, the
history manager 60 obtains history objects relevant to the bounding
box and the time window for the historical request from the
datastore 68 of the MAP server 12 (step 2504). 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
request.
[0197] Next, in this embodiment, the history manager 60 determines
an equivalent depth of the bounding box (D.sub.BB) within the
quadtree data structures used to store the history objects (step
2506). More specifically, the area of the base quadtree region
(e.g., the base quadtree region 102) is referred to as A.sub.BASE.
Then, at each depth of the quadtree, the area of the corresponding
quadtree nodes is (1/4).sup.D*A.sub.BASE. In other words, the area
of a child node is 1/4.sup.th of the area of the parent node of
that child node. The history manager 60 determines the equivalent
depth of the bounding box (D.sub.BB) by determining a quadtree
depth at which the area of the corresponding quadtree nodes most
closely matches an area of the bounding box (A.sub.BB). Note that
equivalent quadtree depth of the bounding box (D.sub.BB) determined
in step 2506 is used below in order to efficiently determine the
ratios of the area of the bounding box (A.sub.BB) to areas of the
relevant history objects (A.sub.HO). However, in an alternative
embodiment, the ratios of the area of the bounding box (A.sub.BB)
to the areas of the relevant history objects (A.sub.HO) may be
otherwise computed, in which case step 2506 would not be
needed.
[0198] At this point, the history manager 60 gets the next history
object from the history objects obtained for the historical request
in step 2504 (step 2508). Next, the history manager 60 sets a
relevancy weight for the history object, where the relevancy weight
is indicative of a relevancy of the history object to the bounding
box for the historical request (step 2510). For instance, a history
object includes anonymized user profile data for a corresponding
geographic area. If that geographic area is within or significantly
overlaps the bounding box, then the history object will have a high
relevancy weight. However, if the geographic area only overlaps the
bounding box slightly, then the history object will have a low
relevancy weight. In this embodiment, the relevancy weight for the
history object is set to an approximate ratio of the area of the
bounding box (A.sub.BB) to an area of the history object (A.sub.HO)
computed based on a difference between the quadtree depth of the
history object (D.sub.HO) and the equivalent quadtree depth of the
bounding box (D.sub.EQ). The quadtree depth of the history object
(D.sub.HO) is stored in the history object. More specifically, in
one embodiment, the relevancy weight of the history object is set
according to the following:
relevancy = A BB A HO .apprxeq. ( 1 4 ) D HO - D BB ,
##EQU00013##
[0199] for D.sub.HO>D.sub.BB, and
[0200] relevancy=1, for D.sub.HO.ltoreq.D.sub.BB.
[0201] Next, the history manager 60 generates an aggregate profile
for the history object using a user profile of the requesting user,
which for this example is the user 20-1, or a select subset thereof
(step 2512). The user profile of the user 20-1 used to generate the
aggregate profile for the history object may the user profile of
the user 20-1 included in the user record of the user 20-1 stored
in the datastore 68 of the MAP server 12. For example, the
historical request may include information identifying the user
20-1. Using this information, the MAP server 12 identifies the user
20-1 and obtains the user profile of the user 20-1 from the
datastore 68 of the MAP server 12. In another embodiment, the user
profile of the user 20-1 is a user profile defined for the user
20-1 for use by the route-generation service 40. This user profile
may be stored by the route-generation service 40 and included in
the historical request.
[0202] In order to generate the aggregate profile for the history
object, the history manager 60 compares the user profile of the
user 20-1, or the select subset thereof, to the user profiles of
the anonymous user records stored in the history object. In one
embodiment, the resulting aggregate profile for the history object
includes a number of user matches and a total number of users. The
number of user matches is the number of users having user profiles
that include at least one keyword matching at least one keyword in
the user profile of the user 20-1 (or the select subset of the user
profile of the user 20-1). The total number of users is the total
number of anonymous user records in the history object. In addition
or alternatively, the aggregate profile for the history object may
include a list of keywords from the user profile of the user 20-1
or the select subset of the user profile of the user 20-1 having at
least one user match. Still further, the aggregate profile for the
history object may include the number of user matches for each of
the keywords from the user profile of the user 20-1 or the select
subset of the user profile of the user 20-1 having at least one
user match.
[0203] The history manager 60 then determines whether there are
more history objects to be processed (step 2514). If so, the
process returns to step 2508 and is repeated until all of the
history objects have been processed. Once all of the history
objects have been processed, the history manager 60 combines the
aggregate profiles of the history objects to provide a combined
aggregate profile. More specifically, in this embodiment, the
history manager 60 computes a weighted average of the aggregate
profiles for the history objects obtained for the historical
request using the relevancy weights of the history objects (step
2516). In one embodiment, the aggregate profile of each of the
history objects includes the number of user matches for the history
object and the total number of users for the history object. In
this embodiment, the weighted average of the aggregate profiles of
the history objects obtained for the historical request (i.e., the
average aggregate profile for the potential physical waypoint)
includes the weighted average of the number of user matches for all
of the history objects obtained for the historical request, which
may be computed as:
user_matches AVG = i = 1 n ( relevancy i number_of _user _matches i
) i = 1 n relevancy i , ##EQU00014##
where relevancy.sub.i is the relevancy weight computed in step 2510
for the i-th history object, number_of_user matches, is the number
of user matches from the aggregate profile of the i-th history
object, and n is the number of history objects obtained for the
historical request. In a similar manner, in this embodiment, the
average aggregate profile for the potential physical waypoint
includes the weighted average of the total number of users for all
of the history objects obtained for the historical request, which
may be computed as:
total_users AVG = i = 1 n ( relevancy i total_users i ) i = 1 n
relevancy i , ##EQU00015##
where relevancy.sub.i is the relevancy weight computed in step 2510
for the i-th history object, total users, is the total number of
users from the aggregate profile of the i-th history object, and n
is the number of history objects obtained for the historical
request. In addition or alternatively, the average aggregate
profile for the potential physical waypoint may include the
weighted average of the ratio of user matches to total users for
all of the history objects obtained for the historical request,
which may be computed as:
user_matches total_users AVG = i = 1 n ( relevancy i number_of
_user _matches i total_users i ) i = 1 n relevancy i ,
##EQU00016##
where relevancy.sub.i is the relevancy weight computed in step 2510
for the i-th history object, number_of_user_matches, is the number
of user matches from the aggregate profile of the i-th history
object, total users, is the total number of users from the
aggregate profile of the i-th history object, and n is the number
of history objects obtained for the historical request.
[0204] In addition or alternatively, if the aggregate profiles for
the history objects include the number of user matches for each
keyword in the user profile of the user 20-1, or the select subset
thereof, having at least one user match, the average aggregate
profile for the potential physical waypoint may include a weighted
average of the number of user matches for each of those keywords,
which may be computed as:
user_matches KEYWORD _ j , AVG = i = 1 n ( relevancy i number_of
_user _matches KEYWORD _ j , i ) i = 1 n relevancy i ,
##EQU00017##
where relevancy.sub.i is the relevancy weight computed in step 2510
for the i-th history object,
number_of_user_matches.sub.KEYWORD.sub.--.sub.j,i is the number of
user matches for the j-th keyword for the i-th history object, and
n is the number of history objects obtained for the historical
request. In addition or alternatively, the average aggregate
profile for the potential physical waypoint may include the
weighted average of the ratio of the user matches to total users
for each keyword, which may be computed as:
user_matches total_users KEYWORD _ j , AVG = i = 1 n ( relevancy i
number_of _user _matches KEYWORD _ j , i total_users i ) i = 1 n
relevancy i , ##EQU00018##
where relevancy.sub.i is the relevancy weight computed in step 2510
for the i-th history object,
number_of_user_matches.sub.KEYWORD.sub.--.sub.j,i is the number of
user matches for the j-th keyword for the i-th history object,
total users, is the total number of users from the aggregate
profile of the i-th history object, and n is the number of history
objects obtained for the historical request.
[0205] At this point, the average aggregate profile for the
potential physical waypoint is returned to the route-generation
service 40 as, or as part of, the aggregate profile data for the
potential physical waypoint. As discussed above, route-generation
service 40 utilizes the average aggregate profile for the potential
physical waypoint to generate the score for the potential physical
waypoint.
[0206] FIG. 28 illustrates the operation of the MAP server 12 to
generate aggregate profile data for crowds currently at a potential
physical waypoint in response to the aggregate profile data request
of step 2400 of FIG. 26 according to one embodiment of the present
disclosure. In this embodiment, the aggregate profile data request
includes a request for aggregate profile data for crowds relevant
to the potential physical waypoint. First, the MAP server 12
identifies one or more crowds relevant to the potential physical
waypoint (step 2600). More specifically, in one embodiment, the
crowd analyzer 62 of the MAP server 12 performs a crowd formation
process such as that described above in FIG. 16 to form one or more
crowds relevant to the POI or the AOI corresponding the to the
potential physical waypoint of the aggregate profile data request.
In another embodiment, the crowd analyzer 62 proactively forms
crowds using a process such as that described above in FIGS. 18A
through 18D and stores corresponding crowd records in the datastore
68 of the MAP server 12. Then, rather than forming the relevant
crowds in response to the aggregate profile data request, the crowd
analyzer 62 queries the datastore 68 to identify the crowds that
are relevant to the potential physical waypoint. The crowds
relevant to the potential physical waypoint may be those crowds
within or intersecting a bounding region, such as a bounding box,
for the potential physical waypoint. If the potential physical
waypoint is expressed as a POI, the bounding region is a geographic
region of a predefined shape and size centered at the potential
physical waypoint. If the potential physical waypoint is expressed
as an AOI, the bounding region is the AOI.
[0207] After the crowd analyzer 62 has identified the crowds
relevant to the potential physical waypoint, the identified crowds
are passed to the aggregation engine 64 of the MAP server 12. The
aggregation engine 64 selects a next crowd to process, which for
the first iteration is the first crowd (step 2602). The aggregation
engine 64 then selects the next user in the crowd (step 2604).
Next, the aggregation engine 64 compares the user profile of the
user in the crowd to the user profile of the requesting user, which
for this example is the user 20-1 of the mobile device 18-1, or a
select subset of the user profile of the requesting user (step
2606). The user profile of the user 20-1 used for the comparison
may be user profile of the user 20-1 included in the user record of
the user 20-1 stored in the datastore 68 of the MAP server 12. For
example, the aggregate profile data request from the
route-generation service 40 may include information identifying the
user 20-1. Using this information, the MAP server 12 identifies the
user 20-1 and obtains the user profile of the user 20-1 from the
datastore 68 of the MAP server 12. In another embodiment, the user
profile of the user 20-1 is a user profile defined for the user
20-1 for use by the route-generation service 40. This user profile
may be stored by the route-generation service 40 and included in
the aggregate profile data request.
[0208] When comparing the user profile of the user in the crowd to
the user profile of the user 20-1, the aggregation engine 64
identifies matches between the user profile of the user in the
crowd and the user profile of the user 20-1 or the select subset of
the user profile of the user 20-1. In one embodiment, the user
profiles are expressed as keywords in a number of profile
categories. The aggregation engine 64 may then make a list of
keywords from the user profile of the user in the crowd that match
keywords in user profile of the user 20-1 or the select subset of
the user profile of the user 20-1.
[0209] Next, the aggregation engine 64 determines whether there are
more users in the crowd (step 2608). If so, the process returns to
step 2604 and is repeated for the next user in the crowd. Once all
of the users in the crowd have been processed, the aggregation
engine 64 generates an aggregate profile for the crowd based on
data resulting from the comparisons of the user profiles of the
users in the crowd to the user profile of the user 20-1 or the
select subset of the user profile of the user 20-1 (step 2610). In
one embodiment, the data resulting from the comparisons is a list
of matching keywords for each of the users in the crowd. The
aggregate profile for the crowd may then include a number of user
matches over all keywords, the number of users in the crowd, and/or
a ratio of the number of user matches over all keywords to the
number of users in the crowd. The number of user matches over all
keywords is a number of users in the crowd having at least one
keyword in their user profile that matches a keyword in the user
profile of the user 20-1 or the select subset of the user profile
of the user 20-1. The aggregate profile may additionally or
alternatively include, for each keyword in the user profile of the
user 20-1 or the select subset of the user profile of the user
20-1, a ratio of the number of user matches for the keyword to the
number of users in the crowd. Note that keywords in the user
profile of the user 20-1 or the select subset of the user profile
of the user 20-1 that have no user matches may be excluded from the
aggregate profile.
[0210] Once the aggregate profile of the crowd is generated, the
aggregation engine 64 determines whether there are more crowds to
process (step 2612). If so, the process returns to step 2602 and is
repeated for the next crowd. Once aggregate profiles have been
generated for all of the crowds relevant to the potential physical
waypoint, the aggregate profiles for the crowds are returned to the
route-generation service 40 (step 2614).
[0211] FIGS. 29A and 29B present a flow chart illustrating step
2212 of FIG. 24 in more detail according to one embodiment of the
present disclosure. In this embodiment, in order to generate the
recommended routes, the route-generation service 40 first obtains
an optimal base route from the starting point to the stopping point
identified by the user 20-1 (i.e., the requesting user) and
included in the route recommendation request (step 2700). The
optimal base route may be obtained using any suitable technique. In
one embodiment, the route-generation service 40 generates the
optimal base route from the starting point to the stopping point
using an algorithm similar to that employed by conventional routing
services such as, for example, Google.RTM. Maps. The optimal base
route is preferably a shortest route in distance and/or time
between the starting point and the stopping point. In another
embodiment, the route-generation service 40 uses a remote service
such as, for example, Google.RTM. Maps to obtain the optimal base
route from the starting point to the stopping point.
[0212] Next, the route-generation service 40 marks all of the
abstract waypoints as incomplete (step 2702) and initializes a
recommended route to the optimal base route (step 2704). For the
first iteration, the recommended route is a first recommended
route. The route-generation service 40 then identifies potential
physical waypoints for the abstract waypoints that are marked as
incomplete (step 2706). The abstract waypoints that are marked as
incomplete are also referred to herein as incomplete abstract
waypoints. In the preferred embodiment, the route-generation
service 40 identifies potential physical waypoints for the
incomplete abstract waypoints that are within a predefined
divergence distance from the recommended route. For the first
iteration, the recommended route is the optimal base route. As
such, the route-generation service 40 identifies potential physical
waypoints for the abstract waypoints that are within the predefined
divergence distance from the optimal base route. However, for
subsequent iterations, physical waypoints have been selected for
the recommended route and the recommended route has been updated
accordingly. Since the divergence distance is relative to the
recommended route, the geographic area about the recommended route
in which potential physical waypoints for the recommended route are
identified will change as the recommended route changes due to the
selection of physical waypoints.
[0213] The divergence distance may be an absolute divergence
distance such as, for example, one mile from the recommended route.
Alternatively, the divergence distance may be a relative distance
that is a function of a total distance of the recommended route.
For example, the divergence distance may be five percent of the
total distance of the recommended route. So, if the total distance
of the recommended route is ten miles, the divergence distance
would be a half of a mile. As another alternative, the divergence
distance may be a combination of a static distance and a relative
distance. For example, the divergence distance may be five percent
of the total distance of the recommended route up to a maximum
divergence distance of three miles. So, if the total distance of
the recommended route is fifty miles, the divergence distance would
be two and a half miles. However, if the total distance of the
recommended route is one-hundred miles, the divergence distance
would be capped at the three mile maximum.
[0214] In the preferred embodiment, the route-generation service 40
maintains or has access to a local or remote database of known
physical waypoints. The known physical waypoints are POIs such as,
for example, restaurants, gas stations, grocery stores, shopping
malls, golf courses, movie theaters, movie rental stores, ATM
locations, and the like. For each known physical waypoint, the
database of physical waypoints includes a location of the known
physical waypoint and metadata describing the known physical
waypoint. The route-generation service 40 then queries the physical
waypoints database to identify potential physical waypoints that
match the incomplete abstract waypoints and are within the
divergence distance from the recommended route.
[0215] Next, the route-generation service 40 determines whether any
potential physical waypoints have been identified for the
incomplete abstract waypoints (step 2708). If not, the incomplete
abstract waypoints are marked as complete (step 2710) and the
process proceeds to step 2724. If potential physical waypoints have
been identified for the incomplete abstract waypoints, the
route-generation service 40 scores or otherwise ranks the potential
physical waypoints identified for the abstract waypoints based on
the routing factors and the corresponding routing factor weightings
obtained for the user 20-1 associated with the navigation client 42
(step 2712). The route-generation service 40 scores the potential
physical waypoints in the same manner as described above with
respect to FIGS. 26, 27, and 28.
[0216] Then, for each incomplete abstract waypoint, the
route-generation service 40 combines the scores of the potential
physical waypoints identified for the incomplete abstract waypoint
to provide a combined score for the incomplete abstract waypoint
(step 2714). For example, the scores of the potential physical
waypoints identified for the incomplete abstract waypoint may be
averaged to provide the combined score for the incomplete abstract
waypoint. The route-generation service 40 then selects one of the
incomplete abstract waypoints based on the combined scores of the
incomplete abstract waypoints (step 2716). For example, the
incomplete abstract waypoint having the highest combined score may
be selected.
[0217] Next, the route-generation service 40 selects a physical
waypoint for the recommended route from the potential physical
waypoints identified for the selected incomplete abstract waypoint
based on the scores of the potential physical waypoints (step
2718). The route-generation service 40 then updates the recommended
route to include the selected physical waypoint (step 2720) and
marks the selected incomplete abstract waypoint as complete (step
2722). The route-generation service 40 then determines whether all
of the abstract waypoints are complete (step 2724). If not, the
process returns to step 2706 and is repeated for the remaining
incomplete abstract waypoints. Once all of the abstract waypoints
have been marked as complete, the recommended route is complete. At
that point, the route-generation service 40 determines whether the
desired number of recommended routes has been generated (step
2726). If not, the process returns to step 2704 and is repeated to
until the desired number of recommended routes are generated. Once
the last recommended route is generated, the process is
complete.
[0218] FIG. 30 illustrates an exemplary Graphical User Interface
(GUI) 172 provided by the navigation client 42 according to one
embodiment of the present disclosure. As illustrated, the GUI 172
includes a start and stop input area 174 that enables the user 20-1
to enter or otherwise select a starting point and a stopping point
for the automated social routing process. The GUI 172 also includes
a To Do List area 176 that presents a list of abstract waypoints
(e.g., Asparagus, Bicycle Light, Coaxial Cable, etc.) and enables
the user 20-1 to select one or more abstract waypoints for the
automated social routing process. In addition, the GUI 172 includes
a Recommend Routes button 178 that enables the user 20-1 to
initiate the automated social routing process. Optionally, as part
of initiating the automated social routing process, the user 20-1
may be enabled to select a desired number of recommended routes.
Alternatively, the desired number of recommended routes may be a
system-defined number.
[0219] When the user 20-1 selects the Recommend Routes button 178,
the navigation client 42 sends a route recommendation request
including the starting point and stopping point defined in the
start and stop input area 174 and the abstract waypoints selected
in the To Do list area 176. In response, as discussed above, the
route-generation service 40 generates the desired number of
recommended routes from the starting point to the stopping point
through a number of physical waypoints matching the selected
abstract waypoints and returns the recommended routes to the
navigation client 42. Once obtained by the navigation client 42,
the recommended routes are presented to the user 20-1 in a route
presentation area 180 of the GUI 172. In this example, there are
four recommended routes 182-188 that are obtained and presented in
the route presentation area 180.
[0220] The GUI 172 also includes a number of tabs 190-202. At this
point, the routing tab 190 is selected. As shown, by selecting the
routing tab 190, the user 20-1 is enabled to initiate the social
routing process and be presented with the resulting recommended
routes 182-188. In response to selecting a profiles tab 192, as
illustrated in FIG. 31, the GUI 172 presents a list of weighting
profiles 204 to the user 20-1, and the user 20-1 is enabled to
select one of the weighting profiles in the list of weighting
profiles 204 to be used for the automated social routing process.
In addition, the user 20-1 may be enabled to edit the weighting
profiles in the list of weighting profiles 204 by selecting
corresponding Edit buttons 206-210.
[0221] For example, if the user 20-1 selects the Edit button 208,
the GUI 172 presents the home weighting profile to the user 20-1
and enables the user 20-1 to adjust the weightings in the home
weighting profile, as illustrated in FIG. 32. As shown, the home
weighting profile includes a number of primary routing factors
212-1 through 212-8, which in this example are a time routing
factor 212-1, a social routing factor 212-2, a parking routing
factor 212-3, a gas routing factor 212-4, a cost routing factor
212-5, a distance routing factor 212-6, an ambiance routing factor
212-7, and an adventure routing factor 212-8. Weightings assigned
to the primary routing factors 212-1 through 212-8 are manually
assigned by the user 20-1 using, in this example, corresponding
slider bars 214-1 through 214-8. In addition, at least some of the
primary routing factors 212-1 through 212-9 can be expanded to view
corresponding sub-factors. For instance, in this example, the user
20-1 has expanded the social routing factor 212-2 to view secondary
social routing factors 216-1 through 216-3. In this example, the
secondary social routing factors are an aggregate profile routing
factor 216-1, an explicit rating routing factor 216-2, and an
implicit rating routing factor 216-3. Weightings are manually
assigned to the secondary social routing factors 216-1 through
216-3 via corresponding slider bars 218-1 through 218-3.
[0222] The aggregate profile routing factor 216-1 can be expanded
to view and adjust weightings assigned profile categories and
keywords in a user profile of the user 20-1 that is used to
generate aggregate profile data in the manner described above.
Specifically, in this example, the user profile includes a number
of profile categories 220-1 through 220-8, where weightings for the
profile categories 220-1 through 220-8 are assigned via
corresponding slider bars 222-1 through 222-8. In addition, as
illustrated with respect to the Education profile category 220-3,
the user 20-1 may also be enabled to assign weightings to each
keyword in each of the profile categories 220-1 through 220-8. For
example, as illustrated, the user 20-1 has expanded the Education
profile category 220-3. As a result, a number of keywords 224-1
through 224-5 in the user profile of the user 20-1 for the
Education profile category 220-3 are presented, and the user 20-1
is enabled to adjust weightings assigned to the keywords 224-1
through 224-5 via corresponding slider bars 226-1 through 226-5.
Once the user 20-1 is finished adjusting the weighting profile, the
user 20-1 may select a Done button 227 to return the list of
weighting profiles illustrated in FIG. 31.
[0223] Returning to FIG. 30, the GUI 172 also includes the To Do
List tab 194. When the user 20-1 selects the To Do List tab 194,
the GUI 172 presents a list of potential abstract waypoints 228 to
the user 20-1 as illustrated in FIG. 33. The potential abstract
waypoints may be imported from another application such as, for
example, an electronic calendar application or an application
having an electronic calendar. Alternatively, the potential
abstract waypoints may have been previously defined by the user
20-1 or may be system-defined. In this example, the user 20-1 is
enabled to add new potential abstract waypoints via an add button
230 and remove potential abstract waypoints via a remove button
232.
[0224] Again returning to FIG. 30, the GUI 172 includes the Share
tab 196. The Share tab 196 enables the user 20-1 to share one or
more of the recommended routes 182-188 with another user. Sharing
may occur via, for example, email, text-messaging, or similar
mechanism. The Edit tab 198 enables the user 20-1 to edit a select
one of the recommended routes 182-188. Using the recommended route
182 as an example, the user 20-1 may edit the recommended route 182
by selecting a new physical waypoint for one or more of the
selected abstract waypoints. For example, the user 20-1 may be
presented with a list of the potential physical waypoints
identified for the selected abstract waypoints along with the
scores generated for the potential physical waypoints. The user
20-1 may then select a new physical waypoint for one or more of the
selected waypoints. The user 20-1 may also be enabled to edit the
recommended route 182 by changing the starting or stopping point,
adding or removing an abstract waypoint, changing a routing factor
weighting, or the like. Note, however, that some types of edits
such as, for example, changing the starting or ending point, adding
or removing an abstract waypoint, or changing the routing factor
weightings may also be performed by using other mechanisms in the
GUI 172 and then re-running the automated social routing
process.
[0225] The GUI 172 also includes the Mobilize tab 200. The Mobilize
tab enables the user 20-1 to send a select one of the recommended
routes to a mobile device of the user 20-1 such as, for example, a
portable navigation device. The selected recommended route may be
sent to the mobile device via, for example, a local wireless link
(e.g., a Bluetooth.RTM. link) or a wired link (e.g., a USB link).
Note that the Mobilize tab 200 may be particularly beneficial for
embodiments where the navigation client 42 is implemented on a
static device such as, for example, a personal computer of the user
20-1. In this case, the user 20-1 may be enabled to send the
selected recommended route from his personal computer to his mobile
device 18-1, a personal navigation device of the user 20-1, or the
like. The GUI172 also includes a Personalize tab 202. The
Personalize tab 202 enables the user 20-1 to customize the
appearance of the GUI 172 (e.g., color schemes, layout, or the
like).
[0226] In this embodiment, the GUI 172 also includes a weighting
profile bar 234. The weighting profile bar 234 presents the
weighting profile that has been selected by the user 20-1 for use
in the automated social routing process. In this example, the user
20-1 has selected the home weighting profile (i.e., the home
profile). In addition, text font sizes are used to indicate the
weightings assigned to the routing factors for the home weightings
profile. The user 20-1 may be further enabled to explore the home
weightings profile in the weighting profile bar 234 by scrolling
over or otherwise selecting the routing factors in the weighting
profile bar 234. For example, if the user 20-1 selects the Social
routing factor in the weighting profile bar 234, the GUI 172 may
present a tag cloud 236 to the user 20-1, where the tag cloud 236
enables the user 20-1 to navigate the secondary social routing
factors, as illustrated in FIG. 34. The user 20-1 may further
navigate the secondary social routing factors using similar tag
clouds. For example, as illustrated in FIG. 34, the user 20-1 has
further selected the Aggregate Profile factor. In response, a tag
cloud 238 is presented that includes a number of profile
categories, where text font sizes are indicative of weightings
assigned to the profile categories. Further, in this example, the
user 20-1 has selected the Education profile category. In response,
a tag cloud 240 is presented that includes keywords in the user
profile of the user 20-1 within the Education profile category,
where again text font size is indicative of weightings assigned to
the keywords. Note that the user 20-1 may be enabled to adjust the
weightings of the routing factors or their sub-factors by resizing
the corresponding terms in the weighting profile bar 234 and the
tag clouds 236-240.
[0227] In this embodiment, the GUI 172 also includes buttons 242
through 246 that enable the user 20-1 to directly access and edit
the different weighting profiles. Lastly, the GUI 172 includes tabs
248-256 that enable the user 20-1 to explore related locations
(e.g., potential physical waypoints that were scored highly but are
not included in the recommended routes, POIs related to the
physical waypoints in the recommended routes, or the like), explore
related profiles, explore related people, explore related to do
lists, and explore POIs having an ambiance related to one or more
of the physical waypoints selected for the recommended routes,
respectively.
[0228] FIG. 35 illustrates the system 10 according to another
embodiment of the present disclosure. In this embodiment, the
functionality of the route-generation service 40 and the navigation
client 42 (FIG. 1) is implemented in a navigation function 258. The
navigation function 258 may be implemented in software, hardware,
or a combination thereof. While the navigation function 258 may be
implemented on any user device (e.g., personal computer, personal
navigation device, mobile device, etc.), in this embodiment, the
navigation function 258 is implemented on the mobile device 18-1 of
the user 20-1. The navigation function 258 operates to generate
recommended routes for the user 20-1 in much the same manner as the
route-generation service 40.
[0229] More specifically, the navigation function 258 enables the
user 20-1 to define a starting point, a stopping point, and,
optionally, one or more abstract waypoints. Then, for each of a
desired number of recommended routes from the starting point to the
stopping point, the navigation function 258 communicates with the
MAP server 12 either directly or via the MAP client 30-1 to obtain
aggregate profile data, implicit ratings, and/or explicit ratings
for potential waypoints in order to selects physical waypoints for
recommended routes based on routing factors including one or more
social routing factors in the manner described above.
[0230] FIG. 36 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 260 connected to memory 262, one or
more secondary storage devices 264, and a communication interface
266 by a bus 268 or similar mechanism. The controller 260 is a
microprocessor, digital Application Specific Integrated Circuit
(ASIC), Field Programmable Gate Array (FPGA), or the like. In this
embodiment, the controller 260 is a microprocessor, and the
application layer 44, the business logic layer 46, and the object
mapping layer 66 (FIG. 2) are implemented in software and stored in
the memory 262 for execution by the controller 260. Further, the
datastore 68 (FIG. 2) may be implemented in the one or more
secondary storage devices 264. The secondary storage devices 264
are digital data storage devices such as, for example, one or more
hard disk drives. The communication interface 266 is a wired or
wireless communication interface that communicatively couples the
MAP server 12 to the network 28. For example, the communication
interface 266 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.
[0231] FIG. 37 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 270 connected to memory 272, a communication interface
274, one or more user interface components 276, and the location
function 36-1 by a bus 278 or similar mechanism. The controller 270
is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 270 is a microprocessor, and the MAP
client 30-1, the MAP application 32-1, the third-party applications
34-1, the navigation client 42 (FIG. 1), and the navigation
function 258 (FIG. 35) are implemented in software and stored in
the memory 272 for execution by the controller 270. In this
embodiment, the location function 36-1 is a hardware component such
as, for example, a GPS receiver. The communication interface 274 is
a wireless communication interface that communicatively couples the
mobile device 18-1 to the network 28. For example, the
communication interface 274 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 276 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.
[0232] FIG. 38 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 280
connected to memory 282, one or more secondary storage devices 284,
a communication interface 286, and one or more user interface
components 288 by a bus 290 or similar mechanism. The controller
280 is a microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 280 is a microprocessor, and the web
browser 38 (FIG. 1) is implemented in software and stored in the
memory 282 for execution by the controller 280. The one or more
secondary storage devices 284 are digital storage devices such as,
for example, one or more hard disk drives. The communication
interface 286 is a wired or wireless communication interface that
communicatively couples the subscriber device 22 to the network 28.
For example, the communication interface 286 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 288 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.
[0233] FIG. 39 is a block diagram of the third-party server 26 of
FIG. 1 according to one embodiment of the present disclosure. The
third-party server 26 includes a controller 292 connected to memory
294, one or more secondary storage devices 296, a communication
interface 298, and one or more user interface components 300 by a
bus 302 or similar mechanism. The controller 292 is a
microprocessor, digital ASIC, FPGA, or the like. In this
embodiment, the controller 292 is a microprocessor, and the
route-generation service 40 is implemented in software and stored
in the memory 294 for execution by the controller 292. The one or
more secondary storage devices 296 are digital storage devices such
as, for example, one or more hard disk drives. The communication
interface 298 is a wired or wireless communication interface that
communicatively couples the third-party server 26 to the network
28. For example, the communication interface 298 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 300 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.
[0234] 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.
* * * * *