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

Abstract

<P>PROBLEM TO BE SOLVED: To provide a file management system allowing efficient retrieval of a useful file. <P>SOLUTION: This file management system has a file server storing a file and providing the file via a network according to requirement from a client. The file server has an interface connected to a network, a processor executing a program, a memory storing a program and information for using the program, and a storage device storing the file. The memory stores organization information wherein a department constituting an organization is recorded. The processor records an access history of the file, totals the access history in each department stored in the organization information, decides that usability of the file is high about the department having a large number of accesses, and retrieves the file decided that its usability is high. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a file sharing system, and more particularly to a technique for managing files stored in a file server.

  In recent years, many organizations have introduced file sharing systems to improve business efficiency. In the file sharing system, when a file owner registers a file that can be used between members in a file server, other members can also use the registered file.

  For example, if a member creates a material that effectively introduces the features and merits of the new product to the customer, other members can also use the created product introduction material. In the file sharing system, when a document creator registers a product introduction document for a new product in the file server, other members can easily obtain this product introduction document when introducing a new product to a customer. This saves you the trouble of creating materials.

  The convenience of such a file sharing system is improved by techniques disclosed in several patent documents. For example, Patent Document 1 discloses a technique for promoting registration of a useful file in a file server. Specifically, points that affect personnel evaluation are given to members who have registered files in the file server.

  Japanese Patent Application Laid-Open No. 2004-228561 discloses a technique for more members to use a file registered in a file server. More specifically, a keyword is extracted from a registered file, and if the keyword matches a keyword associated with a group such as a department, the member of the department with the matched keyword is notified that the file has been registered.

Furthermore, Patent Document 3 discloses a technique for rearranging search results of shared files. Specifically, necessary file acquisition is facilitated by rearranging file search results based on keywords used in the past within the member's department.
JP 2001-222597 A JP 2005-92340 A JP 2004-348626 A

  However, even if the above-described conventional technology improves the convenience of the file sharing system, the shared file may not be used effectively.

  In the technique disclosed in Patent Document 2, if a file of another department matches a keyword assigned to the department to which the department belongs, the member registered to the server is notified that the file is registered in the server. However, in order to eliminate unnecessary notifications and efficiently obtain useful file registration notifications, keywords must be frequently maintained. Even if useful files are stored in the server of the own department, if the server contains a lot of unnecessary files, the processing speed and accuracy of the search are reduced.

  With the technique disclosed in Patent Literature 3, even if a useful file can be found from the search result, the search processing speed and accuracy itself cannot be improved.

  In a typical embodiment of the present invention, a file management system includes a file server that stores a file and provides the file through a network in response to a request from a client, and the file server is connected to the network. A first interface connected to the first interface and executing a program; a first memory storing the program and information used by the program; a first storage device storing the file; And the first memory stores organization information in which departments constituting the organization are recorded, and the first processor records the access history of the file, and the access history for each department stored in the organization information. And the usefulness of the file for departments with a high number of accesses The Most determined, characterized by searching the determined file to be high the utility.

  According to one aspect of the present invention, by managing a file determined to be highly useful in association with a department, it is possible to improve search accuracy and speed up search.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

(First embodiment)
In the first embodiment, an access history for a file stored in a file server is recorded, the access history is periodically analyzed to determine a department where the file is highly useful, and the file metadata is stored in the department. Manage in association with.

(Overall system configuration)
FIG. 1 is a configuration diagram of the entire file sharing system according to the first embodiment. The file sharing system according to the first embodiment includes a file server 1, a metadata server 2, and a client 3. The file server 1, metadata server 2, and client 3 are connected by a network 4. The network 4 is configured by, for example, an IP network.

The file server 1 is a computer that stores and manages files shared among members. For example, the file server 1 may be a CIFS (COMMON INTERNET FILE SYSTEM, a protocol used in the WINDOWS (registered trademark) file sharing service of MICROSOFT) or Samba (WINDOWS (registered trademark)).
A file sharing function is provided to the client 3 by installing a UNIX (registered trademark) OS free software that provides a file sharing service to a machine.

  The metadata server 2 is a computer that stores and manages the metadata of files stored in the file server 1. The metadata server 2 is implemented with a relational database (hereinafter “RDB”), and stores and manages metadata. Note that the metadata is data describing information about the file, such as bibliographic / system information such as the file path, creator and creation date, and character strings and keywords included in the file.

  The client 3 is a computer used by members of the organization. The client 3 registers a file with the file server 1 or accesses a file stored in the file server 1.

  In FIG. 1, each of the file server 1 and the metadata server 2 corresponds to one computer, but it is not necessary to limit to this. The file server 1 and the metadata server 2 may be mounted on the same computer, or the file server 1 or the metadata server 2 may be configured by a plurality of computers.

(Hardware configuration)
FIG. 2 is a hardware configuration diagram of the file server 1 according to the first embodiment. Note that the hardware of the file server 1, the metadata server 2, and the client 3 are all the same.

  The file server 1 includes a CPU 10, a network interface 15, a hard disk 20, a memory 30, a display 40, a display control unit 41, a keyboard 50, a keyboard control unit 51, a mouse 60, a mouse control unit 61, and a bus 70.

  The CPU 10 executes data input / output and various processes by executing a program stored in the memory 30. The network interface 15 communicates with other computers via a network. The hard disk 20 stores programs and data. The memory 30 stores programs and data executed by the CPU 10.

  The display 40 displays data to the user and is controlled by the display control unit 41. The keyboard 50 receives input from the user and is controlled by the keyboard control unit 51. The mouse 60 receives input from the user and is controlled by the mouse control unit 61. The bus 70 passes data to each component.

(Module configuration of file server 1)
FIG. 3 is a module configuration diagram of the file server 1 according to the first embodiment. The file server 1 includes a processing unit that executes various processes, a data storage unit that stores data, and a temporary data unit that stores temporarily generated data. The processing unit is rectangular, the data storage unit is drum-shaped, and the temporary data unit is tape-shaped.

(Module configuration of file server 1: processing unit)
The processing unit of the file server 1 includes a file registration unit 11A, a file management unit 11B, and a file search unit 11C.

  The file registration unit 11A stores the registration file 13A transmitted from the client 3 in the file storage unit 12A. Further, when storing the registration file 13A, the file registration unit 11A generates metadata based on the registration file 13A. Then, the file registration unit 11A creates a metadata arrangement command 13B and transmits it to the metadata server 2.

  The file management unit 11B determines the usefulness of the file stored in the file server 1, and rearranges the metadata. The configuration of the file management unit 11B will be described in detail later with reference to FIG.

  The file search unit 11C receives the search condition 13C input by the client 3, generates a search command 13D, and transmits it to the metadata server 2. Then, the file search unit 11C receives the search result 13E from the metadata server 2, generates a display search result 13F, and transmits it to the client 3. Furthermore, when the file name 13G is selected by the client 3, the file search unit 11C extracts the corresponding file 13H from the file storage unit 12A and transmits it to the client 3.

(Detailed module configuration of the file management unit 11B)
FIG. 4 is a detailed module configuration diagram of the file management unit 11B according to the first embodiment. The file management unit 11B includes four types of modules: a processing unit (rectangular), a data storage unit (drum type), a temporary data unit (tape type), and a table (parallelogram). The access log storage unit 12B, the access history storage unit 12C, the organization information storage unit 12D, and the metadata arrangement command 13B shown in FIG. 4 are the same as the modules constituting the file server 1 shown in FIG. To do.

(Detailed module configuration of the file management unit 11B: processing unit)
The processing unit of the file management unit 11B includes an access history extraction unit 11B1, a file usability determination unit 11B2, and a metadata arrangement unit 11B3.

  The access history extraction unit 11B1 acquires the access log stored in the file server 1 from the access log storage unit 12B. The access log is a history of registering a file in the file server 1 or referring to a file stored in the file server 1.

  In addition, the access history extraction unit 11B1 extracts an access history from the access log and stores it in the access history storage unit 12C. The access history is obtained by extracting only the record that refers to the file from the information recorded in the access log.

  The file usability determination unit 11B2 analyzes the access history stored in the access history storage unit 12C and determines the usefulness of the file. The process for determining the usefulness of the file will be described later with reference to FIG.

  The metadata arrangement unit 11B3 associates the file determined to be useful with the department. Specifically, a metadata arrangement command 13B for associating the metadata of this file with a department is created and transmitted to the metadata server 2. The processing for rearranging metadata will be described later with reference to FIG.

(Detailed module configuration of the file management unit 11B: table)
FIG. 5 is a diagram illustrating a configuration of the access history table 11B4 according to the first embodiment. The access history table 11B4 includes an entry 11B401 and a affiliation 11B402.

  The entry 11B401 stores the name of the member who referred to a certain file or the department name to which the member belongs. The affiliation 11B402 stores the department name to which the member or department stored in the entry 11B401 belongs.

  FIG. 5 shows that the member's name “Ichiro Suzuki” is stored as an entry in the fifth row, and the affiliation is “Sales Section 1”.

(Module configuration of file server 1: data storage unit)
The data storage unit of the file server 1 includes a file storage unit 12A, an access log storage unit 12B, an access history storage unit 12C, and an organization information storage unit 12D.

  The file storage unit 12A stores a shared file. The access log storage unit 12B stores an access log for the file server 1. For example, a CIFS protocol providing a file sharing function or a log output by Samba is used. As described above, the access history storage unit 12C stores the access history extracted from the access log stored in the access log storage unit 12B. The organization information storage unit 12D stores organization configuration information including departments and organization members.

  Hereinafter, the configuration of each data storage unit will be described.

(Configuration of file storage unit 12A)
FIG. 6 is a configuration diagram of the file storage unit 12A according to the first embodiment. The file storage unit 12A includes a file name 12A01, file data 12A02, metadata table name 12A03, and metadata arrangement date 12A04.

  The file name 12A01 stores a file name including the path of the shared file stored in the file server 1. The file data 12A02 stores the contents of the file including the character string and format information of the file. The file data 12A02 may be a file itself or a link indicating a storage location of the file.

  The metadata table name 12A03 stores the name of the metadata table 22A00 included in the metadata storage unit 22A described later. The metadata arrangement date 12A04 stores the date when the metadata is arranged in the metadata table 22A00.

  As shown in FIG. 6, in the first line, the file name “¥¥ fs ¥ file1.doc” is proposed to company A under the head of the section manager on the date “○ month × day”. Is stored. Furthermore, the metadata of this file is stored in the table “eigyo1”, and it is recorded that it was placed on December 3, 2005.

  In FIG. 6, only text data is shown as the file data 12A02, but it may be an image file or a moving image file. Further, FIG. 6 shows the file storage unit 12A in a table format, but the file may hold these pieces of information as attributes.

(Configuration of access log storage unit 12B)
FIG. 7 is a configuration diagram of the access log storage unit 12B according to the first embodiment. The access log storage unit 12B includes an access date 12B01, an accessor 12B02, a file name 12B03, and an access type 12B04.

  The access date 12B01 stores the date when the file stored in the file server 1 is accessed. Although only the date is displayed in FIG. 7, detailed access time may be recorded. The accessor 12B02 stores the user ID of the member who has accessed the file. The file name 12B03 stores the file name of the accessed file. The access type 12B04 stores the type of access such as file registration, reference, or deletion.

  As shown in FIG. 7, the first line records that the member whose user ID is “katoh” registered the file “¥¥ fs ¥ file1.doc” on October 24, 2005. Yes.

(Configuration of access history storage unit 12C)
FIG. 8 is a configuration diagram of the access history storage unit 12C according to the first embodiment. The access history storage unit 12C includes an access date 12C01, an accessor 12C02, and a file name 12C03.

  The access date 12C01 stores the access date of the file. In FIG. 8, only the date is recorded, but a detailed access time may be recorded. The accessor 12C02 stores the user ID of the member who accessed the file. The accessed file name is stored in the file name 12C03.

  As shown in FIG. 8, in the first line, a history of a member having a user ID “yamada” accessing the file “¥¥ fs ¥ file1.doc” on October 24, 2005 is recorded. .

(Configuration of organization information storage unit 12D)
FIG. 9 is a configuration diagram of the organization information storage unit 12D according to the first embodiment. The organization information storage unit 12D includes an entry 12D01, a user ID 12D02, an affiliation 12D03, and a metadata table name 12D04.

  The entry 12D01 stores a department name or a member name belonging to a department constituting the organization. The user ID 12D02 stores the user ID of the entry in the file sharing system. The department 12D03 stores the department name to which the entry belongs. The metadata table name 12D04 stores the metadata table name corresponding to the entry in the metadata storage unit 22A described later.

  As shown in FIG. 9, the first line records that the entry “General Affairs Section” belongs to “General Affairs Department” and the name of the corresponding metadata table is “syomu”. In the fifth line, the user ID of the entry “Ichiro Suzuki” is “suzuki” and is recorded as belonging to “Sales Division 1”.

  In FIG. 9, when the entry is a department, no user ID is assigned. However, a user ID can be assigned to the department and the file can be registered and accessed in the file server 1 with the authority as the department. Further, when the entry is a member (person), the metadata table name is not associated, but the member may be associated as the smallest unit constituting the organization. At this time, metadata of a file used only by a certain member is managed in correspondence with the member.

  Further, the organization information storage unit 12D may divert data of the IT system introduced / used in the organization. Specifically, LDAP in a security system, an electronic phone book in a mail system, user information in a document management system, and the like may be used as organization information.

(Module configuration of file server 1: temporary data section)
The temporary data part includes a registration file 13A, a metadata arrangement command 13B, a search condition 13C, a search command 13D, a search result 13E, a display search result 13F, a file name 13G, and a file 13H.

  The registration file 13A is a file registered from the client 3 to the file server 1. The metadata arrangement command 13B is a command for arranging metadata in the metadata server 2. The search condition 13 </ b> C is a search condition for a file input by a member from the client 3. The search command 13D is a command for searching for metadata. The search result 13E is a result of executing the search command 13D. The display search result 13F is data processed to display the search result 13E. The file name 13G is the file name of the file selected by the member. The file 13H is a file itself corresponding to the file name 13G.

(Example of registration file 13A)
FIG. 10 is a diagram illustrating an example of the registration file 13A according to the first embodiment. The registration file 13A stores file data 13A01. As shown in FIG. 10, the content of the file data 13A01 is “business daily report ○ month × day, suggestion of office system to company A…”.

(An example of the metadata arrangement command 13B)
FIGS. 11 and 12 are diagrams illustrating an example of the metadata arrangement command 13B transmitted from the file server 1 to the metadata server 2 according to the first embodiment. In the first embodiment, since the RDB is mounted on the metadata server 2 as described above, the metadata placement command 13B is an SQL command for the RDB.

  The SQL command 13B01 is an example of a command for registering metadata in the RDB of the metadata server 2. The SQL command 13B01 inserts a record with the file name “¥¥ fs ¥ file1.doc” and the metadata “Company A”, “Proposal”, and “Office system” into the metadata table “eigyo1”.

  The SQL command 13B02 is an example of an SQL command for rearranging metadata registered in the metadata server 2. The SQL command 13B02 moves the metadata of the file name “¥¥ fs ¥ file1.doc” from the metadata table name “eigyo1” to “eigyo”.

(Example of search condition 13C)
FIG. 13 is a diagram illustrating an example of the file search condition 13C according to the first embodiment. The search condition 13C includes a user ID 13C01, a client 13C02, a department 13C03, and a keyword 13C04.

  The user ID 13C01 stores the user ID of the user who has input the search condition. The client 13C02 stores the identification name of the client 3 used by the user who has input the search condition. The department 13C03 stores a department designated as a search condition by the user. The keyword 13C04 stores a keyword input by the user as a search condition.

  FIG. 13 shows that a member whose user ID is “satoh” includes “company A, proposal” as a keyword among files determined to be highly useful in “sales department 1” in the client “satoh-pc”. Indicates the conditions for searching for files.

(Example of search command 13D)
FIG. 14 is a diagram illustrating an example of a search command 13D that the file search unit 12C according to the first embodiment transmits to the metadata server 2. As described above, since the metadata is stored in the RDB, the search command 13D is the SQL command 13D01.

  The SQL command 13D01 acquires the file name of a record including “Company A” and “Suggestion” in the metadata from the metadata table “eigyo1”.

(Example of search result 13E)
FIG. 15 is a diagram illustrating an example of a search result 13E received from the metadata server 2 by the file search unit 12C according to the first embodiment.

  The search result 13E is an execution result 13E01 of the search command 13D. As shown in FIG. 15, the file name “¥¥ fs ¥ file1.doc” is stored in the first line as the execution result 13E01 of the search command 13D shown in FIG.

(Example of display search result 13F)
FIG. 16 is a diagram illustrating an example of the display search result 13 </ b> F transmitted to the client 3 by the file search unit 12 </ b> C according to the first embodiment.

  The display search result 13F includes the file name acquired from the search result 13E and part or all of the contents of the file. As shown in FIG. 16, the file name “file1.doc” is displayed as the display content 13F01 on the first line of the display search result 13F, and the file content “○ month × day, accompanying the section manager” is displayed on the second line. ”Is stored in Company A.

(Example of file name 13G)
FIG. 17 is a diagram illustrating an example of the file name 13G selected by the user according to the first embodiment. As shown in FIG. 17, “file1.doc” is stored as the file name 13G01 selected by the user.

(Example of file 13H)
FIG. 18 is a diagram illustrating an example of a file 13H having a file name designated by a member according to the first embodiment. The file 13H stores file data 13H01. As shown in FIG. 18, the file data 13H01 stores "○ month x day, proposal to company A under the accompanying department manager ...".

(Module configuration of the metadata server 2)
FIG. 19 is a module configuration diagram of the metadata server 2 according to the first embodiment. Similar to the file server 1 shown in FIG. 3, the metadata server 2 includes a processing unit, a data storage unit, and a temporary data unit.

(Module configuration of the metadata server 2: processing unit)
The processing unit of the metadata server 2 includes a metadata registration unit 21A, a metadata management unit 21B, and a metadata search unit 21C.

  The metadata registration unit 21A receives the metadata arrangement command 13B transmitted from the file server 1, and stores the metadata in the metadata storage unit 22A. The metadata management unit 21B receives the metadata arrangement command 13B from the file server 1, and rearranges the metadata stored in the metadata storage unit 22A. The metadata search unit 21C receives the search command 13D from the file server 1, executes the search command 13D with respect to the metadata storage unit 22, and transmits the search result 13E to the file server 1.

(Module configuration of the metadata server 2: data storage unit)
FIG. 20 is a configuration diagram of the metadata storage unit 22A according to the first embodiment. As described above, the RDB is implemented in the metadata server 2, and the metadata storage unit 22A stores the table 22A00 corresponding to each department of the organization.

  The table 22A00 includes a file name 22A01 and metadata 22A02. The file name 22A01 stores the file name of the file stored in the file server 1. The metadata 22A02 stores metadata of the file.

  As shown in FIG. 20, a file name “¥¥ fs ¥ file1.doc” and corresponding metadata “business daily report, company A, proposal...

  The metadata 22A02 shows keywords extracted from the file as an example, but may include bibliographic data or annotations that can be acquired as file attributes, such as the creator name or creation date of the file.

(Module configuration of metadata server 2: temporary data storage unit)
The temporary data storage unit of the metadata server 2 includes a metadata arrangement command 13B, a search command 13D, and a search result 13E. Since the metadata arrangement command 13B, the search command 13D, and the search result 13E are common to the temporary data storage unit of the file server 1, description thereof is omitted.

  The configuration of the file sharing system according to the first embodiment has been described above.

(Processing procedure of the file sharing system)
Next, processing executed in the file sharing system according to the first embodiment will be described. In the first embodiment, paying attention to the fact that the usefulness of a file differs depending on the department, it is determined that the usefulness is high in a department with many users based on the access history of the file. Therefore, the file metadata is arranged corresponding to the department where the file is determined to be useful. Furthermore, considering the fact that the usefulness of the file may change over time, the usefulness of the file is periodically determined, and the metadata is rearranged.

  FIG. 21 is a flowchart illustrating a process executed resident in the file sharing system according to the first embodiment. Note that the numbers in parentheses at the end of the description are process numbers in each flowchart.

  The file server 1 determines whether or not the current time matches a predetermined execution time of the metadata rearrangement process (S101). When the execution time of the metadata rearrangement process is reached (result of S101 is “Y”), the file server 1 executes the metadata rearrangement process (S102). Details of the metadata rearrangement process will be described later with reference to FIG.

  If the current time is not the time for rearranging the metadata (the result of S101 is “N”), the file server 1 determines whether there is an input from the client 3 (S103).

  When an instruction is input from the client 3 (result of S103 is “Y”), the file server 1 determines whether the input instruction is a registration instruction (S104). On the other hand, if there is no input from the client 3, the process returns to S101.

  When the input from the client 3 is a registration instruction (the result of S104 is “Y”), the file server 1 executes a file registration process (S105). The file registration process is executed by the file registration unit 11A.

  The file registration unit 11A receives the registration file 13A transmitted from the client 3 and stores it in the file storage unit 12A.

  The file registration unit 11A stores the registration file 13A and extracts keywords from the registration file 13A. The extraction of keywords can be performed by using Non-Patent Document 1 (Mitsuo Shibata et al., “Keyword Extraction by Character Type Extraction and Compound Word Decomposition”, Information Processing Society of Japan, Natural Language Processing Study Group Report, 120-13, 1997) or Non-Patent Document 2 (Original This can be realized by applying the prior art described in Masaaki et al., “Keyword extraction using text format and importance within word range”, Information Processing Society of Japan, Journal, VOL.38, No.2, 1997). Alternatively, a person who registers a file may manually enter a keyword.

  Also, the file registration unit 11A refers to the organization information storage unit 12D, acquires the affiliation of the member who transmitted the registration file 13A, and further acquires the metadata table name 12D04 from the acquired affiliation. Then, the file registration unit 11A inserts the extracted keyword into the metadata table as metadata. Specifically, a metadata arrangement command 13B is created and transmitted to the metadata server 2.

  When the metadata registration unit 21A of the metadata server 2 receives the metadata arrangement command 13B, the metadata registration unit 21A executes the command to the metadata storage unit 22A and stores the metadata.

  Thereafter, the file registration unit 11A records the metadata table name storing the metadata in the metadata table name 12A03 of the file storage unit 12A. Further, the file registration unit 11A records the registration date in the metadata arrangement date 12A04 of the file storage unit 12A, and returns to the process of S101 (S105).

  The file server 1 determines whether the input from the client 3 is a search instruction (S106). If it is not a search instruction, the process returns to S101 (the result of S106 is “N”).

  If the input from the client 3 is a search instruction (the result of S106 is “Y”), the file server 1 executes a file search (S107). The file search is executed by the file search unit 11C.

  The file search unit 11C receives the search condition 13C transmitted from the client. The file search unit 11C generates a search command 13D and transmits it to the metadata server 2. Upon receiving the search command 13D, the metadata search unit 21C of the metadata server 2 executes the search command 13D on the metadata storage unit 22A. The metadata search unit 21C transmits the search result 13E to the file search unit 11C of the file server 1.

  The file search unit 11C creates a display search result 13F based on the search result 13E. The display search result 13F includes a file name and part or all of the contents of the file. The file search unit 11C transmits the created display search result 13F to the client 3.

  The client 3 displays the received display search result 13F on the screen. When the file name on which the member is displayed is selected, the client 3 transmits the selected file name 13G to the file server 1. The file server 1 receives the file name 13G, acquires the corresponding file 13H from the file storage unit 11A, and transmits it to the client 3. The client 3 displays the file 13H transmitted from the file server 1 on the screen (S107).

(Detailed processing procedure for metadata relocation processing)
FIG. 22 is a flowchart illustrating a processing procedure of metadata rearrangement processing according to the first embodiment.

  First, the file management unit 11B clears the access history storage unit 12C, extracts an access log whose access type 12B04 is “reference” from the access log storage unit 12B, and stores it in the access history storage unit 12C (S201). Further, the file management unit 11B sorts the records in the access history storage unit 12C using the file name 12C03 as a key (S202). Therefore, records that record accesses to the same file are continuously stored in the access history storage unit 12C. Then, the access history storage unit 12C is sequentially processed from the top record to determine the usefulness of each file.

  The file management unit 11B sets 1 to the global variable i indicating the index of the record to be processed in the access history storage unit 12C (S203).

  The file management unit 11B sets the file name stored in the i-th record of the access history storage unit 12C in the global variable FN (S204). The variable FN stores the file name of the file whose usefulness is determined. The file management unit 11B refers to the file storage unit 12A, acquires the metadata table name corresponding to FN, and sets it in the global variable TN1 (S205).

  The file management unit 11B initializes the global variable TN2 (S206). TN2 is a variable that determines the usefulness of the file in the process of S207 and stores the table name of the metadata table corresponding to the department determined to be useful.

  Subsequently, the file management unit 11B reads the access history from the access history storage unit 12C while increasing the value of the index i, and determines the usefulness of the FN (S207). In the file usability determination process, the table name of the metadata table corresponding to the department determined to be useful at this time is stored in TN2.

  The file management unit 11B determines whether TN1 and TN2 are different (S208). When TN1 and TN2 are different (result of S208 is “Y”), the file management unit 11B rearranges the metadata because the department that has determined that FN is useful has changed (S209). In the rearrangement of metadata, the metadata whose file name corresponds to FN is moved from the table TN1 to TN2. Specifically, the file management unit 11B creates a metadata arrangement command 13B and transmits it to the metadata server 2 (S209).

  On the other hand, the file management unit 11B updates the record corresponding to the FN in the file storage unit 12A when TN1 and TN2 are equal (result of S208 is “N”) or when the metadata rearrangement is completed. (S210). Specifically, the metadata table name 12A03 and the metadata arrangement date 12A04 are updated. Even if the metadata is not rearranged, it is possible to determine that the file is useful at the time of the metadata arrangement date by updating the metadata arrangement date 12A04.

  The file management unit 11B compares the value of the index i with the number of records in the access history storage unit 12C (S211). When the index i is equal to or less than the number of access histories stored in the access history storage unit 12C (result of S211 is “N”), since the usefulness has not been determined for all files, the process proceeds to S204. Determine the usefulness of the remaining files. When the index i is larger than the access history number (the result of S211 is “Y”), since the determination of the usefulness of all accessed files is finished, the metadata rearrangement process S102 is finished.

(Usefulness of files in the organization)
Here, the usefulness of the file in the organization will be explained before the usefulness determination process of the file.

  As described above, the usefulness of a file is determined by the frequency of access to the file. Specifically, if the access frequency is high, it is determined that the usefulness of the file is high, and conversely, if the frequency is low, it is determined that the usefulness is low.

  Furthermore, considering that the file is useful to “who”, the management is performed so that members who are likely to be able to use the file are easily accessible to the file. Specifically, it is determined that the file is useful for a department including many members who have accessed a file, and the file and the department are associated and managed.

  In addition, the usefulness of files changes over time. Even if the access frequency is high and the file is useful, if the access frequency decreases, the usefulness also decreases. In addition, even if a file has a low access frequency at the stage of creating the file, its usefulness increases as the access frequency increases with time. Therefore, it is periodically checked whether or not the useful department has changed, and if it has changed, the department newly determined to be useful is associated with the file.

  FIG. 23 is a diagram for explaining the relationship between the file access frequency and the department where the file is useful. As an example, the organization is configured by “X section”, “Y section”, and “Z section”, and “X section” is further configured by “section X1”, “section X2”, and “section X3”.

  FIG. 23A shows a state in which a file registered in the file server is accessed by a member of “Section X1”. In this state, the file is considered to be useful in “Section X1”.

  Here, it is assumed that the state changes from the state (A) to the state (B), and the file is accessed from “Section X3”. At this time, as shown in (C), it is considered that the file has become useful in “Section X3” in addition to “Section X1”.

  However, in (C), a file that is useful only for “Section X3” and a file that is useful for “Section X1” and “Section X3” are handled in the same way. As a result, even if a file that is useful only in “Section X3”, for example, a file that is related only to the work of “Section X3”, a useful file that is common to “Section X1” and “Section X3” is used. Will be extracted together, causing problems such as poor search accuracy.

  Therefore, in the first embodiment, when the state of a certain file changes from (A) to (B), it is assumed that the level of the organization in which the file is useful has changed. Specifically, as shown in (D), “X department”, which is a common upper department of “section X1” and “section X3”, is determined to be a department in which the file is useful. By doing so, it is possible to clearly distinguish the file from the useful file only by “Section X3”. By specifying a department in which the file is useful, it is possible to easily obtain a file required by the user, such as a file directly connected to business or a file useful at a higher level in the organization.

  In addition, the fact that the access frequency has changed from the state of (A) to the state of (B) means that the department belonging to “Department X” will be a department other than “Department X1” and “Department X3”, that is, “Department X2”. May increase the access frequency. Therefore, as shown in (D), if it is determined that the “Department X”, which is a higher-level department, is useful, the file can be easily accessed from “Section X2”.

(Processing procedure of file usability judgment processing)
FIG. 24 is a flowchart illustrating a processing procedure of the file usability determination process S207 of the metadata rearrangement process S102 illustrated in FIG. The file usability determination process S207 is executed by the file management unit 11B.

  The file management unit 11B initializes the variable j indicating the index of the access history table 11B4 by setting 1 (S301).

  Subsequently, the file management unit 11B extracts the i-th access person 12C02 in the access history storage unit 12C, and acquires the entry 12D01 that matches the user ID 12D02 with reference to the organization information storage unit 12D. Then, the acquired entry 12D01 is stored in the entry 11B401 of the jth record in the access history table 11B4 (S302). Similarly, the affiliation of the i-th accessor in the access history storage unit is acquired and set in the affiliation 11B402 of the j-th record in the access history table 11B4 (S303).

  Next, the file management unit 11B adds 1 each to i and j (S304). Further, it is determined whether or not the i-th file name in the access history storage unit 12C matches FN (S305). If they match (result of S305 is “Y”), since the corresponding record is the access history for the FN, the file management unit 11B executes the process of S302 and adds the record to the access history table 11B4.

  Further, when the i-th file name in the access history storage unit 12C does not match FN (result of S305 is “N”), the file management unit 11B completes the addition of the record to the access history table 11B4, so S306 The subsequent processing is executed. As described above, the access history storage unit 12C is sorted by file name, and the access history is continuously stored for each file. Therefore, when the i-th file name in the access history 12C no longer matches the FN, a record corresponding to the access history of the FN is generated in the access history table 11B4. At this time, the index j stores a value of FN access count + 1.

  Then, the file management unit 11B tabulates the access history table 11B4 (S306). The tabulation of the access history table 11B4 is to calculate the ratio of the number of accesses of each affiliation to the total number of accesses to the FN.

  The file management unit 11B determines whether the affiliation ratio with the largest number of accesses exceeds a predetermined value α (for example, 80%) (S307). If the ratio of the affiliation with the largest number of accesses exceeds α (the result of S307 is “Y”), it is determined that the FN is highly useful for the affiliation. The metadata table name 12D04 corresponding to is acquired and stored in TN2 (S308).

  On the other hand, the file management unit 11B, when the ratio of the affiliation with the largest number of accesses does not exceed α (the result of S307 is “N”), there is no department determined that the usefulness of the FN is high. The data is counted again in the higher affiliation stored in the access history table 11B4. Hereinafter, the process of re-aggregating by the higher affiliation will be described.

  First, the file management unit 11B initializes the variable k indicating the index of the access history table 11B4 by setting 1 (S309).

  Next, the file management unit 11B copies the kth affiliation 11B402 of the access history table 11B4 to the entry 11B401 (S310). Here, the file management unit 11B refers to the organization information storage unit 12D and determines whether or not a higher order affiliation exists in the copied entry (S311). If there is a higher affiliation (the result of S311 is “Y”), the higher affiliation is set in the k-th affiliation 11B402 of the access history table 11B4 (S312).

  Thereafter, the file management unit 11B adds 1 to the value of k (S313), and determines whether the value of k is equal to or greater than the value of j (S314). In the process of S314, since the value of the number of accesses of the file FN + 1 is stored in the variable j, it can be determined whether or not all the affiliations stored in the access history table 11B4 have been updated to higher affiliations.

  When the value of k is smaller than the value of j (the result of S314 is “N”), the file management unit 11B executes the processing from S310 to S313 for the remaining records in the access history table 11B4. If the value of k is greater than or equal to the value of j (the result of S314 is “Y”), the update of all the records in the access history table 11B4 has been completed. The sex is determined (S307).

  In the processing of S308, the belonging metadata table name 12D04 having the largest number of accesses is stored in TN2, but the table name set in TN2 need not be limited to one. Considering the convenience of the user accessing the file, it is also possible to place metadata in a plurality of tables. Hereinafter, an example thereof will be described with reference to FIG.

  It is assumed that a certain file has been accessed by a member of section X1 (state (A)) and is also accessed by a member of section X3 (state (B)). At this time, in normal processing, the metadata of this file is moved from the metadata table corresponding to section X1 to the metadata table corresponding to the X section (state (D)).

  On the other hand, when the metadata is rearranged and there are still many accesses from the X1 section, the metadata stored in the table corresponding to the X1 section is left as it is, and at the same time in the metadata table corresponding to the X section. The same metadata may be stored. Specifically, in the processing of S308, the metadata table name 12D04 and TN1 corresponding to the affiliation with the largest number of accesses may be stored in TN2.

  The processing procedure of the file sharing system according to the first embodiment of this invention has been described above using flowcharts.

(Example of client screen for file search)
Here, a search instruction screen for executing the file search process S107 and a search result display screen will be described. The search instruction screen and the search result display screen are displayed on the client 3.

(Example of client screen for file search: search instruction screen)
FIG. 25 is a diagram illustrating an example of a search instruction screen displayed on the client 3 according to the first embodiment. The search instruction screen includes a search key input area 401, a search range designation area 402, a search instruction button 403, an end instruction button 404, and a search result display area 405.

  A search key input area 401 is an area for inputting a keyword for searching for a file. In FIG. 25, “Company A” and “Proposal” are entered as keywords in the search key input area 401.

  A search range designation area 402 is an item for designating a range of departments to search for files. In FIG. 25, “Sales Section 1” and “Sales Department” are designated as the departments to be searched.

  A search instruction button 403 instructs the user to execute a file search to the file sharing system. The end instruction button 404 instructs the system to end the file search. The search result display area 405 is an area for displaying a file search result.

(Example of client screen for file search: search result display screen)
FIG. 26 shows an example of a screen that displays the search results executed according to the search conditions shown in FIG. The screen configuration is the same as in FIG.

  The search condition input in FIG. 25 is transmitted to the file search unit 11C of the file server 1 through the network 4 as the search condition 13C when the search instruction button 403 is pressed. Upon receiving the search condition 13C, the file search unit 11C executes the file search process S107 as described above, and transmits the display search result 13F to the client 3. Upon receiving the display search result 13F, the client 3 displays the file name of the extracted file and a part of its content in the search result display area 405, as shown in FIG.

(Example of client screen for file search: department designation list display screen)
Alternatively, a file may be searched by specifying only a department without specifying a keyword. By searching for a file by specifying only the department, it is possible to obtain a list of files determined to be highly useful for each department.

  FIG. 27 is an example of a department designation list display screen. The department designation list display screen includes a department designation column 402, a list display button 406, an end instruction button 404, and a list display section 408. Note that elements assigned the same reference numerals as those in FIG. 25 have the same functions and will not be described. If the search is possible without inputting a keyword, the search instruction screen shown in FIG. 25 may be used.

  The list display button 406 transmits the designated department to the file server 1. When the file server 1 receives the department as the search condition 13C, the file server 1 generates a search command 13D, executes a search process, and transmits the display search result 13F to the client 3. At this time, the display search result 13F is transmitted to the client 3 as a list for each department.

  Upon receiving the display search result 13F, the client 3 displays a list of files determined to be highly useful for each department on the list display unit 408. In FIG. 27, the list display unit 408 is configured to be able to switch and display a list of files for each department.

(Effects of the first embodiment)
According to the first embodiment, it is possible to improve search accuracy and increase search speed by managing a file determined to be highly useful in association with a department.

  In the first embodiment, file metadata is used, and file metadata determined to be highly useful is managed in association with a department. Therefore, the search speed can be increased because metadata is searched for, not the file itself.

  Furthermore, according to the first embodiment, since the process of rearranging metadata is periodically executed according to the usefulness of the file, there is no need for the administrator and the user to rearrange the metadata. , Maintenance can be improved.

(Modification of the first embodiment)
In the first embodiment, the file sharing function is implemented using the CIFS protocol or Samba. However, the file sharing function of the document management system may be used. That is, the document management server in the document management system is the file server 1, the document storage unit is the file storage unit 12 A, the system log is the access log storage unit 12 B, the user information is the organization information 12 D, and the document registration unit is the file registration unit 11 A. Thus, the first embodiment can be implemented.

  It is also possible to implement the present invention by regarding the WEB server as the file server 1, regarding the WEB page storage area in the WEB system as the file storage unit 12A, and the access log for the WEB page as the access log storage unit 12B.

(Second Embodiment)
In the second embodiment, metadata of a file having low usefulness is managed as an unnecessary file without corresponding to each department. In addition, the same code | symbol is attached | subjected to the structure which performs the function similar to 1st Embodiment, and the overlapping description is abbreviate | omitted suitably.

  The configuration of the file sharing system of the second embodiment is the same as that of the first embodiment, and is as shown in FIGS. However, a table for storing metadata of a file determined to be unnecessary is added to the metadata storage unit 22A of FIG. 20 in addition to a table corresponding to each department. Note that the configuration of the table that stores the metadata of the files that are determined to be unnecessary is the same as the configuration of the table that stores the metadata corresponding to each department.

  The processing procedure of the file sharing system in the second embodiment is the same as that in the first embodiment except for the process of rearranging the metadata in S102. Therefore, the process executed resident in the system is the same as the procedure shown in the flowchart of FIG.

(Detailed processing procedure of the metadata rearrangement processing S102 of the second embodiment)
FIG. 28 is a flowchart illustrating a processing procedure of the metadata rearrangement processing S102 according to the second embodiment.

  The processing from S201 to S211 in the flowchart shown in FIG. 28 is the same as the processing from S201 to S211 in the first embodiment shown in FIG. That is, the file management unit 11B first clears the access history storage unit 12C, extracts the access history from the access log storage unit 12B, stores it in the access history storage unit 12C (S201), and sorts by file name (S202). . Then, the usefulness of the file is determined in order from the top record of the access history storage unit 12C, and the metadata is rearranged (S204 to S211). Note that the procedure for determining the usefulness of a file is the same as the procedure shown in the flowchart of FIG.

  When the metadata rearrangement process is completed, the file management unit 11B rearranges unnecessary file metadata (S212). In the second embodiment, a file that has not been accessed by the user for a certain period (for example, six months) is determined as an unnecessary file. Then, the file management unit 11B moves the metadata of the corresponding file to the metadata table storing the metadata of the unnecessary file.

  Specifically, first, the file management unit 11B refers to the file storage unit 12A, and extracts records whose metadata arrangement date 12A04 is earlier than γ (for example, a date six months ago). Next, the file management unit 11B acquires a file name and a metadata table name from the extracted record. Further, the file management unit 11B extracts metadata based on the file name acquired from the acquired metadata table name. Then, a metadata arrangement command 13B for moving the extracted metadata to a metadata table for storing unnecessary file metadata is created and transmitted to the metadata server 2.

(Effect of the second embodiment)
According to the second embodiment, a file that has not been accessed for a certain period of time is assumed to be less useful, and metadata is moved to a metadata table that stores unnecessary data. In this way, the metadata to be searched can be limited to highly useful file metadata, and the file search accuracy can be improved and the search speed can be increased.

  Further, as a modification of the second embodiment, instead of moving the metadata of a file determined to be unnecessary, the file registrant may be notified to request deletion.

(Third embodiment)
A useful file stored in a file server in another department may be obtained indirectly by using an information transmission tool such as mail or instant message. For example, when a useful file is stored in the file server of another department, a person who intends to use this file may request a member of another department to send the file. Therefore, the member of the other department that receives the request sends the file to the requester using the attached file function of the mail system or the file transfer function of the instant message system.

  In such a case, the person who accessed the file server should be considered as the requester, not the member of the other department that received the request.

  Therefore, in the file sharing system of the third embodiment, the access history is also extracted from the attached file transmission log in the mail system.

(System configuration in the third embodiment)
FIG. 29 is a diagram illustrating a configuration of a file sharing system according to the third embodiment. The file sharing system according to the third embodiment includes a file server 1, a metadata server 2, a client 3, a network 4, and a mail server 5. The file server 1, the metadata server 2, the client 3, and the network 4 have the same configuration as that of the first embodiment.

  The mail server 5 receives the transmitted mail, and transmits the mail with reference to the destination described in the mail header. If there is an instruction to refer to the mail from the client 3, the mail transmitted to the user of the client 3 is transmitted to the client 3.

  The hardware configuration of the mail server 5 of the third embodiment is the same as the configuration shown in FIG.

(Module configuration in the third embodiment)
Next, the module configuration of the file sharing system according to the third embodiment will be described.

  FIG. 30 is a module configuration diagram of the file server 1 of the file sharing system according to the third embodiment. The processing unit (rectangular), the data storage unit (drum type), and the temporary data unit (tape type) are the same as the module configuration of the first embodiment shown in FIG. However, the third embodiment is different in that the file management unit 11B refers to the mail log storage unit 32A of the client 3. Other modules are the same as those shown in FIGS. 5 to 18 and will not be described.

  The module configuration of the metadata server 2 is the same as that shown in FIG. 19, and a detailed description thereof will be omitted. The mail server 5 can be constructed by installing existing software such as SENDMIL (registered trademark), and detailed description thereof is omitted.

  The client 3 has a mail system client function in addition to the configuration of the first embodiment.

  FIG. 31 is a diagram showing a module configuration related to the mail client function of the client 3. The module of the mail client function of the client 3 includes a mail client unit 31A, a mail log storage unit 32A, a mail 33A, and a file 33B.

  The mail client unit 31A transmits and receives mail. The mail log storage unit 32A stores a log of processing executed by the mail client unit 31A. The mail 33A is mail data transmitted and received by the user. The file 33B is file data attached when the user creates a mail.

(Processing procedure of the file sharing system in the third embodiment)
Next, a processing procedure of the file sharing system according to the third embodiment will be described. The processing procedure of the third embodiment is substantially the same as the processing procedure of the first embodiment. However, the process S201 for extracting the access history of the file is different in the metadata arrangement process S102.

  In the third embodiment, an access history for a file is extracted from the access log storage unit 12B, and a mail log is acquired from the mail log storage unit 32A of the client 3. When a file stored in the file storage unit 12A of the file server 1 is transmitted as an attached file from the contents of the mail log, the mail recipient is set as the file accessor. The recipient of the mail is extracted by referring to the destination included in the header information of the mail that sent the file.

  In the third embodiment, the mail log is collected from the client 3, but the mail server 5 may collect the mail log.

(Effect of the third embodiment)
According to the third embodiment, an access history closer to the actual situation can be acquired by including in the access history file access via a third party by a mail system or the like. Therefore, the usefulness of the file can be determined more accurately, and the file search accuracy can be further improved.

(Modification of the third embodiment)
As a modification of the third embodiment, the present invention may be applied to an instant message system instead of a mail system. In this case, an instant messaging server is used instead of the mail server 5. The access history may be collected on the instant messaging server or may be collected from the client 3.

It is a figure which shows the structure of the file sharing system of 1st Embodiment. It is a figure which shows the hardware constitutions of the file server 1, the metadata server 2, and the client 3 of 1st Embodiment. It is a figure which shows the module structure of the file server 1 of 1st Embodiment. It is a figure which shows the module structure of the file management part 11B of the file server 1 of 1st Embodiment. It is a figure which shows the structure of the access history table of 1st Embodiment. It is a figure which shows the structure of the file storage part of 1st Embodiment. It is a figure which shows the structure of the access log storage part of 1st Embodiment. It is a figure which shows the structure of the access log | history storage part of 1st Embodiment. It is a figure which shows the structure of the organization information storage part of 1st Embodiment. It is a figure which shows an example of the registration file of 1st Embodiment. It is a figure which shows an example of the metadata arrangement | positioning command (registration) of 1st Embodiment. It is a figure which shows an example of the metadata arrangement | positioning command (movement) of 1st Embodiment. It is a figure which shows an example of the search condition of 1st Embodiment. It is a figure which shows an example of the search command of 1st Embodiment. It is a figure which shows an example of the search result of 1st Embodiment. It is a figure which shows an example of the search result for a display of 1st Embodiment. It is a figure which shows an example of the file name of 1st Embodiment. It is a figure which shows an example of the file of 1st Embodiment. It is a figure which shows the module structure of the metadata server 2 of 1st Embodiment. It is a figure which shows the structure of the metadata storage part of 1st Embodiment. It is a flowchart which shows the process sequence of the file sharing system of 1st Embodiment. It is a flowchart which shows the procedure of the metadata rearrangement process of 1st Embodiment. It is a figure explaining the relationship between the access frequency of the file of 1st Embodiment, and the department where a file is useful. It is a flowchart which shows the procedure of the file usefulness determination process of 1st Embodiment. It is an example of the screen of the file search instruction | indication screen of 1st Embodiment. It is an example of the screen which displays the search result of the file of 1st Embodiment. It is an example of the screen which displays the list of useful files for every department of a 1st embodiment. It is a flowchart which shows the procedure of the metadata rearrangement process of 2nd Embodiment. It is a figure which shows the structure of the file sharing system of 3rd Embodiment. It is a figure which shows the module structure of the file server of 3rd Embodiment. It is a figure which shows the module structure of the client of 3rd Embodiment.

Explanation of symbols

1 file server 2 metadata server 3 client 4 network 5 mail server 10 CPU
DESCRIPTION OF SYMBOLS 15 Network interface 20 Hard disk 30 Memory 40 Display 41 Display control part 50 Keyboard 51 Keyboard control part 60 Mouse 61 Mouse control part 70 Bus 11A File registration part 11B File management part 11C File search part 12A File storage part 12B Access log storage part 12C Access History storage unit 12D Organization information storage unit 13A Registration file 13B Metadata placement command 13C Search condition 13D Search command 13E Search result 13F Search result 13G File name 13H File 21A Metadata registration unit 21B Metadata management unit 21C Metadata search unit 22A Metadata storage unit 11B1 Access history extraction unit 11B2 File usability determination unit 11B3 Metadata arrangement unit 11B4 Access Gravel table

Claims (20)

A file management system comprising a file server for storing a file and providing the file through a network in response to a request from a client,
The file server includes a first interface connected to the network, a first processor connected to the first interface and executing a program, a first memory storing the program and information used by the program, A first storage device for storing files,
The first memory stores organization information recording departments constituting the organization,
The first processor is
Record the access history of the file,
Aggregate the access history for each department stored in the organization information, determine that the file is highly useful for departments with a large number of accesses,
A file management system for searching for a file determined to be highly useful. A metadata server for storing metadata of the file;
The metadata server includes a second interface connected to the network, a second processor connected to the second interface and executing a program, a second memory storing the program and information used by the program, A second storage device for storing the metadata,
2. The second processor according to claim 1, wherein the second processor records the correspondence between the metadata of the file determined to be highly useful and the department having the large number of accesses in the second storage device. File management system.   The file management system according to claim 2, wherein the file is managed as an unnecessary file when there is no department determined that the usefulness of the file is high.   4. The file management system according to claim 3, wherein the first processor notifies the file server of a request to delete the file when there is no department determined that the file is highly useful. 5. .   The file management system according to claim 1, wherein the first processor periodically determines the usefulness of the file.   2. The file management system according to claim 1, wherein designation of a department is accepted as a search condition, and a file determined to be highly useful for the designated department is searched.   The file management system according to claim 1, wherein the file determined to be highly useful is displayed for each department. Further comprising a mail system or instant messaging system;
The access history is recorded as if the file stored in the file server is transmitted by the mail system or the instant message system as being accessed by the recipient. The file management system according to 1.   When the ratio of the number of accesses from a specific department for each file to the total number of accesses of the file is greater than a predetermined value, the first processor determines the specific department as a department with a large number of accesses. The file management system according to claim 1. A program for managing files stored in a file server,
Procedure to record access history from clients,
Summarizing the access history for each department stored in the organization information, and determining that the file is highly useful for departments with a large number of accesses;
A file management program that causes a computer to execute a procedure for searching for a file determined to be highly useful. A procedure for storing metadata describing information about the file;
The file management program according to claim 10, further causing the computer to execute a procedure for associating the metadata of the file determined to be highly useful with the department having the large number of accesses.   12. The file management program according to claim 11, further causing a computer to execute a procedure for managing a file for which a department judged to be highly useful does not exist as an unnecessary file.   13. The file management program according to claim 12, further causing a computer to execute a procedure for notifying a file having no department determined to be highly useful to be deleted from the file server.   The file management program according to claim 10, wherein the computer periodically executes a procedure for determining the usefulness of the file.   11. The file management program according to claim 10, further comprising: causing a computer to execute a procedure of receiving a designation of the department as a search condition and searching for a file determined to be highly useful for the designated department. .   The file management program according to claim 10, further causing a computer to execute a procedure for displaying the file determined to be highly useful for each department.   The procedure of recording the access history records the access history as having accessed the file on the receiving side when the file is transmitted by a mail system or an instant message system. File management program.   The procedure for determining the usefulness of the file is such that when the ratio of the number of accesses from a specific department for each file to the total number of accesses of the file is larger than a predetermined value, the specific department has a large number of accesses. The file management program according to claim 10, wherein the file management program is determined as a department. A file management method in a file management system comprising a file server that stores a file and provides the file through a network in response to a request from a client,
Stores organization information that records the departments that make up the organization,
Record the access history of the file,
Aggregate the access history for each department stored in the organization information, determine that the file is highly useful for departments with a large number of accesses,
A file management method, comprising: searching for a file determined to be highly useful. The file management system further includes a metadata server that stores metadata describing information about the file,
20. The file management method according to claim 19, wherein the metadata of the file determined to be highly useful is associated with the department having the large number of accesses.

Images