電子的ドキュメントレポジトリーマネジメントおよびアクセスシステム
本発明は、カスタマイズされたサービスを複数の多種多様なエンドユーザーに提供しつつ、付加価値のある電子文書の大きなコーパスの配布およびマネジメントを提供するシステムおよび方法に関する。1つの実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムであって、このシステムは、ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有するデータ集合を備える。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データレポジトリーのアクセスおよび利用のために作製された、大規模の電子的データレポジトリーおよびソフトウェアアプリケーションにおける、データ、特にドキュメントの配布およびマネジメントに関する。
【背景技術】
【0002】
コンピュータおよびウェブ−ベースアプリケーションの使用にともなって、非常に大量の情報が、エンドユーザーにとって、オンラインでアクセス可能となり得る。近年、オンラインデータベースが、コンテンツにおいて特化され、特定のタイプの記録(例えば、商標、または特定分野の技術文献)のみを網羅する。従って、データベースおよびアクセスツールは、特に、そのコンテンツを念頭において、設計された。複数の情報に対するニーズを有するユーザーは、図1に示す環境が、強いられる。各情報は、必須とされる別個のシステムでの作業およびその特定のユーザーインターフェース(特定のデータベース(または関連するデータベースのセット)に対するアクセスを提供し、その情報リソースに特有のアクセスソフトウェアおよび課金ソフトウェアによってサービスを受ける)を必要とする。大量の格納能力および速度の改善によって、データベースが非常に大きなサイズに成長することを可能にし、そして単一のプロバイダによって、複数のデータベースを提供することを可能にする。
【0003】
しかし、コンピュータ化された情報の集合のサイズの増加、および、検索速度に対するユーザーの期待、および、使用のユーザー−フレンドリーの形式、およびドキュメントデリバリーは、情報プロバイダの変化をもたらす。過去から受け継がれたユーザーインターフェースおよびアクセスシステムは、しばしば、それを使用することに対して非常に慣れた者に対してのみユーザー−フレンドリーであり、特定のコンテンツに対して調整されたほとんどのユーザーインターフェースおよびアクセスシステムは、お互いに異なり、そのことのために、ユーザーが1つのシステムから、他のコンテンツのためのシステムに移動することを困難となる。たとえ、ユーザーがその差異を受け入れることができたとしても、オペレータは、ただ単に、別個の過去から受け継いだシステムを、より大きな格納デバイスを有するより早いプロセッサにロードすることは、効率的でないことを見出している。
【0004】
さらに、1つの過去から受け継いだシステムを用いて、別のシステムのデータベースにアクセスして、共有することは、通常、不可能出ない場合でも、困難である。たとえ、過去から受け継いだデータベースが、過去から受け継いだシステムの間で共有することができたとしても、他の非効率性の問題が生じ得る。しばしば、同一の情報が、異なるユーザーによって、異なる目的のために、求められる。従って、同一の情報は、複数のリサーチリソースまたはチャンネル(例えば、法律または金融ドキュメントサービスに対するニュースサービス)を通して、異なるタイプのユーザーにとって、利用可能とされ得る。同一の情報を、複数のリソースを通して利用可能とするために、データは、しばしば、重複し、そして異なるデータベースに格納される。さらに、異なるユーザーの問合せアプリケーション(ユーザーインターフェースと関連するものを含む)は、各別個のデータベースにアクセスするために使用され得る。このような構造は、典型的に非効率的である。なぜなら、これは、重複した、開発およびサポートのための努力、ならびに重複した情報の格納を必要とするからである。さらに、このことは、変化した顧客の関係または市場の状況に応答して、既存のシステムを変化することを、困難にする。
【0005】
情報プロバイダにとって、2つの基本的な目的は、ユーザーに売却するために利用可能な情報を最大化し、そして情報の売却におけるフレキシビリティーを最大化するということである。これらの目的は、情報プロバイダが、情報プロバイダが、多くの異なる種類のユーザーに対してアピールすることができ、異なるレベルのアクセスおよびデリバリーのモードを提供することができ、そしてコンテンツおよび形式について調整された情報をデリバリーすることができることを意味する。これらの目的を追求することは、情報プロバイダが、異なるユーザーに異なる商品および価格決定を適合させ、そして新規のコンテンツおよび顧客を追加することにおいて、より大きなフレキシビリティを提供する。
【発明の開示】
【発明が解決しようとする課題】
【0006】
これらの目的に取り組むために、複数のユーザーが、異なるアプリケーション(ウェブ−ベースまたはそれ以外)から、同一の情報にアクセスすることを可能にする、集中化された情報データベースおよび情報マネジメントシステムが必要である。さらに、電子的に格納されたドキュメントの大きな集合体にアクセスするための、そのようなアプリケーションを構築するために、効率的なアーキテクチャ/インフラストラクチャモデルがさらに必要である。
【課題を解決するための手段】
【0007】
(発明の簡単な要旨)
1つの実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムである。
【0008】
別の実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムであって、このシステムは、ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有するデータ集合を備える。このシステムはさらに、少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント、および、受け取ったドキュメントを処理して、ドキュメントを富化するための、エンリッチメントコンポーネントを、備える。このシステムはさらに、データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント、少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント、ならびに、ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネントを、備える。
【0009】
別の実施形態において、本発明は、問合せメッセージを処理するシステムであって、このシステムは、問合せメッセージを入力するための、1つ以上のユーザーインターフェースであって、ここで、この1つ以上のユーザーインターフェースの各々は、リソースアプリケーションに適合する、ユーザーインターフェース、問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合、および、その1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、1つ以上のメタデータ情報ファイルを備える。このシステムは、さらに、1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、この取入れ口コンポーネントは、新規ドキュメントからメタデータを作成し、そして、1つ以上のデータ集合において、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、を備える
別の実施形態において、本発明は、問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法である。この方法は、ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、少なくとも1つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程、および、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、サーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程、を包含する。この方法は、さらに、問合せメッセージに対する応答において、ユーザーに対して、1つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程、および、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、ユーザーに関連するユーザープロファイルに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程であって、リソースアプリケーションにおいて具体化され得る、工程、を包含する。この発明はまた、選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、を包含する。
【0010】
別の実施形態において、本発明は、問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、少なくとも1つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネントを備える、伝達媒体において具体化されたコンピュータデータシグナル。この媒体はまた、問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、サーチコンポーネントに対してデリバリーされる、問合せメッセージに備えるコードコンポーネント、および、1つ以上のドキュメントを同定するサーチ結果メッセージを、問合せメッセージに応答してユーザーに提供するためのコードコンポーネントを備える。この媒体はまた、ユーザーと関連するユーザープロファイルに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答するコードコンポーネント、を備える、コンピュータデータシグナル。
【0011】
複数の実施形態が開示されるが、本発明のなお別の実施形態が、以下の詳細な説明に従って、当業者に明らかとなる。明かであるように、本発明は、全て本発明の趣旨および範囲から逸脱することなく、種々の明白な局面において、修飾され得る。従って、図面および詳細な説明は、発明の性質を例示するもと看做されるが、限定するものではない。
【0012】
(詳細な説明)
(A.システムの概観)
図2は、いかにして、本発明のシステムが共通のリソースまたは共有されたシステムサービスを用いて、メタデータ50を有する複数のデータ集合30に対する共有されたアクセスに基づいて、ユーザー6に対して、識別された情報リソースサービスを提供するのかを示す、ブロック図である。より具体的には、図2は、いかにして、複数のユーザー6(例えば、金融ニュースに興味を持つユーザーa、法律ドキュメントに興味を持つユーザーb、および技術および特許ドキュメントに興味を持つユーザーz)が、システムと相互に作用し得る。(これら興味の対象は、例示である;ユーザーは、法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース情報、あるいは、これら分野の特定の部門。)各ユーザーは、それぞれのユーザー問合せメッセージQa1、Qb1、およびQz1を送り、これらは、ユーザーのそれぞれのリソースアプリケーションソフトウェア15(例えば、リソースAppA、リソースAppB、およびリソースAppC)によって受け取られ、これらの各々は、その情報ソースに対して購読し、そしてアクセスを購入するユーザーの特定のドキュメントのニーズに対して役に立つように、設計される。リソースアプリケーション15(リソースAppA、リソースAppB、およびリソースAppC)の各々は、それぞれのユーザー問合せメッセージQa1、Qb1、およびQz1を、共有システムサービス/ツール20(各リサーチリソースを含む情報リソースフィーチャーを提供するために必要な種々の機能を実行するソフトウェアとハードウェア)のセットに対して送る。
【0013】
概観するために、より重要な共有されたサービス/ツールは、サーチサービス(ユーザー問合せを処理して、問合せに応答する1つ以上のドキュメントを見出す)、会計サービスおよびビジネスサービス(情報の小売を可能にする)である。共有されたサーチサービスは、適切なデータ集合30(関連するメタデータ50を含む)のコンテンツを分析し、これらの各々は、関連するメタデータ50を有す1つ以上のドキュメントを含む。単純化のために、各データ集合を、2つのドキュメントのみを有するとして示す。従って、データ集合は、ドキュメントD11、D22を有し、データ集合2は、ドキュメントDn1、Dn2を有する。各ユーザーは、1つのみのデータ集合30に対するアクセスを提供する購読を有し得、そして各ユーザーのアクセス可能なデータ集合は、他者のものとは異なり得るが、システムは、限定されない。図2の例において、ユーザーaは、データ集合にアクセスする問合せを送り、その一方で、ユーザーbは、データ集合1およびデータ集合2の両方にアクセスする問合せを送った。さらに、ユーザーzは、データ集合2およびデータ集合zの両方にアクセスする問合せを送った。
【0014】
ユーザーaは、ユーザーの問合せQa1に応答して、データ集合からドキュメントD11aを受け取る。デリバリーされるD11aは、リソースAppAのフィーチャーに基づき、特定の形式であり、そしてD11として格納されたドキュメントのフォーマットである。ユーザーbは、その問合せQb1に応答して、データ集合から2つのドキュメントを受け取る(データ集合1からのドキュメントD11(問合せQa1に応答するドキュメントと同一のドキュメント)およびデータ集合2からのドキュメントD21)。図2において示されるように、ユーザーに対してデリバリーされるドキュメントD11は、リソースAppBがD11として格納されたドキュメントをデリバリーする形式またはフォーマットD11bとは同一ではない、リソースAppAによって決定される特徴的な形式、またはフォーマットD11aとして与えられ得る。ユーザーzはまた、問合せQz1に応答して、2つのドキュメントを受け取る(データ集合2からドキュメントD22、データ集合nからドキュメントn2)。再度、リソースAppzは、リソースAppzのフィーチャーに基づいて、D22およびDn1として格納したドキュメントの特定の形式またはフォーマット(すなわち、D22zおよびDn2z)において、これらドキュメントの各々を、受け取る。従って、図2は、2つの異なるリソースアプリケーション15が、各々同一のデータ集合30にアクセスし得、そして実際にその集合中の同一のドキュメントにアクセスし得ることを示す。さらに、図2は、各リソースアプリケーション15が、共有されたシステムサービス/ツール20を利用するが、そのユーザーに対してデリバリーされたドキュメントを、別のリソースアプリケーションによってデリバリーされた同一のドキュメントのデリバリーされた形式/フォーマットとは、いくぶん異なる形式またはフォーマットにし得る。サービスおよびデータレベルでのリソースは、共有されるが、ユーザーにデリバリーされる結果は、異なり得る。
【0015】
図3は、電子的に格納されたドキュメントの大きな集合体を維持しそして分配するためのシステム(図2において機能的に考察されるものを含む)の概観を示す略ブロック図である。より高いレベルの機能エレメントが、示される。これらの格納されたドキュメントは、多様なユーザーの集団によって利用可能とされる。システムのエレメントとしては、1つ以上のリソースアプリケーション(RA)ユーザーインターフェース10a、10b、...10n(ユーザーのための種々の静止スクリーンおよびインタラクティブスクリーンにアクセスし、および/または作成してデリバリーし、そして、1つ以上のユーザーメッセージ12a、12b、...12nを入力として引き出して受け入れる);共有されたサーチコンポーネント22;1つ以上のデータベースまたはデータ集合30a、30b(単純化のために、2つのみが示される);共有されたドキュメントデリバリーコンポーネント40;1つ以上のメタデータファイル50a、50b(再度、単純化のために、2つのみを示す);および新規ドキュメントキュー70、エンリッチメントコンポーネント80を伴い、プライオリティーコンポーネント90およびGUIDコントロール100を含む。
【0016】
各RAユーザーインターフェースは、10a、10b...10nは、1つ以上の主題領域中の情報アクセスリソースとして供されるソフトウェアのコレクションである、リソースアプリケーション15a、15b...の一部である。リソースアプリケーションは、特定の所望の市販の提供(すなわち、「製品」)を具現化、および/または得意のユーザー必要性またはユーザープロフィールに応答する。従って、1つのリソースアプリケーションは、その他から、それ自身を:アクセス可能なコンテンツ/主題の事項;ドキュメントエンリッチメントの程度、ユーザーインターフェース特徴;ドキュメント送達フォーマットまたはモード;正確さ;および特定のリソース必要性またはユーザーマーケットに対するその他のアピール特徴によって区別し得る。
【0017】
本発明の種々のコンポーネントは、異なるリソースアプリケーションを横切る記憶されたドキュメントの本質的に縫い目のないコンテンツを共有すること、および種々の様式でアクセス(例えば、ウェブサイト、インターネット、エクストラネット、ワイアレスなど)を可能するツールのセットを提供する。本発明はまた、リソースアプリケーションへの共有されたサービスおよびツールを提供するための、共通リソースアプリケーションインフラ構造(ARサーバー300、図4)による履行を含む。情報販売、セキュリティおよび請求書発行サービスは、重要な共有サービスである。各リソースアプリケーションは、共通コンテンツレポジトリーおよびデータサーバーソフトウェア(CCRDSサーバー400、図4)により記憶および維持されたドキュメントの少なくとも一部分へのアクセスを容易にすることにより、特定のユーザープロフィールおよびマッケットプレイスをサービスするために開発されている。リソースアプリケーションついて規定し、かつ履行することの利点は、共有サービスおよびツールのセットは、以下に論議されるようなものを含み:再使用可能性,アプリケーションを開発するための減少した時間、および新たなアプリケーション開発のための低減されたコストを含む。
【0018】
本発明に適用可能な1つのシステムでは、データの大きな塊が、CCRDSサーバー400によって管理される共通コンテンツレポジトリー中に記憶されるが、それは、複数のアクセス可能なサーバー上に広がり得、そして余分に維持される。このデータは、広範な範囲の主題をカバーし、そして異なる理由のために多様なグループのユーザーによってアクセスされ得る。従って、それは、異なるユーザーインターフェース10a、10b、...10cを通じてデータへの異なるタイプのユーザーアクセスを提供するために有用であり得る。各ユーザーインターフェースは、特定の詳細ユーザー特徴および必要性を供するよう適合されたスクリーン中で履行され得る。このユーザーインターフェースは、カクタマイズされて質問を作製するか、ドキュメントをリクエストするユーザーメッセージの処方の容易さを提供するのみならず、カスタマイズされてドキュメント送達のためにユーザーに適切な形態およびフォーマットを提供する。すなわち、共通のレポジトリーから送達されたデータは、特定のユーザーインターフェースに特異的に仕立てられ、かつフォーマットされる>
種々の理由のため、記憶された情報は、ドキュメントの塊内の個々のドキュメントの形態で記憶されている。このドキュメントの塊は、ドキュメントの1つ以上のコレクション中に区画される。本明細書で用いられるとき、ドキュメントは、著者または供給元が情報を調製する、ニュース論説、司法的意見(事例レポート)、規制規則、レポート、電子ファイルまたはデータベース記録、またはその他の慣例のフォーマット(紙または電子媒体のいずれか)のような、特有の一般的な識別子(GUID)を受ける1つの密着したデー
タユニットとして広く規定される。関連するドキュメントのグループは、コレクションとして一緒に記憶され得(論理的に、必ずしも物理的である必要はない)、そして1つ以上のコレクションが、セットとて、一緒に貯蔵され得る(再び、論理的に、必ずしも物理的である必要はない)。
【0019】
コレクションおよびセットの使用は、ユーザーが、特定の、共通して理解されるセットまたはコレクション、例えば、特定セットの地域法律事例レポーター;法律総説のような特定カテゴリーの定期刊行物;死亡、所有権または商標の記録のような記録のコレクション内のサーチすることのユーザーの範囲を容易にし得る。各ドキュメントは、コレンションおよびセット内で少なくとも一度インデックスを付けられる。このコレクションおよびセット配列はまた、システムが、サーチを特定のコレクションまたはセットに向けることにより課せられるサーチを低減し、そして各サーチが全ドキュメントレポジトリーをカバーすることを必要としない。ドキュメントレポジトリーは、合計20テトラバイト以上の情報を含んで極度に多くあり得る。
【0020】
いくつかの分野では、新規ドキュメントが、常時、しばしば、数分毎または数秒毎に現れるというような高頻度でさえ生成され、そしてFTPまたはその他のフォーマットにより、リアルタイムにドキュメント行列待ち70に送達される。このデータレポジトリーがアップデートされるか、またはそのコレクションが拡張するとき、新規ドキュメントは、1つ以上のデータコレクション30a、30bに付加され得る。新規ドキュメントは、後に、異なる目的のために異なるユーザーによってアクセスされるので、取り込みコンポーネント(Intake Component)80によって実施されるドキュメント取り込み機能が、適正な基礎を提供することが所望される。所定のドキュメントの取り込みを繰り返されなければならないこと、または、通常でない状況にあることを除き、それがレポジトリーに付加された後でそれを編集することは所望されない。なお、この同じドキュメントは、このドキュメントをアクセスするために採用され得るユーザーインターフェースおよびリソースアプリケーションに基づき、その送達の一部分として改変可能である必要があってもよい。(さらに、このリソースアプリケーションは、このドキュメントがドキュメントコレクションに入るときに存在しなくてもよい)。従って、各ドキュメントは、好ましくは、XML、または後の刊行において柔軟性を許容する別のドキュメントフォーマットで記憶され、そして柔軟性を支援する属性をもって生成またはエントリーの時間で提供される。さらに、このドキュメントに関連するメタデータファイルエントリーまたは記録がまた生成され得る。このメタデータファイルエントリーまたは記録は、ドキュメントのコンテンツが、ドキュメントのコンテンツの取り込みの時間に、ドキュメント自身のために適切であり得る特定の様式で富化され得ることを可能にし、そしてまた、ドキュメント自身を改変することなく、取り込みのときに、ドキュメントに関連するメタデータを改変することにより、ユーザーに利用可能な情報の後の富化を許容する。(本明細書で用いられるとき、メタデータは、情報についての情報を意味し、そしてユーザー、システム、または両方のいずかに有用であるドキュメントについての任意の情報であり得る)。
【0021】
図6は、ドキュメント110に関連するメタデータレコード152が記憶される、データコレクション30a、30bおよびメタデータファイル150に記憶され得るような、ドキュメントレコード110の概略図である。このドキュメントレコード110は、タイトル112、著者/刊行者114、日付114、GUID(全体汎用識別子:global universal identifier)118、およびPIT(時間点:point in time)スタンプのようなフィールドを含む。このドキュメントは、取り込み時に調製されたエンリッチメントデータを受けるためのフィールド126を含み得、そして必要に応じて、1つ以上のTable of Content(以下にさらに詳細に論議される)にこのドキュメントを関連付ける「ntoview」フィールド127を含み得る。このドキュメントは、1つ以上の挿入されたリンク122または分類属性124を含み得る。ドキュメントは、テキスト、持続するかまたは移動するイメージ、音またはコンテンツのその他の形態を含み得る。コンテンツの性質は、ドキュメントレコード110中またはメタデータファイルレコード152中のいずれかに捕獲される別の属性111であり得る。
【0022】
陳述のように、取り込みコンポーネント80により処理されるドキュメントは、属性をもつソースから受けたファイル(例えば、ニュース刊行者、ジャーナル刊行者、ストックマーケット、裁判所または規制当局)を提供することにより富化され得る。提供された特定の属性は、付加されているドキュメントのタイプに依存する。これら属性はまた、特定のリソースアプリケーションに一部として特定され得る。
【0023】
属性は、少なくとも2つの機能を提供し得る。第一は、そのシステム内またはユーザーに対するユーティリタリアン(utilitarian)である。すなわち、特定のコンテンツまたはコンテンツモディファイヤ、ならびに機能フィーチャ(例えば、他の文書へのナビゲーション関係またはナビゲーション接続をアクティブに確立するリンクを示す)が作成され得る。第二は、ブランド認識フィーチャである。なぜなら、ソースの受容は、しばしば、文書自体と同様に重要であるからである。このブランド識別性は、文書の最終の外観によって確立され得る。これは、文書に付加される特定のブランド識別属性(例えば、ユニークな形式またはソースから送達されるコンテンツから生成される特殊に派生する付加価値コンテンツ)によって容易にされ得る。
【0024】
例えば、取り込みのために処理される文書は、所定の株式報告または会社分析に関連し得る。この文書のテキストまたは事実コンテンツは、一般的に一旦作成されると不変である。2つの異なる販売者は、各々が受容されるレベルの品質を有し、その文書のコンテンツに対するアクセスをユーザーに提供し得る。各々の販売者は、文書をアクセス可能にするが、自分自身の情報販売システムの「外観および感触」を有することを欲し得る。従って、本発明のシステムの属性および/またはメタデータファイルを利用して、それがそのソースから提供されるときに文書を補充または強化し得、その結果、特定のユーザーインターフェースまたはリソースアプリケーションを介して提示されるときに、それが、ユニーク性を増し、そしてブランド化され、そして付加価値が与えられた製品として受容され得る。
【0025】
取り込みの際にそのエンリッチメントのために文書に関連付けされ得る属性の一つは、リソースアプリケーションに依存するベースに基づいて後に可能性のある使用のために、文書へのリンク付け(例えば、ハイパーリンク122の挿入による)を含む。例えば、法律のリソースアプリケーションに適合される判例法国は、他の内部参照される判例報告へのリンクを含み得る。これは、共通コンテンツレポジトリにおいて見出され得る(または他の場所(例えば、ワールドワイドウェブ))。新聞記事は、その話において識別される個人または事件に関連する特定のコンテンツにリンクされ得る。そのようなリンク122のアクセス可能性は、不確実であり得、すなわち、リソースアプリケーションに依存するが、いくつかの文脈においてユーザーインターフェースを通じて提供されないかもしれない。例えば、ニュースサービスの法曹ではないユーザーが法律関連の判決例報告にアクセスし得る。他の判決例報告に対するリンクは、アクティブではない可能性があり、あるいはそのユーザーについて、法曹のプロユーザーについて同じ様式で適切ではないかもしれない。記述されるように、文書に関連付けられるメタデータファイル記録152は、レポジトリにそれが付加される時点で付加される属性に関する別の場所である。メタデータ記録152は、リソースアプリケーションによって使用されて、もとの格納された文書記録110自体を変化させることなく、ユーザー照会メッセージに関連して文書についてデータ、パラメータまたはディスプレイ形式を重ねがき、付加、削除または改変する情報を格納する(または他のメタデータファイルにリンク付けする156)。
【0026】
文書取り込みのプロセスの一部として、文書記録110は、編集材料によって強化され得る。すなわち、付加価値編集コンテンツが、文書に挿入され得るか、またはメタデータ記録に付加することによってその文書に関連付けまたは付着され得る。例えば、法律の判決例報告の場合、ヘッドノートまたはまとめが、作成および付加され得る。この材料は、手動でまたはある場合は、自動的に作成され得る。例えば、法律の判決例報告において言及される判例は、引用チェックされ、そして自動的に引用がアップデートされ得る。さらに、新たな文書が種々の分類属性124によってラベルされ得る。この属性は、いくつかの集合分類(例えば、管轄、トピックなど)についての指標として使用され得る。
【0027】
(B.照会プロセスの外観)
情報小売は、種々の顧客関係に基づいて行うことができる。しかし、ほとんどの場合において、ある種の顧客契約が存在し、この契約は、顧客が購入したサブスクリプションまたはアクセス条項を定義し得る。この契約は、アクセスされ得る主題、アクセス時間などに関する制限を特定し得、そして料金を定義し得る。契約は、紙またはオンラインで締結され得、そして情報レポジトリのいかなる使用に十分先立って結ばれ得る。適切な支払いが確認されると、契約はまた、使用前にすぐに締結され得る。一旦情報プロバイダとユーザーとの間の契約関係が定義されると、ユーザーは、1または複数のリソースアプリケーションおよびそのユーザーインターフェースを介して少なくとも一部の共通コンテンツレポジトリに対するアクセスを有することになる。
【0028】
本発明の一つの目的は、情報プロバイダが、共通のコンテンツレポジトリの部分へのアクセスおよび文書の送達について所望される本質的に任意の情報製品/サービスおよび顧客との関係を定義することを可能にすることである。従って、この関係は、多数のパラメータを含み得、これは、顧客によって変動し得、以下を含み得る:アクセスが許容されるコレクションまたはセット;アクセス時間、アクセス利用可能なユーザーまたは他のロード制限の数値;ユーザーに提示されるスクリーンの外観およびコンテンツ(これによって、ユーザーは、要求を照会し、そして結果を受け取る);要求され得る文書の送達のモードおよび/または形式;および種々の使用形式の料金。従って、小売業者は、種々の関係を支持するリソースアプリケーションを開発して、システムが、種々の合意されたビジネス条項に適合するサービスを提供することを可能にすることを所望し得る。
【0029】
リソースアプリケーションがどのようにして共通コンテンツレポジトリにアクセスするかの概観は有用である。まず、エンドユーザーがエンドユーザーの照会においてシステムから文書を検索する。図3に示されるように、これは、ユーザーメッセージ12a、12b、、、12nの形式である。多数のユーザーメッセージが、一日のどの時間でも、世界中のとこからでも(ただし、定義された顧客関係によって制限されない限り)同時にユーザーから入力され得る。ユーザーメッセージは、多数の異なる形式(例えば、検索(find)、サーチ(search)、またはブラウズ機能)に適合され得る。例えば、あるユーザーが特定の情報(例えば、文書のタイトルおよび著者)を知っている場合、そのユーザーは、その特定の文書を検索するようにシステムに要求する。他方、ユーザーがある主題について一般的な情報を探している場合、そのユーザーは、サーチまたはブラウズを実行して、関連する情報を見出し、または照会を再検討する。これらは、リソースアプリケーション内で定義され得、そしてユーザーからシステムが受け取ることができる多数のタイプのユーザーメッセージの本の一例である。
【0030】
各々のユーザーメッセージは、ユーザーによって、RAユーザーインターフェース10a、10b、、、10nのうち1または複数を使用することによってシステムに入力される。各々のユーザーインターフェースは、ユニークな概観および感触を有し得、そしてユーザーが特定の種類の文書を検索することを容易にする。これは、使用されるユーザーインターフェースのタイプに依存する。例えば、法律文書を検索するためのリソースアプリケーションのユーザーインターフェースは、新聞記事を検索するために設計されてアユーザーインターフェースとは異なる文書にアクセスするように適合される。異なるアプリケーションのこれらのユーザーインターフェースは、おそらく、異なる概観および感触を有する。なぜなら、これらは、異なるタイプの文書にアクセスするように設計されており、そして異なるユーザープロファイルに対してアピールするからである。
【0031】
要求がユーザーによってユーザーメッセージ12a、12b、、、12nとして入力された後、サーチコンポーネント22を用いて関連する文書を見つける。サーチコンポーネントが、キーワードまたはフレーズを、ユーザーの要求によって使用して、関連する文書が配置される場所、および1または複数の文書を識別するサーチ結果メッセージを送信する場所を決定する。サーチコンポーネントは、究極には、各々の文書についてGUID識別子を見つける。このGUID識別子は、文書が、コレクションから容易に取り出されることを可能にする。いくつかの場合において、サーチコンポーネントは、実際の文書ではなく「ヒット」のリストを送達し、そしてさらなるユーザーメッセージは観察または他の送達のための特定の文書の選択を定義する。サーチコンポーネントは、さらに詳細に以下に記載される。
【0032】
1または複数のデータコレクション30a、30bに格納される各々の文書は、GUID制御コンポーネントのタイムスタンプコンポーネントから正確な時点(PIT)120を伴って格納される。このPITフィールドは、実際のクロック時間値であり得るが、また、所定の文書について、単に特定のバージョンが他のバージョンに比較して意味づけされることを示す一連の識別子またはバージョンであり得る。例えば、バージョン識別子は、GUID:GUID.00、GUID.01、GUID.02などに基づいて構築され得る(これは、法律的文書について特に有用であり得る)。従って、文書または関連するデータが、経時的に改変される場合(例えば、関連するメタデータを加えるかまたは変更することによる)、PITは、システムが、文書の最も現在のバージョンおよび関連するデータがユーザーに提示されているかどうかを検出することを支援し得る。また、文書の以前のバージョンがすでに提示されているにもかかわらず、文書のアップデートされたバージョンが、サーチ機能がその文書を発見したときに提示されることを可能にする。取り込み時間PITに加えて、リソースアプリケーションは、この後者のアップデート機能について有用であり得る送達時間を追跡し得る。
【0033】
一旦文書がデーベースから要求されると、文書送達コンポーネント40を用いて、文書をユーザーに送達する。この送達コンポーネント40は、文書を、リソースアプリケーションによって利用可能にされた中からユーザーが選択した形式およびモード(例えば、電子メール、ファクス、郵便)で文書を提示する。従って、送達されるときには同じ文書が、異なる概観および送達モードを有し得、これらの概観および送達モードに依存して、ユーザーインターフェースおよびリソースアプリケーションがそれに関して要求を受け取る。
【0034】
図3に示されるように、データベースまたはデータコレクション30a、30bに格納される文書は、メタデータファイル50a、50bと関連付けられる。メタデータファイルは、各々の文書に関連する種々のさらなる情報を含み得る。この情報は、文書コンテンツ自体の一部ではないが、関連する文書についてのサーチの間にアクセスされ得、または文書自体と同時に送達のためにアクセスされる。
【0035】
各々の新たな文書は、まず、取り込みコンポーネント60によってデータベース30a、30bへと配置される。このデータベースは、定期的かつ頻繁に文書がアップデートされ、そして少なくとも文書のいくつかは、即座の発行が必要とされる。例えば、株式市況報告およびホットニュース記事は、可能な限り早く利用可能になるべきである。その関連性は、しばしば、短命であり、その価値は、そのタイムリー性に関連する。取り込みコンポーネントの優先度コンポーネント90は、1または複数の優先度レベルを用いて処理のために入ってくる文書を優先度をつけて、特定のリソースアプリケーション(例えば、報告またはニュース事項の場合の時間発行利用可能性を約束するリソースアプリケーション)のために定義され得るリアルタイムまたは他の特定の利用可能な要件を用いて受け取り文書の時間順序から選択的に処理する。GUID制御コンポーネント100は、それがデータコレクション中の任意のユーザーに利用可能とされる前に、各々の文書に関する割り当てられた文書識別子のユニーク性をチェックし得る。取り込みコンポーネント60はまた、ユーザーに利用可能な文書を作成する前に、所定の形式について文書をチェックし得る。これらのフィーチャは、データコレクション30a、30bに対してリリースされる文書がこのシステムによってアクセスされる準備ができることを確実にすることを支援する。
【0036】
(取り込み処理)
図8は、取り込み処理をフローチャートの形式で示す。802において、システム5(図3)は、ソース(例えば、ニュースサービス、裁判所、市場データサービス)から送信されるファイルを受け取り、そして804において取り込みコンポーネント60は、ファイルを送信形式から、取り込み処理により適切な形式へと変換する。806において、個々の文書が処理のために分離され、そして808において取り込みコンポーネントは、ソースによってすでに割り当てられたかもしれないまたはいまや割り当てられる必要があり得る優先度コードをサーチする。810において、文書が1または複数のキュー中に蚊k脳され、優先度に従ってさらに処理される。812において、このシステムは、ファイル中のさらなる文書および/または受け取られるべきさらなるファイルについてチェックし、そしていずれかが存在する場合、適切な実行ポイントを返して、次の文書またはファイルを処理する。
【0037】
814において、最高の優先度を伴う文書を選択することによって、別の処理リソースが文書のキューにアクセスする。816において、取り込みコンポーネントは、ソースによってすでに割り当てられてい得る(GUIDのユニーク性を確実にせねばならないシステムに強調して)か、または今やユニーク姓を確実にする履歴およびアルゴリズムに基づいて割り当てられることを必要とし得るGUIDについてサーチする。818において、文書の格納フォーマットは、エンリッチメント80を処理するための準備を確実にするために820においてチェックされる。
【0038】
エンリッチメントコンポーネントを用いて、文書コレクション30a、30bにおいて配置されるように、各々の文書を増強することができる。エンリッチメントコンポーネントは、種々のフィーチャを各々の文書に加え、これは、1または複数のユーザーグループのための文書の価値を増大させる。エンリッチメントコンポーネントは、各々の文書を、以下のうち1または複数と関連付ける:人間のエージェントによって準備されたさらなる編集材料;自動化エージェントによって準備されたさらなる編集材料;このデータベース中の別の文書へのポインタを提供するリンク;またはメタデータファイルに出現する文書と関連付けられたエントリ。これらのエンリッチメントフィーチャは、エンドユーザーに対して、ある種類のさらなるコンテンツと組み合わされた個々の文書の形式で付加価値生成物を受け取ることを可能にする。種々の形式のエンリッチメントが、特定のユーザーに役にたち、そして特定の文書を送達するために使用されるリソースアプリケーション15に依存して利用可能であり得る。
【0039】
820におけるエンリッチメント処理の後、文書は、822においてメタデータ抽出コンポーネント処理に供され得る。この処理で得られるメタデータは、一般に、この文書を1または複数のコレクションへと接続するために重要なデータを抽出する工程を含む。従って、この文書のコンテンツを解析して、同じまたは異なるコレクションにおいて他の文書に対してこの文書の言語学的に洗練された分類を開発することができる。格納または検索を支援し、そして文書を改変またはカスタマイズして1または複数のリソースアプリケーションのフィーチャのための基礎を提供する、種々の形式のメタデータが開発され得る。
【0040】
図8をなおも参照すると、メタデータが抽出された後、824において、文書がアクセスのためのリリースのその時間に対応するPITとともに格納される。826において、このシステムは、処理される優先キューにおいてより多くの文書が存在するかどうかを決定する。そうでない場合、文書プロセッサは、828において待ち状態へと移る。より多くの文書が存在する場合、制御は、実行点へと移り、その時点で、次の文書が優先キューから選択される。
【0041】
新たな文書が配置される少なくとも1つのデータコレクションにおける文書は、少なくとも1つのコレクションサブセットへと区分され得、そして新たな文書を受け取るための取り込みコンポーネントが各々の追加の文書がユニークな識別しそして少なくとも1つのコレクションサブセットに割り当てられることを確実にし得る。別のデータコレクションは、少なくとも1つの文書セットを有し得、この文書セットは、1または複数のコレクションサブセットの文書のアグリゲーションである。
【0042】
(エンリッチメントおよびメタデータ処理)
図9は、図8において言及された文書エンリッチメントおよびメタデータ抽出のプロセス900のためのフローチャートを示す。902において、文書エンリッチメント処理のために使用されるコンポーネントは、制御を受け取り、そしてエンリッチメントのための文書を受け取る。904において、自動化されたエンリッチメントエージェントが適用され、そしてこのエージェントによって生成されるエンリッチメントフィーチャを使用して、文書を増強する。例えば、このエージェントは、新聞記事または事件の中で個人名または会社名についてサーチし得、次いで、文書をブラウズする個人によって相談され得る再度バーディスプレイのためのファイルを構築することができる。自動化されたエンリッチメントエージェントの適用の後、バイパス経路905〜ステップ910は、人間のエンリッチメントエディタの割り当てが必要でない場合に採られ得る。バイパス905が採られない場合、906において、文書は、再検討および編集のために人間のエンリッチメントエディタに割り当てられる。908において、人間のエンリッチメントエディタがさらに増強された文書と共にファイルを返す。910において、増強された文書は、メタデータ処理のために送達され、そして912において、メタデータ抽出コンポーネントは、送達された文書を受け取る。914において、自動化されたメタデータエンジンが文書に適用されて、メタデータが抽出され、そして916において、このメタデータファイルが収集され、そしてその文書と関連付けされる。例えば、抽出されたメタデータは、XMLデータまたはメタデータのレイヤに構築されたリソース・ディスクリプション・フレームワーク(RDF)ステートメントの形式でメタデータのレイヤへと開発され得る。918において、この文書のためのメタデータファイルは、他の文書に関してメタデータファイルとリンク付けられる。例えば、メタデータ処理が、文書のいくつかの言語学的分類を生じる場合、表、インデックス、コンテンツ表または他のコレクションワイドのメタデータファイルが、この文書に由来する情報および/またはそれに対する参照とともにアップデートされ得る。920において、リソースアプリケーション条件付タグがメタデータファイルに付加され得る。これらは、特定のリソースアプリケーションによって用いられて、特定のリソースアプリケーションによって供給される文書リソースサービスにおいて含めるのかまたは排除するためにメタデータをタグ付けする。いくつかの場合において、メタデータは、リソースアプリケーションによってアクセス可能なタグの存在または非存在に基づいて、サーチまたはディスプレイから排除される。
【0043】
922において、メタデータファイルが格納される。これらは、文書と関連付けられて(couple)格納され得るか、または関連付けられずに格納され得る。すなわち、物理的な関連付けまたは単に論理的な関連付けが存在し得る。924において、このシステムは、ファイル(または部分)を候補としてマークし、または将来のメタデータの付加のための候補としてではなくそのファイルをマークする。この将来のメタデータは、文書使用パターンを経時的に統計学的またはヒューリスティックな規則解析の使用によって派生され得る。メタデータを格納すると共に、処理される文書は、ユーザーアクセスのために準備ができるようになるが、関連するメタデータは後に変更され得る。このシステムが、使用パターンを追跡および解析するためのエージェントを有する場合、このマーキングは、適切な場合この文書の使用が追跡されること、および結果(例えば、図6における使用メタデータ154)が記録されることを確実にし得る。さらに、使用パターン情報が開発されるにつれ、メタデータは、文書取り込みがアップデートされ得る時間に格納され得る。例えば、この文書が頻繁に、観察されるサーチパターンの部分である場合、メタデータファイルは、生じた一連のサーチにおいて近似する他の文書を反映するようになり得、その結果、同じ一連のサーチに沿ってユーザーが後に導くことを支援する。926において、エンリッチメントおよびメタデータ抽出コンポーネントは、システムに制御を戻す。
【0044】
メタデータは、情報オブジェクトへのアクセスを構成、記述、追跡および他の様式で増強するように作成される付加価値情報である。以下により詳細に説明されるように、本発明において、とりわけ、メタデータは、コンテンツの表、フィルタリングまたは他の操作によって得られるコンテンツ表の派生物、ユーザー追跡情報から派生する使用パターンデータ、重複検出のために開発された文書シグネチャ、およびトークンインデクシングの形式で開発される。文書の大きなアグリゲーションにおいて、メタデータは、ヒエラルキー形態であり得、ここで、より高いレベルのメタデータは、より低いレベルのメタデータの意味を解釈するにおいて支援するように開発され得る。他の状況において、メタデータは、非ヒエラルキーであるがそれにもかかわらず他のメタデータに関してリンクまたは他の非ヒエラルキー形態の指摘手段によって関連付けられるメタデータである。次に記載されるコンテンツ表は、付加価値メタデータを開発するためのプライム機会を提供する。
【0045】
(コンテンツ表(TOC)構築)
1つの形態のメタデータプロセシングは、コンテンツ表(TOC)構築である。本発明において実行されるように、TOCは、2つの異なるコレクションタイプが定義されることを必要とする。TOCコレクションは、TOCヒエラルキー関係を含む。文書(DOC)コレクションは、文書を含む。TOCは、1、2または多数のDOCコレクションにおいて文書を参照することができる。恒常的なGUIDは、現在のTOC設計の利益を達成するための要件である。システムが多数のタイプの情報をユーザーに提供する場合、それは、代表的には、各々のタイプの情報について少なくとも1つのTOCを有する。
【0046】
TOCヒエラルキーは、共通のコンテンツレポジトリー中に1つのコレクション中に存在し、そして文書に対する参照を含む。参照される文書は、1または複数のDOCコレクション中に存在する。コレクションセットを用いて、単一のTOCコレクションとDOCコレクション(単数または複数)とを結びつける。このDOCコレクションは、参照される文書を含む。図10は、TOCアーキテクチャの模式的外観である。以下は、TOCの実行についてのさらなる詳細である。
【0047】
a.ローディングデータ。TOCデータをTOCコレクションにロードする。DOCデータを、DOCコレクションにロードする。TOCコレクションおよびDOCコレクションの両方は、同時に、ローディングデータであり得る。TOCおよび文書データをsync(同期)に維持するために、同期プロモートが、多重コレクションの同期を促進することをクライアントに可能にするために利用可能である。
【0048】
b.TOCノードに基づくサーチの制限。「n−tocview」エレメントが文書データロードに加えられて、TOCサーチ−クエリ−ビュー制限を支持する。この「n−tocview」127(図6)は、クライアントが文書と関連付けることを希望するTOC GUIDを含む。以下は、図11Aにおいて単純化したサンプルTOC構造をアップデートするために使用されるXMLの例である。ここでは、陰付ノードは、文書「d2」を指摘するTOCノードを表す。
【0049】
【数1】
【0050】
【数2】
【0051】
。
【0052】
注意。n−topview中で特定されるGUIDは、共通のコンテンツレポジトリによって、コレクションセット内に存在することも、関連情報であることがベリファイされていない。
【0053】
c.ラッパーAPL。コレクションセットを用いて、TOCコレクションをDOCコレクション(単数または複数)に結びつける。このDOCコレクションは、参照される文書を含む。ラッパーAPLは、コレクションまたはコレクションセットと共に用いるためのTOC APIを含む。コレクションセットは、ラッパーAPIが使用され得る単一の点を提供する。
【0054】
d.TOC XML。TOCノードは、n−nodeエレメントによって作成、アップデートおよび削除される。各々のn−nodeエレメントは、TOCノードを記述する情報を含む。TOCデータは、(文書のように)トークンインデクシングされておらず、従って、共通のコンテンツレポジトリによってサーチ可能ではない。n−topview情報がその文書内に配置され得、従って、サーチのためにインデクシングされ得る。
【0055】
n−nodeは2つの属性を有する:
guid−TOCノード GUID
control:起こるべき動作を示す。
【0056】
(表)
値 |動作の記述
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
「ADD」 |TOCノードをこの段階で加える
「DEL」 |TOCノードをこの段階から削除する
「DELBRANCH」 |TOCノードおよびこの段階について
|すべてのTOCノードの子を削除する。
【0057】
n−nodeは、以下のエレメントを有する:
n−parent−guid:親ノードのGUID。ルートノードは、このエレメントを含まない
n−doc−guid:このTOCノードが文書を参照する場合の文書のGUID。TOCノードは、ゼロを有し得るか、またはそれに関連する1つの文書を有し得る。このエレメントにおける任意のコンテンツは、TOCノードが文書を参照することを示す
n−anchor−guid:このTOCがアンカを参照するときのアンカのGUID
n−label:598バイトのサイズ制限を伴うテキストフィールド
n−rank:ランク順序で表示するためのアプリケーションのためのTOCノードをソートするために用いられる実数
n−name:アプリケーションに対して通過して戻るTOCノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内にTOC定義に対する意味を有しない。n−nameに対する最大値は、20バイトである
n−value:n−name値を伴うアプリケーションに対して通過して戻るTOCノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内のTOC定義に対して意味を有しない。n−valueの最大値は、200バイトである
n−meta−data:TOCに関するメタデータの情報を含む。
【0058】
e.TOC DTD
【0059】
【数3】
【0060】
【数4】
【0061】
f.TOCおよび文書XMLの例。図11Bを今度は参照すると、陰付ノードは、文書を参照するTOCノードを表す。2つのTOCノードは、文書「d1」を参照する。TOCノード「n7」は、「n5」のアンカーである。
【0062】
【数5】
【0063】
留意点:
文書「d1」は、<n−tocview>n1、n2 n4 n3 n6</n−tocview>の組み合わせn−tocviewを有し得る。文書内に含まれるアンカーは、クライアント特異的なタグで特定される。システムは、アンカーが要求するタグを文書内に含まない。
【0064】
g.n−nodeに関するルールのアップデート
1.重複するGUIDはない。GUIDは、2回加えられず、削除もされず、そして同じロードにおいて加えられる。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
2.定義されるn−nodeは、置き換えられるノードである。n−nodeがXMLで定義される場合、n−nodeにあるすべての情報は、再定義される必要がある。このデータのロードは成功する。このノードは、最新の定義のみを反映する。
3.子なしのn−nodeは削除機能とともに削除され得る。この条件が満たされない場合、このロードは、データエラーと共に失敗する。
4.ブランチの削除は、n−nodeおよびすべてのその子ノードが削除されたことを示す。
5.削除したブランチのn−nodeは、改変され得ず、ブランと削除として同じロードに加えられ得ない(規則1を参照のこと)。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
6.n−nodeの親guidは、既存のノードでなければならない。この条件が満たされない場合、ロードは、データエラーと共に失敗する。(既存のノードは、すでにTOC中に存在するノードであるか、または現在のロードに存在するノードである。ノードは、ランク順序によりロードされる必要はない。欠失するノードのべリフィケーションは、ロードプロセスの最後に起こる。しかし、よりよいロード速度は、ノードをヒエラルキー(ランク付け)様式でロードする場合に起こり得る)。
【0065】
h.TOCローディングでの使用の場合
以下は、TOCの実用的な含意を示す使用の場合である。これらの実施例の大部分は、図11CのTOC構造に基づく。この同じ構造は、上記XMLの例において用いられた。
1.大きなデータはどのようにしてTOC構造を用いてロードされ得るか?
例えば、50ギガバイトの生データをロードし、所定のコレクションについて500メガバイト/時の速度でロードできるとしよう。1つのTOCおよび3つの文書コレクションが使用される場合、この同じデータは、1日より若干長い時間でロードすることができる。クライアントが文書データを多数のコレクションに分断したい場合、データは迅速にロードされ得る。
2.TOCからブランチはどのようにして削除され得るか?
本発明者らの実施例を用いてノード「n2」に始まるTOCブランチを削除し、そしてまた、ノード「n2」のもとでいかなるノードをも削除するとしよう。文書「d2」は、TOC中でもはや参照されない。文書は、「d2」について欠如が共通コンテンツレポジトリに渡されない限り、削除されない。
以下は、「n2」で始まるブランチを削除するためのXMLである。
【0066】
【数6】
【0067】
以下は、文書「d2」を削除するためのXMLである。
【0068】
【数7】
【0069】
3.文書「d1」のテキストはどのようにして変更可能か?
文書「d1」を新たな文書データおよびTOCサーチ制限を許容するn−tocview情報とともにリロードする。以下はそのXMLである。
【0070】
【数8】
【0071】
4.TOCノード「n4」のラベルは変更可能か?
TOCノード「n4」を、新たなラベル情報と共にリロードする。この同じ例は、TOCランク、名称、値またはメタデータのフィールドを変更する場合にも機能する。以下は、そのXMLである。
【0072】
【数9】
【0073】
5.文書「d3」は、どのようにして削除され得、そしてノード「n3」をどのようにしてTOC中に残し得るか?
文書「d3」について削除命令を送信し、そしてTOCノード「n3」を最適議して、文書「d3」に対する参照を含ませないようにする。以下はそのXMLである。
【0074】
【数10】
【0075】
6.文書「d1」は、どのようにして削除され得、そしてそれを参照するすべてのTOCノードを以下にして除去し得るか?
文書「d1」についての削除命令を送信し、そしてノード「n4」および「n6」についての削除命令を送信する。以下はそのXMLである。
【0076】
【数11】
【0077】
7.新たなTOCノード「n7」を、TOCノード「n1」と「n3」との間にどのようにして挿入し得るか?
新たなTOC構造は、図11Dのようである。
文書「d1」および「d3」を新たなn−tocviewとともにリロードして、GUID「n7」をクエリビュー制限として支持する。「n7」について新たなTOCノードも作成し、そしてTOCノード「n3」を再定義して、「n1」の代わりに「n7」を指し示すようにする。以下はそのXMLである。
【0078】
【数12】
【0079】
まとめると、TOCは、文書に関するヒエラルキーメタデータを格納するための構造を提供する。TOCは、ノードからなる。GUIDはノード、親ノード、参照される文書およびアンカーを識別する。TOCを構築するためのすべての入力は、XMLである。TOCは、再帰的構造であり得る。これは、ノードのn−doc−guidが、文書のGUIDの代わりにTOCノードのGUIDを含む場合に起こる。次いで、TOCノードは、TOCノードを参照する。TOC中のノードラベルの語彙は、メタデータRDFステートメントに関する語彙として使用することができる。
【0080】
文書は、いっときに任意の点において、たった一つのDOCコレクション中に存在し得る。しかし、文書は、TOCとともに多重の位置において表され得る。1または複数のDOCコレクションからの文書は、1つのTOCにおいて表され得る。
【0081】
TOCヒエラルキーデータは、TOCコレクション中に格納される。文書データは、1または複数のDOCコレクション中に格納される。特定のTOCは、1つのコレクション中に存在する。TOCコレクションが参照するTOCコレクションおよび1または複数のDOCコレクションは1つのコレクションセットにより互いに結び付けられる。図12は、2つの文書(ラベルしたDG1およびDG2)を参照する単純化したTOCのサンプルを示す。
【0082】
本発明のTOC設計は、多数の有用な特徴を許容する。
【0083】
TOCナビゲーション:APIを提供して、TOCのノードをナビゲートする。以下のサンプル操作は、そのようなAPIを通じて実行され得る:TOCのルートノードを検索し;ノードを与え、その子を検索し;TOCサーチ結果およびTOCノードを与え、TOCの順序で次または前のノードを検索し;そしてノードを与えその親を検索する。
【0084】
ヒットを伴うTOC:サーチが文書ヒットを得たとき、これらを併せて各々のTOCノードにおけるヒット数をリターンする。
【0085】
フィルタリングしたTOC:リソースアプリケーションがサーチおよびTOCノードに対して参照を送信するとき、そのサーチに適合しないTOCの部分は、除去される。リソースアプリケーションがサブスクリプションハンドル(サーチに基づく制限、サブスクリプションに基づく)に対する参照を送信するとき、そのサブスクリプション基準に合わない任意のTOCが除去される。
【0086】
ノードを見出す:リソースアプリケーションが、名称および/または値に対する参照を送信するとき、TOCは、関連するノードをリターンする。
【0087】
TOCアンカー:アンカーを用いて文書内のヒエラルキーを反映させることができる。
【0088】
(インデクシング)
メタデータプロセシングのための準備として、文書を、インデックスファイルの作成により正常にインデクシングさせる。そのようなインデックスファイルは、トークン化、ストップ、ステミング、大文字使用の除去、および逆返還(inversion)によって従来の様式で誘導させる。米国特許第6,389, 412号を参照のこと。メタデータ抽出に対するインデクシングプロセスの関係は関心の対象とされ得る。インデクシングは、意味情報のいくつかの喪失を生じることから、インデクシングは、ある文書コレクションについては所望されないかもしれない。他のコレクションにおいて、インデクシングは受容可能であるが、抽出されるべき情報が、インデクシングにおいてその全体または部分が喪失する特徴を伴う場合インデクシング形式ではない文書に基づいてメタデータ抽出を行うことが最良である。メタデータは、インデクシングされてもよくされなくてもよい。1つの実施形態において、TOCデータは、インデクシングされず、従って、インデクシングに依存するサーチエンジンによってサーチ可能でない。しかし、ユーザーが以下に詳細に説明するように探索することは可能である。
【0089】
データコレクション中の文書は、少なくとも1つのコレクションサブセットに区分され得る。このシステムは、コレクションサブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有し得る。ここで、インデックス中のキーワードとそのコレクションサブセット中の出現の位置との関係が存在する。
【0090】
(コンポーネント実行のビュー:概説)
図4は、上記に示されたかまたは記載された高レベル機能エレメントを実行するメインコンポーネントを示すブロック図である。メインコンポーネントは、ウェブサーバー200、アプリケーションリソース(AR)サーバーコンポーネント300、および1または複数のリソースアプリケーションを備える。ウェブベースのシステムにおいて、CCRDサーバー400およびARサーバー300は、クライアントとしてリソースアプリケーションとともにサーバーとして動作する。具体的には、CCRDサーバー400は、データベース(コレクション)サーバーおよびウェブサーバー200およびARサーバー300が、それぞれウェブおよびアプリケーションのサーバーである。他のシステムコンポーネントは、オンラインビジネスシステムサービス500およびビジネスシステム600およびパブリシングAPI700である。ビジネスシステム600内には、オンライン決済およびSAPコンポーネントが存在する。
【0091】
ARサーバー300コンポーネントは、CCRDSサーバー400レポジトリに存在する文書にアクセスする、ウェブベースのリソースアプリケーションを配備するために使用されるアプリケーションフレームワークを提供する。このフレームワークは、ユーザーがサブスクライブし得る新たなるソースアプリケーション(例えば、ニュースサービス、法律サービスなど)の迅速なターンアラウンドを提供する。1つの実施形態において、ARサーバーコンポーネントは、J2EEコンテナにまたがって使用され得るシリアル化可能なオブジェクトを提供する。
【0092】
多数のリソースアプリケーションにわたる共有される顧客情報を提供することについて多大な利益およびシステムの能力は、共有されるARサーバーコンポーネントの最大限の使用を伴って生じるが、アプリケーションは、必ずしも、サーバー構造によって提供されるすべての機能を利用するとは限らない。図4のサーバー構造の他の利点のいくつかとしては、再利用可能性、新たなまたはアップデートされたアプリケーションの市場に対する時間の速度および新たな製品開発のためのコストの減少を挙げることができる。
【0093】
一般的に、CCRDSサーバー400コンポーネントは、電子的に格納され、インデクシングされ、そしてソートされる文書の大きな集合に対するアクセスを提供する。これらの文書は、共通のコンテンツレポジトリに加えられ、そしてより簡単な検索および付加価値コンテンツを可能にするために増強される。リソースアプリケーションを通じて文書をユーザーがサーチまたは要求するとき、CCRDSサーバー400は、ARサーバー300と相互作用して効率よい様式でサーチ結果または文書を提供する。CCRDSサーバー400は、多数の道具を利用して、文書を増強する。これらの道具は、以下により詳細に記載される。
【0094】
一般的に、ARサーバーコンポーネント300は、ウェブベースのリソースアプリケーションを配置するために用いられるアプリケーションフレームワークを提供する。このコンポーネントは、共通のサービスおよびツールフレームワークを実行する。このサービスおよびツールフレームワークは、CCRDSサーバー400を用いて文書を検索する各々のリソースアプリケーションについて開発時間およびコストを減少させる。従って、新規リソースアプリケーションは、ビジネス部門がテーラーメイドのインターフェースを簡単かつ迅速に作ることを可能にし、他方で、データおよびサービスの集中処理されたコアにアクセスできるようになる。さらに、ARサーバー300コンポーネントは、種々のアプリケーションにわたって顧客に関する情報を共有することを促進する。1つの実施形態において、フレームワークは、アプリケーション開発(例えば、Java(登録商標)2 Enterprise Edition(J2EE))に対するセットモデルおよび他の推奨されるガイドラインを確立する。
【0095】
フレームワークは、アプリケーションプログラムインターフェース(API)を提供し、HTMLまたはXMLのような包括的マークアップ言語を生成するが、しかし、リソースアプリケーションのアプリケーション開発者は、XMLスタイルシートまたはJava(登録商標)オブジェクトが、包括的HTMLまたはXMLを、このリソースアプリケーションによって要求されるフォーマットに変換するか否かのインターフェースを提供する。共通サービスおよびツールがARサーバーコンポーネント300によって提供され、それ故、各リソースアプリケーションがこれらサービスを個々に開発する必要性をなくする。
【0096】
各リソースアプリケーションは、ユーザーに、特定のマーケット中で、ドキュメントを位置決めかつ回収するための仕立てられた製品を提供するように設計された特有のアプリケーションである。上記で説明されるように、リソースアプリケーションは、ARサーバー300によって提供される特別のサービスおよびツールを利用し、CCRDSサーバー400によって管理されるドキュメントの大きな共通のコンテンツレポジトリーにアクセスする。1つ以上のリソースアプリケーションが、ARサーバー300およびCCRDSサーバー400と同時に相互作用し得、同じドキュメントをアクセスかつリクエストする;しかし、このドキュメントは、このドキュメントを送達するために用いられるリソースアプリケーションに基づく特有のルック&フィールで提供され得る。
【0097】
各リソースアプリケーションは、HTML、JPEGイメージ、Java(登録商標)Server Pages(JSP)、Servlets、カスタムスタイルシートなどのようなそれ自身のインターフェースコンポーネントを有して開発されている。しかし、ユーザーと通信するためにカスタムツールおよびサービスを利用する各リソースアプリケーション15(図3)の代わりに、プロセスUser Messageは、共通のコンテンツレポジトリーに記憶されたドキュメントにアクセスし、そして情報小売取り扱いのためのすべてのその他のビジネスルールを適用し、このARサーバー300およびCCRDSサーバー400は、各リソースアプリケーションが予めプログラムされたツールおよびサービスを利用することを可能にする標準的コンポーネントを有している。例えば、ARサーバー300のSecrurityコンポーネントは、各リソースアプリケーションが、同じセキュリティ特徴を利用することを可能にし、なお各々は、アプリケーションを開発するために選択されたコンポーネントに依存して、異なるフォーマットでセキュリティ特徴を提示し得る。ARサーバー300およびCCRDSサーバー400により提供される種々のツールおよびサービス、およびこれらが種々のリソースアプリケーションとどのように相互作用するかは、以下に記載される。
【0098】
ARサーバー300は、企業を横切るフェブアプリケーションを構築するための共通アーキテクチャー/インフラストラクチャーモデルを提供する。CCRDSサーバー400は、サーチ、ドキュメント送達、およびTable of Contentsのための再利用可能なバックエンドを提供する。ARサーバー300は、ウェブアプリケーションのために同じ再利用可能性を提供する。
【0099】
(CCRDSサーバー)
CCRDSサーバー400は、新規ドキュメントの導入および現存するドキュメントの回収を容易にする共通コンテンツレポジトリーおよび管理システムである。CCRDSサーバー400は、ドキュメントを入力し、豊富にし、見出しおよび回収するための以下のユーティリティを含む:サーチエンジン、Table of Contents(TOC)、Doc、Utility、CCI、Load Management、Data Management、およびLogging。
【0100】
(サーチエンジン)
サーチエンジンは、ドキュメントを異なる方法で位置決めするための多くのツールを提供する。例えば、サーチ(Search)、FindおよびBrowse操作が提供され得る。
【0101】
このサーチ操作は、ユーザーが、User Messageに応答して、共通コンテンツレポジトリーからのクエリーを満足する適正な質問の単一または複数「ヒット」を提供する。一般に、ユーザーインターフェースは、ユーザーを勧誘してクエリー事項を特定し、そして所望のコンテンツコレクションおよび/またはコンテンツタイプをSearch操作の一部分として選択するようにする。Search操作のユーザーは、オンライン−サーチ機能性について異なる能力および理解を有し得る。所有のサーエンジ製品などで先の経験を有するユーザーも居れば、Intenetサーチエンジンで経験を有するユーザーも居る。ユーザーインターフェースは、このような経験をもつ者に親しむように設計され得る。
【0102】
Searchの1つの使用は、BooleanオペレーターでのQuery Termによる情報のサーチを含む。このユーザーは、クエリー事項(単数または複数)をクエリーボックスに入れ、そしてResultリストが、この事項(単数または複数)を含むドキュメントを含むという期待を有する。ここで、ユーザーは、事項およびBooleanオペレーターでクエリーを構築することを欲する。このユーザーは、すべてのBooleanオペレーターが支持されている、すなわち、かれらが、サーチエンジンによって認識され、しかもクエリー−ストリングの条件を満足するドキュメントのみが回収されるという期待を有する。
【0103】
Boolean言語サーチは、「フィールド情報」の使用を経由して拡張され得る。この技法は、ユーザーが、特定のメタデータおよびデータのコンテンツ属性をサーチしこのサーチをさらにフィルターにかけることを可能にする。代表的なフィールドは、種々のタイプのドキュメントデータ、著者、タイトル、刊行物、トピック分類などのような項目を含む。
【0104】
トピックによるサーチ(そこでは、トピックスが、編集プロセスにより進んで割り当てられた特定のドキュメントをともなう)は、Booleanサーチに対するFieldedサーチの拡張を用いて達成されるが、より便利なサーチとして同じ方法でユーザーに曝されなくてもよい。フィールドはまた、コンテンツコレクションに極めて特異的である、例えば:事例に対するパーティ、ジャッジ、ドケット番号などに拡張され得る。
【0105】
サーチの別の方法は、自然の言語を用いる情報に対するSearchを用いることである。ここで、ユーザーは、自然の言語の構文でクエリー項目を入力することを欲する。例えば:「保険詐欺」。Natural Langageサーチャーから戻るサーチ結果は、文構築構文を省略して、サーチの事項に関する関連性を有することが期待される。例えば、上記のサーチでは、戻る結果は、用語「保険詐欺」を含むべきである。
【0106】
アラート(Alert)として知られる混合Search機能が提供され得、ここでは、ユーザーは、それらの実施の領域(単数または複数)に関連するなにかが変更されたか、新たな情報があるとき、アップデートすることを欲する。ユーザーは、定期的ベースで自動的に稼動するサーチアラートのポートフォリオをセットアップする。各アラートは、特定の規定された間隔で特定のコンテンツコレクションに対して特定のサーチを走らせるためにセットされる。各アラートは、規定されるべき特定の属性を可能にする。サーチャーには、これらの属性は、例えば、クエリー事項、コンテンツコレクション、主題の領域などを含み得る。ユーザーは、複数のアラート、および各アラートについてそれらのポートフォリオにおける頻度のストップ、スタート、削除または変更を規定することができるべきである。このアラートサービスによって見出されたドキュメントは、従来のクリッピングサービスの様式で送達され得る。
【0107】
このFind操作は、ユーザーがコンテンツコレクションから単一のドキュメントを回収することを可能にする。一般に、ユーザーは、司法のような特定の分野、カテゴリーまたは領域、またはFind操作の一部分として実施領域を特定することを要求されるべきではない。Find操作のユーザーは、ドキュメントが存在するという予備知識を有し、そしてその特定のドキュメントにアクセスすることを希望する。このようなユーザーは、例えば、サイト、タイトル、関与するパーティ、またはドキュメントの共通名のようなそのドキュメントに特異的な情報を識別する。
【0108】
特定の参考は、特定のドキュメントを記載するには不十分であるかもしれない。このタイプの問題は、同じドキュメントの複数テキスト、異なる言語の同じドキュメント、または特定の引用略語の異なる供給源で生じる。例えば、略号「ALR」は、AmericanとAustralianとのLegal Report刊行物の間を区別するには不十分である。このような場合、このFind操作は、この参照に適合する特定のドキュメントのすべてのバージョンを回収し、そしてユーザーが目的の特定のドキュメントを選択することを可能にする。
【0109】
このFind操作は、SearchまたはBrowseとは異なる。Findは、ユーザーが単一の特定のドキュメントにアクセスすることを可能にする。Searchは、ユーザーがかれらが規定する規準のセットに適合するドキュメントについてコレクションを走査することを可能にする。Browseは、ユーザーが、かれらの必要性に適合し得るドキュメントの分類学を通じて精選する。
【0110】
Findコマンドにまた含まれて、ユーザーが、ドキュメントまたはそのメタデータの1つ以上の属性を特定することによりドキュメントを回収することを可能にする、Find by Attribute操作がある。Find by Attribute操作の例は:Find by Title、Find by Parties(パーティに参加することにより調べる)、およびFind by Common Nameがある。
【0111】
アプリケーションに依存して、Find操作を走らす前に、プレフィルターをセットアップすることが適切であるときがしばしばある。このようなフィルターは、ユーザーがCountryコード、Lauguage、Applicationドメイン、Applicationで規定されるコンテンツセット、Contentタイプ(法律、規則、税金、ニュース)、Practiceエリア、Jurisdiction、Classificaton区画などにより結果を制限することを可能にし得る。ユーザーは、かれらが、より広いコンテンツベース内でドキュメントを見出すことを希望する場合、このようなデフォールトフィルター属性を置き換えることができるべきである。
【0112】
Find操作は、その他の操作とパイプラインされ、特有の新規操作または製品を生じる。例えば、Find操作の出力は、直接プリントに送られ得るか、またはeメールサーバーに押され、単一ドキュメントの送達を生成する。ユーザーのプロフィールは、非特有の結果の数を制限するために、複数のコレクションに対して進行するFind捜査のために、デフォールトと自動プレフィルターのセットを含んで用いられ得る。
【0113】
Find操作の履行のためのデータ要求は、設計時間の間のコンテンツアプリケーションについて決定されるべきである。このアプリケーションは、Find機能性を提供するために十分な、規準化されたかつ正規の名、参照および各ドキュメントのついての情報を提供し得る。
【0114】
サーチレベルでは、Findは、Search操作と類似である。一般に、Findは、履行および/またはユーザーインターフェースである。ユーザーの視点からは、Findは、Searchが操作が、条件のクエリーに適合する1つ以上の可能なドキュメントについてコンテンツコーパスを走査し、そしてそれでエンドユーザーに異なるタスクモデルを提示する間に、コンテンツコーパスから既知のドキュメントをどうにか引かなければならない。
【0115】
(Table of Content(TOC)機能)
CCRDSサーバー400により提供されるTOC機能は、コンテンツのペーパーブックテーブルの電子バージョンであるが、ドキュメントへの頭だしレベルおよびドキュメントへのリンクすることの拡張/押し縮めを可能にする適切な技法で増大される。TOCは、階層のトップのルートノード、随意の中間ブランチおよびターミナルエンドのリーフノードから構成される。リーフノードは、ドキュメントまたはドキュメント内のセクションに単一にリンクしている。
【0116】
Browse Table of Content(TOC)操作は、ユーザーがコレクションのコンテンツの階層図を追求することを可能にする。コレクションは、1つ以上のドキュメントから構成され得るので、対応するTOCは、複数ドキュメント、単一ドキュメント、または特定のドキュメントのサブセクションのためのTOCを提示し得る。逆に、ドキュメントの単一コレクションは、複数のTOCを有し得る。TOCは、特定のユーザータイプおよびそれが参照する特定のDOCコレクションに適合され得る。
【0117】
TOCをブラウズする間、ユーザーは、かれらが見出すことを試みる特定のドキュメントの予め存在する知識を有し得:かれらは、法律および/または実施の親しみのない領域に関する指針を捜し得;またはかれらは、TOCを用いて論点または問題を補助して作成し得る。TOCによりアドレスされるコンテンツコレクションが1つのドキュメントであるとき、そのときは、関連するTOCは、ドキュメントの構造を反映し得る。ユーザーは、大きなドキュメント、例えば、Legislationを航行するためにこのタイプのTOCを必要とする。
【0118】
同様に、コンテンツコレクションが、複数のドキュメント、例えば、Journal Articles、Statutes、またはフォームを含むとき、TOCは、各ドキュメントの存在を示して生成され得る。これは、ユーザーが適切なドキュメントをブラウズかつ選択し得るためにすべてのドキュメントのリストを必要とするための重要な特徴である。
【0119】
TOCブロウジング機能は、リンクされた材料の航行アクセスを含む。航行には、TOC構造は、コレクションの性質およびサイズに依存して、狭く、広く、深く、または浅くあり得る。このTOCは、スクリーン上の航行を支援するために拡張する(より低いレベルを示す)か、または押し縮める(より高いレベルを示す)階層のレベルを有し得る。
【0120】
ユーザーは、特異性が増加する各レベルにある、トップレベルノードから中間および末端ノードまでのリンクに従うことにより、TOCを下降する。このようなリンクは、アウトライン形態、開放または閉鎖され得るフォルダーのいずれかで明瞭に示されるか、またはその他の階層ユーザーインターフェース方法を用いる。ユーザーがこのTOCを下降するとき、「ブレッドクラム」トリイルが生成され、訪問された各レベルに戻るリンクを提供する。ユーザーは、トップレベルノードから選択すること、そして別のパスに沿って戻って移動することによるか、またはTOCをサーチすることにより、TOCを横切って航行する。
【0121】
このTOCは、そのコレクション内の任意のドキュメントを見るときアクセス可能であるべきである。コレクション中の他のドキュメントに対するそのドキュメントの相対位置は、TOCによって示される。ユーザーは、このTOCを、コンテンツコレクション中の任意のドキュメントを見ると同時に航行し得;すなわち、このドキュメントは、ユーザーがさらなるコンテンツを捜してTOCを航行するとき、なお開いている。
【0122】
TOCが、特定のコンテンツコレクションのために、視覚TOCを生成するようフィルターにかけることにより、視覚TOCを生成するよう混合することにより、例えば、編集により、プログラムにより構築され得る。もちろん、TOCは、従来のアプローチを用いて手動で生成され得る。TOCは、コンテンツ中に含まれるマークアップを利用することによりプログラムにより生成され得る。このような場合、このTOCは動的に作製され得、そして種々の方法で組織化され得る。一旦、TOCが生成されると、それは、異なるリソースアプリケーションによって異なる様式で用いられる得るメタデータの柔軟な本体を提供する。TOCは、リソースアプリケーションにより動的にフィルターされ得、1つ以上の完全TOCのサブセット表示を生成する。このような表示は、ドキュメントまたはコレクションのTOCのより大きなコンテンツ内の特定のドキュメントのサブセクションを示す稼動ヘッダーおよびフッターを生成するために用いられ得る。フィルターされた表示は、トピックの、司法の、管理の、または一時的サブセットへの表示を制限するTOCの性質を抽出することにより生成され得る。1つ以上のTOCから抽出された複数のサブセットは、動的に抽出され得、そして組み合わされて、物理的スペースに単一ドキュメントとして存在しない仮想ドキュメントに対応する視覚TOCを生成する。
【0123】
仮想TOC表示を生成するためのサブセット抽出フィルターは、すべてのレベルの全TOCに対して、または複数のコンテンツセットTOCに対して付与され得る。上記のように、これらサブセット抽出の結果は、所望の選択された部分をクリップして出す。このクリップされたセクションは、次いで、配列され得、新規な混合表示TOCを生成する。この表示TOCは、ユーザーに、同一または異なるコンテンツコレクション中の複数の参照を示す単一の仮想ドキュメントの外観を与える。
【0124】
インデックスもまた提供され得る。このインデックスは、特定のXMLタグおよびコードをドキュメント内のテキストにマップし、そしてまた、ドキュメント、コレクションまたはセット内の全体のテキストを、完全にサーチ可能なツール中にマップする。
【0125】
(ロード管理)
本アーキテクチャーは、ハードウェアおよびロードに応答するために共通であるその他のリソースのスケーリングを容易にする。複製されたリソースとともに、ロードを、タスクが、その他がこのようなタスクに代用可能であるとき、特定のリソースに過度に待ち行列を作らないようにバランスすることが必要である。従って、本発明は、ロード管理にビッドスタイルを採用する。これは、待ち行例を作っているタスクのさらなる処理のためにそれらの利用可能性を報告するためにアイドルまたは低ロードリソースを必要とする。このビッドモデルは、モニタリングコンポーネントによるLDAPの使用により一部履行され得る。
【0126】
(ログ)
ログは、共有されたサービス/ツールによりリクエストされる事象をトラックし、そして何が実際に入ったかを基に診断を可能にする。すなわち、フロントエンドドキュメントロードおよびユーザーサーチの両方がトラックされ、リアルタイムモニタリングおよび階層エラーチェッキングを提供する。
【0127】
(データ管理)
データ管理コンポーネントは、基礎的なシステム維持および最適化を提供する。
【0128】
(CCI(中央制御情報))
CCIコンポーネントは、すべてのメタデータが記憶されている場所を管理し、そしてそれを各データコレクション中の形態についてそれをモニターする。取り込みの間、このCCIは、コレクションのロードセットが与えられる。ロードセットは、XMLデータが、共有ツール/サービスによってどのように処理されるべきかを規定するためのルールを含むテーブルである。詳細なインデックス規則、DOC、TOC、およびMMに対する処理規則、およびどのビルダーによりどのエレメントが処理されるかの規則を含むロードセットが存在する。ロードセットは、1つ以上のデータコレクションにより共有され得る。
【0129】
(DOC)
DOCは、レンダリングコンポーネントへの送達のために、リクエスト、戻りドキュメント、改変、マークアップおよびセットアップドキュメントをとるサービスである。これは、ドキュメントフィルタリングのためのDOC回収エンジンによって提供されるファシリティーを含む。DOCはまた、完全XMLドキュメントから良好に形成された部分を識別かつ回収するために設計されたフィルタリングオプションを提供する。
【0130】
(ユーティリティ)
ユーティリティサービスは、それら自身のサービスでは保証されていない多くのサービスを集めるために設計された一般的サービスである(これは、それら自身のMQ待ち行列を有することを意味する)。以下のサービスがこのUtility Service内に収容されている。
【0131】
(1.ドキュメントロケーター)
このサービスは、どのコレクションが、GUIDを与えられたドキュメントをどのコレクションが含むかを位置決めするために用いられる。それは、一般に、ハイパーリンクを置き換える、および/またはそれに従うときに用いられる(これは、標的GUIDのみを含む)。
【0132】
(2.結果航法)
このサービスは、サーチ結果オブジェクト内の基礎的航法のための機能を提供する。このSearch Serviceは、サーチ結果オブジェクトを生成する。このDOC Searviceは、ドキュメントのテキストを回収するために用いられる。このResult Navigation Serviceは、これら2つを、クライアントが特定のランクについてドキュメント情報(GUID)をリクエストすることを可能にすることにより結びつける。この情報は、サーチ結果オブジェクトから抽出され得、そして戻される。次いで、クライアントは、必要な情報をもち、それを用いてDOC Serviceがドキュメントテキストを回収することを誘起する。
【0133】
(3.PIT Get)
クラアントは、それらの世界の表示を「凍結」するための機構といてPIT(時間点、point−in−time)値を用いる。同じPITが次の共通コンテンツレポジトリーサービスコールについて用いられ限り、この表示は一定のままである(それらは、ロードされた任意の新たなデータを見ない)。クライアントが、新たなPITをリクエストするとき、それは、リクエストの時間における時間点流れへのその表示をリセットしている。
【0134】
(4.持続的オブジェクトデストロイヤー)
Persistence Service仕様で記載されるように、持続的オブジェクトの破壊は、クライアントの責任である。このPersistent Object Destryer Serviceは、クライアントが、この破壊が生じるようにし得るAPIを提供する。別個および特有のAPIは、各タイプの持続的オブジェクトを破壊するために生成される。
【0135】
(持続性)
Persistence Serviceは、図4中では、ARサーバー300の一部として見られるが、それは、共通コンテンツレポジトリーおよびCCRDSサーバー400と緊密に関連している。Persistenceコンポーネントの機能は、サーチの再実行を必要とすることなく次のアクセスのためにサーチ結果を記憶することである。例えば、所定のサーチは、100の関連するドキュメントのための識別子を回収することに至り得る。1〜10のドキュメントが表示され、その一方、11〜100までが保持されている。従って、ユーザーがドキュメント50選択すると、ドキュメント50は、サーチを再び実行する必要なく、記憶された識別子にアクセスすることによりPersistenceコンポーネントから後に決定され得る。サーチコンポーネントで共通のコンテンツレポジトリーをアクセスする複数のユーザーで、このPersistenceコンポーネントは、サーチコンポーネントの負荷を容易にする。
【0136】
(ウェブサーバー、ARサーバー)
ウェブサーバー200およびARサーバー300コンポーネントは、CCRDSサーバー400のドキュメントレポジトリー中にあるデータに基づく、ウェブベースアプリケーションを生成および破壊するために用いられるアプリケーションフレームワークを提供する。このフレームワークの部分として、ARサーバー300は、参加するビジネスユニットを横切る顧客に関する共有情報を促進するための高レベルのゴールを有している。共通レポジトリーは、ビジネスユニットに参加するためのユーザー情報を記憶する。これらのコンポーネントはまた、ユーザーによる複数アプリケーションのための単一のサインオンを支持する。
【0137】
ARサーバー300は、異なるリソースアプリケーションと関連する複数の異なるユーザーインタフェースコンポーネントからアクセスできるようにする単一のホストプラットフォームである。このプラットフォームは、翻訳(Rendering)、ローカル化(Localization)およびアラート(アラート)サービスと同様に、若干の共通機能を提供するコンポーネントのセットを有する。プラットフォームは、また、フェイルオーバー(failover)を支持し、且つ高い有効性を支持するコンポーネントを支持するための持続性を実行する共通の標準設計を含む。加えて、再使用可能で一般的な持続するデータコンポーネントは使用可能とされる。セキュリティモデルが、顧客の単一のビュー(view)を確実にするために、認証およびアクセス制御のために提供される。プラットフォームは、モニター、管理および展開のための共通手順を更に含む。
【0138】
ARサーバー300のコンポーネントは、CCRDSサーバー400のデータ格納部から共通性を引き出す特定のユーザーインタフェースのためのアプリケーションをカスタマイズするために、ツールキットをリソースアプリケーションデベロッパーに提供する。ARサーバー300の重要なコンポーネントに関する説明は、以下に続く。
【0139】
(重複の検出)
重複の検出サービスが、それが最後に見られた時からそれが修正されない限り、同じドキュメントが再び示されるのを防止するために、フィルタとして機能する。表題、ソースまたはバージョンの重要でない違いだけについては、例えば、ユーザーが質問をDOCコレクションに提出して、重複を含むドキュメントのリストを受けとるときに、重複ドキュメントの問題は起こる。これは、例えば、ニュース記事に起こり得、それは共通コンテンツレポジトリー部に記事を提供する多くの新聞において同様に報告され得る。ニュース検索から戻されるドキュメントの30%と同程度多くのものは重複ドキュメントのセットの部材であり得ることが分かっている。重複ドキュメントのセットの中で、重複と思われ得る全てのドキュメントの半分以上は、正確な重複のカテゴリに分類される。しかしながら、非常に類似しているが同一でないドキュメントを検出するための重複のよりあいまいな概念を含むことはまた面白いかも知れない。
【0140】
2つのテキストストリングの比較として、アブストラクトの充分なレベルで、ドキュメント重複の検出は調査することができる。しかし、このとき、引用および候補ソースドキュメントの代わりに、1つはドキュメントおよび候補ソースドキュメントを有する。上部のn(nは比較的少ない整数である)のドキュメントidf条件(各々と関連して特長およびそれらの位置を含む)が、比較のために、ドキュメントの「指紋」を提供するのに十分であると決定された。ここで、idfは、「逆のドキュメント頻度」を意味し、与えられた条件が、条件の「ドキュメント頻度」の逆であり、すなわち、1が、条件を含む考慮の基で、コレクションのドキュメントの数によって分けられる。
【0141】
この指紋は、重複検出システムで使われる各々のドキュメントのためのメタデータ分野として準備されなければならない。それは、ドキュメント入力時に実行されなければならない計算作業を提供する(ドキュメント収集がすでに共通コンテンツレポジトリーに収納されるために、それは後でなされ得るが)。重複を含み得る検索結果が成されるときに、実際に指紋比較をする計算負荷を広げるのを助けるために、比較作業は、クライアント側(検索要請はそれから始まる)およびサーバー側で分けられる。このように、重複の検出は、基本的に次の3つのステップを含む。
【0142】
(A.メタデータ生成−バッチロードプロセスの間)
ドキュメント入力セッションの間、各々のドキュメントのために、完全なドキュメント署名(signature)がメタデータ(長さスカラー+指紋ベクトル)の形態として格納される。
【0143】
ドキュメントの「長さスカラー」(表題、著者および他のヘッダ情報を含む特徴で)が、署名(背丁)の一部として格納される。
【0144】
「指紋ベクトル」は、例えば、『言葉のごまかし[76]、人質[O]、顕著な[25]、非妥協性[121]、残忍性[163]、シアター(theater)[13]』(idf値によってランクした)、などの互いに関連するそれらの位置とともに、ドキュメント(ヘッダ情報を除外する)の上部n(nが4〜30、好ましくは4〜6、最も好ましくは6である)のユニークなidf条件から成る。
【0145】
考慮中の条件は、ドキュメントのタイトル、および他の見出しを排除することに注意されたい(なぜなら、異なるタイトル、発行者、編集等によって、これらは明らかに変わり得るので)。
【0146】
さらに、異常に高いidf(すなわちidf>0.8)は、トップ6の候補とは思われないことに注意されたい。なぜなら、これらは異常(すなわちタイプミスおよびミススペル)である傾向があるので。
【0147】
指紋ベクトルは、それから、対処可能な長さのキーにハッシュされる、例えば[!X9V^4#w+z2%7t$d](16バイト)。それらが二回以上ドキュメントに記載される場合であっても、ドキュメントの最も高いidf条件は、一回ベクトルの一番上のnのidf条件に現れ得るだけである。
【0148】
(B.ドキュメント比較処理−サーバー側に検索結果リストが与えられる)
サーバーに、検索結果のトップランクのドキュメントおよびそれとまだ比較される次のドキュメントが始まる。
【0149】
ドキュメントの長さが比較される、仮に、比較ドキュメントが、ベースドキュメントの±M文字の範囲内である場合は(例えば、Mが0〜256、好ましくは40文字)、続ける;そうでない場合は比較が終わる(±Mが、ヘッダ材料の近くでテキストの潜在的な差異を補償するのに役立つ)。
【0150】
ドキュメント指紋が次に比較される。仮に比較ドキュメントがベースドキュメントのそれと同一の指紋を有する場合、重複として重複ドキュメントにフラグを付ける、そうでない場合は、比較を終える。
【0151】
重複の状況のためにフラグを付けられたドキュメントは、クライアント上の重複フォルダに効果的に移動される。
【0152】
すでに重複のためにフラグが付けらない次の最高にランクが付けられたドキュメントは、以前にフラグが付けられない結果リストの下の順位の他の全てのドキュメントと比較される。
【0153】
そのプロセスは、フラグが付けられないドキュメントの最後の一対が比較されるまで続く。
【0154】
(C.ドキュメント翻訳−クライアント側)
(1)重複のないドキュメントは、標準の検索結果リストに記載される。
(2)重複を有する最高位のドキュメントは、標準の検索結果リストに記載される、しかし、それらの対応する重複のドキュメントが、「重複」フォルダ(例えば、スクリーンの下側の左手の隅に見られる)において見られることを示すためにマークされる。
(3)残りの重複のドキュメントは、「重複」フォルダにおいて見られる。
【0155】
この重複の検出システムを実行することは、いくらかのさらなる考慮を含む。
【0156】
最高にランク付けされたフラグのないドキュメントは、標準の結果リストに維持される。
【0157】
idfsは、時間とともに疑いなく変化する。idfsが得られるコレクションが変化する場合、今日発生する指紋は、来年発生する指紋に対応しないかもしれない。周期的にドキュメントの指紋を再生する必要性を回避するために、それから、idfsスコアを基にする大きな安定したコレクションを維持することは重要である。あるいは、一旦大きな安定したコレクションが決定されるならば、条件およびそれらの対応するidfsは、単に参照表に経済的に格納され得る。
【0158】
ニュース記事のようなドキュメントにおいて、全てのnの上部idf値の条件が同じパラグラフから来ることは可能である。これは、このように乏しいクロスドキュメント範囲を表すようである。しかしながら、およそ1ページの平均の長さで、ニュース記事は長くない。全てのnの高いidf条件が、1つの比較的小さい場所で起こることが非常に低い可能性である場合であっても、これはそれらのドキュメントの範囲がいかなる形であれ減弱するということはできない。ドキュメントの他のセクションにおいて最も高いidf条件の欠如もまた検出に役に立つので、指紋範囲は完全なままである。
【0159】
指紋ベクトルをハッシュ(hash)することを選択せず、その代わりに、比較されるベクトルの条件の±1、±2又は±Nの関係を許すことによって、ある程度の「不明瞭」を重複の検出プロセスに加えることができる。このように、システムを重複の検出の所望のレベルに合わせるために、2つのドキュメント間の指紋および/または長さスカラーパラメータが、規定のマルチファクターに対して測定でき、類似閾値に調整可能である。
【0160】
ハッシュすることは、比較されるドキュメント署名に厳格に余分のレベルを加えることができる。なぜなら、idf値における適度の変化は、最高のnのidf条件のオーダーを変えることができ、条件自体でないからである。そのため、用語A[0]の中でハッシュ、用語B[25]の中でハッシュは、用語B[25]、用語A[0]・・・とは異なる。従って、idf算出が標準のマスターコレクションを使用して安定しない限り、より多くの比較は上記の現象のゆえに失敗し得る。
【0161】
(ドキュメント翻訳コンポーネント)
ドキュメント翻訳コンポーネントは、ドキュメントをアプリケーション特殊スタイルシート(application−specific stylesheet)にマップする。各々のドキュメントは、ARサーバー標準に従って、スタイルシート参照タグで埋められる。翻訳コンポーネントは、外部入力を必要とする。これらの入力は、アプリケーション開発者のカスタムスタイルシートおよび付随するスタイルシートGUIDへのスタイルシートのマッピングを含む。入力は、ファイルシステムおよび共通のコンテンツ保管システムを使用している翻訳コンポーネントによって検索される。
【0162】
ドキュメント翻訳サービスは描きおよびXSLスタイルシートを蓄える。リソースアプリケーションは、toHTML()を使用してXMLのスタイルを整える。図19は、ドキュメント翻訳がどのように最小のプレゼンテーションスタイルシートを続行するかについて模式的に示す。図20は、ドキュメント翻訳がどのようにカスタムスタイルシートによって、そして、多数のスタイルシートマップによって続行するかを図式的に示す。
【0163】
(お気に入りオンラインアプリケーションの具体的なインフォメーション格納)
このサービスは、ユーザーが日常的に使用するドキュメント、コレクション、検索文字列またはセットを選択、格納およびアクセスできるようにする。このコンポーネントは、また、ユーザーが、そのユーザーのためそのドキュメントに格納される所与のドキュメントにコメントを加えることができる。格納され得る情報の他の実施例は、保存されたサーチ(Saved Searches)、ドキュメントに対する保存されたクイックリンク(Saved Quick Links)、アラートデフィニションに対する保存されたクイックリンク(Saved Quick Links)を含む。その情報は、ユーザーによって操作され得る動的な階層として格納される。特徴は、従来のウェブブラウザのお気に入り特徴と類似している。
【0164】
(画像転換)
JPEGに対するTIFFの共有サービス/ツール変換の画像転換コンポーネントが撮像を表わし、又は他の画像フォーマット転換を実行する。コンポーネントはさらに、画像および支持画像操作の大きさを変更するための特徴を支える。上記は、スケーリング、回転、クロップ(cropping)、フィルターを含む。従来の画像転換コンポーネントが使用され得る。
【0165】
(ローカル化)
このコンポーネントはユーザーに、個々に彼らのローカルユーザーインタフェースを修正し、カスタマイゼーション(custornization)を提供することを許容する。例えば、ユーザーインタフェースは、スペイン語に翻訳されることができ、または特定の市場のためスペイン語で開発され得る。さらに、自然言語の調査が許される範囲で、ローカル化は、英語検索エンジンの全て又は一部はローカル言語に特有の検索コンポーネントと交換されることを必要とし得る。
【0166】
ローカルは、言語、地方およびこれらのバリエーションによってユーザーのために特定され得る。テキストおよび画像の両方は、ローカル化され得る。1つのプロパティはファイルし、そして、1つのディレクトリはローカルにつきセットアップされる。
【0167】
(アラートAPIおよびサービス)
アラートサービスは、選ぶ顧客が質問を検索することを許容し、それは指定された間隔で動作する。検索の質問が新しい結果がを出すたびに、検索結果はエンドユーザーに送られる。アラートサービスは、電子メールおよびファクシミリ用の共有サービス/ツールドキュメント送達メカニズムを使用する。以下のコンポーネントは、アラートサービスの一部である:アラートエントリを保つためのデータベース;ユーザーインタフェースからアラートエントリを操作するためのAPI;アラートエントリを行い、結果を顧客に伝えるためのサービス。これらのコンポーネントは、各々のリソースアプリケーションが、それらの特定のアプリケーションのための同じアラートサービスを使用できるようにする。
【0168】
図16に好適に示されるように、あらゆるユーザーに対する警告は、警告API1602を使用したディレクトリへのエントリーを伴って設定される。警告エントリーは、作成され、修正され、削除され、あるいはランされる。警告エントリー内において定義されるドキュメント選択データをランする頻度は、毎日、ウィークデイ、毎週、隔週、毎月に設定可能であり、あるいは保存される。警告サービス1604は、コモンコンテンツレポジトリー1606および警告データベース1608と情報交換し、続いてクリップしたドキュメントをドキュメントはデリバリーサービス1610を介してデリバリーする。ユーザーは、マルチプルDOCコレクションを利用できる。
【0169】
(ドキュメントデリバリーAPIおよびサービス)
デリバリーサービスは、ユーザーにオンラインドキュメントの物理的あるいはローカルな電気的コピーの作成を可能にする。デリバリー機能は、調査処理のあらゆる場面においてアクセス可能である。ドキュメントをデリバリーするために、ユーザーは、一般に以下の情報を特定する:デリバリー内容、包含(inclusions)、省略、デリバリー先、およびフォーマット。
【0170】
デリバリー内容を決定するために、リソースアプリケーションは、特定のドキュメントあるいは所産のためのデリバリー機能にアクセスするための少なくとも1つの方法を提供すると想定される。直接的指示(例えば、ページ上のボタン)あるいは間接的指示(例えば、プリントリンク)によってなされるかは、機能的には同一である。一般には、全体のドキュメントあるいは所産(artifact)がデリバリーされると想定される。大きなドキュメントに対しては、ユーザーには単にドキュメントの特定部のみがデリバリーされ得る。テーブルコンテンツのような手段が、ドキュメント部分の選択に使用できる。
【0171】
何を含有しあるいは省くかの決定に際し、デリバリー操作のディフォルトモードは、全体テキスト、ならびに映像および特殊なドキュメントに伴うテーブルの全体セットを含む。ドキュメントタイプあるいは他のプロパティに応じて、追加アイテムがデリバリージョブに追加され、あるいは削除される。ユーザーに、各アイテムがドキュメントタイプに適合するかのチェックは、はずされる。
【0172】
デリバリー先は、ユーザーの選択およびデリバリー先装置の有効性に基づいて決定される。例えば、デリバリー先は、添付のプリンタ(ユーザーコンピュータあるいはLANに添付されたプリンタ)、Eメールアドレス(プリントジョブに代えて、ファイルのフォーマットコピーがユーザーのEメールアドレスに送付される)、ファックス(ファイルのフォーマットコピーがユーザーのファックスアドレスに送付される)、あるいはダウンロード(ファイルのフォーマットコピーが、ユーザーによって特定されたデリバリー先のユーザーコンピュータのハードディスク上に保存される)を含み得る。ユーザーは、デフォルトとしてデリバリー先を選択するまで、デリバリー先アドレスを特定する必要はない。
【0173】
デリバリー(および多様な他のオプション)のためのユーザーの選択は、リソースアプリケーションおよび共通サービス/ツールのためのデフォルトバリューを保持するファイル内に特定されている。
【0174】
ドキュメントデリバリー用にサポートされたフォーマットは、HTML、RTF、PDF、PostScriptおよびテキストファイルを含む。図18Aおよび図18Bは、ドキュメントデリバリーに含まれる種々のコンポーネントの関係を示す。デリバリーされるドキュメントは、ドキュメントを表示コンポーネントに提供するデリバリーサービスによってアクセスされる格納装置に一時的に保持される。デリバリーサービスは、表示コンポーネントを有し、XMLおよびXSLtドキュメントを取り入れる。それは、これらをXSL FO、HTMLおよびテキストフォーマットにおいてデリバリーする。XSL FOプロセッサは、SMTPメールによって送信可能なHTMLおよびPDF/PostScriptドキュメントを作成する。RTFプロセッサは、RTFドキュメントをウェブ(Web)に提供する。テキストを含むHTMLドキュメントもまた、デリバリーされ得る。
【0175】
(トレイルAPIおよびサービス)
トレイルサービスは、再作成可能なアプリケーションイベントの相互交流のあるヒストリを維持する。これによって、ユーザーは、ドキュメント結果を再作成するリサーチイベントを再開発する要求をすることなく、即座にドキュメントを発見することができる。すなわち、システムは、結果として生じるドキュメントのテキストではなく、共通コンテンツ保管場所および作成結果の問い合わせによって実行されるようなリサーチに関する情報を保持する。例えば、各ドキュメントはGUID(Global Universal Identifier)によって識別され、また「Best−of−the−searched−GUIDs」は、参照のために、トレイル機能によって格納される。常時ユーザーは、作成されたリソースアプリケーション、ユーザー要求のトレイルおよび修正のうちの1つに関する新しいセッションを開始する。ユーザーが以前の要求に戻る必要がある場合、トレイルコンポーネントは、サーチプロセスの間に設立されたトレイルを使用してドキュメントへの即座なアクセスを提供する。トレイルコンポーネントは、また、ユーザーにトレイルを保存あるいは以前のトレイルへのアクセスを可能にすることによって、以前のセッションからのサーチの利用をユーザーに可能にする。
【0176】
トレイル機能は、トレイルデータベース1702(図17参照)に保持されたデータ構造内のユーザーによって実行された操作シーケンスを収集することにより、ユーザーに、簡易で迅速な方法によって以前のサーチを可能にする。トレイルディレクトリは、作成、削除、変更および回収作業を特定するために使用される。トレイル機能は、ユーザーにアクセスを与え、ユーザーにトレイルデータの操作を許可する。
【0177】
トレイル記録はサーチセッションの間に形成され、データ構造としてリソースアプリケーション内に保持される。トレイルデータ構造は、特定のパスワードに特定さてれおり、そこでは、認証手段、その上クライアントIDによって記録される。トレイル内に記録されたイベントは、基本的に変更可能なリサーチイベント、例えば最初のドキュメント取り込み、サーチおよび引用要求に対応し得る。イベントをクリックすることにより、ユーザーはドキュメント、サーチへの戻り、あるいは引用等にリターンすることができる。
【0178】
リソースアプリケーションは、ユーザーに、リサーチセッションの間、いつでもトレイル設備へのアクセス(トレイルイベント需要者1706を介して)を可能にする。同様に、トレイル設備は、ユーザーに、リサーチセッションへの離れた地点への継続的な再入力を可能にする。
【0179】
アプリケーションは、トレイルワークを以下の追跡方法によって進行する。アプリケーションは、ニュートレイルを作成し、特定の情報(例えば、トレイル名、プロダクト、ユーザーID、クライアントID等)を設定する。トレイルはまた、作成データ、最終アクセクデータ、および期限切れデータを含む。追加パラメータも定義可能であり、特にプロダクトによって利用可能である。この「プロパティ」は、データベース検索ができないXMLストリングに格納される。その他、アプリケーションは、特有のトレイルキーによって、特別に先存するトレイルを得る。
【0180】
プロダクトの「再作成可能イベント」(例えば、サーチ結果、ドキュメント)のために、アプリケーションはニュートレイルアイテムを作成し、それをトレイルに加える。トレイルアイテムは、アイテムタイプ(例えば、サーチ、ドキュメント)のような特別情報を格納し、またデータを作成する。特にプロダクトによって定義されかつ使用される追加パラメータは、格納可能である。これら「プロパティ」は、XMLストリングに格納され、また、プロダクト用のイベントを再作成するために使用可能である。
【0181】
システムはトレイル要求をキュー(queue)に置き、バックグランドサービスがその要求を処理する。FIFO(First−In−First−Out)フォーマットが、要求を処理するために使用される。サービスは、新規要求のためのキューを継続的にモニタする。データベースエラーが発生した場合、キューはバックアップされ、トレイル情報をユーザーに対して遅延する。それは、アプリケーションの実行をスローダウンさせない。
【0182】
リソースアプリケーションは、利用可能な最もアップデートなトレイル情報を調べる。アプリケーションは、需要者のためにトレイルアイテム(例えば、再作成可能なイベントへのリンクを伴うウェブページ)のリストを作成するために、トレイルAPI1708を使用する(イベントの再作成は、特別がプロダクトのために正当な請求イベントがビジネスルールに基づいて作成されあるいは回避されることを確認するアプリケーションによってコントロールされ、そのためイベントはトレイル上に再作成されないことに、留意を要する)。
【0183】
アプリケーションは、ユーザーセッションが終了したとき、あるいはアプリケーションが明らかにトレイルを終了したとき、トレイルを終了する。
【0184】
トレイル情報の他の使用は、ユーザーの要求および期待に適合するためのシステム改善にある。そのため、要求メッセージに応答して見出されたドキュメント用の特別なリソースアプリケーションおよび識別子の範囲内の、ユーザーサーチ処理に関する情報を保持する1つ以上のトレイルファイルを、システムが有する場合、この情報は、特別なリソースアプリケーション用の共通使用パターンを決定するトレイルファイルを処理するためのトレイル分析コンポーネントに対して、提供可能である。この分析は、検索オプションを提供するために、およびそのような使用パターンに、より適した結果を検索するために、リソースアプリケーションのパラメータ調整に導かれ得る。
【0185】
ドキュメントが検索結果として存在している優先オーダーに関連する検索結果内で識別されているドキュメントをユーザーが表示しているシーケンスを含む、共通使用パターンを、その分析がもたらす場合、調製されたパラメータは、ドキュメントが検索結果として存在している優先オーダーに影響を与え得る。その分析が、検索結果内に識別されたドキュメントのユーザーレビューが複製(duplicate)として含まれる共通使用パターンをもたらす場合、調製されたパラメータは、二重の検出サービスのための類似閾値に影響を与え得る。また、トレイル分析は、そのような使用パターンを具体化し、それに関連するリソースアプリケーションに適合させるために、メタデータ内に捕らえられている共通使用パターンに導かれ得る。例えば、リソースアプリケーションの最も経験豊富なユーザーのトレイル分析が、TOCブランチの少ない利用、あるいはTOCノードからの探査のある種のパターンを示す最も実際的なTOC使用パターンを表す場合、これは、ベストの実施と見られる具体化として提供され、また経験の少ないユーザーにとっても価値あるものとされ得る。
【0186】
(イベント課金/ロギングAPI)
共有されるサービス/ツールは、リソースアプリケーションの作成者に、ウェブアプリケーションからの課金記録を作成することを可能にする。課金記録は、一般的であり、リソースアプリケーション作成者に課金要求に必要なデータを獲得させる。APIはXMLに必要なデーダを提供し、しかしながら、リソースアプリケーション作成者は、一般的XMLをその課金システムに適正なフォーマットへの変換するリソースアプリケーションの提供に対する責任がある。
【0187】
APIは、リソースアプリケーションの特別の名前/価値ペアを伴うイベントを作成する。課金/ロギング機能は、課金イベント情報をビジネスシステム需要者にデリバリーする。ある種のデフォルトプロパティが課金イベントのために存在する:スレッドバリュー、機械名、ファイル更新記録、およびイベントGUID(イベントのためのグローバルな特有ID)。
【0188】
(セキュリティサービス:セキュリティおよびアクセスコントロールAPI)
セキュリティおよびアクセスコントロールの1つの部分は、サインオンおよびサインオフを含む認証を含む。このサインオン操作はユーザーを識別し、そしてリソースアプリケーションリサーチセッションを開始する。サインオンは、ユーザー識別子(ユーザーid)およびユーザー認証子(バスワード)を必要とする。これらは、リソースアプリケーションによるか、またはユーザーにより生成され得、(特有の識別子文字列が提供される限り)エイリアスを思い出す容易さを含む。このサインオフ操作は、このセッションを閉鎖する。
【0189】
アクセス制御操作は、リソースアプリケーションが使用法および/または制限アクセスをモニターすることを必要とする;ユーザーが個々またはグループを基礎にインターフェースのカスタム化を必要とする;アクセスが、コンテンツおよび/または機能レベルでモニターされなければならない;ユーザーアクセスが同じコンテンツを参照するアプリケーションタイプを横断して共有されなければならない(例えば、同じコンテンツコレクションへのウェブおよびインターネットアクセス);またはユーザーアクセスが複数のリソースアプリケーションを横切って共有されなければならないとき必要である。
【0190】
本発明とともに、複数のリソースアプリケーションが、共通システムを横切ってリンクされる。従って、認証プロセスは、ユーザーが使用する権利を有する種々のリソースアプリケーションのすべてについてユーザーにアクセスを提供する。しかし、これら種々のリソースアプリケーションが、それら自身の使用法要求および請求パラメーターを有するとき、この使用法をトラックかつ請求するアプリケーションへのユーザーID/パスワードの接続および記録は、各リソースアプリケーションの責任である。換言すれば、共通のユーザープロフィールが生成されかつ利用される。図13は、ユーザー認可情報を基づくユーザーの置き換え、およびそれらの質問メッセージを提供するために、オンラインで共有されるセキュリティコンポーネントが、どのようにリソースアプリケーション1302およびセキュリティデータベース1304中に記憶されたインターネットセキュリティ情報と通信するかの概略図を提供する。図13は、さらに、顧客の定義、製品、価格プラン、認可などを維持するビジネスシステム1306が、どのように、管理サービス1308を通ってセキュリティデータベースにどのようにアプリケーションセキュリティ定義をおすのかを示す。この認可サービスは、このデータベースの維持を可能にするAPIを出す。このAPIは、XMLリクエスト応答メッセージに基づく。リソースアプリケーションに特異的なセキュリティ情報は、その他のアプリケーションによって用いられ得る。
【0191】
共有されたアプリケーションサービス中で履行されるセキュリティは、顧客の一致した表示を提供する。共有されたアプリケーションサービスSecurity Model中にユーザー実体(User entity)を生成することにより、顧客は、各サイトの証明書の特異的セットを思い出す必要性なくして参加サイト(またはリソースアプリケーション)間を容易に移動し得る。これは、ユーザーが、すべての参加サイトについて、唯一のサインオンIDおよびパスワードを必要とし、しかもユーザーの保証書が1つの安全な場所に記憶されることを意味する。
【0192】
従って、ユーザーを認証する共通サイト共有セキュリティは、それら自身の認証システムを構築、購買、ホストおよび維持しなければならないことはないことによって、時間およびお金を節約する。開発者は、それら自身のサイトの特徴および機能性に集中し得る。
【0193】
セキュリティは、ユーザーの基礎的プロフィールを支持する。言語優先およびファーストネームおよび名字のような情報は、アカウント生成時間で集まり得る。セキュリティモデル内のユーザーは、アカウントが生成されるとき、User Guid(グローバル汎用識別子)を割り当てられる。このユーザーを識別するために用いられるのはこの識別である。
【0194】
このセキュリティサービスは、種々のセキュリティタスクを実施する。このタスクは:現存するセキュリティユーザーを認証すること;リソースアプリケーションが認証を実施することを可能にすること;現存するセキュリティユーザーをアップデートすること;新たなセキュリティユーザーをセキュリティデータベースに追加すること;セキュリティユーザーを特定の特徴へのアクセスを認可するためにグループと関連付けるか、関連を解くことを含む。その他のセキュリティ特徴は、容積または価格限界をたどること、受給限界のタイミングをとること、エクスポート制御を含む。
【0195】
図14は、用いられるセキュリティパラダイムを概略的に示す。セキュリティは、ユーザー1402、ユーザーグループ1404、およびユーザーのための認可1406を含む。単一のユーザー定義がすべてのリソースアプリケーションについて用いられ得る。従って、1つのユーザーIDおよびパスワードが、ユーザーが任意のリソースアプリケーションからのドキュメントをアクセスすることを可能にするために用いられ得る。各ユーザーは、一旦性格なIDおよびパスワードが入力されると、利用可能になる特有の許可を認可される。ユーザーIDおよびパスワードが、Security APIを用いてセットアップおよび変更され得る。各認可は、コレクションセットのような特徴1408をリソース1410に関連付ける。
【0196】
ユーザーはユーザーグループに属し得る。ユーザーグループは、ユーザーのクラスを表示し得る。グループ中のすべてのユーザーは、同じ許可で認可される。ここで再び、ユーザーグループが一旦記載され得、そして次に、すべてのリソースアプリケーションによって用いられる。
【0197】
図15は、1つの実施形態についてのセキュリティモデルのコンポーネントおよびそれらの関係を示す。このモデルをセットアップするために、最初に、アプリケーション特異的実体のための名前識別子を規定するドメイン1502をセットアップすることが必要である。これは、アプリケーションを横切る二重の名前、例えば、Fiji:サーチを可能する。Ownerm1504は、次いで、管理者にユーザーIDおよびパスワードを定義する。次に、ユーザー1506が規定される。ユーザーID、パスワードおよびその他のユーザープロフィール情報が割り当てられる。このユーザーGUIDは、この定義の基礎にある。
【0198】
定義されたユーザーがグループの一部である場合、グループユーザーエンティティ1508は、ユーザーのクラスを表すグループ1510へユーザーを追加するために使用される。グループの定義は、一度定義され、あるいは多数のユーザーに割り当てられる許可が認可される際の管理を簡易化する。グループは序列という言葉によって定義され得る。親グループは、1つ以上の子グループを有し得る。子グループは、その親グループから許可を受ける。
【0199】
フィーチャー1512は、セパレート制御あるいは価格設定(例えば、ドキュメント引用、クリッピング)を要求し得るリソースアプリケーション機能として定義される。セキュリティモデルを介して、ユーザーは、特別のコンテンツあるいは機能へアクセスするフィーチャーの使用を許可され、あるいは拒否され得る。コンテンツリソース1514は、セパレート制御あるいは価格設定(例えば、Fijiニュース、Fiji事情)を要求するコンテンツの定義されたサブセットを表す。セキュリティモデルのために定義されたコモンリソースタイプは、DOCコレクションあるいはコレクションセットである。
【0200】
また、アクセスコントロールオブジェクト1516は、セキュリティモデル内において定義可能である。アクセスコントロールは、フィーチャー(例えば、サーチ)を介してのコンテンツリソース(例えば、ワールドニュース)へのアクセス許可を許可あるいは拒否する。そのようなアクセスコントロールは、グループあるいは個々に割り当てられ得る。
【0201】
申し込みが定義されたとき、ユーザー、グループユーザー、グループ、アクセスコントロール、フィーチャー、およびセキュリティモデルのリソース要素は、互いにリンクされる。
【0202】
(マルチティアー環境)
リソースアプリケーションは、ドキュメントを引き出すために特有のプロダクトを作成するために、ARサーバー300およびCCRDSサーバー400のコンポーネントを利用する。
【0203】
図5は、リソースアプリケーションおよびそのインフラストラクチャーを形成する、クライアントティアー、サーバーティアー、およびデータサーバーティアー構造のコンポーネントを示す。クライアント側を表すために1つのユーザーが使用されるが、多数の異なり分散されたクライアントユーザーインターフェースがシステムにアクセスする。クライアントユーザーインターフェースは、オンラインデリバリー環境によって提供されるウェブサーバーをアクセスする。オンラインデリバリー環境は、同様に適正なアプリケーションサーバーおよび特別のユーザーインターフェースに基づくプロトコルを提供する。検索が実行されるとき、共有されるサービスサーバー、ディレクトリサーバーおよびアプリケーションサーバーは、ドキュメントを引き出すためのデータベースへのアクセスを得るために、データティアーと情報交換する。
【0204】
(作成環境)
図7は、本発明に従うリソースアプリケーションのための作成環境を示す。プロセスは、希望プロダクトのフィーチャー、環境サイズ、期待サービスレベル、およびクラスタリングを定義する質問事項によって開始する。作成はまた、実行のための種々のロギング、デバッグ、およびビジネスレポートを含む。設計のスケーラビリティはキャパシティ計画と共に考慮される。管理変更、発行された管理、拡大、および議論フォーラムのためのプロシージャーと同様に、構築および作成のためのツールおよびプロシージャーが、プロセスの作成のために必要である。コンポーネントが作成されるとき、復帰(regression)をテストするユニットおよびストレステストの実行が必要である。また、警告、デリバリー、およびトレイル機能の管理のための種々のツールが作成において使用される。最後に、リソースアプリケーション作成プロセスは、オペレーションシステム、ウェブサーバー、アプリケーションサーバーおよびデータベースのアップグレイドをアドレスしなければならない。
【0205】
先行作成サービスおよびツールがともに使用され、モノタリングが種々のウェブサーバー、アプリケーションサーバー、共有されるサービス/ツールおよびデータベースサーバーのために使用される。加えて、作成プロセスは、共通コンテンツの保管場所のパーツである、オンラインビジネスサービス、ビジネスサービス、共通コンテンツサービスおよび出版コンポーネントを、必然的に求める。
【0206】
本発明は好ましい実施形態を参照して記載されたが、本発明の真意と範囲から逸脱することなく、様々な変更が形態および詳細においてなされ得ることは、当業者にとって認められ得る。
【図面の簡単な説明】
【0207】
【図1】図1は、従来技術の小売システムを示す、略ブロック図である。
【図2】図2は、本発明のシステムが、いかにして、共通のリソース(共有されたサービス)を使用する別個のアプリケーションを利用して、複数のデータ集合に対する共有されたアクセスに基づき、識別されたユーザーのサービスを提供するのかを示した、略ブロック図である。
【図3】図3は、電子的に格納されたドキュメントの大きな集合体を、維持および分配するためのシステムの概観を示す略ブロック図である。
【図4】図4は、ドキュメント問合せおよび検索アプリケーションのためのウェブ−ベースのアプリケーションフレームワーク、および共通のコンテンツレポジトリーソフトウェアシステムとのそのインターコネクションを示すブロック図である。
【図5】図5は、図4のシステムの、クライアント、サーバーおよびデータのトレイルを示す、模式図である。
【図6】図6は、本発明において使用されるドキュメントレコードおよび関連するメタデータレコードの模式図である。
【図7】図7は、リソースアプリケーションを構築するために使用される開発ツールを示す略ブロック図である。
【図8】図8は、ドキュメントの取り込みのためのプロセスを示すフローチャートダイアグラムである。
【図9】図9は、ドキュメントのエンリッチメントのプロセスおよびドキュメントのメタデータ処理を示すフローチャートダイアグラムである。
【図10】図10は、本発明のコンテンツ(TOC)アーキテクチャのテーブルを示す模式図である。
【図11】図11A〜Dは、本発明に従って構築されたコンテンツ構造のテーブルを示す模式図である。
【図12】図12は、本発明に従って構築されたコンテンツの例のテーブルを示す模式図である。
【図13】図13は、本発明において、セキュリティーサービスがどのようにして機能するのかを示す、略ブロック図である。
【図14】図14は、いかにしてセキュリティーが実行されるのか、ならびにユーザーグループおよび許可を示す、関係ダイアグラムである。
【図15】図15は、本発明のセキュリティーモデルについての、定義および関連ダイアグラムである。
【図16】図16は、いかにして、アラートサービスがクリッピングを提供するかを示す、模式図である。
【図17】図17は、いかにして、トレイルサービスが機能するのかを示す、模式図である。
【図18A】図18Aは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。
【図18B】図18Bは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。
【図19】図19は、いかにして、ドキュメントレンダリングが、最小のプレゼンテーションスタイルシートとともに機能するのかを示す、略ブロック図である。
【図20】図20は、いかにして、ドキュメントレンダリングが、あつらえのスタイルシートおよび複数のスタイルシートともに機能するのかを示す略ブロック図である。
【技術分野】
【0001】
本発明は、データレポジトリーのアクセスおよび利用のために作製された、大規模の電子的データレポジトリーおよびソフトウェアアプリケーションにおける、データ、特にドキュメントの配布およびマネジメントに関する。
【背景技術】
【0002】
コンピュータおよびウェブ−ベースアプリケーションの使用にともなって、非常に大量の情報が、エンドユーザーにとって、オンラインでアクセス可能となり得る。近年、オンラインデータベースが、コンテンツにおいて特化され、特定のタイプの記録(例えば、商標、または特定分野の技術文献)のみを網羅する。従って、データベースおよびアクセスツールは、特に、そのコンテンツを念頭において、設計された。複数の情報に対するニーズを有するユーザーは、図1に示す環境が、強いられる。各情報は、必須とされる別個のシステムでの作業およびその特定のユーザーインターフェース(特定のデータベース(または関連するデータベースのセット)に対するアクセスを提供し、その情報リソースに特有のアクセスソフトウェアおよび課金ソフトウェアによってサービスを受ける)を必要とする。大量の格納能力および速度の改善によって、データベースが非常に大きなサイズに成長することを可能にし、そして単一のプロバイダによって、複数のデータベースを提供することを可能にする。
【0003】
しかし、コンピュータ化された情報の集合のサイズの増加、および、検索速度に対するユーザーの期待、および、使用のユーザー−フレンドリーの形式、およびドキュメントデリバリーは、情報プロバイダの変化をもたらす。過去から受け継がれたユーザーインターフェースおよびアクセスシステムは、しばしば、それを使用することに対して非常に慣れた者に対してのみユーザー−フレンドリーであり、特定のコンテンツに対して調整されたほとんどのユーザーインターフェースおよびアクセスシステムは、お互いに異なり、そのことのために、ユーザーが1つのシステムから、他のコンテンツのためのシステムに移動することを困難となる。たとえ、ユーザーがその差異を受け入れることができたとしても、オペレータは、ただ単に、別個の過去から受け継いだシステムを、より大きな格納デバイスを有するより早いプロセッサにロードすることは、効率的でないことを見出している。
【0004】
さらに、1つの過去から受け継いだシステムを用いて、別のシステムのデータベースにアクセスして、共有することは、通常、不可能出ない場合でも、困難である。たとえ、過去から受け継いだデータベースが、過去から受け継いだシステムの間で共有することができたとしても、他の非効率性の問題が生じ得る。しばしば、同一の情報が、異なるユーザーによって、異なる目的のために、求められる。従って、同一の情報は、複数のリサーチリソースまたはチャンネル(例えば、法律または金融ドキュメントサービスに対するニュースサービス)を通して、異なるタイプのユーザーにとって、利用可能とされ得る。同一の情報を、複数のリソースを通して利用可能とするために、データは、しばしば、重複し、そして異なるデータベースに格納される。さらに、異なるユーザーの問合せアプリケーション(ユーザーインターフェースと関連するものを含む)は、各別個のデータベースにアクセスするために使用され得る。このような構造は、典型的に非効率的である。なぜなら、これは、重複した、開発およびサポートのための努力、ならびに重複した情報の格納を必要とするからである。さらに、このことは、変化した顧客の関係または市場の状況に応答して、既存のシステムを変化することを、困難にする。
【0005】
情報プロバイダにとって、2つの基本的な目的は、ユーザーに売却するために利用可能な情報を最大化し、そして情報の売却におけるフレキシビリティーを最大化するということである。これらの目的は、情報プロバイダが、情報プロバイダが、多くの異なる種類のユーザーに対してアピールすることができ、異なるレベルのアクセスおよびデリバリーのモードを提供することができ、そしてコンテンツおよび形式について調整された情報をデリバリーすることができることを意味する。これらの目的を追求することは、情報プロバイダが、異なるユーザーに異なる商品および価格決定を適合させ、そして新規のコンテンツおよび顧客を追加することにおいて、より大きなフレキシビリティを提供する。
【発明の開示】
【発明が解決しようとする課題】
【0006】
これらの目的に取り組むために、複数のユーザーが、異なるアプリケーション(ウェブ−ベースまたはそれ以外)から、同一の情報にアクセスすることを可能にする、集中化された情報データベースおよび情報マネジメントシステムが必要である。さらに、電子的に格納されたドキュメントの大きな集合体にアクセスするための、そのようなアプリケーションを構築するために、効率的なアーキテクチャ/インフラストラクチャモデルがさらに必要である。
【課題を解決するための手段】
【0007】
(発明の簡単な要旨)
1つの実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムである。
【0008】
別の実施形態において、本発明は、電子的に格納されたドキュメントの大きな集合体を維持し、そしてそれらドキュメントを、問合せメッセージを出すユーザーにとって利用可能にするためのシステムであって、このシステムは、ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有するデータ集合を備える。このシステムはさらに、少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント、および、受け取ったドキュメントを処理して、ドキュメントを富化するための、エンリッチメントコンポーネントを、備える。このシステムはさらに、データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント、少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント、ならびに、ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネントを、備える。
【0009】
別の実施形態において、本発明は、問合せメッセージを処理するシステムであって、このシステムは、問合せメッセージを入力するための、1つ以上のユーザーインターフェースであって、ここで、この1つ以上のユーザーインターフェースの各々は、リソースアプリケーションに適合する、ユーザーインターフェース、問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合、および、その1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、1つ以上のメタデータ情報ファイルを備える。このシステムは、さらに、1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、この取入れ口コンポーネントは、新規ドキュメントからメタデータを作成し、そして、1つ以上のデータ集合において、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、を備える
別の実施形態において、本発明は、問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法である。この方法は、ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、少なくとも1つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程、および、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、サーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程、を包含する。この方法は、さらに、問合せメッセージに対する応答において、ユーザーに対して、1つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程、および、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、ユーザーに関連するユーザープロファイルに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程であって、リソースアプリケーションにおいて具体化され得る、工程、を包含する。この発明はまた、選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、を包含する。
【0010】
別の実施形態において、本発明は、問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、少なくとも1つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネントを備える、伝達媒体において具体化されたコンピュータデータシグナル。この媒体はまた、問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、サーチコンポーネントに対してデリバリーされる、問合せメッセージに備えるコードコンポーネント、および、1つ以上のドキュメントを同定するサーチ結果メッセージを、問合せメッセージに応答してユーザーに提供するためのコードコンポーネントを備える。この媒体はまた、ユーザーと関連するユーザープロファイルに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答するコードコンポーネント、を備える、コンピュータデータシグナル。
【0011】
複数の実施形態が開示されるが、本発明のなお別の実施形態が、以下の詳細な説明に従って、当業者に明らかとなる。明かであるように、本発明は、全て本発明の趣旨および範囲から逸脱することなく、種々の明白な局面において、修飾され得る。従って、図面および詳細な説明は、発明の性質を例示するもと看做されるが、限定するものではない。
【0012】
(詳細な説明)
(A.システムの概観)
図2は、いかにして、本発明のシステムが共通のリソースまたは共有されたシステムサービスを用いて、メタデータ50を有する複数のデータ集合30に対する共有されたアクセスに基づいて、ユーザー6に対して、識別された情報リソースサービスを提供するのかを示す、ブロック図である。より具体的には、図2は、いかにして、複数のユーザー6(例えば、金融ニュースに興味を持つユーザーa、法律ドキュメントに興味を持つユーザーb、および技術および特許ドキュメントに興味を持つユーザーz)が、システムと相互に作用し得る。(これら興味の対象は、例示である;ユーザーは、法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース情報、あるいは、これら分野の特定の部門。)各ユーザーは、それぞれのユーザー問合せメッセージQa1、Qb1、およびQz1を送り、これらは、ユーザーのそれぞれのリソースアプリケーションソフトウェア15(例えば、リソースAppA、リソースAppB、およびリソースAppC)によって受け取られ、これらの各々は、その情報ソースに対して購読し、そしてアクセスを購入するユーザーの特定のドキュメントのニーズに対して役に立つように、設計される。リソースアプリケーション15(リソースAppA、リソースAppB、およびリソースAppC)の各々は、それぞれのユーザー問合せメッセージQa1、Qb1、およびQz1を、共有システムサービス/ツール20(各リサーチリソースを含む情報リソースフィーチャーを提供するために必要な種々の機能を実行するソフトウェアとハードウェア)のセットに対して送る。
【0013】
概観するために、より重要な共有されたサービス/ツールは、サーチサービス(ユーザー問合せを処理して、問合せに応答する1つ以上のドキュメントを見出す)、会計サービスおよびビジネスサービス(情報の小売を可能にする)である。共有されたサーチサービスは、適切なデータ集合30(関連するメタデータ50を含む)のコンテンツを分析し、これらの各々は、関連するメタデータ50を有す1つ以上のドキュメントを含む。単純化のために、各データ集合を、2つのドキュメントのみを有するとして示す。従って、データ集合は、ドキュメントD11、D22を有し、データ集合2は、ドキュメントDn1、Dn2を有する。各ユーザーは、1つのみのデータ集合30に対するアクセスを提供する購読を有し得、そして各ユーザーのアクセス可能なデータ集合は、他者のものとは異なり得るが、システムは、限定されない。図2の例において、ユーザーaは、データ集合にアクセスする問合せを送り、その一方で、ユーザーbは、データ集合1およびデータ集合2の両方にアクセスする問合せを送った。さらに、ユーザーzは、データ集合2およびデータ集合zの両方にアクセスする問合せを送った。
【0014】
ユーザーaは、ユーザーの問合せQa1に応答して、データ集合からドキュメントD11aを受け取る。デリバリーされるD11aは、リソースAppAのフィーチャーに基づき、特定の形式であり、そしてD11として格納されたドキュメントのフォーマットである。ユーザーbは、その問合せQb1に応答して、データ集合から2つのドキュメントを受け取る(データ集合1からのドキュメントD11(問合せQa1に応答するドキュメントと同一のドキュメント)およびデータ集合2からのドキュメントD21)。図2において示されるように、ユーザーに対してデリバリーされるドキュメントD11は、リソースAppBがD11として格納されたドキュメントをデリバリーする形式またはフォーマットD11bとは同一ではない、リソースAppAによって決定される特徴的な形式、またはフォーマットD11aとして与えられ得る。ユーザーzはまた、問合せQz1に応答して、2つのドキュメントを受け取る(データ集合2からドキュメントD22、データ集合nからドキュメントn2)。再度、リソースAppzは、リソースAppzのフィーチャーに基づいて、D22およびDn1として格納したドキュメントの特定の形式またはフォーマット(すなわち、D22zおよびDn2z)において、これらドキュメントの各々を、受け取る。従って、図2は、2つの異なるリソースアプリケーション15が、各々同一のデータ集合30にアクセスし得、そして実際にその集合中の同一のドキュメントにアクセスし得ることを示す。さらに、図2は、各リソースアプリケーション15が、共有されたシステムサービス/ツール20を利用するが、そのユーザーに対してデリバリーされたドキュメントを、別のリソースアプリケーションによってデリバリーされた同一のドキュメントのデリバリーされた形式/フォーマットとは、いくぶん異なる形式またはフォーマットにし得る。サービスおよびデータレベルでのリソースは、共有されるが、ユーザーにデリバリーされる結果は、異なり得る。
【0015】
図3は、電子的に格納されたドキュメントの大きな集合体を維持しそして分配するためのシステム(図2において機能的に考察されるものを含む)の概観を示す略ブロック図である。より高いレベルの機能エレメントが、示される。これらの格納されたドキュメントは、多様なユーザーの集団によって利用可能とされる。システムのエレメントとしては、1つ以上のリソースアプリケーション(RA)ユーザーインターフェース10a、10b、...10n(ユーザーのための種々の静止スクリーンおよびインタラクティブスクリーンにアクセスし、および/または作成してデリバリーし、そして、1つ以上のユーザーメッセージ12a、12b、...12nを入力として引き出して受け入れる);共有されたサーチコンポーネント22;1つ以上のデータベースまたはデータ集合30a、30b(単純化のために、2つのみが示される);共有されたドキュメントデリバリーコンポーネント40;1つ以上のメタデータファイル50a、50b(再度、単純化のために、2つのみを示す);および新規ドキュメントキュー70、エンリッチメントコンポーネント80を伴い、プライオリティーコンポーネント90およびGUIDコントロール100を含む。
【0016】
各RAユーザーインターフェースは、10a、10b...10nは、1つ以上の主題領域中の情報アクセスリソースとして供されるソフトウェアのコレクションである、リソースアプリケーション15a、15b...の一部である。リソースアプリケーションは、特定の所望の市販の提供(すなわち、「製品」)を具現化、および/または得意のユーザー必要性またはユーザープロフィールに応答する。従って、1つのリソースアプリケーションは、その他から、それ自身を:アクセス可能なコンテンツ/主題の事項;ドキュメントエンリッチメントの程度、ユーザーインターフェース特徴;ドキュメント送達フォーマットまたはモード;正確さ;および特定のリソース必要性またはユーザーマーケットに対するその他のアピール特徴によって区別し得る。
【0017】
本発明の種々のコンポーネントは、異なるリソースアプリケーションを横切る記憶されたドキュメントの本質的に縫い目のないコンテンツを共有すること、および種々の様式でアクセス(例えば、ウェブサイト、インターネット、エクストラネット、ワイアレスなど)を可能するツールのセットを提供する。本発明はまた、リソースアプリケーションへの共有されたサービスおよびツールを提供するための、共通リソースアプリケーションインフラ構造(ARサーバー300、図4)による履行を含む。情報販売、セキュリティおよび請求書発行サービスは、重要な共有サービスである。各リソースアプリケーションは、共通コンテンツレポジトリーおよびデータサーバーソフトウェア(CCRDSサーバー400、図4)により記憶および維持されたドキュメントの少なくとも一部分へのアクセスを容易にすることにより、特定のユーザープロフィールおよびマッケットプレイスをサービスするために開発されている。リソースアプリケーションついて規定し、かつ履行することの利点は、共有サービスおよびツールのセットは、以下に論議されるようなものを含み:再使用可能性,アプリケーションを開発するための減少した時間、および新たなアプリケーション開発のための低減されたコストを含む。
【0018】
本発明に適用可能な1つのシステムでは、データの大きな塊が、CCRDSサーバー400によって管理される共通コンテンツレポジトリー中に記憶されるが、それは、複数のアクセス可能なサーバー上に広がり得、そして余分に維持される。このデータは、広範な範囲の主題をカバーし、そして異なる理由のために多様なグループのユーザーによってアクセスされ得る。従って、それは、異なるユーザーインターフェース10a、10b、...10cを通じてデータへの異なるタイプのユーザーアクセスを提供するために有用であり得る。各ユーザーインターフェースは、特定の詳細ユーザー特徴および必要性を供するよう適合されたスクリーン中で履行され得る。このユーザーインターフェースは、カクタマイズされて質問を作製するか、ドキュメントをリクエストするユーザーメッセージの処方の容易さを提供するのみならず、カスタマイズされてドキュメント送達のためにユーザーに適切な形態およびフォーマットを提供する。すなわち、共通のレポジトリーから送達されたデータは、特定のユーザーインターフェースに特異的に仕立てられ、かつフォーマットされる>
種々の理由のため、記憶された情報は、ドキュメントの塊内の個々のドキュメントの形態で記憶されている。このドキュメントの塊は、ドキュメントの1つ以上のコレクション中に区画される。本明細書で用いられるとき、ドキュメントは、著者または供給元が情報を調製する、ニュース論説、司法的意見(事例レポート)、規制規則、レポート、電子ファイルまたはデータベース記録、またはその他の慣例のフォーマット(紙または電子媒体のいずれか)のような、特有の一般的な識別子(GUID)を受ける1つの密着したデー
タユニットとして広く規定される。関連するドキュメントのグループは、コレクションとして一緒に記憶され得(論理的に、必ずしも物理的である必要はない)、そして1つ以上のコレクションが、セットとて、一緒に貯蔵され得る(再び、論理的に、必ずしも物理的である必要はない)。
【0019】
コレクションおよびセットの使用は、ユーザーが、特定の、共通して理解されるセットまたはコレクション、例えば、特定セットの地域法律事例レポーター;法律総説のような特定カテゴリーの定期刊行物;死亡、所有権または商標の記録のような記録のコレクション内のサーチすることのユーザーの範囲を容易にし得る。各ドキュメントは、コレンションおよびセット内で少なくとも一度インデックスを付けられる。このコレクションおよびセット配列はまた、システムが、サーチを特定のコレクションまたはセットに向けることにより課せられるサーチを低減し、そして各サーチが全ドキュメントレポジトリーをカバーすることを必要としない。ドキュメントレポジトリーは、合計20テトラバイト以上の情報を含んで極度に多くあり得る。
【0020】
いくつかの分野では、新規ドキュメントが、常時、しばしば、数分毎または数秒毎に現れるというような高頻度でさえ生成され、そしてFTPまたはその他のフォーマットにより、リアルタイムにドキュメント行列待ち70に送達される。このデータレポジトリーがアップデートされるか、またはそのコレクションが拡張するとき、新規ドキュメントは、1つ以上のデータコレクション30a、30bに付加され得る。新規ドキュメントは、後に、異なる目的のために異なるユーザーによってアクセスされるので、取り込みコンポーネント(Intake Component)80によって実施されるドキュメント取り込み機能が、適正な基礎を提供することが所望される。所定のドキュメントの取り込みを繰り返されなければならないこと、または、通常でない状況にあることを除き、それがレポジトリーに付加された後でそれを編集することは所望されない。なお、この同じドキュメントは、このドキュメントをアクセスするために採用され得るユーザーインターフェースおよびリソースアプリケーションに基づき、その送達の一部分として改変可能である必要があってもよい。(さらに、このリソースアプリケーションは、このドキュメントがドキュメントコレクションに入るときに存在しなくてもよい)。従って、各ドキュメントは、好ましくは、XML、または後の刊行において柔軟性を許容する別のドキュメントフォーマットで記憶され、そして柔軟性を支援する属性をもって生成またはエントリーの時間で提供される。さらに、このドキュメントに関連するメタデータファイルエントリーまたは記録がまた生成され得る。このメタデータファイルエントリーまたは記録は、ドキュメントのコンテンツが、ドキュメントのコンテンツの取り込みの時間に、ドキュメント自身のために適切であり得る特定の様式で富化され得ることを可能にし、そしてまた、ドキュメント自身を改変することなく、取り込みのときに、ドキュメントに関連するメタデータを改変することにより、ユーザーに利用可能な情報の後の富化を許容する。(本明細書で用いられるとき、メタデータは、情報についての情報を意味し、そしてユーザー、システム、または両方のいずかに有用であるドキュメントについての任意の情報であり得る)。
【0021】
図6は、ドキュメント110に関連するメタデータレコード152が記憶される、データコレクション30a、30bおよびメタデータファイル150に記憶され得るような、ドキュメントレコード110の概略図である。このドキュメントレコード110は、タイトル112、著者/刊行者114、日付114、GUID(全体汎用識別子:global universal identifier)118、およびPIT(時間点:point in time)スタンプのようなフィールドを含む。このドキュメントは、取り込み時に調製されたエンリッチメントデータを受けるためのフィールド126を含み得、そして必要に応じて、1つ以上のTable of Content(以下にさらに詳細に論議される)にこのドキュメントを関連付ける「ntoview」フィールド127を含み得る。このドキュメントは、1つ以上の挿入されたリンク122または分類属性124を含み得る。ドキュメントは、テキスト、持続するかまたは移動するイメージ、音またはコンテンツのその他の形態を含み得る。コンテンツの性質は、ドキュメントレコード110中またはメタデータファイルレコード152中のいずれかに捕獲される別の属性111であり得る。
【0022】
陳述のように、取り込みコンポーネント80により処理されるドキュメントは、属性をもつソースから受けたファイル(例えば、ニュース刊行者、ジャーナル刊行者、ストックマーケット、裁判所または規制当局)を提供することにより富化され得る。提供された特定の属性は、付加されているドキュメントのタイプに依存する。これら属性はまた、特定のリソースアプリケーションに一部として特定され得る。
【0023】
属性は、少なくとも2つの機能を提供し得る。第一は、そのシステム内またはユーザーに対するユーティリタリアン(utilitarian)である。すなわち、特定のコンテンツまたはコンテンツモディファイヤ、ならびに機能フィーチャ(例えば、他の文書へのナビゲーション関係またはナビゲーション接続をアクティブに確立するリンクを示す)が作成され得る。第二は、ブランド認識フィーチャである。なぜなら、ソースの受容は、しばしば、文書自体と同様に重要であるからである。このブランド識別性は、文書の最終の外観によって確立され得る。これは、文書に付加される特定のブランド識別属性(例えば、ユニークな形式またはソースから送達されるコンテンツから生成される特殊に派生する付加価値コンテンツ)によって容易にされ得る。
【0024】
例えば、取り込みのために処理される文書は、所定の株式報告または会社分析に関連し得る。この文書のテキストまたは事実コンテンツは、一般的に一旦作成されると不変である。2つの異なる販売者は、各々が受容されるレベルの品質を有し、その文書のコンテンツに対するアクセスをユーザーに提供し得る。各々の販売者は、文書をアクセス可能にするが、自分自身の情報販売システムの「外観および感触」を有することを欲し得る。従って、本発明のシステムの属性および/またはメタデータファイルを利用して、それがそのソースから提供されるときに文書を補充または強化し得、その結果、特定のユーザーインターフェースまたはリソースアプリケーションを介して提示されるときに、それが、ユニーク性を増し、そしてブランド化され、そして付加価値が与えられた製品として受容され得る。
【0025】
取り込みの際にそのエンリッチメントのために文書に関連付けされ得る属性の一つは、リソースアプリケーションに依存するベースに基づいて後に可能性のある使用のために、文書へのリンク付け(例えば、ハイパーリンク122の挿入による)を含む。例えば、法律のリソースアプリケーションに適合される判例法国は、他の内部参照される判例報告へのリンクを含み得る。これは、共通コンテンツレポジトリにおいて見出され得る(または他の場所(例えば、ワールドワイドウェブ))。新聞記事は、その話において識別される個人または事件に関連する特定のコンテンツにリンクされ得る。そのようなリンク122のアクセス可能性は、不確実であり得、すなわち、リソースアプリケーションに依存するが、いくつかの文脈においてユーザーインターフェースを通じて提供されないかもしれない。例えば、ニュースサービスの法曹ではないユーザーが法律関連の判決例報告にアクセスし得る。他の判決例報告に対するリンクは、アクティブではない可能性があり、あるいはそのユーザーについて、法曹のプロユーザーについて同じ様式で適切ではないかもしれない。記述されるように、文書に関連付けられるメタデータファイル記録152は、レポジトリにそれが付加される時点で付加される属性に関する別の場所である。メタデータ記録152は、リソースアプリケーションによって使用されて、もとの格納された文書記録110自体を変化させることなく、ユーザー照会メッセージに関連して文書についてデータ、パラメータまたはディスプレイ形式を重ねがき、付加、削除または改変する情報を格納する(または他のメタデータファイルにリンク付けする156)。
【0026】
文書取り込みのプロセスの一部として、文書記録110は、編集材料によって強化され得る。すなわち、付加価値編集コンテンツが、文書に挿入され得るか、またはメタデータ記録に付加することによってその文書に関連付けまたは付着され得る。例えば、法律の判決例報告の場合、ヘッドノートまたはまとめが、作成および付加され得る。この材料は、手動でまたはある場合は、自動的に作成され得る。例えば、法律の判決例報告において言及される判例は、引用チェックされ、そして自動的に引用がアップデートされ得る。さらに、新たな文書が種々の分類属性124によってラベルされ得る。この属性は、いくつかの集合分類(例えば、管轄、トピックなど)についての指標として使用され得る。
【0027】
(B.照会プロセスの外観)
情報小売は、種々の顧客関係に基づいて行うことができる。しかし、ほとんどの場合において、ある種の顧客契約が存在し、この契約は、顧客が購入したサブスクリプションまたはアクセス条項を定義し得る。この契約は、アクセスされ得る主題、アクセス時間などに関する制限を特定し得、そして料金を定義し得る。契約は、紙またはオンラインで締結され得、そして情報レポジトリのいかなる使用に十分先立って結ばれ得る。適切な支払いが確認されると、契約はまた、使用前にすぐに締結され得る。一旦情報プロバイダとユーザーとの間の契約関係が定義されると、ユーザーは、1または複数のリソースアプリケーションおよびそのユーザーインターフェースを介して少なくとも一部の共通コンテンツレポジトリに対するアクセスを有することになる。
【0028】
本発明の一つの目的は、情報プロバイダが、共通のコンテンツレポジトリの部分へのアクセスおよび文書の送達について所望される本質的に任意の情報製品/サービスおよび顧客との関係を定義することを可能にすることである。従って、この関係は、多数のパラメータを含み得、これは、顧客によって変動し得、以下を含み得る:アクセスが許容されるコレクションまたはセット;アクセス時間、アクセス利用可能なユーザーまたは他のロード制限の数値;ユーザーに提示されるスクリーンの外観およびコンテンツ(これによって、ユーザーは、要求を照会し、そして結果を受け取る);要求され得る文書の送達のモードおよび/または形式;および種々の使用形式の料金。従って、小売業者は、種々の関係を支持するリソースアプリケーションを開発して、システムが、種々の合意されたビジネス条項に適合するサービスを提供することを可能にすることを所望し得る。
【0029】
リソースアプリケーションがどのようにして共通コンテンツレポジトリにアクセスするかの概観は有用である。まず、エンドユーザーがエンドユーザーの照会においてシステムから文書を検索する。図3に示されるように、これは、ユーザーメッセージ12a、12b、、、12nの形式である。多数のユーザーメッセージが、一日のどの時間でも、世界中のとこからでも(ただし、定義された顧客関係によって制限されない限り)同時にユーザーから入力され得る。ユーザーメッセージは、多数の異なる形式(例えば、検索(find)、サーチ(search)、またはブラウズ機能)に適合され得る。例えば、あるユーザーが特定の情報(例えば、文書のタイトルおよび著者)を知っている場合、そのユーザーは、その特定の文書を検索するようにシステムに要求する。他方、ユーザーがある主題について一般的な情報を探している場合、そのユーザーは、サーチまたはブラウズを実行して、関連する情報を見出し、または照会を再検討する。これらは、リソースアプリケーション内で定義され得、そしてユーザーからシステムが受け取ることができる多数のタイプのユーザーメッセージの本の一例である。
【0030】
各々のユーザーメッセージは、ユーザーによって、RAユーザーインターフェース10a、10b、、、10nのうち1または複数を使用することによってシステムに入力される。各々のユーザーインターフェースは、ユニークな概観および感触を有し得、そしてユーザーが特定の種類の文書を検索することを容易にする。これは、使用されるユーザーインターフェースのタイプに依存する。例えば、法律文書を検索するためのリソースアプリケーションのユーザーインターフェースは、新聞記事を検索するために設計されてアユーザーインターフェースとは異なる文書にアクセスするように適合される。異なるアプリケーションのこれらのユーザーインターフェースは、おそらく、異なる概観および感触を有する。なぜなら、これらは、異なるタイプの文書にアクセスするように設計されており、そして異なるユーザープロファイルに対してアピールするからである。
【0031】
要求がユーザーによってユーザーメッセージ12a、12b、、、12nとして入力された後、サーチコンポーネント22を用いて関連する文書を見つける。サーチコンポーネントが、キーワードまたはフレーズを、ユーザーの要求によって使用して、関連する文書が配置される場所、および1または複数の文書を識別するサーチ結果メッセージを送信する場所を決定する。サーチコンポーネントは、究極には、各々の文書についてGUID識別子を見つける。このGUID識別子は、文書が、コレクションから容易に取り出されることを可能にする。いくつかの場合において、サーチコンポーネントは、実際の文書ではなく「ヒット」のリストを送達し、そしてさらなるユーザーメッセージは観察または他の送達のための特定の文書の選択を定義する。サーチコンポーネントは、さらに詳細に以下に記載される。
【0032】
1または複数のデータコレクション30a、30bに格納される各々の文書は、GUID制御コンポーネントのタイムスタンプコンポーネントから正確な時点(PIT)120を伴って格納される。このPITフィールドは、実際のクロック時間値であり得るが、また、所定の文書について、単に特定のバージョンが他のバージョンに比較して意味づけされることを示す一連の識別子またはバージョンであり得る。例えば、バージョン識別子は、GUID:GUID.00、GUID.01、GUID.02などに基づいて構築され得る(これは、法律的文書について特に有用であり得る)。従って、文書または関連するデータが、経時的に改変される場合(例えば、関連するメタデータを加えるかまたは変更することによる)、PITは、システムが、文書の最も現在のバージョンおよび関連するデータがユーザーに提示されているかどうかを検出することを支援し得る。また、文書の以前のバージョンがすでに提示されているにもかかわらず、文書のアップデートされたバージョンが、サーチ機能がその文書を発見したときに提示されることを可能にする。取り込み時間PITに加えて、リソースアプリケーションは、この後者のアップデート機能について有用であり得る送達時間を追跡し得る。
【0033】
一旦文書がデーベースから要求されると、文書送達コンポーネント40を用いて、文書をユーザーに送達する。この送達コンポーネント40は、文書を、リソースアプリケーションによって利用可能にされた中からユーザーが選択した形式およびモード(例えば、電子メール、ファクス、郵便)で文書を提示する。従って、送達されるときには同じ文書が、異なる概観および送達モードを有し得、これらの概観および送達モードに依存して、ユーザーインターフェースおよびリソースアプリケーションがそれに関して要求を受け取る。
【0034】
図3に示されるように、データベースまたはデータコレクション30a、30bに格納される文書は、メタデータファイル50a、50bと関連付けられる。メタデータファイルは、各々の文書に関連する種々のさらなる情報を含み得る。この情報は、文書コンテンツ自体の一部ではないが、関連する文書についてのサーチの間にアクセスされ得、または文書自体と同時に送達のためにアクセスされる。
【0035】
各々の新たな文書は、まず、取り込みコンポーネント60によってデータベース30a、30bへと配置される。このデータベースは、定期的かつ頻繁に文書がアップデートされ、そして少なくとも文書のいくつかは、即座の発行が必要とされる。例えば、株式市況報告およびホットニュース記事は、可能な限り早く利用可能になるべきである。その関連性は、しばしば、短命であり、その価値は、そのタイムリー性に関連する。取り込みコンポーネントの優先度コンポーネント90は、1または複数の優先度レベルを用いて処理のために入ってくる文書を優先度をつけて、特定のリソースアプリケーション(例えば、報告またはニュース事項の場合の時間発行利用可能性を約束するリソースアプリケーション)のために定義され得るリアルタイムまたは他の特定の利用可能な要件を用いて受け取り文書の時間順序から選択的に処理する。GUID制御コンポーネント100は、それがデータコレクション中の任意のユーザーに利用可能とされる前に、各々の文書に関する割り当てられた文書識別子のユニーク性をチェックし得る。取り込みコンポーネント60はまた、ユーザーに利用可能な文書を作成する前に、所定の形式について文書をチェックし得る。これらのフィーチャは、データコレクション30a、30bに対してリリースされる文書がこのシステムによってアクセスされる準備ができることを確実にすることを支援する。
【0036】
(取り込み処理)
図8は、取り込み処理をフローチャートの形式で示す。802において、システム5(図3)は、ソース(例えば、ニュースサービス、裁判所、市場データサービス)から送信されるファイルを受け取り、そして804において取り込みコンポーネント60は、ファイルを送信形式から、取り込み処理により適切な形式へと変換する。806において、個々の文書が処理のために分離され、そして808において取り込みコンポーネントは、ソースによってすでに割り当てられたかもしれないまたはいまや割り当てられる必要があり得る優先度コードをサーチする。810において、文書が1または複数のキュー中に蚊k脳され、優先度に従ってさらに処理される。812において、このシステムは、ファイル中のさらなる文書および/または受け取られるべきさらなるファイルについてチェックし、そしていずれかが存在する場合、適切な実行ポイントを返して、次の文書またはファイルを処理する。
【0037】
814において、最高の優先度を伴う文書を選択することによって、別の処理リソースが文書のキューにアクセスする。816において、取り込みコンポーネントは、ソースによってすでに割り当てられてい得る(GUIDのユニーク性を確実にせねばならないシステムに強調して)か、または今やユニーク姓を確実にする履歴およびアルゴリズムに基づいて割り当てられることを必要とし得るGUIDについてサーチする。818において、文書の格納フォーマットは、エンリッチメント80を処理するための準備を確実にするために820においてチェックされる。
【0038】
エンリッチメントコンポーネントを用いて、文書コレクション30a、30bにおいて配置されるように、各々の文書を増強することができる。エンリッチメントコンポーネントは、種々のフィーチャを各々の文書に加え、これは、1または複数のユーザーグループのための文書の価値を増大させる。エンリッチメントコンポーネントは、各々の文書を、以下のうち1または複数と関連付ける:人間のエージェントによって準備されたさらなる編集材料;自動化エージェントによって準備されたさらなる編集材料;このデータベース中の別の文書へのポインタを提供するリンク;またはメタデータファイルに出現する文書と関連付けられたエントリ。これらのエンリッチメントフィーチャは、エンドユーザーに対して、ある種類のさらなるコンテンツと組み合わされた個々の文書の形式で付加価値生成物を受け取ることを可能にする。種々の形式のエンリッチメントが、特定のユーザーに役にたち、そして特定の文書を送達するために使用されるリソースアプリケーション15に依存して利用可能であり得る。
【0039】
820におけるエンリッチメント処理の後、文書は、822においてメタデータ抽出コンポーネント処理に供され得る。この処理で得られるメタデータは、一般に、この文書を1または複数のコレクションへと接続するために重要なデータを抽出する工程を含む。従って、この文書のコンテンツを解析して、同じまたは異なるコレクションにおいて他の文書に対してこの文書の言語学的に洗練された分類を開発することができる。格納または検索を支援し、そして文書を改変またはカスタマイズして1または複数のリソースアプリケーションのフィーチャのための基礎を提供する、種々の形式のメタデータが開発され得る。
【0040】
図8をなおも参照すると、メタデータが抽出された後、824において、文書がアクセスのためのリリースのその時間に対応するPITとともに格納される。826において、このシステムは、処理される優先キューにおいてより多くの文書が存在するかどうかを決定する。そうでない場合、文書プロセッサは、828において待ち状態へと移る。より多くの文書が存在する場合、制御は、実行点へと移り、その時点で、次の文書が優先キューから選択される。
【0041】
新たな文書が配置される少なくとも1つのデータコレクションにおける文書は、少なくとも1つのコレクションサブセットへと区分され得、そして新たな文書を受け取るための取り込みコンポーネントが各々の追加の文書がユニークな識別しそして少なくとも1つのコレクションサブセットに割り当てられることを確実にし得る。別のデータコレクションは、少なくとも1つの文書セットを有し得、この文書セットは、1または複数のコレクションサブセットの文書のアグリゲーションである。
【0042】
(エンリッチメントおよびメタデータ処理)
図9は、図8において言及された文書エンリッチメントおよびメタデータ抽出のプロセス900のためのフローチャートを示す。902において、文書エンリッチメント処理のために使用されるコンポーネントは、制御を受け取り、そしてエンリッチメントのための文書を受け取る。904において、自動化されたエンリッチメントエージェントが適用され、そしてこのエージェントによって生成されるエンリッチメントフィーチャを使用して、文書を増強する。例えば、このエージェントは、新聞記事または事件の中で個人名または会社名についてサーチし得、次いで、文書をブラウズする個人によって相談され得る再度バーディスプレイのためのファイルを構築することができる。自動化されたエンリッチメントエージェントの適用の後、バイパス経路905〜ステップ910は、人間のエンリッチメントエディタの割り当てが必要でない場合に採られ得る。バイパス905が採られない場合、906において、文書は、再検討および編集のために人間のエンリッチメントエディタに割り当てられる。908において、人間のエンリッチメントエディタがさらに増強された文書と共にファイルを返す。910において、増強された文書は、メタデータ処理のために送達され、そして912において、メタデータ抽出コンポーネントは、送達された文書を受け取る。914において、自動化されたメタデータエンジンが文書に適用されて、メタデータが抽出され、そして916において、このメタデータファイルが収集され、そしてその文書と関連付けされる。例えば、抽出されたメタデータは、XMLデータまたはメタデータのレイヤに構築されたリソース・ディスクリプション・フレームワーク(RDF)ステートメントの形式でメタデータのレイヤへと開発され得る。918において、この文書のためのメタデータファイルは、他の文書に関してメタデータファイルとリンク付けられる。例えば、メタデータ処理が、文書のいくつかの言語学的分類を生じる場合、表、インデックス、コンテンツ表または他のコレクションワイドのメタデータファイルが、この文書に由来する情報および/またはそれに対する参照とともにアップデートされ得る。920において、リソースアプリケーション条件付タグがメタデータファイルに付加され得る。これらは、特定のリソースアプリケーションによって用いられて、特定のリソースアプリケーションによって供給される文書リソースサービスにおいて含めるのかまたは排除するためにメタデータをタグ付けする。いくつかの場合において、メタデータは、リソースアプリケーションによってアクセス可能なタグの存在または非存在に基づいて、サーチまたはディスプレイから排除される。
【0043】
922において、メタデータファイルが格納される。これらは、文書と関連付けられて(couple)格納され得るか、または関連付けられずに格納され得る。すなわち、物理的な関連付けまたは単に論理的な関連付けが存在し得る。924において、このシステムは、ファイル(または部分)を候補としてマークし、または将来のメタデータの付加のための候補としてではなくそのファイルをマークする。この将来のメタデータは、文書使用パターンを経時的に統計学的またはヒューリスティックな規則解析の使用によって派生され得る。メタデータを格納すると共に、処理される文書は、ユーザーアクセスのために準備ができるようになるが、関連するメタデータは後に変更され得る。このシステムが、使用パターンを追跡および解析するためのエージェントを有する場合、このマーキングは、適切な場合この文書の使用が追跡されること、および結果(例えば、図6における使用メタデータ154)が記録されることを確実にし得る。さらに、使用パターン情報が開発されるにつれ、メタデータは、文書取り込みがアップデートされ得る時間に格納され得る。例えば、この文書が頻繁に、観察されるサーチパターンの部分である場合、メタデータファイルは、生じた一連のサーチにおいて近似する他の文書を反映するようになり得、その結果、同じ一連のサーチに沿ってユーザーが後に導くことを支援する。926において、エンリッチメントおよびメタデータ抽出コンポーネントは、システムに制御を戻す。
【0044】
メタデータは、情報オブジェクトへのアクセスを構成、記述、追跡および他の様式で増強するように作成される付加価値情報である。以下により詳細に説明されるように、本発明において、とりわけ、メタデータは、コンテンツの表、フィルタリングまたは他の操作によって得られるコンテンツ表の派生物、ユーザー追跡情報から派生する使用パターンデータ、重複検出のために開発された文書シグネチャ、およびトークンインデクシングの形式で開発される。文書の大きなアグリゲーションにおいて、メタデータは、ヒエラルキー形態であり得、ここで、より高いレベルのメタデータは、より低いレベルのメタデータの意味を解釈するにおいて支援するように開発され得る。他の状況において、メタデータは、非ヒエラルキーであるがそれにもかかわらず他のメタデータに関してリンクまたは他の非ヒエラルキー形態の指摘手段によって関連付けられるメタデータである。次に記載されるコンテンツ表は、付加価値メタデータを開発するためのプライム機会を提供する。
【0045】
(コンテンツ表(TOC)構築)
1つの形態のメタデータプロセシングは、コンテンツ表(TOC)構築である。本発明において実行されるように、TOCは、2つの異なるコレクションタイプが定義されることを必要とする。TOCコレクションは、TOCヒエラルキー関係を含む。文書(DOC)コレクションは、文書を含む。TOCは、1、2または多数のDOCコレクションにおいて文書を参照することができる。恒常的なGUIDは、現在のTOC設計の利益を達成するための要件である。システムが多数のタイプの情報をユーザーに提供する場合、それは、代表的には、各々のタイプの情報について少なくとも1つのTOCを有する。
【0046】
TOCヒエラルキーは、共通のコンテンツレポジトリー中に1つのコレクション中に存在し、そして文書に対する参照を含む。参照される文書は、1または複数のDOCコレクション中に存在する。コレクションセットを用いて、単一のTOCコレクションとDOCコレクション(単数または複数)とを結びつける。このDOCコレクションは、参照される文書を含む。図10は、TOCアーキテクチャの模式的外観である。以下は、TOCの実行についてのさらなる詳細である。
【0047】
a.ローディングデータ。TOCデータをTOCコレクションにロードする。DOCデータを、DOCコレクションにロードする。TOCコレクションおよびDOCコレクションの両方は、同時に、ローディングデータであり得る。TOCおよび文書データをsync(同期)に維持するために、同期プロモートが、多重コレクションの同期を促進することをクライアントに可能にするために利用可能である。
【0048】
b.TOCノードに基づくサーチの制限。「n−tocview」エレメントが文書データロードに加えられて、TOCサーチ−クエリ−ビュー制限を支持する。この「n−tocview」127(図6)は、クライアントが文書と関連付けることを希望するTOC GUIDを含む。以下は、図11Aにおいて単純化したサンプルTOC構造をアップデートするために使用されるXMLの例である。ここでは、陰付ノードは、文書「d2」を指摘するTOCノードを表す。
【0049】
【数1】
【0050】
【数2】
【0051】
。
【0052】
注意。n−topview中で特定されるGUIDは、共通のコンテンツレポジトリによって、コレクションセット内に存在することも、関連情報であることがベリファイされていない。
【0053】
c.ラッパーAPL。コレクションセットを用いて、TOCコレクションをDOCコレクション(単数または複数)に結びつける。このDOCコレクションは、参照される文書を含む。ラッパーAPLは、コレクションまたはコレクションセットと共に用いるためのTOC APIを含む。コレクションセットは、ラッパーAPIが使用され得る単一の点を提供する。
【0054】
d.TOC XML。TOCノードは、n−nodeエレメントによって作成、アップデートおよび削除される。各々のn−nodeエレメントは、TOCノードを記述する情報を含む。TOCデータは、(文書のように)トークンインデクシングされておらず、従って、共通のコンテンツレポジトリによってサーチ可能ではない。n−topview情報がその文書内に配置され得、従って、サーチのためにインデクシングされ得る。
【0055】
n−nodeは2つの属性を有する:
guid−TOCノード GUID
control:起こるべき動作を示す。
【0056】
(表)
値 |動作の記述
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
「ADD」 |TOCノードをこの段階で加える
「DEL」 |TOCノードをこの段階から削除する
「DELBRANCH」 |TOCノードおよびこの段階について
|すべてのTOCノードの子を削除する。
【0057】
n−nodeは、以下のエレメントを有する:
n−parent−guid:親ノードのGUID。ルートノードは、このエレメントを含まない
n−doc−guid:このTOCノードが文書を参照する場合の文書のGUID。TOCノードは、ゼロを有し得るか、またはそれに関連する1つの文書を有し得る。このエレメントにおける任意のコンテンツは、TOCノードが文書を参照することを示す
n−anchor−guid:このTOCがアンカを参照するときのアンカのGUID
n−label:598バイトのサイズ制限を伴うテキストフィールド
n−rank:ランク順序で表示するためのアプリケーションのためのTOCノードをソートするために用いられる実数
n−name:アプリケーションに対して通過して戻るTOCノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内にTOC定義に対する意味を有しない。n−nameに対する最大値は、20バイトである
n−value:n−name値を伴うアプリケーションに対して通過して戻るTOCノードに特異的なコンテンツ。このデータは、共通のコンテンツレポジトリ内のTOC定義に対して意味を有しない。n−valueの最大値は、200バイトである
n−meta−data:TOCに関するメタデータの情報を含む。
【0058】
e.TOC DTD
【0059】
【数3】
【0060】
【数4】
【0061】
f.TOCおよび文書XMLの例。図11Bを今度は参照すると、陰付ノードは、文書を参照するTOCノードを表す。2つのTOCノードは、文書「d1」を参照する。TOCノード「n7」は、「n5」のアンカーである。
【0062】
【数5】
【0063】
留意点:
文書「d1」は、<n−tocview>n1、n2 n4 n3 n6</n−tocview>の組み合わせn−tocviewを有し得る。文書内に含まれるアンカーは、クライアント特異的なタグで特定される。システムは、アンカーが要求するタグを文書内に含まない。
【0064】
g.n−nodeに関するルールのアップデート
1.重複するGUIDはない。GUIDは、2回加えられず、削除もされず、そして同じロードにおいて加えられる。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
2.定義されるn−nodeは、置き換えられるノードである。n−nodeがXMLで定義される場合、n−nodeにあるすべての情報は、再定義される必要がある。このデータのロードは成功する。このノードは、最新の定義のみを反映する。
3.子なしのn−nodeは削除機能とともに削除され得る。この条件が満たされない場合、このロードは、データエラーと共に失敗する。
4.ブランチの削除は、n−nodeおよびすべてのその子ノードが削除されたことを示す。
5.削除したブランチのn−nodeは、改変され得ず、ブランと削除として同じロードに加えられ得ない(規則1を参照のこと)。この条件が満たされない場合、ロードは、データエラーと共に失敗する。
6.n−nodeの親guidは、既存のノードでなければならない。この条件が満たされない場合、ロードは、データエラーと共に失敗する。(既存のノードは、すでにTOC中に存在するノードであるか、または現在のロードに存在するノードである。ノードは、ランク順序によりロードされる必要はない。欠失するノードのべリフィケーションは、ロードプロセスの最後に起こる。しかし、よりよいロード速度は、ノードをヒエラルキー(ランク付け)様式でロードする場合に起こり得る)。
【0065】
h.TOCローディングでの使用の場合
以下は、TOCの実用的な含意を示す使用の場合である。これらの実施例の大部分は、図11CのTOC構造に基づく。この同じ構造は、上記XMLの例において用いられた。
1.大きなデータはどのようにしてTOC構造を用いてロードされ得るか?
例えば、50ギガバイトの生データをロードし、所定のコレクションについて500メガバイト/時の速度でロードできるとしよう。1つのTOCおよび3つの文書コレクションが使用される場合、この同じデータは、1日より若干長い時間でロードすることができる。クライアントが文書データを多数のコレクションに分断したい場合、データは迅速にロードされ得る。
2.TOCからブランチはどのようにして削除され得るか?
本発明者らの実施例を用いてノード「n2」に始まるTOCブランチを削除し、そしてまた、ノード「n2」のもとでいかなるノードをも削除するとしよう。文書「d2」は、TOC中でもはや参照されない。文書は、「d2」について欠如が共通コンテンツレポジトリに渡されない限り、削除されない。
以下は、「n2」で始まるブランチを削除するためのXMLである。
【0066】
【数6】
【0067】
以下は、文書「d2」を削除するためのXMLである。
【0068】
【数7】
【0069】
3.文書「d1」のテキストはどのようにして変更可能か?
文書「d1」を新たな文書データおよびTOCサーチ制限を許容するn−tocview情報とともにリロードする。以下はそのXMLである。
【0070】
【数8】
【0071】
4.TOCノード「n4」のラベルは変更可能か?
TOCノード「n4」を、新たなラベル情報と共にリロードする。この同じ例は、TOCランク、名称、値またはメタデータのフィールドを変更する場合にも機能する。以下は、そのXMLである。
【0072】
【数9】
【0073】
5.文書「d3」は、どのようにして削除され得、そしてノード「n3」をどのようにしてTOC中に残し得るか?
文書「d3」について削除命令を送信し、そしてTOCノード「n3」を最適議して、文書「d3」に対する参照を含ませないようにする。以下はそのXMLである。
【0074】
【数10】
【0075】
6.文書「d1」は、どのようにして削除され得、そしてそれを参照するすべてのTOCノードを以下にして除去し得るか?
文書「d1」についての削除命令を送信し、そしてノード「n4」および「n6」についての削除命令を送信する。以下はそのXMLである。
【0076】
【数11】
【0077】
7.新たなTOCノード「n7」を、TOCノード「n1」と「n3」との間にどのようにして挿入し得るか?
新たなTOC構造は、図11Dのようである。
文書「d1」および「d3」を新たなn−tocviewとともにリロードして、GUID「n7」をクエリビュー制限として支持する。「n7」について新たなTOCノードも作成し、そしてTOCノード「n3」を再定義して、「n1」の代わりに「n7」を指し示すようにする。以下はそのXMLである。
【0078】
【数12】
【0079】
まとめると、TOCは、文書に関するヒエラルキーメタデータを格納するための構造を提供する。TOCは、ノードからなる。GUIDはノード、親ノード、参照される文書およびアンカーを識別する。TOCを構築するためのすべての入力は、XMLである。TOCは、再帰的構造であり得る。これは、ノードのn−doc−guidが、文書のGUIDの代わりにTOCノードのGUIDを含む場合に起こる。次いで、TOCノードは、TOCノードを参照する。TOC中のノードラベルの語彙は、メタデータRDFステートメントに関する語彙として使用することができる。
【0080】
文書は、いっときに任意の点において、たった一つのDOCコレクション中に存在し得る。しかし、文書は、TOCとともに多重の位置において表され得る。1または複数のDOCコレクションからの文書は、1つのTOCにおいて表され得る。
【0081】
TOCヒエラルキーデータは、TOCコレクション中に格納される。文書データは、1または複数のDOCコレクション中に格納される。特定のTOCは、1つのコレクション中に存在する。TOCコレクションが参照するTOCコレクションおよび1または複数のDOCコレクションは1つのコレクションセットにより互いに結び付けられる。図12は、2つの文書(ラベルしたDG1およびDG2)を参照する単純化したTOCのサンプルを示す。
【0082】
本発明のTOC設計は、多数の有用な特徴を許容する。
【0083】
TOCナビゲーション:APIを提供して、TOCのノードをナビゲートする。以下のサンプル操作は、そのようなAPIを通じて実行され得る:TOCのルートノードを検索し;ノードを与え、その子を検索し;TOCサーチ結果およびTOCノードを与え、TOCの順序で次または前のノードを検索し;そしてノードを与えその親を検索する。
【0084】
ヒットを伴うTOC:サーチが文書ヒットを得たとき、これらを併せて各々のTOCノードにおけるヒット数をリターンする。
【0085】
フィルタリングしたTOC:リソースアプリケーションがサーチおよびTOCノードに対して参照を送信するとき、そのサーチに適合しないTOCの部分は、除去される。リソースアプリケーションがサブスクリプションハンドル(サーチに基づく制限、サブスクリプションに基づく)に対する参照を送信するとき、そのサブスクリプション基準に合わない任意のTOCが除去される。
【0086】
ノードを見出す:リソースアプリケーションが、名称および/または値に対する参照を送信するとき、TOCは、関連するノードをリターンする。
【0087】
TOCアンカー:アンカーを用いて文書内のヒエラルキーを反映させることができる。
【0088】
(インデクシング)
メタデータプロセシングのための準備として、文書を、インデックスファイルの作成により正常にインデクシングさせる。そのようなインデックスファイルは、トークン化、ストップ、ステミング、大文字使用の除去、および逆返還(inversion)によって従来の様式で誘導させる。米国特許第6,389, 412号を参照のこと。メタデータ抽出に対するインデクシングプロセスの関係は関心の対象とされ得る。インデクシングは、意味情報のいくつかの喪失を生じることから、インデクシングは、ある文書コレクションについては所望されないかもしれない。他のコレクションにおいて、インデクシングは受容可能であるが、抽出されるべき情報が、インデクシングにおいてその全体または部分が喪失する特徴を伴う場合インデクシング形式ではない文書に基づいてメタデータ抽出を行うことが最良である。メタデータは、インデクシングされてもよくされなくてもよい。1つの実施形態において、TOCデータは、インデクシングされず、従って、インデクシングに依存するサーチエンジンによってサーチ可能でない。しかし、ユーザーが以下に詳細に説明するように探索することは可能である。
【0089】
データコレクション中の文書は、少なくとも1つのコレクションサブセットに区分され得る。このシステムは、コレクションサブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有し得る。ここで、インデックス中のキーワードとそのコレクションサブセット中の出現の位置との関係が存在する。
【0090】
(コンポーネント実行のビュー:概説)
図4は、上記に示されたかまたは記載された高レベル機能エレメントを実行するメインコンポーネントを示すブロック図である。メインコンポーネントは、ウェブサーバー200、アプリケーションリソース(AR)サーバーコンポーネント300、および1または複数のリソースアプリケーションを備える。ウェブベースのシステムにおいて、CCRDサーバー400およびARサーバー300は、クライアントとしてリソースアプリケーションとともにサーバーとして動作する。具体的には、CCRDサーバー400は、データベース(コレクション)サーバーおよびウェブサーバー200およびARサーバー300が、それぞれウェブおよびアプリケーションのサーバーである。他のシステムコンポーネントは、オンラインビジネスシステムサービス500およびビジネスシステム600およびパブリシングAPI700である。ビジネスシステム600内には、オンライン決済およびSAPコンポーネントが存在する。
【0091】
ARサーバー300コンポーネントは、CCRDSサーバー400レポジトリに存在する文書にアクセスする、ウェブベースのリソースアプリケーションを配備するために使用されるアプリケーションフレームワークを提供する。このフレームワークは、ユーザーがサブスクライブし得る新たなるソースアプリケーション(例えば、ニュースサービス、法律サービスなど)の迅速なターンアラウンドを提供する。1つの実施形態において、ARサーバーコンポーネントは、J2EEコンテナにまたがって使用され得るシリアル化可能なオブジェクトを提供する。
【0092】
多数のリソースアプリケーションにわたる共有される顧客情報を提供することについて多大な利益およびシステムの能力は、共有されるARサーバーコンポーネントの最大限の使用を伴って生じるが、アプリケーションは、必ずしも、サーバー構造によって提供されるすべての機能を利用するとは限らない。図4のサーバー構造の他の利点のいくつかとしては、再利用可能性、新たなまたはアップデートされたアプリケーションの市場に対する時間の速度および新たな製品開発のためのコストの減少を挙げることができる。
【0093】
一般的に、CCRDSサーバー400コンポーネントは、電子的に格納され、インデクシングされ、そしてソートされる文書の大きな集合に対するアクセスを提供する。これらの文書は、共通のコンテンツレポジトリに加えられ、そしてより簡単な検索および付加価値コンテンツを可能にするために増強される。リソースアプリケーションを通じて文書をユーザーがサーチまたは要求するとき、CCRDSサーバー400は、ARサーバー300と相互作用して効率よい様式でサーチ結果または文書を提供する。CCRDSサーバー400は、多数の道具を利用して、文書を増強する。これらの道具は、以下により詳細に記載される。
【0094】
一般的に、ARサーバーコンポーネント300は、ウェブベースのリソースアプリケーションを配置するために用いられるアプリケーションフレームワークを提供する。このコンポーネントは、共通のサービスおよびツールフレームワークを実行する。このサービスおよびツールフレームワークは、CCRDSサーバー400を用いて文書を検索する各々のリソースアプリケーションについて開発時間およびコストを減少させる。従って、新規リソースアプリケーションは、ビジネス部門がテーラーメイドのインターフェースを簡単かつ迅速に作ることを可能にし、他方で、データおよびサービスの集中処理されたコアにアクセスできるようになる。さらに、ARサーバー300コンポーネントは、種々のアプリケーションにわたって顧客に関する情報を共有することを促進する。1つの実施形態において、フレームワークは、アプリケーション開発(例えば、Java(登録商標)2 Enterprise Edition(J2EE))に対するセットモデルおよび他の推奨されるガイドラインを確立する。
【0095】
フレームワークは、アプリケーションプログラムインターフェース(API)を提供し、HTMLまたはXMLのような包括的マークアップ言語を生成するが、しかし、リソースアプリケーションのアプリケーション開発者は、XMLスタイルシートまたはJava(登録商標)オブジェクトが、包括的HTMLまたはXMLを、このリソースアプリケーションによって要求されるフォーマットに変換するか否かのインターフェースを提供する。共通サービスおよびツールがARサーバーコンポーネント300によって提供され、それ故、各リソースアプリケーションがこれらサービスを個々に開発する必要性をなくする。
【0096】
各リソースアプリケーションは、ユーザーに、特定のマーケット中で、ドキュメントを位置決めかつ回収するための仕立てられた製品を提供するように設計された特有のアプリケーションである。上記で説明されるように、リソースアプリケーションは、ARサーバー300によって提供される特別のサービスおよびツールを利用し、CCRDSサーバー400によって管理されるドキュメントの大きな共通のコンテンツレポジトリーにアクセスする。1つ以上のリソースアプリケーションが、ARサーバー300およびCCRDSサーバー400と同時に相互作用し得、同じドキュメントをアクセスかつリクエストする;しかし、このドキュメントは、このドキュメントを送達するために用いられるリソースアプリケーションに基づく特有のルック&フィールで提供され得る。
【0097】
各リソースアプリケーションは、HTML、JPEGイメージ、Java(登録商標)Server Pages(JSP)、Servlets、カスタムスタイルシートなどのようなそれ自身のインターフェースコンポーネントを有して開発されている。しかし、ユーザーと通信するためにカスタムツールおよびサービスを利用する各リソースアプリケーション15(図3)の代わりに、プロセスUser Messageは、共通のコンテンツレポジトリーに記憶されたドキュメントにアクセスし、そして情報小売取り扱いのためのすべてのその他のビジネスルールを適用し、このARサーバー300およびCCRDSサーバー400は、各リソースアプリケーションが予めプログラムされたツールおよびサービスを利用することを可能にする標準的コンポーネントを有している。例えば、ARサーバー300のSecrurityコンポーネントは、各リソースアプリケーションが、同じセキュリティ特徴を利用することを可能にし、なお各々は、アプリケーションを開発するために選択されたコンポーネントに依存して、異なるフォーマットでセキュリティ特徴を提示し得る。ARサーバー300およびCCRDSサーバー400により提供される種々のツールおよびサービス、およびこれらが種々のリソースアプリケーションとどのように相互作用するかは、以下に記載される。
【0098】
ARサーバー300は、企業を横切るフェブアプリケーションを構築するための共通アーキテクチャー/インフラストラクチャーモデルを提供する。CCRDSサーバー400は、サーチ、ドキュメント送達、およびTable of Contentsのための再利用可能なバックエンドを提供する。ARサーバー300は、ウェブアプリケーションのために同じ再利用可能性を提供する。
【0099】
(CCRDSサーバー)
CCRDSサーバー400は、新規ドキュメントの導入および現存するドキュメントの回収を容易にする共通コンテンツレポジトリーおよび管理システムである。CCRDSサーバー400は、ドキュメントを入力し、豊富にし、見出しおよび回収するための以下のユーティリティを含む:サーチエンジン、Table of Contents(TOC)、Doc、Utility、CCI、Load Management、Data Management、およびLogging。
【0100】
(サーチエンジン)
サーチエンジンは、ドキュメントを異なる方法で位置決めするための多くのツールを提供する。例えば、サーチ(Search)、FindおよびBrowse操作が提供され得る。
【0101】
このサーチ操作は、ユーザーが、User Messageに応答して、共通コンテンツレポジトリーからのクエリーを満足する適正な質問の単一または複数「ヒット」を提供する。一般に、ユーザーインターフェースは、ユーザーを勧誘してクエリー事項を特定し、そして所望のコンテンツコレクションおよび/またはコンテンツタイプをSearch操作の一部分として選択するようにする。Search操作のユーザーは、オンライン−サーチ機能性について異なる能力および理解を有し得る。所有のサーエンジ製品などで先の経験を有するユーザーも居れば、Intenetサーチエンジンで経験を有するユーザーも居る。ユーザーインターフェースは、このような経験をもつ者に親しむように設計され得る。
【0102】
Searchの1つの使用は、BooleanオペレーターでのQuery Termによる情報のサーチを含む。このユーザーは、クエリー事項(単数または複数)をクエリーボックスに入れ、そしてResultリストが、この事項(単数または複数)を含むドキュメントを含むという期待を有する。ここで、ユーザーは、事項およびBooleanオペレーターでクエリーを構築することを欲する。このユーザーは、すべてのBooleanオペレーターが支持されている、すなわち、かれらが、サーチエンジンによって認識され、しかもクエリー−ストリングの条件を満足するドキュメントのみが回収されるという期待を有する。
【0103】
Boolean言語サーチは、「フィールド情報」の使用を経由して拡張され得る。この技法は、ユーザーが、特定のメタデータおよびデータのコンテンツ属性をサーチしこのサーチをさらにフィルターにかけることを可能にする。代表的なフィールドは、種々のタイプのドキュメントデータ、著者、タイトル、刊行物、トピック分類などのような項目を含む。
【0104】
トピックによるサーチ(そこでは、トピックスが、編集プロセスにより進んで割り当てられた特定のドキュメントをともなう)は、Booleanサーチに対するFieldedサーチの拡張を用いて達成されるが、より便利なサーチとして同じ方法でユーザーに曝されなくてもよい。フィールドはまた、コンテンツコレクションに極めて特異的である、例えば:事例に対するパーティ、ジャッジ、ドケット番号などに拡張され得る。
【0105】
サーチの別の方法は、自然の言語を用いる情報に対するSearchを用いることである。ここで、ユーザーは、自然の言語の構文でクエリー項目を入力することを欲する。例えば:「保険詐欺」。Natural Langageサーチャーから戻るサーチ結果は、文構築構文を省略して、サーチの事項に関する関連性を有することが期待される。例えば、上記のサーチでは、戻る結果は、用語「保険詐欺」を含むべきである。
【0106】
アラート(Alert)として知られる混合Search機能が提供され得、ここでは、ユーザーは、それらの実施の領域(単数または複数)に関連するなにかが変更されたか、新たな情報があるとき、アップデートすることを欲する。ユーザーは、定期的ベースで自動的に稼動するサーチアラートのポートフォリオをセットアップする。各アラートは、特定の規定された間隔で特定のコンテンツコレクションに対して特定のサーチを走らせるためにセットされる。各アラートは、規定されるべき特定の属性を可能にする。サーチャーには、これらの属性は、例えば、クエリー事項、コンテンツコレクション、主題の領域などを含み得る。ユーザーは、複数のアラート、および各アラートについてそれらのポートフォリオにおける頻度のストップ、スタート、削除または変更を規定することができるべきである。このアラートサービスによって見出されたドキュメントは、従来のクリッピングサービスの様式で送達され得る。
【0107】
このFind操作は、ユーザーがコンテンツコレクションから単一のドキュメントを回収することを可能にする。一般に、ユーザーは、司法のような特定の分野、カテゴリーまたは領域、またはFind操作の一部分として実施領域を特定することを要求されるべきではない。Find操作のユーザーは、ドキュメントが存在するという予備知識を有し、そしてその特定のドキュメントにアクセスすることを希望する。このようなユーザーは、例えば、サイト、タイトル、関与するパーティ、またはドキュメントの共通名のようなそのドキュメントに特異的な情報を識別する。
【0108】
特定の参考は、特定のドキュメントを記載するには不十分であるかもしれない。このタイプの問題は、同じドキュメントの複数テキスト、異なる言語の同じドキュメント、または特定の引用略語の異なる供給源で生じる。例えば、略号「ALR」は、AmericanとAustralianとのLegal Report刊行物の間を区別するには不十分である。このような場合、このFind操作は、この参照に適合する特定のドキュメントのすべてのバージョンを回収し、そしてユーザーが目的の特定のドキュメントを選択することを可能にする。
【0109】
このFind操作は、SearchまたはBrowseとは異なる。Findは、ユーザーが単一の特定のドキュメントにアクセスすることを可能にする。Searchは、ユーザーがかれらが規定する規準のセットに適合するドキュメントについてコレクションを走査することを可能にする。Browseは、ユーザーが、かれらの必要性に適合し得るドキュメントの分類学を通じて精選する。
【0110】
Findコマンドにまた含まれて、ユーザーが、ドキュメントまたはそのメタデータの1つ以上の属性を特定することによりドキュメントを回収することを可能にする、Find by Attribute操作がある。Find by Attribute操作の例は:Find by Title、Find by Parties(パーティに参加することにより調べる)、およびFind by Common Nameがある。
【0111】
アプリケーションに依存して、Find操作を走らす前に、プレフィルターをセットアップすることが適切であるときがしばしばある。このようなフィルターは、ユーザーがCountryコード、Lauguage、Applicationドメイン、Applicationで規定されるコンテンツセット、Contentタイプ(法律、規則、税金、ニュース)、Practiceエリア、Jurisdiction、Classificaton区画などにより結果を制限することを可能にし得る。ユーザーは、かれらが、より広いコンテンツベース内でドキュメントを見出すことを希望する場合、このようなデフォールトフィルター属性を置き換えることができるべきである。
【0112】
Find操作は、その他の操作とパイプラインされ、特有の新規操作または製品を生じる。例えば、Find操作の出力は、直接プリントに送られ得るか、またはeメールサーバーに押され、単一ドキュメントの送達を生成する。ユーザーのプロフィールは、非特有の結果の数を制限するために、複数のコレクションに対して進行するFind捜査のために、デフォールトと自動プレフィルターのセットを含んで用いられ得る。
【0113】
Find操作の履行のためのデータ要求は、設計時間の間のコンテンツアプリケーションについて決定されるべきである。このアプリケーションは、Find機能性を提供するために十分な、規準化されたかつ正規の名、参照および各ドキュメントのついての情報を提供し得る。
【0114】
サーチレベルでは、Findは、Search操作と類似である。一般に、Findは、履行および/またはユーザーインターフェースである。ユーザーの視点からは、Findは、Searchが操作が、条件のクエリーに適合する1つ以上の可能なドキュメントについてコンテンツコーパスを走査し、そしてそれでエンドユーザーに異なるタスクモデルを提示する間に、コンテンツコーパスから既知のドキュメントをどうにか引かなければならない。
【0115】
(Table of Content(TOC)機能)
CCRDSサーバー400により提供されるTOC機能は、コンテンツのペーパーブックテーブルの電子バージョンであるが、ドキュメントへの頭だしレベルおよびドキュメントへのリンクすることの拡張/押し縮めを可能にする適切な技法で増大される。TOCは、階層のトップのルートノード、随意の中間ブランチおよびターミナルエンドのリーフノードから構成される。リーフノードは、ドキュメントまたはドキュメント内のセクションに単一にリンクしている。
【0116】
Browse Table of Content(TOC)操作は、ユーザーがコレクションのコンテンツの階層図を追求することを可能にする。コレクションは、1つ以上のドキュメントから構成され得るので、対応するTOCは、複数ドキュメント、単一ドキュメント、または特定のドキュメントのサブセクションのためのTOCを提示し得る。逆に、ドキュメントの単一コレクションは、複数のTOCを有し得る。TOCは、特定のユーザータイプおよびそれが参照する特定のDOCコレクションに適合され得る。
【0117】
TOCをブラウズする間、ユーザーは、かれらが見出すことを試みる特定のドキュメントの予め存在する知識を有し得:かれらは、法律および/または実施の親しみのない領域に関する指針を捜し得;またはかれらは、TOCを用いて論点または問題を補助して作成し得る。TOCによりアドレスされるコンテンツコレクションが1つのドキュメントであるとき、そのときは、関連するTOCは、ドキュメントの構造を反映し得る。ユーザーは、大きなドキュメント、例えば、Legislationを航行するためにこのタイプのTOCを必要とする。
【0118】
同様に、コンテンツコレクションが、複数のドキュメント、例えば、Journal Articles、Statutes、またはフォームを含むとき、TOCは、各ドキュメントの存在を示して生成され得る。これは、ユーザーが適切なドキュメントをブラウズかつ選択し得るためにすべてのドキュメントのリストを必要とするための重要な特徴である。
【0119】
TOCブロウジング機能は、リンクされた材料の航行アクセスを含む。航行には、TOC構造は、コレクションの性質およびサイズに依存して、狭く、広く、深く、または浅くあり得る。このTOCは、スクリーン上の航行を支援するために拡張する(より低いレベルを示す)か、または押し縮める(より高いレベルを示す)階層のレベルを有し得る。
【0120】
ユーザーは、特異性が増加する各レベルにある、トップレベルノードから中間および末端ノードまでのリンクに従うことにより、TOCを下降する。このようなリンクは、アウトライン形態、開放または閉鎖され得るフォルダーのいずれかで明瞭に示されるか、またはその他の階層ユーザーインターフェース方法を用いる。ユーザーがこのTOCを下降するとき、「ブレッドクラム」トリイルが生成され、訪問された各レベルに戻るリンクを提供する。ユーザーは、トップレベルノードから選択すること、そして別のパスに沿って戻って移動することによるか、またはTOCをサーチすることにより、TOCを横切って航行する。
【0121】
このTOCは、そのコレクション内の任意のドキュメントを見るときアクセス可能であるべきである。コレクション中の他のドキュメントに対するそのドキュメントの相対位置は、TOCによって示される。ユーザーは、このTOCを、コンテンツコレクション中の任意のドキュメントを見ると同時に航行し得;すなわち、このドキュメントは、ユーザーがさらなるコンテンツを捜してTOCを航行するとき、なお開いている。
【0122】
TOCが、特定のコンテンツコレクションのために、視覚TOCを生成するようフィルターにかけることにより、視覚TOCを生成するよう混合することにより、例えば、編集により、プログラムにより構築され得る。もちろん、TOCは、従来のアプローチを用いて手動で生成され得る。TOCは、コンテンツ中に含まれるマークアップを利用することによりプログラムにより生成され得る。このような場合、このTOCは動的に作製され得、そして種々の方法で組織化され得る。一旦、TOCが生成されると、それは、異なるリソースアプリケーションによって異なる様式で用いられる得るメタデータの柔軟な本体を提供する。TOCは、リソースアプリケーションにより動的にフィルターされ得、1つ以上の完全TOCのサブセット表示を生成する。このような表示は、ドキュメントまたはコレクションのTOCのより大きなコンテンツ内の特定のドキュメントのサブセクションを示す稼動ヘッダーおよびフッターを生成するために用いられ得る。フィルターされた表示は、トピックの、司法の、管理の、または一時的サブセットへの表示を制限するTOCの性質を抽出することにより生成され得る。1つ以上のTOCから抽出された複数のサブセットは、動的に抽出され得、そして組み合わされて、物理的スペースに単一ドキュメントとして存在しない仮想ドキュメントに対応する視覚TOCを生成する。
【0123】
仮想TOC表示を生成するためのサブセット抽出フィルターは、すべてのレベルの全TOCに対して、または複数のコンテンツセットTOCに対して付与され得る。上記のように、これらサブセット抽出の結果は、所望の選択された部分をクリップして出す。このクリップされたセクションは、次いで、配列され得、新規な混合表示TOCを生成する。この表示TOCは、ユーザーに、同一または異なるコンテンツコレクション中の複数の参照を示す単一の仮想ドキュメントの外観を与える。
【0124】
インデックスもまた提供され得る。このインデックスは、特定のXMLタグおよびコードをドキュメント内のテキストにマップし、そしてまた、ドキュメント、コレクションまたはセット内の全体のテキストを、完全にサーチ可能なツール中にマップする。
【0125】
(ロード管理)
本アーキテクチャーは、ハードウェアおよびロードに応答するために共通であるその他のリソースのスケーリングを容易にする。複製されたリソースとともに、ロードを、タスクが、その他がこのようなタスクに代用可能であるとき、特定のリソースに過度に待ち行列を作らないようにバランスすることが必要である。従って、本発明は、ロード管理にビッドスタイルを採用する。これは、待ち行例を作っているタスクのさらなる処理のためにそれらの利用可能性を報告するためにアイドルまたは低ロードリソースを必要とする。このビッドモデルは、モニタリングコンポーネントによるLDAPの使用により一部履行され得る。
【0126】
(ログ)
ログは、共有されたサービス/ツールによりリクエストされる事象をトラックし、そして何が実際に入ったかを基に診断を可能にする。すなわち、フロントエンドドキュメントロードおよびユーザーサーチの両方がトラックされ、リアルタイムモニタリングおよび階層エラーチェッキングを提供する。
【0127】
(データ管理)
データ管理コンポーネントは、基礎的なシステム維持および最適化を提供する。
【0128】
(CCI(中央制御情報))
CCIコンポーネントは、すべてのメタデータが記憶されている場所を管理し、そしてそれを各データコレクション中の形態についてそれをモニターする。取り込みの間、このCCIは、コレクションのロードセットが与えられる。ロードセットは、XMLデータが、共有ツール/サービスによってどのように処理されるべきかを規定するためのルールを含むテーブルである。詳細なインデックス規則、DOC、TOC、およびMMに対する処理規則、およびどのビルダーによりどのエレメントが処理されるかの規則を含むロードセットが存在する。ロードセットは、1つ以上のデータコレクションにより共有され得る。
【0129】
(DOC)
DOCは、レンダリングコンポーネントへの送達のために、リクエスト、戻りドキュメント、改変、マークアップおよびセットアップドキュメントをとるサービスである。これは、ドキュメントフィルタリングのためのDOC回収エンジンによって提供されるファシリティーを含む。DOCはまた、完全XMLドキュメントから良好に形成された部分を識別かつ回収するために設計されたフィルタリングオプションを提供する。
【0130】
(ユーティリティ)
ユーティリティサービスは、それら自身のサービスでは保証されていない多くのサービスを集めるために設計された一般的サービスである(これは、それら自身のMQ待ち行列を有することを意味する)。以下のサービスがこのUtility Service内に収容されている。
【0131】
(1.ドキュメントロケーター)
このサービスは、どのコレクションが、GUIDを与えられたドキュメントをどのコレクションが含むかを位置決めするために用いられる。それは、一般に、ハイパーリンクを置き換える、および/またはそれに従うときに用いられる(これは、標的GUIDのみを含む)。
【0132】
(2.結果航法)
このサービスは、サーチ結果オブジェクト内の基礎的航法のための機能を提供する。このSearch Serviceは、サーチ結果オブジェクトを生成する。このDOC Searviceは、ドキュメントのテキストを回収するために用いられる。このResult Navigation Serviceは、これら2つを、クライアントが特定のランクについてドキュメント情報(GUID)をリクエストすることを可能にすることにより結びつける。この情報は、サーチ結果オブジェクトから抽出され得、そして戻される。次いで、クライアントは、必要な情報をもち、それを用いてDOC Serviceがドキュメントテキストを回収することを誘起する。
【0133】
(3.PIT Get)
クラアントは、それらの世界の表示を「凍結」するための機構といてPIT(時間点、point−in−time)値を用いる。同じPITが次の共通コンテンツレポジトリーサービスコールについて用いられ限り、この表示は一定のままである(それらは、ロードされた任意の新たなデータを見ない)。クライアントが、新たなPITをリクエストするとき、それは、リクエストの時間における時間点流れへのその表示をリセットしている。
【0134】
(4.持続的オブジェクトデストロイヤー)
Persistence Service仕様で記載されるように、持続的オブジェクトの破壊は、クライアントの責任である。このPersistent Object Destryer Serviceは、クライアントが、この破壊が生じるようにし得るAPIを提供する。別個および特有のAPIは、各タイプの持続的オブジェクトを破壊するために生成される。
【0135】
(持続性)
Persistence Serviceは、図4中では、ARサーバー300の一部として見られるが、それは、共通コンテンツレポジトリーおよびCCRDSサーバー400と緊密に関連している。Persistenceコンポーネントの機能は、サーチの再実行を必要とすることなく次のアクセスのためにサーチ結果を記憶することである。例えば、所定のサーチは、100の関連するドキュメントのための識別子を回収することに至り得る。1〜10のドキュメントが表示され、その一方、11〜100までが保持されている。従って、ユーザーがドキュメント50選択すると、ドキュメント50は、サーチを再び実行する必要なく、記憶された識別子にアクセスすることによりPersistenceコンポーネントから後に決定され得る。サーチコンポーネントで共通のコンテンツレポジトリーをアクセスする複数のユーザーで、このPersistenceコンポーネントは、サーチコンポーネントの負荷を容易にする。
【0136】
(ウェブサーバー、ARサーバー)
ウェブサーバー200およびARサーバー300コンポーネントは、CCRDSサーバー400のドキュメントレポジトリー中にあるデータに基づく、ウェブベースアプリケーションを生成および破壊するために用いられるアプリケーションフレームワークを提供する。このフレームワークの部分として、ARサーバー300は、参加するビジネスユニットを横切る顧客に関する共有情報を促進するための高レベルのゴールを有している。共通レポジトリーは、ビジネスユニットに参加するためのユーザー情報を記憶する。これらのコンポーネントはまた、ユーザーによる複数アプリケーションのための単一のサインオンを支持する。
【0137】
ARサーバー300は、異なるリソースアプリケーションと関連する複数の異なるユーザーインタフェースコンポーネントからアクセスできるようにする単一のホストプラットフォームである。このプラットフォームは、翻訳(Rendering)、ローカル化(Localization)およびアラート(アラート)サービスと同様に、若干の共通機能を提供するコンポーネントのセットを有する。プラットフォームは、また、フェイルオーバー(failover)を支持し、且つ高い有効性を支持するコンポーネントを支持するための持続性を実行する共通の標準設計を含む。加えて、再使用可能で一般的な持続するデータコンポーネントは使用可能とされる。セキュリティモデルが、顧客の単一のビュー(view)を確実にするために、認証およびアクセス制御のために提供される。プラットフォームは、モニター、管理および展開のための共通手順を更に含む。
【0138】
ARサーバー300のコンポーネントは、CCRDSサーバー400のデータ格納部から共通性を引き出す特定のユーザーインタフェースのためのアプリケーションをカスタマイズするために、ツールキットをリソースアプリケーションデベロッパーに提供する。ARサーバー300の重要なコンポーネントに関する説明は、以下に続く。
【0139】
(重複の検出)
重複の検出サービスが、それが最後に見られた時からそれが修正されない限り、同じドキュメントが再び示されるのを防止するために、フィルタとして機能する。表題、ソースまたはバージョンの重要でない違いだけについては、例えば、ユーザーが質問をDOCコレクションに提出して、重複を含むドキュメントのリストを受けとるときに、重複ドキュメントの問題は起こる。これは、例えば、ニュース記事に起こり得、それは共通コンテンツレポジトリー部に記事を提供する多くの新聞において同様に報告され得る。ニュース検索から戻されるドキュメントの30%と同程度多くのものは重複ドキュメントのセットの部材であり得ることが分かっている。重複ドキュメントのセットの中で、重複と思われ得る全てのドキュメントの半分以上は、正確な重複のカテゴリに分類される。しかしながら、非常に類似しているが同一でないドキュメントを検出するための重複のよりあいまいな概念を含むことはまた面白いかも知れない。
【0140】
2つのテキストストリングの比較として、アブストラクトの充分なレベルで、ドキュメント重複の検出は調査することができる。しかし、このとき、引用および候補ソースドキュメントの代わりに、1つはドキュメントおよび候補ソースドキュメントを有する。上部のn(nは比較的少ない整数である)のドキュメントidf条件(各々と関連して特長およびそれらの位置を含む)が、比較のために、ドキュメントの「指紋」を提供するのに十分であると決定された。ここで、idfは、「逆のドキュメント頻度」を意味し、与えられた条件が、条件の「ドキュメント頻度」の逆であり、すなわち、1が、条件を含む考慮の基で、コレクションのドキュメントの数によって分けられる。
【0141】
この指紋は、重複検出システムで使われる各々のドキュメントのためのメタデータ分野として準備されなければならない。それは、ドキュメント入力時に実行されなければならない計算作業を提供する(ドキュメント収集がすでに共通コンテンツレポジトリーに収納されるために、それは後でなされ得るが)。重複を含み得る検索結果が成されるときに、実際に指紋比較をする計算負荷を広げるのを助けるために、比較作業は、クライアント側(検索要請はそれから始まる)およびサーバー側で分けられる。このように、重複の検出は、基本的に次の3つのステップを含む。
【0142】
(A.メタデータ生成−バッチロードプロセスの間)
ドキュメント入力セッションの間、各々のドキュメントのために、完全なドキュメント署名(signature)がメタデータ(長さスカラー+指紋ベクトル)の形態として格納される。
【0143】
ドキュメントの「長さスカラー」(表題、著者および他のヘッダ情報を含む特徴で)が、署名(背丁)の一部として格納される。
【0144】
「指紋ベクトル」は、例えば、『言葉のごまかし[76]、人質[O]、顕著な[25]、非妥協性[121]、残忍性[163]、シアター(theater)[13]』(idf値によってランクした)、などの互いに関連するそれらの位置とともに、ドキュメント(ヘッダ情報を除外する)の上部n(nが4〜30、好ましくは4〜6、最も好ましくは6である)のユニークなidf条件から成る。
【0145】
考慮中の条件は、ドキュメントのタイトル、および他の見出しを排除することに注意されたい(なぜなら、異なるタイトル、発行者、編集等によって、これらは明らかに変わり得るので)。
【0146】
さらに、異常に高いidf(すなわちidf>0.8)は、トップ6の候補とは思われないことに注意されたい。なぜなら、これらは異常(すなわちタイプミスおよびミススペル)である傾向があるので。
【0147】
指紋ベクトルは、それから、対処可能な長さのキーにハッシュされる、例えば[!X9V^4#w+z2%7t$d](16バイト)。それらが二回以上ドキュメントに記載される場合であっても、ドキュメントの最も高いidf条件は、一回ベクトルの一番上のnのidf条件に現れ得るだけである。
【0148】
(B.ドキュメント比較処理−サーバー側に検索結果リストが与えられる)
サーバーに、検索結果のトップランクのドキュメントおよびそれとまだ比較される次のドキュメントが始まる。
【0149】
ドキュメントの長さが比較される、仮に、比較ドキュメントが、ベースドキュメントの±M文字の範囲内である場合は(例えば、Mが0〜256、好ましくは40文字)、続ける;そうでない場合は比較が終わる(±Mが、ヘッダ材料の近くでテキストの潜在的な差異を補償するのに役立つ)。
【0150】
ドキュメント指紋が次に比較される。仮に比較ドキュメントがベースドキュメントのそれと同一の指紋を有する場合、重複として重複ドキュメントにフラグを付ける、そうでない場合は、比較を終える。
【0151】
重複の状況のためにフラグを付けられたドキュメントは、クライアント上の重複フォルダに効果的に移動される。
【0152】
すでに重複のためにフラグが付けらない次の最高にランクが付けられたドキュメントは、以前にフラグが付けられない結果リストの下の順位の他の全てのドキュメントと比較される。
【0153】
そのプロセスは、フラグが付けられないドキュメントの最後の一対が比較されるまで続く。
【0154】
(C.ドキュメント翻訳−クライアント側)
(1)重複のないドキュメントは、標準の検索結果リストに記載される。
(2)重複を有する最高位のドキュメントは、標準の検索結果リストに記載される、しかし、それらの対応する重複のドキュメントが、「重複」フォルダ(例えば、スクリーンの下側の左手の隅に見られる)において見られることを示すためにマークされる。
(3)残りの重複のドキュメントは、「重複」フォルダにおいて見られる。
【0155】
この重複の検出システムを実行することは、いくらかのさらなる考慮を含む。
【0156】
最高にランク付けされたフラグのないドキュメントは、標準の結果リストに維持される。
【0157】
idfsは、時間とともに疑いなく変化する。idfsが得られるコレクションが変化する場合、今日発生する指紋は、来年発生する指紋に対応しないかもしれない。周期的にドキュメントの指紋を再生する必要性を回避するために、それから、idfsスコアを基にする大きな安定したコレクションを維持することは重要である。あるいは、一旦大きな安定したコレクションが決定されるならば、条件およびそれらの対応するidfsは、単に参照表に経済的に格納され得る。
【0158】
ニュース記事のようなドキュメントにおいて、全てのnの上部idf値の条件が同じパラグラフから来ることは可能である。これは、このように乏しいクロスドキュメント範囲を表すようである。しかしながら、およそ1ページの平均の長さで、ニュース記事は長くない。全てのnの高いidf条件が、1つの比較的小さい場所で起こることが非常に低い可能性である場合であっても、これはそれらのドキュメントの範囲がいかなる形であれ減弱するということはできない。ドキュメントの他のセクションにおいて最も高いidf条件の欠如もまた検出に役に立つので、指紋範囲は完全なままである。
【0159】
指紋ベクトルをハッシュ(hash)することを選択せず、その代わりに、比較されるベクトルの条件の±1、±2又は±Nの関係を許すことによって、ある程度の「不明瞭」を重複の検出プロセスに加えることができる。このように、システムを重複の検出の所望のレベルに合わせるために、2つのドキュメント間の指紋および/または長さスカラーパラメータが、規定のマルチファクターに対して測定でき、類似閾値に調整可能である。
【0160】
ハッシュすることは、比較されるドキュメント署名に厳格に余分のレベルを加えることができる。なぜなら、idf値における適度の変化は、最高のnのidf条件のオーダーを変えることができ、条件自体でないからである。そのため、用語A[0]の中でハッシュ、用語B[25]の中でハッシュは、用語B[25]、用語A[0]・・・とは異なる。従って、idf算出が標準のマスターコレクションを使用して安定しない限り、より多くの比較は上記の現象のゆえに失敗し得る。
【0161】
(ドキュメント翻訳コンポーネント)
ドキュメント翻訳コンポーネントは、ドキュメントをアプリケーション特殊スタイルシート(application−specific stylesheet)にマップする。各々のドキュメントは、ARサーバー標準に従って、スタイルシート参照タグで埋められる。翻訳コンポーネントは、外部入力を必要とする。これらの入力は、アプリケーション開発者のカスタムスタイルシートおよび付随するスタイルシートGUIDへのスタイルシートのマッピングを含む。入力は、ファイルシステムおよび共通のコンテンツ保管システムを使用している翻訳コンポーネントによって検索される。
【0162】
ドキュメント翻訳サービスは描きおよびXSLスタイルシートを蓄える。リソースアプリケーションは、toHTML()を使用してXMLのスタイルを整える。図19は、ドキュメント翻訳がどのように最小のプレゼンテーションスタイルシートを続行するかについて模式的に示す。図20は、ドキュメント翻訳がどのようにカスタムスタイルシートによって、そして、多数のスタイルシートマップによって続行するかを図式的に示す。
【0163】
(お気に入りオンラインアプリケーションの具体的なインフォメーション格納)
このサービスは、ユーザーが日常的に使用するドキュメント、コレクション、検索文字列またはセットを選択、格納およびアクセスできるようにする。このコンポーネントは、また、ユーザーが、そのユーザーのためそのドキュメントに格納される所与のドキュメントにコメントを加えることができる。格納され得る情報の他の実施例は、保存されたサーチ(Saved Searches)、ドキュメントに対する保存されたクイックリンク(Saved Quick Links)、アラートデフィニションに対する保存されたクイックリンク(Saved Quick Links)を含む。その情報は、ユーザーによって操作され得る動的な階層として格納される。特徴は、従来のウェブブラウザのお気に入り特徴と類似している。
【0164】
(画像転換)
JPEGに対するTIFFの共有サービス/ツール変換の画像転換コンポーネントが撮像を表わし、又は他の画像フォーマット転換を実行する。コンポーネントはさらに、画像および支持画像操作の大きさを変更するための特徴を支える。上記は、スケーリング、回転、クロップ(cropping)、フィルターを含む。従来の画像転換コンポーネントが使用され得る。
【0165】
(ローカル化)
このコンポーネントはユーザーに、個々に彼らのローカルユーザーインタフェースを修正し、カスタマイゼーション(custornization)を提供することを許容する。例えば、ユーザーインタフェースは、スペイン語に翻訳されることができ、または特定の市場のためスペイン語で開発され得る。さらに、自然言語の調査が許される範囲で、ローカル化は、英語検索エンジンの全て又は一部はローカル言語に特有の検索コンポーネントと交換されることを必要とし得る。
【0166】
ローカルは、言語、地方およびこれらのバリエーションによってユーザーのために特定され得る。テキストおよび画像の両方は、ローカル化され得る。1つのプロパティはファイルし、そして、1つのディレクトリはローカルにつきセットアップされる。
【0167】
(アラートAPIおよびサービス)
アラートサービスは、選ぶ顧客が質問を検索することを許容し、それは指定された間隔で動作する。検索の質問が新しい結果がを出すたびに、検索結果はエンドユーザーに送られる。アラートサービスは、電子メールおよびファクシミリ用の共有サービス/ツールドキュメント送達メカニズムを使用する。以下のコンポーネントは、アラートサービスの一部である:アラートエントリを保つためのデータベース;ユーザーインタフェースからアラートエントリを操作するためのAPI;アラートエントリを行い、結果を顧客に伝えるためのサービス。これらのコンポーネントは、各々のリソースアプリケーションが、それらの特定のアプリケーションのための同じアラートサービスを使用できるようにする。
【0168】
図16に好適に示されるように、あらゆるユーザーに対する警告は、警告API1602を使用したディレクトリへのエントリーを伴って設定される。警告エントリーは、作成され、修正され、削除され、あるいはランされる。警告エントリー内において定義されるドキュメント選択データをランする頻度は、毎日、ウィークデイ、毎週、隔週、毎月に設定可能であり、あるいは保存される。警告サービス1604は、コモンコンテンツレポジトリー1606および警告データベース1608と情報交換し、続いてクリップしたドキュメントをドキュメントはデリバリーサービス1610を介してデリバリーする。ユーザーは、マルチプルDOCコレクションを利用できる。
【0169】
(ドキュメントデリバリーAPIおよびサービス)
デリバリーサービスは、ユーザーにオンラインドキュメントの物理的あるいはローカルな電気的コピーの作成を可能にする。デリバリー機能は、調査処理のあらゆる場面においてアクセス可能である。ドキュメントをデリバリーするために、ユーザーは、一般に以下の情報を特定する:デリバリー内容、包含(inclusions)、省略、デリバリー先、およびフォーマット。
【0170】
デリバリー内容を決定するために、リソースアプリケーションは、特定のドキュメントあるいは所産のためのデリバリー機能にアクセスするための少なくとも1つの方法を提供すると想定される。直接的指示(例えば、ページ上のボタン)あるいは間接的指示(例えば、プリントリンク)によってなされるかは、機能的には同一である。一般には、全体のドキュメントあるいは所産(artifact)がデリバリーされると想定される。大きなドキュメントに対しては、ユーザーには単にドキュメントの特定部のみがデリバリーされ得る。テーブルコンテンツのような手段が、ドキュメント部分の選択に使用できる。
【0171】
何を含有しあるいは省くかの決定に際し、デリバリー操作のディフォルトモードは、全体テキスト、ならびに映像および特殊なドキュメントに伴うテーブルの全体セットを含む。ドキュメントタイプあるいは他のプロパティに応じて、追加アイテムがデリバリージョブに追加され、あるいは削除される。ユーザーに、各アイテムがドキュメントタイプに適合するかのチェックは、はずされる。
【0172】
デリバリー先は、ユーザーの選択およびデリバリー先装置の有効性に基づいて決定される。例えば、デリバリー先は、添付のプリンタ(ユーザーコンピュータあるいはLANに添付されたプリンタ)、Eメールアドレス(プリントジョブに代えて、ファイルのフォーマットコピーがユーザーのEメールアドレスに送付される)、ファックス(ファイルのフォーマットコピーがユーザーのファックスアドレスに送付される)、あるいはダウンロード(ファイルのフォーマットコピーが、ユーザーによって特定されたデリバリー先のユーザーコンピュータのハードディスク上に保存される)を含み得る。ユーザーは、デフォルトとしてデリバリー先を選択するまで、デリバリー先アドレスを特定する必要はない。
【0173】
デリバリー(および多様な他のオプション)のためのユーザーの選択は、リソースアプリケーションおよび共通サービス/ツールのためのデフォルトバリューを保持するファイル内に特定されている。
【0174】
ドキュメントデリバリー用にサポートされたフォーマットは、HTML、RTF、PDF、PostScriptおよびテキストファイルを含む。図18Aおよび図18Bは、ドキュメントデリバリーに含まれる種々のコンポーネントの関係を示す。デリバリーされるドキュメントは、ドキュメントを表示コンポーネントに提供するデリバリーサービスによってアクセスされる格納装置に一時的に保持される。デリバリーサービスは、表示コンポーネントを有し、XMLおよびXSLtドキュメントを取り入れる。それは、これらをXSL FO、HTMLおよびテキストフォーマットにおいてデリバリーする。XSL FOプロセッサは、SMTPメールによって送信可能なHTMLおよびPDF/PostScriptドキュメントを作成する。RTFプロセッサは、RTFドキュメントをウェブ(Web)に提供する。テキストを含むHTMLドキュメントもまた、デリバリーされ得る。
【0175】
(トレイルAPIおよびサービス)
トレイルサービスは、再作成可能なアプリケーションイベントの相互交流のあるヒストリを維持する。これによって、ユーザーは、ドキュメント結果を再作成するリサーチイベントを再開発する要求をすることなく、即座にドキュメントを発見することができる。すなわち、システムは、結果として生じるドキュメントのテキストではなく、共通コンテンツ保管場所および作成結果の問い合わせによって実行されるようなリサーチに関する情報を保持する。例えば、各ドキュメントはGUID(Global Universal Identifier)によって識別され、また「Best−of−the−searched−GUIDs」は、参照のために、トレイル機能によって格納される。常時ユーザーは、作成されたリソースアプリケーション、ユーザー要求のトレイルおよび修正のうちの1つに関する新しいセッションを開始する。ユーザーが以前の要求に戻る必要がある場合、トレイルコンポーネントは、サーチプロセスの間に設立されたトレイルを使用してドキュメントへの即座なアクセスを提供する。トレイルコンポーネントは、また、ユーザーにトレイルを保存あるいは以前のトレイルへのアクセスを可能にすることによって、以前のセッションからのサーチの利用をユーザーに可能にする。
【0176】
トレイル機能は、トレイルデータベース1702(図17参照)に保持されたデータ構造内のユーザーによって実行された操作シーケンスを収集することにより、ユーザーに、簡易で迅速な方法によって以前のサーチを可能にする。トレイルディレクトリは、作成、削除、変更および回収作業を特定するために使用される。トレイル機能は、ユーザーにアクセスを与え、ユーザーにトレイルデータの操作を許可する。
【0177】
トレイル記録はサーチセッションの間に形成され、データ構造としてリソースアプリケーション内に保持される。トレイルデータ構造は、特定のパスワードに特定さてれおり、そこでは、認証手段、その上クライアントIDによって記録される。トレイル内に記録されたイベントは、基本的に変更可能なリサーチイベント、例えば最初のドキュメント取り込み、サーチおよび引用要求に対応し得る。イベントをクリックすることにより、ユーザーはドキュメント、サーチへの戻り、あるいは引用等にリターンすることができる。
【0178】
リソースアプリケーションは、ユーザーに、リサーチセッションの間、いつでもトレイル設備へのアクセス(トレイルイベント需要者1706を介して)を可能にする。同様に、トレイル設備は、ユーザーに、リサーチセッションへの離れた地点への継続的な再入力を可能にする。
【0179】
アプリケーションは、トレイルワークを以下の追跡方法によって進行する。アプリケーションは、ニュートレイルを作成し、特定の情報(例えば、トレイル名、プロダクト、ユーザーID、クライアントID等)を設定する。トレイルはまた、作成データ、最終アクセクデータ、および期限切れデータを含む。追加パラメータも定義可能であり、特にプロダクトによって利用可能である。この「プロパティ」は、データベース検索ができないXMLストリングに格納される。その他、アプリケーションは、特有のトレイルキーによって、特別に先存するトレイルを得る。
【0180】
プロダクトの「再作成可能イベント」(例えば、サーチ結果、ドキュメント)のために、アプリケーションはニュートレイルアイテムを作成し、それをトレイルに加える。トレイルアイテムは、アイテムタイプ(例えば、サーチ、ドキュメント)のような特別情報を格納し、またデータを作成する。特にプロダクトによって定義されかつ使用される追加パラメータは、格納可能である。これら「プロパティ」は、XMLストリングに格納され、また、プロダクト用のイベントを再作成するために使用可能である。
【0181】
システムはトレイル要求をキュー(queue)に置き、バックグランドサービスがその要求を処理する。FIFO(First−In−First−Out)フォーマットが、要求を処理するために使用される。サービスは、新規要求のためのキューを継続的にモニタする。データベースエラーが発生した場合、キューはバックアップされ、トレイル情報をユーザーに対して遅延する。それは、アプリケーションの実行をスローダウンさせない。
【0182】
リソースアプリケーションは、利用可能な最もアップデートなトレイル情報を調べる。アプリケーションは、需要者のためにトレイルアイテム(例えば、再作成可能なイベントへのリンクを伴うウェブページ)のリストを作成するために、トレイルAPI1708を使用する(イベントの再作成は、特別がプロダクトのために正当な請求イベントがビジネスルールに基づいて作成されあるいは回避されることを確認するアプリケーションによってコントロールされ、そのためイベントはトレイル上に再作成されないことに、留意を要する)。
【0183】
アプリケーションは、ユーザーセッションが終了したとき、あるいはアプリケーションが明らかにトレイルを終了したとき、トレイルを終了する。
【0184】
トレイル情報の他の使用は、ユーザーの要求および期待に適合するためのシステム改善にある。そのため、要求メッセージに応答して見出されたドキュメント用の特別なリソースアプリケーションおよび識別子の範囲内の、ユーザーサーチ処理に関する情報を保持する1つ以上のトレイルファイルを、システムが有する場合、この情報は、特別なリソースアプリケーション用の共通使用パターンを決定するトレイルファイルを処理するためのトレイル分析コンポーネントに対して、提供可能である。この分析は、検索オプションを提供するために、およびそのような使用パターンに、より適した結果を検索するために、リソースアプリケーションのパラメータ調整に導かれ得る。
【0185】
ドキュメントが検索結果として存在している優先オーダーに関連する検索結果内で識別されているドキュメントをユーザーが表示しているシーケンスを含む、共通使用パターンを、その分析がもたらす場合、調製されたパラメータは、ドキュメントが検索結果として存在している優先オーダーに影響を与え得る。その分析が、検索結果内に識別されたドキュメントのユーザーレビューが複製(duplicate)として含まれる共通使用パターンをもたらす場合、調製されたパラメータは、二重の検出サービスのための類似閾値に影響を与え得る。また、トレイル分析は、そのような使用パターンを具体化し、それに関連するリソースアプリケーションに適合させるために、メタデータ内に捕らえられている共通使用パターンに導かれ得る。例えば、リソースアプリケーションの最も経験豊富なユーザーのトレイル分析が、TOCブランチの少ない利用、あるいはTOCノードからの探査のある種のパターンを示す最も実際的なTOC使用パターンを表す場合、これは、ベストの実施と見られる具体化として提供され、また経験の少ないユーザーにとっても価値あるものとされ得る。
【0186】
(イベント課金/ロギングAPI)
共有されるサービス/ツールは、リソースアプリケーションの作成者に、ウェブアプリケーションからの課金記録を作成することを可能にする。課金記録は、一般的であり、リソースアプリケーション作成者に課金要求に必要なデータを獲得させる。APIはXMLに必要なデーダを提供し、しかしながら、リソースアプリケーション作成者は、一般的XMLをその課金システムに適正なフォーマットへの変換するリソースアプリケーションの提供に対する責任がある。
【0187】
APIは、リソースアプリケーションの特別の名前/価値ペアを伴うイベントを作成する。課金/ロギング機能は、課金イベント情報をビジネスシステム需要者にデリバリーする。ある種のデフォルトプロパティが課金イベントのために存在する:スレッドバリュー、機械名、ファイル更新記録、およびイベントGUID(イベントのためのグローバルな特有ID)。
【0188】
(セキュリティサービス:セキュリティおよびアクセスコントロールAPI)
セキュリティおよびアクセスコントロールの1つの部分は、サインオンおよびサインオフを含む認証を含む。このサインオン操作はユーザーを識別し、そしてリソースアプリケーションリサーチセッションを開始する。サインオンは、ユーザー識別子(ユーザーid)およびユーザー認証子(バスワード)を必要とする。これらは、リソースアプリケーションによるか、またはユーザーにより生成され得、(特有の識別子文字列が提供される限り)エイリアスを思い出す容易さを含む。このサインオフ操作は、このセッションを閉鎖する。
【0189】
アクセス制御操作は、リソースアプリケーションが使用法および/または制限アクセスをモニターすることを必要とする;ユーザーが個々またはグループを基礎にインターフェースのカスタム化を必要とする;アクセスが、コンテンツおよび/または機能レベルでモニターされなければならない;ユーザーアクセスが同じコンテンツを参照するアプリケーションタイプを横断して共有されなければならない(例えば、同じコンテンツコレクションへのウェブおよびインターネットアクセス);またはユーザーアクセスが複数のリソースアプリケーションを横切って共有されなければならないとき必要である。
【0190】
本発明とともに、複数のリソースアプリケーションが、共通システムを横切ってリンクされる。従って、認証プロセスは、ユーザーが使用する権利を有する種々のリソースアプリケーションのすべてについてユーザーにアクセスを提供する。しかし、これら種々のリソースアプリケーションが、それら自身の使用法要求および請求パラメーターを有するとき、この使用法をトラックかつ請求するアプリケーションへのユーザーID/パスワードの接続および記録は、各リソースアプリケーションの責任である。換言すれば、共通のユーザープロフィールが生成されかつ利用される。図13は、ユーザー認可情報を基づくユーザーの置き換え、およびそれらの質問メッセージを提供するために、オンラインで共有されるセキュリティコンポーネントが、どのようにリソースアプリケーション1302およびセキュリティデータベース1304中に記憶されたインターネットセキュリティ情報と通信するかの概略図を提供する。図13は、さらに、顧客の定義、製品、価格プラン、認可などを維持するビジネスシステム1306が、どのように、管理サービス1308を通ってセキュリティデータベースにどのようにアプリケーションセキュリティ定義をおすのかを示す。この認可サービスは、このデータベースの維持を可能にするAPIを出す。このAPIは、XMLリクエスト応答メッセージに基づく。リソースアプリケーションに特異的なセキュリティ情報は、その他のアプリケーションによって用いられ得る。
【0191】
共有されたアプリケーションサービス中で履行されるセキュリティは、顧客の一致した表示を提供する。共有されたアプリケーションサービスSecurity Model中にユーザー実体(User entity)を生成することにより、顧客は、各サイトの証明書の特異的セットを思い出す必要性なくして参加サイト(またはリソースアプリケーション)間を容易に移動し得る。これは、ユーザーが、すべての参加サイトについて、唯一のサインオンIDおよびパスワードを必要とし、しかもユーザーの保証書が1つの安全な場所に記憶されることを意味する。
【0192】
従って、ユーザーを認証する共通サイト共有セキュリティは、それら自身の認証システムを構築、購買、ホストおよび維持しなければならないことはないことによって、時間およびお金を節約する。開発者は、それら自身のサイトの特徴および機能性に集中し得る。
【0193】
セキュリティは、ユーザーの基礎的プロフィールを支持する。言語優先およびファーストネームおよび名字のような情報は、アカウント生成時間で集まり得る。セキュリティモデル内のユーザーは、アカウントが生成されるとき、User Guid(グローバル汎用識別子)を割り当てられる。このユーザーを識別するために用いられるのはこの識別である。
【0194】
このセキュリティサービスは、種々のセキュリティタスクを実施する。このタスクは:現存するセキュリティユーザーを認証すること;リソースアプリケーションが認証を実施することを可能にすること;現存するセキュリティユーザーをアップデートすること;新たなセキュリティユーザーをセキュリティデータベースに追加すること;セキュリティユーザーを特定の特徴へのアクセスを認可するためにグループと関連付けるか、関連を解くことを含む。その他のセキュリティ特徴は、容積または価格限界をたどること、受給限界のタイミングをとること、エクスポート制御を含む。
【0195】
図14は、用いられるセキュリティパラダイムを概略的に示す。セキュリティは、ユーザー1402、ユーザーグループ1404、およびユーザーのための認可1406を含む。単一のユーザー定義がすべてのリソースアプリケーションについて用いられ得る。従って、1つのユーザーIDおよびパスワードが、ユーザーが任意のリソースアプリケーションからのドキュメントをアクセスすることを可能にするために用いられ得る。各ユーザーは、一旦性格なIDおよびパスワードが入力されると、利用可能になる特有の許可を認可される。ユーザーIDおよびパスワードが、Security APIを用いてセットアップおよび変更され得る。各認可は、コレクションセットのような特徴1408をリソース1410に関連付ける。
【0196】
ユーザーはユーザーグループに属し得る。ユーザーグループは、ユーザーのクラスを表示し得る。グループ中のすべてのユーザーは、同じ許可で認可される。ここで再び、ユーザーグループが一旦記載され得、そして次に、すべてのリソースアプリケーションによって用いられる。
【0197】
図15は、1つの実施形態についてのセキュリティモデルのコンポーネントおよびそれらの関係を示す。このモデルをセットアップするために、最初に、アプリケーション特異的実体のための名前識別子を規定するドメイン1502をセットアップすることが必要である。これは、アプリケーションを横切る二重の名前、例えば、Fiji:サーチを可能する。Ownerm1504は、次いで、管理者にユーザーIDおよびパスワードを定義する。次に、ユーザー1506が規定される。ユーザーID、パスワードおよびその他のユーザープロフィール情報が割り当てられる。このユーザーGUIDは、この定義の基礎にある。
【0198】
定義されたユーザーがグループの一部である場合、グループユーザーエンティティ1508は、ユーザーのクラスを表すグループ1510へユーザーを追加するために使用される。グループの定義は、一度定義され、あるいは多数のユーザーに割り当てられる許可が認可される際の管理を簡易化する。グループは序列という言葉によって定義され得る。親グループは、1つ以上の子グループを有し得る。子グループは、その親グループから許可を受ける。
【0199】
フィーチャー1512は、セパレート制御あるいは価格設定(例えば、ドキュメント引用、クリッピング)を要求し得るリソースアプリケーション機能として定義される。セキュリティモデルを介して、ユーザーは、特別のコンテンツあるいは機能へアクセスするフィーチャーの使用を許可され、あるいは拒否され得る。コンテンツリソース1514は、セパレート制御あるいは価格設定(例えば、Fijiニュース、Fiji事情)を要求するコンテンツの定義されたサブセットを表す。セキュリティモデルのために定義されたコモンリソースタイプは、DOCコレクションあるいはコレクションセットである。
【0200】
また、アクセスコントロールオブジェクト1516は、セキュリティモデル内において定義可能である。アクセスコントロールは、フィーチャー(例えば、サーチ)を介してのコンテンツリソース(例えば、ワールドニュース)へのアクセス許可を許可あるいは拒否する。そのようなアクセスコントロールは、グループあるいは個々に割り当てられ得る。
【0201】
申し込みが定義されたとき、ユーザー、グループユーザー、グループ、アクセスコントロール、フィーチャー、およびセキュリティモデルのリソース要素は、互いにリンクされる。
【0202】
(マルチティアー環境)
リソースアプリケーションは、ドキュメントを引き出すために特有のプロダクトを作成するために、ARサーバー300およびCCRDSサーバー400のコンポーネントを利用する。
【0203】
図5は、リソースアプリケーションおよびそのインフラストラクチャーを形成する、クライアントティアー、サーバーティアー、およびデータサーバーティアー構造のコンポーネントを示す。クライアント側を表すために1つのユーザーが使用されるが、多数の異なり分散されたクライアントユーザーインターフェースがシステムにアクセスする。クライアントユーザーインターフェースは、オンラインデリバリー環境によって提供されるウェブサーバーをアクセスする。オンラインデリバリー環境は、同様に適正なアプリケーションサーバーおよび特別のユーザーインターフェースに基づくプロトコルを提供する。検索が実行されるとき、共有されるサービスサーバー、ディレクトリサーバーおよびアプリケーションサーバーは、ドキュメントを引き出すためのデータベースへのアクセスを得るために、データティアーと情報交換する。
【0204】
(作成環境)
図7は、本発明に従うリソースアプリケーションのための作成環境を示す。プロセスは、希望プロダクトのフィーチャー、環境サイズ、期待サービスレベル、およびクラスタリングを定義する質問事項によって開始する。作成はまた、実行のための種々のロギング、デバッグ、およびビジネスレポートを含む。設計のスケーラビリティはキャパシティ計画と共に考慮される。管理変更、発行された管理、拡大、および議論フォーラムのためのプロシージャーと同様に、構築および作成のためのツールおよびプロシージャーが、プロセスの作成のために必要である。コンポーネントが作成されるとき、復帰(regression)をテストするユニットおよびストレステストの実行が必要である。また、警告、デリバリー、およびトレイル機能の管理のための種々のツールが作成において使用される。最後に、リソースアプリケーション作成プロセスは、オペレーションシステム、ウェブサーバー、アプリケーションサーバーおよびデータベースのアップグレイドをアドレスしなければならない。
【0205】
先行作成サービスおよびツールがともに使用され、モノタリングが種々のウェブサーバー、アプリケーションサーバー、共有されるサービス/ツールおよびデータベースサーバーのために使用される。加えて、作成プロセスは、共通コンテンツの保管場所のパーツである、オンラインビジネスサービス、ビジネスサービス、共通コンテンツサービスおよび出版コンポーネントを、必然的に求める。
【0206】
本発明は好ましい実施形態を参照して記載されたが、本発明の真意と範囲から逸脱することなく、様々な変更が形態および詳細においてなされ得ることは、当業者にとって認められ得る。
【図面の簡単な説明】
【0207】
【図1】図1は、従来技術の小売システムを示す、略ブロック図である。
【図2】図2は、本発明のシステムが、いかにして、共通のリソース(共有されたサービス)を使用する別個のアプリケーションを利用して、複数のデータ集合に対する共有されたアクセスに基づき、識別されたユーザーのサービスを提供するのかを示した、略ブロック図である。
【図3】図3は、電子的に格納されたドキュメントの大きな集合体を、維持および分配するためのシステムの概観を示す略ブロック図である。
【図4】図4は、ドキュメント問合せおよび検索アプリケーションのためのウェブ−ベースのアプリケーションフレームワーク、および共通のコンテンツレポジトリーソフトウェアシステムとのそのインターコネクションを示すブロック図である。
【図5】図5は、図4のシステムの、クライアント、サーバーおよびデータのトレイルを示す、模式図である。
【図6】図6は、本発明において使用されるドキュメントレコードおよび関連するメタデータレコードの模式図である。
【図7】図7は、リソースアプリケーションを構築するために使用される開発ツールを示す略ブロック図である。
【図8】図8は、ドキュメントの取り込みのためのプロセスを示すフローチャートダイアグラムである。
【図9】図9は、ドキュメントのエンリッチメントのプロセスおよびドキュメントのメタデータ処理を示すフローチャートダイアグラムである。
【図10】図10は、本発明のコンテンツ(TOC)アーキテクチャのテーブルを示す模式図である。
【図11】図11A〜Dは、本発明に従って構築されたコンテンツ構造のテーブルを示す模式図である。
【図12】図12は、本発明に従って構築されたコンテンツの例のテーブルを示す模式図である。
【図13】図13は、本発明において、セキュリティーサービスがどのようにして機能するのかを示す、略ブロック図である。
【図14】図14は、いかにしてセキュリティーが実行されるのか、ならびにユーザーグループおよび許可を示す、関係ダイアグラムである。
【図15】図15は、本発明のセキュリティーモデルについての、定義および関連ダイアグラムである。
【図16】図16は、いかにして、アラートサービスがクリッピングを提供するかを示す、模式図である。
【図17】図17は、いかにして、トレイルサービスが機能するのかを示す、模式図である。
【図18A】図18Aは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。
【図18B】図18Bは、いかにして、ドキュメントデリバリーサービスが機能するのかを示す、模式的関連ダイアグラムである。
【図19】図19は、いかにして、ドキュメントレンダリングが、最小のプレゼンテーションスタイルシートとともに機能するのかを示す、略ブロック図である。
【図20】図20は、いかにして、ドキュメントレンダリングが、あつらえのスタイルシートおよび複数のスタイルシートともに機能するのかを示す略ブロック図である。
【特許請求の範囲】
【請求項1】
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下:
a.ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合;
b.該少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント;
c.受け取ったドキュメントを処理して、該ドキュメントを富化するための、該取入れ口コンポーネントと関連したエンリッチメントコンポーネント;
d.データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント;
e.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント;ならびに、
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント、
を備える、システム。
【請求項2】
請求項1に記載のシステムであって、ここで、該システムはさらに、サーチコンポーネントが少なくとも1つのユーザー問合せメッセージを再処理しないその後のアクセスのための、検索された識別子を格納するための持続性のサービスを備える、システム。
【請求項3】
請求項1に記載のシステムであって、ここで、該システムはさらに、複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで該ノードの1つ以上が該1つ以上のノードと関連する1つ以上のドキュメントと同定する、システム。
【請求項4】
請求項3に記載のシステムであって、ここで、コンテンツサービスのテーブルが、コンテンツの2つ以上のテーブルをサポートし、ここで、コンテンツの各テーブルが特定のユーザーのタイプに適合する、システム。
【請求項5】
請求項3に記載のシステムであって、ここで、コンテンツの少なくとも1つのテーブルが、2つ以上のデータ集合を参照する、システム。
【請求項6】
請求項4に記載のシステムであって、ここで、コンテンツの2つ以上のテーブルの1つが、コンテンツの別の2つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
【請求項7】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
【請求項8】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る取入れ口コンポーネントは、各追加のドキュメントが特有の識別子を有しそして少なくとも1つの集合サブセットに割り当てられることを、確実にする、システム。
【請求項9】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合が、1つ以上の集合サブセット中のドキュメントの集合体である少なくとも1つのドキュメントのセットを有する、システム。
【請求項10】
請求項1に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
【請求項11】
請求項1に記載のシステムであって、ここで、エンリッチメントコンポーネントは、ドキュメントが以下:
a.ヒト作因によって準備される、さらなる編集材料;
b.自動化作因によって準備される、さらなる編集材料;
c.前記データ集合中の別のドキュメントに対するポインタを提供するリンク;
d.法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用;または、
e.メタデータファイル中に出現するドキュメントと関連するエントリ、
の少なくとも1つと関連を生じるように、該ドキュメントを処理する、システム。
【請求項12】
請求項1に記載のシステムであって、ここで、新規ドキュメントを受け取るための前記取入れ口コンポーネントが、前記受け取られたドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
【請求項13】
請求項1に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項14】
請求項1に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項15】
請求項1に記載のシステムであって、ここで、前記ドキュメントの集合体が、少なくとも20テラバイト情報を含む、システム。
【請求項16】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.該1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、1つ以上のメタデータ情報ファイル;ならびに
d.該1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、
を備える、システム。
【請求項17】
請求項16に記載のシステムであって、ここで、前記システムは、複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで、該ノードの1つ以上が、該1つ以上のノードと関連する1つ以上のドキュメントを同定する、システム。
【請求項18】
請求項17に記載のシステムであって、ここで、前記コンテンツサービスのテーブルが、コンテンツの2つ以上のテーブルをサポートし、ここで、コンテンツのテーブルの各々が、特定のユーザーのタイプに適合する、システム。
【請求項19】
請求項17に記載のシステムであって、ここで、前記コンテンツの少なくとも1つのテーブルが、2つ以上のデータ集合中にあるドキュメントを参照する、システム。
【請求項20】
請求項18に記載のシステムであって、ここで、コンテンツの2つ以上のテーブルの1つが、コンテンツの別の2つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
【請求項21】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
【請求項22】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る手段は、各追加のドキュメントが特有の識別子を有しそして少なくとも1つの集合サブセットに割り当てられることを、確実にする、システム。
【請求項23】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合が、1つ以上の集合サブセット中のドキュメントの集合体である少なくとも1つのドキュメントのセットを有する、システム。
【請求項24】
請求項16に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
【請求項25】
請求項16に記載のシステムであって、ここで、メタデータエクストラクタは、ドキュメントが以下:
a.ヒト作因によって準備される、さらなる編集材料;
b.自動化作因によって準備される、さらなる編集材料;
c.前記データ集合中の別のドキュメントに対するポインタを提供するリンク;
d.法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用;または、
e.メタデータファイル中に出現するドキュメントと関連するエントリ、
の少なくとも1つと関連を生じるように、該ドキュメントを処理する、システム。
【請求項26】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、前記ドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
【請求項27】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項28】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、任意のデータ集合において利用可能にする、システム。
【請求項29】
請求項16に記載のシステムであって、ここで、前記1つ以上のデータ集合が、少なくとも20テラバイト情報を含む、システム。
【請求項30】
問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法であって、該方法は、以下:
a.ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、コンピュータシステム上で実行するリソースアプリケーションに関連する、少なくとも1つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程;
b.応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程;
c.該問合せメッセージに対する応答において、該ユーザーに対して、1つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程;
d.該サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、少なくとも1つのユーザーインターフェースに関連する少なくとも1つのリソースアプリケーションに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程;ならびに、
e.該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、
を包含する、方法。
【請求項31】
問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、以下:
データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、コンピュータシステム上で実行するリソースアプリケーションに関連した少なくとも1つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネント;
該問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる、該問合せメッセージに備えるコードコンポーネント;
1つ以上のドキュメントを同定する、サーチ結果メッセージを提供するためのコードコンポーネント;ならびに
少なくとも1つのユーザーインターフェースと関連する少なくとも1つのリソースアプリケーションに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、ドキュメント選択データに応答するコードコンポーネント、
を備える、コンピュータデータシグナル。
【請求項32】
電子的に格納されたドキュメントの大きな集合体を維持し、そしてそのドキュメントを、問合せメッセージを出すユーザーに対して利用可能にするためのシステムであって、該システムは、以下:
a.ドキュメントを、電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは、特有の識別子を有する、データ集合;
b.該少なくとも1つのデータ集合に対して追加されるべき新規のドキュメントを受け取り、そして新規のドキュメントを、ドキュメントの上位n個の特有の逆ドキュメント頻度(idf)タームおよびドキュメント長さスカラを含む重複比較シグネチャと関連付けるための取入れ口コンポーネント;
c.該データ集合から情報を探す、少なくとも1つのユーザー問合せメッセージを受け取るためのユーザーインターフェース;
d.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント
e.該応答するドキュメントの重複比較シグネチャの中で比較を行って、そして比較シグネチャが正確に同一であるか、または予め決定された類似性の閾値内である場合に、重複を同定するための、重複検出コンポーネント;ならびに
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントを提示するためのデリバリーコンポーネント、
を備える、システム。
【請求項33】
請求項32に記載のシステムであって、ここで、重複比較シグネチャは、上位n個の特有のidfタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、そしてnが4から30である、システム。
【請求項34】
請求項32に記載のシステムであって、ここで、重複比較シグネチャは、トークンに基づく、上位n個の特有のidfタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、ここで、長さスカラに関して予め決定された類似性閾値が0から256の範囲である、システム。
【請求項35】
請求項32に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、重複検出コンポーネントは、サーバー側にあり、そして、クライアント側に対して、重複の同定を伝達する、システム。
【請求項36】
請求項32に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、クライアント側に対する重複の同定を用いて、ユーザーに伝達されたサーチ結果リストから該重複ドキュメントを取り除く、システム。
【請求項37】
請求項36に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含む、システム。
【請求項38】
請求項36に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含み、そして重複ドキュメントのセットが、ユーザーにとってアクセス可能にされる、システム。
【請求項39】
ユーザー問合せメッセージによって探される情報を小売するためのシステムであって、以下:
a.問合せメッセージを受け取るための1つ以上のユーザーインターフェースであって、該1つ以上のユーザーインターフェースは、システム上で実行するリソースアプリケーションに適合される、ユーザーインターフェース;
b.問合せメッセージに応答してユーザーにデリバリーするための、リソースアプリケーションのための目的のドキュメントを格納するための1つ以上のデータ集合;
c.1つ以上のデータ集合中に格納されたドキュメントについて、問合せメッセージによって開始するサーチを容易にするために、メタデータを保持するための1つ以上のメタデータ情報ファイル;
d.1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント;ならびに
e.問合せメッセージに応答した1つ以上のデータ集合に対するアクセスを制御し、そして、1つ以上のデータ集合に対するアクセスについてユーザーに課金するための情報を作成するための、2つ以上のリソースアプリケーションによって共有されるセキュリティサービスおよび課金サービス、
を備える、システム。
【請求項40】
請求項39に記載のシステムであって、ここで、前記1つ以上のデータ集合は、以下のタイプの情報:法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース、の1つ以上を含む、システム。
【請求項41】
請求項40に記載のシステムであって、ここで、該システムは、さらに、各々のタイプの情報について、複数のノードを有する少なくとも1つのコンテンツのテーブルを維持するためのコンテンツサービスのテーブルを含み、ここで、該ノードの1つ以上は、該1つ以上のノードに関連する1つ以上のドキュメントを同定し、そして、少なくとも1つのドキュメントは、1つよりも多いコンテンツのテーブルにおいて同定される、システム。
【請求項42】
ドキュメントを探す問合せメッセージを処理するためのシステムであって、以下:
a.問合せメッセージを受け取るための1つ以上のユーザーインターフェースであって、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに応答して、ユーザーに対してデリバリーするための、ドキュメントを格納するための、1つ以上のデータ集合;
c.該1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするための、メタデータを保持するための、1つ以上のメタデータ情報ファイル;ならびに、
d.該1つ以上のデータ集合に追加されるべきドキュメントを処理するための新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからリソース記述フレームワーク(RDF)ステートメントの形式のメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、新規ドキュメント取入れ口コンポーネント、
を備える、システム。
【請求項43】
請求項42に記載のシステムであって、さらに、該システムは、各タイプの情報についての複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するための、コンテンツサービスのテーブルを備え、そして前記メタデータエクストラクタの少なくとも1つは、RDFステートメントための語彙として、コンテンツの少なくとも1つのテーブルのノードのラベルを用いる、システム。
【請求項44】
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下:
a.ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合;
b.該少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント;
c.受け取ったドキュメント内において、少なくとも1つのPITフィールドの位置決めをするか、または配置するための、該取入れ口コンポーネントと関連したタイムスタンプコンポーネント;
d.データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント;
e.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネントであって、ここで、該処理および検索は、少なくとも1つのPITフィールドに応答して、問合せメッセージのPIT制限に対して応答するドキュメントのバージョンをデリバリーする、サーチコンポーネント;ならびに
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント。
【請求項45】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、時間と日付の情報を含む、システム。
【請求項46】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、バージョンの情報を含む、システム。
【請求項47】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、法律の異なるバージョンを識別する、システム。
【請求項48】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、1つ以上の試行ファイル;ならびに、
d.試行ファイルを処理して、特定のリソースアプリケーションについての共通の使用パターンを決定し、そして、そのような使用パターンとより一致する様式において、現在のサーチオプションおよびサーチ結果に対して、リソースアプリケーションのパラメータを、調節する、試行分析コンポーネント、
を備える、システム。
【請求項49】
請求項48に記載のシステムであって、ここで、共通の使用パターンは、ドキュメントがサーチ結果として表示される優先順位と比較して、ユーザーがサーチ結果において同定されたドキュメントをディスプレイする順序を含み、そして、調節されたパラメータは、ドキュメントがサーチ結果として表される優先順位に影響する、システム。
【請求項50】
請求項48に記載のシステムであって、ここで、共通の使用パターンは、サーチ結果において重複であるとして同定されたドキュメントのユーザーの再調査を含み、そして、調節されたパラメータは、重複する検出サービスについての、類似性閾値に影響する、システム。
【請求項51】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、1つ以上の試行ファイル;ならびに、
d.試行ファイルを処理して、共通の使用パターンを決定し、そして、そのような使用パターンに対するリソースアプリケーションに対して、アクセス可能であるメタデータファイルを構築する、試行分析コンポーネント、
を備える、システム。
【請求項1】
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下:
a.ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合;
b.該少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント;
c.受け取ったドキュメントを処理して、該ドキュメントを富化するための、該取入れ口コンポーネントと関連したエンリッチメントコンポーネント;
d.データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント;
e.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント;ならびに、
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント、
を備える、システム。
【請求項2】
請求項1に記載のシステムであって、ここで、該システムはさらに、サーチコンポーネントが少なくとも1つのユーザー問合せメッセージを再処理しないその後のアクセスのための、検索された識別子を格納するための持続性のサービスを備える、システム。
【請求項3】
請求項1に記載のシステムであって、ここで、該システムはさらに、複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで該ノードの1つ以上が該1つ以上のノードと関連する1つ以上のドキュメントと同定する、システム。
【請求項4】
請求項3に記載のシステムであって、ここで、コンテンツサービスのテーブルが、コンテンツの2つ以上のテーブルをサポートし、ここで、コンテンツの各テーブルが特定のユーザーのタイプに適合する、システム。
【請求項5】
請求項3に記載のシステムであって、ここで、コンテンツの少なくとも1つのテーブルが、2つ以上のデータ集合を参照する、システム。
【請求項6】
請求項4に記載のシステムであって、ここで、コンテンツの2つ以上のテーブルの1つが、コンテンツの別の2つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
【請求項7】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
【請求項8】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る取入れ口コンポーネントは、各追加のドキュメントが特有の識別子を有しそして少なくとも1つの集合サブセットに割り当てられることを、確実にする、システム。
【請求項9】
請求項1に記載のシステムであって、ここで、少なくとも1つのデータ集合が、1つ以上の集合サブセット中のドキュメントの集合体である少なくとも1つのドキュメントのセットを有する、システム。
【請求項10】
請求項1に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
【請求項11】
請求項1に記載のシステムであって、ここで、エンリッチメントコンポーネントは、ドキュメントが以下:
a.ヒト作因によって準備される、さらなる編集材料;
b.自動化作因によって準備される、さらなる編集材料;
c.前記データ集合中の別のドキュメントに対するポインタを提供するリンク;
d.法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用;または、
e.メタデータファイル中に出現するドキュメントと関連するエントリ、
の少なくとも1つと関連を生じるように、該ドキュメントを処理する、システム。
【請求項12】
請求項1に記載のシステムであって、ここで、新規ドキュメントを受け取るための前記取入れ口コンポーネントが、前記受け取られたドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
【請求項13】
請求項1に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項14】
請求項1に記載のシステムであって、ここで、新規のドキュメントを受け取るための前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項15】
請求項1に記載のシステムであって、ここで、前記ドキュメントの集合体が、少なくとも20テラバイト情報を含む、システム。
【請求項16】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.該1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするためのメタデータを保持するための、1つ以上のメタデータ情報ファイル;ならびに
d.該1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント、
を備える、システム。
【請求項17】
請求項16に記載のシステムであって、ここで、前記システムは、複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するためのコンテンツサービスのテーブルを備え、ここで、該ノードの1つ以上が、該1つ以上のノードと関連する1つ以上のドキュメントを同定する、システム。
【請求項18】
請求項17に記載のシステムであって、ここで、前記コンテンツサービスのテーブルが、コンテンツの2つ以上のテーブルをサポートし、ここで、コンテンツのテーブルの各々が、特定のユーザーのタイプに適合する、システム。
【請求項19】
請求項17に記載のシステムであって、ここで、前記コンテンツの少なくとも1つのテーブルが、2つ以上のデータ集合中にあるドキュメントを参照する、システム。
【請求項20】
請求項18に記載のシステムであって、ここで、コンテンツの2つ以上のテーブルの1つが、コンテンツの別の2つ以上のテーブルのノードを参照して、再帰的構造を規定する、システム。
【請求項21】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そして該システムは、該インデックス中のキーワードと該集合サブセット中の該キーワードの出現の位置との間の関連を有する、集合サブセット中に少なくとも1回出現するキーワードのインデックスを維持するインデックスサービスを有する、システム。
【請求項22】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合中のドキュメントが、少なくとも1つの集合サブセットに分割され、そしてここで、新規のドキュメントを受け取る手段は、各追加のドキュメントが特有の識別子を有しそして少なくとも1つの集合サブセットに割り当てられることを、確実にする、システム。
【請求項23】
請求項16に記載のシステムであって、ここで、少なくとも1つのデータ集合が、1つ以上の集合サブセット中のドキュメントの集合体である少なくとも1つのドキュメントのセットを有する、システム。
【請求項24】
請求項16に記載のシステムであって、ここで、該システムは、ユーザー識別情報および問合せメッセージを受け取り、そして、ユーザーの申し込み情報に対する該識別情報および問合せメッセージを確認する、セキュリティサービスコンポーネントをさらに備える、システム。
【請求項25】
請求項16に記載のシステムであって、ここで、メタデータエクストラクタは、ドキュメントが以下:
a.ヒト作因によって準備される、さらなる編集材料;
b.自動化作因によって準備される、さらなる編集材料;
c.前記データ集合中の別のドキュメントに対するポインタを提供するリンク;
d.法律ドキュメントまたは文献目録ドキュメントに対するメタデータに基づく、引用;または、
e.メタデータファイル中に出現するドキュメントと関連するエントリ、
の少なくとも1つと関連を生じるように、該ドキュメントを処理する、システム。
【請求項26】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、前記ドキュメントに優先順位をつけ、そして、通常の順序からはずれて、時間を感知できるインディケータを持つ受領ドキュメントの時間に基づき、処理する、システム。
【請求項27】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、割り当てられたドキュメントの識別子の特有さを確認し、その後に、そのようなドキュメント識別子を有する新規のドキュメントを、少なくとも1つのデータ集合において利用可能にする、システム。
【請求項28】
請求項16に記載のシステムであって、ここで、前記取入れ口コンポーネントが、予め決められた取入れ口形式について新規のドキュメントを確認し、その後に、そのような新規のドキュメントを、任意のデータ集合において利用可能にする、システム。
【請求項29】
請求項16に記載のシステムであって、ここで、前記1つ以上のデータ集合が、少なくとも20テラバイト情報を含む、システム。
【請求項30】
問合せメッセージを出すユーザーに対して、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントをデリバリーするための方法であって、該方法は、以下:
a.ユーザーから、データ集合中に電子的形式において格納されたドキュメントを探す電子的形式における問合せメッセージを引き出すために、コンピュータシステム上で実行するリソースアプリケーションに関連する、少なくとも1つのユーザーインターフェースに対するアクセスを提供する工程であって、ここで、各ドキュメントは、特有の識別子を有する、工程;
b.応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するための問合せメッセージを処理するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる問合せメッセージに備える工程;
c.該問合せメッセージに対する応答において、該ユーザーに対して、1つ以上のドキュメントを同定するサーチ結果メッセージを提供する工程;
d.該サーチ結果メッセージからドキュメントを選択するユーザーのメッセージに応答して、少なくとも1つのユーザーインターフェースに関連する少なくとも1つのリソースアプリケーションに基づいて、予め決められた形式において、該選択されたドキュメントを、デリバリーする工程;ならびに、
e.該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容する、工程、
を包含する、方法。
【請求項31】
問合せメッセージを出したユーザーに対する、問合せ結果、および電子的に格納されたドキュメントの大きな集合体から選択されたドキュメントのデリバリーを容易にするための、伝達媒体において具体化されたコンピュータデータシグナルであって、以下:
データ集合中に電子的形式において格納されたドキュメントを探す、電子的形式の問合せメッセージを、ユーザーから引き出すための、コンピュータシステム上で実行するリソースアプリケーションに関連した少なくとも1つのユーザーインターフェースを提示するためのコードコンポーネントであって、ここで、各ドキュメントは、特有の識別子を有する、コンポーネント;
該問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索するために、複数のリソースアプリケーションによって共有されるサーチコンポーネントに対してデリバリーされる、該問合せメッセージに備えるコードコンポーネント;
1つ以上のドキュメントを同定する、サーチ結果メッセージを提供するためのコードコンポーネント;ならびに
少なくとも1つのユーザーインターフェースと関連する少なくとも1つのリソースアプリケーションに基づいて、予め決定された形式において、ユーザーに対して選択されたドキュメントをデリバリーし、そして該選択されたドキュメントを、時点のアトリビュートと関連付けて、選択されたドキュメントのアップデートされたバージョンの選択を許容するために、ドキュメント選択データに応答するコードコンポーネント、
を備える、コンピュータデータシグナル。
【請求項32】
電子的に格納されたドキュメントの大きな集合体を維持し、そしてそのドキュメントを、問合せメッセージを出すユーザーに対して利用可能にするためのシステムであって、該システムは、以下:
a.ドキュメントを、電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは、特有の識別子を有する、データ集合;
b.該少なくとも1つのデータ集合に対して追加されるべき新規のドキュメントを受け取り、そして新規のドキュメントを、ドキュメントの上位n個の特有の逆ドキュメント頻度(idf)タームおよびドキュメント長さスカラを含む重複比較シグネチャと関連付けるための取入れ口コンポーネント;
c.該データ集合から情報を探す、少なくとも1つのユーザー問合せメッセージを受け取るためのユーザーインターフェース;
d.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネント
e.該応答するドキュメントの重複比較シグネチャの中で比較を行って、そして比較シグネチャが正確に同一であるか、または予め決定された類似性の閾値内である場合に、重複を同定するための、重複検出コンポーネント;ならびに
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントを提示するためのデリバリーコンポーネント、
を備える、システム。
【請求項33】
請求項32に記載のシステムであって、ここで、重複比較シグネチャは、上位n個の特有のidfタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、そしてnが4から30である、システム。
【請求項34】
請求項32に記載のシステムであって、ここで、重複比較シグネチャは、トークンに基づく、上位n個の特有のidfタームおよび前記ドキュメント中でのその相対的位置、およびドキュメント長スカラを含み、ここで、長さスカラに関して予め決定された類似性閾値が0から256の範囲である、システム。
【請求項35】
請求項32に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、重複検出コンポーネントは、サーバー側にあり、そして、クライアント側に対して、重複の同定を伝達する、システム。
【請求項36】
請求項32に記載のシステムであって、ここで、該システムは、クライアント−サーバー−アーキテクチャを利用し、そして、クライアント側に対する重複の同定を用いて、ユーザーに伝達されたサーチ結果リストから該重複ドキュメントを取り除く、システム。
【請求項37】
請求項36に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含む、システム。
【請求項38】
請求項36に記載のシステムであって、ここで、前記クライアント側において、ユーザーに伝達されたサーチ結果リストが、重複が見つけられたドキュメントの表示を含み、そして重複ドキュメントのセットが、ユーザーにとってアクセス可能にされる、システム。
【請求項39】
ユーザー問合せメッセージによって探される情報を小売するためのシステムであって、以下:
a.問合せメッセージを受け取るための1つ以上のユーザーインターフェースであって、該1つ以上のユーザーインターフェースは、システム上で実行するリソースアプリケーションに適合される、ユーザーインターフェース;
b.問合せメッセージに応答してユーザーにデリバリーするための、リソースアプリケーションのための目的のドキュメントを格納するための1つ以上のデータ集合;
c.1つ以上のデータ集合中に格納されたドキュメントについて、問合せメッセージによって開始するサーチを容易にするために、メタデータを保持するための1つ以上のメタデータ情報ファイル;
d.1つ以上のデータ集合に追加されるべきドキュメントを処理するための、新規ドキュメント取入れ口コンポーネントであって、該インターフェースは、新規ドキュメントからメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、取入れ口コンポーネント;ならびに
e.問合せメッセージに応答した1つ以上のデータ集合に対するアクセスを制御し、そして、1つ以上のデータ集合に対するアクセスについてユーザーに課金するための情報を作成するための、2つ以上のリソースアプリケーションによって共有されるセキュリティサービスおよび課金サービス、
を備える、システム。
【請求項40】
請求項39に記載のシステムであって、ここで、前記1つ以上のデータ集合は、以下のタイプの情報:法律、税金、会計、医療、科学、知的財産、教育課程の教材またはニュース、の1つ以上を含む、システム。
【請求項41】
請求項40に記載のシステムであって、ここで、該システムは、さらに、各々のタイプの情報について、複数のノードを有する少なくとも1つのコンテンツのテーブルを維持するためのコンテンツサービスのテーブルを含み、ここで、該ノードの1つ以上は、該1つ以上のノードに関連する1つ以上のドキュメントを同定し、そして、少なくとも1つのドキュメントは、1つよりも多いコンテンツのテーブルにおいて同定される、システム。
【請求項42】
ドキュメントを探す問合せメッセージを処理するためのシステムであって、以下:
a.問合せメッセージを受け取るための1つ以上のユーザーインターフェースであって、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに応答して、ユーザーに対してデリバリーするための、ドキュメントを格納するための、1つ以上のデータ集合;
c.該1つ以上のデータ集合中に格納されたドキュメントについてのサーチを容易にするための、メタデータを保持するための、1つ以上のメタデータ情報ファイル;ならびに、
d.該1つ以上のデータ集合に追加されるべきドキュメントを処理するための新規ドキュメント取入れ口コンポーネントであって、ここで、該インターフェースは、新規ドキュメントからリソース記述フレームワーク(RDF)ステートメントの形式のメタデータを作成し、そして、該1つ以上のデータ集合においてユーザーアクセスの用意ができているように、実質的に該新規ドキュメントを格納するのと同時に、該メタデータの少なくとも一部を該メタデータ情報ファイル中に格納する、メタデータエクストラクタを有する、新規ドキュメント取入れ口コンポーネント、
を備える、システム。
【請求項43】
請求項42に記載のシステムであって、さらに、該システムは、各タイプの情報についての複数のノードを有するコンテンツの少なくとも1つのテーブルを維持するための、コンテンツサービスのテーブルを備え、そして前記メタデータエクストラクタの少なくとも1つは、RDFステートメントための語彙として、コンテンツの少なくとも1つのテーブルのノードのラベルを用いる、システム。
【請求項44】
電子的に格納されたドキュメントの大きな集合体を維持し、そして問合せメッセージを出すユーザーに該ドキュメントを利用可能とするためのシステムであって、該システムは、以下:
a.ドキュメントを電子的形式において格納するための少なくとも1つのデータ集合であって、ここで、各ドキュメントは特有の識別子を有する、集合;
b.該少なくとも1つのデータ集合に対して追加される新規のドキュメントを受け取るための、取入れ口コンポーネント;
c.受け取ったドキュメント内において、少なくとも1つのPITフィールドの位置決めをするか、または配置するための、該取入れ口コンポーネントと関連したタイムスタンプコンポーネント;
d.データ集合からの情報を探す、少なくとも1つのユーザーの問合せメッセージを受け取るための、ユーザーインターフェースコンポーネント;
e.少なくとも1つのユーザー問合せメッセージを処理して、応答するデータ集合中のドキュメントを同定し、そして、応答するドキュメントについての識別子を検索する、サーチコンポーネントであって、ここで、該処理および検索は、少なくとも1つのPITフィールドに応答して、問合せメッセージのPIT制限に対して応答するドキュメントのバージョンをデリバリーする、サーチコンポーネント;ならびに
f.ユーザーのドキュメント要求に対して応答する、要求されたドキュメントのデリバリーのためのデリバリーコンポーネント。
【請求項45】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、時間と日付の情報を含む、システム。
【請求項46】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、バージョンの情報を含む、システム。
【請求項47】
請求項44に記載のシステムであって、ここで、前記少なくとも1つのPITフィールドは、法律の異なるバージョンを識別する、システム。
【請求項48】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、1つ以上の試行ファイル;ならびに、
d.試行ファイルを処理して、特定のリソースアプリケーションについての共通の使用パターンを決定し、そして、そのような使用パターンとより一致する様式において、現在のサーチオプションおよびサーチ結果に対して、リソースアプリケーションのパラメータを、調節する、試行分析コンポーネント、
を備える、システム。
【請求項49】
請求項48に記載のシステムであって、ここで、共通の使用パターンは、ドキュメントがサーチ結果として表示される優先順位と比較して、ユーザーがサーチ結果において同定されたドキュメントをディスプレイする順序を含み、そして、調節されたパラメータは、ドキュメントがサーチ結果として表される優先順位に影響する、システム。
【請求項50】
請求項48に記載のシステムであって、ここで、共通の使用パターンは、サーチ結果において重複であるとして同定されたドキュメントのユーザーの再調査を含み、そして、調節されたパラメータは、重複する検出サービスについての、類似性閾値に影響する、システム。
【請求項51】
ドキュメントを探す問合せメッセージを処理するシステムであって、該システムは、以下:
a.問合せメッセージを受け取るための、1つ以上のユーザーインターフェースであって、ここで、該1つ以上のユーザーインターフェースの各々は、システム上で実行するリソースアプリケーションに適合する、ユーザーインターフェース;
b.問合せメッセージに対する応答において、ユーザーに対するデリバリーのために、ドキュメントを格納するための1つ以上のデータ集合;
c.特定のリソースアプリケーション内の、ユーザーのサーチ処理についての情報、および、問合せメッセージに応答して見出されたドキュメントについての識別子についての情報を保持するための、1つ以上の試行ファイル;ならびに、
d.試行ファイルを処理して、共通の使用パターンを決定し、そして、そのような使用パターンに対するリソースアプリケーションに対して、アクセス可能であるメタデータファイルを構築する、試行分析コンポーネント、
を備える、システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18A】
【図18B】
【図19】
【図20】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18A】
【図18B】
【図19】
【図20】
【公表番号】特表2006−505863(P2006−505863A)
【公表日】平成18年2月16日(2006.2.16)
【国際特許分類】
【出願番号】特願2004−551574(P2004−551574)
【出願日】平成15年10月27日(2003.10.27)
【国際出願番号】PCT/US2003/033908
【国際公開番号】WO2004/044676
【国際公開日】平成16年5月27日(2004.5.27)
【出願人】(505006286)トムソン グローバル リソーシーズ アー.ゲー. (2)
【Fターム(参考)】
【公表日】平成18年2月16日(2006.2.16)
【国際特許分類】
【出願日】平成15年10月27日(2003.10.27)
【国際出願番号】PCT/US2003/033908
【国際公開番号】WO2004/044676
【国際公開日】平成16年5月27日(2004.5.27)
【出願人】(505006286)トムソン グローバル リソーシーズ アー.ゲー. (2)
【Fターム(参考)】
[ Back to top ]