Domaine technique

L'invention se rapporte à un procédé de gestion d'une invitation à participer à une conférence ; la conférence impliquant plusieurs dispositifs de traitement de données reliés par l'intermédiaire d'un réseau de communication.

L'invention vise tout particulièrement un procédé de gestion d'une pluralité d'invitations reçues par un même dispositif, les invitations reçues ayant pour objet une création d'une même conférence. Les dispositifs visés ci-dessus sont équipés de moyens de communication pour communiquer avec un réseau de communication. Ces dispositifs sont équipés de modules clients respectifs de manière à échanger des messages lors d'une conférence. Un dispositif est par exemple un ordinateur personnel de type PC, une tablette, un téléphone, etc. Etat de la technique

Rappelons qu'une conférence est un lieu d'échanges où chaque message émis depuis un dispositif est diffusé à un ensemble de dispositifs connectés à la conférence. La conférence est constituée de "participants", à savoir les utilisateurs finaux qui s'échangent des messages entre eux dans le cadre de la conférence.

Des outils de messagerie, via les outils logiciels de communication SIMPLE IM (sigle anglo-saxon de « Session Initiation Protocol for Instant Messaging and Présence Leveraging Extensions » et de « Instant Messaging ») et CPM (sigle anglo-saxon de « Converged IP Messaging »), tels qu'ils sont définis par l'organisme de standardisation OMA (sigle anglo-saxon de « Open Mobile Alliance »), permettent de réaliser des conférences entre plusieurs modules clients présents sur les dispositifs. La mise en œuvre de conférences par de tels outils logiciels repose sur un nœud central dans le réseau d'un opérateur de télécommunications, à savoir un module de création de conférence (le plus souvent désigné par l'expression anglo-saxonne "Controlling Function" par l'homme du métier).

Pour créer une conférence, un module de création de conférence crée une instance de conférence mettant en relation des modules clients. Les différents participants peuvent alors échanger des messages.

Le principe de fonctionnement est le suivant :

- Un module client transmet une demande de création d'une conférence au module de création de conférence de son opérateur ; la demande inclut une liste de modules clients invités ;

- Le module de création de conférence crée ensuite une instance de conférence et transmet une invitation à chacun des modules clients invités ; un identifiant de conférence est créé.

- les modules clients invités qui acceptent l'invitation se retrouvent ensuite connectés à l'instance de conférence et deviennent des participants de la conférence.

- Enfin, chaque participant souhaitant communiquer envoie son message à l'instance de conférence géré par le module de création à l'origine des invitations, qui le transmet à l'ensemble des autres participants. Lorsque l'identifiant de conférence est créé, celui-ci peut être conservé par le module client ainsi que la liste des participants pour un usage futur.

Les participants peuvent quitter la conférence à tout moment.

Les règles du cycle de vie de la conférence peuvent varier selon le service. Par exemple, pour économiser les ressources réseaux, l'opérateur hébergeant la conférence peut décider, suite à une certaine période d'inactivité, à savoir une absence d'échange de messages, pendant un certain temps défini par l'opérateur, de suspendre la conférence, voire de la supprimer. Sur reprise d'activité, à savoir lorsqu'un utilisateur souhaite émettre un message, le participant peut demander à ce qu'une instance de conférence relative à la même conférence soit récréée, afin de remettre en relation l'ensemble des participants à la conférence qui a été supprimée. Dans le cas où l'opérateur a supprimé l'instance de conférence, une nouvelle instance de conférence relative à la conférence supprimée doit être recréée. La procédure précédemment décrite se remet alors en place. Lors de cette procédure, le module client réutilise l'identifiant de conférence qu'il a mémorisé pour créer une nouvelle instance de cette même conférence. Un constat est que toute demande de création d'une conférence faite par un module client se fait auprès du module de création de l'opérateur qui gère le module client. Ce mode de fonctionnement est basé sur une politique des opérateurs indiquant qu'un participant peut démarrer une instance de conférence uniquement dans le réseau de son propre opérateur. Dans cette configuration, une instance de conférence peut être recréée chez un opérateur différent de celui où l'instance avait été initialement créée. Il en résulte un problème lié à la réception possible, par un même module client, d'une pluralité d'invitations à participer à la même conférence émise depuis plusieurs modules de création distincts. Pour éviter une gestion chaotique, une règle commune est nécessaire pour que les clients utilisent la même instance de conférence pour leurs échanges de message. Une solution consiste à se baser sur l'ordre d'arriver des invitations. Par exemple, un module client sélectionne la première invitation reçue et ne prend pas en compte les suivantes. Cependant, se baser sur l'ordre d'arrivée des invitations, comme usuellement pratiqué aujourd'hui, n'est pas dans les faits toujours suffisant. En effet, l'ordre d'arrivée des invitations peut être différent pour les participants du fait d'aléas de transmission et de chemins réseau différents pour chaque participant. Cet inconvénient n'est pas surmonté à ce jour. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.

L'invention

A cet effet, selon un aspect fonctionnel, l'invention a pour objet un Procédé de gestion d'une invitation à participer à une conférence impliquant plusieurs dispositifs de traitement de données communiquant entre eux via un réseau de communication, les dispositifs étant aptes à requérir la création d'une conférence auprès de modules de création de conférence respectifs, les modules de création étant aptes à transmettre des invitations respectives à participer à la conférence, caractérisé en ce qu'il comprend une étape d'ajout, par les modules de création, de codes alphanumériques dans les invitations, respectivement, et en ce qu'un dispositif recevant au moins deux invitations relatives à une même conférence réalise les étapes suivantes :

- une étape de réception de la pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs,

- une étape de comparaison des codes reçus et,

- une étape de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

L'invention permet de gérer des conflits entre invitations relatives à une même conférence reçues par un même module client et issues d'une pluralité de modules de création de conférence distincts. Pour cela, l'invention propose un mécanisme permettant de définir sans ambiguïté quelle doit être l'invitation à considérer parmi la pluralité d'invitations reçues, ce indépendamment à la fois des aléas de transmission et des chemins d'accès par lesquels sont acheminés les invitations.

Selon un mode de mise en œuvre particulier de l'invention, une création initiale d'une conférence fait l'objet d'une invitation initiale qui ne comprend pas de code alphanumérique. Suite, par exemple, à une suppression de la conférence, les invitations suivantes ayant pour objet une re-création de la conférence relative à la même conférence incluent ledit code. De cette manière, l'insertion du code alphanumérique s'associe ainsi explicitement à l'acte de recréation d'une conférence passée qui a par exemple été supprimée, clôturée ou suspendue, ou plus généralement qui n'est plus active.

Selon un mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le code est issu d'une fonction mathématique choisie de telle sorte que les codes générés par au moins deux modules relativement à une même conférence sont différents. La fonction mathématique utilisée est la même pour tous les participants à la conférence. De cette manière, lorsque deux modules clients reçoivent plusieurs invitations relativement à une même conférence, une comparaison de codes et l'application d'une règle donnée permettent de sélection une invitation parmi l'ensemble des invitations reçues. La règle est par exemple la sélection de l'invitation ayant le code alphanumérique le plus élevé, ou le code le plus petit, etc.

A noter qu'il existe plusieurs fonctions mathématiques permettant de générer des codes alphanumériques et que la fonction utilisée peut être différente d'une conférence à une autre. Les fonctions mathématiques sont mises en œuvre par le biais de programmes apte à générer des codes, le plus souvent des codes aléatoires. Selon une variante de ce mode de mise en œuvre, le code est un code aléatoire. Une fonction connue est par exemple celle décrite dans le document RFC 4122 de l'IETF (sigle anglo-saxon de « Internet Engineering Task Force ») proposant une génération de code de 128 bits

Selon un second aspect fonctionnel, l'invention a trait à un procédé de gestion, par un dispositif, d'une pluralité d'invitations à participer à une même conférence issues de modules de création de conférence respectifs, caractérisé en ce qu'il comprend au niveau du dispositif : - une étape de réception de la pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs,

- une étape de comparaison des codes reçus, et - une étape de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

Selon un mode de mise en œuvre particulier de l'invention, l'étape de réception s'effectue sur une plage temporelle préalablement fixée. Cette plage temporelle a pour origine la réception d'une invitation et une durée fixée au préalable par exemple 10 secondes. De cette manière, l'étape de comparaison s'effectue à l'expiration de cette plage temporelle.

Selon un autre aspect fonctionnel, l'invention a trait à un procédé de gestion d'une demande de création d'une conférence impliquant plusieurs dispositifs de traitement de données communiquant entre eux via un réseau de communication, les dispositifs étant aptes à requérir la création d'une conférence auprès de modules de création de conférence respectifs, un module étant apte à transmettre au moins une invitation à participer à la conférence, caractérisé en ce qu'il comprend, dans le module de création, une étape d'ajout d'un code alphanumérique dans l'invitation, - une étape de transmission de l'invitation incluant le code à destination de dispositifs invités à participer à la conférence.

Selon un aspect matériel, l'invention a trait à un Système de gestion d'une invitation à participer à une conférence impliquant plusieurs dispositifs de traitement de données entre eux via un réseau de communication, les dispositifs comprenant des modules de création respectifs aptes à requérir la création d'une conférence auprès de modules de création de conférence respectifs, les modules de création comprenant un module de transmission apte à transmettre une invitation à participer à la conférence, caractérisé en ce que les modules de création comprennent en outre un module d'ajout d'un code alphanumérique dans une invitation à transmettre, et en ce qu'un dispositif comprend

Un module de réception d'une pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs,

Un module de comparaison des codes reçus et

Un module de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

Selon un autre aspect matériel, l'invention à trait à un module de création d'une conférence impliquant plusieurs dispositifs de traitement de données communiquant entre eux via un réseau de communication, le module comprenant un module de transmission apte à transmettre une invitation à participer à la conférence à des participants, caractérisé en ce qu'il comprend,

- un module d'ajout d'un code alphanumérique dans l'invitation, - un module de transmission de l'invitation incluant le code à destination des dispositifs des participants invités à participer à la conférence.

Le lieu de création du code alphanumérique importe peu. Ce lieu peut être par exemple, le module de création, ou le dispositif sur lequel se trouve le module client à l'origine de la demande création, ou tout autre dispositif du réseau.

Selon un autre aspect matériel l'invention a trait à un dispositif caractérisé en ce qu'il comprend :

- Un module de réception d'une pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs,

Un module de comparaison des codes reçus et - Un module de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

Enfin, selon un autre aspect matériel, l'invention a également trait à un programme d'ordinateur apte à être mis en œuvre sur un module tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur réalise les étapes du procédé défini ci-dessus à savoir une étape d'ajout d'un code alphanumérique dans l'invitation, une étape de transmission de l'invitation incluant le code à destination de dispositifs invités à participer à la conférence.

Enfin, selon un autre aspect matériel, l'invention a également trait à un programme d'ordinateur apte à être mis en œuvre sur un module tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur réalise les étapes du procédé défini ci-dessus à savoir :

- une étape de réception de la pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs,

- une étape de comparaison des codes reçus, et

- une étape de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés sur lesquels :

La figure 1 représente un système informatique dans lequel l'invention peut être mise en œuvre selon un mode de réalisation. La figure 2 est une vue schématique d'échanges de messages selon le mode de réalisation décrit en référence à la figure 1. La figure 3 est un algorithme détaillant une étape décrite en référence à la figure 2, étape qui a trait à la gestion de la réception par un même dispositif (sous-entendu module client) d'une pluralité d'invitations relatives à une même conférence. Description détaillée d'un exemple de réalisation illustrant l'invention

La figure 1 représente un système des gestion SYS comprenant, dans notre exemple, trois dispositifs de de traitement de données (D1,D21,D23). Ces trois dispositifs sont équipés de processeurs respectifs et de mémoires respectives pour le traitement de données. Les dispositifs sont également équipés de ressources physique et logicielles pour communiquer entre eux par le biais d'au moins un réseau de communication RES. Dans notre exemple, le réseau de communication est le réseau Internet.

Dans notre exemple, parmi les trois dispositifs, un dispositif est géré par un premier opérateur de télécommunications OP1, et les deux autres par un second opérateur OP2.

Les dispositifs sont équipés de modules clients MC1, MC21, MC22 respectifs aptes à requérir la création d'une conférence et à gérer l'échange de messages entre les modules clients.

Chaque opérateur OP1 et OP2 dispose de son propre module de création de conférence MConf1 et MConf2, respectivement.

Dans cette configuration, le premier module client MCI fait appel au premier module de création de conférence MConfl, et les modules clients MC21 et MC22 font appel au second module de création de conférence MConf2.

On fait ici l'hypothèse que le premier module client MC1 requiert la création d'une conférence dont les participants sont les trois dispositifs, sous- entendus les trois modules clients.

Une demande de création d'une conférence selon le principe de l'invention s'effectue de la façon suivante. Une première phase initiale PH1 a trait à la création d'une conférence. Sur la figure 2, les étapes relatives à cette première phase sont référencées ET1n (n=1 à 4).

Lors d'une première étape ET11, le premier module client MC1 requiert une demande de création d'une conférence au premier module de création de conférence MConfl de son opérateur.

La demande visée ci-dessus inclut, entre autres, au moins une liste de dispositifs invités à participer à la conférence. Une liste inclut par exemple des identifiants URI (sigle anglo-saxon de Uniform Resource Identifier) du type sip:b@mno_B.com et sip:c@mno_C.com (cf. annexe 1).

Ensuite, le premier module de création MConfl reçoit la demande de création et gère la création de la conférence. Pour cela, le premier module créé une instance de conférence.

Suite à la création de l'instance, lors d'une troisième étape ET13, le premier module MConfl transmet une invitation à chaque dispositif identifié dans la demande de création issue du premier dispositif.

Dans notre exemple, cette invitation initiale ne comprend pas de code alphanumérique conformément au procédé. En effet, la phase initiale de création de la conférence ne nécessite pas de code alphanumérique car la probabilité de recevoir plusieurs invitations pour initier une conférence, en particulier une première instance de conférence, est très faible. Le risque de conflits entre invitations est donc très faible. Néanmoins, un code aurait pu être utilisé.

Ensuite, les modules clients MC21 et MC23 reçoivent des invitations respectives. A noter que, dans notre exemple, les modules ne reçoivent qu'une seule invitation lors de cette première phase.

Lors d'une quatrième étape ET14, les utilisateurs acceptent ou non l'invitation. Dans notre exemple, les utilisateurs acceptent. A ce stade, la conférence est créée. Les utilisateurs peuvent communiquer.

On suppose ici que, plus tard, la conférence est supprimée suite à une période d'inutilisation. Suite à la suppression, des utilisateurs vont demander à re-créer une autre instance de conférence relative à la conférence qui a été supprimée. Supposons que ces utilisateurs sont les utilisateurs du premier dispositif D1 et du deuxième dispositif D22.

Une re-création d'une autre instance de la conférence supprimée a lieu lors d'une deuxième PH2. Sur la figure 2, les étapes relatives à cette deuxième phase sont référencées ETlk (n=1 à 3).

Le procédé de re-création de la conférence est le suivant :

Lors d'une première étape ET21, le premier module client MCI requiert une demande de re-création de la conférence au premier module de création de conférence MConfl de son opérateur. Dans notre exemple, la demande de création concerne plus particulièrement une demande de re-création d'une instance de conférence relative à une conférence qui a été supprimée.

Lors d'une première étape ET21bis, qui peut se produire simultanément à la première étape ET21 ou à un instant différent, le deuxième module client MC21 requiert aussi une demande de re-création de la même conférence au deuxième module de création de conférence MConf2 de son opérateur.

A ce stade du procédé, le premier module de création MConfl ainsi que le deuxième module de création MConf2 reçoivent les demandes de re-cration et gèrent respectivement ces re-créations.

Suite à la réinitialisation de l'instance, lors d'une deuxième étape ET22/ET22bis, les modules MConf1 et MConf2 transmettent une invitation à chaque dispositif identifié dans les demandes de re-création issues du premier dispositif et du second dispositif.

En l'espèce, - le premier module de création MConf1 transmet, lors d'une deuxième étape ET22, une invitation à la fois au module client MC21 et au module client MC22 ;

- le deuxième module de création MConf2 transmet, lors d'une deuxième étape ET22bis, une invitation à la fois au module client

MCI et au module client MC22 ;

Selon l'invention, les invitations incluent des codes alphanumériques respectifs.

A noter que le code peut être créé indifféremment par le module client ou le module de création de conférence ou toute autre entité apte à calculer un code et à le fournir au module de création de conférence.

Si le code est créé par le module client, ce dernier inclut le code dans la demande de re-création à l'étape ET21/ET21bis.

L'annexe 1 donne un exemple d'invitation de type « INVITE » conformément au standard RFC 3261. Dans cet exemple, un attribut « restart » comprend le code alphanumérique ajouté dans l'invitation et utilisé lors d'une étape de comparaison qui sera décrite ci-après.

A ce stade,

- le module client MC1 reçoit une invitation à participer à la conférence

- le module client MC21 reçoit une invitation à participer à la conférence

- le module client MC22 reçoit deux invitations résultant des étapes ET22/ET22bis décrites ci-dessus. Dans cette configuration, un même module client, dans notre exemple le module MC22, reçoit deux invitations relatives à une même conférence. Lors d'une troisième étape ET23, pour sélectionner une invitation, le module client MC22 compare les codes des deux invitations reçues, et sélectionne une des deux invitations en fonction d'une règle prédéfinie. Une règle consiste par exemple à comparer les deux codes et à sélectionner l'invitation transportant le code le plus élevé. D'autres règles peuvent bien évidemment être utilisées.

Les modules recevant des invitations liées à une re-création d'une conférence appliquent la même règle de sélection de code.

La figure 3 donne des précisions sur la façon dont les modules gèrent les invitations reçues, par exemple le module MC22 lors de la troisième étape ET23. Dans notre exemple, cette troisième étape ET23 se décompose en 5 sous- étapes ET23-j (j=1 à 5).

Lors d'une première étape ET23-1 (RCP-INV), le module MC22 reçoit une invitation. Lors d'une deuxième étape ET23-2 (Nb>1 ?), le module vérifie si d'autres invitations ont été reçues relativement à une même conférence.

Dans la négative, lors de l'étape ET23-3 (OK), le module client accepte ou non l'invitation.

Dans l'affirmative, le module client compare les codes relatifs aux invitations reçues lors d'une étape ET23-4 (COMP). Dans notre exemple, le module sélectionne l'invitation ayant le code le plus élevé lors de l'étape ET23-5 (SEL).

Lorsque tous les modules clients invités ont sélectionnés une invitation, une instance de conférence est créée. Selon une variante possible, lorsqu'un module de création reçoit une invitation, un compteur temporel (ou horloge) est activé pendant une plage temporelle T ayant pour origine un instant tl correspondant par exemple à l'instant de réception d'une invitation. La durée T de cet intervalle de temps est fixée au préalable.

Dans cette configuration, lors de l'étape ET23-1, le module client MC22 reçoit plusieurs invitations. Ensuite, à l'issue de la durée T visée ci-dessus, l'étape ET23-2 est réalisée.

Pour la réalisation de l'invention, les modules de création MConf1 et MConf2 disposent des modules suivants : un module d'ajout d'un code alphanumérique dans l'invitation, un module de transmission de l'invitation incluant le code à destination des dispositifs des participants invités à participer à la conférence.

Le dispositif dispose quant à lui des modules suivants :

Un module de réception d'une pluralité d'invitations à participer à une même conférence, les invitations incluant des codes alphanumériques respectifs, - un module de comparaison des codes reçus et un module de sélection de l'invitation à prendre en considération en fonction du résultat de l'étape de comparaison.

Précisons ici que le terme module utilisé dans la présente demande peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous- programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Annexe 1

INVITE sip:conf-fact@mno A.com SIP/2.0

Via: SIP/2.0/UDP pca.mno_A.com;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Conf Factory <sip:conf-fact@mno A.com>

From: A <sip:a@mno A.com>:tag=2131302775

Call-ID: 563b4c76e66712

CSeq: 203048 INVITE

Contact: <sip:a@pca.mno A.com>:+g.oma.sip-im

Require: recipient-list-invite

Supported: eventlist, timer

Allow: INVITO,ACK,CANCEL,BYE,REFER^OTIFY,UPDATE,OPTIONS User-Agent: IM-client/OMA1.0

Accept-Contact: *;+g.oma.sip-im

P-Preferred-Identity: < sip:a@mno A.com>

Content-Type: multipart/mixed; boundary="boundary42" Contribution-ID: defgh-5678-1234-90abcd-cdef01234567; restarts 134651

-boundary42

Content-Type: application/sdp

(A's SDP not shown)

~boundary42

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

Content-Length: 337

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list>

<entry uri="sip:b@mno B.com" />

<enlty uri= "sip:c@mno C.com" />

</list>

</resource-lists>

— boundary42