Procédé de transmission de données en deux étapes, dispositif et produit programme d'ordinateur correspondants.

La présente invention se rapporte au domaine de la gestion de communication et plus particulièrement de session dans un serveur de session contrôlant 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, et donner lieu à des activations successives d'un ou plusieurs dispositifs de communication.

Les sessions d'usage sont par exemple mises en œuvre dans le cadre d'extensions du couplage téléphonie/informatique dans des réseaux de communication. L'invention concerne donc la gestion de sessions d'usage.

La présente invention se rapporte plus particulièrement au domaine des transmissions de données applicatives dans des systèmes de télécommunication.

Dans l'état actuel de la technique, un système de télécommunication mettant en œuvre le procédé décrit plus haut 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 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 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 ou par divers éléments séparément 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 œuvre 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 œuvre 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 œuvre 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. On présente, en relation avec la figure 1, le principe de création et de transfert de session d'usage. Dans une première phase 10, un client 100 demande (101) à une entité 102, la création d'une session. L'entité 102 peut soit créer la session, soit faire appel (103) à une entité de gestion de session 104 pour construire la session. Cette entité 104 transfère (105) alors l'identifiant de session à l'entité 102 qui le transfère (106) à son tour à au client 100.

Dans une deuxième phase 11, l'entité 102 qui a besoin d'obtenir des données de session, demande (111) ces données à l'entité de gestion de session 104, qui lui fournit (112), l'intégralité des données 113 afin que l'entité 102 puisse rendre un service demandé. Une session, au sens de la présente description, peut par exemple être représentée comme une transmission d'une suite de champs de longueur fixe prédéterminée comprenant chacun une information représentative de données de session. Ces données de session peuvent être, par exemple, des contextes de session lesquels contiennent un identifiant de session ainsi que des informations de sessions. Ces informations peuvent notamment être des droits accordées à cette session. Ces données de session peuvent également être des contextes d'exécution de services ou d'applications, comprenant un identifiant, des droits d'accès à des ressources, un entête, ainsi qu'un corps. Les sessions sont enregistrées au sein de bases de données dont la structure ne fait pas partie de la présente invention. Ainsi la matérialisation de la session au sien d'un support d'enregistrement et/ou de stockage est indépendante de sa représentation fonctionnelle.

Un suivi des sessions de communication est assuré au sein d'un système de gestion de données de sessions, également nommé « Serveur de Données de Session » dont un mode de mise en œuvre particulier est décrit dans une demande de brevet français référencée FR0502197 et déposée le 04/03/2005. Un tel « Serveur de données de sessions » est habilité à communiquer avec les différents clients nécessaires à l'exécution d'un service ou d'une application au sein d'un système d'information distribué et apte à communiquer avec des éléments présents dans des réseaux de communication différents. Il gère la complexité des échanges de données entre les clients en leur transmettant les données constituant la session. Les clients utilisent ces données pour réaliser les traitements dont ils ont la charge et transmettent en retour les données de la session, éventuellement modifiées, soit à un client suivant soit au serveur de données de session, ceci en fonction d'un mode de gestion des sessions préalablement défini.

Un inconvénient de cette technique de gestion d'information de sessions selon l'art antérieur est lié au fait que le système de gestion des données de session transmet l'intégralité des données de session aux clients. Ainsi, ces derniers reçoivent la plupart du temps des volumes de données conséquents qui posent de nombreux problèmes parmi lesquels : une surcharge des clients, tant en volume de données reçues et transmises qu'en capacités de traitement de ces données ; la nécessité d'un dimensionnement des réseaux de communication afin de supporter les échanges entre les clients et le serveur de données de session ; un report de la complexité applicative de gestion des sessions de la part du serveur de données de session vers les clients.

En ce qui concerne le système de gestion de session, cette technique de l'art antérieur présente également des inconvénients notamment : - une surcharge du système, tant en volume de données reçues et transmises, qu'en capacités de traitement de ces données ; un accroissement des risques d'accès concurrents à des données distribuées à plusieurs clients qui agissent sur des données identiques d'une même session. Un autre inconvénient de cette technique de l'art antérieur est la nécessaire complexité des architectures de systèmes d'information résultant de la transmission de volume de données très important. En effet, pour pouvoir traiter et gérer l'intégralité des données des sessions, les clients du système d'information doivent être surdimensionnés par rapport aux tâches réelles à accomplir, sous peine de nuire aux performances globales du système. Ceci n'est pas sans poser de problème, notamment concernant les terminaux des utilisateurs. Dans le cas d'un terminal téléphonique connu de l'art antérieur, la transmission intégrale des données de session oblige l'opérateur de téléphonie à mettre en œuvre un client supplémentaire qui dispose de capacités suffisantes pour traiter les informations

de session. Cette mise en place n'est pas sans conséquence, notamment concernant les coûts de service résultant d'une telle implémentation.

L'invention propose une solution qui ne présente pas ces inconvénients de l'art antérieur, grâce à un procédé de gestion d'au moins une communication établie entre au moins deux dispositifs de communication, au cours d'une session lors de laquelle sont transmises, d'une part, des informations de constitution décrivant la session et, d'autre part, des données de session.

Selon l'invention, ledit procédé de gestion comprend une étape de sélection d'au moins une desdites informations de constitution en cours de déroulement de ladite session.

La gestion de la communication induit une administration de session laquelle est réalisée selon l'invention par une sélection des informations de constitution utiles à un instant donné. On se distingue donc des procédés de gestion de session selon l'art antérieur qui transmettent l'ensemble des informations d'une session aux clients qui en font la demande. Une optimisation des ressources des réseaux lors de la transmission de données est ainsi mise en œuvre. Ceci est particulièrement utile si l'on considère qu'une session peut comprendre une chaîne d'activations successives d'au moins un dispositif de communication, permettant ainsi d'agréger un important volume de données de constitution, par exemple en provenance de différents serveurs qui sont successivement mis en œuvre lors de la durée de vie de la session.

Dans un mode de réalisation particulier de l'invention, ladite étape de sélection tient compte d'au moins un paramètre d'un niveau de détail requis, ledit niveau de détail permettant de déterminer lesdites informations de constitution à transmettre.

Un client (qui est un dispositif qui requiert de l'information auprès d'un serveur) dispose par exemple d'une indication de l'information requise. Il peut ainsi transmettre au serveur de gestion de session cette indication. Le procédé permet, dans un mode de réalisation, associer cette information à un niveau de détail et peut ainsi permettre de tronquer un arbre de session (arbre construit à

partir de la chaîne d'activations successives des moyens de communication) et ne transmettre que les informations de constitution pertinentes. Dans un autre mode de réalisation, le client peut disposer, à l'aide d'une configuration adaptée, du niveau de détail lui-même et transmettre directement ce niveau de détail au serveur qui met en œuvre le procédé selon l'invention.

Selon un aspect particulier de l'invention, ladite étape de sélection tient compte d'au moins un paramètre d'habilitation, ledit paramètre d'habilitation définissant des droits d'accès auxdites informations de constitution.

Ainsi, on met en œuvre une habilitation des clients, qui permet d'asseoir une politique de sécurité permettant le contrôle, par le procédé de gestion, des accès aux informations requises. Dans un mode de mise en œuvre de l'invention, le procédé de gestion peut comprendre une étape d'accès à une base de données des clients et obtenir de cette base de données des informations d'autorisation d'accès. Selon un mode de mise en œuvre particulier, ledit paramètre d'habilitation est associé à au moins un groupe de clients autorisé à accéder auxdites informations de constitution.

Ainsi, on met en œuvre une notion de groupe de clients. Un groupe de clients peut par exemple consister en un ensemble de serveurs pouvant être mis en œuvre dans le cadre de l'exécution d'un service déterminé. Ainsi, si pour fournir à un utilisateur des résultats sportifs qui l'intéressent, il est nécessaire de mettre en œuvre trois serveurs qui se relaient pour fournir le service désiré, il est alors possible de définir un groupe de clients composé des trois serveurs nécessaires et de donner à ces trois serveurs une autorisation d'accès aux informations de constitution de la session d'usage.

Selon une caractéristique originale de l'invention, ledit procédé de gestion comprend : une étape de transmission d'une partie desdites informations de constitution ; - une étape de transmission d'un sous-ensemble desdites données de session

auquel est associée ladite partie des informations de constitution transmise.

Le procédé de gestion selon l'invention optimise ainsi l'utilisation des ressources réseau. En effet, en plus d'offrir un accès à certaines données de constitution de la session et des possibilités de restrictions d'accès à ces données de constitution, l'invention permet de transmettre en deux temps les données aux clients qui en font la demande. Dans un premier temps, seules les informations de constitution de la session sont transmises. Dans un second temps, les données associées sont transmises. Ainsi, on évite de provoquer des congestions dans les réseaux de communication en transmettant les informations en deux passes Selon un aspect particulier de l'invention, ladite étape de transmission desdites données inclut un découpage des données de session à transmettre en fonction d'au moins une information de volume de données à transmettre contenue au sein des informations de constitution.

Ainsi, le découpage des données à transmettre permet de limiter l'usage des ressources des réseaux. Donc, si les données associées aux informations de constitution sont volumineuses, le procédé selon l'invention offre la possibilité de les scinder en plusieurs paquets qui sont successivement transmis aux clients.

Selon une caractéristique originale de l'invention, les données de session à transmettre sont extraites de ladite session. Dans ce mode de réalisation, les données à transmettre sont incluses dans la session. On a ainsi une correspondance entre la structure de la session et les données qu'elle contient. On facilite donc le maintien de la cohérence des données. Dans un autre mode de réalisation, les données peuvent être disponibles au sien d'un autre dispositif du réseau (par exemple une base de données de session) et être transmises au client qui en fait la demande sur ordre du dispositif qui reçoit la demande.

Selon un mode de mise en œuvre particulier, lorsque ladite information de volume de données à transmettre représente un volume inférieur à un seuil prédéterminé, lesdites étapes de transmission desdites informations de constitution et desdites données sont confondues en une seule étape de transmission.

Ainsi, il n'est pas nécessaire de procéder à plusieurs transmissions quand la taille des données de sessions à transmettre est située sous un seuil donné, car alors il est possible de consommer plus de bande passante avec deux transmissions qu'avec une seule. Un seuil prédéterminé ou négocié de volume de données est donc utilisé pour décider de la transmission, ou non, des informations en plusieurs étapes successives.

L'invention concerne également un dispositif de gestion d'au moins une communication établie entre au moins deux dispositifs de communication, au cours d'une session lors de laquelle sont transmises, d'une part, des informations de constitution décrivant la session et, d'autre part, des données de session, ledit dispositif de gestion comprenant des moyens de sélection d'au moins une desdites informations de constitution en cours de déroulement de ladite session.

Un tel dispositif comprendra avantageusement de manière générale des moyens de mise en œuvre du procédé de gestion de session tel que décrit précédemment.

Dans un autre mode de réalisation, 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. Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de gestion de session 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, déjà décrite, est un diagramme de blocs présentant le principe de transfert de session selon l'art antérieur ; la figure 2 présente un diagramme de bloc de la constitution d'une session selon l'invention ;

la figure 3 est un schéma fonctionnel qui représente mode de fonctionnement possible d'un système de télécommunication dans lequel un procédé de transmission selon l'invention est mis en œuvre ; la figure 4 décrit une architecture simplifiée d'un serveur de gestion de données de session selon l'invention.

L'invention propose une transmission asynchrone des données applicatives d'une session. L'invention permet de gérer les sessions d'usage dans la cadre de la mise en œuvre de services rendus à un client par un fournisseur de services (tel qu'un serveur), lorsque par exemple, le client intervient depuis un premier réseau de communication, de type Réseau Téléphonique Commuté et que les services sont mis en œuvre au sein d'un deuxième réseau de communication, par exemple du type Internet.

Une session d'usage peut être définie comme incluant une chaîne d'activations successives d'un ou plusieurs moyens de communication, tels par exemple un terminal mis à disposition d'un utilisateur ou des serveurs mis en œuvre par des clients d'un système de communication.

Le principe général de l'invention repose sur la connaissance des données d'une session et notamment sur la prise en compte des informations de constitution de la session lors de la transmission des données de la session aux clients qui en font la demande. Ainsi, l'invention permet de ne transmettre à un moment donné, que les données et informations utiles au déroulement de l'application et ce qu'il s'agisse d'une transmission d'un premier client vers un second client ou d'un client vers un système de gestion de données de session et vice versa. La solution proposée repose sur la mise en œuvre, au sein d'un système de gestion de données de session, de la capacité à recevoir de ses clients et à leur délivrer des données applicatives relatives à une session d'usage en suivant deux principes :

Scinder les blocs de données applicatives échangés de client à client (via le serveur de données de session) ou de client à serveur de données de

session, en un en-tête et un corps. Ces deux éléments peuvent être transmis séparément ou ensemble, selon les besoins.

L'en-tête du bloc a vocation à décrire (données constitutives) le contenu du bloc de données applicatives. Le corps du bloc du bloc de données a quant à lui vocation à contenir les données applicatives.

Permettre en outre l'intégration dans l'en-tête de bloc de petits volumes de données applicatives. Le corps du bloc de données sert alors à contenir les données dans le cas de forts volumes.

Ainsi, dans le cas de données peu volumineuses, un client peut communiquer ou se voir communiquer en un seul message toutes les données applicatives (celles des échanges de client à client) et leur descriptif.

Dans le cas de fort volume, seules les données descriptives sont transmises dans un premier temps. Ces données descriptives peuvent comprendre des données applicatives de faible volume. Dans un second temps, à la demande du client, les données applicatives ayant le plus fort volume sont transmises.

De cette façon, le procédé selon l'invention parvient à concilier la faible granularité des messages, pour une meilleure maîtrise des charges réseau et applicatives, avec la possibilité néanmoins de transporter rapidement d'un coup les informations relativement peu volumineuses. Par la suite, on présente notamment le cas d'un système de gestion des données de session autorisant le transfert de plusieurs niveaux de détail dans la communication des informations de session à un client cible. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre 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 objectifs listés par la suite sont intéressants.

Description d'un mode de réalisation

On présente dans ce mode de réalisation, la mise en œuvre d'un système de gestion des données de session autorisant le transfert de plusieurs niveaux de détail dans la communication des informations de session à un client cible. Pour ce faire, on décrit une implémentation d'une session selon l'invention, ainsi que la gestion des droits d'accès à ces données de session en fonction d'informations présentes dans les données de sessions.

Session

Afin de permettre l'échange en applicatifs de services de données de contexte de session d'usage tant dans un environnement de services informatiques que télécoms, le serveur de données de session intègre donc des mécanismes de gestion de sessions, de gestion des opérations portant sur les sessions, sur les informations et données et sur les corrélants réseaux (ou jetons) associés aux sessions, et de gestion des messages associés au lancement ou à l'exécution de ces opérations.

Un corrélant réseau est une information permettant de rapprocher le réseau des plateformes de service (tel qu'un intranet technique contenant des plateformes de service, apte à rendre les services fournis à un utilisateur) et le réseau utilisateur (par exemple un réseau téléphonique, un domaine Internet lié à un opérateur). Plus précisément, un corrélant réseau peut être établi lors d'un appel à un serveur de rappel, dans le but par exemple d'établir une liaison téléphonique entre Paris et New- York en passant par la Jamaïque. Le serveur de rappel, basé en Jamaïque, établit une liaison téléphonique entre la Jamaïque et la France puis entre la Jamaïque et les Etats-Unis. Pour conserver une même session de service, le serveur de rappel utilise un corrélant. Ainsi, il s'assure que les données vocales seront correctement acheminées entre les différents réseaux téléphoniques utilisés dans cette session.

Au sein du serveur de données de session, une session : est désignée par un identifiant (Id) public unique (unique sur une période donnée, qui peut être infinie) ;

est accessible selon des droits et des règles ; référence et/ou contient des données, qui peuvent être structurées en blocs.

Le serveur de données de session intègre des mécanismes de gestion des opérations portant sur les sessions. Ainsi, au sein du serveur de données de session, une session peut, par exemple, être l'objet des opérations suivantes : création, à l'initiative d'un client (dit client initiateur ou initiateur) ou d'un ou de plusieurs systèmes liés au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session ; association/dissociation à un corrélant, temporaire ou permanent, local ou global (en référence à un ou plusieurs réseaux), destiné à être véhiculé sur un ou plusieurs réseaux, à l'initiative d'un client ou d'un ou de plusieurs système lié au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session. Ce corrélant est destiné à permettre aux clients de rapprocher événements réseaux et sessions et au serveur de données de session de vérifier les droits d'accès des clients à la session ; clôture ou fermeture, à l'initiative de clients ou du serveur de données de session, par exemple sur minuterie, ou dans le cadre de l'exécution d'une stratégie de sécurité ; maintien, par exemple à l'initiative d'un client qui ne souhaite pas la voir close pour une période donnée (éventuellement infinie) ; archivage de tout ou partie des informations et données attachées à la session, à l'initiative de clients ou du serveur de données de session, par exemple sur minuterie ; association/concaténation/fusion à une ou plusieurs autres sessions, à l'initiative d'un client ou d'un ou de plusieurs systèmes liés au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session ; dissociation en plusieurs sessions, à l'initiative d'un client ou d'un ou de plusieurs systèmes liés au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session ; - écriture et/ou lecture et/ou modification et/ou exécution de droits et/ou de

règles de droits portant sur la session et/ou son contenu, à l'initiative d'un client ou d'un ou de plusieurs systèmes liés au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session ; association/dissociation d'informations ou de données relativement à la session, à l'initiative d'un client ou d'un ou de plusieurs système lié au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session ; écriture ou lecture ou modification ou exécution d'informations ou de données associées à la session ou à son contenu, à l'initiative d'un client ou d'un ou de plusieurs systèmes liés au(x) réseau(x), interne(s) ou externe(s) au serveur de données de session.

L'identifiant de session est créé lors d'une demande de création de session émanant d'un client. Cet identifiant permet ensuite aux clients du serveur de données de session de s'échanger des informations et données relativement à cette session, pour peu qu'ils en aient le droit. Le client initiateur d'une session demande sa création au serveur de données de session. L'identifiant de cette session (Id public de session) doit être unique. Il est généré soit : par un système externe au client et au serveur de données de session, et est fourni par le client au serveur de données de session ou par le serveur de données de session au client ; par le client (Id privé de session, privé par nature), ce qui nécessite pour le rendre unique un traitement supplémentaire (opéré par le client ou le serveur de données de session), comme par exemple : concaténation d'un identifiant (ou adresse) du client à I ¹ Id privé de session fourni par ce client ; si le client fournit un Id privé de session au serveur de données de session, celui-ci retourne au client I ¹ Id public de la session.

On décrit, en relation avec la figure 2, une implémentation possible d'une session 200. Une session 200 est composée d'un identifiant 2001, d'informations

de session et de contextes de branches de session (201 à 20In). Les informations de session comprennent : des droits et des règles 2002 ; un identifiant d'un client créateur 2003 de la session ; - une information représentative de la date et de l'heure de début de session 2004 ; une information représentative de la date et de l'heure prévue de fin de session 2005 ; une information représentative de la fermeture de la session 2006. La session peut être découpée sous la forme de branche (201 à 20In) lesquelles peuvent correspondre à l'exécution de services ou d'application différentes en relation avec la session. Une telle branche 201 de session est composée d'un identifiant 2011, d'informations de branches et de blocs de session (202 à 202n). Les informations de branche comprennent : - des droits et des règles 2012 ; un identifiant d'un client créateur 2013 de la branche ; une information représentative de la date et de l'heure de début de branche 2014 ; une information représentative de la date et de l'heure prévue de fin de branche 2015 ; une information représentative de la fermeture de la branche 2016 ; une identification des clients participants à la branche 2017.

Les branches de session peuvent contenir des blocs de session. Ces blocs de session comprennent notamment des données de sessions qui peuvent être des données applicatives relatives à l'exécution de services ou d'application en relation avec des actions effectuées par exemple par le client initiateur.

Un tel bloc de session 202 est composée d'un identifiant 2021, d'informations de blocs d'un contenu de bloc 2024. Les informations de bloc comprennent : - des droits et des règles 2022 ;

un identifiant d'un client créateur 2023 du bloc ; des informations relatives au contenu des données applicatives du bloc 203 comprenant : une information représentative de la taille des données applicatives du bloc 2031 ; une indication d'un cryptage 2032 des données applicatives du bloc ; une signature 2034 des données applicatives du bloc ; les données applicatives 2024 du bloc ; Dans un mode de réalisation particulier, les sessions peuvent être monobranche, auquel cas la session 200 comprend à la racine les blocs de session 202 à 202n.

Ainsi, une session selon l'invention peut être représentée sous la forme d'une structure arborescente hiérarchique dont le nœud père est la session 200 comprenant des nœuds fils 201 à 201n, correspondants aux branches de la session, une branche comprenant des nœuds fils 202 à 202n, correspondants aux blocs de la sessions, lesquels contiennent les données applicatives de la session. Une session est donc composée de données (applicatives) et d'informations de constitution de la session servant à la gestion de celle-ci. Très schématiquement, on peut représenter une session comme étant constituée de données qui vont servir aux applications ou aux services mis en œuvre au cours de la session et d'information nécessaires à l'interaction entre les différents clients (et le serveur de données de session) intervenants dans la session.

Chaque bloc contient une information représentative de la taille des données applicatives contenues dans le bloc. Ainsi, il est possible de connaître la taille des données applicatives de chaque bloc, des branches et de la session.

La session est un principe bien connu de l'homme du métier. La description qui en est faite ici permet de décrire le procédé de transmission de données selon l'invention. Il va de soit que tout autre implémentation d'une session peut être utilisée dans le cadre de l'invention. L'invention retient des

sessions qu'elles peuvent être identifiées et qu'elles matérialisent un lien existant entre des clients d'un système de communication et/ou d'information. Le terme « client » désignant ici une entité qui sollicite les ressources d'une autre entité pour exécuter une tâche. Droits d'accès aux données de session

Le serveur de données de session intègre également 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éfinies 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 œuvre 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.

Dans un mode de mise en œuvre, pour les clients et les groupes de clients autorisés à accéder à une session, les droits associés à des ou aux blocs de données peuvent être prioritaires par rapport aux droits associés à la session. De même, l'initiateur peut se voir attribuer de façon intangible ou seulement implicitement tous les droits sur une session et son contenu. Pareillement, le créateur d'un bloc

de données peut se voir attribuer de façon intangible ou seulement implicitement tous les droits sur ce bloc et son contenu. On peut également choisir de n'autoriser l'affectation de droits à des groupes fermés de clients qu'aux clients membres de ces groupes fermés de clients. Enfin, au sein des groupes fermés de clients ou bien de façon globale au sein de l'ensemble des clients du serveur de données de session, le serveur de données de session peut distinguer les clients ou sous-groupes fermés de clients autorisés ou non, de façon plus statique, à être initiateurs de sessions.

La structuration des données en blocs permet quant à elle aux clients émetteurs de distribuer des informations et des données à des clients et groupes fermés de clients cibles spécifiques librement choisis. Pour peu qu'il soit définit comme cible ou qu'il appartienne à un groupe fermé de clients cible, et qu'il soit en possession d'un corrélant valide pour une session, un client peut prendre connaissance des informations et accéder aux données autorisées par le ou les émetteurs.

Transmission des informations de session

La présente invention permet donc de distribuer les données de session en fonction des besoins des clients. Ainsi, le serveur de données de session gère les demandes concurrentes aux données de sessions sans surcharger le réseau de communication. Il maintient également la cohérence des données de session en s'assurant qu'elles ne font pas l'objet de mises à jour en parallèle par des ressources différentes.

On présente, en relation avec la figure 2, un mode de réalisation du procédé de transmission des données et des informations constitutives de ces données selon l'invention.

Un système de télécommunication SYST est voué à assurer une transmission de données DAT entre un terminal, par exemple un radiotéléphone, un agenda personnel muni de fonctionnalités d'émission/réception, ou encore un micro-ordinateur ou une console multimédia, mis à disposition d'un utilisateur USR du système SYST, et une multiplicité de moyens de communication, dans

l'exemple décrit ici des serveurs de données amont et aval SERVA et SERVB, tous ces moyens de communication étant aptes à communiquer les uns avec les autres via des liaisons de données DLU, DLA et DLB établies au sein d'un réseau de communication principal formé par un réseau de téléphonie commuté CTNW de type RTC.

Dans le mode de mise en oeuvre de l'invention représenté ici, le service rendu consécutivement à une requête AxRq(T) émise par l'utilisateur est mis en œuvre par le biais de deux serveurs SERVA et SERVB, communicant avec l'utilisateur USR par le biais d'une plate-forme de réseau intelligent INPF qui aiguille les données DAT émises par le terminal de l'utilisateur USR vers le serveur de données amont SERVA qui aura été identifié par la plate-forme INPF comme mieux à même de répondre à la requête émise par l'utilisateur USR, et donc comme premier destinataire de la communication qu'aura initiée l'utilisateur USR. Les données DAT sont échangées entre la plate-forme INPF et le serveur SERVA par le biais d'une interface de communication DLA. La plate-forme de réseau intelligent INPF inclut usuellement un commutateur d'accès SAC piloté par un point de commande de services SCP et est en elle-même bien connue de l'homme du métier, de sorte qu'elle ne sera pas davantage décrite ici.

Lorsque le serveur amont SERVA recevra de la part du terminal de l'utilisateur les données DAT, il recevra simultanément des informations de constitution relatives auxdites données DAT, et devra veiller à leur intégrité, ainsi qu'à leur mémorisation le cas échéant. En effet, il adviendra souvent que le serveur amont SERVA ne soit pas capable, à lui seul, de procéder à un traitement exhaustif de la requête AxRq(T) émise par l'utilisateur USR, auquel cas ledit serveur amont SERVA devra faire appel à un autre serveur SERVB, dit serveur aval, pour traiter certains aspects de cette requête. Dans une telle hypothèse, le serveur amont SERVA avertira la plate-forme INPF de la nécessité de l'intervention du serveur aval SERVB, lequel sera alors sollicité par ladite plateforme INPF et se verra communiquer par le serveur amont SERVA les données

qu'il est destiné à traiter, par l'intermédiaire d'une interface de communication DLB.

Par exemple, le serveur amont SERVA pourra supporter un service de fourniture de renseignements d'ordre général et recevoir de la part de l'utilisateur USR une requête aux fins de se voir connecter à un club de philatélie proche de sa localisation géographique, qui est incluse dans les informations de constitution. Le serveur aval SERVA correspondant au club de philatélie ciblé sera alors attrait dans la session en cours en vue de satisfaire la requête de l'utilisateur USR. Les mises en relation successives du terminal de l'utilisateur USR avec le serveur amont SERVA, puis du terminal de l'utilisateur USR avec le serveur aval SERVB s'inscrivent dans une même chaîne d'activations successives de moyens de communication et sont donc incluses dans une même session, par exemple sous la forme de deux branches constitutives de la session ou encore sous la forme de blocs de sessions consécutifs. Dans le mode de mise en oeuvre de l'invention représenté ici, lorsque le serveur amont SERVA aura reçu la requête initiale AxRq(T) et en aura déduit que l'intervention d'un serveur aval est au moins partiellement nécessaire au traitement de ladite requête, ce serveur amont SERVA établira une communication avec un Serveur de données de session serveur de données de session, afin d'organiser un adressage spécifique des informations de constitution reçues en parallèle avec cette requête initiale AxRq(T) sous la forme d'une session telle qu'elle a été décrite précédemment. La constitution des identifiants de session a déjà fait l'objet d'une description précise dans la demande FR0502197, de sorte qu'elle ne sera pas d'avantage décrite ici. Le Serveur de données de session serveur de données de session est apte à communiquer via un réseau de communication spécifique SCNW, par exemple un réseau de type Intranet dédié (tel qu'un intranet technique comportant des plateformes de service), avec les différents moyens de communication destinés à être activés en cours de session. Les communications des serveurs SERVA et

SERVB avec le serveur de données de session sont mises en œuvre par le biais de deux interfaces de communication SLA et SLB.

Dans ce mode de mise en œuvre de l'invention, le serveur SERVA charge le serveur de données de session serveur de données de session de maintenir la session. Lorsque le serveur de données de session serveur de données de session reçoit une requête de transmission de données applicatives contenues dans la session de la part du serveur SERVB, il transmet à celui-ci une information de constitution de la session. Cette information de constitution de session est représentative de la requête émise par le serveur SERVB. Ainsi, dans ce mode de réalisation, le serveur de données de session peut autoriser plusieurs niveaux de détail dans la communication des informations à un client cible, comme par exemple le serveur SERVB. Ce dernier peut par exemple demander et recevoir : une communication de I ¹ Id public de session ; une communication de la description de la session ; - une communication de la description de tout ou partie des blocs de la session ; une communication des données de tout ou partie des blocs de la session.

Ainsi, un client du serveur de données de session peut dans un premier temps, requérir une description de la session puis dans un second temps, faire la demande des seules données de bloc qui lui sont utiles. On optimise ainsi grandement le transfert des données sur le réseau dédié.

Dans un mode de réalisation particulier, la communication par le serveur de données de session de la description de la session et celle de tout ou partie des blocs de la session peut être couplée, en fonction de paramètres liés à la taille de données de session. Ainsi, le serveur de données de session peut, en fonction d'une taille de corps de bloc et de paramètres liés à la charge du réseau et à la bande passante disponible, par exemple, décider : de transmettre les informations descriptives de la session, dans le cadre d'une première réponse à une requête émise par un client (par exemple SERVB) ;

de transmettre les données de session dans le cadre d'au moins une deuxième réponse à la même requête.

De cette façon, le client reçoit dans un premier temps un descriptif des données qui lui permet de préparer l'exécution du service requit. On augmente alors les capacités de traitement des clients et on diminue la charge du réseau.

De même, en matière de droits, dans certains modes de mise en œuvre, une priorisation des droits « blocs » et des droits « session » peut être opérée. Le serveur de données de session autorise plusieurs niveaux de détail dans la communication de ses droits ou des droits d'autres clients ou groupes fermés de clients à un client donné : communication des seuls droits propres au client demandeur résultants de l'application des règles de priorisation des droits ; communication des droits bruts détaillés propres au client demandeur, et, sous réserve qu'il soit un client autorisé : - communication, au client demandeur, de droits concernant un ou plusieurs clients ou groupes fermés de clients et résultants de l'application des règles de priorisation des droits, communication, au client demandeur, des droits bruts détaillés concernant un ou plusieurs clients ou groupes fermés de clients. Ce mode de réalisation particulier nécessite la mise en place d'un protocole de communication permettant l'échange de messages de description de session entre le serveur de données de session et ses clients.

Dans un mode de mise en œuvre particulier, il est envisageable de ne pas définir de protocole de communication spécifique. Ceci est rendu possible par la connaissance, par le serveur de données de session, des services rendus par les différents clients de la plate-forme. Ainsi, le serveur de données de session, détermine, en fonction du client qui lui en fait la demande, les informations dont celui-ci à besoin. Du fait de la structure arborescente de la session telles qu'elle a été préalablement définie, le serveur de données de session est bien en mesure de ne transférer à un client que les informations et les données de session le

concernant, tout en maintenant en condition opérationnelle l'intégralité de la session et ce en respectant les droits liés aux clients.

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 requêtes d'obtention de données de session 44. Ces informations sont traitées par le microprocesseur, selon les instructions du programme 42, pour : émettre des descriptions de session 46a ; émettre des données de session 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.