Contextual presence system and associated methods

RELATED APPLICATIONS

This application claims priority to U.S. Patent Application Ser. No. 61/405,967 titled “Contextual Presence System and Associated Methods”, filed Oct. 22, 2010, and incorporated herein by reference.

BACKGROUND

A presence system collects real-time presence information about an individual, applies one or more rules that deduce a status of that individual from that information, and then publishes that information to one or more acquaintances of that individual (known as watchers). Although the presence information is typically ascribed to an individual, the presence information is typically received from devices associated with that individual. For example, a computer associated with (and used by) the individual may send a message to the presence system indicating that it is being used by the individual. The presence system thereby implies that the individual is proximate to that computer when the computer indicates it has user interaction.

Presence systems can be based on an Instant Messaging like paradigm where there is typically a single context (for example, logged in or online with a device) and the people who can see each other's presence in that single context are previously known to each other as part of their buddy list system.

Presence systems can also be based on gaming/chat rooms where there is a fixed set of contexts (e.g., a game room or a chat room) and people that join those contexts can see each other. These contexts typically stay for a long period and people can remain anonymous.

Typically, a presence server written for one of the paradigms above cannot be used practically for the other.

<figref idref="DRAWINGS">FIG. 1</figref> shows one prior art presence system <b>100</b>. A presence server <b>102</b> of system <b>100</b> receives presence information <b>122</b> relating to an individual <b>110</b> from at least one source, such as a device <b>104</b> used by individual <b>110</b>. Individual <b>110</b> subscribes to services of presence server <b>102</b> and provides rules as to how presence information <b>122</b> is handled and published by presence server <b>102</b>. In <figref idref="DRAWINGS">FIG. 1</figref>, acquaintances <b>112</b> and <b>114</b> of individual <b>110</b> also subscribe to presence server <b>102</b> and are authorized by individual <b>110</b> to receive published presence information <b>124</b> associated with individual <b>110</b> (and based upon presence information <b>122</b>). Specifically, acquaintance <b>112</b> utilizes a watcher device <b>106</b>(<b>1</b>) to receive presence information <b>124</b>(A) from presence server <b>102</b>, and acquaintance <b>114</b> utilizes a watcher device <b>106</b>(<b>2</b>) to receive presence information <b>124</b>(B) from presence server <b>102</b>. Devices <b>104</b> and <b>106</b> may represent a device selected from the group including: mobile phones, personal digital assistants (PDAs), smart phones, and personal computers.

In operation, device <b>104</b> allows individual <b>110</b> to send presence information <b>122</b> (such as a current location, and an activity such as working) to presence server <b>102</b>, which in turn publishes (i.e., sends) presence information <b>124</b> to acquaintances <b>112</b> and <b>114</b>, thereby informing them of changes in the status of individual <b>110</b>. Specifically, devices <b>106</b>(<b>1</b>) and <b>106</b>(<b>2</b>) do not request status information <b>124</b>(A) and <b>124</b>(B), respectively, from presence server <b>102</b>, but are notified directly upon changes to the stored presence of individual <b>110</b>.

Where device <b>104</b> represents a mobile phone, an associated service provider (or the phone itself if it includes GPS functionality) may determine a location of device <b>104</b> automatically and send this location as presence information <b>122</b> to presence server <b>102</b>. Thus, published presence information <b>124</b> may include location information of device <b>104</b>, which is also assumed to be the location of individual <b>110</b>.

Presence server <b>102</b> may represent similar social networking services, such as Facebook™, where individual <b>110</b> describes current activities and feelings for publication to a network of authorized ‘friends’. Presence server <b>102</b> may also represent more than one presence server and social networking server that interact to receive and publish presence information.

In conventional presence systems, such as shown in <figref idref="DRAWINGS">FIG. 1</figref>, when presence status of an individual changes, presence information is published only to authorized subscribers (i.e., acquaintances of the individual) of that information. Scalability of conventional presence is poor: the more subscribers to an individual's presence information, the more work is required to publish that information. Presence information of an individual cannot be received without subscribing to that information through the presence server, and being authorized by the individual to receive that information. Presence information is not available to a third party unknown to the individual.

Further, since there are many difference presence systems, certain acquaintances of the individual may subscribe to a different presence system that the one subscribed to by the individual. Often, to overcome this limitation, the individual would subscribe to more than one presence system such that acquaintances would be allowed to receive published presence information from the individual.

SUMMARY OF THE INVENTION

In an embodiment, a contextual presence system (CPS) dynamically forms a context group having a plurality of members and propagates payload data between the members. The system includes a database for associating a context identifier (ID) of the context group with a user ID of each said member, a context manager, communicatively coupled with the database, and a payload handler for receiving payload data from one of said members and for propagating the payload data to other said members of the context group. The context manager receives a join context request containing the context ID and a user ID from each said member, creates the context group, if not existing, within the database in response to the join request, and adds the user ID, if not existing, of each said member to the database in association with the context ID.

In another embodiment, a computer implemented method dynamically forms a context group. A first join context request is received from a first user device running an application and includes (a) a context ID defined by the application and (b) a first user ID of the first user device. The context group is created within a database based upon the context ID and the first user ID directly upon receiving the first join context request.

BRIEF DESCRIPTION OF THE FIGURES

<figref idref="DRAWINGS">FIG. 1</figref> shows a presence system of the prior art.

<figref idref="DRAWINGS">FIG. 2</figref> shows one exemplary contextual presence system for providing ad hoc on-the-fly contextual presence, in an embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating one exemplary method for interacting with the contextual presence server (CPS) of <figref idref="DRAWINGS">FIG. 2</figref> from an application running on a user device, in an embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating one exemplary method for creating and managing a context group, in an embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating one exemplary method for handling payload, in an embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> shows the payload handler of <figref idref="DRAWINGS">FIG. 2</figref> with a plurality of edge nodes, in an embodiment.

<figref idref="DRAWINGS">FIG. 7</figref> shows the CPS of <figref idref="DRAWINGS">FIG. 2</figref> connected to two application servers, each having a plurality of clients, in an embodiment.

DETAILED DESCRIPTION OF THE DRAWINGS

Unlike prior art presence systems that publish presence information to registered watchers of that information, a contextual presence system transports payload data between members of a context group, where that context group may be created in real-time as needed. Scalability of the contextual presence system is superior in that payload data is not collected and propagated to a list of specific watchers, as occurs in the prior art.

<figref idref="DRAWINGS">FIG. 2</figref> shows one exemplary contextual presence system <b>200</b> for providing ad-hoc, on-the-fly, contextual presence. System <b>200</b> includes a contextual presence server (CPS) <b>202</b> that interacts with at least one user device <b>204</b>. CPS <b>202</b> includes a database <b>244</b>, a context manager <b>240</b> communicatively coupled with database <b>244</b> for managing context groups within database <b>244</b>, and a payload handler <b>242</b> for propagating application payload <b>230</b>, received from a member of a particular context group, to other members of that context group. Context manager <b>240</b>, payload handler <b>242</b>, and database <b>244</b> are for example software applications that are executed by a processor of CPS <b>202</b>. A context group member is for example a user of an application <b>206</b> running on a computing device of the user, for example.

Continuing with the example of <figref idref="DRAWINGS">FIG. 2</figref>, CPS <b>202</b> is shown interacting with user devices <b>204</b>(<b>1</b>) and <b>204</b>(<b>2</b>). User devices <b>204</b> may represent any device or devices capable of communicating within system <b>200</b>, such as one or more of: a smart phone, a tablet computer, a laptop computer, and a desktop computer. That is, user device <b>204</b> includes a memory for storing data and machine readable instruction and a processor for executing these instructions and processing the data. Each user device <b>204</b> includes an application <b>206</b> that is for example downloaded into user device <b>204</b> from an application store. Application <b>206</b> is preconfigured with a CPS application ID <b>208</b> that may be unique, such that CPS <b>202</b> may distinguish application <b>206</b> from other applications that may be in communication with CPS <b>202</b>. That is, CPS application ID <b>208</b> allows application <b>206</b> to utilize services of CPS <b>202</b>. Further, CPS application ID <b>208</b> may also allow CPS <b>202</b> to validate received communication as being from an authentic source.

Within user device <b>204</b>, application <b>206</b> utilizes an application user ID <b>210</b> that identifies the specific user of application <b>206</b> on user device <b>204</b>. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, application <b>206</b> running on user device <b>204</b>(<b>1</b>) utilizes an application user id <b>210</b>(<b>1</b>) and application <b>206</b> running on user device <b>204</b>(<b>2</b>) utilizes an application user ID <b>210</b>(<b>2</b>). That is, although each user device <b>204</b> may run the same application <b>206</b>, communication from these applications may be distinguished by CPS <b>202</b> based upon application user ID <b>210</b>.

Application <b>206</b> interacts with CPS <b>202</b> to create context group <b>220</b> based upon a user's operation of application <b>206</b> running on user device <b>204</b>. Application <b>206</b> creates a context ID <b>212</b>, which may be based upon functionality of application <b>206</b>. For example, where application <b>206</b> is a crossword application that presents the user of device <b>204</b> with one of a plurality of crosswords to solve, context ID <b>212</b> may be based upon, at least in part, that particular crossword. Thus, where the application is running on a second user device <b>204</b>(<b>2</b>) and is presenting the same crossword to a second user, that user may automatically join the same context group <b>220</b>. When the user finishes the crossword and selects another or simply leaves application <b>206</b>, their application user ID <b>210</b> is automatically removed from context group <b>220</b>. In another example, where application <b>206</b> is a game, context ID <b>212</b> may be based upon the current user's level within that game, such that the user may be aware of other players at that level. In another example, where application <b>206</b> is a conferencing application, context ID <b>212</b> may be selected from a list of active conferences, thereby allowing the user to register with the context group associated with a particular conference. In one embodiment, context ID <b>212</b> is predefined within application <b>206</b>.

Application <b>206</b> may also utilize an application user ID <b>210</b> that is unique within context group <b>220</b> and associated with the user of application <b>206</b> on that user device <b>204</b>. Application user ID <b>210</b> is then used to register the user of user device <b>204</b> within context group <b>220</b>. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, application user ID <b>210</b>(<b>1</b>) of user device <b>204</b>(<b>1</b>) and application user ID <b>210</b>(<b>2</b>) of user device <b>204</b>(<b>2</b>) are both registered with context group <b>220</b>, which is identified by context ID <b>212</b>.

Also associated with application <b>206</b> and context group <b>220</b> is an application payload <b>230</b>. Neither CPS <b>202</b> nor context group <b>220</b> defines the size or content of application payload <b>230</b>; rather, application <b>206</b> defines the size and content of application payload <b>230</b>. In one example of operation, application payload <b>230</b> is propagated by a payload handler <b>242</b> to other members (e.g., application <b>206</b> of user device <b>204</b>(<b>2</b>) that is associated with application user ID <b>210</b>(<b>2</b>)) of context group <b>220</b>. Application payload <b>230</b> is not necessarily sent to CPS <b>202</b>, but is preferably handled by edge nodes (see <figref idref="DRAWINGS">FIG. 6</figref> and associated description) that are managed by payload handler <b>242</b>.

CPS <b>202</b> includes a context manager <b>240</b> for interacting with each application <b>206</b> to construct, manage, and destroy context group <b>220</b>. CPS <b>202</b> also includes a payload handler <b>242</b> that propagates received application payloads <b>230</b> to other members of the context group to which the sending application belongs.

CPS <b>202</b> does not specifically identify individuals within each context group. That is, identity of context group members is handled by each application <b>206</b>. It should also be noted that context groups <b>220</b> and applications <b>206</b> do not rely upon the concept of “buddy” lists. Application payloads <b>230</b> are propagated to all other members of a context group, whether they are known to one another, or not. In the above example where application <b>206</b> presents a crossword puzzle, many users may be running application <b>206</b> simultaneously. Of those users, many may be working on the same crossword, and thereby are members of the same context group. Unlike conventional presence servers where presence information of a user is propagated only to subscribed watchers of that presence information, CPS <b>202</b> propagates payload data (which may include a status of a user) to each other member of the context group. Context group <b>220</b> and its associated application payload <b>230</b> propagation may therefore be very large in comparison to the number of watchers in prior art presence that have limited authorized watchers.

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating one exemplary method <b>300</b> for utilizing CPS <b>202</b> of <figref idref="DRAWINGS">FIG. 2</figref> from an application <b>206</b> running on a user device <b>204</b>. Method <b>300</b> is implemented as machine readable instructions loaded within a memory of user device <b>204</b> as at least part of application <b>206</b>, for example. In step <b>302</b>, a context ID is generated. In one example of step <b>302</b>, application <b>206</b> runs within user device <b>204</b>(<b>1</b>) and generates a context ID based upon functionality of application <b>204</b>(<b>1</b>). In step <b>304</b>, a message containing a CPS application ID and the generated context ID of step <b>302</b> is sent to the CPS. In one example of step <b>304</b>, application <b>206</b> running on user device <b>204</b>(<b>1</b>) sends a message <b>214</b> including CPS application ID <b>208</b>, context ID <b>212</b>, and application user ID <b>210</b>(<b>1</b>) to CPS <b>202</b>.

Dashed outline <b>306</b> represents a portion of method <b>300</b> in which application <b>206</b> interacts with CPS <b>202</b> to distribute a payload to other members of the context group, and in which application <b>206</b> receives a payload from other members of the context group. In step <b>308</b>, the application generates a payload for distribution to other members of the context group. In one example of step <b>308</b>, application <b>206</b> generates application payload <b>230</b> based upon the user's progress with a displayed crossword. In step <b>310</b>, the application sends the payload of step <b>308</b> to the CPS. In one example of step <b>310</b>, application <b>206</b> sends a message including CPS application ID <b>208</b>, context ID <b>212</b>, application user ID <b>210</b>(<b>1</b>), and application payload <b>230</b> to CPS <b>202</b>. Steps <b>308</b> and <b>310</b> repeat based upon functionality of application <b>206</b>. For example, the application <b>206</b> may repeat steps to <b>308</b> and <b>310</b> each time the user changes the status of application <b>206</b>. In step <b>312</b>, application receives the payload from CPS <b>202</b>. In one example of step <b>312</b>, application <b>206</b> receives application payload <b>230</b>. In step <b>314</b>, the application processes and stores the payload received in step <b>312</b>. In one example of step <b>314</b>, application <b>206</b> processes and stores application payload <b>230</b>. Steps <b>312</b> and <b>314</b> repeat for each payload received from CPS <b>202</b>.

In step <b>316</b>, the application that sends a message to the CPS to leave the context group. In one example of step <b>316</b>, application <b>206</b> sends an exit message to CPS <b>202</b>.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating one exemplary method <b>400</b> for processing a join message received from an application. Method <b>400</b> is implemented as machine readable instructions stored within a memory and executes by a processor within CPS <b>202</b>, for example. In step <b>402</b>, the CPS receives a join context message from an application. In one example of step <b>402</b>, CPS <b>202</b> receives message <b>214</b> from application <b>206</b> running on user device <b>204</b>(<b>1</b>). Step <b>404</b> is a decision. If, in step <b>404</b>, the context group identified in step <b>402</b> exists, method <b>400</b> continues with step <b>408</b>; otherwise, method <b>400</b> continues with step <b>406</b>. In step <b>406</b>, the CPS creates the context group using the context ID received in the join message of step <b>402</b>. In one example of step <b>406</b>, CPS <b>202</b> creates context group <b>220</b> based upon CPS application ID <b>208</b> and context ID <b>212</b> received in step <b>402</b>. Method <b>410</b> continues with step <b>408</b>.

In step <b>408</b>, the application user ID received in step <b>402</b> is added as a member of the context group identified in step <b>402</b>. In one example of step <b>408</b>, CPS <b>202</b> adds application user ID <b>210</b>(<b>1</b>), received in step <b>402</b>, to context group <b>220</b> identified by context ID <b>212</b>, also received in step <b>402</b>. In step <b>410</b>, the CPS returns a success message. In one example of step <b>410</b>, CPS <b>202</b> returns message <b>222</b> to application <b>206</b> running on user device <b>204</b>(<b>1</b>).

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating one exemplary method <b>500</b> for processing a payload message. Method <b>500</b> is for example implemented as machine readable instructions stored within a memory and executed by a processor within payload handler <b>242</b> and CPS <b>202</b> of <figref idref="DRAWINGS">FIG. 2</figref>. In step <b>502</b>, a payload is received from an application. In one example of step <b>502</b>, payload handler <b>242</b> receives a payload message <b>232</b>, containing application payload <b>230</b>, from application <b>206</b> running on user device <b>204</b>(<b>1</b>). Step <b>504</b> is a decision. If, in step <b>504</b>, the context group identified in the received message of step <b>502</b> exists, method <b>500</b> continues with step <b>508</b>; otherwise method <b>500</b> continues with step <b>506</b>.

In step <b>506</b>, a new context group is created using the context ID received in step <b>502</b>. In one example of step <b>506</b>, payload handler <b>242</b> interacts with context manager <b>240</b> to create context group <b>220</b> based upon context ID <b>212</b> received in payload message <b>232</b> at step <b>502</b>. Method <b>500</b> continues with step <b>510</b>.

Step <b>508</b> is a decision. If, in step <b>508</b>, the application user ID received in step <b>502</b> exists within the context group, method <b>500</b> continues with step <b>512</b>; otherwise, method <b>500</b> continues with step <b>510</b>. In step <b>510</b>, the application user ID, received in step <b>502</b>, is added to the context group identified by the context ID also received in step <b>502</b>. In one example of step <b>510</b>, payload handler <b>242</b> interacts with context manager <b>240</b> to add application user ID <b>210</b> to context group <b>220</b>. Method <b>500</b> continues with step <b>512</b>.

In step <b>512</b>, other members of the context group, identified by the context ID received in step <b>502</b>, are determined. In one example of step <b>512</b>, context manager <b>240</b> searches database <b>244</b> to identify application user IDs <b>210</b>(<b>1</b>) and <b>210</b>(<b>2</b>) within context group <b>220</b>. In step <b>514</b>, the payload is propagated to each other member. In one example of step <b>514</b>, payload handler <b>242</b> propagates application payload <b>230</b> to application <b>206</b> of user device <b>204</b>(<b>2</b>).

As used within CPS <b>202</b>, identities are created and assigned by the applications interacting with the CPS, and not by the CPS. Thus, the CPS may operate with many different applications to create different context groups based upon the requirements of each application. Each application (e.g., application <b>206</b>) wishing to utilize contextual services of CPS <b>202</b> has a unique CPS application ID <b>208</b>. This unique CPS application ID is used together with the context ID <b>212</b> when creating context group <b>220</b> within CPS <b>202</b>; the same context ID <b>212</b> may therefore be used with different applications without confusion.

Each context group created by CPS <b>202</b> operates to link individuals that may not otherwise be linked by presence. That is, these individuals may not be linked by conventional presence, and may not know one another, but they become linked within context group <b>220</b> and may thereby exchange payload data. Each application defines the content and size of the payload data, which is not evaluated or restricted by the CPS. The payload handler distributes a payload from a first member of a context group to all other members of that context group. In one embodiment, payload handler <b>242</b> implements a data size limit to prevent overwhelming system <b>200</b> with extremes of data. The number of context groups created by an application is not limited; an application may create as many context groups as necessary for its desired functionality. Where multiple instances of an application wish to share a single context group, each instance of the application uses the same context ID.

In one example of operation, a conferencing support application is used by a plurality of attendees of a conference. Each attendee utilizes the application to connect to a common context group, thereby allowing the attendees to share comments as payload data while at the conference. That is, comments entered to the conferencing support application are propagated to other members of the context group, thereby forming a “tweeting” type service specific to that conference, and between attendees (i.e. users of the conferencing support application) that are not necessarily otherwise connected by presence.

In another example, a customer relationship management (CRM) application may create a static context group (e.g., for a discussion room) that allows users (representatives and their customers) of the application to join the context group for discussion purposes. The application may also create a context group for an online customer meeting that provides a mechanism (through distribution of payload data) for communication, file transfer, and information sharing. In another similar example, a context group may be created for a group of employees attending the same conference. The users of the application are thereby automatically connected through the context group with other employees at the same conference without requiring complicated configuration and individual ID management.

Exemplary payload data defined by an application may include a user's phone number that allows other members of the context group to contact other members through the application and the context group. In one example, application <b>206</b> allows the user to place a call to another member of a context group without the user learning the phone number of the member or dialing it. That is, the application need not make all payload data available to users of the application.

A user may become a member of multiple context groups. A context group may exist with only one member. The use of context groups and their associated payload data is very flexible, and allows CPS <b>202</b> to provide contextual presence support for many different types of application. It should be noted that a context group provided by the CPS is not synonymous with conventional presence status. That is, different status of an end user should not be seen as being in a different context group. Rather, users that may have differing status are related when joining the same context group and may receive payload data distributed within that context group.

In another example, application <b>206</b> is a game played by many people on many different user devices. The payload data associated with the game includes statistics of the game based upon the uses performance. Application <b>206</b> may not reveal personal information included with received payload data from other players of the game, but may allow that information to be used within the application <b>206</b>.

It should be noted that payload data (e.g., payload data <b>230</b>) is delivered to members of a context group and is not processed by CPS <b>202</b>. That is, neither CPS <b>202</b> nor payload handler <b>242</b> evaluate the content of the payload data.

<figref idref="DRAWINGS">FIG. 6</figref> shows exemplary handling, by payload handler <b>242</b> of <figref idref="DRAWINGS">FIG. 2</figref>, of payload message <b>232</b>. Payload handler <b>242</b> has a plurality of edge nodes <b>602</b> that form a network for propagating payload data <b>230</b> of payload message <b>232</b> from one member of a context group (e.g., context group <b>220</b>, <figref idref="DRAWINGS">FIG. 2</figref>) to other members of that context group. In one embodiment, edge nodes <b>602</b> form a distributed network, wherein payload handler <b>242</b> is spatially distributed to facilitate payload propagation. That is, edge nodes <b>602</b> need not be co-located with CPS <b>202</b>. For example, edge nodes <b>602</b> are geographically distributed.

Payload handler <b>242</b> also includes a payload manager <b>604</b> (that may be located within CPS <b>202</b>) that maintains a routing table <b>606</b> within each edge node <b>602</b> based upon context group information stored within database <b>244</b>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, edge node <b>602</b>(<b>1</b>) has a routing table <b>606</b>(<b>1</b>), edge node <b>602</b>(<b>2</b>) has a routing table <b>606</b>(<b>2</b>), and edge node <b>602</b>(<b>3</b>) has a routing table <b>606</b>(<b>3</b>). Routing tables <b>606</b> facilitate routing of payload message <b>232</b> between edge nodes <b>602</b>, and to destination user devices <b>204</b> based upon an associated context. Using routine tables <b>606</b>, edge nodes <b>602</b>, upon receipt of payload message <b>232</b>, each edge node <b>602</b> may quickly and efficiently propagate payload message <b>232</b> to other edge nodes and user devices, without requiring access to database <b>244</b> or other functionality of CPS <b>202</b>. In one embodiment, user devices <b>204</b> form edge nodes of payload handler <b>242</b> and perform peer-to-peer communication with other user devices based upon context group <b>220</b>.

To facilitate routing of payloads to user devices, each application user ID <b>210</b> added to context group <b>220</b> may also include connectivity information, such as web addresses, port addresses, etc. that facilitate propagation of application payload <b>230</b>. In one embodiment, database <b>244</b> maintains connectivity information for each application user ID <b>210</b> within context group <b>220</b>. Payload manager <b>604</b> generates and maintains routing tables <b>606</b> based upon this stored connectivity information.

In one example of operation, user device <b>204</b>(<b>1</b>) sends payload message <b>232</b> to a first edge node <b>602</b>(<b>1</b>) of payload handler <b>242</b>. Edge node <b>602</b>(<b>1</b>) utilizes routing table <b>606</b>(<b>1</b>) to determine that payload message <b>232</b> is to be sent to edge nodes <b>602</b>(<b>2</b>) and <b>602</b>(<b>3</b>). Upon receiving payload message <b>232</b>, edge node <b>602</b>(<b>2</b>) utilizes routing table <b>606</b>(<b>2</b>) to route payload message <b>232</b> to user device <b>204</b>(<b>2</b>). Similarly, upon receiving payload message <b>232</b>, edge node <b>602</b>(<b>3</b>) utilizes routing table <b>606</b>(<b>3</b>) to route payload message <b>232</b> to user device <b>204</b>(<b>3</b>). Although only one user device <b>204</b> is shown connected to each edge node <b>602</b>, edge nodes <b>602</b> may each connect to many user devices without departing from the scope hereof.

By utilizing a network (optionally a distributed network) of edge nodes <b>602</b>, or a peer-to-peer network of user devices <b>204</b>, propagation of payload message <b>232</b> avoids the typical bottle necks associated with conventional presence servers (wherein presence registration and propagation of presence updates are handled by the presence server), and thereby facilitating improved scalability of CPS <b>202</b>. That is, since the internal components of CPS <b>202</b> handle context changes, and external components (e.g., edge nodes <b>602</b>) handle payload data, scalability is improved over conventional presence.

<figref idref="DRAWINGS">FIG. 7</figref> shows CPS <b>202</b> connected to two application servers <b>702</b> and <b>710</b>, each having a plurality of clients <b>704</b> and <b>708</b>, respectively. Each client <b>704</b>, <b>708</b> is shown with an associated user <b>706</b>. Application server <b>702</b> has an assigned CPS application ID <b>208</b>(<b>1</b>) and creates a context group <b>220</b>(<b>1</b>) within CPS <b>202</b>. Application sever <b>710</b> has a CPS application ID <b>208</b>(<b>2</b>) and creates a context group <b>220</b>(<b>2</b>) within CPS <b>202</b>. Each application server <b>702</b>, <b>710</b>, may utilize more than one context group <b>220</b> within CPS <b>202</b>.

In one embodiment, application server <b>702</b> assigns application user ID <b>210</b>(<b>1</b>) to client <b>704</b>(<b>1</b>), and application user ID <b>210</b>(<b>2</b>) to client <b>704</b>(<b>2</b>). Application server <b>702</b> may then add application user IDs <b>210</b>(<b>1</b>) and <b>210</b>(<b>2</b>) to context group <b>220</b>(<b>1</b>), as shown, thereby automatically registering users <b>706</b>(<b>1</b>) and <b>706</b>(<b>2</b>) with context group <b>220</b>(<b>1</b>). Users <b>706</b>(<b>1</b>) and <b>706</b>(<b>2</b>) need not be co-located, and need not know one another; however, through use of context group <b>220</b>(<b>1</b>) by application server <b>702</b>, users <b>706</b>(<b>1</b>) and <b>706</b>(<b>2</b>) become contextually aware of one another. Application server <b>702</b> may create more than one context group within CPS <b>202</b>, such that users (e.g., users <b>706</b>(<b>1</b>) and <b>706</b>(<b>2</b>)) may be contextually linked in different ways, for example based upon selected options within client <b>704</b>. In another embodiment, client <b>708</b>(<b>1</b>) assigns application user ID <b>210</b>(<b>3</b>) to user <b>706</b>(<b>3</b>), for example based upon information of user <b>706</b>(<b>3</b>), client <b>708</b>(<b>2</b>) assigns application user ID <b>210</b>(<b>4</b>) to user <b>706</b>(<b>4</b>), for example based upon information of user <b>706</b>(<b>4</b>), and client <b>708</b>(<b>3</b>) assigns application user ID <b>210</b>(<b>5</b>) to user <b>706</b>(<b>5</b>), for example based upon information of user <b>706</b>(<b>5</b>). Each client <b>708</b>, via application server <b>710</b>, adds its assigned application user ID <b>210</b> to context group <b>220</b>(<b>2</b>), as shown in <figref idref="DRAWINGS">FIG. 7</figref>.

In one example of operation, application server <b>702</b> represents a customer relationship management tool, user <b>706</b>(<b>1</b>) is a sales representative and user <b>706</b>(<b>2</b>) is a customer accessing application server <b>702</b> via a client <b>704</b>(<b>2</b>). Application server <b>702</b> creates context group <b>220</b>(<b>1</b>) for a planned meeting (e.g., an online meeting) between the representative and the customer, thereby allowing specific data to be exchanged between the representative and the customer as payload data. For example, in preparation for a face-to-face meeting, the payload data may represent travel status and expected time of arrival data that is updated automatically by clients <b>704</b> that are mobile devices.

CPS <b>202</b> may simultaneously support many context groups <b>220</b> for many different applications.

Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween.