FR2872938A1 - Digital multimedia document sharing method, involves sending notification having representation of digital document and/or associated identifier, and potential server station lists to destination stations - Google Patents

Abstract

The method involves obtaining an identifier of a digital document and a list of destination stations of the document in a peer-to-peer type network. A list of potential server stations (102, 103) that serve the document in the network are obtained. A notification having a representation of the document and/or associated identifier and the server station lists are sent to the destination stations. An independent claim is also included for a device to share a digital document across a peer to peer communication network# an information medium readable by a computer system, particularly CD-ROM or magnetic medium, such as hard disk or floppy disk, or transmissible medium, such as electrical or optical medium# a computer program stored on the information medium comprising instructions allowing to implement a digital document sharing method.

Description

The present invention relates to the sharing of a digital data through

  a distributed communication network. It finds a particular application in sharing, storing and accessing digital data

  multimedia in a peer-to-peer distributed communication network, still called peer-to-peer or peer to peer in English.

  Subsequently, the term digital data, digital document or file can be applied to both images, text or digital video. The term version refers to a particular resolution of the data. The original data has the highest resolution. The data having a lower resolution than that of the original datum is called a thumbnail. In the case where the digital data is an image, the original data corresponds to the original image, ie to full resolution, while the thumbnail corresponds to a lower resolution image. In the case where the data is a video, the original data corresponds to the original image sequence, while the thumbnail corresponds, for example, to the first image of the video having a resolution lower than that of the original video.

  Peer-to-peer communication systems are different from traditional client / server communication systems because in peer-to-peer systems, each station or machine can be both client and server. Thus, a station can both receive and serve files, including those that the peer has already received. In addition, data is served directly from users' machines. The storage space can therefore be considered in practice as unlimited.

  However, peer extensions are not always connected and their addresses may change with each connection.

  We know how to remedy this problem by using a central server that guarantees a minimum quality of service. This is called a hybrid peer-to-peer communication network.

  Nevertheless, searching for a document is still difficult in such a hybrid peer-to-peer network.

  It is possible to improve this search by associating a unique identifier with each digital document to be shared, by constituting an index table and by matching, in this index table, the identifier of a document and the location of this document. document in the network.

  The index table can be centralized or distributed.

  In the case of a centralized index table, the index table minimizes the search time of the location of a document in the network. However, the central server must be sized according to the number of even peers connected. Indeed, the more the system is used, the greater the performance of the central server must be important (answers to simultaneous requests, search in a database, ...).

  One way to reduce the cost of such a central server is to distribute and distribute the index table on the peer computers themselves. However, duplicating the centralized index table on each peer station requires relatively large resources that can be, in practice, unbearable for such peer positions. In addition, distributing the index table implies an update of the local index tables. The most trivial solution would be to inform each station of the network as soon as a new document is shared or a post has just retrieved a document. This type of update is in practice inconceivable because this mechanism would clutter the network and most of the peer-to-peer communications would be to exchange update messages.

  The present invention provides a solution to this problem.

  It relates to a method of sharing a digital document through a communication network, in particular of the peer-to-peer type, said method being implemented within a creator station of said document to be shared.

  According to a general definition of the invention, the method comprises the following steps: i) obtaining at least one identifier of said document to be shared and / or a representation thereof; ii) obtain at least a list of the recipients of said document in the network; iii) to obtain at least a list of stations capable of serving said document in the network; iv) obtain at least a list of potential positions that can serve the said document in the network; and v) send to the destination stations belonging to said list of destination stations a notification comprising a representation of the document to be shared and / or the associated identifier, the list of positions that can be used, and the list of potential positions.

  Thus, as soon as a document is shared, each of the items belonging to the list of recipient stations is informed of the positions that are suitable for serving the document and items that are potentially capable of serving said document. The list of suitable positions and the list of potential positions thus define the positions that are really interested in the location and / or location information associated with the document to be shared.

  Posts excluded from these two lists are not really affected by this location information. In practice, excluded items never access this document in a sharing system according to the invention, in which access to the document to be shared is thus limited and filtered by the list of destination stations.

  According to one embodiment, each item wishing to share a document comprises at least one local index table containing information belonging to the group formed by the identifier of the document to be shared, at least one representation of said document to be shared, the audit path. document, at least one identifier of a station that can serve, and at least one identifier of a potential position.

  In practice, the method further comprises a step of updating the local index table by changing the status of a position belonging to the list of potential positions in post adapted to serve following the reception, from a destination station, a confirmation message of ability to serve the document.

  According to another embodiment, the method further comprises the step of obtaining at a central server station a central user table containing information relating to the registration of the users, a central table of the stations containing information relating to the connection of the stations to the communication network, a central table containing information on the destination stations and a central query table containing information relating to the sharing notifications.

  Preferably, each station further comprises an address book containing information belonging to the group formed by the name of the user, an e-mail address in the network, a user identifier-r-and-an-identifier In addition, each station further includes a local post table containing information belonging to the group consisting of the post identifier, and connection and bandwidth information.

  For example, obtaining the identifier of the document to be shared and / or the representation thereof is carried out by the local index table of the post.

  According to another example, obtaining the identifier of the document and / or the representation thereof is performed at the central server station.

  For its part, obtaining lists of suitable and potential positions is performed by the local index table of the position.

  In practice, the notification includes connection information for a selected subset of items belonging to the lists of suitable positions and potential positions.

  For example, the subset of items is determined based on a predetermined maximum number of items.

  According to one embodiment, the suitable positions are taken in priority with respect to the potential positions, in the subset of positions.

  According to another embodiment, the subset of stations is determined according to a criterion of bandwidth and / or time of presence of the station in the communication network.

  The present invention also relates to a method of sharing a digital document through a communication network, in particular of the peer-to-peer type, said method being implemented within a destination station of said document, characterized in that it includes the following steps: 1) to receive a notification comprising a representation of the digital document and / or the identifier thereof, at least one list of positions capable of serving the document and at least one list of potential positions that are likely to serve the digital document in the network; and 2) in response to the notification thus received, updating a local index table comprising information belonging to the group formed by the identifier of the document to be shared, at least one representation of said document to be shared, the access path audit document, at least one identifier of a position suitable for serving, and at least one identifier of a potential position.

  According to one embodiment, the method further comprises, in order to obtain a digital document, the following steps: a) from the index local table thus updated, extracting the information corresponding to the sharing of the document as well as those of the suitable positions to serve and potential positions; and (b) send a request to obtain the document for at least one post from the list of suitable posts and the list of potential posts thus extracted.

  According to one embodiment, the obtaining request is sent sequentially to the positions among the lists of suitable positions and potential positions in a predetermined order until the document is obtained.

  According to another embodiment, the method comprises a step of updating the local index table by assigning the potential item status to the destination items of the obtaining request that do not send the document in response to said request for the 'obtaining.

  In practice, the obtaining request and the lists of suitable positions and potential positions are sent to a central server station in the case where the document has not been received following the sequential sending.

  For example, the predetermined order of the sending is defined according to a bandwidth criterion and / or time of presence of the station in the communication network.

  According to yet another embodiment, the method comprises a step of updating the local index table following the reception in response to the request to obtain a new list of server positions and a new list of positions. potential.

  In practice, the new lists are taken into account for the sequential sending of the obtaining request.

  In addition, the method includes a step of sending to destination positions of the lists of suitable positions and potential positions, a confirmation message confirming the ability to serve the digital document, following the receipt of an answer to the request for obtaining said digital document.

  The present invention also relates to a sharing device for implementing the method and / or methods according to the invention.

  The present invention also relates to an information carrier readable by a computer system, possibly totally or partially removable, including CD-ROM or magnetic medium, such as a hard disk or a floppy disk, or transmittable medium, such as an electrical or optical signal , characterized in that it comprises instructions of a computer program for implementing a sharing method according to the invention, when this program is loaded and executed by a computer system.

  Finally, a subject of the present invention is a computer program stored on an information medium, said program comprising instructions enabling the implementation of a sharing method according to the invention, when this program is loaded and executed by a user. Other features and advantages of the invention will become apparent in the light of the detailed description below and the drawings in which: FIG. 1a schematically represents the general architecture of a sharing device according to the invention; , and Figure lb represents a collection file according to the invention; FIG. 2 schematically represents the general architecture of a central server according to the invention; FIGS. 3a, 3b, 3c and 3d respectively represent the central tables of the users, the stations, the notification messages and the obtaining requests contained in the central server station in accordance with the present invention; FIGS. 4a, 4b and 4c respectively represent a local index table, an address book and a local table of items contained in each peer station according to the present invention; FIG. 5 is a flowchart illustrating the sharing of a set of documents according to the invention; FIG. 6 is a flowchart illustrating the composition and sending of the notification message intended for each recipient according to the invention; Fig. 7 is a flowchart illustrating the update of the local index table following step E510 of Fig. 5; FIG. 8 is a flowchart illustrating the update of the local index table following step E512 of FIG. 5; FIG. 9 is a flowchart illustrating the extraction of the connection information of the stations that can serve and the potential stations according to the invention; FIG. 10 is a flowchart illustrating the selection of suitable stations and, where appropriate, the selection of potential stations according to the invention; FIG. 11 is a flowchart illustrating the method according to the invention when a notification message is received by a registered recipient; FIG. 12 is a flowchart illustrating the updating of the local index table following the steps E1110 and E1119 of FIG. 11; FIG. 13 is a flowchart illustrating the updating of the local index table following receipt of a notification message according to the invention; FIG. 14 is a flowchart illustrating the method for requesting a version of a shared document according to the invention; FIG. 15 is a flowchart illustrating the method of connecting a local station with a remote station according to the invention following the step E1406 of FIG. 14; FIG. 16 is a flowchart illustrating the update of the local index table following the step E1414 of FIG. 14; FIG. 17 is a flowchart illustrating the response implemented in response to a request for obtaining a document sent by a remote station according to the invention; FIG. 18 is a flowchart illustrating the receipt of an answer following the transmission of a request; FIG. 19 is a flowchart illustrating the reception of a notification message sent by a substation that has become a station that can be used according to the invention; and Fig. 20 is a flowchart illustrating the method of no longer serving a shared document according to the invention.

  Referring to Figure 1a, there is shown in the form of a block diagram the general architecture of a digital document sharing device using a distributed index table. The device is composed of a central server station 100 and three stations 101, 102 and 103. The station 101 is subsequently considered as being the station from which the sharing of a new document is issued. Item 102 is subsequently considered to be a position that receives a requisition but can not serve the requested document. Item 103 is subsequently considered to be the item that issues a request to obtain item 101. Item 101 responds by serving the requested document. These different entities are connected by a communication network 104 such as the Internet.

  The central server 100 has the role of centralizing and storing in tables the information concerning the registered users (central user table, FIG. 3a) and the connection information of the stations connected to the system (central post table, FIG. 3b). . In addition, the central server 100 temporarily stores the confirmation and / or notification messages (central message table, FIG. 3c) and the obtaining requests (central query table, FIG. 3d). The central server station 100 is for example a machine of the microcomputer or workstation type, permanently connected to the peer-to-peer network. The architecture of such a machine is described with reference to FIG.

  In practice, a user who wishes to share a document is registered with the central server station 100. For this, the user connects to the central server via a web service or via a dedicated graphics application. For example, the central server sends a form that the user fills out by specifying a login name (password name in English), a password (password in English), a way to send him a message notification that a new document is being shared (for example, an e-mail address or a phone number). In addition, a post is attached to this user, also called a reference post. Such a reference station may be the means to send this user a notification message, instead of sending this notification by mail. The reference station is also used to send confirmation messages. Subsequently, it is considered that only one reference station is attached to each user but several reference stations can also be attached. In the case of a plurality of reference stations, the confirmation (and possibly notification) messages are sent to all the stations or to a reference station selected by the user from this plurality of reference stations.

  For example, notification messages are sent to the user's email address and confirmation messages are sent to a reference station. Thus, only registered recipients receive confirmation messages from the local index table.

  In another example, during the registration procedure, the central server registers the station from which the user is logged as his reference station. The identifier of this reference item is added to the information concerning this user.

  Of course, the user can access this registration information so as to modify, for example, his reference position, or add an e-mail address. All this information is stored in the central user table. In addition, the central server station associates a unique identifier with the newly registered user.

  Any post acting as a shared document server station is registered with the central server. This recording can be performed automatically, according to one embodiment of the invention, as soon as the station connects for the first time to the system or a user registers with the central table of users. To register, the station sends the connection information (IP address, port, usage name, etc.) to the central server station 100 which associates a unique identifier with this station. This information is stored in the central station table of the central server station 100 which will be described in more detail below.

  It can be noted that the central post table is updated each time a registered post is connected or disconnected. When the extension is disconnected, the corresponding entry in the central station table is retained, but the connection information is no longer available. As soon as it connects, the entry of the central post table is updated by including the new connection information. For each station thus recorded, the central station table also stores the average connection time and the bandwidth.

  Stations 101, 102 and 103 may be for example a microcomputer or a workstation. These devices fully play the role of peer-to-peer, namely the client role and the server role. The architecture of these stations is for example identical to that of station 100 described with reference to FIG. 2. However, these stations differ from station 100 because of their storage and computing power which can be much lower than those of FIG. Station 100. Each station 101, 102 or 103 maintains a local index table and an address book described in detail with reference to Figures 4a and 4b. The local index table retrieves the identifiers of the server stations, that is to say the stations that serve a version of a digital document and identifiers of potential positions that may serve this version. Each of these posts also maintains an address book that can send a message to a recipient.

  Referring to Figure 2, there is described the programmable apparatus embodying the invention. This apparatus may be station 100, 101, 102 or 103. The apparatus comprises a communication bus 209 to which are connected: a central processing unit 202 (microprocessor), which controls the exchanges between the various elements of the apparatus a read-only memory 201 which may comprise the programs; a random access memory 205 comprising registers 208 adapted to record variables and parameters created and modified during the execution of the programs; a hard disk 203 which may comprise the abovementioned programs; a floppy disk drive 211 adapted to receive a floppy disk 210 and to read or write to it documents processed or to be processed according to the invention; a communication interface 206 connected to a communication network 104, for example the Internet network; , the interface being able to transmit and receive documents.

  The communication bus 209 allows communication and interoperability between the various elements included in the device or connected to it. The representation of the bus is not limiting and, in particular, the central unit is capable of communicating instructions to any element of the apparatus directly or via another element of the apparatus.

  The executable code of each program enabling the programmable device to implement the processes according to the invention can be stored for example in the hard disk 203 or in the read-only memory 201.

  According to an alternative embodiment, the diskette 210 may contain documents as well as the executable code of the aforementioned programs which, once read by the device, is stored in the hard disk 203.

  According to another variant embodiment, the executable code of the programs can be received via the communication network 104, via the interface 206, to be stored in the same manner as that described previously.

  Floppies can be replaced by any information medium such as, for example, a compact disc (CD-ROM) or a memory card. In general, an information storage means, readable by a computer or by a microprocessor, integrated or not integrated into the device, possibly removable, is adapted to store one or more programs whose execution allows the implementation of the process according to the invention.

  More generally, the program or programs can be loaded into one of the storage means of the device before being executed.

  The central unit 202 controls and directs the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in the hard disk 203 or the read-only memory 201 or in the other storage elements mentioned above. . When powering on, the program or programs that are stored in a non-volatile memory, for example the hard disk 203 or the ROM 201, are transferred into the RAM 205 which will then contain the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.

  It should be noted that the communication device comprising the device according to the invention can also be a programmed device.

  This device then contains the code of the computer program or programs for example frozen in a specific application integrated circuit (ASIC).

  Reference is again made to Figure la. The sharing system starts with step El sharing at least one document (from the station 101). This step consists of updating the local table of the indexes and creating an FC collection file which will be described in more detail with reference to FIGS. 5 to 10. The FC file (FIG. 1b) includes the unique identifier IDD of each one. documents to share (LIDD list of IDD images), the list of LPS server stations of the original version of each document and the list of potential LPP servers of this version. One variant is to also store in this FC collection file the version numbers and, for each version of each document, the list of LPS server stations and the list of potential LPP server stations.

  The FC collection file here contains only the IDD identifiers of the images (no version or representation identifier, and in a variant that is not represented, the collection file may also contain identifiers relative to each version or representation of the document to be shared. According to another variant, the collection may also contain a unique collection identifier.

  It may be noted that the list LD of the recipient stations (not represented in FIG. 1b) can be included in the FC collection file in the case where access rights are set up to restrict access to these shared documents. In addition, the two lists of LPS and LPP extensions may not be directly integrated into the FC collection file. In practice, the notification message includes the identifiers of the shared IDD documents and the two lists of LPP and LPS stations.

  The list of LPS server stations is a list of IDP remote station identifiers that serve as a representation, preferably the original version, of a document. The list of potential LPP server stations is the list of IDP remote station identifiers that can serve this representation, preferably this original version. Potential positions have not confirmed that they serve this original version unlike the server stations that are on the LPS list. This confirmation of capacity to be used is described in more detail with reference to FIG. 18. For example, the potential servers are at least the items of the LPR list, that is to say the list of the reference items of each recipient. (at least one post per recipient), who have not yet confirmed their ability to serve an original version.

  Once the creating step E1 is complete, step E2 sends a notification message to each recipient (FIG. 6). In this notification message, extension 101 included a list of server stations of the original version (for example, its own station) and a list of potential positions (at least extension 102 and extension 103). This message includes the collection file and a way to retrieve at least one version (the thumbnail) of each shared document.

  According to one variant, the notification message is also sent to the central server station 100 which becomes a server station of at least one version of each shared document (step E2 '). Thus, at least one version of each shared document is always available in the network. In return, it is necessary to provide the central server station with enough memory space to store the version of these documents. In practice, the thumbnail of each shared document is stored on the station 100. Thus, each station can recover the thumbnail of a document in the event that the copy of this version received with the notification message is destroyed.

  Once a recipient 103 has received this notification, it updates its local index table (Figures 11 and 12) and can view the thumbnails of newly shared documents. It can also select one or more of them and ask to retrieve another version of this or these documents (step E3). Subsequently, it is considered that the query relates only to the version of a single document. In fact, in the case where a user selects several documents and requests for each of them a version, a request is sent for each of the documents.

  To create a query, the system uses the local index table which provides a list of the LPS server stations of the selected version and the list of potential LPP servers (Figures 14 to 16). Then, the request is sent in turn until one of these stations can serve the version of the document (steps E4 and E6). We will see later how to solve the case where none of these positions can serve the version.

  Upon receipt of a request, the local station responds by sending the version of the requested document (step E7) (Figure 17). In the case where this version is not stored locally, the post extracts from its local index table, the list of LPS server stations and the list of potential LPP servers corresponding to all the versions of this document. A response message for updating is created and sent to the requesting station (step E5).

  This response message contains the two lists of LPS and LPP position identifiers (Figure 17).

  Once the requesting station receives the response to its request (Figure 18), two cases may occur. If this message contains the version of the requested document, the workstation updates its local index table by referencing the path of the table entry for that version. It then becomes the server of the version. Then, this post sends to each station of the list of LPS server stations and to each station of the list of potential LPP servers, a confirmation message informing them that it is server of the version of the document that it has just recovered. . In the case where the remote station can not be connected, the message is stored temporarily in the central message table of the station 100. This message is delivered to the remote station as soon as the latter connects.

  If the request response message does not contain the version of the requested document, the status of the remote station is modified: if the remote station is a server station, it is removed from the list of server stations and added to the list of stations potential LPP servers. In addition, the local index table is updated according to the two mailing lists received (Figure 18). Obviously, we avoid sending the request twice to the same post. It may be noted that according to the preferred embodiment, no update message is sent in this case. An alternative is to send this message to the stations of the two LPS and LPP lists to inform them that a remote station is no longer server of this version of this document.

  In a digital document sharing system, means should be provided for sharing a document but also means for a station to stop serving one or more versions of a document (FIG. 20), or all versions of a document. all documents referenced in a collection file.

  In practice, three types of messages are sent: the notification message, the request messages and the update messages of the index local tables.

  Sending a message from one extension to another in a hybrid peer-to-peer system is not a problem when the destination is already connected to the transmitting station. It is the same for any message sent from a post to the central server which is permanently accessible. By cons, the problem of sending a message arises when the destination station is not accessible temporarily, because it is then necessary to store the message and send it to this post as soon as it becomes accessible.

  Two strategies can be used: passive or active.

  The first (passive) consists of storing the message on the sending station (for example the station 101) and sending the message to the destination station (for example the station 102), as soon as the latter connects to the station 101. A variant of this strategy is to send the message to the central server 100, which stores the message until the station 102 connects to the central server 100. The message is then sent to the station 102.

  The second (active) policy is to connect to extension 102 and send the message. Since the station 101 only knows the identifier of this station 102 (from the TLI local index table or the CA address book), it must obtain the information to connect to this item 102 (information connection).

  A first sub-variant consists in asking the central server for this connection information, which is stored in the central table of the TCP stations, if the station 102 is connected. According to this sub-variant and, in the case where the station 102 is not accessible, the message is either stored on the station 101 or sent to the central server that stores it. As soon as the station 102 connects, it informs the central server. If the message is stored on the central server, the message is delivered to the station 102. If the message is stored on the station 101, the central server 100 sends the connection information of the station 102 to the station 101, which connects to the station 102 to send him the message.

  A second sub-variant consists of storing a local table of posts locally on each item. The description of this table is identical to that used by the central server 100, but its update is different. In fact, only the connection information of certain stations are stored in this table, namely the connection information of the stations referenced in the local table of the TLI indexes. This table can be synchronized with the central station table of the central server. However, this synchronization generates traffic. However, this local post table is updated when the post receives a message. For this, as soon as a station sends a message containing a station identifier, it attaches to this message the connection information of this station according to its local table posts.

  If the connection information of station 102 is available from the local post table, station 102 may not be accessible if this information is out of date. In this case, the station 101 requests the connection information from the central server which transmits the information from the central table TLP stations. This information is stored in the local post table.

  It may happen that the station 102 is not accessible due to its non-connection to the network. At this time, either the message is stored locally on the station 101, or it is stored on the central server.

  In the first case, as soon as the station 102 connects to the central server, the central server informs the station 101 which retrieves the connection information, updates its local post table and establishes a connection with the station 102 to send it the message. It may also happen that the local postal table is updated from messages from other remote stations. At this time, in the case where the message has been stored locally, each time an update of the connection information of the station 102 is made, the station 101 tries to connect to the station 102. If successful , the message is sent. If the message is stored on the central server, the message is sent to extension 102 as soon as this extension connects.

  In one embodiment, each station maintains a local post table (Figure 4) and the messages are stored on the central server. The message table contains the message and the identifier of the destination station. The query table contains the query and a list of extensions (server stations and potential servers) (Figure 3). This list is sent at the same time as the request by the station sending the request. Thus, as soon as the central table of the posts of the central server is updated, the central server tests whether a message can be delivered or if a request can be served. If yes, the message is sent and the request is sent in turn to each connected station (looping). Of course, as soon as a post has received the request, it is removed from the list of posts associated with the query. As soon as one of these items has issued the requested document, the query is removed from the table. Similarly, as soon as the request is sent to all the items in this list, the query is removed from the query table.

  With reference to FIG. 3, the organization of the information stored on the central server 100 has been described.

  According to one embodiment, the information concerning queries waiting for replies, update messages, information on users and the connection information of the stations are centralized on the central server station 100.

  In a variant, the invention can be applied to a system that distributes this information (or a part of it) on the stations 101, 102 or 103.

  The information stored on the central server is grouped into four tables: 1) the central TCU user table (Figure 3a); 2) the central table of TCP stations (Figure 3b); 3) the central message table TCM (Figure 3c); and 4) the central TCR query table (Figure 3d).

  The purpose of the TCU user central table is to store information about a registered user. Five fields are filled in: the unique identifier of the user IDU, the login name, the password, the identifier of his reference post and a way to reach him (e-mail or telephone number).

  The central table of the TCP stations is intended to store the connection information of the stations connected to the sharing system. Indeed, each registered station provides upon its connection its use name, its IP address, port, .... Moreover, the central server is able to calculate a time of presence (connection) for this post on a defined period of time. Finally, each station provides its bandwidth.

  The central TCR query table temporarily stores queries that can not be served. The identifier of the version of the document that is being searched for, the list of server stations and the list of potential server stations associated with the requested document correspond to an entry in the central query table. Thus, as soon as a new station connects to the central server, the latter checks whether the request can be served by this station.

  The central TCM update message table. Updating the local TLI index table requires sending update messages to some remote desktops. A message is stored in the local index table when a station is not connected to the network, since this message must be sent to it. As soon as the station receiving this message connects to the central server, the update message is sent to it.

  With reference to FIG. 4, the organization of the information stored on the stations 101, 102 and 103 has been described.

  The TLI local index table is empty at system startup. The TLI table has several entries, each of which stores information corresponding to a version of a shared document. Each entry consists of five fields: 1) the unique identifier of the shared document (IDD); 2) the version number of the shared document (IDV); 3) the local path to accessing a version of a document (CHA); 4) the list of position identifiers that serve the document version (IDPS); and 5) the list of position identifiers that can serve the document version (IDPP).

  Two identifiers are associated with each version of each shared document: a single IDD to identify the document and another IDV to identify the version of this document (original version, thumbnail, ...). The identifier IDV is a number specifying a version (resolution, visual quality). Subsequently, we consider that V (integer) versions are accessible for each shared document.

  The CA address book is a table in which the means of identifying a recipient are stored. Recall that recipients are not necessarily registered to receive a shared data. In this case, the CA address book contains only the NOU usage name and at least one way to send a message to the recipient (e-mail, phone number).

  In the case where the recipient is registered, the identifier of the user IDU and at least one reference station IDPR are also stored.

  The purpose of the TLP local mailing table is to store the connection information of the referenced items in the local TLI index table.

  With reference to FIG. 5, the method of sharing a set of digital documents has been described. The process begins with the creation of a new collection file described with reference to Figure 1b. The FC file contains the IDD IDs of the D (integer) documents to be shared and, for each of them, the list of identifiers of the items that serve the original version of the document and the list of identifiers of the items that can be used for the version. original of this document.

  In step E500, the user selects D (D integer) documents to be shared and K (integer) recipients from his CA address book. Steps E501 to E507 are used to create the LD list of reference stations of the registered recipients. In the case where the information concerning a recipient is not present (or incomplete) in the CA address book, the station requests this information from the central server station 100 which responds if the recipient is registered and, in this case, sends him his IDU ID and the identifier of his reference IDPR.

  Then, for each document (E508), step E509 tests whether the document is already shared. For this, the method relies on the means of selecting the document to be shared. Indeed, the user selects the document from a graphical interface. This interface makes it possible to display the thumbnails of the documents already shared and the documents stored locally and which are not shared. Thus, if the selection relates to a thumbnail, the method knows that this document is already shared through its TLI local index table, which references the path of this version.

  In the case where the document is already shared, an entry in the TLI local index table is selected. Step E510 retrieves the IDD of the document from this entry. Step E511 updates the local index table according to Fig. 7. Document processing stops following step E514.

  In case the document is not already shared, a new identifier is generated. In one embodiment, this identifier is created by the local station. An alternative is to request an identifier at station 100. Step 20 E513 updates the local index table according to FIG.

  The method of FIG. 5 continues with step E515 (FIG. 6) in the case where the test of step E514 is positive (all the documents to be shared are processed).

  With reference to FIG. 6, the continuation of the method of sharing a set of documents of FIG. 5 is described. FIG. 6 describes the composition and sending of the notification message to each of the recipient K's.

  Steps E517 to E524 describe the processing for a document.

  Step E517 adds the thumbnail to the FC collection file. Step E518 selects the entry of the local index table corresponding to the original version V of the current document. Steps E519 and E520 extract and add to the FC collection file the list of LPS server stations corresponding to this entry, that is to say the list of stations that serve the original version of the current document (for example the initiating station, s it contains the data). Step E521 tests whether the original version of the document is stored locally (referenced path of the selected entry). If yes, the IDD of the local station is added to the list of extracted server stations.

  The method according to steps E523 and E524 extracts and adds to the collection file the list of potential LPP server stations corresponding to this entry, that is to say the list of items that can serve the original version of the current document. At a minimum, this list contains the items in the LPR list, that is to say the items to which the notification is sent since they are likely to have the version later.

  The method according to step E527 creates a list L composed of the identifiers of the two extracted lists (server stations and potential server stations). For this, each of these two LPS and LPP lists is ordered decreasingly according to the presence and / or the bandwidth of each of the items (information extracted from the local table posts).

  The method according to step E528 extracts and adds the connection information of the items of the list thus constituted to the FC collection file (FIG. 9). According to another variant, this information is not integrated in the FC collection file, but is stored in the notification message sent to the recipient during step E529. In the case where the information concerning a recipient is incomplete (absent from the CA address book), the item requests this information from the central server that responds to the identifier of the recipient and the identifier of his reference position in the where this recipient is registered. The recovered information is stored in the CA Address Book.

  With reference to FIG. 7, updating of the local TLI index table has been described following step E510. Step E700 considers the V entries of the table corresponding to the identifier of the document to be shared. The method according to step E702 adds the LPR list (list of recipient reference stations) to the list of potential LPP server stations of the current entry for each of the V entries of the local index table.

  The update ends when all entries corresponding to the IDD ID of the document are processed.

  With reference to FIG. 8, the updating of the local index table TLI following step E512 has been described. The method according to step E800 creates V new entries in the local index table. V is the number of accessible versions of each shared document. Steps E801 to E809 describe the processing applied to each of these inputs. Steps E802 and E803 add the IDD of the current document and the current version number to the current entry. Step E804 is similar to that described in Figure 7 (step E702). In the case where the current version is not stored locally (E805), the document version is created and stored locally and the path of the current entry is referenced.

  The update of the TLI table stops when all versions are processed (E808).

  With reference to FIG. 9, the method relating to step E528 of FIG. 6 is described, making it possible to extract the connection information of S (integer) server stations from the LPS list and from P (integer). potential posts from the LPP list. The number of stations in the list of server stations and potential servers can be very high. To prevent the message size from being too large, not all login information for these items is sent. By cons, all the identifiers of the posts are sent. If the number of server stations (S) and the number of potential server stations (P) is too large (greater than a threshold Max (integer)), only the connection information of the SI (integer) first server stations and P1 (integer) first potential server stations are sent (the selection is made at step E901 described in FIG. 10). In any case, in step E903, the information of the IS server stations and the P1 potential server stations are sent. Steps E903 to E907 process the SI server stations. For each station, the method seeks to retrieve the connection information of the current station from the local table posts. According to one variant, this information can be retrieved from the central station table of the central server (station 100). In this case, once recovered, the local postal table is updated.

  The method according to step E905 tests whether the connection information could be obtained. If yes, that is, if the remote station is connected, this information is added to the notification message.

  Steps E909 through E914 process potential P1 servers. For each station, the method seeks to recover the connection information of the current station in a manner similar to that described above.

  With reference to FIG. 10, the method of selecting SI server stations is described according to a list of S server stations and P1 potential server stations according to a list of P stations. Step E1000 tests whether the number of server stations is greater than a threshold Max. If so, the top first posts of the list of server stations are considered. No potential server is considered (E1001). If not, all server stations are considered and Max-SI server stations are considered (E1002). To be able to consider a small number of items among a set, the presence and bandwidth criteria are used. The positions that are selected are the stations with the highest bandwidth and secondly those with the highest presence time (E1003 and E1004).

  Referring to Figure 11, there is described the sharing method implemented upon receipt of a notification message by a registered recipient.

  A notification message is sent to each recipient via a mail. For example, the FC collection file is an attachment to the message. In this case, when the user clicks on this attachment, the process extracts the number of shared documents (El 100). The other steps of Figure 11 describe the processing performed on the local station of the recipient with respect to information about each of these documents. Step E1102 extracts and stores the vignette locally. Step E1103 retrieves the identifier IDD of the document and the number of server stations (E1104) corresponding to the original version of this document (version V). For each of these server stations, the connection information is retrieved (E1107) and the local postal table is updated (E1108). The local index table is updated according to Figure 12 by considering V = K (original version). Steps E1113 to 1119 describe the same method for the list of potential server stations. Once the test of step E1122 is positive, the method continues with step E1801 of FIG. 18 so as to send a confirmation message to the recipients.

  Referring to Figure 12 there is described the method of updating the local index table following the receipt of a notification message (E1109 or E1118). Step E1200 tests whether the entry of the local index table corresponding to the current version of the current document exists. If not, a new entry is created according to figure 13. If yes, step E1201 tests whether this item is server of the original version V. If yes, the identifier of this item is deleted from the list of potential server positions (if it was in this list, of course) (E1202 and 1203). The identifier of the current extension is added to the list of server stations of the current entry if it is not already present (E1204 and E1205).

  The method according to step E1206 verifies whether the current station is a potential server of the original version. If yes, step E1207 tests whether the current item is in the list of server stations. If not, the identifier of the current item is added to the list of potential server items of the current entry if it is not already present (E1208 and E1209).

  With reference to FIG. 13, the method of updating the local index table following the reception of a notification message (E1200, that is to say when the local station receives a message has been described. notification that contains new documents that are not referenced in the local local table). Figure 13 describes the processing of each of the V entries created in the local index table. Step E1300 considers the first entry of this table. It corresponds to the thumbnail of the current document. Steps E1301 and E1302 create a new entry and add the IDD of the document and the version number to this current entry. Step E1303 tests whether the current entry corresponds to the original version V. If so, step E1304 tests whether the current position is server of the current version. If this is the case, step E1305 adds the IDD of the document to the list of LPS server stations of the current entry. If the current item is a potential server, it is added to the list of potential LPP server items of the current entry (E1306, E1307). In the case of processing the first entry, the path of this entry is referenced because the notification message contains the thumbnail of each shared document (E1309).

  Following receiving a notification and updating its index table as previously described with reference to Figure 11, the destination station may request a version that it does not have, of a shared document. For this, it implements a method making it possible to request a version of a shared document described with reference to FIG. 14. The step E1400 selects the entry of the local index table according to the IDD identifier of the document and the selected version number. Step E1401extracts the LPS list of the S servers and the LPP list of the P potential servers of the input thus selected. The method according to step E1402 creates a list of the identifiers of the two extracted lists (server stations and potential server stations). For this, each of these two LPS and LPP lists is ordered decreasingly according to the presence and / or the bandwidth of each of the items (information extracted from the local table posts). Step E1403 creates a request by inserting the IDD of the document and the version number. Steps E1405 to E1416 send the request to a remote station according to the information of the local index table and the local postal table. Each item in the ordered list is considered. The connection with this station is tested in step E1406 (FIG. 15). If a connection can be established with the current remote station, the request is sent to this extension. If this station sends in response the version of the requested document, the method continues with step E1801 of FIG. 18. It can be seen in the description of FIG. 17 that when a remote station can not serve a version of a document, it sends in response a list of LPS server stations and a list of potential LPP server stations of the document, regardless of the version. In this case, this remote station is deleted from the list of LPP server stations and added to the list of potential server stations (change of status of the remote station). In addition, the identifiers of these stations are stored in a list of responses created in advance by step E1404. A variation is to test the server workstations and the potential server stations as they are received.

  Step E1411 considers the list containing all the responses from the remote stations that can be connected: S2 (integer) server stations and P2 (integer) potential server stations. If this list is empty, the request is sent to the station 100 (central server) which stores this request (identifier IDD of the document, version number, list of the LPS server stations and potential LPP servers of the index local table). This request is served as soon as one of these stations connects. For this, each time a station connects to the central server, the station 100 assesses whether one of the queries stored in the query table can be honored. If this is the case, the request is sent to the remote station that responds to the central server. If this item can serve the document version, the central server stores this version until the requesting item is connected and the request is removed from the request table. If the remote station responds to a list of LPS server stations and a list of potential LPP server stations, these two lists are sent to the requesting station via the central server and the calling station drops in the case of the step E1414 which sets updating the local index table according to FIG.

  Referring to Figure 15, there is described the method of connecting a local station with a remote station, corresponding to step E1406 of Figure 14. Step E1500 tests whether the remote station information is available from from the local postal table. If this information is not present, the process stops. If so, the method according to step E1501 retrieves this information and tries to connect it to the remote station (E1502). If the connection information is out of date (and therefore the connection can not be established), the connection information of the remote station is deleted from the local post table (E1503).

  With reference to FIG. 16, the method of updating the local index table following step E1414 has been described. FIG. 16 describes the processing of each of the V entries corresponding to a document. Step E1600 considers an entry of this table. Step E1601 tests whether the current post is server of the current version of the document. If this is the case, the step E1602 tests whether the IDP identifier of this item is contained in the list of potential LPP server stations. If this is the case, step E1603 deletes this identifier from this list. Step E1604 tests whether the current station is contained in the list of LPS server stations of the current entry. If this is not the case, step E1605 adds the IDP identifier of the current station in the list of LPS server stations. Step E1606 tests whether the current item is a potential server of the current version of the document. If this is the case, step E1607 tests whether the IDP identifier of this item is contained in the list of LPS server stations. If this is not the case, step E1608 tests whether the current item is contained in the list of potential LPP server stations. If it is not, step E1609 adds the IDP of the current station to the list of potential LPP server stations of the current entry.

  With reference to FIG. 17, the response implemented with reference to a request sent by a remote station has been described. Step E1700 extracts the IDD ID of the document and the requested version number. The local station (which has just received a request) tests whether this version can be served. If so, that is, the local index table of this item contains an entry for that version and the path of that entry is referenced, the extension serves the version. If not, step E1702 creates a response message and the V entries of the local index table of that item are selected (E1702, E1703). The method according to step E1704 considers the current input V2. Entry VI (thumbnail) is not considered. Step E1705 extracts the current entry from the local index table. Step E1706 extracts the list of S server stations from this entry. Step El 707 tests whether the version of the document corresponding to the current entry can be served (referenced path). If this is the case, the IDP ID of the local station is added to the list of extracted server stations. Step E1709 extracts the list of potential P servers from the current entry. Step E1710 adds the two lists to the response message. Step E1711 extracts the connection information from each of the stations of these two lists and adds this information to the response message (FIG. 9). Step E1714 sends the message to the requesting station once all the selected entries have been considered.

  Referring to FIG. 18, the method of receiving a response following the issuing of a request for obtaining a document corresponding to step E1410 of FIG. 14 and step E1122 of FIG. Fig. 11. The method according to step E1800 tests whether the response is the version of the requested document. If this is not the case, the lists of servers and potential server stations corresponding to each version of this document are extracted from the message and the new server stations and potential stations are updated in the local index table to step E1414 of FIG. 14.

  If the version of the document has been obtained, step E1801 stores this version. Step E1802 extracts the entry from the local index table corresponding to this version. Step E1803 deletes the IDP ID of the local station from the list of potential servers and adds the path of the extracted entry (E1804). Steps E1805 to E1813 send a confirmation message of ability to serve the version considered at each of the stations referenced by this entry. Step El 805 creates the confirmation message. Thus, the post confirms that he has become the server of the version. Step E1806 extracts the list of S servers and the list of P potential servers of the current entry. Step E1807 adds the IDP ID of the local station, the IDD of the document and the version number to the message. Step E1808 considers the first item in the list of extensions (server and potential server positions). Step E1809 tries to connect to the current station according to FIG. 15. If the connection can not be established, the message is sent to station 100 which stores the message in the message table. The message will be sent to the destination station when it connects to the central server. If the connection has been established, the message is sent.

  Referring to Figure 19, there is described the method of receiving a confirmation message issued by a station become server. Steps E1900 and E1901 extract the IDD of the document, the version number and the IDP ID of the sender station from the message. The step E1903 updates the local index table of the local station according to FIG. 12 considering that the transmitting station is server.

  Referring to Figure 20, there is described the method of no longer serving a shared document or set of documents (eg a collection). This process is initiated by the user through a graphical interface not described here. In this case, the local station does not send a message to the destination stations. These stations are informed of the change of status of the local station when they request the version of the document and that the local station sends them in response the lists of the posts servers and potential servers. Step E2000 considers the first version of the document. Step E2001 extracts the corresponding entry from the local index table. Step E2002 removes the path of this entry. Step E2003 extracts the list of potential items LPP from the current entry and adds the IDP identifier of the local station to this list (E2004).

Claims (46)

  1. A method of sharing a digital document through a communication network, in particular of the peer-to-peer type, said method being implemented within a document creator station, characterized in that it comprises the steps following: i) obtain at least one identifier (IDD) of said document to be shared and / or a representation thereof; ii) obtaining at least one list (LD) of the recipients of said document in the network; iii) obtain at least one list of positions (LPS) able to serve said document in the network; iv) obtain at least one list of potential positions (LPP), which can serve the said document in the network; and v) send to the recipient stations in the list (LD) of the destination stations a notification including a representation of the digital document and / or the associated identifier, the list of positions (LPS) suitable for use, and the list of potential positions. (PPA).   2. Method according to claim 1, characterized in that each station wishing to share a document comprises at least one local index table (TLI) containing information belonging to the group formed by the identifier (IDD) of the document to share, to at least one representation (IDV) of said document to be shared, the access path (CHA) to said document, at least one identifier of a suitable station (IDPS), and at least one identifier of a potential position (IDPP) .   3. Method according to claim 2, characterized in that it further comprises a step of updating the local index table (TLI) by changing the status of a position belonging to the list of potential positions (LPP). ) in a position suitable for use following the receipt, from a receiving station, of a confirmation message of ability to serve the document.   4. Method according to one of claims 1 to 3, characterized in that it further comprises the step of obtaining at a central server station a central user table (TCU) containing information relating to at the user registration, a central station table (TCP) containing information relating to the connection of the stations to the communication network, a central table (TCM) containing information on the destination stations and a central request table (TCR). ) containing information about sharing notifications.   5. Method according to one of claims 2 to 4, characterized in that each station further comprises an address book (CA) containing information belonging to the group formed by the name of the user (NOU), an address message (EMA) in the network, a user ID (IDU) and an ID of a reference station (IDPR).   6. Method according to one of claims 2 to 5, characterized in that each station further comprises a local table posts (TLP) containing information belonging to the group formed by the identifier of the post (IDP), and information connection and bandwidth.   7. Method according to claim 2, characterized in that obtaining the identifier (IDD) of the document to be shared and / or the representation thereof is performed by the local index table (TU) of the station.   8. Method according to claim 4, characterized in that obtaining the identifier (IDD) of the document and / or the representation thereof is performed at the central server station.   9. The method of claim 2, characterized in that obtaining lists of suitable and potential positions (LPS and LPP) is performed by the local index table (TLI) station.   10. Method according to any one of claims 1 to 9, characterized in that the notification comprises connection information for a selected subset of positions belonging to the lists of suitable positions and potential positions (LPS and LPP).   11. The method of claim 10, characterized in that the subset of sets is determined according to a predetermined maximum number of stations.   12. The method of claim 10, characterized in that the suitable positions are taken in priority over the potential positions in the subset of positions.   13. The method of claim 10, characterized in that the subset of sets is determined according to a bandwidth criterion and / or time of presence of the station in the communication network.   14. A method of sharing a digital document through a communication network, in particular of the peer-to-peer type, said method being implemented within a destination station of said document, characterized in that it comprises the steps following: 1) to receive a notification comprising a representation of the digital document and / or the identifier (IDD) thereof, at least one list (LPS) of stations capable of serving the document and at least one list (LPP) of potential positions that could serve the digital document in the network; and 2) in response to the notification thus received, updating a local index table (TLI) comprising information belonging to the group formed by the identifier (IDD) of the document to be shared, at least one representation of said document to be shared , the access path (CHA) to said document, at least one identifier of a service station (IDPS), and at least one identifier of a potential station (IDPP).   15. Sharing method according to claim 14, characterized in that it further comprises, in order to obtain a digital document, the following steps: a) starting from the local index table (TLI) thus updated, extracting the 10 information relating to the sharing of the document as well as suitable positions and potential positions; and (b) send a request to obtain the document for at least one post from the list of suitable posts (LPS) and the list of potential posts (LPP) thus extracted.   16. The method of claim 15, characterized in that the request is sent sequentially to the positions among the lists of suitable positions (LPS) and potential positions (LPP) in a predetermined order until obtaining the document.   17. The method as claimed in claim 16, characterized in that it comprises a step of updating the local index table (TLI) by assigning the potential position status to the destination stations of the obtaining request which does not do not send the document in response to said obtaining request.   18. The method of claim 16, characterized in that the obtaining request and the lists of positions capable of serving (LPS) and potential positions (LPP), are sent to a central server station in the case where the document n has not been received following the sequential sending of the request for obtaining.   19. The method of claim 16, characterized in that the predetermined order of the sending is defined according to a bandwidth criterion and / or time of presence of the station in the communication network.   20. The method of claim 16, characterized in that it comprises a step of updating the local index table (TLI) following receipt in response to the request for obtaining a new list of server positions. and a new list of potential positions.   21. Method according to claim 20, characterized in that the new lists are taken into account for the sequential sending of the obtaining request.   22. Method according to any one of claims 16 to 21, characterized in that it comprises a step of sending to the positions of the lists of suitable positions (LPS) and potential positions (LPP), a message confirming the ability to serve the digital document, following receipt of a response to the request for obtaining said digital document.   23. Device for sharing a digital document through a communication network, in particular of the peer-to-peer type, said device being integrated within a document creator station, characterized in that it comprises: to obtain at least one identifier (IDD) of said document to be shared and / or a representation thereof; means for obtaining at least a list of the stations (LD) receiving the document in the network; means for obtaining at least one list of stations (LPS) able to serve said document in the network; means for obtaining at least one list (LPP) of potential items, capable of serving said document in the network; and - means for sending to the recipient stations belonging to the list (LD) of the destination stations a notification comprising a representation of the digital document and / or the associated identifier, the list (LPS) of the stations that can serve, and the list ( LPP) potential positions.   24. Device according to claim 23, characterized in that each station wishing to share a document comprises at least one local index table (TLI) containing information belonging to the group formed by the identifier (IDD) of the document to be shared, the at least one representation (IDV) of said document to be shared, the access path (CHA) to said document, at least one identifier of a suitable station (IDPS), and at least one identifier of a potential position (IDPP) .   25. Device according to claim 24, characterized in that it further comprises means for updating the local index table (TL!) By changing the status of a position belonging to the list of potential positions ( LPP) in station adapted to serve following the reception, from a destination station, of a confirmation message of aptitude to serve the document.   26. Device according to one of claims 23 to 25, characterized in that it further comprises means for obtaining at a central server station a central user table (TCU) containing information relating to the user registration, a central station table (TCP) containing information relating to the connection of the stations to the communication network, a central table (TCM) containing information on the destination stations and a central request table (TCR) containing information about sharing notifications.   27. Device according to one of claims 24 to 26, characterized in that each station further comprises an address book (CA) containing information belonging to the group formed by the name of the user (NOU), an address message (EMA) in the network, a user ID (IDU) and an ID of a reference station (IDPR).   28. Device according to one of claims 24 to 27, characterized in that each station further comprises a local table posts (TLP) containing information belonging to the group formed by the identifier of the station (IDP), and information connection and bandwidth.   29. Device according to claim 24, characterized in that the means for obtaining the identifier (IDD) of the document to be shared and / or the representation thereof are formed by the local index table (TLI) of the post.   30. Device according to claim 26, characterized in that the means for obtaining the identifier (IDD) of the document and / or the representation thereof are formed by the central server station.   31. Device according to claim 24, characterized in that the means for obtaining lists of suitable and potential positions (LPS and LPP) are formed by the local index table (TLI) of the station.   32. Device according to any one of claims 23 to 31, characterized in that the notification comprises connection information for a selected subset of positions belonging to the lists of suitable positions and potential positions (LPS and LPP).   33. Device according to claim 32, characterized in that the subset of sets is determined according to a predetermined maximum number of stations.   34. Apparatus according to claim 32, characterized in that the suitable positions are taken priority over the potential positions in the subset of stations.   35. Device according to claim 32, characterized in that the subset of stations is determined according to a bandwidth criterion and / or time of presence of the station in the communication network.   36. Device for sharing a digital document through a communication network, in particular of the peer-to-peer type, said device being integrated within a destination station of said document, characterized in that it comprises: - means receiving means capable of receiving a notification comprising a representation of the digital document and / or the identifier (IDD) thereof, at least one list (LPS) of items capable of serving the document and at least one list (LPP) of potential positions that could serve the digital document in the network; and means adapted, in response to the notification thus received, to update a local index table (TLI) comprising information belonging to the group formed by the identifier (IDD) of the document to be shared, at least one representation said document to be shared, the access path (CHA) to said document, at least one identifier of a suitable station (IDPS), and at least one identifier of a potential station (IDPP).   37. Sharing device according to claim 36, characterized in that it furthermore comprises, in order to obtain a digital document: means capable, from the updated local index table (TLI), of extracting the information relating to the sharing of the document as well as suitable positions and potential positions; and transmitting means capable of sending a request for obtaining the document to at least one item belonging to the list of suitable stations (LPS) and to the list of potential stations (LPP) thus extracted.   38. Device according to claim 37, characterized in that it comprises means capable of sending the request is sequentially to the positions among the lists of suitable positions (LPS) and potential positions (LPP) in a predetermined order until obtained of the document.   39. Device according to claim 38, characterized in that it comprises means for updating the local index table (TLI) by assigning the potential position status to the destination of the obtaining request which n ' do not send the document in response to said obtaining request.   40. Device according to claim 38, characterized in that the request for obtaining and the lists of positions capable of serving (LPS) and potential positions (LPP), are sent to a central server station in the case where the document n has not been received following the sequential sending of the request for obtaining.   41. Device according to claim 38, characterized in that the predetermined order of the sending is defined according to a bandwidth criterion and / or time of presence of the station in the communication network.   42. Device according to claim 38, characterized in that it comprises means for updating the local index table (TLI) following receipt in response to the request for obtaining a new list of server positions. and a new list of potential positions.   43. Device according to claim 42, characterized in that the new lists are taken into account for the sequential sending of the request for obtaining.   44. Device according to any one of claims 38 to 43, characterized in that it comprises means for sending to the positions of the lists of suitable positions (LPS) and potential positions (LPP), a message confirming the ability to serve the digital document, following receipt of a response to the request for obtaining said digital document.   45. Information carrier readable by a computer system, possibly totally or partially removable, in particular a CD-ROM or magnetic medium, such as a hard disk or a diskette, or a transmissible medium, such as an electrical or optical signal, characterized in that it comprises instructions of a computer program for implementing a sharing method according to any one of claims 1 to 22, when the program is loaded and executed by a computer system.   46. Computer program stored on an information carrier, said program comprising instructions for implementing a sharing method according to any one of claims 1 to 22, when this program is loaded and executed by a user. computer system.