JP5461360B2 - スーパーユニットを用いた検索処理のためのシステム及び方法 - Google Patents

Description

本発明は、一般的には、ネットワーク、インターネット検索及びインタフェースシステムに関し、より特定的には、拡張型検索に対して機能性を与える検索システムに関する。

この出願は、「ユニットのクラスタ化を用いた検索処理のためのシステム及び方法」と題して２００３年１０月９日に出願された米国仮出願第６０／５１０,２２０号の利益を主張するものであり、この仮出願の開示内容は、引用によりあらゆる目的のために本明細書に組み入れられる。

この明細書の開示内容は、「検索の問い合わせから概念ユニットを生成するシステム及び方法」と題して２００３年１１月１２日に出願され、上記仮出願と同様に譲渡された米国特許出願第１０／７１３,５７６号に関連し、また、「汎用性検索インターフェースシステム及び方法」と題して２００３年４月４日に出願され、上記仮出願と同様に譲渡された米国特許出願第６０／４６０,２２２号に関連する。これらの出願の各開示内容は、引用によりあらゆる目的のために本明細書に組み入れられる。

インターネットが出現し、多数のウェブページ及びメディアコンテンツがワールドワイドウェブ（ウェブ）を介してユーザに利用可能となったことにより、ウェブから所望の情報をフィルタリングして取得する能率化した手法をユーザに対して提供する必要がある。検索システム及び処理は、ユーザによる所望の情報を取得する必要性を満たすように開発されている。このようなテクノロジーの例は、Ｙａｈｏｏ！、Ｇｏｏｇｌｅ及び他のサイトを介して利用することができる。典型的には、ユーザが、問い合わせ（query）を入力し、検索処理が、その問い合わせに関連した１又はそれ以上のリンク（ウェブを検索する場合）、文書及び／又はリファレンスを返す。返されるリンクは、そのユーザが実際に探しているものと密接に関連しているか、又は、全く関連していない。問い合わせに対する結果の「関連性」は、部分的には、用いられた検索システム（基礎的な収集システム）の頑強性（robustness）に加えて、入力された実際の問い合わせの関数となりうる。関連性は、ユーザによって主観的に決定され、又は、ユーザが探していたかもしれないものによって客観的に決定されうる。ユーザが探していたかもしれないものによって客観的に決定されうる。全く関連していない。問い合わせに対するものと密接に関連しているか、又は、全く関連していない。問い合わせに対する結果の「関連性」は、部分的には、用いられた検索システム（基礎的な収集システム）の頑強性に加えて、入力された十さいの問い合わせの関数となりうる。関連性は、ユーザによって主観的に決定され、又は、ユーザが探していたかもしれないものによって客観的に決定されうる。ユーザが探していたかもしれないものによって客観的に決定される。全く関連していない。問い合わせに対するものと密接に関連しているか、又はまったく関連していない。どのようにしてユーザによって主観的に決定され、又は、ユーザが探していたかもしれないものによって客観的に決定されうる。

ユーザが入力した問い合わせは、典型的には１又はそれ以上の単語により構成される。例えば、「hawaii」は問い合わせであり、「new york city」や「new york city law enforcement」もまた問い合わせである。問い合わせは全体として人間の脳に不可欠なものではない。換言すれば、人間は、本来、問い合わせに基づいて思考しているのではない。問い合わせは、部分的には、検索エンジンに問い合わせる必要性又はライブラリカタログを調べる必要性によって課された人工的な構築物である。人間は、本来、画一的な単語のみに基づいて思考しているのではない。人間が思考する際に基づいているものは、自然な概念である。例えば、「hawaii」及び「new york city」は、単語数によって測定される長さという点においては著しく異なる問い合わせであるが、人間にとっては、これらは、１つの重要な特徴を共有する、すなわち、これらは各々１つの概念によって構成されている。対照的に、「new york city law enforcement（ニューヨーク市の法律施行）」という問い合わせは、２つの互いに異なる概念、すなわち、「new york city（ニューヨーク市）」及び「law enforcement（法律施行）」により作られているので、人間は、この問い合わせを根本的に異なるものとして考える。

人間はまた、概念と概念との間の論理的な関係に基づいて思考している。例えば、「law enforcement（法律施行）」と「police（警察）」とは、警察が法律施行の重要な機関であるので、関連した概念であるが、これら概念のうちの一方に基づいてタイプ入力をするユーザは、ユーザがたまたまタイプ入力をした特定の単語又はフレーズを他方の概念に関連するサイトが含んでいなくとも、そのサイトに興味を持っているかも知れない。このような思考パターンの結果として、人間は、本来、単に可変的に羅列した画一的な単語を入力することによってではなく、１又はそれ以上の自然な概念を入力することによって、問い合わせを構築し、この問い合わせは、一般的に、必ずしもユーザが気づいている関連した概念のすべてを含んでいるわけではない。また、ユーザの意図は、その問い合わせにおける個々の単語に必ずしも反映されているわけではない。例えば、「law enforcement（法律施行）」は１つの概念であるが、「law（法律）」及び「enforcement（施行）」という別々の単語は、これらが組み合わさった単語と同一のユーザの意図を個別に伝えるのではない。例えば、「法律施行」は１つの概念であるが、「法律」及び「施行」という別々の単語は、これらが組み合わさった単語と同一のユーザの意図を個別に伝えるのではい。

主要な検索プロバイダ、例えばＭＳＮ、Ｇｏｏｇｌｅ又は他の主要な検索エンジンサイトにおける現在の技術は、問い合わせを、人間がその問い合わせを創作する方法と同一の方法では理解しない。例えば、現存する検索エンジンは、一般的には、ユーザが実際に頭の中で考えている基本的な自然な概念又は関連する概念についてではなく、ユーザが入力した正確な単語又はフレーズについて検索をする。これが、恐らく検索プロバイダがユーザの意図を認識できず最適な検索結果及びコンテンツを提供することを妨げる最も重要な理由となっている。

以上の説明から明らかなように、ユーザが興味を持っているかもしれない実際の概念にさらに近づいた結果を提供し、よりよいユーザ体験を提供することを支援する、改善された検索技術及びインタフェース技術に対する必要性がある。

本発明の実施形態は、検索の対象となっている情報をより正確に理解することを可能とするために、受信した問い合わせを分析することを含め、検索の要求を処理するシステム及び方法を提供する。問い合わせを複数のユニットに分解し、例えば問い合わせ中に一緒に出現している複数のユニットのパターンに基づいて、これら複数のユニットの間において様々な関係を定めることによって、概念ネットワークが１組の問い合わせから生成される。この概念ネットワークから、異なる複数のユニット間における様々な類似性を検出することができ、いくつかの識別特性を共通に有する複数のユニットを複数のスーパーユニットにグループ化することができる。各スーパーユニットについて、そのグループの識別特性を定める対応する署名がある。複数の構成要素ユニットを識別し、その構成要素ユニットのいくつか又はすべてのスーパーユニットメンバシップを決定し、その情報を用いてその問い合わせに対する応答を形成することにより、その問い合わせは処理される。

本発明の１つの特徴によれば、ユーザの検索の問い合わせからスーパーユニットを生成するためにコンピュータにより実行される方法が提供される。多数の過去の（previous）問い合わせが、複数のユニットと、各々が結合したエネルギーウェイトを有する複数のユニットの複数の対の間で定められる関係とを含む概念ネットワークとして表現される。スーパーユニット種が識別され、このスーパーユニット種は、各々が概念ネットワークにおける複数のユニットの１つである少なくとも１つのメンバユニットを有する。署名がスーパーユニット種について定められる。その署名は、各々が少なくとも最少数のメンバユニットとの間で概念ネットワークにおいて関係を有する１又はそれ以上の署名ユニットを含む。次に、スーパーユニット種は、各々が署名に基づく一致基準を満足する１又はそれ以上の新メンバユニットを概念ネットワークから加えることにより拡張される。署名は、拡張されたスーパーユニット種に基づいて変更される。拡張及び変更するステップは、収束基準が満足されるまで繰り返され、一旦その収束基準が満足されると、最終的なスーパーユニット及び最終的な署名が形成される。次に、最終的なスーパーユニットにおける各メンバユニットについてのスーパーユニットメンバシップ情報が格納され、この情報は、この後の問い合わせに応答して用いることができる。スーパーユニットメンバシップ情報は、例えば、最終的なスーパーユニットにおける各メンバユニットについてのメンバシップウェイトを含むことができる。このメンバシップウェイトは、最終的な署名におけるメンバユニットと署名ユニットとの間での概念ネットワークにおける関係に基づいている。

本発明の別の特徴によれば、ユーザの検索の問い合わせからスーパーユニットを生成するシステムが、概念ネットワーク構築モジュールと、スーパーユニット種モジュールと、スーパーユニット構築モジュールと、格納モジュールとを含む。概念ネットワーク構築モジュールは、１組の過去の問い合わせから概念ネットワークを生成するように構成され、この概念ネットワークは、複数のユニットと、各々が結合エッジウェイトを有する複数のユニットの対の間で定められた複数の関係とを含む。スーパーユニット種モジュールは、各々が概念ネットワークにおける複数のユニットのうちの１つである少なくとも１つのメンバユニットを備えるスーパーユニット種を識別するように構成される。スーパーユニット構築モジュールは、スーパーユニット種から始めて、スーパーユニット及び署名を構築するように構成される。各スーパーユニットは、複数のメンバユニットを含み、各署名は、スーパーユニットのうちの１つと結合している。各署名は、各々が結合したスーパーユニットにおける少なくとも最小数のメンバユニットとの間で概念ネットワークにおいて関係を有する１又はそれ以上の署名ユニットを含む。格納モジュールは、スーパーユニット構築モジュールによって与えられる、メンバユニットについてのスーパーユニットメンバシップ情報を格納するように構成される。いくつかの実施形態では、本システムはまた、格納モジュールに結合され、現在の問い合わせを受信するように構成された問い合わせ応答モジュールをも含む。問い合わせ応答モジュールは、現在の問い合わせを１又はそれ以上の構成要素ユニットに分解し、１又はそれ以上の構成要素ユニットについてのスーパーユニットメンバシップ情報を格納モジュールから検索し、検索したスーパーユニットメンバシップ情報に少なくとも部分的に基づいて現在の問い合わせに対する応答を形成する。

本発明の本質及び有利な点をより理解しやすくするために、以下、添付図面を参照しつつ詳細に説明する。

本発明の一実施形態に係る情報検索及び通信システムの簡略化した高レベルのブロック図である。 本発明の一実施形態に係るメディアコンテンツを通信するための情報検索及び通信ネットワークの簡略化したブロック図である。 本発明の一実施形態に係る概念ネットワークの図による表現である。 本発明の一実施形態に係る問い合わせ処理エンジンの簡略化したブロック図である。 本発明の一実施形態に係るスーパーユニット種として利用可能なクラスタを生成するための処理のフロー図である。 本発明の一実施形態に係るスーパーユニット種として利用可能なクリークを生成するための処理のフロー図である。 本発明の一実施形態に係る種からスーパーユニットを構築するための処理のフロー図である。 図７に示したスーパーユニット生成処理における異なるステージでの概念ネットワークの図による表現である。 図７に示したスーパーユニット生成処理における異なるステージでの概念ネットワークの図による表現である。 本発明の一実施形態に係るスーパーユニットについての署名の組を構築するための処理のフロー図である。 図７のスーパーユニット生成処理の結果の一例を示し、署名ユニットを示す図である。 図７のスーパーユニット生成処理の結果の一例を示し、各スーパーユニットメンバを示す図である。 本発明の一実施形態に係る、ユニット辞書及び結合処理知能をいくつかの特徴における問い合わせ処理エンジンとともに含むシステムの簡略化したブロック図である。

１．概略
Ａ．ネットワークの実装
図１は、本発明の一実施形態に係るクライアントシステム２０を含む情報検索及び通信ネットワーク１０の概略を示す。コンピュータネットワーク１０において、クライアントシステム２０が、例えばローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）を通じインターネット４０又は他の通信ネットワークを介して、多数のサーバシステム５０₁〜５０_Nに結合されている。本明細書において記載するように、クライアントシステム２０は、本発明に従い、サーバシステム５０₁〜５０_Nのいずれかと通信して、例えば、メディアコンテンツ及びウェブページのような他の情報をアクセス、受信、検索及び表示するように構成されている。

図１に示すシステムにおけるいくつかの構成要素は、本明細書では詳細には説明する必要のない通常の周知な構成要素を含む。例えば、クライアントシステム２０は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、携帯情報端末（ＰＤＡ）、携帯電話、ＷＡＰを利用可能な装置、又は、インターネットに対して直接的に又は間接的にインタフェース可能な計算装置を含むことができる。クライアントシステム２０は、典型的には、マイクロソフト社のインターネットエクスプローラ（登録商標）、ネットスケープナビゲータ（登録商標）ブラウザ、モジラ（登録商標）ブラウザ、オペラ（登録商標）ブラウザのようなブラウジングプログラム、又は、携帯電話、ＰＤＡ若しくは他の無線装置等の場合にはＷＡＰを利用可能なブラウザを実行させて、クライアントシステム２０のユーザに対して、インターネット４０を通じてサーバシステム５０₁〜５０_Nからユーザに利用可能な情報及びページをアクセス、処理及び表示することを可能にしている。クライアントシステム２０はまた、典型的には、サーバシステム５０₁〜５０_N又は他のサーバにより提供されるページ、フォーム及び他の情報に関連して、ディスプレイ（例えばモニタスクリーン、ＬＣＤディスプレイ等）上においてブラウザによって提供されるグラフィカルユーザインタフェース（ＧＵＩ）と対話するためのキーボード、マウス、タッチスクリーン、ペン等のような１又はそれ以上のユーザインタフェース装置２２を含む。本発明は、様々なネットワークのうちの特定のグローバルインターネットワークを示す、インターネットを用いた用途に好適である。しかしながら、インターネットに代えて又はインターネットに加えて、イントラネット、エクストラネット、仮想専用線網（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、ＬＡＮ又はＷＡＮ等のような他のネットワークを用いることもできる、ということが理解できよう。

一実施形態によれば、クライアントシステム２０及びこのクライアントシステム２０のすべての構成要素は、インテル社のペンティアム（登録商標）プロセッサ、ＡＭＤ社のアスロン（登録商標）プロセッサ等又は多数のプロセッサのような中央処理装置（ＣＰＵ）を用いてコンピュータコードを実行することを含むアプリケーションを用いて、オペレータにより構成可能である。クライアントシステム２０を動作させ構成して、本明細書で説明するようなデータ及びメディアを通信、処理及び表示するためのコンピュータコードは、好ましくは、ダウンロードされハードディスクに格納されるが、プログラムコード全体又はプログラムコードの複数の部分は、ＲＯＭ又はＲＡＭのような周知となっている他の揮発性若しくは不揮発性のメモリ媒体若しくは装置に格納することもできるし、或いは、コンパクトディスク（ＣＤ）媒体、ディジタルビデオディスク（ＤＶＤ）媒体若しくはフロッピー（登録商標）ディスク等のような、プログラムコードを格納することが可能な媒体に設けることができる。さらには、プログラムコード全体又はプログラムコードの複数の部分は、ソフトウェアソースから例えばサーバシステム５０₁〜５０_Nから、クライアントシステム２０に対して、インターネットを通じて送信及びダウンロードすることができ、又は、通信媒体及び通信プロトコル（例えばＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）若しくは通常の媒体及びプロトコル）を用いてネットワーク接続（例えばエクストラネット、ＶＰＮ、ＬＡＮ若しくは他の通常のネットワーク）を通じて送信することができる。

本発明の特徴を実現するためのコンピュータコードは、Ｃ、Ｃ＋＋、ＨＴＭＬ、ＸＭＬ、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ等のコードとすることができ、或いは、クライアントシステム２０上で実行可能な若しくはクライアントシステム２０上でコンパイルして実行可能な、他の適当なスクリプト言語又は適当なプログラミング言語とすることができる、ということが理解できよう。いくつかの実施形態では、クライアントシステム２０にはコードがダウンロードされず、必要とされるコードがサーバにより実行され、或いは、クライアントシステム２０に既に存在するコードが実行される。

Ｂ．検索システム
図２は、本発明の一実施形態に係る、別のメディアコンテンツを通信するための情報検索及び通信ネットワーク１１０を示す。図２に示すように、ネットワーク１１０は、クライアントシステム１２０と、１又はそれ以上のコンテンツサーバシステム１５０と、検索サーバシステム１６０とを含む。ネットワーク１１０において、クライアントシステム１２０が、インターネット１４０又は他の通信ネットワークを介してサーバシステム１５０及び１６０に対して通信可能に結合されている。上述したように、クライアントシステム１２０及びこのクライアントシステムの構成要素は、インターネット１４０又は他のネットワークを介してサーバシステム１５０及び１６０並びに他のサーバシステムと通信するように構成されている。

１．クライアントシステム
一実施形態によれば、クライアントシステム１２０上で実行するクライアントアプリケーション（モジュール１２５として表現されている）は、クライアントシステム１２０を制御するための命令と、サーバシステム１５０及び１６０と通信してこれらから受信したデータコンテンツを処理及び表示するためのクライアントシステム１２０の構成要素とを含む。クライアントアプリケーション１２５は、好ましくは、リモートサーバシステム（例えば、サーバシステム１５０、サーバシステム１６０又は他のリモートサーバシステム）のようなソフトウェアソースからクライアントシステム１２０に対して送信及びダウンロードされるが、クライアントアプリケーションモジュール１２５は、上述したようなフロッピーディスク、ＣＤやＤＶＤ等のようなソフトウェア格納媒体上に設けることができる。例えば、１つの特徴として、クライアントアプリケーションモジュール１２５は、インターネット１４０を介して、様々なオブジェクト、フレーム及びウィンドウにおいてデータを操作及びレンダリングするための様々なコントロール、例えば、組込み型Ｊａｖａスクリプト若しくはアクティブＸコントロールを含んだＨＴＭＬラッパーにより提供することができる。

さらには、クライアントアプリケーションモジュール１２５は、検索リクエスト及び検索結果データを処理する専用の検索モジュール１２６のような、データ及びメディアコンテンツを処理するための様々なソフトウェアモジュールと、テキスト、データフレーム及びアクティブウィンドウ（例えばブラウザウィンドウ及びダイアローグボックス）におけるデータ及びメディアコンテンツをレンダリングするためのユーザインタフェースモジュール１２７と、クライアント１２０上で実行している様々なアプリケーションをインタフェースしこのアプリケーションと通信するためのアプリケーションインタフェースモジュール１２８とを含む。本発明の特徴に従って好ましくはインタフェースするように構成されたアプリケーションインタフェースモジュール１２８によるインタフェースの対象となるクライアントシステム１２０上で実行する様々なアプリケーションの例は、電子メールアプリケーション、インスタントメッセージ（ＩＭ）アプリケーション、ブラウザアプリケーション、文書管理アプリケーション及びその他を含む。さらには、インタフェースモジュール１２７は、クライアントシステム１２０上で構成されたデフォルトのブラウザ又は別のブラウザのようなブラウザを含むことができる。いくつかの実施形態では、クライアントアプリケーションモジュール１２５は、上記の通り参照した仮出願第６０／４６０,２２２号において記載したような汎用型（universal）検索インターフェースの特徴を実現する。

２．検索サーバシステム
一実施形態によれば、検索サーバシステム１６０は、クライアントシステム１２０に対して検索結果データ及びメディアコンテンツを与えるように構成されており、コンテンツサーバシステム１５０は、ウェブページのようなデータ及びメディアコンテンツを、例えば検索サーバシステム１６０により与えられた検索結果ページにおいて選択されたリンクに応答して、クライアントシステム１２０に与えるように構成されている。いくつかの変形例では、検索サーバシステム１６０は、コンテンツに対するリンク及び／又は他のリファレンスとともに又はこれに代えて、コンテンツを返す。検索サーバシステム１６０はまた、好ましくは、後述する問い合わせログファイルの形で、ユーザの問い合わせ行動（activity）を記録するように構成される。

一実施形態における検索サーバシステム１６０は、ページ、ページへのリンク、インデックスしたページの内容を示すデータ等を用いて生成された、様々なページインデックス１７０を参照する。ページインデックスは、階層構造内にウェブページを分類及び等級付けるためのマニュアル又は半自動分類アルゴリズム及びインタフェースとともに、自動ウェブクローラ（crawler）、スパイダ等を含む様々な収集技術により生成される。これらの技術は、検索サーバシステム１６０上において、又は、ページインデックス１７０を生成して検索サーバシステム１６０で利用可能にする別のシステム（図示しない）内において、実現することができる。

ページインデックス１７０におけるエントリ１６２は、検索語と、この検索語が現れているページに対するリンク（又は他の符号化された識別子）と、そのページに関するコンテキスト識別子とを含む。コンテンキスト識別子は、様々なコンテキストにおいて様々な意味を有しうる検索語についての類似した結果を分類（グループ化）する。例えば、「ｊａｖａ」という検索語は、Ｊａｖａコンピュータ言語、インドネシアのジャバ島、又は、コーヒー（これは口語的にはjavaと称されることが多い）を示す。ページに関するコンテキスト識別子は、好ましくは、これらのコンテキストのうちいずれが適用可能であるかを示す。ページリンクは、多数のコンテキスト識別子に関連付けることができるので、同一のページ（又はこのページに対するリンク）は、多数のコンテキストにおいて表示することができる。コンテキスト識別子は、好ましくは、ユーザが関連した検索を実行したときに、このシステムによってページリンクに対して自動的に関連付けられるが、識別子は、１又はそれ以上の識別子編集者チームの手作業により、変更されリンクに関連付けることができる。この方法により、非常に多くの検索から集められた知識が、このシステムにフィードバックされて、コンテキストを定義及び再定義して、表示される検索結果をリクエストをしたユーザにとってより価値がありより有益なものとすることができる。

検索サーバシステム１６０は、クライアントシステムから受信した、具体的には検索モジュール１２６から受信した様々な検索リクエストに応答するデータを提供するように構成される。例えば、検索サーバシステム１６０は、（例えば、問い合わせにおける検索語、コンテキスト識別子、ページのスポンサ等の出現パターンによって測定されたような論理的関連性の組み合わせに基づいて）与えられた問い合わせに関連するウェブページを処理及び等級付けするための、検索に関連したアルゴリズムを用いて構成することができる。本発明の実施形態によれば、これらのアルゴリズムは、概念分析のためのアルゴリズムを含む。

例えば、本発明のいくつかの実施形態は、ユーザのコンピュータ１２０において表示するためのコンテキストにおける検索問い合わせ及び／又は結果並びにグループ結果を分析する。例えば、「Ｊａｖａ」という検索語に応答して、いくつかの実施形態に係る検索サーバシステム１６０は、３つの（他のコンテキストが認識されている場合にはそれ以上の）コンテキスト又は単語の意味にグループ化した検索結果、すなわち、「Ｊａｖａ コンピュータ言語」、「Ｊａｖａ 島」及び「コーヒー ｊａｖａ」を返す。このシステムは、各コンテキストに関連して設けられたリンクを有するセットとして結果を表示するように構成することができ、或いは、このシステムは、リンクのないコンテキストのみを表示して、ユーザに対して、所望のコンテキストを選択させてこれに関連するリンクを表示することができる。Ｙａｈｏｏ！ネットワークシステムでは、例えば、各々が、検索インデックスからのページに対する１組のリンクと、スポンサー提供されたマッチ（sponsored match）に関連するリンクと、直接的なマッチに関連するリンクと、Ｉｎｓｉｄｅ Ｙａｈｏｏ！（ＩＹ）マッチに関連するリンクとを有する、１組のコンテキストを表示することができる。

「Ｊａｖａ」のようなあいまいな（複数通りの；ambiguous）意味を有する単語又はフレーズに加えて、本発明のいくつかの実施形態は、必ずしもあいまいであるとは限らない検索語についてのコンテキストに結果をグループ化するように構成される。１つの例は、「ハワイ」という検索語について返される結果である。「ハワイ」という語は、本来、あいまいな語ではないし、ひとりでにあいまいな語になることもないが、このような語について返される結果の特徴は、非常に広くなり、ハワイについて議論する又はハワイについて単に言及するに過ぎないあらゆるサイトに関連しうる。ユーザに対してより有用な結果を与えるためには、本発明のシステムは、好ましくは、検索結果が実際に何に関連しているのかについての知識を高めることにより、この検索結果をコンテキスト内に編入する。例えば、ハワイについては、本システムは、「ハワイ：旅行」、「ハワイ：気候」、「ハワイ：地理学」、「ハワイ：文化」等のような様々なコンテキストのグループ化（グルーピング；grouping）によって、結果を返すことができる。このようなコンテキスト識別子（「旅行」や「気候」等）は、上述したようにページインデックスエントリ１６２に格納することができる。

本明細書で説明した検索システムが例示的なものであり、様々な変形及び変更が可能である、ということが理解できよう。コンテンツサーバ及び検索サーバシステムは、単一の組織の部分、例えば、Ｙａｈｏｏ！株式会社によってユーザに適用されるもののような分散型サーバシステムとすることができ、或いは、これらは、異なる複数の組織の部分とすることができる。各サーバシステムは、通常、少なくとも１つのサーバと、１つの関連するデータベースシステムとを含み、また、多数のサーバと、複数の関連するデータベースシステムとを含むこともでき、さらに、１つのブロックとして図示したが、地理的に分散させることもできる。例えば、１つの検索サーバシステムにおけるすべてのサーバは、（例えば、単一の建物又はキャンパスにおいて配置された１つのサーバファーム（farm）内に）互いに近接して配置することができ、或いは、これらすべてのサーバは、互いに離れた位置に（例えば、１又はそれ以上のサーバをＡ市に配置し、１又はそれ以上のサーバをＢ市に配置して）分散させることができる。このように、本明細書において用いたように、「サーバシステム」は、典型的には、近くに又は１若しくはそれ以上の地理的な位置にわたって分散された、１又はそれ以上の論理的及び／又は物理的に接続されたサーバを含むが、「サーバ」及び「サーバシステム」という語は、入れ替えて用いることができる。

検索サーバシステムは、１又はそれ以上のページインデックスと、このページインデックスにアクセスして、クライアントシステムから受信した検索語に応答してユーザに対して検索結果を与えるためのアルゴリズムとを有するように、構成することができる。検索サーバシステムは、ページインデックス自体を生成し、別のソース（例えば別個のサーバシステム）からページインデックスを受信し、或いは、別のソースからページインデックスを受信してこのインデックスに対するさらなる処理（例えば、コンテキスト識別子を付加又は更新すること）を実行することができる。

Ｃ．概念ネットワーク及びスーパーユニット
１つの実施形態では、検索サーバシステム１６０上のアルゴリズムは、検索語に対する概念分析を実行して、ユーザに対してより関連のある結果を与える。例えば「New York City（ニューヨーク市）」という検索フレーズについては、ユーザは、ニューヨーク州の他の都市と比較すると、ニューヨーク市（この都市又は地域）に関連する場所に興味を持っている可能性が非常に高い。同様に、「New York City law enforcement（ニューヨーク市の法律施行）」については、ユーザは、ニューヨーク市における法律施行（職の一部（segment of jobs））に関連する場所に興味を持っている可能性が非常に高い。しかしながら、通常のほとんどの検索エンジンは、これらの語がこの検索フレーズにおいて出現する順序に関係なく、単に、「New」、「York」、「City」、「law」及び「enforcement」という個々の語を用いて検索をするに過ぎない。他の通常の検索エンジンは、インデックスにも出現する、検索フレーズにおける最も長いサブストリングを探そうとする。例えば、インデックスが、「New York」、「New York City」及び「New York City law」を含むが、「New York City law enforcement」を含まない場合には、検索エンジンは、「New York City law」及び「enforcement」を用いて検索をし、これは、必ずしもユーザが意図したものになるとは限らず、また、最適な結果を生成しそうもない。

検索サーバシステム１６０は、好ましくは、「New York City law enforcement（ニューヨーク市の法律施行）」のような問い合わせの中から、「New York City」及び「law enforcement」という概念を検出して、これら２つの概念についての結果を返すように構成される。いくつかの実施形態では、検索サーバ１６０は、検索語が問い合わせの中において存在している順序を用いて、その検索語が作り上げている概念を認識する。例えば、検索フレーズとしての「New York City law enforcement」を用いて、本システムは、例えば、ハッシングにより、この検索フレーズ中の２つの概念としての「New York City」及び「law enforcement」を認識して、これらの概念についての結果を返す。これと同一の結果が、「city law enforcement in New York（ニューヨークにおける都市法律施行）」についても返される。しかしながら、「law enforcement in New York City（ニューヨーク市における法律施行）」については、「law enforcement（法律施行）」、「New York（ニューヨーク）」及び「city（都市）」という概念、又は、「city law enforcement（都市の法律施行）」及び「New York（ニューヨーク）」という概念に基づいた異なる結果が返される。同様に、「enforcement of law in New York City（ニューヨーク市における法律の施行」は、「New York City（ニューヨーク市）」、「law（法律）」及び「enforcement（施行）」という概念を含むものとして識別される。このように、複数の概念の順序は、概念を作り上げる語の順序ほどは重要ではない。いくつかの実施形態では、概念がページインデックスに（例えば、語及び／又はコンテキストの識別子として）含まれ、或いは、別個の概念インデックスを実装することができる。「law enforcement（法律施行）」は、「enforcement of law（法律施行）」と同一であるとみなされるか、或いは、コンテキストに依存しないとみなされる、ということに留意すべきである。いくつかの実施形態では、１つの問い合わせ内の複数の概念が、好ましくは、既知の概念（又は「ユニット」）のリストを含むユニット辞書１７２に対する参照により検出される。

ユニット辞書１７２は、好ましくは、いくつか（好ましくは、例えば少なくとも数百・数千といったような多数）の以前の（過去の）問い合わせに基づいた概念発見処理によって生成される。例については後述する概念辞書は、概念ネットワークを生成するために問い合わせを分析することを含み、検索サーバ１６０又は別のサーバ（図示しない）によって実行されるものとすることができる。

本明細書で記載するように、「概念ネットワーク」という用語は、複数の概念の間における関係の表現を含む。例えば、図３が、少数の概念についての概念ネットワークを図示している。各概念又はユニット（例えば「New」、「York」、「New York City」等）は、このネットワークにおける「ノード」（例えばノード３０２）であり、概念との間における様々な関係を表現する「エッジ（edge）」（例えばエッジ３０４）によって他のノードと接続されている。概念ネットワークは、いろいろな関係を取り込むことができる。図３に示す実施形態では、関係は、拡張（extension）と、結合（association）と、代替（alternative）とを含うが、ここで記載したこれらに加えて或いはこれらに代えて、他の関係を取り込むこともできる。

本明細書で用いる「拡張」は、２つのユニットを連結することによって得られた文字列もまたユニットとなるときに存在する２つのユニットの間の関係である。例えば、ユニット「new york」とユニット「city」とを連結することによって得られた文字列は、「new york city」であり、この「new york city」もまたユニットである。拡張の関係は、図３には、拡張によって関連する２つのユニット（例えば「new york」及び「city」）を接続する横棒（crossbar）と、拡張ユニット（例えば「new york city」）に接続する茎（stem）とを有する「Ｔ」接合として示されている。

本明細書で用いる「結合」は、複数の問い合わせにおいて一緒に出現する２つのユニット間に存在する関係である。例えば、図３は、ユニット「hotel」が、ユニット（new york）とユニット（new york city）との結合となっている。結合したユニットの複数対が、本明細書では「隣接語（neighbors）」として称され、その隣接語の組がユニットの「隣接語集合（neighborhood）」である。複数のユニットの間において結合を確立するためには、共同発生の最小頻度が必要とされる。結合によって関連した複数のユニットは、問い合わせにおいて互いに隣接して出現する必要がなく、また、結合した複数のユニットを連結することにより得られる文字列は１つのユニットである必要がない、ということに留意されたい（もしそうであるならば、拡張の関係は存在しなくなる。よって、拡張の関係は、特別な種類の結合としてみなすことができる）。

最初のユニットの「代替」は、同一表現に対する異なった形（好ましい形、訂正した形又は他の違った形とすることができる）である。例えば、図３は、「motel」と「hotel」とが代替であることを示している。代替の他の例は、「brittany spears」と「britney spears」（異なる綴り）、又は、「belgian」と「belgium」（話し方の異なる部分）である。１組の代替ユニットのうち一方を例えば出現頻度に基づいた「好ましい」ものとして指定することができ、例えば、「britney spears」（人気歌手の名前の正確な綴り）は、「brittany spears」のような誤って綴られた代替に対する好ましい代替とすることができる。本明細書で説明する実施形態は、場面による影響を受けないものであり、大文字使用のみしか異ならない語（たとえば、「Belgium」及び「belgium」)は、同一のユニットを示し、他の実施形態は、場面に基づくユニットを区別することができ、大文字使用のみしか異ならないユニットを代替として認識することができる。

いくつかの実施形態では、概念ネットワークにおけるエッジに対して、（図３には示していない）ウェイト、すなわち、異なる関係に対する関連強度を示す数値を割り当てることができる。例えば、第１のユニットとこれに結合したユニットとの間におけるエッジのウェイトは、この第１のユニットを含みさらにこの結合したユニットをも含むすべての問い合わせに対する割合に基づいて、又は、一方のユニットを含みさらに他方のユニットをも含むすべての問い合わせに対する割合に基づいて、決定することができる。ウェイトは、好ましくは、関連強度を反映し、したがって、ウェイトは、所望のいかなる方法によっても正規化することができる。図３は例示的なものであり、他の関係を、異なるユニット同士及び異なる概念同士の間の接続又は関係について他の表現とともに用いることもでき、本明細書で使用した「概念ネットワーク」という用語は、別の表現を包含する、ということが理解できよう。

本発明の実施形態では、概念ネットワークにおいて表現した関係はまた、「スーパーユニット」において様々なユニットのメンバーシップ（membership）をも含む。本明細書において用いる「スーパーユニット」という用語は、認識された共通の特性を有する１組のユニットを示す。この識別された共通の特性（多数の要素を含むことができる）は、別のユニットがスーパーユニットに属するか否かを決定するために用いることができる、スーパーユニットの「署名」によって表現される。いくつかの実施形態では、署名はまた、各メンバーユニットの特性と署名の特性との間における類似度に基づいた、各メンバーユニットについての「メンバーシップウェイト」を決定するためにも用いられる。メンバーシップウェイトの閾値を定めることができ、スーパーユニットは、ウェイトがこの閾値を超えたユニットのみを含むことができる。

例えば、１つのスーパーユニットが都市（例えば「New York City」、「San Francisco」や「Chicago」等）により構成されており、そのスーパーユニットの署名が、都市の名前に関連した問い合わせ（例えば、「hotel」、「museum」、「mayor」や「job」等）に頻繁に出現するいくつかの数の他のユニットを含むことができる。新しいユニットは、評価されて、その代替をその署名と比較することにより、都市であるかどうかを（すなわち、そのスーパーユニットのメンバーであるかどうかを）決定することができる。別の例として、別のスーパーユニットが互いに代替であるユニット（例えば、「britney spears」、「brittany spears」や「britney speers」等）により構成され、そのスーパーユニットの署名が、綴りにおいて類似性を示す「編集距離（edit distance）」に対してだけでなく、その歌手の名前に対しても結合するユニット（例えば、「photos」、「mp3」や「旅行」等）を含むことができる。類似した結合ではあるが大きな編集距離を有するユニット（例えば、「barbra streisand」又は「celine dion」）は、除外される一方、Britney Spearsの他の綴り間違いは含まれる。問い合わせからスーパーユニット及び署名を生成する具体的な方法は、以下の通りである。ユニットの他の関係と同様に、様々なユニットについてのスーパーユニットの署名及びスーパーユニットのメンバーシップ情報（例えばメンバーシップウェイト）を、ユニット辞書１７２に記憶することができる。

いくつかの実施形態では、スーパーユニットの署名の異なる要素に対して、異なるウェイトを割り当てることができる。このウェイトは、好ましくは、そのスーパーユニットを特徴付ける際に、異なる署名の要素の相対的な有効性を反映するように選択される。

検索サーバ１６０は、好ましくは、例えば、問い合わせ中のユニットがどのスーパーユニットに属するかを決定することにより、また、その問い合わせにおけるそのユニットをそれらのスーパーユニットの署名と比較してユーザが最も意図していそうなものを決定することにより、問い合わせに応答してスーパーユニット情報を用いる。検索サーバ１６０は、ユーザが持っていそうな意図に関するこの情報を用いて、例えば、検索結果を構成し、関連した検索等を提案することができる。検索サーバ１６０のこれらの特徴については、セクション３において説明する。

２．概念分析システム
図４は、本発明の一実施形態に係る、スーパーユニット生成を含めて概念発見又は概念分析を実行するシステム４００のブロック図である。１又はそれ以上のログファイル４０２（又は実際の問い合わせ）が、ユニット辞書を生成する問い合わせ処理エンジン（「問い合わせエンジン」ともいう。）４０４により受信される。問い合わせエンジン４０４は、検索サーバシステム１６０（図２）における１つの構成要素とすることができ、或いは、検索サーバシステム１６０と通信する別のシステムとすることができる。１つの実施形態では、問い合わせエンジン４０４は、概念ネットワーク（ＣＮ）構築部４１０と、スーパーユニット種モジュール４１２と、スーパーユニット構築部４１４とを含む。ＣＮ構築部４１０は、問い合わせログファイル４０２の内容を分析し、ユニットと、ユニット間の関係（例えば、拡張、結合及び代替）と、その関係に対するエッジウェイトとを含む概念ネットワーク４０８を生成する。スーパーユニット種モジュール４１２は、複数のユニットを複数のスーパーユニットに対して準備的にグルーピングしたもの（ここでは「種」という）を、選択的には、概念ネットワーク４０８の分析により生成する。スーパーユニット構築部４１４は、スーパーユニット種モジュール４１２により与えられた種を用いて概念ネットワーク４０８を処理して、多数のスーパーユニットを生成する。複数のユニット及びそれらの関係は、複数のスーパーユニットを含めて、ユニット辞書４０６に取り込まれる。

ユニット辞書４０６は、任意のフォーマットにより実現することができ、磁気ディスク若しくはテープ、コンパクトディスク（ＣＤ）のような光学記憶媒体等を含む、任意の適切な記憶媒体に記憶することができる。ユニット辞書４０６の内容は、好ましくは、複数のユニットを、関係（例えば、拡張、結合、代替）、ＣＮ構築部４１０により生成された統計的データ（例えばエッジウェイト）、スーパーユニット構築部４１４により決定されたスーパーユニットメンバーシップ（例えばメンバーシップウェイト）といったような、各ユニットに関する付加的な情報とともに含む。ユニット辞書４０６はまた、１つのスーパーユニットに結合した１つの署名というパラメータといったような、複数のスーパーユニット自体に関連した情報を含むことができる。ユニット辞書４０６に記憶された情報は、検索サーバ（例えば図２の検索サーバ１６０）により利用されて、この後に発生する問い合わせに応答することができる。

問い合わせログファイル６０２（又は実際の問い合わせ）は、インターネットを介して、又は、例えば、ＬＡＮ、ＷＡＮ、直接リンクといった様々なネットワーク接続や流通媒体（例えばＣＤ、ＤＶＤ、フロッピーディスク）等を介して、様々なソースから受信することができる。ソースの例は、検索サーバシステム１６０（図２）、又は、検索サーバの分散型ネットワークにおける多数の検索サーバ１６０、及び、１又はそれ以上のコンテンツサーバ１５０である。問い合わせログファイルのソースは、典型的には、同一の組織又はエンティティ、例えばＹａｈｏｏ！サーバに結合しているが、これに限られない。問い合わせログファイル（「問い合わせログ」ともいう。）は、情報理論又は相互情報量といった概念において用いることができるような統計的方法を用いて、問い合わせエンジン４０４により処理される。いくつかの実施形態では、１日単位の問い合わせログが用いられるが、異なる時間周期、例えば、時間や週等の異なる時間周期についてのログを、所望により用いることができる。問い合わせログは、典型的には、ユーザによって提出された実際の問い合わせ（例えばテキスト文字列）を含み、それら問い合わせのうちのいくつか又は全部についての付加的な情報（ここでは「メタ情報」という。）、例えば、問い合わせをしているユーザの地理的位置、タイムスタンプ、クライアントシステムのＩＰアドレス、クッキーやクライアントの型（例えばブラウザの型）といったような情報をも含むことができる。例えば、問い合わせログへの登録項目（エントリ）は、<query_string,meta-information>又は<count,query_string>としてフォーマットすることができる。ここで、「count」は、発生頻度を表す（頻度は正規化することができるが、所望により正規化しなくともよい）。

Ａ．概念ネットワーク構築部
ＣＮ構築部４１０が、問い合わせログ４０２を処理して、概念ネットワーク４０８を生成する。好ましい実施形態では、ＣＮ構築部４１０が、１つの問い合わせ内の検索語の順序を用いて、その問い合わせを構成する１又はそれ以上のユニットを識別する。例えば、１つのユニットは、１つの単語（例えば「java」）とすることができ、或いは、互いに隣接して頻繁に出現する単語のグループ（例えば「new york city」）とすることができる。このユニットは、概念ネットワークにおけるノード（概念）に対応する。

ＣＮ構築部４１０はまた、ユニットを分析して、（別の語若しくはユニットが時には後に続き又は時には後に続かない１つの単語又はユニットに基づいて検出することができる）拡張、（複数対のユニットの発生頻度に基づいて検出することができる）結合及び（「編集距離」すなわち１つのユニットから別のユニットに変換するのに必要とされるタイプ上の変化数に基づいて検出することができる）代替といったような関係を検出する。複数のユニット及び複数のユニット間の関係を認識する特定の技術は、上記の通り参照した出願番号第１０／７１３,５７６号において詳細に記載されている。ＣＮ構築部４１０がまた、概念ネットワーク４０８を生成するために本明細書で記載した技術に加えて又はこれら技術に代えて他の技術を実装することができる、ということが理解できよう。

概念ネットワーク４０８の表現はユニット辞書４０６に記憶することができる。いくつかの実施形態では、この表現は、複数のユニットを、各ユニットについての複数セットの関係及びウェイトとともに含む。ユニット辞書４０６におけるこの情報を表現するために、様々なデータ圧縮技術を用いることができる。

Ｂ．スーパーユニット種モジュール
スーパーユニット種モジュール４１２は、スーパーユニットの構築の元にすることができる１又はそれ以上の種を生成する。本明細書で用いる通り、「種」は、１つのユニットとすることができ、或いは、１又はそれ以上の特性を有するユニットのリストとすることができる。スーパーユニット種モジュール４１２は、複数の種を生成するために様々な技術を用いることができる。ここで、このような技術の４つの例は以下の通りである。すなわち、４つの技術の例は、（１）概念ネットワーク４０８の分析、（２）外部ソースの参照、（３）ユーザの振る舞いの分析、及び、（４）検索コーパス内の文書の分析、である。１つのユニットが１つの種として用いられ、スーパーユニット種モジュール４１２が単に種として用いるべきいくつかの数のユニットを（例えば、発生回数、隣接語集合のサイズ又は他のいくつかの基準に基づいて）概念ネットワーク４０８から選択することができる。

１．概念ネットワークに基づいた種（クラスタ（Clusters）及びクリーク（Cliques））
１つの実施形態では、スーパーユニット種モジュール４１２は、さらに、概念ネットワーク４０８を用いて問い合わせの分析を実行し、種として用いることができるクラスタ（すなわち関連するユニットのグループ）を生成する。この実施形態では、クラスタは、類似した隣接語集合（すなわち、結合した複数のユニットの組）を有する異なるユニット（クラスタにおける「メンバ」）を識別することによりユニットから生成される。クラスタは、スーパーユニットの生成のための種として用いることができるが、理解できるように、クラスタ自体をスーパーユニットとすることもできる。

例えば、ユーザがお気に入りの音楽演奏家に関する情報を検索する場合を考える。典型的には、これらユーザは、この演奏家の名前（例えば、「アヴリル・ラビーン（Avril Lavigne）」、「セリーヌ・ディオン（Celine Dion）」又は「マッチボックス・トゥエンティ（Matchbox twenty）」）、及び、「歌詞」、「mp3」、「ギタータブ」、「ディスコグラフィー」等のような、探そうとしている情報のタイプを反映するいくつかの他の単語をも含む問い合わせを構築し、これらの他の単語は、異なる演奏家の名前と一緒に出現する傾向のある隣接語ユニットである。類似した隣接語ユニットの発生に基づいて、スーパーユニット種モジュール４１２は、その演奏家の名前を１つのクラスタにグループ化する。

さらに具体的に説明すると、図５は、概念ネットワーク４０８からクラスタを生成するためにスーパーユニット種モジュール４１２によって実行することができる処理５００のフロー図である。ステップ５０２において、概念ネットワーク４０８が、スーパーユニット種モジュール４１２に与えられる。

ステップ５０３において、クラスタを形成するためのベースユニットが選択される。いくつかの実施形態では、概念ネットワークにおけるすべてのユニットは、ベースユニットとして用いることができる。他の実施形態では、ベースユニットは、例えば、少なくともいくつかの最小限の頻度で発生するユニットに限定することができる。異なるベースユニットを用いて処理５００を繰り返すことにより、任意の数のクラスタを生成することができる、ということを理解されたい。

ステップ５０４において、概念ネットワーク４０８における別のユニットが、そのベースユニットを有するクラスタに含まれるための候補ユニットとして選択される。すべての対のユニットを選択するために反復処理を用いることができ、或いは、選択の対象を特定の基準を満たすユニットのみに限定することができる。例えば、１つの実施形態では、概念ネットワーク４０８は、特定のユニットの結合と、様々な隣接語ユニットとを含む。この実施形態では、ステップ５０４は、ベースユニットの隣接集合と第２ユニットとを比較して、重複の度合いを決定することを含むが、その度合いが小さい場合には、第２ユニットは、候補ユニットにはならない。この実施形態では、考慮の対象とするユニットの選択は、ベースユニットＢから始めて、隣接語ユニットＡを見つけた後、Ａの隣接語でもある第３ユニットＣを見つけることにより、簡略化される。ユニットＢ及びＣの隣接語集合を比較することによって、ユニットＣが、ユニットＢを有するクラスタに含めるための候補ユニットとして選択するかどうかを決定することができる。この手順によれば、存在しうる候補ユニットの組を、ベースユニットに共通する少なくとも１つの隣接語を有するユニットに減らすことができる。

ステップ５０６において、ベースユニット及び候補ユニットの両方と一緒に発生する隣接語の例が識別される。例えば、「アヴリル・ラビーン」及び「マッチボックス・トゥエンティ」がベースユニット及び候補ユニットである場合には、共通の隣接語ユニットは、「歌詞」や「ディスコグラフィー」等を含む。ベースユニット及び候補ユニットと一緒に発生する隣接語ユニットは、本明細書では「一致（matched）」ユニットという。

ステップ５０８では、候補ユニットに対するクラスタ化（clustering）ウェイトが、一致ユニットを含んだ隣接語ユニットに基づいて計算される。このクラスタ化ウェイトは、候補ユニットとベースユニットとの間における類似性の目安となり、このクラスタ化ウェイトは、様々な方法により計算することができる。ここで、クラスタ化ウェイトを計算するための適切なアルゴリズムの５つの例を説明するが、当業者であれば、他のアルゴリズムをも用いることができるということを認識できる。

＜例１＞
１つ目のアルゴリズムは、類似性の目安として一致ユニットの数を考慮に入れる。ユニットｕ₁及びｕ₂に対するクラスタ化ウェイトは、次の（１）式により定められる。
Ｗ（ｕ₁,ｕ₂）＝Ｎ_C／Ｎ_T （１）
ここで、Ｎ_Cは一致ユニットの数であり、Ｎ_Tは、ユニットｕ₁についての隣接語ユニットの総数及びユニットｕ₂についての隣接語ユニットの総数のうちの大きい方である。

変形させることも可能である。例えば、Ｎ_Tは、上記２つの総数のうちの（大きい方に代えて）小さい方として定めることもでき、或いは、上記２つの総数の平均として定めることもできる。

＜例２＞
第２のアルゴリズムは、あらゆる一致ユニットについて頻度（よって、隣接語ユニットが１つのユニットにとってどれだ重要であるか）を考慮に入れる。ユニットｕ₁及びｕ₂は、次の（２）式により定められる。
Ｗ（ｕ₁,ｕ₂）＝Ｆ_M／Ｆ_T （２）
ここで、Ｆ_Mは、すべての一致ユニットｓｉにわたって、ユニットｓ_iがユニットｕ₁と一緒に発生する頻度及びユニットｓ_iがユニットｕ₂と一緒に発生する頻度の合計であり、Ｆ_Tは、一致ユニット又はそうでないユニットのすべての隣接語ユニットにわたる同一の頻度の合計である。

＜例３＞
一致ユニットがユニットｕ₁と一緒に発生する相対的な頻度と、一致ユニットがユニットｕ₂と一緒に発生する相対的な頻度とが異なるような場合に、ペナルティ（ウェイトの減少）が課されるという点において、相対的な頻度は、重要度についての別の目安である。この例では、Ｒ１ｉ及びＲ２ｉが、それぞれ、隣接語ユニットｓ_iがユニットｕ₁と一緒に発生する相対的頻度、及び、隣接語ユニットｓ_iがユニットとｕ₂一緒に発生する相対的頻度として定められる。クラスタ化ウェイトは、次の式（３）により与えられる。

ここで、上記合計が一致ユニットｓｉの上にかけられ、Ｐは、相対的な頻度同士の間にウェイトをかけるペナルティ要素である。Ｐの値は変化させることができるものであるが、１つの実施形態では、Ｐ＝２である。

＜例４＞
頻度（ランク）の減少する順序で隣接語ユニットを比較することが、重要性を測定するための別の方法である。例３と同様に、一致ユニットのランクにおける相違に対してペナルティが付加される。各一致ユニットｓ_iには、それぞれ、ユニットｕ₁及びユニットｕ₂とともにそのランクを示す、２つのランクＱ１ｉ及びＱ２ｉが割り当てられる。クラスタ化ウェイトは、次の（４）式により与えられる。

ここで、Ｍは、ユニットｕ₁についての隣接語ユニットの総数及びユニットｕ₂についての隣接語ユニットの総数のうちの小さい方であり、その合計が、一致ユニットｓ_iの上にかけられる。

＜例５＞
上述したアルゴリズムとは異なり、このアルゴリズムは、隣接語ユニットの差別的なパワー（discriminatory power）を考慮に入れる。任意のユニットｕについての「関連性（Relevance）」は、そのユニットが１つの問い合わせ（ｆｕ）内の１又はそれ以上の他のユニット（どのようなユニットであってもよい）と一緒に出現する頻度と、そのユニットが１つの問い合わせ（ｆｑ）内で単独で出現する頻度とを比較することにより、定めることができる。１つの測定では、関連性は、ρ（ｕ）＝ｆｕ／ｆｑにより与えられる。

この関連性の算出は、上述した相対的な頻度の考えと組み合わせて、クラスタ化のウェイトを計算することができる。「スコア」σが、各一致ユニットｓ_iに対しその相対的な頻度に基づいて、具体的には、σ（ｓ_i）＝１−（Ｒ１ｉ−Ｒ２ｉ）により与えられる。ここで、Ｒ１ｉ及びＲ２ｉは、上述した例３におけると同様に定められる。クラスタ化ウェイトは、次の式（５）により与えられる。

定数Ｃの値は、経験値に基づいて最適化することができ、１つの実施形態では、Ｃ＝０.５である。

図５を参照すると、ステップ５１０では、ベースユニットを有する１つのクラスタ内に候補ユニットを含めるかどうかについての決定がなされる。例えば、１つのユニットは、そのクラスタ化ウェイトが低すぎる場合には、１つのクラスタから除外することができる。

いくつかの実施形態では、複数対のユニットに対するクラスタ化を中止することができる。他の実施形態では、異なる候補ユニットを選択し、ステップ５０６、５０８及び５１０を繰り返すことにより、より大きなクラスタが形成される。さらに別の実施形態では、２又はそれ以上のクラスタが、ベースユニットの代わりに用いられて、より大きなクラスタを生成することができる。１つのクラスタが１つのベースユニットとして用いられる場合には、その隣接語集合は、例えば、メンバーユニットの隣接語集合に対する合併集合演算（union）又は共通部分演算（intersection）、メンバーユニットのうちの少なくともいくつかの最小割合（例えば２５％、５０％、８０％）の隣接語であるユニットのセット等の様々な方法により定めることができる。クラスタは、サイズとは無関係に、スーパーユニット種として用いることができる。

いくつかの実施形態では、クラスタは、さらに、メンバーユニット同士の間においてより強力な又はより近接した関係を有する「クリーク（cliques）」に向上させることができる。１つの実施形態では、「クリーク」は、あらゆるメンバーユニットが他のあらゆるメンバーユニットから形成されたクラスタ内に存在するような場所にある、１組のユニットである。クリークは、例えば、綴り誤り及び代替となる単語の形を識別すること、或いは、クラスタが形成されている周りのベースユニットの異なる単語の意味を識別することのような様々な目的のために用いることができる。例えば、ベースユニットが「New York」であるクラスタは、他の都市の名前（例えば「Boston」や「Seattle」等）であるユニットを含むことができ、また、同一の都市に関する別の名前（例えば「NY」や「NYC」）であるユニットをも含むことができる。これらのユニットから、異なる都市を含むクリーク（「New York」、「Boston」や「Seattle」）及び、「New York City」についての別の名前を含む異なるクリーク（「New York」、「NYC」や「NY」）を、形成することができる。

別の例として、ベースユニット「Yahoo」を有するクラスタは、他の電子メールプロバイダ（例えば「AOL」や「Hotmail」）の名前を、他の検索エンジンの名前（例えば「Google」）とともに含むことができる。ベースユニット「Google」を有するクラスタは、「Yahoo」を含むことができるが、「AOL」又は「Hotmail」を含まない。よって、「Yahoo」及び「Google」は、１つのクリークにおけるメンバとなることができるが、「Yahoo」、「AOL」及び「Hotmail」は、別のクリークにおけるメンバとなることができる。

図６は、本発明の一実施形態に係る、クラスタのグループからメンバユニットｑ_kを有するクリークＱを形成するために用いることができる処理６００のフロー図である。これらの例では、クラスタの番号Ｎが形成されており、各クラスタは、異なるベースユニットｂ_i（１≦ｉ≦Ｎ）を有する。ここでは、クラスタはＣ（ｂ_i）として表記され、クラスタＣ（ｂ_i）のメンバであるユニットｕは、Ｗ（ｕ、ｂ_i）で表記されたクラスタ化ウェイトを有し、このクラスタ化ウェイトは、例えば、上記の通り与えられた数式のいずれかを用いて計算することができる（クラスタＣ（ｂ_i）内にないユニットｕについては、ウェイト（ｕ、ｂ_i）には、値０を割り当てることができる）。与えられたユニットは、任意の数のクラスタＣ（ｂ_i）のうちのメンバとすることができ、いくつかの例では、クラスタＣ（ｂ_i）は、ベースユニットｂ_iのみにより構成することができる、ということを理解されたい。処理６００では、メンバｑ_kを有するクリークＱ（ｂ_i）が、クリークＱ（ｂ_i）の第１メンバとしてベースユニットｂ_iから開始し、（１）クリークＱにおけるすべてのメンバｑ_kはクラスタＣ（ｕ_j）における要素であること、（２）ユニットｕ_jはクリークＱにおける各メンバｑ_kについてのクラスタＣ（ｑ_k）の要素であること、を満足するＣ（ｂ_i）における他のユニットｕ_jを見つけることにより形成される。

より具体的には、ステップ６０２では、クリークＱが１つのメンバｂ_iとともに形成される。ステップ６０４では、クラスタＣ（ｂ_i）における次のメンバユニットｕ_iが得られる。ステップ６０６では、クラスタＣ（ｕ_j）が得られる。ステップ６０８では、クリークＱにおけるすべてのメンバがクラスタＣ（ｕ_j）のメンバでもあるかどうかが決定される。そうでなければ、ユニットｕ_jはクリークｑには加えられず、処理６００は、ステップ６１６にジャンプする。或いはまた、ステップ６１０では、クリークＱにおける各面罵ｑ_kについて、クラスタＣ（ｑ_k）が得られる。ステップ６１２では、ユニットｕ_jがステップ６１０で得られた各クラスタＣ（ｑ_k）であるかどうかが決定される。ステップ６１０及び６１２は、クリークＱにおけるメンバｑ_kにわたって繰り返すことにより実行することができ、或いは、多数のメンバｑ_kについてのクラスタは、並行して試験することができる。ユニットｕ_jがステップ６１０で得られたあらゆるクラスタＣ（ｑ_k）内にない場合には、ｕ_jはクリークＱには付加されず、処理６００はステップ６１６にジャンプする。ユニットｕ_jがあらゆるクラスタＣ（ｑ_k）内にある場合には、ユニットｕ_jがステップ６１４においてクリークＱに付加される。

ステップ６１６では、ユニットｕ_jがクリークＱに付加されたかどうかにかかわらず、１又はそれ以上のユニットｕ_jがクラスタＣ（ｂ_i）内に残っているかどうかが決定される。そうであれば、処理６００は、ステップ６０４に戻り、次のメンバユニットｕ_jを処理する。

すべてのユニットｕ_jが処理された後、ステップ６１８では、クリークＱにおける各メンバｑ_kについてメンバーシップスコアが決定される。１つの実施形態では、そのスコアは、クリークＱにおける他のメンバユニットの各々に基づいてクラスタ内のユニットｑ_kのクラスタ化ウェイトを付加することによって、次の式（６）により計算される。

ここで、Ｗ（ｑ_k、ｑ_i）は、クラスタＣ（ｑ_i）のメンバとしてのユニットｑ_kに対するクラスタ化ウェイトを示す。クリークメンバーシップスコアを割り当てるために、他の数式を用いることもできる。いくつかの実施形態では、クリークメンバは、スコアの降順又は昇順に従って並べることができる。

本明細書で説明した処理は例示的なものであり、変形及び変更が可能である、ということを理解できよう。時系列で記載した複数のステップは、並列に実行することができ、複数のステップの順序は変更することができるものであり、また、複数のステップは変更又は結合することができるものである。（ステップ６０８において）クリークＱにおけるメンバｑ_kのうちの少なくとも割合ｆ１が、クラスタＣ（ｕ_j）の要素であること、又は、（ステップ６１２において）ｕ_jがクラスタＣ（ｑ_k）のうちの少なくとも割合ｆ２の要素であることという要求に対して、例えば１つのユニットを１つのクリークに加えるための条件を緩和することができる。割合ｆ１及び／又はｆ２は、所望の通りに選ぶことができ、また、例えば、５０％、７０％、９０％等とすることができ、２つの割合は、様々な実施形態において、等しくすることもでき或いは等しくしないこともできる。処理６００を異なるベースユニットｂ_iに対して繰り返して、任意の数のクリークを生成することができる。クリークが生成された場合には、クリークは、クラスタに代えてスーパーユニット種として用いることができ、或いは、クリークとクラスタとの組み合わせをスーパーユニット種として用いることができる。

２．外部ソースに基づく種
別の実施形態では、スーパーユニット種モジュール４１２が、１又はそれ以上の外部ソース（図４においてブロック４１６として概略が示されている）を参照することによって種を生成する。外部ソースの例は、編集者又は編集者チームにより生成された関連した語のリスト（例えば、人気歌手のリスト、又は、そのチームに知られている自動車製造業者のリスト）と、権威あるウェブサイト（例えば、辞書又は他の病気の一覧表を維持する医学的参照サイト）等を含む。この実施形態では、スーパーユニット種モジュール４１２は、外部ソースデータに対してほとんど又は全く処理を実行しない。例えば、単語のリストが編集者チームによって供給された場合には、スーパーユニット種モジュール４１２が短にそのリストをスーパーユニット構築部４１４に転送することができる。スーパーユニット種モジュール４１２はまた、そのリストを簡潔にして（prune）、概念ネットワーク４０８内のユニットではないエントリを除去することもできる。このようなスーパーユニット種は、網羅的なリストとする必要がなく、少数の（例えば２つ、４つ又は６つの）ユニットを含むことができる、ということに留意されたい。

３．ユーザの振る舞いに基づく種
第３の実施形態では、スーパーユニット種モジュール４１２は、ユーザの振る舞いを分析することにより種を生成する。例えば、検索サーバ（例えば図２のサーバ１６０）は、問い合わせに応答して、クライアント１２０に対して検索結果ページを提供する。この検索結果ページは、「ヒット」（この問い合わせに関連するコンテンツを含むウェブページ又はサイトへのリンク）のリストを含む。ヒットのリストは、例えば、関連するコンテンツ及び／又は他の情報を示すページタイトル、抜粋を含むことができる。このユーザは、そのリストを検討し、表示されたリンクをクリックすること等によりヒットを選択する（この動作は「クリックスルー」といわれるが、リンク及びクリック操作が不要であるということを理解されたい）。問い合わせログ４０２は、ユーザが検索結果ページから辿ってきたリンクを示す問い合わせのいくつか又はすべてについて、クリックスルーデータを供給することができる。スーパーユニット種モジュール４１２は、このデータを受信して、異なる問い合わせを入力したユーザが同一のページに対してクリックスルーしている段階を認識することができる。このユーザの振る舞いは、複数の問い合わせの間の共通性を提案し、種モジュール４１２は、類似した（又は同一の）クリックスルー振る舞いを有する問い合わせ（又はその問い合わせから選択されたユニット）を種にグループ化することができる。種モジュール４１２は、好ましくは、ページの関連性を提案する振る舞いパターンが検出されたとき（例えば、特定の最小頻度において特定のページへのクリックスルーが起きたとき）にのみ問い合わせ（又はユニット）をグループ化するように構成される。

４．文書の分析に基づく種
第４実施形態では、種モジュール４１２は、検索コーパス（例えば、ウェブ検索の実施形態においてはウェブページ）内の１又はそれ以上の「ソース」文書を分析することにより種を生成する。この実施形態では、種モジュール４１２は、複数のユニット間の共通性を、それらが同一文書に出現することに基づいて推定する。例えば、種モジュール４１２は、例えば、テキスト文字列をユニット辞書４０６内のエントリ又は概念ネットワーク４０８内のユニットと一致するものを見つけることにより、１つの文書を解釈して構成ユニットに分割することができる。１つの実施形態では、文書内で発見されたユニットのすべては、１つの種リストに集約される。別の実施形態では、それらユニットは、最小発生頻度を必要とすることにより、複数対の（又はさらに大きいグループの）ユニットが互いに近接して出現した場合にのみこれら複数対のユニットを含ませること等により、フィルタリングされる。ユニットの結果リストは、スーパーユニット種として用いることができる。文書の分析は、任意の数のソース文書を用いて実行することができ、また、分析の対象とする文書を自動的又はマニュアルで選択するために様々な基準を用いることができる。

上述した種モジュール４１２の実施形態は例示的なものであってこれに限定されない、ということを理解されたい。種は、上述した技術若しくは他の技術のうちの１若しくはそれ以上のものを用いて、又は、これら技術を組み合わせて、生成することができる。さらに別の実施形態では、各ユニット（又は、そのユニット、例えば最も頻発するユニットのいくつかのサブセットの各々）は、別々の種として用いることができる。

Ｃ．スーパーユニット構築部
どのように種が生成されるかに関係なく、種モジュール４１２は、その種をスーパーユニット構築部４１４に与え、このスーパーユニット構築部４１４は、その種とＣＮ構築部４１０により生成された概念ネットワーク４０８とを用いてスーパーユニットを構築する。いくつかの実施形態では、スーパーユニットは、署名（すなわち、種におけるユニットが共通して有する傾向のある１又はそれ以上の関係）を識別し、その署名と一致する概念ネットワークにおける付加的なユニットを検索し、これらユニットをそのスーパーユニットに付加し、さらに、そのスーパーユニットの現在の内容を反映するようにその署名を修正する、といった処理を繰り返すことにより、構築される。

さらに具体的には、図７は、本発明の一実施形態に係るスーパーユニット構築部４１４において実装することができるスーパーユニットを生成する処理７００のフロー図である。ステップ７０２において、スーパーユニット構築部４１４は、種モジュール４１２から種を受信する。

ステップ７０４において、その（初期）スーパーユニットについての署名が、決定される。その署名は、好ましくは、そのスーパーユニットの１又はそれ以上のユニットに関連する１組のユニットに基づいて定められ、この署名のユニットのいずれも、そのスーパーユニットのメンバではない。例えば、スーパーユニット構築部４１４は、そのスーパーユニットにおけるメンバユニットを概念ネットワーク４０８に配置することができ、各面罵ユニットにおける隣接語ユニットを比較して、どの隣接語ユニットがそのメンバユニットと共通している（かつ、それ自体がメンバユニットではない）かを決定することができる。１つの実施形態では、署名ユニットは、好ましくは、２つの基準に基づいて選択される。すなわち、２つの基準とは、（１）スーパーユニットのメンバがその署名ユニットの隣接語であることについての確からしさ、（２）その署名ユニットの隣接語がそのスーパーユニットのメンバであることについての確からしさ、である。これらの基準は、スーパーユニットにおけるメンバと非メンバとの間における効果的な判別要素となる傾向を有する署名ユニットを識別する。

第１の基準の例として、署名ユニットは、メンバユニットのうちの少なくとも５％（又は１０％又は５０％）との間で特定の関係を有することを必要とされ、或いは、メンバユニットのうちのいくつかの割合に対する署名ユニットの関係が最小限のエッジウェイトを有することを必要とされ、或いは、署名ユニットとメンバユニットとの間におけるエッジウェイトの合計がいくつかの閾値を超えることが必要とされる。いくつかの実施形態では、署名ユニットは、スーパーユニットのメンバユニットと各署名ユニットとの間の関係についての平均エッジウェイト（又はエッジウェイトの分布）を反映することができるウェイトの範囲に結合している。

第２の基準の例として、署名ユニットにおける隣接語ユニットのうちの最小の割合が、スーパーユニットのメンバであることを必要とすることができ、或いは、署名ユニットとメンバユニットとの間の関係についてのエッジウェイトと、署名ユニットと非メンバユニットとの間の関係についてのエッジウェイトとが、特定の関係を満たすことが必要とすることができる。さらに署名の定義の例を以下に説明する。

ステップ７０６では、候補ユニット、すなわち、スーパーユニット内又は署名内にないユニットが、評価されて、その候補ユニットがその署名と一致するかどうかが決定される。候補ユニットは、その候補ユニットの署名ユニットに対する関係が事前に確立された基準を満たす場合には、その署名に一致する。例えば、その候補ユニットには、その関係がその署名に対してどれだけ近接して一致しているかどうかを反映するメンバシップスコアを与えることができる。このスコアは、様々な方法により計算することができ、最小スコアは、「一致」基準として用いることができる。１つの実施形態では、メンバシップスコアは、５０％（又は４０％又は９０％等）の最小スコアを有する候補ユニットに関連する署名ユニットの割合に基づく。別の実施形態では、署名ユニットがウェイト範囲に結合している場合に、候補は、その候補の関係のエッジウェイトがウェイト範囲内にあることについての署名ユニットの割りアプリケーションに基づいて評価することができる。
さらに別の実施形態では、上述したアルゴリズムのいずれか、又は、クラスタリング処理（図５）の間に２つのユニットの類似性を決定するための他の適切なアルゴリズムが、他の候補ユニットとしてのスーパーユニットとこのスーパーユニットのための隣接語ユニットとしての署名ユニットとを用いて、候補ユニットについてのメンバシップスコアを決定するのに適しているものとすることができる。

評価の対象とする候補ユニットを選択することは、例えば、１又はそれ以上の署名ユニットに直接的に関連したユニットのみを考慮することにより、簡略化することができる。上述したように、既にスーパーユニット又は署名のメンバであるユニットは、候補リストから除外することができる。

ステップ７０８において、署名（例えば、いくつかの閾値を超えるメンバシップスコアを有する署名）と一致する候補ユニットがスーパーユニットに追加される。ステップ７１０では、新しい署名が更新されたスーパーユニットのために生成される。ステップ７１０は、好ましくは、ステップ７０４におけるものと同一の署名生成技術を用い、この結果、新しい署名と以前の署名との間の相違がスーパーユニットにおいてメンバシップが変化したことに起因するようになる。

ステップ７１２において、スーパーユニットは、新しい署名に一致しないメンバユニットを除去することにより、パージ（purge）される。ステップ７１２は、好ましくは、ステップ７０６におけるものと同一の一致基準を用いる。いくつかの実施形態では、他のメンバユニットと同様に、ステップ７１２において試験されパージされ、別の実施形態では、種ユニットはパージされない。さらに別の実施形態では、スーパーユニットメンバシップが減少せずに増加することができるように、ステップ７１２が省略される。

ステップ７１４では、スーパーユニットが収束したかどうかを決定し、そうでなければ、処理は、ステップ７０６に戻って、署名に基づいてスーパーユニットを更新した後その署名を更新するというステップを繰り返す。スーパーユニット又はその署名のいずれか（或いは両方）がその繰り返し処理の間に変化しない場合には、収束が発生する。いくつかの実施形態は、収束のために緩和した条件を用いて、十分に小さい変化がスーパーユニット又は署名において発生したときに、収束を見つけられるようにすることができる。

ステップ７１６では、スーパーユニットが一旦収束すると、新しいスーパーユニットがユニット辞書４０６に追加される。例えば、スーパーユニットは、（各メンバについてのメンバシップウェイトが、最後の署名から決定された最終的なメンバシップスコアである場合には）メンバユニットのベクトル及びメンバシップウェイトのベクトルとして表現することができる。或いはまた、スーパーユニットは、ユニット辞書４０６におけるすべてのユニットについてのメンバシップウェイトのベクトルを用いて表現することができる。この場合、スーパーユニットのメンバでないユニットについてのウェイトは、０に設定することができ、或いは、メンバシップウェイトは、最後の署名に基づいた非メンバユニットについて計算することができる。スーパーユニットについての最後の書名はまた、好ましくは、ユニット辞書４０６に記憶される。

図８Ａ及び図８Ｂは、処理７００に従ってスーパーユニットを構築する間における概念ネットワーク８００の一部を示す。図８Ａ及び図８Ｂにおける符号の付し方は、ネットワーク８００について結合関係のみが示され、その結果関係エッジが付されていないということを除いて図３におけるものとほぼ同様である（他のケースでは、結合以外の関係も考慮することができる、ということが理解できよう）。図８Ａは、ステップ７０４の後の概念ネットワーク８００の状態を示す。ノード「アヴリル・ラビーン」８０２とノード「セリーヌ・ディオン」８０４は、スーパーユニット「Ｘ」（点線で示されたボックス８０６）についての種のメンバである。ノード「mp3」８０８、ノード「mp3」８０８、ノード「歌詞」８１０、ノード「写真」８１２、ノード「アルバム」８１４及びノード「旅行」８１６は、スーパーユニットＸの署名「Ｙ」（点線で示されたボックス８１８）のメンバとして（ステップ７０４の間において）認識されている。ノード「barbra streisan」８２０、ノード「映画」８２２及びノード「arnold schwarzenegger」８２４は、スーパーユニットＸ又は署名Ｙのいずれのメンバでもない。

この例では、各ユニットが署名Ｙにおける少なくとも１つのユニットの隣接語であるので、スーパーユニットの生成は、ユニット「barbra streisand」８２０及び「arnold schwarzenegger」８２４を候補ユニットとして認識することにより、進行する。各候補ユニットは、次に、いくつかの基準に基づいた署名に対する一致のために評価される。例えば、必要とされるかもしれない候補が、署名ユニットのうちの少なくとも７５％と結合される。「barbra streisand」ノード８２０が、署名Ｙにおける５つのユニットのうちの４つと結合され、ステップ７０８においてスーパーユニットＸに加えられる。「arnold schwarzenegger」ノード８２４は、署名Ｙにおけるユニットのうち１つのみに結合され、ステップ７０８においてスーパーユニットＸに付加されない。図８Ｂは、「barbra streisand」ノード８２０がスーパーユニットＸ’（点線で示されたボックス８０６’）に付加されている、ステップ７０６及び７０８の後の概念ネットワーク８００の状態を示す。

次に、スーパーユニットＸ’についての書名Ｙが更新される（ステップ７１０）。例えば、署名Ｙは、スーパーユニットＸのメンバのうちの少なくとも５０％と結合するユニットのみを含むように定めることができる。「barbra streisand」ユニット８２０は、「映画」ユニット８２２に結合されているが、他のメンバは「映画」ユニット８２２に結合されていない。したがって、「映画」は署名Ｙに付加されない。「写真」ユニット８１２は、「barbra streisand」メンバユニット８２０に結合されていないが、これら３つのユニットのうちの他の２つに結合されている。よって、「映画」は署名に残る。

この例では、署名Ｙは繰り返し処理の間には変化せず、また、存在しうる候補ユニットのメンバシップスコアが変化しないので、収束は見られない。この例は非常に簡略化されており、概念ネットワークは、図８Ａ及び図８Ｂに示した部分よりも著しく大きくかつ複雑であり、スーパーユニットを収束させるためには非常に多くの繰り返し処理が必要になるであろう、ということを理解されたい。

ここで、処理７００に従ったスーパーユニット生成の別の例を、薬品に関連したスーパーユニットについて説明する。この例では、概念ネットワークは、多数の問い合わせ（例えば、Ｙａｈｏｏ！のような主要なインターネット検索プロバイダによって受信されたある週の問い合わせの量）から生成されている。概念ネットワークからは、ベースユニットとして特定の薬物（例えば「Vicodin」）のブランド名を用いてクリークが形成された。このクリークは、上述した処理６００に従って形成されたものであり、特定の薬物の名前（例えば「Oxycontin」や「Propecia」等）である他のユニットを少数（このケースでは、９個）含む。

このクリーは、スーパーユニット組Ｘを生成するために、スーパーユニット種として用いられた（ステップ７０２）。このスーパーユニット種における各メンバユニットｘ_iには、一定の値（例えばすべてのｘｉについてＷ（ｘ_i）＝１）に初期化されたメンバシップウェイトＷ（ｘ_i）が割り当てられ、他の実施形態では、（例えば上述したクラスタリングアルゴリズムのうちのいずれかを用いた）クラスタリングウェイト又は（例えば、上述した式（６）からの）クリークメンバシップスコアを、初期メンバシップウェイトとして用いることができる。

次に、署名が、スーパーユニット種について生成される（ステップ７０４）。「薬品」スーパーユニットについて用いられる種類の署名生成処理の一例が、図９において処理９００として示されている。ステップ９０２において、準備署名の組Ｐが形成される。ここで、組Ｐは、スーパーユニットの組Ｘのメンバユニットｘ_iの各々に対する隣接語の組Ｖ（ｘ_i）である。いくつかの実施形態では、組Ｖ（ｘ_i）は、メンバユニットｘｉに対するすべての隣接語よりも少なくすることができ、例えば、最小エッジウェイト又は特定の型の関係を必要とすることができ、或いは、この組は、選別して重複したユニットを除去することができる（例えば、「map of spain」又は「spain map」のうちの１つのみを残すことができる）。

ステップ９０４において、第１スコアが準備署名の組Ｐにおける各ユニットｐ_jについて計算される。ユニットｐ_jについての第１スコアは、好ましくは、スーパーユニットの組Ｘにおけるメンバｘ_iがユニットｐ_jの隣接語になることについての確からしさを反映する。「薬品」スーパーユニットの例では、ユニットｐ_jについての第１スコアが、ユニットｐ_jの隣接語であるユニットｘ_iのメンバシップウェイトＷ（ｘ_i）に基づく「関連した比率（related proportion;RP）」であった。例えば、ｘ_iがユニットｐ_jの隣接語である場合には、Ｌ（ｘ_i、ｐ_j）が１に等しいと定義され、それ以外の場合には０と定義されるような場合には、ＲＰスコアは、次の式により計算することができる。

ここで、Ｎ［Ｘ］は、スーパーユニットの組Ｘにおいけるメンバユニットの総数を示す。

ステップ９０６において、準備署名の組Ｐにおける各ユニットｐ_jについて第２スコアが計算される。ユニットｐｊについての第２スコアは、好ましくは、潜在的な（potential）署名ユニットｐ_j（すなわち隣接語の組Ｖ（ｐ_j）の１つのメンバ）の隣接語ユニットがスーパーユニット組Ｘのメンバでもあることについての確からしさを反映する。「薬品」スーパーユニットの例では、第２スコアは、次の式により与えられる関連した頻度比率（ＲＦＲ）であった。
ＲＦＲ（ｐ_j）＝１００*ρ[Ｖ（ｐ_j），Ｘ]／ρ[Ｖ（ｐ_j）] （８）
ここで、ρ[Ｖ（ｐ_j），Ｘ]は、隣接語の組Ｖ（ｐ_j）のメンバと組Ｘのメンバユニットとの間における関係の頻度（又はエッジウェイト）の合計を示し、ρ[Ｖ（ｐ_j）]は、隣接語の組Ｖ（ｐ_j）におけるすべてのメンバの集合（aggregate）頻度を示す。

ステップ９０８では、第１スコア及び第２スコアを組み合わせることにより準備組Ｐにおける各ユニットｐ_jについて、最終スコアＳ_f（ｐ_j）が計算される。「薬品」スーパーユニットの例では、式（７）及び（８）のそれぞれにより上述したように定義されたＲＰ及びＲＦＲを用いて、最終スコアが次の式により与えられる。
Ｓ_f（ｐ_j）＝ＲＰ（ｐ_j）*ｌｏｇＲＦＲ（Ｐ_j） （９）
他の実施形態では、最終スコアＳ_f（ｐ_j）は、ＲＰスコアとＲＦＲスコアとの異なる組み合わせとすることができる。

ステップ９１０では、閾値が最終スコアＳ_f（ｐ_j）と、上述したスコアを有するユニットｐ_jとに適用され、上記閾値は、スーパーユニットＸについての署名の組Ｙにおける署名ユニットｙ_jとなる。「薬品」スーパーユニットの例では、上記閾値は、任意のユニットｐ_jについてのＳ_f（ｐ_j）の最大値を固定値により除することにより決定されたが、この例では、６という固定値が用いられたが、他の値をも選択することができる。署名の組Ｙに含まれた各ユニットｙ_iについて、最終スコアＳ_f（ｙ_j）が、メンバシップウェイトＷ（ｙ_j）として保存された。

署名が生成された後、候補ユニットｃ_kが、スーパーユニットの組Ｘ（処理７００におけるステップ７０８）に対する考えられうる付加について試験され、これにより、変更されたスーパーユニットＸ’が生成される。これらの候補ユニットｃ_kは、少なくとも１つの署名ユニットｙ_j（ここで、ｙ_jは組Ｙのメンバである）の隣接語であり、かつ、未だ組Ｘ又は組Ｙのメンバとなっていないユニットから選択された。各候補ユニットｃ_kについて、メンバシップスコアが、候補ユニットｃ_kにおける隣接語ユニットＶ（ｃ_k）及び署名の組Ｙにおける署名ユニットｙ_jに部分的に基づいて計算された。スーパーユニットメンバについてのメンバシップスコアの計算は、署名について上述した処理９００とほぼ同様であり、そのスコア自体は同様に計算された。

さらに具体的には、１つのスコアは、上述した式（７）と同様に定義された関連した比率スコアであった。すなわち、Ｌ（ｙ_j、ｃ_k）が１に等しくなるように定義され、ユニットｙ_jがユニットｃ_kの隣接語であって０に等しい場合には、候補ユニットｃ_kについてのＲＰスコアは、次の式により定義された。
ＰＲ（ｃ_k）＝（１／Ｎ[Ｙ]）*Ｓｕｍ[Ｌ（ｙ_j、ｃ_k）*Ｗ（ｙ_j）] （１０）
ここで、Ｎ[Ｙ]は、署名の組Ｙにおけるユニットｙ_jの総数であり、Ｗ（ｙ_j）は、ユニットｙ_jについてのメンバシップスコア（上述した式（９）の結果）である。第２スコアは、上述した式（８）によるものと同様に定義された関連した頻度比率スコアであった。すなわち、Ｖ（ｃ_k）が候補ユニットｃ_kにおけるすべての隣接語ユニットの組を示し、ρ[Ｖ（ｃ_k）、Ｙ]が、隣接語の組Ｖ（ｃ_k）のメンバと署名の組Ｙにおける署名ユニットとの間における関係の頻度又はエッジウェイトの合計を示し、ρ[Ｖ（ｃ_k）]は、隣接語の組Ｖ（ｃ_k）におけるすべてのメンバの集合頻度を示す。
ＲＦＲ（ｃ_k）＝１００*ρ[Ｖ（ｃ_k），Ｘ]／ρ[Ｖ（ｃ_k）] （１１）
最終的なスコアＳ_f（ｃ_k）は、ＲＰスコアとＲＦＲスコアとを組み合わせることにより決定された。すなわち、最終的なスコアＳ_f（ｃ_k）は、上述した式（９）と同様に、次の式により決定された。
Ｓ_f（ｃ_k）＝ＲＰ（ｃ_k）＊ｌｏｇＲＦＲ（ｃ_k） （１２）
閾値が最終的なスコアＳ_f（ｃ_k）に適用されて、候補ｃ_kがスーパーユニットの組Ｘ’に加えるべきかどうかが決定された。この閾値は、すべての候補ユニットｃ_kにわたるＳ_f（ｃ_k）のうちの最大値を固定値で除することにより決定された。この例では、６という固定値が用いられたが、他の値を選択することも可能である。ユニットｘ_iとして追加された各候補ｃ_kについて、そのメンバシップウェイトＷ（ｘ_i）がその最終的なスコアに等しくなるように設定された。このメンバシップウェイトは、処理７００における署名の更新ステップ７１０についての次の繰り返し処理において用いられた。

すべての候補が処理された後、スーパーユニット生成処理がステップ７１０まで続けられ、ここで、署名の組Ｙは、更新されたスーパーユニットの組Ｘ’におけるメンバシップに基づく新しい組Ｙ’に更新された。これは、スーパーユニットの組Ｘ’における現在のメンバシップを用いて処理９００を再度実行することによりなされた。次に、ステップ７１２において、スーパーユニットの組Ｘ’のメンバユニットが評価されて、これらを除去すべきかどうかが決定され、この処理は、ステップ７０８におけるものと同一のスコア計算及びメンバシップ基準を用いた。

ステップ７１４において、組Ｘ’及び組Ｙ’をそれぞれ組Ｘ及び組Ｙと比較することにより、収束又は非収束が決定された。収束が生じた各対の組の間には、変化が全くないか或いは十分に小さい変化しかない。

図１０は、「薬品」のスーパーユニットについての結果を示す。上述したように、種は、単一のブランド名（ＶＩＣＯＤＩＮ）に基づいたクリークであり、署名ウェイトは上述した式（７）、（８）及び（９）により決定され、スーパーユニットメンバシップウェイトは、上述した式（１０）、（１１）及び（１２）により決定された。図１０Ａは、８回の繰り返し処理の後における、署名ユニットと、それらの各メンバシップウェイトとを示し、図１０Ｂは、同様に８回の繰り返し処理の後における、スーパーユニットメンバのいくつかと、それらの各ウェイトのいくつかとを示す。これらの結果は、多数の実際のユーザの問い合わせから生成され、全スーパーユニットは１００以上のメンバを含んでいるが、ここでは、それらのうち代表的なものが示されている。

この例について、６つのユニットにより構成された署名セットが図１０Ａに列挙されている。これらは、人が薬品に関する情報を検索するときに含むことを期待し薬品に関連しない検索においては含まないように期待するユニットである、ということに留意されたい。それらのうちのいくつかが図１０Ｂに示されているスーパーユニットメンバは、様々な薬品のブランド名の多数を含んでいる（周りにスーパーユニット種が形成されるベースユニットである「Ｖｉｃｏｄｉｎ」は別にして、これらのブランド名が図１０Ｂに＜ブランドＡ＞等のように列挙されている。特定のブランド及びそれらの順序は、本発明には関係がない）。図１０Ａは、薬品（例えば、「イブプロフェン」、「薬品」や「カフェイン」）、食品添加物（例えば、いくつかの様々なビタミン（列挙されていないが）に加えて「アスパルテーム」等）、及び、他の薬品関係の用語（例えば「化学療法」）についての一般的な名前をも含んでいる。

この例は例示的なものであり、変形及び変更が可能であり、異なる概念ネットワークが入力として用いられた場合には、スーパーユニットメンバ、署名ユニット及び／又はスコアが通常はこの例において述べたものとは変わる、ということを理解できよう。さらには、署名及びスーパーユニットメンバシップスコアについて説明した計算式は、例示的なものであり、所望により変化させることができる。

例えば、いくつかの実施形態では、潜在的な署名ユニットは、スーパーユニットメンバのメンバシップウェイトＷ（ｘ_i）を参照することなく計算することができるものである。このような実施形態では、Ｎ[Ｘ∩Ｖ（ｐ_i）]は、ユニットｐ_jの隣接語の組Ｖ（ｐ_j）のメンバでもある、スーパーユニットの組Ｘのメンバを示し、Ｎ[Ｘ]は、スーパーユニットの組Ｘにおけるメンバの総数を示し、少なくともの組Ｘのメンバがユニットｐ_jの隣接語であることについての確からしさを反映するユニットｐ_jについての第１スコアＳ₁は、次の式により計算することができる。
Ｓ₁（ｐ_j）＝Ｎ[Ｘ∩Ｖ（ｐ_j）]／Ｎ[Ｘ] （１３）
同様に、ユニットｐｊの隣接語ユニットがスーパーユニットの組Ｘのメンバであることについての確からしさを反映する、ユニットｐｊについての第２スコアは、次の式により計算することができる。
Ｓ₂（ｐ_j）＝ρ[Ｖ（ｐ_j）,Ｘ]／ρ[Ｖ（ｐ_j）] （１４）
ここで、ρ[Ｖ（ｐ_j）,Ｘ]及びρ[Ｖ（ｐ_j）]は、上述の通り定義される。他の例として、ユニットｐｊについての第２スコアは、次の式により計算される。
Ｓ₂'（ｐ_j）＝Ｎ[Ｖ（ｐ_j）∩Ｘ]／Ｎ[Ｖ（ｐ_j）] （１５）
ここで、Ｖ（ｐ_j）は、ユニットｐ_jの隣接語ユニットの組を示し、Ｎ[Ｖ（ｐ_j）∩Ｘ]は、Ｘのメンバでもあるユニットｐ_jについての隣接語の組Ｖ（ｐ_j）におけるユニットの数を示し、Ｎ[Ｖ（ｐ_j）]は、隣接語の組Ｖ（ｐ_j）における隣接語のユニットの総数を示す。

第１スコア及び第２スコアは、署名の組Ｙに含むことについての閾値を適用することを目的として最終スコアを決定するのに望まれるどのような方法によっても組み合わせることができる。或いはまた、各スコアに対して個別に別々のカットオフ（cut off）を適用することが可能である。例えば、いくつかの閾値ｔ₁、ｔ₂についてＳ₁（ｐ_j）＞ｔ₁及びＳ₂（ｐ_j）＞ｔ₂である場合に、ユニットｐ_jが署名の組Ｙのメンバユニットｙ_jとなる。２つのスコアに対して別々のカットオフを用いた場合には、両方のスコアをメンバシップウェイトとして保存することができる。

スーパーユニットＸに含めるために考慮された候補ユニットｃ_kについての類似したスコアを同様に計算することができる、ということが理解できよう。例えば、Ｎ[Ｖ（ｃ_k）∩Ｙ]が、組Ｙにおける署名ユニットである候補ｃ_kの隣接語ユニットの数を示し、Ｎ[Ｖ（ｃ_k）]が候補ユニットｃ_kの隣接語ユニットの総数を示し、Ｎ[Ｙ]が署名ユニットＹの総数を示す場合には、２つのメンバシップスコアＳ₁及びＳ₂は、上述した式（１３）及び（１５）に類似した次の式により定義することができる。
Ｓ₁（ｃ_k）＝Ｎ[Ｖ（ｃ_k）∩Ｙ]／Ｎ[Ｖ（ｃ_k）] （１６）
Ｓ₂（ｃ_k）＝Ｎ[Ｖ（ｃ_k）∩Ｙ]／Ｎ[Ｙ] （１７）
頻度という形での定義もまた、上記スコアのいずれか又は両方に対して用いることができる。候補ユニットｃｋを付加するかどうかは、個別のスコアのうちのいずれか若しくは両方、又は、これらの組み合わせに基づいて決定することができる。

上述したように、スーパーユニット又は署名のいずれかについての候補ユニットの隣接語のすべてを必ずしも考慮する必要はない。候補ユニットは、例えば、特定の関係（例えば拡張のみ）、最小エッジウェイト又は他の基準に基づいて制限することができる。１つの実施形態では、用いられる隣接語ユニットは、候補ユニットについての「提案（suggestions）」となる。ここで、提案は、上記の通り参照した出願第１０／７１３,５７６号に詳細に記載された技術を用いて認識することができる。

本明細書に記載したスーパーユニット構築処理は例示的なものであり、変形及び変更が可能である、ということが理解できよう。時系列なものとして記載したステップは並列に実行することができ、ステップの順序は変化させることができ、ステップは変更することができ、或いは、複数のステップを組み合わせることができる。多数のスーパーユニットは、任意の数の種から開始して、並列的に（又は逐次的に）構築することができる。加えて、スーパーユニットの変化させた組は、スーパーユニット及び／又は署名におけるメンバシップについて異なる基準を用いることにより、同一の概念ネットワーク（及び選択的には同一の種）から構築することができ、これにより、異なるコンテンツを有するスーパーユニットを生成することができる。さらには、上述した例は、結合の関係を参照して説明したが、スーパーユニットメンバと署名ユニットとの間における他の型の関係をも考慮することができる。また、上述した例は、メンバユニットの直ぐ隣にある隣接語である署名ユニットのみを考慮したが、他の実施形態は、間接的な関係、問い合わせにおける２以上のユニットの共同発生等を選択することができる。

いくつかの特徴では、スーパーユニット構築処理は、上述したクラスタ生成処理５００（図５）を拡張したものである。ここで用いる「クラスタ」とは、ユニットの隣接語集合（すなわち結合したユニット）の類似度に基づいて関連した、それらユニットのグループをいい、その意味において、クラスタは、スーパーユニットの１つの型とみなすことができ、署名は、共通の隣接語集合に基づいて定められる。他の型のスーパーユニットをもまた、スーパーユニットのメンバ間における直接的な関係を含む、他のタイプの関係をも取り込むように、生成することができる。例えば、ユニット「britney spears」及び「brittany spears」（共通の綴り誤り）は、共通の隣接語集合を有しそうであり、明らかに他の歌手を示している「barbra streisand」及び「celine dion」のようなユニットとともに、クラスタ型のスーパーユニットに含まれそうである。「britney spears」という正しい綴りと様々な正しくない綴りとの間における特別な関係を取り込むために、代替のスーパーユニットを生成することができる。この型のスーパーユニットの署名は、いくつかの数の他のメンバ（又は単一の「好ましい」メンバ）を、共通の隣接語集合とともに（又は共通の隣接語集合に代えて）有する「代替」の関係の存在を含むことができる。

図４を再度参照すると、問い合わせエンジン４０４は、好ましくは、繰り返し発生することを基本として問い合わせ処理動作を（毎週、毎日、毎時間、問い合わせを受信したときにリアルタイムに等）実行するように構成される。いくつかの実施形態では、現存するユニット辞書は、新しい組の問い合わせログファイルにおける受信した問い合わせに基づいて更新され、他の実施形態では、新しいユニット辞書は、上記新しい組の問い合わせログファイルからのスクラッチ（scractch）から生成することができる。いずれのケースにおいても、概念ネットワーク及びスーパーユニットは、ユーザの振る舞いの変化に応答して自然に進化することができる。例えば、新しい歌手が有名になった場合には、ユーザは、スーパーユニットＸの署名ユニットに関連したその新しい歌手の名前の検索を開始する可能性が高いので、その歌手は、図８におけるスーパーユニットＸの部分になりそうである。

好ましい実施形態では、問い合わせ処理エンジン４０４は、実世界の知識又はユニット若しくは問い合わせに関する語義的情報を設ける必要がなくとも、スーパーユニットは、概念について実世界の関係を反映する傾向がある。例えば、１つのスーパーユニットは、「New York」、「San Francisco」及び「Chicago」を含むことができ、そのスーパーユニットについての署名は、「hotel」、「restaurant」及び「night club」を含むことができる。このようなスーパーユニットは、New York City、San Francisco及びChicagoがすべての旅行者の目的地（又は都市）であることを反映するが、問い合わせエンジン４０４（図４）は、「目的地」（又は「都市」）という概念についての以前の知識を処理する必要がない。この概念的な知識は、問い合わせのパターンの分析から自動的に増加することができる。本明細書は、人間に語義的な意味を伝える用語をスーパーユニットとしているが、これは、本明細書の開示を容易にするのに便利であるからである。実際には、問い合わせエンジン４０４又はユニット辞書４０６により用いられるスーパーユニットラベル付与方法は、このような性質を有する必要はない。例えば、スーパーユニットというラベルは、単に、スーパーユニットについてのウェイトベクトル又は署名に対する番号、参照等とすることができる。

いくつかの実施形態では、スーパーユニットは、スーパーユニットのいくつか又はすべてに対する意味を持ったラベルを語義的に割り当てることにより、さらに向上させることができる。例えば、ラベル（例えば「芸術家」）を１又はそれ以上のキーワードに結合する分類されたキーワードデータベースを、ラベルの割り当てに用いるために設けることができる。スーパーユニットにおける署名ユニットがキーワードと比較されて、ラベルを適用するかどうかを決定することができる。人間によるインデックス編集者が、例えば、キーワードデータベースを構築すること、及び／又は、ラベルをスーパーユニットに割り当てることを確認することにより、この処理に参加することができる。

１つのユニットは、多数のスーパーユニットに属することができる。例えば、「java」のようなあいまいなユニットは、「コンピュータプログラミング」というスーパーユニット、「食事及び飲み物」というスーパーユニット、及び、「旅行」又は「場所」というスーパーユニットとなりうる。いくつかの実施形態では、いかなるスーパーユニットにも属さないユニットが発生することもある。生成されるスーパーユニットの数は、事前に確立することができ、例えば１００、５００、１５００又は５０００とすることができる。他の実施形態では、スーパーユニットの数は事前には決定されない。

本明細書で説明したシステム及び処理は例示的なものであり、変形及び変更が可能である、ということを理解されたい。時系列的なものとして説明した処理ステップは、並列に実行することが可能であり、ステップは組み合わせることが可能であり、複数のステップの順序を変更するｋとも可能である。例えば、スーパーユニットにおけるメンバシップについての候補として考慮したユニットの組は、様々な方法（例えば、比較的に頻繁に発生するユニットに対する候補を制限すること等）により制限することができ、署名ユニットの組もまた制限することができる。１つの実施形態では、署名ユニットは、スーパーユニットのメンバにおける少なくとも１つと結合した「提案」を含み、又は、この「提案」に限定することができる。提案は、この意味において、特定の問い合わせ（又はユニット）においてタイピングするユーザが興味を持ちうる本当らしい事項であり、かつ、ユニット及び頻度情報の分析に基づいている本当らしい事項（likely thing）として認識されているユニットである。提案を生成する技術は、上記の通り参照した米国出願第１０／７１３,５７６号に詳細に記載されている。

３．問い合わせ応答におけるスーパーユニットの適用
スーパーユニットの情報は、様々な方法により用いて、問い合わせに対する応答を高めることができる。図１１は、図２におけるシステム１１０が問い合わせに応答することができる方法を示す。クライアント１２０は、検索サーバシステム１６０に問い合わせを送信する。検索サーバシステム１６０は、その問い合わせ及び／又はその構成要素ユニットを、ユニット辞書４０６にアクセスする概念サーバ１８０に送信する。概念サーバ１８０は、その問い合わせから認識される１又はそれ以上のユニット、及び、これに加えてその様々なユニットについての統計値及びスーパーユニット情報のような、その問い合わせに関連する概念的データを返す。この情報は、例えば、その問い合わせをハッシングしてこの問い合わせに含まれているユニットを識別することにより、及び、ユニット辞書４０６にアクセスして、識別した各ユニットについてのエントリを検索することにより、取り出すことができる。この実施形態では、ユニット辞書４０６は、問い合わせ処理の間に利用可能にされるユニットに関する情報を含んでおり、また、概念ネットワークの表現全体又部分を含むことができる。１つの実施形態では、返された情報は、問い合わせに結合したスーパーユニットに関する情報、又は、その問い合わせにおける個々のユニットに関する情報を含む。

検索サーバシステム１６０は、好ましくは、その問い合わせに応答するときに概念サーバ１８０から受信した概念データを用いる。検索サーバシステム１６０により返された結果は、好ましくは、ユーザの問い合わせに応答した結果を、他の関連した情報とともに含む。他の関連した情報とは、例えば、スーパーユニットを含むユニット及びユニットの関係において取り込まれたユーザの要望についての理解に基づいた、ユーザが次に探したいであろう事項に関するヒント及び秘訣である。ここで、スーパーユニット情報を問い合わせに応答して用いることができる方法のいくつかの例について説明するが、これらの例は例示的なものであり限定的なものではないということを理解されたい。

Ａ．あいまいさの解決
いくつかの実施形態では、検索サーバシステム１６０は、多数ユニットの問い合わせにおける構成要素ユニットを用いて、その構成要素ユニットの１つにおけるあいまいさを解決することができる。例えば、問い合わせが、１以上のコンテキストにおいて用いられうる「java」のようなあいまいな語を含む場合を考える。このような語は、多数のスーパーユニット、例えば、「食べ物及び飲み物」というスーパーユニット、「コンピュータ」というスーパーユニット、及び、「場所」というスーパーユニットに属しうる。その問い合わせをユニットに分解（parse）し、「java」というユニットにおけるあいまいあさを検出した後、検索サーバ１６０は、問い合わせにおける他の構成要素ユニットを、そのスーパーユニットの各々における署名と比較することができる。よって、その問い合わせがまた「店」又は「コーヒー」のような用語を含む場合には、検索サーｂアプリケーションシステム１６０は、そのユーザが「食べ物及び飲み物」というスーパーユニットに興味を持っている可能性が非常に高いと推定する一方、「プログラム」又は「スクリプト」といったような語は、「コンピュータ」というスーパーユニット等を示している。結果（例えば、その問い合わせに応答するページへのリンク）は、異なるスーパーユニットに対応するグループにおいて存在することになり、最も本当らしいスーパーユニットが最初に出現する。別の実施形態では、異なるスーパーユニット（又はコンテキスト）からの結果は、結果のページにおける異なる「タブ」上に配列することができ、これにより、ユーザに所望のタブ上をクリックさせることによりコンテキストを選択させることができる。最も本当らしいコンテキストをデフォルトにより表示させることができる。

スーパーユニットはまた、他の方法により、例えば、ユーザが同一のセッションにおいて作成した他の問い合わせを検討することにより、あいまいさを解決するために用いることができる。例えば、「ジャガー」というユニットは、動物又は自動車を示すことができる。ユーザの「ジャガー」の前の問い合わせが動物にではなくて自動車（例えば、「ケリーのブルーブック」又は「ポルシェ」）に関連していれば、ユーザは動物にではなく自動車に興味を持っている可能性が高いと推定することができる。このような推定は、同一のユーザにより入力された異なる問い合わせにおけるユニットのスーパーユニットメンバシップを検討することにより自動化することができる。メンバとして両方のユニットを有するスーパーユニットは、両方のユニットを有していないスーパーユニットよりも本当らしいとして認識することができる。例えば、最も最新の問い合わせに対してより大きなウェイトを与えて、任意の数のユーザの以前の（過去の）問い合わせを考慮することができる。

検索サーバシステム１６０は、様々な技術を用いて、結果をグループ化する方法を決定することができる。例えば、ページインデックス（例えば図２におけるページインデックス１７０）を生成する、検索に関連したアルゴリズムは、ユニット辞書４０６からの現存するスーパーユニットデータを用いて、インデックスにおける各ページ又はサイト（又は他のユニットのコンテンツ）を、１又はそれ以上のスーパーユニットに割り当てるように構成することができ、スーパーユニットの割り当ては、特定の語又はユニットの発生に関連したデータとともに、インデックス（例えばコンテンツ識別子１７２として）に格納される。

Ｂ．関連した検索の提案
いくつかの実施形態では、検索サーバシステム１６０は、スーパーユニット情報に基づいた、関連した検索を提案する。例えば、問い合わせが「New York City（ニューヨーク市）」であり、このユニットが「目的地」というスーパーユニットに属していることが既知となっている場合を考える。検索サーバシステム１６０は、そのスーパーユニットに結合した署名を用いて、付加的な検索、例えば「New York City（ニューヨーク市）」に関連した「レストラン」又は「ホテル」についての検索を提案する。このような提案は、例えば、スーパーユニットの署名ユニットに基づくことができる。

Ｃ．「脇道」検索の提案
いくつかの実施形態では、検索サーバシステム１６０はまた、スーパーユニット情報を用いて、類似するサイト又は関連するサイトの「脇道」検索を提案する。例えば、ユーザがＷ日におけるＡ点からＢ点への飛行に興味を持っていると考える。ユーザは、直接、航空会社のサイト、例えばアメリカンエアライン（登録商標）のサイトにアクセスし、そのサイト内で検索を実行するか、或いは、ユーザは、「航空会社」、「航空機旅行」又は「アメリカンエアライン」等についての検索を要求し、表示された検索結果（例えば、アメリカンエアラインのサイト）におけるリンクから特定のサイトにアクセスし、そのようにアクセスしたサイト内においてＷ日におけるＡ点からＢ点へのフライトに関する情報を要求する。今、そのユーザは、要求した情報、例えば、多分、利用可能な様々なフライトに関連した価格情報を含む情報に関する、アメリカンエアラインのサイトからの情報を見ている。「脇道」検索は、ユーザに対して、同一の情報、例えばＡ点、Ｂ点及びＷ日という情報を用いて別のサイトを検索し、手動操作により新しいサイトにアクセスして所望の情報を再入力しなくとも、類似した結果を得ることを可能にする。

本発明の一実施形態では、検索サーバシステム１６０は、関連するサイトを識別するスーパーユニット情報を用いて、提案した「関連する」サイトに対する脇道検索を実行するように、ユーザを促すことができる。例えば、「アメリカンエアライン」というユニットは、「エアライン」又は「輸送」というスーパーユニットに属することができ、検索サーバシステム１６０は、そのスーパーユニットにおいて他のユニット（例えば「ユナイテッドエアラインズ」）を識別し、そのユニットに結合したサイトに対する検索を実行するように提案する。ユーザが脇道検索を選択した場合には、そのシステムは、その識別されたサイトとのインターフェースを行って、所望の検索結果、例えば、Ｗ日におけるＡ点からＢ点へのフライトに関する価格情報を列挙する識別されたサイトにおけるページを提供する。ユーザが、或るサイトに直接アクセスして、そのアクセスしたサイトに結合したフォームに検索情報を入力した場合には、検索モジュール１２６は、その入力情報を格納し、脇道検索を要求されたときに関連するサイトにおけるフォームを埋めるのに必要となるそのような情報を用いる。ユーザは、勿論、その選択したサイトの要求に応じて新しいサイトにおいて付加的な情報を入力する必要がある。この方法により、ユーザには、類似した情報について異なるウェブサイトにわたって類似した検索を能率化する機能が提供される。

Ｄ．綴り誤りの解決
いくつかの実施形態では、スーパーユニット及び署名が用いられて、問い合わせ処理の間に向上させた綴りチェックが実現される。例えば、ユーザが「basset」を含む問い合わせを入力した場合、通常の検索サーバシステムは、「bassett」又は「basket」が可能性のある代替語であると認識して、これらのうちのいずれか又は両方をユーザに提案するかもしれない。スーパーユニットデータにアクセスした検索サーバ１６０は、概念ネットワークを強化して、いずれの代替綴りがユーザによって最も意図されている可能性が高いかを決定することができる。

例えば、「basset」を含む以前の（過去の）問い合わせが「basket」よりも「bassett」に近い署名を有する場合を考える（例えば、「basset」は、「weaving」と一緒に出現する場合に比べて、遥かに頻繁に「hound」と一緒に出現するので）。この場合、検索サーバは、最良の代替形として「basset」を提案する。別の実装例では、完全な問い合わせは、「basket」を含む１つのスーパーユニットに結合した署名及び「bassett」を含む別のスーパーユニットに結合した署名の各々と比較して、これらのうち、署名がその問い合わせにより近似して一致した方に基づいて提案がなされる。このようにして、検索サーバ１６０は、「basset hound」という問い合わせに応答して「bassett hound」についての検索を提案し、「basset weaving」という問い合わせに応答して「basket weaving」についての検索を提案する。

Ｅ．ディレクトリベースの検索のサポート
さらなる実施形態では、スーパーユニット情報を用いて、ユニットの階層カテゴリ分類を構築することができる。１つの実施形態では、スーパーユニットの構築における多数のフェイズが実行される。この第１フェイズでは、比較的厳格なメンバシップ基準を用いることにより、階層構造の低いレベルを表現するスーパーユニットを生成することができる。例えば、「都市」というスーパーユニット、「州」というスーパーユニット及び「国」というスーパーユニットを、このフェイズにおいて構築することができる。後のフェイズでは、スーパーユニットの初期の組から開始して再度スーパーユニットを構築し（選択的には、以前より厳格ではない基準を用いて）、これにより、高いレベルのスーパーユニット（都市、州及び国を含む「場所」というスーパーユニットといったような）を生成することができる。或いはまた、スーパーユニット構築処理（例えば図７の処理７００）の繰り返し処理における異なるステージが用いられて、階層構造の異なるレベルを認識することができる。

スーパーユニットに基づいた階層カテゴリ分類が用いられて、現在Ｙａｈｏｏ！及び他の検索サービスプロバイダにより提供されているものと類似したディレクトリベースの検索機能が実現される。通常のディレクトリベースの検索システムは、ディレクトリを構築するために人的編集チームに専ら依存しており、スーパーユニットからディレクトリを構築することは、処理を自動化し、ユーザの興味及び振る舞いの変化に対してより迅速に適合するディレクトリを結果として生じさせることができる。

Ｆ．他のアプリケーション
スーパーユニットはまた他の方法により用いることもできる。例えば、いくつかの実施形態では、ウェブサイトのオペレータ又は他のエンティティは、スポンサによって提供された広告（又は単にスポンサのサイトへのリンク）が、問い合わせがそのスポンサー提供されたスーパーユニットと結合するユニットを含むときにはいつでも目立って表示されるように、スーパーユニットを「スポンサー提供」することができる。他の実施形態では、問い合わせ中の語は、スーパーユニット名と比較され、そのスーパーユニットにおける他のメンバについての関連した検索を提案することができる。さらに他の実施形態では、問い合わせの語がスーパーユニット名と一致した場合には、他の問い合わせ語に関連のあるページを、そのコンテキストがそのスーパーユニットに対応するかどうかに基づいてランク付けすることができる。

４．さらなる実施形態
特定の実施形態に関連して本発明を説明してきたが、当業者であれば、多数の変更が可能であるということが理解できよう。例えば、スーパーユニットの数及び特定性は変化させることができ、ユニットは１以上のスーパーユニットに属するものとすることができる。実装に依存して、あらゆるユニットが少なくとも１つのスーパーユニットに属するということが必要とされたり、必要とされなかったりしうる。スーパーユニット及び署名は、動的に定義することができるものであり、概念の発見及び／又は概念の分析は、ユーザの振る舞いの変化に応答して、ユニット、スーパーユニット及び／又は署名データを更新するために、時には実行することができる。上述したように、スーパーユニットを生成するためにユニットを識別しユニットを関係付けるための様々な技術を用いることができる。スーパーユニットは、概念についての実世界の関係を反映する傾向がある一方、すべてのスーパーユニット（又は任意のスーパーユニット）が任意の特定の度合いにまでそのような実世界の関係を反映することは、必ずしも必要とはされない。加えて、スーパーユニットは、階層型のディレクトリ構造、或いは、Ｙａｈｏｏ！ディレクトリのような実世界の知識から確立された他のカテゴリ分類を反映する必要はない。本明細書で説明した自動化されたシステム及び方法は、結果として生じた、ユニットディレクトリ、スーパーユニット、署名、特定のインデックスされたページ又はサイトにおけるスーパーユニットの割り当て等のうちのすべて又は部分を人間が検討することにより、拡大又は補うことができる。

本明細書で説明した実施形態は、ウェブサイト、リンク、及び、ワールドワイドウェブ（又はそのサブセット）が検索コーパスとして機能する事例において固有な他の専門用語を参照してきた。本明細書で説明したシステム及び処理は、別の検索コーパスを用いる場合にも適用できるということ、及び、その結果は、コンテントが発見される場所に対するリンク又は参照とともにコンテンツを含むことができるということを理解されたい。

以上のように、本発明を特定の実施形態に関連して説明してきたが、本発明は、添付した特許請求の範囲の技術的範囲内のすべての変更物及び均等物を含むことを意図している、ということが理解できよう。

Claims (7)

1. 複数のユニットと、各々が結合したエッジウェイトを有し前記複数のユニットの間において定められた複数の関係と、を含む概念ネットワークから、第２クラスタに基づいて第１クラスタを形成するためにコンピュータにより実行される方法であって、
   ２つ以上のユニットを含む前記第２クラスタを前記概念ネットワークから前記第１のクラスタにおけるベースクラスタとして選択する段階と、
   第１候補ユニットを前記概念ネットワークから選択する段階と、
   各々が前記ベースクラスタのメンバの少なくとも一部に対して前記概念ネットワークにおける関係を有する、前記ベースクラスタの複数の隣接語ユニットを識別する段階と、
   前記隣接語ユニットのうち少なくとも１つを、前記第１候補ユニットに対する前記概念ネットワークにおける関係を有する一致ユニットとして識別する段階と、
   前記少なくとも１つの一致ユニットを含む前記複数の隣接語ユニットに基づいて、前記第１候補ユニットについてクラスタリングウェイトを計算する段階と、
   該クラスタリングウェイトに基づいて、前記ベースクラスタを有する前記第１クラスタに前記第１候補ユニットを含むかどうかを決定する段階と、
   を含むことを特徴とする方法。
2. 第２候補ユニットを選択する段階と、
   該第２候補ユニットを用いて、前記隣接語ユニットのうちの少なくとも１つを前記一致ユニットとして識別する段階、前記クラスタリングウェイトを計算する段階を繰り返すことにより、前記第１クラスタに前記第２候補ユニットを含むかどうかを決定する段階と、を含むことを特徴とする請求項１に記載の方法。
3. 複数のユニットと、各々が結合したエッジウェイトを有し、前記複数のユニットの間において定められた複数の関係と、を含む概念ネットワークからクリークを形成するためにコンピュータにより実行される方法であって、
   各々が少なくとも１つのベースユニットを含む複数のクラスタを形成する段階と、
   開始クラスタとして前記複数のクラスタのうちの１つを選択する段階と、
   前記開始クラスタにおける前記ベースユニットのみを含むようにクリークを初期化する段階と、
   前記開始クラスタにおける各メンバユニットｕについて、
   （ａ）前記クリークの現在のメンバｑ_kの少なくとも第１部分が、前記ベースユニットとしてメンバユニットｕを有する前記クラスタのうちの１つであるクラスタＣ（ｕ）のメンバでもあり、かつ、
   （ｂ）それぞれが現在のクリークのメンバｑ_kの１つを前記ベースユニットとして有するクラスタＣ（ｑ_k）の少なくとも第２部分が、メンバユニットｕを含む場合に、前記クリークに前記メンバユニットｕを加える段階と、
   を含むことを特徴とする方法。
4. 前記第１部分は前記現在のメンバｑ_kの１００％を含み、
   前記第２部分は前記クラスタＣ（ｑ_k）の１００％を含む、請求項３に記載の方法。
5. 前記第１部分は前記現在のメンバｑ_kの７０％を含み、
   前記第２部分は前記クラスタＣ（ｑ_k）の７０％を含む、請求項３に記載の方法。
6. 前記一部は前記ベースクラスタの前記メンバの１００％を含む、請求項１に記載の方法。
7. 前記一部は前記ベースクラスタの前記メンバの２５％を含む、請求項１に記載の方法。

Images