JP5030654B2 - ロギングとデータ交換同期のセキュアかつ効率的な方法 - Google Patents

ロギングとデータ交換同期のセキュアかつ効率的な方法 Download PDF

Info

Publication number
JP5030654B2
JP5030654B2 JP2007112344A JP2007112344A JP5030654B2 JP 5030654 B2 JP5030654 B2 JP 5030654B2 JP 2007112344 A JP2007112344 A JP 2007112344A JP 2007112344 A JP2007112344 A JP 2007112344A JP 5030654 B2 JP5030654 B2 JP 5030654B2
Authority
JP
Japan
Prior art keywords
log
entry
attribute
content
context
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007112344A
Other languages
English (en)
Other versions
JP2007293855A5 (ja
JP2007293855A (ja
Inventor
ジェイ ウォルフ グレゴリー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Publication of JP2007293855A publication Critical patent/JP2007293855A/ja
Publication of JP2007293855A5 publication Critical patent/JP2007293855A5/ja
Application granted granted Critical
Publication of JP5030654B2 publication Critical patent/JP5030654B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は文書処理の分野に関する。より具体的には、本発明はロギングとデータ交換同期に関する。
信頼できる共有の履歴を残すことは、地域社会における信頼の基礎である。複式会計やペーパートレール（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：１７ コメントの本文
しかし、コンテンツがログファイル中に現れなければならないという必要性はない。コンテンツがファイルに含まれていなくても、ＧＵＩＤは属性識別子の一部として現れる。これはコンテンツが別のところに記憶された画像等の大きなファイルである場合に、特に有用である。コンテンツログファイルの一例は以下の通りである。
Figure 0005030654
 図１は、ロギングコンテンツエントリを使用するプロセスの一実施形態を示すフロー図である。図１のプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。
図１を参照して、本プロセスは、処理ロジック（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コンテクストに割り照られた属性がない場合にのみ含めることを決定してもよい。
Figure 0005030654
 コンピュータシステムの実施例
図１０は、ここに記載した１つ以上の動作を実行するコンピュータシステムの例を示すブロック図である。図１０を参照して、コンピュータシステム１０００は、クライアントまたはサーバのコンピュータシステムを含む。コンピュータシステム１０００は、情報をやりとりする通信メカニズムすなわちバス１０１１と、情報を処理する、バス１０１１に結合したプロセッサ１０１２とを有する。プロセッサ１０１２は、例えばペンティアム（登録商標）プロセッサ、パワーＰＣ（商標）、アルファ（商標）等のマイクロプロセッサを含むが、マイクロプロセッサに限定されない。
システム１０００は、さらに、プロセッサ１０１２により実行される情報及び命令を格納する、バス１０１１に結合したランダムアクセスメモリ（ＲＡＭ）またはその他のダイナミック記憶装置１００４（ここではメインメモリと呼ぶ）を有する。メインメモリ１００４は、プロセッサ１０１２による命令の実行中に、一時的変数やその他の中間情報を記憶するために使用される。
コンピュータシステム１０００は、プロセッサ１０１２の静的情報や命令を記憶する、バス１０１１に結合した読み出し専用メモリ（ＲＯＭ）及び／またはその他の静的記憶装置１００６と、磁気ディスク、光ディスクとその対応するディスクドライブ等であるデータ記憶装置１００７とを有する。データ記憶装置１００７は、情報と命令を記憶し、バス１０１１に結合している。
コンピュータシステム１０００は、コンピュータのユーザに情報を表示するための、バス１０１１に結合した、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）等のディスプレイ装置１０２１に結合している。英数字入力装置１０２２は、英数字その他のキーを含み、バス１０１１に結合され、プロセッサ１０１２に情報とコマンド選択を送る。追加的なユーザ入力装置として、マウス、トラックボール、トラックパッド、スタイラス、またはカーソル、方向キー等のカーソル制御１０２３があり、バス１０１１に結合し、プロセッサ１０１２に方向情報とコマンド選択を送り、ディスプレイ１０２１上のカーソルの動きを制御する。
バス１０１１に結合した他の装置としてハードコピー装置１０２４がある。このハードコピー装置１０２４は、紙、フィルム、その他のメディア上に、命令、データ、その他の情報を印刷するために使用される。バス１０１１に結合する他の装置として、電話やハンドヘルドパームトップ装置と通信する、有線または無線の通信機能１０２５がある。
システム１０００のどの構成要素もそれに関連するハードウェアも、本発明で使用してもよい。しかし、言うまでもなく、他の構成のコンピュータシステムでは、これらの構成要素の一部または全部を含んでもよい。
上記の説明を読んだ当業者には本発明の変形例や修正例が明らかになったことは間違いなく、言うまでもなく、上記のどの実施形態も本発明を限定することを目的としたものではない。それゆえ、いろいろな実施形態の詳細の説明は、本発明に本質的であると考えられる特徴のみを記載した請求項の範囲を限定するものではない。
ロギングコンテンツエントリを使用するプロセスの一実施形態を示すフロー図である。 コンテクストログ修正プロセスの一実施形態を示すフロー図である。 コンテクストログ同期プロセスの一実施形態を示すフロー図である。 コンテクストログ同期プロセスの他の実施形態を示すフロー図である。 コンテクストログ中のエントリの同期プロセスの他の実施形態を示すフロー図である。 文書確認プロセスの一実施形態を示すフロー図である。 ログが同じ順序のオーバーラップするエントリを有するか確認するプロセスの一実施形態を示すフロー図である。 コンテクストログデータのプライバシーを守るプロセスの一実施形態を示すフロー図である。 認証プロセスの一実施形態を示すフロー図である。 信頼できる中心グループ（trusted central party）を用いずに他のユーザのエントリを認証するプロセスの一実施形態を示すフロー図である。 コンピュータシステムの一実施形態を示すブロック図である。
符号の説明
１００４ メインメモリ
１００６ 静的メモリ
１００７ 大容量メモリ
１０１１ バス
１０１２ プロセッサ
１０２０ 外部ネットワークインターフェイス
１０２１ ディスプレイ
１０２２ キーボード
１０２３ カーソル制御装置
１０２４ ハードコピー装置

Claims (6)

  1. コンピュータシステムにおける方法であって、
    保持手段が、チェックポイントにより区切られたコンテンツエントリと属性エントリとのシーケンスを含むファイルフォーマットを有する第１のログを記憶手段に保持する段階であって、前記コンテンツエントリはストリングのハッシュと前記ストリングとを有するベクトルを含み、前記属性エントリはログファイルに関連する識別子と、コンテンツエントリの識別子と、前記コンテンツエントリの属性の名称及び前記属性に関連する値のペアとを含む、保持する段階と、
    受信手段が、第１のログにデータをポストする要求を要求装置から受ける段階と、
    特定手段が、前記第１のログの記憶場所と、前記第１のログに対応する文書に関連するデジタルデータとを示す前記要求中のコンテクスト識別子に基づき前記第１のログを特定する段階と、
    生成手段が、前記要求中の前記デジタルデータに基づいて、ポストする前記データのハッシュと、前記データを表すストリングと、前記ストリング中の文字数とを含む第１のエントリを生成する段階と、
    加える手段が、前記第１のログに第１のエントリを加える段階と、
    計算手段が、ポストした前記データのハッシュを計算する段階と、
    送信手段が、前記計算したハッシュを前記要求装置に送信する段階とを有する、方法。
  2. 前記保持手段が、第１のログを１つ以上のチェックポイントにより区切られた各コンテクストと関連づけられたコンテンツ及び属性エントリのシーケンスを含むフォーマットで保持する段階と、
    検索手段が、コンテクストログにアクセスして、その内部に記憶された情報を検索する段階とをさらに含む、
    請求項１に記載の方法。
  3. コンテクストは、第１と第２の識別子の組み合わせであり、第１の識別子は前記第１のログを記憶したマシンを識別し、第２の識別子はデジタルデータのグループを識別する、
    請求項２に記載の方法。
  4. 第１のログ中のエントリに対する、チェックポイントを含む要求を受信する段階と、
    前記チェックポイントの後のエントリを送信して前記要求を満たす段階とをさらに有する、
    請求項１に記載の方法。
  5. 計算手段が、前記要求で受信したデータの一部のハッシュを計算する段階と、
    比較手段が、前記ハッシュを前記第１のログと関連づけられた識別子中の１つ以上のハッシュのリストと比較する段階と、
    受け入れ手段が、前記ハッシュが前記識別子中のハッシュのリストに現れる場合、ポスト要求を受け入れる段階とを有する、
    請求項１に記載の方法。
  6. コンピュータプログラムであって、コンピュータシステムにより実行されたとき、前記コンピュータシステムに、
    チェックポイントにより区切られたコンテンツエントリと属性エントリとのシーケンスを含むファイルフォーマットを有する第１のログを記憶手段に保持する段階であって、前記コンテンツエントリはストリングのハッシュと前記ストリングとを有するベクトルを含み、前記属性エントリはログファイルに関連する識別子と、コンテンツエントリの識別子と、前記コンテンツエントリの属性の名称及び前記属性に関連する値のペアとを含む、保持する段階と、
    第１のログにデータをポストする要求を要求装置から受ける段階と、
    前記第１のログの記憶場所と、前記第１のログに対応する文書に関連するデジタルデータとを示す前記要求中のコンテクスト識別子に基づき前記第１のログを特定する段階と、
    前記要求中の前記デジタルデータに基づいて、ポストする前記データのハッシュと、前記データを表すストリングと、前記ストリング中の文字数とを含む第１のエントリを生成する段階と、
    前記第１のログに第１のエントリを加える段階と、
    ポストした前記データのハッシュを計算する段階と、
    前記計算したハッシュを前記要求装置に送信する段階と
    を実行させる、コンピュータプログラム。
JP2007112344A 2006-04-21 2007-04-20 ロギングとデータ交換同期のセキュアかつ効率的な方法 Expired - Fee Related JP5030654B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US79396706P 2006-04-21 2006-04-21
US60/793,967 2006-04-21
US11/673,496 2007-02-09
US11/673,496 US7809685B2 (en) 2006-04-21 2007-02-09 Secure and efficient methods for logging and synchronizing data exchanges

Publications (3)

Publication Number Publication Date
JP2007293855A JP2007293855A (ja) 2007-11-08
JP2007293855A5 JP2007293855A5 (ja) 2010-02-18
JP5030654B2 true JP5030654B2 (ja) 2012-09-19

Family

ID=38267689

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007112344A Expired - Fee Related JP5030654B2 (ja) 2006-04-21 2007-04-20 ロギングとデータ交換同期のセキュアかつ効率的な方法

Country Status (3)

Country Link
US (1) US7809685B2 (ja)
EP (1) EP1847935A3 (ja)
JP (1) JP5030654B2 (ja)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8001080B2 (en) * 2006-09-12 2011-08-16 Infosys Technologies Ltd. Managing real-time execution of transactions in a network
US20080282175A1 (en) * 2007-05-07 2008-11-13 Adobe Systems Incorporated Automatically encoded, gracefully degrading panels
US8683458B2 (en) * 2007-11-30 2014-03-25 Red Hat, Inc. Automatic full install upgrade of a network appliance
US8589592B2 (en) * 2007-12-11 2013-11-19 Red Hat, Inc. Efficient object distribution
US8418164B2 (en) * 2008-05-29 2013-04-09 Red Hat, Inc. Image install of a network appliance
US20100004950A1 (en) * 2008-07-03 2010-01-07 Nokia Corporation System and method for usage of personal medical records in mobile devices
US8255373B2 (en) * 2008-10-24 2012-08-28 Microsoft Corporation Atomic multiple modification of data in a distributed storage system
US9208315B2 (en) * 2009-03-17 2015-12-08 Microsoft Corporation Identification of telemetry data
US8671265B2 (en) 2010-03-05 2014-03-11 Solidfire, Inc. Distributed data storage system providing de-duplication of data using block identifiers
ES2703767T3 (es) * 2010-03-11 2019-03-12 Rakuten Inc Método de procesamiento de información, dispositivo de procesamiento de información, programa y medio de grabación
JP5799259B2 (ja) * 2010-07-08 2015-10-21 パナソニックＩｐマネジメント株式会社 電子機器およびコンピュータプログラム
US20120143824A1 (en) * 2010-12-02 2012-06-07 Microsoft Corporation Protecting files that include editable metadata
US9824091B2 (en) 2010-12-03 2017-11-21 Microsoft Technology Licensing, Llc File system backup using change journal
US8620894B2 (en) 2010-12-21 2013-12-31 Microsoft Corporation Searching files
US8527472B2 (en) * 2011-03-29 2013-09-03 Kaseya International Limited Method and apparatus of securely processing data for file backup, de-duplication, and restoration
US8805901B1 (en) * 2011-07-19 2014-08-12 Google Inc. Geographically distributed file system
US9229818B2 (en) 2011-07-20 2016-01-05 Microsoft Technology Licensing, Llc Adaptive retention for backup data
US8825697B2 (en) * 2011-09-13 2014-09-02 Stefano Foresti Method and system to capture, share and find information and relationships
US9015857B2 (en) * 2011-11-14 2015-04-21 Wave Systems Corp. Security systems and methods for encoding and decoding digital content
US9043866B2 (en) * 2011-11-14 2015-05-26 Wave Systems Corp. Security systems and methods for encoding and decoding digital content
US9054992B2 (en) 2011-12-27 2015-06-09 Solidfire, Inc. Quality of service policy sets
US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
US9401904B1 (en) * 2012-03-15 2016-07-26 Motio, Inc. Security migration in a business intelligence environment
WO2014051558A1 (en) * 2012-09-26 2014-04-03 Empire Technology Development Llc Shared secret identification for secure communication
TW201423469A (zh) * 2012-12-03 2014-06-16 Inst Information Industry 電子數位資料匿篩裝置、方法及其電腦可讀取紀錄媒體
US9935910B2 (en) * 2012-12-21 2018-04-03 Google Llc Recipient location aware notifications in response to related posts
US9268653B2 (en) * 2014-01-17 2016-02-23 Netapp, Inc. Extent metadata update logging and checkpointing
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
US10133511B2 (en) 2014-09-12 2018-11-20 Netapp, Inc Optimized segment cleaning technique
US9836229B2 (en) 2014-11-18 2017-12-05 Netapp, Inc. N-way merge technique for updating volume metadata in a storage I/O stack
US10223372B2 (en) 2016-01-26 2019-03-05 International Business Machines Corporation Log synchronization among discrete devices in a computer system
US10929022B2 (en) 2016-04-25 2021-02-23 Netapp. Inc. Space savings reporting for storage system supporting snapshot and clones
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US11048695B2 (en) * 2017-09-12 2021-06-29 Sap Se Context-aware data commenting system
EP3750272A4 (en) 2018-02-06 2021-12-15 Nb Research Llc SYSTEM AND PROCEDURE FOR SECURING A RESOURCE
CN109472150B (zh) * 2018-10-31 2021-06-29 佛山科学技术学院 一种文件信息的设置读取方法
US11093642B2 (en) * 2019-01-03 2021-08-17 International Business Machines Corporation Push down policy enforcement
JPWO2022230153A1 (ja) * 2021-04-28 2022-11-03

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US6345288B1 (en) * 1989-08-31 2002-02-05 Onename Corporation Computer-based communication system and method using metadata defining a control-structure
US5963962A (en) * 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
JP3593366B2 (ja) * 1994-09-19 2004-11-24 株式会社日立製作所 デ−タベ−ス管理方法
US5592618A (en) * 1994-10-03 1997-01-07 International Business Machines Corporation Remote copy secondary data copy validation-audit function
EP1526472A3 (en) 1995-02-13 2006-07-26 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
AU6500596A (en) * 1995-07-20 1997-02-18 Novell, Inc. Transaction log management in a disconnectable computer and network
US5809415A (en) * 1995-12-11 1998-09-15 Unwired Planet, Inc. Method and architecture for an interactive two-way data communication network
US6308175B1 (en) 1996-04-04 2001-10-23 Lycos, Inc. Integrated collaborative/content-based filter structure employing selectively shared, content-based profile data to evaluate information entities in a massive information network
US6026379A (en) * 1996-06-17 2000-02-15 Verifone, Inc. System, method and article of manufacture for managing transactions in a high availability system
US20020046072A1 (en) 1996-06-18 2002-04-18 Toshikatsu Arai Workflow system
US5845292A (en) * 1996-12-16 1998-12-01 Lucent Technologies Inc. System and method for restoring a distributed checkpointed database
US6065018A (en) * 1998-03-04 2000-05-16 International Business Machines Corporation Synchronizing recovery log having time stamp to a remote site for disaster recovery of a primary database having related hierarchial and relational databases
US6360215B1 (en) 1998-11-03 2002-03-19 Inktomi Corporation Method and apparatus for retrieving documents based on information other than document content
US6584477B1 (en) * 1999-02-04 2003-06-24 Hewlett Packard Development Company, L.P. High speed system and method for replicating a large database at a remote location
US6574627B1 (en) * 1999-02-24 2003-06-03 Francesco Bergadano Method and apparatus for the verification of server access logs and statistics
US7278115B1 (en) 1999-06-18 2007-10-02 Microsoft Corporation Methods, apparatus and data structures for providing a user interface to objects, the user interface exploiting spatial memory and visually indicating at least one object parameter
US6546385B1 (en) 1999-08-13 2003-04-08 International Business Machines Corporation Method and apparatus for indexing and searching content in hardcopy documents
JP2001092827A (ja) * 1999-09-20 2001-04-06 Toshiba Corp データ管理装置および方法
US7134021B2 (en) * 1999-10-22 2006-11-07 Hitachi, Ltd. Method and system for recovering the validity of cryptographically signed digital data
US7287003B2 (en) * 2000-06-02 2007-10-23 Iprint.Com Integrated electronic shopping cart system and method
US6687696B2 (en) 2000-07-26 2004-02-03 Recommind Inc. System and method for personalized search, information filtering, and for generating recommendations utilizing statistical latent class models
US6615208B1 (en) 2000-09-01 2003-09-02 Telcordia Technologies, Inc. Automatic recommendation of products using latent semantic indexing of content
US8032542B2 (en) 2000-10-26 2011-10-04 Reynolds Mark L Creating, verifying, managing, and using original digital files
US7925967B2 (en) 2000-11-21 2011-04-12 Aol Inc. Metadata quality improvement
US20040030681A1 (en) 2000-11-21 2004-02-12 Shannon Paul Thurmond System and process for network site fragmented search
US6775792B2 (en) 2001-01-29 2004-08-10 Snap Appliance, Inc. Discrete mapping of parity blocks
US20020120484A1 (en) 2001-02-23 2002-08-29 International Business Machines Corporation Method and system for providing intelligent rules-based engine with heuristics for determining optimal routing and processing of business events
US7200627B2 (en) 2001-03-21 2007-04-03 Nokia Corporation Method and apparatus for generating a directory structure
US7668718B2 (en) 2001-07-17 2010-02-23 Custom Speech Usa, Inc. Synchronized pattern recognition source data processed by manual or automatic means for creation of shared speaker-dependent speech user profile
GB2395100B (en) * 2001-08-16 2005-11-23 Goldpocket Interactive Digital data monitoring and logging in an ITV system
US20030046586A1 (en) 2001-09-05 2003-03-06 Satyam Bheemarasetti Secure remote access to data between peers
US7007074B2 (en) 2001-09-10 2006-02-28 Yahoo! Inc. Targeted advertisements using time-dependent key search terms
WO2003046689A2 (en) 2001-11-21 2003-06-05 Amicas, Inc. System and methods for real-time worklist service
US20030126276A1 (en) * 2002-01-02 2003-07-03 Kime Gregory C. Automated content integrity validation for streaming data
US6965883B2 (en) 2002-02-20 2005-11-15 Nokia Corporation Charging mechanism for multicasting
US20030217008A1 (en) 2002-02-20 2003-11-20 Habegger Millard J. Electronic document tracking
KR20040032260A (ko) 2002-10-08 2004-04-17 전자부품연구원 메타데이터를 이용한 광고 디스플레이 장치 및 그 서비스방법
US7263521B2 (en) * 2002-12-10 2007-08-28 Caringo, Inc. Navigation of the content space of a document set
US20050004899A1 (en) 2003-04-29 2005-01-06 Adrian Baldwin Auditing method and service
US20040260593A1 (en) 2003-05-20 2004-12-23 Klaus Abraham-Fuchs System and user interface supporting workflow operation improvement
US7406487B1 (en) 2003-08-29 2008-07-29 Symantec Operating Corporation Method and system for performing periodic replication using a log
US8229932B2 (en) 2003-09-04 2012-07-24 Oracle International Corporation Storing XML documents efficiently in an RDBMS
CA2442796A1 (en) 2003-09-26 2005-03-26 Ibm Canada Limited - Ibm Canada Limitee Binding a workflow engine to a data model
US7203796B1 (en) * 2003-10-24 2007-04-10 Network Appliance, Inc. Method and apparatus for synchronous data mirroring
US7451167B2 (en) * 2003-10-24 2008-11-11 Network Appliance, Inc. Verification of file system log data using per-entry checksums
US7392533B2 (en) 2004-05-19 2008-06-24 Microsoft Corporation System and method for management of a componentized electronic document retrievable over a network
US20050289187A1 (en) 2004-06-29 2005-12-29 Oracle International Corporation System and method for investigating a data operation performed on a database
US7949666B2 (en) * 2004-07-09 2011-05-24 Ricoh, Ltd. Synchronizing distributed work through document logs
US8230326B2 (en) 2004-12-17 2012-07-24 International Business Machines Corporation Method for associating annotations with document families
US20060218204A1 (en) * 2005-03-25 2006-09-28 International Business Machines Corporation Log stream validation in log shipping data replication systems
US20070143356A1 (en) 2005-12-15 2007-06-21 Kleinsmith Richard A Enforcing workflow for implementing unique identification
US8095537B2 (en) * 2005-12-29 2012-01-10 Ricoh Co., Ltd. Log integrity verification
US8943332B2 (en) * 2006-10-31 2015-01-27 Hewlett-Packard Development Company, L.P. Audit-log integrity using redactable signatures

Also Published As

Publication number Publication date
US7809685B2 (en) 2010-10-05
US20070255530A1 (en) 2007-11-01
EP1847935A2 (en) 2007-10-24
JP2007293855A (ja) 2007-11-08
EP1847935A3 (en) 2010-10-27

Similar Documents

Publication Publication Date Title
JP5030654B2 (ja) ロギングとデータ交換同期のセキュアかつ効率的な方法
CN110495132B (zh) 用于在分布式网络节点内生成、上传和执行代码区块的系统和方法
US8903788B2 (en) Synchronizing distributed work through document logs
JP5103243B2 (ja) 書類画像を認証するサーバーシステム及び方法
JP2022509104A (ja) ブロックチェーンネットワークを介するデータの効率的且つセキュアな処理、アクセス、及び送信のためのシステム及び方法
US8793278B2 (en) System and method for data preservation and retrieval
CN110785760A (zh) 用于登记数字文档的方法和系统
US8887297B2 (en) Creating and validating cryptographically secured documents
US8572049B2 (en) Document authentication
JP2020526820A (ja) 分散型台帳を用いて公共のソフトウェアコンポーネント・エコシステムを管理するためのシステムおよび方法
US20090199274A1 (en) method and system for collaboration during an event
KR100697132B1 (ko) 타임 스탬프 서비스 시스템, 타임 스탬프 정보 검증 서버 장치, 및 기록 매체
US8887298B2 (en) Updating and validating documents secured cryptographically
WO2017156160A1 (en) Management of workflows
JP2012085276A (ja) 複合リソース文書上のデジタル署名
US10691834B2 (en) System and method of a privacy-preserving semi-distributed ledger
US11003653B2 (en) Method and system for secure digital documentation of subjects using hash chains
US11283595B1 (en) Systems and methods for securing cached data stored off-chain in a blockchain-based network
EP1159683A1 (en) Content certification
JP2024512068A (ja) ブロックチェーンで実行されるデータ・アプリケーションにおける改善されたシグネチャ検証方法及びシステム
Marian et al. Requirements Analysis for a System for Certifying Online Content
JP3818795B2 (ja) 電子帳票処理方法
WO2002077831A1 (en) Content certification
Schmidmaier Design and Implementation of a Decentralized Trusted Issuer Registry for Self-Sovereign Identity

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091225

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120326

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120410

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120511

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120529

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120626

R150 Certificate of patent or registration of utility model

Ref document number: 5030654

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150706

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees