US20120041672A1

US20120041672A1 - Automated social routing

Info

Publication number: US20120041672A1
Application number: US12/698,265
Authority: US
Inventors: Scott Curtis; Steven L. Petersen; Ravi Reddy Katpelly
Original assignee: Waldeck Technology LLC
Current assignee: Ip3 2017 Series 200 Of Allied Security Trust I
Priority date: 2009-02-02
Filing date: 2010-02-02
Publication date: 2012-02-16
Also published as: US9554248B2; US8588819B2; US20140073359A1; US20130005360A1; US20100198880A1; US8265658B2; US20170339522A1; US9674665B2; US9338601B2; US20100197219A1; US20160255474A1

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.

Description

RELATED APPLICATIONS

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

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

Routes generated by traditional portable navigation devices and Internet-based routing services such as Google® 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

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.
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.
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.
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.
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

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.

FIG. 1 illustrates a Mobile Aggregate Profile (MAP) system enabling automated social routing according to one embodiment of the present disclosure;

FIG. 2 is a block diagram of the MAP server of FIG. 1 according to one embodiment of the present disclosure;

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;

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;

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;

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;

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;

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;

FIG. 10 graphically illustrates anonymization of a user record according to one embodiment of the present disclosure;

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;

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;

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;

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;

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;

FIG. 16 is a flow chart for a spatial crowd formation process according to one embodiment of the present disclosure;

FIGS. 17A through 17D graphically illustrate the crowd formation process of FIG. 16 for an exemplary bounding box;

FIGS. 18A through 18D illustrate a flow chart for a spatial crowd formation process according to another embodiment of the present disclosure;

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;

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;

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;

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;

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;

FIG. 24 illustrates the operation of the system of FIG. 1 to provide automated social routing according to one embodiment of the present disclosure;

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;

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;

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;

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;

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;

FIGS. 30-34 illustrate a Graphical User Interface (GUI) of the navigation client of FIG. 1 according to one embodiment of the present disclosure;

FIG. 35 illustrates a MAP system enabling automated social routing according to another embodiment of the present disclosure;

FIG. 36 is a block diagram of the MAP server of FIG. 1 according to one embodiment of the present disclosure;

FIG. 37 is a block diagram of one of the mobile devices of FIG. 1 according to one embodiment of the present disclosure;

FIG. 38 is a block diagram of the subscriber device of FIG. 1 according to one embodiment of the present disclosure; and

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

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.
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).
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.
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® social networking service, the MySpace® social networking service, the LinkedIN® 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.
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® iPhone, the Palm Pre, the Samsung Rogue, the Blackberry Storm, and the Apple® iPod Touch® device. However, this list of exemplary mobile devices is not exhaustive and is not intended to limit the scope of the present disclosure.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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® iPhone. As such, if the mobile device 18-1 is an Apple® 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.
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.
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).
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.
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.
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.
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.
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.
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.
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® iPhone. As such, if the mobile device 18-1 is an Apple® 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.
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^thof 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^thof 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.
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).
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.
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^thof 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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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).
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.
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ⁿ×2ⁿlocation buckets, where n is an integer greater than or equal to 1.
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.
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.
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).
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×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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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).
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.
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).
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.
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.
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.
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.
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.
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×40 meter regions and a 1×1 meter square at the northeast corner of the new bounding box overlaps a 1×1 meter square at the southwest corner of the old bounding box, the crowd analyzer 62 may create a 79×79 meter square bounding box encompassing both the new and old bounding boxes.
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 \cdot \sqrt{\frac{A_{BoundingBox}}{number_of_users}},$
where a is a number between 0 and 1, A_BoundingBoxis 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 ⅔.
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).
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.
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 = \frac{1}{n + 1} \cdot (initial_optimal_inclusion_dist + \sum_{i = 1}^{n} d_{i}), optimial_inclusion_dist = average + \sqrt{(\frac{1}{n} \cdot \sum_{i = 1}^{n} {(d_{i} - average)}^{2})},$
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.
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.
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 \cdot \sqrt{\frac{A_{BoundingBox}}{number_of_users}},$
where a is a number between 0 and 1, A_BoundingBoxis 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 ⅔.
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).
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.
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 = \frac{1}{n + 1} \cdot (initial_optimal_inclusion_dist + \sum_{i = 1}^{n} d_{i}), optimial_inclusion_dist = average + \sqrt{(\frac{1}{n} \cdot \sum_{i = 1}^{n} {(d_{i} - average)}^{2})},$
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 \cdot \sqrt{\frac{A_{BoundingBox}}{number_of_users}},$
where a is a number between 0 and 1, A_BoundingBoxis 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 ⅔. 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.
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 = \frac{1}{n + 1} \cdot (initial_optimal_inclusion_dist + \sum_{i = 1}^{n} d_{i}), optimial_inclusion_dist = average + \sqrt{(\frac{1}{n} \cdot \sum_{i = 1}^{n} {(d_{i} - average)}^{2})},$
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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® 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® 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.
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® 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® Maps to obtain the optimal base route from the starting point to the stopping point.
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.
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).
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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).
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.
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.
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).
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 = \frac{\begin{matrix} {Social}_{WEIGHT} \cdot {Social}_{SCORE} + \\ \sum_{i = 1}^{NF} (\begin{matrix} {Additional_Factor}_{WEIGHT, i} \cdot \\ {Additional_Factor}_{SCORE, i} \end{matrix}) \end{matrix}}{{Social}_{WEIGHT} + \sum_{i = 1}^{NF} {Additional_Factor}_{WEIGHT, i}},$
where Score is the score of the potential physical waypoint, Social_WEIGHTis the social weighting factor for the user 20-1, and Social_SCOREis a score generated for the potential physical waypoint based on the social routing factors. Additional_Factor_WEIGHT,Iis 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_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.
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_SCORE, and Additional_Factor_SCOREare values in the range of 0-10, and Social_WEIGHTand Additional_Factor_WEIGHTare values in the range of 1-10.
In one embodiment, the score for the potential physical waypoint for the social factor is computed as:
${Social}_{SCORE} = \frac{\begin{matrix} {AP}_{WEIGHT} \cdot {AP}_{SCORE} + \\ {IR}_{WEIGHT} \cdot IR + {ER}_{WEIGHT} \cdot ER \end{matrix}}{{AP}_{WEIGHT} + {IR}_{WEIGHT} + {ER}_{WEIGHT}},$
where AP_WEIGHTis 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_SCOREis 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_WEIGHTis 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_WEIGHTis 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_SCORE, AP_SCORE, IR, and ER are values in the range of 0-10, and AP_WEIGHT, IR_WEIGHT, and ER_WEIGHTare values in the range of 1-10.
The aggregate profile score (AP_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_AVG) for all history objects relevant to the potential physical waypoint and a weighted average of a total number of users (total_users_AVG) for all history objects relevant to the potential physical waypoint, as discussed below. Using this information, the aggregate profile score (AP_SCORE) may be computed as:
${AP}_{SCORE} = \frac{{user_matches}_{AVG}}{{total_users}_{AVG}} \cdot 10.$
Alternatively, the historical aggregate profile data includes the ratio of the weighted average of a number of user matches (user_matches_AVG) for all history objects relevant to the potential physical waypoint and the weighted average of a total number of users (total_users_AVG) for all history objects relevant to the potential physical waypoint, as discussed below. In this case, the aggregate profile score (AP_SCORE) may be computed as that ratio multiplied by ten (10).
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_keyword _— _i _— _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_keyword _— _i _— _AVG) for all history objects relevant to the potential physical waypoint, as discussed below. Using this information, the aggregate profile score (AP_SCORE) may be computed as:
${AP}_{SCORE} = \frac{\sum_{j} ({weight}_{keyword_j} \cdot \frac{{user_matches}_{keyword_j_AVG}}{{total_users}_{keyword_j_AVG}} \cdot 10)}{\sum_{j} {weight}_{keyword_j}} .$
where weight_keyword _— _iis 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_SCORE) may be computed based on the equation above using weightings of ten (10) for all of the individual keywords.
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_SCORE) may be computed as:
${AP}_{SCORE} = \sum_{i} (\frac{{user_matches}_{crowd_i}}{{total_users}_{crowd_i}}) \cdot 10,$
where user_matches_crowd _— _iis the total number of user matches for the ith crowd and total_users_crowd _— _iis 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_SCORE) may be computed by summing these ratios and then multiplying the sum by ten (10).
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_SCORE) may be computed as:
${AP}_{SCORE} = \frac{\sum_{j} ({weight}_{keyword_j} \cdot \sum_{i} (\frac{{user_matches}_{crowd_i, keyword_j}}{{total_users}_{crowd_i}}) \cdot 10)}{\sum_{j} {weight}_{keyword_j}},$
where user_matches_crowd _— _i,keyword _— _iis the total number of user matches for the ith crowd for the jth keyword, total_users_crowd _— _iis the total number of users for the ith crowd, and weight_keyword _— _iis 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.
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_SCORE) for the potential physical waypoint.
It should be noted that while the discussion herein primarily focuses on computing the aggregate profile score (AP_SCORE) at the route-generation service 40, the present disclosure is not limited thereto. In an alternative embodiment, the aggregate profile score (AP_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.
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.
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.
Next, in this embodiment, the history manager 60 determines an equivalent depth of the bounding box (D_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_BASE. Then, at each depth of the quadtree, the area of the corresponding quadtree nodes is (¼)^D*A_BASE. In other words, the area of a child node is ¼^thof the area of the parent node of that child node. The history manager 60 determines the equivalent depth of the bounding box (D_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_BB). Note that equivalent quadtree depth of the bounding box (D_BB) determined in step 2506 is used below in order to efficiently determine the ratios of the area of the bounding box (A_BB) to areas of the relevant history objects (A_HO). However, in an alternative embodiment, the ratios of the area of the bounding box (A_BB) to the areas of the relevant history objects (A_HO) may be otherwise computed, in which case step 2506 would not be needed.
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_BB) to an area of the history object (A_HO) computed based on a difference between the quadtree depth of the history object (D_HO) and the equivalent quadtree depth of the bounding box (D_EQ). The quadtree depth of the history object (D_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 = \frac{A_{BB}}{A_{HO}} ≅ {(\frac{1}{4})}^{D_{HO} - D_{BB}},$
for D_HO>D_BB, and
relevancy=1, for D_HO≦D_BB.
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.
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.
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} = \frac{\sum_{i = 1}^{n} ({relevancy}_{i} \cdot number_of_user {_matches}_{i})}{\sum_{i = 1}^{n} {relevancy}_{i}},$
where relevancy_iis 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} = \frac{\sum_{i = 1}^{n} ({relevancy}_{i} \cdot {total_users}_{i})}{\sum_{i = 1}^{n} {relevancy}_{i}},$
where relevancy_iis 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:
$\frac{user_matches}{{total_users}_{AVG}} = \frac{\sum_{i = 1}^{n} ({relevancy}_{i} \cdot \frac{number_of_user {_matches}_{i}}{{total_users}_{i}})}{\sum_{i = 1}^{n} {relevancy}_{i}},$
where relevancy_iis 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.
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} = \frac{\sum_{i = 1}^{n} ({relevancy}_{i} \cdot number_of_user {_matches}_{KEYWORD_j, i})}{\sum_{i = 1}^{n} {relevancy}_{i}},$
where relevancy_iis the relevancy weight computed in step 2510 for the i-th history object, number_of_user_matches_KEYWORD _— _j,iis 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:
$\frac{user_matches}{{total_users}_{KEYWORD_j, AVG}} = \frac{\sum_{i = 1}^{n} ({relevancy}_{i} \cdot \frac{number_of_user {_matches}_{KEYWORD_j, i}}{{total_users}_{i}})}{\sum_{i = 1}^{n} {relevancy}_{i}},$
where relevancy_iis the relevancy weight computed in step 2510 for the i-th history object, number_of_user_matches_KEYWORD _— _j,iis 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.
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.
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.
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.
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.
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.
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).
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® 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® Maps to obtain the optimal base route from the starting point to the stopping point.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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® 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.

Claims

What is claimed is:

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:

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:

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