FR2919140A1 - Procede d'echange de messages entre serveur de donnees de session et services clients - Google Patents

Abstract

L'invention concerne un procédé de transmission de données.Selon l'invention, un tel procédé comprend :- une étape de réception d'un message émis par une entité émettrice, ledit message comprenant :- un identifiant de typologie, désignant un type prédéfini ;- une information corrélante, ayant une durée d'existence limitée ;- une étape d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante.

Description

Procédé d'échange de messages entre serveur de données de session et

services clients La présente invention se rapporte au domaine de la gestion de communication et plus particulièrement de session dans un serveur de session partie prenante des interconnexions entre au moins deux dispositifs de communication, une session comprenant d'une part des informations de constitution décrivant la session et des données de session. Par session, on entend, Session d'usage . Une session d'usage se différencie d'une session de communication par le fait qu'elle intègre une notion de service. Pour sa part une session de communication est liée à l'établissement d'une communication entre un utilisateur et un dispositif auquel il est connecté. Ainsi, une session de communication est fermée quand l'utilisateur se déconnecte du dispositif. Au contraire, une session d'usage contient des données persistantes, qui subsistent après que la session de communication ait expiré. Ainsi une session d'usage peut contenir plusieurs sessions de communication, plusieurs identifiants d'utilisateurs, plusieurs données de services. Les sessions d'usage sont par exemple mises en oeuvre dans le cadre d'extensions du couplage téléphonie/informatique dans des réseaux de communication. L'invention concerne la structuration des échanges avec un serveur de session. La présente invention se rapporte plus particulièrement au domaine des transmissions de données dans des systèmes de télécommunication, en particulier des données applicatives, et porte notamment sur la distinction de données au sein du système.

Dans l'état actuel de la technique, un système de télécommunication mettant en oeuvre un procédé d'échange de données de session inclut un réseau de communication principal, tel un réseau téléphonique commuté, apte à mettre en relation un terminal mis à disposition d'un utilisateur avec au moins un premier moyen de communication mis en oeuvre par un premier client, dit client amont, identifié par exemple comme premier destinataire d'une communication qu'aura z initiée l'utilisateur, par exemple en composant un code prédéterminé sur un clavier alphanumérique dont est muni son terminal. Ce premier moyen de communication pourra par exemple être un serveur vocal d'accueil apte à recevoir de la part de l'utilisateur une requête, par exemple verbale, et à orienter cette requête, et donc la communication en cours, vers un deuxième moyen de communication mis en oeuvre par un autre client situé au sein d'un second réseau de communication, dit client aval, lequel aura été identifié par le client amont comme fournissant un service apte à satisfaire la requête formulée par l'utilisateur. Le terme "client" doit être compris ici et dans la suite de l'exposé comme désignant une entité qui sollicite directement ou indirectement les ressources d'une autre entité pour exécuter une tâche, un client pouvant être matérialisé par un serveur autonome, par un groupe de serveurs, une plateforme de services ou par divers éléments répartis au sein de divers moyens de communication inclus dans le système.

Une transmission de données entre les moyens de communication d'un système de communication, tels ceux mis en oeuvre par la demanderesse, induit généralement une identification de ces données afin de s'assurer qu'elles sont transmises conformément à l'exécution d'applications liées à des actions initiées par un utilisateur ou par un élément du système. L'identification de ces données est mise en oeuvre par l'implémentation de sessions de communication, lesquelles sont utilisées tout au long des interactions entre un utilisateur d'un service et les moyens de communication utilisés dans l'exécution de ce service. Le mécanisme de session, bien connu de l'homme du métier, permet, notamment dans la mise en oeuvre de systèmes d'information n-tiers , de conserver des informations afin de permettre une continuité de service. Une telle session est donc susceptible de contenir un important volume de données. Plus généralement, une session possède des informations de constitution et des données qui lui sont propres. Ces données de session sont routées entre les différentes plateformes de services. Une plateforme de service est une entité du réseau de communication en charge de la fourniture de services applicatifs à un client qui en fait la demande. Ainsi, une plateforme de services peut mettre en oeuvre plusieurs services applicatifs qui vont chacun rendre un ou plusieurs services. Des techniques communément employées de l'art antérieur appliquées à ces données de session d'usage permettent de réaliser un échange applicatif de données en deux étapes. En effet, les données applicatives des sessions d'usage contiennent de nombreux paramètres et de nombreuses informations de sorte que l'échange des données d'une session d'usage entre un serveur de données de session (qui gère ces données de manière centralisée) et des plateformes de services (qui ont successivement besoin de ces données) est difficilement réalisable d'un seul tenant. Ainsi, il a été développé un mécanisme permettant d'échanger des données par le biais d'une première phase d'interrogation, par la plateforme de service, d'un serveur de données de session qui permet à la plate forme de demander la structure de la session d'usage puis au moins une deuxième phase de transmission des données de la session en fonction des besoins de la plateforme de service. Ainsi, les échanges entre les plateformes de services et le serveur de données de session sont réduits en fonction des besoins des plateformes. Les travaux des inventeurs ont cependant permis de découvrir que ces transferts applicatifs en deux phases ne résolvent pas tous les problèmes liés à des 20 échanges de données trop volumineuses. En effet, les données de session d'usage (données applicatives et descriptions) sont par exemple routées d'une plateforme de services à une autre via le serveur de données de session en utilisant un mécanisme dit de jeton (également appelé corrélant réseau). Le jeton applicatif et le corrélant réseau (pour 25 les applicatifs de services, véhiculés dans la signalisation réseau) sont donc des informations corrélantes permettant de maintenir un lien entre les appels et les applicatifs de services. Un mécanisme semblable est déjà mis en oeuvre au sein de protocoles réseaux ( anneau à jeton de l'anglais token ring ) et fonctionne sur les 30 couches Physique et Liaison du modèle OSI. î 2919140 4 Ce mécanisme a ingénieusement fait l'objet d'une transposition au niveau applicatif par les inventeurs et a permis d'obtenir un mécanisme de routage des données par le biais d'un corrélant réseau applicatif. Or un tel corrélant réseau ne permet de transporter qu'une quantité limitée de données avant de devenir 5 caduque (en effet, un tel corrélant réseau à une durée de vie limitée, au delà de laquelle il ne peut plus être utilisé). De plus, en l'état actuel, la structuration des échanges en deux phases (structure puis données) combinée à un échange sous la forme de jeton entraîne une complexité importante, tant au niveau des plateformes de service que du 10 serveur de données de sessions. En effet, du point de vue des plateformes de services, la gestion des données de session pèse inutilement sur les performances globales de la plateforme et entraîne des retards de mise en oeuvre des services en tant que tels. Effectivement les missions dédiées aux plateformes de services sont bien 15 d'exécuter des services en tant que tels et non de gérer la pertinence de données en provenance d'un serveur central et d'en déduire le traitement à effectuer. La solution proposée par l'invention ne présente pas ces inconvénients de l'art antérieur. Elle concerne en effet un procédé de transmission de données. Selon l'invention un tel procédé comprend : - une étape de réception d'un message émis par une entité émettrice, ledit message comprenant : - un identifiant de typologie, désignant un type prédéfini ; - une information corrélante, ayant une durée d'existence limitée ; - une étape d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante. Ainsi, dans le cadre d'un réseau de communication qui comprend un serveur de données de session et des plateformes de services, l'invention permet de résoudre les problèmes de performance qui engendrent une insatisfaction des utilisateurs. En effet, la réception d'un message n'est plus réalisée par le dispositif de communication de manière uniforme, à savoir indifférenciée. Au contraire, cette réception dépend de circonstances liées au contenu du message lui-même. Ainsi, par exemple, si le message vise uniquement à obtenir une notification de présence ou d'absence d'un fournisseur de service auquel il est adressé, l'invention permet de réserver un traitement spécifique et accéléré à ce type de message qui ne perturbe pas les traitements applicatifs du fournisseur de service. Ce traitement spécifique peut être réalisé par l'intermédiaire d'une activation d'un dispositif propre à un type auquel le message se conforme et apte à prendre en charge le message. De plus, la durée d'existence de l'information corrélante permet de traiter le message dans le temps imparti. Une telle information permet donc tout à la fois d'équilibrer la charge de l'entité qui traite le message tout en structurant les échanges. Par exemple, un dispositif spécifique peut se voir allouer, dans certains modes de réalisation des charges maximum à ne pas dépasser pour ses traitements et adapter la prise en charge des messages en fonction de cette contrainte. La durée de vie de l'information corrélante (jeton) n'est pas liée à celle du message échangé mais plutôt à celle des établissements d'appels ou des échanges réseaux. Ainsi, on parle d'une durée de vie "limitée" dans la mesure ou cette limitation peut être opérée par les clients ou l'entité de gestion de données de session.

Selon un mode de réalisation particulier de l'invention, le dit procédé comprend, postérieurement à ladite étape d'utilisation une deuxième étape d'émission d'une réponse audit message à destination de ladite entité émettrice, par le biais dudit dispositif spécifique. Ainsi, le procédé selon l'invention permet de répondre au message émis de façon circonstanciée, tant que le corrélant réseau (ou le jeton) est encore en vie, c'est-à-dire, tant que le temps alloué pour répondre au premier message n'est pas dépassé. L'invention permet donc de réduire fortement les temps d'attente et les charges de traitement associées aux messages transmis tout en rationalisant la gestion de ceux-ci.

Selon une caractéristique particulière de l'invention, ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; - des notifications ; des commandes ; des requêtes. Ainsi, l'invention permet de trier les messages en fonction de leur type et de séparer les traitements de ceux-ci. Par exemple, lors de la réception d'un message de type message de service , l'entité qui reçoit ce message par le dispositif dédié peut prendre des mesures pour le traitement rapide de ce message. Par exemple, si l'entité qui reçoit ce message de service est un fournisseur de services, ce fournisseur de services n'est pas obligé de mettre en oeuvre un service applicatif pour répondre à ce message.

En d'autres termes, grâce à l'invention, il n'est pas nécessaire, pour une plateforme de service de mettre en oeuvre des modules applicatifs lourds et consommateurs de ressources pour répondre à des messages de services simples. Ainsi, la réponse peut être réalisée dans des temps très courts, qui ne nécessitent pas l'utilisation de plusieurs jetons. En conséquence, l'invention permet de réaliser des traitements plus rapides des types de message relevant de la compétence de dispositifs spécifiques qui mettent en oeuvre des moyens moins gourmands en terme de mémoire et d'utilisation de puissance de calcul. En effet, l'utilisation de dispositifs spécifiques rapides pour répondre à des messages simples permet de diminuer le nombre d'instances des modules applicatifs à un instant donné et donc d'allouer à chaque instance une quantité de mémoire plus importante et un temps CPU plus long. Selon un mode de réalisation particulier de l'invention, ledit procédé comprend, préalablement à ladite étape de réception, une étape d'obtention d'une information corrélante apte à être utilisée au sein dudit message.

Ainsi, l'invention permet de séquencer le traitement des messages suivant un ordre d'obtention de corrélants réseaux. L'ordonnancement des messages est donc réalisé par le biais des corrélants réseaux qui font office de moyens de régulation des traitements au sein même du réseau de communication et procurent une cohérence de traitement et d'instanciation de modules spécifiques au sein des différentes entités du réseau de sorte qu'il est possible de répartir dynamiquement les charges de traitement dans l'ensemble du réseau. De plus, l'invention offre la possibilité de faire varier la durée de vie du jeton applicatif en fonction du client ou du type de client ou du groupe fermé de clients concerné. Ainsi, en cas de forte charge du système, les clients pourraient sur une base globale, partielle ou individuelle, se voir accorder ainsi un plus ou moins grand degré de liberté et/ou de priorité dans l'utilisation des jetons. Selon une caractéristique particulière de l'invention, ledit dispositif spécifique se présente sous la forme d'au moins un module logiciel client spécifique pour chaque type de message appartenant à ladite typologie. Ainsi, l'invention permet accroît les performances. En effet, la réception et le traitement des messages dépendent du module logiciel utilisé. Ainsi, par exemple, si le message vise uniquement à obtenir une notification de présence ou d'absence d'un fournisseur de service auquel il est adressé, l'invention permet de réserver un traitement spécifique et accéléré à ce type de message. Ce traitement spécifique est réalisé par l'intermédiaire d'une activation d'un module logiciel propre au type auquel le message se conforme. Procédé de transmission de données, caractérisé en ce que ledit au moins un module logiciel comprend une capacité d'échange de données avec au moins un module applicatif apte à rendre un service applicatif requit par ledit message. Ainsi, le procédé selon l'invention permet à des modules logiciels spécifiques de communiquer des informations qu'ils ont récupéré par le biais des messages et de les délivrer au processus applicatifs (modules logiciels applicatifs qui en font la demande. Ainsi, des tels modules logiciels spécifiques, lorsqu'ils sont associés à une interface spécifique, présentent l'avantage dans le cadre d'un mode de réalisation de l'invention, d'autoriser une gestion externe des entrées/sorties et des communications sur le réseau afin de préserver l'applicatif (le logiciel qui rend le service) de la gestion de telles procédures. Ainsi, la cohérence globale du système s'en trouve renforcée tout en permettant une réduction drastique des coûts de développement. Selon un mode de réalisation particulier de l'invention, ledit dispositif spécifique se présente sous la forme interface spécifique pour chaque type de message appartenant à ladite typologie. Une interface peut être définie comme une zone, qui permet de faire la jonction entre deux éléments. En particulier, dans le domaine de l'invention qui comprend des assemblages de composants par exemple, une interface désigne ce que chaque composant a besoin de connaître de l'autre pour interagir avec lui. L'utilisation d'une interface spécifique permettant d'échanger des messages en fonction de la typologie permet donc de structurer les échanges.

Selon une caractéristique particulière de l'invention, ledit dispositif spécifique se présente sous la forme d'un module logiciel client combiné à une interface spécifique. Selon une caractéristique particulière de l'invention, ladite interface spécifique est une adresse IP spécifique pour chaque type de message appartenant 20 à ladite typologie. Ainsi, l'invention permet de résoudre tout à la fois les problèmes liés aux charges de traitement et aux charges mémoires, en allouant expressément un type de message à une adresse IP spécifique. Ainsi l'invention permet d'associer, par exemple à un composant donné, une adresse lP et de diffuser cette information. 25 Tout ce qu'un autre composant peut avoir besoin de connaître de celui-ci est son adresse IP. Selon un mode de réalisation particulier de l'invention, ladite interface spécifique se présente sous la forme d'un port spécifique d'une adresse 1P. Ainsi, l'invention permet de résoudre tout à la fois les problèmes liés aux 30 charges de traitement et aux charges mémoires, en allouant expressément un port spécifique d'une même adresse W à un type de message. Ce mode de réalisation présente également l'avantage de ne pas nécessiter de multiples adresses pour une même entité du réseau. Par exemple, Une adresse, et notamment les adresses IP, comprennent deux parties :un identifiant de l'entité (ordinateur) connecté au réseau et un port, permettant de distinguer les sources des données. Par exemple pour une adresse IP : 192.168.1.10 il y a plusieurs ports associables en fonction de l'applicatif. L'invention permet un emploi nouveau de ce mécanisme de port dans la structuration de l'échange de messages. L'invention concerne également un dispositif de transmission de données, Selon l'invention, un tel dispositif comprend : - des moyens de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini ; une information corrélante, ayant une durée d'existence limitée ; - des moyens d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit au moins un message pendant ladite durée d'existence de ladite information corrélante. Dans un mode de réalisation particulier de l'invention, un tel dispositif peut se présenter sous la forme d'une entité de gestion de données de session.

Dans un autre mode de réalisation de l'invention, un tel dispositif peut se présenter sous la forme d'une plateforme de services. Selon un autre aspect, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et comprenant des instructions de code de programme pour l'exécution du procédé de transmission de données tel que décrit précédemment. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 est un diagramme de blocs décrivant le principe du procédé de transmission de données selon l'invention ; la figure 2, est un diagramme de blocs présentant le principe de transfert de session selon l'art antérieur ; la figure 3 présente un diagramme de séquence présentant le principe de transfert de session en utilisant un serveur de données de session ; - la figure 4 décrit une architecture simplifiée d'un serveur de gestion de données de session selon l'invention ; - la figure 5 est un diagramme de séquence présentant le principe de transfert de session en utilisant un serveur de données de session et un dispositif spécifique selon un mode de réalisation de l'invention. L'invention propose une méthode de gestion des messages échangés entre des entités d'un réseau de communication comprenant des plateformes de gestion de données de session et des plateformes applicatives. On rappelle à toute fin utile qu'une tel réseau mis en oeuvre par la demanderesse peut notamment être destiné à s'interfacer avec un réseau téléphonique commuté classique, permettant par exemple à un utilisateur d'accéder à des services vocaux. On rappelle également que ce type de réseau peut être utilisé pour rendre à la fois des services vocaux en lien avec un réseau téléphonique commuté et que les mêmes plateformes applicatives peuvent, notamment grâce au procédé de l'invention, être utilisées pour rendre des services de type vidéo ou encore des services web, sans qu'il soit nécessaire de procéder à des développement de plateformes de services spécifiques. De plus, le procédé selon l'invention permet également d'envisager l'utilisation optimisée de plusieurs canaux de média en parallèle (voix/web, voix/vidéo, vidéo/web, vidéo/voix/web) pour rendre un même service à l'utilisateur. L'invention propose donc une méthode de gestion spécifique des messages échangés entre les entités applicatives du réseau. On rappelle qu'un tel réseau comprend une entité de gestion de données de session d'usage liées à un ou plusieurs services à rendre à un client qui en fait la demande et que cette entité de gestion de données de session comprend des moyens permettant une transmission étagée des données applicatives d'une session. Une telle entité de gestion de données de session permet de gérer les sessions d'usage dans le cadre de la mise en oeuvre de services rendus à un client par une entité fournisseur de services (tel qu'un serveur), lorsque par exemple, un client intervient depuis un premier réseau de communication, de type Réseau Téléphonique Commuté (RTC) et que les services sont mis en oeuvre au sein d'un deuxième réseau de communication, par exemple du type Internet. On rappelle qu'une session d'usage peut être définie comme une chaîne d'activations successives de différents moyens de communication, tels par exemple un terminal mis à disposition d'un utilisateur ou des serveurs mis en oeuvre par des clients d'un système de communication. La solution proposée repose sur la mise en oeuvre, au sein d'une entité de gestion de données de session et des entités clientes, de la capacité à recevoir et à délivrer de l'information pertinente sous la forme de messages classés selon au moins quatre catégories : des messages de service ; - des notifications - des commandes ; - des requêtes. Ainsi, à la différence des techniques antérieures, il n'est plus nécessaire de prévoir de multiples échanges de données complexes et des traitements applicatifs lourds qui ralentissent le système. La solution apportée par l'invention permet donc de réaliser une structuration des échanges, portant plus particulièrement sur la distinction des messages en requêtes et réponses, messages de service, notifications et commandes. Ainsi, grâce à l'utilisation d'un protocole applicatif ad hoc présentant une structuration particulière des messages orientée gestion de contexte et données de session, il devient plus facile au développeur de service d'intégrer dans l'applicatif service les fonctions de traitement des messages applicatifs pour l'utilisation souhaitée. Un autre avantage procuré par l'invention est de permettre de découpler totalement le protocole d'échange des messages et le contenu des messages eux- mêmes, et donc d'en disjoindre les traitements et d'augmenter la performance globale du système, grâce à l'utilisation d'un dispositif spécifique de traitement. L'invention permet donc de réduire les temps de traitement et de mieux répartir la charge de traitement en fonction d'une typologie de messages échangés par les différentes entités applicatives intervenant dans le réseau de communication. Pour ce faire, l'invention met en oeuvre des corrélants réseaux tel que conçus par les inventeurs tout en étageant (ordonnançant) la prise en charge des messages échangés entre les entités. On présente, en relation avec la figure 1, le principe général de l'invention : Une entité 100, reçoit (1000) un message 101 émis par une première entité 102. Cette réception est effectuée en fonction de la typologie préalablement définie et le message 101 contient un corrélant réseau 103. L'entité 100 active (1001) sélectivement un dispositif spécifique 104 propre à la typologie qui est apte à être mis en oeuvre pour le message 101 pendant une durée de vie du corrélant réseau 103. Cette durée de vie du corrélant réseau ne correspond pas nécessairement à la durée de vie du message, qui peut être plus longue ou plus courte. La durée de vie de l'information corrélante (jeton)est plutôt limitée à celle des établissements d'appels ou des échanges réseaux. Ainsi, on parle d'une durée de vie "limitée" dans la mesure ou cette limitation peut être opérée par les clients ou les entités de gestion de données de session. L'entité 100 fournit ensuite (1002), une réponse 105 au message 101 à destination de la première entité 102. La réponse inclue également le corrélant réseau 103, qui permet par exemple de vérifier la validité de cette réponse 105. Par la suite, on présente notamment le cas d'un système de gestion des données de session autorisant une structuration des échanges telle que décrites dans l'invention. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreux autres domaines, et par exemple dans le transfert de données entre des processus applicatifs différents d'une même application ou d'un même service, ou entre les applications d'un Système d'Information invoquées dans un processus de gestion de flux d'informations, et plus généralement dans tous les cas où les avantages listés par la suite sont intéressants. Description d'un mode de réalisation, On présente, dans ce mode de réalisation, une mise en oeuvre du procédé de transmission de données selon l'invention au sein d'un système de communication comprenant un serveur de données de session et des plateformes de services. Conjointement à la mise en oeuvre d'un mécanisme réseau de reroutage entre plateformes de services, ce serveur de données de session permet, par l'utilisation d'un jeton, le transfert de données applicatives entre ces mêmes plateformes de services. Le reroutage est un service offert aux plateformes de services connectées au réseau et qui souhaitent transférer un appel (vocal, vidéo, textuel) vers une autre plateforme de service ou à un terminal. Au contraire de l'aboutement (technique permettant de mettre en relation deux correspondants externes d'un système, bien connue de l'homme du métier), un tel transfert de l'appel évite de maintenir le premier service en prise sur la communication. Selon les mécanismes de l'art antérieur, sur le RTC (réseau téléphonique commuté) par exemple, ce service du type réseau intelligent est supporté par un Point de Commande de Service commandant un commutateur. Sur un réseau de nouvelle génération ( NGN de l'anglais New Generation Network ), il est supporté par un serveur d'application commandant un serveur d'appels. Selon ces techniques antérieures, pour la mise en oeuvre du reroutage, les plateformes de services communiquent avec un serveur applicatif de reroutage en utilisant un protocole applicatif dit "de reroutage", véhiculé dans la signalisation des messages échangés (au sein d'un canal de signalisation). Un tel reroutage est par exemple mis en oeuvre au sein du protocole RNIS ( Réseau Numérique à Intégration de Service ). On présente, en relation avec la figure 2, une architecture classique d'un système d'information tel que ceux mis en oeuvre par la demanderesse et dans laquelle il n'est pas fait appel à un serveur dedonnées de session et qu'une structuration des messages n'est pas mise en oeuvre. Dans un telle architecture, des plateformes de services aval 201 et amont 202 s'échangent des données par le biais d'une plateforme centrale 203 d'un réseau intelligent. Les messages échangés peuvent être représentés par trois couches 2001, 2002 et 2003, correspondant à des couches du modèle OSI : La couche média 2001 ; La couche signalisation 2002 ; La couche reroutage 2003 qui est du domaine applicatif. Les plateformes de services, qui doivent rendre des services applicatifs aux clients qui en font la demande intègrent directement tous les éléments (2011, 2012, 2013, 2021, 2022, 2023) qui permettent de gérer à la fois les problématiques de média, de signalisation et de reroutage. Il s'en suit qu'une plateforme de service est obligé de traiter, de la même manière, un message en provenance du canal média et un message de reroutage, par exemple, alors même que ces messages ne présentent pas le même intérêt du point de vue du client notamment du point de vue de la rapidité d'exécution du service rendu. Dans le cas d'un reroutage dit "aveugle", il n'y a pas visibilité directe entre le rerouteur 201, initiateur du reroutage, et le rerouté 202, celui vers lequel est transféré l'appel. Les échanges d'informations entre ceux-ci se font en mode tire-et- oublie , et, dans le cadre du reroutage, uniquement dans le sens amont vers aval. Dans sa demande de reroutage aveugle, le service initiateur du reroutage (le rerouteur) peut fournir des données, dites "de contexte", qui seront transmises au service vers lequel est effectué le reroutage (le rerouté) via une commande particulière (comme la commande "possibilités", pour un serveur raccordé en RNIS). Ce transfert d'informations peut notamment avoir pour objet de communiquer au service rerouté les circonstances du reroutage. Cependant, pour des raisons d'optimisation, le canal dédié à la signalisation réseau offre une capacité qui peut paraître trop limitée pour certains besoins des plates-formes de services. Ainsi, sur le RTC, dans certains modes d'implémentation, le volume maximum des données de contexte échangées lors d'un reroutage est de 23 octets. Afin de palier ce type de limitation, un système, au sein duquel on met en oeuvre un procédé de transmission de données selon l'invention, comprend un serveur de données de session qui transfert les données en se reposant sur l'utilisation de jetons. Le serveur de données de session permet donc l'échange de données après l'obtention d'un jeton. Un tel système comprend également en parallèle une plate-forme de type Réseau Intelligent supportant la fonction du reroutage téléphonique. Un réseau informatique dédié relie entre eux le serveur de données de session (SDS), et les plates-formes de services (PFS), afin de permettre les échanges de données relatives aux sessions d'usage des utilisateurs des services. Pour adresser ces données de sessions (stockées plus ou moins temporairement sur le SDS) et de les rattacher à des évènements réseaux tels qu'ils sont vus des plateformes de services, on utilise des jetons uniques (sur une période donnée). Ces jetons sont échangés par les plateformes de services dans la signalisation lors de la mise en oeuvre du reroutage. L'unicité d'un jeton sur le réseau pour une période donnée, ainsi que la génération des identifiants de sessions sont ici assurées par le serveur de données de session mais elles pourront être implémentées en dehors du serveur de données de session dans d'autres modes de réalisation. On présente, en relation avec la figure 3, un diagramme de séquence d'un échange de messages se déroulant dans une architecture évoluée d'un système d'information tel que ceux mis en oeuvre par la demanderesse et dans laquelle un serveur de données de session est utilisé sans toutefois qu'une structuration des messages soit mise en oeuvre.

Un utilisateur 300 entre en relation (3000) avec une plateforme de services amont 301, laquelle obtient le profil de l'utilisateur 300, génère des informations de session d'usage (3001) et décide de faire appel à une plateforme de service 302 pour poursuivre la fourniture de service demandée par l'utilisateur 300. Pour ce faire, la plateforme de services amont 301 requiert (3002) un corrélant réseau auprès d'un serveur de données de session 303. Ce dernier génère le corrélant réseau (3003) puis l'envoie (30030) à la plateforme de service amont 301. Cette dernière associe (3004) les données de la session d'usage qu'elle vient de créer avec le corrélant réseau puis envoie (3005) ces données associées au serveur de données de session 303, qui se charge de stocker et de maintenir ces données (3006). Enfin, la plateforme de service 301 obtient du réseau le reroutage (3007) de l'appel du client 300 vers la plateforme de service aval 302, avec transmission du corrélant réseau. A réception de l'appel suite au reroutage, après extraction du corrélant réseau de la signalisation, la plateforme de service aval 302 demande (3008) les données de session d'usage au serveur de données de session 303 en indiquant le corrélant réseau auquel ces données sont associées. Le serveur de données de session retrouve (3009) alors ces données et les transmet (3010) à la plateforme de service 302 afin qu'elle poursuive l'interaction avec l'utilisateur 300.

Il apparaît, à l'issue de cette description, que les ressources des plateformes de services pourraient être mieux utilisées. En effet, ces plateformes doivent non seulement gérer tout à la fois le service à rendre à l'utilisateur mais également les interactions avec le réseau, ce qui a pour conséquence de nuire aux performances générales des plateformes.

L'invention permet notamment de palier cet inconvénient comme le montre la figure 5 en structurant les échanges de messages entre les entités du réseau. Un utilisateur 500 entre en relation (5000) avec une plateforme de services amont 501, laquelle obtient le profil de l'utilisateur 500, génère des informations de session d'usage (5001) et décide de faire appel à une plateforme de service 502 pour poursuivre la fourniture de service demandée par l'utilisateur 500. Pour ce faire, la plateforme de services amont 501 requiert (5002), à l'aide d'un dispositif spécifique 510 un corrélant réseau auprès d'un serveur de données de session 503. Ce dernier identifie cette requête (50031) à l'aide d'une typologie de message, génère le corrélant réseau (5003) puis l'envoie (50050) à la plateforme de service amont 501. Cette dernière identifie la typologie de la réponse (50041) et associe, à l'aide d'un dispositif spécifique (5004) les données de la session d'usage qu'elle vient de créer avec le corrélant réseau puis envoie (5005) ces données associées au serveur de données de session 503, qui se charge de stocker et de maintenir ces données (5006). Enfin, la plateforme de service 501 met en oeuvre un dispositif spécifique de routage (5071) et demande le reroutage (5007) de l'appel du client 500 vers la plateforme de service aval 502 en transmettant le corrélant réseau. Ce reroutage (5007) est effectué par l'intermédiaire du serveur de données de session 503.

A réception de l'appel suite au reroutage, la plateforme de service aval 502 identifie le type de message (50081) et demande (5008), par l'intermédiaire d'un dispositif spécifique (50082) les données de session d'usage au serveur de données de session 503 en indiquant le corrélant réseau auquel ces données sont associées. Le serveur de données de session retrouve (5009) alors ces données et les transmet (5010) à la plateforme de service 502 afin qu'elle poursuive l'interaction avec l'utilisateur 500. Ainsi, selon l'invention, pour alléger et structurer l'échange d'information entre les clients et le serveur de données de sessions, on procède à un échange structuré de messages applicatifs qui permettent de mettre en oeuvre des modules spécifiques apte à traiter l'information de manière plus efficiente qu'une application de service qui a été créer pour rendre un service spécifique et non pas traiter des échanges de messages. Messagerie support Dans ce mode de réalisation, la solution proposée consiste en la mise en 30 oeuvre, tant sur les plates-formes clientes d'un Serveur de Données de Sessions que sur celui-ci, le cas échéant, de modules logiciels en charge de l'écriture et de la lecture de messages. De tels messages ont une syntaxe qui peut reproduire la logique arborescente de la structuration des données de session. Or, cette structuration relève du domaine méfier de cette messagerie inter-services. Ainsi, au sein des plateformes clientes et du serveur de données de session, on permet une différentiation des traitements. Le support de cette messagerie applicative pourra être basé sur l'utilisation de XML/HTTP/IP ou de SOAP, mais on pourrait également préférer un produit sur étagère, ou des requêtes SQL, et CFT pourrait être préféré à HTTP. Le réseau support de ces liens peut être un intranet/extranet dédié, accessible aux plates-formes de services d'opérateurs ou d'entreprises partenaires, voire aux terminaux utilisateurs. Le protocole applicatif utilisé, par exemple HTTP, est un système bidirectionnel d'échanges de messages entre clients et SDS. Par exemple, des requêtes applicatives HTTP sont envoyées des clients vers le SDS, et des réponses HTTP du SDS vers les clients. Le contenu des messages peut être au format XML. Messages échangés Afin de faciliter le travail de développement des éléments du système et 20 leur modularité, les messages échangés entre clients et serveur de données de session sont classés en plusieurs catégories : messages de service ; -notifications ; - commandes ; 25 - requêtes ; Les messages de service sont utilisés pour la gestion du réseau applicatif et sont traités au seul niveau des interfaces bas niveau des clients et SDS, tandis que les notifications et commandes et les requêtes concernent la gestion des données des services, et font appel à l'applicatif des clients et du SDS.

Un message de service est par exemple le message Hello , qui sert au SDS ou au client à tester la présence de l'autre. Un message du SDS peut être adressé à un ou plusieurs clients et/ou à un ou plusieurs Groupes Fermés de Clients. Le message n'est envoyé qu'à eux seuls.

On rappelle qu'un serveur de données de session intègre des mécanismes de gestion des clients et des groupes fermés de clients, et un mécanisme de gestion des droits de sessions ou des données de session des clients et des groupes fermés de clients, et des droits des clients et sous-groupes fermés de clients au sein des groupes fermés de clients. Les droits associés à une session peuvent être par exemple : lecture/écriture/modification du contenu de la session, et/ou des droits d'accès à celle-ci, et/ou des opérations autorisées sur la session. Le serveur de données de session intègre également des mécanismes de prise en charge de règles de gestion défmies implicitement (par défaut) et/ou explicitement (par l'initiateur de la session) en fonction des droits de la session ou d'autres règles.

Ces droits et règles peuvent être décrits sous la forme de masques (chaîne de bits) ou de scripts (structurés selon un langage approprié). Les droits d'accès à la session (ou à tout ou partie des données et informations référencées) ainsi que la gestion des droits d'accès à la session sont définissables par le client initiateur de la session. Ces droits peuvent être définis par défaut par le serveur de données de session, qui sont alors mis en oeuvre s'ils ne sont pas définis par l'initiateur. L'initiateur peut également définir les droits d'accès et/ou d'exécution et/ou de modification de ces droits attachés aux blocs de structuration des données. Les droits ainsi définis sont affectés à des ensembles de clients et/ou de groupes fermés de clients.

Au niveau du réseau, l'envoi d'un message à un groupe fermé de client est en fait une série d'envois de point à point en parallèle (à chaque client), mais, au niveau applicatif, il s'agit d'une diffusion d'un message à un groupe de client. Une commande est par exemple la commande de libération de jeton, qui sert au SDS à donner à un ou plusieurs clients destinataires (éventuellement tous) l'ordre de libérer tels ou tels jetons, voire tous leurs jetons. Il s'agit là aussi d'une diffusion au niveau applicatif. Les autres messages sont par exemple les requêtes échangées du client vers le serveur de données de session, dont les réponses ne sont adressées qu'au seul client émetteur de la requête. Une liste de message est présentée en annexe, qui fait parie intégrante de la description. Utilisation d'une interface spécifique en tant que dispositif de structuration des échanges Dans un mode de réalisation de l'invention, on assigne à chaque catégorie de message échangé, une interface spécifique permettant de structurer les échanges. Une telle interface peut donc être dédiée à l'échange de certaines catégories de message tandis que d'autres interfaces peuvent être dédiées à l'échange d'autres catégories de messages. Cette interface fait office de dispositif spécifique de traitement du message. Elle peut se présenter, par exemple, sous la forme d'une adresse 1P (de l'anglais Internet Protocol pour Protocole Internet ). Ainsi, on peut utiliser une adresse IP spécifique à l'échange des messages de services et des notifications, une adresse IP spécifique à l'échange des commandes et une autre spécifique à l'échange des requêtes. Une telle implémentation nécessite alors qu'un serveur dispose de trois adresses IP différentes. Dans un autre mode de réalisation, il est également possible d'allouer, pour une même adresse IP, des ports de communication différents en fonction de la catégorie du message. Ainsi, pour une même adresse 1P, par exemple 192.168.2.10, le port 1024 aux messages de services, 1025 aux notifications, 1026 aux commandes et conserver le port 80 pour les requêtes HTTP (requêtes applicatives). On évite ainsi de devoir allouer plusieurs adresses IP à un même serveur. Bien entendu, des combinaisons des deux modes de réalisation précédents peuvent également être employées.

Utilisation d'un module logiciel client en tant que dispositif de structuration et d'allègement des échanges. Dans un mode de réalisation particulier de l'invention, un module logiciel client (MLC) peut être utilisé en tant que dispositif spécifique de traitement des 5 messages échangés. Ainsi, un module logiciel client (MLC) permet selon l'invention : d'assurer, pour le compte d'un client de l'entité de gestion de données de session, la prise en charge de couches basses des protocoles d'échanges avec l'entité de gestion de données de session (notifications, commandes) ; 10 - d'assurer pour le compte d'un client de l'entité de gestion de données de session, et de façon transparente pour ce client, la gestion et les traitements des informations propres à ces couches basses et n'interférant pas directement avec les traitements des applicatifs services ; - d'assurer pour le compte d'un client de l'entité de gestion de données de 15 session, et de façon transparente pour celui-ci, l'aiguillage des messages émanant éventuellement de plusieurs entités de gestion de données de session ; - d'être, pour les échanges avec le ou les entités de gestion de données de session éventuelles, porteur de l'identité du ou des clients au service 20 desquels il travaille, que ces clients soient ou non distingués du point de vue de l'entité de gestion de données de session ; de mutualiser le cas échéant, lorsqu'il travaille pour plusieurs clients, les ressources partageables entre ceux-ci, comme par exemple des informations corrélantes de session, ou des identifiants de sessions. 25 Dans un mode de réalisation particulier de l'invention, la solution proposée consiste en la mise en oeuvre, sur les plates-formes clientes d'un Serveur de Données de Sessions (SDS), des Module Logiciels Clients (MLC) de ce serveur de données de session, situé en coupure entre les applicatifs services clients de l'entité de gestion de données de session et l'entité de gestion de données de 30 session. Ces MLC, mutualisables et réutilisables (sous forme de code informatique avec ou saris support matériel dédié), portent sur des couches basses des plates-formes de services assurant la gestion des échanges entre les applicatifs de services de ces plates-formes et les serveurs de données de sessions. On trouvera en annexe, qui fait partie intégrante du contenu de la description, un ensemble de fonctionnalités des modules logiciels client. Architecture d'un module logiciel client On présente, une architecture d'un module logiciel client. Un tel module comprend un module de traitement qui réalise les opérations propres : - à la réception et à l'envoi de messages vers un serveur de données de session; - à la réception de commandes applicatives et à l'envoi de données en provenance d'un applicatif de service. Pour réaliser ses traitements, le module de traitement dispose d'un accès à des paramètres de fonctionnement, d'une gestion d'informations volatiles (piles et timers) et de paramètres de configuration, comprenant notamment des identifiants et des adresses. Le module logiciel client dispose également d'un module d'administration et de supervision, qui par le biais d'une interface homme/machine permet de vérifier son fonctionnement. On présente, une architecture d'un module logiciel multi-client (module 20 logiciel multi-client). Un tel module comprend un module de traitement qui réalise les opérations propres : - à la réception et à l'envoi de messages vers un serveur de données de session; - à la réception de commandes applicatives et à l'envoi de données 25 en provenance des plusieurs applicatifs de service. Pour réaliser ses traitements, le module de traitement dispose d'un accès à des paramètres de fonctionnement généraux ainsi qu'à des paramètres de fonctionnement spécifiques à chaque service applicatif, d'une gestion d'informations volatiles générales (piles et timers) ainsi qu'à des informations 30 volatiles propres à chaque service applicatif et de paramètres de configuration, comprenant notamment des identifiants et des adresses. Le module logiciel client dispose également d'un module d'administration et de supervision, qui par le biais d'une interface homme/machine permet de vérifier son fonctionnement. Ainsi, le module logiciel client (ou module logiciel multi-client) rend possible la définition d'une interface d'accès au serveur de données de session simplifiée, pour les services, chargée notamment d'assurer la prise en compte de notifications (comme par exemple un arrêt du serveur de données de session...), de messages de services (type hello ). On réduit ainsi fortement le nombre de fonction à implémenter pour la 10 définition d'un service. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits. Dans un mode de réalisation particulier de l'invention, le module logiciel client peut être situé sur un serveur physique distinct de la plateforme de service auquel il est connecté. Dans un autre mode de réalisation de l'invention, le 15 module logiciel client peut être intégré au sein du même serveur physique que celui de la plateforme de service auquel il est appairé. Dans un mode de réalisation particulier de l'invention, le module logiciel client peut prendre à son compte la gestion de données échangées de façon récurrente avec le serveur de données de session. Ainsi, les jetons ou corrélants 20 temporaires de sessions existent en nombre limité sur les réseaux, et le serveur de données de session se charge de les répartir entre les clients actifs suivant de nombreux critères, avec une durée de vie limitée pour chaque jeton, pour sa réutilisabilité. Afin de tenir le temps réel, c'est sans délai que les services ont besoins des jetons réseaux. 25 Il est donc envisageable de confier au module logiciel client par exemple la gestion de la pile de jetons allouée temporairement à un client par un serveur de données de session. Quand plusieurs serveurs de données de session sont accessibles, que ce soit pour des raisons de sécurisation, de partage de charge ou parce qu'ils sont 30 exploités par des opérateurs distincts, le module logiciel client assure l'aiguillage des messages de et vers le bon serveur de données de session. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits. Plusieurs client peuvent le cas échéant utiliser un même module logiciel client ou plusieurs instances d'un même module logiciel client (Module Logiciel Multi-Client) pour s'interfacer avec un ou plusieurs serveurs de données de session, que ce soit pour des raisons simplification matérielle ou logicielle. le module logiciel multi-client assure alors l'aiguillage des messages de et vers le bon client. La tâche du développeur de service en est simplifiée, et les coûts de développement réduits.

De plus, la possibilité de l'externalisation du module logiciel multi-client (une ou plusieurs instances) sur une machine hôte distincte de la ou des plates-formes de services permet une plus grande flexibilité des architectures de plates-formes de services, notamment dans l'optique d'une sécurisation et d'une répartition de charge globale.

Lorsque plusieurs clients utilisent un même module logiciel multi-client, ou plusieurs instances d'un même module logiciel client (chargement statique ou dynamique) pour s'interfacer avec un ou plusieurs serveur de données de session, on peut localement procéder à la mise en commun entre ces clients de certaines ressources réparties par les serveurs de données de session entre leurs clients respectifs, comme par exemple les jetons réseaux. Une ressource rare devient donc plus facilement disponible pour chaque client serveur de données de session individuel, et l'exploitant de plates-formes de services est plus à même d'assurer dynamiquement l'allocation de cette ressource aux clients qu'il juge prioritaires à un moment donné. L'efficacité du système est donc augmentée. Combinaison des interfaces spécifiques et des modules logiciels clients Dans un mode de réalisation particulier de l'invention, il est envisagé d'utiliser les interfaces spécifiques précédemment décrites pour la réception et l'envoi des messages entre le module logiciel spécifique et le serveur de données de session. Ainsi, par exemple, il est possible d'attribuer une adresse IP spécifique à un module logiciel spécifique qui serait par exemple chargé de la réponse à des notifications. Il est également possible d'attribuer un port spécifique d'une adresse IP générale à un tel module logiciel. Ainsi, on augmente encore les performances du système en établissant une classification bidimensionnelle des échanges.

En effet, une telle classification permet, dans un mode de réalisation particulier de définir une architecture d'une plateforme de service qui comprend par exemple un ensemble de quatre modules logiciels clients (correspondant aux quatre types de messages de la typologie), utilisant chacun une interface spécifique constituée d'une adresse IP et d'un port spécifique de cette adresse.

Ces quatre interfaces sont utilisées par le serveur de données de session pour s'adresser à la plateforme de services en fonction du degré d'échange exigé entre le serveur de données de session et le ou les services applicatifs disponibles sur la plateforme. Il est donc possible de disjoindre totalement le module logiciel client de l'applicatif de service, de sorte que l'instanciation d'un module logiciel client n'entraîne pas une baisse des performances générales de la plateforme de service. Architecture du serveur de données de sessions On présente, en relation avec la figure 4, une architecture simplifiée d'un serveur de données de session selon l'invention. Il comprend une mémoire 41, et une unité de traitement 40 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 42. L'unité de traitement 40 reçoit en entrée, via un module d'interface d'entrée réseau 43, des réponses et des notifications 44. Ces informations sont traitées par le microprocesseur, selon les 25 instructions du programme 42, pour : -émettre des messages de service 46a ; - émettre des requêtes 46b ; Ces données sont transmises via un module d'interface de sortie réseau 45 à destination des dispositifs du réseau de communication qui en ont la charge.

30 ANNEXES 1. Fonctions des module logiciel client et module logiciel multi-client 1.1. Échanges entre module logiciel client/module logiciel multi-client et serveur de données de session Les fonctions type de l'interface de programmation applicative d'un serveur de données de session comprennent notamment : - Requêtes (client vers serveur de données de session) : création de session, - retrait de session, récupération de l'identifiant de session, - ajout de données, - récupération des descriptions des données, - récupération de données, modification de données, - suppression de données, récupération de droits, modification de droits, récupération de jetons, - test de validité de jetons, association d'un jeton à une session, libération de jetons, - libération de tous les jetons. Messages de service : - ping (serveur de données de session vers client), - pong (client vers serveur de données de session), timeout de session (serveur de données de session vers client), maintien de session (client vers serveur de données de session), - hello = test de validité de client (client vers serveur de données de session), - arrêt serveur de données de session (serveur de données de session vers client), - redémarrage serveur de données de session (serveur de données de session vers client), arrêt ou redémarrage client (client vers serveur de données de session). Notifications (serveur de données de session vers client): clôture de session, expiration de jeton, expiration de tous les jetons. 1.2. Echanges entre applicatifs services et module logiciel client/module logiciel multi-client Un exemple d'un tel protocole est décrit de façon détaillée dans les documents références, et plus particulièrement du document [3], Manuel 15 utilisateur Serveur de Données de Session. En résumé, les fonctions type de l'API d'un Module Logiciel Client ou d'un Module Logiciel Multi-Client faisant fonction de client d'un Serveur de Données de Session pour le compte d'un o de plusieurs applicatifs de services peuvent être les suivantes : 20 - Requêtes (client vers module logiciel client) : - création de session, retrait de session, récupération de l'identifiant de session, - ajout de données, 25 récupération des descriptions des données, récupération de données, - modification de données, - suppression de données, - récupération de droits, 30 -modification de droits, - récupération de jetons, 10 association d'un jeton à une session, libération de jetons, libération de tous les jetons. - Messages de service : - arrêt serveur de données de session (module logiciel client vers client), redémarrage serveur de données de session (module logiciel client vers client), arrêt ou redémarrage client (client vers module logiciel client). 10 - Notifications (module logiciel client vers client): clôture de session, expiration de jeton, - expiration de tous les jetons. 15 1.3. Simplification des échanges entre applicatifs services et serveur de données de session La simplification des échanges entre applicatifs services et serveur de données de session apportée par le Module Logiciel Client ou le module logiciel multi-client peut ainsi résider principalement dans prise en main de la gestion des 20 messages deservice ainsi que des requêtes relatives à la gestion de piles de jetons, pour le compte de l'applicatif service : Requêtes (client vers module logiciel client) : - test de validité de jetons. Messages de service : ping (serveur de données de session vers module logiciel client), - pong (module logiciel client vers serveur de données de session), - timeout de session (serveur de données de session vers module logiciel client), maintien de session (module logiciel client vers serveur de données de session), hello = test de validité de client (module logiciel client vers serveur 25 30 29 de données de session). 2. Données traitées par les module logiciel client et module logiciel multiclient Les module logiciel client et module logiciel multi-client gèrent, par exemple, les informations et données suivantes : Données de configuration : identifiants du ou des clients gérés par le module logiciel client ou le module logiciel multi-client, - adresses du ou des applicatifs services servis, adresses du ou des serveurs de données de session utilisables. Paramètres de fonctionnement : - durée des timers des jetons, durée des timers des sessions, - durée des timers d'activité des serveurs de données de session, - durée des timers d'activité des clients taille minimum de la pile de jetons affectable à tel ou tel applicatif service servi ou globalement à tous les applicatifs services. - taille maximum de la pile de jetons affectable à tel ou tel applicatif service servi ou globalement à tous les applicatifs services. Nombre maximum de jetons allouable à chaque client par le serveur de données de session. - Informations volatiles : - valeur des timers des jetons affectables aux applicatifs services 25 servis, - valeur des timers des sessions en cours des applicatifs services servis, contenu de chaque pile de jetons gérée, état (activité) de chaque applicatif service servi, 30 - état (activité) de chaque serveur de données de session utilisé ou utilisable. sessions auxquelles participe chaque applicatif servi. jetons en cours d'utilisation par chaque applicatif (AS) servi. état (activité) de chaque serveur de données de session utilisé ou utilisable. 3. Traitements opérés par les module logiciel client et module logiciel multiclient Les module logiciel client et module logiciel multi-client procèdent, par exemple, aux traitements suivants, sur réception de signaux ou changement d'état : 10 - Message ping reçu du serveur de données de session : - S'il gère le client dont l'identifiant est précisé dans le ping, renvoie un message pong avec cet identifiant. Message arrêt du serveur de données de session : - Informe les AS gérés et mémorise l'information. 15 - Message redémarrage du serveur de données de session : - Informe les AS gérés et mémorise l'information. Message timeout de session reçu du serveur de données de session : - Peut par défaut demander un maintien de session, ou transférer le message à l'AS ou aux AS concernés. 20 - Timeout serveur de données de session ou client : Envoie au(x) serveur(s) de données de session concerné(s) un message hello, avec l'identifiant du client servi. Taille minimum de pile de jeton d'un client : Envoie au serveur de données de session une requête de demande 25 de n=max-min jetons. - Entre ces jetons dans la pile du client concerné. - Timeout de jeton : Envoie au serveur de données de session une requête de test de validité du jeton. 30 - Si NOK, supprime le jeton de la pile. Message expiration de jetons reçu du serveur de données de session :5 Supprime les jetons concernés des piles - Si les jetons sont déjà alloués à des AS, les en informe. Message expiration de tous les jetons reçu du serveur de données de session : Supprime tous les jetons des piles Si des jetons sont déjà alloués à des AS, les en informe. - Requête récupération de j jetons reçue d'un AS : Retire les j jetons de la pile de jetons affectée à cet AS. Requête libération de jetons de j jetons reçue d'un AS : - Remet les j jetons dans la pile de jetons affectée à cet AS. - Requête libération de tous les jetons reçus d'un AS : Si mémorisation de l'état des jetons, remet les jetons dans la pile de jetons affectée à cet AS. - Si non mémorisation de l'état des jetons, peut : - soit ignorer cette requête, soit vider la pile de jetons affectée à cet AS et transmettre cette requête au serveur de données de session. - Message arrêt ou redémarrage client reçu d'un AS : - Informe les serveurs de données de session concernés en précisant les identifiants clients et mémorise l'information. Pour les autres messages, les modules logiciels clients et module logiciel multi-client peuvent transférer les messages des AS vers les serveurs de données de session et des serveurs de données de session vers les AS, en mettant à jour les indicateurs d'états et les timers. 20 25

Claims (12)

REVENDICATIONS

1. Procédé de transmission de données, caractérisé en ce qu'il comprend : - une étape de réception d'un message émis par une entité émettrice, ledit message comprenant : un identifiant de typologie, désignant un type prédéfini ; - une information corrélante, ayant une durée d'existence limitée ; - une étape d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit message pendant ladite durée d'existence de ladite information corrélante.

2. Procédé de transmission de données selon la revendication 1, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'utilisation une deuxième étape d'émission d'une réponse audit message à destination de ladite entité émettrice, par le biais dudit dispositif spécifique.

3. Procédé de transmission de données selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : - des messages de service ; - des notifications ; des commandes ; - des requêtes.

4. Procédé de transmission de données selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend, préalablement à ladite étape de réception, une étape d'obtention d'une information corrélante apte à être utilisée au sein dudit message.

5. Procédé de transmission de données selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'au moins un module logiciel client spécifique pour chaque type de message appartenant à ladite typologie.

6. Procédé de transmission de données selon la revendication 5, caractérisé en ce que ledit au moins un module logiciel comprend une capacité d'échange de données avec au moins un module applicatif apte à rendre un service applicatif requit par ledit message.

7. Procédé de transmission de données selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'une interface spécifique pour chaque type de message appartenant à ladite typologie.

8. Procédé de transmission de données selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit dispositif spécifique se présente sous la forme d'un module logiciel client combiné à une interface spécifique.

9. Procédé de transmission de données selon l'une quelconque des revendications 7 et 8, caractérisé en ce que ladite interface spécifique est une adresse IP spécifique pour chaque type de message appartenant à ladite typologie.

10. Procédé de transmission de données selon l'une quelconque des revendications 7 et 8, caractérisé en ce que ladite interface spécifique se présente sous la forme d'un port spécifique d'une adresse IP.

11. Dispositif de transmission de données, caractérisé en ce qu'il comprend : - des moyens de réception d'un message émis par une entité émettrice, ledit message comprenant : - un identifiant de typologie, désignant un type prédéfini ; une information corrélante, ayant une durée d'existence limitée ; des moyens d'utilisation sélective d'au moins un dispositif spécifique audit type et apte à être utilisée pour traiter ledit message pendant ladite durée d'existence de ladite information corrélante.

12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ouexécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du Procédé de transmission de données selon l'une au moins des revendications 1 à 4, lorsqu'il est exécuté sur un ordinateur.