Contextual presence system and associated methods
Systems and methods dynamically form a context group that has a plurality of members and propagate payload data between the members. A database associates a context identifier (ID) of the context group with a user ID of each member. A context manager, communicatively coupled with the database, 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. A payload handler receives payload data from one of said members and propagates the payload data to other said members of the context group.
Latest Sabse Technologies, Inc. Patents:
- Systems and methods for providing context to a forwarded call
- Personal gateway for originating and terminating telephone calls
- Methods and systems for selecting a buddy from a buddy list and for placing call to a buddy
- Method and system for communicating across telephone and data networks
- METHOD AND SYSTEM FOR COMMUNICATING ACROSS TELEPHONE AND DATA NETWORKS
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.
BACKGROUNDA 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.
In operation, device 104 allows individual 110 to send presence information 122 (such as a current location, and an activity such as working) to presence server 102, which in turn publishes (i.e., sends) presence information 124 to acquaintances 112 and 114, thereby informing them of changes in the status of individual 110. Specifically, devices 106(1) and 106(2) do not request status information 124(A) and 124(B), respectively, from presence server 102, but are notified directly upon changes to the stored presence of individual 110.
Where device 104 represents a mobile phone, an associated service provider (or the phone itself if it includes GPS functionality) may determine a location of device 104 automatically and send this location as presence information 122 to presence server 102. Thus, published presence information 124 may include location information of device 104, which is also assumed to be the location of individual 110.
Presence server 102 may represent similar social networking services, such as Facebook™, where individual 110 describes current activities and feelings for publication to a network of authorized ‘friends’. Presence server 102 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
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 INVENTIONIn 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.
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.
Continuing with the example of
Within user device 204, application 206 utilizes an application user ID 210 that identifies the specific user of application 206 on user device 204. In the example of
Application 206 interacts with CPS 202 to create context group 220 based upon a user's operation of application 206 running on user device 204. Application 206 creates a context ID 212, which may be based upon functionality of application 206. For example, where application 206 is a crossword application that presents the user of device 204 with one of a plurality of crosswords to solve, context ID 212 may be based upon, at least in part, that particular crossword. Thus, where the application is running on a second user device 204(2) and is presenting the same crossword to a second user, that user may automatically join the same context group 220. When the user finishes the crossword and selects another or simply leaves application 206, their application user ID 210 is automatically removed from context group 220. In another example, where application 206 is a game, context ID 212 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 206 is a conferencing application, context ID 212 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 212 is predefined within application 206.
Application 206 may also utilize an application user ID 210 that is unique within context group 220 and associated with the user of application 206 on that user device 204. Application user ID 210 is then used to register the user of user device 204 within context group 220. As shown in
Also associated with application 206 and context group 220 is an application payload 230. Neither CPS 202 nor context group 220 defines the size or content of application payload 230; rather, application 206 defines the size and content of application payload 230. In one example of operation, application payload 230 is propagated by a payload handler 242 to other members (e.g., application 206 of user device 204(2) that is associated with application user ID 210(2)) of context group 220. Application payload 230 is not necessarily sent to CPS 202, but is preferably handled by edge nodes (see
CPS 202 includes a context manager 240 for interacting with each application 206 to construct, manage, and destroy context group 220. CPS 202 also includes a payload handler 242 that propagates received application payloads 230 to other members of the context group to which the sending application belongs.
CPS 202 does not specifically identify individuals within each context group. That is, identity of context group members is handled by each application 206. It should also be noted that context groups 220 and applications 206 do not rely upon the concept of “buddy” lists. Application payloads 230 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 206 presents a crossword puzzle, many users may be running application 206 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 202 propagates payload data (which may include a status of a user) to each other member of the context group. Context group 220 and its associated application payload 230 propagation may therefore be very large in comparison to the number of watchers in prior art presence that have limited authorized watchers.
Dashed outline 306 represents a portion of method 300 in which application 206 interacts with CPS 202 to distribute a payload to other members of the context group, and in which application 206 receives a payload from other members of the context group. In step 308, the application generates a payload for distribution to other members of the context group. In one example of step 308, application 206 generates application payload 230 based upon the user's progress with a displayed crossword. In step 310, the application sends the payload of step 308 to the CPS. In one example of step 310, application 206 sends a message including CPS application ID 208, context ID 212, application user ID 210(1), and application payload 230 to CPS 202. Steps 308 and 310 repeat based upon functionality of application 206. For example, the application 206 may repeat steps to 308 and 310 each time the user changes the status of application 206. In step 312, application receives the payload from CPS 202. In one example of step 312, application 206 receives application payload 230. In step 314, the application processes and stores the payload received in step 312. In one example of step 314, application 206 processes and stores application payload 230. Steps 312 and 314 repeat for each payload received from CPS 202.
In step 316, the application that sends a message to the CPS to leave the context group. In one example of step 316, application 206 sends an exit message to CPS 202.
In step 408, the application user ID received in step 402 is added as a member of the context group identified in step 402. In one example of step 408, CPS 202 adds application user ID 210(1), received in step 402, to context group 220 identified by context ID 212, also received in step 402. In step 410, the CPS returns a success message. In one example of step 410, CPS 202 returns message 222 to application 206 running on user device 204(1).
In step 506, a new context group is created using the context ID received in step 502. In one example of step 506, payload handler 242 interacts with context manager 240 to create context group 220 based upon context ID 212 received in payload message 232 at step 502. Method 500 continues with step 510.
Step 508 is a decision. If, in step 508, the application user ID received in step 502 exists within the context group, method 500 continues with step 512; otherwise, method 500 continues with step 510. In step 510, the application user ID, received in step 502, is added to the context group identified by the context ID also received in step 502. In one example of step 510, payload handler 242 interacts with context manager 240 to add application user ID 210 to context group 220. Method 500 continues with step 512.
In step 512, other members of the context group, identified by the context ID received in step 502, are determined. In one example of step 512, context manager 240 searches database 244 to identify application user IDs 210(1) and 210(2) within context group 220. In step 514, the payload is propagated to each other member. In one example of step 514, payload handler 242 propagates application payload 230 to application 206 of user device 204(2).
As used within CPS 202, 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 206) wishing to utilize contextual services of CPS 202 has a unique CPS application ID 208. This unique CPS application ID is used together with the context ID 212 when creating context group 220 within CPS 202; the same context ID 212 may therefore be used with different applications without confusion.
Each context group created by CPS 202 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 220 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 242 implements a data size limit to prevent overwhelming system 200 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 206 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 202 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 206 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 206 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 206.
It should be noted that payload data (e.g., payload data 230) is delivered to members of a context group and is not processed by CPS 202. That is, neither CPS 202 nor payload handler 242 evaluate the content of the payload data.
Payload handler 242 also includes a payload manager 604 (that may be located within CPS 202) that maintains a routing table 606 within each edge node 602 based upon context group information stored within database 244. As shown in
To facilitate routing of payloads to user devices, each application user ID 210 added to context group 220 may also include connectivity information, such as web addresses, port addresses, etc. that facilitate propagation of application payload 230. In one embodiment, database 244 maintains connectivity information for each application user ID 210 within context group 220. Payload manager 604 generates and maintains routing tables 606 based upon this stored connectivity information.
In one example of operation, user device 204(1) sends payload message 232 to a first edge node 602(1) of payload handler 242. Edge node 602(1) utilizes routing table 606(1) to determine that payload message 232 is to be sent to edge nodes 602(2) and 602(3). Upon receiving payload message 232, edge node 602(2) utilizes routing table 606(2) to route payload message 232 to user device 204(2). Similarly, upon receiving payload message 232, edge node 602(3) utilizes routing table 606(3) to route payload message 232 to user device 204(3). Although only one user device 204 is shown connected to each edge node 602, edge nodes 602 may each connect to many user devices without departing from the scope hereof.
By utilizing a network (optionally a distributed network) of edge nodes 602, or a peer-to-peer network of user devices 204, propagation of payload message 232 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 202. That is, since the internal components of CPS 202 handle context changes, and external components (e.g., edge nodes 602) handle payload data, scalability is improved over conventional presence.
In one embodiment, application server 702 assigns application user ID 210(1) to client 704(1), and application user ID 210(2) to client 704(2). Application server 702 may then add application user IDs 210(1) and 210(2) to context group 220(1), as shown, thereby automatically registering users 706(1) and 706(2) with context group 220(1). Users 706(1) and 706(2) need not be co-located, and need not know one another; however, through use of context group 220(1) by application server 702, users 706(1) and 706(2) become contextually aware of one another. Application server 702 may create more than one context group within CPS 202, such that users (e.g., users 706(1) and 706(2)) may be contextually linked in different ways, for example based upon selected options within client 704. In another embodiment, client 708(1) assigns application user ID 210(3) to user 706(3), for example based upon information of user 706(3), client 708(2) assigns application user ID 210(4) to user 706(4), for example based upon information of user 706(4), and client 708(3) assigns application user ID 210(5) to user 706(5), for example based upon information of user 706(5). Each client 708, via application server 710, adds its assigned application user ID 210 to context group 220(2), as shown in
In one example of operation, application server 702 represents a customer relationship management tool, user 706(1) is a sales representative and user 706(2) is a customer accessing application server 702 via a client 704(2). Application server 702 creates context group 220(1) 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 704 that are mobile devices.
CPS 202 may simultaneously support many context groups 220 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.
Claims
1. A contextual presence system (CPS) for dynamically forming a context group and for propagating payload data between members of the context group, each member having a device running an application configured with a context identifier (ID) that identifies the context group and a user ID that uniquely identifies the member within the context group, the system comprising:
- a database capable of associating the context with each user ID;
- a context manager, communicatively coupled with the database, capable of:
- receiving, from each member device, a join context request containing the context ID and said corresponding user ID;
- storing within the database, for each received join context request, the context ID in association with the user ID to create the context group; and
- a payload handler capable of receiving payload data from one of said devices of a corresponding one of said members and for propagating the payload data to each other of said devices corresponding to other of said members of said context group;
- wherein the contextual presence system (a) has no knowledge of the context ID prior to receiving the join request, (b) transports the payload data without evaluation of the payload data content, and (c) concurrently supports more than one context group.
2. The system of claim 1, wherein the CPS is capable of creating the context group in real-time upon receiving the join context request when the context ID does not exist within the database.
3. The system of claim 1, wherein the size and content of the payload data is defined by the application running on a user device that sent the join context request.
4. The system of claim 1, wherein the user ID is defined by the application running on a user device that sent the join context request.
5. The system of claim 1, wherein the context manager is further capable of validating validates the join context request using a CPS application ID to identify the application sending the join context request.
6. The system of claim 1, wherein the context ID is generated by the application running on a user device that sent the join context request based upon a parameter under control of a user of the device.
7. The system of claim 6, wherein the user device may join more than one context group.
8. The system of claim 1, wherein the database is further operable to store connectivity information of each of the user devices corresponding to said members of the context group.
9. The system of claim 1, wherein the payload handler is configured as a plurality of internetworked edge nodes in communication with the context manager, and wherein the payload data is received by a first edge node and propagated to at least one of the other said devices via a second of the edge nodes without passing through a server of the context manager; each of the edge nodes being located remotely from the member devices.
10. The system of claim 9, the payload handler further comprising a payload manager capable of storing, on each of the edge nodes, a routing table defining propagation of the payload data based upon connectivity of each said member of the context group.
11. The system of claim 9, wherein the edge nodes are geographically distributed.
12. A computer implemented method for dynamically forming a context group between members of a context group, comprising the steps of:
- receiving, within a contextual presence server and from a first user device running an application, a first join context request comprising (a) a context ID defined by the application and based upon the functionality of the application and (b) a first user ID of the first user device for uniquely identifying the first user device within the context group;
- creating the context group within a database by associating the context ID and with the first user ID,
- wherein (a) the context ID is not known within the contextual presence server prior to receiving the first join context request, (b) the context group does not exist within the database prior to receiving the first join request, and (c) the contextual presence server concurrently supports more than one context group;
- receiving, from one of the first and a second user devices, a payload message comprising payload data, the context ID, and a corresponding one of the first and second user IDs; and
- propagating the payload data to corresponding other of said first and second user devices based upon the context ID and the corresponding one of the first and second user IDs,
- wherein the payload data is propagated without evaluation of the payload data content.
13. The method of claim 12, further comprising the steps of:
- receiving, from a second user device running a copy of the application, a second join context request comprising the context ID and a second user ID of the second user device; and
- adding the second user ID to the context group by associating the second user ID with the context ID within the database.
14. The method of claim 13, wherein the steps of receiving the second join context request and adding are repeated for each received additional join context request.
15. The method of claim 12, further comprising the steps of:
- receiving, from one of the first and second user devices, a leave context message comprising the context ID and a corresponding one of the first and second user IDs; and
- removing said corresponding one of the first and second user IDs from the context group;
- wherein the context group is deleted from the database directly upon receiving the leave context message if the removed corresponding one of the first and second IDs was the only ID of the context group.
6493703 | December 10, 2002 | Knight et al. |
7613776 | November 3, 2009 | Ben-Yoseph |
7890871 | February 15, 2011 | Etkin |
7899862 | March 1, 2011 | Appelman et al. |
8128487 | March 6, 2012 | Hamilton et al. |
8516052 | August 20, 2013 | Fu et al. |
20040148347 | July 29, 2004 | Appelman et al. |
20060048059 | March 2, 2006 | Etkin |
20060135263 | June 22, 2006 | Labrie |
20070112719 | May 17, 2007 | Reich et al. |
20070192461 | August 16, 2007 | Reich et al. |
20070293212 | December 20, 2007 | Quon et al. |
20080189621 | August 7, 2008 | Reich et al. |
20090037534 | February 5, 2009 | Castro et al. |
20090157814 | June 18, 2009 | Lee et al. |
20100223335 | September 2, 2010 | Fu et al. |
20110022621 | January 27, 2011 | Luo et al. |
20120008526 | January 12, 2012 | Borghei |
20120072497 | March 22, 2012 | Steiert |
20120084669 | April 5, 2012 | Flint et al. |
- Wei-Lun Chang & Tzu-Hsiang Lin, A Cluster-Based Approach for Automatic Social Network Construction, IEEE International Conference on Social Computing, 2010.
Type: Grant
Filed: Oct 24, 2011
Date of Patent: Feb 23, 2016
Patent Publication Number: 20120102073
Assignee: Sabse Technologies, Inc. (Mountain View, CA)
Inventor: Yogesh B. Patel (Mountain View, CA)
Primary Examiner: James Trujillo
Assistant Examiner: Kurt Mueller
Application Number: 13/279,896
International Classification: G06F 17/30 (20060101); H04L 12/58 (20060101);