CA2436061C - System and method for facilitating communication using presence and communication system - Google Patents
System and method for facilitating communication using presence and communication system Download PDFInfo
- Publication number
- CA2436061C CA2436061C CA002436061A CA2436061A CA2436061C CA 2436061 C CA2436061 C CA 2436061C CA 002436061 A CA002436061 A CA 002436061A CA 2436061 A CA2436061 A CA 2436061A CA 2436061 C CA2436061 C CA 2436061C
- Authority
- CA
- Canada
- Prior art keywords
- service
- presentity
- user
- communication
- checking
- 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.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
- H04M2203/2066—Call type detection of indication, e.g. voice or fax, mobile of fixed, PSTN or IP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/45—Aspects of automatic or semi-automatic exchanges related to voicemail messaging
- H04M2203/4536—Voicemail combined with text-based messaging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42025—Calling or Called party identification service
- H04M3/42034—Calling party identification service
- H04M3/42059—Making use of the calling party identifier
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42025—Calling or Called party identification service
- H04M3/42085—Called party identification service
- H04M3/42093—Notifying the calling party of information on the called or connected party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42365—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity
Abstract
A method for facilitating communication with a user. The method comprises the steps of receiving contact information for the user, from a presence service; checking to determine if a particular communication service is supported by the user; checking to determine if the contact address of the user is accessible; launching at least one of an appropriate helper application and objects; and initiating communication with the user through the particular communication service.
Description
~vstem and method fir facilitating communication using_nresence and communicati~
services Field of Invention The present invention relates to communication systems and more particularly to a system for facilitating communication using separate presence and communication services.
to Bacl~ground of the InventiQ~
Presence services are primarily used for providing "availability" information of one user to another user of a system. This "availability" information includes an indication of desire and availability or willingness of the user to engage in immediate 15 communication. In order to achieve immediate communication a Presence Service is used to convey contact information to a user's presence client and the presence client is required to use that information to determine how to connect the users. This is particularly difficult when the communication services are developed by a third party vendor.
Communication services include any application that creates a communication path 2o between two or more parties. Examples of such services include telephone voice connections, Instant Messaging, chat, video conferencing, and sharing of presentations.
Existing Presence, or Instant Messaging (IM), services rely on a fixed and a built-in set of communication connection aids. For example, in order to enable communication 25 via instant messaging services such as MSN and AOL, the communication service is normally tightly coupled with the presence service. These communication services are developed by the same vendor and usually pass through the IM server.
The prior art suffers inherent disadvantages because they are "closed"
systems.
3o There is no flexible way to add other telephony or communication services to these systems. For example, the existing Instant Messaging systems cannot add a non-IP phone call set via third party voice products. The communication connections of these systems are hardwired and limited. While this may be suitable for IM chat style of communication services, it is not suitable for other communication services, for example, existing telephony services.
Several standard bodies are attempting to define how contact information is conveyed with a user's availability in a presence framework. Of particular interest is the IETF Instant Message and Presence Protocol (IMPP) set forth in "A Model for Presence and Instant Messaging", M. Day, J. Rosenberg, and H. Sugano, IETF RFC 2778, February 2000. Two further IETF documents discuss the Common Profile for Instant Messaging (CPIM). These two documents are the Common Presence and Instant Messaging:
Message Format document (Common Presence and Instant Messaging: Message Format <draft-ietf impp-cpim-msgfint-03.txt>) and the CPIM Presence Information Data Format (CPIM Presence Information Data Format <draft-ietf impp-cpim-pidf OO.txt>).
The Common Presence and Instant Messaging: Message Format document defines a mime content-type 'message/cpim' object which is a multipart entity. This document defines the structure of an IM message specifying mandatory fields such as "From:", "To:", "Date:", "Subject:", etc. The second document, CPIM Presence Information Data, defines the actual contact information that a presence client receives in order to enable a communication session between two users of a presence service. This document does not 2o discuss how a presence client uses contact information for launching third party communication applications.
There is no flexible way to enhance any existing Presence (or Availability) Service to handle communication connection via third party communication products.
Summarv of the Invention In accordance with the present invention, a system is provided for facilitating communication through separation between the presence and communication components.
3o The system is based on the exchange of availability messages that are not based on the mime format, and which contain information for proper presence service functioning.
Preferably, the system adopts the SLP service definition format and provides a method for a presence client to use contact information for launching third party communication applications.
Therefore, in accordance with the present invention, there is provided an approach and protocol to allow a Presence service to employ third party communication services to handle communication connection after a user's availability is established.
Advantageously, the present invention enables a Presence Service to deploy any number of communication mediums to create a communication path, including, for example, different Instant Messaging providers to send instant messages.
to Brief Desc~tion o the Drawing The present invention will be described in detail with reference to the accompanying drawings, in which like numerals denote like parts, and in which:
15 Figure 1 is a block diagram of a communication system according an embodiment of the present invention;
Figure 2 is a diagram showing separation of Projection of Availability (POA) information from Control of Communications (COC) information according to the present 20 invention;
Figure 3 is a representation of an application of the invention for facilitating ad hoc collaboration; and 25 Figure 4 is a representation of another application of the invention to contacting experts in a retail environment.
Detailed Descr~tion 3o A presence service generally offers two types of information, including projection of availability and communication contact information. Projection of availability includes the user's availability information and is an indication of the person's desire or willingness for communication. The availability information is projected, or conveyed, to other users.
A user appears available if that user is willing to communicate. Otherwise, the user appears unavailable.
Communication contact information includes information used for connecting with a user, such as how, where or by what means a user is available for communication. The contact information describes different communication service types on which the user is available at that time. Such communication types include telephony, Instant Messaging, chat, video streaming, etc.
to The following is an example of how a presence client registers and receives availability information. This example is provided in order to give a better understanding of the mechanism by which the presence service projects a user's availability and is provided solely for the purpose of illustration. Refernng to Figure l, a presence system according to an embodiment of the present invention is indicated generally by the numeral 20. The presence system includes a presence server 22 which runs the presence service which includes a directory service 24 and a presence agent 26, a presence client 28 and resources 30, as will be described in more detail below.
The presence server 22 is a server that allows users to publish their availability to 2o communicate to other users. The presence service on the presence server 22 includes a directory service 24 and a presence agent 26. A user registration procedure is targeted primarily to the directory service 24, while a user log-in procedure is performed on the presence agent 26. Procedures such as user registration and user log-in are two distinct operations.
The directory service 24 is static data storage for storing a data record in association with each user. The data record includes static information about the user including, for example, name, ID, password, address, etc. The directory service 24 allows authorized access to the system from applications other than the presence service on the 3o presence server 22.
The presence agent 26 is an entity within the presence server 22 that is associated with one individual user. The presence agent 26 is responsible for storage and management of user defined presence policies, and a user profile. The presence policies are used to determine the acceptance of "Subscription" requests from other presence agents that want to view the availability of the individual user and to control when availability notifications are to be sent to those presence agents already subscribed. It maintains contact and user state information that is projected to those users subscribed to the individual user's presence. Communication between the user and presence agents 26 is enabled via presence clients 28.
The presence client 28 is a platform specific software entity that resides on an individual device and operates as a user interface to the presence server 22.
There can 1o exist several presence clients for an individual user. The presence client 28 facilitates communication between the user and the associated presence agent 26. This communication includes, for example, subscription and notification policies, resource contact information, user role, relationship, and buddy list management, as discussed in greater detail with reference to applicant's copending application filed on the same day as 15 this application and entitled "Architecture and Implementation for Control of Context Aware Call Processing with Local Feature Definition". The login procedure is used to authenticate a client in order for the client to obtain permission for such communication.
A resource 30 is an entity that represents a communication identification and 2o communication service. A resource can be activated/deactivated, added, removed or modified. The system 20 generally includes more than one resource 30 and each resource 30 has an associated resource profile. The resource profile includes a resource identification, an indication of whether or nor the resource is active and a communication address. An exemplary resource profile for a desktop phone is listed below.
25 <resource-profile id='desktop phone' active=' inactive' service url= 'serviceaelephonyael/E164/4567;phone-context=+16135922122'/>
3o When a new resource 30 is added, the presence client 28 discovers the resource profile of the resource 30 and sends a request to add this resource to the presence agent 26.
Once added, the resource 30 can be activated by sending the appropriate request to the presence agent 26. The resource activation procedure triggers the user's current presence policies and publishes the user's availability to other presence agents 26.
A user that requests to view another user's availability is referred to herein as a watcher while the user being watched is referred to as a presentity. These definitions conform to the definitions used by the IETF IMPP model discussed above. A
watcher issues a subscription request to the presence server 22 in order to determine the availability of a presentity. The subscription request includes both the presentity's and the watcher's identity as well as a presentity role discussed in greater detail in applicant's co-pending application filed on the same day as this application and entitled "Role-Based Presence Enabled Service for Communication System". An exemplary XML
description of the subscription request or "subscribe" message is included below. It will be understood that messages in the system 20 are referred to as events of particular types.
Thus, the subscribe message is an event of type "subscribe".
<event type=subscribe originator=watcher@domain.com receiver=presentity@domain.com role=role />
After issuing a subscribe message, the watcher receives one of the following two replies.
Positive Reply Negative Rep <reply <reply event=subscribe event=subscribe from~resentity.~c~domain.com from=preseritlty@domairi.COm to=watcher@domain.com to=watcher a(~.domain.com value=success value=failed role=role role=role key=key/> reason=string/
These replies include "role" and "key" tags. The role tag is used to define the role that the presentity must be in, in order for the watcher to receive a notification of the presentity's availability. The key tag is used as a mechanism for identifying the appropriate presentity's availability for a particular subscription request.
A "notify" event is used for notification of a presentity's availability. The notify event is summarized below.
<event type=notify /* Event type */
originator=key /* Originator identified using key value */
value=yes ~ no ~ cancel /* Presentity's availability */
status=status> /* Presentity's status */
<resource_profile id='id' service url='service url'/>/* List of media service URLs*/
<resource-profile id='id' service url='service url'/>
<resource-profile id='id' service url='service url'/>
</event>
The notify event is posted if the user's presence policies for notification are triggered positively. A user's notification presence policies are triggered by changes in the user's state, location, and activation a resource. It will be understood that three availability status values are available, including "yes" for available, "no" for unavailable, or "cancel"
for the cancellation of the subscription request. The contact information for the presentity is represented using a service url. For the present embodiment, the service url is the URL
service scheme as defined by the IETF Service Locator Protocol (SLP), as dicussed in "Service Location Protocol for Enterprise Networks", J. Kempf and P. St.
Pierre, 1999, and further disclosed in the IETF document CPIM Presence Information Data Format (CPIM Presence Information Data Format <draft-ietf impp-cpim-pidf OO.txt>).
Those of skill in the art will understand the SLP service scheme and thus, only an overview is presented herein. The SLP service scheme defines a service URL as follows:
service url = "service:" service-type ":" service-access-info"
The service-type allows for the specification of service abstract types and particular recognized URL scheme names like http, ftp, telnet, etc. Some examples of this include "service:lpr:", "service:http:", "service:ftp:", "service:chat:".
Service types can utilize a generic service name as well as the specific service name to help the user understand the URL. For example, the generic service type "printer" can be used to represent a series of protocols that relate to communication with a printer.
The service in this case can be specified using "service:printer:lpr".
The service-access-info describes how the associated service is to be accessed.
This includes information regarding how a user is to be contacted. Service access information consists of the following format:
service-access-info = "/" address-family '/" address-spec [ "/" [url-path]
[";" attribute-list]]
The address-family indicates the network layer. For example "//" indicates an IP
address. The address specification is the address used for communication with the presentity. A url-path is protocol-specific and specifies details regarding the manner of accessing the service. Similar to the attributes, this is an optional item.
Attributes are specified in the following manner: attribute-id "--" value.
The following is a set of examples of typical IP-based service types that a presentity projects to watchers.
service:IM:ICQ//[host:port)/uin@icq.aol.com;version=1.2 to service:chat:IRC//betty_roland@kanata.mitel.com;version=2.3 service:http//webset2100@mitel.com;version=1.0 A non-IP protocol can also be specified for a service such as a telephony service using the SLP format (e.g. a telephony service based on the IETF RFC2806 report on 15 URLs for Telephone Calls). The phone context allows a presence client to determine how to make a call based on the client's location context. The example provided below shows a particular example of a phone number 4567. This phone number is a local number and therefore is only available if the user is the 16135922122 number code:
serviceaelephonyael/E164/4567;phone-context=+16135922122 Using SLP, these services are defined using a service template and are registered with the Internet Assigned Numbers Authority (IANA) to represent the service media type.
Launching 3'a Party Communication Applications With reference to Figure 2, after the availability information is projected, the communications contact information can be used by the presence clients 28 for establishing the communications path. Thus, the projection of availability (POA) can be 3o de-coupled from control of communications (COC) information. The presence service on the presence server 22 is operable to manage a user's availability and willingness to communicate while control of communications is managed by the communication services 32.
The service contact information in the availability message provides the link between the presence server 22 and communication services 32. The presence client 28 initiates the communication in one of two ways. The communication is initiated using a known interface protocol to the communication services 32 or the presence client 28 launches the communication application using a known set of parameters if no interface protocol is provided. Thus, the use of third party communication applications that can not be integrated with a presence client 28 is enabled.
Using both of these approaches, the presence client 28 employs a "mapping"
that 1o allows the presence client 28 to launch the appropriate helper application and/or objects, as described in greater detail below. This includes performing two checks prior to displaying the contact information of the presentity to the user. These checks include checking the service lookup table in order to determine if it supports the particular communication service and determining if the presentity's domain information in the 15 service url is accessible from the user's domain. The check to determine if presentity's contact address is accessible is based on the address-family. For an IP domain name for example, the presence client can check the domain name server (DNS) to ensure that the domain name can be mapped to an IP address. For E164 telephony addresses, this is done by using the phone-context argument that specifies the context that the telephony address 2o is valid for.
For example, when a client receives a serviceaelephoneael contact from a presence notification event it checks to see if it supports that particular service. An example of an object that supports the telephone service is presented below.
25 /**
* Simple desktop telephone service component for a Mitel ICP client.
*/
public class E164TeIService implements Runnable {
private String resource_profile = null;
private String serviceURL = null;
private String resource id = null;
private Thread phone_monitor = null;
private ServerSocket socket = null;
private boolean alive = false;
private Boolean active = false;
private BasicClient client = null;
to This basic E164TelService service class also needs to implement an instantiation method and connect method. An example of these are presented below.
/**
* DesktopClient constructor.
*/
public TelephonyResource(String serviceURL, String resource_id, BasicClient client) {
setServiceURL(serviceURL);
setResourceld(resource id);
this.client = client;
/** Connect: This particular client uses MiTAI connections **/
public void connect(String serviceURL) throws UnknownHostException, IOException {
MiTAIConnection connection = new MiTAIConnection(getMitaiHost(), getMitaiSocketQ, Integer.parselnt(getMyExtension()));
connection.makeCall(Integer.parselnt(getExtension(serviceURL)));
The service look-up table is similar to the look-up table used for Web browsers. A
relationship file specifies a mapping between the contact service URL and the application that can service that URL. The service-access-info component of the service URL is specified by the service look-up table and an optional url-path is not required. The following is an exemplary format for the service look-up table.
table-service-access-info comm-interface table-service-access-info = "service:" service-type ":" "/" address-family '/"comm-interface = protocol-API ~ executable-file 3o protocol-API = Any alphanumeric name executable-file = Any alphanumeric name + ".exe"
For the telephony example above the entry in the lookup table would appear in the following manner.
3s serviceaelephonyael/E164/ E164TeIService The example above was particular to the case where a protocol API is available. In some situations a communication client can be launched for the user.
Infomation regarding which client application to launch is required for communication using an AOL
40 IM client, for example. This information is specified in the lookup table by referencing an executable rather than a module. For example:
service:chat:IRC//kanata.mitel.com IRCChat.exe service:IM:ICQ//uin@icq.aol.comAOL.exe tt The first example shown demonstrated the specification of using the Mitel MiTAI
APIs to service the tel protocol by the presence client 28. The final look up table examples show that the ICQ service is better managed using an executable file named "AOL.exe".
Thus, in this example, the presence client launches that particular application with the address contact information as a parameter.
A more complete understanding of the invention can be obtained by reference to the examples of Figures 3 and 4, which show uses of the system for making a presence server aware of communication services. These examples are provided solely for 1o purposes of illustration and are not intended to limit the scope of the invention.
Referring to Figure 3, several users are shown for the purpose of setting up a conference call and these users desire access to other communication services in an ad hoc fashion. Automatic registration of the users' portable computers 34 is performed by 15 creating a personal area network 36 with a base station 38 that acts as a telephone conference unit.
In operation, the users first register on to the presence service running on the presence server that is accessible to all the members of the conference call.
The procedure 20 of registering creates presence agents and sets the user profile that includes contact service information. Typical contact URLs that are shared among the members of the conference call allow them to commence chat, presentation sharing, and/or video sessions among themselves.
25 Reference is now made to Figure 4, which shows an application of the invention to a retail environment having a number of experts. This example leverages the use of roles for finding experts that is discussed in greater detail in applicant's co-pending application filed on the same day as this application and entitled "Role-Based Presence Enabled Service for Communication System". An expert registers with the presence service on the 3o presence server 22 for a particular role that reflects the expert's area of expertise. Through this action he/she thereby becomes available to potential customers in a retail store via multimedia communication devices 40, such as a Mitel~ WebsetTMdevice. Typical service URLs that can be proj ected to the Webset device allow for local telephony communications and sharing of product images.
Variations and modifications of the invention are possible. For example, All such modifications and variations are within the sphere and scope of the present invention as defined by the appended claims.
services Field of Invention The present invention relates to communication systems and more particularly to a system for facilitating communication using separate presence and communication services.
to Bacl~ground of the InventiQ~
Presence services are primarily used for providing "availability" information of one user to another user of a system. This "availability" information includes an indication of desire and availability or willingness of the user to engage in immediate 15 communication. In order to achieve immediate communication a Presence Service is used to convey contact information to a user's presence client and the presence client is required to use that information to determine how to connect the users. This is particularly difficult when the communication services are developed by a third party vendor.
Communication services include any application that creates a communication path 2o between two or more parties. Examples of such services include telephone voice connections, Instant Messaging, chat, video conferencing, and sharing of presentations.
Existing Presence, or Instant Messaging (IM), services rely on a fixed and a built-in set of communication connection aids. For example, in order to enable communication 25 via instant messaging services such as MSN and AOL, the communication service is normally tightly coupled with the presence service. These communication services are developed by the same vendor and usually pass through the IM server.
The prior art suffers inherent disadvantages because they are "closed"
systems.
3o There is no flexible way to add other telephony or communication services to these systems. For example, the existing Instant Messaging systems cannot add a non-IP phone call set via third party voice products. The communication connections of these systems are hardwired and limited. While this may be suitable for IM chat style of communication services, it is not suitable for other communication services, for example, existing telephony services.
Several standard bodies are attempting to define how contact information is conveyed with a user's availability in a presence framework. Of particular interest is the IETF Instant Message and Presence Protocol (IMPP) set forth in "A Model for Presence and Instant Messaging", M. Day, J. Rosenberg, and H. Sugano, IETF RFC 2778, February 2000. Two further IETF documents discuss the Common Profile for Instant Messaging (CPIM). These two documents are the Common Presence and Instant Messaging:
Message Format document (Common Presence and Instant Messaging: Message Format <draft-ietf impp-cpim-msgfint-03.txt>) and the CPIM Presence Information Data Format (CPIM Presence Information Data Format <draft-ietf impp-cpim-pidf OO.txt>).
The Common Presence and Instant Messaging: Message Format document defines a mime content-type 'message/cpim' object which is a multipart entity. This document defines the structure of an IM message specifying mandatory fields such as "From:", "To:", "Date:", "Subject:", etc. The second document, CPIM Presence Information Data, defines the actual contact information that a presence client receives in order to enable a communication session between two users of a presence service. This document does not 2o discuss how a presence client uses contact information for launching third party communication applications.
There is no flexible way to enhance any existing Presence (or Availability) Service to handle communication connection via third party communication products.
Summarv of the Invention In accordance with the present invention, a system is provided for facilitating communication through separation between the presence and communication components.
3o The system is based on the exchange of availability messages that are not based on the mime format, and which contain information for proper presence service functioning.
Preferably, the system adopts the SLP service definition format and provides a method for a presence client to use contact information for launching third party communication applications.
Therefore, in accordance with the present invention, there is provided an approach and protocol to allow a Presence service to employ third party communication services to handle communication connection after a user's availability is established.
Advantageously, the present invention enables a Presence Service to deploy any number of communication mediums to create a communication path, including, for example, different Instant Messaging providers to send instant messages.
to Brief Desc~tion o the Drawing The present invention will be described in detail with reference to the accompanying drawings, in which like numerals denote like parts, and in which:
15 Figure 1 is a block diagram of a communication system according an embodiment of the present invention;
Figure 2 is a diagram showing separation of Projection of Availability (POA) information from Control of Communications (COC) information according to the present 20 invention;
Figure 3 is a representation of an application of the invention for facilitating ad hoc collaboration; and 25 Figure 4 is a representation of another application of the invention to contacting experts in a retail environment.
Detailed Descr~tion 3o A presence service generally offers two types of information, including projection of availability and communication contact information. Projection of availability includes the user's availability information and is an indication of the person's desire or willingness for communication. The availability information is projected, or conveyed, to other users.
A user appears available if that user is willing to communicate. Otherwise, the user appears unavailable.
Communication contact information includes information used for connecting with a user, such as how, where or by what means a user is available for communication. The contact information describes different communication service types on which the user is available at that time. Such communication types include telephony, Instant Messaging, chat, video streaming, etc.
to The following is an example of how a presence client registers and receives availability information. This example is provided in order to give a better understanding of the mechanism by which the presence service projects a user's availability and is provided solely for the purpose of illustration. Refernng to Figure l, a presence system according to an embodiment of the present invention is indicated generally by the numeral 20. The presence system includes a presence server 22 which runs the presence service which includes a directory service 24 and a presence agent 26, a presence client 28 and resources 30, as will be described in more detail below.
The presence server 22 is a server that allows users to publish their availability to 2o communicate to other users. The presence service on the presence server 22 includes a directory service 24 and a presence agent 26. A user registration procedure is targeted primarily to the directory service 24, while a user log-in procedure is performed on the presence agent 26. Procedures such as user registration and user log-in are two distinct operations.
The directory service 24 is static data storage for storing a data record in association with each user. The data record includes static information about the user including, for example, name, ID, password, address, etc. The directory service 24 allows authorized access to the system from applications other than the presence service on the 3o presence server 22.
The presence agent 26 is an entity within the presence server 22 that is associated with one individual user. The presence agent 26 is responsible for storage and management of user defined presence policies, and a user profile. The presence policies are used to determine the acceptance of "Subscription" requests from other presence agents that want to view the availability of the individual user and to control when availability notifications are to be sent to those presence agents already subscribed. It maintains contact and user state information that is projected to those users subscribed to the individual user's presence. Communication between the user and presence agents 26 is enabled via presence clients 28.
The presence client 28 is a platform specific software entity that resides on an individual device and operates as a user interface to the presence server 22.
There can 1o exist several presence clients for an individual user. The presence client 28 facilitates communication between the user and the associated presence agent 26. This communication includes, for example, subscription and notification policies, resource contact information, user role, relationship, and buddy list management, as discussed in greater detail with reference to applicant's copending application filed on the same day as 15 this application and entitled "Architecture and Implementation for Control of Context Aware Call Processing with Local Feature Definition". The login procedure is used to authenticate a client in order for the client to obtain permission for such communication.
A resource 30 is an entity that represents a communication identification and 2o communication service. A resource can be activated/deactivated, added, removed or modified. The system 20 generally includes more than one resource 30 and each resource 30 has an associated resource profile. The resource profile includes a resource identification, an indication of whether or nor the resource is active and a communication address. An exemplary resource profile for a desktop phone is listed below.
25 <resource-profile id='desktop phone' active=' inactive' service url= 'serviceaelephonyael/E164/4567;phone-context=+16135922122'/>
3o When a new resource 30 is added, the presence client 28 discovers the resource profile of the resource 30 and sends a request to add this resource to the presence agent 26.
Once added, the resource 30 can be activated by sending the appropriate request to the presence agent 26. The resource activation procedure triggers the user's current presence policies and publishes the user's availability to other presence agents 26.
A user that requests to view another user's availability is referred to herein as a watcher while the user being watched is referred to as a presentity. These definitions conform to the definitions used by the IETF IMPP model discussed above. A
watcher issues a subscription request to the presence server 22 in order to determine the availability of a presentity. The subscription request includes both the presentity's and the watcher's identity as well as a presentity role discussed in greater detail in applicant's co-pending application filed on the same day as this application and entitled "Role-Based Presence Enabled Service for Communication System". An exemplary XML
description of the subscription request or "subscribe" message is included below. It will be understood that messages in the system 20 are referred to as events of particular types.
Thus, the subscribe message is an event of type "subscribe".
<event type=subscribe originator=watcher@domain.com receiver=presentity@domain.com role=role />
After issuing a subscribe message, the watcher receives one of the following two replies.
Positive Reply Negative Rep <reply <reply event=subscribe event=subscribe from~resentity.~c~domain.com from=preseritlty@domairi.COm to=watcher@domain.com to=watcher a(~.domain.com value=success value=failed role=role role=role key=key/> reason=string/
These replies include "role" and "key" tags. The role tag is used to define the role that the presentity must be in, in order for the watcher to receive a notification of the presentity's availability. The key tag is used as a mechanism for identifying the appropriate presentity's availability for a particular subscription request.
A "notify" event is used for notification of a presentity's availability. The notify event is summarized below.
<event type=notify /* Event type */
originator=key /* Originator identified using key value */
value=yes ~ no ~ cancel /* Presentity's availability */
status=status> /* Presentity's status */
<resource_profile id='id' service url='service url'/>/* List of media service URLs*/
<resource-profile id='id' service url='service url'/>
<resource-profile id='id' service url='service url'/>
</event>
The notify event is posted if the user's presence policies for notification are triggered positively. A user's notification presence policies are triggered by changes in the user's state, location, and activation a resource. It will be understood that three availability status values are available, including "yes" for available, "no" for unavailable, or "cancel"
for the cancellation of the subscription request. The contact information for the presentity is represented using a service url. For the present embodiment, the service url is the URL
service scheme as defined by the IETF Service Locator Protocol (SLP), as dicussed in "Service Location Protocol for Enterprise Networks", J. Kempf and P. St.
Pierre, 1999, and further disclosed in the IETF document CPIM Presence Information Data Format (CPIM Presence Information Data Format <draft-ietf impp-cpim-pidf OO.txt>).
Those of skill in the art will understand the SLP service scheme and thus, only an overview is presented herein. The SLP service scheme defines a service URL as follows:
service url = "service:" service-type ":" service-access-info"
The service-type allows for the specification of service abstract types and particular recognized URL scheme names like http, ftp, telnet, etc. Some examples of this include "service:lpr:", "service:http:", "service:ftp:", "service:chat:".
Service types can utilize a generic service name as well as the specific service name to help the user understand the URL. For example, the generic service type "printer" can be used to represent a series of protocols that relate to communication with a printer.
The service in this case can be specified using "service:printer:lpr".
The service-access-info describes how the associated service is to be accessed.
This includes information regarding how a user is to be contacted. Service access information consists of the following format:
service-access-info = "/" address-family '/" address-spec [ "/" [url-path]
[";" attribute-list]]
The address-family indicates the network layer. For example "//" indicates an IP
address. The address specification is the address used for communication with the presentity. A url-path is protocol-specific and specifies details regarding the manner of accessing the service. Similar to the attributes, this is an optional item.
Attributes are specified in the following manner: attribute-id "--" value.
The following is a set of examples of typical IP-based service types that a presentity projects to watchers.
service:IM:ICQ//[host:port)/uin@icq.aol.com;version=1.2 to service:chat:IRC//betty_roland@kanata.mitel.com;version=2.3 service:http//webset2100@mitel.com;version=1.0 A non-IP protocol can also be specified for a service such as a telephony service using the SLP format (e.g. a telephony service based on the IETF RFC2806 report on 15 URLs for Telephone Calls). The phone context allows a presence client to determine how to make a call based on the client's location context. The example provided below shows a particular example of a phone number 4567. This phone number is a local number and therefore is only available if the user is the 16135922122 number code:
serviceaelephonyael/E164/4567;phone-context=+16135922122 Using SLP, these services are defined using a service template and are registered with the Internet Assigned Numbers Authority (IANA) to represent the service media type.
Launching 3'a Party Communication Applications With reference to Figure 2, after the availability information is projected, the communications contact information can be used by the presence clients 28 for establishing the communications path. Thus, the projection of availability (POA) can be 3o de-coupled from control of communications (COC) information. The presence service on the presence server 22 is operable to manage a user's availability and willingness to communicate while control of communications is managed by the communication services 32.
The service contact information in the availability message provides the link between the presence server 22 and communication services 32. The presence client 28 initiates the communication in one of two ways. The communication is initiated using a known interface protocol to the communication services 32 or the presence client 28 launches the communication application using a known set of parameters if no interface protocol is provided. Thus, the use of third party communication applications that can not be integrated with a presence client 28 is enabled.
Using both of these approaches, the presence client 28 employs a "mapping"
that 1o allows the presence client 28 to launch the appropriate helper application and/or objects, as described in greater detail below. This includes performing two checks prior to displaying the contact information of the presentity to the user. These checks include checking the service lookup table in order to determine if it supports the particular communication service and determining if the presentity's domain information in the 15 service url is accessible from the user's domain. The check to determine if presentity's contact address is accessible is based on the address-family. For an IP domain name for example, the presence client can check the domain name server (DNS) to ensure that the domain name can be mapped to an IP address. For E164 telephony addresses, this is done by using the phone-context argument that specifies the context that the telephony address 2o is valid for.
For example, when a client receives a serviceaelephoneael contact from a presence notification event it checks to see if it supports that particular service. An example of an object that supports the telephone service is presented below.
25 /**
* Simple desktop telephone service component for a Mitel ICP client.
*/
public class E164TeIService implements Runnable {
private String resource_profile = null;
private String serviceURL = null;
private String resource id = null;
private Thread phone_monitor = null;
private ServerSocket socket = null;
private boolean alive = false;
private Boolean active = false;
private BasicClient client = null;
to This basic E164TelService service class also needs to implement an instantiation method and connect method. An example of these are presented below.
/**
* DesktopClient constructor.
*/
public TelephonyResource(String serviceURL, String resource_id, BasicClient client) {
setServiceURL(serviceURL);
setResourceld(resource id);
this.client = client;
/** Connect: This particular client uses MiTAI connections **/
public void connect(String serviceURL) throws UnknownHostException, IOException {
MiTAIConnection connection = new MiTAIConnection(getMitaiHost(), getMitaiSocketQ, Integer.parselnt(getMyExtension()));
connection.makeCall(Integer.parselnt(getExtension(serviceURL)));
The service look-up table is similar to the look-up table used for Web browsers. A
relationship file specifies a mapping between the contact service URL and the application that can service that URL. The service-access-info component of the service URL is specified by the service look-up table and an optional url-path is not required. The following is an exemplary format for the service look-up table.
table-service-access-info comm-interface table-service-access-info = "service:" service-type ":" "/" address-family '/"comm-interface = protocol-API ~ executable-file 3o protocol-API = Any alphanumeric name executable-file = Any alphanumeric name + ".exe"
For the telephony example above the entry in the lookup table would appear in the following manner.
3s serviceaelephonyael/E164/ E164TeIService The example above was particular to the case where a protocol API is available. In some situations a communication client can be launched for the user.
Infomation regarding which client application to launch is required for communication using an AOL
40 IM client, for example. This information is specified in the lookup table by referencing an executable rather than a module. For example:
service:chat:IRC//kanata.mitel.com IRCChat.exe service:IM:ICQ//uin@icq.aol.comAOL.exe tt The first example shown demonstrated the specification of using the Mitel MiTAI
APIs to service the tel protocol by the presence client 28. The final look up table examples show that the ICQ service is better managed using an executable file named "AOL.exe".
Thus, in this example, the presence client launches that particular application with the address contact information as a parameter.
A more complete understanding of the invention can be obtained by reference to the examples of Figures 3 and 4, which show uses of the system for making a presence server aware of communication services. These examples are provided solely for 1o purposes of illustration and are not intended to limit the scope of the invention.
Referring to Figure 3, several users are shown for the purpose of setting up a conference call and these users desire access to other communication services in an ad hoc fashion. Automatic registration of the users' portable computers 34 is performed by 15 creating a personal area network 36 with a base station 38 that acts as a telephone conference unit.
In operation, the users first register on to the presence service running on the presence server that is accessible to all the members of the conference call.
The procedure 20 of registering creates presence agents and sets the user profile that includes contact service information. Typical contact URLs that are shared among the members of the conference call allow them to commence chat, presentation sharing, and/or video sessions among themselves.
25 Reference is now made to Figure 4, which shows an application of the invention to a retail environment having a number of experts. This example leverages the use of roles for finding experts that is discussed in greater detail in applicant's co-pending application filed on the same day as this application and entitled "Role-Based Presence Enabled Service for Communication System". An expert registers with the presence service on the 3o presence server 22 for a particular role that reflects the expert's area of expertise. Through this action he/she thereby becomes available to potential customers in a retail store via multimedia communication devices 40, such as a Mitel~ WebsetTMdevice. Typical service URLs that can be proj ected to the Webset device allow for local telephony communications and sharing of product images.
Variations and modifications of the invention are possible. For example, All such modifications and variations are within the sphere and scope of the present invention as defined by the appended claims.
Claims (15)
1. A method for facilitating communication with a user, the method comprising the steps of:
receiving contact information for said user, from a presence service;
checking to determine if a particular communication service is supported by said user;
checking to determine if the contact address of the user is accessible;
launching at least one of an appropriate helper application and objects; and initiating communication with the user through the particular communication service.
receiving contact information for said user, from a presence service;
checking to determine if a particular communication service is supported by said user;
checking to determine if the contact address of the user is accessible;
launching at least one of an appropriate helper application and objects; and initiating communication with the user through the particular communication service.
2. A method as claimed in claim 1, wherein said step of checking to determine if a particular communication service is supported comprises checking a service look-up table.
3. A method as claimed in claim 2, wherein said step of checking said service look- up table includes determining if domain information in the service url of the user is accessible.
4. A method as claimed in any one of claims 1 to 3, wherein said step of checking to determine if the contact address of the user is accessible is based on the address-family of the user.
5. A method as claimed in any one of claims 1 to 4 further comprising the step of receiving availability information of the user from the presence service, prior to the step of receiving contact information.
6. A method as claimed in any one of claims 1 to 5 further comprising the step of projecting availability information to the presence service, prior to the step of receiving availability information of the user.
7. A method for facilitating communication with a presentity, comprising the steps of:
projecting a subscription request to a presence service for determining the availability of the presentity;
receiving a notification message from the presence service including role and key tags for identifying a role that the presentity is in and for identifying the availability of the presentity for the subscription request;
checking to determine if a particular communication service is supported by the presentity;
checking network accessibility of the presentity;
launching at least one of an appropriate helper application and objects; and initiating communication with the presentity through the particular communication service.
projecting a subscription request to a presence service for determining the availability of the presentity;
receiving a notification message from the presence service including role and key tags for identifying a role that the presentity is in and for identifying the availability of the presentity for the subscription request;
checking to determine if a particular communication service is supported by the presentity;
checking network accessibility of the presentity;
launching at least one of an appropriate helper application and objects; and initiating communication with the presentity through the particular communication service.
8. A method as claimed in claim 7, wherein said step of checking to determine if a particular communication service is supported comprises checking a service look-up table.
9. A method as claimed in claim 8, wherein said step of checking said service look-up table includes determining if domain information of the presentity is accessible.
10. A method as claimed in any one of claims 7 to 9, wherein the step of checking to determine if the contact address of the presentity is accessible is based on the address-family of the user.
11. A method as claimed in any one of claims 7 to 10 further comprising the step of projecting availability information to the presence service, prior to the step of projecting a subscription request.
12. A system for facilitating communication with a presentity, comprising:
a presentity presence client;
a watcher presence client for projecting a subscription request;
a presence server connected to the presentity presence client and the watcher presence client, said presence server for receiving the subscription request and for replying to said watcher presence client to identify the availability of the presentity for the subscription request; and a communication service separate from said presence server and connected to said watcher presence client and said presentity presence client.
wherein said watcher presence client is operable to launch at least one of an appropriate helper application and objects and to initiate communication with the presentity through the particular communication service.
a presentity presence client;
a watcher presence client for projecting a subscription request;
a presence server connected to the presentity presence client and the watcher presence client, said presence server for receiving the subscription request and for replying to said watcher presence client to identify the availability of the presentity for the subscription request; and a communication service separate from said presence server and connected to said watcher presence client and said presentity presence client.
wherein said watcher presence client is operable to launch at least one of an appropriate helper application and objects and to initiate communication with the presentity through the particular communication service.
13. A system for initiating communication as claimed in claim 12 wherein said presentity comprises a presentity resource.
14. A system for initialing communication as claimed in claim 12 or claim 13, wherein said presence server comprises a directory service for storing a data record in association with a plurality of users.
15. A system for initiating communication as claimed in claim 14, wherein said presence server further comprises a user agent for maintaining information about the availability of the presentity and the means by which the presentity is available.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0218711.0 | 2002-08-12 | ||
| GBGB0218711.0A GB0218711D0 (en) | 2002-08-12 | 2002-08-12 | System and method for facilitating communication using presence and communication services |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2436061A1 CA2436061A1 (en) | 2004-02-12 |
| CA2436061C true CA2436061C (en) | 2007-07-17 |
Family
ID=9942152
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002436061A Expired - Lifetime CA2436061C (en) | 2002-08-12 | 2003-07-24 | System and method for facilitating communication using presence and communication system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7412522B2 (en) |
| EP (1) | EP1396987A3 (en) |
| CA (1) | CA2436061C (en) |
| GB (1) | GB0218711D0 (en) |
Families Citing this family (78)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8644475B1 (en) | 2001-10-16 | 2014-02-04 | Rockstar Consortium Us Lp | Telephony usage derived presence information |
| US7239981B2 (en) * | 2002-07-26 | 2007-07-03 | Arbitron Inc. | Systems and methods for gathering audience measurement data |
| US8392609B2 (en) | 2002-09-17 | 2013-03-05 | Apple Inc. | Proximity detection for media proxies |
| US7555108B2 (en) * | 2002-10-01 | 2009-06-30 | Nortel Networks Limited | Presence information for telephony users |
| US7249161B2 (en) | 2002-12-27 | 2007-07-24 | Nokia Corporation | Method and system for facilitating instant messaging transactions between disparate service providers |
| AU2003234420A1 (en) | 2002-12-27 | 2004-07-29 | Nielsen Media Research, Inc. | Methods and apparatus for transcoding metadata |
| 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 |
| US8060459B2 (en) | 2003-08-01 | 2011-11-15 | Mitel Networks Corporation | Method for generating prospective availability data |
| US9118574B1 (en) | 2003-11-26 | 2015-08-25 | RPX Clearinghouse, LLC | Presence reporting using wireless messaging |
| US7647375B1 (en) * | 2003-12-22 | 2010-01-12 | Aol Llc | Enabling mapping identification of online identities between different messaging services |
| US8229454B1 (en) | 2004-03-22 | 2012-07-24 | Avaya Inc. | Personal location information management |
| JP4352959B2 (en) * | 2004-03-25 | 2009-10-28 | 日本電気株式会社 | Group communication system based on presence information and client device |
| EP1585281A1 (en) * | 2004-04-07 | 2005-10-12 | Siemens Aktiengesellschaft | A method and arrangements for dynamically reconfiguring a presence enabled application framework within a communication network |
| 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 |
| DE102004047689A1 (en) | 2004-09-30 | 2006-04-13 | Siemens Ag | Method for realizing a presence service and presence system |
| US8280957B2 (en) * | 2004-12-23 | 2012-10-02 | Alcatel Lucent | Presence system and method for event-driven presence subscription |
| 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 |
| EP1713218A1 (en) * | 2005-04-15 | 2006-10-18 | France Telecom | Communications system and method |
| US8781081B2 (en) * | 2005-04-21 | 2014-07-15 | At&T Intellectual Property I, L.P. | Presence management system |
| US8036140B2 (en) | 2005-04-22 | 2011-10-11 | Microsoft Corporation | Application programming interface for inviting participants in a serverless peer to peer network |
| US7571228B2 (en) * | 2005-04-22 | 2009-08-04 | Microsoft Corporation | Contact management in a serverless peer-to-peer system |
| US7752253B2 (en) * | 2005-04-25 | 2010-07-06 | Microsoft Corporation | Collaborative invitation system and method |
| US7617281B2 (en) * | 2005-04-25 | 2009-11-10 | Microsoft Corporation | System and method for collaboration with serverless presence |
| US20060248185A1 (en) * | 2005-04-29 | 2006-11-02 | Morris Robert P | System and method for utilizing a presence service to advertise activity availability |
| US7567553B2 (en) * | 2005-06-10 | 2009-07-28 | Swift Creek Systems, Llc | Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol |
| US20070005725A1 (en) * | 2005-06-30 | 2007-01-04 | Morris Robert P | Method and apparatus for browsing network resources using an asynchronous communications protocol |
| US20070027915A1 (en) * | 2005-07-29 | 2007-02-01 | Morris Robert P | Method and system for processing a workflow using a publish-subscribe protocol |
| US20070043646A1 (en) * | 2005-08-22 | 2007-02-22 | Morris Robert P | Methods, systems, and computer program products for conducting a business transaction using a pub/sub protocol |
| US9053461B2 (en) * | 2005-10-07 | 2015-06-09 | Yahoo! Inc. | Instant messaging interoperability between disparate service providers |
| US20070088839A1 (en) * | 2005-10-19 | 2007-04-19 | Nortel Networks Limited | Local time related presence automation and session control |
| US9392069B2 (en) * | 2005-11-18 | 2016-07-12 | Aol Inc. | Promoting interoperability of presence-based systems through the use of ubiquitous online identities |
| US8452852B2 (en) * | 2005-12-21 | 2013-05-28 | Alcatel Lucent | System and method for providing an information service to distribute real-time information to users via a presence system |
| US7512880B2 (en) * | 2005-12-23 | 2009-03-31 | Swift Creek Systems, Llc | Method and system for presenting published information in a browser |
| US20070150441A1 (en) * | 2005-12-23 | 2007-06-28 | Morris Robert P | Methods, systems, and computer program products for associating policies with tuples using a pub/sub protocol |
| US20070168420A1 (en) * | 2005-12-30 | 2007-07-19 | Morris Robert P | Method and apparatus for providing customized subscription data |
| US7587450B2 (en) * | 2006-02-01 | 2009-09-08 | Swift Creek Systems, Llc | HTTP publish/subscribe communication protocol |
| US8254537B2 (en) * | 2006-02-03 | 2012-08-28 | Motorola Mobility Llc | Method and apparatus for updating a presence attribute |
| US8005073B2 (en) * | 2006-02-13 | 2011-08-23 | Nokia Corporation | Representing network availability status information in presence information |
| CN1863175B (en) * | 2006-02-25 | 2010-08-25 | 华为技术有限公司 | Presence service access apparatus, presence service system and method for issuing and obtaining presence information |
| US20070208702A1 (en) * | 2006-03-02 | 2007-09-06 | Morris Robert P | Method and system for delivering published information associated with a tuple using a pub/sub protocol |
| US9940626B2 (en) | 2006-06-23 | 2018-04-10 | At&T Intellectual Property I, L.P. | Methods and apparatus to provide an electronic agent |
| US20080005294A1 (en) * | 2006-06-30 | 2008-01-03 | Morris Robert P | Method and system for exchanging messages using a presence service |
| US20080120337A1 (en) * | 2006-11-21 | 2008-05-22 | Fry Jared S | Method And System For Performing Data Operations Using A Publish/Subscribe Service |
| US20080126475A1 (en) * | 2006-11-29 | 2008-05-29 | Morris Robert P | Method And System For Providing Supplemental Information In A Presence Client-Based Service Message |
| 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 |
| US20080147799A1 (en) * | 2006-12-13 | 2008-06-19 | Morris Robert P | Methods, Systems, And Computer Program Products For Providing Access To A Secure Service Via A Link In A Message |
| 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 |
| US8301782B2 (en) * | 2007-03-02 | 2012-10-30 | Yahoo! Inc. | Stateless gateways having remote dialog store |
| US7769951B2 (en) * | 2007-04-10 | 2010-08-03 | Yahoo! Inc. | Intelligent caching of user data for real time communications |
| US20090037582A1 (en) * | 2007-07-31 | 2009-02-05 | Morris Robert P | Method And System For Managing Access To A Resource Over A Network Using Status Information Of A Principal |
| US20090037588A1 (en) * | 2007-07-31 | 2009-02-05 | Morris Robert P | Method And System For Providing Status Information Of At Least Two Related Principals |
| US20090182821A1 (en) * | 2008-01-15 | 2009-07-16 | Research In Motion Limited | Apparatus and associated method for providing network based address book and sharing and synchornizing address book information at multiple communication devices |
| US20090307374A1 (en) * | 2008-06-05 | 2009-12-10 | Morris Robert P | Method And System For Providing A Subscription To A Tuple Based On A Schema Associated With The Tuple |
| 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 |
| 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 |
| US9667365B2 (en) | 2008-10-24 | 2017-05-30 | The Nielsen Company (Us), Llc | Methods and apparatus to perform audio watermarking and watermark detection and extraction |
| US8121830B2 (en) | 2008-10-24 | 2012-02-21 | The Nielsen Company (Us), Llc | Methods and apparatus to extract data encoded in media content |
| US8359205B2 (en) | 2008-10-24 | 2013-01-22 | The Nielsen Company (Us), Llc | Methods and apparatus to perform audio watermarking and watermark detection and extraction |
| 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 |
| US8508357B2 (en) * | 2008-11-26 | 2013-08-13 | The Nielsen Company (Us), Llc | Methods and apparatus to encode and decode audio for shopper location and advertisement presentation tracking |
| US20100146101A1 (en) * | 2008-12-09 | 2010-06-10 | Morris Robert P | Method And System For Binding A Watcher Representing A Principal To A Tuple Based On A Matching Criterion |
| AU2010242814B2 (en) | 2009-05-01 | 2014-07-31 | The Nielsen Company (Us), Llc | Methods, apparatus and articles of manufacture to provide secondary content in association with primary broadcast media content |
| US9588803B2 (en) * | 2009-05-11 | 2017-03-07 | Microsoft Technology Licensing, Llc | Executing native-code applications in a browser |
| US9380356B2 (en) | 2011-04-12 | 2016-06-28 | The Nielsen Company (Us), Llc | Methods and apparatus to generate a tag for media content |
| US9210208B2 (en) | 2011-06-21 | 2015-12-08 | The Nielsen Company (Us), Llc | Monitoring streaming media content |
| US9209978B2 (en) | 2012-05-15 | 2015-12-08 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| US8751500B2 (en) | 2012-06-26 | 2014-06-10 | Google Inc. | Notification classification and display |
| US8719280B1 (en) | 2012-10-16 | 2014-05-06 | Google Inc. | Person-based information aggregation |
| US9282587B2 (en) | 2012-11-16 | 2016-03-08 | Google Technology Holdings, LLC | Method for managing notifications in a communication device |
| US9313544B2 (en) | 2013-02-14 | 2016-04-12 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| US20150039321A1 (en) | 2013-07-31 | 2015-02-05 | Arbitron Inc. | Apparatus, System and Method for Reading Codes From Digital Audio on a Processing Device |
| US9711152B2 (en) | 2013-07-31 | 2017-07-18 | The Nielsen Company (Us), Llc | Systems apparatus and methods for encoding/decoding persistent universal media codes to encoded audio |
| US9332035B2 (en) | 2013-10-10 | 2016-05-03 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| US9762965B2 (en) | 2015-05-29 | 2017-09-12 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| CA2956413A1 (en) | 2016-01-28 | 2017-07-28 | Mitel Networks Corporation | Method and system of providing context aware announcements |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6526129B1 (en) | 1997-05-02 | 2003-02-25 | Nortel Networks Limited | System and method for communication media management |
| US20020065894A1 (en) * | 1999-12-03 | 2002-05-30 | Dalal Siddhartha R. | Local presence state and user-controlled presence and message forwarding in unified instant messaging |
| US7603411B1 (en) | 1999-12-14 | 2009-10-13 | Nortel Networks Limited | Presence management system |
| AU2001240154A1 (en) | 2000-03-15 | 2001-09-24 | Telecommunication Systems, Inc. | Mobile originated internet relay chat |
| US7197565B2 (en) * | 2001-01-22 | 2007-03-27 | Sun Microsystems, Inc. | System and method of using a pipe advertisement for a peer-to-peer network entity in peer-to-peer presence detection |
| US7162474B1 (en) * | 2001-05-10 | 2007-01-09 | Nortel Networks Limited | Recipient controlled contact directories |
| US7149701B2 (en) * | 2001-11-02 | 2006-12-12 | Jerry L. Mckinney 2002 Trust | Regulatory compliance system and method |
| US7206388B2 (en) * | 2002-03-18 | 2007-04-17 | Openwave Systems Inc. | System and method for providing voice-activated presence information |
| US7139797B1 (en) * | 2002-04-10 | 2006-11-21 | Nortel Networks Limited | Presence information based on media activity |
| US7035923B1 (en) * | 2002-04-10 | 2006-04-25 | Nortel Networks Limited | Presence information specifying communication preferences |
| US7050810B2 (en) * | 2002-07-22 | 2006-05-23 | Lucent Technologies Inc. | Instant presence system for a guaranteed call connection |
| US7219153B1 (en) * | 2002-12-02 | 2007-05-15 | Cisco Technology, Inc. | Methods and apparatus for distributing content |
-
2002
- 2002-08-12 GB GBGB0218711.0A patent/GB0218711D0/en not_active Ceased
-
2003
- 2003-07-24 CA CA002436061A patent/CA2436061C/en not_active Expired - Lifetime
- 2003-08-01 US US10/631,789 patent/US7412522B2/en active Active
- 2003-08-11 EP EP03017608A patent/EP1396987A3/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| US7412522B2 (en) | 2008-08-12 |
| GB0218711D0 (en) | 2002-09-18 |
| US20040037271A1 (en) | 2004-02-26 |
| EP1396987A2 (en) | 2004-03-10 |
| EP1396987A3 (en) | 2006-10-25 |
| CA2436061A1 (en) | 2004-02-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2436061C (en) | System and method for facilitating communication using presence and communication system | |
| US6564261B1 (en) | Distributed system to intelligently establish sessions between anonymous users over various networks | |
| US7797010B1 (en) | Systems and methods for talk group distribution | |
| JP5416877B2 (en) | Existence management system, multiple access network, and processing method | |
| US7523165B2 (en) | Transmission of application information and commands using presence technology | |
| US8345843B2 (en) | Method and arrangement for handling communication requests from unknown parties | |
| JP5049438B2 (en) | Existence management system and method | |
| JP4431000B2 (en) | Method and apparatus for delivering an e-mail message with instructions indicating the presence of the sender | |
| JP4299242B2 (en) | Update presence information | |
| US7864716B1 (en) | Talk group management architecture | |
| US7738900B1 (en) | Systems and methods of group distribution for latency sensitive applications | |
| JP2004526367A (en) | Separation of Instant Messaging User and Client Identification | |
| US20060004924A1 (en) | Method and system providing support for location and service category service discovery in a SIP environment using a SIP event package, forking and AOR registration | |
| US7844294B1 (en) | Systems and methods for opt-in and opt-out talk group management | |
| KR20100136906A (en) | Pluggable contact resolution | |
| US8706090B2 (en) | Method and apparatus for delivering a voice mail message with an indication of the presence of the sender | |
| JP2014147128A (en) | Existence management system, storage medium, multiple access communication network and operation method | |
| US20060168553A1 (en) | Software development kit for real-time communication applications and system | |
| EP2294780B1 (en) | A method for masking data | |
| US20070030802A1 (en) | Enabling non real-time communication enabled devices to participate in real time communication scenarios | |
| US8239517B1 (en) | Architecture for presence based transaction tracking across multiple devices and clients | |
| Liscano | Presence and Awareness Services | |
| US7733884B1 (en) | Systems and methods for exposing functionality with strict access controls | |
| Liscano et al. | Integrating service discovery protocols with presence-based communications for ad hoc collaborative scenarios |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20230724 |