WO2004072759A2 - Method of enhancing the contents of a digital page having a format which enables the creation of links to computer objects - Google Patents

Abstract

The invention relates to a method of enhancing the contents of a digital page having a format which enables the creation of links to computer objects, the representation of said page being displayed using a display support. The invention is characterised in that it comprises the following steps consisting in: defining at least one tree structure, the leaves of which correspond to target codes; defining at least one element; creating at least one original marker including a link to the aforementioned element; enhancing the original marker by generating a new marker which is substituted for the original marker, said original marker being modified using (i) the contents of the original marker, (ii) one or more references to the above-mentioned tree structure(s) and (iii) a means for deploying the representation of said tree structure; adding a link to the enhanced marker to the digital page; and displaying the representation of the enhanced marker, thereby giving rise to an enhanced representation of the element.

Description

 METHOD FOR ENRICHING THE CONTENT OF A PAGE

DIGITAL IN WHICH FORMAT ALLOWS CREATION

LINKS TO COMPUTER OBJECTS

The present invention relates to the field of methods for enriching the content of digital pages.

The present invention relates more particularly to the enrichment of the content of digital pages whose format allows the creation of links to computer objects. For example, they can be web pages or pages that can be viewed on a portable device such as a PDA.

Advertising is now present on many websites. Numerous methods make it possible to target the content of the banner ads according to the user. Several solutions of the prior art are already known.

The prior art already knows from PCT patent application WO 99/57660 (iWeb Ltd.) a system and a method intended to provide content, including rich information content to a particular audience of computer users. , preferably in accordance with the characteristics of these users, such that the content is exposed in a controlled manner and is transferred by a third party into a "two-party" system, such as the World Wide Web. For example, rather than transferring content, such as an advertisement, as part of a web page to a website remote from the computer user, the invention transfers the advertisement through ISP ( Internet service provider) of the user, for example, on the user's computer screen. Advertising or other content is as well optionally displayed to the user, regardless of whether the web page is displayed on the user's computer screen, in a manner substantially transparent to the user. In this way, the content is targeted specifically to the user, rather than being displayed generally on the web page or the like transferred through "two-party" channels such as web servers.

The prior art also knows from American patent application US 5948061 (Double Click) methods and devices for targeting the distribution of advertising over a network such as the Internet. Statistics are compiled on individual users and networks and the use of advertisements is observed to allow targeting of individual users by advertisements. In response to queries from affiliated sites, an advertising server sends people accessing the site page appropriate advertising based on user and network profiling.

The prior art also knows, by PCT patent application WO 01/29727 (Adfluence), network methods for interactive advertising and direct marketing. In an interactive advertising method for the Internet, a banner is displayed in the advertising space of a web page. The banner allows the user to carry out a purchase transaction or view a list of goods and services with descriptions, without leaving the web page. The user transaction takes place through the banner, and so the user does not need to leave the web page to make a purchase. The advertising space and the program according to the invention provide a personalized appearance which resembles the brand of the advertiser. Data extraction is provided by means of the interaction of the user with the advertising space, and information databases can be set up for the purpose of knowing user profiles, carrying out marketing actions and implementing statistical analyzes.

The prior art also knows, from US patent application US 20020111865 (Enliven), a method for monitoring the micro-interactions of the user in advertising on a web page. In connection with the display of advertising in web pages, an applet is downloaded to the user's web browser to track user interactions with the web page. The interactions of the users tracked include the position of the mouse cursor, the time spent on the page, the time spent by the cursor on the advertisement, and so on. At an appropriate time, such as when the display of the web page is complete, the applet transmits information on client interactions to a remote server, the remote server typically being controlled by an advertiser, or the like. As a result, the advertiser can track the consumer's response to ad impressions on the web page without asking the user to download other pages. This allows advertisers to track the user's response to specific elements of the web page and to obtain better information about the user's interests in order to qualify the user before presenting the advertisement.

Also known, from PCT patent application WO 01/44969 (Ad4Ever), is a method and a system for presenting an animated advertisement on a Web page. This PCT patent application relates to a method of presenting an animated advertisement on a Web page. According to this method, a web server obtains a web page layer, designed to contain an animated advertisement having at least one object. running across a web page downloaded to a client computer connected to the web server, without at any time hiding or disabling portions of the web page outside of an object boundary. The web server then downloads the layer of the web page to the client computer for display of the animated advertising content associated with said web page. Preferably, the animated advertisement is displayed as a short animated clip relating to a product or service, in order to capture the attention of an observer, and displaying a link with an advertisement kept in association with a web server of advertisements, itself associated with the product or service. Thus, the observer can obtain other information relating to the product or service, by clicking on the link. Animated advertising thus constitutes a mystery advertisement intended to encourage the user to request an advertisement, the link serving as a reminder of the advertisement after the end of the mystery advertisement.

Also known, from PCT patent application WO 99/60504 (Unicast Communications), is a technique used to set up network distributed advertising in a client-server environment. According to this technique, advertisements are downloaded from an ad server to a browser running on a client computer, and subsequently displayed by that browser interstitially, in response to a click produced by the user. An HTML advertising label is incorporated into a referring web page. This label contains two elements. An item effectively downloads, from a dispatch web server, and continuously instantiates an agent in the client browser, that agent downloads advertising files from an advertising management system located on a third-party advertising web server, to an advertisement given in the browser's cache memory, and reproduced these media files later through the browser interstitially. The other element is a reference of the advertising management system, which completely "dissociates" the advertising content of a web page, so that a web page contains only an advertising label referring, via a URL, to a specific advertising management system. The specific advertising management system selects the given advertisement to download.

The present invention intends to remedy the drawbacks of the prior art by allowing interactivity to appear on an element of a digital page without modifying the structure of the normal display circuit. The method of the present invention has many advantages over the methods already known: for example, it does not require a particular plugin installed on the client platform, and it does not require that a banner be developed by means of 'a tool other than those used to develop web pages in DHTML. In addition, the technology of the present invention is able to "encapsulate" third-party technologies. The method according to the invention does not impose any proprietary modification of the original banner and makes it possible to completely separate the graphic aspect of the banner from its application logic. This technology also makes it possible to deliver the banner independently of its interactive logic. A major advantage of the method of the present invention is that once an interactivity structure is created, it makes it possible to deploy it in multiple forms such as an advertising banner, a geographic map or a text. In addition, this process gives the possibility of reflecting changes in interactivity in real time on the banner, and allows easy grouping of several advertisers on the same banner. It also makes it possible to easily compose complex menus from elementary menus, only involves the agency on an agency server and ideally only on a banner server. Finally, the method of the present invention makes the banners accessible by search engines, allows companies to provide their own services that the advertiser can decide to include in its tree structure and allows designers to offer the possibility to provide models (also called "templates") that advertisers can decide to use for the presentation of their interactivity.

To this end, the present invention relates, according to its most general meaning, to a method for enriching the content of a digital page whose format allows the creation of links to computer objects, and whose representation is displayed through a display medium, characterized in that it comprises:

• a step of defining at least one tree structure whose sheets correspond to target codes;

• a step of defining at least one element;

• a step of creating at least one original marker, including a link to said element;

• a step of enriching the original marker consisting in the generation of a new marker substituted for said original marker, said original marker being modified from: the content of the original marker, from a (of) reference (s) to said ( to said) tree structure (s) and means for deploying the representation of said tree structure;

• a step of adding, on the digital page, a link to the enriched marker; • a step of displaying the representation of said enriched marker leading to an “enriched representation” of said element;

• a step of deploying the representation of said tree structure in the display medium, after action by a user on the "enriched representation" of said element.

Preferably, said step of defining a tree structure comprises a sub-step of storing a tree structure or of a mechanism making it possible to dynamically create a tree structure as a function of context parameters.

According to a first variant, the storage takes place on a dedicated server. According to another variant, the storage takes place locally.

Advantageously, the storage takes place with the original marker.

Advantageously, the storage is carried out in the form of files, these files being files of SGML format or of a format derived from SGML, files of XML format or of a format derived from XML, files of DHTML format, files binary format, pre-compiled format files or text format files. According to a variant, the storage is carried out in a digital database, this digital database being relational or object. Preferably, said step of defining a tree structure consists in the creation of this tree structure.

Advantageously, said step of defining a tree structure consists in modifying an already existing tree structure.

According to a particular embodiment, said step of defining a tree structure consists in the composition of a tree structure from at least two already existing tree structures, these tree structures not necessarily being distinct one others.

According to a first variant, said modification consists in removing a node from said already existing tree structure.

According to a second variant, said modification consists in the creation of a new node of said already existing tree structure.

According to another variant, said modification consists in modifying a node of said already existing tree structure.

According to another variant, said modification consists in the displacement of a node of said already existing tree structure. Preferably, said composition consists in attaching a fragment or all of one of the already existing tree structures to another already existing tree structure.

According to a variant, the user is a human being.

According to another variant, the user is an automaton.

According to a first mode of implementation, the deployment means is software in nature. According to a second mode of implementation, the deployment means is of a material nature.

Advantageously, the display medium is a program installed locally. According to a variant, the display medium is a web browser.

According to another variant, the display medium is a plug-in associated with a web browser.

According to a particular mode of implementation, the display support is implemented on an embedded system.

According to another particular mode of implementation, the display medium is implemented on a personal computer.

According to a variant, the display support is implemented on an interactive terminal.

According to another variant, the display support is implemented on an interactive television apparatus.

According to another variant, the display support is implemented on a portable device.

Preferably, the action of a user on the representation of the enriched marker consists of a mouse event or a keyboard event.

Advantageously, the action of a user on the representation of the enriched marker consists of an audible signal.

Advantageously, the action of a user on the representation of the enriched marker consists of a tactile event. According to a variant, the action of a user on the representation of the enriched marker consists of an automation triggered by the context.

Advantageously, the context is the physical geographic location of the user. According to a particular mode of implementation, the context is a keyword.

According to another particular mode of implementation, the context is the date. According to a variant, the context is the geographic location as designated by the user.

According to another variant, the context is a predefined constraint in advance. Preferably, said digital page is a card support.

Advantageously, said digital page is a medium for multimedia or text content.

Advantageously, said digital page is a computer object support.

Preferably, said digital page is a static or dynamic page written in DHTML, XML, HTML, C- HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. According to a variant, said digital page is a static or dynamic page containing code written in DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript.

According to another variant, said digital page is a static or dynamic page using code written in DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript.

According to a particular implementation mode, said digital page is a static or dynamic digital page, implementing Flash animation.

Preferably, said original marker consists of code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. Advantageously, said original marker contains a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. Advantageously, said original marker uses a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript.

According to a particular mode of implementation, said original marker is a compiled or precompiled program, of ASCII code or of text.

Preferably, said original marker is a file, this file is a multimedia file, a text file, a file of SGML format or of a format derived from SGML, a file of XML format or of a format derived from XML, a DHTML format file or data file. Advantageously, said enriched marker consists of code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG , Java, JavaScript, or VBScript.

Advantageously, said enriched marker contains a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. According to a variant, said enriched marker uses a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. According to a particular mode of implementation, said enriched marker is a compiled or pre-compiled program, ASCII code or text.

Preferably, said enriched marker is a file, this file is a multimedia file, a text file, a file in SGML format or a format derived from the SGML, an XML format file or a format derived from XML, a DHTML format file or a data file.

According to a particular mode of implementation, said tree structure is reduced to a single sheet.

Preferably, said target codes are references to target files consisting of code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript.

Advantageously, said target codes are references to target files containing a code written in

DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript.

Advantageously, said target codes are references to target files using a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP , CFM, JSP, SVG, Java, JavaScript, or VBScript.

According to a variant, said target codes are references to multimedia files, these multimedia files being sound, animation or video files.

Preferably, said multimedia files are broadcast in the form of streaming.

Preferably, said representation of said enriched marker is a set of nested menus and submenus.

Advantageously, said representation of said enriched marker is a set of separate drop-down lists.

According to a variant, said representation of said enriched marker is a set of sensitive areas of a multimedia file. Preferably, the leaves of said tree structure correspond to links dynamically created as a function of conditions resolved at the time of the user's request. Advantageously, the leaves of said tree structure correspond to static links. Preferably, said tree structure is created via a creation interface.

According to a variant, said creation interface is accessible online.

According to another variant, said creation interface is part of software installed on the workstation of the user of said interface.

According to a particular embodiment, said step of defining a tree structure consists in calling a tree structure previously recorded on a recording medium.

Advantageously, said recording medium is a removable medium. Preferably, the original marker refers to an advertising banner.

According to a variant, the enriched marker dynamically calls up the tree structures relating to the words dynamically loaded on the digital page. According to another variant, the enriched marker dynamically calls upon the tree structures relating to the intersection of a geographic context and a thematic context loaded dynamically on the digital page. According to a particular mode of implementation, the step of dynamic display of the representation of said enriched marker includes dynamic modifications of the digital page. The present invention also relates to a multi-server computer architecture characterized in that it comprises in particular:

• a client station calling a digital page, the content of which is enriched according to the aforementioned process;

• an element server storing elements;

• a server containing rules for calling said references to said elements;

• a dedicated server containing the tree structures;

• a web server containing said digital page.

Preferably, the architecture further comprises a server containing references to said elements and rules for calling towards said elements

Advantageously, the architecture also comprises a second web server containing target files.

According to a variant, the elements are pages of text.

According to another variant, the elements are geometric figures or words, in that the web server containing said digital page is a space server.

The invention will be better understood using the description, given below for purely explanatory purposes, of an embodiment of the invention, with reference to the appended figures:

• Figure 1 shows a tree structure;

• Figure 2 illustrates conditional tree structures; • Figure 3 illustrates the different basic definitions;

• Figure 4 shows the production of an item by an item server;

5 • Figure 5 compares the representation of the element in several cases of declination of the invention;

• Figure 6 shows the different phases of the method according to the invention;

10 • Figures 7 and 8 represent a modeling of the e-advertising market: the technical structure and the players;

FIG. 9 represents the referrals, through the browser, during the

15 display phase;

• Figure 10 shows an example of service creation interface;

• figure 11 represents an example of interface of creation of structures

20 trees;

• Figure 12 represents the traceability of the variables during the different phases;

FIG. 13 illustrates an example of an input interface allowing an agency to associate a stylized tree with an advertising banner of its advertising client;

FIG. 14 illustrates the principle of the Rich-Banner production phase;

• Figure 15 shows the Rich-Banner production phases;

FIG. 16 presents a possible process of a phase of production of the Rich-

35 Banner according to the invention: • Figure 17 illustrates an example of Rich-Banner with a menu deployed and a minipage displayed;

• Figure 18 illustrates the case of a 5 traditional technique of e-advertising;

• Figure 19 shows a possible process of a production phase of the Rich-Banner according to the invention (case

10 of the iframe tag);

FIG. 20 illustrates an example of an interface relating to the development phase of Rich-Word;

FIG. 21 illustrates a possible method 15 of a Rich-Word production phase;

• Figures 22 and 23 illustrate the theoretical principle of Rich-Word;

• Figure 24 illustrates the notion of association in the case of Rich-Word;

FIG. 25 illustrates the principle of the sensitive zones of an image;

• Figure 26 illustrates the Rich-Image principle;

FIG. 27 represents an example 25 of an interface of a development phase in the case of Rich-Image;

• Figure 28 shows a possible process of a production phase in the case of Rich-Image;

FIG. 29 represents an example of an interface of a development phase in the case of Rich-Geobject;

• Figure 30 shows a possible process of a production phase in

35 the case of Rich-Geobject; • Figures 31 and 32 illustrate the principle of the permanent element in the case of the Rich-Miniportail;

• Figure 33 illustrates the participation of active trees in the search engine search process.

A tree structure (or tree) is a structured code representing, by successive overlaps, a tree structure capable of presenting structured information, conducive to structured navigation such as menus and submenus (M _ijk ). The endings (or leaves) of the tree represent "target codes" which can be represented, in XML technology, in the form of text nodes (TC _ijk ) (TC: target code). Such a text node can, for example, correspond to the absolute HTTP address of a web page. These addresses will then allow access to the corresponding web pages during a so-called use phase (see below). These web pages are called "minipages". Each of the nodes of the tree structure can be accompanied by particular attributes, suitable for giving them specific functionalities, such as the possibility of obtaining a Web minipage by clicking on the level of a menu which is not a sheet.

FIG. 2 represents a conventional menu structure whose menus and sheets have a name, and whose sheets have a name and a target page. More complex tree structures can be envisaged, as we will see below, in particular:

• style attributes (color ...),

• target pages on menus that are not sheets, • conditional attributes making it possible to incorporate, within the tree itself, for example into the “condition” attribute of the “menu” element, the conditions for displaying said menu as a function, for example, of the characteristics of the platform - client form, determined using the request header, etc. Conditions can be placed anywhere in the tree, for example in the form of an attribute whose value is a script. One can also consider contextual conditions of deployment at the instant, for example, of the click of the mouse on a command corresponding to a leaf of the tree.

A tree is said to be stylized when a certain number of stylistic attributes have been added to it (whether or not through an external style sheet). A non-stylized tree contains only structured data, while a stylized tree is ready to be presented graphically, since it contains both presentation styles (color, font ...) and interactivity styles (animation of opening menus ...).

A tree is said to be active when it is inserted into a production chain which can lead to its display on the client platform of an Internet user. An active tree has necessarily been stylized beforehand. A tree (even if it is stylized) cannot be displayed on a client platform if it has not been activated beforehand.

A tree server is understood to mean a server storing and restoring tree structures on demand. An element is a computer file that can represent a multimedia object (image file, video file, etc.) or a mechanism allowing to dynamically create such a computer object. An item is stored on an item server. The original marker is a code including a reference to an element. The enriched marker is the marker obtained from the enrichment of an original marker, which leads to an “enriched representation” of the element of the original marker, a representation on which a user (internet user or application) performs an action in order to deploy the representation of the tree structure associated with it, during a phase called "development phase". We will speak of consultation support by generalization of the Web page, subject of the consultation of the Internet user. In the particular case of a target code referring to a target file which is a Web page, the latter is called "minipage". They are often displayed in a small window (pop-up) during the action performed by the user on the command of a deployed menu.

A tree server serves a set of menus which is graphically grafted onto the representation of an element (banner, geometric figure, etc.), this element being mediated (in the sense of a means (media) of transport) by a medium (respectively the web page, the map, ...). Once the grafting has been carried out, we can consider that the element is "enriched" with a menu structure which allows it to reach through the "minipages" to which each of the commands pointed to is accessed through these menus. . It is, in fact, an "enriched representation" of the element, and by abuse of language, an "enriched element". These commands refer, for example, to URLs each indicating the address of a web page (static or dynamic), and which are called "minipages". This menu structure can be considered as a "navigation structure" in the sense that this structure makes it possible to "navigate" through these "minipages". The preceding definitions can be based on the production of an element by an element server as described in FIG. 4.

An element server (SE) produces an element (E) on a client platform when, following a request (Ri) on the part of said client platform on an element reference server (SR) ( phase 1), said element reference server responds to it by sending a code (Cl) (phase 2) which encapsulates a code cl, interpretable by a virtual machine (MV) installed on said client platform, code making reference to the address url (E) of said element E on an element server (SE) and having as a purpose the graphic display of said element on said client platform. The interpretation of the Cl code (Cl≈document.write (cl) (for example in Javascript) leads to unencapsulate cl which is then interpreted by the virtual machine (MV). The virtual machine MV detects a tag (phase 3) that it interprets by searching for the value of an attribute indicating the url (E) address of the element E on the Web (phase 4) which allows it to request it (phase 5). The element server SE then produces element E by uploading its code to the client platform (phase 6) The browser then processes this code for display on the client platform (phase 7).

The present invention can, among others, have the following variations:

• Rich-Banner: advertising banner enriched with a deployable menu structure. • Rich-Geobject: geometrical element (composed of geometrical primitives) superimposed on a geographic map, and of which the internet user, by moving the mouse over it, deploys a corresponding menu structure. • Rich-Word: word from which the user, by passing the mouse over, deploys a suitable menu structure.

• Rich-Image: geometric element superimposed on an image (gif jpeg, png ...), or sensitive area, from which the Internet user, by passing the mouse over, deploys a tree structure of corresponding menus. The tree in question can also be conceived in the form of a path whose sensitive areas of an image are the guides to the next images.

• Rich-Miniportail: menu structure adapted to the specific needs of an individual and deployable from an element on a Web page. Ideally, this element is permanent, that is to say that it is found from web page to web page, as the user navigates, in the same position relative to the window containing the Web page, and in the same state (menus deployed or not).

The term “rich”, which appears commonly, indicates that each of these elements is “enriched” with a tree structure deployable by an action of a user (internet user or application) on the

"Enriched representation" of the element.

The process of the present invention has many properties which are of great interest to those skilled in the art. For example, a tree structure can be reused by an advertiser for its deployments in multiple forms, in particular: banner advertising (Rich-Banner), geographic map (Rich-Geobject), text (Rich-Word) ... In other words, it it is a "write once, inform anywhere". The graphical deployment of the tree structure, by action of a user on the “enriched representation” of an element, allows it to consult information and use services, while remaining on the support of the element. He thus remains in control of his navigation. The repercussion of the modifications made by the advertiser on its tree structure is effective in real time. Tree structures belonging to different advertisers can be associated together with the same element, thus allowing a user, when graphically deploying this tree structure, to consult information or to use services corresponding to different advertisers. In addition, it is possible for an advertiser to assemble bricks of tree structures in order to compose a more complex structure.

The various versions of the present invention must take into account the constraints of the chain of actors involved in the target market. In the particular market of e-advertising, non-intrusion consists, ideally, of not intervening either on the advertising network of advertising, nor on the advertising servers of agency. Ideally, we only intervene on the content server delivering the element, the object of advertising creation. Ideally still, there is no intrusion into the process of creating the advertising object. It is then a question of adding an element completely complementary to the advertising object created by the agency. Thus, it is possible to obtain detailed reports in real time, allowing agencies and their advertising customers to determine the parameters of success of this or that advertising creation, in order to have a usable knowledge base for the next media plans, and readjust parameters during the campaign.

The method according to the invention makes it possible to encapsulate a large number of existing technologies (java applet, flash pay, gif ...) as well as to integrate within these technologies. Agencies should invest as few resources as possible in learning new methods specific to the new technology. Ideally, we should be able to split a file obtained by these tools into a tree component (structure and data) and a purely stylistic component (style and interactivity). Finally, the trees created and activated (that is to say ready to be distributed on demand) are accessible by search engines, even if they are not explicitly part of the content of a web page. A failure in the display of the tree should not be detrimental to that of the element, whether in terms of time or display itself.

Offer companies the possibility of providing their own services that the advertiser can decide to include in its tree structure. Offer designers the possibility of providing models that advertisers can decide to use, exclusively or not, for the presentation of their tree structure.

The process of the present invention comprises three different phases:

• a pre-development phase; • a development phase;

• a production phase.

The pre-development phase is the phase corresponding, completely independently, to: • The creation of trees or a dynamic tree creation mechanism: we include in this phase the creations of trees (data and structure), style sheets of trees, and means of deployment and interactivity of trees .

• Creation of elements or a mechanism for dynamic creation of elements. ^“ The creation of markers.

• The creation of minipages or a mechanism for the dynamic creation of minipages.

• The creation of services.

The development phase is the phase during which a marker is enriched by associating a stylized tree with means of deployment, phase accompanied by the substitution of the original marker by the enriched marker. This phase can also consist in the storage of the association between an element and a tree and its means of deployment: this is the case, for example, of the process that Rich-Word uses.

The production phase is the phase initiated by the request of an Internet user or an application. The production phase itself comprises three phases:

• The display phase. This is the phase initiated by a user or an application, the term of which corresponds to the display of the "enriched representation" of the element.

• The deployment phase. This is the phase initiated by a user action on the "representation enriched ”with the element and whose term corresponds to the graphic deployment of the tree structure. It can notably be a deployment of menus and submenus coded in a language understandable by the client platform, which is for example the case of JavaScript in a Web page. • The use phase. This is the phase corresponding to user actions on one or more menu (s), submenu (s) or command (s) of the tree structure graphically deployed. Once a sheet has been selected, it leads to the execution of the associated target code, which can lead, for example, with an appropriate JavaScript client code, to the display of a Web minipage in a window opened for this purpose.

In Figure 6, we observe the following elements

MD: Means of deployment MP: Media plan

Link (MP): Link to the Media Plan M: Original marker RM: Rich marker (Rich Marker) E: RE element: Rich Link element (E): Link to the AND element: Tree (tree structure) Link (Menu): Link to a modifiable code through 3 interfaces (tree, style and MD) The pre-development phase is indicated by the four arrows in the "pre-development phase" column. The tree creation phase can consist of creating mechanisms allowing the trees to be obtained dynamically, in the production phase, according to context parameters. The creation of a tree (or a tree creation mechanism) can be done from an existing tree that is modified, or by composition of two trees, the resulting tree being obtained by grafting from the root of one on a leaf of the other. The tree creation phase can, independently, consist of using three separate interfaces dedicated to the creation of the data and the structure of the tree, to the creation of the stylistic attributes of the tree and to the creation of its means of deployment and interactivity. The use of these interfaces leads, for example, to the creation of a JavaScript file (extension js) for the means of deployment and interactivity, to the creation of a style sheet (extension css) for the stylistic attributes of the tree as well as an xml file for the tree itself (structure and data). It is also conceivable that at the end of the pre-development phase, the data, structure and style of the tree are incorporated into the same JavaScript file.

The development phase is indicated in Figure 6 by the three dotted arrows, leading to the creation of an enriched marker (RM), stored on the marker server in substitution for the original marker

(M).

The production phase (case of the RichBanner) can be described like this (with reference to Figure 6): Al: Consultation of a Web page by an Internet user A2: The Web server containing the page delivers the Web page which is the subject of the consultation: it is the "consultation page".

A3: The advertising tag, previously supplied by the sales manager and inserted by the Webmaster in the source code of the web page consulted, uses the advertising server of the sales manager or "marker server". Taking into account context parameters, the advertising management server chooses one of the enriched markers (RM) from those it has in stock. This enriched marker includes a link named Link (MP) to a media plan and a link named Link (Menu) to a tree. A4: The enriched marker contains a reference to a media plan (MP). The JavaScript write method of the document object allows you to write the link to the media plan (MP) in the DOM of the consultation page. A5: The link is therefore made to an agency advertising server which is an “item reference server”. It is a mechanism allowing the agency advertising server, depending on the context parameters, to choose an element reference (Link (E)). A6: The JavaScript method write of the document object allows to write the link to the element (E) in the DOM of the consultation page.

A7: The link is therefore made to the content server, called “element server”, using the link reference (E), in order to extract the element E. A8: Display of the element E on the client platform of the internet user.

A9: The enriched marker contains a reference (Link (Menu)) to a set consisting of a tree structure (T), a style sheet and a deployment means (MD), including the deployment rules and interactivity of this menu. This set is stored on a server, called "tree server". A mechanism can also be stored there allowing the tree server, depending on the context parameters, to dynamically constitute the tree in question. The JavaScript write method of the document object allows you to write the Link (Menu) link in the DOM of the consultation page. A10: The link is therefore made to the tree server, using the Link reference (Menu) which refers, for example, to an external JavaScript file (<Script src = "http: // .. js ">), file made up of a series of commands encapsulated in write methods of the document object in order to write in the DOM of the consultation page. Garlic: Display of the tree (data, structure and style) accompanied by its means of deployment and interactivity (MD) and download of all of this code on the client platform. It can be displayed or wait for a user action to deploy visibly on the client platform.

In the following table, the definitions are presented in the case of the four versions of the present invention:

Table 1: definitions in the case of four versions of the invention.

Figures 7 and 8 represent a modeling of the e-advertising market: the technical structure and the players.

Referring to FIGS. 7 and 8, it will be noted that the graphic agency GD_m ₀ designs the visual of the advertising GC for the advertiser AD ^^ then delivers this visual to the central purchasing agency G_i _! . The central purchasing agency AG_i _x consults the media plan and determines which websites PS_i _{2d 2} have been selected. These websites determine the PB__i ₂ boards which are responsible for manage advertising space on PS_i websites ₂ d ₂ . The central purchasing agency AG_i _! then hands over to the PB_i ₂ sales offices thus selected, a tag, known as an "agency tag" and including a reference to this visual. This discount is made either by sending an email to the trafficker of the sales center, or by entering it, by the trafficker of the central purchasing agency AG_i ₂ from a server interface. advertising AS_i ₂ of the management PB_i ₂ . When a user consults a page of the PS_i ₂ j _{2 website} , in which the Webmaster of that site has placed a tag, known as an "advertising tag", the latter calls up his sales representative PB_i ₂ . The ad server AS_i ₂ of ₂ PB_i governed governed performs a process in which it decides the "tag agency" that will dynamically write to the browser of the user (or to which it will lead in the framework of 'a redirection from server to server). If the previous "agency tag" is thus chosen, the request is redirected to the content server containing the advertising image, a content server which may or may not be confused with the advertising server AS_i _! from the central purchasing agency AG_i _! .

RichBanner can "encapsulate" third-party richMedia technology, in the sense that the menus are deployed around richMedia graphic creation.

Traditional third-party technological solutions are integrated into the production of a richMedia advertisement by being a banner server (we will more generally say a content server), the specificity of their technology requiring that they entirely host the graphic creation on their own server. In this case, the agency advertising servers should not combine the function of content server, but leave the hand to a separate content server. There is therefore a redirection of the request from the agency server to a server of external content. With RichBanner, there is no question of hosting the entire graphic design, but simply an additive to it, in the form of a tree. This therefore requires that an additional referral be made to the tree server.

RichBanner is complementary to the richMedia proprietary technology banners, from the moment we have access to the agency tag in order to enrich it, which is necessarily the case, because it must be provided to the management server for the banner to be put in traffick (sent by email or by the field of an online form).

References, through the browser, during the display phase are illustrated in Figure 9.

Websites can register as a Service Provider (SP).

Once they have provided a basic URL and a secure system has made it technically possible to confirm that this URL belonged to them, a password is provided to the Webmaster of this site.

This password allows him to access an interface through which he references the site and its services in the database of service providers.

The purpose of such a service is to allow an advertiser to integrate them into its own tree structures. If a service requires the advertiser to enter parameters when creating its tree structure, the supplier must indicate this in the "URL parameters" section, when it creates the service.

If the service is geolocated, that is to say if the service is configured by a latitude / longitude pair (obtained by the position of the cursor on a map provider or by GPS), the supplier specifies it by checking the box "Geolocated service".

The “Latitude” and “Longitude” fields then indicate the name of the parameters as they should appear in the URL of the geolocated service.

A dynamic URL can be represented in the following form: Filename.ext? a ₁ = v ₁ , ..., a _n = v _n ext is the file extension and can be used in particular: asp, jsp, php, cfm or x l.

Ai are the names of parameters and v _has the values of each of these parameters. Let us consider a minipage of which two parameters a and a _i2 respectively represent the latitudes and longitudes. The service provider must then fill in the two fields "Latitude" and "Longitude" in the interface for creating services, giving them the values "a _u " and "a _i2 " respectively. In the following, we will consider that the service provider has entered the values “lat” and “long” in the “Latitude” and “Longitude” fields respectively. This convention will allow us to trace the variable throughout the production process.

The interface for creating services is illustrated in FIG. 10. The interface presented in FIG. 11 allows an advertiser to create a tree structure by associating with each leaf of the tree a target code or else directly the URL of a Web page. .

The advertiser has the choice of entering the URL directly in a text field provided for this purpose (to, for example, allow the Internet user to display a minipage from his own site: we provide for this purpose the possibility of '' drag and drop from the browser's address bar directly into the input field of the URL), or choose, using a drop-down list, a among those offered by service providers.

In the latter case, several possibilities:

1- The advertiser has nothing else to enter than the name of the service available in the drop-down list. This is the case when:

1. the URL points to a static page 2. the URL points to a dynamic page whose parameters cannot be modified by

1 advertiser

2. The advertiser must provide details of his choice. This is the case when: 2 The service is “semi-dynamic” the URL points to a dynamic page whose values of certain parameters of the URL must be entered by 1 advertiser. Entering this service in the drop-down list then opens a window presenting a form, in which the advertiser provides the parameter values. The validation of this form involves the concatenation of a character string leading to create the URL which will be stored in the tree structure database.

3. The service is "totally dynamic" the URL is dynamic and the value of certain parameters will only be entered when the tree structure is graphically deployed: this is the case, for example, of the corresponding parameters at geographic coordinates whose value is determined by the position of the cursor at the time of the deployment of the tree structure.

The k ^th tree structure T_i _x j _x k of the advertiser AD_i ₁ j _x is saved in a database in a tree server. This will allow it to be deployed on multiple elements: advertising banner, word of an article or geometric element on a geographic map. This will also make it possible to associate, within the same element, tree structures belonging to different advertisers, even if they are managed by different agencies.

Figure 12 (traceability of variables) illustrates the production of a fully dynamic service in the context of the deployment of a tree structure on a cartographic support. To perform the traceability of variables throughout the different phases, note the reuse of the two variables "lat" and "long" as defined in the chapter "registration of services".

If a geolocated service has been incorporated, the names of the geographic parameters entered by the service provider, when the service is created, appear in the xml file as the value of the attribute as the value of 1 ' "name" attribute of "param" tags nested in the "url" tag.

In a development phase, the agency extracts from the multi-language tree, a single-language tree, before associating it with an element. Here, the structure of the English language has been extracted. Are also determined the background colors and menu titles.

In a deployment phase of the production phase, the user performs a right click on a map, or the geographic coordinates of the place are provided by a GPS.

Client-side javascript, associated with the map returned by the space server, defines the value of the two latit variables and lengthens in correspondence with the position of the cursor on the map. The menus are displayed with their title and color.

In a phase of use of the production phase, if the internet user chooses the order corresponding to the geolocated service, the client-side javascript code dynamically concatenates the character string forming the url, by adding to the base url defined in the text node of the url tag, the two parameters "lat" and "long" to which it gives the values of the global javascript variables "latit" and "longit" respectively. The url thus formed, the corresponding web page is displayed as a minipage in a pop-up.

An input interface, shown in FIG. 13, allows the agency AG_i _x to enter or modify the] ^th tree structure T_i ₁ j _x k of its advertiser client AD_i _x j _x . The purpose of this interface is to stylize the original tree. The original tree is limited to presenting data in a structured manner.

The development phase leads to the instantiation of a tree that we “stylize”.

By stylization of the tree is meant the addition of stylistic attributes which can be attributes of color as well as interactivity.

Technically, this is ideally done by transforming the original tree using one or more several style sheet (s), created by a graphic agency, and stored on the tree server, possibly in the context of XML technology (XSL, XSLT style sheets), and / or DHTML standard (CSS style sheets). These style sheets could have been created, for example, using standard graphics tools such as Flash or Director.

By "interactivity" is meant only the style of this interactivity (for example in the form of an animation), with the exception of the result of the action itself, which is defined in the leaves of the tree structure.

The choice of the original tree is described in steps A1 to A6.

Al: The agency enters a password

A2: This password gives him access to a set of advertisers whose management agency (the "Advertiser" drop-down list is filled with the names of these advertisers).

A3: The choice of one of the advertisers gives access to all the tree structures of this advertiser (the drop-down list "Tree" is filled with the names of these trees). A4: The agency chooses an advertiser from the list of advertisers, which has the effect of requesting the tree database in search of tree structures belonging to the selected advertiser. A5: Said tree structures appear among the options available from the drop-down list called "Tree".

A6: The agency chooses a tree from the “Tree” drop-down list, which has the effect of filling the list called “language” with all the possible languages. This is done without making access to the tree server. Indeed, the selected tree has been loaded into the DOM of the client page. Once loaded, the tree was parsed in search of the languages it manages, which made it possible to extract the titles of these languages.

It is only once the choice of a tree has been made, and that the latter is therefore loaded in the DOM of the client page, that the "Color" and "Interactivity" buttons are accessible.

The choice of interactivity for the stylized tree is described in steps B1 to B2.

Bl: A click on the "interactivity" button leads to the opening of a window whose main page is based on a query on the [GD] (Graphical Designer) and [GC] (Graphical Creation) databases.

B2: This page contains a form allowing to define the type of interactivity which one wishes to associate with the deployment and the use of the tree. The query allows to propose a drop-down list, intended to propose pre-established choices of interactivity, by drawing its values from a database comprising graphic creations [GC], These graphic creations are, ideally, style sheets which have been created by designers using, for example, standard graphic creation tools (Flash, Director ...), or more directly (coding). Once you have chosen an interactive animation, a "Preview" portion of the window allows you to test the interactive animation within the framework of the selected tree structure.

The choice is made by clicking on the "OK" button, which leads to a dynamic modification of the XML fragment corresponding, in the DOM of the client page, to the tree structure being stylized.

The choice of colors (and more generally of the style) of the stylized tree (Cl) is done by clicking on the "color" button, leading to the opening of a window containing a form allowing the colors of the texts and backgrounds of the elements to be established. following of the tree structure: tabs, main menus and submenus. By convention, a tab and a menu of the highest level (level 0 or root), a main menu is a menu of level 1 and the sub-menus are the menus of level strictly higher than 1.

It is envisaged in the present invention to implement a method of assistance in the choice of the colors of the tree as well as in the choice of other stylistic attributes. Help in choosing the colors of the menu items defined above (and the style in general) will be carried out by considering that these colors must use part of the colors appearing in the advertising banner. How, however, to determine precisely their hexadecimal value, given that the web page is not given access to the image file constituting said banner? The banner ad points, using the "href" attribute of the "img" tag, to a web page from which it logically adopts the graphic style and in particular the colors. This style is defined, either in said web page, target of the banner ad, or in a style sheet (CSS for example) to which said web page explicitly refers in its source code. The solution therefore consists in importing the HTML document (in XHTML form for example) whose URL is defined as the value of the "href" attribute of the "img" tag, to parse said document in search of occurrences of tags whose name is "style", to finally extract the values of the sub-attributes of these tags corresponding to the definition of styles that interests us (for example: background and text colors). If explicit reference is made, in the source code of the page that we are importing, to external style sheets (for example CSS style sheets), we import said style sheet, whose URL is explicitly defined in value of the attribute "src" of the tag "style", and we proceed in a manner equivalent to the above, except that the parsing will be carried out taking into account, as regards a CSS style sheet , the difference between the structure of a CSS document and the structure of an XML file. In the particular case of color, once the hexadecimal values have been retrieved, their resulting color is displayed in drop-down lists, thus making it possible to choose, from a restricted and consistent set of colors, while testing the rendering obtained in the context of the tree structure. So that there is no ambiguity as to the URL towards which the banner ad points, a text field will be provided for this purpose in the development interface, unless a process is able to extract it from the text field in which the original marker is written. This process can be extended to the case of the extraction of a minisite from the target site of the advertising banner. This extraction can be semi-automated and consist of support aimed at the joint production of minipages and the tree structure.

It is also possible to carry out an extension of the process in the case of a close integration between the tree structure and the file defining the banner. This is the case, for example, in which the stylized tree is an integral part of the file defining the advertising banner. In other words, the deployment of the menus will take place within the banner, which may be in proprietary technology. The present invention also applies to this case, since it is possible to separate the tree structure from the rest of the file defining said strip.

The registration of the stylized tree structure in the database is implemented in step E1:

El: Clicking on the "OK" button saves the stylized tree structure in the tree structure database. In terms, for example, of XML technology, this can consist in memorizing the XML file representing the original tree structure, together with the associated XSLT stylesheets making it possible to restore, on demand, the monolingual tree, in color and comprising the interactivity. But we can also very well operate this transformation during the development phase, so that we will then memorize, for example, a javascript file (js) comprising all the information allowing to graphically deploy the stylized tree .

The enrichment step of the original marker corresponds to E2:

E2: The original marker, generally generated automatically by the agency's advertising server, is pasted into the field of the interface provided for this purpose. In the diagram above, this is a simple banner associated with a click-through type link. The choice of an option of the “Type of Tag” interface will allow the system to guide the agency in the creation of the enriched marker from the original marker: this is called a semi-automated system or help to enrichment of the marker. The enriched marker consists of adding a script (or a reference to an external script) to the original marker, as well as adding a fragment representing a tree structure (or a reference to such a fragment ), or representing a mechanism allowing to dynamically and contextually restore a tree structure (or a reference to such a mechanism). The new marker thus created (the enriched marker) now includes code (JavaScript for example) which will allow, on the one hand, to insert the stylized tree extracted from the tree structure database (the recording of the stylized tree having been made during the previous step (El), and on the other hand, to ensure the interactivity necessary for the graphic deployment and the use of this tree structure in adequacy with the advertising banner. Once the enriched marker has been retrieved, it is placed on the advertising server of the advertising networks in place of the original markers.

In order to give a more complete description of the invention, it is necessary to address the problem of determining the language used in the menus deployed by the banner. Consider the case of an Internet user viewing a website from a computer in a Web café abroad and assume that said Internet user does not understand the language of that country. There is a good chance that the browser on this computer has been configured so that its default language is that of the country in which it is located. If therefore the language of the tree structure is determined dynamically in the tree server, at the time of the request from the browser, thanks to the header of the latter, this means that the language of the tree structure is determined based on browser settings, which are likely to match the country where the computer is located. In our example, the user will see a tree structure in the language of the country whose language he does not speak. If the problem does not arise with advertising banners whose message is clear, this regardless of the language, the question becomes unavoidable as regards the possibility, for this banner, of deploying more provided information, which poses the problem of language determination. Another way to determine the language is to do it during the development phase and not during the production phase (display phase). Logically, the language of the banner menu must correspond to that of the page that the Internet user consults and in which the said banner is inserted. Indeed, if the Internet user consults this page, it is because he understands the language. We will assume, in what follows, that the choice of language corresponding to the banner is made when associating the tree with said banner, that is to say during the development phase.

For there to be a linguistic adequacy between the language of the Internet user and the menus of the enhanced banner, the following constraints must be respected:

• If the original banner has a particular linguistic attribute (text or a link to a web page in a given language), we will rest on the fact that the enriched banner will naturally be trafficked on sites in linguistic adequacy with the non-enriched banner. In other words, the fact of enriching the banner will not influence the media plan of the central purchasing office.

• If the original banner does not have any particular linguistic attribute (no text or link to a Web page inviting a prior choice of language), the central purchasing office must ensure that the marker, enriched with a call to a tree of given language, is well trafficked on Web pages in linguistic adequacy with the said menu. Indeed, any enriched banner is linguistically specific. This will require the central purchasing office to readjust its media plan.

By placing itself in the chain of actors participating in the production phase, the tree server ensures the ability to count the number of displays of the RichBanner. So that the tree server can also participate in the counting during the use phase, several possibilities can be envisaged:

1-Post-click trackers can be placed in the minipages so that a server is informed each time such a minipage is displayed. 2- When the click on a menu is not followed by the display of a minipage, as it can for example be the case of the dynamic display of a form in JavaScript, an insertion request, present at within the target code, will record the activation of this menu command. Each action on the different menus can be recorded on a server, reporting is able to rely on the breakdown of information represented by the tree structure. It is therefore possible to have very precise information concerning the use of the interactivity of the Rich-Banner: as precise as the breakdown made by the advertiser to give access to its set of functionalities. The idea is based on the fact that we have the same information as that delivered by post-click trackers of the web pages of the advertiser site, except that this information is obtained from the choices of menu commands made by 1 'user. The Rich-Banner production principle is shown in Figure 14.

In addition, Figure 15 shows the Rich-Banner production phases. The web server provides the advertising support web page, the advertising network server provides the file containing a link to the media plan, the agency advertising server provides a link to the banner ad, the content server provides the element (for example: banner), the tree server provides the tree structure and the mini-page server provides the mini-pages that are called from the deployed menu of the RB.

FIG. 16 shows a possible method of a production phase of the RichBanner according to the invention. This is the case of the Agency Tag of type document.write ('<A href= "..."><IMG src = "..."></A>'). Steps Al to Ail, which appear in FIG. 16, repeat steps Al to Ail which have been explained above. Here is what the DOM (Document Object Model) of the consultation page can look like for the RichBanner to work:

<! DOCTYPE HTML PUBLIC "- // W3C // DTD HTML 4.0

Tr ansitional / / EN ">

<HTML> <BODY>

<! - RICHBANNER LAYER ->

/ * Layer including both the banner ad, the RichBanner technology logo as well as the menu layer (s) associated with the banner ad and the minipages * /

<DIV id = "div_richbanner" STYLE≈ "position: absolute;" onMouseOver≈ "javascript: document. GetElementByld ('div_ Tab') .style.visibility = 'visible';" document.getElementByld ('div_ongle' ). style.visibility≈ 'hidden'; ">

<! - LAYER TAB ->

<DIV id = "div_ Tab" STYLE = "position: absolute; left: 0; top: 0; visibility: hidden;" onMouseOver≈ "javascript: document. GetElementByld ('div_menu')

. style. visibility≈ 'isible'; ">

<SCRIPT LANGUAGE≈ "JavaScript" SRC = "tabs. Js"> </SCRIPT>

</ DIV>

<! - HEADBAND ->

/ * Banner

"ext" is a file extension corresponding to a page

Static (htm, html) or dynamic (asp, php, cfm, jsp, xml) web. * /

<A href="http:// ... / lien_annonceur.ext" target=_blank> <IMG src = "http: // ... / image__bandeau.gif"> </A>

<! - RB Logo LAYER -> / * Layer including the logo placed on the advertising banner and indicating that it is a RichBanner * /

<DIV ID = "div_logo" STYLE≈ "position: absolute; left: [strip width] -wlogo; top: [strip height] - hlogo;"> <A href = "http://www.intercreative.net "> <IMG src =" logo_richbanner.gif "border = 0> </A> </DIV>

<! - MENU LAYER ->

/ * Layer including the code allowing to deploy the tree structure * /

/ * The menu is initially hidden * /

<DIV id = "div_menu" STYLE≈ "position: absolute; left: 0; top: [height of banner]; visibility: hidden;" onmouseout≈ "javascript: document. getElementByld ('div_menu'). style.visibility≈ 'hidden';" onmouseover≈ "javascript: document. getElementByld ('div nenu') .style.visibility≈ 'visible';">

/ * Reference to the JavaScript function including the menu structure, its style and the code allowing its deployment and interactivity * / <script language≈ "JavaScript" type = "text / JavaScript" src = "menu. js" x / script>

</ DIV>

<! - MINIPAGE LAYER ->

/ * The minipages are initially hidden * /

<DIV id = "div_minipage" STYLE = "position: absolute; left: 0

; top: [headband_height + menu_height]; visibility: h i d d e n; "onmouseout≈" javascript: document. getElementByld ('div_minipag e'). style .visibility≈ 'hidden'; document.getElementByld ('div_ menu') .style.visibility≈ 'hidden'; "onmouseover≈" javascrip: document. getElementByld ('div_menu')

.style.visibility≈ 'visible'; "> <IFRAME id =" iframe_minipage "height =" 300 "width =" 470 "scrolling =" yes "src≈" minipage. ext "x / IFRAME> </DIV>

</ DIV>

<HTML> <B0DY>

Figure 17 illustrates the above code. The file "menu. js ", which is referred to using an absolute path in the SRC attribute of the SCRIPT tag, contains instructions of type" document.write ", allowing to write, in the DOM of the page of consultation, HTML tags (as well as their attributes and text node) allowing to visualize the menu structure. He can in particular write DIV tags there in order to position menu items at any position, relative to the advertising banner with which this menu structure is associated. He also wrote there the references to the functions defined in the remote file "menu." js ". Since the “document .write” instructions are used during the loading phase of the Web page, these lead to writing dynamically in the Web page without the latter being reloaded.

Figure 18 illustrates the case of the traditional technique of e-advertising with b: a banner B: Web page containing the banner

S: Support web page A: Advertiser web page IF: iframe

H: height of b and IF W: width of b and IF

This is the case for the Agency Tag of type document.write ('<IFRAME src≈ "...">') (or ILAYER). The traditional banner appears through an IFRAME. This case differs from the case where the marker was of the form <A href="...">> <IMG src = "..."> </A>, in that in this case it doesn’t is not explicitly mentioned the banner.

In the case of an agency tag of the IFRAME type, the agency has complete control over the enrichment of the marker without it being necessary for it to modify the Agency tag which is located on the management server.

In the case of the IMG type agency tag, the marker was the Agency tag, while in this case, the marker is the value of the SRC attribute of the IFRAME dynamically written in the DOM of the consultation page. The development phase:

In the context of the present invention, the original marker is page B.

The following presents an example of a process intended to enrich page B.

During the development phase, page B is transformed into a page B _bis , which is the enriched marker.

The development phase leads to enriching the original marker B (page B.ext) with a client code (for example written in JavaScript) obtained from a tree chosen from those offered by the development interface, as well as 'stylistic and interactivity attributes also informed through the development interface.

The client code is called "stylized tree code": it is the means of deployment.

A server-side process (for example in Java) builds, from the tree, a code interpretable by the surfer's platform (for example JavaScript). This code must allow the internet user, once the display process is complete, to graphically deploy the stylized tree on his platform (deployment phase) and to click on the menus thus deployed (usage phase), for example, to access web pages (minipages) displayed in pop-ups. This code is made during the development phase when a tree (or tree creation mechanism) and stylistic and interactivity attributes are associated with a web page.

Once this code has been produced, it is incorporated into page B, which has been enriched to become the page B _bis , page which has also been allocated a certain number of functionalities allowing it, in the production phase, to carry out specific processes. This is how, for example, the BODY tag is assigned a specific reaction to the onLoad event, this by means of a "create_rb ()" function, the mechanism of which we will explain in the chapter on the phase. of production.

At the same time, to have access to this function, page B _bis must include a reference to the “rb.js” file containing it.

Also during this development phase, the page B _bls thus obtained was placed at the URL of page B, so as to be called by page S in place of the initial page B.

We note in Figure 19:

S: Web page for consultation rb: Rich-Banner b: banner

Menu Code: Javascript code (allows the tree to be deployed on the client platform) MP: Mini-Page B: agency page containing b before its transformation into Bbis

Bbis:: Web page obtained from B in the development phase

T: Tree structure A: Advertiser's web page

Al to A9: display phase Ul & U2:: use phase IF1: iframe tag of the control room and placed on the consultation web page H: height of b and IF1 W: width of b and IFl urlBbis: url of page B

More specifically, the support page S is the page that the Internet user consults.

The advertising tag corresponds to the tag that the agency requests the Webmaster to place in the source code of the page S. The agency tag is in the form of document .write ('<IFRAME ...>') and is written dynamically in the DOM of the consultation page S. This is the iframe that we will denote IF _X

The value of the "src" attribute (for source) of the iframe IF _X : this is the URL of page B.

The internet user consults the support page S (Al and A2).

The advertising tag requests the ad manager to manage it, for example by providing it with the URL of the calling page (A3), which allows the ad server process to determine the Agency tag to select and return (A4). We consider here that the tag Document.write ('<IFRAME ...>') is chosen: the iframe IF _X is then loaded in the consultation page S.

This results in the loading of page B _bis (A5) in addition to the original page B, since page B was replaced by page B _bis during the development phase.

At the end of the loading of the page B _bis , the “onLoad” event of its “BODY” tag is notified. The value of the onLoad attribute is the JavaScript function "create_ rb ()" which is accessible since defined in the “rb.js” file referenced in the SCRIPT tag on page B _bis .

This function uses the “parent.parent.document” instruction to allow it, from the _bis page, to exit the DIV tag, then access the DOM (document object model) of the S support page.

Thus, the expression "parent .parent.document. getElementByTagName ('iframe') ”allows, for example, to reach an iframe tag from the DOM of page S.

(We can note that this is not necessary if we decide to intervene directly on the agency tag, considered then as the original marker, in which case we lose however the advantage of only intervening on the element server in the development phase, which is interesting insofar as it makes the process even less intrusive).

It is however necessary to determine the correct IFRAME tag, in case there are several on the consultation page.

When the iframe IF _X loads its source, it first requests the agency adserver (this is the request explicitly written in value of the SRC attribute of the iframe IF _X ).

This request returns the URL URL (B _bis ) on the element server.

When the code "stylized tree code" accesses the DOM of page S, it accesses the last values loaded (which is not necessarily identical to the source code of page S).

In particular, "stylized tree code", referring to the SRC attribute value of _the iframe IF accesses URL _(Ba) and not to the initial request to the ad server agent. We can therefore identify, among several iframe, the iframe whose SRC attribute has URL value (B _bis ), which we do by browsing the list obtained from the parent.document instruction. getElementByTagName ('iframe') and by stopping the search when an element of this list has URL (B _bis ) for value of the attribute SRC. (It is, for example, a loop in JavaScript allowing to extract, one by one, the “elt” elements from the list and to perform the following test: elt.src≈ URL (B, - _is )). It is at the level of the development interface that the URL URL (B _bis ) must be specified, which one must know if one then wants to save it in the right place.

The S page whose DOM, just before the loading of the _bis page, was as follows:

<HTML>

<BODY ...>

<IFRAME SRC≈ "url (B _bis )">

• • •

</ IFRAME> </ BODY> </ HTML>

becomes page S 'whose DOM, following the execution of the function create_rb () and its consequent action on the DOM of page S, is now the following:

S '

<HTML> <BODY. . . >

<DIV STYLE≈ "position: absolute;">

<IFRAME SRC = "url (B _bis )" visible ();" ();">

• •

</ IFRAME>

<DIV STYLE = "position: absolute; left: 0; top: H;">

"Stylized tree code"

</ DIV>

</ DIV>

</ B0DY>

</ HTML>

It is first of all the nesting of the IFRAME (IF _X ) in a DIV tag.

Then a second DIV tag is nested in the first, following the closing tag of the IFRAME tag.

This second DIV tag is intended to accommodate the graphics of the stylized tree (for example in the form of drop-down menus) associated with the banner b.

Thus the assignment of values to the "left" and "top" attributes of the STYLE attribute of this tag is sufficient to position the content of the second DIV tag relative to the upper left corner of the first tag

DIV. Here is the height of the IFRAME. In other words, it is thus possible to position the drop-down menus precisely with respect to the banner b.

We placed "stylized tree code" (which was manufactured during the development phase) between two IVDs.

This code represents the stylized tree, that is to say the tree from the point of view of data, graphics as well as interactivity. If, in the case of the IMG tag, it was necessary to frame the code of the stylized tree between two DIVs to position it, this is no longer the case here, if we assume that the banner is always at the top left of the B _big web page. Once displayed, the Rich-Banner can be used by the Internet user: he interacts with it by deploying the menus and clicking on the commands that appear.

He then has access to mini-pages and can thus consult the advertiser's mini-website while remaining on the support page S.

We could also have conceived that the remote javascript file “http: // ... /rb.js” is obtained from the development interface and contains the stylized tree (instead of being the page B _bis which contains it).

If the file name "rb.js" does not change from one tree to another, the path to it is specific to the tree in question and is stored on the tree server. The development interface takes care of the automation consisting of creating a new path each time a tree is created, and modifying the page B _bis so that it refers to the correct "rb.js" file. Consider the case of the Agency Tag of type document.write ('<EMBED src≈ "...">') (or OBJECT):

In the same spirit as the above, we can apply one or more method (s) allowing a tag of type EMBED or OBJECT to enrich itself with a tree structure located on an external tree server or not.

This can allow in particular to enrich an external tree as well a Flash file as a Java applet.

The enrichment of the original marker can be done by calling a tree after the source of the EMBED (or the OBJECT) is called.

The enrichment can also relate to a concatenation of the character string constituting the value of the source attribute "SRC". It can then be, for example, to add a character string consisting of a list of items of the type parameter≈ "value", items separated by the character "&", this in order to specify on the dynamic page called, the parameters that we want to transmit to it.

We can also consider the possibility of associating a single tree structure with a set of separate banners appearing on the same web page.

Thus, this unique tree structure will be stylized in order to allow the internet user to navigate, thanks to a single “dashboard” present on its page, through the functionalities offered by all of the advertising banners present on the page that he consults.

The Rich-Word development phase, illustrated in Figure 20, consists of three separate interfaces: • The Régie interface

RI: The user of the governed interface (usually the authority that manages advertising space on behalf of websites through his trafficker) begins by entering a password identifying him, then registers a website for which it manages advertising space by indicating its URL (here the site whose URL is: PS_i ₂ j ₂ ).

R2: When the trafficker clicks on the button

OK, the URL PS_i ₂ j ₂ is stored in the website database (PS).

A3: The click on the OK button has also led to assigning and presenting a password dedicated to the site registered by the trafficker of the sales center.

R4: The trafficker becomes aware of said password R5: The trafficker communicates, for example by email, said password to the Webmaster of the site

PS_i ₂ d ₂ .

• The Agency interface

Al: The user of the agency interface (in general the agency which manages the purchases of advertising space on behalf of an advertiser through his trafficker) begins by entering a password identifying him. A2: She then chooses a website from the "Website URL" drop-down list which presents her with all the URLs of the websites in the PS database, made up of websites. who have independently informed the dedicated development interface. Here she chooses the URL PS_i ₂ j ₂ .

A3: The agency indicates, in the "Word (s)" provided for this purpose, the word (s) on which it wishes to communicate on the site it has selected. Here, she selects the word "Web", indicating that she wishes to communicate on the word "Web" on the web page PS_i ₂ j ₂ .

A4: The agency selects one of the advertisers it manages. Here she selects the advertiser AD ^ - using the "Advertiser" drop-down list. A5: The choice of the advertiser causes the display, in the "Tree" drop-down list, of all the tree structures of the advertiser AD ^^. The agency selects one of the trees presented in this drop-down list. Here she chooses the tree noted T_i ₁ j ₁ k.

this Webmaster

Wl: The Webmaster enters the password communicated to him by the management in the "Password" field provided for this purpose.

W2: this has the effect of indicating, from the PS database, the URL PS_i ₂ d ₂ of the Webmaster's site. W3: In the "directory" field, the Webmaster indicates, in the form of a relative URL, the portion of the site whose pages are the advertising spaces that the agency is responsible for managing for Rich-Word. W4, W5: When the Webmaster clicks on the OK button, each of the Web pages included in the aforementioned directory are embellished with a JavaScript code allowing, when the page is consulted, to search for the tree structures corresponding to the words purchased on this page.

W6: the new page is saved to the old url.

The decrease in intrusion corresponds to a non-intervention by the Webmaster.

We can make the development phase even less intrusive by allowing the Webmaster not to intervene. To do this, it suffices to enrich the original markers of the banner ads with a call to the server script "searchWord. Jsp" which requests the RW database. This process can also be extended to advertising banners which are not Rich-Banners. Thus, it is not necessary to modify the web pages that the advertising agency wishes to make available to agencies for the reservation of words, insofar as the tag already appears there through the banner ads whose markers have been enriched with the call to the Rich-Word server.

The Rich-Word production phase is illustrated in Figure 21.

This Rich-Word production phase includes the following stages:

1: The internet user consults a web page of the PS_i site ₂ d ₂ .

2: The code, inserted into this page during the development phase, allows you to request a dynamic web page remote "searchWord.ext", giving it the URL of the current page.

3: Said dynamic page imports the list of words reserved for this page, during the development phase.

4: The text of the current Web page is searched for reserved words, which determines a new list, called "short list"

5: Is imported from the tree server, all the tree structures coinciding with the words of the shortlist.

6: Modification of the DOM of the current web page by integration of said tree structures.

In the case of Rich-Word, the element is a word.

The idea behind Rich-Word is to allow an agency to reserve a set of words on a given web page for a certain period of time. Web pages are today most often dynamic, so that one cannot predict the content of the Web page before the text fields, which dynamically call upon the fields of a table of a database, are filled with the text they extract from this database. Figure 22 summarizes the principle of dynamic call of text from a database. The web page consists of a number of TN Text nodes _± . Some of these text nodes use a database using an <M _A > marker. Various SSI technologies (side include server) can be used for this purpose: asp, php, cfm, jsp ... The <M _A > marker therefore performs a request (Request) on a database, request whose result (Response ) is displayed in place of said marker. Thus, if the element is the word, we must take into account the fact that this element is initially stored in the field of a table of a database. Only after the final content text nodes have been integrated, in this way, to the content of the web page, that we are able to compare all of the content of the text nodes with all of the words that have been reserved by the agencies for this page for communication purposes. Figure 23 shows the principle.

At the end of the page loading, and therefore once all the TN _± text nodes have been resolved, a request is sent to the RW database in order to obtain all the words reserved by the agencies for this Web page: this list is noted WordList. A client process then generates a shortlist E which is the intersection of WordList and all the words contained in the text nodes T _± . E therefore consists of a set of words e _if a word e _d having both been reserved by an agency for this Web page and having been imported from a database in a field of a table on occasion loading the dynamic page: E = {e _j }. This set E is sent as a parameter of a process aimed at extracting, from the tree server database, the set T = {t _j } from the tree structures t _j associated with β _j .

The definition of the tree structure is done independently of whether one is in the case of Rich-Word or Rich-Banner or other. In the case of RichWord, the element is a word. The definition of the element consists in the creation of the text containing the word-element, text recorded in the field of a table of a database. In the case of RichWord, the original marker, consisting of the Web page containing all the tags <M _± >, has a link with the elements insofar as these tags make it possible to dynamically load the TN _t which contain the elements. The fundamental difference between RichWord and RichBanner lies in the fact that the enrichment step here consists of storing the association of the element (here the word) and the tree structure (as well as its means of deployment). In the case of Rich-Word, there is no enrichment of a marker during a development phase. There is only one tag to put on the digital page. On the other hand, in the case of Rich-Banner, the original marker contains a reference to an element choice mechanism and the enrichment consists of adding a reference to it to a dynamic tree creation mechanism associated with the element.

Figure 24 illustrates the notion of association in the case of Rich-Word. This figure can however also apply to the case where the word is an element of another type. Rich-Word applies as much to the words contained in the Web pages as to the words contained in the source code of the vector graphics, of which the geographical vector maps, since the said graphics explicitly store the said words in their source code. - A possible application of Rich-Word concerns e-advertising by the ability to buy a word (s) on a web page, this for a fixed period, and to deploy menus adapted to this (these) word (s) and relating, for example, to service offers. - Another possible application concerns e-learning by the ability to provide detailed and structured explanations, text and / or multimedia, to words on web pages or vector graphics.

Another application relates to encyclopedias by the ability to associate words, contained in a web page or vector graphics, with detailed and structured explanations, textual and / or multimedia from a digital encyclopedia, possibly online. - Rich-Word can also be used for the translation of words, contained in a web page or vector graphics, by relying on digital dictionaries, possibly online. This list of possible applications is not exhaustive.

The Rich-Image principles are illustrated in FIGS. 25 and 26. We consider an image on which there is a set of m sensitive zones represented by the polygons P _k . The polygon P _k an (k) vertices whose coordinates are noted x _± , y _t . When we click on the polygon P _k we access the target_k.ext web page where the ext extension can belong, for example, to the following set: html, xml, asp, php, cfm, jsp ...

The HTML code of this image, with its sensitive areas, is as follows: <IMG src≈ "..." usemap = "# zones">

<MAP name≈ "zones">

<AREA href = "target_l.ext" shape = "poly" coords = "x ₁ , y ₁ , ..., x _{n (1)} , y _{n (1)} "/>

<AREA href = "target_k.ext" shape = "poly" coords = "x ₁ , y ₁ , ..., x _{n (k)} , y _{n (k)} "/>

<AREA hr ef = "c ib le_m. Ext" shape = "poly" coords = "x ₁ , γ ₁ , ..., x _{n (m)} , y _{n (m)} "/>

<MAP>

</ IMG> A modification of the HTML code consisting in giving, for the value of the "href" attributes of the "AREA" tags, an expression of the type "javascript: [menu javascript code]" gives, instead of a call to a Web page, the deployment a menu. <IMG src≈ "..." usemap = "# zones">

<MAP name≈ "zones">

<AREA href = "javascript: [javascript menu] _! " Shape = "poly 'coords =" x ₁ , y ₁ , ..., x _{n (1)} , y _{n (1)} ">

<AREA href≈ "javascript: [javascript menu] _k " shape = "poly" coords = "x ₁ , y ₁ , ..., x _{n (k)} , y _{n (k)} ">

<AREA href≈ "javascript: [javascript menu] ,." shape = "poly" coords = "x ₁ , y ₁ , ..., x _{n (m)} , y _{n (m)} ">

<MAP>

</ LMG>

The Rich-Image development phase will therefore consist of working from the original marker, constituted by the IMG tag, in order to enrich it, by adding a MAP tag defining all the sensitive areas deploying the menus. Unlike Rich-Banner and Rich-Word, the development phase incorporates a graphic work consisting of drawing on the image itself all the sensitive areas from which we intend to deploy the tree structures.

The development interface initially invites the user to paste the original marker in the "marker" field. The user then draws a sensitive area on the image it imported so that it appears on the interface page. Then it validates this sensitive area by clicking on the "Tree association" button, which opens a window ("tree selection and stylization") largely taking up the Rich- development interface. Banner. The user then defines a stylized tree for the sensitive area he has just drawn, by proceeding as if he were assigning a stylized tree to an advertising banner. Each stylized tree is saved in the tree structure database (El). After validation (click on the "OK" button), the window disappears, giving him the possibility of drawing other sensitive zones with which he will associate stylized trees (E2). As this process proceeds, the original marker is gradually enriched, the new marker being stored in the DOM of the web page of the development interface. Once this is done, the user clicks on the validation button ("OK" button) (SI), which results in the provision of the enriched marker in the "marker" field, so that the user can copy to transmit it to the management servers it chooses.

The production phase has one essential characteristic: after the enriched marker has called on the image via the IMG tag, it requests the tree server as many times as there are nested AREA tags in the MAP tag, that is to say as many times as there are sensitive areas associated with a tree structure.

As for the cascade of requests leading to calling the enriched marker, it can be, for example, a simple Web page incorporating this marker. The image can also be, for example, an advertising banner, in which case, said banner will be routed to the client platform of the Internet user according to the conventional process which we have already mentioned, namely the advertising tag, followed by agency tag and finally the call to the content server. Thus, it is conceivable to add sensitive areas to existing advertising banners, sensitive areas to which we associate tree structures stored on an independent tree server. Interactivity is thus added, no longer outside the banner but within the advertising space itself.

A special case of Rich-Image consists in navigating from images to images through sensitive areas, that is to say, allowing, from a click on a sensitive area zSi of image A, d '' reach an image B which, itself, contains sensitive zones whose target is another image. This can indeed be conceived according to the method of the present invention, insofar as we consider the creation of a tree structure T _L reduced to a sheet containing the client code (javascript for example) making it possible to reach the image B. This tree structure Ti may also not be reduced to a sheet and present a set of different images B _j towards which to navigate from the image A.

The sensitive areas of an image are made from closed polygons. The question arises of knowing if it is possible to establish, on an image, sensitive zones from other geometric primitives than closed polygons, and this without plug-in, that is to say by not counting only on the native browser. The solution goes through the possibility of constructing the set of geometric primitives from closed polygons. If this is done, then it will be possible to construct any geometric figure from sensitive areas. It is therefore a question of establishing a set of correspondence in the form, for example of script libraries in javascript.

The <map> tag must be used with the <area> tag, which has three attributes: shape, coords and href. We are interested here in shape and coords.

"Shape" can take three values:

- rect: For a rectangle - circle: For a poly circle: For a "c o o r d s" polygon:

- Indicates the coordinates of the upper left and lower right corners of the area for a rectangle "rect" - Indicates the coordinates of each angle of the polygon if you choose the value "poly"

- Indicates the coordinates of the center of the circle and the dimension of the radius of this same circle for the value "circle"

Polygons are of course no problem since they correspond to the "poly" value of the "shape" attribute. So: squares, rectangles, diamonds, triangles, quadrilaterals ... are no problem. Circles are of course no problem since they correspond to the "circle" value of the "shape" attribute. The line (AB) (as well as the half-line [AB) or the segment [AB]) is represented by the polygon ABA (triangle). The ellipse is represented by a polygon inscribed in the ellipse that we are trying to trace. The polyline (broken line) A _l ..., A _n is obtained by the polygon A _lf ..., _ _{ι r} A. ,, A- .. _! , ... _r A. The curve (C) is obtained by the polyline A _ιr ..., A-, the vertices of which are distributed regularly on the curve (C), and this frequently enough. The point is represented by a small diameter circle. And so on.

We can thus conceive in particular an equivalence between the principle of sensitive areas of an image in HTML and plug-ins with vocation of vector graphics (SVG, Flash ...).

It is noted that, in the case of the Rich-Geobject, and this most often, it is preferable to ensure that the server of the consultation medium is identical to the medium of the element, that is to say here of the space server. It is indeed necessary that the element, in order to be correctly displayed, undergo the same types of treatment as those applied to the consultation medium (the geographic map). These treatments are specific to GIS (Geographic Information Systems). These include intelligent agents for the storage and then the extraction of the data stored according to a spatial indexing, clipping avoiding any graphic overflow, transformations allowing conversion into structured mode of structured data for example in GML (Geography Markup Language).

The development phase of Rich-Geobject is fairly close to that of Rich-Image insofar as, in an equivalent manner, it integrates a graphic work consisting of drawing on the map even the set of geometric primitives of which we intend to deploy the structures tree.

If it is a static geographic map (Gif image for example), the problem comes down to the one already dealt with in Rich-Image. However, if it is a dynamic map, the problem comes down, in part, to that treated in the case of Rich-Word, namely the storage of the association between the element (here the geometric primitive) and the tree structure. Because it is only once that said primitive will become an integral part of the DOM of the page of the client platform, that it will be possible to carry out the search for the tree structure which has possibly been associated with it in a phase anterior development. Primitives are memorized by their shape in terrestrial coordinates (latitude and longitude). They are defined by the faculty offered, by the development interface to the user, of drawing these primitives in superimposition of a geographical map, then of associating them with stylized tree structures. The development interface must therefore serve a geographic map, coming from a space server, and allow the internet user to navigate on said map, in order to correctly position said geometric primitive. The production phase will be based on geographic maps served by the same space server as that which served during the development phase, in order to avoid any problem of data inconsistency.

Figure 29 shows an example of a development interface. Phase E1 corresponds to the registration of the stylized tree, while phase E2 brings the user back to the starting interface. In the SI phase, the terrestrial coordinates of the geometric primitive, which he has just drawn on the geographic map, are recorded, as well as the association of this primitive with the stylized tree which he has just created.

FIG. 30 represents an example of the Rich-Geobject production phase, in the case of a space server relying on SVG technology. The user's request leads to the display of a geographic map, which which leads to display the corresponding geometric primitives, and which ultimately leads to importing the stylized trees associated with these geometric primitives. Thus, in the display phase, the Internet user makes a spatial request from, for example, a click on a geographic map of a web page. In the deployment phase, the tree structure is graphically deployed from a mouse over of one of the displayed elements. Finally, in the use phase, the user clicks on one of the menus deployed and has access to the corresponding minipage in a pop-up, minipage possibly dynamically created to take into account the geographic coordinates corresponding to the cursor position.

Consider a new generation type navigation.

The traditional method of navigation can be modeled like this: the Internet user navigates from Web pages to Web page by means of clicks on the links of said pages. We will identify each stage of this navigation by the index i = l, 2, 3 ... At the i ^th stage of navigation, we will note _L the web page displayed in the browser. The internet user starts browsing by opening the browser which opens the home page of said browser, a web page corresponding to the index i≈l. In other words, navigation starts on page A ₁ . We define the web page sequence (A _A ) in the following way: the Internet user goes from page A _L to page A _{i + 1} by clicking on a link on page Ai. The links of a Web page are identified, in its DOM (document object model), among others by the attribute "href" of the elements "A" or of the elements "IMG". The user clicks on the k ^th link of the page A _± , k ^th link in the order of appearance in the DOM of the page A _i in the sense of a parsing defined beforehand. We can therefore define the sequence (k _± ) as the sequence formed by the indices k chosen by the user during his navigation from page to page. In other words, at the i ^th step, the user clicks on the ki ^th link on page A. Like the sequence (i), the sequence (k _± ) is not known a priori, but is built as you navigate. It is therefore known only a posteriori, no mathematical rule making it possible to define it a priori since it depends on the arbitrary choices of the navigation of the Internet user.

We will note A _± (k) the web page, target of the k ^th link of page A _± . At the i ^th stage of his navigation, the Internet user clicks on the kJ " ^th link of the page A _if link whose value of the attribute href is therefore url (A _± (ki)). By definition of the continuation of Web pages (A _± ) constituting the navigation of the Internet user, we have: A _{i + 1} = Ai (k _± ). This is a way of saying that page A _{i + 1} is the target page of the link k _A from page A _± .

Now define a Farnelian navigation: consider a traditional navigation (Ai), defined by the relation: A _{i + 1} = Ai (ki). Then consider a dynamic page P located on a server at the following url: url (P). By assumption, this dynamic page P must admit, as input, at least one parameter named "url", of type string. We will write: P (url, ...) A navigation ('i) is called "Farnelian navigation of origin (A _£ ) and of parameter P", which we note (A'i) = F [(A _L ), P], if, for all i, we have A'i (k) = P (url (A _± (k)) ...). If we replace k with k _if we then have:

A'i (ki) = P (url (Ai (ki)), ...) or A ' _{i + 1} = P (url (A _{i + 1} )). In the case, for example, of the k ^th link constituted by a hypertext link, we had, in the DOM of page A _lr the following element: <A href≈ "url(A _± (k))"> Now, we have, in the DOM of page A'i, the following element: <A href≈ "url (P)? url≈ 'url (Ai (k))'& ... ">

Once k _{£ has been} determined (when the user clicks), A _{i + 1} is determined at the same time, since A _{1 + 1} = Ai (k _± ). The query launched is then the following: “url (P)? url≈ ⁱ url (A _i (k _i )) '& ... ", that is to say:" url (P)? url≈ 'url (A _{i + 1} )'& ... "

The nature of the dynamic page P conditions the type of processing carried out on the server. So that navigation (A ' _± ) "sticks" as much as possible to navigation (Ai), care must be taken to ensure that an additional constraint relating to the nature of this processing is observed. In our case, A ' _{i + 1} (result of the query "url (P)? Url≈' url (A _{i + 1} ) '&...") must not be too far from A _{i + 1} . We will therefore impose that, at a minimum, the _k ^th ii _en on page A ' _{i + 1} has for target "url (P)? url≈ ^y url (A _{1 + 1} (k)) '& ... "Which means that the processing performed by page P contains, at a minimum, the operation consisting, for each link k of page A _{i + 1} (page accessible since its url is in parameter of P), to extract the url url (A _{i + 1} (k)), and to perform a concatenation of character string resulting in the dynamic creation of the following character string: "Url (P)? url≈ ^y url (A _{i + 1} (k)) '& ... ", string placed on the target page of the _k th _{link of page A} / _{l + ι} .

A generalization of the concept of navigation

Farnelienne can consist in not being constrained by a dynamic page P independent of the indices i and k. We we will then denote P _ik instead of P. We thus define, from the navigation (A _x ), a navigation (A'i), called the “original (A)” navigation and “subsequently configured

(Pi *) » ^• The sequence (A ' _{i + 1} ) is then defined by the following recurrence relation:

A ' _{i + 1} = P _ik (url (Ai (ki)), ...) or A' _{i + 1} = P _ik (url (A _{i + 1} ))

A navigation (Bi) is said to be conditioned if there is a navigation (A _£ ) and a series of conditions (Ci), such that, for all i, the page Bi corresponds to the "minimal" transformation of the page Ai, of such that B _± verifies the condition Ci. We will note: (Bi) = C [(A _± ), (Ci)] We will say of the navigation (Bi) that it is a navigation conditioned by (Ci) and of origin (A _± ).

Special case: In the case where the sequence (Ci) is constant and worth C, we will say, by abuse of language, that (B _± ) is conditioned by C.

Condition C, which is supposed to be verified by A _L , page currently displayed in the browser, is said to be "propagated" from A _L to A _{i + 1} if, at the end of the transition leading to display of A _{i + 1} , it is verified by A _{i + 1} .

By definition of a navigation (Bi) conditioned by condition C, said condition C must be verified for any i greater than or equal to 1. For this to be achieved, it must be verified for i≈l and must "propagate" from A _A to A _{i + 1} (this for any i greater than or equal to 1). For the propagation method of condition C to be effective, account must be taken not only of the propagation of said condition C but also of the propagation of the means of this propagation. One way of carrying out such a propagation consists in ensuring that there is a file, called by “remote script” convention, including a code interpretable by the client platform, such that, for all i, the following two constraints are verified:

"Ai contains a reference to the" remote script "

A special case is that of the remote script whose language is javascript, and which we will note “sd.js”, said reference can then be expressed as follows: <SCRIPT src≈ “url (sd.js)”> </ SCRIPT

• The target of the k ^th link on page A _± is an instruction launching the sd function with the parameter (url (Ai (k))).

In the previous particular case, it will be the following instruction:

"Javascript: sd (url (Ai (k)))"

So far, we have mentioned the notion of propagation of the condition C from i to i + 1. It is of course necessary, so that such a propagation can exist, that the first page A _λ of such a navigation (Ai) satisfies said condition C, in other words that there is a beginning to this propagation. The solution here will be to ensure that such navigation starts as soon as the browser is opened. For that, the solution consists in redefining the home page of the navigator, which we will note A ₀ , without forcing to the Net surfer to see, at the opening of the navigator, another page than that which it has used to see first, page that we will note here A _x . In other words, it will be a question of defining a new home page A ₀ which will process and then redirect to page A _λ . The purpose of said processing will be to cause page A _{x to} satisfy condition c, because if this is the case, it will therefore be the same for page A ₂ then page A ₃ and so on, because the spread of said condition.

It is a problem equivalent to the known principle of mathematics, called "recurrence". If we note P _± the following property: (P _A ) "Page A _± checks condition C"

And if we assume that:

• the property P _x is true,

• For any i greater than or equal to 1, (Pi is true) implies that (P _{± +} i is true)

Then, in accordance with the principle of recurrence, we can say that: for any i greater than or equal to 1, (P _± is true).

This is another way of saying that whatever page is reached during the browsing process, the user checks condition C.

The main thing is therefore to ensure that the page A ₀ redirects to A _x in such a way that P _x is true, that is to say that A _x satisfies condition C.

The user defines the page he will see first (A _x ) through a dedicated website and no longer directly by the browser.

Once this page A _x filled using a text field of a form of said dedicated website, the validation of said form results in the creation of a dynamic page verifying condition C as well as the means of its propagation, and automatically redirecting to page A _x .

The validation of the form also entails the modification of the browser settings by assigning the dynamic page A ₀ as its home page.

We will say of the Farnelian navigation (A'i) = F [(Ai), P] that it is a navigation of permanent element "ep", if it is a navigation conditioned by the condition C defined by the fact that , for all i:

The DOM of A ' _± includes a fragment identified by the character string "ep", the interpretation of this fragment by the browser corresponding to the representation of said permanent element on the page displayed in the browser.

An example of a fragment is the following layer: <DIV id≈ "ep"> ... HTML code ... </DIV> (We will consider, in the following, to be in this particular case). Said fragment is posted to be retrieved by the dynamic Farnelian navigation page. The propagation of said condition C consists in propagating a fragment of code identified permanently from page to page, as well as in propagating the means of this propagation. In order to differentiate the particular case of the condition of the permanent element from a more general condition, we will name "ep" the remote script and "ep ()" a function defined in said remote script.

A particular case is that of the permanent script expressed in javascript, which we will note "ep.js", said reference can then be expressed as follows: <SCRIPT src≈ "url (ep.js)"> </SCRIPT>

By definition of the sequence (k _± ), the user clicks on the ki ^th link on the page A _ir which, by hypothesis, calls the function ep (url (Ai (ki)). Let us study a possible principle of operation of such a call:

• this function dynamically creates a form containing a text field (element of type "input"), whose attribute "name" has the value "ep", which allows the element <DIV id = "ep"> to be posted, this thanks to the document method. getElementByld ("ep") which locates this element.

• The function then gives, in value of the "action" attribute of the "submit" button of said form, the character string corresponding to the following query: url (P)? url = url (Ai (ki)), where A ^ k is the character string passed in parameter of the "ep" function.

• Finally, the function simulates a click on the "submit" button of the form, this thanks to the "submit.click ()" instruction, which results in sending said request accompanied by the fragment corresponding to the permanent element in the state it was in when the user clicked on one of the links on the Ai page.

In the context of XML technology, we can consider that page P is an XML file associated with an XSLT stylesheet which we will denote by Q; The dynamic page is then noted: P _Q.

ceci grâce à l'url dont la chaîne de caractères est explicitement écrite en paramètre de la requête url(P_Q?url(Ai(ki) ) ) .The page P _Q towards which the Internet user is directed is therefore the result of an XSLT process transforming the page A _{i + 1} into A ' _{i + 1} , which can be noted in the form: A' _{i + 1} = P _Q (A _{i + 1} ). The P _Q page starts with load the page in your DOM

this thanks to the url whose character string is explicitly written as a parameter of the url request (P _Q ? url (Ai (ki))).

) :Let us now detail the transformation t transforming A _{i + 1} into A ' _{i + 1}

):

Once the page A _{i + 1} loaded in the DOM of page P _Q , the latter will parse (cross) the DOM of page A _{i + 1} in search of link occurrences (for example by searching for elements having a attribute "href"). For each link thus found, it analyzes the character string constituting the value of its target (for example the value of the "href" attribute). If the said character string begins with the expression "javascript", no modification is made. If it is not the case, that means that the value of the attribute "href" of the k ^th link of the page A _{i + 1} is of the form url (A _{i + 1} (k)). The XSLT process then modifies the value of this attribute by dynamic concatenation of a character string so that the new value is: "javascript: ep (url (P _Q )? Url (A _{i + 1} (k)))", which allows to make sure that the second condition constraint is checked by the page

It thus propagated well from i to i + 1. It therefore suffices that it is verified for i≈l so that, propagating in this way, it is verified for any i greater than or equal to 1, in accordance with the mathematical principle of reasoning by induction (See previous chapter). In the same way, the first conditioner constraint propagates from i to i + 1 by the simple capacity of the process P _Q to generate the following code: "<SCRIPT src≈" ep.js "></SCRIPT> in the new page displayed.

The first condition of the permanent element propagated from i to i + 1, since the dynamically created form posted the fragment identified by "Ep", so that it is retrieved from the new page displayed. As for the second condition of the permanent element, it has propagated from i to i + 1 since it is a functionality included in the ep () function, to which the new page displayed refers because of the propagation of the two conditioning constraints.

The principle of Rich-Miniportail is to allow a surfer to browse the Internet while having "at your fingertips" his personalized portal "which follows him from page to page".

Rich-Miniportail is used in accordance with the principles inherent in the present invention, in particular with regard to the ability to consult and act on the miniportal without leaving the consultation site.

Rich-Miniportail is, from this point of view, an advance, compared to the toolbars of the portals that the Internet user installs on his computer, insofar as the buttons of the said toolbars cause redirection to a Web page other than the user’s consultation page.

On the other hand, Rich-Miniportail benefits from all of the Rich-Navigator functionalities, namely the ability to create personalized tree structures that use services provided by external companies: weather, dictionary, calendar ... .

Thus, the Internet user can choose a certain number of functionalities which do not necessarily exist in a given portal, or choose an equivalent service, but other than that offered in the portal which he is used to using.

Once defined custom tree structures stored on a tree server, Rich- Miniportal can be accessed as well via the buttons of a toolbar as by what we will call in the following a "permanent element".

The principle of the permanent element for the

Rich-Miniportail is the following: when loading a new page in a browser, this process allows an object, which occupied a determined position in the main window of the browser as well as a particular intrinsic state, to appear in the same position and state on the newly loaded web page.

This principle is illustrated in Figure 31 (same position) and Figure 32 (same state).

The process is as follows: the solution consists in writing dynamically, in the DOM (document object model) of the web page being loaded, a layer containing the information, relating to the permanent element, retrieved from the previous page , in accordance with the so-called “permanent element navigation” process as described in the previous chapter.

This layer must be positioned precisely in the main browser window, which requires specifying a value for the position attribute: absolute ... This is one of the conditions for conditioned navigation.

The start-up of the process by the Internet user includes the following steps:

• User registration on a specific website

The Internet user, in order to start the navigation process by permanent element, must register with prior to an online service available using an interface on a dedicated site. The user registers by defining his pseudonym and a password.

• Definition of the type of the element

Once registered, the user accesses other interfaces, allowing him to choose the type of graphic element that will be displayed superimposed on the web pages on which he will navigate.

• Creation of trees

The user then accesses an interface for creating tree structures. For this purpose, he will use services which he will personalize according to his specific needs: agenda, dictionary, weather forecast ... He will benefit from all the functionalities already discussed with regard to the creation of tree structures: composition of 'a tree from two trees ...

• Creation and activation of a permanent element

The creation of a permanent element consists first of all in associating a graphic element with a tree and then in storing this association in the database of a server. The activation of this permanent element then consists in clicking on a validation button, which has the effect of giving a boolean the value true specifying thus that this element must be served when opening the browser.

• Definition of a home page The definition of a home page is done in the same way as for the initiation of the conditioned navigation process. The method for initiating navigation by permanent element is described above.

When a user searches for occurrences of a word on the Web using a search engine, the search can extend to a search in the text content of vector graphics as well as in active tree structures.

Vector graphics provide access to text content explicitly written in the source code. We can therefore extend the search of search engines to the textual content of vector graphics (SVG, Flash ...). This applies, in particular, to the case of vector mapping. One can, in fact, consider a search by a search engine which leads, in addition to traditional results (web pages, images ...), to display the results of the textual content of vector geographic maps. For example, a search on the word "Prune" can lead to the display of a geographical map automatically centered on the city of Agen, if a map, for example in SVG format is present on the Web and mentions, in its source code, the word "Prune" at the level (latitude and longitude) of the city of Agen. The word "Prune" may be stored in a database and not in the source code of the SVG file which is created dynamically by drawing information from the said database. In this case, the problem is equivalent to the problem of referencing dynamic web pages, some solutions of which have been envisaged such as the fact of producing static pages from dynamic pages and of storing them on a web server. Conversely, we can consider a geolocated service allowing to geographically restrict the search for a search engine. search based on the location of the click on a geographic map. This also applies to the case where the geographic position is not obtained from a click on a geographic map but from a GPS. In addition, Rich-Word is not reduced to use on a Web page but also on geographic maps given the textual access to the words on said map.

Activated trees can, for example, be made available on a web server as a static page. In this way, by ensuring that these pages are referenced by the search engines, said trees will also be accessible when searching for a word on a search engine. An advertisement in the form of a Rich-Banner will therefore benefit from greater visibility since it is also accessible through search engines.

The invention is described in the foregoing by way of example. It is understood that a person skilled in the art is able to produce different variants of the invention without going beyond the scope of the patent.

Claims

1. Method for enriching the content of a digital page whose format allows the creation of links to computer objects, and whose representation is displayed by means of a display medium after loading of said digital page on computer equipment connected to a communication network from at least one computer server, characterized in that it comprises: • a step of defining at least one tree structure consisting of a structured code representing a tree structure whose sheets correspond to target codes, capable of presenting information structured by successive overlaps; • a step of defining at least one element consisting of a computer file capable of representing a multimedia object; • a step of creating at least one original marker, consisting of a code including a reference to one of said elements; • a step of enriching the original marker consisting in the generation of a new marker substituted for said original marker, said original marker being modified from: the content of the original marker, from a (of) reference (s) to said ( said tree structure (s) and a means of deploying the representation of said tree structure; • a step of adding, on the digital page, a link to the enriched marker; • a step of displaying on a client equipment the representation of said enriched marker leading to an “enriched representation” of said element; • a step of deploying the representation of said tree structure in the display medium, after action by a user on the "enriched representation" of said element. 2. Method for enriching the content of a digital page according to claim 1, characterized in that said step of defining a tree structure comprises a sub-step of storing a tree structure or of a mechanism making it possible to dynamically create a tree structure according to context parameters. 3. A method of enriching the content of a digital page according to claim 2, characterized in that the storage takes place on a dedicated server. 4. Method for enriching the content of a digital page according to claim 2, characterized in that the storage takes place locally. 5. Method for enriching the content of a digital page according to claim 2, characterized in that the storage takes place with the original marker. 6. Method for enriching the content of a digital page according to one of claims 2 to 5, characterized in that the storage is carried out in the form of files, these files being files of SGML format or of a derived format SGML, XML format files or a format derived from XML, DHTML format files, binary format files, precompiled format files or text format files. 7. A method of enriching the content of a digital page according to one of claims 2 to 5, characterized in that the storage is carried out in a digital database, this digital database being relational or object. 8. Method for enriching the content of a digital page according to one of the preceding claims, characterized in that said step of defining a tree structure consists in the creation of this tree structure. 9. A method for enriching the content of a digital page according to one of claims 1 and 2, characterized in that said step of defining a tree structure consists in modifying an already existing tree structure. 10. A method of enriching the content of a digital page according to one of claims 1 and 2, characterized in that said step of defining a tree structure consists in the composition of a tree structure from at at least two already existing tree structures, these tree structures not necessarily being distinct from each other. 11. A method of enriching the content of a digital page according to claim 9, characterized in that said modification consists in the removal of a node from said already existing tree structure. 12. A method of enriching the content of a digital page according to claim 9, characterized in that said modification consists in the creation of a new node of said already existing tree structure. 13. A method of enriching the content of a digital page according to claim 9, characterized in that said modification consists in modifying a node of said already existing tree structure. 14. A method of enriching the content of a digital page according to claim 9, characterized in that said modification consists in the displacement of a node of said already existing tree structure. 15. A method for enriching the content of a digital page according to claim 10, characterized in that said composition consists in attaching a fragment or all of one of the tree structures already existing to another tree structure already existing. 16. Method for enriching the content of a digital page according to claim 1, characterized in that the user is an automaton. 17. A method of enriching the content of a digital page according to claim 1, characterized in that the deployment means is of software nature. 18. A method of enriching the content of a digital page according to claim 1, characterized in that the deployment means is of a material nature. 19. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is a program installed locally. 20. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is a web browser. 21. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is a plug-in associated with a web browser. 22. Method for enriching the content of a digital page according to claim 1, characterized in that the display medium is implemented on an on-board system. 23. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is implemented on a personal computer. 24. Method for enriching the content of a digital page according to claim 1, characterized in that the display medium is implemented on an interactive terminal. 25. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is implemented on an interactive television apparatus. 26. A method of enriching the content of a digital page according to claim 1, characterized in that the display medium is implemented on a portable device. 27. A method of enriching the content of a digital page according to claim 1, characterized in that the action of a user on the representation of the enriched marker consists of a mouse event or a keyboard event. 28. A method of enriching the content of a digital page according to claim 1, characterized in that the action of a user on the representation of the enriched marker consists of an audible signal. 29. Method for enriching the content of a digital page according to claim 1, characterized in that the action of a user on the representation of the enriched marker consists of a tactile event. 30. A method of enriching the content of a digital page according to claim 1, characterized in that the action of a user on the representation of the enriched marker consists of an automation triggered by the context. 31. A method of enriching the content of a digital page according to claim 30, characterized in that the context is the physical geographic location of the user. 32. Method for enriching the content of a digital page according to claim 30, characterized in that the context is a keyword. 33. Method for enriching the content of a digital page according to claim 30, characterized in that the context is the date. 34. Method for enriching the content of a digital page according to claim 30, characterized in that the context is the geographical location as it is designated by the user. 35. A method of enriching the content of a digital page according to claim 30, characterized in that the context is a predefined constraint in advance. 36. A method of enriching the content of a digital page according to claim 1, characterized in that said digital page is a card support. 37. Method for enriching the content of a digital page according to claim 1, characterized in that said digital page is a medium for multimedia or text content. 38. A method of enriching the content of a digital page according to claim 1, characterized in that said digital page is a computer object support. 39. Method for enriching the content of a digital page according to claim 1, characterized in that said digital page is a static or dynamic page written in DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM , JSP, SVG, Java, JavaScript, or VBScript. 40. Method for enriching the content of a digital page according to claim 1, characterized in that said digital page is a static or dynamic page containing code written in DHTML, XML, HTML, C- HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 41. Method for enriching the content of a digital page according to claim 1, characterized in that said digital page is a static or dynamic page using code written in DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 42. Method for enriching the content of a digital page according to claim 1, characterized in that said digital page is a static or dynamic digital page, implementing Flash animation. 43. Method for enriching the content of a digital page according to claim 1, characterized in that said original marker consists of a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 44. A method for enriching the content of a digital page according to claim 1, characterized in that said original marker contains a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 45. A method of enriching the content of a digital page according to claim 1, characterized in that said original marker uses a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 46. A method of enriching the content of a digital page according to claim 1, characterized in that said original marker is a compiled or pre-compiled program, of ASCII code or of text. 47. Method for enriching the content of a digital page according to claim 1, characterized in that said original marker is a file, this file is a multimedia file, a text file, a file of SGML format or of a format derived from SGML, an XML format file or a format derived from XML, a DHTML format file or a data file. 48. Method for enriching the content of a digital page according to claim 1, characterized in that said enriched marker consists of a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 49. Method for enriching the content of a digital page according to claim 1, characterized in that said enriched marker contains a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 50. A method of enriching the content of a digital page according to claim 1, characterized in that said enriched marker uses a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 51. Method for enriching the content of a digital page according to claim 1, characterized in that said enriched marker is a compiled or pre-compiled program, ASCII code or text. 52. Method for enriching the content of a digital page according to claim 1, characterized in that said enriched marker is a file, this file is a multimedia file, a text file, a file of SGML format or of a format derived from SGML, an XML format file or a format derived from XML, a DHTML format file or a data file. 53. A method of enriching the content of a digital page according to claim 1, characterized in that said tree structure is reduced to a single sheet. 54. Method for enriching the content of a digital page according to claim 1, characterized in that said target codes are references to target files consisting of a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 55. Method for enriching the content of a digital page according to claim 1, characterized in that said target codes are references to target files containing a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C- HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 56. Method for enriching the content of a digital page according to claim 1, characterized in that said target codes are references to target files using a code written in DHTML, SGML or one of its derivatives, XML or one of its derivatives, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, or VBScript. 57. Method for enriching the content of a digital page according to claim 1, characterized in that said target codes are references to multimedia files, these multimedia files being sound, animation or video files. 58. A method of enriching the content of a digital page according to claim 57, characterized in that said multimedia files are broadcast in the form of streaming. 59. Method for enriching the content of a digital page according to claim 1, characterized in that said representation of said enriched marker is a set of nested menus and submenus. 60. Method for enriching the content of a digital page according to claim 1, characterized in that said representation of said enriched marker is a set of separate drop-down lists. 61. Method for enriching the content of a digital page according to claim 1, characterized in that said representation of said enriched marker is a set of sensitive areas of a multimedia file. 62. Method for enriching the content of a digital page according to one of the preceding claims, characterized in that the sheets of said tree structure correspond to links dynamically created according to conditions resolved at the time of the request of the user. 63. Method for enriching the content of a digital page according to one of the preceding claims, characterized in that the sheets of said tree structure correspond to static links. 64. Method for enriching the content of a digital page according to one of the preceding claims, characterized in that said tree structure is created via a creation interface. 65. A method of enriching the content of a digital page according to claim 64, characterized in that said creation interface is accessible online. 66. Method for enriching the content of a digital page according to claim 64, characterized in that said creation interface is part of software installed on the workstation of the user of said interface. 67. Method for enriching the content of a digital page according to one of the claims above, characterized in that said step of defining a tree structure consists in calling a tree structure previously recorded on a recording medium. 68. A method of enriching the content of a digital page according to claim 67, characterized in that said recording medium is a removable medium. 69. A method for enriching the content of a digital page according to claim 1, characterized in that the original marker refers to an advertising banner. 70. A method of enriching the content of a digital page according to claim 1, characterized in that the enriched marker dynamically uses the tree structures relating to the words dynamically loaded on the digital page. 71. A method of enriching the content of a digital page according to claim 1, characterized in that the enriched marker dynamically uses tree structures relating to the intersection of a geographic context and a thematic context loaded dynamically on the digital page. 72. Method for enriching the content of a digital page according to any one of the preceding claims, characterized in that the step of dynamic display of the representation of said enriched marker includes dynamic modifications of the digital page. 7 3. Multi-server IT architecture, characterized in that it comprises in particular: • a client station calling a digital page whose content is enriched according to the method of claim 1; • an element server storing elements; • a server containing rules for calling said references to said elements; • a dedicated server containing the tree structures; • a Web server containing said digital page. 74. Multi-server computer architecture according to claim 73, characterized in that it further comprises a server containing references to said elements and rules for calling towards said elements 75. Multi-server computer architecture according to claim 73 or 74, characterized in that it further comprises a second Web server containing target files. 76. Multi-server computer architecture according to claim 73, characterized in that the elements are pages of text. 77. Multi-server computer architecture according to claim 73, characterized in that the elements are geometric figures or words, in that the Web server containing said digital page is a space server.