Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol

RELATED APPLICATIONS

p-0002The present application is related to co-pending U.S. patent application Ser. No. 11/118,882 entitled “SYSTEM AND METHOD FOR UTILIZING A PRESENCE SERVICE TO ADVERTISE ACTIVITY AVAILABILITY,” filed on Apr. 29, 2005, and assigned to the assignee of the present application. The present application is also related to co-pending U.S. patent application Ser. No. 11/096,764, entitled “SYSTEM AND METHOD FOR UTILIZING A PRESENCE SERVICE TO FACILITATE ACCESS TO A SERVICE OR APPLICATION OVER A NETWORK,” filed on Mar. 31, 2005, and assigned to the assignee of the present application. The present application is also related to co-pending U.S. patent application Ser. No. 10/960,365, entitled “SYSTEM AND METHOD FOR UTILIZING CONTACT INFORMATION, PRESENCE INFORMATION AND DEVICE ACTIVITY,” and co-pending U.S. patent application Ser. No. 10/960,135, entitled “SYSTEM AND METHOD FOR UTILIZING CONTACT INFORMATION, PRESENCE INFORMATION AND DEVICE ACTIVITY,” both filed on Oct. 6, 2004, and both assigned to the assignee of the present application. The present application is also related to co-pending U.S. patent application Ser. No. 10/900,558, entitled “SYSTEM AND METHOD FOR PROVIDING AND UTILIZING PRESENCE INFORMATION,” filed on Jul. 28, 2004, and assigned to the assignee of the present application. The present application is also related to co-pending U.S. patent application Ser. No. 10/903,576, entitled “SYSTEM AND METHOD FOR HARMONIZING CHANGES IN USER ACTIVITIES, DEVICE CAPABILITES AND PRESENCE INFORMATION,” filed on Jul. 30, 2004, and assigned to the assignee of the present application. Each of the above-cited related applications is incorporated here by reference in its entirety.

BACKGROUND

p-0003Determining whether a person or object is present and available for interaction or use has been, and likely will remain, an everyday occurrence in society. As technology has evolved, so too have the ways in which we can determine the presence of persons or objects to interact with. For example, the explosive growth over the past two decades in the use of computers and their internetworking via wide-area networks (WANs), such as the Internet, has led to the development and use of presence services. Presence services can be used to convey a user's presence on a network to other network users based on user's connectivity to the network via a computing and/or communication device. Information describing users' presence on a network can be used by applications and/or other services to provide what are referred to here as “presence aware applications”.

p-0004One of today's more popular presence aware applications is instant messaging (or IM). Popular IM applications include Yahoo's YAHOO MESSENGER, Microsoft's MSN MESSENGER, and America Online's AOL INSTANT MESSENGER (or AIM). IM applications use presence services to allow users to determine whether other users (referred to by these applications as “friends” or “buddies”) are present on (e.g., connected to) a network. Presence services can also be used to determine a user's status (e.g., available, not available, and the like) and a communication address for communicating with a user. The communication address can include both a means of communicating with the user (e.g., via a telephone or email) and a corresponding contact address (e.g., a telephone number or email address).

p-0005The architecture, models, and protocols associated with presence services in general are described in “Request for Comments” (or RFC) documents RFC 2778 to Day et al., titled “A Model for Presence and Instant Messaging” (February 2000), and RFC 2779 to Day et al., titled “Instant Messaging/Presence Protocol” (February 2000), each published and owned by the Internet Society. While the various presence aware IM applications described above may use proprietary architectures and protocols to implement their presence service components, each of the applications use presence architectures and protocols that are consistent with the presence model and protocols described in RFC 2778 and RFC 2779 in terms of features and function.

p-0006The presence service model described in RFC 2778 describes two distinct users of a presence service, referred to as presence “clients”. The first of these clients, called a presentity (combining the terms “presence” and “entity”), provides presence information to be stored and distributed throughout the presence service. Presence information includes the status of a user of the presence service and may include additional information used by the service. This additional information can include, for example, the communication means and contract address of the user as described above. Presence information can be stored or maintained in any form for use by the presence service, but typically is organized into portions referred to as presence tuples. As will be understood by those skilled in the art, a tuple, in its broadest sense, is a data object containing one or more components. Thus, a presence tuple can include an identifier of a user and the user's status, contact address, or other information used by the presence service.

p-0007The second type of presence client is referred to as a “watcher”. Watchers receive presence information from the presence service. The presence model of RFC 2778 describes types of watchers, referred to as “subscribers” and “fetchers”. A subscriber requests notification from the presence service of a change in some presentity's presence information. The presence service establishes a subscription on behalf of the subscriber to a presentity's presence information, such that future changes in the presentity's presence information are “pushed” to the subscriber. In contrast, the fetcher class of watchers requests (or fetches) the current value of some presentity's presence information from the presence service. As such, the presence information can be said to be “pulled” from the presence service to the presentity. A special kind of fetcher, referred to as a “poller”, is defined in the model that fetches information on a regular (or polling) basis.

p-0008The presence service can also manage, store, and distribute presence information associated with watchers, as well as the watchers' activities in terms of the fetching or subscribing to the presence information of other presence clients using the presence service. This “watcher information” can be distributed to other watchers by the presence service using the same mechanisms that are available for distributing the presence information of presentities. It will be understood that while the model describes the presentity and watcher as separate entities, these entities can be combined functionally as a single presence entity having the characteristics of both a presentity and a watcher. Accordingly, the phrase “presence entity” (in contrast to the term “presentity”) or more simply the term “entity” with an appropriate modifier (e.g., responding, requesting, receiving, or sending) will be used throughout this document to describe any one or any combination of all of the presentity, watcher, subscriber, fetcher, or poller entities described above.

p-0009Users of the presence service are referred to in the presence model described in RFC 2778 as principals. Typically, a principal is a person or group that exists outside of the presence model, but can also represent software or other resources capable of interacting with the presence service. The model does not define the requirements or functionality of principals, but does state that two distinct principals be distinct, and two identical principals be identical. For purposes of this document, this strict interpretation of principals should not be adopted—that is, two distinct principals need not be distinct, and two identical principals need not be identical. For example, the 3rd Generation Partnership Project (3GPP) has included standards for incorporating presence services into their Universal Mobile Telecommunications System (UMTS) that define the use of “public identities” for users of the UMTS. A particular UMTS user may have several public identities. Consequently, were such a public identity to be construed as a principal, the public identity as a principal could be associated with more than one presence client.

p-0010According to the general presence model described in RFC 2778, a principal can interact with the presence system through a presence user agent (PUA) or a watcher user agent (WUA). As in the case of the presentity and watcher clients to which these user agents interact, the presence and watcher user agents can be combined functionally as a single user agent having both the characteristics of the presence and watcher user agents. User agents can be implemented such that their functionality exists within the presence service, external to the presence service, or a combination or both internal and external to the presence service.

p-0011Most presence aware applications, such as IM, use presence services only to determine an application user's presence, status, and communication address. For example, IM applications do not use the presence service itself to deliver core application services and information, such as the instant messages themselves, to their users. More specifically, IM applications do not use the base presence protocol messages (or commands) to exchange instant message information, but instead rely on a separate and distinct instant message protocol (see, e.g., RFC 2778 and RFC 2779) to exchange this information.

p-0012Likewise, other presence aware applications and extensions to presence services would be expected to use new protocols to support these applications or extended services. For example, to create a presence aware application capable of providing request/response services, developers would be expected to use a specific request/response protocol, separate from the presence protocol, to support the request/response services. Examples of request/response protocols include Hypertext Transfer Protocol (HTTP), used, for example, to exchange information between clients and servers over the Internet, and Simple Mail Transfer Protocol (SMTP) used for exchanging email messages over a network.

p-0013Indeed, the standards track publications RFC 3920 to Saint-Andre, titled “Extensible Messaging and Presence Protocol (XMPP): Core” (October 2004), and RFC 3921 to Saint-Andre, titled “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence” (October 2004), each published and owned by the Internet Society, envision the use of separate protocols for supporting presence and request/response services. These publications describe a protocol for streaming Extensible Markup Language (XML) elements to exchange structured information in close to real time between any two network endpoints. Rather than combining both presence information and request/response information into a common XML stanza to be carried using only a presence protocol, XMPP defines the use of a first XML stanza (a “/presence” stanza) for carrying presence information and a separate, second XML stanza (an “/iq” stanza) for carrying request/response information (see, e.g., RFC 3920; section 9). These separate stanzas would then be carried by respective presence and request/response protocol layers.

p-0014Others have described arrangements for sending application information using a presence service, but fall short of providing general request/response services using a presence protocol. For example, U.S. Patent Application No. 200410122896 A1 to Gourraud, titled “TRANSMISSION OF APPLICATION INFORMATION AND COMMANDS USING PRESENCE TECHNOLOGY”, describes a presence entity that publishes application information or commands destined to a certain application, in the form of a presence tuple. The watcher subscribes to presence information associated with the certain application, and once authorized, receives the tuple with the application information or command.

p-0015In a first embodiment, Gourraud's arrangement sends an application identifier from user equipment to an application server using a presence service. The application server then sends predefined information to the user equipment using the presence service. The arrangement does not allow the user equipment to request specific information or services from the application server—only the predefined information may be received. Indeed, no mechanism is described in Gourraud's first embodiment for sending a request from the user equipment to the application through using the presence service or presence protocol. In a second embodiment, Gourraud's arrangement allows a command to be sent from the user equipment to an application server using a presence service. Only an acknowledgment that the command was executed by the server is sent to the user equipment. Moreover, the acknowledgment is sent using a separate protocol from the presence protocol, i.e., an instant message confirmation is sent using the Session Initiation Protocol (SIP). As such, no response is sent from the application server to the user equipment in Gourraud's second embodiment, nor is any mechanism described in the embodiment for sending such a response using the presence service or presence protocol.

p-0016Rather than using multiple protocols to support a presence aware application that is capable of providing request/response services, it would be more efficient and desirable to have an arrangement for providing a general request/response messaging protocol using a presence service and its underlying presence protocol.

SUMMARY

p-0017Accordingly, a method and system are disclosed for providing a general request/response protocol using a presence protocol. According to an exemplary embodiment, a method is described for using the presence protocol for receiving from a requesting entity a descriptor of a resource associated with the responding entity and a request related to the resource; sending the descriptor and the request to the responding entity; receiving a response from the responding entity replying to the request message; and sending the response to the requesting entity.

p-0018According to another exemplary embodiment, a method is disclosed for providing a general request/response protocol using a presence protocol. The method includes receiving via the presence server a descriptor of a resource and a request related to the resource; processing the request by the resource to form a response replying to the request; and sending a response to the presence server replying to the request message.

p-0019According to yet another an exemplary embodiment, a method is disclosed for providing a general request/response protocol using a presence protocol. The method includes sending a descriptor of a resource and a request related to the resource; and receiving via the presence server a response replying to the request message.

p-0020According to still another exemplary embodiment, a computer readable medium is disclosed containing a data structure for use with a presence protocol in providing a general request/response protocol. The data structure includes a resource data object including an element for storing a descriptor of a resource associated with a responding entity; a request data object including an element for storing a request from a requesting entity related to the resource; and a response data object including an element for storing a response from the responding entity replying to the request message.

p-0021According to another exemplary embodiment, a system is described for providing a general request/response protocol. The system includes a presence server configured to receive, store, and distribute information using a presence protocol. A responding device is configured to exchange information with the presence server using the presence protocol. The responding device includes access to at least one resource; a responding watcher component configured to receive via the presence server a descriptor of a resource and a request related to the resource; and a responding presentity component configured to send a response to the presence server replying to the request message. The system also includes a requesting device configured to exchange information with the presence server using the presence protocol. The requesting device includes a requesting presentity component configured to send the descriptor and the request related to the resource to the presence server; and a requesting watcher component configured to receive via the presence server the response replying to the request message.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0022The accompanying drawings provide visual representations which will be used to more fully describe the representative embodiments disclosed here and can be used by those skilled in the art to better understand them and their inherent advantages. In these drawings, like reference numerals identify corresponding elements, and:

p-0023<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a system for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.

p-0024<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram illustrating the various components that can form a responding and/or requesting network devices according to an exemplary embodiment.

p-0025<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an interface that may be used by an owner of the resource to interact with responding and/or requesting entity according to an exemplary embodiment.

p-0026<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a data structure for use with a presence protocol in providing a general request/response protocol according to an exemplary embodiment.

p-0027<figref idrefs="DRAWINGS">FIGS. 5A and 5B</figref> show an expanded view of a request data object included in the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> according to an exemplary embodiment.

p-0028<figref idrefs="DRAWINGS">FIG. 6</figref> shows an expanded view of a response data object included in the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> according to an exemplary embodiment.

p-0029<figref idrefs="DRAWINGS">FIG. 7</figref> depicts a data structure for storing presence information associated with an IM resource according to an exemplary embodiment.

p-0030<figref idrefs="DRAWINGS">FIG. 8</figref> is a flowchart illustrating a method for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.

p-0031<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates an exemplary flow of information occurring among presence entities in carrying out a multi-entity transaction.

p-0032<figref idrefs="DRAWINGS">FIG. 10</figref> is signal flow diagram for an illustrative request/response scenario according to an exemplary embodiment.

DETAILED DESCRIPTION

p-0033Various aspects will now be described in connection with exemplary embodiments, including certain aspects described in terms of sequences of actions that can be performed by elements of a computer system. For example, it will be recognized that in each of the embodiments, the various actions can be performed by specialized circuits or circuitry (e.g., discrete and/or integrated logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. Thus, the various aspects can be embodied in many different forms, and all such forms are contemplated to be within the scope of what is described.

p-0034When describing the architecture, models, and protocols associated with presence services, this document uses terms described in RFC 2778 and RFC 2779. While the various presence service and presence protocol embodiments used today have differences, all of these embodiments use presence architectures and protocols that are consistent with the presence model and protocols described in RFC 2778 and RFC 2779 in terms of features and function. Accordingly, the terms used here should not be limited to any one of the presence models, services, and/or protocol embodiments in use today.

p-0035For example, today's presence protocols each support a common set of messages (or commands) from a functional standpoint (See, e.g., RFC 2779). These functional commands include: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0035">Publish: Allowing a presence entity (through a PUA/presentity) to update/provide its own presence information (e.g. its status or contact information) to a presence server;</li><li id="ul0002-0002" num="0036">Notify: Allowing a presence server to provide information from a presence tuple to a WUA/watcher. Notifications may be point-to-point (e.g., via a directed publish/notify command as described in the following paragraph) or broadcast; and</li><li id="ul0002-0003" num="0037">Subscribe (Unsubscribe): Allowing a WUA/watcher to subscribe or unsubscribe to notifications related to specific presence information. <br /> The phrase “presence protocol”, as used here, includes at least those commands to allow entities to publish presence information, notify entities of other entities' presence information, and allow entities to subscribe (unsubscribe) to other entities' presence information. </li></ul></li></ul>

p-0036Several optional, functionally equivalent presence commands also exist. These optional commands include: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0039">Probe: Allowing a presence service to get information associated with a presence entity. This is equivalent to a combined Notify/Publish command except that the presence service requests presence information rather than having the presence client send the information unsolicited; and</li><li id="ul0004-0002" num="0040">Directed Publish/Notify: Allowing a client to issue a publish command that results in a notify command being sent to a specific presence client, thus bypassing the subscription function.</li></ul></li></ul>

p-0037There is also a functional equivalent set of commands for managing a “friends list” (or “roster”) related to presence services. This set of commands includes: <ul><li id="ul0005-0001" num="0000"><ul><li id="ul0006-0001" num="0042">Request: Allowing a client to request a specific or default roster;</li><li id="ul0006-0002" num="0043">Add: Allowing a client to add an item for a presence entity to a roster;</li><li id="ul0006-0003" num="0044">Update: Allowing a client to update a roster item; and</li><li id="ul0006-0004" num="0045">Delete: Allowing a client to delete an item from a roster. <br /> Related to rosters are privacy lists. A privacy list can be generally described in terms of a roster configured to identify presence clients that are to be blocked from interacting with the owner of the roster/privacy list. </li></ul></li></ul>

p-0038Referring now to <figref idrefs="DRAWINGS">FIG. 1</figref>, a system <b>100</b> is depicted for providing a general request/response protocol using a presence protocol. The system includes a presence server <b>118</b> configured to receive, store, and distribute information via a presence service <b>120</b>. The system further includes responding and requesting devices <b>102</b> configured to exchange information with the presence server <b>118</b> via the network <b>116</b> using a presence protocol. The responding and requesting devices <b>102</b> can include any of Personal Computers (PCs), Personal Digital Assistants (PDAs), network-enabled cameras, camera phones, cell phones, and the like.

p-0039Although depicted as a stand-alone server in <figref idrefs="DRAWINGS">FIG. 1</figref>, the presence server <b>118</b> can include several servers (not shown) that together can function as the presence service <b>120</b>. Moreover, the function of the presence server <b>118</b> can be incorporated, either in whole or in part, into any of the devices <b>120</b> and server <b>118</b> shown in the figure, and thus can be distributed throughout the network of elements shown. As such, the meaning of “presence server” used here does not strictly conform to the definition of a “server” included in RFC 2778 as being an indivisible unit of a presence service. Nevertheless, the presence server <b>118</b> and presence service <b>120</b> are closely link to one another and can be considered to perform one and the same function. As used here, however, the presence server <b>118</b> can also include additional services, such as the account service <b>122</b> and proxy service <b>124</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, although these additional services need not be included in the server <b>118</b>. It will be understood that these additional services can also be distributed across one or more servers or devices <b>102</b> interconnected via the network <b>116</b>.

p-0040A responding device can be, for example, a PC, such as the PC <b>102</b><i>b </i>shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The responding device <b>102</b><i>b </i>includes access to at least one resource. The resource can be any service, application, file, or other information associated with the responding device that can be made available for use by or interaction with a requesting device, such as the camera <b>102</b><i>a </i>or camera phone <b>102</b><i>c</i>, via the network <b>116</b>. For example, <figref idrefs="DRAWINGS">FIG. 1</figref> shows that the responding device <b>102</b><i>b </i>can provide resources including services <b>104</b> (e.g., web services, such as a photo sharing website), software applications <b>108</b>, and files <b>112</b> (such as image files). Requesting devices, such as the camera <b>102</b><i>a </i>or camera phone <b>102</b><i>c</i>, can request information or services related to these resources using the presence service <b>120</b> via the network <b>116</b>.

p-0041<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram illustrating the various components that can make up the responding and/or requesting network devices <b>102</b>. For convenience, the arrangement shown in <figref idrefs="DRAWINGS">FIG. 2</figref> represents a network device capable of functioning both as a responding device and as a requesting device. Nevertheless, persons skilled in the art will understand that a responding device need not include the components necessary to function as a requesting device, and vice versa. Moreover, the figure includes a responding/requesting presentity component <b>202</b> and responding/requesting watcher component <b>204</b>. It will be understood that each of these components can be combined into a single respective presentity <b>202</b> or watcher <b>204</b> component, or can be implemented as separate responding and requesting entities as described below.

p-0042First consider the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of a responding device, such as the PC <b>102</b><i>b</i>. From this perspective, the arrangement includes a responding presentity component <b>202</b>. According to an exemplary embodiment, the responding presentity component <b>202</b> can be configured to send a descriptor of the resource <b>104</b>, <b>108</b>, <b>112</b> to the presence server <b>118</b>. The descriptor can include any information that describes and/or identifies any of the resources <b>104</b>, <b>108</b>, <b>112</b> available to the responding device, and can be used to advertise the availability of those resources to requesting devices for processing their requests.

p-0043For example, <figref idrefs="DRAWINGS">FIG. 2</figref> shows that the responding device <b>102</b><i>b </i>has access to web services <b>104</b>, including a photo sharing web service <b>104</b><i>a </i>and other web services <b>104</b><i>b</i>, a file system <b>112</b>, printer services <b>104</b><i>c</i>, and camera services <b>104</b><i>d</i>. The descriptor can simply identify a resource by name or can include other information to describe or identify the resource to other presence entities coupled to the network <b>116</b> The responding presentity component <b>202</b> can send the descriptor of the resource to the presence server <b>118</b> by including the descriptor in presence information as described in conjunction with <figref idrefs="DRAWINGS">FIGS. 4-6</figref> below. The presence information including the descriptor can be sent to the presence server <b>118</b> via the presence protocol using a publish command. The descriptor can thus be used to advertise the availability of the resource to other presence entities that are subscribed to the presence information of the responding device.

p-0044In an alternative embodiment, the responding presentity component <b>202</b> need not send the descriptor of the resource <b>104</b>, <b>108</b>, <b>112</b> to the presence server <b>118</b> to advertise the availability of the resource for processing requests. Instead, requesting devices coupled to the presence server <b>118</b> can broadcast a standardized request without a descriptor for processing by any of all of the resources <b>104</b>, <b>108</b>, <b>112</b> associated with responding devices coupled to the presence server <b>118</b> via the network <b>116</b>.

p-0045Continuing to consider the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of the responding device <b>102</b><i>b</i>, the arrangement further includes a responding watcher component <b>204</b>. The responding watcher component <b>204</b> is configured to receive from a requesting device (e.g., the camera phone <b>102</b><i>c</i>), via the presence server <b>118</b>, the descriptor of the resource <b>104</b>, <b>108</b>, <b>112</b> and a request related to the resource. The presence server <b>118</b> can send the descriptor and the request to the responding watcher component <b>204</b> via the presence protocol using a notify command. The notify command including the descriptor and request may be sent to the responding watcher component <b>204</b> based on a subscription to the presence information of the requesting device <b>102</b><i>c</i>, as a result of a directed publish/notify command sent by the requesting device <b>102</b><i>c </i>for delivery to the responding device <b>102</b><i>b</i>, or in response to a fetch or polling request made by responding device <b>102</b><i>b. </i>

p-0046As described below in conjunction with <figref idrefs="DRAWINGS">FIGS. 4-6</figref>, the descriptor of the resource can be included in the request itself or can be included in the presence protocol commands, such as the notify command described above, used to carry the request from the requesting device to the responding device. The descriptor can be used to associate the request with a particular resource <b>104</b>, <b>108</b>, <b>112</b> available to the responding device <b>102</b><i>b</i>, and the request message can be used to carry the resource request. As such, the responding device <b>102</b><i>b </i>can process multiple requests for different resources <b>104</b>, <b>108</b>, <b>112</b> corresponding to the various requesting devices <b>102</b><i>c </i>connected to the network <b>116</b>.

p-0047Again considering the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of the responding device <b>102</b><i>b</i>, the responding presentity component <b>202</b> is further configured to send a response to the presence server <b>118</b> replying to the request message. The responding presentity component <b>202</b> can send the response to the presence server <b>118</b> by including the response in presence information as described in conjunction with <figref idrefs="DRAWINGS">FIGS. 4-6</figref> below. The presence information including the response can be sent to the presence server <b>118</b> via the presence protocol using either a broadcast or directed publish command.

p-0048According to an exemplary embodiment, the responding device can include a responding user agent (RSUA). The RSUA component is coupled to the resource <b>104</b>, <b>108</b>, <b>112</b> and to the responding presentity <b>202</b> and watcher <b>204</b> components. Like the PUA and WUA components described above, the RSUA can interact with the responding presentity <b>202</b> and watcher <b>204</b> components on behalf of a principal. Generally, the RSUA will interact with the resource <b>104</b>, <b>108</b>, <b>112</b> as its principal, although the RSUA can also interact with an owner of the resource as well as other principals.

p-0049The RSUA component can be configured to facilitate a sending of the descriptor of the resource by the responding presentity component <b>202</b> to advertise the resource to other presence entities coupled to the network <b>116</b>. The RSUA component can interact with the resource <b>104</b>, <b>108</b>, <b>112</b> directly to determine and publish the descriptor or can provide an appropriate interface for an owner of the resource to publish the descriptor of the resource using the presence protocol. To provide an interface for the owner of the resource, the RSUA can be coupled to a user communication client <b>110</b><i>a </i>or any number of associated communication clients, such as an IM communication client <b>110</b><i>b</i>, a phone client <b>110</b><i>c</i>, an email client <b>110</b><i>d</i>, a Multimedia Messaging Service (MMS) client <b>110</b><i>d</i>, and a browser client <b>110</b><i>f </i>(collectively, communication clients <b>110</b>) as shown in <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0050For example, <figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an interface that may be used by an owner of the resource <b>104</b>, <b>108</b>, <b>112</b> to interact with the responding presentity component <b>202</b> to publish the descriptor of the resource. Using the IM client <b>110</b><i>b</i>, the exemplary interface can be presented on a display <b>300</b> in the form a “friends list” <b>302</b>, recognizable to those familiar with IM applications. The friends list <b>302</b> can include the names of human resource owners, e.g., John, Paul, George, and Ringo, and/or non-human resource owners, e.g., Server<b>1</b>. The friends list <b>302</b> can also include information identifying the resources associated with each of displayed owners that are offered to authorized requesting entities, as well as a status of the offered resources. For example, the resources associated with John in the exemplary list <b>302</b> can include a print service that is not available (N/A), web services, including a photo sharing service that is available, an IM service that is available, and a file system that is not available (N/A).

p-0051The interface <b>302</b> can also include an Actions menu item <b>306</b>, suitable for invoking commands associated with resources. The Actions menu can include entries <b>306</b><i>a </i>to publish a resource, publish a response to a request, publish a request associated with a resource, subscribe to information associated with a resource, and subscribe to information associated with a request related to resource. A corresponding dialog box (not shown) can be presented to gather the necessary information to perform the selected action.

p-0052The RSUA can be further configured to facilitate a processing by the resource <b>104</b>, <b>108</b>, <b>112</b> of the request received by the responding watcher component <b>204</b>. The RSUA can be configured to forward the request to the appropriate resource <b>104</b>, <b>108</b>, <b>112</b> for processing or can interpret and/or pre-process the request prior to its being forward to the resource. For example, if the request were related to accessing the photo sharing web service <b>104</b><i>a </i>illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, the RSUA could translate the request into an appropriate HTTP get request and then forward the request to the web service for processing (e.g., serving a requested photo web page).

p-0053The RSUA can facilitate the processing of the request without any user intervention or, if appropriate, can provide a suitable interface for gathering information, such as authorization, from an owner of the resource. For example, the interface <b>302</b> shown in <figref idrefs="DRAWINGS">FIG. 3</figref> is illustrated as presenting a dialog box <b>304</b> indicating that a user, George, has requested access to a printer service (e.g., service <b>104</b><i>c </i>of <figref idrefs="DRAWINGS">FIG. 2</figref>) by submitting a print job request. The owner of the printer service can either accept or deny the request by selecting the appropriate dialog box control. If the request is accepted by the owner of the printer service, the RSUA can forward the request to the printer service, performing any translations of the request as needed.

p-0054In addition, the RSUA can be further configured to facilitate a sending of the response to the request by the responding presentity component <b>202</b>. As with the publishing of the descriptor, the RSUA component can interact with the resource <b>104</b>, <b>108</b>, <b>112</b> directly to determine and publish the response to the request or can provide an appropriate interface for the owner of the resource to publish the response using the presence protocol. For example, upon selection of the “publish a response” entry included in the Action entry list <b>306</b><i>a </i>of <figref idrefs="DRAWINGS">FIG. 3</figref>, an appropriate dialog box (not shown) can be presented to gather the necessary information to form the response to the request. The RSUA can then forward the response to the responding presentity component <b>202</b> for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the response as needed.

p-0055In facilitating the exchange of information between the responding presentity <b>202</b> and watcher <b>204</b> components, the resource <b>104</b>, <b>108</b>, <b>112</b>, and the communication clients <b>110</b>, the RSUA may act in conjunction with appropriate PUAs and/or WUAs or may bypass the operation of these agents. Moreover, it will be understood that the RSUA for a particular resource can be combined with the PUA and/or WUA associated with that resource, or can be configured to act as a responding user agent for all resources associated with a particular device and/or owner. As with PUAs and WUAs, the RSUA can be implemented such that its functionality exists within the presence service, external to the presence service, or a combination or both internal and external to the presence service.

p-0056Consider now the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of a requesting device, such as the camera phone <b>102</b><i>c </i>shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. From this perspective, the arrangement includes a requesting watcher component <b>204</b> which can be configured to receive the descriptor of the resource <b>104</b>, <b>108</b>, <b>112</b> if sent from the presence server <b>118</b>. The presence server <b>118</b> can send the descriptor to the requesting watcher component <b>204</b> via the presence protocol using a notify command. The notify command including the descriptor may be sent to the requesting watcher component <b>204</b> based on a subscription to the presence information of the responding device <b>102</b><i>b</i>, as a result of a directed publish/notify command sent by the responding device <b>102</b><i>b </i>for delivery to the requesting device <b>102</b><i>c</i>, or in response to a fetch or polling request made by the requesting device <b>102</b><i>c</i>. The descriptor of the resource can be included in presence information associated with the responding device or can be included in the presence protocol commands, such as the notify command described above, used to carry the presence information from the responding device to the requesting device.

p-0057Continuing to consider the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of the requesting device <b>102</b><i>c</i>, the arrangement further includes a requesting presentity component <b>202</b> configured to send the descriptor and the request related to the resource to the presence server <b>118</b>. The requesting presentity component <b>202</b> can send the request to the presence server <b>118</b> by including the request in presence information as described in conjunction with <figref idrefs="DRAWINGS">FIGS. 4-6</figref> below. The descriptor of the resource can be included in the request itself or can be included in the presence protocol commands used to carry the presence information including the request from the requesting device to the responding device. The presence information including the request can be sent to the presence server <b>118</b> via the presence protocol using either a broadcast or directed publish command.

p-0058Again, considering the arrangement of <figref idrefs="DRAWINGS">FIG. 2</figref> from the perspective of the requesting device <b>102</b><i>c</i>, the requesting watcher component <b>204</b> is further configured to receive via the presence server <b>118</b> the response replying to the request message. The presence server <b>118</b> can send the response to the requesting watcher component <b>204</b> via the presence protocol using a notify command. The notify command including the response may be sent to the requesting watcher component <b>204</b> based on a subscription to the presence information of the responding device <b>102</b><i>b</i>, as a result of a directed publish/notify command sent by the responding device <b>102</b><i>b </i>for delivery to the requesting device <b>102</b><i>c</i>, or in response to a fetch or polling request made by the requesting device <b>102</b><i>c. </i>

p-0059According to an exemplary embodiment, the requesting device can include a requesting user agent (RQUA) component coupled to the requesting presentity <b>202</b> and watcher <b>204</b> components. Like the RSUA, the RQUA can also be coupled to the communication clients <b>110</b><i>a</i>-<b>110</b><i>f </i>shown in <figref idrefs="DRAWINGS">FIG. 2</figref> for interacting with a user/principal of the requesting device <b>102</b><i>c</i>. The RQUA can be configured to facilitate a presentation of the descriptor received by the requesting watcher component <b>204</b>. For example, using the IM client <b>110</b><i>b</i>, the RQUA can present a descriptor of a resource received by the requesting watcher component <b>204</b>, such as the photo sharing web service shown as being owned by John or the programs and service shown as being owned by Server<b>1</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>. The descriptor can be presented in the interface <b>302</b> together with information describing the owner of the resource and a status of the resource.

p-0060The RQUA can also be configured to facilitate a sending of the request by the requesting presentity component <b>202</b>. The request can be automatically generated by the RQUA in response to some other action occurring in relation to the resource, e.g., an action by a related program running on the requesting device <b>102</b><i>c</i>. Alternatively, an interface, such as the interface <b>302</b> shown in <figref idrefs="DRAWINGS">FIG. 3</figref>, can be presented to a user/principal of the requesting device <b>102</b><i>c </i>to gather information needed to form the request. For example, upon selecting the “publish a request” Action entry <b>306</b><i>a</i>, a corresponding dialog box (not shown) can be presented to a user/principal to gather the necessary information to form the request. The RQUA can then forward the request to the requesting presentity component <b>202</b> for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the request as needed.

p-0061The RQUA can also be configured to facilitate a presentation of the response received by the requesting watcher component <b>204</b>. For example, if the response were to include a web page served from the photo sharing web service <b>104</b><i>a </i>of the responding device <b>102</b><i>b </i>illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, the RQUA could invoke the browser client <b>110</b><i>f </i>of the requesting device <b>102</b><i>c </i>shown in the figure to display the served web page. Thus, the RQUA can effectively establish itself as a proxy for processing requests directed to and responses received from presence server <b>118</b>. Alternatively, the RQUA can present a dialog box to receive authorization or additional information from a user/principal prior to acting on the response.

p-0062In facilitating the exchange of information between the requesting presentity <b>202</b> and watcher <b>204</b> components and the communication clients <b>110</b>, the RQUA may act in conjunction with appropriate PUAs and/or WUAs or may bypass the operation of these agents. As with PUAs and WUAs, the RQUA can be implemented such that its functionality exists within the presence service, external to the presence service, or a combination or both internal and external to the presence service.

p-0063Referring again to <figref idrefs="DRAWINGS">FIG. 1</figref>, the presence server <b>118</b> can include the proxy service <b>124</b>. The proxy service <b>124</b> can be configured to send the request to the responding watcher component <b>204</b> through a firewall <b>114</b> associated with the responding device <b>102</b><i>b </i>or to send the response to the requesting watcher component through a firewall (not shown) associated with the requesting device <b>102</b><i>c</i>. According to another exemplary embodiment, the presence server <b>118</b> can also include the account service <b>122</b>. The account service <b>122</b> can be configured to authenticate an identity of each of the requesting and responding devices and to authorize a receiving by each of the devices of the request or the response prior to sending the request or response to the respective entity.

p-0064Rosters and/or privacy lists may be used by the account service <b>122</b> to authorize and authenticate access to a particular resource or to prevent providers from advertising certain resources to subscribers. In this sense, the rosters and/or privacy lists can operate as access control lists (ACLs) for authenticating and authorizing resource usage among presence entities. The roster and/or privacy list data can be stored in a database, such as the account and authorization information database <b>128</b> coupled to the account service <b>122</b>. Multiple rosters and/or privacy lists may be maintained in the database <b>128</b> and used by the service <b>122</b>. No new extension to the account service protocol for roster management is required to maintain the rosters or lists, however, the roster data can instead be included in presence information and carried by the presence protocol.

p-0065Referring now to <figref idrefs="DRAWINGS">FIG. 4</figref>, a data structure is illustrated for use with a presence protocol in providing a general request/response protocol. For convenience, the data structure shown in <figref idrefs="DRAWINGS">FIG. 4</figref> includes data objects and elements for storing the presence information of both a responding entity and a requesting entity. Nevertheless, persons skilled in the art will understand that a data structure for storing the presence information associated with a responding device need not include the objects and elements necessary to store the presence information of a requesting device, and vice versa.

p-0066Should the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> include data objects and elements for storing the presence information of both a responding and requesting entity, one of the following arrangements may exist: 1) the responding and requesting entities are associated with the same principal, and are responding to and making requests related to different resources; or 2) the responding and requesting entities are associated with different principals, and are responding to and making requests related to a common resource. This second arrangement requires a change to the standard presence services access control policies, and could lead to a more complex access control system. Nevertheless, performing the entire request/response transaction using information stored in a single presence tuple associated with the resource or owner of the resource could lead to efficiencies in data storage usage and data exchange.

p-0067The data structure shown in <figref idrefs="DRAWINGS">FIG. 4</figref> may be contained in any suitable computer readable medium, including any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium, such as a removable storage device. More specific examples (a non-exhaustive list) of the computer readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read only memory (CDROM).

p-0068The data structure shown in <figref idrefs="DRAWINGS">FIG. 4</figref> represents presence information <b>400</b> that includes an enhanced presence tuple <b>402</b>. The presence information <b>400</b> can be stored in a database coupled to the presence server <b>118</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, such as the presence information database <b>126</b>. Although a single database <b>126</b> is shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, persons skilled in the art will understand that the presence information can be distributed throughout the network <b>116</b> across multiple databases and/or stored, at least in part, in memory associated with the requesting and/or responding devices <b>102</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>.

p-0069The presence tuple <b>402</b> shown in <figref idrefs="DRAWINGS">FIG. 4</figref> includes standard data objects for storing the status <b>404</b> and communication address <b>406</b> information described in RFC 2778 and RFC 2779. The presence tuple <b>402</b> also includes data objects for storing a contact means <b>408</b> and contact address <b>410</b>, as well as a data object for storing other markup <b>418</b>, thus maintaining the extensibility of the tuple <b>402</b> in accordance with presence standards. Because the presence tuple <b>402</b> maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information <b>400</b> can be carried across the network <b>116</b> using standard presence protocol commands. It is not necessary that the presence server <b>118</b> to understand the content of the tuple <b>402</b> in order to route the information contained therein to the various presence entities coupled to the network <b>116</b>.

p-0070Considering first the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> from the perspective of a responding entity, to provide a general request/response protocol using a presence protocol, the presence tuple <b>402</b> includes a resource data object <b>412</b>, including an element (not expressly shown) for storing a descriptor of a resource associated with a responding entity. As described in conjunction with <figref idrefs="DRAWINGS">FIGS. 1-3</figref> above, the descriptor can include any information that describes and/or identifies the resource available to the responding entity, such as any of the resources <b>104</b>, <b>108</b>, <b>112</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The responding entity can be, for example, the responding presentity component <b>202</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. According to an exemplary embodiment, the resource data object <b>412</b> can also include at least one element (not expressly shown) for storing information describing the requests supported by the resource, including information describing the types of functions and requests that the resource can support and information describing how to format the requests. The resource data object <b>412</b> can also include at least one element (not expressly shown) for storing information describing the responses available for replying to the requests supported by the resource.

p-0071Now, considering the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> from the perspective of a requesting entity, the presence tuple <b>402</b> also includes a request data object <b>416</b>. The request data object includes an element for storing a request from a requesting entity related to the resource. The requesting entity can be, for example, the requesting presentity component <b>202</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0072<figref idrefs="DRAWINGS">FIG. 5A</figref> shows an expanded view of the request data object <b>416</b> according to an exemplary embodiment. As shown in the figure, the expanded view of the request data object <b>416</b> can include an element for storing a request message <b>504</b> related to the resource. The request data object <b>416</b> can also include a descriptor element <b>502</b> for storing a descriptor of a resource associated with the responding entity. The descriptor element <b>502</b> can include information to describe or identify only the resource, or can include information to describe or identify both the responding entity and its associated resource(s), such as a Uniform Resource Identifier (URI).

p-0073For example, consider the following XML-based message published by a requesting entity (“customer@isp.net”) for notification to an online store, “online.com” that includes a service (or resource) for ordering books: <ul><li id="ul0007-0001" num="0082"><presence</li><li id="ul0007-0002" num="0083">from=‘customer@isp.net’</li><li id="ul0007-0003" num="0084">to=‘sales@online.com’</li><li id="ul0007-0004" num="0085">xml:lang=‘en’></li><li id="ul0007-0005" num="0086"><request></li><li id="ul0007-0006" num="0087"><descriptor>books</descriptor></li><li id="ul0007-0007" num="0088"></request></li><li id="ul0007-0008" num="0089"></presence> <br /> The descriptor stored in element <b>502</b> could be simply “books” (as indicated) to identify the resource, or the descriptor could be a full URI, e.g., “sales@online.com/books”, to identify both the responding entity (e.g., by node and domain name) and the resource. It should be understood that the responding entity can correspond to the resource itself, and thus the descriptor can describe or identify the responding entity/resource using a simpler URI, such as the URI “books@online.com”. The presence server <b>118</b> can use the descriptor stored in the element <b>502</b> both to route the request message stored in element <b>504</b> to the requesting entity/resource (e.g., using the node and domain portion of a URI descriptor) and to describe or identify the resource to process the request (e.g., using the identifier portion of a URI descriptor. </li></ul>

p-0074It can be useful to include the descriptor in the request under circumstances when the requesting entity's identifying information is being sent to all watching entities that may be subscribed to the request or when the presence information that includes the request is being broadcast to all watching entities coupled to the network <b>116</b> (i.e., when a directed publish/notify command is not used). For example, consider the following XML-based message published by a requesting entity (“customer@isp.net”) for broadcast to any available responding entity/resource:

p-0075<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><presence</entry></row><row><entry /><entry>from=‘customer@isp.net’</entry></row><row><entry /><entry>xml:lang=‘en’></entry></row><row><entry /><entry><request></entry></row><row><entry /><entry><descriptor>sales@online.com/books</descriptor></entry></row><row><entry /><entry></request></entry></row><row><entry /><entry></presence></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Broadcasting to all entities can be useful when the responding entity has not subscribed to at least the presence information of the requesting entity that includes the request.

p-0076<figref idrefs="DRAWINGS">FIG. 5B</figref> shows an expanded view of the request data object <b>416</b> according to an alternative embodiment. In this embodiment, the request data object <b>416</b> does not include an element for storing the descriptor of the resource associated with the responding entity (e.g., element <b>502</b> shown in <figref idrefs="DRAWINGS">FIG. 5A</figref>). Instead, the descriptor of the resource can be included in the presence protocol commands used to carry the request from the requesting device to the responding device. For example, consider the following XML-based message published by a requesting entity (“customer@isp.net”) for notification to the online store described above:

p-0077<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><presence</entry></row><row><entry /><entry>from=‘customer@isp.net’</entry></row><row><entry /><entry>to=‘sales@online.com/books’</entry></row><row><entry /><entry>xml:lang=‘en’></entry></row><row><entry /><entry><request> ... </request></entry></row><row><entry /><entry></presence></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Rather than including the descriptor for the “books” service offered by the online store in the request message itself (e.g., between the <request> and </request> elements of the message), the descriptor can be included in a presence attribute, “sales@online.com/books”, used by the presence server <b>118</b> to route the notify portion of the directed publish/notify command to the responding entity.

p-0078It can also be useful for the requesting entity to broadcast a standardized request without a particular resource descriptor when the requesting entity has no preference as to the responding entity/resource that processes and responds to the request. Consequently, the request can be processed by any available responding entity/resource. For example, consider the following XML-based message published by a requesting entity (“customer@isp.net”) for broadcast to any available responding entity/resource:

p-0079<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><presence</entry></row><row><entry /><entry>from=‘customer@isp.net’</entry></row><row><entry /><entry>xml:lang=‘en’></entry></row><row><entry /><entry><request> ... </request></entry></row><row><entry /><entry></presence></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Since the broadcast message including the request does not include a descriptor of a resource to process the request (either in a presence attribute of the message or in the request itself), any watching entity/resource can evaluate the request, and process and respond to the request if appropriate.

p-0080In a related embodiment, the request data object can also include an element for storing an identifier of the responding entity. For example, the expanded view of the exemplary request data object <b>416</b> shown in <figref idrefs="DRAWINGS">FIG. 5B</figref> includes an identifier element <b>506</b> for storing an identifier of the responding entity. The identifier can be a URI including a node and domain of a responding entity, such as “sales@online.com”. Such an identifier can be used by the requesting entity when broadcasting a request to all watching entities (e.g., for notice purposes), but when the request is to be processed by only the responding entity corresponding to the identifier.

p-0081For example, consider the following XML-based message published by a requesting entity (“customer@isp.net”) for broadcast to any available responding entity/resource, but including an identifier in the request for identifying a responding entity having a resource available to process the request:

p-0082<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><presence</entry></row><row><entry /><entry>from=‘customer@isp.net’</entry></row><row><entry /><entry>xml:lang=‘en’></entry></row><row><entry /><entry><request></entry></row><row><entry /><entry><identifier>sales@online.com</identifier></entry></row><row><entry /><entry></request></entry></row><row><entry /><entry></presence></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this sense, the identifier stored in element <b>506</b> serves a similar function to the descriptor stored in element <b>502</b> of the arrangement shown in <figref idrefs="DRAWINGS">FIG. 5A</figref>. The identifier, however, need not include a descriptor of the resource used to process the request. Thus, if the responding entity corresponding to the identifier has access to a number of resources, any one of those resources can be used to process the request.

p-0083According to another exemplary embodiment, the request message stored in element <b>504</b> can be an XML-based message formed in the structure of a SOAP message. SOAP is a standard for exchanging XML-based messages over a computer network, typically using HTTP. SOAP forms the foundation layer of a protocol stack for providing web services. The standard provides a basic messaging framework that more abstract layers in the stack can build on.

p-0084There are several different types of messaging patterns available in SOAP, but the most common is the Remote Procedure Call (RPC) pattern, where one network node (the client) sends a request message to another node (the server), and the server immediately sends a response message to the client. SOAP originally was an acronym for Simple Object Access Protocol, but the acronym has been dropped in Version 1.2 of the SOAP specification. A primer for this version of the standard, published by the World Wide Web Consortium (W3C) XML Protocol Working Group could be downloaded or viewed from http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ at the time this application was filed.

p-0085Referring once again to the data structure of <figref idrefs="DRAWINGS">FIG. 4</figref> from the perspective of a responding entity, the presence tuple <b>402</b> also includes a response data object <b>414</b> including an element for storing a response from the responding entity replying to the request message. The responding entity can be, for example, the responding presentity component <b>202</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. It should be noted that <figref idrefs="DRAWINGS">FIG. 4</figref> depicts two response data objects <b>414</b> linked to the resource data object <b>412</b> in the presence tuple <b>402</b>. Such an arrangement allows for the efficient storage and management of the information needed to respond to multiple requests (from, e.g., multiple presence entities) that are related to a common resource. Nevertheless, the arrangement shown in <figref idrefs="DRAWINGS">FIG. 4</figref> is merely exemplary, and other arrangements for storing and managing the resource, request, and response information are within the scope of the techniques describe here.

p-0086<figref idrefs="DRAWINGS">FIG. 6</figref> shows an expanded view of the response data object <b>414</b> according to an exemplary embodiment. As shown in the figure, the expanded view of the response data object <b>414</b> can include an element for storing a response message <b>604</b> replying to the request message stored in element <b>504</b>. Similar to the request message, the response message stored in element <b>604</b> can be an XML-based message formed in the structure of a SOAP message.

p-0087The response data object <b>414</b> can also include an identifier element <b>602</b> (similar to the identifier element <b>506</b> shown in <figref idrefs="DRAWINGS">FIG. 5B</figref>) for storing an identifier, such as a URI, of the requesting entity. The presence server <b>118</b> can use the identifier stored in the element <b>602</b> to route the response message stored in element <b>604</b> of the presence tuple <b>402</b> to the requesting entity. It can be useful for the presence server <b>118</b> to use this identifier under circumstances when both the responding entity's presence information is being broadcast to all presence entities coupled to the network <b>116</b> (i.e., when a directed publish/notify command is not used) and the requesting entity has not subscribed to at least the presence information of the responding entity that includes the response message, or when there is a need to notify other subscribed watchers of the response.

p-0088For example, consider the following XML-based message published by a responding entity (“sales@online.com”) for broadcast to any available requesting entity:

p-0089<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><presence</entry></row><row><entry /><entry>from=‘sales@online.com’</entry></row><row><entry /><entry>xml:lang=‘en’></entry></row><row><entry /><entry><response></entry></row><row><entry /><entry><identifier>customer@isp.net</identifier></entry></row><row><entry /><entry></response></entry></row><row><entry /><entry></presence></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Notwithstanding the message being broadcast to all watching entities, the identifier can be used by the requesting entity (“customer@isp.net”) to determine that the response is in reply to its own request. When there is no need to notify other subscribed watchers of the response, a directed publish/notify of the response to the requesting entity can be used, making it unnecessary to store the identifier of the requesting entity in the response data object <b>414</b>.

p-0090Most presence protocols are XML-based (e.g., text-based) protocols. Should it be necessary to include binary data in either the request or response message, the binary data can be supported through the use of attachments. For example, the document “SOAP with attachments”, published by the W3C and available for downloading or viewing from http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/ at the time this application, describes SOAP support for binary attachments. Alternatively, binary data may be passed in the request/response messages by reference. That is, URIs may be passed in the XML-based request/response messages, using which a presence entity and/or agent may retrieve the binary data. It is preferred that binary data pass through and/or be stored in a presence tuple encoded in a text format, such that presence server <b>118</b> can apply security, tracking, and management services to this type of data as well by treating it just as any other piece of tuple data.

p-0091In an exemplary embodiment, the resource <b>412</b> and response <b>414</b> data objects can be included in a presence tuple associated with the resource or an owner of the resource. When the resource <b>412</b> and response <b>414</b> data objects are included in a presence tuple associated with the resource, the presence tuple associated with the resource can include a data object linking the presence tuple associated with the resource to a presence tuple associated with the owner of the resource.

p-0092For example, <figref idrefs="DRAWINGS">FIG. 7</figref> depicts a data structure for storing presence information associated with an IM resource, such as the IM client <b>110</b><i>b </i>shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. The presence information <b>400</b> includes an IM presence tuple <b>702</b> corresponding to the IM client <b>110</b><i>b</i>, and other IM presence tuples <b>702</b> corresponding to other IM clients (not shown) coupled to the network <b>116</b>. The IM presence tuple <b>702</b> includes standard data objects for storing a service status <b>704</b>, a communication address <b>706</b>, including elements for storing a contact means <b>708</b> and contact address <b>710</b>, and a data object for storing other markup information <b>418</b>. The information stored in the status <b>704</b> and communication address <b>706</b> data objects can represent the status and communication address of an owner or principal associated with the IM client <b>110</b><i>b </i>and/or the status and communication address of the IM client <b>110</b><i>b. </i>

p-0093Since the IM presence tuple <b>702</b> is associated with a resource (e.g., the IM client <b>110</b><i>b</i>) and not the owner of the resource, the IM presence tuple <b>702</b> can also include a data object <b>712</b> for storing information linking information in the owner/principal's presence tuple (not shown) to the IM presence tuple <b>702</b>. Moreover, since the IM present tuple <b>702</b> is itself associated with the resource, a resource data object, such as the resource data object <b>412</b> shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, is not required. Instead, the descriptor of the IM service, along with any other information about the service, such as the types of functions and requests that the service supports and how to format requests to the service, can be stored in other data objects and/or elements (not expressly shown) of the IM presence tuple <b>702</b>.

p-0094The IM presence tuple <b>702</b> can also include a request data object <b>714</b>, including identifier <b>716</b> and message <b>718</b> elements, as well as subject <b>720</b> and body <b>722</b> sub-elements, for storing IM message information to send to other presence entities coupled to the network <b>116</b>. A presentity associated with IM client <b>110</b><i>e </i>can use directed publish/notify commands to send messages to specific entities, or can broadcast messages to all subscribers to the IM presence tuple <b>702</b> information. Because the IM presence tuple <b>702</b> maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information <b>400</b> can be carried across the network <b>116</b> using standard presence protocol commands. It is not necessary that the presence server <b>118</b> to understand the content of the tuple <b>702</b> in order to route the information contained therein to the various presence entities coupled to the network <b>116</b>. Moreover, the arrangement shown in <figref idrefs="DRAWINGS">FIG. 7</figref> allows both conventional presence information and IM messaging information to be carried solely by the presence protocol, eliminating the need to use a separate messaging protocol to send the IM message content.

p-0095In a related exemplary embodiment, the request data object <b>416</b> can be included in a presence tuple associated with the resource or a principal associated with the requesting entity. When the request data object <b>416</b> is included in a presence tuple associated with the resource, the presence tuple associated with the resource can include a data object linking the presence tuple associated with the resource to a presence tuple associated with the principal associated with the requesting entity.

p-0096<figref idrefs="DRAWINGS">FIG. 8</figref> is a flowchart illustrating a method for providing a general request/response protocol using a presence protocol. The method can be carried out using the arrangement described in conjunction with <figref idrefs="DRAWINGS">FIGS. 1-3</figref> and the data structure described in conjunction with <figref idrefs="DRAWINGS">FIGS. 4-6</figref> above, portions of which are referenced in the description that follows. In particular, the method can be carried out using the presence server <b>118</b>. It will be understood that other arrangements and/or data structures can be used to carry out the described method without departing from the scope of the described techniques. Descriptions of certain terms, the meanings of which are described in detail above in conjunction with <figref idrefs="DRAWINGS">FIGS. 1-6</figref>, are not repeated here.

p-0097Moreover, the executable instructions of a computer program as illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref> for providing a general request/response protocol using a presence protocol can be embodied in any computer readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer based system, processor containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

p-0098The method begins in block <b>802</b>, at which the presence protocol is used for receiving, from a requesting entity, a descriptor of a resource associated with a responding entity and a request related to the resource. For example, the presence server <b>118</b> can receive the descriptor and the request from the requesting presentity component <b>202</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. In block <b>804</b>, the descriptor and the request are sent, e.g., from the presence server <b>118</b>, to the responding entity, e.g., the responding watcher component <b>204</b>. The descriptor can be included in the request as described above in conjunction with the request data object <b>416</b> shown in <figref idrefs="DRAWINGS">FIG. 5A</figref>. Alternatively, the descriptor can be included in each of respective presence protocol commands, e.g., publish and notify commands, used in receiving the request from the requesting entity and in sending the request to the responding entity.

p-0099A response from the responding entity, e.g. the responding presentity component <b>202</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>, is received, e.g. by the presence server <b>118</b>, in block <b>806</b>. The response can include a response message replying to the request message, stored, for example, in element <b>604</b> of the data structure shown <figref idrefs="DRAWINGS">FIG. 6</figref>, and an identifier of the requesting entity, stored, for example, in element <b>602</b> of the data structure. In block <b>808</b>, the response is sent, e.g., by the presence server <b>118</b>, to the requesting entity, e.g., the requesting watcher component <b>204</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. Accordingly, a general request/response protocol is formed using the commands of a presence protocol.

p-0100According to an exemplary embodiment, the presence protocol can be used for receiving, e.g., by the presence server <b>118</b>, the descriptor of the resource from the responding entity, e.g., the responding presentity component <b>202</b> shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. The descriptor of the resource can be sent to the requesting entity based on a subscription established for the requesting entity to at least some presence information of the responding entity, for example, the presence information stored in the resource data object <b>412</b>. The presence protocol can be used for automatically establishing a subscription for the responding entity to at least some presence information of the requesting entity, for example, the presence information stored in the request data object <b>416</b>, when the subscription to the presence information of the responding entity is established for the requesting entity <b>102</b>. The request sent to the responding entity can be based on the subscription automatically established for the responding entity. The automatic subscription provides an efficient mechanism of allowing the responding entity to be notified of requests from requesting entities that have subscribed to information associated with the resource.

p-0101If automatically establishing a subscription is not desired, the presence protocol can be used in an alternative embodiment for sending a notification to the responding entity indicating that the subscription to at least some of the presence information of the responding entity, for example, the presence information stored in the resource data object <b>412</b>, is established for the requesting entity. A subscription request can be received from the responding entity in response to the notification, requesting a subscription to at least some presence information of the requesting entity, for example, the presence information stored in the request data object <b>416</b>. The subscription to the presence information of the requesting entity can then be established for the responding entity based on the received subscription request. The request sent to the responding entity can then be based on the subscription established for the responding entity.

p-0102In another embodiment, the presence protocol can be used for sending the descriptor of the resource to the requesting entity in response to a fetching or a polling request by the requesting entity for at least some presence information of the responding entity. For example, rather than subscribe to the presence information of the responding entity to be notified when new resources are made available, the requesting entity can request that the presence server <b>118</b> probe the presence information of the responding entity on a periodic basis to determine if a new resource has been published, and to notify the requesting entity of such a publication.

p-0103The request sent to the responding entity can be based on a subscription established for the responding entity to at least some presence information, for example, the presence information included in the request data object <b>416</b>, of the requesting entity. Alternatively, the request can be sent to the responding entity using an identifier of the responding entity included in presence information of the requesting entity. Thus, rather than notifying the responding entity of the request based on a subscription request, the presence server <b>118</b> can notify the responding entity of the request based on a directed publish/notify of the request information sent from the requesting entity. The request can also be sent to the responding entity in response to a fetching or a polling request by the responding entity for at least some presence information of the requesting entity. Accordingly, the presence server <b>118</b> can probe the presence information of the requesting entity on a periodic basis for the request information pursuant to a polling or fetch request received from the responding entity. The presence server <b>118</b> can then notify the responding entity of the request when detected via the probe command.

p-0104Likewise, the response sent to the requesting entity can be based on a subscription established for the requesting entity to at least some presence information, for example, the presence information included in the response data object <b>414</b>, of the responding entity. Alternatively, the response can be sent to the requesting entity using an identifier of the requesting entity included in presence information of the responding entity. Thus, rather than notifying the requesting entity of the response based on a subscription request, the presence server <b>118</b> can notify the requesting entity of the response based on a directed publish/notify of the response information sent from the responding entity. The response can also be sent to the requesting entity in response to a fetching or a polling request by the requesting entity for at least some presence information of the responding entity. Accordingly, the presence server <b>118</b> can probe the presence information of the responding entity on a periodic basis for the response information pursuant to a polling or fetch request received from the requesting entity. The presence server <b>118</b> can then notify the requesting entity of the response when detected via the probe command.

p-0105According to an exemplary embodiment, the request can be included in presence information associated with the requesting entity but is not included in presence information associated with the responding entity. Similarly, the response can be included in the presence information associated with the responding entity but is not included in the presence information associated with the requesting entity. Consequently, each of the requesting and responding entities publish presence information only to their respective presence tuples. With such an arrangement, the presence service <b>120</b> and its underlying presence protocol need not be modified to allow for the exchange of request/response information included in the presence tuples.

p-0106In a related embodiment, the presence information associated with the responding entity can correspond to presence information of the resource or presence information of an owner of the resource. When the presence information associated with responding entity corresponds to presence information of the resource, the presence information of the resource can include a link to the presence information of the owner of the resource. In another related embodiment, the presence information associated with the requesting entity can correspond to presence information of a second resource associated with the requesting entity or presence information of an owner of the second resource, the second resource being configured to form the request. The reader is referred to <figref idrefs="DRAWINGS">FIG. 7</figref>, depicting a data structure for storing presence information associated with an IM resource, and its associated text for details regarding the linking of presence information of a resource and the presence information of an owner/principal of the resource.

p-0107According to an exemplary embodiment, an identity of each of the requesting and responding entities can be authenticated and a receiving by each of the entities of the request or the response can be authorized prior to sending the request or response to the respective entity. For example, as described above, the presence server <b>118</b> can include the account service <b>122</b> configured to authenticate an identity of each of the requesting and responding devices and to authorize a receiving by each of the devices of the request or the response prior to sending the request or response to the respective entity. In addition, rosters and/or privacy lists may be used by the account service <b>122</b> to authorize and authenticate access to a particular resource or to prevent providers from advertising certain resources to subscribers.

p-0108In another exemplary embodiment, a proxy service can be provided for sending the request to the responding entity through a firewall associated with the responding entity or for sending the response to the requesting entity through a firewall associated with the requesting entity. For example, referring to <figref idrefs="DRAWINGS">FIGS. 1 and 2</figref>, the presence server <b>118</b> can include a proxy service <b>124</b> configured to send the request to a responding watcher component <b>204</b> through a firewall <b>114</b> associated with the responding device <b>102</b><i>b</i>, or to send the response to a requesting watcher component through a firewall (not shown) associated with the requesting device <b>102</b><i>c. </i>

p-0109According to another embodiment, the presence protocol can be used for receiving from the responding entity a second descriptor of a second resource associated with a second responding entity and a second request related to the second resource. The second request can be related to the response replying to the request from the requesting entity. The presence protocol can also be used for sending the second descriptor and the second request to the second responding entity. Consequently, the original responding entity can function as a requesting entity and can make requests of other responding entities when processing the original received request. Such an arrangement can be used to support workflows among various presence entities to efficiently carry out complex multi-entity transactions.

p-0110For example, <figref idrefs="DRAWINGS">FIG. 9</figref> illustrates the flow of information among presence entities that can occur in carrying out a multi-entity online purchase transaction. The arrangement of <figref idrefs="DRAWINGS">FIG. 9</figref> includes a presence server <b>902</b> and presence entities representing a customer <b>906</b> and an online store <b>904</b>. Additional presence entities representing a shipping provider <b>908</b> and a credit provider <b>910</b> are also shown. The customer entity <b>906</b> can begin a transaction by publishing, to the presence server <b>902</b>, presence information <b>912</b> including a request to purchase a book from the online store entity <b>904</b>. The presence information <b>912</b> includes an identifier (“customer@isp.net”) of the customer entity <b>906</b> as a “from” presence attribute, and an identifier/descriptor (“sales@online.com/books”) of a resource associated with the online store entity <b>904</b> as a “to” presence attribute of a directed publish/notify command. Alternatively, the presence information <b>912</b> could be broadcast to the presence server <b>902</b> by the customer entity <b>906</b>.

p-0111The request included in the presence information <b>912</b> can include information specifying the title of the book (“My Book”), the quantity to be ordered (“1”), payment information, including a payment type, such as a credit card (“Card”), and other related payment information including a card number (“999999999”) and expiration date (“0808”). The request can also include shipping information, including a shipping type, such as by parcel post (“Parcel”), and other related shipping information including a shipping address (“1234 Street City, ST, 00000”).

p-0112Once published, the presence information <b>912</b> including the request can be sent by the presence server <b>902</b> to the online store entity <b>904</b>. The presence information <b>912</b> including the request can be sent to the online store entity <b>904</b> via the notify portion of a directed publish/notify command (as shown), or can be sent via a notify command in response to a subscription by the online store entity <b>904</b> to the presence information <b>912</b> of the customer entity <b>906</b>. The request can then be processed by the online store's “books” service. In processing the request from the customer entity <b>906</b>, the online store entity <b>904</b> may broadcast requests to the presence server <b>902</b> for notification to other responding entities, such as the shipping <b>908</b> and credit <b>910</b> provider entities. Each of these entities can be subscribed to the presence information <b>914</b> of the online store entity <b>904</b> as denoted by the dotted lines included in the figure. The presence information <b>914</b> broadcast by the online store <b>904</b> entity can include requests for the shipping <b>908</b> and credit <b>910</b> provider entities.

p-0113Each of the shipping <b>908</b> and credit <b>910</b> provider entities can receive notifications from the presence server <b>902</b> pursuant to their subscriptions to the presence information <b>914</b> of the online store entity <b>904</b>. For example, the shipping provider entity <b>908</b> can receive presence information <b>916</b> including the online store's shipping request. The shipping request can result in one title of the book “My Book” being shipped to the address included in the presence information <b>912</b> of the customer entity <b>906</b>. In addition, the credit provider entity <b>910</b> can receive presence information <b>918</b> including the online store's credit request. The credit request can result in credit from the account “999999999” being provided by the credit provider entity <b>910</b> on behalf of the customer entity <b>906</b> for the purchase price of the book.

p-0114Note that the credit provider entity <b>910</b> can also be subscribed to the presence information <b>912</b> of the customer entity <b>906</b> (again, as denoted by the dashed line in the figure). As a result of the subscription, the credit provider entity <b>910</b> can preprocess a request for credit from the online store <b>904</b> on behalf of the customer entity <b>906</b> at the time the request to purchase the book is made by the customer entity <b>906</b>. Consequently, credit can be pre-approved for the purchase at the time the order is fulfilled by the online store, resulting in an overall more efficient transaction.

p-0115In an alternate embodiment, rather than the online store entity <b>904</b> issuing a request directed to the shipping provider <b>908</b> and the credit provider <b>910</b> entities as described above, the shipping provider <b>908</b> and credit provider <b>910</b> entities can receive notifications related to their services pursuant to outstanding subscriptions to all responses published by the online store entity <b>904</b> that specify their services. Such an arrangement allows the shipping provider <b>908</b> and credit provider <b>910</b> entities to monitor the request/response transaction between the customer entity <b>906</b> and online store entity <b>904</b> for relevant transaction information.

p-0116For example, consider when the online store entity <b>904</b> publishes a response to the customer entity's <b>906</b> request for a book purchase, the customer can receive a notification that the order is “in process”. The shipping provider <b>908</b> and credit provider <b>910</b> entities, which are subscribed to the published response, receive first notifications pursuant to their existing subscriptions. The credit provider entity <b>910</b> may ignore this first notification, for example, if shipping costs have not been calculated and included in the published presence information. The shipping provider entity <b>908</b> can publish data (or send the data outside the presence service or “out-of-band”) to the online store <b>904</b> providing shipping charges and perhaps a pickup date.

p-0117The online store <b>904</b> entity can then update its response tuple with the new shipping information and publish this information to the presence server <b>902</b>. At this point, the customer <b>906</b> entity can receive a notification with the new shipping information and perhaps a new transaction status indicator, such as “shipping approved”. The credit provider entity <b>910</b> can receive a second notification based on its subscription to the online store entity's <b>904</b> response. The credit provider entity <b>910</b> can determine from the notification that a total transaction cost (e.g., cost of the book plus the new shipping charges) is now available. The credit provider entity <b>910</b> can then approve the charges and publish data (or send the data out-of-band) to the online store entity <b>904</b> indicating that the charge has been approved. The online store entity <b>904</b> can then publish new status information to the existing response tuple indicating that the status of the transaction is “order completed”. The customer entity <b>906</b> can then receive a notification from the presence server <b>902</b> with the new status information.

p-0118Instead of the requesting and responding entities publishing presence information only to their respective presence tuples, a method is now described that allows a requesting entity to update the responding entity's presence information by adding a request related to the resource to the responding entity's presence tuple. With this methodology, the entire request/response transaction can occur using information stored in a single presence tuple. For example, the data structure shown in <figref idrefs="DRAWINGS">FIG. 4</figref> can be configured to store the presence information of both a responding and requesting entity. But rather than the responding and requesting entities being associated with the same principal and configured to respond to and make requests related to different resources (as described in conjunction with method illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref>), the responding and requesting entities can be associated with different principals and configured to respond and make requests related to a common resource.

p-0119As described above, such a methodology requires a change to the standard presence services access control policies, and could lead to a more complex access control system. Nevertheless, performing the entire request/response transaction using information stored in a single presence tuple associated with the resource or owner of the resource could lead to efficiencies in data storage usage and data exchange.

p-0120The exemplary method includes receiving presence information from a responding entity including a descriptor of a resource associated with the responding entity. A request is received along with a descriptor related to the resource from a requesting entity. The request include a request message related to the resource. The presence information of the responding entity is updated to include the request message. The presence information is received from the responding entity, including a response message replying to the request message. The response message is then sent to the requesting entity.

ILLUSTRATIVE EXAMPLE

p-0121The following illustrative example is provided in conjunction with the signal flow diagram shown in <figref idrefs="DRAWINGS">FIG. 10</figref> to clarify the concepts described above. The actions carried out in the example are for illustrative purposes, and should not be construed as being limiting in any way. Nor should the numerical order of the steps, either in the text below or as shown in <figref idrefs="DRAWINGS">FIG. 10</figref>, be construed as limiting or necessary in any way. In the example, users (through their presence entities and agents) are allowed to update only their own presence tuples. This approach allows a request response protocol to be provided using a presence protocol without having to change the structure of the underlying presence service.

p-0122The example is directed to an arrangement in which a standard presence tuple is extended to support a web service resource, such as the photo sharing web service <b>104</b><i>a </i>shown in <figref idrefs="DRAWINGS">FIG. 2</figref>. The photo sharing service can be a web site accessible or hosted by a responding entity, such as the PC <b>102</b><i>b</i>. The PC <b>102</b><i>b </i>can include a presentity component/PUA, a watcher component/WUA and various communication clients <b>110</b>. The PC <b>102</b><i>b </i>can be protected by a firewall <b>114</b>.

p-0123First, a resource data object <b>412</b> is added to a standard presence tuple <b>402</b> in the portion intended for extended data, as shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. In the example, the presence tuple <b>402</b> corresponds to an owner, Xena, of the web service, but could correspond to the web server itself. The resource data object <b>412</b> is used to store information, such as a descriptor, related to the photo sharing service. In addition, one or more response data objects <b>414</b> are added to the presence tuple <b>402</b> to store responses to requests made to the service.

p-0124The resource <b>412</b> and response <b>414</b> data objects can be added to the presence tuple <b>402</b> using an RSUA associated with the photo sharing service. The RSUA is an extension to the Xena's presentity and also is configured to update the resource <b>412</b> and response <b>416</b> data objects of Xena's presence tuple <b>402</b> with corresponding service and response information. For example, the RSUA can detect the activity of the web site on the PC <b>102</b><i>b </i>and update, in action <b>1002</b>, the service owner's (Xena's) presence tuple <b>402</b> with information, such as a service descriptor, related to the web service. The RSUA can then facilitate the advertising of the photo sharing service to other presence entities in action <b>1004</b> by instructing Xena's presentity (and any associated PUA) to publish the presence information including the descriptor of the photo sharing service.

p-0125In the example, a friend of Xena, Mike, operates a requesting device, such as the camera phone <b>102</b><i>c</i>. The camera phone <b>102</b><i>c </i>can include a presentity component/PUA, a watcher component/WUA and various communication clients <b>110</b>, such as the IM client <b>102</b><i>b </i>and the browser <b>110</b><i>f </i>client. The browser client <b>110</b><i>f </i>can be used for exchanging information with web services, such as Xena's photo sharing service. The camera phone <b>102</b><i>c </i>can also be protected by a firewall (not shown).

p-0126Mike subscribes to Xena's presence tuple <b>402</b> in action <b>1006</b>. Mike's subscription can cause a subscription to be automatically established to Mike's presence tuple on behalf of Xena's presentity in action <b>1008</b>. Alternatively, Mike's presentity component can notify Xena of his subscription, allowing Xena to then request a subscription to Mike's presence tuple. The subscription to Mike's presence tuple allows Xena's watcher component to be notified of photo sharing service requests that are published with Mike's presence tuple. An account service <b>122</b> can be included in the presence server <b>118</b> for authenticating Mike's and Xena's identities to the other, and for authorizing the receiving of information from the presence service <b>118</b>.

p-0127In action <b>1010</b>, Mike's watcher receives a notify message from the presence server <b>118</b> in response to the subscription established in action <b>1006</b>. A proxy service <b>124</b> can be used to route the notify message through Mike's firewall (not shown). The notify message sent in action <b>1006</b> includes the descriptor of Xena's photo sharing service. The camera phone <b>102</b><i>c </i>can include a RQUA that is configured to process Xena's presence information in cooperation the WUA. The RQUA can display the presence information, including the descriptor of the photo sharing service, in action <b>1012</b> using an appropriate communication client, such as the IM client <b>102</b><i>b </i>shown in <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0128The RQUA can also be configured to add a request data object <b>416</b> to Mike's presence tuple. The request data object <b>416</b> can be added to the portion of the presence tuple <b>402</b> intended for extended data, as shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. In response to Mike selecting Xena's web service using the IM client <b>110</b><i>f</i>, the RQUA (in cooperation, perhaps, with the PUA) can use other information included in the resource data object <b>412</b> of Xena's presence tuple, such as information describing the form of service request, to include a request message in, action <b>1014</b>, the request data object <b>416</b> of Mike's presence tuple along with the descriptor of the photo sharing service. The request can be for a web page advertised as being available through Xena's photo sharing server. The RQUA then instructs the camera phone's presentity to publish the request in action <b>1016</b>.

p-0129In action <b>1018</b>, the presence server <b>118</b> sends a notify command to Xena's watcher component pursuant to the subscription request established in action <b>1008</b>. Again, the proxy service <b>124</b> can be used to route the notify message through Xena's firewall <b>114</b>. Xena can be informed of the request, or the request can be automatically processed in action <b>1020</b> using the PC's RSUA and/or WUA. For example, the RSUA can convert the request for a particular web page into an appropriate HTTP request that can be routed to the photo sharing service for processing. The RSUA then receives the response from the photo sharing service, and perhaps converts the response to an appropriate message format for transmission. In action <b>1022</b>, the response message is stored in the response data object <b>414</b> of Xena's presence tuple. The RSUA then instructs Xena's presentity to publish the presence tuple, including the response, to the presence server <b>118</b> in action <b>1024</b>.

p-0130In action <b>1026</b>, the presence server sends a notify command to Mike's watcher component pursuant to the subscription request established in action <b>1006</b>, again perhaps using the proxy service <b>124</b>. Mike can be informed of the response or the response can be automatically processed in action <b>1028</b> using the camera phone's RQUA and/or WUA. For example, the RQUA can convert the response message including the requested web page into an appropriate HTTP response that can be routed to Mike's browser client <b>110</b><i>f </i>for displaying the requested web page on the display of Mike's camera phone <b>102</b><i>c. </i>

p-0131Methods, system, and data structure for providing a general request/response messaging protocol using a presence protocol have been described. Using the techniques described here, the publish-subscribe mechanisms of the presence protocol can be expanded to provide general request/response services. The resultant general request/response protocol includes the advantageous features of a presence service, including authentication, authorization, security, and proxies for firewall piercing. The techniques described here allow for the development of enhanced applications, services, and workflows having characteristics not present in conventional applications, services, and workflows that use a presence protocol or a request/response protocol alone. In addition, the presence service supports centralized, distributed, peer-to-peer, and mixed architectures for implementing such enhanced applications, services, and workflows.

p-0132It will be appreciated by those of ordinary skill in the art that the concepts and techniques described here can be embodied in various specific forms without departing from the essential characteristics thereof. The presently disclosed embodiments are considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims, rather than the foregoing description, and all changes that come within the meaning and range of equivalence thereof are intended to be embraced.