JP2013516022A - 検索提案のクラスタ化及び提示 - Google Patents

Abstract

検索提案をクラスタ化して提示するための方法及び装置を開示する。ユーザインターフェイスの検索クエリ欄を通じて、検索クエリの一部であるテキストの一部を取得する。各々がこのテキストの一部に関する提案検索クエリである提案を含む提案セットを取得する。各々が異なる提案セット部分を含む２又はそれ以上の提案グループを生成する。この２又はそれ以上の提案グループを、これらの各々がユーザインターフェイスの検索支援部分の別個の区分内に表示されるように提供する。
【選択図】 図２Ｃ

Description

〔関連出願との相互参照〕
本出願は、２００９年１２月２８日に出願された米国特許出願第１２／６４８，２２０号の利益を主張するものであり、この特許出願は全ての目的のために引用により本明細書に組み入れられる。

本発明は、一般に、提案検索クエリのコンピュータによる検索及び提示に関する。

ワールドワイドウェブのユーザは、興味のあるコンテンツを特定するための、ウェブ上で利用できる様々なサービスに精通している。数多くのエンティティが検索エンジンを提供しており、多くのウェブサイトに検索機能が組み込まれている。例えば、ウェブサイトのコンテンツ及びインターネット全体にわたるウェブサイトをユーザが検索できるようにする検索アプリケーションを多くのウェブサイトが提供している。

多くの場合、検索エンジンは、ユーザがタイプする次の文字及び単語を予測することにより、ユーザがより速くクエリを完成させる支援をする検索提案ツールを提供する。例えば、ユーザが「ｓａｃｒ．．．，」とタイプし始めると、通常、検索ボックスの下に、「ｓａｃｒａｍｅｎｔｏ」、「ｓａｃｒａｍｅｎｔｏ ａｉｒｐｏｒｔ」及び「ｓａｃｒｅｄ ｈｅａｒｔ」などの一般的な完成形及び関連提案を示すドロップダウンウィンドウが現れる。この結果、ユーザは、完全な検索クエリをタイプする代わりに、リストから単純に選択を行うことができる。

提案検索クエリ（すなわち検索提案）をクラスタ化して提示するための方法及び装置を開示する。１つの実施形態では、ユーザインターフェイスの検索クエリ欄を通じて、検索クエリの一部であるテキスト部分を取得する。各々がこのテキスト部分に関する、又はこれを含む提案検索クエリである提案セットを取得する。各々が異なる提案セット部分を含む２又はそれ以上の提案グループを生成する。２又はそれ以上の提案グループを、各々がユーザインターフェイスの検索支援部分の別個の区分内に表示されるように提供する。

１つの態様では、２又はそれ以上の提案グループの各々に関連して、ユーザインターフェイス内で２又はそれ以上の提案グループの対応する１つのごく近くに表示されるようにラベル又は画像を提供する。このラベル又は画像は、対応する提案グループ内からの情報を使用して取得することができる。或いは、対応する提案グループ内から取得した情報に加え、又はこの代わりに、対応する提案グループ外の情報を使用してラベル又は画像を取得することもできる。

さらに別の態様によれば、検索クエリの提出部分に基づいて検索クエリが曖昧であると判定された場合、提案セットをクラスタ化することができる。例えば、提案セットの最初のクラスタ化により、大幅に異なるサイズの提案グループが生じた場合、検索クエリが曖昧となり得る。

別の実施形態では、本発明は、プロセッサ、メモリ及びディスプレイを含む装置に関する。プロセッサ及びメモリは、上述した方法動作の１又はそれ以上を実行するように構成される。別の実施形態では、本発明は、上述した方法動作の１又はそれ以上を実行するように構成されたコンピュータプログラム命令を記憶するコンピュータ可読記憶媒体に関する。

以下の本発明の明細書、及び本発明の原理を一例として例示する添付図面に、本発明のこれらの及びその他の特徴及び利点をより詳細に示す。

様々な実施形態を実施できるシステム例を示すブロック図である。 検索クエリ提案リストを提示するグラフィカルユーザインターフェイス例を示す図である。 提案リストのクラスタ化を行った後の提案グループ例を示すグラフィカルユーザインターフェイスである。 提案リストのクラスタ化を行った後の提案グループ例を示すグラフィカルユーザインターフェイスである。 本発明の様々な実施形態による、提案セットをクラスタ化して提示する方法例を示す処理フロー図である。 ユーザがユーザインターフェイスの検索クエリ欄に「ｓａｌｓａ」とタイプしたときにユーザに提供できる提案例を示す図である。 様々な実施形態を実施できるネットワーク環境例を示す略図である。 様々な実施形態を実施できるコンピュータシステム例を示す図である。

ここで、本発明の特定の実施形態を詳細に参照する。これらの実施形態例を添付図面に示す。これらの特定の実施形態とともに本発明を説明するが、本発明をこれらの実施形態に限定する意図はないことを理解されたい。むしろ、代替物、修正物、及び同等物を、添付の特許請求の範囲により定められる本発明の思想及び範囲に含むことができるものとして網羅することを意図する。以下の説明では、本発明を完全に理解できるように数多くの特定の詳細を記載する。これらの特定の詳細の一部又は全部を伴わずに本発明を実施することもできる。その他の場合、本発明を不必要に曖昧にしないように、周知の処理動作については詳細に説明していない。

開示する実施形態は、検索クエリの一部を受け取ったことに応答して検索提案を提供するためのユーザインターフェイスを提供するものである。より詳細には、各検索提案を、検索クエリの一部に関する、又はこれを含む（例えば、完成させた又は訂正した）提案検索クエリとすることができる。従って、「提案」、「検索提案」、「提案検索クエリ」、「完成クエリ」、「提案検索完成クエリ」、及び「完成クエリ提案」という用語は同義的に使用することができる。

ユーザに提供する検索提案を２又はそれ以上のグループに分類することができ、このグループをクラスタ又は区分と呼ぶことができる。検索提案のクラスタ化は、複数の解釈が可能な曖昧なクエリに対して特に有用となり得る。より詳細には、検索クエリの既に入力されている部分の異なる解釈に基づいて検索クエリを分類することができる。

ユーザがタイピングを行う（例えば、１又はそれ以上の文字を追加、修正、及び／又は削除する）につれ、提供する検索提案は変化する。同様に、検索提案のクラスタ化も、ユーザが検索クエリをタイプするにつれて動的に行われる。従って、提案グループの数、各提案グループ内の提案数、及び提案をグループ化する方法も、ユーザがクエリの一部をタイプするにつれて動的に変化する。換言すれば、以下で詳細に説明するように、ユーザが検索クエリの少なくとも一部を修正、追加、及び／又は削除すると、提案のクラスタ化が開始される。

近年、何百万ものユーザにとって、インターネットが主な情報源になっている。これらのユーザは、自分が興味のある情報を検索するためにインターネットに依拠する。ユーザが情報を検索するための１つの従来の方法は、検索サービスのウェブページを通じて検索クエリを開始することである。通常、ユーザは、検索ウェブページ上の入力ボックスに１又はそれ以上の検索語を含むクエリを入力し、このような入力した検索語に基づいて検索を開始することができる。このクエリに応答して、一般に、ウェブ検索エンジンが、順序を付けた検索結果文献のリストを戻す。

文献は、この文献が存在し得る場所を識別するユニフォームリソースロケータ（ＵＲＬ）として定義することができる。文献は、特定のウェブサイト、及びウェブサイト上の特定のウェブページ上に存在することができる。例えば、文献が存在するウェブページの場所を第１のＵＲＬによって識別することができ、文献が存在し得るウェブサイトの場所を第２のＵＲＬによって識別することができる。

図１に、本発明の様々な実施形態を実施できるネットワークセグメント例を示す。図示のように、複数のクライアント１０２ａ、１０２ｂ、１０２ｃが、ネットワーク１０４を介して、例えば検索サーバ１０６上の検索アプリケーションにアクセスすることができ、及び／又は以下でより詳細に説明するように、グラフィカルユーザインターフェイスを介して、例えばウェブサーバ１１４上のウェブサービスにアクセスすることができる。このネットワークは、ワイドエリアネットワーク又はインターネット及び／又は１又はそれ以上のローカルエリアネットワーク（ＬＡＮ）などのいずれかの適当な形をとることができる。ネットワーク１０４は、各クライアントから検索アプリケーション又はウェブアプリケーションに検索オブジェクト要求又はウェブオブジェクト要求を転送して、要求側クライアントに検索結果又はウェブ結果を転送するための、ルータ及びスイッチなどのいずれかの適当な数及び種類の装置を含むことができる。

本発明は、例えば、ＴＣＰ／ＩＰベースのネットワーク、通信ネットワーク、無線ネットワークなどを含む（ネットワーク１０４によって示す）様々なネットワーク環境内で実施することもできる。また、本発明の実施形態を実施するコンピュータプログラム命令を、あらゆる種類のコンピュータ可読媒体に記憶することができ、クライアント／サーバモデル、ピアツーピアモデル、独立型コンピュータ装置を含む様々な計算モデルに従って、或いは本明細書で説明する様々な機能を異なる場所で実現又は利用できる分散型計算モデルに従って実行することができる。

一般に、検索アプリケーションは、ネットワーク１０４を介してアクセスできるとともに１又はそれ以上の検索語を含む検索クエリに関する情報をユーザ（人間又は自動化エンティティ）が検索できるようにするものである。ユーザは、あらゆる方法で検索語を入力することができる。例えば、以下でさらに詳細に説明するようなグラフィカルユーザインターフェイスがクライアント（例えば、クライアントの装置上）に入力機能を提供することができ、これによりクライアントは、１又はそれ以上の検索語を含むクエリを入力することができる。特定の実施構成では、このグラフィカルユーザインターフェイスが、ユーザがあらゆる数の検索語又はその一部を含むクエリをタイプできるようにする入力ボックス（すなわち、検索クエリ欄）を提供する。詳細には、グラフィカルユーザインターフェイスが、検索クエリの少なくとも一部を受け取るための検索クエリ欄と、この検索クエリに関連する提案検索クエリ（すなわち、検索提案）を提供できる別の部分とを提供することができる。その後、ユーザは、これらの提案検索クエリの１つを選択し、グラフィカルユーザインターフェイスを介して検索エンジンに提出することができる。

この結果、（検索サーバ１０６及び／又はウェブサーバ１１４などに関連する）１又はそれ以上の検索アプリケーション及び／又は１又はそれ以上のデータソースを介して検索クエリを実行することができる。本発明の実施形態は、あらゆる検索アプリケーションに関して利用することができる。検索アプリケーションは、いずれの数のサーバ上でも実行することができるが、明確にするために１つの検索サーバ１０６しか示していない。

検索サーバ１０６（又は複数のサーバ）は、検索情報を保持する１又はそれ以上のクエリログ１１０にアクセスすることができる。例えば、このクエリログ１１０を、検索サーバ１０６に接続された１又はそれ以上のメモリに保存することができる。ユーザが１又はそれ以上の検索語に基づく検索を行うたびに、このような検索に関する情報をクエリログ１１０に保持することができる。例えば、ユーザの検索要求は、ユーザ又はブラウザの識別情報及び検索語などのあらゆる数のパラメータを含むことができ、これらをクエリログ１１０内に保持することができる。クエリログ１１０には、検索要求パラメータとともに、検索に関するタイムスタンプなどの追加情報も保持することができる。入力した検索語に基づいてユーザに結果を提示する際に、このような検索結果からのパラメータもクエリログ１１０に保持することができる。例えば、クエリログ１１０には、ウェブサイト、検索結果の提示順、各検索結果がスポンサー付きであるか、それともアルゴリズム的検索結果であるか、各検索結果の所有者（ウェブサイトなど）、各検索結果（もしあれば）がユーザにより選択（すなわちクリック）されたかどうか、及び／又はタイムスタンプなどの、特定の検索結果も保持することができる。

検索サーバ１０６は、検索クエリを受け取ると、このクエリに関する適当なウェブページを識別して提示することができる。例えば、検索サーバ１０６は、検索クエリに関するコンテンツを識別する複数のハイパーテキストリンク、及びこれらの複数のハイパーテキストリンクに関連する概要又は要約を識別して提示することができる。

本明細書で開示する実施形態は、検索サーバ（又はその他のサーバ）１０６及び／又はクライアント１０２ａ、１０２ｂ、１０２ｃを介して実施することができる。例えば、クライアント１０２ａ、１０２ｂ、及び１０２ｃ上のウェブブラウザ及び／又はアプリケーションを介して様々な機能を実現することができる。開示する実施形態は、ソフトウェア及び／又はハードウェアを介して実施することができる。

検索エンジンは、ユーザが検索に関する作業を行う上での努力を軽減する方法の探求を深めている。このような努力の結果、ユーザがクエリを作成している間に考えられる検索クエリの完全形を自動的に提案するオートコンプリション機構が広く使用されるようになった。しかしながら、従来のオートコンプリート機構が提供する検索提案は、特に完全形の組がクエリの異なる解釈で構成されて交互配置で表示される場合、ユーザにとって分かりにくいことがある。

図２Ａは、従来のオートコンプリション機構を通じて提供される提案検索クエリを例示するグラフィカルユーザインターフェイス例を示す図である。ユーザが、検索エンジンに付随するグラフィカルユーザインターフェイスの検索クエリ欄２０２内にｈａｉｆａという文字列をタイプすることによって検索エンジンクエリを開始した場合について検討する。ユーザが、グラフィカルユーザインターフェイスの検索クエリ欄２０２内にタイプすると、このユーザの入力を検索クエリの一部として処理することができる。この検索クエリの一部は、１又はそれ以上の文字、及び１又はそれ以上の単語又はその一部を含むことができる。この例では、検索クエリの一部が検索クエリプレフィクスとして処理される。この検索クエリプレフィクスでは、主検索エンジンにより提示される提案セットが、２０４に示すような順序付きリストを含むことができる。

クリック行動、クエリ頻度、又はクエリ再編成などの、過去のユーザ行動に基づく様々な因子により、検索エンジンが提供する提案検索完成クエリの組（すなわち検索提案）を決定することができる。開示する実施形態は、オートコンプリートの提案をトピックごとに分類することにより、現在のクエリ完成方法を拡張することができる。

図２Ａに示すように、完成クエリ提案は、同一でない実在のエンティティ、ファセット、又はトピックに対応することができる。例えば、位置１、２、及び５の提案は人気のあるエンターテイナーに対応するが、位置３及び６の提案は都市に対応する。さらに、同様の又は同じファセット又はトピックに関連するクエリ提案をともにグループ化することはできず、従って提案が主題的観点から非順序付きリストとして提示されることもある。

図２Ａに示すように、検索クエリ（又はその一部）が異なる意味を有する可能性がある場合、提案は、検索クエリの既に提供されている部分の異なる解釈に関連することができる。さらに、通常、これらの提案は人気のみによってソートされ、異なる解釈に対応する提案が交互配置で提供される。開示する実施形態は、提案検索クエリをグループ化して、最も関連性の高い検索提案を含む検索クエリのグループをユーザが容易に識別できるようにする。

図２Ｂ〜図２Ｃは、様々な実施形態に基づいて提示できるグラフィカルユーザインターフェイス例を示すスクリーンショットである。図２Ｂ〜図２Ｃに示すように、開示する実施形態では、提案クエリの組がグラフィカルユーザインターフェイスを通じてクラスタ化されて提示されるようにすることができる。さらに、図２Ｂ及び図２Ｃにそれぞれ示すように、各クラスタをグラフィカルユーザインターフェイス内のラベル又は画像によって識別することができる。

図２Ｂ及び図２Ｃに示すように、ユーザがグラフィカルユーザインターフェイスの検索クエリ欄２０２内に「Ｈａｉｆａ」という検索クエリ部分を入力すると、この検索クエリ部分を含む提案セットを（１又はそれ以上の検索クエリログなどを介して）取得することができる。この提案セットを、実在のエンティティ、ファセット、トピック又はその他の基準に基づく１又はそれ以上のクラスタ化法を使用して、２又はそれ以上の提案グループにクラスタ化することができる。例えば、各提案グループを、グラフィカルユーザインターフェイスの別個の区分又は区分内に提示することができる。

さらに、対応する提案グループを区別する上でユーザを支援するために、各提案グループを識別する適当なラベル又は画像を確認し、提案グループに関連して提供することができる。図２Ｂ〜図２Ｃに示すように、２又はそれ以上の提案グループの各々に関連して、対応するグループに関連して提供されるようにラベル又は画像を表示することができる。例えば、これらのラベル又は画像を、ユーザインターフェイス内の２又はそれ以上の提案グループの対応するグループのごく近くに表示することができる。

図２Ｂに示すように、各提案グループ又はグラフィカルユーザインターフェイスの対応する区分に関連して異なるラベルを表示することができる。例えば、区分２０６内に表示された第１の提案グループには、２０８に表示される「Ｈａｉｆａ（歌手）」というラベルを割り当て、区分２１０内に表示された第２の提案グループには、２１２に表示された「Ｈａｉｆａ（都市）」というラベルを割り当てることができる。

同様に、図２Ｃに示すように、各提案グループ又はグラフィカルユーザインターフェイスの区分に関連して異なる画像を表示することもできる。例えば、区分２１４内に表示された第１の提案グループを、２１６に表示される画像によって識別することができ、区分２１８内に表示された第２の提案グループを、２２０に表示される画像によって識別することができる。

ユーザが提案グループの１つの中の提案の１つを選択すると、この選択した提案に関連する検索結果を取得して提供することができる。このようにして、開示する実施形態は、ユーザ検索処理を容易にすることができる。

図３は、様々な実施形態による、検索提案のクラスタ化を実行する方法例を示す処理フロー図である。３０２において、ユーザインターフェイスの検索クエリ欄を通じて、検索クエリの一部であるテキストの一部を取得することができる。より詳細には、この検索クエリの一部を検索クエリの最初の部分とすることができ、これを検索クエリの「プレフィクス」又は「クエリプレフィクス」と呼ぶことができる。例えば、このクエリプレフィクスは、ユーザが検索クエリを作成する間にタイプした文字列であってもよい。或いは、この検索クエリの一部を、対象の検索クエリの中央部又は最後部とすることもでき、これらをそれぞれ「インフィクス」又は「サフィックス」と呼ぶことができる。

３０４において、テキスト部分を含む提案検索クエリである各提案を含む提案セットを取得することができる。提案セットは、ユーザが入力したテキスト（クエリプレフィクスなど）を含むクエリを求めて検索クエリのデータベースを検索することにより取得することができる。検索クエリのデータベースは、ユーザに関連するものであってもよく、又は複数のユーザのデータを記憶するグローバルデータベースであってもよい。一般に、これらの提案は、対応する検索クエリの人気に従って順序付けされる。

１つの実施形態では、提案セットから、検索クエリが曖昧なクエリであるかどうかを判定することができる。検索クエリの以前に入力された部分について複数通りの解釈が考えられる場合、この検索クエリを曖昧と判定することができる。例えば、提案セットを最初にクラスタ化したときの各提案グループ内の提案数に基づいて、クエリを曖昧と判定することができる。より詳細には、提案が２又はそれ以上のグループに該当する場合、クエリを曖昧と判定することができる。しかしながら、１つのグループ内の提案数が別のグループに比べて非常に少ない場合、これはクエリが曖昧でないことを示すことができる。検索クエリが曖昧なクエリである場合、ブロック３０６及び３０８を参照しながら以下で説明するように、提案セットをクラスタ化することができる。

３０６において、各々が異なる提案セット部分を含む２又はそれ以上の提案グループを生成することができる。より詳細には、提案セット内の各提案に関連する１又はそれ以上の特徴セットを取得することができる。次に、提案セット内の各提案に関連する２又はそれ以上の特徴セットを適用して２又はそれ以上の提案グループを生成することができる。これらの特徴は、提案及び／又はこの提案を使用して検索クエリが実行されたときに取得される検索結果の少なくとも一部から取得することができる。例えば、特定の提案の特徴は、提案内の１又はそれ以上の単語セット及び／又は検索結果内の１又はそれ以上の単語セットを含むことができる。特定の提案に関する検索結果内の単語は、１又はそれ以上の文献のタイトル、要約、及び／又はユニフォームリソースロケータ（ＵＲＬ）内に見出される単語を含むことができる。特定の提案の特徴は、この提案に関連するクリックスルーデータを含むこともできる。以下、様々な特徴を取得して適用するための様々な機構についてさらに詳細に説明する。

提案グループを生成すると、この提案グループを再グループ化することが望ましいことがある。例えば、特定の提案グループ内の提案数が別の提案グループ内の提案数よりも大幅に少ない場合、再グループ化を行うことが望ましい。

２又はそれ以上の提案グループを提示するかどうかを判定することが望ましいこともある。例えば、クエリが曖昧でないと判定されることがある。クエリが曖昧でないと判定された場合は、２又はそれ以上の提案グループを提供（例えば表示）しなくてもよい。

クエリが曖昧な場合、３０８において、２又はそれ以上の提案グループを、これらの提案グループの各々がユーザインターフェイスの検索支援部分の別個の区分内に表示されるように提供することができる。例えば、ユーザインターフェイスの検索支援部分内に、区分を連続的に提示することができる。以下、検索支援部分内で提案グループを順序付けするための様々な方法についてさらに説明する。

特定の提案グループ内の提案も、様々な方法によって順序付けすることができる。例えば、特定の提案グループ内の提案を、検索クエリのように提案の実行又は選択の人気順に表示することができる。特定の提案の検索クエリとしての人気は、現在の検索クエリを入力しているユーザのクエリログデータを使用して確認することができる。或いは、特定の提案の検索クエリとしての人気を、複数のユーザのクエリログデータを使用して確認することもできる。

さらに、２又はそれ以上の提案グループの各々を識別するラベル又は画像を、これらのラベル又は画像が対応する提案グループに関連して表示されるように提供することができる。例えば、ラベル又は画像を、検索支援部分の対応する区分に関連して表示することができる。より詳細には、２又はそれ以上の提案グループに関連するラベル又は画像を、ユーザインターフェイスの検索支援部分の対応する部分に提供することができる。以下、提示される特定の提案グループのラベル又は画像を識別又は生成するための様々な方法についてさらに詳細に説明する。

１．提案のクラスタ化
２又はそれ以上の提案グループを、これらの提案グループ間で提案セットが分割されるように生成することは、数学的問題として定義することができる。

問題：クエリの一部（プレフィクスｐなど）及び提案セット（順序付き提案セットなど）（Ｓ＝｛ｓ１，ｓ２，．．．，ｓｎ｝）が与えられた場合、Ｓをｋ個の互いに素な区分（順序付き区分など）に区分化し（Ｐ＝｛Ｐ１，Ｐ２，．．．，Ｐｋ｝）、全てのｓｉが正確に１つのＰｊに属し、全てのＰｊの要素が主題的にコヒーレントである（すなわち、クエリｑの単一の主題又は側面を示す）ようにすることができること。Ｓを区分化した後、各区分に明確なラベルＬ（及び／又は画像Ｉ）を割り当て、これらの主題又は側面が区分Ｐ（ｊ）の要素には共通するが、Ｓ内の要素の残りには共通しないことをＬ（Ｐｊ）又はＩ（Ｐｊ）がユーザに指示又は記述するようにすることができること。より詳細には、区分Ｐ（ｊ）の要素に共通の主題又は側面を識別し、この識別された主題又は側面を表すラベル又は画像を取得することができること。また、区分Ｐ（ｊ）及び／又は区分Ｐ（ｊ）の各々における提案を、ユーザに対する組Ｓの有用性を最大化するようにランク付けすることもできること。

クエリの一部（クエリプレフィクスなど）に基づいて提案セットを２又はそれ以上の提案グループに区分化するために、様々なクラスタ化機構を適用することができる。以下、３つの異なるクラスタ化機構について説明する。以下の説明では、提案セット内の提案により共有されるクエリ部分をクエリプレフィクスと仮定する。しかしながら、クエリの共有される部分はクエリ内の異なる箇所に存在し得る点に留意することが重要である。

クラスタ化作業を、クラスタ化される要素（提案など）のいずれか２つの間の類似性（又は距離）を発見する作業に軽減することができる。以下で説明する３つのクラスタ化機構の例は、クエリの一部に関して提供する提案セット内の２つの提案間の類似性を推定する様々な方法を提供するものである。

１．１ 見出語のクラスタ化
ユーザが検索クエリをタイプするにつれて提供される提案の多くは、ユーザ入力をプレフィクスとして処理する完全形である。たまに、このユーザ入力がサフィックス又はインフィクスとして処理されることがある。この結果、組Ｓが、語彙レベルで既に非常に類似していることがある。一般に、ユーザが提供したクエリプレフィクスをｐとし、特定の提案ｓｉに追加された追加コンテキスト（１又はそれ以上の文字など）をｃｉとした場合、提案ｓｉを、
と見なすことができる。ユーザにより入力されたクエリ部分をクエリプレフィクスとする場合、追加コンテキストｃｉを、クエリプレフィクスに続く１又はそれ以上の文字とすることができる。或いは、追加コンテキストｃｉは、このクエリ部分の前の１又はそれ以上の文字及び／又はこのクエリ部分の後の１又はそれ以上の文字を含むことができる。入力されたクエリ部分の前及び／又は後の（単複の）文字は、１又はそれ以上の単語又はその一部を含むことができる。

図４は、ユーザがユーザインターフェイスの検索クエリ欄内に「ｓａｌｓａ」とタイプしたときにユーザに提供できる提案例を示す図である。この例に示すように、これらの提案は、プレフィクスｐを既に共有している。提案ｓｉが属するクラスタを識別するために有用となり得る用語は、ほとんどがこの提案ｓｉの追加コンテキストｃｉ内に存在する。

１つの実施形態では、各提案ｓｉから、最も代表的な、すなわち提案ｓｉを提案の残りと最も区別する単一の用語を選択することができる。次に、これらの用語を使用して、Ｓにクラスタ化を行うことができる。図４に示す例では、区別的な用語は、「レシピ（ｒｅｃｉｐｅｓ）」、「ダンシング（ｄａｎｃｉｎｇ）」、「ダンス（ｄａｎｃｅ）」、「音楽（ｍｕｓｉｃ）」、「歌手（ｓｉｎｇｅｒ）」、「ホームメード（ｈｏｍｅｍａｄｅ）」、「レッスン（ｌｅｓｓｏｎｓ）」、及び「クラス（ｃｌａｓｓｅｓ）」である。これらの用語の各々を、対応する提案ｓｉの「見出語」と呼ぶことができる。

提案セットＳ内の各提案ｓｉを解析して、１又はそれ以上の単語セットを取得することができる。次に、提案ｓｉごとに、１又はそれ以上の単語セット内の「見出語」（代表的な語など）を識別することができる。従って、提案セット内の各提案ｓｉに関連する特徴セットは、提案の見出語を含むことができる。

提案の見出語間の類似性を確認し、従って提案ｓｉ間の類似性を確認するために、意味的又は主題的な単語レベルの類似性を推定するための様々な方法を適用することができる。一般的な方法として、Ｗｏｒｄｎｅｔなどの、大規模コーパス又は語彙資源内の単語コンテキストに基づく方法がある。例えば、情報検索（ＩＲ）を使用する自己相互情報量（ＰＭＩ）（ＰＭＩ−ＩＲ）は、２つの単語｛ｗｉ，ｗｊ｝間の類似性を確認するために使用できる単純な共起技術である。２つの単語｛ｗｉ，ｗｊ｝間の類似性は、単語間の自己相互情報量として定義することができ、コーパスにおける最大発生可能性を使用して単一の単語の可能性、Ｐ（ｗｉ）及び結合可能性Ｐ（ｗｉ，ｗｊ）が推定される。詳細には、この場合の単語間の類似性尺度を以下のように定義することができる。

式中、ｃｏｕｎｔｓ（ｘ）は、ｘを含む文献の組であり、ｎはコーパスサイズ（検索結果数など）である。２つの提案間の類似性は、見出語間の類似性とすることができる。

見出語の選択
ウェブクエリの平均長さが短いことにより、追加コンテキストｃｉは、単一の用語を含むことが多い。従って、この単一の用語を提案ｓｉの見出語として使用することができる。しかしながら、追加コンテキストｃｉが２又はそれ以上の用語を含む場合もある。従って、特定の提案ｓｉの見出語を選択するための様々な方法を使用して、これらの用語から見出語を選択することができる。以下、いくつかの方法例を説明する。

最初の単語：追加コンテキストｃｉの最も左側の単語を選択する。例えば、提案が「ｓａｌｓａ ｓｉｎｇｅｒ ｃｒｕｚ」である場合、追加コンテキストｃｉは「ｓｉｎｇｅｒ ｃｒｕｚ」であり、最初の単語は「ｓｉｎｇｅｒ」である。

最後の単語：追加コンテキストｃｉの最も右側の単語（例えば、「ｓａｌｓａ ｓｉｎｇｅｒ ｃｒｕｚ」という提案ではｃｒｕｚ）を選択する。

頻度：追加コンテキストｃｉ内の単語ごとに、用語頻度（ｔｆ）値と逆文献頻度（ｉｄｆ）値の積（ｔｆ・ｉｄｆ）を計算し、この場合、ｔｆを計算するために使用できる「文献」は、クラスタ化する提案セットＳ内の全ての単語を含むことができ、ユーザ入力の全ての提案セットＳにわたってｉｄｆが計算される。


ｔｆ・ｉｄｆ値が最も高い単語を選択することにより、特定の提案ｓｉの見出語を選択することができる。

１．２ 結果セットのクラスタ化
２つのクエリ提案間の類似性を確認するために、クエリ提案の各々に関連する検索結果を活用することができる。対応するクエリ提案の上位Ｎ個にランクされる検索結果（文献など）内で見出される用語の対応するｔｆ・ｉｄｆ値を使用して、提案クエリの各々を表すことができる。従って、提案セット内の各提案に関連する特徴セットは、対応する検索結果セット内の単語セットを含むことができ、或いはこれに基づくことができる。

クエリ提案ｓｉが与えられると、検索エンジンによって戻される提案ｓｉの上位Ｎ個の文献の検索結果セットＲ（ｓｉ）を取得することができる。各文献ｄ∈Ｒ（ｓｉ）は、タイトル、要約、及びユニフォームリサーチロケータ（ＵＲＬ）を含むことができる。要約は、クエリ内の用語及びこの用語を取り巻く少量のコンテキストを含む、ユーザに示される文献ｄの一部とすることができる。従って、上位Ｎ個の検索結果の各々のタイトルｔ（ｄ）、要約ａ（ｄ）、及び／又はＵＲＬｕ（ｄ）内の１又はそれ以上の単語のｔｆ・ｉｄｆ値を確認することができる。

１つの実施形態では、各文献の要素（タイトル、要約、及び／又はＵＲＬ）を、その中に現れる用語のｔｆ・ｉｄｆベクトル、すなわち各位置が１つの単語のｔｆ・ｉｄｆ値を記憶するベクトルによって表すことができる。この文献要素ベクトルを、上位Ｎ個の文献の各々について確認することができる。特定の提案ｓｉに関する文献全てにわたる要素ベクトルの各々の中央値（平均ベクトルなど）を取得することにより、結果セットＲ（ｓ）の文献要素ベクトルを取得することができる。例えば、結果セットＲ（ｓｉ）を定義する上位Ｎ個の文献タイトルに関するベクトルタイトル（ｄ）の中央値を取得することにより、結果セットＲ（ｓｉ）のベクトルタイトル（ｓｉ）を取得することができる。特定の提案ｓｉに関する結果セットＲ（ｓｉ）に対応するベクトルタイトル（ｄ）、要約（ｄ）、及び／又はｕｒｌ（ｄ）を連結することにより、その提案ｓｉに関する単一のベクトル（ｖｓ）を取得することができる。この処理を、各提案ｓｉに対して行うことができる。２つの異なる中心値ベクトル間の類似性（ｖｓ）を確認するために、余弦類似性関数などの類似性関数を適用することができ、従って２つの対応する提案ｓｉ間の類似性は、これらのドット積となる。
Ｓｉｍ（Ｓ_i，Ｓ_j）＝ｖ_si・ｖ_sj

１．３ クリックベースのクラスタ化
提案セットＳを２又はそれ以上のグループに分割するために、検索エンジンが保持するクリックスルーデータを活用することができる。クリックスルーデータは、１又はそれ以上のユーザがクリックした、このユーザに提示される検索結果のＵＲＬに関する情報を含むことができる。例えば、検索ログが、「ｐｉｎｅａｐｐｌｅ ｓａｌｓａ」という特定のクエリ提案に関する、複数のユーザにわたる３つの異なるクリックされたＵＲＬを含むものとする。
ＵＲＬ１：ｗｗｗ．ａｌｌｒｅｃｉｐｅｓ．ｃｏｍ／ｐｉｎｅａｐｐｌｅ−ｓａｌｓａ／ｄｅｔａｉｌ．ａｓｐｘ
ＵＲＬ２：ｗｗｗ．ｃｏｏｋｓ．ｃｏｍ／ｒｅｃ／ｐｉｎｅａｐｐｌｅ＿ｓａｌｓａ．ｈｔｍｌ
ＵＲＬ３：ｗｗｗ．ｂｌｏｇｃｈｅｆ．ｎｅｔ／ｐｉｎｅａｐｐｌｅ−ｓａｌｓａ−ｒｅｃｉｐｅ／

特定のクエリ提案ｓｉのクリックスルーデータを使用して、各提案ｓｉを検索クエリの一部（クエリプレフィクスなど）に関して、この提案に関連するクリックされたＵＲＬの組ごとに特徴付けることができる。同様のユーザクリック動作が行われた提案は、同じグループにまとめることができる。より詳細には、異なるクエリによって同じＵＲＬの１又はそれ以上がクリックされた場合、同様のユーザの意図を捕捉することができる。例えば、「ｐｉｎｅａｐｐｌｅ ｓａｌｓａ ｆｏｒ ｆｉｓｈ」というクエリ提案が、上記ＵＲＬの１つのクリックをもたらした場合、２つの提案が類似していることを示す。

ウェブサイトは、１つの概念につき１つのウェブページに専心する傾向にあるので、クリックされたＵＲＬを使用することで、特定の表現が限定的すぎることが判明するようになる。従って、特定のクリックされたＵＲＬではなく、むしろクリックスルーデータから得られるベースＵＲＬを使用することができる。例えば、ＵＲＬ１をｗｗｗ．ａｌｌｒｅｃｉｐｅｓ．ｃｏｍに一般化することができる。従って、特定のウェブページに関連するＵＲＬよりもむしろウェブサイトに関連するＵＲＬを使用することができる。

また、ｗｗｗ．ｗｉｋｉｐｅｄｉａ．ｏｒｇなどの情報又は百科事典ウェブサイトは、好ましくない偏向をもたらし、同じクラスタ内に類似しない概念が配置されるようになる。同様に、ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍなどのその他のウェブサイトも、このような偏向をもたらす場合がある。この問題に対処するために、以下にさらに詳細に説明するように、各提案を文献として処理し、各ベースＵＲＬの逆文献頻度を計算し、これを、表現を生成する際の重みとして使用することができる。或いは、これらの逆文献頻度に基づいて１又はそれ以上のＵＲＬを削除することもできる。より詳細には、逆文献頻度は、クエリログ内で提案が行われた頻度の逆数を表すことができる。

クリックスルーデータを使用してクエリ提案を表すこともできる。より詳細には、プレフィクスｐ及びこれに関連する提案セットＳを所与として、ｐのクリックスルーグラフを定義することができる。クリックスルーグラフは、提案ノード（ｓノード）とベースＵＲＬノード（ｕノード）という２つのノードクラス、及び有向エッジＥの組を含む２分グラフとして定義することができる。提案セットＳ内の各提案をｓノードとして表すことができる。ｕノードを生成するためには、各提案に関連するベースＵＲＬの組の和集合をとり、異なるベースＵＲＬごとに１つのノードを生成することができる。提案ノードｓとＵＲＬノードｕの間のエッジｓ−＞ｕは、ｓがクエリとして発行されたときにＵＲＬｕがクリックされたことを示す。各エッジには、ｓがクエリとして発行されたときにＵＲＬｕがクリックされた回数である重みを割り当てることができる。

クリックスルーグラフを使用して、グラフ内の提案ｓごとに、グラフ内のＵＲＬノードの数に等しいサイズのＬ２−標準化特徴ベクトルを生成することができ、ベクトルの各大きさはグラフ内のＵＲＬを表す。ＵＲＬｊに関連する大きさの値は、次のように計算することができる。
提案ｓとｊの間にエッジが存在する場合：

そうでない場合：０。
式中、Ｕは、クリックスルーグラフ内のＵＲＬの組であり、Ｗ_sjは、クリックスルーグラフ内のエッジｓ−＞ｊに関連する重みである。プレフィクスｐに関する２つの提案間の類似性を計算するために、余弦類似性関数などの類似性関数を使用して、以下のように類似性メトリックを生成することができる。

１．４ クラスタ化アルゴリズム
Ｓ内の全ての提案対間の類似性が得られると、上述した３つの方法の１つを使用してクエリプレフィクスを定義し、これをクラスタ化のための類似性尺度として使用することができる。次に、クラスタ化アルゴリズムを使用し、対応する類似性尺度を使用して、類似する提案がともにグループ化されるように提案をグループ化することができる。より詳細には、２つの異なる提案間の類似性が推定されると、階層凝集型クラスタ化などの教師なしクラスタ化アルゴリズムを使用して、提案を２又はそれ以上のクラスタに区分することができる。

２．クラスタのラベル付け
提案セットＳが２又はそれ以上のグループに区分されると、各提案グループに異なるラベル又は画像を割り当て、対応する提案グループに関連して表示することができる。このようにして、対応する提案グループの主題を示すための視覚キューを提供することができる。以下、提案グループにラベル又は画像を割り当てる様々な方法について詳細に説明する。

２．１ 最高頻度提案（ＭＦＳ）
クエリ提案のクラスタのラベル（又は画像）を選択する１つの方法は、クラスタ内の最も代表的な提案を選択することである。クラスタ内の提案は全てクエリであるため、最も代表的な提案を選択する１つの方法は、（クエリログになど基づいて）ユーザにより提示及び／又はクリックされた頻度が最も高い提案を選択することである。より詳細には、ＭＦＳによって提案Ｓの特定のクラスタに割り当てられるラベルは、以下のようになる。

式中、Ｆｒｅｑ（ｘ）は、クエリログ内でｘが観察される回数である。

提案グループ内の最も代表的な提案が識別されると、この代表的な提案に関連するラベル及び／又は画像を取得して提供（例えば、表示）することができる。例えば、ラベルは、単純に代表的な提案（「看護」など）であってもよい。別の例として、「看護」というラベルではなく看護師の画像を提供してもよい。

２．２ 最長の共通部分列（ＬＣＳ）
多くの場合、文字列は、他のクラスタ内の提案と共有されるのではなく、クラスタ内の提案間で共有される。例えば、ユーザにより提出された「ｕｓ ａ」というクエリの一部を、（両方とも１つのクラスタ内にある）「ｕｓ ａｉｒｗａｙｓ」及び「ｕｓ ａｉｒｗａｙｓ ｆｌｉｇｈｔｓ」、並びに（異なるクラスタ内にある）「ｕｓ ａｒｍｙ」及び「ｕｓ ａｒｍｙ ｊｏｂｓ」に完成させることができる。クエリ提案のクラスタのラベルとして（或いは画像を選択するために）、提案の最も長い共通部分列を使用することが望ましいことがある。提案セットＳのＬＣＳは、以下のように示すことができる。
ＬＣＳ（Ｓ）＝
式中、Ｑ（Ｓ）は、いずれかの提案の部分列の組ｓ∈Ｓである。例えば、ＬＣＳ法により、「ｎｕｒｓｉｎｇ ｈｏｍｅ」、「ｎｕｒｓｉｎｇ ｈｏｍｅ ｃｏｍｐａｒｅ」、及び「ｎｕｒｓｉｎｇ ｈｏｍｅ ｃｏｓｔｓ」を含む検索クエリ提案セットに割り当てることができるラベルは、「ｎｕｒｓｉｎｇ ｈｏｍｅ」である。従って、２又はそれ以上の提案グループに共通する文字列が識別されると、この提案グループに共通する文字列に関連する（例えば、これを識別する）ラベル又は画像を提供（例えば、表示）することができる。

２．３ 結果セット内の最高頻度（ＭＦＲＳ）
ＭＦＳ及びＬＣＳ法の１つの欠点は、そのクラスタに属する提案からクラスタのラベルを生成する点である。しかしながら、提案クラスタによっては、クラスタ内の提案からだけでは意味のあるラベルを確認できないものもある。これらの場合、クラスタ外の資源を使用してクラスタのラベルを取得することができる。例えば、「ｌｏｓ ａｎｇｅｌｓ ｄａｉｌｙ ｎｅｗｓ」、「ｌｏｓ ａｎｇｅｌｓ ｔｉｍｅｓ」、及び「ｌｏｓ ａｎｇｅｌｓ ｔｉｍｅｓ ｎｅｗｓｐａｐｅｒｓ」という提案を含むクラスタでは、有用なラベルを「ｌｏｓ ａｎｇｅｌｓ ｎｅｗｓｐａｐｅｒｓ」とすることができ、このラベルは、クラスタ内の提案の全てと部分的にしか重ならない。

クラスタ化自体を行う場合と同様に、各提案の上位にランクされた文献の組（検索エンジンに提出されたクエリとして使用される場合）をこの外部知識に使用することができる。より詳細には、各検索クエリ提案を、対応する文献の組を取得するための検索エンジンを介した検索クエリとして実行することができる。特定のクラスタ内の提案セットを文献の組に変換することにより、文献（クエリでなく）にラベル付けするために開発した様々な方法を適用することができる。

文献のクラスタにラベル付けする１つの標準的な方法は、文献から単語のｎグラムを取り込み、最も頻度の高いｎグラムを選択することである。ｎグラムとは、連続する一連のｎ個の単語のことである。提案ｓの上位にランクされた検索結果セットをＲ（ｓ）とし、
とし、文献ｄに含まれる単語セットｎグラムをＮＧ（ｄ）とし、提案クラスタの上位にランクされた文献全てにおける全てのｎグラムの組をＮＧ（Ｒ（Ｓ））とすると、

となる。そして、ＭＦＲＳ法により提案セットＳに割り当てられるラベルは以下のようになる。
ＭＦＲＳ（Ｓ）＝ｌ_ｉ：ｌ_ｉ∈ＮＧ（Ｒ（Ｓ）），


例えば、ＭＦＲＳ法では、「ｌｏｓ ａｎｇｅｌｓ ｄａｉｌｙ ｎｅｗｓ」、「ｌｏｓ ａｎｇｅｌｓ ｔｉｍｅｓ」、及び「ｌｏｓ ａｎｇｅｌｓ ｔｉｍｅｓ ｎｅｗｓｐａｐｅｒ」という提案を含む提案クラスタに「ｎｅｗｓ」というラベルを割り当てることができる。

１つの実施形態によれば、提案グループごとに、各々が対応するタイトル、要約及びユニフォームリサーチロケータ（ＵＲＬ）を含む、対応する提案セットに関連する検索結果セット（文献など）を取得することができる。その後、対応する検索結果セットを使用して、各提案グループのラベル（又は画像）を識別又は生成することができる。

２．４ 修正した結果セット内の最高頻度（ＭＦＲＳ ^* ）
検索提案は、エンティティの集合として、高度の語彙オーバーラップを有するクラスタに一意である。長い共通部分列を含むクラスタでは、ラベル付けに興味のある要素が、クラスタの全ての要素間で共有されない提案部分内に最も良く表されることがある。従って、追加のラベル付け機構ＭＲＦＳ＊を適用することができる。ＭＦＲＳ＊はＭＦＲＳに類似するが、（検索提案を全体的に実行するのではなく）クラスタ内の異なる提案部分のみを実行することにより、上位にランクされた文献の組を取得するために実行されるクエリを取得することができる。例えば、「ｌｏｓ ａｎｇｅｌｓ ｐｕｂｌｉｃ ｌｉｂｒａｒｙ」、「ｌｏｓ ａｎｇｅｌｓ ｐｏｌｉｃｅ ｄｅｐａｒｔｍｅｎｔ」、及び「ｌｏｓ ａｎｇｅｌｓ ｕｎｉｆｉｅｄ ｓｃｈｏｏｌ ｄｉｓｔｒｉｃｔ」という提案を含む提案クラスタでは、「ｐｕｂｌｉｃ ｌｉｂｒａｒｙ」及び「ｐｏｌｉｃｅ ｄｅｐａｒｔｍｅｎｔ」、及び「ｕｎｉｆｉｅｄ ｓｃｈｏｏｌ ｄｉｓｔｒｉｃｔ」という検索クエリを実行することができる。ＭＦＲＳ^*機構は、以下のように定義することができる。

提案セットＳの最も長い共通部分列を取り除いた提案ｓ_ｉをｓ_ｉ ^＊としてｓ_ｉ ^＊＝ｓ_ｉ−ＬＣＳ（Ｓ）とし、最も長い共通部分列を全ての提案から取り除いた提案セットＳを

とすると、ＭＦＲＳ^＊によってＳに割り当てられるラベルは以下のようになる。
ＭＦＲＳ^＊（Ｓ）＝ＭＦＲＳ（Ｓ^＊）
例えば、ＭＦＲＳ^＊法では、「ｌｏｓ ａｎｇｅｌｓ ｐｕｂｌｉｃ ｌｉｂｒａｒｙ」、「ｌｏｓ ａｎｇｅｌｓ ｐｏｌｉｃｅ ｄｅｐａｒｔｍｅｎｔ」、及び「ｌｏｓ ａｎｇｅｌｓ ｕｎｉｆｉｅｄ ｓｃｈｏｏｌ ｄｉｓｔｒｉｃｔ」という提案を含む提案クラスタに「サービス（ｓｅｒｖｉｃｅｓ）」というラベルを割り当てることができる。

２．５ ラベル付け戦略の組み合わせ
上述したような１又はそれ以上のラベル付け機構を別個に又は互いに組み合わせて適用して、様々な提案グループにラベル（又は画像）を割り当てることができる。提案クラスタは異なる特性を有することができ、従って異なるラベル付け法から恩恵を受けることができる。従って、選択され適用される（単複の）ラベル付け機構は、これらを適用するシステムによって変化することができる。さらに、選択され適用される（単複の）ラベル付け機構は、クラスタのクラスタ特性によって変化することができる。

クラスタ内からの情報（提案など）のみを使用してクラスタにラベル（又は画像）を割り当てることができる。例えば、ＭＦＳ又はＬＣＳなどの機構を適用してラベル（又は画像）を割り当てることができる。或いは、クラスタ内からの情報に加えて、又はこの代わりにクラスタ外の情報（検索結果など）を使用してクラスタにラベル（又は画像）を割り当てることもできる。例えば、ＭＦＲＳ又はＭＦＲＳ^*などの機構を適用してラベル（又は画像）を割り当てることができる。

１つの実施形態では、クラスタのクラスタ結合度を求めるためにクラスタを調べることができる。換言すれば、クラスタの要素（提案など）の類似度を求めるためにクラスタを調べることができる。クラスタが小型であるほど（例えば、クラスタの要素が類似するほど）、外部からではなくクラスタの要素内から適当なラベルを発見する可能性が高くなる。提案セットＳの結合度は、クラスタＳの要素間の平均距離を使用して測定することができる。クラスタＳの結合度が閾値量未満の場合、ＭＦＲＳ又はＭＦＲＳ^*などのクラスタ外の情報を使用する機構を適用することができ、その他の場合、ＭＦＳ又はＬＣＳなどのクラスタ内の情報を使用する機構を適用することができる。

３．提案クラスタの順序付け
開示する実施形態を適用して、クエリを完成させるための提案セットを提示し、ユーザが提案セットから所望の提案を特定する努力を軽減することができる。提案セットをグループ化する態様により、ユーザ努力の量を軽減することができる。同様に、提案グループを提示する順序、及び特定の提案グループ内に提案を提示する順序も、提示された提案セットから所望の提案を特定するために費やされるユーザ努力の量に影響を与えることができる。

１つの態様によれば、２又はそれ以上の提案グループを表示用に提供する前に、この２又はそれ以上の提案グループを提供する順序を確認することができる。その後、この２又はそれ以上の提案グループを、これらが確認した順序に従ってユーザインターフェイスの検索支援部分の別個の区分内に表示されるように提供することができる。

提案クラスタの組内から提案を特定する際に費やされるユーザ努力を特徴付けるために、コスト評価基準を適用することができる。より詳細には、このコスト評価基準により、２又はそれ以上の提案グループ内から提案を特定する際の予想コストを表す数値を生成することができる。その後、提案クラスタの組から提案を特定する際の予想コストを最小にするためのアルゴリズムを適用することができる。

ユーザにより入力された検索クエリの一部に関連して提示する提案セットをクラスタ化（及びラベル付け）することにより、ユーザがクラスタ間をスキップし、関連するクラスタの識別時に、ユーザがクラスタ内をスキャンして所望の提案を特定できるようにすることができる。従って、所望の提案を識別するコストを以下のように定義することができる。

クラスタラベルを読み取る時間：ユーザは、対応するラベル（又は画像）を読み取ることによって提案クラスタを閲覧することができる。各クラスタＣにおいて、ユーザは、ラベルがユーザの関心領域を捕えているかどうかに応じて、そのクラスタをスキップすべきか、それともスキャンすべきかを判断することができる。クラスタのラベルを読み取る際のコストをＴ_lb（Ｃ）として示すことができる。

クラスタをスキャンする時間：所望の提案ｓを含むクラスタＣを識別すると、ユーザは、所望の提案ｓが特定されるまでクラスタＣ内の提案をスキャンすることができる。クラスタ内の各提案ｓをスキャンするコストをＴ_SC（ｓ）によって示すことができる。

クエリプレフィクスｐを入力し、クラスタＣ１、Ｃ２、．．．、Ｃｎの組から提案ｓを特定することに関心のあるユーザについて検討し、提案ｓ１、ｓ２、．．．ｓｊを含むクラスタをＣｍとしてｓｋ＝ｓとする。換言すれば、提案ｓは、クラスタＣｍ内の位置ｋに存在する。Ｔ（ｓ）で示すことができる、ユーザが提案ｓを特定する際のコストを、

として定義することができる。単純にするために、いずれかのクラスタラベルを読み取るためのコストは全てのクラスタで同じであり、すなわちＴ_ｌｂであると仮定することができる。同様に、クラスタ内の提案をスキャンするコストｉｄ Ｔｓｃも提案に関わらず同じであると仮定することができる。この結果、クラスタｍ内の位置ｋに存在する提案ｓのＴ（ｓ）は、Ｔ（ｓ）＝ｍ・Ｔｌｂ＋ｋ・Ｔｓｃとなる。

プレフィクスｐを入力したユーザに関し、複数の提案から関心のある提案を特定する予想コストＴ（ｐ）を次のように定義することができる。

式中、Ｐ（ｓ｜ｐ）は、プレフィクスを入力したときにユーザが提案ｓを気に入る確率を示し、Ｔｐは、提案ｓのランク付けＲの関数である。Ｐ（ｓ｜ｐ）は、プレフィクスｐを入力したときに観察されるユーザの好みに基づいてクエリログから推定することができる。より詳細には、ユーザ（又は一般に複数のユーザ）により提出又は選択されたプレフィクスｐを含むクエリを識別することができる。その後、識別されたクエリから、プレフィクスｓを含むクエリの総数に対するクエリｓが提出又は選択された回数を確認することができる。詳細には、（１又は複数の）ユーザによりプレフィクスが入力された回数（例えば、１又は複数のユーザによってプレフィクスを含むクエリが提出された回数）をｆ（ｐ）とし、提案ｓがユーザクエリとして提出された回数をｆ（ｓ）とする場合、次式のようになる。

なお、ユーザが提案セット内に存在しないクエリを入力したとも考えられるので、一般に

は１未満になる。ユーザが提案セット内に存在しない提案に関心を持ったことに対するコストは、提示する提案セットのランク付けとは無関係であると仮定することができる。

クラスタ及びクラスタ内の提案を、Ｔｐ（Ｒ）が最小になるように順序付けるためのランク付けアルゴリズムを使用することができる。１つの実施形態では、このランク付けアルゴリズムにより、クラスタ内の提案に、頻度ｆ（ｓ）が増加しない順序（減少する順序など）でランク付けすることができる。提案クラスタにランク付けするためには、各クラスタＳに、クラスタＣ内の提案の全ての頻度の和に等しい集約頻度Ｆ（Ｃ）を割り当てることができる。従って、ランク付けアルゴリズムは、提案クラスタに、集約頻度Ｆ（Ｃ）が増加しない順序（減少する順序など）でランク付けすることができる。

別の態様によれば、提案グループの各々の提案を順序付けすることができる。より詳細には、２又はそれ以上の提案グループの各々の中の提案セット部分を提供する順序を確認することができる。例えば、この順序は、クエリログによる提案の人気を示すことができる。その後、２又はそれ以上の提案グループの各々の提案を、確認した順序に従ってユーザインターフェイスの検索支援部分の対応する区分内に表示することができる。

本発明の実施形態を使用して、グラフィカルユーザインターフェイスを介して検索を実行しながら、同じグラフィカルユーザインターフェイスを使用して検索提案を提供することができる。開示する実施形態は、様々な計算コンテキストのいずれかで実施することができる。例えば、図５に示すように、ユーザが、あらゆる種類のコンピュータ（デスクトップ、ラップトップ、タブレットなど）１１０２、メディアコンピュータプラットフォーム１１０３（ケーブル及び衛星セットトップボックス及びデジタルビデオレコーダなど）、ハンドヘルドコンピュータ装置（ＰＤＡなど）１１０４、携帯電話１１０６を介して、又はその他のいずれかの種類のコンピュータ又は通信プラットフォームを介して異なるネットワーク環境とやりとりする実施構成が想定される。

また、様々な実施形態によれば、本発明によって処理される入力を、様々な技術を使用して取得することができる。例えば、グラフィカルユーザインターフェイスを介して、ユーザがローカルアプリケーション、ウェブサイト又はウェブベースのアプリケーション又はサービスとやりとりすることから検索クエリを取得することができ、ユーザから情報を取得するための様々な周知の機構のいずれかを使用して検索クエリを完成させることができる。しかしながら、ユーザからの入力を取得するこのような方法は一例にすぎず、その他の多くの方法で検索クエリを取得することもできると理解されたい。

開示する実施形態により、何らかの集中化方式で検索提案をクラスタ化して提示することもできる。このことを、当然ながら複数の分散装置及びデータストアに対応できる図５のサーバ１１０８及びデータストア１１１０によって表している。例えば、ＴＣＰ／ＩＰベースのネットワーク、通信ネットワーク、無線ネットワークなどを含む（ネットワーク１１１２によって表す）様々なネットワーク環境内で本発明を実施することもできる。また、本発明の実施形態を実施するコンピュータプログラム命令を、あらゆる種類のコンピュータ可読媒体に記憶し、クライアント／サーバモデル、ピアツーピアモデルを含む様々な計算モデルに従って独立型コンピュータ装置上で、或いは本明細書で説明した様々な機能を異なる場所で実現又は利用できる分散型コンピュータモデルに従って実行することもできる。

開示する本発明の技術は、ソフトウェア、及び／又はウェブベースのサーバ又はデスクトップコンピュータシステムなどのハードウェアシステムのいずれかの適切な組み合わせで実施することができる。さらに、本発明の様々な実施形態を実施するシステムを、ラップトップ又は携帯電話などのポータブル装置とすることもできる。本発明の検索装置及び／又はウェブブラウザは、必要な目的のために特別に構成することもでき、或いはコンピュータに記憶されたコンピュータプログラム及び／又はデータ構造によって選択的に起動又は再構成される汎用コンピュータとすることもできる。本明細書に示す処理は、本質的にいずれの特定のコンピュータ又はその他の装置にも関連しない。特に、本明細書の教示に従って書かれたプログラムを含む様々な汎用機械を使用することもでき、又は必要な方法ステップを実行するようにより特化された装置を構成する方が便利な場合もある。

システムの構成に関わらず、汎用処理動作及び／又は本明細書で説明した発明技術のためのデータ、プログラム命令を記憶するように構成された１又はそれ以上のメモリ又はメモリモジュールを使用することができる。例えば、プログラム命令は、オペレーティングシステム及び／又は１又はそれ以上のアプリケーションの動作を制御することができる。１又は複数のメモリを、開示した方法を実行するための命令、並びにクエリログ、ラベル、画像、検索結果などを記憶するように構成することもできる。

このような情報及びプログラム命令を使用して、本明細書で説明したシステム／方法を実現することもできるので、本発明は、本明細書で説明した様々な動作を実行するためのプログラム命令、状態情報などを含む機械可読媒体にも関する。機械可読媒体の例として、以下に限定されるわけではないが、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープなどの磁気媒体、ＣＤ−ＲＯＭディスクなどの光学媒体、フロプティカルディスクなどの磁気光学媒体、及び読み出し専用メモリ素子（ＲＯＭ）及びランダムアクセスメモリ（ＲＡＭ）などの、プログラム命令を記憶して実行するように特別に構成されたハードウェア装置が挙げられる。プログラム命令の例としては、コンパイラにより作成されるような機械コード、及びコンピュータが翻訳器を使用して実行できる高水準コードを含むファイルのいずれもが挙げられる。

図６に、適切に構成又は設計されたときに本発明のシステムとして機能できる典型的なコンピュータシステムを示す。コンピュータシステム１２００は、一次記憶装置１２０６（通常はランダムアクセスメモリ、すなわちＲＡＭ）、一次記憶装置１２０４（通常は読み出し専用メモリ、すなわちＲＯＭ）を含む記憶装置に結合されたあらゆる数のプロセッサ１２０２（中央処理装置、すなわちＣＰＵとも呼ばれる）を含む。ＣＰＵ１２０２は、プログラマブル装置（例えば、ＣＰＬＤ及びＦＰＧＡ）などのマイクロコントローラ及びマイクロプロセッサ、及びゲートアレイＡＳＩＣ又は汎用マイクロプロセッサなどのアンプログラマブル装置を含む様々な種類であってよい。当業で周知のように、一次記憶装置１２０４は、データ及び命令をＣＰＵに単方向に転送するように機能し、一次記憶装置１２０６は、通常、データ及び命令を双方向に転送するように使用される。これらの両一次記憶装置は、上述したようなあらゆる好適なコンピュータ可読媒体を含むことができる。ＣＰＵ１２０２には大容量記憶装置１２０８も双方向に接続され、この大容量記憶装置は、追加のデータ記憶容量を提供し、上述したコンピュータ可読媒体のいずれを含むこともできる。大容量記憶装置１２０８を使用して、プログラム、データなどを記憶することができ、この大容量記憶装置は、通常はハードディスクなどの二次記憶媒体である。必要に応じて、大容量記憶装置１２０８内に保持される情報を、仮想メモリである一次記憶装置１２０６の一部として標準的に組み入れることができると理解されるであろう。ＣＤ−ＲＯＭ１２１４などの特定の大容量記憶装置も、データをＣＰＵに単方向に転送することができる。

ＣＰＵ１２０２を、ビデオモニタ、トラックボール、マウス、キーボード、マイク、タッチセンサ式ディスプレイ、トランスデューサカードリーダ、磁気又は紙テープリーダ、タブレット、スタイラス、音声又は手書き認識装置、又は当然ながら他のコンピュータなどのその他の周知の入力装置などの１又はそれ以上の入力／出力装置に接続するインターフェイス１２１０に結合することもできる。最後に、ＣＰＵ１２０２を、１２１２で大まかに示すような外部接続部を使用して、データベース又はコンピュータ又は通信ネットワークなどの外部装置に任意に結合することもできる。このような接続により、ＣＰＵがネットワークから情報を受け取り、又は本明細書で説明した方法ステップを実行する途中でネットワークに情報を出力できるようになると想定される。

以上、明確に理解できるように本発明を少々詳しく説明したが、添付の特許請求の範囲内でいくつかの変更及び修正を行えることが明らかであろう。従って、本実施形態は、限定的ではなく例示的なものであると見なすべきであり、本明細書に示す詳細に本発明を限定すべきではなく、添付の特許請求の範囲及び同等物の範囲内で修正することができる。

２１４ 区分
２１６ 画像
２１８ 区分
２２０ 画像

Claims (25)

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. 前記２又はそれ以上の提案グループの各々について、
    前記２又はそれ以上の提案グループの１つの結合度を確認するステップと、
    前記２又はそれ以上の提案グループの１つの結合度に基づいて、前記２又はそれ以上の提案グループの１つの外部の情報を使用して前記２又はそれ以上の提案グループの１つに関連するラベル又は画像を取得するステップと、
    をさらに含むことを特徴とする請求項１６に記載の方法。