JP2010160698A - 来歴管理システム、来歴管理サーバ及びその管理方法 - Google Patents

Abstract

【課題】コンテンツの漏洩が発生した場合、その漏洩の経過を明らかにする。
【解決手段】来歴管理システムは、クライアント、他の装置、及び来歴管理サーバを含む。クライアントは、ファイルなどのコンテンツの内容の更新を含む操作ログを送信する。他の装置は、コンテンツの内容の更新に係らない操作ログを送信する。来歴管理サーバは、クライアント及び他の装置からの操作ログを受信し、コンテンツ及びコンテンツへの操作の指定に応答して、指定されたコンテンツ及びコンテンツへの操作を表示し、表示したコンテンツ及びコンテンツへの操作に係る操作来歴を、受信した操作ログからトレースし、表示したコンテンツ及びコンテンツへの操作にトレース結果を連結して表示する。
【選択図】図２

Description

本発明は、電子ファイルや紙文書などのコンテンツの操作に関する管理する技術に関する。

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

このような問題に対処するために、アクセス権の悪用の可能性を示しうる記憶媒体やネットワークへのファイルの通過を監視する技術がある(特許文献１)。具体的には、ファイルの使用点(使用時点および使用場所)においてエージェントが、リソースへのアクセス要求に割込み、イベントを検出し、検出したイベントをフィルタリングした上で、分析し、分析結果が予め定めたポリシーに反しているならば、ポリシーに対応する処理（警告などのポリシー論理）を実行する技術である。

特表2006−525562

特許文献1の技術は、記憶媒体やネットワークを介したファイルの漏洩防止に寄与するが、最近の情報処理システムにおいては、システム構築時に想定し得ない不正アクセスが発生したり、システムの再構成も頻繁に実行されるので、検出すべきイベントや予め設定するポリシーを網羅することは困難である。

ファイルなどのコンテンツの漏洩の問題に対するアプローチには、特許文献1のように漏洩自体を発生させないようにすること、漏洩を抑制するために、漏洩が発生しても、その漏洩の経過を明らかにすることがある。前者には網羅性の点に課題を残すので、前者と併用するとしても後者が必要となる。

ファイルに対する操作の経過を明らかにしたり、その経過を再利用したりするために、ファイルシステムではファイルへの操作ログが記録される。しかしながら、操作ログからのファイル操作の経過は、そのファイルシステムの中に留まり、ファイルシステムから外部へ又は外部からファイルシステムへのファイルのコピーなどの操作ログは記録されない。

上記課題を解決するために、本発明は、次のような構成の来歴管理システム、その来歴管理システムに含まれる来歴管理サーバ及び来歴管理方法を提供する。来歴管理システムは、ネットワークを介して接続するクライアント、他の装置、及び来歴管理サーバを含む。クライアントは、ファイルなどのコンテンツの内容の更新を含む操作に関する第1の操作ログを取得する第1のログ取得部と取得した第1の操作ログを送信する第1の送信部とを有する。他の装置は、コンテンツの内容の更新に係らない操作に関する第２の操作ログを取得する第２のログ取得部と取得した第２の操作ログを送信する第２の送信部とを有する。来歴管理サーバは、クライアントからの第1の操作ログ及び他の装置からの第２の操作ログを受信する受信部と、コンテンツ及びコンテンツへの操作の指定に応答して、指定されたコンテンツ及びコンテンツへの操作を表示し、表示したコンテンツ及びコンテンツへの操作にトレース結果を連結して表示する表示部と、表示したコンテンツ及びコンテンツへの操作に係る操作来歴を、受信した第1の操作ログ及び第２の操作ログとからトレースし、表示するためのトレース結果を得る来歴検索部とを有する。

本発明の他の態様は、来歴管理サーバの表示部は、コンテンツ及びコンテンツへの操作、並びにトレース結果を階層化して表示する。

本発明のさらに他の態様は、来歴管理サーバの来歴検索部による操作来歴のトレースは、表示したコンテンツ及びコンテンツへの操作のいずれか一方を基点とした、第1の操作ログ及び第２の操作ログとからのバックトレース及びフォワードトレースのいずれか一方である。

本発明のさらに他の態様は、来歴管理サーバの来歴検索部によるトレース結果は、第1の操作ログ及び第２の操作ログの中の、操作来歴として不完全な操作ログを含む。

本発明のさらに他の態様は、クライアントおよび他の装置の識別情報を含む資産情報を管理する資産管理サーバをさらに設け、資産管理サーバが管理する資産情報を参照して、トレース結果に含まれる操作来歴として不完全な操作ログを修正する。

本発明のさらに他の態様は、他のシステムは、コンテンツを印刷するプリンタドライバ、コンテンツを添付して送受信するメールサーバ、及びコンテンツを複写又はスキャンする複合機の少なくとも一つである。

本発明によれば、コンテンツに対する複数の異なるシステムにおける操作ログをトレースして、トレース結果を連結して表示するので、コンテンツの漏洩が発生しても、その漏洩の経過を明らかにすることができる。

実施例1の来歴管理システムの構成を示した図である。 実施例1の来歴管理システムを構成するクライアントおよびサーバの構成図の一例である。 実施例1の来歴管理システムのブロック図である。 ファイル操作ログの一例である。 ファイル操作ログの一例である。 ファイル操作ログの一例である。 メール送受信ログおよび印刷ログの一例である。 紙の複写ログおよびスキャンログの一例である。 来歴DBのデータ構造の一例である。 来歴検索プログラムの構成図およびインターフェースの一例である。 ログ表示のフローチャートである。 ログの表示例である。 バックトレース処理のフローチャートである。 バックトレースにおける基点ログに応じた処理のフローチャートである。 検索結果表示処理のフローチャートである。 バックトレース結果の表示例である。 バックトレース結果の表示例である。 バックトレース結果の表示例である。 フォワードトレースのフローチャートである。 フォワードトレース結果の表示例である。 フォワードトレースおよびバックトレースの結果の表示例である。 実施例2の来歴管理システムの全体図の一例である。 資産管理サーバと来歴管理サーバの構成図および資産情報である。 資産情報を用いた来歴の修正例である。

図面を参照しつつ、来歴管理システムの実施例について説明する。以下、電子ファイル、電子メール、紙文書などを総称して「コンテンツ」とよぶ。

図１は、実施例１の来歴管理システムの構成を示した図である。来歴管理システム10は、1台以上のクライアント(PCなどの端末)102-1〜102-nと、メールの送受信を制御するメールサーバ104と、紙の書類の印刷、複写およびスキャンを行う複合機106と、そしてこれらの機器で収集されるさまざまなログを管理する来歴管理サーバ100を有する。また、これらの機器はネットワーク108に接続しており、ネットワーク108を介してデータを授受する。

なお、本実施例においては、来歴管理システム10はメールサーバ104もしくは複合機106を備えなくても構わない。また、ログを収集する別の装置がネットワーク108に接続されていてもよい。以降、そのような場合についても適宜補足する。

図２は、来歴管理システムを構成するクライアントおよびサーバの構成図の一例である。クライアント102(図1のクライアント102-1〜102-nの代表)は、ファイル操作監視プログラム220aと、ファイル操作ログDB222aと、ファイル操作ログ送信サービス224a、およびプリンタドライバ220bと、印刷ログDB222bと、印刷ログ送信サービス224bとを含む。

ファイル操作監視プログラム220aは、クライアント102のOSやファイルシステムを監視して、ファイルの作成、編集、削除などのファイル操作に関するログを取得するプログラムである。監視して得られたログ情報はファイル操作ログDB222aに格納され、ファイル操作ログ送信サービス224aによって、来歴管理サーバ100に送信される。

プリンタドライバ220bは、クライアント102に格納された電子ファイルを印刷する際にその印刷ログを取得するプログラムである。得られた印刷ログは印刷ログDB222bに格納され、印刷ログ送信サービス224bによって来歴管理サーバ100に送信される。

メールサーバ104は、メール送受信監視プログラム240、メール送受信ログDB242、およびメール送受信ログ送信サービス244を含む。メール送受信監視プログラム240は、メールサーバ104が配信するメールを監視してログを取得するプログラムである。得られたログはメール送受信ログDB242に格納され、メール送受信ログ送信サービス244によって来歴管理サーバ100に送信される。

複合機106は、複写監視プログラム260a、複写ログDB262a、複写ログ送信サービス264a、およびスキャン監視プログラム260b、スキャンログDB262b、スキャンログ送信サービス264bを含む。複写監視プログラム260aは、複合機106での紙の書類の複写を監視してログを取得するプログラムである。得られたログは複写ログDB262aに格納され、複写ログ送信サービス264aによって来歴管理サーバ100に送信される。

スキャン監視プログラム260bは、複合機106での紙のスキャン(電子化)を監視してログを取得するプログラムである。得られたログはスキャンログDB262bに格納され、スキャンログ送信サービス264bによって来歴管理サーバ100に送信される。

なお、各種ログを取得する各プログラムは、各々のDBにログを格納せずに、各送信サービスを介して来歴管理サーバ100に取得したログを送信してもよい。この場合、各々のDB222a、222b、242、262a、262bは不要になる。

上述のような監視プログラムによって、ファイル操作ログ、印刷ログ、メール送受信ログ、および複写ログ、スキャンログが、来歴管理サーバ100に送信されることになる。以下、これら様々なログを総称して「来歴」と呼ぶ。

来歴登録サーバ100は、クライアント102、メールサーバ104、複合機106より送信される来歴200を受信して、来歴DB282に登録する来歴登録サービス284と、来歴200を格納する来歴DB282と、来歴DB282に格納された来歴を検索する来歴検索プログラム280を含む。

以上の説明から分かるように、ファイル操作監視プログラム220aによって監視されるファイル操作は、ファイルの生成、削除、内容の更新などのコンテンツの内容に係る操作（生成の場合は内容が無し（Null）の状態から内容が作成され、削除の場合はその逆）を含むが、他の監視プログラムによる操作ログに記録される操作によっては、コンテンツの移動、数の増加、媒体の変更（電子ファイルと紙ファイルとの変更）などがあるが、コンテンツの内容自体を更新されない。たとえば、複合機106による複写の場合、複写日時を印刷する複合機が存在するが、ここではコンテンツのないようそのものを更新しているとは見なさない。したがって、図1および図2を用いて説明した来歴管理システム10は、ファイルシステムのようなコンテンツの内容を更新するシステムと、コンテンツの内容の更新に係らない他のシステムとを含むことになる。

図3は、来歴管理システム10のブロック図である。クライアント102は、前述の各種プログラムの実行などを行うCPU302aと、データやプログラムを一時的に記憶しCPU302aが直接読み書きするメモリ304aと、クライアント102の電源を切ってもデータやプログラムが消失しないように保存しておくための記憶装置306aと、有線あるいは無線でネットワーク108と通信を行う通信部308aと、クライアント102の利用者にデータの計算、加工の結果をディスプレイなどに表示するための表示部310aと、当該利用者からのキーボード入力やマウス入力などを受け付けるための操作部312aと、USBメモリやCD-Rなどの可搬媒体へのデータの読み書きを行うための可搬媒体接続部314aとが、バス300aに接続される。

図2のプログラム220a、ドライバ220b、サービス224aおよび224bは、メモリ304aもしくは記憶装置306aに格納されて、CPU302a上で実行される。DB222aおよび222bは、記憶装置306a上に実装される。さらにサービス224aおよび224bは、記憶装置306aに格納されたログを、通信部308aを介して来歴管理サーバ100へ送信する。

サーバ110は、来歴管理サーバ100およびメールサーバ104の構成に相当する。サーバ110は、CPU302bと、メモリ304bと、記憶装置306bと、通信部308bと、表示部310bと、操作部312bとが、バス300bに接続されたハードウェア構成を持つ。図2のプログラム240および280、サービス244および284は、メモリ304bもしくは記憶装置306bに格納されて、CPU302b上で実行される。DB242および282は記憶装置306b上に実装される。また、サービス244および284は、通信部308bを介してログを授受する。

なお、複合機106は、サーバ110の構成に、印刷やスキャンなどの機構を加えたものである。

以下、図4〜6を用いて、ファイル操作監視プログラム220が取得するファイル操作ログの内容について説明する。

図4は、ファイル操作ログの一例である。図4(a)は、ファイルをコピーした場合のファイル操作ログの例である。ファイル操作ログは、ユーザ操作を表すイベント400aと、イベント400aが発生した時刻402aと、イベント400aが発生する前のファイル情報を表す404aと、イベント400aが発生した後のファイル情報を表す406aなどで構成される。イベント発生前ファイル情報404aは、イベントが発生したクライアントの識別情報440a、ファイルのパス名442a、ファイル名444a、ドライブ種別446aなどで構成される。イベント発生後ファイル情報406aも同様に、クライアントの識別情報460a、ファイルのパス名462a、ファイル名464a、ドライブ種別466aなどで構成される。

ここで、本明細書で用いる用語を定義しておく。

クライアント102、複合機106などを総称して「ホスト」とよぶ。あるホストから見てネットワーク108に接続された別のホストのことを「外部ホスト」とよぶ。

また、ホストのIPアドレス、MACアドレスや、名称など、ホストをネットワーク108上で一意に識別するための識別情報を総称して「ホスト識別情報」とよぶ。

さらに、ホスト識別情報、パス名、ファイル名、ドライブ種別など、ホスト内にあるファイルを識別するための情報を総称して「ファイル情報」とよぶ。

特に、ドライブ種別として、クライアント内に存在して外部からアクセスできない「ローカルドライブ」や、外部からアクセス可能な「ネットワークドライブ」、可搬媒体上のドライブであることを示す「リムーマブルドライブ」などがある。

そして、ファイル情報から来歴管理システム10内のファイルを一意に特定できる場合、このファイル情報は「完全」であるという。例えば、ホスト識別情報、パス名、ファイル名が明示されたファイル情報は完全となる。逆に、例えばファイル名しか含まないファイル情報は「不完全」となる。

図4(a)は、2008年4月28日10時21分14秒に、「PC-123」という名称のクライアントで、ローカルドライブ上のフォルダ「C:\MyDocuments」の下の「readme.txt」というファイルがコピーされて、「C:\DeskTop\readme.txt」というファイルが生成されたというイベントを表す。

図4(a)の例では、イベント発生前ファイル情報404a、イベント発生後ファイル情報406aとも1つのファイルで構成されたが、ファイルが存在しない場合や複数となる場合もある。例えば、イベント400aがファイルの新規作成であれば、イベント発生前ファイル情報404aは存在せず、カラム440a〜446aは空となる。また、イベント400aがファイルの削除でれば、イベント発生後ファイル情報406aは存在せず、カラム460a〜466aは空となる。

図4(b)は、イベント発生前のファイルが複数である一例である。イベント400bが圧縮の場合、1つ以上のファイルが圧縮されて、纏まった1つのファイルが生成されるとき、イベント発生前ファイル情報404bは1つ以上のファイル情報で構成される。

図5は、可搬媒体や外部ホストのファイルが関係する操作ログの一例である。

図5(a)は、可搬媒体上のファイルをクライアントにコピーした場合のログの一例である。ドライブ種別546aに、リムーバブルドライブの識別情報「USB-001」が記載されている。

図5(b)は、ネットワーク経由で他のクライアントのフォルダにファイルをコピーした場合のログの一例である。イベント発生後のホスト識別情報560bがイベント発生前と同じ「PC-123」となっており、パス名562bが「Z:\Public」となっている。一般にWindows（登録商標）などのOSでは、他のホストのフォルダをネットワークドライブとして「Z:\」などを割り当てることが可能であるため、パス名562bからホスト識別情報560bを特定できるわけではない。そのため、ネットワークを介してファイルをコピーした場合、図5(b)のようなログだけから、どのクライアントへファイルがコピーされたかを追跡できない。

図6は、ファイル操作ログの一例であり、誤ったファイル操作ログが収集される例である。

図6(a)は、メールの添付ファイルを保存した場合のログの一例である。前述したように、ファイル操作監視プログラム220は、クライアント102のOSやファイルシステムを監視してログを収集するため、クライアントのユーザがメールの添付ファイルを保存した場合、メーラによってファイルが生成されたところまではログを取得できるが、それがどのメールの添付ファイルであるかを特定することは、原理上困難である。その結果、添付ファイルの保存というユーザ操作は、図6(a)のイベント600aのようにファイルが「新規作成」されたものとして、誤ってログが取られる可能性がある。

また、ネットワーク経由で外部ホストからファイルをコピーされた場合も、もしOSがその外部ホストを識別できないのであれば、どの外部ホストからファイルがコピーされたかを知ることはできない。このとき、外部ホストからのファイルコピーという操作は、図6-(b)のパス名662bのフォルダにファイルが「新規作成」されたものとして、誤ってログが取られる可能性がある。これらのように不正確なログが収集された場合でも、来歴を追跡可能であることを後述する。 図7は、(a)メール送受信ログの一例及び(b)印刷ログの一例である。

図7(a)のメール送受信ログは、外部へのメール送信か外部からのメール受信かを表すイベント700aと、イベント700aが発生した時刻702aと、メールのメッセージID704aと、メールの送信先のメールアドレス706aと、カーボンコピー先のアドレス708aと、ブラインドカーボンコピー先のアドレス710aと、メールの送信元のアドレス712aと、添付ファイル名714aなどで構成される。メールアドレス706a、708a、710aおよび添付ファイル714aは複数となる可能性がある。

なお、イベント700aがメール受信であった場合、ブラインドカーボンコピー先のメールアドレス710aは、メールサーバ104にメールを送信した外部のメールサーバによって消去されているため取得できない。

図7(a)の例は、2008年4月28日10時21分14秒に、「attachment1.txt」「attachment2.txt」などのファイルが添付されたメッセージIDが「48F697B8.5000406@in.com」のメールが、メールアドレス「ddd@in.com」のユーザから、アドレス「aaa1@out1.com」「aaa2@out2.com」などへ送信、「bbb1@out3.com」「bbb2@out4.com」などへカーボンコピー送信、「ccc1@out5.com」「ccc2@out6.com」などへブラインドカーボンコピー送信されたというメール送信イベントを表している。

図7(b)の印刷ログは、印刷というイベントが発生したことを表すイベント700bと、印刷イベント700bが発生した時刻702bと、印刷元のファイル情報704bと、印刷して生成された紙文書を識別するための情報706bなどで構成される。印刷元のファイル情報704bは、ホスト識別情報740bと、パス名742bと、ファイル名744bと、ドライブ種別746bなどで構成される。印刷して生成された紙文書を識別するための情報706bは、ホスト(プリンタもしくは複合機)の識別情報760bと、紙文書を識別するためのID762bなどで構成される。

紙文書ID762bは印刷された紙文書を識別するためのIDで、紙文書の背景部に直接書き込まれたり、バーコードの形で印字されたり、もしくは電子透かしの形で目立たないように紙文書全体に埋め込まれたりする。

図7(b)は、2008年4月28日10時21分14秒に、「PC-123」という名称のクライアントで、ローカルドライブ上のファイル「C:\MyDocuments\readme.txt」が、「Printer-456」という名称のプリンタで印刷されて、128ビットのID「29E548C7-E81F-4464-A7DC-B3CA0DCA381E」が印字された紙文書が生成されたことを表している。

以下、ホスト識別情報、紙文書IDなど紙の入出力に関するログをまとめて「紙文書情報」とよぶ。また、ファイル情報、紙文書情報などコンテンツに関する情報を総称して「コンテンツ情報」とよぶ。そして、紙文書情報から来歴管理システム10内の紙文書を一意に特定できる場合、この紙文書情報は「完全」であるという。例えば、紙文書IDがプリンタで出力された紙の通し番号であれば、ホスト識別情報と紙文書IDがともに明示されたときに完全となる。

図8は、(a)紙の複写ログの一例及び(b)紙のスキャンログの一例である。図8(a)の複写ログは、紙の複写というイベントが発生したことを表すイベント800aと、イベント800aが発生した時刻802aと、複写元を識別するための情報804aと、複写先を識別するための情報806aなどで構成される。複写元を識別するための情報804aは、ホスト(複写機もしくは複合機)の識別情報804aと、複写元の紙文書ID842aなどで構成される。複写先を識別するための情報806aも同様に、ホスト識別情報860aと、複写して生成された紙文書のID862aなどで構成される。

図8(a)の例は、2008年4月28日10時21分14秒に、「MFP-456」という名称の複合機で、紙文書ID「29E548C7-E81F-4464-A7DC-B3CA0DCA381E」の紙が複写されてID「11941F48-9B6D-4276-A5E7-D1DBD0A60FD4」の紙が生成されたことを表している。

図8(b)の紙のスキャンログは、紙のスキャンというイベントが発生したことを表すイベント800bと、イベント800bが発生した時刻802bと、スキャン元を識別するための情報804bと、スキャンして生成されたファイルに関する情報806bなどで構成される。スキャン元を識別するための情報804bは、ホスト(スキャナもしくは複合機)の識別情報840bと、スキャン元の紙文書ID842bなどで構成される。スキャンして生成されたファイルの情報806bは、生成ファイルが存在するホストの識別情報860bと、パス名862bと、ファイル名864bと、ドライブ種別866bなどで構成される。

図8(b)の例は、2008年4月28日10時21分14秒に、「MFP-456」という名称の複合機で、紙文書ID「29E548C7-E81F-4464-A7DC-B3CA0DCA381E」の紙がスキャンされて、「PC-123」という名称のクライアントのネットワークドライブ上に、ファイル「C:\Public\scan.pdf」が生成されたことを表している。

図4〜図8で説明したさまざまログ(来歴)は、来歴管理サーバ100の来歴DB282に格納される。図9は、来歴DB282のデータ構造の一例である。

来歴DB282は、図4〜図6のようなファイル操作ログを格納するファイル操作ログテーブル900と、図7(a)のようなメール送受信ログを格納するメール送受信ログテーブル902と、図7(b)のような印刷ログ、図8(a)のような複写ログ、図8(b)のようなスキャンログを格納する紙文書ログテーブル904とで構成される。

図7(b)、図8(a)、図8(b)で例示したように、印刷ログ、複写ログ、スキャンログのデータ構造は一般には異なるため、紙文書ログテーブル904として、印刷ログ、複写ログ、スキャンログの構成要素(項目)の和集合を準備する。すなわち、紙文書ログテーブル904は、イベント発生前およびイベント発生後の情報として電子ファイルだけではなく紙文書にも対応できるように、ホスト識別情報、パス名、ファイル名、ドライブ種別、および紙文書IDを表すカラムを有する。例えば複写ログを紙文書ログテーブル940に登録する場合、イベント発生前の情報でのパス名、ファイル名、ドライブ種別などを無効値として登録しておく。

なお、ファイル操作ログにおいても、パス名が取得できないなどといったように、ログに含まれる情報が不完全であっても構わない。不完全である場合、その対応するカラムを空にして来歴DB282に登録する。

また、別の種類のログを収集する装置がネットワーク108に接続されている場合、来歴DB282は、そのログを格納するテーブルも含んでもよい。

また、テーブル900、902、904の分類もあくまで一例であり、類似したデータ構造を持つログをまとめたものである。例えば、もしファイル操作ログテーブル900とメール送受信ログテーブル902を1つのテーブルに統合する場合は、上述の紙文書ログテーブル904の例と同様、統合対象となる複数のログの構成要素の和集合をもつテーブルを準備すればよい。

以下、来歴DB282は図9に示すデータ構造を持つものとして、メール送受信ログテーブル902、紙文書ログテーブル904がない場合、他のテーブルが存在する場合での処理手順については適宜補足することにする。

図10は、(a)コンテンツのトレースを行う来歴検索プログラム280の構成図の一例及び(b)インターフェース1020の一例である。

来歴検索プログラム280は、来歴を検索する検索部1000と、検索条件の入力を受け付ける検索条件入力部1002と、来歴DB282との通信を行う通信部1004と、検索結果を一時的に格納する検索結果スタック1006と、検索結果を表示する検索結果表示部1008を含む。検索結果スタック1006の動作については、後に図15を用いて詳しく説明する。

図10は、検索条件入力部1002からの入力を受け付け、検索結果表示部1008からの出力を表示するための、来歴検索プログラム280のインターフェース1020の一例である。

インターフェース1020は、来歴の検索条件をユーザが指定するための検索条件指定領域1022と、検索条件にヒットしたログを表示するためのログ表示領域1040と、ヒットしたログをグラフィカルに表示して、コンテンツのトレースを行うための来歴トレース領域1060とで構成される。

検索条件指定領域1022は、検索対象となるログの種別を指定する領域1024a〜1024cと、時刻の検索範囲(期間)を指定する領域1026と、クライアントや複合機などのIPアドレス、名称などといったホスト識別情報を指定する領域1028と、ファイル情報や紙文書情報を指定する領域1030などで構成される。

図10(b)の例では、ログの種別としてファイル1024aが選択されている(図中、ハッチング)ので、ファイル操作ログテーブル900のうち、2001年1月1日0時0分0秒から2008年9月12日23時59分59秒の範囲の、「PC-123」という名称のクライアントで、ファイル「readme.txt」を含むログを検索することになる。

なお、領域1028と1030においては、部分一致、完全一致などを指定できるようにする、正規表現を受け付けるなどの拡張があっても良い。また、領域1028と1030を1つにまとめて、指定されたキーワードをログ中のいずれかのカラムに含むログを全て抽出するといった変形もある。

検索条件指定領域1022で指定された検索条件は、検索条件入力部1002を介して検索部1000にて検索される。そして、検索条件にヒットしたログの一覧は、検索結果表示部1008を介して、ログ表示領域1040に表示される。

図10(b)の例では、イベントが新規作成のログ1041と、イベントがファイルコピーのログ1042などが表示されている。ログ1041、1042ともに、ファイル名「readme.txt」を含んでいる。

ユーザがログ表示領域1040からログを選択すると、来歴トレース領域1060に選択したログの内容が図示される。来歴トレース領域1060内に表示されているノード1062〜1066および矢印1068は、ログ1042を選択した場合の表示の一例である。親ノード1062はイベント発生前のファイルに関する情報を、子ノード1064はログ1042のイベント情報を、孫ノード1066はイベント発生後のファイルに関する情報をそれぞれ表しており、矢印1068によって、ノード1062からノード1066が派生したことを示している。

図10(b)の例では、選択された（図中、ハッチング）ログ1042は、ファイル「C:\readme.txt」を「C:\work.txt」にコピーしたというログであることが容易に理解できる。

なお、来歴トレース領域1060に表示されているノードにはファイル名、イベント名しか表示されておらず、ファイル情報やログ情報の詳細を省略しているが、例えば、詳細もノードに表示する、ノード1062〜1066を選択したときにポップアップもしくは別のダイアログで詳細を表示するなどと拡張しても良い。

図11に示すログ表示のフローチャートを用いて、ログ表示領域1040で選択されたログを来歴トレース領域1060に表示する処理手順について説明する。以降のステップは、検索部1000が実行する。ステップ1100にて、来歴トレース領域1060に表示するためのノードを3種類準備する。表示する上から順に、親ノード、子ノード、孫ノードとよぶ。

ステップ1102にて、ログ表示領域1040で選択され、来歴トレース領域1060に表示対象となるログが属するテーブルを調べる。ファイル操作ログテーブル900に属する場合はステップ1104aへ、メール送受信ログテーブル902に属する場合はステップ1104bへ、紙文書ログテーブル904に属する場合はステップ1104cへ進む。

表示対象となるログがファイル操作ログテーブル900に属する場合、イベント発生前やイベント発生後のファイルが存在しないことがある。そこで、ステップ1104aにて、イベントが新規作成かどうかを調べる。新規作成以外ではイベント発生前のファイルが存在するため、イベント発生前のファイル情報を親ノードに記載する。新規作成である場合は親ノードを空にする。ノードを空にするとは、ノード自体を表示しないことや、ノードに情報がないことを明記することである。

ステップ1106aにて、イベントに関するログ情報を子ノードとする。ステップ1108aにて、イベントが削除かどうかを調べる。削除以外ではイベント発生後のファイルが存在するため、イベント発生後のファイル情報を孫ノードに記載する。削除である場合は孫ノードを空にする。ステップ1104a〜1108aを完了した後、ステップ1110へ進む。

表示対象となるログがメール送受信ログテーブル902に属する場合、ステップ1104bにて、ログがとられているメールに添付ファイルが存在すれば、この添付ファイルに関する情報を親ノードとする。存在しなければ親ノードを空とする。

ステップ1106aにて、イベントに関するログ情報を子ノードとする。ステップ1108aにて、メール情報を孫ノードとする。ステップ1104b〜1108bを完了した後、ステップ1110へ進む。

表示対象となるログが紙文書ログテーブル904に属する場合、イベントによってノードの内容がファイルになったり紙になったりする。ステップ1104cにてイベントが印刷かどうかを調べ、印刷である場合はイベント発生前のファイル情報を、印刷でない場合はイベント発生前の紙文書情報を、親ノードに記載する。

ステップ1106cにて、イベントに関するログ情報を子ノードとする。ステップ1108cにて、イベントがスキャンかどうかを調べ、スキャンである場合はイベント発生後のファイル情報を、スキャンでない場合はイベント発生後の紙文書情報を、孫ノードとする。ステップ1104c〜1108cを完了した後、ステップ1110へ進む。

来歴DB282が他のテーブルを具備している場合にも、上記のように、イベント発生前の情報が存在すれば、それを親ノードとし、ログ情報を子ノードとし、イベント発生後の情報が存在すれば、それを孫ノードとすれば良い。

ステップ1110で、親ノードと子ノード、および子ノードと孫ノードをそれぞれ連結して表示して、ログを来歴トレース領域1060に表示する処理が完了する。各ノードの連結及び表示において、ファイルの圧縮のように親ノードが複数となる場合、ファイルを複数部数印刷したときのように孫ノードが複数となる場合もある。

図12は、図11のログを表示する処理手順を実行した結果の、来歴トレース領域1060へのログの表示例である。

図12(a)は、「readme.txt」というファイルを新規作成したというファイル操作ログの表示例である。イベント発生前ファイルが存在しないため、親ノードが表示されていない。

図12(b)は、図4(b)の圧縮ファイル作成ログの表示例である。イベント発生前ファイルが複数存在するため、複数の親ノードがある。

図12(c)は、ファイルが添付されていない、メールID「メール001」のメールを送信したというメール送信ログの表示例である。添付ファイルが存在しないため親ノードが表示されていない。添付ファイルがある場合の表示例が図12(d)である。添付ファイルが複数存在するため複数の親ノードがある。

図12(e)は、「readme.txt」というファイルを印刷して、紙文書ID「紙文書001」の紙が生成されたという印刷ログの表示例である。複数部数を印刷した場合、孫ノードは複数となる。

図12(f)は、紙文書ID「紙文書001」の紙を複写して、紙文書ID「紙文書002」の紙が生成されたという複写ログの表示例である。複数部数を複写した場合、孫ノードは複数となる。

図12-(g)は、紙文書ID「紙文書002」の紙をスキャンして「scan.pdf」という電子ファイルが生成されたというスキャンログの表示例である。複数の紙文書をまとめてスキャンした場合には、親ノードが複数となる。

検索部1000が図11のフローチャートに従って動作した結果、ログが図12のように来歴トレース部1060に表示される。本実施例は、来歴DB282に格納された来歴情報をもとに、来歴トレース部1060に表示されたコンテンツをトレースする。トレースの結果は、来歴トレース部1060に表示済みのノードに連結して図示される。

トレースには、コンテンツの親を追跡していく「バックトレース」と、コンテンツの子を追跡していく「フォワードトレース」の2種類がある。まずバックトレースの処理手順について、図13を用いて説明する。図13のバックトレースの処理は、検索部1000が通信部1004を介して来歴DB282をDB操作することで実行する。

ここで用語を定義しておく。バックトレースの基点とするノードを「基点ノード」、基点ノードが表しているログを「基点ログ」とよぶ。基点ノードが表すファイル情報、紙文書情報などのコンテンツ情報を「基点ノード情報」とよぶ。

また、ログ内のイベント発生前のコンテンツ情報とイベント発生後のコンテンツ情報がともに完全であるとき、ログが「完全」という。完全でないログを「不完全」であるという。「不完全」なログとは、以下に説明する操作来歴のトレースにおいて、基点ノードからの操作来歴として関連している可能性があるものの、曖昧さ（不確実さ）があるログである。

ステップ1300にて、基点ノードの親ノードがすでに表示されており、かつどちらのノードも完全である場合、表示されている親ノードがバックトレースの唯一正しい結果であるため、検索処理を終了する。

なお、表示されている親ノードが不完全であった場合、その親ノードだけが正しいトレース結果とは限らない。よって、親ノードがすでに表示されていたとしても、それが完全でなければ、次のステップ1302に進んでバックトレースを行う。このことについては、図21を用いて後で説明する。

ステップ1302にて、基点ノードのコンテンツの種類を調べる。基点ノードの種類がファイルのときステップ1304aへ、紙文書のとき1306bへ進む。なお、基点ノードがメールである場合、メール送受信ログは、親ノードに添付ファイル、子ノードにログ、孫ノードにメール情報が記載される形式で表示されるので、添付ファイルが存在すれば、すでに添付ファイルの情報が完全ログとして表示されている。この場合、ステップ1300にてすでに検索処理は終了している。したがって、本ステップでは基点ノードがメールの場合を考慮する必要はない。

基点ノードがファイルのとき、ステップ1304aにて、基点ログに応じた処理を行う。例えば図6 (a)で説明したように、基点ログのイベントが新規作成であっても、実際にはメールの添付ファイルの保存など別のイベントである可能性がある。そこで本ステップにて、基点ログに応じて、ファイル操作ログ以外のテーブルを参照するなどといった対応を行う。詳細については図14を用いて後で説明する。

ステップ1306aにて、ファイルのバックトレースを行う。すなわち、基点ノードがファイルなので、ファイル操作ログテーブル900を参照して、以下の条件を全て満たすファイル操作ログを抽出する：
(1) イベント発生時刻が基点ログのイベント発生時刻以前である。
(2) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

該当するログが存在した場合、基点ノードのファイル情報とイベント発生後のファイル情報がともに完全で、かつ同一のファイルを指している場合、完全ログとして検索結果スタック1006に出力する。そうでないのであれば、不完全ログとして出力する。出力後、ステップ1308へ進む。

なお、条件(1)でイベント発生時刻を比較するが、来歴管理システム10を構成する全てのホストで同一の時刻を保っている保証はないため、「以前」とみなすための許容範囲を、来歴検索プログラム280内であらかじめ「10秒」などと定めておく、来歴検索プログラム280起動時に引数や設定ファイルで渡される、インターフェース1020で入力部を準備しておく、などにより指定する。

また、条件(2)ではファイル名を照合するが、ファイル名はファイルを特定するために最低限必要な情報であり、かつ、イベントによってはログを完全に収集できない場合を考慮したためである。図14を用いて後述するように、本実施例では、不完全なログに対してはファイル名を照合し、ヒットした検索結果を全て「候補」として表示するので、本ステップでもファイル名を照合し、ヒットしたログを全て検索結果スタック1006に格納する。

基点ノードが紙文書である場合のステップ1306bも同様で、紙文書ログテーブル904を参照して以下の条件を全て満たす紙文書ログを抽出し、該当するログが存在する場合、および基点ノードのコンテンツ情報とイベント発生後のコンテンツ情報がともに完全である場合に完全ログとして、そうでない場合に不完全ログとして、検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻以前である。
(2) 基点ノードが紙文書である場合、イベント発生後の紙文書IDが基点ノード情報の紙文書IDに一致する。基点ノードがファイルである場合、イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

なお、条件(2)では、基点ノードが紙文書である場合に紙文書IDを照合するが、これもステップ1306aと同様、紙文書IDは紙を識別するための最低限必要な情報であり、かつ、イベントによってはログを完全に収集できない場合を考慮したためである。

最後にステップ1308にて、検索結果スタック1006に格納された検索結果を表示して、バックトレース処理を終了する。ステップ1308の詳細については図15を用いて後で説明する。

図14は、ステップ1302a（バックトレースにおける基点ログに応じた処理）の詳細のフローチャートである。ステップ1400にて、基点ログの種類を調べる。図5、6を用いて説明したように、イベントが新規作成であったり、外部ホストや可搬媒体上のファイルを授受したときに、ログは不正確になったり、不完全になったりする。そこで基点ログのイベントを調べ、イベントが新規作成のときにステップ1402へ、ファイルコピーもしくはファイル移動の場合にステップ1410へ進む。それ以外の場合はステップ1302aの処理を終了する。

ステップ1402にて、基点ノードのドライブ種別を調べる。図6(b)に示したように、ドライブ種別がネットワークドライブである場合、ネットワーク108経由で外部のホストからファイルがコピーもしくは移動された可能性があるため、ステップ1404へ進む。そうでない場合はステップ1406へ飛ぶ。なお、基点ログがドライブ種別を取得できていない場合も、ステップ1404へ進んで外部ホストの検索を行う。

ステップ1404では、外部ホストからのファイルコピー/移動の検索を行うために、以下の条件を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻の近傍に存在する。
(2) イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

外部ホストからのファイルコピー/移動の時刻とそれによるファイル作成の時刻はほぼ同じなので、条件(1)でイベント発生時刻が近傍のログを検索する。

なお、条件(1)で「近傍」とみなす時間範囲は、ステップ1306aで説明したとおり、来歴検索プログラム280内であらかじめ「1分」などと定めておく、来歴検索プログラム280起動時に引数や設定ファイルで渡される、インターフェース1020で入力部を準備しておく、などにより指定する。

また、図5(b)を用いて説明したように、外部ホストから見た場合、ファイルコピー/移動先のホスト識別情報およびパス名は必ずしもコピー先のクライアントを指すわけではないので、条件(3)でファイル名を用いて検索する。ホスト識別情報はファイル名と比較して不正確であるため利用しない。

このようにログが不完全である場合に、ファイルを特定するために最低限必要なファイル名を手がかりに検索する。このファイル名を用いた検索では、抽出したログは必ず不完全となる。処理が完了後、ステップ1406へ進む。

ステップ1406では、メール添付ファイル保存の検索を行う。そのために、メール送受信ログテーブル902を探索し、以下の条件を全て満たすログを不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻以前である。
(2) 基点ノード情報のファイル名に一致する添付ファイルが存在する。

メールの添付ファイルを保存するのは必ずメール受信後となるので、条件(1)でログを検索する。また、本ステップもファイル名を用いた検索であるので、抽出したログは必ず不完全となる。処理が完了後、ステップ1408へ進む。

ステップ1408では、スキャン画像保存の検索を行う。外部ホストからのファイルコピー/移動と同様、もしクライアントのOSが複合機106を識別できないのであれば、どのホストからファイルがコピーされたかを知ることはできない。このとき、複合機106からのスキャン画像保存という操作は、スキャン画像ファイルが「新規作成」されたものとして、誤ってログが取得される可能性がある。そこで本ステップでは、複合機106からのスキャン画像保存の検索を行うために、以下の条件を全て満たす紙文書操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻近傍に存在する。
(2) イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

各条件の意味はステップ1404の場合と同じなので、説明を省略する。以上のステップで基点ログに応じた処理ステップ1304aが終了する。

ステップ1410、1412では、外部ホストや可搬媒体からのファイルコピー/移動を検索する。

ステップ1410では、基点ノードのドライブ種別がネットワークドライブである場合、もしくはドライブ種別を取得できなかった場合に、ステップ1404と同様、以下の条件を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻以前である。
(2) イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

この場合も、基点ログや検索対象ログ内に含まれるホスト識別情報およびパス名は不正確である可能性があるので、本実施例では利用しない。後の実施例2で、ホスト識別情報やパス名を利用する例について説明する。

次のステップ1412では、基点ノードのドライブ種別がリムーバブルドライブである場合、もしくはドライブ種別を取得できなかった場合に、以下の条件を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻以前である。
(2) イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がリムーバブルドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。
(4) リムーバブルドライブの識別情報が、イベント発生後のファイル情報と基点ノード情報とに存在し、双方のリムーバブルドライブの識別情報が一致する。

リムーバブルドライブの識別情報が取得できれば、ファイル名のほかにこの識別情報を用いてより確実にログを検索する。逆に、基点ノードのドライブ種別が取得できなかった場合は、ステップ1410、1412両方でファイル操作ログテーブル900を検索することになる。また、基点ノードのドライブ種別が上記以外である場合は何もしないことになる。以上で基点ログに応じた処理ステップ1304aを終了する。

図13、14の処理では、ファイル名をキーにログを検索するため、同じファイル名である不要なログを検索する可能性がある。そのため本実施例では、不完全なログを検索結果の候補として表示する。

この場合、例えばネットワークドライブ上のフォルダにメールの添付ファイルを保存し、さらに保存した添付ファイルを削除し、別途ネットワークドライブ上の同じフォルダに同名ファイル（添付ファイルと同名のファイル）を外部ホストからコピーされた場合、バックトレースの結果、メール送受信ログとファイルコピーのログが同時にヒットする。そこで上記では、ログがヒットしても、検索結果スタック1006に格納するだけで検索処理を続行し、全て表示することにする。

なお、フォルダ、可搬媒体、メールなどの、ファイルの格納環境に依存しないような「特徴値」がログとして収集されているのであれば、ファイル名の代わりにその特徴値を利用してもよい。この場合、不要なログを検索する可能性が低減して、より高精度にトレースを行うことができる。

また、図13、14の処理では、ドライブ種別がログとして取得できなかった場合、ファイル名をキーに検索を行うことになるが、これではヒットするログが多すぎて、候補を絞り込めない可能性がある。この場合、以下のようにする。
(a) ステップ1404、1408、1410、1412の全てもしくは一部の処理を行わない。
(b) ドライブ種別の代わりにホスト識別情報とパス名を用いて、各ステップにて上述の条件を満たし、さらに基点ノードのホスト識別情報およびパス名と、検索対象ログのイベント発生後のホスト識別情報およびパス名とがそれぞれ一致する場合に、検索結果スタック1006にログを出力する。

本実施例では、図5(b)のような例があるためホスト識別情報やパス名を利用しなかったが、(b)を実施することで、ホスト識別情報およびパス名が正しく取得できているログに関してのみ、トレースが成功するようになる。(b)については後の実施例2で詳しく説明する。

図13、14では、来歴DB282がログテーブル900、902、904を備えることを前提として、バックトレースの処理を説明した。その要点は以下の通りである。
・イベントが新規作成などで親ノードが存在しない場合、他のテーブルも探す。
・ファイル名や紙文書IDなど、コンテンツを特定するために最低限必要な情報が一致したログを全て出力する。
・イベント発生時刻、ドライブ種別などの情報も正確性が保証されていれば利用する。
・ホスト識別情報、パス名など正確性が保証できない情報はできるだけ利用しない。

来歴DB282が図9に記載したデータ構造でないとしても、この要点を基に、コンテンツのバックトレースを行い、候補を求めることが可能になる。

図13、14を用いて説明したように、検索結果一式は検索結果スタック1006に格納される。図15を用いて、格納された検索結果一式を表示するためのステップ1308(検索結果表示)の処理手順を説明する。なお、この処理は、検索部1000が検索結果スタック1006を参照しつつ実行する。

ステップ1500にて、検索結果スタック1006内にログが存在するかを検証する。存在すればステップ1502aへ、存在しなければステップ1502cへ進む。

検索結果スタック1006にログが存在しなかった場合、ステップ1502cにて、バックトレースの候補となるログが存在しなかった旨を表示して、ステップ1308の検索結果表示処理を終了する。

ログが存在する場合、ステップ1502aにて、検索結果スタック1006内に完全ログが存在するかを調べる。完全ログが存在すればステップ1504aへ、存在しなければステップ1504bへ進む。

完全ログが存在すればそれが唯一正しいログであるため、まずステップ1504aにて、図11記載のステップ1100〜1112の手順で完全ログの親ノード、子ノード、孫ノードを求める。なお、求めた孫ノードは複数となる可能性があるため、当該孫ノードは基点ノードを含む。

次にステップ1506aへ進み、求めた子ノードが基点ノードの親となるように、かつ求めた孫ノードが基点ノードと同じレベルに表示されるように、連結して表示する。以上でステップ1308の検索結果表示処理を終了する。

検索結果スタック1006内に完全ログが1つも存在しなければ、検索結果スタック1006に格納されたログを全て候補として表示する。まずステップ1504bにて、図11記載のステップ1100〜1112の手順で、全てのログの親ノード、子ノード、孫ノードを求める。

そして、ステップ1506bにて、求めたノードを基点ノードに連結して表示する。ここで、例えば基点ログが新規作成であっても、図14の処理手順によってバックトレースした結果、メールの添付ファイルの保存というログが候補としてヒットする可能性がある。そこで本ステップでは、まず基点ログの種類を調べて、それぞれについて最適な検索結果の表示を行う。具体的には、基点ログが新規作成である場合ステップ1508bへ、それ以外の場合ステップ1510bへ飛ぶ。

ステップ1508bでは、新規作成イベントに対してバックトレースをした結果、メール添付ファイル保存などの不完全ログがヒットした場合の表示を行う。具体的には、求めた親ノード、子ノード、孫ノードを、表示されている「新規作成」イベントと、求めた子ノードとが並列になるように追加して表示する。後で図16(b)、図18(a)を用いて詳細を説明する。

一方のステップ1510bでは、新規作成以外のイベントで不完全ログがヒットした場合の表示を行う。例として、外部ホストからのネットワークを介したファイルコピーした場合があげられる。すなわち、例えば基点ノードのファイルが「Z:\readme.txt」のようにネットワークドライブ上にあり、パス名「Z:\」だけからクライアントを特定することが困難であっても、バックトレースの結果、「Z:\」の実体となるフォルダの候補を絞り込むことができるため、本ステップ1510bでは、基点ノードを適宜求めた孫ノードの情報で修正してから、求めた親ノード、子ノードを基点ノードの親として連結する。後で図17を用いて詳細を説明する。

以上でステップ1308の検索結果表示処理を終了する。

図13〜15のバックトレースの処理手順では、検索結果スタック1006に候補となるログを全て格納した後に、ログが完全であるかどうかなどを調べて来歴トレース領域1060への表示処理を行う。完全ログがヒットした場合、それが唯一正しいバックトレース結果であるから、ステップ1304a、1306a、1306bにおいて完全ログが見つかり次第、処理を終了して、求めた完全ログを表示してもよい。本実施例では、わかりやすさを優先して、最後にまとめてトレース結果を表示した。

図13〜15のバックトレース手順による検索結果の一例を図16〜18に示す。

図16(a)は、ファイル「sample.zip」のバックトレースをした結果、ステップ1306bでログが見つかり、ファイル「readme1.txt」「readme2.txt」「readme3.txt」の圧縮という完全ログがヒットした場合の表示例である。完全ログなのでこの圧縮イベントが唯一正しいトレース結果である。

図16(b)は、ファイル「attachment.txt」を新規作成したというログをバックトレースした結果、ステップ1406で、メール送受信ログテーブル902から添付ファイル名「attachment.txt」をもつログが2件ヒットした場合の表示例である。イベント「新規作成」の隣にヒットしたログが候補として追加されている。

なお、図13〜15のバックトレース処理で求まるのは、ノード1600a〜1604aおよび1600b〜1604bである。図16(b)の例より、求めたログの種類に応じて、ノード1606a、1606bを追加する、矢印1608を点線にして検索結果は候補に過ぎないことを明示する。求めたログの種類に応じたトレース結果の表示方法の詳細については説明を割愛する。

図17(a)は、ネットワークドライブ上のファイル「Z:\readme.txt」をファイルコピーしたというログのバックトレースした結果、ステップ1410で、ネットワークドライブ上にファイル名「readme.txt」というファイルをコピーしたというログが2件ヒットした場合の表示例である。パス名「Z:\」だけからクライアントを識別することは困難であるが、上述のバックトレース手順に従ってファイル名をキーに検索した結果、「PC-123」もしくは「PC-456」という名称のクライアントからのコピーであることまで限定できた。

図17(b)は、識別番号「USB-001」をもつ可搬媒体上のファイル「readme.txt」をファイルコピーしたというログのバックトレース結果である。ファイル名「readme.txt」および可搬媒体の識別番号「USB-001」をキーに検索した結果、ステップ1410でログが見つかり、「PC-123」もしくは「PC-456」という名称のクライアントから可搬媒体「USB-001」にファイルコピーしたということまで判明した。

図18(a)は、ネットワークドライブ上のファイル「C:\Public\readme.txt」を新規作成したというログのバックトレースした結果、ステップ1404で、外部ホスト「PC-123」もしくは「PC-456」からファイルコピーされたというログが2件ヒットした場合の表示例である。イベント「新規作成」の隣にヒットしたログが候補として追加されている。

図18(b)は、ネットワークドライブ上のファイル「C:\Public\scan.pdf」が新規作成されたというログをバックトレースした結果、ステップ1408でログが見つかり、紙文書ID「紙文書002」の紙をスキャンしたというログがヒットした場合の表示例である。イベント「新規作成」の隣にヒットしたログが候補として追加されている。

紙文書ID「紙文書002」の紙についてさらにバックトレースを行った結果、ステップ1306bより複写ログが見つかり、「紙文書002」は、紙文書ID「紙文書001」の紙を複写したことが判明した。このように、本実施例によれば、トレース結果をもとにコンテンツの操作元を追跡していくことが可能となる。

次に、コンテンツの子を追跡していくフォワードトレースの具体的な処理手順について、図19(a)を用いて説明する。なお、図19(a)のフォワードトレースの処理は、検索部1000が通信部1004を介して来歴DB282をDB操作することで実行する。

ステップ1900にて、基点ノードのコンテンツの種類を調べる。ファイルを添付してメール送信することがあるため、バックトレースと異なり基点ノードの子ノードとしてメールもありうる。基点ノードの種類がファイルのときステップ1902へ、メールのとき1904bへ、紙文書のとき1904cへ進む。

なお、フォワードトレースでは、仮に基点ノードの子ノードがすでに表示されていたとしても、表示後に新たな操作が行われる可能性があるため、子ノードの表示状況によらず常に検索を行う。

基点ノードの種類がファイルのとき、まずステップ1902にて、基点ログに応じた処理を行う。詳細については図19(b)を用いて後で説明する。

次にステップ1904aにて、ログテーブル900、904、906全てに対してフォワードトレースを行う。ここで全てのテーブルを参照するのは、ファイルはメールに添付されて送信されるかもしれないし、印刷されるかもしれないためである。具体的には、ログテーブル900、902、および904を参照して、以下の条件を全て満たすログを抽出する：
(1) イベント発生時刻が基点ログのイベント発生時刻以降である。
(2) イベント発生前のファイル名が基点ノード情報のファイル名に一致する。

バックトレースの場合と同様、来歴管理システム10を構成する全てのホストで同一の時刻を保っている保証はないため、「以後」とみなすための許容範囲は、来歴検索プログラム280内であらかじめ「10秒」などと定めておく、来歴検索プログラム280起動時に引数や設定ファイルで渡される、インターフェース1020で入力部を準備しておく、などにより指定する。

該当するログが存在したとき、基点ノードのファイル情報とイベント発生前のファイル情報がともに完全で、かつ同一のファイルを指している場合に、完全ログとして検索結果スタック1006に出力する。そうでない場合、不完全ログとして出力する。次にステップ1906へ進む。

基点ノードの種類がメールのとき、ステップ1904aにて、ファイルログ操作テーブル900の検索を行う。図6(a)で例示したように、メールの添付ファイルを保存するというイベントは、ファイル操作ログとしては新規作成イベントとして記録されるので、ファイルログ操作テーブル900のうち以下の条件を全て満たすログを、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻以降である。
(2) イベントが新規作成である。
(3) イベント発生後のファイル名が基点ログの添付ファイル名に一致する。

メールの添付ファイルを保存するのは必ずメール受信後となるので、条件(1)でログを検索する。また、検索時にファイル名を用いているので、抽出したログは必ず不完全となる。処理が完了後、ステップ1906へ進む。

基点ノードの種類が紙文書のとき、ステップ1904cにて、紙文書ログテーブル904を検索する。イベント発生前のコンテンツが紙文書となるイベントは複写かスキャンであるので、紙文書ログテーブル904のうち以下の条件を全て満たすログを抽出する：
(1) イベント発生時刻が基点ログのイベント発生時刻以降である。
(2) イベントが複写またはスキャンである。
(3) イベント発生前の紙文書IDが基点ログの紙文書IDに一致する。

該当するログが存在したとき、基点ノードの紙文書情報とイベント発生前の紙文書情報がともに完全で、かつ同一の紙文書を指している場合に限り、完全ログとして検索結果スタック1006に出力する。そうでない場合、不完全ログとして出力する。次にステップ1906へ進む。

最後にステップ1906にて、検索結果スタック1006に格納された検索結果一式を来歴トレース領域1060に表示する。表示のためのフローチャートは図15と同様で、基点ノードの親ではなく子に連結する点だけが異なる。そのため詳細については説明を省略する。なお、フォワードトレースの場合、図15のステップ1508bにて、表示されない「新規作成」イベントも新たに表示される。後で図20(b)を用いて具体例をあげる。

図19(b)は、ステップ1902を実行するための詳細のフローチャートである。

図14に記載したバックトレース処理の場合では、外部ホストや可搬媒体からのファイルコピー/移動、メールの添付ファイルの保存、およびスキャン画像の保存のときログが不正確もしくは不完全となる可能性があるため特別に考慮したが、フォワードトレースではすでにステップ1904bでメールの添付ファイルの保存について考慮されているため、ここではそれ以外の場合について検索する。

まずステップ1920にて、基点ログの種類について調べる。ファイルコピー/移動であればステップ1922へ、紙文書のスキャンであればステップ1926へ進む。それ以外の場合はステップ1902の処理を終了する。

基点ログがファイルコピー/移動の場合、次に外部ホストもしくは可搬媒体上のファイル操作について検索する。ステップ1922にて、もし基点ノードのドライブ種別がネットワークドライブである場合、もしくはドライブ種別が取得できなかった場合は、以下の条件(1)〜(3)、もしくは(1')〜(4')を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻近傍である。
(2) イベント発生前のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生前のファイル名が基点ノード情報のファイル名に一致する。
もしくは：
(1') イベント発生時刻が基点ログのイベント発生時刻近傍である。
(2') イベントが新規作成である。
(3') イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(4') イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

ここで、条件(1)〜(3)を満たすファイル操作ログは、図5(b)のように外部ホストからファイルをコピー/移動した場合に対応し、条件(1')〜(4')を満たすファイル操作ログは、図6(b)のように外部ホストから第三者によってファイルをコピー/移動されて、イベントが新規作成と誤ってログが取られた場合に対応する。従って、条件(1)〜(3)、(1')〜(4')を合わせて考慮することによって、外部ホストからのファイルコピー/移動を確実に捕捉できる。

なお、基点ログや検索対象ログに含まれるホスト識別情報およびパス名は不正確である可能性があるので、本実施例では利用しない。ホスト識別情報およびパス名を利用する方法については後の実施例2で説明する。

次にステップ1924に進み、基点ノードのドライブ種別がリムーバブルドライブである場合、もしくはドライブ種別を取得できなかった場合は、以下の条件を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻近傍である。
(2) イベント発生前のファイル情報のドライブ種別が存在し、そのドライブ種別がリムーバブルドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(3) イベント発生前のファイル名が基点ノード情報のファイル名に一致する。
(4) リムーバブルドライブの識別情報が、イベント発生前のファイル情報と基点ノード情報とに存在し、双方のリムーバブルドライブの識別情報が一致する。

以上で基点ログが外部ホストもしくは可搬媒体からのファイルコピー/移動であった場合のステップ1902の処理を終了する。

基点ログが紙文書のスキャンである場合のステップ1926も、ステップ1922と同様、フォワードトレース結果の候補となるログはファイルの新規作成になることに注意して、以下の条件を全て満たすファイル操作ログを抽出し、不完全ログとして検索結果スタック1006に出力する：
(1) イベント発生時刻が基点ログのイベント発生時刻近傍である。
(2) イベントが新規作成である。
(3) イベント発生後のファイル情報のドライブ種別が存在し、そのドライブ種別がネットワークドライブである。存在しなければ、本条件は常に真である（条件が常に成立する）。
(4) イベント発生後のファイル名が基点ノード情報のファイル名に一致する。

この場合も、基点ログに記載されたイベント発生後のホスト識別情報が正確であるとは限らないので、利用しない。以上でステップ1902の処理を終了する。

以上、図19のフォワードトレースの処理手順では、バックトレースと同様、検索結果スタック1006に候補となるログを全て格納した後に、ログが完全であるかどうかを調べて来歴トレース領域1060に表示する。完全ログがヒットした場合、それが唯一正しいフォワードトレース結果であるから、ステップ1902、1904a、1904b、1904cで完全ログが見つかり次第、検索処理を終了して、求めた完全ログを表示しても良い。本実施例ではわかりやすさを優先して、最後にまとめてトレース結果を表示している。

なお、バックトレースの場合と同様、ファイルの格納環境に依存しないような特徴値がログとして収集されているのであれば、ファイル名の代わりにその特徴値を利用してもよい。この場合、不要なログを検索する可能性が低減して、より高精度にトレースを行うことができる。

また、図19のフォワードトレースでは、ドライブ種別がログとして取得できなかった場合ファイル名をキーに検索を行うが、これではヒットするログが多すぎて、候補を絞り込めない可能性がある。この場合、
(a) ステップ1922、1924、1926の全てもしくは一部の処理を行わない
(b) ファイル名以外にホスト識別情報およびパス名も用いて、各ステップにて上述の条件を満たし、さらに基点ノードのホスト識別情報およびパス名と、検索対象ログのイベント発生後のホスト識別情報およびパス名とが一致する場合に、検索結果スタック1006にログを出力しても良い。 (b)については実施例2で説明する。

図19の処理手順では、来歴DB282がログテーブル900、902、904を備えることを前提とした。その要点は以下の通りである。
・基点ログが不正確である場合は、イベントが新規作成のログを検索する。
・ファイル名や紙文書IDなど、コンテンツを特定するために最低限必要な情報が一致したログを全て出力する。
・イベント発生時刻、ドライブ種別などの情報も正確性が保証されていれば利用する。
・ホスト識別情報、パス名など正確性が保証できない情報はできるだけ利用しない。

来歴DB282が図9に記載したデータ構造でないとしても、この要点を基に、コンテンツのフォワードトレースを行い、候補を求めることが可能になる。

図19のフォワードトレース手順による検索結果の表示例を図20に示す。

図20(a)は、新規作成されたファイル「readme1.txt」をフォワードトレースした結果、ステップ1904aにて、ファイル「readme2.txt」と「readme3.txt」と一緒に圧縮したという完全ログが見つかった場合の表示例である。検索の結果「readme2.txt」と「readme3.txt」も見つかったため、基点ノードと同じレベルにこれらのファイルも表示されている。

図20(b)は、ファイル「scan.pdf」を添付してメッセージID「メール111」のメールを送信したというログをフォワードトレースした結果、ステップ1904bでファイル操作ログが見つかり、添付ファイルを保存したというログが2件ヒットした場合の表示例である。ステップ1904bではファイル「scan.pdf」を新規作成したというログを添付ファイル保存したというログと解釈して不完全ログとして連結するが、本当にファイル「scan.pdf」を新規作成した可能性も残るため、イベント「新規作成」のログもあわせて、図15のステップ1508bの処理で表示される。

図21は、図20(b)記載のフォワードトレースの結果に対してバックトレースをした場合の表示例である。

図20(b)のフォワードトレースの結果の一部であるノード2100をバックトレースすると、ステップ1408でスキャン画像を保存したというログも新たにヒットしたため、新たにノード2102、2104が追加されている。このように不完全ログがすでに表示されている場合でも、バックトレースを行うと別の不完全ログがヒットする可能性があるため、図13のバックトレースのフローチャートでは、親ノードがすでに表示済みでも、ステップ1300にて完全でない場合に検索する。

本実施例によれば、コンテンツに対する複数の異なるシステムにおける操作ログをトレースして、トレース結果を連結して表示するので、コンテンツの漏洩が発生しても、その漏洩の経過を明らかにすることができる。

前述の実施例1では、イベントによってはホスト識別情報が不正確となるため、ファイル名を用いてトレースを行った。本実施例は、ホスト識別情報も用いて検索することが可能になるような来歴管理システムである。

図22は、本実施例の来歴管理システム20の全体図の一例である。

来歴管理システム20は、1台以上のクライアント(PCなどの端末)102-1〜102-nと、メール送受信を制御するメールサーバ104と、紙の印刷・複写およびスキャンを行う複合機106と、来歴を管理する来歴管理サーバ2200と、そしてクライアント102-1〜102-nや複合機106のホスト識別情報やネットワークフォルダ情報を管理する資産管理サーバ2202で構成される。これらの機器はネットワーク108に接続しており、ネットワーク108を介してデータを授受する。

なお、本実施例においても、実施例1と同様、来歴管理システム20はメールサーバ104もしくは複合機106を備えなくても構わない。また、ログを収集する別の装置がネットワーク108に接続されていてもよい。

クライアント102-1〜102-n、メールサーバ104、複合機106は、図2および3と同様の構成を持つ。図23(a)を用いて、資産管理サーバ2202および来歴管理サーバ2200の構成図の一例をあげる。

資産管理サーバ2200は、ホストを監視して資産情報を取得するホスト監視プログラム2320と、取得した資産情報を格納する資産情報管理DB2322と、資産情報を来歴管理サーバ2000に送信する資産情報送信サービス2324とを含む。

ホスト監視プログラム2320は、ネットワーク108に接続している全てのホストを監視して、ホストの名称、IPアドレス、MACアドレスなどといったホスト識別情報と、ネットワーク108からアクセス可能なネットワークフォルダに関する情報などを各ホストから入手し、資産情報管理DB2322に登録する。以下、資産情報管理DB2322に登録された情報を「資産情報」とよぶ。

来歴管理サーバ2000は、実施例1で説明した来歴検索プログラム280、来歴DB282、来歴登録サービス284の他に、資産情報2300に基づいて来歴DB282に格納されている来歴情報を修正する来歴修正プログラム2340と、資産管理サーバ2200から資産情報2300を受信してプログラム2340に渡す資産情報登録サービス2342を含む。来歴修正プログラム2340の動作の詳細については後で図24を用いて説明する。

図23(a)で説明した資産管理サーバ2200および来歴管理サーバ2000は、図3のサーバ110と同様のハードウェア構成をもつ。すなわち、プログラム2320、2340、サービス2324、2342は、メモリ304bもしくは記憶装置306bに格納されて、CPU302b上で実行される。DB2322は、記憶装置306b上に実装される。また、サービス2324および2342は、通信部308bを介して資産情報ログを授受する。

資産情報2300の一例を図22(b)に示す。資産情報2300は、ホスト名2360a、ホストのIPアドレス2360b、MACアドレス2360cといったホスト識別情報2360と、当該ホスト内のネットワークフォルダに関する情報2362などの構成要素を持つ。情報2362は、他のホストからアクセスするために用いられるパス(以下UNCパスという)の名称2362aと、当該ホスト内の実際のパス名2362bとで構成される。

図23(b)記載の資産情報の例2381は、ホスト名「PC-123」、IPアドレス「133.144.6.23」、MACアドレス「00-80-3F-04-A3-EF」で識別されるホストは、フォルダ「C:\Public\」をUNCパス名「\\PC-123\Public\」のネットワークフォルダとしてネットワーク108に公開しているということを意味している。

来歴修正プログラム2340による来歴の修正例を、図24に示す。

ログ2400は、ファイル「C:\MyDocuments\readme.txt」を、ネットワークフォルダ「\\192.211.43.1\Test\」へファイルコピーしたというファイル操作ログである。実施例1で説明したとおり、UNCパス名「\\192.211.43.1\Test\」だけからは、どのクライアントのどのフォルダにコピーしたのか、特定することは困難である。

ところが、資産情報2300を参照すると、UNCパス名「\\192.211.43.1\Test\」のネットワークフォルダは、実際にはホスト名「PC-456」のクライアント上の「D:\Share\Test」というフォルダに対応することがわかる。

従って、来歴修正プログラム2340は、以下の処理手順により、ログ2400内のホスト識別情報およびパス名を正確にすることができる：
(1) 資産情報2300のネットワークフォルダ2362のカラムを参照して、ログ2400に含まれるパス名と一致するUNCパス名を見つける。
(2) 一致したUNCパス名を実際のパス名に置き換え、かつ、ホスト識別情報を、資産情報2340に記載されている正しい識別情報(ホスト名、IPアドレス、MACアドレスのいずれか)に置き換える。

図24の例では、来歴修正プログラム2340によってログ2400がログ2422に修正されて、ログ2400内のホスト識別情報2402「PC-123」およびパス名2404「\\192.211.43.1\Test\」が、正しいホスト識別情報2422「PC-456」、パス名2424「D:\Share\Test\」に置き換えられている。

来歴修正プログラム2340は、定期的、もしくは資産情報を受信するたびに、このような処理を来歴DB282に格納されている全ての来歴情報について行い、ログに含まれるホスト識別情報およびパス名を正確にする。

本実施例のように、来歴管理システムに資産管理サーバ2202を追加するなどして、来歴情報内のホスト識別情報およびパス名の正確性が保証される場合、ファイル名だけではなくホスト識別情報およびパス名も利用してファイル操作ログを検索できるようになり、ヒットしたログが不完全となる可能性が大幅に減少する。

具体的には、バックトレースのステップ1306a、1412、フォワードトレースのステップ1904aにて、ファイル名だけでなくホスト識別情報およびパス名も一致するログを調べて、完全ログとして出力できるようになる。さらに、外部ホストからのファイルコピー/移動を検索する図14のステップ1410も不要となる。

本実施例によれば、操作ログのトレース結果を連結して表示する上で、不完全な操作ログを修正できる。

10・・・来歴管理システム、100・・・来歴管理サーバ、102・・・クライアント、104・・・メールサーバ、106・・・複合機、200・・・来歴、220a・・・ファイル操作監視プログラム、222a・・・ファイル操作ログDB、224a・・・ファイル操作ログ送信サービス、220b・・・プリンタドライバ、222b・・・印刷ログDB、224b・・・印刷ログ送信サービス、240・・・メール送受信監視プログラム、242・・・メール送受信ログDB、244・・・メール送受信ログ送信サービス、260a・・・複写監視プログラム、262a・・・複写ログDB、264a・・・複写ログ送信サービス、260b・・・スキャン監視プログラム、262b・・・スキャンログDB、264b・・・スキャンログ送信サービス、280・・・来歴検索プログラム、282・・・来歴DB、284・・・来歴登録サービス、110・・・サーバ、302a、302b・・・CPU、304a、304b・・・メモリ、306a、306b・・・記憶装置、308a、308b・・・通信部、310a、310b・・・表示部、312a、312b・・・操作部、314a・・・可搬媒体接続部、900・・・ファイル操作ログテーブル、902・・・メール送受信ログテーブル、904・・・紙文書ログテーブル、1000・・・検索部、1002・・・検索条件入力部、1004・・・通信部、1006・・・検索結果スタック、1008・・・検索結果表示部、1020・・・インターフェース、1022・・・検索条件指定領域、1040・・・ログ表示領域、1060・・・来歴トレース領域、20・・・来歴管理システム、2200・・・来歴管理サーバ、2202・・・資産管理サーバ、2300・・・資産情報、2320・・・ホスト監視プログラム、2322・・・資産情報管理DB、2324・・・資産情報送信サービス、2340・・・資産情報登録プログラム、2342・・・資産情報登録サービス。

Claims (18)

1. コンテンツの内容の更新を含む操作に関する第1の操作ログを取得する第1のログ取得部と前記取得した第1の操作ログを送信する第1の送信部とを有するクライアント、
   前記コンテンツの内容の更新に係らない操作に関する第２の操作ログを取得する第2のログ取得部と前記取得した第２の操作ログを送信する第２の送信部とを有する他の装置、および、
   前記クライアントおよび前記他の装置とネットワークを介して接続し、前記第1の送信部からの前記第1の操作ログ及び前記第２の送信部からの前記第２の操作ログを受信する受信部と、前記コンテンツ及び前記コンテンツへの操作の指定に応答して、前記指定された前記コンテンツ及び前記コンテンツへの操作を表示し、前記表示した前記コンテンツ及び前記コンテンツへの操作にトレース結果を連結して表示する表示部と、前記表示した前記コンテンツ及び前記コンテンツへの操作に係る操作来歴を、前記受信した前記第1の操作ログ及び前記第２の操作ログとからトレースし、前記表示するトレース結果を得る来歴検索部とを有する来歴管理サーバを設けることを特徴とする来歴管理システム。
2. 前記来歴管理サーバの前記表示部は、前記コンテンツ及び前記コンテンツへの操作、並びに前記トレース結果を階層化して表示することを特徴とする請求項1記載の来歴管理システム。
3. 前記来歴管理サーバの前記来歴検索部による前記操作来歴のトレースは、前記表示した前記コンテンツ及び前記コンテンツへの操作のいずれか一方を基点とした、前記第1の操作ログ及び前記第２の操作ログとからのバックトレース及びフォワードトレースのいずれか一方であることを特徴とする請求項２記載の来歴管理システム。
4. 前記来歴管理サーバの前記来歴検索部による前記トレース結果は、前記第1の操作ログ及び前記第２の操作ログの中の、前記操作来歴として不完全な操作ログを含むことを特徴とする請求項３記載の来歴管理システム。
5. 前記クライアントおよび前記他の装置の識別情報を含む資産情報を管理する資産管理サーバをさらに設け、前記資産管理サーバが管理する前記資産情報を参照して、前記トレース結果に含まれる前記操作来歴として不完全な操作ログを修正することを特徴とする請求項４記載の来歴管理システム。
6. 前記他のシステムは、前記コンテンツを印刷するプリンタドライバ、前記コンテンツを添付して送受信するメールサーバ、及び前記コンテンツを複写又はスキャンする複合機の少なくとも一つであることを特徴とする請求項５記載の来歴管理システム。
7. クライアントおよび他の装置とネットワークを介して接続し、
   前記クライアントからのコンテンツの内容の更新を含む操作に関する第1の操作ログと前記他の装置からの前記コンテンツの内容の更新に係らない操作に関する第２の操作ログとを受信する受信部、
   前記コンテンツ及び前記コンテンツへの操作の指定に応答して、前記指定された前記コンテンツ及び前記コンテンツへの操作を表示し、前記表示した前記コンテンツ及び前記コンテンツへの操作にトレース結果を連結して表示する表示部、及び、
   前記表示した前記コンテンツ及び前記コンテンツへの操作に係る操作来歴を、前記受信した前記第1の操作ログ及び前記第２の操作ログとからトレースし、前記表示するトレース結果を得る来歴検索部を有することを特徴とする来歴管理サーバ。
8. 前記表示部は、前記コンテンツ及び前記コンテンツへの操作、並びに前記トレース結果を階層化して表示することを特徴とする請求項７記載の来歴管理サーバ。
9. 前記来歴検索部による前記操作来歴のトレースは、前記表示した前記コンテンツ及び前記コンテンツへの操作のいずれか一方を基点とした、前記第1の操作ログ及び前記第２の操作ログとからのバックトレース及びフォワードトレースのいずれか一方であることを特徴とする請求項８記載の来歴管理サーバ。
10. 前記来歴検索部による前記トレース結果は、前記第1の操作ログ及び前記第２の操作ログの中の、前記操作来歴として不完全な操作ログを含むことを特徴とする請求項９記載の来歴管理サーバ。
11. 前記クライアントおよび前記他の装置の識別情報を含む資産情報を管理する資産管理サーバと前記ネットワークを介してさらに接続し、前記資産管理サーバが管理する前記資産情報を参照して、前記トレース結果に含まれる前記操作来歴として不完全な操作ログを修正することを特徴とする請求項１０記載の来歴管理サーバ。
12. 前記他のシステムは、前記コンテンツを印刷するプリンタドライバ、前記コンテンツを添付して送受信するメールサーバ、及び前記コンテンツを複写又はスキャンする複合機の少なくとも一つであることを特徴とする請求項１１記載の来歴管理サーバ。
13. クライアントおよび他の装置とネットワークを介して接続した来歴管理サーバにおける来歴管理方法であって、
    前記クライアントからのコンテンツの内容の更新を含む操作に関する第1の操作ログと
    前記他の装置からの前記コンテンツの内容の更新に係らない操作に関する第２の操作ログとを受信し、
    前記コンテンツ及び前記コンテンツへの操作の指定に応答して、前記指定された前記コンテンツ及び前記コンテンツへの操作を表示し、
    前記表示した前記コンテンツ及び前記コンテンツへの操作に係る操作来歴を、前記受信した前記第1の操作ログ及び前記第２の操作ログとからトレースし、
    前記表示した前記コンテンツ及び前記コンテンツへの操作に前記トレースした結果を連結して表示することを特徴とする来歴管理方法。
14. 前記コンテンツ及び前記コンテンツへの操作、並びに前記トレース結果の表示は、階層化して表示することを特徴とする請求項１３記載の来歴管理方法。
15. 前記操作来歴のトレースは、前記表示した前記コンテンツ及び前記コンテンツへの操作のいずれか一方を基点とした、前記第1の操作ログ及び前記第２の操作ログとからのバックトレース及びフォワードトレースのいずれか一方であることを特徴とする請求項１４記載の来歴管理方法。
16. 前記トレースした結果には、前記第1の操作ログ及び前記第２の操作ログの中の、前記操作来歴として不完全な操作ログを含むことを特徴とする請求項１５記載の来歴管理方法。
17. 前記クライアントおよび前記他の装置の識別情報を含む資産情報を管理する資産管理サーバと前記ネットワークを介してさらに接続し、前記資産管理サーバが管理する前記資産情報を参照して、前記トレース結果に含まれる前記操作来歴として不完全な操作ログを修正することを特徴とする請求項１６記載の来歴管理方法。
18. 前記他のシステムは、前記コンテンツを印刷するプリンタドライバ、前記コンテンツを添付して送受信するメールサーバ、及び前記コンテンツを複写又はスキャンする複合機の少なくとも一つであることを特徴とする請求項１７記載の来歴管理方法。

Images