JP5068996B2 - サブドメインヒントによる検索及びサブドメイン単位のスポンサー付き結果提供を組み込んだ検索結果生成のシステム - Google Patents

Description

本発明は、概括的には、コンテンツ検索に関し、より厳密には、検索要求に応じてコンテンツを検索するための方法及び装置に関する。

本出願は、２００３年４月４日出願の米国仮特許出願第６０／４６０，６５８号「検索サブドメイン、検索照会ステートメント内のサブドメインに対するのヒント、並びにサブドメイン単位のスポンサー付き結果、を使用した検索システム」の優先権の恩典をＵＳＣ１１９条に基づいて主張し、同出願の開示内容全体を参考文献としてここに援用する。

コンテンツ検索システムでは、ユーザーは、コンテンツを要求し、その要求に合致するコンテンツを受け取る。ユーザーは、要求を処理し及び／又は他のコンピュータシステムへの要求を転送するコンピュータのユーザーインターフェースと対話する人間のユーザーでもよい。また、ユーザーは、要求をプログラムで生成する別のコンピュータプロセス又はシステムであってもよい。後者の場合、その要求を出しているコンピュータのユーザーが要求の結果もプログラム処理すると考えがちであるが、そうではなく、コンピュータのユーザーが要求を出し、人間のユーザーがその応答の最終的な受信者となる場合もあるし、逆に、人間のユーザーが要求を出しコンピュータのユーザーがその応答の最終的な受信者となる場合も考えられる。

コンテンツ検索システムは広く使用されている。今日普及している一般的なシステムの１つに、インターネットと呼ばれる世界規模の相互接続ネットワークがあるが、インターネットでは、ネットワークのノードがコンテンツで応答する他のノードに要求を出す仕組みになっている。コンテンツの要求に利用できるプロトコルの１つにHyperText Transport Protocol （ＨＴＴＰ）があり、このプロトコルでは、ＨＴＴＰクライアント（ブラウザなど）が、Uniform Resource Locator（ＵＲＬ）により参照されるコンテンツに対する要求を出し、ＨＴＴＰサーバーが、ＵＲＬにより指定されたコンテンツを送ることによりこの要求に応答する仕組みになっている。無論、これは非常に一般的な例であって、コンテンツ検索はこの方式に限定されているわけではない。

例えば、トークンリング、ＷＡＰ、オーバレイ、ポイントツーポイント、所有権のあるネットワークなど、インターネット以外のネットワークも使用できる。ＳＭＴＰ、ＦＴＰのような、ＨＴＴＰ以外のプロトコルを使用してコンテンツの要求と移送を行い、コンテンツをＵＲＬ以外のもので指定することもできる。本発明は一部、各種アプリケーションに対応して現在普及している世界規模の相互接続ネットワークであるインターネットに関連した記述を含むが、インターネットへの言及は、インターネットの基本コンセプトを様々に変更した形態（例えば、イントラネット、仮想的専用ネットワーク、閉鎖ＴＣＰ／ＩＰネットワークなど）並びに他のネットワーク形態に置き換えることができるものと理解されたい。また、本発明は１つのコンピュータ又は複数のコンピュータの１つの集合体の中で完全に作動させることもでき、従ってその場合にはネットワークの必要性がなくなるという点も理解されたい。

コンテンツ自体は多様な形態であってもよい。コンテンツには、例えば、テキスト、画像、ビデオ、音声、動画、プログラムコード、データ構造、フォーマットされたテキストなどがある。例えば、ユーザーは、ニュース記事（テキスト）及び付随する画像を有するページであるコンテンツを、他のコンテンツへのリンク付きで要求してもよい（その場合、HyperText Markup Language（ＨＴＭＬ）に従ってコンテンツをフォーマットすることによるなどの方法を用いる）。

ＨＴＭＬはＨＴＴＰサーバーから供給されるページ又は他のコンテンツに使用される一般的なフォーマットである。ＨＴＭＬでフォーマットされたコンテンツは、他のＨＴＭＬコンテンツへのリンクを含んでおり、他のコンテンツを参照するコンテンツの集合体は、ドキュメントウェブとして捉えることができ、それ故ＨＴＭＬでフォーマットされたコンテンツの集合体の一例に、「ワールドワイドウェブ」即ち「ＷＷＷ」の名前が与えられている。これは周知の構成体であることから、本願では数多くの例で使用しているが、特に限定しない限り、これらの例で説明するコンセプトは、ＷＷＷ、ＷＴＭＬ、ＨＴＴＰ、インターネットなどに限定されない旨理解されたい。

コンテンツが、独自に識別されたコンテンツオブジェクトへの要求に応じてアクセスされる事例もある。例えば、Yahoo!ホームページのYahoo!スポーツ属性のコンテンツを入手しようとしているユーザーは、ウェブブラウザクライアントを起動して、そのような目的のためにウェブブラウザが提供しているダイアログボックスのURL sports.yahoo.com に入ればよい。この要求に応答して、ウェブブラウザクライアントは、特定のサーバーに対し指定されたページに対する要求を出すようにプログラムされており、サーバーは要求されたページを提示することで応答するが、これらは全て、HTTP及びHTTPSのような要求／応答プロトコルに馴染の人には周知である。

また、ユーザーは、特定のＵＲＬを念頭に置いているわけではなく、コンテンツを求めるもっと漠然とした要求を検索照会の形式で出す場合もある。典型的な検索照会では、ユーザーにはダイアログボックスが提示され、そこにユーザーは検索照会用の用語を入力し、それらの用語に基づく要求を開始する。検索の一例として、Yahoo!検索がある。Yahoo!検索を実行する１つの方法は、ウェブブラウザクライアントをURL www.yahoo.com のページに導き、当該ページに提示された検索ダイアログボックスに検索照会を入力することによる方法である。ウェブブラウザクライアントが www.yahoo.com サーバー（又は当該ページのＨＴＭＬ入っている参照又は他のコードで指示された他のサーバー）に送信するという照会に応えて、受信側のサーバーでは、検索を実行し又は検索が実行されるようにして、検索結果をウェブブラウザクライアントに、通常はページの形態で、戻す。

現在使用されている検索と応答の或る変形例では、ユーザーが１つ又は複数の文字のストリングを、通常は１つ又はそれ以上の単語又はコンセプト（トークン）をスペースやコンマなどの区切り記号で区切った形式で入力すると、検索結果として、幾つかの検索ヒットを含む、それらヒットが見つかった相手先により編成されたページ、が提示される。例えば、検索結果ページは、"Inside Yahoo!"に一致というヒット、Yahoo!ディレクトリに一致というヒット、スポンサー付に一致というヒット、Ｗｅｂ検索に一致というヒットなどを一覧表にして提示する。なお、「一致」とは、それぞれの検索コンテンツにより意味が異なっていてもよいものと理解されたい。例えば、一致は完全整合であるとする検索コンテンツもあれば、単数形とこれに相当する複数形も一致とみなすなど、一致は近似であるとする検索コンテンツもある。

検索によっては、全ての利用可能なドキュメントを対象に行われるものもあれば、検索対象として利用可能なドキュメントの１つ又はそれ以上のサブドメインに対して行われるものもある。例えば、公開Yahoo!属性は全て検索に利用可能であるが、Yahoo!Travel属性又はYahoo!Sports属性に限定して検索を行うこともできる。照会を生成しているユーザーは、どのサブドメインを検索すべきか知っている場合が多く、従って検索を限定することができる。しかしながら、その場合には、通常、特定のサブドメインに関係付けられたページまでナビゲートして、そこで検索用語を入力するなど余計な段階を要する。

サブドメイン検索に対する１つの解は、ブラウザ又は他のソフトウェアに検索ダイアログボックスを設けて、その中で検索用語に基づいて、サブドメインに関係付けられた各種ページでどのように検索を行うかを示しているＸＭＬファイルにマップして検索を処理することである。例えば、"dic"から始まる検索ストリングは、"dic"コマンドに関係付けられたページ上に提供される検索ダイアログボックスへの残りの引数のユーザー入力を、クライアントがどのようにシミュレートするかについてのインストラクションを含んでいるＸＭＬファイル dic.xml により処理されることになる。この処理は、構造に変化がないページに関しては良好に働くが、利用されるページは通常はクライアントの制御下にはなく、ＸＭＬファイルはクライアントに対して局所的に記憶されている。このため、例えば、dic.xml ファイルが導かれるディクショナリ・ウェブサイトの保守管理者がページの構造を変更すると、検索が正しく作動しなくなり、クライアントは変更されたページにアクセスするため及び検索のユーザー入力をシミュレートするためにＸＭＬインストラクションを書き換え又は更新する必要が生じる。

必要とされているのは、サブドメイン及び他の技法を使った、改良された検索である。

米国仮特許出願第６０／４６０，６５８号

本発明の実施形態による検索システムは、検索照会をサブドメインに経路決めするべきか否かを判定するために検索照会を分析し、その結果を、サブドメイン単位でサンドメイン上に委託されているスポンサー付きヒットを含めて提示する。

本発明の他の特性及び利点は、以下の詳細な説明及び好適な実施形態を見て頂ければ明らかとなるであろう。

これより、本発明の実施形態について説明していくが、これは一例であって本発明に限定を加えるものではない。なお、本発明は、用途が広く且つ多種多様な状況で使用できるものと理解されたい。

以下に説明する検索処理の例は、検索システムに照会を提示し、見つけられた１つ又はそれ以上の「ヒット」を示す応答（検索結果）を受信する検索者によってモデル化することができる。照会は、区切り記号又は構文解析規則で区切られた１つ又はそれ以上のトークンを含む検索照会ストリングの形式をとる。検索照会ストリングの各種バリエーションに基づいて検索を変更することの他に、コンテキストも考慮に入れられる。例えば、照会側が、前もって検索に対して、年齢に相応しいヒットのみを返すこと、のような制約を設定している場合もあり、事前の検索が考慮されることもあり、照会側のＩＤ（検索照会ストリングを提出しているＷｅｂブラウザクライアントに現在対応付けられているYahoo!ＩＤなど）及び設定がユーザーによって設定される場合もある。

検索システムは、照会を受け取ると、検索を処理して１つ又はそれ以上の「ヒット」を戻すが、ここで「ヒット」とは検索システムが操作する原子単位である。例えば、検索システムが構造化データベースを管理している場合、ヒットは構造化方データベースからの記録である。検索システムが、テキストドキュメント、画像及びテキストドキュメント、画像ドキュメント、ＨＴＭＬドキュメント、ＰＤＦドキュメントのようなドキュメントを管理している場合、原子単位はドキュメントである。なお、本発明は特定の原子単位に限定されるものではなく、一例として、本開示の多くの部分で、ドキュメントを原子単位として使用している検索処理について説明しているものと理解されたい。また、構造化データベースは必要条件ではない。

ヒットは、検索システムが、照会により定義された一致基準として識別する原子単位である。なお、検索システムは、全てのヒットを提供する必要も、照会に一致するヒットだけを提供する必要もないと理解されたい。例えば、検索システムは、戻されるヒットの個数を或る数までに制限してもよいし、照会に一致するヒットを省略する、重複するヒットを無視するなどというように、照会用語に他の制限を加えてもよい。検索システムは、検索結果に、照会にほぼ一致するヒット、特殊な話題のヒット、広告ヒットなどのような検索者側に組み入れられるように規定されているヒット、が含まれるように、検索結果を拡大してもよい。或る程度の拡大又は縮小は、このような拡大又は縮小に先立つ検索結果の大きさ又はコンテンツによって決まる。例えば、検索エンジンは、それ以外にヒットを戻すことができない場合には、一致に近いヒットを付け加え、戻すべきヒットが多くなり過ぎる場合には、例えば検索結果を完了する前に照会から共通の単語を消去してヒットを削除してもよい。

検索者は、Ｗｅｂを介して検索エンジンに照会を行うためにブラウザウインドウに検索用語を打ち込んでいる人のような、人間のユーザーであってもよいが、検索エンジンが期待する形式で検索エンジンに対して照会を送ることのできるコンピュータプログラムのような自動化されたプロセスであってもよい。例えば、コンピュータプログラムが、照会を生成し、検索エンジンに連結されたＷｅｂサーバーに向けてＨＴＴＰメッセージを作成してもよい。

ここに示した例の多くでは、検索エンジンは、一組のドキュメントの中で、照会によって定義された基準に一致するドキュメント（ヒット）を検索する。なお「ドキュメント」という用語は、検索対象のコーパスの単位を指すのに一般的に使用されているものと理解されたい。ドキュメントは、契約書、ファイル、記事、書き物などのような文書であってもよいが、テキストの断片、他の意味合いではドキュメントの一部と考えられるデータ、プログラムコード、画像データ、記憶されたファイルなどであってもよい。従って、当該用語を狭義に解釈する必要はない。

検索時、検索エンジンは、索引に載せた全ての利用可能なドキュメントから引き出すこともできるが、検索を１つ又はそれ以上のサブドメインの中のドキュメントに絞ることもでき、この場合、サブドメインは、検索エンジンに利用可能な全てのドキュメントの事前に規定された正しいサブセットである。場合によっては、サブドメインは更に小さいサブドメインに副分割することもできる。

サブドメインの例として、Yahoo!属性がある。Yahoo!属性の例を挙げると、Yahoo!News、Yahoo!Sports、Yahoo!Mail、Yahoo!Shopping、Yahoo!Auction、Yahoo!Weatherなどがある。照会を出しているユーザーには或る場合には或る特定のドメイン外の情報は役に立たないであろうことが分かっている場合が多いので、サブドメインは有用な検索ツールである。例えば、ユーザーがニューヨークの天気情報を入手することに興味があるとする。大域検索では、ニューヨークの天気とその天気が幾つかのスポーツイベントに及ぼす影響にたまたま言及している多くのスポーツ記事を取り上げることになるが、ユーザーはYahoo!Weather属性以外のヒットはどれも役に立たないであろうと既に判断しているかもしれない。別の例として、ユーザーは、結果的に、記憶されたｅメール内では数件のヒットしか無いが、全Yahoo!属性又はＷｅｂページを対象に検索が行われる場合には何千件ものヒットになるであろうキーワードを使って、自分の記憶済みのYahoo!ｅメールを検索することを望むかもしれない。サブドメインを使用することの利点は、ユーザーが、ダイアログボックスのような汎用の検索入力オブジェクトに検索を入力して、検索サーバーに検索照会ストリングを分析させてユーザーの意図したサブドメインを判定してもらうことができることである。サブドメインを使用することの別の利点は、例えば、ユーザーに対して無料で提供される検索サービスを支援するスポンサー付リンク又は目標を絞った広告を、スポンサー及び広告主に、サブドメイン単位で割り振ることができる点である。

これより図面を参照しながら、代表的な検索システムを説明する。

図１は、本発明の実施形態による検索システム１００のブロック図である。検索システム１００を使う場合、照会側は、Ｗｅｂブラウザクライアントのような検索クライアントを使用して、検索要求を検索サーバーに発行する。図１に示すように、人間のユーザー１０３又はコンピュータプロセス１０５は、検索クライアント１１０を使って照会を発行する。検索照会は、通常は検索照会ストリングの形態をしており、検索サーバー１２０に送られ、検索サーバーは、検索照会に応えて結果を検索クライアント１１０に戻す。他のバリエーションでは、検索照会が或るシステムから出され、結果は別のシステムに経路決めされる。

検索サーバー１２０は、幾つかのサブドメインサーバー１３０に接続されており、それらのサーバーは更に対応するサブドメインコーパス１３２に接続されている。なお、記憶効率又は他の理由により、サブドメインコーパスのコンテンツ又は情報は、或る程度のコンテンツ又は情報が２つ以上のサブドメインコーパスに存在するようにオーバーラップしているものと理解されたい。この開示全体を通して、複数のオブジェクトのインスタンスが存在し、インスタンスの数は重要ではなく、インスタンスには「１」から「Ｎ」までの番号が付されるが、Ｎの値は特に明示されない限り使用毎に同一である必要はないと理解されたい。例えば、Ｎはサブドメインの個数として使用されるが、その数は事例毎に変わる。また、インスタンス全てを使用するという必要もないものと理解されたい。

各種システム間の相互接続は、相互接続の方法が周知の技法を使って実現できるため、詳しく説明する必要はない。例えば、検索クライアント１１０は、ＷｅｂブラウザクライアントのようなＨＴＴＰクライアントを実行し、世界規模のインターネットのようなネットワーク上で相互接続されている検索サーバー１２０で実行されているＨＴＴＰサーバーと通信するパーソナルコンピュータであってもよい。なお、他の実施形態も本発明の範囲に含まれるものと理解されたい。例えば、検索クライアント１１０は、ハンドヘルド装置、人間ユーザー用インターフェースを備えていないコンピュータ、専用装置、キオスクなどとして実施してよい。また、クライアントとサーバーは、ＨＴＴＰを使用する必要はなく、ページとオブジェクトの要求を出すため及びそれらの要求に応答するための異なるプロトコルを使用してもよい。

作動時、詳しくは後で説明するが、検索クライアント１１０は検索照会ストリングを検索サーバー１２０に送り、このストリングにはおそらく要求を送っているYahoo!ユーザーのYahoo!ＩＤのようなコンテキストデータも含まれている。当該コンテキストを用いて、検索サーバー１２０は、識別されたユーザーのユーザー・デモグラフィックを調べ、それを使って検索を通知する。検索サーバー１２０は、検索照会ストリングを構文解析し分析して、サブドメイン検索が適当か否かを判定し、次いで当該照会を適当なサブドメインに送るか、又は大まかな検索を実行する。図示のように、検索結果は、検索サーバー１２０によって戻すこともできるが、サブドメインサーバーによって直接戻してもよい。

図２は、検索サーバーの要素を詳細に説明している。本図に示すように、検索サーバーは、ページコンストラクタ２００、及び、検索結果２１０用の記憶装置、一致する広告、一致するインサート２１４、スポンサー付リンク２１６、並びに照会ログ２２０を含んでいる。受け取った照会から、検索サーバーは、検索自体を実行すること又は別の検索エンジンからの結果を要求することの何れかにより、検索結果２１０を入手する。通常、キーワードインデクスのような検索対象のコーパスに対するインデクスを使用して検索が行われる。その場合、検索結果２１０はインデクスに基づいて生成されるヒットである。ページコンストラクタ２００は、ここで、記憶装置２１０−２１６内の要素からページを生成し、当該ページを検索照会に対する応答として送信する。

ページコンストラクタ２００によって作成されたページ３００の一例を図３に示している。本例では、検索ストリングは「カメラ」である。ページ３００には、別々のページレイアウト領域３０２、３０４、３０６、３０８、３１０、３１２及び３１４に分けて編成された情報が含まれている。

ページ３００の一番上には、検索の表示、別の検索を開始することができるダイアログボックス、及びヘルプ、ホームページなど用のクリック可能なリンクがある。「カメラ」に対するＷｅｂインデクスによる検索結果のような単純な検索結果が、レイアウト領域３０８に一覧表示されている。この例では、照会ストリング「カメラ」を使った検索照会があると、検索サーバーは、記憶装置２１０にＷｅｂ検索結果並びにおそらくは他の結果も入れ、記憶装置２１２には検索ストリングに関係付けられた広告を入れ、記憶装置２１４には検索ストリングに関係付けられたインサートを入れ、記憶装置２１６には検索ストリングに関係付けられたスポンサー付リンクを入れる。

広告は、何のビューが販売されたかに基づいて選択してもよい。而して、広告主は、検索照会が「カメラ」という単語を含んでいる場合は、特定の広告を検索結果ページに掲載してもらうためにお金を払う。スポンサー付リンクも同じように配置することができ、リンクの順序及び／又は順位は、誰がプレゼンテーションに支払うか及びどんな検索条件について支払うかということによって決まる。

レイアウト領域３０８は、検索用語に応じたヒットを表すリンクを含んでおり、誰がリンクに出資しているかとは別であるのが望ましい。レイアウト領域３１０は、一致する広告、又は場合によっては一般的な広告を挿入するために設けられている。レイアウト領域３１２と２１４は、追加的な一致するインサートを提供しており、それらは使用される検索用語に特定のものであるが、大抵は検索結果でも、スポンサー付きの一致や広告でもない。本例では、レイアウト領域３１２には、代わりの検索を実行するためのリンクが含まれており、レイアウト領域３１４には、代わりに実行することのできるサブドメイン特定検索のためのリンクが含まれている。

しかしながら、好適な実施形態では、サブドメイン検索は検索照会ダイアログボックスから第１インスタンスでそのまま実行することができる。例えば、ユーザーが自分はカメラのオークションを探していることが分かっている場合、ユーザーは、その旨を直接表示し、「カメラ」と打ち込むのではなくレイアウト領域３１４で「Yahoo!！オークション」を選択することができる。これによりユーザーの時間と労力が節約でき、また、より的を絞ったインサート、広告、及びスポンサー付リンクが可能になる。例えば、ユーザーが検索ストリング「オークション カメラ」と指定すると、検索サーバーは、第１トークン「オークション」を検索ストリング固有の部分であるとは解釈せず、サブドメインヒントと解釈する。この場合、検索サーバーは検索ストリング「カメラ」をYahoo!！オークションに特定したサブドメインサーバーに方向付ける。

検索結果ページは、結果として、更に絞り込まれることになる。一致するインサートは、検索用語に対するイエローページ検索用のリンクは含んでおらず、スポンサー付リンク及び広告が選択対象となる。従って、或るスポンサーは、一般的な検索下又はイエローページサブドメイン内の検索下ではなくて、オークションサブドメイン下での用語「カメラ」に対するスポンサー付リンクの設置を購入することを選ぶことになる。こうして、広告及びスポンサー付リンクは更に絞り込まれることになる。これは、例えば、広告主がオークションでカメラを売買するために検索しているユーザーに到達したいと望んでいる場合には有用であるが、ユーザーがカメラ店の場所を探している場合にはそうではない。

レイアウト領域３０２は、一致しているインサート２１４を表示している。本例では、それら一致しているインサートは、検索用語に関係する「インサイド Yahoo!！」リンクである。レイアウト領域３０４は、ディレクトリ一致を表示しており、これらは、トピックスとそれらトピックスに関係付けられたリンクを階層内のそれぞれのレベルに配置した階層配置であるYahoo!！ディレクトリを網羅しているサブドメインからの一致である。レイアウト領域３０６は、スポンサー付一致を表示しており、これらは特定の用語のスポンサーシップに基づいてユーザーに提供されるヒットである。

ある種のブラウザ又は他の入力装置構成では、ユーザーには、検索入力用、環境設定（preference）の設定用、独自化ヒント群（例えば、アペンディックスＡに示す一覧のサブセットとなりうるリスト）の選択／編集用、及び検索なしにある種のサービス、例えばメインメールボックスページなどに直接ジャンプするためのツールバーが提供されている。別の例として、「地図 サニーベール ９４０８９」を検索照会する場合には、検索は不要であり、地図属性、サイト又はシステムを、カリフォルニア州サニーベールの地図を求める曖昧でない要求と共に転送するだけでよい。

ユーザーは、「カメラ」のような単純な検索照会を入力してもよいが、サブドメインに適用されるかもしれない検索を含む、もっと複雑な照会を入力することもできる。例えば、図４に示すダイアログボックスに入力された検索「天気９４０８９」はサブドメインに適用される。一般的な検索が、例えば全てのＷｅｂページ上で実行されると、検索は、役に立つヒットを上回る数の、概ね見当違いの多くのヒットを、提示することになる。しかしながら、入力されたシーケンスが構文解析可能なサブドメイン検索として扱われると、検索サーバーは、「天気」を天気検索システムのサブドメインに対するヒントとして識別することによって照会を処理し、要求を天気検索エンジンに送ることになる。

実施例の中には、ヒントが、サブドメインに関係付けられた単なる単語ではないものもある。例えば、或る検索サーバーは、ヒントが提示されたときに判断を助ける一組のビジネス規則を保持している。例えば、規則は、検索ストリングが５桁の数字で始まるか終わるかしたときには、それがサブドメインヒントを有していると解釈し、サブドメインヒントは、検索をジップコードに基づいて限定する。従って、「天気９４０８９」の検索には２つのヒントが含まれ、即ち、「天気」は、検索がYahoo!！天気サイトのような天気サブドメイン上で実行されるべきであること、検索はジップコード「９４０８９」に対応する区域に限定されるべきこと、を示している。

ヒントには数多くのバリエーションを持たせることができる。例えば、「９４０８９ピザ」であれば、これが５桁ヒントから始まっているのでイエローページサブドメイン上の検索であり、表示されたジップコード内のピザ宅配店を求める検索であると解釈される。実施例の中には、検索サーバーがユーザーの独自化を保持しているものもある。独自化を用いれば、使用されるヒントはユーザーに特定のものとなる。従って、或るユーザーはヒントストリング"res"がレジュメ検索と解釈されるように独自化を設定し、別のユーザーはヒントストリング"res"がレストラン検索と解釈されるように独自化を設定しているかもしれない。それら独自化をクライアントではなくて検索サーバーに記憶させておくと、各ユーザーは、異なる記憶位置で独自化された検索を実行することができる。

場合によっては、サブドメイン上でのヒント「検索」が１つのヒットしか出ない程度にまで独自化を徹底することもでき、その場合、検索ダイアログボックスは事実上ブックマーク検索として使用されることになる。そうすると、図５に示すように、ユーザーは、自分のヒントを、検索照会ストリング"favteam"が結果としてユーザーのお気に入りのスポーツチームのホームページという１つのヒットしか戻されないように、独自化することができる。戻されるページが典型的に、事前に特定された特定ＵＲＬであることから、厳密にはこれは検索ではないが、同じインターフェースを検索処理として使用し、ユーザーに対するダイアログボックスの認知性をより完全なものとすることができる。サーバー端末では、ページ生成処理の幾つかの段階は、ブックマーク又は「ナビゲーショナル」検索の場合も同じである。例えば、インサート、広告などの一致は、複数ヒットのインデクスを検索するサブドメイン検索を用いながら進められる。

図６は、検索サーバーで使用される幾つかの要素を示すブロック図である。図示のように、記憶装置は、検索結果及びサブドメイン特定のインサート／広告用として、並びに一般的なインサート／広告用として、提供されている。検索サーバーが検索を独自化している場合、「天気があまり暑くない場所」を検索すると、ヒット、インサート、及び広告の結果ページが提示されることになるが、このインサート及び広告は、実際に検索を行っているサブドメインサーバーによって判定及び／又は特定されたものである。当該検索又は当該サブドメインに特定されない一般的なインサート及び広告も提供することができる。検索がナビゲーショナル検索である場合には、一般的なインサート及び広告は、他のコンテキストが、ユーザーがナビゲーショナル検索用のブックマークとして使用しているラベル又はブックマークラベルに関係付けられているＵＲＬによって判断されない限り、使用されないようにしてもよい。

図７は、構文解析処理に使用することができる記憶装置を示すブロック図であり、ユーザー環境設定用の記憶装置７００、ビジネス規則用の記憶装置７０２及びブックマークヒント用の記憶装置７０４を含んでいる。記憶装置７００は、ユーザーの指定した設定及び／又は環境設定の全て又はサブセットを含んでいる。例えば、ユーザーの設定がユーザーのYahoo!環境設定である場合、そこにはユーザーの年齢、場所、性別、興味などが含まれることになる。ビジネス規則には、「天気」、「ニュース」、「ディレクトリ参照」などのような、単語からサブドメインへのマッピングが含まれる。ビジネス規則は、全ユーザーに同じでもよいし、ユーザーによってはカストマイズされた規則を持つようにしてもよい。ユーザー毎にカストマイズされたブックマークを持つようにしてもよいが、一般的なブックマーク群があってもよい。

パーサ７１０は、検索紹介ストリングとユーザーが照会を出しているという表示とを受け取ると、記憶装置７００、７０２、７０４のコンテンツを使って、ストリング内のどのトークンがヒントであるかを判定し、適切なサブドメインサーバーに対して適切な検索要求を出す。返される検索結果を受け取るページコンストラクタは、記憶装置７００、７０２、７０４を使用して、検索結果ページに含まれるインサート及び／又は広告を決める。ページコンストラクタはその情報を使用することができる（検索サーバーには容易にアクセス可能）ので、インサート及び広告をサブドメイン特定とすることができる。例えば、検索サーバーのオペレータは、特定のキーワードに対する広告を、サブドメイン毎に販売することができる。従って、或るピザ店は、一組のジップコードに対する全ての広告を、それが検索用語「ピザ」と共に現れるときに購入することができ、全く別の場所に在るピザ店は、やはり「ピザ」に対する全ての広告を、異なる一組のジップコードに対して購入することができる。これにより、広告、特に場所に従属して提供される種類の広告は、より的を絞ったものになる。

ビジネス規則７０２は、照会ログ７０６のコンテンツに基づいて判定される。パーサ７１０の動作はヒューリスティック７０８の影響を受けるが、このヒューリスティックは、過去の行為に基づいて照会に適用することのできる各種規則を照会ログ７０６から判定するヒューリスティックジェネレータ７２０から出たものである。

図８は、検索サーバーが、ユーザーから受け取った検索照会ストリングに応じて構文解析を実行し、検索を行うプロセスの一例を示すフローチャートである。本例では、サブドメイン検索などで、少なくとも１つのヒントを有するものとして処理されることになる検索に、”！”のようなヒント演算子が先行している。実施例の中には、ヒント演算子が必要ないものもあるが、他の例では、ヒント演算子は、曖昧さを減らし、そうでなければヒントと見なされるものを使って通常の検索が行えるようにする。図示のように、この場合、ヒント演算子が存在しなければ、一般的なＷｅｂ検索のような、検索照会ストリングを入力として使用する一般検索プロセスが呼び出される。中には、最初のステップが、検索照会ストリングを構文解析して、その中のどの部分がヒントを含んでいるのかを判定する段階である場合もある。また、ヒントが暗示的と見なされ、検索サーバーが、いつ暗示的なヒントを付け加えるべきかを判定する場合もある。

ヒント演算子が存在する場合、又は暗示されている場合には、検索照会ストリングが構文解析される。様々なビジネス規則を適用することができるが、ここではその一例を挙げる。第１トークンが５桁であれば、それはまずジップコードと解釈され、有効なジップコードのリストで調べられる。認識できるトークンがない場合は、通常の検索が実施されるが、恐らくその際に、ユーザーには、ヒント演算子を使用したが認識されるヒントが無かった旨のメッセージが与えられることになる。

ヒントが認識された場合、ヒントと見なすべきではない用語のブラックリストと対比される。例えば、検索ストリング「!９４０８９冒険」は、９４０８９のジップコードヒントと残りの検索ストリング「冒険」から成るヒント演算子と解釈される。「９４０８９冒険」が人気映画の題名である場合には、この検索照会は常に誤訳されることになる。そのような事態を回避するために、ストリング「９４０８９冒険」をブラックリストに載せ、当該ストリングをヒントの無いストリングと解釈させるようにする。

ヒント演算子が存在し、ヒントが検出され、当該ヒントがブラックリストに載っていなかったとすると、検索サーバーによりヒントトークンと見なされる。当該ヒントがディクショナリサブドメイン検索用である場合、残りの検索ストリングは、ディクショナリサブドメイン検索サーバーに引き渡される。これは、ユーザーのクライアントを適切なサーバーに転送することにより行われる。同様に、ヒントが天気、ニュース、地図などのサブドメイン検索用の場合、要求は適切なサブドメインに送られる。

地図、イエローページなどのサブドメイン検索の場合には、アドレスを求めるために追加的なヒントが使用される。例えば、検索照会ストリング「!yp９４０８９パーク」は、「yp」（イエローページ）ヒントと、検索を限定するのに使用される「９４０８９」という追加的ヒントと、残りのストリング「パーク」とから成るヒント演算子と解釈される。而して、上記検索照会ストリングは、パークに対するイエローページサブドメインの検索を、ジップコード９４０８９のものに限定して行うことになる。ジップコード（又は郵便番号又は他のインジケータ）が有効でない場合、又はアドレスが解明できない場合、応答は一般検索及びエラーメッセージとなる。場所を一切識別しないイエローページ検索のような例では、応答はエラーメッセージだけになる。

ある種のブラウザ又は他の入力装置構成では、ユーザーには、検索入力用、環境設定の設定用、独自化ヒント群（例えば、アペンディックスＡに示す一覧のサブセットとなりうるリスト）の選択／編集用、及び検索無しにある種のサービス、例えばメールボックスページを求める要求であると見なされた検索照会ストリングの場合にはメインメールボックスページなど、に直接ジャンプするためのツールバーが提供されている。別の例として、「地図サニーベール９４０８９」を検索照会する場合、検索は不要であり、地図属性、サイト又はシステムを、カリフォルニア州サニーベールの地図を求める曖昧でない要求と共に、転送するだけでよい。

ヒントキーワードとして使用できるサブドメインキーワードの例を、アペンディックスＡに示している。これらサブドメインキーワードは、検索を特定のサブドメインに限定するのに使用することができ、それらサブドメイン内の検索に影響を与えるためにも使用される。サブドメインによっては、検索システムが検索照会を検索以外のインストラクションとして書き直すこともある。例えば、検索システムは「母からのメール」を、識別されたユーザーのメールデータベースのメールサブドメインに対する検索と解釈して、「送信者＝母」からのメールを検索するかもしれないし、一方で、検索システムは「！メール」又は単に「メール」を、ユーザーのメールインターフェースを或るデフォルト条件で開く、例えばメールボックス内のユーザーのページなどを開く要求として解釈することもある。

或るバリエーションでは、ユーザーは、検索システムが当該ユーザーについてヒントをどう解釈するかを独自化することができる。これを行うための１つの方法は、ユーザー毎に、又は好みが同じユーザー群毎に、カストマイズされたショートカットのセット、又はユーザーが選択することのできるカストマイズされたショートカットのセットを提供することである。例えば、「音楽狂」用にカスタマイズされたショートカットのセットと、「石油採掘業者」用にカストマイズされたショートカットのセットが作成されると、バンドのドラマーが「音楽狂」ショートカットを使用したいと（又は、そこから独自化するためのベースとして）選択すると、「ドラムストア」の検索によってスネアドラムなどを購入する場所の検索結果に導かれる、一方で、石油業界のトラック運転手は「石油採掘業者」用にカストマイズされたショートカットを選択することになり、「ドラムストア」の検索は、この場合にはドラム缶の供給メーカーに導く。

更に他の検索システムのバリエーションでは、検索システムは、ユーザーの履歴及び／又はプロフィールに基づく追加的な検索又は情報を提案する。例えば、ドラマーには、ドラムについての雑学的知識のような自発的な情報、他のドラマーが有用である思った追加的な役に立つ検索などが提供される。

更に別のバリエーションでは、検索は検索されたコーパスの或る部分に限定した暗示的な制限を含んでいてもよい。従って、検索ユーザー又は検索システムオペレータは、ユーザー又はオペレータの制御下にある縦方向アプリケーションに対する優先的な取り扱いを含んでいてもよい。これは、共有サイトを最初に見つけるプラン、又はコンテンツがより多くの検索に現れるようにしようとコンテンツを改造する第三者の影響を制限するプランの一部ともなり得る。

暗示的なヒントオペレーションの一部として、検索システムは、暗示的に局所的な検索を検知する論理を含んでいてもよい。例えば、自動車販売特約店を求める検索の大部分は、普通は車の購入者が車両の購入のために地元区域を出ることは無いので、暗示的に局所的である。従って、検索者が「フォード特約販売店」と入力すると、検索システムは、ユーザーのジップコード（又は概略ジップコードや場所）という暗示的検索ヒントを付け加えることになる。場所を判定するのは、ユーザーが識別されており環境設定を表明している場合にはユーザーの環境設定を調べる、又はＩＰ／ネットワークアドレスや、携帯電話アクセスポイントを調べる（環境設定からの住所ではなく、移動体装置ユーザーが現在いる場所に局所的な情報を見つける）など、数々の方法で求めることができる。

このような局所的な検索の場合、ユーザーには、一般的な検索を得るため、又は別の場所を拾い上げるなどのため、検索の「局所性」を使用不能にするか否かの選択権が与えられる。或るバリエーションでは、ユーザーには局所的な検索結果と一般的な検索結果の両方が、それらを見分けるための表示要素（カラー、オフセット、ラベルなど）を付けて戻される。

検索が異なる言語又は方言を有する区域を対象に行える場合、自動的にスペルチェックを行うため、又は検索照会を翻訳又は別の方法で調整するために、場所情報を使用してもよい。例えば、検索照会「ブーツオガナイザー」が入力され、検索は北アメリカから入ってきていると検知されると、曖昧性を除去して「シューズ保管オガナイザー」とされることもあれば、一方で、検索が英国又は同様の方言の他の英語圏から入ってきていると検知されると、検索は曖昧性を除去して「自動車コンパートメントストレージユニット」とされる場合もある。

検索システムオペレータの提供物にもよるが、検索照会の幾つかは、広告又はコンテンツ設置を導く検索又はビジネス規則に入るためにユーザーが取る経路を明らかにするために構文解析される。例えば、ユーザーがスポーツページを訪れ、次いで検索入力ページにジャンプして検索を入力した場合、結果は、ユーザーが現在スポーツ関係ページを見ているという知識の影響を受けることになる。従って、「コンペティション」の検索は、スポーツの競技会に関係するページを提供することになり、一方でユーザーが金融関連のページから来た場合は、同じ検索ストリングでも商戦関連のページが提示されることになる。

ビジネス規則により導かれた結果の場合、検索システムオペレータは、取られた経路に続いて或る或る種の検索を実行するユーザーに対してだけ広告主の広告が提示されるように広告主に選択性を提供することができ、そうすると、「コンペティション」を探している或る検索者は、その分野の競争力を向上させるためのスポーツトレーニングキャンプの広告を目にすることになり、一方、「コンペティション」の別の検索者は、市場及び産業分析サービスの広告を目にすることになる。別の例として、ニュースの経路から「ワシントン」を検索している人は政治的な広告を得ることになり、一方、旅行経路から「ワシントン」を検索している人は天気のページへのプロンプト又はリンクを得ることになる。曖昧性の除去には追加的なビジネス規則も利用可能である。

とりわけ、明示的なヒントは検索照会ストリング内の特定の位置に限定されない。例えば、検索システムは、「！天気９４０８９」、「天気９４０８９」、「サニーベール、ＣＡ、天気」、「地域コード９４０８９はどんな天気」などのどのストリングでも「天気」ヒントと判定する。無論、検索システムは、検索ストリング内の場所ヒントも判定する。検索照会ストリングのどのトークン又はトークン部分がヒントであるかの判定は、意味が分かっている単語のルックアップ表により判定されることが多いが、照会ログを使用してどのトークン部分がヒントかを判定することもできる。例えば、照会ログの入力が、使用された検索照会ストリング、及び照会に続いてユーザーが選択した検索結果からのページの識別又は表示（タイトル、ＵＲＬなど）を含むように、照会ログは保持される。例えば、検索「ラブラドール」を提出して検索結果を得たユーザーが、カナダを扱ったページよりも犬を扱った結果ページを殆どいつも選択していることを照会ログが示している場合、検索システムは、ラブラドールを場所ヒントとして使うことをしなくなる。従って、ユーザーが「ラブラドールフード」の検索を入力すると、ドッグフードのサイトが現れる。一方、紹介ログに「ラブラドール」の検索者の殆どが次にカナダ地方に関係するリンクをクリックすると記録されていることが分かった場合、検索システムは、「ラブラドールフード」の中の「ラブラドール」を場所ヒントとして使用し、その結果、おそらくは、カナダのニューファンドランと及びラブラドール地方に場所を限定した食料品店及びレストランの検索結果が出されることになる。

照会ログを使用するバリエーションでは、ヒントは検索内の時間変数に注目することにより収集される。特定のエンティティの検索が急増した場合には、明示的なヒントである「ニュース」が付け加えられる。従って、ユーザーが「パリファッション」の検索を提出すると、検索システムは、一般的にパリのファッションに関係するページを戻すことになるが、照会ログに「パリファッション」の検索が目立ってくると、検索システムはニュースサブドメインに対する検索に的を絞ることになり、これは、多くの検索者がパリのファッションシーンが絡んだ或る種の速報についての情報を探している場合には、ユーザーが目当とするものであると考えられる。

多数の検索が処理中の状態では、１つの検索サーバーではこの負荷を処理しきれなくなる。そのような状況に対処するため、検索サーバーは複数のサーバーを備え、その中で入ってくる照会を方向付ける。サーバーは、検索コンテンツに基づいて選択してもよいが、負荷を均等化するためにコンテンツ如何によらず選択してもよい。

図９は、複数の検索クライアントがドキュメントのコーパスに照会を行うために検索システムにアクセスすることができる、ネットワーク化されたシステムを示している。このシステムでは、１つ又は複数の（恐らくは数千又はそれ以上の）クライアントシステム９０２がインターネット９０４を介して要求を出す。要求はＨＴＴＰサーバー９０６を経由してサーバー９０７に流れるが、複数のＴＨＨＰサーバーが存在しており、ＨＴＴＰに代えて又はこれに追加して他のプロトコルも使用されることを理解頂かねばならない。サーバー９０８は、照会を照会プロセス９１０に送るが、これは、サーバー９０８又はその他の場所のソフトウェアオブジェクトの例示であってもよいし、ハードウェア要素を含んでいてもよい。照会プロセス９１０は、次いで検索照会ストリングを構文解析して、ドキュメント、ドキュメントへの参照、リンク、又はその他のヒット表示を、１つ又は複数のコーパス９１２から取得する。

或る実施形態では、コーパス９１２はコーパス全体の完全なコピーであるが、他の実施形態では、コーパス９１２は完全なコーパスのサブセットである。後者の場合、サーバー９０８又はサーバープロセス９１０は、照会及び恐らくは他の情報から、どのコーパスを使用するかを判定することができる。場合によっては、単一の照会に対しても、１つの照会プロセス９１０が２つ以上のコーパス９１２にアクセスすることもある。例えば、別々のサブドメインが別々のコーパスとして記憶されることもある。

図９では、複数のオブジェクトのインスタンスは、クライアントシステム９０２の特定のインスタンスに対し９０２（１）のような括弧付インデクスにより区別される。各種オブジェクトに対して、端末インデクスは「６０２（Ｎ１）」のようなある種の不特定番号である。オブジェクトの番号が同じである必要がない場合、端末のインデクスは明確に区別できる変数で表示される。この様に、図９には３つのサーバー９８０と３つのコーパス９１２しか図示されていないが、Ｎ２（不定数）のサーバーとＮ６（別の不定数）のコーパス９１２が図９には含まれており、従って、サーバーとコーパスは１対１の対応が必要なわけではない。特に指定のない限り、異なる端末インデクスは、１から１より大きい数の範囲で同じ又は異なる値を有していてもよい。

上記の例では、ヒントはパーサ７１０により構文解釈される。なお、処理によっては、クライアント側で行われる場合もあると理解されたい。何れにしろ、結果としての検索がそれぞれのユーザー毎に異なるように解釈はカストマイズされる。こうして、ユーザーの環境設定により検索が変化し、各ユーザーは、自身の特注のナビゲーショナルヒント群を持つことができる。例えば、或るユーザーの環境設定が居住している都市を示している場合が考えられ、それは検索へ通知するのに使用される。例えば、ユーザーの環境設定が、ユーザーの住んでいる都市として「サニーベール、ＣＡ」を示している場合、検索照会ストリング「!yp ピザ」は、カリフォルニア州サニーベール内の又はその付近の「ピザ」のイエローページサブドメインに対して検索が行われるようにする。５桁のジップコード又は６桁の郵便番号などを使用するのに加えて、ビジネス規則は、場所に翻訳される都市の一覧を含んでいてもよい。他の環境設定は、不適切なリンクをフィルタリングで外すなどのフィルタリング、又は検索をユーザーの好む言語に検索を限定することを含んでいてもよい。

場所特定検索の場合、検索されているサブドメインが場所に従って索引付けされていれば、より的を絞った結果が期待できる。都市名をヒントとして含んでいる検索では、サブドメインがフィルタに掛けられる検索に変換される。例えば、検索が「サニーベール」を含んでおり、それが天気サブドメインのような、場所で索引付けされたサブドメインの場合、検索は、その場所に関係付けられており、残りの検索照会ストリングに一致しているページに対するものとなる。

検索が場所特定であると識別されている場合、提供されるインサート及び広告も場所特定型となる。上記の例では、場所特定検索での「ピザ」の検索は、当該場所内で用語「ピザ」を使った検索だけを対象として広告掲載を選択しているピザ供給者からの広告を載せた結果ページが表示される。中には、対象を幅広く場所を特定した広告活動がサポートされている場合もあり、その場合には、例えば、広告主は、サブドメイン又は使用されている検索用語には関係なく、場所に関係付けられた検索結果ページに掲載される広告を購入することを選択することが考えられる。事実、検索結果ページの集合全体は、ぴったりの検索結果（従来の「キーワード」販売における）、ぴったりの場所、又はその両方に基づく広告活動又はインサート活動のために副分割することもできる。

図１０は、場所が暗示される検索にとって可能な処理の流れを示したフローチャートである。図示のように、検索システムは、検索を受信し（Ｓ１）、次いで、検索照会内の場所を表しているかもしれないものを調べる（Ｓ２）。場所表示となるものがない場合、検索は場所特定性無しで処理される（Ｓ３）。次にステップＳ４で、場所表示は、それが例外か否か判定するために調べられる。例えば、検索照会ストリングが「テイスト・オブ・フランス・レストラン・メニュー」であるとする。「フランス」は場所として識別されるが、更にここで、検索システムはレストランの一覧を保持しており、その内の１つが「テイスト・オブ・フランス」と呼ばれているとする。この場合、検索は「フランス」という場所特定性を伴う検索ではない。検索システムは、次に、場所特定性無しに検索を処理することになる（ステップＳ３）が、レストランについて場所が分かっている場合は、場所特定性を採用してもよい。ステップＳ２とＳ４（並びに他の予想されるステップ）の処理過程は、照会ログのコンテンツを使って、場所ヒントがあるのならばどのトークンが暗示的ヒントを与えているかを判定し、或いは場所自体を判定する。

場所特定性が存在すると見なされると、局所的検索が実行され（Ｓ５）、検索は、例えば、場所ヒントを外した検索照会ストリングの残りの部分に場所フィルタを使って検索することで行われる。よって、検索「フランス、バーガンディのレストラン」であれば、フランス、バーガンディに対して場所フィルタを使った「レストラン」（又は「〜のレストラン」に対する検索となる。フィルタは、検索を場所により収集されたコーパスに限定するように、又はフィルタリングにより共通のコーパスから他の場所が連想されるヒットを得るように動作する。

次に、識別された場所に対してマップが入手され（Ｓ６）、適したイエローページ入力又はイエローページ入力のプロンプトが入手される（Ｓ７）。次いで、結果、マップ、イエローページなどを組み合わせて（Ｓ８）表示ページが作成され、ユーザーに戻される。

ヒントの中には、"dic"、"dictionary"のような同義語、"define"など、全てディクショナリ・サブドメインの検索に対するマップであるものを有するものもある。ヒントによっては、「！天気 サニーベール」と「！サニーベール 天気」のように順序を変えることができるヒントもある。

中には、Yahoo!のディレクトリ構造に一致する用語のようなディレクトリ特定のヒントもある。ディレクトリ特定検索の場合、検索は、ディレクトリの選択されたカテゴリに限定される。例えば、検索照会ストリング「！ディレクトリ 弁護士 サニーベール」は、ページ上に用語「弁護士」をたまたま有する弁護士のページの検索ではなく、ディレクトリ検索で、サニーベールに場所特定で、弁護士の検索であることを表示するヒントを持つ検索である、と構文解析される。これは、多くの弁護士のページが当該ページ上にその名前を有しているが、商号の一部で無い限り用語「弁護士」はページ上には無いことから、より有用であるといえる。

ヒントの中には、カストマイズされた曖昧さのないヒントの形態のものもあり、その場合、ユーザーの環境設定が検索に使用される用語の曖昧さを取り除くために使用される。例えば、或るユーザーでは、「フットボール」は「サッカー」を指すことを示すのがカストマイズされた曖昧さの除去であり、別のユーザーでは、「フットボール」は「アメリカンフットボール」を指すことを示すのがカストマイズされた曖昧さの除去になる。

これらカストマイズされた曖昧さ除去のヒントは、オンザフライで生成される。例えば、ユーザーが、曖昧であり且つ未だ曖昧さ除去されていないとフラグを立てられた用語を含んでいる検索照会を送ると、ユーザーは当該用語に対して優先する意味を選択するように促される。別のやり方では、曖昧さ除去は、曖昧であるとしてフラグを立てられた用語に限定されず、１つ又はそれ以上の使用した用語が明らかに曖昧であることを、ユーザーが検索結果から判断したときにはいつでもオプションとして行われる。

曖昧さ除去では、キーワードが検索の曖昧さを完全に取り除いて１つの返却ページを作成できるように行われる。例えば、ユーザーは、検索照会ストリング「フットボールゲーム」を使って検索サーバーに検索を送ると、数百ページに及ぶ検索結果ページを入手する。検索結果ページで、ユーザーが環境設定ページを示すことができれば、当該ページは、当該用語を使用した将来的な照会に応えてもたらされるページになる。この返答は、当該ユーザーに特定のものとなるが、検索サーバーオペレータは、全てのユーザー又はユーザーのある一定の集合体に対して利用可能となる大域的な曖昧さ除去を実行することを選択してもよい。

更に別のバリエーションでは、曖昧さ除去に対する中間的なやり方は、全ての異なる意味を網羅した一般的な返答と、照会用語に関係付けられた特定のページの特定の返答とから、何らかの曖昧さを取り除いて、ユーザーの曖昧さ除去において用語を解釈する回数が減るようにしている。

上記例の多くでは、検索対象のコーパスは一般的にアクセス可能なコーパスである。他のバリエーションでは、コーパスは、ユーザーは検索できるが検索サーバーは通常はそこでは動作を行わないある種のデータベースである。一例として、企業従業員ルックアップがあるが、これはユーザーに対して内部的にのみ利用可能であり、検索サーバーにより直接アクセスできるものではない。このバリエーションでは、検索サーバーは、それでも、私有のデータにアクセスすることなくこれを検索するための機能を提供する。例えば、ユーザーは、殆どの検索に使用されるダイアログボックスに行き、「！電話 ジョー・ジョーンズ」と打ち込む。検索サーバーのパーサは、これを、「電話」サブドメインの検索要求であると解釈し、変更された検索照会ストリングを付けてクライアントを、クライアントならアクセス可能で検索サーバーはアクセス不能なデータベースに転送する。しかしながら、検索サーバーは、それでも、矛盾のないルック・アンド・フィールのインサート及び／又は広告を提供することができる。

検索サーバーが直接利用できないコーパスに対するもっと一般的なやり方では、検索サーバーは、検索を構文解析して、当該検索を守備範囲とする別のサーバーに仲介する。検索の仲介には、検索サーバーオペレータと仲介された検索の受諾先システムのオペレータとの間で、何らかの値変更が仲介サービスと引き換えで手渡されるようにする合意が関わってくる。

以上、好適な実施形態を参照しながら、本発明について説明してきた。当業者には、これに対する変更及び置換が自明であろう。従って、本発明は、特許請求の範囲によって規定されるものを除いて、限定されるものではない。

アペンディックスＡはヒントの一覧であり、検索を特定のサブドメインに限定する場合に使用されるヒントキーワードとして使用できるサブドメインキーワード例を載せている。

［アペンディックスＡ］
このアペンディックスは、"!"（又は他のヒント表示方法又は暗示的ヒント提示）が後に続く検索照会ストリングに使用された場合に、サブドメイン特定の検索が行われるようにする、キーワードの一覧の一例である。

本発明の実施形態による検索システムのブロック図である。 図１の検索サーバーの要素を詳しく示すブロック図である。 検索結果のページを表す図である。 サブドメイン検索に構文解析可能な検索シーケンスを受け入れる場合にユーザーに提示されるページを表す図である。 ブックマーク検索のサブドメイン検索に構文解析可能である検索シーケンスを受け入れる場合にユーザーに提示されるページを表す図である。 検索サーバーの別の変形例を示すブロック図である。 検索サーバーの他の要素を説明する図である。 検索照会を構文解析及び分析して、必要に応じてサブドメインを呼び出す処理のフローチャートである。 ここで説明するように受け取って分析された照会の処理に使用される分散型照会操作システムのブロック図である。 位置が暗示されている検索の場合の、或る予想される処理の流れを示すフローチャートである。

Claims (20)

1. 少なくとも１つの検索照会ストリングを含む検索要求に応じて検索結果を提供するための方法であって、
   検索サーバが該検索サーバにおけるパーサを用いて前記検索照会ストリングをトークンに構文解析する段階と、
   前記検索照会ストリングにトークンが存在する場合には、前記検索サーバがどのトークンがヒントトークンであるかを該検索サーバに保持されたビジネス規則に基づいて決定する段階と、
   前記検索要求が暗示的ヒントを暗示しているということを１又はそれ以上の照会ログの内容を用いて決定する段階と、
   前記暗示的ヒントに従って前記検索要求について検索を実行する段階と、
   を含み、
   前記検索要求が暗示的ヒントを暗示しているということを１又はそれ以上の照会ログの内容を用いて決定し、前記暗示的ヒントに従って前記検索要求について検索を実行する動作が、
   照会ログに基づき暗示的ヒントを推測する段階と、
   前記検索要求に推測された前記暗示的ヒントを付加する段階と、を含む、
   ことを特徴とする方法。
2. 前記検索要求に付加される前記暗示的ヒントが追加的な検索用語を含む、請求項１に記載の方法。
3. どのトークンがヒントトークンであるかを決定する前記段階は、一組のヒューリスティックに決められたビジネス規則を使って、前記トークンを分析する段階を含む、請求項１に記載の方法。
4. どのトークンがヒントトークンであるかを決定する前記段階が、さらに、
   検索照会の履歴を保持している照会ログ内で、１つ又は複数のトークンに対する一致を見つける段階と、
   前記照会ログ内での前記一致に基づいて、トークンをヒントトークンとして識別する段階と、
   を含む、請求項１に記載の方法。
5. どのトークンがヒントトークンであるかを判定する前記段階は、前記検索サーバが保持しているヒントトークン候補の表を分析する段階を含む、請求項１に記載の方法。
6. 少なくとも１つのヒントトークンを有する前記検索照会ストリングを、残りの検索ストリングと、前記少なくとも１つのヒントトークンと、に構文解析する段階と、
   前記残りの検索ストリングを、前記少なくとも１つのヒントトークンのうちの１又はそれ以上のヒントトークンにより示された１又はそれ以上のサブドメインサーバに導く段階と、
   をさらに含む、請求項１に記載の方法。
7. 少なくとも１つのヒントトークンを有する前記検索照会ストリングを、残りの検索ストリングと、前記少なくとも１つのヒントトークンと、に構文解析する段階と、
   前記残りの検索ストリングを、前記少なくとも１つのヒントトークンのうちの１又はそれ以上のヒントトークンにより示唆されたコーパスを対象に検索するための前記検索エンジンに導く段階と、
   をさらに含む、請求項１に記載の方法。
8. 前記検索照会ストリングに少なくとも１つの場所ヒントトークンが存在していることについて最初の判定を行う段階と、
   少なくとも１つの場所ヒントトークンが存在する場合に、前記少なくとも１つの場所ヒントトークンが前記検索サーバによりアクセス可能なメモリにおいて場所を決定するものではないとして記録されているかどうかを決定する段階と、
   少なくとも１つの場所ヒントトークンが存在しかつ場所を決定するものではないとして記録されていない場合に、場所に基づく検索を実行する段階と、
   場所ヒントトークンが存在しないか、又は、場所ヒントトークンが存在していても場所を決定するものではないとして記録されている場合に、場所独立型検索を実行する段階と、をさらに含む、請求項１に記載の方法。
9. 場所ヒントトークンが存在する場合に、場所を決定するものではないとして記録されていないこのような場所ヒントトークンによって示された場所の地図を生成する段階をさらに含む、請求項８に記載の方法。
10. 要求側に戻される表示ページに、前記地図と前記場所に基づく検索の結果を組み合わせる段階をさらに含む、請求項９に記載の方法。
11. 検索サーバが該検索サーバにおけるパーサを用いて検索照会ストリングをトークンに構文解析する段階と、
    前記検索照会ストリングにトークンが存在する場合には、前記検索サーバがどのトークンがヒントトークンであるかを該検索サーバに保持されたビジネス規則に基づいて決定する段階と、
    前記検索要求が暗示的ヒントを暗示しているということを１又はそれ以上の照会ログの内容を用いて決定する段階と、
    前記暗示的ヒントに従って前記検索要求について検索を実行する段階と、
    を実行するように構成された１つ以上のコンピュータであって、
    前記検索照会ストリングについての検索要求が暗示的ヒントを暗示しているということを１又はそれ以上の照会ログの内容を用いて決定し、前記暗示的ヒントに従って前記検索要求について検索を実行する動作が、
    照会ログに基づき暗示的ヒントを推測する段階と、
    前記検索要求に推測された前記暗示的ヒントを付加する段階と、を含む、
    ことを特徴とする１つ以上のコンピュータ。
12. 前記検索要求に付加される前記暗示的ヒントが追加的な検索用語を含む、請求項１０に記載の１つ以上のコンピュータ。
13. どのトークンがヒントトークンであるかを決定する前記段階は、一組のヒューリスティックに決められたビジネス規則を使って、前記トークンを分析する段階を含む、請求項１０に記載の１つ以上のコンピュータ。
14. どのトークンがヒントトークンであるかを決定する前記段階が、さらに、
    検索照会の履歴を保持している照会ログ内で、１つ又は複数のトークンに対する一致を見つける段階と、
    前記照会ログ内での前記一致に基づいて、トークンをヒントトークンとして識別する段階と、
    を含む、請求項１０に記載の１つ以上のコンピュータ。
15. どのトークンがヒントトークンであるかを判定する前記段階は、前記検索サーバが保持しているヒントトークン候補の表を分析する段階を含む、請求項１０に記載の１つ以上のコンピュータ。
16. 少なくとも１つのヒントトークンを有する前記検索照会ストリングを、残りの検索ストリングと、前記少なくとも１つのヒントトークンと、に構文解析する段階と、
    前記残りの検索ストリングを、前記少なくとも１つのヒントトークンのうちの１又はそれ以上のヒントトークンにより示された１又はそれ以上のサブドメインサーバに導く段階と、
    をさらに含む、請求項１０に記載の１つ以上のコンピュータ。
17. 少なくとも１つのヒントトークンを有する前記検索照会ストリングを、残りの検索ストリングと、前記少なくとも１つのヒントトークンと、に構文解析する段階と、
    前記残りの検索ストリングを、前記少なくとも１つのヒントトークンのうちの１又はそれ以上のヒントトークンにより示唆されたコーパスを対象に検索するための前記検索エンジンに導く段階と、
    をさらに含む、請求項１０に記載の１つ以上のコンピュータ。
18. 前記検索照会ストリングに少なくとも１つの場所ヒントトークンが存在していることについて最初の判定を行う段階と、
    少なくとも１つの場所ヒントトークンが存在する場合に、前記少なくとも１つの場所ヒントトークンが前記検索サーバによりアクセス可能なメモリにおいて場所を決定するものではないとして記録されているかどうかを決定する段階と、
    少なくとも１つの場所ヒントトークンが存在しかつ場所を決定するものではないとして記録されていない場合に、場所に基づく検索を実行する段階と、
    場所ヒントトークンが存在しないか、又は、場所ヒントトークンが存在していても場所を決定するものではないとして記録されている場合に、場所独立型検索を実行する段階と、をさらに含む、請求項１０に記載の１つ以上のコンピュータ。
19. 場所ヒントトークンが存在する場合に、場所を決定するものではないとして記録されていないこのような場所ヒントトークンによって示された場所の地図を生成する段階をさらに含む、請求項１８に記載の１つ以上のコンピュータ。
20. 要求側に戻される表示ページに、前記地図と前記場所に基づく検索の結果を組み合わせる段階をさらに含む、請求項１９に記載の１つ以上のコンピュータ。

Images