FR2898005A1 - Dispositif et procede de gestion de messages pour messagerie instantanee - Google Patents

Abstract

L'invention concerne un dispositif client (100) comportant des moyens (18) adaptés à recevoir, dans un réseau de télécommunications (2), des messages en provenance d'un premier dispositif client (7) selon un premier protocole de communication et d'au moins un deuxième dispositif client (6) selon un deuxième protocole de communication différent dudit premier protocole de communication, ledit dispositif client (100) étant caractérisé en ce qu' il comporte en outre des moyens de relais (20) pour relayer au moins ledit premier message émis par ledit premier dispositif client (7) audit deuxième dispositif client (6), lesdits moyens de relais (20) étant adaptés à :- recevoir au moins ledit premier message en provenance dudit premier dispositif client selon ledit premier protocole de communication;- extraire le contenu dudit premier message ;- encapsuler ledit contenu dans au moins un deuxième message; et- envoyer ledit deuxième message audit au moins un deuxième dispositif client (6) selon ledit deuxième protocole de communication.

Description

Titre de l'invention Dispositif et procédé de gestion de messages pour

messagerie instantanée.

Domaine de l'invention La présente invention concerne le domaine des applications de messagerie instantanée mises en oeuvre dans des réseaux de télécommunications. De façon connue, ces applications permettent d'établir des conférences entre deux ou plusieurs dispositifs clients sur des terminaux, tels qu'ordinateurs, téléphones mobiles, PDAs (Portable Digital Assistants), ou autres. L'invention concerne plus particulièrement l'interconnexion de dispositifs clients pour réaliser de telles conférences, ces dispositifs clients 15 mettant en oeuvre des protocoles de communication différents.

Art antérieur Le document WO 03 094011 décrit un système de messagerie instantanée qui, pour faire dialoguer différents clients, propose d'utiliser 20 un protocole et des serveurs dits universels conformes à un même standard, par exemple XML (Extensible Markup Language). En conséquence, chaque serveur du réseau doit incorporer un serveur de messagerie universel afin de rendre ce service. Le document US 6 549 937 B1 décrit un système de 25 communication multi-protocole, permettant à plusieurs clients utilisant des protocoles de communication différents de communiquer entre eux, au moyen d'une plateforme de conversion de protocole implémentée par les serveurs du réseau. Cette solution a pour inconvénient de nécessiter l'intégration de 30 la plateforme de conversion dans les serveurs du réseau.

Il existe actuellement des clients de messagerie instantanée, tels que TrillianTM, capables de se connecter à des serveurs de messagerie instantanée différents tels que MSN ou ICQ , en utilisant des protocoles de communication différents, autrement dit incompatibles entre eux.

La figure 1 décrit, à titre d'exemple et conformément à l'état actuel de la technique, un client TrillianTM 1 apte à communiquer, dans un réseau 2 de télécommunications, avec deux clients ICQ 61 et 62 et un client MSN 7, les clients ICQ 61 et 62 (respectivement le client MSN 7) étant directement connectés à un serveur ICQ 3 (respectivement à un serveur MSN 4) du réseau 2. Le client TrillianTM 1 permet à un utilisateur possédant un compte de messagerie instantanée ICQ et un compte de messagerie instantanée MSN , de visualiser, sous une plateforme logicielle unique, ses contacts constitués, dans cet exemple, par le client 61, le client 62 et le client 7. Le client 1 offre en outre la possibilité d'établir des conférences de messagerie instantanée entre des clients utilisant un même protocole de communication, par exemple les clients 61 et 62. Néanmoins, le client 1 ne permet pas de créer de conférences entre des clients de messagerie utilisant des protocoles de communication différents, à savoir dans cet exemple, entre le client MSN 7 et les clients ICQ 61, 62.

Objet de l'invention La présente invention vise à remédier aux inconvénients précités. Elle propose une solution technique permettant de gérer des conférences de messagerie instantanée entre des clients utilisant des protocoles différents, cette solution ne nécessitant aucune modification des serveurs de messagerie impliqués dans ces conférences.

Ces buts sont atteints grâce à un dispositif client comportant des moyens adaptés à recevoir, dans un réseau de télécommunications, des messages en provenance d'un premier dispositif client selon un premier protocole de communication et d'au moins un deuxième dispositif client selon un deuxième protocole de communication différent du premier protocole de communication. Ce dispositif client comporte en outre des moyens de relais pour relayer au moins un premier message émis par le premier dispositif client à au moins un deuxième dispositif client, ces moyens de relais étant adaptés à : - recevoir au moins un premier message en provenance du premier dispositif client selon le premier protocole de communication; -extraire le contenu de ce premier message ; - encapsuler ce contenu dans au moins un deuxième message; 15 et - envoyer le deuxième message à au moins un deuxième dispositif client selon le deuxième protocole de communication. Ainsi, le dispositif client selon l'invention permet de faire 20 communiquer entre eux, deux clients utilisant des protocoles de communication différents. En ce sens, le dispositif client selon l'invention sera dénommé ci-après client multi-protocole . La mise en relation de deux clients utilisant des protocoles différents est assurée par les moyens de relais du dispositif multi-protocole 25 selon l'invention. La solution selon l'invention ne nécessite pas d'apporter de modification au niveau du réseau, contrairement à la solution décrite dans le document US 6 549 937 B1 qui nécessite l'intégration d'une plateforme de conversion.

De plus, les clients participant à la conférence n'ont pas besoin d'être modifiés. Dans un mode particulier de réalisation, le dispositif client selon l'invention peut aussi faire communiquer entre eux des clients utilisant un 5 protocole de communication commun. Ainsi, le dispositif client selon l'invention permet de mettre en relation plusieurs clients : - lorsque le protocole commun de communication n'est pas adapté à réaliser une conférence avec plus de deux clients participants ; ou 10 - lorsque le protocole commun de communication permet de réaliser des conférences avec plus de deux clients participants mais lorsqu'au moins un de ces clients n'est pas adapté à implémenter une fonctionnalité de conférence. Selon une particularité de l'invention, le dispositif client selon 15 l'invention comporte en outre des moyens adaptés à encapsuler un même contenu dans au moins deux messages, et à envoyer un premier de ces messages au premier dispositif client selon le premier protocole de communication et un deuxième message au deuxième dispositif client selon le deuxième protocole de communication. 20 Ainsi, le dispositif selon l'invention permet de diffuser en une seule manipulation un message de même contenu à différents clients utilisant des protocoles de communication non compatibles entre eux. Cette caractéristique n'était rendue possible par aucun des systèmes de messagerie de l'art antérieur précités. 25 Selon une particularité de l'invention, les moyens d'encapsulation du dispositif client selon l'invention sont en outre adaptés à encapsuler dans au moins les premier et deuxième messages un contenu personnalisé en fonction des premier et deuxième dispositifs clients.

Ainsi, dans le cas d'une application d'une conférence par messagerie instantanée, le dispositif client selon l'invention peut envoyer des messages personnalisés aux différents participants, comme par exemple des messages de bienvenue lors de l'initialisation de cette conférence. Dans un mode de réalisation préféré, le dispositif client selon l'invention communique avec au moins un des dispositifs clients via un serveur du réseau de télécommunications. Dans cette architecture de type client/serveur, chaque client est directement relié au serveur auquel il est associé. Ce type d'architecture est préservé dans le cas de la présente invention qui ne nécessite aucune modification au niveau du serveur. Cette caractéristique représente une amélioration vis-à-vis de la solution précitée proposée dans le document WO 03 094011 qui requiert 15 un serveur de messagerie universel dans le réseau. Dans un autre mode de réalisation, certains clients communiquent entre eux sans l'intermédiaire d'un serveur, en utilisant par exemple le protocole SIP/SIMPLE (Session Initiation Protocol, SIP for Instant Messaging and Presence Leveraging Extensions) en cours de 20 normalisation par l'IETF (Internet Engineering Task Force). Dans une application privilégiée de l'invention, les premier et deuxième dispositifs clients sont des clients de messagerie instantanée utilisant des protocoles de communication différents. Dans cette application, le dispositif client selon l'invention permet l'établissement et 25 la gestion d'une conférence entre ces dispositifs clients de messagerie instantanée. Plus précisément, le dispositif client selon l'invention initialise la conférence de messagerie instantanée et assure ensuite le relais des messages entre les différents clients participant à la conférence.

Selon une caractéristique de l'invention, le dispositif client selon l'invention comprend une interface homme-machine permettant à un utilisateur du dispositif de sélectionner des objets ou icônes représentatifs des clients pour établir une conférence de messagerie entre ces clients.

Ainsi, le dispositif client selon l'invention propose une interface homme-machine traditionnelle, du type de celles utilisées dans les systèmes de messagerie instantanée mono-protocole. Selon une autre caractéristique de l'invention, le dispositif client selon l'invention comporte des moyens adaptés à interroger au moins un serveur de présence associé aux dispositifs clients, et à maintenir une liste de présence des dispositifs clients. Ainsi, le dispositif client selon l'invention connaît à chaque instant la liste des clients présents à la conférence. Ce serveur de présence pourrait également fournir des informations concernant la disponibilité de chaque client. Par exemple, le statut ne pas déranger d'un client pourrait rentrer en ligne de compte pour la transmission de messages privés ou autres. De façon connue, dans une architecture de type client/serveur, la fonction serveur de présence peut être implémentée par les serveurs de messagerie auxquels sont connectés les différents clients. Selon une autre caractéristique de l'invention, le dispositif client selon l'invention comporte, en outre : - des moyens destinés à déterminer, à partir d'une convention syntaxique, si le contenu d'un message reçu par le dispositif client selon l'invention est représentatif ou non d'une commande, et - des moyens de traitement de cette commande. A la réception d'un message, le dispositif client multi-protocole selon l'invention est capable de déterminer s'il s'agit d'une commande passée par l'un des utilisateurs participant à la conférence, cette

commande étant conforme à une convention syntaxique devant être respectée par les utilisateurs de ces clients. Par exemple, une telle convention pourrait consister à introduire un identificateur tel qu'un + , au début du contenu de chaque message destiné à être interprété en tant que commande par le dispositif client multi-protocole. Selon l'invention, la commande est ensuite traitée par le dispositif client multi-protocole. Les interfaces homme-machine actuellement utilisées par les clients de messagerie instantanée mono-protocole fournissent des boutons qui génèrent des commandes traitées sur le réseau par le serveur associé aux clients. Les moyens mis en oeuvre par le dispositif client multiprotocole selon la présente invention, permettent de rendre les mêmes services, mais dans un contexte multi-protocole et sans faire intervenir les serveurs de messagerie pour le traitement de ces commandes. Ainsi, le traitement des commandes est centralisé au niveau du dispositif client multi-protocole, sans avoir à passer par une pluralité de serveurs de messagerie instantanée pour le traitement de ces commandes.

Selon une autre caractéristique de l'invention, le dispositif est adapté à envoyer à au moins un des clients, un message contenant au moins une partie d'une liste comportant au moins une commande. Ainsi, tous les clients participant à la conférence peuvent être informés de manière simple, et à n'importe quel moment, des différentes commandes qui sont mises à leur disposition lors de la conférence. Par exemple, au moment de l'initialisation d'une conférence, le dispositif client multi-protocole peut diffuser à l'ensemble des clients participant à la conférence, un message comportant la liste des commandes essentielles.

Ainsi, chaque client n'a pas besoin de connaître a priori ces commandes. De plus, la liste des commandes peut être mise à jour de manière centralisée au niveau du dispositif client multi-protocole selon l'invention.

Selon une autre caractéristique de l'invention, cette commande est choisie parmi: - une requête pour obtenir la liste des premier et au moins un deuxième dispositifs clients; - une requête pour obtenir la liste des clients présents ; - une requête pour quitter la conférence en cours ; -une requête pour obtenir un message d'aide ; - une requête pour faire passer un message privé à un desdits clients ; Ces commandes classiques permettent d'implémenter des fonctionnalités qui rendent la conférence plus lisible par les différents clients participant à la conférence. Voici à titre d'exemple non limitatif, la liste de ces commandes. +list : commande permettant d'obtenir la liste des premier et au moins un deuxième dispositifs clients. +listp : commande permettant d'obtenir la liste des clients actuellement présents à la conférence. +quit : commande permettant de quitter la conférence en cours. +help : commande permettant d'obtenir un message d'aide comprenant des informations essentielles aux participants de la conférence, comme par exemple la syntaxe à utiliser pour passer des commandes ainsi que la liste des commandes disponibles. +priv : commande permettant de passer un message privé à un des clients, évitant toute diffusion auprès des autres clients. D'autres commandes pourraient être implémentées, telle qu'une 30 requête permettant de récupérer des informations concernant le profil

d'un des clients participant à la conférence. Par exemple, la syntaxe de cette commande pourrait être la suivante : +getinfo <nickname>, où nickname est le nom (ou identifiant) de l'utilisateur associé au client dont les informations sont à récupérer.

Cette commande peut être utilisée pour contourner des systèmes de privauté. Considérons une session de conférence comprenant deux clients MSN et un dispositif client multi-protocole selon l'invention. Dans le cas où un client MSN a refusé l'accès à ses données personnelles à l'autre client MSN , cet autre client MSN pourra obtenir ces données en s'adressant au dispositif client multi-protocole selon l'invention. L'invention vise également un procédé de gestion de messages dans un réseau de télécommunications, comportant : - une étape de réception d'au moins un premier message en provenance d'un premier dispositif client selon un premier protocole de 15 communication ; - une étape d'extraction du contenu de ce message ; - une étape d'encapsulation de ce contenu dans au moins un deuxième message ; et - une étape d'envoi du deuxième message à au 20 moins un deuxième dispositif client selon un deuxième protocole de communication différent du premier protocole de communication. Les avantages et réalisations particulières de ce procédé sont les mêmes que ceux associés au dispositif client selon l'invention, décrits ci-avant. 25 Dans un mode préféré de réalisation, les différentes étapes du procédé de gestion de messages sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant 30 susceptible d'être mis en oeuvre dans un ordinateur, ce programme

comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de gestion de messages tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur 10 tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen 15 d'enregistrement magnétique, par exemple une disquette ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres 20 moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en 25 question.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins qui

en illustrent un exemple de réalisation dépourvu de tout caractère limitatif et dans lesquels : - la figure 1 déjà décrite, représente des clients de messagerie instantanée de l'état actuel de la technique, dans leur environnement ; - la figure 2 illustre un système d'interconnexion entre deux clients utilisant des protocoles de communication différents et un dispositif client multi-protocole selon l'invention, dans un mode particulier de réalisation ; - la figure 3A représente les étapes mises en oeuvre par le dispositif client selon l'invention de la figure 2, lors de la diffusion d'un message de même contenu aux autres clients de la figure 2 ; - la figure 3B représente les étapes mises en oeuvre par le dispositif client selon l'invention, lors de la réception d'un message en provenance d'un client ; - la figure 4 illustre des échanges de message entre les clients et le dispositif client selon l'invention de la figure 2 ; et - la figure 5 représente, à titre d'exemple, une liste de présence et/ou disponibilité des clients participant à la conférence, gérée par le dispositif client selon l'invention.

Description détaillée d'un mode de réalisation L'invention va maintenant être décrite dans une application privilégiée d'un système de messagerie instantanée. La figure 2 illustre, à titre d'exemple, un système d'interconnexion entre deux clients de messagerie instantanée (par exemple, un client ICQ 6 et un client MSN 7) et un dispositif client 100 selon l'invention, dans un mode particulier de réalisation. Le client ICQ 6 (respectivement le client MSN 7) est relié au serveur ICQ 3 (respectivement au serveur MSN 4) dans un réseau de

télécommunications 2 comportant en outre un serveur de présence 5 relié aux serveurs de messagerie instantanée 3 et 4. Dans l'exemple décrit ici, le dispositif client 100 selon l'invention est constitué par un ordinateur comprenant une unité centrale (CPU) 20, un système de mémoire 10 et un système de bus 9 permettant de relier les différents composants et notamment l'unité centrale 20 au système de mémoire 10 et à un écran 14, un clavier 15, une souris 16, un disque dur 19 et à des moyens de communication constitués par une interface réseau 18 et un modem 17. Le système de mémoire 10 comprend de la mémoire vive (RAM) 11, de la mémoire morte (ROM) 12, un BIOS (Basic Input/Output System) 13. De façon connue, l'utilisateur interagit avec le dispositif client notamment par l'écran 14, le clavier 15 et la souris 16 précités, par l'intermédiaire d'une interface homme-machine. Dans l'exemple décrit ici, la mémoire morte 12 constitue un support d'enregistrement qui mémorise un programme d'ordinateur PG conforme à l'invention, apte à mettre en oeuvre, lorsqu'il est exécuté par l'unité centrale 20, les étapes du procédé de gestion de messages conforme à l'invention, ce procédé étant représenté sous forme d'organigrammes aux figures 3A et 3B.

Etablissement d'une conférence Nous supposons qu'un utilisateur 23 du dispositif client multiprotocole 100 conforme à l'invention, souhaite établir une conférence de messagerie instantanée entre un utilisateur 21 utilisant le premier client de messagerie 6 et un utilisateur 22 utilisant le deuxième client de messagerie 7. Dans l'exemple décrit ici, l'utilisateur 23 sélectionne, dans un premier temps, au moyen de l'interface homme-machine, des objets représentatifs des clients 6 et 7 (autrement appelés contacts), et dans un deuxième temps, l'utilisateur 23 sélectionne dans un menu une fonction

de type conférence qui permet d'établir la conférence de messagerie instantanée entre les dispositifs clients 100, 6, 7. Par exemple, une fenêtre de conférence dans laquelle s'inscrit l'historique de la conférence apparaît chez l'utilisateur 23. Cette fenêtre fournit également une liste des contacts préalablement sélectionnés (représentatifs des clients 6 et 7 dans cet exemple) lors de l'établissement de la conférence. La conférence est maintenant établie entre les dispositifs clients 100, 6, 7.

Diffusion d'un message Nous allons maintenant décrire les étapes permettant au dispositif client selon l'invention de diffuser un même contenu de message aux autres clients participant à la conférence.

Dans l'exemple décrit ici, le dispositif client 100 souhaite envoyer un message de bienvenue aux clients 6 et 7. La figure 3A décrit sous forme d'organigramme, les étapes mises en oeuvre par le dispositif client multi-protocole 100, lors de la diffusion d'un message de même contenu aux clients de la figure 2.

Le contenu du message à diffuser est identifié au cours d'une étape E1. Au cours d'une étape E2, ce contenu est encapsulé dans deux messages de bienvenue MI et M2 destinés respectivement au client 7 et au client 6 de la figure 4. A cet effet, le dispositif client 100 utilise les moyens d'encapsulation constitués par l'unité centrale 20 qui met en oeuvre l'étape E2 du procédé selon l'invention. Le dispositif client multi-protocole 100 envoie ensuite au cours d'une étape E4, en utilisant les moyens de communication formés par l'interface réseau 18 et le modem 17, le message MI au client 7 par l'intermédiaire de son serveur associé 4 selon le protocole de communication utilisé par le client 7, et le message M2 au client 6 par

l'intermédiaire de son serveur associé 3 selon le protocole de communication utilisé par le client 6. La diffusion est alors terminée conformément à l'étape E6. Le contenu de ces deux messages MI et M2 est identique et peut, par exemple, inclure un avertissement prévenant les utilisateurs 21 et 22 que tout ce qu'ils enverront à partir de ce moment à l'utilisateur 23 sera diffusé à tous les participants à la conférence. Par exemple, un autre message expliquant qu'ils peuvent obtenir de l'aide spécifique relative au fonctionnement de la conférence, peut leur être également envoyé. Ce message peut, par exemple, informer les utilisateurs participant qu'en tapant la commande +help , ils pourront obtenir des informations sur les commandes disponibles lors de la conférence. Selon une caractéristique de l'invention, les moyens d'encapsulation 20 du dispositif client multi-protocole 100 sont adaptés 15 pour personnaliser le contenu des messages MI et M2. Pour cela, les moyens d'encapsulation 20 implémentent par exemple, une fonction paramétrée qui modifie le contenu des messages MI et M2 à partir de données relatives au profil des utilisateurs 21 et 22 respectivement. 20 Ainsi, lors de l'initialisation d'une conférence, le dispositif client 100 peut adresser des messages de bienvenue personnalisés tels que Bonjour 21 et Bonjour 22 respectivement destinés aux utilisateurs 21 et 22.

25 Réception et traitement d'un message par le dispositif client selon l'invention La figure 3B représente sous forme d'organigramme, les étapes mises en oeuvre par le dispositif client 100 selon l'invention, lors de la réception d'un message en provenance d'un client.

Lors d'une étape [10, l'interface réseau 18 du dispositif client multi-protocole 100 reçoit un message en provenance d'un client. Au cours d'une étape [20, le dispositif client 100 teste, de façon connue, si le client dont provient le message fait partie des clients participant à la conférence en cours. Si le message ne provient pas d'un client participant à cette conférence, il sera traité comme un message banal, selon une étape E30, c'est-à-dire que ce message ne sera ni diffusé aux clients participant à la conférence, ni interprété comme une commande par le client mufti- protocole 100. Dans le cas contraire, c'est-à-dire dans le cas où le client en question est un client participant à la conférence (par exemple le client 7 des figures 2 et 4), le client multi-protocole 100 détermine, au cours d'une étape [40, si le message reçu est une commande, à partir d'une convention syntaxique qui doit être respectée par l'ensemble des clients participant à la conférence. Par exemple, si le contenu du message est précédé du symbole + , il sera interprété par le dispositif client 100 comme une commande. Dans ce cas, le dispositif client multi-protocole 100 selon l'invention, teste lors d'une étape E41 si la commande est une commande connue (ou autorisée). Si la commande est connue (ou autorisée), alors le dispositif client multi-protocole 100 exécute cette commande au cours d'une étape [43.

Si la commande n'est pas une commande connue (ou autorisée), le dispositif client 100 traite cette commande comme un message banal au cours de l'étape E30 telle que décrite précédemment. En variante, lorsque le dispositif client multi-protocole 100 détecte une commande et que celle-ci n'est pas reconnue (ou autorisée) par le dispositif client multi-protocole 100, alors celui-ci met en

oeuvre un algorithme permettant, de façon connue, de détecter éventuellement une erreur de syntaxe et envoie le cas échéant un message d'erreur au client à l'origine de la commande erronée. Si le message reçu par le client 100, n'est pas une commande alors le dispositif client multi-protocole 100 procède à la diffusion du contenu de ce message aux autres clients participant à la conférence. Cette diffusion comprend une étape d'extraction E50 du contenu du message à diffuser, suivie d'une étape d'encapsulation E60 de ce contenu dans un message selon le protocole du client 7 de la figure 4, par exemple. Ce message est ensuite envoyé au client 7, dans cet exemple, selon une étape [70. Les moyens de réception, d'envoi et d'encapsulation sont constitués par les moyens de communication formés par l'interface réseau 18 et le modem 17 du dispositif client 100 selon l'invention, mettant en oeuvre les étapes du procédé décrit ci-dessus.

Échange de messages entre des clients et le dispositif client selon l'invention La figure 4 illustre plusieurs exemples d'échanges de message entre le dispositif client multi-protocole 100 et les deux dispositifs clients 6 et 7 de la figure 2. Considérons un premier cas dans lequel un client participant à la conférence, souhaite passer une commande au dispositif client 100 selon l'invention.

Prenons, à titre d'exemple, le cas où le client 6 souhaite connaître la liste des clients participant à la conférence. A cette fin, le client 6 envoie un message M5 au dispositif client multi-protocole 100 par l'intermédiaire du serveur 3. Le contenu de ce message M5 est +list . Le dispositif client 100 selon l'invention reçoit le message M5 qu'il interprète en tant que commande, car il détecte la présence du symbole

+ dans le contenu +Iist . Le dispositif client 100 traite alors cette commande et envoie en retour au client 6 un message M6 contenant la liste des clients participant à la conférence. Considérons maintenant un deuxième cas, dans lequel un client participant à la conférence envoie unmessage qui cette fois n'est pas une commande, au dispositif client 100 selon l'invention, de manière à le diffuser aux autres clients participant à la conférence. Par exemple, le client 7 envoie un message M3 au dispositif client multi-protocole 100 selon l'invention par l'intermédiaire de son serveur associé 4. Le dispositif client multi-protocole 100 extrait le contenu de ce message, l'encapsule dans un message M4 selon le protocole de communication utilisé par le client 6, puis l'envoie au client 6 via son serveur associé 3. Considérons enfin un troisième cas, dans lequel le dispositif client multi-protocole 100 selon l'invention souhaite diffuser un même contenu de message aux clients 6 et 7 participant à la conférence. Pour cela, le dispositif client 100 encapsule ce même contenu dans deux messages MI et M2 selon les protocoles propres des clients 6 et 7 respectivement. Les messages MI et M2 sont ensuite envoyés respectivement au client 7 via son serveur associé 4 et au client 6 via son serveur associé 3. Les moyens de réception, d'envoi et d'encapsulation sont constitués par les moyens de communication formés par l'interface réseau 18 et le modem 17 du dispositif client 100 selon l'invention, mettant en oeuvre les étapes du procédé décrit ci-dessus.

Présence/disponibilité des dispositifs clients Nous allons maintenant décrire, à titre d'exemple, des moyens mis en oeuvre afin de connaître l'état de présence et/ou de disponibilité des dispositifs clients 6 et 7 de la figure 2.

Comme représenté sur la figure 2, un serveur de présence 5 permettant d'obtenir des informations de présence relatives aux clients 6 et 7 est relié aux serveurs de messagerie instantanée 3 et 4. Dans une alternative, au lieu d'utiliser un serveur de présence 5 pour obtenir des informations de présence relatives aux clients 6 et 7, on utilise deux serveurs (non référencés) associés respectivement aux clients 6 et 7. Le dispositif client multi-protocole 100 selon l'invention comporte des moyens adaptés à interroger les serveurs de présence associés aux serveurs de messagerie instantanée, de manière à obtenir et centraliser des informations de présence des clients, par exemple, pour maintenir une liste de présence L2 des dispositifs clients présents à la conférence. Ces informations de présence peuvent être ensuite relayées aux différents serveurs de messagerie instantanée.

En variante, ces serveurs de présence, pourraient également gérer des informations concernant la disponibilité des utilisateurs 21 et 22 des clients 6 et 7 respectivement. La figure 5 décrit, à titre d'exemple, une table de données T gérée par le client multi-protocole 100 selon l'invention, lui permettant d'obtenir une liste des clients participant à la conférence L1, une liste de présence L2 et/ou une liste de disponibilité L3 des clients de la figure 2. La table de données T est constituée de quatre colonnes. Une première colonne CI répertorie les utilisateurs participant à la conférence (utilisateurs 21 et 22 dans cet exemple).

Une deuxième colonne C2 associe à chaque utilisateur de la colonne CI, le type de client (ou protocole) qu'il utilise. Une troisième colonne C3 associe à chaque utilisateur de la colonne CI son état de présence. Par exemple, on attribue la valeur 0 si l'utilisateur est absent, et la valeur 1 si l'utilisateur est présent.

Une quatrième colonne C4 associe à chaque utilisateur son état de disponibilité. Par exemple, on attribue la valeur 0 si l'utilisateur n'est pas disponible et la valeur 1 si l'utilisateur est disponible. Ainsi à titre d'exemple et conformément à la figure 5, l'utilisateur 21 utilisant le client 6, est présent mais non disponible, tandis que l'utilisateur 22 utilisant le client 7 n'est pas présent et par conséquent est non disponible. La colonne CI constitue la liste L1 des clients participant à la conférence.

L'ensemble formé par les colonnes CI et C3 fournit la liste de présence L2 des clients participant et présents à la conférence. L'ensemble formé par les colonnes CI et C4 fournit la liste de disponibilité L3 des clients participant à la conférence et disponibles.

Claims (12)

REVENDICATIONS

1. Dispositif client (100) comportant des moyens adaptés à recevoir, dans un réseau de télécommunications (2), des messages (M3, M5) en provenance d'un premier dispositif client (7) selon un premier protocole de communication et d'au moins un deuxième dispositif client (6) selon un deuxième protocole de communication différent dudit premier protocole de communication, ledit dispositif client (100) étant caractérisé en ce qu' il comporte en outre des moyens de relais (20) pour relayer au moins ledit premier message (M3) émis par ledit premier dispositif client (7) audit deuxième dispositif client (6), lesdits moyens de relais (20) étant adaptés à: - recevoir (E10) au moins ledit premier message (M3) en provenance dudit premier dispositif client (7) selon ledit premier protocole 15 de communication; - extraire (E50) le contenu dudit premier message (M3); - encapsuler (E60) ledit contenu dans au moins un deuxième message (M4); et - envoyer (E70) ledit deuxième message (M4) audit au 20 moins un deuxième dispositif client (6) selon ledit deuxième protocole de communication.

2. Dispositif client (100) selon la revendication 1, caractérisé en ce qu'il comporte en outre des moyens adaptés à encapsuler un même contenu 25 dans au moins deux messages (MI, M2), et à envoyer un premier desdits messages (MI) audit premier (7) dispositif client selon ledit premier protocole de communication et un deuxième message (M2) audit au moins un deuxième (6) dispositif client selon ledit deuxième protocole de communication. 30

3. Dispositif client (100) selon la revendication 2, caractérisé en ce que lesdits moyens d'encapsulation sont en outre adaptés à encapsuler, dans au moins les premier (MI) et deuxième (M2) messages, un contenu personnalisé en fonction desdits premier (6) et deuxième (7) dispositifs clients.

4. Dispositif client (100) selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit dispositif client (100) communique avec au moins un desdits dispositifs clients (6, 7) via un serveur (3, 4) dudit réseau (2).

5. Dispositif client (100) selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte des moyens pour gérer une conférence de messagerie instantanée entre lesdits premier (7) et deuxième (6) dispositifs clients, ceux-ci étant constitués par des clients de messagerie instantanée.

6. Dispositif client (100) selon la revendication 5, caractérisé en ce qu'il comporte des moyens adaptés à interroger au moins un serveur de présence (5) associé auxdits premier (7) et deuxième (6) dispositifs client, et à maintenir une liste de présence (L2) desdits premier (7) et au moins un deuxième dispositif clients (6).

7. Dispositif client (100) selon l'une quelconque des revendications 5 et 6, caractérisé en ce qu'il comporte, en outre : - des moyens destinés à déterminer, à partir d'une convention syntaxique, si ledit contenu est représentatif ou non d'une commande ; et - des moyens de traitement de ladite commande.

8. Dispositif client (100) selon la revendication 7 caractérisé en ce qu'il est adapté à envoyer ([60) à au moins un des clients (6, 7) un message contenant au moins une partie d'une liste comportant au moins ladite commande.

9. Dispositif client (100) selon l'une quelconque des revendications 7 et 8, caractérisé en ce que ladite commande est choisie parmi : - une requête pour obtenir la liste desdits premier et au moins un deuxième dispositifs clients; - une requête pour obtenir la liste des clients présents ; - une requête pour quitter la conférence en cours ; - une requête pour obtenir des informations concernant un desdits clients ; - une requête pour obtenir un message d'aide ; et - une requête pour faire passer un message privé à un desdits clients.

10. Procédé de gestion de messages dans un réseau de télécommunications (2), caractérisé en ce qu'il comporte : - une étape de réception ([10) d'au moins un premier message (M3) en provenance d'un premier dispositif client (7) selon un premier protocole de communication; - une étape d'extraction ([50) du contenu dudit premier message (M3) ; - une étape d'encapsulation ([60) dudit contenu dans au moins un deuxième message (M4); et - une étape d'envoi ([70) dudit deuxième message (M4) audit au moins un deuxième dispositif client (6) selon un deuxième protocole de communication différent dudit premier protocole de communication.30

11. Programme d'ordinateur (PG) comportant des instructions pour l'exécution des étapes du procédé de gestion de messages selon la revendication 10 lorsque ledit programme est exécuté par un ordinateur.

12. Support d'enregistrement (12) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion de messages selon la revendication 10.