WO2002003658A2 - Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet - Google Patents

Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet Download PDF

Info

Publication number
WO2002003658A2
WO2002003658A2 PCT/FR2001/002140 FR0102140W WO0203658A2 WO 2002003658 A2 WO2002003658 A2 WO 2002003658A2 FR 0102140 W FR0102140 W FR 0102140W WO 0203658 A2 WO0203658 A2 WO 0203658A2
Authority
WO
WIPO (PCT)
Prior art keywords
services
subscriber
pages
presentation
terminals
Prior art date
Application number
PCT/FR2001/002140
Other languages
English (en)
Other versions
WO2002003658A3 (fr
Inventor
Hong-Loc Nguyen
Original Assignee
Eads Defence And Security Networks
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Eads Defence And Security Networks filed Critical Eads Defence And Security Networks
Priority to EP01951770A priority Critical patent/EP1312196A2/fr
Priority to AU2001272623A priority patent/AU2001272623A1/en
Publication of WO2002003658A2 publication Critical patent/WO2002003658A2/fr
Publication of WO2002003658A3 publication Critical patent/WO2002003658A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present invention relates to the provision of remote services via telecommunications networks. It applies in particular, but not exclusively, to networks operating according to the IP protocol ("Internet Protocol").
  • IP protocol Internet Protocol
  • the intermediation device can form a “proxy” server, the role of which is to group together under a single address vis-à-vis the external servers the elements originating from or intended for a set of client terminals.
  • the intermediary device can also act as a portal, that is to say providing client terminals with an access interface for various services available through the Internet.
  • This access interface typically includes home pages containing links to various services offered such as electronic mail, electronic directory, databases or all kinds of web services.
  • the links also allow you to "navigate” between various services managed by dedicated servers.
  • Some portals offer customization of the access interface, allowing users to define how the services will be presented to them (customization of the display, list of "favorites", ...) and / or filter the services to which he will have access.
  • An object of the present invention is to enrich the services offered from intermediation devices, without necessarily requiring a multiplication or modification of existing dedicated servers.
  • the invention thus proposes an intermediation device between stations connected to a communication network and including dedicated servers managing respective services.
  • the device comprises means for integrating services and means for interfacing between the means for integrating services and the stations.
  • the service integration means include a memory in which scripts are recorded defining additional services, the execution of which involves the invocation of services managed by the dedicated servers, and control means cooperating with the script memory to execute services additional in response to messages from at least some of the stations.
  • the stations connected to the network include subscriber terminals, and the interface means advantageously comprise means for managing subscriber contexts to establish communication sessions with the subscribers, and means for presenting services to the terminals in the framework of sessions established between the context management means and the subscribers using said terminals.
  • This intermediation device is not a simple platform for browsing between the services offered by dedicated servers. It acts as a portal, itself providing additional value-added services based on those to which the servers connected to the network are dedicated, in a particularly simple and flexible way, while making it possible to manage subscribers and subscribers independently. terminals.
  • the service integration means communicate with the interface means by exchanging pages of marked data, in particular according to an XML language (“eXtended Markup Language”).
  • XML language eXtended Markup Language
  • the scripts defining the additional services can then be recorded in the memory of the integration means in the form of marked data pages describing the parameters and input and output data of the procedures invoked in the context of the external services.
  • This architecture gives great flexibility in the deployment of the services offered on the network.
  • the creator of additional services can obtain servers dedicated to different services from different suppliers, taking into account the know-how of these suppliers, the technologies implemented and / or the price conditions applied. All services supported by these servers will be merged at the level of the intermediation device, thanks to which the creator of additional services may also, according to his needs, define all kinds of value-added services, describing these services as well as the input messages taken into account in the invocation of dedicated servers in a markup language, such as XML.
  • the presentation means comprise means for interpreting the pages transmitted by the context management means within the framework of a current session with a subscriber using one of the terminals, so as to generate commands adapted to the presentation on the terminal of interaction elements described by the data marked on the page.
  • This makes it possible to connect very simple terminals (“thin terminais”) to the network, which may nevertheless have the services rendered through the intermediation system, including additional value-added services.
  • FIG. 1 is a diagram illustrating an example of a telecommunications network incorporating a device according to the invention
  • - Figure 2 is a general diagram of a device according to the invention
  • - Figure 3 is a diagram of another embodiment of a device according to the invention.
  • terminal equipment of different types have access, via a corporate communication network and a device according to the invention , to diversified telephony, database access, directory, unified messaging (i.e. voice or electronic), web browsing services on an Internet or Intranet network that are provided by a set of dedicated servers connected to the network.
  • unified messaging i.e. voice or electronic
  • Figure 1 shows the terminals of different types (for example mobile station 100, microcomputer 101, ISDN station with an IP adapter 102, native IP station 103) connected to a packet communication network 300 operating according to the IP protocol.
  • the network 300 may be a local area network (LAN) with which an organization is equipped to provide data transmission services to the holders of the terminals 100-103. It is for example made up of several subnetworks of the type Ethernet between which the switching of IP packets is carried out conventionally by routers not shown.
  • LAN local area network
  • a telephony server 200 a directory server 201, a unified messaging server 202, a web browsing server 203, as well as a database manager server (DBMS) 204.
  • DBMS database manager server
  • SIP Session Initiation Protocol
  • LDAP Lightweight Directory Access Protocol
  • SMTP Simple Mail Transfer Protocol
  • IMAP Internet Message Access Protocol
  • HTTP HyperText Transfer Protocol
  • Such servers can also be used in the architecture of FIG. 1.
  • An intermediation device according to the invention 400 is connected to the LAN 300.
  • This device fulfills a function of proxy server, that is to say that, to access the services managed by the dedicated servers 200-204 of the network 300, the terminals 100-103 can only open a session with the device 400.
  • the incoming signaling relating to these services can only be addressed to the terminals through the device 400.
  • the device 400 also fulfills a portal function, that is to say that it presents to the terminals 100-103 an interface for accessing the various services available.
  • the intermediation device 400 can be seen as having an integrated three-thirds type architecture, of which FIG. 2 shows the three stages 410, 420, 430.
  • the access stage to services 410 (business entity) groups together all of the processing specific to the various services managed by dedicated servers 200-204. It performs the interface of the intermediation device 400 with the various dedicated servers 200-204, and exchanges data from and to the service entity 420 according to a unified format.
  • the stage 420 (service entity) is itself divided into two levels: a service integrator 421 and a subscriber context manager 426. It performs the interaction between the different services managed by the dedicated servers 200-204, routes the requests from the presentation stage 430 to the modules of the access stage 410, and transmits to the presentation stage data coming from the access stage 410.
  • the context manager 426 administers open sessions with the various terminals connected to the intermediation device 400. Seen from the service integrator 421, the access stage 410 forms an interface to the dedicated servers 200-204, while the context manager 426 and the presentation stage 430 form an interface to the client terminals 100-103 and the subscribers who use them.
  • the service presentation stage 430 contains all the means of connection and dialogue with the different types of terminals compatible with the intermediation device 400, and fulfills the function of presentation of the data received from the stage 420 towards the terminal from which the subscriber receiving the data has opened a session with the intermediation device 400. According to their characteristics, the terminals 100-103 can be arranged to communicate according to different types of formats and communication protocols.
  • the access stage 410 and the presentation stage 430 are connected to a module 440 for interfacing with the LAN 300 which performs the functions of layers 1 to 4 of the OSI model. In the example considered, the module 440 manages the exchanges of the intermediation device 400 according to the TCP, IP and Ethernet protocols.
  • Stage 410 comprises access modules 4100-4104 respectively associated with dedicated servers 200-204 with which they are able to communicate through the interface module 440.
  • Each access module 4100-4104 performs the processing relating to the provision of a service by the associated dedicated server 200-204 to the users of the network integrating the intermediation device 400.
  • there is an access module 4100 associated with the dedicated telephony server 200 an access module 4101 associated with the dedicated directory server 201, an access module 4102 associated with the dedicated messaging server 202, an access module 4103 associated with the dedicated navigation server 203 and an access module 4104 associated with the base server of data 204.
  • each access module 4100 associated with the dedicated telephony server 200
  • an access module 4101 associated with the dedicated directory server 201 an access module 4102 associated with the dedicated messaging server 202
  • an access module 4103 associated with the dedicated navigation server 203
  • an access module 4104 associated with the base server of data 204.
  • each access module 4100 associated with the dedicated telephony server 200, an access module 4101
  • 4100-4104 manages a connection at the application level of the OSI model with its associated dedicated server 200-204.
  • the structure of the data exchanged and the protocol for exchanging this data depends on the service concerned (for example SIP for telephony, LDAP for the directory service, IMAP4 for electronic messaging, HTTP for navigation, etc.).
  • part or all of the dedicated servers 200-204 communicate directly with the corresponding access modules 4100-4104 according to a connection of a transport level protocol, typically TCP (“Transmission Contrai Protocol”) , and exchange tagged data pages providing semantic descriptions of elements in an XML language.
  • a transport level protocol typically TCP (“Transmission Contrai Protocol”)
  • TCP Transmission Contrai Protocol
  • the access stage 410 generates tagged data pages, that is to say sets of element descriptions whose syntax is common to all the access modules 4100-4104, which it transmits on stage 420.
  • structured data description pages are used in the XML sense. The interest of such pages lies in their flexibility of use, and the possibility of presenting data in a format which can be adapted by a simple filtering operation to any type of terminal.
  • XML pages are produced by the 4100-4104 access module by translating the elements received from the corresponding dedicated server.
  • the translation if required, is carried out by means of XSL (“XML Stylesheet Language”) transformations.
  • XSL XML Stylesheet Language
  • This type of transformation is described in the Recommendation “XSL Transformations (XSLT)”, version 1.0, published on November 16, 1999 by the W3C organization.
  • the XML pages delivered by the access stage 410 at least some of which are transmitted to the presentation stage 430, contain data tagged which describe, in a format independent of the terminals, elements of interaction with the subscribers.
  • Some of these interaction elements are to be presented dynamically to the subscriber concerned by the page, the mode of presentation being defined in stage 430 as a function of the type of human-machine interface with which the terminal used is provided ( display on screen of such or such type or size, audible signaling, voice messages, etc.) and possibly configuration parameters of the human-machine interface defined by the subscriber.
  • These dynamically presented elements can represent a subscriber context (for example, incoming call, busy position, message received, etc.), information provided as part of a service (for example directory number, content a message, web page, etc.), input fields allowing the subscriber to enter information useful to the servers (for example, call number, identification of directory card, message to be sent, etc.), or actions that the subscriber can select using a programmable event in the presentation stage (actuation of a virtual key, voice command, etc.).
  • the tagged data on the XML page belongs to a dynamic link which points to a page address.
  • interaction elements described in the XML pages transmitted to presentation stage 430 may relate to specific events likely to occur at the terminal level and defined statically, that is to say independently of the subscriber context and dynamic elements presented. These events, defined at the presentation stage 430 level, include for example the actuation by the subscriber of a special key, the expiration of a time delay, etc.
  • the tagged data of the XML page describing this kind of element belongs to a static link pointing to a page address.
  • the presentation stage 430 has an XML 436 browser that incorporates an XSL 431 processor or equivalent.
  • This browser analyzes, in connection with a memory 432 containing terminal profiles, the pages received from the context manager 426 of the stage 420, and controls the man-machine interfaces of the terminals 100-103, which may only perform very limited processing (“thin terminal” concept).
  • the XSL 431 processor transforms the semantic description of the data in the XML pages into another language suitable for the presentation of services on terminals. .
  • a terminal provided with suitable navigation software can directly receive HTML pages (“HyperText Markup Language”),
  • the browser 436 further monitors the occurrence of events corresponding to the action links defined in the XML page, and signals the detection of such an event.
  • the presentation stage 430 returns to the context manager 426, as part of the current session with the subscriber concerned, a GETJJRL primitive including the page address of the corresponding link. .
  • Each pair association creation (physical terminal, subscriber) via the presentation stage 430 gives rise to a subscriber session opening request received by the context manager 426 (primitive OPEN_SESSION) .
  • This works with a table 427 for recording the contexts of the subscribers for which a session is open.
  • the subscriber login request contains information indicating inter alia a subscriber identifier (for example his telephone number) and a logical port of the presentation stage for sending the pages intended for the 'subscriber. It also contains information relating to the authentication of the subscriber, such as a password entered by the latter.
  • the context manager 426 interrogates the table 427 in order to make sure that the subscriber is not already registered there, in which case it returns a negative acknowledgment NACK which is transmitted to the presentation stage 430. Otherwise, it creates a record in table 427 including the information contained in the logon request, then returns an ACK positive acknowledgment to the presentation entity.
  • a mechanism for deleting a recording is also provided, for example, in the event of the dissolution of a couple (terminal, subscriber) which gives rise to the sending by the presentation floor of a closing request. subscriber session to destination of the context manager (primitive CLOSE_SESSION).
  • the reception of a positive acknowledgment ACK by the presentation stage 430 triggers the presentation of a home page to the subscriber, from which he can access the various services.
  • the service integrator 421 includes an event filter 422 which performs the following functions:
  • Such an event can be the presence of a particular URL in the data originating from the presentation stage for a terminal;
  • additional services can be performed locally in the intermediation facility. But in general the execution of at least some of these additional services will involve the invocation, by the integration engine 423, of one or more services managed by the dedicated servers 200-204.
  • An example of such an additional service is the presentation of value added incoming call according to the following script: in response to the detection of an incoming telephone call (in an XML page coming from the access module
  • the event filter 422 extracts the number of the caller, then the engine 423 integration invokes a directory service (via module 4101) to obtain the name of the caller, searches in an electronic mailbox for all messages concerning the caller (via module 4102), or look up information in an external database, and it presents all of this information (or only part of it) to the subscriber along with the incoming call.
  • a directory service via module 41011
  • the engine 423 integration invokes a directory service (via module 4101) to obtain the name of the caller, searches in an electronic mailbox for all messages concerning the caller (via module 4102), or look up information in an external database, and it presents all of this information (or only part of it) to the subscriber along with the incoming call.
  • a similar value-added service can be provided in the case of an outgoing call.
  • this kind of additional service is defined at the level of the integrator 421 without requiring any particular adaptation of the dedicated servers 200-204 or their access modules 4100-4104 .
  • This provides great flexibility in the definition of new services, since the server dedicated to a given “trade” (for example telephony) does not need to know the details of the other trades (for example messaging).
  • it is not necessary to make specific adaptations of protocols to make the different dedicated servers communicate.
  • the integration engine 423 cooperates with a memory 424 where the scripts defining the additional services are saved, in XML format.
  • a meta-language such as XML can describe the inputs and outputs of any program. In other words, it uses data whose syntax defines meta-APIs (an API is a software programming interface, or "Application Programming Interface”) allowing automatic interactions between applications.
  • meta-APIs an API is a software programming interface, or "Application Programming Interface"
  • Any program can thus be described in XML by placing a program name, its parameters and the result it returns between appropriate tags defined in a DTD ("Document Type Description") or an "XML schema”.
  • a script stored in memory 424 can be called by the integration engine 423 by means of its name which is associated with the event detected by the filter 422.
  • Each script describes actions which include the invocation by the engine 423 integration of one or more services managed by remote servers 200-204, by defining the input and output parameters of the services invoked. The output parameters can in turn serve as input parameters for invoking other services.
  • the value-added service is presented to the user by the integration engine 423 via the context manager 426 and the presentation stage 430.
  • the concept of Internet intermediation is applied for the benefit not of the consumers of services as in the example described with reference to FIGS. 1 and 2, but of the producers of services.
  • the device then constitutes a “reverse portal” providing value-added services to the servers connected to the network.
  • the telephony server 200 can interrupt its call processing, recover the location of the mobile subscriber in a database managed by another server 204 and continue its processing of appeal in a relevant way.
  • a reverse portal device then allows the creation of new services by exploiting the separation between telephone switching over IP and the service logic located at the level of the service integrator 421.
  • an additional value-added service rendered by a reverse portal for a telephony server 200 there may be mentioned a call transfer service according to the agenda and / or the mobility of the called party, the agenda and mobility being managed autonomously in separate servers (databases). Similar value-added services can be rendered to the messaging server 202 when messages arrive.
  • the reverse portal will generally not have the function of proxy vis-à-vis the beneficiaries of the value added services. Consequently, the event filters 422 triggering the execution of the value added services of the reverse portal will generally be located in the dedicated servers (200, 202 in the two examples of services above). These event filters can establish sessions with the integration engine 423 of the reverse portal and exchange data with it in XML format. Engine Integration 423 executes the script corresponding to the detected event by interrogating the other servers as required, then returning the enriched data in the form of an XML page to the server dedicated to the origin of the request.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)

Abstract

Les stations reliées au réseau incluent des serveurs dédiés gérant des services respectifs. Le dispositif d'intermédiation comprend des moyens d'intégration de services (421) et des moyens d'interface (410, 426, 430) entre les moyens d'intégration de services et les stations. 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.

Description

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 (« Internet 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'Internet, 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 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. Les stations reliées au réseau comprennent des terminaux d'abonnés, et 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.
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 joue un rôle de portail, fournissant en outre lui-même des services supplémentaires à valeur ajoutée fondés sur ceux auxquels sont dédiés les serveurs reliés au réseau, de façon particulièrement simple et flexible, tout en permettant de gérer de façon autonome les abonnés et les terminaux.
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 œuvre 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.
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.
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 l'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 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 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 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 , l'é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 associé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
4100-4104 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 Contrai 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 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, l'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 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 (« HyperText Markup Language »),
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 GETJJRL 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. 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 l'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 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 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 requête.

Claims

R E V E N D I C A T I O N S
1. Dispositif d'intermédiation entre des stations (100-103, 200-204) reliées à un réseau de communication (300) qui comprennent des terminaux d'abonnés (100-103), 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, 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.
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 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.
7. Dispositif selon la revendication 6, 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).
8. Dispositif selon l'une quelconque des revendications précédentes, 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.
9. Dispositif selon la revendication 8, 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.
10. Dispositif selon l'une quelconque des revendications 1 à 9, 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 session avec un identifiant d'abonné et des paramètres d'authentification mémorisés pour ledit abonné.
PCT/FR2001/002140 2000-07-06 2001-07-04 Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet WO2002003658A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP01951770A EP1312196A2 (fr) 2000-07-06 2001-07-04 Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet
AU2001272623A AU2001272623A1 (en) 2000-07-06 2001-07-04 Intermediation server for access to different services available through internet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0008800A FR2811496B1 (fr) 2000-07-06 2000-07-06 Dispositif d'intermediation entre des stations reliees a un reseau de communication
FR00/08800 2000-07-06

Publications (2)

Publication Number Publication Date
WO2002003658A2 true WO2002003658A2 (fr) 2002-01-10
WO2002003658A3 WO2002003658A3 (fr) 2003-02-13

Family

ID=8852178

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/002140 WO2002003658A2 (fr) 2000-07-06 2001-07-04 Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet

Country Status (4)

Country Link
EP (1) EP1312196A2 (fr)
AU (1) AU2001272623A1 (fr)
FR (1) FR2811496B1 (fr)
WO (1) WO2002003658A2 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MMUSIC WG: HANDLEY; SCHULZRINNE; SCHOOLER; ROSENBERG: "draft-ietf-sip-rfc2543bis-00.ps - SIP: Session Initiation Protocol" 5 juin 2000 (2000-06-05) , INTERNET ENGINEERING TASK FORCE XP002164649 alinéa 14: SIP Authentication using HTTP Basic and Digest Schemes *
ROSENBERG J ET AL: "PROGRAMMING INTERNET TELEPHONY SERVICES" IEEE NETWORK,IEEE INC. NEW YORK,US, vol. 13, no. 3, mai 1999 (1999-05), pages 42-49, XP000870630 ISSN: 0890-8044 *
SCHULZRINNE, HENNING G.; ROSENBERG, JONATHAN D.: "The Session Initiation Protocol: Providing Advanced Telephony Services Across the Internet" BELL LABS TECHNICAL JOURNAL., vol. 3, no. 4, octobre 1998 (1998-10) - décembre 1998 (1998-12), pages 144-160, XP002164648 BELL LABORATORIES., US ISSN: 1089-7089 *

Also Published As

Publication number Publication date
WO2002003658A3 (fr) 2003-02-13
EP1312196A2 (fr) 2003-05-21
FR2811496B1 (fr) 2004-05-28
FR2811496A1 (fr) 2002-01-11
AU2001272623A1 (en) 2002-01-14

Similar Documents

Publication Publication Date Title
CA2357409C (fr) Systeme de communication d'un equipement d'automatisme base sur le langage wsdl
EP1376410B1 (fr) Procédé de gestion d'informations de contexte par serveur intermédiaire
US20040083479A1 (en) Method for organizing multiple versions of XML for use in a contact center environment
WO2004068809A1 (fr) Procede de presentation d’etat d’un utilisateur utilisant plusieurs equipements de communication
CA2808275A1 (fr) Plate-forme de services informatiques distribuee
EP1104903A1 (fr) Procédé d'accès selon divers protocoles à des objets d'un arbre représentatif d'au moins une ressource de système
EP1469660B1 (fr) Procédé pour contrôler l'établissement de communications entre terminaux choisis par un utilisateur
EP1755306B1 (fr) Dispositif et procédé d'activation/désactivation à distance de services pour des terminaux de communication, via un réseau IP
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
WO2001005138A1 (fr) Gestion de telephones publics
EP1139637A2 (fr) Procédé et système d'octroi de privilèges par un gestionnaire d'accèss au sein d'un réseau de communication
EP2112811A1 (fr) Procédé et dispositif de fourniture à un appelé d'informations relatives à un appelant, sans décrochage
EP1279298B1 (fr) Dispositif de supervision de terminaux
WO2002003658A2 (fr) Serveur d'intermediation pour acces aux differents services disponibles a travers le reseau internet
EP1443702A1 (fr) Dispositif perfectionné de gestion d'équipements hétérogènes de réseau de communications
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
EP1517497B1 (fr) Serveur de profil et application aux réseaux de communication
WO2000070844A1 (fr) Procede de signalisation entre un systeme de commutation et un equipement telephonique terminal, et systeme et equipement pour la mise en oeuvre
EP1031926A1 (fr) Procédé de communication entre objects distants
WO2010023376A1 (fr) Système informatique à serveur d'accès simplifié, et procédé correspondant
EP1853040A1 (fr) Système de communication et terminaux de visualisation à basse consommation convenant à un tel système
FR2923036A1 (fr) Procede de composition automatique de services web et systeme informatique pour la mise en oeuvre d'un tel procede
FR2816416A1 (fr) Procede d'obtention de donnees par lots
FR2805625A1 (fr) Procede et systeme d'octroi de privileges par un gestionnaire d'acces au sein d'un reseau de communication
FR2900778A1 (fr) Systeme de communication et terninaux de visualisation a basse consommation convenant a un tel systeme

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 2001951770

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001951770

Country of ref document: EP

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP