JP5063440B2 - 処理装置及び処理方法 - Google Patents

Description

本発明は一般にディジタルオブジェクトを配布する技術分野に関連し、特に本発明は書類ログを使って情報を関連付けることに関連する。

多くの書類管理システムが過去に提案され実現されている。これらの書類管理システムは、書類を格納し且つリクエストと応答の調整を処理するシステムを含む。しかしながら、これらのシステムは組織境界を越えるものではないし、必要な一致を実現するものでもない。

ウェブログ(Web log)は情報を記録するのに使用されるオンライン書類管理ツールである。ウェブログはクライアントサーバーフレームワークを使って、１つ以上のクライアントロケーションからそのウェブログを主催するサーバにおいて、コンテンツの追加又は取り出しを許可する。１つのサーバが各ウェブログを主催するので、ウェブログは一般に特定のHTTPロケーションに固定される。

Wolff,Gregory J,et al.により西暦2004年7月9日に出願された“Synchronizing distributed work through document logs”と題する米国出願第10/887,998号(特許文献１)は、書類ログの利用を通じて、分散したワークの同期をとることを開示している。そこに開示されているように、書類のようなディジタルオブジェクトに関連する或るセットにメタデータエントリが付加される。メタデータエントリは、そのメタデータエントリを参照する固有の識別子を使ってアクセスされる。一実施例では、固有の識別子の各々がそのメタデータエントリの内容に基づく。
米国特許出願公開第20060010095号明細書

本発明の課題は、ログとの関連性を記録する方法及び装置を提供することである。

一形態による方法は、
処理装置が行う処理方法であって、
第１ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得するステップと、
関連する前記第１及び第２ログエントリの前記時間情報に基づいて、第１メディアが第２メディアと関連していることを確認するステップと、
を有し、前記第１ログエントリは前記第１メディアに対応する第１メディア識別子を含み、前記第２ログエントリは前記第２メディアに対応する第２メディア識別子を含み、
前記第１及び第２ログエントリ各々から取得された時間情報が示す時間が、所定の時間範囲内にあった場合に、前記第1及び第２ログエントリの時間情報は関連していると判定され、
前記第１及び第２ログエントリの各々は、メッセージに対してハッシュ計算したものとローリングチェックサムとのペアの一連のレコードを含み、或るレコードにおけるローリングチェックサムは、少なくとも、先行するレコードにおけるローリングチェックサムと、時間情報と、メッセージに対してハッシュ計算したものとを連結してハッシュ計算したものである、処理方法である。

以下でなされる詳細な説明により及び本発明の様々な実施例の添付図面により、本発明は十分に理解されるであろうが、実施例は本発明を特定の実施例に限定するために使用されるべきでなく、説明及び理解を促すためのものに過ぎない。

メディア及びメディア識別子の中での関連付けを促進するようにログを使った方法、装置及び製品が開示される。換言すれば、１つ以上のメディアの部分が装置と関連する又は互いに関連する場合に、本願で説明されるログ及びロギング技法が記録に使用される。これは、メディアに対応する１つ以上のメディア識別子を利用することで実行される。

以下の説明では、本発明の更なる説明を与えるために多数の詳細が述べられる。しかしながら本発明はそれらの具体的詳細によらず実現されてもよいことは当業者に明らかであろう。また、本発明を曖昧にすることを避けるため、周知の構造や装置は詳細な形式ではなくブロック図形式で示される。

以下の詳細な説明の一部は、コンピュータメモリ内のデータビットを処理するアルゴリズム及び記号表現の観点からなされる。これらのアルゴリズムの説明及び表現は、このデータ処理技術分野の当業者が他の当業者に彼らの仕事内容を最も効率的に伝えるのに使用される手段である。ここで、アルゴリズムは一般に所望の結果に導く首尾一貫した一連のステップと考えられる。そのステップは物理量の物理的処理を必要とするものである。必須ではないが、通常それらの物理量は、格納、転送、結合、比較その他の処理を施すことの可能な電気的な又は磁気的な信号の形態をとる。原則的な一般的な用法の観点から、ビット、値、エレメント、シンボル、キャラクタ、期間、数等としてそれらの信号に言及することが折に触れて便利なことが分かる。

しかしながら、これらの及び類似の用語の全ては、適切な物理量に関連しており且つそれらの量に付された便宜的なラベルにすぎないことに留意を要する。特に断りのない限り、以下の説明から明らかなように、本説明を通じて、「処理」、「演算」、「計算」、「決定」又は「表示」等のような用語を用いる説明は、コンピュータシステム又は同様な電子コンピュータ装置の動作や処理に関連し、その動作や処理は、コンピュータシステムのレジスタ及びメモリの中で物理的な（電子的な）量として表現されるデータを、コンピュータシステムメモリやレジスタその他の情報ストレージ、伝送又は表示装置の中で物理量として同様に表現される他のデータに変換及び処理することが、理解されるであろう。

本発明はここで説明される処理を実行する装置にも関連している。その装置は、必要な目的に応じて特別に構築されてもよいし、コンピュータに格納されているコンピュータプログラムによって選択的にアクティブにされる又は再構成される汎用コンピュータで構築されてもよい。そのようなコンピュータプログラムはコンピュータ読取可能な記憶媒体に格納されてもよく、その記憶媒体は、限定ではないが、フロッピディスク、光ディスク、CD-ROM、磁気光ディスク、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光カード等の如何なるタイプのディスクを含んでもよいし、或いは電子的な命令を格納するのに指摘した如何なるタイプの媒体を含んでもよいし、ディスクも媒体もそれぞれコンピュータシステムバスに結合される。

ここで説明されるアルゴリズム及び表示は、特定のコンピュータその他の装置のどれにも固有に関連するものではない。様々な汎用システムがここで教示するものによるプログラムと共に使用されてよく、或いは、必要な方法ステップを実行するように、よりいっそう特化した装置を構築することが便利なことが分かるかもしれない。これら様々なシステムに必要な構造は以下の説明から明らかになるであろう。更に、本発明は特定のプログラミング言語のどれにも依存しない。ここで説明される本発明の教示内容を実現するのに様々なプログラミング言語が使用されてよいことが分かるであろう。

マシン読み取り可能な媒体は、マシン(例えば、コンピュータ)で読み取り可能な形式で情報を記憶又は転送する如何なる手段をも含んでよい。例えば、マシン読み取り可能な媒体は、読み取り専用メモリ(ROM)；ランダムアクセスメモリ(RAM)；磁気ディスク記憶媒体；光記憶媒体；フラッシュメモリ装置；電気、光、音又は他の形式で伝搬する信号(例えば、搬送波、赤外線信号、ディジタル信号等)；等である。

＜メディア識別子、シーケンシャルログ及びエンタングリング＞
＜物理的及び電子的アイテムのメディア識別子＞
ここで説明される発明の多くは、書類(ドキュメント)、ビデオ、歌、紙の一部又は電子ファイルを識別子で参照できることを要する。このため、書類、ビデオ、歌、紙の一部又は電子ファイルはここではメディアとして言及される。メディアを識別するのに使用される識別子は、メディア識別子と呼ばれ、一実施例では、一連のバイトである。

メディア及びメディア識別子間に本発明で有用な関連付けの特性がいくつかある：Ａ）メディアを有する誰もが同じメディア識別子を確認できることは有用である；Ｂ）同じメディア識別子を有する２つの別個のメディア部分を発見することは誰にとっても困難なことは有用である；Ｃ）メディア識別子はそのメディアの内容については何も明らかにしないことは有用である；及びＤ）メディアに対する如何なる変更も別の識別子をもたらすことは有用である。

メディアの一部に識別子を割り当てる方法は多数存在する。電子ファイルの場合、一実施例では、暗号ハッシュ関数(Cryptographic hash function)をファイルのバイトに適用することで識別子が生成される。暗号ハッシュ関数はセキュリティ業界で周知であり、様々な連邦の及び国際的な標準仕様で規格にされているソフトウエアツールキットである。

暗号ハッシュ関数は上記の性質に良く合致するので、識別子を形成するのにたとえ別の技術が使用されていたとしても、一部のメディアの識別子を決定するプロセスを「ハッシュ処理」としばしば言及し、そのメディア識別子を「ハッシュ」としばしば言及する。

ファイルに識別子を割り当てる別の方法もある。例えば、サーバは全てのファイルのコピーを保持し、過去に未使用のストリングを新たなファイル各々にランダムに割り当てる。この方法はＢ，Ｃ及びＤに非常に良く機能するが、誰もがサーバにアクセス可能な場合であって、例えばサービス拒絶でオフラインになる場合でさえサーバを変えることのできない場合にのみ上記のＡの性質に合致する。

ファイルを区別するために暗号ハッシュより簡易な関数を使用することも可能である。例えば、簡易なチェックサムがファイルに使用可能であり、その結果がメディア識別子として使用可能である。これはＡ及びＣの性質を満たすが、Ｂの性質は満たさない。何らかの変更は異なるチェックサムになるが、僅かにそうならない場合もあり、従ってＤの性質は常には満たされない。しかしながら、アプリケーションによってはこれらの性質が重要でないかもしれない。また、２つのメディア部分（何れも同じチェックサムを有し、且つ構造化されたデータの規則に従う）を見つけるのが困難であるように、あるアプリケーションは非常に構造化されたデータを有するかもしれない。

例えば、ある用紙をスキャンし、その結果のスキャンされたファイルの暗号ハッシュを計算することで、一部の紙に識別子を割り当てることができる。しかしながら、スキャン処理中のノイズに起因して、その用紙の別のスキャンがしばしば別の電子ファイルをもたらし、別の識別子をもたらす。この理由のため、バーコード又は他のマシン読み取り可能な識別子(例えば、RFIDタグ)を一部の紙に又は他の部地理装置に取り付けることがしばしば有用である。マシン読み取り可能なIDを利用することは、誰もが同じ識別子を得ることを容易にする；しかしながら、異なるメディアに同じID値を付けることも可能になるので、この場合Ｂの性質は完全には合わない。

一実施例では、マシン読み取り可能なIDの弱点を克服するため、「フィンガープリント処理」形式が物理的なメディアを識別するのに使用される。フィンガープリント処理は或る値を物理装置に関連付けるので、同じフィンガープリント(指紋)を伴う紙の部分又は新たな「フィンガ」を作成することは非常に困難に又は不可能になる。しかしながら多くの場合に「フィンガープリント」は物理メディアに関する何かを露わにしてしまい、フィンガープリントを変えずに物理メディアを僅かに変更できるかもしれない。従ってそのような場合ＣやＤの性質は完全には保たれない。

単独の一部のメディアに関連する複数の識別子が存在してもよい。例えば、SHA1暗号ハッシュ関数をメディアに使用することで形成される識別子や、SHA256又はMD5暗号ハッシュを同じメディアに使用することで形成される識別子があってもよい。一実施例では、鍵の付いたハッシュメッセージ認証コード又はHMACがメディア識別子を計算するのに使用される。HMAC-MD5又はMHAC-SHA1のようなこれらのメッセージ認証コードは、変更可能な鍵を使用するので、B,C,Dの性質に関しては、基礎的な暗号ハッシュ関数(MD5及びSHA1)よりも優れているかもしれない。しかしながら性質Ａはメッセージ認証コードと共に困難になる−なぜなら、同じハッシュを計算するため、それを計算する全ての場所で鍵に対するアクセス権を要するからである。

同じデータの異なるフォーマットに関連する識別子があってもよい。例えば、ファイルのハッシュや、ZIPと共にロスレスに圧縮された同一ファイルのハッシュは、異なる識別子になるが、それらは最終的には同じデータに関連付けられる。

メディアの一部のために形成された識別子があってもよい。例えば、ビデオの場合、異なるフレーム各々について形成された識別子があってもよい。ネットワークでのパケット損失に起因して、同じビデオを見る２人の人々は同じファイルにたどり着けないかもしれないし、従って彼らは同じ識別子を計算できないかもしれない。しかしながら各人はそのビデオのいくつかの同じフレームを受信している。従って、彼らが受信した各フレームのハッシュを彼らが計算した場合、多くの一致するハッシュに起因して、彼らが同じビデオを鑑賞していたことを彼らは確認できる。

同じ例を続けると、同じビデオを鑑賞している２人の人々は、それを異なる解像度で干渉するかもしれない。その場合、２つのフレームは同じハッシュを持たないであろう。しかしながら、例えばJPEG2000パート3のようなスケーラブル法でビデオが格納されていた場合、ビデオの最低解像度の部分は双方の視聴者にとって同じになり、共通するハッシュが確認可能になる。

ビデオがスケーラブルなフォーマットで格納されていなかった場合、一般的にはサーバはビデオの複数のバージョンを異なる解像度で格納する。従ってサーバは全ての解像度の格納しているフレーム全てのハッシュを計算することができ、クライアントに完全に受信されたどのフレームもハッシュ処理可能であり、そのハッシュはビデオを確認するためにサーバ上のものと後に比較される。

ビデオだけでなく、部分的に送信されてよい他のタイプのメディアも存在する。例えば、大きなXML書類の一部が必要とされるかもしれない。このリクエストは例えばXPATHクエリ(問い合わせ語句)によりなされてもよい。クライアントで受信される書類の部分は、サーバで利用可能な書類全体とは異なる。しかしながら、(例えば、XML書類のサブツリーのような)書類の一部について又はXML書類の特定のノードのコンテンツについてでさえハッシュを計算することができる。XML書類の一部分と共にクライアントは、受信したそのサブツリー及びノードのハッシュを計算し、それらはサーバ上の大規模なハッシュリストに適合可能である。

何らかの特定のメディアに関し、関連するデータの一部分がしばしば特定され、これらの一部分は、完全なメディアのハッシュに加えてハッシュ処理可能である。

場合によっては、配布された部分がデータの中で実際に完全には表れないように、データが処理される。例えば、カラーの画像がグレースケールに変換されて配信されてもよいし、或いはスプレッドシート中のエントリの合計が計算されて報告されてもよい。しかしながら、データが２つの場所(例えば、サーバ及びクライアント)に存在する場合、修正されたデータのみが配信される場合でさえ、サーバ及びクライアント双方にとって、修正されたデータのハッシュを記録することが可能であり、受信データ及びそのソース間の関連付けが後に用意されてもよい。

場合によっては「サーバ」は修正されたデータを初めは持っていないかもしれない。例えば、中間的な処理の場合に装置がデータに関する計算を実行する場合である。しかしながら計算のタイプが既知ならば、オリジナルのデータと受信データとを関連付けるようにサーバで後に計算を実行できる。例えば、サーバは高いビットレートのビデオを送信するかもしれないが、ネットワークの輻輳に起因して、途中のルータで品質レイヤを除去することで切り詰めるかもしれない。そしてクライアントはハッシュ処理可能な中程度のビットレートのビデオを受信する。同じハッシュを確認するために、ルータが破棄した品質レイヤなしに、サーバは高ビットレートのビデオについてハッシュ処理を行う。

＜シーケンシャルログ＞
ここで説明される本発明の多くは、イベントシーケンスを読み取ることを含む。イベントの記録は、「ログ」又は「ログ−ファイル」として言及され、船舶や航空機のイベントを記録するログブック(航行日誌)や、コンピュータシステムで行われるアクションを記録するのに使用されるログファイルと同様な関係である。一実施例では、末尾に新たな記録を追加するのは容易であるが、容易に検出される変更を伴わずに、ログの中に既にある記録を変更するのは困難であるという性質を、ログは有する。

従来の「ログブック」又は「ログファイル」とは異なり、一実施例では、記録されているイベントに関する多くの情報をそのログは開示しないことが望ましい。このようにログファイルは非常に多数の人々やシステムに利用可能になるが、その際に、何らかの記録は検査可能であるが、その記録の大部分の内容は秘密のままにするようにできる。

ログのいくつかの可能な実現手段が存在し、それらは追加が容易なこと、変更が困難なこと、情報の部分的な開示等の目的に関して、異なる達成度合いを有する。

ログを実現する概念的に簡易な手段は、不正改ざんできない追記型メモリ(tamper proof write once memory)である。記録(レコード)の各々はメモリに順番に書き込まれる。これは追加に容易で修正困難な目的には合致するが、「不正改ざんできない」メモリが変更されていないことを遠隔的に確認することは困難である。

ログを実現する１つの方法は、一連のレコードを作成することであり、そのレコードの各々は、以前のレコード中の何らかの情報のハッシュ、及び現在のレコードの内容を含む。例えば、ｉ番目のレコードのメッセージ部分をMiとし、ローリングチェックサム(rolling checksum)をriとする。ｉ番目のレコードについてのローリングチェックサムは、次のように計算できる：
r_i=hash(r_i-1．Mi)
この場合に、メッセージ及び以前のチェックサムは連結され(“．”で表現されている)、ハッシュ関数に与えられている。この場合のログは、メッセージ及びチェックサムのシーケンスで構成される(Mi，ri)。一実施例では、そのログへの追加は、最後のチェックサムと現在のメッセージを取り出し、それら２つを連結し、ハッシュを計算することで作成されてもよい。これは図１に示されている。図１を参照するに、新たなメッセージ及びチェックサムのペアを作成するため、メッセージ及びチェックサムのジェネレータ101は、新たなメッセージM_i+3及びログ110の中で最後のエントリのチェックサムr_i+2を受信する。連結モジュール102は以前のチェックサムr_i+2とメッセージM_i+3を連結する。ハッシュモジュール103は上述したようにハッシュ関数を適用し、次のチェックサムr_i+3を生成する。メッセージM_i+3及びチェックサムr_i+3はログ110に格納される。メッセージ及びチェックサムジェネレータ101は、連結モジュール102及びハッシュユニット103と共に処理ユニット(例えば、マイクロプロセッサ)で構成され、102,103は処理ユニットで実行される命令のソフトウエアモジュールであることに留意を要する。或いは、これらの機能はハードウエアで実現されてもよい。

ログの中のメッセージの1つが修正された場合又はログの中のチェックサムの１つが修正された場合、以後のチェックサムは正しくなくなる。従ってレコードの修正はメッセージ及び以後の全てのチェックサムの修正を要する。チェックサムの１つが複製されてどこかに保存されると、そのチェックサムに先行する如何なる修正も消去可能になる。修正がチェックサムの変更無しになされた場合、ログ中のそのローリングチェックサムのハッシュを再計算するとエラーを表す。ハッシュが全て変更され、ログが自己矛盾しないようになった場合、それらは外部に保存された値とは合わなくなるであろう。

上述したように、ハッシュ関数は簡易なチェックサムでもよいが、好ましくは暗号ハッシュ関数である。

本方法はログの目的にほぼ合致するが、更なる利便性をもたらす変形例もある。

１つの変形例は、メッセージ自身でなくメッセージのハッシュをログに保存することである。従って、m_iが次のように定義される場合：
m_i=hash(Mi)
ログは(m_i,r_i)の二乗として定義でき、r_iはメッセージハッシュ及び以前のチェックサムのみのチェックサムである：
r_i=hash(r_i-1．mi)。

これは図２に示されている。図２を参照するに、新たなメッセージ及びチェックサムのペアを作成するため、メッセージ及びチェックサムジェネレータ201は、新たなメッセージM_i+3及びログ210内の最後のエントリのチェックサムr_i+2を受信する。連結モジュール102は以前のチェックサムr_i+2とメッセージM_i+3を連結する。ハッシュモジュール103は上述したようにハッシュ関数を適用し、次のチェックサムr_i+3を生成する。ハッシュモジュール203はハッシュ関数をメッセージM_i+3に適用し、ハッシュ処理されたメッセージm_i+3を生成する。一実施例では、ハッシュモジュール203に適用されるハッシュ関数は、ハッシュモジュール103に適用されたハッシュ関数と同じである；或いは、ハッシュモジュール203に適用されるハッシュ関数は、ハッシュモジュール103に適用されたハッシュ関数と同じでなくてもよい。メッセージm_i+3及びチェックサムr_i+3はログ210に格納される。メッセージ及びチェックサムジェネレータ201は、連結モジュール102、ハッシュユニット103及びハッシュユニット203と共に処理ユニット(例えば、マイクロプロセッサ)で構成され、102,103,203は処理ユニットで実行される命令のソフトウエアモジュールである。或いは、これらの機能はハードウエアで実現されてもよい。

本方法は、ハッシュ関数が固定長を有する場合に(通常的にはこの仮定は正しい)、固定長のレコードを生成するという利点を有する。更に本方法は如何なるメッセージのコンテンツもログに持ち込まない利点を有する。メッセージが何らかの顧客情報であった場合(例えば、名前、住所その他の情報の入った購入依頼であった場合)、メッセージを公表することは好ましくない。しかしながら、ハッシュ関数がそのメッセージに関する情報を明らかにしないのであれば、情報を公表することなく、(mi,ri)のシーケンス全体(即ち、ログ)を公表できる。

場合によっては、メッセージのハッシュ単独よりも多くの情報を伴うログを有することが好ましい。例えば、ログに格納された時間や、公表されたログに格納されたログエントリの情報タイプを有することがしばしば有用である。これは特定のレコードを求めてログをサーチすることを容易にする。読み取り可能なレコードの情報が「プレインテキスト(平文)」(tiと言及する)で規定されていた場合、ログは(ti,mi,ri)のシーケンスで構成され、各々のチェックサムriは次式で計算される。

r_i=hash(r_i-1．t_i．m_i)。
この数式は非常に一般的である。なぜなら、tiの部分は更なる構造を含んでもよいし(例えば、日にち、タイプ、ファイル名を常に含んでもよい)、メッセージも構造化されてよいからである。当然に、以前のローリングチェックサム、現在のメッセージ又はメッセージハッシュ及び「平文」情報の順序は、その順序がチェックサムを生成する或いは確認する必要のある全てのアプリケーションに既知である限り、変更可能である。

ログ中の情報への部分的なアクセスをもたらす別の方法は、ログに保存されている情報の一部を暗号化することである。あるログに関する暗号化された情報がEiであり、Eiのハッシュがeiであったとする。一実施例では、Ei又はeiはログに格納可能である。そして、ログエントリは(ti,mi,Ei,ri)で構成され、即ち、平文の部分、メッセージのハッシュ、或る暗号化されたデータ及びログ中の以前のハッシュに関するチェックサムで構成され、それらはメッセージのハッシュと共に連結される。一般に、時間が混ざってもよく、レコードは、いくつかの平文の部分、いくつかの暗号化部分及びいくつかのメッセージのハッシュを含んでもよい。

一実施例では、ログエントリのフォーマットは、データを伴う一群のヘッダ「ライン」及びボディで、例えば次のように表現される。

作者：ゴーミッシュ(gormish)
SHA1：1bff5d8cda307b5f3f3757cb25588a54cfb01ce0
コンテンツ長：５６７
５６７バイトのデータ。

一実施例では、このフォーマットタイプはhttp及び電子メール(email)に使用される。従って、いくつかの周知のヘッダが規定されており、ログで使用可能である。

ログの中の異なる暗号化エントリや異なるタイプの暗号化エントリについて、異なるキー(鍵)が使用されてもよい。例えば、全てのエンタングルメント(entanglement)情報が１つのキーで暗号化され、全ての分類値に異なるキーが付随してもよい。そのログが1つの書類に関連付けられ、その書類が暗号化される場合、ログ中のエントリはその書類に使用されたのと同じキーで暗号化されてもよい。これにより、書類にアクセス権を有する誰でもが、ログ中の情報にアクセスすることを許可される。

一実施例では、異なる複数のローリングハッシュ又は異なるタイプのハッシュをログはサポートし、それらのハッシュは異なる暗号化ハッシュ関数と共に計算されたものである。例えば、一実施例では、値riは次のようになる：
r_i=hash(r_i-1．t_i．m_i)。
そして、tiの値は(例えば、MD5、SHA1、SHA256等のような)どのハッシュ関数が使用されていたかを特定する。一実施例では、２つの異なるローリングチェックサムを共なうログエントリは、次のようなエントリを有し：
(t_i,m_i,r_i,s_i)
ここで、riは次式で計算される：
r_i=SHA(r_i-1．t_i．m_i)。
siは次式で計算される：
s_i=SHA256(s_i-1．t_i．m_i)。
これは、唯１種類のハッシュしかサポートしないシステムと共に同じログが使用されることを可能にし、あるハッシュ関数が不具合を生じた場合、他のハッシュ関数が依然として有効であり、双方の組み合わせは不具合に対して強くなる。２つ以上のハッシュ関数を使用するログの他の例は、当業者には明白であろう。

新たなハッシュチェーンをログに遡及的に追加するログエントリが追加可能であることに留意すべきである。ログがメッセージ及びローリングハッシュのペア(Mi,ri)で構成され、r_i=SHA(r_i-1,M_i)であり、ｉは１乃至Ｎの範囲内にあるとする。新たなメッセージがログに追加可能であり、そのログは、古いメッセージと、異なるハッシュ関数と共に計算された新たなローリングハッシュとを含む。そして、メッセージＮ＋１は新たなハッシュ関数と用いて計算されたローリングチェックサムと共に結合された第１メッセージである。一般に：
M_N+1=M_i．s_i
であり、ここで、
s_i=SHA256(s_i-1,M_i)
である。これは、同じものをカバーする新たなハッシュを加えることで、ハッシュ関数に障害のあるログの後の修正を可能にする。ハッシュ関数に障害があり新たな関数が発見される場合、いくつのハッシュ関数がこの形式で遡及的に適用されてもよい。

一実施例では、第２のハッシュ関数はその計算の際に第１のハッシュ関数を利用得する。例えば、
s_i=SHA256(s_i-1．t_i．m_i．r_i)。
又は
s_i=SHA256(r_i-1．s_i．t_i．m_i)。
でもよい。

＜ログの記憶＞
一実施例では、ログは単独のファイルに順に格納される。この種のログは非常に用に作成できる。なぜなら、最後のエントリによるローリングハッシュが読み取られ、新たなデータはファイルの末尾に加えられるからである。エントリが固定長であった場合、ファイル中で特定のエントリを見つけるのは容易である。多くの場合に単独のファイルで十分であり、特にログが（過剰に多くのエントリを含んでいない）単独の書類に関する場合には十分である。

場合によっては、ログが非常に長くなるかもしれない。なぜなら通常的には一般的なイベントのレコードが作成され続けるからである。ログが複数のソースからのデータを蓄積するように使用される場合、いくつものエントリが毎秒存在するかもしれない。この場合、例えば10,000エントリ毎に、ログを複数のファイルに分断することが有用かもしれない。

別の実施例では、各ログエントリが個別のファイルに格納される。この場合、高速アクセスに備えて、最も新しいエントリを指すポインタが使用される。一実施例では、レコードはその中にシーケンス番号を含み、最も新しい最近のレコードは、全てのレコードの番号を検査することで判定できる。１つの技法は、ローリングハッシュと共にファイルを指名することであり、そのファイル内の以前のレコードのローリングハッシュを含む。こうして、最も新しいエントリから、ポインタに従って全てのエントリに遡って進行することができる。

別の実施例では、ログエントリの各々がデータベースのレコードになる。特定のメッセージハッシュ、ローリングハッシュ、時間範囲又は平文を速やかに、或いはログエントリの残りのコンテンツが含む場合はいつでも、サーチできるようにする点でこれは非常に有用である。データベースは処理の統合性をもたらすので、データベース手段は、大量のエントリがログの中で作成された場合に有用である。

＜ライトワンスメモリ＞
イベントがシーケンスで発生することを保証する数学的方法に加えて、一実施例では、物理的な改ざん防止装置がイベントのシーケンスを記憶するのに使用される。一実施例では、物理的な改ざん防止装置はライトワンスメモリ(write once memory)であり、メッセージのハッシュを順番に格納する。この種のログのエントリを変えることは、メモリを変更することを要する。

ライトワンスメモリは簡易であるが、改ざんされてないことを遠隔的に確認することは困難である。従って、一実施例では、改ざん防止システムはディジタル署名又は他の認証手段をそのコンテンツのために用意する。

＜エンタングリング＞
１つのログを修正することは比較的容易なので、一実施例では、ログの間で情報がやりとりされ、或るログの中のエントリの修正が他のログを調べることで検出可能にする。第１ログの中の情報全てに依存する情報を第２ログに格納することは重要である。以前に定義されているログの場合、ローリングチェックサムはその性質を備えている。チェックサムの各々は、ログエントリ中の他のデータ及び以前のチェックサムに依存する。従って、ログエントリの何らかの部分が変更された場合、そのローリングチェックサムが変わり、その時点以後のローリングチェックサムも変わる。「ハッシュ」に使用される計算関数によらず、メッセージ又はレコードがハッシュよりも長かった場合、同じハッシュを持つ複数のメッセージ又はレコードが存在する。しかしながら、ローリングチェックサムに使用される関数が上手に選ばれていたならば、例えば暗号ハッシュ関数は、これらのメッセージを発見することを極めて困難にする。

あるログからの情報を別のログに格納するいくつもの方法がある。このプロセスはエンタングリング(entangling)−相互依存方式−と呼ばれる。なぜなら、あるログからの情報を別のログに格納した後、第２ログでの将来の全てのローリングチェックサムは、第１ログでの情報に依存することになるからである。

一実施例では、使用されるログは、メッセージハッシュ及びローリングハッシュのペア−即ち、(m_i,r_i)−を格納しており、第２ログ内のエントリのメッセージハッシュは、第１ログからのローリングハッシュで置換される。従って、第２ログ内のそのエントリ以降の全てのローリングハッシュは、第１ログからのそのローリングハッシュに依存する。

これは最も簡潔な例であるが、エンタングリングの際に格納される限られた量の情報により、エンタングリングの性質がどのようであるかを判定しにくくすることができる。従って、一実施例では、エンタングルメントに使用されるログエントリに追加的な情報が含められる。例えば、あるタイプの値を使うこれらのログは、そのタイプを設定し、そのデータが「正規のメッセージ」でなく「エンタングルメントエントリ」であることを示すようにしてもよい。更に、メッセージハッシュの代わりにローリングチェックサムを直接的に使用しないで、第１ログからのローリングハッシュ及び第１ログの場所(例えば、サーバ名、ログ名、ファイル名、URL等)を含むメッセージが形成されてもよい。一実施例では、第１ログのローリングハッシュのロケーション(例えば、シーケンス番号、データ等)が包含される。この例は、ログが後に続くことを可能にし、現在のログが依存する他のログを判定可能にする。

多くの場合に、どのログが第１ログに依存するかを判定することが望ましい。これを支援するため、エンタングルメントがなされる場合に、双方のログに情報が格納されてよい。図３はペアのログにエンタングルメントを施すプロセスの一例を示すフローチャートである。このプロセスは処理ロジックで実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図３を参照するに、情報を格納する処理ロジックによりプロセスは始まり、ログＡの現在のローリングチェックサムをログＢのログエントリに含める(処理ブロック301)。

次に、処理ロジックは、ログＢに関する情報をログＡに格納する(処理ブロック302)。一実施例では、ログＡに格納されたログＢに関する情報は、ログＢのサーバ名、ファイル名又はURL、及びエンタングルメントが格納されるログの中の場所を含んでもよい。一実施例では、ログＡに格納される情報もログＢからのローリングチェックサムを含んでよい。チェックサムが格納されると、エンタングルメントがログＢからログＡへ及びログＡからログＢへなされる。

＜確認手順＞
多くの場合に、ログが作成されて以来ログが修正されているか否かを確認する必要がある。これはソフトウエア、コンピュータシステム及び人々(ログ生成のハードウエア、ソフトウエア及び人々と独立な人々)によってなされるべきである。

一実施例では、ログが首尾一貫していることを確認するため、(図１８のコンピュータシステム(又は専用マシン)におけるもののような)確認ソフトウエアが、ログの中の各エントリについてローリングハッシュを再計算する。確認ソフトウエアで計算されたローリングハッシュが、ログに格納されているローリングハッシュと合致したならば、そのエントリは、ハッシュ関数が漏洩していない限り、変更されていない。この場合において、ハッシュ関数が「漏洩している」とは、２つの別個のバイトシーケンスが、同じハッシュをもたらすことが発見されていることを意味する。

ログのエントリが複数のログの間で一致するか否かを確認する際、そのエントリは、他のログに格納された(エンタングルされた)ローリングチェックサムを含む及び関心のあるメッセージの中で一貫している必要がある。第２ログの中のエントリは、エンタングルメントエントリの前後で首尾一貫している必要がある。

＜エンタングリング検出手順の具体例＞
エントリが作成されて他のログとエンタングルされた後のある時点で、ログに格納されたメッセージの有効性を第三者が確認することを希望する場合、エンタングルメント検出は、メッセージに一致するエントリを有する全てのサーバが判定されることを可能にする。図４はエンタングルメント検出を実行するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックで実行され、その処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータ又は専用マシンで動作するようなもの)又はそれらの組み合わせで構成される。

図４を参照するに、空集合の(空であることの)証拠を有するサーバのリストを初期化し、単独のメッセージ又は所望のハッシュに関心のあるメッセージ又はハッシュのリストを初期化し、全ての既知のログについて関心のあるメッセージ又はメッセージハッシュをサーチする(処理ブロック401)処理ロジックによってプロセスは始まる。メッセージ又はそのハッシュが何処にも発見されなかった場合、確認は不可能であり、プロセスは終了する。

関心のあるメッセージ又はハッシュが発見された場合、処理ロジックは、メッセージ又はハッシュに続くローリングチェックサムを、そのメッセージ又はメッセージハッシュの発見されたログ全てについて確認する(処理ブロック402)。一実施例では、これは、確認ソフトウエアを使ってそのログについてチェックサムr_iを再計算することでなされる。

処理ロジックは、関心のあるハッシュ以後に表れる全てのローリングハッシュにハッシュのリストを付加し、現在のログで参照されるどのログにも、関心のあるログのリストを付加する(処理ブロック403)。あるログは他のログをリスト化せず、その場合そのサブステップを実行するものはない。

処理ロジックは、未探索の既知のログの1つの中で関心のあるリストのハッシュにおける全てのハッシュを探索する(処理ブロック404)。その後、処理ロジックはローリングハッシュがそのログに現れるか否かを検査する(処理ブロック405)。現れなければ、処理は処理ブロック404に移り、その処理を続ける。ローリングハッシュがログに現れた場合、処理ロジックは、オリジナルのメッセージ又はハッシュについての証拠(エビデンス)と共にそのログをログのリストに加え(処理ブロック406)、関心のあるハッシュ以後そのログに現れる全てのローリングチェックサムをそのハッシュリストに加え(処理ブロック407)、そのログで参照されるどのログもそのログリストに加える(処理ブロック408)。

その後処理ロジックは探索する何らかの別の既知のログが存在するか否かを確認する(処理ブロック409)。無ければ処理は終了する。有れば、処理は処理ブロック404に移り、関心のあるハッシュのリストに新たなハッシュが追加されなくなり、新たなログがリストログに追加されなくなるまでプロセスが反復される。

一般に、同じ装置、同じオフィス又は同じ会社に多くのログが保管されている。しかしながら、あるログが、複数の物理装置上の複数のログと関わりを持つ場合(エンタングルされる場合)又は異なる企業の管理下にあるログと関わりを持つ場合、そのログを確認する者は、そのログが変更されていないことについて更に多くの信頼を得るであろう。様々な装置とエンタングリングを行うこの利点は、ログはエンタングルされたログのアドレスを(企業及び装置境界を越えて)格納できるべきであることを意味する。これを行う1つの方法は、ログを特定するURLを利用することである。

以下のパイソン(Python)ソースコードは、他のログの中でメッセージハッシュを確認するログを判定する。このソースコードは、他のログへのリファレンスを含まないログの特定の形式で動作するように設計されている。従って、それは検査に初期化されたそのログの中だけで証拠を見つけ、新たなハッシュが既知のログだけについて探索される。ソースコードは、複数の独立したhttpサーバからログにアクセスするように設計されている。ソースの実行は今の場合サーバ毎に唯1つのログを使用しているが、サーバ当たり複数のログを許容するようにURLが修正されてもよい。

以下のサンプルソフトウエアは、有効なエンタングルメントを確認するのに使用されてよい：

一般に、ログを確認する上記の技法は多くの処理を含むかもしれない。しかしながら、以前に探索したログ及びハッシュの良好な追跡結果を保持することで、その複雑さを減らすことができる。ある時間以前に生じているログエントリを単に考察することで、或いは例えば或るログがエンタングリングに頻繁に使用されていることが分かっていた場合にそのログを先に探すことによっても複雑さを軽減することができる(そのログは早期に探索可能である)。

＜ログによる確認＞
ログの中のローリングチェックサムは、認証機構の一部に使用可能である。例えば、最も新しいローリングチェックサムr_Nの情報が、あるログに追加的なエントリを書き込むことの許可に使用されてもよい。ログを保持する装置は、最新のチェックサムが新たなログエントリに用意されていることを主張できる。そうすることで、２つの装置がそのチェックサムを知っており且つ双方がそのログに書き込みを要求した場合、一方のみが成功するようにできる。新たなログエントリを用意する第１の装置は、チェックサムの変更を引き起こし、以後、第２の装置は適切なチェックサムを持たなくなる。この技法は、データの提供者がそのログに関して最も最新のデータ情報を有する場合にのみ、新たなデータが追加されることを保証する方法をもたらす。こうして、チェックサムはログについての「ロック(lock)」のように使用可能であり、競合する状況を回避できる。

上記では、ログへのアクセスを管理するためにローリングチェックサムを使用することを説明しているが、ローリングチェックサムは、同じログが再び使用されることを防止するために使用されてもよい。その場合、ログの完全な内容は公に利用可能になっているべきでない。あるログを使って何者かがシステムと最初にやり取りを行い、そのログにメッセージを格納し、ローリングハッシュをシステムに提供する(例えば、ある口座に預金がなされた場合にメッセージが格納されるかもしれない。)。以後、その口座から引き出しが望まれる場合、システムはその預金をするのに使用されたローリングハッシュを要求する。更なるセキュリティが望まれる場合、一実施例では、システムはそのローリングハッシュについての情報(例えば、そのローリングハッシュのハッシュ及びチャレンジストリング)を要求する。システムは以前のやり取りに関する情報の一部分を要求することもでき、それはそのログを所有する者によってのみ回答可能である。

＜関連付け＞
上述のログ及び技法は多種多様な関連性を記録するのに使用されてもよい。より具体的には、特定のログの中のあるエントリは、メディアの２つの部分が互いに関連していることを示してもよい。作成の望まれるかもしれない１つの関連性は、２つの異なるメディアが異なるバージョンであるのを示すものであり、例えば一方は他方のアップグレードされたバージョンであることが示される。書類又は他のメディアの異なるバージョンは、コンテンツ(内容)が異なるので異なるハッシュ又はメディア識別子を持つことになる。しかしながら、あるアプリケーションでは、様々なバージョンを関連付け得ることが重要である。ある異なるバージョンの書類は、内容は変わらないが、変更されたフォーマットを有する書類を含むかもしれない(例えば、tiffファイルからJPEGファイルへの変換、HTML書類からPDFへの変換、mp3からAACへの変換等である。)。別の例では、異なるバージョンが僅かに異なる内容を含む(例えば、編集された書類、歌の２回目の録音、切り取られたホワイトバランス画像等)。更に別の場合でも、メタデータが変わったことだけに起因してバージョンが変わるかもしれない(例えば、コピーライトタグがmp3ファイルに付加されたり、色空間に関する何らかの情報が画像ファイルから削除された場合である。)。同じ紙書類の２つの別個のスキャンは、別バージョンになるようにみなされるかもしれない。何れの場合でも、２つの書類が同じものの別バージョンであるか否かは、アプリケーションに依存する。あるアプリケーションでは、その答は主観的であるが、別の場合には何らかの客観的な基準に基づいて判定可能である。例えば、同じ紙書類の別々のスキャンの場合のように、関連性を示さずに２つの書類が別個であることを、ログは明示的に述べる必要はない。あるアプリケーションはログにアクセスし、それらを同じ書類とみなすが、別のアプリケーションはそれらを別書類をみなすかもしれない。一実施例では、メディアの双方のバージョンを関連付け、多くの場合それらを同じメディアとして取り扱うためにログが使用される。しかしながら、例えば画像のようなメディアの有効性が維持される必要のあるアプリケーションでは、フォーマット変換により内容が変わっていないことを知ることは重要である。従って、このような場合には、２つのメディア部分が関連しているのを知るだけでなく、バージョン間の相違がフォーマット変更のものだけに限定されていることを知ることも重要になる。

一実施例では、ログのエントリは２つのメディアが何らかの方法で関連していることを示す。この関連性はそれらが等価な内容を有することでもよい。図５Ａは、関連するメディアの２つの部分の間の関連性を表すログのエントリを作成する様子を示す。図５Ａを参照するに、２つの書類D1,D2がメディア識別ジェネレータ501に入力される。書類D2は書類D1と別バージョンである。メディア識別ジェネレータ501は、書類D1,D2各々のメディア識別子を上述したように生成し、以後メディア識別子d_D1,d_D2としてそれぞれ言及する。メディア識別ジェネレータ501はエントリ502を生成し、エントリ502は書類D1,D2にそれぞれ対応するメディア識別子d_D1,d_D2をタイプインジケータt₁と共に含み、２つのメディア識別子d_D1,d_D2は、同じ書類の異なるバージョンであるメディアの２つの部分についてのメディア識別子であることを示す。エントリ502はログ503のエントリに格納され、ログはメモリ504に格納される。

以後、確認モジュール506は、それら２つが関連しているか否かを確認するリクエストの一部分として、書類D1又はD2の双方又は一方を入力として受信する。双方が入力された場合、メディア識別ジェネレータ501は双方についてメディア識別子を生成し、確認モジュールはログ503にアクセスし、メディア識別子の双方又は一方についてサーチする。確認モジュール506はエントリ502を見出し、タイプの指示を調べ、メディアの２つの部分が同じであることを示す出力を提供することができる。或いは、確認モジュール506は双方についてメディア識別子を受信し、上述したようにログ503をサーチする。そのような場合、メディア識別ジェネレータ501は必須でない。別の実施例では、確認モジュール506が書類の別バージョンのリクエストを受信する。その場合、確認モジュール506は書類D1のような書類を入力で受信し、書類のメディア識別子を生成し、メディア識別子を含むエントリのログ503をサーチする。確認モジュール506は、メディア識別子を有するログエントリ全てを検査し、タイプ識別子t₁に基づいて関連するバージョンを含むエントリを確認し、関連するメディアのメディア識別子を取得する。確認モジュール506は、関連する書類のメディア識別子を出力として用意し、及び／又はそのメディア識別子に対応するメディア(或いは、そのメディアが位置する場所及び／又はそのメディアのアクセス元の場所の指示情報)を用意することができる。

図５Ｂは、関連性を処理する処理ユニットの代替例を示す。図５Ｂを参照するに、メディア識別ジェネレータ501を用いてエントリを生成し、エントリ502をログ503に格納することは、図５Ａと同様である。しかしながら、メディア識別子501はメディア処理ユニット510の一部分であり、メディア処理ユニット510は、書類D1であるメディアの一部分のみを受信し、この例では書類D2であるメディアの第２部分を生成するフォーマッタ511を含む。例えば、フォーマッタ511は書類のビットマップ画像を生成してもよい。フォーマット処理の後、書類D2及び書類D1はメディア識別ジェネレータ501に入力され、エントリが上述したように生成される。そしてその処理は画像又は他のメディアを変換し、オリジナルメディアのハッシュ及び新たなメディアのハッシュを、それらの等価性を主張するログに入れる。

ログを利用することは、メディアに適用されている全ての処理を記録することに拡張可能である。システムは、或るステップから別のステップに至る一連のステップの後で、メディアの自動変換を実行できる(これらのステップは、必要に応じて、ログを検査することで後に確認可能である。)。一実施例では、ログは、入力されたメディアに使用されているアルゴリズムのハッシュを格納する。このハッシュを格納することで、及びメディア(又は別のアルゴリズムの出力)に適用されている他の如何なるアルゴリズムや処理のハッシュでも格納することで、メディアがどんな処理を受けたかを特定可能にする曖昧でないレコードが作成可能になる。一実施例では、ハッシュ関数に入力された情報は、アルゴリズムソースコードや、何らかのCPU情報を伴う実行ファイルを含む。

＜マルチメディアアソシエーション／コネクション＞
一実施例では、メディアの２つの部分の間の関連性を記録するのにログが使用される。メディアの２つの部分は、(一方は再フォーマット処理を受けてさえいないが)同じコンテンツでバージョンが僅かに異なっているものかもしれない。例えば、ストリーミングオーディオビデオの場合、欠落したフレーム及び解像度の相違に起因して、同じコンテンツの僅かに異なるバージョンを２人が見ることになるのが予想される。その場合、いくつかのハッシュがメディアの一部分に使用され、別々の提示の間で一致が生じるようにする。一実施例では、全フレーム、一部のフレーム又は各フレームの一部(例えば、ビデオのDC係数)のハッシュが生成される。これは、何らかの共通するフレームが受信された場合に、いくつかのハッシュが合致していることを確認処理が判定できるようにする。従って、一実施例では、異なる解像度でも依然として同じハッシュを有する。

図６は、関連メディアを関連付けるプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図６を参照するに、プロセスが始まり、処理ロジックは複数のメディア識別子をメディアの様々なバージョンに関連付け(処理ブロック601)、その後に複数のメディア識別子をログのエントリに格納する(処理ブロック602)。一実施例では、メディアの個々のバージョンが、異なるフレーム数又は異なる解像度を有する２つのビデオのバージョンに対応する。別の実施例では、一方のメディアが他方の「一部分又はサブセット(subset)」である。例えば、あるメディアはビデオのIフレームだけであるかもしれないし、或いは或るタグタイプのXMLファイルの一部分だけかもしれない(例えば、‘<item>’及び‘</item>’の間)。

一実施例では、サーバ又は他のコンピュータ装置は、メディアの全ての部分を有し、データの様々な部分について多くの識別子を計算する。この例は図５Ｂに示されている。或いは、サーバ又はコンピュータ装置は、ログの中に、エントリを互いに関連する複数のメディア識別子と共に格納する。クライアント又は他の装置のリクエストに基づいて、サーバは或る指示(例えば、タイプ識別子)と共に一部のハッシュを格納でき、タイプ識別子等はメディアの関連する一部分についてのものである。以後、これらは確認プロセスの一部として照合可能になる。

図７は、２つのメディア部分の間の関連性を確認するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図７を参照するに、プロセスが始まると、処理ロジックは第１メディアに対応する第１メディア識別子を取得する(処理ブロック701)。一実施例では、第１メディア識別子は、第１メディア識別子を入力として受信することで取得される。一実施例では、第１メディア識別子を受信することは、第１メディア識別子を含むサーチリクエストを受信することを含む。別の例では、第１メディア識別子は、第１メディアを受信し、第１メディアを使って第１メディア識別子を計算することで得られる。

一実施例では、第１メディアは或る書類であり、第１メディア識別子は書類識別子である。一実施例では、第１メディア識別子は上述したようなローリングチェックサム又は暗号化ハッシュ値である。一実施例では、第１メディア識別子はハッシュ関数を第１メディアに適用した結果である。上述したように、ハッシュ関数は如何なるハッシュ関数でもよく、例えば、SHA1暗号ハッシュアルゴリズム、SHA256暗号ハッシュアルゴリズム、MD5ハッシュアルゴリズム及び同様な性質を有する他の多くのハッシュアルゴリズム等でもよい。

処理ブロックは１つ以上のエントリを含むログにアクセスし、２つ以上のメディア識別子を互いに関連付け(処理ブロック702)、第２メディア識別子は第１メディア識別子と関連してはいるが異なっていることを示すログに基づいて、第１メディアは第２メディアに関連付けられている(処理ブロック703)。一実施例では、第１メディア識別子を含むログのログエントリにアクセスし、そのログエントリからタイプ情報を取得し、そのタイプ情報に基づいてログエントリが関連するメディア識別子を含んでいるか否かを判定し、そのタイプ情報に基づいてログエントリが関連するメディア識別子を含んでいることをタイプ情報が示していた場合、そのログエントリから第２メディア識別子を取得することで、第1メディアは第２メディアと関連するように判定される。

一実施例では、タイプ情報は識別子の形式であるが、このことは必須ではない。タイプ情報は、エントリ中のメディア識別子が或るメディアに対応することを示すのに使用される識別子であってよいし、或るメディアは、同じメディアに関連するもの、同じメディアの異なるバージョンでもよいし、又は或るメディアは別のメディアの別バージョンでもよい。

一実施例では、第１メディア及び第２メディアはメディアの異なるバージョンであり、ログのエントリは、第１及び第２メディア識別子が異なるバージョンのメディアに対応することを示す。一実施例では、第１メディア及び第２メディアがビデオの異なるフレームであり、ログの中のエントリは、第１及び第２メディア識別子が同じメディアの異なる部分であることを示す。一実施例では、第１及び第２メディアはビデオのフレームである。一実施例では、第１メディアが第２メディアに関連していることの確認に基づいて、第１メディアが第２メディアから導出されるよう決定される。

同じ書類の別バージョンである部分以外のメディア部分間における関係のタイプを記録するのにログが使用されてもよい。そのような関連性の１つは時間に基づくものである。即ち、メディア部分がある時間要素に基づいて関連付けられていることを記録するために、ログが使用されてもよい。例えば、一実施例では、書類が一緒に使用されることを記録するために、ログが使用されてもよい。例えば、最終的なステートメントが用意される場合に、あるレコードを含むエントリを有するログが作成され、そのレコードのサポート書類は財務的なステートメントが準備された場合に使用されたものである。より具体的には、一実施例では、紙書類がRFIDタグを有し、それらの書類中のidがハッシュに格納され、更にログは、作業のなされたスプレッドシート及び同時に電子的に開かれていた他の書類のハッシュを格納する。純粋に電子書類の場合、正規のスクリーンショットが作成され、ハッシュ処理され、ログに格納される。これらは、何が画面に有るか、決定が何時なされたか或いは何時処理がなされたか等を確認するために後に使用可能である。また、リナックス“lsof”(list open fles)のような或るコンピュータツールは、どのファイルが同時に使用され、どの情報がログに格納され、後の変更を防ぐために他のログと関わっているかを確認するのに使用されてよい。

図８は、時間情報に基づいてメディア間の関係を判定するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図８を参照するに、プロセスが始まると、処理ロジックは第１ログにアクセスして第１ログエントリを取得し、第２ログにアクセスして第２ログエントリを取得し(処理ブロック801)、第1ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得する(処理ブロック802)。第１ログエントリは第１メディアに対応する第１メディア識別子を含み、第２ログエントリは第２メディアに対応する第２メディア識別子を含む。第１及び第２ログは同じログでもよいことに留意を要する。

次に、第1及び第２ログエントリの時間情報に基づいて、第１メディアが第２メディアと関連していることを処理ロジックは確認する(処理ブロック803)。一実施例では、第1及び第２ログエントリの時間情報は、第１及び第２ログエントリの時間情報が、所定の閾値時間の範囲内(例えば、１分以内)に互いに収まっていたならば、関連しているように判定される。一実施例では、第１及び第２ログエントリが、それらの時間情報は同時とみなされることを示す場合に、時間情報は関連しているものとされる。

一実施例では、第１メディア及び第２メディアが或るメディアの異なるバージョンであることを確認することで、第１メディアは第２メディアに関連するように判定される。一実施例では、第１メディア及び第２メディアが或るビデオの異なるフレームであることを確認することで、第１メディアは第２メディアに関連するように判定される。第１メディアが第２メディアから導出されることを確認することで、第１メディアは第２メディアに関連するように判定される。

ログに格納される情報を使用するため及び時間に基づいて何らかの関連性を突き止めるため、情報が捕捉されてログに格納される。一実施例では、ログはコンピュータに関する人間の動作を捕捉する。例えば、ログは画面ショットのハッシュやアプリケーションからの情報を記録するのに使用され、その情報は、電子メールメッセージが閲覧されたこと、行、列及びタブのどれが閲覧されたか、どの書類がアプリケーションで開かれたか、どのファイルがダウンロードされたか、どのアプリケーションが書き込みの際に開かれたか等である。一実施例では、捕捉プロセスは、時間情報を捕捉することをも含み、メディア識別子及び／又はメディア(即ち、捕捉された情報)と共に、時間情報を何らかのエントリに含めることを可能にする。更に、そのようなログは、他のログとエンタングル処理(関わり合うように処理)された場合、確認可能になり、人がどんな処理を行ったかを各人が検討できるようにする。即ち、ログが他のログとエンタングル処理された場合、ローリングハッシュを記録すること及び他のログとエンタングル処理を行うことによる特徴は、ログに対する変更が、検出されずに行われてしまうことを防ぐ。

図９は、相互作用処理のプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図９を参照するに、プロセスが始まると、コンピュータシステムで使用されているアプリケーションに関するユーザ入力を処理ロジックは捕捉する(処理ブロック901)。一実施例では、ユーザ入力を捕捉することは、画面ショットのハッシュを記録すること、閲覧された電子メールメッセージを記録すること、閲覧された行、列及びタブを記録すること、アプリケーションで開かれていた書類を記録すること、ダウンロードされたファイルを記録すること、又は書き込むためのアプリケーションを記録すること等を含む。情報を捕捉した後、処理ロジックは、少なくとも１つの他のログとエンタングル処理された確認可能なログの情報を記録する(処理ブロック902)。

以後、ログが変更された後、情報等を捕捉することで、その関連性はログを監査に使用可能にする、或いは特定の書類を使用した者を探索可能にする。ログが書類を認めないように変更できない場合、或いはログの他の部分が検査される場合に可能である。図１０は、捕捉したメディアの一部分と他のデータとの間の関係を判定するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図10を参照するに、プロセスが始まると、処理ロジックはメディアを受信し(処理ブロック1001)、処理ロジックはそのメディアに対応するメディア識別子を生成する(処理ブロック1002)。メディア識別子を使って、処理ロジックは、監査処理の一部として、そのメディア識別子について装置の確認可能なログを探索し、装置がそのメディアに対するアクセス権を持っているか否かを判定する(処理ブロック1003)。例えば、探索されているログが処理した捕捉プロセスの一部として生成され、各人がタスクを実行していた場合、そのプロセスは書類(又は他のメディア)を使用し、それについてのメディア識別子を生成し、ログ内のメディア識別子を探索し、各人がその書類を見たか否かを確認する(なぜなら、それは捕捉プロセスの一部としてほそくされているからである。)。時間も捕捉可能であり、ログの何らかのサーチが、求められているメディアだけでなく時間にも基づいてなされてよいことに留意を要する。

＜ロギング処理＞
関連性の別の例は、ロギング処理の状況で生じる。ロギング処理は、出力(結果)を生成したもの(入力、出力、マシン及びプログラム(又は他の一群の処理))が、書類ログを使って証明される際の技法である。言い換えれば、ロギング処理を利用する際、ほとんどどの出力についても一連の確認手順が存在し、それは動作している複合的な一群のプログラムの結果である。一連の確認手順(確認チェーン)は、各処理ステップが実行されたことを誰かが確認できるようにする。そうすることで、その者は、確認プロセスの一部として処理を反復しなくて済むようにできる。

ロギング処理は特に重要な書類(例えば、財務記録)について有用になるかもしれない。例えば、財務記録を生成するために実行される全ての処理は、以後の再検討に備えて記録される。従って、ロギング処理は企業コンテンツ管理(ECM: Enterprise Content Management)規格及び／又は分散的書類管理サービスの一部になってもよい。

図１１は、ロギング処理の一例を示す図である。図１１を参照するに、1つ以上の処理動作３組1101-1103が一列に並んで示されている。各々は、別個のプログラムでもよいし、或いは３つが１つのプログラム又はその一部を表現してもよい。また、処理群1101-1103はワークフローを表現してもよい。この例では３つしか示されていないが、３つより多くの又は少ないものも使用可能であることを当業者は認めることに留意を要する。これらの処理群の各々は、コンピュータシステム又は他の何らかのコンピュータ装置内のプロセスによって実行されてよい。

入力、一群の書類動作、各群1101-1103各々の出力はログ1109に記録され、エントリ1106-1108としてメモリに格納される。一実施例では、ロギングに先立って、(上述したように)各々はメディア識別ジェネレータ1120によりメディア識別子に変換される。これは必須でないことに留意を要する。代替実施例では、入力の１つ以上のメディア識別子、一群の処理及び出力が生成される。こうして、ロギング処理を行うことが可能になり、入力、出力及び／又は一群の処理がログに格納され、公的なアクセスに有用になるかもしれない。

図１２は、ロギング処理のプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図１２を参照するに、プロセスが始まると、処理ロジックは入力を識別するために第１識別子を生成し(処理ブロック1201)、１つ以上の処理動作一式を識別するために第２識別子を生成し(処理ブロック1202)、１つ以上の処理動作一式の出力を識別するために第３識別子を生成する(処理ブロック1203)。一実施例では、１つ以上の処理動作一式を表す情報に第１ハッシュ関数を適用することで第１識別子が作成され、一群の処理動作に対する入力を表す情報に第２ハッシュ関数を適用することで第２識別子が生成され、一群の書類動作の出力を表す情報に第３ハッシュ関数を適用することで第３識別子が生成される。一実施例では、第１、第２及び第３ハッシュ関数は同じである。一実施例では、入力、出力及び／又は一群の処理動作の内の少なくとも１つの識別子は、ハッシュの結果物ではなく、上述したように、それらは如何なる付加的な処理なしに読み取り可能なままでもよいことに留意を要する。一実施例では、一群の処理動作はプログラムを構成する。

第１、第２及び第３識別子を作成した後に、処理ロジックは、第１、第２及び第３識別子と共にログ内のエントリを作成する(処理ブロック1204)。

その後に、処理ロジックは一群の処理動作を確認し、その処理動作は、ログにアクセスしてエントリの情報を取得した結果に基づいて、メディアについて実行される。即ち、プロセスログが一旦作成されると、それは、適用されるプロセスの再検討(レビュー)を可能にするようにアクセスされてもよい。レビューはプロセスが適切に実行されたことを確認するためになされてもよい。そのような確認は、適切な一群の１つ以上の処理が実行されたこと、及びそれらの処理が適切に及び適切な入力を用いて実行されたことを確認することでなされてもよい。

２つ以上のプロセスが並列的に生じた場合、(エンタングル処理により)関わり合うログは双方のプロセスについて実行可能である。そのようなエンタングル処理は、２つのプロセスが順に適切に動作したことを証明し、これは重要な業務又は安全な結果を備える。例えば、２つのプロセスが同時に動作していることがエンタングル処理されたプロセスログから明らかな場合、これは、処理の行き詰まり又は競合状態に起因する何らかの障害の原因を証明するのに使用されてもよい。或いは、２つの処理のタイミングに起因して、或るタスクの完了に対する題材である或る処理が適切に考慮されていなかったことを検出するのに使用されてもよい。タイムスタンプ情報はそのような判定を下すのに十分信頼できないかもしれないが、一連のハッシュの順序の性質は、多数の競合するプロセス(そのプロセスログはエンタングル処理されている)の中での順番を決めるのに使用可能である。例えば、多種多様な電子株取引システムのエンタングル処理されたプロセスログは、ある取引が適切であったか或いは不適切であったかを、ある取引者が何を取引していたかを他者に明らかにする必要なしに判定するのに使用されてもよい。飛行機の電子システムのプロセスログが、これらのシステムの相互作用により安全上の欠陥を明らかにするようにしてもよい。

不適切なプロセスが実行された場合、後の時点でログをレビューすることでその事実を確認可能であり、そのログに記録されている「ワークフロー」は訂正されたプロセス又は訂正された入力と共に返されてもよい。一実施例では、プロセスの演算ステップは誤りを訂正するようにネットワーク化される。例えば、入力、プログラム(又は他の一群の処理動作)、ログエントリ中の出力を保持することで、入力の１つが悪いものでありそのステップに戻ること、及び代替的な計算バージョンと共に新たなログを生成すること等を判定することができる。そのようなプロセスは、同様な計算の「仮の(what-if?)」バージョンを実行及び維持するために使用されてもよい。

プロセスが良好でないことの判定がなされると、そのプロセスは訂正され、新たなエントリがログの末尾に追加されてもよい。新たなエントリを含めることは、訂正がなされたことを示すのに使用されてもよい。例えば、ログエントリの１つが不適切であり、そのログに訂正が加わったことの指摘がなされてもよい(例えば、35行目に誤記が確認され、その後に訂正がなされたこと等である。)。このようにして、ログをレビューする他者が、そのエントリが不適切であるかを知り、正しい結果を得ることさえ可能である。

図１３は、プロセスが適切に実行されたことを確認するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図１３を参照するに、プロセスが始まると、処理ロジックは、第１、第２及び第３データを含む１つ以上のログエントリを有するログにアクセスする。一実施例では、第１、第２及び第３データの１つ以上は第１、第２及び第３メディア識別子でそれぞれ構成され、第１識別子は１つ以上の処理動作群を表し、第２識別子は１つ以上の処理動作への入力を表し、第３識別子は１つ以上の処理動作の出力を表す(処理ブロック1301)。一実施例では、第１、第２及び第３メディア識別子はハッシュ値である。一実施例では、第１，第２及び第３メディア識別子は、一群の処理動作を表す情報に、一群の処理動作への入力を表す情報に及び一群の処理動作の出力を表す情報にハッシュ関数をそれぞれ適用した結果である。一実施例では、ハッシュ関数はSHA1暗号化ハッシュアルゴリズム、SHA256暗号化ハッシュアルゴリズム又はMD5ハッシュアルゴリズムである。一実施例では、入力はユーザ入力である。一実施例では、ユーザ入力は、メニュー選択肢、パスワード、カーソル制御動作(例えば、マウスの動作)、及びペンの動きで構成される群中の１つ以上の選択肢である。別の実施例では、入力はメディア(例えば、書類)であり、第１メディア識別子はメディア識別子(例えば、書類識別子)である。更に別の実施例では、入力はユーザ入力及びファイルの組み合わせである。

次に、処理ロジックは、ログのログエントリの１つ以上における情報に基づいて、１つ以上の処理動作群が実行されたことを確認する(処理ブロック1302)。

次に、処理ロジックはログの中のエントリを再検討し、実行されたプロセスでエラーが生じたか否かを確認する(処理ブロック1303)。上述したように、これは、処理動作が適切に実行されか否か或いは適切な結果を生成したか否か(即ち、処理動作は適切な入力について適切になされたか否か)を判定するためになされる。

エラーのあったことを処理ブロックが確認した場合、処理ロジックはプロセスを再実行し(処理ブロック1304)、１つ以上の処理動作群を表す第４データと共に、１つ以上の処理動作への入力を表す第５データと共に及び１つ以上の処理動作の出力を表す第６データと共に、１つ以上の新たなログエントリをログに加える(処理ブロック1305)。第４、第５及び第６データは、メディア識別子でもよい。

別の実施例では、ログのレビューは最も正しい出力(例えば、最良の回答)を発見するのに使用されてもよい。そのような場合、ログを処理する際、回答がログの或るエントリの中で発見されるかもしれないが、それでもレビューはそのログの中で継続され、ログの中の後続のエントリが先行するエントリは適切でないことを示すか否かを調べる。他のどのエントリもその場合に該当しなかったならば、レビューを行った者は、それらが利用可能なより適切な回答を得ていることを知る。

一実施例では、結果(データ)は何らかの情報を露呈することなく認証される。例えば、サーバはデータベースに一群のSQLクエリ(問い合わせ語句)の入力及び出力を記録する。そして、提示されたクエリがなされたものであったこと、及び提示された結果を得ていることを誰かが確認するかもしれないが、それらの者は他のクエリに関する情報を得ることはできない。

＜アーカイブビットマップ＞
一実施例では、上述のログ及びロギング技法の利用は、拡張された期間の間に、書類にアクセスして関連性を維持することに使用されてもよい。一実施例では、１つ以上の関連する書類はビットマップの形式で保持される。そのような書類へのアクセス及び保持はサービスとして提供されてもよい。一実施例では、サービスは、ある期間(例えば、100年間)にわたって書類のビットマップを保持することを保証する。サービスは必要に応じて新たなフォーマットにビットマップを更新し、現在のビットマップ及び初期に提供されたビットマップ又はメディアの間の関連性を示す証明書と共に、対象物の現在のビットマップ形式を常に保持する。現在のビットマップ及び初期に提供されたビットマップ又はメディアの間の関連性の記録を維持するため、一実施例ではログが保持され、以前のバージョン、ハッシュ及び（様々なバージョンの間で実行された)処理の1つ以上を示すようにする。

一実施例では、（例えば、オリジナル書類のような）古いバージョンから生成されている場合に書類の新たなバージョンをサーバは示し、それにより古いバージョンとの関連性を証明する。

図１４は、アーカイブサービスの一例を示すブロック図である。図１４を参照するに、アーカイブユニット1400は画像1401を受信する。一実施例では、画像1401はビットマップである。一実施例では、アーカイブユニット1400は画像1401のメディア識別子を生成するメディア識別ジェネレータを含み、メディア識別子はエントリ1405の一部としてログ1407に格納されてもよい。エントリ1405は時間に基づいて時間識別子を含み、画像1401は受信され、時間入力1404によって指定され、画像はメディア識別ジェネレータ1403で生成されるメディア識別子の形式であってもなくてもよい。

一実施例では、アーカイブユニット1400は新たなバージョンジェネレータ1402を含む。この場合、メディア1401はビットマップではなく、新たなバージョンジェネレータ1402はビットマップを生成するように構成されてもよい。そして、新たに生成されたビットマップは、メディア1401と共に、選択的に1404と共に、メディア識別ジェネレータ1403に入力され、メディア識別ジェネレータはエントリ1405の一部としてログ1407に格納されるメディア識別子を生成する。そのような場合、エントリ1405は画像1401及び新たに生成されたビットマップの間の関連性を記録する。

別の実施例では、メディア1401はビットマップであり、新たなバージョン生成ジェネレータ1402はビットマップ1401の新たなバージョンを生成する。例えば、ビットマップ1401がソフトウエアの古いバージョンと共に生成され、新たなバージョンジェネレータ1402はソフトウエアの最新バージョンを用いてビットマップ1401の新しいバージョンを生成することができる。上述の実施例と同様に、メディア識別子が作成され、ログ1407のエントリ1405として格納され、２つのバージョン間の関連性を記録する。

一実施例では、サービスは、書類及び／又は書類のバージョンを維持するための手数料を課金する。様々な課金モデルが使用されてよく、１回の利用料金を使ってもよいし、周期的なキー(例えば、年間の料金)等を使ってもよいが、これらに限定されない。

図１５は、ログを使ってアーカイブサービスを実行するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図１５を参照するに、プロセスが始まると処理ロジックは１つ以上のエントリと共にログを維持する。この場合において、１つのエントリは、第１バージョンのメディアに関連する第１メディア識別子と、第１バージョンのメディアから生成されたメディアのビットマップ表現に対応する第２メディア識別子とを格納する(処理ブロック1501)。次に、処理ロジックはログにアクセスし、第１バージョンのメディアとメディアのビットマップ表現との間の対応関係を確認する。このアクセス及び確認は、ユーザのリクエストに応答してもよく(そのリクエストでユーザはメディアの第１バージョン又はビットマップ表現を提供し)、ユーザの提供している表現が他のバージョンに関連しているか否かを判定しようと試みる。一実施例では、メディアの第１バージョン及びメディアのビットマップ表現は、同じソフトウエアプログラムの２つの異なるバージョンと共に生成されている。そのような場合、ユーザは先行するバージョンで生成された表現を有し、新たなバージョンを希望するかもしれない。

一実施例では、或るエントリにアクセスし、その或るエントリ中の時間情報を分析することで、メディアの第１バージョン及びメディアのビットマップ表現が何時作成されたかを処理ロジックは確認する。一実施例では、時間情報はその或るエントリ内にハッシュ値として格納されている。

一実施例では、処理ロジックは対応関係を確認した後でメディアの第２バージョンを用意する(処理ブロック1502)。一実施例では、第２バージョンは第１バージョンよりも新しいメディアのバージョンである。

一実施例では、サービスプロバイダはサービスを実行するために多数の処理を実行する。図１６は、アーカイブサービスを提供するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図１６を参照するに、オリジナルメディアにアクセスすることでプロセスが始まる(処理ブロック1601)。一実施例では、オリジナルメディアは書類のビットマップ、スクリーンショット又は他の何らかの画像フォーマットである。

メディアを受信した後、処理ロジックは、そのログを更新し、オリジナルメディアが受信された日付を特定する指摘を含めるようにし(処理ブロック1602)、オリジナル書類がビットマップに未だなっていなかったならば、選択的に、オリジナル書類をビットマップに変換する(処理ブロック1603)。

ビットマップ形式になると、処理ロジックは、或るエントリと共にログを更新し、そのログ(エントリ)は、オリジナルメディア及びビットマップ間の関係を特定し、それらが関連していることを示す(処理ブロック1604)。エントリはそのエントリに対応する識別子及びそのメディアに対応する識別子を含む。一実施例では、エントリは、ビットマップが作成された時点を示す。このログは、オリジナルの受領日に受信したのと同じログでもよい。

以後、選択的に、処理ロジックはメディアの最新バージョンを維持し、この維持は、アクセス可能なエントリと共にログを維持し、最新のバージョンとオリジナルメディア間の関係を確認することを含む(処理ブロック1605)。一実施例では、最新バージョンを維持することは手数料を受領することに応答して行われる。

選択的に、オリジナルメディア又はオリジナルメディアのバージョンに対応するリクエストを処理ロジックが受けることをプロセスは含んでもよい(処理ロジック1606)。このリクエストは、オリジナルメディアを含み、そのメディアの現在のバージョンを取得することを求める。ユーザが保持している特定のバージョンのメディアが、オリジナルメディアに又は別バージョンのメディア(例えば、最新バージョン)に関連しているか否かをそのリクエストは突き止めようとする。このリクエストに応答して、一実施例では、処理ロジックは、受信したメディアについて新たなメディア識別子を生成し、新たな識別子を求めてログをサーチし、或る指摘を用意する(その指摘は、第２ログが新たな識別子を含んでいた場合に、受信したメディアが、オリジナルメディア又はビットマップの双方又は一方に関連していることを示す。)。これは、証明データを提供することで実行されてもよく、例えば、受信したメディア(最新バージョンのメディアかもしれない)とオリジナルバージョンのメディアとの間の関係を立証することでなされてもよい。

リクエストに応答して、一実施例では、処理ロジックはログを更新し、そのバージョンの１つが要求された時点を示す(処理ブロック1607)。この選択的な動作は全てのプロセスと共に実行されなくてもよい。

最新バージョンのメディアとオリジナルバージョンのメディアとの間の関係を立証するために使用される証明データも、処理ブロックは用意する(処理部録1608)。一実施例では、証明データが証明書になる。一実施例では、処理ロジックは手数料を受け取ることに応じて証明データを用意する(例えば、証明書を発行する)。

図１７は、サービスを利用するユーザプロセスの一例を示すフローチャートである。このプロセスは処理ロジックによって実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。

図１７を参照するに、プロセスが始まると処理ロジックはメディアをサービスに送る(処理ブロック1701)。そして処理ロジックはそのメディアの異なるバージョンを受信し(処理ブロック1702)、証明データを受け(処理ブロック1703)、その証明データは、そのメディアが格納されていることを示し、且つその異なるバージョンがそのメディアに関連していることを示す。

＜コンピュータシステムの具体例＞
図18は上記の動作の1つ以上の実行するコンピュータシステムの一例を示すブロック図である。図18を参照するに、コンピュータシステム1800は例示的なクライアント又はサーバコンピュータシステムで構成されてよい。コンピュータシステム1800は、情報を通信する通信手段又はバス1811、及び情報を処理するためにバス1811に結合されたプロセッサ1812を有する。プロセッサ1812は例えばペンティアム(登録商標)等のようなマイクロプロセッサを含むがこれに限定されない。

システム1800は、バス1811に結合された、ランダムアクセスメモリ(RAM)又は他のダイナミックストレージデバイス1804(メインメモリと言及される)を更に有し、これらのメモリ等はプロセッサ1812で実行される命令や情報を格納する。メインメモリ1804はプロセッサ1812による命令の実行中に変数や他の中間的な情報を一時的に格納する。

コンピュータシステム1800は、バス1811に結合されたリードオンリメモリ(ROM)及び／又は他のスタティックストレージデバイス1806(これらもプロセッサ1812のための命令や静的な情報を格納する)と、磁気ディスク、光ディスク及びディスクドライブに関連するようなデータストレージデバイス1807とを更に有する。データストレージデバイス1807は情報及び命令を格納するためにバス1811に結合される。

コンピュータシステム1800は、バス1811に結合され、コンピュータユーザに情報を表示する陰極線管(CRT)液晶ディスプレイ(LCD)のようなディスプレイ装置1821に結合される。情報及びコマンド選択内容をプロセッサ1812に通知するため、英数字及び他のキーを含む英数字入力装置1822もバス1811に結合される。更なるユーザ入力装置はカーソル制御部1823(例えば、マウス、トラックボール、トラックパッド、スタイラス又はカーソル指示キー)であり、指示情報及びコマンド選択内容をプロセッサ1812に通知したり、ディスプレイ装置1821でのカーソルの動きを制御するのに使用される。

バス1811に結合される他の装置はハードコピー装置1824であり、命令、データ又は他の情報を紙、フィルム又は同様なタイプの媒体に印刷するのに使用される。更に、スピーカ及び／又はマイクロフォン等を備えた音声記録及び再生装置がバス1811に選択的に結合され、コンピュータシステム1800との音声インターフェースを用意する。バス1811に結合されてよい別の装置は、有線の／無線の通信機能部1825であり、電話又は携帯用装置と通信する。

システム1800及び関連するハードウエアの要素の全部又はどの一部分でもが本発明で使用されてよいことに留意を要する。しかしながら、コンピュータシステムの他のコンフィギュレーションは本装置の全部又は一部を含んでよいことが理解されるであろう。

本発明に関する多くの代替例及び変形例は、上記の説明を理解した当業者にとっては 疑う余地無く明らかである。例示的に図示及び説明された如何なる特定の実施例も、限定的に解釈されるべきでないことが理解されるべきである。従って、様々な実施例の詳細に関連するものは、本発明の範囲を限定するように解釈されるべきでなく、特許請求の範囲は、本発明に本質的であると認められる事項のみを列挙している。

以下、本発明により教示される手段を例示的に列挙する。

（付記１）
第１メディアに対応する第１メディア識別子を取得するステップと、
２以上のメディア識別子を互いに関連付ける１つ以上のエントリを含むログにアクセスするステップと、
第２メディア識別子は前記第１メディア識別子と異なるが関連付けられていることを示す前記ログに基づいて、前記第１メディアが前記第２ログに関連していることを確認するステップと、
を有する方法。

（付記２）
第１メディア識別子を取得するステップが、前記第１メディア識別子を受信するステップを含む第１項記載の方法。

（付記３）
第１メディア識別子を取得するステップが、前記第１メディアを受信し、前記第１メディアを用いて前記第１メディア識別子を計算するステップを含む第１項記載の方法。

（付記４）
前記第１メディアが前記第２ログに関連していることを確認するステップが、
前記第１メディア識別子を含む前記ログ内のログエントリにアクセスするステップと
前記ログエントリからタイプ情報を取得するステップと、
前記タイプ情報に基づいて、前記ログエントリが関連するメディア識別子を含んでいるか否かを判定するステップと、
前記タイプ情報に基づいて、前記ログエントリが関連するメディア識別子を含んでいることを前記タイプ情報が示していた場合、前記ログエントリから前記第２メディア識別子を取得するステップと、
を有する方法。

（付記５）
前記第１メディア及び前記第２メディアが異なるバージョンのメディアであり、前記ログ内のエントリが、前記第１及び前記第２メディア識別子は異なるバージョンのメディアに対応することを示す第１項記載の方法。

（付記６）
前記第１メディア及び前記第２メディアがビデオの異なるフレームであり、前記ログ内のエントリが、前記第１及び前記第２メディア識別子は同じメディアの異なる部分であることを示す第１項記載の方法。

（付記７）
前記第１及び第２メディアがビデオのフレームである第６項記載の方法。

（付記８）
前記第１メディアが第２メディアに関連していることの確認に基づいて、前記第１メディアが前記第２メディアから導出されていることを確認するステップを更に有する第１項記載の方法。

（付記９）
第１メディア識別子を受信するステップが、前記第１メディア識別子を含むサーチリクエストを受信するステップを含む第１項記載の方法。

（付記１０）
前記第１メディア識別子は、暗号ハッシュ値で表現される第１項記載の方法。

（付記１１）
前記第１メディア識別子は、ハッシュ関数を前記第１メディアに適用した結果である第１０項記載の方法。

（付記１２）
前記ハッシュ関数は、SHA1暗号化ハッシュアルゴリズム、SHA256暗号化ハッシュアルゴリズム及びMD5ハッシュアルゴリズムで構成される群の内の１つで行われる第１１項記載の方法。

（付記１３）
前記第１メディアが書類であり、前記第１メディア識別子が書類識別子である第１項記載の方法。

（付記１４）
命令を格納する１つ以上のコンピュータ読み取り可能な記憶媒体を有する製品であって、前記命令は、システムで実行される際、通信を認証する方法を前記システムに実行させ、前記方法は、
第１メディアに対応する第１メディア識別子を取得するステップと、
２以上のメディア識別子を互いに関連付ける１つ以上のエントリを含むログにアクセスするステップと、
第２メディア識別子は前記第１メディア識別子と異なるが関連付けられていることを示す前記ログに基づいて、前記第１メディアが前記第２メディアに関連していることを確認するステップと、
を有するようにした製品。

（付記１５）
第１ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得するステップと、
関連する前記第１及び第２ログエントリの前記時間情報に基づいて、第１メディアが第２メディアと関連していることを確認するステップと、
を有し、前記第１ログエントリは前記第１メディアに対応する第１メディア識別子を含み、前記第２ログエントリは前記第２メディアに対応する第２メディア識別子を含む方法。

（付記１６）
前記第１及び第２ログエントリの前記時間情報が、互いに所定の時間閾値の範囲内にあった場合に、前記第1及び第２ログエントリの前記時間情報は関連しているように判定される第１５項記載の方法。

（付記１７）
前記第1及び第２ログエントリが各自の時間情報は同じであることを示す場合に、前記時間情報は関連しているように判定される第１５項記載の方法。

（付記１８）
前記第１ログエントリを取得するために第１ログに、及び前記第２ログエントリを取得するために第２ログにアクセスする第１５項記載の方法。

（付記１９）
前記第１メディアが前記第２ログに関連していることを確認するステップが、前記第１メディア及び前記第２メディアは別バージョンのメディアであることを確認するステップを含む第１５項記載の方法。

（付記２０）
第１メディアが第２メディアと関連していることを確認するステップが、前記第１メディア及び前記第２メディアはビデオの異なるフレームであることを確認するステップを含む第１５項記載の方法。

（付記２１）
前記第１メディアが前記第２メディアと関連していることを確認するステップが、前記第１メディアは前記第２メディアから導出されたものであることを確認するステップを含む第１５項記載の方法。

（付記２２）
命令を格納する１つ以上のコンピュータ読み取り可能な記憶媒体を有する製品であって、前記命令は、システムで実行される際、通信を認証する方法を前記システムに実行させ、前記方法は、
第１ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得するステップと、
関連する前記第１及び第２ログエントリの前記時間情報に基づいて、第１メディアが第２メディアと関連していることを確認するステップと、
を有し、前記第１ログエントリは前記第１メディアに対応する第１メディア識別子を含み、前記第２ログエントリは前記第２メディアに対応する第２メディア識別子を含むようにした製品。

（付記２３）
複数のメディア識別子を異なるバージョンのメディアに関連付けるステップと、
前記複数のメディア識別子をログのエントリに格納するステップと、
を有する方法。

（付記２４）
コンピュータシステムで使用されるアプリケーションに関するユーザ入力を取得するステップと、
少なくとも１つの他のログと関わり合う確認可能なログに情報を記録するステップと、
を有する方法。

（付記２５）
前記ユーザ入力を取得するステップが、画面ショットのハッシュを記録すること、閲覧した電子メールメッセージを記録すること、行、列及びタブが閲覧されたことを記録すること、前記アプリケーションで開かれていた書類を記録すること、ダウンロードされたファイルを記録すること及び書き込みようのアプリケーションを記録することで構成される群の内の１つで行われる第２４項記載の方法。

（付記２６）
メディアを受信するステップと、
前記メディアに対応するメディア識別子を生成するステップと、
監査処理の一部として前記メディア識別子を求めて装置の確認可能なログを探索し、前記装置が前記メディアにアクセスしたか否かを判定するステップと、
を有する方法。

エントリを生成してログの中に格納する様子を示す図である。 メディアのハッシュを生成してログの中に格納する様子を示す図である。 ログのペアを関連付けるプロセスの一例を示すフローチャートである。 エンタングルメント検出を実行するプロセスの一例を示すフローチャートである。 関連する２つのメディア部分の間の関連性を示すように使用されるログのエントリを作成する様子を示す図である。 サーバ又は他のコンピュータ装置が全てのメディアの部分を有し、様々なデータの部分について多くの識別子を作成する様子を示す図である。 関連メディアを関連付けるプロセスの一例を示すフローチャートである。 ２つのメディア部分の間の関連性を確認するプロセスの一例を示すフローチャートである。 時間情報に基づいてメディア間の関係を判定するプロセスの一例を示すフローチャートである。 相互作用処理のプロセスの一例を示すフローチャートである。 捕捉したメディアの一部分と他のデータ部分との間の関係を判定するプロセスの一例を示すフローチャートである。 ロギング処理の一例を示す図である。 ロギング処理のプロセスの一例を示すフローチャートである。 プロセスが適切に実行されたことを確認するプロセスの一例を示すフローチャートである。 アーカイブサービスの一例を示すブロック図である。 ログを使ってアーカイブサービスを実行するプロセスの一例を示すフローチャートである。 アーカイブサービスを実行するプロセスの一例を示すフローチャートである。 サービスを利用するユーザプロセスの一例を示すフローチャートである。 本願で説明される１つ以上の動作を実行するコンピュータシステムのブロック図である。

符号の説明

101 メッセージ及びチェックサムジェネレータ
102 連結モジュール
103，203 ハッシュモジュール
110，210 記録部
501，507 メディア識別ジェネレータ
503 ログ
504 メモリ
506 確認モジュール
510 メディア処理ユニット
511 フォーマッタ
904 メインメモリ
906 スタティックメモリ
907 大容量ストレージメモリ
911 バス
912 プロセッサ
920 外部ネットワークインターフェース
921 ディスプレイ
922 キーボード
923 カーソル制御装置
924 ハードコピー装置

Claims (10)

1. 処理装置が行う処理方法であって、
   第１ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得するステップと、
   関連する前記第１及び第２ログエントリの前記時間情報に基づいて、第１メディアが第２メディアと関連していることを確認するステップと、
   を有し、前記第１ログエントリは前記第１メディアに対応する第１メディア識別子を含み、前記第２ログエントリは前記第２メディアに対応する第２メディア識別子を含み、
   前記第１及び第２ログエントリ各々から取得された時間情報が示す時間が、所定の時間範囲内にあった場合に、前記第1及び第２ログエントリの時間情報は関連していると判定され、
   前記第１及び第２ログエントリの各々は、メッセージに対してハッシュ計算したものとローリングチェックサムとのペアの一連のレコードを含み、或るレコードにおけるローリングチェックサムは、少なくとも、先行するレコードにおけるローリングチェックサムと、時間情報と、メッセージに対してハッシュ計算したものとを連結してハッシュ計算したものである、処理方法。
2. 前記第１ログエントリを取得するために第１ログに、及び前記第２ログエントリを取得するために第２ログにアクセスする請求項１記載の処理方法。
3. 前記第１メディアが前記第２ログに関連していることを確認するステップにおいて、前記第１メディア及び前記第２メディアは別バージョンのメディアであることを確認する、請求項１又は２に記載の処理方法。
4. 前記第１メディアが第２メディアと関連していることを確認するステップにおいて、前記第１メディア及び前記第２メディアはビデオの異なるフレームであることを確認する、請求項１ないし３の何れか１項に記載の処理方法。
5. 前記第１メディアが前記第２メディアと関連していることを確認するステップにおいて、前記第１メディアは前記第２メディアから導出されたものであることを確認する、請求項１ないし４の何れか１項に記載の処理方法。
6. 第１ログの第１ログエントリ及び第２ログの第２ログエントリ双方から時間情報を取得する手段と、
   関連する前記第１及び第２ログエントリの前記時間情報に基づいて、第１メディアが第２メディアと関連していることを確認する手段と、
   を有し、前記第１ログエントリは前記第１メディアに対応する第１メディア識別子を含み、前記第２ログエントリは前記第２メディアに対応する第２メディア識別子を含み、
   前記第１及び第２ログエントリ各々から取得された時間情報が示す時間が、所定の時間範囲内にあった場合に、前記第1及び第２ログエントリの時間情報は関連していると判定され、
   前記第１及び第２ログエントリの各々は、メッセージに対してハッシュ計算したものとローリングチェックサムとのペアの一連のレコードを含み、或るレコードにおけるローリングチェックサムは、少なくとも、先行するレコードにおけるローリングチェックサムと、時間情報と、メッセージに対してハッシュ計算したものとを連結してハッシュ計算したものである、処理装置。
7. 前記第１ログエントリを取得するために第１ログに、及び前記第２ログエントリを取得するために第２ログにアクセスする請求項６記載の処理装置。
8. 前記第１メディアが前記第２ログに関連していることを確認する手段において、前記第１メディア及び前記第２メディアは別バージョンのメディアであることを確認する、請求項６又は７に記載の処理装置。
9. 前記第１メディアが第２メディアと関連していることを確認する手段において、前記第１メディア及び前記第２メディアはビデオの異なるフレームであることを確認する、請求項６ないし８の何れか１項に記載の処理装置。
10. 前記第１メディアが前記第２メディアと関連していることを確認する手段において、前記第１メディアは前記第２メディアから導出されたものであることを確認する、請求項６ないし９の何れか１項に記載の処理装置。