SMART ENCOUNTERS

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 of FIG. 1 according to one embodiment of the present disclosure;

FIG. 3 is a more detailed illustration of one of the MAP clients 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 location updates 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 location updates to the MAP server according to another embodiment of the present disclosure;

FIG. 6 illustrates the operation of the system of FIG. 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 of FIG. 1 according to one embodiment of the present disclosure;

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

FIG. 15 is a block diagram of the content consumption device of FIG. 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 a system 10 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, the system 10 includes a Mobile Aggregate Profile (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 content consumption device (CCD) 22 having an associated user 24, and one or more recommendation services 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. As discussed below in detail, in this embodiment, the MAP server 12 operates to predict encounters between users such as the users 20-1 through 20-N and 24 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, the MAP server 12 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 users 20-1 through 20-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 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 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 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, the MAP client 30-1 may enable 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 content consumption device (CCD) 22 is a user device that enables the user 24 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, the CCD 22 may be a set-top box that enables the user 24 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, the CCD 22 may be an Internet enabled device such as, for example, a personal computer or mobile smart phone that enables the user 24 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, the CCD 22 includes a smart encounters service 38. The smart encounters service 38 is preferably implemented in software, but is not limited thereto. As discussed below in detail, the smart encounters service 38 operates to obtain content recommendations for the user 24 based on aggregate profile data for predicted encounters between the user 24 and other users such as the users 20-1 through 20-N. More specifically, as used herein, a predicted encounter is either a predicted physical encounter or a predicted remote encounter. Using the user 24 as an example, a predicted physical encounter for the user 24 is a future time, or future period of time, when the user 24 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 the user 24 is a future time, or future period of time, when the user 24 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, the smart encounters service 38 generates the content recommendations locally based on the aggregate profile data. In another embodiment, the smart encounters service 38 queries the one or more recommendation services 26 using the aggregate profile data for the predicted encounters to obtain content recommendations for the user 24. The recommendation services 26 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 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.

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 40, a business logic layer 42, and a persistence layer 44. The application layer 40 includes a user web application 46, a mobile client/server protocol component 48, and one or more data Application Programming Interfaces (APIs) 50. The user web application 46 is preferably implemented in software and operates to provide a web interface for accessing the MAP server 12 via a web browser. The mobile client/server protocol component 48 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 50 enable third-party services to access the MAP server 12. In one embodiment, the smart encounters service 38 is a third-party service that accesses the MAP server via the data APIs 50.

The business logic layer 42 includes a profile manager 52, a location manager 54, a history manager 56, a crowd analyzer 58, an aggregation engine 60, and a prediction engine 62, each of which is preferably implemented in software. The profile manager 52 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 44. The location manager 54 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 56 generally operates to maintain a historical record of anonymized user profile data by location. However, in this embodiment, the history manager 56 may also operate to maintain historical records of the locations of the users 20-1 through 20-N, where the historical records may be used to predict future locations of the users 20-1 through 20-N. The crowd analyzer 58 operates to form crowds of users. In one embodiment, the crowd analyzer 58 utilizes a spatial crowd formation algorithm. However, the present disclosure is not limited thereto. In addition, the crowd analyzer 58 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, the crowd analyzer 58 may also operate to track crowds. The aggregation engine 60 generally operates to provide aggregate profile data in response to requests from the mobile devices 18-1 through 18-N and the smart encounters service 38. The prediction engine 62 generally operates to predict encounters between users in response to requests from smart encounters services, such as the smart encounters service 38, as discussed below in detail.

The persistence layer 44 includes an object mapping layer 64 and a datastore 66. The object mapping layer 64 is preferably implemented in software. The datastore 66 is preferably a relational database, which is implemented in a combination of hardware (i.e., physical data storage hardware) and software (i.e., relational database software). In this embodiment, the business logic layer 42 is implemented in an object-oriented programming language such as, for example, Java. As such, the object mapping layer 64 operates to map objects used in the business logic layer 42 to relational database entities stored in the datastore 66. Note that, in one embodiment, data is stored in the datastore 66 in a Resource Description Framework (RDF) compatible format.

In an alternative embodiment, rather than being a relational database, the datastore 66 may be implemented as an RDF datastore. More specifically, the RDF datastore may be compatible with RDF technology adopted by Semantic Web activities. Namely, the RDF datastore may use the Friend-Of-A-Friend (FOAF) vocabulary for describing people, their social networks, and their interests. In this embodiment, the MAP server 12 may be designed to accept raw FOAF files describing persons, their friends, and their interests. These FOAF files are currently output by some social networking services such as Livejournal and Facebook. The MAP server 12 may then persist RDF descriptions of the users 20-1 through 20-N as a proprietary extension of the FOAF vocabulary that includes additional properties desired for the system 10.

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 68, a MAP middleware component 70, and a mobile client/server protocol component 72. The MAP access API 68 is implemented in software and provides an interface by which the MAP client 30-1 and the third-party applications 34-1 are enabled to access the MAP server 12. The MAP middleware component 70 is implemented in software and performs the operations needed for the MAP client 30-1 to operate as an interface between the MAP application 32-1 and the third-party applications 34-1 at the mobile device 18-1 and the MAP server 12. The mobile client/server protocol component 72 enables communication between the MAP client 30-1 and the MAP server 12 via a defined protocol.

FIG. 4 illustrates the operation of the system 10 of FIG. 1 to provide the user profile of the user 20-1 of the mobile device 18-1 to the MAP server 12 according to one embodiment of the present disclosure. This discussion is equally applicable to user profiles of the other users 20-2 through 20-N of the other mobile devices 18-2 through 18-N. First, an authentication process is performed (step 1000). For authentication, in this embodiment, the mobile device 18-1 authenticates with the profile server 14 (step 1000A) and the MAP server 12 (step 1000B). In addition, the MAP server 12 authenticates with the profile server 14 (step 1000C). Preferably, authentication is performed using OpenID or similar technology. However, authentication may alternatively be performed using separate credentials (e.g., username and password) of the user 20-1 for access to the MAP server 12 and the profile server 14. Assuming that authentication is successful, the profile server 14 returns an authentication succeeded message to the MAP server 12 (step 1000D), and the profile server 14 returns an authentication succeeded message to the MAP client 30-1 of the mobile device 18-1 (step 1000E).

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 52 of the MAP server 12 processes the user profile (step 1002D). More specifically, in the preferred embodiment, the profile manager 52 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 52 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 52 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 52 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 52 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 52 of the MAP server 12 stores the resulting user profile for the user 20-1 (step 1002E). More specifically, in one embodiment, the MAP server 12 stores user records for the users 20-1 through 20-N in the datastore 66 (FIG. 2). The user profile of the user 20-1 is stored in the user record of the user 20-1. The user record of the user 20-1 includes a unique identifier of the user 20-1, the user profile of the user 20-1, and, as discussed below, a current location of the user 20-1. Note that the user profile of the user 20-1 may be updated as desired. For example, in one embodiment, the user profile of the user 20-1 is updated by repeating step 1002 each time the user 20-1 activates the MAP application 32-1.

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

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 54 of the MAP server 12 stores the current location of the mobile device 18-1 as the current location of the user 20-1 (step 1004B). More specifically, in one embodiment, the current location of the user 20-1 is stored in the user record of the user 20-1 maintained in the datastore 66 of the MAP server 12. 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. However, in another embodiment, a historical record of the location of the user 20-1 may be maintained by the history manager 56 within the user record of the user 20-1 or as a separate record. The historical record of the location of the user 20-1 may be utilized by the prediction engine 62 to predict encounters between the user 20-1 and other user(s) in the future.

In addition to storing the current location of the user 20-1, the location manager 54 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 54 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 of the user 20-1 of the mobile device 18-1 according to another embodiment of the present disclosure. This discussion is equally applicable to user profiles of the other users 20-2 through 20-N of the other mobile devices 18-2 through 18-N. First, an authentication process is performed (step 1100). For authentication, in this embodiment, the mobile device 18-1 authenticates with the MAP server 12 (step 1100A), and the MAP server 12 authenticates with the profile server 14 (step 1100B). Preferably, authentication is performed using OpenID or similar technology. However, authentication may alternatively be performed using separate credentials (e.g., username and password) of the user 20-1 for access to the MAP server 12 and the profile server 14. Assuming that authentication is successful, the profile server 14 returns an authentication succeeded message to the MAP server 12 (step 1100C), and the MAP server 12 returns an authentication succeeded message to the MAP client 30-1 of the mobile device 18-1 (step 1100D).

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 52 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 52 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 52 of the MAP server 12 processes the user profile (step 1102C). More specifically, as discussed above, in the preferred embodiment, the profile manager 52 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 52 of the MAP server 12 stores the resulting user profile for the user 20-1 (step 1102D). More specifically, in one embodiment, the MAP server 12 stores user records for the users 20-1 through 20-N in the datastore 66 (FIG. 2). The user profile of the user 20-1 is stored in the user record of the user 20-1. The user record of the user 20-1 includes a unique identifier of the user 20-1, the user profile of the user 20-1, and, as discussed below, a current location of the user 20-1. Note that the user profile of the user 20-1 may be updated as desired. For example, in one embodiment, the user profile of the user 20-1 is updated by repeating step 1102 each time the user 20-1 activates the MAP application 32-1.

Note that while the discussion herein focuses on an embodiment where the user profiles of the users 20-1 through 20-N are obtained from the one or more profile servers 14, the user profiles of the users 20-1 through 20-N may be obtained in any desired manner. For example, in one alternative embodiment, the user 20-1 may identify one or more favorite websites. The profile manager 52 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.

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 54 of the MAP server 12 stores the current location of the mobile device 18-1 as the current location of the user 20-1 (step 1104C). More specifically, in one embodiment, the current location of the user 20-1 is stored in the user record of the user 20-1 maintained in the datastore 66 of the MAP server 12. 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. However, in another embodiment, a historical record of the location of the user 20-1 may be maintained by the history manager 56 within the user record of the user 20-1 or as a separate record. The historical record of the location of the user 20-1 may be utilized by the prediction engine 62 to predict encounters between the user 20-1 and other user(s) in the future.

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

FIG. 6 illustrates the operation of the system 10 of FIG. 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, the smart encounters service 38 first obtains encounter parameters to be used to predict encounters between the user 24 and the users 20-1 through 20-N and recommendation parameters to be used to obtain content recommendations based on aggregate profile data for predicted encounters for the user 24 (steps 2000 and 2002). 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 the user 24 or remotely interacting with the user 24 before that user is said to be part of a predicted encounter with the user 24. 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 the user 24 form a predicted physical encounter with the user 24. 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 the user 24 form an encounter with the user 24. In this embodiment, the encounter parameters are configurable by the user 24. However, in another embodiment, the encounter parameters are system-defined and either programmed into or stored by the prediction engine 62, in which case step 2000 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, the smart encounters service 38 sends an encounter-based aggregate profile request to the MAP server 12 (step 2004). 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 the user 24. In another embodiment, the request is initiated by the smart encounters service 38. For example, in one embodiment, once the smart encounters service 38 is configured by the user 24, the smart encounters service 38 may periodically send requests to the MAP server 12 and obtain corresponding content recommendations.

In response to the encounter-based aggregate profile request, the MAP server 12, and more specifically the prediction engine 62, predicts one or more encounters for the user 24 (step 2006). In one embodiment, the prediction engine 62 predicts one or more physical encounters for the user 24 during the time window for the request. In another embodiment, the prediction engine 62 predicts one or more remote encounters for the user 24 during the time window for the request. In yet another embodiment, the prediction engine 62 predicts one or more physical encounters and one or more remote encounters for the user 24 during the time window for the request.

In order to predict physical encounters of the user 24, the prediction engine 62 predicts one or more future locations of the user 24 and one or more future locations of each of at least a subset of the users 20-1 through 20-N during the time window for the request. In one embodiment, the future locations of the user 24 may be predicted based on a historical record of the location of the user 24 or a schedule of the user 24 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 the user 24, if the CCD 22 is a location-aware portable device, the MAP server 12 may obtain location updates for the location of the user 24 via the CCD 22 in a manner similar to that described above for the users 20-1 through 20-N of the mobile devices 18-1 through 18-N and maintain the historical record of the user 24 based thereon. Alternatively, the user 24 may also be one of the users 20-1 through 20-N, in which case the user 24 is identified as one of the users 20-1 through 20-N and the corresponding historical record of the location of that user is used as the historical record of the location of the user 24. Regarding the schedule of the user 24, in one embodiment, the schedule of the user 24 may be maintained on the CCD 22 via, for example, an electronic calendar. The schedule of the user 24 may identify a location of each scheduled event and information identifying the other users, if any, to participate in the scheduled event. The CCD 22 may then provide the schedule of the user 24, or at least a relevant portion thereof, to the MAP server 12. Alternatively, the user 24 may also be one of the users 20-1 through 20-N, in which case the schedule of the user 24 may be stored in a user record maintained by the MAP server 12 for that user. In this case, the schedule of the user 24 may be obtained from the corresponding one of the mobile devices 18-1 through 18-N, obtained from the profile servers 14 if such information is maintained by the profile servers 14, or the like. In a similar manner, the MAP server 12 may obtain schedules of the users 20-1 through 20-N.

Overlaps in the future locations of the user 24 and the future locations of one or more of the users 20-1 through 20-N that last for at least the minimum amount of time required for predicted encounters are identified as predicted physical encounters for the user 24. The overlaps in the future locations of the user 24 and the future locations of the one or more of the users 20-1 through 20-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. The prediction engine 62 may then analyze the historical record of the location of the user 24 to determine that the user 24 regularly visits a particular location Fridays from 3-5 P.M. As such, prediction engine 62 identifies that particular location as a predicted, or future, location of the user 24. In a similar manner, the prediction engine 62 analyzes the historical records of the users 20-1 through 20-N to predict locations of the users 20-1 through 20-N on Friday. Then, any of the users 20-1 through 20-N that are predicted to be located at or sufficiently near the predicted location of the user 24 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 the user 24. The prediction engine 62 then creates a predicted physical encounter record that identifies the other users identified for the predicted physical encounter with the user 24 and, optionally, the user 24 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. The prediction engine 62 may then analyze the schedule of the user 24 for Friday to identify a particular street address as a predicted location of the user 24 from 3-5 P.M. on Friday. In a similar manner, the prediction engine 62 analyzes the schedules of the users 20-1 through 20-N to determine which of the users 20-1 through 20-N are scheduled to be located at the same street address as the user 24 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 the user 24. The prediction engine 62 then creates a predicted physical encounter record that identifies the other users identified for the physical encounter with the user 24 and, optionally, the user 24 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, the prediction engine 62 may predict one or more remote encounters for the user 24 based on a schedule of the user 24 and/or schedules of the users 20-1 through 20-N. For example, if the time window for the request is tomorrow, which for this example is Friday, the prediction engine 62 may analyze the schedule of the user 24 for Friday to identify a remote encounter with one or more of the other users 20-1 through 20-N. The remote encounter may be, for example, a scheduled conference call between the user 20-1 and two or more of the users 20-1 through 20-N. As another example, if the time window for the request is tomorrow, which for this example is Friday, the prediction engine 62 may analyze the schedules of the users 20-1 through 20-N to identify any of the users 20-1 through 20-N that have a scheduled remote encounter with the user 24. Again, the remote encounter may be a conference call. The identified users are users for the predicted remote encounter with the user.

The prediction engine 62 may also predict one or more remote encounters for the user 24 based on a call log of the user 24 and/or call logs of the other users 20-1 through 20-N. Note that the call logs of the users 20-1 through 20-N and 24, or at least relevant portions thereof, may be obtained from the mobile devices 18-1 through 18-N and, if applicable, the CCD 22 and stored by the MAP server 12. For example, the time window for the request may be tomorrow, which for this example is Friday. The prediction engine 62 may analyze the call log of the user 24 and/or the call logs of the users 20-1 through 20-N to determine that the user 24 regularly participates in a telephone call or a conference call with one or more of the users 20-1 through 20-N on Fridays from 11A.M. until Noon. As such, the prediction engine 62 creates a predicted remote encounter between the user 24 and the one or more of the users 20-1 through 20-N that regularly participate in the telephone call or conference call.

Once the prediction engine has predicted the one or more encounters for the user 24 (also referred to herein as predicted encounters of the user 24), the MAP server 12, and more specifically the aggregation engine 60, generates one or more aggregate profiles for each of the predicted encounters of the user 24 (step 2008). In general, the aggregate profiles generated for the predicted encounters for the user 24 reflect aggregate interests of the users identified for the predicted encounters with the user 24. While discussed below in detail, in one embodiment, for each predicted encounter, the aggregation engine 60 generates a single aggregate profile for the predicted encounter. In another embodiment, for each predicted encounter, the aggregation engine 60 divides the users identified for the predicted encounter with the user 24 into a number of user groups and generates a separate aggregate profile for each of the user groups.

Next, the MAP server 12 returns the aggregate profile(s) for the one or more predicted encounters to the smart encounters service 38 (step 2010). Then, the smart encounters service 38 obtains one or more content recommendations for the user 24 based on the aggregate profile(s) for the predicted encounter(s) of the user 24 (step 2012). 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, the CCD 22 is a set-top box that enables the user 24 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, the smart encounters service 38 may obtain the one or more content recommendations for the user 24 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. The smart encounters service 38 may then create content recommendations for television content that matches the aggregate profile to at least a defined threshold degree. In another embodiment, the CCD 22 has access to the one or more recommendation services 26 via the network 28. As such, for each of the aggregate profiles, the smart encounters service 38 may query at least one of the recommendation services 26 using the aggregate profile to obtain content recommendations. Note that step 2010 and/or step 2012 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.

The smart encounters service 38 then presents the content recommendations to the user 24 at the CCD 22 via an associated Graphical User Interface (GUI) (step 2014). In one embodiment, each content recommendation includes a name or title of the recommended content and information enabling the user 24 to access the recommended content. The information enabling the user 24 to access the recommended content may vary depending on the particular implementation and the type of recommended content. For example, the information enabling the user 24 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 flow chart illustrating step 2008 of FIG. 6 in more detail according to one embodiment of the present disclosure. Specifically, in this embodiment, the aggregation engine 60 of the MAP server 12 generates a single aggregate profile for each of the one or more predicted encounters for the user 24. First, the aggregation engine 60 selects a next predicted encounter to process, which for the first iteration is the first predicted encounter for the user 24 (step 2100). The aggregation engine 60 then selects the next user identified for the predicted encounter with the user 24 (step 2102). Next, the aggregation engine 60 compares the user profile of the user identified for the predicted encounter to the user profile of the user 24, or a select subset of the user profile of the user 24 (step 2104). In some embodiments, the user 24 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, the user 24 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 the user 24, the aggregation engine 60 identifies matches between the user profile of the user identified for the encounter and the user profile of the user 24 or the select subset of the user profile of the user 24. In one embodiment, the user profiles are expressed as keywords in a number of profile categories. The aggregation engine 60 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 the user 24 or the select subset of the user profile of the user 24.

Next, the aggregation engine 60 determines whether there are more users identified for the encounter with the user 24 (step 2106). If so, the process returns to step 2102 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, the aggregation engine 60 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 the user 24 or the select subset of the user profile of the user 24 (step 2108). In an alternative embodiment, the aggregation engine 60 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 the user 24.

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 the user 24 or the select subset of the user profile of the user 24, 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 the user 24 or the select subset of the user profile of the user 24 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, the aggregation engine 60 determines whether there are more predicted encounters to process (step 2110). If so, the process returns to step 2100 and is repeated for the next predicted encounter. Once aggregate profiles have been generated for all of the predicted encounters for the user 24, the aggregate profiles for the predicted encounters are returned to the smart encounters service 38 (step 2112). In an alternative embodiment, the aggregate profiles for the predicted encounters are returned to the smart encounters service 38 one by one as the aggregate profiles are generated in step 2108. In this case, the list of predicted encounters is preferably returned to the smart encounters service 38 in step 2006 of FIG. 6.

FIG. 8 is a flow chart illustrating step 2008 of FIG. 6 in more detail according to another embodiment of the present disclosure. Specifically, in this embodiment, the aggregation engine 60 of the MAP server 12 generates a single aggregate profile for each of the one or more predicted encounters for the user 24. First, the aggregation engine 60 selects a next predicted encounter for the user 24 to process, which for the first iteration is the first predicted encounter for the user 24 (step 2200). The aggregation engine 60 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 (step 2202). In this embodiment, neither the user profile of the user 24 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, the aggregation engine 60 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, the aggregation engine 60 determines whether there are more predicted encounters for the user 24 to process (step 2204). If so, the process returns to step 2200 and is repeated for the next predicted encounter. Once aggregate profiles have been generated for all of the predicted encounters for the user 24, the aggregate profiles for the predicted encounters are returned to the smart encounters service 38 (step 2206).

FIG. 9 is a flow chart illustrating step 2008 of FIG. 6 in more detail according to yet another embodiment of the present disclosure. Specifically, in this embodiment, the aggregation engine 60 of the MAP server 12 generates an aggregate profile for each of a number of user groups for each of the one or more predicted encounters for the user 24. First, the aggregation engine 60 selects a next predicted encounter for the user 24 to process, which for the first iteration is the first predicted encounter for the user 24 (step 2300). The aggregation engine 60 then divides the users identified for the predicted encounter into a number of user groups (step 2302). In one embodiment, the aggregation engine 60 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, the aggregation engine 60 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, the aggregation engine 60 selects the next user group for the predicted encounter, which for the first iteration is the first user group for the predicted encounter (step 2304). The aggregation engine 60 then generates an aggregate profile for the user group for the predicted encounter (step 2306). In one embodiment, the aggregate profile is generated by comparing the user profile of the user 24, 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 to FIG. 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 to FIG. 8. In this embodiment, neither the user profile of the user 24 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, the aggregation engine 60 determines whether the last user group for the predicted encounter has been processed (step 2308). If not, the process returns to step 2304 and is repeated. Once the last user group for the predicted encounter is processed, the aggregation engine 60 determines whether the last predicted encounter has been processed (step 2310). If not, the process returns to step 2300 and is repeated. Once the last predicted encounter has been processed, the aggregation engine 60 returns the aggregate profiles for the user groups for each of the one or more predicted encounters to the smart encounters service 38 (step 2312).

FIG. 10 is a flow chart illustrating step 2302 of FIG. 9 in more detail according to one embodiment of the present disclosure. Note that while in this discussion the process of FIG. 10 is performed by the aggregation engine 60, the process of FIG. 10 may alternatively be performed by the crowd analyzer 58, where the users identified for the predicted encounter are treated as a crowd and the crowd analyzer 58 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, the aggregation engine 60 first creates a user group for each user identified for the predicted encounter (step 2400). The user groups created in step 2400 each include a single user.

Next, the aggregation engine 60 selects a next pair of user groups (step 2402) and then selects one user from each of those user groups (step 2404). The aggregation engine 60 then determines a DOS between the users from the pair of user groups (step 2406). 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.

The aggregation engine 60 then determines whether the DOS between the two users is less than a predefined maximum DOS for a user group (step 2408). 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 step 2414. If the DOS between the two users is less than the predefined maximum DOS, the aggregation engine 60 determines whether a bidirectionality requirement is satisfied (step 2410). 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, the aggregation engine 60 combines the pair of user groups (step 2412) and the process then returns to step 2402 and is repeated for a next pair of user groups. If the two users do not satisfy the bidirectionality requirement, the process proceeds to step 2414.

At this point, whether proceeding from step 2408 or step 2410, the aggregation engine 60 determines whether all user pairs from the two user groups have been processed (step 2414). If not, the process returns to step 2404 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, the aggregation engine 60 then determines whether all user groups have been processed (step 2416). If not, the process returns to step 2402 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 an exemplary GUI 74 provided by the smart encounters service 38 according to one embodiment of the present disclosure. As illustrated, the GUI 74 enables the user 24 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 the user 24. In this example, the time window is April 24^th from 8:30 A.M. to 5:30 P.M. The time window can be changed by the user 24 by selecting an edit button 76. Once the user 24 has configured the time window, the smart encounters service 38 sends an encounters-based aggregate profile request to the MAP server 12, as discussed above. In response, the MAP server 12 determines one or more predicted encounters for the user 24, generates aggregate profiles for the predicted encounters, and returns the aggregate profiles to the smart encounters service 38.

In this embodiment, the smart encounters service 38 enables the user 24 to view the locations of the predicted encounters and the aggregate profiles for the predicted encounters. More specifically, the GUI 74 includes a map area 78 for presenting the locations of the predicted encounters to the user 24. In this example, there are three predicted encounters, namely, a predicted encounter 80 at the user's work location, a predicted encounter 82 at a gym that the user regularly visits, and a predicted encounter 84 at a deli that the user 24 regularly visits. As further illustrated, the GUI 74 enables the user 24 to select, for example, the predicted encounter 80 in order to view an aggregate profile 86 for the predicted encounter 80. Buttons 88-94 enable the user 24 to modify, or edit, corresponding keywords in the aggregate profile 86 for purposes of generating content recommendations for the predicted encounter. As such, if the user 24 modifies one of the keywords in the aggregate profile 86, the content recommendations for the predicted encounter will also change. In addition, buttons 96-102 enable the user 24 to delete corresponding keywords in the aggregate profile 86 for purposes of content recommendations. Buttons 104 and 106 enable the user 24 to navigate from one predicted encounter to another. Thus, if there are multiple predicted encounters for the user 24, the user 24 may use the buttons 104 and 106 to view the aggregate profiles and content recommendations for the different predicted encounters.

In addition, the GUI 74 includes a content recommendations area 108 for presenting the content recommendations for the selected predicted encounter to the user 24. In this embodiment, the content recommendations area 108 includes a Now button 110 that, if selected, causes only content recommendations for currently available content to be presented to the user 24 and a Later button 112 that, if selected, causes only content recommendations for content that will be available at a later time to be presented to the user 24. The content recommendations area 108 also includes an All button 114. If both the Now button 110 and the All button 114 are selected, the GUI 74 presents all content recommendations for currently available content to be presented to the user 24. If both the Later button 112 and the All button 114 are selected, the GUI 74 presents all content recommendations for content that will be available at a later time to be presented to the user 24 in the content recommendations area 108. In a similar manner, a TV button 116 may be used in connection with the Now button 110 or Later button 118 to view content recommendations for television content that is currently available or will be later available. Likewise, a Web button 118 may be used in connection with the Now button 110 or Later button 118 to view content recommendations for web-based content that is currently available or will be later available. A Local button 120 may be used in connection with the Now button 110 or Later button 118 to view content recommendations for locally stored content that is currently available or will be later available. Buttons 122 and 124 may be used by the user 24 to scroll left or right in the content recommendations area 108 to view additional content recommendations.

FIG. 12 illustrates another exemplary GUI 126 that may be provided by the smart encounters service 38 according to another embodiment of the present disclosure. The GUI 126 is particularly relevant to the embodiment where the CCD 22 is a mobile device, such as a mobile smart phone. In this embodiment, the smart encounters service 38 provides content recommendation alerts to the user 24. More specifically, after obtaining a predicted encounter and an aggregate profile for the predicted encounter from the MAP server 12, the smart encounters service 38 periodically obtains content recommendations for the predicted encounter based on the aggregate profile for the predicted encounter. When new recommended content is found, the smart encounters service 38 provides a content recommendation alert for the predicted encounter to the user 24 via the GUI 126.

As illustrated, the GUI 126 includes an Alerts button 128 that, when selected by the user 24, causes content recommendation alerts to be presented to the user 24. In this example, upon selecting the Alerts button 128, a new content recommendation alert is presented to the user 24. Button 130 may be selected by the user 24 to access the recommended content, view information enabling the user 24 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. Button 132 may be selected by the user 24 to delete or otherwise remove the new alert. Also, as shown, the GUI 126 identifies the predicted encounter for which the alert is provided, which for this example is “Charlotte Meeting.” A Previous Alerts button 134 may be selected by the user 24 in order to view previously received content recommendation alerts. A Map button 136 may be selected by the user 24 to view a map showing a location of each of a number of predicted encounters for the user 24. Lastly, a Settings button 138 may be selected by the user 24 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. The settings button 138 may also be selected by the user 24 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 the MAP server 12 according to one embodiment of the present disclosure. As illustrated, the MAP server 12 includes a controller 140 connected to memory 142, one or more secondary storage devices 144, and a communication interface 146 by a bus 148 or similar mechanism. The controller 140 is a microprocessor, digital Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or the like. In this embodiment, the controller 140 is a microprocessor, and the application layer 40, the business logic layer 42, and the object mapping layer 64 (FIG. 2) are implemented in software and stored in the memory 142 for execution by the controller 140. Further, the datastore 66 (FIG. 2) may be implemented in the one or more secondary storage devices 144. The secondary storage devices 144 are digital data storage devices such as, for example, one or more hard disk drives. The communication interface 146 is a wired or wireless communication interface that communicatively couples the MAP server 12 to the network 28 (FIG. 1). For example, the communication interface 146 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 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 150 connected to memory 152, a communication interface 154, one or more user interface components 156, and the location function 36-1 by a bus 158 or similar mechanism. The controller 150 is a microprocessor, digital ASIC, FPGA, or the like. In this embodiment, the controller 150 is a microprocessor, and the MAP client 30-1, the MAP application 32-1, and the third-party applications 34-1 are implemented in software and stored in the memory 152 for execution by the controller 150. In this embodiment, the location function 36-1 is a hardware component such as, for example, a GPS receiver. The communication interface 154 is a wireless communication interface that communicatively couples the mobile device 18-1 to the network 28 (FIG. 1). For example, the communication interface 154 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 156 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 the CCD 22 according to one embodiment of the present disclosure. As illustrated, the CCD 22 includes a controller 160 connected to memory 162, one or more secondary storage devices 164, a communication interface 166, and one or more user interface components 168 by a bus 170 or similar mechanism. The controller 160 is a microprocessor, digital ASIC, FPGA, or the like. In this embodiment, the controller 160 is a microprocessor, and the smart encounters service 38 (FIG. 1) is implemented in software and stored in the memory 162 for execution by the controller 160. The one or more secondary storage devices 164 are digital storage devices such as, for example, one or more hard disk drives. The communication interface 166 is a wired or wireless communication interface that communicatively couples the CCD 22 to the network 28 (FIG. 1). For example, the communication interface 166 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 components 168 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 the system 10 described herein provides substantial opportunity for variation without departing from the spirit or scope of the present disclosure. For example, while the smart encounters service 38 has been illustrated and described as being implemented on the CCD 22, the smart encounters service 38 may be implemented on each of one or more of the mobile devices 18-1 through 18-N as, for instance, third-party applications 34-1 through 34-N. As another example, the smart encounters service 38 may be implemented on a server, such as the MAP server 12, wherein users, such as the users 20-1 through 20-N and 24, may access the smart encounters service 38 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

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 of claim 1 wherein the predicted encounter is a predicted physical encounter.

3. The method of claim 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 of claim 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 of claim 2 wherein the predicted physical encounter is predicted based on a schedule of the first user.

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

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

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

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

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

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

12. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 1 wherein the plurality of second users are users identified for the predicted encounter.

26. The method of claim 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.