FR2814263A1 - METHOD FOR CONSULTING COMPUTER DOCUMENTS AND SYSTEM THEREOF - Google Patents

Abstract

The invention relates to a method of consultation by at least one user of an original computer document corresponding to an original file (A. ext1) of a given format and saved in a computer memory location (Ei) designated by an address, the method being intended to be implemented with an operating system which comprises means for storing files and means for displaying the original document on a visual interface such as a screen, the method comprising displaying on the visual interface of graphic overloads superimposed on the original document, in a frame linked to the original document, and the storage of said overloads in association with the original document in a dedicated memory location (Eu1) so that the integrity of the original file n is not compromised by the superposition of overloads, characterized in that the stored overloads are personal to each user and his t stored in an individual memory location (Eu1) which is personally associated with the user. The invention also relates to a system for implementing this method.

Description

The present invention relates to a document consultation method

  computers, and a system for implementing such a method. A "document" can be defined as a set of information that can be displayed simultaneously on a medium. Previously, this medium was generally paper. Now, a document can also be presented on a computer screen. In the rest of this text, these two types of document will be designated as "paper document" and "computer document", it being understood that when the general term "document" is used alone, it designates a document relating to the present invention , ie a "computer document". Such a document is generally stored in a computer system in the form of one or more files, possibly associated with links

various types.

  Computer documents are now an extremely common medium for exchanging information, tending to add to or replace traditional paper documents

many cases.

  As such, it would be advantageous to give each reader the possibility of annotating the documents by providing comments, enrichments, questions ..., as it is known to do on

paper documents.

  In general, the known systems for processing and managing computer documents certainly allow the enrichment of the file, but the overloads brought are in reality modifications of the file (s) in which these are stored. document information; these modifications alter the structure of this file (s) because the recording of the modifications requires the recording of the whole of the

modified file (s).

  And the fact that the structure of the file (s) is altered implies, in addition to the need to mobilize memory capacities for the recording of the modified versions, a greater complexity of the management of the different versions of files (conservation of the versions

  previous versions, replacement with new versions ...).

  Systems are also known which make it possible, when displaying a document corresponding to one or more files, to superimpose on the screen an additional level of information over the display of the document, the additional information being recorded separately. so that the structure of the file (s) corresponding to the document is not altered. The Thirdvoice (registered trademark) system is an example

of such a system.

  With such systems, several users can consult a document with overloads (or the document itself without its overloads), while the integrity of the corresponding file (s) is respected. But a first important drawback of these systems is that they

  impose a single version of the surcharges for all users.

  However, it would in many cases be preferable to allow different users to add their personal overloads to a document and to be able to view and share the document provided only with these specific overloads, without imposing on all users the same version of the document with the same overloads so everyone could adapt their overloads to their own needs and objectives (as is the case with paper documents, which everyone can overload at their own

  guise, thus "appropriating" the document).

  In addition, these known systems store overloads in a single, centralized memory location, for example a centralized server on the Internet. This also constitutes a

  disadvantage because it makes the system more difficult.

  The object of the invention is to propose an improvement to the systems

  mentioned above, avoiding the drawbacks mentioned.

  In order to achieve this object, the invention proposes, according to a first aspect, a method of consultation by at least one user of an original computer document corresponding to an original file of a given format and saved in a computer memory location designated by an address, the method being intended to be implemented with an operating system which comprises means for storing files and means for displaying the original document on a visual interface such as a screen, the method comprising: A . the call of an original document by a user, B. the display of the original document on the visual interface, C. the display on the visual interface of graphic overloads superimposed on the original document, in a linked reference to the original document, D. and storing said overloads in association with the original document in a dedicated memory location so that the integrity of the original file is not not compromised by the superposition of overloads, characterized in that the overloads stored during step D are personal to each user and are stored in an individual memory location which is personally associated with the user. Preferred, but non-limiting aspects of the method according to the invention are as follows: in step D comprises the creation of an overload file which is associated with the original file and with the user, the associated file containing relative information to the original file, Each user can modify the overloads of the associated file, ò the graphic overloads can constitute zones that can be activated by any user to generate a character string, ò the character strings are associated with function commands of the system operation, the associated file contains the name of the original file and information allowing to characterize the location and appearance of the graphic overloads, ò prior to step D each user can modify his individual memory location so that the storage of overloads can be carried out in any individual memory location desired by the user, the method comprises, between steps A and B, the automatic search, in the individual memory location of the user, for the overload file associated with the original document, a during step C, the overloads displayed are those of the file associated with the original file and with the user, so that different users, by calling the same original document, will cause the display of the respective overloads which are individually associated with them, superimposed on said original document, when step C the user has the possibility of modifying the overloads, To the associated file is stored in a specific associated format

in the original file format.

  According to a second aspect, the invention also provides a system for consulting an original computer document corresponding to an original file of a given format saved in a computer memory location designated by an address, the system being intended to be put into operation. works with an operating system which comprises means for storing files and means for displaying the original document on a visual interface such as a screen, the system comprising means for ensuring respectively: A. the call of an original document by a user, B. the display of the original document on the visual interface, C. the display on the visual interface of graphic overloads superimposed on the original document, in a reference linked to the original document, D. and storing said overloads in association with the original document in a dedicated memory location so that the integrity of the original file is not c omitted by superimposing overloads, characterized in that the system comprises means for storing overloads in an individual memory location which is personally associated with the user so that said overloads

  are personal to each user.

  Preferred, but non-limiting aspects of the system according to the invention are as follows: ò said overload storage means comprise means for creating an overload file which is associated with the original file and with the user, the associated file containing a information relating to the original file, the system comprises means for allowing each user to modify the overloads of the associated file, A the system comprises means for associating with the graphic overloads a function for generating a character string, said function being able to be activated by a user, the character strings are associated with operating system function commands, the associated file contains the name of the original file and information used to characterize the location and appearance of graphic overloads, the system includes means to allow each user to change their location nt of individual memory so that the storage of overloads can be carried out in any individual memory location desired by the user, the system includes means for automatically searching, in the individual memory location of the user, for the file overloads associated with the original document, ò the overloads displayed are those of the file associated with the original file and with the user, so that different users, by calling the same original document, will cause the display of the respective overloads which are individually associated with them, superimposed on said original document, ò the system includes means to allow the user to modify the overloads, ò the associated file is stored in a specific associated format

in the original file format.

  Other aspects, aims and advantages of the invention will appear better

  on reading the following description of an embodiment of

  I'invention, made with reference to the accompanying drawings in which In Figures 1, 2 and 4 are schematic representations of the structure of a system implementing the invention, Figure 3 is a flow diagram schematically representing the main steps d 'a process of selection and processing of character strings implemented in the invention, ò Figures 5 and 6 are flow diagrams schematically representing the main steps of the search process

  files implemented in the invention.

  In the preamble to the description which follows, it is specified that if this

  description constitutes a support intended to establish patent protection,

  it does not in any way constitute an infringement of other intellectual property rights attached to the system described below, in particular copyright. Referring first to Figure 1, there is shown generally

  by reference 10 means for permanent storage of files.

  As will be seen, these means may include several locations, connected by data transmission means (which can implement private or public networks, in particular the Internet) but which are not necessarily physically grouped, each memory location possibly corresponding to a support

  different physics, of any type known per se.

  In the rest of this text, the means 10 will generally be designated by the general term "memory", said memory comprising a plurality of locations which can each be identified by a

address.

  A unit 20 has also been shown connected to an operating system of the window type or not (the particular embodiment described below implementing, without limitation, a system

window operation).

  The operating system, known per se, makes it possible in a known manner to call, display, edit and save files, the unit 20 comprising interface means allowing a user to perform operations on edited files (display screen, mouse and input keyboard for example). This unit 20 can be a computer

any type.

  Unit 20 is globally connected to memory 10 by a link 30

  allowing the transfer of data and files between these two elements.

  The link 30 can be of any known type, using wired components (conventional or high speed link), non-wired components (radio link, infrared link, etc.) or a combination of the two types of link. To open on the unit 20 a work session of the system according to the invention, a user must, after launching the operating system, declare a username ul which is registered in a location

Memory usage 10.

  To this end, the system according to the invention implements a program P which is located in a location E0 of the memory 10 (the location E0 can be physically integrated into the unit 20) and the user of which launches the execution, which causes on the screen of the unit 20 the opening of a window F1 dedicated to the program P. Inside this window F1, the program also opens a sub-window F2 for entering the name d 'user. Once the user name ul has been declared in this pane, this user name will remain stored in the Eutil memory location for the duration of the work session (i.e. while the P program is active) , but also after the end of this session. The Eutil memory location thus stores the name

  user permanently.

  Eutil can also contain references specific to the user (password securing the opening of a session under the name ul, ...) and to the last session carried out by this user (open screens, files viewed ... ). As said, the system according to the invention is intended to operate with an operating system, the two systems being interfaced together. Thus, within a work session, a user can call up on the screen files contained in

memory locations Ei 10.

  The memory locations Ei can constitute a single location, or a plurality of distinct memory locations, each of which can be a specific directory of the same memory disk, or a location in a memory disk or a specific server (said server can be a private or publicly accessible server (via the Internet for example), or a location on a recordable data carrier such as a CD-ROM, or any other

known memory type.

  The files stored in the Ei locations can be of any known type compatible with the window operating system, their format being specified by the type of extension of the file (.doc, .xls, .wav, gif ,. jpeg, .htm, .html, .xml, .ppt, .pdf, etc ...). The system according to the invention is in fact designed to process any type of known file, and has for this purpose

  effect of interfaces with the operating system.

  We will now describe the general functioning of the system

according to the invention.

  Or a file A from a location Ei, the file A being in extl format (extl can designate any type of extension known per se - htm for example). Within a work session, the user opens the A.extl file and displays the corresponding document in a new window on the screen of the unit 20, included in the window F1 of the program P. It is known that the operating system allows the user to modify this document and save its modifications by replacing the old version of the A.extl file with a new version with the modifications made ("save" function), or by saving the last modified version in a desired memory location ("save as ..." function). We will see that the system according to the invention (which will hereinafter simply be called "the system" for convenience), which is intended to be combined with the operating system, offers

far superior possibilities.

  Indeed, the program P which is active permanently allows the user declared under the name ul to carry out overloads which are personal to him on such a document corresponding to the file A.extl, without

  alter the integrity of the A.extl file as we will see.

  The notion of "control" of the system should first be defined. A command is a character string recognizable by the system, which causes the execution of an action by the system (this one

  using the operating system for this).

  To do this, the character string to be recognized must be supplied to the system; practically, this can be done in particular in two ways: ò the user directly enters the character string in a window called by an additional program associated with the program P, this additional program can itself be called by a specific button of the window F1 that the user activates, TO or the character string was itself produced by a

ordered.

  The system recognizes the character strings obeying a predefined format and stored in a specific memory location (which can be the EO location). It is thus possible to define in the system functions which can be executed by a character string formulated according to a certain syntax. We can for example define the following associations character string Associated function # A.extl Open the file A.extl & A.extl Open the file A.extl (without displaying the links contained in this file)> message, x, y Edit the message in a window at location (x, y) <sound Execute a sound ^ program, a, b, c Execute the program with parameters a, b, c @glossary Activate a glossary (this term will be explained later) * localization Add a localization (this term will be explained below) ma, b, c Add an overload (this term will be explained below) with the parameters a, b, c Several character strings can also be supplied to the system "in one only once ", each character string being separated from the next by a semicolon (case of direct input of the command by the user). In this case, the system processes the character strings

one after the other.

  It will be noted that the character strings can be transcoded in different form, for example signals which do not correspond to characters that can be displayed on the screen; this variant may be useful for reasons of confidentiality. You can also define character strings in the form of a single character which saves

from memory.

  It is possible to improve the ergonomics of the system by defining in the window F1 a set of menus and buttons allowing

  the user to quickly access a plurality of commands.

  Thus, taking the case of the file A.extl1, the user has: ò a command to open on the screen the document corresponding to the file A.extl (or to any other file of the memory locations Ei, whatever its format), ò and commands activating a menu called "overload" which allows the user to superimpose on the screen on the document corresponding to the file A.extl (which will be called "the original file", the associated document being the "original document") of

  overloads (or graphic objects), on the same editing screen.

  For this, the user uses the mouse of the unit 20 which makes it possible to position the overloads in desired locations of the editing window (or of the screen in the case of an operating system without window), and to size them. These graphic objects are thus superimposed on the original document at locations determined by coordinates linked to the mark of the original document, so that when this original document is edited, the overloads are fixed relative to the elements of this document and move with these elements when scrolling through the content of the document. The overloads can be surfaces with a configurable aspect, and be associated as we will see with

system commands.

  When the user opens the original document corresponding to A.extl and superimposes overloads, the system according to the invention automatically creates a so-called "associated" file A. @ extl with which a specific extension is associated (thus the system according to invention will associate a 1 1 associated file A. @ doc with an original A.doc file, a file A. @ gif with a

original file A.gif, etc ...).

  The associated file A. @ extl which includes all the overloads made by the user ul to the document corresponding to the original file A.extl, is saved by the system in a memory location Eul individually associated with the user ul. Eul's address was defined by the user during his first working session (the system offers the user a default address). This address is stored in association with ul in the Eutil memory location, so that the file A. @ extl is associated by the system with the original file

A.extl and username ul.

  In the rest of this text we will define Eul as the "folder

personal "of user ul.

  The Eul address is an important parameter of the system according to the invention since it makes it possible to associate individually with each user a save address for the associated overload files of the type of A. @extl. This address can be subsequently modified by the user during any work session declared under the name ul, by recalling with a

  dedicated command (activated by the menu in window F1) the sub-

  F2 window for entering the user name, which also includes a field allowing you to modify the backup address (or the addresses of

backup as we will see).

  The user can thus add overloads to an original document corresponding to an original A.extl file, said overloads being saved in a specific file associated with A. @ extl and which can have any desired appearance (shape, color, size, association with a icon or a

  image ...) thanks to commands to configure these aspects.

  The user has, at any time, the possibility of recording the overloads which he has made to a file by a dedicated command of the system, which causes the associated file A. @ extl to be saved in the

personal file Eul of ul.

  It should be noted that for the user, the overlay of the documents associated respectively with the A.extl and A. @ extl files in the same window is "transparent", that is to say that the user processes a window d single edition, which displays an overlay of the content of the original A.extl document and overloads of the "associated" document A. @ extl which corresponds to the file A. @ extl, like a single document in appearance, the file A. @ extl providing a "layer" which "plates" overloads on the original document in places of this original document chosen by the user. When the user thus opens the document corresponding to the A.extl file, nothing indicates to him that the overloads of the associated "layer" file A. @ extl are superimposed on him, so that the user processes in appearance

a single entity.

  When a user declared under the name ul then opens the document corresponding to A.extl, the system automatically searches in Eul which is the personal folder of ul (and possibly in other memory locations defined in the system as will be seen further on about "localization lists"), the existence of an associated file named A. @ extl, and automatically superimposes in the editing window the overloads of the associated file A. @ extl on the original document, if an A. @ extl file was detected in Eul. Otherwise, only the document associated with A.extl is displayed. In all cases, it is necessary to execute a command activating the overload menu

  to add or modify overloads on A.extl.

  In this way, the system according to the invention allows each user name (ul or other) declared in the system to have its personal version of overloads made to the same original document while the integrity of the file corresponding to this document is preserved, the original file undergoing no modification. The associated overloads are automatically superimposed on the original document of

  so that the user apparently manipulates a single document.

  When creating the overload file A. @ extl associated with the original A.extl file, the system also creates a description of this associated file. The description is a set of information concerning the associated file A. @ extl, recorded in the file A. @ extl, in the location

from memory Eul.

  This set of information does not appear directly on the screen when the documents corresponding to the A.extl and A. @ extl files are opened, but the user can call it by a specific command in order to

  view the information it contains, and modify it if necessary.

  The description thus contains among others the following information To name of the associated file (A. @ extl), To name of the original file (A.extl), To title (this title will be the one that will be displayed at the top of the editing window of the superimposition of A.extl and A. @ extl - it defaults to the name of the original A.extl file but can be modified by the user), has version information and update date (filled in automatically by the system),

  description (free text area that can be filled in by

  the user), information on the overloads of the file A. @ ext1 (coordinates, appearance, associated commands - we will explain below the association of a command with an overload), glossaries associated with the file (this notion will be specified in the

continuation of the text).

  According to the invention, it is also possible for the same user to modify the user name under which he is declared within the same working session. A user U1 can thus no longer declare himself under the name ul but under the name ul ', which will be stored in a file dedicated to the Eutil location and to which corresponds a personal folder Eul' whose system stores the address in Eutil, in association with the

name ul '(see figure 1).

  In this case, if the user then opens the document corresponding to the A.extl file, he will not have access to the overloads made under the name ul and stored in the file A. @ extl located in the Eul personal folder of ul . It can on the other hand bring other overloads, different, that the system will memorize in another file also named A. @ extl but which will be saved in a personal Eul 'folder

  username ul ', different from ul's personal folder.

  When a user logs in to the system with the user name ul and calls A.extl, the system will look for an associated file A. @ extl in Eul the personal folder of ul, and the user will have access to the overlay of A.extl and overloads of the associated file version corresponding to the Eul personal folder of ul.

  When the user logs in under the user name ul 'and in the same way calls the same document corresponding to the file A. extl, these are the overloads of the version of the associated file corresponding to the personal folder Eul' of ul 'which 'it will display because the system then searches for the associated file in Eul' the personal folder

of ul1 '.

  The user can also open several working sessions in parallel by launching several executions of the program P which each cause the opening of a sub-window Fi of the window F1, and declare themselves

  so under several different user names.

  As we said, overloads are graphic objects which can have a desired appearance and be associated with commands from the

1 5 system.

  More precisely, the system according to the invention allows the user to configure, by means of dedicated commands: The appearance of the graphic area of the overload (shape, color, thickness of the contour lines, size, inclusion and text format, replacement by an icon or an image, etc ...), * the function of the graphic area. If this can be an "inert" zone that can only contain text (for example an overprint equivalent to a "post it" (registered trademark) placed in the margin of a document, in order to provide a comment or to ask a question about this document), it can also be

an activatable zone.

  In the latter case, the user can associate a command to the graphics area which triggers an action as explained at the beginning of this text. This command will be activated during subsequent consultations of the overlay of the document corresponding to the original file and its overloads, for example by moving a cursor using a mouse on the graphic area and clicking on it. In this way, it is possible to associate with the overload any command of the system and to

make the overload active.

  The surcharges can thus include links to objects or documents of any address (file opening command), including hypertext links to pages of Internet sites, said links being able to be activated by a simple mouse click on the corresponding overload. In this way, it is possible according to the invention to associate with the overload

  any command from the system and make the overload active.

  And this notion of "active overload" is an element

  particularly advantageous of the invention.

  It is specified that in the case of a command to open another file, the system offers the possibility of "marking" the document corresponding to the called file, by an overload affixed automatically in a determined place of the document thus called (by example at the top left of its editing window), in order to view the link

  thus established between the two documents.

  It is possible to configure the system so that overloads associated with a command are invisible on the screen. It is also possible to permanently activate a "comment" function on the overloads on which the cursor is located (signal of the presence of a

  overload - useful when the overload is invisible, description of the

associated command ...).

  It is therefore understood that the system according to the invention is a flexible and powerful tool for processing and managing documents, which allows a user to personalize original documents by adding graphic zones, comments, commands or links in order to adapt the document to its environment and to its particular needs,

  this without altering the integrity of the original files which remain unchanged.

  It has been said that the description of an A. @ extl file associated with an original A.extl file includes a link to the original file, that is to say the address of the original file. The user can also modify this attachment, and associate the file A. @ extl with another original file (of the same type as the first original file or not), for example B.ext2 (ext2 designating a type file may be different from en.extl files). In this case, when the user executes a command to then open the document corresponding to the file A.extl, the system automatically searches for an associated file A. @extl in the personal folder of the user, finds there A. @ extl and reads the attachment file from its description. The description of this associated file now referring to B.ext2, the system causes the opening of the document corresponding to this second original B.ext2 file with the overloads of A. @ extl

  superimposed, not the opening of A.extl.

  This possibility is advantageous, for example in the context of managing successive versions of an evolving original file. Either the original file A.extl, it is then possible to attach the associated file A. @ extl to a desired version of this original file (latest version by

  example), by updating the description of the associated file A. @ extl.

  In this way, several different original files which are all named A.extl, corresponding to different versions of a document, can be saved in different memory locations (successive backup discs for example ...); in all cases the execution of the command to open A.extl will cause the edition of the

  desired version determined by updating the description of A. @ extl.

  It is also possible to define for several different user names access to different versions of the original file A. extl, or to another original file, by attaching the associated file A. @ extl of each user to a specific version of the original file or to the other

original file.

  Thus, by calling the same A.extl file, the different users will have access not only to overloads which can be different, but also to original files which can be

also different.

  With reference now to FIG. 2, a second aspect of the system according to the invention will be described, which can advantageously be implemented in combination with the system for creating and managing

overloads described above.

  This figure shows the memory 10, the unit 20 and the link 30.

  Also found in the memory 10 are the locations Ei for storing the original files, the location E0, the location Eutil containing the names of users and the addresses of corresponding personal folders, and locations Eul and Eul 'which are folders personal. When creating a user name ul, the system according to the invention not only creates a personal folder Eul which will be the storage location for the overload files associated with original files that the user ul consults, but also a file of type "glossary", Keywords. @ dy, which is empty when created and that the system

  saves ul's personal file in Eul.

  This glossary is a file intended to contain a series of character strings which will be called "keys", each key being able to form one or more words, or not. In the glossary, each key is individually associated with a command such as those mentioned above (display of a message on the screen, opening of a file, etc.), or else with another character string which does not necessarily have the format of a

  command whose syntax is recognized by the system.

  The ul user has the possibility to edit and modify this glossary, by adding, deleting or modifying pairs (key, command) or

  more generally (key, character string).

  The user can also activate and deactivate this glossary. To activate the glossary, the user simply has to open the corresponding Keywords. @ Dy file, directly using the operating system, or via a dedicated command from the system. The glossary is thus present in the RAM of unit 20

when activated.

  If the Keywords. @ Dy glossary is activated, any "selection" of one of the glossary keys will cause the associated command to be executed. We will see with reference to Figure 3 what are the main

  Ways to Perform Such a "Selection" of a Key.

  Each ul user thus has a personal glossary which allows him to associate specific commands with certain

  strings that can be selected.

  When an ul user opens an original document corresponding to an A.extl file and associates an A. @ extl file with it as described above, he also has the possibility of creating and linking to the associated file A. @ extl, a glossary A. @ dy which will thus be associated with the couple (ul user, file

associate A. @ ext1).

  Like the personal glossary Keywords. @ Dy, such a glossary A. @ dy called "document" is created by the system with an extension in 5. @ dy in order to be recognizable by the system according to the invention. This glossary, stored in the associated file A. @ extl, is automatically active when the user displays on the screen the document corresponding to the file A. @ extl. On the other hand, the document glossary is not active when the document editing window corresponding to the file A. @ extl, to which the glossary A. @ dy is linked, is not the window which is selected (each opening opening a window inside

  window F1 which is the application window of the system according to the invention).

  According to the invention, the user can also integrate into any glossary a command called "initial command" which will be executed when the glossary is opened. This command can be of any type mentioned above. And a third specific type of glossary that a user can create is the "application glossary". Such a glossary is an @dy file which is "associated" with the launching of a desired application in the operating system. In this case the application glossary comprises an initial command which launches the application and the opening of the application glossary causes the execution of a first command of

  the application, said glossary remaining active for the application.

  It is also possible to create one or more independent glossaries, thanks to a dedicated system command. We can thus create at will files with a specific extension. @ Dy, which

  can be active on demand.

  It is thus possible to create and modify several types of glossaries containing pairs of character strings, the first of which is a

  key and the second can be a command recognized by the system.

  Figure 3 shows different ways of "selecting" a character string to activate a command associated with it in a

active glossary.

  Thus, it is first of all possible for this to: select the character string in a document being displayed on the screen, for example using the mouse. We can thus define a character string and click on it, which causes the selection of the character string (step 300), and it is also possible to directly enter the character string on the keyboard of unit 20, the system allowing call

  a dialog box for making such an entry (step 301).

  * another alternative is the selection of the character string by the system itself (step 302). Such a selection may result for example from the selection by the user of an active overload of a document displayed on the screen, said active overload generating the character string (step 303). Such a selection can also result from the execution of an initial command following the opening of a glossary (step 304), À and it is also possible for the user to display the glossary on the screen and to directly select a character string which constitutes a key of said glossary, in an editing window of the

glossary (step 305).

  Steps 300 to 305 are (non-limiting) alternatives for selecting a character string. The selection of the character string causes the activation of a function of the system which consists in processing the selected character string (step 306). Schematically, this function performs the following steps: * verification (step 307) that the character string has not yet been processed, an indicator of the system linked to the string

  characters being created when processing the character string.

  Thus, if the system does not detect such an indicator, the function continues its processing as we will see. If, on the contrary, the system detects an indicator of a processing carried out on the character string, the processing function ends (step 308) by canceling the indicator at 309 in anticipation of subsequent selections of the character string, À in the case no indicator associated with the character string was detected, the processing function creates such an indicator at 310 (so that if this indicator is not canceled, during a next processing of the same string characters the processing function will end in 308), after step 310, the processing function analyzes in 311 the character string. To this end, this function implements means such as means for splitting the character string into "words" and syntactic recognition means, at the end of this analysis, during a step 312, if the chain of

  characters is a system command as mentioned above

  above the processing function executes in 313 this command and cancels in 314 the indicator created in 310. If on the contrary the character string does not correspond to any command recognized by the system, the processing function consults in 315 the glossaries

  assets (the terms of this consultation being detailed below)

  below) to determine in 316 if the character string is a key of an active glossary, À if the character string is not a key of a glossary, the processing function ends in 317 by canceling in 318 l indicator generated in 310, A if the character string is a key in an active glossary, the processing function generates in 319 the character string corresponding in this glossary to said key, which constitutes an additional means of selecting a string characters to activate the processing function again in 306

  the new character string generated in 319.

  We note that during a work session, several glossaries can be active at the same time. To resolve the conflict problems which could arise during step 315 in the case where the same key is associated in two different glossaries with two different commands, the two glossaries being active at the same time, a default order of priority is provided : when a character string is selected in one of the ways described above, the system consults, during this step 315, in the order: a the "document" glossary of the file whose editing window is selected, ò then the glossary of the application linked to the format of the edited file, if it exists, finally the user's personal glossary (glossary of

keywords Keywords. @ dy).

  As soon as the system detects a key corresponding to the character string which has been selected, the corresponding command is executed and the system stops consulting the glossaries, and proceeds to step 316. It should be noted that this order of priority can be neutralized by the choice of an option in which the system presents the user with all the glossaries containing a key corresponding to a selected character string, the user then being able to choose the glossary he wishes to use. It will be noted that in the case where the user selects on the screen the desired character string in the displayed document (step 300), it is possible according to a variant of the intervention to highlight graphically the character strings which are keys to an active glossary. In this case, all the keys of the active glossaries are systematically highlighted graphically inside the selected window, in which the user displays an A.extl document.

  likely to contain such keys.

  This highlighting can be done by a modification of the font and / or the color of these characters, in a similar way for example to the highlighting of hypertext links in

many existing applications.

  This produces a hypertext link which can be described as "inverted", because it is not the author of the document here who freezes the hypertext link once and for all as in the case of a conventional hypertext link; on the contrary, the hyperlink can change depending on the active glossary. And it is thus possible to automatically create a link specific to a given user (or group of users), so that

adapt the link to the user.

  According to an advantageous aspect of the invention which can be combined with the preceding aspects, the system according to the invention also makes it possible, as will now be seen, to manage access to

different files and documents.

  It has been said that the system allows the user to call A.extl files stored in memory locations Ei; for this purpose the system is interfaced with the operating system. According to the invention and as shown in FIG. 4, during each work session for which the user declares himself under a name - ul for example - the system also offers the user the possibility of defining an ordered list LOC1 d '' memory addresses (each of which can correspond to any memory location in a network configuration or not, each location can be located

  on any physical medium known per se).

  This LOC1 list which will be called "localization list" constitutes a file saved by the system in the Eutil location, in association

  with the username ul under which the user is declared.

  The list can be consulted and modified at any time by the user (including to change the order of addresses), by calling the sub-window F2 which is edited when the user connects to the system and which contains the

  session-specific and user-specific settings.

  A user can select a desired location list, and modify their selected location list. He may also not have selected any location list. In any event, only one

  location list can be selected by both a user.

  If a location list such as LOC1 is selected by the user, the system according to the invention automatically constitutes an ordered list of addresses called "search list>", in which the address of Eul the personal file of the user tops the list,

  followed by the ordered addresses of the selected location list.

  If now no location list has been selected by the user, the search list consists by default of the only

Eul personal file address.

  In the known case of the simple implementation of an operating system, the user wanting to open an A.extl file must specify the address of the file by specifying the directory tree leading to

  The storage location of the file.

  In the case of the invention, on the contrary, when the user calls an A.extl file, he does not have to specify the address of this file. If however it does, the system will anyway ignore this address first and will automatically consult the addresses in the search list, in their order according to this list, to search successively in each of the locations corresponding to these respective addresses

an associated file named A. @ extl.

  As soon as the system detects a corresponding associated file A. @ extl

  to this search, he opens it and does not continue his search.

  In the event that this search is unsuccessful, the system will ultimately search in the address specified by the user when

  command to open A.extl, if such an address has been specified.

  More precisely, FIG. 5 represents the steps implemented when a user calls a file, whether it is original (of type A. extl) or

associated (type A. @ extl).

  In this figure, these two have thus been represented in 501 and 502

  first possible ways to call a file.

  If the user calls an original A.extl file in 501, the system automatically constitutes a request for the operating system to search for an associated file A. @ extl, which is equivalent to step 502

  in which it is the user who directly makes such a request.

  A file having thus been called in 501 or in 502 by the user, the system searches, successively in the various memory locations designated by the addresses of the search list, the file

associated A. @ extl (step 503).

  As soon as such a file A. @ extl is located in one of the memory locations in the search list, the system reads in 504 the name of the original file associated with A. @ extl and its title in the description of A. @ extl (this title can be, as we said, modified by the user). If this title is

  different from the name of the file, the system memorizes it (always in 504).

  If no A. @ extl file was found in the locations designated by the search list (nor as a last resort in a location designated by a possible address provided by the user when ordering to open in 501 or 502 ), the system automatically considers that the original file associated with A. @ extl has the name A.extl; this identification of the original file name from the file name

associated takes place in 505.

  After step 504 or 505, the system therefore has an original file name and searches in 506 in the locations of the search list for this original file. If it does not find it, the system stops

  search in 507 and the user request does not succeed.

  If, on the contrary, the original file sought (A.extl or other) was found in 506, the system proceeds in 508 to: on opening this original file found, 10. reading the title associated with this original file found in the description, and if this title is different from the name of the file, when the title read is memorized, the screen display of the document corresponding to the original file found, The screen display of the document corresponding to the associated file A. @ extl superimposed on the document corresponding to the file

  original, if such an associated file was found in 503.

  After having carried out these operations, the system updates in 509 two "historical lists" which are files similar to glossaries, one list being relative to the current working session and the other being permanent and

  updated during each session of the same user.

  These historical lists contain a set of pairs (title, file name), the system controlling the opening of a file associated with a

title when this title is called.

  For this update, the system fills in the "title" field with the first title read and stored in 504 or 508 and different from the file names in the description of which it is integrated or, if not, the name of the original file

identified in 506.

  The historical lists allow the user to call up files in a third way, different from steps 501 and 502: the user can indeed simply enter a title in 510, the system then determining

  in 511 whether this title belongs to a historical list or not.

  If the title belongs to a historical list, the system calls in 501 or 502 the file (original or associated) which is associated with the title in said

* listing. Otherwise, the user request does not succeed (end step 507).

  It is understood that by modifying his location list LOC1, the user has the possibility of modifying the search list so as to, by calling

  just a filename or title, actually open different files.

  The user thus performs a "dynamic localization" of the files he wishes to consult. It is also possible to activate an option "all documents>" in which the system does not stop its search when it has located during step 503 an associated file in one of the corresponding locations

  to an address in the search list.

  In this case, the system continues its search by scanning all the addresses in the search list, and opens on the screen the original file A.extl called, as well as all of the associated files named A. @ extl which could be located in the different locations corresponding to an address in the search list, these associated files

  then being all superimposed on the screen on the original file.

  More precisely and with reference to FIG. 6, after calling an original or associated file at 601, by means of a command corresponding to steps 501, 502 or 510 described with reference to the figure, the system scans at 602 - corresponding to step 503 of FIG. 5, all the locations of the search list, to constitute in 603 a set made up of all the pairs (associated file found; file

corresponding original).

  In 604, the system determines whether all the original files of the

  couples of this set are actually one and the same original file.

  If this is the case, the system displays on the screen the document corresponding to said original file, with all the documents corresponding to the

  associated files overlay (step 605).

  It is also possible in an option that the system offers the user a drop-down menu allowing to select the associated files of which he wishes to display the documents corresponding to the screen, in

overlay (step 606).

  If now the couples of the set constituted in 603 include different original files, the system proposes in 607 to the user to select an original file and displays the document

  correspondent with its associated documents.

  We therefore understand that by changing the location list (and / or personal folder), a user will open different files by

  executing the same command to open an A.extl file.

  It is also possible to save in different memory locations localization lists LOC1, LOC2, etc., corresponding to lists of memory locations containing different files. In any event, as we have said, only a list of

  localization is active both during a work session.

  If, for example, we consider the case of students and a professor connected to a network and working on a project, the professor can ask his different students to work on the same original X.htm file containing the statement of a problem. and the data

necessary for its resolution.

  To answer the questions, each student opens the document corresponding to the original X.htm file and creates an X. @ htm overload file which he stores in his own memory location to save his answers (which can be the folder student staff). Each student thus creates a different X. @ htm file, which may include overloads associated or not with commands, which can call different files (including Internet pages), the professor being able to call each of these associated files by selecting a list of location where the student's memory location is in

head of list.

  In this case, when the professor calls the file X.htm, the system superimposes on the document corresponding to the original file containing the statement, the document corresponding to the associated file of responses from

the chosen student.

  The teacher can also activate the "all documents" option described above and choose a location list in which the addresses of the respective memory locations in which the

  different students record their responses.

  In this case, by calling the X.htm file, the professor recovers on the screen the superimposition of all the answer files on the original question file; he can also select a memory location dedicated to a student from a list as mentioned for step 606 in

  reference to Figure 6, to view this student's responses.

  It thus appears that the user can manage the operating system with which the system according to the invention is interfaced, using a single simple file opening command, to access different desired files. Thus, depending on the context in which the user is located, he can access different files by executing the same file opening commands, only the desired location list to be

updated by the user.

  It can also do this by defining a command that automatically sets a given LOC1 location list as the active location list, depending on an environment of

desired work.

  We can for example think of the example of a speaker preparing in a preparation base a mission in the field, and using for this a location list which allows access to a first set of files by executing a given series of opening commands from

  file (said series can be described in a procedure).

  Once in the field, the user will need to deal with the same themes as during the preparation, but he will need different information which he will access by changing his active localization list so that the execution of the series of same order

  procedure will cause access to different files.

  A user U1 declared under the name ul can also constitute, with other users declared under names ui or even alone, a "group" G with which is associated a location EG of the memory 10

(shown in Figure 4).

  The declaration of a group is an operation analogous to the declaration of a user name, which requires choosing a location EG or "group folder" corresponding to a storage location for group-specific data, EG being for the group

  the equivalent of the user's personal file.

  A group is an entity recognized by the system, in the same way as a user, the group constituting a higher level of attachment of several users. And it is possible to associate a location list with a group, as for a user, and modify the

  group location list or change it.

  When opening a working session and editing the sub-

  window F2, the system offers the user the possibility of creating a group and defining an associated EG memory location, the user being able to

  to join or not to this group for the work session.

  Just as user names are permanently saved between two working sessions, group names and associated addresses remain in memory 10 (the user having the possibility of modifying the addresses of the groups or of deleting groups). When the user ul is attached to a group G, the system stores in the location Eul the address of the location EG associated with the group and constitutes the user's search list by following the address of the personal file. of the user by the addresses of the group search list, including the location list associated with the group if the group has one. Several different users can be linked to a

same group.

  In response to a command to open an A.extl file by ul, the system searches for an associated file A. @ extl in the search list composed of the address of the user's personal folder Eul followed by the

group search list.

  In this case, the system operates at both the user and group level, displaying on the screen the overlay: To documents corresponding to the original file A.extl, and documents corresponding to the associated files A . @ extl found in Eul and in the locations in the list of

group search.

  Thus, the user ul visualizes his own overloads, with those which

  are associated at group level.

  But if the user ul then brings new overloads, the overloads will be recorded only in the associated file A. @ extl of Eul the personal folder of ul. Any A. @ extl files associated with A.extl and saved in EG and / or in the group's localization list

are not changed.

  In this case, the overloads brought by the user to A.extl are specific to it and are not shared with the other users attached to the same group, because another u2 user attached to the same group G will not view the contents of file A. @extl saved in the folder

staff of ul.

  If another user u2 attached to the same group G calls A.extl, he will view the overloads brought to the group level (stored in EG), as well as any additional overloads associated with the group (designated by the group location list), but not those

  made specifically by ul declared as a simple user.

  And u2 can also bring its own overloads which will only be visible to it alone, by opening A.extl while it is declared

  like u2 whose personal file is that of u2 and not that of the group.

  Each user thus has the possibility of adding their personal overloads to overloads brought at group level, the

  personal overloads only visible to this user.

  The system also offers the user the possibility of declaring himself for a work session not simply as a user (ul. ..), but as a "group manager" (by an editable field in the sub -window F2, which allows the user to declare as his "folder

  staff "The EG location which corresponds to the group).

  In this case, the user's search list is assimilated to that of the group, namely the address of EG the location where the group is stored, followed by any ordered addresses from the location list.

associated with the group.

  And the user declared as manager of the group "is" the group, ie he can modify the location list associated with the group, or change the location list for the entire group. The access of a user at the "group manager" level can be protected by

a specific password.

  If the same user ul now declares that his personal file is EG, thus placing himself at the level of the group manager, the execution of an opening command of A.extl entered by the user will make appear on the screen the overlay of the original A.extl document and overloads corresponding to the associated file A. @ extl present in EG (and possibly to the associated file (s) of a localization list of the

  group), the overloads recorded in Eul not appearing.

  On the other hand, at this level the overloads brought by the user will be recorded in the file A. @ extl memorized in EG, and will appear for all the other users calling A.extl as soon as they

  are declared as attached to group G for their work session.

  It is thus possible to modify at two different levels the overloads brought to a file, the overloads brought at the group level (that is to say by a user declared as group manager) being able to be viewed by all the users. attached

to the group.

  And each user also has the opportunity to add more to

  file its own overloads, which will only be visible to it alone.

  The user can also choose not to select any home group for his work session, he will then be declared simply as a user (he can also open different sessions simultaneously, some under user names, others under as a group manager). The user has as we also said the

  possibility to modify the list of groups to which it is attached.

  If the user is declared under the name ul without having selected

  home group, his personal file is Eul which is that of ul.

  Consequently, when the user then calls an A.extl file, the system searches in the search list consisting of the address of the personal file Eul followed, where appropriate, by a location list.

  user selected by ul, an associated file A. @ extl.

  It is thus understood that the system makes it possible to process files at two levels (user level and group manager level), each level corresponding to a type of entity (user for the level

  user, group for group level).

  In the same way, the system allows to create at will other

  levels, which can thus constitute a tree structure with multiple levels.

  For example, in an embodiment of the system according to the invention, four levels are thus provided by default, with starting from the most general level and going to the most detailed level: At a level 4 "application" which is the level at which a set of used files are modified. This level includes only one entity, At a level 3 "update" which can bring together the different update versions of this set of files. In this case, a given entity of level 3 corresponds to the update on a given date of the set of files and all these entities are attached to the previous level, a level 2 "group", each group being able to gather several users, and be attached itself to all entities at the "update" level, or to only some containing the versions of interest to the group,

a level 1 "user".

  In the example architecture above, when a user is declared at the user level (level 1) and calls a file A. extl, the user's search list consists of the address of the user's personal file, followed by the level 2 search list, then

  from the level 3 search list, and finally from the level 4 search list.

  The system will therefore superimpose on the screen the associated files A. @ extl from levels 1 to 4 to the original file, so that the user will see all the overloads brought to levels higher than his own (while not being able to bring overloads that at its level, these overloads not being visible for example for the other users attached to the same group, or for the other groups attached to the same update). In the same way, a group manager will view the

  overloads brought to levels 2, 3 and 4.

  It is also possible to define for a user a "minimum level" in order to view only the overloads brought to general levels. In the above example of four-level architecture, a user ul declared in the system as user can thus declare in the system as minimum level level 3

(" updates ").

  In this case, when the user calls an A.extl file, the system only superimposes on the original document the associated documents of levels 3 and 4, so that the user will only see the overloads brought to these levels, and not the overloads brought to the level of

  group and the user himself.

Claims (22)

  1. Method for consultation by at least one user of an original computer document corresponding to an original file (A.extl) of a given format and saved in a computer memory location (Ei) designated by an address, the method being intended to be implemented with an operating system which comprises means for storing files and means for displaying the original document on a visual interface such as a screen, the method comprising: A. calling an original document by a user (ul, ul '), B. the display of the original document on the visual interface, C. the display on the visual interface of graphic overloads superimposed on the original document, in a linked frame to the original document, D. and the storage of said overloads in association with the original document in a dedicated memory location (Eul) so that the integrity of the original file is not compromised by the superposition of overloads, characterized in that the overloads stored during step D are personal to each user and are stored in an individual memory location (Eul) which is personally associated with the user.   2. Method according to claim 1, characterized in that step D comprises the creation of an overload file (A. @ extl) which is associated with the original file (A.extl) and with the user (ul, ul '), the file   associated containing information relating to the original file.   3. Method according to claim 2, characterized in that each   user can modify the overloads of the associated file.   4. Method according to claim 3, characterized in that the graphic overloads can constitute zones that can be activated by a user   any one to generate a character string.   5. Method according to claim 4, characterized in that the character strings are associated with commands of operating system functions. 6. Method according to claim 4 or 5, characterized in that the associated file (A. @ extl) contains the name of the original file (A.extl) and information making it possible to characterize the location and the appearance of the graphic overloads.   7. Method according to one of claims 2 to 6, characterized in that   prior to step D each user can modify his individual memory location (Eul) so that the storage of overloads can be carried out in any memory location   desired by the user.   8. Method according to one of claims 2 to 7, characterized in that the   method comprises, between steps A and B, the automatic search, in the individual memory location of the user, for the file   overloads (A. @ extl) associated with the original document (A.extl).   9. Method according to the preceding claim, characterized in that during step C, the overloads displayed are those of the file associated with the original file (A.extl) and with the user (ul, ul '), so that different users, by calling the same original document, will cause the display of the respective overloads which are individually their   associated, superimposed on said original document.   10. Method according to one of claims 2 to 9, characterized in that during   from step C the user has the possibility to modify the overloads.   11. Method according to one of claims 2 to 10, characterized in that the   associated file is stored in a specific format associated with format of the original file.   12. System for consulting an original computer document corresponding to an original file (A.extl) of a given format saved in a computer memory location (Ei) designated by an address, the system being intended to be implemented with an operating system which comprises means for storing files and means for displaying the original document on a visual interface such as a screen, the system comprising means for ensuring respectively: A. the call of a original document by a user (ul, ul '), B. the display of the original document on the visual interface, C. the display on the visual interface of graphic overloads superimposed on the original document, in a reference linked to the original document, D. and storing said overloads in association with the original document in a dedicated memory location (Eul) so that the integrity of the original file is not compromised by the overlap ion of overloads, characterized in that the system comprises means for storing overloads in an individual memory location (Eul) which is personally associated with the user so that   said overloads are personal to each user.   13. System according to claim 12, characterized in that said overload storage means comprise means for creating a file of overloads (A. @ extl) which is associated with the original file (A. extl) and with the user ( ul, ul '), the associated file containing   information relating to the original file.   14. System according to claim 13, characterized in that the system comprises means to allow each user to modify the overloads of the associated file.   15. System according to claim 14, characterized in that the system comprises means for associating with the graphic overloads a function for generating a character string, said function being able to be activated by a user. 16. System according to claim 15, characterized in that the character strings are associated with commands of functions of the operating system. 17. System according to claim 15 or 16, characterized in that the associated file (A. @ extl) contains the name of the original file (A.extl) and information making it possible to characterize the location and the appearance of the graphic overloads.   18. System according to one of claims 13 to 17, characterized in that   the system comprises means for allowing each user to modify his individual memory location (Eul1) so that the storage of overloads can be carried out in any   individual memory location desired by the user.   19. System according to one of claims 13 to 18, characterized in that   the system includes means for automatically searching, in the individual memory location of the user, the file   associated overloads (A. @ extl) to the original document (A.extl).   20. System according to the preceding claim, characterized in that the overloads displayed are those of the file associated with the original file (A.extl) and with the user, so that different users (ul, ul '), by calling the same original document, will cause the display of the respective overloads which are individually associated with them, in   overlay on said original document.   21. System according to one of claims 13 to 20, characterized in that   the system includes means for allowing the user to modify the overloads.   22. System according to one of claims 13 to 21, characterized in that   the associated file is stored in a specific format associated with the format of the original file.