JP2010079444A

JP2010079444A - File management method and system by metadata

Info

Publication number: JP2010079444A
Application number: JP2008244782A
Authority: JP
Inventors: Hideaki Saijo; 秀明才所
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 2008-09-24
Filing date: 2008-09-24
Publication date: 2010-04-08

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.

しかし、従来の文書管理システムでは、電子文書ファイルを、独自のリポジトリもしくは特定のリポジトリ製品に配置することが前提である（非特許文献３、非特許文献４）。既存のファイルサーバにある電子文書ファイルを移すモジュールはあるものの、基本的に既存のファイルサーバを、既存の電子文書ファイルを含めて、そのまま利用することは出来ない。従って、多数の電子文書ファイルが存在する場合、移行や登録のコストがある。
また、従来の文書管理システムでは、独自のクライアントソフトウェアもしくはブラウザ経由で電子文書ファイルを操作することが前提の場合が多い（非特許文献５）。一般的なユーザは、ファイルの保管やアクセスなど従来行っていた作業については、Exploreのような従来のＵＩ(ユーザインタフェース)に慣れているため、使い勝手が問題である。
さらに、一部の電子文書ファイルのみを文書管理システムに移行するスモールスタートは可能であるが、全ての電子文書ファイルに対し、一部のユーザのみ対象とするようなスモールスタートは出来ない。
このため、従来の文書管理システムは、法律や規格などにより厳密な管理が必要とされる特定の電子文書ファイルにしか適用されず、組織内の多くの電子文書ファイルは旧来のファイルサーバで管理されている。 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.htmDocumentumhttp: //www.emc.com/products/family/documentum-family.htm DocumentBrokerhttp://www.hitachi.co.jp/Prod/comp/soft1/docbro/DocumentBrokerhttp: //www.hitachi.co.jp/Prod/comp/soft1/docbro/ Documentum Content Serverhttp://www.japan.emc.com/products/detail/software/content-server.htmDocumentum Content Server http://www.japan.emc.com/products/detail/software/content-server.htm DocumentBroker Version 3 機能概要と対応する製品http://www.hitachi.co.jp/Prod/comp/soft1/docbro/info/function/prod.html#func_outlineDocumentBroker Version 3 Function Overview and Supported Products http://www.hitachi.co.jp/Prod/comp/soft1/docbro/info/function/prod.html#func_outline ECM製品の基本的な仕組みhttp://www.insightnow.jp/article/1347Basic structure of ECM products http://www.insightnow.jp/article/1347 FAST ESPhttp://www.fastsearch.co.jp/download/data/ESP_Sheet_9ydA9.pdfFAST ESPhttp: //www.fastsearch.co.jp/download/data/ESP_Sheet_9ydA9.pdf Varonis DatAdvantage http://www.nox.co.jp/products/storage/varonis/index.shtmlVaronis 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/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.

一方、図１の権限ポリシーＤＢ１３７は、図６に示すアクセス権限テーブル６００と、図７に示すアクセス権限設定権限テーブル７００で構成される。
図６のアクセス権限テーブル６００は、アクセス権限の識別子である権限ＩＤ６０１と、アクセス権限を設定する対象の種別を示す対象種別６０２、アクセス権限を設定する対象のメタデータを示す対象メタデータ６０３、与える権限を示す権限６０４、メタデータの追加や追加ルールを設定する権限を設定する場合に利用できるメタデータである利用可能メタデータ６０５、アクセス権限を持つユーザのメタデータを示す権限者メタデータ６０５で構成される。
ここで、対象種別６０２には、ファイルを示す「Ｆ」、ディレクトリを示す「Ｄ」、ユーザを示す「Ｕ」の組み合わせを設定する。権限には、通常のファイルサーバのファイルやディレクトリで設定可能な権限（readやwriteなど）に加え、メタデータを追加できる権限であるaddmeta権限や、ディレクトリに対してメタデータ付与ルールを設定できるsetrule権限、アクセス権限を追加できるsetsecurity権限を設定する。
利用可能メタデータ６０５には、addmeta権限やsetrule権限、setsecurity権限で利用可能なメタデータを設定する。また、権限ＩＤが００００８の行のように、制限を行うための「！」表現も可能とする。
例えば、この行では、［｛部署：営業部｝｛セキュリティ：部外秘｝］のメタデータを持つファイルやディレクトリは、［！｛部署：営業部｝］が意味する「｛部署：営業部｝」メタデータを持たないユーザに対し、全ての権限を許可しないという権限「！＊」が設定されている。これにより、部外秘のデータを部外のユーザにアクセスさせないように設定可能とする。 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.

図１１は、一般的なユーザが、本発明のシステムを通してエクスプローラ１０１でファイルやディレクトリの操作を行う場合のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートである。
一般的なユーザは通常のファイルサーバと同様に、本システムのプロキシ１３０にアクセスを行う。その際、エクスプローラ用インタフェース部１３１は、ユーザＩＤとアクセス先のパス、アクセスの種類を確認する（ステップ１１０１）。この確認は、通常のファイルサーバで行われているログイン処理やディレクトリサーバとの連携など、既存技術のものを利用する。
次に、エクスプローラ用インタフェース部１３１は、ユーザＩＤ及びアクセス先のパスから、メタデータ検索処理部１３４を通して、メタデータ管理ＤＢ１３６上にあるメタデータを取得する。具体的には、アクセス先のパスから、図２に示したファイルディレクトリのメタデータ管理テーブル２００をＵＲＩ２０２で検索し、そのＵＲＩに付与されたメタデータ群を取得する。また、ユーザＩＤから、ユーザのメタデータの権限管理テーブル３００をユーザＩＤ３０１で検索し、そのユーザに付与されたメタデータ群３０２を取得する。
例えば、ユーザＩＤが１０００００１であるユーザが、「\\server1\営業部\X社\見積書．doc」というパスにあるファイルにアクセスする場合には、図２及び図３について、各々１行目にあるメタデータ群を取得する。 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.

次に、エクスプローラ用インタフェース部１３１は、管理用処理部１３５を通して権限ポリシーＤＢ１３７を検索し、アクセス権限チェックを行う（ステップ１１０２）。具体的には、ファイルかディレクトリかの対象種別６０２、対象メタデータ６０３、権限６０４、権限者メタデータ６０６で検索を行い、ステップ１１０１で取得したメタデータ及びアクセス種類が含まれる行をチェックする。
例えば、ユーザＩＤが１０００００１であるユーザが、「\\server1\営業部\X社\見積書．doc」というパスにあるファイルに対し、readアクセスする場合を例にすると、ステップ１で得られた図３の１行目のメタデータ群は、図６の１行目の対象メタデータを含んでおり、ステップ１で得られた図２の１行目のメタデータ群は、図６の１行目の権限者メタデータを含んでおり、対象種別はファイルの「Ｆ」が設定されており、さらに権限にreadが含まれている。従って、この行においては、チェックが許可される。 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.

図１２は、エクスプローラ用インタフェース部１３１が管理用処理部１３５を通して行う図１１のメタデータ関連処理の詳細に関するフローチャートである。
エクスプローラ用インタフェース部１３１は、ステップ１１０１で得たアクセスの種類から、ファイルやディレクトリの新規作成かどうかをチェックする（ステップ１２０１）。新規作成の場合は、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータ管理テーブル２００に、そのパスをＵＲＩとして、新たな行を登録する。
また、メタデータ付与ルール群１３８のメタデータ付与ルールテーブル８００をチェックし、そのルールに基づいたメタデータを、適用したルールのルールＩＤとともに、メタデータ管理テーブル２００の追加した行に登録する。
また、付与ルール設定権限テーブル９００から適用したルールの権限ユーザメタデータを、ファイルディレクトリのメタデータ権限管理テーブル４００の対応する部分にコピーする（ステップ１２０２）。
例えば、「\\server1\営業部\」以下に新規作成した場合には、図８のルールＩＤの００００１から００００３などが適用され、各々のルールに示されたメタデータを付与する。 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.

図１３は、拡張操作インタフェース部１３２の処理概要に関するフローチャートである。
まず、ユーザのログイン認証を行い、認証とともにユーザＩＤを取得する（ステップ１３０１）。これは、認証自体やユーザＩＤの取得は、ディレクトリサーバ１１０と連携するなど、既存の技術を利用する。
次に、ユーザが利用する操作を入力すると、拡張操作インタフェース部１３２は、その操作に応じて処理を行う。
まず、メタデータの検索操作かどうかをチェックし（ステップ１３０２）する。メタデータの検索操作であった場合は、ユーザに検索するメタデータを入力させ、メタデータ検索処理部１３４を用いて、メタデータ管理ＤＢ１３６を検索し、対応するＵＲＩをクライアントソフト１０２に表示する（ステップ１３０３）。この検索の際には、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２と同様にチェックし、少なくともreadのアクセス権限のあるものだけを表示させる。この表示においては、同時にアクセス権限を表示しても良いし、権限の無いものもアクセス権限が無いことと同時に表示する機能を追加しても良い。
メタデータ管理ＤＢ１３６からメタデータを用いて検索する以外は、既存の検索システムの技術を利用しても良い。
続けてメタデータ関連操作を行うかどうかをユーザに入力させ、そのチェックを行い（ステップ１３０４）、終了で無い場合は、ステップ１３０２に戻る。終了の場合は、そのまま拡張操作インタフェース部１３２の処理を終える。
以下同じ要領で、操作の種類のチェック（ステップ１３０５、ステップ１３０７）を行い、後で説明する対応した操作の処理を行う（ステップ１３０６、ステップ１３０８、ステップ１３０９）。その後は、ステップ１３０３の処理後と同じである。 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.

図１４は、図１３のステップ１３０６のメタデータ付与ルール関連操作に関する処理概要のフローチャートである。
拡張操作インタフェース部１３２は、ユーザの入力を促し、メタデータ付与ルールの追加する新規追加かどうかをチェックする（ステップ１４０１）。
新規追加であった場合は、ユーザにそのルールを入力させる（ステップ１４０２）。この入力の際には、このルールの変更削除権限も入力させる。このルール入力時に、図１３のステップ１３０３にある検索処理を利用し、もしくは応用してファイルディレクトリやユーザの検索処理を追加し、入力補助をしても良い。
次に、管理用処理部１３５を通して、そのルールを追加してよいかどうかをチェックする（ステップ１４０３）。このチェックは、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、setrule権限があるかどうかをチェックし、そのルールで付与しようとしているメタデータが利用可能メタデータ６０５に含まれているかどうかをチェックする。チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。 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.

図１５は、図１３のステップ１３０８のメタデータ関連操作に関する処理概要のフローチャートである。
まず、ユーザのメタデータを操作する対象がファイルディレクトリか、ユーザか、ファイルやディレクトリの場合は、ＵＲＩもしくはメタデータ、ユーザＩＤなどを入力させ（ステップ１５０１）、その入力を元に、メタデータ管理ＤＢ１３６から対応するメタデータ群２０３もしくはメタデータ群３０２を検索し、その結果を表示する（ステップ１５０２）。
次にユーザの入力を促し、新たなメタデータの付与する新規付与かどうかをチェックする（ステップ１５０３）。
新規付与の場合は、新規付与できる権限を持つかどうかを、管理用処理部１３５を通して、権限ポリシーＤＢ１３７のアクセス権限テーブル６００と、ユーザのメタデータ管理テーブル３００を用いてチェックする。このチェックは、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、meta権限があるかどうかをチェックする（ステップ１５０４）。図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
次に、新規付与するメタデータをユーザに入力させ、権限ポリシーＤＢ１３７のアクセス権限テーブル６００と、ユーザのメタデータ管理テーブル３００を用いて、そのメタデータが付与可能かチェックする（ステップ１５０５）。
チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。 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.

図１６は、図１３のステップ１３０８の権限関連操作に関する処理概要のフローチャートである。
ユーザの入力を促し、新しい権限の追加かどうかをチェックする（ステップ１６０１）。
新規追加であった場合は、ユーザにその権限を入力させる（ステップ１６０２）。この入力の際には、この権限の変更削除権限も入力させる。
このルール入力時に、図１３のステップ１３０３にある検索処理を利用し、もしくは応用してファイルディレクトリやユーザの検索処理を追加し、入力補助をしても良い。
次に、管理用処理部１３５を通して、その権限を追加してよいかどうかをチェックする（ステップ１６０３）。このチェックは図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、setsecurity権限があるかどうかをチェックし、新規追加する権限に利用するメタデータが利用可能メタデータ６０５に含まれているかどうかをチェックする。チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。 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

既存ファイルサーバのフロントにプロキシサーバを配置し、このプロキシサーバが既存ファイルサーバにおけるファイルのメタデータ、各ファイルのメタデータとディレクトリの関係、ユーザとメタデータとの関係、メタデータによるアクセス権限を管理する処理を実行するように構成したことを特徴とする既存ファイルサーバにおけるファイルのメタデータによるファイル管理方法。 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.