JP2007183954A

JP2007183954A - ログコンテントに基づく洗練方法

Info

Publication number: JP2007183954A
Application number: JP2006351720A
Authority: JP
Inventors: Piasoru Kurt; ピアソルカート; Wolf Gregg; ウォルフグレッグ
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2005-12-29
Filing date: 2006-12-27
Publication date: 2007-07-19
Also published as: EP1804180A1

Abstract

【課題】ログのコンテントに基づいて洗練動作を実行する方法と装置を提供することである。
【解決手段】本方法は、１つ以上のメタデータエントリーのセットから別々に記憶されたデジタルオブジェクトに対応するセット中の１つ以上のメタデータエントリーを分析する段階と、メタデータエントリー中のコンテントの分析に基づいて表示する１つ以上のデジタルオブジェクトを選択する段階と、を含む。
【選択図】図１

Description

本発明は、デジタルオブジェクト配信の分野に関し、より具体的には、デジタルオブジェクトに対応した同期情報に関する。

何百万という文書が日夜やりとりされている。これらの文書をアドレッシングするために大きな労力と時間が費やされている。職場では、この大きな労力と時間の結果、コストと費用が増加してしまう。
文書と関係する典型的な問題として、分散作業の同期の問題がある。分散作業の同期には作業のアレンジメントが関係してくる。作業に文書が含まれると、かかる同期には文書に対応する情報の調整が含まれる。例えば、いくつかのパーティが文書に関するコメントを作成している時、そのコメントはより分かりやすいように、または文書をより完全な状態でレビューするように構成され、順序付けられる。

過去、多数の文書管理システムが提案され、実施されてきた。これらの文書管理システムには、文書を記憶して要求と応答との調整を処理するシステムが含まれる。しかし、これらのシステムは、組織の境界を破るものではなく、必要な同期を実行できない。

ウェブログ（web log）は情報を記録するために使用されるオンライン文書管理ツールである。ウェブログはクライアントサーバフレームワークを使用して、１つ以上のクライアントからそのウェブログをホストしているサーバにコンテントの追加と削除をさせる。１つのサーバが各ウェブログをホストするので、ウェブログは一般的には特定のＨＴＴＰロケーションにアンカーされる。

ログのコンテントに基づいて洗練動作（refining operation）を実行する方法と装置が記載されている。一実施形態では、本方法は、１つ以上のメタデータエントリーのセットから別々に記憶されたデジタルオブジェクトに対応するセット中の１つ以上のメタデータエントリーを分析する段階と、メタデータエントリー中のコンテントの分析に基づいて表示する１つ以上のデジタルオブジェクトを選択する段階と、を含む。

本発明は、以下の詳細な説明と本発明のいろいろな実施形態を示した添付図面から、よりよく理解できるであろう。しかし、これらの実施形態は、本発明を限定されるものと解してはならず、説明と理解を目的としたものと解すべきである。

デジタルオブジェクト（例えば、文書が開示されている）に対応するメタデータエントリーのセット中の情報を使用する方法と装置である。このセットはここで文書ログと呼ぶ。文書ログはメタデータのログエントリーを有する。メタデータは、ユーザまたは自動化システムにより入力された短いテキストメッセージ、２進フォーマットのデータ、及び／または任意的なリンクを有する。文書ログは配信されてもよい。一実施形態では、文書ログはＸＭＬとして配信される。

文書ログとそれに含まれる情報を使用するアプリケーションは多数ある。かかるアプリケーションは、ワークフローの検出、ワークフローの調整とトラッキング、ログコンテントを用いたデジタルオブジェクト（例えば文書）に関する知識の洗練、モバイル装置コミュニケーション等が含まれるが、これに限定されるものではない。

ウェブログのクライアント／サーバフレームワークとは異なり、文書ログの配信と処理は、ネットワークで接続されたノード（例えばユニット、装置等）の間に分散されている。プロセスは任意的にスケールすることができる。ネットワークでつながれた環境では、各ノードはログエントリーキャッシングと同期、及び他のノードとエントリーを交換する機能を最低限提供する。また、ユーザインタフェースノード（例えばクライアント）は、エントリーとその対象の文書のビューを提供し、新しいエントリー及び／またはそれからのリンクを追加するメカニズムを提供する。

一実施形態では、所与の文書ログまたはログのセットに対して、単一のノードを指定して、ログエントリーの同期を取る。この「同期」ノードの役割は、分散作業を同期させて、ノードがログエントリーを入力する順序と合うようにすることである。同期ノードはサーバであってもよい。特に、同期ノードは、各文書ログの標準的なエントリー順序を提供する。他の実施形態では、ウェブサーバを介して単一のワークグループまたはグローバルに作用することにより、かかる同期をローカルで取る。同じ同期ノードを使用するよう合意した２つのノードは、同じエントリー順序を有する。

以下の説明では、詳細に記載して本発明をより詳しく説明する。しかし、言うまでもなく、本発明はこれらの詳細がなくても実施することができる。他の場合では、詳細事項ではなくブロック図に周知の構造と機器を示すが、これは本発明が不明瞭になることを避けるためである。

以下の詳細な説明の一部は、コンピュータメモリ中のデータビットに対する操作のアルゴリズムと記号による表現により表されている。これらのアルゴリズムによる説明と表現は、データ処理技術の当業者が、自分の仕事内容を他の分野の人に最も効果的に伝える手段である。ここで、また一般的に、アルゴリズムとは、所望の結果に導く自己矛盾のないステップのシーケンスである。このステップは、物理量の物理的操作を要するステップである。通常、必ずしも必要ではないが、この物理量には、記憶し、伝達し、結合し、比較し、操作できる電気的または磁気的信号の形をとる。主に一般的な使用のために、これらの信号をビット、値、要素、記号、文字、式、数字等で表すと便利な時がある。

しかし、これらの用語や類似の用語は適当な物理量と関連しているべきであり、これらの物理量に付された便利なラベルに過ぎないことに留意すべきである。特に断らなければ、以下の説明から明らかなように、言うまでもなく、この明細書全体において、「処理」、「算出」、「計算」、「判断」、「表示」等の用語を用いた説明は、コンピュータシステム、類似の電子的計算機器の動作やプロセスであって、コンピュータシステムのレジスタやメモリ内の物理的（電子的）量として表されたデータを操作し、コンピュータシステムメモリやレジスタ、その他の情報記憶装置、伝送機器、表示機器内の物理量として同様に表された他のデータに変換するものの動作や処理を指す。

本発明は、また、これらの動作を実行する装置にも関する。この装置は、必要な目的のために特に構成されたものでもよく、コンピュータ中に記憶されたコンピュータプログラムにより選択的に起動または再構成された汎用コンピュータを有していてもよい。かかるコンピュータプログラムは、コンピュータによる読み取りが可能な記憶媒体に記憶することができる。このような記憶媒体には、例えば、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク等のディスク、読出専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、光カード、その他の電子的命令の記憶に適した媒体であってコンピュータのシステムバスに結合されたものが含まれるが、これらには限定されない。

ここで説明するアルゴリズムとディスプレイは、特定のコンピュータその他の装置に本質的に関係するものではない。いろいろな汎用システムをここでの教示に従ったプログラムで用いることができるし、必要な方法ステップを実行することに特化した装置を構成しても便利である。これらのシステムに必要な構成を以下に示す。また、本発明は特定のプログラミング言語により記述されるものではない。言うまでもなく、いろいろなプログラミング言語を用いてここに説明する本発明の教示を実施できる。

機械読み取り可能媒体には、機械により読み取り可能な形式で情報を記憶または送信するメカニズムであれば、どんなものも含まれる。例えば、機械読み取り可能媒体には、読出専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、伝搬信号（電気的・光学的・音響的その他の形式を含み、例えば搬送波・赤外線信号・デジタル信号等である）等が含まれる。

一般的な文書ログ
ログ（例えば文書ログ）は、メタデータの１つ以上のセットを有するデジタルオブジェクトにより構成される。デジタルオブジェクトは、バイトシーケンスとして表される。デジタルオブジェクトは文書でもよく、メタデータはその文書に係るコメントのセットに対応していてもよい。このように、各文書には、その文書に係るコメントのセットがある。コメントは、一般的にはテキストストリングで構成され、文書自体であってもよく、任意的なバイトストリングにより構成されていてもよい。コメントは簡単なテキストエントリーであって他の文書を参照する、誰かユーザまたは何かの装置により生成されてものであってもよい。テクニカルな論文の場合、コメントのセットはレビューした人々からのフィードバックを表す。写真（例えばＪＰＥＧファイル）の場合、コメントのセットには、誕生バーティ等のその写真に写っているイベントに関する話が含まれていてもよい。患者チャートの場合、コメントのセットには、その患者との個別のアポイントメントまたは訪問についての記載が含まれる。

（コンフリクトなしに）文書に係るコメントのリストを交換及び結合する方法をここで説明する。

一実施形態では、文書ログは、「アンカー」文書とエントリーリストを指定した簡単なＸＭＬフォーマットを用いて表される。例えば、シンプルシンジケート（ＲＳＳ）フォーマット等のフォーマットは、同じ目的に機能するように容易に適応させることができる。

一実施形態では、交換メカニズムを用いて、２つのノードがエントリーのリストを交換できるようにする。一実施形態では、ノードはＨＴＴＰＧＥＴメソッドを用いて、文書ログに対応するＸＭＬファイルを読み出し、ＨＴＴＰＰＯＳＴメソッドを用いて、ノードにＸＭＬファイルまたはエントリーを有するストリングを送る。ここでの目的のため、ＧＥＴは、ＨＴＴＰの一部で使用されようがされまいが、ロケータを関連するコンテントを読み出す動作を指す。あるいは、単純なファイルコピー動作やファイル共有システムを含むその他の交換メカニズムを使用することもできる。

ノードには、ユーザが文書ログエントリーを見て追加できるようにするユーザインターフェイスを含んでいてもよい。多数のユーザインターフェイスが文書ログを見て追加するために使用できる。ユーザインターフェイスの例を図１に示した。図１を参照して、アンカー文書１０１が右側に表示され、文書ログエントリー１０２が左側に表示されている。左下にはテキストボックス１０３があり、ユーザが新しいエントリーを入力することができる。

図１は、文書ログを見るプロトタイプのユーザインターフェイスを示している。この実施例では、文書は画像（例えば患者の画像）であって、エントリーはこの患者に関する情報に対応する。これらのエントリーは、他の文書（例えば、アポイントメントまたは処置結果等）と関連ログへのリンクを含む。このように、図１のユーザインターフェイスは、患者情報をトラッキングするための仮定的使用を容易にする。図１の右側には文書があり、この場合患者の写真である。ログエントリー１０２は、患者と関連するエントリーである。これらのエントリーの一部は、オフィススタッフ、内科医、または患者自身により手作業でタイプインされ、他のエントリーは、スケジューリングシステムや放射線画像化機等の関連システムにより自動的に生成される。文書ログ等の各エントリーでは、他の文書へのリンクがエントリーに含まれてもよい。関連文書の小さなサムネイル１０４がエントリーの右側に示されている。

一実施形態では、カーソル下の「アクティブな」コメントは魚眼効果で拡大され、単一のリスト内で多数のコメントを素早くブラウズできるようになっている。ユーザインターフェイスの一実施例で、マウスカーソル下のエントリー１０５は容易に見られるように拡大される。ここに示した実施例では、ハイライトされたエントリーは、本技術分野で周知のやり方で、機械により自動的に生成される。図示した文書ログの識別子は、この文書ログを印刷したものにあるバーコードその他のメカニズムを使用して、機械に入力してもよい。元の文書ログに自動的に入力されたアイテムには、画像化装置により自動的に生成された結果の画像が含まれてもよい。いずれかのエントリー１０２をクリックすると、そのエントリーに付随する文書ログに行く。関連文書をポイントするリンクに係わるコメントをクリックすると、文書とその参照文書に関連するログに飛ぶ。図２は、図１中のハイライトされたコメントにより参照された放射線画像に係わるログのビューを示す図である。図２を参照して、Ｘ線装置により自動的に作成された文書とその文書に関連するコメントが示されている。

場合によっては、参照された文書に関連するログは、リンクを含む元のログを逆にポイントするエントリーを有するが、多くの場合はそうではない。このプロトタイプビュアーの上部にあるナビゲーションツールは、標準的なウェブブラウザと同様の前進後退機能を提供する。

画像に加えて、文書タイプには、文書処理ファイル、フラッシュペーパー、エクセルファイル、テキスト文書、その他のタイプのデータが含まれてもよい。この現行システムでは、どのファイル（または個別にアドレス可能なユニット）を「文書」として使用することもできる。

ロケーションとしての文書
概念的には、文書ログは仮想空間すなわち（ファイルの）階層を表す。空間の原点である「ルート」ノードは文書自体により決まる。ディレクトリ名を用いて仮想空間のロケーションを指定することもできる。しかし、一実施形態では、ディレクトリ名を用いてロケーションを指定するのではなく、文書自体のハッシュ値を用いて仮想空間すなわちファイル階層上の文書とコメントのロケーションを指示する。例えば、／Ａ／Ｃは、文書（Ａ＝ＳＨＡ１（Ａ）となるａ）上のコメント（Ｃ＝ＳＨＡ１（ｃ）となるｃ）を表し、ここでＳＨＡ１は任意のバイトシーケンスを固定サイズのシーケンスにマップするハッシュ関数である。すなわち、文字Ａを用いてオブジェクトａのハッシュを示す、すなわちＡ＝ＳＨＡ１（ａ）であり、ここでＡはバイトのシーケンスを表す。例えば、ストリング「This is a character string」は（１６進表示を用いて）「97d981dad06b03622cbf8e1a5642724cbcae64f8」に写される。

この表示に関連する記憶は標準のディレクトリ構造であってもよい。例えば、Ａはディレクトリの名前であり、Ｃはａに関するコメントを含むファイルの名前である。ハッシュ値を主キーとして用いるデータベース等の他の記憶メカニズムは、同様にうまく機能し、どのノードがかかる記憶メカニズムを使用してもよい。ａの値がパスまたはユニフォームリソースロケータ（ＵＲＬ）と解釈できるストリングである混乱しやすい場合がある。a=“http://foo.com/path/to/file.ext”である場合、ｃがロケーションに関するコメントであるか、その内容が変化するウェブページに関するコメントであるか、特定の時間のそのウェブページの内容に関するコメントであるかどうかは明確ではない。後者の場合、参照ストリングのハッシュをアンカーとして使用するより、アンカー文書として（もしあれば）コンテンツのハッシュを使用する方がより安全である。

ａがストリングであり有効なＵＲＬである場合、個々のノードを選択してストリングに関するコメントと、そのＵＲＬから取得した「既知の」コンテントに関するコメントを結合する。また、慣例により、ａの文書ログはａから得られたコンテンツの各々のエントリーを、このコンテンツと関連する文書ログへのポインタとともに含む。

ここでは説明を目的として、一実施形態において、文書は１つのバイトシーケンスと同一の不変のオブジェクトであり、文書のハッシュ値はその文書を参照するために使用される。文書のバージョンが異なればハッシュ値も異なるから、異なるバージョンは異なる文書であると見なされる。（Ｄ２が文書Ｄ１の新しいバージョンである場合、変換により、文書Ｄ１のログはＤ２をポイントするエントリーを有し、Ｄ２のログはＤ１を逆にポイントするエントリーを有する。）
より具体的に、ハッシュ関数とディレクトリ構造の使用に関して、例えば、ＪＰＥＧファイル、ワード文書、ポストスクリプト文書、テキストストリング等であるauは、オブジェクトａのロケーション（例えばhttp://www.server.com/path/a.jpgまたはfile:///path/to/a.jpg等のＵＲＬ）を示す。
a=GET(a_u)
（ａはa_uを読み出した結果である。）
A_uをSHA1(GET(a_u))＝Aであるロケーションa_uの集合とする。

A_uの各要素は、デジタルオブジェクトを返すロケーション、すなわちａのストリング表示に対応している。

新しい「仮想的」ＳＨＡ１プロトコルを：SHA1://host.name/A/B/Cと定義する。これはＡ，Ｂ，Ｃの間の関係とそれに対応する値ａ，ｂ，ｃを表す。値ｂはａに関するコメント（または文書ログエントリー）であり、一方ｃはｂに関するコメントである。

いずれかのＵＲＬを用いてGET(SHA1://host.name/A/B/C)がうまくいくと、バイトストリングとしてコンテントが返される。他のプロトコルと異なり、このコンテントはｃであり、どのホストとも同一ではないが、変化しない。言い換えると、ＳＨＡ１(GET(SHA1://.../C))がｃと等しくなければエラーである。よって、ノードがｃのコピーを有する場合、そのノードはコミュニケーションをしてGET(SHA1://.../C)を返す必要はない（クライアントはSHA1(c)を計算し、結果とＣをキーとして使用するルックアップテーブルを記憶すると仮定する）。

同一の画像ファイルをいくつかの場所に置いて、同じコメントをいくつかの文書に関係づけてもよい。cがbに関するコメントであるとすると、SHA1:///A/B/CとSHA1:///B/Cの両方が有効なＵＲＬである。コメントcは文書Ｘに関するコメントであってもよい。この場合、SHA1:///X/Cも有効である。ここで有効とは、誰かまたはいずれかのプロセスが実際にｃを文書ｘとｂに関するコメントとして付け加えたことを言う。

文書ログリスト
慣例により、後続のスラッシュを用いて、文書に関連するコメントのリストを示す。一実施形態において、GET(SHA1://host.com/A/)は、文書ａに関するコメントのリストをhost.comから返す。同様に、SHA1://foo.com/A/はホストfoo.comのリストである。/A/はａに関するローカルで知られているコメントである。SHA1://host.com/A/C/は、host.comのコメントａに関するコメントのリストを指す。

Ｈ／Ａ／Ｃのルックアップを実行するアルゴリズム例は次の通りである。
ａ）Ｃのローカル記憶をチェックする（記憶内容はハッシュテーブル、データベース、ファイルディレクトリ等であってもよい）
ｂ）あれば、関連値（例えばコンテント）を求めて返す（セットＣ／がルックアップされた場合、関連セットを結果に追加して、（任意的に）Ａのローカル記憶のチェックを続ける。見つかった場合、コメントに関する関連セットを求める）。
ｃ）ハッシュ値をコメントと比較する
ｄ）いずれかのコメントがハッシュ値Ｃを有する場合、そのコメントを返す
ｅ）ドメイン名Ｈ（ＵＲＬに対応するストリングのハッシュ値であってもよい）をルックアップする
ｆ）Ａ／Ｃと伴にＧＥＴ要求をＨに送る
ｇ）結果を返す（有効なハッシュを任意的にチェックする）
ｈ）その要求を事前設定したサーバに送る（サーバはＡまたはａを求めるため前述のロケーションにあることに注意せよ）
ｉ）ＨがａＵＲＬのハッシュｈである場合、通常のＧＥＴ要求にそのＵＲＬを使用する。そのＧＥＴ要求によりａが返される
ｈ／、h.xml、またはｈの同様の標準的変形をクライアントでコメントリスト（例えばＸＭＬファイル）のサーバへの要求として使用できる。このコメントリストを用いてＣ（例えば、ｃがそのファイルのエントリーの１つである場合）を計算することができる。

クライアントはＡをｕ１とｕ２にマッピングしたリストも保持している。ｕ１はクライアントがａ（またはａに基づく情報）を取得したロケーションのセットであり、ｕ２はａ（例えばＸＭＬファイル）に関するコメントを含むロケーションである。別の実施形態では、クライアントは単にｕ２をルックアップし、関連するコメントセットを読み出し、Ｃの計算を試みる。

SHA1:及びHTTP:URLの間のマッピング
一実施形態では、クライアントはコンテントからロケーションへの独自のマッピングを定義して保持している。例えば、ｒがリコーイノベーションのホームページであるとする。この時、r_uはhttp://www.rii.ricoh.com/であり、R=“c2c0bfe479dd6da1d58ec4d0c42c5c7c10a1acfe”である（これは「Welcome to RII」のハッシュ値であり、この例では、index.html＝rの全コンテントである）。

この場合、クライアントは次のエントリーを有する内部テーブルを保持していてもよい。

ハッシュ値は同じ長さである必要はないことに留意せよ。特に、指示されたハッシュ値のビットが多ければ多いほど、その値は「安全」である。それ故、コンテントと識別子Ｉに基づいてここに説明したように、暗号キーＫを使用して文書中の情報及び／またはそのログエントリーを暗号化する場合、ＫとＩは同じアルゴリズムの出力の異なる部分であってもよく、異なるアルゴリズムの出力であってもよい。すなわち、Ｉはｘのハッシュであり、ＫはＩのハッシュである。同様に、Ｉは最初の８０ビットであり、Ｋは同じハッシュ計算値のビット８１−ビット１６０であってもよい。

Ａの文書ログを記憶し、処理し、表示し、追加するノードまたはサーバがコンテントａにアクセス必要はないことに留意せよ。しかし、サーバの場合の慣例により、例えば、文書のコンテントのキャッシュまたはコピーを実際に有するcache.comは、http://cache.com/A等の文書の要求に応答してこれらのコンテントを提供することができ、http://cache.com/A/に応答してログエントリーのリストを提供することができる。この場合、同じ文書を参照するHTTP:及びSHA1:URLのパス成分は同じであってもよい。

個別のコメントを読み出すために、クライアントはhttp://cache.com/A/Cを要求してもよい（再度、cache.comはａにアクセスしなくてもｃにアクセスして返してもよいことに留意せよ）。ｃがそのロケーションにより他の文書を指す場合（例えば、HREF=HTTP://foo.com/b.htmlでありb_u=HTTP://foo.com/b.html）、クライアントはb_u,からbを読み出し、Ｂを計算し、Ｂに関連する文書ログエントリーをGET(SHA1:///B/)を介してその位置を特定する。一実施形態では、デフォルトで、クライアントは、ランデブーポイント（同期サーバ）、ローカルキャッシュ、foo.com/b.html.xmlその他を含むいくつかの位置からのログエントリーをチェックして統合する。

もちろん、ｃは、SHA1:URL(例えばb_u=SHA1:/B)によりそのリンクを指定する。この場合は、まだbまたはb_uのＨＴＴＰバージョンを有していない場合、クライアントが実際のコンテントbをダウンロードするロケーションを特定するいくつかのメカニズムを使用する。

２つのノード間の同期
一実施形態では、個別のクライアントは、各文書のエントリーのローカルキャッシュを保持する。これらはハッシュテーブルに記憶される。ローカルキャッシュはいかなるメモリ空間でも記憶ロケーションであってもよい。一実施形態では、各ハッシュのエントリーは２つの部分からなる。第１の部分は、実際のコンテント自体及び/または（もしあれば）実際のコンテントへのポインタを含むストリングであり、第２の部分はこの文書に関するコメントに対応するハッシュ値のリストである。クライアントはエントリーリストの場所をチェックするように構成され得る。一実施形態では、デフォルトロケーションはランデブーポイントまたは同期サーバであり、定期的にチェックされる。例えば、ユーザが文書を見たときにいつもチェックされる。

クライアントが例えばＧＥＴ動作の結果である追加エントリーを取得すると、そのエントリーはローカルキャッシュに追加され（コンテントがハッシュ値と等しいことを確認するためコンシステンシーチェックをしてもよい）、エントリーのローカルリストを更新して新しいエントリーを反映する。（同期サーバから取得したシーケンス番号等の情報を用いて、このリストをプレゼンテーションのために順序づける。）
交換システムの一実施形態では、ノードが対称であることに注意する。クライアントとサーバの間の違いは、クライアントは、ＧＥＴを用いて通信を開始して、エントリーリストかリストを送るＰＯＳＴを読み出すマシンであることである。もちろん、異なるノード（特にサーバとして動作するもの）は、その設定が異なり、特に特定のノード（クライアント）からのエントリーを受け付けるかどうかについて異なる。

ノードは他のノード（他のクライアントまたはサーバ）との通信の経過を追い、「新しい」エントリーのみを他のノードに送る（ＰＯＳＴを介して、またはＧＥＴに応答して）。

別の交換プロトコルも使用することがあることにも注意する。例えば、同じ文書ログを示す２つのＸＭＬファイルのコンテントをコピーして単一のファイルに添付する。

文書ログエントリーにいくつのＸＭＬ表示を使用してもよい。

図３は、文書Ａに係わるログを表すＸＭＬファイルの例を示す図である。コンテント（「文書Ａに関する最初のコメント」）に加えて、各エントリーはそのエントリーの発信者（originator）または他のノードにより割り当てられるいくつかの属性を有する。図３において、ＳＥＱ属性はランデブーポイントサーバにより割り当てられる。このＸＭＬ文書自体は、Ａと関連する文書ログのクエリーに応答して返される。慣例として、このクエリーは、//rp.com/A/の形である。ここで、“rp.com”はランデブーポイントのホスト名である。（他のサーバ／ホストは、このリストの自機バージョンを返す。ランデブーポイントにより与えられるシーケンス番号は「カノニカル」として指定される。）エントリーのＨＲＥＦ属性は、ＨＴＭＬのアンカー¡a href=...¿<a href=…>タグのＨＲＥＦ属性と同様の他の文書へのリンクを指定する。同様に、ＳＲＣタグは、ＨＴＭＬＩＭＧタグのＳＲＣ属性と類似しており、参照される文書を表すサムネイル画像の情報源を指定する。

他の可能性として、既存の非常にシンプルなシンジケーション（ＲＳＳ）スキームを用いることである。ＲＳＳフィードのベース文書（アンカー）を特定するＲＳＳの簡単な拡張により、ここで説明した使用が可能となる。あるいは、ＲＳＳを拡張するのではなく、ＲＳＳの既存のフィールドを使用してもよい。

コメントを結合することは問題ではない。コメントはそのハッシュ値により記憶されているからである。（テキスト）値に加えて、例えば、著者と日付をハッシュ値Ｃの計算に使用してもよい。

図４は、文書のランデブーポイントにエントリーを送るクライアントの設定を示す図である。図４を参照して、クライアントからランデブーポイントへのエントリーの提出を示す概略図を示した。いくつかのクライアントはランデブーポイントに直接エントリーをＰＯＳＴし、他のクライアントは中間ノードを介している。エントリーをそのハッシュ値により指示し、記憶しているので、いずれのノードもコンフリクトを心配せずに他のノードと直接エントリーを交換することができる。個々のノードは自分自信の順序付けをエントリーのシーケンスに割り当てることもできる。ランデブーポイントにより提供されるオーダリングは、慣例的に、カノニカルオーダリングとして扱われる。文書の元の作者は、最初の要素の¡doc..¿ルートまたはｒｐ属性を指示することにより、その文書に関連するログエントリーのランデブーポイントまたは「ルート」を指示してもよい。しかし、文書ログは誰が作成してもよく、文書の作者に限定されないことに注意せよ。（文書の作成者は文書の最初のログエントリーを登録する最初の機会を有している。）他のノードは、文書要素中に指定されたルート属性を使用してもしなくてもよい。文書エントリーは、オフラインで作成して、そのエントリーを１つ以上のサービスと自動的に同期する。

ランデブーポイントから見えるエントリーの順序は、実際にそれが作成された順序とは異なるかもしれない（特に、作成時にクライアントがオフラインである場合）。また、中間ノードは他の複数のノードからのエントリーを集積して、提出（submit）する。

ランデブーポイントのサーバ側では、一実施形態では、シーケンス番号は受け取った順序で割り当てられる。ユーザ識別子（例えば、ポスティング権能）設定と確認は、幾つかある方法のどれかで処理することができる。これには、ユーザ名とパスワードの確認、ＩＰアドレスのテスト、セッション識別子等が含まれる。暗号化コンテントの場合、ユーザは暗号化キーＡ（及び／またはコンテントａ）を実際に知っていることを（暗号方法により）証明しなければならないとしてもよい。

ランデブーポイントとグローバル同期
上記の通り、上記のノードの構成は、分散化されたスケーラブルなピアツーピア構成での文書ログの交換においてよく機能する。コメントは、オフラインまたはオンラインで作成して、ローカルの交換を通じて解決され得る。

しかし、大きな問題が生じるのは、複数のクライアント間で作業の調整を試みる時である。クライアントは頻繁にエントリーの順序付けすなわちシーケンスについて合意する必要がある。同時に作成されたりコミュニケーションの時差があるので、エントリーをユニークに順序付けることは不可能であるかも知れない。それよりむしろ、各ノードが独自の順序付けをしてもよい。

一実施形態では、ランデブーポイント（ＲＰ．ｎｅｔ）（ＲＰ．ｎｅｔは実際のドメイン名ではなく、単なる例として使用しているに過ぎない）としてここで参照したウェブサービスは、文書ログのグローバルな順序付けを提供するものである。POST(http://RP.net/A/C)等のＰＯＳＴ要求に応答して、ＲＰ．ｎｅｔは文書ａとの関連でコメントｃにシーケンス番号を割り当てる。ＧＥＴ要求に応答して、ＲＰ．ｎｅｔはGET(http://RP.net/A/)に対して既知のコメントのリストを返し、各コメントのシーケンス番号を指定する。

ルートドメイン名サーバ以外のサーバがＤＮＳ機能を提供できるのと同じやり方で、一実施形態では、ＲＰ．ｎｅｔ以外のサーバはシーケンス番号を提供することができる。しかし、パートナーはシーケンス番号を割り当てるカノニカルサービスとして単一のサービスを使用することに同意する。一実施形態では、その権能は他のサービスに以上されるが、責任はＲＰ．ｎｅｔの組織に残る。

このように、サーバはメタデータ（コメント等）とデジタルオブジェクト（コメントがなされた文書等）に関係するハッシュその他の値等である識別子とを受け取り、一実施形態では、サーバがそのメタデータエントリーにシーケンス番号を割り当てて、更新されたシーケンス番号のリストと関連するメタデータエントリーとを公開する。サーバは、エントリーのコンテントかエントリーのコンテントに基づいて計算した識別子かのいずれかを公開することができる。また、一実施形態では、サーバは公開するリストにデジタルサインをする。これには暗号キーの使用が含まれる。

図５は、同期プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図５を参照して、プロセスの開始では、処理ロジックがデジタルオブジェクトに対応するセットを参照する第１のユニークな識別子を受け取る（処理ブロック５０１）。一実施形態では、第１のユニークな識別子はデジタルオブジェクトのコンテントに基づいて計算される。一実施形態では、第１のユニークな識別子はハッシュ値であり、このハッシュ値は、デジタルオブジェクトと関連する任意のバイトシーケンスを固定サイズのシーケンスにマッピングするハッシュ関数を適用した結果である。あるいは、ハッシュ値はデジタルオブジェクトのコンテントにハッシュ関数を適用した結果である。

デジタルオブジェクトを第１のユニークな識別子によりインデックスしてもよいことに注意せよ。

処理ロジックは第１と第２のメタデータエントリーも受け取る（処理ブロック５０２）。第１と第２のメタデータエントリーの情報源は異なってもよい。

第１と第２のメタデータエントリーを受け取った後、処理ロジックはその第１と第２のメタデータエントリーをセットに追加する（処理ブロック５０３）。

一旦追加すると、処理ロジックは、第１と第２のメタデータエントリーをそれぞれ参照する第２と第３のユニーク識別子へのアクセスを提供する（処理ブロック５０４）。第２と第３のユニークな識別子は第１と第２のメタデータエントリーのコンテントにそれぞれ基づく。一実施形態では、第２と第３のユニーク識別子はハッシュ値である。一実施形態では、第２と第３のユニークな識別子は第１と第２のメタデータエントリーのコンテントにそれぞれ基づくハッシュ値を計算した結果である。

一実施形態では、第２と第３のユニーク識別子へのアクセスを提供する段階は、第２と第３のユニーク識別子のカノニカルな順序付けを送る段階を有する。他の実施形態では、第２と第３のユニーク識別子へのアクセスを提供する段階は、第２と第３のユニーク識別子に関連するシーケンス番号を送る段階を有する。ここで、各シーケンス番号は第２と第３のユニーク識別子の１つだけと関連する。コンテントに基づき計算された識別子を送らずに、コンテント自体を送ることもできる。

一実施形態では、ここに説明したように、プロセスは、第１と第２のメタデータエントリーをカノニカルに順序付ける段階（処理ブロック５０５）と、シーケンス番号を生成（及び送信）する段階（処理ブロック５０６）とを更に有する。

一実施形態では、第１と第２のユニークな識別子をインデックスとして用いて第１と第２のメタデータにアクセスする段階をさらに含む。一実施形態では、インデックスはハッシュ値である。

図６は、データプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図６を参照して、プロセスの開始では、処理ロジックがデジタルオブジェクトに対応するセットを参照する第１のユニークな識別子を送る（処理ブロック６０１）。

処理ロジックは、次に、セット中の各メタデータエントリーのシーケンス番号とユニーク識別子のペアを受け取る（処理ブロック６０２）。一実施形態では、ペア中のユニーク識別子はハッシュ値である。

一実施形態では、プロセスは、さらに、他のパーティから１つ以上の追加エントリーを受け取る段階（処理ブロック６０３）と、追加エントリーのユニーク識別子を生成する段階（処理ブロック６０４）と、生成されたユニーク識別子を受け取ったユニーク識別子と比較して、１つ以上の追加エントリーとセット中のその他のエントリーの間の順序を特定する段階（処理ブロック６０５）と、を更に有する。

一実施形態では、処理は、セット中のユニーク識別子間の第１のユニーク識別子の一時的ロケーションを特定する段階をさらに含む。

不正開封防止ログ
不正開封防止ログは、「チェックポイントハッシュ」により分離されたメタデータエントリーのシーケンスである。シーケンスは文書オブジェクト識別子（文書オブジェクトのハッシュ）で始まる。これはチェックポイントハッシュ＃０である。

一実施形態では、チェックポイントハッシュ＃ｎは、ＳＨＡ１(#n-1,entry_n)を計算することにより構成される。ここで、＃ｎは前のチェックポイントハッシュであり、エントリー＿ｎはｎ番目のエントリーである。＃ｎ−１とエントリー＿ｎは、ハッシュ関数に順次入力され、更新されたチェックポイントハッシュが計算され、シーケンスに追加される。

任意的に、チェックポイントハッシュは位置情報（例えば、#abc:123）を含む。ここで、ａｂｃはハッシュ値を表し、１２３はｎ（例えば、１２３番目のエントリー）に対応する。あるいは、１２３は、ファイル中の現在のバイト位置に対応する。これにより、対応するチェックポイントハッシュを与えるファイル中のエントリーを非常に効率的に見つける（locate）することができる。

文書ログのアプリケーション
文書のコンテントのみでなく、文書ログ中に格納された情報を使用するアプリケーションがある。こうしたアプリケーションのいくつかを以下に示す。

ログデータの分析によるワークフロー検出
文書ログの一アプリケーションは、文書ログ中の情報を用いてワークフローを検出するものである。一実施形態では、分析方法を文書ログのコンテントに適用する。

ワークフローには多数のタイプがある。かかるワークフローの一例はオーダー処理である。他のワークフローには、登録申し込みフォーム、医療記録／照会、文書イメージとその関連謄本などが含まれる。

図７Ａは、ワークフローの例を示す図である。図７Ａを参照して、コピー機７２０がそのメモリに格納されたオーダーをする。オーダー７１０のハードコピーも示してある。電子メールサーバ７３０とファックス機７５０もそのオーダーに関する情報を含む。同期サーバ７６０は、オーダー７１０に対応するログエントリーをすべて同期する。電子メールリーダ等のクライアント装置７４０は、同期サーバ７６０にアクセスして、オーダ７１０に対応する文書ログを取得する。クライアント装置７４０は、そのコンテントに基づいて文書識別子を計算することにより、オーダ７１０に対応する文書ログにアクセスし、同期サーバー７６０に文書識別子を送る。同期サーバ７６０は、文書７１０に対応する文書ログにアクセスする。

クライアント装置７４０は、文書ログにテキスト分析を実行して、単語及び／またはログ中に単語が現れる順序に基づき、クライアント装置７４０はそのオーダ７１０が正しいものであることを確認することができる。

図７Ｂは、ワークフロー情報の処理プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図７Ｂを参照して、このプロセスの開始において、処理ロジックがデジタルオブジェクトの電子フォームにアクセスする（処理ブロック７０１）。一実施形態では、デジタルオブジェクトは文書である。

次に、処理ロジックは、デジタルオブジェクトの電子フォームのコンテントに基づいて、識別子を計算する（処理ブロック７０２）。上で説明したように、識別子はハッシュ値を有してもよい。

識別子を計算した後、処理ロジックは、デジタルオブジェクトに対応するメタデータエントリーのセットのメタデータエントリーを読み出す（処理ブロック７０３）。一実施形態では、メタデータエントリーのセットは、デジタルオブジェクトと関連するがこのデジタルオブジェクトとは別に格納された文書ログを有する。

メタデータエントリーを一旦読み出すと、処理ロジックは、メタデータエントリーを分析し（処理ブロック７０４）、メタデータエントリーの分析に基づいてワークフローを検出する（処理ブロック７０５）。一実施形態では、処理ロジックは、ログエントリー中のパターンを分析の一部として特定し、特定されたパターンに基づきワークフローを検出する。パターンは、ログデータに表れたワークフローと関連する１つ以上の単語のセットを含んでもよい。パターンは、ログデータ中のワークフローと関連するオーダー中の単語のセットを含んでもよい。かかる場合、単語のセットがオーダー中にあることは、そのワークフローを示す。一実施形態では、分析は、パターンマッチングを実行してワークフローを特定することを含む。

その後、処理ロジックはワークフローを検出したのに応じて１つ以上の動作を実行する。一実施形態では、かかる動作は追加エントリーのログへの挿入である。他の動作は、エントリーのバックアップの実行と、データベースへのアイテムの追加と読み出しその他の動作が含む。その他の動作には、メモリロケーションへの情報の記憶、電子メールの送信、ａ）ＤＣＥ、ｂ）ＨＴＴＰ、ｃ）ＨＴＴＰＳ、ｄ）ＣＯＲＢＡ等を介した遠隔手続きコールの実行、テキストメッセージの送信、電話コールの開始、機械的装置のトリガー、文書の印刷、及び／またはファックスの送信等を含む。

別の実施形態では、分析には異なる文書のログ中のデータの分析が含まれる。例えば、エントリー中のパターンは、文書Ａ、Ｂ、Ｃと関連付けられ、Ｄと関連付けられそうなセクションを推論する。その後、処理ロジックは、異なる文書にわたって繰り返されるパターンに基づきワークフローを検出する。
かかる場合、ワークフローはすべての文書と関連付けられるか、１つの文書と関連するワークフローを特定するために複数の文書を見ることができる。例えば、多数の医療記録が１つの入院と関連づけられていることを検出した場合である。多数の記録が入院を参照していることだけから、その入院を検出することができる。

ワークフロー特定の簡単な例は、いくつかの文書について繰り返す著者の順次パターンに気がつくことである。例えば、購入リクエストの許可は、アリス、ボブ、チャーリーによるルーチンエントリーにより構成されているかも知れない。システムは、アリスとボブが文書にエントリーをしたのを検出して、自動的にその文書をチャーリーに提示（または提示の申し出）をするかも知れない。

レガシーワークフローの調整とトラッキング
文書ログとその関連メタデータを用いて、レガシーワークフローを調整し追跡してもよい。これを用いて、すでにオーダー処理をする（か、他のワークフローを実行する）ように配置された、大きな既存のシステムを見えるようにする。一実施形態では、これはワークフローの部分を実行した結果を記録する様々な機能を実行するチェックポイントコードを構成要素（例えばクライアント、サーバ等）に挿入することにより実行される。例えば、チェックポイントコードを挿入して、文書識別子を計算し、ログエントリーをポストしてもよい。文書識別子は、既存の構成要素とやりとりされるデータに基づき計算され得る。ワークフローの処理段階と関連する結果を文書ログに加えたメタデータエントリーとしてポストするチェックポイントコードを挿入してもよい。

図７Ａの構成は上記のチェックポイントコードを含んでもよい。例えば、コピー機７２０、電子メールサーバ７３０、ファックス機７５０は、実行するワークフローの異なる部分に対応する文書ログ中のログエントリーのデータを送り返すチェックポイントコードを、含んでいてもよい。例えば、オーダーをコピーした時はいつも、コピー機７２０で実行されているチェックポイントコードは同期サーバ７６０にそのオーダーの電子コピーを送る。電子メールサーバ７３０は、オーダーが出荷された時、クライアント７４０に電子メールを送る。電子メールサーバ７３０上のチェックポイントコードは、その電子メールのコピーを同期サーバ７６０に送り、オーダーが出荷されたことを記録する。一実施形態では、ハッシュの計算は、電子メールのコンテントと画像中のバーコードのスキャン及び／または読みとに基づくことに注意せよ。これらのバーコードは、印刷されたオブジェクトに対応するデータの識別子を含む。

図８は、ワークフロー情報の処理プロセスの別の実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図８を参照して、プロセスの開始は、処理ロジックが様々な処理段階でワークフロー中にチェックポイントソフトウェアコードを挿入する（処理ブロック８０１）ことによる。ワークフローは２つ以上の処理段階を有し、各処理段階には１つ以上の処理動作が含まれる。一実施形態では、１つの処理段階が新しいオブジェクトを生成する場合、古いオブジェクトと新しいオブジェクトの両方にエントリーがなされる。チェックポイントコードの実行により、処理段階の処理動作に対応するメタデータエントリーが追加される。

チェックポイントコードを用意して、処理ロジックはワークフローを実行する（処理ブロック８０２）。２つ以上の処理動作の各々について、処理ロジックは、識別子を計算し、各処理動作に対応する少なくとも１つのメタデータエントリーを、デジタルオブジェクト（例えばワークフローを表す文書）に対応するメタデータエントリーのセット（例えば文書ログ）に追加する。一実施形態では、識別子は各処理動作または段階に入力または出力されるデータに基づいて計算する。

ログコンテントに基づく改良（refining）
一実施形態では、分析方法を文書ログのコンテントに適用する。そうすることにより、ログエントリー中のメタデータを用いてデジタルオブジェクト（例えば文書）に関する追加データを確かめる。第１に、文書に関連した文書ログのコンテントを用いて、その文書のトピックをより正確に理解する。第２に、文書ログに格納された情報を用いて、関心のありそうな関連するデジタルオブジェクトを表示する。

一実施形態では、文書ログ中の情報の分析結果に基づいて、文書にインデックスをつける。例えば、テキスト検索エンジンは文書ログ中の単語の出現にインデックスし、そのインデックスに検索を実行することができる。かかるサーチは、用語のブール組み合わせを用いて実行される。

他の実施形態では、文書ログ中の情報の分析結果に基づいて文書を検索してもよい。これは、結果がコンテントに基づく文書サーチエンジンには特に有用であり、特に文書の検索にコンテント間の関係を使用する文書サーチエンジンに有用である。言い換えると、分析結果はサーチエンジンの動作をサポートするために使用できるメタデータである。
より具体的に、サーチを明確にし、目標とするリファレンス（後述する）を作成するために文書ログに含まれる情報は貴重である。例えば、ある文書で、コンテントを分析して最も頻繁に出現し区別しやすい単語が「shell」、「sound」、「mix」である場合、その文書はプログラミングに関する文書であるとの結論が出るかも知れない。例えば、その文書は、サウンドミキシングシステム上のオーディオ入力チャネルを管理するシェルスクリプトを説明しているかも知れない。しかし、これと同一の文書に文書ログが添付され、アルゴリズムに関する有名な著作の著者であるＤｏｎａｌｄＫｎｕｔｈからのコメントを含む場合を考える。追加情報に基づいて、その文書は多数のコンピュータプログラムで使用されている標準的なソートアルゴリズムであるシェルソート（shell sort）に関するとの結論が出そうである。よって、「mix」という単語は、最初オーディオ処理中の技術用語であると考えられたが、Ｋｎｕｔｈにより彼のアルゴリズムを説明するために使用された「ＭＩＸ」アセンブリ言語を指すだろうと見られる。文書ログに含まれる情報は、文書とトピックを他のものから明確にするのに役立つ状況情報が豊富である。

一実施形態では、サーチは、ここで開示した方法をサポートするブラウザページを用いて実行してもよい。一実施形態では、かかるブラウザページは文書識別子を特定するボックスを含む。文書識別子に基づいて文書ログにアクセスする。文書ログを用いて、文書ログのコンテント自体、及び／または関連文書による文書ログのコンテントの分析に基づいて、コンテントサーチをする。結果が返され、ブラウザページに表示される。一実施形態では、ユーザが文書識別子に入れて文書を検索することができるインターフェイスを使用する。別のリンクやユーザインターフェイスオプションがディスプレイ上で利用でき、ユーザは任意的に文書と関係してサーチを実行することができる。

以下は、ログエントリーに含まれる情報の例である：エントリーの著者、エントリーコメント、エントリータイプ、及びエントリー共有。エントリー著者は、特定の著者は特定の主題に関してより権威があり、自分の関心トピック領域に関してコメントすることが多いから、有用である。エントリーコンテントは、ログエントリーは文書が使用される状況に関して非常に啓発的であることが多いから、有用である。上記の例では、コメントに単語「order」、「comparison」、「log」があることが、その文書がソーティングアルゴリズムに関する強い証拠であった。エントリータイプは、上記の例では、既知の標準に従うエントリーがいくつかある場合、著作が何らかの標準化団体に関連するかどうか、または学術論文であるかどうか判断するから、有用である。エントリー共有は、共有されるエントリーは通常貴重なメタデータを含むから、有用である。共有エントリーは、（同じエントリーなので同じハッシュを有するが）異なる２つのログに現れるエントリーである。エントリーがよく知られた文書（例えば、The Art of Computer Programming-Volume3）とあまり知られていない文書（例えば、A Modified Shell）の間で共有されている場合、あまり知られていない文書のトピック的つながりを推測することができる。

一実施形態では、ログエントリー中の情報を用いて、或る目的のために関連文書の関連性を計算する。関連性は関連性尺度の形であってもよい。情報には、ログエントリー、ログエントリー著者、ログエントリーのタイプ等が含まれるが、これに限定はされない。メタデータ中の重複する単語は、関連性の例である。標準のＴＦＩＤＦ（Term Frequency
Inverse Document Frequency）テキスト関連性計算器を用いて関連性を決定してもよい。

関連性を計算して、関連文書がサーチクエリと関連するか決定してもよい。サーチクエリの場合、文書が関連性を有するか決定する従来の方法は、文書自体のコンテントにフォーカスするものである。しかし、文書中の各エントリーのメタデータ中のコンテントを用いて、文書の主題に関する追加情報を取得してもよい。よって、サーチクエリが生成されると、文書ログ中の情報を評価して、その文書がサーチに関連するか判断し、関連する場合、その文書をサーチクエリの結果として返す。

一例として、文書ログのメタデータエントリー中に格納されたコメントは、計算された関連性尺度に基づくコメントランキングを受け取ってもよい。

セット中のメンバーを調べて、他のセットメンバーと比較して関連性をチェックすることができる。関連文書は同じ情報源、同じキーワードを含む文書、その他により生成された文書を含んでもよい。一実施形態では、文書のグループ化は関係していると見なすことができる。どのセットのコメントも、「バージョン」エントリー、「著者」、「タイプ」その他の属性のものであっても、セットに集めるために使用できる。

図９は、文書の関連性を判断するプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図９を参照して、プロセスは、処理ロジックがアクセスされ表示されるデジタルオブジェクトに基づいて識別子を決定する段階（処理ブロック９０１）で始まる。上記の通り、識別子はデジタルオブジェクト（例えば文書）のコンテントに基づく。識別子を用いて、処理ロジックは、その識別子に基づきセット（例えば文書ログ）のメタデータエントリー（例えばログエントリー）を取得する。

メタデータエントリーを取得した後、処理ロジックは、メタデータエントリーとは別に記憶されているデジタルオブジェクト（例えば文書）に対応する１つ以上のメタデータエントリーを分析する（処理ブロック９０３）。一実施形態では、処理ロジックは、１つ以上のメタデータエントリーにテキスト分析を実行することにより、メタデータエントリーを分析する。テキスト分析は、単語タイプ、エントリー著者、エントリーがされた時間、エントリー共有、及びエントリータイプに基づき実行してもよい。これらはすべてメタデータ中の識別子であり得る。

テキスト分析を実行する時、処理ロジックはテキストの特徴が異なれば異なるウェイトを適用してもよい。例えば、ログエントリーの著者は、ログエントリーのタイプよりウェイトが高くても、その逆であってもよい。これは、１つ以上のメタデータエントリー中のコメントの既知の著者を１つ以上のメタデータエントリー中のコメントの未知の著者よりも多かれ少なかれ関係があるとしてウェイトをかけることを含む。例えば、処理ロジックは、同じデジタルオブジェクトをより関連性があるとしてコメントする著者にウェイトをかける。また、著者に関して、ウェイトは同じ文書にどのパーティがコメントしたかに基づくものでもよい。例えば、９０通の文書とその文書にコメントした人が３人（Ｐ１、Ｐ２、及びＰ３）とがいると仮定しよう。Ｐ１とＰ２の両方が９０通の文書すべてにコメントし、Ｐ２とＰ３の両方が３通の文書だけにコメントした場合、Ｐ１とＰ２の間の距離は１／９０であり、Ｐ２とＰ３の間の距離は１／３である。それゆえ、Ｐ１とＰ２は、Ｐ２とＰ３より近い。このことにより、だれがコメントをしたかに基づきコメントのウェイトを修正することができる。

メタデータエントリーを分析した後、処理ロジックは、メタデータエントリー中のコンテントに基づきデジタルオブジェクトに関する知識を洗練する（処理ブロック９０４）。一実施形態では、処理ロジックは、メタデータを分析してデジタルオブジェクトのトピックを識別する。

洗練されたデジタルオブジェクトの知識に基づき、処理ロジックは動作する（処理ロジック９０５）。一実施形態では、処理ロジックは、洗練されたデジタルオブジェクトの知識に基づき、所定目的のためにデジタルオブジェクトの関連性を決定する。

一実施形態では、処理ロジックは、文書ログのメタデータエントリーのコンテント自体に基づいて、または文書からのコンテントを用いて文書の主題を決定する。

上記の通り、文書ログに格納された情報を用いて、関心のありそうな関連するデジタルオブジェクトを表示する。これによりディスプレイが適応的（adaptive）になる。目的のリファレンス、またはより正確なサーチ結果を作ることを創造することは容易である。潜在的なトピックスに関するより多くの情報が得られるからである。一実施形態では、洗練された文書に関する知識がその関連性を分析して得られた後、文書の表示（サーチ結果ページを含む）を他の文書へのリファレンスで注釈をつけてもよい。決定された関連性により、デジタルオブジェクトに関連するコメントが自動的に検索され表示される点で、表示は適応的である。

表示を適応させる方法はいくつかある。一実施形態では、文書の集まりに対して、サムネイル（その他の画像）のサイズは、その文書に関連する文書ログ中に格納されたコメントの数に依存する。あるいは、サムネイルのサイズは、文書ログ中のコメントの著者、ログエントリー間のつながりの密度等に依存してもよい。

図１０は、文書ログ中のメタデータエントリーからの情報に基づくディスプレイ適応処理の一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図１０を参照して、処理ブロック１００１、１００２、１００３、１００４は、それぞれ図９の処理ブロック９０１、９０２、９０３、９０４と同じである。

洗練されたデジタルオブジェクトの知識に基づいて、処理ロジックは、デジタルオブジェクトの洗練された知識に基づいて、目的のために、デジタルオブジェクトの関連性を決定する（処理ブロック１００５）。決定された関連性に基づいて、処理ロジックは表示を変更する（処理ブロック１００６）。一実施形態では、処理ロジックは、決定された関連性に基づいて、デジタルオブジェクトがサーチクエリと関連することを示すことにより、表示を変更する。一実施形態では、処理ロジックは、デジタルオブジェクトが、閾値より上の１つ以上のメタデータに関連することを示す。例えば、同じ文書へのコメント数がその関連性を示してもよい。

他の実施形態では、処理ロジックは、サーチクエリへのサーチ結果の表示の一部として、デジタルオブジェクトを表示することにより、表示を修正する。

さらに別の実施形態では、処理ロジックは、メタデータエントリー中のコンテントに基づいて表示する情報を選択してもよい。処理ロジックは、１つ以上の基準に基づき、１つ以上のサムネイル画像の表示を変更することにより、表示する情報を選択してもよい。表示の変更には、１つ以上のサムネイル画像のクラスター化と、１つ以上のサムネイル画像のサムネイルサイズの変更が含まれる。一実施形態では、基準は、メタデータエントリー中のコメント数及び／または１つ以上のメタデータエントリー中のクロスリファレンスの数に基づく。クロスリファレンスは、ＵＲＬまたはハッシュ識別子のいずれかによる、他の文書へのリンクである。一実施形態では、クロスリファレンスにより共有エントリーが参照される。あるいは、エントリー内のＩＤへの言及はクロスリファレンスを構成する。

一実施形態では、処理ロジックはデジタルオブジェクトを表示し、そのサイズはコメントの数に基づいて決まる。コメント数がある閾値に達した場合、ディスプレイ中のデジタルオブジェクトのサイズが調整される。例えば、処理ロジックは、ログ中のコメント数が閾値より下であれば、文書（デジタルオブジェクト）を１つのサイズで表示してもよく、ログ中のコメント数が閾値より上であれば、その１つのサイズより大きいサイズで表示してもよい。

広告
ログエントリー自体のコンテントを用いて、または文書のコンテントを用いて文書のトピックに関して取得した知識を用いて、目的とする広告を選択及び表示してもよい。サーチエンジン企業は、この方法を広告の選択に使用してもよい。そのような構成を図１１Ａに示した。図１１Ａを参照して、クライアント１１１０はディスプレイ１１１１と記憶装置１１１２を含む。ディスプレイ１１１１は文書１１１３を表示する。一実施形態では、文書１１１３はサーバ１１３０から提供されたものである。別の実施形態では、文書１１１３は他の装置により提供される。広告エンジン１１２０は、文書１１１３と関連する文書識別子を用いて、文書１１１３に対応するログエントリーにアクセスし、これらのログエントリーを分析して、文書１１１３が表示されている間に、ディスプレイ１１１１の他の部分に何の広告を入れるべきか決定する。このように、広告エンジン１１２０は、文書１１１３に関係するログエントリーに関連したコメントを分析する。広告エンジン１１２０は、コメント著者のＩＤと見た者（viewer）のＩＤを分析してもよい。かかるＩＤはサーバ１１３０とＩＤ記憶装置１１３２に記憶される。一実施形態では、広告エンジン１１２０からクライアント１１１０へのデータには、文書と（任意的に）そのログエントリーが含まれ、これらのデータはサーバ１１３０のデータ１１３３からのものである。広告エンジン１１２０は、これらのデータを分析して、それに広告を付加する。同期ユニット１１３１は、ディスプレイ１１１１上で使用するために、広告（ＡＤ）１１１４を文書１１１３と同期させる。

一実施形態では、この方法を使用するため、文書が表示されている時、その識別子を自動的に計算し、その識別子をインデックスとして使用してログエントリーにアクセスする。広告スペース尺度をログエントリー中の情報に基づいて計算してもよい。その尺度に基づいて、広告を選択し表示する。このように、ログエントリーからの情報で広告を選択し、（見る者とログエントリーの著者、動作等の間の関係を含む）文書のコンテクストに表示する。

図１１Ｂは、文書ログ中のメタデータエントリーからの情報に基づき選択され表示される広告をディスプレイに含めるプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図１１Ｂを参照して、処理ブロック１１０１、１１０２、１１０３、１１０４は、それぞれ図９の処理ブロック９０１、９０２、９０３、９０４と同じである。デジタルオブジェクトの洗練された知識に基づき、処理ロジックは、メタデータエントリーのコンテントに基づき、１つ以上の広告を選択し、送信し、表示する。一実施形態では、広告の選択は、１つ以上のメタデータエントリー中の１人以上のコメント著者に関連する１つ以上の識別子に基づく。別の実施形態では、広告の選択は１つ以上のメタデータエントリー中のコメントを見た者に関連する識別子に基づく。広告は文書自体のコンテントに基づいてもよい。

ログコンテントの分析に基づくリファレンス（分析を含む）の提供
ログ中の情報を用いて、トピックをあまり理解せずに、ありそうなリファレンスを作成してもよい。これは、文書を見るときに、文書ブラウザディスプレイが関連材料を提供するのに有用である。

この方法の有用性を示す例としては、次のものがあるが、これらに限定はされない。第１に、この方法を用いて、同じ著者によるコメントを有する文書または共通コメントを有する文書を取得してもよい。また、この方法を用いて、現在表示されている文書に関するコメントをした著者による文書を見つける。これは、権威のある情報源からの文書を探す貴重な援助となるであろう。

著者ではなく、ログ中のエントリーから他のメタデータ情報を取得してもよい。例えば、文書ログのエントリー時間を他のログデータと組み合わせて使用してもよい。より具体的に、エントリー時間が１ヶ月以内になされた著者によるコメントは、特定の著者のバイアスまたはコメントがなされた状況に関する貴重な洞察を与えるであろう。

ログエントリー中の情報のさらに別の使用は、文書タイプが探している特定の文書タイプとマッチするログエントリーを特定するものである。例えば、費用レポートシステムを用いて領収書をサーチする場合、この方法を用いて所定の文書セット中のすべての領収書を集めることができる。文書コンテントは領収書ごとに違っても、購買スタッフによる認証エントリーを含むからである。

この種のサーチは、文書自体の実際のコンテントとはほとんど関係がない。これらは、ブラウザや、関係素材を探すサーチエンジンに有用である。

図１２は、ログエントリー中のメタデータの分析に基づき、デジタルオブジェクトを参照するプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図１２を参照して、プロセスは、処理ロジックがアクセスされ表示されるデジタルオブジェクトに基づいて識別子を決定する段階（処理ブロック１２０１）で始まる。上記の通り、識別子はデジタルオブジェクト（例えば文書）のコンテントに基づく。識別子を用いて、処理ロジックは、その識別子に基づきセット（例えば文書ログ）のメタデータエントリー（例えばログエントリー）を取得する（処理ブロック１２０２）。

メタデータエントリーを取得した後、処理ロジックは、デジタルオブジェクト（例えば文書）に対応するメタデータエントリーを分析する（処理ブロック１２０３）。上記の通り、メタデータエントリーはデジタルオブジェクトとは別に格納される。

一実施形態では、処理ロジックは、文書の関連性を決定することによりメタデータエントリー中のデータを分析する。一実施形態では、処理ロジックは、セット中の１つ以上のメタデータエントリー中のコンテント中のキーワードをサーチすることにより、関連性を決定する。あるいは、関連性は、セット中の１つ以上のメタデータエントリー中のコンテントに基づいてもよい。関連性は、セット中の１つ以上のメタデータエントリー中のコンテントに基づく関連性尺度を計算することにより決定されてもよい。これらの関連性尺度は、ＴＦＩＤＦ（term frequency and inverse document frequency）を含んでもよい。

一実施形態では、処理ロジックは、１つ以上のメタデータエントリーにテキスト分析を実行することにより、メタデータエントリーを分析する。テキスト分析は、単語タイプ、エントリー著者、エントリーがされた時間、エントリー共有、及びエントリータイプに基づき実行してもよい。これらはすべてメタデータ中の識別子であり得る。テキスト分析を実行する時、処理ロジックはテキストの特徴が異なれば異なるウェイトを適用してもよい。

メタデータエントリーを分析した後、処理ロジックは、メタデータエントリー中のコンテントの分析に基づき他のデータへのリファレンスを提供する（処理ブロック９０４）。リファレンスは実行された分析（例えば、関連性尺度、キーワード分析等）に基づき特定されたデジタルオブジェクトに対するもの、及び／またはそのデジタルオブジェクトに関連する他のメタデータに対するものであってもよい。一実施形態では、処理ロジックは、現在表示されている文書に関するコメントをした１人以上の著者のデジタルオブジェクトを特定してもよい。かかる場合、処理ロジックは、特定されたデジタルオブジェクトに関する情報を表示することにより、メタデータエントリー中のコンテントの分析に基づいて、他のデータへのリファレンスを提供してもよい。一実施形態では、情報は特定された各デジタルオブジェクトへのリンクを含む。別の実施形態では、情報は、特定された各デジタルオブジェクトに対応するサムネイル（またはその他のタイプの）画像を含む。

常にオン／常に更新されている
ここで説明する付お方は、携帯電話やパーソナルデジタルアシスタント（ＰＤＡ）等のモバイル装置で利用してもよい。これらの装置は文書中のメタデータにアクセスし、更新されたエントリーや新しいエントリーを含むメタデータエントリーのデータを受け取る。

図１３Ａは、サーバから情報を受けるモバイル装置を有する構成を示す図である。図１３Ａを参照して、モバイル装置１３２０は、マシンコードリーダ（例えばバーコードリーダ１３２１）を用いて紙文書１３１０から文書ＩＤをスキャンし、文書識別子を計算する。モバイル装置１３２０は、無線トランシーバ１３２５を用いて、文書ＩＤをサーバに送る。これに応じて、サーバは、コメント及び／またはその他のログエントリーのメタデータをモバイル装置１３２０に送る。モバイル装置１３２０は、無線トランシーバ１３２５を用いてこれらを受け取る。これらはメモリ１３２２に格納される。（メモリ１３２２は、モバイル装置１３２０の動作を制御する命令を記憶してもよい。）モバイル装置１３２０は、ディスプレイ１３２３上に最新のコメント（例えば、文書ログの新しいバージョン）を自動的に示す。一実施形態では、モバイル装置１３２０は、関連した文書ログを受け取り、オフラインで見るようにキャッシュに最新のコメントを記憶する。

モバイル装置１３２０で取られたノートは、文書ログにポスティングされる。コメントがされたときにオフラインであった場合、モバイル装置１３２０は、再び接続されるまで、そのコメントをローカルでキャッシュする。文書の新しいバージョンを生成すると、新しいハッシュ識別子が生成される。システムは、新しい識別子へのリンクを含む古い識別子のログにエントリーを自動的に追加することができ、その逆もできる。この場合、１つのバージョンへのリンクは、その文書ＩＤで前のバージョンを参照するログエントリーである。かかるバージョンは、編集された、または印刷されただけのバージョンであってもよい。モバイル装置１３２０の動作はプロセッサ１３２４により制御される。

図１３Ｂは、ログエントリーの管理プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図１３Ｂを参照して、このプロセスは、処理ロジックが文書の文書識別子を取得する（処理ブロック１３０１）ことにより始まる。一実施形態では、処理ロジックは、紙に印刷された文書から機械読み取り可能コード（例えばバーコード）をスキャンすることにより、文書識別子を取得する。他の実施形態では、処理ロジックは、１つ以上の文書識別子のリストから文書識別子を選択することにより、文書識別子を取得する。

文書識別子を取得した後、処理ロジックは、文書識別子に基づいて、サーバからメタデータエントリーのセットを検索する。一実施形態では、メタデータエントリーは、文書に対応する情報（例えばコメント）を有し、一旦メタデータエントリーを取得すると、処理ロジックはメタデータエントリーからの情報を表示する（処理ブロック１３０３）。

任意的に、処理ロジックは、サーバに定期的に問い合わせて、メタデータエントリーのセットの更新された情報を受け取る。一実施形態では、ユーザが加入者である場合にのみ、サーバへの定期的な問い合わせを行う。加入者からの要求があったときに問い合わせが行われ、ログ中のメタデータエントリーから情報の供給を受ける。

任意的に、処理ロジックは、オフラインの間（例えば、情報を受け取るネットワークにアクセスしていない間）、ログに追加すべき追加情報を格納し、オンラインに戻ったときに（例えば、後でネットワークにアクセスした時に）、セットに追加するために、追加情報を更新させる（処理ブロック１３０５）。

文書識別子を解きコンテントを取得する
ここに説明する方法を用いて、文書識別子をデジタルオブジェクト（例えば文書）と結合してもよい。すなわち、既存の文書識別子と複数のデジタルオブジェクトがある場合、文書の各々の文書識別子を計算することにより、文書識別子と結合した文書を特定することができる。そして、既存の文書識別子と、生成した文書識別子の１つをマッチさせる。マッチングの結果に基づいて、その既存の識別子と対応するデジタルオブジェクトを特定する。

図１４は、受け取った文書識別子に応じたデジタルオブジェクトを決定するプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア（例えば回路、専用ロジック等）、（汎用コンピュータシステムまたは専用機上で実行される）ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。

図１４を参照して、プロセスは、処理ロジックが複数の文書にハッシュをかけて、文書の各々の文書識別子を決定する（処理ブロック１４０１）ことにより始まる。次に、処理ロジックは、文書の生成された文書識別子を所定の文書識別子と比較して、どの文書が所定の文書識別子と対応するか決定する（処理ブロック１４０２）。

文書間の参照
ユーザインターフェイスを用いて文書間の参照をする。一実施形態では、ログ生成ページをこの目的に使用する。ログ生成ページを用いて、ドロップダウンメニューを用いてコンテントを取得するか、コンテントのＩＤを計算するときに取得されたコンテントをサーチする。画面の一部には、コンテントのプレビューが示され、他の部分はログエントリーをする場所である。文書がそれに結合した既存のログを有する場合、他の文書ログがその文書（文書ログ自体の場合もある）を参照してもよい。これにより、両方に参照を入力することができる。文書への他のレファレンスが文書ログに追加されたときはいつも、それぞれの文書ログの両方にレファレンスを自動的に入れる。このように、互いにポインティングしている２つのログに同時に追加されるエントリーがある。例えば、コマンドラインコピーツールを用いてファイルをあるロケーションにコピーした場合、コピーが実行されると、コマンドラインコピーツールはそのディレクトリのファイル名のＩＤとしてハッシュを用いて、自動的にエントリーを入れる。そして、各ディレクトリに各ファイルのログを置き、そのファイルのコピーをこの他のロケーションに移動したことを示す。

また、新しいファイルに関連する名前とＩＤだけでなく反復ファイルのコンテントにもこのことを示す。これは、コンテントの他のバージョンを生成するために複数のリンクを自動的に追加する点で、上で説明した従来のワークフローアプリケーションと同様である。

エントリーがサーバーにポスティングされたとき、ユーザはコメントの基礎であるデジタルオブジェクトを示し、デジタルオブジェクトのＵＲＬをサーバに与える。サーバは他のサーバにコンタクトして、ユーザがＵＲＬと関連したデジタルオブジェクトにコメントをしていることを示す。サーバー間通信を用いて、２つの文書のログに２つのエントリーをし、そのログを通常通り複写する。

コンテントを登録するため、コンテントのコピーを取得し、そのＵＲＬを計算して送る。ファイルシステムは、リネームまたはムーブ動作に応じて、ローカルキャッシュを使用して現在の文書ファイル名を識別子にマッピングする。ムーブ（またはファイルにその他の動作）を実行する前に、そのファイルの識別子のハッシュを計算して、現在のリストされたバージョンと比較する。異なれば、エントリーを新しいバージョンとしてログに加える。それに何らかの動作が実行された場合、文書に実行された動作を示す他のエントリーを追加する。これは、ＵＲＬまたは文書識別子を指示するのではなく、ウェブブラウザにより行われる。

ログインテグリティ検証システム
一実施形態では、システムはログエントリーのインテグリティを検証する。これは、重要なトランザクションレコードを格納するためにログを使用する場合に価値がある。例えば、小切手とチェックレジスタのデポジットの順序は、当座貸越が合ったかどうか決定する上で非常に重要である。

文書ログは、一方向のハッシュ関数を用いることにより、順序とコンテントを検証することができる。ログが最初に生成されたとき、大きな乱数ｒｎを選択する。この数は、第１のエントリーとともに、ログ中に明らかなテキスト情報として格納される。ＳＨＡ１、ＭＤ５等の一方向ハッシュ関数等を用いて、ログエントリーｅと乱数ｒｎの連結したコンテントのハッシュを作る。この新しい値は、ここではエントリーのチェックハッシュと呼ぶ。

新しいエントリーがされるたびに、前のエントリーのチェックハッシュをエントリーのコンテントに連結して、新しいチェックハッシュを上記と同じハッシュ関数を用いて生成する。このように、各ログエントリーは、すべての先行エントリー（前のエントリーのチェックハッシュ）のコンテントとそれ自体のコンテントとの両方から容易に検証できる方法で求められる数を含む。ベース文書がログエントリーであるログエントリーは、親エントリーのチェックハッシュを用いて自分自身のコンテントを生成する。

これらのチェックハッシュはログエントリーコンテントには依存せず、文書コンテントハッシュの計算には使用すべきではないことに注意せよ。

これらのチェックハッシュは、順次コンテントの検証には有用であるが、エントリーを単に変更することによりログを修正でき、後続のすべてのエントリーのチェックハッシュを再計算できることは、当業者には明らかである。しかし、いかなる所与のログであっても他のログのコンテントと、同時に見られるチェックハッシュとを記録できるエントリーを記憶できることも明らかである。

例えば、２つのログａとｂを考える。各々は、そのチェックハッシュを用いて、コンテントとシーケンスについて検証可能である。攻撃者がログｂのアイテム２を改変しようとしていると仮定する。攻撃者はエントリーを修正し、新しいログエントリーの適当なチェックハッシュを再計算する。そして、ログｂの後続のすべてのエントリーについて、このプロセスを繰り返す。今、ログｂが変更されるが、チェックハッシュを調べてもその変更を検出できない。

しかし、ログａ中のエントリーがログｂのエントリー（ｂ中のエントリーのシーケンス番号とログｂ中のそのエントリーのチェックハッシュとを含む）を参照している場合、攻撃者には新しい問題が生じる。彼は、検出を逃れるには、ログａも変更しなければならない。これは、上記と同じ方法を用いて可能である。

多数のログがあり、上記の通り他のログのチェックハッシュを参照している場合を考える。攻撃者は、すべてのログを見つける方法は有さず、攻撃しているログを参照するアクセスは有さない場合、攻撃者には検出を避けるためにすべての必要なログをうまく改変することは不可能であることが分かるであろう。

コンピュータシステムの実施例
図１５は、ここに記載した１つ以上の動作を実行するコンピュータシステムの例を示すブロック図である。図１５を参照して、コンピュータシステム１５００は、クライアントまたはサーバのコンピュータシステムを含む。コンピュータシステム１５００は、情報をやりとりする通信メカニズムすなわちバス１５１１と、情報を処理する、バス１５１２に結合したプロセッサ１５１１とを有する。プロセッサ１５１２は、例えばペンティアム（商標）プロセッサ等のマイクロプロセッサを含むが、マイクロプロセッサに限定されない。

システム１５００は、さらに、プロセッサ１０４により実行される情報及び命令を格納する、バス１５１１に結合したランダムアクセスメモリ（ＲＡＭ）またはその他のダイナミック記憶装置１５１２（ここではメインメモリと呼ぶ）を有する。メインメモリ１５０４は、プロセッサ１５１２による命令の実行中に、一時的変数やその他の中間情報を記憶するために使用される。

コンピュータシステム１５００は、プロセッサ１５０６の静的情報や命令を記憶する、バス１５１１に結合した読み出し専用メモリ（ＲＯＭ）及び／またはその他の静的記憶装置１５１２と、磁気ディスク、光ディスクとその対応するディスクドライブ等であるデータ記憶装置１５０７とを有する。データ記憶装置１５０７は、情報と命令を記憶し、バス１５１１に結合している。

コンピュータシステム１５００は、コンピュータのユーザに情報を表示するための、バス１５１１に結合した、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）等のディスプレイ装置１５２１に結合している。英数字入力装置１５２２は、英数字その他のキーを含み、バス１５１１に結合され、プロセッサ１５１２に情報とコマンド選択を送る。追加的なユーザ入力装置として、マウス、トラックボール、トラックパッド、スタイラス、またはカーソル方向キー等のカーソル制御１５２３があり、バス１５１１に結合し、プロセッサ１５１２に方向情報とコマンド選択を送り、ディスプレイ１５２１上のカーソルの動きを制御する。

バス１５１１に結合した他の装置としてハードコピー装置１５２４がある。このハードコピー装置８２４は、紙、フィルム、その他のメディア上に、命令、データ、その他の情報を印刷するために使用される。さらに、スピーカ及び／またはマイクロホン等の音声録音再生装置も任意的にバス１５１１に結合しており、コンピュータシステム１５００のオーディオインターフェイスとして機能する。バス１５１１に結合する他の装置として、電話やハンドヘルドパームトップ装置と通信する、有線または無線の通信機能１５２５がある。

システム１５００のどの構成要素もそれに関連するハードウェアも、本発明で使用してもよい。しかし、言うまでもなく、他の構成のコンピュータシステムでは、これらの構成要素の一部または全部を含んでもよい。

上記の説明を読んだ当業者には本発明の変形例や修正例が明らかになったことは間違いなく、言うまでもなく、上記のどの実施形態も本発明を限定することを目的としたものではない。それゆえ、いろいろな実施形態の詳細の説明は、本発明に本質的であると考えられる特徴のみを記載した請求項の範囲を限定するものではない。

ユーザインターフェイスの例を示す図である。図１中のハイライトされたコメントにより参照された放射線画像に係わるログのビューを示す図である。文書に係わるログを表すＸＭＬファイルの例を示す図である。文書のランデブーポイントにエントリーを送るクライアントの設定を示す図である。同期プロセスの一実施形態を示すフロー図である。データプロセスの一実施形態を示すフロー図である。ワークフローの例を示す図である。ワークフロー情報の処理プロセスの一実施形態を示すフロー図である。ワークフロー情報の処理プロセスの別の実施形態を示すフロー図である。文書の関連性を判断するプロセスの一実施形態を示すフロー図である。文書ログ中のメタデータエントリーからの情報に基づくディスプレイ適応処理の一実施形態を示すフロー図である。システムの一実施形態を示すフロー図である。文書ログ中のメタデータエントリーからの情報に基づき選択され表示される広告をディスプレイに含めるプロセスの一実施形態を示すフロー図である。ログエントリー中のメタデータの分析に基づき、デジタルオブジェクトを参照するプロセスの一実施形態を示すフロー図である。サーバから情報を受けるモバイル装置を有する構成を示す図である。ログエントリーの管理プロセスの一実施形態を示すフロー図である。受け取った文書識別子に応じたデジタルオブジェクトを決定するプロセスの一実施形態を示すフロー図である。コンピュータシステムの一実施形態を示すブロック図である。

符号の説明

１１１０クライアント
１１１１ディスプレイ
１１１２記憶装置
１１１３文書
１１２０広告エンジン
１１３０サーバ
１１３１同期ユニット
１１３２ＩＤ
１１３３データ
１３１０紙文書
１３２０モバイル装置
１３２１バーコードリーダ
１３２２メモリ
１３２３ディスプレイ
１３２４プロセッサ
１３２５無線通信トランシーバ

Claims

１つ以上のメタデータエントリーのセットとは別に記憶されたデジタルオブジェクトに対応するセット中の１つ以上のメタデータエントリーを分析する段階と、
メタデータエントリー中のコンテントの分析に基づいて表示する１つ以上のデジタルオブジェクトを選択する段階と、を有することを特徴とする方法。
請求項１に記載の方法であって、
メタデータエントリーを分析する段階は１つ以上のメタデータエントリーにテキスト分析を実行する段階を有することを特徴とする方法。
請求項１に記載の方法であって、
１つ以上のメタデータを分析する段階は、異なるテキスト特徴に異なるウェイトをかける段階を有することを特徴とする方法。
請求項３に記載の方法であって、
異なるテキスト特徴に異なるウェイトをかける段階は、同じデジタルオブジェクトにコメントする著者をより関係があるとしてウェイトをかけることを特徴とする方法。
請求項１に記載の方法であって、
１つ以上のメタデータエントリーの分析に基づいて動作を実行する段階を更に有することを特徴とする方法。
請求項１に記載の方法であって、
閾値に対して１つのレベルにある１つ以上のメタデータエントリー中のいくつかのコメントに基づいて、１つのサイズを有するデジタルオブジェクトを表示する段階を更に有することを特徴とする方法。
請求項６に記載の方法であって、
デジタルオブジェクトを表示する段階は、１つ以上のメタデータエントリー中のコメント数が閾値より下である場合、第１のサイズの画像としてデジタルオブジェクトを表示し、１つ以上のメタデータエントリー中のコメント数が閾値より上である場合、第１のサイズの画像より大きい第２のサイズの画像としてデジタルオブジェクトを表示する段階を有することを特徴とする方法。
請求項１に記載の方法であって、
メタデータエントリー中のコンテントに基づき、表示する情報を選択する段階を更に有することを特徴とする方法。
請求項８に記載の方法であって、
表示する情報を選択する段階は、１つ以上の基準に基づき、１つ以上のサムネイル画像の表示を変更する段階を有することを特徴とする方法。
請求項９に記載の方法であって、
表示を変更する段階は、１つ以上のサムネイル画像のクラスター化を変更する段階を有することを特徴とする方法。
請求項１０に記載の方法であって、
表示を変更する段階は、１つ以上のサムネイル画像のサムネイルサイズを変更する段階を有することを特徴とする方法。
請求項９に記載の方法であって、
基準は、１つ以上のメタデータエントリー中のコメント数に基づくことを特徴とする方法。
請求項９に記載の方法であって、
基準は、１つ以上のメタデータエントリー中のクロスリファレンス数に基づくことを特徴とする方法。
請求項１に記載の方法であって、
各識別子は前記各メタデータエントリーのコンテントに基づくことを特徴とする方法。
請求項１４に記載の方法であって、
識別子はハッシュ値であることを特徴とする方法。
請求項１４に記載の方法であって、
識別子はコンテントの電子フォームにハッシュ関数を作用させた結果であることを特徴とする方法。
文書の文書識別子のユーザ入力を受け取る段階と、
識別子に関連するメタデータエントリーからの情報を表示する段階と、
を有することを特徴とする方法。
第１のログを受け取る段階と、
各エントリーの後のチェックポイントハッシュが一貫しているか決定する段階と、
を有することを特徴とする方法。