JP2010079444A - File management method and system by metadata - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To manage an electronic document file by metadata without tampering with existing electronic files as thoroughly as possible without transferring them. <P>SOLUTION: A server operating as a proxy is disposed in the front of an existing file server, and the management of a relation between the metadata and the file or a directory on the existing file server, a relation between the metadata and a user, and an access right by the metadata is performed in the proxy server. The right management of each additional correction change is also performed by the metadata. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a method and system for managing files, directories, and access authority on an existing file server using metadata.

At present, strict access authority management, information leakage countermeasures, and life cycle management are regarded as important for electronic document files in organizations from the viewpoint of security and compliance.
On the other hand, search and information sharing are also regarded as important for improving efficiency by sharing knowledge. In addition, since there are a large number of electronic document files, efficient management using metadata is desired instead of individual files, directories, and users, and various systems and products exist.
For access authority management, life cycle management, and the like, there is a product in a field called a document management system (Non-Patent Document 1, Non-Patent Document 2). In these document management systems, electronic document files can be managed with metadata, and some functions such as version management and workflow exist in addition to access authority management, life cycle management, and retrieval by metadata.

However, in the conventional document management system, it is premised that the electronic document file is placed in a unique repository or a specific repository product (Non-patent Documents 3 and 4). Although there is a module for transferring an electronic document file in an existing file server, basically, an existing file server including an existing electronic document file cannot be used as it is. Therefore, when there are a large number of electronic document files, there is a migration and registration cost.
Also, in the conventional document management system, it is often premised that an electronic document file is operated via original client software or a browser (Non-Patent Document 5). A general user is accustomed to a conventional UI (User Interface) such as Explore for work that has been conventionally performed, such as storage and access of files.
Furthermore, although a small start in which only a part of the electronic document files is transferred to the document management system is possible, a small start in which only some users are targeted for all the electronic document files cannot be performed.
For this reason, the conventional document management system is applied only to specific electronic document files that require strict management according to laws and standards, and many electronic document files in an organization are managed by an old file server. ing.

On the other hand, products in the field of enterprise search specialized for search enable flexible search at high speed including metadata search for existing file servers (Non-Patent Document 6). However, although it is possible to control the search result, access control to the actual electronic document file is out of scope and cannot be used for managing the electronic document life cycle in the organization.
There are also products having some functions of file server access authority management and life cycle management (Non-patent Document 7). However, it is basically limited to checking and reporting functions, and does not cover all access authority management and life cycle management.
In addition, WAFS (Non-patent Document 7) performs only a cache for speeding up, and cannot be used for access authority management, life cycle management, or the like.

Documentumhttp: //www.emc.com/products/family/documentum-family.htm DocumentBrokerhttp: //www.hitachi.co.jp/Prod/comp/soft1/docbro/ Documentum Content Server http://www.japan.emc.com/products/detail/software/content-server.htm DocumentBroker Version 3 Function Overview and Supported Products http://www.hitachi.co.jp/Prod/comp/soft1/docbro/info/function/prod.html#func_outline Basic structure of ECM products http://www.insightnow.jp/article/1347 FAST ESPhttp: //www.fastsearch.co.jp/download/data/ESP_Sheet_9ydA9.pdf Varonis DatAdvantage http://www.nox.co.jp/products/storage/varonis/index.shtml WAFS (wide area file services) http://itpro.nikkeibp.co.jp/article/COLUMN/20060919/248323/

  In view of the problems of the prior art as described above, the present invention is a file based on the metadata of an electronic document file without changing the existing electronic document file as much as possible to the existing file server and without transferring them. An object is to provide a file management method and system based on metadata in an existing file server capable of realizing management and access authority management.

In order to achieve the above object, a file management method using metadata in an existing file server according to the present invention has a proxy server placed in front of the existing file server, and the proxy server uses the file metadata in the existing file server, The present invention is characterized in that a process for managing the relationship between the metadata and directory of each file, the relationship between the user and metadata, and the access authority based on the metadata is executed.
Further, the file management system based on metadata in the existing file server according to the present invention includes the file metadata in the existing file server, the relationship between the metadata and directory of each file, the relationship between the user and metadata, and the access authority based on the metadata. A proxy server having means for executing a process for managing

  According to the present invention, it is possible to manage an electronic document file using metadata and access authority using metadata with respect to the existing file server while minimizing changes to the existing file server and reducing initial costs. Management can be realized.

Hereinafter, an embodiment for carrying out the present invention will be specifically described with reference to the drawings.
FIG. 1 shows a system configuration diagram showing a portable device according to the present invention.
The system of this embodiment includes a client PC 100, a directory server 110, an existing file server group 120, and a file server integrated management proxy 130.
The client PC 100 includes an explorer 101 for operating a directory or file on a local or existing file server, client software 102 serving as a UI (user interface) of the system of the present invention, and the like.
Here, the client software 102 may be dedicated client software, or may use an existing Web browser. Except for dedicated client software, it is an existing technology.
The directory server 110 is an existing technology, and manages some attribute information such as a user ID / password and a job system, and performs proxy for user authentication. In the present embodiment, an existing directory server is used, but a function for managing information equivalent to the directory server 110 and performing user authentication may be arranged in the file server integrated management proxy 130.
The existing file server group 120 is a file server that is already used in various organizations such as a company, and directories and files are already arranged therein.

The file server integrated management proxy 130 is the center of the system of the present invention, and is only newly introduced when the client software 102 does not use dedicated client software.
The file server integrated management proxy 130 includes an explorer interface unit 131, an extended operation interface unit 132, a metadata processing unit 133, a metadata search processing unit 134, a management processing unit 135, a metadata management DB 136, an authority policy DB 137, and metadata. The assignment rule group 138, the crawl processing rule group 139, the file server interface unit 140, and the crawl processing unit 141 are configured.

The explorer interface unit 131 communicates with the explorer 101 on the client PC 100, and performs processing while providing a UI equivalent to that used by an existing file server to the client PC user. Specific examples are directory / file reference / creation / deletion.
The extended operation interface unit 132 communicates with the client software 102, and performs functions such as search by metadata and addition / modification of metadata described later, which are functions that do not exist in the existing file server. The client PC user executes these functions with the extended operation interface unit 132 through the client software 102.
The metadata processing unit 133 performs processing of metadata managed by the metadata management DB 136 using the metadata assignment rule group 138 and the authority policy DB 137 in the processing of the explorer interface unit 131.
The metadata search processing unit 134 searches the metadata management DB 136 for metadata using the authority policy DB 137 in the processing of the extended operation interface unit 132.
The management processing unit 135 uses the authority policy DB 137 to perform additional correction processing on the authority policy DB 137 itself, the metadata management DB 136, the metadata assignment rule group 138, and the crawl processing rule group 139.
The metadata management DB 136 includes a file directory metadata management table 200 shown in FIG. 2, a user metadata management table 300 shown in FIG. 3, a file directory metadata authority table 400 shown in FIG. 4, and a user shown in FIG. Metadata authority table 500.

The file directory metadata management table 200 in FIG. 2 includes an item number ID 201, a file directory path information URI 202, and a metadata group 203 attached to each URI.
The metadata group 203 includes a plurality of metadata managed by the metadata ID 204.
In this embodiment, including the following description, the metadata is in a format in which the metadata classification 205 and the metadata content 206 are separated by “:” and collected by “{}”. Further, as seen in the column with ID 00001, it is assumed that the content of a plurality of metadata can be registered for one URI with respect to the same metadata classification. However, other existing metadata formats and specifications may be used.

The user metadata management table 300 in FIG. 3 includes a user ID 301 that is a user identifier and a metadata group 302 attached to each user. Similar to the metadata management table 200 of the file directory, the metadata group 302 includes a plurality of metadata managed by metadata IDs.
Here, in the present embodiment, since cooperation with the directory server 110 is assumed, the user ID 301 is synchronized with that managed by the directory server 110.

The file directory metadata authority table 400 of FIG. 4 includes an ID 401 indicating the corresponding ID 201 of the metadata management table 200 of the file directory, a metadata ID 402 indicating the metadata ID 204 of the corresponding metadata group 203, An authority user metadata 403 indicating metadata of a user having change / delete authority, and a rule ID 404 indicating the rule ID when set in the metadata grant rule.
In the authorized user metadata 403, a metadata group obtained by combining a plurality of metadata can be designated, and a plurality of metadata groups can be designated. For example, in the first row of this table, the metadata “{department: sales department}” having the metadata ID 001 existing in the first line of FIG. 2 is [{department: sales department} {job type: department manager}]. Or a user having a metadata group of [{Department: Sales Department} {Occupation: Department Manager}] can be changed and deleted.

  The user metadata authority table 500 shown in FIG. 5 includes a user ID 401 indicating the corresponding user ID 301 of the user metadata management table 300, a metadata ID 501 indicating the metadata ID of the corresponding metadata group 302, It consists of authority user metadata 503 indicating metadata of a user having change / delete authority. The meaning is the same as the relationship between the metadata management table 200 of the file directory and the metadata authority table 400 of the file directory.

On the other hand, the authority policy DB 137 of FIG. 1 includes an access authority table 600 shown in FIG. 6 and an access authority setting authority table 700 shown in FIG.
The access authority table 600 of FIG. 6 gives an authority ID 601 that is an identifier of the access authority, a target type 602 that indicates the type of target for which the access authority is set, and target metadata 603 that indicates the target metadata for which the access authority is set. An authority 604 indicating authority, usable metadata 605 that is metadata that can be used when setting an authority for adding metadata and setting additional rules, and authorized person metadata 605 that indicates metadata of a user having access authority. Composed.
Here, in the target type 602, a combination of “F” indicating a file, “D” indicating a directory, and “U” indicating a user is set. In addition to the permissions (read, write, etc.) that can be set for normal file server files and directories, addmeta permission that can add metadata, and setrule that can set metadata grant rules for directories Set security permission that can add permission and access authority.
In the usable metadata 605, metadata that can be used with the addmeta authority, the setrule authority, and the setsecurity authority are set. Also, it is possible to express “!” For restriction as in a row with an authority ID of 00008.
For example, in this line, a file or directory having metadata of [{department: sales department} {security: confidential}} is [! An authority “! *” That does not permit all authority is set for a user who does not have “{department: sales department}” metadata, which means {department: sales department}. Accordingly, it is possible to set so that confidential data is not accessed by outside users.

The access authority setting authority table 700 in FIG. 7 includes an authority ID 701 that indicates the corresponding authority ID 601 in the access authority table 600 and authority user metadata 702 that indicates metadata of a user who has authority to change and delete this metadata. .
In the authority user metadata 702, a metadata group combining a plurality of metadata can be specified, as in the metadata authority table 400 of the file directory in FIG. 4 and the metadata authority table 500 of the user in FIG. Multiple metadata groups can be specified.
For example, the first row of this table is the user whose authority ID is 00001 in FIG. 6 is a user having a metadata group of [{department: system management department} {job type: chief}], or [{department: system This means that a user having the metadata group {management department} {job type: file server manager}] can change and delete.

The metadata grant rule group 138 includes a metadata grant rule table 800 and a grant rule setting authority table 900 shown in FIG.
8 includes a rule ID 801 serving as a rule identifier and a provision rule 802 serving as the rule itself.
The rules describe what and how to add and modify the metadata at what timing. The rule in FIG. 8 is merely an example. For example, the row with the rule ID 00001 is a rule for changing the date of access and the metadata of the information of the user who has accessed.
The line with rule ID 00002 is a rule for adding creator metadata when a file is newly placed on the file server. Although not shown in the figure, it is possible to add or change metadata through an external subsystem in this rule.

The grant rule setting authority table 900 shown in FIG. 9 includes an authority ID 901 that indicates a corresponding rule ID 801 in the metadata assignment rule table 800 and authority user metadata 902 that indicates metadata of a user who has the authority to change and delete this metadata. The
In the authority user metadata 702, a metadata group combining a plurality of metadata can be specified, as in the metadata authority table 400 of the file directory in FIG. 4 and the metadata authority table 500 of the user in FIG. Multiple metadata groups can be specified.
For example, the first row of this table is the user having the metadata group [{department: system management department} {job type: chief}] in the row with rule ID 00001 in FIG. This means that a user having the metadata group {management department} {job type: file server manager}] can change and delete.

On the other hand, the file server interface unit 140 shown in FIG. 1 communicates with the existing file server group 120, and performs an operation process on files and directories in the existing file server group 120 in the process of the explorer interface unit 131. .
The crawl processing unit 141 performs crawl processing on the existing file server group 120 through the file server interface unit 140 in accordance with a rule of the crawl processing rule group 139 or an administrator's operation such as introduction. Although details of the crawl processing rule group 139 are omitted, for example, a rule for performing a metadata grant process in accordance with a metadata grant rule in the metadata grant rule group immediately once or periodically. This rule is used for dealing with files arranged in the file server at the time of initial introduction or access from outside the system of the present invention.

FIG. 10 is a flowchart relating to an outline of processing when the system of the present invention is introduced.
The system installer designates the target existing file server group 120 and the directory server 110 to be linked (step 1001).
Next, set the initial policy at the time of introduction. In this, for example, the metadata grant rule table 800 and the grant rule setting authority table 900 corresponding to the rule are set. The latter may be set as [{department: system management department} {job type: file server charge}] or the like by default. In addition, the user uses a subsystem extracted from the directory server 110 to specify metadata to be given to each user. In addition, initial settings such as the authority policy DB 137 are also performed.
Next, initial setting of the metadata management DB 136 is performed (step 1003). This uses the crawl processing unit 141 to register file and directory metadata in the metadata DB 136 based on the rules in the metadata assignment rule group 138. In this case, there may be a rule that is not applied. The rule applied at this time is basically a rule in which metadata is determined according to the URI.

Finally, the system introducer performs additional corrections such as the authority policy DB 137 and the metadata assignment rule group 138 mainly on the additional correction of the metadata management DB 137. In addition modification of the authority policy DB 137, a mechanism for extracting from the access authority of the existing file server group 120 may be prepared and used.
This completes the process of introducing the system of the present invention into the existing file server group 120.
This realizes that the existing file server group 120 can be installed without being stopped, restricted in use, or moved or copied.

FIG. 11 is a flowchart relating to the processing outline of the explorer interface unit 131 when a general user performs file and directory operations on the explorer 101 through the system of the present invention.
A general user accesses the proxy 130 of this system in the same manner as a normal file server. At this time, the explorer interface unit 131 checks the user ID, the access destination path, and the access type (step 1101). This confirmation uses existing technology such as login processing performed on a normal file server or linkage with a directory server.
Next, the explorer interface unit 131 acquires the metadata on the metadata management DB 136 from the user ID and the access destination path through the metadata search processing unit 134. Specifically, the metadata management table 200 of the file directory shown in FIG. 2 is searched with the URI 202 from the access destination path, and the metadata group assigned to the URI is acquired. Further, the user ID authority management table 300 is searched with the user ID 301 from the user ID, and the metadata group 302 assigned to the user is acquired.
For example, when a user with a user ID of 1000001 accesses a file in the path "\\ server1 \ sales department \ X company \ estimate.doc", each of the first line in FIG. 2 and FIG. Get metadata group in.

Next, the explorer interface unit 131 searches the authority policy DB 137 through the management processing unit 135 and performs an access authority check (step 1102). Specifically, a search is performed with the target type 602, the target metadata 603, the authority 604, and the authority person metadata 606, which is a file or a directory, and a line including the metadata and the access type acquired in step 1101 is checked.
For example, when the user with the user ID 1000001 has read access to the file in the path “\\ server1 \ sales department \ X company \ estimate.doc”, it is obtained in step 1. The metadata group in the first row in FIG. 3 includes the target metadata in the first row in FIG. 6, and the metadata group in the first row in FIG. 2 obtained in step 1 is the first row in FIG. The right authority metadata is included, the object type is set to “F” of the file, and the authority includes read. Therefore, checking is permitted in this line.

As described above, the management processing unit 135 checks the row of the access authority table in FIG. 6 of the authority policy DB 137 to determine whether access is permitted or not.
If the explorer interface unit 131 determines in step 1102 that access is not permitted, the explorer interface unit 131 returns to the explorer 101 of the client PC 100 access denial similar to that performed by a normal file server.
On the other hand, if it is determined in step 1102 that access is permitted, the access operation itself is reflected in the existing file server group 120 through the file server interface unit 140 and the metadata processing is performed by the management processing unit 135. (1106). To reflect the former existing file server group, the file server interface unit 140 simply passes the contents received by the explorer interface unit 131 to the existing file server group 120. Details of the latter metadata-related processing will be described with reference to FIG.

FIG. 12 is a flowchart regarding the details of the metadata-related processing of FIG. 11 performed by the explorer interface unit 131 through the management processing unit 135.
The explorer interface unit 131 checks whether or not a new file or directory is created based on the access type obtained in step 1101 (step 1201). In the case of new creation, a new line is registered in the metadata management table 200 in the file directory of the metadata management DB 136 with the path as a URI.
Also, the metadata addition rule table 800 of the metadata addition rule group 138 is checked, and the metadata based on the rule is registered in the added row of the metadata management table 200 together with the rule ID of the applied rule.
Also, the authority user metadata of the rule applied from the assignment rule setting authority table 900 is copied to the corresponding part of the metadata authority management table 400 of the file directory (step 1202).
For example, when newly created under “\\ server1 \ sales department \”, the rule IDs 00001 to 00003 in FIG. 8 are applied, and metadata shown in each rule is given.

If it is determined in step 1201 that the access type is not newly created, it is next checked whether or not to delete (1203). If the check results in deletion, the metadata management DB 136 is searched for a line whose access destination path and URI match, and the line is deleted (step 1204).
In step 1203, if the access type is not deletion, that is, if the access type including step 1201 is neither newly created nor deleted, the metadata management DB 136 is searched for a line where the access destination path and URI match. Then, the metadata addition rule group is checked, and additional correction of the metadata based on the rule is performed (step 1205).
For example, rule ID 00001 in FIG. 8 is applied, and the last access date and user ID metadata are changed.
As described above, when access is performed from the client PC 100 through the explorer 101 in the same manner as a normal file server, all of the processing of the metadata, the access authority management using the metadata, and the processing on the existing file server are all performed. realizable.

  Next, a metadata search function that does not exist in a normal file server and a management function such as change of metadata and authority will be described. These functions are realized by the client software 102 that is the UI of the client PC 100 and the extended operation interface unit 132 that performs actual processing.

FIG. 13 is a flowchart regarding the processing outline of the extended operation interface unit 132.
First, user login authentication is performed, and a user ID is acquired together with the authentication (step 1301). This uses existing techniques such as authentication itself and acquisition of a user ID in cooperation with the directory server 110.
Next, when an operation used by the user is input, the extended operation interface unit 132 performs processing in accordance with the operation.
First, it is checked whether it is a metadata search operation (step 1302). If the operation is a metadata search operation, the user is made to input metadata to be searched, the metadata search processing unit 134 is used to search the metadata management DB 136, and the corresponding URI is displayed on the client software 102 ( Step 1303). In this search, a check is made in the same manner as in step 1102 in the flowchart relating to the processing outline of the explorer interface unit 131 in FIG. 11, and only those having at least read access authority are displayed. In this display, an access authority may be displayed at the same time, or a function for displaying an unauthorized user at the same time that there is no access authority may be added.
Except for searching using metadata from the metadata management DB 136, the technology of the existing search system may be used.
Subsequently, the user is made to input whether or not to perform an operation related to metadata, and the check is performed (step 1304). If not completed, the process returns to step 1302. In the case of termination, the processing of the extended operation interface unit 132 is finished as it is.
Thereafter, the operation type is checked (step 1305, step 1307) in the same manner, and the corresponding operation processing described later is performed (step 1306, step 1308, step 1309). The subsequent processing is the same as that after step 1303.

FIG. 14 is a flowchart of an outline of processing related to the metadata assignment rule-related operation in step 1306 of FIG.
The extended operation interface unit 132 prompts the user for input and checks whether or not the metadata addition rule is a new addition (step 1401).
If it is a new addition, the user is prompted to input the rule (step 1402). At the time of this input, the change deletion authority of this rule is also input. When inputting the rule, the search process in step 1303 in FIG. 13 may be used or applied to add a file directory or a user search process to assist input.
Next, it is checked whether or not the rule can be added through the management processing unit 135 (step 1403). This check is almost the same as step 1102 in the flowchart relating to the processing outline of the explorer interface unit 131 in FIG. 11, but checks whether there is a setrule authority instead of the type of access, and tries to give it by that rule. It is checked whether the metadata is included in the available metadata 605. If the check is not passed, although omitted in the figure, the user is prompted to select whether to prompt input again or end, and the process is performed.

If it is determined in step 1401 that no new addition has been made, the user is made to search for a rule to be changed and deleted using the metadata assignment rule table 800 of the metadata assignment rule group 138 (step 1405). Then, whether or not there is an authority to change and delete the selected rule is checked using the grant rule setting authority table 900 and the user metadata management table 500. This check checks whether one of the metadata groups listed in the authority user metadata 702 of the rule to be changed is included in the user metadata group 302 (step 1406).
If the check is not passed, it is omitted in the figure, but the user is prompted to select again or end, and the process is performed.
Here, when selecting from the metadata assignment rule table 800 in step 1405, only those having the authority to change and delete may be displayed, and step 1406 may be omitted.

Next, the user selects whether to change the rule or delete the rule, and checks the result (step 1407). In the case of a change, the process proceeds to step 1402 for new addition, and in the same manner as in the case of new addition, the grant rule authority check in step 1403 is performed for the rule after the change.
If the rule is deleted after step 1403 or in step 1407, the URI, the metadata group before and after the addition / deletion of the rule, the access authority for the file or directory affected by the addition / deletion of the rule The metadata of the user who has is displayed (step 1404).
Specifically, from the metadata management table 200 of the file directory of the metadata management DB 136, the rule information using the pre-change rule ID or the rule ID to be deleted, the post-change rule information or the added rule path information is used. A URI of a file or directory whose metadata changes before and after addition / deletion, and a metadata group of the file / directory before and after addition / deletion of rules are searched.
Further, using the metadata group of the search result, the authority authority metadata 606 and the authority 604 having the access authority before and after the rule addition / change are deleted from the access authority table 600 of the authority policy DB 137. These search results are displayed separately before and after the rule addition / change / deletion.

Next, the user is judged whether or not to execute addition / deletion of the rule, and the result is checked (step 1408).
If it is to be executed in step 1408, the rule change is reflected in the metadata addition rule table 800 of the metadata addition rule group 138 in the rule addition / change deletion.
Further, in the case of adding a rule, the user's metadata group having the authority to change and delete the rule is input by the user and reflected in the grant rule setting authority table 900 (step 1409).
Here, regarding the latter, it is possible to set a metadata group of a user who has added a rule by default, and to perform additional correction on the metadata group.
After step 1409, the user is prompted to check whether or not the rule addition / deletion is to be applied to the existing directory file (step 1410). In the case of applying, the URI and the metadata group after addition / change deletion of the rule displayed in step 1404 are reflected in the metadata management table 200 of the file directory of the metadata management DB 136.
Further, similarly to step 1202 of the flowchart relating to the details of the metadata-related processing in FIG. 11, the contents of the metadata authority management table 400 of the file directory in the file directory of the metadata management DB 136 are appropriately changed (step 1411). .

If it is not applied to the existing directory file in step 1410, or after step 1411, the user is prompted to perform an authority-related operation and checked (step 1412).
When the authority-related operation is performed, the authority-related operation described later with reference to FIG. 16 is performed (step 1413).
If the authority-related operation is not performed in step 1412, or after step 1413, the user is asked to input whether or not to perform the metadata assignment rule-related operation, and the check is performed (step 1414). Return to step 1401. In the case of the end, the processing of the metadata assignment rule related operation is finished as it is.

FIG. 15 is a flowchart of an outline of processing relating to metadata-related operations in step 1308 of FIG.
First, if the user's metadata operation target is a file directory, a user, or a file or directory, a URI or metadata, a user ID, etc. are input (step 1501), and metadata management is performed based on the input. The corresponding metadata group 203 or metadata group 302 is searched from the DB 136 and the result is displayed (step 1502).
Next, the user input is urged to check whether it is a new grant to which new metadata is given (step 1503).
In the case of a new grant, whether the user has the right to grant a new grant is checked using the access authority table 600 of the authority policy DB 137 and the user metadata management table 300 through the management processing unit 135. This check is almost the same as step 1102 in the flowchart relating to the processing outline of the explorer interface unit 131 in FIG. 11, but checks whether there is a meta authority, not an access type (step 1504). Although not shown in the figure, the user is prompted to select again or end, and the process is performed.
Next, the user is made to input metadata to be newly added, and it is checked whether or not the metadata can be assigned by using the access authority table 600 of the authority policy DB 137 and the user metadata management table 300 (step 1505).
If the check is not passed, although omitted in the figure, the user is prompted to select whether to prompt input again or end, and the process is performed.

If it is determined in step 1503 that the metadata is not newly assigned, the user is caused to select metadata to be changed and deleted from the metadata displayed in step 1502 (step 1506).
Next, whether or not it has the authority to change and delete is determined by checking the authority management table 400 of the metadata of the file directory of the metadata management DB 136 or the authority management table 500 of the user metadata and the user metadata management table 300. Use to check.
Whether this is included in the authority user metadata of the user to be changed or deleted in the authority management table 400 of the metadata of the file directory corresponding to the metadata to be changed or deleted, or the authority management table 500 of the user metadata. Check if. If the check is not passed, although omitted in the figure, the user is prompted to select whether to prompt input again or end, and the process is performed.
After step 1507, the user inputs whether to change or add metadata, and checks the result (step 1508). In the case of a change, the user makes input after the change, and checks whether or not the metadata after the change can be added in the same manner as in the previous step 1505 (step 1509). When deleting metadata, nothing is done.
After step 1505 in the case of new addition of metadata, or after step 1509 in the case of change of metadata, or after step 1508 in the case of deletion of metadata, the influence of the new addition of metadata and the change deletion is described. It is displayed (step 1510). This displays the URI to be changed before and after the new addition of metadata, the change of the metadata, the metadata, and the related authority, almost the same as in step 1404 of the metadata assignment rule related operation.

Thereafter, in the same manner as in step 1408 of the metadata assignment rule-related operation, the user is caused to input whether or not new assignment / change deletion of metadata is actually executed, and the result is checked (step 1511).
In the case of executing in step 1511, new addition / change deletion of metadata is reflected in the metadata management table 200 of the file directory of the metadata management DB 136 or the metadata management table 300 of the user (step 1512).
Next, the user is caused to determine whether or not the authority-related operation is performed, and the result is checked (step 1513). When performing the authority related operation, the authority related operation described later is processed (step 1514).
After step 1514, if no authority management operation is performed in step 1513, or if reflection to the metadata management DB is not performed in step 1511, the user determines whether to end without performing other metadata related operations. The result is checked (step 1515).
If it is determined to end, the process ends as it is. If not, the process returns to step 1501.

FIG. 16 is a flowchart of a process outline regarding the authority-related operation in step 1308 of FIG.
The user is prompted to check whether a new authority is added (step 1601).
If it is a new addition, the user is allowed to input the authority (step 1602). At the time of this input, the authority to change and delete this authority is also input.
When inputting the rule, the search process in step 1303 in FIG. 13 may be used or applied to add a file directory or a user search process to assist input.
Next, it is checked whether or not the authority can be added through the management processing unit 135 (step 1603). This check is almost the same as step 1102 in the flowchart relating to the processing outline of the explorer interface unit 131 in FIG. 11, but it checks whether there is a setsecurity authority instead of an access type, and a meta that is used for newly adding authority. Check whether the data is included in the available metadata 605. If the check is not passed, although omitted in the figure, the user is prompted to select whether to prompt input again or end, and the process is performed.

If it is determined in step 1601 that there is no new addition, the user is made to search for a rule to be changed and deleted using the access authority table 600 of the authority policy DB 137 (step 1605).
Then, whether or not there is an authority to change and delete the selected authority is checked using the access authority setting authority table 700 and the user metadata management table 500. This check checks whether one of the metadata groups listed in the authority user metadata 702 of the rule to be changed is included in the user metadata group 302 (step 1606).
Next, the user is allowed to select authority change or authority deletion, and the result is checked (step 1607). In the case of a change, the process proceeds to step 1602 for adding a new item, and in the same manner as in the case of adding a new item, the added rule authority check in step 1603 is performed for the changed rule.
After step 1603 or when the authority is deleted in step 1607, the URI, the metadata group before and after the addition / deletion of the rule, the access authority for the file or directory affected by the addition / deletion of the authority The metadata of the user who has is displayed (step 1604). These are basically the same as step 1404 of the processing related to the metadata providing rule-related operation shown in FIG.

Next, the user is made to determine whether to execute addition / change / deletion of authority, and the result is checked (step 1608).
In the case of executing in step 1608, the change of authority is reflected in the access authority table 600 of the authority policy DB 137 as addition / deletion of authority. Further, in the case of adding an authority, the user's metadata group having the authority to change or delete the authority is input by the user and reflected in the access authority setting authority table 700 (step 1609).
Here, regarding the latter, it is possible to set a metadata group of a user who has added a rule by default, and to perform additional correction on the metadata group.
Next, the user determines whether or not to perform an operation related to the metadata assignment rule, checks the result (step 1610), and performs the operation related to the metadata assignment rule. Processing related to the data addition rule-related operation is performed (step 1611).

Further, the user determines whether or not to perform the metadata related operation, checks the result (step 1612), and when performing the metadata related operation, it is related to the metadata related operation described above with reference to FIG. (Step 1613).
After step 1613, if the metadata-related operation is not performed in step 1612, or if it is not performed in step 1608, the user determines whether to end without performing any other authority-related operation and checks the result. (Step 1614). If it is determined to end, the process ends as it is. If not, the process returns to step 1601.

1 is a system configuration diagram showing an embodiment of a file management system according to the present invention. It is a figure which shows the structural example of the metadata management table of a file directory. It is a figure which shows the structural example of a user's metadata management table. It is a figure which shows the example of a permission management table structure of the metadata of a file directory. It is a figure which shows the example of an authority management table structure of a user's metadata. It is a figure which shows the structural example of an access authority table. It is a figure which shows the structural example of an access authority setting authority table. It is a figure which shows the structural example of a metadata provision rule table. It is a figure which shows the structural example of a provision rule setting authority table. It is a flowchart regarding the process outline | summary at the time of system introduction. It is a flowchart regarding the process outline | summary of the interface part 131 for explorers. 12 is a flowchart regarding details of metadata-related processing in step 1104 in FIG. 11. 10 is a flowchart relating to a processing outline of the extended operation interface unit 132; It is a flowchart of the process outline | summary regarding the metadata provision rule related operation of step 1306 of FIG. It is a flowchart of the process outline | summary regarding the metadata relevant operation of step 1308 of FIG. It is a flowchart of the process outline | summary regarding the authority related operation of step 1309 of FIG.

Explanation of symbols

100: Client PC
101 ... Explorer 102 ... Client software 110 ... Directory server 120 ... Existing file server group 121 ... Existing file server A
122 ... Existing file server B
DESCRIPTION OF SYMBOLS 130 ... File server integrated management proxy 131 ... Explorer interface part 132 ... Extended operation interface part 133 ... Metadata processing part 134 ... Metadata search processing part 135 ... Management processing part 136 ... Metadata management DB
137 ... Authority policy DB
138 ... Metadata giving rule group 139 ... Crawl process rule part 140 ... Interface part for file server 141 ... Crawl process part

Claims (2)

  A proxy server is placed in front of the existing file server, and this proxy server manages the file metadata in the existing file server, the relationship between the metadata and directory of each file, the relationship between the user and metadata, and the access authority based on the metadata. A file management method based on file metadata in an existing file server, characterized in that it is configured to execute a process to execute.   A proxy server having means for executing processing for managing file metadata in an existing file server, a relationship between metadata and a directory of each file, a relationship between a user and metadata, and access authority by the metadata is provided. A file management system based on file metadata in an existing file server.

Images