WO2003019414A1 - Computer system and document management method - Google Patents

Abstract

The invention relates to a computer system that can be used to manage documents. The inventive system comprises: at least one server; at least one client station which can exchange data with the server; at least one document which is stored by the server and which can be sent by the server to a determined client station; and a means for the absolute designation of the document, such that the access to said document is secure.

Description

 Computer system and document management method

The present invention relates to the field of computer systems, in particular servers suitable for document management. In the context of a computer network with remote data communication, for example the Internet, the documents which one wishes to make available to other users are presented in a particular form generally called markup language. The HTML markup language defines a set of fixed tags which depends on the language version and which is oriented towards a given presentation. It has enabled the development of the exchange of hypertextual • data through the Internet. Different HTML standards have defined how browsers should represent HTML data. For more information on HTML one can refer to the site http://www.w3.org.

More recently, the XML language has been developed which is a language for constituting data adapted to represent structured documentation.

A so-called structured document is a document that contains both text and images, but also indications of the role played by each element of text: the title of a paragraph, the caption of an image, the content of a brand. footer. The XML language or Extensible Markup Language (extensible Markup Language in English) makes it possible to materialize the structure of the document and to focus on the role of the elements, the semantics, more than on the form of representation. The XML language does not fix either the semantics or the set of tags used. Viewing or printing an XML document requires defining how the data is displayed or printed, programmatically or using style sheets. In the XML language, the information must either be framed by opening and closing tags with possible nesting, or included inside the tags for example: <TOPIC BOOK = XML>. Here the SUBJECT attribute of the BOOK element has the value "XML". The XML standard can be found at. httpr / Λv w. w3.org/TR/REC- OXML

The XML language makes it possible to enter or update a single content once without worrying about the presentation or future processing and without having to enter labels such as "author", "year of publication", etc., without. having to put titles in italics, in other words exactly the way you would feed a database. XML also makes it possible to automatically generate multiple presentations with possible sorting, selection, reorganization, automatic generation of wording, table of contents, index, etc .; and this on multiple media - screens, papers, Braille terminals, etc.

The existing XML language servers are essentially designed to facilitate the search for information on the basis of any criteria. The query languages associated with XML, for example of the XQL, SXQL, XUPDATE, etc. type designate the tags from a path description in the XML tree.

However, this operating mode is ill suited to reliable and fine management of access rights to documents or parts of documents. In fact, the tree structure is constantly evolving in a multiuser context with the addition or deletion of sub trees by the different users, and depends on access rights.

For example, either a tag comprising two sub-tags of lower rank to which three users access simultaneously at a given time or at least in a given state at close times. Suppose that the first user adds a third sub-tag to the tag and returns the tag to the server by means of an adapted request, then that the second user removes the first sub-tag from the tag and returns the tag to the server by means of a request adapted at a later time to the addition of the third tag. Then finally, the third user sends a request to modify the second sub-tag. The server will take into account the request of the third user by applying it to the third sub-tag and not to the second because of the relative classification of sub-tags. This relative classification of sub-tags also poses difficulties in the context of filtering users according to their right of access.

The invention provides a document sharing system suitable for a multi-user context and for managing access rights. The invention proposes a system which makes it possible to solve the problems mentioned above, to carry out unambiguously the updates carried out by different users and thus to allow them to work simultaneously on different tags of the same document.

The computer system capable of managing documents according to one aspect of the invention comprises at least one server, at least one client station capable of exchanging data with the server, at least one document stored by the server and. capable of being sent by the server to a specific client station, and a means of absolute designation of the document, so that access to said document is secure. The client station can be another server, a computer, for example of the PC type, a pocket computer, of the personal organizer type, a telephone station equipped with means of communications.

Internet, a radiotelephone, for example of the WAP type and more generally any means of data processing equipped with means of communication with a network.

In one embodiment, the system comprises means for absolute designation of tag or part of the document, each tag being associated with a label, a label being associated with a single tag.

Advantageously, the system comprises means for generating a document or tag request for a document. The requests can be independent of each other.

In one embodiment, the system comprises a communication network between the server and the client station.

Advantageously, at least one label is assigned to at least one document.

Advantageously, at least one tag is uniquely identified by a label. All tags can be identified by a label. The invention also provides a computer server capable of managing documents and comprising means for exchanging data with at least one client station, means for storing at least one document, means for sending a document to a specific client station, and a means of absolute designation of the document, so that access to said document is secure.

Advantageously, the server comprises means for assigning a unique label to each tag or part of the document.

The invention also provides a computer program comprising program code means for operating the server as described above, when said program is running on a processing means or a computer.

The invention also proposes a document management method, in which data is exchanged between at least one server and at least one client station, the server storing at least one document and sending it to a determined client station, the document being designated in an absolute manner so that access to said document is secure.

In one embodiment, a document is made available to several client stations simultaneously. Advantageously, a document is divided into tags or parts, each tag being associated with a label and a label being associated with a single document tag. A label is associated with a document tag in a stable manner over time.

The invention also provides a computer program comprising program code means for implementing the steps of the above method, when said program is operating in a server processing means or on a computer.

The invention allows efficient document sharing thanks to the unique and systematic labeling by the server of all the document tags. The labeling makes the documents a little more voluminous but leads to a concise and unambiguous expression of the requests for modifications. This removes any conflicts or uncertainties during modification requests or access requests. In addition, it is particularly advantageous to associate this systematic labeling with a process for managing the versions of a document. Each user can indicate the version of the tag of the document which he has, which allows the server by comparison with version numbers associated with each tag on the common document, to arbitrate the concurrency. The invention proposes to express access rights in the form of attributes.

The various embodiments of the invention integrate efficiently in XML format and make it possible to provide many useful functionalities on a document server such as association of files or documents, administration of accounts, notions of domains, application. style sheets ...

By way of example, the invention applies in an interesting manner to telemedicine applications aiming to share the medical records of patients between a group of health professionals. In this area, the access rights management functionalities prove to be extremely useful and the sharing of medical information meets a need both for health organizations and for the practitioners themselves.

The present invention will be better understood on studying the detailed description of an embodiment taken by way of nonlimiting example illustrated by the appended drawings, in which:

- Figure 1 is a diagram of the architecture of the system; -

- Figure 2 is a block diagram of software according to one aspect of the invention; - Figure 3 is a diagram of the system according to the different types of client;

- Figure 4 is a document organization diagram; and

- Figure 5 is a flowchart showing the sequence selected for the consultation of a medical type client file from a WAP mobile phone. As can be seen in FIG. 1, a server 1 is associated with a large capacity data storage 2, for example a hard disk which has been represented here externally but which could be integrated into the server 1. The server 1 is also associated with an http server 3, an electronic mail server 5 and another server 5 of unspecified standard. The http server 3 is connected to a WAP gateway 6. These different servers or gateways 3 to 6 are each provided for communicating with client workstations, one of which is referenced 7, via a communication network 8 Of type

1.0 wired, fiber optic, or wireless.

The server 1 comprises a memory -9, a communication bus 10, a communication interface 11 with external servers, in particular the servers 3 to 5, an interface 12 with the data storage 2, a calculation and processing unit 13 including at least

15 a microprocessor and a memory 14 which may be smaller than the memory 9 but with reduced access time.

The server 1 is equipped with a plurality of software stored in the memory 9 and which can also be stored in the memory 14 to be executed by the unit 13. The memories. 9 and 14, the interfaces 11 and 12 0 and the unit 13 communicate by means of the communication bus 10. The interface 11 can be of the CGI type.

A document, for example in XML format, of the user is stored in the form of a file. The storage organization is illustrated in FIG. 2. The software 15 stored in the memory 9 and / or 14 and executed 5 by the unit 13 makes it possible to process such documents. A document 16 is capable of being sent or received by the software 15 and stored in the form of a file, in the data storage 2. Certain information originating from the document 16 must be stored in a relational database 18 via of a basic management system of

30 data 19, to facilitate access. These are essentially the values of the elements likely to appear in the lists of documents. These elements are previously declared to the server via a meta-document as described below. A file 17 associated with document 16 can also be stored in a directory without special treatment. When creating a rheta-document, the tables useful for managing the corresponding XML documents are generated in the relational database 18. In the absence of a “Ref” tag among the elements to be listed, there is no as a table, with as many columns as there are elements. If it is necessary to manage “Ref” tags in the lists, additional tables are created since the tag can take different values depending on the fields. After each operation on an XML document, the values of the elements of the lists are both updated in the file 16 and in the relational database 18. The table below shows the principle of storage of an XML document having "Ref" fields.

XML documents

Items to appear in the list of documents

<A D="20 'I="2">

<B>

<Ref I = "0"? B0_ 2 </?._ ï>

<oc_ _2 </C>

<D> D_ ~ 2 </D>

</ B>

<E>

<Re-f I = "0"> E0_ _2 </Ref>

<Ref I = "1"> E1 ~ ^ 2 </ Re>

</ I>

<F> F_2 </ F>

</A> Relational Dase

list 20

I c3 c4

1 C 1 D 1 2 C_2 D 2

Additional tables to manage the references in the lists

The same document or folder can be read or written simultaneously by several users. To avoid the classic problems of data overwriting or inconsistency, a version management mechanism is provided in the software 15.

The server 1 assigns a version counter to each XML document and marks each modified or created tag with the current value of the counter, in the form of an attribute noted “N”. Each user who requests a file from the server is informed of the current value of the counter, attribute "N" at the root level. It must restore this value during a modification operation. The server compares the value indicated with the value it has for the tags affected by the modifications or creations. For a given tag, the server actually checks the versions of all the parent tags and all the child tags. If one of the versions is higher than the version of the user, the modification request is rejected. In other words, a field can only be modified if the value which was available when the field was read has not been modified in the meantime. The table below illustrates the version management algorithm.

It should be noted that the user is not informed of the version of each tag. He only knows the version of the whole file. The expected algorithm performs optimistic locking. The pessimistic locking technique, that is to say the initial locking of the parts of the document intended to be modified, can be carried out by the user by playing on the access rights, for example by placing an exclusive right of writing on the parties concerned in the file before proceeding to their modifications, then restoring the initial rights after the operation. The storage of the versions also allows the server 1 to locate the modified tags with respect to an interior version of the document. This indicates to the user the “file” tags modified compared to a local version on a client computer. However, it is not possible to reconstitute the list of deleted tags on the server. But this information can be easily deduced by the customer himself.

Thus, the invention proposes a document server in XML or equivalent format intended to allow the sharing of these documents by a set of users. This server is placed at the center of a client server architecture and provides services comparable to those of a relational database management system, but with XML documents. These services may include defining a user account, storing documents in a transparent manner for the user, managing access to documents according to precise rules, searching for documents on the basis of certain criteria, executing transactional requests ...

Compared to a relational database, the adoption of the XML format to represent the data also makes it possible to effectively arbitrate the write accesses to the various parts of a document, to very finely fix the access rights, to a any level of the XML tree, associating binary files with documents, or even giving direct access to the server to a wide range of platforms and client software. Of course, the invention minimizes the constraints imposed on hosted XML documents while making the server architecture independent of the data processed.

To allow server access to a wide variety of clients or users, the server function invocation protocol is as simple as possible. It is therefore provided for requests that are independent of each other, in the absence of a notion of session, a transactional operation, that is to say that a request is either canceled, or executed in full and if the description is excepted attached files which can be of varied format, a purely ASCII format for the requests, and, moreover, of XML type, as for the documents handled. The invention of functions through XML requests is in line with the principle of the SOAP protocol (SIMPLE OBJECT ACCESS PROTOCOL in English). A simpler formulation specific to the processing of XML documents can be chosen. Unless the client or user requests a binary file associated with a document, the server also responds with an XML message.

Any software capable of dialoging in XML format with the server, according to the appropriate communication protocol (http, or other), can a priori play the role of client. To allow direct access to the server, that is to say without intermediate software, from html or wml browser type clients, a mechanism for transforming the XML response using style sheets can be integrated into the server. The simplicity of the access to the server and the possibilities of applying stylesheets lead to a wide variety of potential customers which can be another server, a computer, a handheld computer, a Web telephone, a Wap radio telephone, etc.

The role of the server is to allow the sharing of XML documents between several users. The aim is also to ensure high operating security, to rigorously manage access and in particular questions of access rights and access competition, to open the system to as wide a range of users as possible. client platforms and software as well as minimizing the constraints imposed on hosted XML documents. The server provides among other things the user account management service with administration functions (creation, modification, deletion, list ...), user profile, home domain and authentication by smart cards, and management of XML documents with administration, arbitration functions concurrent access, control of access rights with data filtering, management of attached files and application of style sheets to the document.

For reasons related to the operating principle of the server and to security, two syntax requirements are introduced. First of all, each piece of data must be between an opening tag and the corresponding closing tag. We therefore exclude the following scenario:

<Text> This is <Underlined> not </ Underlined> allowed. </Text> and the order in which the tags are written does not matter. All documents or objects managed by the server are uniquely designated by identifiers generated by the server itself. The format of the identifiers is that of a base 36 number (composed of the numbers from 0 to 9 and the letters from A to Z). File identifiers also include an alphanumeric extension that indicates the type, for example ".doc".

The application hosted on the server is accessible with the HTTP or HTTPS protocols. The nature of the protocol does not affect the operation, so other access sites can be considered, for example with an SMTP protocol for one ^; delayed access, by email ...

Any software capable of generating a request in XML format, interpreting the response in the same format, except when reading a file associated with a document, and communicating via the network with the appropriate protocol (HTTP, HTTPS, WAP , SMTP ...) is likely to play the role of client when executed by a computing and processing unit. In order to also give direct access, without intermediate software, to the server to thin clients of HTML or WML browser type, the server is associated with an XSL stylesheet processor which can transform the response XML to HTML or WML. The style sheet to be used is indicated in the request, under the form of a URL or file name local to the server. To formulate XML requests in the browser environment, we rely on the available scripting languages such as JAVAscript, NBscript, WMLscript ... The use of style sheets is essentially justified for thin clients, that is ie downloaded. So-called heavy clients, that is to say the applications installed on the client workstation, generally written in a high-level language, will generally be able to directly interpret an XML response from the server. The different information flows, in XML or derived format, are presented in Figure 3.

The data relating to the administration of the system are represented in the form of XML documents of imposed structure, unlike that of the user documents described below. An attribute "D" characterizes the type of document. D = 0 indicates a meta-document, D = 1 indicates a user account, D = 2 indicates an account profile, D = 3 indicates a domain. Thus, when considering for example a document describing an area, its value will always be equal to 3.

A domain (D = 3) designates a set of users who share the same system of indexing information, for example file reference numbers. A domain is characterized by a unique name according to the following syntax:

<Domain D = "3" I = "domain id" N = "version id"> <Νom> domain name (unique name) </Nom> </Domaine>

For example :

<Domain B = ^M 0 "D =" 3 "1 =" 5 "V =" 0 "><Name B =" l "> Clinique du X </Nom></Domaine> The concept of domain makes it possible to carry out a automatic management of reference numbers by the server, whatever the document considered Each reference will be delimited by a reserved tag "Ref", with the following syntax

<Ref I = "domain id"> reference </Ref> Consider a document that. contains, at any place in the XML tree, the following lines: <Ref B = "2H" I = "5"> altai N 77 </Ref><Ref B = "21" I = "3E"> a8364 </ ref>

<Ref B = "2J" I = "9" <alt-nic-77.3 </Ref>

A user of domain I = "9" who accesses the document will in fact only see the following line: <Ref B = "2J" I = "9"> alt-nic-77.3 </Ref>

An account allows a user to connect to the server. It is identified by the couple (count name; domain), by its internal identifier (attribute I at the root) or by a key number.

<Coπιpte D = "l" I = "account id" V = "version id"> (optional) <User><Mom> user name </ Nor><Preno> first name </Firstname><Civility> civility </Civilite><Sexe> M or ^' F </Sexe><Portrait>

<File I = "id of file" S≈ "size in ocfcets" X / File> -r </Portrait>

</ >user> <Access>

<Do aine I≈ "domain id"> domain name </Domain> (optional) <Norn> account name (unique on the domain) </Nom> (optional) <Cle C = "type" 1 = " unique key identifier "x / Cle>

. . . (possible repetition of the <Cle> tag) (optional, not accessible in reading) <MotDePasse> scrambled password </MotDePasse> 10 </Acces>

<By m>

<Actif> YES or NO (default) </Actif>

<Profile I = "profile id"> profile name </Profile>

(optional if not active) <Exρiration

T = "da te-heure JJ / m / AAAA: l-! M: SS (server clock)"> </ Eκpiration>

(optional) <Eraail> email address </Eraail> </Param> 15 (read-only) <Trace>

<Creation T≈ "da te-heure JJ / ΛtV / AAAA H: MM: SS. (Server clock)">

<Account I≈ "cor.ιpte id"> first name + username r </Account> </Creation> <Eκpiration>

<Corr.ρte I = "account id"> first name + user name </ Corαpte> </ Eκpiration>

<Req ete T = "da te-Λeure JJ / MM / AAAA HH: tW: SS (customer clock t)" ηp. I≈ "identifier was assigned by the client to the request">

^ ^υ <Action> action </Action>

</Requete> <Service T = "da te -hour JJ / m / AAAA HH: t_.: SS (server clock)">

(in case of error) <Error I≈ "error id"> </ Erreύr> </Service> </Trace> </Compte>

25 The value of the <password> tag corresponds to f (P), that is to say to a scrambling function applied to the password. The length of this value can be between 10 and 25 characters. This field is not returned by the server. It is created by client software to change the account password.

30 All the fields in the <Account / trace> block are generated by the server and cannot be modified. The tags <request> and <service> recall certain parameters of the last access to the server with the account considered. This information can be useful for managing a recovery after a connection break during a request. The request account identification is not intentionally traced. In writing, the domain and the profile can be designated by their name or the attribute <I>. Any user of an account is authorized to view his own <account> folder and to change his password. The concept of key has been introduced to allow rapid identification of accounts from a single login and in ^'some cases authentication of the user. A key is characterized by a type, a unique identifier for a given type (serial number, carrier number, ...), and, optionally, a cryptographic authentication protocol. A key is described with the following syntax:

<key C = "type" 1 = "unique key identifier"> </ key> The presence of a key at the level of an account (<Account / param / key> tag) does not require the use of this key for access to the account. It is in the description of the account profile that the imposition of this type of constraint is defined.

The user profile makes it possible to associate a certain number of rights, such as access to documents, administration of accounts, etc. and constraints such as authentication to each account. The user profile can be defined as follows:

<Profile D = "2" I≈ "profile id" V = "id da version"> <Name> profile name (unique name) </Name>

<Authentication>

<Password> YES (default; or NAME </Password> <Key C = "type" (optional) ï = "" x / Key> </Authentication>

<Account>

<Domain> YES (default) or NAME </Domain>

<List> YES or MY ('default; </List>

<Authentication> YES or NAME (default) </Authentication>

<Profile I = "profile id"> profile name </Profile>

. . . . (possible repetition of the <Profile> tag) </Compte> <Doc D≈ "id de πιé a-document"> ⁽ read-only) <Mom> name of me a -document </Nom><iste> YES or NO (default) </List>

<Authentication> YES or NAME (default) </Authentication> <reading> NONE (default) or PERSONAL or ALL </Reading> <Write> NONE (default) or PERSONAL or ALL </Write> ^ <Creation> YES or NO (default) </Creation>

<Suppression> YES or NO (default) </Suppression> <Archive> YES or NO (default) </Archivage> <BlocChernin>

<Path A = "Λ ⁽ default ⁾ or W"> path accessible in the document </Chemin>. . . . (repetition of "Chemin") </ BlocCheπιin></Doc>

10. . . . (repetition of "Doc")

</ Profile>

Or as an example

^'• ^ - <Profile B = "0" D = "2" I = "B" V = "l"><Name B = "l"> Patient </Name>

<Authentication ^' B = "2">

<Mot'DePasse B = "3" x / MotDePasse> </Authentication>

<Doc B = "10" D = "10"> 20 <Name B = "ll"> Patient record </Hom>

<reading B = "12"> PERSONAL </Leading><Writing B = "13"> N0N </Write><Creation B = "14"> NO </Creation><Supρression B = "15"> N0M </ Delete><Archiving B≈ "16"> NO </Archiving><Bi^' ôcCheπιin B = "17">

<Che in B = "18"> Patient / A τιinistrative </ Chémin> <Path B = "19"> Patient / Gensral </Chernin> 5 </BlocCherain>

</ Doc>

<Doc B = "20" .D = "11">

<Name B = "21"> Professional file </Nora> <Reading B = "22"> PERSON </Reading> <Writing B = "23"> NO </Write> <Creation B = "24"> NO < / Creation> <Deletion B = "25"> NO </Suppression>

30 <Archiving B≈ "26"> MON </ Arc ivaςe> <BlocC'nemin B = "27">

<Cherain B = "28"> FrofessionneK / C'nerain>

</ BlocCherήin> </Doc>

</ Profile> More specifically, the <Profile / Authentication> block defines the mandatory parameters for the authentication of accounts with this profile. Thus, a value <yes> for the <password> tag indicates, for example, the need to present a non-empty password for access to the account. For the <clef> tag, the type must correspond to an authentication key. In the absence of the attribute <I> any key of the indicated type opens access to the account. But this key does not, by itself, identify the account because it is necessary to specify an account name and a domain name. If the attribute <I> is present (with an empty value) this means that a precise key number is required at the account level. In this case, the key allows both identification and authentication of the account.

The <Profile / Account> block describes the account administration possibilities linked to the profile. In the <Profile / Account / domain> block, the value <YES> restricts the administration rights to the domain in which the account belongs.

The <Profile / Account / List> block conditions access to the list of accounts. The <Profile / Account / Authentication> block makes it possible to impose an authentication of the users of the administered accounts. Manageable profiles are specified in the block

<Profile / Account / Profile>. A profile with a value of <YES> for the tag "Domain" cannot administer a profile with a value of <NO> at this level.

The <Prof il / Doc> block allows you to prohibit access to this type of document in the absence of a <Doc> tag corresponding to a type of document. The <Profile / Doc / List> block specifies whether the list of documents is accessible to the user.

The <Profile / Doc / Authentication> block indicates in the event of a value

<YES> that access to the document is only possible if an account has been associated with the document (attribute <C> at the root level of the document).

The identification and authentication data required for this account must be indicated in the request.

The <Profile / Doc / Read> and <Profile / Doc / Write> blocks are used to define the accesses. In case of value <NONE>, no access is not authorized, in the case of a "<PERSONAL>" value, access is authorized to accessible parts of personal files as defined by the access rights defined in the documents. If <TOUS> is set, access to the accessible parts of all documents is authorized. If there is no <BlocPath> or <Path> tag, all the paths are accessible in read and write, that is to say in modification. The paths with A = "W" are accessible in read and write. The others are only read. If there are paths A = "R" without any path A = "W", no modification is authorized. Any type of XML document hosted by the server must be described beforehand by a document called a "meta-document". This requirement is linked to the need to be able to manage lists of documents effectively. A meta-document describes in fact the elements of the documents that one wishes to appear in the lists and on the basis of which one makes the selections. The structure of a meta-document is illustrated below.

<Meta D = "0" I = "meta-document id" V≈ "version id"> <Name> meta-document name (unique name) </ Mo> <ist> <Elem>

<Desc> (optional) description of the element </Desc>

<Doc> path (without the root) of the element in the document </Doc>

<iste> path of the element in the document list </Liste>

<Size>

<Usuelle> (optional) usual size (number of characters) of the element </Usuelle> <Maximal> maximum size of the element </Maximal> </Size> </Elem>

. . . . (repetition of "Elem")

_{</ L} i _ste> Professional D = "ll" I = "13" B = "14" V = "E"></Meta><Administrative B = "13"><NomB = "l"> Y ₁ < / name>

<First name B = "2"> X ₁ </Firstname><Civility B = "3"> M </Civilite><Sex B = "4"> M </Sexe><Portrait B = "5"><File B = "6" I = "J.jpg" S = "2932" x / File>

</ Portrait> </ Administrative>

</ Professional>

<List D = "l l"> <Doc I = "l">

<Name> Y ₂ </Name><Firstname> X ₂ <Firstname><Sexe> F </Sexe></Doc><Doc I = "13">

<Name> Y [</Name><Firstname> X ₁ </Firstname><Sexe> M </Sexe></Doc><Doc I = "14"> ^ <Name> Y ₃ </Name><First name > X ₃ </Prenom>

<Sexe> M </Sexe> </Doc> </Liste>

If the path to the item in the document is empty, the name of the root tag appears in the list. The usual size of the elements as well as the description field are not used by the server. This optional information is simply intended to facilitate the formatting of any list of documents by client workstations. If the maximum size is exceeded, the information is truncated in the list but not in the document. It is possible to list attribute values or to place attribute values in the list. It suffices to indicate the name of the attribute and the rest of the path, with the following syntax: Path / ® name of the Attribute A list can include several <Ref> tags. Access to the elements of the lists in the documents does not take account of any access rights specified in these documents.

Users have great latitude in structuring their XML document. Only a few attributes and tags are interpreted by the server. At the root level, the user must always specify the type of document in question, that is to say indicate, with the attribute "D" the identifier of the corresponding meta-document. The attributes "I" and "N" are generated by the server. They should be reminded to the server when the document is subsequently modified. The version counter allows the server to manage access concurrency. The attribute "C" optionally allows the document to be associated with an account. For the user of this account, it will be a personal folder to which he may have privileged access. Each tag in a document is automatically marked by the server with a unique identifier, in the form of an attribute "B" which then allows the client software to effectively designate any tag in the document to make a modification. For example, we have: <tag B = "tag ID">. . . </balise> The "A" attribute allows the user to specify the access rights on a part of the document. The users authorized to access this tag can be described by their account, their profile or their domain, more precisely by their account for a specific user, by their profile for users with a specific and specific profile and by a domain for all users of a domain. You can specify a whole list of users. We can have for example:

A = "R: c 9A" Reading: account "9 A"

A = "R: cR52 + p4E / W: c67" Reading: "R52" account or "4E" profile

Reading and writing: account "67" A = "R: d2 + p9A" Reading: domain "2" or profile "9A"

Access restrictions are combined by traversing paths in the document from root.

Access restrictions are combined by traversing paths in the document from the root.

The principle of using the <Ref> tag has already been described below. A user of a given domain cannot create or modify a reference on another domain. However, deletion is authorized for The principle of using the <Ref> tag has already been described above. A user of a given domain cannot create or modify a reference on another domain. On the other hand, erasure is authorized to avoid deadlock situations. The <Ref> tag constitutes a sheet 5 in the XML tree.

The <File> tag is used to refer to a file external to the document managed as a whole by the server. The file tag uses attributes and "I" and "S" generated by the server, see below. The <file> tag usually does not contain a value. 10 The path tags declared in the meta-document must be respected if you want their value to appear in the list of documents.

During the dialogue between the client and the server, the general format of a request is as follows: 15

<Request V = "server version for which the client software was created" T = "in the duration of the request DD / MM / YYYY H: MM: SS (client clock)" I = "(optional) iden tifier (unique or not) was tributed by the client "StyleSheet≈" (optional) URL of a style sheet "StyleErr =" (optional) UP.L of a style sheet with these errors "StyleProcess≈ "(optional) YES or NO (default)"><Account I = "account id" K = "(optional) password validation key"> ryn. </ Cθmptβ> ^U <Action> READ or READ FILE or LIST or MODIFY OR CREATE or

ARCHIVE or DELETE or AUTHENTICATE </Action> <Param>

. . . {fields specific to each action) </Param> </Requete>. . . (possibly: data relating to files)

2 The server response follows the frame below (unless a file has been requested):

<Service V = "server version"

K = "(if the account is authenticated by a key) random challenge" T = "at the time of processing DD / teV / YYYY HH: K- SS (server clock)">. . . (data λï -. 'L) <Info>

<Request I = "ident t t tributed by the client to the search" X / P.equete>

30

</Info></Service> In the event of an error, the message indicates at least one error code:

<Service V = "..." T = "...">

<Error I = "error id"> _ <Desc> description of the error </Desc>

^ </Err>

<Info>

<Request I = "identifian t was awarded by the customer to the head" x / Reαuete> </Info> </Service>

The version attribute “N” requires the client to indicate for 0 which version of the server it was designed. This allows the server to reject obsolete requests, by inviting the user to update its IT resources.

If an identifier is assigned to the request by the client, its value will be recalled in the server response under the attribute "I". The 5 attributes "StyleSheet", "StyleErr" and "StyleProcess" are useful for transforming XML documents using XSL style sheets, at the URL "StyleSheet" if the processing is successful and, when 'StyleError' URL in case of error. If "StyleProcess" is equal to "NO" and a style sheet URL is specified, said URL is 0 copied at the head of the returned XML data:

<? xml-stylesheet type = "text / xsl" href = "URL specified in the request"?>

If "StyleProcess" is equal to "YES", the server itself performs the transformation of the XML result of the request with the specified style sheets (which, in this case, must be local to the server). The date attribute "T" is not checked by the server. If this information is not readily available, for example on a mobile phone, in WML script, it suffices to initialize the attribute at any value 0. The attribute "Request / Account / K" corresponds to a calculated code dependent on the password of the user. It can take different forms depending on the computing capacities of the client workstation. It is a precautionary mechanism to deter the desire for unauthorized access. An account can be designated in several ways, by its unique identifier by the name of the account and the domain name or even by a unique key identifier.

The first request sent to the server by a user is generally that which allows the description of the user's account to be obtained, which is advantageous for directly using the account identifier in subsequent requests and for immediately checking the accuracy of access parameters. The server request and response can take the following form

<Request V

^<C ! and account authentication ⁾

</ Co pte> <Action> READ </Action>

</ Request>

<Service V = "..." T = "...">

<Account D = "l" I- "id of account" V = "d of version B- ...>

<User B = "...">

<Last name B = "..."> user name </Name> <First name B = "..."> first name </Firstname>

</Corapte> </Service>

The list query is used to obtain the list of documents of a given type. It is possible to filter this list by indicating values for the elements to be listed. A filter consists of the same paths as those indicated for the list in the meta-document. A filter value ending with "*" indicates any sequence of characters. A request for a document list and the response from the server can take the following form: <Request V = ".„ "T =" ... ">

<Account I = "account id" K = "... ' ^! X / Account>

<Action> ISTER </Action>

<Settings>

<Doc D = "id of meta-document" I = "filter on document id">

. . . (filter on the listed items) </Doc> </Param> </Requete>

<Service V≈ "..." T = "...">

<iste D = "meta-document id">

<Doc I = "document id">

. . . (items to list for this document) </Doc>

. . . (repetition of "Doc")

</Liste> </Service> In response to a request from. reading a document, the file sends the binary data of the file except in case of error or it sends an XML error message.

Deleting or archiving a document deletes the archiving of files associated with this document. If the delete or archive operation went well, the server response is minimized. The request for deletion or archiving and the response from the server can appear ¹ as follows:

<Request V = "..." T = "..."> <Account I = "account id" = "..." X / Account>

<Action> DELETE or ARCHIVE </Action> <Param>

<Doc D = "id of the meta-document" I≈ "id of the document" X / Doc>

</Pararn> </ Reαuete>

<Service V = Il _ll II * </Service>

To create a document, you must send the XML content to the server, with the content of any attached files. In response, the server returns the entire XML document, supplemented by the attributes "I" and "N" at the root and the attributes "B" at the level of each tag. The creation request and the server response can be presented as follows:

<Request V = "..." T = "..." I = "...">

<Corapte I = "account id" K = "..." x / Account>

<Action> CREATE </ Action>

<Settings>

<root tag D = "meta-document id t">

. . . (content of the document)

</ root tag> </Parara>. <: / Request> J

The data relating to the file is added following the creation request, using any sequence of characters as a separator, for example. There are as many data blocks as “File” tags in the XML document. In addition, the i ^th block is assumed to correspond to the i ^th “file” tag. Each of these tags must have an "I" attribute that tells the server the extension (three letters) to give to the file. In the server response, the "I" attribute is supplemented by a name to constitute a unique file identifier. In addition, the size of the transmitted file is indicated in an "S" attribute:

<File I = "name. Extension" S = "size in bytes" x / File> If the client software keeps a local copy of the files, for example to allow work without connection to the server, it is necessary to rename these files with the new names assigned by the server. To facilitate this operation, the client can indicate, in the creation request, the file names used locally. In its response, the server then also provides a renaming list, which directly gives the correspondence between the old names, those of the client, and the new names, those assigned by the server. The format of this list can be as follows:

<Name> C ₁ .E ₁ : S Eι | etc </Renom> with C _x and following the names given by the client,

≤ _! and following the names given by the server, and

E _t and following the names of extensions.

The modification of a document is carried out by sending the server the sequence of elementary modification orders to be carried out. If the files are modified or created, they should also be sent to the server. The principle is the same as for the creation of documents. The data are classified following the request, in the order defined by the "File" tags in the XML part. Instead of the content of the document, a list of elementary orders of modifications to be sent is sent. If there is no error, the server responds by returning the content of the modified XML document. We also find the file renaming list, the principle of which is preserved. It is also expected that the server response will contain a modified file list which contains the names of the files that have been created or modified between the document version indicated by the server (Request / doc / Arobase N) and that of the document returned by the server (Service / tag / root / @ N). The information is interesting in the case of a client who allows local work, since he thus knows which files are to be updated. The list can ignore the last modification, made by the customer himself. There is no list of files deleted since the customer can easily create it himself, in particular by comparing the “File” tags before and after modification of the document. There are four basic elementary modification operations: erasing an existing tag denoted D, modifying the subtree of a tag or the value if it is a sheet and possible modification attributes, denoted M, creation of a new subtree denoted C, modification of the attributes of the tag and possibly access rights denoted A. An elementary modification order will generally include the identifier of the tag and so optional the name of the tag which is redundant information but which can be useful. The modification operations are carried out as follows: Erasure

<D B = "tag identifier to delete"> </D>

Tag modification

<MB = "identifier of the tag to be modified" (optional) attribute name t- 'value "attribute name≈' 'value" ...> new subtree (without tag identifiers) or value s' it is a leaf

</ M>

Creation

<C B = "identifier of the father tag"> new sub-tree (without tag identifiers) or value if it is a sheet </C>

Editing attributes

<A B= "tag identifier to modify" attribute name- 'value" attribute name="value" ...> </A>

In one embodiment of the invention, it will be necessary to indicate all the attributes for their modification. Indeed, for the designated tag, the new list of attributes can be fully copied into the document, in place of the old one. The following table gives an example of a document before modification, a modification request and the server response with the document after modification. Document before modifications:

<Patient D≈ "10" B = "ll" v≈ "0" I = "35"> <Administrative A = "R: c65 / W: c65" B = "13"> <First name B = "18"> Albert </Prenom> <Mom B = "19"> DUBOIS </Mom> <Civility B≈ "1A"> M. </Civilite> <Gender B = "1B"> M </ Seκe>

<Profession B = "lC"> Electrician </Profession> <Portrait B = "1D">

<File I = "14.jpg" B = "1E" S = "4477" x / File> </Portrait> </ Administra if> <General B = "1F"> <BlocPiece B = "1G"> <Piece B = "1H">

<File I = "15.txt" S = "19" B = "lI" X / File> <Date B = "lJ"> 19 / ιo / 2000 </ Dâte> </Piece> <Piece B = "1K ">

<File I≈-lβ.jpg "S =" 49601 "B =" 1L "X / File> <Date B =" 1M "> 20 / I0 / 2000 </Date> </Piece> <Piece B =" 1N ">

<File I≈ "17.rtf" S = "1007" B = "10" X / File> <Date B = "lP"> 20/10/2000 </Date> </Piece> </ Bloc? Iece> </General> </Patient>

Request for modifications:

<P.equete I = "8" V = "1.0" T = "10/20/2000 5:24:51 PM">

<Account I = "65" K = "40K14bho4PSMï 3BjIDcJ" x / Account>

<Action> EDIT </ Action>

<? ara>

<Doc D = "10" I = "35" V = "0"> <DB = "1E" X / D> <AB = "13" A = ": c65" X / A> <HB = "lC" > Electrical engineer </M> <MB = "10" I = "17.rtf"> </M> <CB = "1G"> <Piece>

<File I = "_ 5. Jpg" X / File><Date> 20/10/2000 </Date> ^{% *} <Desc> R.MN tete </Desc></Piece></C></Doc>

</ Para></Requete> - "nextpart"y0i> àqsd3éunhacàçθlzrc31azn. . . (binary data from the file “17.rtf” ⁾ - “nextpart”

8) àSéeçàbQdYEdAER £ §μ23ZAst. . . (binary data from the file "_5.JP9")

- "nextpart" - Response with document after modifications:

<Service V = "1.0" T = "20/10/2000 17: 25: 01"> <Patient D = "10" B = "ll" V≈ "2" I = "35"> administrative A = "W : c65 "B =" 13 "> <First name B =" 18 "> Albert </Prenom> <Name B =" 19 "> DUB0IS </Nom>

<Civility B = "1A"> M. </Civilite> <Gender B = "1B"> M </Sexe>

<Profession B = "lC"> Electrical engineer </Profession> <Portrait B = "lD" X / Portrait> </Adrπ.inistratif> <General B = "1F"> <BlocPiece B = "1G"> <Piece B = "1H"> <File I = "15. Txt" S == "232" B = "ll" x / File>

<Date B = "U"> 20/10/2000 </Date> </Piece> <Piece B = "1K">

<File I = "16. Jpg" S = "49601" B≈ "1L" X / File> <Date B = "lM"> 20/10/2000 </Date> </Fiece> <Piece B = "1M ">

<File I = "17. Rtf" S = "2934" B = "10" X / File> <Date B = "lP"> 10/20/2000 </Date> </Piece> <Piece B = "1U ">

<File I = "18. Jpg" S = "4293" B = "lV" X / File> <Date B = "lW"> 20/10/2000 </Date> <Desc B = "1X"> RMN head </Desc> </Piece> </BlocPiece> <Blood B = "1S">

<Group B = "lT"> 0 </Groupe> </Sang> </Ger.eral> </ Pati ent> <Info>

<Renoτn> _5. jpg: 18. jpg </Renorn> <Modif> 15. txt </Modif> <Request I = "8" x / F.equete> </Info> -

</ Service>

It should be noted that between the first reading of the document by the user and the sending of the modification request, the document was modified by another user (and, in particular, the file "15.txt" indicated in the list of modifications "Service / info / Modif"). This explains that the version changes from the value "0"("Request / Param / Doc / @ V") to the value "2"("Service / Patient / @ V"). An error is generated by the server if a user tries to modify the value of a tag, while the initial value of this tag is no longer valid, following a modification made in the meantime on the server by another user . In other words, the tag value that the user sees must match that on the server for the modification to be authorized. Using the previous table, if in the request, we also tried to modify the file "15.txt" with the order: <MB = "II" I = "15.txt"></M>.

The server would have returned an error message indicating concurrency:

<Service V = "1.0" T = "10/20/2000 5:25:01 PM"> <Error I = "9000">

<Desc> Document modified in the meantime by another user </ Dεsc> <Oriçine B = "1I" N = "File" x / Origin> </Erreur> <Info> '<Request I = "8" x / P. equete>

</Info> </Service>

The tag causing the error is specified in the error message in the form:

<Origin E = "tag id" N = "name of the tag" x / Origin>

The system also includes an account authentication mechanism using keys. We mean here, in general, an authentication mechanism using asymmetric keys, based on solving challenges: certificate, smart cards ... The user has the following information: a unique identifier also called an identifier of keys marked Kid, a public key Kpub, a private key Kpriv and Daccrd accreditation data.

During a first specific request, the user sends the values of the key identifier, the public key and the accreditation data to the server. The redundancy contained in this data allows the server to check its validity. The server generates a random sequence denoted D which it sends back to the client. The triplet of value identifier of key, public key and random sequence is memorized by the server;

Each server response to a client request contains a new random sequence value. The user encrypts this value with his private key and returns the result in the following request for it to be accepted. With the value of the public key stored, the server can decrypt the result and verify that it has found the value of the random sequence, also stored, see the table below:

The first user request is constructed as follows:

<Request V = "..." T => "...">

<Account K = "password validation key">

<Cle C = "type" I = "id de cle (so KId with the previous notations)"> </ Cl </Corapte>

<Action> AUTHENTICATE </Action> <Param>

. . . (public key and accreditation data) </Param> </Requete>

10 If this data is deemed valid, the server returns the first challenge under the form of an attribute "K" (the value of the challenge is expressed in base 64), as well as the account identifier:

<Service v = ".„ "T≈" ... "K =" value of the challenge in base 64 ">

<Account I = "..." X / Account> </Service>

15

For the following requests, the client indicates each time its response (in base 64) to the challenge of the previous request in a K attribute at the level of the “Request / Account / Key” tag:

<Request V = "..." T = "...">

<Co-ιpte I≈ "..." K = "validation key for the password">

<Key C = "type" I = "key id" K≈ "response to the challenge in base 64"> </ C_ -> </ Cc: apt> on <Action>. . . </ Action>

<Settings>

</Pararn> </Requete>

₂₅ In the case ^of a response in XML, the challenge is again indicated at the root: Service Vy T = "..." ^ new challenge for the next request ^

^• . . ⁽ response XML content ₎ </Service>

0 XMT ^{S l} ι 7 ^{of U} r ^Ct ^ ^flchie, μ ^{r es} Wπaires of ^data f ⁱ le are preceded by an in-Tet Snnée the le ∞W ** ^0! "^ * this header and then delete it to keep only the

<Service V = "..." τ = ". ^„ "K≈" new challenge for the following request ">

</Service> J binary data from the file If the identification and authentication of the account are conducted properly, the server _returns, always a new challenge, even in case of error on the requested treatment (example below).

Example

<Service V ^≈ -'l. O "T = ^* '08 / 12/2000 13: 54: 56" K = "Jif2hZcVrR3SlN3Edhk5MfGttVg =">

<Error I = ' ^, 8111 ^, '>

<Desc> Insufficient privilege </Desc>

</Err>> </Service>

If the error concerns the identification or authentication of the account, the server does not generate a new challenge and the authentication protocol should be resumed at its beginning.

Example:

<Service V = "1.0" T = "08/12/2000 13:50:41"> <Error I = "9999">

<Desc> Access denied </Desc> </Err>

</ Service>

As indicated above, it is possible to associate an account with a document and to impose, at the level of the profile, to present the parameters of access to this account in order to be able to gain access to the document. In this case, for all requests relating to a document of this type, the account parameters are indicated in the <Param> block of the request. The identification of the owner of the document can be used to identify the document insofar as it is only possible to link a single account and a single document. There are thus ultimately three possibilities for designating a document: the identifier of the document of type I = "Id of the document", the identifier of the account of the owner of the document of the type C = "Id of the account of the owner", and the document owner account settings. If the two accounts of the user and the owner of the document use an authentication key, the value of the random sequence is the same for the two accounts and corresponds to the value returned during the authentication of the account of the. user. For the management of access rights - for an isolated tag, two rules are applied: in the absence of restriction of read right, the right is taken for granted, in the absence of restriction of write right, the right is acquired for users authorized to read. The algorithm for evaluating access rights at the beacon level as executed by the server can be, in a simplified manner, as follows:

AccesBal function (Oper: "R" or "W"; B: Beacon; User: User): boo _l éen

'- Read the attribute of access rights for tag B, ie: A = "R: ListUtilR / W: ListUtil"

(if there is no attribute A, the lists are assumed to be empty)

- If Oper = "R" then

If ListUtilR is empty

Then AccesBal = True

Otherwise AccesBal = (Use ε ListUtilR)

- If Oper = "W" then.

If ListUtilW is empty

Then AccesBal = AccesBal ("R", B, Util)

Otherwise AccesBal = (Use ListUtilW)

The server is also expected to understand them. following two functions for managing upper and lower access from a given tag. These functions allow you to manage the nesting of tags.

AccesSup function (Oper: "R" or "W"; B: Ealise; Util: User): boolean

If there is a tag B 'parent of B (at any level) such as AccesBal (Oper, B *, Util) ≈ False Then

AccesSup = False Otherwise

AccesSup = True

Acceslnf function (Oper: "R" or "W"; B: Tag; User: User): boolean If there is a tag B 'daughter of B (at any level) such as

AccesBal (Oper, B ', Util) = False Then

. Acceslnf ≈ False Otherwise

Acceslnf = True A tag is only visible to a user if the tag, as well as all of the parent tags, give the user read rights. The read filtering operation can result in the following procedure:

Filtering procedure (Doc ^' : document; User: User)

Clear all B tags from Doc such as: (AccesBal ("R", B, Util) = False) or (AccesSup ("R", B, Util) = False)

To make elementary modifications, for example to delete (operation D) or modify a tag (operation M), you must have write permission for the tag concerned, for the parent tags and for the daughter tags. To modify the attributes of a tag (operation A) or add a daughter tag (operation C), you must have write permission for the tag concerned and for the parent tags.

Thus the operation of one of the four types described above and noted "Oper" requested by a user "Util" and relating to a tag "B" is only authorized if the following function implemented in the server returns the true value:

AccesOper function

(Oper: "D", "M", "C" or "A"; B: tag; User: User): boolean

If Oper = "D" or Oper ≈ "M" then

AccesOper = AccesBal ("W", B, Util) and AccesSup ("W", B, Util) and Acceslnf ("W", B, Util)

so

AccesOper = AccesBal ("W", B, Util) and AccesSup ("W", B, Util)

The invention advantageously applies in the medical field, more precisely in the field of sharing medical records of patients between health professionals. The use of XML format and the importance given to rigorous management of access rights are particularly advantageous. The invention applies both to central server computer systems and to distributed systems with a main server and a plurality of secondary servers. It is expected that all users regardless of their software will access the same documents on the server. The patient record constitutes the main document for this application of the invention. Two documents of lesser importance, entitled professional file and establishment file, may contain summary information relating to health professionals and healthcare establishments. These secondary files make it possible to avoid the repetition of information in each patient file with the difficulties of updating that this would imply. Whatever the client software, the procedure for accessing information likely to be delivered by the server remains essentially the same. The user is first invited to identify himself and then accesses the list of patients, filtered according to criteria such as name, first name, sex, date of birth ... This list allows him to select the patient file which is of particular interest. Such a file may then contain links to other professional or establishment type files. <professional> and <establishment> tags can be provided but whose management is exclusively the responsibility of the user and not of the server. great freedom is left to the user to structure the data.

In FIG. 4, the organization chosen for the documents is illustrated. The documents entitled "account", "profile" and "domain" have an imposed form while the user benefits from a great latitude for the other documents, for example the documents "patient", "professional", "establishment".

“Heavy” client workstation is understood to mean a client workstation equipped with an application requiring an installation step on the workstation. This type of client workstation offers many processing possibilities such as work - in offline mode following a local copy of documents, a richer man-machine interface which facilitates sometimes complex interactions to modify files (specifications access rights) editions of tables ...) administer accounts and profiles, etc. Even if the software is downloaded, the download volume remains quite reasonable in the order of a few megabytes. In addition, the updates are less bulky. A client workstation accessing the server through an HTML browser is said to be "Light" and benefits from fewer processing possibilities. However, no installation or update is required. Just enter the home page URL in the browser. The client workstation is open to all systems and its interfaces are familiar to Internet users. In general, a "Light" client workstation is well suited to quickly consulting a file from any workstation.

In the case of a “Light” client using WML protocol, the objective is essentially to be able to quickly view some important elements of the files. However, nothing prevents the provision of more extensive functionality such as modification of data including from a mobile phone.

FIG. 5 shows the sequence of interfaces or screens which has been provided for consulting a patient file from an organizer or from a mobile phone. The invention therefore makes it possible to share documents, in particular XML documents, while effectively managing concurrency and access rights at any level of the tree structure. This allows users to work simultaneously on different parts of the same document.

Claims

1. Computer system capable of managing documents, characterized in that it comprises at least one server (1), at least one client workstation (7) capable of exchanging data with said server, at least one document stored by the server and capable of being sent by the server to a determined client station, and a means of absolute designation of the document, so that access to said document is secure. lp

2. System according to claim 1, characterized in that it comprises means for the absolute designation of tags or parts of the document, each document tag being associated with a label, a label being associated with a single document tag.

3. System according to claim 1 or 2, characterized in that it comprises means for generating a request for a document or part of a document.

4. System according to claim 3, characterized in that the requests are independent of each other.

5. System according to any one of the preceding claims 0, characterized in that the documents are of format

XML.

6. System according to any one of the preceding claims, characterized in that it comprises a communication network between the server and the client station. 5

7. System according to any one of the preceding claims, characterized in that at least one label is assigned to at least one document.

8. System according to claim 7, characterized in that at least one tag is uniquely identified by a

30 label.

9. Computer server (1) capable of managing documents, comprising means for exchanging data with at least one client station, means for storing at least one document, means for sending a document to a specific client station, characterized in that it includes a means for absolute designation of the document, so that access to said document is secure.

10. Server according to claim 9, characterized in that it comprises means for assigning a unique label to each tag or part of document.

11. A computer program comprising program code means for operating the server according to claim 9 or 10, when said program is running on a computer.

12. Document management method, in which data is exchanged between at least one server and at least one client station, the server storing at least one document and sending it to a determined client station, the document being designated so absolute so that access to said document is secure.

13. Method according to the preceding claim, in which a document is made available simultaneously to several post-clients.

14. The method of claim 12 or 13, wherein a document is divided into tags or parts, each tag being associated with a label, a label being associated with a single document tag.

15. Computer program comprising program code means for implementing the steps of the method according to any one of claims 2 to 14, when said program is running on a computer.