WO2005006684A1 - Dispositif et procede de traitement de donnees de presence - Google Patents

Dispositif et procede de traitement de donnees de presence Download PDF

Info

Publication number
WO2005006684A1
WO2005006684A1 PCT/FR2004/001812 FR2004001812W WO2005006684A1 WO 2005006684 A1 WO2005006684 A1 WO 2005006684A1 FR 2004001812 W FR2004001812 W FR 2004001812W WO 2005006684 A1 WO2005006684 A1 WO 2005006684A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
data
database
server
application
Prior art date
Application number
PCT/FR2004/001812
Other languages
English (en)
Inventor
Emmanuel Bertin
Christèle ROUSSEL
Stéphane Polouchkine
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2005006684A1 publication Critical patent/WO2005006684A1/fr

Links

Classifications

    • 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]
    • H04L51/043—Real-time or near real-time messaging, e.g. instant messaging [IM] using or handling presence information

Definitions

  • Presence management is an increasingly used function in connecting individuals.
  • Presence is a binary state (present, absent) indicating that a user is registered and connected to a presence management system. Being present means that, seen from the presence management system, the user is registered and connected by means of one or more terminals. Being “present” does not necessarily mean that the user can be reached. For example, the user of a switched-on mobile phone will be considered “present” by a mobile presence management system but will be unreachable in a non-covered area.
  • the reachability represents the visibility, vis-à-vis an event or a person, that a user wishes to give of his state of presence and his will to be or not to be reached, in depending on its availability. Presence becomes an important issue in the development of new communication services. Many " players in the field (publishers, mobile manufacturers, equipment manufacturers, operators, startups ...) are aware of this and are actively working on it. In addition to the work carried out on the subject in standardization bodies (OMA, Parlay, PA forum, ⁇ ETF), we are seeing more and more solutions related to presence management. Most of these solutions are strongly associated with instant messaging. Some players work more specifically on presence management as a function independent of instant messaging: DynamicSoft, Indigo, Hotsip ...
  • PresenceWorks federates presence information from instant messaging services such as AOL, MSM Messenger, Yahoo Messenger, ICQ and can then be queried by client applications.
  • Antepo is a multi-protocol platform which makes it possible to interface with XMPP or SIMPLE clients and / or servers, or even more.
  • Another device entitled "device for managing user presence information from a plurality of presence management systems" (FR-02 12471) can only be used in consultation mode. None of the existing solutions offers the possibility of unifying access to these systems for consulting and modifying presence data for the same user on several servers at the same time.
  • FR-02 12471 can only be used in consultation mode and not in client mode, that is to say that it does not make it possible to modify the presence states, to manage a list of contacts and to be notified of changes in the states of presence of the members of this list.
  • the invention relates to a device for processing the presence data of user devices, comprising: - first interface means, for access of at least one first application to said device, - means of communication with at at least one presence database, and means for managing this database, - second interface means for issuing a request to send information on changes in presence data to a second data processing device and for receiving said modification information.
  • a device for processing the presence data of user devices, comprising: - first interface means, for access of at least one first application to said device, - means of communication with at at least one presence database, and means for managing this database, - second interface means for issuing a request to send information on changes in presence data to a second data processing device and for receiving said modification information.
  • the management means of said database allow this database to be updated as a function of the data modification information received from the second data processing device, or possibly from the application itself.
  • the device according to the invention can also be connected, not only to a second data processing device, but also to a third, or to a plurality of data processing devices, each memorizing user presence data or devices or media.
  • the second interface means can then allow the transmission of a request for sending information of changes in presence data to this third, or these other, data processing devices.
  • one or more connectors allow adaptation of the protocols of the device and of the data processing devices.
  • the database management means then make it possible to store in the database the different information, coming from the different data processing devices, allowing the application or applications to view the device as a single component for managing presence.
  • the first interface means can allow access of one or more applications to said device, possibly using protocol adaptation connectors.
  • the interface to the application, or to the applications can in fact be a multimodal interface, offering several means of access and thus widening the type of applications that can use the device.
  • the interface can thus include HTTP access, and / or Web Service, and / or VXML, and / or email, and / or SMS, and / or IM, and / or SIMPLE and / or others possibly.
  • the invention also relates to a method for processing the presence data of user devices, comprising: - the reception, by at least one server device, of presence data from at least one of the user devices, - the transmission, to a second server device, of said presence data, - updating, by this second server device, as a function of the data received, of a presence database, and, possibly, - sending, to at least one application, information relating to changes in the presence data of at least one user device.
  • This method comprises, for example, the sending, by the second server to the first server, of a request to send information on changes in presence data.
  • the method according to the invention can also comprise the transmission, by the second server to the first server, of said information relating to modifications of the presence data of at least one device of a user, transmitted by a applications.
  • This method can also include updating or modifying or searching, in the database, data relating to at least one device used by at least one user, or to a characteristic of such a device.
  • FIG. 1 shows the general structure of a data processing device 10, or computer (hereinafter called server), which can be used in the context of the present invention.
  • Storage means 12 which may or may not be contained in the server 10, store data, for example in the form of a database.
  • the reference 11 symbolizes means of access to these storage means and means for managing this database.
  • the server can be connected to elements 22-1, ... 22-n of different applications, for example different computers or different servers. Each of these elements will dialogue or exchange information with the server 10 according to a specific access protocol, but mainly as "client" of this server. In particular, one or more of these applications will search for information concerning the presence or the state of presence of users.
  • Each of these users can use one or more different media (for example: landline, mobile phone, PC, communicating PDA, etc.).
  • the presence is for example a binary state indicating that a user is registered and connected.
  • Each of these elements will dialogue or exchange information with the server 10 according to a specific access protocol, but mainly as "client".
  • Each protocol is characterized for example by a structuring of the data (for example: structure of the data identifying a user), a structuring of the requests, the way in which are treated data and requests, or steps for processing data and requests, possibly how to handle certain errors, or steps for processing errors.
  • Two protocols will be different, if they differ by at least one of the above elements, that is to say if they have different data structures (for example: data structures identifying a user), and / or different structures of the requests, and / or different methods and / or different stages of data processing and / or requests, and / or different methods and / or steps of management or error handling.
  • Different users will therefore be able to dialogue, as "clients" with the server 10 according to different protocols.
  • the server 10 can also be connected to one or more elements, for example different computers or different servers, also called presence management servers, or "SGP", 24-1, ..., 24-n.
  • PMS host information for example in the form of a database, relating to the presence states of different users.
  • each user can use different media, the data concerning the presence of a media of a given user being transmitted then listed in a single SGP, that concerning another media of the same user being able to be, likewise, transmitted then listed in a single GSP, the same as the previous or another.
  • Any change in the status of the presence of a user or of a user's media is notified to the corresponding SGP, for example either by the user or the media itself, or by a third party, which may also be one of the 22-i applications.
  • These changes of state are then transmitted or notified to the server 10, which thus updates the database 12.
  • the server 10 when it is an application 22-i which notifies a change of state, it does so d first to the server 10, which then retransmits the information to the corresponding SGP which it identifies with the information contained in the database 12.
  • the server 10 will therefore dialogue or exchange information with each of the SGP 24-i but it acts mainly as a client live from these.
  • it stores, for example in the database 12, the identification data of the SGP (for example: address of the server which hosts it) to be reached or interrogated for a given medium of a given user and possibly the protocol used to communicate with this SGP.
  • FIG. 2 schematically represents, as a block, the various components of a data processing apparatus 40.
  • a microprocessor 50 is connected, by a bus 52, to a set of RAM memories 54 for storing data, and to a ROM memory 56 in which program instructions can be stored.
  • This system can also include a display device 58, or screen and peripheral means such as keyboard or mouse.
  • the reference 64 designates means for interfacing with a network, for example of the modem type. According to another example, it can be an Ethernet port associated with one or more network card (s).
  • the server 10 can also be one (or more) specific port (s) to support one or more particular protocol (s).
  • An embodiment of the invention will be described, in conjunction with FIG. 3, in which the references 100 - 157 denote software elements hosted on the server 10. More precisely, the references 132 - 136 represent three connectors for SGP, and references 151 - 157 six application connectors.
  • This embodiment therefore comprises a central module 100, as well as, in addition, an application programming interface, or API 130, on the side of the SGP systems 24-1, 24-2, 24-3 for managing presence, and an application programming interface, or API 140 on the applications side 22-i.
  • the central module 100 stores, in the form of a database
  • the information associated with the users from notifications transmitted by one or more SGPs through the API SGP 130, or possibly transmitted by the applications 22-i through the API 140.
  • This information includes, for example, the presence state of a user or one or more of its media and, optionally, the contact lists and associated presence states, or also data or technical characteristics relating to the devices or media. used by users.
  • a database management system is implemented, preferably designed as openly as possible, that is to say having one or more of the following characteristics: - the module 100 can interoperate with different types of
  • the database management system not only makes it possible to identify and update the state of presence of a media, but also to automatically notify some of the applications 22-i, which have specifically required the 'sending, or subscribing to the sending, of such notifications, when the state of presence of a given media or user changes.
  • the user applications can be listed, for example in the database 120.
  • a data model can be defined. As an example, such a model consists of the following seven tables which will be described below: Media, User ,. Sgp, Presence, List, Contact, Application. 1. Media Table
  • This table makes it possible to avoid redundancies since a medium is defined in a unique way by the couple (Identif ⁇ ant_dans_SGP, Identif ⁇ ant_SGP) '; from there a media is defined by a local identifier.
  • the Media_type field allows you to define the type of media (landline, mobile phone, etc.).
  • the User table will allow the correspondence between a user defined by his application identifier and the media he uses.
  • the SGP table will identify the SGP by storing the corresponding information (address of the server hosting the SGP, the port and the protocol used to communicate).
  • the Presence table contains the presence state of each media translated by the status field: binary state characterizing the user vis-à-vis means of joining it (for a PC, if it is connected or not on the network, for a mobile phone if it is connected to the GSM network or not ).
  • the note field is a character string giving information about the user in relation to a medium. This information is provided by the corresponding SGP and can be entered by the user or detected automatically.
  • the Expires field determines the expiration date of the information.
  • This table is used to assign one or more contact lists to a user.
  • a list of contacts is represented by a unique identifier and by an alphanumeric name.
  • This table associates users (contacts) with a list.
  • This table makes it possible to identify the applications 22-i using the server 10 in order, in particular, to notify them when the presence states change.
  • An application registers with a user name (Application_Identifier). Associated with it is an IP address, a port number and a protocol by which notifications will be transmitted to it.
  • the SGP 130 interface will allow the module 100 to be able to interoperate with different types of 24-i presence management systems. Most SGPs have a specific interface, the dialogue will not be done directly but through adaptive modules 132, 134, 136 (or the connectors 34-1 and 34-2 in Figure 1) which will serve as gateways between module 100 and SGPs.
  • the server can send requests to one or more of the SGP, requesting to transmit or report or notify one or any change of state of a user or a media.
  • the information or any state change information available will either be automatically notified by the SGP, or obtained by interrogation of the SGP.
  • This state change information then allows the server 10 to update the database 120, and possibly to inform the applications 22-i.
  • the local identifier of the media can be determined, and the table of presence can be updated taking into account the information received.
  • the module 100 can be used by multiple applications 22-i through different connectors (depending on the access mode chosen).
  • a API 140 has been defined in order to allow access to the different functions of module 100.
  • This API can be planned or programmed to provide, or to propose, one or more of the following functions, or groups of functions or interfaces, possibly same implemented or implemented or programmed in the database management system: - management of users and / or lists in the database (for example: addition or deletion of user and / or associated media and / or a list), - media management in the database (verification that a media is recorded, and / or creation or deletion of a media, verification that a media has given capacities, and / or associate or delete a capacity for a given medium); - associate media and users in the database (search for a given capacity among the media of a user and / or search for all the capacities of a user and / or all the media of a user who have a defined capacity, and / or sending of information concerning all the media of a user and / or all the users of a media, and / or addition or deletion of a media with a user); - obtain and / or modify the state of presence of media and / or users.
  • the API 140 preferably conforms to the specifications of the PAM forum (Presence and Availabilit-y Management). In more detail, here is an embodiment of each of these interfaces (Il - 17):
  • This interface provides an API for user and list management.
  • addToGroupQ Adds a user to a group or list (commonly called "contact list” or “friend lists”). Both the list and the user have been created beforehand.
  • createldentityQ Any user can use the facilities of the presence management service. To do this, it is declared by the application using this function by providing its identifier (name + context).
  • createGroupidentityQ Creation of a new list. The list is associated with a user. It contains a set of other users previously created.
  • deleteldentityQ This function is called for deregistering a user and associated media.
  • deleteGroupIdentityQ This function deletes a previously created list. IsidentityQ: This function tests whether the user is registered or not.
  • isGroupidentityO This function checks that the list exists.
  • UstMembersO This function lists the members of a list. 12.
  • Agent Management Interface This interface provides an API for media management.
  • isAgentQ This function tests whether the media is recorded or not.
  • createAgentf This function creates a media by adding the entries in the corresponding tables and causes the declaration of the media with the SGP concerned in order to receive notifications concerning it.
  • deleteAgent This function deletes the media from the tables and then calls the media deregistration function from the SGP interface.
  • isCapabie Qf This function tests whether the media has the capacity mentioned.
  • a capacity represents one or more technical characteristics of a medium, reflecting the possibility of the latter participating in communications and data exchange (example: instant message, WAP, SMS, etc.).
  • enableCapabilitiesQ This function associates an ability with a medium.
  • disableCapabilitiesQ This function removes an ability from a given media.
  • HstAIICapabilitiesQ This function lists all the capacities of a media
  • Agent Assignment Interface This interface allows you to link media to users. isIdentityCapableOfQ: This function tests whether, among the media that the user has, there is a media that has the requested capacity. listCapabilitiesOfldentityQ: This function lists all the capacities of a user.
  • UstAssignedAgentsByCapabilityO This function lists all the media of a user who have a certain capacity. HstAssignedAgentsQ: This function returns all the media associated with a user. UstAssociatedldentitiesOfAgentO: This function returns all the users of a media. assignAgent (): This function associates media with a user. unassignAgentQ: This function removes media from a user.
  • Agent Presence Interface This interface provides an API to obtain or modify the state of media presence.
  • getAgentPresen ⁇ Q This function returns the value of the presence attributes requested for a given media.
  • getCapabilii ⁇ Presen ⁇ O This function returns the value of the attributes for a specific capacity of a medium.
  • setAgentPresen ⁇ O This function sets the presence attributes of a given media.
  • setCapabifityPresencef J This function sets the value of the attributes of a set of capacities for a given medium.
  • Identity Pr sence Interface This interface allows users to obtain or modify the presence information.
  • getldentityPresenceQ This function returns the value of all the attributes requested for each media used by the user. setldentityPresenceQ: This function sets the value of the attributes of a given user.
  • Event Management Interface This interface allows applications to register (or deregister) in order to be notified of events.
  • registerAppInterfaceQ Registration of the notification interface for a given application.
  • deregisterAPPInterfa ⁇ Q Deregistering the notification interface of a previously registered application.
  • registerForEvent / deregisterFromEvent ⁇ Registration / deregistration of a client application for a given event.
  • the requested events are for example the following: - P ⁇ M_CE_AGENT_PRESEN ⁇ _SET: to be notified of changes in the explicit presence state of a user on a given medium, - PAM CE _IDENTITY_PRESENCE_SET: to be notified of the changes in the explicit presence state of a user (a user is declared present if one of its media is in the present state) 17.
  • Application Notification Interface This interface is implemented and offered by a client application in order to be notified of certain events.
  • the server 10 then functions as a client of the application and the latter is a server. When a change of state takes place, the server 10 invokes or calls this function or interface in the application, this function or interface making it possible to notify the changes to the application.
  • eventNotify This function is used by module 10 to notify an application of an event.
  • the functions of connectors 132, 134, 136 will now be described.
  • the module 100 providing a standard interface independent of the SGPs 24-i, the role of a connector module 132 - 134 is essentially the protocol adaptation between this module 100 and the SGP 20.
  • SIMPLE RRC 3265
  • SIMPLE Short Message Protocol
  • IM Instant Messaging Protocol
  • IM Instant Messaging Protocol
  • SIP Session Message
  • IM Instant Message
  • SIP Session Message
  • the functions of this connector are mainly the following four: - Aui authenticationlldentification: The connector is seen as an ordinary client by the SGP presence server. When it is launched or during a subscription, it identifies itself to this server by an authenticator / identifier. This identifier is specific to the module.
  • the adaptation module memorizes all the users it treats with the date of their last declaration to allow it to update it (timeout of one hour) or in the event of a restart of the module.
  • - Update of the presence status of a media The connector receives notifications (i OTIFY message) about the changes status of a user's media that it filters and retransmits to module 100. Notifications are received in “text / lpidf” format. Conversely, the connector receives requests to change the state of a medium from a user of the 22-i applications which it retransmits to the SGP.
  • Jabber is an instant messaging and presence management system based on the extensible Messaging and Presence Protocol (XMPP). It is designed to be interoperable with several instant messaging services such as AIM, Yahoo Messenger, MSN Messenger and ICQ via gateways.
  • the functions of the associated connector are mainly the following four: - Authentication / Identification: The connector is in fact a simple Jabber client. It must first connect and identify itself (like any other client of the Jabber server) before calling on objects allowing it to communicate with the Jabber server.
  • - Declaration by a user to the SGP Jabber uses the term roster for contact lists.
  • the connector receives responses from the server. In order to exploit these responses, "listeners" are set up, and in particular for notifications on the presence of a user. Each time a notification is received, the presence information is updated. Conversely, the connector receives update requests from the applications which it retransmits to the SGP via the SGP API 130.
  • the application connectors 151 - 157 make it possible to offer multiple invocation interfaces for module 10. They are supported by the application API 140 described above and therefore interact with the module 100 using the functions of this API.
  • the system includes for example one or more connectors for consulting and / or modifying data 152 - 155 and one or more connectors 156, 157 used for the notification of information or data from the server 10 to one or more applications 22-1 , 22-2.
  • connectors Web Service, HTTP, VXML, email and SMS.
  • Other connectors or connector configurations are obviously possible.
  • a WebService connector 151 makes it possible to make two subsystems of similar or different architectures communicate in a standard manner in order to exchange services or application processing.
  • the connector of type WebService set up allows access to the functions of module 100. Communication with the connector is done via an interface provided by this connector: only the functionalities of module 100 exposed through this interface are accessible by applications clients. Communication between the connector and the client application is done using the SOAP protocol.
  • the interface is provided to client applications that wish to interface with the module 100 either in the form of a WSDL file or, when possible, in the form of code (generated from the interface specifications provided by the WSDL file ) allowing the implementation at the client level of a SOAP proxy (code allowing the encoding / decoding of the data to be transmitted in SOAP format).
  • Access to the exposed functionalities of module 100 is carried out at the client level in two successive stages: calling the service either directly by its WSDL description, or by using a SOAP proxy from the WSDL file then calling the method corresponding to the functionality at which we want to access.
  • Access to the service and to the functionalities associated with it can be made from a client application implemented in any language offering SOAP implementations (Java, PHP, Perl ).
  • An HTTP connector 152 is in fact an HTTP server which hosts a set of HTML pages offering a Web interface allowing access to the presence management functions of the module 100. This connector therefore makes it possible to access the functions of this module from a simple web browser.
  • the web interface consists of the following pages:
  • a VXML 153 connector allows applications to access the functions of the module 100 in voice form. All that is required is to make VXML files (files in XML formats) accessible on the connector, which the application retrieves according to an established protocol.
  • the application is in fact a voice server equipped with a VXML interpreter which communicates with the connector by asking it for VXML pages and according to the choices made by the user through the voice interface.
  • the connector translates these choices into a function invocation of modules 100.
  • a function returns a result, such as for example from its list of contacts, this return is then dynamically translated into a VXML file so that the end user can read it.
  • An email connector 154 allows the application to invoke the functions of module 100 by sending electronic mails.
  • the messages that the application must send have the following form: object and body.
  • the object contains the name of the function to invoke, and in the body of the message the parameters of the function.
  • Object createGroupIdentity Corporation: name of the list, type of the list, identifier of the requester
  • the connector translates the messages sent by the application and converts them into a request from the application API.
  • the connector invokes the createGroupIdentity () function.
  • Some requests may require a return such as getAgentPresence ().
  • the connector returns the result by sending a response to the initiator message.
  • the message has the following form:
  • SMS 155 connector works a bit like the email connector.
  • the application sends SMS messages to invoke a function of module 100.
  • the format of SMS messages is as follows: nom_fct_a_invoquerlparametrellparametre2 / ...
  • an SMS message is sent back to the 'application according to the format: nom_fc_invoqueelvaleur instancellvaleur pointZI ...
  • Another type of connector, called notification allows module 100 to notify applications using specific events.
  • a notification connector implements the "Application Notification Interface" and is capable of transmitting the received notification messages, from the module 100 to the applications having made the request, according to a protocol chosen by these applications. It is also capable of taking into account the registration and deregistration messages sent by the applications. There is one connector per protocol supported.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un dispositif de traitement de données de présence d'appareils d'utilisateurs qui permet d'intégrer des fonctions de gestion de présence à des applications basées sur la mise en relation de personnes. A cet effet, le dispositif comprend des premiers moyens d'interface (140) pour permettre l'accès d'au moins une première application (22-1, 22-2) au dispositif et des moyens de communication avec au moins une base de données de présence (120). Le dispositif de traitement de données de présence comprend également des deuxièmes moyens d'interface (130) pour émettre une requête d'envoi d'informations de modifications de données de présence vers un deuxième dispositif de traitement de données (24-1, 24-2, 24-3) et pour recevoir lesdites informations de modifications.

Description

DISPOSITIF ET PROCEDE DE TRAITEMENT DE DONNEES DE PRESENCE
L'invention concerne les systèmes de gestion de présence, notamment dans les domaines multimédias et Internet. La gestion de présence est une fonction de plus en plus utilisée dans la mise en relation des individus. La présence est un état binaire (présent, absent) indiquant qu'un utilisateur est enregistré et connecté vis à vis d'un système de gestion de présence. Etre présent signifie que, vu du système de gestion de présence, l'utilisateur est enregistré et connecté au moyen d'un ou plusieurs terminaux. Etre « présent » ne veut pas obligatoirement dire que l'utilisateur est joignable. Par exemple, l'utilisateur d'un téléphone portable allumé sera considéré « présent » par un système de gestion de présence des mobiles mais sera injoignable dans une zone de non-couvertùre. La joignabilité (au niveau service) représente la visibilité, vis à vis d'un événement ou d'une personne, qu'un utilisateur souhaite donner de son état de présence et de sa volonté d'être ou de ne pas être joint, en fonction de sa disponibilité. La présence devient un enjeu important dans le développement de nouveaux services de communication. De nombreux" acteurs du domaine (éditeurs, constructeurs mobile, équipementiers, opérateurs, startups...) en ont pris conscience et y travaillent activement. En plus des . travaux menés sur le sujet dans les instances de normalisation (OMA, Parlay, PA forum, ÏETF), on voit poindre de plus en plus de solutions en rapport avec la gestion de présence. La plupart de ces solutions sont associées fortement à la messagerie instantanée. Certains acteurs travaillent plus spécifiquement sur la gestion de présence comme fonction indépendante de la messagerie instantanée : DynamicSoft, Indigo, Hotsip... offrent des serveurs de gestion de présence; - PresenceWorks, Antepo des solutions de médiation. Des industriels du monde mobile comme Ericsson, Motorola, Nokia tiennent compte de la présence dans leur plate-forme et applications. PresenceWorks fédère les informations de présence issues des services de messagerie instantanée tels que AOL, MSM Messenger, Yahoo Messenger, ICQ et permet ensuite d'être interrogée par des applications clientes. Antepo est une plate-forme multi-protocoles qui permet de s'interfacer avec des clients et/ou serveurs XMPP ou SIMPLE, voire plus. Un autre dispositif intitulé "dispositif pour gérer des informations de présence d'utilisateurs issues d'une pluralité de systèmes de gestion de présence" (FR-02 12471) n'est utilisable qu'en mode consultation. Aucune des solutions existantes n'offre la possibilité d'unifier l'accès à ces systèmes pour la consultation et la modification des données de présence pour un même utilisateur sur plusieurs serveurs en même temps. Elles ne permettent pas non plus d'interfonctionner avec d'autres systèmes de gestion de présence que ceux prévus par leurs interfaces, c'est-à-dire de les adapter facilement à d'autres. Et enfin, ces solutions n'offrent souvent qu'une interface applicative sous forme d'API ou de Web service, complexifiant ou limitant les possibilités d'applications les utilisant. Le dispositif décrit dans FR-02 12471 n'est utilisable qu'en mode consultation et non en mode client, c'est-à-dire qu'il ne permet pas de modifier les états de présence, de gérer une liste de contacts et d'être notifié des modifications d'états de présence des membres de cette liste.
E-^rosé i-s BlB snltiffi)»
L'invention concerne un ddispositif de traitement de données de présence d'appareils d'utilisateurs, comportant : - des premiers moyens d'interface, pour l'accès d'au moins une première application audit dispositif, - des moyens de communication avec au moins une base de données de présence, et des moyens de gestion de cette base de données, - des deuxième moyens d'interface pour émettre une requête d'envoi d'informations de modifications de données de présence vers un deuxième dispositif de traitement de données et pour recevoir lesdites informations de modifications. Un tel dispositif permet d'intégrer facilement, et de façon fiable, des fonctions de gestion de présence à des applications basées sur la mise en relation de personnes. Ce dispositif réalise une fonction de gestion de la base de données. Par ses moyens d'interface, il peut être adapté afin de répondre à l'environnement dans lequel il est intégré. Cette possibilité d'adaptation par les moyens d'interface apporte un gain de temps important dans la conception de nouvelles applications, mais aussi améliore la fiabilité du dispositif puisque les éléments génériques, et notamment de gestion de la base de données, peuvent être développés dans un contexte industriel, éprouvés puis testés. Les moyens de gestion de ladite base de données permettent une mise à jour de cette base en fonction des informations de modifications de données reçues du deuxième dispositif de traitement de données, ou éventuellement de l'application elle-même. Le dispositif selon l'invention peut en outre être relié, non seulement à un deuxième dispositif de traitement de données, mais aussi à un troisième, ou à une pluralité de dispositifs de traitement de données, chacun mémorisant des données de présence d'utilisateurs ou d'appareils ou de médias. Les deuxième moyens d'interface peuvent alors permettre l'émission d'une requête d'envoi d'informations de modifications de données de présence vers ce troisième, ou ces autres, dispositifs) de traitement de données. Eventuellement, un ou plusieurs connecteurs permettent une adaptation des protocoles du dispositif et des dispositifs de traitement de données. Les moyens de gestion de la base de données permettent alors de mémoriser dans la base les différentes informations, provenant des différents dispositifs de traitement de données, permettant à l'application, ou aux applications, de voir le dispositif comme un unique composant de gestion de présence. Par ailleurs, les premiers moyens d'interface peuvent permettre l'accès d'une ou de plusieurs applications audit dispositif, éventuellement à l'aide de connecteurs d'adaptation de protocoles. L'interface vers l'application, ou vers les applications, peut être en fait une interface multimodale, offrant plusieurs moyens d'accès et élargissant ainsi le type des applications pouvant utiliser le dispositif. L'interface peut ainsi comprendre un accès HTTP, et/ou Web Service, et/ou VXML, et/ou email, et/ou SMS, et/ou IM, et/ou SIMPLE et/ou d'autres éventuellement. L'invention concerne également un procédé de traitement de données de présence d'appareils d'utilisateurs, comportant : - la réception, par au moins un appareil serveur, de données de présence d'au moins un des appareils d'utilisateurs, - la transmission, à un deuxième appareil serveur, desdites données de présence, - la mise à jour, par ce deuxième appareil serveur, en fonction des données reçues, d'une base de données de présence, et, éventuellement, - l'envoi, à au moins une application, d'informations concernant des modifications de données de présence d'au moins un appareil d'utilisateur. Ce procédé comporte par exemple l'envoi, par le deuxième serveur au premier serveur, d'une requête d'envoi d'informations de modifications de données de présence. Il peut aussi comporter la réception, par le deuxième serveur, d'une requête d'envoi d'informations de modifications de données de présence, cette requête étant émise par une application, ou encore la réception, par le deuxième serveur, d'informations relatives à des modifications des données de présence d'au moins un appareil d'un utilisateur, ces informations étant émises par une des applications. Selon un autre aspect, le procédé selon l'invention peut en outre comporter la transmission, par le deuxième serveur au premier serveur, desdites informations relatives à des modifications des données de présence d'au moins un appareil d'un utilisateur, émises par une des applications. Ce procédé peut aussi comporter la mise à jour ou la modification ou la recherche, dans la base de données, de données relatives à au moins un appareil utilisé par au moins un utilisateur, ou à une caractéristique d'un tel appareil. Brève description des figures la figure 1 représente un mode de réalisation de l'invention, la figure 2 représente la structure d'un dispositif de traitement de données, la figure 3 représente une configuration générale d'un système selon l'invention.
Description détaillée de modes de réalisation de l'invention
La figure 1 représente la structure générale d'un dispositif 10 de traitement de données, ou ordinateur (par la suite appelé serveur), pouvant être utilisé dans le cadre de la présente invention. Des moyens de mémorisation 12, qui peuvent ou non être contenus dans le serveur 10, mémorisent des données, par exemple sous forme d'une base de données. La référence 11 symbolise des moyens d'accès à ces moyens de mémorisation et des moyens de gestion de cette base de données. Le serveur peut être relié à des éléments 22-1,... 22-n de différentes applications, par exemple différents ordinateurs ou différents serveurs. Chacun de ces éléments va dialoguer ou échanger des informations avec le serveur 10 selon un protocole d'accès spécifique, mais principalement en tant que « client » de ce serveur. En particulier, une ou plusieurs de ces applications vont rechercher des informations concernant la présence ou l'état de présence d'utilisateurs. Chacun de ces utilisateurs peut utiliser un ou plusieurs médias différents (par exemple : téléphone fixe, téléphone mobile, PC, PDA communiquant..etc.). Comme déjà indiqué ci-dessus^ la présence est par exemple un état binaire indiquant qu'un utilisateur est enregistré et connecté. Chacun de ces éléments va dialoguer ou échanger des informations avec le serveur 10 selon un protocole d'accès spécifique, mais principalement en tant que « client ». Chaque protocole se caractérise par exemple par une structuration des données (par exemple : structure des données identifiant un utilisateur), une structuration des requêtes, la manière dont sont traitées données et requêtes, ou des étapes de traitement des données et requêtes, éventuellement la manière de gérer certaines erreurs, ou des étapes de traitement des erreurs. Deux protocoles seront différents, s'ils diffèrent par au moins l'un des éléments ci-dessus, c'est-à-dire s'ils ont des structurations différentes des données (par exemple : structures des données identifiant un utilisateur), et/ou des structurations différentes des requêtes, et/ou des procédés différents et/ou des étapes différentes de traitement des données et/ou requêtes, et/ou des procédés et/ou des étapes différentes de gestion ou de traitement d'erreurs. Différents utilisateurs vont donc pouvoir dialoguer, en tant que « clients » avec le serveur 10 selon différents protocoles. D'où la présence, sur la figure 1, de différents connecteurs 32-1, 32-2 ou interfaces d'accès. Le serveur 10 peut par ailleurs être relié à un ou plusieurs éléments, par exemple différents ordinateurs ou différents serveurs, appelés encore serveurs de gestion de présence, ou « SGP », 24-1,..., 24-n. Ces SGP hébergent des informations, par exemple sous forme de base de données, relatives à des états de présence de différents utilisateurs. Encore une fois, chaque utilisateur peut utiliser différents médias, les données concernant la présence d'un média d'un utilisateur donné étant transmises puis répertoriées dans un SGP unique, celles concernant un autre média du même utilisateur pouvant être, de même, transmises puis répertoriées dans un SGP unique, le même que le précédent ou un autre. Tout changement d'état de présence d'un utilisateur ou d'un média d'un utilisateur est notifié au SGP correspondant, par e emple soit par l'utilisateur ou le média lui-même, soit par un tiers qui peut d'ailleurs être une des applications 22-i. Ces changements d'état sont ensuite transmis ou notifiés au serveur 10, qui met ainsi à jour la base de donnée 12. On notera que, lorsque c'est une application 22-i qui notifie un changement d'état, elle le fait d'abord au serveur 10, qui retransmet ensuite l'information au SGP correspondant qu'il identifie par les informations contenues dans la base de données 12. Le serveur 10 va donc dialoguer ou échanger des informations avec chacun des SGP 24-i mais il agit principalement comme client vis-à vis de ceux-ci. De préférence, il mémorise, par exemple dans la base de données 12, les données d'identification des SGP (par exemple : adresse du serveur qui l'héberge) à atteindre ou à interroger pour un média donné d'un utilisateur donné et éventuellement le protocole utilisé pour communiquer avec ce SGP. Les références 34-1, 34-2 représentent deux connecteurs ou interfaces d'accès permettant de faire dialoguer le serveur 10 avec des SGP n'exploitant pas les mêmes protocoles, au sens déjà indiqué ci- dessus. La figure 2 représente schématiquement, en bloc, les diverses composantes d'un appareil de traitement de données 40. Un microprocesseur 50 est relié, par un bus 52, à un ensemble de mémoires RAM 54 pour stocker des données, et à une mémoire ROM 56 dans laquelle des instructions de programme peuvent être mémorisées. Ce système peut en outre comporter un dispositif de visualisation 58, ou écran et des moyens périphériques tels que clavier ou souris. La référence 64 désigne des moyens d'interface avec un réseau, par exemple de type modem. Selon un autre exemple, il peut s'agir d'un port Ethernet associé à une ou plusieurs carte(s) réseau. Il peut aussi s'agir d'un (ou de plusieurs) port(s) spécifιque(s) pour supporter un ou des protocole(s) particulier(s). Le serveur 10, ainsi que les serveurs 24-1, ...24-n, ont chacun, globalement, une structure du même type, avec un ou plusieurs processeur(s), une ou plusieurs zone(s) de stockage de données et diverses connexions aux réseaux, une ou plusieurs mémoire(s) dans lesquelles des instructions de programme peuvent être mémorisées, et notamment les instructions pour la mise en oeuvre des procédés décrits dans la présente demande. Un mode de réalisation de l'invention va être décrit, en liaison avec la figure 3, sur laquelle les références 100 - 157 désignent des éléments logiciels hébergés sur le serveur 10. Plus précisément, les références 132 - 136 représentent trois connecteurs pour SGP, et les références 151 - 157 six connecteurs applicatifs. Ce mode de réalisation comporte donc un module central 100, ainsi que, en outre, une interface de programmation d'application, ou API 130, du côté des systèmes SGP 24-1, 24-2, 24-3 de gestion de présence, et une interface de programmation d'application, ou API 140 du côté des applications 22-i. Le module central 100 stocke, sous forme de base de données
120, les informations associées aux utilisateurs à partir des notifications transmises par un ou plusieurs SGP à travers l'API SGP 130, ou éventuellement transmises par les applications 22-i à travers l'API 140.
Ces informations comportent par exemple l'état de présence d'un utilisateur ou d'un ou de plusieurs de ses médias et, éventuellement, les listes de contacts et états de présence associés, ou encore des données ou caractéristiques techniques relatives aux appareils ou médias utilisés par les utilisateurs. Un système de gestion de base de données est mis en oeuvre, de préférence conçu d'une manière la plus ouverte possible c'est-à-dire présentant une ou plusieurs des caractéristiques suivantes : - le module 100 peut interfonctionner avec différents types de
SGP; - un utilisateur peut disposer de plusieurs médias qui peuvent être enregistrés dans différents SGP 24-i; - un utilisateur peut avoir plusieurs listes de contacts; - les contacts peuvent être enregistrés dans différents SGP 24-i; - la gestion est évolutive. Selon un exemple, le système de gestion de base de données permet non seulement d'identifier et de mettre à jour l'état de présence d'un média, mais aussi de notifier automatiquement certaines des applications 22-i, qui ont spécifiquement requis l'envoi, ou souscrit à l'envoi, de telles notifications, lors d'un changement d'état de présence d'un média ou d'un utilisateur donné. A cette fin, les applications utilisatrices peuvent être répertoriées, par exemple dans la base de données 120. Pour pouvoir mémoriser les différentes informations, un modèle de données peut être défini. A titre d'exemple, un tel modèle se compose des sept tables suivantes qui vont être décrites ci-dessous: Média, Utilisateur,. Sgp, Présence, Liste, Contact, Application. 1. Table Média
Figure imgf000011_0001
Cette table permet d'éviter les redondances puisqu'un média est défini d'une façon unique par le couple (Identifιant_dans_SGP, Identifιant_SGP) ' ; à partir de là un média est défini par un identifiant local. Le champ Type_média permet de définir le type de média (téléphone fixe, téléphone mobile...).
2. Table Utilisateur
Figure imgf000011_0002
La table Utilisateur va permettre de faire la correspondance entre un utilisateur défini par son identifiant applicatif et les médias qu'il utilise.
3. Table SGP
Figure imgf000011_0003
La table SGP va permettre d'identifier le SGP en stockant les informations correspondantes (adresse du serveur qui héberge le SGP, le port et le protocole utilisé pour communiquer).
4o --Ta-feDe P-rése-r-iœ
Figure imgf000011_0004
La table Présence contient l'état de présence de chaque média traduit par le champ status : état binaire caractérisant l'utilisateur vis-à-vis des moyens de le joindre (pour un PC, s'il est connecté ou non sur le réseau, pour un téléphone mobile s'il est connecté le réseau GSM ou non...). Le champ note est une chaîne de caractère donnant des informations sur l'utilisateur par rapport à un média. Cette information est fournie par le SGP correspondant et peut être saisie par l'utilisateur ou détectée automatiquement. Le champ Expires détermine la date d'expiration des informations.
5. Table Liste
Figure imgf000012_0001
Cette table permet d'attribuer une ou plusieurs listes de contacts à un utilisateur. Une liste de contacts est représentée par un identifiant unique et par un nom alphanumérique.
(5. Tatoi© Contac
Figure imgf000012_0002
Cette table associe des utilisateurs (contacts) à une liste.
7. Table Application
Figure imgf000012_0003
Cette table permet d'identifier les applications 22-i utilisatrices du serveur 10 afin, notamment, de les notifier lors de changement d'états de présence. Une application s'enregistre avec un nom d'utilisateur (Identifιant_Applicatif). Lui sont associés une adresse IP, un numéro de port et un protocole par lesquels les notifications lui seront transmises. L'interface SGP 130 va permettre au module 100 de pouvoir interfonctionner avec différents types de systèmes de gestion de présence 24-i. La plupart des SGPs ayant une interface spécifique, le dialogue ne se fera pas directement mais par l'intermédiaire de modules adaptatifs 132, 134, 136 (ou les connecteurs 34-1 et 34-2 de la figure 1) qui serviront de passerelles entre le module 100 et les SGPs. Le serveur peut envoyer des requêtes à un ou plusieurs des SGP, demandant ainsi de transmettre ou de signaler ou de notifier un ou tout changement d'état d'un utilisateur ou d'un média. Suivant le mode de fonctionnement du SGP, l'information ou toute information de changement d'état disponible sera soit notifiée automatiquement par le SGP, soit obtenue par interrogation du SGP. Ces informations de changement d'état permettent ensuite au serveur 10 de mettre à jour la base de données 120, et éventuellement d'informer les applications 22-i. Selon un exemple de réalisation, voici quelques fonctions de l'interface 130: - Changement de l'état de présence sur un média donné Requête envoyée par l'interface 130 au SGP correspondant au média concerné pour demander le changement d'état. - Enregistrement d'un média d'un utilisateur auprès du SGP Requête envoyée au SGP par l'interface 130 pour demander à recevoir les notifications relatives à l'état de présence d'un média donné pour un utilisateur donné. - Désenregistrement d'un média auprès du SGP Requête envoyée au SGP par l'interface 130 pour supprimer les demandes de notifications concernant ce média. - Mise à jour de l'état de présence d'un média L'interface SGP 130 reçoit des notifications d'un SGP à propos des changements d'état d'un média d'un utilisateur.
Selon l'exemple de tables indiqué ci-dessus pour le système de base de données, à partir de l'identifiant du média dans le SGP et l'identifiant du SGP, l'identifiant local du média peut être déterminé, et la table de présence peut être mise à jour en tenant compte des informations reçues. Le module 100 peut être utilisé par de multiples applications 22-i au travers de différents connecteurs (selon le mode d'accès choisi). Une API 140 a été définie afin de permettre l'accès aux différentes fonctions du module 100. Cette API peut être prévue ou programmée pour assurer, ou pour proposer, une ou plusieurs des fonctions, ou des groupes de fonctions ou interfaces suivantes, éventuellement elles- mêmes implementees ou mises en oeuvre ou programmées dans le système de gestion de la base de données: - gestion des utilisateurs et/ou des listes dans la base de données (par exemple : ajout ou suppression d'utilisateur et/ou des médias associés et/ou d'une liste), - gestion des médias dans la base de données (vérification qu'un média est enregistré, et/ou création ou suppression d'un média, vérification qu'un média a des capacités données, et/ou associer ou supprimer une capacité pour un média donné) ; - associer médias et utilisateurs dans la base de données (recherche d'une capacité donnée parmi les médias d'un utilisateur et/ou recherche de toutes les capacités d'un utilisateur et/ou de tous les médias d'un utilisateur qui ont une capacité définie, et/ou envoi de l'information concernant tous les médias d'un utilisateur et/ou tous les utilisateurs d'un média, et/ou ajout ou suppression d'un média avec un utilisateur) ; - obtenir et/ou modifier l'état de présence de médias et/ou d'utilisateurs. - enregistrement d'applications pour être notifiées d'événements ; - fonction de mise en oeuvre d'applications clientes par le serveur afin que celui-ci soit notifié de certains événements. On peut n'utiliser que certaines des fonctions ci-dessus. Pour faciliter son intégration et la rendre la plus évolutive possible, l'API 140 se conforme de préférence aux spécifications du PAM forum (Présence and Availabilit-y Management). De manière plus détaillée, voici un mode de réalisation de chacune de ces interfaces (Il - 17):
II. Identity Management Interface Cette interface fournit une API pour la gestion des utilisateurs et des listes. addToGroupQ : Ajoute un utilisateur à un groupe ou liste (communément appelé "liste de contacts" ou "listes d'amis"). La liste comme l'utilisateur ont été préalablement créés. createldentityQ : Tout utilisateur peut utiliser les facilités du service de gestion de présence. Pour ce faire, il est déclaré par l'application à l'aide de cette fonction en fournissant son identifiant (nom+contexte). createGroupidentityQ : Création d'une nouvelle liste. La liste est associée à un utilisateur. Elle contient un ensemble d'autres utilisateurs préalablement créés. deleteldentityQ : Cette fonction est appelée pour le désenregistrement d'un utilisateur et des médias associés. deleteGroupIdentityQ : Cette fonction supprime une liste préalablement créée. IsidentityQ : Cette fonction teste si l'utilisateur est enregistré ou non. isGroupidentityO : Cette fonction vérifie que la liste existe. UstMembersO : Cette fonction liste les membres d'une liste. 12. Agent Management Interface Cette interface fournit une API pour la gestion des médias. isAgentQ : Cette fonction teste si le média est enregistré ou non. createAgentf) : Cette fonction crée un média en ajoutant les entrées dans les tables correspondantes et provoque la déclaration du média auprès du SGP concerné afin de recevoir des notifications le concernant. deleteAgent() : Cette fonction supprime le média des tables puis elle fait appel à la fonction de désenregistrement d'un média de l'interface SGP. isCapabie Qf() Cette fonction teste si le média a la capacité mentionnée. Une capacité représente une ou plusieurs caractéristiques techniques d'un média traduisant la possibilité de ce dernier de participer aux communications et à l'échange de données (exemple: message instantané, WAP, SMS...). enableCapabilitiesQ : Cette fonction associe une capacité à un média. disableCapabilitiesQ : Cette fonction supprime une capacité à un média donné. HstAIICapabilitiesQ : Cette fonction liste toutes les capacités d'un média.
13. Agent Assignement Interface Cette interface permet de rattacher les médias aux utilisateurs. isIdentityCapableOfQ : Cette fonction teste si, parmi les médias que l'utilisateur possède, il existe un média qui a la capacité demandée. listCapabilitiesOfldentityQ : Cette fonction liste toutes les capacités d'un utilisateur.
UstAssignedAgentsByCapabilityO : Cette fonction liste tous les médias d'un utilisateur qui ont une certaine capacité. HstAssignedAgentsQ : Cette fonction retourne tous les médias associés à un utilisateur. UstAssociatedldentitiesOfAgentO : Cette fonction retourne tous les utilisateurs d'un média. assignAgent() : Cette fonction associe un média à un utilisateur. unassignAgentQ : Cette fonction supprime un média à un utilisateur.
14. Agent Présence Interface Cette interface fournit une API pour obtenir ou modifier l'état de présence des médias. getAgentPresenœQ : Cette fonction retourne la valeur des attributs de présence demandés pour un média donné. getCapabiliiγPresenœO : Cette fonction retourne la valeur des attributs pour une capacité spécifique d'un média. setAgentPresenœO : Cette fonction positionne les attributs de présence d'un média donné. setCapabifityPresencef J : Cette fonction positionne la valeur des attributs d'un ensemble de capacités d'un média donné. 15. Identity Pr sence Interface Cette interface permet d'obtenir ou de modifier les informations de présence des utilisateurs. getldentityPresenceQ : Cette fonction retourne la valeur de tous les attributs demandés pour chaque média utilisé par l'utilisateur. setldentityPresenceQ : Cette fonction positionne la valeur des attributs d'un utilisateur donné.
16. Event Management Interface Cette interface permet aux applications de s'enregistrer (ou de se désenregistrer) afin d'être notifiées d'événements. registerAppInterfaceQ Enregistrement de l'interface de notification d'une application donnée. deregisterAPPInterfaœQ : Désenregistrement de l'interface de notification d'une application préalablement enregistrée. registerForEvent/deregisterFromEventζ) : Enregistrement/désenregistrement d'une application cliente pour un événement donné.
Les événements demandés sont par exemple les suivants : - PÂM_CE_AGENT_PRESENŒ_SET : pour être notifié des changements d'état de présence explicite d'un utilisateur sur un média donné, - PAM CE _IDENTITY_PRESENCE_SET : pour être notifié des changements d'état de présence explicite d'un utilisateur (un utilisateur est déclaré présent si l'un de ses médias est à l'état présent) 17. Application Notification Interface Cette interface est implémentée et proposée par une application cliente afin d'être notifiée de certains événements. Le serveur 10 fonctionne alors comme client de l'application et celle-ci est serveur. Lorsqu'un changement d'état a lieu, le serveur 10 invoque ou appelle cette fonction ou interface dans l'application, cette fonction ou interface permettant de notifier les changements à l'application. eventNotify() : Cette fonction est utilisée par le module 10 pour notifier une application d'un événement. Les fonctions des connecteurs 132, 134, 136 vont maintenant être décrites. Le module 100 fournissant une interface standard indépendante des SGPs 24-i, le rôle d'un module connecteur 132 - 134 est essentiellement l'adaptation protocolaire entre ce module 100 et le SGP 20. Il y a autant de connecteurs que d'interfaces SGP différentes. II existe plusieurs types de protocoles d'interface avec les systèmes de gestion de présence SGP 24-i. Certains sont standardisés ou en cours de standardisation par l'IETF tels que: SIMPLE (RFC 3265), qui est utilisé aussi pour transporter les messages échangés entre messageries instantanées. - XMPP (Internet draft), protocole défini par Jabber, qui est utilisé principalement pour la messagerie instantanée ; il fournit un ensemble de fonctionnalités qui supportent la notion de présence. En plus de ces standards, il existe de nombreux protocoles propriétaires tels que ceux d'ICQ et d'AOL. Le connecteur SIMPLE (SIP for Instant Messaging and Pr sence
Leveraging Extensions) met en oeuvre un protocole permettant l'interopérabilité entre les services de message instantané et de présence conformément au RFC 2779 et aux spécifications du CPIM (Common Présence and Instant Messaging ). SIMPLE permet de proposer une structure générale de notifications d'événements qui a ensuite été instanciée pour SIP, de proposer une extension de SIP pour le transport des IM (Instant Message); et de proposer une extension de SIP pour supporter les messages de souscription et notification utilisés par des serveurs de gestion de présence. Les fonctions de ce connecteur sont principalement les quatre suivantes : - Auihentificationlldentification : Le connecteur est vu comme un client ordinaire par le serveur de présence SGP. Lors de son lancement ou lors d'une souscription, il s'identifie auprès de ce serveur par un authentifiant/identifiant. Cet identifiant est propre au module. Déclaration d'un utilisateur auprès du SGP : Cette demande est envoyée au SGP à partir de son identifiant utilisateur. Le module d'adaptation mémorise tous les utilisateurs qu'il traite avec la date de leur dernière déclaration pour lui permettre de l'actualiser (timeout d'une heure) ou en cas de redémarrage du module. - Mise à jour de l'état de présence d'un média : Le connecteur reçoit des notifications (message i OTIFY) à propos des changements d'état d'un média d'un utilisateur qu'il filtre et retransmet au module 100. Les notifications sont reçues sous format « text/lpidf ». Réciproquement, le connecteur reçoit des demandes de changement d'état d'un média d'un utilisateur des applications 22-i qu'il retransmet au SGP. Désenregistrement d'un utilisateur: Cette fonctionnalité envoie un message SUBSCRIBE au serveur de présence puis supprime l'utilisateur de la base locale. Jabber est un système de messagerie instantanée et de gestion de présence basé sur le protocole XMPP (extensible Messaging and Présence Protocol). Il est conçu pour être interopérable avec plusieurs services de messagerie instantanée comme AIM, Yahoo Messenger, MSN Messenger et ICQ via des passerelles. Les fonctions du connecteur associé sont principalement les quatre suivantes : - Authentification/Identification : Le connecteur est en fait un simple client Jabber. Il doit tout d'abord se connecter et s'identifier (comme tout autre client du serveur Jabber) avant de faire appel à des objets lui permettant de communiquer avec le serveur Jabber. - Déclaration d'un utilisateur auprès du SGP : Jabber utilise le terme roster pour les listes de contacts. Dans un roster, il peut y avoir les listes de contacts ainsi que des ressources que l'on veut sauvegarder comme par exemple les noms de salons de discussion. Pour ce connecteur, il est utilisé pour sauvegarder les noms des utilisateurs dont les états de présence sont intéressants. Un utilisateur à déclarer au serveur Jabber est ajouté dans le roster, puis il est souscrit à son état de présence. Pour pouvoir recevoir des notifications, il faut déclarer un état de présence comme « available » au serveur. Le serveur interroge l'utilisateur en question s'il accepte la demande de souscription. Dans le cas positif, le serveur envoie des notifications chaque fois qu'il y a un changement dans l'état de présence de l'utilisateur concerné. - Désenregistrement d'un utilisateur : Le désenregistrement d'un utilisateur correspond tout simplement à la suppression de cet utilisateur du roster. Si on souhaite juste ne plus recevoir de notification tout en conservant l'utilisateur dans la liste de contact, il suffit d'envoyer un message de type Présence. UNSUBSCRIBE. Il faut noter que la suppression d'un utilisateur du roster entraîne systématiquement l'annulation de la souscription de présence, par contre l'ajout d'un utilisateur au roster n'entraîne pas automatiquement une souscription. Mise à jour de l'état de présence d'un média : Le connecteur reçoit des réponses du serveur. Afin d'exploiter ces réponses, des « écouteurs » (ou listeners) sont mis en place, et notamment pour les notifications sur la présence d'un utilisateur. A chaque fois qu'une notification est reçue, les informations de présence sont mises à jour. Réciproquement, le connecteur reçoit des demandes de mise à jour en provenance des applications qu'il retransmet au SGP via l'API SGP 130. Les connecteurs applicatifs 151 - 157 permettent d'offrir de multiples interfaces d'invocation du module 10. Ils sont supportés par l'API applicative 140 décrite ci-dessus et dialoguent donc avec le module 100 en utilisant les fonctions de cette API. Le système comporte par exemple un ou des connecteurs de consultation et/ou de modifications de données 152 - 155 et un ou des connecteurs 156, 157 utilisés pour la notification d'informations ou de données du serveur 10 vers une ou des applications 22-1, 22-2. Dans le présent exemple, on identifie 5 connecteurs (Web Service, HTTP, VXML, email et SMS). D'autres connecteurs ou configurations de connecteurs sont bien évidemment envisageables. Un connecteur WebService 151 permet de faire communiquer deux sous-systèmes d'architectures semblables ou différentes de manière standard dans le but d'échanger des services ou des traitements applicatifs. Le connecteur de type WebService mis en place permet d'accéder aux fonctions du module 100. La communication avec le connecteur se fait via une interface fournit par ce connecteur: seules les fonctionnalités du module 100 exposées au travers de cette interface sont accessibles par les applications clientes. La communication entre le connecteur et l'application cliente se fait en utilisant le protocole SOAP. L'interface est fournie aux applications clientes qui souhaitent s'interfacer avec le module 100 soit sous forme de fichier WSDL soit, quand c'est possible, sous forme de code (généré à partir des spécifications de l'interface fournies par le fichier WSDL) permettant l'implémentation au niveau du client d'un proxy SOAP (code permettant le codage / décodage des données à transmettre au format SOAP). L'accès aux fonctionnalités exposées du module 100 est réalisé au niveau du client en deux étapes successives : appel du service soit directement par sa description WSDL, soit en utilisant un proxy SOAP issu du fichier WSDL puis appel de la méthode correspondant à la fonctionnalité à laquelle on souhaite accéder. L'accès au service et aux fonctionnalités qui lui sont associées peut être effectué à partir d'une application cliente implémentée dans tout langage offrant des implémentations de SOAP (Java, PHP, Perl...). Un Connecteur HTTP 152 est en fait un serveur HTTP qui héberge un ensemble de pages HTML offrant une interface Web permettant d'accéder aux fonctions de gestion de présence du module 100. Ce connecteur permet donc d'accéder aux fonctions de ce module à partir d'un, simple navigateur Web. L'interface Web se compose des pages suivantes :
- une page d'identification de l'utilisateur
- une page d'accueil présentant la liste courante de contacts (et l'état de présence de chaque membre de la liste) et les fonctions accessibles (modification état de présence, gestion de la buddy list) - une page modification de la gestion de présence
- une page gestion de la liste de contact présentant les fonctions associées (ajout, suppression...) une page par fonction possible au niveau de la liste de contacts. Un Connecteur VXML 153 permet à des applications d'accéder sous forme vocale aux fonctions du module 100. Il suffit pour cela de rendre accessible sur le connecteur des fichiers VXML (fichiers aux formats XML) que l'application récupère selon un protocole établi
(souvent HTTP). L'application est en fait un serveur vocal doté d'un interpréteur VXML qui communique avec le connecteur en lui demandant des pages VXML et en fonction des choix faits par l'utilisateur au travers de l'interface vocale. Le connecteur traduit ces choix en invocation de fonctions du modules 100. Quand une fonction retourne un résultat, comme par exemple de sa liste de contacts, ce retour est alors traduit dynamiquement en fichier VXML afin que l'utilisateur final puisse en prendre connaissance. Un Connecteur email 154 permet à l'application d'invoquer les fonctions du module 100 par envoi de courriers électroniques. Les messages que doit envoyer l'application ont la forme suivante : objet et corps. L'objet contient le nom de la fonction à invoquer, et dans le corps du message les paramètres de la fonction. Selon un exemple : Objet : createGroupIdentity Corps : nom de la liste, type de la liste, identifiant du demandeur Le connecteur traduit les messages émis par l'application et les convertit en requête de l'API applicative. Dans l'exemple donné, le connecteur invoque la fonction createGroupIdentityQ. Certaines requêtes peuvent nécessiter un retour comme par exemple getAgentPresenceQ. Pour cela le connecteur retourne le résultat en envoyant une réponse au message initiateur. Le message a la forme suivante :
Objet: RE: getAgentPresenœ Corps : <valeurs retournées par l'exécution de la fonction> Un Connecteur SMS 155 fonctionne un peu comme le connecteur email. L'application envoie des messages SMS pour invoquer une fonction du module 100. Le format des messages SMS est le suivant : nom_fct_a_invoquerlparametrellparametre2/... De la même façon, si une requête nécessite une réponse, un message SMS est envoyé en retour à l'application selon le format : nom_fc_invoqueelvaleur retourllvaleur retourZI... Un autre type de connecteur, dit de notification, permet au module 100 de notifier les applications utilisatrices d'événements particuliers. Un connecteur de notification implémente l'interface "Application Notification Interface" et est capable de transmettre les messages de notification reçus, du module 100 aux applications en ayant fait la demande, selon un protocole choisi par ces applications. Il est aussi capable de prendre en compte les messages d'enregistrement et de désenregistrement envoyés par les applications. Il existe un connecteur par protocole supporté.

Claims

REVENDICATIONS
1. Dispositif de traitement de données de présence d'appareils d'utilisateurs, comportant des premiers moyens d'interface (140) pour l'accès d'au moins une première application (22-1, 22-2) audit dispositif, et des deuxièmes moyens d'interface (130) pour émettre une requête d'envoi d'informations de modifications de données de présence vers un deuxième dispositif de traitement de données (24-1, 24-2, 24-3) et pour recevoir lesdites informations de modifications, caractérisé en ce qu'il comprend en outre des moyens (11) de communication avec au moins une base de données de présence (12, 120), et de gestion de ladite base de données (12, 120) permettant une mise à jour de cette base en fonction des informations de modifications de données reçues du deuxième dispositif de traitement de données (24- 1, 24-2, 24-3).
2. Dispositif selon la revendication 1, les premiers moyens d'interface (140) constituant une interface multimodale.
3. Dispositif selon la revendication 1 ou 2, les deuxièmes moyens d'interface (130) permettant l'émission d'une requête d'envoi d'informations de modifications de données de présence vers un troisième dispositif de traitement de données.
4. Dispositif selon l'une des revendications 1 à 3, comportant en outre au moins un connecteur (132, 134, 136) pour adapter un protocole du dispositif à un protocole du deuxième dispositif de traitement de données et éventuellement d'autres dispositifs de traitement de données.
5. Dispositif selon l'une des revendications 1 à 4, comportant en outre des moyens pour envoyer ou notifier ladite première application (22-1, 22-2) d'un changement dans les données contenues dans la base de données (12, 120).
6. Dispositif selon la revendication 5, l'envoi ou la notification d'un changement étant réalisé en fonction de données d'adressage de l'application contenues dans la base de données (12, 120).
7. Dispositif selon l'une des revendications 1 à 6, comportant en outre des moyens (100, 140) pour recevoir des informations de modification de données de la part de ladite première application (22-1, 22-2), lesdits moyens (11) de gestion de ladite base de données (12, 120) permettant une mise à jour de cette base en fonction de ces informations de modification.
8. Dispositif selon la revendication 7, comportant en outre des moyens (100, 130) pour transmettre lesdites informations de modification de données reçues de la part de ladite première application vers le deuxième ou éventuellement d'autres dispositifs (24-l,...24-n) de traitement de données.
9. Dispositif selon la revendication 8, lesdites informations de modification de données reçues de la part de ladite première application étant transmises en fonction de données d'adressage contenues dans la base de données (12,120).
10. Dispositif selon l'une des revendications 1 à 9, comportant en outre des moyens (100, 140) pour ajouter ou supprimer un utilisateur ou un appareil d'un utilisateur dans la base de données.
11. Dispositif selon l'une des revendications 1 à 10, comportant en outre des moyens (100, 140) pour vérifier, dans la base de données, qu'un appareil est enregistré et/ou a au moins une capacité ou caractéristique donnée et/ou pour créer ou supprimer, dans la base de données, un appareil ou une capacité ou caractéristique d'un appareil dans la base de données.
12. Dispositif selon l'une des revendications 1 à 11, comportant en outre des moyens (100, 140) pour rechercher une capacité donnée parmi les appareils d'un utilisateur et/ou rechercher toutes les capacités d'un utilisateur et/ou rechercher tous les appareils d'un utilisateur qui ont une capacité définie, et/ou envoyer l'information concernant tous les appareils d'un utilisateur et/ou rechercher tous les utilisateurs d'un type d'appareils, et/ou ajouter ou supprimer un appareil en relation avec un utilisateur.
13. Procédé de traitement de données de présence d'appareils d'utilisateurs, lesdites données de présence étant reçues par au moins un appareil serveur (24-1,...24-n), le procédé comportant la transmission, à un deuxième appareil serveur (10), desdites données de présence, caractérisé en ce qu'il comprend en outre la mise à jour, par ce deuxième appareil serveur, en fonction des données reçues, d'une base de données de présence (12, 120).
14. Procédé selon la revendication 13, comportant en outre l'envoi, à au moins une application (22-1, 22-2), d'informations concernant des modifications de données de présence d'au moins un appareil d'utilisateur.
15. Procédé selon la revendication 13 ou 14, comportant l'envoi, par le deuxième serveur au premier serveur, d'une requête d'envoi d'informations de modifications de données de présence.
16. Procédé selon l'une des revendications 13 à 15, comportant la réception, par le deuxième serveur, d'une requête d'envoi d'informations de modifications de données de présence, cette requête étant émise par une application (22-1, 22-2).
17. Procédé selon l'une des revendications 13 à 16, comportant en outre la réception, par le deuxième serveur, d'informations relatives à des modifications des données de présence d'au moins un appareil d'un utilisateur, ces informations étant émises par une des applications (22-1,
22-2).
18. Procédé selon la revendication 17, comportant en outre la transmission, par le deuxième serveur (10) au premier serveur (24- l,...24-n), desdites informations relatives à des modifications des données de présence d'au moins un appareil d'un utilisateur, émises par une des applications.
19. Procédé selon l'une des revendications 14 à 18, comportant en outre la mise à jour ou la modification ou la recherche, dans la base de données (12, 120), de données relatives à au moins un appareil utilisé par au moins un utilisateur, ou à une caractéristique d'un tel appareil.
PCT/FR2004/001812 2003-07-09 2004-07-09 Dispositif et procede de traitement de donnees de presence WO2005006684A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR03/08423 2003-07-09
FR0308423A FR2857479A1 (fr) 2003-07-09 2003-07-09 Dispositif et procede de traitement de donnees de presence

Publications (1)

Publication Number Publication Date
WO2005006684A1 true WO2005006684A1 (fr) 2005-01-20

Family

ID=33522914

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001812 WO2005006684A1 (fr) 2003-07-09 2004-07-09 Dispositif et procede de traitement de donnees de presence

Country Status (2)

Country Link
FR (1) FR2857479A1 (fr)
WO (1) WO2005006684A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001072055A2 (fr) * 2000-03-22 2001-09-27 Tekelec Noeud d'enregistrement de presence et de routage
WO2001078425A1 (fr) * 2000-04-11 2001-10-18 Telecommunication Systems, Inc. Suiveur d'etat d'activite d'un dispositif mobile
US20030065788A1 (en) * 2001-05-11 2003-04-03 Nokia Corporation Mobile instant messaging and presence service
US6549937B1 (en) * 1999-07-21 2003-04-15 Microsoft Corporation System and method for multi-protocol communication in a computer network
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
US6549937B1 (en) * 1999-07-21 2003-04-15 Microsoft Corporation System and method for multi-protocol communication in a computer network
WO2001072055A2 (fr) * 2000-03-22 2001-09-27 Tekelec Noeud d'enregistrement de presence et de routage
WO2001078425A1 (fr) * 2000-04-11 2001-10-18 Telecommunication Systems, Inc. Suiveur d'etat d'activite d'un dispositif mobile
US20030065788A1 (en) * 2001-05-11 2003-04-03 Nokia Corporation Mobile instant messaging and presence service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAY M ET AL: "A Model for Presence and Instant Messaging", IETF REQUEST FOR COMMENTS, XX, XX, no. 2778, February 2000 (2000-02-01), pages 1 - 17, XP002199726 *

Also Published As

Publication number Publication date
FR2857479A1 (fr) 2005-01-14

Similar Documents

Publication Publication Date Title
US9929984B2 (en) Method and computer program product for establishing real-time communications between networked computers
US9723460B1 (en) Device message management system
EP1726124B1 (fr) Systeme et procede de controle d&#39;equipements a distance a l&#39;aide de commandes at, dispositif, module de radiocommunication et programme correspondants
US20060010201A1 (en) Method and computer program product for establishing real-time communications between networked computers
CN1825311A (zh) 用于从多个联系人源聚集联系人信息的方法和系统
EP1590931A1 (fr) PROCEDE DE PRESENTATION D&amp;rsquo;ETAT D&amp;rsquo;UN UTILISATEUR UTILISANT PLUSIEURS EQUIPEMENTS DE COMMUNICATION
IL173011A (en) Image insertion for cellular text messaging
EP3087706B1 (fr) Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée
EP2795870B1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP1900179A2 (fr) Procede d&#39;obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp
EP2169911A1 (fr) Procédé permettant la communication interopérable entre communautés réelles et virtuelles
EP1595371A1 (fr) PROCEDE DE GESTION DE PRESENCE SELECTIVE POUR SERVICE DE MESSAGERIE INSTANTANEE AU SEIN D&amp;rsquo;UN RESEAU DE TELECOMMUNICATION TEL QUE LE RESEAU INTERNET
WO2005006684A1 (fr) Dispositif et procede de traitement de donnees de presence
EP1279298B1 (fr) Dispositif de supervision de terminaux
EP2843923A2 (fr) Dispositif et procédé d&#39;enrichissement d&#39;une communication
EP1517497B1 (fr) Serveur de profil et application aux réseaux de communication
FR2835673A1 (fr) Equipement d&#39;automatisme communiquant par messagerie instantanee
Karunamurthy et al. A Novel web service for presence and its implementation in an IETF Simple protocol environment
WO2009007585A1 (fr) Envoi de messages par mandat
FR3005541A1 (fr) Procede de gestion d&#39;un service de messagerie
WO2007012657A1 (fr) Systeme d&#39;echange de donnees informationnelles specifiques entre deux sites web, procede et programme d&#39;ordinateur correspondants
EP1312196A2 (fr) Serveur d&#39;intermediation pour acces aux differents services disponibles a travers le reseau internet
WO2004034295A2 (fr) Dispositif pour gerer des informations de presence d’utilisateurs issues d’une pluralite de systemes de gestion de presence.
FR2887718A1 (fr) Dispositif et procede pour realiser l&#39;interface entre un equipement informatique et un serveur http
FR2898005A1 (fr) Dispositif et procede de gestion de messages pour messagerie instantanee

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase