JP2004515829A - 検索タスクモデル及び双方向検索タスク改良処理を有する検索エンジン - Google Patents

Abstract

検索結果と比較され、追加的要求により若しくは自動的に検索を改良するのに用いられることが可能なタスクモデル定義を受け入れるインテリジェント・アシスタントを提供する検索エンジン。タスクモデルの一般的なアプローチは、検索結果がユーザが探しているものと良好に一致するか否かを直接的に若しくは受動的に決定することである。このように、本システムは、ユーザが取り出した検索結果と比較するための何かを有する。良く知られているように、複雑なデータ群の検索を行う処理には多くのフラストレーションが伴い得る。上記システムは、検索結果と比較するための情報若しくは実行前に検索を改良するための情報をユーザに指定させること若しくはシステムに推定させることが可能なメカニズムを提供する。図示するように、これは、別の検索語を提供することによってユーザに彼の検索を改良する機会を与えるインテリジェント・アシスタントの基礎として用いられ得る。

Description

【０００１】
（発明の背景）
（発明の属する技術分野）
本発明は、インターネット、電子番組表、インデックス付きドキュメント・データベースなどの検索に用いられるものなどの検索エンジンに係り、特に、キーワード及びフルテキストで検索可能なデータベースを検索するのに用いられるものなどの大量の別の検索語を含み得る問い合わせを採用する検索に関する。より詳しく言えば、本発明は、上記のような検索エンジンであって、特に、検索問い合わせによって返された結果の妥当性を向上させるためのタスクモデルが指定される検索エンジンに関する。
【０００２】
（背景）
検索エンジンは、それらの処理の一部として、問い合わせを生成し、該問い合わせをデータベースからレコードを取り出すために用いる。多様な検索エンジンが良く知られている。検索エンジンの多くは、ユーザに１以上の語を含む検索定義（例えば、検索文字列）を入力させる。上記語のそれぞれは、大量の考えられる語のうちの１つである。例えば、辞書中のすべての語がキーワード及びフルテキスト検索問い合わせを構成し得る。更に、多くの重複語若しくは冗長語がこれら大量の語の中に存在する。考えられる語数を減らしても、それらの考えられる組み合わせが大きくなり得る。考えられる問い合わせ語のリスト（通常は、ユーザによって選択された母国語）に時々内在する語数及び冗長性は、検索エンジンの使用について深刻な問題を導き得る。
【０００３】
検索を実行する典型的なルーチンは、検索文字列の入力から始まる。この入力は、例えば、自由形式の文章、質問、語群若しくはフレーズ群、又は、一単語である。検索エンジンは、語及びフレームが考えられる個別の語として採用されるように語群を解釈してもよい。例えば、「赤い」という語の後に「犬」という語が現れる場合、検索エンジンは、同じドキュメントにおいて、「赤い犬」を検索してもよく、「赤い」及び「犬」という語を互いに別々の語として検索してもよい。更に、検索エンジンは、ある語にはより重要なものを加え、ある語にはより重要でないものを加えることを可能にする文法モデルを含んでもよい。近似範囲、離散接続詞、接続詞などのシンボル（例えば、語）を接続させるブーリアン（Ｂｏｏｌｅａｎ）演算子などの他の変形例も用いられる。検索エンジンは、これら入力から結果を選択するための明確な問い合わせを生成する。そして、該問い合わせが結果を取り出し、関連性に基づいて並び替える。
【０００４】
関連性は、最も一般的なものの１つである検索語の相対的重要性以外の基準を含んでもよい。例えば、検索エンジンは、問い合わせによって返される候補レコードに、Ｇｏｏｇｌｅ（Ｒ）によって行われる場合のように、その候補を指摘する他のサイトに存在するリンク数に基づいて特定の値を割り当ててもよい。関連性は、問い合わせ若しくはユーザによって何かしら明確に指定されたものから推測されてもよい。
【０００５】
現存技術の問題の１つは、ユーザが取り出そうとするレコード数とほぼ無関係に検索結果を生成することである。ユーザがレコードを１つだけ欲しい場合に、彼／彼女は、彼／彼女の問い合わせに対する膨大な数の応答を受け取り、彼／彼女が特定のレコードを探すのに役立つようにその数を減らすために彼／彼女の文字列を改良しなければならなくなるかもしれない。これは解決策を要求する欠点である。しばしば用いられるアプローチの１つは、結果を優先度に応じて並び替えることである。しかし、これは、語自体及びユーザによって適用されるかもしれない演算子とは別に、ユーザによるアクセスが不可能な予め指定された基準の内因的メリットを前提としている。よく発生する別の問題は、検索が予想よりはるかに少ない数の結果しか返さない場合である。これは、良い語が用いられたとしても、すべての考えられる関連語を表していないために起こり得る。例えば、ユーザが人の名前を検索したが、彼／彼女のニックネームを検索しなかった場合、検索は関連レコードを見逃すかもしれない。
【０００６】
ユーザが検索処理により知能（すなわち、彼／彼女が彼の検索を始める前にユーザが知っている情報）を提供できるようにする解決策が望まれる。
【０００７】
（発明の開示）
インテリジェント検索処理は、ネットワーク・ワークステーション若しくは電子番組表（ＥＰＧ）を有するテレビ・セットトップ・ボックスなどのコンピュータ若しくはコンピュータ・ネットワーク上で実行可能である。この処理は、従来の検索語のみならず、タスクモデル定義をも受け入れる。タスクモデル定義は、ユーザが例えば探すレコード数を指定することを可能にする。ＥＰＧ検索環境において、ユーザは、多くの結果ではなく、特定の一番組を探してもよい。ユーザが多くの結果を望む場合、彼／彼女は、例えば全ジャンル若しくは全時間帯を通じた閲覧を希望するかもしれない。ユーザが特定のレコードを欲する場合、彼／彼女は１つの特定の番組のみが望まれることは前もって知っているかもしれないが、タイトル、チャンネル、若しくは該検索を効果的に狭める他の変数について確信を持っていない。これら種類のタスクをサポートするために、ユーザ・インターフェース（ＵＩ）により、ユーザが１つの「ヒット」を検索しているのか、少数の「ヒット」を検索しているのか、又は、大量の「ヒット」を検索しているのかをタスクモデルの内容に示させることができる。別の方法として、タスクモデルは、現存状態から推定されてもよく、番組表若しくは他の検索結果の閲覧などのユーザの行動から受動的に推定されてもよい。
【０００８】
検索エンジンは、タスクモデルによって定義された追加的インテリジェンスを用いて検索結果を修正する。ユーザによって提供された情報は、タスクモデルの内容によって補完される。置き換えられはしない。このように、取り出されたレコード群は、多くの問い合わせ生成モデル及び並び替えモデルの中の任意のものを採用した一般的な方法で取得されてもよい。しかし、検索結果が一旦得られると、タスクモデル内容は、結果を修正するのに用いられてもよい。一実施形態において、検索によって返されるレコード数よりはるかに（何倍も）少ないレコード数を要求するタスクモデルへの応答として、検索エンジンは、返されたレコード群から弁別物（ｄｉｓｃｒｉｍｉｎａｎｔ）を探し、返された結果を単に並べる代わりにそこから選択するように弁別物のリストをユーザに提供してもよい。この弁別物は、例えば、取り出された結果に小さい割合でしか登場しないが他の結果には群を抜いて欠けている重要な語である。多くのこのような弁別物を識別し、それらのすべてをユーザにそこから選択するように提供してもよい。
【０００９】
弁別物の識別は、それ自体良く開発された技術である。非常にシンプルなアプローチは、返されたレコードに最も頻繁に登場する語を示すヒストグラムを生成し、ユーザに最大頻度を有する語の中からユーザに選択させることである。別のアプローチは、問い合わせ中に指定されていないが問い合わせ中に指定された語に関連して登場する語の一般的な発生率を上記両語が相互に隣接して登場する時に上記指定されていない語が上記指定された語を修正するという前提の下で探すことである。これら指定された語は、そこから選択すべきオプションとして提示される。これら弁別物を識別するために必要とされる統計は、検索エンジンによって採用される処理から端的に生成される。検索エンジンは、このような統計の即時生成を可能にするインデックス・ファイルを生成若しくは使用する。
【００１０】
タスクモデル選択は、２つの入力：予想されるヒット数及び検索されたヒット数を受信し得る。このタスクモデルの選択は、選択リスト、数字、若しくは探す若しくは予想されるレコード数を示すための他のコード若しくはシンボルを用いて行われ得る。
【００１１】
本発明と共に用いられ得る別のタスクモデルは、自動的に指定若しくは推定されたコンテキスト定義の鍵が掛けられてもよい。例えば、ユーザが特定の日時における特定の種類の一番組を探している場合、これら条件が提示されると、システムは適切な推定を行ってもよい。例えば、システムは、彼／彼女が見るための特定の番組を探しているのか、或いは彼／彼女が（従前の選択に基づいて）特定の種類の番組を欲しているのかを推定してもよい。応答として、システムは、これら推定に基づいた選択リストを彼／彼女に提供してもよい。
【００１２】
本発明をより完全に明らかにするために、以下の例示的図面を参照して、本発明を特定の好ましい実施形態に関して説明する。図面を参照する際、図示された事項は、例示的であって、本発明の好ましい実施形態を例示的に説明することだけを目的としたものであり、本発明の原理及び概念的態様についての最も有益的で容易に理解される説明と信じられているものを提供するために提示される。この点、本発明の基本的理解に必要なもの以上の本発明の構造上の詳細を示す試みは為されていないが、本発明の複数の形が如何に実際に実施され得るかは図面を共に説明を読むことによって当業者には明らかとなる。
【００１３】
（発明の詳細な説明）
図１を参照する。図１は、家庭用テレビシステム用の電子番組表（ｅｌｅｃｔｒｏｎｉｃ ｐｒｏｇｒａｍ ｇｕｉｄｅ：ＥＰＧ）環境における本発明を示す。一実施形態において、コンピュータ（若しくは「セットトップ・ボックス」）２４０は、番組情報をテレビ若しくはモニタ２３０上に表示する。コンピュータ２４０は、キーボード２１１や手持ちリモコン２１０などのユーザ入力装置を通じて検索問い合わせを受け入れることに加えて、１又は複数のサーバ２７６や他のビデオ・ソースからネットワーク・チャネル２７４を通じてデータやビデオなどの信号２６０を受信し、チャネル切替機能を制御するように装備されてもよい。ＥＰＧは、検索エンジン処理を用いて照会されると共に、（現在の日時などの）デフォルト・フィルタなどのシンプルな基準に基づいて閲覧することができる。コンピュータ２４０は、更に、ユーザが（図示しない）テレビのチューナではなくコンピュータ２４０内部の（図示しない）チューナを通じてチャネルを選択することができるようにプログラムされてもよい。すると、ユーザは、コンピュータを制御するリモコン２１０を用いて、表示された番組スケジュールから所望の選択を強調することによって、見る番組を選択することが可能となる。コンピュータ２４０は、例えばスピーカ２３１などの他の様相を通じて出力してもよい。コンピュータ２４０は、それを通じて更新された番組スケジュール・データを受信することができるデータやビデオなど用のリンク２６０を有する。これは、例えば、インターネット・サービス・プロバイダや他の適切なデータ接続へ接続可能な電話線である。コンピュータ２４０は、番組スケジュール情報、番組アプリケーション及び更新、及び、他の情報、などを記録するための例えばハードディスクである大容量記録装置２３５を有する。ユーザのプリファレンス及び他のデータについての情報は、メモリ・カード若しくはディスク２２０などの着脱可能媒体を通じてコンピュータ２４０内へアップロードすることができる。
【００１４】
ＥＰＧデータは、タイトルと、物語の要約や内容を分類する様々なキーワードなどの多様な記述情報とを含んでもよい。これらは、適切なユーザ・インターフェース（ＵＩ）を通じてフルテキストとして検索可能であってもよい。ここで図２も参照する。番組情報は、ユーザに示され、ユーザはそれを閲覧することができる。付随するディスプレイは、現存するケーブルテレビのチャネルガイドに一般的に用いられているものと同様の時間グリッド形式であってもよい。時間グリッド表示１７０において、バー１３０で示されるもののように、様々な番組が示される。各バーの長さは、個々の番組の持続時間を示し、各バーの始点及び終点は、個々の番組の開始時刻及び終了時刻をそれぞれ示す。記述窓１６５は、現在選択されている番組に関する詳細情報を提供する。
【００１５】
上記例示的ハードウェア環境において多くの置換が可能であり、すべてのものが本発明と共に用いられ得ることに注意。大容量ストレージは、揮発性メモリ若しくは不揮発性メモリによって置換され得る。データは、ローカルにもリモートにも保存することができる。事実、コンピュータ２４０全体は、リンクを通じて周辺で作動する１若しくは複数のサーバ２７６によって置換され得る。赤外線ポート２１５を通じてコンピュータ２４０にコマンドを送信するリモコンを用いる代わりに、コントローラがビデオを運ぶ物理チャネルとは別の若しくは該物理チャネルと同じデータ、ビデオなど用のリンク２６０を通じてコマンドを送信することも可能である。ビデオ若しくは他のコンテントは、ケーブル、ＲＦ、若しくはケーブル・ソース１００’から発せられた他の広帯域物理チャネルによって運ばれることも可能であり、例えばデータ・ストア２３５又はメモリ・カード若しくはディスク２２０などの大容量ストレージ若しくは着脱可能記録媒体から取得することも可能である。コンテントは、電話回線などの交換型物理チャネルによって運ばれてもよく、ＡＴＭなどの仮想交換型チャネルによって運ばれてもよく、同期データ通信に適した他のネットワークによって運ばれてもよい。コンテントは、今日のＩＰネットワークを用いることが可能となるように、非同期で、ドロップアウトを許容するものであってもよい。更に、プログラミング・コンテントが受信される際に通る回線のコンテントは、例えば、オーディオ、チャット、会話データ、ウェブ・サイト、若しくは多様な選択が可能なあらゆる他の種類のコンテントなどである。番組ガイド・データは、データ、ビデオなど用の個別のリンク２６０以外のチャネルを通じて受信することも可能である。例えば、番組ガイド情報は、ビデオ若しくは他のコンテントと同じ物理チャネルを通じて受信することが可能である。番組ガイド情報は、更に、メモリ・カード若しくはディスク２２０などの着脱可能データ記録媒体を通じて提供されることも可能である。リモコン２１０は、キーボード、音声入力インターフェース、三次元マウス、ジョイスティック、若しくは他の適切な入力装置によって置換され得る。選択は、点滅しているインジケータを移動させることによって為されることも可能であり、（例えば名前や番号によって）象徴的に選択を識別することも可能であり、データ伝送若しくは着脱可能媒体を通じてバッチ形式で選択することも可能である。
【００１６】
図５を参照する。工程Ｓ１０において、ユーザは問い合わせを選択若しくは入力する。タスクモデルは、予想されるレコード数及び／若しくは最終的に所望されるレコード数の推定値である。これは、データベース・サイズ若しくは一般的なトピック・エリアなどの基準に対して判断され得る「小さい」、「普通」、若しくは「大きい」などの用語によって概算として指定され得る。工程Ｓ２０において、問い合わせが送信され、検索結果が取り出される。次に、工程Ｓ２５において、タスクモデルが取り出された検索レコードより小さい場合、適切な統計によって設定された有益的な弁別物が取り出されたレコードから選択される。この弁別物は、以下に述べる様々な方法によって導かれ得る。工程Ｓ３０において、これらは表示され、ユーザはそれらの中から１若しくは複数を選択する。工程Ｓ３５において、これらは返される結果へ適用される。この処理は、最終的に所望される結果数が生成されたレコードに一致するまで繰り返されてもよい。最後に、工程Ｓ４０において、結果がユーザへ表示される。例えば特定の結果を検索若しくは閲覧のために選択するなどの適切なアクションが採られてもよい。
【００１７】
タスクモデルは予想されるレコード数と最終的に所望されるレコード数の両方の内容を含む必要は無いことに注意。但し、両者が指定されれば、より有益的となり得る。ユーザが特定の一レコードを欲し、賢い検索処理から正しいレコードを見つけるにあたっての援助を受信することを期待して、彼／彼女の考えて幅広いネットに着目することから始める状況を考える。すると、ユーザは、彼／彼女が考えているネットが入力された最初の検索文字列によってどのくらい大きく定義されるかをシステムに告げることができる。最終的に１つのレコードが求められるにもかかわらず、ユーザが大量のレコードを生成することを文字列に対して期待していると検索処理が認識する場合、検索処理は、ユーザが最初に検索を拡張するのに役立ち、次いで落とすべき結果群を削除する弁別を実行するのを可能にする。
【００１８】
タスクモデルは予想されるレコード数を指定する必要が無いことに注意。未知数の結果が含まれている場合、システムは、（図３Ｄ乃至３Ｆ及び付属テキストに示されるような技術を用いて）検索の拡張を試みることから始め、次いで弁別物を選択することによってそれに焦点を絞るようにすることも可能である。
【００１９】
工程Ｓ２５において識別される弁別物は、様々な方法によって導かれ得る。例えば、返された選択群を用いて、返されたレコード群における各語の頻度を示すヒストグラムが生成され得る。最も高い識別力を有する複数の語が表示され、ユーザがその中の１以上を選択できるようにしてもよい。例えば、ユーザが、彼／彼女が知らない特定の品種に関する情報を見つけようとして、ブーリアン（Ｂｏｏｌｅａｎ）問い合わせ：「犬」且つ「ファー（ｆｕｒ）又は毛（ｈａｉｒ）」且つ「カーリー（ｃｕｒｌｙ）又はウェイビィ（ｗａｖｙ）」を入力するとする。ユーザが持っている上記品種に関する唯一の情報は、その品種は巻き毛（ｃｕｒｌｙ ｆｕｒ）を有することである。ユーザは、彼／彼女が探している特定のものを示す少数の応答を指定するタスクモデルを入力してもよく、多くの望まれない一致結果を問い合わせに期待してもよい。
【００２０】
例えば、検索によって返されたレコードが、様々な品種についての情報を含み、そのほとんどが特定の品種に着目している。最大ヒット頻度を有する語は、ユーザがあるレコード・クラスは所望せず、あるクラスは所望することを検索エンジンへ示すのに用いることが可能ないくつかの情報を提供してもよい。よって、例えば、「小さい」、「大きい」、「薄い」、及び「重い」などの共通記述子が返されてもよい。ユーザは、選択されたレコードを閲覧するのに便利であると思われる数まで削減するために、それらの中から選択を行うことができる。この処理を増強するために、ユーザ・インターフェースは、元の結果群におけるヒット数を表示してもよい。この数は、任意の提案された弁別物を元の問い合わせと組み合わせたものであり、組み合わせの効果は、この弁別された語を用いて、新しい問い合わせとして生成される。後者の例に対して、ユーザが問い合わせ：「薄い且つ小さい」を入力し始めるものとする。ディスプレイは、各語が加えられた時に効果を示し得る。これは、検索問い合わせが入力された時に返される結果数が連続的に更新される、Ｆｏｌｉｏ ｃｏｒｐｏｒａｔｉｏｎによるＦｏｌｉｏ Ｂｏｕｎｄ Ｖｉｅｗｓ（Ｒ）の作動方法と同様である。
【００２１】
このようなシンプルな弁別の問題は、このような語は、元の検索問い合わせにおける語に付いていてもよい。換言すれば、それらは、返された結果のほとんどについて共通であり、よって結果の中から良好に弁別できない。より望ましいものは、返されたレコードの大部分を分割する高い確率を有する弁別物である。より良い弁別物を識別する１つの方法は、元の問い合わせには含まれていないが元の問い合わせの語であって関連性があると推定する語と関連すると見られる語の共通例を探すことである。関連性は、例えば語の相互類似性、又は（例えば、検索問い合わせ語を修正する形容詞を識別する）文法解析などによって推定されてもよい。ここで、最高の識別力と共に現れる複数の候補弁別物をユーザに提示し、ユーザがその中から選択するようにすることもできる。
【００２２】
前述の２つのアプローチに対する改良は、返された結果群を少数のグループへ分割するための弁別物をそれぞれの能力に基づいて選択することである。これを行う１つの方法は、ヒストグラム手順によって導かれたものなどの高ヒット数の候補弁別物群を取り、それらの中のいずれが取り出された結果のわずかしか現れないが他のものには目立って欠けている「重要な」（例えば、レコード内での発生頻度、タイトル内での使用などから推定された重要性）語かを判断することである。すなわち、その語は、一部のレコードでは重要であるが、すべてのレコードに登場するわけではない。上記カーリーヘアーの犬の品種の例では、レコードが関連する品種の名前は品種に関するレコードにおいては重要であり、品種と無関係なレコードには現れない。すると、検索エンジンは、そのようなその多くが品種名を含むかもしれない弁別物のリストを示す。
【００２３】
ここで、図３Ｃ及び４を参照する。通常、ユーザがデータベースを検索する際、問い合わせ窓が適切なユーザ・インターフェース５８（図４）に生成される。このユーザ・インターフェース５８は、図３Ｃに示すようなディスプレイ２３０上の外観３０５を有し得る。ユーザは検索文字列３１０を定義するキーワード及び演算子などの記号を入力若しくは選択する。検索文字列３１０は、特定の問い合わせを生成するのに用いられる。この問い合わせは、次いで、データベース３０からのデータをフィルタリング及び閲覧するために表示／閲覧処理４０へ転送され得るフィルタリング基準を生成するために、検索エンジン処理５９によって用いられる。取り出されたデータが表示されることが最終的な結果である。
【００２４】
ここで、図３Ａ及び３Ｂを参照する。上記処理を改善し、ユーザが現検索用のタスクモデルをも示すことを考える。検索ＵＩ処理５８において、いくつの結果をユーザが欲するか、及び、ちょうど入力された検索文字列によっていくつの結果が返されると予測されるか、をユーザから要求するための問い合わせが生成される。これは、図３Ａに示すようなラジオ・ボタンを用いて選択することによっても、図３Ｂに示すような数字データを入力することによっても為され得る情報が既知でないことを示すオプションを提供してもよい。
【００２５】
例示的シナリオは以下の通り。ユーザは、多くの結果又は少し（若しくは１つ）の結果のいずれかを望むが、ユーザは入力した問い合わせが多くのヒット数を産むと予想すること述べるタスクモデルを入力する。例えば、ユーザが何百という書籍を執筆している人として知られている作家の名前を入力したとする。この例において、ユーザは、特定の１つだけを探してもよい。検索が少ないヒットを返す場合、システムは検索を広げるためのいくつかの選択肢をユーザに与えてもよい。例えば、ユーザが作家の名前を短縮形で入力した場合、システムはそれを認識し、正式名も使えることをユーザに提案することによって検索を拡張することを提供することもできる。例えば、ユーザが「ベッキー・ワーグナー」と入力したとする。本システムは、レベッカを検索に加えることを提案し得る。別の例は類義語の使用を含み得る。天象に関する記事を検索する人には、返された結果が予想より少なかった場合に、「宇宙学」、「ブラックホール」、「ビッグバン」などの語が提供されるかもしれない。
【００２６】
データベースからのデータを閲覧する別の方法は、直接的に表示／閲覧処理４０を通じた方法である。例えばシステム上をチューニングし、各チャネルについてその時点での番組を見ることによってユーザがデータベースのデータを閲覧する時、彼／彼女の閲覧行動は、タスクモデル推定エンジン処理５６とプロファイル・エンジン処理５３とによって連続的に監視されてもよい。相互作用データは、ユーザの希望を推定する両処理によって用いられる。閲覧の選択、詳細の選択、繰り返し閲覧されるものを提供しているチャネルなどからユーザの趣向について推定することによって、システムはそれに応じたプロファイル・データ（プロファイル・データベース５０に保存される）を生成してもよい。
【００２７】
他の既知システムにおいて、同じプロファイル・データが閲覧を高性能化するために生のデータベース・データをフィルタリングし、並び替えるのに用いられてもよい。例えば、この機能は、プロファイル・データが閲覧用データをフィルタリングするＵＩ４０処理によっても用いられるように、本発明と組み合わせられてもよい。
【００２８】
プロファイル・エンジン処理５３は、ユーザが図３Ｃのユーザ・インターフェースなどを通じて明確な検索語を入力する必要が常に必要ではなくなるように、関連したフィルタリング基準を導くのに用いるデータを保存している。タスクモデル推定エンジン処理５６は、ユーザが現在手助けを必要としているか否かを推定し、最も適切なタスクモデルを推定する相互作用動作データを使用する。
【００２９】
推定処理は、多くの形を採り得る。シンプルな例は、あるレコードに関連して特定のアクションが発生したときに重要度の値をそのレコードに相互に関連付ける。例えば、ユーザは、ＥＰＧを閲覧中により詳しい情報を取得するために特定のレコードを選択してもよい。重要度の値は、更なる情報を要求するアクションに関連付けられ、データベースにおいて日時、平日若しくは週末などの他の情報と共に特定のレコードに相互に関連付けられる。更に、ユーザがレコードを見るのに費やした時間（それを通り過ぎて素早くスキップした場合を除く）が値に関連付けられてもよい。この情報は、ユーザが実行中のタスク（ＥＰＧの閲覧）を推定し、何に興味があるのかを推定するのに直接的に用いられてもよい。例えば、ユーザは、閲覧中に特定の番組群の詳細を表示させることを選んでもよい。閲覧が続けられる時、番組群は、詳細を閲覧するために選択された番組群における特定の共通する特徴を識別するのに十分な程度に大きくなってもよい。これに対する応答として、ＵＩ処理は、例えばスポーツ番組などのユーザが探しているものの確認を要求するピクチャ・イン・ピクチャ・ウィンドウを生成することができる。ＵＩ要素は、いくつのレコードが探されるか、又は、探しているものに対応するかもしれない特定の重要なスポーツ放送をいくつ提案するかを尋ねることができる。それは、更に、その行動パターンにフィットする１以上のタスクモデルを推定し得る。
【００３０】
図６を参照する。タスクモデルの別の例は、明確に定義されたタスクモデルに加えて若しくは代わりに環境データ若しくはユーザの行動から導かれるタスクモデルである。工程Ｓ５０において、ユーザは、問い合わせを入力するか、或いはデータ（例えば図２に表示されたＥＰＧスクリーンなど）を閲覧する。工程Ｓ５５において、タスクモデルは、ユーザの行動や、日時、曜日、休日、重要日付、及び／若しくはユーザ・プロファイル・データベース５０に保存されたデータなどの環境変数に基づいて、本システムによって推定される。例えば、ユーザが録画するためのスポーツ番組を検索中であり、且つ、近い将来スーパーボール若しくはワールドカップ大会が開かれる場合、これらは提案としてユーザへ提供されてもよい。別の方法として、本システムは、ユーザがこのような提案を提供する前に特定のイベントを検索中であるか否かを尋ねてもよい。工程Ｓ６０において、問い合わせは、タスクモデル及びあらゆる他の問い合わせデータに基づいて導かれ、その結果は工程Ｓ８０において表示される。
【００３１】
例えば、ユーザはスポーツ・チャネルを閲覧中であるものとする。本システムは、ユーザが現在でない時間を見ていることを検知してもよい。本システムは、このようにタスクモデルを推定することも可能であり、及び／若しくは、ユーザに質問を問うことによってタスクモデルを定義若しくは改良することをユーザに要求することもできる。例えば、本システムは、ユーザが将来の且つスポーツイベントのみの放送に関する詳細な情報を要求したという事実に基づいて、ユーザは将来のスポーツ・チャネルを検索中であると裁定することができる。本システムは、近い将来有効となるすべてのスポーツイベントを提示することを提供することができる。別の方法として、本システムは、ユーザに彼／彼女が興味を持っている時間範囲はいつかをユーザに問い、それに応じて結果を表示してもよい。本システムは、ユーザが特定のイベントを探しているか否かを問い、ネットワーク推薦（例えば、ネットワーク・バナー・イベントがＥＰＧデータベースにおいて有効であってもよい）に基づいて、或いは、検索を向上させるための問い合わせ語を催促することによって、いくつかのオプションを提供することも可能である。
【００３２】
タスクモデルの一般的アプローチは、ユーザが何を探しているかを判断するために、直接的に若しくは受動的に決定される。この場合、本システムは、ユーザが取り出した検索結果と比較するための何かを有する。良く知られているように、複雑なデータ群の検索を行う処理には多くのフラストレーションが伴い得る。上記システムは、検索結果と比較するための情報若しくは実行前に検索を改良するための情報をユーザに指定させること若しくは本システムに推定させることが可能なメカニズムを提供する。図示するように、これは、別の検索語を提供することによってユーザに彼／彼女の検索を改良する機会を与えるインテリジェント・アシスタントの基礎として用いられ得る。
【００３３】
ここで図４及び７の別の実施形態を参照する。ユーザは、工程Ｓ５において、タスクモデルを選ぶか又は入力する。このタスクモデルは、そのユーザに対して自動的に選択されてもよく、推定されてもよく、そのユーザによって直接的に指定されてもよい。例えば、閲覧者がデータベースを閲覧している時、或いはチャネル若しくはＥＰＧを閲覧している時、本システムは、そのタスクが直ちに見るショーを見つけることであることを推定するかもしれない。このような行動中、タスクモデル推定エンジン５６及びプロファイル・エンジン５３の両者は、相互作用動作を監視する。ユーザがＥＰＧディスプレイの電源を入れ、彼／彼女が検索したい旨指示すると、異なるタスクが推定されるかもしれず、或いはユーザがリストからタスクモデルを選択するように求められ得る。図７を参照する。ユーザは、検索したい旨指示したものとする。ユーザは、工程Ｓ５において、図３Ａ及び３Ｂに示したようなＵＩ要素を用いてタスクモデルを選択する。次いで、ユーザは、工程Ｓ１０において、図３Ｃに示したようなＵＩ要素を用いて問い合わせを選択若しくは入力する。次いで、工程Ｓ２０において、ユーザによって送信された問い合わせ文字列から問い合わせが生成され、この問い合わせが送信され、工程Ｓ２０において検索結果が取り出される。この結果は、工程Ｓ２５において、タスクモデルと比較される。工程Ｓ４５において、結果がタスクモデルと一致すれば、その結果は、工程Ｓ４０において表示される。工程Ｓ４５において、結果が期待されるものと一致しなければ、工程Ｓ２２において問い合わせ修正戦略が選択され、工程Ｓ１５において確認される。前述のように、この問い合わせ修正戦略は、結果が多すぎる場合に弁別物を識別するのに用いられることが可能であるか、或いは、結果が少なすぎる場合に基準を拡張することを提案するのに用いられることが可能である。
【００３４】
結果が少なすぎる場合、検索戦略は、拡張される必要がある。図３Ｄを参照する。これは、図示するような選択インターフェースを通じて為され得る。検索を拡張することを要求する一般的な選択は、検索を如何に拡張するかの判断をシステムに任せている。例えば、システムは、類語辞典拡張、綴り字異形拡張、語の削除などの別の拡張装置を表示し、ユーザに検索を拡張するのにいずれの装置を用いるかを選択可能にする。図３Ｆを参照する。システムによって代替語が一語ごとに提案されており、ユーザは語（Δ）を提案された語（＋）へ変更してもよく、代替語（＋）を検索に加えてもよい。図３Ｆを参照する。語「ベッキー」は、レベッカを含むように拡張され、語「法」は「法律」を含むように拡張される。このシステムは、類似のスペルを有する別の名前（「ウィンガー」）を「ワーグナー」についての代替物若しくは置換物として提案する。
【００３５】
図４を参照する。閲覧／表示処理４０と相互作用しているユーザの相互作用行動４４は、プロファイル・データベース５０を転送する結果４２を生成するプロファイル・エンジン処理５３と、ユーザが必要とするものを予想するタスクモデル推定エンジン５６とによって連続的に監視される。タスクモデル推定エンジン５６は、ユーザを検索文字列の入力を適宜可能にする検索４６ＵＩ処置５８へ切り替えるように誘うことができる。それは、更に、プリファレンス・データから自動的に問い合わせ４８を生成し、結果表示／閲覧処理４０によって用いられるフィルタリング基準を生成するために検索エンジンへ送信してもよい。これは、ユーザの閲覧中にタスクモデル推定エンジン５６が（予測エンジン処理４５を通じて供給されたプリファレンス・データと組み合わせられて）閲覧行動について例えばその日に見るスポーツ番組を探しているなどの何かした特定のパターンを示唆するパターンを識別すると、起こる。このように、問い合わせを生成するためのデータ及びそれに一致する表示結果を自動的に生成するためのデータは十分にある。図４における処理は、ユーザに様々なステージを中断させることが好ましい。そして、ユーザがシステムによってスポーツ番組へと絞られた表示を欲しない場合には、システムは、まずヘルプを提供してもよく、フィルタリングを行う前にユーザがその自動機能を引き返す若しくは無効にすることができるようにしてもよい。タスクモデル推定エンジン５６は、更に、ユーザが見たいものについての推定を為すのに十分なデータを持っていない場合に、ユーザからのタスクモデルを助けの提供として要求し得る。その場合、ユーザを検索ＵＩ処理５８へ切り替えることを提案するかもしれない。これは、結果表示／閲覧ＵＩ処理４０からと同様に、ユーザによるリクエストによって直接的にも４６発動され得る。
【００３６】
ここで、図８を参照する。ユーザは、工程Ｓ１１０において、テレビを使い始め、ライブＴＶを見るか若しくはＥＰＧを使うことのいずれかを選ぶ。ユーザがＥＰＧを使うことを選んだ場合、ユーザは、ＥＰＧを閲覧するか若しくはそれを検索することができる（工程Ｓ１１５）。ユーザがＥＰＧを検索することを選んだ場合、工程Ｓ１２０において、ユーザによってタスクモデルが選択され、工程Ｓ１５２において問い合わせが入力され、工程Ｓ１５５において、検索が送信され、結果が取り出される。次に、工程Ｓ１６０において、結果がタスクモデルと比較される。結果がタスクモデルと一致した場合（Ｓ１６５）、工程Ｓ１７０において、結果が表示される。結果がタスクモデルと一致しなかった場合（Ｓ１６５）、工程Ｓ１２２において問い合わせ修正戦略が選択され、工程Ｓ１１６において、この戦略がユーザによって承認若しくは修正される（例えば、図３Ｄ乃至３Ｆ及び付属説明を参照）。工程Ｓ１１０において、ユーザがライブＴＶを見ることを選んだ場合、本システムは、工程Ｓ１３０において、一レコードのタスクモデルを推定し、工程Ｓ１４７において、ユーザの相互作用行動がユーザを助けるための介入を保証するか否かを判断するために、ユーザの相互作用行動を観察する。１以上の基準は、例えば、ユーザが検索に費やした時間でもよく、詳細な情報のために選択されたアイテム数でもよく、閲覧のランダム性でもよく、他のカテゴリからのレコードを除外することなく１つのカテゴリからのアイテムの詳細を表示するなどの非効率の目印でもよい。この基準が満たされれば、本システムは、２つのオプションを提供することによって助けを提案する。第一のオプションは、ユーザを通常検索システムへ連れて行くことである。第二のオプションは、プロファイル・データベース５０におけるプリファレンス・データを依拠することによって、完全検索無しでユーザを支援ことを試みることである。第三のオプションは、単にユーザがヘルプを拒否することである。工程Ｓ１４７において、第一のオプションが選択されると、ユーザは工程Ｓ１２０から始まる前に概説される通常検索工程へ導かれる。第二のオプションが選ばれると、これらオプションを制限するための有益的な問い合わせを生成するのに十分な情報が提示されているか否かを知るために、プロファイル・データベースが照会される（Ｓ１４０）。例えば、今が木曜日の夜であるとし、ユーザは木曜日の夜には欠かさず様々なホームコメディを見ているものとする。本システムがプロファイル・データベースに関連データを見つけると（工程Ｓ１４５）、本システムは、工程Ｓ１３２において、問い合わせを生成し、工程Ｓ１５５において、前のフローを入力する。本システムが問い合わせを生成するのに十分なデータを見つけることができなかった場合、工程Ｓ１４８において、本システムは検索を実行するオプションをユーザに提供し、ユーザがそれを実行したい旨指示すれば、工程Ｓ１２０へ進み、そのような指示がなければ、ユーザは更なる相互作用無しに閲覧若しくはチャネル・サーフィンを続けることができる。別の方法として、処理全体が先頭から再スタートすることも可能である。
【００３７】
上記議論において、ユーザは、予想されるレコード数を数字形式で示し、この数は検索によって返された結果群と比較されることを前提としているが、実際の処理はこのように具体的である必要はないことに注意。結果群は、問い合わせと正確に一致するレコードを多く含み得るが、検索語が重要な語（例えば、レコード中のヒット頻度、その語が「フロント・ページ」語であるか否か、などによって判断される）でない劣悪な一致である。よって、弱いヒットのレコードは無視され、予想される結果と比較された時に予想されたレコード数が予想された数に近いが、その結果が多くの弱いヒットを含む場合、結果は縮小されずに拡張されてもよい。この比較は、いずれにしても厳格である必要はない。それは、ファジー集合比較であってもよい。
【００３８】
本発明は、上記例示的実施形態の詳細に限定されるものではなく、本発明は、その意図若しくは基本的特性を逸脱することなく、他の特定の形式で実施されることも可能であることは当業者には明らかである。よって、本実施形態は、あらゆる点で例示的且つ非限定的であると考えられるため、上記説明ではなく付属の請求項によって示された本発明の範囲、及び、請求項と等価の意義及び範囲内に収まるすべての変更は、本発明に包含されることが意図されている。
【図面の簡単な説明】
【図１】
本発明が実施され得るハードウェア・システムの例である。
【図２】
本発明の電子番組表用途の構成要素を構成し得るユーザ・インターフェースの表示部を示す。
【図３Ａ】
本発明の一実施形態に係るタスクモデルを入力するのに用いられるユーザ・インターフェース・ダイアログを示す。
【図３Ｂ】
本発明の一実施形態に係るタスクモデルを入力するのに用いられるユーザ・インターフェース・ダイアログを示す。
【図３Ｃ】
本発明の一実施形態に係る問い合わせ入力用ユーザ・インターフェース・ダイアログを示す。
【図３Ｄ】
本発明の一実施形態に係る結果及び／若しくはタスクモデルに基づいて検索問い合わせを修正するのに用いられるユーザ・インターフェース・ダイアログを示す。
【図３Ｅ】
本発明の一実施形態に係る結果及び／若しくはタスクモデルに基づいて検索問い合わせを修正するのに用いられるユーザ・インターフェース・ダイアログを示す。
【図３Ｆ】
本発明の一実施形態に係る結果及び／若しくはタスクモデルに基づいて検索問い合わせを修正するのに用いられるユーザ・インターフェース・ダイアログを示す。
【図４】
本発明の一実施形態における処理とデータ保存との間のデータの流れを示すブロック図である。
【図５】
本発明を用いたデータベースを検索する際に採られる工程を示すフローチャートである。
【図６】
本発明の別の一実施形態に係るデータベースを検索する際に採られる工程を示すフローチャートである。
【図７】
本発明の更に別の一実施形態に係るデータベースを検索する際に採られる工程を示すフローチャートである。
【図８】
本発明の更に別の一実施形態に係るデータベースを検索する際に採られる工程を示すフローチャートである。

Claims (16)

1. データベースを検索する方法であって、
   ユーザから第一の検索問い合わせを受信する工程と、
   前記検索問い合わせに基づく前記データベースのフィルタリングの結果と比較され得る検索された所望結果の内容を受信する工程と、
   前記内容を前記検索問い合わせに基づく前記データベースのフィルタリングの結果と比較する工程と、
   前記比較工程の結果に応じて、前記ユーザから別のデータベースを受信する工程と、
   前記別のデータの受信工程に応じて、前記第一の検索問い合わせ及び前記別のデータに基づいて第二の検索問い合わせを生成する工程と、を有する方法。
2. 請求項１記載の方法であって、
   前記検索は、更に、
   前記比較工程の後に、前記フィルタリングの結果に応じて該結果から少なくとも１つの弁別語を識別する工程を有し、
   前記弁別語は、前記結果の一部のレコードには存在するが前記結果の他のレコードには存在しないという特性を有する前記フィルタリング結果中の語である、ことを特徴とする方法。
3. 請求項２記載の方法であって、
   前記弁別語は、前記一部のレコードにおける他の語と比較した相対的重要性の判断に応じて選択されることを特徴とする方法。
4. データベースを検索する方法であって、
   検索語以外の情報を含む検索タスク定義を受信する工程と、
   検索語を受信する工程と、
   前記検索結果を分析し、前記タスク定義に応じて、前記結果の一部のレコードを前記結果の他のレコードから弁別することが可能な前記結果中に現れる語を識別する工程と、を有する方法。
5. 請求項４記載の方法であって、
   前記タスク定義は、検索されたレコード数を示すことを特徴とする方法。
6. 請求項４記載の方法であって、
   前記タスク定義は、
   データベースを閲覧するためのコマンドを入力する工程と、
   前記入力工程に基づいて戦略を導く工程と、によって導かれることを特徴とする方法。
7. データベースを検索する方法であって、
   検索定義と一致すると予想されるレコード数を示す第一のデータを受信する工程と、
   前記第一のデータを前記検索定義を実際に一致するレコード数を示す第二のデータと比較する工程と、
   前記第一のデータが前記第二のデータより大きい場合に、前記検索定義をより大きいレコード数を導くように拡張する工程と、を有する方法。
8. 請求項７記載の方法であって、
   前記第一のデータが前記第二のデータより小さい場合に、前記検索をより少ないレコード数を導くように削減する工程を更に有することを特徴とする方法。
9. データベースを検索する方法であって、
   検索定義と一致すると予想されるレコード数を示す第一のデータを受信する工程と、
   前記第一のデータを前記検索定義を実際に一致するレコード数を示す第二のデータと比較する工程と、
   前記第一のデータが前記第二のデータより小さい場合に、前記検索定義をより少ないレコード数を導くように削減する工程と、を有する方法。
10. 請求項７記載の方法であって、
    前記第一のデータが前記第二のデータより大きい場合に、前記検索をより大きいレコード数を導くように拡張する工程を更に有することを特徴とする方法。
11. データベースを検索する装置であって、
    データ・ストアと、出力装置と、入力装置と、を有するプログラム可能コントローラを有し、
    前記コントローラは、
    前記入力装置を通じて、検索定義を受信し、
    前記入力装置を通じて、前記検索定義と一致すると予想される前記データベース中のレコード数を示すタスク定義を受信し、
    前記検索定義と実際に一致するレコード数を判断し、
    前記タスク定義によって示された数と前記検索定義と実際に一致した数との差異に応じて、前記検索定義に対して拡張又は縮小のいずれかを行う、ようにプログラムされている装置。
12. データベースを検索する方法であって、
    検索定義を受信する工程と、
    前記検索定義を拡張する方法を識別し、前記方法のうちの少なくとも１つを選択するユーザ入力を受信する工程と、
    前記ユーザからの入力を受信する工程の結果に応じて、前記検索定義を拡張する工程と、
    前記拡張工程の結果に応じて、データベースからレコードを取り出す工程と、を有する方法。
13. 請求項１２記載の方法であって、
    前記識別工程は、前記検索定義における語と似た意味を有する語を識別すること、又は、前記検索定義における語と似たスペルを有する語を識別することのいずれかを含むことを特徴とする方法。
14. データベースを検索する方法であって、
    検索定義を受信する工程と、
    前記検索定義を拡張する方法を識別し、前記方法のうちの少なくとも１つを選択するユーザからの入力を受信する工程と、
    ユーザからの入力を受信する工程の結果に応じて、前記検索定義を削減する工程と、
    前記拡張工程の結果に応じて、データベースからレコードを取り出す工程と、を有する方法。
15. 請求項１４記載の方法であって、
    前記識別工程は、一致レコードに現れる語であって、前記一致レコードを弁別する前記検索定義と一致する語を識別することの少なくとも１つを含むことを特徴とする方法。
16. データベースを検索する装置であって、
    データ・ストアと、出力装置と、入力装置と、を有するプログラム可能コントローラを有し、
    前記コントローラは、
    前記入力装置を通じて、検索定義を受信し、
    前記入力装置を通じて、前記検索定義と一致すると予想される前記データベース中のレコード数を示すタスク定義を受信し、
    前記検索定義と実際に一致するレコード数を判断し、
    前記タスク定義によって示された数及び前記検索定義と実際に一致した数が実質的に異なるか若しくはほぼ同等であるかに応じて、前記検索定義に対して拡張又は縮小のいずれかを行う、ようにプログラムされている装置。

Images