Methods and Systems for Aggregating Presence Information to Provide a Simplified Unified Presence

FIELD

0001The present application relates to methods, systems, and devices for providing simplified presence information for a user.

BACKGROUND

0002One of the trends in communications is toward providing enriched presence information to third parties regarding a user's availability. For example, H. Schulzrinne, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)”, RFC 4480, July 2006, describes extensions to presence models that enable dissemination of a user's “mood” and “activities”. Under such trends, third parties subscribing to a user's presence information may expect to receive a large quantity of data regarding the user.

0003Another trend in modern communications is toward the use of multiple devices for communications, and often for some of the same types of services. Many users have a home telephone, work telephone, one or more personal computers, one or more mobile devices, fax machines, and other such user devices. Any one of these user devices may provide multiples services. For example, a user may use his or her home telephone, work telephone, mobile devices, and, in some cases, personal computer to place or receive voice calls. In some cases those voice calls may be placed as conventional PSTN circuit-switched calls, cellular wireless calls, VoIP calls, etc., or combinations of these. Even VoIP calls may be made over different types of network connections, including WAN, WLAN, DSL, etc.

0004A complication that arises in the context of rich presence information with regard to multiple devices is that third parties may be given an excessive amount of information regarding the various devices on which the user may be available. This places the onus on the third party to decipher the presence information and select an appropriate device to which to direct a message or session request.

0005It would be advantageous to provide for improved methods and systems for simplifying presence in a multi-device context.

BRIEF DESCRIPTION OF THE DRAWINGS

0006Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

0007<figref idref="DRAWINGS">FIG. 1</figref> diagrammatically shows an example communication system;

0008<figref idref="DRAWINGS">FIG. 2</figref> diagrammatically illustrates one example scheme of aggregation for presence information;

0009<figref idref="DRAWINGS">FIG. 3</figref> diagrammatically shows an example classification system for use in aggregating presence information by service class;

0010<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> show an example aggregation of device state data into virtual device definitions; and

0011<figref idref="DRAWINGS">FIG. 5</figref> shows, in flowchart form, a method for aggregating presence information to provide a simplified unified presence.

0012Similar reference numerals may have been used in different figures to denote similar components.

DESCRIPTION OF EXAMPLE EMBODIMENTS

0013In one aspect, the present application describes a method of providing simplified presence for a user, the user having a plurality of associated communication devices and being registered with a communications server, each communication device enabling at least one communication service class, and the communications server having a user data entry associating the user with each of the plurality of communication devices. The method includes defining a virtual device associated with the user; receiving, at the communications server, presence information from at least two of the plurality of communication devices; aggregating the received presence information, the aggregated presence information indicating the service classes available from the aggregated at least two communication devices based on the received presence information; generating a virtual device presence document containing the aggregated presence information; and providing the virtual device presence document to a presence server as presence information associated with the user.

0014In another aspect, the present application describes a communications server for providing simplified presence for a user, the user having a plurality of associated communication devices, and each communication device enabling at least one communication service class. The communications server includes a network interface for connecting the server to an IP network; a memory storing a user data entry associating the user with each of the plurality of communication devices, and storing a virtual device definition in association with the user; a processor; and a presence manager executable by the processor. The presence manager is configured to receive presence information from at least two of the plurality of communication devices, aggregate the received presence information, the aggregated presence information indicating the service classes available from the aggregated at least two communication devices based on the received presence information, generate a virtual device presence document containing the aggregated presence information, and provide the virtual device presence document to a presence server as presence information associated with the user.

0015Embodiments of the present application are not limited to any particular operating system, mobile device architecture, server architecture, or computer programming language. Many of the example embodiments described herein relate to mobile devices; however, it will be appreciated that the present application is not limited to mobile devices and has application to a variety of user devices.

0016Reference is made herein to a “service class”. The term “service class” as used in this application is not necessarily related to the <service-class> tuple described in H. Schulzrinne, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)”, RFC 4480, July 2006, at section 3.10. The term “service class” in the present application may, in some embodiments, make use of the <class> element described by Schulzrinne at section 3.3, but not necessarily.

0017Reference is first made to <figref idref="DRAWINGS">FIG. 1</figref>, which diagrammatically shows an example communication system <b>10</b>. As will be discussed below, the system <b>10</b> provides for a full integration of local and remote IP-based communication devices, such as communication devices <b>70</b> (shown individually as <b>70</b><i>a, </i>. . . , <b>70</b><i>f</i>). In this example, the communication devices <b>70</b> include any device capable of IP-based communications. In one embodiment, the device <b>70</b><i>a </i>may be a mobile device configured to connect with a wireless local area network (WLAN) <b>40</b> through an access point using, for example, any one of the IEEE 802.11 suite of communications protocols. In another embodiment, the device <b>70</b><i>b </i>may be a personal computer or computing device including a Ethernet card configured to connect to an wide area network (WAN) <b>45</b>, for example via an internet service provider (ISP). In another embodiment, the device <b>70</b><i>c </i>may be a wireless mobile device configured to connect with a wireless wide area network (WWAN) <b>60</b> using any one or more of a number of radio protocols, such as GSM/GPRS/EDGE, UMTS, CDMA, WiMAX, etc. In yet other embodiments, an enterprise network <b>80</b> may include devices such as a digital desktop telephone set <b>70</b><i>d </i>and/or a personal computer <b>70</b><i>e. </i>Device <b>70</b><i>f </i>may be an IP-enabled home phone, for example, or another device configured to operated within a Next Generation Network (NGN) <b>86</b>, such as TISPAN NGN or HFC cable networks. Other communications devices <b>70</b> capable of IP-based messaging or session-based communications will be understood by those skilled in the art. It will be appreciated that combinations of these various embodiments (e.g., a home telephone, with business telephone and wireless mobile devices linked via IP to the same core network) are also possible.

0018Some of the devices <b>70</b> may be configured for messaging applications. Messaging applications may include text-based messaging, including SMS, E-mail, Instant Messaging (IM), etc., but may also include multi-media messaging, including images, video and/or audio. Some of the devices <b>70</b> may alternatively or additionally be configured for session-based communications. Session-based communications may include voice-over-IP (VoIP), but may also include chat, some IM services, Push-to-talk over Cellular (PoC), some webcasting, video conferencing, and other such multi-media services.

0019In the embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, the devices <b>70</b> are SIP-compliant. The devices <b>70</b> are capable of sending and receiving SIP message requests and responses to set up, tear down, and manage session-based communications. In other words, the compliant devices <b>70</b> are configured as SIP User Agents. Nevertheless, it will be appreciated that the present application is not necessarily limited to SIP-based embodiments. In some other embodiments (not shown), the devices may conform to another standard for session management.

0020In the present example embodiment, a user is associated with two or more devices <b>70</b>. For example, the user may be associated with devices <b>70</b><i>a, </i><b>70</b><i>b, </i><b>70</b><i>c, </i><b>70</b><i>d, </i><b>70</b><i>e, </i>and <b>70</b><i>f. </i>The particular user has a unique user address that the user may publish or disseminate to third parties to enable the third parties to contact the user. In some examples, the user address may include a unique number, such as a telephone number, or a unique name. The association between the user and the devices <b>70</b> may be realized as an association between the user address and the devices <b>70</b>, specifically, a unique device identifier for each of the associated devices <b>70</b>. In some embodiments, the device <b>70</b> to which the system <b>10</b> directs communications may be selected by the system <b>10</b> based on user preferences.

0021Each of the devices <b>70</b> is capable of communicating with an IP network <b>50</b>. The IP network <b>50</b> may, for example, be a WAN, such as the Internet. The IP network <b>50</b> may be a local area network (LAN), a municipal area network (MAN), or a Public IP network (e.g. IP Multimedia Subsystem) in some embodiments. In some embodiments, the devices <b>70</b> may reach the IP network <b>50</b> via the WLAN <b>40</b>, WAN <b>45</b>, WWAN <b>60</b>, enterprise network <b>80</b>, NGN <b>86</b>, and other networks.

0022In some embodiments, the IP network <b>50</b> and the WLAN <b>40</b>, WAN <b>45</b>, WWAN <b>60</b>, enterprise network <b>80</b>, and NGN <b>86</b>, may contain SIP elements <b>52</b>, <b>42</b>, <b>47</b>, <b>62</b>, <b>84</b> and <b>88</b>. SIP elements may include, for example, one or more SIP proxy servers for receiving and forwarding messaging to the devices <b>70</b>, one or more SIP registrars, location servers, DNS servers, back-to-back user agents, or other such SIP elements. The various networks <b>50</b>, <b>40</b>, <b>45</b>, <b>60</b>, <b>80</b>, <b>86</b> and SIP elements <b>52</b>, <b>42</b>, <b>47</b>, <b>62</b>, <b>84</b>, <b>88</b>, form a SIP/IP layer interconnecting the devices <b>70</b> and other user agents and servers. Alternatively, some or all of the SIP elements <b>52</b>, <b>42</b>, <b>47</b>, <b>62</b>, <b>84</b>, <b>88</b>, may be contained within the IP network <b>50</b> (e.g. IP Multimedia Subsystem) and the WLAN <b>40</b>, WAN <b>45</b>, WWAN <b>60</b>, NGN <b>86</b> and enterprise network <b>80</b> provide IP access to the SIP-enabled IP network <b>50</b>.

0023The system <b>10</b> includes a communication server <b>30</b>. The communication server <b>30</b> is connected to the IP network <b>50</b> and provides converged seamless messaging and session functionality and interoperability over multiple devices. In particular, the communication server <b>30</b> includes a control server <b>32</b>. The control server <b>32</b> provides the central logic and control for the communications server <b>30</b> and enforces both user preferences and service provider policies. The control server <b>32</b> participates in the control over the routing of messaging and the set-up, tear-down and management of sessions with the devices <b>70</b>. The control server may also store a log of the sessions (session history) or some other network entity may store the session history. Functions of the control server <b>32</b> are described in greater detail below.

0024The communication server <b>30</b> also includes media storage <b>34</b>. The media storage <b>34</b> is one or more databases containing stored media data relating to messaging or sessions. For example, the media storage <b>34</b> may include session history, messaging content, and metadata relating to content. The media storage <b>34</b> may apply privileges associated with a user or a resource. It may support synchronization operations in accordance with an applicable policy with regard to media stored on a client device <b>70</b>. In one embodiment a client device <b>70</b> may send on/off setting information that indicates whether to synchronize media between the device <b>70</b> and media storage <b>34</b>, for example, using SIP PUBLISH method. In another embodiment, the client device <b>70</b> may send a request to synchronize media between device <b>70</b> and media storage <b>34</b> and may receive a response from the server <b>30</b>, for example, using HTTP request/response or XCAP request/response as specified in RFC 4825. It may also enable user management of media content, including establishment of storage policies and the copying, deleting, uploading, downloading, managing of folders to store media content (e.g. creating, deleting, moving, modifying folders), or other operations with respect to media content.

0025The communication server <b>30</b> further includes user data entity <b>36</b>. The user data entity <b>36</b> may store user data associated with the devices <b>70</b>. For example, the user data may include associations between a user address and one or more of the devices <b>70</b>, or identifiers of the devices <b>70</b>. In many embodiments, a single user address is associated with multiple devices <b>70</b>. For example, the single user address may be associated with a plurality of unique device addresses specific to the associated devices <b>70</b>. This enables third parties to contact the user through a single user address without necessarily requiring knowledge of the specific device addresses. In some cases, the user need not have any knowledge of the specific device addresses and may only know his or her unique user address. Additional user-related data and functionality may be implemented in the user data entity <b>36</b>, such as contact information, media preferences, and user configuration settings. It will also be appreciated that the IP network <b>50</b> may store user data associated with the devices <b>70</b>. It will be appreciated that the control server <b>32</b>, media storage <b>34</b>, and user data entity <b>36</b> may be implemented in a variety of ways. For example, they may be implemented on separate servers or together on one server.

0026The communication system <b>10</b> may be connected to legacy networks, such as for example PSTN <b>16</b>, via an interworking entity <b>14</b>. The interworking entity <b>14</b> provides translation services for converting messages and signaling between the legacy network and the communication system <b>10</b>. For example, in one embodiment the interworking entity <b>14</b> is a PBX/IP-PBX connected to the PSTN <b>16</b> by primary rate interface (PRI) and to the IP network <b>50</b> by IP connection. In that example, voice media is converted from circuit-switched audio on the PSTN <b>16</b> side to voice-over-IP (VoIP) on the IP network <b>50</b> side by the interworking entity <b>14</b>. In another embodiment the interworking entity <b>14</b> is an IP-SM-GW (IP Short Message Gateway) that is interworking between SIP-based messaging and SMS. Other interworking entities <b>14</b> may perform similar translations of IP-based session or messaging data protocols to legacy or proprietary data protocols. For another example, in one embodiment the interworking entity <b>14</b> is connected to the communication server <b>30</b>.

0027The communication system <b>10</b> may be connected to one or more remote communication systems <b>90</b> having similar services and functionality. Messaging and sessions may cross multiple systems <b>10</b>, <b>90</b> and the respective control servers <b>32</b> may be configured to ensure interoperability of the cross-system communications.

0028It will be appreciated that the devices <b>70</b> are each configured to communicate with the communication server <b>30</b> using, for example, SIP compliant messaging. Details of one or more example devices are given below. In general, each device <b>70</b> includes a user interface, a processor, memory, and a “client” application for communicating with the communication server <b>30</b>. The devices <b>70</b> may further include messaging applications, multimedia applications, and other applications configured to compose, receive, present, or send messages or sessions with remote users. Example applications may include e-mail applications, instant messaging applications, text messaging applications, video conferencing applications, Push-to-Talk over cellular (PoC), and others.

0029Initially, the devices <b>70</b> each register with a SIP registrar, which may be one of the SIP elements <b>52</b> in IP network <b>50</b>. The devices <b>70</b> may directly contact the server <b>30</b> to indicate that they are registered. Alternatively the server <b>30</b> obtains information about the registration of devices <b>70</b> indirectly from the IP network <b>50</b> using the third party registration mechanism as defined in 3GPP TS 24.229 and/or the registration event package as defined in RFC 3680. The registration may be performed automatically, e.g. every time the device <b>70</b> is powered on or on a periodic basis, or it may occur manually on user selection. In another embodiment, the registration may be performed in response to a request from the server <b>30</b>, for example if the device <b>70</b> is required by the network to re-authenticate. The device <b>70</b> may contact the server <b>30</b> using a SIP-based message in some embodiments. In response, the server <b>30</b> sends a response data signal rejecting, failing or accepting the request. Once registered, the device <b>70</b> and server <b>30</b> may request information each other using data signals/messages.

0030As noted above, each user has at least one unique user address. The user address is a single unified contact address for reaching a user on any of his or her devices. In some embodiments, a user address may include a TEL URI (telephone number), SIP URI, SIPS URI, e-mail address, PNP telephone number, GRUU, or other addressing scheme. In one embodiment, the user address is a Public User Identity as defined in 3GPP TS 23.003. Irrespective of the format of the address, each user has two or more devices <b>70</b> associated with their user address. In this example embodiment an example user has six associated devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>This association is stored as user preference data in the SIP elements <b>52</b> or user data entity <b>36</b> of the communication server <b>30</b>. In particular, in some embodiments, the association is stored as an association between the unique user address and the specific device addresses of each of the associated devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>Accordingly, when the SIP elements <b>52</b> or server <b>30</b> receive messages or session data addressed to the user address, it is capable of identifying the device(s) <b>70</b> and/or device addresses to which the messages or session data may be relayed. The user preference data may specify logic rules or other criteria for determining to which device(s) <b>70</b> messages or session data should be sent.

0031In the present application, the system <b>10</b> may include a presence server <b>96</b>. One or more presence servers <b>98</b> may also, or alternatively, be accessible through the remote communication system <b>90</b>. The server <b>30</b> may receive presence information from a source of presence information, such as the presence servers <b>96</b>, <b>98</b>. The presence servers <b>96</b>, <b>98</b> may receive presence data from devices connected to the system <b>10</b> or the remote communication system <b>90</b>. The presence data reflects the availability and capabilities of the device and may be associated with a user of the device. In this regard, the presence servers <b>96</b>, <b>98</b> may have defined “presentities”, where a presentity is a complete picture of a user's presence status on the network. The presence servers <b>96</b>, <b>98</b> may generate and make available Presence Information Data Format (PIDF) documents or Rich Presence Information Data format (RPID) documents containing presence information for a particular user. Third parties interested in communicating with the particular user may obtain (in some cases, subscribe to) presence data from the presence servers <b>96</b>, <b>98</b> that indicates the availability of the particular user. The availability information may include information regarding the various devices associated with the user and their state of connectivity, the services provided by those devices. Further details regarding presence data models and PIDF and RPID documents may be found in IETF standards, including J. Rosenberg, “A data model for presence”, RFC 4479, July 2006 and H. Schulzrinne, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)”, RFC 4480, July 2006. In one embodiment, the presence server functionality may be implemented by the communication server <b>30</b>.

0032The delivery of messages or session data to the device(s) <b>70</b> may be wholly or partly based on presence information. It may also depend on the nature of the messages or session data and the corresponding capabilities of the device(s) <b>70</b>, as specified for example in predefined logic rules.

0033When an incoming message is received by the server <b>30</b> addressed to a user address, the server <b>30</b> may deliver the message or a message notification to one or more of the device(s) <b>70</b> based on the message characteristics (e.g. the type of media), the device capabilities, user preferences set in the user data entity <b>36</b>, and/or presence information. For example, the user preferences for a given user may specify to which of the devices <b>70</b><i>a</i>-<b>70</b><i>f </i>messages or message notifications should be delivered and/or when they should be delivered and when they should be queued for later delivery. By way of another example, the server <b>30</b> may deliver a message to a device <b>70</b>, such as wireless device <b>70</b><i>a, </i>containing video only if the device characteristics associated with wireless device <b>70</b><i>a </i>indicate sufficient processing speed and display resolution for a reasonable quality of service experience. It will be appreciated that many other factors may be taken into account in determining to which devices(s) <b>70</b> messages or message notifications are to be delivered.

0034The server <b>30</b> may also be configured to deliver an incoming session request addressed to the user address to one or more of the device(s) <b>70</b>. As with messages, the determination of which device(s) <b>70</b> are to receive the session invitation may be partly based on user preferences, device capabilities, nature of the media specified in the session request, service provider policy, presence, and other factors.

0035In one example, a session invitation is sent by a remote party to the server <b>30</b> addressed to the user address. The server <b>30</b> determines to which device(s) <b>70</b> the invitation ought to be directed. It then generates and sends a new session invitation to the identified device(s) <b>70</b>, such as a SIP INVITE message. The invitation may contain data regarding the remote party. The invitation may be sent simultaneously to more than one of the devices <b>70</b>, or it may be sent sequentially to more than one of the devices <b>70</b> if it goes unanswered at a first one of the devices <b>70</b>.

0036On receipt of the invitation, the device(s) <b>70</b> alerts the user to the incoming request, for example by audible, visual and/or vibratory indicators, and offers the user the opportunity to accept or reject the proposed session. If the user accepts the session, then the device <b>70</b> responds with an acceptance message to the remote party via the server <b>30</b>, such as a SIP 200 OK message. After the exchange of ACK messages, the session will be initiated over a first leg from the device <b>70</b> to the server <b>30</b> and a second leg from the server <b>30</b> to the remote party. It will be appreciated that the second leg may comprise a number of legs depending on the network architecture between the server <b>30</b> and the remote party. The server <b>30</b> substantially seamlessly connects the two legs to enable the exchange of media between the device <b>70</b> and the remote party.

0037In another example, a session may be initiated by the user from one of the devices <b>70</b>. Based on a user request input through a user interface, perhaps using a session-based application program like a video conferencing application, the device <b>70</b> generates and sends a session invitation addressed to a remote party. The session invitation is sent to the server <b>30</b>. The server <b>30</b> may assess whether the invitation request conforms to predetermined criteria, including user policies, service provider policies, or other such criteria. If acceptable, then the server <b>30</b> sends an invitation request to the remote party. If the session invitation is accepted by the remote party, the server <b>30</b> and device <b>70</b> complete set-up of the session between the device <b>70</b> and the server <b>30</b> and the server <b>30</b> completes set-up of the session between the server <b>30</b> and the remote party. The two legs of the session are substantially seamlessly connected by the server <b>30</b> to facilitate conduct of the session application between the device <b>70</b> and the remote party.

0038In these examples, the remote party may be a user/device within the system <b>10</b>, within a remote communications system <b>90</b>, or, in some instances, a legacy system like the PSTN 16.

0039Because the server <b>30</b> is involved in routing messages and establishing sessions on behalf of the devices <b>70</b>, it is capable of providing additional session functionality during an active session. For example, during the progress of an active session, the server <b>30</b> permits the device <b>70</b> to add or modify media within the session, add additional sessions (e.g. dialogs), etc. Using SIP signaling, the device <b>70</b> can send requests to the server <b>30</b> and the server <b>30</b> can initiate additional sessions, modify existing sessions, and otherwise manage the ongoing sessions.

0040The sessions may support any number of session-based applications, including VoIP, messaging, Push to Talk (PoC), etc. With respect to VoIP, video-conferencing, or other telephony-type services, the server <b>30</b> may support telephony-type functions or operations such as voicemail, universal voice mail notification, answer acknowledgement, extension dialing, session hold and retrieval, DTMF tones, caller ID, callback, call forwarding, call transfer, call waiting, mute, call blocking, call redial, call parking, speed dial, do not disturb (DND), DND bypass list, and DND list, among others.

0041In accordance with an embodiment, the user data entity <b>36</b> of server <b>30</b> may specify numerous system-defined user access rights and user modifiable preferences, which can alter the session handling described herein. Referring back to <figref idref="DRAWINGS">FIG. 1</figref>, a system administrator may set user access rights and priorities. The user may use any IP-enabled device capable of accessing the IP network <b>50</b> to set numerous user preferences. For example, the user may employ a Web-based or graphical user interface, e.g. a web browser application on a personal computer or mobile device, to access and set user preferences, alternatively XCAP may be used or SIP mechanisms such as SIP Publish or other SIP Methods.

0042It will be appreciated that the system <b>10</b> provides one user address for each user, which has several advantages. The single address may be, for example, the user's physical office extension DID telephone number (TEL URL), the user's SIP URI, SIPS URI, the user's e-mail address, GRUU, or any other such address. This user address will not have to be changed even when the user changes his devices <b>70</b>. In fact, if a system administrator or other personnel provides the user with a new device (and the number/address of the device is associated with the user address in the server <b>30</b>), the user may never need to know the actual device address of the new device. The user only needs to remember the user address regardless of which device he/she is using.

0043In some instances, the system <b>10</b> may use a Globally Routed User Agent URI (GRUU) to uniquely identify each device <b>70</b> despite the fact that each of a user's devices <b>70</b> share a common user address. In the context of SIP, GRUUs are described in J. Rosenberg, “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)”, Internet Engineering Task Force, Jun. 25, 2007 (hereinafter referred to as Rosenberg and hereby incorporated by reference in its entirety). A public GRUU is constructed by adding a “gr” URI parameter to the normal address of record (AOR) or user address. For example, a public GRUU may be: sip:bob@company.com;gr=kdf234rh48fj. A temporary GRUU may be constructed using algorithm in the registrar, and may take the form: sip:lkjwe23423kl324j234j332@company.com;gr. Each device obtains its GRUU from a SIP registrar in the system. In some embodiments, the SIP registrar may be implemented within the SIP elements <b>52</b>. The user preference information in the user data entity <b>36</b> that associates the devices <b>70</b> with the user address may include GRUU information.

0044Another published IETF standard, Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations”, RFC 3680, March 2004, details mechanisms by which a “watcher” can obtain information from a SIP registrar, including registered contact information. Draft guidelines have been published to detail an extension to the registration event package for obtaining GRUU information from a SIP registrar: Kyzivat, P., “Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)”, Internet Engineering Task Force, Jul. 6, 2007 (hereinafter referred to as Kyzivat and hereby incorporated by reference in its entirety). Together, these documents define SIP protocols for obtaining GRUU information from SIP registrars for an address of record. Accordingly, the server <b>30</b> may be configured to use these SIP registration event protocols to obtain GRUU information from SIP registrars within the system <b>10</b> regarding the devices <b>70</b> associated with a user address. In this manner, the server <b>30</b>, and in particular the user data entity <b>36</b>, may obtain up-to-date contact information, including GRUUs, for each of the devices <b>70</b> registered with the system <b>10</b> and associated with the user address.

0045The server <b>30</b> obtains the GRUUs for each device <b>70</b> using the mechanism in “Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)”. The user preferences contain the GRUU or GRUUs to which requests that meet particular criteria should be routed. The Public GRUU contains the user address as well as an identifier in the gr parameter that uniquely identifies the specific device instance.

0046The user or system <b>10</b> can publish this single user address (as opposed to the multiple numbers/addresses associated with the many devices the user can associate with his/her account), for example, in business cards, user profile on a website, telephone directories, etc. In the case of telephony-based sessions, this user address can be placed into the ANI/DNIS information of placed calls, which helps mask the physical telephone number of the device <b>70</b> from the other party on the call. More generically, the user address may be reflected in the SIP header information of SIP messages sent from the server <b>30</b> to remote parties, thereby masking the contact details of the device(s) <b>70</b> participating in the session. This also means that people or organizations attempting to contact the user only require the single user address, which is particularly advantageous.

0047For dual mode devices, there is often a telephone or contact number associated with the cellular mode of the device and a separate, different address or contact number associated with the data/WiFi mode of the device. When the user is registered with the server <b>30</b> the user does not need to know either number. In operation, the server <b>30</b> may use the cellular and WiFi modes of the device as two separate interfaces for establishing sessions.

0048In the example embodiment of <figref idref="DRAWINGS">FIG. 1</figref>, the presence servers <b>96</b>, <b>98</b> may receive presence information relating to the user of the devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>One of the presence servers, for example presence server <b>96</b>, may create and maintain a “presentity” detailing the availability of the user. A third party wishing to contact the user may subscribe to the presentity (using a Presentity URI, as described in RFC 4479) so as to obtain up-to-date presence information regarding the user.

0049In a conventional presence configuration, the presence server <b>96</b> might receive presence information directly from the devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>The devices <b>70</b><i>a</i>-<b>70</b><i>f </i>may publish their state using, for example, SIP PUBLISH or similar mechanisms. Reference may be made to IETF standard A. Niemi, “Session Initiation Protocol (SIP) Extension for Event State Publication”, RFC 3903, October 2004. In this configuration, the presence server <b>96</b> independently receives state information for each of the devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and consolidates this information into presence document(s). The presence server <b>96</b> might have a stored association between the user and the devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and may, on this basis, consolidate the presence information for all the devices into a single presence document for distribution to subscribers. In such a configuration, the presence server <b>96</b> operates entirely independently of the communications server <b>30</b>. This configuration may lead to complications and confusion, as third parties may be provided with excessive detail regarding the actual devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and their addresses by the presence server <b>96</b>, whereas the communication server <b>30</b> is configured to disguise that detail behind a unified single user address.

0050In accordance with one embodiment, the communication server <b>30</b> may be configured to gather presence data with regard to the various devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and report the data to the presence server <b>96</b>. Mechanisms such as SIP PUBLISH may be used by the devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and the communications server <b>30</b> to obtain up-to-date state information for each of the devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>In this regard, the control server <b>32</b> may include a presence manager <b>38</b> for receiving state information from the devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and reporting the state information to the presence server <b>96</b>.

0051In order to provide third parties with a unified and simplified view of user availability, the presence manager <b>38</b> may be configured to aggregate state information for the various devices <b>70</b><i>a</i>-<b>70</b><i>f </i>and to report unified or aggregate presence information to the presence server <b>96</b>, as will be described in greater detail below. In other words, the presence manager <b>38</b> gathers state information for a user's devices, aggregates the data to create a unified depiction of the user's availability, and then reports the unified availability information to a presence server <b>96</b>, <b>98</b>.

0052In order to disguise the device details behind the unified availability information, and present a singular unified view of a user's availability, the presence manager <b>38</b> or other elements within the communication server <b>30</b>, defines a “virtual device” associated with the user. The presence manager <b>38</b> reports or publishes presence information regarding the “virtual device” associated with the user, rather than presence information for the individual devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>In a SIP-based implementation, the communications server <b>30</b> may be said to be emulating a SIP User Agent having the characteristics and state information of the aggregated user devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>The presence server <b>96</b> is aware only of the “virtual” device associated with the user. Thus, third parties that subscribe to notifications regarding the availability of the user from the presence server <b>36</b> are provided with presence data for the “virtual device”. This has the added benefit of placing the communications server <b>30</b> in control of the state and availability details made available to third parties. This allows the communications server <b>30</b> to filter information in accordance with user or administrator preferences, and allows the communications server <b>30</b> to route session requests or other messaging based on its policies and preferences, rather than based on a third party's selection of a particular one of the devices <b>70</b><i>a</i>-<b>70</b><i>f. </i>

0053The effect of this configuration is that a third party that subscribes to a user's presence information (for example, by including the user on a “buddy list”), will be aware of the user's availability for certain types or classes of communication/service; but not the individual devices <b>70</b><i>a</i>-<b>70</b><i>f </i>or their addresses on which the user is presently available. From the point of view of the third party, the user has a single device, the service characteristics of which may fluctuate to reflect the user's availability for certain classes of communication services.

0054Reference may be made to <figref idref="DRAWINGS">FIG. 2</figref>, which diagrammatically illustrates one example scheme of aggregation in accordance with the present application. An example user may have four associated devices <b>170</b><i>a, </i><b>170</b><i>b, </i><b>170</b><i>c, </i>and <b>170</b><i>d. </i>Device <b>170</b><i>a </i>may be a personal computer configured to connect to an IP network. The computer may include various software applications, including a voice-over-IP (VoIP) application, an instant messaging (IM) application, a videoconference application, and a messaging application. The messaging application may be an e-mail application, for example.

0055Device <b>170</b><i>b </i>may be a dual-mode handheld mobile device configured for voice communications in either WLAN or WAN networks. The device <b>170</b><i>b </i>may include a voice application (or two separate voice applications) for voice communications. The voice application may be configured to use the cellular interface when the device <b>170</b><i>b </i>is connected to a WAN, and the VoIP interface when the device <b>170</b><i>b </i>is connected to a WLAN. In some instances, the voice application may be configured to use VoIP over the WAN connection where IP connectivity can be established. The selection between VoIP or cellular operation and the use of WAN or WLAN connectivity in the case of a dual-mode mobile device will be familiar to those of ordinary skill in the art. The device <b>170</b><i>b </i>may also include one or more messaging applications, including an e-mail application, SMS application, and MMS application. In some instances, e-mail, SMS and MMS functionality may be provided by a single messaging application; in other instances the functionality may be implemented using separate modules or applications. The various messaging functions may be integrated into a unified messaging user interface on the device <b>170</b><i>b. </i>The various possible embodiments of a dual-mode mobile device having voice and messaging functions will be understood by those skilled in the art.

0056Device <b>170</b><i>c </i>may be a desktop office telephone with basic voice functionality. Device <b>170</b><i>d </i>may be a fax machine connected, for example, to an enterprise network.

0057It will be appreciated that the devices <b>170</b><i>a</i>-<b>170</b><i>d </i>are illustrative examples only and are not intended to limit the scope of the present application to such devices or devices having only these characteristics.

0058<figref idref="DRAWINGS">FIG. 3</figref> diagrammatically shows an example classification system <b>200</b> for use in aggregating presence information by service class. In this example, four service classes are defined: voice <b>202</b>, video <b>204</b>, text <b>206</b>, and imaging <b>208</b>. The voice service class <b>202</b> may include services such as VoIP and conventional circuit-switched telephony. The video service class <b>204</b> may include services like videoconferencing and/or videostreaming. The text service class <b>206</b> may include text-based communication services such as SMS, IM, and e-mail. The imaging service class <b>208</b> may include services such as MMS and facsimile. Additional classes and/or services may be included in the classification system <b>200</b>.

0059The classification system <b>200</b> abstracts away from specific services to a class of service. In one sense, the service classes <b>202</b>-<b>208</b> indicate the nature of the services, but not the specific type of application for providing that service.

0060Some applications may offer more than one service. For example, a videoconferencing application may be considered to be both videoconferencing and VoIP. The application might also allow for IM on top of the video session. Other example combinations are possible. In this case, a single application may fall into more than one service class. In other words, a device having such an application may be described as offering multiple service classes.

0061It will be understood that fewer or more classes may be included in other examples, and that different classifications can be used to groups services in a different manner or according to different characteristics.

0062Reference is now also made to <figref idref="DRAWINGS">FIGS. 4A and 4B</figref>. <figref idref="DRAWINGS">FIG. 4A</figref> illustrates an example aggregation of device state data <b>302</b> into a virtual device definition <b>304</b>. In this example, devices <b>170</b><i>b, </i><b>170</b><i>d </i>and <b>170</b><i>c </i>from <figref idref="DRAWINGS">FIG. 2</figref> report their presence to the communications server <b>30</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and, in particular, to the presence manager <b>38</b> (<figref idref="DRAWINGS">FIG. 1</figref>). In some embodiments, the information reported from the devices <b>170</b> to the presence manager <b>38</b> may include the device's availability (e.g. connected, busy, etc.). In some embodiments, the devices <b>170</b> also communicate service information, such as the applications available and/or the service classes available. In other embodiments, the presence manager <b>38</b> may already have some information about a device's capabilities or services. For example, the presence manager <b>38</b> may obtain stored device service data from the user data entity <b>36</b> (<figref idref="DRAWINGS">FIG. 1</figref>).

0063To illustrate an example, the dual-mode mobile device <b>170</b><i>b </i>may be connected via a WAN and may report to the presence manager <b>38</b> that it has WAN connectivity. From this, the presence manager <b>38</b> may, in some embodiments, conclude that the device <b>170</b><i>b </i>is available for cellular telephony, SMS, and e-mail. To reach this conclusion, the presence manager <b>38</b> reads device-specific data from the user data entity <b>36</b> that indicates the applications and/or services available on the device <b>170</b><i>b </i>when the device <b>170</b><i>b </i>has WAN connectivity.

0064In another example, the device <b>170</b><i>b </i>may include its application/service information in its reporting communication to the presence manager <b>38</b>. For example, it may inform the presence manager <b>38</b> that it has voice and text service classes available. In another embodiment, it may inform the presence manager <b>38</b> that it is currently available for cellular telephony, SMS and e-mail services.

0065It will be appreciated that the devices <b>170</b> provide some level of information to the presence manager <b>38</b> regarding their availability. The presence manager <b>38</b> may or may not have stored data regarding each device's capabilities that it may draw on to obtain a more complete picture of the device's capabilities. In any event, the presence manager <b>38</b> receives or deduces service availability information for each of the devices <b>170</b>.

0066Those ordinarily skilled in the art will appreciated the various mechanisms and processes for developing and reporting presence information. For example, in some instances, GPS-based location information obtained from a user's mobile phone may impact the determination of the “presence” status of home or office equipment (based on the user's proximity to same). The present application is not intended to be limited to any particular type of presence data or information. The data reported from the devices <b>170</b> to the presence manager <b>38</b> may include any useful information for making presence assessments with regard to the individual devices <b>170</b>.

0067The presence manager <b>38</b> defines a “virtual device”. The virtual device is associated with the user of the devices <b>170</b>. In this regard the virtual device definition <b>304</b> may be stored in memory on the communications server <b>30</b> in association with the user, for example by reference to the user address. The virtual device definition <b>304</b> includes device capability/availability/willingness information. This “presence” information is created by aggregating the presence information received from the devices <b>170</b>. In particular, the presence information is aggregated across service classes, thereby developing a unified device picture of service classes available for reaching the user.

0068For example, with reference to <figref idref="DRAWINGS">FIG. 4A</figref>, if devices <b>170</b><i>b, </i><b>170</b><i>d, </i>and <b>170</b><i>c </i>all report the presence information listed in the figure, then the virtual device definition <b>304</b> contains the aggregated presence information. The aggregated presence information reflects that the user is available for voice, text or imaging services and the user is willing to show such services are available to use. In some cases, the virtual definition may retain the application type, such as SMS or e-mail under the “text” service class or the virtual definition may retain the application type, such as SMS, MMS, PoC or e-mail without any service class. The voice class includes only “telephony”, although it will be noted that both devices <b>170</b><i>b </i>and <b>170</b><i>c </i>offer a telephony service. Even though there are two types of telephone service (mobile and desktop), the virtual device definition <b>304</b> simply indicates that the user is available for voice services.

0069The virtual device definition <b>304</b> may be used by the presence manager <b>38</b> to generate a presence document <b>306</b> to be published to a presence server, such as presence server <b>96</b> (<figref idref="DRAWINGS">FIG. 1</figref>). The presence document <b>306</b> includes a unique user identifier, which may be the user address, and service class information. For example, with reference to <figref idref="DRAWINGS">FIG. 4A</figref>, the presence document <b>306</b> may indicate that the user is available for voice, text and imaging service classes. In all cases, any device information in the presence document <b>306</b> reflects the “virtual device” and not the individual devices <b>170</b>.

0070To continue with the example from <figref idref="DRAWINGS">FIGS. 2 and 4A</figref>, reference is now made to <figref idref="DRAWINGS">FIG. 4B</figref>, which shows another example aggregation of device state data <b>312</b> into a virtual device definition <b>314</b>. In this example, devices <b>170</b><i>b, </i><b>170</b><i>d, </i>and <b>170</b><i>a </i>all report presence information to the presence manager <b>38</b>. This example reflects a case in which the user is available by way of his or her fax machine <b>170</b><i>d, </i>personal computer <b>170</b><i>a, </i>and dual-mode mobile device <b>170</b><i>b. </i>In this case, the mobile device <b>170</b><i>b </i>has WLAN connectivity.

0071In the example, it is presumed that the dual-mode device <b>170</b><i>b </i>requires WLAN connectivity to enable MMS services under the “imaging” service class. It will also be noted that the device <b>170</b><i>b </i>is available for both cellular telephony and VoIP voice services due to the WLAN connection. In other embodiments, with other devices, the type of services available may not vary based on the type of network connectivity. The type of network connectivity may be used by the communication server <b>30</b> in making decisions as to where to route sessions and messages, whether on a least-cost basis or use other logic rules. Those skilled in the art will appreciated that the differing services illustrated in <figref idref="DRAWINGS">FIGS. 4A and 4B</figref> are for illustrative purposes and are not intended as a limitation of the present application.

0072Device <b>170</b><i>a </i>reports its availability for voice (VoIP), text (IM and e-mail), and video (videoconferencing) service classes.

0073The presence server <b>38</b> aggregates the service class information and, possibly, other presence data to generate the virtual device definition <b>314</b>. The virtual device definition <b>314</b> in this example indicates that the user is available for the services classes of voice, video, text, and imaging. The resultant presence document <b>316</b> indicates the user's availability for these services classes. Again, it will be noted that the presence document does not include details of the devices <b>170</b> but rather abstracts away that detail and associates the service classes with the “virtual device”.

0074The presence documents <b>306</b> and <b>316</b> are published to presence servers, such as presence server <b>96</b>, whereupon updated presence data with regard to the user may be sent to subscribing third parties. By way of example, the presence server <b>96</b> may inform the third parties of the user's availability for voice, text, or imaging communications/messages following receipt of the presence document <b>306</b>. To initiate such a communication, the third party does not need to chose a device to which to direct the proposed communication/invitation. Indeed, details of the available devices <b>170</b> are not made public, leaving the third party to direct invitation or other communications to the “virtual device” at the user address. The communication server <b>30</b> manages the routing of any such incoming invitations, etc., to the appropriate user device(s) <b>170</b> in accordance with its configuration for managing user communications.

0075Reference is now made to <figref idref="DRAWINGS">FIG. 5</figref>, which shows, in flowchart form, a method <b>500</b> for aggregating presence information to provide a simplified unified presence. The method <b>500</b> begins in step <b>502</b>, wherein a virtual device definition is created. As described above, the presence manager <b>38</b> may generate and store a virtual device definition in association with a user (e.g. a unique user identifier/address). The virtual device definition is configured to store aggregate presence information for the user and, in particular, aggregate service class information.

0076In step <b>504</b>, the presence manager <b>38</b> may receive updated presence information from one of the user's devices <b>170</b>. The presence manager <b>38</b> may be configured to determine that presence information for a given device <b>170</b> is associated with the user based on a link/association between the user and the given device <b>170</b>. The link/association may be stored in the user data entity <b>36</b> in some embodiments.

0077If updated presence information is received in step <b>504</b>, then the presence manager <b>38</b> aggregates the user presence information with presence information already received from the user's other devices <b>170</b> (if any), as shown in step <b>506</b>. The presence manager <b>38</b> may, in one embodiment, store the most up-to-date presence information received from each device <b>170</b> in a memory or database and may separately maintain the virtual device definition containing the aggregation of presence information. In other words, in such an embodiment the presence manager <b>38</b> may have the most recently received presence information from each device <b>170</b> stored. This may permit the presence <b>38</b> manager to apply time-outs or other such mechanisms for determining when presence information for a particular device <b>170</b> is stale and should be considered inaccurate. Stale presence information may be dealt with by discarding the information and presuming the device <b>170</b> is offline or out-of-service, or by sending a request for a presence update to the device <b>170</b>. It will be appreciated that the stale-dating of presence information may result in the presence manager <b>38</b> updating the aggregated device information, as reflected in steps <b>506</b>-<b>510</b>, as described herein.

0078In step <b>508</b>, having aggregated the presence information from the individual devices <b>170</b> into aggregate virtual device presence information, the presence manager <b>38</b> generates a virtual device presence document containing at least some of the aggregate presence information. In particular, the presence document contains at least service class information indicating the services classes for which the user is available, and/or the user's availability status for each service class. The presence document also includes a user identifier, such as the user address.

0079The presence document is published or transmitted to the presence server <b>96</b>, as indicated in step <b>510</b>. This provides the presence server <b>96</b> with a status update regarding the user, thereby enabling the presence server <b>96</b> to send/publish presence information to subscribing third parties with regard to the user.

0080Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.