Brevet FR2811496A1 — publié le 20020111

DISPOSITIF D'INTERMEDIATION ENTRE DES STATIONS RELIEES A UN RESEAU DE COMMUNICATION La présente invention concerne la fourniture de services à distance par l'intermédiaire de réseaux de télécommunications. Elle s'applique notamment, mais non exclusivement, aux réseaux fonctionnant selon le protocole IP (" Intemrnet Protocol "). Dans le passé, les consommateurs et les producteurs de services à distance avaient des relations directes à travers le réseau de télécommunication, lequel fournissait des ressources leur permettant de dialoguer dans le cadre de sessions consacrées à ces services. Avec l'avènement de l'lnternet, il est de plus en plus fréquent que les consommateurs et producteurs de services n'interagissent plus directement, mais à travers un niveau d'intermédiation. Un dispositif d'intermédiation dialogue d'une part avec le producteur de services et d'autre part avec le consommateur afin de transmettre les requêtes de ce dernier après un traitement éventuel et de lui présenter les éléments d'information concernant les services concernés. Le dispositif d'intermédiation peut former un serveur " proxy " dont le rôle est de regrouper sous une adresse unique vis-à-vis des serveurs extérieurs les éléments provenant ou destinés à un ensemble de terminaux clients. Le dispositif d'intermédiation peut également jouer un rôle de portail, c'est-à-dire fournir aux terminaux clients une interface d'accès pour différents services disponibles à travers le réseau Internet. Cette interface d'accès comporte typiquement des pages d'accueil contenant des liens vers différents services proposés tels que messagerie électronique, annuaire électronique, bases de données ou toutes sortes de services Web. Les liens permettent aussi de " naviguer " entre divers services gérés par des serveurs dédiés Certains portails proposent une personnalisation de l'interface d'accès, permettant aux utilisateurs de définir la façon dont les services vont lui être présentés (personnalisation de l'affichage, liste de " favoris ",...) et/ou de filtrer les services auxquels il aura accès. Un but de la présente invention est d'enrichir les services proposés à partir de dispositifs d'intermédiation, sans requérir obligatoirement une -2- multiplication ou une modification des serveurs dédiés existants. L'invention propose ainsi un dispositif d'intermédiation entre des stations reliées à un réseau de communication et incluant des serveurs dédiés gérant des services respectifs. Le dispositif comprend des moyens d'intégration de services et des moyens d'interface entre les moyens d'intégration de services et les stations. Les moyens d'intégration de services comprennent une mémoire o sont enregistrés des scripts définissant des services supplémentaires dont l'exécution comporte l'invocation de services gérés par les serveurs dédiés, et des moyens de contrôle coopérant avec la mémoire de scripts pour exécuter des services supplémentaires en réponse à des messages provenant de certaines au moins des stations. Ce dispositif d'intermédiation n'est pas une simple plate-forme de navigation entre les services offerts par les serveurs dédiés. Il propose lui- même des services supplémentaires fondés sur ceux auxquels sont dédiés les serveurs reliés au réseau. De préférence, les moyens d'intégration de services communiquent avec les moyens d'interface en échangeant des pages de données balisées, en particulier selon un langage XML (" eXtended Markup Language "). Les scripts définissant les services supplémentaires peuvent alors être enregistrés dans la mémoire des moyens d'intégration sous forme de pages de données balisées décrivant les paramètres et données d'entrée et de sortie des procédures invoquées dans le cadre des services extérieurs. Cette architecture donne une grande flexibilité dans le déploiement des services proposés sur le réseau. En particulier, le créateur de services supplémentaires peut se procurer des serveurs dédiés à différents services auprès de fournisseurs différents, en tenant compte du savoir-faire de ces fournisseurs, des technologies mises en oeuvre et/ou des conditions de prix pratiquées. L'ensemble des services supportés par ces serveurs sera fusionné au niveau du dispositif d'intermédiation, grâce auquel le créateur de services supplémentaires pourra en outre, selon ses besoins, définir toutes sortes de services à valeur ajoutée, en décrivant ces services ainsi que les messages d'entrée et de sortie pris en compte dans l'invocation des serveurs dédiés dans un langage de balisage, tel que XML. Les scripts étant écrits dans ce même langage, on a un format unique au niveau des moyens d'intégration de service, ce qui facilite la multiplication des services spécifiques. -3- Lorsque les stations reliées au réseau comprennent des terminaux d'abonnés, les moyens d'interface comprennent avantageusement des moyens de gestion de contextes d'abonnés pour établir des sessions de communication avec les abonnés, et des moyens de présentation de services aux terminaux dans le cadre de sessions établies entre les moyens de gestion de contextes et les abonnés utilisant lesdits terminaux. Ceci permet de gérer de façon autonome les abonnés et les terminaux. Le dispositif d'intermédiation joue alors un rôle de portail, fournissant en outre des services à valeur ajoutée, de façon particulièrement simple et flexible. Dans un mode de réalisation préféré, les moyens de présentation comprennent des moyens d'interprétation des pages transmises par les moyens de gestion de contextes dans le cadre d'une session en cours avec un abonné utilisant l'un des terminaux, de façon à générer des commandes adaptées à la présentation sur le terminal d'éléments d'interaction décrits par les données balisées de la page. Ceci permet de raccorder au réseau des terminaux très simples (" thin terminaIs ") qui pourront néanmoins disposer des services rendus à travers le dispositif d'intermédiation, y compris les services supplémentaires à valeur ajoutée. Dans une autre réalisation de l'invention, les moyens de contrôle sont prévus pour exécuter des services supplémentaires en réponse à des messages de requête provenant de serveurs dédiés. Le dispositif d'intermédiation peut ainsi jouer un rôle de " portail inverse " vis-à-vis des serveurs reliés au réseau. D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels: - la figure 1 est un schéma illustrant un exemple de réseau de télécommunication intégrant un dispositif selon l'invention; - la figure 2 est un schéma général d'un dispositif selon l'invention; - la figure 3 est un schéma d'un autre mode de réalisation d'un dispositif selon l'invention. Dans l'exemple de réalisation de l'invention décrit en référence aux figures 1 et 2, des équipements terminaux de différents types ont accès, par I'intermédiaire d'un réseau de communication d'entreprise et d'un dispositif selon l'invention, à des services diversifiés de téléphonie, d'accès à des bases -4- de données, d'annuaire, de messagerie unifiée (c'est-à-dire vocale ou électronique), de navigation Web sur un réseau Internet ou Intranet qui sont fournis par un ensemble de serveurs dédiés reliés au réseau. La figure 1 montre les terminaux de différents types (par exemple poste mobile 100, micro-ordinateur 101, poste RNIS doté d'un adaptateur IP 102, poste natif IP 103) raccordés à un réseau de communication en mode paquet 300 fonctionnant selon le protocole IP. Le réseau 300 peut être un réseau local (LAN, " Local Area Network ") dont est équipée une organisation pour fournir des services de transmission de données aux détenteurs des terminaux 100- 103. Il est par exemple constitué de plusieurs sous-réseaux de type Ethernet entre lesquels la commutation des paquets IP est effectuée de façon classique par des routeurs non représentés. Plusieurs serveurs, dédiés aux services considérés, sont par ailleurs connectés au LAN 300: un serveur de téléphonie 200, un serveur d'annuaire 201, un serveur messagerie unifiée 202, un serveur de navigation Web 203, ainsi qu'un serveur gestionnaire de bases de données (SGBD) 204. Ces serveurs dédiés communiquent selon des protocoles propres aux types de services qu'ils gèrent, par exemple SIP (" Session Initiation Protocol ") pour la signalisation téléphonique sur IP, LDAP (" Lightweight Directory Access Protocol ") pour les services d'annuaire, SMTP (" Simple Mail Transfer Protocol ") ou IMAP (" Internet Message Access Protocol ") pour la messagerie, ou HTTP (" HyperText Transfer Protocol ") pour la navigation Web, etc. Des constructeurs proposent maintenant des serveurs capables de dialoguer avec leur environnement selon des langages de la famille XML adaptés aux services concernés, par exemple DSML (" Directory Service Markup Language ") pour les services d'annuaire. De tels serveurs sont également utilisables dans l'architecture de la figure 1. Un dispositif d'intermédiation selon l'invention 400 est raccordé au LAN 300. Ce dispositif remplit une fonction de serveur proxy, c'est-à-dire que, pour accéder aux services gérés par les serveurs dédiés 200-204 du réseau 300, les terminaux 100-103 ne peuvent ouvrir de session qu'avec le dispositif 400. D'autre part, la signalisation entrante relative à ces services ne peut être adressée aux terminaux que par l'intermédiaire du dispositif 400. Le dispositif 400 remplit également une fonction de portail, c'est-à-dire qu'il présente aux terminaux 100-103 une interface d'accès aux différents -5- services disponibles. Bien entendu, il est possible que certains des serveurs 200-204, 400 soient réalisés dans une plate-forme commune. Le dispositif d'intermédiation 400 peut être vu comme ayant une architecture de type trois-tiers intégrée, dont la figure 2 montre les trois étages 410,420, 430. L'étage d'accès aux services 410 (entité métier) regroupe l'ensemble des traitements spécifiques aux différents services gérés par les serveurs dédiés 200-204. Il réalise l'interface du dispositif d'intermédiation 400 avec les différents serveurs dédiés 200-204, et échange des données en provenance et à destination de l'entité service 420 selon un format unifié. L'étage 420 (entité service) est lui-même divisé en deux niveaux: un intégrateur de services 421 et un gestionnaire de contextes d'abonné 426. Il réalise l'interaction entre les différents services gérés par les serveurs dédiés i5 200-204, route les requêtes en provenance de l'étage de présentation 430 vers les modules de l'étage d'accès 410, et transmet à l'étage de présentation des données en provenance de l'étage d'accès 410. Le gestionnaire de contextes 426 administre les sessions ouvertes avec les différents terminaux reliés au dispositif d'intermédiation 400. Vu de l'intégrateur de services 421, I'étage d'accès 410 forme une interface vers les serveurs dédiés 200-204, tandis que le gestionnaire de contextes 426 et l'étage de présentation 430 forment une interface vers les terminaux clients 100-103 et les abonnés qui les utilisent. L'étage de présentation des services 430 (entité présentation) contient l'ensemble des moyens de connexion et de dialogue avec les différents types de terminaux compatibles avec le dispositif d'intermédiation 400, et remplit la fonction de présentation des données reçues de l'étage 420 vers le terminal à partir duquel l'abonné destinataire des données a ouvert une session avec le dispositif d'intermédiation 400. Selon leurs caractéristiques, les terminaux 100- 103 peuvent être agencés pour communiquer selon différents types de formats et protocoles de communication. L'étage d'accès 410 et l'étage de présentation 430 sont reliés à un module 440 d'interface avec le LAN 300 qui accomplit les fonctions des couches 1 à 4 du modèle OSI. Dans l'exemple considéré, le module 440 gère les échanges du dispositif d'intermédiation 400 selon les protocoles TCP, IP et Ethernet. L'étage 410 comporte des modules d'accès 4100-4104 respectivement -6associés aux serveurs dédiés 200-204 avec lesquels ils sont capables de dialoguer à travers le module d'interface 440. Chaque module d'accès 4100- 4104 effectue les traitements relatifs à la fourniture d'un service par le serveur dédié associé 200-204 aux utilisateurs du réseau intégrant le dispositif d'intermédiation 400. On trouve ainsi, dans l'exemple considéré, un module d'accès 4100 associé au serveur dédié de téléphonie 200, un module d'accès 4101 associé au serveur dédié d'annuaire 201, un module d'accès 4102 associé au serveur dédié de messagerie 202, un module d'accès 4103 associé au serveur dédié de navigation 203 et un module d'accès 4104 associé au serveur de base de données 204. Dans un mode de réalisation de l'invention, chaque module d'accès 41004104 gère une connexion au niveau applicatif du modèle OSI avec son serveur dédié associé 200-204. La structure des données échangées et le protocole d'échange de ces données dépendent du service concerné (par exemple SIP pour la téléphonie, LDAP pour le service annuaire, IMAP4 pour la messagerie électronique, HTTP pour la navigation, etc.). Dans un autre mode de réalisation, une partie ou la totalité des serveurs dédiés 200-204 dialoguent directement avec les modules d'accès correspondants 4100-4104 selon une connexion d'un protocole de niveau transport, typiquement TCP (" Transmission Control Protocol "), et échangent des pages de données balisées fournissant des descriptions sémantiques d'éléments selon un langage XML. Des versions de XML, développées pour être adaptées à différents métiers, par exemple DSML comme indiqué ci- dessus, peuvent ainsi être utilisées pour les échanges entre le dispositif d'intermédiation 400 et les serveurs des métiers correspondants. L'étage d'accès 410 génère des pages de données balisées, c'est-à- dire des ensembles de descriptions d'éléments dont la syntaxe est commune à l'ensemble des modules d'accès 4100-4104, qu'il transmet à l'étage 420. Dans un mode de réalisation préféré de l'invention, on utilise des pages de description de données structurées au sens XML. L'intérêt de telles pages réside dans leur souplesse d'utilisation, et la possibilité de présenter des données dans un format qui peut être adapté par une simple opération de filtrage à tout type de terminal. Ces pages XML sont produites par le module d'accès 4100-4104 en traduisant les éléments reçus du serveur dédié correspondant. Dans le cas o ce dernier communique déjà selon un format XML, la traduction, si elle est -7- requise, est effectuée au moyen de transformations XSL (" XML Stylesheet Language "). Ce type de transformation est décrit dans la Recommandation " XSL Transformations (XSLT) ", version 1.0, publiée le 16 novembre 1999 par l'organisation W3C. Les pages XML délivrées par l'étage d'accès 410, dont certaines au moins sont transmises à l'étage de présentation 430, contiennent des données balisées qui décrivent, selon un format indépendant des terminaux, des éléments d'interaction avec les abonnés. Certains de ces éléments d'interaction sont à présenter de façon dynamique à l'abonné concerné par la page, le mode de présentation étant défini dans l'étage 430 en fonction du type d'interface homme-machine dont est pourvu le terminal utilisé (affichage sur écran de tel type ou telle taille, signalisation sonore, messages vocaux, etc.) et éventuellement de paramètres de configuration de l'interface homme-machine définis par l'abonné. Ces éléments présentés de façon dynamique peuvent représenter un contexte d'abonné (par exemple appel entrant, poste occupé, message reçu, etc.), de l'information fournie dans le cadre d'un service (par exemple numéro d'annuaire, contenu d'un message, page Web, etc.), des champs de saisie permettant à l'abonné d'entrer des informations utiles aux serveurs (par exemple numéro d'appel, identification de fiche annuaire, message à émettre, etc.), ou des actions que l'abonné peut sélectionner à l'aide d'un événement programmable dans l'étage de présentation (actionnement d'une touche virtuelle, commande vocale, etc.). Pour ce dernier type d'élément, les données balisées de la page XML appartiennent à un lien dynamique qui pointe vers une adresse de page. D'autres éléments d'interaction décrits dans les pages XML transmises à l'étage de présentation 430 peuvent se rapporter à des événements déterminés susceptibles de se produire au niveau des terminaux et définis de façon statique, c'est-à-dire indépendamment du contexte d'abonné et des éléments dynamiques présentés. Ces événements, définis au niveau de l'étage de présentation 430, comprennent par exemple l'actionnement par l'abonné d'une touche spéciale, I'expiration d'une temporisation, etc. Les données balisées de la page XML décrivant ce genre d'élément appartiennent à un lien statique pointant vers une adresse de page. Dans les liens précités, il est possible d'utiliser des adresses de pages similaires à des adresses URL (" Uniform Resource Locator ") couramment 8- utilisées dans les applications de navigation. Certaines adresses sont complétées par un ou plusieurs champs de paramètres utiles à la production de la page désignée, les paramètres correspondants pouvant être fournis explicitement dans la page XML transmise à l'étage de présentation 430 ou récupérés dans des champs de saisie décrits dans cette page XML. Dans l'exemple représenté sur la figure 2, l'étage de présentation 430 comporte un navigateur XML 436 qui incorpore un processeur XSL 431 ou un programme équivalent. Ce navigateur analyse, en liaison avec une mémoire 432 contenant des profils de terminaux, les pages reçues du gestionnaire de contextes 426 de l'étage 420, et contrôle les interfaces homme-machine des terminaux 100-103, lesquels peuvent n'effectuer que des traitements très limités (concept de " thin terminal "). Le processeur XSL 431 transforme la description sémantique des données dans les pages XML en un autre langage adapté à la présentation des services sur les terminaux.. Il est à noter qu'un terminal pourvu d'un logiciel de navigation adapté peut recevoir directement des pages HTML ( XML ou WML (" Wireless Markup Language ") délivrées par le navigateur 436. Le navigateur 436 surveille en outre l'occurrence des événements correspondant aux liens d'action définis dans la page XML, et signalent la détection d'un tel événement. En réponse à la détection d'un tel événement, l'étage de présentation 430 retourne au gestionnaire de contextes 426, dans le cadre de la session en cours avec l'abonné concerné, une primitive GET_URL incluant l'adresse de page du lien correspondant. Chaque création d'association d'un couple (terminal physique, abonné) par l'intermédiaire de l'étage de présentation 430 donne lieu à une requête d'ouverture de session d'abonné reçue par le gestionnaire de contextes 426 (primitive OPEN_SESSION). Celui-ci fonctionne avec une table 427 d'enregistrement des contextes des abonnés pour lesquels une session est ouverte. La requête d'ouverture de session d'abonné contient des informations indiquant entre autres un identifiant d'abonné (par exemple son numéro d'appel téléphonique) et un port logique de l'étage de présentation pour l'envoi des pages destinées à l'abonné. Elle contient de plus des informations relatives à l'authentification de l'abonné, comme par exemple un mot de passe saisi par ce dernier. Le gestionnaire de contextes 426 interroge la table 427 afin de s'assurer que l'abonné n'y est pas déjà enregistré, auquel cas il retourne un acquittement négatif NACK qui est transmis à l'étage de présentation 430. -9- Dans le cas contraire, il crée un enregistrement dans la table 427 incluant les informations contenues dans la requête d'ouverture de session, puis renvoie un acquittement positif ACK à destination de l'entité présentation. Un mécanisme de suppression d'un enregistrement est aussi prévu, par exemple, dans le cas d'une dissolution d'un couple (terminal, abonné) qui donne lieu à l'envoi par l'étage de présentation d'une requête de fermeture de session d'abonné à destination du gestionnaire de contextes (primitive CLOSE_SESSION). La réception d'un acquittement positif ACK par l'étage de présentation 430 déclenche la présentation d'une page d'accueil à l'abonné, à partir de laquelle il peut accéder aux différents services. L'intégrateur de services 421 comporte un filtre d'événements 422 qui assure les fonction suivantes: - détecter certains événements tels que remontés par l'étage de présentation 430 et qui vont générer des actions dans le cadre de services supplémentaires qui ne sont pas gérés directement par l'un des serveurs dédiés 200-204 mais par l'intégrateur de services 421. Un tel événement peut être la présence d'un URL particulier dans les données issues de l'étage de présentation pour un terminal; -signaler ces événements à un moteur d'intégration 423 en indiquant I'abonné pour lequel l'événement a été détecté et le cas échéant des données associées; - pour les autres messages remontés par l'étage de présentation 430, qui correspondent typiquement à des requêtes de pages XML à destination des modules d'accès 4100-4104, router ces requêtes vers le module concerné, par exemple sur la base de l'URL; - détecter certains événements (méta-données) décrits dans les pages XML provenant de l'étage d'accès 410 et qui vont aussi générer des actions dans le cadre de services supplémentaires gérés par l'intégrateur de services 421 signaler ces événements au moteur d'intégration 423 en indiquant l'abonné concerné et le cas échéant des données associées; - relayer les autres pages XML provenant de l'étage d'accès 410 vers le gestionnaire de contextes 426 et l'étage de présentation 430. Certains des services supplémentaires peuvent être exécutés localement dans le dispositif d'intermédiation. Mais en général l'exécution de certains au moins de ces services supplémentaires comportera l'invocation, par -10- le moteur d'intégration 423, d'un ou de plusieurs services gérés par les serveurs dédiés 200-204. Un exemple d'un tel service supplémentaire est la présentation d'appel entrant à valeur ajoutée selon le script suivant: en réponse à la détection d'un appel téléphonique entrant (dans une page XML provenant du module d'accès 4100), le filtre d'événements 422 extrait le numéro de l'appelant, puis le moteur d'intégration 423 invoque un service d'annuaire (via le module 4101) pour obtenir le nom de l'appelant, va chercher dans une boîte aux lettres électronique tous les messages concernant l'appelant (via le module 4102), ou encore va chercher des informations dans une base de données externe, et il présente toutes ces informations (ou une partie seulement) à l'abonné en même temps que l'appel entrant. Un service à valeur ajoutée similaire peut être prévu dans le cas d'un appel sortant. Il est à noter que, dans le cadre de l'invention, ce genre de service supplémentaire est défini au niveau de l'intégrateur 421 sans requérir d'adaptation particulière des serveurs dédiés 200-204 ou de leurs modules d'accès 4100-4104. Ceci procure une grande souplesse dans la définition de nouveaux services, puisque le serveur dédié à un " métier " donné (par exemple la téléphonie) n'a pas besoin de connaître les détails des autres métiers (par exemple la messagerie). De plus, il n'est pas nécessaire de faire des adaptations spécifiques de protocoles pour faire dialoguer les différents serveurs dédiés. Un autre facteur de souplesse est l'utilisation d'un langage XML pour décrire les scripts. Le moteur d'intégration 423 coopère avec une mémoire 424 o sont enregistrés, au format XML, les scripts définissant les services supplémentaires. Un méta-langage tel que XML peut décrire les entrées et les sorties de n'importe quel programme. En d'autres termes, il utilise des données dont la syntaxe définit des méta-API (une API est une interface logicielle de programmation, ou " Application Programming Interface ") permettant des interactions automatiques entre applications. Tout programme peut ainsi être décrit en XML en plaçant un nom de programme, ses paramètres et le résultat qu'il retourne entre des balises appropriées définie dans une DTD (" Document Type Description ") ou un " schéma XML ". Ainsi, un script enregistré dans la mémoire 424 peut être appelé par le moteur d'intégration 423 au moyen de son nom qui est associé à l'événement détecté par le filtre 422. Chaque script décrit des actions qui incluent l'invocation par le moteur d'intégration 423 d'un ou plusieurs services gérés par les serveurs distants 200-204, en définissant les paramètres d'entrée et de sortie des services invoqués. Les paramètres de sortie peuvent à leur tour servir de paramètres d'entrée pour l'invocation d'autres services. Finalement, le service à valeur ajoutée est présenté à l'utilisateur par le moteur d'intégration 423 par l'intermédiaire du gestionnaire de contexte 426 et de l'étage de présentation 430. Dans un autre mode de réalisation de l'invention, illustré par la figure 3, le concept d'intermédiation Internet est appliqué au bénéfice non pas des consommateurs de services comme dans l'exemple décrit en référence aux figures 1 et 2, mais des producteurs de services. Le dispositif constitue alors un " portail inverse " fournissant des services à valeur ajoutée aux serveurs reliés au réseau. Afin d'enrichir leurs services, certains producteurs ou serveurs peuvent avoir besoin d'agréger des informations provenant d'autres producteurs ou serveurs. Par exemple, en recevant une signalisation téléphonique pour un appel entrant, le serveur de téléphonie 200 peut interrompre son traitement d'appel, récupérer la localisation de l'abonné mobile dans une base de données gérée par un autre serveur 204 et poursuivre son traitement d'appel de manière pertinente. Un dispositif portail inverse selon l'invention permet alors la création de nouveaux services en exploitant la séparation entre la commutation téléphonique sur IP et la logique de services située au niveau de l'intégrateur de services 421. A titre d'exemple de service supplémentaire à valeur ajoutée rendu par un portail inverse pour un serveur de téléphonie 200, on peut citer un service de transfert d'appel en fonction de l'agenda et/ou de la mobilité de l'appelé, l'agenda et la mobilité étant gérés de manière autonome dans des serveurs distincts (bases de données). Des services à valeur ajoutée similaires peuvent être rendus vis-à-vis du serveur de messagerie 202 lors de l'arrivée de messages. Contrairement à l'exemple de réalisation décrit en référence aux figures 1 et 2, le portail inverse n'aura généralement pas la fonction de proxy - 12 - vis-à-vis des bénéficiaires des services à valeur ajoutée. En conséquence, les filtres d'événement 422 déclenchant l'exécution des services à valeur ajoutée du portail inverse seront généralement situés dans les serveurs dédiés (200, 202 dans les deux exemples de services ci-dessus). Ces filtres d'événement peuvent établir des sessions avec le moteur d'intégration 423 du portail inverse et échanger avec lui des données au format XML. Le moteur d'intégration 423 exécute le script correspondant à l'événement détecté en interrogeant les autres serveurs comme requis, puis en retournant les données enrichies sous forme d'une page XML au serveur dédié à l'origine de la o requête. - 13- REVENDICATIONS 1. Dispositif d'intermédiation entre des stations (100-103, 200-204) reliées à un réseau de communication (300) et incluant des serveurs dédiés (200-204) gérant des services respectifs, comprenant des moyens d'intégration de services (421) et des moyens d'interface (410, 426, 427, 430) entre les moyens d'intégration de services et les stations, dans lequel les moyens d'intégration de services comprennent une mémoire (424) o sont enregistrés des scripts définissant des services supplémentaires dont l'exécution comporte l'invocation de services gérés par les serveurs dédiés, et des moyens de contrôle (423) coopérant avec la mémoire de scripts pour exécuter des services supplémentaires en réponse à des messages provenant de certaines au moins des stations. 2. Dispositif selon la revendication 1, dans lequel les moyens d'intégration de services (421) communiquent avec les moyens d'interface (410, 426, 427, 430) en échangeant des pages de données balisées. 3. Dispositif selon la revendication 2, dans lequel les scripts sont enregistrés dans ladite mémoire (424) sous forme de pages de données balisées. 4. Dispositif selon la revendication 3, dans lequel les données balisées des pages de script décrivent des paramètres d'entrée et des paramètres de sortie des services gérés par les serveurs dédiés (200-204) qui sont invoqués dans l'exécution des services supplémentaires. 5. Dispositif selon l'une quelconque des revendications 2 à 4, dans lequel lesdites pages de données balisées sont des pages XML. 6. Dispositif selon l'une quelconque des revendications précédentes, dans lequel lesdites stations comprennent des terminaux d'abonnés (100103), et dans lequel les moyens d'interface comprennent des moyens de gestion de contextes d'abonnés (426) pour établir des sessions de communication avec les abonnés, et des moyens (430) de présentation de services aux terminaux dans le cadre de sessions établies entre les moyens de gestion de contextes et les abonnés utilisant lesdits terminaux. - 14- 7. Dispositif selon la revendication 6 et l'une quelconque des revendications 2 à 5, dans lequel des moyens de présentation (430) comprennent des moyens (431) d'interprétation des pages transmises par les moyens de gestion de contextes (426) dans le cadre d'une session en cours avec un abonné utilisant l'un des terminaux (100-103), de façon à générer des commandes adaptées à la présentation sur le terminal d'éléments d'interaction décrits par les données balisées de la page. 8. Dispositif selon la revendication 7, dans lequel lesdites commandes adaptées à la présentation des éléments d'interaction sur le terminal (100-103) sont décrites dans d'autres pages de données balisées selon un langage différent de celui des pages transmises par les moyens de gestion de contextes (426). 9. Dispositif selon l'une quelconque des revendications 6 à 8, dans lequel les données balisées contenues dans certaines au moins des pages transmises par les moyens de gestion de contextes (426) décrivent, en plus des éléments d'interaction avec l'abonné associé, au moins un lien entre l'un desdits éléments d'interaction et une adresse de page, et dans lequel les moyens de présentation (430) sont agencés pour associer chaque lien d'une page reçue des moyens de gestion de contextes dans le cadre d'une session en cours avec un abonné utilisant l'un des terminaux (100- 103) à un événement pouvant se produire au niveau du terminal, et pour retourner l'adresse de page dudit lien aux moyens de gestion de contextes dans le cadre de ladite session en réponse à une occurrence dudit événement. 10. Dispositif selon la revendication 9, dans lequel les liens décrits dans les données balisées contenues dans les pages transmises par les moyens de gestion de contextes (426) comprennent des liens statiques que les moyens de présentation (430) associent à des événements prédéterminés pouvant se produire au niveau des terminaux (100-103) et des liens dynamiques associés à des éléments présentés dynamiquement au niveau des terminaux. 11. Dispositif selon l'une quelconque des revendications 6 à 10, dans lequel les moyens de gestion de contextes d'abonnés (426) sont agencés pour comparer des paramètres fournis par un abonné lors d'une ouverture de - 15- session avec un identifiant d'abonné et des paramètres d'authentification mémorisés pour ledit abonné. 12. Dispositif selon l'une quelconque des revendications 1 à 5, dans lequel les moyens de contrôle (423) sont prévus pour exécuter des services supplémentaires en réponse à des messages de requête provenant de serveurs dédiés (200-204).