JP2008541272A - 署名生成および関連性を有するマッチングエンジン - Google Patents

Abstract

システムおよび方法は、ドキュメントに関連した少なくとも１つの署名を生成する。一実施形態では、テキストから作成されたドキュメントが受信され、トークンセットを生成するために解析される。トークンセットは複数のトークンを含む。各トークンは、予め定められた文字特性によって生成されるドキュメント内のテキストに対応する。ドキュメント内のテキストの頻度と分布とに基づいてトークンセットの各トークンのためにスコアが計算される。そして、各トークンは計算されたスコアに基づいてランク付けされる。ランク付けされたトークンのサブセットが選択され、署名は、選択されたトークンの各発生のために生成される。署名の選択されたリストはその後出力される。
【選択図】図１

Description

本発明は、一般に、サーチエンジン技術の分野に関し、より詳細には、ドキュメント保存場所から関連するドキュメントのクエリを行う企業サーチエンジンの分野に関する。

本出願は、「テキストドキュメントの署名生成および関連性検出を持つ関連ドキュメントのクエリを行うためのマッチングエンジン」と題し、２００５年５月９日に出願された米国仮特許出願第６０／６７９，３１４号と、「署名生成を持つマッチングエンジン」と題し、２００６年２月２４日に出願された米国特許出願第１１／３６１，３４０号と、「関連のクエリを行うためのマッチングエンジン」と題し、２００６年２月２４日に出願された米国特許出願第１１／３６１，４４７号の優先権を主張する。これらの出願の内容は参照により本出願に組み込まれる。

一般に、企業サーチエンジンは、所定のクエリステートメントを持つ関連のあるドキュメントをサーチするソフトウェアシステムである。企業サーチエンジンは、典型的に、クローラ、インデックス付与部、サーチ部（サーチ手段）およびクエリエンジンからなる。クローラは、予め割り当てられた位置からドキュメントを集め、それらをドキュメント保存場所にダンピングする。インデックス付与部は、ドキュメント保存場所からドキュメントを取り出し、そのドキュメントからインデックスを作成し、インデックスデータベースにそのインデックスを格納する。サーチ部は、インデックスデータベースをサーチし、特定のクエリに応じて、関連のあるドキュメントのリスト（「ヒット」という）を戻す。クエリエンジンは、ユーザによって提供されるクエリ表現を解析し、処理のためにクエリコマンドをサーチ部に送信する。

従来のサーチエンジン技術は、多くのクエリ問題に対する関連のあるドキュメントをサーチするには不十分である。例えば、２つのドキュメントの関連性がある所定のパーセンテージ値、例えば、Ｘ％で測定されると想定される問題を考慮する。入力ドキュメントおよびパーセンテージ値Ｘ％が与えられ、この入力ドキュメントとあらゆる戻りのドキュメントとの間の関連性がＸ％より大きくなければならないように、ドキュメント保存場所からの関連のあるドキュメントのサーチは実施される。

従来のサーチエンジンの上述のクエリ問題への直接適用は、いくつかの不利益をもたらす。例えば、ドキュメント関連性の正確で有効な測定の欠如がある。さらに、従来のシステムは、ドキュメントの大きなリストを戻し、そのほとんどは関連がないかもしれない。したがって、検索（retrieval）の正確な割合は低い。ドキュメントの大きいリストを返すことは、すべての従来のサーチエンジン技術の共通の問題である。なぜならば、キーとなる語により提供されるクエリは、ユーザが検索を試みるドキュメントを正確に描写することができないからである。

多くの関連のないドキュメントを返すとは言え、従来のサーチエンジンの別の問題は、それらが言語に依存することである。各書き言葉のために、従来のサーチエンジンは、異なる言語の解析部および分析部を実装しなければならない。これは、リソースの多くの使用をもたらし、一般に効率的ではない。

まだ、従来のサーチエンジンの持つ別の問題は、しばしば正確であるか、または高いコンピューティングインセンティブであるモデルを通してドキュメントの関連性を測定することである。正確なリソースインセンティブのモデルのような例は、用語ベクトル空間モデル、確率的モデル、隠れている意味空間モデルなどを含む。

このため、高いとんどは、をもたらし、、関連性を有するドキュメントを返すために、クエリを効果的に実行する従来のサーチエンジンアーキテクチャを修正し、改良するシステムおよびその方法の必要性がある。

一実施形態では、サーチエンジンは、あるドキュメントに関連した署名の適用および使用を通して高い関連性を有するドキュメントを返すためのクエリを効率的に実行するよう構成されればよい。その署名は、キーワードのような他の機構と比較されるドキュメントのより良い特徴付けを可能にする。また、署名は、２つの関連のあるドキュメントがいくつかの共通の署名を持つべきであるように、関連のあるドキュメントを渡って安定である。共通の署名の数は、関連性の度合いに依存してもよい。さらに、署名は、２つの関連のないドキュメントが同一の署名を所有すべきでないように、ドキュメント間でユニーク（唯一）である。これらの要因は、サーチを実行するのによりロバストな環境および機構を提供する。

一実施形態では、システム（および方法）は、あるドキュメントに関連した少なくとも１つの署名を生成するよう構成される。システムは、テキストを含むドキュメントを受信する。そのドキュメントは、トークンセットを生成するために解析される。トークンセットは、２以上のトークンを含む。各トークンは、予め定められた文字特性により分けられるドキュメント内のテキストに対応する。予め定められた文字特性の例は、デリミタ、小文字、およびストップワードを含む。他の例では、予め定められた文字特性は、語の語幹解釈（ステミング）を通して識別されてもよい。

システムは、ドキュメント内のそのテキストの頻度および分布に基づいて、トークンセットにおける各トークンのためのスコアを計算する。計算されたスコアに基づいて、システムは、トークンセット内の各トークンをランク付けする。これらのランク付けされたトークンから、システムは、ランク付けされたトークンのサブセットを選択する。例えば、システムは、Ｎがランク付けされたトークンの総数未満のいずれかの整数であるとき、トップＮにランク付けされたトークンを選択するよう構成されてもよい。ランク付けされたトークンが選択されると、システムは、選択されたトークンの各発生のための署名を生成する。システムは、例えば、署名をソートし、最初のＭの署名を選択することにより（Ｍは、生成された署名の総数未満のいずれかの整数である）、生成された署名のサブセットを選択する。そして、その処理は、署名の生成されたリストを出力する。

署名システム（および方法）の別の実施形態は、ＵＴＦ−８（８ビットユニコード変換フォーマット）エンコードを使用するドキュメントを使用のための追加の適応性に提供する。一実施形態では、システム（および方法）は、あるドキュメントに関連した少なくとも１つの署名を生成するよう構成される。特に、システムは、２以上の文字を含むドキュメントを受信する。そのドキュメントは、２以上の文字から有益ではない文字を取り除くために標準化される。有益でない文字の例は、余分な空白または制御文字を含む。

システムは、そのドキュメントの発生頻度および分布に基づいて、複数の文字の各有益な文字のためのスコアを計算する。複数の文字の各有益な文字は、計算されたスコアに基づいてランク付けされる。このランク付け（ランキング）から、システムは、文字発生を選択し、各選択された文字発生のための署名を生成する。そして、１以上の生成された署名のリストは出力され得る。

前に言及したとおり、署名の生成は、多くの利益および利点を提供する。例えば、サーチエンジンのコンテキストでは、署名は、高い関連性を有するドキュメントを返すためのクエリを効果的に実行するよう影響力を及ぼされてもよい。以上のように、署名は、ドキュメントのより良い特徴を可能にする。さらに、署名は、２つの関連のあるドキュメントがいくつかの共通の署名を有するように、関連のあるドキュメントに渡って安定性を有する。共通の署名の数は、関連性の度合いに依存してもよい。さらに、署名は、２つの関連のないドキュメントが同じ署名を所有しないように、ドキュメント間でユニークである。２つの関連のあるドキュメント間の共通の署名により、サーチエンジンは、入力ドキュメントのための関連のあるドキュメントを返すことができる。入力ドキュメントのための署名のユニークさにより、ここで記述されるようなサーチエンジンは、関連のないドキュメントを返すよりもむしろ、高度に関連のあるドキュメントを返すことができる。

一実施形態では、サーチエンジンは、高い関連性を有するドキュメントを返すクエリを効果的に実行するよう構成されてもよい。本開示において構成される関連性検出エンジンは、ドキュメント関連性の予め定められた度合いに基づいて、所定のドキュメントと他のドキュメントのリストとの間の関連性（または類似性）を計算する。

別の実施形態では、システム（および方法）は、テキストを含む最初のドキュメントを受信するよう構成される。さらに、システムは、ドキュメントのリストを受信する。このリストもテキストを含む。ドキュメントのリストは、最初の（または所定の）ドキュメントに対するマッチングのために用いられる。また、システムは、パーセンテージに関して求められる関連性の度合いに対応する所定の値を受信してもよい。例えば、システムは、Ｘ％、例えば９５％の関連性以下のドキュメントが最終結果として除去されるように、少なくともＸ％、例えば９５％の関連性を有するドキュメントを要求してもよい。

システムは、最小部分文字列の適合長を受信し、ドキュメントのリストにおけるドキュメントのテキストを標準化する。一実施形態では、システムは、そのサーチを始める前に、最初のドキュメントのテキストをソートする。また、システムは、そのサーチを始める前に、最初のドキュメントのテキストの部分文字列のためのハッシュ値を生成してもよい。システムがサーチを初期化すると、システムは、最初のドキュメントのテキストとドキュメントのリストにおける各ドキュメントのテキストとの間の共通のサブストリングをサーチする。そして、システムは、サーチされた共通のサブストリングに基づいてマッチ（適合）パーセンテージを計算する。一実施形態では、システムは、相似関数に基づいてマッチパーセンテージを計算するよう構成される。そして、システムは、最初に定義された関連性の度合いに対応する所定の値に応じたマッチパーセンテージを有するドキュメントを出力する。

関連性検出エンジンは、有利に、パーセンテージ測定においてドキュメント関連性を決定するよう構成される。その構成は、ヒットに含まれる関連のないドキュメントがパーセンテージ閾値によって除外され得るよう構成される。これは、サーチエンジンの利用を増加させ、より大きい承諾を有する結果を提供する。

一実施形態では、関連性検出エンジンは、有利に、ドキュメントフィルタを提供するよう構成される。それは、ドキュメント関連性の定義に基づいて、所定のドキュメントと他のドキュメントのリストとの間の関連性（または類似性）を計算する。その関連性はパーセンテージとして与えられる。所定の閾値Ｘ％のために、関連性検出エンジンは、Ｘ％未満の関連性を有するリスト内のドキュメントを除外する。

明細書に記載される特徴および利点は、すべてを含むものではなく、特に、多くの追加の特徴および利点は、図面、明細書および特許請求の範囲に関して当業者にとって明白であろう。さらに、明細書でも用いられる言語が読みやすさと説明書の目的のために主として選択され、本発明の主題を描写するために選択されるものではないことを注意されたい。

開示の実施形態は、添付図面に関連してなされるとき、以下の詳細な記述および添付の特許請求の範囲から容易に明白である他の利点および特徴を有する。

以下、いくつかの実施形態を詳細に言及する。この例は添付図面に示される。実行性のある限り、同様の参照符号が図面では用いられ、それらが同様の機能性を示すことを注意されたい。図面は、単に例証の目的で本発明の実施形態を描写する。当業者は、以下の記述から、ここに示される構成および方法の代わりの実施形態がここに記述の原則から逸脱することなく使用され得ることを容易に認識するであろう。

一般に、開示の実施形態は、ドキュメントに関連した少なくとも１つの署名を生成するシステムおよび方法を記述する。その署名は、例えば、企業コンピューティングシステムにおいて、サーチクエリにとって適切な結果を得るために用いられる。一実施形態では、テキストからなるドキュメントは、トークンセットを生成するために受信され、解析される。トークンセットは複数のトークンを含む。各トークンは、予め定められた文字特性により分けられたドキュメント内のテキストに対応する。スコアは、そのドキュメント内のテキストの頻度および分布に基づいて、トークンセット内の各トークンのために計算される。そして、各トークンは、計算されたスコアに基づいてランク付けされる。ランク付けされたトークンのサブセットが選択され、署名は、選択されたトークンの各発生に対して生成される。そして、署名の選択されたリストは出力される。システムおよび処理をさらにここで説明する。

図１を参照して、図１は、サーチエンジン１００の従来のアーキテクチャの一実施形態を示す。従来のアーキテクチャ１００は、ドキュメント保存場所１１０に格納される１以上のドキュメント１０５（ａ〜ｎ）を含む。そして、それらのドキュメントは、サーチエンジン１２０によりインデックスを付され、インデックス付ドキュメント１２２は、インデックスデータベース１２４に格納される。

続いて、情報を探しているユーザ１５０は、サーチエンジン１２０内のドキュメント１２６をサーチするためにクエリ１３０を作る。サーチは、インデックスデータベース１２４内のインデックス付ドキュメント１２２に対して行われる。マッチがそのクエリに対応して見出されると、サーチエンジンは、ユーザ１５０に提供されるサーチ結果として関連のあるインデックス付ドキュメントを返す。

この処理は、従来の労働集約的サーチ作業における改良であるが、未だに制限を有する。インデックス付ドキュメントは、クエリのコンテキストに関して必ずしも適切ではないかもしれない。このため、プロフットボールリーグ（ＮＦＬ：National Football League）のスコアに関するドキュメントのサーチは、アメリカンフットボールリーグよりも英語のフットボール（サッカー）に関連した結果を返すかもしれない。

図２は、本発明におけるマッチングエンジンのアーキテクチャの一実施形態を示す。一実施形態では、１以上のドキュメントリソース２０５（ａ〜ｎ）は、ドキュメント保存場所２１０に集められる（あるいは保存される）。一般に、アーキテクチャは、そのドキュメントからトークンを前処理し、最も有益なトークンを選択し、その有益なトークンに基づいて、そのドキュメントに関連した署名を生成するよう構成される。また、アーキテクチャは、入力ドキュメントのコンテキストに関して生成された署名のユニークさを保証するよう構成される。さらに、アーキテクチャは、同じドキュメントの変化バージョンを渡って収集の安定性を確保しつつ収集される署名の数を限定するよう構成される。なお、一実施形態では、署名は、ある値、例えば、選択されたトークンに応じてＡＳＣＩＩ文字の特定の情報またはストリング（文字列）に対応するハッシュ表現である。

アーキテクチャに関する処理の一実施形態において、ドキュメント２０５が手動であるいはクローラの使用を通して収集されてもよいことをまず指摘する。例えば、クローラは、ドキュメントを収集するために、すべての割り当てられたドキュメントソースを訪問し、収集される各ドキュメントにユニークなドキュメント識別子（ＩＤ）を割り当て、その後ドキュメント保存場所２１０にユニークなドキュメントＩＤおよびドキュメントを配置するよう構成される。

次に、署名生成部２１５は、ドキュメント保存場所２１０内の特定のドキュメントから署名のリストを生成する。署名は、あるドキュメントを表すユニークな情報から作られるストリングまたは値である。この表示情報は、そのドキュメントにとってユニークであり、そのドキュメントが適度な変更を有するときも安定している。署名生成部２１５は、１以上の署名生成処理を格納するよう構成され得る。さらに、署名生成部２１５は、処理すべきドキュメントの種類に基づいて、格納された処理から１つを選択して実行するよう構成され得る。例えば、署名生成処理の一実施形態は、例えば、ＡＳＣＩＩコードの英語のドキュメントで使用するようになっていてもよい（構成されてもよい）。これについては図３でさらに説明する。また、その処理は、小文字、ストップワードおよびステミングを用いてもよい。例えば、ロマンス語やラテン語などの他の言語に適用することができる。署名生成処理の別の実施形態は、ユニコードによりサポートされるあらゆる言語のためにＵＴＦ−８（汎用変換フォーマット）エンコードのドキュメントで使用されるようになっている。これについては図４でさらに説明する。

署名生成部２１５が特定のドキュメントのための署名を生成すると、インデックス付与部２２２は、ユニークなドキュメント識別子（ＩＤ）と署名生成部２１５により生成された署名とをそのドキュメントにインデックスとして付す。その結果は、サーチエンジン２２０のインデックスデータベース２２４に格納されるインデックス付ドキュメント（インデックス付与部２２２による）である。

サーチエンジン２２０のインデックスデータベース２２４内のインデックス付ドキュメントでは、そのドキュメントは、クエリを発する用意ができている。ユーザ２５０は、署名生成部２１５により生成された署名に基づいてクエリ表現を作成するためにクエリライタ２３０を用いる。なお、ユーザ２５０により提供される入力ドキュメントがクエリ入力を提供する。ユーザ２５０は、署名が何であるかを知る必要がなく、むしろ、ユーザ２５０は、何が入力ドキュメントであるかのみを知る必要がある。ユーザ２５０は、その入力ドキュメントを署名生成部２１５に送る。署名生成部２１５から出力される署名は、クエリ構文のためにクエリライタ２３０に送られる。そして、構文のクエリは、ドキュメントをサーチするためにサーチ部２２６（サーチ（検索）機能）に送られる。

サーチエンジン２２０内のサーチ部２２６は、クエリライタ２３０を介して提供されるクエリを用いて、インデックスデータベース２２４をサーチする。サーチ部は、可能な関連のあるドキュメント２２６（「ヒット（hits）」）のリストを関連性検出エンジン２４０に返す。関連性検出エンジン２４０は、入力ドキュメントとヒットの間の関連性（例えば、パーセンテージの数値で）を計算する。関連性検出エンジン２４０は、関連性計算（または分析）のための１以上の処理を含むよう構成される。関連性決定処理の第１実施形態は図５に関してさらに説明される。関連性決定処理の第２実施形態は図６に関してさらに説明される。なお、関連性検出エンジン２４０は、これらの処理のいずれかを選択しあるいは実行することができる。例えば、小さいドキュメントのために、関連性決定処理の第１実施形態を配置することができ、例えば、サイズが１０ＭＢよりも大きいドキュメントのために、関連性決定処理の第２実施形態を配置することができる。

マッチングエンジンアーキテクチャは、有利に、ユニークな構成を提供する。例えば、クエリは、所定のドキュメントＤおよびパーセンテージＸ％のために、Ｄと（Ｄ１，．．．，Ｄｎ）のすべてとの関連性がＸ％よりも大きいように、ドキュメント保存場所からドキュメントのリスト（Ｄ１，・・・，Ｄｎ）をサーチするよう構成される。

＜署名生成＞
図３は、本発明における署名生成処理の第１実施形態を示す。本実施形態は、ＡＳＣＩＩコードでエンコードされた英語ドキュメントから署名を生成することを示す。その処理は、ドキュメントを入力することにより開始する（ステップ３０５）。その処理は、１以上のトークン（トークンリスト）の最初のリストを生成（作成）するために、そのドキュメントを解析する（ステップ３１０）。一実施形態では、トークンは、予め定められた文字特性により分けられたドキュメントのテキストを含む。予め定められた文字特性の例は、デリミタ（区切り文字）を含む。トークンが分けられると、ステミング、ストップワークまたは小文字の分析等の機能が適用可能である。

その処理は、トークンリストの各トークンを小文字化し続ける（ステップ３１５）。小文字化は、トークンの各文字を小文字の文字に変換する関数である（ステップ３１５）。また、その処理は、トークンリストの各トークンを語幹化する（ステップ３２０）。なお、単語ステミングは、ある単語からコア語根（core root）を識別し、あるいは抽出する処理である。続いて、その処理は、新しい第１のトークンリスト（Ｌ₁）策定するために、ストップワードリストをそのリストの各トークンに適用する（ステップ３２５）。ストップワードは、情報を持たないように考えられる単語である。ストップワードの例は、「the」、「are」、「do」、「am」などを含む。さらに、その処理は、ストップワードリストの各要素を語幹化する。

その処理は、第２のトークンリスト（Ｌ₂）を形成するために、新しい第１のトークンリスト（Ｌ₁）の各ユニークなトークンを選択する（または取り出す）（ステップ３３０）。第２のトークンリストＬ₂の各トークンのために、その処理は、第１のトークンリストＬ₁における発生位置をマークし（ステップ３３５）、以下のセットを生成する。
Ｌ₁＝（ｔ₁，ｔ₂，．．．，ｔ_n）
Ｌ₂＝（Ｔ₁，Ｔ₂，．．．，Ｔ_m）
ここで、発生の位置をマークするために、Ｔｉ〜＜Ｐ（ｉ，１），Ｐ（ｉ，２），．．．，Ｐ（ｉ，Ｓ_i）＞を示す（ｉ＝１，．．．，ｍであり、Ｓ₁＋Ｓ₂＋．．．＋Ｓ_m＝ｎである）。

そして、その処理は、第２のトークンリストＬ₂内の各トークンのランク付けスコアを計算（あるいは生成）する（ステップ３４０）。そのスコアは、以下のように決定されればよい。
スコア（Ｔ_j）＝｛Ｐ（ｊ，Ｓ_j）−Ｐ（ｊ，１）｝×Ｓ_j×重み付け（Ｔ_j）／Ｓｑｒｔ（Ｄ_j）
ここで、Ｄ_j＝｛Ｐ（ｊ，２）−Ｐ（ｊ，１）］²＋｛Ｐ（ｊ，３）−Ｐ（ｊ，２）｝²．．．＋｛Ｐ（Ｊ，Ｓ_j）−Ｐ（ｊ，Ｓ_j-1）｝²である。
さらに、スコア関数は、頻度および割り当てられた重み付けによってテキスト内のあるトークンの重要性を測定する。なお、重み付け（）は、予め定義された関数であればよい。一実施形態では、その値は「１」であるが、トークンが「−」、「＿」および「＠」のような特別な文字を含むならば、代わりの実施形態では、予め割り当てられたある数字、例えば、６．８であってもよい。スコア関数は、Ｓ_j×重み付け（Ｔ_j）により決定されればよい。スコア関数は、より良いスコアを得るために、ドキュメント全体にトークンを均等に分配するために用いられてもよい。これは、｛Ｐ（ｊ，Ｓ_j）−Ｐ（ｊ，１）｝／Ｓｑｒｔ（Ｄ_j）により決定される。

次に、その処理は、計算されたスコアにより第２のトークンリストＬ₂をソートし（ステップ３４５）、そのリスト（Ｌ₂）からスコアによるトップＮトークンを選択する（あるいは取り出す）（ステップ３５０）。なお、「Ｎ」はいずれかの整数であればよく、システム内に予め定められてもよく、あるいはシステムへの入力として選択されてもよい。第２のトークンリストＬ₂からのスコアによるトップＮトークンは、第３のトークンリストＬ₃を作成する。第３のトークンリストＬ₃の各トークンＴ_jのために、Ｌ₁におけるその発生および隣接したトークンから署名を生成する（ステップ３５５）。また、この処理は、以下のように表示され得る。
各ｋε｛Ｐ（ｊ，１），Ｐ（ｊ，２），．．．．，Ｐ（ｊ，Ｓ_i）｝のために、Ｌ₁における隣接した２番目のトークンを取り出し、ｔ_k-d＋．．．＋ｔ_k-1＋ｔ_k＋ｔ_k+1＋．．．＋ｔ_k+dのストリングを形成するために、それらを鎖状につなぐ。
このストリングのエンコードは、署名Ｆ_j,kを我々に与える。

第３のトークンリストＬ₃の各Ｔ_jのために、その処理は、リスト（Ｆ_j,1，Ｆ_j,2，．．．Ｆ_j,Sj）をソートし、このソートされたリストからトップＭの署名を選択する（ステップ３６０）。なお、「Ｍ」はいずれかの整数であればよく、システム内に予め定められてもよく、あるいはシステムへの入力として選択されてもよい。次に、第３のトークンリストＬ₃のすべての要素のために、合計（Ｎ×Ｍ）あり、選択された署名は、集められ（あるいは収集され）る（ステップ３６５）。そして、その処理は、署名のコレクションを出力する（ステップ３７０）。

図４は、本発明における署名生成処理の第２実施形態を示す。第２実施形態は、例えば、明確なＵＴＦ−８フォーマット（汎用変換フォーマット）におけるあらゆる言語のテキストドキュメントと、有益であると考えられるＵＴＦ−８アルファベットの文字のリストを入力する処理（ステップ４０５）とを含む。さらに、他の入力は、トップにランクするスコアを持つ多くの文字に対応するある数Ｍと、各文字の最大署名数に対応するある数Ｎとを含んでもよい。他の任意の入力は、予め定められた値、例えば３０を有することができる整数定数ＣＨＡＲ＿ＮＥＩＧＨＢＯＲを含んでもよい。この整数定数は、テキストストリングにおける文字の隣のもののサイズを定義する。それは、署名を生成するために用いられる。他の入力は選択割合Ｒである。それは０と１の間の予め定められた範囲、例えば０．２０を有する。選択割合は、あるセットからサブセットを選択するのに使用する数である。さらに他の入力は空の署名リストＳであってもよい。

その処理は、有益でない文字を取り除くためにドキュメントをスキャンすることにより、そのドキュメントを標準化する（ステップ４１０）。有益でない文字は、テキストコンテキストに貢献しないＵＴＦ−８文字である。それらは、書式設定（フォーマッティング）などの他の目的を提供してもよい。例えば、ストリングがｎ個の連続するスペースを有するならば、ｎ−１個のスペースは有益でないと考えられる。有益でない文字の他の例は、制御（ＣＴＲＬ）文字及びリターンを含む。

そして、その処理は、ＵＴＦ−８アルファベット内の各文字ｃの発生を記録するために、標準化されたドキュメントをスキャンする（ステップ４１５）。発生の位置は、Ｐ（１，ｃ），Ｐ（２，ｃ），．．．，Ｐ（ｎ，ｃ）として示される。その処理は、以下を用いて文字ｃのためのランク付きのスコアを計算（あるいは生成）する。
スコア（ｃ）＝Ｓｑｒｔ（ｎ）×｛Ｐ（ｎ，ｃ）−Ｐ（１，ｃ）｝／Ｓｑｒｔ（Ｄ）
ここで、Ｄ＝｛Ｐ（２，ｃ）−Ｐ（１，ｃ）｝²＋｛Ｐ（３，ｃ）−Ｐ（２，ｃ）｝²＋．．．＋｛Ｐ（ｎ，ｃ）−Ｐ（ｎ−１，ｃ）｝²である。スコア関数は、その頻度によってテキスト内の文字の重要性を測定する。また、スコア関数は、ドキュメント全体に均等に分布した文字がより良いスコアを得ることを確実にする。これを達成する計算は、以下を含む。
｛Ｐ（ｎ，ｃ）−Ｐ（１，ｃ）｝／Ｓｑｒｔ（Ｄ）

その処理は、スコアによる文字アルファベットをソートし続け（ステップ４２０）、トップスコアを持つＭ文字を選択する（あるいは取り出す）（ステップ４２５）。この生成されたリストは、文字リストＬとして示される。なお、「Ｍ」は、いずれかの整数であればよく、システム内に予め定められてもよく、前述のように、システムへの入力として選択されてもよい。

文字リストＬの各文字ｃのために、文字ｃの各発生ｐにおいて、その処理は、その隣接するものを計算する。特に、その処理値は、その左右の文字を取り、すべてのエンコードバイトをともに連結することにより、整数ｖを形成する。この隣接値ｖおよび発生ｐは、ペア（ｖ，ｐ）を作る。次に、その処理は、１の値を変数ｊに割り当てる。変数ｊは、リストＬの列挙である。ｊを用いて、Ｌの要素は１つずつ処理されればよい。図示の処理では、この構造は、「各（each）」の概念を実現するために用いられ、インクリメントに増加される。順々に、これは、文字リストＬ内の各文字ｃのペアのリストＬ₁（ｃ）を形成する（ステップ４４０ａ）。リストＬ₁（ｃ）のサイズは、Ｎ（ｃ）として示されてもよい。各リストＬ₁（ｃ）のために、その処理は、トリプレット（ｍ，ｖ，ｐ）を持つ第２のリストＬ₂（ｃ）を形成するために（ステップ４４５）、そのリスト内の各隣接値ｖの繰り返しｍをカウントする。また、第２のリストＬ₂（ｃ）のサイズは、Ｎ（ｃ）として示されてもよい。各リストＬ₂（ｃ）は、（ｍ，ｖ）によってソートされる（ステップ４５０）。ここで、「ｍ」は第１の比較パラメータであり、「ｖ」は第２の比較パラメータである。

その処理は、ソートされた第２のリストＬ₂（ｃ）からトップのＫ（ｃ）トリプレットを選択する（あるいは取り出す）（ステップ４５５）。ここで、Ｋ（ｃ）≦Ｒ×Ｎ（ｃ）である。これは、第３のリストＬ₃（ｃ）を形成する。第３のリストＬ₃（ｃ）の各トリプレット（ｍ，ｖ，ｐ）のために、その処理は、発生位置ｐを囲む隣接文字を持つハッシュ値を生成するハッシュ関数ｈａｓｈ（ｐ）によりそのハッシュ値を計算する（ステップ４６０）。適用可能なハッシュ関数の例は、従来のラビン−カープ（Karp-Rabin）ハッシュ関数であればよい。隣接文字の数は、ＣＨＡＲ＿ＮＥＩＧＨＢＯＲにより決定される。その処理は、ハッシュ値により第３のリストＬ₃（ｃ）をソートし（ステップ４６５）、第４のリストＬ₄（ｃ）を形成するために、ソートされたリストＬ₃（ｃ）のトップからＮトリプレットまでを選択する（取り上げる）（ステップ４７０）。なお、「Ｎ」はいずれかの整数であればよく、システム内に予め定められてもよく、あるいは上述のようにシステムへの入力として選択されてもよい。Ｌ₄（ｃ）の各トリプレット（ｍ，ｖ，ｐ）のために、その処理は、発生位置ｐを囲む文字を用いて署名を生成し、それを署名リストＳに追加する（ステップ４７５）。そして、その処理は、署名リストＳを出力する（ステップ４８５）。なお、上述の処理は繰り返しであり、そのため、リストＬ内のすべての文字ｃのために繰り返される。

署名生成部は、有利に、クエリを作成するときキーワードの役割を取り替えるユニークな構成である。署名生成部は、ヒットのサイズを低減するため、有効である。これは、マッチングエンジンのパフォーマンスを向上する。さらに、署名生成部は、マッチングエンジンのサーチの正確な割合を改善する。また、署名生成部は、言語に依存せず、したがって、サーチに利用可能なドキュメントの範囲を拡大するよう構成され得る。

概して、署名は、従来のキーワードよりも有益な方法で、サーチエンジン内の特定の役割を果たす。署名は、キーワードよりもドキュメントを特徴付けあるいは表すここに記述のような方法で、ドキュメントから抽出される。このため、それらは、キーワードよりもドキュメントに関連する。署名がキーワードとは異なることに注意されたい。ここでは、署名はドキュメントに強く関連するが、キーワードは必ずしもそうではない。２つの関連のないドキュメントは、あらゆる署名を共有しないが、それらは同じ一つのキーワードを所有することができ、署名は、キーワードよりも良いサーチの正確な割合を達成する。

＜関連性検出＞
また、本発明におけるシステムは、関連性検出の機会を含んでもよい。関連性検出に対して、各ドキュメントは、アルファベットの文字（ＡＳＣＩＩ、ユニコードなど）のストリングとして考慮され得る。したがって、２つのドキュメントの関連性は、２つのストリングの類似性に強く関連する。２つのストリングの類似性を定義するための従来のアプローチがある。１つのアプローチは、２つのストリングの最も大きい共通の部分列を得ることである。第２のアプローチは、２つのストリングの最も大きい共通の部分文字列を抽出することである。しかしながら、これらのアプローチの両方は、しばしばその使用を不十分にする制限を有する。最も大きい共通のストリングのアプローチは、他の類似の共通の部分文字列を含まず、そのため、正確ではない。最も大きい共通の部分列のアプローチは、コンテンツ交換（スワッピング）を取り扱うことができず、そのため、また不正確である。

本発明において、第３のアプローチは、ストリングの類似性から始まる。例えば、２つのストリングｓｔｒ１およびｓｔｒ２と、２番目のストリングｓｔｒ２の部分文字列のリストＳとを考慮する。このリストは、Ｓ内のすべての要素が重なり合わず、Ｓの各要素の長さが最小値Ｍより大きく、Ｓの各要素がｓｔｒ１の部分文字列でもあるという条件を満足する。なお、「Ｍ」は、いずれかの整数であれば良く、システム内に予め定められてもよく、あるいはシステムへの入力として選択されてもよい。

上記３つの条件を満足する部分文字列のすべてのセットのために、Ｓは、すべての部分文字列の長さ極大合計を得る。関数ＳＩＭは、ｓｔｒ１に対するｓｔｒ２の類似性を測定するために適用される。その関数は、以下のように定義されればよい。

ＳＩＭ（ｓｔｒ２，ｓｔｒ１）＝（Ｓのすべての部分文字列の長さの合計）／（ｓｔｒ２の長さ）×１００％
関数ＳＩＭが対称ではない、すなわち、ＳＩＭ（ｓｔｒ１，ｓｔｒ２）≠ＳＩＭ（ｓｔｒ２，ｓｔｒ１）であることを知らせる。例えば、ｓｔｒ１＝「ＡＡＡＡＡＣＣＣＣＣＣＣＣＢＢＢＢＢＢＤＤＤＤＤＤＡＡＡＡＡＡＬＬＬＬＬＬＬ」およびｓｔｒ２＝「ＣＣＣＣＣＣＣＣＣＺＺＺＺＺＡＡＡＡＡＡＡＢＢＢＢＴＴＴＴＬＬＬ」を考慮する。部分文字列の長さの要求される最小値は、例えば、Ｍ＝４として設定されればよい。そして、Ｓ＝（「ＡＡＡＡＡＡ」，「ＣＣＣＣＣＣＣＣ」，「ＢＢＢＢ」）であり、ｓｔｒ２の部分文字列は、類似性を計算する必要があるものである。
ＳＩＭ（ｓｔｒ２,ｓｔｒ１）＝１８／２７＝６７％

上記の例は、各コピーの最小サイズ要求で、ｓｔｒ１からｓｔｒ２にコピーされる部分文字列によって実際に定義される２つのストリングの類似性の一実施形態を示す。テキストドキュメントには、ドキュメントコンテキストに必ずしも貢献しない多くの文字がある。例えば、余分な空白や不可視文字は全く有益ではない。このため、これらの役に立たない文字は、関数ＳＩＭを適用する前に、ドキュメントから最初に取り除かれる。この処理は「ストリング標準化」といってもよい。例えば、ストリング「この文にはいくつかの役に立たない文字がある！（There are some useless characters in this sentence !）」は、「There are some useless characters in this sentence!」として標準化され得る。この例では、不必要な（あるいは役に立たない）元の文の単語の間の空白および標準化後の単語の間のただ１つの空白がある。

上記に加え、明白なＡＳＣＩＩまたはＵＴＦ−８フォーマットの２つのテキストドキュメントｄｏｃ１およびｄｏｃ２を与える以下の例を考慮する。まず、ドキュメントｄｏｃ１は、ストリングｓｔｒ１になるように標準化され、ドキュメントｄｏｃ２は、ストリングｓｔｒ２になるように標準化される。ｄｏｃ１に対するｄｏｃ２の関連性は、ＳＩＭ（ｓｔｒ２，ｓｔｒ１）により定義される。それは、ＲＬＶＮ（ｄｏｃ２，ｄｏｃ１）として示され得る。関数ＲＬＶＮはこの例では対称ではない。

次に、ストリング接尾辞を考慮する。ｎ＋１文字のあるストリングＸ＝ｘ₀ｘ₁．．．ｘ_nが与えられる。ここで、最初のｎ文字は、実際のストリングを含み、ｘ_n＝＄は、ＡＳＣＩＩまたはＵＴＦ−８テーブルに定義されないユニークなセンチネル文字で、位置ｉ（ここで、ｉ＝０，１，．．．，ｎ）で始まるＸの接尾辞である。この例では、Ｓ（Ｘ，０）＝ＸおよびＳ（Ｘ，ｎ）＝＄であり、ストリングＸはｎ＋１個の接尾辞（または接尾辞ストリング）を有する。さらに、接尾辞ストリングはソートされる。ストリングＸはｎ＋１個の接尾辞ストリングを有する。これらは、あらゆる手段により辞書編集上ソートされ得る。接尾辞のソートは、当業者に公知の従来のアルゴリズム問題である。

上記概要を考慮に入れて、ここで図５を参照する。図５は、本発明における関連性決定処理の第１実施形態を示す。その処理は、１以上の追加のドキュメントと、整数Ｍと、最初のドキュメント（例えば、「ｄｏｃ」という）との入力で始まる（ステップ５０５）。例として、ここでは、追加のドキュメントのリストは、マッチされるべきテキストドキュメントのリストであればよい。追加のドキュメントは、ｄｏｃ_m（またはｄｏｃ＿ｍ）を通してｄｏｃ₁（またはｄｏｃ＿１）といってもよい。ここで、「ｍ」は追加のドキュメントの数であり、「Ｍ」は最小部分文字列の適合長に対応する整数である。なお、「Ｍ」は、いずれかの整数であればよく、システム内に予め定められてもよく、あるいは、前述のようなシステムへの入力として選択されてもよい。

その処理は、ストリングｓｔｒと、ｓｔｒ₁（またはｓｔｒ＿１）からｓｔｒ_m（またはｓｔｒ＿ｍ）とを得るために、すべてのドキュメント、最初のｄｏｃと、追加のｄｏｃ₁からｄｏｃ_nとを標準化する（ステップ５１０）。従来の接尾辞ソートアルゴリズムを使用して、その処理は、接尾辞ストリング位置を記録するために、アレイＩＤＸを持つｓｔｒの接尾辞をソートする（ステップ５１５）。なお、アレイＩＤＸは従来の接尾辞ソートアルゴリズムにおいて公知である。そして、その処理は、割り当てるべき変数ｋ、例えば、ｋ＝１を割り当てる値を割り当て（あるいは許す）（ステップ５２０）。また、それは、ストリングｓｔｒの長さに変数Ｌを、ｓｔｒ_kの長さに変数Ｌ_kを、変数Ｐ＝０、およびＳＩＭ_k＝０を割り当て（あるいは許す）（ステップ５２５）。

次に、その処理は、ストリングｓｔｒおよびＳ（ｓｔｒ_k，Ｐ）の最大マッチング長さをサーチする（ステップ５３５）。特に、その処理は、変数Ｖ＝ＳｅａｒｃｈＭａｘＭａｔｃｈＬｅｎ（ＩＤＸ，０，Ｌ，ｓｔｒ，Ｌ，Ｓ（ｓｔｒ_k，Ｐ），Ｌ_k−Ｐ）を割り当てる（許す）。ここで、ＳｅａｒｃｈＭａｘＭａｔｃｈＬｅｎ（）は、以下にさらに定義されるように、ストリングｓｔｒおよびＳ（ｓｔｒ_k，Ｐ）の最大マッチング長さを計算するための帰納的関数である。
int searchMaxMatchLen (intIDX, int start, int end, char *str, int len,
char *str2, int len2) {
int i, j;

if(end-start < 2) {
i = getMaxMatchSize(str+IDX[start], len -IDX[start], str2, len2);
j = getMaxMatchSize(str+IDX[end], len -IDX[end], str2, len2);
if(i >j)
return i;
else
return j; }
i = start+(end-start)/2;
if(strncmp(str+IDX[i], str2, minimum(len-IDX[i], len2)) < 0)
return searchMaxMatchLen (IDX, i, end, str, len, str2, len2);
else
return searchMaxMatchLen (IDX, i, start, str, len, str2, len2); }

int getMaxMatchSize(char *str, int len, char *str2, int len2) {
int i;
for(i = 0; (i < len) && (i < len2); i++)
if(str[i] != str2[i]) break;
return i; }

上記は、別のストリングｓｔｒ２を持つ最も長い共通の接頭辞の部分文字列を共有する（ストリングｓｔｒの）接尾辞ストリングをサーチするための関数ｓｅａｒｃｈＭａｘＭａｒｔｃｈＬｅｎの例を示す。この関数は、二分サーチにより実行される。関数ｇｅｔＭａｘＭａｔｃｈＳｉｚｅは、２つのストリングの間の最も長い共通の接頭辞を得るためのものである。次に、その処理は、Ｖ≧Ｍを決定し（ステップ５４０）、ＳＩＭ_k＝ＳＩＭ_k＋Ｖ／Ｌ_k、Ｐ＝Ｐ＋Ｖを割り当てる（ステップ５５０）。その他、条件Ｖ≧Ｍが満たされないとその処理が決定するならば、その処理は、Ｐ＝Ｐ＋１のように変数Ｐをインクリメントする（ステップ５４５）。そして、その処理がＰ＜Ｌ_kであると決定するならば、その処理は、ストリングｓｔｒおよびＳ（ｓｔｒ_k，Ｐ）の最大マッチング長さをサーチするステップ５３５に戻る。

条件Ｐ＜Ｌ_kが満たされないとその処理が決定するならば（ステップ５４５）、その処理は、ｋ＜ｍを決定する（ステップ５６０）。ｋ＜ｍならば、その処理は、ｋ＝ｋ＋１によりｋをインクリメントする（ステップ５３０）。そして、その処理は、ストリングｓｔｒの長さに変数Ｌを、ｓｔｒ_kの長さに変数Ｌ_kを、変数Ｐ＝０およびＳＩＭ_k＝０を割り当てるステップ５２５に戻る。条件ｋ＜ｍが満たされないとその処理が決定するならば（ステップ５６０）、その処理は、ＳＩＭ₁，．．．，ＳＩＭ_mの結果を出力する（ステップ５６５）。

その出力は、有利に、入力ドキュメントと追加のドキュメントのリストとの間のパーセンテージによる類似性を提供する。例えば、上述のように、格納されたインデックスドキュメントデータベース内のドキュメントを見付けるために、Ｘ％と入力ドキュメントとが与えられる。その処理は、有利に、署名生成部により入力ドキュメントの署名を生成する。サーチ部は、その署名を用いてインデックスデータベースをサーチし、ドキュメントのリスト（ヒット）を返す。それぞれは、少なくとも１つの共通の署名を入力ドキュメントに分配する。関連性決定処理は、入力ドキュメントとそのリスト内の各ドキュメントとの間の類似性を計算する。これらは、ＳＩＭ_i，．．．，ＳＩＭ_mとして出力される。ここで、その処理は、ＳＩＭ_k≧Ｘ％を満足するドキュメントを選択することができる。また、このロジックは、マッチングエンジンアーキテクチャを通して暗示される。

図６において、本発明における関連性決定処理の第２実施形態を示す。その処理は、「ｄｏｃ」という最初のテキストドキュメント、そのｄｏｃにマッチすべきテキストドキュメントのリスト、および整数Ｍの入力で始まる（ステップ６０５）。テキストドキュメントのリストはｄｏｃ₁，．．．，ｄｏｃ_mという。ここで、「ｍ」はテキストドキュメントの数であり、「Ｍ」は最小部分文字列の適合長である。なお、「Ｍ」はいずれかの整数であればよく、システム内に予め定められてもよく、あるいは、前述のようにシステムへの入力として選択されてもよい。

その処理は、ストリングｓｔｒ、ｓｔｒ₁，．．．，ｓｔｒ_mを生成する（または作り出す）ために、ｄｏｃ₁，．．．，ｄｏｃ_mを標準化する（ステップ６１０）。次に、その処理は、ストリングｓｔｒのサイズより大きいＬという素数Ｑを割り当てる（ステップ６１５）。例として、Ｑ＝３×Ｌ／２である本実施形態を説明する目的を想定する。その処理は、サイズＱを持つアレイＨをハッシュ値の衝突を解決する能力を変更するハッシュテーブルに配分する。所定の変数のために、ｊ＝０からＬ−Ｍであり、その処理は、ハッシュ値ｈ＝ＨＴ＿ＦＵＮ（ｓｔｒ，ｊ，Ｍ）を生成し（ステップ６２０）、Ｈ［ｈ］におけるストリング位置を格納する。その代わりに、それは、衝突チェーンリンクリストにそれを格納してもよい。ハッシュ関数ＨＴ＿ＦＵＮは、ストリングｓｔｒの部分文字列のハッシュ値を計算するものであり、位置ｊおよび長さＭで始まる。一実施形態では、従来のラビン−カープハッシュ関数が適用されればよい。

次に、変数ｋは、ある値例えばｋ＝１を割り当てられる（ステップ６２５）。また、値は、Ｌ_kにストリングｓｔｒ_kの長さを、Ｐ＝０およびＳＩＭ_k＝０を割り当てられる（ステップ６３０）。その処理は、ｈ＝ＨＴ＿ＦＵＮ（ｓｔｒ_k，Ｐ，Ｍ）のようにハッシュ値を計算する（ステップ６４０）。その処理は、ハッシュテーブル入力Ｈ［ｈ］を調べ、Ｈ［ｈ］が空であるか否かを決定する（ステップ６４５）。Ｈ［ｈ］が空でないならば、Ｈ［ｈ］におけるチェーンリンクリストの各ストリング位置のために、その処理は、２つの部分文字列の最大マッチング長さを得るために、変数Ｖ（ｓ）＝ｇｅｔＭａｘＭａｔｃｈＳｉｚｅ（ｓｔｒ＋ｓ，Ｌ−ｓ，ｓｔｒ_k＋Ｐ，Ｌ_k−Ｐ）を割り当てる（ステップ６５０）。そして、その処理は、Ｖ＝ｍａｘｉｍｕｍ（Ｖ（ｓ））を割り当てる。変数Ｖは、Ｓ（ｓｔｒ_k，Ｐ）の最も大きい接頭辞ストリングの長さを表す。また、この接頭辞は、ストリングｓｔｒの部分文字列である。

その処理がＶ≧Ｍと決定するならば（ステップ６６０）、それは、ＳＩＭ_k＝ＳＩＭ_k＋Ｖ／Ｌ_kおよびＰ＝Ｐ＋Ｖを割り当てる（ステップ６７０）。それがＶ＜Ｍであると決定するならば（ステップ６６０）、それは、Ｐ＝Ｐ＋１を割り当てる（ステップ６６５）。同様に、その処理がＨ［ｈ］は空であると決定したならば、Ｐ＝Ｐ＋１を割り当てるだろう（ステップ６６５）。その処理のこれらの後者の態様のいずれかでは、次のステップは、Ｐ＜Ｌ_k−Ｍを決定することである（ステップ６７５）。Ｐ＜Ｌ_k−Ｍならば、その処理は、ｈ＝ＨＴ＿ＦＵＮ（ｓｔｒ_k，Ｐ，Ｍ）のようにハッシュ値を計算するステップ６４０に戻る。しかしながら、その処理がＰはＬ_k−Ｍ以上であると決定するならば、それは、ｋ＜ｍであるか否かを決定する（ステップ６８０）。ｋ＜ｍならば、その処理は、ｋ＝ｋ＋１のようにｋをインクリメントし（ステップ６３５）、Ｌ_kにストリングｓｔｒ_kの長さを、Ｐ＝０およびＳＩＭ_k＝０のために値を割り当てる（ステップ６３０）。ｋがｍ以上であれば、その処理は、ＳＩＭ₁，．．．，ＳＩＭ_mを出力する（ステップ６８５）。上述のように、その出力は、有利に、入力ドキュメントと追加のドキュメントのリストとの間のパーセンテージでの類似性を提供する。

関連性検出エンジンは、有利に、パーセンテージ測定におけるドキュメント関連性を決定するよう構成される。その構成は、ヒットに含まれる関連のないドキュメントがパーセンテージ閾値によって除外され得るよう構成される。これは、サーチエンジンの利用を増加させ、大きい度合いの容認を有する結果を提供する。

一実施形態では、関連性検出エンジンは、有利に、ドキュメントフィルタを提供するよう構成される。それは、ドキュメント関連性の定義に基づいて、所定のドキュメントと他のドキュメントのリストの間の関連性（または類似性）を計算する。その関連性はパーセンテージで与えられる。所定の閾値Ｘ％のために、エンジンは、Ｘ％未満の関連性を有するリスト内のドキュメントを除外する。

概して、開示のマッチングエンジンは、多くのユニークな特徴および利点を含む。上述のような署名生成部および関連性検出エンジンの適用は、それぞれ個別におよびシステム構成内にユニークな態様を追加する。

また、明細書に記述の特徴および利点は、ここで実施形態に記述されるようなシステムおよび方法を使用するものにとって有利な使用をもたらす。例えば、ユーザは、ここに記述のような特定の情報へのアクセスを制御するために、例えば、制御信号を送受信することにより、多くの機構を提供される。また、それらの機能をサポートする構成要素例えばサーバシステムのすべての部分がユーザに対してローカルに位置するか遠隔に位置するかにかかわらず、これらの利益は生じる。

実施形態の完全な理解を与えるために、多数の特定の詳細を説明した。しかしながら、その実施形態がこれらの特定の詳細なしに実施されてもよいことを当業者は理解するであろう。他の例では、実施形態を不明瞭にしないように、周知の動作、構成要素および回路を詳細に説明しなかった。ここに開示の特定の構造および機能の詳細が代表的なものであり、実施形態の範囲を必ずしも限定しないことを認識されたい。

種々の実施形態は、１以上のハードウェア要素を用いて実施されればよい。一般に、ハードウェア要素は、一定の動作を実行するために配置されるあらゆるハードウェア構成を参照する。一実施形態では、例えば、ハードウェア要素は、基板上に設置されるあらゆるアナログあるいはデジタル電気あるいは電子素子を含んでもよい。その製造は、例えば、相補型金属酸化膜半導体（ＣＭＯＳ）、バイポーラ、バイポーラＣＭＯＳ（ＢｉＣＭＯＳ）技術のようなシリコンベースの集積回路（ＩＣ）技術を用いて実行されればよい。ハードウェア要素の例は、プロセッサ、マイクロプロセッサ、回路、回路素子（例えば、トランジスタ、抵抗器、コンデンサ、インダクタなど）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能な論理回路（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、論理ゲート、レジスタ、半導体素子、チップ、マイクロチップ、チップセットなどを含む。実施形態はこのコンテキストに限定されない。

種々の実施形態は、１以上のソフトウェア要素を用いて実施されてもよい。一般に、ソフトウェア要素は、一定の動作を実行するために配置されたあらゆるソフトウェア構造を参照する。一実施形態では、例えば、ソフトウェア要素は、プロセッサなどのハードウェア要素による実行に適したプログラム指示（命令）やデータを含めばよい。指示のプログラムは、実行されるとき、対応する動作セットをプロセッサに実行させる所定の構文にアレンジされた単語、値、もしくは記号を含むコマンドの組織的リストを含めばよい。

ソフトウェアは、プログラミング言語を用いて書かれあるいはコード化されればよい。プログラミング言語の例は、Ｃ、Ｃ＋＋、ＢＡＳＩＣ、Ｐｅｒｌ、Ｍａｔｌａｂ、Ｐａｓｃａｌ、Ｖｉｓｕａｌ ＢＡＳＩＣ、ＪＡＶＡ（商標）、ＡｃｔｉｖｅＸ、アセンブリ言語、機械コードなどを含めばよい。ソフトウェアは、あらゆるタイプのコンピュータに読み取り可能な媒体または機械に読み取り可能な媒体を用いて格納されてもよい。また、ソフトウェアは、ソースコードまたはオブジェクトコードとして媒体に格納されてもよい。また、ソフトウェアは、圧縮あるいは暗号化データとして媒体に格納されてもよい。ソフトウェアの例は、あらゆるソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、機械プログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、方法、手順（procedure）、ソフトウェアインタフェース、アプリケーションプログラムインタフェース（ＡＰＩ）、指示（命令）セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、文言、値、記号、あるいはあらゆるそれらの組み合わせを含めばよい。実施形態はこのコンテキストに限定されない。

いくつかの実施形態は、それらの派生語とともに、「連結され（coupled）」および「接続され（connected）」という表現を用いて説明され得る。これらの用語が互いに類義語として意図されていないことを理解されたい。例えば、いくつかの実施形態は、２以上の構成要素が互いに直接物理的または電気的に接触していることを示すために、用語「接続され」を用いて説明されてもよい。他の例では、いくつかの実施形態は、２以上の構成要素が直接物理的または電気的に接触していることを示すために、用語「連結され」を用いて説明されてもよい。また、しかしながら、用語「連結され」は、２以上の構成要素が互いに直接接触してないが、互いに協働しあるいは相互作用することを意味してもよい。実施形態はこのコンテキストに限定されない。

いくつかの実施形態は、例えば、あらゆるコンピュータに読み取り可能な媒体、機械に読み取り可能な媒体、あるいはソフトウェアを格納可能な商品を用いて実施されればよい。媒体または商品は、メモリを参照して記述されるあらゆる例のようなあらゆる適当なタイプのメモリユニット、メモリ素子、メモリ商品、メモリ媒体、記憶装置、記憶商品、記憶媒体あるいは記憶ユニットを含めばよい。媒体または商品は、メモリ、着脱可能なもしくは着脱できない媒体、消去可能なもしくは消去できない媒体、書き込み可能もしくは再書き込み可能な媒体、デジタルもしくはアナログ媒体、ハードディスク、フロッピー（登録商標）ディスク、読み出し専用のコンパクトディスク（ＣＤ−ＲＯＭ）、記録可能なコンパクトディスク（ＣＤ−Ｒ）、書き換え可能なコンパクトディスク（ＣＤ−ＲＷ）、光ディスク、磁気媒体、光磁気媒体、着脱可能なメモリカードもしくはディスク、多種のデジタルバーサタイルディスク（ＤＶＤ）、加入者識別モジュール、テープ、カセットなどを含めばよい。指示（命令）は、ソースコード、オブジェクトコード、コンパイル済コード、解釈済コード、実行可能なコード、スタティックコード、ダイナミックコードなどのあらゆる適当なタイプのコードを含めばよい。指示は、Ｃ、Ｃ＋＋、Ｊａｖａ、ＢＡＳＩＣ、Ｐｅｒｌ、Ｍａｔｌａｂ、Ｐａｓｃａｌ、Ｖｉｓｕａｌ ＢＡＳＩＣ、ＪＡＶＡ、ＡｃｔｉｖｅＸ、アセンブリ言語、機械コードなどのあらゆる適当なハイレベルの、ローレベルの、オブジェクト指向の、視覚による、コンパイル済のあるいは解釈済のプログラミング言語を用いて実施されてもよい。実施形態はこのコンテキストに限定されない。

別な方法で特に述べていない限り、「処理（processing）」、「コンピューティング（computing）」、「計算する（calculating）」、「決定する（determining）」などの用語は、コンピューティングシステムのレジスタあるいはメモリ内の物理量（例えば、電子）として表されるデータを処理し、コンピューティングシステムのメモリ、レジスタまたは他のそのような情報記録、送信または表示装置内で物理量として同様に表される他のデータに変換するコンピュータもしくはコンピューティングシステムまたは同様の電子コンピューティング装置の動作あるいは処理を言及することを認識するであろう。実施形態はこのコンテキストに限定されない。

ここで用いられるように、「一実施形態（one embodiment）」または「一実施形態（an embodiment）」というあらゆる参照は、実施形態に関連して説明される特定の要素、特徴、構造、または特性が少なくとも一つの実施形態に含まれることを意味するものである。明細書中の種々の場所の句「一実施形態における（in one embodiment）」の出現は、必ずしもすべてが同じ実施形態に言及していない。

ここで用いられるように、用語「備える（comprises）」、「備えている（comprising）」、「含む（includes）」、「含んでいる（including）」、「有する（has）」、「有している（having）」あるいはあらゆる他のバリエーションは、排他的ではない包含を含むように意図される。例えば、要素のリストを含む処理、方法、商品または装置は、必ずしもそのような要素のみに限定されず、明白にリストされずあるいはそのような処理、方法、商品、または装置に固有の他の要素を含んでもよい。また、それと反対に明白に言わない限り、「または、もしくは（or）」は、排他的な「or」ではなく包含的な「or」を言及する。例えば、条件ＡまたはＢは、以下の条件、すなわち、Ａが正であり（または存在し）、Ｂが偽（または存在しない）であるか、Ａが偽（または存在しない）であり、Ｂが正（または存在し）あるか、ＡとＢの両方が正である（または存在する）かのいずれか一つによって満たされる。

また、「ある（a）」または「ある（an）」の使用は、本発明の実施形態の要素および構成要素を記述するために用いられる。これは、単に好都合で、本発明の実施形態の一般的な意味を与えるためになされたものである。この記述は、１つあるいは少なくとも１つを含むように読むべきである。また、単数は、別な方法で意味することが明白でない限り、複数を含むものである。

本開示を読むと、当業者は、クエリ関連ドキュメントに対するマッチングエンジンのシステムおよび処理のための追加の代わりの構造的および機能的設計を認識するであろう。それは、ここに開示の原則を通して署名生成および関連性検出を含んでもよい。したがって、特定の実施形態および適用が記載され、説明されたが、本発明がここに開示の正確な構成および構成要素に限定されず、添付の特許請求の範囲において定義されるような本発明の意図および範囲を逸脱することなく、当業者に明白な種々の修正、変更および変形がここに開示の本発明の方法および装置の配置、動作、詳細においてなされてもよいことを理解されたい。

サーチエンジンの従来のアーキテクチャの一実施形態を示す。 本発明におけるマッチングエンジンのアーキテクチャの一実施形態を示す。 本発明における署名生成処理の第１実施形態を示す。 本発明における署名生成処理の第２実施形態を示す。 本発明における関連性決定処理の第１実施形態を示す。 本発明における関連性決定処理の第２実施形態を示す。

Claims (38)

1. ドキュメントに関連した複数の署名を生成する方法であって、
   テキストを含むドキュメントを受信するステップと、
   それぞれが予め定められた文字特性によって分けられる前記ドキュメントのテキストに対応する複数のトークンを含むトークンセットを生成するために、前記ドキュメントを解析するステップと、
   前記ドキュメント内の前記テキストの頻度および分布に基づいて、前記トークンセット内の各トークンのためのスコアを計算するステップと、
   前記計算されたスコアに基づいて、前記トークンセット内の各トークンをランク付けするステップと、
   前記ランク付けされたトークンからランク付けされたトークンのサブセットを選択するステップと、
   前記選択されたトークンの各発生のための署名を生成するステップと、
   を含むことを特徴とする方法。
2. 前記予め定められた文字特性はデリミタを含むことを特徴とする請求項１に記載の方法。
3. 前記ランク付けされたトークンから前記ランク付けされたトークンのサブセットを選択するステップは、トップにランク付けされたトークンの所定数を選択するステップをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記署名の選択されたリストを出力するステップは、あるリスト内のトップの署名の所定数を出力するステップをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記ドキュメントはＡＳＣＩＩドキュメントであることを特徴とする請求項１に記載の方法。
6. 前記生成された署名のリストを出力するステップをさらに有することを特徴とする請求項１に記載の方法。
7. ドキュメントに関連した複数の署名を生成する方法であって、
   複数の文字を含むドキュメントを受信するステップと、
   前記複数の文字から有益でない文字を取り除くために、前記ドキュメントを標準化するステップと、
   前記ドキュメントの発生頻度および分布に基づいて、前記複数の文字の各有益な文字のスコアを計算するステップと、
   前記計算されたスコアに基づいて、前記複数の文字の各有益な文字をランク付けするステップと、
   前記ランク付けされた有益な文字から文字発生を選択するステップと、
   各選択された文字発生のための署名を生成するステップと、
   を有することを特徴とする方法。
8. 前記文字発生を選択するステップは、ハッシュ値を生成するために、各文字発生の回りのバイトをハッシングするステップと、予め定められたランク付けに前記ハッシュ値をソートするステップとをさらに含むことを特徴とする請求項７に記載の方法。
9. 前記署名を生成するステップは、前記選択された文字発生の回りの文字を用いて、前記署名を生成するステップをさらに含むことを特徴とする請求項７に記載の方法。
10. 前記文字はＵＴＦ−８文字であることを特徴とする請求項７に記載の方法。
11. 前記有益でない文字は、余分な空白、制御文字、その組み合わせからなるグループからの一つを含むことを特徴とする請求項７に記載の方法。
12. 前記生成された署名のリストを出力するステップをさらに有することを特徴とする請求項７に記載の方法。
13. プロセッサに実行可能な指示を格納するよう構成されるコンピュータに読み取り可能な媒体であって、前記指示は、実行されるとき、
    テキストを含むドキュメントを受信するステップと、
    それぞれが予め定められた文字特性によって分けられる前記ドキュメントのテキストに対応する複数のトークンを含むトークンセットを生成するために、前記ドキュメントを解析するステップと、
    前記ドキュメント内の前記テキストの頻度および分布に基づいて、前記トークンセット内の各トークンのためのスコアを計算するステップと、
    前記計算されたスコアに基づいて、前記トークンセット内の各トークンをランク付けするステップと、
    前記ランク付けされたトークンからランク付けされたトークンのサブセットを選択するステップと、
    前記選択されたトークンの各発生のための署名を生成するステップと、
    を前記プロセッサに実行させることを特徴とするコンピュータに読み取り可能な媒体。
14. 前記予め定められた文字特性はデリミタを含むことを特徴とする請求項１３に記載のコンピュータに読み取り可能な媒体。
15. 前記ランク付けされたトークンから前記ランク付けされたトークンのサブセットを前記プロセッサに選択させる指示は、トップにランク付けされたトークンの所定数を該プロセッサに選択させる指示をさらに含むことを特徴とする請求項１３に記載のコンピュータに読み取り可能な媒体。
16. 前記署名の選択されたリストを前記プロセッサに出力させる指示は、あるリスト内のトップの署名の所定数を該プロセッサに出力させる指示をさらに含むことを特徴とする請求項１３に記載のコンピュータに読み取り可能な媒体。
17. 前記ドキュメントはＡＳＣＩＩドキュメントであることを特徴とする請求項１３に記載のコンピュータに読み取り可能な媒体。
18. 前記プロセッサに実行されるときの前記指示は、さらに、前記生成された署名のリストを該プロセッサに出力させることを特徴とする請求項１３に記載のコンピュータに読み取り可能な媒体。
19. プロセッサに実行可能な指示を格納するよう構成されるコンピュータに読み取り可能な媒体であって、前記指示は、実行されるとき、
    複数の文字を含むドキュメントを受信するステップと、
    前記複数の文字から有益でない文字を取り除くために、前記ドキュメントを標準化するステップと、
    前記ドキュメントの発生頻度および分布に基づいて、前記複数の文字の各有益な文字のスコアを計算するステップと、
    前記計算されたスコアに基づいて、前記複数の文字の各有益な文字をランク付けするステップと、
    前記ランク付けされた有益な文字から文字発生を選択するステップと、
    各選択された文字発生のための署名を生成するステップと、
    を前記プロセッサに実行させることを特徴とするコンピュータに読み取り可能な媒体。
20. 前記文字発生を前記プロセッサに選択させる指示は、該プロセッサにより実行されるとき、ハッシュ値を生成するために、各文字発生の回りのバイトを該プロセッサにハッシングさせる指示と、該プロセッサに予め定められたランク付けに前記ハッシュ値をソートさせる指示とをさらに含むことを特徴とする請求項１９に記載のコンピュータに読み取り可能な媒体。
21. 前記プロセッサに前記署名を生成させる指示は、前記選択された文字発生の回りの文字を用いて、該プロセッサに前記署名を生成させる指示をさらに含むことを特徴とする請求項１９に記載のコンピュータに読み取り可能な媒体。
22. 前記文字はＵＴＦ−８文字であることを特徴とする請求項１９に記載のコンピュータに読み取り可能な媒体。
23. 前記有益でない文字は、余分な空白、制御文字、リターン、その組み合わせからなるグループからの一つを含むことを特徴とする請求項２２に記載のコンピュータに読み取り可能な媒体。
24. 前記プロセッサにより実行されるときの前記指示は、前記生成された署名のリストを前記プロセッサに出力させることを特徴とする請求項１９に記載のコンピュータに読み取り可能な媒体。
25. 所定の関連性を有するドキュメントの出力を生成する方法であって、
    テキストを含む最初のドキュメントを受信するステップと、
    マッチングのために、それぞれがテキストを含む複数のドキュメントのリストを受信するステップと、
    最小部分文字列の適合長を受信するステップと、
    前記ドキュメントのリストにおける該ドキュメントの前記テキストを標準化するステップと、
    前記最初のドキュメントの前記テキストと前記ドキュメントのリストにおける各ドキュメントの前記テキストとの間の共通の部分文字列をサーチするステップと、
    前記サーチされた共通の部分文字列に基づいて、適合パーセンテージを計算するステップと、
    所定の値に対応する適合パーセンテージを有するドキュメントを出力するステップと、
    を有することを特徴とする方法。
26. 前記サーチステップの前に、前記最初のドキュメントの前記テキストをソートするステップをさらに有することを特徴とする請求項２５に記載の方法。
27. 前記サーチステップの前に、前記最初のドキュメントの前記テキストの部分文字列に対するハッシュ値を生成するステップをさらに有することを特徴とする請求項２５に記載の方法。
28. 前記サーチステップは、二分サーチ技術を用いてサーチするステップをさらに含むことを特徴とする請求項２５に記載の方法。
29. 前記計算ステップは、相似関数に基づいて、適合パーセンテージを計算するステップをさらに含むことを特徴とする請求項２５に記載の方法。
30. 前記所定の値は、第１の所定の値と第２の所定の値との間の範囲であることを特徴とする請求項２５に記載の方法。
31. 前記ドキュメントのリストは複数のドキュメントを含むことを特徴とする請求項２５に記載の方法。
32. プロセッサに実行可能な指示を格納するよう構成されるコンピュータに読み取り可能な媒体であって、前記指示は、実行されるとき、
    テキストを含む最初のドキュメントを受信するステップと、
    マッチングのために、それぞれがテキストを含む複数のドキュメントのリストを受信するステップと、
    最小部分文字列の適合長を受信するステップと、
    前記ドキュメントのリストにおける該ドキュメントの前記テキストを標準化するステップと、
    前記最初のドキュメントの前記テキストと前記ドキュメントのリストにおける各ドキュメントの前記テキストとの間の共通の部分文字列をサーチするステップと、
    前記サーチされた共通の部分文字列に基づいて、適合パーセンテージを計算するステップと、
    所定の値に対応する適合パーセンテージを有するドキュメントを出力するステップと、
    を前記プロセッサに実行させることを特徴とするコンピュータに読み取り可能な媒体。
33. 前記サーチステップの前に、前記プロセッサに前記最初のドキュメントの前記テキストをソートさせる指示をさらに含むことを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。
34. 前記サーチステップの前に、前記最初のドキュメントの前記テキストの部分文字列に対するハッシュ値を前記プロセッサに生成させる指示をさらに含むを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。
35. 前記プロセッサにサーチさせる指示は、前記プロセッサに二分サーチ技術を用いてサーチさせる指示をさらに含むことを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。
36. 前記プロセッサに計算させる指示は、相似関数に基づいて、前記プロセッサに適合パーセンテージを計算させる指示をさらに含むことを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。
37. 前記所定の値は、第１の所定の値と第２の所定の値との間の範囲であることを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。
38. 前記ドキュメントのリストは複数のドキュメントを含むことを特徴とする請求項３２に記載のコンピュータに読み取り可能な媒体。

Images