JP2011238165A - 計算機システム及びメタデータ管理サーバ - Google Patents

Abstract

【課題】派生したファイルのメタデータを効率的に管理する。
【解決手段】本発明は、メタデータ管理サーバ及び来歴を管理する来歴管理サーバを備える計算機システムにおいて、前記各サーバは、前記ファイルを保持するクライアント計算機と接続されており、前記メタデータ管理サーバは、前記クライアント計算機に保持されるファイルのメタデータが変更されたイベントを検出し、前記検出されたイベントに関係する来歴の検索を前記来歴管理サーバに要求し、前記来歴管理サーバから送信された来歴の検索結果に基づいて、前記メタデータが変更された第１ファイルから派生した派生先の第２ファイル、及び当該第１ファイルを派生した派生元の第３ファイルを抽出し、前記抽出された第２ファイル及び第３ファイルのうち、前記メタデータを更新すべきファイルを特定し、前記特定されたファイルのメタデータを更新するためのメタデータ更新要求を生成する。
【選択図】図１

Description

本発明は，電子ファイルのメタデータを管理する技術に関する。

官民共に機密情報の適切な取扱いが強く求められているにもかかわらず、依然として機密情報の漏えい事件・事故が問題となっている。

情報漏洩対策では、情報を取り扱うユーザが、管理されている個人情報及び他者情報などの機密情報を的確に識別できる必要がある。電子ファイル（以下、「ファイル」という）形式の機密情報を識別する手段として、文書管理システム、ファイルシステムなどを利用し、機密レベルなどの機密情報を表す情報をファイルのメタデータとしてファイルと関連付けて管理するという方法が知られている。しかし、一般にメタデータを付与する作業は、情報を取り扱うユーザによる機密レベルの判定などを含むため、手間がかかることが多い。

このような課題に対して、特許文献１、２では、セキュリティ情報を表すメタデータが設定されていないファイルに、当該ファイルと類似するファイルのメタデータを付与することによって、メタデータの付与を効率化している。

特開２００６−１８５１５３号公報 特開２００９−２３０４２７号公報

前述した特許文献１、２で開示されている技術では、メタデータの付与を効率化できるが、複製や編集を経て派生したファイルが組織内に散在している場合、それら派生したファイルのメタデータも変更する方法は開示されていない。

本発明は、派生したファイルのメタデータを効率的に管理することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、ファイルのメタデータを管理する計算機システムにおいて、前記計算機システムは、前記ファイルのメタデータを管理するメタデータ管理サーバ、及び、前記ファイルの操作のログの来歴を管理する来歴管理サーバを備え、前記メタデータ管理サーバ及び前記来歴管理サーバは、前記ファイルを保持するクライアント計算機と接続されており、前記来歴管理サーバは、前記クライアント計算機による前記ファイルの内容又は格納場所に変化が生じるイベントを収集し、前記収集されたイベントの情報を来歴として蓄積し、前記メタデータ管理サーバは、前記クライアント計算機に保持されるファイルのメタデータが変更されたイベントを検出し、前記検出されたイベントに関係する来歴の検索を前記来歴管理サーバに要求し、前記来歴管理サーバは、前記メタデータ管理サーバからの要求に基づいて、管理されている来歴を検索し、前記来歴の検索結果を前記メタデータ管理サーバに送信し、前記メタデータ管理サーバは、前記来歴管理サーバから送信された来歴の検索結果を受信し、前記受信した来歴の検索結果に基づいて、前記メタデータが変更された第１ファイルから派生した派生先の第２ファイル、及び当該第１ファイルを派生した派生元の第３ファイルを抽出し、前記抽出された派生先の第２ファイル及び派生元の第３ファイルのうち、前記メタデータを更新すべきファイルを特定し、前記特定されたファイルのメタデータを更新するためのメタデータ更新要求を生成し、前記生成されたメタデータ更新要求を前記クライアントに送信することを特徴とする。

本発明の実施の形態によると、組織内に散在している機密文書の管理を効率化できる。

本発明の実施形態の計算機システムの構成例を示す図である。 本発明の実施形態のメタデータ管理サーバの構成のブロック図である。 本発明の実施形態でファイルをコピーした操作のログの一例を示す説明図である。 本発明の実施形態でファイルを圧縮した操作のログの一例を示す説明図である。 本発明の実施形態で可搬記録媒体が関係する操作のログの一例を示す説明図である。 本発明の実施形態で外部ホストが関係する操作のログの一例を示す説明図である。 本発明の実施形態でメールの添付ファイルを保存する操作のログの一例を示す説明図である。 本発明の実施形態でネットワーク経由でファイルをコピーする操作のログの一例を示す説明図である。 本発明の実施形態で編集されたファイルを上書保存した操作のログの一例を示す説明図である。 本発明の実施形態で編集されたファイルを別名で保存した操作のログの一例を示す説明図である。 本発明の実施形態でファイルを削除した操作のログの一例を示す説明図である。 本発明の実施形態でファイルを印刷した操作のログの一例を示す説明図である。 本発明の実施形態でファイルが添付されたメールを送受信したログを示す説明図である。 本発明の実施形態の来歴検索クエリの一例を示す説明図である。 本発明の実施形態の来歴検索結果の一例を示す説明図である。 本発明の実施形態のメタデータ変更イベントの一例を示す説明図である。 本発明の実施形態のメタデータ変更イベント選択ルールの一例を示す説明図である。 本発明の実施形態の派生先に適用されるルールの一例を示す説明図である。 本発明の実施形態の派生元に適用されるルールの一例を示す説明図である。 本発明の実施形態のメタデータ更新クエリの一例を示す説明図である。 本発明の実施形態のメタデータ管理処理のフローチャートである。 本発明の実施形態の派生先の来歴に対するメタデータ更新クエリ生成処理のフローチャートである。 本発明の実施形態の派生元の来歴に対するメタデータ更新クエリ生成処理のフローチャートである。 本発明の実施形態のメタデータ更新処理のフローチャートである。

以下、本発明のメタデータ管理システムを実施するための形態について、適宜図面を参照して、説明する。

＜システム構成＞
まず、本発明の実施形態の概要を説明する。

図１は、本発明の実施形態に係る計算機システムの構成例を示す図である。

図１に示すように、本実施形態の計算機システムは、メタデータ管理サーバ１３０及び来歴管理サーバ１４０を備える。本計算機システムは、メールサーバ１２０を備えてもよい。これらの装置はネットワーク１０１を介して相互に接続されている。また、ネットワーク１０１には、クライアント１１０が接続されている。図１には、１台のクライアント１１０を図示したが、複数のクライアント１１０がネットワーク１０１に接続されてもよい。

ネットワーク１０１に接続される各装置は、少なくともプロセッサ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）及びメモリを備えたコンピュータであり、プロセッサがメモリに格納されたプログラムを実行することによって、その機能を発揮する。

本計算機システムで取り扱われるメタデータは、クライアント１１０に格納さるファイルに関する付加的なデータを表す。例えば、ファイルの作成者、ファイルの作成日時、ファイルの機密レベル等がメタデータに含まれる。これらのメタデータは、ファイルそのものに格納されても、ファイルと関連付けられて管理される別のデータであってもよい。ファイルを取り扱うユーザは、メタデータを編集及び参照することができる。

次に、これら各装置の構成及び動作について説明する。

クライアント１１０は、メタデータ変更監視プログラム１１１、メタデータ更新プログラム１１２及びファイル操作監視プログラム１１３を備える。これらのプログラムは、補助記憶装置（例えば、磁気ディスクドライブ）に格納されており、補助記憶装置から読み出され、クライアント１１０の主記憶装置（メモリ）にロードされ、プロセッサによって実行される。

メタデータ変更監視プログラム１１１は、クライアント１１０のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ファイルシステム、メタデータを編集するプログラムを監視し、メタデータが変更された場合、メタデータ管理サーバ１３０へ変更の内容を通知するプログラムである。例えば、クライアント１１０に格納されるファイルの機密レベルを表すメタデータが、「公開情報」から「社外秘情報」へ変更された場合、メタデータ変更監視プログラム１１１は、メタデータ管理サーバ１３０へメタデータの変更を通知する。ただし、メタデータ更新プログラム１１２がメタデータを変更した場合、メタデータ更新ログがメタデータ管理サーバ１３０に送信されるので、このメタデータの変更はメタデータ変更監視プログラム１１１からメタデータ管理サーバ１３０へ通知されない。

メタデータ更新プログラム１１２は、メタデータ管理プログラム１３１から、クライアント１１０上のファイルのメタデータを更新する通知を受信した場合、受信した通知に基づいて、メタデータを更新し、メタデータ更新処理の結果をメタデータ管理サーバ１３０へ通知するなどの処理を行うプログラムである。例えば、クライアント１１０に格納されたファイルの機密レベルを表すメタデータを「社外秘情報」にするための通知をメタデータ管理プログラム１３１から受信した場合、メタデータ更新プログラム１１２は、受信した通知に指定されたファイルのメタデータを「社外秘情報」に更新し、更新の完了をメタデータ管理サーバ１３０へ通知する。

ファイル操作監視プログラム１１３は、クライアント１１０のＯＳやファイルシステムを監視し、ファイルの新規作成、編集、印刷などのファイル操作に関するログを取得し、取得したログを来歴管理サーバ１４０へ送信するプログラムである。

メールサーバ１２０は、クライアント１１０からの要求に従ってメールを送信するメール送信プログラム、受信したメールをクライアント１１０からの要求に従って配信するメール受信プログラム及びメール送受信監視プログラム１２１を備える。これらのプログラムは、補助記憶装置（例えば、磁気ディスクドライブ）に格納されており、補助記憶装置から読み出され、メールサーバ１２０の主記憶装置（メモリ）にロードされ、プロセッサによって実行される。

メール送受信監視プログラム１２１は、メールサーバ１２０によるメールの送受信に関するログを取得し、取得したログを来歴管理サーバ１４０へ送信するプログラムである。

メタデータ管理サーバ１３０は、メタデータ管理プログラム１３１、管理ルール設定プログラム１３２及び来歴走査プログラム１３３を備える。これらのプログラムは、補助記憶装置（例えば、磁気ディスクドライブ）に格納されており、補助記憶装置から読み出され、メタデータ管理サーバ１３０の主記憶装置（メモリ）にロードされ、プロセッサによって実行される。

また、メタデータ管理サーバ１３０は、メタデータ変更ログデータベース１３６、メタデータ変更イベント選択ルール１３４及びメタデータ更新ファイル選択ルール１３５を、補助記憶装置に格納する。

メタデータ変更イベント選択ルール１３４は、ファイルのメタデータを更新すべきメタデータ変更イベントを判定するためのルールである。メタデータ変更イベント選択ルール１３４の詳細は図１２を用いて説明する。

メタデータ更新ファイル選択ルール１３５は、メタデータを更新すべきファイルを判定するためのルールである。メタデータ更新ファイル選択ルール１３５の詳細は、図１３を用いて説明する。

メタデータ管理プログラム１３１は、クライアント１１０でファイルのメタデータが変更されたことの通知をメタデータ管理プログラム１３１から受信した場合、受信した通知に基づいて、メタデータの変更が生じたファイルに関するログを来歴管理サーバ１４０から取得し、メタデータ更新ファイル選択ルール１３５に基づいて、メタデータを更新する通知をクライアント１１０に送信するプログラムである。メタデータ管理プログラム１３１の詳細は、図１７を用いて説明する。

管理ルール設定プログラム１３２は、ユーザがメタデータ変更イベント選択ルール１３４及びメタデータ更新ファイル選択ルール１３５を設定するためのインターフェースを備えたプログラムである。すなわち、管理ルール設定プログラム１３２は、各ルールのフィールドの値を、ユーザがＣＵＩやＧＵＩで設定できる機能を備える。

メタデータ更新ログデータベース１３６は、メタデータの更新処理を行ったクライアント１１０から通知される処理結果が格納される。具体的には、メタデータを更新した日時、クライアント１１０の識別情報（例えば、ホスト名）、メタデータが更新されるファイルの識別情報（例えば、ファイルパス）、更新前のメタデータ、更新後のメタデータなどが含まれる。メタデータ管理サーバ１３０を管理するユーザは、メタデータ更新ログデータベース１３６によって、メタデータの更新状況を把握することができる。

来歴走査プログラム１３３は、メタデータ管理プログラム１３１がメタデータが更新されるファイルを特定する際に、補助的に実行されるプログラムである。来歴管理サーバ１４０から受信したログは、図１１に示すようにツリー構造のデータになっている。メタデータ管理プログラム１３１は、ツリー構造のデータを順に解析する。来歴走査プログラム１３３は、メタデータ管理プログラムが解析した結果に従って、次の解析対象の来歴を決定し、メタデータ管理プログラム１３１に通知する。

来歴管理サーバ１４０は、来歴検索プログラム１４１及び来歴送信プログラム１４２を備える。これらのプログラムは、補助記憶装置（例えば、磁気ディスクドライブ）に格納されており、補助記憶装置から読み出され、来歴管理サーバ１４０の主記憶装置（メモリ）にロードされ、プロセッサによって実行される。

また、来歴管理サーバ１４０は、来歴データベース１４３を、補助記憶装置に格納する。

来歴データベース１４３は、クライアント１１０におけるファイル操作のログ、メールサーバ１２０におけるメール送受信のログ等を含む。これらのログは、ファイル操作監視プログラム１１３及びメール送受信監視プログラム１２１により来歴管理サーバ１４０に送信され、来歴データベース１４３に格納される。来歴データベース１４３に格納されたログを「来歴」という。

来歴検索プログラム１４１は、来歴管理サーバ１４０に格納される来歴を検索するプログラムである。

来歴送信プログラム１４２は、来歴検索プログラム１４１によって検索された来歴を、メタデータ管理サーバ１３０へ送信するプログラムである。

なお、メタデータ管理サーバ１３０と来歴管理サーバ１４０とを１台のコンピュータに実装してもよい。また、来歴管理サーバ１４０の機能をメタデータ管理サーバ１３０に集約して、メタデータ管理サーバ１３０が来歴の検索・管理をするように構成してもよい。

次に、本実施形態の各コンピュータの構成について説明する。図２は、本実施形態のメタデータ管理サーバ１３０の構成のブロック図である。

図２に示すように、メタデータ管理サーバ１３０は、プロセッサ（ＣＰＵ）２０２、主記憶装置２０３、補助記憶装置２０４、ネットワークインターフェース２０５、Ｉ／Ｏインターフェース２０６及び可搬媒体接続部２０７を備える。これらの各ハードウェア資源は内部バス２０８によって接続されている。

プロセッサ２０２は、主記憶装置２０３にロードされたプログラムを実行する。主記憶装置２０３は、プロセッサ２０２で実行されるプログラム、プログラムの実行時に必要なデータを格納するメモリである。補助記憶装置２０４は、例えば、磁気ディスクドライブ、フラッシュメモリ等の不揮発性記憶装置である。

ネットワークインターフェース２０５は、ネットワーク１０１と接続され、ネットワーク１０１と接続された各装置と通信する。Ｉ／Ｏインターフェース２０６は、出力装置（例えば、ディスプレイ等）及び入力装置（例えば、キーボード、マウス）を接続する。可搬媒体接続部２０７は、光ディスク、ＵＳＢメモリ等の可搬記録媒体と接続するためのインターフェースであり、本計算機システムで管理されるファイルを記録媒体から読み込むために使用される。また、可搬記録媒体は、本計算機システムの計算機で実行されるプログラムを記録媒体から読み込むために使用される。

なお、本明細書では、主記憶装置２０３と補助記憶装置２０４とを、「記憶装置」と総称する。また、各装置には、本実施形態の記録閲覧及び監査の処理に必要なプログラムが格納されるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）が備わる。

以上、メタデータ管理サーバ１３０の構成を図２を用いて説明したが、来歴管理サーバ１４０、メールサーバ１２０及びクライアント１１０も、メタデータ管理サーバ１３０と同じ構成を有するコンピュータである。

＜ログの構成＞
次に、図３Ａから図８を参照して、ファイル操作監視プログラム１１３が取得するファイル操作ログについて説明する。

図３Ａは、ファイルをコピーした操作のログの一例を示す説明図である。

ファイル操作ログは、ユーザ操作を表すイベント３００Ａと、イベント３００Ａが発生した時刻３０２Ａと、イベント３００Ａが発生する前のファイルの情報を表す３０４Ａと、イベント３００Ａが発生した後のファイルの情報を表す３０６Ａなどを含む。

イベント発生前ファイルの情報３０４Ａは、イベントが発生したクライアント１１０の識別情報３４０Ａ、イベントによって操作されたファイルのパス名３４２Ａ、イベントによって操作されたファイル名３４４Ａ、イベントによって操作されたファイルが格納された補助記憶装置の種別を表すドライブ種別３４６Ａなどを含む。イベント発生後ファイルの情報３０６Ａも同様に、クライアント１１０の識別情報３６９Ａ、イベントによって操作されたファイルのパス名３６２Ａ、イベントによって操作されたファイル名３６４Ａ、イベントによって操作されたファイルが格納された補助記憶装置の種別を表すドライブ種別３６６Ａなどを含む。

また、ファイルを特徴づける情報（ファイルのテキスト情報等）を取得できる場合、取得した情報を、イベント発生前ファイルの情報３０４Ａ及びイベント発生後ファイルの情報３０６Ａに含めてもよい。

ここで、本明細書で用いる用語を定義する。

クライアント１１０等の計算機を「ホスト」と総称する。あるホストから見てネットワーク１０１に接続された別のホストを「外部ホスト」という。

また、ホストのＩＰアドレス、ＭＡＣアドレス及び名称等、ホストをネットワーク１０上で一意に識別するための識別情報を「ホスト識別情報」と総称する。

さらに、ホスト識別情報、パス名、ファイル名、ドライブ種別など、ホスト内にあるファイルを識別するための情報を「ファイル情報」と総称する。例えば、ドライブ種別には、クライアント１１０内に存在して外部からアクセスできない「ローカルドライブ」、外部からアクセス可能な「ネットワークドライブ」、可搬記録媒体上のドライブであることを示す「リムーバブルドライブ」などがある。このファイル情報から計算機システム内に格納されるファイルを一意に特定できる場合、このファイル情報は「完全」である。例えば、ホスト識別情報、パス名、ファイル名が明示されたファイル情報は完全となる。逆に、例えば、ファイル名しか含まないファイル情報は「不完全」となる。

図３Ａには、イベント３００Ａがファイルのコピーであるイベントを示す。具体的には、図３Ａに示すログで表されるイベントは、２００８年４月２８日１０時２１分１４秒に、「ＰＣ−１２３」という名称のクライアント１１０で、ローカルドライブ上のフォルダ「Ｃ：￥ＭｙＤｏｃｕｍｅｎｔｓ」の下のファイル「ｒｅａｄｍｅ．ｔｘｔ」がコピーされて、ファイル「Ｃ：￥ＤｅｓｋＴｏｐ￥ｒｅａｄｍｅ．ｔｘｔ」が生成されたイベントを表す。

図３Ａに示す例では、イベント発生前のファイルの情報３０４Ａ、イベント発生後ファイルの情報３０６Ａの各々には一つのファイルが記載されるが、記載されるファイルが存在しない場合、記載されるファイルが複数となる場合もある。例えば、イベントがファイルの新規作成であれば、イベント発生前ファイルの情報３０４Ａは存在せず、カラム３４０Ａ〜３４６Ａは空となる。また、イベントがファイルの削除であれば、イベント発生後ファイルの情報３０６Ａは存在せず、カラム３６０Ａ〜３６６Ａは空となる。

図３Ｂは、ファイルを圧縮した操作のログの一例を示す説明図である。図３Ｂに示すイベントは、イベント３００Ｂがファイルの圧縮であるイベントであり、このイベントにおいては、複数のファイルが圧縮されて一つのファイルが生成される。この場合、イベント発生前ファイルの情報３０４Ｂに複数のファイルの情報が記載されてもよい。

図４Ａは、可搬記録媒体が関係する操作のログの一例を示す説明図である。図４Ａに示すログで表されるイベントでは、可搬媒体に記録されたファイルがクライアント１１０の補助記憶装置２０４にコピーされている。ドライブ種別４４６Ａに、リムーバブルドライブの識別情報「ＵＳＢ−００１」が記載されている。

図４Ｂは、外部ホストが関係する操作のログの一例を示す説明図である。図４Ｂに示すログで表されるイベントでは、ネットワーク経由で他のクライアント１１０のフォルダにファイルがコピーされている。イベント発生後のホスト識別情報４６０Ｂがイベント発生前と同じ「ＰＣ−１２３」となっており、パス名４６２Ｂが「Ｚ：￥Ｐｕｂｌｉｃ」となっている。他のホストのフォルダをネットワークドライブとして割り当てることができるＯＳがある。このようなＯＳでは、パス名４６２Ｂからホスト識別情報４６０Ｂを特定できない場合がある。このため、ネットワーク１０１を介してファイルをコピーした場合、ファイル操作のログからは、どのクライアント１１０へファイルがコピーされたかを追跡できない。すなわち、このファイル情報は不完全である。

図５Ａ及び図５Ｂは、不正確なログの一例を示す説明図である。

図５Ａは、メールの添付ファイルを保存する操作のログの一例を示す説明図である。前述したように、ファイル操作監視プログラム１１３は、クライアント１１０のＯＳやファイルシステムを監視してログを収集する。このため、クライアント１１０のユーザがメールの添付ファイルを保存した場合、メール送受信プログラムによってファイルが生成されたところまではログを取得できるが、それがどのメールの添付ファイルであるかを特定することは、困難である。その結果、添付ファイルの保存というユーザ操作は、図５Ａに示すイベント５００Ａのようにファイルが「新規作成」されたものとして、不正確なログが取られる可能性がある。

また、図５Ｂに示すように、ＯＳがその外部ホストを識別できない場合、ネットワーク１０１経由で外部ホストからコピーされたファイルが、どの外部ホストに格納されていたファイルかを知ることはできない。このとき、外部ホストからファイルをコピーする操作は、図５Ｂに示すイベントのパス名５６２Ｂのフォルダにファイルが「新規作成」されたものとして、不正確なログが収集される可能性がある。

本実施の形態では、このように不正確なログが収集された場合でも、来歴を追跡可能である。

図６Ａは、編集されたファイルを上書保存した操作のログの一例を示す説明図である。図６Ａに示すログで表されるイベントでは、編集されたファイルを上書保存したため、イベント発生前の情報６０４Ａのホスト名６４０Ａ、パス名６４２Ａ、ファイル名６４４Ａ及びドライブ種別６４６Ａは、イベント発生後の情報６０６Ａのホスト名６６０Ａ、パス名６６２Ａ、ファイル名６６４Ａ及びドライブ種別６６６Ａと、それぞれ同じ値になっている。しかし、前述したテキスト情報などのファイルを特徴づける情報がログに含まれる場合、編集元ファイルをそのまま存置し、上書保存は別場所に保存されることがある。この場合、それらの値は、イベント発生前とイベント発生後で異なることがある。

図６Ｂは、編集されたファイルを別名で保存した操作のログの一例を示す説明図である。図６Ｂに示すログで表されるイベントでは、編集されたファイルを、別名で保存したため、イベント発生前の情報６０４Ｂのホスト名６４０Ｂ、パス名６４２Ｂ及びファイル名６４４Ｂの少なくとも一つの値は、イベント発生後情報６０６Ｂのホスト名６６０Ｂ、パス名６６２Ｂ及びファイル名６６４Ｂと異なる。この例では、編集されたファイルは、ファイル名を「ｒｅａｄｍｅ．ｔｘｔ」から「ｓａｍｐｌｅ．ｔｘｔ」に変更して保存されている。

図７Ａは、ファイルを削除した操作のログの一例を示す説明図である。図７Ａに示すログで表されるイベントでは、イベント発生前の情報７０４Ａで特定されるファイルを削除したため、イベント発生後の情報７０６Ａは空になっている。

図７Ｂは、ファイルを印刷した操作のログの一例を示す説明図である。図７Ｂに示すログで表されるイベントは、イベント７００Ｂがファイルの印刷であるイベントである。このログには、イベントが発生した時刻７０２Ｂ、イベント発生前の情報７０４Ｂ及びイベント発生後の情報７０６Ｂが含まれる。イベント発生前の情報７０４Ｂは、印刷されたファイルの情報であり、ホスト識別情報７４０Ｂ、パス名７４２Ｂ、ファイル名７４４Ｂ及びドライブ種別７４６Ｂなどを含む。イベント発生後の情報７０６Ｂは、印刷して生成された紙文書を識別するための情報であり、ホスト（プリンタ又は複合機）の識別情報７６０Ｂ及び紙文書ＩＤ７６２Ｂなどを含む。紙文書ＩＤ７６２Ｂは、印刷された紙文書を識別するための識別情報で、紙文書の背景部に直接書き込まれたり、バーコードとして印字されたり、又は電子透かしとして目立たないように紙文書全体に埋め込まれたりする。電子透かしについては、例えば、特開２００４−２８９７８３号公報に開示される技術を用いることができる。

具体的には、図７Ｂに示す例では、２００８年４月２８日１０時２１分１４秒に、「ＰＣ−１２３」という名称のクライアント１１０で、ローカルドライブ上のファイル「Ｃ：￥ＭｙＤｏｃｕｍｅｎｔｓ￥ｒｅａｄｍｅ．ｔｘｔ」が、「Ｐｒｉｎｔｅｒ−４５６」という名称のプリンタで印刷されて、１２８ビットのＩＤ「２９Ｅ５４８Ｃ７−Ｅ８１Ｆ−４４６４−Ａ７ＤＣ−Ｂ３ＣＡ０ＤＣＡ３８１Ｅ」が付与された紙文書が生成されたことを表している。

図８は、メール送受信ログを示す説明図である。図８に示すメール送信のログは、メールの送信か受信かを表すイベント８００Ａ、イベントが発生した時刻８０２Ａ、メールのメッセージＩＤ８０４Ａ、メールの送信宛先のメールアドレス８０６Ａ、カーボンコピー先のアドレス８０８Ａ、ブラインドカーボンコピー先のアドレス８１０Ａ、メールの送信元のアドレス８１２Ａ及び添付ファイル名８１４Ａなどを含む。

メールアドレス８０６Ａ、８０８Ａ、８１０Ａには複数のアドレスが記録されることがあり、添付ファイル８１４Ａには複数のファイル名が記録されることがある。なお、イベント８００Ａがメール受信であった場合、ブラインドカーボンコピー先のメールアドレス８１０Ａは、受信側メールサーバ１２０にメールを送信した送信側メールサーバ１２０によって消去されているため取得できない。

具体的には、図８に示す例では、２００８年４月２８日１０時２１分１４秒に、「ａｔｔａｃｈｍｅｎｔ１．ｔｘｔ」「ａｔｔａｃｈｍｅｎｔ２．ｔｘｔ」などのファイルが添付されたメッセージＩＤが「４８Ｆ６９７Ｂ８．５０００４０６＠ｉｎ．ｃｏｍ」のメールが、メールアドレス「ｄｄｄ＠ｉｎ．ｃｏｍ」のユーザから、アドレス「ａａａ１＠ｏｕｔ１．ｃｏｍ」「ａａａ２＠ｏｕｔ２．ｃｏｍ」などへ送信、「ｂｂｂ１＠ｏｕｔ３．ｃｏｍ」「ｂｂｂ２＠ｏｕｔ４．ｃｏｍ」などへカーボンコピー送信、「ｃｃｃ１＠ｏｕｔ５．ｃｏｍ」「ｃｃｃ２＠ｏｕｔ６．ｃｏｍ」などへブラインドカーボンコピー送信されたというメール送信イベントを表している。

図８には、メールの送信ログを示したが、メール送受信監視プログラム１２１は、メールの受信ログも取得してもよい。ずなわち、メールサーバ１２０は、ファイルが添付されているメールをクライアント１１０に転送した際、メールの受信ログを生成する。また、前述したように、受信したメールに添付されたファイルがローカルディスク（補助記憶装置）に格納された場合、ファイルを新規作成したログが生成される。

図３Ａ〜図８で説明した様々なログ（来歴）は、来歴管理サーバ１４０に格納される。

＜各種データの構成＞
図９は、来歴検索クエリの一例を示す説明図である。来歴検索クエリ９００は、ファイル情報（すなわち、ホスト識別情報９０１、パス名９０２、ファイル名９０３及びドライブ種別９０４）などを含む。なお、来歴検索クエリ９００に含まれるパラメータは、システム内でファイルを一意に特定できるものであればよく、例えば、来歴検索クエリ９００にドライブ種別９０４を含まなくてもよい。また、来歴検索クエリ９００に時刻（又は、時間範囲）を含んでもよい。来歴検索クエリ９００に時刻を含む場合、その時刻以前又は以後のイベントのみを検索することができ、来歴検索クエリ９００に時間範囲を含む場合、その時間範囲内のイベントのみを検索することができる。

来歴検索プログラム１４１は、来歴検索クエリ９００を受信すると、受信した来歴検索クエリに含まれるファイル情報と一致する来歴及びその来歴からトレースされる来歴を検索し、検索結果を来歴送信プログラム１４２へ出力する。

図１０は、来歴検索結果の一例を示す説明図である。来歴検索結果に含まれる各テーブル１０１０等は、来歴のイベント種別１０１１、イベント発生前の情報１０１２及びイベント発生後１０１３の情報を簡略化して表しているが、実際には、図３Ａから図８で説明したログのデータである。

来歴検索プログラム１４２は、来歴データベース１４３に格納されている来歴から、図１０に示すツリー状のデータを作成する。すなわち、検索された来歴はポインタによって、下位の来歴を指定することによって、ツリー状のデータが構成される。

ここで、連結された二つの来歴は、上位の来歴から下位の来歴が派生したことを表す。例えば、連結された来歴１０１０及び１０２０は、来歴１０１０で作成されたファイル「ｒｅａｄｍｅ．ｔｘｔ」が、来歴１０２０で、編集され、上書き保存されたことを表す。ファイル操作に関するログの場合は、ある来歴のイベント発生後の情報と、他の来歴のイベント発生前の情報とを比較することによって、この来歴同士を連結するかを判定できる。

ファイル操作に関するログ１０３０とメール送受信に関するログ１０６０との連結の可否は、メール送受信ログの添付ファイルの情報とファイル操作のイベント発生前あるいは発生後の情報を比較することによって判定できる。来歴検索プログラム１４２は、来歴データベース１４３に含まれるすべての来歴の連結可否を検索することによって、図１０のようなツリー構造をしたデータを複数作成することができる。

来歴検索プログラム１４１は、来歴検索クエリ９００を受信すると、来歴検索クエリ９００に含まれるファイルの情報と一致するファイルの情報を持つ来歴を検索し、その来歴が含まれるツリー構造のデータを来歴検索結果として来歴送信１４２プログラムへ出力する。なお、このデータは、来歴検索クエリ９００によって検索が行われる都度、検索条件に一致する来歴によってツリー状のデータを作成してもよいし、クライアント１１０又はメールサーバ１２０からログが送信され、来歴データベース１４３が更新されるタイミングで作成してもよい。

図１１は、メタデータ変更イベントの一例を示す説明図である。メタデータ変更イベント１１００は、変更イベントが発生した時刻１１０１、イベントが発生したクライアント１１０の識別情報１１０２、ファイルのパス名１１０３、ファイル名１１０４、ファイルが格納された補助記憶装置の種別を表すドライブ種別１１０５、変更前のメタデータ１１０６及び変更後のメタデータ１１０７などを含む。変更前のメタデータ１１０６及び変更後のメタデータ１１０７は、それぞれ複数のメタデータを格納できる。図１１に示す例では、「機密レベル＝公開」というメタデータ１１０８が、「機密レベル＝社外秘」というメタデータ１１０９に変更されたことを表す。メタデータには、図示した機密レベルの他、ファイルの属性、ファイルの保存期間、検索用キーワードなどを含んでもよい。

なお、メタデータが設定されていないファイルに、新たにメタデータが設定された場合のイベントは、変更前メタデータが空で、変更後メタデータに値が含まれるイベントによって表される。

図１２は、メタデータ変更イベント選択ルールの一例を示す説明図である。メタデータ変更イベント選択ルール１３４は、メタデータ管理サーバ１３０によって管理され、条件１２１０及び条件式１２２０などを含む。

条件１２１０は、メタデータ変更イベント１１００のフィールドと同じフィールド（時刻１２１１、ホストの識別情報１２１２、ファイルのパス名１２１３、ファイル名１２１４、ドライブ種別１２１５）及び変更前メタデータ１２１６及び変更後メタデータ１２１７を含む。ユーザは、管理ルール設定プログラム１３２のインターフェースを用いて、条件１２１０の中の各フィールドの値を設定する。

メタデータ管理プログラム１３１は、メタデータ変更監視プログラム１１１から受信したメタデータ変更イベント１１００の各フィールドの値と、メタデータ変更イベント選択ルール１３４の条件の中の各フィールドの値を比較し、それぞれの値が一致するかを判定する。図１２に示す例で、記号「＊」は任意の値を表し、比較する際に「＊」の項目は、常に一致すると判定される。

条件式１２２０は、条件の各フィールドの比較結果から、メタデータ変更イベント１１００がメタデータ変更イベント選択ルール１３４を満たすかを判定するための規則を表す。図１２に示す例の「ＡＮＤ」は、メタデータ変更監視プログラム１１１から受信したメタデータ変更イベント１１００の対応する各フィールドの値と、条件の各フィールドとが全て一致する場合に、受信したメタデータ変更イベント１１００が選択ルールを満たすと判定することを表す。

図１２に示す例では、メタデータ変更イベントの時刻１２１１が「２００９年」、ドライブ種別１２１５が「ローカルドライブ」、変更前メタデータ１２１８が「機密レベル＝公開」、変更後メタデータ１２１９が「機密レベル＝社外秘」である場合、メタデータ管理プログラム１３１は、受信したメタデータ変更イベントが選択ルールに含まれると判定する。

一般に、メタデータ変更イベント選択ルール１３４には、条件及び条件式のセットを含む複数の選択ルールが含まれる。メタデータ管理プログラム１３１は、メタデータ変更監視プログラム１１１から受信したメタデータ変更イベント１１００とメタデータ変更イベント選択ルール１３４に含まれる全ての選択ルールとを比較し、メタデータ変更イベント１１００が１以上の選択ルールと一致する場合、メタデータ管理プログラム１３１は、そのメタデータ変更イベント１１００がメタデータ変更イベント選択ルール１３４を満たすと判定する。

次に、メタデータ更新ファイル選択ルール１３５について説明する。メタデータ更新ファイル選択ルール１３５は、図１３Ａに示す派生先（図１０に示すツリーの下位）に適用されるルール１３００Ａ、及び、図１３Ｂに示す派生元（図１０に示すツリーの上位）に適用されるルール１３００Ｂを含む。

図１３Ａは、派生先に適用されるルールの一例を示す説明図である。派生先に適用されるルール１３００Ａは、メタデータ管理プログラム１３１が、メタデータ変更イベントが発生したファイルに関する来歴（以下、イベント発生来歴という）の派生先の来歴を解析する際に適用される。派生先に適用されるルールは、メタデータ変更イベントが発生したファイルと、そのファイルの派生先の関係にあるファイルとの類似度のしきい値１３１０Ａ、及び、来歴のイベントの種別に応じてメタデータを更新するための処理の種別を表すクエリ種別フィールド１３２０Ａなどを含む。

しきい値１３１０Ａは、あるファイルと他のファイルとが類似しているかを表す指標を用いて設定され、様々な方法が採用可能である。図１３Ａに示す例では、二つのファイルの類似度を表す指標に、一方のファイルから何回編集されて他方のファイルが生成されたかを表す編集回数を用いており、しきい値１３１０Ａとして「２回」が設定されている。このしきい値１３１０Ａは、メタデータ管理プログラム１３１がメタデータを更新するファイルを決定するため、図１０で示されるようなツリー構造の来歴をイベント発生来歴から派生先来歴へと順次解析していく際に用いられる。イベント発生来歴と解析対象の来歴との間（解析対象の来歴も含める）にイベント種別が編集である来歴が３回以上存在する場合は、解析対象の来歴に対応するファイルのメタデータは更新されないことになる。

メタデータを更新するための処理の種別１３２０Ａは、メタデータ管理プログラム１３１が来歴に対応するファイルのメタデータを更新する処理をクライアント１１０のメタデータ更新プログラム１１２へ依頼する際に、メタデータ更新プログラム１１２によって行われる処理を、来歴のイベントの種別ごとに指定する。処理の種別として、ここでは、「強制」、「確認」、「通知」の３種類が登録されている。なお、前述以外にも、様々な処理を設定できる。

「強制」は、メタデータ更新プログラム１１２が、更新対象のファイルのメタデータを、ユーザへの確認も通知もすることなく、強制的に更新することを意味する。「確認」は、メタデータ更新プログラム１１２が、更新対象のファイルのメタデータを更新するかの入力を促すメッセージをクライアント１１０に表示し、ユーザによる入力に従って、ファイルのメタデータを更新する（又は、更新しない）ことを意味する。「通知」は、メタデータ更新プログラム１１２が、ユーザに対してメタデータ更新イベントが発生したことを通知するメッセージを表示するだけで、メタデータは更新しないことを意味する。

例えば、「通知」は、メタデータ管理プログラム１３１が、イベント種別が「印刷」又は「メール送信」の来歴に対応するファイルのメタデータを更新する際に、イベントが発生したクライアント１１０上のメタデータ更新プログラム１１２を通じて、このファイルを印刷又はメールに添付して送信したユーザにメッセージを送ることが考えられる。ユーザは、通知を受け取ることによって、印刷した紙文書の取り扱いを変更したり、メールの送信先に注意を促すことが可能になる。

図１３Ｂは、派生元に適用されるルールの一例を示す説明図である。派生元に適用されるルール１３００Ｂは、メタデータ管理プログラム１３１が、イベントが発生したファイルに関する来歴の派生元の来歴を解析する際に適用される。各フィールドで設定される項目は、派生先に適用されるルール１３００Ａと同じであるが、設定される値を変更することによって、派生先と派生元に対して異なる取り扱いをすることができる。

図１４は、メタデータ更新クエリの一例を示す説明図である。メタデータ更新クエリ１４１００は、メタデータが更新されるファイルが格納されているクライアント１１０の識別情報１４１０１、更新対象のファイルのパス１４０２、更新対象のファイル名１４０３、メタデータが更新されるファイルが格納された補助記憶装置の種別を表すドライブ種別１４０４、メタデータ管理プログラム１３１が作成した更新クエリに対応する来歴のイベント種別１４１０５、このイベント発生時刻１４１０６、メタデータ更新プログラム１１２によって行われる処理を表すクエリ種別１４０７、メタデータ更新イベント１４１０８、及び補足情報１４１０９などを含む。

メタデータ更新イベント１４１０８のフィールドには、メタデータ変更イベント１１００（図１１）に含まれるデータが格納される。補足情報１４１０９には、例えば、メタデータが更新されるファイルをメールに添付して送信した場合の送信宛先メールアドレスなどが格納される。

＜システムによる処理＞
次に、図１５を参照して、メタデータ管理プログラム１３１によって実行される処理について説明する。

まず、メタデータ管理プログラム１３１は、メタデータ変更監視プログラム１１１によって送信されるメタデータ変更通知を受信する。メタデータ変更通知には、メタデータ変更イベント１１００が含まれている（Ｓ１５０１）。なお、クライアント１１０（メタデータ変更監視プログラム１１１）が、メタデータ変更通知を送信しなくても、メタデータ管理サーバ１３０（メタデータ管理プログラム１３１）が、繰り返し、クライアント１１０に問い合わせるなどによってメタデータの変更を検出してもよい。

その後、メタデータ管理プログラム１３１は、ステップＳ１５０１において受信したメタデータ変更イベント１１００がメタデータ変更イベント選択ルール１３４と一致するかを判定する（Ｓ１５０２）。その結果、メタデータ変更イベント１１００がメタデータ変更イベント選択ルール１３４と一致すると判定された場合、ステップＳ１５０３に進む。一方、メタデータ変更イベント１１００がメタデータ変更イベント選択ルール１３４と一致しないと判定された場合、ステップＳ１５０１に戻る。

ステップＳ１５０３において、メタデータ管理プログラム１３１は、来歴管理サーバ１４０へ送信する来歴検索クエリ９００を生成する。具体的には、メタデータ管理プログラム１３１が受信したメタデータ変更イベント１１００からファイルの情報を抽出し、抽出されたファイルの情報を来歴検索クエリ９００に設定する。

その後、メタデータ管理プログラム１３１は、ステップＳ１５０３において生成された来歴検索クエリを来歴管理サーバ１４０へ送信する（Ｓ１５０４）。

メタデータ管理プログラム１３１は、来歴管理サーバ１４０における来歴送信プログラム１４２によって送信される来歴検索結果を受信する（Ｓ１５０５）。

メタデータ管理プログラム１３１は、ステップＳ１５０５において受信した来歴検索結果及びメタデータ更新ファイル選択ルール１３５を参照して、メタデータ更新クエリ１４１００を生成する（Ｓ１５０６）。この処理の結果、０又は１以上のメタデータ更新クエリ１４１００が生成される。メタデータ更新クエリ１４１００を生成する処理は、ステップＳ１５０５において受信した来歴検索結果のうち、イベントが発生したファイルの来歴と派生先の来歴に対する処理（図１６）と、派生元の来歴に対する処理（図１７）とに分かれている。メタデータ管理プログラム１３１は、ステップＳ１５０６において、これら両方の処理を実行する。

なお、本実施の形態では、派生先の来歴に対する処理（図１６）及び派生元の来歴に対する処理（図１７）との両方を実行するが、計算機システムで管理されるファイルによっては、派生先の来歴に対する処理又は派生元の来歴に対する処理の一方を実行すればよい。

メタデータ管理プログラム１３１は、ステップＳ１５０６において生成されたメタデータ更新クエリ１４１００の有無を判定する（Ｓ１５０７）。その結果、メタデータ更新クエリ１４１００が存在すると判定された場合、ステップＳ１５０８に進む。一方、メタデータ更新クエリ１４１００が存在しないと判定された場合、ステップＳ１５０１に戻る。

ステップＳ１５０８において、メタデータ管理プログラム１３１は、メタデータを更新する。具体的には、ステップ１５０６において生成されたメタデータ更新クエリ１４１００に含まれるファイルの情報を参照し、このファイルの情報によって識別されるクライアント１１０にメタデータ更新クエリ１４１００を送信する。

クライアント１１０がメタデータ更新クエリ１４１００を受信すると、メタデータ更新プログラム１１２が、受信したメタデータ更新クエリ１４１００に従ってメタデータを更新する。メタデータ更新プログラム１１２の処理の詳細は図１８を用いて説明する。

メタデータ更新プログラム１１２は、メタデータ更新処理の最後に、メタデータ更新ログをメタデータ管理サーバ１３０へ送信する。メタデータ更新ログには、更新処理の内容、及び更新処理が実行された時刻などが含まれる。

メタデータ管理サーバ１３０がメタデータ更新プログラム１１２からメタデータ更新ログを受信すると、メタデータ管理プログラム１３１は、受信したメタデータ更新ログをメタデータ更新ログデータベース１３６に格納する。

次に、図１６を参照して、派生先の来歴に対してメタデータ更新クエリを生成する処理について説明する。

前述したように、来歴検索結果は、ツリー構造である。来歴走査プログラム１３３は、このツリーから一つの枝（経路）を選択し、その経路上の来歴を走査する。以下で説明する処理は、この一つの経路に対して適用されるものである。来歴走査プログラム１３３は、処理されたフローを記憶し、来歴検索結果のツリーの全ての経路を走査するまで、この処理が繰り返される。

まず、メタデータ管理プログラム１３１は、ステップＳ１５０５において受信した来歴検索結果を参照し、イベントが発生したファイルの来歴を識別する（Ｓ１６０１）。具体的には、ステップＳ１５０１において受信したメタデータ変更イベントに含まれるファイルの情報をキーとして、ステップＳ１５０５において受信した来歴検索結果を検索し、メタデータ変更イベントに含まれるファイルの情報と一致する来歴をイベントが発生した来歴として識別する。但し、該当する来歴が複数検索された場合、時刻が一番新しい来歴をイベントが発生した来歴として識別する。

その後、来歴走査プログラム１３３は、ステップＳ１６０１においてメタデータ管理プログラム１３１によって識別されたイベント発生来歴を解析対象に設定する（Ｓ１６０２）。

さらに、来歴走査プログラム１３３は、解析対象に設定されている来歴から派生した派生先イベントがあるかを判定する（Ｓ１６０３）。その結果、派生先イベントが存在しないと判定された場合、この来歴はツリーの末端なので、処理を終了する。一方、派生先イベントが存在すると判定された場合、来歴走査プログラム１３３は、ステップＳ１６０２において設定されたイベントから派生した派生先イベントの来歴を解析対象に設定する（Ｓ１６０４）。

その後、メタデータ管理プログラム１３１は、ステップＳ１６０４で解析対象に設定された派生先イベントの来歴のイベント種別を識別し、識別した結果によって処理を振り分ける（Ｓ１６０５）。すなわち、識別した結果、イベント種別が「新規作成」、「ファイルコピー」、「圧縮」のいずれかの場合、ステップＳ１６０６に進む。イベント種別が、「メール送信」、「印刷」のいずれかの場合、ステップＳ１６０９に進む。イベント種別が「編集」の場合、ステップＳ１６０８に進む。イベント種別が「削除」の場合、処理を終了する。

イベント種別が「新規作成」、「ファイルコピー」又は「圧縮」の場合、ステップＳ１６０６において、メタデータ管理プログラム１３１は、解析対象の来歴から派生した来歴の中に、イベント種別が「削除」、「編集」のいずれかの来歴があるかを判定する。そして、イベント種別が「編集」の来歴が存在する場合、イベント種別が「編集」の来歴のイベント発生前のファイルの情報とイベント発生後のファイルの情報とが一致するかを判定する。ファイルの情報が一致する編集イベントが存在する場合、ファイルは上書き保存されたと判定できる。

その結果、削除イベントが存在するか、又は、ファイルの情報が一致する編集イベントが存在すると判定された場合、ステップＳ１６０３に進む。一方、これらのイベントが存在しないと判定された場合、ステップＳ１６０９に進む。派生先の来歴に削除イベントが含まれる場合、メタデータ変更イベントが発生したファイルから派生したファイルが、ある時刻において存在したが、現在は存在しないので、メタデータを更新する必要がないと判定できる。また、派生先の来歴に上書保存イベントが含まれる場合、この来歴ではメタデータを更新せず、その上書保存イベントでメタデータを更新すればよいので、メタデータの更新が重複することを避けることができる。

イベント種別が「編集」の場合、ステップＳ１６０８において、メタデータ管理プログラム１３１は、メタデータを変更するイベントが発生した際のファイルと、解析対象のイベント発生後のファイルの情報で識別されるファイルとの類似度を計算し、計算された類似度と、メタデータ更新ファイル選択ルール１３５に設定された類似度のしきい値とを比較することによって、両ファイルが類似するかを判定する。類似度は、前述した編集回数を用いて計算してもよいし、テキストマッチング、文書解析などの公知の方法によって計算してもよい。その結果、両ファイルが類似すると判定された場合、類似するファイルのメタデータも更新するために、ステップＳ１６０９に進む。一方、両ファイルが類似しないと判定された場合、両ファイルは異なるものであり、派生先のファイルのメタデータを更新する必要がないので、処理を終了する。

イベント種別が、「メール送信」又は「印刷」の場合、ステップＳ１６０９において、メタデータ管理プログラム１３１は、解析対象の来歴からメタデータ更新クエリ１４１００を生成する。解析対象の来歴のイベント種別が、「新規作成」、「ファイルコピー」、「圧縮」又は「編集」の場合、メタデータ管理プログラムは、解析対象の来歴からイベント発生後のファイルの情報を取得し、メタデータ更新クエリ１４１００のファイルの情報のフィールド１４１０１〜１４１０４に設定する。一方、解析対象の来歴のイベント種別がメール送信の場合、解析対象の来歴の派生元来歴のイベント発生後のファイルの情報をメタデータ更新クエリ１４１００のファイルの情報のフィールド１４１０１〜１４１０４に設定する。

メタデータ更新クエリ１４１００のイベント種別のフィールド１４１０５には、解析対象の来歴のイベント種別を設定する。イベント発生時刻のフィールド１４１０６には、解析対象の来歴のイベント発生時刻を設定する。クエリ種別のフィールド１４１０７には、派生先に適用されるメタデータ更新ファイル選択ルール１３００Ａのクエリ種別１３２０Ａの中で、イベント種別１４１０５に対応する処理の種別（強制、確認又は通知）を設定する。メタデータ変更イベントフィールド１４１０８には、ステップＳ１５０１において受信したメタデータ変更イベントを設定する。また、必要に応じて、補足情報フィールド１４１０９にデータ（例えば、メールを送信した宛先メールアドレス）を設定する。メタデータ更新クエリを生成した後、ステップＳ１６０３に進む。

次に、図１７を参照して、派生元の来歴に対してメタデータ更新クエリを生成する処理について説明する。

まず、メタデータ管理プログラム１３１は、ステップＳ１５０５において受信した来歴検索結果を参照し、イベントが発生したファイルの来歴を識別する（Ｓ１７０１）。具体的には、ステップ１５０１において受信したメタデータ変更イベントに含まれるファイルの情報をキーとして、ステップＳ１５０５において受信した来歴検索結果を検索し、メタデータ変更イベントに含まれるファイルの情報と一致する来歴をイベントが発生した来歴として識別する。但し、該当する来歴が複数検索された場合、時刻が一番新しい来歴をイベントが発生した来歴として識別する。

その後、来歴走査プログラム１３３は、ステップＳ１７０１においてメタデータ管理プログラム１３１によって識別されたイベント発生来歴を解析対象に設定する（Ｓ１７０２）。

さらに、来歴走査プログラム１３３は、解析対象に設定されている来歴から派生した派生先イベントがあるかを判定する（Ｓ１７０３）。その結果、派生先イベントが存在しないと判定された場合、この来歴はツリーの末端なので、処理を終了する。一方、派生先イベントが存在すると判定された場合、来歴走査プログラム１３３は、ステップＳ１７０２において設定されたイベントの派生先イベントの来歴を解析対象に設定する（Ｓ１７０４）。

その後、メタデータ管理プログラム１３１は、ステップＳ１７０４で解析対象に設定された派生先イベントの来歴のイベント種別を識別し、識別した結果によって処理を振り分ける（Ｓ１７０５）。すなわち、識別した結果、イベント種別が「新規作成」、「ファイルコピー」、「圧縮」のいずれかの場合、ステップＳ１７０６に進む。イベント種別が、「メール送信」、「印刷」のいずれかの場合、ステップＳ１７１０に進む。イベント種別が「編集」の場合、ステップＳ１７０８に進む。イベント種別が「削除」の場合、処理を終了する。

イベント種別が「新規作成」、「ファイルコピー」又は「圧縮」の場合、ステップＳ１７０６において、メタデータ管理プログラム１３１は、解析対象の来歴から派生した来歴の中に、イベント種別が「削除」、「編集」のいずれかの来歴があるかを判定する。そして、イベント種別が「編集」の来歴が存在する場合、イベント種別が「編集」の来歴のイベント発生前のファイルの情報とイベント発生後のファイルの情報とが一致するかを判定する。ファイルの情報が一致する編集イベントが存在する場合、ファイルは上書き保存されたと判定できる。

その結果、削除イベントが存在するか、又は、ファイルの情報が一致する編集イベントが存在すると判定された場合、ステップＳ１７０９に進む。一方、これらのイベントが存在しないと判定された場合、ステップＳ１７１０に進む。派生先の来歴に削除イベントが含まれる場合、メタデータ変更イベントが発生したファイルから派生したファイルが、ある時刻において存在したが、現在は存在しないので、メタデータを更新する必要がないと判定できる。また、派生先の来歴に上書保存イベントが含まれる場合、この来歴ではメタデータを更新せず、その上書保存イベントでメタデータを更新すればよいので、メタデータの更新が重複することを避けることができる。

イベント種別が「編集」の場合、ステップＳ１７０８において、メタデータ管理プログラム１３１は、メタデータを変更するイベントが発生した際のファイルと、解析対象のイベント発生後のファイルの情報で識別されるファイルとの類似度を計算し、計算された類似度と、メタデータ更新ファイル選択ルール１３５に設定された類似度のしきい値とを比較することによって、両ファイルが類似するかを判定する。類似度は、前述した編集回数を用いて計算してもよいし、テキストマッチング、文書解析などの公知の方法によって計算してもよい。その結果、両ファイルが類似すると判定された場合、類似するファイルのメタデータも更新するために、ステップＳ１６０９に進む。一方、両ファイルが類似しないと判定された場合、両ファイルは異なるものであり、派生先のファイルのメタデータを更新する必要がないので、処理を終了する。

イベント種別が、「メール送信」又は「印刷」の場合、ステップＳ１７１０において、メタデータ管理プログラム１３１は、解析対象の来歴からメタデータ更新クエリ１４１００を生成する。解析対象の来歴のイベント種別が、「新規作成」、「ファイルコピー」、「圧縮」又は「編集」の場合、メタデータ管理プログラムは、解析対象の来歴からイベント発生後のファイルの情報を取得し、メタデータ更新クエリ１４１００のファイルの情報のフィールド１４１０１〜１４１０４に設定する。一方、解析対象の来歴のイベント種別がメール送信の場合、解析対象の来歴の派生先来歴のイベント発生後のファイルの情報をメタデータ更新クエリ１４１００のファイルの情報のフィールド１４１０１〜１４１０４に設定する。

メタデータ更新クエリ１４１００のイベント種別のフィールド１４１０５には、解析対象の来歴のイベント種別を設定する。イベント発生時刻のフィールド１４１０６には、解析対象の来歴のイベント発生時刻を設定する。クエリ種別のフィールド１４１０７には、派生元に適用されるメタデータ更新ファイル選択ルール１３００Ｂのクエリ種別１３２０Ｂの中で、イベント種別１４１０５に対応する処理の種別（強制、確認又は通知）を設定する。メタデータ変更イベントフィールド１４１０８には、ステップＳ１５０１において受信したメタデータ変更イベントを設定する。また、必要に応じて、補足情報フィールド１４１０９にデータ（例えば、メールを送信した宛先メールアドレス）を設定する。メタデータ更新クエリを生成した後、ステップＳ１７０３に進む。

ステップＳ１７０９において、来歴走査プログラム１３３は、解析対象の来歴に派生先イベントがあるかを判定する。その結果、派生先来歴が存在する場合、この来歴から分岐する枝（経路）が存在するので、ステップＳ１７１１に進み、さらにメタデータ更新クエリ１４１００を生成する。一方、派生先来歴が存在しない場合、この来歴から分岐する枝は存在しないので、ステップＳ１７１１に進み、さらにメタデーステップＳ１７０３に進む。

ステップＳ１７１１において、メタデータ管理プログラム１３１は、派生先来歴を対象としたメタデータ更新クエリの生成処理を行う。具体的には、Ｓ１７１１において解析対象に設定されている来歴を解析対象に設定した後、図１６に示すメタデータ更新クエリ生成処理のステップＳ１６０３からの処理と同じ処理を実行する。来歴走査プログラム１３３は、ステップＳ１６０２において解析対象に設定された来歴を基点とした派生先来歴について、全ての経路を走査するまで、この処理を繰り返す。すべての経路について、この処理を行った後、ステップＳ１７０３に戻る。

次に、図１８を参照して、メタデータ更新プログラム１１２の処理について説明する。

まず、メタデータ更新プログラム１１２は、メタデータ管理プログラム１３１によって送信されたメタデータ更新クエリ１４１００を受信する（Ｓ１８０１）。

メタデータ更新プログラム１１２は、ステップＳ１８０１において受信したメタデータ更新クエリ１４１００のクエリ種別を判定する（Ｓ１８０２）。その結果、クエリ種別が「強制」又は「確認」であると判定された場合、ステップＳ１８０５に進む。一方、クエリ種別が「通知」である場合、メタデータ更新プログラム１１２は、メタデータの変更を知らせるメッセージを表示する（Ｓ１８０３）。

その後、ユーザは、ステップＳ１８０３において表示されたメッセージを確認し、確認した旨を入力する（Ｓ１８０４）。例えば、ユーザが表示されたメッセージの中の「確認」ボタンを操作することによって、メタデータ更新プログラム１１２がユーザによる確認結果を取得する。その後、ステップＳ１８１１に進む。

ステップＳ１８０５において、メタデータ更新プログラム１１２は、ステップＳ１８０１において受信したメタデータ更新クエリ１４１００に含まれるファイルの情報で識別されるファイルが、クライアント１１０上に保存されているかを判定する。その結果、このファイルがクライアント１１０上に保存されていないと判定された場合、ステップＳ１８１１に進む。一方、このファイルがクライアント１１０上に保存されていると判定された場合、メタデータ更新プログラム１１２は、ステップＳ１８０１において受信したメタデータ更新クエリ１４１００のクエリ種別を判定する。判定した結果、クエリ種別が「強制」である場合、ステップＳ１８１０に進む。一方、クエリ種別が「確認」である場合、メタデータ更新プログラム１１２は、ユーザによるメタデータを更新するか否かの判定を促すメッセージを表示する（Ｓ１８０７）。

その後、ユーザは、ステップＳ１８０７において表示されたメッセージを確認し、メタデータを更新するかを決定する（Ｓ１８０８）。例えば、ユーザが表示されたメッセージの中の「更新」ボタン又は「非更新」ボタンを操作することによって、メタデータ更新プログラム１１２がユーザによる更新／非更新の選択結果を取得する。

そして、メタデータ更新プログラム１１２は、ユーザが非更新を選択した場合、ステップＳ１８１１に進む。一方、ユーザが更新を選択した場合、メタデータ更新プログラム１１２は、メタデータを更新する（Ｓ１８１０）。

ステップＳ１８１１において、メタデータ更新プログラム１１２は、処理結果(メタデータ更新ログ)をメタデータ管理サーバ１３０へ送信し（Ｓ１８１１）、その後、処理を終了する。

以上説明したように、本発明の実施の形態では、予めルール（メタデータイベント選択ルール１３４、メタデータ更新ファイル選択ルール１３５）を設定しておくことによって、クライアント１１０上のファイルのメタデータが変更された場合に、メタデータを更新すべきファイルを漏れなく効率的に更新することができる。

なお、前述した実施形態は、本発明を実施するための一例であり、本発明の範囲は明細書に開示された実施形態に限定されない。したがって、本発明の要旨を変更しない範囲内においてその実施形式を種々変形することが可能である。例えば、ハードウェア、ソフトウェア、各フローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１１０ クライアント
１１１ メタデータ変更監視プログラム
１１２ メタデータ更新プログラム
１１３ ファイル操作監視プログラム
１２０ メールサーバ
１２１ メール送受信監視プログラム
１３０ メタデータ管理サーバ
１３１ メタデータ管理プログラム
１３２ 管理ルール設定プログラム
１３３ 来歴走査プログラム
１３４ メタデータ変更イベント選択ルール
１３５ メタデータ更新ファイル選択ルール
１３６ メタデータ変更ログデータベース
１４０ 来歴管理サーバ
１４１ 来歴検索プログラム
１４２ 来歴送信プログラム
１４３ 来歴データベース

Claims (18)

1. ファイルのメタデータを管理する計算機システムにおいて、
   前記計算機システムは、前記ファイルのメタデータを管理するメタデータ管理サーバ、及び、前記ファイルの操作のログの来歴を管理する来歴管理サーバを備え、
   前記メタデータ管理サーバ及び前記来歴管理サーバは、前記ファイルを保持するクライアント計算機と接続されており、
   前記来歴管理サーバは、前記クライアント計算機による前記ファイルの内容又は格納場所に変化が生じるイベントを収集し、前記収集されたイベントの情報を来歴として蓄積し、
   前記メタデータ管理サーバは、
   前記クライアント計算機に保持されるファイルのメタデータが変更されたイベントを検出し、
   前記検出されたイベントに関係する来歴の検索を前記来歴管理サーバに要求し、
   前記来歴管理サーバは、
   前記メタデータ管理サーバからの要求に基づいて、管理されている来歴を検索し、
   前記来歴の検索結果を前記メタデータ管理サーバに送信し、
   前記メタデータ管理サーバは、
   前記来歴管理サーバから送信された来歴の検索結果を受信し、
   前記受信した来歴の検索結果に基づいて、前記メタデータが変更された第１ファイルから派生した派生先の第２ファイル、及び当該第１ファイルを派生した派生元の第３ファイルを抽出し、
   前記抽出された派生先の第２ファイル及び派生元の第３ファイルのうち、前記メタデータを更新すべきファイルを特定し、
   前記特定されたファイルのメタデータを更新するためのメタデータ更新要求を生成し、
   前記生成されたメタデータ更新要求を前記クライアントに送信することを特徴とする計算機システム。
2. 前記来歴検索結果は、ファイルが操作された順に派生元来歴と派生先来歴とがリンクしたツリー構造であって、
   前記メタデータ管理サーバは、前記抽出された派生先の第２ファイル又は派生元の第３ファイルが所定条件を満たす場合、前記第１ファイルがメタデータを更新すべきファイルであると特定することを特徴とする請求項１に記載の計算機システム。
3. 前記メタデータ管理サーバは、
   前記抽出された派生先の第２ファイルから派生した第４ファイルに対応する来歴に削除イベントも、上書保存イベントも存在しない場合、当該抽出された派生先の第２ファイルが、メタデータを更新すべきファイルであると特定し、
   前記抽出された派生元の第３ファイルを派生した第５ファイルに対応する来歴に削除イベントも、上書保存イベントも存在しない場合、当該抽出された派生元の第３ファイルが、メタデータを更新すべきファイルであると特定することを特徴とする請求項２に記載の計算機システム。
4. 前記メタデータ管理サーバは、
   前記抽出された派生先の第２ファイルに対応する来歴が編集イベントであり、かつ、前記第２ファイルが派生元の第１ファイルと類似する場合、前記第２ファイルが、メタデータを更新すべきファイルであると特定し、
   前記抽出された派生元の第３ファイルに対応する来歴が編集イベントであり、かつ、前記第３ファイルが派生先の第１ファイルと類似する場合、前記第３ファイルが、メタデータを更新すべきファイルであると特定することを特徴とする請求項２に記載の計算機システム。
5. 前記来歴検索要求は、前記計算機システム内でファイルを一意に特定可能なパラメータを含むことを特徴とする請求項１に記載の計算機システム。
6. 前記メタデータ管理サーバは、
   前記イベントが、派生先及び派生元のファイルのメタデータを更新すべきものか否かの情報を含むメタデータ変更イベント選択ルールを管理し、
   前記検出されたイベントが、前記メタデータ変更イベント選択ルールに一致する場合、前記検出されたイベントに関係する来歴の検索を前記来歴管理サーバに要求することを特徴とする請求項１に記載の計算機システム。
7. 前記メタデータ更新要求には、利用者が確認した場合にメタデータを更新する第１の種別と、メタデータを更新せず、関連するファイルのメタデータの更新を利用者に通知する第２の種別と、利用者へ確認も通知もすることなくメタデータを更新する第３の種別とを含む要求の種別が設定され、
   前記クライアント計算機は、前記メタデータ更新要求に設定された要求の種別に対応する処理を選択的に実行することを特徴とする請求項１に記載の計算機システム。
8. 前記メタデータ管理サーバは、
   前記イベントがファイルの新規作成である場合、前記メタデータ更新要求には前記第３の種別を設定し、
   前記イベントがファイルのコピーである場合、前記メタデータ更新要求には前記第１の種別を設定し、
   前記イベントがファイルの転送である場合、前記メタデータ更新要求には前記第２の種別を設定することを特徴とする請求項１に記載の計算機システム。
9. 前記クライアントは、
   前記メタデータ更新要求を受信した場合、受信したメタデータ更新要求に従って、メタデータを更新し、
   メタデータ更新ログを生成し、
   前記生成されたメタデータ更新ログを前記メタデータ管理サーバに送信し、
   前記メタデータ管理サーバは、受信した前記メタデータ更新ログを記憶装置に格納することを特徴とする請求項１に記載の計算機システム。
10. ファイルのメタデータを管理するメタデータ管理サーバであって、
    前記メタデータ管理サーバは、プログラムを実行するプロセッサ、前記プロセッサで実行されるプログラムを格納するメモリ、及び他の計算機と接続するインターフェースを備え、前記ファイルを保持するクライアント計算機と接続されており、
    前記メタデータ管理サーバが備わる計算機システムでは、前記クライアント計算機による前記ファイルの内容又は格納場所に変化が生じるイベントを収集し、前記収集されたイベントの情報を来歴として蓄積されており、
    前記メタデータ管理サーバは、
    前記クライアント計算機に保持されるファイルのメタデータが変更されたイベントを検出し、
    前記検出されたイベントに関係する来歴を検索した結果に基づいて、前記メタデータが変更された第１ファイルから派生した派生先の第２ファイル、及び当該第１ファイルを派生した派生元の第３ファイルを抽出し、
    前記抽出された派生先の第２ファイル及び派生元の第３ファイルのうち、前記メタデータを更新すべきファイルを特定し、
    前記特定されたファイルのメタデータを更新するためのメタデータ更新要求を生成し、
    前記生成されたメタデータ更新要求を前記クライアントに送信することを特徴とするメタデータ管理サーバ。
11. 前記来歴の検索結果は、ファイルが操作された順に派生元来歴と派生先来歴とがリンクしたツリー構造であって、
    前記メタデータ管理サーバは、前記抽出された派生先の第２ファイル又は派生元の第３ファイルが所定条件を満たす場合、前記第１ファイルがメタデータを更新すべきファイルであると特定することを特徴とする請求項１０に記載のメタデータ管理サーバ。
12. 前記抽出された派生先の第２ファイルから派生した第４ファイルに対応する来歴に削除イベントも、上書保存イベントも存在しない場合、当該抽出された派生先の第２ファイルが、メタデータを更新すべきファイルであると特定し、
    前記抽出された派生元の第３ファイルを派生した第５ファイルに対応する来歴に削除イベントも、上書保存イベントも存在しない場合、当該抽出された派生元の第３ファイルが、メタデータを更新すべきファイルであると特定することを特徴とする請求項１１に記載の前記メタデータ管理サーバ。
13. 前記抽出された派生先の第２ファイルに対応する来歴が編集イベントであり、かつ、前記第２ファイルが派生元の第１ファイルと類似する場合、前記第２ファイルが、メタデータを更新すべきファイルであると特定し、
    前記抽出された派生元の第３ファイルに対応する来歴が編集イベントであり、かつ、前記第３ファイルが派生先の第１ファイルと類似する場合、前記第３ファイルが、メタデータを更新すべきファイルであると特定することを特徴とする請求項１１に記載の前記メタデータ管理サーバ。
14. 前記来歴検索要求は、前記計算機システム内でファイルを一意に特定可能なパラメータを含むことを特徴とする請求項１０に記載の前記メタデータ管理サーバ。
15. 前記メタデータ管理サーバは、
    前記イベントが、派生ファイルのメタデータを更新すべきものか否かの情報を含むメタデータ変更イベント選択ルールを管理し、
    前記検出されたイベントが、前記メタデータ変更イベント選択ルールに一致する場合、前記検出されたイベントに関係する来歴を検索することを特徴とする請求項１０に記載の前記メタデータ管理サーバ。
16. 前記メタデータ更新要求には、利用者が確認した場合にメタデータを更新する第１の種別と、メタデータを更新せず、関連するファイルのメタデータの更新を利用者に通知する第２の種別と、利用者へ確認も通知もすることなくメタデータを更新する第３の種別とを含む要求の種別が設定され、
    前記クライアント計算機は、前記メタデータ更新要求に設定された要求の種別に対応する処理を選択的に実行することを特徴とする請求項１０に記載の前記メタデータ管理サーバ。
17. 前記メタデータ管理サーバは、
    前記イベントがファイルの新規作成である場合、前記メタデータ更新要求には前記第３の種別を設定し、
    前記イベントがファイルのコピーである場合、前記メタデータ更新要求には前記第１の種別を設定し、
    前記イベントがファイルの転送である場合、前記メタデータ更新要求には前記第２の種別を設定することを特徴とする請求項１０に記載の前記メタデータ管理サーバ。
18. 前記クライアントは、
    前記メタデータ更新要求を受信した場合、受信したメタデータ更新要求に従って、メタデータを更新し、
    メタデータ更新ログを生成し、
    前記生成されたメタデータ更新ログを前記メタデータ管理サーバに送信し、
    前記メタデータ管理サーバは、受信した前記メタデータ更新ログを記憶装置に格納することを特徴とする請求項１０に記載の前記メタデータ管理サーバ。

Images