JP2008508605A - インラインのコンテキストクエリを用いた検索システムおよび方法 - Google Patents

Abstract

クエリが入力されるときにユーザが見ているウェブページ（または他の文書）に関連付けられるコンテキストの情報を用いて検索を実現するためのシステムおよび方法が与えられる。ページは、ページのコンテンツを代表する関連付けられたコンテキストベクトルを有する文脈探索インターフェースを含む。ユーザが文脈探索インターフェースを介して検索クエリを実行依頼するとき、クエリおよびコンテキストベクトルがクエリプロセッサに与えられ、クエリに応答するのに用いられる。

Description

発明の背景
本発明は、一般に検索システムおよび方法に関し、特にインラインの文脈（コンテキスト：context）のクエリを用いた検索システムおよび方法に関する。

ワールドワイドウェブ（Web）は、その名前が示唆するように、相互リンクされた情報の大規模な分散型集合体であり、その情報は、事実上すべての考えられる話題に関連する、すなわち一般にはテキスト、画像および／または媒体コンテンツを包含し得る「ページ」の形式の情報である。ユーザがあるページについてのユニフォームリソースロケータ（ＵＲＬ）を知っており、または見つけると、（一般にブラウザと呼ばれる）ウェブクライアントにそのＵＲＬを与え、ほとんど即座にそのページを見ることができる。ウェブページは典型的には（「ハイパーリンク」とも呼ばれる）他のページへのリンクを含んでいるので、ＵＲＬを見つけることは一般に困難ではない。

ほとんどのユーザにとって困難なのは、自分にとって興味のあるページのＵＲＬを見つけることである。ウェブで利用可能なコンテンツの全体量は、特定の興味に関するページを見つける作業を究極の「干し草の山の中で針を探す」問題としてしまう。この問題に取組むために、検索プロバイダ産業（たとえばＹＡＨＯＯ！，ＭＳＮ，Ｇｏｏｇｌｅなど）が発展してきた。検索プロバイダは典型的にはウェブページのデータベースを維持し、その各ページのＵＲＬはそのコンテンツを反映する情報（たとえばキーワード、カテゴリデータなど）と関連付けられている。検索プロバイダは、さらにウェブ上の検索ページ（またはサイト）をホストする検索サーバを維持する。検索ページはフォームを与え、そこにユーザが自分の興味を表す１つ以上の用語を通常含むクエリを入力することができる。一旦クエリが入力されれば、検索サーバはデータベースにアクセスし、「ヒット」、典型的にはそのコンテンツがユーザのクエリから導き出されるキーワードと一致するページのＵＲＬのリストを生成する。このリストがユーザに与えられる。クエリがしばしば何百、何千という、または場合によっては何百万というヒットを返すことができるので、検索プロバイダはヒットをランク付けする（すなわちユーザに対してヒットを表示するための順番を決定する）ための高度なアルゴリズムを開発してきた。その結果、与えられたクエリに最も関係が深いページはリストのトップに現われやすい。典型的なランク付けアルゴリズムは、キーワードおよびその発生頻度のみならず、他の情報、たとえばヒットページにリンクする他のページの数、ユーザの間でのヒットページの人気度などをも考慮に入れる。

さらに検索プロバイダのサービスが容易に用いられ得るよう、今ではウェブブラウザプログラム用の「検索ツールバー」アドオンを提供する検索プロバイダもある。検索ツールバーは典型的には、ユーザがクエリをタイプすることができるテキストボックスおよび検索プロバイダのサーバにクエリを実行依頼するための「実行依頼（submit）」ボタンをもたらす。一般に検索ツールバーは、一旦ユーザによってインストールされるとユーザがいかなるページを見ているかにかかわらず見ることができ、ユーザが検索プロバイダのウェブサイトにまずナビゲートすることなくいつでもクエリを入力することを可能にする。ツールバーによって開始された検索は、プロバイダのサイトで始められた検索と同じように処理される。唯一の相違は、ユーザが検索プロバイダのサイトをナビゲートするステップを免れることである。

検索技術は極めて有用になり得る一方で多くの制限を有し、その主要なものは、関連コンテンツに検索を導くためにコンテキストの情報を十分に伝えるのにユーザが苦労するこ
とである。過度に広いクエリ（少なすぎるコンテキスト）は、無関係のヒットの干し草の山に埋められた数本の関連コンテンツの針を返すこととなる。過度に狭いクエリ（あまりにも多くのコンテキスト）は、干し草と一緒に針を濾過する結果となることがある。しばしば、ユーザはかなり限定されたコンテキストのことを考えているのに、この限定されたコンテキストがクエリに反映されていないことがある。たとえば、クエリ「ジャガー」を入力するユーザは、自動車、動物、プロフットボールチーム、または全く別のものについて考えているのかもしれない。

原則としてコンテキストの情報は、ユーザがクエリを入力する前に行なっていたことから拾い集めることができる。ユーザが現在見ている情報がさらなる質問を生じ、ユーザがしばしば検索を行なうよう示唆されることが周知である。たとえば、自動車関連のページを見た後（または見ているとき）に「ジャガー」のクエリを入力するユーザは自動車に興味を持っていることが最もあり得ることであり、その一方で、動物園関連のページを見た後（または見ているとき）に同じクエリを入力するユーザはこの動物に興味を持っていることが最もあり得る。既存の検索技術は、このようなコンテキストの情報を集めたり、クエリに応答するためにそれを用いたりする信頼できる方法を与えていない。

したがって、クエリに応答するために使用可能なコンテキストの情報を検索サーバに与えることが望ましい。

発明の概要
本発明の実施例は、クエリが入力されるときにユーザが見ているページまたは他の文書に関連付けられるコンテキスト情報を用いて検索を実現するためのシステムおよび方法を与える。いくつかの実施例においては、ページまたは文書は、ページまたは文書のコンテンツを代表する関連付けられたコンテキストベクトルを有する文脈探索インターフェースを含む。ユーザが文脈探索インターフェースを介して検索クエリを実行依頼すると、コンテキストベクトルがクエリプロセッサに与えられ、クエリに応答するのに用いられる。コンテキストベクトルは、ユーザにとって興味があるかもしれない付加的なコンテンツを選択するなどの他の方法で用いられてもよい。

本発明の１つの局面によれば、クエリを処理するための方法が与えられる。ユーザクエリが文脈探索インターフェースを介して受取られ、そのユーザクエリはユーザによって入力されたデータを含む。文脈探索インターフェースに関連付けられるコンテキストベクトルも受取られ、そのコンテキストベクトルは文脈探索インターフェースに関連付けられたコンテンツを代表するデータを含む。検索クエリおよびコンテキストベクトルを用いて検索コーパスが検索され、ヒットリストを含む検索結果を得る。検索結果はユーザに提示するために送信される。

本発明の別の局面によれば、情報をユーザに与えるための方法が与えられる。コンテキストを包含するページが与えられる。文脈探索インターフェースはコンテンツに関連付けられ、その文脈探索インターフェースはユーザからクエリを受取るよう適合される。コンテキストを代表するコンテキストベクトルが文脈探索インターフェースに関連付けられる。文脈探索インターフェースを介してユーザからクエリが受取られ、クエリおよびコンテキストベクトルは処理のために検索サーバに送信され、検索サーバは、クエリおよびコンテキストベクトルを用いて検索コーパスを検索してユーザに検索結果を返すよう構成される。いくつかの実施例では、文脈探索インターフェースについてアクティブ状態および非アクティブ状態が規定され、文脈探索インターフェースは、非アクティブ状態では小さな
アイコンとしてページ上に現われ、アクティブ状態では完全なインターフェースとして現われる。たとえば、デフォルトで非アクティブ状態の文脈探索インターフェースが表示され、ユーザがそのアイコンを選択することに応答してアクティブ状態で再表示されることができる。いくつかの実施例において、ユーザがそのアイコンを選択することに応答してページにスペシャルコンテンツを加えることができ、そのスペシャルコンテンツはコンテキストベクトルに基づいて選択される。

下記の詳細な説明は、添付の図面とともに本発明の性質および利点についてよりよい理解を与える。

発明の詳細な説明
Ｉ．概観
Ａ．ネットワーク実現例
図１は、本発明の実施例によるクライアントシステム２０を含む情報検索および通信ネットワーク１０の一般的概観を示す。コンピュータネットワーク１０では、クライアントシステム２０は、インターネット４０または他の通信ネットワーク、たとえば任意のローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を通じて、５０１から５０Ｎまでの任意の個数のサーバシステムに結合される。本願明細書に説明されるように、本発明によるクライアントシステム２０は、たとえば媒体コンテンツおよびウェブページなどの他の情報にアクセスし、受取り、検索し、表示するなど、任意のサーバシステム５０１から５０Ｎと通信するよう構成される。

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

１つの実施例によれば、クライアントシステム２０およびそのコンポーネントのすべては、インテルペンティアム（登録商標）プロセッサ、ＡＭＤアスロン（登録商標）プロセッサなどの中央処理装置または複数のプロセッサを用いて実行される計算機コードを含むアプリケーションを用いてオペレータ構成可能（operator configurable）である。本願明細書に説明されるようにクライアントシステム２０がデータおよび媒体コンテンツを通
信し、処理し、表示するように、操作し、構成するためのコンピュータコードは、好ましくはダウンロードされ、ハードディスク上に記憶されるが、そのプログラムコード全体もしくはその一部は、揮発性もしくは不揮発性メモリ媒体、またはＲＯＭもしくはＲＡＭなどの周知の装置に記憶されてもよく、またはコンパクトディスク（ＣＤ）媒体、デジタル汎用ディスク（ＤＶＤ）媒体、フロッピー（登録商標）ディスクなどの、プログラムコードを記憶することができる任意の媒体に与えられてもよい。さらに、プログラムコード全体またはその一部は、ソフトウェアソース、たとえばサーバシステム５０１から５０Ｎの１つなどからインターネットを通じてクライアントシステム２０へ送信されてダウンロードされることができ、または任意の通信媒体およびプロトコル（たとえばＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）、または他の従来の媒体およびプロトコル）を用いて任意の他のネットワーク接続（たとえばエクストラネット、ＶＰＮ、ＬＡＮ、または他の従来のネットワーク）を通じて送信されることができる。

本発明の局面を実現するためのコンピュータコードが、Ｃ、Ｃ＋＋、ＨＴＭＬ、ＸＭＬ、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどのコード、または他のあらゆる好適なスクリプト言語（たとえばＶＢＳＳｃｒｉｐｔ）、またはクライアントシステム２０で実行され得るかもしくはクライアントシステム２０で実行し得るようコンパイルされ得るあらゆる他の好適なプログラミング言語であり得ることが認識されるべきである。いくつかの実施例において、クライアントシステム２０にはコードがダウンロードされず、必要なコードはサーバによって実行されるか、またはクライアントシステム２０に既に存在するコードが実行される。

Ｂ．検索システム
図２は、本発明の実施例による、媒体コンテンツを通信するための別の情報検索および通信ネットワーク１１０を示す。示されるように、ネットワーク１１０はクライアントシステム１２０、１つ以上のコンテンツサーバシステム１５０、および１つの検索サーバシステム１６０を含む。ネットワーク１１０において、クライアントシステム１２０は、インターネット１４０または他の通信ネットワークを通じて、サーバシステム１５０および１６０に通信可能に結合される。上述のように、クライアントシステム１２０およびそのコンポーネントは、インターネット１４０または他の通信ネットワークを通じて、サーバシステム１５０および１６０ならびに他のサーバシステムと通信するよう構成される。

１．クライアントシステム
１つの実施例によれば、クライアントシステム１２０で実行するクライアントアプリケーション（モジュール１２５として表わされる）は、クライアントシステム１２０およびそのコンポーネントがサーバシステム１５０および１６０と通信し、そこから受取ったデータコンテンツを処理して表示するように制御する命令を含む。クライアントアプリケーション１２５は、リモートサーバシステム（たとえばサーバシステム１５０、サーバシステム１６０または他のリモートサーバシステム）などのソフトウェアソースからクライアントシステム１２０に送信され、ダウンロードされてもよい。または、クライアントアプリケーションモジュール１２５は、上述のようにクライアントシステム１２０によって読取可能なすべてのソフトウェア記憶媒体（フロッピー（登録商標）ディスク、ＣＤ、ＤＶＤなど）で与えられてもよい。たとえば１つの局面では、クライアントアプリケーション１２５は、データを操作し、さまざまなオブジェクト、フレームおよびウィンドウにおいてデータをレンダリングするために、たとえば埋込型Ｊａｖａ（登録商標）ＳｃｒｉｐｔまたはＡｃｔｉｖｅＸ制御などのさまざまな制御を含むＨＴＭＬラッパで、インターネット１４０を通じてクライアントシステム１２０に与えられてもよい。

クライアントアプリケーションモジュール１２５は、データおよび媒体コンテンツの処理のためのさまざまなソフトウェアモジュールを有利に含む。１つの実施例では、これら
のモジュールは、専用検索モジュール１２６、ユーザインターフェースモジュール１２７およびアプリケーションインターフェースモジュール１２８を含む。専用検索モジュール１２６は、検索サーバ１６０に送られる（ここではクエリとも呼ばれる）検索リクエストおよび検索サーバ１６０から受取った検索結果データを処理するよう構成される。専用検索モジュール１２６の特定の局面は下記に説明される。

ユーザインターフェースモジュール１２７は、テキスト、データフレーム、およびたとえばブラウザウィンドウおよびダイアログボックスなどのアクティブウインドウにおけるデータおよび媒体コンテンツをレンダリングするよう構成される。いくつかの実施例においては、ユーザインターフェースモジュール１２７はブラウザプログラムを含むかまたはこれと通信し、ブラウザプログラムはクライアントシステム１２０に構成されるデフォルトブラウザまたは異なるブラウザであってもよい。アプリケーションインターフェースモジュール１２８は、クライアントアプリケーション１２５と、クライアント１２０で実行される電子メールアプリケーション、インスタントメッセージング（ＩＭ）アプリケーション、ブラウザアプリケーション、文書管理アプリケーションなどのさまざまな他のアプリケーションとの間のインターフェースおよび通信をサポートするよう構成される。

ユーザインターフェースモジュール１２７は、ユーザが検索サーバシステム１６０による処理のためにクエリを入力することを可能にする、ユーザ入力インターフェースを与えるのが有利である。たとえば、ユーザインターフェースモジュール１２７がブラウザを含むかこれと通信する場合、ユーザはＵＲＬを入力するか制御ボタンを起動してブラウザをウェブ検索ページ（またはサイト）に導くことができ、ユーザはそこから処理のために検索サーバシステム１６０にクエリを実行依頼することができる。追加的に、または代替的に、ユーザインターフェースモジュール１２７は、ユーザが最初に検索ページをナビゲートすることなくクエリを入力し実行依頼することができる、検索ツールバーまたは他のインターフェースを含んでもよい。ユーザインターフェースモジュール１２７を用いて入力されたクエリは、たとえばいわゆる「ストップワード」（「その（the）」「そして（and）」など）を取除くため、スペルミスなどを修正するなどのために、検索サーバシステム１６０に送られる前に専用検索モジュール１２６によって処理されてもよい。

本発明の実施例によるクライアントアプリケーション１２５は、ユーザのクエリにコンテキストデータ（本願明細書において「コンテキストベクトル」とも呼ばれる）を加えるためのさまざまな機構を含んでもよい。たとえば、専用検索モジュール１２６は、ユーザがクエリを入力するときに見ているコンテンツに基づいて、コンテキストベクトルを生成するよう構成されてもよい。別の例として、本発明のいくつかの実施例では、ブラウザに表示されるウェブページは、ユーザに入力されたクエリを補足するために用いることができる１つ以上のコンテキストベクトルを含んでもよい。ユーザインターフェースモジュール１２７は、表示されているページにおいてこのようなコンテキストのベクトルを検知し、かつユーザに入力されたクエリを補足するためにコンテキストベクトルデータを用いるよう構成されてもよい。これらの、および他の機構は下記に説明される。

２．検索サーバシステム
本発明の一実施例によれば、検索サーバシステム１６０は検索結果データおよび媒体コンテンツをクライアントシステム１２０に与えるよう構成され、コンテンツサーバシステム１５０は、たとえば検索サーバシステム１６０によって与えられた検索結果ページにおいてユーザが選択したリンクに応答して、ウェブページなどのデータおよび媒体コンテンツをクライアントシステム１２０に与えるよう構成される。いくつかの変形例において、検索サーバシステム１６０は、コンテンツへのリンクおよび／または他の参照とともに、またはその代わりに、コンテンツを返す。

検索サーバシステム１６０は、たとえばページ、ページへのリンク、インデックスが付いたページのコンテンツを代表するデータなどが存在する、さまざまなページインデックス１７０を参照する。ページインデックスは自動ウェブクローラ（Web Clawler）１７２などのさまざまな収集技術によって生成されてもよい。さらに、階層的カテゴリ構造内でウェブページを分類しランク付けするための手動または半自動式の分類アルゴリズムおよびインターフェースが与えられてもよい。そのような技術およびアルゴリズムは一般的な従来の設計でもよく、本発明にとって重要ではないので詳細な説明は省略する。

一実施例において、ページインデックス１７０におけるエントリは、検索用語、その用語が現われるページへの参照（たとえばＵＲＬまたは他のエンコードされた識別子）、およびそのページのコンテキスト識別子を含む。コンテキスト識別子は、異なるコンテキストにおいて異なる意味を有し得る検索用語の類似する結果をグループ化するために用いられてもよい。たとえば検索用語「ジャガー」は、英国の自動車、動物、プロフットボールチーム、などを参照し得る。ページのコンテキスト識別子は、これらのコンテキストのいずれが適用可能かを示すよう用いることができる。一実施例において、コンテキスト識別子はページのカテゴリを含み、そのカテゴリはコンテンツカテゴリの定義済み階層的分類から割当てられている。ページ参照は複数のコンテキスト識別子に関連付けられてもよく、そのため同じページ（またはそこへのリンク）が複数のコンテキストに表示されてもよい。いくつかの実施例において、コンテキスト識別子は、ユーザがさまざまな検索を実行する間にシステムによって自動的にページリンクに関連付けられる。識別子は、検索エディタの１つ以上のチームによって修正され、手動でリンクに関連付けられてもよい。

検索サーバシステム１６０は、クライアントシステム１２０、特に検索モジュール１２６および／またはユーザインターフェースモジュール１２７から受取ったさまざまな検索リクエストに反応するデータを与えるよう構成される。たとえば検索サーバシステム１６０はクエリ応答モジュール１６４を含んでもよく、クエリ応答モジュール１６４は、たとえば（検索用語のクエリにおける発生パターンによって測定され得る）論理的関連性、コンテキスト識別子、ページスポンサー権などの組合せに基づいて、所与のクエリに関連のあるウェブページを特定しランク付けするための、検索関連アルゴリズムで構成される。

本発明の実施例によれば、クエリ応答モジュール１６４はさらに、クエリに対する応答を強化するためにクエリに関連付けられて与えられ得るコンテキストベクトルデータを受取って使用するよう構成される。クエリに対する応答にコンテキストベクトルデータを使用することがさらに下記に説明される。クエリ応答モジュール１６４はさらに、スポンサーされたコンテンツデータベース１６２から得られる追加情報（たとえばリンクおよび／または広告コピー）を用いて検索結果情報を強化する。スポンサーされたコンテンツデータベース１６２は、各エントリに付加的なフィールドを包含することによってページインデックス１７０の一部として実現されて、スポンサーされているページ参照およびスポンサーされたコンテンツの表示をトリガするためのキーワードを特定してもよく、または個別のデータベースで実現されてもよい。

いくつかの実施例において、検索サーバ１６０はさらに、受取ったコンテンツを代表するコンテキストベクトルを生成するよう受取ったコンテンツを処理するためのさまざまなアルゴリズムで構成される、コンテキスト処理モジュール１６６を含む。一般にコンテキストベクトルは、コンテンツのすべてまたはその一部を代表するあらゆるデータを含んでもよい。たとえば、テキストコンテンツ用のコンテキストベクトルの１つの実施例は、コンテンツに現れる用語（たとえば単語またはフレーズ）などのキーワードを含んでいてもよく、そのような用語はそれぞれ、その用語がコンテンツにおいて何回発生するかを反映する頻度カウントを有してもよい。他のタイプのデータ、たとえばコンテンツに含まれ得るＵＲＬまたは他の任意のリンクを特定するデータ、コンテンツまたはコンテンツを包含
するページに関連付けられたカテゴリデータなどが含まれていてもよい。

いくつかの実施例ではコンテンツ増補サーバ１８０も与えられる。コンテンツ増補サーバ１８０はインターネット１４０を通じてクライアントアプリケーション１２５と通信し、表示されたページに関連付けられたコンテキストベクトルデータに基づいて有利に選択された「スペシャルコンテンツ」を伴って表示されているウェブページのコンテンツを強化する。クライアントアプリケーション１２５は、ユーザが（その例が下記に説明される）特定のコンテキスト関連の情報に対して興味を示している状況でコンテキストベクトルをコンテンツ増補サーバ１８０に送信し、コンテンツ増補サーバ１８０は、クライアントアプリケーション１２５によって表示されているウェブページに加えられるスペシャルコンテンツに応答する。

１つの実施例では、コンテンツ増補サーバ１８０および検索サーバ１６０は共通の制御下にあり、コンテンツ増補サーバ１８０はスポンサーされたコンテンツデータベース１６２からスペシャルコンテンツを有利に選択する。別の実施例では、コンテンツ増補サーバ１８０は検索サーバ１６０から独立してそれ自体のスペシャルコンテンツのデータベースを有していてもよく、クライアントアプリケーション１２５によって与えられるコンテキストベクトルに基づいて、そのデータベースから選択がなされ得る。

本願明細書に説明された検索システムは例示的であり、変形および修正が可能なことが認識されるだろう。コンテンツサーバ、検索サーバ、およびコンテンツ増補サーバシステムは、単一組織、たとえばヤフー社によってユーザに与えられる分散サーバシステムの一部か、または異なる組織の一部であってもよい。各サーバシステムは一般に、少なくとも１つのサーバおよび関連付けられたデータベースシステムを含み、複数のサーバおよび関連付けられたデータベースシステムを含んでもよく、かつ、単一のブロックとして示されたが、地理的に分散されていてもよい。たとえば、検索サーバシステムのサーバはすべて互いにすぐ近く（たとえば、単一の建物またはキャンパスのサーバファーム内）に位置してもよく、または互いに遠隔に（たとえば１つ以上のサーバがＡ市に、１つ以上のサーバがＢ市にあるなど）分散していてもよい。したがって、本願明細書に用いられるように、「サーバシステム」は、典型的には、局所的にまたは１つ以上の地理的な場所にわたって分散した、論理的および／または物理的に接続された１つ以上のサーバを含む。用語「サーバ」および「サーバシステム」は交換可能に用いられる。

検索サーバシステムは、クライアントシステムから受取った検索クエリに応答して、ページインデックスにアクセスしてユーザに検索結果を与えるための、１つ以上のページインデックスおよびアルゴリズムで構成されてもよい。検索サーバシステムがページインデックス自体を生成してもよく、別のソース（たとえば別個のサーバシステム）からページインデックスを受取るか、または別のソースからページインデックスを受取ってそのさらなる処理（たとえばコンテキスト識別子の追加または更新）を実行してもよい。

Ｃ．文脈探索インターフェース
上述のように、クライアントアプリケーション１２５のユーザインターフェースモジュール１２７は１つ以上のインターフェースを含み、たとえば検索サーバ１６０によってホストされた検索ページへブラウザをナビゲートすることによって、またはクエリ実行依頼のためのツールバー・インターフェースを与えることによって、ユーザが検索サーバ１６０にクエリ実行依頼をすることができるようにする。このようなインターフェースは一般的な従来の態様で実現されてもよい。

本発明の実施例に従って、ユーザはさらにこのようなインターフェースに加えて（またはその代わりに）、任意の「ホスティング」ウェブページ上の可視要素として実現され得
る「文脈探索」インターフェースを用いてコンテキストのクエリを入力してもよい。（本願明細書に用いられるように、用語「ホスティングウェブページ」または「ホスティングページ」は、少なくとも１つの文脈探索インターフェースを含む任意のページを指すと理解される。ホスティングページは、検索サーバ１６０またはコンテンツ増補サーバ１８０と共通の制御下にあってもよいし、そうでなくてもよい。）各文脈探索インターフェースはこれに関連付けられたコンテキストベクトルを有する。コンテキストベクトルはホスティングページ上で目に見える必要はなく、ホスティングページのコンテンツ（またはその部分）を反映する付加的なデータを与える。このデータは、たとえば下記に説明されるように、クエリ処理中にクエリ応答モジュール１６４によって用いられ得る。

文脈探索インターフェースの例がここで説明される。図３は、あるコンテンツ３０２を有するホスティングページ３００を、図２のクライアントシステム１２０に表示された場合に現われ得るように示す。ホスティングページ３００は、コンテンツ３０２の近くに有利に置かれた文脈探索インターフェース３０４を含む。ユーザは、インターフェース３０４のテキストフィールド３０６にクエリ（たとえば「fuel consumption (燃料消費量)」）を入力し、たとえばクリック可能なボタンであり得る「実行依頼」制御３０８を起動することによって、文脈探索を始めることができる。ホスティングページ３００のためのソースコード（示されない）は、文脈探索インターフェース３０４に関連付けられたコンテキストベクトルを含む。この実施例では、コンテキストベクトルは実際にはページ３００に表示されないが、そのデータは、ページ３００が要求されるとクライアントアプリケーション１２５に与えられるソースコードとともに含まれる。

さまざまな方法で実現され得るコンテキストベクトルは、近隣のコンテンツ３０２を示す用語および／またはカテゴリラベル（または任意の他のデータ）を有利に１つ以上含む。図４は、図３の文脈探索インターフェース３０４から始められた検索に与えられ得るコンテキストベクトル４００の例である。コンテキストベクトル４００は、コンテンツ３０２に現われる用語（「ｃａｂｒｉｏ（カブリオ）」、「ｇｏｌｆ（ゴルフ）」など）のリスト４０２および各用語に関連付けられた追加情報を含む。この例において、追加情報は、用語頻度４０４、文書頻度４０６、ウェイト４０８および用語タイプ４１０を含む。用語頻度４０４は用語がコンテンツ３０２に発生した回数を反映する。文書頻度４０６は用語を包含する検索コーパスにおける文書数を反映する。ウェイト４０８は用語に割当てられた重要性を反映し、それは用語が本文に発生するかまたは見出しに発生するのかといった情報、用語頻度４０４、および／または文書頻度４０６から計算されてもよい。用語タイプ４１０は、コンテキストベクトルに含まれ得るさまざまなタイプのデータ、たとえばテキスト（ＴＥＸＴ）の用語、カテゴリデータ、ＵＲＬデータなどを区別するために用いることができる。コンテキストベクトルはさらに、図４に示されるものよりさらに多くの、またはさらに少ない、または異なる要素を含んでもよく、要素は任意の所望のフォーマットで与えられ得ることが理解される。１つの実施例では、コンテキストベクトル４００は、文脈探索インターフェース３０４のためのコードと関連付けられてホスティングページ３００のソースコードに含まれる。

ホスティングページ３００を見るために（図２の）クライアントアプリケーション１２５を用いているユーザが、テキストフィールド３０６にクエリを入力し実行依頼制御３０８を起動することにより検索を始めるときは、有利に処理するためにクライアントアプリケーション１２５によって検索サーバ１６０に送られるクエリは、テキストフィールド３０６からの明示的なユーザ入力だけでなくコンテキストベクトル４００の表示をも含む。たとえば、文脈探索インターフェース３０４の１つの実現例では、ウェブページ３００は、実行依頼制御３０８に応答して検索サーバ１６０にＨＴＴＰ（ハイパーテキスト移送プロトコル）リクエストを送るためのプログラムコードを含む。このプログラムコードは、ユーザのクエリおよびコンテキストベクトルの表示を、ＨＴＴＰリクエストに用いられた
ＵＲＬに対する付加的なデータとして添付するためのコードを含むことができる。

（テキストフィールド３０６からの）ユーザのクエリおよびコンテキストベクトル４００に加えて、検索サーバ１６０は、（わかっていれば）ユーザの識別子、ユーザのＩＰアドレス、時刻など他のメタデータを受取ってもよい。このメタデータは、ホスティングページまたは文脈探索インターフェースに特有であってもなくてもよく、クライアントアプリケーション１２５または他のソースから得ることができる。

文脈探索インターフェース３０４を通して開始されたクエリを受取る際、検索サーバ１６０は、クエリ応答モジュール１６４を用い、ユーザのクエリおよびコンテキストベクトル（および任意にあらゆる他の利用可能なメタデータ）に基づいて検索を実行する。クエリ応答モジュール１６４は、ヒットリストを生成し、ランク付けする。結果として生じるヒットリストは、一般に少なくとも部分的にコンテキストベクトルに依存し、たとえば検索結果ページのフォームでユーザに返される。コンテキストベクトルは検索を実行する際にさまざまな方法で用いられ得る。たとえば、１つの実施例では、ユーザのクエリ（たとえば図３のテキストフィールド３０６における明示的な入力）は、コンテキストベクトルから選択された１つ以上のキーワードを加えることにより修正され、別の実施例では、検索は、結果をランク付けするのに用いられたコンテキストベクトルからのキーワードおよび／またはカテゴリデータと共に、実行依頼された通りのユーザのクエリを用いて実行される。付加的な実施例は下記に説明される。

いくつかの実施例では、ホスティングページの文脈探索インターフェースは、比較的小さなアイコンだけがページに現われる「非アクティブ」状態で最初に表示され得る。非アクティブの文脈探索インターフェースの例は図５に図示される。ホスティングページ３００′は、図３のホスティングページ３００と同じソースコードから生成され、同じコンテンツ３０２を有している。しかしながら、ページ３００′では、図３に示される完全な文脈探索インターフェース３０４ではなく小さな文脈探索アイコン５０４だけが表示される。アイコン５０４は非アクティブな文脈探索インターフェースを表わす。コンテンツ３０２と関連する文脈探索の実行を所望する、ページ３００′を見ているユーザは、アイコン５０４をたとえばクリックするかそうでなければ選択することによって文脈探索インターフェースを起動することができる。アイコン５０４の選択により、アクティブ状態の文脈探索インターフェース３０４を用いて、図３のページ３００が表示されてユーザが文脈探索を実行することができるようになる。

ホスティングページにはいかなる数の文脈探索インターフェースが与えられてもよく、各文脈探索インターフェースは近くのコンテンツを反映するそれ自体のコンテキストベクトルを有し得る。たとえば、図６はホスティングページ６００を示し、そのコンテンツはいくつかの異なるニュース記事の要約６０２、６０４、６０６を含む。各要約６０２、６０４、６０６は、その近くに置かれたそれぞれの文脈探索アイコン６１２、６１４、６１６を有する。各アイコン６１２、６１４、６１６は異なる文脈探索インターフェースの非アクティブ状態であり、その各々は、隣接する要約６０２、６０４、６０６から導き出されたそれ自体のコンテキストベクトルを有する。これらのアイコンのうちのいずれか１つがユーザによって起動され、次に（たとえば、アイコン５０４およびアクティブな文脈探索インターフェース３０４に関して上述されたのと同じ態様で）文脈探索を始めるために用いられ得る。アイコン６１４から開始された検索のためのコンテキストベクトルは要約６０４から有利に導き出され、アイコン６１２から開始された検索のためのコンテキストベクトルは要約６０２から有利に導き出される、などと続く。アイコン６１２および６１４が異なる関連コンテキストベクトルを有するので、一般に検索結果（ヒットまたはそのランク付けもしくはその両方）は、同じクエリが入力されたとしても、アイコン６１２を介して始めた検索と６１４を介して始めた検索とで異なるであろう。

さらに下記の１つの実施例では、ホスティングページの作成者は、ページに文脈探索インターフェースをいくつ含むべきか、それらがどこに位置するべきか、およびページのどの部分を用いて検索用コンテキストを規定するべきかを決定することができる。

以下のセクションでは、文脈探索インターフェースおよびコンテキストベクトルの生成のための例となる実施例（セクションＩＩ）、クエリ処理におけるコンテキストベクトルの使用（セクションＩＩＩ）、および、文脈探索を強化するための付加的なオプション機構（セクションＩＶおよびＶ）を説明する。

ＩＩ．文脈探索インターフェースおよびコンテキストベクトルの生成
Ａ．コンテンツプロバイダによる生成
いくつかの実施例では、ウェブページを作成するコンテンツ開発者の自由裁量で、１つ以上の文脈探索インターフェースをウェブページに加えることができる。たとえば、検索プロバイダ（または他の文脈探索技術の実施者）は、文脈探索を実現するためのアプリケーションプログラムインターフェース（ＡＰＩ）を発行してもよい。ＡＰＩは、検索サーバ１６０が文脈探索リクエストを認識し処理することができるように、そのようなリクエストを特定するためのフォーマットを含む。１つの実施例では、ＡＰＩは、検索サーバ１６０に文脈探索を実行依頼するためのベースＵＲＬを特定し、ユーザのクエリおよびコンテキストベクトルを代表する付加的なデータを用いてそのベースＵＲＬを強化するためのフォーマットを特定する。ＡＰＩはさらに、特定の実現例に応じてクエリおよび／またはコンテキストベクトルをエンコードするためのフォーマットを特定することもできる。

いくつかの実施例において、ＡＰＩはさらに、文脈探索インターフェースの外観および／または特徴を特定することもできる。たとえば、ＡＰＩは、インターフェースが非アクティブ状態のアイコンとして最初に表示されるべきか否か、そのようなアイコンはいかに見えるべきか、および、文脈探索を実行する機会をユーザに知らせるためのアイコンとともに表示される標準的なフレーズを特定することができる。ＡＰＩの他の局面では、アクティブ状態における文脈探索インターフェースの特徴、たとえばテキストボックスおよび／または他の入力フィールドが与えられるべきか、またそのようなフィールドがいかに見えるべきかなどを特定することができる。オプションではあるが、文脈探索の審美的な局面に均一な仕様を与えることは、文脈探索インターフェースについてのユーザの意識および認識を促すのに役立ち得る。

ＡＰＩのすべてまたは一部は、ウェブページに挿入することができる利用可能な画像、またはコンテンツ作成者がページに挿入すればよいだけの（ＨＴＭＬなどの）一般に使用されるウェブページコード化言語の適切なコードブロックを作ることによって与えられてもよい。

コンテンツプロバイダは、ホスティングページのソースコードに適切なコードを含め、このコードにホスティングページの実際のコンテンツを代表するコンテキストベクトル用の適切なデータを補足することにより、文脈探索インターフェースを実現することができる。コードの実行が結果として文脈探索リクエストになる限り、ＡＰＩ準拠のフォーマットにおいていずれの言語のいずれのコードでも用いることができ、文脈探索インターフェースへの入力に応じて生成され、検索サーバ１６０に実行依頼される。

他の実施例において、検索プロバイダ（または文脈探索技術の他の実施者）は、たとえばホスティングページの文脈探索コードのいくらかまたはすべての作成を自動化することによって、コンテンツプロバイダによる文脈探索インターフェースの作成をさらに容易にする。１つの例として、ホスティングページコンテンツからのコンテキストベクトルの生
成が有利に自動化され得る。図７および図８は、文脈探索インターフェースを作成するための部分的に自動化されたプロセスを示すフロー図であり、図７はコンテンツ開発者によって実行されるプロセス７００を示し、図８は検索プロバイダによって実行されるプロセス８００を示す。

プロセス７００は、コンテンツ開発者が概念検索インターフェースを含むウェブページのためのコンテンツを作成し、または修正することから始まる（ステップ７０２）。コンテンツは、従来のウェブ開発ソフトウェアの使用を含む、いかなる手動または自動の手法を用いて生成されてもよい。いつかの時点で、コンテンツ開発者は、文脈探索インターフェースをホスティングウェブページのコンテンツのいくらか（またはすべて）の部分に関連付けることが望ましいと決定する。コンテンツ開発者は、文脈探索インターフェースに関連付けられるコンテンツを選択し（ステップ７０４）、それを検索プロバイダに実行依頼する（ステップ７０６）。

検索プロバイダへのコンテンツの実行依頼は複数の方法で行われ得る。いくつかの実施例では、検索プロバイダはコンテンツプロバイダのためにウェブブラウザベースの文脈解析インターフェースを提供する。このインターフェースは、たとえば、図２に示される検索サーバ１６０のコンテキスト処理モジュール１６６に対するインターフェースであってもよい。コンテンツ開発者は、自分のブラウザをこのインターフェースへナビゲートし、ホスティングページから適切なコンテンツを（たとえばコピーペーストによって）入力することができる。他の実施例では、コンテンツ開発者は、検索プロバイダの文脈解析インターフェースへブラウザをナビゲートし、ホスティングウェブページへＵＲＬを実行依頼するかもしれない。さらに他の実施例においては、検索プロバイダは（たとえばコンテキスト処理モジュール１６６の局面を組込んだ）ソフトウェアツールを配布してもよく、コンテンツプロバイダがそれを用いてコンテンツを選択し、ウェブブラウザを用いずにそれを検索プロバイダに実行依頼することができる。このツールは、デスクトップツール、またはさまざまなウェブコンテンツ開発ソフトウェアプログラムに組込むことができるウィジェットなどの、さまざまな形式をとってもよい。

開発者からコンテンツを受取る際、コンテキスト処理モジュール１６６はコンテンツを分析し、コンテキストベクトルを生成する。図８は、コンテキスト処理モジュール１６６において実現され得るプロセス８００のフロー図である。プロセス８００は、文脈探索インターフェースに関連付けられるコンテンツがコンテキスト処理モジュール１６６によって受取られると、開始する（ステップ８０２）。

ステップ８０４において、受取られたコンテンツはトークン（token）にされる。トークンにすることは従来の手法を用いて行うことができ、たとえば単語の境界の検知、単語の正準化（たとえば接尾辞の除去、スペルミスまたは変形などの修正など）、一般的すぎて検索では有用になり得ないさまざまな単語（たとえば定冠詞（the）、および（and）など）の除去などを含み得る。ステップ８０６で、トークンは、用語のコンテンツにおける発生頻度などの適切な基準によって仕分けられ、ステップ８０８では、最も頻繁に発生するトークンがコンテキストベクトルに含まれるよう選択される。選択されるトークンの数はたとえば何らかの整数Ｋに限定されてもよい。

ステップ８１０で、コンテキストベクトルがトークンを用いて生成される。１つの実施例では、コンテキストベクトルは選択されたトークンと同様にそれぞれの頻度および他の任意の情報も含む。いくつかの実施例では、トークン間の同時発生および相関をも用いてコンテキストベクトルに組込むことができるフレーズを特定する。（たとえば図３のコンテンツ３０２では、「Ｇｏｌｆ Ｃａｂｒｉｏ（ゴルフ・カブリオ）」というフレーズが特定され得る。）さらに、コンテンツに含まれるリンク先の文書のＵＲＬ（または他の識
別子）またはコンテンツ自体のＵＲＬ（または他の識別子）が含まれていてもよい。より一般に、コンテンツを代表する任意の情報、またはコンテンツの何らかの局面もコンテキストベクトルに含まれていてもよい。

ステップ８１２で、コンテキストベクトルは、文脈探索インターフェースを実現する標準的なコードのブロックに挿入される。１つの実施例では、一般的なコードブロックは、検索サーバのもとにコンテキストクエリを送るために用いられる強化されたＵＲＬ用のテンプレートを含み、ステップ８１２は、このテンプレートにコンテキストベクトル（またはそのコード化された表示）を挿入することを含む。一般的なコードブロックは、さらに、ユーザのクエリを検索サーバに送る前に強化されたＵＲＬに挿入するためのコード、アクティブおよび／または非アクティブ状態で文脈探索インターフェースを表示するためのコードなどの、他のコードを含んでもよい。コンテキストベクトルを含む、結果として生じるコードブロックは、ステップ８１４でコンテンツ開発者に返される。

図７を再び参照して、ステップ７０８で、コンテンツ開発者はコンテキスト処理モジュール１６６からコードブロックを受け取る。ステップ７１０で、コンテンツ開発者は所望の時点でホスティングウェブページにコードブロックを挿入し、それによってページに文脈探索インターフェースを加える。

ここに説明された文脈探索インターフェースを生成するためのプロセスが例示的であって、変形および修正が可能であることが認識される。連続するとして説明されたステップは並行して実行されてもよく、ステップの順序は変えられてもよく、ステップは修正されても組み合わせられてもよい。コンテンツの選択および文脈探索コードブロックの挿入などのさまざまなステップは、自動化されてもよく、手動で実行されてもよい。１つの代替実施例では、検索プロバイダは、コンテンツプロバイダのシステムにインストールされ実行され得るコンテキスト処理モジュールを与えてもよく、その結果、コンテキストベクトルを生成するために情報が検索プロバイダのもとに送られる必要はない。さらに、いくつかの実施例では、たとえばページコンテンツが更新されるときにコンテキストベクトルが自動的に更新されるよう、文脈探索インターフェースの生成が自動化されてもよい。たとえば、図４のページ４００がニュースページを表わし、そのトップ記事が頻繁に変更される場合、関連付けられた記事が変更されるたびに文脈探索インターフェースのうちの１つのためのコンテキストベクトルを自動的に更新するようなプロセスが与えられてもよい。

コンテキストベクトルを生成するための他のアルゴリズムも実現され得る。たとえば、いくつかのアルゴリズムは、見出し、小見出し、メタタグ、または他の選択されたフィールドに現れる用語に本文に現れる用語よりも大きい重みを与えることができる。いくつかのアルゴリズムは非テキストコンテンツ（たとえば画像または媒体コンテンツ）をも考慮に入れることができ、それについて適切なコンテンツ記述子が利用可能であるか、または決定され得る。コンテキストベクトルにおける用語は単一の単語に限定されない。用語はフレーズ（互いに隣接して発生する２つ以上の単語）であってもよい。いくつかの実施例では、コンテキストベクトルはコンテンツで見つかった用語以外の情報に基づいて生成され得る。たとえばコンテンツプロバイダは、コンテンツのためのカテゴリまたは他のコンテキスト識別子を指定するように促されてもよく、この情報をコンテキストベクトルに含むことができる。別の実施例では、コンテキストベクトルは、コンテンツに含まれるリンクについての情報（たとえばそのようなリンクのＵＲＬまたはリンク先ページについてのカテゴリ情報）を含んでもよい。

いくつかの実施例では、コンテキストベクトルは、エンコードされた形式で文脈探索インターフェースのコードブロックに含まれ得る。たとえば、ハッシュ関数または他の適切な手法が用いられて、コンテキストベクトルのさまざまなトークンを代表してもよい。別
の例として、完全なコンテキストベクトルデータは、検索サーバがアクセス可能なテーブルまたはデータベースに記憶されることができ、コードブロックは、検索サーバがクエリ処理中にコンテキストベクトルデータを調べるために用いることのできるキーまたは他のコードを含んでもよい。

Ｂ．ユーザによる生成
別の実施例において、任意のウェブページを見ているユーザが、そのページ（あるいはその一部）について文脈探索インターフェースを生成することができる。たとえば検索プロバイダは、ユーザがブラウザウィンドウに表示された任意のウェブページの一部を検索クエリ用のコンテキストとして選択することができるようにする、「文脈探索」ウィジェット（widget）を有するブラウザツールバーを与えてもよい。

図９は、ユーザによる文脈探索インターフェース生成のプロセス９００のフロー図である。ユーザは、プロセス９００が開始するとき、ブラウザ（たとえば図２のクライアントアプリケーション１２５のユーザインターフェースモジュール１２７の一局面など）を用いてウェブページを見ている。ユーザのブラウザは、「文脈探索」ウィジェットを有するツールバーを備える。見ているページは、コンテンツプロバイダが供給する文脈探索インターフェースを含んでも含まなくてもよい。ステップ９０２で、ページを見ている間、ユーザは、ツールバーから（たとえばそれをクリックすることによって）「文脈探索」ボタンを選択する。これに応答して、ステップ９０４において、ブラウザは表示されたページの一部を検索用コンテキストとして選択するようにユーザに促す。この催促は、たとえばマウスカーソルを選択を表示する形状に変えること、および／またはテキストプロンプトを表示することを含んでもよい。

ステップ９０６で、ユーザは、たとえば表示されたページのある領域でマウスカーソルをクリックし、ドラッグすることによって、表示されたページの一部またはすべてを選択する。選択されたテキストは強調して示され（たとえば色が変更され、またはコンテンツのまわりにボックスが描かれ）、ユーザに視覚的なフィードバックを与える。いくつかの実施例では、クリックおよびドラッグ手法に加えて、またはその代わりに、他のコンテンツ選択機構が与えられてもよい。たとえば、ユーザは予め定義されたキーを押すことにより全ページを選択することができてもよく、マウスカーソルがあるパラグラフの任意の場所に位置決めされている間にクリックすることによってそのパラグラフを選択してもよく、または、マウスカーソルがセクションの見出しに位置決めされている間にクリックすることによってそのセクションを選択することができてもよい。

ステップ９０８において、選択されたコンテンツからクライアントアプリケーション１２５がコンテキストベクトルを生成する。一実施例では、クライアントアプリケーション１２５は、上述のプロセス８００に従ったコンテキストベクトル生成のために、選択されたコンテンツを検索サーバ１６０のコンテキスト処理モジュール１６６に実行依頼してもよい。別の実施例では、クライアントアプリケーション１２５はコンテンツを局所的に処理するよう構成され、検索サーバに情報を送信することなく、（たとえばプロセス８００のステップを介して）コンテキストベクトルを生成する。そのような処理能力は、たとえば図２のクライアントアプリケーション１２５の専用検索モジュール１２６の一部としてコンテキスト処理モジュールを含むことによって実現され得る。

ステップ９１０において、ブラウザは現在のページを再表示し、ページの選択された部分において、またはその近くに文脈探索インターフェースを加える。この実施例では、新しく追加された文脈探索インターフェースは、ユーザが最初にインターフェースを起動することなくクエリを入力するだけで実行依頼することができるように最初からアクティブ状態で現われてもよく、または非アクティブ状態で現われてもよい。ユーザに生成される
文脈探索インターフェースが一旦生成されると、上述の文脈探索インターフェース３０４と同様に有利に作用する。特に、ユーザに生成される文脈探索インターフェースを通してユーザがクエリを入力すると、クライアントアプリケーションは、クエリとユーザに生成される文脈探索インターフェースに関連付けられたコンテキストベクトルとを検索サーバに実行依頼する。

プロセス９００は例示であって、変形および修正が可能なことが認識される。連続するとして説明されたステップは並行して実行されてもよく、ステップの順序は変えられてもよく、ステップは修正され、組合わせられてもよい。たとえば、ユーザはコンテンツを最初に選択し、次に検索ツールバーの「文脈探索」ボタンを起動してもよい。文脈探索インターフェースをウェブページに加える代わりに、ユーザに生成される文脈探索インターフェースが（たとえば標準的な非文脈探索インターフェースの代わりに）ツールバーに置かれてもよく、または別個のポップアップウィンドウで与えられてもよい。

他の実施例において、クライアントアプリケーションは、クエリに先立ってコンテキストベクトルを生成するのではなく、選択されたコンテンツをユーザのクエリと一緒に検索サーバに送ってもよく、検索サーバはそのクエリ処理活動の一部としてコンテキストベクトルを（たとえば、コンテキスト処理モジュール１６６を用いて）生成してもよい。このコンテキストベクトルはクライアントアプリケーションに送り返されて、クライアントアプリケーションによってその後の再使用のためにキャッシュしてもよい。

別の実施例では、ユーザは、たとえば付随するテキストの一部を選択することによって、先在する文脈探索インターフェース用のコンテキストを改良することができてもよい。そのような選択がなされる場合、文脈探索インターフェースに関連付けられるコンテキストベクトルは、たとえば選択されたテキストに現われる用語だけを含むよう修正することができ、それにより、コンテキストがいかに定義されるかについて、ユーザにさらなる制御を与える。

さらに別の実施例において、クライアントアプリケーションはまた、ユーザのデスクトップ上のアイコンまたはオペレーティングシステムのツールバーにおいてアクセス可能な、文脈探索生成のためのモジュールを含んでもよい。そのようなモジュールによって、ユーザは、たとえばワープロまたはファイルビューアアプリケーションにおいて開いた文書、電子メールメッセージ、インスタントメッセージなどを含むウェブページ以外のコンテンツに基づいて文脈探索を実行するためのコンテキストベクトルを作成することができ得る。ブラウザが開いているか否かに関わらず、ユーザはいつでもこのアイコンを起動することができ、（偶然表示されるすべてのウェブページを含む）自分のデスクトップ上のいずれの文書からでも、コンテキストベクトルを生成するためのコンテンツを選択できる。選択されたコンテンツのためのユーザに生成される文脈探索インターフェースは、たとえば選択されたコンテンツの近くのポップアップウィンドウもしくはダイアログボックスに、または他の適切なユーザインターフェース要素に現れる。検索が実行されて結果が返されると、クライアントアプリケーションは有利にブラウザウィンドウを開き、結果を表示し、ユーザがヒットページまたはサイトにナビゲートすることを可能にする。

ＩＩＩ．クエリ処理におけるコンテキストベクトルの使用
上述のように、図３のインターフェース３０４などの文脈探索インターフェースがアクティブな場合、ユーザはテキストフィールド３０６にクエリを入力して実行依頼ボタン３０８を操作することにより、文脈探索を始めてもよい。これに応答して、検索サーバがユーザのクエリに応答するのを助けることができるコンテキスト情報がコンテキストベクトル（たとえば図４のコンテキストベクトル４００）を介して供給され、コンテキストベクトルは文脈探索インターフェースに関連付けられてユーザのクエリとともに自動的に検索
サーバに送られるる。

検索サーバ（たとえば図２の検索サーバ１６０）は、ユーザのクエリおよびコンテキストベクトルの両方を含む文脈探索クエリを受取り、たとえばクエリ応答モジュール１６４を用いて検索を実行する。文脈探索クエリを処理するためのアルゴリズムは、ユーザの興味が近隣のコンテンツに関連するであろうという前提を有利に活用する。したがって、そのコンテンツを代表するコンテキストベクトルが検索結果を生成するために有利に用いられる。検索が周辺のコンテンツに関連付けられることを望まないユーザは、非文脈探索を実行するための異なるインターフェース（たとえば検索ツールバーまたは検索プロバイダのウェブインターフェース）を用いてもよく、また検索サーバ１６０はコンテキストクエリ、非コンテキストクエリの両方を処理するよう構成されてもよいことに注意されるべきである。

文脈探索クエリを処理するための特定のアルゴリズムがここで説明される。図１０は、このようなプロセス１０００フロー図であり、そこでユーザが与える検索用語はコンテキストベクトルからの１つ以上の付加的な用語を用いて補足される。

ステップ１００２で、ユーザが供給する少なくとも１つの用語および関連するコンテキストベクトルを含むコンテキストクエリが受取られる。ステップ１００４で、たとえば従来のクエリ構文解析手法を用いて、ユーザが供給する用語から１つ以上のユーザキーワードが抽出され、それは単語の境界を検知し、単語を正準化し（たとえば接尾辞の除去、スペルミスまたは変形の修正など）、一般的すぎて検索では有用になり得ないさまざまな単語（たとえば定冠詞（the）、および（and）など）をなくすことなどを含むことができる。

ステップ１００６で、ユーザキーワードを補足するために、コンテキストベクトルから１つ以上のコンテキストキーワードが抽出される。いくつかの実施例では、コンテキストベクトルは、（たとえばプロセス８００について上述のように）既に解析され、正準化された用語を含み、したがって、既にキーワードとしての使用に適している。他の実施例では、コンテキストベクトルにおける用語について構文解析および正準化が同様に実行されてもよい。さらに、ステップ１００６は、コンテキストベクトルのうちどの用語がいくつ、コンテキストキーワードとして用いられるべきかを決定することを含んでもよい。たとえば、いくつかの実施例では、少なくとも１つの最小の頻度または重みを有する用語だけが選択されてもよく、または、選択することができる用語の数が制限されて、最も頻繁であるか、または最も大きい重みがつけられた用語がまず選択されてもよい。選択されたコンテキストキーワードの数は、ユーザキーワードの数にも依存し得る（たとえばより多くのユーザキーワードを備えたクエリについては、より少ない数のコンテキストキーワードが選択されてもよい）。ステップ１００６は、ユーザキーワードと重複するいかなるコンテキストキーワードをも検知しクエリから除去することを含んでもよい。重複したキーワードは、公知の同義語および完全な複製をも含み得る。

ステップ１００８で、ユーザキーワードおよびコンテキストキーワードを含むクエリを用いて検索が実行される。検索実行は、１つ以上のキーワード（または、いくつかの実施例ではすべてのキーワード）を包含するウェブページを特定するための従来の手法を組込んでもよい。そのようなページは本願明細書において「ヒット」（または「検索ヒット」）と呼ばれる。ステップ１０１０で、検索ヒットは、適切なランク付けアルゴリズムによって決定される関連度に基づいてランク付けされる。ヒットページ中のキーワードの頻度および／または近似性に基づいて各ヒットページのスコアリングをする従来のアルゴリズムが用いられてもよく、その場合ユーザのキーワードおよび／またはコンテキストのキーワードがスコアリングにおいて考慮される。さらに、キーワードとして選択されなかった
コンテキストベクトルからのいかなる用語も、ページのスコアおよびランク付けの決定に用いられ得る。ヒットにリンクするページの数、ヒットページに関連するユーザの評価および好み、および／またはさまざまなヒットページのスポンサー権を含む他の基準も、ランク付けを決定する際に考慮されてもよい。

ステップ１０１２で、検索結果がユーザに返される。１つの実施例では、結果は、ユーザのブラウザを介して表示することができるウェブページとして、さまざまなヒットページまたはサイトへのリンクを伴って返される。結果ページは、たとえばホスティングページから結果のページまでブラウザを転送することによって、または結果ページの新しいブラウザウィンドウを開くことによって表示されてもよい。多くのヒットが返されなければならない場合、複数の相互リンクされた結果ページが生成され得る。結果のページは、ユーザのもとのクエリ、および検索クエリに加えられたコンテキストキーワードの両方を表示し得る。この情報はいくつかの実施例では対話型のフォームを用いて示され、それを介してユーザが自分のクエリもしくはコンテキストキーワード（または両方）を修正することができ、修正されたコンテキストのクエリを検索サーバ１６０に実行依頼することができる。

図１１は、文脈探索を実行するための代替的プロセス１１００のフロー図である。プロセス１１００では、ユーザのクエリ用語は付加的なコンテキストキーワードなしで用いられてヒットを生成し、コンテキストデータはランク付けアルゴリズムに組込まれる。より具体的には、ステップ１１０２では、ユーザが供給する少なくとも１つの用語および関連付けられたコンテキストベクトルを含むコンテキストのクエリが受取られる。ステップ１１０４で、ユーザが供給する用語から１つ以上のユーザキーワードが抽出される。このステップは、上述のプロセス１０００のステップ１００４に類似していてもよい。ステップ１１０６で、ユーザキーワードからできたクエリを用いて検索が実行され、ヒットリストを生成する。プロセス１０００と異なり、コンテキストベクトルに基づくキーワードは、検索クエリにおいてユーザキーワードを補足するためには用いられない。プロセス１０００について上述されたように、検索実行は従来の手法を用いて実現され得る。

ステップ１１０８で、コンテキストベクトルからコンテキストキーワードが抽出され、このステップは上述のプロセス１０００のステップ１００６に類似し得る。ステップ１１１０で、ヒットはコンテキストキーワードを用いてランク付けされる。いくつかの実施例ではユーザキーワードもランク付けに用いられてもよい。ランク付けアルゴリズムは、プロセス１０００のステップ１０１０で使用されたアルゴリズムに概して類似していてもよい。ステップ１１１２で、プロセス１０００のステップ１０１２と同様に、ユーザに結果が返される。プロセス１０００と同様に、ユーザのクエリおよびコンテキストキーワードは対話型のフォームを用いて提示され、これを介してユーザが自分のクエリもしくはコンテキストキーワード（または両方）を修正することができ、修正されたコンテキストクエリを検索サーバ１６０に実行依頼することができる。

プロセス１０００および１１００は、ヒットのコンテンツおよび／または順序について異なるヒットリストを結果として生じ得ることに注意されるべきである。これらのプロセスにおける他の変形例もあり得る。たとえば、コンテキストベクトルからの用語は、検索クエリの中でコンテキストキーワードとして用いられるものもあり、ヒットをランク付けするためにのみ用いられるものもある。別の変形例では、コンテキストキーワードのみが検索に用いられる一方で、ユーザキーワードが検索ヒットをランク付けするためにのみ用いられることができる。

いかなる場合も、ユーザキーワードおよび／またはコンテキストキーワードに基づくページのランク付けは、クエリについてのさまざまなメタデータを用いる他のページランク
付けアルゴリズムに基づいてさらに修正され得ることが理解されるべきである。例として、曖昧な用語を解決するため、ユーザの意図を推定するためのさまざまな経験則と同じく、（ユーザの識別性が知られている場合の）ユーザプロファイルデータの使用を含む。ヒットリストに加えて、検索結果ページはさらに、スポンサーされている結果または検索プロバイダによって決定される他のコンテンツを含んでもよい。

ＩＶ．増補された（Augmented）コンテンツを用いる文脈探索インターフェース
上述のように、文脈探索インターフェースは有利にアクティブ状態および非アクティブ状態を含む。非アクティブ状態では、（たとえば図５に示される）小さなアイコンが表示され得る。これはユーザに文脈探索オプションが利用可能であると通知しつつ、一方でページ上の視覚的なクラッタを減じることができる。アクティブ状態においては、（たとえば図３に示される）クエリフォームおよび実行依頼制御が表示される。

いくつかの実施例において、文脈探索インターフェースがアクティブな場合、クエリフォームは、ユーザが興味を持つかもしれない付加的なコンテンツ（本願明細書で「スペシャルコンテンツ」と呼ばれる）によって増補されてもよい。一般に、ユーザが非アクティブな文脈探索アイコンを起動することを選択すると、ユーザがそのコンテキストに関連コンテンツに興味を持っているであろうと推論することができる。コンテンツ増補機能により、そのようなコンテンツ（またはそのようなコンテンツへのリンク）がアクティブな文脈探索インターフェースの一部として示され、非アクティブな文脈探索インターフェースについては示されない（あるいは隠されている）ことを可能にする。スペシャルコンテンツは、起動されている文脈探索インターフェースのコンテキストベクトルに基づいて動的に選択することができる。

１つの実施例では、増補されたコンテンツは、買物関連コンテンツ（本願明細書で「コンテキスト内店舗（Shop in Context）」と呼ぶ）を含み、そこではコンテンツに関連する製品を買う機会がユーザに与えられる。たとえば、上述の図６のウェブページ６００は、各々が固有の文脈探索アイコン６１２、６１４、６１６を伴った、異なるニュース記事６０２、６０４、６０６の要約を含む。ユーザは、これらのアイコンのうちの１つ、たとえばアイコン６１２をクリックすることにより起動することができ、それにより、アクティブな文脈探索インターフェースが表示されるようにし、かつ表示されたページに「コンテキスト内店舗」コンテンツが加えられるようにする。

図１２は、文脈探索アイコン６１２が起動された後のウェブページ６００の部分を示す。アイコン６１２は増補された文脈探索インターフェース１２０２にまで拡張され、それは以前に説明された文脈探索インターフェースと同様に動作する検索ボックス１２０４および実行依頼制御１２０６（この例においては「Ｓｅａｒｃｈ（検索）」とラベル付けされる）を含む。増補された文脈探索インターフェース１２０２は「コンテキスト内店舗」コンテンツ１２０８をも含み、それはこの場合、ニュース記事６０２の対象（具体的には音楽家Ｂｏｎｏ（ボノ））に関連する商品を買うことができるサイトを特定するリンクおよびテキストを与える。

文脈探索インターフェースのための「コンテキスト内店舗」コンテンツはコンテキストベクトルに基づいて有利に選択され、その結果、同じページの異なる文脈探索インターフェースを起動することにより、一般に異なる「コンテキスト内店舗」コンテンツが生成される。たとえば、図１２はニュース記事６０４に関連付けられた文脈探索インターフェース１２１２をも含む。図６の文脈探索アイコン６１６が起動されるとインターフェース１２１２が現われる。文脈探索インターフェース１２１２は、テキストフィールド１２１４、実行依頼ボタン１２１６、および「Shop in Context（コンテキスト内店舗）」コンテンツ１２１６を含む。記事６０４が記事６０２とは異なる対象に関するので、（Venus Wi
lliams（ヴィーナス・ウイリアムズ）に関する）「Shop in Context（コンテキスト内店舗）」コンテンツ１２１６は、コンテンツ１２０８とは異なる。

いくつかの実施例では、「コンテキスト内店舗」コンテンツなどのスペシャルコンテンツは、文脈探索インターフェースがユーザによって起動されるとき、コンテンツリクエストをクライアントアプリケーション１２５（図２）からコンテンツ増補サーバ１８０へ送ることにより動的に生成される。このコンテンツリクエストはコンテキストベクトルを含み、コンテンツ増補サーバ１８０が適切なスペシャルコンテンツを選択するためにそれを用いる。コンテンツ増補サーバ１８０は、検索プロバイダによって、または文脈探索技術の別の実施者によって、操作されてもよい。

図１３は、スペシャルコンテンツ（たとえば「コンテキスト内店舗」コンテンツ）を含む増補された文脈探索インターフェースを生成するためのプロセス１３００のフロー図である。ステップ１３０２で、図６のページ６００などのホスティングページがユーザのブラウザに表示される。上述のように、ホスティングページは１つ以上の文脈探索インターフェースを含み、各々は非アクティブ（アイコン）状態にある。ステップ１３０４で、ユーザはこれらのインターフェースのうちの１つを、たとえばそれをクリックすることによって起動する。ステップ１３０６で、新しく起動されたインターフェースのためのコンテキストベクトルを含むコンテンツリクエストがコンテンツ増補サーバ１８０に送信される。

ステップ１３０８で、コンテンツ増補サーバ１８０は、コンテキストベクトルに基づいて、ホスティングページに加えられるコンテンツを生成したり選択したりする。たとえば、コンテンツ増補サーバ１８０はスポンサーされたコンテンツデータベース１６２（図２に示される）にアクセスしてもよく、スポンサーされたコンテンツの特定の項目をさまざまなキーワードに有利に関連付ける。コンテンツ増補サーバ１８０は受取ったコンテキストベクトルからキーワードを抽出し、キーワードに基づいて１つ以上のスポンサーされたコンテンツの項目をデータベース１６２から選択することができる。選択される項目の数は、所望であれば制限することができる（たとえば図１２では、各文脈探索インターフェースについて２つの項目が選択される）。最大個数を越えた数の項目がキーワードと一致する場合、項目の選択はさまざまな基準、たとえば各項目と一致するキーワードの数もしくは重要性、および／または、コンテンツ増補サーバ１８０のプロバイダとデータベース１６２のコンテンツのさまざまなスポンサーとの間のスポンサー契約の条件などに基づくことができる。

ステップ１３１０で、コンテンツ増補サーバ１８０はクライアントアプリケーション１２５にスペシャルコンテンツを返し、スペシャルコンテンツを含むホストページを再表示する（ステップ１３１２）。文脈探索インターフェースの挿入ポイントに続くいかなるホスティングページコンテンツも、スペシャルコンテンツのための場所を空けるために、必要に応じて下へ移動され得る。

本願明細書に説明されたプロセスは例示的であり、変形および修正が可能であることが理解される。連続するとして説明されたステップは、並行して実行されてもよく、ステップの順序が変えられてもよく、ステップが修正されても組合わされてもよい。いくつかの実施例において、たとえば文脈探索インターフェースが生成されたり更新されたりするとスペシャルコンテンツが前もって選択され、ホスティングページ用のソースコードに組込まれて、そのためリアルタイムでコンテンツ増補サーバにリクエストする必要がない。ホスティングページが複数の文脈探索インターフェースを含む場合、スペシャルコンテンツは任意のアクティブなインターフェースについて表示され、非アクティブのインターフェースについても表示されることがないことが理解される。

スペシャルコンテンツは、買物または宣伝情報に限定されない。他のタイプのスペシャルコンテンツは、そのコンテンツ関連のニュース記事へのリンク、コンテンツ関連の最も人気のあるウェブサイトへのリンク、関連画像または媒体コンテンツ、または他のいかなるタイプのコンテンツを含んでもよい。コンテキストベクトルに基づいて、たとえばコンテキストベクトルを用いて適切なデータベースにアクセスすることによって、任意のタイプのスペシャルコンテンツを選択することができる。たとえば、関連ニュース記事へのリンクは、コンテキストベクトルから選択された用語（またはすべての用語）を用いて１つ以上のニュースサーバまたはニュースサイトにクエリすることにより生成されてもよい。最も人気のある関連サイトのリストは、たとえば、最も人気のあるサイトのリストを得て、そのリストからコンテキストベクトルの用語を包含するサイトを特定することによって生成することができる。関連画像は、画像データベースにアクセスすることにより見つけることができる。

より一般には、文脈探索インターフェースに関連付けられたコンテキストベクトルはさまざまな方法において用いられ、関連コンテンツを特定することができる。本願明細書に説明されたコンテンツ増補システムおよび方法を用いると、ユーザが文脈探索インターフェースの起動によりそのようなコンテンツへの関心を示すまでは、そのようなコンテンツを表示することを延期することができる。このようにして、ホスティングページに表示される特定の話題に関連する情報の量は、その話題に対してユーザが示した興味に依存し得る。

Ｖ．さらなる実施例
文脈探索能力およびコンテキストベクトルはさまざまな他の実施例および適用例を有する。いくつかの例がここで説明される。これらの例は例示的であり、本発明を限定しないことが理解される。

いくつかの実施例では、コンテキストベクトルはユーザによるクエリ入力を容易にするために用いられる。たとえば、ユーザがホスティングウェブページを見ながらクライアントアプリケーションの検索ツールバー・インターフェースに（たとえばタイプすることによって）クエリの入力を開始する場合、クライアントアプリケーションは、そのページのコンテキストベクトルを用いてクエリのオートコンプリート提案を生成することができる。これは、特定の文脈探索インターフェースがアクティブか非アクティブかにかかわらず行うことができる。たとえば、図６のページ６００では、ユーザが検索ツールバー・インターフェース（図６に示されない）に「Ｖ−Ｅ−Ｎ」とタイプした場合、クライアントアプリケーションは意図したテキストとして「ヴィーナス（Venus）」または「ヴィーナス・ウイリアムズ（Venus Williams）」を提案することができる。次いで、ユーザはＥｎｔｅｒまたはＴａｂキー（または他の指定されるキー）を叩いてその提案を受取るか、または単に提案を無視してタイプを続けることができる。同様に、ユーザが文脈探索インターフェースにクエリのタイプを開始する場合、そのインターフェースのコンテキストベクトルが用いられてユーザのためにオートコンプリート提案を生成してもよい。

他の実施例では、コンテキストベクトルは「クエリがない」検索を実現するために用いられてもよい。ユーザはアクティブな文脈探索インターフェース（たとえば図３のインターフェース３０４）から、いかなるクエリ用語も入力せずに単に実行依頼ボタンを起動してもよい。ユーザ用語のない文脈探索が実行依頼される場合、検索サーバ（またはクライアントアプリケーション）は、コンテキストベクトルまたはコンテキストベクトルから選択された用語に基づいてクエリを構築し処理するよう構成され得る。

いくつかの実施例では、検索サーバは、文脈探索関連のデータを集め、このデータをこ
のような検索の結果を向上させるために用いてもよい。データは、たとえばコンテキストベクトルごと、またはホスティングページごとに集められてもよい。データは、特定のコンテキストベクトルとともに、または特定のホスティングページから受け取られたクエリを含むログファイル、ログされたクエリを入力したユーザが実際にはどのヒットを調査していたのかを示すクリックスルー統計、ヒットページの明示的なユーザ評価などを含んでもよい。このデータはさまざまな方法で用いることができ、文脈探索の結果を向上させる。たとえば、クエリが特定の文脈探索インターフェースから来る場合、検索サーバは、検索結果とともに、ユーザが次に調査したいかもしれない関連クエリについての１つ以上の提案を含んでもよい。関連クエリは、たとえば頻繁に同じコンテキストベクトルとともに受取られ、または同じホスティングページから受取られる、他のクエリに基づいて決定することができる。

別の例として、所与のコンテキストベクトルまたは文脈探索インターフェースを用いた検索から結果として生じたヒットに関連付けられたクリックスルーデータおよび／または明示的な評価データを用いて、同じコンテキストベクトルを含む、または同じ文脈探索インターフェースに由来するクエリのその後の処理中に、検索ヒットのスコアリングまたはランク付けを改良することができる。たとえば、（コンテキストベクトルに代表されるような）特定のコンテキストを有する以前のユーザが頻繁に訪れたか、または高い評価をしたヒットページまたはサイトは、同じコンテキストを有するその後のユーザにとって比較的有用であろう。このようなヒットは、より目立つ位置を受取るように、スコアまたはランクが上方へ調整されてもよい。反対に、概して無視される、または特定のコンテキスト内でユーザから低い評価を受けているヒットは、重要性がさほどなく、スコアまたはランクが下方へ調整されてもよい。

さらに、特定の文脈探索インターフェースに由来するクエリおよび／またはクリックスルーについての集計されたデータは、好ましくは個々のユーザを特定することなく、文脈探索インターフェースに責任を負うコンテンツプロバイダと共有されてもよい。コンテンツプロバイダは、サイトを訪れるユーザの関心および挙動に対する推察を獲得するためにそのようなデータを用いることができ、それはコンテンツプロバイダがサイトの有用性および人気を向上させることを助け得る。

クエリおよび／またはクリックスルーデータもまたコンテンツ増補に用いられてもよい。たとえば、ユーザが文脈探索インターフェースを起動すると、スペシャルコンテンツは、そのインターフェースを介して実行依頼された最も頻繁なクエリまたはそのインターフェースの以前のユーザが最も頻繁に訪れたサイトのリストを含むことができる。これらのクエリまたはサイトは、ユーザがクエリのうちの１つを実行することができ、またはリンクをクリックすることによりサイトを訪れることができるように、アクティブなリンクを用いて示されてもよい。

いくつかの実施例では、検索サーバ（または別のサーバ）は、既存の文脈探索インターフェースについてのデータを集め、それぞれのコンテキストベクトルに基づいてその間の関係を規定することができる。たとえば、コンテキストベクトル用語のある一部を共有する２つのインターフェース間で「類似」関係が規定され得る。１つのインターフェースのコンテキストベクトルが別のインターフェースのコンテキストベクトルのすべての用語と少なくとも１つの付加的な用語とを含む場合、「改良（refine）」関係が規定され得る。この態様で、文脈探索インターフェースをノードとして、および関係をエッジとして備えたグラフを規定することができる。クエリ処理中にグラフ表示が用いられてもよい。たとえば、文脈探索インターフェースＡが文脈探索インターフェースＢの改良されたものであると仮定する。クエリがインターフェースＢを介して実行依頼されると、インターフェースＡのコンテキストベクトルの用語がクエリを処理するのに用いられ得る。間接的な関係
（たとえばＡがＢの改良されたものであり、ＢがＣの改良されたものである場合に、ＡがＣの改良されたものであることが推論され得る）を含む他の関係も規定され、クエリ処理に利用されてもよい。

さらに他の実施例において、文脈探索クエリはいずれの検索サーバにも実行依頼されることができ、たとえばクエリを実行依頼するためのＵＲＬが所望の検索サーバにさまざまな文脈探索を導くように文脈探索インターフェースを構成することによって、さまざまなエンティティによって制御される検索サーバにさまざまな文脈探索を実行依頼することができる。たとえば、自動車関連の文脈探索インターフェースが生成される場合、かつ自動車情報用の（検索能力を備えた）専用サーバがウェブ上で利用可能な場合、ＵＲＬにそのサーバのインターネットアドレスを含めることにより、文脈探索がそのサーバにルーティングされることができる。このように、文脈探索により、ユーザのコンテキストに特に好適な検索サーバへのアクセスがユーザに与えられ、ユーザはそのようなサーバが存在することを前もって知っておく必要はない。コンテキストに依存した態様でクエリを自動的に適切なサーバに導く能力により、さらにユーザにとって文脈探索の魅力が増し得る。

コンテキストクエリの選択的ルーティングはさまざまな方法で実現され得る。たとえば、文脈探索インターフェースがコンテンツ開発者によって生成される場合、コンテンツ開発者はウェブ上のいずれかのサーバのアドレスに導かれるクエリＵＲＬを構築することができ、ターゲットとなるサーバ用に適切にフォーマットされたクエリを用いてクエリＵＲＬを強化してもよい。そのような強化されたＵＲＬはユーザが供給する用語とともにコンテキストの用語（たとえばコンテキストベクトル）を有利に含む。

同様に、文脈探索インターフェースが自動的に生成される場合は、そのようなインターフェースを生成するソフトウェアモジュールがコンテキストベクトルに基づいてクエリＵＲＬに適切な検索サーバおよびフォーマットを選択するよう構成されてもよい。ソフトウェアモジュールが、選択された検索サーバにリクエストが送信されるようにするコードを、選択された検索サーバが処理し得るフォーマットで生成することができるならば、選択された検索サーバは、インターフェース生成ソフトウェアモジュールの作成者または実施者と何らかの組織的な関連を有している必要はないことが理解される。

検索クエリが専用検索サーバに導かれる場合、文脈探索インターフェースのアクティブ状態は上述のようなスペシャルコンテンツを含み得る。このスペシャルコンテンツは、専用検索サーバによって、または異なるエンティティによって制御され得るコンテンツ増補サーバによって与えられてもよい。スペシャルコンテンツは、検索サーバのウェブサイトへのリンクなどの、検索が導かれる検索サーバについての情報を含んでもよい。

さらに別の実現例では、文脈探索クエリをどこに導くべきかについての決定がクエリ実行時になされ得る。たとえば、すべての文脈探索クエリを検索サーバ（たとえば図２の検索サーバ１６０）に導くことができ、検索サーバはユーザクエリおよびコンテキストベクトル情報の組合せに基づいて、処理のためにクエリを異なるサーバへ転送するか否かを決定することができる。この実現例では、クエリを転送する決定は、クエリのうちユーザが供給する要素に部分的に依存し得る。たとえば、文脈探索インターフェースのためのコンテンツが新しいアルバムに関連すると仮定する。ユーザが文脈探索インターフェースを介してクエリ「批評」を入力すると、そのクエリは音楽批評のデータベースに転送されることができ、一方でユーザが同じインターフェースを介してクエリ「買う」を入力すると、そのクエリは転送されることなく検索サーバによって処理され得る。

いくつかの実施例では、異なる文脈探索クエリが同じ検索サーバに導かれ得るが、検索コーパスの異なる部分に限定され得る。たとえば、検索プロバイダはウェブページを、「
ニュース」特性、「買物」特性、「スポーツ」特性などのいくつかの潜在的に重なる「特性」に分割してもよい。そのような特性はそれぞれ別個の検索コーパスとしてを扱われ、クエリおよびコンテキストベクトルに基づき、検索はこれらの特性のうちの１つ以上に導かれ得る。複数の特性にわたって検索が実行される場合、特定の結果を返した特性も、結果をランク付けする要因として用いられ得る。

他の実施例は、コンテキストと同様にユーザに特定的なデータに検索結果を通知させるパーそナライズ機能を含む。たとえば検索プロバイダは、そのサービスの各登録ユーザについてユーザプロファイルを維持することができる。ログインされた登録ユーザが（コンテキストまたは他の）検索を実行すると、その検索についての情報が記録され、ユーザと関連付けられ得る。所与のユーザのクエリのパターンを分析することによって「ユーザベクトル」が開発され得る。文脈探索中に、コンテキストベクトルと同じくユーザベクトルからの情報も、検索の実行および／または結果のランク付けに用いられ得る。さらにユーザベクトルは、ユーザが上述のように文脈探索インターフェースを起動するとき、増補コンテンツを動的に生成するのにも用いられ得る。クエリを入力したユーザが識別可能であれば、いかなるユーザ特定情報（たとえばユーザがブックマークを付けたサイトまたはページ、サイトまたはページの明示的なユーザの評価など）もコンテキストベクトルと関連して検索結果を通知するために用いられ得る。

さらなる実施例では、ユーザは、有用であると感じた文脈探索インターフェース（または特定のコンテキストのクエリ）に容易に戻ることができるよう、これらのインターフェースについてのブックマークを生成することができてもよい。文脈探索インターフェースがコンテキストに依存した結果を返すので、そのようなインターフェースのすべてが特定のユーザにとって等しく有用だとは限らないことが認識される。ユーザが有用なものを見つけると、従来のブラウザベースのブックマークを用いて、または検索ツールバーにサポートされるブックマーク機能を用いて、それを包含するページにブックマークを付けることができる。しかしながら、ホスティングページのコンテンツが変わるとコンテキストベクトルも変わり得ることが認識される。したがって、本発明のいくつかの実施例においては、ユーザは、たとえばコンテキストベクトルを含む強化されたクエリＵＲＬを保存することによって、文脈探索自体にブックマークを付けることができる。ユーザがこのブックマークを選択するとクエリを入力するよう促され、この新しいクエリを用いて文脈探索が実行される。代替的には、ユーザはブックマークの一部としてクエリを保存することができ、そのため、しばらくの後にブックマークを選択することにより、ホスティングページの現在のコンテンツにかかわらず特定の文脈探索が再実行される。

ユーザは、たとえばさまざまな信頼ネットワーク機構を通して、ブックマークした文脈探索を他のユーザと共有することもできる。さらに他の実施例において、ユーザはブックマークされた（そうでなければ保存された）文脈探索またはインターフェースに注釈およびラベルを付けることができる。

本発明は特定の実施例に関して説明されているが、当業者は多くの修正が可能であることを認識するだろう。たとえば特定の入力装置（たとえばコンピュータマウス）が本願明細書で言及される場合、異なる入力装置（たとえばキーストロークまたはボイスコマンド）で代用することができる。同様に、本願明細書で言及されたクリック可能なボタンおよび他のグラフィカルユーザインターフェース制御要素は、任意の適切な代替的制御要素と置換されてもよい。

アクティブかつ／または非アクティブな状態の文脈探索インターフェースの外観も、本願明細書に示されたものと異なってもよい。たとえばアクティブなインターフェースは、図３に示されるようにホスティングページにも、または個別のポップアップウィンドウに
も現われ得る。さらに、アイコンおよび／またはアクティブインターフェース要素の外観は可変である。そのような変形は、文脈探索実施者またはコンテンツプロバイダによって制御され得る。単に一例であるが、非アクティブのアイコンの外観はコンテキストを示唆するために変動してもよいので、エンターテインメント関連の検索用アイコンにはフィルムリールが含まれ、フットボールまたは野球がスポーツ関連の検索用アイコンに含まれる、などでもよい。一貫したテキスト文字列（たとえば図６に示される「Search This（これを検索）」）または他の要素は、アイコンが文脈探索インターフェースを代表することのさらなる表示としてアイコンに含まれてもよい。

別の変形例では、文脈探索アイコンの非アクティブ状態は、隠れたモードまたは可視モードで実現され得る。たとえば文脈探索アイコンは、ユーザのマウスカーソルが関連コンテンツの上に位置決めされたり移動されたりする場合を除き、隠れる（すなわちホスティングページに表示されない）ことができる。マウスカーソルがそのように位置決めされると、アイコンは目に見えるようになり、ユーザはそれをクリックして起動することができる。隠れたモードおよび可視モードは、たとえば、Ｊａｖａ（登録商標）などの言語を用いて実現されてもよい。

本願明細書に説明された実施例は、ウェブサイトページ、リンク、および、ワールドワイドウェブ（またはそのサブセット）が検索コーパスとして機能する場合に特有の他の用語を参照し得る。本願明細書に説明されたシステムおよびプロセスは異なる検索コーパス（電子データベースまたは文書リポジトリなど）を伴う使用に適合されてもよく、結果はコンテンツとコンテンツが見つかるかもしれない場所へのリンクまたは参照とを含み得ることが理解されるべきである。

さらに、本発明は特定のハードウェアおよびソフトウェア要素を有するコンピュータシステムに関して説明された。ハードウェアおよび／またはソフトウェアコンポーネントの異なる組合せを備える他のシステムも実現され得ることが理解されるべきである。

このように本発明は特定の実施例に関して説明されたが、本発明が添付の請求項の範囲内で修正例および等価物をすべて包含するよう意図されることが認識される。

本発明の実施例によるクライアントシステムを含む通信ネットワークおよび情報検索のハイレベルなブロック図である。 本発明の実施例による、別の情報検索および通信ネットワークのブロック図である。 本発明の実施例による文脈探索インターフェースを有するウェブページの図である。 本発明の実施例による文脈探索のためのコンテキストベクトルの図である。 本発明の実施例による非アクティブ状態の文脈探索インターフェースを有するウェブページの図である。 本発明の実施例による複数の文脈探索インターフェースを有するウェブページの図である。 本発明の実施例による文脈探索インターフェースを生成するための、コンテンツ開発者によって実行されるプロセスのフロー図である。 本発明の実施例によるコンテキストベクトルを生成するプロセスのフロー図である。 本発明の実施例による文脈探索インターフェースをユーザが生成するためのプロセスのフロー図である。 本発明の実施例による文脈探索を実行するプロセスのフロー図である。 本発明の実施例による文脈探索を実行する別のプロセスのフロー図である。 本発明の実施例による、コンテンツを含む文脈探索インターフェースを有するウェブページの図である。 本発明の実施例による増補コンテンツを選択するプロセスのフロー図である。

Claims (39)

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. クエリユニットは、ユーザクエリおよびコンテキストベクトルの一方または両方を用いて検索コーパスを検索するようさらに構成される、請求項３７に記載のシステム
39. ランク付けユニットは、ユーザクエリおよびコンテキストベクトルの一方または両方に少なくとも部分的に基づいてランク付けを計算するようさらに構成される、請求項３７に記載のシステム。

Images