Social graph based co-location of network users

Description

TECHNICAL FIELD

The subject matter disclosed herein generally relates to provisioning network server resources for generating and distributing electronic messages. More specifically, the present disclosure describes systems and methods for grouping network users based on social graph data (e.g., a social graph is a graph that depicts the relations of network users) and profiling the groups in order to efficiently match the groups to the available network server resources.

BACKGROUND

Workload forecasting and capacity planning are fundamental in provisioning of web services and applications. It is common for workload parameters to be analyzed “after the fact”, for example, to compensate for workload levels already being experienced by a particular web server. As a result, such a workload analysis of a system does not provide any insight into the level or location of activity that a network system is likely to experience in the future. However, forecasting user activity patterns is crucial for efficiently deploying and organizing network server resources. Knowledge regarding the relationships between network users can also be used in devising ways to handle the activity patterns that a network system is likely to experience in the future.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which:

FIG. 1 is a block diagram showing a network system configured to transmit messages over a network consistent with some embodiments.

FIG. 2 is a block diagram illustrating an example of a network environment including a server operating a system for allocating network resources for processing and storing messages among users of client devices, consistent with some embodiments.

FIG. 3 is a block diagram showing some of the functional components or modules that make up the user grouping module, in accordance with an example embodiment.

FIG. 4 is a block diagram illustrating an example grouping of network users for co-location on servers providing network resources.

FIG. 5 is a flow diagram illustrating one example embodiment of an operation of the user grouping module.

FIG. 6 is a flow diagram illustrating one example embodiment of an operation of the group profiling module and the user co-location module.

FIG. 7 is a diagrammatic representation of machine, in the example form of a computer system, within which a set of instructions may be executed to cause the machine to perform one or more of the methodologies discussed herein.

FIG. 8 is a block diagram illustrating a mobile device, according to an example embodiment.

DETAILED DESCRIPTION

Although the present disclosure is described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

A network system (e.g., a messaging system) may provision network server resources, via geographic location and/or logical organization, in order to take advantage of social graph data of network users. The embodiments described herein provide systems and methods for analyzing the activities of network users to obtain social graph data, grouping the users based on the social graph data and provisioning network server resources based on matching server resources to groups of users. These embodiments will be described in relation to mobile wireless communication devices, hereafter referred to as client devices, for sending and receiving electronic messages such as text, images or video and associated servers for receiving and forwarding messages to and from the client devices. It will be appreciated by those skilled in the art, however, that this description is not intended to limit the scope of the described embodiments to the communication devices described below or to a specific form of electronic message. The methods and systems described herein may be applied to any appropriate communication or data processing device and to any appropriate electronic communication format.

Overview

Users of a network, individuals and organizations, may be analyzed as nodes on a social graph. Interdependencies between the users, called ties, can be based on many factors such as frequency of communications and the like. The information from such a social graph may be used for workload forecasting and network capacity planning.

FIG. 1 is a block diagram showing a network system 100 configured to transmit data over a network 105 (e.g., the Internet) consistent with some embodiments, in an embodiment, network servers 120A, 120B and 120C provides network resources for use by client devices. The client device may be a mobile device 115A or a more static device 130A (e.g., desktop computer) of a user 110A of network 105. The network activity of the users (e.g., 110A) may be monitored and used to generate social graph data associated with each of the users respectively. The social graph data may then be used to cluster the users into groups of tightly connected users, e.g., users with many ties among themselves. Once the groups are identified, data associated with each group is analyzed to obtain a profile for the group, This profile may then be used to match a group to a network server (e.g., 120B) for the most optimal provisioning of network resources.

As mentioned above, the first step is to obtain network activity data for a plurality of network users (110A, 110B, etc.) and generate social graph data associated with each user. It is noted that social graph information regarding network users may also be obtained in other ways, for example from other networks, from partners or via purchases. The social graph data is then used to cluster the users into groups based on, for example, a measure of connectivity between the users. The connectivity may be measured according to how strong the ties between each pair of users are with regard to a selected measurement, such as number of communications transmitted between the user pair. The users (110A, 110B, etc.) may then be clustered using a clustering algorithm which identifies groups of users that are likely to communicate with each other more often over a future period of time. Data associated with these groups of users is then analyzed to obtain group profiles that will be used to match the groups with available network server resources (e.g., 120A, 120B, 120C, etc.) for efficient provisioning.

In some embodiments, the particular connectivity measure used to perform the clustering may be selected to exploit the available social graph data. Depending on the subset of social graph data used, different clustering results can be obtained. For example, users (e.g., 110A, 110B, etc.) can be clustered according to the level of communication between them, the level of similarity of their navigation patterns (e.g., often visit many of the same websites), the level of similarity of their user profiles (e.g., a location of the user), the level of similarity of their user contacts, etc. Each of these clustering measures may result in different groupings of users and can be combined as needed to further cluster the network users. The particular measures used for the clustering may be selected based on which are most important for logically organizing network users into groups for provisioning network server resources in a particular implementation.

In an embodiment, the clustering is performed according to a communication level between pairs of users like 110A and 110B. For this purpose, the number of messages sent between their respective client devices (e.g., 115A and 115B) per a given time period (e.g., per hour, minute, etc.) may be used as the measure from the social graph data for clustering the network users into groups. The clustering may be performed using time series data values (e.g., a sequence of data points, typically consisting of successive measurements made over a time interval) for the selected measurement, or a function of these time series data values for the selected measurement. Once the measurements (e.g., communication level) of social graph data are used to perform the clustering, data associated with the resulting user groups may then be analyzed to obtain group profiles which may be compared to relevant data points used to locate and organize network server resources (e.g., 120A, 120B, 120C, etc.). For example, relevant data points for placing a server may be based on the server's capabilities (e.g., hardware and/or software) and a user group profile that includes values/data with respect to these relevant data points for all of the users associated with the user group may be compared to the server's capabilities to determine if the server should be assigned to the users associated with the group profile. In other words, only servers having sufficient capabilities are assigned to the users associated with this group profile.

In an embodiment, profiling of a user group involves first determining the relevant data points, from the social graph data, upon which the user group profiles will be based. In some embodiments, a location of a user (e.g., 110A), an activity level of a user or a server asset often utilized by a user may be used as the relevant data points to generate the user group profiles for the identified groups of users. In generating the profile for a group, different types of analyses may be performed on the social graph data of the users of a group. Generating a group profile for a group of users may be based on identifying values/data for each of the users, where the values/data are related to any of the relevant data points being used to locate and organize network server resources (e.g., server 120A, 120B, 120C . . . ). For example, user network activity may be monitored to identify values/data that are the most similar to the set of social graph values/data for the users of the group (e.g., the mode), where the values/data of the set are related to any of the relevant data points.

In an embodiment, the profile for a group is generated by simply averaging the values with respect to relevant data points for all the users of a user group. However since an outlying (e.g., with respect to the averaged data points) user (e.g., 110A) of the group may have an associated value for the averaged data point that is far from the group average, the clustering of groups described above may be performed so that it minimizes the maximum difference of values associated with all of the users in a group with respect to the average value of the relevant data points for provisioning network server resources. Furthermore, different profiles may be generated for different recurring time periods, such as day of the week, week of the month, month of the year, etc.

In an embodiment, the profile of each user group may be compared to corresponding data associated with the plurality of servers (e.g., 120A, 120B, 120C, etc.) for the purpose of assigning each user group to at least one of the plurality of servers based on the comparison. For example, if the users (e.g., 110A, 110B, etc.) of a group are located within a specified geographic area then the group might be assigned to access network resources via a server that is closest to the said geographic area. In other examples, the user groups may be assigned to servers based on matching the group to a server based on other relevant data points.

In embodiments, the comparison of user group profiles to corresponding server data includes at least one of: comparing a geographic location associated with the users of a group to a geographic location of a server, of application server(s) 218, as noted above; comparing an activity level (e.g., average number of send/receive actions) associated with the users of a group to a capacity of a server so that the server is able to provision network services to the group without overloading; or comparing a server asset utilized by users of a group to assets available at a server so that user requested assets are available at the server to which a user group is assigned.

System Architecture

FIG. 2 is a network diagram depicting a network system 200 having a client-server architecture configured for exchanging data over a network, according to one embodiment. For example, the network system 200 may be a messaging system where clients may communicate and exchange data within the network system 200. The data may pertain to various functions (e.g., sending and receiving text, photo and video communications) and aspects (e.g., publication of blogs and websites) associated with the network system 200 and its users. Although illustrated herein as client-server architecture, other embodiments may include other network architectures, such as peer-to-peer or distributed network environments.

A data exchange platform 202, in an example, includes a user grouping module 220 and a user co-location module 222, and may provide server-side functionality via a network 204 (e.g., the Internet) to one or more client devices. Although described as residing on a server (e.g., application server(s) 218) in some embodiments, in other embodiments some or all of the functions of user grouping module 220 and a user co-location module 222 may be provided by a client device. The one or more clients may include users (e.g., 110A and 110B) that use the network system 200 to exchange data over the network 204. These operations may include transmitting, receiving (communicating), and processing data to, from, and regarding content and users of the network system 200. The data may include, but is not limited to, content and user data such as user profiles, messaging content, messaging attributes, client device information, and geolocation information, among others.

In various embodiments, the data exchanges within the network system 200 may be dependent upon user-selected functions available through one or more client or user interfaces (UIs). The UIs may be associated with a client machine, such as client devices 210, 212 using a programmatic client 206, such as a client application. The programmatic client 206 may be in communication with the user grouping module 220 and a user co-location module 222 at least one of application server(s) 218. The client devices 210, 212 may comprise mobile devices with wireless communication components and applications for sending specific types of electronic messages over network 204 (e.g., messaging application 207).

Turning specifically to the user grouping module 220 and a user co-location module 222, an application program interface (API) server 214 is coupled to, and provides programmatic interface to one or more application server(s) 218 that host the user grouping module 220 and a user co-location module 222. The application server(s) 218 are, in turn, shown to be coupled to one or more database(s) 224, 226 and 228 for storing and/or accessing network data.

The API server 214 communicates and receives data pertaining to messages, among other things, via various user input tools. For example, the API server 214 may send and receive data to and from an application (e.g., via the programmatic client 206) running on another client machine (e.g., client devices 210, 212 or a third party server).

In one example embodiment, the user grouping module 220 provides monitoring mechanisms for users of the client devices 210 and 212 in order to obtain user activity data. The application server(s) 218 can access and view the user activity data from, for example, the activity and behavior database 228.

Application server(s) 218 provide network resources for use by client devices, such as client devices 210 and 212. Each of the client devices 210 and 212 may be a mobile device (e.g., like 115A) or a more static device (e.g., like 130A) of a user (e.g., like 110A) of network 204. The network activity of the users (e.g., 110A) may be monitored via the user grouping module 220 and used to generate social graph data associated with each of the users of the client devices 210 and 212 respectively. The social graph data may then be stored in social graph database 226 and accessed for use in clustering the users of data exchange platform 202 into groups of tightly connected users, e.g., users with many social ties among themselves. Once the groups are identified, data associated with each group is analyzed to obtain a profile for the group. This profile may then be used to match a group to a network server, from application server(s) 218, for the improved provisioning of network resources.

The activities of client devices 210 and 212 may be monitored, for example, via a messaging application 207 residing on each of the devices. The activities of client devices 210 and 212 may also be monitored via application server(s) 218 which may record any user interaction with the application server(s) 218. The network activity data for a plurality of network users (e.g., 110A, 110B, etc.), which may be stored in activity and behavior database 228, is used to generate social graph data associated with each user of a client device such as client device 210. It is noted that social graph information regarding network users may also be obtained in other ways, for example from other networks, from partners or via purchase. It is also noted that user profile data stored in profile database 224 (e.g., names, addresses, phone numbers, affiliations, etc.) may also be used to generate the social graph data.

The social graph data, which may be stored in social graph database 226, is then used by user grouping module 220 to cluster the users into groups based on, for example, a measure of connectivity between the users. The connectivity may be measured according to how strong the ties between each pair of users are with regard to a selected measurement, such as number of communications transmitted between the user pair. It is noted that user profile data stored in profile database 224 may also be used to aid in clustering the users into logical user groups. The users (e.g., 110A, 110B, etc.) may then be clustered using a clustering algorithm which identifies groups of users that are, for example, likely to communicate with each other more often over a future period of time. Data associated with these groups of users is then analyzed to obtain user group profiles that will be used to match the user groups with available network server resources, such as application server(s) 218, for efficient provisioning of network resources.

The particular connectivity measure used to perform the clustering may be selected to exploit the available social graph data. Depending on the subset of social graph data used, different clustering results can be obtained. For example, users (e.g., 110A, 110B, etc.) can be clustered according to: the level of communication between them (so that users that often message each other might be grouped); the level of similarity of their navigation patterns (so that users that often visit the same websites might be grouped (e.g., from social graph database 226)); the level of similarity of their user profiles (so that users that list similar addresses or jobs on their profiles might be grouped (e.g., from profile database 224)); the level of similarity of their user contacts (so that users with substantially overlapping sets of contacts might be grouped), etc. Each of these clustering measures will result in different groupings of users and can be combined as needed to further cluster the network users. The particular measures used for the clustering may be selected, for example, based on which are most important (e.g., activity level) for logically organizing network users into groups for the provisioning of network server resources in a particular implementation.

The clustering of users into user groups may be performed according to a measure of the level of communication between pairs of users like 110A and 1101. For this purpose, the number of messages sent between their respective client devices (e.g., 210 and 212) per hour may be used as the measure from the social graph data for clustering the network users into groups. The clustering may be performed using the time series data values for the selected measurement (e.g. a number of messages sent between a user pair), or a function of these time series data values for the selected measurement (e.g., derivatives of the values). Once the measurements (e.g., inter-user communication level) of social graph data are used to perform the clustering, the resulting user groups are analyzed to obtain group profiles with regard to relevant data points (e.g., geographic location) used to locate and organize network server resources such as application server(s) 218.

The profiling of a user group, via the user grouping module 220, involves first determining the relevant data points (e.g., user location, user job, user network communication levels, user website navigation patterns, user server asset utilization, etc., from the social graph data, upon which the user group profiles will be based. It is noted that user profile data, stored in profile database 224, for the users of a user group may also be used to generate the user group profile. The relevant data points may be selected based on their respective importance in determining how to deploy and apportion network server resources such as application server(s) 218. In some embodiments, a location of a user (e.g., 110A), an activity level of a user and/or a server asset often utilized by a user may be used as the relevant data points to generate the user group profiles for the identified groups of users. In generating the profile for a group, different types of analyses may be performed on the social graph data (e.g., in social graph database 226) associated with the users of a group. Generating a group profile for a group of users may be based on identifying values/data for each of the users, where the values/data are related to any of the relevant data points being used to locate and organize network server resources (e.g., application server(s) 218). For example, user network activity may be monitored to identify values/data that are the most similar to the set of social graph values/data for the users of the group (e.g., the mode), where the values/data of the set are related to any of the relevant data points.

The profile for a group may also be generated by simply averaging the values with respect to the relevant data points for all the users (e.g., 110A and 110B) of a user group. However since an outlying (e.g., with respect to the averaged data points) user (e.g., 110A) of the group may have an associated value for an averaged data point that is far from the group average, the clustering of groups described above may be performed so that it minimizes the maximum difference of values associated with all of the users in a group with respect to the average value of the relevant data points for provisioning network server resources. Furthermore, different user group profiles may be generated for different recurring time periods, such as day of the week, week of the month, month of the year, etc.

The profile of each user group may then be compared, by the user co-location module 222, to corresponding data associated with the application server(s) 218 for the purpose of assigning (for the provision of network resources) each user group to at least one of the application server(s) 218 based on the comparison. For example, if the users (e.g., 110A and 110B) of a group are located within a specified geographic area, then the group might be assigned to access network resources via a server, of application server(s) 218, that is closest to the said specified geographic area. In other examples, the user groups may be assigned to servers, of application server(s) 218, based on matching the user group to a server based on other relevant data points.

The comparison of user group profiles to corresponding server data, of application server(s) 218, includes at least one of: comparing a geographic location associated with the users (e.g., 110A and 110B) of a group to a geographic location of a server as noted above; comparing an activity level (e.g., average send/receive) associated with the users of a group to a capacity of a server so that the server is able to provision network services to the group without overloading; or comparing a server asset utilized by users of a group to assets available at a server so that user requested assets are certain to be available at the server to which a user group is assigned for requesting network resources.

User Grouping and Profiling

FIG. 3 is a block diagram 300 showing some of the functional components or modules that make up the user grouping module 220, in accordance with an example embodiment. As shown in FIG. 3, the social graph database 226 is accessed by the user grouping module 220 so as to cluster the users into groups based on, for example, a measure of connectivity between the users. The grouping engine 302 of user grouping module 220 may be programmed via a configuration file 304 to measure user connectivity according to how strong the social graph ties between each pair of users (e.g., 110A and 110B) are with regard to a specified measurement, such as number of communications transmitted between the user pair. It is noted that user profile data stored in profile database 224 may also be used to aid grouping engine 302 in clustering the users into logical user groups. The users may then be clustered by grouping engine 302 using a clustering algorithm which identifies groups of users that are, for example, likely to communicate with each other more often over a future period of time. Data associated with these groups of users (e.g., in databases 224, 226 or 228) is then analyzed by group profiling module 306 to obtain user group profiles (which may be stored in profile database 224) that will be used to match the user groups with available network server resources, such as application server(s) 218, for efficient provisioning of network resources.

The particular connectivity measure used to perform the clustering by grouping engine 302 may be specified via configuration file 304 so as to exploit the available social graph data and so as to facilitate provisioning of network server resources such as application server(s) 218. Depending on the subset of social graph data used, different clustering results can be obtained. For example, users (e.g., 110A and 110B) can be clustered according to the level of communication between them as noted above, the level of similarity of their navigation patterns (e.g., from social graph database 226), the level of similarity of their user profiles (e.g., from profile database 224), the level of similarity of their user contacts, or according to other such measures. Each of these clustering measures will result in different groupings of users and can be combined as needed to further cluster the network users.

The clustering of users into user groups may be performed by grouping engine 302 according to a measure of the level of communication between pairs of users like 110A and 110B. For this purpose, the number of messages sent between their respective client devices (e.g., 210 and 212) per hour may be used (e.g., as recorded via messaging application 207) for the measure from the social graph data for clustering the network users into groups. Once the measurements (e.g., inter-user communication level) of social graph data are used to perform the clustering by grouping engine 302, data associated with the resulting user groups is analyzed by group profiling module 306 to obtain group profiles with regard to relevant data points (e.g., geographic location) used to locate and organize network server resources such as application server(s) 218.

The profiling of a user group, via the group profiling module 306, involves first determining the relevant data points, from the social graph data, upon which the user group profiles will be based, This information may be specified via the configuration file 304. It is noted that user profile data in profile database 224 may also be used by the group profiling module 306 to generate the user group profile. The relevant data points may be specified based on their respective importance in determining how to deploy and apportion network server resources such as application server(s) 218. In some embodiments, a location of a user (e.g., 110A), an activity level of a user and/or a server asset often utilized by a user may be used as the relevant data points to generate the user group profiles for the identified groups of users. In generating the profile for a group, different types of analyses may be performed, by grouping module 306, on the social graph data (e.g., in social graph database 226) associated with the users of a group. Generating a group profile for a group of users may be based on identifying values/data for each of the users, where the values/data are related to any of the relevant data points being used to locate and organize network server resources (e.g., application server(s) 218). For example, user network activity may be monitored to identify values/data that are the most similar to the set of social graph values/data for the users of the group (e.g., the mode), where the values/data of the set are related to any of the relevant data points.

In another example, the profile for a group may be generated by group profiling module 302 by simply averaging the values with respect to the relevant data points for all the users (e.g., 110A and 110B) of a user group. However since an outlying (e.g., with respect to the averaged data points) user (e.g., 110A) of the group may have an associated value for an averaged data point that is far from the group average, the clustering of groups described above may be performed by group profiling module 302 so that it minimizes the maximum difference of values associated with all of the users in a group with respect to the average value of the relevant data points for provisioning network server resources. Furthermore, different user group profiles may be generated by group profiling module 302 for different recurring time periods, such as day of the week, week of the month, month of the year, or other such recurring time periods.

As illustrated in the example of FIG. 3, the group profiling module 306 includes a data point retrieval module 308 and a data point derivation module 310. The data point retrieval module 308 of the group profiling module 306 may retrieve various user social graph (or user profile) data points from social graph database 226 (or profile database 224), such that these retrieved data points may be used to determine the similarity of any two users of data exchange platform 202 with respect to relevant data points for provisioning network server resources such as application server(s) 218 (e.g., geographic location). These social graph (or user profile) data points retrieved from social graph database 26 and/or profile database 224 may then also be used by the data point derivation module 310 to derive further profile data points. For example, the data point derivation module 310 may derive certain group profile data points (e.g., location) based on the data extracted by the data point retrieval module 308 (e.g., telephone number).

In addition to retrieving and/or deriving various user group profile data points, the group profiling module 306 may include logic to normalize or standardize certain user group profile data points. For instance, in some examples, a group profile will include data regarding a common job held by a group of users in the form of a profile “job title” data point. However, because job titles may vary from one company to the next and from one industry to the next, job titles may need to be normalized or standardized. For example, the simple job title, “analyst” may have very different meanings in different industries. By normalizing and/or standardizing the job titles and then providing the standardized and/or normalized job title for the user group profile, the user co-location module may make meaningful comparisons to corresponding server data (e.g., does a server provide resources accessed by users with the job title), and thereby provide network server resources such as application server(s) 218 according to the comparison.

User Co-Location

FIG. 4 is a block diagram 400 illustrating an example grouping of network users, according to group profiles 402, for co-location on servers (e.g., application server(s) 218) providing network resources. The profiles (402A-402D) of each user group is compared, by the user co-location module 222, to corresponding data associated with the application server(s) 218 for the purpose of assigning (for the provision of network resources) each user group to at least one of the application server(s) 218 based on the comparison. For example, if a group profile 402A indicates that the users of a group are located within a specified geographic area at field 404, then the group might be assigned by the user co-location module 222 to access network resources via a server of application server(s) 218 that is closest to the said specified geographic area. If a group profile 402B indicates that a group of users has already been assigned to one of the application server(s) 218 at field 410, then the group will be ignored by the user co-location module 222 when determining the allocation and provisioning of network server resources. In other example embodiments, the user groups may be assigned by co-location module 222, to servers of application server(s) 218, based on matching the user group to a server based on other relevant data points.

The comparison of user group profiles to corresponding server data, of application server(s) 218, may include one of: comparing a geographic location associated with the users (e.g., 110A and 110B) of a group (e.g., field 404) to a geographic location of a server as noted above; comparing an activity level (e.g., field 406) associated with the users of a group to a capacity of a server so that the server is able to provision network services to the group without overloading; or comparing a server asset utilized by users of a group (e.g., field 408) to assets available at a server so that user requested assets are certain to be available at the server to which a user group is assigned for requesting network resources.

Methods

FIG. 5 is a flow diagram 500 illustrating one example embodiment of an operation of the user grouping module 220. At operation 502, the network activity of a plurality of network users is monitored. The user activities may be monitored, for example, via a messaging application (e.g., messaging application 207) residing on client devices of the users. The user activities may also be monitored via network servers (e.g., application server(s) 218) which may record any user interaction with the network servers. The network activity data for the plurality of network users may be stored in user activity database (e.g., activity and behavior database 228). At operation 504, the monitored user activity is used to generate social graph data for each network user. The user social graph data may include data regarding interdependencies between the users that are based on many factors such as frequency of communications.

At operation 506, a connectivity measure is calculated for each pair of users based on the generated social graph data. The particular connectivity measure may be selected to exploit the available social graph data. For example, the social graph data of a pair of network users (e.g., 110A, 110B, etc.) can be examined in regard to a measure of the level of communication between the pair of users, the level of similarity of the pair's navigation patterns, or the level of similarity of the pair's user contacts, etc. Each of these measures will result in different groupings of users and can be combined as needed to further group the network users. Finally at operation 508, the network users are clustered into groups based on the connectivity measures for calculated for each pair of users. If the clustering is performed according to a communication level between pairs of users like 110A and 110B, the number of messages sent between them per hour may be used as the measure from the social graph data for clustering the network users into groups. Once the measurements (e.g., communication level) of social graph data are used to perform the clustering, data associated with the resulting user groups may then be analyzed to obtain group profiles as explained below with respect to FIG. 6.

FIG. 6 is a flow diagram 600 illustrating one example embodiment of an operation of the group profiling module 306 and the user co-location module 222. At operation 602, data associated with the user groups may be analyzed with respect to a set of relevant data points. In some embodiments, a location of a user (e.g., 110A), an activity level of a user or a server asset often utilized by a user may be analyzed as the relevant data points that will then be used to generate the user profiles for the identified groups of users. Different types of analyses may be performed on the social graph data (or user profile data) associated with the users of a group. For example, in certain embodiments, an average of certain values (e.g., a number of messages sent) may be calculated. At operation 604, a group profile for each of the groups may be generated based on the analysis of the user groups. For example, a group profile for a group may be based on identifying values/data with respect to each of the relevant data points, wherein the identified values/data are the most similar to the associated values/data with respect to each of the relevant data points for all of the members of the group.

At operation 606, each group profile may be compared to corresponding data associated with the plurality of servers, such as application server(s) 218. For example, if the data associated with the users of a group indicates that the users are located within a specified geographic area then the group might be assigned to access network resources via a server of application server(s) 218 that is closest to that geographic area. In other examples, the user groups may be assigned to servers based on matching the group to a server based on other relevant data points. Finally at operation 608, each user group may be assigned to at least one of the application server(s) 218 based on the comparison. For example, a user group may be assigned to a server based on comparing a geographic location associated with the users of a group to a geographic location of a server as noted above; comparing an activity level (e.g., average send/receive) associated with the users of a group to a capacity of a server so that the server is able to provision network services to the group without overloading; or comparing a server asset utilized by users of a group to assets available at a server so that user requested assets are available at the server to which a user group is assigned.

Modules, Components and Logic

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

In various embodiments, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically, constructed, permanently configured (e.g., hardwired), or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respectively different hardware-implemented modules at different times. Software may, accordingly, configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time.

Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules may be regarded as being communicatively coupled. Where multiples of such hardware-implemented modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses that connect the hardware-implemented modules). In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules may also initiate communications with input or output devices, and can operate on a resource.

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via the network 104 (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

Electronic Apparatus and System

Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations of them. Example embodiments may be implemented using a computer program product (e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers).

A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry (e.g., an FPGA or an ASIC).

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures merit consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed in various example embodiments.

Example Computer System

FIG. 7 shows a diagrammatic representation of a machine in the example form of a machine or computer system 700 within which a set of instructions 724 may be executed causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions 724 (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions 724 to perform any one or more of the methodologies discussed herein.

The example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 704, and a static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 700 also includes an alphanumeric input device 712 (e.g., a keyboard), a UI navigation device 714 (e.g., a mouse), a drive unit 716, a signal generation device 718 (e.g., a speaker), and a network interface device 720.

The drive unit 716 includes a computer-readable medium 722 on which is stored one or more sets of data structures and instructions 724 (e.g., software) embodying or used by any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704 or within the processor 702 during execution thereof by the computer system 700, with the main memory 704 and the processor 702 also constituting machine-readable photo.

The instructions 724 may further be transmitted or received over a network 726 via the network interface device 720 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).

While the computer-readable medium 722 is shown in an example embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple photo (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions 724. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions 724 for execution by the machine that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures used by or associated with such a set of instructions 724. The term “computer-readable medium” shall, accordingly, be taken to include, but not be limited to, solid-state memories, optical photo, and magnetic photo.

Furthermore, the machine-readable medium is non-transitory in that it does not embody a propagating signal. However, labeling the tangible machine-readable medium “non-transitory” should not be construed to mean that the medium is incapable of movement—the medium should be considered as being transportable from one physical location to another. Additionally, since the machine-readable medium is tangible, the medium may be considered to be a machine-readable device.

Example Mobile Device

FIG. 8 is a block diagram illustrating a mobile device 800, according to an example embodiment. The mobile device 800 may include a processor 802. The processor 802 may be any of a variety of different types of commercially available processors 802 suitable for mobile devices 800 (for example, an XScale architecture microprocessor, a microprocessor without interlocked pipeline stages (MIPS) architecture processor, or another type of processor 802). A memory 804, such as a random access memory (RAM), a flash memory, or another type of memory, is typically accessible to the processor 802. The memory 804 may be adapted to store an operating system (OS) 806, as well as applications 808, such as a mobile location enabled application that may provide location-based services (LBSs) to a user. The processor 802 may be coupled, either directly or via appropriate hardware, to a display 810 and to one or more input/output (I/O) devices 812, such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor 802 may be coupled to a transceiver 814 that interfaces with an antenna 816. The transceiver 814 may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna 816, depending on the nature of the mobile device 800. Further, in some configurations, a GPS receiver 818 may also make use of the antenna 816 to receive GPS signals.

Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present invention. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present invention as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.