Patent Application
20090106677
The present disclosure relates to presence services, and more particularly to a mechanism for publishing presence information within a presence service and a user interface for configuring same.
In computing, a presence service is a network service which accepts, stores and distributes presence information. Presence information is generally defined as information regarding the availability, willingness or capacity of a user for communication, e.g. by way of a communication system with which the presence service is associated. The communication system may for example be an instant messaging (IM) system or computer-based Voice over IP (VoIP) telephony system). In a typical arrangement, each user executes a software-based presence service client (a form of “presence user agent”) that is associated with, and in many cases integrated with, a communication system client (e.g. an IM client executing on an internet-connected personal computer). The presence service client may permit a presence user (the user of the presence service) to see whether other presence users in a user-specified set of contacts, commonly known as a “contact list”, “buddy list” or “friend list”, are currently on-line and available for communication. The availability of each contact may be indicated by way of a presence indicator such as “available”, “busy”, “idle”, “do not disturb”, or “out to lunch” for example. The current value of the presence indicator is based on presence information received from the presence service client of the contact. To keep these indicators substantially up to date, when a contact's presence service client detects that the value of its presence information has changed, it automatically reports (“publishes”) the changed information to other users of the presence service. Publishing is typically done by way of a central presence server. Specifically, an update regarding the changed presence information is sent to the presence server, which in turn relays the changed presence information to all connected users who have elected to receive such updates regarding that contact (i.e. have “subscribed” to the presence information of that contact). The presence service client of the contact which publishes the changed presence information is referred to as a presence entity or “presentity”. The presence service clients of the subscribing presence users who receive these updates are referred to as “watchers”.
A contact's presentity may publish its presence information according to a publish/subscribe model or a request-based model (each constituting a different “publishing mechanism”). In the publish/subscribe model, the presentity automatically publishes its presence information regardless of whether any watchers have subscribed to that presence information. For example, in a presence service having a central presence server, the presentity apprises the presence server every time that the presentity's presence information changes. If no watchers have subscribed to that presence information, that information is not relayed to any watchers. Thus, in the absence of any subscribed watchers, the periodic publication of changed presence information by the presentity is, disadvantageously, wasteful of bandwidth between the presentity and the presence server, since there are no consumers of that information. The amount of wasted bandwidth may be particularly high when the size of the presence information is large or when the frequency of updates is high. Wasted bandwidth may disadvantageously increase service charges in the case where such charges are based, at least in part, on the amount of the bandwidth consumed. Another shortcoming associated with the publish/subscribe model can arise when the presentity restricts the set of presence information that it publishes over time. For example, a presentity may initially publish presence information comprising two presence attributes: user status (e.g. “do not disturb”, “out to lunch”, etc.) and device status (e.g. “in coverage range”, “out of coverage range”, these values assume that the presence service client executes on a wireless communication device that may occasionally be out of wireless network coverage). Later, the presentity may unilaterally decide to cease publishing device status information. Because the presentity does not know which watchers, if any, have subscribed to its presence information nor which attributes have been subscribed to, it has no way of knowing whether any watchers will be impacted by this decision. If any watchers have subscribed to a presence attribute that ceased being published, the watcher may fail to appreciate why the delivery of updates regarding the relevant presence indicator has suddenly ceased.
In the request-based model, the presentity only publishes its presence information if at least one watcher has subscribed to that presence information. Moreover, it only publishes the presence attributes to which at least one watcher has subscribed. For example, the presence information of a presentity may include two presence attributes, user status and device status, as described above. A watcher may subscribe to only the user status presence attribute but not the device status presence attribute. The presentity is apprised of this subscription, as it is apprised of all subscriptions to any of its presence attributes. If the watcher is the first to subscribe to any presence attribute of the presentity, the subscription causes the presentity to begin publishing only the presence attribute of interest (i.e. user status). Publishing may entail apprising a central presence server every time the presence attribute changes. If another watcher later subscribes to only the other presence attribute, the presentity is apprised of that subscription as well and, in response, now begins publishing the device status attribute in addition to the user status attribute. It should be noted that the presence server sends presence updates to each subscriber regarding only the presence attribute(s) of interest to that subscriber, e.g. regarding only user status attribute to the first subscriber and regarding only the device status attribute to the second subscriber. Because the presentity publishes only the presence attributes to which at least one watcher has subscribed in the request-based model, less bandwidth is wasted between the presentity and the presence server than in the publish/subscribe model. However, the request-based model may have other shortcomings. For example, the worst-case latency between a watcher's subscription to a presentity's presence attribute and the watcher's receipt of the current value of that presence attribute may be higher than in the publish/subscribe model. This is by virtue of the fact that, if the watcher is the first subscriber to a presence attribute, publication of the present attribute does not commence until the presentity has been notified of the subscription. The notification step introduces delay in this scenario that may not exist in the publish/subscribe model. As well, the monitoring of watcher subscriptions in the request-based model generally increases system complexity as compared with the publish/subscribe model, in which watcher subscriptions are not monitored. The resultant additional system overhead at the presence server and presentity can negatively impact the performance, reliability and scalability of presence services using the request-based model.
An alternative mechanism for publishing presence information would be desirable.
In the figures which illustrate an exemplary embodiment:
In one aspect of the present embodiment, there is provided a method of publishing presence information of a presentity within a presence service, the presence information including a first presence attribute and a second presence attribute, the method comprising: publishing the first presence attribute within the presence service only if at least one watcher within the presence service has subscribed to the first presence attribute; and further publishing the second presence attribute within the presence service regardless of whether any watcher within the presence service has subscribed to the second presence attribute, said publishing and said further publishing both occurring during a connection of said presentity with said presence service.
In another aspect of the present embodiment there is provided a machine-readable medium storing instructions which, when executed by a processor of a computing device, adapt the computing device to: publish a first presence attribute of a presentity within a presence service, the publishing occurring only if at least one watcher within the presence service has subscribed to the first presence attribute; and further publish a second presence attribute of the presentity within the presence service, the further publishing occurring regardless of whether any watcher within the presence service has subscribed to the second presence attribute, said publishing and said further publishing both occurring during a connection of said presentity with said presence service.
In another aspect of the present embodiment there is provided a computing device comprising: a processor; and memory storing executable instructions which, when executed by the processor, adapt the computing device to: publish a first presence attribute of a presentity within a presence service, the publishing occurring only if at least one watcher within the presence service has subscribed to the first presence attribute; and further publish a second presence attribute of the presentity within the presence service, the further publishing occurring regardless of whether any watcher within the presence service has subscribed to the second presence attribute, said publishing and said further publishing both occurring during a connection of said presentity with said presence service.
In another aspect of the present embodiment there is provided a method comprising: at a computing device having a display, presenting a user interface on the display, the user interface comprising: for each presence attribute comprising presence information of a presentity within a presence service, a user interface control permitting selection of the publication mechanism for that presence attribute within the presence service, the user interface control having a plurality of options, the options including: a first option for causing the presence attribute to be published only if at least one watcher within the presence service has subscribed to the presence attribute; and a second option for causing the presence attribute to be published regardless of whether any watcher within the presence service has subscribed to the presence attribute.
In another aspect of the present embodiment there is provided a machine-readable medium storing instructions which, when executed by a processor of a computing device having a display, cause the computing device to present a user interface on the display, the user interface comprising: for each presence attribute comprising presence information of a presentity within a presence service, a user interface control permitting selection of the publication mechanism for that presence attribute within the presence service, the user interface control having a plurality of options, the options including: a first option for causing the presence attribute to be published only if at least one watcher within the presence service has subscribed to the presence attribute; and a second option for causing the presence attribute to be published regardless of whether any watcher within the presence service has subscribed to the presence attribute.
As shown in
In the illustrated embodiment, presentity 14 and watcher 16 are each understood to be components of a software application, which is referred to as a presence service client. As is typical, one instance of the presence service client is executed at computing device 20 while another instance of the same presence service client is executed at computing device 24. For clarity, only the presentity component is shown at computing device 20 and only the watcher component is shown at computing device 24. The presence service clients may be subsumed within communication system clients, such as IM clients for example.
In the illustrated embodiment, each computing device 20, 24 executing presence service client software is a wireless communication device, such as a two-way pager, personal digital assistant (PDA), cellular phone, smart phone, portable computer or the like. Each wireless communication device includes a processor interconnected with memory, an input device (e.g. a keypad or keyboard), and an output device such as a liquid crystal display, none of which are expressly illustrated in
Each wireless communication device 20, 24 includes a communication subsystem comprising a receiver, a transmitter, and one or more antennas (not expressly shown). The communication subsystem permits the device to communicate with presence server 12 over a wireless data network. The wireless network communication may be relayed over a conventional wired data network via a gateway, in order to arrive at presence server 12, however this is not a central aspect of the present description. The specific design and implementation of the communication subsystem at the wireless communication devices 20, 24 is dependent upon the wireless network over which the wireless communication device is intended to communicate (e.g. Mobitex™, DataTAC™ or General Packet Radio Service (GPRS) mobile data communication networks).
Operation of the present embodiment is illustrated in
Referring to
After both users have subscribed to the presence service, the presentity 14 and watcher 16 each connect to the presence service 10 (S206 and S208, respectively). In the case where presence service 10 is part of an IM service, connection may require Tom and Jennifer to each log into the IM service, e.g., by specifying the username and password chosen during subscription. It is noted that neither Tom nor Jennifer has yet indicated any desire to receive the presence information of the other.
At this stage Tom configures the format of the presence information 18 of presentity 14 by selecting the presence attributes that shall comprise that information (S210). This configuration constitutes operation of phase I. Configuration may be achieved by selecting the presence attributes A1, A2 from a set of all possible presence attributes which the presentity 14 could possibly share with other users. For example, Tom may select the presence attributes from a template provided by the provider of the presence service 10 (e.g. an IM service provider) through a GUI. Alternatively, a service provider or network operator could specify default presence attributes. The template may be a markup language document enumerating a variety of different presence attributes, which may be of the types listed in Appendix A.
In the present example, it is assumed that Tom selects two presence attributes to comprise presence information 18: user status (attribute A1) and communication status (attribute A2). These attributes are described in more detail below.
The user status attribute A1 reflects the willingness of Tom to communicate. In the present embodiment, this attribute includes both a textual willingness indicator (e.g. “available”, “out to lunch”, “do not disturb”, etc.) and an icon visually reflecting the current willingness level.
The communication status attribute A2 indicates the current communication status of the computing device 20 at which presentity 14 of Tom executes. This attribute includes a device status indicator (e.g. “in coverage”, “out of coverage”, etc.) and location information, namely, latitude and longitude. Location information may be specific to embodiments in which the computing device upon which the presentity executes is wireless or portable, as in the present embodiment.
As part of operation S210, Tom also specifies a publication mechanism for each presence attribute that he has selected as part of his presence information 18, i.e., for each of presence attributes A1 and A2. In particular, Tom interacts with the presence service client software at computing device 20, using the input device of computer device 20, to cause the graphical user interface (GUI) 300 of
Referring to
In the example of
In the present embodiment, the presence information format and the user-configured publication mechanism for each presence attribute are captured within a single Extensible Markup Language (XML) document.
Referring to
The exemplary XML document 400 of
For efficiency, the default publication mechanism specified in the <presenceInfo> element may represent the publication mechanism that is the most common among the multiple subordinate presence attributes represented in document 400. This may limit the number of overriding presenceServiceType attributes that must be specified within the document 400, which may in turn advantageously limit the size of the document.
With the exception of setting the presenceServiceType attribute using the approach described above, the remaining content of XML document 400 may be determined based on the presence attributes that the presentity 14 elects to publish. For example, the XML elements representing presence attribute A1 and presence attribute A2 may be copied from a template or “master” XML document, which contains not only the XML elements representing attributes A1 and A2 but also XML elements representing other presence attributes that are not currently maintained at presentity 14. Should the presence attributes maintained by presentity 14 change in the future, the substance of document 400 may be updated, e.g., by deleting the XML elements pertaining to any presence attributes that are no longer maintained and by copying XML elements pertaining to newly elected presence attributes from the master document. XML document 400 may be stored, for example, on device 20, or at the presence server 12.
It is noted that none of the elements within the XML document 400 have any values. This is consistent with the role of document 400 as a model for the subsequent publication of presence information 18 by presentity 14. As will become apparent, when the presentity publishes its presence information (e.g. upon the occurrence of a change in the presence information), publication is done by way of an XML document that is modelled after XML document 400 but in which the XML elements have values representing current values of presence information 18.
Upon the completion of operation phase I (S210 of
Operation phase II begins when presentity 14 begins publishing only those presence attributes for which the publish/subscribe model has been elected (
It is assumed that Jennifer now interacts with her presence service client at computing device 24 (
Thereafter, the presence attributes elected by Jennifer are communicated to the presence server 12 (S216). This may occur automatically after Jennifer has confirmed her selections in S214, for example. When presence server 12 receives the communication (S216), two actions are triggered.
First, for all of the selected presence attributes of presentity 14 that were earlier configured for publishing according to the publish/subscribe model (in S210), a communication is immediately sent from presence server 12 back to watcher 16 to convey the current value of those presence attributes (as most recently received from presentity 14). This tends to limit the worst-case latency between a watcher's subscription to the presentity's presence attribute and the watcher's receipt of the current value of that presence attribute. In the present example, the latest value of presence attribute A2 is accordingly communicated from the presence server 12 to watcher 16 (S218). This value may have a format similar to XML document 500 of
Second, the presence server 12 sends a communication to presentity 14 identifying the presence attributes to which Jennifer has subscribed (S220). In the present embodiment, this communication identifies all the presence attributes to which Jennifer has subscribed, regardless of whether they are to be published according to the publish/subscribe model or the request-based model. This is to ensure that the presentity 14 is made aware of all watchers who have subscribed to any of its presence attributes, regardless of the publication mechanism by which the attributes are published. This information may be of use should presentity 14 later wish to cease publishing any of its presence attributes, in which case the presentity 14 can base its decision of whether or not to do so upon whether any watchers, and/or how many watchers and which ones, would be impacted (alternatively, or in conjunction, presentity 14 may at least notify the impacted watchers before ceasing publication of one or more of its presence attributes). This aspect of the present embodiment, i.e. notifying a presentity of the identity of any watchers who have subscribed to its presence information even in the case where the publish/subscribe model is being used to publish the presence information, is one way in which presence service 10 is distinguishable from conventional presence services.
It is assumed that presentity 14 authorizes (i.e. confirms) the subscription by watcher 16 to presence attribute A1 (i.e. to the presence attribute that is being published according to the request-based model). The authorization may be performed automatically by presentity 14, e.g., merely by virtue of the fact that Jennifer is in Tom's contact list. In other words, one's contact list may represent the users with whom one implicitly agrees to share one's presence information. The authorization is communicated to the presence server 12 (S222), which in turn communicates the authorization to watcher 16 (S224). In the present embodiment, no authorization is required for presence attribute A2 because it is being published according to the publish/subscribe model. In some embodiments, authorization for presence attributes published according to the publish/subscribe model may be automatically provided by the presence server 12 based on an earlier pre-configuration of the presence server 12 by presentity 14 with the identity of a group of watchers for which authorization should be automatically provided.
Now that at least one subscriber has subscribed to presence attribute A1, presentity 14 begins publishing that presence attribute (
The presence service 10 now enters a stage of operation in which presence information 18 is published, as described above in conjunction with operation S226 and S228, whenever either of presence attributes A1 or A2 changes. This stage is represented in
At a later point in time, Jennifer interacts with her presence service client at computing device 24 in order to cause watcher 16 to unsubscribe to both presence attributes A1 and A2 of presentity 14 (
In some embodiments, in place of continued publication in the absence of any real watchers (as at S240, or if no watchers are presently connected to presence service 10), presentity 14 may refrain from publishing presence updates to the presence server 12 even for presence attributes for which the publish/subscribe model was specified. This may be done to avoid unnecessary bandwidth consumption between presentity 14 and presence server 12. Of course, if watchers frequently change their connection status from connected to disconnected and vice-versa, the presence server 12 and presentity 14 may disadvantageously have significant overhead in monitoring the statuses of the watchers and activating/deactivating presence information publishing.
It will be appreciated that, in the present embodiment, each presentity can be configured to publish its presence information independent from every other presentity. Thus Jennifer could configure her presentity (not shown) to publish presence information differently from the manner in which presentity 14 publishes its presence information.
As should now be appreciated, the capacity of each presentity to select the publication mechanism for its presence information on an attribute-by-attribute basis promotes certain efficiencies within the presence service 10. However, the determination of which publication mechanism is most efficient for a particular presence attribute or a particular presence service may be situation-specific.
For example, if a presentity has a presence attribute that either requires much bandwidth to communicate (e.g. an avatar), changes frequently, or both, then the request-based model may be preferred for that presence attribute. The reason is that the size of the presence attribute and/or the high frequency of its changes is such that, when the presentity publishes updates to a presence server, significant bandwidth may be consumed between the presentity and the presence server. In the request-based model, publishing is only done if at least one watcher has subscribed to the attribute, thus bandwidth is not wasted when no watchers have subscribed to the attribute.
Alternatively, if it is important for the worst-case latency between a watcher's subscription to a presence attribute of a presentity and its receipt of the current value of that presence attribute to be minimal, then the publish/subscribe model may be preferred for that attribute.
For clarity, it is noted that some of the above-noted efficiency advantages may not be immediately apparent from the perspective of a watcher in an exemplary presence service. For example, the watcher may not be able to detect any improved efficiencies in the utilization of the network(s) between a presentity and a presence server in the form of a change in behaviour of his presence service client. Other advantages may however be more apparent. For example, the watcher may be able to detect the low latency between its subscription to a presence attribute and its receipt of the current value of that presence attribute, when the attribute is published according to the publish/subscribe model versus the request based model, and when the watcher is the first subscriber to that attribute.
It should be appreciated that presentity 14 could be configured so that each presence attribute is published according to the publish/subscribe model or so that each presence attribute is published according to the request-based model, in addition to the above-described “hybrid” combination of both publishing mechanisms. This provides flexibility for adopting whatever publishing mechanism(s) is/are most efficient or suitable for the presence service or presence information in question.
As will be appreciated by those skilled in the art, modifications can be made to the above-described embodiment without departing from the essence of the invention. For example, computing devices 20, 24 described above as wireless communication devices. In alternative embodiments, the computing devices could be any type of computing device capable of operating as described herein, including, without limitation, personal computers, workstations, web appliances, or the like. The devices need not be wireless or portable in all embodiments.
It should also be appreciate that above-described embodiment may be associated with a communication system other than an instant messaging system or VoIP system, such as a two-way paging system, push-to-talk system, group chat system or content sharing system for example.
In another alternative, configuration of the publication mechanism for presence attributes comprising the presence information of a presentity may not be performed by the presence user of that presentity. The configuration could be performed by a system administrator of the presence service or wireless service provider for example. The configuration of individual presentities may be automatic and centrally administered to be consistent from presentity to presentity.
In some embodiments, the communication S220 is limited to identifying only the presence attributes to which Jennifer has subscribed which the presentity 14 is publishing using the request-based model. The reason for this limitation is that presentity 14 may not need to authorize watcher subscriptions to presence attributes that are being published according to the publish/subscribe model in those embodiments. This limitation may advantageously reduce bandwidth usage between presence server 12 and presentity 14. The latter advantage may however come at the cost of restricting the ability of presentity 14 of being able to identify or apprise impacted watchers in the event that presentity 14 wishes to cease publishing a presence attribute that is being published according to the publish/subscribe model.
In some embodiments, the presentity 14 may grant presence server 12 the authority to authorize watcher subscriptions to some or all of the presentity's presence attributes on its behalf. This grant of authority may for example be effected through a presence service client configuration setting elected by Tom or the presence service provider. In such embodiments, the presence server 12 can authorize to watcher subscription requests during operation phase II without having to consult presentity 14. This may be referred to as “proactive authorization”, as distinguished from “reactive authorization” in which the presentity itself provides the authorization.
In some embodiments, the presence server stores an XML document like document 400 for each presentity in the service, rather than having the watcher maintain an XML document like document 400 for each presentity in the service. Thus two types of presence attribute configurations may be maintained by the server: a publication presence attribute configuration for each presentity in the presence service and a notification presence attribute configuration for each watcher in the presence service.
Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
1For the wireless networks, GPS is usually used to provide the device-derived location at a mobile device.
2Data model indicates person, service or device.
3RPID well defines the enumerated values for the mood attribute. Refer to RPID.
4“xa” indicates extended away.
5recently in coverage means that it was in coverage in the last X minutes (e.g. X = 30).
6recently out of coverage means that it was out of coverage in the last Y minutes (e.g. Y = 30)
7in poor coverage means that it has changed coverage state Z+ times within the last AA min. (e.g. Z = 3 and A = 30).
