US20090254627A1 - Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol - Google Patents

Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol Download PDF

Info

Publication number
US20090254627A1
US20090254627A1 US12/485,261 US48526109A US2009254627A1 US 20090254627 A1 US20090254627 A1 US 20090254627A1 US 48526109 A US48526109 A US 48526109A US 2009254627 A1 US2009254627 A1 US 2009254627A1
Authority
US
United States
Prior art keywords
request
entity
resource
responding
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/485,261
Inventor
Robert Paul Morris
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Scenera Technologies LLC
Original Assignee
Swift Creek Systems LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Swift Creek Systems LLC filed Critical Swift Creek Systems LLC
Priority to US12/485,261 priority Critical patent/US20090254627A1/en
Assigned to SCENERA TECHNOLOGIES, LLC reassignment SCENERA TECHNOLOGIES, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MORRIS, ROBERT P.
Assigned to SWIFT CREEK SYSTEMS, LLC reassignment SWIFT CREEK SYSTEMS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCENERA TECHNOLOGIES, LLC
Publication of US20090254627A1 publication Critical patent/US20090254627A1/en
Assigned to SCENERA TECHNOLOGIES, LLC reassignment SCENERA TECHNOLOGIES, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SWIFT CREEK SYSTEMS, LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/54Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Definitions

  • the present application is a continuation of co-pending U.S. patent application Ser. No. 11/160,157, entitled “Method, System, and Data Structure for Providing a General Request/Response Messaging Protocol Using a Presence Protocol.”
  • the present application is also related to co-pending U.S. patent application Ser. No. 11/118,882 entitled “System and Method for Utilizing a Presence Service to Advertize 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.
  • 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.
  • 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.”
  • IM instant messaging
  • 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).
  • 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.
  • 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.
  • a tuple in its broadest sense, is a data object containing one or more components.
  • 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.
  • the 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.
  • the fetcher class of watchers requests (or fetches) the current value of some presentity's presence information from the presence service.
  • 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.
  • the 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.
  • 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.
  • 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.
  • 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.
  • 3GPP 3rd Generation Partnership Project
  • UMTS Universal Mobile Telecommunications System
  • 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.
  • a principal can interact with the presence system through a presence user agent (PUA) or a watcher user agent (WUA).
  • PUA presence user agent
  • WUA watcher user agent
  • 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.
  • IM applications use presence services only to determine an application user's presence, status, and communication address.
  • 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.
  • presence aware applications and extensions to presence services would be expected to use new protocols to support these applications or extended services.
  • developers would be expected to use a specific request/response protocol, separate from the presence protocol, to support the request/response services.
  • 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.
  • HTTP Hypertext Transfer Protocol
  • SMTP Simple Mail Transfer 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.
  • 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.
  • 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.
  • 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).
  • SIP Session Initiation Protocol
  • a method and system are disclosed for providing a general request/response protocol using a presence protocol.
  • 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.
  • a method 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.
  • a method 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.
  • a computer readable medium 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.
  • a system 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.
  • FIG. 1 illustrates a system for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.
  • FIG. 2 is a block diagram illustrating the various components that can form a responding and/or requesting network devices according to an exemplary embodiment.
  • FIG. 3 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.
  • FIG. 4 illustrates a data structure for use with a presence protocol in providing a general request/response protocol according to an exemplary embodiment.
  • FIGS. 5A and 5B show an expanded view of a request data object included in the data structure of FIG. 4 according to an exemplary embodiment.
  • FIG. 6 shows an expanded view of a response data object included in the data structure of FIG. 4 according to an exemplary embodiment.
  • FIG. 7 depicts a data structure for storing presence information associated with an IM resource according to an exemplary embodiment.
  • FIG. 8 is a flowchart illustrating a method for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.
  • FIG. 9 illustrates an exemplary flow of information occurring among presence entities in carrying out a multi-entity transaction.
  • FIG. 10 is signal flow diagram for an illustrative request/response scenario according to an exemplary embodiment.
  • This set of commands includes:
  • a system 100 for providing a general request/response protocol using a presence protocol.
  • the system includes a presence server 118 configured to receive, store, and distribute information via a presence service 120 .
  • the system further includes responding and requesting devices 102 configured to exchange information with the presence server 118 via the network 116 using a presence protocol.
  • the responding and requesting devices 102 can include any of Personal Computers (PCs), Personal Digital Assistants (PDAs), network-enabled cameras, camera phones, cell phones, and the like.
  • the presence server 118 can include several servers (not shown) that together can function as the presence service 120 . Moreover, the function of the presence server 118 can be incorporated, either in whole or in part, into any of the devices 120 and server 118 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 118 and presence service 120 are closely link to one another and can be considered to perform one and the same function.
  • the presence server 118 can also include additional services, such as the account service 122 and proxy service 124 shown in FIG. 1 , although these additional services need not be included in the server 118 . It will be understood that these additional services can also be distributed across one or more servers or devices 102 interconnected via the network 116 .
  • a responding device can be, for example, a PC, such as the PC 102 b shown in FIG. 1 .
  • the responding device 102 b 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 102 a or camera phone 102 c , via the network 116 .
  • FIG. 1 shows that the responding device 102 b can provide resources including services 104 (e.g., web services, such as a photo sharing website), software applications 108 , and files 112 (such as image files).
  • Requesting devices such as the camera 102 a or camera phone 102 c , can request information or services related to these resources using the presence service 120 via the network 116 .
  • FIG. 2 is a block diagram illustrating the various components that can make up the responding and/or requesting network devices 102 .
  • the arrangement shown in FIG. 2 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.
  • the figure includes a responding/requesting presentity component 202 and responding/requesting watcher component 204 . It will be understood that each of these components can be combined into a single respective presentity 202 or watcher 204 component, or can be implemented as separate responding and requesting entities as described below.
  • the arrangement includes a responding presentity component 202 .
  • the responding presentity component 202 can be configured to send a descriptor of the resource 104 , 108 , 112 to the presence server 118 .
  • the descriptor can include any information that describes and/or identifies any of the resources 104 , 108 , 112 available to the responding device, and can be used to advertise the availability of those resources to requesting devices for processing their requests.
  • FIG. 2 shows that the responding device 102 b has access to web services 104 , including a photo sharing web service 104 a and other web services 104 b , a file system 112 , printer services 104 c , and camera services 104 d .
  • 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 116
  • the responding presentity component 202 can send the descriptor of the resource to the presence server 118 by including the descriptor in presence information as described in conjunction with FIGS. 4-6 below.
  • the presence information including the descriptor can be sent to the presence server 118 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.
  • the responding presentity component 202 need not send the descriptor of the resource 104 , 108 , 112 to the presence server 118 to advertise the availability of the resource for processing requests. Instead, requesting devices coupled to the presence server 118 can broadcast a standardized request without a descriptor for processing by any of all of the resources 104 , 108 , 112 associated with responding devices coupled to the presence server 118 via the network 116 .
  • the arrangement further includes a responding watcher component 204 .
  • the responding watcher component 204 is configured to receive from a requesting device (e.g., the camera phone 102 c ), via the presence server 118 , the descriptor of the resource 104 , 108 , 112 and a request related to the resource.
  • the presence server 118 can send the descriptor and the request to the responding watcher component 204 via the presence protocol using a notify command.
  • the notify command including the descriptor and request may be sent to the responding watcher component 204 based on a subscription to the presence information of the requesting device 102 c , as a result of a directed publish/notify command sent by the requesting device 102 c for delivery to the responding device 102 b , or in response to a fetch or polling request made by responding device 102 b.
  • 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 104 , 108 , 112 available to the responding device 102 b , and the request message can be used to carry the resource request.
  • the responding device 102 b can process multiple requests for different resources 104 , 108 , 112 corresponding to the various requesting devices 102 c connected to the network 116 .
  • the responding presentity component 202 is further configured to send a response to the presence server 118 replying to the request message.
  • the responding presentity component 202 can send the response to the presence server 118 by including the response in presence information as described in conjunction with FIGS. 4-6 below.
  • the presence information including the response can be sent to the presence server 118 via the presence protocol using either a broadcast or directed publish command.
  • the responding device can include a responding user agent (RSUA).
  • the RSUA component is coupled to the resource 104 , 108 , 112 and to the responding presentity 202 and watcher 204 components.
  • the RSUA can interact with the responding presentity 202 and watcher 204 components on behalf of a principal.
  • the RSUA will interact with the resource 104 , 108 , 112 as its principal, although the RSUA can also interact with an owner of the resource as well as other principals.
  • the RSUA component can be configured to facilitate a sending of the descriptor of the resource by the responding presentity component 202 to advertise the resource to other presence entities coupled to the network 116 .
  • the RSUA component can interact with the resource 104 , 108 , 112 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.
  • the RSUA can be coupled to a user communication client 110 a or any number of associated communication clients, such as an IM communication client 110 b , a phone client 110 c , an email client 110 d , a Multimedia Messaging Service (MMS) client 110 d , and a browser client 110 f (collectively, communication clients 110 ) as shown in FIG. 2 .
  • IM communication client 110 b a phone client 110 c
  • an email client 110 d a Multimedia Messaging Service (MMS) client 110 d
  • MMS Multimedia Messaging Service
  • browser client 110 f collectively, communication clients 110
  • FIG. 3 illustrates an interface that may be used by an owner of the resource 104 , 108 , 112 to interact with the responding presentity component 202 to publish the descriptor of the resource.
  • the exemplary interface can be presented on a display 300 in the form a “friends list” 302 , recognizable to those familiar with IM applications.
  • the friends list 302 can include the names of human resource owners, e.g., John, Paul, George, and Ringo, and/or non-human resource owners, e.g., Server1.
  • the friends list 302 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.
  • the resources associated with John in the exemplary list 302 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).
  • N/A print service that is not available
  • 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).
  • the interface 302 can also include an Actions menu item 306 , suitable for invoking commands associated with resources.
  • the Actions menu can include entries 306 a 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.
  • the RSUA can be further configured to facilitate a processing by the resource 104 , 108 , 112 of the request received by the responding watcher component 204 .
  • the RSUA can be configured to forward the request to the appropriate resource 104 , 108 , 112 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 104 a illustrated in FIG. 2 , 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).
  • the 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.
  • the interface 302 shown in FIG. 3 is illustrated as presenting a dialog box 304 indicating that a user, George, has requested access to a printer service (e.g., service 104 c of FIG. 2 ) 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.
  • the RSUA can be further configured to facilitate a sending of the response to the request by the responding presentity component 202 .
  • the RSUA component can interact with the resource 104 , 108 , 112 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 306 a of FIG. 3 , 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 202 for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the response as needed.
  • the RSUA may act in conjunction with appropriate PUAs and/or WUAs or may bypass the operation of these agents.
  • 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.
  • 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.
  • the arrangement includes a requesting watcher component 204 which can be configured to receive the descriptor of the resource 104 , 108 , 112 if sent from the presence server 118 .
  • the presence server 118 can send the descriptor to the requesting watcher component 204 via the presence protocol using a notify command.
  • the notify command including the descriptor may be sent to the requesting watcher component 204 based on a subscription to the presence information of the responding device 102 b , as a result of a directed publish/notify command sent by the responding device 102 b for delivery to the requesting device 102 c , or in response to a fetch or polling request made by the requesting device 102 c .
  • 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.
  • the arrangement further includes a requesting presentity component 202 configured to send the descriptor and the request related to the resource to the presence server 118 .
  • the requesting presentity component 202 can send the request to the presence server 118 by including the request in presence information as described in conjunction with FIGS. 4-6 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 118 via the presence protocol using either a broadcast or directed publish command.
  • the requesting watcher component 204 is further configured to receive via the presence server 118 the response replying to the request message.
  • the presence server 118 can send the response to the requesting watcher component 204 via the presence protocol using a notify command.
  • the notify command including the response may be sent to the requesting watcher component 204 based on a subscription to the presence information of the responding device 102 b , as a result of a directed publish/notify command sent by the responding device 102 b for delivery to the requesting device 102 c , or in response to a fetch or polling request made by the requesting device 102 c.
  • the requesting device can include a requesting user agent (RQUA) component coupled to the requesting presentity 202 and watcher 204 components.
  • RQUA requesting user agent
  • the RQUA can also be coupled to the communication clients 110 a - 110 f shown in FIG. 2 for interacting with a user/principal of the requesting device 102 c .
  • the RQUA can be configured to facilitate a presentation of the descriptor received by the requesting watcher component 204 .
  • the RQUA can present a descriptor of a resource received by the requesting watcher component 204 , such as the photo sharing web service shown as being owned by John or the programs and service shown as being owned by Server1 in FIG. 2 .
  • the descriptor can be presented in the interface 302 together with information describing the owner of the resource and a status of the resource.
  • the RQUA can also be configured to facilitate a sending of the request by the requesting presentity component 202 .
  • 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 102 c .
  • an interface such as the interface 302 shown in FIG. 3 , can be presented to a user/principal of the requesting device 102 c to gather information needed to form the request.
  • 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 202 for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the request as needed.
  • the RQUA can also be configured to facilitate a presentation of the response received by the requesting watcher component 204 .
  • the RQUA could invoke the browser client 110 f of the requesting device 102 c shown in the figure to display the served web page.
  • the RQUA can effectively establish itself as a proxy for processing requests directed to and responses received from presence server 118 .
  • the RQUA can present a dialog box to receive authorization or additional information from a user/principal prior to acting on the response.
  • the RQUA may act in conjunction with appropriate PUAs and/or WUAs or may bypass the operation of these agents.
  • 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.
  • the presence server 118 can include the proxy service 124 .
  • the proxy service 124 can be configured to send the request to the responding watcher component 204 through a firewall 114 associated with the responding device 102 b or to send the response to the requesting watcher component through a firewall (not shown) associated with the requesting device 102 c .
  • the presence server 118 can also include the account service 122 .
  • the account service 122 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.
  • Rosters and/or privacy lists may be used by the account service 122 to authorize and authenticate access to a particular resource or to prevent providers from advertising certain resources to subscribers.
  • 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 128 coupled to the account service 122 . Multiple rosters and/or privacy lists may be maintained in the database 128 and used by the service 122 . 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.
  • FIG. 4 a data structure is illustrated for use with a presence protocol in providing a general request/response protocol.
  • the data structure shown in FIG. 4 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.
  • 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.
  • the data structure shown in FIG. 4 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.
  • 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).
  • RAM random access memory
  • ROM read only memory
  • EPROM or Flash memory erasable programmable read only memory
  • CDROM portable compact disc read only memory
  • the data structure shown in FIG. 4 represents presence information 400 that includes an enhanced presence tuple 402 .
  • the presence information 400 can be stored in a database coupled to the presence server 118 shown in FIG. 1 , such as the presence information database 126 .
  • a single database 126 is shown in FIG. 1 , persons skilled in the art will understand that the presence information can be distributed throughout the network 116 across multiple databases and/or stored, at least in part, in memory associated with the requesting and/or responding devices 102 shown in FIG. 1 .
  • the presence tuple 402 shown in FIG. 4 includes standard data objects for storing the status 404 and communication address 406 information described in RFC 2778 and RFC 2779.
  • the presence tuple 402 also includes data objects for storing a contact means 408 and contact address 410 , as well as a data object for storing other markup 418 , thus maintaining the extensibility of the tuple 402 in accordance with presence standards. Because the presence tuple 402 maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information 400 can be carried across the network 116 using standard presence protocol commands. It is not necessary that the presence server 118 to understand the content of the tuple 402 in order to route the information contained therein to the various presence entities coupled to the network 116 .
  • the presence tuple 402 includes a resource data object 412 , including an element (not expressly shown) for storing a descriptor of a resource associated with a responding entity.
  • the descriptor can include any information that describes and/or identifies the resource available to the responding entity, such as any of the resources 104 , 108 , 112 shown in FIG. 1 .
  • the responding entity can be, for example, the responding presentity component 202 shown in FIG. 2 .
  • the resource data object 412 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 412 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.
  • the presence tuple 402 also includes a request data object 416 .
  • 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 202 shown in FIG. 2 .
  • FIG. 5A shows an expanded view of the request data object 416 according to an exemplary embodiment.
  • the expanded view of the request data object 416 can include an element for storing a request message 504 related to the resource.
  • the request data object 416 can also include a descriptor element 502 for storing a descriptor of a resource associated with the responding entity.
  • the descriptor element 502 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).
  • URI Uniform Resource Identifier
  • the descriptor stored in element 502 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.
  • 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 118 can use the descriptor stored in the element 502 both to route the request message stored in element 504 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.
  • FIG. 5B shows an expanded view of the request data object 416 according to an alternative embodiment.
  • the request data object 416 does not include an element for storing the descriptor of the resource associated with the responding entity (e.g., element 502 shown in FIG. 5A ).
  • 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:
  • the descriptor can be included in a presence attribute, “sales@online.com/books”, used by the presence server 118 to route the notify portion of the directed publish/notify command to the responding entity.
  • the requesting entity 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:
  • 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.
  • the request data object can also include an element for storing an identifier of the responding entity.
  • the expanded view of the exemplary request data object 416 shown in FIG. 5B includes an identifier element 506 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.
  • the identifier stored in element 506 serves a similar function to the descriptor stored in element 502 of the arrangement shown in FIG. 5A .
  • the identifier 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.
  • the request message stored in element 504 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.
  • RPC Remote Procedure Call
  • SOAP originally was an acronym for Simple Object Access Protocol, but the acronym has been dropped in Version 1.2 of the SOAP specification.
  • W3C World Wide Web Consortium
  • 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.
  • the presence tuple 402 also includes a response data object 414 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 202 shown in FIG. 2 .
  • FIG. 4 depicts two response data objects 414 linked to the resource data object 412 in the presence tuple 402 .
  • 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.
  • the arrangement shown in FIG. 4 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.
  • FIG. 6 shows an expanded view of the response data object 414 according to an exemplary embodiment.
  • the expanded view of the response data object 414 can include an element for storing a response message 604 replying to the request message stored in element 504 .
  • the response message stored in element 604 can be an XML-based message formed in the structure of a SOAP message.
  • the response data object 414 can also include an identifier element 602 (similar to the identifier element 506 shown in FIG. 5B ) for storing an identifier, such as a URI, of the requesting entity.
  • the presence server 118 can use the identifier stored in the element 602 to route the response message stored in element 604 of the presence tuple 402 to the requesting entity.
  • the presence server 118 can use this identifier under circumstances when both the responding entity's presence information is being broadcast to all presence entities coupled to the network 116 (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.
  • the identifier can be used by the requesting entity (“customer@isp.net”) to determine that the response is in reply to its own request.
  • 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 414 .
  • binary data can be supported through the use of attachments.
  • 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.
  • 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.
  • binary data pass through and/or be stored in a presence tuple encoded in a text format, such that presence server 118 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.
  • the resource 412 and response 414 data objects can be included in a presence tuple associated with the resource or an owner of 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.
  • FIG. 7 depicts a data structure for storing presence information associated with an IM resource, such as the IM client 110 b shown in FIG. 2 .
  • the presence information 400 includes an IM presence tuple 702 corresponding to the IM client 110 b , and other IM presence tuples 702 corresponding to other IM clients (not shown) coupled to the network 116 .
  • the IM presence tuple 702 includes standard data objects for storing a service status 704 , a communication address 706 , including elements for storing a contact means 708 and contact address 710 , and a data object for storing other markup information 418 .
  • the information stored in the status 704 and communication address 706 data objects can represent the status and communication address of an owner or principal associated with the IM client 110 b and/or the status and communication address of the IM client 110 b.
  • the IM presence tuple 702 can also include a data object 712 for storing information linking information in the owner/principal's presence tuple (not shown) to the IM presence tuple 702 .
  • a resource data object such as the resource data object 412 shown in FIG. 4 , is not required.
  • 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 702 .
  • the IM presence tuple 702 can also include a request data object 714 , including identifier 716 and message 718 elements, as well as subject 720 and body 722 sub-elements, for storing IM message information to send to other presence entities coupled to the network 116 .
  • a presentity associated with IM client 110 e can use directed publish/notify commands to send messages to specific entities, or can broadcast messages to all subscribers to the IM presence tuple 702 information. Because the IM presence tuple 702 maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information 400 can be carried across the network 116 using standard presence protocol commands.
  • the presence server 118 it is not necessary that the presence server 118 to understand the content of the tuple 702 in order to route the information contained therein to the various presence entities coupled to the network 116 . Moreover, the arrangement shown in FIG. 7 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.
  • the request data object 416 can be included in a presence tuple associated with the resource or a principal associated with the requesting entity.
  • 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.
  • FIG. 8 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 FIGS. 1-3 and the data structure described in conjunction with FIGS. 4-6 above, portions of which are referenced in the description that follows.
  • the method can be carried out using the presence server 118 .
  • 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 FIGS. 1-6 , are not repeated here.
  • executable instructions of a computer program as illustrated in FIG. 8 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.
  • the method begins in block 802 , 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.
  • the presence server 118 can receive the descriptor and the request from the requesting presentity component 202 shown in FIG. 2 .
  • the descriptor and the request are sent, e.g., from the presence server 118 , to the responding entity, e.g., the responding watcher component 204 .
  • the descriptor can be included in the request as described above in conjunction with the request data object 416 shown in FIG. 5A .
  • 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.
  • a response from the responding entity is received, e.g. by the presence server 118 , in block 806 .
  • the response can include a response message replying to the request message, stored, for example, in element 604 of the data structure shown FIG. 6 , and an identifier of the requesting entity, stored, for example, in element 602 of the data structure.
  • the response is sent, e.g., by the presence server 118 , to the requesting entity, e.g., the requesting watcher component 204 shown in FIG. 2 .
  • a general request/response protocol is formed using the commands of a presence protocol.
  • the presence protocol can be used for receiving, e.g., by the presence server 118 , the descriptor of the resource from the responding entity, e.g., the responding presentity component 202 shown in FIG. 2 .
  • 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 412 .
  • 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 416 , when the subscription to the presence information of the responding entity is established for the requesting entity 102 .
  • 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.
  • 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 412 , 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 416 .
  • 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.
  • 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 118 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.
  • the 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 416 , of the requesting entity.
  • the request can be sent to the responding entity using an identifier of the responding entity included in presence information of the requesting entity.
  • the presence server 118 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.
  • the presence server 118 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 118 can then notify the responding entity of the request when detected via the probe command.
  • 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 414 , of the responding entity.
  • the response can be sent to the requesting entity using an identifier of the requesting entity included in presence information of the responding entity.
  • the presence server 118 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.
  • the presence server 118 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 118 can then notify the requesting entity of the response when detected via the probe command.
  • 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.
  • 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 120 and its underlying presence protocol need not be modified to allow for the exchange of request/response information included in the presence tuples.
  • 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.
  • the presence information of the resource can include a link to the presence information of the owner of the resource.
  • 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.
  • FIG. 7 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.
  • 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.
  • the presence server 118 can include the account service 122 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.
  • rosters and/or privacy lists may be used by the account service 122 to authorize and authenticate access to a particular resource or to prevent providers from advertising certain resources to subscribers.
  • 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.
  • the presence server 118 can include a proxy service 124 configured to send the request to a responding watcher component 204 through a firewall 114 associated with the responding device 102 b , or to send the response to a requesting watcher component through a firewall (not shown) associated with the requesting device 102 c.
  • 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.
  • FIG. 9 illustrates the flow of information among presence entities that can occur in carrying out a multi-entity online purchase transaction.
  • the arrangement of FIG. 9 includes a presence server 902 and presence entities representing a customer 906 and an online store 904 . Additional presence entities representing a shipping provider 908 and a credit provider 910 are also shown.
  • the customer entity 906 can begin a transaction by publishing, to the presence server 902 , presence information 912 including a request to purchase a book from the online store entity 904 .
  • the presence information 912 includes an identifier (“customer@isp.net”) of the customer entity 906 as a “from” presence attribute, and an identifier/descriptor (“sales@online.com/books”) of a resource associated with the online store entity 904 as a “to” presence attribute of a directed publish/notify command.
  • the presence information 912 could be broadcast to the presence server 902 by the customer entity 906 .
  • the request included in the presence information 912 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”).
  • the presence information 912 including the request can be sent by the presence server 902 to the online store entity 904 .
  • the presence information 912 including the request can be sent to the online store entity 904 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 904 to the presence information 912 of the customer entity 906 .
  • the request can then be processed by the online store's “books” service.
  • the online store entity 904 may broadcast requests to the presence server 902 for notification to other responding entities, such as the shipping 908 and credit 910 provider entities. Each of these entities can be subscribed to the presence information 914 of the online store entity 904 as denoted by the dotted lines included in the figure.
  • the presence information 914 broadcast by the online store 904 entity can include requests for the shipping 908 and credit 910 provider entities.
  • Each of the shipping 908 and credit 910 provider entities can receive notifications from the presence server 902 pursuant to their subscriptions to the presence information 914 of the online store entity 904 .
  • the shipping provider entity 908 can receive presence information 916 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 912 of the customer entity 906 .
  • the credit provider entity 910 can receive presence information 918 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 910 on behalf of the customer entity 906 for the purchase price of the book.
  • the credit provider entity 910 can also be subscribed to the presence information 912 of the customer entity 906 (again, as denoted by the dashed line in the figure). As a result of the subscription, the credit provider entity 910 can preprocess a request for credit from the online store 904 on behalf of the customer entity 906 at the time the request to purchase the book is made by the customer entity 906 . 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.
  • the shipping provider 908 and credit provider 910 entities can receive notifications related to their services pursuant to outstanding subscriptions to all responses published by the online store entity 904 that specify their services.
  • Such an arrangement allows the shipping provider 908 and credit provider 910 entities to monitor the request/response transaction between the customer entity 906 and online store entity 904 for relevant transaction information.
  • the customer can receive a notification that the order is “in process”.
  • the shipping provider 908 and credit provider 910 entities which are subscribed to the published response, receive first notifications pursuant to their existing subscriptions.
  • the credit provider entity 910 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 908 can publish data (or send the data outside the presence service or “out-of-band”) to the online store 904 providing shipping charges and perhaps a pickup date.
  • the online store 904 entity can then update its response tuple with the new shipping information and publish this information to the presence server 902 .
  • the customer 906 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 910 can receive a second notification based on its subscription to the online store entity's 904 response.
  • the credit provider entity 910 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 910 can then approve the charges and publish data (or send the data out-of-band) to the online store entity 904 indicating that the charge has been approved.
  • the online store entity 904 can then publish new status information to the existing response tuple indicating that the status of the transaction is “order completed”.
  • the customer entity 906 can then receive a notification from the presence server 902 with the new status information.
  • 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.
  • the entire request/response transaction can occur using information stored in a single presence tuple.
  • the data structure shown in FIG. 4 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 FIG. 8 ), the responding and requesting entities can be associated with different principals and configured to respond and make requests related to a common resource.
  • the 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.
  • the 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 104 a shown in FIG. 2 .
  • the photo sharing service can be a web site accessible or hosted by a responding entity, such as the PC 102 b .
  • the PC 102 b can include a presentity component/PUA, a watcher component/WUA and various communication clients 110 .
  • the PC 102 b can be protected by a firewall 114 .
  • a resource data object 412 is added to a standard presence tuple 402 in the portion intended for extended data, as shown in FIG. 4 .
  • the presence tuple 402 corresponds to an owner, Xena, of the web service, but could correspond to the web server itself.
  • the resource data object 412 is used to store information, such as a descriptor, related to the photo sharing service.
  • one or more response data objects 414 are added to the presence tuple 402 to store responses to requests made to the service.
  • the resource 412 and response 414 data objects can be added to the presence tuple 402 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 412 and response 416 data objects of Xena's presence tuple 402 with corresponding service and response information.
  • the RSUA can detect the activity of the web site on the PC 102 b and update, in action 1002 , the service owner's (Xena's) presence tuple 402 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 1004 by instructing Xena's presentity (and any associated PUA) to publish the presence information including the descriptor of the photo sharing service.
  • a friend of Xena operates a requesting device, such as the camera phone 102 c .
  • the camera phone 102 c can include a presentity component/PUA, a watcher component/WUA and various communication clients 110 , such as the IM client 102 b and the browser 110 f client.
  • the browser client 110 f can be used for exchanging information with web services, such as Xena's photo sharing service.
  • the camera phone 102 c can also be protected by a firewall (not shown).
  • Mike's subscription can cause a subscription to be automatically established to Mike's presence tuple on behalf of Xena's presentity in action 1008 .
  • 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 122 can be included in the presence server 118 for authenticating Mike's and Xena's identities to the other, and for authorizing the receiving of information from the presence service 118 .
  • Mike's watcher receives a notify message from the presence server 118 in response to the subscription established in action 1006 .
  • a proxy service 124 can be used to route the notify message through Mike's firewall (not shown).
  • the notify message sent in action 1006 includes the descriptor of Xena's photo sharing service.
  • the camera phone 102 c 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 1012 using an appropriate communication client, such as the IM client 102 b shown in FIG. 2 .
  • the RQUA can also be configured to add a request data object 416 to Mike's presence tuple.
  • the request data object 416 can be added to the portion of the presence tuple 402 intended for extended data, as shown in FIG. 4 .
  • the RQUA in response to Mike selecting Xena's web service using the IM client 110 f , the RQUA (in cooperation, perhaps, with the PUA) can use other information included in the resource data object 412 of Xena's presence tuple, such as information describing the form of service request, to include a request message, in action 1014 , in the request data object 416 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 1016 .
  • the presence server 118 sends a notify command to Xena's watcher component pursuant to the subscription request established in action 1008 .
  • the proxy service 124 can be used to route the notify message through Xena's firewall 114 .
  • Xena can be informed of the request, or the request can be automatically processed in action 1020 using the PC's RSUA and/or WUA.
  • 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.
  • the response message is stored in the response data object 414 of Xena's presence tuple.
  • the RSUA then instructs Xena's presentity to publish the presence tuple, including the response, to the presence server 118 in action 1024 .
  • the presence server sends a notify command to Mike's watcher component pursuant to the subscription request established in action 1006 , again perhaps using the proxy service 124 .
  • Mike can be informed of the response or the response can be automatically processed in action 1028 using the camera phone's RQUA and/or WUA.
  • 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 110 f for displaying the requested web page on the display of Mike's camera phone 102 c.
  • 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.
  • the presence service supports centralized, distributed, peer-to-peer, and mixed architectures for implementing such enhanced applications, services, and workflows.

Abstract

A method and system are described 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 a responding entity and a request related to the resource. The descriptor and the request are sent to the responding entity using the presence protocol. Using the presence protocol, a response is received from the responding entity replying to the request. The response is sent to the requesting entity using the presence protocol.

Description

    RELATED APPLICATIONS
  • The present application is a continuation of co-pending U.S. patent application Ser. No. 11/160,157, entitled “Method, System, and Data Structure for Providing a General Request/Response Messaging Protocol Using a Presence Protocol.” The present application is also related to co-pending U.S. patent application Ser. No. 11/118,882 entitled “System and Method for Utilizing a Presence Service to Advertize 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 Capabilities 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
  • Determining 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.”
  • One 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).
  • The 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.
  • The 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.
  • The 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.
  • The 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.
  • Users 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.
  • According 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.
  • Most 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.
  • Likewise, 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.
  • Indeed, 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.
  • Others 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.
  • In 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.
  • Rather 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
  • Accordingly, 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.
  • According 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.
  • According 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.
  • According 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.
  • According 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
  • The 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:
  • FIG. 1 illustrates a system for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.
  • FIG. 2 is a block diagram illustrating the various components that can form a responding and/or requesting network devices according to an exemplary embodiment.
  • FIG. 3 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.
  • FIG. 4 illustrates a data structure for use with a presence protocol in providing a general request/response protocol according to an exemplary embodiment.
  • FIGS. 5A and 5B show an expanded view of a request data object included in the data structure of FIG. 4 according to an exemplary embodiment.
  • FIG. 6 shows an expanded view of a response data object included in the data structure of FIG. 4 according to an exemplary embodiment.
  • FIG. 7 depicts a data structure for storing presence information associated with an IM resource according to an exemplary embodiment.
  • FIG. 8 is a flowchart illustrating a method for providing a general request/response protocol using a presence protocol according to an exemplary embodiment.
  • FIG. 9 illustrates an exemplary flow of information occurring among presence entities in carrying out a multi-entity transaction.
  • FIG. 10 is signal flow diagram for an illustrative request/response scenario according to an exemplary embodiment.
  • DETAILED DESCRIPTION
  • Various 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.
  • When 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.
  • For 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:
      • 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;
      • 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
      • Subscribe (Unsubscribe): Allowing a WUA/watcher to subscribe or unsubscribe to notifications related to specific presence information.
        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.
  • Several optional, functionally equivalent presence commands also exist. These optional commands include:
      • 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
      • 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.
  • There is also a functional equivalent set of commands for managing a “friends list” (or “roster”) related to presence services. This set of commands includes:
      • Request: Allowing a client to request a specific or default roster;
      • Add: Allowing a client to add an item for a presence entity to a roster;
      • Update: Allowing a client to update a roster item; and
      • Delete: Allowing a client to delete an item from a roster.
        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.
  • Referring now to FIG. 1, a system 100 is depicted for providing a general request/response protocol using a presence protocol. The system includes a presence server 118 configured to receive, store, and distribute information via a presence service 120. The system further includes responding and requesting devices 102 configured to exchange information with the presence server 118 via the network 116 using a presence protocol. The responding and requesting devices 102 can include any of Personal Computers (PCs), Personal Digital Assistants (PDAs), network-enabled cameras, camera phones, cell phones, and the like.
  • Although depicted as a stand-alone server in FIG. 1, the presence server 118 can include several servers (not shown) that together can function as the presence service 120. Moreover, the function of the presence server 118 can be incorporated, either in whole or in part, into any of the devices 120 and server 118 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 118 and presence service 120 are closely link to one another and can be considered to perform one and the same function. As used here, however, the presence server 118 can also include additional services, such as the account service 122 and proxy service 124 shown in FIG. 1, although these additional services need not be included in the server 118. It will be understood that these additional services can also be distributed across one or more servers or devices 102 interconnected via the network 116.
  • A responding device can be, for example, a PC, such as the PC 102 b shown in FIG. 1. The responding device 102 b 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 102 a or camera phone 102 c, via the network 116. For example, FIG. 1 shows that the responding device 102 b can provide resources including services 104 (e.g., web services, such as a photo sharing website), software applications 108, and files 112 (such as image files). Requesting devices, such as the camera 102 a or camera phone 102 c, can request information or services related to these resources using the presence service 120 via the network 116.
  • FIG. 2 is a block diagram illustrating the various components that can make up the responding and/or requesting network devices 102. For convenience, the arrangement shown in FIG. 2 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 202 and responding/requesting watcher component 204. It will be understood that each of these components can be combined into a single respective presentity 202 or watcher 204 component, or can be implemented as separate responding and requesting entities as described below.
  • First consider the arrangement of FIG. 2 from the perspective of a responding device, such as the PC 102 b. From this perspective, the arrangement includes a responding presentity component 202. According to an exemplary embodiment, the responding presentity component 202 can be configured to send a descriptor of the resource 104, 108, 112 to the presence server 118. The descriptor can include any information that describes and/or identifies any of the resources 104, 108, 112 available to the responding device, and can be used to advertise the availability of those resources to requesting devices for processing their requests.
  • For example, FIG. 2 shows that the responding device 102 b has access to web services 104, including a photo sharing web service 104 a and other web services 104 b, a file system 112, printer services 104 c, and camera services 104 d. 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 116 The responding presentity component 202 can send the descriptor of the resource to the presence server 118 by including the descriptor in presence information as described in conjunction with FIGS. 4-6 below. The presence information including the descriptor can be sent to the presence server 118 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.
  • In an alternative embodiment, the responding presentity component 202 need not send the descriptor of the resource 104, 108, 112 to the presence server 118 to advertise the availability of the resource for processing requests. Instead, requesting devices coupled to the presence server 118 can broadcast a standardized request without a descriptor for processing by any of all of the resources 104, 108, 112 associated with responding devices coupled to the presence server 118 via the network 116.
  • Continuing to consider the arrangement of FIG. 2 from the perspective of the responding device 102 b, the arrangement further includes a responding watcher component 204. The responding watcher component 204 is configured to receive from a requesting device (e.g., the camera phone 102 c), via the presence server 118, the descriptor of the resource 104, 108, 112 and a request related to the resource. The presence server 118 can send the descriptor and the request to the responding watcher component 204 via the presence protocol using a notify command. The notify command including the descriptor and request may be sent to the responding watcher component 204 based on a subscription to the presence information of the requesting device 102 c, as a result of a directed publish/notify command sent by the requesting device 102 c for delivery to the responding device 102 b, or in response to a fetch or polling request made by responding device 102 b.
  • As described below in conjunction with FIGS. 4-6, 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 104, 108, 112 available to the responding device 102 b, and the request message can be used to carry the resource request. As such, the responding device 102 b can process multiple requests for different resources 104, 108, 112 corresponding to the various requesting devices 102 c connected to the network 116.
  • Again considering the arrangement of FIG. 2 from the perspective of the responding device 102 b, the responding presentity component 202 is further configured to send a response to the presence server 118 replying to the request message. The responding presentity component 202 can send the response to the presence server 118 by including the response in presence information as described in conjunction with FIGS. 4-6 below. The presence information including the response can be sent to the presence server 118 via the presence protocol using either a broadcast or directed publish command.
  • According to an exemplary embodiment, the responding device can include a responding user agent (RSUA). The RSUA component is coupled to the resource 104, 108, 112 and to the responding presentity 202 and watcher 204 components. Like the PUA and WUA components described above, the RSUA can interact with the responding presentity 202 and watcher 204 components on behalf of a principal. Generally, the RSUA will interact with the resource 104, 108, 112 as its principal, although the RSUA can also interact with an owner of the resource as well as other principals.
  • The RSUA component can be configured to facilitate a sending of the descriptor of the resource by the responding presentity component 202 to advertise the resource to other presence entities coupled to the network 116. The RSUA component can interact with the resource 104, 108, 112 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 110 a or any number of associated communication clients, such as an IM communication client 110 b, a phone client 110 c, an email client 110 d, a Multimedia Messaging Service (MMS) client 110 d, and a browser client 110 f (collectively, communication clients 110) as shown in FIG. 2.
  • For example, FIG. 3 illustrates an interface that may be used by an owner of the resource 104, 108, 112 to interact with the responding presentity component 202 to publish the descriptor of the resource. Using the IM client 110 b, the exemplary interface can be presented on a display 300 in the form a “friends list” 302, recognizable to those familiar with IM applications. The friends list 302 can include the names of human resource owners, e.g., John, Paul, George, and Ringo, and/or non-human resource owners, e.g., Server1. The friends list 302 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 302 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).
  • The interface 302 can also include an Actions menu item 306, suitable for invoking commands associated with resources. The Actions menu can include entries 306 a 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.
  • The RSUA can be further configured to facilitate a processing by the resource 104, 108, 112 of the request received by the responding watcher component 204. The RSUA can be configured to forward the request to the appropriate resource 104, 108, 112 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 104 a illustrated in FIG. 2, 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).
  • The 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 302 shown in FIG. 3 is illustrated as presenting a dialog box 304 indicating that a user, George, has requested access to a printer service (e.g., service 104 c of FIG. 2) 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.
  • In addition, the RSUA can be further configured to facilitate a sending of the response to the request by the responding presentity component 202. As with the publishing of the descriptor, the RSUA component can interact with the resource 104, 108, 112 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 306 a of FIG. 3, 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 202 for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the response as needed.
  • In facilitating the exchange of information between the responding presentity 202 and watcher 204 components, the resource 104, 108, 112, and the communication clients 110, 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.
  • Consider now the arrangement of FIG. 2 from the perspective of a requesting device, such as the camera phone 102 c shown in FIG. 1. From this perspective, the arrangement includes a requesting watcher component 204 which can be configured to receive the descriptor of the resource 104, 108, 112 if sent from the presence server 118. The presence server 118 can send the descriptor to the requesting watcher component 204 via the presence protocol using a notify command. The notify command including the descriptor may be sent to the requesting watcher component 204 based on a subscription to the presence information of the responding device 102 b, as a result of a directed publish/notify command sent by the responding device 102 b for delivery to the requesting device 102 c, or in response to a fetch or polling request made by the requesting device 102 c. 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.
  • Continuing to consider the arrangement of FIG. 2 from the perspective of the requesting device 102 c, the arrangement further includes a requesting presentity component 202 configured to send the descriptor and the request related to the resource to the presence server 118. The requesting presentity component 202 can send the request to the presence server 118 by including the request in presence information as described in conjunction with FIGS. 4-6 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 118 via the presence protocol using either a broadcast or directed publish command.
  • Again, considering the arrangement of FIG. 2 from the perspective of the requesting device 102 c, the requesting watcher component 204 is further configured to receive via the presence server 118 the response replying to the request message. The presence server 118 can send the response to the requesting watcher component 204 via the presence protocol using a notify command. The notify command including the response may be sent to the requesting watcher component 204 based on a subscription to the presence information of the responding device 102 b, as a result of a directed publish/notify command sent by the responding device 102 b for delivery to the requesting device 102 c, or in response to a fetch or polling request made by the requesting device 102 c.
  • According to an exemplary embodiment, the requesting device can include a requesting user agent (RQUA) component coupled to the requesting presentity 202 and watcher 204 components. Like the RSUA, the RQUA can also be coupled to the communication clients 110 a-110 f shown in FIG. 2 for interacting with a user/principal of the requesting device 102 c. The RQUA can be configured to facilitate a presentation of the descriptor received by the requesting watcher component 204. For example, using the IM client 110 b, the RQUA can present a descriptor of a resource received by the requesting watcher component 204, such as the photo sharing web service shown as being owned by John or the programs and service shown as being owned by Server1 in FIG. 2. The descriptor can be presented in the interface 302 together with information describing the owner of the resource and a status of the resource.
  • The RQUA can also be configured to facilitate a sending of the request by the requesting presentity component 202. 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 102 c. Alternatively, an interface, such as the interface 302 shown in FIG. 3, can be presented to a user/principal of the requesting device 102 c to gather information needed to form the request. For example, upon selecting the “publish a request” Action entry 306 a, 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 202 for publishing (perhaps with the assistance of an appropriate PUA), performing any translations of the request as needed.
  • The RQUA can also be configured to facilitate a presentation of the response received by the requesting watcher component 204. For example, if the response were to include a web page served from the photo sharing web service 104 a of the responding device 102 b illustrated in FIG. 2, the RQUA could invoke the browser client 110 f of the requesting device 102 c 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 118. Alternatively, the RQUA can present a dialog box to receive authorization or additional information from a user/principal prior to acting on the response.
  • In facilitating the exchange of information between the requesting presentity 202 and watcher 204 components and the communication clients 110, 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.
  • Referring again to FIG. 1, the presence server 118 can include the proxy service 124. The proxy service 124 can be configured to send the request to the responding watcher component 204 through a firewall 114 associated with the responding device 102 b or to send the response to the requesting watcher component through a firewall (not shown) associated with the requesting device 102 c. According to another exemplary embodiment, the presence server 118 can also include the account service 122. The account service 122 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.
  • Rosters and/or privacy lists may be used by the account service 122 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 128 coupled to the account service 122. Multiple rosters and/or privacy lists may be maintained in the database 128 and used by the service 122. 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.
  • Referring now to FIG. 4, 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 FIG. 4 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.
  • Should the data structure of FIG. 4 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.
  • The data structure shown in FIG. 4 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).
  • The data structure shown in FIG. 4 represents presence information 400 that includes an enhanced presence tuple 402. The presence information 400 can be stored in a database coupled to the presence server 118 shown in FIG. 1, such as the presence information database 126. Although a single database 126 is shown in FIG. 1, persons skilled in the art will understand that the presence information can be distributed throughout the network 116 across multiple databases and/or stored, at least in part, in memory associated with the requesting and/or responding devices 102 shown in FIG. 1.
  • The presence tuple 402 shown in FIG. 4 includes standard data objects for storing the status 404 and communication address 406 information described in RFC 2778 and RFC 2779. The presence tuple 402 also includes data objects for storing a contact means 408 and contact address 410, as well as a data object for storing other markup 418, thus maintaining the extensibility of the tuple 402 in accordance with presence standards. Because the presence tuple 402 maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information 400 can be carried across the network 116 using standard presence protocol commands. It is not necessary that the presence server 118 to understand the content of the tuple 402 in order to route the information contained therein to the various presence entities coupled to the network 116.
  • Considering first the data structure of FIG. 4 from the perspective of a responding entity, to provide a general request/response protocol using a presence protocol, the presence tuple 402 includes a resource data object 412, including an element (not expressly shown) for storing a descriptor of a resource associated with a responding entity. As described in conjunction with FIGS. 1-3 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 104, 108, 112 shown in FIG. 1. The responding entity can be, for example, the responding presentity component 202 shown in FIG. 2. According to an exemplary embodiment, the resource data object 412 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 412 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.
  • Now, considering the data structure of FIG. 4 from the perspective of a requesting entity, the presence tuple 402 also includes a request data object 416. 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 202 shown in FIG. 2.
  • FIG. 5A shows an expanded view of the request data object 416 according to an exemplary embodiment. As shown in the figure, the expanded view of the request data object 416 can include an element for storing a request message 504 related to the resource. The request data object 416 can also include a descriptor element 502 for storing a descriptor of a resource associated with the responding entity. The descriptor element 502 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).
  • For 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:
  • <presence
    from=‘customer@isp.net’
    to =‘sales@online.com’
    xml:lang=‘en’>
    <request>
    <descriptor>books</descriptor>
    </request>
    </presence>
    The descriptor stored in element 502 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 118 can use the descriptor stored in the element 502 both to route the request message stored in element 504 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.
  • It 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 116 (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:
  • <presence
    from=‘customer@isp.net’
    xml:lang=‘en’>
    <request>
    <descriptor>sales@online.com/books</descriptor>
    </request>
    </presence>
    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.
  • FIG. 5B shows an expanded view of the request data object 416 according to an alternative embodiment. In this embodiment, the request data object 416 does not include an element for storing the descriptor of the resource associated with the responding entity (e.g., element 502 shown in FIG. 5A). 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:
  • <presence
    from=‘customer@isp.net’
    to =‘sales@online.com/books’
    xml:lang=‘en’>
    <request> . . . </request>
    </presence>
    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 118 to route the notify portion of the directed publish/notify command to the responding entity.
  • It 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:
  • <presence
    from=‘customer@isp.net’
    xml:lang=‘en’>
    <request> . . . </request>
    </presence>
    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.
  • In 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 416 shown in FIG. 5B includes an identifier element 506 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.
  • For 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:
  • <presence
    from=‘customer@isp.net’
    xml:lang=‘en’>
    <request>
    <identifier>sales@online.com</identifier>
    </request>
    </presence>
    In this sense, the identifier stored in element 506 serves a similar function to the descriptor stored in element 502 of the arrangement shown in FIG. 5A. 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.
  • According to another exemplary embodiment, the request message stored in element 504 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.
  • There 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.
  • Referring once again to the data structure of FIG. 4 from the perspective of a responding entity, the presence tuple 402 also includes a response data object 414 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 202 shown in FIG. 2. It should be noted that FIG. 4 depicts two response data objects 414 linked to the resource data object 412 in the presence tuple 402. 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 FIG. 4 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.
  • FIG. 6 shows an expanded view of the response data object 414 according to an exemplary embodiment. As shown in the figure, the expanded view of the response data object 414 can include an element for storing a response message 604 replying to the request message stored in element 504. Similar to the request message, the response message stored in element 604 can be an XML-based message formed in the structure of a SOAP message.
  • The response data object 414 can also include an identifier element 602 (similar to the identifier element 506 shown in FIG. 5B) for storing an identifier, such as a URI, of the requesting entity. The presence server 118 can use the identifier stored in the element 602 to route the response message stored in element 604 of the presence tuple 402 to the requesting entity. It can be useful for the presence server 118 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 116 (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.
  • For example, consider the following XML-based message published by a responding entity (“sales@online.com”) for broadcast to any available requesting entity:
  • <presence
    from=‘sales@online.com’
    xml:lang=‘en’>
    <response>
    <identifier>customer@isp.net</identifier>
    </response>
    </presence>
    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 414.
  • Most 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 118 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.
  • In an exemplary embodiment, the resource 412 and response 414 data objects can be included in a presence tuple associated with the resource or an owner of the resource. When the resource 412 and response 414 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.
  • For example, FIG. 7 depicts a data structure for storing presence information associated with an IM resource, such as the IM client 110 b shown in FIG. 2. The presence information 400 includes an IM presence tuple 702 corresponding to the IM client 110 b, and other IM presence tuples 702 corresponding to other IM clients (not shown) coupled to the network 116. The IM presence tuple 702 includes standard data objects for storing a service status 704, a communication address 706, including elements for storing a contact means 708 and contact address 710, and a data object for storing other markup information 418. The information stored in the status 704 and communication address 706 data objects can represent the status and communication address of an owner or principal associated with the IM client 110 b and/or the status and communication address of the IM client 110 b.
  • Since the IM presence tuple 702 is associated with a resource (e.g., the IM client 110 b) and not the owner of the resource, the IM presence tuple 702 can also include a data object 712 for storing information linking information in the owner/principal's presence tuple (not shown) to the IM presence tuple 702. Moreover, since the IM present tuple 702 is itself associated with the resource, a resource data object, such as the resource data object 412 shown in FIG. 4, 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 702.
  • The IM presence tuple 702 can also include a request data object 714, including identifier 716 and message 718 elements, as well as subject 720 and body 722 sub-elements, for storing IM message information to send to other presence entities coupled to the network 116. A presentity associated with IM client 110 e can use directed publish/notify commands to send messages to specific entities, or can broadcast messages to all subscribers to the IM presence tuple 702 information. Because the IM presence tuple 702 maintains the standard form for presence information described in RFC 2778 and RFC 2779, the presence information 400 can be carried across the network 116 using standard presence protocol commands. It is not necessary that the presence server 118 to understand the content of the tuple 702 in order to route the information contained therein to the various presence entities coupled to the network 116. Moreover, the arrangement shown in FIG. 7 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.
  • In a related exemplary embodiment, the request data object 416 can be included in a presence tuple associated with the resource or a principal associated with the requesting entity. When the request data object 416 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.
  • FIG. 8 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 FIGS. 1-3 and the data structure described in conjunction with FIGS. 4-6 above, portions of which are referenced in the description that follows. In particular, the method can be carried out using the presence server 118. 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 FIGS. 1-6, are not repeated here.
  • Moreover, the executable instructions of a computer program as illustrated in FIG. 8 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.
  • The method begins in block 802, 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 118 can receive the descriptor and the request from the requesting presentity component 202 shown in FIG. 2. In block 804, the descriptor and the request are sent, e.g., from the presence server 118, to the responding entity, e.g., the responding watcher component 204. The descriptor can be included in the request as described above in conjunction with the request data object 416 shown in FIG. 5A. 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.
  • A response from the responding entity, e.g. the responding presentity component 202 of FIG. 2, is received, e.g. by the presence server 118, in block 806. The response can include a response message replying to the request message, stored, for example, in element 604 of the data structure shown FIG. 6, and an identifier of the requesting entity, stored, for example, in element 602 of the data structure. In block 808, the response is sent, e.g., by the presence server 118, to the requesting entity, e.g., the requesting watcher component 204 shown in FIG. 2. Accordingly, a general request/response protocol is formed using the commands of a presence protocol.
  • According to an exemplary embodiment, the presence protocol can be used for receiving, e.g., by the presence server 118, the descriptor of the resource from the responding entity, e.g., the responding presentity component 202 shown in FIG. 2. 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 412. 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 416, when the subscription to the presence information of the responding entity is established for the requesting entity 102. 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.
  • If 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 412, 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 416. 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.
  • In 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 118 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.
  • The 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 416, 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 118 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 118 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 118 can then notify the responding entity of the request when detected via the probe command.
  • Likewise, 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 414, 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 118 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 118 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 118 can then notify the requesting entity of the response when detected via the probe command.
  • According 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 120 and its underlying presence protocol need not be modified to allow for the exchange of request/response information included in the presence tuples.
  • In 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 FIG. 7, 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.
  • According 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 118 can include the account service 122 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 122 to authorize and authenticate access to a particular resource or to prevent providers from advertising certain resources to subscribers.
  • In 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 FIGS. 1 and 2, the presence server 118 can include a proxy service 124 configured to send the request to a responding watcher component 204 through a firewall 114 associated with the responding device 102 b, or to send the response to a requesting watcher component through a firewall (not shown) associated with the requesting device 102 c.
  • According 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.
  • For example, FIG. 9 illustrates the flow of information among presence entities that can occur in carrying out a multi-entity online purchase transaction. The arrangement of FIG. 9 includes a presence server 902 and presence entities representing a customer 906 and an online store 904. Additional presence entities representing a shipping provider 908 and a credit provider 910 are also shown. The customer entity 906 can begin a transaction by publishing, to the presence server 902, presence information 912 including a request to purchase a book from the online store entity 904. The presence information 912 includes an identifier (“customer@isp.net”) of the customer entity 906 as a “from” presence attribute, and an identifier/descriptor (“sales@online.com/books”) of a resource associated with the online store entity 904 as a “to” presence attribute of a directed publish/notify command. Alternatively, the presence information 912 could be broadcast to the presence server 902 by the customer entity 906.
  • The request included in the presence information 912 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”).
  • Once published, the presence information 912 including the request can be sent by the presence server 902 to the online store entity 904. The presence information 912 including the request can be sent to the online store entity 904 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 904 to the presence information 912 of the customer entity 906. The request can then be processed by the online store's “books” service. In processing the request from the customer entity 906, the online store entity 904 may broadcast requests to the presence server 902 for notification to other responding entities, such as the shipping 908 and credit 910 provider entities. Each of these entities can be subscribed to the presence information 914 of the online store entity 904 as denoted by the dotted lines included in the figure. The presence information 914 broadcast by the online store 904 entity can include requests for the shipping 908 and credit 910 provider entities.
  • Each of the shipping 908 and credit 910 provider entities can receive notifications from the presence server 902 pursuant to their subscriptions to the presence information 914 of the online store entity 904. For example, the shipping provider entity 908 can receive presence information 916 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 912 of the customer entity 906. In addition, the credit provider entity 910 can receive presence information 918 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 910 on behalf of the customer entity 906 for the purchase price of the book.
  • Note that the credit provider entity 910 can also be subscribed to the presence information 912 of the customer entity 906 (again, as denoted by the dashed line in the figure). As a result of the subscription, the credit provider entity 910 can preprocess a request for credit from the online store 904 on behalf of the customer entity 906 at the time the request to purchase the book is made by the customer entity 906. 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.
  • In an alternate embodiment, rather than the online store entity 904 issuing a request directed to the shipping provider 908 and the credit provider 910 entities as described above, the shipping provider 908 and credit provider 910 entities can receive notifications related to their services pursuant to outstanding subscriptions to all responses published by the online store entity 904 that specify their services. Such an arrangement allows the shipping provider 908 and credit provider 910 entities to monitor the request/response transaction between the customer entity 906 and online store entity 904 for relevant transaction information.
  • For example, consider when the online store entity 904 publishes a response to the customer entity's 906 request for a book purchase, the customer can receive a notification that the order is “in process”. The shipping provider 908 and credit provider 910 entities, which are subscribed to the published response, receive first notifications pursuant to their existing subscriptions. The credit provider entity 910 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 908 can publish data (or send the data outside the presence service or “out-of-band”) to the online store 904 providing shipping charges and perhaps a pickup date.
  • The online store 904 entity can then update its response tuple with the new shipping information and publish this information to the presence server 902. At this point, the customer 906 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 910 can receive a second notification based on its subscription to the online store entity's 904 response. The credit provider entity 910 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 910 can then approve the charges and publish data (or send the data out-of-band) to the online store entity 904 indicating that the charge has been approved. The online store entity 904 can then publish new status information to the existing response tuple indicating that the status of the transaction is “order completed”. The customer entity 906 can then receive a notification from the presence server 902 with the new status information.
  • Instead 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 FIG. 4 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 FIG. 8), the responding and requesting entities can be associated with different principals and configured to respond and make requests related to a common resource.
  • As 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.
  • The 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
  • The following illustrative example is provided in conjunction with the signal flow diagram shown in FIG. 10 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 FIG. 10, 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.
  • The 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 104 a shown in FIG. 2. The photo sharing service can be a web site accessible or hosted by a responding entity, such as the PC 102 b. The PC 102 b can include a presentity component/PUA, a watcher component/WUA and various communication clients 110. The PC 102 b can be protected by a firewall 114.
  • First, a resource data object 412 is added to a standard presence tuple 402 in the portion intended for extended data, as shown in FIG. 4. In the example, the presence tuple 402 corresponds to an owner, Xena, of the web service, but could correspond to the web server itself. The resource data object 412 is used to store information, such as a descriptor, related to the photo sharing service. In addition, one or more response data objects 414 are added to the presence tuple 402 to store responses to requests made to the service.
  • The resource 412 and response 414 data objects can be added to the presence tuple 402 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 412 and response 416 data objects of Xena's presence tuple 402 with corresponding service and response information. For example, the RSUA can detect the activity of the web site on the PC 102 b and update, in action 1002, the service owner's (Xena's) presence tuple 402 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 1004 by instructing Xena's presentity (and any associated PUA) to publish the presence information including the descriptor of the photo sharing service.
  • In the example, a friend of Xena, Mike, operates a requesting device, such as the camera phone 102 c. The camera phone 102 c can include a presentity component/PUA, a watcher component/WUA and various communication clients 110, such as the IM client 102 b and the browser 110 f client. The browser client 110 f can be used for exchanging information with web services, such as Xena's photo sharing service. The camera phone 102 c can also be protected by a firewall (not shown).
  • Mike subscribes to Xena's presence tuple 402 in action 1006. Mike's subscription can cause a subscription to be automatically established to Mike's presence tuple on behalf of Xena's presentity in action 1008. 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 122 can be included in the presence server 118 for authenticating Mike's and Xena's identities to the other, and for authorizing the receiving of information from the presence service 118.
  • In action 1010, Mike's watcher receives a notify message from the presence server 118 in response to the subscription established in action 1006. A proxy service 124 can be used to route the notify message through Mike's firewall (not shown). The notify message sent in action 1006 includes the descriptor of Xena's photo sharing service. The camera phone 102 c 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 1012 using an appropriate communication client, such as the IM client 102 b shown in FIG. 2.
  • The RQUA can also be configured to add a request data object 416 to Mike's presence tuple. The request data object 416 can be added to the portion of the presence tuple 402 intended for extended data, as shown in FIG. 4. In response to Mike selecting Xena's web service using the IM client 110 f, the RQUA (in cooperation, perhaps, with the PUA) can use other information included in the resource data object 412 of Xena's presence tuple, such as information describing the form of service request, to include a request message, in action 1014, in the request data object 416 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 1016.
  • In action 1018, the presence server 118 sends a notify command to Xena's watcher component pursuant to the subscription request established in action 1008. Again, the proxy service 124 can be used to route the notify message through Xena's firewall 114. Xena can be informed of the request, or the request can be automatically processed in action 1020 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 1022, the response message is stored in the response data object 414 of Xena's presence tuple. The RSUA then instructs Xena's presentity to publish the presence tuple, including the response, to the presence server 118 in action 1024.
  • In action 1026, the presence server sends a notify command to Mike's watcher component pursuant to the subscription request established in action 1006, again perhaps using the proxy service 124. Mike can be informed of the response or the response can be automatically processed in action 1028 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 110 f for displaying the requested web page on the display of Mike's camera phone 102 c.
  • Methods, 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.
  • It 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.

Claims (44)

1. A method for providing a general request/response protocol, the method comprising:
receiving, by a server from a requesting entity using a publish-subscribe protocol, a descriptor of a resource associated with a responding entity and a request related to the resource;
sending, by the server using the publish-subscribe protocol, the descriptor and the request to the responding entity;
receiving, by the server using the publish-subscribe protocol, a response from the responding entity replying to the request; and
sending, by the server using the publish-subscribe protocol, the response to the requesting entity.
2. The method of claim 1 further comprising using, by the server, the publish-subscribe protocol for receiving the descriptor of the resource from the responding entity.
3. The method of claim 2 further comprising using, by the server, the publish-subscribe protocol for sending the descriptor of the resource to the requesting entity based on a subscription established for the requesting entity to at least some presence information of the responding entity.
4. The method of claim 3 further comprising using, by the server, the publish-subscribe protocol for:
automatically establishing a subscription for the responding entity to at least some presence information of the requesting entity when the subscription to the presence information of the responding entity is established for the requesting entity;
wherein sending the request to the responding entity is based on the subscription automatically established for the responding entity.
5. The method of claim 3 further comprising using, by the server, the publish-subscribe protocol for:
sending a notification to the responding entity indicating that the subscription to at least some of the presence information of the responding entity is established for the requesting entity;
receiving a subscription request, sent from the responding entity in response to the notification, for a subscription to at least some presence information of the requesting entity; and
establishing the subscription to the presence information of the requesting entity for the responding entity based on the received subscription request;
wherein sending the request to the responding entity is based on the subscription established for the responding entity.
6. The method of claim 3 further comprising using, by the server, the publish-subscribe protocol 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.
7. The method of claim 1 wherein sending the request to the responding entity is based on a subscription established for the responding entity to at least some presence information of the requesting entity.
8. The method of claim 1 wherein the request is sent by the server to the responding entity using an identifier of the responding entity included in presence information of the requesting entity.
9. The method of claim 1 wherein the request is sent by the server 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.
10. The method of claim 1 wherein sending the response to the requesting entity is based on a subscription established for the requesting entity to at least some presence information of the responding entity.
11. The method of claim 1 wherein the response is sent by the server to the requesting entity using an identifier of the requesting entity included in presence information of the responding entity.
12. The method of claim 1 wherein the response is sent by the server 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.
13. The method of claim 1 wherein the request is included in presence information associated with the requesting entity but is not included in presence information associated with the responding entity and the response is included in the presence information associated with the responding entity but is not included in the presence information associated with the requesting entity.
14. The method of claim 13 wherein the presence information associated with the responding entity corresponds to presence information of the resource or presence information of an owner of the resource.
15. The method of claim 14 wherein when the presence information associated with the responding entity corresponds to presence information of the resource, the presence information of the resource includes a link to the presence information of the owner of the resource.
16. The method of claim 13 wherein the presence information associated with the requesting entity corresponds 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.
17. The method of claim 1 further comprising:
authenticating, by the server, an identity of each of the requesting and responding entities; and
authorizing, by the server, a receiving by each of the entities of the request or the response prior to sending the request or response to the respective entity.
18. The method of claim 1 further comprising:
providing, by the server, a proxy service configured 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.
19. The method of claim 1 wherein the resource is at least one of a service, an application program, a file, and data associated with the responding entity.
20. The method of claim 1 wherein the descriptor is included in the request.
21. The method of claim 1 wherein the descriptor is included in each of respective presence protocol commands used in receiving the request from the requesting entity and in sending the request to the responding entity.
22. The method of claim 1 further comprising using, by the server, the publish-subscribe protocol 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, and for sending the second descriptor and the second request to the second responding entity, wherein the second request is related to the response replying to the request from the requesting entity.
23. A method for providing a general request/response protocol, the method comprising:
receiving, by the server from a requesting entity, a descriptor of a resource associated with a responding entity and a request related to the resource;
using, by the server, the descriptor to update the presence information of the responding entity to include the request;
receiving, by the server, the presence information from the responding entity including a response replying to the request; and
sending, by the server, the response to the requesting entity.
24. A method for providing a general request/response protocol, the method comprising:
using a publish-subscribe protocol for:
sending a descriptor of a resource and a request related to the resource to a server; and
receiving via the server a response replying to the request.
25. The method of claim 24 further comprising using the publish-subscribe protocol for receiving the descriptor of the resource from the server.
26. A computer readable medium containing a data structure for use with a publish-subscribe protocol in providing a general request/response protocol, the data structure comprising:
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.
27. The computer readable medium of claim 26, wherein the request data object includes an element for storing the descriptor of the resource associated with the responding entity.
28. The computer readable medium of claim 26, wherein the resource data object includes at least one element for storing information describing requests supported by the resource and information describing responses for replying to the supported requests.
29. The computer readable medium of claim 26, wherein the request data object includes an element for storing an identifier of the responding entity.
30. The computer readable medium of claim 26, wherein the response data object includes an element for storing an identifier of the requesting entity.
31. The computer readable medium of claim 26, wherein the request and the response each include an XML-based message formed in the structure of a SOAP message.
32. The computer readable medium of claim 26, wherein the resource and response data objects are included in a presence tuple associated with the resource or an owner of the resource.
33. The computer readable medium of claim 32, wherein when the resource and response data objects are included in a presence tuple associated with the resource, the presence tuple associated with the resource includes a data object linking the presence tuple associated with the resource to a presence tuple associated with the owner of the resource.
34. The computer readable medium of claim 26, wherein the request data object is included in a presence tuple associated with the resource or a principal associated with the requesting entity.
35. The computer readable medium of claim 34, wherein when the request data object is included in a presence tuple associated with the resource, the presence tuple associated with the resource includes a data object linking the presence tuple associated with the resource to a presence tuple associated with the principal associated with the requesting entity.
36. A system for providing a general request/response protocol, the system comprising:
a server configured to receive, store, and distribute information using a publish-subscribe protocol;
a responding device configured to exchange information with the server using the publish-subscribe protocol, the responding device including:
access to at least one resource;
a responding watcher component configured to receive, via the server using the publish-subscribe protocol, a descriptor of the resource and a request related to the resource; and
a responding presentity component configured to send, using the publish-subscribe protocol, a response to the server replying to the request; and
a requesting device configured to exchange information with the server using the publish-subscribe protocol, the requesting device including:
a requesting presentity component configured to send the descriptor and the request related to the resource to the server using the publish-subscribe protocol; and
a requesting watcher component configured to receive, via the server using the publish-subscribe protocol, the response replying to the request.
37. The system of claim 36, wherein the responding presentity component is further configured to send the descriptor of the resource to the server using the publish-subscribe protocol, and the requesting watcher component is further configured to receive the descriptor of the resource from the server using the publish-subscribe protocol.
38. The system of claim 37, wherein the responding device includes a responding user agent component coupled to the resource and the responding presentity and watcher components, the responding user agent component configured to facilitate a sending of the descriptor of the resource by the responding presentity component using the publish-subscribe protocol, a processing by the resource of the request received by the responding watcher component, and a sending of the response by the responding presentity component using the publish-subscribe protocol.
39. The system of claim 37, wherein the requesting device includes a requesting user agent component coupled to the requesting presentity and watcher components, the requesting user agent configured to facilitate a presentation of the descriptor received by the requesting watcher component, a sending of the request by the requesting presentity component, and a presentation of the response received by the requesting watcher component.
40. The system of claim 36, wherein the server includes a proxy service configured to send the request, using the publish-subscribe protocol, to the responding watcher component through a firewall associated with the responding device or to send the response, using the publish-subscribe protocol, to the requesting watcher component through a firewall associated with the requesting device.
41. The system of claim 36, wherein the server includes an account service 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 response prior to sending the request or response to the respective device.
42. The system of claim 41, comprising a database coupled to the account service including roster and/or privacy list information used by the account service to authorize the receiving by each of the devices of the request or response.
43. A computer readable medium containing a computer program for providing a general request/response protocol, the computer program comprising executable instructions for:
receiving, by a server from a requesting entity using a publish-subscribe protocol, a descriptor of a resource associated with a responding entity and a request related to the resource;
sending, by the server using the publish-subscribe protocol, the descriptor and the request to the responding entity;
receiving, by the server using the publish-subscribe protocol, a response from the responding entity replying to the request; and
sending, by the server using the publish-subscribe protocol, the response to the requesting entity.
44. The computer readable medium of claim 43, wherein the computer program comprises executable instructions for using the publish-subscribe protocol for receiving the descriptor of the resource from the responding entity and for sending the descriptor of the resource to the requesting entity.
US12/485,261 2005-06-10 2009-06-16 Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol Abandoned US20090254627A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/485,261 US20090254627A1 (en) 2005-06-10 2009-06-16 Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/160,157 US7567553B2 (en) 2005-06-10 2005-06-10 Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol
US12/485,261 US20090254627A1 (en) 2005-06-10 2009-06-16 Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/160,157 Continuation US7567553B2 (en) 2005-06-10 2005-06-10 Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol

Publications (1)

Publication Number Publication Date
US20090254627A1 true US20090254627A1 (en) 2009-10-08

Family

ID=37524043

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/160,157 Expired - Fee Related US7567553B2 (en) 2005-06-10 2005-06-10 Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol
US12/485,261 Abandoned US20090254627A1 (en) 2005-06-10 2009-06-16 Method, System, And Data Structure For Providing A General Request/Response Messaging Protocol Using A Presence Protocol

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/160,157 Expired - Fee Related US7567553B2 (en) 2005-06-10 2005-06-10 Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol

Country Status (5)

Country Link
US (2) US7567553B2 (en)
EP (1) EP1889429A2 (en)
JP (1) JP2008546356A (en)
CN (1) CN101273593A (en)
WO (1) WO2006135685A2 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100262809A1 (en) * 2009-04-09 2010-10-14 Research In Motion Limited System and Method for Conflict Resolution During the Consolidation of Information Relating to a Data Service
US20110004518A1 (en) * 2008-03-12 2011-01-06 Christer Boberg Method and user device for handling mobile advertising
US20110035443A1 (en) * 2009-08-04 2011-02-10 At&T Intellectual Property I, L.P. Aggregated Presence Over User Federated Devices
US20110302414A1 (en) * 2010-06-08 2011-12-08 Mark Logan Remote control of medical devices using instant messaging infrastructure
US20110320585A1 (en) * 2010-06-26 2011-12-29 Cisco Technology, Inc. Providing state information and remote command execution in a managed media device
US8346853B2 (en) 2010-05-27 2013-01-01 Robert Paul Morris Methods, systems, and computer program products for processing an attached command response
US8533306B2 (en) 2006-09-21 2013-09-10 At&T Intellectual Property I, L.P. Personal presentity presence subsystem
US20130244650A1 (en) * 2010-09-29 2013-09-19 At&T Intellectual Property I, L.P. Notifications based on device presence
US8577958B2 (en) 2010-05-28 2013-11-05 Robert Paul Morris Methods, systems, and computer program products for processing a non-returnable command response based on a markup element

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050232408A1 (en) * 2004-04-15 2005-10-20 Hodson Jeffrey D System for contact system entities beyond end-points to track state availability and capabilites by implementing SIP presence technologies
US20060286993A1 (en) * 2005-06-20 2006-12-21 Motorola, Inc. Throttling server communications in a communication network
US8356011B2 (en) * 2005-07-26 2013-01-15 Microsoft Corporation Organizing presence information into collections of publications
US7650337B2 (en) * 2005-07-26 2010-01-19 Microsoft Corporation Managing rich presence collections
US7587450B2 (en) * 2006-02-01 2009-09-08 Swift Creek Systems, Llc HTTP publish/subscribe communication protocol
US8005073B2 (en) * 2006-02-13 2011-08-23 Nokia Corporation Representing network availability status information in presence information
US8108345B2 (en) 2006-03-31 2012-01-31 Microsoft Corporation Managing rich presence collections in a single request
US8234559B2 (en) * 2006-03-31 2012-07-31 Microsoft Corporation Managing rich presence collections
US20070233852A1 (en) * 2006-03-31 2007-10-04 Jack Jachner Presence logging in calendar systems
US8155580B2 (en) * 2006-06-23 2012-04-10 Qualcomm Incorporated Methods and apparatus for efficient data distribution to a group of users
US9330190B2 (en) 2006-12-11 2016-05-03 Swift Creek Systems, Llc Method and system for providing data handling information for use by a publish/subscribe client
CN101611609B (en) * 2006-12-28 2012-11-14 艾利森电话股份有限公司 Method and apparatus for service discovery
US20080183816A1 (en) * 2007-01-31 2008-07-31 Morris Robert P Method and system for associating a tag with a status value of a principal associated with a presence client
US7966039B2 (en) * 2007-02-02 2011-06-21 Microsoft Corporation Bidirectional dynamic offloading of tasks between a host and a mobile device
US7627608B2 (en) * 2007-02-07 2009-12-01 Nokia Corporation Sharing of media using contact data
US20080313323A1 (en) * 2007-06-15 2008-12-18 Morris Robert P Methods, Systems, And Computer Program Products For Monitoring Transaction Status With A Presence Tuple
US20090112997A1 (en) * 2007-10-25 2009-04-30 Cisco Technology, Inc. Utilizing Presence Data Associated with Web Item
US20090107265A1 (en) * 2007-10-25 2009-04-30 Cisco Technology, Inc. Utilizing Presence Data Associated with a Sensor
US8539029B2 (en) 2007-10-29 2013-09-17 Microsoft Corporation Pre-send evaluation of E-mail communications
WO2009064289A1 (en) * 2007-11-13 2009-05-22 Alcatel Lucent Watcher proposed presence states
WO2009104998A1 (en) * 2008-02-18 2009-08-27 Telefonaktiebolaget Lm Ericsson (Publ) A method of enabling a service at a communication network node
US8280963B2 (en) * 2008-04-10 2012-10-02 Microsoft Corporation Caching and exposing pre-send data relating to the sender or recipient of an electronic mail message
SG159399A1 (en) * 2008-08-13 2010-03-30 Smart Comm Inc Message routing platform
US8473733B2 (en) * 2008-10-14 2013-06-25 Research In Motion Limited Method for managing opaque presence indications within a presence access layer
US8103730B2 (en) 2008-10-15 2012-01-24 Research In Motion Limited Use of persistent sessions by a presence access layer
US20100093366A1 (en) * 2008-10-15 2010-04-15 Research In Motion Limited Incorporating Non-Presence Information in the Calculation of Presence Aspects by a Presence Access Layer
US20100093328A1 (en) * 2008-10-15 2010-04-15 Research In Motion Limited Interworking Function with a Presence Access Layer to Provide Enhanced Presence Aspect Indications
US20100099387A1 (en) * 2008-10-16 2010-04-22 Research In Motion Limited Controlling and/or Limiting Publication Through the Presence Access Layer
US8751584B2 (en) * 2008-10-16 2014-06-10 Blackberry Limited System for assignment of a service identifier as a mechanism for establishing a seamless profile in a contextually aware presence access layer
US8386769B2 (en) * 2008-11-21 2013-02-26 Research In Motion Limited Apparatus, and an associated method, for providing and using opaque presence indications in a presence service
US8495245B2 (en) * 2009-01-08 2013-07-23 Alcatel Lucent Connectivity, adjacencies and adaptation functions
US20100257223A1 (en) * 2009-04-02 2010-10-07 Morris Robert P Method and System For Changing A Subscription To A Tuple Based On A Changed State Of A Subscribing Principal
EP2239920B1 (en) * 2009-04-09 2013-08-07 Research In Motion Limited Method, server and computer-readable medium for establishing a presence context within a presence platform
US20100262661A1 (en) * 2009-04-09 2010-10-14 Research In Motion Limited Method and system for establishing a presence context within a presence platform
US9628831B2 (en) 2010-03-25 2017-04-18 Whatsapp, Inc. Multimedia transcoding method and system for mobile devices
US8995965B1 (en) * 2010-03-25 2015-03-31 Whatsapp Inc. Synthetic communication network method and system
US10171392B1 (en) 2010-07-09 2019-01-01 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US10158590B1 (en) 2010-07-09 2018-12-18 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US10212112B1 (en) 2010-07-09 2019-02-19 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US10015122B1 (en) 2012-10-18 2018-07-03 Sitting Man, Llc Methods and computer program products for processing a search
US20140172998A1 (en) * 2012-12-16 2014-06-19 Deep River Ventures, Llc Methods, Systems, and Computer Program Products for Browsing Via a Communications Agent
US10419374B1 (en) 2010-07-09 2019-09-17 Gummarus, Llc Methods, systems, and computer program products for processing a request for a resource in a communication
US8935613B1 (en) 2010-10-28 2015-01-13 Google Inc. Communication initiation control
EP2469822B1 (en) * 2010-12-23 2019-07-31 Unify GmbH & Co. KG Computer-Telephone-Integration whereby the computers are connected via a presence server
CN102143181B (en) * 2011-03-31 2014-03-05 中国联合网络通信集团有限公司 Method and device for acquiring resources in grid environment
US9413556B2 (en) * 2011-06-03 2016-08-09 Apple Inc. Unified account list
US9124646B2 (en) 2012-02-16 2015-09-01 Blackberry Limited Method and system for obtaining availability status for multiple SIP users
US9043415B2 (en) * 2012-05-09 2015-05-26 International Business Machines Corporation Managing a subscription hierarchy in presence systems
US10021052B1 (en) 2012-09-22 2018-07-10 Sitting Man, Llc Methods, systems, and computer program products for processing a data object identification request in a communication
US10013158B1 (en) 2012-09-22 2018-07-03 Sitting Man, Llc Methods, systems, and computer program products for sharing a data object in a data store via a communication
US20140172999A1 (en) * 2012-12-16 2014-06-19 Deep River Ventures, Llc Methods, Systems, and Computer Program Products for Accessing a Service Via a Proxy Communications Agent
US10019135B1 (en) 2012-10-18 2018-07-10 Sitting Man, Llc Methods, and computer program products for constraining a communication exchange
US10033672B1 (en) 2012-10-18 2018-07-24 Sitting Man, Llc Methods and computer program products for browsing using a communicant identifier
US9560145B2 (en) * 2013-07-20 2017-01-31 Cisco Technology, Inc. XMPP based UPNP device architecture for cloud computing in a network environment
DE102014219090A1 (en) * 2014-09-22 2016-03-24 Siemens Aktiengesellschaft Device with communication interface and method for controlling a database access
CN107621968A (en) * 2016-07-15 2018-01-23 阿里巴巴集团控股有限公司 One kind instruction issues request processing method and control node

Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5960406A (en) * 1998-01-22 1999-09-28 Ecal, Corp. Scheduling system for use between users on the web
US5963913A (en) * 1997-02-28 1999-10-05 Silicon Graphics, Inc. System and method for scheduling an event subject to the availability of requested participants
US6240451B1 (en) * 1995-05-25 2001-05-29 Punch Networks Corporation Method and apparatus for automatically disseminating information over a network
US20020019816A1 (en) * 1994-05-02 2002-02-14 Avner Shafrir Co-presence data retrieval system which indicates observers of data
US20020055973A1 (en) * 2000-10-17 2002-05-09 Low Colin Andrew Inviting assistant entity into a network communication session
US20030225840A1 (en) * 2002-05-28 2003-12-04 Glassco David H.J. Change notification and update service for object sharing via publication and subscription
US20030233537A1 (en) * 2002-06-10 2003-12-18 Wohlgemuth Sean Christian Presence and notification system for maintaining and communicating information
US20040002967A1 (en) * 2002-03-28 2004-01-01 Rosenblum David S. Method and apparatus for implementing query-response interactions in a publish-subscribe network
US20040034848A1 (en) * 2002-08-09 2004-02-19 Eric Moore Rule engine
US20040117458A1 (en) * 2002-09-06 2004-06-17 Sony Corporation Program, method and apparatus for processing information
US20040122896A1 (en) * 2002-12-24 2004-06-24 Christophe Gourraud Transmission of application information and commands using presence technology
US6757722B2 (en) * 2002-07-16 2004-06-29 Nokia Corporation System and method for providing partial presence notifications
US6757833B2 (en) * 1997-03-24 2004-06-29 Canon Kabushiki Kaisha Information processing apparatus for performing processing dependent on presence/absence of user, and method therefor
US20040128181A1 (en) * 2002-12-31 2004-07-01 Zurko Mary Ellen Instance messaging auto-scheduling
US20040187133A1 (en) * 2000-09-15 2004-09-23 Bernhard Weisshaar Service framework with local proxy for representing remote services
US20050027805A1 (en) * 2003-07-15 2005-02-03 Aoki Norihiro Edwin Instant messaging and enhanced scheduling
US6853634B1 (en) * 1999-12-14 2005-02-08 Nortel Networks Limited Anonymity in a presence management system
US20050114159A1 (en) * 2003-11-25 2005-05-26 Timucin Ozugur Web based CRM service using on-line presence information
US20050267896A1 (en) * 2002-07-26 2005-12-01 International Business Machines Corporation Performing an operation on a message received from a publish/subscribe service
US6980993B2 (en) * 2001-03-14 2005-12-27 Microsoft Corporation Schemas for a notification platform and related information services
US20060014546A1 (en) * 2004-07-13 2006-01-19 International Business Machines Corporation Dynamic media content for collaborators including disparate location representations
US7035923B1 (en) * 2002-04-10 2006-04-25 Nortel Networks Limited Presence information specifying communication preferences
US20060195565A1 (en) * 2003-08-01 2006-08-31 Antoine De-Poorter Method and Apparatus for Routing a Service Request
US20060224688A1 (en) * 2005-03-31 2006-10-05 Morris Robert P System and method for utilizing a presence service to facilitate access to a service or application over a network
US7219153B1 (en) * 2002-12-02 2007-05-15 Cisco Technology, Inc. Methods and apparatus for distributing content
US20070162360A1 (en) * 2004-06-30 2007-07-12 Archer-Daniels-Midland Company Container inventory management systems, methods and tools
US7269162B1 (en) * 2001-07-20 2007-09-11 Cisco Technology, Inc. Integration of presence services with a network enabled telephony device
US20080046556A1 (en) * 2002-09-16 2008-02-21 Geoffrey Deane Owen Nicholls Method and apparatus for distributed rule evaluation in a near real-time business intelligence system
US20080049734A1 (en) * 1998-09-24 2008-02-28 Zhakov Vyacheslav I Call Transfer Using Session Initiation Protocol (SIP)
US7412522B2 (en) * 2002-08-12 2008-08-12 Mitel Networks Corporation System and method for facilitating communication using presence and communication services
US7606913B2 (en) * 2003-06-17 2009-10-20 Hitachi, Ltd. Presence management apparatus
US7686215B2 (en) * 2005-05-21 2010-03-30 Apple Inc. Techniques and systems for supporting podcasting

Family Cites Families (132)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US129901A (en) * 1872-07-30 Improvement in processes of rendering leather
US86309A (en) * 1869-01-26 Improved table
US215723A (en) * 1879-05-27 Improvement in jet-exhausters for gas-works
US122896A (en) * 1872-01-23 Improvement in horse-powers
US172455A (en) * 1876-01-18 Improvement in hay rakers and loaders
US125941A (en) * 1872-04-23 Improvement in apparatus for the manufacture of gas from petroleum
US23132A (en) * 1859-03-01 Improvement in harvesters
US243941A (en) * 1881-07-05 Device for threading pipes
US43190A (en) * 1864-06-21 Improvement in collar-clasps
US3090A (en) * 1843-05-19 Method
US4995A (en) * 1847-03-06 Improvement in plows
US177134A (en) * 1876-05-09 Ifvlproveiviewt in compositions for cigar-lighters
US153506A (en) * 1874-07-28 Improvement in packings for extension gas-fixtures
US10637A (en) * 1854-03-14 albert hock
US55898A (en) * 1866-06-26 Improved medicine to cure cholera
US236832A (en) * 1881-01-18 Road-engine
US158608A (en) * 1875-01-12 In the manufacture of leather
US86300A (en) * 1869-01-26 Improvement in letter-openers
US177116A (en) * 1876-05-09 Improvement in thermostats
US27805A (en) * 1860-04-10 Improvement in needle-guards
US4985A (en) * 1847-02-27 Improvement in the manufacture of sugar
US236831A (en) * 1881-01-18 Carpet-cleaner
US21626A (en) * 1858-09-28 Office
US117458A (en) * 1871-07-25 Improvement in steam-engines
US135569A (en) * 1873-02-04 Improvement in wash-boiler attachments
US179039A (en) * 1876-06-20 Improvement in machines for cutting ovals
US39134A (en) * 1863-07-07 Improved egg-beater
US55983A (en) * 1866-07-03 Improved beverage
US236830A (en) * 1881-01-18 Francis e
US4984A (en) * 1847-02-27 Henry stanton
US9530A (en) * 1853-01-11 Improvement in porous cells for galvanic batteries
US65788A (en) * 1867-06-18 Improved car-truck
US130904A (en) * 1872-08-27 Improvement in machines for turning logs
US21624A (en) * 1858-09-28 India-rubber car-springs
US200268A (en) * 1878-02-12 Improvement in reels
US182428A (en) * 1876-09-19 Improvement in devices for catching water-fowls
US44144A (en) * 1864-09-06 Improved packing for hydro carbon-burners
US183829A (en) * 1876-10-31 Improvement in suspender-ends
US108387A (en) * 1870-10-18 Improvement in machines for making rope
US5491626A (en) 1993-06-16 1996-02-13 International Business Machines Corporation Method and apparatus for profile transposition to calendar events
EP0733967B1 (en) 1995-03-24 2005-02-09 Hewlett-Packard Company, A Delaware Corporation Methods and apparatus for monitoring events and implementing corrective action in a multi-entity computer system
KR100239719B1 (en) 1997-01-07 2000-01-15 김영환 Method for etching organic layer for manufacturing semiconductor device
US6148328A (en) 1998-01-29 2000-11-14 International Business Machines Corp. Method and system for signaling presence of users in a networked environment
US6085166A (en) 1998-06-19 2000-07-04 International Business Machines Electronic calendar with group scheduling and asynchronous fan out method
WO2000016209A1 (en) 1998-09-15 2000-03-23 Local2Me.Com, Inc. Dynamic matchingtm of users for group communication
US6400381B1 (en) 1999-06-11 2002-06-04 International Business Machines Corporation Web places
US6301609B1 (en) 1999-07-07 2001-10-09 Lucent Technologies Inc. Assignable associate priorities for user-definable instant messaging buddy groups
US6430604B1 (en) 1999-08-03 2002-08-06 International Business Machines Corporation Technique for enabling messaging systems to use alternative message delivery mechanisms
US6549939B1 (en) 1999-08-31 2003-04-15 International Business Machines Corporation Proactive calendar notification agent
US6754904B1 (en) 1999-12-30 2004-06-22 America Online, Inc. Informing network users of television programming viewed by other network users
US6799196B1 (en) 2000-01-21 2004-09-28 Gateway, Inc. On-demand data streaming parceling
US6668167B2 (en) 2000-01-26 2003-12-23 Mcdowell Mark Method and apparatus for sharing mobile user event information between wireless networks and fixed IP networks
US6839735B2 (en) 2000-02-29 2005-01-04 Microsoft Corporation Methods and systems for controlling access to presence information according to a variety of different access permission types
JP3926963B2 (en) 2000-03-03 2007-06-06 富士通株式会社 State setting system and method
WO2001072002A2 (en) 2000-03-17 2001-09-27 America Online, Inc. Shared groups rostering system
US6961765B2 (en) 2000-04-06 2005-11-01 Bbx Technologies, Inc. System and method for real time monitoring and control of networked computers
US6839737B1 (en) 2000-07-19 2005-01-04 Neoplanet, Inc. Messaging system for indicating status of a sender of electronic mail and method and computer program product therefor
US20030009530A1 (en) 2000-11-08 2003-01-09 Laurent Philonenko Instant message presence protocol for facilitating communication center activity
US6668173B2 (en) 2000-12-15 2003-12-23 Motorola, Inc. Instant message user location tracking system
US7010303B2 (en) * 2000-12-22 2006-03-07 Research In Motion Limited Wireless router system and method
US20020103743A1 (en) 2001-01-30 2002-08-01 Sun Microsystems, Inc. Platform independent business to business publish/subscribe messaging system
US20020120774A1 (en) 2001-02-05 2002-08-29 Athanassios Diacakis Method of sending a communication from a first terminal to a second terminal via a host
US6981223B2 (en) 2001-03-19 2005-12-27 Ecrio, Inc. Method, apparatus and computer readable medium for multiple messaging session management with a graphical user interface
US20030055983A1 (en) 2001-03-19 2003-03-20 Jeff Callegari Methods for providing a virtual journal
AUPR459901A0 (en) 2001-04-27 2001-05-24 Sharinga Networks Inc. Instant messaging
DE60203798T2 (en) 2001-05-11 2006-02-09 Nokia Corp. MOBILE INSTANT MESSAGING AND PRESENCE SERVICE
US8868659B2 (en) 2001-05-15 2014-10-21 Avaya Inc. Method and apparatus for automatic notification and response
US8311887B2 (en) 2001-05-29 2012-11-13 Fujitsu Limited Methods, devices and systems for real-time instant presence with advertisement (RIPA)
US20030120734A1 (en) 2001-06-15 2003-06-26 Justin Kagan Method and system for peer-to-peer networking and information sharing architecture
US7203753B2 (en) 2001-07-31 2007-04-10 Sun Microsystems, Inc. Propagating and updating trust relationships in distributed peer-to-peer networks
US7346658B2 (en) 2001-08-08 2008-03-18 At&T Delaware Intellectual Property, Inc. System and method for notifying an offline global computer network user of an online interaction
US20030043190A1 (en) 2001-08-31 2003-03-06 Eastman Kodak Company Website chat room having images displayed simultaneously with interactive chatting
US20030097410A1 (en) 2001-10-04 2003-05-22 Atkins R. Travis Methodology for enabling multi-party collaboration across a data network
US20030119540A1 (en) 2001-12-21 2003-06-26 Mathis James Earl Contact list-based group call
US20030135569A1 (en) 2002-01-15 2003-07-17 Khakoo Shabbir A. Method and apparatus for delivering messages based on user presence, preference or location
JP2005518114A (en) 2002-02-14 2005-06-16 アバイア テクノロジー コーポレーション Presence tracking and namespace interconnect technology
US20030182428A1 (en) 2002-03-19 2003-09-25 Jiang Li Peer-to-peer (P2P) communication system
US7028075B2 (en) 2002-04-23 2006-04-11 Flashpoint Technology, Inc. Method and system for sharing digital images over a network
US20030217098A1 (en) 2002-05-15 2003-11-20 Microsoft Corporation Method and system for supporting the communication of presence information regarding one or more telephony devices
US20040109197A1 (en) 2002-06-05 2004-06-10 Isabelle Gardaz Apparatus and method for sharing digital content of an image across a communications network
US20030236830A1 (en) 2002-06-19 2003-12-25 Eastman Kodak Company Method and system for sharing images over a communication network among a plurality of users
US7392296B2 (en) 2002-06-19 2008-06-24 Eastman Kodak Company Method and computer software program for sharing images over a communication network among a plurality of users in accordance with a criteria
US8307046B2 (en) 2002-06-19 2012-11-06 Eastman Kodak Company Method and system for setting up a system for sharing images over a communication network between multiple users
US7139554B2 (en) 2002-06-24 2006-11-21 Thomson Licensing User-selectable status indication for cellular communications devices
US20040003090A1 (en) 2002-06-28 2004-01-01 Douglas Deeds Peer-to-peer media sharing
US7111044B2 (en) 2002-07-17 2006-09-19 Fastmobile, Inc. Method and system for displaying group chat sessions on wireless mobile terminals
US8150922B2 (en) 2002-07-17 2012-04-03 Research In Motion Limited Voice and text group chat display management techniques for wireless mobile terminals
US7912899B2 (en) * 2002-09-06 2011-03-22 Oracle International Corporation Method for selectively sending a notification to an instant messaging device
US20040059781A1 (en) 2002-09-19 2004-03-25 Nortel Networks Limited Dynamic presence indicators
DE10245642A1 (en) 2002-09-30 2004-04-15 Siemens Ag Procedure for providing absence information
AU2003270863A1 (en) 2002-09-30 2004-04-23 Advent Networks, Inc. Implementing request/reply programming semantics using publish/subscribe middleware
US8037202B2 (en) 2002-10-31 2011-10-11 Oracle America, Inc. Presence detection using mobile agents in peer-to-peer networks
AU2003291042A1 (en) 2002-11-18 2004-06-15 America Online, Inc. Enhanced buddy list interface
JP4093850B2 (en) 2002-12-03 2008-06-04 シャープ株式会社 Optical object identification apparatus, printing apparatus using the same, and object type classification apparatus
US7257218B2 (en) 2002-12-30 2007-08-14 Nortel Networks Limited Presence enabled queue management
US7711810B2 (en) 2003-01-03 2010-05-04 Nortel Networks Limited Distributed services based on presence technology
EP1786173B1 (en) 2003-01-22 2013-06-26 NEC Corporation Dynamic buddy list generation method
JP2004240821A (en) * 2003-02-07 2004-08-26 Nec Corp Presence service system, presence server, and presence server program
US7949712B2 (en) 2003-02-10 2011-05-24 At&T Intellectual Property I, L.P. High availability presence engine for instant messaging
US8204938B2 (en) 2003-02-14 2012-06-19 Devereux Research Ab Llc System and method for immediate and delayed real-time communication activities using availability data from and communications through an external instant messaging system
US7263545B2 (en) 2003-02-14 2007-08-28 Convoq, Inc. System and method for immediate and delayed real-time communication activities using availability data from and communications through an external instant messaging system
US7184524B2 (en) 2003-02-14 2007-02-27 Convoq, Inc. Rules based real-time communication system
US20040179037A1 (en) 2003-03-03 2004-09-16 Blattner Patrick D. Using avatars to communicate context out-of-band
US7930350B2 (en) 2003-03-05 2011-04-19 Canon U.S.A., Inc. Digital image sharing enabled chat application
US7543237B2 (en) 2003-03-19 2009-06-02 Accenture Global Servicecs Gmbh Dynamic collaboration assistant
US20040201668A1 (en) 2003-04-11 2004-10-14 Hitachi, Ltd. Method and apparatus for presence indication
US20040215723A1 (en) 2003-04-22 2004-10-28 Siemens Information Methods and apparatus for facilitating online presence based actions
US7334021B1 (en) 2003-04-30 2008-02-19 Aol Llc Personalized away messages
BRPI0410362B1 (en) 2003-05-16 2017-06-20 Google Inc. SYSTEMS AND METHODS OF SHARING NETWORK AND NETWORK MEDIA
US20040250212A1 (en) 2003-05-20 2004-12-09 Fish Edmund J. User interface for presence and geographic location notification based on group identity
US20050021626A1 (en) 2003-05-22 2005-01-27 Cisco Technology, Inc. Peer-to-peer dynamic web page sharing
US7409639B2 (en) 2003-06-19 2008-08-05 Accenture Global Services Gmbh Intelligent collaborative media
JP4340576B2 (en) * 2003-06-23 2009-10-07 株式会社日立製作所 server
EP1492307A1 (en) * 2003-06-27 2004-12-29 Hewlett-Packard Development Company, L.P. Method and apparatus for automatically determining a presence status
US20040267887A1 (en) 2003-06-30 2004-12-30 Berger Kelly D. System and method for dynamically managing presence and contact information
US8001187B2 (en) 2003-07-01 2011-08-16 Apple Inc. Peer-to-peer active content sharing
US8135759B2 (en) 2003-08-07 2012-03-13 Teamon Systems, Inc. Communications system including protocol interface device for use with multiple operating protocols and related methods
US20050039134A1 (en) 2003-08-11 2005-02-17 Sony Corporation System and method for effectively implementing a dynamic user interface in an electronic network
WO2005022330A2 (en) * 2003-08-27 2005-03-10 Jambo Networks, Inc. A system and method for providing communication services to mobile device users
US8688786B2 (en) * 2003-09-25 2014-04-01 Oracle America, Inc. Method and system for busy presence state detection in an instant messaging system
US20050071428A1 (en) * 2003-09-26 2005-03-31 Khakoo Shabbir A. Method and apparatus for delivering an electronic mail message with an indication of the presence of the sender
US7287066B2 (en) * 2003-10-31 2007-10-23 Sap Aktiengesellschaft Publish-subscribe system having a reliability mechanism
US20050119913A1 (en) * 2003-12-01 2005-06-02 International Business Machines Corporation Subscription-based dynamic content update
ES2300536T3 (en) * 2003-12-02 2008-06-16 Alcatel Lucent DISSEMINATION OF SERVICES BASED ON THE LOCATION OF A MOBILE TERMINAL IN A WIRELESS NETWORK.
US8443092B2 (en) * 2003-12-23 2013-05-14 Alcatel Lucent Presentity filtering for user preferences
US7376670B2 (en) * 2004-02-20 2008-05-20 Alcatel-Lucent System and method for provisioning presence application services
US20050190744A1 (en) * 2004-02-27 2005-09-01 Xian-He Sun Method of informing a callee of an attempted telephone call by means of internet protocol messaging
US20050213609A1 (en) * 2004-03-25 2005-09-29 Alec Brusilovsky Providing internet users with presence information about telephone lines in the public switched telephone network
US7444379B2 (en) 2004-06-30 2008-10-28 International Business Machines Corporation Method for automatically setting chat status based on user activity in local environment
US20060004921A1 (en) * 2004-06-30 2006-01-05 Suess Carol S Systems and methods for establishing communication between users
US20060036712A1 (en) * 2004-07-28 2006-02-16 Morris Robert P System and method for providing and utilizing presence information
US7593984B2 (en) * 2004-07-30 2009-09-22 Swift Creek Systems, Llc System and method for harmonizing changes in user activities, device capabilities and presence information

Patent Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020019816A1 (en) * 1994-05-02 2002-02-14 Avner Shafrir Co-presence data retrieval system which indicates observers of data
US6240451B1 (en) * 1995-05-25 2001-05-29 Punch Networks Corporation Method and apparatus for automatically disseminating information over a network
US5963913A (en) * 1997-02-28 1999-10-05 Silicon Graphics, Inc. System and method for scheduling an event subject to the availability of requested participants
US6757833B2 (en) * 1997-03-24 2004-06-29 Canon Kabushiki Kaisha Information processing apparatus for performing processing dependent on presence/absence of user, and method therefor
US5960406A (en) * 1998-01-22 1999-09-28 Ecal, Corp. Scheduling system for use between users on the web
US20080049734A1 (en) * 1998-09-24 2008-02-28 Zhakov Vyacheslav I Call Transfer Using Session Initiation Protocol (SIP)
US6853634B1 (en) * 1999-12-14 2005-02-08 Nortel Networks Limited Anonymity in a presence management system
US20040187133A1 (en) * 2000-09-15 2004-09-23 Bernhard Weisshaar Service framework with local proxy for representing remote services
US20020055973A1 (en) * 2000-10-17 2002-05-09 Low Colin Andrew Inviting assistant entity into a network communication session
US6980993B2 (en) * 2001-03-14 2005-12-27 Microsoft Corporation Schemas for a notification platform and related information services
US7302634B2 (en) * 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7269162B1 (en) * 2001-07-20 2007-09-11 Cisco Technology, Inc. Integration of presence services with a network enabled telephony device
US20040002967A1 (en) * 2002-03-28 2004-01-01 Rosenblum David S. Method and apparatus for implementing query-response interactions in a publish-subscribe network
US7035923B1 (en) * 2002-04-10 2006-04-25 Nortel Networks Limited Presence information specifying communication preferences
US20030225840A1 (en) * 2002-05-28 2003-12-04 Glassco David H.J. Change notification and update service for object sharing via publication and subscription
US20030233537A1 (en) * 2002-06-10 2003-12-18 Wohlgemuth Sean Christian Presence and notification system for maintaining and communicating information
US6757722B2 (en) * 2002-07-16 2004-06-29 Nokia Corporation System and method for providing partial presence notifications
US20060036679A1 (en) * 2002-07-26 2006-02-16 International Business Machines Corporation Pub/sub message invoking a subscribers client application program
US20050267896A1 (en) * 2002-07-26 2005-12-01 International Business Machines Corporation Performing an operation on a message received from a publish/subscribe service
US20040034848A1 (en) * 2002-08-09 2004-02-19 Eric Moore Rule engine
US7412522B2 (en) * 2002-08-12 2008-08-12 Mitel Networks Corporation System and method for facilitating communication using presence and communication services
US20040117458A1 (en) * 2002-09-06 2004-06-17 Sony Corporation Program, method and apparatus for processing information
US20080046556A1 (en) * 2002-09-16 2008-02-21 Geoffrey Deane Owen Nicholls Method and apparatus for distributed rule evaluation in a near real-time business intelligence system
US7219153B1 (en) * 2002-12-02 2007-05-15 Cisco Technology, Inc. Methods and apparatus for distributing content
US20040122896A1 (en) * 2002-12-24 2004-06-24 Christophe Gourraud Transmission of application information and commands using presence technology
US20040128181A1 (en) * 2002-12-31 2004-07-01 Zurko Mary Ellen Instance messaging auto-scheduling
US7606913B2 (en) * 2003-06-17 2009-10-20 Hitachi, Ltd. Presence management apparatus
US20050027805A1 (en) * 2003-07-15 2005-02-03 Aoki Norihiro Edwin Instant messaging and enhanced scheduling
US20060195565A1 (en) * 2003-08-01 2006-08-31 Antoine De-Poorter Method and Apparatus for Routing a Service Request
US20050114159A1 (en) * 2003-11-25 2005-05-26 Timucin Ozugur Web based CRM service using on-line presence information
US20070162360A1 (en) * 2004-06-30 2007-07-12 Archer-Daniels-Midland Company Container inventory management systems, methods and tools
US20060014546A1 (en) * 2004-07-13 2006-01-19 International Business Machines Corporation Dynamic media content for collaborators including disparate location representations
US20060224688A1 (en) * 2005-03-31 2006-10-05 Morris Robert P System and method for utilizing a presence service to facilitate access to a service or application over a network
US7686215B2 (en) * 2005-05-21 2010-03-30 Apple Inc. Techniques and systems for supporting podcasting

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8533306B2 (en) 2006-09-21 2013-09-10 At&T Intellectual Property I, L.P. Personal presentity presence subsystem
US20110004518A1 (en) * 2008-03-12 2011-01-06 Christer Boberg Method and user device for handling mobile advertising
US20100262809A1 (en) * 2009-04-09 2010-10-14 Research In Motion Limited System and Method for Conflict Resolution During the Consolidation of Information Relating to a Data Service
US8214434B2 (en) * 2009-04-09 2012-07-03 Research In Motion Limited System and method for conflict resolution during the consolidation of information relating to a data service
US9258376B2 (en) * 2009-08-04 2016-02-09 At&T Intellectual Property I, L.P. Aggregated presence over user federated devices
US20110035443A1 (en) * 2009-08-04 2011-02-10 At&T Intellectual Property I, L.P. Aggregated Presence Over User Federated Devices
US10511552B2 (en) 2009-08-04 2019-12-17 At&T Intellectual Property I, L.P. Aggregated presence over user federated devices
US8346853B2 (en) 2010-05-27 2013-01-01 Robert Paul Morris Methods, systems, and computer program products for processing an attached command response
US8577958B2 (en) 2010-05-28 2013-11-05 Robert Paul Morris Methods, systems, and computer program products for processing a non-returnable command response based on a markup element
US10387614B2 (en) * 2010-06-08 2019-08-20 Merge Healthcare Incorporated Remote control of medical devices using instant messaging infrastructure
US20110302414A1 (en) * 2010-06-08 2011-12-08 Mark Logan Remote control of medical devices using instant messaging infrastructure
US8621213B2 (en) * 2010-06-08 2013-12-31 Merge Healthcare, Inc. Remote control of medical devices using instant messaging infrastructure
US9385977B2 (en) 2010-06-08 2016-07-05 Merge Healthcare Incorporated Remote control of medical devices using instant messaging infrastructure
US8601115B2 (en) * 2010-06-26 2013-12-03 Cisco Technology, Inc. Providing state information and remote command execution in a managed media device
US20110320585A1 (en) * 2010-06-26 2011-12-29 Cisco Technology, Inc. Providing state information and remote command execution in a managed media device
US9060345B2 (en) * 2010-09-29 2015-06-16 At&T Intellectual Property I, L.P. Notifications based on device presence
US9503998B2 (en) 2010-09-29 2016-11-22 At&T Intellectual Property I, L.P. Notifications based on device presence
US10003920B2 (en) 2010-09-29 2018-06-19 At&T Intellectual Property I, L.P. Notifications based on device presence
US20130244650A1 (en) * 2010-09-29 2013-09-19 At&T Intellectual Property I, L.P. Notifications based on device presence
US10631119B2 (en) 2010-09-29 2020-04-21 At&T Intellectual Property I, L.P. Notifications based on device presence

Also Published As

Publication number Publication date
EP1889429A2 (en) 2008-02-20
US20060280166A1 (en) 2006-12-14
JP2008546356A (en) 2008-12-18
CN101273593A (en) 2008-09-24
WO2006135685A2 (en) 2006-12-21
WO2006135685A3 (en) 2007-12-27
US7567553B2 (en) 2009-07-28

Similar Documents

Publication Publication Date Title
US7567553B2 (en) Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol
US7587450B2 (en) HTTP publish/subscribe communication protocol
US7890572B2 (en) Pub/sub message invoking a subscribers client application program
EP1379971B1 (en) Schemas for a notification platform and related information services
US20060224688A1 (en) System and method for utilizing a presence service to facilitate access to a service or application over a network
US20070168420A1 (en) Method and apparatus for providing customized subscription data
US9330190B2 (en) Method and system for providing data handling information for use by a publish/subscribe client
US9124447B2 (en) Interactive client computer communication
US8156183B2 (en) Mobile phone aggregation system
US20080147799A1 (en) Methods, Systems, And Computer Program Products For Providing Access To A Secure Service Via A Link In A Message
US20150172228A1 (en) Method and system for communicating information over a network
US20080126475A1 (en) Method And System For Providing Supplemental Information In A Presence Client-Based Service Message
US20070047701A1 (en) Internet alerts
US20070208702A1 (en) Method and system for delivering published information associated with a tuple using a pub/sub protocol
US20030131069A1 (en) Schema-based context service
US20070027915A1 (en) Method and system for processing a workflow using a publish-subscribe protocol
US20090125420A1 (en) Web-based information delivery method, system, and apparatus
CA2729867A1 (en) A method to provide an option to the customer relationship management (crm) user to select from a list of short message service (sms) gateways from the graphical user interface (gui) before sending out an sms message
AU2016200982B2 (en) Communication system and method
US20080313323A1 (en) Methods, Systems, And Computer Program Products For Monitoring Transaction Status With A Presence Tuple
US20080183816A1 (en) Method and system for associating a tag with a status value of a principal associated with a presence client
US20090265358A1 (en) Methods, Systems, And Computer Program Products For Accessing Metadata Associated With A Network-Accessible Resource
US8954509B1 (en) System and method for broadcasting data over a computer network

Legal Events

Date Code Title Description
AS Assignment

Owner name: SCENERA TECHNOLOGIES, LLC, NEW HAMPSHIRE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MORRIS, ROBERT P.;REEL/FRAME:022995/0490

Effective date: 20060301

Owner name: SWIFT CREEK SYSTEMS, LLC, NEW HAMPSHIRE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCENERA TECHNOLOGIES, LLC;REEL/FRAME:022995/0517

Effective date: 20061012

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: SCENERA TECHNOLOGIES, LLC, NEW HAMPSHIRE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SWIFT CREEK SYSTEMS, LLC;REEL/FRAME:044830/0065

Effective date: 20171122