FR2805375A1 - System for sharing information on a computer network - Google Patents

System for sharing information on a computer network Download PDF

Info

Publication number
FR2805375A1
FR2805375A1 FR0007249A FR0007249A FR2805375A1 FR 2805375 A1 FR2805375 A1 FR 2805375A1 FR 0007249 A FR0007249 A FR 0007249A FR 0007249 A FR0007249 A FR 0007249A FR 2805375 A1 FR2805375 A1 FR 2805375A1
Authority
FR
France
Prior art keywords
information
user
container
links
gt
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0007249A
Other languages
French (fr)
Inventor
Enrico Maim
Original Assignee
Enrico Maim
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR9914151A priority Critical patent/FR2805373A1/en
Priority to FR0004207A priority patent/FR2807179A1/en
Application filed by Enrico Maim filed Critical Enrico Maim
Priority to FR0007249A priority patent/FR2805375A1/en
Publication of FR2805375A1 publication Critical patent/FR2805375A1/en
Application status is Withdrawn legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/016Input arrangements with force or tactile feedback as computer generated output to the user
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/953Querying, e.g. by the use of web search engines
    • G06F16/9535Search customisation based on user profiles and personalisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/955Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9562Bookmark management
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2203/00Indexing scheme relating to G06F3/00 - G06F3/048
    • G06F2203/01Indexing scheme relating to G06F3/01
    • G06F2203/014Force feedback applied to GUI

Abstract

An information sharing system on a computer network comprises: a first set of organized information comprising at least a first container and a plurality of first information accessible via the or each first container, a second set of organized information comprising at least a second container and a plurality of second information accessible via the or each second container, means for establishing a correspondence between the or each first container and a second said container, means for a user to add information in the first set of information, means enabling a user to add information in the second set of information, network communication means between the first and second sets of information, said means being capable, during a adding information accessible via a first container, to suggest the same addition in the s econd corresponding container. Application in particular to the improvement of the reciprocal contribution between personal data and collective data on the Internet.

Description

The present invention relates generally to a management system

  of a plurality of organized information sets, including information

personal network.

  More specifically, the present invention aims at enabling each individual in a community to organize his information and selectively share it in community on the Internet or within a private network ("intranet"), with particular functions of collective construction of information of the same categories and automatic suggestion of information when they belong to

given categories.

  BACKGROUND The so-called "bookmark" concept, which enables an individual to establish and memorize links to his favorite server pages, is already known in the state of the art. The present invention aims more specifically at combining and organizing, within the same user interface, different pieces of information, created or collected from different sources, for example by extracting them from different sources. other pages

Internet servers.

  Another object of the present invention is to ensure that each added piece of information transparently or semiautomatically adopts a defined category or subcategory of the organized information set.

  it is hoped that it will allow access to this piece of information.

  Another object of the present invention is to ensure that non-confidential information items inserted into a user's information set can be viewed by other users as part of their own set of information. information, that is to say inserted by them in a

  container own ad hoc for viewing.

  In other words, the purpose of the invention is to propose means of intercommunication such that the addition of a new piece of information in a given category by a given user amounts to publishing this piece of information in association with this category, thus going well beyond what bookmarks allow

  equipping current Internet browsers.

  Another object of the invention is to ensure that the users who feed or consult the information elements can do so in

conditions of anonymity.

  Moreover, the invention also aims to propose that the fact that a user adds a piece of information to a category represents a "declaration of interest" that can be exploited in the context of new business models, according to which, in response to such expressions of interest, other information

  may be offered (especially for sale) to the user automatically.

  The present invention also aims to propose the use of an open system of category vocabularies, which references the information elements and their containers. In view of the fact that categorizations made by users are subject to errors (involuntary or voluntary), another object of the present

  invention is to propose means of self-purification by the users themselves.

  same, on the basis of a qualitative degree of contribution, exploitable by transitivity.

  Another object of the invention is to preserve the anonymity of the users.

  The present invention also aims at automatically suggesting or recommending new information to each user according to his statements.

interests or tastes.

  SUMMARY OF THE INVENTION Thus, the invention proposes a system for sharing information between at least two users on a computer network, characterized in that it comprises: a first set of organized information comprising at least a first container and a plurality of first information accessible via the or each first container, a second set of organized information comprising at least a second container and a plurality of second information accessible via the or each second container, means for establishing a match between the or each first container; containing and a second said container, means for a user to add information in the first set of information, means for a user to add information in the second set of information, means for network intercommunication between the first and second sets of information, these means being apt when adding information accessible via a first container, to suggest the same addition in the second

corresponding container.

  Preferred, but not limiting, aspects of the system according to the invention are the following: each information accessible via a workbook belongs to a group comprising direct contents, references to contents located in other organized information sets and Sub-containers via which other information

are accessible.

  said references to contents are constituted by links.

  the first set of organized information is part of a server and is intended to be accessible by a plurality of users of a community, and there is provided a plurality of second sets of organized information constituting

  private sets specific to a plurality of users.

  the information accessible via the containers of the first set of information organized is constituted by the union of all the information accessible via the

  corresponding containers of the second sets of organized information.

  - all organized information sets include an organized structure

of containers.

  - the organized structures are arborescent.

  2 0 - all organized information sets include the same structure

organized containers.

  the system comprises, in association with a set of organized information in which an addition of information has been suggested, a memory containing a

  Suggestion process state flag.

  - the status indicator can take the values "Suggested", "Accepted" and "Rejected".

  the system comprises a means for deleting information previously added to a set of organized information only after checking the status indicators associated with the other sets of information

  organized on the said added information.

  the verification of the state indicators consists in verifying that all have the value "Refused", the system also comprises suitable warning means, when a content-type information previously added in a set of organized information is intended to be deleted, to inform of said desired deletion any user of another set of organized information having a reference to this content, and means allowing each user to duplicate said

  content element to said other set of organized information.

  said information includes links to contents external to the system.

  - each set of organized information also provides access to

  information the addition of which does not give rise to any suggestion.

  the means of intercommunication comprise means for deriving from an original container of a first set of organized information to a destination container of a second set of organized information information accessible via said original container said correspondence means being responsive, in response to said derivation means, to a correspondence between the original container and the container

of destination.

  in response to said derivation means, the correspondence means are also able to establish a correspondence between the container

  destination and the original container.

  the means of intercommunication furthermore comprise means suitable, during the implementation of the diversion means, for selectively accepting and refusing

  accessibility of said information via the destination container.

  the derivation means are capable of conducting chain derivations between

  several sets of information organized.

  the derivation means are able to merge into a destination container

  given information accessible via a plurality of original containers.

  - the system includes suitable means, when removing in a container the accessibility of information by this container, preserve the accessibility of this

  information via an archive container.

  when the accessibility of previously added information via a container is removed, the means of intercommunication are no longer able to suggest the addition of this information in the corresponding container or containers of other sets

organized information.

  the means of intercommunication comprise means for referencing, from an original container of a first set of information organized to a destination container of a second set of organized information, the information accessible via said original container, said means for establishing correspondence being able to establish a correspondence between the original container and the destination container in response to said referencing means only if a user of the container of destination has accepted the

  referencing said information.

  the system comprises a set of organized information comprising a plurality of categorizing containers, and the containers of each other set of organized information are at least partially corresponding to said

categorizing containers.

  all the containers of each other set of information organized are necessarily correspondents of said categorizing containers. each container has a name, and means are provided, when adding in a set of organized information a container corresponding to a categorizing container, to name it regardless of the name of the container

categorizing.

  - The derivation means are also able to derive a plurality of containers organized according to a container structure, said container structure being

preserved during the diversion.

  each organized information set comprises a container tree structure, and the system further comprises means for representing at least the highest level containers in the tree structure under

form of binders.

  the system further comprises means for representing containers of

  lowest level in the tree structure in the form of workbook pages.

  the system comprises means for representing content elements accessible via containers forming pages in the form of layers applied to

the page considered.

  each set of organized information comprises a tree structure of containers, and the system further comprises means for representing, in zones adjacent to a user screen, the tree structure of a set of organized own information user and the tree structure of a

  another set of organized system information.

  the derivation means are controlled by a drag-and-drop operation performed on said representation of the tree structures. the referencing means are controlled by a drag-and-drop operation

  performed on said representation of the tree structures.

  the system further comprises contribution notation means according to the result of suggestions for adding information between two sets

organized information.

  the contribution notation means comprise a plurality of contribution variables able to vary in one direction when a suggestion of adding information is accepted and in the opposite direction when a suggestion of adding information is refused. a contribution variable per pair of sets of information is provided

2 0 organized.

  the system further comprises means for similarity notation between information accessible via two containers belonging to two sets of organized information, as a function of the number of information added after

  2 5 suggestion of a container towards the other and vice versa.

  the similarity notation means comprise a plurality of similarity variables able to vary in one direction when a suggestion for adding information is accepted and in the opposite direction when information whose addition has been added

  3 0 previously accepted is deleted.

  a similarity variable is provided for each pair of corresponding containers.

  the means for establishing correspondence between containers of two sets of organized information are able to be implemented between two containers which are not previously corresponding in pairs, but belonging to a chain of corresponding containers two by two, in a function of the value of the contribution and / or similarity variables in relation to the sets

  associated organized information.

  the system includes means for neutralizing the suggestion process between sets of information organized when a contribution notation and / or

  similarity concerning said sets is less than a threshold.

  the means of intercommunication are able to suggest said addition of information

for a limited time.

  - when adding a container to a set of organized information, provision is made for determining whether the container is susceptible in itself or not.

  to be mapped to another container.

  Other aspects, objects and advantages of the present invention will become more apparent

  reading the following detailed description of a preferred embodiment of

  this, given by way of nonlimiting example and with reference to the accompanying drawings, in which Figures 1 to 13 diagrammatically illustrate different states and behaviors of a display management method according to the invention, FIGS. 17 are diagrammatic perspective views illustrating the behavior of two superimposed display elements and associated zones according to a generalization of the invention, FIG. 18 is a plan view of the various zones exploited, FIG. possible positions of a given display element, FIG. 20 indicates a representation symbol of the states of the display management system, FIG. 21 is a state-transition diagram of the system, FIG. 22 illustrates by modeling. in section, transversely to the plane of the display, the behaviors illustrated in FIG. 21, FIGS. 23 to 25 are schematic perspective views illustrating the the behavior of the system of the invention with three superposed display elements, FIG. 26 illustrates by a sectional modeling, transversely to the plane of the display, the behavior of a system according to the invention applied to a plurality of

  superimposed display elements.

  FIGS. 27 to 31 illustrate the various steps of the behavior of a display management method according to the invention, applied to windows of an operating system, FIG. 32 illustrates a structure of links between added pages. by a user according to the present invention, Fig. 33 illustrates the combination of the Web and a personal web consisting of such added links, Fig. 34 schematically illustrates how to create the association between a page and its added links, FIG. 35 illustrates one way of displaying a page and the added links associated therewith, FIGS. 36a to 36c illustrate an example of a combination of added links, FIG. 37 illustrates various operations for creating links added between pages, FIGS. 38 and 39 illustrate the application of a display management mechanism according to the invention to a superposition of pages provided with their added links, FIG. it is a different display arrangement of the added links associated with pages, FIG. 41 illustrates the correspondence between the added link creation operations and the storage of such added links, FIG. 42 illustrates in a similar way to FIG. in the case where the added links also include reverse added links, Figure 43 schematically illustrates a storage mode of the links added; Figure 44 schematically illustrates a first mode of obtaining via a network a page and links added thereto; Figure 45 schematically illustrates a second method of obtaining a page network and associated links associated therewith, and FIGS. 46 to 51 illustrate six examples of manipulations of pages and links added to the page. pages contained in user directories, Figures 52 and 53 illustrate two modes of presentation of stored links or links added from rank 54 in relation to a current page FIG. 54 illustrates an exemplary user access interface as part of a page with associated links added, FIG. 55a illustrates an example of a user interface in FIG. which on one page are associated on the one hand links added, and secondly a selection of close directories, Figure 55b shows a display detail of a page and associated added links to change an attribute of an added link, FIG. 56 illustrates in a UML standard representation a class diagram for the added links and their aforementioned attribute, FIG. 57 schematically presents the principles of direct access to the added links and to the directories, FIGS. 59 schematically illustrate the fundamentals of the primary calculus of proximity between repertoires for a given current page, Figure 60 schematically illustrates the foundations of the calculation method transitive proximity between directories for a given current page FIGS. 61 to 63 schematically illustrate the foundations of three advanced modes of computation of proximity between directories, FIG. 64 illustrates two modes of graphical representation of an added link associated with a page, the FIG. 65 schematically illustrates the direct access to the directories, FIG. 66 illustrates a display detail of a directory and the links it contains making it possible to change an attribute of a link, FIG. 67 illustrates in a standard UML representation. a class diagram for the links and their attribute, Figure 68 schematically illustrates the placement of containers in a document, Figure 69 schematically illustrates the import of a content from one container to another, Figure 70 schematically illustrates the derivation of a container, FIG. 71 schematically illustrates the import of a content of a document to a container of a container. Another document, FIG. 72 schematically illustrates the principle of content composition, FIG. 73 schematically illustrates the principle of structuring references between elements, FIG. 74 schematically illustrates the indirect access to a page on the Web via Figure 75 schematically illustrates the process implemented by the system, Figure 76 schematically illustrates two containers, Figure 77 schematically illustrates the import process, Figure 78 schematically illustrates the process of importing the system. a content in a container of different category, Figure 79 schematically illustrates nested containers, Figures 80a and 80b schematically illustrate the derivation process, Figure 81 schematically illustrates an infinite branch structure, Figure 82 schematically illustrates a simple example of document structure, Figure 83 schematically illustrates the principle of storing the attributes of the contents, FIG. 84a illustrates an example of a user interface in which on a page are notably associated added links and links on contents in a container, FIG. 84b illustrates an example of an interface in which there are check boxes "Applicant" and "Offerer", FIG. 85 is a class diagram in UML representation of a hierarchical structure of Information Containers used according to a third aspect of the present invention, the Figure 86 is a class diagram including the notion of User Profile, Figure 87 is another illustration of the organization of Profiles, Containers and Contents, Figure 88 is a class diagram in which the notions of Reference are introduced. Content (link to content) and Content Popularity, Figure 89 is a class diagram that introduces the concepts of Direct Content and Content In 90 illustrates a basic advantage of a basic embodiment of the invention, FIG. 91 is a class diagram illustrating the notion of cascaded reference, FIG. 92 illustrates a principle of profile propagation, FIGS. FIGS. 93 and 94 illustrate the creation of links corresponding to the Profile propagation of FIG. 92, FIG. 95 illustrates another profile propagation principle, FIGS. 96 and 97 illustrate the creation of links corresponding to the propagation of Profiles. In FIG. 95, FIGS. 98 and 99 illustrate link creations caused by a referencing process, FIG. 100 is a class diagram incorporating the notions of Profile Propagation and Profile Referencing, FIGS. 101 to 104. illustrate four possible link transition configurations, Figures 105 through 107 illustrate link building for archiving and restoring elements, Figure 108 illustrates a collection principle of Profiles as a set of common files, Fig. 109 is a class diagram implementing the principle of Fig. 108, Fig. 110 illustrates a tree construction as a part of the principle. of FIG. 108, FIG. 111 is a class diagram showing all the principles of FIGS. 85 to 110, FIG. 112 illustrates a tree structure of binders according to the present invention, FIG. 13 is a class diagram incorporating this concept of workbooks, Fig. 114 illustrates the structure of a SQL database associated with the organization in workbooks, Fig. 115 illustrates a workbook table, Fig. 116 illustrates a table of user-specific items. in a workbook, Figure 117 illustrates a table of links, Figure 118 illustrates the creation of a <"Derived" element, Figure 119 illustrates the deletion of a sub-element not Derived, Figures 120a to 120c illustrate the deletion of a derived sub-element Derivative, Figure 121 illustrates a link table when restoring a sub-element, Figure 122 illustrates the behavior of sub-elements "implicit", 1 0 Figure 123 illustrates a corresponding link table, Figure 124 illustrates the acceptance of implicit sub-elements, Figure 125 illustrates a corresponding link table, Figure 126 illustrates the rejection of an implicit sub-file, Figure 127. illustrates the corresponding link table, FIG. 127a illustrates a possible example of a user interface, FIG. 128 illustrates proximity measurement between two profiles, FIG. 129 illustrates another possible proximity measurement, FIG. 130 illustrates the respective contents of FIG. two pages of user workbooks organized according to two common criteria, Figure 131 illustrates suggestions by Collaborative Recommendation, Figure 132 illustrates the two pages of binders of users after inserting an accepted element, FIG. 133 illustrates these two same workbook pages, with insertions of elements accepted in positions that meet other criteria, FIG. 134 illustrates a server architecture allowing, with the present invention, to implement anonymity and commission functions on

  e-commerce operations.

  FIG. 135 schematizes the sequential behavior of a plurality of objects, according to a fourth aspect of the present invention, FIG. 136 illustrates the standardized notation "UML>", FIG. 137 illustrates a simplified example of a class diagram, FIG. 138 illustrates the state-transition diagram for the aforementioned example, FIG. 139 represents a simplified object comprising a method, FIG. 140 illustrates by a simplified example an equivalence between attribute of a class and link between two classes. Figure 141 illustrates the equivalence between a transition action and an automatic outgoing transition intermediate state, Figure 142 illustrates the addition of a pseudo state to a standard transition state diagram, Figure 143 illustrates an example. a simplified example of an object with two types of actions, Figure 144 illustrates an enriched example of the simplified example in Figure 137, Figure 145 illustrates the behavior of an object in the figure 144, Figure 146 illustrates the principle of decomposition of the states of an object, Figure 147 gives an example of an object to which is applied the principle illustrated in Figure 146, Figure 148 illustrates the object after transformation according to this In principle, FIG. 149 illustrates the structure of a message sent by the object, FIG. 150 illustrates the basic behavior of a sequencer in response to such a message, FIG. 151 illustrates the notion of cycle used according to the invention. FIG. 152 illustrates the behavior of sequencer-controlled objects for certain types of cycles, FIG. 153 illustrates by a state-transition diagram the behavior of the sequencer with the control illustrated in FIG. Figure 155 illustrates the same enrichment in the case where an object has a certain type of action, Figure 156 illustrates a succession of messages stored by the sequencer, the fi Figure 157 illustrates the sequencer state-transition diagram with a history management function, Figure 158 illustrates additional operation by the sequencer of the messages of Figure 156, Figure 159 illustrates with a state-transition diagram. the behavior of the sequencer modified accordingly, FIG. 160 illustrates the complete state-transition diagram of the sequencer, FIG. 161 illustrates the initial state-transition diagrams of six objects in an exemplary implementation of the invention, FIG. 162 shows the new state-transition diagrams of objects according to the aspect of the invention illustrated so far; FIG. 163 illustrates the sequence diagram of certain events and actions in a certain phase for this same example, Fig. 164 illustrates an excerpt from the corresponding message list, Fig. 165 illustrates the sequence diagram in another phase, Fig. 166 illustrates a corresponding excerpt from the list. In Figs. 167 illustrates the sequence diagram in a third phase, Fig. 168 illustrates a corresponding extract of the message list, Fig. 169 illustrates the sequence diagram of another type of action managed by Sequencer, Figure 170 illustrates an example of objects and their links, Figure 171 illustrates a tree structure of objects and links, Figure 172 illustrates in more detail such a tree structure, Figure 173 illustrates a path. between objects used according to a fifth aspect of the invention, Fig. 174 illustrates a particular composition of links in a path, Fig. 175 illustrates the principle of grouping certain objects of a tree structure, Fig. 176 illustrates the application of such a grouping to viewing areas associated with objects, FIG. 177 illustrates links in relation to the proximity between viewing areas, FIG. groupings of objects according to the same principle, with increasing granularity, FIG. 179 illustrates two possibilities of link transformations, FIG. 180 illustrates by a simplified UML diagram two types of objects, namely object proper or collection element. FIGS. 181 and 182 illustrate a first phase of a connection method between objects, FIG. 183 illustrates in another form a grouping of objects, FIG. 184 illustrates a number of actions in a tree structure of objects. in connection with display objects grouped on an object constituting a viewing area, FIG. 185 illustrates the corresponding sequence diagram; FIGS. 186 to 189 illustrate an application of the fifth aspect of the invention to changing composition links; FIG. 190 illustrates a list of sequencer messages according to the fifth aspect of the invention in the context of FIGS. 186 to 189, FIG. To illustrate an object transition as part of a refinement of the fifth aspect of the invention, Figure 192 illustrates the principle of an anticipatory connection between objects, Figure 193 illustrates such an anticipatory connection in the form of a diagram. UML, Figure 194 illustrates the corresponding sequence diagram, Figures 195 and 196 illustrate two modes of anticipatory connection of objects, depending on the type of object, Figure 197 illustrates the basic architecture of a data server Figure 198 illustrates the manipulation of shared objects by two users of client computers, Figure 199 illustrates a principle of mixed replication according to a sixth aspect of the invention, Figure 200 illustrates the same principle, applied. In case the shared objects are managed by two servers, Figure 201 illustrates the state-transition diagrams for an example of four objects, three of which are of different types, Figure 2 02 illustrates the behavior of these four objects during a transition caused by the user on one of the objects, FIG. 203 illustrates the behavior associated with the level of two message lists, respectively on the side of a client station. and on the server side, Fig. 204 illustrates an object coding used in Fig. 205, Fig. 205 illustrates the propagation of a transition from a client station to a server and to others. Figure 206 illustrates the same principle of propagation in the case where there are two servers, Figure 207 is a diagram of the architecture of the communication means between the client stations and the server, Figure 208 is a sequence diagram of a connection procedure between the client and the server, FIG. 209 is a diagram similar to that of FIG. 207, illustrating the information flows during a method call, FIGS. 210 and 211 are Correct sequence diagrams Figure 212 is a sequence diagram illustrating the end of a connection, Figures 213 and 214 are sequence diagrams illustrating the allocation of locks to objects, Figures 215 and 216 are state diagrams. transition illustrating the lock behaviors on an object, Figs. 217 and 218 are sequence diagrams illustrating a read and write lock request from a client station to a server, Fig. 219 is another form of block diagram. a sequence illustrating a latency in the lock allocation process, FIG. 220 is a sequence diagram illustrating a lock request to read from a client station to a server, FIG. 221 is another form of diagram. sequence illustrating a latency in the lock allocation process, Figures 222 to 224 illustrate a mutual blocking situation when waiting for locks between objects, Figure 225 illustrates an example of e requests and allocation of locks on logical time axes of two client stations in association with such mutual blocking, Figure 226 illustrates two situations respectively corresponding to a mutual blocking and the absence of such blocking, Figure 227 illustrates the use of a counter to unblock mutual blocking situations, Figure 228 illustrates transitions propagations between five objects, to illustrate a backward function, Figure 229 illustrates the status of corresponding message lists side server and client side, Figure 230 illustrates further propagation of transitions in the same example, Figure 231 illustrates the corresponding state of the server-side message list, Figure 232 illustrates other propagation of transitions still in the same

example,

  Fig. 233 illustrates the corresponding state of the client-side message list, Fig. 234 is a state-and-message diagram illustrating a server-client conflict situation, Figs. 235-238 illustrate at the list level of the client-side message list. server-side messages

  3 0 steps to resolve the conflict.

Introduction of the description

  We will present in the following in six chapters, different systems and processes - related - aimed generally at improvements to computer tools related to Intemrnet and more generally to shared computing via network. Chapter I aims in particular at improvements to the management of the on-screen display of graphic elements such as pages of the Web, parts of pages or even windows of an operating system, in different circumstances such as

  as the loading of pages or drag-and-drop operations.

  Chapter II aims, in particular by using the display management of Chapter 1, to allow a user to create personal links between pages of the Web, and

  also aims at different techniques to take advantage of these created links.

  Chapter III aims, using in particular the linkage techniques created in Chapter II, different techniques of mutual enrichment of knowledge, particularly via

  the Internet. In this respect, he reiterates the concepts set out in Chapter II.

  Chapter IV concerns object-oriented applications and means to make deterministic the behavior of such applications when they

  are shared especially via the Internet.

  Chapter V aims, in line with the shared applications of Chapter IV, to propose execution techniques such as applications that are at least

  in part, low or limited bandwidth issues.

  Finally, chapter VI concerns, again in the context of object oriented applications 30 shared and in particular with chapters IV and V, techniques making it possible to facilitate the good shared execution of applications having

different types of objects.

  Chapter I - Management of superimposed display areas (FIGS. 1-27) With reference first of all to FIG. 1, there is shown schematically an interactive page P. such as a page in HTML language, which must be loaded on a slow and / or irregular network such as Intemrnet, which is large (some

  tens of kilobytes, or even more than one hundred kilobytes, or even more).

  This page is broken down into two display areas ZI and Z2 covering, typically, a window of a browser software on the Internet. In the example of Figure 1, a page element E2 is loaded in the zone ZI, while an element

  of page E5 is loaded in zone Z2.

  One of these zones (the ZI zone in this case) is defined as being able to "tolerate" the overlapping of the display of the page P by the display of elements

1 5 external.

  In other words, the zone decomposition makes it possible to distinguish a zone (Z1) in which the display of the current element (element E2) can be covered (entirely or partially) by the display of one or more elements. which do not belong to the interactive page P. Of course, the zones in question could be of any shape, and

  consist of parts (sub-areas) contiguous or not.

  According to the present invention, it is intended to make the user wait during the loading of the interactive page, the basic idea of presenting him beforehand with an additional element (element E1 in the diagrams that will follow) whose essential characteristic is to be light in terms of volume of data to

  transmit, for example by being a simple introductory text, that is to say

  3 0 very quickly loadable.

  Figure 2 illustrates the element El displayed in the zone ZI after being loaded.

  The display of this element El is carried out in the zone ZI in order to be able to cover later the display of certain elements of the interactive page (and more precisely the element E2) when these will be loaded. We will now describe a number of details of concrete implementation of the invention. Section 1- Stability of the display of the element El The cumulative loading time of the elements E2 and E5 intended to constitute the page P not being exactly predictable, and moreover the duration necessary for the complete examination by the user of the content of the element El - that is to say, the duration of reading of the text it contains being dependent on the capabilities and attention of the user, it is advantageous that the element El remains displayed until the user removes it on his own initiative. It is indeed unpleasant for the user to see each other

  Suddenly deprived of a text he is reading.

  The approach adopted, which will now be described in more detail with reference to FIG. 3, is as follows: as soon as the loading of the elements E2 and E5 initially necessary for the execution of the interactive page P is complete, all or part of the zone Z1 in which the element El is to be displayed serves as a "sensitive zone", so that when the pointer of a mouse (or any other input device of the machine 25 constituting a device pointing point) enters this zone ZI (and without a mouse click being necessary), the display of the element El is automatically replaced

by that of element E2.

  It will be observed here that one can equip the machine means (button, dialogue window or other) then allowing the user to declare if necessary that subsequently, he no longer wishes to see the El element displayed . This means can for example be

  a sub-element of interactivity in E2 or El.

  Section 2- Re-viewing the El Element

  Unless explicitly stated otherwise by the user as indicated above

  above, it is then expected that the user can retrieve the element E1 later on his own initiative and as easily as possible, for example in the case where he

would have removed it by mistake.

  However, after the replacement of the element E1 by the element E2, since the element E2 must offer the user all his own possibilities of interactivity (hyperlinks, etc.) in the display area Z1, he is advantageous that this zone ZI is not used to trigger the opposite operation, that is to say the replacement of the element

E2 by the element E l.

  To satisfy this constraint, and as illustrated in FIG. 4, at the moment when the element E2 is displayed, it is provided that all or part of the display zone Z2 in which element E5 is displayed becomes in turn < <sensitive area ", element E1

  can be re-displayed as soon as the pointer input is detected in this zone.

  However, as soon as the element El has been displayed again, the ES element 20 must have all its own possibilities for interactivity. It is then, as before, all or part of the zone Zl (then containing the element El) which

  becomes a sensitive area. This is illustrated in Figure 5.

  The behaviors of Figures 4 and 5 may, in the present embodiment, be chained to infinity, as long as the user has not called other pages. Of course, both E2 and E1 may also have interaction sub-elements, constituting other sensitive zones, for respectively bringing and

Remove the element El.

  We will now describe in detail different sequences of the process according to the invention. Case 1: The mouse pointer is initially in zone Z2 This is the case where, at the moment when the elements necessary for the initial execution of the interactive page P are finished to be loaded, the pointer of the mouse is in the

  Display area that does not contain the E1 element.

  The sequence of the process is as follows: the element E1 is loaded and displayed first, and remains displayed as long as the elements necessary for the initial execution of the interactive page P (namely the elements E2 and ES) are not not yet loaded; the element El remains displayed, even after loading the elements E2 and E5, as long as the pointer actuated by the mouse does not make an entry in the display zone Zi containing the element E1; 2 0 - it is only during such an entry that it is replaced by the elements E2 and E5 - in case the pointer is then brought into the display zone Z2 which contains

  not element E2, element E1 is displayed again (E2 can remain displayed or not).

  This sequence is shown in the diagram of FIG.

  Case 2. The mouse pointer is initially in the zone Z1 This is the case where, at the moment when the elements E2 and E5 necessary for the initial execution of the interactive page P have been loaded, the pointer of the mouse is in

  the ZI display area that contains the element El.

  In this case the element El remains displayed as long as the pointer has not left the zone Z1, and then entered again therein; it's only in the latter case

  that the element El is replaced by the elements E2 and ES on the display screen.

  This sequence is shown in the diagram of Figure 7.

  The so-called "streaming" approach Of course, in all cases, the elements E2 and E5 of the interactive page P can be transmitted in a "streaming" approach, a conventional approach in which elements of a page are displayed and executed. before the page is fully loaded. It is indeed not necessary to wait until all of these

  elements of the page are loaded to activate the "sensitive areas".

  We will present below a "streaming" approach for the element El, which in

  the present example consists of two sub-elements El. 1 and E 1.2.

  Rather than waiting for the end of the complete loading of the element El, the distinct parts E 1.1 and E 1.2 of the element E 1 (which can be for example mainly

  text) can be loaded and displayed successively, in the reading order.

  The principle of displaying the elements according to the movements of the pointer of the

  The mouse may remain identical, as shown in the diagram of Figure 8.

  Alternatively, the behavior of the different parts of the element E1 can be dissociated, according to the rules set out below and described with reference to FIGS. 9 to 12, on which each "window" aims to show on the one hand the new elements displayed in response to the movement action of the mouse pointer 30 presented in the immediately preceding window, if any, on the other hand a new movement action of the mouse whose effect is shown in the window

following, as appropriate.

  Rule 1 This is a simple reminder of the principle already stated in the paragraph "Case 2: The mouse pointer is initially in Z1": In the case where, at the moment of the end of the loading of the elements E2 and E5 of the interactive page P. the mouse pointer is in the ZI area, the pointer moves have no effect until the pointer is brought out of the area

  ZI (that is, introduced into the zone Z2) and then returned to the zone Z1.

This is illustrated in Figure 9.

  Rule 2 Moving the mouse pointer from Z2 to Z1 causes the display of only the sub-element affected by the corresponding sub-element of the interactive page to be replaced. In the example illustrated in FIG. 10, the entry of the pointer in the region assigned to the sub-element El.1 of the element El will provoke

  replaced by a sub-element E2.1 of element E2, while the other sub-element E2.1

  element E 1.2 of element El will remain intact.

  Rule 3 This rule addresses the reversibility of the behavior defined by rule 2: if the pointer then returns to the Z2 zone, even if it has passed through other regions in the meantime, but provided that the replacements caused between -time, the display of element E2.1 is replaced by that of element

  This is shown in Figure 10.

  The diagrams of FIGS. 11 and 12 show other examples of implementation of reversibility, as described below. Rule 4 The displacement of the mouse pointer from the region occupied by sub-element E2.1 to the occupied region by the sub-element El1.2 triggers the replacement of the display of the sub-element E 1.2 by that of the corresponding sub-element E2.2 of the

interactive page.

  Rule 5 This rule describes a form of rule 4 reversibility: if the pointer returns from the region of sub-element E2.2 to the region of sub-element E2.1, even passing through other regions between -time, but provided that the replacements caused in the meantime are automatically undone, the display of sub-element E2.2 is

  replaced by that of sub-element E 1.2. This is illustrated in Figure 1 1.

  The diagram of FIG. 12 presents an alternative embodiment of rule 5.

  Suppose that after the following path of the mouse pointer: Z2 - El. 1 (which becomes E2.1) --- El.2 (which becomes E2.2) the pointer of the mouse is brought from the region occupied by sub-element E2.2 to zone Z2. This, because it is not a return within the meaning of the Rule

  3, does not result in the replacement of sub-element E2.2 by sub-element E1.2.

  Rule 6 This rule consists of making the above operation reversible: if the pointer returns from zone Z2 to the region occupied by sub-element E2.2, even if it has passed through other zones in the meantime but provided that to have automatically defeated the replacements caused meanwhile and if the return is carried out before a given "time threshold", the operation is considered as being defeated. This is illustrated in FIG. 12. This embodiment advantageously makes it possible to no longer call the sub-elements constituting the initial element E1 when a period of

  The predetermined time elapsed during which the user remained on the sub-

  elements of element E2, which is indicative of, for example, a beginning of

the user on the element E2.

  Section 3 - Examples of applications of this chapter In the context of Internet or other applications, the method according to the invention can be

  supplemented for example by elements presented in the diagram of Figure 13.

  The information carried by the elements which are represented there are for example the following: Element El: text (and where appropriate image and / or sound, etc.) introductory or host, the essential being that are loading is relatively fast compared elements E2 and E5 (constituting for example the main page of the site); Element E3, initially occupying zone Z2: for example a message of the type "Please wait, the interactive page is being loaded" Element E4, replacing element E3 in zone Z2: for example a message of the type "The minimum loading of the interactive page is finished"; Element E2 the part of the main page occupying the zone Z1;

  Element E5 the part of the main page occupying zone Z2.

  Those skilled in the art will easily implement the invention in a machine for example of the personal computer type (standard "PC", "MacOS" (registered trademark), etc.), comprising a processor, memories, and inputs / outputs, a display screen and a link with a relocated server, this for example by programming appropriate routines in connection with the loading protocol 20 elements from the server, knowing in particular that - the definition of "sensitive areas> > for a mouse pointer or similar - the detection of the presence of the pointer in these areas, - the detection of the end of loading of different HTML pages or their individual elements (texts, images, sounds, etc.)

  2 5 are classic tools available to developers.

  Many variations can also be made to the present invention.

  First, it can be expected that the region in which the initial element El will be displayed is not superimposed exactly on the region in which the element E2 of the main page will be displayed. In particular, the region occupied by the element El may be smaller than the region (zone ZI) in which will be displayed, under the conditions defined above, the element E2. In this case, the part of the zone ZI not covered by the region occupied by the element El may for example remain blank as long as the element E2 is not displayed. In this case, it is advantageously the entry of the mouse pointer in the only region occupied by the element El that will cause the replacement of the element E1 by the element E2. The region occupied by element E1 may also be larger than the region (zone ZI)

  in which the E2 element will be displayed.

  According to another variant, it is possible for the display of the element El to be replaced in place of the element E2 by not bringing the mouse pointer into the zone Z2, but by any other means. action and in particular: - by bringing the pointer of the mouse (with if necessary the necessity of a click) into a button, tab, etc. displayed in the vicinity of the element E2 when the latter is displayed (or belonging to the element E2); - by pressing a specific key on the keyboard of the machine, - etc. It can also be expected that the different sub-elements of the initial element El

  20 are contiguous or non-contiguous.

  In addition, different element movement techniques can be used to remove E1 from the display area Z1 (or the region or regions it occupies in this area, if any) with a given visual effect for the area. 'user. In particular, it is possible to provide a progressive horizontal or vertical translation of the representation

  from element E1 to the outside of the screen.

  Also, it can be expected that the element El, after being initially displayed, is covered by certain sub-elements (buttons, etc.) belonging to the element E2

  3 0 being loaded (for example, a loading of E2 in "streaming").

  the element El is thus somehow "sandwiched" between certain sub-elements of the element E2 (those which will remain invisible until the element E1 is removed) and

  other sub-elements of element E2 which will behave as indicated below

  above. In this case, the disappearance of the element El when the pointer enters the associated zone, when it is done by translation towards the outside of the screen of the representation on the screen of said element, is advantageously carried out leaving

  still the sub-elements of the element E2 then visible on the screen.

  Finally, we can predict that the element E1 initially displayed contains sub-

  elements of interactivity (links to other pages, buttons triggering actions, etc.). In this case, it is advantageously provided that these subelements are active (that is to say actuable by mouse pointer in particular) at least during the period during which the element E2 is being loaded, and that these - items become inactive as soon as the pointer enters the zone

  of element E1 must cause the disappearance of this element. Indeed, the sub-

  elements of interactivity in question are no longer attainable.

  We will now describe with reference to FIGS. 14 to 24 a generalization of the

  The present invention as described above.

  We first place ourselves in the situation where we want to visualize two pages (by

  example HTML pages) in a single display window.

  To clarify this aspect of the invention, it will be considered that these two pages are in two different planes, the page Pl1 of the upper plane partly covering the P2 page of the lower plane, being fully visible in the viewing window. (whose size is here slightly greater than that of page P2),

as shown in Figure 14.

  The page PI of the upper plane can also occupy a staggered position; it still partially overlaps the page P2, but is visible only partially,

  marginally, as shown in Figure 15.

  In this embodiment, there is further provided a virtual "clamp" which can fix the two pages together, as will be detailed later, and in one or other of their two mutual positions. This clip is schematized by PC on

Figures 16 and 17.

  In plan view, the user can thus distinguish four zones ZI 1, Z12, Z13 and Z14

* in its display window, as shown in Figure 18.

  Zone Z I 1 is an area that is never covered by the page PI of the upper plane. Zone ZI 1 therefore permanently contains the corresponding part of the

page P2 of

lower plane.

  Zone Z12 is the area covered by the page Pl of the upper plane when this one

  is not shifted, that is, when it occupies the position illustrated in Figure 14.

  And when the page P1 of the upper plane is shifted (situation of FIG. 15), the zone Z12 presents the corresponding part of the page P2 of the lower plane, this page

  then occupying the sum of zones Z 11 and Z 12.

  Zone Z13 is the area occupied by the clip, which can be symbolized

  graphically anyway appropriate.

  Finally zone Z14 is an area that is covered by page P1 of the upper plane

  whatever the position of the latter.

  We will now present the different possible states of the system and the possible transitions between these states, the latter being the consequence of the actions of the user. The states are defined by: * the position of the page of the upper plane (that is to say, shifted or not shifted) * the possible positions of a mouse pointer with respect to the different zones,

  * the state of the PC clamp (open or closed).

  Figure 19 shows the two possible positions of page P1 of the upper plane.

  FIG. 20 shows an exemplary state of the system, for which a set of sensitive regions responsive to the arrival therein of the pointer of the

  mouse, the position of the top plane page and the state of the clip.

  In the example of FIG. 20, the shaded regions (here the zones Z12 and Z13) designate places where the presence of the pointer has no effect on the system, while the white regions (here the zones Z11 and Z14) designate regions for which the entry of the pointer in one of these causes an action, such as

we will detail it later.

  The behavior of the system is presented in Figure 21 in the form of a state-transition diagram, which illustrates the different manipulations of the pages Pl

and P2 in their respective planes.

  The system ensures that the top-plane page P1 is not replaced by the P2 page of the lower plan (once it has been loaded from a server, if any) only on the default action of the user, and this in a very intuitive way. Unlike "streaming" processes, the user will not be surprised to see the page being replaced.

examine.

  Thus, when the page of the lower plane is if necessary loaded: - if the pointer of the mouse is in zone ZI 1, bringing it in the zone Z12 - if the pointer is in one of the zones Z12, Z13 and Z14, bringing it into zone Zl 1 and then again into zone Z12

  will result in shifting the page P l of the upper plane.

  Then, the user can cause the reverse movement of the page P1 of the upper plane (that is to say bring it back into the zone Z 12): either by bringing the pointer of the mouse in the zone Z 1,

  - or by dragging the mouse pointer in zone Z14.

  This double choice offered to the user has an important advantage: the first choice makes it possible to use the means of interactivity (buttons, etc.) contained in the page P2 of the lower plane in the zone Z1 1, - the second choice allows to use the means of interactivity contained in the

  page P I of the upper plane in zone Z 12.

  The fact of "tightening" the PC clamp (for example by a simple mouse click in the dedicated area Z13) has the effect of avoiding shifting the top plane page as a result of the manipulations indicated above. other words, the process of shifting and returning the page Pi is then neutralized, and the mutual positions of the pages Pi

  and P2 (whether with the P I page shifted or the P I page not shifted) are frozen.

  This neutralization can be advantageously suppressed by clicking again in

  zone Z13 to "loosen" the PC clamp.

  It will be noted that the different states and the different transitions illustrated in FIG. 21 can be supplemented if necessary by other states and other transitions, especially when there exists in the window, outside zones Z11 to Z14. , a margin zone that can be used, for example, to go from the zone Z 1 to one of the zones Z13 or Z14, or vice versa, without passing through the zone Z12 which separates them. The system described above with reference to Figs. 14 to 22 may be extended to handle more than two overlapped planes. Thus, FIGS. 23 to 26 show a page P2 of lower plane which is fixed, and two pages P1 and P1 'of respectively higher and intermediate levels, which can individually adopt a non-shifted (fully visible) or offset position. . The PC clamp is here common to all three pages, and can occupy a zone

unique graphic.

  In addition to the clip, a graphic means of "joining" adjacent planes taken in pairs can be implemented. When this means is activated,

  two planes that it connects move together.

  The system described with reference to FIGS. 14 to 26 can here again advantageously be implemented in the context of applications on the Intemrnet, in which the pages put a significant time to be loaded. The Pl1 page of the upper plane can be loaded first and wait for the user while the P2 page of the lower plane is loaded. Likewise, the display of pages P1 and / or P2 can make it possible for the user to wait while loading another page P3,

  even more "inferior" according to the presentation adopted here, and so on.

  Finally, in the various embodiments of the invention, it is possible to provide a page P 1 that is substantially smaller than the page P2, in which case the display areas

  occupied by the page P1 in its two respective positions are disjointed.

  A method for managing the display of windows of an operating system, in particular during drag-and-drop operations, will now be described with reference to FIGS. Fig. 27 illustrates a first window F1 that partially overlaps a second window F2 (it does not matter here whether the window "on top" is active or not). FIG. 28 shows a mouse pointer (or cursor) PT that is on an object 01 (such as a folder or document) visible in the window F1. User support of a button the mouse makes it possible, in a manner known per se, to "grasp" this

  object for an operation, also known per se, of "drag and drop".

  In FIG. 29, the pointer P1 accompanied by the object 01 travels a path (arrow fl) from the window F1 towards the visible part of the window F2, thus crossing the

  edge (left in this case) of the F1 window, without letting go of the mouse button.

  In FIG. 30, the movement of the pointer PT accompanied by the object 01 again reaches, by an inverse movement (arrow f2), the edge of the window F1 previously crossed. This phenomenon causes, in the present example of

  realization, putting the window F1 in the background with respect to the window F2.

  2 0 The entire window F2 becomes visible, and the user can freely choose which of the objects visible in the entire window F2, that objects (object designated by 02) on which it will drop the object 01. This is illustrated by the

figure 31.

  According to a variant, it can be provided that during the movement of the pointer according to the arrow f2, the window F1 moves, preferably in the same movement as the

  pointer PT, thus gradually clear the window F2.

  Other variants are of course possible, and in particular: the system sends a signal to the user when the pointer reaches the edge of the first window; this signaling may be chosen from the group comprising visual signaling, sound signaling and tactile signaling such as force feedback within a manual input device which controls said pointer; the window F1 can automatically go into the background of the window F2 as soon as the pointer PT equipped with the object O1 has remained in the zone of the second window not covered by the first window for a duration greater than a predetermined threshold; the window F1 can automatically switch to the background of the window F2 when a key of a keyboard of the computer station is actuated, or else by voice command; the setting in the background or the displacement of the window F1 to clear the window F2 can be reversible, for example by performing a reverse movement of the

  pointer after its movement according to the arrow f2.

  Of course, those skilled in the art will be able to make the necessary adaptations in the

  where it is necessary to manage the display of several superimposed windows.

  Chapter II - Creation of links (FIGS. 32 to 84) According to another aspect of the invention, a system will now be described allowing the user to create hypertext links (which will be called in the following "links").

  added ") between pages he discovers as he browses the Internet.

  One purpose of this system is that each user adds his own links to the mass of information available on the Internet. Figure 32 illustrates this concept, with each black dot representing a page and each line separating two black dots

representing an added link.

  In concrete terms, the user sets up new links in the course of his

  navigation, these added links being intended to help him in his navigation in the future.

  He sails in a "pro-active" way.

  In other words, for each user, the set of added links, which can be considered as his personal thumbnail (Miniweb), is added to the web

  Internet (Web) to which he already had access, as shown in Figure 33.

  For this purpose, the system is installed between the browser and the sites visited, and increases

  for each user the network of links that are available to navigate.

  To do this, the system is provided with storage means for added links. These means allow, each access (link) to a page to which one or more added links have been associated, to present them to the user in addition to said page. On a practical level, and as illustrated in Figure 34, an indirection is established to a link-added links table, in order to associate these added links to this page before present it to the user. Storage of added links can be local (on the client machine) or remote (on a

  appropriate server). In the rest of the description, we will focus on a storage

  remote. Indeed, in some of the improvements that will be presented later, the links forming the personal miniature canvases of different users will automatically be compared with each other and added links may be communicated from one personal canvas to another, which a remote storage makes it easier

to implement.

  Each personal web can thus be enriched with added links from other personal webs, and automatically proposed by the system which, for example, furthermore has means for detecting that their respective users share the same centers of interest. Moreover, each user can form a circle of relations (of friends) proposed by the system following the detection of centers

common interests.

  The rest of the description is structured as follows:

  We will first present the system that allows a user to create added links and find them later (when accessing the pages they have

  been associated). This is described in the "Create and Find Added Links" section.

  A further refinement of the system is to combine added links with an approach of storing these links in a hierarchical structure of directories and sub-directories (ie in integration with the traditional approach of memory systems of "favorite links", "bookmarks",

  or "bookmarks" or "scrapbook" according to English terminology).

  This will be described in the section "Creating links added in Directories".

  We will then present an improvement of the traditional system of brandpages,

  which consists of making the bookmarks contextual.

  Next, a system enhancement will be introduced allowing users to publish (or make available to a small group) at least a subset of the added links to their personal web. These added links can be viewed directly using a standard Internet browser. Alternatively, these added links can be consulted with the system and enrich the personal web of the user who consults them. This is described in the section "Publishing links

added ".

  An enhancement will then be presented which allows the system to automatically suggest to users added links from other users whose interests are close. This is described in the section "Detecting

Close Directories ".

  An architecture will then be presented that allows the editor or administrator of an Internet site ("Webmaster" in English terminology) to propose links added to users of the system in a personalized way. This is described in the section "Suggestion of links added by the Webmaster". Finally, a system will be presented to simulate the propagation of a new added link among the users of the system on the Internet and calculate the volume of

  the likely audience. This is described in the "Audience Calculation" section.

  We will then present an improvement of the system allowing the user to publish (or make available to a small group) at least a subset of the directories of his personal web. These directories can be viewed directly using a standard browser. Alternatively, these directories can be consulted with the system and enrich the personal web of the user

  who consults them. This is described in the "Publishing Directories" section.

  We will then present an improvement of the system allowing the user to store (locally or on a server) not only a link but also a fixed copy

  one page. This is described in the section "Links in Frozen Mode".

  An improvement will then be described which, in the context of the system presented so far, makes it possible to publish pages which have been restructured to present links directly within themselves, the user being able to delete these links or to add links to them. others. To do this, the pages contain one or more containers in which are presented contents that may themselves contain other

  containers recursively. This is described in the "Containers and Contents" section.

  By integrating the concepts presented so far (added links associated with pages and links in containers included in pages) and illustrating them by means of an example, we will summarize the functionalities of the overall system and will be supplemented by some improvements. This is described in the section

  "Proposal of Directories Specialists and Neighbors".

  We will then present an improvement of the system allowing the user to associate with the links which interested him attributes, such as the wish to buy or sell the product represented by the pointed information (or more generally the attributes of type "Offerer" and "Applicant"). These attributes are exploited by the system to refine the selection of specialist and close directories, and the linking of users interested in the same content and in a situation of complementarity. This is described in the "Attributes related to

acceptance ".

  We will then present a refinement that allows the restructured pages to present content in a "personalized" way, that is to say according to the interests of the user. This is described in the "Pages" section

Customized ".

  Next, a set of system enhancements will be described, allowing a user to load a page progressively, and to remote users to share the content of pages that they simultaneously manipulate as part of the system.

  collaborative applications on a network such as the Internet.

  Section 1 - Creating and Retrieving Added Links Figure 35 illustrates the principle that, as a result of user access to a page through the Internet, the system automatically presents it with a number of links added, the occurrence in the form of graphic symbols, to pages p2, p3 and p4 that he had associated with the page pl during previous navigations. Motivation The added links are created by the user in order to establish relationships between pages that interest him. The added links represent relevant relationships between these pages; a page linked to another page is interesting in the context of said other page (and optionally, in the opposite direction as well). For the user, the set of links added thus constitutes a network of additional relationships between pages that interest him in relation to each other, as illustrated in FIGS. 36a, 36b and 36c which illustrate for FIGS. 36a and 36b. , two networks of links between a number of pages, and for Figure 36c, the network

"agglomerated" said links.

  From a selected page or set of pages, the system allows the user to navigate to pages that are linked to it. The network of links added thus constitutes for the user a personal navigation network according to his own "mental scheme" and allows him to find the elements more easily.

  information he had already identified.

  Create added links The sliding plan approach described in the first part of this

  description is particularly favorable to the establishment of links added by the

  technical, classic in itself, "drag and drop". The user can select a page or an element (or graphic area that represents it) that is in a plan, drag it and drop it in another page (or graphic area that represents it) that

  is in another plane, to establish an added link between these two pages.

  This approach is to be compared with the approach of dragging pages between different windows of the browser tool, which partially overlap and thus prevent viewing the pages entirely. The advantage of the sliding plane approach is to allow, during the process of drag-and-drop (that is to say without releasing the finger on the mouse button), to visualize the contents of the plans ( the pages and their links added) in turn, by simple movement of the mouse, as described above with reference

particularly in Figure 26.

  It is also understood that, according to one variant, this technique of "sliding

  drop >> with revealing the background display areas on which the cursor is moving during the operation can be generalized in case these display areas are windows of a conventional operating system such as "Windows" or "<MacOS" (registered trademarks). Specifically, it is expected in this case that a window in the background passes in the foreground when the cursor

  "push" the window that was in the foreground when coming against one of its edges.

  Figure 37 shows an example of creating links added between pages, drawing links between the graphical objects representing them (to the left of the pages), the

  clamp described above being active and blocking the movement of the planes.

  The bottom of Figure 37 illustrates the particular case of creating links added (drag and drop graphic objects) between different instances of the system, simultaneously opened by the user on the client machine. The mouse movements that make it possible to draw added links between the pages P6 and P7 illustrate the technique described previously which consists of bringing the mouse pointer outside the window containing the page P6 and then returning it towards this point. even

  window in order to make it pass in the background of the window of the page P7.

  Of course, each plan can be deleted or <"minimized" (so that its visible part takes up the least possible space) by means of click on a

  button (this is not shown in the figures).

  Although Fig. 37 does not show it, graphical objects within the pages may also be dragged or dropped between them or to graphical areas or objects representing the pages. In some cases, as will be seen below, the graphic objects located outside the pages, and representing contents of

  pages, can also be dragged-dropped inside pages.

  Figure 38 shows the arrangement of sliding planes when the upper plane is shifted to the right. Figure 39 shows the arrangement of sliding planes when all planes, except the lowest plane, are offset. As already described, the transition (from one of the arrangements of sliding planes to another) is done incrementally, by means of simple movements of the mouse, the clamp described more

top being unlocked.

  It should be noted here that, to simplify the manipulations, the state of the clamp can be reversed for example by pressing on the spacebar or another key of the keyboard

from the client station.

  According to a variant, not shown, the clamp can be moved on a "rail" and it blocks only the plans to the left. In other words, depending on the position of the clamp, the planes that are not visible to the left of the clamp are blocked and those that

  are on his right can be shifted.

  According to another variant, tongs can be selectively activated and deactivated between two adjacent pages, so that these two pages are always treated in the same way in the context of the plane displacement process. It will also be noted here that it is the fact that the clamp is in the active state that makes it possible to draw links added between the pages (by dragging and dropping graphic objects the

  representative), without moving the plans as described.

  According to another embodiment, the graphic areas that represent pages can be on other planes than those that present the pages. Figure 40 shows a configuration where the links added to each page are on one or

  several planes adjacent to said page.

  The added links can also advantageously be seen as thumbnails like butterflies "glued" on the pages and movable by the user as desired

using the mouse.

  According to an advantageous variant, these thumbnails can be arranged in blank areas of the page that could have been used for example to display

advertising banners.

  Links added by the user by drag-and-drop (or if necessary manually using the keyboard or by mouse clicks), are stored in the system by

  example as a TABLE table, as shown in Figure 41.

  In the following, we adopt the (optional) hypothesis according to which the links added on a page entail the creation of inverse links on the pages pointed by these added links (bidirectionality of the links). Thus, as illustrated in FIG. 42, as a consequence of the creation of the added links of p2, p3 and p4 on the page p1, a link

  added pl is added automatically on pages p2, p3 and p4.

  The creation of added links is done when the user sees a relationship between different pages that he discovers as he navigates by following hypertext links or moving inside large pages or virtual worlds in three dimensions (in immersive virtual reality). In any case, the creation of an added link can be done by simply dragging and dropping the "handle" or other miniaturization of the page or the currently viewed scene (for example from the

  3D scene commonly viewed) to the handle of the page to be linked (other 3D scene).

  The storage means of the added links are advantageously implemented remotely (on a server), as shown in FIG. 43. The user adds and / or deletes links added on the client station and these manipulations are reflected on the server, the communications being done for example by

  through an Internet Service Provider.

  Section 2 - Finding the added links The display of the page with its added links can be prepared on the client computer, in an architecture schematized by the diagram of figure 44, or on the server, in an architecture schematized by the diagram of Figure 45. It will be noted that the two architectures are adapted to an operation according to the

HTTP protocol for example.

  In the case of the architecture of FIG. 44, the request or link "Link" of the user is communicated by the client station, both to the server of the requested page and to the server where the added links have been stored. In return, before presentation to the user, the added links provided by the second server are graphically combined, by the client station, with the page provided by the first server, and are

  jointly presented on this page.

  In the case of the architecture of FIG. 45, the request or link of the user is communicated by the client station, only to the server where the added links have been stored. This server is responsible for retransmitting the request to the server of the requested page to receive this page. In return, the added links are added to the page and all is the answer to the user's request. The graphic combination

  Links added to the page can be made on the server or on the client computer.

  Section 3 - Creation of links added in Directories Already known in the state of the art concept called "bookmark" or "bookmark" that allows an individual to store links to his favorite pages on the Web, such a concept being present in the current Internet browsers. These store stored links in directories that can

  form a tree structure of directories and subdirectories.

  The establishment of a personal web (personal navigation network that is added to the Web) by creating (by drag-and-drop or manually) links added directly to pages as described in the previous section, is complementary to these classic ways of storing links in directories

  (usually constituting personal categories of the user).

  Indeed: - the user can put in a directory not only a link (to a page),

  but also an added link (between two pages).

  the added links can thus be contextual: an added link associated with a first page (or more exactly, associated with a link to a first page) and pointing to a second page can exist within the framework of a given directory which contains a link to this first page without existing in another directory that

  yet also contains the link to the said first page.

  For example, in the directory "my favorite drinks" on the page "coca" (registered trademark) can be found a link added to the page "pepsi" (registered trademark) while in the directory "my favorite management styles" on the

  same page "coca" may not be added link to the page "pepsi".

  (See the example at the end of this section and Figure 51).

  (All trademarks mentioned herein are registered trademarks of

  their respective owners, in particular "coca", "pepsi", "perrier" and "hp").

  In the design choices adopted throughout the rest of the description:

  - each added link belongs to a directory and only one: a "current directory" still exists, and it is in this directory that links to pages and their added links are inserted by default; if no directory is selected by the user to be the current directory, a first current directory is provided by default when he accesses a page and associates a first link added. creating an added link in a given directory creates the added reverse link in the same directory (if it does not already exist). This rule imposes the existence, in the same directory, of the link to the page pointed by the added link; in the case where it does not exist, it is automatically inserted there; this is illustrated by

the example in Figure 46).

  - the user can select several directories as "current directories"; the added links displayed for a current page are then constituted by the union of the added links located in these directories; a new added link inserted is in each of these directories; finally we will see in the section "Detection of close directories" that the search for close directories will also be done

  based on the union of added links located in these directories.

  The user can perform the following actions: - insert or delete, in a directory, a link to a page: * to insert a page, one of the possible methods is as follows: the user chooses a current directory (or more, see the explanation of the previous paragraph), or remains in the default directory (which is considered as current directory), and accesses a page whose link will be automatically

  stored in this directory (s) current (s).

  * to delete a page, the user selects the page in question and

  activate the delete command (for example by pressing the "Delete" key on the keyboard).

  - create an added link: * either he manually creates a link added to a page (typically by typing his URL on the keyboard), * or he uses the technique of drag and drop: from a first page,

  it pulls in a second page an added link that will point to the first page.

  - move or copy one or more pages from one directory to another: * either, manually, he chooses the pages to move or copy, or he uses the technique of drag and drop; in fact, the user moves or copies

  links to pages, even if he thinks he is moving the pages themselves.

  In the following description, to simplify the reading and describe what the user

  "believe to do", we will sometimes use the word "page" instead of "link to a page". So we say "move a page" (or "copy a page") instead of "move a link to a page" ("copy a link to a page >>). "a page has an added link" instead of saying "a link to a page is associated with an added link >>, or" link added on a page "instead of" added link associated with a link to a page In addition, "link to a page" is a

  shortcut for "link to a page or element contained in a page".

  Let's take an example: The user has created two directories, labeled respectively "Drinks" (for "my favorite drinks") and "Mgt" (for "management styles"). default, labeled "Buffer" (for "buffer") that is created

automatically by the system.

  According to the traditional approach of memorizing bookmarks, the user inserts the link www.coca.com ("coca") in the Drinks directory and also inserts the link

  www.hp.com ("hp") in the Mgt directory.

  As part of the current directory which in this case is Buffer (default), the user accesses via the Web at www.pepsi.com ("pepsi"). From coca (which is in Drinks) he pulls (drag and drop) a link added to the page

pepsi (see Figure 46).

  This link added on the Pepsi page will be www.coca.com. Since, to satisfy the design hypothesis mentioned above, an inverse added link must be created in the same directory, the COCA page must be introduced with an added link www.pepsi.com. As a result, the pepsi and coca pages are both in Buffer, each having an added link on the other. Indeed, the link on the coca page had to be duplicated in Buffer to allow the creation of the added inverse link (from coca to pepsi). The

Figure 46 illustrates this example.

  The man-machine interface allowing these operations can for example be the one

  schematized in Figures 46 to 51.

  The user can drag and drop, copy or move a page to another directory. The user can also copy or move a set of pages from one directory to another. Several cases of control to the system are possible: 1. either this entails the displacement or the copy of the links towards these pages, without their added links. (See Figure 47); 2. Or this entails moving or copying links to these pages, with all the added links existing between them; moving is only possible for pages that have no links added to pages outside the moved set (the other pages in the set are copied); see Figure 47; 3. either this involves moving or copying links to these pages, with all links added between them or with other pages in the same directory; see Figure 48; Continuing the same example, the user moves the coca page from the Buffer directory to the Drinks directory; if one is in the first or second case of control to the system, the coca page already in Drinks, this operation

  has no effect. This is illustrated in Figure 47.

  In another case, the user would like to store in the Drinks directory all the links added to the COCA page. If we are in the third system control case, as a result of the drag and drop of coke (which is in Buffer) to the Drinks directory, the pepsi page is also in Drinks and the link added between pepsi and Coca is reproduced in Drinks. The user could then delete from the Buffer directory the pages pepsi and coca (with all links

  added together); these two operations are illustrated in Figure 48.

  Note that pepsi (or coca) could not have been deleted if a third page "perrier" (registered trademark) was in the same directory Buffer and had a link added on pepsi or coca), unless this third page "perrier" was not

  deleted in the same action. This is illustrated in Figure 49.

  If in the second case of control to the system, the user can directly move all the pepsi and coca links to the Drinks directory, as well as the links added between them. No external page to the deleted set having a link added to coca, this page is then deleted automatically. this is

shown in Figure 50.

  Let's continue the example: the user, who thinks that the management styles of the companies coca and hp (trademarks) deserve to be related, pulls by drag and drop an added link on the page hp from the page Coca. This is illustrated

in figure 51.

  The creation of the added link from hp to coca results in the creation of the added reverse link from coca to hp, the two links added being in the Mgt directory (where is the destination of the drag and drop). Although the operation performed does not explicitly consist of a page move or copy, it involves copying the COCA page into the Mgt directory (since both ends of any link added

  must be in the same directory).

  Section 4 - Contextual Bookmarks Remember that the classic system of bookmarks (already mentioned at the beginning of the previous section) allows the user to put in a directory a link on (or

  a copy of) the current page viewed, in case he wants to memorize said link.

  In addition, modern browsers offer the option of displaying, in a sub-window 20 adjacent to that containing the viewed page, the tree structure of directories.

  bookmarks and bookmarks (links or copies stored) that they contain.

  This option for displaying the stored links, simultaneously with the page accessed by the user, can be improved by making the display of the stored link directories and the stored links (or copies) contextual. In fact, rather than presenting the structure of the directories and the links they contain, independently of the user's navigation, the system can directly: - point to the directories already containing the link on the current page viewed,

  And present their respective contents.

  Thus, the user does not have to fetch, in his directories, the links (on the pages that had interested him) memorized that happen to be in the context of the

  current page, since it automatically has them available.

  In a practical implementation, the system presents these directories (containing the current page) in the area showing the added links associated with the current page by giving them a different appearance (the icon representing a directory or a page of a directory that is not associated with an added link to the current page is different from the icon representing an associated page by added link). This is shown schematically in FIG. 52 which illustrates the display of the directories in which the current page is stored, automatically, simultaneously with the display of the current page. The user can, by a simple click of a button (for example on the bar with a triangle in Figure 52), view the contents of these directories

  and thus find the other pages he had put together in these directories.

  According to an implementation detail, in the case where the page in question is stored in only one directory, the other pages of said directory (if they are not too many) can be displayed directly, without even requiring a click , for

  thus offer contextual access to the stored links in an even more direct way.

  The user can click directly on the graphical presentation representing a directory, for example an icon representing a folder (r2 in FIG.

  open a new page with the directory r2 with all its contents (the sub-

  directories and the pages it contains).

  Of course, the presentation of Figure 52 can be replaced by a classic tree presentation like the one found in

existing bookmarks.

  A similar function is for displaying Added links associated with a current page. It's about being able to navigate through "added" second links

rank ".

  Figure 53 illustrates an example of implementation of this approach. By clicking on a particular graphic zone of an added p3 link associated with the page p 1, the user can also see the added links (p31, p32 and p33) which are associated with the page p3

  while it is the page pl that is currently viewed (and not page p3).

  Of course, this approach can be generalized (recursively) for

  displaying links displayed with ranks greater than 2.

  It will further be observed that each of the graphic presentations representing a stored link or an added link (for example a thumbnail representing the page in miniaturized form) may be incidentally provided with a sign which indicates that the pointed page has been updated, the where appropriate, since the last visit of

  the user. This constitutes an invitation to consult the said page again.

  In addition, this same sign may appear on the graphic representation of each

  directory where at least one of the pages has been updated.

  Section 5 - Publishing Added Links An enhancement to the system is to publish the added links that have been associated with a page. Publishing means making them available to the public or to a specific group of users (who can access them through

  example by giving a password).

  The system allows two cases of access to published added links - published added links can be viewed directly via a standard Internet browser, - or the added links published can be accessed through the system client interface and enrich the personal canvas of the user who consults them. Direct visualization using a standard browser In the case of direct visualization using a standard browser, a first user views by standard means a page published by a second user on the Web, said page having links added associated with another page. This visualization can be the result of an access or a reception: the first user can access via the Web to a page presenting the added links published by the second user, in a conventional manner, using his standard Internet browser and communicating the URL of the page, - the first user can receive a page presenting the links added, published by

  the second user, typically by email.

  The page to which it was accessed via the Web or received by e-mail includes fields allowing the first user to identify himself in case he would like to consult the links added using the system. It is therefore an "invitation" to use the system, the main advantages of which are: - to allow to memorize the links added in his personal space on a server and to find them automatically, and - to receive automatically suggestions for new links added from third parties.

  A schematic example of this "invitation" is shown in Figure 54.

  System Lookup In the case of a lookup through the system, when a first user accesses, for a given page, links added to a second user, these added links are added to those that, if any , had already been associated with this

  same page at the first user.

  We will now describe how a second user is selected by

  the first user to find added links.

  For each page accessed by the first user, three lists of directories belonging to second users are proposed to him, as shown in Figure 55a. The user can select (for example by clicking a checkbox) one or more items from these lists to indicate that he wants to add their added links to his own list of added links. The three lists are described below: 1. the content of the first list is optional: this content exists in the case where the author of the page in question is himself a user of the system and wanted to suggest added links the first user; this is described in detail later in the "Suggestion of links added by the site administrator" section; 2. the second list ("neighbors of interest") is intended to present to the first user the directories most likely to contain interesting links added to his or her interest profile, the list of these directories is automatically determined by the system by comparing the users' personal canvas, this is described later in the section "Detecting Directories".

Close >>).

  3. the third list ("buddies") contains directories chosen by the first user (for example, directories belonging to the personal webs of friends,

* colleagues, experts, etc.).

  According to one variant, can be added to the three lists above a fourth list of

  directories belonging to the first user.

  In the first case presented above (direct visualization by means of a standard browser), the pseudonym of the second user who is the sender of the added links received by the first user - or of the directory containing these added links (note here that 'it can also be another directory of the first user) - is automatically put in first position in the third list

  ("buddies") in active (ie, selected) mode by default.

  The third list can advantageously be based on: - a "default list" given globally by the user for all the pages, and "overloaded" by the preferences provided by the user expressly for the

page in question.

  In the set of added links associated with the page that it is viewing, the user receives additional added links drawn from the selected directories in these three lists. We can consider that the user "visit"

these directories.

  Means for selecting added links, based on criteria given by the user or associated with the current page, can be advantageously implemented. For example, the user can specify that he wants to draw from the checked directories only links added on labeled pages: - "Applicant" rather than "Offerer", in order to discover new customers rather than new ones. sellers, - according to criteria concerning the intended audience: "Age", "Geographical Area">, "Sex", "Preference" (among a finite set of preferences), - etc. The added links which are thus to him The suggested links must be distinguished from those that he himself has added, so that he can selectively accept and reject them.Therefore, the added links can be in one of several different modes: << Suggested >>, << Accepted >>, "Refused >> and" Frozen "(this last mode

  being described later in the section "Frozen Mode Links").

  Chapter III will give a more complete description of the implementation of

technical work of these modes.

  The added links received by a first user, from the added links published by a second user (or from links added from another directory of the first user

  user), are initially at the first user in "Suggested" mode.

  Following a user action, each link added in Suggested mode can switch to one of the other modes. The man-machine interface allowing this is

2 0 diagrammatically in Figure 55b.

  For this purpose, the storage means associates with the added links a "Mode" attribute which can take as value the modes already mentioned with the exception of Suggested (that is to say, one of three values: Accepted, Refused, Frozen). Figure 56 shows a class diagram for the added links, based on the UML (Unified Modeling Language) standard representation highlighting the Mode attribute

added links.

  A link added in Suggested mode to a first user only exists during the "visit" of the links added (for the page in question) to a second user (or to another directory of the first user). It is not displayed outside this tour. Remember that this visit is done as soon as and as long as one or more directory (s) is (are) selected (s) in one of the lists (Specialists, Neighbors, Buddies). A link added in Suggested mode is not stored in the personal storage of the first user because, at each new visit, it is recreated from the corresponding added link stored in the second user, or in the other directory

of the first user.

  The passage of an added link from the Suggested mode to the Denied mode has the effect of automatically filtering said added link during subsequent accesses to all the added links stored in the second user's memory space, or in another

  directory of the first user, for the same page.

  Switching to Accept mode means that the user validates the added link that is in the Suggested mode. This action has the effect of: 1. storing said added link in its personal storage space, so that it is presented again with each new presentation of the page to which said added link is associated; this presentation takes place even if the added link has been deleted at the source (at the second user, or in the other directory of the first user) - this as opposed to the links added in Suggested mode that are no longer presented from the moment o they are deleted at the second user; in addition, this presentation takes place even if the source (ie the second user or other directory of the first user) is no longer

  selected (was unchecked).

  2. if the directory in which the said added link is stored, is published, to publish ex officio (unless the user otherwise instructs) said added link - this by

  opposition to links added in Suggested mode that will not be published.

  Inserting (manual or drag-and-drop) a link added to a page

  automatically put in Accept mode (since the user has inserted it himself).

  Section 6 - Near Directory Detection Overview The system detects for the user the existence of other users who share its interests (and tastes) in relation to a "" current page>> that it is currently

  visualize and therefore represents the current context of its interests.

  Thus, compared to a current page viewed by a first user, the system selects the second most "close" users, that is to say having, in their network of added links published, on the one hand said page, and on the other hand, around that page, the largest set of links added together with the

first user.

  For each of the second users selected by the system, the added links associated with said page that are not included in the first user are "suggested".

2 0 to this last.

  Alternatively, the selection of second close users can be done with respect to a set of pages selected by the first user, rather than compared to a single page. We will describe in the following the selection process from a

  On the one page, the person skilled in the art will be able to adapt this method to the case of several pages.

  Advantages The search for second users is done in a focused way; it is not based on their overall interest profile (vis-à-vis the overall interest profile of the first user). This is an advantage both at the level of

  relevance of the result as performance performance.

  In terms of the relevance of the result, the advantage of the focus is to be able to compare the profiles of the users by disregarding the elements of these profiles.

  that are not in the context that interests the user at the current time.

  In other words, the number of relevant elements (relative to the current context) which are found to be in common between the first user and a second user with whom he is compared, on the one hand, is not "diluted" in the mass of elements that are globally common, and secondly can be relativized with respect to the

  domain size of the current context.

  In order to focus the searches of neighboring profiles, the state of the prior art consists in partitioning the elements of the profiles according to categories adopted by all the users, which make it possible to classify them globally or in relation to attributes that characterize them. This specifies their membership of the respective domains taken into account during the searches, which allows to prune the elements

  profiles that are not in the user's current interest area.

  However, the categorization of profile elements requires users to agree on the vocabularies of categories to share. However, this approach is not advantageously adapted to widely decentralized systems such as the Internet. The essential advantage of the method according to this aspect of the present invention is to focus the search without having to classify the elements of the profiles according to shared categories, and therefore without having to agree on common vocabularies.

2 5 categories.

  At the performance level, the selection can be done on the basis of a search in direct access thanks to a data structure (such as an inverted file) which allows to find the second close users directly from said

  Page, or even from that page and its added links.

  Detection Details of Close Directories As users can place the same links added in directories

  different, the method can be used to select directories instead of users. In particular, the system can advantageously serve to select; -

  << close >> directories of the first user,

  - several directories of the same second user.

  In the following, we will describe the approach of selecting directories

rather than users.

  As already indicated for the case of searching for the closest users, the selection of the closest directories can also be done very efficiently thanks to a data structure (such as an inverted file) allowing to find in direct access the directories containing a given page (the current page of the user). Direct access can even be based on the given page and links

Added associated with it.

  Note in this regard that the Added links from which the selection is started are those of the current directory (or those of all the current directories selected by the user, as described in the section "Creating links

Added in Directories ">).

  Figure 57 schematizes the two types of data access request execution (in the case where the data is stored in relational tables) - the direct access to the links added from: 3 0 - of one or more pages, - of a user, - in one (or more) directories; - direct access to users and their directories from: - one (or more) pages, - and its added links (obtained by a request of the first type). Recall that the first type of request is the one that allows the "Find Added Links" functionalities described above, whereas the second type of request is that of "Detection of Close Directories", which is the subject of this

section.

  The closest directories, automatically selected, are presented to the user in the second list (called "neighbors of interest") schematically illustrated in Figure 55a. As already described in the previous section ("Publishing of added links"), the user can check one or more of the directories that are offered by the system. As a result, new links added, drawn from this or these directories, are suggested in association with the

  current page (as described in the previous section).

  The system can also provide the user with the means to attempt to connect - through synchronous communication means on Intemrnet such as simultaneous messaging, video conferencing, and so on. with users who have these

  directories that would be online at the same time as the user.

  Indeed, in the two types of client-server architecture represented respectively in FIGS. 44 and 45, the requests that the users form by means of their browser are communicated to the server in which the system is executed. The latter is therefore able to know if the users in question are online and if

can communicate with them.

  The user can also get in touch by asynchronous communication, in particular by e-mail or in the context of discussion forums, with these "close" users (that makes him "discover" the system), even if they are not

not online at the same time.

  It should be noted in this respect, that thanks to the already mentioned means of selection in direct access of users from pages of interest to them (in addition to a structure of direct path to pages from users and directories) the system is able to build, with very good performances, communities of users sharing the same interests. The discussion topics created are those for which a set of pages of sufficient size has interested a large number of users. They are invited to participate in a discussion forum

  having as theme this set of pages.

  We will now describe the method of calculating proximity.

  Starting from the current page (that is to say the page viewed by the first user) with its links added in the current directory or with the union of the added links associated with this page in the current directories selected by the user. - the system finds among the other directories (of the first user and / or among the published directories of second users) containing said page,

  those with the highest proximity score around that page.

  As a result, the system proposes to the user these directories in the order of their

2 5 proximity.

  Proximity is calculated at different levels.

  At the first level, the proximity is a function of the number of common added links associated with the current page. Figure 58 illustrates the determination of proximity to

level 1.

  At level 2, proximity is also a function of the number of common added links associated with pages linked to the current page by added link, such as

Figure 59 illustrates this.

  At level n, proximity is a function of the number of common added links associated with pages indirectly linked to the current page by added link, where n is the number

of indirection steps.

  Transitive proximity We will describe below an improvement of the method of calculating proximity between

  two directories described above.

  The system can enrich its evaluation of proximity by anticipating the propagations

  likely links added in the future.

  Indeed, the added links that are currently not yet propagated (suggested) from one close repertoire to another, will probably be in the future, and, after acceptance, will be ready to be suggested to a third. directory (and so on). The system can enrich its estimate of proximity by anticipating these propagations (suggestions) and acceptances, and by calculating the proximity of a

  directory taking into account this anticipation.

  This can be done by two different approaches: - either by predictive simulation: Predictive simulation takes into account the probability of acceptance (as described later) of future suggestions for links added, in the directories

  close to the current directory of the user.

  The predictive simulation method consists of simulating the propagation of added links, from directories a priori not close to the current directory, to directories close to the current directory. Following the (simulated) propagation of a link added from each non-close directory (to a nearby directory), an acceptance probability coefficient (described later) related to this non-repertoire

  near is associated with the added link.

  The proximity can then be refined taking into account the new added links (introduced by the simulation) weighted by their acceptance probability coefficient. The proximity calculation can be refined gradually, taking into account more and more indirect levels. Indeed, the predictive simulation can be done at increasingly greater depths of indirection: thus an added link can be propagated (by simulation) in a directory close to the close repertoire in question, before arriving in the latter, And so on. For each new directory, the system applies to the added link the acceptance probability coefficient associated with the directory from which it was drawn. On arrival in the close repertoire in question, the added links (suggested by simulation) have a probability of acceptance coefficient which represents the composition of the probabilities of acceptance in the different

directories where they are.

  Optionally, the user can set the system to ask him to directly suggest the added links propagated by simulation in the nearby directory (although these added links are not yet accepted by the owner of the

close repertoire).

  In a progressively more indirect manner, the user can ask the system 30 to directly suggest the added links propagated by simulation in the directories close to a nearby directory, and so on. During propagations from one directory to another, the acceptance probability coefficients are composed

  and the suggestions can be made in the order of these coefficients.

  - or according to the approach described below and called calculation of "transitive proximity" and which offers the advantage of a greater speed of computation Consider three repertoires R1, R2 and R3 The "transitive proximity of R3 for RI "is a function of the minimum between" the proximity of R2 to RI "and" the proximity of

R3 for R2 ".

  The underlying principle is, in fact, that in a chain of potential propagations of added links, the transitive proximity is a function of the proximity of the

  weakest link in the chain.

  At the obtained value (taking the minimum of the proximities), one must also apply the composition of the coefficients of probability of acceptance of the respective repertoires

  (acceptance of R2 by R1 and of R3 by R2).

  An example is shown in Figure 60: - the proximity of R2 for RI is 2; indeed the added links pointing to pages p2 and p3 are in common; the proximity of R3 for R2 is 1 (only p5 is in common); it follows that the Transitive Proximity of R3 for Ri is 1 (the minimum between 2 and 1), while the

  Proximity to R3 for RI is only 0 (no link added in common).

  Of course, the transitive proximity can also be calculated in a longer chain of potential propagations, taking the minimum of the proximities between the repertoires taken sequentially in said chain and applying to it the composition of the coefficients of acceptance probability existing for all the

links in the chain.

  Acceptance probability coefficient The determination of the probability of accepting, in a first directory, a suggested added link from a second directory can be based on the history

  Suggested link acceptances suggested from this second directory.

  In this sense, each first directory maintains a counter for each second directory from which it has received suggestions in the past. Of course, this counter can be maintained for a time limited in time. The

  value of this counter represents the coefficient of probability of acceptance.

  The acceptance probability coefficient is a function of the number of accepted links accepted (in normal mode or in frozen mode) minus the number of added links refused.

  in relation to the number (total) of suggested added links.

  This process may comprise various sophistications that will be implemented by the skilled person, including weighting to give a weight

  stronger to more recent acceptances / refusals.

  For a new directory, that is from where no added link has been suggested in the past to the user's current directory, the system can be based on an intermediate directory (having a history in the current directory and the new directory having a history at home) to determine the probability of acceptance. This is done according to the following approach: If a directory RI enjoys a high coefficient of probability of acceptance (C0-1) 30 from a directory R0, and a directory R2 has a high coefficient of probability of acceptance (C1-2) with the repertoire R1, then, by transitivity, R2 will have a strong

  acceptance probability coefficient (C0-2) from the R0 repertoire.

  More precisely, the value CO-1 reflects the degree of confidence that the owner of the directory R0 gives to the contents of the directory R1. Indeed, since in general the owner of the directory R0 accepts the suggestions from the directory RI1, it gives a relatively high degree of confidence in the validity of the act of acceptance in the directory RI. In other words, the owner of the repertoire R0 considers that the owner of the repertory Ri has a good judgment in terms of acceptance and

refusal in said directory R 1.

  Now it happens that the owner of the directory RI has accepted in this directory a large part of the suggestions from the directory R2 (that is to say that the value C1-2 is high). Since his judgment is good in the eyes of the owner of the repertoire R0, the system can conclude that the owner of the repertoire R0 will probably

  also accept suggestions from the R2 directory.

  By the same reasoning, if the value C0-1 is strong and if the value C1 2 is low,

  then, the system can conclude that the C0-2 value will be low.

  Of course, the depth of transitivity (the number of intermediaries) can be greater: the system can be based on several intermediaries that have strongly validated in the past (preferably the recent past - see above on the weighting ) to predict that a new directory will probably be validated or not. But, of course, the reliability of the coefficient obtained will decrease with

the depth of transitivity.

  It has already been mentioned that the detection of close directories makes it possible to present these directories to the user in the second list (entitled << neighbors of interest >>) 30 diagrammatically illustrated in FIG. 55a. The probability of acceptance coefficient is an indicator that is presented with each of these directories (it can for example be called "acceptance statistics"). The user will prefer to check

  directories that have this highest coefficient possible.

  Section 7 - Suggestion of links added by the administrator of a site Presentation The administrator of a site ("Webmaster" according to the English terminology) specifies, in the source code of the page to which a user accesses, or still in a table contained in a suitable server and whose key is the address of said page, all the addresses of the directories (called "Specialists") which

  can be offered to the user in the first list of Figure 55a.

  The following two steps can be implemented in the exploitation of these directories (candidate directories) for a given user: 1. In the first step, the system retains among the candidate directories only those which are closest to the current directory ( within the meaning of the previous section "Detection of Close Directories"). However, this approach is valid only if the page accessed by the user is not new to the user, and the user has already added links to it, so that the system can compare them with those in each of the candidate directories specified by the administrator (to determine how far this directory is

  close, and thus retain only the closest candidate directories).

  If, on the contrary, the page to which the user accesses is new for him, the system can, optionally, still try to select nearby candidate directories, by comparing the added links which are in the current directory of the user (these added links are not associated with the current page, since this is new, but to other pages) with added links from candidate directories, starting from pages at progressively higher levels

  away from the current page in the candidate directories.

  In case of failure, the system may propose the first directories specified by the site administrator to be presented by default. 2. The system retains, in the directories chosen in the first step, only the most advantageous added links according to a set of relevance criteria whose weight

  relative can be set by the site administrator.

  From the Candidate Specialist directories (and / or close "neighbor of interest" directories), the system can also synthesize a first specialist directory in a "custom" manner and propose it to the default user. The content of this new directory is created by grouping selected links selected in the candidate directories, which are potentially the most relevant for the user. In relation to each added link, the administrator may specify: - the manner in which said added link will be graphically presented with the current page; - and how the reverse added link will be graphically presented when the page

  towards which points said added link tip will be viewed.

  2 5 Directories in the list entitled "Specialists" The source document of a page accessed by the user (for example a page written in HTML) may contain, among the data not shown on the screen, the address of the user. a first directory (containing links added) to propose by default to

The user.

  This address (composed for example of the user's pseudonym and the directory path chosen by the site administrator) is used by the system to be presented first in the first list ("Specialists") of the

Figure 55a.

  This address is checked (selected) by default by the system, which means that the user is implicitly considered as wishing to be suggested the added links of the directory in question in his own list of added links (according to

  the description in the section "Publishing added links").

  In the source document, the administrator can also specify additional addresses of directories of other specialists. These will be used as optional elements in the first list (<"Specialists)>> of directories proposed in

  the user, but will not be checked by default.

  Alternatively, these specialized directory addresses, instead of being noted in the source document of the page accessed by the user, can be stored on a server in a table that provides the correspondence between the address of the page and the Directory addresses Specialists assigned to it. In the case where said server is also the added link server for the current user, this alternative avoids an extra roundtrip on the link server added in the server.

  case of the architecture of Figure 44.

  Selecting Candidate Directories The number of Specialist directory addresses (specified by the administrator) can be much greater than the number of directories that will actually be presented to the user. A maximum number of directories to present can be fixed

  by the administrator and / or the user.

  As already mentioned briefly in the presentation above, among the candidate directories, the system selects the directories closest to the user. This is done: - either directly according to the technique described above in the section "Detection of Close Directories", - or according to an extension of this technique, called "Proximité Décalée", that one

will now describe.

  Proximity Offset In the case where the current page (viewed by the user) - has no added link (especially because the user accesses it for the first time in its current directory) - or does not have enough links added in common with none of the candidate directories (with respect to a quantitative criterion set during the system configuration), the system, not being able to detect (by the method described in the section "Detection of close directories">), among the candidate directories, the "closest" directories, select the candidate directories by the following steps: 2 5 a the system retains the candidate directories offering the largest number of pages of removal of level 1 (this is pages pointed by added links associated with the current page) that are in common, for each of the level I remoting pages that are in common, the system calculates the Proximity (as described in the section "Detection of

  Close Directories> ") from these pages.

  The Proximity Offset for the candidate directory is a function of the Proximities thus determined. In the end, the system selects the candidate directories offering the most

  High Decal proximity determined as described above.

  In the case where the result of the search of the point "a." Is not sufficiently satisfactory, the system can possibly search, in the current directory, pages located at progressive levels of remoteness in the directories

  candidates (Proximity Shifted away> 1).

  At point "b.", The Proximity search depth level may possibly be increased or decreased (the least expensive computing resource case being the one with level 0 depth, that is, in

shorting the point "b.").

  Fig. 61 illustrates the offset offset distance determination I for a candidate repertoire. In this example, the system finds, in the current directory 20 of the user: two pages in common (p 1 and p 2), for the page p1 of the candidate directory, a proximity value equal to two links added on three; and for page p2, a proximity value equal to an added link

On two.

  Note that this proximity calculation technique shifted from a progressive level of distance from the current page can also be used in general to search for nearby directories (in particular among a set of users), in addition of the proximity calculation technique

  3 0 described in the section <"Detecting Close Directories".

  FIG. 62 thus illustrates the determination of the offset 1 away proximity of a directory B with respect to a current page p0 in a directory A. It will be observed that in this example, the proximity determination as described in the section << Close Directory Detection ") would have failed since the p0 page does not exist in the B directory. Selection among the added links The added links contained in the selected candidate directories (ie the" Specialists "proposed in the first list in Figure 55a) may have many more links added (in "Accepted" or "Frozen" mode) than those suggested to users, since the system is able to select the most relevant added links for each the user who will receive them.Thus the suggestion of added links is done in a "personalized" way.The selection is carried out for example according to one or more of the criteria sui vantages (selected in particular according to the resources that they require a priori for their implementation): the potential interest of the added link in question (said "added candidate link") for the user: as already mentioned in the section " Creating links added in "directories", the added links are bidirectional, ie an added link associated with a page P1 and pointing to a P2 page implies (as soon as it is accepted) the creating the added link associated with page P2 and pointing to the page Pi; it is therefore in the interest of the site administrator to suggest a link added on a potentially interesting P2 page, since * the more interesting the P2 page, the more the user will consult it; * and each time he will consult it, the added link pointing to the page P1

  will appear there and will thus encourage the user to go to consult said page PI.

  In order to satisfy this particular criterion, the system notably has the possibility of analyzing whether the added candidate link has been accepted or frozen in directories close to the user's current directory. To do this, and as shown in Figure 63, the system searches for directories (close candidate directory) with: * the current page (note that because the current page is new to the user, no link added is still associated with it); * the added candidate link associated with the current page, in accepted or frozen mode, * and the directory of the user having a strong proximity value shifted by distance 1 (or progressively more if necessary) with respect to the directory

  close candidate from the current page.

  - the fact that the user had already received the page pointed to by the added candidate link (if it is not a new page for him) in the current directory, and the fact that in addition the page pointed by the added candidate link is already well "anchored" in the current directory (in the sense that the user has a relatively high probability of consulting it by navigating from one page to another in the directory), since the more the user accesses the page pointed to by the added link, the more he will see the added inverse link which will encourage him to revisit the current page (however, see the third sub-criterion below which consists in setting a higher threshold number of pre-existing added links), the anchor property is measured by counting in the current directory the number of added links that point to the page in question (or more simply, since the added links are bidirectional, counting the links

  added to the page in question).

  - how much the user had already accepted or frozen this page (or on the contrary, how many times he had left it in suggested mode or he had refused it): thus, if the user had already received this page ( pointed to by the added candidate link) in the current directory, and if moreover it had accepted it (or frozen), this indicates that this page interests it and that it will thus probably be accepted again as an added link of the current page; it is therefore more advantageous to choose the added link pointing to this page rather than an added link pointing to a new page for the user; on the other hand, if the user had already received this page but since then it left it in suggested mode, or, a fortiori, it refused it, the system will prefer not to choose it, because the link added candidate has relatively less than

  chances of being accepted by the user.

  - the number of links added commonly associated with the page pointed by the added candidate link: if, in the user's current directory, a multitude of added links are already associated with the page pointed by the added candidate link, the added link inverse to the added candidate link will be "drowned" in this multitude and will not have the desired incentive effect; It is therefore not always advantageous to choose a candidate added link whose page to which it points already has too many links added to the user's directory (note that this sub-criterion is the inverse of the criterion of anchorage, it must be used to set a threshold that must not be exceeded); the administrator then indicates advantageously, with each specialist directory (which it specifies for example in the not shown part of the source document of the page, or in a table on the server, as described above): * the maximum number of added links to suggest (see above), being reminded that the user too can constrain this number; * the relative weight to give to each of the criteria (ie the weighted aggregation formula of the criteria) described above, as well as possibly indications on the heuristics to be implemented in their taking into account (it's about

  in particular to avoid criteria that consume too many resources).

  Direct suggestion in the default directory The system can synthesize and propose links added from: - Specialist directories and / or - close directories automatically determined by the system and present the added links obtained from these directories (candidate directories) for example through the first repertoire of the first list of Figure 55a, which

  is offered to the default user.

  This first directory is thus "synthesized" in a different way for each user. To do this, in the candidate directories, the system chooses the links added: - which point to a page, * while this page is already existing and has been accepted (or frozen) a sufficient number of times in the current directory of the 'user' or who has proved to be interesting in a sufficient number of neighboring users of interest (or more exactly, who was accepted or frozen in a sufficient number of close directories), - and optionally, who point to a page for which the "Cumulated Offset Proximity"> of distance I (from the current page), obtained by adding the Distance 1 Proximities of distance 1 in the candidate directories, is the most

great possible.

  Graphic presentation With each added link, the site administrator can specify in which form, with which image and at which position of the current page, the added link will have to be placed, the presentation being able for example: - on the edge of the page (in a list of "thumbnails"), - on the page (like a sticker), or in the form of a small icon on the page that turns into such a placard when the mouse passes, - or still in areas of the page that were intended to contain advertising. The administrator can also specify these graphical presentation settings for the added reverse link (which will be displayed on the page to which the added link points

in question).

  In particular, the administrator may expressly wish to specify to which position or in which region, on the page pointed to by the added link in question, the graphic representation of the added inverse link will be applied. It is indeed by this means that he can better encourage the user to come and consult his own page (the current page). His audience will therefore depend in part on the position (as well

  as the graphical appearance) of the added inverse link.

  Figure 64 illustrates the graphical presentation of an inverse added link on a page (in the form of a poster). A page has a link added on a p2 page which is already very crowded with a multitude of added links presented graphically as thumbnails (in a vertical list). On page p2, the added inverse link pointing to pl is not presented as one more thumbnail, but in the form of a placard directly on the content of the page. The graphical representation of the added inverse link can also be automatically inserted into a region that normally should have contained advertising. The administrator hopes to attract

the user's attention.

  The service offered by the system, consisting of allowing the administrator to incite the user to click on an inverse added link (pointing to the page published by said administrator): - may be offered ("quote" function) by means of a hearing forecasting calculation - may be billed ("billing" function) for the service actually rendered, based on: * the audience of the page to which is associated the inverse added link (the number of times that the page p2 of figure 64 is seen by the users of the system), * effective clicks, that is to say according to the number actually clicks

  made on reverse added links.

  Indeed, not only, an inverse added link directly encourages the user to access the page to which he points (in this case the page pl of Figure 64), but in addition, the links added to the page (p2 ) to which the reverse added link is associated can be published (see the section "Publishing added links") and be

  thus propagated from one user to another.

  In this propagation scheme, only reverse-added links accepted by a user will be suggested to users who are downstream in the propagation chain. The audience prediction can be advantageously performed by applying the acceptance probability coefficient which takes into account the behavior of the users (as described above in the section "Detecting Directories").

Relatives ").

  Section 9 - Publishing Directories An enhancement of the system is to allow the user to publish (or make available to a small group) at least a subset of

  directories of his personal canvas.

  In the same way as in the approach described above in the "Publication of Added Links" section, links to pages contained in a published directory can be viewed: - directly by means of a standard browser (for example, more upon receipt of an e-mail);

- or by means of the system.

  The directory accessed by the user through the system becomes his current directory. It can be one of its own directories or a directory published by another user. The user can "manually" insert new links into

this directory.

  The user who visualizes the contents of a directory by means of the system, can also enrich this content by being suggested links from other directories which are proposed to him in the lists "Specialists", "Neighbors of interest" , and "Buddies" (as in the case of Added Links). These three lists are recalled below: 1. The Specialist directories are those proposed by the site administrator, and the latter can propose to the user a number of specialist directories (candidates) larger than the number of directories that will be presented in this first list. The system selects: first the directories specified as to be presented by default (if any), - then, as and when the user accepts links (the acceptance is described later in this section) in the current directory, the system selects the directories whose links are as close as possible to the links

  Commonly accepted (or frozen) by the user.

  To do this, the system essentially chooses the directories containing the most links in common with the set of links accepted (or frozen) by the user at

current moment.

  A Specialist directory may contain more links than the number of links that will be suggested to the user. The system then preferably selects the links associated with the largest number of links added (in the Candidate Specialist directory) with links that (in the current directory) are already accepted. Of course, only the links that are not

  not already in the current directory.

  2. Neighbor directories of interest are determined automatically by the system. These are: - either close directories and the same category, which are determined by causing the system to select, among the directories of the same category, those that contain the most links in common with the links accepted (or frozen) by the user. 2 0 - either directories containing the most links in common with links accepted (or frozen) in the current directory, regardless of their categories; this approach can be effective if the selection of these directories can be made in direct access from the links contained in the current directory (see the type of query shown schematically in Figure 65); in addition, this approach makes it possible to associate the categories with the directories automatically, since the categories associated with each automatically determined directory are proposed to the user, when

  last selects said directory.

  The great advantage of this method is that it allows users to associate categories of common vocabularies with the directories (the system encourages

speak a "common language").

  3. Copains directories are directories chosen by the user (see section

"Publishing Added Links").

  The principle of Publication and Suggestion being the same as for the Publication of Added Links (see the section "Publication of Added Links"), we do not specify here all the details, but some particularities of the links (associated with the directories)

  as opposed to the added links (associated with the pages).

  In the set of links (to pages) that are contained in the directory that the user is viewing, the user receives additional links from the directories selected in the three lists described above (Specialists,

Neighbors, Buddies).

  As for the Added links, the system can advantageously comprise means for selecting links based on criteria ("Provider",

  "Requestor", etc.), given by the user or associated with the viewed directory.

  The links that are thus suggested to the user must be distinguished from those he himself had added: he may indeed refuse some. For this purpose, the links can be in one of several different modes: "Suggested", "Accepted", "Refused" (and "Frozen", the latter mode being described in the section

"Frozen Mode Links").

  2 5 The links received by a first user, from the links published by a second user (or from one of the directories of the first user), are at home.

  first user initially in "Suggested" mode.

  Following a user action, each link added in Suggested mode can switch to one of the other modes. The user interface allowing the implementation of

  these mode changes are shown schematically in Figure 66.

  This figure also illustrates the fact that, since the directories are viewed as pages, the user can associate them with added links. It can thus be seen that the directory rl has been associated (by the technique of the links added) the directories r2 and r3 as well as the page p6. The storage means therefore associate with the links a "Mode" attribute which can take the value: Accepted, Refused or Frozen. Figure 56 shows a class diagram for the Added links, according to the Unified Modeling Language (UML) standard representation, highlighting the Link Mode attribute

  Added. We complete this description with Figure 67 which shows that the links

  (to pages) also have a Mode attribute. This attribute can also be set to Accepted, Denied, or Frozen. In addition, the "Directory" class has the "Categories" attribute, which is used to compare directories of the same category (regardless of the names that users give them).

gave).

  A link in Suggested mode only exists while visiting a selected directory in one of the three lists already mentioned. It is not displayed outside of this

2 0 visit.

  A link in Suggested mode is not stored in the user's personal storage space because, at each new visit, it is recreated from the corresponding link

stored in the source directory.

  Passing a link from the Suggested mode to the Denied mode has the effect of filtering

  automatically said link during subsequent visits.

  Switching to Accept mode means that the user "<valid" the link that is in Suggested mode, which has the effect of: 1. storing the link in his personal storage space, so that he is presented again with each new presentation of the contents of the directory in which the link was stored, this presentation takes place even if the link was deleted in the directory that was the source of the link) - this in contrast to the Suggested mode links which are no longer presented from the moment they are deleted in the source directory, this presentation takes place even if the directory was

  the source is no longer selected (has been unchecked).

  2. if the directory in which the said link is stored is published, to publish the link ex officio (unless the user otherwise instructs) - this as opposed to the links

  added in Suggested mode that will not be published.

  Note here that the insertion of a link into a directory (for example manually by typing its URL or by drag and drop from another directory)

* automatically causes its setting to Accept mode (since the user has inserted it himself).

  A page viewed by the user in the current directory causes the insertion of the

  link to said page in Suggested mode in said directory. It is not stored.

  However, as soon as a link added in Accept mode is associated with this link, the link goes into Accept mode and the system stores it in the user's personal space. Section 10 - Links in frozen mode Switching to "frozen" mode means that: - not only has the user validated the added link, but also - the current version of the page (pointed to by the added link at the time o the transition to frozen mode is performed) is stored in the system to assure the user that said added link (as long as it is not deleted) will direct

  always the user on this same version of the page in the future.

  More specifically, the current version of the page in question is copied to a storage space specific to the current directory of the user, and the link points to

  now to this stored version.

  In fact, to optimize the space consumed, it is advantageous for the system to store only one copy of each different version of the page, which will be shared by all the users and directories with this link in Frozen mode. This optimization is necessary because the same version of page can be pointed by added links associated with different pages: - from the same directory, - from different directories of the same user, or - from different user directories, and therefore a multitude of frozen added links pointing to the same page

can exist.

  When an added link pointing to a page is frozen, the system first checks if the current version of that page is already copied, if necessary the system modifies

  said link added to point to this copy.

  To determine if a copy of the current version of the page already exists or not: - the system stores in a table, in association with each link (to a page) for which a copy is stored, the date and time of the copy; if a copy exists for the link in question and the copy is recent, the system compares the content of the current version with that of the copy, and if the contents are identical, the system thus avoids creating a new copy; alternatively, the system can exploit the information provided in the source document of the page in question to know its version (and determine if

  it is different from the version as copied).

  Section 11 - Containers and contents We will now generalize the concepts described in the previous sections, in

  considering "Container" structures ("Containers") in English terminology

  saxon) containing elements "Contents" ("Contents" in English terminology

  saxone), at any level in the structure of information held by

  the user in his personal storage space.

  The various modes of exploitation of the links added between pages described elsewhere in this chapter may, in many instances, be extended to the exploitation of links located in containers included directly in the page structure and pointing to contents likely to be incorporated into the page in question. The pages are documents, themselves structured in hierarchical form (for example: sections, paragraphs, etc.), and associated with a user presentation specification. In the following, we will consider documents whose content is specified according to the standard notation XML (abbreviation of the English expression Extended Markup Language), and whose presentation is specified in the language XSL (abbreviation of the expression Anglo -Signs XML Stylesheet Language) or equivalent language. These technologies lend themselves perfectly

  hierarchical structuring of information.

  The entire personal web of the user is viewed as a tree structure of nested contents / containers, each content being viewed as a document (or document fragment) in XML format which is optionally associated with a presentation specification in XSL format. At each level in this tree structure, content can be displayed on the computer screen autonomously only if an XSL document is associated with it. In the opposite case, the Content

  The closest ancestor with an XSL is displayed by default.

  For example, a directory is first of all a content that can be presented to the user as a stand-alone page, as long as an XSL document for the presentation of the directories is associated with it. A directory also has one and only one container whose contents are themselves directories or other types of documents. Some of these documents may contain multiple containers, which

  themselves contain content, and so on.

  All the means described so far for directories and pages are applicable

  respectively to containers and contents.

  In this case, in particular: - the links (to pages) are then links to contents; the Added links will also point to contents, - and the Acceptability Probability Coefficients introduced in the "Near Directory Detection" section are then associated with containers rather than

Directories.

  Starting from the fact that the user can copy (or "import") a link from one directory to another, this section proposes a system to allow him to import any content from any container to another. another (provided that the type of content does not violate the type constraints of the container that is supposed to receive it) at any level in the information structure

of the user.

  Likewise, this extension of the system is intended to allow the user to pull (ie drag-and-drop) links added from any content to any other content. Thus, instead of being able to derive links added between pages, between directories and in a mixed way between directories and pages, the user can pull an added link between an element in one page and another

  page considered in its entirety, for example.

  Advantageously, an added link (and in particular an inverse added link) may point to content buried in a page. In the case where the content to which the added link points has no associated presentation specification (in XSL format), the implemented mechanism will display the closest parent content (which contains it)

in the hierarchy of contents.

  In addition, a third manipulation offered to the user will be introduced: the "derivation" of the container, according to which a first container derived from a second container receives in Suggestion mode all the contents of the second container (or possibly a selection thereof). ) that are in Accepted (or Frozen) mode. This transmission of contents is permanent, in the sense that even the contents that are accepted in the future in the second container are

  suggested in the first container as soon as they are accepted in the second container.

  The documents that constitute the pages published on the Intemrnet sites must be restructured to make it possible to distinguish the contents and containers which constitute them. The text below is a simple example of an XML document: <Root> example <img src = "urlsource" /> information of all kinds <A id="A-1" name="Anatole"> < C name = "Hubert" id = "Cl" /> 3 0 <C name = "Edward" /> <C name = "Antoine" /> <C name = "Raymond" /> </A> <B name = "Henri" /> <B name = "Claude" myfriend = "C- 1" myenemies = "A- I B- 1"> example information text example information text <D name = "Dominique" myfriend = "A- 1" /> </ B> <B name = "Robert" id = "B1" //> <B name = "Andre" /> </ Root> An example of an XSL stylesheet that renders is rendered. presented in

the next ten paragraphs.

  Style sheet header: <? Xml version = "1.0" encoding = "ISO-8859-1"?> <Xsl: stylesheet xmlns: xsl = "http://www.w3.org/TR/WD-xsl "> <xsl: template match =" / ">

<HTML>

<HEAD />

<BASEFONT FACE = "ARIAL" SIZE = "2">

<xsl: apply-templates />

</ BASEFONT>

</ HTML>

  2 5 </ xsl: template> The source code nodes for which no particular processing is provided are copied to the HTML page: <xsl: template match = "*"> 3 0 <xsl: copy> <xsl: apply -templates select = "@ * Inode ()" /> </ xsl: copy> </ xsl: template> Attributes of the source code for which no processing is expected take the values specified in the source code: <xsl: template match = "@ *"> <xsl: attribute> <xsl: value-of /> </ xsl: attribute> </ xsl: template> For the Root tag, a title and a paragraph are added: <xsl: template match = "Root">

<H 1I> FAMILY / FRIENDSHIP / ETC ... </ H1>

  <p> In the street, there are plenty of people: </ p> <xsl: apply-templates /> </ xsl: template>

  The value of the name attribute is in bold.

  <xsl: template match = "* [@ name]"> <li> <b> <xsl: value-of select = "@ name" /> </ b> If the node has an id attribute, the value of the attribute is placed in the parenthetical rendering: <xsl: if test = "(id"> (id = <xsl: value-of select = "@ id" />) </ xsl: if> If the node has a myfriend attribute, the value of the attribute is placed in parenthetical rendering: <xsl: if test = "@ myfriend"> (friend of <xsl: value-of select = "@ myfriend" />) </ xsl: if> If the node has a myenemies attribute, the value of the attribute is placed in the parenthetical rendering: <xsl: if test = "@ myenemies"> (enemy of <xsl: value-of select = "(myenemies" />) </ xsl: if> <xsl: choose> If a node with a name attribute has subnodes with name attributes, these subnodes are presented in a list preceded by the "Children:" label: <xsl: when test = "* [@ name]"> <blockquote> Children: 2 5 <ol> <xsl: for-each select- "* [@name]"> <xsl: apply-templates select- "." /> < / xsl: for-each> </ o1> 3 0 </ blockquote> < / xsl: when> If a node with a name attribute does not have subnodes with name attributes, the "No child" label is displayed: <xsl: otherwise> - No child </ xsl: otherwise> </ xsl : choose> </ li> </ xsl: template> </ xsl: stylesheet> Here, the XML data structure is broken down into a set of containers and contents. These contain the elements of the initial XML structure. For purposes of classification, the containers may optionally be associated with categories, so that the contents they possess are classified in this category. In FIG. 68, in the tree structure of a document, we see

  containers (shown in dotted lines).

  Figure 69 illustrates the fact that such a structure makes it possible to take elements

  container to place in others by the import process.

  There will also be described a derivation process for placing a container in another, in order to take advantage of the contents of the original container, such as

schematized by Figure 70.

  Figure 71 illustrates that these manipulations can also be performed

from one document to another.

  We try to be able, from Internet pages, to restructure the information that is there to allow the user to compose his own pages, and this from containers and contents that he finds during his navigation. This involves defining a macrostructure of containers / contents, and dissociating

  content, which can be moved or reproduced from one page to another.

  On this basis, the XML data of a Web document will be decomposed to adopt the following structure: - a structure tree defining the nesting of the different information containers, each bearing the references of its contents;

  a series of contents, grouping the elements referenced in the containers.

  Steps of the transformation The administrator of a page of a site has an initial XML code (one will take again the example already presented above), which it wishes to make share with the users of the

system.

  A. Creating the Macrostructure In order for the source code to be restructured and stored without redundancy, the user specifies which elements are contents and which container each content belongs to. we call here

the macrostructure.

  Containers are specified by means of attributes. Using attributes rather than "tags" ("tags" in English terminology) offers the advantage of not changing the structure and thus, in particular, not to question the application of XSL style sheets. The restructuring is thus "non-intrusive." We will now present the application of a method of specification of contents and containers (using the example already presented above) by means of attributes <Root CONTAINERNUMBER = "I "CATEGORY =" url 1 "> sample information <img src:" urlsource "/> of all kinds <A id="A- 1" name="Anatole"> <C name =" Hubert "CONTAINERNUMBER" 1 " "CATEGORY:" url2 "id =" C- 1 "/> <Cname =" Edward "CONTAINERNUMBER =" 2 "CATEGORY =" url3 "/> <C name =" Antony "CONTAINERNUMBER =" 2 "CATEGORY =" url3 " /> <C name = "Raymond" CONTAINERNUMBER = "2" CATEGORY = "url3" /> </A> <B name = "Henry" /> <B name = "Claude" CONTAINERNUMBER = "1" CATEGORY = "url4 "myfriend =" C- 1 "myenemies =" A- 1 B- 1 "> example information text example information te xte <D name = "Dominique" myfriend = "A-" /> <B name "Robert" CONTAINERNUMBER = "1" CATEGORY = "url4" id = "Bl" /> <B name = "Andre "CONTAINERNUMBER =" 1 "CATEGORY =" url4 "> </ Root> Note that: -" Hubert "is in a container (CONTAINERNUMBER =" 1 ") different from the one

  of "Antoine", "Edouard" and "Raymond" (CONTAINERNUMBER = "2").

  - the attributes "myfriend" and "myenemies" are references to the nodes of the tree, because they have been specified as such (type "idref") by the schema associated with the

source code in XML.

  Notes 1- The macrostructure allows to dissociate the elements, of the structure in which they reside. Thus, the elements are stored uniquely on the server which

  30 the number of times they have been reproduced.

  2- By default, without any manual intervention, the macrostructure could be automatically modeled on the structure of the document. The granularity of the partition (granularity of the elements that can be replicated) would then be that of the elements of the document. But the system would be heavy to handle for the user, the macrostructure would be bulky and the performance would suffer. The approach we present is to allow to specify the macrostructure explicitly in the documents, that is to say to choose the granularity of the contents that can be shared. Thus, when specifying a content, it is, at the same time, located in a container that can group several contents. As the contents could have been modeled on the structure of the elements of the document, the containers could have been modeled on the structure of the contents (all the contents children of the same parent would have been put in a container). We preferred here explicitly to specify which contents are located in

which containers.

  B. Code decomposed From the indications appearing in the new source code, the decomposed structure is built up, on the one hand by the structural tree and on the other hand by the structure

2 0 following contents.

  In our example, the structure tree is: <CONTAINER SRC = "...? Id = 12" CATEGORY = "url 1"> 2 5 <CONTENTREF id = "ContentRef-1" SRC: "... ? id = Content-42 "NAME =" Root ">

<POSITIONCONTAINER N = "1">

  (Container o is Hubert) <CONTAINER SRC = "..? Id = 13" CATEGORY = "url2"> <CONTENTREF id = "ContentRef-2" SRC = "...? Id = Content-43" NAME = " C ">

</ CONTAINER>

  (Container o are Antoine, Edouard and Raymond) <CONTAINER SRC = "...? Id = 14" CATEGORY = "ur13"> <CONTENTREF id = "ContentRef-3" SRC = "...? Id = Content- 44 "NAME =" C "> <CONTENTREF id =" ContentRef-4 "SRC =" ...? Id = Content45 "NAME =" C "> <CONTENTREF id =" ContentRef-5 "SRC =" ...? id = Content-46 "NAME =" C ">

</ CONTAINER>

</ POSITIONCONTAINER>

<POSITIONCONTAINER N = "2">

  <CONTAINER SRC = "...? Id = 15" CATEGORY = "ur14"> <CONTENTREF id = "ContentRef6" SRC = "...? Id = Content-47" NAME = "B">

<POSITIONELTREFS N = "1">

  <ELTREFS SRC = "...? Id = ContentRef-2" />

</ POSITIONELTREFS>

<POSITIONELTREFS N = "2">

  <ELTREFS SRC = "...? Id = ContentRef- l" /> <ELTREFS SRC = "...? Id = ContentRef7" />

2 5 </ POSITIONELTREFS>

<POSITIONELTREFS N = "3">

  <ELTREFS SRC = "...? Id = ContentRef- 1">

</ POSITIONELTREFS>

</ CONTENTREF>

  <CONTENTREF id = "ContentRef-7" SRC = "...? Id = Content-48" NAME = "B" /> <CONTENTREF id- "ContentRef-8" SRC = "...? Id = Content-49 "NAME =" B "/>

</ CONTAINER>

<POSITIONCONTAINER>

</ CONTENTREF>

</ CONTAINER>

  The following content is: <CONTENT id = "Content-42" CATEGORY = "url 1"> <Root> sample information <img src: "urlsource" /> of all kinds <A name = "Anatole" id = "A- 1">

<POSITIONCONTAINER N = "1" />

</A> <B name = "Henri" />

<POSITIONCONTAINER N = "2" />

</ Root>

2 0 </ CONTENT>

  <CONTENT id = "Content-43" CATEGORY = "url2"> <C name = "Hubert" id = C-1 />

</ CONTENT>

  <CONTENT id = "Content-44" CATEGORY = "url3"> <C name = "Edward" />

</ CONTENT>

  <CONTENT id = "Content-45" CATEGORY: "url3"> <C name = "Antoine" />

</ CONTENT>

  <CONTENT id = "Content-46" CATEGORY = "url3"> <C name = "Raymond" />

</ CONTENT>

  <CONTENT id = "Content-47" CATEGORY = "ur14"> <B name = "Claude" myfriend = "C1" myenemies = "A-1 B-1"> <POSITION_ELTREFS N = "1" ATTRIB = "myfriend" /> <POSITION_ELTREFS N = "2" ATTRIB = "myenemies" /> example information text example information text <D name = "Dominique" myfriend = "A- 1"> <POSITIONELTREFS N = "3" ATTRIB = "myfriend" / > </ D>

<B!>

</ CONTENT>

  <CONTENT id = "48" CATEGORY = "url4"> <B name = "Robert" id = "B-1" />

</ CONTENT>

  <CONTENT id = "49" CATEGORY = "url4"> <B name = "Andre" />

</ CONTENT>

  As can be seen, all starting tree data is separated in the following content. The structure tree represents the nesting of the containers between them. 3 The nesting between "Root" and "Henry" is not in the structure tree because "Root" and "Henry" are in the same content, but the nesting between << Anatole "and" Hubert "," Edouard "," Antoine "and" Raymond "are reflected in the structure tree, because" Hubert "," Edouard "," Antoine "and" Raymond "are

  grouped in two different containers under "Anatole".

  In addition, it is found that the containers can be arranged very precisely in the contents. We will talk about positioning. The contents in which there are containers carry a tag indicating o the containers are (by means of a number POSITION_CONTAINER N). The positions in the contents are used in the structure tree. Each container is indeed nested under a POSITIONCONTAINER tag with a number. This number corresponds to

  the indication "N" in the contents. This is illustrated in Figure 72.

  When some tags have references to other tags, this is materialized in the structure tree and in the content suite by means of the POSITION_ELTREFS tag. The same approach as for the positioning of the containers is used. The position of references to elements is materialized in a content using a number POSITION_ELTREFS N, which one finds in the tree of structure, in the field "CONTENTREF" correspondent. This indirection makes it possible to find, in the tree structure of containers, the

  Where is the referenced element. This is illustrated in Figure 73.

  Detail of the decomposed macrostructure a. Structure tree 1. "CONTAINER" tag This tag represents a container within the structure tree. A container is

  identified by a URL called SRC.

  This URL is composed of the domain name where the container is archived, and the local identifier of this container for the domain. If multiple servers are associated with a domain name, then this server name is specified in the URL address between the domain name and the local identifier: SRC: DomainName / ServerName? ID This tag also has an attribute indicating to which category is associated

  container. This category is specified by means of a URL.

  A container is composed of several CONTENTREF tags (see precise definition below) that refer to the content in the succession of contents. In addition, a container may be in a content at a given position, according POSITION_CONTAINER tag (defined below) designating the position at which it is located.

find.

For example:

  <CONTAINER SRC = "...? Id = 12 >> CATEGORY =" URL "> 2." CONTENTREF "tag This tag is a reference to a given CONTENT element of the content sequence. It is identified by an integer identifier "ID", and carries a SRC attribute which is the unique identifier of the referenced content CONTENTREF The same URL syntax as for the containers is adopted. NAME name:

  <CONTENTREF ID = "432" SRC = "...? 43" NAME = "A" />

  3. "POSITIONCONTAINER" tag This tag is used to indicate the different positions where you can find containers in a content, as shown in the example below.

  CONTENTREF can contain several POSITION_CONTAINER tags, that is,

  that containers may be placed in more than one location of the content in question. In addition, at a given position, it is possible to find several containers, as in the following example:

  <CONTENTREF ID = 26 SRC = "...? ID = 44" NAME = "<< B">

<POSITIONCONTAINER N = 1>

  <CONTAINER SRC = "...? ID = 13" CATEGORY = "URLI">

  <CONTENTREF ID = 27 SRC = "...? ID = 45" NAME = "B 1" />

</ CONTAINER>

  <CONTAINER SRC = "...? ID = 14" CATEGORY = "URL2">

  <CONTENTREF ID = 28 SRC = "...? ID = 46" NAME = "B2" />

</ CONTAINER>

</ POSITIONCONTAINER>

<POSITIONCONTAINER N = 2>

  <CONTAINER SRC = "...? ID = 13" CATEGORY = "URL 1">

  2 0 <CONTENTREF ID = 29 SRC = "...? ID = 47" NAME = "B3" />

</ CONTAINER>

</ POSITIONCONTAINER>

</ CONTENTREF>

  B. Content Suite 1. <CONTENT "tag This tag represents content. Content may contain one or more tags from the original XML source code. The contents are identified by a unique identifier, and carry the URL of the category to which they belong, as in the following example:

<CONTENT ID: "43 >> CATEGORY =" URL ">

<A> <C> </A>

</ CONTENT>

  There may be cases that lead to the creation of content: (i) external content, that is, content that points to another content of a different (external category) host, for example: <CONTENT ID = " << 124 "CATEGORY =" URL2 (external) "> <A> <C /> </A>

</ CONTENT>

  (ii) indirect content, ie content that points to another content of the same host (but of a different category), for example:

  <CONTENT ID = << 44 "CATEGORY =" URL3 "INDIRECT = << 43">

2 5 </ CONTENT>

  2. "POSITIONCONTAINER" tag This tag indicates the position where a container can be inserted into a content, for example

For example:

  <POSITIONCONTAINER N = "l" /> 3. Tag "POSITIONELTREFS" This tag makes it possible to materialize, in the contents, the references that some beacons carry on others.As the tags "POSITION_CONTAINER", they carry an integer attribute < <N "indicating their positions in the content. They also have an attribute "ATTRIB" which contains the name of the attribute used by the author of the XML source code to define the reference. For example: <POSITION_ELTREFS N = "I" ATTRIB = <"myfriends" /> C. Recomposition of the pages of the Web Figure 74 illustrates the fact that the Net surfer has an additional access to the information. It can access it in a classic way by connecting to the source site of the Web, and it can also access it via the system, which allows it to interact

  with the containers and the contents, that is to say to organize them according to his will.

  The system breaks down this site into containers / contents (this site must imperatively have been put by its administrator in the form already described before, namely the form in which the administrator has indicated in particular where are the

contents and containers).

  In order to be presented to the user, the output information of the system is reconstructed and transformed using the XSL style sheet associated with the original XML. To allow the manipulation of <"handles" (which allow to graphically designate contents), the XSL style sheet adds, on the fly, in the original XSL specification, presentation code.

In FIG. 75.

D. Reconstructed XML code

  In order to be presented to the user, the decomposed XML is reconstructed.

  We can then apply an XSL style sheet. During reconstitution, it is ensured that the contents and containers are materialized so that

the user can manipulate them.

  In this regard, as we will see later, the intemaute can select a content or a container by means of "handles" to move or put them

in another document.

  For the example treated so far the reconstituted code is the following <Root CONTAINERNUMBER = "1" CATEGORY = "urll1"> Example of information <img src = "urlsource" /> of all kinds <A id = "A- 1 "name =" Anatole "> <C name =" Hubert "CONTAINERNUMBER =" 1 "

CONTAINERID = "13"

Contentid = "43"

  CATEGORY: "url2" id = "C- 1" /> <C name = "Edward" CONTAINERNUMBER = "2"

CONTAINERID = "14"

ContentID = "44"

  CATEGORY: "url3" /> <C name: "Antoine" CONTAINERNUMBER = "2"

CONTAINERID = "14"

Contentid = "45"

  CATEGORY = "ur13" /> <C name = "Raymond" CONTAINERNUMBER = "2"

CONTAINERID = "14"

Contentid = "46"

  CATEGORY = "url3" /> </A> <B name = "Henry" /> <B name: "Claude" CONTAINERNUMBER = "I"

ContainerId = "86"

Contentid = "47"

  CATEGORY = "url4" myfriend = "C- 1" myenemies = "A- 1 B- 1"> Example information text example information text 2 0 <D name = "Dominique" myfriend = "A-1" /> </ B > <B name = "Robert" CONTAINERNUMBER = "1"

ContainerId = "87"

Contentid = "48"

  CATEGORY = "url4" id = "B- 1"> <B name = "Andre" CONTAINERNUMBER = "1"

3 0 CONTAINERID = "88"

Contentid = "49"

  CATEGORY = "url4" /> </ Root> Presentation example From the reconstructed XML, a presentation HTML page is constructed using an XSL style sheet. In the context of the example presented in the introduction of this section, the same XSL sheet is used, except that it has been added "bypass elements" (that is to say the handles) allowing

  to interact with the content of the page.

  In the following, we will describe precisely what these derivation elements are, then how are the actions of import / derivation and their

consequence: the suggestion.

  A. Inserting import / derivation handles Using a template ("Template" in English terminology), the transformation into HTML of the information of the structure which allows the derivation, the import is defined. and the association of added links. Containers can not be represented as such, because they do not necessarily correspond to an "envelope" (ie to a single graphic object) viewed graphically in the resulting HTML page. That is why this transformation gives a graphical element (derivation element) for each node of type content. This derivation element allows drag and drop management of both containers and contents. Indeed, a component "BEHAVIOR" (see Appendix) attached to

  the element then communicates with the system.

  The above model is added at the end of the XSL page in order to overload it effectively.

  and for the derivation elements to be actually displayed.

</ = las soIelduwol-ldde: Isx>

<I1A0: ISX />

  (o ',, (} IEtINIVIlNOD ,,) alnq, lluVla Sl

<IUAD: ISX>

  <J.:lSX/> <luomolo: lsx /> <olnq.m3u: sx /> o E </ (IIULNtLNOD ,, l: 1olos joonIA: Isx> </ ALUI} WINOEIOPSJO-a'fltA: SX> <, , pIuluoo ,, = otueu omnqu.w: isx> <olnq.ille: Isx /> </ ,, (I itNIVJ.NOD) ,,: 1oolos.jo-onl ^ A: Isx> (oq'do.puimp ' uilsXs / ') im:> JOIAVHit 01 <.., 1, úS ,, = otm * u oinq.ul: Isx> <,, AIO ,, = omweu luoLumoI: [sx> <,. [. [= t OIN3IINVH ] * / ,, = 1sal j!: Isx> S <,, [0 <0I} IttNIVúNOD)]. ,,: qoleU Xoeldwol: lsx>

  : lueAins l [.I ap oldwoxo Did inod olopoum o op omle, -

  The DIV element (introduced in the 3rd line) is a derivation element with which the component "BEHAVIOR: url (... / system.dragndrop.htc)" is associated, whose appearance is presented in the Appendix. This component allows a management of the "drag and drop" of

  elements for the derivation of containers that it will communicate to the system.

  B. Reception of the event "ONDERIVE" When the component BEHAVIOR triggers the event ONDERIVE, by the instruction "fire (" ONDERIVE ", oEvent)" which is in the function "FinishDrag" (the variable "oEvent" being an event object in which are available information (identifiers of the source and target elements) that allow derivation and import), the system is then notified and performs the following actions:

  1- he asks if the user wishes to import the contents or to derive the container ;.

  2- it sends the import / derivation request; 3- it checks whether the display page is able to take into account the new source; 4- it triggers the refresh of the display, as follows: a. if the page is frozen, reconstruction and overall treatment of the source;

  b. if the page is dynamic, simple notification of data insertion.

  In this case, the page receives the notification.

  This event provides a pointer to an object that allows the script of the page to transform that new source (using, for example, the XSL sheet that has it

  initialized) and insert the resulting HTML code into the page.

  C. Manipulation of the macrostructure The development of the macrostructure of containers / contents makes it possible: - to place new contents in a container; we are talking about importing content; - to reproduce a container within other contents; we then speak of derivation

of containers.

  Importing Assume that we are in the situation shown in Figure 76: Containers 1 and 2 ("Container 1" and "Container 2") are attached to Category 1 (symbolized by the gray arrow). 1 is a reference to the content 1.1 ("Content 1.1"), and in the container 2 there is a reference to the content 1.2 ("Content 1.2")

  (These references are symbolized by black arrows).

  Importing the content 1.1 into the container 2 amounts to creating, in this container, a CONTENTREF tag that points to the content 1.1 in the content suite. This

is shown in Figure 77.

  When importing content from a category into a container associated with a different category, it is said that the import causes a recategorization. This results in the creation of indirect content, ie a tag similar to a CONTENTREF tag, but which is distinguished by the fact that it appears in the following

  content, within a category. This is illustrated in Figure 78.

  In the case where the imported contents have containers, these are

  derivatives according to the mechanism described below.

  Derivation Suppose we have the container / content nesting presented on the

figure 79.

  Deriving the container I amounts to inserting it into a content at a certain "position".

  To do this, a new container is created in the structure tree, and points (that is, has a reference, shown as a gray arrow on the diagram.

  of Figure 80a) to the container that one wants to derive.

  On the server, the data structure then has the following form for the derived part: - for the structure tree: <CONTENTREF ID = 26 SRC = "...? ID = 44" NAME = "Content"> 2 0 <POSITIONCONTAINER N = l>

  <CONTAINER SRC = <"...? ID = 126" SOURCESRC = "...? ID = I">

</ CONTAINER>

<POSITIONCONTAINER>

</ CONTENTREF>

- for the following content:

* <CONTENT ID: "44" CATEGORY = "URL">

  <Content> <POSITIONCONTAINER N = "l" /> </ Content>

</ CONTENT>

  As can be seen in Figure 80a, the container 126 does not refer to any content. It just has a reference to the source container, namely the one from which the derivation was made. The loading of the data into the derived container is done via the source container: this is "suggestion".

  client station, in the arrangement illustrated in Figure 80b.

  The sub-containers are derived in exactly the same way as the first container: a new container is created and points to the source subcontainer. The depth at which the elements are loaded into the derived container is fixed by the progressive loading mechanism (see chapter V below). Such a mechanism is necessary here because, otherwise, there could be cases of infinite loops in the load. Indeed, it is possible to derive containers in themselves,

  as shown in Figure 81, and thus create a virtually infinite structure.

  Without this mechanism, loading a container would then cause an infinite loop in

  the framework of a truly infinite structure.

  Case of the superposition of containers As already mentioned, the containers are inserted in very precise positions of the contents. But nothing prevents to insert several containers to the same

  position. This is called stacking containers.

  2 5 Let us start from the structure presented in Figure 82 (noting that the elements

  in a dashed frame are considered to be in a container).

  This translates as follows: 3 0 - for the structure tree: <CONTENTREF ID = 54 SRC = "...? ID = 42" NAME = "Root >>>

<POSITIONCONTAINER N = 1>

  <CONTAINER SRC = "...? ID = 12" CATEGORY = "<< URL >>>

  <CONTENTREF ID = 55 SRC = "...? ID = 43" NAME = << A>

<POSITION CONTAINER N = 1>

  <CONTAINER SRC = "...? ID = 13" CATEGORY = "URL">

  <CONTENTREF ID = 56 SRC = "...? ID = 44" NAME = - "C" />

</ CONTAINER>

</ POSITIONCONTAINER>

</ CONTENTREF>

  <CONTENTREF ID = 57 SRC = <"...? ID = 45" NAME = "B >>>

<POSITION CONTAINER N = I>

<CONTAINER IDCONTAINER = "14">

  <CONTENTREF ID = 58 SRC = "...? ID = 46" NAME = "D" />

</ CONTAINER>

</ POSITIONCONTAINER>

</ CONTENTREF>

</ CONTAINER>

</ POSITIONCONTAINER>

2 0 </ CONTENTREF>

- for the following content:

<CONTENT ID = "42" CATEGORY = "URL">

2 5 <Root>

<POSITIONCONTAINER N = "1">

</ Root>

</ CONTENT>

<CONTENT ID = "43" CATEGORY = "URL >>>

< "A>" -

<POSITIONCONTAINER N = <"1" />

<A>

</ CONTENT>

<CONTENT ID = "44" CATEGORY = << URL>

<B>

<POSITIONCONTAINER N = "<< 1>" />

</ B>

</ CONTENT>

<CONTENT ID = "45 >> CATEGORY =" URL ">

<C />

</ CONTENT>

<CONTENT ID = "46 >> CATEGORY =" URL >>>

<D />

</ CONTENT>

  Suppose now that the container 13 (the one containing the content C) is derived in the content 44 (which corresponds to the content B) at the same position as the container 14 (which contains the content D). The tag corresponding to the content 44 in the content sequence will not be modified. Indeed, the content keeps a single position for the containers, even if two containers are superimposed on this position. This superposition is manifested at the level of the structure tree by the fact that a new container is added under the POSITION N = 1 tag, as shown below: <CONTENTREF ID = 32 SRC = "...? ID = 42 "NAME =" Root ">> <POSITIONCONTAINER N = 1>

  <CONTAINER SRC = "...? ID = I 12 >> CATEGORY =" URL >>>

  <CONTENTREF ID = 33 SRC = "...? ID = 43" NAME = "A">

<POSITION_CONTAINER N = I>

  <CONTAINER SRC = << ...? ID = 13 >> CATEGORY = "URL">

  <CONTENTREF ID = 34 SRC = "...? ID = 44" NAME = "C>" />

</ CONTAINER>

</ POSITIONCONTAINER>

</ CONTENTREF>

  <CONTENTREF ID = 35 SRC = "...? ID = 45" NAME = "<< B >>>

<POSITIONCONTAINER N = l>

  <CONTAINER SRC = "..? ID = 144" CATEGORY = "URL">

  <CONTENTREF ID = 36 SRC = "...? ID = 46 >> NAME =" D >> />

</ CONTAINER>

  <CONTAINER SRC = "I 5 >> CATEGORY =" URL "

SOURCESRC = << ...? ID13 >>>

</ CONTAINER>

1 5 </ POSITIONCONTAINER>

</ CONTENTREF>

</ CONTAINER>

</ POSITIONCONTAINER>

</ CONTENTREF>

  Suggestion mechanism for new content (propagation in the macrostructure) The fact of deriving a container implies that it is possible to access the "accepted" contents present in the original container. These contents are in fact automatically "suggested" in the derived containers as and when they are inserted. It is up to the user to specify whether or not he accepts the suggestions, as described elsewhere. It should be noted that only accepted content can be derived in turn. The suggestion can thus be made between different users (for example when a user derives a container from a document of which he was not the author), but also when the same user derives a container between two of his own documents. When a user derives a container, he creates a new container with the reference of the source container, and the contents of the source container that were in "Accepted"> mode are loaded into it. These contents are initially in mode

  << Suggested, and the user can change their mode.

  In terms of the database contained in the server, the derived container does not contain any information about the suggested content. This information can indeed be found via the reference on the source container. On the other hand, on the client station where this container has been derived, a CONTENTREF tag is added for

  each content loaded in this container, with a MODE = SUGGESTED attribute.

  What is suggested can be accepted or rejected (or left in suggested mode).

  This possible change of mode is reflected by an update of the database on the server, as follows: - if the content is accepted: a CONTENTREF tag to this content is added in the database in the derived container , with an attribute

MODE = ACCEPTED.

  - if the content is refused: a CONTENTREF tag to this content is also added to the database in the derived container, with a MODE = REFUSED attribute; the goal in this case is to note that this content should not

  be presented to the user at the next login.

  The memorization corresponding to these different cases is shown schematically in Figure 83.

  Section 12 - Proposal of Specialist and Neighbors Directories We saw in the previous section that, in the context of a page to which the user accesses the Web by standard means, can be found containers, and that in each container can be links to content. These links are those chosen by the site administrator where the page is

  issue as to be presented by default.

  These links are supposed to be in Suggested mode. The user, through the system, can change their mode, to give them the value Accepted, Frozen or

  Refused, accessing this same page with the system.

  Instead of presenting the same links to all users, the Specialist Directory Proposal feature (already described in the "Publishing Added Links" and "Publishing Directories" sections) allows you to present several points of view on a topic. , according to a metaphor of "visiting" personal canvases

of "Specialists".

  With this page, the user can also receive added links (which have been

  associated by the administrator of the site or the Specialists he has selected).

  Thanks to the Specialist Directory Proposal feature, the added links will only be suggested in relation to a directory "visit" and will not overload

2 5 so not the page right away. In the example that we will take throughout this section (see figure

  84a), for a page on foie gras, Specialists (here Chefs) different present: 3 0 - associated with the page, links added on wines (Sauterne) and salads (Mesclun) different; - inside a container of the page, links on different types of foie gras

(Duck, Goose).

  The user can then accept certain added links and / or links located inside containers of the page, which are thus suggested to him. Note that, in this case, not only the "Mode" attribute of the added link but also the Link Mode attribute in the current directory, pointing to the page with which this added link is associated, is updated to the value "Accepted". Acceptance thus goes back from child to parent recursively. Thus the Mode attribute of the link pointing to the current directory, in the directory that contains it, if any, is also updated, and so on. It is the same for the links located in the

containers of the page.

  However, in general, the user does not accept an added link (or a link in a container) pointing to a page P, without first clicking on it to view the page P it points. Then, if the page P interests him, he accepts it directly, without returning to accept the added link where he came. In other words, instead of accepting the added link (or the link in a container) pointing to P, it accepts the page P itself, that is, the link pointing to said page P in the directory

current that welcomes him.

  A refinement of the system then consists in following the path of the user who clicks on an added link so that, when the target page is accepted, the system also updates the Mode attribute of the added link through which he has

accessed this page.

  By accepting an added link (or a link in a page container) the user declares his / her interest in the content to which these Links point. Its "profile of interest" is thus built up gradually, and when it reaches a threshold of representativeness, the system can propose to it close repertoires in the list of

  "Neighbors of interest" directories (see the "Buddies" list in Figure 84a).

  In the case o, as in the example of Figure 84a, the current page includes not only links added (Sauterne, Mesclun), but also links in at least one container (Duck, Goose) found in the page, the system selects directories that are close to: - compared to the accepted added links associated with the current page: the system selects the directories in which the current page is located as well as a large number of links added in common, as described in the section "Detection of Close Directories" - in relation to the links accepted) found in each container on the page: the system selects the directories containing the largest number of links in common with the container, as described in the section "Publication of

Directories ".

  It will be observed here that the system can exploit not only the links (links and links in the containers) accepted and frozen, but also the links refused. It is indeed interesting to consider what the user did not remember in the links that

  have been proposed to build his profile.

  The system uses the same data (added links and links in the containers) to adjust the Specialist directories offered to the user. This is described in

  the sections "Publication of Added Links" and "Publication of Directories".

  By offering a set of close directories, the system allows the user to visit the personal webs of a set of other users, with whom he can also get in touch, as already described in the section "Detection of

Close Directories >>.

  The user can click on a link (to content) in a container of the page, or on an added link to access the content in question. The system then offers the directories "Specialists", "Neighbors" and "Buddies" for this new content, and so on. Finally, the user can select a set of added links, or a set of links in a container, to ask the system to select directories close to him considering this set. The skilled person will easily extend

  the methods described so far to implement this functionality.

  Section 13 - Acceptance Attributes When accepting (switching to Accepted or Frozen Mode) content, the user can specify whether he or she is interested in purchasing, selling, and / or other interests

  as appropriate, depending on the type of content.

  These specifications are done by giving values to attributes that the system takes into account when selecting directories (Specialists and Neighbors) that it proposes to the user, as well as to select the content of the latter if necessary. (see "Detecting Close Directories", "Suggestion of Links Added by a Site Administrator", "Publishing Directories" and

  << Proposal of Directories Specialists and Neighbors ").

  2 5 The user who accesses a page (current page), can specify criteria on these attributes to restrict all the directories (Specialists and Neighbors) which

  are proposed in relation to said current page.

  Thus, if for example he is interested in buying the product presented in the current page (or in a set of pages that he selects), he can be interested selectively in user directories: interested in selling this product ( looking for suppliers of this product), - or interested like him to buy this product: he will be able to join the group of users interested in this purchase and increase the influence of this group to lower the price of the product at a supplier , possibly using an automated procedure (help with bulk purchasing) that triggers when this criterion

is used.

  In the first case the user will receive, from the directories of sellers thus selected, links in suggested mode concerning particular offers for the product presented in the current page as well as on other products proposed by

these sellers.

  In the second case, the user will benefit from the discoveries of the other users

  (potential buyers) with close interests (and / or tastes).

  It should be noted that users of the system are anonymous and can access them in

using a pseudonym.

  A particular implementation of this aspect of the invention will now be described.

  Only two attributes are implemented: "Applicant" and "Offerer".

  When accepting a link, using the interface illustrated in Figures 55b and 66 (which in particular allow it to change the mode of the link from "suggested" to "accepted" or "frozen"), the user has two "checkboxes" at his disposal,

  know: "Applicant" and "Offerer".

  This configuration is illustrated schematically in Figure 84b.

  It will check "Applicant" if it is positioned as the applicant, and "Offerer" if it is positioned as "provider", vis-à-vis the "thing" presented in the current page. are not exclusive: it can be

  position both as an applicant and as an offerer.

  The system stores the value of these two attributes for each link in the personal canvas of each user. He can thus take it into account in the process of

  selection of directories to offer to users.

  To operate the selection of directories proposed in the first two lists ("specialists" and "neighbors", see Figure 55a) according to these two attributes, the user has two other check boxes "Applicant" and "Offerer" to his disposition.

  These two other checkboxes are checked by default.

  By unchecking "Applicant", the user specifies that he is not interested in visiting the directories that are positioned as the requestor in relation to the thing presented in the

current page.

  Similarly, by unchecking "Offerer", the user specifies that he does not wish to receive links from directories positioned as an offerer with regard to

  the thing presented in the current page.

  2 5 These attributes may have a broader interpretation than buying and selling. For example, the attribute Vendor can be used by the user to inform about his own characteristics: the user can for example check the offeror attribute on a page presenting a film actor who looks like him, in the hope of being able to to contact, by means of the system (for example by videoconference), with a user who appreciates this actor as it is presented

in this page.

  In the case of the bulk purchase application mentioned above, the system will offer the user neighbors who are "applicants" of the product presented in the current page viewed. The user can then interact with these users by computer-assisted means, in synchronous communication (instant messaging, etc.) or asynchronously (forum and electronic mail augmented with special semi-automatic means to facilitate the coordination of group purchasing, especially

  to negotiate prices with the Offerors).

  Section 14 - Custom Pages Restructured documents as described in the previous section are used to present, in containers, contents selected according to the interests of the user. We will now describe a way that can be

made this selection.

  First of all, remember that any content accepted by the user in a container adopts the category of this container (as described in particular earlier in this chapter and as will be discussed in Chapter III), in addition to categories of other containers in which the user has also accepted this content

where appropriate.

  Because the system knows the categories of containers nested in content that is the subject of a request, it can automatically enrich the query with additional criteria. Indeed, the system is able to determine that for a certain number of contents of each of said categories, there are other categories that have been assigned by the user to these same contents. The principle used here is to exploit these other categories by using them as additional criteria (or more precisely as "preferences") to enrich

  Automatically the request formed by the user.

  For example, in a content that is the subject of a query, there is nested a container category "guitar", and the user, a number of contents of this category also have the category "object of art. "So we exploit the fact that a priori, in this container, the user will prefer to receive (by the suggestion process described elsewhere) content that not only have the category" guitar ", but also the category" piece of art ". Thus, for the category container "guitar", the request of the user can be enriched by the additional criterion: category = "art object". It will be observed here that, if there is no content belonging to these two categories simultaneously, the system then proposes to the user the contents belonging simply to the "guitar" category. The

  an additional criterion will thus be taken into account as a "preference".

  It is therefore understandable that the contents are selected by the system in a "personalized" way, that is to say taking into account the potential centers of interest of

  the user for the containers in question.

  In addition, categorizations made by users can "go back" to the administrator of a site as categorization suggestions for the contents in question, so as to modify the XML structure of the page considered if the administrator judges it timely. The self-purification process described in detail in the following chapter will automate, to a certain extent, the filtering

  Categorizations considered qualitatively bad or unreliable.

  Chapter III - General Suggestion Process (Figures 85 to 134) This chapter aims at a different framework for the suggestion process described earlier in the last sections of Chapter II as well as different extensions of this process. This process will be described below at increasing levels of functionality and sophistication. We will first present (Section 1) the basic structures and processes of each level. The presentation of each level builds on the previous levels. In Section 2, we will describe the additional methods of filtering by learning the reliability of the information. Section 3 presents the principle of automatic suggestion by comparison of interests, and section 4 presents an improvement of the automatic suggestion mechanisms which exploits the advantage of the graph of derivations between utilistaurs. Then, the methods of reinforcing the anonymity of the Users and the possible economic models are presented (Section 5). Finally, Section 6 presents the exploitation of the derivation / suggestion / acceptance mechanism described in the first section.

  user retention by exploiting their collector fiber.

  Section 1 - Fundamental Structure and Processes A. A brief reminder of the UML notation Consider the schematic hierarchical structure below: Contant-1 Contents Content-1 Content-2 Sub-Containers Containing-11 Contents Sub-Containers Containing-12 Containing 2 This hierarchical structure is specified in Figure 85 of the drawings which is a class diagram according to a known standard of Object Oriented Modeling, noted UML (see in particular "UML Reference Manual" - Rumbaugh, Booch, Jacobson, 1999). It is a tree hierarchical structure of Elements ("Elt"), each Element being a "Container" or "Content", the Containers may contain Elements (these are their Sub-elements <"SousElt"). ), while the Content does not

may not contain elements.

  The users of the system according to the invention use such a tree structure of Elements. B. Basic Implementation (Level 1) All System Users use the same Container structure. But, in the same Containers, each User groups Contents that can

  to be different from one User to another.

  All Contents of all Users - except Confidential Contents (see below) - are grouped in their respective Containers in a Database.

  Common, denoted << BD >>, accessible by all Users.

  Here is called "Profile" all the Contents of a given User for a

Container given.

  The corresponding class diagram is shown in Figure 86.

  3 0 The system described here offers for the Users a guarantee of anonymity: thus a User can not access the Profiles of another User (the Profiles are confidential), although he can access all the Contents (non-confidential )

  since he can consult the whole of the Common Database.

  In other words, the Common Database stores, in each Container, the union of User Profiles for that Container, without allowing any

distinguish the Profiles themselves.

  From there, a User is unable to determine in which Profiles is referenced a

  Given content that he accesses in the Common Database.

  This organization is shown schematically in Figure 87.

  When a Content is modified by a User (of course, provided that he has the right to do so, for example if he is the creator of that Content), the other Users, having that Content in their respective Profiles, see it. automatically updated as soon as they access the Commune Comic for the first time after the modification. The User can consult the Common Compendium. It can subscribe to it to be automatically informed about the addition of Content in some of the Containers, selectively (for example by using the power of expression of a traditional query language to a Database). The fact of being informed automatically is what is called a "suggestion process", which will be given

  more details later.

  We will now describe a number of possible features offered to Users. a) Adding and Deleting Direct Content The User can choose to add in one of his Profiles: * Contents that he has drawn from the Container related to this Profile * Content that he has drawn from other Containers * or new Content that did not exist in any Container

  (which he would for example have collected by browsing the Internet).

  Regardless of where it comes from, if Content added to a Profile did not already exist in the Container linked to that Profile, it is added. Other users can then

read it.

  It should be noted here that, in practice, Profiles may not be directly composed of Contents, but References to them, or a mixture of Contents and References to Content. Figure 88 illustrates the associated class diagram, which includes in particular a link between Content and Reference to Content). In a Profile, a Content may have one of three attributes, namely "Suggested", "Accepted", or "Rejected." "Suggested" Content means that Content is received in the Profile, without so far have been accepted or rejected by the User who has this Profile, the Contents in this state are not permanently stored (ie a Reference is not yet created

in the Profiles DB).

  "Accepting" Content means that the system permanently creates a Reference to that Content, and the Accepted Content is permanently stored in the Profile, so it is to be observed here that acceptance as defined herein

  chapter corresponds to the "Frozen" mode described in Chapter II.

  Content whose presence in a Profile is "Denied" can not be deleted directly in the Container (ie in the Common Database, where the Content is actually stored), as that Content may previously have also been Suggested or Accepted in another Profile. It can only really be deleted when no other Profile contains a Reference to it. In the meantime, it is the "Denied" attribute that materializes the virtual deletion desired by a User. The Reference with this attribute is however permanently stored and is used to avoid resubmitting Content that

has previously been "Refused".

  b) References to Contents of other Containers or External Content (Indirect Content) In a particular embodiment, the system may allow Users to insert into a Container (via their respective Profiles), a Reference to a Content already belonging to another Container. This is preferable to inserting a copy of this Content. Of course, this Reference can only exist as long as the Referenced Content exists. We call this reference "Indirect Content",

  and the Referenced Content is called "Direct Content".

  Advantageously, with each new access to the Common Database, in the case where the Direct Content has meanwhile been modified, the User sees, through the Indirect Content, this Content in its new version. The class diagram

  Associated UML is illustrated in Figure 89.

  Deleting Direct Content implies first to manage the Indirect Content linked to it. They will not have any more to exist, but as explained previously, they will be able to be effectively removed only when no more profile will refer them. The deletion of a Direct Content will therefore consist of 3 2 5 types of actions that did not necessarily occur immediately: (1) deletion, in Profiles, of References to Direct Content and Indirect Content related to it, ( 2) removal of these Indirect Content,

  (3) removal of the Direct Content itself.

  A User, who has referenced in his Profile an Indirect Content for which he is notified of an upcoming deletion, may wish to create a copy of the Content

  Direct referenced instead of Indirect Content, so as not to lose information.

  The system can be designed to give him the possibility.

  Indirect Content may also be references to content

  external to the system, including links to items found on the Internet.

  The system then comprises means for updating (or error management

  access) when deleting external content.

  c) Popularity of a categorization The fact of inserting a Content into a certain Container (via a Profile) amounts to "categorizing" it. A Container is indeed supposed to group together Contents of the same

category.

  Different Users may classify the same Content in different Containers, directly (by making a copy) or by means of a

indirection (Indirect Content).

  Here we call "Popularity" the number of times that a Content is found in Profiles associated with the same Container, or more generally a variable representative of this number. In the case where the User hesitates between two possible categorizations, he will generally prefer the most popular Container, in order to "speak the same language" as the greatest number of Users and thus benefit from profile matching services. and other benefits such

that we will describe them later.

  The essential advantage of this basic embodiment of the invention can be summarized by the following, with reference to FIG. 90: first of all, a User A, for his own categorization and storage needs information (this is a sufficient incentive), over time add to its own Profile A new Content, in Containers representing shared categories; - by using these Containers, the User "speaks the same language" as other Users and thus benefits from additional advantages (such as the automatic suggestion of information by profile reconciliation, etc., described in the subsequent sections) in exchange for the fact that it contributes to the Comune BD - the BD Comune is thus fed automatically and transparently, and another User B can consult it or be automatically and spontaneously informed about its enrichment; - each User can be in situation A or B; the fact that a User contributes to the Common Database does not deprive him of his privacy because he can remain anonymous; - Finally, the economic model described in the last section makes it possible to reward those who contribute more to the comic strip that they do not consult, and to sanction the opposite. Even more summarized, the individual advantage of being able to organize information (discovery by everyone), according to shared categories, is an incentive that pushes each User to contribute to a comic that is common to

all the users.

  C. First Development (Level 2) According to this first development, not all Profiles are necessarily confidential. We distinguish between Users who want to publish some of their Profiles (or one or more subsets of their Profiles) to others (or some others), as opposed to Users who use the system only

  for their personal organization of information.

  More exactly, we distinguish the Profiles (or subsets of Profile) that are published to the set (or a subset) of other Users and name them

"Non-Confidential Profile>".

  We will now describe a certain number of functionalities authorized by this improvement. a) The Derivative Concept Users can "Derive" a Non-Confidential Profile, ie import it and use it as their own Profile (Confidential or not) and in

remove or add Content.

  By this is meant that the Added (or Accepted) Content in the Source Profile is automatically Suggested in the Derived Profile and that the User of that Profile is

  So can accept all or part of it.

  By "removing" it is meant that the User may refuse certain Suggested Content Finally, the User may also add: * References to Content, or

  References to References in other Profiles.

  New Contents (Direct or Indirect) are then added to the DB

  Common in the Container related to the Derived Profile, if they were not already there.

  A class diagram relating to the structure of such a system of derivation of

  Profiles is illustrated in Figure 91 of the drawings.

  It is observed that a Derivative and Non-Confidential Profile can be derived in turn by another User. References between Profiles can be cascaded

  to finally reach the Content in the Common Database.

  Optionally, a Derived Profile can be merged with an already existing Profile

  (whether the latter is Derivative or not) and adopt the Container of the latter.

  As a result, a Profile can be derived from several Profiles.

  b) Link Profile-Content The same Reference can at the same time be in the Added state in a Profile and in the Refused state in another Profile. We must then introduce an intermediate object "Link Profile-Content" (or link) to specify this state. Thus, the same Reference may have a link added with a Profile and a Suggested link with a

other Profile.

  The status of a Profile-Content link can be "Suggested", "Rejected", "Added", or

  << Retired >>. This will be specified later.

  c) Archive One can also introduce a function of "Profile Archive", which serves as a stage

  intermediate before the effective deletion of a Reference in a Profile.

  A Reference R can be Retired in a Profile P I while in a Profile P2 it is referenced in Added or Suggested mode. In this case, when R is removed from Pl, it is placed in the "Profile Archive" linked to P1 and can only be effectively deleted when no more profiles refer to it in the same mode.

Added or Suggested.

  In other words, when a Profile-Content link changes to the "Retired" state, if there are other references to the Reference in question, the Reference is released from the Profile and links with the Archive of that Profile, and if no reference exists on it, it can be suppressed effectively (subject to the possibility of cancellation of the action by traditional methods). Thus a "Bypass Counter" attribute can be provided to store the number of References Suggested or Added on the Reference in question. The Reference can be deleted from the Archive when the Derivative Counter value

goes to zero.

* d) Suggestion method The suggestion is the communication process between Profiles. By this process, the Contents 5 propagate: * either automatically - from a Profile to its Derived Profiles, - and conversely, from Derived Profiles to Source Profiles * or "manually">, by submitting Content to one Profile to another

Profile.

  We will detail below these different modes of propagation: i) Propagation of a Profile to its Derivative Profiles The References added in a Profile of a User UB, which Profile is derived by a User UA, are by default automatically suggested to UA, as

Figure 92 illustrates this.

  The result of the suggestion is materialized by a Suggested Derived link as shown in Figure 93. This link is not made permanent, in that it does not exist

than on the client computer.

  In the case where the owner of Profile A accepts the suggestion of the Content pointed by R, there is no need to suggest R again for each connection, because another

  Reference R 'pointing to R is created, as shown in Figure 94.

  The system will then use the fact that the state of the link Suggested Derived is Consulted (the link is stored permanently on the server) not to suggest again

  this Content at the next login of the User on this Profile.

  ii) Propagation of a Profile Derived from its (or its) Profile (s) source (s) The References added in a Derivative Profile are automatically suggested to the owner (s) of the Profile (s) of origin. Of course, this (or these) last

  can not accept or reject them.

  The scheme of Figure 95 illustrates the communication from UB to Uc via the UA Profile,

  The UB and Uc Profiles having been derived from the DU Profile.

  The result of the automatic suggestion of Profile B to Profile A is materialized by a Suggested link, as illustrated in Figure 96, which is not permanently stored: In the case where the owner of Profile A accepts Reference R, it is no longer necessary to suggest it again with each connection, because another Reference R 'on R is created. To enable this, the Suggested link is made permanent. This is illustrated on the

Figure 97.

  iii) Referencing (Manual Suggestion) In contrast to the automatic suggestions mentioned above, Referencing is explicitly requested by the User. It consists of "re-categorizing" a

  Content in another Container and leads to the creation of Indirect Content.

  A Profile-Content link of Referencing Suggestion has the same behavior

  that the Profile-Container links of Automatic Suggestion (already mentioned above -

  see also the specifications of state transitions below).

  The result of the suggestion of Referencing Profile B to Profile A is materialized by a Suggested link as shown in Figure 98, which is made permanent (unlike the previous examples): It should be noted that by going back the link Suggestion of Referencing, we can

  find the Profile in which the Content in question has been referenced.

  In the case where the owner of the Profile A accepts the Reference R, it is not necessary to suggest it again at each connection, because another Reference R 'pointing

  on R is created, as shown in Figure 99.

  Note on the types of links Profile-Content The Contents (more precisely References to Contents) located in a Clean Profile or in a Derived Profile have links with these Profiles which can be

2 5 different.

  Thus the Clean Profiles can have: * Created links (links with new Direct or Indirect Contents), * Derived links (links with Contents derived from other Profiles) or

  3 0 * Suggested links (links to suggested Content).

  Derived Profiles may have: * Created links (links with new Direct or Indirect Content), * Derived links (links with Content derived from other Profiles) * Suggested links Derived (links with Contents belonging to Source Profile) or

  * Suggested links (links to suggested Content).

  The class diagram illustrating these different types of links is illustrated on the

Figure 100 of the drawings.

  Note on the Transitions of links We will describe below the different transitions appearing for Created links,

  Derivative links, Suggested links and Archive links.

  at. Transitions of Created Links (Figure 101) 1. Creation of a Reference (new Content, Content taken from the associated Container or another Container) 2. The User wants to delete it, it is first put in Archive (effect: link Archive transition 1) 3. Put in the Profile a Retired Reference ("effect") (effect: link Archive transition 2) 4. In case the Derivative Counter falls to zero, the Reference can be effectively deleted. (Also deleted in Archive - Transition 2) as well as

his link.

  b. Transitions of Derived Links (Figure 102) 1. Either a Reference is ("manually") derived from another Profile, or a suggested Reference is endorsed. At the same time, the corresponding Suggested link (the

  where appropriate) moves to Consulted (Transition 5).

  2. The user can then remove it. In which case it is first put in Archive (Link Archive Transition 1). The corresponding Suggested link (if any) remains in Consulted.

  3. "Restore" (return of the Archive), Transition 2 for the Archive link.

  4. In case the Derivative Counter falls to zero, the Reference is effectively deleted and so is its link (also deleted in the Archive: Transition 2). At the same time, the corresponding Suggested link (if any) is

deleted (Transition 4).

  c. Suggested Links Transitions (Figure 103)

  It will be noted first of all that the Suggested Derived link is a special case.

  1. A Profile receives a Reference (a Content is suggested). The Suggested link in the Suggested state is not stored permanently, except in the case of Referencing (since in this case the suggestion does not result from the derivation of the

  2 0 Profile and is therefore not redundant information).

  2. The user refuses it or adds it (if it adds it: transition 1 of the Derived link). The Suggested link is then stored permanently (in the Consulted state). The system will thus be able to avoid suggesting this Reference again at the next connection 2 5 3. "Restore" The permanently stored link is simply deleted in the Profiles DB, except in the case of Referencing.

to be suggested again.

  4. The source being effectively deleted (link Archive - 2), its link is removed.

  If it exists, the corresponding Derived link performs Transition 4.

  d. Archive Link Transitions (Figure 104)

  1. Reference placed in Archive (cause: transition 2 of Created and Derived links).

  2. Archive link deleted, either because the Reference is restored (transition 3 of the Created and Derived links), or because the Derivative Counter falls to zero (no other Reference points to the Reference attached to this link), in this case

  Transition 4 for Suggested and Derived Link or Created Link.

  iv) Archiving and Restoring Let us start from the situation illustrated in FIG. 105, in which a Profile A has a Reference R 'on a Reference R of a Profi! B. When the reference R 'is Retired it goes into Archive, as illustrated in Figure 106. But as soon as no more Reference points to it (as soon as the Derivative Counter of R' goes to zero), R 'can be actually deleted. This is illustrated

in Figure 107.

  This first refinement of the present invention has, besides the advantages of the basic embodiment, a whole series of additional advantages, and mainly the fact of being able to derive Profiles, and thus to benefit from "communication channels". Automatically between Users: More precisely: - whereas in the basic embodiment, the User could consult the Compositers of the Common Comics and subscribe to (be automatically informed of) their new Contents, the first improvement allows to the user to consult and subscribe to the Profiles he has derived, thus exploiting the expertise (of selective grouping and categorization of information) materialized in these Profiles, the diagram of Figure 92 illustrates that a Content, added by a User UB, is communicated to a User UA automatically via their respective Profiles, thanks to the fact that the Profile of UA (Profile A) is derived from elui of UB (Profile B), ie References added in a User-UB Profile, which Profile is derived by a UA User, are by default automatically

communicated to AU.

  - The References added in a Derived Profile are automatically suggested to the owner (s) of the Profile (s) of origin. In the event that the registrant (s) validate them, his (their) own Profile (s) is (are) enriched with these Contents, and, in accordance with the above , these are then automatically propagated to other Users who have derived the same Profile (s) and subscribed to it; the diagram of Figure 95 illustrates the communication from UB to UC via the UA Profile,

  The UB and UC Profiles that were derived from the UA Profile.

  - finally, thanks to the functionality of Archive, a Content derived in a Profile remains

  living even when the original Content is deleted.

  D. Second Improvement (Level 3) According to this second improvement, Users no longer share a common structure of Containers. In other words, each user can have a structure

  of Containers different from those of other Users.

  These Container structures are stored in "Personal Databases (DBs)" of the Users and not in the Common Compendium, which does not exist

  Plus 5 as such but as a set of files ("Containers").

  In the same spirit as the above, a Personal DB is composed of References rather than Containers and Contents themselves. In fact, for each Container, all the Contents (except those which are confidential) are stored outside the Personal DB in a common file ("Container") In the Personal DB, the references to these Contents form a "Profile." Some of these profiles may be published to all or a subset of the others

  Users (Non-Confidential Profiles - see above).

  Profiles contain Sub-Profiles and thus form a tree structure shown in Figure 108 (or a graph structure), which may be different

from one personal comic to another.

  Primitively, this structure can be represented by a diagram of

  UML class, as shown in Figure 109.

  Here again, the system offers a guarantee of anonymity: The Users, for a given Container (accessible through a Profile of their Personal DB), can consult (or subscribe to) all the Content added by the other Users in this Container. , without being able to determine which Content is in which comic strip

1 5 Personal.

  Here, two Profiles associated with the same Container may have a different name. The name of a Profile is called "Category". Since the Category of a Container depends on the choice of the User, the Category class is associated with the

  "Profile" class (or an attribute thereof) and not the "Container" class.

  We will now describe how the tree is built by each User, that is to say how the different SubContents are created in

  Profiles, as well as the incentive that exists for a User to derive a Profile.

  a) New Container The User can freely create a new Container, as a sub-profile in a Profile of his Personal DB. If it is Non-Confidential, it will result in a new file (Container-l) in the Common Part, as shown in Figure 110. b) Existing Container Alternatively, the User may derive a Non-Confidential Profile from another User or Profile from his own Personal Comics. This Profile is added as a Sub-Profile in a Profile of his Personal DB that he has chosen (for example, he has inserted the Derived Profile into this Profile by the "drag-and-drop" technique). The elements (Contents and Sub-Profiles) that the Source Profile contains are

  automatically suggested in this new Sub-Profile.

  It should be noted here that deriving a Profile does not automatically generate the derivation of the entire underlying structure. In other words, sub-profiles are not automatically derived, but only if the user explicitly adds them. Indeed, in the opposite case, the process of derivation could enter a

infinite loop.

  c) Inciting the User to derive a Profile i) Link Profile-Profile Created The User can decide to derive a Profile following his consultation, on his own initiative, Profiles (non-confidential) made available by other Users . ii) Suggested or Derived Profile Profile Link Using the top-down suggestion process mentioned above for the first refinement, the new Sub-Profiles added in a P1 Profile, from which a

  Profile P2 was derived, are automatically found in P2, in suggested mode.

  Conversely, thanks to the upward suggestion process, a new SubProfile added in P2 is suggested in Pl. When a new SubProfile appears thus,

  the User can ignore it (this is the case by default), keep it (add it) or refuse it.

  iii) Profile-Profile Link Reference ("Manual Suggestion") This process is called "Referencing." An AU User may, on his / her own initiative, suggest an IR Reference or a P1 Profile to a UB User, so that derived as Reference Rl 'or profile PI' under Profile P2 (No

  Confidential) of the UB Personal Comics.

  These different links appear on the class diagram of Figure 1 1.

  In addition to the advantages mentioned above with regard to the basic embodiment and the first improvement (levels 1 and 2), this second improvement of the invention adds other advantages: - firstly, different users can have a different structure of Containers; the User is thus master of the categorization of his data and is not constrained by a fixed common structure; in this new framework, the system: * always exploits the fact that Containers are shared (advantage of level 1), and * allows derivations not only of Contents but also of structures

trees of Containers.

  - Then, the derivation of Profile or Content can be done, not only by the initiative of the User who derives, but also by the initiative of another User who wishes that his Profiles or Contents are derived in a Profile (Referencing mechanism) and for this reason suggest them "manually" (by

  opposition to automatic suggestions described above.

  This last advantage is considerable; thanks to Referencing, the system can expand and see its User Community increase ever more, * without any real risk of "pollution" because of the introduction of poor quality information. Indeed, although such information can actually be introduced into the system, the number of users who access it will not be significant. Because in order to be widely accessed, they should be referenced in "wide audience" public profiles, that is, known by a large number of users and widely consulted and / or derivatives. However, the owners of these Public Profiles are not obliged to accept a Referencing suggested by anyone and can filter it. They will thus filter the bad information under pain of devaluing their own image and the trust of their "audience". Users of the system therefore play the role of

  decentralized "moderators". The system is thus self-regulated.

  E. Third Enhancement (Level 4) This third improvement consists of an evolution of the second to take into account the assembly, in a User's Profile, of several sets of

Contained for the same Container.

  According to this improvement, Level 3 Profiles are replaced by "Workbooks". A Workbook is associated with a Container and contains (zero, one or)

  several "Pages>" Each Page brings together a set of Contents.

  2 5 A workbook contains pages and sub-folders.

  The tree structure is thus represented in the form of a hierarchy of

  "Workbooks" as shown in Figure 112.

  Workbooks, Pages, and References can be derived. The Profile- links

  Content is replaced by Link-Page and Page-Content links. The Profile Archive is replaced by a Global Archive for each Personal Database.

  This structure is specified by the class diagram shown in Figure 113.

  The Binders and Pages (Non-Confidential) of a Personal DB may be derived from another Personal DB, or even from another location in the same Personal DB.

  The benefits of levels I to 3 remain here.

  We will now describe a practical application of this third improvement.

  A User has a basic workbook that is "clean", in which he can perform various actions, and in particular: a) Creation of sub-elements "specific to the User" The User constitutes his workbook of his own Sub -Classeurs, Pages and Layers (we will describe these last two objects in the following) thanks to a document editor

integrated into the system.

  b) Creation of "derived" sub-elements 2 5 The User inserts in his workbook elements recovered in other workbooks. c) Deletion of sub-elements "specific to the User"

  3 0 The user deletes his own items.

  d) Acceptance or Refusal of "derived" sub-elements The User makes visible or not the "implicit" sub-elements of the "derived" elements, ie the sub-elements of the elements recovered in other workbooks. This information is stored in a database, for example of the SQL type,

  as shown in Figure 114.

  It should be noted that REFLement, REFstyle, REFcontenu referencing fields are here "url" type addresses. The pages to which one points thus return the desired code, and in particular the data of Content in HTML format, the data of Workbook in XML format, etc. As can be seen in FIG. 114, binders, pages and layers are "elements" linked hierarchically by "link" tables. their definitions are distinguished only by an attribute on average (IDcontaining by a workbook, REFstyle

  for a page, IDcontent for a layer).

  In this context, examples of actions will be described below.

  a) Prologue: creation of User Before any action of the User, it is necessary that this one is defined. His existence

  2 5 is written in a "Users" table, as illustrated in FIG.

  (Note: when creating a new User, we also create a "Base Workbook" and an item for "Archive" (special type element for storing

  all items being deleted, as described above).

  b) Action 1: "User-specific" element / sub-element creation Figure 116 illustrates a hierarchical structure of Workbooks and an associated Table,

  for a given User (here User No. 1 called "Demo").

  The different "elements" of the Table in Figure 116 are "clean" to this User, in that they do not refer to any other element (the field

  "REFelement" is always equal to the value "Null", that is empty.

  There are 3 types of elements, recognized by the value of the variable

Type of Table in Figure 116.

  i) Filing cabinets (type 1) In this example, the elements Nos. 1 and 2 (that is to say, whose IDelement values are respectively equal to 1 and 2) are Workbooks called "Demo 0" and "Demo 0 1", the Workbook No. 1 being also the Workbook Base

the User in question.

ii) Pages (type 2)

  In this example, the elements Nos. 3 and 7 are User Pages.

iii) Layers (type 3)

  In this same example, the elements Nos. 4 and 5 are User's Layers.

  The kinship relationships are listed in a "Links" Table, as shown in Figure 117. This Table shows that Item No. I (<"Demo 0") is the Parent of Elements Nos. 2 and 6 ("Demo 0 1" and "Demo 0 2") c) Action 2 creation of element / sub-element "Derived" Figure 118 shows an example of a tree structure of workbooks including

  a "Derivative" workbook (named here "Favorite Aline"), and the associated Table.

  A derived element results from the retrieval of an element by a User other than its original designer. It is a "clean-up" element to which is

  added a reference to the original element.

  The example in Figure 1 18 shows that item No. 9 ("Favorite Aline") is derived from

  of element No. 2 ("Demo 0 1"), because the value of REFelement is here equal to 2.

  The Binder No. 9 then implicitly has the sub-elements of the binder No. 2.

  These sub-elements must be Accepted or Refused (see Action 4 below) so that Users who derive Workbook No. 9 do not see or see them,

depending on the case.

  As in a "user-specific" element, the user of the derived element can add or subtract other elements according to his choice; his additions and

  deletions will be suggested later to the author of the original element.

  (Note: When a user creates a "derived" element (as here the "Favorite Aline" workbook), the derivation counter of the original element (counter variable "is automatically incremented (as here for the workbook"). demo 0 1 ") This allows you to know if the deletion of the original is possible or if this

  The original must be archived when its author hides it.

  d) Action 3: Deleting "user-specific" elements i) Deleting a "clean" sub-element not derived Consider the example where the user "demo" wishes to delete the sub-element " Demo 0 2 ". According to the Derivative Counter, it is used as a reference by no one. We can therefore delete the link between "Demo 0" and "Demo 0 2>", but also delete "Demo 0" and all its sub-elements whose value of the Derivative Counter is zero.

  The result of this deletion is illustrated in FIG.

  ii) Deleting a "clean" sub-element derived at least once Consider here the example where the user "demo" wishes to delete the sub-element

"Demo 0 2".

  However, according to the value of the Derivative Counter, it is used as a reference by another workbook (in this case the "Aline favorites" workbook). So we can remove the link between "Demo 0" and "Demo 0 1", but we can not delete

the element "Demo 0 1" itself.

  Therefore, it is then related to the user's "Archive" folder (so as not to generate an orphan). He will stay there until the value of

  Derivative counter drops to zero.

  The situation is illustrated in FIGS. 120a to 120c. Thus figure 120c shows that element n 2 (Idenfant = 2) no longer really belongs to element No. I (Idparent =

  2 5 1), because its "Operation" attribute is set to zero.

  This same element is however added to the element "archive" n 12 (Idparent =

  12) of the User, of which he becomes a sub-element.

  The fact that this sub-element is attached to an item "archive" will still be able to view it if necessary restore it at the initiative of the user,

as we will see below.

  iii) Restoring an "archive" sub-element To restore an "archive" sub-element, the user consults the "archive" element and designates the sub-element to be restored, simply replace the "0" element. by a << + >> in the "link" corresponding to the sub-element, then delete the link

  between this element and the "archive" element. This is illustrated in Figure 121.

  It will be observed that one could also archive the deleted elements whose derivation counter is zero to allow their restoration ... In this case, the "emptying" would be done in the same way as with the "trash" d a file explorer. However, the elements can not be "drained"

  their derivation counter is non-zero.

  e) Action 4: Acceptance / Refusal of "implicit" sub-elements The derived elements implicitly possess the sub-elements of the element

- original.

  Thus, at each opening of its derived element, the user will see appear and disappear sub-elements at the discretion of the user of the original element. Thus figure 122 illustrates the case where a file 9 n "Aline favorites" (Idelement = 9) is

  derived from a binder n 2 (REFelement = 2), and thus implicitly possesses the sub-

  elements of the latter, such as the elements illustrated in Figure 123, whose

Idparent variable is equal to 2.

  We will describe below how these sub-elements can be Accepted or Refused. i) Acceptance of an "implicit" sub-element The User must accept an "implicit" sub-element (sub-element of the original) in order not to risk seeing it disappear and to propose it to Users who derive or who derived in turn the derived element (for example, if in

  the above example a third user creates a workbook derived from workbook # 9).

  The acceptance of an "implicit" sub-element is in fact a derivation of this sub-element.

  element in the derived workbook. In database, this amounts to creating a

  derived workbook and to make it a child of the derived element.

  Example of acceptance of the implicit subfolder "Demo O 1 1" Figure 124 illustrates the creation of element n 15 derived from n 13, namely "Demo

  0 1 1 ", and Figure 125 illustrates the creation of the relationship between the elements.

  The User expresses his interest to the original author for this element. In addition, the original author will be able to suggest further additions and retrenchment of sub-elements. ii) Refusal of an "implicit" sub-element The User must refuse an "implicit" sub-element (sub-element of the original)

  when he does not want to see it reappear with each opening of his binder.

  The refusal of an "implicit" sub-element is in fact a special relationship between this sub-element and the derived workbook, which is used to signify the refusal, so in the database, this amounts to creating a link between the derived element and the sub-element

  with the value "-" in the Operation field.

  Example of refusal of the implicit subfolder "Demo 0 1 2" This particular example is illustrated in Figures 126 and 127, Figure 127 showing

  the value "-" in the Operation field.

  The User thus expresses his disinterest in the original author for this element. In addition, when the original element is actually deleted, this link will no longer be useful

  and can therefore also be deleted.

  It will be noted here that the management of the workbooks and the elements they contain can advantageously be done according to a user interface as illustrated in FIG. 127a. This user interface has two Cadrel and Frame2 overlapping windows or frames on the left, with the Cadrel top frame displaying a tree structure (for example, "Windows Explorer" - trademark of Microsoft Corp.) of the user's workbook, while the lower frame Cadre2 contains, with the same type of representation, the file of a third party being consulted remotely by this same user. It is thus easy to navigate from one Container to another, the contents of the active frame being displayed in a larger frame Cadre3 provided in the right part of the screen. These contents (pages) are displayed with the style imposed by the currently selected frame. Tabs allow

  also navigate the structure.

  This interface allows: - to import from the third workbook, by the "drag-and-drop" technique from the Cadre2 frame to the Cadrel frame, all or some of the Containers (including Associated Contents) or individual contents, knowing that the importation of one or more Containers may involve a procedure of selective acceptance, collectively or individually, of the Associated Content - to propose to the third party, always by the technique of drag and drop, but this time of Cadrel to Cadre2, all or part of its own workbook, to implement the function described above of manual suggestion or "Referencing" - as regards the Cadre3 display frame, a series of buttons and / or tabs is advantageously provided for scrolling pages, changing layers, etc. Finally, it should be noted here that the operations of accepting / refusing suggestions can be done in specific dialog boxes, or when the user accesses a workbook containing newly suggested items since they last logged in, or when the user accesses the Containers for

suggested elements.

  Moreover, these aspects of the invention make it possible to exploit a new "multi-portal" technology on the Internet, which enables: - information providers, such as consumer magazines for example, to create and update their information directly on the Internet, - access to information through multiple entry doors, from which information can be presented in a different way; for example, each magazine can offer access to the multi-portal via its own domain name of "www.telmagazine.fr", to information providers to "retain" the user by playing on his fiber collector; the user can indeed build collections of information in a personal online binder, - to the product suppliers, to offer elements of content describing their products (goods or services): in a few mouse clicks, they reference them in ezines, communicate their novelties and promotions and collect commercial transactions, magazines to turn into mini-directories (such as portals or directories known today on the Internet) and collect a commission on visits and sales generated, - finally, to the Internet users to consult the magazines and the offers of products: they can slide in their personal workbook of the elements of content that they find at each connection, these elements of contents being updated and completed; dragging information into the personal workbook implicitly represents a "declaration of interest" that allows them to be suggested

  automatically related information.

  Thus a new online magazine joining an existing multi-portal will be able to

  exploit the traffic that is already there.

  Section 2 - Self-purification of the System 2 We will now describe in detail a function of the present invention making it possible to take into account the quality of the suggestions in order to achieve, by a notion of "degree of confidence", in limiting the effects of This section is to be compared to the "Probability of Acceptance Coefficients" section in Chapter II, since the level of listing acceptance described in this section of Chapter II is broader than the acceptance at the level of users such

  described in this section.

Introduction

  The system uses a double purification principle.

  First, as mentioned with the "manual" suggestion in section 1 of this same chapter, the dissemination of information between Users can be done by "Referencing" a given User Profile in Profiles (Workbooks or Pages) other users he hopes to capture the audience (including that from other users' non-confidential profiles, the public can find the information specific to said given user). The system allows this in a decentralized way. SEO is a suggestion and can be filtered by the recipient, who plays the role of purifier. Thus, those who provide poor quality information lose their credibility, and tend to no longer be shunted to other users. Their

audience drops so.

  Secondly, the maintenance of credit granted by each User may be automatically assisted by the system. Through self-learning and transparency, based on experience, the system builds and maintains a contribution notation indicative of a "degree of confidence" that a User can grant to

  information provided by another User.

  This degree of trust can be determined indirectly by following a "chain" of Users in which each User has been able to determine the degree of

  trust for the next (ie by transitivity).

  The degree of confidence thus obtained makes it possible to automatically filter the suggestions

  content with a high probability of not being relevant.

  It is important to note here that the identity (or rather the pseudonym) of the User who is at the origin of the suggestion is known to the system but not to the other Users. Details of the self-purification process For each type of action (accept, refuse, move, etc.), it is expected that

  improvement of the invention the use of a contribution notation, that is to say

  to say to a system of attribution of positive or negative points, on the basis that the user B who receives positive points by the user A increases all the confidence that the latter grants him. Likewise, he diminishes his confidence when he

receives negative points.

  User A can thus automatically filter (in his requests) the suggestions

  made by Users whose degree of confidence is below a certain threshold.

  The interest of this function resides mainly in the fact that the evaluation (or notation)

  in the framework of the current use of the tool, in a transparent way.

  For example, following a request, a User A receives Content suggested by a User C that he has not yet had the opportunity to evaluate. In the case where User C has a negative degree of confidence in User B, and User B has a positive degree of confidence in User A, then, by transitivity, User C obtains negative points from User A. The latter can then automatically filter the Content suggested by C. Indeed, User A has confidence in the suggestions made by User B. So if User B believes that the User's suggestions C do not match his expectations, so User A may be confident that he would have the same negative opinion. Concretely, this approach can be based on a data structure including a representation of a graph of transitivity between the different Users (while

  3 0 keeping their anonymity relative to each other).

  Advantageously, this approach can be accompanied by weighting coefficients as a function of the length of the transitivity chain for a given evaluation.

  as well as other criteria and thresholds.

  For example, for User A to be able to rely on User B's judgment regarding User C, the degree of trust that User A has in User B must be above a certain threshold for some time (criterion

stability).

  Thus, the system automatically builds what can be described as a "trusted network", self-powered and self-regulated, which allows to purify selectively the

inadequate suggestions.

  It should be noted here that there is still a risk: a malicious user can register in the system frequently, with pseudonyms each time

  different, with the aim of suggesting poor quality content.

  Since this malicious user was not evaluated by anyone at the beginning, his suggestions

  may be filtered for a period of time.

  To eliminate this risk, recent users whose suggested volume of items has not reached a certain threshold, which is called the "contribution threshold", can be filtered out. This filtering can also be used to encourage users to contribute enough so that the content they suggest is not filtered. This prompts us to keep the system alive. The contribution volume of each may be determined by a method that avoids artificially propagated contributions

  to reach the contribution threshold.

  Alternatively, subscribing to the suggestion-based trading system can be paid for, or nominative via a trusted third party, which would discourage the suggestion of suggestions.

  Contained under different pseudonyms.

  Section 3 - Automatic Suggestion Techniques Introduction Profiles, as described in Section 1, characterize Users and can thus be used as profiles of interests (or tastes) that are confronted with each other to extract relevant information and suggest

automatically to Users.

  The confrontation of a profile with the others can be done individually (for example by the known techniques of << Collaborative filtering >>, of "Recommendation on the basis of Contents"), or on the synthesized set of the other profiles of way.

  compact (eg by Bayesian Networks techniques, etc.).

  An important contribution of this aspect of the invention is to take advantage of the order of the Contents in the Profiles to improve the suggestions. If we go to Level 4 of Section 1 of this chapter, the user can order the Contents (which are displayed in a certain order in the pages), and the pages between them (the order of the pages). is displayed in the form of a workbook), according to different order criteria chosen by itself (for example, global preference criterion, temporal criterion, economic criterion, aesthetic criterion, etc.) or an ordered conjunction

such criteria.

  Since these criteria are shared with other users, the system derives ordered profiles, improves the relevance of the recommended elements, inserts the recommended elements in their correct position, and can even automatically order information in bulk based on the order adopted by

  close profiles. These methods are described in the following section.

  Details of Automatic Suggestion Techniques a. Detecting Neighboring Profiles Content is composed of elements (for example in XML format) that have attributes and nested elements. In order to detect, between two given profiles, the Contents that can be considered as "virtually identical", they can be analyzed according to rules that are triggered from a mechanism of

* pattern recognition ("pattemrn matching").

  A Container can thus give different weight to the attributes of the elements of its Contents. One Content will then be considered "virtually identical" to another if a sufficiently representative set of attributes (representativeness will be

  calculated according to their respective weights) have the same values.

  Thus, it is not necessary for two users to have in their profiles

  Content exactly the same to be considered close.

  The proximity between two profiles Px and Py - ordered according to a given criterion - is measured by evaluating the amount of layers that the Users A and B have in common, with a weighting by the position of these layers in the profiles of the Users A

  and B respectively, as illustrated in Figure 128.

  Virtually the proximity measure will be Content by Content as long as the marginal weight remains above a certain threshold. So it will be enough to compare a number

  set of elements in the order corresponding to the given criterion.

  The user can also rely on a number of other indicators such as

for example:

  The percentage of information in common, as illustrated in FIG. 129;

  - the number of times the same Content is suggested (from different Profiles).

  b. Inserting suggested Content that is accepted When a User accepts a Content suggestion from the Collaborative Recommendation system, the Content is ranked in the correct place according to each criterion of the workbook configuration. We will consider, with reference to FIG. 130, the following example: Suppose that for a given Container, Users ul and u36 respectively have the pages ("xSheet") xsA and xsB, whose Contents are ordered.

  each according to two criteria I1 and X2.

  For this category, ul and u36 are close in the sense that they both have the contents c4 and c12. The Collaborative Recommendation system therefore makes the proposals as illustrated in Figure 131, where c8 is suggested from u36 to ul and cl

being suggested from ul to u36.

  If these suggestions are accepted by each User, the Content is then

  inserted in accordance with the positions they occupy in their original page.

  For the criterion II of ul, c8 is classified with respect to the Contents common to ul and u36, it is thus placed before c4 and c12. Of course, ul is free to relocate c8 if he deems it misclassified against the criterion used. Symmetrical reasoning is applied for u36. For criterion X2, the elements common to xsA and xsB are not classified in the same order. Several conventions are then possible: the one that seems the most appropriate is not to violate any relationship established in the initial profile. Thus, c8 must be inserted after c12 and c4 in xsA, and cl must be inserted after c12 in xsB (although it is before c4 in the starting profile). The result is shown in the figure

132.

  Another convention could for example be inserting cl in xsA and c8 in xsB

  relative to the nearest common element, as shown in FIG.

  The insertion of a Content, as described above with cl and c8, causes the update of the profiles of ul and u36 for the upper nodes of the taxonomy (aggregated profiles). The place where the new Content is inserted in the aggregated profiles

  depends on where it was classified when it was inserted, and the criterion used.

  Order Profiles Automatically (Profile Sorting by Collaborative Recommendation) As mentioned before, in a profile some of the Contents have not been

  explicitly ordered. In the leaves, these correspond to gray tabs.

  For each profile, the gray contents that are part of the contents in common with a neighboring profile, but in the unmerged partition at the neighbor's, are ordered according to

the order suggested by this neighbor.

  Section 4 - Bypass Charts Introduction It should be recalled here that the system described in section 1 of this chapter offers the user the possibility of (and stimulation for) deriving and rearranging (add, remove, modify, reorder, move d 'Container to container, etc.) information not declared as confidential. The stimulation comes from the fact that the user thus benefits from the expertise of the whole chain of users "upstream">

  that is to say, the origin of each information.

  The system therefore encourages its Users to extend it (to make it "grow") by derivation, and the Users come to share the same Containers and Contents. The great advantage offered is thus "speaking the same language", both for the information itself (Content) and for their respective categories (Containers). However, to speak a common language (this one consisting of all the Containers and Contents that are in the common part of the system) greatly facilitates the comparison of Profiles. Indeed: - from the Contents, one can find directly (in direct access) the References on these and the Profiles which contain them; - from a Container associated with a given Profile, we can find directly all the Contents accessed by the Users (and thus we can

  find the Profiles that contain them directly).

  The use of the system therefore results in a dynamic "derivation graph", whose nodes are the Profiles and arcs (oriented) are the derivations between Profiles made by the Users. These may be branches of Profiles (derivation of a

  Workbook or Page, if you are at Level 4) or Content derivation.

  The essential idea of this aspect of the present invention is to use the derivation graph between Profiles to benefit from the locality of the comparisons to be made.

between Profiles.

  In this respect, the user interface of the system advantageously comprises a means (button, etc.) enabling a user consulting a given Container of a third-party binder to directly consult the contents designated in the whole of the container of the common part which defines this category without having to navigate

  in the tree, or to move to an Internet portal or the like.

  How to take advantage of the derivation graph between Profiles By relying on the derivation graph (which evolves dynamically during execution), each Profile (that is to say each node of the derivation graph) keeps in memory a list of neighbors within a certain perimeter (at a distance less than a given threshold, distance measured in number of arcs of

  derivation), with for each neighbor, a set of proximity indicators.

  Indicators may be for example those mentioned in the previous section

  or simply Counters of Contents in common.

  In addition, it is possible to incrementally maintain the Proximity Indicators between Profiles: for each addition and removal of Content in each Profile, these indicators are updated for all the neighbors in the graph. For example, with each addition of Content, for each Neighbor Profile that would also have it, the system increments

  the "Common Content Counter" indicator in both Profiles.

  With each withdrawal of Content, the system decrements the same counter.

  Each profile thus incrementally maintains the knowledge it has of the proximity of its neighbors (anonymous of course) and the system can thus perform

  suggestions automatically by Collaborative Filtering.

  The distance threshold can also be adjusted during execution by a learning technique based on a criterion of performance (evaluation of success

  suggestions at different distances).

  It will be observed here that the present invention makes it possible to avoid resorting to extremely heavy calculations of comparison of profiles by their contents themselves, which typically require, when the number of users is important,

  <"batch"> processing of considerable time.

  2 5 Section 5 - Anonymity and Electronic Commerce Architecture An architecture consisting of 4 classes of computers connected on a network is considered here: - at least one client station (for example of the personal computer or network terminal), handled by a User; at least one third-party server (ST), namely a data transfer server (or equivalent device) or a trusted server; at least one Storage Server (SdS);

  - optionally one or more Product Provider Servers (SFPs).

  The basic needs are: - Minimum anonymity: the anonymity of the Users can be directly ensured by the

  or the SDs that centralize the pieces of information collected.

  - Anonymity by trusted third party: alternatively, the anonymity can be achieved by an architecture including one or more additional servers that are managed by one or more trusted third parties (ST) and which are "obligatory passages" during communications in consultation or adding elements; the IP addresses of

  Users who consult the information elements are thus hidden.

  The identity (or pseudonym) of the User adding a piece of information is transformed (coded, encrypted) by the third party server, in a different way to each

  addition (in addition to the fact that its IP address is hidden).

  The correspondence between different transformations of the same identity is known by one or more of the third-party servers, or by one or more third-party servers 2 independent of the first ones (it is they who in particular can derive the degrees of confidence). Third-party servers can be used to provide a certificate to testify to the provision of an information element by a server. This can be used in the

  3 0 different economic models, as will be discussed later.

  Workbooks can also be stored on an SdS storage server. In this case, their links to the non-confidential contents (which form the profiles) will be stored on the SdS storage server after encryption on the personal computer (or an ST transfer server). These links can not be decrypted by the storage server, but only on the personal computer or on the transfer server. Additional needs involved by the. Collaborative Recommendation process is as follows: - Minimal anonymity: The anonymity of the profiles can be provided directly by storage servers which also act as recommendation servers, that is to say who produce the

  profiles, maintain them and confront them.

  - Anonymity by trusted third party: Alternatively, transfer servers can have the role of producing and maintaining the profiles and then communicating them to a storage server after rendering them anonymous, that is, after associating them with a identity

transformed (coded, encrypted).

  Recommendation servers only handle anonymous profiles and

  are unable to detect that two profiles belong to the same User.

  To avoid associating different profiles of a user together, by recognizing the same IP address during their transmission (for example when there is obviously only one user online), it is preferable to use a transfer server 3 0 different per profile (as much as possible, ie to the extent that we have

  a sufficient number of transfer servers.

  Moreover, the architecture described above can be used in the context of e-commerce via the Internet, as will now be described with reference

in figure 134.

  Thus, this figure shows that an SdS storage server containing Profiles is able to make purchase suggestions to a PC user station from the server of an SFP provider via a third-party server ST that allows the user ensure anonymity of users at the Profile level. The actual purchase of a good or service by the User from the SFP server, which corresponds to an acceptance of the suggestion, can be proved by the third party server ST to the SFP server via the server of storage SdS, while the service rendered by the storage server SdS and by the third party server ST is duly remunerated (commission on sale) by the server of the provider SFP (the remuneration $ of the third server ST being constituted by a fraction of the remuneration server's $$$

storage.

  Section 6 - Subscriptions and Retention According to this other aspect of the present invention, it is interesting that a server (for example an electronic magazine) proposes new content, on a periodic basis, for example bi-weekly. At the end of this period, the contents are archived as described above, and are therefore no longer suggested. New content is then put in place. It is understood that this fundamentally encourages the user or subscriber to visit the server at least once in the period of "validity" of the added content (in this case twice a week), so as to

  benefit from all suggestions for additions.

  Thus, the derivation / suggestion / acceptance mechanisms presented in this chapter and in the preceding chapters (see the frozen mode in the previous chapter) make it possible to exploit the collector fiber of the user. Indeed, the user who collects content in a container is strongly urged not to miss an opportunity to enrich his collection while content is still available online. He wants to return to visit the website at the same frequency

  as updating the contents. The user is thus loyal.

  Chapter IV - Deterministic Execution Model (Figures 135 to 169) In this chapter, we will introduce an execution model that will be used in particular in the context of the sharing of applications on the Internet that we will present in the

Chapter VI.

  It is said of a system that it is deterministic if, for the same sequence of impulses passed in, its objects always carry out the same transitions (in the sense of their

state-transition diagram).

  The search for determinism is the result of a double motivation, to ensure the following properties: * To be able to reproduce exactly the same execution: a user expects the application he uses to be reproducible; that is to say,

always the same behavior.

  * Can duplicate an execution between multiple machines using a computational replication mechanism. This point will be detailed in the

  Chapter 3: "Multiuser interactions".

  Ensuring determinism, however, is not obvious for an application consisting of several "active" objects at the same time. We then have objects that evolve in parallel, in what is called a "multithreading" model according to the terminology

  Anglo-Saxon. This approach, while having some advantages, creates

  determinism. In fact, from one execution to another, the occupation of the system can

  vary, and the tasks performed by the objects may take more or less time.

  Such an approach, where each object evolves according to an independent process ("thread" according to Anglosaxon terminology), can not therefore respond to the deterministic constraint aimed at. The solution according to the present invention is based on the arbitration of the actions performed by the objects. To do this, the applications are

  see endowed with a particular object, constituting a Sequencer.

  The primary function of the Sequencer is to guarantee determinism while giving a parallelism effect, we will talk about quasi-parallelism. Indeed, the sequencer makes it possible to give to each of the objects in turn a part of the resources corresponding to the sending of a message (thus the realization of an action). This objective is shown diagrammatically in FIG. 135 of the drawings, where it can be observed that independent actions of four objects A, B, C and D are organized in a determined order, according to a single flow process, allocating in turn

resources to each of these objects.

  Section 1 - Framework We will refer to the notion of the object of the current jargon of object-oriented computing - according to, for example, the book "The Unified Modeling Language (UML) Reference Manual", Rumbaugh, Booch and Jacobson , Addisson

Wesley 1999

  The applications we manipulate here are composed of interacting objects.

  These objects, and their relationships, can be defined using a class diagram

  UML, an example of which is given in Figure 136.

  It will be recalled here that the notion of "Multiplicity"> (for example the number 3 associated with the object D indicates the number of objects of the class that can be created during execution, and that the notion of "Multiplicity"> Role "(for example" theC "in the link between B and D) indicates the name under which an object knows another object, here the object of class B knows the object of class C under the name theC. It is thanks to the name theC, that the object of B can communicate with the object of C. To each object defined (via its class) in a diagram of class, one can associate a behavior by means of a diagram of This diagram describes the behavior of objects of a given class in the form of a machine.

to state.

  Thus, at a given moment, an object is in a precise state. Objects change state

  according to transitions that may (or may not) be caused by events.

  To take a very simplified example, we can model a switch

  ("Switch") and a lamp ("Lamp") as shown in Figure 137 of the drawings.

  According to the model illustrated in FIG. 138, a Switch object, which is in its initial state "Idle", can receive a "TurnSwitch" event which triggers a transition from the "Idle" state to the same state, when from which a "TurnLamp" message is sent to the "myLamp" object ("Lamp" class) .This "TurnLamp" message becomes, for the lamp that receives it, an event triggering a

  transition from "Off" to "On", or vice versa, depending on the state in which it is located.

  Being able to send a "TurnLamp" message to an object of the "Lamp" class implies that this class exposes the corresponding method. The sending of the message amounts to calling the corresponding method. (Note that messages may have arguments like methods). The representation of the

  "Lamp" class with the TurnLamp method is shown in Figure 139.

  Note also that in the rest of this description, we do not treat the

  attributes, because we equate them with objects linked by relations of compositions (that is to say sub-objects), which makes it possible to include them in the general case of the treatment of objects. (Attributes are distinguished from objects in general, by the fact that they have no links with other objects, this does not contradict the generalization here made). For the record, Figure 140 illustrates the equivalence between a class "<< Classel" with an attribute "Attributel (class Class2) >>, and the link between the

  two classes "Classel" and "<Class2".

  Finally, in the remainder of this description, we do not deal with the cases of

  specified on a transition, as these can be transformed into an equivalent form, in which the actions are specified in an intermediate state that has an automatic transition as its only outgoing transition. For the Switch class of

  In the previous example, such an equivalence is illustrated in FIG.

  In the rest of the description, we consider the transitionstructure diagrams of

  the shape shown in Figure 142. The black dot designates a "Pseudo State", which

  symbolizes the initial state, ie the state where the object is located right after its creation.

  An "Event" (here << "eventl" for the transition between OStatus and State1) triggers the transition to which it is associated as soon as the object receives it. If no event is associated with a transition, it occurs as soon as the object has finished executing its actions (it is then called "automatic transition"). Finally the "Actions" (here for example "Entry / theC.evt" are the tasks that the object can

perform in a given state.

  Transitions are seen as snapshots while states usually have a duration. Each state E of an object thus corresponds to a part of its behavior. This part is described by a set of actions carried out by the object in the state E. These actions make it possible to trigger transitions of other objects, by the emission of the associated event. In the example above, B triggers

  the transition associated with the event "evt" at C (identified by the role "theC").

  Within a state, actions can be of two types: * On Entry: These are the actions that the object performs when entering a state. This sequence of actions can not be interrupted in any case, it has an atomic character. * Activity: These are the actions performed by the object once it has entered its new state (so once the atomic sequence of the On Entry actions is complete). This is a set of actions, each action being atomic. The reception of an event associated with a transition may

  counter interrupt this part (between two atomic actions).

  A state may have no On Entry action as it can have more than one.

  is the same for Activity actions.

  A state will therefore be represented as illustrated by way of example in FIG.

  Note that "Do" here specifies actions of type Activity).

  We will illustrate the actions Activity of a state by extension of the example of the switch and the lamp presented previously, illustrated again on the figure

144.

  In this example, and as shown in FIG. 145, the lamp has no On Entry type action in its On state. In the context of the activity part (messages <"Do />") of this state, the lamp sends for example four incrementation messages to a counter ("Counter"), but this activity (composed of these 4 messages) can

  be interrupted if a "TurnLamp" message is received.

  More generally, when it enters a new state, an object performs its On Entry actions, and once they are finished, chain the Activity actions (denoted << Do / ... >>). However, from the point of view of the user, the objects perform the actions in parallel with each other (since the action series Activity can be interrupted). The goal of the sequencing mechanism is to simulate this parallelism by giving the hand to objects that perform their actions

each in turn.

  To meet these requirements, models must be developed in particular ways, as we will see in the following section.

transparent for the modeler.

  Section 2 - Arrangement of Models Canonicalization of Objects To simulate parallelism, the mechanism of the invention consists in scheduling the

  Activity actions of objects using a particular entity, namely a Sequencer.

  To achieve this order, the states are transformed into a form called the "canonical form", as illustrated in detail in Figure 146, a canonical form in which these states are decomposed so that at each action Activity corresponds to a state. The Sequencer is then responsible for controlling the transitions

  between states corresponding to Activity actions.

  However, the transformation into a canonical form must respect the character

Atomic On Entry actions.

  Overall, the transformation into canonical form must therefore respect two constraints preserving the atomic character of On Entry actions: To do this, the On Entry actions are grouped together in a "Sentry" state, as shown in Figure 145. For these actions are not interrupted, the only outgoing transition from this state is an automatic transition. An automatic transition is a transition to which no event is associated. Such a transition has

  therefore place only once all the actions of the state Sentry performed.

  Thus, when the incoming transition is triggered (by another object for example), the object enters the state Sentry. In this state, the object performs all On Entry actions of state S. When all actions are performed, and only when they are, the object enters the state Sactivity. As in the example, the object did not perform any Activity actions in the S state, it is placed in the Swait subreport where it waits to receive an event allowing it to enter the T state or the state U. It will be noted here that, in the following, in order to bring more clarity to the reading,

  we will separate Entry actions in different subreports.

  * allow to establish a quasi parallelism in the execution of the activities of the objects.

  Rather than having a "thread" per object, the activities of all objects can be processed in a single thread: that of the Sequencer. The role of this Sequencer will be to govern the transition from one sub state of activity to another by the emission of

  the next event, for all objects.

  The corresponding canonicalization is illustrated in Figure 146.

  As before, the object enters the state Sentry and performs all the actions there

  On entry provided in state S. Then, the object automatically enters the state Swait.

  We are here in the case where Activity actions were provided in state S. Each of these actions is treated in a different state. We will call them sub states of activity. The transition from one sub state of activity to another is done upon receipt of the next event. It's the Sequencer that emits this event for

  Simulate the parallelism between objects.

  At any time, the object can receive an event associated with one of the outgoing transitions. At this point, the object leaves the state Sactivity (and therefore the sub-state of activity in which it is) to enter either T or U. Role of Swait The outgoing transitions of the state S depart, in the canonical form, from the state Sactivity. Indeed, if they also left Sentry, the shares On

  Entry could be interrupted, supposedly their atomic character.

  This is why once the On Entry actions are completed, the object automatically enters the Swait sub-state of Sactivity. In this state, the object waits to receive the first next of the Sequencer, but can also pass

  to another state if an object triggers one of the outgoing transitions.

  It will be observed here that the canonical form described above with reference to FIG. 146 makes it possible to represent the state diagrams of Harel transitions (hierarchical states and orthogonal states); the transformations of these cases being obvious

  for the skilled person, they will not be described further.

  Notion of history (trace) In order to be able to follow what is happening in the computer system, one can have a history which records all the actions carried out by the objects and associates them

a logical time.

  Before performing an action, an object informs the sequencer by an appropriate message, and the sequencer writes in the trace the following information: * Which object performs the transition * What was the state of the object before the transition (on will call it previous state),

by means of an identifier.

  * What is the "cause" of this transition (either the user user if any, or the object that caused the transition) Note that the conditions specified on the transitions (see UML - Unified Modeling Language, already mentioned ) or in the states, can also be

Noted in the trace.

  This history will play a role in the virtualization process described in the following chapter, as well as in the Rollback mechanism explained in Chapter VI. Let us consider the example of an object O1 illustrated in FIG. 147. The canonicalization will give the result illustrated in FIG. the call to put the Sequencer, illustrated in Figure 148, corresponds to a writing in the history

  with the elements we mentioned above.

  Suppose now that the user creates this object 01. This one will thus enter the state Sentry, and carry out its action Entryl. In passing, the trace will be

  filled in as illustrated in Figure 149.

  In the method call << Put (O1, initial, user) >>, << O1 >> designates the object that makes the transition, "initial" refers to the previous state of the object, while "user" here refers to the object (in this case an action of the user) which is at the origin of the transition (which will be called the "cause"). "54" here refers to the logical time at which the

  message is received by the sequencer.

  The write cursor indicates o must be done next entry in the trace.

  The Sequencer must be able to react to the put event by writing the different information received in the history. The behavior of the sequencer, as regards the management of the history, can then be represented in the way

  illustrated in Figure 150, where H represents History.

  Mutual exclusion of the first cycles - Notion of cycle When an object triggers an event in another (by sending a message to it or by a notification of change of state if the object is subscribed to it, etc), it causes a change of state of the latter. In its new state, this one can itself make change of state to a third object, etc ... This until all the affected objects have completed their actions On Entry (the actions Activity being the spring of the sequencer like we will see it later). The hand is then returned, by return of call of method, to the object which triggered the first transition: one speaks then of cycle. By definition, a cycle is therefore atomic in the sense that it can not be interrupted. A cycle begins when an object O causes another to make a transition,

  and ends when O picks up the hand.

  Thus Figure 151 illustrates an example where two cycles Cyclel and Cycle2 follow each other, the return from the ObjectC occurring as soon as the receipt of "EntryB1" because, if ObjectB changes well state, it has no action to perform. The Cycle2 cycle is similar, with traversing objects ObjectA, ObjectC and ObjectD and

  back from ObjectD which has no action to perform.

  - Concept of the first cycle When one considers all the cycles of an application, one realizes that there exist particular cycles: those which are initiated by the user. We

  in this case will speak of first cycles.

  These first cycles are important because their trigger depends on the user.

  2 5 Their flow is therefore parallel and they can conflict with each other

  the others if they ever go through the same objects.

  To manage this kind of problem, that is to say to avoid having to perform rollbacks (or "rollback" according to English terminology), a mutual exclusion mechanism of these first cycles is necessary. As we will see in the next section, a possible solution is to put them in sequence: they are then treated one after the other according to the order in which they

  were triggered by the user.

  - Mechanism Implemented In this approach, each object that performs a user-driven transition prevents the Sequencer by using the BOFC event (BeginOfFirstCycle: start of first cycle). Once the first cycle is complete (we have returned to the first object by method callback), the object prevents the Sequencer that the first cycle is

  completed using the EOFC event (EndOfFirstCycle: end of first cycle).

  Upon receipt of a BOFC message, a first cycle counter (FCC), integrated in the Sequencer, is incremented. If, after incrementing, this counter is 1, then the Sequencer tells the object that the first cycle can begin by sending the message proceed. When the Sequencer receives EOFC, it

  decrements his first cycle counter.

  When the Sequencer receives a BOFC while a first cycle is already in progress, it waits for the current cycle (as well as all those that are waiting) to be completed,

  Before starting the new first cycle.

  An exemplary implementation is illustrated in the diagram of FIG.

  The behavior of the Sequencer with respect to the BOFC and EOFC can be represented by means of the state-transition diagram illustrated in Figure 153. Obtaining the quasi-parallelism After having carried out their On Entry actions, the objects can perform their actions Activity. By definition, these actions take place in parallel. The purpose of this part is to describe the mechanism of quasi parallelism allowing to simulate the parallelism of

  activities in a purely sequential approach.

  - Extension of the history As we have seen, the decomposition in canonical form releases sub-states

  activities. The transition from one of these sub-states to another is done by the event next.

  This allows you to control the different Activity actions of all the objects that perform their activity. This control is provided by the Sequencer, responsible for issuing

  the event next to the objects having made the request.

  To do this, an object will tell the sequencer that it has an activity to perform just before the last action of its On Entry part of the current state, by writing it in the history. (In case it only has one On Entry action in the current state, the object will inform the sequencer before performing the action). This is done by writing to the history using put. The set of information stored in the history for each put must therefore be extended as follows: in addition to the information already presented, a put must also contain a type and an index

2 0 obsolescence.

  The type indicates whether it is just a simple write in the history (type = trace),

  or if it is a request to perform activities (type = next).

  The obsolescence index (indicated only in the case type = next) makes it possible to detect if a next receipt is invalid following a change of state during activities. If we take again our example of canonicalization of figure 148, we obtain now what is illustrated in figure 154, and in the case where the object

  must perform Activity actions, which is shown in Figure 155.

  Suppose a user creates this object (in the case of Activity actions). The information contained in the trace for this object will therefore be for example those

illustrated in Figure 156.

  The state-transition diagram showing the behavior of the Sequencer for the

  History management must then be extended as shown in Figure 157.

  - Role of the Sequencer The role of the Sequencer is to govern the different activities of the objects by simulating a

parallel execution.

  To do this, the Sequencer uses the information of the history by following the different entries, and by processing the put of type = next. This is materialized by another cursor, the processing cursor, as shown in Figure 158. This slider

  indicates, at each moment, where is the execution of the application.

  Whenever the processing cursor moves to a next type put, the

  Sequencer sends next to the specified object in the put.

  The processing of the activities by the Sequencer can therefore be modeled by the

  transition state diagram shown in Figure 159.

  Thus the complete state-transition diagram of the Sequencer will be as illustrated

in Figure 160.

Example

  Consider 6 objects A, B, C, D, E, and F. These objects have state diagrams.

  transition which are illustrated in Figure 161.

  A, B, and C are in canonical form as illustrated in Figure 162.

  Suppose that a user triggers the msgO of the object A. A enters the state S1, it follows a first cycle, then the Sequencer arbitrates the different activities. This will be shown in the sequence diagram shown in Figure 163. By the time the first cycle ends, the history carries the information

illustrated in Figure 164.

  The sequencer will start processing the activities from the Sequencer cursor position. For each put of type next, it will send to the object concerned the message next so that it can continue its activity. If we continue the previous example until its end, we obtain the diagram shown in the figure

165.

  When the treatment of the first put of type next is finished, the processing cursor switches to the put whose next type = next, as illustrated in FIG. 166, and

  the corresponding processing is illustrated in Figure 167.

  Finally, the trace groups the information shown in Figure 168.

  - Obsolescence of "next" 3 0 The activities of an object can be interrupted by a change of state.We say that the Sequencer sends an event next obsolete if the object has made at least one transition since it was emitted the corresponding next type put.This can happen when state-specific activities are interrupted in the sense we have seen before.To avoid this problem, each object has a next-type put emission counter ( initialized to zero at the beginning of execution.) Whenever an object emits a put (of type trace or next), it increments this counter beforehand and, in the case of a put of type next, passes the value of the In addition, each object also has a PendingNext flag to know if it is waiting for a next, or when sending a next type, this flag changes to 1 (it

  is reset to 0 upon receipt of the next).

  Subsequently, when the object receives a next and it also receives the value it had spent at the time of sending the next type put. The object then compares this value that it receives with the current value of its counter. If the two values are equal,

  the next receipt must be processed, otherwise it is obsolete and is therefore ignored.

  A corresponding example is illustrated in Figure 169.

  * $ * Chapter V - Progressive Loading and Unloading Mechanism (Figures 170-196) Like Chapter IV, this chapter contributes to Chapter VI presented below, and

  completes the techniques of Chapter IV.

  Here we place ourselves in the context of a client / server computer architecture, where a user executes an application from a "light" client station, in the sense that the objects of the application are instantiated from a server. In fact, we distinguish two types of objects: transient objects, and permanent objects Transient objects are specific to each execution of a document, they have a lifetime that can in no case exceed that of the execution the state and the characteristic values of the permanent objects are, on the contrary, saved (knowing that one is here in a case where this backup is carried out on a distant server) and survive an execution with the From the structure induced by the class diagram, a certain number of objects "exist" at the outset of the application: the model (by which the document was created) indicates that, as soon as the beginning of the execution, these objects exist already exist and are available from each other (depending on the associations defined in the model). The basic principle of this chapter, however, is not to create these objects from the beginning, but in a "lazy" way (as and when they are needed), and this in a way that is transparent to the user. The designer does not need to predict these aspects when modeling the application to be developed; they are automatically managed by the system. The user, meanwhile, does not have to worry about the objects that pass between his client and the server, everything happens for him

  as if he owned all the objects of the application.

  Thus, some objects are in fact absent when, according to the model, they should exist; they say they exist virtually. The behavior of the application is not impeded because these objects are created (made) "just in time" if necessary, they are even made by anticipation ("ahead of time") to ensure the fluidity of execution. Even running, depending on the pattern of new objects appear virtually and still, they are only realized as and when

2 5 their real needs.

  As a result, downloading objects is done gradually. This allows reasonable load times to be maintained under band conditions

low pass and irregular.

  In order to reduce the consumption of computer resources, objects that are not (or no longer) used can cease to be truly existent (they can be virtualized). They are deleted, transparently, after a certain latency period (to avoid deletions / untimely creations), knowing that they can be realized again when necessary. Section 1 - Structure of an Application Links The structure of an application is based on the class diagram and exploits associations between classes. Running, the structure is based on the links between the objects. A link is an association-oriented instance. Among the different associations we distinguish the composition (container-content relation) which implies that an object can be contained only by a single object (the containing object) at a given instant. The composition associations are graphically noted as solid rhombs. For example, in Figure 170, object A contains objects B, C, and D. An application therefore contains a set of objects, with behavior. These behaviors (or behaviors) are defined using state machines such as

* we have seen them in section 1 of chapter IV.

  Objects form a tree structure of composition links, within which any object is necessarily a component of another object. Any object therefore has a "path" that identifies it from the root of the application, the Root object, as

illustrated in Figure 171.

  The techniques described here can be applied to dynamic structures, i.e.

  say in which some objects can be created and deleted running. We consider that these are grouped together in what we call a collection (the methods described here can be applied to any other dynamic structure). The collection is represented by a Collection object that is static, and that is in the tree structure based on the composition links. The subobjects of the Collection object represent the elements of the collection as shown in Figure 172, and are indexed. Of course, the objects can also have links between them other than the composition links that form the structure of the application. These links are the instantiations of the different associations existing between the classes of the objects. It is through these links that the objects can communicate, that is, send messages to each other. These links may change while running. Indeed, an association connects two classes. This implies that the instance of a class can communicate with

  any instance of the other class.

  The communication between any object and an element of a collection (for example between A and B [2] in the previous figure) will be done through

  The corresponding Collection object, specifying the index of the desired element (here 2).

  A link between two objects is defined by a path leading from one to another, within

of the structure.

  A link can be built using only the composition links, we will call them "basic links". Figure 173 shows an example. In this figure, the path leading from D to C is formed from the composition links D_B, B_A and A_C. Such a path (defining a basic link) is carried by the object within

  of a structured variable that we will call "port".

  But a link can also exploit links that have themselves been formed from composition links, which we will call a "derived link."

  illustrate an example in Figure 174.

  The path from D to E can reuse the path between D and C in the previous example: DC and C_E. It is not necessary to go through B and A, but it is possible to determine the corresponding path that exploits only the composition links. This will play a major role, as we will see in the first part of Section 2 of Chapter V, as regards the achievement of

objects.

  We can therefore define a link recursively, as being either: * A basic link, that is to say, exploiting only links of composition * A derived link, that is to say exploiting a number finished links (which may be

basis and / or derivatives).

  Display Objects Some of the objects in an application are display elements, such as a button or an input box, for example. The display elements are grouped together to form different screens of the human-machine interface of an application, different pages of an Internet site, or different fields of view in a

  virtual reality environment in 3D for example.

  This grouping of display elements is done using specially created objects, which we call visuZone. Each group of display elements is linked to a visual object. These groups are not necessarily disjoint. So the

  Fig. 175 illustrates a group of grouped display objects D, F and H.

  The grouping of the display objects in this manner has the following purpose: in the course of execution, the loading at a client of a display object belonging to a viewing area, causes the loading of all the other objects of display. display of the same area. Depending on the depth of anticipation desired, objects (display

  or not) connected to objects in the viewing area can also be loaded.

  An interesting example of using visuZone objects can be moving a frame on a map. VisuZone objects can be used to manage concepts

  like the geographical neighborhood and the zoom.

  * Geographical neighborhood We place ourselves here in a context where the application contains a large number of data, distributed geographically on a map (for example a map of a city). Navigation on this map is done by means of a visualization frame

  constituted by the surface of the screen of the user.

  The purpose of using visuZone objects is to make sure that only objects

  and those who are geographically close to them are present.

  To achieve this objective, it is first necessary to divide the 2D area to be covered, and to associate each piece with a visual object (that is to say connect all the objects of this piece of plane to the visuZone object) . This is illustrated in Figure 176, where each "piece" of the rectangle is associated with a visual object grouping together the

  objects, designated by points, which are contained therein.

  In a second step, it is necessary to include the notion of proximity between zones of

  visualization: it is therefore a question of linking visuZone objects close to each other.

  Thus, a mesh network of visuZone objects is obtained, as illustrated in FIG. 177, where the visuZone objects are designated by circles at the right of each "piece",

  and o the links between such objects are indicated by straight lines.

  Thus, loading a visuZone object causes (automatically), by

  anticipation, loading display objects located in neighboring areas.

  In this way, the depth of anticipation and the size of the viewing areas are the parameters that make it possible to play on the granularity of the "mesh". * Zoom in and out In the type of application that we describe in this example, an interesting feature is also the ability to zoom in and out in one

given point of the map.

  This function induces the concept of level of detail, therefore of hierarchy within

  VisuZone objects, an example of such a hierarchy being illustrated in Figure 178.

  The upper visuZone object corresponds to the lower level of detail, while the visuZone objects below represent a median level of detail, and the

  VisuZone's lowest objects represent a higher level of detail.

  Each visual object of the highest level of detail is connected to all objects

  Displaying the finest granularity viewing area.

  The visuZone object of the lowest level of detail (top object) is connected to certain objects in all parts of the split plane. This constitutes a global view

  of the map o only the most striking elements appear.

  VisuZone objects in the median detail level (intermediate objects) are linked to additional objects in their respective quarter-plane. These objects bring more

  precision on each quarter of a plane.

  Finally, visuZone objects of the highest level of detail (lower objects) are connected to all the objects remaining in their fraction of plane. At this level, all objects

are loaded.

  As with the question of proximity, visuZone objects corresponding to

  different levels of detail are linked together for the sake of anticipation.

  A zoom approach without level of detail can also be considered. In this one, the lower visuZone objects are connected to all the objects of their fraction of

  plan. Intermediate visuZone objects are only connected to lower objects, etc.

  Section 2 - Methods of Realization and Virtualization of Objects When launching the application, only the root of the document (Root object) is performed. It is the root of the entire tree of objects in the document. From there, the other objects are "realized" as and when, on

  request from another object, or by anticipation.

  Thus, when an object has to send a message to another object that is not present, the

  realization of the latter is carried out during the process of sending message.

  This process is intercepted by a special layer of the system that makes the different mechanisms involved in this chapter (realization, virtualization,

  anticipation) are managed transparently for the designer and the user.

  In any object-oriented application, for an object to send a message to another object, there must be a link between them, in the sense we have defined it previously. This link is created from the moment the sending object knows the path to the recipient object within the structure. Such a link does not have a fixed character, it can be "modified" during the execution, by modifying the path The role of the path is to allow, by traversing the structure, to recover the reference of the The recipient of this reference is the purpose of a mechanism that we will call the connection process (defined below) which is an integral part of the message sending process. is stored by the object within the structured variable "port" which contains

already the way.

  This method can only work for paths consisting of composition links only. Indeed, it is only by following the links of composition that one can

  create instances of objects (an object can only be realized by its parent).

  To reach an object following a path implies to be able to realize the objects of this path which are only virtually present, hence the need that such a path

  relies on composition links.

  For this, it is possible to return any link to the corresponding base link, that is to say to the minimum set of constituent links that constitute it. The two possible cases of transformation are presented in FIG. 179: in the two illustrated cases, the composition of the links from O0 to On, and from 0, n to 0m, can be

  bring back to the basic link formed of the composition links O0_Oi, OiOj, and Oj_Om.

  Connection method (realization) Suppose an object O0 wants to connect to an ON object. In order to access ON, O0 has a path path that exploits the tree structure. A value of this path can be stored in the port, but this value can also programmatically be modified while running, knowing that a port (base link) does not exist.

  It can contain only composition links.

  To represent a basic link, a port includes a positive index integer value and an (On) nE [i..N] object sequence. index indicates at which level of the hierarchy, from the object that connects, is the common ancestor Oi. The sequence (On) ne [i, N] groups the objects that lead from Oi to ON, it constitutes the "descending" path (to ON), which we will note as descendingPath.Everything can be designated either an object or an element of In the latter case, we note On [p] o On is the collection object that groups all the elements of

  collection, and o p represents the index of the element within the collection.

  The corresponding UML structure is illustrated in Figure 180.

  The realization being from parent to child (an object can only be realized by its only parent in the sense of the relation of composition), the existence of O0 implies that all objects, up to the common ancestor Oi, have been made at least once

  (although they may have been virtualized since).

  The connection method resides in the recursive call of a connect method carried by each object. This method returns the reference of the object to which you want to connect. It takes as argument the path (index, descendingPath) leading to the object to which we want to connect and the depth argument which indicates how deep the connections will be made, as we will see in section 3 of chapter V. This process is started by calling the method symbolized by: 0o. connect (index, descendingPath, depth) Once the ON reference has been retrieved, O0 sends its own reference that ON stores in an inverseRef attribute. Indeed, if ON is virtualized, the reference that O0 30 has has no more meaning. We must therefore prevent O0 that it is virtualized by nulling its reference carried by O0. He can do it thanks to inverseRef O0 knows then that he will have to

  reconnect to ON to send a message.

  If the parent of an object (which wants to connect) has been virtualized, it is realized again during the connection process. To do this, each object has the reference of the Root object. When an object detects that its parent has been virtualized (the reference of its parent is null), it passes to the Root object the path that leads from the root to its parent. The Root object can then instantiate the parent by connecting to it with the path it has received. An illustration of this phenomenon is given in

the example shown in Figure 181.

  In this figure, suppose that A wants to send a message to E using the link defined by the path (3, myC_myE). A can not access its parent D because it has been virtualized (in gray in the figure), so A no longer has the reference of D. To get it

  again, he has to go through the Root object.

  Now with reference to Figure 182, A knows its own path from the root (myB_myDmyA). It can infer that of its parent D: myB_myD. This path is passed to the Root object which will then proceed to instantiate objects missing up to D (here B in step I and D in step 2).). Once instantiated D, its

  reference is passed to A by method return.

  The connection process can be summarized as follows: * Path from the model tree to the target object through a common ancestor. * Achievement "at the crossing" of objects that have been virtualized, or have not yet

been made.

  * Retrieving the reference of the target object, which is stored in the port variable.

  3 0 * Sends the reference of the object that connects to the target object (inverseRef).

  As an example, consider when launching the application, the Root object sends a message to the visuZone object that groups together the display elements that make up the application's home page. We have the path shown in Figure 183, where the object

  Root is white, the visuZone object is black, and the display objects are gray.

  On receipt of this message, the visuZone object connects to its display elements exactly in the same way as described above. This is detailed in FIG. 184, and can be expressed by the transitions diagram of FIG. 185. Cases of non-immutable composition links Optionally, during the execution, composition links may be modified. The fact that an object has only one parent at a given time does not preclude

  not to have several parents at different times.

  Consider the tree shown in Figure 186.

  In this figure, the solid lines represent the composition links and the dotted lines represent the links of simple associations. In order to obtain the reference of J, F has a path (1, GI J). The value 1 indicates that one has to go back one step in the hierarchy of the ancestors of F to find the common ancestor to F and I (in this case D). The GIJ path shows that we have to go through G and I to reach J. If I is virtualized, it is up to G to realize it again, likewise between J and I. Suppose now that the composition link between G and I be broken, and

  replaced by a link between H and I, as shown in Figure 187.

  If J is virtualized, F loses the reference it had previously acquired. And in the case where F must send another message to J, he must determine this reference again by the path he carries. Now, the parent of I having changed, the path to

question no longer makes sense.

  To overcome this problem, we introduce an indirection. The structured variable port must contain, for parent-child composition links, not only the reference of the child, but also that of the object itself or the new parent

who replaces him.

  If we take the example of Figure 186, we obtain in a first step, as shown in Figure 188, a reference to the parent (light gray arrow) and a reference to the son (dark gray arrow). G is the parent of I, and the reference to

  his parent is a reference to himself.

  And in the second stage where H becomes the parent of I, as illustrated in Figure 189, the reference of the parent of I carried by G is now that of H, while the reference of G on his ex-child I is set. Null because G is no longer the parent. The port variable of H then takes the form that of G in the previous step. The parent reference points to H and itself, and the child reference points to I. G now bears the reference of H, but also the path to H (3, myCmyE_myH). If H is virtualized, G can do it again with this

2 5 way.

  So, when F wants to get the reference of I again, he can use the same path (1, G_I). An indirection is then done automatically by following the parent reference from G to H. Virtualization The fact that an object can be virtualized to save computer resources, has

  was introduced at the beginning of this chapter.

  As we have also seen in the introduction of this chapter, we have transitory objects (specific to the client workstation and which do not survive the execution of the application) and permanent objects (saved on a server). A permanent object can be freely "virtualized" on the client (when it is not used), since its current state can always be retrieved from the server. On the other hand, a transient object can only be virtualized when it is in its initial state. Indeed, by its nature, its state is present only in memory on the client's computer, and is not saved anywhere. It can only be realized in its initial state. In fact, if a transient object was virtualized in a state other than its state

  initially, we would lose information.

  Virtualization is triggered by visuZone objects: when display objects disappear from the screen (for example, because the user has changed pages), a single timer is triggered. If no display element attached to the visuZone object is redisplayed before the timeout expires, all

elements are virtualized.

  Virtualizing these elements can cause those objects connected to it (linked), objects connected to them, and so on. Indeed, using Sequencer and history, it is possible to find what are the objects that manipulate the display objects by following the relations of

  cause and effect (in the sense of effects to causes).

  Suppose now, in the example shown in Figure 190, that F is a display object that can be virtualized. The history tells us that at the logical moment t + 7, E was at the origin of a transition of F, then at time t + 5, D was at the origin of a transition of E , ... and so on until A whose transition was initiated by the user. A, B, D, and E are candidates for virtualization (virtualisables)

when F becomes virtualized.

  However, a candidate virtualization object may be interacting with other objects, and it should not be virtualized (note here that an interaction, close in time, expected with non-virtual objects). The current active visuZone object or its mesins is not a hindrance to virtualization if these objects are replicated and live on the server - see chapter VI below). To be able to detect these cases, we have several techniques: * As we have seen, each object has a PendingNext flag that indicates whether it is waiting for a next to continue its activities. An object in this case, of course, should not be virtualized, since

  would be realized again soon after, as soon as he received the next.

  * A virtualizable object (in the cause-and-effect chain that has resulted in the transition of a display object) may be performing other actions. These are then reported in the history. For each virtualisable object, it is sufficient to look in the history if there are no other entries concerning it (after that in the chain of cause and effect). Each time a message is sent, the object records the CPU time (CPU time that executes it) in a lastActionTime attribute. When an object is declared potentially virtualizable (in the sense we have just

  define), we look again at the currentTime CPU time.

  / If currentTime - lastActionTime> 5, 1 being a predetermined time interval, then the object has not interacted for a long time and can

so be virtualized.

  At If currentTime - lastActionTime <8, the object is not virtualized and the propagation stops in that direction: the system does not attempt to

  virtualize the objects connected to it.

  Additional devices can also be considered: * A learning system that will infer the time between the different actions, this avoids virtualizing objects just before they perform an action. * A probabilistic mechanism allowing to associate (manually, or by

  inference on the part of the system) to each object a probability of being virtualized.

  Section 3 - Anticipatory Realization Mechanism Two broad, non-exclusive, anticipatory approaches can be implemented.

  the structural approach and the behavioral approach.

  The structural approach offers the advantage of being transparent (does not require any additional specification). It uses the links that have previously been established between the objects, depending on the structure of the associations in the model. This approach therefore does not necessarily yield much results at the launch of

  application, but is becoming more efficient throughout the run.

  Behavioral Anticipation The behavioral approach consists in executing the model of the application with a certain number of steps in advance, thanks to additional specifications (annotations) explicitly provided in the model. This includes adding "anticipatory transitions" to the model that represent the effects of likely impulses that the system might receive from its external environment.In implementation, anticipatory transitions are not taken into account as true transitions (in other words, an anticipatory transition does not change the current state of the object but rather changes one-or-more-variable of work in which the future state is simulated), they nonetheless serve, in particular, " to realize "the objects that would be in the" virtual "state. (It will be observed here that the behavioral anticipation can also be used for temporal reasoning, for the help to the

tactical decision for example).

  Thus, in the example shown in Fig. 191, a Switch object can transition from Off to On by the turnOn message. In order for the system to automatically anticipate a transition from Off to On, taking place three seconds after entering the Off state, the modeller annotates the anticipatory transition (in dotted lines) with the event triggering time-out (3s) ( of course he can add

conditions, actions, etc.).

  The modeler states that anticipatory transitions are anticipated with a lead time of 5 (he can declare this globally for the whole application or selectively). The predictive transition of the Switch object is thus done after 3-8

  2 0 seconds if 8 <3, and immediately otherwise, after entering the Off state.

  The transitions that result (the actions in the anticipated states produce events that cause other transitions) are also anticipatory. Like the former, they are not on the same level as the execution of the application and serve to amplify the process of realization. Of course, the states anticipated by the

  system have no edge effect (especially on the HMI).

  Thus, in the preceding example, if we assume that the object Switch, in its On state, triggers a transition of a Lamp object that would be in the "virtual" state, the behavioral approach, anticipating the transition turnOn, allows the Lamp to be "done" before the user triggers (directly or indirectly) the

actual turnOn transition.

  In the following, we describe the structural approach, although we will retain that behavioral anticipation is an important complement, since it amplifies the benefits of structural anticipation (both approaches have a synergetic relationship). Structural Anticipation As we saw in the first part of Section 2 of Chapter V, a depth argument is passed on calls to the connect method. This argument makes it possible to establish the degree of anticipation that one wishes to achieve. Indeed, once the connection of O0 to ON is complete, if depth> O, ON will establish its own connections (at the desired depth), as shown in the diagram of Figure 192,

  which illustrates a connection to depth 3 (depth = 3).

  Consider now the class diagram shown in Figure 193, and assume that the realizations are at depth 1. Then the connection of the visuZonel object to the object B will cause not only the creation of B, but also that of the object D via the connection from B to D.

  This is explained in the sequence diagram of FIG.

  VisuZone object case In the case where the target object is a display element, the anticipation is done via the visuZone object. It provides the link between the intended object (the first display element) and the other elements of the same group. But this intermediary must be transparent and must not intervene in the calculation of the depth of anticipation. Thus, in the representation of FIG. 195 which illustrates a connection to the depth 2, it is observed that the connection to a visual object does not count in the

  calculation of the depth of anticipation.

  Moreover, as we saw in the example of the geographical neighborhood, the visuZone objects can be connected to each other. This does not change the mechanism of anticipation, except that in this case the connection between objects

  visuZone counts in the calculation of the depth.

  Thus, FIG. 196 shows, again in the case of a connection at depth 2, that the connection between two visuZone objects counts in the calculation of the depth of anticipation. Chapter VI - Inter-Client Sharing (Figures 197 to 238) Introduction 2 0 We will deal here with the sharing of one or more applications by several remote users. So we place ourselves in a client / server computer architecture, where each client runs an application whose objects can be shared by other clients. In particular, sharing may be implemented as a result of

  suggestions / acceptances of contents described in Chapters II and III.

  Section 1 - Types of Objects We have seen earlier, in the context of the progressive loading mechanism described in Chapter V, that there are two types of objects: transient objects and permanent objects. In Chapter V, this last category is subdivided into

  two: private permanent objects and shared permanent objects.

  A shared permanent object can be used jointly by all clients.

  Each user shares with others the characteristic values of the object (state, roles, etc.). When a user modifies the state of such an object, this is felt by all the customers who have realized (in the sense of the progressive loading mechanism) this object. Private permanent objects are, as their name indicates, specific to each client. Customers use the same objects in the sense that they use the same application, but private permanent objects are decorrelated between them from one client to another. The management of the sharing of one or more applications between several clients therefore amounts to managing the shared permanent objects, in such a way that the modification of such an object by a user is carried over to all the customers concerned, that is to say

  those in whom this object really exists.

  Section 2 - Architecture Several approaches can be followed to manage the inter-client sharing. The first is based on shared data "replication" replication, and with reference to Figure 197, replication between the different PC clients can be managed by means of a database management system on one or more servers. Such a system ensures the permanence of information

  2 5 shared and deals with concurrent access to data.

  In such a context, the management of determinism is not necessary. Indeed, the behavior of the objects (the actions they perform) takes place at the different clients and in no case on the server. The latter retains only the different values (state ...) of the shared objects, it does not need to reproduce the behavior of the objects. Whenever a shared object O is modified at a client, the values of O are updated in the data structure, and reproduced in the clients who also use O. If this approach has the undeniable advantage of simplicity, does not allow the persistence of treatments. From the moment when no client works, the objects of the application are inert since they have no life on the server. The persistence of treatments is especially useful in the case of simulation applications where we do not necessarily want to leave the client station on for

  allow the continuation of the simulation.

  To allow this persistence of treatment is the subject of the second approach which we will detail in this chapter. It implies that the applications used jointly by the clients also run on the server. This allows, as we will see in the next chapter, a replication mechanism by calculation. On the other hand, this mechanism requires a high degree of determinism of the behavior of the shared objects and to have a rollback mechanism at its disposal to make up for the non-determinism between client and server (optimistic execution on the server, see section 5 of the chapter). VI). Applications on the server have

  also a Sequencer regulating the shared objects.

  Section 3 - Replication Mechanism As we have seen, users of an application can share some instances of shared permanent objects. Users can interact with these objects, but each in turn through a mutual exclusion mechanism explained later. When a user modifies an object, since the same instance can be shared with certain other users, they must be notified of this change. Thus figure 198 illustrates the case where two users User1 and User2 handle different objects (black objects for Userl, white objects for

User2).

  However, because of the progressive loading mechanism, users who share the same instances do not necessarily all actually have these instances on their workstation. Thus, when a shared object is changed, it is not necessary to replicate this change to all clients that share this instance, but only to those for whom the object in question is real (has been realized, and since

has not been virtualized).

  Any modification of a shared permanent object due to a message from a transient object or a private permanent object is also performed on a server, by the replication of the transition which is at the origin (actions performed by the shared permanent object are thus executed both at the client who has locked this object, and on the server). These changes are then reported from the server at each of the customers who actually owns this object. This is the first aspect

  of this replication mechanism: replication by "value".

  If one of the actions of the shared permanent object causes a transition of another shared permanent object, that shared object is not replicated from the client (which has the lock) on the server. It is directly "computed" by the server .. Of course, the modification of this second shared permanent object is also reported to each of the customers who actually owns it.This is the second aspect of this mechanism.

  replication: replication by "calculation".

  Such a type of replication is only possible if the shared application is also running on the server, in accordance with the execution model specified in the

  Chapter IV (thus regulated by a Sequencer).

  Thus, we have globally a "mixed replication" mechanism: * By value: in the sense that the transitions of shared permanent objects are reproduced when they were caused by purely local objects whose server did not not visibility (transient and permanent private) * By computation: in the sense o transitions of shared permanent objects are deduced by the server when they were caused by another shared permanent object

  (whose server then has visibility).

  Thus, FIG. 199 illustrates the two types of replication between a client and a sharing server, when transient objects, permanent objects are implemented.

  private and shared permanent objects.

  Of course, such an approach is not limited to the use of a single server, as shown in Figure 200 where there are two Share Server Sharing servers 1 and

  Sharing Server 2 cooperating with each other.

  This replication mechanism can be split into two distinct phases: the replication on a server of a transition made by an object to a client (who has the right to do so in the sense of mutual exclusion), and the propagation of this same transition of the server to all customers who actually own (within the meaning of

  progressive loading mechanism) the object.

  Replication on a server from a client station Suppose that a shared persistent object SPO (for "Shared Persistent Object" in English terminology), at a client C, makes a transition due to the receipt of a message from a transient object or of a private permanent object. The following information is then sent to the server: 1. The shared object making the transition 2. The state preceding the transition (which we will call previous state) 3. The current state after the transition (which we will call current state) ) 4. The logical time corresponding to this transition in the customer who is at the origin 5. The logical time corresponding to the previous transition at the customer who is at the origin Thanks to the information 1. and 3., the application on the server finds what object it is and makes it transition to the specified state. Information 2., 4. and 5. are used for various error recovery processes explained more

  far in section 5 of chapter VI.

  When the shared permanent object transitions to the server, it does so for

  a logical Sequencer time of the server application.

  Consider the example where we have four objects A, B, C, and D. A is a transient object, B and C are shared permanent objects, and D is a private permanent object.

  An extract of the state-transition diagrams of these objects is shown in Figure 201.

  Suppose that a client K causes the transition from the SO to SI1 state of the object A. Then the flow illustrated in Figure 202 (the objects were put in form

  canonical as described in Chapter IV).

  This is reflected at the client K and the server as follows, illustrated in FIG. 203:

  The object B (shared) makes a transition due to a transient object.

  This transition is replicated on the server.

  - object C (shared) makes a transition due to a permanent object

  private. This transition is replicated to the server.

  - the object D is a private permanent object, the application of the server does not

  has no visibility. The message sent by B in state S5B is ignored.

  - Since an application runs on the server, the transitions of the shared objects are done directly on the server, independently of those that take place at the client K. Propagation of a replicated transition to the clients concerned Whenever a transition occurs a shared permanent object takes place on the server, it is propagated on each of the client computers that actually owns the object. Customers who have such an object that virtually will get it back anyway to his

  current state (on the server) when it is done again.

  This can be materialized by the diagram of FIG. 205, to be considered in relation with the diagram of FIG. 204 which gives the representation of a transient object T and

  of three shared permanent objects Pl, P2 and P3.

  First, the object T passes the object Pi, and this is replicated on the server.

  The client L actually owns the objects Pi, P2 and P3. The transitions of each of

  these objects are replicated from the server.

  The client M actually only has the P2 and P3 objects. Their transitions are replicated. The Pi object is only there virtually, and its transition is

not replicated.

  Only the object P3 is present at the client N, and its transition is replicated.

  Transitions that are downstream of the P3 object occur independently in the

client K and the server.

  3 Replication in a multi-server framework

  Objects shared by clients may be distributed across multiple servers.

  The replication and propagation mechanism presented in Chapters IV and V remains the same for each server separately. Each server runs

  the application and regulates the objects it possesses by means of a sequencer.

  In the same way that a transition of a shared object caused by a private or transient object is replicated by value, the transition of a shared object of a server caused by a shared object from another server is also replicated by value. If other shared objects on this server are involved in the resulting cycle, they are of course replicated by calculation. The diagram in Figure 206 illustrates this mechanism, in which - T passes P 1, and this is replicated on the server S I, and - P2 passes P3, and this is treated as if P2 was transient or private: the

Replication is by value.

  Section 4 - Communication Protocol When running applications using shared permanent objects, a communication system is required to convey information from the server

  to multiple clients, as well as a client to servers.

  To do this, each client station has a component that allows it to interact with the different servers. They must always listen to

  possible connection requests from customers.

  At each connection, a component must be generated on the server. It is specific to the customer who has just connected, is responsible for interpreting the information in

  from the client, and to send the server information to this one.

  Component on the client computers The network component of the client station (clientCommunicationManager) offers the following functionalities: / Establish a connection with the server, ie initiate the creation of the component on the server that corresponds to it, and instantiate a new object

  GbxClient, customer-specific that connects.

  / Listen to information coming from the server. This information can not be

to be only method calls.

  / Send information to the server, using a method of type 1 0 clientCommunicationManager.send (methodName, argList)

  O methodName is the name of the method to call.

  argList is the argument list for this method.

  Component on the servers Symmetrically, the server's network component for a client workstation must allow: / To listen to information coming from the client station to which it is "connected", these

  information being of type (methodName, argList) as we have seen.

  2 0 methodName must be a method of the server's GbxClient object.

  To send information to the client, using the same type of method serverCommunicationManager.send (methodName, argList) Establishing a connection Referring now to Figure 207, we observe that each server has a Listener component that listens any connection requests from the client computers. When one of these requests arrives, it causes the creation on the server of a network component (ServerCommunicationManager) which will dialogue with its corresponding 0 on the client station (here Clientl or Client2). It consists of a routine that listens to the different messages that can come from the corresponding remote client station, and a device (method call) allowing it to send messages.

data to this one.

  When a client is connected, the ServerCommunicationManager component calls the newClient (connectionRef) method of the server's Document object. This method creates an instance of the GbxClient object, which will be the representative of the client node within the server. At the time this instance is created, the Document object passes a reference to itself to GbxClient. The reference of this GbxClient will be returned

  to the network component of the server that ordered its instantiation.

  Following this, the network component of the server returns to the network component of the client that had connected an acknowledgment that the connection was successful. This acknowledgment will be used to avoid switching

  automatic to a backup communication system using the http protocol.

  The connection process is shown in the diagram in Figure 208.

  Communication between clients and servers Referring now to Figure 209, the only information that can be exchanged between clients and servers are method names, and arguments for these methods. As we have seen previously, this information is

  passed using the send method of network components.

  serverCommunicationManager.send (methodName, argList) clientCommunicationManager.send (methodName, argList) If the recipient is the server, the methodName method is called at the GbxClient object, and if the recipient is the client node, the methodName method is called at l Application object of the client computer. A consistency check method can be put in place after transmission to verify that the

  Arguments in argList have meaning.

  The sequence diagrams of FIGS. 210 and 211 illustrate the two types of communication, respectively from a client to the server, and from the server to a client. Ending a connection When a user exits all applications that use shared permanent objects, the connection may be terminated. To do this, the Document object on the item

  client calls the endOfConnection (argument) method of its network component.

  This component must then signal to the network component that corresponds to it on the server that it must delete the instance of GbxClient, and disappear. The network component on the server calls the killClient (clientRef) method of the object

Application on the server.

* This can be represented by the sequence diagram shown in Figure 212.

  Management of secure access problems In the case of access restrictions ("firewalls") for users who do not have full authority over the management of firewalls.

  their domain, an automatic migration to a backup system is envisaged.

  Such a system has the following characteristics. Automatic Switching By default, the transmission protocol used is that described above. However, it must include an error management system that automatically switches to the system described below in the event of an emission problem or

reception.

  During the connection request, the client network component that connects starts counting a timer. If this timer expires before the client network component has received the acknowledgment, the

protocol switches.

  Communication from a client to the server To bypass access restrictions, the idea is to use the "http" protocol to convey the information. To do this, the methodName and argList elements that must be passed from a client to a server are passed as parameters when calling a dynamic link library DLL file (for the English term "Dynamic Link Library ") of the server, via a URL type address. The CommunicationManager module of the client workstation will be

charged with such an appeal.

  On reception, the CommunicationManager module of the associated GbxClient module on the server to the client concerned will have to retrieve these parameters and proceed to

  the method method (argsList) method call of the server's GbxClient module.

  Communication from a server to a client The idea is the same as in the previous case, except that in the context of the protocol

  http, it is impossible for the server to send data to the client by itself.

  To circumvent this difficulty, a pseudo-push method ("push") of information is used, for example of the following type: the CommunicationManager module of the client station, at regular time intervals (for example every 10 seconds ... ), performs a http request on the server to retrieve a file in html format.This file, managed by the corresponding CommunicationManager module on the server, contains the data that the GbxClient module is waiting for.The CommunicationManager module of the client workstation must be able to to extract the methodName and argsList elements from this html file, and to call the method method (argsList)

  the Application object of the client computer.

  Section 5 - Mutual Exclusion Because the same instances are shared by multiple users, a mutual exclusion mechanism is required to prevent concurrent access to the same object. This mechanism is based on a double lock system: a lock in

  read / write (W / R) and read lock (R).

  Any change in the state of a shared permanent object can only be done if the object is unlocked in read / write mode. On the other hand, the read access to the characteristic values of the object (in its state for example) requires only the unlocking R. The recovery of the lock is the responsibility of the object which makes it feel the need, that is, changing the state of the shared permanent object (it then requests the W / R lock)

  30 or reads the current state of the object (it then asks for a lock R).

  The allocation of the W / R lock has an exclusive character Only a client can access a read / write object at a given time. But this is not the case for read access: thus several users can read access to the same object. Of course, the fact that a customer has the lock W / R excludes during the same time any obtaining of a lock R by any other client. Using Locked Objects A client can use a shared permanent object from the moment it obtains a lock (whether R or W / R) on that object. As long as the cycle (as defined earlier in Chapter IV), initiated by the transition of the object that caused the lock request, is not completed, the locked object is considered to be

in use.

  We will therefore consider that a client has finished using a locked object in read mode if the

  cycle in which it reads one of the values of this object is completed.

  For example, and referring to Figure 213, suppose that an object A wants to send

  a message to an object B by passing it the current state of a shared permanent O object.

  Object A is considered to have finished using object O when object A resumes

  hand by method callback.

  A client is also considered to have finished using an unlocked read / write object if the cycle caused by the transition of the object that requested the

lock is finished.

  For example, and referring to Figure 214, assume that an object A obtains the WR lock on a shared permanent O object to change its state. We consider that object A has finished using object O when object A takes over

By method callback.

  Object Lock Behavior An R or W / R lock of an object will be defined below using state-transition diagrams. For a given shared object O, a client may be in one of the following states with respect to the R lock or the W / R lock: * The client may not have the lock on the O object * The client may have the lock on the object O but do not use it * The customer can have the lock on the object O and use it * The client can be about to make the lock on the object O if another client

has made the request.

  A shared permanent object can be realized in two distinct ways in a client (just when the client needs the object or in advance, see

  the introduction of Chapter V), which affects the allocation of the lock.

  Indeed, if a shared permanent object is realized in a "just in time" mode, it means that the customer wants to read or manipulate this object. The latch R or W / R is then given to it directly. We then have the state-transition diagram of Figure 215: On the other hand, if a shared permanent object is realized in anticipation, the client has not yet expressed the will to manipulate the object. It will only get the lock if it actually accesses the object. This is manifested in the state-transition diagram

2 of Figure 216.

  WR lock request An object A at a client C requests the lock on the object to which it wishes to send a message (if it does not already have it).

  If the object is not already used by another client (either read or write), it becomes so as shown in the sequence diagram shown on the

figure 217.

  If the object was unlocked for reading, the lock is removed from each client that has it after a certain latency. This latency is specific to each object

  and can constitute for example an attribute.

  This is illustrated in Figure 218.

  If the object was already locked in read / write, the lock is also rendered after a certain latency. This case can be represented by the diagram of Figure 219. As we are here in the context of a communication protocol based on the TCP protocol, and that this protocol provides a communication in the mode "first-in-first-out" "(FIFO), all transitions of object B replicated from Client I occurred at Client 2 before the lock on B was obtained Lock Request R The assumption is that an object O in a client C requests the lock R on the object whose

  he wants to know the state (if he does not already know it).

  If the object is not locked in either read / write or read, it becomes locked in

  reading, as shown in Figure 220.

  If the object is already read by other clients, the C object is added to the list of clients that have the R lock on the O object. Many clients thus access the same object for reading. If the object is already read / write by another client, the request for object O is placed on hold until the object is

  available. this is illustrated in Figure 221.

  Management of mutual blockages There are, however, so-called mutual blocking cases where clients can

  expect each other because of demand for locks.

  Consider for example, with reference to FIGS. 222 and 223, two clients C1 and C2.

  The client Cl has the shared permanent objects O1 and 02, while the client C2 has the shared permanent objects 01, 02 and 03. The clients have locks as follows:

  the client C l has the W / R lock on 0 1.

  the C2 client has the W / R lock on 02 and 03.

  We then find ourselves in the situation of Figure 224.

  Now suppose that, during the cycle initiated by the object 01, the client C1 asks the client C2 for the lock W / R on the object 02. The client C2 can not return the lock on the object 02 because a cycle initiated by object 02 is going on at the customer's

  C2. We then find ourselves in the situation of figure 225.

  The client Cl waits for the client C2 to finish using the object 02 to take the lock and continue executing it. Suppose now that in the cycle initiated by the object 02 at the client C2, this same client comes to request the lock on the object 01. As we have seen, a cycle initiated by the object O1 is in progress at the client Cl, and the lock W / R on the object O1 can not be rendered. This is illustrated in Figure 197: the client Cl waits after the client C2 to get the lock on the object 02, while the client C2 waits after the client Cl to get the lock on the object

  O1; we are in a situation of mutual blocking.

  To remove this situation, you must undo the actions performed by one of the two clients so that all the locks that intervene in the locking loop

mutual benefit be restored.

  Suppose that in the same example, the lock acquisitions took place in the order shown in Figure 225. It seems more relevant here to undo the actions that took place at the client C2. Indeed, the first getting a lock on a

  object in the deadlock loop is newer at the C2 client.

  Undoing the actions performed at the C2 client is equivalent to using a feature

  referred to as "Rollback" ("Rollback" in English terminology) described above.

  after from the logical time o the client C2 got the lock on object 02.

  The object Ol can thus obtain the lock on the object 02 and continue its cycle. The

  client C2 is then put on hold until client Cl releases object 02.

  However, resolving mutual blocking involves detecting the presence

  a loop in lock requests, as we will now describe.

  Detecting Loops There can be no loop in lock requests if an object receives a lock request while it is waiting for a lock. However, this

  it is not because one is in this case that there is necessarily a loop.

  In any event, it is from this contentious case that the loop detection begins.

  Figure 226 illustrates on the left side a case of mutual blocking, while

  that its right side illustrates a case where there is no mutual blocking.

  To avoid mixing the data related to each instance of the mutual blocking management algorithm, these data are stamped with markers using a growing counter, representative for example of the launch time.

of the instance of the alogrithm.

  Thus, and now with reference to FIG. 227, when the object A receives a lock request while it is already waiting, it raises the CPU time of the current sequence in order to use it as a marker. It then goes back the lock requests of this sequence by marking each pending object by the CPU time it has raised. If it falls back on itself for the same mark, a cycle is detected, and the process of going back can be put

implemented.

  Section 6 - Rollback Mechanism Two replicated execution approaches of this mechanism are possible: pessimistic and optimistic. In the optimistic approach we describe in this chapter, the backtracking mechanism serves as a method of catching up on erroneous predictions. The same Rollback mechanism is also used in the management of mutual blockages in the context of mutual exclusion. Here we treat the case

catching up, on an example.

  In this example, shown in Fig. 228, objects 01, 02, 03, and 04 are shared objects, while object 05 is a private object, and it is assumed that the client

  Clientl has the W / R lock on the shared objects.

  Following a user action on the object 01, the messages Msg1, Msg2 and Msg3 are linked together. Because it concerns shared objects, the transition of object 01 is replicated by value on a server. On the other hand, the consequences of the transition of the object 01, namely the transitions of O2 and O3 are not transmitted since the

server generates them itself.

  Once the transition of the object 03 performed (following the Msg3 message), the first cycle from the action of the user is completed. The traces available to the sequencers of the client and server client workstations then contain

  respectively the information illustrated in Figure 229.

  On the server, once the first cycle is complete, the sequencer goes into action and processes the PutNext actions in the trace. This results in sending the message Next to the objects that had requested it (here the object 02) and the

  message Msg5 that follows, as shown in Figure 230.

  The trace on the server then contains the information shown in Figure 231.

  Suppose now that on his computer, the client clientl user manipulates the object 05 during the first cycle (which was initiated by the Msgl message). He is

  the client then runs the scenario shown in Figure 232.

  The sequencer of the client then contains the information illustrated in FIG. 233.

  It is observed here that the server has taken too much advance in the processing of its sequencer, so that different scenarios are played at client clientl 1 and on the server. The server must therefore go back on the advance that it has taken: it is the

  mechanism of return back, whose operation will now be described.

  Detection Such a contentious case is detected during the replication of the transition of the object 02 of the state S1 to the state S4, whose cause is due to an object not shared. Indeed, during a replication, the server receives the following information: 1. The object that makes the transition 2. The state preceding the transition (that will be called the previous state) 3. The current state after the transition (which will be called current state) 4. The logical time corresponding to this transition at the customer who is at the origin 5. The logical time corresponding to the previous transition at the customer who is at the origin. Information 1 and 3 allow the server to find which object to transition to and in which state. The information 4 will allow the detection of a litigious case (if the server has already associated this logical time with a put, there is conflict). Finally the information 5 will be used to reposition the cursor of the treatment in the case where a return operation is necessary. In the same example, the server will know that the transition from the object 02 to the state S4 corresponds to the time logical 127 for the client clientl. Now the server has already, by calculation, associated with logical time 127 a transition that is different, since it concerns the passage of the object 04 to the state SI). A backtrack must be made. Reversal steps Reversal is carried out by the following sequence of steps: 1. Find in the trace the last "stable" position before the disputed case (point from which the sequencer will resume its processing) 2. Determine in the history what entries are to be undone 3. Determine which objects are affected and in what state they should be restored, and restore them to the server and to all passive clients who actually own them 4. Replicate the transition which made it possible to detect the conflict (here the passage of the object 02 from the state S1 to the state S4)

  5. Resume sequencer processing from the last stable position.

  Details of the steps - Step I A conflict situation can be schematized by the state-transition diagram of the

Figure 234.

  The solution to the conflict is to bring the problem object back to the last of its states for which both the client and server are in agreement. Rather than searching for this state in the client's trace, the object itself can tell what the logical time it was in the previous state was. This logical time is that of the last state for which client and server are in agreement for the object which poses a problem: this logical time is then transmitted to the server so that it can be reduced to it. Whenever they make a transition, the objects store for what logical time of the client they change state. So, when a transition is replicated, the

  server can receive the logical time that the object was entered in the previous state.

  Thus, during the replication of the transition to the logical time 127, the server receives the logical time of the client client corresponding to the previous transition of the object

02: this logical time is 124.

  The server therefore repositions the cursor of the sequencer to the logical time 124 of the

  Client client, as shown in Figure 235.

  - Step 2 Finding in the server trace what needs to be undone is to determine what was the first transition to be done wrongly. It is from this transition that what has been done in advance on the server must be undone. This transition is the first transition of the problematic object (here the object 02) located downstream (in the sense of the logical time) of the processing cursor (as it has been

returned to step a).

  In the example, this is the transition to logical time26. This is where the write cursor is repositioned. This transition corresponds to the reaction of the object 02 to a message Next of the sequencer. If the server had been in adequacy with the

  Client client, this Next should have been obsolete.

  As we have seen, the object 02 is still in the SI state when it receives the

  Next message, and this one causes a transition.

  The corresponding situation is illustrated in Figure 236.

  As will be seen, only transitions from the write cursor in Fig. 236 should be canceled, while processing resumes from the new position of the processing cursor. This is justified by the fact that the consequences of the transitions appearing between the processing cursor and the writing cursor are necessarily after the new position of the writing cursor: they are thus undone. This is why the transitions that are causing it (ie those that appear from the processing cursor to the excluded write cursor) must be kept to continue the process in place of what has been undone. . - Step 3 From the writing cursor, you have to go through the trace to determine what are the

  objects that have incorrectly transitions.

  The trace carries, for each entry, which object made a transition and what was its previous state. It is therefore sufficient to recover the first entry from the writing cursor for each object: there is the previous state in which the object must

to be restored.

  In the example, only object 04 has an entry under the write cursor: it must

to be restored in the state SO.

  Transitions made in advance and wrongly by the server must be canceled.

  They must also be canceled in all customers who have passively replicated them and who actually own them (in the sense of

  progressive loading described above).

  To do this, all objects to be restored to their previous state. These forced transitions are replicated by customers who own

  These objects are actually using the replication method already described (Step 4.).

  Once this is done, all history entries that appear downstream (in the sense of the logical time) of the write cursor are removed, as shown in Figure 237. - Step 4 Once the transitions done wrong have have been defeated, it is necessary to re-homogenize the entire system. To do this, it is ensured that the replicated transition which has made it possible to detect the contentious case also takes place on the server. The sequencing mechanism then makes the information corresponding to this transition

  plotted in the trace from the trace cursor. This is illustrated in Figure 238.

  Of course, this transition is propagated to all customers who actually own the object (in the sense of the progressive loading mechanism). - Step 5 Once the transition is replicated, the sequencer can take over to manage the ongoing activities of the objects. It resumes processing from the processing slider.

  In the example, his first task will be to send the message Next to object 02.

  However, since the object 02 is now in state S4, the Next it receives is

obsolete and is therefore ignored.

  Of course, the present invention is not limited to the embodiments described and shown, but the skilled person will be able to make any variant or modification within his mind. In particular, the characteristics of the invention set out in the different chapters and the different sections of these

  chapters can be combined in very different ways.

ANNEX

  Component BEHAVIOR <PUBLIC: ATTACH EVENT = ondragstart "ONEVENT =" InitiateDrag "/> <PUBLIC: ATTACH EVENT =" ondrop "ONEVENT =" FinishDragn /> <PUBLIC: ATTACH EVENT = "defragment" ONEVENT = "DragEnter /> <PUBLIC: ATTACH EVENT = "ondragleave" ONEVENT = "DragLeave" /> <SCRIPT LANGUAGE = "JScript"> // drag'n drop management

  // -> The user starts to move the handle ...

  // Store the identifier of the source container.

  function InitiateDrag () {var caid = event.srcElement.containerid; var ceid = event.srcElement.contentid; event.dataTransfer.setData ("'Text", "#contentid =" + ceid + n # containerid = "+ caid); event.dataTransfer. effectAllowed =" copy ";

  // -> The user places the handle on another ...

  // Modify the style to show the interaction of the target. function DragEnter () {event.dataTransfer.dropEffect = 'copy'; style. backgroundColor = 'red'; style.color = 'white'; event.returnValue = false; }

  // -> The user moves the handle away from the other ...

  // Re-modify the style to reset the target to a state

normal.

  function DragLeave () {style.backgroundColor = '' style.color = ''; }

  // -> The user drops the handle on the other ...

  // Get the identifier of the source container and the target. // Pass the action by event to the system function FinishDrag () {style. backgroundColor = ''; style.color = '';

  // Broadcast the "onderive" event ...

  var oEvent = createEventObject (); oEvent.cible = event.srcElement. ContainerId; oEvent.source = event.dataTransfer.getData ("Text") fire ("onderive", oEvent); } // End of drag'n drop management

//....__ __

</ SCRIPT>

Claims (39)

  1. A system for sharing information on a computer network, characterized in that it comprises: a first set of organized information comprising at least a first container and a plurality of first information accessible via the or each first container, a second set of organized information comprising at least a second container and a plurality of second information accessible via the or each second container, means for matching the or each first container and a corresponding second container, means for a user to add information in the first set of information, means for a user to add information in the second set of information, network communication means between the first and second sets of information, these means being able, when adding information accessible via a first container, to suggest rer adding the same in the second
corresponding container.
  System according to claim 1, characterized in that each information accessible via a workbook belongs to a group comprising direct contents, references to contents located in other organized information sets and sub-containers via which 'other information
are accessible.
  3. System according to claim 2, characterized in that said
  References to content are links.
  4. System according to claim 1, characterized in that the first set of organized information is part of a server and is intended to be accessible by a plurality of users of a community, and in that it is provided a plurality of second sets of organized information constituting private sets specific to a plurality of users. 5. System according to claim 4, characterized in that the information accessible via the containers of the first set of information organized are constituted by the union of all the information accessible via the
  corresponding containers of the second sets of organized information.
  6. System according to one of claims 4 and 5, characterized in that
  all organized information sets include an organized structure
of containers.
  7. System according to claim 6, characterized in that the
  organized structures are arborescent.
  8. System according to one of claims 6 and 7, characterized in that
  all organized information sets include the same structure
organized containers.
  9. System according to one of claims I to 8, characterized in that
  includes, in association with a set of organized information in which an addition of information has been suggested, a memory containing a status indicator of
suggestion process.
  10. System according to claim 9, characterized in that the indicator
  status can be "Suggested", "Accepted" and "Rejected".
  I11. System according to one of claims 9 and 10, characterized in that
  it comprises means for deleting information previously added from a set of organized information only after verification of the status indicators associated with the other sets of organized information concerning said added information.
  12. System according to claims 10 and 11 taken in combination,
  characterized in that the verification of the status indicators is to verify that all
have the value "Rejected".
  13. System according to one of claims 9 and 10, characterized in that
  it further comprises suitable warning means, when content type information previously added in a set of organized information is intended to be deleted, to inform said desired deletion any user of another set of organized information having a reference to that content, and means for each user to duplicate said
  content to said other set of organized information.
  14. System according to one of claims 1 to 13, characterized in that
  Said information includes links to contents external to the system.
  15. System according to one of claims 1 to 14, characterized in that
  that each set of organized information also provides access to
  information the addition of which does not give rise to any suggestion.
  16. System according to one of claims 1 to 15, characterized in that
  the intercommunication means comprises means for deriving from an original container of a first set of information organized to a destination container of a second set of information the information accessible via said container of information. origin, said correspondence means being able, in response to said derivation means, to establish a correspondence between the original container and the container
of destination.
  17. System according to claim 16, characterized in that in response to said derivation means, the correspondence means are also able to establish a correspondence between the destination container and the
original container.
  18. System according to one of claims 16 and 17, characterized in that
  the means of intercommunication further comprise means suitable, during the implementation of the derivation means, for selectively accepting and refusing
  accessibility of said information via the destination container.
  19. System according to one of claims 16 to 18, characterized in that
  that the derivation means are able to perform chain derivations between
  several sets of information organized.
  20. System according to one of claims 16 to 19, characterized in that
  that the diversion means are able to merge, in a container of destination
  Given information accessible via a plurality of original containers.
  21. System according to one of claims I to 20, characterized in that
  that it includes suitable means, when removing in a container from the accessibility of information by this container, preserve the accessibility of this
  2 5 information via an archive container.
  22. System according to claim 21, characterized in that, when the accessibility of previously added information via a container is removed, the intercommunication means are no longer able to suggest the addition of this information in the system. or the corresponding containers of other sets
organized information.
  23. System according to one of claims 1 to 22, characterized in that
  the intercommunication means comprise means for referencing, from an original container of a first set of information organized to a destination container of a second set of organized information, the information accessible via said original container, said means for establishing correspondence being able to establish a correspondence between the original container and the destination container in response to said referencing means only if a user of the container of destination has accepted the
  referencing said information.
  24. System according to one of claims 1 to 23, characterized in that
  it comprises a set of organized information comprising a plurality of categorizing containers, and in that the containers of each other set of organized information are at least partially correspondents of said
categorizing containers.
  25. System according to claim 24, characterized in that all the containers of each other set of organized information are necessarily
  Correspondents of said categorizing containers.
  26. A system according to claim 24, characterized in that each container has a name, and in that means are provided when adding in a set of organized information a container corresponding to one containing categorizer, to name it regardless of the name of the categorizing container.
  27. System according to one of claims 24 to 26 taken in
  combination with one of claims 16 to 20, characterized in that the means
  Also, the branch structure is adapted to derive a plurality of containers organized according to a container structure, said container structure being preserved when
of the derivation.
  28. System according to one of claims I to 27, characterized in that
  each set of organized information comprises a container tree structure, and further comprising means for representing at least the highest level containers in the tree structure under
form of binders.
  29. System according to claim 28, characterized in that it further comprises means for representing containers of the lowest level in the
  tree structure in the form of binder pages.
  30. System according to claim 29, characterized in that it comprises means for representing content elements accessible via containers
  forming pages in the form of layers applied on the page considered.
  31. System according to one of claims 1 to 30, characterized in that
  each set of organized information comprises a tree structure of containers, and in that it further comprises means for representing, in areas adjacent to a user screen, the tree structure of a set of information organized own user audit and the tree structure of a
  another set of organized system information.
  32. The system of claim 31 taken in combination with one
  Claims 16 to 20, characterized in that the diverting means are
  controlled by a drag-and-drop operation performed on said representation
tree structures.
  33. System according to claim 31 taken in combination with claim 23, characterized in that the referencing means are controlled by a drag-and-drop operation carried out on said representation.
tree structures.
  34. System according to one of claims 1 to 33, characterized in that
  it further comprises contribution notation means according to the result suggestions for adding information between two sets of organized information. 35. System according to claim 34, characterized in that the contribution notation means comprise a plurality of contribution variables able to vary in one direction when a suggestion of adding information is accepted and in the opposite direction when a suggestion to add information is refused. 36. System according to claim 35, characterized in that provision is made
  a contribution variable per pair of organized information sets.
  37. System according to one of claims I to 36, characterized in that
  it further comprises similarity notation means between information accessible via two containers belonging to two sets of organized information, depending on the number of information added after suggestion of a
  container towards the other and vice versa.
  38. System according to claim 37, characterized in that the similarity notation means comprise a plurality of similarity variables able to vary in one direction when a suggestion of adding information is accepted and in the opposite direction when information the addition of which was previously
accepted is deleted.
  39. System according to claim 38, characterized in that it is provided
  a similarity variable per pair of corresponding containers.
  40. System according to one of claims 34 to 39, characterized in that
  the means for establishing correspondence between containers of two sets of organized information are able to be implemented between two containers not previously corresponding in pairs, but belonging to a chain of containers corresponding two by two, in a function of the value of the contribution and / or similarity variables in relation to the sets
  associated organized information.
  41. System according to one of claims 34 to 40, characterized in that
  that it includes means to neutralize the suggestion process between organized sets of information when a contribution notation and / or
  similarity concerning said sets is less than a threshold.
  42. System according to one of claims 1 to 41, characterized in that
  that the means of intercommunication are able to suggest said addition of information
for a limited time.
  43. System according to one of claims 1 to 42, characterized in that
  when adding a container to a set of organized information, provision is made for determining whether the container is susceptible in itself or not
  to be mapped to another container.
FR0007249A 1999-11-10 2000-06-06 System for sharing information on a computer network Withdrawn FR2805375A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR9914151A FR2805373A1 (en) 1999-11-10 1999-11-10 System for sharing data between two or more users of computer system, uses organization of data into first and second containers, with communication between them, and uses XML documents for structuring data
FR0004207A FR2807179A1 (en) 2000-04-03 2000-04-03 System for sharing data between two or more users of computer system, uses organization of data into first and second containers, with communication between them, and uses XML documents for structuring data
FR0007249A FR2805375A1 (en) 1999-11-10 2000-06-06 System for sharing information on a computer network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0007249A FR2805375A1 (en) 1999-11-10 2000-06-06 System for sharing information on a computer network
PCT/FR2000/003157 WO2001035269A2 (en) 1999-11-10 2000-11-10 System for sharing data between at least two users on a computer network

Publications (1)

Publication Number Publication Date
FR2805375A1 true FR2805375A1 (en) 2001-08-24

Family

ID=27248641

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0007249A Withdrawn FR2805375A1 (en) 1999-11-10 2000-06-06 System for sharing information on a computer network

Country Status (2)

Country Link
FR (1) FR2805375A1 (en)
WO (1) WO2001035269A2 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6968334B2 (en) 2001-05-15 2005-11-22 Nokia Corporation Method and business process to maintain privacy in distributed recommendation systems
US7340214B1 (en) 2002-02-13 2008-03-04 Nokia Corporation Short-range wireless system and method for multimedia tags
US7102640B1 (en) 2002-03-21 2006-09-05 Nokia Corporation Service/device indication with graphical interface
GB2481191A (en) 2010-02-25 2011-12-21 Sita Information Networking Computing Ireland Ltd Graphical development tool for software application development
SG190038A1 (en) 2010-12-21 2013-06-28 Sita N V Reservation system and method
US9460412B2 (en) 2011-08-03 2016-10-04 Sita Information Networking Computing Usa, Inc. Item handling and tracking system and method therefor
GB2499288A (en) 2012-02-09 2013-08-14 Sita Inf Networking Computing Usa Inc Path determination
US9087204B2 (en) 2012-04-10 2015-07-21 Sita Information Networking Computing Ireland Limited Airport security check system and method therefor
US10320908B2 (en) 2013-03-25 2019-06-11 Sita Information Networking Computing Ireland Limited In-flight computing device for aircraft cabin crew
GB2515142A (en) 2013-06-14 2014-12-17 Sita Information Networking Computing Ireland Ltd Portable user control system and method therefor
GB2523441A (en) 2014-02-19 2015-08-26 Sita Information Networking Computing Ireland Ltd Reservation system and method therefor
US10001546B2 (en) 2014-12-02 2018-06-19 Sita Information Networking Computing Uk Limited Apparatus for monitoring aircraft position

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768578A (en) * 1994-02-28 1998-06-16 Lucent Technologies Inc. User interface for information retrieval system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768578A (en) * 1994-02-28 1998-06-16 Lucent Technologies Inc. User interface for information retrieval system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KAMIYA K ET AL: "Grassroots: A system providing a uniform framework for communicating, structuring, sharing information, and organizing people", COMPUTER NETWORKS AND ISDN SYSTEMS, NORTH HOLLAND PUBLISHING. AMSTERDAM, NL, vol. 28, no. 11, 1 May 1996 (1996-05-01), pages 1157 - 1174, XP004018217, ISSN: 0169-7552 *
RUCKER J ET AL: "SITESEER: PERSONALIZED NAVIGATION FOR THE WEB. BOOKMARKS CAN BE A KEY COMPONENT FOR GATHERING PREFERENTIAL INFORMATION", COMMUNICATIONS OF THE ASSOCIATION FOR COMPUTING MACHINERY, ASSOCIATION FOR COMPUTING MACHINERY. NEW YORK, US, vol. 40, no. 3, 1 March 1997 (1997-03-01), pages 73 - 75, XP000689873, ISSN: 0001-0782 *
SUSAKI S ET AL: "Information sharing system on the WWW with interactive communication", COMPUTER NETWORKS AND ISDN SYSTEMS, NORTH HOLLAND PUBLISHING. AMSTERDAM, NL, vol. 30, no. 1-7, 1 April 1998 (1998-04-01), pages 747 - 749, XP004121477, ISSN: 0169-7552 *

Also Published As

Publication number Publication date
WO2001035269A2 (en) 2001-05-17
WO2001035269A3 (en) 2003-01-09

Similar Documents

Publication Publication Date Title
Rennison Galaxy of news: An approach to visualizing and understanding expansive news landscapes
Quan et al. How to make a semantic web browser
US9471670B2 (en) NLP-based content recommender
EP1143356B1 (en) Meta-document and method of managing meta-documents
TWI493367B (en) Progressive filtering search results
AU2006315818B2 (en) System and method for information retrieval from object collections with complex interrelationships
US9384245B2 (en) Method and system for assessing relevant properties of work contexts for use by information services
US8819003B2 (en) Query refinement based on user selections
US7895595B2 (en) Automatic method and system for formulating and transforming representations of context used by information services
US20070038610A1 (en) System and method for knowledge retrieval, management, delivery and presentation
US8745162B2 (en) Method and system for presenting information with multiple views
US20070130186A1 (en) Automatic task creation and execution using browser helper objects
US20090307205A1 (en) Friendly search and socially augmented search query assistance layer
US20070016563A1 (en) Information nervous system
Baca Introduction to metadata
Karger et al. Haystack: A customizable general-purpose information management tool for end users of semistructured data
US20100313252A1 (en) System, method and apparatus for creating and using a virtual layer within a web browsing environment
Rogers Digital methods
US20110213750A1 (en) Idea page system and method
Chen Information visualisation and virtual environments
Domingue et al. Magpie: supporting browsing and navigation on the semantic web
US8495099B2 (en) Method of manipulating information objects and of accessing such objects in a computer environment
JP2006522388A (en) Systems and methods for acquiring, managing, capturing, sharing, discovering, communicating and presenting semantic knowledge
US8005832B2 (en) Search document generation and use to provide recommendations
US8442996B2 (en) Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefore

Legal Events

Date Code Title Description
ST Notification of lapse