(57)【要約】【課題】ロギング及び／またはデータ交換同期のための方法と装置を提供する。【解決手段】要求装置からの第１のログにデータをポストする要求を受ける段階と、第１のログの記憶場所を示す要求中のコンテクスト識別子と第１のログに対応する文書に関するデジタルデータとに基づきログを特定する段階と、要求中のデータに基づいて第１のエントリを生成する段階と、第１のログに第１のエントリを加える段階と、第１のログ中のログエントリに基づいて第１の識別子を計算する段階と、第１の識別子を要求装置に送信する段階とを有する方法である。【選択図】図１
2007293855.tif 000002
【特許請求の範囲】
【請求項１】
第１のログにデータをポストする要求を要求装置から受ける段階と、
前記第１のログの記憶場所を示す要求中のコンテクスト識別子と前記第１のログに対応する文書に関するデジタルデータとに基づき前記第１のログを特定する段階と、
要求中のデータに基づいて第１のエントリを生成する段階と、
前記第１のログに第１のエントリを加える段階と、
前記第１のログ中のログエントリに基づいて第１の識別子を計算する段階と、
前記第１の識別子を前記要求装置に送信する段階とを有する、方法。
【請求項２】
前記第１のログにポストされた１つ以上のアイテムを有する応答を送信する段階をさらに有する、
請求項１に記載の方法。
【請求項３】
第２のログを１つ以上のアイテムと同期させる段階をさらに有する、
請求項２に記載の方法。
【請求項４】
前記第２のログを１つ以上のアイテムと同期させる段階は、
１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツと属性エントリの第１のシーケンスと第２のシーケンスを含む第１のログと第２のログにある属性エントリの交点を計算する段階と、
前記第１のログにおける出現に応じて前記エントリを順序付ける段階と、
前記第２のログ中の各エントリが属性エントリの交点にあるか、または順番が次のエントリであるかを判断する段階と、
シーケンスの第１と第２のセットの後の第１と第２のログの各々のチェックポイントから始まる、第１のログと第２のログの間の追加的比較を実行する段階とを有する、
請求項３に記載の方法。
【請求項５】
第１のログを１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツ及び属性エントリのシーケンスを含むフォーマットで保持する段階と、
コンテクストログにアクセスして、その内部に記憶された情報を検索する段階とをさらに含む、
請求項１に記載の方法。
【請求項６】
１つのコンテンツエントリはストリングのハッシュとそのストリングとを有するベクトルを含む、
請求項５に記載の方法。
【請求項７】
１つの属性エントリは、コンテンツエントリの識別子と、コンテンツ中のそのコンテンツエントリの属性のラベルとその属性に関連付けられた値とにより構成された１つ以上のペアとをつなげた、ログファイルと関連付けられた識別子を含むエントリを有するベクトルを有する、
請求項５に記載の方法。
【請求項８】
少なくとも１つのチェックポイントは、前のチェックポイントのハッシュに、その前のチェックポイントとその少なくとも１つのチェックポイントとの間のすべてのエントリがつながったものを含む、請求項５に記載の方法。
【請求項９】
コンテクストは、第１と第２の識別子の組み合わせであり、第１の識別子はマシンを識別し、第２の識別子はデジタルデータのグループを識別する、
請求項５に記載の方法。
【請求項１０】
第１のログ中のエントリに対する、チェックポイントを含む要求を受信する段階と、
要求を満たすチェックポイントの後のエントリを送信する段階とをさらに有する、
請求項１に記載の方法。
【請求項１１】
前記第１のログの前記エントリに対する要求は、要求で指示されたチェックポイント後のすべてのエントリに対する要求であり、当該チェックポイントが第１のログにあるか判断する段階をさらに有する、
請求項８に記載の方法。
【請求項１２】
少なくとも１つのエントリは他の記憶場所に伝達されたデータの第１のハッシュバージョンを含み、そのデータを第１のログの信ぴょう性を確認するために使用し、
マシンが第１のログを生成したことを証明する要求をそのマシンが受信する段階と、
前記マシンがデータを送信して、当該マシンが前記第１のログを生成したことを証明するために伝達された第１のハッシュバージョンのインスタンスと比較される、データの第２のハッシュバージョンを生成するためにハッシュをデータに適用する
請求項１１に記載の方法。
【請求項１３】
前記要求で受信したデータの一部のハッシュを計算する段階と、
前記ハッシュを前記第１のログと関連づけられた識別子中の１つ以上のハッシュのリストと比較する段階と、
前記ハッシュが前記識別子中のハッシュのリストに現れる場合、ポスト要求を受け入れる段階とを有する、
請求項１に記載の方法。
【請求項１４】
第１のチェックポイント後にある第１のコンテクストログ中のエントリに対する要求を送信する段階と、
前記要求を満たす前記第１のチェックポイントの後の前記エントリを受信する段階と、
前記第２のコンテクストログと前記第１のコンテクストログを同期させるために、第２のコンテクストログに１つ以上のエントリを加える段階とを有する、方法。
【請求項１５】
第１のコンテクストログは１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツ及び属性エントリのシーケンスを含むファイルフォーマットを有する、
請求項１４に記載の方法。
【請求項１６】
１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツと属性エントリの第１のシーケンスと第２のシーケンスを含む第１のログと第２のログにある属性エントリの交点を計算する段階と、
前記第１のログの出現に応じて前記エントリを順序付ける段階と、
前記第２のログ中の各エントリが属性エントリの交点にあるか、または順番が次のエントリであるかを判断する段階と、
シーケンスの第１と第２のセットの後の第１と第２のログの各々のチェックポイントから始めて、第１のログと第２のログの間の追加的比較を実行する段階とを有する方法。
請求項１４に記載の方法。
【請求項１７】
システムにより実行されると、システムに一方法を実行させる命令を格納した記録媒体であって、
第１のチェックポイント後にある第１のコンテクストログ中のエントリに対する要求を送信する段階と、
前記要求を満たす前記第１のチェックポイントの後の前記エントリを受信する段階と、
前記第２のコンテクストログと前記第１のコンテクストログを同期させるために、第２のコンテクストログに１つ以上のエントリを加える段階とを含む方法を前記システムに実行させる記憶媒体。
【請求項１８】
１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツと属性エントリの第１のシーケンスと第２のシーケンスを含む第１のログと第２のログにある属性エントリの交点を計算する段階と、
前記第１のログの出現に応じて前記エントリを順序付ける段階と、
第２のログ中の各エントリが属性エントリの交点にあるか、または順番が次のエントリであるかを判断する段階と、
シーケンスの第１と第２のセットの後の第１と第２のログの各々のチェックポイントから始まる、第１のログと第２のログの間の追加的比較を実行する段階とを有する、方法。
【請求項１９】
ハッシュのリストを有する識別子を含むログに第１のエントリを記憶する段階と、
データの一部を含む新しいエントリをログにポストする要求を受信する段階と、
前記要求で受信したデータの一部のハッシュを計算する段階と、
前記ハッシュを前記識別子中の１つ以上のハッシュのリストと比較する段階と、
前記ハッシュが前記識別子中のハッシュのリストに現れる場合、ポスト要求を受け入れる段階とを有する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は文書処理の分野に関する。より具体的には、本発明はロギングとデータ交換同期に関する。
【背景技術】
【０００２】
信頼できる共有の履歴を残すことは、地域社会における信頼の基礎である。複式会計やペーパートレール（paper  trails）等の標準的なプロセスによりトレーサビリティ（traceability）と監査のサポートが得られる。これらの記録を独立に検証することは、地域の病院と自助グループから世界的な証券取引まですべての地域社会と機関が機能する上で重要である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ロギング（logging）及び／またはデータ交換同期のための方法と装置を提供する。
【課題を解決するための手段】
【０００４】
一実施形態において、本方法は、要求装置からの第１のログにデータをポストする要求を受ける段階と、第１のログの記憶場所を示す要求中のコンテクスト識別子と第１のログに対応する文書に関するデジタルデータとに基づきログを特定する段階と、要求中のデータに基づいて第１のエントリを生成する段階と、第１のログに第１のエントリを加える段階と、第１のログ中のログエントリに基づいて第１の識別子を計算する段階と、第１の識別子を要求装置に送信する段階とを有する。
（発明の詳細な説明）
【０００５】
本発明は、以下の詳細な説明と本発明のいろいろな実施形態を示した添付図面から、よりよく理解できるであろう。しかし、これらの実施形態は、本発明を限定されるものと解してはならず、説明と理解を目的としたものと解すべきである。
【０００６】
かかるデジタル交換をするためのデジタルデータトラッキング（tracking）方法と装置を説明する。デジタル交換にトレーサビリティ（traceablility）と透明性の標準をもたらす慣習、プロトコル、及びプロセスのセットがこれらの技術（techniques）をサポートする。かかる技術は、これらの原理に従って同時に使用するソフトウェアとシステムを作成するときに、開発者が使用できる。
本システムの一実施形態の要素としては、グローバルに一意的な識別子、ＨＴＴＰベースのデータ交換、ロギングフォーマット、同期方法、監査手続及び認証手続がある。各要素は、以下に詳細に説明し、上記のプロジェクトの実施例を例示する。
【０００７】
以下の説明では、多数の詳細事項を記載して本発明をより詳しく説明する。しかし、言うまでもなく、本発明はこれらの詳細事項がなくても実施することができる。他の場合では、詳細事項ではなくブロック図に周知の構造と機器を示すが、これは本発発明が不明瞭になることを避けるためである。
【０００８】
以下の詳細な説明の一部は、コンピュータメモリ中のデータビットに対する操作のアルゴリズムと記号による表現により表されている。これらのアルゴリズムによる説明と表現は、データ処理技術の当業者が、自分の仕事内容を他の分野の人に最も効果的に伝える手段である。ここで、また一般的に、アルゴリズムとは、所望の結果に導く自己矛盾のないステップのシーケンスである。このステップは、物理量の物理的操作を要するステップである。通常、必ずしも必要ではないが、この物理量には、記憶し、伝達し、結合し、比較し、操作できる電気的または磁気的信号の形をとる。主に一般的な使用のために、これらの信号をビット、値、要素、記号、文字、式、数字等で表すと便利な時がある。
【０００９】
しかし、これらの用語や類似の用語は適当な物理量と関連しているべきであり、これらの物理量に付された便利なラベルに過ぎないことに留意すべきである。特に断らなければ、以下の説明から明らかなように、言うまでもなく、この明細書全体において、「処理」、「算出」、「計算」、「判断」、「表示」等の用語を用いた説明は、コンピュータシステム、類似の電子的計算機器の動作やプロセスであって、コンピュータシステムのレジスタやメモリ内の物理的（電子的）量として表されたデータを操作し、コンピュータシステムメモリやレジスタ、その他の情報記憶装置、伝送機器、表示機器内の物理量として同様に表された他のデータに変換するものの動作や処理を指す。
【００１０】
本発明は、また、これらの動作を実行する装置にも関する。この装置は、必要な目的のために特に構成されたものでもよく、コンピュータ中に記憶されたコンピュータプログラムにより選択的に起動または再構成された汎用コンピュータを有していてもよい。かかるコンピュータプログラムは、コンピュータによる読み取りが可能な記憶媒体に記憶することができる。このような記憶媒体には、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク等のいかなるタイプのディスクも含まれ、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、電子的命令を格納するのに好適な、コンピュータシステムバスに結合されたいかなるタイプの媒体も含まれるが、これらに限定されるわけではない。
【００１１】
ここで説明するアルゴリズムとディスプレイは、特定のコンピュータその他の装置に本質的に関係するものではない。いろいろな汎用システムをここでの教示に従ったプログラムで用いることができるし、必要な方法ステップを実行することに特化した装置を構成しても便利である。これらのシステムに必要な構成を以下に示す。また、本発明は特定のプログラミング言語により記述されるものではない。言うまでもなく、いろいろなプログラミング言語を用いてここに説明する本発明の教示を実施できる。
【００１２】
機械読み取り可能媒体には、機械による読み取りが可能な形式で情報を記憶または伝送するいかなるメカニズムも含まれる。例えば、機械読み取り可能媒体には、読出専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）；磁気ディスク記憶媒体；光記憶媒体；フラッシュメモリデバイス；電子的、光学的、音響的その他の形式の伝送信号（例えば搬送波、赤外線信号、デジタル信号等）などが含まれる。
【００１３】
概要
コンテクスト
本技術を詳細に説明する前に、ここで使用する「コンテクスト（contexts）」の概念及びそれがいかにトレーサビリティをサポートするかを説明する。この目的のため、一実施形態では、コンテクストは２つの一意的識別子の組み合わせである。第１の識別子は１つのマシン（machine）（例えば、サーバ）を識別する。第２の識別子は１つのデジタルデータ（例えば、文書ファイル）を識別する。この２つの識別子を組み合わせて、さらに別のグローバルに一意的な「コンテクスト識別子」を生成する。
【００１４】
「コンテクストログ」はこのコンテクストに関するエントリのシーケンスである。以下に説明するように、このシーケンスはそのコンテクストの履歴として機能する。特に、コンテクストログは、デジタルファイルに適用されたステップのシーケンス、文書のバージョン履歴、文書のアクセス、いろいろなアプリケーションに関係するその他の情報を表す。換言すると、コンテクストログは、１つのデジタルデータの履歴を表す。一実施形態では、コンテクストログは、透明で、監査可能で、偽造困難または不可能な方法で格納され交換される。それゆえ、コンテクストログは紙の文書に似た特性を有し、デジタルデータのトレーサビリティの基礎となる。
【００１５】
識別子
本技術とともに使用されるいくつかの識別子をここに説明する。以下は識別子またはその一部を表すために使用される文字のリストである。
Ａ  −Ａはデジタルデータを表す。一実施形態では、Ａはデジタルファイルであるが、Ａは任意のデジタルデータまたはバイトシーケンスであってもよい。
0xA−  0xA＝ＳＨＡ１（Ａ）であり、ＨＡＳＨ（例えば、ＳＨＡ１関数）バイトストリングＡに適用したものである。いかなるハッシュ関数を使用してもよい。一実施形態では、これは４０桁の１６進数である。
＃０ｎ  −頭に０を付けて一定の長さ（例えば、２０桁）にした１０進数を表す。
【００１６】
コンテンツエントリ
任意のデジタルデータは、ｎバイトのシーケンスとして表される。一実施形態において、0xA：ｎは１つのデータの識別子として使用され、ハッシュ値が0xAであるｎバイトのシーケンスを表す。この識別子にはいくつかの利点がある。第１に、識別子をデータ自体から計算でき、グローバルに一意的であることを基本的に保証できる。これは、識別子はそれ自体が正当性を証明していることを意味し、これはデジタルデータが与えられれば、識別子を計算し、確認（verify）することができることを意味する。しかし、ここで留意すべきことは、その逆は正しくないことである。識別子に関連するデータは不変なので、この識別子を使用してキャッシング（caching）とマシン間の同期を非常に簡単かつ効率的にできる。識別子がローカル（local）のファイルリスト中にあれば、そのファイルを離れたところにあるサーバに要求する必要はない。
【００１７】
留意すべきことは、いくつかのアプリケーションでは、データの長さ（：ｎ）は省略されることである。これは、特に、基礎となるデータ自体がプライベート（private）であり、一方識別子がパブリック（public）である場合である。（ｎを知っているので、サーチする範囲を狭くできる。）：ｎが指定されようがされまいが、システムが機能するように、交換の実施をコード化すべきである。
【００１８】
属性エントリ
１つのコンテクスト（context）において、１つのデータはそれに関連する属性を有する。例えば、写真にはタイトルがある。これらの属性は名称値ペアのシーケンス、ａｔｔｒ１＝ｖａｌ１、ａｔｔｒ２＝ｖａｌ２、．．．として表される。
【００１９】
一実施形態において、0xM．0xA：ｍを用いてコンテクスト0xMのデータ0xAと関連づけられた属性のシーケンスを示す。Ｍは、ログファイルと関連付けられた識別子であり、通常はマシン名またはＩＤを含むログファイルのカノニカル（canonical）ＵＲＬである。前述の通り、0xAはコンテンツエントリＡの識別子である。
【００２０】
コンテンツエントリとは異なり、１つのコンテクストのコンテンツと関連付けられた属性は時間的に変化できる。一実施形態では、属性エントリＩＤは、そのコンテクスト中の１つのコンテンツの「最新の」属性を言う。他の実施形態では、属性エントリＩＤを用いて、そのコンテクストの属性の履歴全体を指す。
【００２１】
一実施形態では、属性識別子をティドリーウィキ（ＴｉｄｄｌｙＷｉｋｉ）ファイルのＤＩＶ  ＸＭＬ要素のＩＤ属性として使用する。その場合、Ｍは通常、ティドリーウィキと関連付けられたログが読み出されたＵＲＬであり、Ａは（個々のティドラー（tiddler）のテキストである）ＤＩＶのコンテンツである。
【００２２】
一実施形態では、コンテンツの履歴中の属性のセットを識別するために、0xM#nnn.0xA:mを使用できる。
【００２３】
ｍを省略できることにも留意せよ。これは、単に属性のセットの全体的長さを与えるヒントである。記法を明確にするため、コンテンツと属性エントリの：ｍと：ｎの長さのコンポーネントは、一般的に例では省略する。
【００２４】
チェックポイント
コンテクストはコンテンツエントリと属性エントリのシーケンスである。そのシーケンスにはいくつかのチェックポイントが含まれることが多い。一実施形態では、チェックポイントは０ｘＣＣ＃０ｎと表される。ここで、０ｘＣＣ＝ＳＨＡ１（０ｘＣ＃０ｎ−１，ＡＢＣ）である。すなわち、前のチェックポイント０ｘＣ＃ｎ−１のハッシュに先行チェックポイントと計算される新しいチェックポイント間のすべてのエントリを連結したもののハッシュである。０ｎはこのチェックポイントのインデックスである。そのインデックスはシーケンス中のすべてのチェックポイントについて単調増加する。
【００２５】
これらのチェックポイントは、以下に説明するプロセスの同期と監査のためのログファイルで主として使用される。
【００２６】
ＨＴＴＰ  ＡＰＩ
一実施形態では、デジタル交換の中核となる組み立てブロックは４つの方法である。それらの方法は、コンテンツエントリをアップロードするメカニズム、コンテンツエントリをダウンロードするメカニズム、コンテンツ属性をアップロードするメカニズム、及びコンテンツ属性をダウンロードするメカニズムである。以下、これらのプロセスをウェブクライアントとウェブサーバ間のインターラクション（interaction）として説明する。留意すべきことは、交換の状況に応じてその他の多数の実施形態が可能だということである。特に、共有記録ＡＰＩ（Shared  Records  API）は、これらの方法のＪＡＶＡ（登録商標）ベースのプログラムインターフェイスを記述する。
【００２７】
ポストコンテンツ
クライアントはＨＴＴＰ  ＰＯＳＴメソッドを使用して、ＲＦＣ１８６７で規定されたマルチパート／フォームデータエンコーディング（multipart/form-data  encoding）サーバにデジタルデータファイルを送信する。「コンテンツトランスファエンコーディング」ヘッダ（“content-transfer-encoding”  header）によりデータをデコードしてから、そのデータのＳＨＡ１ハッシュを計算する。上記の通り、この識別子はこのコンテンツを指すときに使用する。サーバは、通常、そのデータファイルを読み出すために使用できるＵＲＬの一部として、その識別子をクライアントに返す。（以下のコンテンツ取得のセクションを参照せよ。）
一実施形態では、データはローカルの記憶ディレクトリ内のファイルに記憶される。コンテンツのフィンガープリント0xAは、ＧＵＩＤとも呼ぶが、ファイル名として使用される。また、ＧＵＩＤはサーバのデータベースに記憶されてもよい。
【００２８】
一実施形態では、この時点で、サーバはそのサーバのマスターログにそのＧＵＩＤを登録し、このＧＵＩＤの新しいログを作成する（このＧＵＩＤはこのサーバに始めてのものであると仮定する）。（以下のロギングのセクションを参照せよ。）
アプリケーションに応じて動作やフィールド名はカスタマイズしてもよい。例えば、一実施形態では、「アップロード（upload）」を動作として使用し（例えば、http://server.org/upload）、「データ」をファイルのコンテンツのフィールド名として使用する。
【００２９】
他の実施形態では、ファイル名をファイルデータを含むＭＩＭＥ部のヘッダの属性として使用する。この属性（及びその他の属性）が属性エントリとしてコンテンツエントリと関連づけられる。一実施形態では、このファイル名のファイル拡張子をそのファイルのローカルに保存されたコピーの拡張子として使用する。
【００３０】
コンテンツ取得
一実施形態では、クライアントはＨＴＴＰ  ＧＥＴメソッドを用いてサーバにＧＵＩＤに関連付けられたデータを要求する。この要求のＵＲＬは通常：
http://server.org/0xA/0xA
ここで、最初の0xAはコンテンツの（記憶場所を識別するための）ＧＵＩＤであり、次の0xAは実際のデータを指す。（任意的にこのＧＵＩＤには拡張子．ｅｘｔが加えられる。）サーバは対応するデータに応答する。一実施形態では、この応答のヘッダにはそのコンテンツと関連付けられた（ＭＩＭＥタイプを含む）様々な属性が含まれる。
【００３１】
クライアントは、ダウンロードしたデータのＳＨＡ１ハッシュを計算し、識別子0xAと比較して、そのデータを確認（verify）することができる。
【００３２】
このダウンロードのパスコンポーネント（path  component）はローカルのアプリケーションに対してカスタマイズされてもよい。例えば、パスコンポーネントは次の通りである：
http://server.org/download/0xA。
しかし、既存のキャッシングメカニズムを利用しやすくするために、一実施形態では、ＧＵＩＤは、ＵＲＬのクエリ成分ではなく、パスの一部、好ましくはパスの最後の「ファイル名」部分として規定される。クエリストリングにＧＵＩＤを使用して、0xAのコンテクストに関連づけられた属性にアクセスするために、以下ではhttp://server.org/get?uid=0xAなどを使用する。0xAはグローバルで一意的なので、パス成分はデータを位置特定するには必要ない。一実施形態では、クライアントと中間サーバは要求を傍受（intercept）して、キャッシュに対応するデータがあればそれを回答する。また、一実施形態では、ＨＴＭＬ文書内のコンテンツファイルの参照は、「href=0xA」の形で行われ、ローカルの参照とグローバルの参照の間の変換の問題を避ける。
【００３３】
ポスト（Ｐｏｓｔ）属性
一実施形態では、クライアントはＨＴＴＰ  ＰＯＳＴメソッドを使用して属性をサーバに送信し、要求は２つのパラメータＵＩＤとＤＩＶＳを含み、application/x-www-form-urlencodedエンコーディングを用いて送信される。
【００３４】
例として、server.org上のファイル0xAに関連付けられたコメント「Ａコメント」をアップロードするために使用できるＵＲＬを以下に示す。
【００３５】
http://server.org/  0xA&DIVS=<div  title=’’A  Comment’’>body  of  comment</div>
この例は、ＰＯＳＴメソッドではなくＨＴＴＰ  ＧＥＴメソッドを用いて、ＨＴＴＰ要求のＵＲＬを用いて示されている。ＧＥＴメソッドでは、ＤＩＶＳパラメータがＵＲＬのクエリストリング（query  string）として含まれる。ＰＯＳＴメソッドでは、これらのパラメータはサーバに送信される要求メッセージの本文に含まれる。実際、ほとんどのウェブアプリケーションはこれら２つの要求メソッドを同一に扱い、ＵＲＬの長さの限度を超えない少量データの場合は、クライアントは一般的にクライアントは一般的にいずれのアプローチを使用することもできる。一般に、ＰＯＳＴメソッドを使用する方が安全である。
【００３６】
留意すべきことは、この例は、ティドリーウィキ（TiddlyWiki）の「ティドラー（tiddlers）」をアップロードするモデルのものだということである。共有レコードＡＰＩ（SharedRecords  API）の場合、レコードに関連付けられたメタデータのポスティングにはすこし違うフォーマットが使用されるが、基本的な考え方は同じである。
【００３７】
この場合、ＸＭＬをＤＩＶの要素のフィールド値として使用する。このＸＭＬは、個々のＤＩＶ要素により構成され、属性エントリとコンテンツエントリの両方を同時に指定することができる。コンテンツエントリはＤＩＶ要素の本文である。ＤＩＶ要素の属性の名前−値ペアは、ＵＩＤにより画成されたコンテンツのそのコンテンツエントリに関係づけられた属性である。留意すべきことは、ＨＴＴＰ要求自体の名前＝値ペアを使用して属性エントリを指定することもあることである。これは可能だが２つの問題が生じる。第１の問題は、アップロードを処理するウェブアプリケーションがそれ自体のためにＵＩＤ等の特定のフィールド名を使用していると、名前の衝突が発生する可能性があることである。第２の問題は、ほとんどのウェブアプリケーションは、ＰＯＳＴ要求のためのフィールド名を含む入力が適切なものであるか確認するように書かれていることである。フィールド名と値の範囲を不必要に制限することなくこの種の確認を正しいエントリにする必要はない。属性エントリ自体をＸＭＬとしてエンコードし、それを指定されたフィールドの値として送信すれば、これらの問題は回避できる。ちなみに、そうすると、クライアントでの処理が非常に容易にもなる。クライアントはローカルの記憶領域に記憶されたまだ解析していないＤＩＶＳだけを送信できるからである。
【００３８】
この要求を受信すると、サーバはコンテンツエントリ0xDのＧＵＩＤを計算し、関連する属性エントリである例えば0xM．0xDのＧＵＩＤを計算する。コンテンツエントリと属性エントリは、コンテクスト0xMと関連付けられたログに記憶される。
【００３９】
一実施形態では、サーバは、これらの属性エントリを受けるか否か決定しＧＥＴ  ＡＴＴＲＩＢＩＴＥＳメソッドで利用できるようにする前に、別のいくつかのチェックをする。グローバルに一意的かつ不変なコンテンツエントリとは異なり、属性エントリはサーバコンテンツに固有である。
【００４０】
チェックが無事終了すると、サーバは指定されたコンテクストに関連するサーバ上の最新のチェックポイントを返す。様々な実施形態ではチェックが無事終了した時に返すものが異なる。もっとも新しいチェックポイントを返すことにより、クライアントはそのローカルな属性シーケンスがサーバのものと一致するか否か確認できる。留意すべきことは、クライアントはチェックポイント以降、常にサーバに属性のセットを問い合わせることもできることである。これについては後でより詳しく説明する。
【００４１】
ポスト（Ｐｏｓｔ）属性コンテクスト
上記の通り、コンテクスト識別子0xMは一般的に２つの一意的識別子からできる。一実施形態では、カノニカルＵＲＬ（canonical  URL）のハッシュを、コンテクストを読み出すためにそのコンテクストの識別子として使用する。上記の例では、Ｍは次のＵＲＬのハッシュに等しい：
http://server.org/get?UID=0xA
これは、server.org上の0xAと関連する属性シーケンスを求めるＵＲＬとして機能する。以下に詳細に説明する。
【００４２】
プログラマは、Ｍを名前空間と考え、あるサーバでどの名前空間を使用するか選択するために0xAを使用する。１つのサーバは異なる多数の「名前空間（namespace）」を有してもよいし、同じ「名前空間」が異なる多数のサーバ上にあってもよい。（以下、本明細書では、0xAに対して「名前空間」ではなく「デジタルデータ」または「文書」という用語を使用する。しかし、0xAが何らかの既知のデータのハッシュに対応しなければならないとの必要性はない。このため、この識別子は正しい統語仕様（syntactic  conventions）に沿っていればいかなる文字列であってもよい。
【００４３】
ＵＲＬのハッシュをコンテクスト識別子として使用すると、クライアントが属性シーケンスの信ぴょう性を確認するために使用した他の情報が提供される。特に、以下に説明するように１組の属性を読み出すとき、一実施形態では、クライアントは要求ＵＲＬに基づいて識別子を計算し、それを要求に応答して返された属性エントリ識別子と一致するか確認する。
【００４４】
サーバは異なるコンテクストのエントリを受け取ることもできる。例えば、クライアントは、異なるコンテクストを指定するＩＤ属性をすでに有するＤＩＶをアップロードしてもよい。これをどう処理するかはサーバにより異なってもよい。サーバは、「無関係な（foreign）」コンテクスト識別子を有するその属性を、ＧＥＴ要求に応答して返す属性に含めてもよい。サーバは、かかるエントリを自機のエントリとして受けてもよいし、そのコンテクストから新しい識別子を割り当ててもよい。これについては、以下に同期とともに説明する。
【００４５】
属性取得（get  attributes）
一実施形態では、１組の属性を読み出すため、クライアントは次の形式のＵＲＬを有するＨＴＴＰ  ＧＥＴを使用する：
http://server.org/get?UID=0xA
これにより、１組の属性を含むＨＴＭＬ文書またはＸＭＬ文書が返される。ティドリーウィキ（TiddlyWiki.org）の場合、これはＪａｖａ（登録商標）Ｓｃｒｉｐｔヘッダとそれに続くＤＩＶ要素のシーケンスを含む「記憶領域」を含むティドリーウィキそのものである。一実施形態では、各ＤＩＶ要素は0xM．0xDの形のＩＤを有する。ここでＤはＤＩＶ要素の本文のハッシュである。別の実施形態では、最初の送信では本文は省略され、ＡＪＡＸスタイルのＪａｖａ（登録商標）Ｓｃｒｉｐｔ要求を用いるＧＥＴ  ＣＯＮＴＥＮＴの上記方法を用いて読み出される。これにより、大きなデータを含むティドラー（tiddlers）の効率が大幅に高くなる。
【００４６】
この応答は、サーバの現在の状態を表すチェックポイント（CHECKPOINT）識別子を含んでもよい。通常、これは記憶領域を含むＤＩＶのＩＤ要素、すなわち、0xAに関連付けられた属性に対応する１組のＤＩＶを含む要素として含まれる。
【００４７】
公開（publish）
上記の４つの方法は、クライアントとサーバ間でデータを交換するための基本的な要素である。同期と監査（auditing）に関する方法を以下に説明する。これらの方法は、サーバ間の通信及びトラッキング機能に有用である。
【００４８】
また、「草稿」情報と「公開」情報を区別することが必要な場合が多い。特に、１つのコンテクストと関連付けられたすべての属性エントリが、その情報を利用可能とする前にサーバにより登録されていることの確認をユーザまたはプロセスは欲することがある。換言すると、１組の属性の一貫性をそれが公開される前に確認することを欲することがある。
【００４９】
一実施形態では、これを実現するため、クライアントはＵＲＬの「公開（PUBLISH）」パスまたはクエリコンポーネントを有するＨＴＴＰ  ＧＥＴメソッドを使用する。例えば、
http://server.org/publish?UID=0xA&CHECKPOINT  =０xCC
は、ＵＩＤ0xAからチェックポイント０ｘＣＣまでに関連する１組のエントリを公開するようにサーバに命じる。
【００５０】
ティドリーウィキの場合、これは既知の記憶場所にある静的なＨＴＭＬファイルを公開することに対応する。記憶場所とは、例えば、：
http://server.org/  0xA/index.html
この命令が無事に実行されると、上記のＵＲＬがＨＴＭＬページの一部として読み出され、クライアントに送信される。
【００５１】
エラー
上記の通信では、要求が失敗した場合、一般的なＨＴＴＰエラーはすべてクライアントに返されてもよい。
【００５２】
しかし、一実施形態では、追加的エラー条件が使用され処理される。この追加的エラー条件には、「ＧＵＩＤミスマッチ（GUID  Mismatch）」と「無効属性エントリ（Invalid  Attribute  Entries）」エラー条件が含まれる。
【００５３】
ＧＵＩＤミスマッチ−ダウンロードしたデータのハッシュが要求された識別子にマッチしない場合、これはクライアントが処理するエラー条件を構成する。それはなりすまし（spoofing）か、または単なるデータの破損を意味する。
【００５４】
無効属性エントリ−サーバはクライアントからの属性エントリの一部または全部の受け取りを拒否する。これにより、クライアントはサーバと同期しなくなる。これはクライアントがサーバから帰されたチェックポイントを確認（verifying）するか、最新バージョンを要求することによりテストされ得る。いずれの場合にも、この条件もクライアントにより処理される。
【００５５】
ロギングファイルフォーマット（Logging  File  Format）
サーバに記憶された各コンテクストに対して、サーバはコンテクストログを持っている。一実施形態では、これは「付加のみ（append  only）」のファイルフォーマットである。
【００５６】
ログファイルフォーマット自体は３種類のアイテム、すなわちコンテンツエントリ（ContentEntries）、属性エントリ（AttributeEntries）及びチェックポイント（Checkpoints）を含む。上記の定義を用いて、ログファイルのフォーマットは以下の通りである：
コンテンツエントリ−ストリングエントリは0xA：ｎストリング（STRING）から構成される。ここでストリングはエントリのコンテンツであり、ｎはストリング中の文字（バイト）数であり、0xAはストリングのハッシュである。
【００５７】
属性エントリ−属性エントリは0xM．0xA：ｍ属性１＝値１  属性２＝値２により構成される。Ｍは属性割り当てのコンテンツと呼ばれる。Ｍは、ログファイルと関連付けられた識別子であり、通常はマシン名またはＩＤを含むログファイルのカノニカル（canonical）ＵＲＬである。上記の通り、0xAはコンテンツエントリＡの識別子であり、属性１は第１の属性のラベルであり、値１はコンテンツＭのコンテンツＡのその属性と関連付けられた値である。スペースで隔てられた属性値ペアはいくつあってもよい。ｍは属性値ペアのリスト中の全文字数であり、空白のデリミタ（delimiters）を含む。
【００５８】
チェックポイント−チェックポイントは０ｘＣＣ＃０ｎで表される。ここで、０ｘＣＣ＝ＳＨＡ１（０ｘＣ＃０ｎ−１，ＡＢＣ）である。すなわち、前のチェックポイント０ｘＣ＃ｎ−１のハッシュにそのチェックポイントと計算される新しいチェックポイント間のすべてのエントリ（例えば、ＡＢＣ）を連結したもののハッシュである。０ｎはファイル中のすべてのチックポイントに対して単調増加するチェックポイントのインデックスである。
【００５９】
一実施形態では、ログファイルは、コンテンツを表すＵＲＬそのものであるコンテンツエントリで始まる。そのＵＲＬは、すなわち、このログファイルのコンテンツを読み出すことができるカノニカルな記憶場所（canonical  location）である。ログファイルのエントリの第１の例は：
0xM:２５  http://server.org/０xABC/  ０Xcc#０００１
これは、サーバ（server.org）と名付けられたマシン上の識別子0xAＢＣ（一般的に、これはこのマシン上のコンテンツまたは「名前空間」であるデジタルデータのハッシュである）と関連付けられたログである。０ｘＣＣはストリング「0xM:２５  http://server.org/０xABC/」のハッシュである。チェックポイントはいつファイルに挿入されてもよい。一実施形態では、チェックポイントは各ポスト（POST）要求の後に挿入される。
【００６０】
留意すべきことは、この場合、0xMは、このファイル中の属性エントリに割り当てられたＧＵＩＤの一部として使用されるコンテクスト識別子に厳密に一致（corresponds）することである。
一実施形態では、属性エントリは、0xM．0xD：２９タイトル＝Ａ「コンテンツ」修正＝「２００５年１２月２２日」のようなものである。これはこのコンテンツ中の（ハッシュ値0xDを有する）コンテンツのタイトルと修正日を示す。一実施形態では、ティドリーウィキの場合、コンテンツはストリングのコメントであり、おそらく前にファイル中に現れている：
0xD：１７  コメントの本文
しかし、コンテンツがログファイル中に現れなければならないという必要性はない。コンテンツがファイルに含まれていなくても、ＧＵＩＤは属性識別子の一部として現れる。これはコンテンツが別のところに記憶された画像等の大きなファイルである場合に、特に有用である。コンテンツログファイルの一例は以下の通りである。
【００６１】
【数１】
2007293855.tif 000003
図１は、ロギングコンテンツエントリを使用するプロセスの一実施形態を示すフロー図である。図１のプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【００６２】
図１を参照して、本プロセスは、処理ロジック（processing  logic）が、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成（maintain）することにより始まる（処理ブロック１０１）。一実施形態では、１つのコンテンツエントリはストリングのハッシュとそのストリングとを有するベクトルを含む。一実施形態では、１つの属性エントリは、コンテンツエントリの識別子と、コンテンツ中のそのコンテンツエントリの属性のラベルとその属性に関連付けられた値とにより構成された１つ以上のペアとをつなげた、ログファイルと関連付けられた識別子を含むエントリを有するベクトルを有する。一実施形態では、コンテンツエントリの識別子はそのコンテンツエントリのハッシュを有し、ログファイルと関連付けられた識別子は属性割り当てのコンテクストのハッシュを含む。一実施形態では、少なくとも１つのチェックポイントは、前のチェックポイントのハッシュに、その前のチェックポイントとその少なくとも１つのチェックポイントとの間のすべてのエントリがつながったものを含む。一実施形態では、コンテクストは、第１と第２の識別子の組み合わせである。第１の識別子はマシンを識別し、第２の識別子はデジタルデータのグループを識別する。
【００６３】
そのあと、処理ロジック（processing  logic）はコンテクストログにアクセスしてそこに記憶されている情報をレビューする（処理ブロック１０２）。
【００６４】
特性
上記の通り、一実施形態では、ログファイルは、チェックポイントにより区切られたコンテンツと属性エントリのシーケンスにより構成される。一実施形態では、このファイルは「付加のみ（append  only）」である。換言すると、すべてのエントリはファイルの終わりに付加され、一旦エントリがされるとそれは変更できない。
【００６５】
図２は、コンテクストログ修正プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【００６６】
図２を参照して、本プロセスは、処理ロジック（processing  logic）が、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成（maintain）することにより始まる（処理ブロック２０１）。そのあと、処理ロジック（processing  logic）はコンテクストログにアクセスしてそこに記憶されている情報をレビューする（処理ブロック２０２）。処理ロジックは、コンテクストログの終わりに新しいエントリを付加することによりコンテンツログを修正する（処理ブロック２０３）。
【００６７】
ファイルは、そのリーダがすべてのチェックポイントを計算してログのインテグリティ（integrity）を確認できるという意味で、自己確認的（self-verifying）である。ファイルの一部が破損していても、そのファイルの残りは依然として有効である。ただし、履歴（history）は破損後の最初のチェックポイントまでしかたどれない。
【００６８】
そのファイルは非常に解析しやすい。すべての有効なエントリは、０ｘで始まり、有限数の空白を含まない文字が続く。これは識別されたラベルまたはエントリと呼ばれる。一実施形態では、チェックポイントは固定サイズであり、エントリの長さはエントリ識別子中に含まれている。改行文字がエントリとチェックポイントを分離する。これは、パーサ（parser）がエントリの実際のコンテンツをスキップできることを意味する。また、ファイルのサイズは、エントリとチェックポイントのサイズと数が分かっている場合、予想できることを意味する。
【００６９】
一実施形態では、スレッド問題（threading  issues）を回避するため、コンテクストログファイルに書き込んでいるプロセスは、ファイルに付加するとき、そのファイルをロックする。留意すべきことは、このロックは、チェックポイントを含むエントリを書き込むのに必要な限りにおいて維持されることである。ファイルに書き込む前に、本プロセスはファイルの終わりを見つけて、最後のＮバイトが有効なチェックポイントを構成することを確認する。（チェックポイントのサイズは一定であり、慣例的に、ファイルはチェックポイントで終わるので、これは簡単な動作である。）このチェックポイントは、書き込まれるログエントリの付加の最後に、付加すべき次のチェックポイントの計算に使用される。
【００７０】
拡張子（Extensions）
慣例により、コンテクストの現在のログファイルは「インデックス．ログ（index.log）」と名付けられ、0xAＢＣと名付けられたディレクトリに格納される。ここで0xAＢＣはコンテクスト識別子のＧＵＩＤコンポーネントである。言い換えると、このログファイルがデジタルファイルのイベントまたは処理のログである場合、0xAＢＣはそのファイルのハッシュである。ログファイルはいくらでも大きくなるので、コンテクストログは別のファイルにすると便利である。そうするために、現在のログファイル、例えばインデックス．ログのハッシュを計算し、インデックス．ログファイルをその値（例えば、０ｘＦＦＦがそのファイルのハッシュ値である場合、０ｘＦＦＦ．ｌｏｇ）で名前の付け替えをする。この時点では、ファイル０ｘＦＦＦ．ｌｏｇは、何らかの変化をすればファイル中のデータのハッシュ値とファイル名とが異なるので、「不変である（immutable）」と考えられる。
【００７１】
新しいｉｎｄｅｘ．ｌｏｇファイルを生成する。そのファイルの第１ラインは前のファイルに書き込まれた最後のチェックポイント（すなわち、０ｘＦＦＦ．ｌｏｇ中の最後のチェックポイント）のコピーである。次に、属性エントリが新しく生成されたｉｎｄｅｘ．ｌｏｇに書き込まれ、０ｘＦＦＦがこのログの前のバージョンであることを示す。例えば、属性エントリはは次の通りである：
0xM.０xFFF:２２_type=previous_log  file_location=０xFFF.log
この場合、プライベート情報に使用される＿ｔｙｐｅはこのコンテクストにあり、ハッシュ０ｘＦＦＦを有するコンテンツは、このコンテンツ内の前のログエントリから構成されていると識別する。また、ファイル記憶場所（file_location）はローカルマシン上のファイルを見つけるヒントとして提供される。チェックポイント数やそのログファイル中の最後のチェックポイントの追加情報を属性として提供することもできる。
【００７２】
このように、１つの大きな「仮想」コンテクストログを形成するファイルのチェーン全体を生成できる。現在のインデックス．ログファイル以外のすべてのファイルは不変なので、他のコンテンツとして取り扱うこともできる。例えば、それらのファイルを他のサーバに格納及び／またはキャッシュすることもできる。
【００７３】
マスターコンテクストファイル
一実施形態では、マスターコンテクストファイルを使用してサーバ上の重要な変更を記録する。例えば、新しいコンテンツエントリがサーバにアップロードされるたびに、及び／または新しいコンテンツログが生成されるたびに、マスターコンテンツファイルはその事実を記録するために修正される。このように、マスターコンテクストファイルはマスターログとして機能する。
【００７４】
一実施形態では、このマスターログにおいて、新しいコンテンツログが生成されるといつも新しい属性エントリが追加される。新しい属性エントリの例は次の通りである：
0xMASTER:0xM:２２  created=  “２００５/１２/２２”  data=0xA
ここで、0xMＡＳＴＥＲはサーバのマスタコンテクストであり、0xMはサーバ上のコンテクストである。この場合、データ＝0xA属性は、このコンテクストがハッシュ値0xAを有するデジタルデータと関連づけられていることを示す。任意的に、生成された属性は、いつコンテクストログファイルが最初に生成されたか示す。
【００７５】
一実施形態では、サーバのマスターコンテクストの識別子は、http://server.org/index.logのハッシュである。
【００７６】
http://server.org/index.log
すべてのコンテクストファイル、及び特にマスターコンテクストファイルは、「シークレットデータ（secret  data）」と関連づけられた属性エントリを含む。これは、サーバの秘密鍵を用いた「デジタル署名」である正確なエントリを含むか、またはサーバにのみ分かっているデータのハッシュである。コンテクストファイル中のこのシークレットデータと関連エントリを用いて、ログファイルの信ぴょう性を確認する。例えば、ログファイルのエントリの第１のエントリは：
0xM.０xS:１２  _type=seed
ここで、０ｘSはサーバにだけ分かっている秘密の「シード」のハッシュである。かかるシードはログを初期化するためにいくつ使用してもよい。この最初のログは広く伝達される。サーバは、あるログを生成したことを証明するように求められると、その秘密データを提供しシードと関連させる。同様に、ログの後ろの方のエントリは、「サインされたチェックポイント（signed  checkpoints）」である属性エントリであり得る。ファイル中の最も新しいのチェックポイントは、秘密シードの１つと連結され、属性エントリは例えば次のログに入れられる：
0xM.０xS２２:１９  _type=signed_checkpoint  seed=０xS
ここで、０ｘＳ２２は前のチェックポイントと０ｘＳで特定されるシードとの連結のハッシュである。
【００７７】
同期
コンテンツエントリ
一実施形態では、サーバはそのディスクにローカルに記憶されたコンテンツエントリのリストを持っている。これは、各ファイルはその識別子に従って記憶されている簡単なディレクトリリストの形であるか、または実際の記憶場所へのポインタを有する識別子のデータベースの形である。
（例えば、ＧＥＴ  ＣＯＮＴＥＮＴ動作を通して）あるコンテンツを求められると、サーバはこのリストをチェックして、そのリストに要求された識別子が見つかった場合、ファイル中の関連データを応答として返す。
【００７８】
離れたところにあるマシンのファイルをミラーまたはバックアップするために、サーバは、そのマシンのコンテクスト識別子のリストを取得する。これは、例えば、その離れたところにあるマシンからマスタコンテクストログを取得することにより行われる。コンテクスト識別子のリストを取得すると、サーバは、そのリストからすでにローカルに記憶されている識別子をすぐに削除できる。次に、サーバは、例えばＧＥＴ  ＣＯＮＴＥＮＴメソッドを用いて、離れたところにあるマシンから新しい識別子を要求する。
【００７９】
図３Ａは、コンテクストログ同期プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログをサーバのコンテクストログと同期させることを欲するクライアントとともに動作するサーバにより実行される。
【００８０】
図３Ａを参照して、本プロセスは、処理ロジック（processing  logic）が、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成（maintain）することにより始まる（処理ブロック３０１）。次に、処理ロジックは、コンテクストログ中のエントリに対する要求を受信し（処理ブロック３０２）、そのコンテクストログにアクセスしてそれに記憶された情報を読み出し（処理ブロック３０３）、最初のチェックポイントの後ろにあるコンテクストログのエントリを送信して要求を満たす（処理ブロック３０４）。
【００８１】
図３Ｂは、コンテクストログ同期プロセスの他の実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログをサーバのコンテクストログと同期させることを欲するクライアントとともに動作するサーバにより実行される。
【００８２】
図３Ｂを参照して、本プロセスは、処理ロジック（processing  logic）が、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成（maintain）することにより始まる（処理ブロック３１１）。次に、処理ロジックは、１つのチェックポイント以降に為されたコンテンツログのエントリに対する要求を受信し（処理ブロック３１２）、コンテクストログにアクセスしてそこに格納されている情報を見る（処理ブロック３１３）。処理ロジックは、次に、第１のチェックポイントがコンテクストログ中にあるかチェックする（処理ブロック３１４）。もしあれば、処理ロジックは、第１のチェックポイントより後ろのコンテクストログのエントリを送信して要求を満たす（処理ブロック３１５）。もしなければ、プロセスは終了する（処理ブロック３１６）。
【００８３】
図４は、コンテクストログ中のエントリの同期プロセスの他の実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログを持っているサーバとともに動作するクライアントにより実行される。
【００８４】
図４を参照して、本プロセスは、処理ロジック（processing  logic）が、チェックポイントの後にある第１のコンテクストログに含まれたエントリに対する要求を送信して始まる。第１のコンテクストログは、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有する（処理ブロック４０１）。次に、処理ロジックは、要求を満たすために、第１のチェックポイントの後にあるエントリを受信し（処理ブロック４０２）、第２のコンテクストログにこれらのエントリを加える。
【００８５】
コンテクストログ（Context  logs）
チェックポイントを使用して、別々のマシンに記憶されたログを効率的に同期できる。文書Ｘと関連づけられたログの場合、マシン＃１はＸのログ中のマシン＃２からの最新のチェックポイント（例えば、５番目のチェックポイントである０ｘＣ２＃０５）を追跡できる。マシン＃１は、そのログをマシン＃３からの新しいエントリで更新したいとき、０ｘＣ２＃０５以降のすべてのエントリを求める。新しいエントリを受信すると、マシン＃１はそれ自体のログにそれらのエントリを加える。マシン＃１がマシン＃２と厳密に同じエントリのシーケンスを有する場合、そのログとチェックポイントは文書Ｘのマシン＃２と同じである。アプリケーションに応じて、これは最も一般的な場合である。
【００８６】
一方、マシン＃１のログが＃２のログと異なる場合、マシン＃１は自分自信のログ中のマシン＃２の最新チェックポイントに対応するチェックポイントを追跡しなければならない。この場合、マシン＃２は、０ｘＣ２＃０５（マシン＃１のリストに現れないチェックポイント）以降のすべてのエントリを求めることができる。マシン＃１は、通信を追跡していた場合、それ自体のログ中の対応するチェックポイント以降のすべての新しいエントリを応答することができる。留意すべきことは、マシン＃２は、そのログにこれらのエントリの一部をすでに有しており、再度加えることはない可能性があることである。また、いずれかのマシンがハッシュテーブルにエントリのラベルを記憶していて、アイテムをログに加える前にこのテーブルをチェックするかも知れない。
マシン＃１は、マシン＃２のログの既存のチェックポイントを持たない場合、「０」を送信して、すべてのエントリの受信を希望することを示す。
【００８７】
同期手続の例
一実施形態では、クライアントは、サーバに記憶されている最新のコンテクストログと関連コンテンツのローカルなコピーを欲する場合、要求をしてコンテクストと関連づけられた現在のｉｎｄｅｘ．ｌｏｇファイルを求める。例えば、要求とそれに続いて
http://server.org/0xA/index.log
により、ｓｅｒｖｅｒ．ｏｒｇ上の0xA（例えば文書のハッシュ）と関連づけられたログが返される。クライアントはダウンロードしたファイル中の各属性エントリをチェックする。クライアントにローカルに記憶されていないデータを参照するエントリの後のエントリに対して、クライアントはＧＥＴ  ＣＯＮＴＥＮＴ要求をする。
【００８８】
効率のために、クライアントは、index.logを最も新しくダウンロードしたバージョン中の最後のチェックポイントを追跡する。新しいバージョンがダウンロードされると、チェックポイントを比較して、前のチェックポイントより後にあるアイテムだけを調べてダウンロードする。
【００８９】
カノニカルバージョン（Canonical  Version）
一実施形態では、２つの別々のマシンは、１つのコンテクストについて動作を同期させるために、第３の「カノニカル」サーバからのログエントリのシーケンスを使用することに同意する。その後、各サーバの各々により生成されたエントリはカノニカルサーバに直接または間接にポストされる。カノニカルサーバからのコンテクストログ中にあるエントリの後のエントリのシーケンスは、それらのエントリの同意された順序を決定する。かかる情報を用いて、例えば、２つの別々のサーバ上で同時に変化する文書の「オフィシャルな」履歴を決定することができる。
【００９０】
複数バージョン
一実施形態では、単一サーバのログファイルは複数のサーバからのエントリを含む。特に、これは、ログファイルがコンテンツ識別子が混ざったものを含む、すなわち、例えば、
0xM1.0xD:  title=”  Machine  M1  title”
0xM.0xCM1:  _type=”M1  Checkpoint  entry”
0xM2.0xD:  title=”  Machine  M2  title”
0xM.0xCM2:  _type=”M1  Checkpoint  entry”
…
ここで、Ｍ１とＭ２は異なるマシンの同じ「名前空間」（例えば、0xA）を指す。この場合、現在のサーバは0xDの正確なエントリを有さず、またはサーバＭ１及びＭ２の属性と関連づけられた０ｘＣＭ１と０ｘＣＭ２からのエントリの後のいずれかのエントリを使用するよう決定する。これは確認と監査のために使用できる。
【００９１】
0xM.0xD:  title=”  Machine  M１  title”
１つのサーバからの属性を読み取る（例えば、server.orgからティドリーウィキを取得する）クライアントは、そのコンテクスト（例えば、0xM．0xD）と関連づけられた属性にだけ興味を有するかも知れない。一方、クライアントは、ログは0xMと関連づけられたサーバから読み出していても、異なるコンテクストと関連づけられた属性、例えば0xM2と関連づけられたサーバからの0xM2属性にのみ関心を有しているかも知れない。
【００９２】
特性と確認（Properties  and  verification）
２つのマシンからの２つのコンテクストログがある場合、これらのログにオーバーラップしたエントリがあるか否か確認し、これらのエントリが各ログで同じ順序で現れるか確認することは非常に簡単である。
【００９３】
図５は、文書確認プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【００９４】
図５を参照して、本プロセスは、処理ロジック（processing  logic）が、コンテンツのシーケンスと、１つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成（maintain）することにより始まる（処理ブロック５０１）。次に、処理ロジックはコンテクストログのエントリの確認要求を受ける。処理ロジックはコンテクストログにアクセスして（処理ブロック５０３）、コンテクストログに格納された情報の最新の状態を確認する（処理ブロック５０４）。一実施形態では、コンテクストログに記憶された情報の現在の状態を確認する段階は、コンテクストログのエントリに基づき文書の現在の状態を確認する。
【００９５】
図６は、オーバーラップするエントリを有するログが同じ順序であるか確認するプロセスを示す。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【００９６】
図６を参照して、処理の開始において、処理ロジックが両方のログにある属性エントリの交わりを計算する（処理ブロック６０１）。次に、処理ロジックはこれらのエントリを第１のログで出てくる順序で並べる（処理ブロック６０２）。次に、第２のログを調べて、各エントリについて、処理ロジックはそのエントリがその交わりにないこと、またはそのエントリが第１のログに従って順序付けられたシーケンス中の「次の」ものであるか確認する（処理ブロック６０３）。
【００９７】
この手続をログ１のチェックポイント＃Ｃ１及びログ２のチェックポイント＃Ｃ２までのエントリに対して行うと、処理ロジックはそれ以降の比較はそれらのチェックポイント以降のもにしかやらない。留意すべきことは、チェックポイント＃Ｃ１とチェックポイント＃Ｃ２は、両方のログにある最後のエントリのすぐ前の最後のチェックポイントであることである。
【００９８】
不変なシーケンス
上記の通り、一実施形態では、ログファイルへの変更はすべてすぐに検出可能である。チェックポイントがもはや有効ではないか、前のチェックポイント（例えば、他のログに記憶されたもの）がもはやログに見つからないからである。
【００９９】
この特性を使用して、ログ間の依存関係を作る。例えば、ログ２がログ１のチェックポイント０ｘＣ１への参照を含み、ログ１がログ２の後続のチェックポイント０ｘＣ２への参照を含む場合、攻撃者は、ログ２との一貫性を保つようにログ１を修正することが不可能になる。例え攻撃者がログ１の新しいチェックポイントを作っても、ログ２中のエントリは残る。攻撃者が偽造ログ中に０ｘＣ２への参照を含めても、０ｘＣ２はもはや有効ではないログ１中のチェックポイントに基づくことが確認される。
【０１００】
それゆえ、一貫性を保つためには、攻撃者はログ２も変更しなければならない。しかし、このログは別のマシンにあり、攻撃者の知らないログのチェックポイントや秘密データのハッシュへの参照を含むから、攻撃者は有効な偽造ログを作ることができない。ログ間（特に別のマシンのログ間）の相互参照の数が増えれば、偽造ログを作れる可能性はほとんどなくなる。
【０１０１】
プライバシー
コンテクストログと関連特性がその基礎となるコンテンツエントリの知識を必要としないということを強調しておく。例えば、識別子0xAと関連づけられた実際のデータは、単一のマシンしか知らない。しかし、その識別子と関連づけられた属性は、別の多数のマシン上で設定、修正ができる。
【０１０２】
この特性により、属性（一般的にはメタデータ）へのアクセスから切り離せるデータへのアクセスをローカルで精密に（fine-grained）制御することができ、一方で監査可能性（auditability）と説明可能性（accountability）とを維持することができる。
【０１０３】
このローカルな制御により、異なる多数のアプリケーションが同じ基本システムを使用することができる。例えば、サービスリンクプロトタイプ（ServiceLink  prototype）により使用される共有記録（SharedRecord）システムにおいて、データ（例えば、テスト結果等の医療文書）は最初に暗号化されてから記憶される。これにより、データ（医療文書）へのアクセスとその文書に関連づけられたコメントその他のメタデータへのアクセスを別々に制御することができる。暗号化されたデータのハッシュは関連エントリの識別子として使用し、文書自体を復号して見るためには別の復号鍵が必要である。属性は、コメントその他のエントリとして暗号化ファイルの識別子と公開して関連づけることができ、暗号化されていてもいなくてもよく、暗号化ファイルと関連づけられたログに加えられる。さらにまた、別のセットのエントリすなわち第２のコンテクストを、同じファイルの暗号化していないバージョンと関連づけてもよい。暗号化していないデータにアクセスできる人（例えば復号鍵を有する人）は、識別子を計算して、エントリを暗号化されていないファイルと関連づけて、それらのエントリを暗号化されたバージョンの識別子と関連づけられたエントリとリンクすることができる。別のセットのコメントを同じ文書の他の暗号化バージョンであって各々が別の暗号化鍵を使用するものと関連づけることができる。このアプローチを変形して、アスリート（athletes）と関連文書へのアクセスを精密かつローカルに制御することもできる。
【０１０４】
図７は、コンテクストログデータのプライバシーを守るプロセスの一実施形態を示すフロー図である。図７のプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【０１０５】
図７を参照して、処理ロジックは最初にデータ（例えば、文書）を暗号化し、暗号化したデータの識別子（例えば、暗号化データのＳＨＡ１）を計算する（処理ブロック７０１）。処理ロジックは、次に、公開して暗号化データの識別子に属性を関連づける（処理ブロック７０２）。
【０１０６】
その後、処理ロジックは、データの暗号化されていないバージョンを用いて第２の識別子を計算する（処理ブロック７０３）。処理ロジックは、エントリのセットを暗号化されていないデータに関連づけられたこの第２の識別子と関連づけ、次に、それらのエントリを暗号化されたバージョンの識別子と関連づけられたエントリと結合またはリンクする（処理ブロック７０４）。
【０１０７】
他の場合、コンテンツはトランザクション情報を含む。個々の関係者は互いに情報を秘密にしておきたいと欲するが、第三者の監査人には事後にその情報を開示する。コンテクストログの共有バージョンがあれば、事後にそのデータを偽造したり改変することを防止できる。この場合、関係者は属性エントリのみをログに入れ、コンテンツエントリを秘密にしておくことができる。監査人は、その属性エントリが同じコンテンツエントリを指していること（エントリ中のコンテンツに対して同じフィンガープリントを使用していること）を確認できる。さらにまた、監査人は、関係者が関連するコンテンツエントリ（またはそれらのエントリの特定の一部）を作ることを要求し、これらのエントリがログ中の属性エントリに対応することを確認できる。
【０１０８】
認証
クライアント／サーバシステムでは、通常はサーバが、誰がそのサーバまたはその様々なリソースにアクセスできるかを管理する。これは、一般的にはクライアントが入力するログインＩＤとパスワードを用いて行われ、このログインＩＤとパスワードをサーバに格納されたデータベースと比較する。もちろん、ここに説明するシステムにおいては、サーバのユーザを認証及び確認するために、同種のメカニズムを使用することもできる。
【０１０９】
補足的または代替的アプローチとして、認証情報を、各コンテクストまたはマシンによらない名前空間の特定の属性エントリに格納することもできる。
例えば、現在の実施形態では、コンテクストログはタイプが「\_update\_keys」である例えば以下の属性エントリを含む：
0xM.0xK:22  title=''\_update\_keys''
サーバはこのコンテクストへのポストの認証のために、識別子０ｘＫと関連づけられたコンテンツを使用する。特に、０ｘＫはリストのハッシュであり、各々は電子メールアドレスその他のフレーズ（phrase）に対応している。クライアントは、ポスト要求をすると、プレーンテキストの電子メールアドレスまたはフレーズ、例えばowner=''wolff@ricoh.com''を含むクッキー（cookie）または属性を含める。サーバは、このフレーズのハッシュを計算し、その結果を０ｘＫ中のハッシュのリストと比較する。リスト中にあれば、ポスト要求は受け付けられる。
【０１１０】
図８は、認証プロセスの一実施形態を示すフロー図である。図８のプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスはサーバにより実行される。
【０１１１】
図８を参照して、本プロセスの開始において、処理ロジックは、各々が認証のために使用されるコンテンツ（電子メールアドレス、フレーズ等）に対応するハッシュまたはそのリストを格納する（処理ブロック８０１）。次に、処理ロジックは、認証情報（例えば、電子メールアドレス、フレーズ等）のプレーンテキストバージョンを含むポスト要求を受ける（処理ブロック８０２）。一実施形態では、認証情報のプレーンテキストバージョンは、属性に含まれてもよい。次に、処理ロジックは、要求で受け取った認証情報のハッシュを計算し（処理ブロック８０３）、それをハッシュのリストと比較する（処理ブロック８０４）。その後、処理ロジックは、認証情報のハッシュがハッシュのリストにあるかテストする（処理ブロック８０５）。あれば、処理ロジックはポスト要求を受け付け（処理ブロック８０６）、処理を終了する。なければ、処理ロジックはポスト要求を拒絶し（処理ブロック８０７）、処理を終了する。
【０１１２】
特に、このポスト要求は「_update_keys」属性エントリの新しい値を提供することに留意せよ。このように、クライアントは特定のコンテクスト内の認証をローカルで管理することができる。
新しいコンテクストログがユーザ要求により開始される時、その要求のオーナーパラメータ（owner  parameter）（または同等のクッキー）を使用して「_update_keys」の初期値をシード（seed）することができる。
【０１１３】
ＧＥＴ要求、ＰＵＢＬＩＳＨ要求にも同様の方法を使用できる。
【０１１４】
サーバポリシー（Server  Policies）
サーバによって、この種の情報をどう取り扱うかのポリシーが異なることに留意せよ。別の実施形態では、サーバは毎回新しい鍵（例えばハッシュ）が提供されることを要求する。これは、クライアントが最新の鍵のプレーンテキストであるパラメータに加えて、「次の」鍵のハッシュを提供するか、またはサーバが応答の一部としてクライアントに「次の」プレーンテキストの鍵を提供するからである。
【０１１５】
サーバは、どの属性エントリをローカルコンテクストに受け入れるかに関しても異なる。上記の通り、１つのサーバ上のコンテクストログは、同じコンテンツと関連づけられたローカルの属性エントリ（例えば、0xM．0xD：ｆｏｏ＝“ｂａｒ”と0xM１．0xD：ｆｏｏ＝“ｎｏｔｂａｒ”は同じログ中に存在し得る）とは異なる、異なるコンテクストからの属性エントリ（例えば、0xM1がリモートサーバの0xAと関連づけられている場合、0xM1．0xD）を含んでもよいサーバがどのエントリを自機のコンテクスト内にあると認めるかを管理するポリシーはサーバ毎に異なる。しかし、監査と比較のメカニズム（これはトレーサビリティの基本である）はどのサーバでも同一である。
【０１１６】
コンテンツベース認証（content  based  authentication）
秘密情報をサーバ間の認証に使用することもできる。例えば、コンテンツエントリの識別子0xAは、少数の人またはマシンだけが知っている「秘密の」フレーズまたはデータに対応する。例えば、このデータは、イントラネット上のページのＵＲＬ、電子メールの主題、またはユーザのＰＣのローカルファイルシステムに格納されたＪＰＥＧファイルである。
【０１１７】
識別子0xAが公開されていても、秘密データをエントリの認証または確認に使用できる。例えば、0xAに対応する主題ヘディングを有する特定の電子メールを受信した人だけが、0xAと関連づけられたコンテクストの属性エントリを加えられるとする。
各ユーザは、最初に、例えばコメント本文を含む通常の属性エントリを送信することにより属性エントリを「サイン（sign）」することできる。次に、次の形式の「署名（signature）」属性エントリを送ることができる：
0xM.0xDS:22  type=signature  entry=0xD
この場合、0xDSは、0xDで特定されたコンテンツが連結された秘密データのハッシュである。コンテンツ（すなわちハッシュが0xDとなるデータ）と、秘密データ（ハッシュが0xAとなるデータ）の両方にアクセスできる他のユーザまたはマシンは、0xDSが正しいハッシュであることを確認できる。これにより、中央サーバに対する信頼を必要とせずに、個々のユーザが互いのエントリを認証する方法を提供する。
【０１１８】
図９は、信頼できる中心の関係者（trusted  central  party）を用いずに他のユーザのエントリを認証するプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
【０１１９】
図９を参照して、プロセスの開始において、処理ロジックはコンテンツ（ハッシュが署名エントリになるデータ）と秘密データの両方を格納するかアクセスする（処理ブロック９０１）。その後、処理ロジックは、他のマシンから通常の属性エントリと署名属性エントリを受け取る（処理ブロック９０２）。署名属性エントリは、それにより特定されるコンテンツと関連づけられた秘密データのハッシュであるデータを含む。処理ロジックは、次に、その署名により特定されるコンテンツに連結された秘密データのハッシュを確認することにより、１つ以上の他人のエントリを認証する（処理ブロック９０３）。
【０１２０】
バージョニング（versioning）
コンテクストログの典型的な使用方法はバージョンの追跡である。例えば、0xAが次のもののハッシュに対応するとする：
http://server.org/wolff/index.html
0xAと関連づけられたログは、このファイルの後のバージョンを指すエントリのシーケンスを含む。例えば、１つのエントリは：
0xM.0xA1:22  type=contents  modified=2005/12/22
であり、その日付に、ファイルｉｎｄｅｘ．ｈｔｍｌのコンテンツが識別子0xA１を有することを示す。後で、そのファイルの新しいバージョンが上記ＵＲＬで公開される。その場合、他のエントリが次のログに含められる：
0xM.0xA2:22  type=contents  modified=2005/12/22
事実上、第２のエントリは前のエントリより優先される。このように、0xAに対応するＵＲＬにあるファイルのコンテンツのバージョン履歴が保持される。例えば、公開された記憶場所0xAとともに、前のバージョンと次のバージョンを指す0xA１と0xA２のコンテクストログを相互参照があってもよい。
【０１２１】
これらのエントリは、別の時間に別のマシンで分散されてこれらのエントリがされてもよいことに留意することは有用である。例えば、他のマシンのユーザは、ファイル0xA２をダウンロードして修正できる。そのマシンにおいて、他のエントリをしてもよい：
0xM1A2.0xA3:22  type=NewVersion  modified=2005/12/23
ここで、0xM1A2は、0xA2のマシンM1上のコンテクストログであり、0xA3は0xA2に基づく新しいデジタルファイルである。マシンＭとＭ１のログを調整するとき、元の文書0xA1の履歴を、対応するログの属性エントリを用いて0xA2から0xA3まで追跡することができる。
【０１２２】
ティドリーウィキ（TiddlyWiki）
以下は、上記のコンテクストログの例に対応するティドリーウィキｈｔｍｌファイルの記憶領域（storeArea）コンポーネントの例である。コンテクストログが同じタイトルを有する複数の属性エントリを含む場合、サーバは、そのティドラー（tiddler）の最新バージョンのみを応答してもよいことに留意せよ。また、ログが他のコンテクストからの属性エントリ（例えば、0xM．0xDではなく0xM1．0xD）を含む場合、サーバまたはクライアントは、それらのエントリを含めないこと、または0xMコンテクストに割り照られた属性がない場合にのみ含めることを決定してもよい。
【０１２３】
【数２】
2007293855.tif 000004
コンピュータシステムの実施例
図１０は、ここに記載した１つ以上の動作を実行するコンピュータシステムの例を示すブロック図である。図１０を参照して、コンピュータシステム１０００は、クライアントまたはサーバのコンピュータシステムを含む。コンピュータシステム１０００は、情報をやりとりする通信メカニズムすなわちバス１０１１と、情報を処理する、バス１０１１に結合したプロセッサ１０１２とを有する。プロセッサ１０１２は、例えばペンティアム（登録商標）プロセッサ、パワーＰＣ（商標）、アルファ（商標）等のマイクロプロセッサを含むが、マイクロプロセッサに限定されない。
【０１２４】
システム１０００は、さらに、プロセッサ１０１２により実行される情報及び命令を格納する、バス１０１１に結合したランダムアクセスメモリ（ＲＡＭ）またはその他のダイナミック記憶装置１００４（ここではメインメモリと呼ぶ）を有する。メインメモリ１００４は、プロセッサ１０１２による命令の実行中に、一時的変数やその他の中間情報を記憶するために使用される。
【０１２５】
コンピュータシステム１０００は、プロセッサ１０１２の静的情報や命令を記憶する、バス１０１１に結合した読み出し専用メモリ（ＲＯＭ）及び／またはその他の静的記憶装置１００６と、磁気ディスク、光ディスクとその対応するディスクドライブ等であるデータ記憶装置１００７とを有する。データ記憶装置１００７は、情報と命令を記憶し、バス１０１１に結合している。
【０１２６】
コンピュータシステム１０００は、コンピュータのユーザに情報を表示するための、バス１０１１に結合した、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）等のディスプレイ装置１０２１に結合している。英数字入力装置１０２２は、英数字その他のキーを含み、バス１０１１に結合され、プロセッサ１０１２に情報とコマンド選択を送る。追加的なユーザ入力装置として、マウス、トラックボール、トラックパッド、スタイラス、またはカーソル、方向キー等のカーソル制御１０２３があり、バス１０１１に結合し、プロセッサ１０１２に方向情報とコマンド選択を送り、ディスプレイ１０２１上のカーソルの動きを制御する。
【０１２７】
バス１０１１に結合した他の装置としてハードコピー装置１０２４がある。このハードコピー装置１０２４は、紙、フィルム、その他のメディア上に、命令、データ、その他の情報を印刷するために使用される。バス１０１１に結合する他の装置として、電話やハンドヘルドパームトップ装置と通信する、有線または無線の通信機能１０２５がある。
【０１２８】
システム１０００のどの構成要素もそれに関連するハードウェアも、本発明で使用してもよい。しかし、言うまでもなく、他の構成のコンピュータシステムでは、これらの構成要素の一部または全部を含んでもよい。
【０１２９】
上記の説明を読んだ当業者には本発明の変形例や修正例が明らかになったことは間違いなく、言うまでもなく、上記のどの実施形態も本発明を限定することを目的としたものではない。それゆえ、いろいろな実施形態の詳細の説明は、本発明に本質的であると考えられる特徴のみを記載した請求項の範囲を限定するものではない。
【図面の簡単な説明】
【０１３０】
【図１】ロギングコンテンツエントリを使用するプロセスの一実施形態を示すフロー図である。
【図２】コンテクストログ修正プロセスの一実施形態を示すフロー図である。
【図３Ａ】コンテクストログ同期プロセスの一実施形態を示すフロー図である。
【図３Ｂ】コンテクストログ同期プロセスの他の実施形態を示すフロー図である。
【図４】コンテクストログ中のエントリの同期プロセスの他の実施形態を示すフロー図である。
【図５】文書確認プロセスの一実施形態を示すフロー図である。
【図６】ログが同じ順序のオーバーラップするエントリを有するか確認するプロセスの一実施形態を示すフロー図である。
【図７】コンテクストログデータのプライバシーを守るプロセスの一実施形態を示すフロー図である。
【図８】認証プロセスの一実施形態を示すフロー図である。
【図９】信頼できる中心グループ（trusted  central  party）を用いずに他のユーザのエントリを認証するプロセスの一実施形態を示すフロー図である。
【図１０】コンピュータシステムの一実施形態を示すブロック図である。
【符号の説明】
【０１３１】
１００４  メインメモリ
１００６  静的メモリ
１００７  大容量メモリ
１０１１  バス
１０１２  プロセッサ
１０２０  外部ネットワークインターフェイス
１０２１  ディスプレイ
１０２２  キーボード
１０２３  カーソル制御装置
１０２４  ハードコピー装置
【図１】
2007293855.tif 000005
【図２】
2007293855.tif 000006
【図３Ａ】
2007293855.tif 000007
【図３Ｂ】
2007293855.tif 000008
【図４】
2007293855.tif 000009
【図５】
2007293855.tif 000010
【図６】
2007293855.tif 000011
【図７】
2007293855.tif 000012
【図８】
2007293855.tif 000013
【図９】
2007293855.tif 000014
【図１０】
2007293855.tif 000015