JP7727481B2 - File management system, file management method, and file management program - Google Patents

Description

The present invention relates to a file management system, a file management method, and a file management program.

Conventionally, systems for managing shared files stored on a server are known (see, for example, Patent Document 1). For example, Patent Document 1 describes a system that reserves a shared file that has been locked based on a client's request so that it can be edited by another client as soon as it is unlocked, and that forcibly unlocks a shared file if it has been locked for an extended period of time.

Patent No. 5373723

However, with conventional technology, the locked state of a shared file is not released until it has been locked for a long time, which results in the shared file being monopolized by a specific user, preventing other users from editing the shared file for an extended period of time.

The object of the present invention is to provide a file management system, file management method, and file management program that prevents a specific user from monopolizing editing of a shared file and allows multiple users to edit the shared file appropriately.

A file management system according to one aspect of the present invention includes: a reception processing unit that receives an edit request from a first client for a shared file that is accessible to each of multiple clients via a network; a lock processing unit that sets the shared file to a locked state in which only the first client can edit the shared file; and a setting processing unit that notifies the first client of a candidate lock time, which is the period of the locked state, based on operation history information regarding past edit operations on the shared file, and sets the lock time in accordance with the operation on the first client for the candidate time.

A file management method according to another aspect of the present invention is a method in which one or more processors execute the following steps: a receiving step in which one or more processors receive an edit request from a first client for a shared file that is accessible to each of multiple clients via a network; a locking step in which the shared file is set to a locked state in which only the first client can edit the shared file; and a setting step in which the first client is notified of a candidate lock time, which is the period of the locked state, based on operation history information regarding past edit operations on the shared file, and the lock time is set in accordance with the operation on the first client for the candidate time.

A file management program according to another aspect of the present invention is a program for causing one or more processors to execute the following steps: a receiving step for receiving an edit request from a first client for a shared file that is accessible to each of multiple clients via a network; a locking step for setting a locked state in which only the first client can edit the shared file; and a setting step for notifying the first client of a candidate lock time, which is the period of the locked state, based on operation history information regarding past edit operations on the shared file, and setting the lock time in accordance with the operation on the first client for the candidate time.

The present invention provides a file management system, file management method, and file management program that prevents a specific user from monopolizing editing of a shared file and allows multiple users to edit the shared file appropriately.

FIG. 1 is a functional block diagram showing the configuration of a file management system according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 3 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 4 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 5 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 6 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 7 is a diagram showing an example of a screen displayed on a user terminal according to an embodiment of the present invention. FIG. 8 is a flowchart illustrating an example of a procedure for a file management process executed in the file management system according to an embodiment of the present invention. FIG. 9 is a diagram showing an example of a screen displayed on a user terminal according to another embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen displayed on a user terminal according to another embodiment of the present invention. FIG. 11 is a diagram showing an example of a screen displayed on a user terminal according to another embodiment of the present invention.

Embodiments of the present invention will now be described with reference to the accompanying drawings. Note that the following embodiments are merely examples of embodiments of the present invention and are not intended to limit the technical scope of the present invention.

[File Management System 10]
1 is a block diagram showing the configuration of a file management system 10 according to an embodiment of the present invention. The file management system 10 includes a management server 1 and a user terminal 2. The management server 1 and the user terminal 2 are connected to each other via a network N1 (e.g., the Internet, a LAN, etc.). The file management system 10 may include multiple user terminals 2. The user terminal 2 is an example of a client of the present invention.

In the file management system 10, the management server 1 manages files uploaded from the user terminal 2. The management server 1 also provides users with a file management service that manages files stored in the memory unit 12. For example, the management server 1 manages multiple files stored in the memory unit 12 so that each of the multiple user terminals 2 can access them via the network N1. In other words, the management server 1 manages the files as shared files.

Each user of multiple user terminals 2 uses a specified application (file management application) to upload files such as document files created on their own user terminal 2 to the management server 1. Each user also uses the file management application to access the management server 1 and download shared files to their user terminal 2 for editing, viewing, etc. When each user finishes editing the downloaded shared file on their user terminal 2, they upload it back to the management server 1. The management server 1 overwrites and saves the edited shared file re-uploaded from the user terminal 2.

The file management system 10 is an example of a file management system of the present invention. Note that the file management system of the present invention may also be configured with the management server 1 alone.

[Management Server 1]
1, the management server 1 includes a control unit 11, a storage unit 12, an operation display unit 13, and a communication unit 14. The management server 1 may be configured as a personal computer, a NAS (Network Attached Storage), or the like.

The communication unit 14 is a communication interface that connects the management server 1 to the network N1 via a wired or wireless connection and performs data communication with the user terminal 2 via the network N1 in accordance with a predetermined communication protocol. The network N1 may be configured, for example, by the Internet or a LAN.

The operation display unit 13 is a user interface that includes a display unit such as a liquid crystal display or organic EL display that displays various information, and an operation unit such as a mouse, keyboard, or touch panel that accepts operations.

The storage unit 12 is a non-volatile storage unit such as a hard disk drive (HDD), solid state drive (SSD), or flash memory that stores various types of information. The storage unit 12 stores data such as shared files managed by the management server 1.

For example, a user launches the file management application on the user terminal 2 and uploads a desired file to the management server 1. The control unit 11 stores the shared file in a specified folder based on the user's operation. For example, as shown in FIG. 2, the management server 1 stores multiple shared files in a hierarchical structure for each folder. Each user terminal 2 can access the management server 1 via the network N1 to display the file list page shown in FIG. 2 (an example of a shared page of the present invention). Note that the shared file may also be stored on a device (such as a data server) different from the management server 1.

The memory unit 12 also stores a file management program that causes the control unit 11 to execute the file management process (see Figure 8) described below. For example, the file management program is non-temporarily recorded on a computer-readable recording medium such as a CD or DVD, and is read by a reading device (not shown) such as a CD drive or DVD drive provided on the management server 1 and stored in the memory unit 12. The file management program may also be distributed from another server and stored in the memory unit 12.

The control unit 11 has control devices such as a CPU, ROM, and RAM. The CPU is a processor that executes various types of arithmetic operations. The ROM pre-stores control programs such as the BIOS and OS that cause the CPU to execute various processes. The RAM stores various types of information and is used as temporary storage memory (work area) for the various processes executed by the CPU. The control unit 11 controls the management server 1 by having the CPU execute various control programs pre-stored in the ROM or memory unit 12.

Specifically, the control unit 11 includes various processing units such as a reception processing unit 111, a lock processing unit 112, a setting processing unit 113, a file processing unit 114, an unlocking processing unit 115, and a display processing unit 116. The control unit 11 functions as the various processing units by executing various processes in accordance with the file management program. Some or all of the processing units included in the control unit 11 may be configured with electronic circuits. The file management program may be a program that causes multiple processors to function as the various processing units.

The reception processing unit 111 receives various types of operation information from each user terminal 2. Specifically, the reception processing unit 111 receives a shared file selection operation from the user terminal 2 on a shared screen (shared page) displayed on the user terminal 2 by the display processing unit 116.

For example, the display processing unit 116 displays file information about the shared file on a shared page (the file list page shown in FIG. 2) that can be accessed from each of multiple user terminals 2 via network N1. The file list page shown in FIG. 2 lists multiple folders and multiple files c1 to c4 stored in a folder selected by user A (here, "folder C") on user terminal 2A (an example of a first client of the present invention). Here, when user A selects a specific shared file ("file c4") on the file list page (see FIG. 2) displayed on user terminal 2A, the reception processing unit 111 accepts the selection operation.

The reception processing unit 111 also receives edit requests for shared files from the user terminal 2. For example, when user A selects "file c4" and selects the edit download button B1 on the file list page (see FIG. 2) displayed on user terminal 2A, the reception processing unit 111 receives the edit request. As another example, when user A selects "file c4" on the file list page (see FIG. 2) displayed on user terminal 2A and performs an operation (drag-and-drop operation) to move the file to a folder or the like on user terminal 2A, the reception processing unit 111 receives the edit request. The operation of selecting the edit download button B1 (edit download operation) and the drag-and-drop operation are examples of edit requests of the present invention. Edit requests of the present invention are not limited to these operations and include well-known edit operations. For example, the edit request may be an edit operation within a website.

The reception processing unit 111 also accepts upload operations for shared files from user terminal 2. For example, when user A edits and uploads a shared file ("file c4") downloaded to user terminal 2A, the reception processing unit 111 accepts the upload operation.

The lock processing unit 112 sets the shared file to a locked state so that only specific user terminals 2 can edit the shared file. For example, if "file c4" is downloaded to user terminal 2A, the lock processing unit 112 sets "file c4" to a locked state. In this case, user terminal 2A can edit "file c4," but other user terminals 2 cannot edit "file c4." In other words, the lock processing unit 112 grants editing authority for the shared file to specific user terminals 2. The lock processing unit 112 may also grant editing authority for the shared file to a user's login ID. Note that when "file c4" is set to a locked state, other user terminals 2 may be able to view "file c4."

The setting processing unit 113 sets the lock time, which is the period of time during which the shared file is locked, based on operation history information regarding past editing operations on the shared file. For example, the setting processing unit 113 sets the lock time based on information such as the type of shared file and the total time (or average time) required to download, edit, and re-upload the shared file in the past.

In another embodiment, the setting processing unit 113 may set the lock time to a predicted time calculated based on the operation history information. For example, some shared files have a relatively long total time the first time they are edited, and the total time tends to become shorter as the number of edits increases. In such a case, the setting processing unit 113 calculates a predicted time based on the progress of the total time, and sets the calculated predicted time as the lock time.

In another embodiment, the setting processing unit 113 may set the lock time according to the user. For example, the operation history information is associated with identification information (user ID) of the user who performed the editing work. In this case, the setting processing unit 113 identifies the user who made the editing request, extracts the operation history information corresponding to the identified user, and sets the lock time based on the extracted operation history information.

Here, the operation history information is stored in association with each shared file stored in the storage unit 12. The control unit 11 accumulates operation history information related to user editing operations for each shared file. For shared files that are not associated with the operation history information, the setting processing unit 113 may set the lock time based on the file attributes (name, update date and time, type, size, etc.), number of pages, etc.

Specifically, the setting processing unit 113 calculates a candidate time for the lock time based on the operation history information and notifies the user terminal 2 of the calculated candidate time. For example, when user A selects "file c4" and selects the edit download button B1 on the file list page (see FIG. 2) displayed on user terminal 2A, the setting processing unit 113 calculates the candidate time as the average time (e.g., "10 minutes") of the total time previously required to download, edit, and re-upload "file c4," and displays the calculated candidate time "10 minutes" on user terminal 2A (see FIG. 3).

User A of user terminal 2A can change the candidate time on screen F1 shown in Figure 3. When the setting processing unit 113 acquires a change time for the candidate time from user terminal 2A, it sets the change time to the lock time. For example, if user A changes the candidate time to "15 minutes" and presses the "Start" button, the setting processing unit 113 sets the lock time to "15 minutes." Note that, for example, if user A presses the "Start" button without changing the candidate time from "10 minutes," the setting processing unit 113 sets the lock time to "10 minutes."

Furthermore, when the "Start" button is pressed on screen F1 shown in FIG. 3, the file processing unit 114 executes the download process for the shared file. In this case, the file processing unit 114 downloads "file c4" to user terminal 2A. While the download process is being executed, the file processing unit 114 displays the progress status F2 of the download process on user terminal 2A, as shown in FIG. 4.

The release processing unit 115 releases the locked state of the shared file (sets it to an unlocked state). For example, the release processing unit 115 releases the locked state of the shared file (e.g., "file c4") when the lock time (e.g., "10 minutes") has elapsed since the shared file was set to a locked state.

Also, for example, the release processing unit 115 releases the lock state if editing of the shared file ("file c4") is completed before the lock time ("10 minutes") is reached. Specifically, when user A finishes editing "file c4" on user terminal 2A and performs an upload operation, the file processing unit 114 executes the upload process for "file c4." Furthermore, the file processing unit 114 overwrites and saves the edited "file c4" uploaded from user terminal 2, and the release processing unit 115 releases the lock state of "file c4."

Once "file c4" is unlocked, each user terminal 2 will be able to edit "file c4."

Here, the control unit 11 is configured to allow other users to recognize that a shared file is locked when the shared file is set to a locked state.

For example, when "file c4" is set to a locked state and the reception processing unit 111 receives access to "file c4" from user terminal 2B (an example of a second client of the present invention), the display processing unit 116 displays lock information indicating that "file c4" is set to a locked state in association with "file c4" on the file list page (see FIG. 5). Specifically, as shown in FIG. 5, the display processing unit 116 displays a warning image M1 indicating that "file c4" is set to a locked state, opposite the information about "file c4."

Furthermore, when user B places the mouse image Ms over the warning image M1 on user terminal 2B (performs a mouse-over operation) (see Figure 6), the display processing unit 116 displays, on the file list page, the identification information (user ID, name, etc.) of user A who is editing "file c4" and lock time information related to the lock time. For example, as shown in Figure 7, the display processing unit 116 displays a lock information screen F3 including information on the remaining time of the lock time ("10 minutes remaining"). In another embodiment, the display processing unit 116 may also display the elapsed time since the locked state was set.

In this way, the lock information may include identification information of the user currently editing the shared file and lock time information regarding the lock time. Furthermore, the lock time information may be information about the remaining time of the lock time, or the elapsed time since the lock state was set.

In addition, when a shared file that has been set to a locked state is selected, the display processing unit 116 may change the edit download button B1 (see Figure 2) to warning information M2 (see Figures 5 to 7) to prevent the shared file from being edited and downloaded.

With the above-described configuration of the display processing unit 116, when user B attempts to edit "file c4," he or she will be able to see that "file c4" is being edited by user A.

[User terminal 2]
1, the user terminal 2 includes a control unit 21, a storage unit 22, an operation display unit 23, and a communication unit 24. The user terminal 2 is an information processing device such as a personal computer, a smartphone, or a tablet terminal.

The communication unit 24 is a communication interface that connects the user terminal 2 to the network N1 via a wired or wireless connection and performs data communication with external devices such as the management server 1 via the network N1 in accordance with a specified communication protocol.

The operation display unit 23 is a user interface that includes a display unit such as an LCD display or organic EL display that displays information such as various web pages, and an operation unit such as a mouse, keyboard, or touch panel that accepts operations.

The memory unit 22 is a non-volatile memory unit such as an HDD, SSD, or flash memory that stores various types of information. For example, the memory unit 22 stores a control program such as a browser program. Specifically, the browser program is a control program that causes the control unit 21 to execute communication processing with an external device such as the management server 1 in accordance with a communication protocol such as HTTP (Hypertext Transfer Protocol). The browser program may also be a dedicated application for executing communication processing with the management server 1 in accordance with a predetermined communication protocol.

The control unit 21 has control devices such as a CPU, ROM, and RAM. The CPU is a processor that executes various types of arithmetic operations. The ROM is a non-volatile storage unit that pre-stores control programs such as BIOS and OS that cause the CPU to execute various processes. The RAM is a volatile or non-volatile storage unit that stores various types of information and is used as temporary storage memory (work area) for the various processes executed by the CPU. The control unit 21 controls the user terminal 2 by having the CPU execute various control programs pre-stored in the ROM or storage unit 22.

Specifically, the control unit 21 functions as a browser processing unit by executing various processes in accordance with the browser program stored in the memory unit 22. The control unit 11 is capable of executing browser processing to display web pages provided by the management server 1 via the network N1 on the operation display unit 23 and input operations for the operation display unit 23 into the management server 1. In other words, the user terminal 2 can function as an operation terminal for the management server 1 by having the browser program executed by the control unit 21. Note that some or all of the processing units included in the control unit 21 may be configured as electronic circuits.

When a user operates the user terminal 2 to request access to a specific URL corresponding to the site of the file management service provided by the management server 1, the control unit 21 acquires the webpage data of the site from the management server 1 and displays the webpage of the site on the operation display unit 23. If a specific application (file management application) corresponding to the management server 1 is installed on the user terminal 2, the user of the user terminal 2 can launch the file management application to display the webpage of the site on the operation display unit 23.

In addition, the control unit 11 uploads files stored on the user terminal 2 to the management server 1 in response to user operations. In addition, the control unit 11 downloads files stored on the management server 1 to the user terminal 2 in response to user operations. In addition, the control unit 11 edits files downloaded from the management server 1 in response to user operations, and then re-uploads them to the management server 1.

The control unit 11 also displays web pages such as file list pages (see Figures 2 to 7) on the operation display unit 23 of the user terminal 2. The control unit 11 also accepts user operations on each file list page.

[File management process]
An example of the procedure of the file management process executed in the file management system 10 will be described below with reference to FIG.

The present invention can be understood as a file management method that executes one or more steps included in the file management process. One or more steps included in the file management process described here may be omitted as appropriate. The steps in the file management process may be executed in a different order as long as the same effects are achieved. While the example described here uses the control unit 11 of the management server 1 to execute each step in the file management process, in other embodiments, one or more processors may execute each step in the file management process in a distributed manner.

As shown in the example above, the management server 1 stores multiple shared files that can be accessed by multiple user terminals 2 via the network N1. The file management process is executed in parallel in response to access from each of the multiple user terminals 2.

First, in step S1, the control unit 11 determines whether or not a selection operation for a shared file has been received from the user terminal 2. If the control unit 11 receives a selection operation for a shared file from the user terminal 2 (S1: Yes), the control unit 11 proceeds to step S2. The control unit 11 waits until a selection operation for a shared file is received from the user terminal 2 (S1: No). Here, user A selects "file c4" on the file list page displayed on user terminal 2A, and the control unit 11 receives the selection operation for "file c4" from user terminal 2A (see Figure 2).

Next, in step S2, the control unit 11 determines whether or not an edit download operation for the shared file has been received from the user terminal 2. If the control unit 11 receives an edit download operation for the shared file from the user terminal 2 (S2: Yes), the control unit 11 transitions to step S3. The control unit 11 waits until an edit download operation for the shared file is received from the user terminal 2 (S2: No). Here, when user A selects "file c4" on the file list page displayed on user terminal 2A and selects the edit download button B1, the control unit 11 receives an edit download operation for "file c4" from user terminal 2A (see Figure 2).

Next, in step S3, the control unit 11 calculates a candidate lock time for locking the shared file. Specifically, the control unit 11 calculates the candidate time based on operation history information regarding past editing operations on the shared file. For example, the control unit 11 collects history information on the total time required to download, edit, and re-upload "file c4" in the past, and calculates the average of that total time as the candidate time.

Next, in step S4, the control unit 11 notifies the user terminal 2 of the calculated candidate time. Here, the control unit 11 notifies the user terminal 2A of the candidate time ("10 minutes"). The control unit 11 causes the user terminal 2 to display a screen F1 that accepts edit download operations, and displays the candidate time on the screen F1 (see Figure 3).

Next, in step S5, the control unit 11 determines whether a lock start operation to put the shared file into a locked state has been received. For example, when user A presses the "Start" button on screen F1 on the file list page displayed on user terminal 2A, the control unit 11 receives the lock start operation from user terminal 2A (see FIG. 3). Furthermore, for example, when user A performs an operation on screen F1 to change the lock time from the candidate time ("10 minutes"), the control unit 11 receives a lock start operation from user terminal 2A, including an operation to change the lock time (see FIG. 3). If the control unit 11 receives a lock start operation from user terminal 2A (S5: Yes), the control unit 11 transitions the process to step S6. On the other hand, if the control unit 11 does not receive a lock start operation from user terminal 2 (S5: No), the control unit 11 transitions the process to step S51.

In step S51, the control unit 11 determines whether a cancel operation related to the edit download has been received from the user terminal 2. For example, when the "Cancel" button on screen F1 (see Figure 3) is pressed, the control unit 11 receives a cancel operation from the user terminal 2A. If the control unit 11 receives a cancel operation from the user terminal 2 (S51: Yes), the control unit 11 transitions the processing to step S1. On the other hand, if the control unit 11 does not receive a cancel operation from the user terminal 2 (S51: No), the control unit 11 transitions the processing to step S5.

In step S6, the control unit 11 sets a lock time for locking the shared file and registers the lock time and the user who will edit the shared file. For example, the control unit 11 sets the lock time for "file c4" to "10 minutes" and registers the lock time and the identification information of user A who will edit "file c4" in the memory unit 12.

Next, in step S7, the control unit 11 sets the shared file to a locked state. For example, the control unit 11 grants editing authority for "file c4" only to user terminal 2A and prohibits editing operations by other user terminals 2.

Next, in step S8, the control unit 11 executes the download process for the shared file. For example, the control unit 11 downloads "file c4" to the user terminal 2A.

Next, in step S9, the control unit 11 determines whether the lock time has been reached. For example, the control unit 11 determines whether the lock time of 10 minutes has elapsed since the download process of "file c4" was started on the user terminal 2A. If the lock time has not been reached (S9: No), the control unit 11 transitions the process to step S10. On the other hand, if the lock time has been reached (S9: Yes), the control unit 11 transitions the process to step S12.

In step S10, the control unit 11 determines whether an upload operation for a shared file has been accepted. For example, if user A edits and uploads "file c4" downloaded to user terminal 2A, the control unit 11 accepts the upload operation. If the control unit 11 accepts an upload operation from user terminal 2A (S10: Yes), the control unit 11 proceeds to step S11. On the other hand, if the control unit 11 does not accept an upload operation from user terminal 2A (S10: No), the control unit 11 proceeds to step S101.

In step S101, the control unit 11 determines whether a selection operation on a shared file that has been set to a locked state has been received from a user terminal 2 other than the user terminal 2 to which editing authority has been granted. For example, when user B selects "file c4" that has been set to a locked state on user terminal 2B (see FIG. 5), the control unit 11 determines that the selection operation has been received. If the control unit 11 receives the selection operation (S101: Yes), it transitions the process to step S102. On the other hand, if the control unit 11 does not receive the selection operation (S101: No), it transitions the process to step S9.

In step S102, the control unit 11 displays lock information indicating that the shared file has been set to a locked state, in association with the shared file. For example, as shown in FIG. 5, the control unit 11 displays a warning image M1 indicating that "file c4" has been set to a locked state, in association with the information about "file c4," on the user terminal 2B.

Furthermore, when user B places the mouse image Ms over the warning image M1 on user terminal 2B (performs a mouse-over operation) (see Figure 6), the control unit 11 displays, on the file list page, the identification information (user ID, name, etc.) of user A who is editing "file c4" and information about the remaining time of the lock time ("10 minutes remaining"), as shown on the lock information screen F3 in Figure 7. After step S102, the control unit 11 transitions the process to step S9.

If the lock time is reached in step S9 (S9: Yes), or if the shared file upload process is executed in step S11, the control unit 11 releases the lock state of the shared file in step S12. For example, if the lock time (10 minutes) elapses without user A uploading "file c4" downloaded to user terminal 2A (S9: Yes), the control unit 11 releases the lock state of "file c4." Furthermore, if user A edits and uploads "file c4" downloaded to user terminal 2A (S11), the control unit 11 overwrites and saves the edited "file c4" uploaded from user terminal 2, and releases the lock state of "file c4."

Once the locked state of "file c4" is released, each user terminal 2 will be able to edit and download "file c4." After step S12, the control unit 11 returns to step S1 and repeats the above-described process.

In this manner, the control unit 11 executes the file management process for each user terminal 2.

As described above, the file management system 10 according to this embodiment accepts an edit request from user terminal 2A (first client) for a shared file that is accessible to each of multiple user terminals 2 (clients) via network N1, and sets the shared file to a locked state in which only user terminal 2A can edit the shared file. The file management system 10 also notifies user terminal 2A of a candidate lock time, which is the duration of the locked state, based on operation history information regarding past editing operations on the shared file, and sets the lock time in accordance with the operation of user terminal 2A for the candidate time. The file management system 10 also releases the locked state of the shared file when the lock time has elapsed since the shared file was set to the locked state.

In this way, when a shared file is being edited by a specific client, a lock time is set for that shared file based on the operation history information. As a result, the shared file remains locked for the time required for past operations (e.g., the average operation time), and the lock state is released once that time has elapsed, so other users do not have to wait a long time to edit the shared file.

Furthermore, when another user selects a shared file that is locked, the file management system 10 displays information indicating that the shared file is locked, information about the remaining time the file will remain locked, and the identification information of the user currently editing the file. This allows other users to easily understand the locked status of the shared file.

Therefore, the file management system 10 prevents a specific user from monopolizing editing of a shared file, allowing multiple users to edit the shared file appropriately.

The present invention is not limited to the above-described embodiments. The present invention may also be embodied in the following ways:

In another embodiment of the present invention, the setting processing unit 113 may notify the user terminal 2 of an inquiry as to whether or not to extend the lock time when the remaining time of the lock time reaches a predetermined time. For example, if user terminal 2A has been granted editing authority for "file c4," and the remaining time of the lock time ("10 minutes") reaches a predetermined time ("1 minute"), the setting processing unit 113 causes user terminal 2A to display an inquiry screen F4 as to whether or not to extend the lock time, as shown in FIG. 9.

Furthermore, when the setting processing unit 113 receives a request from user terminal 2A to extend the lock time, it extends the lock time by a predetermined time. For example, when user A selects "Extend" on inquiry screen F4 (see FIG. 9), the setting processing unit 113 extends the locked state of "file c4" by a predetermined time (e.g., "5 minutes") from the time the selection operation is received. The setting processing unit 113 may also receive an input operation for the extension time from user A on inquiry screen F4, and extend the locked state by the received time. In this case, an upper limit on the time that the user can input (e.g., "10 minutes") may be set.

Furthermore, if another user selects a shared file after the lock status of the shared file has been extended, the display processing unit 116 displays the remaining time after the extension on the lock information screen F3, as shown in FIG. 10. This allows the user to know that the lock status has been extended, the time remaining until the lock status is released, etc.

In another embodiment of the present invention, the control unit 11 may be capable of accepting an operation on the lock information screen F3 (see Figures 7 and 10) to request notification when the locked state of a shared file has been released. For example, as shown in Figure 11, the display processing unit 116 displays a "Notify Unlock" button on the lock information screen F3. When the "Notify Unlock" button is selected on user terminal 2B, for example, the control unit 11 notifies user terminal 2B, at the time the locked state of "file c4" is released, of a message indicating that the locked state of "file c4" has been released or that "file c4" can be edited and downloaded. This allows user B of user terminal 2B to know that "file c4" can now be edited.

In another embodiment of the present invention, the control unit 11 may be capable of accepting an operation to select either an edit download (an example of an edit request) or a view download of a shared file. For example, when the control unit 11 accepts an edit download request for "file c4" from user terminal 2A, it sets "file c4" to a locked state. In this case, the control unit 11 may also be capable of accepting a view download request for "file c4" from user terminal 2B. In this case, the control unit 11 grants user terminal 2B only the right to view "file c4," but not the right to edit it. This allows user B to view "file c4." Furthermore, when "file c4" is displayed on user terminal 2B, if the locked state of "file c4" is released, the control unit 11 may notify user terminal 2B that "file c4" can now be edited.

1: Management server 2: User terminal 10: File management system 111: Reception processing unit 112: Lock processing unit 113: Setting processing unit 114: File processing unit 115: Release processing unit 116: Display processing unit

Claims (10)

a reception processing unit that receives an edit request from a first client for a shared file that can be accessed by each of a plurality of clients via a network;
a lock processing unit that sets the shared file to a locked state in which only the first client can edit the shared file;
a setting processing unit that notifies the first client of a candidate time for a lock time, which is a period of the locked state, based on operation history information regarding past editing operations on the shared file, and sets the lock time in accordance with an operation on the first client for the candidate time;
A file management system comprising: a release processing unit that releases the locked state of the shared file when the lock time has elapsed since the shared file was set in the locked state;
The file management system according to claim 1 . when the setting processing unit acquires a change time for the candidate time from the first client, the change time is set to the lock time.
3. The file management system according to claim 1. a display processing unit that displays file information about the shared file on a shared page accessible from each of the plurality of clients via the network;
when the reception processing unit receives an access request to the shared file from a second client while the shared file is set to the locked state, the display processing unit displays, on the shared page, lock information indicating that the shared file is set to the locked state in association with the shared file.
The file management system according to any one of claims 1 to 3. The lock information further includes identification information of a user currently editing the shared file and lock time information regarding the lock time.
The file management system according to claim 4 . The lock time information is information about the elapsed time since the lock state was set or the remaining time of the lock time.
The file management system according to claim 5 . the setting processing unit notifies the first client of an inquiry as to whether or not to extend the lock time when the remaining time of the lock time reaches a predetermined time, and extends the lock time by the predetermined time when a request to extend the lock time is received from the first client;
The file management system according to any one of claims 1 to 6. the release processing unit releases the locked state when the first client finishes editing the shared file before the lock time is reached.
The file management system according to claim 2 . one or more processors,
a receiving step of receiving an edit request from a first client for a shared file that can be accessed by each of the plurality of clients via a network;
lockstep, which sets the shared file in a locked state so that only the first client can edit the shared file;
a setting step of notifying the first client of a candidate time for a lock time, which is a period of the locked state, based on operation history information regarding past editing operations on the shared file, and setting the lock time in accordance with an operation on the first client for the candidate time;
A file management method that performs a receiving step of receiving an edit request from a first client for a shared file that can be accessed by each of the plurality of clients via a network;
lockstep, which sets the shared file in a locked state so that only the first client can edit the shared file;
a setting step of notifying the first client of a candidate time for a lock time, which is a period of the locked state, based on operation history information regarding past editing operations on the shared file, and setting the lock time in accordance with an operation on the first client for the candidate time;
A file management program for executing on one or more processors.