JP2005092380A - File sharing system and sharing management method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system and a method to carry out shared management of a file of a server system from a plurality of user terminals. <P>SOLUTION: A file is shared among user terminals by managing a plurality of data including update contents based on a revision management number, an edit management number, and file management information of creator's information. The user terminal copies a plurality of data including file management information and edit data. When editing is performed, the contents of modification are notified to the server system, and the server system performs update management of the file. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a file sharing system for sharing data by a plurality of users and updating the data.

  When data is shared in an environment such as a LAN, browsing can be performed by a plurality of users. However, only one user can edit data, and the other users are generally observers. In addition, when updating data, whether the date and time of the data that the user has is compared with the date and time of the server data, or whether the server checks the update date and time of the user data and sends update data Is a common update method. A technique relating to such a data sharing method for a plurality of users is disclosed in Patent Document 1.

  In particular, Patent Document 1 describes an automatic file update and distribution method. In this update method, when a file is accessed from a user terminal, the file in the user terminal is automatically compared with the last update date and time of the file in the center apparatus, and the update file is sent from the center apparatus. It is a mechanism. That is, a method is disclosed in which shared data is held in each terminal without being stored in the center, and the center apparatus performs update management.

JP 2002-189622 A

  Even with the technique disclosed in Patent Document 1, when a single file is shared by a plurality of users, only one user can edit the file, and simultaneous editing by a plurality of users is not possible. Therefore, in order for two or more users to edit, one person must first edit, and after editing is completed and the file is closed, another user must start editing.

  Further, in the above method, only the content of the last saved file is saved in the server, and the file edited by each user is overwritten, so it is not saved.

  Furthermore, if it is desired to keep the editing results of each user, it is necessary to save them under a different name. At this time, it is impossible to manage that the same file is created by editing the same file unless file management is performed such as providing regularity to the file name or making the save destination folder common.

  In the technique of Japanese Patent Laid-Open No. 2002-189622, an update file is not sent unless the file is accessed. Therefore, when a plurality of files are shared by arbitrary users and the files are frequently updated (for example, Internet conference), it is necessary to notify each user of the update in real time. .

  An object of the present invention is to provide a file sharing system that solves the above-described problems and allows a plurality of users to smoothly share a file and also manage a file update history.

  In the present invention, for example, data called File A is not a file body, but is composed of a plurality of revision files and a file being edited. The revision file and the file being edited are managed on the server device side based on file management information such as a revision management number, an editing management number, and creator information. When the user reads out File A, all files managed as File A (revision files and editing files) are copied to the user terminal. The difference from the prior art is not that the files are copied, but the revision files and files being edited and their management status are copied. Therefore, the user can know all revision files and their creators by simply opening File A, and can freely edit any revision file.

  Furthermore, the user terminal is provided with a function for notifying the server device of editing so that all files edited by an arbitrary user remain in the log, and the server receiving the editing notification distinguishes the files by editing management numbers and the like. For example, the user saves the edited file.

  More specifically, a proposal under discussion for a revision 0 file (a file edited by the user) is stored directly under revision 0. When a decision is selected from among them, the revision is updated and revision 1 is newly saved. Thus, efficient file management can be performed by two-dimensionally managing the editing file and the revision file.

  According to the present invention, shared data can be freely edited by a plurality of users through a network such as a LAN or the Internet, and updated data can be instantly developed in real time.

  A server device connected to multiple user terminals manages multiple data including update contents based on revision management number, edit management number, and file management information of creator information. Share. When the user terminal copies a plurality of data including the file management information and the editing process data and performs editing, the user terminal notifies the server device of the change contents, and the server device manages the update of the file. A more specific embodiment will be described next.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. Here, using the system of FIG. 1, editing of data stored in the server device 101, for example, the drafting source file 103 (File A-R0), is performed in parallel on the user A terminal 111 and the B terminal 115. The method to perform is demonstrated. Server device 101 and user A terminal 111 and B terminal 115 are connected via network 110. The drafting source file 103 is shared between the users A and B, and for example, a network conference is performed.

  A location where the actual file body of File A is stored is a File A box 102. Files in the File A box 102 are managed by so-called file management information 109 such as an edit management number 106, creator information 107, and revision management number 108. That is, the drafting source file 103 stored in the server apparatus 101 is managed by the file management information 109.

  When accessing the server apparatus 101 of FIG. 1, the only file that can actually be seen by the file browsing program is File A. When File A is opened, the file 103 is copied to the user terminal, and the file 102 is opened. This point will be described in more detail later.

  The suffix number to be added is defined as an edit management number 106 each time each user notifies the server apparatus 101 of editing. The accessor information 104 is information (for example, user name) of a user who is accessing File A, and the creator information 107 is information (for example, user name) of the creator of each file. This will be specifically described below. Assume that the users A and B edit the drafting source file 103 and then notify the server apparatus 101 of the editing. At this time, the files stored in the server apparatus 101 are, for example, File A-R0 (draft source file 102), File A-R0 # 1 (file edited by user A), File A-R0 # 2 (user B). Is a file that has been edited). The newly created File A-R0 # 1 and File A-R0 # 2 are associated as files 202 and 203, respectively, as shown in FIG. At this time, the suffix numbers (# 1, # 2) added to the file name are edit management numbers. In the creator information 107, information that the creators of the files 202 and 203 are the users A and B, respectively, is recorded. In order to cause the server apparatus 101 to perform the above processing, a function included in the user terminal is defined as an edit notification function 112.

  Next, each time a revision update is notified to the server apparatus 101, the suffix number added is defined as a revision management number 108. The revision update is performed only when the condition set in the revision update condition 105 is satisfied. Examples of the conditions set in the revision update condition 105 include “User A or B is a revision update authority”, “Users A and B are revision update authorities”, and the like. The former can be updated by both the user A and the user B, and the latter can be updated only after the users A and B permit it. This will be specifically described below.

  For example, when the user A updates the drafting source file 103 and the user A updates the revision, the files stored in the server device 101 are, for example, File A-R0 (drafting source file 103), File A-R1 (user A Is a file created by a revision update). The newly created File A-R1 is additionally stored in the server apparatus 101 like the file 204 in FIG. At this time, the suffix number (-R1) added to the file name is the revision management number 105. In the creator information, information that the creator of the file 204 is the user A is recorded. In order to cause the server apparatus 101 to perform the processing as described above, a function provided in the user terminal is defined as a revision update notification function 113.

  It should be noted that the edit management number 106 and the revision management number 108 need only be known to be different from each other, and need not be a suffix number, but may be any information that can distinguish the files.

  FIG. 2B shows the file management status in the server device at the moment when the drafting source file 103 is updated. At this time, the files 202 and 203 (File A-R0 # 1, File A-R0 # 2) that have been edited so far have been deleted, but may be left if necessary. FIG. 2 (c) shows the file management status in the server device after the file 204 has been edited twice.

  As described above, when the file management status in the server apparatus 101 is as shown in FIG. 2C, when the user A looks at the file in the server apparatus 101, only the file A is visible. Here, when this File A is read, the files (files 201, 204, 205, 206) currently managed as File A are copied to the user terminal. As a result, for example, a File A window 301 as shown in FIG. 3 is opened on the screen of the user A terminal. In the window 302, the files copied earlier (files 201, 204, 205, and 206) and the creator of each file are displayed. The creator is information read from the creator information 107 in the server apparatus 101 when the File A window 301 is opened. In window 303, the contents of the file selected in window 302 are displayed.

  When the user A is set as a revision update authority in the revision update condition 105, for example, a revision update button 305 appears as shown in FIG.

  As shown in the window 303 of FIG. 3, when the user A opens the File A window 301, the contents of the file that has been edited or updated by the user (user A) are displayed in the window 303 in advance. It is desirable to do so. When the user A closes the File A window 303, the file close notification function of the user A terminal works. As a result, file server A is notified to the server apparatus 101 and user A is deleted from the accessor information 104.

  Consider a process in which the drafting source file 103 (File A-R0) is edited by the users A and B, and the final draft is File A-R1. It is assumed that only the user A is permitted to update the revision in the revision update condition.

  First, a flowchart when the user A reads a file stored in the server apparatus 101 is shown in FIG. As shown in FIG. 4, the user A accesses the server apparatus 101 and reads File A in step 401. The server apparatus 101 records user A in the accessor information 104 in step 402. Next, in step 403, the management information 109 of File A, the drafting source file 103 (File A-R0) under the management, and the revision update information 105 are transmitted to the user A terminal 111. Receiving this, the user terminal 111 opens the File A window 408 based on the management information of File A received in Step 404. FIG. 5 shows a window opened on the user A terminal 111 at this time. In the window 409, the file name of the file currently managed as File A and its creator. (The creator of the drafting source file 103 is Administrator). In the window 410, the contents of the file selected in the window 409 are displayed. Next, in step 405, the revision update condition received earlier is compared with the condition of the user A terminal 111. If they match, the process proceeds to step 406, and if they do not match, the process proceeds to step 407. As a result, as shown in FIG. 5, the user A terminal 111 displays the edit button 411 for editing, and the user A is allowed to update the revision, so the process proceeds to step 406 and the revision update button 412 is displayed. The

  For the user B terminal, the File A window 408 is opened in the same steps as steps 401 to 404. Since user B is not permitted to update the revision, the process proceeds to step 407 and only editing can be performed.

  Next, a flowchart when the user A edits a file is shown in FIG. As in step 501 in FIG. 6, the user A edits the drafting source file 103 (File A-R0) and notifies the server apparatus 101 of the editing. As in steps 502 and 503, the server apparatus 101 renames the edited File A-R0 received from the user A terminal 111 as, for example, File A-R0 # 1, and the File A box 102 of the server apparatus 101 To store. In step 504, File A-R0 # 1 is transmitted to the user recorded in the accessor information 104. The users A and B terminals receive File A-R0 # 1 and additionally register it in the window 409. Thereafter, the user A terminal 111 and the user B terminal 115 proceed to steps 507 and 510, respectively.

  Next, FIG. 7 shows a flowchart when the user A performs the revision update. As shown in step 601 of FIG. 7, the user A transmits a revision update of File A-R0 # 1 to the server apparatus 101. When the proposal for File A-R0 # 1 is decided and the revision is updated, if the existing editing files (files with editing management numbers # 1 and # 2) are not necessary, step 603 can be performed. If necessary, step 603 can be skipped. Next, the server apparatus 101 renames File A-R0 # 1 received from the user A terminal 111 as, for example, File A-R1, and stores it in the File A box 102 of the server apparatus 101. Then, File A-R1 is transmitted to the user recorded in the accessor information 107. The subsequent processing of each user terminal is as shown in steps 606 to 611.

  In the present invention, when the file X is read, the file is copied (cached) from the server to the user terminal, so that editing can be performed by a plurality of users. In addition, since all the users who read the file X are recorded as accessor information, the editing / update information can be transmitted only to users who need the edit / update information of the file X. That is, for example, editing / update information of the file X is not transmitted to the user who is discussing the file Y at the same time.

  Editor information is added to all files being edited and revision updated, so it is possible to know who has edited or updated revision at the moment when one file is opened.

The block diagram of embodiment. The figure of the management status of File A in the server device. An example of the user interface when File A is opened. The flowchart when the user A reads a file. An example of a window when user A reads a file. The flowchart when the user A edits a file. The flowchart when the user A performs revision update.

Explanation of symbols

101 ... Server device, 102 ... File A box,
103 ... drafting source file (File A-R0), 104 ... accessor information,
105 ... Revision update conditions, 106 ... Editing management number, 107 ... Creator information,
108 ... revision management number, 109 ... file management information,
110 ... Network, 111 ... User A terminal, 112 ... Edit notification function,
113 ... Revision update notification function, 114 ... File close notification function,
115: User B terminal 201: File A-R0 202: File A-R0 # 1
203 ... File A-R0 # 2, 204 ... File A-R1, 205 ... File A-R1 # 1,
206 ... File A-R1 # 2, 301 ... File A window, 304 ... Edit button,
305 ... Revision update button, 408 ... File A window,
411 ... Edit button, 412 ... Revision update button,

Claims (3)

In a file sharing system that records files that are shared and accessed from multiple user terminals, for each target file to be shared and managed, all files created or edited, creator information of the files, and update management number information are stored. In response to a read request from the user terminal, all the files and information of the target file to be shared and managed are notified to the user terminal, and additional storage of the edit file and management of the management number are managed in response to the edit notification from the user terminal. A file-sharing system characterized by performing. A sharing management method of a file sharing system for recording files shared and accessed from a plurality of user terminals,
For each target file to be shared and managed, storing all created or edited files, creator information of the files, and update management number information;
In response to a read request from the user terminal, notifying the user terminal of all the files and information of the target file to be shared and managed,
A file sharing management method comprising the steps of additionally storing an edited file and updating and managing a management number in response to an editing notification from a user terminal. 3. The file sharing management method according to claim 2, wherein the update of the management number includes a step performed in response to an edit notification from a specific user terminal.

Images