HK1195651A - Identifying and employing social network relationships - Google Patents

Abstract

The invention published the identifying and employing social network relationships, describing for detecting social relationships across multiple networks and/or communication channels. These social relationships may then be utilized in a wide variety of ways to support and enhance a broad range of user services.

Description

Identifying and using social network relationships

The application is a divisional application of Chinese patent application No.200880124053.7 entitled "identifying and using social network relationships" filed on 16.12.2008.

Cross Reference to Related Applications

This application claims priority from U.S. patent application No.12/069,731 (attorney docket No. yah1p134/Y04232US01), filed on 11/2008, month 2, according to 35u.s.c120, and from U.S. provisional patent application No.61/019,215 (attorney docket No. yah1p134/Y04232US00), filed on 4/2008, month 1, according to 35u.s.c119(e), the entire disclosures of both of which are incorporated herein by reference for all purposes.

Technical Field

The present invention relates to social networking on the Web, and in particular to techniques for aggregating social networking data from multiple disparate sources.

Background

Many users of the world Wide Web are members of multiple user networks, each of which is typically controlled by a service provider that exercises exclusive control over its dataIncluding data representing the connections (connections) between its members. Examples of such networks include, for exampleFacebook, MySpace, Flickr, LinkedIn, Twitter, and the like. Because of this transactional state, there is typically a large amount of data representing a given user's social network that is not apparent or available to each of the different service providers. As a result, neither the user nor the service provider can utilize the full potential of the user's social connections.

Disclosure of Invention

In accordance with the present invention, techniques are provided to identify and utilize social relationships of individuals to support a wide range of functionality. According to particular embodiments, methods and apparatus are provided for identifying social relationships for a first user operating in a first network context controlled by a first entity. The identity of the first user is generated with reference to a first data source associated with the first network context and under control of the first entity and at least one external data source that is outside the first network context and not under control of the first entity. A plurality of contacts having a relationship with the first user are identified with reference to the first data source, the at least one external data source, and the identity of the first user. A first plurality of contacts of the plurality of contacts cannot be identified from the first data source. A relevancy measure is determined for each of a plurality of contacts that represents the relevancy of the relationship between the first user and the contact. The relevancy measure for each contact is determined with reference to one or more of the first data source or the at least one external data source.

According to another specific embodiment, a method and apparatus for identifying social relationships for a first user operating in a first network context controlled by a first entity is provided. A first user is presented with a plurality of contacts having a relationship with the first user. The plurality of contacts are determined with reference to a first data source associated with the first network context and under control of the first entity, at least one external data source outside the first network context and not under control of the first entity, and an identity of the first user. The identity is determined with reference to the first data source and at least one external data source. A first plurality of contacts of the plurality of contacts cannot be identified from the first data source. The plurality of contacts are presented according to a relevancy measure associated with each of the plurality of contacts that represents a relevancy of the relationship between the first user and the associated contact. The relevancy measure for each contact is determined with reference to one or more of the first data source or the at least one external data source.

According to some embodiments, aggregation of vitality over multiple contexts is enabled. According to further embodiments, each external data source uses a permission model for controlling access to information associated with the external data source. The permission models of the various external data sources are aggregated, thereby enabling access to information associated with each external data source according to its respective permission model.

A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings.

Drawings

Fig. 1-3 are screen shots illustrating a process flow according to a specific embodiment of the invention.

FIG. 4 is a simplified network diagram illustrating a computing scenario in which an embodiment of the present invention may be implemented.

Fig. 5-18 are screen shots illustrating a process flow according to a specific embodiment of the invention.

Fig. 19 and 20 are representations of interfaces that may be used in conjunction with embodiments of the present invention.

FIGS. 21-25 are mobile screen shots illustrating a process flow according to another specific embodiment of the invention.

Detailed Description

Reference will now be made in detail to specific embodiments of the invention including the best modes contemplated by the inventors for carrying out the invention. Examples of these specific embodiments are illustrated in the accompanying drawings. While the invention will be described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, specific details are set forth to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. Additionally, well known features may not have been described in detail to avoid unnecessarily obscuring the invention.

According to various embodiments of the present invention, methods and apparatus are provided that are operable to detect apparent and potential social relationships for a given user across multiple networks or communication channels (e.g., social networks, web portals, communication or messaging systems, etc.). These social relationships may then be utilized in a variety of ways to support and/or enhance a wide variety of user services.

An apparent relationship may be represented, for example, by an explicit association (e.g., in an address book, contact list, buddy list, etc.) between the user and an identity or identity token associated with the other user. The potential relationships are generally less explicit and may be represented by communication patterns or mutual friend connections, for example. Embodiments of the present invention take advantage of potential and apparent social relationships and represent a transition from a "network-centric" or "channel-centric" connection model to a "person-centric" model that works across multiple social networks and communication and vitality (vitality) channels. As will be discussed, various types of potential and apparent social relationships may be detected in a variety of ways.

Furthermore, embodiments of the present invention enable the aggregation of vitality from a variety of sources. Vitality refers to an event or action (e.g., publish content, change state, install and use applications, etc.) corresponding to a particular individual or group of individuals, e.g., what a user's contacts are doing on the Web. Vitality can be distinguished from messaging-type contacts because, for example, an email explicitly defines a group of recipients that are allowed to read the email. In contrast, vitality is a broadcast form of communication based on user actions, with an implicit set of recipients defined by a social relationship graph. This social relationship graph may be labeled and/or subdivided according to category labels such as "friends," "family," "school," "work," and/or many other group or organization based associations.

Thus, one's vitals, "recipients," are predefined and typically receive notification of content distribution as it occurs, the recipients having been implicitly licensed to consume the content. Embodiments of the present invention that enable aggregating vitality allow users to access, aggregate, and display vitality by utilizing existing permissions and privacy models for various networks and/or channels to see vitality events (e.g., status text updates, photo uploads, application installations, etc.) associated with their contacts on the network and/or communication channels.

One example may be of teaching significance. Two users may be inExplicit connections in the network, since they make use ofThe mails intercommunicate with the e-mail. The two users may also have several other contacts, such as Flickr contacts, Facebook friends, Twitter followers, LinkedIn contacts, and so on, some of which may be characterized as obvious and some of which may be characterized as potential. When one of the users initiates a connection Activator (e.g., using the "Simplify Young Inbox" of FIG. 1!(simplify your inbox) button), the Connections Activator first determines who the initiator user is. According to one set of embodiments, this is done by searching for the current network context (e.g., for exampleNetworks) (and in particular, the identity of the user's login on the Yahoo | network), and possibly a wider Web context (perhaps a specified set of networks or attributes on the Web), and gathers data that can be used to identify the user (e.g., user profiles, pages, vitality, etc. generated on current and other networks; any information token that can be used to identify a user).

The identity of the user may also be determined at least in part by requesting input from the user himself. This may include requiring the user to specifically identify other networks, other attributes in the current network, or other systems to which the user belongs or on which the user is represented in some way. The various data is then integrated into a representation of the user. This may be presented to the user, for example as in FIG. 2Not in the interface.

Once the user has been identified, the next phase of activation can be initiated (e.g., using the "Activate your network" button in fig. 2), during which the Connections Activator searches for and gathers data (on the current network, other properties on the current network, other networks or systems on the Web, etc.) relating to others with whom the user interacts. These other individuals may be identified, for example, based on the user's communication mode, the relationship with the user in the current context or other network, an address book, a contact list, the vitality expended by the user, and so forth. These data are then integrated into a representation of the person with whom the user has a relationship.

In some cases, it may be desirable to determine whether identities or identity tokens in different networks correspond to the same person, and if so, whether the identities should be integrated into a single person's representation or "de-duplicated". This may occur, for example, where a person uses different names in different networks. Integration can be automatic, manual (e.g., with input from the user), or semi-automatic, where the system and user can interleave actions in a de-duplication process with feedback from each other in the process. Such de-duplication may be accomplished by comparing identity tokens such as names, email addresses, phone numbers, and the like.

According to various embodiments, the gathering of data may be accomplished using a variety of techniques. For example, one data repository in a current network may have user profile data about a user, while another has the first name, last name, and email address of the contact. A repository in another network may have the first and last names of the contact, as well as other information, such as a telephone number or web page URL. Another repository in the other network may have additional information related to the user himself. Each piece of additional information or token related to the user may be added to the user's identity and used to identify other relevant information about the user and his relationship with others. Similarly, each piece of additional information or token associated with other users may be used to augment their respective identities and provide information to the construction of a social graph that relates them to the users.

The manner in which such information is extracted may also vary widely depending on a number of factors. For example, operators of current network scenarios obviously have direct and consistent access to a data repository associated with the network. However, the nature of access to information on other networks may vary greatly depending on the relationship between the networks and/or the openness of the operators of the other networks. In some cases, a business relationship with an operator of another network may provide direct access to data of that network, or some more restricted level of access to that network, such as API level access. In other cases, such as where no relationship exists, it may be desirable to use techniques such as screen scraping, image recognition, and reverse optical character recognition. Combinations of these methods may also be used.

According to some embodiments, individuals having a relationship with a given user are prioritized, ranked or sorted with reference to the contact's relevance to the user (e.g., closeness or strength of relationship, type of relationship, or group to which the individuals belong). These may be determined with reference to a variety of information including, for example, recency, frequency, amount, and/or periodicity of communication between individuals, number of contacts in different networks or attributes, type of network connecting users, type of relationship (see below), and so forth.

Once the relationship is detected (and possibly classified and/or integrated), the relationship may also be confirmed. This may include an explicit invitation sent to the user and/or others in the relationship that requires confirmation of the relationship. In one example, this may take the form of a list of people with whom the user has a relationship (possibly sorted as described above), which is returned to the user to identify each person (see FIG. 3). According to some embodiments, knowledge about these relationships may be utilized without confirmation.

According to some embodiments, the Connections Activator utilizes a variety of information about the people and their interactions corresponding to the detected relationships to determine that they have a given type of relationship. Such information may include, for example, the nature and content of communications between people, their relationships to each other and other users on the network (e.g., MySpace, Facebook, LinkedIn), demographic information, and so forth. For example, detected relationships may be classified as family, friends, acquaintances, business partners, and so forth based on inferences from static data (e.g., contact information) as well as dynamic data (e.g., communication patterns).

According to various embodiments, the Connections Activator builds a model of the implicit community of relationships between humans by mining data about existing relationships of humans and communication patterns in other networks. This model is represented in some embodiments as a stacked ranking or grouping of humans that are relevant to a given user, which can then be used for a variety of purposes.

For example, knowledge about such relationships can be used to aggregate vitality. That is, by identifying relationships in other networks, and by determining that multiple identities correspond to the same person, embodiments of the invention can be used to aggregate the vitality generated by a particular individual over multiple networks. This is in contrast to the current transaction state, where the user must traverse all of the different networks in order to consume the vitality generated by the user's friends in the different networks.

According to particular embodiments, the aggregation of vitality is achieved by aggregating licensing models associated with various sources of vitality. That is, sources of vitality, such as social networks, use different models for enabling or limiting access to the content and information of their users. Some use a relatively open model in which all or most members have access to some or all of the content and information of other network members. Some use a more restrictive model in which one member may restrict access to a particular identified type of person, group, or relationship. When a user provides the Connections Activator with the necessary information for each network or system with which the user interacts, the Connections Activator is able to obtain access rights to, and content and information in, these networks and systems in accordance with the permission model associated with each. By subsequently identifying that a person with whom a user is in contact in one context is the same person as an identity in another context, the Connections Activator is able to aggregate the vitality of that person for the user, even though the permission models in different contexts may be fundamentally different. Thus, according to a specific embodiment, the present invention implements a Connections Activator that effectively provides a single access control to content and information in several different contexts, while preserving the licensing model of each.

According to some embodiments, information related to social connections and relationships may be used to weight other types of behaviors on the network. I.e. knowing who the user is related to and possibly also the nature and strength of the relation, a variety of functions can be implemented.

For example, such information may be used to sort, filter, or emphasize messages in the inbox, such as presenting emails or other communication types (e.g., voicemail, SMS, IM messages, etc.) in order from the person with whom the user communicates most to the person with whom the user communicates least. In another example, incoming messages may be prioritized to various levels based on the closeness and/or type of relationship, such that some messages are able to pass while others are not, or only messages above a specified priority level generate alerts or ring tones. In another example, email messages from high priority contacts may be presented to the user on a welcome page tab without having to obtain them from an email inbox.

In another example, such information may be referenced to filter or select content consumed by the user. For example, new feeds currently or recently consumed by other users with whom the user has a close and/or particular type of relationship may be selected in this manner.

In another example, the address book auto-complete functionality is enhanced to rank the returned contacts with reference to recency, frequency, and/or amount of communications and/or recency and/or type of social relationship. That is, for example, if the user has five contacts named "Joe," the first contact returned in response to entering "Joe" in the recipient field would be the one with which the user most frequently communicated, rather than the one that is alphabetically the first.

In another example, the user's social network may be used to make recommendations to the user regarding connections that the user may wish to initiate. For example, if a user is in another user's linkedIn network, the first user may wish to invite the second user to form a connection in a social network such as Facebook or MySpace, or to become such asSuch as contacts in a messaging system.

The order, priority, or ranking of contacts may also be represented or used in a variety of ways depending on the particular application. It may appear as a simple stacked ranking or linear list used by the back-end process. Alternatively, a variety of visual representations may be used to identify different groups to which various contacts belong, e.g., indicating the relative importance of the groups from the perspective of a particular user.

In thatAnother example of a use case in the initial context of (a) may be instructive. In this example, the user logs in and provides his email address. A ranked list of the user's contacts, as determined by the contents of the user's mailbox, is determined and returned. In the second phase, the user provides it successivelyLogin, its Twitter login, access to its Facebook account, access to its Flickr account. As each account is added, changes to the ranking of contacts in previous versions of the list are implemented based on a developing social graph that is user-centric and is informative by data accumulated from various networks.

An example of such a flow is shown in the screenshots of fig. 5-18. FIGS. 5-8 show screens in which the source user selectsAs a first data source and provides the corresponding login name and password to start the contact activation process. This results in the base as shown in FIG. 9A list of contacts ranked by data available in the network. Each contact entry having an indication of a source ofThe associated data of (2). These data may be embodied as links that provide access to the original data or the source from which they were derived. They may also initiate an action, such as opening a messaging interface to communicate with the contact. They may also serve as a representation of and link to the vitality produced by the associated contact.

The source user then selects Facebook as the additional data source (fig. 10), in response to which an updated contact list is presented as shown in fig. 11. In this case, the entries have been ranked in different ways taking into account new information derived from Facebook, and are augmented with data for each entry indicating that Facebook is the source. Similar updates occur with reference to Flickr (FIGS. 12 and 13), and then with reference to Twitter (FIGS. 14 and 15). In this way, the source user "claims" membership in various networks and/or communication channels, and the system links together these various identity tokens of the source user, thereby enabling aggregation and/or integration of contacts of the source user from various contexts, grouping and/or ranking of these contacts, and aggregation of vitality and other forms of communication.

Figures 16, 17 and 18 show the effect of the source user applying different levels of filtering to the contact list (i.e. from none to low to medium to high) which has the effect of reducing the number of days for contacts in the list. As described elsewhere herein, such filtering may be performed with reference to the relationship between the source user and each contact and/or the closeness or strength of the communication activity.

Contact activation may occur in various contexts according to various embodiments of the invention. An example is discussed above in which the user isIn the context of (1) initiates a connectionsactator. However, it should be understood that this is just one context in which contact activation may be useful. Other examples include a nearly instituteThere are messaging scenarios, e.g., email, voice messaging, instant messaging, SMS, etc. According to one particular embodiment, it may be determined for any given communication channel whether the user has utilized a Connections Activator to identify social relationships that may be used to enhance services in that channel. Additionally, since there is a high probability of significant overlap of relationships between different contexts, relationships identified in other communication channels and/or network contexts may be utilized to "activate" new channels or contexts. Thus, for example, if a user joins a new social networking site, a process of identifying people on the site that the user may wish to contact may be facilitated by the present invention to identify relationships from other contexts that may be established in the new context.

Further, the integrated identity of the people with which the user is associated may be utilized to "fill in holes" in the user's contact information or address book. For example, if the user's email address book only has email addresses for a particular contact, additional identity tokens from the contact's integrated identity (e.g., phone number, address, screen name, etc.) may be used to populate other fields in the address book entry.

According to various embodiments, a Connections Activator creates a connection graph of Connections between people, where weights and types connect to actions of a user in association with content objects that can be followed. This contact map may then be used as a filter in a variety of contexts, including, for example, vitality generation and consumption, messaging, content consumption, content forwarding, and so forth.

From a set of potential and apparent relationships, the Connections Activator creates an apparent relationship graph and iteratively refines and refines it over time to develop a model of who the user is, with whom the user is connected, how the user is related to the Connections, and the type of transaction associated with the relationships.

Embodiments of the present invention may be used to identify and utilize social relationships and related data in any of a variety of computing contexts. For example, as shown in FIG. 4, implementations are contemplated in which the relevant user population interacts with different network environments via any type of computer (e.g., desktop, laptop, tablet, etc.) 402, media computing platforms 403 (e.g., cable and satellite set-top boxes and digital video recorders), handheld computing devices (e.g., PDAs) 404, cellular telephones 406, or any other type of computing or communication platform.

Also, according to various embodiments, a variety of techniques may be utilized to collect user data processed according to the present invention. For example, the collection of data (e.g., number of page views) representing a user's interactions with a website or web-based application or service may be accomplished using any of a variety of well-known mechanisms for recording a user's online behavior. User data may be mined directly or indirectly, or inferred from a data set associated with any network or communication system on the internet. Also, despite these examples, it should be understood that this method of data collection is merely exemplary and that user data may be collected in a number of ways.

Once collected, the user data may be processed in a centralized manner. This is represented in fig. 4 by a server 408 and a data store 410, it being understood that the data store 410 can correspond to a plurality of distributed devices and data stores. The present invention may also be implemented in a variety of network environments including, for example, TCP/IP based networks, telecommunications networks, wireless networks, and the like. These networks, as well as the various social networking sites and communication systems from which contact data may be aggregated in accordance with the present invention, are represented by network 412.

Furthermore, the computer program instructions to implement embodiments of the present invention may be stored in any type of computer-readable medium and executed according to a variety of computing models, including a client/server model, a peer-to-peer model, on a stand-alone computing device, or according to a distributed computing model, wherein the various functions described herein may be implemented or used in different locations.

Will now be described inSome characteristics of the exemplary implementation in the context of a network. At least some of the features and functions described below may be understood with reference to fig. 5-18 and fig. 19 and 20 mentioned above. According to this implementation mode, the first and second switches are connected,data of users on the network is mined to provide relevant services, for example, to make recommendations about other users with whom the user may be interested in contacting, or to provide an easy way of populating the user's address book based on the user's aggregated contact list. This implementation makes use of user presenceA plurality of places andrich data owned outside the network.

As described above, the Connections Activator of this implementation is operable to de-duplicate data about a contact, i.e. the data is from different sources. Examples of unique identifiers indicating the same person are an email address, a cellular phone number, a home phone number, and a first + last name. Since the list of most users is relatively small, the risk of error is acceptable and can be easily corrected by the user.

In determining the ranking of each relationship, various aspects of each relationship may be given different weights. For example, a bi-directional relationship may be given a higher weight than a unidirectional relationship. Contacts with similar attributes (e.g., same last name, college name, etc.) may also have more weight. Furthermore, if the identity token (e.g., email id or cell phone number) in the user's address book belongs to a known user in the network, the data for the known user may be used to integrate other identifiers for the user.

The goal is to generate a list of contacts where it is possible to obtain the contacts directly (e.g., from the user's address book, a,Buddy lists, etc.), it is also possible to mine other sources to augment the contact list, such as the user's email store and other external sources. These aggregated data are normalized by giving higher weight to the rarer data. For example, if a person is using an address book, it will likely have all mobile number fields for all of their contacts, so the weight associated with the mobile number may be reduced for that user.

The weights may be defined on a global level, but in some cases it may be sensible to allow different emphasis for different groups of users to reflect their specific needs. For example, in some emerging markets, mobile phones are more popular than landline phones, and thus the weights of mobile phones in such markets may be de-emphasized. According to a specific embodiment, the weighted attributes are presented to the user on a slider control (or equivalent) along with default weights. The user may then move the slider and change the weights, and the contact list is refreshed with the new weights. When the user is finished, these weights may be saved as specific to that user.

Machine learning can be incorporated at either or both of the user level and the system level. For example, the system may be configured to learn based on the contacts the user accepts or rejects and the categories the user accepts, renames, or changes.

Each contact recommended may include summary information (e.g., aggregated from all sources) and controls for taking action on each contact (e.g., "Invite," "Reject," and "Later" buttons). The user may be enabled to accept ownership, reject ownership, and customize in between. The "Invite" button triggers the Invite flow. The "Reiect" button causes the contact not to be displayed as a recommendation in the future. The "latex" button allows the contact to be recommended again (assuming it meets the standard relevancy criteria).

This implementation of the Connections Activator may run periodically (with a configurable period), with refreshes coming fromInformation on and off site, and updates the relevance. Communication feeds (e.g., from all mail providers and Messenger logs) can be used to improve accuracy.

This implementation of the Connections Activator retrieves data from the set of internal and/or external networks and/or systems associated with or identified by the user when the user activates an import or a background periodic import. The Connections Activator then requests the authentication system for an appropriate set of third party credentials, which may or may not be persistently stored.

For source users, i.e., the user that initiated the import, which is identified from a Globally Unique Identifier (GUID),an internal contact list is imported and an authenticated third party contact list that the user approves importing is also imported. After import, some lists are provided to the user's address book if the user has selected this option.

A Global Contact List (Global Contact List) is an ordered List of contacts for a given source user identified via a GUID. The objects in the contact list are not necessarily GUID-based, and each entry includes a set of identifiers that are guessed and/or confirmed to be the same entity if multiple identifiers exist for the entry. The best guess is applied to the non-registered users to remove their duplicates from the information provided only in the source user's data, e.g., both imported entries have the same email address. The GUID database may be consulted to support duplicate removals (e.g., matching email addresses, cell phone numbers, first names, last names, etc.) by identifying relationships that may not be inferred from best guess analysis.

The import operation may be re-run to refresh the contact list. If at some point the source user decides not to select a particular network or system, then the reference to the integrated source may be removed from the global contact list at a later import.

As described above, a set of weights is associated with each contact, and the total weight for that contact is calculated. Each integration source has a positive or negative weight associated with it. High positive values indicate a strong relationship and negative values indicate a weak relationship. The total weight is calculated by summing all contributing weights for each entry. For entries from multiple integration sources, the weight is higher, but the contribution of each integration source to the weight may be different.

A suggested contact list based on the de-duplicated and ranked global contact list is returned to the user for activation. The suggested contact list may be derived, for example, by: entries that the source user has taken an action, such as entries already in the bi-directional contact set, previously invited but rejected or still pending, etc., are subtracted from the global contact list.

From the suggested contact list, the source user generates a list of possible presences or non-presencesA grid of a set of objects registered in a network. This may be accomplished, for example, by the source user marking a check box associated with each entry to indicate a desire to send an invitation to contact the relevant contact (e.g., an email including a link). A mechanism may also be provided by which the user may indicate a desire to ignore a suggested contact, in which case the entry will no longer appear in the list.

Another form of contact activation is a "grid" activation, in which a single user may activate a social connection for an interconnected set of contacts. The grid activation database stores the set of targets as well as the source user, which is only one of the contacts considered to be in the group. Each entry includes 3 fields, a grid group id, a user identifier (GUID or some other identity token, such as an email address), and an action status indicating "accepted", "rejected", or "pending". Another table associates a grid group id with a grid group creation time. When the grid is created, the source user defaults to an "accepted" state. All other contacts or users in the grid group are initially in a "pending" state.

When other users in the grid group accept the invitation, they are associated with each person in the group who has accepted and been placed in an "accepted" state. The accepting user is placed in the same state as a user who has accepted the invitation from all accepted people in the grid group and issues the invitation to the rest of the group. When users in the grid group decline the invitation, they are placed in a "declined" state. When all users in the grid are in the "accepted" or "rejected" state, the grid invitation is complete and the unaccepted entries may then be removed.

For contacts in the pending state, the invitation is resent when those contacts have been in the "pending" state for some configurable period of time (e.g., 15 days). If all users are in the "accepted" or "rejected" state or in the "pending" state for longer than another configurable period of time (e.g., 30 days), the grid invitation is considered complete. The unacceptable entries may then be removed.

As will be appreciated, a variety of user interface features may be used in conjunction with various embodiments of the present invention (see, e.g., the interfaces of fig. 1-3 and 5-18). According to the implementation described in the preceding paragraph, each proposed contact in the suggested contact list is represented by an image, a first name and a last name, as shown in fig. 19. A detailed view of each proposed contact may also be presented that includes other available information such as email address, phone number, category, network association, contact to contact, and so forth. An icon may also be presented to indicate whether the contact is already in a particular social network. This information is particularly relevant when the source user is inviting friends to register with a new social network.

Icons indicating the source of the data for a given contact may also be included, as well as mechanisms for adding or removing sources. For example, as shown in FIGS. 5-18, a drop down menu may be provided from which the user may select between a plurality of available sources. Alternatively, a page dedicated to adding or removing sources as shown in FIG. 20 may be presented. The source comprisesA network, and may includeSpecific attributes within the network, external sources (e.g., other networks, social networking sites, communication systems, etc.), and any address book or contact information that may be present on the user device or stored remotely. Each source may be presented with an associated logo and source name. A detailed view of each source may be presented that includes an input field that the source user can use to provide any necessary login name or password information so that the Connections Activator can gain access to the source of the additional data.

According to one embodiment, a control is associated with the contact list that allows the user to influence the number of contacts displayed. An example is shown in fig. 19, where a slider is provided that represents a range of affinities for the relationship, moving from "closest" to "all", which has the effect of filtering the number of contacts displayed based on a normalized weight scale. Initially, a default number of contacts (e.g., 50) are displayed, with the default value reflected in the position of the slider.

It should be noted that the source user can enter the Connections Activator flow from various points and contexts. For example, the source user may not beA member of a network. In this case, the Connections Activator will not be able to activate the user before the user registersThe database mines existing data about the user (e.g., identity tokens). Or, existingThe member may enter the flow for the first time or as a repeat user via a supplemental registration process. Furthermore, the source user may enter the flow from a variety of contexts. For example, the process may begin withIn (1). Alternatively, the process may be from the userAnd (5) page launching. Another alternative is to be able to select fromThe mobile service enters the flow. The flow may even be entered from an external network or system.

According to one embodiment, the contact activation procedure may even be initiated by the system itself. For example, if a pattern of communication is detected between a particular user and a fixed group, the user may be provided with the ability to use Connections activators to activate their contacts in a typical "hub and spoke" topology (the user is the hub and the spokes connect the user to their contacts). Alternatively, the user may create a grid group as described above. This grid group activation process provides an easy way for a user to communicate with this group of users, but will also send out an invitation to each member of the group to contact each of the other members of the group if they are not already in contact. By accepting members into the group, the user agrees to associate with each of the other members of the group.

According to various embodiments, the relevance of a connection may be based not only on its social nature (i.e., "who"), but also on various other characteristics, such as its spatial aspect (i.e., "where"), and temporal aspect (i.e., "when"), and/or its topical aspect (i.e., "what"). The relevance of these additional spatial, temporal and topical aspects may be determined by analyzing the similarities of these aspects between contacts and the patterns of these similarities within and between the various social, spatial, temporal and topical aspects. For example, embodiments are contemplated that are operable to group contacts in spatial and temporal proximity, i.e., contacts that are currently near the user's location. The spatial information may be readily determined with reference to, for example, location and/or proximity data associated with the mobile device, GPS system, or the like. Time information is also widely available in various systems that may be aggregated in accordance with the present invention. Topic information related to contacts may be obtained from a variety of sources including, but not limited to, the content of communications between contacts, and explicit profile data (e.g., declared interests) expressed on the contact's profile on one or more social networking services. Additionally, due to the dynamic nature of the various types of metadata associated with individuals and relationships, the relevancy algorithm used to group or rank contacts may recalculate relevancy measures periodically and/or in response to changes in the metadata. This may result in information that is more contextually relevant to the user.

One example of an implementation using this concept will now be described with reference to fig. 21-25. This example is referred to in the drawings asWhich is implemented in the context of a mobile device and is operable to aggregate not only vitality, but also various forms of direct communication, such as instant messaging, SMS, email, voice, etc., using contact information associated with each contact.

The screen of fig. 21 illustrates a flow by which contacts associated with a user's Facebook account may be aggregated with the user's login information for Facebook, as well as contacts from other networks and communication channels (screen 2102). Also, once the user's networks and/or channels are aggregated, a variety of different views of available information are presented according to various schemes. For example, conversations with the user's contacts in various communication channels may be presented, as shown in fig. 22 (a). In another example, the current status of the user's contacts in various networks may be presented, as shown in fig. 22 (B). The presented information may also be filtered with reference to a single contact. That is, vitality and/or events related to a single contact aggregated from some or all of the networks and/or communication channels may be presented in a single view by selecting that contact, as shown in fig. 22 (C). The user may also be enabled to modify their current state in some or all of the networks or communication channels associated therewith via the mechanism shown in FIG. 22 (D).

The screen of fig. 23 illustrates a flow by which a user may select his grouping for filtering and/or viewing his contacts. As shown in screen 2302, options may include user self-defined Groups, as well as "Smart Groups," which correspond to groupings the user infers from any of a variety of data available to the system. The user-defined groups may include Friends and Work groups, for example. Smart Groups, for example, may include a group of: the group includes all of the contacts of the user that the system identifies and aggregates, the contacts with which the user has recently communicated, the contacts that are currently online, the contacts that are nearby from a geographic perspective, and so on.

By selecting a near contact, the user can view the aggregated vitality from his contacts sorted by distance and/or within some programmable threshold distance, as shown in screen 2304. The user may also be presented with information about other people in the vicinity of the user, but these people may not have been identified as contacts of the user. Such individuals may be identified, for example, because they also use the oneConnect service.

Nearby contacts may then be viewed by the user in a number of ways, such as by ongoing conversation (2306) or current status in various networks (2308). According to some embodiments, a user may view their contacts and their vitality as a function of their most recent activity in any of the various networks and/or communication channels that have been aggregated, such as the "Pulse" view shown in screen 2310. The Pulse view may indicate the nature and/or content of the activity, as well as the context and time in which it occurred. In the example of screen 2310, the nature of the activity is a change in the status of the contact in Facebook.

Figure 24 shows some other examples of contacts presented in the Pulse view. The screen of fig. 24(a) includes events related to any contact of the user and is sorted by time. The screen of FIG. 24(B) includes events that are further filtered by geographic proximity to the user's current location. As shown, such events may include posting of content (e.g., photos in Flickr, social networking posts), taking actions (e.g., tagging photos, commenting on songs, installing applications), updating profiles (e.g., adding work titles or new contact information), and so forth. Almost all activities in any network or communication channel can be represented.

Also, because embodiments of the present invention aggregate the licensing models described above, implementations are contemplated whereby users may interact with the various networks with which they are members, as well as communicate via the various channels they use in a single interface. An example of this is illustrated by the flow in fig. 25, where a user is engaged in an online messaging session with contacts in one network and can make changes in the middle of the conversation by selecting another network.

Further, activities inferred from data associated with a particular network or communication channel may be presented. For example, because the location of the contact's mobile device may be known (if appropriate permission is granted), the contact's movement in the physical world may be represented (e.g., the contact travels from Hamburg to Barcelona).

While the present invention has been particularly shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that changes in form and details may be made to the disclosed embodiments without departing from the spirit or scope of the invention. For example, the context and data sources mentioned in the description of the various embodiments herein should not be considered as limiting the scope of the invention. Any context in which social relationships may be detected and used and any data source that may support the basic functionality described herein are within the scope of the present invention.

Furthermore, although various advantages, aspects, and objects of the present invention have been discussed herein with reference to various embodiments, it will be understood that the scope of the invention should not be limited by reference to such advantages, aspects, and objects. The scope of the invention should be determined with reference to the appended claims.

Claims (26)

1. A computer-implemented method, comprising:

determining an identity of a first user with reference to a first data source associated with a first network and under control of a first entity, the first network being controlled by the first entity, and with reference to at least one external data source outside the first network and not under control of the first entity, wherein the at least one external data source is in one or more other networks, wherein each external data source uses a permission model for controlling access to information associated with the external data source;

accessing information associated with each external data source in accordance with a respective permission model, thereby aggregating the permission models associated with the external data sources;

identifying a plurality of contacts having a relationship with the first user with reference to the first data source, the at least one external data source, and an identity of the first user, a first subset of the plurality of contacts not being identifiable from the first data source; and

aggregating vitality events from within the first network and the one or more other networks for a particular contact of the plurality of contacts.

2. The method of claim 1, wherein the vitality event indicates the nature and/or content of online activity of a particular contact of the plurality of contacts within the first network and the one or more other networks.

3. The method of claim 1, wherein the first user operates in the first network controlled by the first entity.

4. The method of claim 1, wherein the first user is a member of the first network and the one or more other networks.

5. The method of claim 1, wherein the first network and the one or more other networks are social networks.

6. The method of claim 1, wherein determining the identity of the first user comprises: identifying and aggregating a plurality of identity tokens from the first data source and the at least one external data source.

7. The method of claim 1, wherein each of the first data source and the at least one external data source corresponds to one of a social networking system, a messaging system, a content sharing system, or a member network.

8. The method of claim 1, wherein identifying the plurality of contacts comprises referencing one or more of: address book, contact list, message sender, message receiver, content publisher, subscription to content, or social networking data.

9. The method of claim 1 further comprising determining two or more of the plurality of contacts that correspond to a person and aggregating the two or more contacts into a single contact for the person.

10. A system, comprising:

means for determining an identity of the first user with reference to a first data source associated with a first network and under control of a first entity, the first network being controlled by the first entity, and with reference to at least one external data source outside the first network and not under control of the first entity, wherein the at least one external data source is in one or more other networks, wherein each external data source uses a permission model for controlling access to information associated with the external data source;

means for accessing information associated with each external data source in accordance with a respective permission model, thereby aggregating the permission models associated with the external data sources;

means for identifying a plurality of contacts having a relationship with the first user with reference to the first data source, the at least one external data source, and the identity of the first user, a first subset of the plurality of contacts being unidentifiable from the first data source; and

means for aggregating vitality events from within the first network and the one or more other networks for a particular contact of the plurality of contacts.

11. The system of claim 10, wherein the vitality event indicates the nature and/or content of online activity of a particular contact of the plurality of contacts within the first network and the one or more other networks.

12. The system of claim 10, wherein the first user operates in the first network controlled by the first entity.

13. The system of claim 10, the first user being a member of the first network and the one or more other networks.

14. A computer program product comprising at least one computer-readable medium having computer program instructions stored therein, the computer program product configured to cause at least one computing device to:

determining an identity of a first user with reference to a first data source associated with a first network and under control of a first entity, the first network being controlled by the first entity, and with reference to at least one external data source outside the first network and not under control of the first entity, wherein the at least one external data source is in one or more other networks, wherein each external data source uses a permission model for controlling access to information associated with the external data source;

accessing information associated with each external data source in accordance with a respective permission model, thereby aggregating the permission models associated with the external data sources;

identifying a plurality of contacts having a relationship with the first user with reference to the first data source, the at least one external data source, and an identity of the first user, a first subset of the plurality of contacts not being identifiable from the first data source; and

aggregating vitality events from within the first network and the one or more other networks for a particular contact of the plurality of contacts.

15. The computer program product of claim 14, wherein the vitality event indicates the nature and/or content of online activity of a particular contact of the plurality of contacts within the first network and the one or more other networks.

16. The computer program product of claim 14, wherein the first user operation is in the first network controlled by the first entity.

17. The computer program product of claim 14, wherein the first user is a member of the first network and the one or more other networks.

18. A computer-implemented method, comprising:

presenting to a first user a plurality of contacts having a relationship with the first user, the plurality of contacts determined with reference to a first data source associated with a first network and under control of a first entity, at least one external data source external to the first network and not under control of the first entity, the first network being controlled by the first entity, wherein each external data source uses a permission model for controlling access to information associated with the external data source, and an identity of the first user, the identity determined with reference to the first data source and the at least one external data source, a first subset of the plurality of contacts not identifiable from the first data source; and

presenting to the first user an aggregation of vitality events from within the first network and the one or more other networks aggregated for a particular contact of the plurality of contacts, the aggregation determined at least in part by accessing information associated with the at least one external data source according to a respective permission model, thereby aggregating permission models associated with the external data sources.

19. The method of claim 18, wherein the vitality event indicates the nature and/or content of online activity of a particular contact of the plurality of contacts within the first network and the one or more other networks.

20. The method of claim 18, wherein the first user operates in the first network controlled by the first entity.

21. The method of claim 18, wherein the first user is a member of the first network and the one or more other networks.

22. The method of claim 18, wherein each of the first data source and the at least one external data source corresponds to one of a social networking system, a messaging system, a content sharing system, or a member network.

23. The method of claim 18, wherein each of the vital events indicates a respective network and a time at which the vital event occurred.

24. The method of claim 18 wherein at least some of the vitality events include a textual update indicating a change in status of a respective one of the plurality of contacts.

25. The method of claim 18, wherein the vitality event comprises posting content, taking an action, updating a profile, or a combination thereof.

26. The method of claim 18, wherein the vitality events are filtered using geographic proximity to a location associated with the first user.