EP1285361A1 - Multiterminal publishing system and corresponding method for using same - Google Patents

Abstract

The invention concerns a multiterminal publishing system, providing access to at least an application corresponding to a service for supplying to a plurality of terminals, in accordance with at least two different types of terminals, data contained in at least a data source. The invention is characterised in that the system comprises: at least a module (30, 301, 302, 303) for creating objects from raw data; a module (31) for generating response in a generic presentation format, in response to a request (51) made by a terminal concerning a given application; a presentation module (32), for transforming said reply in a generic presentation format specific to said terminal which has made the request.

Description

 Multi - terminal publication system and corresponding implementation method.

The field of the invention is that of communication networks, which are accessed by terminals of different types. More specifically, the invention relates to a multi-terminal publication system, making it possible to publish the same document in different formats, so as to make it searchable from different types of communication terminals.

The invention applies in particular, but not exclusively, to the publication of information available on the global Internet network, or on any other internet type network, to terminals of various types, such as WAP type terminals (in "Wireless Application Protocol"), PDA type terminals (in English "Personal Digital Assistant"), Minitel type terminals, etc. The invention also applies, for example, to the publication of information contained in databases, files, or modules of the java type.

The publication of the same information to terminals of different types is made difficult by the diversity of computer languages and communication protocols, implemented in each type of terminal. Thus, for example, mobile phones of the WAP type (in English "Wireless Application Protocol") use the WML language (in English "Wireless Markup Language"), while terminals such as personal computers implement a language of the type HTML (in English "Hypertext Markup Language"). To date, several solutions have been proposed to the problem of publishing information to terminals of different types.

A first solution, making it possible to make a service accessible to different types of terminals, consists in developing as many versions of this service as there are types of terminals which can access it. Implementation of such a solution guarantees a presentation of the quality service, adapted to the type of terminal used.

A disadvantage of this technique of the prior art is that it requires significant development time. Another drawback of this technique of the prior art is that maintenance work is made difficult by the high number of versions of the service, which increases with the number of types of target terminals.

In the case, for example, where a user wishes to access a website using a mobile phone, it is necessary, according to this first solution, to implement a gateway of WAP type (in English "Wireless Application Protocol ") between the internet type network and the mobile network, and to develop a new version of the website, built from an HTML type language (in English" Hypertext Markup Language "), which is adapted to mobile, that is to say constructed in particular from a language of the WML type (in English "Wireless Markup Language").

Another solution consists in carrying out an automatic conversion of the content of the services. For this purpose, a set of generic rules is used which make it possible, for example, to transform the HTML pages of websites into other formats, such as the WML format, or the "HTML light" format. Such generic rules can for example consist in degrading the quality of images, transforming HTML tags, etc.

The implementation of such a solution, proposed, for example, by HelpInHand ASA BabelServer (registered trademark), consists in republishing from language to language, using a suitable translator. According to this technique, the addresses of the uniform resource locators (URL, in English "Uniform Resource Locator") are simply filtered by the translator.

A drawback of this technique of the prior art is that the conversion tools used do not have the knowledge of the service processed, and the result obtained is therefore of poor quality. In particular, these tools are not capable of identifying the relevant information within the service to be converted. Another disadvantage of this technique of the prior art is that it is only suitable for the WML language, and therefore for the automatic conversion of a website, so as to make it accessible to mobile phones.

Another drawback of such a technique is that it does not allow the information contained in the website to be filtered, depending on the recipient terminal.

Yet another drawback of this technique of the prior art is that it does not make it possible to put a suitable payment system online, in particular allowing users of terminals of the WAP or PAD type for example, to access the paid services of the Internet network.

Other solutions, known as republication by predefined transformation, have been proposed, in particular in the "Portai To Go" servers from Oracle and "WebSphere Transcoding Publisher" from IBM (registered trademarks).

Thus, the "WebSphere Transcoding Publisher" module implements a transformation engine allowing, using a set of generic and specific rules, a direct transformation of the raw data extracted from information sources in HTML or XML formats, in XML format data, accessible by a plurality of terminals of different types. Such a module acts as a proxy. A disadvantage of this technique of the prior art is that the processor implemented within such a module has no intelligence and is therefore not capable of identifying the relevant information within the raw data to be transformed.

Another drawback of this technique of the prior art is that the presentation of the transformed data is directly linked to the presentation of the raw data before transformation, whatever the type of terminal used. In particular, in the case where a user wishes to access a website using a mobile phone, the implementation of the "WebSphere Transcoding Publisher" module forces the user to adopt navigation within the transformed site, same as the original website. Oracle's "Portai - To - Go" solution consists of a data extractor, composed of a plurality of extraction modules, and a transformation engine. Each extraction module is an API (in English "Application Program Interface") which allows respectively to extract raw data in HTML, XML format, or from databases for example, and convert them to XML format. In this design, an extractor performs a search for regular expressions, from a registered library, that is to say it implements a search for patterns (in English "patterns"), for example at within a given web page, based on a predetermined grammar.

The converted data is then transformed so as to be accessible to different types of destination terminals. The "Portai - To - Go" transformation engine includes as many transformation modules as there are types of terminal - destination: each of these modules allows the presentation of the converted data in XML format to be adapted to the type of terminal - destination.

A disadvantage of this technique of the prior art is that it is complex to implement.

Another disadvantage of this technique of the prior art is that it requires a high development time, due to the large number of languages (in number equal to the number of types of terminals - destination) which it is necessary to implement. works in the transformation engine.

This "Portai - To - Go" technique also has the disadvantage of providing the destination terminal with a presentation of the transformed data, which is dependent on the presentation of the original raw data.

Yet another drawback of this technique of the prior art is that the extractor used does not allow automatic monitoring of any links between different web pages. In particular, if, within a Web page, such an extractor identifies a URL address (in English "Uniform Resource Locator") referring to another web page, it does not ask to access it to extract the data it contains.

The "Portai -To -Go" technique also has the disadvantage of not making it possible to respect the tree structure of the Web page from which the information constituting the objects is extracted. Indeed, the search for regular expressions implemented does not take into account the tree structure of the page analyzed. We can then extract from the page a pattern belonging, in part, to a first branch, and, in part, to a second branch of the tree structure of the page. Thus, after extracting the raw data contained in a web page, we lose all notion of navigation within the objects contained in the analyzed page.

The invention particularly aims to overcome these drawbacks of the prior art.

More specifically, an objective of the invention is to provide a multi-terminal publication system, making it possible to publish the same document in different formats, so as to make it searchable from different types of communication terminals.

Another objective of the invention is to implement a multi-terminal publication system which is inexpensive and not very complex to implement.

The invention also aims to implement a multi-terminal publication system, which adapts to any type of data source as well as to any type of consultation terminal.

The invention also aims to provide a scalable multi-terminal publication system, making it easy to adapt to the evolution of sources of information and documents.

The invention also aims to implement a multi-terminal publication system, in which the concepts of data and presentation of data are independent. Another objective of the invention is to implement a multi-terminal publication system making it possible to filter the information from the data sources according to the terminal, or the type of terminal, for which it is intended. Another object of the invention is to provide a multi-terminal publication system having total independence of the information source and of the destination terminal, that is to say in which the processing operations implemented neither depend on nor the nature of the information extracted from the data sources, or the type of terminal for which it is intended. Yet another objective of the invention is to implement a multi-terminal publication system, in which the content and presentation of the information offered to the terminal - destination are perfectly suited to the type of terminal - destination.

The invention also aims to provide a multi-terminal publication system suitable for all light terminals.

These objectives, as well as others which will appear subsequently, are achieved according to the invention, using a multi-terminal publication system, of the type offering access to at least one application corresponding to a service, allowing providing a plurality of terminals, according to at least two distinct types of terminal, with information contained in at least one information source.

According to the invention, such a system comprises: at least one object creation module, making it possible to provide at least one function for creating objects from raw data extracted from said at least one source of information and / or generated by said at least one object creation module; a response generation module in a generic presentation format, in response to a request made by a terminal and relating to a given application, said application being defined, within said response generation module, by a plurality of contexts and a navigation policy among said contexts, each context comprising at least one action and / or at least one object, created by said at least one module for creating objects, said response resulting from navigation according to said navigation policy within said plurality of contexts; a presentation module, making it possible to transform said response in a generic presentation format into a response in a presentation format specific to the type of said terminal having formulated said request.

Thus, the invention is based on a completely new and inventive approach to multi-terminal publication, making it possible to make a document accessible to a plurality of terminals of different types. Indeed, it is based in particular on the new concept of separation of information and the presentation of information. The invention is also based on a new concept of navigation within a set of contexts, in which actions and / or objects created by the multi-terminal publication system are grouped. A response from such a system according to the invention to the request from a communication terminal is thus developed by a generic navigation technique, independent of the type of consultation terminal, which makes it possible to construct a tree structure of objects, created in whole or in part from the data contained in sites

Web, databases, files, or java modules for example. Advantageously, said response in a generic presentation format is an XML type or SGML type tree.

Indeed, the XML language (in English "Extended Markup Language"), which is a language extracted from SGML (in English "Standard Generalized Markup Language"), is a generic language particularly suitable for the publication and exchange of data.

According to an advantageous characteristic of the invention, such a system further comprises an interfacing module making it possible to intercept and analyze said request formulated by a terminal, so as to: identify the type of said terminal; create a new request, in a generic request format, intended for said response generation module.

Thus, the type of consultation terminal having been identified, the system according to the invention can return a response, the content and presentation of which are perfectly suited to the terminal that issued the request.

According to an advantageous technique, each object comprises at least one member relating to the structure of said object and at least one constructor, said at least one constructor enabling said at least one module for creating objects to inform the content of said at least one member. One can for example imagine that a "film" object consists of three members, namely a first member "film title", a second member "film summary", and a third member "director".

In an advantageous embodiment of the invention, said at least one object creation module belongs to the group comprising: - an object creation module, called a Webbike module, making it possible to provide at least one function for creating objects from raw data extracted from at least one data source containing at least one document expressed in a "markup" type language; an object creation module, making it possible to provide at least one function for creating objects from raw data extracted from at least one database of the SQL type; (in English "Structured Query

Language ", structured query language) an object creation module, constructed from a java type language, making it possible to provide at least one function for creating objects from raw data generated by said module creation of objects and / or extracted from at least one predetermined information source.

Such a system according to the invention thus makes it possible to publish on a terminal having issued a request, data coming from multiple sources of information, and in particular from websites, databases, XML-type files, as well as data generated or extracted by implementing a module java type. We can consider that an object is entirely created from data extracted from a Web site. It is also conceivable that certain members of an object are informed from data extracted from a database, and that, for example, all of the other members of the object are informed from data generated by a java type module.

The objects created by the object creation modules are preferably described using a language of the SIDL type (in English "Service Interface Definition Language"), but any other type of language adapted to the invention can also be used. Advantageously, said presentation module is constructed using a language of the XSL type (in English "Extended Stylesheet Language").

According to an advantageous characteristic of the invention, within said response generation module, said at least one application is composed, according to a first specific language, of a service container, describing said service, and of at least one context container , each corresponding to a stage of said navigation.

In order to facilitate reading, such a first specific language will be called, in the following description, the MDSP language (in English "Multi - Device Server Page"). Each application is thus composed of a service container and one or more context containers. The service container is used to describe the instructions to be executed when the application is launched. It also makes it possible to declare entities (for example variables or procedures) usable in all the application considered. The context container makes it possible to describe a context, that is to say a stage of navigation within the application considered.

There is a single service container in each application. However, as explained in the following description, the invention implements instructions allowing, during a session, to change service. For each user of a consultation terminal, the transmission of a request and the visualization of its response, during a single session, can therefore be associated with a plurality of services.

Advantageously, a container is composed of at least one component, making it possible to group together at least one instruction. Advantageously, such a system according to the invention implements six types of components: components of the "entry point" type, making it possible to describe a first plurality of operations that said response generation module must perform at launch. the execution of a service container or a context container; components of the “attributes” type, making it possible to describe a plurality of variables usable in said current container; components of the "method" type, making it possible to group a plurality of said at least one instruction within a procedure; components of the "imports" type, making it possible to describe said at least one object necessary for said response generation module, to generate said response to said request relating to a given application; components of the “processing” type, making it possible to describe a second plurality of operations that said response generation module must perform in response to an action performed by a terminal; components of the “content” type, making it possible to describe said information supplied to a terminal within said response and / or to describe said at least one action that said terminal can perform at a stage of said given navigation. Examples of components of the types set out above are presented in Annex 1. This appendix, as well as the following, is of course part of the present description in its own right.

Thus, an entry point component is characterized by its name, possibly parameters, and the set of instructions that the response generation module must perform when launching the execution of the container. service or the context container to which such an "entry point" type component belongs.

An attribute type component is used to describe variables that can be used in all the components of the current container. Thus, if the attribute component belongs to a service container, the variables that it declares are accessible from all the contexts of the application considered.

The set of instructions of a content type component allow, when executed, to generate an XML tree containing all the information that the multi-terminal publishing system according to the invention offers to the terminal having issued the request considered.

Advantageously, such a system according to the invention implements the following four types of instructions: “content” type instructions, making it possible to generate part of said response in a generic presentation format; - "variable manipulation" type instructions, making it possible to declare and / or manipulate at least one variable; "navigation" type instructions, making it possible to change the current context and / or the current application; "use" type instructions, which can be used by instructions and / or components.

According to a first advantageous characteristic of the invention, said “content” type instructions belong to the group comprising: a “content - literal” instruction, making it possible to describe a character string of said response in a generic format; - a "content - object" instruction, making it possible to describe an object; a "content - list" instruction, used to describe a list of objects; a "content - item" instruction, allowing to describe an element of a list; a "content - member" instruction, used to describe a member of an object; a "content - selection" instruction, making it possible to select an item from a list; a "content - selection - multiple" instruction, making it possible to select at least one item from a list; - a "content - entry" instruction, used to describe an item of type

"input" by which said terminal having formulated said request can enter a value; a "content - scrolling - action" instruction, making it possible to move within a list; - a "content - action" instruction, used to describe an action; a "content - action - change - of - context" instruction, making it possible to describe an action which allows said terminal having formulated said request to change context; a "content - action - context - previous" instruction, allowing said terminal having formulated said request to return to the previous context.

Thus, the instruction "content - literal", which makes it possible to describe a character string to be inserted in the XML tree constituting the response, is characterized by the character string to be inserted and the name of the node of the XML tree generated.

The "content - object" instruction makes it possible, for its part, to describe a SIDL object that the system according to the invention proposes to the terminal having sent the processed request. Such an object can be referenced by its name in all the components of the context to which the component of the "content" type belongs. In order for the "content" component which contains this instruction to be correctly executed, the "content - object" must be initialized before calling the instruction executing the "content" component.

Some examples of "content" type instructions are presented in appendix 2.

According to a second advantageous characteristic of the invention, said instructions of “variable manipulation” type belong to the group comprising: an "object" instruction, used to declare a type variable

"object"; a "list" instruction, allowing to declare a "list" type variable; a "simple" instruction, making it possible to declare a variable of type "simple", distinct from said type "object" and from said type "list"; a "create" instruction, making it possible to construct an object or a list of objects; an "establishment" instruction, making it possible to assign a value to a variable; - a "list - move" instruction, making it possible to move a current pointer from a list, by specifying a displacement step; a "list - move - to" instruction, making it possible to move a current pointer from a list, by specifying a new position of said pointer.

In fact, the MDSP language makes it possible to declare and manipulate variables, which can be used to store information or to transmit parameters.

Thus, the instruction "object" allows to declare a variable of type object.

This object can be referenced by name in all components of the current container. Before being referenced, it must be initialized using a predetermined instruction. The "object" instruction is characterized by the name of the declared variable and by an SIDL class of the object.

The "simple" instruction allows you to declare a variable of simple type, that is to say a variable that can contain a character string, an integer or a float. It is characterized by the name of the variable and by the value that this variable possibly takes on initialization.

The "create" instruction is used to build an object or a list of SIDL objects declared in the current context or in the current service. It is characterized by the name of the variable to build, the SIDL constructor to use, and the values assigned to the constructor parameters. We present, in appendix 3, some examples of instructions of type "manipulation of variables".

According to a third advantageous characteristic of the invention, said “navigation” type instructions belong to the group comprising: - a “change - context” instruction, making it possible to instantiate a new context; a "change - service" instruction, allowing to instantiate a new service; a "context - previous" instruction, allowing to return to the previous context in the current service; a "service - previous" instruction, making it possible to return to the previous context with the last context of said service.

Indeed, at a given instant, for a given client (that is to say for a given terminal having sent a request to the multi-terminal publishing system according to the invention), there is a single current context and a single current service. The MDSP language makes it possible to change this current context and this current service by means of "navigation" type instructions.

Thus, a "context-previous" instruction makes it possible to return to a previous context in the current service. The current context then becomes this context, in the state in which it was left the last time. The presentation returned to the terminal that issued the request therefore corresponds to that described by the last component of the "content" type executed on this context.

Some examples of “navigation” type instructions are presented in appendix 4. According to a fourth advantageous characteristic of the invention, said “use” type instructions belong to the group comprising: a “call” instruction, making it possible to call a “method” component in the current context or service; an "if" instruction, making it possible to establish a condition on a set of instructions; an "otherwise" instruction, following an "if" instruction and making it possible to establish a condition on a set of instructions; an "otherwise - if" instruction, following a "if" instruction and making it possible to establish at least one other condition on said set of instructions; an "execute - content" instruction, making it possible to generate a presentation of said information described in a "content"component; a "SIDL - import" instruction, used to specify an object to be used in the current service; - a "parameter - list" instruction, used to group parameter declarations; a "parameter" instruction, used to specify the value of a parameter; a "do" instruction, making it possible to group in a component of the "processing" type of actions to be performed when launching the execution of a context; an "on" instruction, allowing the grouping of conditions that must be validated for a component of the "processing" type to be executed.

Indeed, there are also, within the MDSP language, various instructions which can be used by instructions or components.

Thus, a "call" instruction makes it possible to call a method (that is to say a component of the "method" type) declared in the current context or in the current service. It is characterized by the name of the method called and by the values assigned to the parameters of the method. An "execute - content" instruction is used to trigger the generation of the presentation of the information described by a content component. It is characterized by the name of the content whose presentation we want to generate and the name of the XSL model that we want to use, if we do not want to use that of the content.

Some examples of "use" type instructions are presented in appendix 5. Advantageously, on receipt by said at least one object creation module of a request for at least one object, said request coming from said response generation module, said at least one object creation function implements at least one extraction sub-function, making it possible to inform the content of at least one member relating to the structure of said at least one object.

Advantageously, said at least one object creation function further comprises a sub-function for comparing said at least one object to which said request relates with a list of objects previously at least partially created, so as not to put implements said at least one extraction sub-function only for the creation of objects not previously created and / or to complete objects previously partially created.

Thus, if an object has already been created in response to a request, previously processed by the multi-terminal publication system according to the invention, this object is reused in the development of the response to the request being processed, and is directly sent to the response generation module.

Advantageously, within said Webbike module, each extraction sub-function is composed, according to a second specific language, of at least one Webbike page comprising at least one Webbike node, and said at least one Webbike page is synchronized with at least a document expressed in a “markup” type language from at least one data source, said at least one document itself comprising at least one node of a “markup” type language, said synchronization allowing a Webbike node to position itself on a node of a "markup" type language in order to extract raw data therefrom with a view to said creation of objects. Throughout the rest of the document, such a second specific language is called the Webbike language: the Webbike language makes it possible to create SIDL objects and to initialize the value of their attributes, from information contained in a data source of a "markup" type language The Webbike language is used to describe a complete service. Consequently, a given Webbike page can contain the description of several documents expressed in a type of language. associated "markup", for example of several HTML pages whatever the address of the server which provides them.

The principle of such a Webbike language is to tell the object creation module called Webbike module, how to search for information in HTML pages, or in XML documents, for example. For this purpose, numerous Webbike nodes (also called Webbike tags) make it possible to synchronize with the source of a language of type "markup" considered. Synchronization allows the Webbike module to position itself on a node of a markup type language, and to extract information from it, such as the value of its attributes, for example, in order to assign them to the members of objects. SIDL.

Advantageously, within said Webbike module, on receipt of a request for at least one first object, said extraction sub-function also makes it possible to inform the content of at least one member of at least one second object, distinct from said at least one first object, when raw data making it possible to fill in said content are present within said document with which said at least one Webbike page is synchronized.

Thus, when the object creation module according to the invention accesses, for example, a web page, it creates, at least partially, all the objects capable of being created from the information contained in this web page. The extraction sub-function therefore extracts all the raw data making it possible to inform the content of the members of objects, including objects on which the processed request does not relate.

In this way, the object creation module according to the invention optimizes access to the data sources, by browsing and analyzing only once each of the web pages, or of the XML documents contained in the data sources. For example, the object creation module accesses a given Web page to create a "film" object: it then also extracts the raw data contained in the page and makes it possible to inform at least some of the members of the objects " director "and" film festival ". According to an advantageous characteristic of the invention, there are at least the following three types of Webbike nodes: Webbike nodes of synchronization type, making it possible to search for a node of a "markup" type language or a "frame" of a node of a "markup" type language in said at least one document expressed in a "markup" type language, in order to position itself on said node of a "markup" type language or on said "frame"; structure type Webbike nodes, making it possible to define at least one execution condition for said synchronization type Webbike nodes; - Webbike command type nodes, making it possible to implement at least one predetermined operation after being positioned on said node of a "markup" type language or on said "frame".

The set of Webbike nodes constitutes a Webbike instruction tree commanding an interpreter to allow "browsing" within the analyzed data source. Such navigation is triggered by the reception, by the Webbike module, of a request to create objects.

According to the invention, there are many synchronization type nodes making it possible to synchronize on a node of a "markup" type language of the page or document analyzed by the object creation module. We can cite, for example, a Webbike node of the type allowing to synchronize on the next HTML comment, or a Webbike node of the type allowing to synchronize on the content of a node of a type language

"Markup". This synchronization condition can notably consist in carrying out a search for regular expressions within the content of said node of a "markup" type language. It should be noted that such a search for regular expressions is also used, within a web page, in the multi-terminal publishing system "Portai - To - Go", but for a completely different purpose

(direct search of patterns in a page, without respecting the tree structure of the page, and not synchronization on the HTML nodes of this page, with the aim of extracting the raw data contained in each of the nodes). Advantageously, there are also at least one of the following types of Webbike nodes: Webbike nodes of the type allowing the definition of an extraction sub-function; (Webbike tag) - Webbike nodes of the type allowing the indication of the object (s) used (s) in an extraction sub-function; (tag implements) Webbike nodes of the type allowing the definition of a Webbike page;

(page tag) Webbike nodes of the type that can be reused with possibly a list of parameters; (tag method) Webbike nodes of the type allowing the declaration of the parameters of a reusable page or node; (param-list tag) of Webbike nodes of the type allowing to call another Webbike page without synchronizing on a node of a "markup" type language; (tag link) Webbike nodes of the type allowing to call a reusable type node; (tag call) Webbike nodes of the type allowing to link to another page

Webbike; (action tag) - Webbike nodes of the type allowing the definition of a dynamic URL for an HTML page; (dynamic-url tag) of Webbike nodes of the type allowing to assign a value to a parameter; (param tag) Webbike nodes of the type allowing a sequence of at least one Webbike node to be repeated; (multiple tag) of Webbike nodes of the type allowing to include at least one command in a normally unauthorized location of a sequence of at least one Webbike node; (tag block) Webbike nodes of the type allowing to define at least two ways of synchronizing according to the content of a document; (tag switch) Webbike nodes of the type making it possible to conditionally interpret a sequence of at least one Webbike node. (if / else tag) We present, in appendix 6, examples of the syntax associated with some of the Webbike nodes described above. Advantageously, said command type Webbike nodes belong to the group comprising: Webbike nodes of the type making it possible to define a block of at least one command associated with a node (Webbike tag) of the type allowing the definition of a sub-function extraction; (tag command) - Webbike nodes of the type allowing the extraction of the textual content of a node of a "markup" type language; (tag body) of Webbike nodes of the type allowing the extraction of at least one attribute of the node from a current "markup" type language; (tag attributes) of Webbike nodes of the type allowing to designate a constant value; (constant tag) of Webbike nodes of the type allowing to assure functions of transformation of information extracted from a file expressed according to a language of type "markup". (function - substring, function - wordextract, f unction - check - url, function - java) According to an advantageous technique of the invention, said at least one command, of a block defined by a Webbike node, belongs to the group comprising: commands for creating objects; commands to modify at least one member of an object. There is thus, in particular, a command for creating a new object

SIDL, a command for updating the members of a SIDL object, and a command for adding text to a member of a SIDL object.

Advantageously, there are at least the following two types of Webbike page: static Webbike pages, analyzed at the launch of said extraction sub-function; dynamic Webbike pages, accessible from another Webbike page by a Webbike node of a particular type, known as a Webbike link. Thus, static pages have a fixed URL, specified in a node

Webbike given, called node "page", and are analyzed when launching the application. Generally, there must be at least one static page within a service. Dynamic pages are reached using a Webbike link. A dynamic page can define parameters allowing objects to be passed from page to page. A parameter can be a simple object, such as a character string, or a SIDL object.

Advantageously, there is at least one specific synchronization type Webbike node making it possible to search for a node of a predetermined "markup" type language, in order to position itself on said node of a predetermined "markup" type language, and , in addition, a generic synchronization type Webbike node making it possible to search for a node of a language of type "markup" not - predetermined but specified in parameter, in order to position itself on said node of a language of type "markup" not - predetermined.

Indeed, markup type languages, such as XML, WML or HTML are too rich to be able to provide a Webbike synchronization node for each node of an existing markup type language. In order not to unnecessarily overload the Webbike language, there is, according to the invention, a Webbike node of the generic synchronization type, which makes it possible to synchronize on any node of a "markup" type language, provided that specify the name of the element on which we want to synchronize.

Preferably, at least some of the synchronization type nodes take into account extraction conditions relating to attributes and / or textual content and / or at least one child node of a node of a markup type language. find. If several nested nodes meet the criteria established in the extraction conditions, the first node encountered is generally retained.

Preferably, said Webbike module implements a cookie management function. Thus, cookies sent by an HTTP server when retrieving an HTML page are stored at the Webbike module level. They are automatically returned by the Webbike module when it accesses pages that correspond to the domain of the cookie. Some websites depend on the management of cookies, it is important to identify the resource that causes the emission of the cookie, in order to access it from the Webbike module at the appropriate time.

In an advantageous embodiment of the invention, at least one of said first and second specific languages is constructed using a language of the XML type.

Advantageously, said "markup" type language belongs to the group comprising: XML type languages (in English "Extended Markup Language"); HTML-type languages (in English "HyperText Markup Language"); SGML type languages (in English "Standard Generalized Markup

Language ") and derivatives; - WML type languages (in English" Wireless Markup Language ").

The invention also relates to a method of implementing a system according to any one of claims 1 to 26, characterized in that it comprises the following steps: a terminal sends a request relating to a given application to said said system; to develop a response to said request, said response generation module sends a request for at least one object to said at least one object creation module, so as to inform the plurality of contexts of said application; said at least one object creation module creates said at least one object and sends it back to said response generation module; said response generation module generates a response in a generic presentation format, implementing said navigation according to said navigation policy within said plurality of contexts; said presentation module receives from said response generation module said response in a generic presentation format and transforms it into a response in a presentation format specific to the type of said terminal having formulated said request; - said system sends said response in a specific presentation format to said terminal.

Advantageously, said method is iterative, and the response to a given request depends on said navigation policy and on at least one previous request and / or response. Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given by way of simple illustrative and nonlimiting example, and of the appended drawings, among which: FIG. 1 presents a block diagram of the different types of terminals that can benefit from a multi-terminal publication system according to the invention; FIG. 2 illustrates the general architecture of a multi-terminal publication system towards the terminals presented in FIG. 1; FIG. 3 presents a block diagram of the various modules implemented in a multi-terminal publication system according to the invention; FIG. 4 describes more precisely the architecture of the multi-terminal publishing system illustrated in FIG. 3; FIG. 5 presents the different steps implemented during the processing of a request sent by a client of the multi-terminal publishing system of FIG. 3. The general principle of the invention is based on the implementation of a multi-terminal publication system, based on the processing of a generic service, regardless of its format in a data source and its final presentation in the terminal. target. There is presented, in relation to FIG. 1, a block diagram of the different types of terminals that can access a service, extracted for example from a website 1, from a multi-terminal publication system 2 according to the invention.

There are, for example, terminals of various types such as a terminal of PDA type (in English "Personal Digital Assistant") 3 or 4, a mobile telephone of WAP type (in English "Wireless Application Protocol") 5, a fixed telephony terminal 6, a Minitel 7 type terminal, or any other type of terminal, and in particular the light terminals 8, 9 and 10.

The general architecture of a multi-terminal publication system is presented in FIG. 2. The terminals 3, 4 and 5, already illustrated in FIG. 1, and a terminal 20 of the personal computer type access via a protocol of the HTTP type to the data. 21 extracted and disseminated on the global Internet network or on any other internet-type network by the web server 22.

The WAP terminal 5 does not support the HTTP type protocol, a WAP gateway 23 is implemented, so as to provide an interface between the HTTP type protocol and the WTP type protocol used on the mobile network. We now present, in relation to FIG. 3, the different modules implemented in a multi-terminal publishing system according to the invention, in the particular case where the data sources implemented are websites composed of a or several HTML page (s). Such a multi-terminal publication system is then composed of three main modules: a module 30 for creating objects; a response generation module 31 in a generic format, using the language called MDSP; - a presentation module 32. The object creation module 30 implements a sub-function for extracting data contained in the HTML pages, by performing synchronization on the HTML nodes. It creates objects using the SIDL language

(in English "Interface Definition Language service"), then transmits them to the response generation module 31.

The response generation module 31 in a generic format implements a computer language based on an XML type language. It retrieves the SIDL objects created by the module 30 for creating objects

The presentation module 32 uses style sheets, specific to each type of consultation terminal, to format the data originating from the response generation module 31, that is to say the intermediate XML tree provided by the module referenced 31, in a format readable by the terminal - destination.

A more precise description is given in relation to FIG. 4 of the architecture of the multi-terminal publishing system, the various modules of which are illustrated in FIG. 3.

Certain data, contained in a data source 40 (for example, an XML type file, a website, a database, etc.) are extracted by an object creation module 30, to inform the members of certain objects, necessary for the construction of a response to a consultation terminal 5. The module 30 implements a specific language, which allows the creation of objects of type SID1 (in English "Service Interface Definition Language").

The SIDL objects are then transmitted to the response generation module 31 in a generic presentation format, which elaborates a response in the form of an XML type tree.

Such an XML tree is then processed by a presentation module, which implements a set of style sheets 32. Each style sheet is associated with a type of consultation terminal, and makes it possible to define the presentation criteria specific to each type of terminal. We can thus envisage that the presentation module uses a style sheet characteristic of the terminals of WAP type, a style sheet characteristic of Minitel type terminals, a style sheet characteristic of PAD type terminals, etc.

The presentation module 32 can then supply, to the terminal 5 having issued a request intended for the multi-terminal publication system ^' according to the invention, a response whose content and presentation are adapted to the type of the consultation terminal 5 (here , a WAP terminal).

The modules 30 for creating objects, 31 for generating responses, and 32 for presentation therefore operate independently, on the one hand, of the nature of the data source 40, and on the other hand, of the type of consultation terminal. 5. We will now describe, in relation to FIG. 5, the different steps implemented during the processing, by the multi-terminal publication system, of a request coming from a client terminal.

During a first step, a client 50 having a terminal adapted to the multi-terminal publishing system according to the invention, issues a request 51 for access to a set of information. For example, the client 50 may request access to a given website, or to a set of information contained in a particular database. The client 50 can also request information that the multi-terminal publishing system according to the invention must, for example, partially extract from a website, partially extract from a database, and partially generate by implementing a java type module.

It can thus be envisaged that the client 50 wishes, for example, to know the list of cultural events which will take place in a given city in the coming months.

According to the embodiment illustrated in FIG. 5, the multi-terminal publication system according to the invention comprises, in addition to the modules presented in FIGS. 3 and 4, an interfacing module 59, making it possible to intercept and analyze the request 51.

After analyzing the request 51, the interfacing module 59 determines the type of terminal used by the client 50 to send the request 51, so that the multi-terminal publication system according to the invention can transmit to the client 50 a response whose content and presentation are adapted to the type of consultation terminal. The interfacing module 59 then transmits its request to the response generation module in a generic format 31, during a step referenced 52. During a referenced step 53, the response generation module 31 transmits to its turn a request to the set of object creation modules 30, so as to require the creation of the objects necessary for the construction of a response to the client 50.

The set of object creation modules 30 interrogates a set of data sources, in order to extract the information requested by the response generation module 31. For example, a java type module 302 generates certain SIDL objects, an object creation module 301, called a Webbike, extracts SIDL objects from one or more websites by synchronization with HTML tags, and an object creation module 302 creates SIDL objects from the raw data contained in one or more databases.

During a step referenced 54, the set of object creation modules 30 transmits to the response generation module in a generic format 31 the SIDL objects created in response to the request 53, as well as necessary SIDL objects when generating a response to the request 51 from the client 50, previously created by all of the modules for creating objects 30. For example, it is possible to envisage that part of the response previously transmitted to another client 50 can be reused for the preparation of a response to request 51; in this case, the set of object creation modules 30 transmits to the response generation module 31 the objects already created previously, for example by extraction from a website and / or from a database and / or of a java module.

For this purpose, upon receipt of a request 53, the set of object creation modules 30 implements a comparison of the objects necessary for the response generation module 31 with a list of previously created objects, so to implement the functions of extraction or generation of objects only for objects not previously created. The response generation module in a generic format 31 then implements navigation within the plurality of contexts relating to the service required by the client 50 during step 51. Such navigation within the contexts, in which the SIDL objects provided by the object creation modules 30 are grouped together, allows the response generation module in a generic format 31 to develop, during a step referenced 55, an XML type tree.

The presentation module 32 then processes this XML intermediate tree, so as to present the response sent to the client 50 in a format adapted to the type of consultation terminal. For this purpose, the presentation module 32 uses a set of style sheets presented in FIG. 4, and grouping together the presentation characteristics specific to each type of consultation terminal.

During a step referenced 56, the presentation module 32 sends the response, in a presentation format specific to the type of terminal having formulated the request 51, to the response generation module 31. The module 31 then returns the final response to the interfacing module 59 during a step referenced 57.

The final response, in a presentation format adapted to the type of terminal used by the client 50, is then forwarded to the consultation terminal, during a step referenced 58.

APPENDIX 1 "Treatment" type component

<handler action = "OK"> <on> <valid field = "selectEvt" />

</on> <do>

<change-context context "pageDuResume">

<param pram = "unEvenement" value = "selectEvt" /> </change-context>

</do> </handler>

Component of type "method" <method name = "uneMethode"> <param-list>

<simple name = "unParametre" /> </param-list>

<if condition = "an EQUALParameter 'return'"> <previous-context> </if> <else> <else>

<change-context context = "PageDAide"/></else></method> APPENDIX 2

"Content" instructions

"Content-item" instruction

<content-item node-name = "current-city"> <content-member member = "nom" /> </content-item>

"Content-scrolling-action" instruction Example <content-action-scroll name = "scrollEvenements">

Generated XML tree <eop-action type = "scroll" direction = "previous" name = "name" value = "5.12-1" url = "hostaddress / lll-17a = 5.12-l" uri = "hostaddress / lll-VI >

<eop-action type = "scroll" direction = "next" name = "name" value = "5.12-2" url = "hostaddressll-lll = 5.12-2" uri = "hostaddressl 1-1-1-1" l > APPENDIX 3

"Variable manipulation" instructions

"List" instruction

<list name = "uneListe" class = "C_Ville" />

"Create" instruction

<create variable = "listeEvt" constructor = "StringEtCat"> <param param = "a_string" value = '"Paris'" /> <param param = "a_cat" value = "CatégorieCourante" />

</ Create>

APPENDIX 4

"Navigation" instructions

"Change-context" instruction

<change-context context = "Event" entrypoint = "fromPlaces">

<param param = "unLieu" value = "lieuSelectionne" /> </change-contexf>

"Change-service" instruction

<change-service service = "ErrorService" entrypoint = "BadName"> <param param = "a_msg" value = "'the name' CAT inputNAME CAT 'is unknown'" />

</ Exchange Service>

APPENDIX 5

"Use" type instruction

"Otherwise" instruction

<if condition = "TERMINAL. Software.language EQUAL 'html'"> <change-context context = "aideHTML" />

</if> <else>

<change-context context = "AideVDXML" />

</ Else>

"Parameter-list" instruction

<Ρaram-list>

<simple name = "unPremierParam" />

<object name = "unSecondParam" class = "C_Ville"/></param-list>

APPENDIX 6 Webbike nodes of the type allowing the definition of an extraction sub-function:

<WebBike service = "nouba" javascript = "on"> <! - - implementation list - -> <! - - page list - -> <! - - method list - -> </WebBike>

Webbike nodes of the type making it possible to conditionally interpret a sequence of at least one Webbike node:

<if condition = "expression"> [<command>]

<! - - WebBike instructions - -> </if> <else>

[<Command>]

<! - - WebBike instructions - -> </else>

Webbike nodes of the type allowing the definition of a dynamic URL for an HTML page:

<dynamic-url base = "http: // ..." [method = "post"]>

<! - - list of objects passed as parameters to the page (list of <param>). Here the param tag associates a page parameter name with a

Parameter name of the request (parameter of an SIDL Object constructor) - -><! - - list of parameters to pass to the CGI (list of <url-param>). - -></dynamic-url> Webbike nodes of the type allowing the definition of a Webbike page

<page name = "root"

[Url = "http: //www.nouba.voilà.fr"]

[= Parse mode "service"]>

[<Param-list>]

[<Command>]

<! - -list of <dynamic-url> - ->

<! - - WebBike instructions - -> </page>

Claims

1. Multi-terminal publication system (2), of the type providing access to at least one application corresponding to a service, making it possible to provide a plurality of terminals (3-10), according to at least two distinct types of terminal, information contained in at least one information source (40), characterized in that it comprises: at least one module for creating objects (30, 301-303), making it possible to provide at least one function for creating 'objects from raw data extracted from said at least one information source and / or generated by said at least one module for creating objects; a response generation module (31) in a generic presentation format, in response to a request (51) formulated by a terminal and relating to a given application, said application being defined, within said response generation module, by a plurality of contexts and a navigation policy among said contexts, each context comprising at least one action and or at least one object, created by said at least one object creation module, said response resulting from navigation according to said policy navigation within said plurality of contexts; - a presentation module (32), making it possible to transform said response in a generic presentation format into a response in a presentation format specific to the type of said terminal having formulated said request.

2. System according to claim 1, characterized in that said response in a generic presentation format is an XML type or SGML type tree.

3. System according to any one of claims 1 and 2, characterized in that it further comprises an interfacing module (59) making it possible to intercept and analyze said request (51) formulated by a terminal, to so as to: identify the type of said terminal; creating a new request (52), in a generic request format, intended for said response generation module.

4. System according to any one of claims 1 to 3, characterized in that each object comprises at least one member relating to the structure of said object and at least one constructor, said at least one constructor allowing said at least one module (30 ) creation of objects to inform the content of said at least one member.

5. System according to any one of claims 1 to 4, characterized in that said at least one module (30) for creating objects belongs to the group comprising: a module (301) for creating objects, called Webbike module , making it possible to provide at least one function for creating objects from raw data extracted from at least one data source containing at least one document expressed in a "markup" type language; an object creation module (303), making it possible to provide at least one function for creating objects from raw data extracted from at least one database of the SQL type; a module (302) for creating objects, constructed from a java-type language, making it possible to provide at least one function for creating objects from raw data generated by said module for creating objects and / or extracted from at least one predetermined source of information.

6. System according to any one of claims 1 to 5, characterized in that said presentation module (32) is constructed using a language of the type

XSL.

7. System according to any one of claims 1 to 6, characterized in that within said response generation module (31), said at least one application is composed, according to a first specific language, of a service container , describing said service, and at least one context container, each corresponding to a step in said navigation.

8. System according to claim 7, characterized in that a container is composed of at least one component, making it possible to group together at least one instruction.

9. System according to claim 8, characterized in that it implements six types of components: components of the "entry point" type, making it possible to describe a first plurality of operations that said response generation module must at the start of the execution of a service container or a context container; components of the “attributes” type, making it possible to describe a plurality of variables usable in said current container; components of the "method" type, making it possible to group a plurality of said at least one instruction within a procedure; components of the "imports" type, making it possible to describe said at least one object necessary for said response generation module, to generate said response to said request relating to a given application; components of the “processing” type, making it possible to describe a second plurality of operations that said response generation module must perform in response to an action performed by a terminal; components of the “content” type, making it possible to describe said information supplied to a terminal within said response and / or to describe said at least one action that said terminal can perform at a stage of said given navigation.

10. System according to any one of claims 8 and 9, characterized in that it implements the following four types of instructions: "content" type instructions, making it possible to generate part of said response in a format generic presentation; - "variable manipulation" type instructions, making it possible to declare and / or manipulate at least one variable; "navigation" type instructions, making it possible to change the current context and / or the current application; "use" type instructions, which can be used by instructions and / or components.

11. System according to claim 10, characterized in that said “content” type instructions belong to the group comprising: a “content-literal” instruction, making it possible to describe a character string of said response in a generic format; - a "content-object" instruction, making it possible to describe an object; a "content-list" instruction, making it possible to describe a list of objects; a "content-item" instruction, allowing to describe an element of a list; a "content-member" instruction, making it possible to describe a member of an object; a "content-selection" instruction, making it possible to select an item from a list; a "content-selection-multiple" instruction, making it possible to select at least one item from a list; - a "content-entry" instruction, allowing to describe an item of type

"input" by which said terminal having formulated said request can enter a value; a "content-scrolling-action" instruction, making it possible to move within a list; - a "content-action" instruction, making it possible to describe an action; a "content-action-change-of-context" instruction, making it possible to describe an action which allows said terminal having formulated said request to change context; a "content-action-context-previous" instruction, allowing said terminal having formulated said request to return to the previous context.

12. System according to any one of claims 10 and 11, characterized in that said instructions of type "manipulation of variables" belong to the group comprising: an instruction "object", making it possible to declare a variable of type "object"; a "list" instruction, allowing to declare a "list" type variable; a "simple" instruction, making it possible to declare a variable of type "simple", distinct from said type "object" and from said type "list"; a "create" instruction, making it possible to construct an object or a list of objects; an "establishment" instruction, making it possible to assign a value to a variable; a "list-move" instruction, making it possible to move a current pointer from a list, by specifying a movement step; - a "list-move-to" instruction, making it possible to move a current pointer from a list by specifying a new position of said pointer.

13. System according to any one of claims 10 to 12, characterized in that said “navigation” type instructions belong to the group comprising: - a “change-context” instruction, making it possible to instantiate a new context; a "change-service" instruction, allowing to instantiate a new service; a "context-previous" instruction, making it possible to return to the previous context in the current service; a "service-previous" instruction, making it possible to return to the previous context with the last context of said service.

14. System according to any one of claims 10 to 13, characterized in that said "use" type instructions belong to the group comprising: a "call" instruction, making it possible to call a "method" component in the context or the current service; an "if" instruction, making it possible to establish a condition on a set of instructions; an "otherwise" instruction, following an "if" instruction and making it possible to establish a condition on a set of instructions; an "if-if" instruction, following on from an "if" instruction and making it possible to establish at least one other condition on said set of instructions; - an "execute-content" instruction, making it possible to generate a presentation of said information described in a "content"component; an instruction "if dl -import", allowing to specify an object to use in the current service; a "parameter-list" instruction, used to group parameter declarations; a "parameter" instruction, used to specify the value of a parameter; a "do" instruction, allowing to group in a component of the type

"processing" of the actions to be performed when launching the execution of a context; an "on" instruction, allowing the grouping of conditions that must be validated for a component of the "processing" type to be executed.

15. System according to any one of claims 1 to 14, characterized in that on receipt by said at least one module (30) of creating objects of a request for at least one object, said request coming of said response generation module (31), said at least one object creation function implements at least one extraction sub-function, making it possible to inform the content of at least one member relating to the structure of said at minus an object.

16. The system as claimed in claim 15, characterized in that said at least one object creation function further comprises a sub-function for comparing said at least one object to which said request relates with a list of objects beforehand at least partially created, so as to implement said at least one extraction sub-function only for the creation of objects not previously created and / or to complete objects previously partially created.

17. System according to any one of claims 15 and 16, characterized in that within said Webbike module (301), each extraction sub-function is composed, according to a second specific language, of at least one page Webbike comprising at least one Webbike node, and in that said at least one Webbike page is synchronized with at least one document expressed in a markup type language from at least one data source, said at least one document comprising it -even at least one node of a "markup" type language, said synchronization allowing a Webbike node to position itself on a node of a "markup" type language in order to extract raw data therefrom with a view to said creation of objects.

18. System according to claims 4 and 17, characterized in that within said Webbike module, on receipt of a request for at least a first object, said extraction sub-function also makes it possible to fill in the content at least one member of at least one second object, distinct from said at least one first object, when raw data making it possible to fill in said content are present within said document with which said at least one Webbike page is synchronized.

19. System according to any one of claims 17 and 18, characterized in that there are at least the following three types of Webbike nodes: - Webbike nodes of synchronization type, making it possible to search for a node of a type language "markup" or a "frame" of a node of a "markup" type language in said at least one document expressed in a "markup" type language, in order to position itself on said node of a type of language "markup" or on said "frame"; - structure type Webbike nodes, making it possible to define at least one execution condition for said synchronization type Webbike nodes; Webbike command type nodes, making it possible to implement at least one predetermined operation after being positioned on said node of a "markup" type language or on said "frame".

20. The system of claim 19, characterized in that there is also at least one of the following types of Webbike nodes: Webbike nodes of the type allowing the definition of an extraction sub-function; - Webbike nodes of the type allowing the indication of the object (s) used (s) in an extraction sub-function; Webbike nodes of the type allowing the definition of a Webbike page; Webbike nodes of the type which can be reused with possibly a list of parameters; - Webbike nodes of the type allowing the declaration of the parameters of a page or of a reusable node; Webbike nodes of the type making it possible to call another Webbike page without synchronizing on a node of a "markup" type language; Webbike nodes of the type allowing to call a reusable type node; Webbike nodes of the type allowing to link to another page

Webbike; Webbike nodes of the type allowing the definition of a dynamic URL for an HTML page; - Webbike nodes of the type allowing a value to be assigned to a parameter; Webbike nodes of the type making it possible to repeat a sequence of at least one Webbike node; Webbike nodes of the type allowing to include at least one command in a normally unauthorized location of a sequence of at least one Webbike node; Webbike nodes of the type making it possible to define at least two ways of synchronizing according to the content of a document; Webbike nodes of the type making it possible to conditionally interpret a sequence of at least one Webbike node.

21. The system as claimed in claim 19, characterized in that said command type Webbike nodes belong to the group comprising: Webbike nodes of the type making it possible to define a block of at least one command associated with a node of the type allowing the definition of 'an extraction sub-function; Webbike nodes of the type allowing the extraction of the textual content of a node of a "markup" type language; Webbike nodes of the type allowing the extraction of at least one attribute of the node from a current "markup" type language; - Webbike nodes of the type allowing to designate a constant value; Webbike nodes of the type making it possible to provide functions for transforming the information extracted from a file of a "markup" type language.

22. System according to claim 21, characterized in that said at least one command, of a block defined by a Webbike node, belongs to the group comprising: commands for creating objects; commands to modify at least one member of an object.

23. System according to any one of claims 17 to 22, characterized in that there are at least the following two types of Webbike page: static Webbike pages, analyzed at the launching of said extraction sub-function; dynamic Webbike pages, accessible from another page

Webbike by a Webbike node of a particular type, called Webbike link.

24. System according to any one of claims 19 to 23, characterized in that there is at least one specific synchronization type Webbike node making it possible to search for a node of a predetermined "markup" type language, in order to position itself. on said node of a predetermined "markup" type language, and, in addition, a Webbike node of generic synchronization type making it possible to search for a node of a non-predetermined "markup" type language specified as a parameter, in order to position itself on said node of a non-predetermined "markup" type language.

25. System according to any one of claims 19 to 24, characterized in that at least some of the synchronization type nodes take account of extraction conditions relating to attributes and / or textual content and / or at least a child node of a node of a "markup" type language found.

26. System according to any one of claims 5 to 25, characterized in that said Webbike module implements a cookie management function.

27. System according to claims 7 and 17, characterized in that at least one of said first and second specific languages is constructed using a language of the XML type.

28. System according to any one of claims 17 to 27, characterized in that said language of type "markup" belongs to the group comprising: languages of type XML (in English "Extended Markup Language"); - HTML type languages (in English "HyperText Markup Language"); SGML (Standard Generalized Markup Language) and derived languages; WML-type languages (in English "Wireless Markup Language").

29. A method of implementing a system according to any one of claims 1 to 28, characterized in that it comprises the following steps: a terminal (3-10) transmits a request (51) relating to an application data intended for said system (2); to develop a response to said request, said response generation module (31) sends a request for at least one object to said at least one object creation module (30), so as to inform the plurality of contexts of said application; said at least one object creation module creates said at least one object and sends it back to said response generation module; said response generation module generates a response in a generic presentation format, implementing said navigation according to said navigation policy within said plurality of contexts; said presentation module (32) receives from said response generation module said response in a generic presentation format and transforms it into a response in a presentation format specific to the type of said terminal having formulated said request; said system sends said response in a specific presentation format to said terminal.

30. Method according to claim 29, characterized in that said method is iterative, and in that the response to a given request depends on said navigation policy and on at least one previous request and / or response.