US 8060572 B2
A method for managing a subscription to content-based presence information entails receiving a subscription-suspension message from a device at a presence service, identifying the subscription associated with the subscription-suspension message, suspending the subscription, and sending a response from the presence service to the device to notify the device that the subscription has been suspended. Suspending the subscription may involve accumulating notifications in a persistent data store. The method may further involve receiving a subscription-resumption message at the presence service to resume the subscription that was suspended.
1. A method performed by a presence service, comprising:
receiving presence information from a presentity;
storing the presence information in any arbitrary data format;
receiving a subscription request from a device, the subscription request including a subscription expression and requesting to establish a subscription to receive the presence information if the presence information matches the subscription expression;
validating the subscription request by determining if the requested presence information is authorized by the presentity from which the presence information is received;
creating the subscription in response to the requested presence information is authorized by the presentity; and
communicating the presence information when the presence information matches the subscription expression;
receiving a subscription-suspension message from the device;
identifying the subscription associated with the subscription-suspension message; and
suspending the subscription.
2. The method as claimed in
3. The method as claimed in
4. The method as claimed in
receiving notifications at a presence function node from a publish-message subsystem; and
forwarding the notifications to the persistent data store for storage until the subscription is resumed.
5. The method as claimed in
6. The method as claimed in
7. A presence system comprising:
one or more processors;
a non-transitory computer-readable medium;
software code stored on the non-transitory computer-readable medium and including instructions that are executable on the one or more processors to:
receive presence information from a presentity; and
store the presence information in any arbitrary data format;
receive a subscription request from a device, the subscription request including a subscription expression and requesting to establish a subscription to receive the presence information if the presence information matches the subscription expression;
validate the subscription request by determining if the requested presence information is authorized by the presentity from which the presence information is received;
create the subscription in response to the requested presence information is authorized by the presentity; and
communicate the presence information when the presence information matches the subscription expression;
receive a subscription-suspension message from the device;
identify the subscription associated with the subscription-suspension message; and
suspend the subscription.
8. The presence system as claimed in
9. The presence system as claimed in
10. The presence system as claimed in
receiving notifications at a presence function node from a publish-message subsystem; and
forwarding the notifications to the persistent data store for storage until the subscription is resumed.
11. The presence system as claimed in
12. The presence system as claimed in
This application claims priority from U.S. Provisional Patent Application Ser. No. 61/155,017 entitled METHOD AND SYSTEM FOR COLLECTING, MANAGING AND DISSEMINATING PRESENCE INFORMATION, which was filed Feb. 24, 2009.
The present technology relates generally to telecommunications and, in particular, to the collection, management and dissemination of presence information.
In telecommunications, presence information has traditionally been used to indicate the ability, availability and willingness of a person to communicate. More generally, a person's presence information provides contextual information to let others know something about the present context of the person.
Presence is currently one of the key drivers behind instant messaging (IM) and some of the recent developments in VoIP technology, in particular Session Initiation Protocol (SIP). While these and other rudimentary presence technologies have been implemented and discussed (see, e.g., the IETF's RFC 2778 entitled “A Model for Presence and Instant Messaging” and RFC 4480 entitled “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)”), these technologies are still generally quite embryonic. These prior-art technologies provide limited flexibility, scalability, security and privacy. Accordingly, improvements in the manner in which presence information is collected, managed and disseminated remain highly desirable.
Further features and advantages of the present technology will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
In general, the present technology disclosed herein provides an innovative presence system and related methods for collecting, managing and disseminating presence information. More specifically, novel systems, methods and devices are disclosed herein for managing subscriptions to presence information. Subscription management enables users to control the influx of presence information about presentities with whom authorized subscription relationships have been previously established.
This novel presence technology is built around a content-based presence service as opposed to one that depends on pre-arranged data formats. This novel content-based presence service enables data content representing presence information to be published and stored in any arbitrary data format. Authorized watchers can thus subscribe to the presence information, or to specific elements of the presence information (“attributes” such as location, mood, activity, availability, etc.) by simply specifying subscription expressions in terms of content. For example, a subscription expression <Contact1, location=“Ottawa”) would notify the user when Contact1 is located in Ottawa. This content-based approach to presence enables data content to be published in any format and enables subscriptions to be defined in terms of the content that is sought or desired. Client applications that contribute or consume presence information can be utilized and updated without having to ensure interoperability of data formats. As such, this novel presence service is highly flexible, scalable and allows highly nuanced presence information to be published or sought. Subscription management is an important aspect of a presence service. Subscription management enables subscriptions to presence information to be suspended or resumed. As will be elaborated below, suspension and resumption of subscriptions can be triggered by manual input of the user or may be based on predefined triggering conditions.
In main implementations of this technology, the presence service has, at its core, a content-based publish-subscribe subsystem for publishing data representing presence information in any arbitrary data format. An authorized contact, or watcher, can subscribe to presence information by specifying data content of interest in the form of subscription expressions that are also purely defined in terms of the content, i.e. independent of data format. When a presentity authorizes a watcher to subscribe to presence information, this establishes an authorized subscription relationship between the presentity and the watcher. The subscription may entitle the watcher to receive notifications relating to all of the presence information that the presentity publishes to the publish-subscribe subsystem or to only a specified subset of the presence information published to the publish-subscribe subsystem.
One main aspect of the present technology is a method for managing subscriptions for a content-based presence service. The method entails receiving a subscription-suspension message from a device at a presence service, identifying the subscription associated with the subscription-suspension message, and suspending the subscription. A response may then be sent from the presence service to the device to notify the device that the subscription has been suspended.
Another main aspect of the present technology is a computer-readable medium comprising code which when loaded into memory and executed on a processor of a computing device is adapted to perform the foregoing acts.
Yet another main aspect of the present technology is a method, performed on a wireless communications device, for managing a subscription to content-based presence information. The method involves sending a subscription-suspension message from the device to a presence service to suspend the subscription and then receiving a response from the presence service notifying that the subscription has been suspended.
Another main aspect of the present technology is a computer-readable medium comprising code which when loaded into memory and executed on a processor of a computing device is adapted to perform the foregoing acts.
Yet another main aspect of the present technology is a presence system for managing subscriptions to presence information. The system includes a publish-subscribe subsystem for subscribing to presence information and a proxy node for routing a subscription-suspension message from a device to a predetermined function node. The function node processes the subscription-suspension message to identify a subscription associated with the subscription-suspension message and then suspends the subscription.
Yet another main aspect of the present technology is a wireless communications device for managing a subscription to presence information. The device includes a processor operatively coupled to a memory for executing a presence client that is programmed to generate a subscription-suspension message and a radiofrequency transceiver for transmitting the subscription-suspension message to a presence service to suspend the subscription.
The details and particulars of these aspects of the technology will now be described below, by way of example, with reference to the attached drawings.
This novel presence system can be understood as a service overlay superimposed on a mobile network infrastructure and the Internet. In other words, the general architecture depicted in
The presence system is defined using a client-server style architecture in which presence clients produce and consume presence information. In general, and as will be elaborated below, presence information that is generated (collected and published) by one or more presentities may be consumed by one or more watchers. A user may be both a presentity and a watcher, or only one or the other. Mediating between presence clients is a presence server. This presence server receives, manages and disseminates the presence information.
The presence server uses a single global service identifier to simplify routing of data. For example, for certain types of wireless clients communicating through a mobile network infrastructure, the presence service has a single global service identifier (or service address). This approach simplifies routing of data and avoids coupling of the presence server with the mobile network infrastructure topology.
Still by way of introduction and overview, the presence server may be implemented as a tiered system made up of a proxy tier, a function tier and a persistence tier. This tiered structure of the presence server is transparent to presence clients. Presence clients may communicate with the presence server using a presence protocol.
For the purposes of this specification, the expression “presence information” refers to a set of information that conveys ability, availability, willingness for various modes of communication, e.g. e-mail, voice, short message service (SMS), multimedia message service (MMS), instant messaging (IM), for various services and various devices. Presence information usually contains specific, unambiguous states such as available/unavailable, current location, activity, holiday/working, sleeping/awake; however, it may also contain ambiguous, nuanced, subtle or qualitative information such as mood, interests, intentions, wishes, etc.
For the purposes of this specification, a “presentity” combines devices, services and personal information for a complete picture of a user's presence status.
System Architecture and Presence Protocol
As noted above, the presence system is a service overlay superimposed on a mobile network infrastructure and/or the Internet. From the perspective of presence clients, the presence service appears as a singular server instance. The service can be identified by a single global service identifier on all instances of the mobile network infrastructure.
The presence protocol is an application protocol that can be transported over the existing network using a suitable transport protocol or wireless transport protocol. The presence protocol depends upon underlying transport layers such as TCP/IP only for basic message delivery services. It is not dependent upon the specifics of transport layer addressing, routing or network topologies.
As a consequence of the design of the system architecture and of the presence protocol, the presence system is decoupled from the network topology (e.g., the presence system is not coupled to any particular instance of a mobile network infrastructure). Furthermore, not only are system functions separate and independent from the applications, but also the applications themselves operate independently of one another. The architecture and protocol moreover enable the following: (i) flexible message routing as defined by the applications, (ii) enhancements and extensions without requiring upgrade or restart of the entire system, and (iii) the addition of individual components to implement new versions of the protocol independently.
A multitude of considerations have influenced and guided the design of the architecture and of the presence protocol such as, for example, having a well-defined protocol layering, and using version management (e.g. ensuring that each message identifies the version of the protocol with which it complies). Transport mapping was also another key consideration in the design the architecture and protocol. For example, the system is designed to map the presence protocol onto underlying network transports to provide basic message delivery services. The system is also designed to work with symmetric, Internet-style transports such as SCTP or SIP for server-server communication. Transaction support is another important consideration. For instance, messaging order can be achieved by implementing a sequence number (which enables local message order correction). The system may also use a transaction identifier to associate related requests and responses.
A further design consideration was to implement a message-based structure (e.g. datagrams for message-oriented communication, application multiplexing, user session multiplexing, application-specific protocol fields and data elements).
Yet a further consideration was network decoupling (i.e. applications and users named independently of underlying network addresses). For example, the transport protocol identifies devices and service whereas the presence protocol identifies users and sessions.
Still a further consideration was to make the system asynchronous and non-blocking. Accordingly, applications are independent of each other, users are independent of each other, and clients are independent of each other.
Security was also a key requirement for this novel system. The system does not reveal any information, such as authorization or filters, through response codes or other normal operations. A key management protocol may be used to ensure communication security between presence clients and the presence service so that presence data is shared in total privacy with only the intended recipient(s). User authentication ensures that only authorized clients are able to receive presence information. System security and user authentication will be described in greater detail below.
Referring now to
In the novel presence system, the client applications may be realized as Java applications running on a mobile device, although any other suitable programming language may be used. In addition to a presence client application, the client applications may include, for example, a distinct presence registration client application and a business card client application.
The proxy tier may also be realized as a Java application that executes on a set of servers known as proxy nodes which are connected to the infrastructure via a suitable transport protocol. These proxy nodes act as gateways which terminate the transport protocols and route presence protocol messages to their correct destinations.
Messages sent from a client to the presence service are routed by a proxy node to the appropriate node in the function tier based upon the identity of the client and the specific application identified in the message.
Messages sent from the presence service to a client are routed by a proxy node based upon the Universally Unique Identifier (UUID) contained in the message.
By way of example to illustrate one possible implementation of this technology, the function tier may be composed of a set of specialized application nodes:
The application nodes of the functional tier may be deployed on separate servers or together in various combinations or clusters depending upon any deployment requirements.
The persistence tier can be implemented, for example, as a database running on a server, a cluster of servers or a network of servers.
The presence protocol supports request-response style (i.e. synchronous) message exchanges as well as asynchronous message delivery, which are depicted schematically in
Applications such as registration, publication, subscription/notification and peer-to-peer communication are independent of each other within the presence protocol layer. In particular, routing of messages is independent and distinct for each application.
In main implementations of this technology, different message categories are employed to identify messages related to different aspects of the presence service.
The next time the presence service sends a message to the presence client the proxy node responsible for routing the message will retrieve the new UUID-mobile device identifier mapping from the persistent data store.
During registration, one message is sent via e-mail to the presence client to verify ownership of the selected user identifier e-mail address. In a specific implementation, this special e-mail message contains only an attachment with content type “application/x-rimdevice-MailAuthToken-authToken.ext”, for example. The attachment contains, in most implementations of this technology, an authentication token.
In one specific implementation, each registration message comprises an eight-byte fixed-length registration session identifier field followed by a single TLV command field where TLV refers to a command encoded using a Type-Length-Value format.
Peer-to-peer messages enable a presence client to communicate with another presence client via the presence system. The presence service mediates the communication, authenticates clients and routes messages between clients.
There are two basic scenarios for peer-to-peer communications. The first scenario is the most common in which the sending party knows the UUID (universally unique identifier) of the destination. In the second scenario the sending party does not yet know the UUID of the destination—only the email address of the destination is known.
Client A populates the DUUID field with “all Fs” (or any other predetermined sequence of letters, numbers or symbols) to indicate to the Presence System that the UUID of the destination is unknown and that there is a TLV-encoded email address included for Client B.
The presence system performs a database lookup on the e-mail address to obtain the corresponding UUID for Client B. The DUUID field is then populated with the UUID of the destination (in this case Client B) and the message is forwarded to Client B.
Subscribing to Presence Information
The present technology enables a user (“watcher”) to subscribe to presence information generated and published to the presence service by a presentity and to manage these subscriptions to control the receipt of presence information for which authorized subscription relationships have been previously established. With the presentity's authorization, the watcher thus establishes a subscription relationship with a presentity. This subscription relationship is consensual in the sense that the watcher may only receive presence information when allowed by the presentity that publishes the presence information. As will be elaborated below, the presentity may impose content-based conditions, time-based conditions, location-based conditions, or any other such conditions on the subscription so as to limit and control what information may be communicated and under what circumstances the information may be communicated. To establish an authorized subscription relationship between a presentity and a watcher, a subscription request is communicated by the would-be watcher to a content-based presence service. The subscription request is then validated by the presence service by determining if information contained in the subscription request represents an authorized subscription relationship, e.g. if the identity of the would-be watcher making the request and the type of information sought by the would-be watcher are accepted by, or acceptable to, the presentity that is of interest to the would-be watcher. In other words, an authorized subscription relationship is created when a presentity grants permission, however limited or contingent, to a watcher to access published data content representing the presence information. The method also involves specifying a subscription expression defining data content that is of interest to the second user (i.e. the watcher) and then receiving presence information about the first user (i.e. the presentity) when the subscription expression matches the data content published by the first user (the presentity) to the presence service. Publishing and/or watching may be accomplished using a wireless communications device. In that case, assuming the wireless communications device has a positioning-determining subsystem, e.g. a GPS chipset, the current time and/or current location of the wireless communications device may be used to determine or filter when a subscription request is sent or how the subscription is expressed. In other words, presence information may be collected based on a time condition and/or a location condition (e.g. only between 9 a.m. and 5 p.m. and provided that the location corresponds to London, England). Similarly, publication of any collected presence information may be controlled by time- and/or location-based criteria. Moreover, as mentioned above, the subscription may stipulate time- and/or location-based conditions that must be met before any presence information is disseminated to a watcher.
The presence server compares the subscription expression with data published by other sources in the future to determine whether there is a match. Whenever there is match with the subscription expression, the presence server sends a notification containing the matching data to the presence client as shown in
Publishing Presence Information
The present technology enables presence information to be published using a computing device such as, for example, a wireless communications device. This involves collecting presence information, publishing data content representing presence information to a content-based presence service, the presence service storing the data content in any arbitrary data format, and authorizing an interested contact to subscribe to the presence information. The interested contact thereby becomes a watcher when the subscription is authorized. This watcher thus receives the published data content representing the presence information of the presentity of interest when a subscription expression specified by the watcher matches the data content published to the presence service by that presentity. Publication may be accomplished using a wireless communications device, which may include a position-determining subsystem such as, for example, a GPS chipset. In that case, the current time and/or current location of the wireless device may be used to determine or filter what presence information is collected and/or published.
The publish message sent to the presence server by Client B contains the data that is intended to be published. The presence service compares the published data with subscription expressions previously received from other clients with whom Client B has authorized subscription relationships. In this example, the published data matches a subscription expression and the presence server sends a notification containing the published data to Client A which created the matching subscription expression.
Upon completion of the key negotiation phase, the presence client and the presence registrar will have established a trusted, encrypted communications channel. This can be accomplished using, for example, the Diffie-Hellman key exchange technique.
The procedure is initiated when the user's device sends, e.g., the [1:TOKEN_REQUEST]) message to the Presence Registrar. This message contains an identifier, typically an e-mail address, selected by the user. To verify that the user actually owns the identifier, the presence registrar sends, e.g., [4a:TOKEN_RESPONSE] to the presence client using the presence protocol and also sends, e.g., [4b:TOKEN_RESPONSE] to the presence client via e-mail. These TOKEN_RESPONSE messages each contain unique security material which the presence client combines and sends back to the presence registrar in, e.g., the [8:AUTHENTICATE] message to prove ownership of the e-mail identifier. Other authentication techniques may be used in lieu of, or in addition to, the procedure described above.
Upon successful authentication of the user's identifier the presence registrar performs a lookup, e.g., [11:Lookup] to determine if the user is a new registrant or if they have previously registered with the presence service. In this scenario the user is a new registrant so the presence registrar generates a new Universally Unique Identifier (UUID) for the user, establishes a binding for the user with a function node using a binding request message, e.g., [12:BIND_REQ] and adds the user's profile in the persistent data store using an add message, e.g., [13:Add User].
The final step of the presence registration procedure is to send an authentication acknowledgement, e.g., [14:AUTHENTICATE ACK] back to the presence client to acknowledge successful registration. The acknowledgement message contains the user's newly generated UUID.
Upon completion of this phase the user is registered with the presence service. The following has thus been accomplished:
Sharing and Updating a Virtual Business Card
In addition to collecting, managing and disseminating presence information, the presence system disclosed herein may also be used to share and update virtual business cards. A virtual business card, such as, for example a vCard, is a data file that stores a contact's name, company name, work address, telephone and fax numbers, e-mail address, etc.
It is possible to allow users to exchange business cards using other methods such as via an Instant Messaging session or through other means.
Publication, Notification and Subscription Management
Suspending a subscription may be done manually or automatically. Manually suspending a subscription may, for example, be done by receiving input on a user input device that indicates that the user wishes to suspend a subscription. Automatically suspending a subscription may, for example, entail programming or pre-configuring the device (or, more specifically, the presence client that executes on the device) to send the suspend/pause subscription message upon satisfaction of one or more predetermined criteria, hereafter referred to as suspension-triggering conditions. These suspension-triggering conditions may be, for example, time-based conditions and/or location-based conditions. These suspension-triggering conditions can be defined to pause a single subscription or a group of subscriptions.
In one implementation, the suspension-triggering conditions suspend the subscription indefinitely until a resumption-triggering condition is met, even if the suspension-triggering condition ceases to be met. In other words, the indefinite or open-ended suspension-triggering condition requires a resumption-triggering condition to affirmatively resume the subscription. (Resumption-triggering conditions are described in detail in the paragraphs below that reference
Time-based suspension-triggering conditions can be defined to pause a subscription starting at any time, day, week, month or year.
For indefinite time-based suspension-triggering conditions, the subscription is paused indefinitely when the current time reaches a prescribed temporal condition, e.g. the subscription is paused indefinitely as of 5:45 p.m. on Friday, Oct. 31, 2009. As this condition is indefinite (open-ended), the subscription will not resume unless a specific, affirmative resume message is received.
For definite time-based suspension-triggering conditions, the subscription can be paused for any period of time, e.g. for a specific day, week, month, year, etc. These definite time-based suspension-triggering conditions thus act as timers for suspending and resuming subscriptions. For example, the device may be configured to automatically send a message to suspend a subscription for a business contact if the current time is not between 9 a.m. and 5 p.m. or if the current day is not Monday to Friday (i.e. during regular business hours).
Location-based suspension-triggering conditions can be defined for a specific geographical location, such as a continent or group of continents, country or group of countries, state/province/district or group of states/provinces/districts, or any city, town or municipality or group of cities, towns or municipalities, etc. The location-based condition may also be the entry into, or exit from, any customized region defined in terms of coordinates of latitude and longitude, graphical bounding box, etc. For example, the device may be automatically configured to send a message to suspend a subscription if the current location is outside North America.
These location-based conditions may also be indefinite or definite. If the condition is indefinite, the subscription is suspended upon satisfaction of the condition (e.g. leaving North America) even if the device subsequently no longer satisfies the triggering condition (e.g. the device returns to North America). A subscription-resumption message (triggered either manually or automatically upon satisfaction of a resumption condition) is required to resume the subscription. If the condition is definite, on the other hand, the subscription is automatically resumed when the triggering condition ceases to exist, e.g. as soon as the device returns to North America.
Time-based and location-based suspension-triggering conditions may be used conjointly. As an example, the device may be automatically configured to send a message to suspend a subscription if the current time is between 1 a.m. and 5 a.m. and if current location corresponds to Barcelona, Spain.
In addition to time-based and location-based suspension-triggering conditions, the subscriptions may be suspended (paused) based on any other conditions such as, for example, the device's battery strength, current network congestion, current CPU usage, etc. For example, if the device is running low on battery, the device may be configured to automatically suspend subscriptions to minimize the amount of data being received over the air.
The device may also be configured to enable all subscriptions to be suspended (a “suspend all subscription” feature). This feature may be triggered manually or automatically upon satisfaction of a predetermined criterion or condition. Such a feature would be useful, for example, to a person who is going on vacation and wishes to efficiently suspend all subscriptions (without having to individually suspend each subscription).
Resuming a subscription may be done manually or automatically, analogously to the procedure for suspending a subscription. Manually resuming a paused subscription may, for example, be done by receiving input on a user input device that indicates that the user wishes to resume a currently suspended subscription. Automatically resuming a subscription may, for example, entail programming or pre-configuring the device to send the resume subscription message upon satisfaction of one or more predetermined criteria, hereafter referred to as subscription-resumption-triggering conditions or simply resumption conditions. These resumption conditions may be, for example, time-based conditions and/or location-based conditions. These resumption conditions can be defined to resume a paused subscription (or to resume a related group of paused subscriptions).
Time-based resumption conditions can be defined to resume a suspended subscription at any particular time, day, week, month, year, etc. A suspension-triggering condition can be used in conjunction with a resumption condition to act as a timer for suspending and resuming subscriptions. For example, a subscription may be paused on June 10 and resumed August 15.
Location-based resumption conditions can also be defined in terms of a specific geographical location, such as a continent or group of continents, country or group of countries, state/province/district or group of states/provinces/districts, or any city, town or municipality or group of cities, towns or municipalities. The location-based condition can also be the entry into, or exit from, any customized region defined in terms of coordinates of latitude and longitude, graphical bounding box, etc. For example, the device may be automatically configured to send a subscription resumption message to resume a paused subscription only when the current location of the device is within the city limits of Montreal. It is to be noted that the location condition that triggers suspension of the subscription may be different from the location condition that causes resumption of the subscription. For example, the subscription may be suspended when the device arrives in Paris and resumed only when the device arrives in Rome.
Time-based and location-based resumption conditions may also be used conjointly. As an example, the device may be configured to automatically send a message to resume a paused subscription if the current time is between 11 a.m. and 4 p.m., the current day is Tuesday, the current month is July and if a current location corresponds to Ottawa, Canada.
In addition to time-based and location-based conditions, paused subscriptions may be resumed based on any other conditions such as, for example, renewed battery strength above a predetermined threshold, diminution in network congestion below a predetermined threshold, CPU usage below a predetermined threshold, etc.
Resuming subscriptions may be accomplished individually, by manually or automatically sending a resume message for each specific subscription. The device may also be configured to enable all currently paused subscriptions to be resumed. A “resume all subscriptions” feature may be manually selected to generate subscription-resumption messages for each paused subscription. This feature may be useful for a person who has returned from vacation and wishes to resume all of his or her subscriptions. Similarly, the resume-all-subscriptions feature may be activated upon satisfaction of one central condition that triggers the sending of resumption messages for all subscriptions.
In the specific implementation depicted by way of example in
In yet another implementation, the presence client executing on the device may include settings, preferences or options for determining whether to retain or discard notifications while the subscription is paused, how long to retain notifications before being purged, or which types of notifications are to be retained or purged. These settings or preferences may be communicated to the presence service in the resumption message.
In yet another implementation, the device may instruct the presence service to transfer the old notification data or a subset thereof from the persistent data store to a remote data store for archiving.
Occasionally, a user will switch devices (e.g. upgrade his or her mobile device to a newer model). There are two key scenarios relating to the switching of devices.
In the first scenario, an up-to-date (fresh) copy of the old device's data is copied to the new device via a backup/restore procedure.
In the second scenario, a current backup of the data from the old device is unavailable. This might happen, for example, if the old device was lost or damaged.
Using the subscription list obtained from the re-registration procedure the user may request re-authorization and new keys from each contact. Existing subscriptions are in place and active so there is no need to create new subscriptions or to modify existing subscriptions. If authorization is not granted then subscriptions should be removed to avoid receiving unwanted notifications. The next step is thus to revoke authorization and encryption keys that have been given to other contacts. This will trigger those contacts to request re-authorization and obtain new keys as shown in
All subscribed contacts will receive notifications containing the message from User1. If the subscribed contact so wishes, these contacts may request re-authorization and new keys from User1.
The presence system described above can be used with any networked computing device or communications device, including, personal computers, laptops, tablets, wireless communications devices (including PDAs, smart phones, cell phones, or any other type of mobile phone). Although the presence technology can be used with a static computing device, it is particularly useful when utilized in conjunction with mobile devices that are equipped with location-determining subsystems such as, for example, Global Positioning System (GPS) receivers as this provides location-based presence information.
As further depicted in
The persistent data store 1400 is not only accumulates (stores) notifications from the publish-subscribe subsystem 1330 during the period that a subscription has been suspended or paused but also stores other information as well. For example, the persistent data store 1400 may also store generally invariable user identification data and a mapping that links each user (via, e.g. a universally unique ID) to each device (via, e.g. a mobile device identifier number associated with the device such as, for example, an International Mobile Equipment Identity (IMEI) number which uniquely identifies a GSM, UMTS, LTE or iDEN mobile device or a Mobile Equipment Identifier (MEID) which uniquely identifies a CDMA mobile device).
While it is advantageous to implement the presence system in the manner illustrated in this figure, i.e. with proxy nodes decoupled from function nodes and with function nodes decoupled from the publish-subscribe subsystem, it is also possible to combine one or more of the nodes depicted in this figure into one or more multi-functional nodes. It should also be appreciated that the additional (backup) nodes may be inserted to provide network redundancy and resiliency.
In one implementation of this exemplary system, the proxy node is configured to route the message relating to presence information based on an identity of the presence client (i.e. which user it is) and a specific application identified in the message.
In one implementation of this exemplary system, the publish-subscribe subsystem 1330 employs independently operable publication and subscription servers, i.e. the publication server(s) and the subscription server(s) function independently of each other. Accordingly, data content can be published even if no matching subscription exists. Likewise, a subscription can be created even if no matching data content has yet been published. For example, a user can publish presence information about himself using any arbitrary descriptors (which need not be pre-defined). Likewise, a watcher can define a subscription expression using any arbitrary language even if there is no published data content relevant to the subscription expression.
The novel presence system disclosed herein is predicated upon a content-based model in which subscribers express their interest by specifying conditions over the content of events they want to receive. A subscription is a query formed by a set of constraints usually in the form of name-value pairs of properties and basic comparison operators (=, <<=, >, >=) which identify valid events. A constraint may also be of the form of a regular expression.
In content-based publish-subscribe systems, events are not classified according to pre-defined criteria, but rather according to properties of the events themselves. Hence the correspondence between publishers and subscribers is on a per-event basis. The higher expressive power of a content-based system comes at the price of higher consumption of resources needed to calculate the set of interested subscribers for the each event.
Because a content-based publish-subscribe system inspects the content of each event in order to match with subscriptions, it is not possible to support full end-to-end encryption of the content of events. The content is temporarily decrypted while matching is performed. In a variant, however, it is possible to assign labels or descriptors to encrypted content to enable the system to identify the encrypted content by its label and to communicate the encrypted content without decrypting it until it reaches the watcher (who has been previously given the specific key to decrypt the encrypted content).
In addition, as shown schematically in
Although the present disclosure refers expressly to the “Global Positioning System” or “GPS”, it should be understood that the term “GPS” is being used expansively to include any satellite-based navigation-signal broadcast system, and would therefore include other systems used around the world including the Beidou (COMPASS) system being developed by China, the multi-national Galileo system being developed by the European Union, in collaboration with China, Israel, India, Morocco, Saudi Arabia and South Korea, Russia's GLONASS system, India's proposed Regional Navigational Satellite System (IRNSS), and Japan's proposed QZSS regional system. In lieu of, or in addition to, GPS, the wireless communications device may use another type of location-determining subsystem. Although GPS is the best way presently known for obtaining a current position fix, a different type of positioning subsystem or location-determining subsystem can be used, e.g. a radiolocation subsystem that determines its current location using radiolocation techniques, as will be elaborated below. In the main implementation, though, the GPS chipset 190 receives and processes signals from GPS satellites to generate latitude and longitude coordinates, thus making the device “location aware”.
In lieu of, or in addition to, GPS coordinates, the location of the device can be determined using triangulation of signals from in-range base towers, such as used for Wireless E911. Wireless Enhanced 911 services enable a cell phone or other wireless device to be located geographically using radiolocation techniques such as (i) angle of arrival (AOA) which entails locating the caller at the point where signals from two towers intersect; (ii) time difference of arrival (TDOA), which uses multilateration like GPS, except that the networks determine the time difference and therefore the distance from each tower; and (iii) location signature, which uses “fingerprinting” to store and recall patterns (such as multipath) which mobile phone signals exhibit at different locations in each cell. Other location-determining techniques (of varying granularity) can also be employed for the purposes of providing location-related presence data, such as, using the identity of the nearest base station, accessing data stored in a Home Location Register/Visitor Location Register (HLR/VLR), etc.
Irrespective of the location-determining technique that is employed, a wireless communications device with a location-determining subsystem, e.g. GPS chipset, can be configured to determine its current location and compare its current location against the location-based triggering conditions for suspending or resuming a subscription. A presence client executing on the wireless communications device can be programmed to generate a subscription-suspension message based on this triggering condition (or, alternatively, based on input received via a user input device such as a keyboard, touch-screen, voice-recognition subsystem, etc.)
The radiofrequency transceiver (e.g. RF chip 170) on the wireless communications device 100 then transmits the subscription-suspension message to a presence service to suspend the subscription. Specifically, the subscription-suspension message is transmitted over the air to a base station tower that passes the suspension message to the relay which, in turn, communicates the suspension message to the proxy node for forwarding, in turn, to the function node. As noted above, the function node processes the message, identifies the subscription to be suspended, and then suspends the subscription by rerouting notifications to the persistent data store where they are accumulated for subsequent retrieval when the subscription is resumed. Analogously, a subscription-resumption message can be generated by the device, either in response to manual user input or in response to detection of a triggering condition. The subscription-resumption message, just like the subscription-suspension message, is communicated to the function node via the base station, relay and proxy node.
In one implementation of this method, the act of validating the request to subscribe entails an act of determining which one or more of a plurality of elements of presence information the first user has authorized the second user to receive. In other words, the first user (the one who publishes his presence information) may authorize the second user to obtain all the presence information that he publishes or merely a subset of this information. In one implementation, the first user may authorize the second user to receive (watch) only certain attributes (elements) of the presence information while restricting access to other attributes. For example, the first user may allow the second user to be notified of the first user's mood and availability but not his location.
In a variant of this implementation, the user may define a set of conditions (e.g. time of day, location, mood, availability) that determine how much access the second user (watcher) may be granted. For example, the first user may specify that the second user may receive presence information pertaining to his mood and availability provided that the time of day is outside of normal working hours and that the location of the second user is within a certain radius of the first user.
In this manner, the first user may set up a highly nuanced set of conditions (in, for example, a watcher profile for the second user) that modulates the access to the presence information. The watcher profile may be statically defined (a set of specified conditions that the first user affirmatively stipulates) or dynamically defined (the conditions may change based on the first user's own presence information, e.g. location, mood, activity, etc., or based on the second user's presence information, or based on a combination of the first and second user's presence information). In like manner, the second user may also define his subscriptions using the same or similar sets of conditions to ensure that presence information is only received for elements/attributes of interest at times when these are relevant or meaningful to the second user (the watcher). This dynamic interaction between the published presence information and the subscription enables users of the presence system to interact much more efficiently than was heretofore possible using the rudimentary presence and rich presence technologies currently known in the art.
Furthermore, in one implementation of the novel presence system, each attribute (each element of presence information) is encrypted separately using a different key so that specific attributes can be shared individually and privately. Keys can be exchanged securely using Diffie-Hellman to one or more authorized watchers for each specific attribute for which an authorization has been granted. This represents a radically different privacy paradigm from what is proposed in RFC 3863 wherein presence information is instantiated as a single monolithic document. If a Presentity wants to apply privacy rules that result in a watcher being permitted to receive only a subset of the presence information then a new document must be created which does not contain private information. This requires filtering of the presence information to remove private data. Filtering would be required for each notification cycle and for each watcher, and then the entire presence document is sent to the watcher even if this contains potentially unneeded information. This is particularly inefficient for mobile clients. In contrast, the novel presence system described herein can encrypt each attribute separately and send only that attribute to the watcher while maintaining complete privacy for all other attributes.
The methods disclosed in the present specification can be implemented as coded instructions in a computer program product or computer readable medium. In other words, the computer program product or computer-readable medium stores software code to perform the foregoing methods when loaded into memory and executed on the microprocessor of one or more computing devices.
This new technology has been described in terms of specific implementations and configurations which are intended to be exemplary only. Persons of ordinary skill in the art will appreciate that variations, modifications and refinements may be made to the technology disclosed herein without departing from the inventive concept(s). The scope of the exclusive right sought is therefore intended to be limited solely by the appended claims.