JP2010211828A - 電子的ドキュメントレポジトリーマネジメントおよびアクセスシステム - Google Patents

Abstract

【課題】カスタマイズされたサービスを複数の多種多様なエンドユーザーに提供しつつ、付加価値のある電子文書の大きなコーパスの配布およびマネジメントを提供するシステムおよび方法を提供すること。
【解決手段】１つの実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムであって、このシステムは、ドキュメントを電子的形式において格納するための少なくとも１つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有するデータ集合を備える。
【選択図】図１

Description

本発明は、データレポジトリーのアクセスおよび利用のために作製された、大規模の電子的データレポジトリーおよびソフトウェアアプリケーションにおける、データ、特にドキュメントの配布およびマネジメントに関する。

コンピュータおよびウェブ−ベースアプリケーションの使用にともなって、非常に大量の情報が、エンドユーザーにとって、オンラインでアクセス可能となり得る。近年、オンラインデータベースが、コンテンツにおいて特化され、特定のタイプの記録（例えば、商標、または特定分野の技術文献）のみを網羅する。従って、データベースおよびアクセスツールは、特に、そのコンテンツを念頭において、設計された。複数の情報に対するニーズを有するユーザーは、図１に示す環境が、強いられる。各情報は、必須とされる別個のシステムでの作業およびその特定のユーザーインターフェース（特定のデータベース（または関連するデータベースのセット）に対するアクセスを提供し、その情報リソースに特有のアクセスソフトウェアおよび課金ソフトウェアによってサービスを受ける）を必要とする。大量の格納能力および速度の改善によって、データベースが非常に大きなサイズに成長することを可能にし、そして単一のプロバイダによって、複数のデータベースを提供することを可能にする。

しかし、コンピュータ化された情報の集合のサイズの増加、および、検索速度に対するユーザーの期待、および、使用のユーザー−フレンドリーの形式、およびドキュメントデリバリーは、情報プロバイダの変化をもたらす。過去から受け継がれたユーザーインターフェースおよびアクセスシステムは、しばしば、それを使用することに対して非常に慣れた者に対してのみユーザー−フレンドリーであり、特定のコンテンツに対して調整されたほとんどのユーザーインターフェースおよびアクセスシステムは、お互いに異なり、そのことのために、ユーザーが１つのシステムから、他のコンテンツのためのシステムに移動することを困難となる。たとえ、ユーザーがその差異を受け入れることができたとしても、オペレータは、ただ単に、別個の過去から受け継いだシステムを、より大きな格納デバイスを有するより早いプロセッサにロードすることは、効率的でないことを見出している。

さらに、１つの過去から受け継いだシステムを用いて、別のシステムのデータベースにアクセスして、共有することは、通常、不可能出ない場合でも、困難である。たとえ、過去から受け継いだデータベースが、過去から受け継いだシステムの間で共有することができたとしても、他の非効率性の問題が生じ得る。しばしば、同一の情報が、異なるユーザーによって、異なる目的のために、求められる。従って、同一の情報は、複数のリサーチリソースまたはチャンネル（例えば、法律または金融ドキュメントサービスに対するニュースサービス）を通して、異なるタイプのユーザーにとって、利用可能とされ得る。同一の情報を、複数のリソースを通して利用可能とするために、データは、しばしば、重複し、そして異なるデータベースに格納される。さらに、異なるユーザーの問合せアプリケーション（ユーザーインターフェースと関連するものを含む）は、各別個のデータベースにアクセスするために使用され得る。このような構造は、典型的に非効率的である。なぜなら、これは、重複した、開発およびサポートのための努力、ならびに重複した情報の格納を必要とするからである。さらに、このことは、変化した顧客の関係または市場の状況に応答して、既存のシステムを変化することを、困難にする。

情報プロバイダにとって、２つの基本的な目的は、ユーザーに売却するために利用可能な情報を最大化し、そして情報の売却におけるフレキシビリティーを最大化するということである。これらの目的は、情報プロバイダが、情報プロバイダが、多くの異なる種類のユーザーに対してアピールすることができ、異なるレベルのアクセスおよびデリバリーのモードを提供することができ、そしてコンテンツおよび形式について調整された情報をデリバリーすることができることを意味する。これらの目的を追求することは、情報プロバイダが、異なるユーザーに異なる商品および価格決定を適合させ、そして新規のコンテンツおよび顧客を追加することにおいて、より大きなフレキシビリティを提供する。

これらの目的に取り組むために、複数のユーザーが、異なるアプリケーション（ウェブ−ベースまたはそれ以外）から、同一の情報にアクセスすることを可能にする、集中化された情報データベースおよび情報マネジメントシステムが必要である。さらに、電子的に格納されたドキュメントの大きな集合体にアクセスするための、そのようなアプリケーションを構築するために、効率的なアーキテクチャ／インフラストラクチャモデルがさらに必要である。

（発明の簡単な要旨）
１つの実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムである。

別の実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムであって、このシステムは、ドキュメントを電子的形式において格納するための少なくとも１つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有するデータ集合を備える。このシステムはさらに、少なくとも１つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント、および、受け取ったドキュメントを処理して、ドキュメントを富化するための、エンリッチメントコンポーネントを、備える。このシステムはさらに、データ集合からの情報を探す、少なくとも１つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント、少なくとも１つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント、ならびに、ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネントを、備える。

別の実施形態において、本発明は、問合せメッセージを処理するシステムであって、このシステムは、問合せメッセージを入力するための、１つ以上のユーザーインターフェースであって、ここで、この１つ以上のユーザーインターフェースの各々は、リソースアプリケーションに適合する、ユーザーインターフェース、問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための１つ以上のデータ集合、および、その１つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、１つ以上のメタデータ情報ファイルを備える。このシステムは、さらに、１つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、この取入れ口コンポーネントは、新規ドキュメントからメタデータを作成し、そして、１つ以上のデータ集合において、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、を備える 別の実施形態において、本発明は、問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法である。この方法は、ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、少なくとも１つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程、および、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、サーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程、を包含する。この方法は、さらに、問合せメッセージに対する応答において、ユーザーに対して、１つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程、および、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、ユーザーに関連するユーザープロファイルに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程であって、リソースアプリケーションにおいて具体化され得る、工程、を包含する。この発明はまた、選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、を包含する。

別の実施形態において、本発明は、問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、少なくとも１つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネントを備える、伝達媒体において具体化されたコンピュータデータシグナル。この媒体はまた、問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、サーチコンポーネントに対してデリバリーされる、問合せメッセージに備えるコードコンポーネント、および、１つ以上のドキュメントを同定するサーチ結果メッセージを、問合せメッセージに応答してユーザーに提供するためのコードコンポーネントを備える。この媒体はまた、ユーザーと関連するユーザープロファイルに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答するコードコンポーネント、を備える、コンピュータデータシグナル。

複数の実施形態が開示されるが、本発明のなお別の実施形態が、以下の詳細な説明に従って、当業者に明らかとなる。明かであるように、本発明は、全て本発明の趣旨および範囲から逸脱することなく、種々の明白な局面において、修飾され得る。従って、図面および詳細な説明は、発明の性質を例示するもと看做されるが、限定するものではない。
例えば、本発明は以下を提供する。
（項目１）
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下：
ａ．ドキュメントを電子的形式において格納するための少なくとも１つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合；
ｂ．該少なくとも１つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント；
ｃ．受け取ったドキュメントを処理して、該ドキュメントを富化するための、該取入れコンポーネントと関連したエンリッチメントコンポーネント；
ｄ．データ集合からの情報を探す、少なくとも１つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント；
ｅ．少なくとも１つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント；ならびに、
ｆ．ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント、
を備える、システム。
（項目２）
項目１に記載のシステムであって、ここで、該システムはさらに、サーチコンポーネントが少なくとも１つのユーザー問合せメッセージを再処理しないその後のアクセスのための、検索された識別子を格納するための持続性のサービスを備える、システム。
（項目３）
項目１に記載のシステムであって、ここで、該システムはさらに、複数のノードを有するコンテンツの少なくとも１つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで該ノードの１つ以上が該１つ以上のノードと関連する１つ以上のドキュメントと同定する、システム。
（項目４）
項目３に記載のシステムであって、ここで、コンテンツサービスのテーブルが、コンテンツの２つ以上のテーブルをサポートし、ここで、コンテンツの各テーブルが特定のユーザーのタイプに適合する、システム。
（項目５）
項目３に記載のシステムであって、ここで、コンテンツの少なくとも１つのテーブルが、２つ以上のデータ集合を参照する、システム。
（項目６）
項目４に記載のシステムであって、ここで、コンテンツの２つ以上のテーブルの１つが、コンテンツの別の２つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
（項目７）
項目１に記載のシステムであって、ここで、少なくとも１つのデータ集合中のドキュメントが、少なくとも１つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも１回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
（項目８）
項目１に記載のシステムであって、ここで、少なくとも１つのデータ集合中のドキュメントが、少なくとも１つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る取入れ口コンポーネントは、各追加のドキュメントが特有の識別子を有しそして少なくとも１つの集合サブセットに割り当てられることを、確実にする、システム。
（項目９）
項目１に記載のシステムであって、ここで、少なくとも１つのデータ集合が、１つ以上の集合サブセット中のドキュメントの集合体である少なくとも１つのドキュメントのセットを有する、システム。
（項目１０）
項目１に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
（項目１１）
項目１に記載のシステムであって、ここで、エンリッチメントコンポーネントは、ドキュメントが以下：
ａ．ヒト作因によって準備される、さらなる編集材料；
ｂ．自動化作因によって準備される、さらなる編集材料；
ｃ．前記データ集合中の別のドキュメントに対するポインタを提供するリンク；
ｄ．法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用；または、
ｅ．メタデータファイル中に出現するドキュメントと関連するエントリ、の少なくとも１つと関連を生じるように、該ドキュメントを処理する、システム。
（項目１２）
項目１に記載のシステムであって、ここで、新規ドキュメントを受け取るための前記取入れ口コンポーネントが、前記受け取られたドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
（項目１３）
項目１に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも１つのデータ集合において利用可能にする、システム。
（項目１４）
項目１に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、少なくとも１つのデータ集合において利用可能にする、システム。
（項目１５）
項目１に記載のシステムであって、ここで、前記ドキュメントの集合体が、少なくとも２０テラバイト情報を含む、システム。
（項目１６）
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下：
ａ．問合せメッセージを受け取るための、１つ以上のユーザーインターフェースであって、ここで、該１つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース；
ｂ．問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための１つ以上のデータ集合；
ｃ．該１つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、１つ以上のメタデータ情報ファイル；ならびに
ｄ．該１つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該１つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、を備える、システム。
（項目１７）
項目１６に記載のシステムであって、ここで、前記システムは、複数のノードを有するコンテンツの少なくとも１つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで、該ノードの１つ以上が、該１つ以上のノードと関連する１つ以上のドキュメントを同定する、システム。
（項目１８）
項目１７に記載のシステムであって、ここで、前記コンテンツサービスのテーブルが、コンテンツの２つ以上のテーブルをサポートし、ここで、コンテンツのテーブルの各々が、特定のユーザーのタイプに適合する、システム。
（項目１９）
項目１７に記載のシステムであって、ここで、前記コンテンツの少なくとも１つのテーブルが、２つ以上のデータ集合中にあるドキュメントを参照する、システム。
（項目２０）
項目１８に記載のシステムであって、ここで、コンテンツの２つ以上のテーブルの１つが、コンテンツの別の２つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
（項目２１）
項目１６に記載のシステムであって、ここで、少なくとも１つのデータ集合中のドキュメントが、少なくとも１つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも１回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
（項目２２）
項目１６に記載のシステムであって、ここで、少なくとも１つのデータ集合中のドキュメントが、少なくとも１つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る手段は、各追加のドキュメントが特有の識別子を有しそして少なくとも１つの集合サブセットに割り当てられることを、確実にする、システム。
（項目２３）
項目１６に記載のシステムであって、ここで、少なくとも１つのデータ集合が、１つ以上の集合サブセット中のドキュメントの集合体である少なくとも１つのドキュメントのセットを有する、システム。
（項目２４）
項目１６に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
（項目２５）
項目１６に記載のシステムであって、ここで、メタデータエクストラクタは、ドキュメントが以下：
ａ．ヒト作因によって準備される、さらなる編集材料；
ｂ．自動化作因によって準備される、さらなる編集材料；
ｃ．前記データ集合中の別のドキュメントに対するポインタを提供するリンク；
ｄ．法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用；または、
ｅ．メタデータファイル中に出現するドキュメントと関連するエントリ、の少なくとも１つと関連を生じるように、該ドキュメントを処理する、システム。
（項目２６）
項目１６に記載のシステムであって、ここで、前記取入れ口コンポーネントが、前記ドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
（項目２７）
項目１６に記載のシステムであって、ここで、前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも１つのデータ集合において利用可能にする、システム。
（項目２８）
項目１６に記載のシステムであって、ここで、前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、任意のデータ集合において利用可能にする、システム。
（項目２９）
項目１６に記載のシステムであって、ここで、前記１つ以上のデータ集合が、少なくとも２０テラバイト情報を含む、システム。
（項目３０）
問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法であって、該方法は、以下：
ａ．ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、コンピュータシステム上で実行するリソースアプリケーションに関連する、少なくとも１つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程；
ｂ．応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程；
ｃ．該問合せメッセージに対する応答において、該ユーザーに対して、１つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程；
ｄ．該サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、少なくとも１つのユーザーインターフェースに関連する少なくとも１つのリソースアプリケーションに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程；ならびに、
ｅ．該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、
を包含する、方法。
（項目３１）
問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、以下：
データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、コンピュータシステム上で実行するリソースアプリケーションに関連した少なくとも１つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネント；
該問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる、該問合せメッセージに備えるコードコンポーネント；
１つ以上のドキュメントを同定する、サーチ結果メッセージを提供するためのコードコンポーネント；ならびに
少なくとも１つのユーザーインターフェースと関連する少なくとも１つのリソースアプリケーションに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、ドキュメント選択データに応答するコードコンポーネント、を備える、コンピュータデータシグナル。
（項目３２）
電子的に格納されたドキュメントの大きな集合体を維持し、そしてそのドキュメントを、問合せメッセージを出すユーザーに対して利用可能にするためのシステムであって、該システムは、以下：
ａ．ドキュメントを、電子的形式において格納するための少なくとも１つのデータ集合であって、ここで、各ドキュメントは、特有の識別子を有する、データ集合；
ｂ．該少なくとも１つのデータ集合に対して追加されるべき新規のドキュメントを受け取り、そして新規のドキュメントを、ドキュメントの上位ｎ個の特有の逆ドキュメント頻度（ｉｄｆ）タームおよびドキュメント長さスカラを含む重複比較シグネチャと関連付けるための取入れ口コンポーネント；
ｃ．該データ集合から情報を探す、少なくとも１つのユーザー問合せメッセージを受け取るためのユーザーインターフェース；
ｄ．少なくとも１つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント
ｅ．該応答するドキュメントの重複比較シグネチャの中で比較を行って、そして比較シグネチャが正確に同一であるか、または予め決定された類似性の閾値内である場合に、重複を同定するための、重複検出コンポーネント；ならびに
ｆ．ユーザーのドキュメント要求に対して応答する、要求されたドキュメントを提示するためのデリバリーコンポーネント、
を備える、システム。
（項目３３）
項目３２に記載のシステムであって、ここで、重複比較シグネチャは、上位ｎ個の特有のｉｄｆタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、そしてｎが４から３０である、システム。
（項目３４）
項目３２に記載のシステムであって、ここで、重複比較シグネチャは、トークンに基づく、上位ｎ個の特有のｉｄｆタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、ここで、長さスカラに関して予め決定された類似性閾値が０から２５６の範囲である、システム。
（項目３５）
項目３２に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、重複検出コンポーネントは、サーバー側にあり、そして、クライアント側に対して、重複の同定を伝達する、システム。
（項目３６）
項目３２に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、クライアント側に対する重複の同定を用いて、ユーザーに伝達されたサーチ結果リストから該重複ドキュメントを取り除く、システム。
（項目３７）
項目３６に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含む、システム。
（項目３８）
項目３６に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含み、そして重複ドキュメントのセットが、ユーザーにとってアクセス可能にされる、システム。
（項目３９）
ユーザー問合せメッセージによって探される情報を小売するためのシステムであって、以下：
ａ．問合せメッセージを受け取るための１つ以上のユーザーインターフェースであって、該１つ以上のユーザーインターフェースは、システム上で実行するリソースアプリケーションに適合される、ユーザーインターフェース；
ｂ．問合せメッセージに応答してユーザーにデリバリーするための、リソースアプリケーションのための目的のドキュメントを格納するための１つ以上のデータ集合；
ｃ．１つ以上のデータ集合中に格納されたドキュメントについて、問合せメッセージによって開始するサーチを容易にするために、メタデータを保持するための１つ以上のメタデータ情報ファイル；
ｄ．１つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該１つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント；ならびに ｅ．問合せメッセージに応答した１つ以上のデータ集合に対するアクセスを制御し、そして、１つ以上のデータ集合に対するアクセスについてユーザーに課金するための情報を作成するための、２つ以上のリソースアプリケーションによって共有されるセキュリティサービスおよび課金サービス、
を備える、システム。
（項目４０）
項目３９に記載のシステムであって、ここで、前記１つ以上のデータ集合は、以下のタイプの情報：法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース、の１つ以上を含む、システム。
（項目４１）
項目４０に記載のシステムであって、ここで、該システムは、さらに、各々のタイプの情報について、複数のノードを有する少なくとも１つのコンテンツのテーブルを維持するためのコンテンツサービスのテーブルを含み、ここで、該ノードの１つ以上は、該１つ以上のノードに関連する１つ以上のドキュメントを同定し、そして、少なくとも１つのドキュメントは、１つよりも多いコンテンツのテーブルにおいて同定される、システム。
（項目４２）
ドキュメントを探す問合せメッセージを処理するためのシステムであって、以下： ａ．問合せメッセージを受け取るための１つ以上のユーザーインターフェースであって、該１つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース；
ｂ．問合せメッセージに応答して、ユーザーに対してデリバリーするための、ドキュメントを格納するための、１つ以上のデータ集合；
ｃ．該１つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするための、メタデータを保持するための、１つ以上のメタデータ情報ファイル；ならびに、
ｄ．該１つ以上のデータ集合に追加されるべきドキュメントを処理するための新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからリソース記述フレームワーク（ＲＤＦ）ステートメントの形式のメタデータを作成し、そして、該１つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、新規ドキュメント取入れ口コンポーネント、
を備える、システム。
（項目４３）
項目４２に記載のシステムであって、さらに、該システムは、各タイプの情報についての複数のノードを有するコンテンツの少なくとも１つのテーブルを維持するための、コンテンツサービスのテーブルを備え、そして前記メタデータエクストラクタの少なくとも１つは、ＲＤＦステートメントための語彙として、コンテンツの少なくとも１つのテーブルのノードのラベルを用いる、システム。
（項目４４）
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下：
ａ．ドキュメントを電子的形式において格納するための少なくとも１つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合；
ｂ．該少なくとも１つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント；
ｃ．受け取ったドキュメント内において、少なくとも１つのＰＩＴフィールドの位置決めをするか、または配置するための、該取入れ口コンポーネントと関連したタイムスタンプコンポーネント；
ｄ．データ集合からの情報を探す、少なくとも１つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント；
ｅ．少なくとも１つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネントであって、ここで、該処理および検索は、少なくとも１つのＰＩＴフィールドに応答して、問合せメッセージのＰＩＴ制限に対して応答するドキュメントのバージョンをデリバリーする、サーチコンポーネント；ならびに
ｆ．ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント。
（項目４５）
項目４４に記載のシステムであって、ここで、前記少なくとも１つのＰＩＴフィールドは、時間と日付の情報を含む、システム。
（項目４６）
項目４４に記載のシステムであって、ここで、前記少なくとも１つのＰＩＴフィールドは、バージョンの情報を含む、システム。
（項目４７）
項目４４に記載のシステムであって、ここで、前記少なくとも１つのＰＩＴフィールドは、法律の異なるバージョンを識別する、システム。
（項目４８）
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下：
ａ．問合せメッセージを受け取るための、１つ以上のユーザーインターフェースであって、ここで、該１つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース；
ｂ．問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための１つ以上のデータ集合；
ｃ．特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、１つ以上の試行ファイル；ならびに、
ｄ．試行ファイルを処理して、特定のリソースアプリケーションについての共通の使用パターンを決定し、そして、そのような使用パターンとより一致する様式において、現在のサーチオプションおよびサーチ結果に対して、リソースアプリケーションのパラメータを、調節する、試行分析コンポーネント、
を備える、システム。
（項目４９）
項目４８に記載のシステムであって、ここで、共通の使用パターンは、ドキュメントがサーチ結果として表示される優先順位と比較して、ユーザーがサーチ結果において同定されたドキュメントをディスプレイする順序を含み、そして、調節されたパラメータは、ドキュメントがサーチ結果として表される優先順位に影響する、システム。
（項目５０）
項目４８に記載のシステムであって、ここで、共通の使用パターンは、サーチ結果において重複であるとして同定されたドキュメントのユーザーの再調査を含み、そして、調節されたパラメータは、重複する検出サービスについての、類似性閾値に影響する、システム。
（項目５１）
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下：
ａ．問合せメッセージを受け取るための、１つ以上のユーザーインターフェースであって、ここで、該１つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース；
ｂ．問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための１つ以上のデータ集合；
ｃ．特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、１つ以上の試行ファイル；ならびに、 ｄ．試行ファイルを処理して、共通の使用パターンを決定し、そして、そのような使用パターンに対するリソースアプリケーションに対して、アクセス可能であるメタデータファイルを構築する、試行分析コンポーネント、
を備える、システム。

図１は、従来技術の小売システムを示す、略ブロック図である。 図２は、本発明のシステムが、いかにして、共通のリソース（共有されたサービス）を使用する別個のアプリケーションを利用して、複数のデータ集合に対する共有されたアクセスに基づき、識別されたユーザーのサービスを提供するのかを示した、略ブロック図である。 図３は、電子的に格納されたドキュメントの大きな集合体を、維持および分配するためのシステムの概観を示す略ブロック図である。 図４は、ドキュメント問合せおよび検索アプリケーションのためのウェブ−ベースのアプリケーションフレームワーク、および共通のコンテンツレポジトリーソフトウェアシステムとのそのインターコネクションを示すブロック図である。 図５は、図４のシステムの、クライアント、サーバーおよびデータのトレイルを示す、模式図である。 図６は、本発明において使用されるドキュメントレコードおよび関連するメタデータレコードの模式図である。 図７は、リソースアプリケーションを構築するために使用される開発ツールを示す略ブロック図である。 図８は、ドキュメントの取り込みのためのプロセスを示すフローチャートダイアグラムである。 図９は、ドキュメントのエンリッチメントのプロセスおよびドキュメントのメタデータ処理を示すフローチャートダイアグラムである。 図１０は、本発明のコンテンツ（ＴＯＣ）アーキテクチャのテーブルを示す模式図である。 図１１Ａ〜Ｄは、本発明に従って構築されたコンテンツ構造のテーブルを示す模式図である。 図１２は、本発明に従って構築されたコンテンツの例のテーブルを示す模式図である。 図１３は、本発明において、セキュリティーサービスがどのようにして機能するのかを示す、略ブロック図である。 図１４は、いかにしてセキュリティーが実行されるのか、ならびにユーザーグループおよび許可を示す、関係ダイアグラムである。 図１５は、本発明のセキュリティーモデルについての、定義および関連ダイアグラムである。 図１６は、いかにして、アラートサービスがクリッピングを提供するかを示す、模式図である。 図１７は、いかにして、トレイルサービスが機能するのかを示す、模式図である。 図１８Ａは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。 図１８Ｂは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。 図１９は、いかにして、ドキュメントレンダリングが、最小のプレゼンテーションスタイルシートとともに機能するのかを示す、略ブロック図である。 図２０は、いかにして、ドキュメントレンダリングが、あつらえのスタイルシートおよび複数のスタイルシートともに機能するのかを示す略ブロック図である。

（詳細な説明）
（Ａ．システムの概観）
図２は、いかにして、本発明のシステムが共通のリソースまたは共有されたシステムサービスを用いて、メタデータ５０を有する複数のデータ集合３０に対する共有されたアクセスに基づいて、ユーザー６に対して、識別された情報リソースサービスを提供するのかを示す、ブロック図である。より具体的には、図２は、いかにして、複数のユーザー６（例えば、金融ニュースに興味を持つユーザー_ａ、法律ドキュメントに興味を持つユーザー_ｂ、および技術および特許ドキュメントに興味を持つユーザー_ｚ）が、システムと相互に作用し得る。（これら興味の対象は、例示である；ユーザーは、法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース情報、あるいは、これら分野の特定の部門。）各ユーザーは、それぞれのユーザー問合せメッセージＱ_ａ１、Ｑ_ｂ１、およびＱ_ｚ１を送り、これらは、ユーザーのそれぞれのリソースアプリケーションソフトウェア１５（例えば、リソースＡｐｐ_Ａ、リソースＡｐｐ_Ｂ、およびリソースＡｐｐ_Ｃ）によって受け取られ、これらの各々は、その情報ソースに対して購読し、そしてアクセスを購入するユーザーの特定のドキュメントのニーズに対して役に立つように、設計される。リソースアプリケーション１５（リソースＡｐｐ_Ａ、リソースＡｐｐ_Ｂ、およびリソースＡｐｐ_Ｃ）の各々は、それぞれのユーザー問合せメッセージＱ_ａ１、Ｑ_ｂ１、およびＱ_ｚ１を、共有システムサービス／ツール２０（各リサーチリソースを含む情報リソースフィーチャーを提供するために必要な種々の機能を実行するソフトウェアとハードウェア）のセットに対して送る。

概観するために、より重要な共有されたサービス／ツールは、サーチサービス（ユーザー問合せを処理して、問合せに応答する１つ以上のドキュメントを見出す）、会計サービスおよびビジネスサービス（情報の小売を可能にする）である。共有されたサーチサービスは、適切なデータ集合３０（関連するメタデータ５０を含む）のコンテンツを分析し、これらの各々は、関連するメタデータ５０を有す１つ以上のドキュメントを含む。単純化のために、各データ集合を、２つのドキュメントのみを有するとして示す。従って、データ集合は、ドキュメントＤ_１１、Ｄ_２２を有し、データ集合_２は、ドキュメントＤ_ｎ１、Ｄ_ｎ２を有する。各ユーザーは、１つのみのデータ集合３０に対するアクセスを提供する購読を有し得、そして各ユーザーのアクセス可能なデータ集合は、他者のものとは異なり得るが、システムは、限定されない。図２の例において、ユーザー_ａは、データ集合にアクセスする問合せを送り、その一方で、ユーザー_ｂは、データ集合_１およびデータ集合_２の両方にアクセスする問合せを送った。さらに、ユーザーｚは、データ集合_２およびデータ集合_ｚの両方にアクセスする問合せを送った。

ユーザー_ａは、ユーザーの問合せＱ_ａ１に応答して、データ集合からドキュメントＤ１１ａを受け取る。デリバリーされるＤ_１１ａは、リソースＡｐｐ_Ａのフィーチャーに基づき、特定の形式であり、そしてＤ_１１として格納されたドキュメントのフォーマットである。ユーザーｂは、その問合せＱ_ｂ１に応答して、データ集合から２つのドキュメントを受け取る（データ集合１からのドキュメントＤ_１１（問合せＱ_ａ１に応答するドキュメントと同一のドキュメント）およびデータ集合２からのドキュメントＤ_２１）。図２において示されるように、ユーザーに対してデリバリーされるドキュメントＤ_１１は、リソースＡｐｐ_ＢがＤ_１１として格納されたドキュメントをデリバリーする形式またはフォーマットＤ_１１ｂとは同一ではない、リソースＡｐｐ_Ａによって決定される特徴的な形式、またはフォーマットＤ_１１ａとして与えられ得る。ユーザーｚはまた、問合せＱｚ１に応答して、２つのドキュメントを受け取る（データ集合２からドキュメントＤ２２、データ集合ｎからドキュメントｎ２）。再度、リソースＡｐｐ_ｚは、リソースＡｐｐｚのフィーチャーに基づいて、Ｄ２２およびＤｎ１として格納したドキュメントの特定の形式またはフォーマット（すなわち、Ｄ２２ｚおよびＤｎ２ｚ）において、これらドキュメントの各々を、受け取る。従って、図２は、２つの異なるリソースアプリケーション１５が、各々同一のデータ集合３０にアクセスし得、そして実際にその集合中の同一のドキュメントにアクセスし得ることを示す。さらに、図２は、各リソースアプリケーション１５が、共有されたシステムサービス／ツール２０を利用するが、そのユーザーに対してデリバリーされたドキュメントを、別のリソースアプリケーションによってデリバリーされた同一のドキュメントのデリバリーされた形式／フォーマットとは、いくぶん異なる形式またはフォーマットにし得る。サービスおよびデータレベルでのリソースは、共有されるが、ユーザーにデリバリーされる結果は、異なり得る。

図３は、電子的に格納されたドキュメントの大きな集合体を維持しそして分配するためのシステム（図２において機能的に考察されるものを含む）の概観を示す略ブロック図である。より高いレベルの機能エレメントが、示される。これらの格納されたドキュメントは、多様なユーザーの集団によって利用可能とされる。システムのエレメントとしては、１つ以上のリソースアプリケーション（ＲＡ）ユーザーインターフェース１０ａ、１０ｂ、．．．１０ｎ（ユーザーのための種々の静止スクリーンおよびインタラクティブスクリーンにアクセスし、および／または作成してデリバリーし、そして、１つ以上のユーザーメッセージ１２ａ、１２ｂ、．．．１２ｎを入力として引き出して受け入れる）；共有されたサーチコンポーネント２２；１つ以上のデータベースまたはデータ集合３０ａ、３０ｂ（単純化のために、２つのみが示される）；共有されたドキュメントデリバリーコンポーネント４０；１つ以上のメタデータファイル５０ａ、５０ｂ（再度、単純化のために、２つのみを示す）；および新規ドキュメントキュー７０、エンリッチメントコンポーネント８０を伴い、プライオリティーコンポーネント９０およびＧＵＩＤコントロール１００を含む。

各ＲＡユーザーインターフェースは、１０ａ、１０ｂ．．．１０ｎは、１つ以上の主題領域中の情報アクセスリソースとして供されるソフトウェアのコレクションである、リソースアプリケーション１５ａ、１５ｂ．．．の一部である。リソースアプリケーションは、特定の所望の市販の提供（すなわち、「製品」）を具現化、および／または得意のユーザー必要性またはユーザープロフィールに応答する。従って、１つのリソースアプリケーションは、その他から、それ自身を：アクセス可能なコンテンツ／主題の事項；ドキュメントエンリッチメントの程度、ユーザーインターフェース特徴；ドキュメント送達フォーマットまたはモード；正確さ；および特定のリソース必要性またはユーザーマーケットに対するその他のアピール特徴によって区別し得る。

本発明の種々のコンポーネントは、異なるリソースアプリケーションを横切る記憶されたドキュメントの本質的に縫い目のないコンテンツを共有すること、および種々の様式でアクセス（例えば、ウェブサイト、インターネット、エクストラネット、ワイアレスなど）を可能するツールのセットを提供する。本発明はまた、リソースアプリケーションへの共有されたサービスおよびツールを提供するための、共通リソースアプリケーションインフラ構造（ＡＲサーバー３００、図４）による履行を含む。情報販売、セキュリティおよび請求書発行サービスは、重要な共有サービスである。各リソースアプリケーションは、共通コンテンツレポジトリーおよびデータサーバーソフトウェア（ＣＣＲＤＳサーバー４００、図４）により記憶および維持されたドキュメントの少なくとも一部分へのアクセスを容易にすることにより、特定のユーザープロフィールおよびマッケットプレイスをサービスするために開発されている。リソースアプリケーションついて規定し、かつ履行することの利点は、共有サービスおよびツールのセットは、以下に論議されるようなものを含み：再使用可能性，アプリケーションを開発するための減少した時間、および新たなアプリケーション開発のための低減されたコストを含む。

本発明に適用可能な１つのシステムでは、データの大きな塊が、ＣＣＲＤＳサーバー４００によって管理される共通コンテンツレポジトリー中に記憶されるが、それは、複数のアクセス可能なサーバー上に広がり得、そして余分に維持される。このデータは、広範な範囲の主題をカバーし、そして異なる理由のために多様なグループのユーザーによってアクセスされ得る。従って、それは、異なるユーザーインターフェース１０ａ、１０ｂ、．．．１０ｃを通じてデータへの異なるタイプのユーザーアクセスを提供するために有用であり得る。各ユーザーインターフェースは、特定の詳細ユーザー特徴および必要性を供するよう適合されたスクリーン中で履行され得る。このユーザーインターフェースは、カクタマイズされて質問を作製するか、ドキュメントをリクエストするユーザーメッセージの処方の容易さを提供するのみならず、カスタマイズされてドキュメント送達のためにユーザーに適切な形態およびフォーマットを提供する。すなわち、共通のレポジトリーから送達されたデータは、特定のユーザーインターフェースに特異的に仕立てられ、かつフォーマットされる＞
種々の理由のため、記憶された情報は、ドキュメントの塊内の個々のドキュメントの形態で記憶されている。このドキュメントの塊は、ドキュメントの１つ以上のコレクション中に区画される。本明細書で用いられるとき、ドキュメントは、著者または供給元が情報を調製する、ニュース論説、司法的意見（事例レポート）、規制規則、レポート、電子ファイルまたはデータベース記録、またはその他の慣例のフォーマット（紙または電子媒体のいずれか）のような、特有の一般的な識別子（ＧＵＩＤ）を受ける１つの密着したデータユニットとして広く規定される。関連するドキュメントのグループは、コレクションとして一緒に記憶され得（論理的に、必ずしも物理的である必要はない）、そして１つ以上のコレクションが、セットとて、一緒に貯蔵され得る（再び、論理的に、必ずしも物理的である必要はない）。

コレクションおよびセットの使用は、ユーザーが、特定の、共通して理解されるセットまたはコレクション、例えば、特定セットの地域法律事例レポーター；法律総説のような特定カテゴリーの定期刊行物；死亡、所有権または商標の記録のような記録のコレクション内のサーチすることのユーザーの範囲を容易にし得る。各ドキュメントは、コレンションおよびセット内で少なくとも一度インデックスを付けられる。このコレクションおよびセット配列はまた、システムが、サーチを特定のコレクションまたはセットに向けることにより課せられるサーチを低減し、そして各サーチが全ドキュメントレポジトリーをカバーすることを必要としない。ドキュメントレポジトリーは、合計２０テトラバイト以上の情報を含んで極度に多くあり得る。

いくつかの分野では、新規ドキュメントが、常時、しばしば、数分毎または数秒毎に現れるというような高頻度でさえ生成され、そしてＦＴＰまたはその他のフォーマットにより、リアルタイムにドキュメント行列待ち７０に送達される。このデータレポジトリーがアップデートされるか、またはそのコレクションが拡張するとき、新規ドキュメントは、１つ以上のデータコレクション３０ａ、３０ｂに付加され得る。新規ドキュメントは、後に、異なる目的のために異なるユーザーによってアクセスされるので、取り込みコンポーネント（Ｉｎｔａｋｅ Ｃｏｍｐｏｎｅｎｔ）８０によって実施されるドキュメント取り込み機能が、適正な基礎を提供することが所望される。所定のドキュメントの取り込みを繰り返されなければならないこと、または、通常でない状況にあることを除き、それがレポジトリーに付加された後でそれを編集することは所望されない。なお、この同じドキュメントは、このドキュメントをアクセスするために採用され得るユーザーインターフェースおよびリソースアプリケーションに基づき、その送達の一部分として改変可能である必要があってもよい。（さらに、このリソースアプリケーションは、このドキュメントがドキュメントコレクションに入るときに存在しなくてもよい）。従って、各ドキュメントは、好ましくは、ＸＭＬ、または後の刊行において柔軟性を許容する別のドキュメントフォーマットで記憶され、そして柔軟性を支援する属性をもって生成またはエントリーの時間で提供される。さらに、このドキュメントに関連するメタデータファイルエントリーまたは記録がまた生成され得る。このメタデータファイルエントリーまたは記録は、ドキュメントのコンテンツが、ドキュメントのコンテンツの取り込みの時間に、ドキュメント自身のために適切であり得る特定の様式で富化され得ることを可能にし、そしてまた、ドキュメント自身を改変することなく、取り込みのときに、ドキュメントに関連するメタデータを改変することにより、ユーザーに利用可能な情報の後の富化を許容する。（本明細書で用いられるとき、メタデータは、情報についての情報を意味し、そしてユーザー、システム、または両方のいずかに有用であるドキュメントについての任意の情報であり得る）。

図６は、ドキュメント１１０に関連するメタデータレコード１５２が記憶される、データコレクション３０ａ、３０ｂおよびメタデータファイル１５０に記憶され得るような、ドキュメントレコード１１０の概略図である。このドキュメントレコード１１０は、タイトル１１２、著者／刊行者１１４、日付１１４、ＧＵＩＤ（全体汎用識別子：ｇｌｏｂａｌ ｕｎｉｖｅｒｓａｌ ｉｄｅｎｔｉｆｉｅｒ）１１８、およびＰＩＴ（時間点：ｐｏｉｎｔ ｉｎ ｔｉｍｅ）スタンプのようなフィールドを含む。このドキュメントは、取り込み時に調製されたエンリッチメントデータを受けるためのフィールド１２６を含み得、そして必要に応じて、１つ以上のＴａｂｌｅ ｏｆ Ｃｏｎｔｅｎｔ（以下にさらに詳細に論議される）にこのドキュメントを関連付ける「ｎｔｏｖｉｅｗ」フィールド１２７を含み得る。このドキュメントは、１つ以上の挿入されたリンク１２２または分類属性１２４を含み得る。ドキュメントは、テキスト、持続するかまたは移動するイメージ、音またはコンテンツのその他の形態を含み得る。コンテンツの性質は、ドキュメントレコード１１０中またはメタデータファイルレコード１５２中のいずれかに捕獲される別の属性１１１であり得る。

陳述のように、取り込みコンポーネント８０により処理されるドキュメントは、属性をもつソースから受けたファイル（例えば、ニュース刊行者、ジャーナル刊行者、ストックマーケット、裁判所または規制当局）を提供することにより富化され得る。提供された特定の属性は、付加されているドキュメントのタイプに依存する。これら属性はまた、特定のリソースアプリケーションに一部として特定され得る。

属性は、少なくとも２つの機能を提供し得る。第一は、そのシステム内またはユーザーに対するユーティリタリアン（ｕｔｉｌｉｔａｒｉａｎ）である。すなわち、特定のコンテンツまたはコンテンツモディファイヤ、ならびに機能フィーチャ（例えば、他の文書へのナビゲーション関係またはナビゲーション接続をアクティブに確立するリンクを示す）が作成され得る。第二は、ブランド認識フィーチャである。なぜなら、ソースの受容は、しばしば、文書自体と同様に重要であるからである。このブランド識別性は、文書の最終の外観によって確立され得る。これは、文書に付加される特定のブランド識別属性（例えば、ユニークな形式またはソースから送達されるコンテンツから生成される特殊に派生する付加価値コンテンツ）によって容易にされ得る。

例えば、取り込みのために処理される文書は、所定の株式報告または会社分析に関連し得る。この文書のテキストまたは事実コンテンツは、一般的に一旦作成されると不変である。２つの異なる販売者は、各々が受容されるレベルの品質を有し、その文書のコンテンツに対するアクセスをユーザーに提供し得る。各々の販売者は、文書をアクセス可能にするが、自分自身の情報販売システムの「外観および感触」を有することを欲し得る。従って、本発明のシステムの属性および／またはメタデータファイルを利用して、それがそのソースから提供されるときに文書を補充または強化し得、その結果、特定のユーザーインターフェースまたはリソースアプリケーションを介して提示されるときに、それが、ユニーク性を増し、そしてブランド化され、そして付加価値が与えられた製品として受容され得る。

取り込みの際にそのエンリッチメントのために文書に関連付けされ得る属性の一つは、リソースアプリケーションに依存するベースに基づいて後に可能性のある使用のために、文書へのリンク付け（例えば、ハイパーリンク１２２の挿入による）を含む。例えば、法律のリソースアプリケーションに適合される判例法国は、他の内部参照される判例報告へのリンクを含み得る。これは、共通コンテンツレポジトリにおいて見出され得る（または他の場所（例えば、ワールドワイドウェブ））。新聞記事は、その話において識別される個人または事件に関連する特定のコンテンツにリンクされ得る。そのようなリンク１２２のアクセス可能性は、不確実であり得、すなわち、リソースアプリケーションに依存するが、いくつかの文脈においてユーザーインターフェースを通じて提供されないかもしれない。例えば、ニュースサービスの法曹ではないユーザーが法律関連の判決例報告にアクセスし得る。他の判決例報告に対するリンクは、アクティブではない可能性があり、あるいはそのユーザーについて、法曹のプロユーザーについて同じ様式で適切ではないかもしれない。記述されるように、文書に関連付けられるメタデータファイル記録１５２は、レポジトリにそれが付加される時点で付加される属性に関する別の場所である。メタデータ記録１５２は、リソースアプリケーションによって使用されて、もとの格納された文書記録１１０自体を変化させることなく、ユーザー照会メッセージに関連して文書についてデータ、パラメータまたはディスプレイ形式を重ねがき、付加、削除または改変する情報を格納する（または他のメタデータファイルにリンク付けする１５６）。

文書取り込みのプロセスの一部として、文書記録１１０は、編集材料によって強化され得る。すなわち、付加価値編集コンテンツが、文書に挿入され得るか、またはメタデータ記録に付加することによってその文書に関連付けまたは付着され得る。例えば、法律の判決例報告の場合、ヘッドノートまたはまとめが、作成および付加され得る。この材料は、手動でまたはある場合は、自動的に作成され得る。例えば、法律の判決例報告において言及される判例は、引用チェックされ、そして自動的に引用がアップデートされ得る。さらに、新たな文書が種々の分類属性１２４によってラベルされ得る。この属性は、いくつかの集合分類（例えば、管轄、トピックなど）についての指標として使用され得る。

（Ｂ．照会プロセスの外観）
情報小売は、種々の顧客関係に基づいて行うことができる。しかし、ほとんどの場合において、ある種の顧客契約が存在し、この契約は、顧客が購入したサブスクリプションまたはアクセス条項を定義し得る。この契約は、アクセスされ得る主題、アクセス時間などに関する制限を特定し得、そして料金を定義し得る。契約は、紙またはオンラインで締結され得、そして情報レポジトリのいかなる使用に十分先立って結ばれ得る。適切な支払いが確認されると、契約はまた、使用前にすぐに締結され得る。一旦情報プロバイダとユーザーとの間の契約関係が定義されると、ユーザーは、１または複数のリソースアプリケーションおよびそのユーザーインターフェースを介して少なくとも一部の共通コンテンツレポジトリに対するアクセスを有することになる。

本発明の一つの目的は、情報プロバイダが、共通のコンテンツレポジトリの部分へのアクセスおよび文書の送達について所望される本質的に任意の情報製品／サービスおよび顧客との関係を定義することを可能にすることである。従って、この関係は、多数のパラメータを含み得、これは、顧客によって変動し得、以下を含み得る：アクセスが許容されるコレクションまたはセット；アクセス時間、アクセス利用可能なユーザーまたは他のロード制限の数値；ユーザーに提示されるスクリーンの外観およびコンテンツ（これによって、ユーザーは、要求を照会し、そして結果を受け取る）；要求され得る文書の送達のモードおよび／または形式；および種々の使用形式の料金。従って、小売業者は、種々の関係を支持するリソースアプリケーションを開発して、システムが、種々の合意されたビジネス条項に適合するサービスを提供することを可能にすることを所望し得る。

リソースアプリケーションがどのようにして共通コンテンツレポジトリにアクセスするかの概観は有用である。まず、エンドユーザーがエンドユーザーの照会においてシステムから文書を検索する。図３に示されるように、これは、ユーザーメッセージ１２ａ、１２ｂ、、、１２ｎの形式である。多数のユーザーメッセージが、一日のどの時間でも、世界中のとこからでも（ただし、定義された顧客関係によって制限されない限り）同時にユーザーから入力され得る。ユーザーメッセージは、多数の異なる形式（例えば、検索（ｆｉｎｄ）、サーチ（ｓｅａｒｃｈ）、またはブラウズ機能）に適合され得る。例えば、あるユーザーが特定の情報（例えば、文書のタイトルおよび著者）を知っている場合、そのユーザーは、その特定の文書を検索するようにシステムに要求する。他方、ユーザーがある主題について一般的な情報を探している場合、そのユーザーは、サーチまたはブラウズを実行して、関連する情報を見出し、または照会を再検討する。これらは、リソースアプリケーション内で定義され得、そしてユーザーからシステムが受け取ることができる多数のタイプのユーザーメッセージの本の一例である。

各々のユーザーメッセージは、ユーザーによって、ＲＡユーザーインターフェース１０ａ、１０ｂ、、、１０ｎのうち１または複数を使用することによってシステムに入力される。各々のユーザーインターフェースは、ユニークな概観および感触を有し得、そしてユーザーが特定の種類の文書を検索することを容易にする。これは、使用されるユーザーインターフェースのタイプに依存する。例えば、法律文書を検索するためのリソースアプリケーションのユーザーインターフェースは、新聞記事を検索するために設計されてアユーザーインターフェースとは異なる文書にアクセスするように適合される。異なるアプリケーションのこれらのユーザーインターフェースは、おそらく、異なる概観および感触を有する。なぜなら、これらは、異なるタイプの文書にアクセスするように設計されており、そして異なるユーザープロファイルに対してアピールするからである。

要求がユーザーによってユーザーメッセージ１２ａ、１２ｂ、、、１２ｎとして入力された後、サーチコンポーネント２２を用いて関連する文書を見つける。サーチコンポーネントが、キーワードまたはフレーズを、ユーザーの要求によって使用して、関連する文書が配置される場所、および１または複数の文書を識別するサーチ結果メッセージを送信する場所を決定する。サーチコンポーネントは、究極には、各々の文書についてＧＵＩＤ識別子を見つける。このＧＵＩＤ識別子は、文書が、コレクションから容易に取り出されることを可能にする。いくつかの場合において、サーチコンポーネントは、実際の文書ではなく「ヒット」のリストを送達し、そしてさらなるユーザーメッセージは観察または他の送達のための特定の文書の選択を定義する。サーチコンポーネントは、さらに詳細に以下に記載される。

１または複数のデータコレクション３０ａ、３０ｂに格納される各々の文書は、ＧＵＩＤ制御コンポーネントのタイムスタンプコンポーネントから正確な時点（ＰＩＴ）１２０を伴って格納される。このＰＩＴフィールドは、実際のクロック時間値であり得るが、また、所定の文書について、単に特定のバージョンが他のバージョンに比較して意味づけされることを示す一連の識別子またはバージョンであり得る。例えば、バージョン識別子は、ＧＵＩＤ：ＧＵＩＤ．００、ＧＵＩＤ．０１、ＧＵＩＤ．０２などに基づいて構築され得る（これは、法律的文書について特に有用であり得る）。従って、文書または関連するデータが、経時的に改変される場合（例えば、関連するメタデータを加えるかまたは変更することによる）、ＰＩＴは、システムが、文書の最も現在のバージョンおよび関連するデータがユーザーに提示されているかどうかを検出することを支援し得る。また、文書の以前のバージョンがすでに提示されているにもかかわらず、文書のアップデートされたバージョンが、サーチ機能がその文書を発見したときに提示されることを可能にする。取り込み時間ＰＩＴに加えて、リソースアプリケーションは、この後者のアップデート機能について有用であり得る送達時間を追跡し得る。

一旦文書がデーベースから要求されると、文書送達コンポーネント４０を用いて、文書をユーザーに送達する。この送達コンポーネント４０は、文書を、リソースアプリケーションによって利用可能にされた中からユーザーが選択した形式およびモード（例えば、電子メール、ファクス、郵便）で文書を提示する。従って、送達されるときには同じ文書が、異なる概観および送達モードを有し得、これらの概観および送達モードに依存して、ユーザーインターフェースおよびリソースアプリケーションがそれに関して要求を受け取る。

図３に示されるように、データベースまたはデータコレクション３０ａ、３０ｂに格納される文書は、メタデータファイル５０ａ、５０ｂと関連付けられる。メタデータファイルは、各々の文書に関連する種々のさらなる情報を含み得る。この情報は、文書コンテンツ自体の一部ではないが、関連する文書についてのサーチの間にアクセスされ得、または文書自体と同時に送達のためにアクセスされる。

各々の新たな文書は、まず、取り込みコンポーネント６０によってデータベース３０ａ、３０ｂへと配置される。このデータベースは、定期的かつ頻繁に文書がアップデートされ、そして少なくとも文書のいくつかは、即座の発行が必要とされる。例えば、株式市況報告およびホットニュース記事は、可能な限り早く利用可能になるべきである。その関連性は、しばしば、短命であり、その価値は、そのタイムリー性に関連する。取り込みコンポーネントの優先度コンポーネント９０は、１または複数の優先度レベルを用いて処理のために入ってくる文書を優先度をつけて、特定のリソースアプリケーション（例えば、報告またはニュース事項の場合の時間発行利用可能性を約束するリソースアプリケーション）のために定義され得るリアルタイムまたは他の特定の利用可能な要件を用いて受け取り文書の時間順序から選択的に処理する。ＧＵＩＤ制御コンポーネント１００は、それがデータコレクション中の任意のユーザーに利用可能とされる前に、各々の文書に関する割り当てられた文書識別子のユニーク性をチェックし得る。取り込みコンポーネント６０はまた、ユーザーに利用可能な文書を作成する前に、所定の形式について文書をチェックし得る。これらのフィーチャは、データコレクション３０ａ、３０ｂに対してリリースされる文書がこのシステムによってアクセスされる準備ができることを確実にすることを支援する。

（取り込み処理）
図８は、取り込み処理をフローチャートの形式で示す。８０２において、システム５（図３）は、ソース（例えば、ニュースサービス、裁判所、市場データサービス）から送信されるファイルを受け取り、そして８０４において取り込みコンポーネント６０は、ファイルを送信形式から、取り込み処理により適切な形式へと変換する。８０６において、個々の文書が処理のために分離され、そして８０８において取り込みコンポーネントは、ソースによってすでに割り当てられたかもしれないまたはいまや割り当てられる必要があり得る優先度コードをサーチする。８１０において、文書が１または複数のキュー中に蚊ｋ脳され、優先度に従ってさらに処理される。８１２において、このシステムは、ファイル中のさらなる文書および／または受け取られるべきさらなるファイルについてチェックし、そしていずれかが存在する場合、適切な実行ポイントを返して、次の文書またはファイルを処理する。

８１４において、最高の優先度を伴う文書を選択することによって、別の処理リソースが文書のキューにアクセスする。８１６において、取り込みコンポーネントは、ソースによってすでに割り当てられてい得る（ＧＵＩＤのユニーク性を確実にせねばならないシステムに強調して）か、または今やユニーク姓を確実にする履歴およびアルゴリズムに基づいて割り当てられることを必要とし得るＧＵＩＤについてサーチする。８１８において、文書の格納フォーマットは、エンリッチメント８０を処理するための準備を確実にするために８２０においてチェックされる。

エンリッチメントコンポーネントを用いて、文書コレクション３０ａ、３０ｂにおいて配置されるように、各々の文書を増強することができる。エンリッチメントコンポーネントは、種々のフィーチャを各々の文書に加え、これは、１または複数のユーザーグループのための文書の価値を増大させる。エンリッチメントコンポーネントは、各々の文書を、以下のうち１または複数と関連付ける：人間のエージェントによって準備されたさらなる編集材料；自動化エージェントによって準備されたさらなる編集材料；このデータベース中の別の文書へのポインタを提供するリンク；またはメタデータファイルに出現する文書と関連付けられたエントリ。これらのエンリッチメントフィーチャは、エンドユーザーに対して、ある種類のさらなるコンテンツと組み合わされた個々の文書の形式で付加価値生成物を受け取ることを可能にする。種々の形式のエンリッチメントが、特定のユーザーに役にたち、そして特定の文書を送達するために使用されるリソースアプリケーション１５に依存して利用可能であり得る。

８２０におけるエンリッチメント処理の後、文書は、８２２においてメタデータ抽出コンポーネント処理に供され得る。この処理で得られるメタデータは、一般に、この文書を１または複数のコレクションへと接続するために重要なデータを抽出する工程を含む。従って、この文書のコンテンツを解析して、同じまたは異なるコレクションにおいて他の文書に対してこの文書の言語学的に洗練された分類を開発することができる。格納または検索を支援し、そして文書を改変またはカスタマイズして１または複数のリソースアプリケーションのフィーチャのための基礎を提供する、種々の形式のメタデータが開発され得る。

図８をなおも参照すると、メタデータが抽出された後、８２４において、文書がアクセスのためのリリースのその時間に対応するＰＩＴとともに格納される。８２６において、このシステムは、処理される優先キューにおいてより多くの文書が存在するかどうかを決定する。そうでない場合、文書プロセッサは、８２８において待ち状態へと移る。より多くの文書が存在する場合、制御は、実行点へと移り、その時点で、次の文書が優先キューから選択される。

新たな文書が配置される少なくとも１つのデータコレクションにおける文書は、少なくとも１つのコレクションサブセットへと区分され得、そして新たな文書を受け取るための取り込みコンポーネントが各々の追加の文書がユニークな識別しそして少なくとも１つのコレクションサブセットに割り当てられることを確実にし得る。別のデータコレクションは、少なくとも１つの文書セットを有し得、この文書セットは、１または複数のコレクションサブセットの文書のアグリゲーションである。

（エンリッチメントおよびメタデータ処理）
図９は、図８において言及された文書エンリッチメントおよびメタデータ抽出のプロセス９００のためのフローチャートを示す。９０２において、文書エンリッチメント処理のために使用されるコンポーネントは、制御を受け取り、そしてエンリッチメントのための文書を受け取る。９０４において、自動化されたエンリッチメントエージェントが適用され、そしてこのエージェントによって生成されるエンリッチメントフィーチャを使用して、文書を増強する。例えば、このエージェントは、新聞記事または事件の中で個人名または会社名についてサーチし得、次いで、文書をブラウズする個人によって相談され得る再度バーディスプレイのためのファイルを構築することができる。自動化されたエンリッチメントエージェントの適用の後、バイパス経路９０５〜ステップ９１０は、人間のエンリッチメントエディタの割り当てが必要でない場合に採られ得る。バイパス９０５が採られない場合、９０６において、文書は、再検討および編集のために人間のエンリッチメントエディタに割り当てられる。９０８において、人間のエンリッチメントエディタがさらに増強された文書と共にファイルを返す。９１０において、増強された文書は、メタデータ処理のために送達され、そして９１２において、メタデータ抽出コンポーネントは、送達された文書を受け取る。９１４において、自動化されたメタデータエンジンが文書に適用されて、メタデータが抽出され、そして９１６において、このメタデータファイルが収集され、そしてその文書と関連付けされる。例えば、抽出されたメタデータは、ＸＭＬデータまたはメタデータのレイヤに構築されたリソース・ディスクリプション・フレームワーク（ＲＤＦ）ステートメントの形式でメタデータのレイヤへと開発され得る。９１８において、この文書のためのメタデータファイルは、他の文書に関してメタデータファイルとリンク付けられる。例えば、メタデータ処理が、文書のいくつかの言語学的分類を生じる場合、表、インデックス、コンテンツ表または他のコレクションワイドのメタデータファイルが、この文書に由来する情報および／またはそれに対する参照とともにアップデートされ得る。９２０において、リソースアプリケーション条件付タグがメタデータファイルに付加され得る。これらは、特定のリソースアプリケーションによって用いられて、特定のリソースアプリケーションによって供給される文書リソースサービスにおいて含めるのかまたは排除するためにメタデータをタグ付けする。いくつかの場合において、メタデータは、リソースアプリケーションによってアクセス可能なタグの存在または非存在に基づいて、サーチまたはディスプレイから排除される。

９２２において、メタデータファイルが格納される。これらは、文書と関連付けられて（ｃｏｕｐｌｅ）格納され得るか、または関連付けられずに格納され得る。すなわち、物理的な関連付けまたは単に論理的な関連付けが存在し得る。９２４において、このシステムは、ファイル（または部分）を候補としてマークし、または将来のメタデータの付加のための候補としてではなくそのファイルをマークする。この将来のメタデータは、文書使用パターンを経時的に統計学的またはヒューリスティックな規則解析の使用によって派生され得る。メタデータを格納すると共に、処理される文書は、ユーザーアクセスのために準備ができるようになるが、関連するメタデータは後に変更され得る。このシステムが、使用パターンを追跡および解析するためのエージェントを有する場合、このマーキングは、適切な場合この文書の使用が追跡されること、および結果（例えば、図６における使用メタデータ１５４）が記録されることを確実にし得る。さらに、使用パターン情報が開発されるにつれ、メタデータは、文書取り込みがアップデートされ得る時間に格納され得る。例えば、この文書が頻繁に、観察されるサーチパターンの部分である場合、メタデータファイルは、生じた一連のサーチにおいて近似する他の文書を反映するようになり得、その結果、同じ一連のサーチに沿ってユーザーが後に導くことを支援する。９２６において、エンリッチメントおよびメタデータ抽出コンポーネントは、システムに制御を戻す。

メタデータは、情報オブジェクトへのアクセスを構成、記述、追跡および他の様式で増強するように作成される付加価値情報である。以下により詳細に説明されるように、本発明において、とりわけ、メタデータは、コンテンツの表、フィルタリングまたは他の操作によって得られるコンテンツ表の派生物、ユーザー追跡情報から派生する使用パターンデータ、重複検出のために開発された文書シグネチャ、およびトークンインデクシングの形式で開発される。文書の大きなアグリゲーションにおいて、メタデータは、ヒエラルキー形態であり得、ここで、より高いレベルのメタデータは、より低いレベルのメタデータの意味を解釈するにおいて支援するように開発され得る。他の状況において、メタデータは、非ヒエラルキーであるがそれにもかかわらず他のメタデータに関してリンクまたは他の非ヒエラルキー形態の指摘手段によって関連付けられるメタデータである。次に記載されるコンテンツ表は、付加価値メタデータを開発するためのプライム機会を提供する。

（コンテンツ表（ＴＯＣ）構築）
１つの形態のメタデータプロセシングは、コンテンツ表（ＴＯＣ）構築である。本発明において実行されるように、ＴＯＣは、２つの異なるコレクションタイプが定義されることを必要とする。ＴＯＣコレクションは、ＴＯＣヒエラルキー関係を含む。文書（ＤＯＣ）コレクションは、文書を含む。ＴＯＣは、１、２または多数のＤＯＣコレクションにおいて文書を参照することができる。恒常的なＧＵＩＤは、現在のＴＯＣ設計の利益を達成するための要件である。システムが多数のタイプの情報をユーザーに提供する場合、それは、代表的には、各々のタイプの情報について少なくとも１つのＴＯＣを有する。

ＴＯＣヒエラルキーは、共通のコンテンツレポジトリー中に１つのコレクション中に存在し、そして文書に対する参照を含む。参照される文書は、１または複数のＤＯＣコレクション中に存在する。コレクションセットを用いて、単一のＴＯＣコレクションとＤＯＣコレクション（単数または複数）とを結びつける。このＤＯＣコレクションは、参照される文書を含む。図１０は、ＴＯＣアーキテクチャの模式的外観である。以下は、ＴＯＣの実行についてのさらなる詳細である。

ａ．ローディングデータ。ＴＯＣデータをＴＯＣコレクションにロードする。ＤＯＣデータを、ＤＯＣコレクションにロードする。ＴＯＣコレクションおよびＤＯＣコレクションの両方は、同時に、ローディングデータであり得る。ＴＯＣおよび文書データをｓｙｎｃ（同期）に維持するために、同期プロモートが、多重コレクションの同期を促進することをクライアントに可能にするために利用可能である。

ｂ．ＴＯＣノードに基づくサーチの制限。「ｎ−ｔｏｃｖｉｅｗ」エレメントが文書データロードに加えられて、ＴＯＣサーチ−クエリ−ビュー制限を支持する。この「ｎ−ｔｏｃｖｉｅｗ」１２７（図６）は、クライアントが文書と関連付けることを希望するＴＯＣ ＧＵＩＤを含む。以下は、図１１Ａにおいて単純化したサンプルＴＯＣ構造をアップデートするために使用されるＸＭＬの例である。ここでは、陰付ノードは、文書「ｄ２」を指摘するＴＯＣノードを表す。

。

注意。ｎ−ｔｏｐｖｉｅｗ中で特定されるＧＵＩＤは、共通のコンテンツレポジトリによって、コレクションセット内に存在することも、関連情報であることがベリファイされていない。

ｃ．ラッパーＡＰＬ。コレクションセットを用いて、ＴＯＣコレクションをＤＯＣコレクション（単数または複数）に結びつける。このＤＯＣコレクションは、参照される文書を含む。ラッパーＡＰＬは、コレクションまたはコレクションセットと共に用いるためのＴＯＣ ＡＰＩを含む。コレクションセットは、ラッパーＡＰＩが使用され得る単一の点を提供する。

ｄ．ＴＯＣ ＸＭＬ。ＴＯＣノードは、ｎ−ｎｏｄｅエレメントによって作成、アップデートおよび削除される。各々のｎ−ｎｏｄｅエレメントは、ＴＯＣノードを記述する情報を含む。ＴＯＣデータは、（文書のように）トークンインデクシングされておらず、従って、共通のコンテンツレポジトリによってサーチ可能ではない。ｎ−ｔｏｐｖｉｅｗ情報がその文書内に配置され得、従って、サーチのためにインデクシングされ得る。

ｎ−ｎｏｄｅは２つの属性を有する：
ｇｕｉｄ−ＴＯＣノード
ＧＵＩＤ
ｃｏｎｔｒｏｌ：起こるべき動作を示す。

（表）
値 ｜動作の記述
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
「ＡＤＤ」 ｜ＴＯＣノードをこの段階で加える
「ＤＥＬ」 ｜ＴＯＣノードをこの段階から削除する
「ＤＥＬＢＲＡＮＣＨ」 ｜ＴＯＣノードおよびこの段階について
｜すべてのＴＯＣノードの子を削除する。

ｎ−ｎｏｄｅは、以下のエレメントを有する：
ｎ−ｐａｒｅｎｔ−ｇｕｉｄ：親ノードのＧＵＩＤ。ルートノードは、このエレメントを含まない
ｎ−ｄｏｃ−ｇｕｉｄ：このＴＯＣノードが文書を参照する場合の文書のＧＵＩＤ。ＴＯＣノードは、ゼロを有し得るか、またはそれに関連する１つの文書を有し得る。このエレメントにおける任意のコンテンツは、ＴＯＣノードが文書を参照することを示す
ｎ−ａｎｃｈｏｒ−ｇｕｉｄ：このＴＯＣがアンカを参照するときのアンカのＧＵＩＤ
ｎ−ｌａｂｅｌ：５９８バイトのサイズ制限を伴うテキストフィールド
ｎ−ｒａｎｋ：ランク順序で表示するためのアプリケーションのためのＴＯＣノードをソートするために用いられる実数
ｎ−ｎａｍｅ：アプリケーションに対して通過して戻るＴＯＣノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内にＴＯＣ定義に対する意味を有しない。ｎ−ｎａｍｅに対する最大値は、２０バイトである
ｎ−ｖａｌｕｅ：ｎ−ｎａｍｅ値を伴うアプリケーションに対して通過して戻るＴＯＣノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内のＴＯＣ定義に対して意味を有しない。ｎ−ｖａｌｕｅの最大値は、２００バイトである
ｎ−ｍｅｔａ−ｄａｔａ：ＴＯＣに関するメタデータの情報を含む。

ｅ．ＴＯＣ ＤＴＤ

ｆ．ＴＯＣおよび文書ＸＭＬの例。図１１Ｂを今度は参照すると、陰付ノードは、文書を参照するＴＯＣノードを表す。２つのＴＯＣノードは、文書「ｄ１」を参照する。ＴＯＣノード「ｎ７」は、「ｎ５」のアンカーである。

留意点：
文書「ｄ１」は、＜ｎ−ｔｏｃｖｉｅｗ＞ｎ１、ｎ２ ｎ４ ｎ３ ｎ６＜／ｎ−ｔｏｃｖｉｅｗ＞の組み合わせｎ−ｔｏｃｖｉｅｗを有し得る。文書内に含まれるアンカーは、クライアント特異的なタグで特定される。システムは、アンカーが要求するタグを文書内に含まない。

ｇ．ｎ−ｎｏｄｅに関するルールのアップデート
１．重複するＧＵＩＤはない。ＧＵＩＤは、２回加えられず、削除もされず、そして同じロードにおいて加えられる。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
２．定義されるｎ−ｎｏｄｅは、置き換えられるノードである。ｎ−ｎｏｄｅがＸＭＬで定義される場合、ｎ−ｎｏｄｅにあるすべての情報は、再定義される必要がある。このデータのロードは成功する。このノードは、最新の定義のみを反映する。
３．子なしのｎ−ｎｏｄｅは削除機能とともに削除され得る。この条件が満たされない場合、このロードは、データエラーと共に失敗する。
４．ブランチの削除は、ｎ−ｎｏｄｅおよびすべてのその子ノードが削除されたことを示す。
５．削除したブランチのｎ−ｎｏｄｅは、改変され得ず、ブランと削除として同じロードに加えられ得ない（規則１を参照のこと）。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
６．ｎ−ｎｏｄｅの親ｇｕｉｄは、既存のノードでなければならない。この条件が満たされない場合、ロードは、データエラーと共に失敗する。（既存のノードは、すでにＴＯＣ中に存在するノードであるか、または現在のロードに存在するノードである。ノードは、ランク順序によりロードされる必要はない。欠失するノードのべリフィケーションは、ロードプロセスの最後に起こる。しかし、よりよいロード速度は、ノードをヒエラルキー（ランク付け）様式でロードする場合に起こり得る）。

ｈ．ＴＯＣローディングでの使用の場合
以下は、ＴＯＣの実用的な含意を示す使用の場合である。これらの実施例の大部分は、図１１ＣのＴＯＣ構造に基づく。この同じ構造は、上記ＸＭＬの例において用いられた。
１．大きなデータはどのようにしてＴＯＣ構造を用いてロードされ得るか？例えば、５０ギガバイトの生データをロードし、所定のコレクションについて５００メガバイト／時の速度でロードできるとしよう。１つのＴＯＣおよび３つの文書コレクションが使用される場合、この同じデータは、１日より若干長い時間でロードすることができる。クライアントが文書データを多数のコレクションに分断したい場合、データは迅速にロードされ得る。
２．ＴＯＣからブランチはどのようにして削除され得るか？本発明者らの実施例を用いてノード「ｎ２」に始まるＴＯＣブランチを削除し、そしてまた、ノード「ｎ２」のもとでいかなるノードをも削除するとしよう。文書「ｄ２」は、ＴＯＣ中でもはや参照されない。文書は、「ｄ２」について欠如が共通コンテンツレポジトリに渡されない限り、削除されない。以下は、「ｎ２」で始まるブランチを削除するためのＸＭＬである。

以下は、文書「ｄ２」を削除するためのＸＭＬである。

３．文書「ｄ１」のテキストはどのようにして変更可能か？
文書「ｄ１」を新たな文書データおよびＴＯＣサーチ制限を許容するｎ−ｔｏｃｖｉｅｗ情報とともにリロードする。以下はそのＸＭＬである。

４．ＴＯＣノード「ｎ４」のラベルは変更可能か？
ＴＯＣノード「ｎ４」を、新たなラベル情報と共にリロードする。この同じ例は、ＴＯＣランク、名称、値またはメタデータのフィールドを変更する場合にも機能する。以下は、そのＸＭＬである。

５．文書「ｄ３」は、どのようにして削除され得、そしてノード「ｎ３」をどのようにしてＴＯＣ中に残し得るか？
文書「ｄ３」について削除命令を送信し、そしてＴＯＣノード「ｎ３」を最適議して、文書「ｄ３」に対する参照を含ませないようにする。以下はそのＸＭＬである。

６．文書「ｄ１」は、どのようにして削除され得、そしてそれを参照するすべてのＴＯＣノードを以下にして除去し得るか？文書「ｄ１」についての削除命令を送信し、そしてノード「ｎ４」および「ｎ６」についての削除命令を送信する。以下はそのＸＭＬである。

７．新たなＴＯＣノード「ｎ７」を、ＴＯＣノード「ｎ１」と「ｎ３」との間にどのようにして挿入し得るか？新たなＴＯＣ構造は、図１１Ｄのようである。文書「ｄ１」および「ｄ３」を新たなｎ−ｔｏｃｖｉｅｗとともにリロードして、ＧＵＩＤ「ｎ７」をクエリビュー制限として支持する。「ｎ７」について新たなＴＯＣノードも作成し、そしてＴＯＣノード「ｎ３」を再定義して、「ｎ１」の代わりに「ｎ７」を指し示すようにする。以下はそのＸＭＬである。

まとめると、ＴＯＣは、文書に関するヒエラルキーメタデータを格納するための構造を提供する。ＴＯＣは、ノードからなる。ＧＵＩＤはノード、親ノード、参照される文書およびアンカーを識別する。ＴＯＣを構築するためのすべての入力は、ＸＭＬである。ＴＯＣは、再帰的構造であり得る。これは、ノードのｎ−ｄｏｃ−ｇｕｉｄが、文書のＧＵＩＤの代わりにＴＯＣノードのＧＵＩＤを含む場合に起こる。次いで、ＴＯＣノードは、ＴＯＣノードを参照する。ＴＯＣ中のノードラベルの語彙は、メタデータＲＤＦステートメントに関する語彙として使用することができる。

文書は、いっときに任意の点において、たった一つのＤＯＣコレクション中に存在し得る。しかし、文書は、ＴＯＣとともに多重の位置において表され得る。１または複数のＤＯＣコレクションからの文書は、１つのＴＯＣにおいて表され得る。

ＴＯＣヒエラルキーデータは、ＴＯＣコレクション中に格納される。文書データは、１または複数のＤＯＣコレクション中に格納される。特定のＴＯＣは、１つのコレクション中に存在する。ＴＯＣコレクションが参照するＴＯＣコレクションおよび１または複数のＤＯＣコレクションは１つのコレクションセットにより互いに結び付けられる。図１２は、２つの文書（ラベルしたＤＧ１およびＤＧ２）を参照する単純化したＴＯＣのサンプルを示す。

本発明のＴＯＣ設計は、多数の有用な特徴を許容する。

ＴＯＣナビゲーション：ＡＰＩを提供して、ＴＯＣのノードをナビゲートする。以下のサンプル操作は、そのようなＡＰＩを通じて実行され得る：ＴＯＣのルートノードを検索し；ノードを与え、その子を検索し；ＴＯＣサーチ結果およびＴＯＣノードを与え、ＴＯＣの順序で次または前のノードを検索し；そしてノードを与えその親を検索する。

ヒットを伴うＴＯＣ：サーチが文書ヒットを得たとき、これらを併せて各々のＴＯＣノードにおけるヒット数をリターンする。

フィルタリングしたＴＯＣ：リソースアプリケーションがサーチおよびＴＯＣノードに対して参照を送信するとき、そのサーチに適合しないＴＯＣの部分は、除去される。リソースアプリケーションがサブスクリプションハンドル（サーチに基づく制限、サブスクリプションに基づく）に対する参照を送信するとき、そのサブスクリプション基準に合わない任意のＴＯＣが除去される。

ノードを見出す：リソースアプリケーションが、名称および／または値に対する参照を送信するとき、ＴＯＣは、関連するノードをリターンする。

ＴＯＣアンカー：アンカーを用いて文書内のヒエラルキーを反映させることができる。

（インデクシング）
メタデータプロセシングのための準備として、文書を、インデックスファイルの作成により正常にインデクシングさせる。そのようなインデックスファイルは、トークン化、ストップ、ステミング、大文字使用の除去、および逆返還（ｉｎｖｅｒｓｉｏｎ）によって従来の様式で誘導させる。米国特許第６，３８９， ４１２号を参照のこと。メタデータ抽出に対するインデクシングプロセスの関係は関心の対象とされ得る。インデクシングは、意味情報のいくつかの喪失を生じることから、インデクシングは、ある文書コレクションについては所望されないかもしれない。他のコレクションにおいて、インデクシングは受容可能であるが、抽出されるべき情報が、インデクシングにおいてその全体または部分が喪失する特徴を伴う場合インデクシング形式ではない文書に基づいてメタデータ抽出を行うことが最良である。メタデータは、インデクシングされてもよくされなくてもよい。１つの実施形態において、ＴＯＣデータは、インデクシングされず、従って、インデクシングに依存するサーチエンジンによってサーチ可能でない。しかし、ユーザーが以下に詳細に説明するように探索することは可能である。

データコレクション中の文書は、少なくとも１つのコレクションサブセットに区分され得る。このシステムは、コレクションサブセット中に少なくとも１回出現するキーワードのインデックスを維持するインデックスサービスを有し得る。ここで、インデックス中のキーワードとそのコレクションサブセット中の出現の位置との関係が存在する。

（コンポーネント実行のビュー：概説）
図４は、上記に示されたかまたは記載された高レベル機能エレメントを実行するメインコンポーネントを示すブロック図である。メインコンポーネントは、ウェブサーバー２００、アプリケーションリソース（ＡＲ）サーバーコンポーネント３００、および１または複数のリソースアプリケーションを備える。ウェブベースのシステムにおいて、ＣＣＲＤサーバー４００およびＡＲサーバー３００は、クライアントとしてリソースアプリケーションとともにサーバーとして動作する。具体的には、ＣＣＲＤサーバー４００は、データベース（コレクション）サーバーおよびウェブサーバー２００およびＡＲサーバー３００が、それぞれウェブおよびアプリケーションのサーバーである。他のシステムコンポーネントは、オンラインビジネスシステムサービス５００およびビジネスシステム６００およびパブリシングＡＰＩ７００である。ビジネスシステム６００内には、オンライン決済およびＳＡＰコンポーネントが存在する。

ＡＲサーバー３００コンポーネントは、ＣＣＲＤＳサーバー４００レポジトリに存在する文書にアクセスする、ウェブベースのリソースアプリケーションを配備するために使用されるアプリケーションフレームワークを提供する。このフレームワークは、ユーザーがサブスクライブし得る新たなるソースアプリケーション（例えば、ニュースサービス、法律サービスなど）の迅速なターンアラウンドを提供する。１つの実施形態において、ＡＲサーバーコンポーネントは、Ｊ２ＥＥコンテナにまたがって使用され得るシリアル化可能なオブジェクトを提供する。

多数のリソースアプリケーションにわたる共有される顧客情報を提供することについて多大な利益およびシステムの能力は、共有されるＡＲサーバーコンポーネントの最大限の使用を伴って生じるが、アプリケーションは、必ずしも、サーバー構造によって提供されるすべての機能を利用するとは限らない。図４のサーバー構造の他の利点のいくつかとしては、再利用可能性、新たなまたはアップデートされたアプリケーションの市場に対する時間の速度および新たな製品開発のためのコストの減少を挙げることができる。

一般的に、ＣＣＲＤＳサーバー４００コンポーネントは、電子的に格納され、インデクシングされ、そしてソートされる文書の大きな集合に対するアクセスを提供する。これらの文書は、共通のコンテンツレポジトリに加えられ、そしてより簡単な検索および付加価値コンテンツを可能にするために増強される。リソースアプリケーションを通じて文書をユーザーがサーチまたは要求するとき、ＣＣＲＤＳサーバー４００は、ＡＲサーバー３００と相互作用して効率よい様式でサーチ結果または文書を提供する。ＣＣＲＤＳサーバー４００は、多数の道具を利用して、文書を増強する。これらの道具は、以下により詳細に記載される。

一般的に、ＡＲサーバーコンポーネント３００は、ウェブベースのリソースアプリケーションを配置するために用いられるアプリケーションフレームワークを提供する。このコンポーネントは、共通のサービスおよびツールフレームワークを実行する。このサービスおよびツールフレームワークは、ＣＣＲＤＳサーバー４００を用いて文書を検索する各々のリソースアプリケーションについて開発時間およびコストを減少させる。従って、新規リソースアプリケーションは、ビジネス部門がテーラーメイドのインターフェースを簡単かつ迅速に作ることを可能にし、他方で、データおよびサービスの集中処理されたコアにアクセスできるようになる。さらに、ＡＲサーバー３００コンポーネントは、種々のアプリケーションにわたって顧客に関する情報を共有することを促進する。１つの実施形態において、フレームワークは、アプリケーション開発（例えば、Ｊａｖａ（登録商標）２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ））に対するセットモデルおよび他の推奨されるガイドラインを確立する。

フレームワークは、アプリケーションプログラムインターフェース（ＡＰＩ）を提供し、ＨＴＭＬまたはＸＭＬのような包括的マークアップ言語を生成するが、しかし、リソースアプリケーションのアプリケーション開発者は、ＸＭＬスタイルシートまたはＪａｖａ（登録商標）オブジェクトが、包括的ＨＴＭＬまたはＸＭＬを、このリソースアプリケーションによって要求されるフォーマットに変換するか否かのインターフェースを提供する。共通サービスおよびツールがＡＲサーバーコンポーネント３００によって提供され、それ故、各リソースアプリケーションがこれらサービスを個々に開発する必要性をなくする。

各リソースアプリケーションは、ユーザーに、特定のマーケット中で、ドキュメントを位置決めかつ回収するための仕立てられた製品を提供するように設計された特有のアプリケーションである。上記で説明されるように、リソースアプリケーションは、ＡＲサーバー３００によって提供される特別のサービスおよびツールを利用し、ＣＣＲＤＳサーバー４００によって管理されるドキュメントの大きな共通のコンテンツレポジトリーにアクセスする。１つ以上のリソースアプリケーションが、ＡＲサーバー３００およびＣＣＲＤＳサーバー４００と同時に相互作用し得、同じドキュメントをアクセスかつリクエストする；しかし、このドキュメントは、このドキュメントを送達するために用いられるリソースアプリケーションに基づく特有のルック＆フィールで提供され得る。

各リソースアプリケーションは、ＨＴＭＬ、ＪＰＥＧイメージ、Ｊａｖａ（登録商標）Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＪＳＰ）、Ｓｅｒｖｌｅｔｓ、カスタムスタイルシートなどのようなそれ自身のインターフェースコンポーネントを有して開発されている。しかし、ユーザーと通信するためにカスタムツールおよびサービスを利用する各リソースアプリケーション１５（図３）の代わりに、プロセスＵｓｅｒ Ｍｅｓｓａｇｅは、共通のコンテンツレポジトリーに記憶されたドキュメントにアクセスし、そして情報小売取り扱いのためのすべてのその他のビジネスルールを適用し、このＡＲサーバー３００およびＣＣＲＤＳサーバー４００は、各リソースアプリケーションが予めプログラムされたツールおよびサービスを利用することを可能にする標準的コンポーネントを有している。例えば、ＡＲサーバー３００のＳｅｃｒｕｒｉｔｙコンポーネントは、各リソースアプリケーションが、同じセキュリティ特徴を利用することを可能にし、なお各々は、アプリケーションを開発するために選択されたコンポーネントに依存して、異なるフォーマットでセキュリティ特徴を提示し得る。ＡＲサーバー３００およびＣＣＲＤＳサーバー４００により提供される種々のツールおよびサービス、およびこれらが種々のリソースアプリケーションとどのように相互作用するかは、以下に記載される。

ＡＲサーバー３００は、企業を横切るフェブアプリケーションを構築するための共通アーキテクチャー／インフラストラクチャーモデルを提供する。ＣＣＲＤＳサーバー４００は、サーチ、ドキュメント送達、およびＴａｂｌｅ ｏｆ Ｃｏｎｔｅｎｔｓのための再利用可能なバックエンドを提供する。ＡＲサーバー３００は、ウェブアプリケーションのために同じ再利用可能性を提供する。

（ＣＣＲＤＳサーバー）
ＣＣＲＤＳサーバー４００は、新規ドキュメントの導入および現存するドキュメントの回収を容易にする共通コンテンツレポジトリーおよび管理システムである。ＣＣＲＤＳサーバー４００は、ドキュメントを入力し、豊富にし、見出しおよび回収するための以下のユーティリティを含む：サーチエンジン、Ｔａｂｌｅ ｏｆ Ｃｏｎｔｅｎｔｓ（ＴＯＣ）、Ｄｏｃ、Ｕｔｉｌｉｔｙ、ＣＣＩ、Ｌｏａｄ Ｍａｎａｇｅｍｅｎｔ、Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ、およびＬｏｇｇｉｎｇ。

（サーチエンジン）
サーチエンジンは、ドキュメントを異なる方法で位置決めするための多くのツールを提供する。例えば、サーチ（Ｓｅａｒｃｈ）、ＦｉｎｄおよびＢｒｏｗｓｅ操作が提供され得る。

このサーチ操作は、ユーザーが、Ｕｓｅｒ Ｍｅｓｓａｇｅに応答して、共通コンテンツレポジトリーからのクエリーを満足する適正な質問の単一または複数「ヒット」を提供する。一般に、ユーザーインターフェースは、ユーザーを勧誘してクエリー事項を特定し、そして所望のコンテンツコレクションおよび／またはコンテンツタイプをＳｅａｒｃｈ操作の一部分として選択するようにする。Ｓｅａｒｃｈ操作のユーザーは、オンライン−サーチ機能性について異なる能力および理解を有し得る。所有のサーエンジ製品などで先の経験を有するユーザーも居れば、Ｉｎｔｅｎｅｔサーチエンジンで経験を有するユーザーも居る。ユーザーインターフェースは、このような経験をもつ者に親しむように設計され得る。

Ｓｅａｒｃｈの１つの使用は、ＢｏｏｌｅａｎオペレーターでのＱｕｅｒｙ Ｔｅｒｍによる情報のサーチを含む。このユーザーは、クエリー事項（単数または複数）をクエリーボックスに入れ、そしてＲｅｓｕｌｔリストが、この事項（単数または複数）を含むドキュメントを含むという期待を有する。ここで、ユーザーは、事項およびＢｏｏｌｅａｎオペレーターでクエリーを構築することを欲する。このユーザーは、すべてのＢｏｏｌｅａｎオペレーターが支持されている、すなわち、かれらが、サーチエンジンによって認識され、しかもクエリー−ストリングの条件を満足するドキュメントのみが回収されるという期待を有する。

Ｂｏｏｌｅａｎ言語サーチは、「フィールド情報」の使用を経由して拡張され得る。この技法は、ユーザーが、特定のメタデータおよびデータのコンテンツ属性をサーチしこのサーチをさらにフィルターにかけることを可能にする。代表的なフィールドは、種々のタイプのドキュメントデータ、著者、タイトル、刊行物、トピック分類などのような項目を含む。

トピックによるサーチ（そこでは、トピックスが、編集プロセスにより進んで割り当てられた特定のドキュメントをともなう）は、Ｂｏｏｌｅａｎサーチに対するＦｉｅｌｄｅｄサーチの拡張を用いて達成されるが、より便利なサーチとして同じ方法でユーザーに曝されなくてもよい。フィールドはまた、コンテンツコレクションに極めて特異的である、例えば：事例に対するパーティ、ジャッジ、ドケット番号などに拡張され得る。

サーチの別の方法は、自然の言語を用いる情報に対するＳｅａｒｃｈを用いることである。ここで、ユーザーは、自然の言語の構文でクエリー項目を入力することを欲する。例えば：「保険詐欺」。Ｎａｔｕｒａｌ Ｌａｎｇａｇｅサーチャーから戻るサーチ結果は、文構築構文を省略して、サーチの事項に関する関連性を有することが期待される。例えば、上記のサーチでは、戻る結果は、用語「保険詐欺」を含むべきである。

アラート（Ａｌｅｒｔ）として知られる混合Ｓｅａｒｃｈ機能が提供され得、ここでは、ユーザーは、それらの実施の領域（単数または複数）に関連するなにかが変更されたか、新たな情報があるとき、アップデートすることを欲する。ユーザーは、定期的ベースで自動的に稼動するサーチアラートのポートフォリオをセットアップする。各アラートは、特定の規定された間隔で特定のコンテンツコレクションに対して特定のサーチを走らせるためにセットされる。各アラートは、規定されるべき特定の属性を可能にする。サーチャーには、これらの属性は、例えば、クエリー事項、コンテンツコレクション、主題の領域などを含み得る。ユーザーは、複数のアラート、および各アラートについてそれらのポートフォリオにおける頻度のストップ、スタート、削除または変更を規定することができるべきである。このアラートサービスによって見出されたドキュメントは、従来のクリッピングサービスの様式で送達され得る。

このＦｉｎｄ操作は、ユーザーがコンテンツコレクションから単一のドキュメントを回収することを可能にする。一般に、ユーザーは、司法のような特定の分野、カテゴリーまたは領域、またはＦｉｎｄ操作の一部分として実施領域を特定することを要求されるべきではない。Ｆｉｎｄ操作のユーザーは、ドキュメントが存在するという予備知識を有し、そしてその特定のドキュメントにアクセスすることを希望する。このようなユーザーは、例えば、サイト、タイトル、関与するパーティ、またはドキュメントの共通名のようなそのドキュメントに特異的な情報を識別する。

特定の参考は、特定のドキュメントを記載するには不十分であるかもしれない。このタイプの問題は、同じドキュメントの複数テキスト、異なる言語の同じドキュメント、または特定の引用略語の異なる供給源で生じる。例えば、略号「ＡＬＲ」は、ＡｍｅｒｉｃａｎとＡｕｓｔｒａｌｉａｎとのＬｅｇａｌ Ｒｅｐｏｒｔ刊行物の間を区別するには不十分である。このような場合、このＦｉｎｄ操作は、この参照に適合する特定のドキュメントのすべてのバージョンを回収し、そしてユーザーが目的の特定のドキュメントを選択することを可能にする。

このＦｉｎｄ操作は、ＳｅａｒｃｈまたはＢｒｏｗｓｅとは異なる。Ｆｉｎｄは、ユーザーが単一の特定のドキュメントにアクセスすることを可能にする。Ｓｅａｒｃｈは、ユーザーがかれらが規定する規準のセットに適合するドキュメントについてコレクションを走査することを可能にする。Ｂｒｏｗｓｅは、ユーザーが、かれらの必要性に適合し得るドキュメントの分類学を通じて精選する。

Ｆｉｎｄコマンドにまた含まれて、ユーザーが、ドキュメントまたはそのメタデータの１つ以上の属性を特定することによりドキュメントを回収することを可能にする、Ｆｉｎｄ ｂｙ Ａｔｔｒｉｂｕｔｅ操作がある。Ｆｉｎｄ ｂｙ Ａｔｔｒｉｂｕｔｅ操作の例は：Ｆｉｎｄ ｂｙ Ｔｉｔｌｅ、Ｆｉｎｄ ｂｙ Ｐａｒｔｉｅｓ（パーティに参加することにより調べる）、およびＦｉｎｄ ｂｙ Ｃｏｍｍｏｎ Ｎａｍｅがある。

アプリケーションに依存して、Ｆｉｎｄ操作を走らす前に、プレフィルターをセットアップすることが適切であるときがしばしばある。このようなフィルターは、ユーザーがＣｏｕｎｔｒｙコード、Ｌａｕｇｕａｇｅ、Ａｐｐｌｉｃａｔｉｏｎドメイン、Ａｐｐｌｉｃａｔｉｏｎで規定されるコンテンツセット、Ｃｏｎｔｅｎｔタイプ（法律、規則、税金、ニュース）、Ｐｒａｃｔｉｃｅエリア、Ｊｕｒｉｓｄｉｃｔｉｏｎ、Ｃｌａｓｓｉｆｉｃａｔｏｎ区画などにより結果を制限することを可能にし得る。ユーザーは、かれらが、より広いコンテンツベース内でドキュメントを見出すことを希望する場合、このようなデフォールトフィルター属性を置き換えることができるべきである。

Ｆｉｎｄ操作は、その他の操作とパイプラインされ、特有の新規操作または製品を生じる。例えば、Ｆｉｎｄ操作の出力は、直接プリントに送られ得るか、またはｅメールサーバーに押され、単一ドキュメントの送達を生成する。ユーザーのプロフィールは、非特有の結果の数を制限するために、複数のコレクションに対して進行するＦｉｎｄ捜査のために、デフォールトと自動プレフィルターのセットを含んで用いられ得る。

Ｆｉｎｄ操作の履行のためのデータ要求は、設計時間の間のコンテンツアプリケーションについて決定されるべきである。このアプリケーションは、Ｆｉｎｄ機能性を提供するために十分な、規準化されたかつ正規の名、参照および各ドキュメントのついての情報を提供し得る。

サーチレベルでは、Ｆｉｎｄは、Ｓｅａｒｃｈ操作と類似である。一般に、Ｆｉｎｄは、履行および／またはユーザーインターフェースである。ユーザーの視点からは、Ｆｉｎｄは、Ｓｅａｒｃｈが操作が、条件のクエリーに適合する１つ以上の可能なドキュメントについてコンテンツコーパスを走査し、そしてそれでエンドユーザーに異なるタスクモデルを提示する間に、コンテンツコーパスから既知のドキュメントをどうにか引かなければならない。

（Ｔａｂｌｅ ｏｆ Ｃｏｎｔｅｎｔ（ＴＯＣ）機能）
ＣＣＲＤＳサーバー４００により提供されるＴＯＣ機能は、コンテンツのペーパーブックテーブルの電子バージョンであるが、ドキュメントへの頭だしレベルおよびドキュメントへのリンクすることの拡張／押し縮めを可能にする適切な技法で増大される。ＴＯＣは、階層のトップのルートノード、随意の中間ブランチおよびターミナルエンドのリーフノードから構成される。リーフノードは、ドキュメントまたはドキュメント内のセクションに単一にリンクしている。

Ｂｒｏｗｓｅ Ｔａｂｌｅ ｏｆ Ｃｏｎｔｅｎｔ（ＴＯＣ）操作は、ユーザーがコレクションのコンテンツの階層図を追求することを可能にする。コレクションは、１つ以上のドキュメントから構成され得るので、対応するＴＯＣは、複数ドキュメント、単一ドキュメント、または特定のドキュメントのサブセクションのためのＴＯＣを提示し得る。逆に、ドキュメントの単一コレクションは、複数のＴＯＣを有し得る。ＴＯＣは、特定のユーザータイプおよびそれが参照する特定のＤＯＣコレクションに適合され得る。

ＴＯＣをブラウズする間、ユーザーは、かれらが見出すことを試みる特定のドキュメントの予め存在する知識を有し得：かれらは、法律および／または実施の親しみのない領域に関する指針を捜し得；またはかれらは、ＴＯＣを用いて論点または問題を補助して作成し得る。ＴＯＣによりアドレスされるコンテンツコレクションが１つのドキュメントであるとき、そのときは、関連するＴＯＣは、ドキュメントの構造を反映し得る。ユーザーは、大きなドキュメント、例えば、Ｌｅｇｉｓｌａｔｉｏｎを航行するためにこのタイプのＴＯＣを必要とする。

同様に、コンテンツコレクションが、複数のドキュメント、例えば、Ｊｏｕｒｎａｌ Ａｒｔｉｃｌｅｓ、Ｓｔａｔｕｔｅｓ、またはフォームを含むとき、ＴＯＣは、各ドキュメントの存在を示して生成され得る。これは、ユーザーが適切なドキュメントをブラウズかつ選択し得るためにすべてのドキュメントのリストを必要とするための重要な特徴である。

ＴＯＣブロウジング機能は、リンクされた材料の航行アクセスを含む。航行には、ＴＯＣ構造は、コレクションの性質およびサイズに依存して、狭く、広く、深く、または浅くあり得る。このＴＯＣは、スクリーン上の航行を支援するために拡張する（より低いレベルを示す）か、または押し縮める（より高いレベルを示す）階層のレベルを有し得る。

ユーザーは、特異性が増加する各レベルにある、トップレベルノードから中間および末端ノードまでのリンクに従うことにより、ＴＯＣを下降する。このようなリンクは、アウトライン形態、開放または閉鎖され得るフォルダーのいずれかで明瞭に示されるか、またはその他の階層ユーザーインターフェース方法を用いる。ユーザーがこのＴＯＣを下降するとき、「ブレッドクラム」トリイルが生成され、訪問された各レベルに戻るリンクを提供する。ユーザーは、トップレベルノードから選択すること、そして別のパスに沿って戻って移動することによるか、またはＴＯＣをサーチすることにより、ＴＯＣを横切って航行する。

このＴＯＣは、そのコレクション内の任意のドキュメントを見るときアクセス可能であるべきである。コレクション中の他のドキュメントに対するそのドキュメントの相対位置は、ＴＯＣによって示される。ユーザーは、このＴＯＣを、コンテンツコレクション中の任意のドキュメントを見ると同時に航行し得；すなわち、このドキュメントは、ユーザーがさらなるコンテンツを捜してＴＯＣを航行するとき、なお開いている。

ＴＯＣが、特定のコンテンツコレクションのために、視覚ＴＯＣを生成するようフィルターにかけることにより、視覚ＴＯＣを生成するよう混合することにより、例えば、編集により、プログラムにより構築され得る。もちろん、ＴＯＣは、従来のアプローチを用いて手動で生成され得る。ＴＯＣは、コンテンツ中に含まれるマークアップを利用することによりプログラムにより生成され得る。このような場合、このＴＯＣは動的に作製され得、そして種々の方法で組織化され得る。一旦、ＴＯＣが生成されると、それは、異なるリソースアプリケーションによって異なる様式で用いられる得るメタデータの柔軟な本体を提供する。ＴＯＣは、リソースアプリケーションにより動的にフィルターされ得、１つ以上の完全ＴＯＣのサブセット表示を生成する。このような表示は、ドキュメントまたはコレクションのＴＯＣのより大きなコンテンツ内の特定のドキュメントのサブセクションを示す稼動ヘッダーおよびフッターを生成するために用いられ得る。フィルターされた表示は、トピックの、司法の、管理の、または一時的サブセットへの表示を制限するＴＯＣの性質を抽出することにより生成され得る。１つ以上のＴＯＣから抽出された複数のサブセットは、動的に抽出され得、そして組み合わされて、物理的スペースに単一ドキュメントとして存在しない仮想ドキュメントに対応する視覚ＴＯＣを生成する。

仮想ＴＯＣ表示を生成するためのサブセット抽出フィルターは、すべてのレベルの全ＴＯＣに対して、または複数のコンテンツセットＴＯＣに対して付与され得る。上記のように、これらサブセット抽出の結果は、所望の選択された部分をクリップして出す。このクリップされたセクションは、次いで、配列され得、新規な混合表示ＴＯＣを生成する。この表示ＴＯＣは、ユーザーに、同一または異なるコンテンツコレクション中の複数の参照を示す単一の仮想ドキュメントの外観を与える。

インデックスもまた提供され得る。このインデックスは、特定のＸＭＬタグおよびコードをドキュメント内のテキストにマップし、そしてまた、ドキュメント、コレクションまたはセット内の全体のテキストを、完全にサーチ可能なツール中にマップする。

（ロード管理）
本アーキテクチャーは、ハードウェアおよびロードに応答するために共通であるその他のリソースのスケーリングを容易にする。複製されたリソースとともに、ロードを、タスクが、その他がこのようなタスクに代用可能であるとき、特定のリソースに過度に待ち行列を作らないようにバランスすることが必要である。従って、本発明は、ロード管理にビッドスタイルを採用する。これは、待ち行例を作っているタスクのさらなる処理のためにそれらの利用可能性を報告するためにアイドルまたは低ロードリソースを必要とする。このビッドモデルは、モニタリングコンポーネントによるＬＤＡＰの使用により一部履行され得る。

（ログ）
ログは、共有されたサービス／ツールによりリクエストされる事象をトラックし、そして何が実際に入ったかを基に診断を可能にする。すなわち、フロントエンドドキュメントロードおよびユーザーサーチの両方がトラックされ、リアルタイムモニタリングおよび階層エラーチェッキングを提供する。

（データ管理）
データ管理コンポーネントは、基礎的なシステム維持および最適化を提供する。

（ＣＣＩ（中央制御情報））
ＣＣＩコンポーネントは、すべてのメタデータが記憶されている場所を管理し、そしてそれを各データコレクション中の形態についてそれをモニターする。取り込みの間、このＣＣＩは、コレクションのロードセットが与えられる。ロードセットは、ＸＭＬデータが、共有ツール／サービスによってどのように処理されるべきかを規定するためのルールを含むテーブルである。詳細なインデックス規則、ＤＯＣ、ＴＯＣ、およびＭＭに対する処理規則、およびどのビルダーによりどのエレメントが処理されるかの規則を含むロードセットが存在する。ロードセットは、１つ以上のデータコレクションにより共有され得る。

（ＤＯＣ）
ＤＯＣは、レンダリングコンポーネントへの送達のために、リクエスト、戻りドキュメント、改変、マークアップおよびセットアップドキュメントをとるサービスである。これは、ドキュメントフィルタリングのためのＤＯＣ回収エンジンによって提供されるファシリティーを含む。ＤＯＣはまた、完全ＸＭＬドキュメントから良好に形成された部分を識別かつ回収するために設計されたフィルタリングオプションを提供する。

（ユーティリティ）
ユーティリティサービスは、それら自身のサービスでは保証されていない多くのサービスを集めるために設計された一般的サービスである（これは、それら自身のＭＱ待ち行列を有することを意味する）。以下のサービスがこのＵｔｉｌｉｔｙ Ｓｅｒｖｉｃｅ内に収容されている。

（１．ドキュメントロケーター）
このサービスは、どのコレクションが、ＧＵＩＤを与えられたドキュメントをどのコレクションが含むかを位置決めするために用いられる。それは、一般に、ハイパーリンクを置き換える、および／またはそれに従うときに用いられる（これは、標的ＧＵＩＤのみを含む）。

（２．結果航法）
このサービスは、サーチ結果オブジェクト内の基礎的航法のための機能を提供する。このＳｅａｒｃｈ Ｓｅｒｖｉｃｅは、サーチ結果オブジェクトを生成する。このＤＯＣ Ｓｅａｒｖｉｃｅは、ドキュメントのテキストを回収するために用いられる。このＲｅｓｕｌｔ Ｎａｖｉｇａｔｉｏｎ Ｓｅｒｖｉｃｅは、これら２つを、クライアントが特定のランクについてドキュメント情報（ＧＵＩＤ）をリクエストすることを可能にすることにより結びつける。この情報は、サーチ結果オブジェクトから抽出され得、そして戻される。次いで、クライアントは、必要な情報をもち、それを用いてＤＯＣ Ｓｅｒｖｉｃｅがドキュメントテキストを回収することを誘起する。

（３．ＰＩＴ Ｇｅｔ）
クラアントは、それらの世界の表示を「凍結」するための機構といてＰＩＴ（時間点、ｐｏｉｎｔ−ｉｎ−ｔｉｍｅ）値を用いる。同じＰＩＴが次の共通コンテンツレポジトリーサービスコールについて用いられ限り、この表示は一定のままである（それらは、ロードされた任意の新たなデータを見ない）。クライアントが、新たなＰＩＴをリクエストするとき、それは、リクエストの時間における時間点流れへのその表示をリセットしている。

（４．持続的オブジェクトデストロイヤー）
Ｐｅｒｓｉｓｔｅｎｃｅ Ｓｅｒｖｉｃｅ仕様で記載されるように、持続的オブジェクトの破壊は、クライアントの責任である。このＰｅｒｓｉｓｔｅｎｔ Ｏｂｊｅｃｔ Ｄｅｓｔｒｙｅｒ Ｓｅｒｖｉｃｅは、クライアントが、この破壊が生じるようにし得るＡＰＩを提供する。別個および特有のＡＰＩは、各タイプの持続的オブジェクトを破壊するために生成される。

（持続性）
Ｐｅｒｓｉｓｔｅｎｃｅ Ｓｅｒｖｉｃｅは、図４中では、ＡＲサーバー３００の一部として見られるが、それは、共通コンテンツレポジトリーおよびＣＣＲＤＳサーバー４００と緊密に関連している。Ｐｅｒｓｉｓｔｅｎｃｅコンポーネントの機能は、サーチの再実行を必要とすることなく次のアクセスのためにサーチ結果を記憶することである。例えば、所定のサーチは、１００の関連するドキュメントのための識別子を回収することに至り得る。１〜１０のドキュメントが表示され、その一方、１１〜１００までが保持されている。従って、ユーザーがドキュメント５０選択すると、ドキュメント５０は、サーチを再び実行する必要なく、記憶された識別子にアクセスすることによりＰｅｒｓｉｓｔｅｎｃｅコンポーネントから後に決定され得る。サーチコンポーネントで共通のコンテンツレポジトリーをアクセスする複数のユーザーで、このＰｅｒｓｉｓｔｅｎｃｅコンポーネントは、サーチコンポーネントの負荷を容易にする。

（ウェブサーバー、ＡＲサーバー）
ウェブサーバー２００およびＡＲサーバー３００コンポーネントは、ＣＣＲＤＳサーバー４００のドキュメントレポジトリー中にあるデータに基づく、ウェブベースアプリケーションを生成および破壊するために用いられるアプリケーションフレームワークを提供する。このフレームワークの部分として、ＡＲサーバー３００は、参加するビジネスユニットを横切る顧客に関する共有情報を促進するための高レベルのゴールを有している。共通レポジトリーは、ビジネスユニットに参加するためのユーザー情報を記憶する。これらのコンポーネントはまた、ユーザーによる複数アプリケーションのための単一のサインオンを支持する。

ＡＲサーバー３００は、異なるリソースアプリケーションと関連する複数の異なるユーザーインタフェースコンポーネントからアクセスできるようにする単一のホストプラットフォームである。このプラットフォームは、翻訳（Ｒｅｎｄｅｒｉｎｇ）、ローカル化（Ｌｏｃａｌｉｚａｔｉｏｎ）およびアラート（アラート）サービスと同様に、若干の共通機能を提供するコンポーネントのセットを有する。プラットフォームは、また、フェイルオーバー（ｆａｉｌｏｖｅｒ）を支持し、且つ高い有効性を支持するコンポーネントを支持するための持続性を実行する共通の標準設計を含む。加えて、再使用可能で一般的な持続するデータコンポーネントは使用可能とされる。セキュリティモデルが、顧客の単一のビュー（ｖｉｅｗ）を確実にするために、認証およびアクセス制御のために提供される。
プラットフォームは、モニター、管理および展開のための共通手順を更に含む。

ＡＲサーバー３００のコンポーネントは、ＣＣＲＤＳサーバー４００のデータ格納部から共通性を引き出す特定のユーザーインタフェースのためのアプリケーションをカスタマイズするために、ツールキットをリソースアプリケーションデベロッパーに提供する。ＡＲサーバー３００の重要なコンポーネントに関する説明は、以下に続く。

（重複の検出）
重複の検出サービスが、それが最後に見られた時からそれが修正されない限り、同じドキュメントが再び示されるのを防止するために、フィルタとして機能する。表題、ソースまたはバージョンの重要でない違いだけについては、例えば、ユーザーが質問をＤＯＣコレクションに提出して、重複を含むドキュメントのリストを受けとるときに、重複ドキュメントの問題は起こる。これは、例えば、ニュース記事に起こり得、それは共通コンテンツレポジトリー部に記事を提供する多くの新聞において同様に報告され得る。ニュース検索から戻されるドキュメントの３０％と同程度多くのものは重複ドキュメントのセットの部材であり得ることが分かっている。重複ドキュメントのセットの中で、重複と思われ得る全てのドキュメントの半分以上は、正確な重複のカテゴリに分類される。しかしながら、非常に類似しているが同一でないドキュメントを検出するための重複のよりあいまいな概念を含むことはまた面白いかも知れない。

２つのテキストストリングの比較として、アブストラクトの充分なレベルで、ドキュメント重複の検出は調査することができる。しかし、このとき、引用および候補ソースドキュメントの代わりに、１つはドキュメントおよび候補ソースドキュメントを有する。上部のｎ（ｎは比較的少ない整数である）のドキュメントｉｄｆ条件（各々と関連して特長およびそれらの位置を含む）が、比較のために、ドキュメントの「指紋」を提供するのに十分であると決定された。ここで、ｉｄｆは、「逆のドキュメント頻度」を意味し、与えられた条件が、条件の「ドキュメント頻度」の逆であり、すなわち、１が、条件を含む考慮の基で、コレクションのドキュメントの数によって分けられる。

この指紋は、重複検出システムで使われる各々のドキュメントのためのメタデータ分野として準備されなければならない。それは、ドキュメント入力時に実行されなければならない計算作業を提供する（ドキュメント収集がすでに共通コンテンツレポジトリーに収納されるために、それは後でなされ得るが）。重複を含み得る検索結果が成されるときに、実際に指紋比較をする計算負荷を広げるのを助けるために、比較作業は、クライアント側（検索要請はそれから始まる）およびサーバー側で分けられる。このように、重複の検出は、基本的に次の３つのステップを含む。

（Ａ．メタデータ生成−バッチロードプロセスの間）
ドキュメント入力セッションの間、各々のドキュメントのために、完全なドキュメント署名（ｓｉｇｎａｔｕｒｅ）がメタデータ（長さスカラー＋指紋ベクトル）の形態として格納される。

ドキュメントの「長さスカラー」（表題、著者および他のヘッダ情報を含む特徴で）が、署名（背丁）の一部として格納される。

「指紋ベクトル」は、例えば、『言葉のごまかし［７６］、人質［Ｏ］、顕著な［２５］、非妥協性［１２１］、残忍性［１６３］、シアター（ｔｈｅａｔｅｒ）［１３］』（ｉｄｆ値によってランクした）、などの互いに関連するそれらの位置とともに、ドキュメント（ヘッダ情報を除外する）の上部ｎ（ｎが４〜３０、好ましくは４〜６、最も好ましくは６である）のユニークなｉｄｆ条件から成る。

考慮中の条件は、ドキュメントのタイトル、および他の見出しを排除することに注意されたい（なぜなら、異なるタイトル、発行者、編集等によって、これらは明らかに変わり得るので）。

さらに、異常に高いｉｄｆ（すなわちｉｄｆ＞０．８）は、トップ６の候補とは思われないことに注意されたい。なぜなら、これらは異常（すなわちタイプミスおよびミススペル）である傾向があるので。

指紋ベクトルは、それから、対処可能な長さのキーにハッシュされる、例えば［！Ｘ９Ｖ＾４＃ｗ＋ｚ２％７ｔ＄ｄ］（１６バイト）。それらが二回以上ドキュメントに記載される場合であっても、ドキュメントの最も高いｉｄｆ条件は、一回ベクトルの一番上のｎのｉｄｆ条件に現れ得るだけである。

（Ｂ．ドキュメント比較処理−サーバー側に検索結果リストが与えられる）
サーバーに、検索結果のトップランクのドキュメントおよびそれとまだ比較される次のドキュメントが始まる。

ドキュメントの長さが比較される、仮に、比較ドキュメントが、ベースドキュメントの±Ｍ文字の範囲内である場合は（例えば、Ｍが０〜２５６、好ましくは４０文字）、続ける；そうでない場合は比較が終わる（±Ｍが、ヘッダ材料の近くでテキストの潜在的な差異を補償するのに役立つ）。

ドキュメント指紋が次に比較される。仮に比較ドキュメントがベースドキュメントのそれと同一の指紋を有する場合、重複として重複ドキュメントにフラグを付ける、そうでない場合は、比較を終える。

重複の状況のためにフラグを付けられたドキュメントは、クライアント上の重複フォルダに効果的に移動される。

すでに重複のためにフラグが付けらない次の最高にランクが付けられたドキュメントは、以前にフラグが付けられない結果リストの下の順位の他の全てのドキュメントと比較される。

そのプロセスは、フラグが付けられないドキュメントの最後の一対が比較されるまで続く。

（Ｃ．ドキュメント翻訳−クライアント側）
（１）重複のないドキュメントは、標準の検索結果リストに記載される。
（２）重複を有する最高位のドキュメントは、標準の検索結果リストに記載される、しかし、それらの対応する重複のドキュメントが、「重複」フォルダ（例えば、スクリーンの下側の左手の隅に見られる）において見られることを示すためにマークされる。
（３）残りの重複のドキュメントは、「重複」フォルダにおいて見られる。

この重複の検出システムを実行することは、いくらかのさらなる考慮を含む。

最高にランク付けされたフラグのないドキュメントは、標準の結果リストに維持される。

ｉｄｆｓは、時間とともに疑いなく変化する。ｉｄｆｓが得られるコレクションが変化する場合、今日発生する指紋は、来年発生する指紋に対応しないかもしれない。周期的にドキュメントの指紋を再生する必要性を回避するために、それから、ｉｄｆｓスコアを基にする大きな安定したコレクションを維持することは重要である。あるいは、一旦大きな安定したコレクションが決定されるならば、条件およびそれらの対応するｉｄｆｓは、単に参照表に経済的に格納され得る。

ニュース記事のようなドキュメントにおいて、全てのｎの上部ｉｄｆ値の条件が同じパラグラフから来ることは可能である。これは、このように乏しいクロスドキュメント範囲を表すようである。しかしながら、およそ１ページの平均の長さで、ニュース記事は長くない。全てのｎの高いｉｄｆ条件が、１つの比較的小さい場所で起こることが非常に低い可能性である場合であっても、これはそれらのドキュメントの範囲がいかなる形であれ減弱するということはできない。ドキュメントの他のセクションにおいて最も高いｉｄｆ条件の欠如もまた検出に役に立つので、指紋範囲は完全なままである。

指紋ベクトルをハッシュ（ｈａｓｈ）することを選択せず、その代わりに、比較されるベクトルの条件の±１、±２又は±Ｎの関係を許すことによって、ある程度の「不明瞭」を重複の検出プロセスに加えることができる。このように、システムを重複の検出の所望のレベルに合わせるために、２つのドキュメント間の指紋および／または長さスカラーパラメータが、規定のマルチファクターに対して測定でき、類似閾値に調整可能である。

ハッシュすることは、比較されるドキュメント署名に厳格に余分のレベルを加えることができる。なぜなら、ｉｄｆ値における適度の変化は、最高のｎのｉｄｆ条件のオーダーを変えることができ、条件自体でないからである。そのため、用語Ａ［０］の中でハッシュ、用語Ｂ［２５］の中でハッシュは、用語Ｂ［２５］、用語Ａ［０］・・・とは異なる。従って、ｉｄｆ算出が標準のマスターコレクションを使用して安定しない限り、より多くの比較は上記の現象のゆえに失敗し得る。

（ドキュメント翻訳コンポーネント）
ドキュメント翻訳コンポーネントは、ドキュメントをアプリケーション特殊スタイルシート（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｓｔｙｌｅｓｈｅｅｔ）にマップする。各々のドキュメントは、ＡＲサーバー標準に従って、スタイルシート参照タグで埋められる。翻訳コンポーネントは、外部入力を必要とする。これらの入力は、アプリケーション開発者のカスタムスタイルシートおよび付随するスタイルシートＧＵＩＤへのスタイルシートのマッピングを含む。入力は、ファイルシステムおよび共通のコンテンツ保管システムを使用している翻訳コンポーネントによって検索される。

ドキュメント翻訳サービスは描きおよびＸＳＬスタイルシートを蓄える。リソースアプリケーションは、ｔｏＨＴＭＬ（）を使用してＸＭＬのスタイルを整える。図１９は、ドキュメント翻訳がどのように最小のプレゼンテーションスタイルシートを続行するかについて模式的に示す。図２０は、ドキュメント翻訳がどのようにカスタムスタイルシートによって、そして、多数のスタイルシートマップによって続行するかを図式的に示す。

（お気に入りオンラインアプリケーションの具体的なインフォメーション格納）
このサービスは、ユーザーが日常的に使用するドキュメント、コレクション、検索文字列またはセットを選択、格納およびアクセスできるようにする。このコンポーネントは、また、ユーザーが、そのユーザーのためそのドキュメントに格納される所与のドキュメントにコメントを加えることができる。格納され得る情報の他の実施例は、保存されたサーチ（Ｓａｖｅｄ Ｓｅａｒｃｈｅｓ）、ドキュメントに対する保存されたクイックリンク（Ｓａｖｅｄ Ｑｕｉｃｋ Ｌｉｎｋｓ）、アラートデフィニションに対する保存されたクイックリンク（Ｓａｖｅｄ Ｑｕｉｃｋ Ｌｉｎｋｓ）を含む。その情報は、ユーザーによって操作され得る動的な階層として格納される。特徴は、従来のウェブブラウザのお気に入り特徴と類似している。

（画像転換）
ＪＰＥＧに対するＴＩＦＦの共有サービス／ツール変換の画像転換コンポーネントが撮像を表わし、又は他の画像フォーマット転換を実行する。コンポーネントはさらに、画像および支持画像操作の大きさを変更するための特徴を支える。上記は、スケーリング、回転、クロップ（ｃｒｏｐｐｉｎｇ）、フィルターを含む。従来の画像転換コンポーネントが使用され得る。

（ローカル化）
このコンポーネントはユーザーに、個々に彼らのローカルユーザーインタフェースを修正し、カスタマイゼーション（ｃｕｓｔｏｒｎｉｚａｔｉｏｎ）を提供することを許容する。例えば、ユーザーインタフェースは、スペイン語に翻訳されることができ、または特定の市場のためスペイン語で開発され得る。さらに、自然言語の調査が許される範囲で、ローカル化は、英語検索エンジンの全て又は一部はローカル言語に特有の検索コンポーネントと交換されることを必要とし得る。

ローカルは、言語、地方およびこれらのバリエーションによってユーザーのために特定され得る。テキストおよび画像の両方は、ローカル化され得る。１つのプロパティはファイルし、そして、１つのディレクトリはローカルにつきセットアップされる。

（アラートＡＰＩおよびサービス）
アラートサービスは、選ぶ顧客が質問を検索することを許容し、それは指定された間隔で動作する。検索の質問が新しい結果がを出すたびに、検索結果はエンドユーザーに送られる。アラートサービスは、電子メールおよびファクシミリ用の共有サービス／ツールドキュメント送達メカニズムを使用する。以下のコンポーネントは、アラートサービスの一部である：アラートエントリを保つためのデータベース；ユーザーインタフェースからアラートエントリを操作するためのＡＰＩ；アラートエントリを行い、結果を顧客に伝えるためのサービス。これらのコンポーネントは、各々のリソースアプリケーションが、それらの特定のアプリケーションのための同じアラートサービスを使用できるようにする。

図１６に好適に示されるように、あらゆるユーザーに対する警告は、警告ＡＰＩ１６０２を使用したディレクトリへのエントリーを伴って設定される。警告エントリーは、作成され、修正され、削除され、あるいはランされる。警告エントリー内において定義されるドキュメント選択データをランする頻度は、毎日、ウィークデイ、毎週、隔週、毎月に設定可能であり、あるいは保存される。警告サービス１６０４は、コモンコンテンツレポジトリー１６０６および警告データベース１６０８と情報交換し、続いてクリップしたドキュメントをドキュメントはデリバリーサービス１６１０を介してデリバリーする。ユーザーは、マルチプルＤＯＣコレクションを利用できる。

（ドキュメントデリバリーＡＰＩおよびサービス）
デリバリーサービスは、ユーザーにオンラインドキュメントの物理的あるいはローカルな電気的コピーの作成を可能にする。デリバリー機能は、調査処理のあらゆる場面においてアクセス可能である。ドキュメントをデリバリーするために、ユーザーは、一般に以下の情報を特定する：デリバリー内容、包含（ｉｎｃｌｕｓｉｏｎｓ）、省略、デリバリー先、およびフォーマット。

デリバリー内容を決定するために、リソースアプリケーションは、特定のドキュメントあるいは所産のためのデリバリー機能にアクセスするための少なくとも１つの方法を提供すると想定される。直接的指示（例えば、ページ上のボタン）あるいは間接的指示（例えば、プリントリンク）によってなされるかは、機能的には同一である。一般には、全体のドキュメントあるいは所産（ａｒｔｉｆａｃｔ）がデリバリーされると想定される。大きなドキュメントに対しては、ユーザーには単にドキュメントの特定部のみがデリバリーされ得る。テーブルコンテンツのような手段が、ドキュメント部分の選択に使用できる。

何を含有しあるいは省くかの決定に際し、デリバリー操作のディフォルトモードは、全体テキスト、ならびに映像および特殊なドキュメントに伴うテーブルの全体セットを含む。ドキュメントタイプあるいは他のプロパティに応じて、追加アイテムがデリバリージョブに追加され、あるいは削除される。ユーザーに、各アイテムがドキュメントタイプに適合するかのチェックは、はずされる。

デリバリー先は、ユーザーの選択およびデリバリー先装置の有効性に基づいて決定される。例えば、デリバリー先は、添付のプリンタ（ユーザーコンピュータあるいはＬＡＮに添付されたプリンタ）、Ｅメールアドレス（プリントジョブに代えて、ファイルのフォーマットコピーがユーザーのＥメールアドレスに送付される）、ファックス（ファイルのフォーマットコピーがユーザーのファックスアドレスに送付される）、あるいはダウンロード（ファイルのフォーマットコピーが、ユーザーによって特定されたデリバリー先のユーザーコンピュータのハードディスク上に保存される）を含み得る。ユーザーは、デフォルトとしてデリバリー先を選択するまで、デリバリー先アドレスを特定する必要はない。

デリバリー（および多様な他のオプション）のためのユーザーの選択は、リソースアプリケーションおよび共通サービス／ツールのためのデフォルトバリューを保持するファイル内に特定されている。

ドキュメントデリバリー用にサポートされたフォーマットは、ＨＴＭＬ、ＲＴＦ、ＰＤＦ、ＰｏｓｔＳｃｒｉｐｔおよびテキストファイルを含む。図１８Ａおよび図１８Ｂは、ドキュメントデリバリーに含まれる種々のコンポーネントの関係を示す。デリバリーされるドキュメントは、ドキュメントを表示コンポーネントに提供するデリバリーサービスによってアクセスされる格納装置に一時的に保持される。デリバリーサービスは、表示コンポーネントを有し、ＸＭＬおよびＸＳＬｔドキュメントを取り入れる。それは、これらをＸＳＬ ＦＯ、ＨＴＭＬおよびテキストフォーマットにおいてデリバリーする。ＸＳＬ ＦＯプロセッサは、ＳＭＴＰメールによって送信可能なＨＴＭＬおよびＰＤＦ/ＰｏｓｔＳｃｒｉｐｔドキュメントを作成する。ＲＴＦプロセッサは、ＲＴＦドキュメントをウェブ（Ｗｅｂ）に提供する。テキストを含むＨＴＭＬドキュメントもまた、デリバリーされ得る。

（トレイルＡＰＩおよびサービス）
トレイルサービスは、再作成可能なアプリケーションイベントの相互交流のあるヒストリを維持する。これによって、ユーザーは、ドキュメント結果を再作成するリサーチイベントを再開発する要求をすることなく、即座にドキュメントを発見することができる。すなわち、システムは、結果として生じるドキュメントのテキストではなく、共通コンテンツ保管場所および作成結果の問い合わせによって実行されるようなリサーチに関する情報を保持する。例えば、各ドキュメントはＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ）によって識別され、また「Ｂｅｓｔ−ｏｆ−ｔｈｅ−ｓｅａｒｃｈｅｄ−ＧＵＩＤｓ」は、参照のために、トレイル機能によって格納される。常時ユーザーは、作成されたリソースアプリケーション、ユーザー要求のトレイルおよび修正のうちの１つに関する新しいセッションを開始する。ユーザーが以前の要求に戻る必要がある場合、トレイルコンポーネントは、サーチプロセスの間に設立されたトレイルを使用してドキュメントへの即座なアクセスを提供する。トレイルコンポーネントは、また、ユーザーにトレイルを保存あるいは以前のトレイルへのアクセスを可能にすることによって、以前のセッションからのサーチの利用をユーザーに可能にする。

トレイル機能は、トレイルデータベース１７０２（図１７参照）に保持されたデータ構造内のユーザーによって実行された操作シーケンスを収集することにより、ユーザーに、簡易で迅速な方法によって以前のサーチを可能にする。トレイルディレクトリは、作成、削除、変更および回収作業を特定するために使用される。トレイル機能は、ユーザーにアクセスを与え、ユーザーにトレイルデータの操作を許可する。

トレイル記録はサーチセッションの間に形成され、データ構造としてリソースアプリケーション内に保持される。トレイルデータ構造は、特定のパスワードに特定さてれおり、そこでは、認証手段、その上クライアントＩＤによって記録される。トレイル内に記録されたイベントは、基本的に変更可能なリサーチイベント、例えば最初のドキュメント取り込み、サーチおよび引用要求に対応し得る。イベントをクリックすることにより、ユーザーはドキュメント、サーチへの戻り、あるいは引用等にリターンすることができる。

リソースアプリケーションは、ユーザーに、リサーチセッションの間、いつでもトレイル設備へのアクセス（トレイルイベント需要者１７０６を介して）を可能にする。同様に、トレイル設備は、ユーザーに、リサーチセッションへの離れた地点への継続的な再入力を可能にする。

アプリケーションは、トレイルワークを以下の追跡方法によって進行する。アプリケーションは、ニュートレイルを作成し、特定の情報（例えば、トレイル名、プロダクト、ユーザーＩＤ、クライアントＩＤ等）を設定する。トレイルはまた、作成データ、最終アクセクデータ、および期限切れデータを含む。追加パラメータも定義可能であり、特にプロダクトによって利用可能である。この「プロパティ」は、データベース検索ができないＸＭＬストリングに格納される。その他、アプリケーションは、特有のトレイルキーによって、特別に先存するトレイルを得る。

プロダクトの「再作成可能イベント」（例えば、サーチ結果、ドキュメント）のために、アプリケーションはニュートレイルアイテムを作成し、それをトレイルに加える。トレイルアイテムは、アイテムタイプ（例えば、サーチ、ドキュメント）のような特別情報を格納し、またデータを作成する。特にプロダクトによって定義されかつ使用される追加パラメータは、格納可能である。これら「プロパティ」は、ＸＭＬストリングに格納され、また、プロダクト用のイベントを再作成するために使用可能である。

システムはトレイル要求をキュー（ｑｕｅｕｅ）に置き、バックグランドサービスがその要求を処理する。ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ−Ｆｉｒｓｔ−Ｏｕｔ）フォーマットが、要求を処理するために使用される。サービスは、新規要求のためのキューを継続的にモニタする。データベースエラーが発生した場合、キューはバックアップされ、トレイル情報をユーザーに対して遅延する。それは、アプリケーションの実行をスローダウンさせない。

リソースアプリケーションは、利用可能な最もアップデートなトレイル情報を調べる。アプリケーションは、需要者のためにトレイルアイテム（例えば、再作成可能なイベントへのリンクを伴うウェブページ）のリストを作成するために、トレイルＡＰＩ１７０８を使用する（イベントの再作成は、特別がプロダクトのために正当な請求イベントがビジネスルールに基づいて作成されあるいは回避されることを確認するアプリケーションによってコントロールされ、そのためイベントはトレイル上に再作成されないことに、留意を要する）。

アプリケーションは、ユーザーセッションが終了したとき、あるいはアプリケーションが明らかにトレイルを終了したとき、トレイルを終了する。

トレイル情報の他の使用は、ユーザーの要求および期待に適合するためのシステム改善にある。そのため、要求メッセージに応答して見出されたドキュメント用の特別なリソースアプリケーションおよび識別子の範囲内の、ユーザーサーチ処理に関する情報を保持する１つ以上のトレイルファイルを、システムが有する場合、この情報は、特別なリソースアプリケーション用の共通使用パターンを決定するトレイルファイルを処理するためのトレイル分析コンポーネントに対して、提供可能である。この分析は、検索オプションを提供するために、およびそのような使用パターンに、より適した結果を検索するために、リソースアプリケーションのパラメータ調整に導かれ得る。

ドキュメントが検索結果として存在している優先オーダーに関連する検索結果内で識別されているドキュメントをユーザーが表示しているシーケンスを含む、共通使用パターンを、その分析がもたらす場合、調製されたパラメータは、ドキュメントが検索結果として存在している優先オーダーに影響を与え得る。その分析が、検索結果内に識別されたドキュメントのユーザーレビューが複製（ｄｕｐｌｉｃａｔｅ）として含まれる共通使用パターンをもたらす場合、調製されたパラメータは、二重の検出サービスのための類似閾値に影響を与え得る。また、トレイル分析は、そのような使用パターンを具体化し、それに関連するリソースアプリケーションに適合させるために、メタデータ内に捕らえられている共通使用パターンに導かれ得る。例えば、リソースアプリケーションの最も経験豊富なユーザーのトレイル分析が、ＴＯＣブランチの少ない利用、あるいはＴＯＣノードからの探査のある種のパターンを示す最も実際的なＴＯＣ使用パターンを表す場合、これは、ベストの実施と見られる具体化として提供され、また経験の少ないユーザーにとっても価値あるものとされ得る。

（イベント課金／ロギングＡＰＩ） 共有されるサービス／ツールは、リソースアプリケーションの作成者に、ウェブアプリケーションからの課金記録を作成することを可能にする。課金記録は、一般的であり、リソースアプリケーション作成者に課金要求に必要なデータを獲得させる。ＡＰＩはＸＭＬに必要なデーダを提供し、しかしながら、リソースアプリケーション作成者は、一般的ＸＭＬをその課金システムに適正なフォーマットへの変換するリソースアプリケーションの提供に対する責任がある。

ＡＰＩは、リソースアプリケーションの特別の名前／価値ペアを伴うイベントを作成する。課金／ロギング機能は、課金イベント情報をビジネスシステム需要者にデリバリーする。ある種のデフォルトプロパティが課金イベントのために存在する：スレッドバリュー、機械名、ファイル更新記録、およびイベントＧＵＩＤ（イベントのためのグローバルな特有ＩＤ）。

（セキュリティサービス：セキュリティおよびアクセスコントロールＡＰＩ）
セキュリティおよびアクセスコントロールの１つの部分は、サインオンおよびサインオフを含む認証を含む。このサインオン操作はユーザーを識別し、そしてリソースアプリケーションリサーチセッションを開始する。サインオンは、ユーザー識別子（ユーザーｉｄ）およびユーザー認証子（バスワード）を必要とする。これらは、リソースアプリケーションによるか、またはユーザーにより生成され得、（特有の識別子文字列が提供される限り）エイリアスを思い出す容易さを含む。このサインオフ操作は、このセッションを閉鎖する。

アクセス制御操作は、リソースアプリケーションが使用法および／または制限アクセスをモニターすることを必要とする；ユーザーが個々またはグループを基礎にインターフェースのカスタム化を必要とする；アクセスが、コンテンツおよび／または機能レベルでモニターされなければならない；ユーザーアクセスが同じコンテンツを参照するアプリケーションタイプを横断して共有されなければならない（例えば、同じコンテンツコレクションへのウェブおよびインターネットアクセス）；またはユーザーアクセスが複数のリソースアプリケーションを横切って共有されなければならないとき必要である。

本発明とともに、複数のリソースアプリケーションが、共通システムを横切ってリンクされる。従って、認証プロセスは、ユーザーが使用する権利を有する種々のリソースアプリケーションのすべてについてユーザーにアクセスを提供する。しかし、これら種々のリソースアプリケーションが、それら自身の使用法要求および請求パラメーターを有するとき、この使用法をトラックかつ請求するアプリケーションへのユーザーＩＤ／パスワードの接続および記録は、各リソースアプリケーションの責任である。換言すれば、共通のユーザープロフィールが生成されかつ利用される。図１３は、ユーザー認可情報を基づくユーザーの置き換え、およびそれらの質問メッセージを提供するために、オンラインで共有されるセキュリティコンポーネントが、どのようにリソースアプリケーション１３０２およびセキュリティデータベース１３０４中に記憶されたインターネットセキュリティ情報と通信するかの概略図を提供する。図１３は、さらに、顧客の定義、製品、価格プラン、認可などを維持するビジネスシステム１３０６が、どのように、管理サービス１３０８を通ってセキュリティデータベースにどのようにアプリケーションセキュリティ定義をおすのかを示す。この認可サービスは、このデータベースの維持を可能にするＡＰＩを出す。このＡＰＩは、ＸＭＬリクエスト応答メッセージに基づく。リソースアプリケーションに特異的なセキュリティ情報は、その他のアプリケーションによって用いられ得る。

共有されたアプリケーションサービス中で履行されるセキュリティは、顧客の一致した表示を提供する。共有されたアプリケーションサービスＳｅｃｕｒｉｔｙ Ｍｏｄｅｌ中にユーザー実体（Ｕｓｅｒ ｅｎｔｉｔｙ）を生成することにより、顧客は、各サイトの証明書の特異的セットを思い出す必要性なくして参加サイト（またはリソースアプリケーション）間を容易に移動し得る。これは、ユーザーが、すべての参加サイトについて、唯一のサインオンＩＤおよびパスワードを必要とし、しかもユーザーの保証書が１つの安全な場所に記憶されることを意味する。

従って、ユーザーを認証する共通サイト共有セキュリティは、それら自身の認証システムを構築、購買、ホストおよび維持しなければならないことはないことによって、時間およびお金を節約する。開発者は、それら自身のサイトの特徴および機能性に集中し得る。

セキュリティは、ユーザーの基礎的プロフィールを支持する。言語優先およびファーストネームおよび名字のような情報は、アカウント生成時間で集まり得る。セキュリティモデル内のユーザーは、アカウントが生成されるとき、Ｕｓｅｒ Ｇｕｉｄ（グローバル汎用識別子）を割り当てられる。このユーザーを識別するために用いられるのはこの識別である。

このセキュリティサービスは、種々のセキュリティタスクを実施する。このタスクは：現存するセキュリティユーザーを認証すること；リソースアプリケーションが認証を実施することを可能にすること；現存するセキュリティユーザーをアップデートすること；新たなセキュリティユーザーをセキュリティデータベースに追加すること；セキュリティユーザーを特定の特徴へのアクセスを認可するためにグループと関連付けるか、関連を解くことを含む。その他のセキュリティ特徴は、容積または価格限界をたどること、受給限界のタイミングをとること、エクスポート制御を含む。

図１４は、用いられるセキュリティパラダイムを概略的に示す。セキュリティは、ユーザー１４０２、ユーザーグループ１４０４、およびユーザーのための認可１４０６を含む。単一のユーザー定義がすべてのリソースアプリケーションについて用いられ得る。従って、１つのユーザーＩＤおよびパスワードが、ユーザーが任意のリソースアプリケーションからのドキュメントをアクセスすることを可能にするために用いられ得る。各ユーザーは、一旦性格なＩＤおよびパスワードが入力されると、利用可能になる特有の許可を認可される。ユーザーＩＤおよびパスワードが、Ｓｅｃｕｒｉｔｙ ＡＰＩを用いてセットアップおよび変更され得る。各認可は、コレクションセットのような特徴１４０８をリソース１４１０に関連付ける。

ユーザーはユーザーグループに属し得る。ユーザーグループは、ユーザーのクラスを表示し得る。グループ中のすべてのユーザーは、同じ許可で認可される。ここで再び、ユーザーグループが一旦記載され得、そして次に、すべてのリソースアプリケーションによって用いられる。

図１５は、１つの実施形態についてのセキュリティモデルのコンポーネントおよびそれらの関係を示す。このモデルをセットアップするために、最初に、アプリケーション特異的実体のための名前識別子を規定するドメイン１５０２をセットアップすることが必要である。これは、アプリケーションを横切る二重の名前、例えば、Ｆｉｊｉ：サーチを可能する。Ｏｗｎｅｒｍ１５０４は、次いで、管理者にユーザーＩＤおよびパスワードを定義する。次に、ユーザー１５０６が規定される。ユーザーＩＤ、パスワードおよびその他のユーザープロフィール情報が割り当てられる。このユーザーＧＵＩＤは、この定義の基礎にある。

定義されたユーザーがグループの一部である場合、グループユーザーエンティティ１５０８は、ユーザーのクラスを表すグループ１５１０へユーザーを追加するために使用される。グループの定義は、一度定義され、あるいは多数のユーザーに割り当てられる許可が認可される際の管理を簡易化する。グループは序列という言葉によって定義され得る。親グループは、１つ以上の子グループを有し得る。子グループは、その親グループから許可を受ける。

フィーチャー１５１２は、セパレート制御あるいは価格設定（例えば、ドキュメント引用、クリッピング）を要求し得るリソースアプリケーション機能として定義される。セキュリティモデルを介して、ユーザーは、特別のコンテンツあるいは機能へアクセスするフィーチャーの使用を許可され、あるいは拒否され得る。コンテンツリソース１５１４は、セパレート制御あるいは価格設定（例えば、Ｆｉｊｉニュース、Ｆｉｊｉ事情）を要求するコンテンツの定義されたサブセットを表す。セキュリティモデルのために定義されたコモンリソースタイプは、ＤＯＣコレクションあるいはコレクションセットである。

また、アクセスコントロールオブジェクト１５１６は、セキュリティモデル内において定義可能である。アクセスコントロールは、フィーチャー（例えば、サーチ）を介してのコンテンツリソース（例えば、ワールドニュース）へのアクセス許可を許可あるいは拒否する。そのようなアクセスコントロールは、グループあるいは個々に割り当てられ得る。

申し込みが定義されたとき、ユーザー、グループユーザー、グループ、アクセスコントロール、フィーチャー、およびセキュリティモデルのリソース要素は、互いにリンクされる。

（マルチティアー環境）
リソースアプリケーションは、ドキュメントを引き出すために特有のプロダクトを作成するために、ＡＲサーバー３００およびＣＣＲＤＳサーバー４００のコンポーネントを利用する。

図５は、リソースアプリケーションおよびそのインフラストラクチャーを形成する、クライアントティアー、サーバーティアー、およびデータサーバーティアー構造のコンポーネントを示す。クライアント側を表すために１つのユーザーが使用されるが、多数の異なり分散されたクライアントユーザーインターフェースがシステムにアクセスする。クライアントユーザーインターフェースは、オンラインデリバリー環境によって提供されるウェブサーバーをアクセスする。オンラインデリバリー環境は、同様に適正なアプリケーションサーバーおよび特別のユーザーインターフェースに基づくプロトコルを提供する。検索が実行されるとき、共有されるサービスサーバー、ディレクトリサーバーおよびアプリケーションサーバーは、ドキュメントを引き出すためのデータベースへのアクセスを得るために、データティアーと情報交換する。

（作成環境）
図７は、本発明に従うリソースアプリケーションのための作成環境を示す。プロセスは、希望プロダクトのフィーチャー、環境サイズ、期待サービスレベル、およびクラスタリングを定義する質問事項によって開始する。作成はまた、実行のための種々のロギング、デバッグ、およびビジネスレポートを含む。設計のスケーラビリティはキャパシティ計画と共に考慮される。管理変更、発行された管理、拡大、および議論フォーラムのためのプロシージャーと同様に、構築および作成のためのツールおよびプロシージャーが、プロセスの作成のために必要である。コンポーネントが作成されるとき、復帰（ｒｅｇｒｅｓｓｉｏｎ）をテストするユニットおよびストレステストの実行が必要である。また、警告、デリバリー、およびトレイル機能の管理のための種々のツールが作成において使用される。最後に、リソースアプリケーション作成プロセスは、オペレーションシステム、ウェブサーバー、アプリケーションサーバーおよびデータベースのアップグレイドをアドレスしなければならない。

先行作成サービスおよびツールがともに使用され、モノタリングが種々のウェブサーバー、アプリケーションサーバー、共有されるサービス／ツールおよびデータベースサーバーのために使用される。加えて、作成プロセスは、共通コンテンツの保管場所のパーツである、オンラインビジネスサービス、ビジネスサービス、共通コンテンツサービスおよび出版コンポーネントを、必然的に求める。

本発明は好ましい実施形態を参照して記載されたが、本発明の真意と範囲から逸脱することなく、様々な変更が形態および詳細においてなされ得ることは、当業者にとって認められ得る。

Claims (1)

1. 本願明細書に記載のシステム。

Images