US20120047087A1 - Smart encounters - Google Patents

Abstract

Systems and methods for providing content recommendations to a user based on aggregate profile data of other users that the user is predicted to encounter in the future are disclosed. In general, an aggregate profile is obtained for a predicted encounter of a first user. The aggregate profile is based on user profiles of a number of second users identified for the predicted encounter. In one embodiment, the predicted encounter is a predicted physical encounter. In another embodiment, the predicted encounter is a predicted remote encounter. One or more content recommendations are then obtained for the first user based on the aggregate profile for the predicted encounter. The content recommendation may be, for example, a recommended movie, a recommended television program, a recommended news article, a recommended user-generated video (e.g., a recommended video on YouTube.com), or the like.

Description

• This application claims the benefit of provisional patent application Ser. No. 61/163,091, filed Mar. 25, 2009, which is hereby incorporated by reference in its entirety.
FIELD OF THE DISCLOSURE
• The present disclosure relates to content recommendations.
BACKGROUND
• Throughout the day, a person typically encounters numerous types of people that often have varying interests. For instance, a person may encounter associates at work having an interest in popular television programs such as The Office, encounter friends at lunch that have an interest in sports, and encounter clients or customers during an afternoon conference call that have an interest in politics. During these encounters, the person desires to be able to contribute to the conversation. However, in many instances, the person will not know of the interests of the other people that the person will encounter beforehand nor will the person necessarily have knowledge of content (e.g., television programs, sporting events, political news articles) of interest to the other people the person will encounter. As such, there is a need for a system and method that provide content recommendations to a person based on aggregate interests of other persons that the person is likely to encounter in the future.
SUMMARY OF THE DETAILED DESCRIPTION
• Systems and methods for providing content recommendations to a user based on aggregate profile data of other users that the user is predicted to encounter in the future are disclosed. In general, an aggregate profile is obtained for a predicted encounter of a first user. The aggregate profile is based on user profiles of a number of second users identified for the predicted encounter. In one embodiment, the predicted encounter is a predicted physical encounter. In another embodiment, the predicted encounter is a predicted remote encounter. One or more content recommendations are then obtained for the first user based on the aggregate profile for the predicted encounter. The content recommendation may be, for example, a recommended movie, a recommended television program, a recommended news article, a recommended user-generated video (e.g., a recommended video on YouTube.com), or the like.
• Those skilled in the art will appreciate the scope of the disclosure and realize additional aspects thereof after reading the following detailed description in association with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• The accompanying drawings incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
• FIG. 1 illustrates a system that provides content recommendations to a user based on aggregate profiles of predicted encounters for the user according to one embodiment of the present disclosure;
• FIG. 2 is a more detailed illustration of the Mobile Aggregate Profile (MAP) server ofFIG. 1 according to one embodiment of the present disclosure;
• FIG. 3 is a more detailed illustration of one of the MAP clients ofFIG. 1 according to one embodiment of the present disclosure;
• FIG. 4 illustrates the operation of the system ofFIG. 1 to provide user profiles and location updates to the MAP server according to one embodiment of the present disclosure;
• FIG. 5 illustrates the operation of the system ofFIG. 1 to provide user profiles and location updates to the MAP server according to another embodiment of the present disclosure;
• FIG. 6 illustrates the operation of the system ofFIG. 1 to provide content recommendations based on aggregate profiles for predicted encounters according to one embodiment of the present disclosure;
• FIG. 7 is a flow chart for a process for generating aggregate profiles for predicted encounters according to one embodiment of the present disclosure;
• FIG. 8 is a flow chart for a process for generating aggregate profiles for predicted encounters according to another embodiment of the present disclosure;
• FIG. 9 is a flow chart for a process for generating aggregate profiles for predicted encounters according to yet another embodiment of the present disclosure;
• FIG. 10 is a flow chart for a process for dividing users identified for a predicted encounter into a number of user groups according to one embodiment of the present disclosure;
• FIG. 11 illustrates an exemplary Graphical User Interface (GUI) provided by the smart encounters service according to one embodiment of the present disclosure;
• FIG. 12 illustrates an exemplary GUI provided by the smart encounters service according to another embodiment of the present disclosure;
• FIG. 13 is a block diagram of the MAP server ofFIG. 1 according to one embodiment of the present disclosure;
• FIG. 14 is a block diagram of one of the mobile devices ofFIG. 1 according to one embodiment of the present disclosure; and
• FIG. 15 is a block diagram of the content consumption device ofFIG. 1 according to one embodiment of the present disclosure.
DETAILED DESCRIPTION
• The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the disclosure and illustrate the best mode of practicing the disclosure. Upon reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the disclosure 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 asystem10 for providing content recommendations to a user based on aggregate profile data obtained for predicted encounters of the user according to one embodiment of the present disclosure. In this embodiment, thesystem10 includes a Mobile Aggregate Profile (MAP)server12, one ormore profile servers14, alocation server16, a number of mobile devices18-1 through18-N having associated users20-1 through20-N, a content consumption device (CCD)22 having an associateduser24, and one ormore recommendation services26 communicatively coupled via anetwork28. Thenetwork28 may be any type of network or any combination of networks. Specifically, thenetwork28 may include wired components, wireless components, or both wired and wireless components. In one exemplary embodiment, thenetwork28 is a distributed public network such as the Internet, where the mobile devices18-1 through18-N are enabled to connect to thenetwork28 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, theMAP server12 operates to obtain current locations, including location updates, and user profiles of the users20-1 through20-N of the mobile devices18-1 through18-N. The current locations of the users20-1 through20-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 users20-1 through20-N, theMAP server12 is enabled to provide a number of features. As discussed below in detail, in this embodiment, theMAP server12 operates to predict encounters between users such as the users20-1 through20-N and24 and generate or otherwise obtain aggregate profile data for the predicted encounters. As discussed below, the aggregate profile data can be used to provide content recommendations in advance of the predicted encounters.
• In addition, theMAP server12 may provide 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 users20-1 through20-N, generating aggregate profiles for crowds of users at a POI or in an AOI using the current user profiles of users in the crowds, and crowd tracking. While not essential for understanding the concepts of this disclosure, for more information regarding these features, the interested reader is directed to U.S. patent application Ser. No. 12/645,535 entitled MAINTAINING A HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA BY LOCATION FOR USERS IN A MOBILE ENVIRONMENT, U.S. patent application Ser. No. 12/645,532 entitled FORMING CROWDS AND PROVIDING ACCESS TO CROWD DATA IN A MOBILE ENVIRONMENT, U.S. patent application Ser. No. 12/645,539 entitled ANONYMOUS CROWD TRACKING, U.S. patent application Ser. No. 12/645,544 entitled MODIFYING A USER'S CONTRIBUTION TO AN AGGREGATE PROFILE BASED ON TIME BETWEEN LOCATION UPDATES AND EXTERNAL EVENTS, U.S. patent application Ser. No. 12/645,546 entitled CROWD FORMATION FOR MOBILE DEVICE USERS, U.S. patent application Ser. No. 12/645,556 entitled SERVING A REQUEST FOR DATA FROM A HISTORICAL RECORD OF ANONYMIZED USER PROFILE DATA IN A MOBILE ENVIRONMENT, and U.S. patent application Ser. No. 12/645,560 entitled HANDLING CROWD REQUESTS FOR LARGE GEOGRAPHIC AREAS, all of which were filed on Dec. 23, 2009 and are hereby incorporated herein by reference in their entireties. Note that while theMAP server12 is illustrated as a single server for simplicity and ease of discussion, it should be appreciated that theMAP server12 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 ormore profile servers14 operate to store user profiles for a number of persons including the users20-1 through20-N of the mobile devices18-1 through18-N. For example, the one ormore profile servers14 may be servers providing social network services such as the Facebook® social networking service, the MySpace® social networking service, the LinkedIN® social networking service, and/or the like. As discussed below, using the one ormore profile servers14, theMAP server12 is enabled to directly or indirectly obtain the user profiles of the users20-1 through20-N of the mobile devices18-1 through18-N. Thelocation server16 generally operates to receive location updates from the mobile devices18-1 through18-N and make the location updates available to entities such as, for instance, theMAP server12. In one exemplary embodiment, thelocation server16 is a server operating to provide Yahoo!'s FireEagle service.
• The mobile devices18-1 through18-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 devices18-1 through18-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 devices18-1 through18-N include MAP clients30-1 through30-N, MAP applications32-1 through32-N, third-party applications34-1 through34-N, and location functions36-1 through36-N, respectively. Using the mobile device18-1 as an example, the MAP client30-1 is preferably implemented in software. In general, in the preferred embodiment, the MAP client30-1 is a middleware layer operating to interface an application layer (i.e., the MAP application32-1 and the third-party applications34-1) to theMAP server12. More specifically, the MAP client30-1 enables the MAP application32-1 and the third-party applications34-1 to request and receive data from theMAP server12. In addition, the MAP client30-1 enables applications, such as the MAP application32-1 and the third-party applications34-1, to access data from theMAP server12. For example, the MAP client30-1 may enable the MAP application32-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 application32-1 is also preferably implemented in software. The MAP application32-1 generally provides a user interface component between the user20-1 and theMAP server12. More specifically, among other things, the MAP application32-1 enables the user20-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 theMAP server12 for a POI or AOI. The MAP application32-1 also enables the user20-1 to configure various settings. For example, the MAP application32-1 may enable the user20-1 to select a desired social networking service (e.g., Facebook, MySpace, LinkedIN, etc.) from which to obtain the user profile of the user20-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 applications34-1 are preferably implemented in software. The third-party applications34-1 operate to access theMAP server12 via the MAP client30-1. The third-party applications34-1 may utilize data obtained from theMAP server12 in any desired manner. As an example, one of the third party applications34-1 may be a gaming application that utilizes historical aggregate profile data to notify the user20-1 of POIs or AOIs where persons having an interest in the game have historically congregated.
• The location function36-1 may be implemented in hardware, software, or a combination thereof. In general, the location function36-1 operates to determine or otherwise obtain the location of the mobile device18-1. For example, the location function36-1 may be or include a Global Positioning System (GPS) receiver.
• The content consumption device (CCD)22 is a user device that enables theuser24 to consume content. As used herein, content is audio and/or visual content (e.g., television programs, radio programs, news articles, or the like). For example, theCCD22 may be a set-top box that enables theuser24 to consume television content such as that provided by traditional cable television or satellite television systems (e.g., Time Warner Cable, DirectTV, or the like), where the set-top box may have Digital Video Recorder (DVR) capabilities. As another example, theCCD22 may be an Internet enabled device such as, for example, a personal computer or mobile smart phone that enables theuser24 to consume content available via the Internet. The content available via the Internet may be, for example, streaming video content such as that available via services such as Hulu.com or YouTube.com, streaming audio content such as streaming radio station content, news articles available via websites such as CNN.com or Yahoo.com, blogs, or the like.
• In this embodiment, theCCD22 includes asmart encounters service38. Thesmart encounters service38 is preferably implemented in software, but is not limited thereto. As discussed below in detail, thesmart encounters service38 operates to obtain content recommendations for theuser24 based on aggregate profile data for predicted encounters between theuser24 and other users such as the users20-1 through20-N. More specifically, as used herein, a predicted encounter is either a predicted physical encounter or a predicted remote encounter. Using theuser24 as an example, a predicted physical encounter for theuser24 is a future time, or future period of time, when theuser24 is likely to be located near one or more identified users for at least a predefined minimum amount of time (e.g., 15 minutes). Similarly, a predicted remote encounter for theuser24 is a future time, or future period of time, when theuser24 is likely to remotely encounter one or more identified users for at least a predefined minimum amount of time. A remote encounter is generally any situation in which users can remotely interact with one another such as, for example, a telephone call or conference call, a voice or text based chat session, or the like.
• In one embodiment, thesmart encounters service38 generates the content recommendations locally based on the aggregate profile data. In another embodiment, thesmart encounters service38 queries the one ormore recommendation services26 using the aggregate profile data for the predicted encounters to obtain content recommendations for theuser24. The recommendation services26 may be any known or existing service for generating content recommendations based on user profile information. The content recommendations are generally recommendations for currently available content or content that will be available in the future prior to the predicted encounter for which the content recommendations are obtained.
• Before proceeding, it should be noted that while thesystem10 ofFIG. 1 illustrates an embodiment where the one ormore profile servers14 and thelocation server16 are separate from theMAP server12, the present disclosure is not limited thereto. In an alternative embodiment, the functionality of the one ormore profile servers14 and/or thelocation server16 may be implemented within theMAP server12.
• FIG. 2 is a block diagram of theMAP server12 ofFIG. 1 according to one embodiment of the present disclosure. As illustrated, theMAP server12 includes anapplication layer40, abusiness logic layer42, and apersistence layer44. Theapplication layer40 includes a user web application46, a mobile client/server protocol component48, and one or more data Application Programming Interfaces (APIs)50. The user web application46 is preferably implemented in software and operates to provide a web interface for accessing theMAP server12 via a web browser. The mobile client/server protocol component48 is preferably implemented in software and operates to provide an interface between theMAP server12 and the MAP clients30-1 through30-N hosted by the mobile devices18-1 through18-N.The data APIs50 enable third-party services to access theMAP server12. In one embodiment, thesmart encounters service38 is a third-party service that accesses the MAP server via thedata APIs50.
• Thebusiness logic layer42 includes aprofile manager52, alocation manager54, ahistory manager56, acrowd analyzer58, anaggregation engine60, and aprediction engine62, each of which is preferably implemented in software. Theprofile manager52 generally operates to obtain the user profiles of the users20-1 through20-N directly or indirectly from the one ormore profile servers14 and store the user profiles in thepersistence layer44. Thelocation manager54 operates to obtain the current locations of the users20-1 through20-N including location updates. As discussed below, the current locations of the users20-1 through20-N may be obtained directly from the mobile devices18-1 through18-N and/or obtained from thelocation server16.
• Thehistory manager56 generally operates to maintain a historical record of anonymized user profile data by location. However, in this embodiment, thehistory manager56 may also operate to maintain historical records of the locations of the users20-1 through20-N, where the historical records may be used to predict future locations of the users20-1 through20-N.The crowd analyzer58 operates to form crowds of users. In one embodiment, thecrowd analyzer58 utilizes a spatial crowd formation algorithm. However, the present disclosure is not limited thereto. In addition, thecrowd analyzer58 may further characterize crowds to reflect degree of fragmentation, best-case and worst-case degree of separation (DOS), and/or degree of bi-directionality of relationship. Still further, thecrowd analyzer58 may also operate to track crowds. Theaggregation engine60 generally operates to provide aggregate profile data in response to requests from the mobile devices18-1 through18-N and thesmart encounters service38. Theprediction engine62 generally operates to predict encounters between users in response to requests from smart encounters services, such as thesmart encounters service38, as discussed below in detail.
• Thepersistence layer44 includes anobject mapping layer64 and adatastore66. Theobject mapping layer64 is preferably implemented in software. Thedatastore66 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, thebusiness logic layer42 is implemented in an object-oriented programming language such as, for example, Java. As such, theobject mapping layer64 operates to map objects used in thebusiness logic layer42 to relational database entities stored in thedatastore66. Note that, in one embodiment, data is stored in thedatastore66 in a Resource Description Framework (RDF) compatible format.
• In an alternative embodiment, rather than being a relational database, thedatastore66 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, theMAP server12 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. TheMAP server12 may then persist RDF descriptions of the users20-1 through20-N as a proprietary extension of the FOAF vocabulary that includes additional properties desired for thesystem10.
• FIG. 3 illustrates the MAP client30-1 ofFIG. 1 in more detail according to one embodiment of the present disclosure. This discussion is equally applicable to the other MAP clients30-2 through30-N. As illustrated, in this embodiment, the MAP client30-1 includes aMAP access API68, aMAP middleware component70, and a mobile client/server protocol component72. TheMAP access API68 is implemented in software and provides an interface by which the MAP client30-1 and the third-party applications34-1 are enabled to access theMAP server12. TheMAP middleware component70 is implemented in software and performs the operations needed for the MAP client30-1 to operate as an interface between the MAP application32-1 and the third-party applications34-1 at the mobile device18-1 and theMAP server12. The mobile client/server protocol component72 enables communication between the MAP client30-1 and theMAP server12 via a defined protocol.
• FIG. 4 illustrates the operation of thesystem10 ofFIG. 1 to provide the user profile of the user20-1 of the mobile device18-1 to theMAP server12 according to one embodiment of the present disclosure. This discussion is equally applicable to user profiles of the other users20-2 through20-N of the other mobile devices18-2 through18-N. First, an authentication process is performed (step1000). For authentication, in this embodiment, the mobile device18-1 authenticates with the profile server14 (step1000A) and the MAP server12 (step1000B). In addition, theMAP server12 authenticates with the profile server14 (step1000C). 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 user20-1 for access to theMAP server12 and theprofile server14. Assuming that authentication is successful, theprofile server14 returns an authentication succeeded message to the MAP server12 (step1000D), and theprofile server14 returns an authentication succeeded message to the MAP client30-1 of the mobile device18-1 (step1000E).
• At some point after authentication is complete, a user profile process is performed such that a user profile of the user20-1 is obtained from theprofile server14 and delivered to the MAP server12 (step1002). In this embodiment, the MAP client30-1 of the mobile device18-1 sends a profile request to the profile server14 (step1002A). In response, theprofile server14 returns the user profile of the user20-1 to the mobile device18-1 (step1002B). The MAP client30-1 of the mobile device18-1 then sends the user profile of the user20-1 to the MAP server12 (step1002C). Note that while in this embodiment the MAP client30-1 sends the complete user profile of the user20-1 to theMAP server12, in an alternative embodiment, the MAP client30-1 may filter the user profile of the user20-1 according to criteria specified by the user20-1. For example, the user profile of the user20-1 may include demographic information, general interests, music interests, and movie interests, and the user20-1 may specify that the demographic information or some subset thereof is to be filtered, or removed, before sending the user profile to theMAP server12.
• Upon receiving the user profile of the user20-1 from the MAP client30-1 of the mobile device18-1, theprofile manager52 of theMAP server12 processes the user profile (step1002D). More specifically, in the preferred embodiment, theprofile manager52 includes social network handlers for the social network services supported by theMAP server12. Thus, for example, if theMAP server12 supports user profiles from Facebook, MySpace, and LinkedIN, theprofile manager52 may include a Facebook handler, a MySpace handler, and a LinkedIN handler. The social network handlers process user profiles to generate user profiles for theMAP server12 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 user20-1 is from Facebook. Theprofile manager52 uses a Facebook handler to process the user profile of the user20-1 to map the user profile of the user20-1 from Facebook to a user profile for theMAP server12 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 user20-1 from Facebook may be processed by the Facebook handler of theprofile manager52 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, theprofile manager52 may use natural language processing or semantic analysis. For example, if the Facebook user profile of the user20-1 states that the user20-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 user20-1 for theMAP server12.
• After processing the user profile of the user20-1, theprofile manager52 of theMAP server12 stores the resulting user profile for the user20-1 (step1002E). More specifically, in one embodiment, theMAP server12 stores user records for the users20-1 through20-N in the datastore66 (FIG. 2). The user profile of the user20-1 is stored in the user record of the user20-1. The user record of the user20-1 includes a unique identifier of the user20-1, the user profile of the user20-1, and, as discussed below, a current location of the user20-1. Note that the user profile of the user20-1 may be updated as desired. For example, in one embodiment, the user profile of the user20-1 is updated by repeatingstep1002 each time the user20-1 activates the MAP application32-1.
• Note that the while the discussion herein focuses on an embodiment where the user profiles of the users20-1 through20-N are obtained from the one ormore profile servers14, the user profiles of the users20-1 through20-N may be obtained in any desired manner. For example, in one alternative embodiment, the user20-1 may identify one or more favorite websites. Theprofile manager52 of theMAP server12 may then crawl the one or more favorite websites of the user20-1 to obtain keywords appearing in the one or more favorite websites of the user20-1. These keywords may then be stored as the user profile of the user20-1.
• At some point, a process is performed such that a current location of the mobile device18-1 and thus a current location of the user20-1 is obtained by the MAP server12 (step1004). In this embodiment, the MAP application32-1 of the mobile device18-1 obtains the current location of the mobile device18-1 from the location function36-1 of the mobile device18-1. The MAP application32-1 then provides the current location of the mobile device18-1 to the MAP client30-1, and the MAP client30-1 then provides the current location of the mobile device18-1 to the MAP server12 (step1004A). Note thatstep1004A may be repeated periodically or in response to a change in the current location of the mobile device18-1 in order for the MAP application32-1 to provide location updates for the user20-1 to theMAP server12.
• In response to receiving the current location of the mobile device18-1, thelocation manager54 of theMAP server12 stores the current location of the mobile device18-1 as the current location of the user20-1 (step1004B). More specifically, in one embodiment, the current location of the user20-1 is stored in the user record of the user20-1 maintained in thedatastore66 of theMAP server12. In one embodiment, only the current location of the user20-1 is stored in the user record of the user20-1. In this manner, theMAP server12 maintains privacy for the user20-1 since theMAP server12 does not maintain a historical record of the location of the user20-1. However, in another embodiment, a historical record of the location of the user20-1 may be maintained by thehistory manager56 within the user record of the user20-1 or as a separate record. The historical record of the location of the user20-1 may be utilized by theprediction engine62 to predict encounters between the user20-1 and other user(s) in the future.
• In addition to storing the current location of the user20-1, thelocation manager54 sends the current location of the user20-1 to the location server16 (step1004C). In this embodiment, by providing location updates to thelocation server16, theMAP server12 in return receives location updates for the user20-1 from thelocation server16. This is particularly beneficial when the mobile device18-1 does not permit background processes, which is the case for the Apple® iPhone. As such, if the mobile device18-1 is an Apple® iPhone or similar device that does not permit background processes, the MAP application32-1 will not be able to provide location updates for the user20-1 to theMAP server12 unless the MAP application32-1 is active.
• Therefore, when the MAP application32-1 is not active, other applications running on the mobile device18-1 (or some other device of the user20-1) may directly or indirectly provide location updates to thelocation server16 for the user20-1. This is illustrated instep1006 where thelocation server16 receives a location update for the user20-1 directly or indirectly from another application running on the mobile device18-1 or an application running on another device of the user20-1 (step1006A). Thelocation server16 then provides the location update for the user20-1 to the MAP server12 (step1006B). In response, thelocation manager54 updates and stores the current location of the user20-1 in the user record of the user20-1 (step1006C). In this manner, theMAP server12 is enabled to obtain location updates for the user20-1 even when the MAP application32-1 is not active at the mobile device18-1.
• FIG. 5 illustrates the operation of thesystem10 ofFIG. 1 to provide the user profile of the user20-1 of the mobile device18-1 according to another embodiment of the present disclosure. This discussion is equally applicable to user profiles of the other users20-2 through20-N of the other mobile devices18-2 through18-N. First, an authentication process is performed (step1100). For authentication, in this embodiment, the mobile device18-1 authenticates with the MAP server12 (step1100A), and theMAP server12 authenticates with the profile server14 (step1100B). 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 user20-1 for access to theMAP server12 and theprofile server14. Assuming that authentication is successful, theprofile server14 returns an authentication succeeded message to the MAP server12 (step1100C), and theMAP server12 returns an authentication succeeded message to the MAP client30-1 of the mobile device18-1 (step1100D).
• At some point after authentication is complete, a user profile process is performed such that a user profile of the user20-1 is obtained from theprofile server14 and delivered to the MAP server12 (step1102). In this embodiment, theprofile manager52 of theMAP server12 sends a profile request to the profile server14 (step1102A). In response, theprofile server14 returns the user profile of the user20-1 to theprofile manager52 of the MAP server12 (step1102B). Note that while in this embodiment theprofile server14 returns the complete user profile of the user20-1 to theMAP server12, in an alternative embodiment, theprofile server14 may return a filtered version of the user profile of the user20-1 to theMAP server12. Theprofile server14 may filter the user profile of the user20-1 according to criteria specified by the user20-1. For example, the user profile of the user20-1 may include demographic information, general interests, music interests, and movie interests, and the user20-1 may specify that the demographic information or some subset thereof is to be filtered, or removed, before sending the user profile to theMAP server12.
• Upon receiving the user profile of the user20-1, theprofile manager52 of theMAP server12 processes the user profile (step1102C). More specifically, as discussed above, in the preferred embodiment, theprofile manager52 includes social network handlers for the social network services supported by theMAP server12. The social network handlers process user profiles to generate user profiles for theMAP server12 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 user20-1, theprofile manager52 of theMAP server12 stores the resulting user profile for the user20-1 (step1102D). More specifically, in one embodiment, theMAP server12 stores user records for the users20-1 through20-N in the datastore66 (FIG. 2). The user profile of the user20-1 is stored in the user record of the user20-1. The user record of the user20-1 includes a unique identifier of the user20-1, the user profile of the user20-1, and, as discussed below, a current location of the user20-1. Note that the user profile of the user20-1 may be updated as desired. For example, in one embodiment, the user profile of the user20-1 is updated by repeatingstep1102 each time the user20-1 activates the MAP application32-1.
• Note that while the discussion herein focuses on an embodiment where the user profiles of the users20-1 through20-N are obtained from the one ormore profile servers14, the user profiles of the users20-1 through20-N may be obtained in any desired manner. For example, in one alternative embodiment, the user20-1 may identify one or more favorite websites. Theprofile manager52 of theMAP server12 may then crawl the one or more favorite websites of the user20-1 to obtain keywords appearing in the one or more favorite websites of the user20-1. These keywords may then be stored as the user profile of the user20-1.
• At some point, a process is performed such that a current location of the mobile device18-1 and thus a current location of the user20-1 is obtained by the MAP server12 (step1104). In this embodiment, the MAP application32-1 of the mobile device18-1 obtains the current location of the mobile device18-1 from the location function36-1 of the mobile device18-1. The MAP application32-1 then provides the current location of the user20-1 of the mobile device18-1 to the location server16 (step1104A). Note thatstep1104A may be repeated periodically or in response to changes in the location of the mobile device18-1 in order to provide location updates for the user20-1 to theMAP server12. Thelocation server16 then provides the current location of the user20-1 to the MAP server12 (step1104B). Thelocation server16 may provide the current location of the user20-1 to theMAP server12 automatically in response to receiving the current location of the user20-1 from the mobile device18-1 or in response to a request from theMAP server12.
• In response to receiving the current location of the mobile device18-1, thelocation manager54 of theMAP server12 stores the current location of the mobile device18-1 as the current location of the user20-1 (step1104C). More specifically, in one embodiment, the current location of the user20-1 is stored in the user record of the user20-1 maintained in thedatastore66 of theMAP server12. In one embodiment, only the current location of the user20-1 is stored in the user record of the user20-1. In this manner, theMAP server12 maintains privacy for the user20-1 since theMAP server12 does not maintain a historical record of the location of the user20-1. However, in another embodiment, a historical record of the location of the user20-1 may be maintained by thehistory manager56 within the user record of the user20-1 or as a separate record. The historical record of the location of the user20-1 may be utilized by theprediction engine62 to predict encounters between the user20-1 and other user(s) in the future.
• As discussed above, the use of thelocation server16 is particularly beneficial when the mobile device18-1 does not permit background processes, which is the case for the Apple® iPhone. As such, if the mobile device18-1 is an Apple® iPhone or similar device that does not permit background processes, the MAP application32-1 will not provide location updates for the user20-1 to thelocation server16 unless the MAP application32-1 is active. However, other applications running on the mobile device18-1 (or some other device of the user20-1) may provide location updates to thelocation server16 for the user20-1 when the MAP application32-1 is not active. This is illustrated instep1106 where thelocation server16 receives a location update for the user20-1 from another application running on the mobile device18-1 or an application running on another device of the user20-1 (step1106A). Thelocation server16 then provides the location update for the user20-1 to the MAP server12 (step1106B). In response, thelocation manager54 updates and stores the current location of the user20-1 in the user record of the user20-1 (step1106C). In this manner, theMAP server12 is enabled to obtain location updates for the user20-1 even when the MAP application32-1 is not active at the mobile device18-1.
• FIG. 6 illustrates the operation of thesystem10 ofFIG. 1 to provide content recommendations to a user based on aggregate profile data for predicted encounters according to one embodiment of the present disclosure. In this embodiment, thesmart encounters service38 first obtains encounter parameters to be used to predict encounters between theuser24 and the users20-1 through20-N and recommendation parameters to be used to obtain content recommendations based on aggregate profile data for predicted encounters for the user24 (steps2000 and2002). The encounter parameters may include a parameter defining a minimum amount of time for an encounter. The minimum amount of time for an encounter defines a minimum amount of time that a user must be predicted to be at or near the same location of theuser24 or remotely interacting with theuser24 before that user is said to be part of a predicted encounter with theuser24. In addition, if predicted physical encounters are desired, the encounter parameters may include a spatial granularity parameter defining a spatial granularity for predicting physical encounters. For example, the spatial granularity may be defined such that users predicted to be at the same physical address as theuser24 form a predicted physical encounter with theuser24. As another example, the spatial granularity may be defined such that users having predicted future locations within a defined distance from a predicted future location of theuser24 form an encounter with theuser24. In this embodiment, the encounter parameters are configurable by theuser24. However, in another embodiment, the encounter parameters are system-defined and either programmed into or stored by theprediction engine62, in whichcase step2000 is not needed.
• The recommendation parameters are optional and may include an encounter location parameter, an encounter duration parameter, a social network distance parameter, a content recommendation frequency parameter, a time parameter, or one or more user profile based parameters. The encounter location parameter is a recommendation parameter that is based on the location of the predicted encounter. For example, the encounter location parameter may define types of content to be recommended based on the location of the predicted encounter. Thus, for instance, the content recommendations may vary depending on whether the location of the predicted encounter is at the user's work, at the user's home, near a gym, at a sports bar, or the like. The encounter duration parameter is a recommendation parameter that is based on a predicted duration of the predicted encounter. Thus, for example, different types or amounts of content may be recommended if the predicted encounter is expected to last thirty minutes as compared to two hours. A social network distance parameter is a recommendation parameter that is based on an average DOS between users in the predicted encounter. Different types of content may be recommended if the users in the predicted encounter have an average DOS of 2 as compared to an average DOS of 5. The content recommendation frequency parameter is a recommendation parameter that controls how often the same or highly related content is recommended. For example, the content recommendation frequency parameter may state that any movie is to be recommended only twice. The time parameter is a content recommendation parameter that states that different types of content are to be recommended based on time of day or day of the week.
• Next, thesmart encounters service38 sends an encounter-based aggregate profile request to the MAP server12 (step2004). The encounter-based aggregate profile request preferably defines a time window for the request. Alternatively, a system-defined or default time window may be used. In one embodiment, the request is initiated by theuser24. In another embodiment, the request is initiated by thesmart encounters service38. For example, in one embodiment, once thesmart encounters service38 is configured by theuser24, thesmart encounters service38 may periodically send requests to theMAP server12 and obtain corresponding content recommendations.
• In response to the encounter-based aggregate profile request, theMAP server12, and more specifically theprediction engine62, predicts one or more encounters for the user24 (step2006). In one embodiment, theprediction engine62 predicts one or more physical encounters for theuser24 during the time window for the request. In another embodiment, theprediction engine62 predicts one or more remote encounters for theuser24 during the time window for the request. In yet another embodiment, theprediction engine62 predicts one or more physical encounters and one or more remote encounters for theuser24 during the time window for the request.
• In order to predict physical encounters of theuser24, theprediction engine62 predicts one or more future locations of theuser24 and one or more future locations of each of at least a subset of the users20-1 through20-N during the time window for the request. In one embodiment, the future locations of theuser24 may be predicted based on a historical record of the location of theuser24 or a schedule of theuser24 such as that maintained in an electronic calendar (e.g., Microsoft Outlook calendar, Apple iCal, or the like). Regarding the historical record of the location of theuser24, if theCCD22 is a location-aware portable device, theMAP server12 may obtain location updates for the location of theuser24 via theCCD22 in a manner similar to that described above for the users20-1 through20-N of the mobile devices18-1 through18-N and maintain the historical record of theuser24 based thereon. Alternatively, theuser24 may also be one of the users20-1 through20-N, in which case theuser24 is identified as one of the users20-1 through20-N and the corresponding historical record of the location of that user is used as the historical record of the location of theuser24. Regarding the schedule of theuser24, in one embodiment, the schedule of theuser24 may be maintained on theCCD22 via, for example, an electronic calendar. The schedule of theuser24 may identify a location of each scheduled event and information identifying the other users, if any, to participate in the scheduled event. TheCCD22 may then provide the schedule of theuser24, or at least a relevant portion thereof, to theMAP server12. Alternatively, theuser24 may also be one of the users20-1 through20-N, in which case the schedule of theuser24 may be stored in a user record maintained by theMAP server12 for that user. In this case, the schedule of theuser24 may be obtained from the corresponding one of the mobile devices18-1 through18-N, obtained from theprofile servers14 if such information is maintained by theprofile servers14, or the like. In a similar manner, theMAP server12 may obtain schedules of the users20-1 through20-N.
• Overlaps in the future locations of theuser24 and the future locations of one or more of the users20-1 through20-N that last for at least the minimum amount of time required for predicted encounters are identified as predicted physical encounters for theuser24. The overlaps in the future locations of theuser24 and the future locations of the one or more of the users20-1 through20-N are determined based on the spatial granularity parameter for predicted encounters.
• As an example, the encounter-based aggregate profile request may identify tomorrow, which for this example is Friday, as the time window for the request. Theprediction engine62 may then analyze the historical record of the location of theuser24 to determine that theuser24 regularly visits a particular location Fridays from 3-5 P.M. As such,prediction engine62 identifies that particular location as a predicted, or future, location of theuser24. In a similar manner, theprediction engine62 analyzes the historical records of the users20-1 through20-N to predict locations of the users20-1 through20-N on Friday. Then, any of the users20-1 through20-N that are predicted to be located at or sufficiently near the predicted location of theuser24 during the period of 3-5 P.M. on Friday for at least the minimum amount of time are identified as users for a predicted physical encounter with theuser24. Theprediction engine62 then creates a predicted physical encounter record that identifies the other users identified for the predicted physical encounter with theuser24 and, optionally, theuser24 and/or the location of the predicted physical encounter.
• As another example, the encounter-based aggregate profile request may identify tomorrow, which for this example is Friday, as the time window for the request. Theprediction engine62 may then analyze the schedule of theuser24 for Friday to identify a particular street address as a predicted location of theuser24 from 3-5 P.M. on Friday. In a similar manner, theprediction engine62 analyzes the schedules of the users20-1 through20-N to determine which of the users20-1 through20-N are scheduled to be located at the same street address as theuser24 during the period of 3-5 P.M. on Friday for at least the minimum amount of time required to be considered an encounter. These other users are identified as users for a predicted physical encounter with theuser24. Theprediction engine62 then creates a predicted physical encounter record that identifies the other users identified for the physical encounter with theuser24 and, optionally, theuser24 and/or the location of the predicted physical encounter, which in this case is the street address at which the predicted physical encounter is predicted to occur.
• Regarding predicted remote encounters, theprediction engine62 may predict one or more remote encounters for theuser24 based on a schedule of theuser24 and/or schedules of the users20-1 through20-N. For example, if the time window for the request is tomorrow, which for this example is Friday, theprediction engine62 may analyze the schedule of theuser24 for Friday to identify a remote encounter with one or more of the other users20-1 through20-N. The remote encounter may be, for example, a scheduled conference call between the user20-1 and two or more of the users20-1 through20-N. As another example, if the time window for the request is tomorrow, which for this example is Friday, theprediction engine62 may analyze the schedules of the users20-1 through20-N to identify any of the users20-1 through20-N that have a scheduled remote encounter with theuser24. Again, the remote encounter may be a conference call. The identified users are users for the predicted remote encounter with the user.
• Theprediction engine62 may also predict one or more remote encounters for theuser24 based on a call log of theuser24 and/or call logs of the other users20-1 through20-N. Note that the call logs of the users20-1 through20-N and24, or at least relevant portions thereof, may be obtained from the mobile devices18-1 through18-N and, if applicable, theCCD22 and stored by theMAP server12. For example, the time window for the request may be tomorrow, which for this example is Friday. Theprediction engine62 may analyze the call log of theuser24 and/or the call logs of the users20-1 through20-N to determine that theuser24 regularly participates in a telephone call or a conference call with one or more of the users20-1 through20-N on Fridays from 11A.M. until Noon. As such, theprediction engine62 creates a predicted remote encounter between theuser24 and the one or more of the users20-1 through20-N that regularly participate in the telephone call or conference call.
• Once the prediction engine has predicted the one or more encounters for the user24 (also referred to herein as predicted encounters of the user24), theMAP server12, and more specifically theaggregation engine60, generates one or more aggregate profiles for each of the predicted encounters of the user24 (step2008). In general, the aggregate profiles generated for the predicted encounters for theuser24 reflect aggregate interests of the users identified for the predicted encounters with theuser24. While discussed below in detail, in one embodiment, for each predicted encounter, theaggregation engine60 generates a single aggregate profile for the predicted encounter. In another embodiment, for each predicted encounter, theaggregation engine60 divides the users identified for the predicted encounter with theuser24 into a number of user groups and generates a separate aggregate profile for each of the user groups.
• Next, theMAP server12 returns the aggregate profile(s) for the one or more predicted encounters to the smart encounters service38 (step2010). Then, thesmart encounters service38 obtains one or more content recommendations for theuser24 based on the aggregate profile(s) for the predicted encounter(s) of the user24 (step2012). In addition, the recommendation parameters, if any, are used when obtaining the content recommendations. In the preferred embodiment, as discussed below in detail, each aggregate profile includes a list of keywords and, optionally, a number of user matches for each keyword in the list of keywords and/or a ratio of user matches to a total number of users for each keyword in the list of keywords. Then, the content recommendations are obtained based on the list of keywords and, optionally, the number of user matches for each keyword and/or the ratio of user matches to a total number of users for each keyword. For instance, in one embodiment, all of the keywords in the aggregate profile for a predicted encounter are used to obtain content recommendations for content that matches those keywords. In another embodiment, the number of user matches and/or the ratio of user matches to total number of users for each keyword may be used to control the relative amounts of content recommendations for content matching those keywords. In other words, the amount of content recommendations for content matching a particular keyword may be a function of the number of user matches for that keyword and/or the ratio of the number of user matches to the total number of users for that keyword. In another embodiment, only the keyword having the M highest number of user matches or the M highest ratios of the number of user matches to the total number of users may be used to obtain the content recommendations, wherein M is an integer greater than or equal to one (1).
• The manner in which the content recommendations are obtained may vary depending on the particular implementation. In one embodiment, theCCD22 is a set-top box that enables theuser24 to view television content from a television service provider, where the set-top box has an Electronic Programming Guide (EPG). As such, for each of the aggregate profiles, thesmart encounters service38 may obtain the one or more content recommendations for theuser24 by comparing the aggregate profile to metadata in the EPG describing television content that is currently available or will be available in the future prior to the corresponding predicted encounter. Thesmart encounters service38 may then create content recommendations for television content that matches the aggregate profile to at least a defined threshold degree. In another embodiment, theCCD22 has access to the one ormore recommendation services26 via thenetwork28. As such, for each of the aggregate profiles, thesmart encounters service38 may query at least one of therecommendation services26 using the aggregate profile to obtain content recommendations. Note thatstep2010 and/orstep2012 may be periodically repeated in order to update the aggregate profiles in response to new or changing predicted encounters and/or to update content recommendations in response to new or changing aggregate profiles and/or newly available content.
• Thesmart encounters service38 then presents the content recommendations to theuser24 at theCCD22 via an associated Graphical User Interface (GUI) (step2014). In one embodiment, each content recommendation includes a name or title of the recommended content and information enabling theuser24 to access the recommended content. The information enabling theuser24 to access the recommended content may vary depending on the particular implementation and the type of recommended content. For example, the information enabling theuser24 to access the recommended content may be a Uniform Resource Locator (URL); date, time, and television channel on which the recommended content will be broadcast; or the like.
• FIG. 7 is a flowchart illustrating step2008 ofFIG. 6 in more detail according to one embodiment of the present disclosure. Specifically, in this embodiment, theaggregation engine60 of theMAP server12 generates a single aggregate profile for each of the one or more predicted encounters for theuser24. First, theaggregation engine60 selects a next predicted encounter to process, which for the first iteration is the first predicted encounter for the user24 (step2100). Theaggregation engine60 then selects the next user identified for the predicted encounter with the user24 (step2102). Next, theaggregation engine60 compares the user profile of the user identified for the predicted encounter to the user profile of theuser24, or a select subset of the user profile of the user24 (step2104). In some embodiments, theuser24 may be enabled to select a subset of his user profile to be used for generation of the aggregate profile. For example, in the embodiment where user profiles are expressed as keywords in a number of profile categories, theuser24 may select one or more of the profile categories to be used for aggregate profile generation. When comparing the user profile of the user identified for the predicted encounter to the user profile of theuser24, theaggregation engine60 identifies matches between the user profile of the user identified for the encounter and the user profile of theuser24 or the select subset of the user profile of theuser24. In one embodiment, the user profiles are expressed as keywords in a number of profile categories. Theaggregation engine60 may then make a list of keywords from the user profile of the user identified for the predicted encounter that match keywords in user profile of theuser24 or the select subset of the user profile of theuser24.
• Next, theaggregation engine60 determines whether there are more users identified for the encounter with the user24 (step2106). If so, the process returns to step2102 and is repeated for the next user identified for the predicted encounter. Once all of the users identified for the predicted encounter have been processed, theaggregation engine60 generates an aggregate profile for the predicted encounter based on data resulting from the comparisons of the user profiles of the users identified for the predicted encounter to the user profile of theuser24 or the select subset of the user profile of the user24 (step2108). In an alternative embodiment, theaggregation engine60 generates an aggregate profile for the predicted encounter based on data resulting from the comparisons of the user profiles of the users identified for the predicted encounter to a target user profile defined or otherwise specified by theuser24.
• In one embodiment, the data resulting from the comparisons is a list of matching keywords for each of the users identified for the predicted encounter. The aggregate profile may then include, for each keyword in the user profile of theuser24 or the select subset of the user profile of theuser24, a number of user matches for the keyword or a ratio of the number of user matches for the keyword to the number of users identified for the predicted encounter. Note that keywords in the user profile of theuser24 or the select subset of the user profile of theuser24 that have no user matches may be excluded from the aggregate profile. In addition, the aggregate profile for the crowd may include a total number of users identified for the predicted encounter.
• Once the aggregate profile of the crowd is generated, theaggregation engine60 determines whether there are more predicted encounters to process (step2110). If so, the process returns to step2100 and is repeated for the next predicted encounter. Once aggregate profiles have been generated for all of the predicted encounters for theuser24, the aggregate profiles for the predicted encounters are returned to the smart encounters service38 (step2112). In an alternative embodiment, the aggregate profiles for the predicted encounters are returned to thesmart encounters service38 one by one as the aggregate profiles are generated instep2108. In this case, the list of predicted encounters is preferably returned to thesmart encounters service38 instep2006 ofFIG. 6.
• FIG. 8 is a flowchart illustrating step2008 ofFIG. 6 in more detail according to another embodiment of the present disclosure. Specifically, in this embodiment, theaggregation engine60 of theMAP server12 generates a single aggregate profile for each of the one or more predicted encounters for theuser24. First, theaggregation engine60 selects a next predicted encounter for theuser24 to process, which for the first iteration is the first predicted encounter for the user24 (step2200). Theaggregation engine60 then generates an aggregate profile for the predicted encounter based on a comparison of the user profiles of the users identified for the predicted encounter to one another (step2202). In this embodiment, neither the user profile of theuser24 nor a target user profile is included in the comparison.
• In one embodiment, in order to generate the aggregate profile for the predicted encounter, the user profiles are expressed as keywords for each of a number of profile categories. Then, theaggregation engine60 may determine an aggregate list of keywords for the predicted encounter. The aggregate list of keywords is a list of all keywords appearing in the user profiles of the users identified for the predicted encounter. The aggregate profile for the predicted encounter may then include a number of user matches for each keyword in the aggregate list of keywords for the predicted encounter. The number of user matches for a keyword is the number of users identified for the predicted encounter having a user profile that includes that keyword. The aggregate profile may include the number of user matches for all keywords in the aggregate list of keywords for the predicted encounter or the number of user matches for keywords in the aggregate list of keywords for the predicted encounter having more than a predefined number of user matches (e.g., more than 1 user match). The aggregate profile may also include the number of users identified for the predicted encounter. In addition or alternatively, the aggregate profile may include, for each keyword in the aggregate list or each keyword in the aggregate list having more than a predefined number of user matches, a ratio of the number of user matches for the keyword to the number of users identified for the predicted encounter.
• Once the aggregate profile of the predicted encounter is generated, theaggregation engine60 determines whether there are more predicted encounters for theuser24 to process (step2204). If so, the process returns to step2200 and is repeated for the next predicted encounter. Once aggregate profiles have been generated for all of the predicted encounters for theuser24, the aggregate profiles for the predicted encounters are returned to the smart encounters service38 (step2206).
• FIG. 9 is a flowchart illustrating step2008 ofFIG. 6 in more detail according to yet another embodiment of the present disclosure. Specifically, in this embodiment, theaggregation engine60 of theMAP server12 generates an aggregate profile for each of a number of user groups for each of the one or more predicted encounters for theuser24. First, theaggregation engine60 selects a next predicted encounter for theuser24 to process, which for the first iteration is the first predicted encounter for the user24 (step2300). Theaggregation engine60 then divides the users identified for the predicted encounter into a number of user groups (step2302). In one embodiment, theaggregation engine60 divides the users identified for the predicted encounter into a number of user groups based on DOS in one or more social networks. In another embodiment, theaggregation engine60 divides the users identified for the predicted encounter into a number of user groups based on the user profiles of the users. For example, users having similar user profiles may be grouped into one user group. In another example, users in close proximity to one another may be grouped into one user group.
• Next, theaggregation engine60 selects the next user group for the predicted encounter, which for the first iteration is the first user group for the predicted encounter (step2304). Theaggregation engine60 then generates an aggregate profile for the user group for the predicted encounter (step2306). In one embodiment, the aggregate profile is generated by comparing the user profile of theuser24, or a select subset thereof, to the user profiles of the users in the user group in a manner similar to that described above with respect toFIG. 7. The resulting aggregate profile for the user group may include a list of matching keywords, a number of user matches for each of the keywords, and/or a ratio of the number of user matches to a total number of users in the user group for each of the keywords. In addition, the aggregate profile may include the total number of users in the user group. In another embodiment, the aggregate profile is generated by comparing a target user profile to the user profiles of the users in the user group.
• In yet another embodiment, the aggregate profile for the user group is generated by comparing the user profiles of the users in the user group to one another in a manner similar to that described above with respect toFIG. 8. In this embodiment, neither the user profile of theuser24 nor a target user profile is included in the comparison. Again, the resulting aggregate profile for the user group may include a list of matching keywords, a number of user matches for each of the keywords, and/or a ratio of the number of user matches to a total number of users in the user group for each of the keywords. In addition, the aggregate profile may include the total number of users in the user group.
• Next, theaggregation engine60 determines whether the last user group for the predicted encounter has been processed (step2308). If not, the process returns to step2304 and is repeated. Once the last user group for the predicted encounter is processed, theaggregation engine60 determines whether the last predicted encounter has been processed (step2310). If not, the process returns to step2300 and is repeated. Once the last predicted encounter has been processed, theaggregation engine60 returns the aggregate profiles for the user groups for each of the one or more predicted encounters to the smart encounters service38 (step2312).
• FIG. 10 is a flowchart illustrating step2302 ofFIG. 9 in more detail according to one embodiment of the present disclosure. Note that while in this discussion the process ofFIG. 10 is performed by theaggregation engine60, the process ofFIG. 10 may alternatively be performed by thecrowd analyzer58, where the users identified for the predicted encounter are treated as a crowd and thecrowd analyzer58 operates to divide that crowd into a number of crowd fragments (i.e., user groups). First, in order to divide the users identified for the predicted encounter into a number of user groups, theaggregation engine60 first creates a user group for each user identified for the predicted encounter (step2400). The user groups created instep2400 each include a single user.
• Next, theaggregation engine60 selects a next pair of user groups (step2402) and then selects one user from each of those user groups (step2404). Theaggregation engine60 then determines a DOS between the users from the pair of user groups (step2406). More specifically, as will be appreciated by one of ordinary skill in the art, DOS is a measure of the degree to which the two users are related in a social network (e.g., the Facebook® social network, the MySpace® social network, or the LinkedIN® social network). The two users have a DOS of one if one of the users is a friend of the other user, a DOS of two if one of the users is a friend of a friend of the other user, a DOS of three if one of the users is a friend of a friend of a friend of the other user, etc. If the two users are not related in a social network or have an unknown DOS, the DOS for the two users is set to a predetermined maximum value.
• Theaggregation engine60 then determines whether the DOS between the two users is less than a predefined maximum DOS for a user group (step2408). For example, the predefined maximum DOS may be three. However, other maximum DOS values may be used. If the DOS between the two users is not less than the predefined maximum DOS, the process proceeds to step2414. If the DOS between the two users is less than the predefined maximum DOS, theaggregation engine60 determines whether a bidirectionality requirement is satisfied (step2410). The bidirectionality requirement specifies whether the relationship between the two users must be bidirectional (i.e., the first user must directly or indirectly know the second user and the second user must directly or indirectly know the first user). Bidirectionality may or may not be required depending on the particular embodiment. If the two users satisfy the bidirectionality requirement, theaggregation engine60 combines the pair of user groups (step2412) and the process then returns to step2402 and is repeated for a next pair of user groups. If the two users do not satisfy the bidirectionality requirement, the process proceeds to step2414.
• At this point, whether proceeding fromstep2408 orstep2410, theaggregation engine60 determines whether all user pairs from the two user groups have been processed (step2414). If not, the process returns to step2404 and is repeated for a new pair of users from the two user groups. If all user pairs from the two user groups have been processed, theaggregation engine60 then determines whether all user groups have been processed (step2416). If not, the process returns to step2402 and is repeated until all user groups have been processed. Once this process is complete, the resulting user groups are the user groups for the predicted encounter.
• FIG. 11 is anexemplary GUI74 provided by thesmart encounters service38 according to one embodiment of the present disclosure. As illustrated, theGUI74 enables theuser24 to configure the time window for the smart encounters process. As discussed above, the time window in a time period in which encounters are predicted for theuser24. In this example, the time window is April 24^thfrom 8:30 A.M. to 5:30 P.M. The time window can be changed by theuser24 by selecting anedit button76. Once theuser24 has configured the time window, thesmart encounters service38 sends an encounters-based aggregate profile request to theMAP server12, as discussed above. In response, theMAP server12 determines one or more predicted encounters for theuser24, generates aggregate profiles for the predicted encounters, and returns the aggregate profiles to thesmart encounters service38.
• In this embodiment, thesmart encounters service38 enables theuser24 to view the locations of the predicted encounters and the aggregate profiles for the predicted encounters. More specifically, theGUI74 includes amap area78 for presenting the locations of the predicted encounters to theuser24. In this example, there are three predicted encounters, namely, a predictedencounter80 at the user's work location, a predictedencounter82 at a gym that the user regularly visits, and a predictedencounter84 at a deli that theuser24 regularly visits. As further illustrated, theGUI74 enables theuser24 to select, for example, the predictedencounter80 in order to view anaggregate profile86 for the predictedencounter80. Buttons88-94 enable theuser24 to modify, or edit, corresponding keywords in theaggregate profile86 for purposes of generating content recommendations for the predicted encounter. As such, if theuser24 modifies one of the keywords in theaggregate profile86, the content recommendations for the predicted encounter will also change. In addition, buttons96-102 enable theuser24 to delete corresponding keywords in theaggregate profile86 for purposes of content recommendations.Buttons104 and106 enable theuser24 to navigate from one predicted encounter to another. Thus, if there are multiple predicted encounters for theuser24, theuser24 may use thebuttons104 and106 to view the aggregate profiles and content recommendations for the different predicted encounters.
• In addition, theGUI74 includes acontent recommendations area108 for presenting the content recommendations for the selected predicted encounter to theuser24. In this embodiment, thecontent recommendations area108 includes aNow button110 that, if selected, causes only content recommendations for currently available content to be presented to theuser24 and aLater button112 that, if selected, causes only content recommendations for content that will be available at a later time to be presented to theuser24. Thecontent recommendations area108 also includes an Allbutton114. If both theNow button110 and theAll button114 are selected, theGUI74 presents all content recommendations for currently available content to be presented to theuser24. If both theLater button112 and theAll button114 are selected, theGUI74 presents all content recommendations for content that will be available at a later time to be presented to theuser24 in thecontent recommendations area108. In a similar manner, aTV button116 may be used in connection with theNow button110 orLater button118 to view content recommendations for television content that is currently available or will be later available. Likewise, aWeb button118 may be used in connection with theNow button110 orLater button118 to view content recommendations for web-based content that is currently available or will be later available. ALocal button120 may be used in connection with theNow button110 orLater button118 to view content recommendations for locally stored content that is currently available or will be later available.Buttons122 and124 may be used by theuser24 to scroll left or right in thecontent recommendations area108 to view additional content recommendations.
• FIG. 12 illustrates anotherexemplary GUI126 that may be provided by thesmart encounters service38 according to another embodiment of the present disclosure. TheGUI126 is particularly relevant to the embodiment where theCCD22 is a mobile device, such as a mobile smart phone. In this embodiment, thesmart encounters service38 provides content recommendation alerts to theuser24. More specifically, after obtaining a predicted encounter and an aggregate profile for the predicted encounter from theMAP server12, thesmart encounters service38 periodically obtains content recommendations for the predicted encounter based on the aggregate profile for the predicted encounter. When new recommended content is found, thesmart encounters service38 provides a content recommendation alert for the predicted encounter to theuser24 via theGUI126.
• As illustrated, theGUI126 includes anAlerts button128 that, when selected by theuser24, causes content recommendation alerts to be presented to theuser24. In this example, upon selecting theAlerts button128, a new content recommendation alert is presented to theuser24.Button130 may be selected by theuser24 to access the recommended content, view information enabling theuser24 to access the recommended content, view a preview of the content, and/or view more detailed information regarding the content, depending on the particular implementation.Button132 may be selected by theuser24 to delete or otherwise remove the new alert. Also, as shown, theGUI126 identifies the predicted encounter for which the alert is provided, which for this example is “Charlotte Meeting.” APrevious Alerts button134 may be selected by theuser24 in order to view previously received content recommendation alerts. AMap button136 may be selected by theuser24 to view a map showing a location of each of a number of predicted encounters for theuser24. Lastly, aSettings button138 may be selected by theuser24 in order to view and modify settings for the smart encounters process such as, for example, the time window for which encounters are to be predicted, encounter parameters, or recommendation parameters. Thesettings button138 may also be selected by theuser24 in order to view or modify settings pertaining to alerts. For example, settings can specify under what circumstances to generate an alert.
• FIG. 13 is a block diagram of theMAP server12 according to one embodiment of the present disclosure. As illustrated, theMAP server12 includes acontroller140 connected tomemory142, one or moresecondary storage devices144, and acommunication interface146 by abus148 or similar mechanism. Thecontroller140 is a microprocessor, digital Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or the like. In this embodiment, thecontroller140 is a microprocessor, and theapplication layer40, thebusiness logic layer42, and the object mapping layer64 (FIG. 2) are implemented in software and stored in thememory142 for execution by thecontroller140. Further, the datastore66 (FIG. 2) may be implemented in the one or moresecondary storage devices144. Thesecondary storage devices144 are digital data storage devices such as, for example, one or more hard disk drives. Thecommunication interface146 is a wired or wireless communication interface that communicatively couples theMAP server12 to the network28 (FIG. 1). For example, thecommunication interface146 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. 14 is a block diagram of the mobile device18-1 according to one embodiment of the present disclosure. This discussion is equally applicable to the other mobile devices18-2 through18-N. As illustrated, the mobile device18-1 includes acontroller150 connected tomemory152, a communication interface154, one or more user interface components156, and the location function36-1 by abus158 or similar mechanism. Thecontroller150 is a microprocessor, digital ASIC, FPGA, or the like. In this embodiment, thecontroller150 is a microprocessor, and the MAP client30-1, the MAP application32-1, and the third-party applications34-1 are implemented in software and stored in thememory152 for execution by thecontroller150. In this embodiment, the location function36-1 is a hardware component such as, for example, a GPS receiver. The communication interface154 is a wireless communication interface that communicatively couples the mobile device18-1 to the network28 (FIG. 1). For example, the communication interface154 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 components156 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. 15 is a block diagram of theCCD22 according to one embodiment of the present disclosure. As illustrated, theCCD22 includes acontroller160 connected tomemory162, one or moresecondary storage devices164, acommunication interface166, and one or more user interface components168 by abus170 or similar mechanism. Thecontroller160 is a microprocessor, digital ASIC, FPGA, or the like. In this embodiment, thecontroller160 is a microprocessor, and the smart encounters service38 (FIG. 1) is implemented in software and stored in thememory162 for execution by thecontroller160. The one or moresecondary storage devices164 are digital storage devices such as, for example, one or more hard disk drives. Thecommunication interface166 is a wired or wireless communication interface that communicatively couples theCCD22 to the network28 (FIG. 1). For example, thecommunication interface166 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, an interface to a network of a television service provider, or the like. The one or more user interface components168 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.
• It should be noted that thesystem10 described herein provides substantial opportunity for variation without departing from the spirit or scope of the present disclosure. For example, while thesmart encounters service38 has been illustrated and described as being implemented on theCCD22, thesmart encounters service38 may be implemented on each of one or more of the mobile devices18-1 through18-N as, for instance, third-party applications34-1 through34-N. As another example, thesmart encounters service38 may be implemented on a server, such as theMAP server12, wherein users, such as the users20-1 through20-N and24, may access thesmart encounters service38 via a custom application or a web browser.
• Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims (28)

What is claimed is:

1. A method of operating a computing device comprising:

obtaining an aggregate profile for a predicted encounter of a first user, the aggregate profile being based on user profiles of a plurality of second users identified for the predicted encounter of the user; and

obtaining one or more content recommendations for the first user based on the aggregate profile for the predicted encounter.

2. The method ofclaim 1 wherein the predicted encounter is a predicted physical encounter.

3. The method ofclaim 2 wherein the predicted physical encounter is predicted based on a historical record of a location of the first user and historical records of locations of the plurality of second users.

4. The method ofclaim 3 wherein the predicted physical encounter is predicted by:

predicting a future location of the first user based on the historical record of the location of the first user;

predicting one or more future locations for each of at least a subset of a plurality of known users based on historical records of locations of the at least a subset of the plurality of known users; and

identifying ones of the at least a subset of the plurality of known users having future locations that overlap the future location of the first user as the plurality of second users for the predicted physical encounter.

5. The method ofclaim 2 wherein the predicted physical encounter is predicted based on a schedule of the first user.

6. The method ofclaim 2 wherein the predicted physical encounter is predicted based on schedules of the plurality of second users.

7. The method ofclaim 2 wherein the predicted physical encounter is predicted based on schedules of the first user and the plurality of second users.

8. The method ofclaim 1 wherein the predicted encounter is a predicted remote encounter.

9. The method ofclaim 8 wherein the predicted remote encounter is predicted based on a schedule of the first user.

10. The method ofclaim 8 wherein the predicted remote encounter is predicted based on schedules of the plurality of second users.

11. The method ofclaim 8 wherein the predicted physical encounter is predicted based on schedules of the first user and the plurality of second users.

12. The method ofclaim 1 wherein the aggregate profile for the predicted encounter comprises one or more keywords, and obtaining the one or more content recommendations comprises obtaining the one or more content recommendations based on at least one of the one or more keywords.

13. The method ofclaim 12 wherein the aggregate profile for the predicted encounter further comprises a number of user matches for each of the one or more keywords.

14. The method ofclaim 13 wherein the one or more keywords is a plurality of keywords, and obtaining the one or more content recommendations comprises obtaining a plurality of content recommendations based on the plurality of keywords and the number of user matches for each of the plurality of keywords.

15. The method ofclaim 14 wherein a number of the plurality of content recommendations that match each keyword of the plurality of keywords is a function of the number of user matches for the keyword.

16. The method ofclaim 13 wherein the one or more keywords is a plurality of keywords, and obtaining the one or more content recommendations comprises obtaining the one or more content recommendations based on one or more of the plurality of keywords having a highest number of user matches.

17. The method ofclaim 12 wherein the aggregate profile for the predicted encounter further comprises a ratio of a number of user matches to a total number of users in the plurality of second users for each of the one or more keywords.

18. The method ofclaim 17 wherein the one or more keywords is a plurality of keywords, and obtaining the one or more content recommendations comprises obtaining a plurality of content recommendations based on the plurality of keywords and the ratio of the number of user matches to the total number of users for each of the plurality of keywords.

19. The method ofclaim 18 wherein a number of the plurality of content recommendations that match each keyword of the plurality of keywords is a function of the ratio of the number of user matches to the total number of users for the keyword.

20. The method ofclaim 17 wherein the one or more keywords is a plurality of keywords, and obtaining the one or more content recommendations comprises obtaining the one or more content recommendations based on one or more of the plurality of keywords having a highest ratio of the number of user matches to the total number of users.

21. The method ofclaim 12 wherein the one or more keywords in the aggregate profile for the predicted encounter are keywords in user profiles of the plurality of second users that match keywords in a user profile of the first user.

22. The method ofclaim 12 wherein the one or more keywords in the aggregate profile for the predicted encounter are keywords in user profiles of the plurality of second users that match keywords in a target user profile defined by the first user.

23. The method ofclaim 12 wherein the one or more keywords in the aggregate profile for the predicted encounter are matching keywords in user profiles of the plurality of second users.

24. The method ofclaim 1 wherein the plurality of second users form a first user group of a plurality of user groups identified for the predicted encounter.

25. The method ofclaim 1 wherein the plurality of second users are users identified for the predicted encounter.

26. The method ofclaim 1 further comprising presenting the one or more content recommendations to the first user.

27. A computing device comprising:

a communication interface; and

a controller associated with the communication interface and adapted to:

obtain an aggregate profile for a predicted encounter of a first user, the aggregate profile being based on user profiles of a plurality of second users identified for the predicted encounter of the user; and

obtain one or more content recommendations for the first user based on the aggregate profile for the predicted encounter.

28. A computer readable medium storing software for instructing a controller of a computing device to:

obtain an aggregate profile for a predicted encounter of a first user, the aggregate profile being based on user profiles of a plurality of second users identified for the predicted encounter of the user; and

obtain one or more content recommendations for the first user based on the aggregate profile for the predicted encounter.

Images