FR2811496A1 - INTERMEDIATION DEVICE BETWEEN STATIONS CONNECTED TO A COMMUNICATION NETWORK - Google Patents

Abstract

The stations connected to the network include dedicated servers managing respective services. The intermediation device comprises means service integrating means (421) and interface means (410, 426, 430) between the service integrating means and the stations. The service integrating means comprise a storage unit (424) wherein are recorded scripts defining additional services whereof the execution includes invocation of services managed by the dedicated servers, and control means (423) co-operating with the script storage to execute additional services in response to messages coming from some at least of the stations.

Description

41 2811496

  INTERMEDIATION DEVICE BETWEEN STATIONS

  CONNECTED TO A COMMUNICATION NETWORK

  The present invention relates to the provision of remote services by

  through telecommunications networks.

  It applies in particular, but not exclusively, to networks

  operating according to the IP protocol ("Intemrnet Protocol").

  In the past, consumers and producers of remote services had direct relationships through the telecommunications network, which provided resources for them to

  dialogue within the framework of sessions devoted to these services.

  With the advent of the Internet, it is more and more frequent that consumers and producers of services no longer interact directly, but through a level of intermediation. An intermediation system dialogues on the one hand with the producer of services and on the other hand with the consumer in order to transmit the latter's requests after possible processing and to present him with the information concerning

the departments concerned.

  The intermediary 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 intermediation device can also act as a portal, that is to say providing client terminals with an access interface for different

  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 -2-

  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 comprise a memory o scripts are defined defining additional services whose execution includes 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.

  This intermediation device is not a simple platform for

  navigation between the services offered by dedicated servers. He himself

  even additional services based on those to which the

servers connected to the network.

  Preferably, the service integration means communicate with the interface means by exchanging tagged data pages,

  in particular according to an 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.

  procedures invoked in the context of external services.

  This architecture gives great flexibility in the deployment of

services offered on the network.

  In particular, 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 used and / or the price conditions applied. All of the services supported by these servers will be merged at the level of the intermediation device, thanks to which the creator of additional services will also be able, according to his needs, to define all kinds of value-added services, by describing these services as well as the input and output messages taken into account in the invocation of dedicated servers in a markup language, such as XML. The scripts being written in this same language, we have a unique format in terms of service integration means, which facilitates the

  multiplication of specific services.

  When the stations connected to the network include subscriber terminals, the interface means advantageously comprise means for managing subscriber contexts to establish communication sessions with the subscribers, and means for presenting services to terminals within the framework of sessions established between the context management means and the subscribers using said terminals. This allows subscribers and terminals to be managed independently. The intermediation system then acts as a portal, also providing value-added services,

  particularly simple and flexible.

  In a preferred embodiment, 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 tagged data of 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 device, including additional value-added services. In another embodiment of the invention, the control means are provided to execute additional services in response to

  request messages from dedicated servers.

  The intermediary system can thus play a role of "portal

  reverse "vis-à-vis the servers connected to the network.

  Other features and advantages of the present invention

  will appear in the description below of non-exemplary embodiments

  limiting, with reference to the accompanying drawings, in which: - Figure 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.

  In the embodiment of the invention described with reference to Figures 1 and 2, terminal equipment of different types have access, via a corporate communication network and a device according to the invention , diversified telephone services, access to databases, directory, unified messaging (i.e. voice or electronic), web browsing on an Internet or Intranet network which are

  provided by a set of dedicated servers connected to the network.

  FIG. 1 shows the terminals of different types (for example mobile station 100, microcomputer 101, ISDN station equipped with an IP adapter 102, native IP station 103) connected to a packet mode communication network 300 operating according to the protocol IP. The network 300 may be a local area network (LAN) with which an organization is equipped to provide

  data transmission services to holders of terminals 100-

  103. It is for example made up of several Ethernet-type subnets between which the switching of IP packets is carried out in a conventional manner

by routers not shown.

  Several servers, dedicated to the services considered, are also connected to LAN 300: 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 204.

  These dedicated servers communicate according to protocols specific to the types of services they manage, for example SIP ("Session Initiation Protocol") for telephone signaling over IP, LDAP ("Lightweight Directory Access Protocol") for directory services, SMTP ("Simple Mail Transfer Protocol") or IMAP ("Internet Message Access Protocol") for email, or HTTP ("HyperText Transfer Protocol") for web browsing, etc. Manufacturers now offer servers capable of interacting with their environment using languages of the XML family adapted to the services concerned, for example DSML ("Directory Service Markup Language") for directory services. Such servers are

  also usable in the architecture of figure 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,

  terminals 100-103 can only log in with device 400.

  On the other hand, the incoming signaling relating to these services cannot be

  addressed to the terminals only 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 access to the different -5-

services available.

  Of course, it is possible that some of the servers 200-204, 400

  are made in a common platform.

  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 service entity 420 in 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 various services managed by the dedicated servers i5 200-204 routes requests from the presentation stage 430 to the modules of the access stage 410, and transmits data coming from the access stage 410 to the presentation stage. The context manager 426 administers the 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 a

  interface to 100-103 client terminals and the subscribers who use them.

  The service presentation stage 430 (presentation entity) 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 floor 420 to the terminal from which the data subscriber has logged on to the

  intermediation device 400. According to their characteristics, the terminals 100-

  103 can be arranged to communicate in 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.

  The stage 410 comprises access modules 4100-4104 respectively -6 associated with the dedicated servers 200-204 with which they are capable of

  dialogue through the interface module 440. Each access module 4100-

  4104 performs the processing relating to the supply of a service by the associated dedicated server 200-204 to the users of the network integrating the intermediation device 400. Thus, in the example considered, 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 a access module 4104 associated with

database server 204.

  In one embodiment of the invention, each access module 41004104 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 the

  email, HTTP for browsing, etc.).

  In another embodiment, some 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 Control Protocol") , and exchange

  tagged data pages providing semantic descriptions

  elements according to an XML language. Versions of XML, developed for

  be adapted to different trades, for example DSML as indicated above

  above, can thus be used for exchanges between the device

  intermediation 400 and the corresponding business servers.

  The access stage 410 generates pages of marked data, that is to say

  say sets of element descriptions whose syntax is common to

  the set of access modules 4100-4104, which it transmits to stage 420. In a preferred embodiment of the invention, pages of

  description of structured data 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 operation of

filtering at any type of terminal.

  These XML pages are produced by the 4100-4104 access module by translating the elements received from the corresponding dedicated server. In the case where the latter already communicates in an XML format, the translation, if it is required, is carried out by means of XSL ("XML Stylesheet Language") transformations. This type of transformation is described in the Recommendation "XSL Transformations (XSLT)", version 1.0, published on November 16, 1999 by

W3C organization.

  The XML pages delivered by the access stage 410, at least some of which are transmitted to the presentation stage 430, contain marked data 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 size, sound signaling, voice messages, etc.) and possibly configuration parameters of the man-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.). For the latter type of element, the tagged data on the XML page belongs to a dynamic link which points to

a page address.

  Other 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 link

  static pointing to a page address.

  In the aforementioned links, it is possible to use addresses of pages similar to URL addresses ("Uniform Resource Locator") commonly 8- used in navigation applications. Certain addresses are supplemented by one or more parameter fields useful for the production of the designated page, the corresponding parameters being able to be explicitly provided in the XML page transmitted to the presentation stage 430 or retrieved in the input fields described in this page. XML. In the example shown in FIG. 2, the presentation stage 430 includes an XML browser 436 which incorporates an XSL processor 431 or an equivalent program. 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 data in XML pages in another language

  adapted to the presentation of services on terminals.

  It should be noted that a terminal provided with suitable navigation software can directly receive HTML pages (<HyperText Markup Language "),

  XML or WML ("Wireless Markup Language") delivered by the browser 436.

  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. In response to the detection of such an event, the presentation stage 430 returns to the context manager 426, within the framework of the current session with the subscriber concerned, a GET_URL 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 ensure that the subscriber is not already registered there, in which case it returns a

  negative acknowledgment NACK which is transmitted to presentation stage 430.

  -9- 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 an ACK positive acknowledgment by the presentation stage 430 triggers the presentation of a home page to the subscriber, from

  which he can access the different services.

  The service integrator 421 includes an event filter 422 which performs the following functions: - detecting certain events such as reported by the presentation stage 430 and which will generate actions in the context of additional services which are not managed directly by one of the dedicated servers 200-204 but by the service integrator 421. Such an event may be the presence of a particular URL in the data originating from the presentation stage for a terminal; signaling these events to an integration engine 423 by indicating the subscriber for whom the event has been detected and, where appropriate, associated data; - for the other messages sent up by the presentation stage 430, which typically correspond to requests for XML pages intended for access modules 4100-4104, route these requests to the module concerned, for example on the basis of the URL; - detect certain events (metadata) described in the XML pages coming from the access stage 410 and which will also generate actions within the framework of additional services managed by the service integrator 421 signal these events to the engine d 'integration 423 by indicating the subscriber concerned and, where appropriate, associated data; - relay the other XML pages coming from access stage 410 to the

  context manager 426 and presentation stage 430.

  Some of the 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 an incoming value-added call according to the following script: in response to the detection of an incoming telephone call (in an XML page originating from the access module 4100), the filter of events 422 extracts the number of the caller, then the integration engine 423 invokes a directory service (via the module 4101) to obtain the name of the caller, will search in an electronic mailbox every messages concerning the caller (via the module 4102), or else will seek information in an external database, and it presents all this information (or a part only) to the subscriber at the same time as the incoming call. A similar value-added service can be

  expected in the case of an outgoing call.

  It should be noted that, within the framework of the invention, 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 defining new services, since the server dedicated to a given "trade" (for example telephony) does not need to know the details of others

  trades (e.g. messaging).

  In addition, there is no need to make specific adaptations of

  protocols for dialoguing the different dedicated servers.

  Another flexibility factor is the use of XML for

describe the scripts.

  The integration engine 423 cooperates with a memory 424 where the scripts defining the additional services are recorded, 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.

  Any program can thus be described in XML by placing a program name, its parameters and the result it returns between tags

  appropriate defined in a DTD ("Document Type Description") or a

"XML schema".

  Thus, 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. Finally, the value-added service is presented to the user by the integration engine 423 via the context manager 426 and the stage of

presentation 430.

  In another embodiment of the invention, illustrated by FIG. 3, the concept of Internet intermediation is applied for the benefit not of consumers of services as in the example described with reference to FIGS. 1 and 2, but of producers Services. The device then constitutes a "reverse portal" providing value-added services to the connected servers

to the network.

  In order to enrich their services, some producers or servers may need to aggregate information from other producers or servers. For example, by receiving a telephone signal for an incoming call, 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 'call

in a relevant way.

  A reverse portal device according to the invention 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 integrator.

of services 421.

  As an example of 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. Unlike the embodiment described with reference to Figures 1 and 2, the reverse portal will generally not have the proxy function

- 12 - vis-à-vis beneficiaries of 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. The integration engine 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

o request.

- 13-

Claims (12)

  1. Intermediation device between stations (100-103, 200-204) connected to a communication network (300) and including dedicated servers (200-204) managing respective services, comprising means for integrating services (421) and interface means (410, 426, 427, 430) between the service integration means and the stations, in which the service integration means comprise a memory (424) where scripts are recorded defining additional services, the execution of which involves the invocation of services managed by the dedicated servers, and control means (423) cooperating with the script memory to execute additional services in response to messages originating from certain at least stations.   2. Device according to claim 1, in which the service integration means (421) communicate with the interface means   (410, 426, 427, 430) by exchanging pages of tagged data.   3. Device according to claim 2, in which the scripts are recorded in said memory (424) in the form of marked data pages. 4. Device according to claim 3, in which the tagged data of the script pages describe input parameters and output parameters of the services managed by the dedicated servers (200-204) which are invoked.   in the performance of additional services.   5. Device according to any one of claims 2 to 4, in   which said tagged data pages are XML pages.   6. Device according to any one of the preceding claims,   wherein said stations include subscriber terminals (100103), and wherein the interface means includes subscriber context management means (426) for establishing communication sessions with subscribers, and means (430 ) presentation of services to the terminals within the framework of sessions established between the context management means and   subscribers using said terminals.   - 14- 7. Device according to claim 6 and any one of   Claims 2 to 5, in which presentation means (430)   comprise means (431) for interpreting the pages transmitted by the context management means (426) within the framework of a current session with a subscriber using one of the terminals (100-103), so as to generate commands adapted to the presentation of interaction elements on the terminal   described by the tagged data on the page.   8. Device according to claim 7, in which said commands adapted to the presentation of the interaction elements on the terminal (100-103) are described in other pages of data marked up in a language different from that of the pages transmitted by the management means contexts (426).   9. Device according to any one of claims 6 to 8, in   which the tagged data contained in at least some of the pages transmitted by the context management means (426) describe, in addition to the elements of interaction with the associated subscriber, at least one link between one of said elements of interaction and a page address, and in which the presentation means (430) are arranged to associate each link of a page received from the context management means within the framework of a current session with a subscriber using one of the terminals (100-103) to an event that may occur at the terminal, and to return the page address of said link to the context management means in the context   of said session in response to an occurrence of said event.   10. Device according to claim 9, in which the links described in the marked data contained in the pages transmitted by the context management means (426) include static links which the presentation means (430) associate with predetermined events which can occur at the terminal level (100-103) and associated dynamic links   elements dynamically presented at the terminal level.   11. Device according to any one of claims 6 to 10, in   which the subscriber context management means (426) are arranged to compare parameters supplied by a subscriber during a session opening with a subscriber identifier and authentication parameters memorized for said subscriber.   12. Device according to any one of claims 1 to 5, in   which control means (423) are provided to perform additional services in response to request messages from dedicated servers (200-204).