JP2010067094A - Electronic document management system, electronic document management method, and program for the same - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an electronic document management system for automatically generating metadata to be used for a subsequent search without imposing a special operation on a user. <P>SOLUTION: Metadata is automatically generated from position information when a user saves a file everyday, using that the position information of the file in a folder hierarchical structure is accurately determined. When the file in a file server is updated, the file is uploaded together with the position information on a document management server. The document management server then automatically generates the metadata by applying a predetermined rule to the position information. A unique file identifier is added to each uploaded file, and the file identifier and the generated metadata are managed in a table in association with each other. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to an electronic document management system, and more particularly to an electronic document management system that automatically generates and manages metadata used for file search.

  2. Description of the Related Art Conventionally, various electronic documents used by a plurality of clients are centrally managed by a file server connected on a network, and an electronic document management system that responds to browsing, print requests, etc. from each client is provided.

  In such an electronic document management system, in order to enable a user to reach a target file relatively easily, rules for storing files are generally defined. In such an electronic document management system, a user creates a folder and stores a file according to a predetermined rule, or inputs metadata such as a creation date and a creator according to a predetermined rule. It is required to do.

  However, in actual operation, the user dislikes complicated metadata input work, and as a result, the work is not thorough and metadata assignment is incomplete. There was a problem of not being able to reach.

On the other hand, Japanese Patent Laid-Open No. 2006-338669 (Patent Document 1) makes it possible to associate a plurality of documents in a plurality of locations with a single identifier in order to realize convenient document management. In addition, a configuration for grouping multiple documents, folders, or folder trees into a single virtual container is disclosed. However, even in Patent Document 1, execution of metadata still depends on the user's discipline, and Patent Document 1 does not indicate a solution to the above-described problem.
JP 2006-338669 A

  The present invention has been made in view of the above-described problems in the prior art, and the present invention provides an electronic document management system that uses a file server without requiring a user to perform a special operation when storing files. An object of the present invention is to provide an electronic document management system capable of automatically generating metadata to be used for searching for a file and automatically storing the metadata in association with a file.

  When storing a file, the inventors automatically generate metadata to be used for a later search without requiring a special operation from the user, and automatically store the metadata in association with the file. As a result of diligent study on the electronic document management system that can do this, pay attention to the regularity of the folder hierarchy structure of the file server, automatically generate metadata using the folder hierarchy structure, and associate this with the file The inventors came up with a configuration for automatically registering in the document management server, and reached the present invention.

  Generally, in a file server, a hierarchical structure of folders constructed according to a certain rule is prepared in advance. For example, after creating a top-level folder with the name of the customer company as the folder name, create a subfolder for each item in the lower hierarchy of the folder, and add a file name such as the item name to each folder. Prepare a hierarchical structure.

  When the user saves an electronic file, the target folder is found out of the folder tree expanded in this way, depending on the folder name, and the target electronic file is assigned a file name and stored. Although such operations are performed based on established rules, in practice, the user can intuitively perform these operations without being aware of such rules, Actually, these operations are performed almost accurately.

  In the present invention, by using the fact that the position information of the file in the folder hierarchical structure is accurately determined by the action of saving the file that the user performs on a daily basis, the metadata is automatically obtained from the position information. Is generated. That is, when the file is saved (or changed) in the file server, the file is uploaded to the document management server together with the position information, and the document management server receiving the file uploads the predetermined information to the position information. Automatically generate metadata by applying rules. Furthermore, in the present invention, a unique file identifier is assigned to each uploaded file, and the file identifier and generated metadata are associated with each other and managed in a table.

  In other words, according to the present invention, there is provided an electronic document management system including a file server for storing an electronic document shared by a plurality of client devices, and a document management server connected to the file server via a network. Means for detecting an updated file, and means for uploading the updated file and location information about the file to the document management server, wherein the document management server uploads the location uploaded from the file server. Means for generating metadata by applying a rule prepared for each type of document to information, means for giving a unique identifier to the file uploaded from the file server, the metadata, The unique knowledge Electronic document management system and means for table management in association with the child and with means for table management for each of the rule in association with said unique identifier and storage location of the file is provided.

  Hereinafter, although this invention is demonstrated with embodiment, this invention is not limited to embodiment mentioned later.

  FIG. 1 shows an electronic document management system 10 of this embodiment. The electronic document management system 10 includes a file server 12 that stores electronic documents shared by a plurality of client devices, and a document management server 14. In the electronic document management system 10, a file server 12, a document management server 14, and an image forming apparatus 16 and a personal computer (PC) 18 exemplified as client apparatuses include a local area network (LAN) and a wide area network. (WAN) or a network 20 configured as a network infrastructure such as the Internet.

  In the example shown in FIG. 1, the image processing device 16 is configured as an MFP (Multi Function Peripheral) having a scanning function, and a user scans a paper document using the function to create an image file. Then, after performing OCR processing as necessary to create a text file, the file server 12 is designated as an output destination, and the file is transmitted via the network 20. Similarly, the user creates an electronic document file using the PC 18, designates the file server 12 as an output destination, and transmits the file via the network 20.

  When the user transmits a file to the file server 12, the user interface provided in the image processing device 16 and the PC 18 displays and guides the folder hierarchical structure built in the file server 12, and the user is expanded. From the folder tree, find the folder where the file should be stored using the folder name, specify the folder as the storage destination, and send the file.

  There are predetermined rules for storing files in which folder, and it is a prerequisite for system operation that the user should follow this. If this level of rule is used, the user will feel some psychological burden. And can be performed intuitively and accurately. The electronic document management system 10 according to the present embodiment further includes a document management server 14, and new information is transferred by transferring predetermined information from the file server 12 to the document management server 14 via the network 20. Realizes electronic file management. This will be described in detail below.

  FIG. 2 is a functional block diagram of the file server 12 in the present embodiment. The file server 12 is configured as a personal computer, a workstation, or the like, and includes a CPU that functions as a system controller, a RAM that provides an execution space for application software, and data or a program for performing processing. A memory such as a ROM that stores the memory, various interface units such as a network interface including a NIC, and a storage device 22 for storing shared files. The storage device 22 is configured by, for example, a hard disk device or an optical disk device.

  The file server 12 includes a file update monitoring unit 24 and a file upload unit 26, and these functional units are used in the file server 12 as WINDOWS (registered trademark), UNIX (registered trademark), LINUX (registered trademark), Realized by executing various application programs described in an object-oriented programming language such as C, C ++, VisualC ++, VisualBasic, Java (registered trademark) under the control of other appropriate operation system (OS) Is done. Note that the file update monitoring unit 24 and the file uploading unit 26 can be realized separately from the file server 12 as devices that can monitor the storage device 22.

  In the storage device 22 of the file server 12, as described above, a folder hierarchical structure is constructed based on predetermined rules, and electronic files are stored in each folder located at the lowest hierarchy. . FIG. 3 is a diagram showing an example of a folder hierarchical structure constructed in the storage device 22, and shows a state in which a folder tree constructed for storing electronic files such as quotations is expanded.

  In the example shown in FIG. 3, the following rules are determined in advance. In other words, the folder hierarchy structure is constructed for each estimate, plan, and other documents (for example, sales orders, drawings, etc.), and the folder name of each top level is set to “estimate”, “plan”. "Rule", "Rule", "Rules", "Quotes" folder, create a folder for each year, and then create a folder for each month, "Plan" In the hierarchy below the "Document" folder, create a folder for each customer. For the "Project" folder, create a folder for each customer in the hierarchy below it. There is a rule that a folder is created for each case number, and a folder is created for each type of document to be stored in the lower hierarchy.

  In addition, the user stores the electronic file in the folder corresponding to the date of creation of the estimate, the file name is the project number + extension, and the plan is stored in the folder corresponding to each customer. Store the file name as matter number + extension, and store other documents in the folder of the relevant document type under the relevant customer number folder under the project folder. The rule that the file name is arbitrary is obligatory.

  Based on the above rules, the following folders are created in the storage device 22. That is, three folders 30, 40, 50 are created in the highest hierarchy, and folder names “estimate”, “plan”, and “project” are assigned to each. In the hierarchy below the “Estimate” folder 30, three folders are created for each year, and folder names “2004”, “2005”, and “2006” are assigned, respectively. Below these folders, folders are created for each month, and folders “January”, “February”, and “March” are created under the “2006” folder. . Further, in the hierarchy below the “plan” folder 40, three folders are created for each customer, and folder names “Yoshida Seisakusho”, “Ohara Kogyo”, and “Nakamura” are assigned respectively. .

  Furthermore, a folder with the folder name “Yoshida Seisakusho” is created in the hierarchy below the “Project” folder 50, and a folder with the project number (“12345”) is further created under that folder. Yes. In this folder hierarchical structure, as described above, among the documents related to the project, documents other than the estimate and the plan (for example, sales order, drawing, etc.) are stored for each type of the document. Therefore, it is necessary to create a folder for each document type. A folder for each document type is created by the user as needed, and a folder name corresponding to the type of document stored by the user is given. In the example shown in FIG. 3, three folders are created for each document type in the hierarchy below the folder with the folder name “12345” that is the case number. ”,“ Drawing ”, and“ inspection document ”.

  When the user stores an “estimate” electronic file in the file server 12 in which the folder hierarchical structure shown in FIG. 3 is constructed, first, the “estimate” folder is found from the top-level folders, and from there Go down the folder in the lower hierarchy, find the folder with the desired year attached as the folder name, expand it, and then go down the lower hierarchy and attach the desired month as the folder name Find the folder, open it, and store the “quote” electronic file there. FIG. 3 shows three electronic files 32 to 34 of “estimate” with “12345.jpg”, “23456.jpg”, and “34567.jpg” as file names in the “March” folder. The mode stored in a format is shown.

  Similarly, when a user stores an electronic file of a “plan”, first the “plan” folder is found in the folder at the highest level, and the target folder is then moved down to a folder at a lower level. The folder with the customer name is found and opened, and an electronic file of “plan” is stored there. In FIG. 3, “12345.jpg”, “33333.jpg”, and “22222.jpg” are added to the “Yoshida Seisakusho” folder, the “Ohara Kogyo” folder, and the “Nakamura” folder, respectively. The aspect which the electronic files 42-44 of a "plan" are stored in a jpeg format is shown.

  Similarly, when the user stores an electronic file of a document other than the estimate and the plan related to the project with the project number “12345”, first, the “project” folder is found from among the folders at the highest hierarchy, and further down from there. The folder with the target customer name is found, and the folder with the target project number is attached as the folder name. Then, a folder with a document type assigned as a folder name is opened down a folder at a lower hierarchy, and an electronic file of the corresponding document is stored there. Fig. 3 shows "Order Form.jpg" in the "Order Form" folder, "Design Drawing ver1.jpg" in the "Drawing" folder, and "Inspection Result 20080329.jpg" in the "Inspection Form" folder. The aspect stored as 52-54 is shown.

  Here, the functions of the file update monitoring unit 24 and the file uploading unit 26 of the file server 12 will be specifically described with reference to the folder hierarchical structure illustrated in FIG. 3 and FIG. 2.

  The file update monitoring unit 24 operates intermittently (for example, every 5 minutes) at a preset monitoring timing (predetermined time interval) to monitor the storage device 22. When the file update monitoring unit 24 detects a file in which the file information in the storage device 22 is updated by transmission of an electronic file from the client device, the file update monitoring unit 24 transfers the file related to the update to the document management server 14 to the file upload unit 26. Instruct them to do so. Upon receiving the instruction, the file upload unit 26 generates “position information” for the corresponding file, and uploads the file to the file transfer server 14 together with the “position information”. Next, processing executed by the file server 12 will be described in more detail based on the operation flowchart shown in FIG.

  FIG. 4 is a flowchart showing the operation of the file server 12. In the file server 12, first, in step 100, it is determined whether or not the monitoring timing is set in advance. If it is determined that it is the monitoring timing (step 100, Yes), in step 102, the storage device is stored. It is determined whether the file information in 22 has been updated. Here, the update of the file information is a concept including that the electronic file with the new file name is newly stored in the folder and the contents of the file already stored in the folder are overwritten. It is. Whether or not the file information has been updated is updated when the time stamp information (creation date and update date information) of the file or folder that the OS file system generally has is newer than the previous operation. Can be judged. If the file information has not been updated (No at Step 102), the process returns to Step 100 again, and the determination at Step 100 is repeated until the next monitoring timing comes. On the other hand, if the file information has been updated (step 102, Yes), the process proceeds to step 104, where “position information” is generated for the file related to the update, and the file is managed together with the generated “position information”. After uploading to the server 14, the process returns to step 100.

  Here, “location information” of a file in the present embodiment means information in which a folder name and a file name having a hierarchical relationship with respect to an updated file are described in one line. In the example shown in FIG. 3, if the file 32 is updated in the “estimate” folder tree, “\ estimate \ 2006 \ March \ 12345. “jpg” is generated, and this “position information” is uploaded to the document management server 14 together with the file 32. In the document management server 14, metadata is automatically generated using this “position information” and registered in a form associated with the file 32. The file server 12 in this embodiment has been described above. Next, the document management server 14 in this embodiment will be described.

  FIG. 5 shows a functional block diagram of the document management server 14 in the present embodiment. Similar to the file server 12 described above, the document management server 14 is configured as a personal computer, a workstation, or the like, and provides a CPU functioning as a system controller and an execution space for application software. RAM, a memory such as a ROM storing data or programs for processing, a network interface including a NIC, various interface units such as a network interface, and a storage device (not shown) including a hard disk device, an optical disk device, and the like It has.

  The document management server 14 further includes a filing control unit 62, a rule management unit 64, a metadata management unit 66, and a file management unit 68, and these functional units are operated in the WINDOWS in the document management server 14. Object-oriented such as C, C ++, VisualC ++, VisualBasic, Java (registered trademark) under the control of (registered trademark), UNIX (registered trademark), LINUX (registered trademark), and other appropriate operating systems (OS) This is realized by executing various application programs described in a programming language.

  As described above, the document management server 14 receives the updated file and its “location information” from the file server 12 via the network 20. The filing control unit 62 automatically generates metadata using the “location information” uploaded from the file server 12. The generation of metadata is performed based on rules managed by the rule management unit 64 as a table. Next, the filing control unit 62 manages the table by associating the generated metadata with the file. At that time, the filing control unit 62 assigns a unique file identifier to each file and stores it in a table provided in the metadata management unit 66 in association with the generated metadata. Further, the filing control unit 62 stores the file uploaded from the file server 12 in the file management unit 68, and the file management unit 68 manages the table by associating the storage location of the file with the file identifier. The functional means of the document management server 14 has been outlined above. Next, processing executed by the document management server 14 will be described in more detail based on the operation flowchart shown in FIG.

  FIG. 6 is a flowchart showing the operation of the document management server 14. In the document management server 14, first, in step 200, it is determined whether or not the updated file and its “location information” are uploaded from the file server 12, and if not uploaded (No in step 200). This determination is repeated. If it is determined in step 200 that the file has been uploaded (step 200, Yes), in step 202, a metadata generation rule is searched based on the uploaded “location information”. The search for the metadata generation rule is executed using the metadata generation rule table of the rule management unit 64. FIG. 7 illustrates a metadata generation rule table provided in the rule management unit 64.

  Next, in step 204, metadata is generated from “location information” based on the retrieved rule, a unique file identifier is assigned, and the metadata table of the metadata management unit 66 is associated with both. Stored in 8 to 10 illustrate metadata tables prepared for each corresponding rule in the metadata management unit 66. FIG.

  Next, in step 206, the file uploaded from the file server 12 is stored in the file management unit 68, and the process proceeds to step 208. In step 208, the storage location of the file and the file identifier are associated with each other and stored in a table provided in the file management unit 68, and then the process returns to step 200. FIG. 11 illustrates a filing information table provided in the file management unit 68. The processing executed by the document management server 14 has been described with reference to the operation flowchart shown in FIG. 6. Next, the folder hierarchical structure shown in FIG. 3 and various tables shown in FIGS. The processing executed by the document management server 14 in this embodiment will be described more specifically with reference to FIG.

  Here, the case where the electronic file stored in the storage device 22 of the file server 12 shown in FIG. 3 is updated will be specifically described as an example. Assume that the files 32 to 34 in the lowest hierarchy in the “estimate” folder tree are updated in the file server 12. When the update of the files 32 to 34 is detected, the file server 12 uploads the files 32 to 34 to the document management server 14 together with the respective “location information”. Specifically, the file 32 and its position information “\ estimate \ 2006 \ March \ 12345.jpg”, the file 33 and its position information “\ estimate \ 2006 \ March \ 23456.jpg”, and The file 34 and its position information “¥ estimate ¥ 2006 ¥ March ¥ 34567.jpg” are uploaded to the document management server 14 respectively.

  When the “location information” of the files 32 to 34 is uploaded to the document management server 14, the filing control unit 62 searches for a corresponding rule using the metadata generation rule table provided in the rule management unit 64. Specifically, the folder name of the top-level folder is extracted from the uploaded “location information”, and the rule stored in association with the folder name is searched from the metadata generation rule table To do.

  FIG. 7 illustrates the metadata generation rule table 70 provided in the rule management unit 64. In the metadata generation rule table 70, metadata generation rules are managed in a table for each top-level folder name. Specifically, a metadata generation rule and its identifier (rule id) are associated with each folder name of the highest hierarchy included in the “location information” uploaded from the file server. A storage destination of metadata generated based on the rule is associated.

  In the rule stored in the metadata generation rule table 70, the part described between% and% means “metadata name”. Also, “num (---)” converts to numerical values, “base (---)” converts to remove the file extension, “text (---)” converts to text, Each means. In addition, “filename” means the file name, and “f [n]” means the nth layer of the folder. Here, the n-th layer of the folder is a value counted as the first layer under the top folder (“estimate”, “plan”, “project” in the example of FIG. 3). Further, the “highest (hierarchical) folder” is not necessarily the highest (root) folder managed by the OS file system, but is the highest hierarchical folder among the folders to be managed in this document management system. .

  In the present embodiment, unique file identifier generation rules are also managed in the metadata generation rule table 70, and a file identifier is generated together with other metadata. In the table shown in FIG. 7, “file id (auto)” means a predetermined expression for automatically generating a unique file identifier.

  Here, considering the files 32 to 34, since the folder name of the folder of the highest hierarchy is “estimate”, the “rule id” stored in association with the folder name “estimate” is stored. = 321 ”is extracted, and the filing control unit 62 generates metadata based on the rule, and at the same time, a unique file identifier for each file is generated as one of the metadata. In “rule id = 321”, “file ID” as a unique file identifier is generated together with four metadata of “year”, “month”, “case ID”, and “document type”.

  For example, for the file 32, for the “file ID”, a unique identifier (543) is calculated using a predetermined formula. For “year”, the folder name (2006) in the first layer of the folder is converted to a numerical value (2006). For “Month”, the folder name (March) in the second layer of the folder is converted into a numerical value (3). “Project ID” is converted to a numerical value (12345) after the file extension (.jpg) is removed from the file name (12345.jpg). The “document type” is “estimate”. For the file 33 and the file 34, metadata and a file identifier are generated in the same procedure. When the filing control unit 62 generates the metadata and the file identifier for each file, the filing control unit 62 stores them in the “mitsumori” table of the metadata management unit 66 designated as the storage destination in the metadata generation rule table 70. FIG. 8 illustrates a “mitsumori” table 80. In the “mitsumori” table 80, the metadata (year, month, item ID, document type) of each of the files 32, 33, and 34 is associated with unique file identifiers “543”, “542”, and “541”. Stored.

  Next, it is assumed that the files 42 to 44 in the lowest hierarchy in the “plan” folder tree are updated in the file server 12. When the update of the files 42 to 44 is detected, the file server 12 uploads the files 42 to 44 to the document management server 14 together with the respective “location information”. Specifically, the file 42 and its position information “\ plan document \ Yoshida Seisakusho \ 12345.jpg”, the file 43 and its position information “\ plan document \ Ohara Kogyo \ 33333.jpg”, and the file 44 and its position Information “\ plan document \ Nakamura \ 22222.jpg” is uploaded to the document management server 14 respectively.

  When the “location information” of the files 42 to 44 is uploaded to the document management server 14, the filing control unit 62 searches for a rule based on the folder name of the folder at the highest hierarchy in these “location information”. .

  Here, in the case of the files 42 to 44, since the folder name of the folder of the highest hierarchy is “plan”, the folder name “plan” is selected from the metadata generation rule table 70 shown in FIG. The rule of “rule id = 250” stored in association with “” is extracted, and the filing control unit 62 generates metadata based on the rule, and at the same time, a unique file identification is generated for each file. The As shown in FIG. 7, in “rule id = 250”, a “file ID” is generated together with three metadata of “customer name”, “case ID”, and “document type”.

  For example, for the file 42, for the “file ID”, a unique identifier (123) is calculated using a predetermined formula. For “customer name”, the folder name (Yoshida Seisakusho) in the first layer of the folder is converted into text. “Project ID” is converted to a numerical value (12345) after the file extension (.jpg) is removed from the file name (12345.jpg). The “document type” is “plan”. Metadata and file identifiers are generated for the files 43 and 44 in the same procedure. When the filing control unit 62 generates metadata and a file identifier for each file, the filing control unit 62 stores them in the “keikakusho” table of the metadata management unit 66 designated as the storage destination in the metadata generation rule table 70. FIG. 9 illustrates a “keikakusho” table 82. In the “keikakusho” table 82, the metadata (customer name, case ID, document type) of the files 42, 43, and 44 are associated with unique file identifiers “123”, “122”, and “121”. Stored.

  Next, it is assumed that the files 52 to 54 in the lowest hierarchy in the “project” folder tree are updated in the file server 12. When the update of the files 52 to 54 is detected, the file server 12 uploads the files 52 to 54 to the document management server 14 together with the respective “location information”. Specifically, the file 52 and its location information “Project \ Yoshida Seisakusho \ 12345 \ Order Form \ Order Receipt.jpg”, the file 53 and its location information “Project \ Yoshida Seisakusho \ 12345 \ Drawings \ Design Drawing ver1.jpg” The file 54 and its location information “project \ Yoshida Seisakusho \ 12345 \ inspection document \ inspection result 20080329.jpg” are uploaded to the document management server 14 respectively.

  When the “location information” of the files 52 to 54 is uploaded to the document management server 14, the filing control unit 62 searches for a rule based on the folder name of the folder at the highest hierarchy in these “location information”. .

  Here, in the case of the files 52 to 54, since the folder name of the folder of the highest hierarchy is “project”, the folder name “project” is selected from the metadata generation rule table 70 shown in FIG. The rule “rule id = 200” stored in association with each other is extracted, and the filing control unit 62 generates metadata based on the rule, and at the same time, a unique file identifier is generated for each file. As shown in FIG. 7, “rule ID = 200” generates “file ID” as a unique file identifier along with three metadata of “customer name”, “case ID”, and “document type”. Is done.

  For example, for the file 52, for the “file ID”, a unique identifier (345) is calculated using a predetermined formula. For “customer name”, the folder name (Yoshida Seisakusho) in the first layer of the folder is converted into text. For “Matter ID”, the folder name (12345) in the second hierarchy of the folder is converted into text. For the “document type”, the folder name (order receipt) in the third hierarchy of the folder is converted into text. Metadata and file identifiers are generated for the files 53 and 54 in the same procedure. When the filing control unit 62 generates the metadata and the file identifier for each file, the filing control unit 62 stores them in the “project” table of the metadata management unit 66 designated as the storage destination in the metadata generation rule table 70. FIG. 10 illustrates a “project” table 84. In the “project” table 84, the metadata (customer name, case ID, document type) of each of the files 52, 53, and 54 is associated with unique file identifiers “345”, “344”, and “343”. Stored.

  As described above with reference to FIG. 3, the folder at the lowest level of the “project” folder tree is created for each document type by the user. However, depending on the operation status, the user creates a temporary folder without permission. It is expected that a unique folder name will be assigned. If such a situation is left unattended, a “document type” unscheduled by the system administrator will be registered as metadata on the database. In the present embodiment, in order to avoid such a situation, it is preferable to accept only predetermined folder names of folders created for each document type. Hereinafter, this point will be described with reference to FIG.

  FIG. 11 illustrates a folder name restriction table 85 that is used to restrict the folder name of the “document type” folder permitted to be created by the user in the hierarchical structure of the “project” folder. As described above with reference to FIG. 10, in “rule id = 200”, metadata obtained by converting the folder name of the third hierarchy of the folder into text is set as “document type” in the “project” table of the metadata management unit 66. At this time, the folder name restriction table 85 shown in FIG. 11 is referred to. Even if the folder name given by the user is not planned by the system administrator (for example, “design drawing”), the folder name restriction table 85 is referred to when generating the metadata, and the document is automatically registered. The type (for example, “drawing”) is registered as metadata. Note that “*” in FIG. 11 represents a wild card and is replaced with an arbitrary character string. For example, the folder names “order receipt”, “order management”, and “order receipt” all match “order *”, and the document type is “order receipt”. In addition, this folder name restriction table is applied in order from the top, and it is assumed that only folder names that do not match any of “Orders *”, “Drawings”, “Design drawings”, and “Inspection documents” match “*” and “Other” documents. A type is assigned.

  As described above, a table is prepared for each corresponding rule in the metadata management unit 66, and the filing control unit 62 stores a unique file identifier and metadata in each table in association with each file. The file body is stored in the file management unit 68. At that time, the filing control unit 62 stores the file storage location and the unique identifier (file ID) of the file in association with each other in the filing information table prepared in the file management unit 68. FIG. 12 illustrates a filing information table 90 prepared in the file management unit 68. In the filing information table 90, “file ID” and “file storage location” are stored in association with each other. As shown in FIG. 11, in the present embodiment, “file ID”, “corresponding rule”, “update date / time”, and “position information” can be stored in association with each other.

  The electronic document management system 10 according to the present embodiment has been described above. However, in the electronic document management system 10, the user is merely required to save the file in the file server 12, and additional metadata related to the metadata is required. It is not necessary to perform a simple input work. In the electronic document management system 10, since predetermined metadata is automatically generated, the operation of the system is surely performed without being influenced by the user's discipline, and as a result, the subsequent use of files can be improved. It becomes easy. Each time a file is updated on the file server 12, a unique identifier is assigned to the updated content file and registered in the database. For example, the same file at the same location on the file server 12 The file overwritten with the name is also registered in the database as a separate file having an identifier different from the file before overwriting, and the file update history can be managed.

  Further, in the electronic document management system 10 of the present embodiment, metadata is generated based on rules corresponding to each document type, and metadata is managed in a separate table for each rule, so that files can be stored in various folders. Even if they are stored separately, by using these metadata tables, the desired metadata can be obtained for different types of documents related to the same matter or multiple types of documents exchanged with the same customer. It becomes possible to search with horizontal skewers using.

  The functions of the above-described embodiments are as follows: assembly language, C, Visual C, C ++, Visual C ++, Java (registered trademark), Java (registered trademark) Beans, Java (registered trademark) Applet, Java (registered trademark) Script, Perl , Ruby, and the like, which can be realized by a device-executable program written in a legacy programming language, an object-oriented programming language, or the like, and can be stored and distributed in a device-readable recording medium.

  The present invention has been described with the embodiments, but the present invention is not limited to the above-described embodiments, and other embodiments, additions, changes, deletions, and the like can be conceived by those skilled in the art. As long as the effect | action and effect of this invention are show | played in any aspect, it is included in the range of this invention.

The figure which shows an electronic document management system. The functional block diagram of a file server. The figure which shows the folder hierarchical structure constructed | assembled in the memory | storage device of a file server. The flowchart which shows operation | movement of a file server. The functional block diagram of a document management server. The flowchart which shows operation | movement of a document management server. The figure which shows a metadata production | generation rule table. The figure which shows a "mitsumori" table. The figure which shows a "keikakusho" table. The figure which shows a "project" table. The figure which shows a folder name restriction | limiting table. The figure which shows a filing information table.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Electronic document management system, 12 ... File server, 14 ... Document management server, 16 ... Image forming apparatus, 18 ... Personal computer, 20 ... Network, 22 ... Storage device, 24 ... File update monitoring part, 26 ... File upload , 30 ... folder, 40 ... folder, 50 ... folder, 32-34 ... electronic file, 42-44 ... electronic file, 52-54 ... electronic file, 62 ... filing control unit, 64 ... rule management unit, 66 ... meta Data management unit 68 ... File management unit 70 ... Metadata generation rule table 80 ... "mitsumori" table 82 ... "keikakusho" table 84 ... "project" table 85 ... Folder name restriction table

Claims (7)

An electronic document management system including a file server for storing an electronic document shared by a plurality of client devices, and a document management server connected to the file server via a network,
The file server is
Means for detecting updated files;
Means for uploading an updated file and location information about the file to the document management server,
The document management server
Means for generating metadata by applying a rule prepared for each type of document to the location information uploaded from the file server;
Means for giving a unique identifier to the file uploaded from the file server;
Means for associating the metadata with the unique identifier and managing the table for each rule; and means for managing the table by associating the unique identifier with the storage location of the file,
Electronic document management system.   The electronic document management system according to claim 1, wherein the position information is information describing a folder name and a file name having a hierarchical relationship with respect to the file. A document management server network-connected to a file server that stores an electronic document shared by a plurality of client devices,
The document management server
Means for acquiring a file updated from the file server and position information about the file; means for generating metadata by applying a rule prepared for each type of document to the acquired position information;
Means for giving a unique identifier to the acquired file;
Means for associating the metadata and the unique identifier with a table for each rule;
Means for managing the table by associating the unique identifier and the storage location of the file,
Document management server.   4. The document management server according to claim 3, wherein the position information is information describing a folder name and a file name having a hierarchical relationship with respect to the file. A computer-executable method for causing a document management server connected to a network to the file server to manage a document shared by a plurality of client devices stored in the file server, the method comprising:
For the document management server,
Means for acquiring a file updated from the file server and position information about the file; means for generating metadata by applying a rule prepared for each type of document to the acquired position information;
Means for giving a unique identifier to the acquired file;
Means for associating the metadata and the unique identifier with a table for each rule;
A method for realizing means for managing the table by associating the unique identifier and the storage location of the file.   6. The method according to claim 5, wherein the location information is information describing a folder name and a file name having a hierarchical relationship with respect to the file.   A computer-executable program for causing a document management server to execute the method according to claim 5.

Images