(57)【要約】【課題】  既存の電子文書ファイルに極力手を加えず、それらを移行すること無しに、電子文書ファイルのメタデータによる管理を実現する。【解決手段】  既存のファイルサーバのフロントにプロキシとして動作するサーバを配し、そのプロキシサーバで既存ファイルサーバ上のファイルやディレクトリとメタデータのとの関係、ユーザとメタデータの関係、メタデータによるアクセス権限管理を行う。さらにそれぞれの追加修正変更の権限管理もメタデータによって行う。【選択図】      図１
2010079444.tif 000002
【特許請求の範囲】
【請求項１】
既存ファイルサーバのフロントにプロキシサーバを配置し、このプロキシサーバが既存ファイルサーバにおけるファイルのメタデータ、各ファイルのメタデータとディレクトリの関係、ユーザとメタデータとの関係、メタデータによるアクセス権限を管理する処理を実行するように構成したことを特徴とする既存ファイルサーバにおけるファイルのメタデータによるファイル管理方法。
【請求項２】
既存ファイルサーバにおけるファイルのメタデータ、各ファイルのメタデータとディレクトリの関係、ユーザとメタデータとの関係、メタデータによるアクセス権限を管理する処理を実行する手段を備えたプロキシサーバを備えることを特徴とする既存ファイルサーバにおけるファイルのメタデータによるファイル管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、既存ファイルサーバ上のファイルやディレクトリやアクセス権限をメタデータにより管理する方法及びシステムに関する。
【背景技術】
【０００２】
現在、組織内の電子文書ファイルに対し、セキュリティ・コンプライアンスの側面から厳密なアクセス権限管理や情報漏えい対策、ライフサイクル管理が重要視されている。
一方で、知識の共有による効率化のために検索や情報共有も重要視されている。また、大量の電子文書ファイルが存在するため、その管理においては、個別のファイルやディレクトリ、ユーザごとではなく、メタデータを用いた効率化した管理が望まれ、様々なシステムや製品が存在する。
アクセス権限管理やライフサイクル管理などに対しては、文書管理システムと呼ばれる分野の製品が存在する（非特許文献１、非特許文献２）。これらの文書管理システムでは、電子文書ファイルをメタデータで管理することができ、アクセス権限管理やライフサイクル管理、メタデータによる検索に加え、版管理、ワークフローなどの機能が存在するものもある。
【０００３】
しかし、従来の文書管理システムでは、電子文書ファイルを、独自のリポジトリもしくは特定のリポジトリ製品に配置することが前提である（非特許文献３、非特許文献４）。既存のファイルサーバにある電子文書ファイルを移すモジュールはあるものの、基本的に既存のファイルサーバを、既存の電子文書ファイルを含めて、そのまま利用することは出来ない。従って、多数の電子文書ファイルが存在する場合、移行や登録のコストがある。
また、従来の文書管理システムでは、独自のクライアントソフトウェアもしくはブラウザ経由で電子文書ファイルを操作することが前提の場合が多い（非特許文献５）。一般的なユーザは、ファイルの保管やアクセスなど従来行っていた作業については、Exploreのような従来のＵＩ(ユーザインタフェース)に慣れているため、使い勝手が問題である。
さらに、一部の電子文書ファイルのみを文書管理システムに移行するスモールスタートは可能であるが、全ての電子文書ファイルに対し、一部のユーザのみ対象とするようなスモールスタートは出来ない。
このため、従来の文書管理システムは、法律や規格などにより厳密な管理が必要とされる特定の電子文書ファイルにしか適用されず、組織内の多くの電子文書ファイルは旧来のファイルサーバで管理されている。
【０００４】
一方、検索に特化したエンタープライズサーチ分野の製品は、既存のファイルサーバに対しメタデータ検索を含めて、高速に柔軟に検索できるようにする（非特許文献６）。しかし、検索結果に対するコントロールは可能であるが、実際の電子文書ファイルに対するアクセス制御は対象外であり、組織内の電子文書ライフサイクルの管理に利用することは出来ない。
また、ファイルサーバのアクセス権限管理やライフサイクル管理の一部の機能を持つ製品も存在する（非特許文献７）。しかし、基本的にチェックやレポート機能のみに限られ、アクセス権限管理やライフサイクル管理の全てをカバーするものではない。
また、ＷＡＦＳ（非特許文献７）は、高速化のためのキャッシュのみを行うものであり、アクセス権限管理やライフサイクル管理などに利用することは出来ない。
【０００５】
【非特許文献１】Documentumhttp://www.emc.com/products/family/documentum-family.htm
【非特許文献２】DocumentBrokerhttp://www.hitachi.co.jp/Prod/comp/soft1/docbro/
【非特許文献３】Documentum Content Serverhttp://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_outline
【非特許文献５】ECM製品の基本的な仕組み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/
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は前述のような従来技術の問題点に鑑み、既存のファイルサーバに対し、既存の電子文書ファイルに極力手を加えず、それらを移行すること無しに、電子文書ファイルのメタデータによるファイル管理、アクセス権限管理を実現することが可能な既存ファイルサーバにおけるメタデータによるファイル管理方法及びシステムを提供することにある。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明に係る既存ファイルサーバにおけるメタデータによるファイル管理方法は、既存ファイルサーバのフロントにプロキシサーバを配置し、このプロキシサーバが既存ファイルサーバにおけるファイルのメタデータ、各ファイルのメタデータとディレクトリの関係、ユーザとメタデータとの関係、メタデータによるアクセス権限を管理する処理を実行するように構成したことを特徴とする。
また、本発明に係る既存ファイルサーバにおけるメタデータによるファイル管理システムは、既存ファイルサーバにおけるファイルのメタデータ、各ファイルのメタデータとディレクトリの関係、ユーザとメタデータとの関係、メタデータによるアクセス権限を管理する処理を実行する手段を備えたプロキシサーバを備えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、既存のファイルサーバへの変更を最小限に抑え、初期コストを抑えた上で、既存のファイルサーバに対し、電子文書ファイルのメタデータによる管理及びメタデータを用いたアクセス権限管理を実現することができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。
図１に本発明の実施の携帯を示すシステム構成図を示す。
本実施形態のシステムは、クライアントＰＣ１００と、ディレクトリサーバ１１０、既存ファイルサーバ群１２０、ファイルサーバ統合管理プロキシ１３０で構成される。
クライアントＰＣ１００には、ローカルもしくは既存ファイルサーバ上のディレクトリやファイルを操作するためのエクスプローラ１０１と、本発明のシステムのＵＩ（ユーザインタフェース）となるクライアントソフト１０２などから構成される。
ここで、クライアントソフト１０２は、専用のクライアントソフトでも良いし、既存のＷｅｂブラウザなどを利用しても良い。専用のクライアントソフトを除けば、既存の技術である。
ディレクトリサーバ１１０は、既存の技術であり、ユーザのＩＤ・パスワードや、職制などの一部の属性情報を管理し、また、ユーザ認証の代行を行うものである。本実施形態では、既存のディレクトリサーバを用いているが、ディレクトリサーバ１１０と同等の情報を管理し、ユーザ認証を行う機能を、ファイルサーバ統合管理プロキシ１３０内に配置しても良い。
既存ファイルサーバ群１２０は、企業など各種の組織などで既に利用されているファイルサーバであり、ディレクトリやファイルが既に配置されているものである。
【００１０】
ファイルサーバ統合管理プロキシ１３０は、本発明のシステムの中枢となるものであり、クライアントソフト１０２に専用のクライアントソフト利用しない場合においては、唯一新たに導入するものである。
ファイルサーバ統合管理プロキシ１３０は、エクスプローラ用インタフェース部１３１、拡張操作インタフェース部１３２、メタデータ処理部１３３、メタデータ検索処理部１３４、管理用処理部１３５、メタデータ管理ＤＢ１３６、権限ポリシーＤＢ１３７、メタデータ付与ルール群１３８、クロール処理ルール群１３９、ファイルサーバ用インタフェース部１４０、クロール処理部１４１で構成される。
【００１１】
エクスプローラ用インタフェース部１３１は、クライアントＰＣ１００上のエクスプローラ１０１と通信を行い、クライアントＰＣユーザに、既存のファイルサーバを利用しているのと同等のＵＩを提供しつつ、その処理を行うものである。具体的な例としては、ディレクトリやファイルの参照・作成・削除である。
拡張操作インタフェース部１３２は、クライアントソフト１０２と通信を行い、既存のファイルサーバには存在しない機能である、メタデータによる検索や、後に説明するメタデータの追加修正などを行うものである。クライアントＰＣユーザは、クライアントソフト１０２を通して、拡張操作インタフェース部１３２で、これらの機能を実行する。
メタデータ処理部１３３は、エクスプローラ用インタフェース部１３１の処理において、メタデータ付与ルール群１３８、権限ポリシーＤＢ１３７を利用し、メタデータ管理ＤＢ１３６で管理されているメタデータの処理を行うものである。
メタデータ検索処理部１３４は、拡張操作インタフェース部１３２の処理において、権限ポリシーＤＢ１３７を利用し、メタデータ管理ＤＢ１３６からメタデータ検索を行うものである。
管理用処理部１３５は、権限ポリシーＤＢ１３７を利用し、権限ポリシーＤＢ１３７自身や、メタデータ管理ＤＢ１３６、メタデータ付与ルール群１３８、クロール処理ルール群１３９に追加修正の処理を行うものである。
メタデータ管理ＤＢ１３６は、図２に示すファイルディレクトリのメタデータ管理テーブル２００と、図３に示すユーザのメタデータ管理テーブル３００、図４に示すファイルディレクトリのメタデータ権限テーブル４００、図５に示すユーザのメタデータ権限テーブル５００で構成される。
【００１２】
図２のファイルディレクトリのメタデータ管理テーブル２００は、項目番号であるＩＤ２０１と、ファイルディレクトリのパス情報であるＵＲＩ２０２、各々のＵＲＩにつけられたメタデータ群２０３で構成される。
メタデータ群２０３は、メタデータＩＤ２０４で管理された複数のメタデータで構成される。
ここで、以降の記述を含めて、本実施例では、メタデータはメタデータの分類２０５とメタデータの内容２０６を「：」で区切り、「｛｝」でまとめた形式とする。また、ＩＤが００００１の列に見られるように、一つのＵＲＩに対し、同じメタデータの分類に対し、複数のメタデータの内容も登録できるものとする。ただし、メタデータ形式や仕様は、他の既存のものでも良い。
【００１３】
図３のユーザのメタデータ管理テーブル３００は、ユーザの識別子であるユーザＩＤ３０１と、各々のユーザに付けられたメタデータ群３０２で構成される。メタデータ群３０２は、ファイルディレクトリのメタデータ管理テーブル２００と同様に、メタデータＩＤで管理された複数のメタデータで構成される。
ここで、本実施形態では、ディレクトリサーバ１１０と連携を前提としているため、ユーザＩＤ３０１はディレクトリサーバ１１０に管理されているものと同期したものである。
【００１４】
図４のファイルディレクトリのメタデータ権限テーブル４００は、ファイルディレクトリのメタデータ管理テーブル２００の対応するＩＤ２０１を示すＩＤ４０１と、対応するメタデータ群２０３のメタデータＩＤ２０４を示すメタデータＩＤ４０２、このメタデータの変更削除権限を持つユーザのメタデータ示す権限ユーザメタデータ４０３、メタデータ付与ルールで設定された場合にそのルールＩＤを示すルールＩＤ４０４で構成される。
権限ユーザメタデータ４０３には、複数のメタデータを組み合わせたメタデータグループを指定でき、さらにそのメタデータグループも複数指定できる。例えば、このテーブルの１行目は、図２の１行目に存在するメタデータＩＤが００１のメタデータ「｛部署：営業部｝」は、［｛部署：営業部｝｛職種：部長｝］というメタデータグループを持つユーザか、もしくは［｛部署：営業部｝｛職種：部長｝］というメタデータグループを持つユーザが変更削除可能という意味である。
【００１５】
図５のユーザのメタデータ権限テーブル５００は、ユーザのメタデータ管理テーブル３００の対応するユーザＩＤ３０１を示すユーザＩＤ４０１と、対応するメタデータ群３０２のメタデータＩＤを示すメタデータＩＤ５０１、このメタデータの変更削除権限を持つユーザのメタデータ示す権限ユーザメタデータ５０３で構成される。意味は、ファイルディレクトリのメタデータ管理テーブル２００と、ファイルディレクトリのメタデータ権限テーブル４００の関係と同じである。
【００１６】
一方、図１の権限ポリシーＤＢ１３７は、図６に示すアクセス権限テーブル６００と、図７に示すアクセス権限設定権限テーブル７００で構成される。
図６のアクセス権限テーブル６００は、アクセス権限の識別子である権限ＩＤ６０１と、アクセス権限を設定する対象の種別を示す対象種別６０２、アクセス権限を設定する対象のメタデータを示す対象メタデータ６０３、与える権限を示す権限６０４、メタデータの追加や追加ルールを設定する権限を設定する場合に利用できるメタデータである利用可能メタデータ６０５、アクセス権限を持つユーザのメタデータを示す権限者メタデータ６０５で構成される。
ここで、対象種別６０２には、ファイルを示す「Ｆ」、ディレクトリを示す「Ｄ」、ユーザを示す「Ｕ」の組み合わせを設定する。権限には、通常のファイルサーバのファイルやディレクトリで設定可能な権限（readやwriteなど）に加え、メタデータを追加できる権限であるaddmeta権限や、ディレクトリに対してメタデータ付与ルールを設定できるsetrule権限、アクセス権限を追加できるsetsecurity権限を設定する。
利用可能メタデータ６０５には、addmeta権限やsetrule権限、setsecurity権限で利用可能なメタデータを設定する。また、権限ＩＤが００００８の行のように、制限を行うための「！」表現も可能とする。
例えば、この行では、［｛部署：営業部｝｛セキュリティ：部外秘｝］のメタデータを持つファイルやディレクトリは、［！｛部署：営業部｝］が意味する「｛部署：営業部｝」メタデータを持たないユーザに対し、全ての権限を許可しないという権限「！＊」が設定されている。これにより、部外秘のデータを部外のユーザにアクセスさせないように設定可能とする。
【００１７】
図７のアクセス権限設定権限テーブル７００は、アクセス権限テーブル６００の対応する権限ＩＤ６０１を示す権限ＩＤ７０１と、このメタデータの変更削除できる権限を持つユーザのメタデータ示す権限ユーザメタデータ７０２で構成される。
権限ユーザメタデータ７０２には、図４のファイルディレクトリのメタデータ権限テーブル４００や図５のユーザのメタデータ権限テーブル５００と同様に、複数のメタデータを組み合わせたメタデータグループを指定でき、さらにそのメタデータグループも複数指定できる。
例えば、このテーブルの１行目は、図６の権限ＩＤが００００１の行は、［｛部署：システム管理部｝｛職種：主任｝］というメタデータグループを持つユーザか、もしくは［｛部署：システム管理部｝｛職種：ファイルサーバ担当｝］というメタデータグループを持つユーザが変更削除可能という意味である。
【００１８】
メタデータ付与ルール群１３８は、図８に示すメタデータ付与ルールテーブル８００と、付与ルール設定権限テーブル９００で構成される。
図８のメタデータ付与ルールテーブル８００は、ルールの識別子となるルールＩＤ８０１と、そのルール自体である付与ルール８０２で構成される。
ルールには、どのタイミングで、メタデータに対して何をどのように追加修正するかを記述する。図８のルールはあくまで例であるが、例えばルールＩＤが００００１の行は、アクセスした際にアクセスした日とアクセスしたユーザの情報のメタデータを変更するルールである。
また、ルールＩＤが００００２の行は、ファイルをファイルサーバに新たに置いた時に、作成者のメタデータを追加するルールである。また、図では示さないが、このルールにおいて外部のサブシステムを通してメタデータの付与や変更も出来るものとする。
【００１９】
図９の付与ルール設定権限テーブル９００は、メタデータ付与ルールテーブル８００の対応するルールＩＤ８０１を示す権限ＩＤ９０１と、このメタデータの変更削除権限を持つユーザのメタデータ示す権限ユーザメタデータ９０２で構成される。
権限ユーザメタデータ７０２には、図４のファイルディレクトリのメタデータ権限テーブル４００や図５のユーザのメタデータ権限テーブル５００と同様に、複数のメタデータを組み合わせたメタデータグループを指定でき、さらにそのメタデータグループも複数指定できる。
例えば、このテーブルの１行目は、図８のルールＩＤが００００１の行は、［｛部署：システム管理部｝｛職種：主任｝］というメタデータグループを持つユーザか、もしくは［｛部署：システム管理部｝｛職種：ファイルサーバ担当｝］というメタデータグループを持つユーザが変更削除可能という意味である。
【００２０】
一方、図１のファイルサーバ用インタフェース部１４０は、既存ファイルサーバ群１２０と通信を行い、エクスプローラ用インタフェース部１３１の処理において、既存ファイルサーバ群１２０にあるファイルやディレクトリの操作処理を行うものである。
クロール処理部１４１は、クロール処理ルール群１３９のルールもしくは導入時などの管理者の操作によって、ファイルサーバ用インタフェース部１４０を通して、既存ファイルサーバ群１２０に対しクロール処理を行うものである。クロール処理ルール群１３９の詳細については省略するが、例えば即時１回、もしくは定期的に、メタデータ付与ルール群にあるメタデータ付与ルールに沿ったメタデータ付与処理を行うルールなどである。このルールは、初期導入時や本発明のシステム外からのアクセスによりファイルサーバに配置されたファイルへの対処に利用する。
【００２１】
図１０は、本発明のシステム導入時の処理概要に関するフローチャートである。
システム導入者は、対象とする既存のファイルサーバ群１２０と、連携するディレクトリサーバ１１０を指定する（ステップ１００１）。
次に、導入時の初期設定のポリシーを設定する。この中では、例えばメタデータ付与ルールテーブル８００や、そのルールに対応する付与ルール設定権限テーブル９００の設定を行う。後者については、デフォルトで［｛部署：システム管理部｝｛職種：ファイルサーバ担当｝］などとしてしまっても良い。また、ユーザにおいては、ディレクトリサーバ１１０から抽出するサブシステムなどを利用し、各ユーザに付与するメタデータの指定を行う。それ以外にも、権限ポリシーＤＢ１３７などの初期設定も行う。
次に、メタデータ管理ＤＢ１３６の初期設定を行う（ステップ１００３）。これは、クロール処理部１４１を用いて、メタデータ付与ルール群１３８にあるルールに基づき、ファイルやディレクトリのメタデータを、メタデータＤＢ１３６に登録する。この際には、適用されないルールがあっても良い。この際適用されるルールは、ＵＲＩに応じてメタデータが決定されるルールが基本である。
【００２２】
最後に、システム導入者が、メタデータ管理ＤＢ１３７の追加修正を中心に、権限ポリシーＤＢ１３７やメタデータ付与ルール群１３８などの追加修正を行う。この権限ポリシーＤＢ１３７の追加修正においては、既存のファイルサーバ群１２０のアクセス権限から抽出する機構を用意して利用しても良い。
以上で、本発明のシステムの既存ファイルサーバ群１２０への導入処理は終了である。
これにより、既存ファイルサーバ群１２０の停止や利用制限、ファイルやディレクトリの移動やコピーをすることなく導入できることを実現する。
【００２３】
図１１は、一般的なユーザが、本発明のシステムを通してエクスプローラ１０１でファイルやディレクトリの操作を行う場合のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートである。
一般的なユーザは通常のファイルサーバと同様に、本システムのプロキシ１３０にアクセスを行う。その際、エクスプローラ用インタフェース部１３１は、ユーザＩＤとアクセス先のパス、アクセスの種類を確認する（ステップ１１０１）。この確認は、通常のファイルサーバで行われているログイン処理やディレクトリサーバとの連携など、既存技術のものを利用する。
次に、エクスプローラ用インタフェース部１３１は、ユーザＩＤ及びアクセス先のパスから、メタデータ検索処理部１３４を通して、メタデータ管理ＤＢ１３６上にあるメタデータを取得する。具体的には、アクセス先のパスから、図２に示したファイルディレクトリのメタデータ管理テーブル２００をＵＲＩ２０２で検索し、そのＵＲＩに付与されたメタデータ群を取得する。また、ユーザＩＤから、ユーザのメタデータの権限管理テーブル３００をユーザＩＤ３０１で検索し、そのユーザに付与されたメタデータ群３０２を取得する。
例えば、ユーザＩＤが１０００００１であるユーザが、「\\server1\営業部\X社\見積書．doc」というパスにあるファイルにアクセスする場合には、図２及び図３について、各々１行目にあるメタデータ群を取得する。
【００２４】
次に、エクスプローラ用インタフェース部１３１は、管理用処理部１３５を通して権限ポリシーＤＢ１３７を検索し、アクセス権限チェックを行う（ステップ１１０２）。具体的には、ファイルかディレクトリかの対象種別６０２、対象メタデータ６０３、権限６０４、権限者メタデータ６０６で検索を行い、ステップ１１０１で取得したメタデータ及びアクセス種類が含まれる行をチェックする。
例えば、ユーザＩＤが１０００００１であるユーザが、「\\server1\営業部\X社\見積書．doc」というパスにあるファイルに対し、readアクセスする場合を例にすると、ステップ１で得られた図３の１行目のメタデータ群は、図６の１行目の対象メタデータを含んでおり、ステップ１で得られた図２の１行目のメタデータ群は、図６の１行目の権限者メタデータを含んでおり、対象種別はファイルの「Ｆ」が設定されており、さらに権限にreadが含まれている。従って、この行においては、チェックが許可される。
【００２５】
管理用処理部１３５は、上記のように権限ポリシーＤＢ１３７のアクセス権限テーブル図６の行をチェックし、アクセス許可及び不許可を判別する。
エクスプローラ用インタフェース部１３１は、ステップ１１０２でアクセス不許可と判別した場合には、通常のファイルサーバが行うのと同様のアクセス拒否をクライアントＰＣ１００のエクスプローラ１０１に返す。
一方、ステップ１１０２でアクセス許可と判別した場合には、そのアクセス操作自体について、ファイルサーバ用インタフェース部１４０を通して、既存ファイルサーバ群１２０に反映しつつ、管理用処理部１３５でメタデータ関連処理を行う（１１０６）。前者の既存ファイルサーバ群の反映は、単にエクスプローラインタフェース部１３１で受けた内容をファイルサーバ用インタフェース部１４０が既存ファイルサーバ群１２０に渡せばよい。後者のメタデータ関連処理の詳細は、次の図１２を用いて説明する。
【００２６】
図１２は、エクスプローラ用インタフェース部１３１が管理用処理部１３５を通して行う図１１のメタデータ関連処理の詳細に関するフローチャートである。
エクスプローラ用インタフェース部１３１は、ステップ１１０１で得たアクセスの種類から、ファイルやディレクトリの新規作成かどうかをチェックする（ステップ１２０１）。新規作成の場合は、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータ管理テーブル２００に、そのパスをＵＲＩとして、新たな行を登録する。
また、メタデータ付与ルール群１３８のメタデータ付与ルールテーブル８００をチェックし、そのルールに基づいたメタデータを、適用したルールのルールＩＤとともに、メタデータ管理テーブル２００の追加した行に登録する。
また、付与ルール設定権限テーブル９００から適用したルールの権限ユーザメタデータを、ファイルディレクトリのメタデータ権限管理テーブル４００の対応する部分にコピーする（ステップ１２０２）。
例えば、「\\server1\営業部\」以下に新規作成した場合には、図８のルールＩＤの００００１から００００３などが適用され、各々のルールに示されたメタデータを付与する。
【００２７】
ステップ１２０１でアクセスの種類が新規作成でない場合は、次に削除かどうかをチェックする（１２０３）。このチェックで、削除であった場合は、メタデータ管理ＤＢ１３６から、アクセス先のパスとＵＲＩが一致する行を検索し、その行を削除する（ステップ１２０４）。
ステップ１２０３で、アクセスの種類が削除で無い場合、すなわちステップ１２０１も含めてアクセスの種類が新規作成でも削除でもない場合は、メタデータ管理ＤＢ１３６から、アクセス先のパスとＵＲＩが一致する行を検索し、メタデータ付与ルール群をチェックし、そのルールに基づいたメタデータの追加修正などを行う（ステップ１２０５）。
例えば、図８のルールＩＤの００００１などが適用され、最終アクセス日やユーザＩＤのメタデータを変更する。
以上により、クライアントＰＣ１００からエクスプローラ１０１を通して、通常のファイルサーバと同様の方法でアクセスを行った場合に、メタデータの処理とメタデータを用いたアクセス権限管理、既存ファイルサーバ上での処理の全てが実現できる。
【００２８】
次に、通常のファイルサーバには存在しないメタデータ検索機能と、メタデータや権限の変更などの管理機能について説明する。これらの機能は、クライアントＰＣ１００のＵＩであるクライアントソフト１０２と、実際の処理を行う拡張操作インタフェース部１３２で実現する。
【００２９】
図１３は、拡張操作インタフェース部１３２の処理概要に関するフローチャートである。
まず、ユーザのログイン認証を行い、認証とともにユーザＩＤを取得する（ステップ１３０１）。これは、認証自体やユーザＩＤの取得は、ディレクトリサーバ１１０と連携するなど、既存の技術を利用する。
次に、ユーザが利用する操作を入力すると、拡張操作インタフェース部１３２は、その操作に応じて処理を行う。
まず、メタデータの検索操作かどうかをチェックし（ステップ１３０２）する。メタデータの検索操作であった場合は、ユーザに検索するメタデータを入力させ、メタデータ検索処理部１３４を用いて、メタデータ管理ＤＢ１３６を検索し、対応するＵＲＩをクライアントソフト１０２に表示する（ステップ１３０３）。この検索の際には、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２と同様にチェックし、少なくともreadのアクセス権限のあるものだけを表示させる。この表示においては、同時にアクセス権限を表示しても良いし、権限の無いものもアクセス権限が無いことと同時に表示する機能を追加しても良い。
メタデータ管理ＤＢ１３６からメタデータを用いて検索する以外は、既存の検索システムの技術を利用しても良い。
続けてメタデータ関連操作を行うかどうかをユーザに入力させ、そのチェックを行い（ステップ１３０４）、終了で無い場合は、ステップ１３０２に戻る。終了の場合は、そのまま拡張操作インタフェース部１３２の処理を終える。
以下同じ要領で、操作の種類のチェック（ステップ１３０５、ステップ１３０７）を行い、後で説明する対応した操作の処理を行う（ステップ１３０６、ステップ１３０８、ステップ１３０９）。その後は、ステップ１３０３の処理後と同じである。
【００３０】
図１４は、図１３のステップ１３０６のメタデータ付与ルール関連操作に関する処理概要のフローチャートである。
拡張操作インタフェース部１３２は、ユーザの入力を促し、メタデータ付与ルールの追加する新規追加かどうかをチェックする（ステップ１４０１）。
新規追加であった場合は、ユーザにそのルールを入力させる（ステップ１４０２）。この入力の際には、このルールの変更削除権限も入力させる。このルール入力時に、図１３のステップ１３０３にある検索処理を利用し、もしくは応用してファイルディレクトリやユーザの検索処理を追加し、入力補助をしても良い。
次に、管理用処理部１３５を通して、そのルールを追加してよいかどうかをチェックする（ステップ１４０３）。このチェックは、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、setrule権限があるかどうかをチェックし、そのルールで付与しようとしているメタデータが利用可能メタデータ６０５に含まれているかどうかをチェックする。チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
【００３１】
ステップ１４０１で、新規追加で無い場合は、メタデータ付与ルール群１３８のメタデータ付与ルールテーブル８００を用いて、変更削除するルールをユーザに検索させる（ステップ１４０５）。そして、選択したルールの変更削除を行う権限があるかどうかを、付与ルール設定権限テーブル９００と、ユーザのメタデータ管理テーブル５００を用いてチェックする。このチェックは、変更するルールの権限ユーザメタデータ７０２に列挙されているメタデータグループの一つが、ユーザのメタデータ群３０２に含まれるかどうかをチェックする（ステップ１４０６）。
チェックが通らなければ、図では省略するが、再度選択を促すか、終了するかをユーザに選択させ、その処理を行う。
ここで、ステップ１４０５で、メタデータ付与ルールテーブル８００の中から選択させる際に、変更削除権限のあるもののみを表示させ、ステップ１４０６を省略しても良い。
【００３２】
次に、ルールの変更かルール削除かの選択をユーザに行わせ、その結果をチェックする（ステップ１４０７）。変更の場合は、新規追加のステップ１４０２に進み、新規追加の場合と同様に、変更後のルールについてステップ１４０３の付与ルール権限チェックを行う。
ステップ１４０３の後、もしくは、ステップ１４０７においてルールの削除であった場合は、ルールの追加変更削除によって影響を受けるファイルやディレクトリについて、そのＵＲＩ、ルールの追加変更削除の前後のメタデータ群、アクセス権限を持つユーザのメタデータを表示する（ステップ１４０４）。
具体的には、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータ管理テーブル２００から、変更前のルールもしくは削除されるルールのＩＤ、変更後のルールもしくは追加されるルールのパス情報を用いて、ルールの追加変更削除の前後でメタデータが変わるファイルやディレクトリのＵＲＩと、そのファイルやディレクトリの、ルールの追加変更削除の前後のメタデータ群を検索する。
さらに、その検索結果のメタデータ群を用いて、権限ポリシーＤＢ１３７のアクセス権限テーブル６００から、ルールの追加変更削除の前後のアクセス権限を持つ権限者メタデータ６０６と、権限６０４を検索する。そして、これらの検索結果を、ルールの追加変更削除の前後で分けて表示する。
【００３３】
次に、ユーザにルールの追加変更削除を実行するかどうかを判断させ、その結果をチェックする（ステップ１４０８）。
ステップ１４０８で、実行する場合は、ルールの変更を、メタデータ付与ルール群１３８のメタデータ付与ルールテーブル８００に、ルールの追加変更削除を反映させる。
さらに、ルールの追加の場合には、そのルールの変更削除権限を持たせるユーザのメタデータ群をユーザ入力させ、それを付与ルール設定権限テーブル９００に反映させる（ステップ１４０９）。
ここで、後者については、デフォルトでルールの追加を行ったユーザのメタデータ群を設定し、それに対する追加修正を行う処理にしても良い。
ステップ１４０９の後、ルールの追加変更削除を既存のディレクトリファイルに適用するかどうかをユーザに入力させ、それをチェックする（ステップ１４１０）。適用する場合には、ステップ１４０４で表示したルールの追加変更削除後のＵＲＩとメタデータ群を、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータ管理テーブル２００に反映させる。
また、図１１のメタデータ関連処理の詳細に関するフローチャートのステップ１２０２と同様に、メタデータ管理ＤＢ１３６のファイルディレクトリにおけるメファイルディレクトリのメタデータの権限管理テーブル４００の内容を適切に変更する（ステップ１４１１）。
【００３４】
ステップ１４１０で既存のディレクトリファイルに適用しない場合、もしくはステップ１４１１の後、権限関連操作を行うかどうかをユーザに入力させ、それをチェックする（ステップ１４１２）。
権限関連操作を行う場合には、後の図１６で説明する権限関連操作を行う（ステップ１４１３）。
ステップ１４１２で権限関連操作を行わない場合、もしくはステップ１４１３の後、続けてメタデータ付与ルール関連操作を行うかどうかをユーザに入力させ、そのチェックを行い（ステップ１４１４）、終了で無い場合は、ステップ１４０１に戻る。終了の場合は、そのままメタデータ付与ルール関連操作の処理を終わる。
【００３５】
図１５は、図１３のステップ１３０８のメタデータ関連操作に関する処理概要のフローチャートである。
まず、ユーザのメタデータを操作する対象がファイルディレクトリか、ユーザか、ファイルやディレクトリの場合は、ＵＲＩもしくはメタデータ、ユーザＩＤなどを入力させ（ステップ１５０１）、その入力を元に、メタデータ管理ＤＢ１３６から対応するメタデータ群２０３もしくはメタデータ群３０２を検索し、その結果を表示する（ステップ１５０２）。
次にユーザの入力を促し、新たなメタデータの付与する新規付与かどうかをチェックする（ステップ１５０３）。
新規付与の場合は、新規付与できる権限を持つかどうかを、管理用処理部１３５を通して、権限ポリシーＤＢ１３７のアクセス権限テーブル６００と、ユーザのメタデータ管理テーブル３００を用いてチェックする。このチェックは、図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、meta権限があるかどうかをチェックする（ステップ１５０４）。図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
次に、新規付与するメタデータをユーザに入力させ、権限ポリシーＤＢ１３７のアクセス権限テーブル６００と、ユーザのメタデータ管理テーブル３００を用いて、そのメタデータが付与可能かチェックする（ステップ１５０５）。
チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
【００３６】
ステップ１５０３で、メタデータの新規付与でない場合は、ステップ１５０２で表示したメタデータから、変更削除するメタデータをユーザに選択させる（ステップ１５０６）。
次に、変更削除できる権限を持つかどうかを、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータの権限管理テーブル４００、もしくは、ユーザのメタデータの権限管理テーブル５００と、ユーザのメタデータ管理テーブル３００を用いてチェックする。
これは、変更削除するメタデータに対応するファイルディレクトリのメタデータの権限管理テーブル４００、もしくは、ユーザのメタデータの権限管理テーブル５００において、変更削除しようとするユーザの権限ユーザメタデータに含まれるかどうかをチェックする。チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
ステップ１５０７の後、メタデータの変更か追加かをユーザに入力させ、その結果をチェックする（ステップ１５０８）。変更の場合は、ユーザに変更後の入力を行わせ、先のステップ１５０５と同様に、変更後のメタデータが、付与可能かどうかチェックする（ステップ１５０９）。メタデータ削除の場合は、特に何も行わない。
メタデータの新規付与の場合のステップ１５０５の後、もしくは、メタデータの変更の場合のステップ１５０９の後、メタデータ削除の場合のステップ１５０８の後、そのメタデータの新規付与、変更削除の影響を表示する（ステップ１５１０）。これは、メタデータ付与ルール関連操作のステップ１４０４とほぼ同様に、メタデータの新規付与、変更削除の前後で変更されるＵＲＩやそのメタデータ、関連する権限を表示する。
【００３７】
その後、メタデータ付与ルール関連操作のステップ１４０８と同様に、実際にメタデータの新規付与、変更削除を実行するかを、ユーザに入力させ、その結果をチェックする（ステップ１５１１）。
ステップ１５１１で実行する場合は、メタデータ管理ＤＢ１３６のファイルディレクトリのメタデータ管理テーブル２００、もしくはユーザのメタデータ管理テーブル３００に、メタデータの新規付与、変更削除を反映させる（ステップ１５１２）。
次に、権限関連操作を行うかユーザに判断させ、その結果をチェックする（ステップ１５１３）。権限関連操作を行う場合には、後で説明する権限関連操作の処理を行う（ステップ１５１４）。
ステップ１５１４の後、ステップ１５１３で権限管理操作を行わない場合、ステップ１５１１でメタデータ管理ＤＢへの反映を行わない場合、他にメタデータ関連操作を行わずに終了するかどうかをユーザに判断させ、その結果をチェックする（ステップ１５１５）。
終了すると判断した場合は、そのまま終了する。終了しない場合は、ステップ１５０１に戻る。
【００３８】
図１６は、図１３のステップ１３０８の権限関連操作に関する処理概要のフローチャートである。
ユーザの入力を促し、新しい権限の追加かどうかをチェックする（ステップ１６０１）。
新規追加であった場合は、ユーザにその権限を入力させる（ステップ１６０２）。この入力の際には、この権限の変更削除権限も入力させる。
このルール入力時に、図１３のステップ１３０３にある検索処理を利用し、もしくは応用してファイルディレクトリやユーザの検索処理を追加し、入力補助をしても良い。
次に、管理用処理部１３５を通して、その権限を追加してよいかどうかをチェックする（ステップ１６０３）。このチェックは図１１のエクスプローラ用インタフェース部１３１の処理概要に関するフローチャートにおけるステップ１１０２とほぼ同様であるが、アクセスの種別ではなく、setsecurity権限があるかどうかをチェックし、新規追加する権限に利用するメタデータが利用可能メタデータ６０５に含まれているかどうかをチェックする。チェックが通らなければ、図では省略するが、再度入力を促すか、終了するかをユーザに選択させ、その処理を行う。
【００３９】
ステップ１６０１で、新規追加で無い場合は、権限ポリシーＤＢ１３７のアクセス権限テーブル６００を用いて、変更削除するルールをユーザに検索させる（ステップ１６０５）。
そして、選択した権限の変更削除を行う権限があるかどうかを、アクセス権限設定権限テーブル７００と、ユーザのメタデータ管理テーブル５００を用いてチェックする。このチェックは、変更するルールの権限ユーザメタデータ７０２に列挙されているメタデータグループの一つが、ユーザのメタデータ群３０２に含まれるかどうかをチェックする（ステップ１６０６）。
次に、権限変更か権限削除かの選択をユーザに行わせ、その結果をチェックする（ステップ１６０７）。変更の場合は、新規追加のステップ１６０２に進み、新規追加の場合と同様に、変更後のルールについてステップ１６０３の付与ルール権限チェックを行う。
ステップ１６０３の後、もしくは、ステップ１６０７において権限の削除であった場合は、権限の追加変更削除によって影響を受けるファイルやディレクトリについて、そのＵＲＩ、ルールの追加変更削除の前後のメタデータ群、アクセス権限を持つユーザのメタデータを表示する（ステップ１６０４）。これらは、基本的に図１４に示したメタデータ付与ルール関連操作に関する処理のステップ１４０４とほぼ同じである。
【００４０】
次に、ユーザに権限の追加変更削除を実行するかどうかを判断させ、その結果をチェックする（ステップ１６０８）。
ステップ１６０８で、実行する場合は、権限の変更を、権限ポリシーＤＢ１３７のアクセス権限テーブル６００に、権限の追加変更削除を反映させる。さらに、権限の追加の場合には、その権限の変更削除権限を持たせるユーザのメタデータ群を、ユーザ入力させ、それをアクセス権限設定権限テーブル７００に反映させる（ステップ１６０９）。
ここで、後者については、デフォルトでルールの追加を行ったユーザのメタデータ群を設定し、それに対する追加修正を行う処理にしても良い。
次に、メタデータ付与ルール関連操作を行うかどうかをユーザに判断させ、その結果のチェックを行い（ステップ１６１０）、メタデータ付与ルール関連操作を行う場合には、先に図１４で説明したメタデータ付与ルール関連操作に関連する処理を行う（ステップ１６１１）。
【００４１】
さらに、メタデータ関連操作を行うかどうかをユーザに判断させ、その結果のチェックを行い（ステップ１６１２）、メタデータ関連操作を行う場合には、先に図１５で説明したメタデータ関連操作に関連する処理を行う（ステップ１６１３）。
ステップ１６１３の後、ステップ１６１２でメタデータ関連操作を行わなかった場合、ステップ１６０８で実行しなかった場合、他に権限関連操作を行わずに終了するかどうかをユーザに判断させ、その結果をチェックする（ステップ１６１４）。終了すると判断した場合は、そのまま終了する。終了しない場合は、ステップ１６０１に戻る。
【図面の簡単な説明】
【００４２】
【図１】本発明に係るファイル管理システムの実施の形態を示すシステム構成図である。
【図２】ファイルディレクトリのメタデータ管理テーブルの構成例を示す図である。
【図３】ユーザのメタデータ管理テーブルの構成例を示す図である。
【図４】ファイルディレクトリのメタデータの権限管理テーブル構成例を示す図である。
【図５】ユーザのメタデータの権限管理テーブル構成例を示す図である。
【図６】アクセス権限テーブルの構成例を示す図である。
【図７】アクセス権限設定権限テーブルの構成例を示す図である。
【図８】メタデータ付与ルールテーブルの構成例を示す図である。
【図９】付与ルール設定権限テーブルの構成例を示す図である。
【図１０】システム導入時の処理概要に関するフローチャートである。
【図１１】エクスプローラ用インタフェース部１３１の処理概要に関するフローチャートである。
【図１２】図１１におけるステップ１１０４のメタデータ関連処理の詳細に関するフローチャートである。
【図１３】拡張操作インタフェース部１３２の処理概要に関するフローチャートである。
【図１４】図１３のステップ１３０６のメタデータ付与ルール関連操作に関する処理概要のフローチャートである。
【図１５】図１３のステップ１３０８のメタデータ関連操作に関する処理概要のフローチャートである。
【図１６】図１３のステップ１３０９の権限関連操作に関する処理概要のフローチャートである。
【符号の説明】
【００４３】
１００…クライアントＰＣ
１０１…エクスプローラ
１０２…クライアントソフト
１１０…ディレクトリサーバ
１２０…既存ファイルサーバ群
１２１…既存ファイルサーバＡ
１２２…既存ファイルサーバＢ
１３０…ファイルサーバ統合管理プロキシ
１３１…エクスプローラ用インタフェース部
１３２…拡張操作インタフェース部
１３３…メタデータ処理部
１３４…メタデータ検索処理部
１３５…管理用処理部
１３６…メタデータ管理ＤＢ
１３７…権限ポリシーＤＢ
１３８…メタデータ付与ルール群
１３９…クロール処理ルール部
１４０…ファイルサーバ用インタフェース部
１４１…クロール処理部
【図１】
2010079444.tif 000003
【図２】
2010079444.tif 000004
【図３】
2010079444.tif 000005
【図４】
2010079444.tif 000006
【図５】
2010079444.tif 000007
【図６】
2010079444.tif 000008
【図７】
2010079444.tif 000009
【図８】
2010079444.tif 000010
【図９】
2010079444.tif 000011
【図１０】
2010079444.tif 000012
【図１１】
2010079444.tif 000013
【図１２】
2010079444.tif 000014
【図１３】
2010079444.tif 000015
【図１４】
2010079444.tif 000016
【図１５】
2010079444.tif 000017
【図１６】
2010079444.tif 000018