IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ベベオ, インコーポレイテッドの特許一覧

特許7371155会話型相互作用におけるユーザの意図の曖昧性の解消
<>
  • 特許-会話型相互作用におけるユーザの意図の曖昧性の解消 図1
  • 特許-会話型相互作用におけるユーザの意図の曖昧性の解消 図2
  • 特許-会話型相互作用におけるユーザの意図の曖昧性の解消 図3
  • 特許-会話型相互作用におけるユーザの意図の曖昧性の解消 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-20
(45)【発行日】2023-10-30
(54)【発明の名称】会話型相互作用におけるユーザの意図の曖昧性の解消
(51)【国際特許分類】
   G06F 16/90 20190101AFI20231023BHJP
【FI】
G06F16/90 100
【請求項の数】 20
(21)【出願番号】P 2022037041
(22)【出願日】2022-03-10
(62)【分割の表示】P 2019231103の分割
【原出願日】2013-07-30
(65)【公開番号】P2022071194
(43)【公開日】2022-05-13
【審査請求日】2022-03-10
(31)【優先権主張番号】61/677,895
(32)【優先日】2012-07-31
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】13/801,812
(32)【優先日】2013-03-13
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】515018105
【氏名又は名称】ベベオ, インコーポレイテッド
(74)【代理人】
【識別番号】100078282
【弁理士】
【氏名又は名称】山本 秀策
(74)【代理人】
【識別番号】100113413
【弁理士】
【氏名又は名称】森下 夏樹
(74)【代理人】
【識別番号】100181674
【弁理士】
【氏名又は名称】飯田 貴敏
(74)【代理人】
【識別番号】100181641
【弁理士】
【氏名又は名称】石川 大輔
(74)【代理人】
【識別番号】230113332
【弁護士】
【氏名又は名称】山本 健策
(72)【発明者】
【氏名】ムラリ アラバムダン
(72)【発明者】
【氏名】ラケシュ バルベ
(72)【発明者】
【氏名】シャシクマール ベンカタラマン
(72)【発明者】
【氏名】ビニート アガーワル
(72)【発明者】
【氏名】アブヒジット サーバルカル
(72)【発明者】
【氏名】ガネーシャ ラマムーシー
(72)【発明者】
【氏名】アフマド ニザム モハイディーン パスルディーン
(72)【発明者】
【氏名】ケー チナ シュリーニバスル レディー
【審査官】齊藤 貴孝
(56)【参考文献】
【文献】国際公開第2011/088053(WO,A2)
【文献】米国特許出願公開第2009/0198488(US,A1)
【文献】米国特許出願公開第2005/0080613(US,A1)
【文献】米国特許出願公開第2002/0059069(US,A1)
【文献】米国特許出願公開第2001/0049688(US,A1)
【文献】米国特許第06272455(US,B1)
【文献】国際公開第2012/088590(WO,A1)
【文献】二宮 和弘、外3名,コミュニケーション支援のための会話内容の図式化ツールの開発,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2005年01月14日,第104巻,第565号,p.37-41
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
(57)【特許請求の範囲】
【請求項1】
コンピュータシステムによって実行される方法であって、前記コンピュータシステムは、制御回路とメモリとを備え、前記方法は、
前記制御回路が、ユーザから第1の入力を受信することであって、前記第1の入力は、第1の組のエンティティを識別することを意図されている、ことと、
前記制御回路が、前記第1の入力に基づいて、前記第1の組のエンティティを提示することと、
前記制御回路が、前記第1の組のエンティティを提示することに応答して、前記ユーザから第2の入力を受信することであって、前記第2の入力は、第2の組のエンティティを識別することを意図されている、ことと、
前記制御回路が、前記第2の入力の曖昧性レベルがしきい値を超えているかどうかを決定することと、
前記第2の入力の前記曖昧性レベルが前記しきい値を超えていることを決定することに応答して、
前記制御回路が、前記第2の組のエンティティの各エンティティを記述するメタデータを受信することと、
前記制御回路が、構造的な知識を受信することであって、前記構造的な知識は、前記第1の組のエンティティの各エンティティと前記第2の組のエンティティの各エンティティとの間の意味論的なリンクを示す、ことと、
前記制御回路が、前記第2の組のエンティティの前記メタデータおよび前記構造的な知識に基づいて、曖昧性が解消された入力を決定することと、
前記制御回路が、前記曖昧性が解消された入力に基づいて、前記第2の組のエンティティを選択することと
を含む、方法。
【請求項2】
前記曖昧性が解消され決定された入力は、前記ユーザの意図を示し、前記曖昧性が解消された入力は、データベース内に記憶されている、請求項1に記載の方法。
【請求項3】
前記方法は、
前記制御回路が、前記構造的な知識に基づいて、前記第2の組のエンティティを順序付けることと、
前記制御回路が、前記順序付けられた第2の組のエンティティのエンティティが前記曖昧性が解消された入力に一致することを述べる自然言語メッセージを構築することと、
前記制御回路が、前記自然言語メッセージを含む前記ユーザに対する通知を表示のために生成することと
をさらに含む、請求項1に記載の方法。
【請求項4】
前記方法は、
前記制御回路が、少なくとも前記第1の組のエンティティおよび前記構造的な知識が前記第2の入力の曖昧性を解消しないことを決定することに応答して、
前記制御回路が、曖昧性を解消するための質問を前記ユーザに提示することと、
前記制御回路が、前記曖昧性を解消するための質問に応答して前記ユーザから第3の入力を受信することと、
前記制御回路が、前記第3の入力にさらに基づいて曖昧性が解消された入力を決定することと
をさらに含む、請求項1に記載の方法。
【請求項5】
前記方法は、
前記制御回路が、前記第1の組のエンティティおよび前記構造的な知識が前記第2の入力の曖昧性を解消しないことを決定することに応答して、前記制御回路が、前記第2の入力に対して複数のオプションが存在するという前記ユーザに対する通知を表示のために生成すること
をさらに含む、請求項1に記載の方法。
【請求項6】
前記曖昧性が解消された入力は、ユーザ選好および前記ユーザの場所および前記第2の入力の時間に基づいてさらに決定される、請求項1に記載の方法。
【請求項7】
前記曖昧性が解消された入力を決定することは、
前記制御回路が、ユーザ選好が利用可能であるかどうかを決定することと、
前記制御回路が、前記ユーザ選好が利用可能であることを決定することに応答して、前記ユーザ選好に基づいて、前記曖昧性が解消された入力を決定することと
をさらに含む、請求項1に記載の方法。
【請求項8】
前記曖昧性が解消された入力を決定することは、ユーザ履歴にさらに基づく、請求項1に記載の方法。
【請求項9】
前記方法は、
前記制御回路が、前記ユーザから第4の入力を受信することであって、前記第4の入力は、第3の組のエンティティを識別することを意図されている、ことと、
前記制御回路が、特定のエンティティを記述するメタデータを受信することと、
前記制御回路が、前記第4の入力の曖昧性レベルがしきい値を超えているかどうかを決定することと、
前記第4の入力の前記曖昧性レベルが前記しきい値を超えていることを決定することに応答して、
前記制御回路が、前記構造的な知識および前記第1の組のエンティティのうちの少なくとも1つに基づいて、曖昧性が解消された入力を決定することと、
前記制御回路が、前記曖昧性が解消された入力と前記第4の入力を記述する前記メタデータとを比較することに基づいて、前記第3の組のエンティティを選択することと
をさらに含む、請求項1に記載の方法。
【請求項10】
前記第2の組のエンティティを選択することは、
前記制御回路が、前記曖昧性が解消された入力と前記第2の組のエンティティの各それぞれのエンティティを記述する前記メタデータとを比較することと、
前記制御回路が、前記比較することに基づいて、前記第2の組のエンティティのいずれのエンティティも前記曖昧性が解消された入力を満たしていないことを決定することと、
前記制御回路が、前記曖昧性が解消された入力の一部を満たすエンティティのサブセットを選択することと
を含む、請求項1に記載の方法。
【請求項11】
システムであって、前記システムは、
制御回路であって、前記制御回路は、
ユーザから第1の入力を受信することであって、前記第1の入力は、第1の組のエンティティを識別することを意図されている、ことと、
前記第1の入力に基づいて、前記第1の組のエンティティを提示することと、
前記第1の組のエンティティを提示することに応答して、前記ユーザから第2の入力を受信することであって、前記第2の入力は、第2の組のエンティティを識別することを意図されている、ことと、
前記第2の入力の曖昧性レベルがしきい値を超えているかどうかを決定することと、
前記第2の入力の前記曖昧性レベルが前記しきい値を超えていることを決定することに応答して、
前記第2の組のエンティティの各エンティティを記述するメタデータを受信することと、
構造的な知識を受信することであって、前記構造的な知識は、前記第1の組のエンティティの各エンティティと前記第2の組のエンティティの各エンティティとの間の意味論的なリンクを示す、ことと、
前記第2の組のエンティティの前記メタデータおよび前記構造的な知識に基づいて、曖昧性が解消された入力を決定することと、
前記曖昧性が解消された入力に基づいて、前記第2の組のエンティティを選択することと
を行うように構成されている、制御回路と、
前記選択された一組のエンティティを表示のために提示するように構成されている入力/出力回路と
を備える、システム。
【請求項12】
前記曖昧性が解消され決定された入力は、前記ユーザの意図を示し、前記曖昧性が解消された入力は、データベース内に記憶されている、請求項11に記載のシステム。
【請求項13】
前記制御回路は、
前記構造的な知識に基づいて、前記第2の組のエンティティを順序付けることと、
前記順序付けられた第2の組のエンティティのエンティティが前記曖昧性が解消された入力に一致することを述べる自然言語メッセージを構築することと、
前記自然言語メッセージを含む前記ユーザに対する通知を表示のために生成することと
を行うようにさらに構成されている、請求項11に記載のシステム。
【請求項14】
前記制御回路は、
少なくとも前記第1の組のエンティティおよび前記構造的な知識が前記第2の入力の曖昧性を解消しないことを決定することに応答して、
曖昧性を解消するための質問を前記ユーザに提示することと、
前記曖昧性を解消するための質問に応答して前記ユーザから第3の入力を受信することと、
前記第3の入力にさらに基づいて曖昧性が解消された入力を決定することと
を行うようにさらに構成されている、請求項11に記載のシステム。
【請求項15】
前記制御回路は、
前記第1の組のエンティティおよび前記構造的な知識が前記第2の入力の曖昧性を解消しないことを決定することに応答して、前記第2の入力に対して複数のオプションが存在するという前記ユーザに対する通知を表示のために生成すること
を行うようにさらに構成されている、請求項11に記載のシステム。
【請求項16】
前記曖昧性が解消された入力は、ユーザ選好および前記ユーザの場所および前記第2の入力の時間に基づいてさらに決定される、請求項11に記載に記載のシステム。
【請求項17】
前記制御回路は、前記曖昧性が解消された入力を決定する場合に、
ユーザ選好が利用可能であるかどうかを決定することと、
前記ユーザ選好が利用可能であることを決定することに応答して、前記ユーザ選好に基づいて、前記曖昧性が解消された入力を決定することと
を行うようにさらに構成されている、請求項11に記載のシステム。
【請求項18】
前記曖昧性が解消された入力を決定することは、ユーザ履歴にさらに基づく、請求項11に記載のシステム。
【請求項19】
前記制御回路は、
前記ユーザから第4の入力を受信することであって、前記第4の入力は、第3の組のエンティティを識別することを意図されている、ことと、
特定のエンティティを記述するメタデータを受信することと、
前記第4の入力の曖昧性レベルがしきい値を超えているかどうかを決定することと、
前記第4の入力の前記曖昧性レベルが前記しきい値を超えていることを決定することに応答して、
前記構造的な知識および前記第1の組のエンティティのうちの少なくとも1つに基づいて、曖昧性が解消された入力を決定することと、
前記曖昧性が解消された入力と前記第4の入力を記述する前記メタデータとを比較することに基づいて、前記第3の組のエンティティを選択することと
を行うようにさらに構成されている、請求項11に記載のシステム。
【請求項20】
前記制御回路は、前記第2の組のエンティティを選択する場合に、
前記曖昧性が解消された入力と前記第2の組のエンティティの各それぞれのエンティティを記述する前記メタデータとを比較することと、
前記比較することに基づいて、前記第2の組のエンティティのいずれのエンティティも前記曖昧性が解消された入力を満たしていないことを決定することと、
前記曖昧性が解消された入力の一部を満たすエンティティのサブセットを選択することと
を行うようにさらに構成されている、請求項11に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
(関連出願の引用)
本願は、以下の特許出願の利益を主張する。これらの出願の内容は、参照により本明細書に引用される:
米国特許出願第13/801,812号(2013年3月12日出願、名称「Disambiguating User Intent in Conversational
Interaction System for Large Corpus Information Retrieval」);および
米国特許出願第61/677,895号(2012年7月31日出願、名称「Disambiguating User Intent in Conversational
Interaction System for Large Corpus Information Retrieval」)。
【0002】
(発明の分野)
本発明は、情報読み出しのために、会話型相互作用システムにおけるユーザの意図の曖昧性を解消する方法に関し、より具体的には、構造情報およびユーザ選好を使用する技法に関する。
【発明の概要】
【課題を解決するための手段】
【0003】
(関連技術および本発明の概要)
本発明は、大量のコーパス情報読み出しのために、「最適」かつ「知的」に、会話型相互作用システムにおけるユーザの意図/入力の曖昧性を解消する方法に関し、意図/入力は、以下の曖昧性、すなわち、(1)語彙的曖昧性(ユーザ入力に語彙的に一致する複数の適合する応答)、あるいは(2)曖昧性が時間的に存在する(時間属性に基づく複数の適合する応答)、または曖昧性が場所的に存在する(場所属性に基づく複数の適合する応答)、または曖昧性が任意のコンテンツ属性またはコンテンツ属性の組み合わせに存在する(ユーザによって指定されたコンテンツ属性/複数の属性に基づく複数の適合する応答)、またはユーザの要求に固有の非特定性から生じ、ひいては、複数の適合する応答をもたらす、単なる曖昧性(例えば、広義の意図の要求)である、意味論的曖昧性のうちの1つ以上を有する。本開示に説明される「最適」曖昧性解消方法の実装は、システムが、最小数の明確化質問を尋ね(理想的場合、いかなる質問も全く尋ねない)、ユーザの意図を理解することを可能にする。本開示に説明される「知的」曖昧性解消方法の実装は、ヒトが会話における曖昧性を明確にする方法と同様に、システムが、曖昧性解消やりとりを自然に行うことを可能にする。システムは、ドメイン特定構造知識、時間、ユーザの場所(利用可能である場合)、およびユーザ選好のシグネチャ(利用可能である場合)を利用して、最適かつ知的曖昧性解消を行う。本開示に説明される方法は、言語特定モジュールの助けを借りて、言語から独立し、複数の言語に適用されることができる。さらに、本明細書に開示される方法は、特に、リポジトリの所与のエンティティまたは概念が多くの方法で参照され得、同一の用語が、異なる意味のコンテキストで生じ得るという事実によって生じる、高度な意味論的曖昧性および衝突を伴う、大量のコーパス情報リポジトリに好適である。
【0004】
会話型システムの重要となる性能測定基準は、ユーザの意図/入力が曖昧ではないとき、その応答がユーザの意図に一致する程度ではなく、ユーザの意図/入力が曖昧性を有するとき、それに対応する方法である。優れた会話型システムは、その可能な応答方式のレパートリー内に、ユーザ入力/意図に曖昧性が存在する場合でも検索エンジンが結果を吐き出すであろうような多数の応答を吐き出す贅沢な機能を有していない。検索エンジンの場合、関連性のある順序において、曖昧な入力/意図に対する全結果を示すことは、優れた検索エンジンの特質として称賛されるであろう。会話型システムにおいて、曖昧なユーザ入力/意図に対して同一のアプローチを採用することは、Starbucksにおいて、単に、ユーザが、ぼんやりとしていて、ユーザが所望する特定の種類のコーヒー(例えば、Caffe Latte)を絞り込めないでいるのにもかかわらず、10種のコーヒ
ーの選択肢を並べ立てるような熱心な販売員との困惑した遭遇に匹敵するであろう。ここでは、販売員は、コーヒー(お茶ではない)が意図されていることを明確に理解しているが、販売員は、その意図に一致する多くの選択肢が存在する事実を心に留めていない。より機転が利く販売員は、おそらく、こう言うであろう「コーヒーの選択肢がたくさんありますが、選択肢を簡単にご説明しましょうか?」
本開示は、ユーザ入力に一致する複数の適合する応答(以下に記載の1つの例外を除く)が存在するシナリオを捉えるために、広義な意味において用語「曖昧性」を使用する。本開示において使用される用語「曖昧な」の意味の一例は、以下の例から理解され得る。優れた会話型システムは、ユーザの意図を理解し、質問に応じて、理想的には、1つのみの簡潔な応答であり得る、最も簡潔な標的応答を生成しようとするであろうが(例えば、質問「今夜soxは試合する?」は、red soxの試合の時間および場所を単に示す応答を生成し得る(ここでは、red soxは、ユーザのシグネチャから推測されている))、必ずしも、全ユーザ質問が単一応答を生成することを含意するわけではない。また、質問に対して複数の選択肢をもたらすことが準最適であろうことを含意するものでもない。例えば、ユーザが、「近くのStarbucksを教えて」と尋ねた場合、最良の応答は、ユーザの近くの全Starbuck結果がプロットされたマップを表示することであり、したがって、ユーザは、視覚的マップから容易に任意の1つを取り上げることができる。「近くのレストランを教えて」等のより広義な意図の要求の場合でも、マップ上に複数の応答を表示することが、システムが提供することができる最良応答である。
【0005】
意図は、これらの両場合において明確であるが、2つ以上ある場合、システムは、ユーザが気に入り得る特定のレストランが不明であるため、応答は、ある意味、「曖昧」である。ユーザ選好のシグネチャが存在する場合でも、他の応答からハイライトされる最も好ましいStarbucks/レストランで応答を生成し得る。前述のこれらの場合における複数の応答は、実際には曖昧な応答ではないが、全てユーザの意図に一致する(但し、ユーザは、この理由から、依然として、あるStarbucksまたはレストランを選定していなくてもよい)一連の「選択肢」である。用語「選択肢」は、ユーザが、1つのみの選択肢ではなく、複数の選択肢を意図したことを示すために、本明細書では、「応答」と区別して使用される(システムが、ユーザ選好のシグネチャを有していた場合でも、依然として、複数の「選択肢」をもたらすであろう)。別の例は、「Meryl Streepの映画を見せて」等の場合である。この場合、ユーザは、その中から「選定」するためのMeryl Streepの複数の映画を所望している。
【0006】
本開示に説明される方法は、曖昧性(または、複数の適合する応答)が、十分な信頼性を持って、ユーザの意図に一致することが把握され得る1つの明確な「選択肢」または一連の「選択肢」をもたらすことができないことから生じる場合に焦点を当てる。さらに、ユーザが、特定の選択肢または複数の選択肢を意図するとき、語彙的および/または意味論的曖昧性にかかわらず、その特定の選択肢または選択肢組を取り上げるために、負荷がシステムにかかる。この曖昧性は、システムの欠陥または「知能の欠如」のためではなく、ユーザによって投げ掛けられたあらゆる質問に固有の曖昧性(語彙的または意味論的)のためである。
【0007】
本開示に説明される方法は、ユーザの意図/入力における固有の曖昧性のため、一組の選択肢をもたらすことが不可能である、これらの曖昧な場合に対する曖昧性解消方法に焦点を当てる。Starbucks/レストランおよび「Meryl Streep」応答は、曖昧性解決が必要ない、最良の場合のシナリオである。システム応答は、前述の質問「今夜soxの試合がある?」に対する簡潔な応答と変わらない。複数の応答は、「選択肢」であり、応答における曖昧性ではない。
【0008】
用語「曖昧性」はまた、本開示では、ユーザの意図/入力に一致する応答が全く存在しない例外の場合に対処するためにも使用される。この境界条件では、曖昧性は、ユーザが意図を正確に表していない、または単に情報ドメイン空間内に一致が存在しない等、種々の理由によるものであり得る。例えば、ユーザが、「今夜soxの試合がある?」と尋ね、いずれのsoxの試合も存在しない場合、これは、試合観戦を所望するユーザの意図との一致が存在しない場合である。
【0009】
厳密な要求/応答の観点から、ここには、曖昧性は存在しない。しかし、ヒトの相互作用では、ユーザが、満たすことができない意図を表すとき、「元の意図を満たすために近似し得る何らかをユーザにもたらす」合理的質問が生じる。典型的には、近似する代替案をもたらす応答が、多くの場合、喜ばれる。「今夜soxの試合がある?」の場合、応答は、「今夜はありませんが、見逃した昨晩の試合ならあります」等となる(この応答は、ユーザ選好のシグネチャおよび過去の履歴を使用して作成されることができる)。本発明の実施形態は、このような無応答を「空白応答曖昧性」として対処し、ユーザの意図を満たすより近似する最良の努力である応答を生成する。別の例は、「XおよびYは、演劇で共演したことがある?」等の場合である。XおよびYが、演劇で共演したことがないと仮定すると、本発明の実装は、ドメイン特定構造知識を利用して、「いいえ、演劇で共演したことはありませんが、1989年に映画Zでともに主役を演じました」という応答を生成するであろう。ここでは、ドメイン特定構造知識は、「空白応答曖昧性」の場合に対する応答を生成するために使用される。
【0010】
本開示に説明される曖昧性の例のほとんどは、主に、デジタルエンターテイメント空間に基づく。しかしながら、本開示に説明される方法は、任意の情報分野(エンターテイメント、電子メール、連絡先等の個人用コーパス)に、また、異なる情報分野にわたって適用されることができる。
【0011】
ユーザの意図/入力における曖昧性は、異なる種類のものであり得る。可能性の1つは、ユーザ入力における語彙的曖昧性であるが、ユーザは、明確な意図を有している。例えば、ユーザが、「Beethovenの映画を見たい」と言ったと仮定する。作曲家Beethovenに関する1936年の映画、Beethovenという名前の犬に関する1992年の映画、または「Immortal Beloved」というBeethovenに関する1994年の有名な映画の3つの映画が、「Beethoven」の映画に該当する。ユーザの意図は、明らかに、これらの映画のうちの1つのみであるが(要求内の「冠詞(the)」の使用に基づいて)、ユーザの入力は、3つの適合する応答に語彙的に一致する。優れた会話型システムは、この場合、これらの3つの適合する応答をユーザがそこから1つを取り上げあるための3つの等しく有効な選択肢としてもたらさないであろう。そのようなシステムは、その性能が結果をもたらす検索エンジン性能に成り下がった会話システムであろう。システムが、おそらく、なんらかの関連測定基準以外、用語「Beethoven」の内部理解を有していないことは明白であろう。
【0012】
ヒトの間の会話に近づこうとする会話型システムは、ヒトが会話中に応答するであろうように、「作曲家に関する映画ですか、犬に関する映画ですか?」とユーザに尋ねるであろう。曖昧性を解消する質問自体が、会話型システムが、ヒトが行うように、用語「Beethoven」を理解しているというインジケータである。例えば、同一の曖昧性を解消する質問は、「Beethovenとは作曲家ですか、Beethovenとは犬ですか?」と言い換えられ得る。これは、依然として、優れた曖昧性を解消する応答であるが、前の応答は、通常の発話により近似し、まさに曖昧である用語、すなわちBeethovenが、ユーザへの曖昧性を解消する応答から抜け落ちている。要するに、優れた会話型システムは、語彙的曖昧性に対するその応答において、特に敏感であり、よりヒトのように曖昧性を解消する応答を生成するであろう。なぜなら、そのような応答は、システムの能力を決定する際の重要な測定基準であり、スケールが「検索エンジン知能」から「自然な会話知能」に及び得るからである。
【0013】
曖昧性の別の形態は、時間または時系列連続性における意味論的曖昧性である。ユーザが、「Borghia(TVシリーズ)を見たい」と言う場合、ユーザが視聴を所望するシーズンに曖昧性が存在するが、ほとんどの場合、現在のシーズンが、合理的応答であると考えられるであろう。しかしながら、ユーザが、第1のシーズンからのシリーズを視聴していた場合、理想的には、最後に視聴したものに続くシーズンが、理想的であろう。この形態の曖昧性はまた、ユーザが連続シリーズのコンテンツ(David Attenboroughの自然シリーズ「Life on earth」等)の視聴途中にあるときにも生じ得る。その場合、曖昧性の解決は、理想的には、同様に、ユーザが最後に視聴したエピソードから開始することによって解決される。いずれの場合も(シーズンまたは時系列シリーズ)、ユーザが、時間または時系列シーケンスにおいて視聴していない場合、曖昧性を解消する質問は、不可避である。しかしながら、ユーザが、「次のBorghiaを見たい」という場合、ユーザの意図は、ユーザが最後に視聴したものに続くエピソードを意味すると解釈され得る。
【0014】
別の曖昧性の形態は、複数の適合する応答をもたらす、場所における曖昧性である。例えば、「Hawaiiで撮影されたSpielbergの映画が見たい」という要求は、複数の映画Jurassic Parkおよびその続編、すなわち、Lost worldおよびJurassic Park III(全て、Hawaii内の場所で撮影されている)をもたらすであろう。ユーザは、ここでは、「(冠詞(the))Spielbergの映画」と尋ねることによって、1つのみを意図している。ヒトの応答により近似する応答は、「Jurassic parkは、Hawaiiで撮影されました。その続編「Lost World」および「Jurassic Park III」も、そこで撮影されました」となるであろう。
【0015】
別の例では、ユーザが、「今夜tigersの試合がある?」と尋ねる場合、ユーザは、野球チームDetroit TigersまたはフットボールチームLouisiana Tigersを意味し得る(フットボールチームLouisiana Tigersは、同一の名前でも、野球チームより人気がある)。しかしながら、ユーザの場所がLouisianaにあることが既知である場合、ユーザは、フットボールチームLouisianaを意味する可能性が最も高い。しかしながら、ユーザの場所が、Detroitにあることが既知である場合、質問は、野球チームDetroitを対象とし得る。ユーザが旅行中であり、場所が既知ではない場合、特に、これらのチームのいずれか1つに対するユーザの選好に関する以前の情報が存在しないとき、質問に、解決される必要がある曖昧性が存在する。さらに、質問が、試合シーズンの間に投げ掛けられた場合、場所に加え、それも曖昧性を解消する要因となり得る。一般に、場所および時間だけではなく、ユーザによって指定される任意の属性に曖昧性が存在し得る。前述の例は、場所および時間等の属性における曖昧性を示す。
【0016】
また、非常に広範囲の意図から、ユーザの意図を理解する際にも曖昧性が存在し得る。例えば、ユーザが、「今夜映画を見たい」と言う場合、ユーザ選好のシグネチャが既知である場合でも、ユーザは、アクションまたはミステリー映画に関心があり得る。したがって、依然として、これらの2つのジャンルタイプの間に、解決される必要がある曖昧性が存在する。いくつかの既存の会話型システムにおいて使用される曖昧性解消方式は、ユーザが、質問をユーザに投げ掛けるマルチレベルの決定ツリーを辿り、選択肢を絞り込むものである。この「アルゴリズムツリーウォークアプローチ」は、自然な会話においてヒトによって行われることはなく、その方式は、自然な会話に近づけようとする会話型システムには容認可能ではない。そのようなマルチレベル決定ツリーウォークは、航空座席予約プロセス等のいくつかのドメインには、ある程度容認可能であり得るが、エンターテイメント空間等のあるドメインに適用されると、滑稽なほど愚問となるであろう。
【0017】
曖昧性はまた、入力が音声またはテキスト入力であり得る場合、ユーザの意図を入力する際のエラーからも生じ得る。それらのエラーは、本開示に説明される方法の目的の場合、語彙的エラーと見なされる(但し、語彙的エラーは、実際には、ある場合には、意味論的差異をもたらし得る)。本開示に説明される曖昧性の解決は、ドメイン特定構造知識、ユーザ選好のシグネチャ(利用可能である場合)、ユーザの場所(利用可能である場合)、および時間を活用する。しかしながら、明らかに、前述の例に見られるように、全ての曖昧性が解決可能であるわけではない。
【0018】
要約すると、ユーザ入力/意図における曖昧性は、語彙的曖昧性の場合のように、相互に少なからず相関し得る、適合する応答につながり得る(「空白応答」の場合を除く)(例えば、Beethovenの映画は、Beethovenという名前の音楽家または犬に関する映画と一致し得る)。他の極端な例では、ユーザ入力/意図における曖昧性は、複数の応答が全て、少なからず相関し、ユーザの意図に高い確率で一致する「選択肢」のようなものである範囲において、相互に少なからず相関し得る、適合する応答につながり得る(例えば、「近くのStarbucksを教えて」に対する応答)。さらに、ユーザの意図が広義であるとき、適合する応答は、潜在的に、非常に大量であり、ユーザに対して曖昧性を解消する応答を余儀なくされる。本発明に説明される会話型システムの実施形態は、ドメイン特定構造知識、時間、ユーザの場所(利用可能である場合)、およびユーザ選好のシグネチャ(利用可能である場合)を利用することによって、曖昧性の性質(語彙的または意味論的曖昧性)および相互との適合する応答の相関の程度に基づいて、会話中でユーザに応答する。ユーザの意図の曖昧性を解消するために結果として生じる会話のやりとりは、ヒトの会話の円滑さという理想的目標に近づこうとするものであり、曖昧性解消は、やりとりそのもの中にシームレスに組み込まれ、その機械生成原因のアーチファクトのため顕著となることによってシームレスな流れを中断しない。本開示に説明される会話型システムの実施形態はまた、「空白応答曖昧性」の場合にも対処し、したがって、ユーザは、満たされない意図とともに行き止まりに取り残されることはない。
【0019】
(発明の要約)
情報読み出しのために、会話型相互作用におけるユーザの意図の曖昧性を解消する方法が、提供される。本方法は、一組のコンテンツアイテムへのアクセスを提供することを含む。コンテンツアイテムの各々は、対応するコンテンツアイテムを記述するメタデータに関連付けられる。本方法はまた、コンテンツアイテム間の意味論的関係およびリンクを示す、構造知識へのアクセスを提供することと、(i)特定のコンテンツアイテム、および(ii)コンテンツアイテムに関連付けられたメタデータのうちの少なくとも1つに対するユーザの選好を記述する、ユーザ選好シグネチャを提供することとを含む。本方法はさらに、第1の入力をユーザから受信することを含む。第1の入力は、ユーザによって、少なくとも1つの所望のコンテンツアイテムを識別するように意図される。本方法はまた、第1の入力の曖昧性インデックスを決定することを含む。本方法は、曖昧性インデックスが第1の閾値を超えるという条件に応じて、第1の入力と、構造知識、ユーザ選好シグネチャ、ユーザの場所、および第1の入力の時間のうちの少なくとも1つとに基づいて、クエリ入力を決定し、クエリ入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの一部を一組のコンテンツアイテムから選択することを含む。本方法はまた、曖昧性インデックスが第1の閾値を超えないという条件に応じて、第1の入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの一部を一組のコンテンツアイテムから選択することを含む。
【0020】
別の実施形態では、本方法はまた、コンテンツアイテムの一部をユーザに提示することを含む。
【0021】
さらに別の実施形態では、曖昧性インデックスは、第1の入力のいくつかの可能な解釈に基づいて決定される。
【0022】
異なる実施形態では、本方法はさらに、曖昧性インデックスが第1の閾値を超えるという条件に応じて、第1の入力のどの部分が曖昧であるかを決定することを含む。クエリ入力の決定は、入力の曖昧な部分にさらに基づくことができる。
【0023】
さらなる実施形態では、本方法は、入力の意図、エンティティ、およびフィルタを決定することを含む。意図は、ユーザによって求められているものであることができ、エンティティは、意図を記述している名詞または代名詞であることができ、フィルタは、エンティティの修飾語句であることができる。
【0024】
さらに別の実施形態では、本方法は、曖昧性インデックスが第2の閾値を超えるという条件に応じて、ユーザから第2の入力を求め、受信することを含む。クエリ入力の決定は、第2の入力にさらに基づくことができる。
【0025】
別の実施形態では、本方法は、ユーザから第2の入力を求め、受信することを含む。クエリ入力の決定は、第2の入力にさらに基づくことができる。
【0026】
さらに別の実施形態では、第2の閾値は、第1の閾値を上回る。
【0027】
ある実施形態では、情報読み出しのために、会話型相互作用におけるユーザの意図の曖昧性を解消するためのシステムが、提供される。本システムは、非一過性コンピュータ読み取り可能な媒体上にエンコードされたコンピュータ読み取り可能な命令を含む。コンピュータ読み取り可能な命令は、コンピュータシステムに、それらの各々が対応するコンテンツアイテムを記述するメタデータに関連付けられる一組のコンテンツアイテムへのアクセスを提供させ、コンテンツアイテム間の意味論的関係およびリンクを示す構造知識へのアクセスを提供させる。コンピュータ読み取り可能な命令はまた、コンピュータシステムに、(i)特定のコンテンツアイテム、および(ii)コンテンツアイテムに関連付けられたメタデータのうちの少なくとも1つに対するユーザの選好を記述するユーザ選好シグネチャを提供させ、ユーザによって、少なくとも1つの所望のコンテンツアイテムを識別するように意図される第1の入力をユーザから受信させ、第1の入力の曖昧性インデックスを決定させる。コンピュータ読み取り可能な命令はさらに、コンピュータシステムに、曖昧性インデックスが第1の閾値を超えるという条件に応じて、第1の入力と、構造知識、ユーザ選好シグネチャ、ユーザの場所、および第1の入力の時間のうちの少なくとも1つとに基づいて、クエリ入力を決定させ、クエリ入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの一部を一組のコンテンツアイテムから選択させる。コンピュータ読み取り可能な命令はまた、コンピュータシステムに、曖昧性インデックスが第1の閾値を超えないという条件に応じて、第1の入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの一部を一組のコンテンツアイテムから選択させる。
本願明細書は、例えば、以下の項目も提供する。
(項目1)
情報読み出しのために、会話型相互作用におけるユーザの意図の曖昧性を解消する方法であって、前記方法は、
一組のコンテンツアイテムへのアクセスを提供することであって、前記コンテンツアイテムの各々は、前記対応するコンテンツアイテムを記述するメタデータに関連付けられている、ことと、
構造知識へのアクセスを提供することであって、前記構造知識は、前記コンテンツアイテム間の意味論的関係およびリンクを示す、ことと、
ユーザ選好シグネチャを提供することであって、前記ユーザ選好シグネチャは、(i)特定のコンテンツアイテム、および(ii)前記コンテンツアイテムに関連付けられたメタデータのうちの少なくとも1つに対するユーザの選好を記述する、ことと、
第1の入力を前記ユーザから受信することであって、前記第1の入力は、前記ユーザによって、少なくとも1つの所望のコンテンツアイテムを識別するように意図されている、ことと、
前記第1の入力の曖昧性インデックスを決定することと、
前記曖昧性インデックスが第1の閾値を超えるという条件に応じて、前記第1の入力と、前記構造知識、前記ユーザ選好シグネチャ、前記ユーザの場所、および前記第1の入力の時間のうちの少なくとも1つとに基づいて、クエリ入力を決定し、前記クエリ入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの前記一部を前記一組のコンテンツアイテムから選択することと、
前記曖昧性インデックスが前記第1の閾値を超えないという条件に応じて、前記第1の入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの前記一部を前記一組のコンテンツアイテムから選択することと
を含む、方法。
(項目2)
コンテンツアイテムの前記一部を前記ユーザに提示することをさらに含む、項目1に記載の方法。
(項目3)
前記曖昧性インデックスは、前記第1の入力のいくつかの可能な解釈に基づいて決定される、項目1に記載の方法。
(項目4)
前記曖昧性インデックスが前記第1の閾値を超えるという条件に応じて、前記第1の入力のどの部分が曖昧であるかを決定することをさらに含み、前記クエリ入力の決定は、前記入力の前記曖昧な部分にさらに基づく、項目1に記載の方法。
(項目5)
前記入力の意図、エンティティ、およびフィルタを決定することをさらに含み、前記意図は、前記ユーザによって求められているものであり、前記エンティティは、前記意図を記述している名詞または代名詞であり、前記フィルタは、前記エンティティの修飾語句である、項目1に記載の方法。
(項目6)
前記曖昧性インデックスが第2の閾値を超えるという条件に応じて、前記ユーザから第2の入力を求め、受信することをさらに含み、前記クエリ入力の決定は、前記第2の入力にさらに基づく、項目1に記載の方法。
(項目7)
前記ユーザから第2の入力を求め、受信することをさらに含み、前記クエリ入力の決定は、前記第2の入力にさらに基づく、項目1に記載の方法。
(項目8)
コンテンツアイテムの前記一部を前記ユーザに提示することをさらに含む、項目7に記載の方法。
(項目9)
前記第2の閾値は、前記第1の閾値を上回る、項目7に記載の方法。
(項目10)
前記曖昧性インデックスが前記第1の閾値を超えるという条件に応じて、前記第1の入力のどの部分が曖昧であるかを決定することをさらに含み、前記クエリ入力の決定は、前記入力の前記曖昧な部分にさらに基づく、項目7に記載の方法。
(項目11)
前記入力の意図、エンティティ、およびフィルタを決定することをさらに含み、前記意図は、前記ユーザによって求められているものであり、前記エンティティは、前記意図を記述している名詞または代名詞であり、前記フィルタは、前記エンティティの修飾語句である、項目7に記載の方法。
(項目12)
情報読み出しのために、会話型相互作用におけるユーザの意図の曖昧性を解消するためのシステムであって、前記システムは、非一過性コンピュータ読み取り可能な媒体上にエンコードされているコンピュータ読み取り可能な命令を備え、
前記コンピュータ読み取り可能な命令は、
一組のコンテンツアイテムへのアクセスを提供することであって、前記コンテンツアイテムの各々は、前記対応するコンテンツアイテムを記述するメタデータに関連付けられている、ことと、
構造知識へのアクセスを提供することであって、前記構造知識は、前記コンテンツアイテム間の意味論的関係およびリンクを示す、ことと、
ユーザ選好シグネチャを提供することであって、前記ユーザ選好シグネチャは、(i)特定のコンテンツアイテム、および(ii)前記コンテンツアイテムに関連付けられたメタデータのうちの少なくとも1つに対するユーザの選好を記述する、ことと、
第1の入力を前記ユーザから受信することであって、前記第1の入力は、前記ユーザによって、少なくとも1つの所望のコンテンツアイテムを識別するように意図されている、ことと、
前記第1の入力の曖昧性インデックスを決定することと、
前記曖昧性インデックスが第1の閾値を超えるという条件に応じて、前記第1の入力と、前記構造知識、前記ユーザ選好シグネチャ、前記ユーザの場所、および前記第1の入力の時間のうちの少なくとも1つとに基づいて、クエリ入力を決定し、前記クエリ入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの前記一部を前記一組のコンテンツアイテムから選択することと、
前記曖昧性インデックスが前記第1の閾値を超えないという条件に応じて、前記第1の入力とコンテンツアイテムの一部に関連付けられたメタデータとの比較に基づいて、コンテンツアイテムの前記一部を前記一組のコンテンツアイテムから選択することと
をコンピュータシステムに行わせる、システム。
(項目13)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、コンテンツアイテムの前記一部を前記ユーザにさらに提示させる、項目12に記載のシステム。
(項目14)
前記曖昧性インデックスは、前記第1の入力のいくつかの可能な解釈に基づいて決定される、項目12に記載のシステム。
(項目15)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記曖昧性インデックスが前記第1の閾値を超えるという条件に応じて、前記第1の入力のどの部分が曖昧であるかをさらに決定させ、前記クエリ入力の決定は、前記入力の前記曖昧な部分にさらに基づく、項目12に記載のシステム。
(項目16)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記入力の意図、エンティティ、およびフィルタをさらに決定させ、前記意図は、前記ユーザによって求められているものであり、前記エンティティは、前記意図を記述している名詞または代名詞であり、前記フィルタは、前記エンティティの修飾語句である、項目12に記載のシステム。
(項目17)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記ユーザから第2の入力をさらに求め、受信させ、前記クエリ入力の決定は、前記第2の入力にさらに基づく、項目12に記載のシステム。
(項目18)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記曖昧性インデックスが第2の閾値を超えるという条件に応じて、前記ユーザから第2の入力をさらに求め、受信させ、前記クエリ入力の決定は、前記第2の入力にさらに基づく、項目12に記載のシステム。
(項目19)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、コンテンツアイテムの前記一部を前記ユーザにさらに提示させる、項目18に記載のシステム。
(項目20)
前記第2の閾値は、前記第1の閾値を上回る、項目18に記載のシステム。
(項目21)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記曖昧性インデックスが前記第1の閾値を超えるという条件に応じて、前記第1の入力のどの部分が曖昧であるかをさらに決定させ、前記クエリ入力の決定は、前記入力の前記曖昧な部分にさらに基づく、項目18に記載のシステム。
(項目22)
前記コンピュータ読み取り可能な命令は、前記コンピュータシステムに、前記入力の意図、エンティティ、およびフィルタをさらに決定させ、前記意図は、前記ユーザによって求められているものであり、前記エンティティは、前記意図を記述している名詞または代名詞であり、前記フィルタは、前記エンティティの修飾語句である、項目18に記載のシステム。
【0028】
本発明の種々の実施形態のより完全な理解のために、ここで、付随の図面と併せて検討される、以下の説明を参照する。
【図面の簡単な説明】
【0029】
図1図1は、本発明の実施形態である、アーキテクチャを図示する。
図2図2は、ドメイン特定構造知識リポジトリの作成を図示する。
図3図3は、ドメイン特定構造知識リポジトリを作成するための段階を図示する。
図4図4は、ドメイン特定知識リポジトリエンティティの一部およびエンティティ間の関係の略図を図示する。
【発明を実施するための形態】
【0030】
本発明の好ましい実施形態は、ユーザの意図の曖昧性を解消し、その意図を会話型やりとりにおいて満たす方法およびシステムを含む。本発明の好ましい実施形態およびその利点は、類似参照番号が類似要素を指す、図1-4を参照することによって理解され得る。
【0031】
(情報リポジトリの作成)
ユーザの意図/入力の曖昧性を解消するために使用されるドメイン特定情報リポジトリは、異種ソースから集められた多くの構造化および非構造化情報をまとめることによって集約された名前付きエンティティの常に進化し続ける拡張可能データベースである。構造知識が、図2に示されるように、異種ソースから集約されるにつれて、暗示的および明示的意味論的関係およびリンクが、名前付きエンティティに利用可能なメタコンテンツに統計的テキスト処理、リンク分析、および他の信号の分析(例えば、場所情報等に対して)を行うことによって、情報リポジトリ自体の要素間で作成される。これらの関係は、常時、進化し(図3に示されるように)、経時的に、総合的使用分析、協調フィルタリング、および他の技法によって強化される。
【0032】
情報リポジトリ内の各名前付きエンティティは、テキスト情報読み出し作業が重み付きテキスト句のベクトルとして文書を表す方法に類似する様式において、重み付きテキスト句(用語)のベクトルとして表される。単純「tf-idf」(用語頻度/逆文書頻度)ベースのアプローチのみでは、多くの重要な場合に、本発明の実装の目的のために適正ではない。名前付きエンティティのベクトル表現における重み算出は、テキスト語句が表示される方法、種々の種類のテキスト記述内のテキスト語句の位置、ならびに、テキスト語句に関連付けられたハイパーリンクの構造および位置特性にも存在するより多くの情報信号を利用するように設計される。重み算出は、したがって、テキスト、ハイパーリンク、および他の特性のより豊富な統計および構造分析、ならびに情報リポジトリ内のメタコンテンツから抽出される関係に基づく。
【0033】
本発明の好ましい実施形態では、情報リポジトリの作成は、名前付きエンティティ集約エンジンによって駆動され、本質的に、そのテキストメタコンテンツに基づいて、各コンテンツアイテムの単純重み付きテキスト句ベクトル表現を算出し、次いで、全名前付きエンティティに対応するテキスト句ベクトルを用いて、アイテムのテキスト句ベクトルの「ドット積」を効率的に計算し、次いで、閾値を超えたドット積に対応する全名前付きエンティティのリストを収集し、さらにフィルタリングならびに並べ替え基準(アイテムおよびエンティティの非テキストメタコンテンツを含み得る)を適用し、次いで、最後に、アイテムに関連するエンティティの最終リストを出力する。プロセスは、ウェブ検索エンジンが、検索クエリをベクトルとして取り扱い、ある種類のドット積算出を行い、そのインデックスから有意義な文書をランク付けする方法に類似する。
【0034】
情報リポジトリを作成するための技法は、本発明の実施形態が、ある単一名前付きエンティティにマップされないこともある任意のニッチ分野の豊富な重み付きテキスト句ベクトル表現を生み出すことを可能にし、また、既存のエンティティ間の新しい関係を発見することを可能にする。要約すると、前述の方法を使用した情報リポジトリ構築は、ユーザの意図/入力の語彙的および意味論的レベル曖昧性解消の基礎としての役割を果たし、図1のアーキテクチャに説明されるモジュールの多くを支援する。本開示に説明される曖昧性解消機構の一部であり、その独自の表現を構築するためにこのリポジトリに依拠する重要なモジュールは、以下に説明されるグラフエンジン110である。
【0035】
(本発明の実施形態に適用可能な情報リポジトリ)
いくつかの情報リポジトリは、エンティティとエンティティ間の関係とを含む。各エンティティ/関係は、それぞれ、一組のタイプからのあるタイプを有する。さらに、いくつかの実施形態では、定義された有限組の名前-値フィールドとして捕捉されることができる一組の属性が、各エンティティ/関係に関連付けられる。エンティティ/関係マッピングは、コンテンツアイテムに関連付けられたメタデータのセットとしての役割も果たす。なぜなら、エンティティ/関係マッピングは、種々のコンテンツアイテムを記述する情報を提供するからである。言い換えると、特定のエンティティは、他のエンティティと関係を有し、これらの「他のエンティティ」は、「特定のエンティティ」に対するメタデータとしての役割を果たす。加えて、マッピング内の各エンティティは、それに割り当てられる属性、または、そのエンティティをマッピング内の他のエンティティに接続する関係に割り当てられる属性を有することができる。集合的に、これは、エンティティ/コンテンツアイテムに関連付けられたメタデータを構成する。一般に、そのような情報リポジトリは、構造化情報リポジトリと呼ばれ、構造化情報リポジトリによって提供される情報は、構造知識と呼ばれる。いくつかの実施形態では、本発明は、情報読み出しのために、構造化情報リポジトリを使用して、構造知識にアクセスする。
【0036】
いくつかの情報リポジトリは、類似タイプの情報および/またはあるタイプのコンテンツアイテムのグループ化である、ドメインに関連付けられる。これらのドメイン特定構造化情報リポジトリは、ドメイン特定構造知識を含む。本発明が使用する構造化情報リポジトリは、ドメイン特定情報リポジトリであり得る。ドメインに関連付けられた情報リポジトリの実施例は、以下に続く。
【0037】
メディアエンターテイメントドメインは、映画、TV番組、エピソード、クルー、役/登場人物、俳優/パーソナリティ、運動選手、試合、チーム、リーグおよびトーナメント、スポーツ選手、音楽アーティストおよび演奏者、作曲家、アルバム、曲、ニュースパーソナリティ、および/またはコンテンツ配信業者等のエンティティを含む。これらのエンティティは、情報リポジトリ内で捕捉される関係を有する。例えば、映画エンティティは、「演技」関係を介して、1つ以上の俳優/パーソナリティエンティティに関連する。同様に、映画エンティティは、「オリジナルサウンドトラック」関係を介して、音楽アルバムエンティティに関連し得、ひいては、「アルバム中のトラック」関係を介して、曲エンティティに関連し得る。一方、名前、説明、スケジュール情報、レビュー、評価、コスト、ビデオまたはオーディオへのURL、アプリケーションまたはコンテンツストアの取扱、評点等は、属性フィールドと見なされ得る。
【0038】
個人用電子メール(電子メール)ドメインは、電子メール、電子メールスレッド、連絡先、送信者、受信者、会社名、企業内の部署/事業部門、電子メールフォルダ、オフィスの場所、および/またはオフィスの場所に対応する都市ならびに国等のエンティティを含む。関係の例証的実施例は、その送信者エンティティに関連する電子メールエンティティ(ならびに宛先、cc先、bcc先、受信機、および電子メールスレッドエンティティ)を含む。一方、連絡先とその会社、部署、オフィスの場所との間の関係も、存在し得る。このリポジトリでは、エンティティに関連付けられた属性フィールドのインスタンスは、連絡先の名前、称号、電子メールハンドル、他の連絡先情報、電子メール送信/受信タイムスタンプ、件名、本文、添付、優先度レベル、オフィスの場所情報、および/または部署の名前ならびに説明を含む。
【0039】
旅行関連/ホテルおよび観光ドメインは、都市、ホテル、ホテルブランド、個々の着目点、着目点のカテゴリ、消費者が対面する小売店チェーン、レンタカーサイト、および/またはレンタカー会社等のエンティティを含む。そのようなエンティティ間の関係は、場所、チェーンのメンバーシップ、および/またはカテゴリを含む。さらに、名前、説明、キーワード、コスト、サービスのタイプ、評価、レビュー等も全て、属性フィールドになる。
【0040】
電子商取引ドメインは、製品アイテム、製品カテゴリおよびサブカテゴリ、ブランド、店舗等のエンティティを含む。そのようなエンティティ間の関係は、製品アイテム間の適合性情報、店舗によって「販売された」製品等を含むことができる。属性フィールドは、説明、キーワード、レビュー、評価、コスト、および/または可用性情報を含む。
【0041】
アドレスブックドメインは、連絡先名、電子メールアドレス、電話番号、物理的アドレス、および雇用者等のエンティティおよび情報を含む。
【0042】
本明細書に記載されたエンティティ、関係、および属性は、例証にすぎず、包括的リストであると意図されるものではない。
【0043】
本発明の実施形態はまた、前述のように、構造化情報リポジトリではないリポジトリを使用し得る。例えば、ネットワークベースの文書(例えば、インターネット/World
Wide Web)に対応する情報リポジトリは、リンクされた文書(エンティティ)の関係ウェブと見なされることができる。しかしながら、一般に、いずれの直接適用可能なタイプの構造も、非自明な方法において、前述の構造化情報リポジトリという意味では、インターネットの要素に関連付けられたあらゆる種類のエンティティならびに関係および属性を有意義に記述することができない。しかしながら、ドメイン名、インターネットメディアタイプ、ファイル名、ファイル名拡張子等の要素が、エンティティまたは属性として、そのような情報とともに使用されることができる。
【0044】
例えば、一組の非構造化テキスト文書から成るコーパスを検討する。この場合、いずれの直接適用可能であるタイプの構造も、文書コンテンツを有意義に記述する一組のエンティティおよび関係を列挙することができない。しかしながら、事前処理ステップとしての意味論的情報抽出処理技法の適用は、そのようなコーパスから構造を部分的に明らかにすることができるエンティティおよび関係をもたらし得る。
【0045】
(本発明のある実施形態下における情報リポジトリへのアクセスの例証的実施例)
以下の説明は、前述のように、構造化および非構造化情報リポジトリとの関連における情報読み出しタスクの例を例証する。
【0046】
ある場合には、ユーザは、ユーザがエンティティが満たさなければならない属性フィールド制約のみを指定することによって明らかにすることを所望する、概して、本明細書では、意図タイプと呼ばれる、あるタイプの1つ以上のエンティティに関心を示す。時として、意図は、ユーザがあるタイプのエンティティのある属性を所望するとき、(タイプ、属性)対であり得ることに留意されたい。例えば、ユーザが、映画の評価を所望する場合、意図は、(タイプ、属性)=(映画、評価)と見なされ得る。そのようなクエリ制約は、概して、本明細書では、属性専用制約と呼ばれる。
【0047】
ユーザが、エンティティの名前を挙げるか、または直接所望の意図タイプエンティティの属性に一致するために十分な情報を指定する場合は常に、それは、属性専用制約である。例えば、ユーザが、名前といくつかの追加の属性(例えば、60年代に作製された「Cape Fear」)とによって映画を識別するとき、または見つけ出したい電子メールの件名一致を指定するとき、または値段範囲に基づいて、ホテルを要求するとき、または32GB、黒色iPodタッチを所望することを指定するときである。
【0048】
しかしながら、ある場合には、ユーザは、意図タイプエンティティの属性フィールド制約を指定するだけでなく、意図タイプエンティティがある明確な方法で関係を介して接続される他のエンティティの属性フィールド制約をさらに指定するか、またはその名前を挙げることによって、意図タイプの1つ以上のエンティティに関心を示す。そのようなクエリ制約は、概して、本明細書では、コネクション指向型制約と呼ばれる。
【0049】
コネクション指向型制約の例は、ユーザが、映画の2人以上の俳優に基づいて、または映画俳優と映画が受賞した賞とに基づいて映画(意図タイプ)を指定することを所望するときである。別の実施例は、電子メールに関連して、ユーザが、過去7日間に特定の会社のある送信者から受信した電子メール(意図タイプ)を所望する場合である。同様に、さらなる実施例は、ユーザが、鉄道の駅ならびにStarbucks店舗が近いホテルの部屋(意図タイプ)の予約を所望する場合である。さらに別の実施例は、ユーザが、Nintendo Wiiとも適合性がある、Samsung製のテレビセット(意図タイプ)を所望する場合である。これらは全て、コネクション指向型制約クエリのインスタンスである。
【0050】
前述のコネクション指向型制約例では、ユーザは、意図エンティティに接続される他のエンティティを明示的に説明または指定する。そのような制約は、概して、本明細書では、明示的コネクション指向型制約と呼ばれ、そのようなエンティティは、明示的エンティティと呼ばれる。
【0051】
一方、他のクエリは、制約明細の一部として、指定されていないまたは暗示的エンティティを含む、コネクション指向型制約を含む。そのような状況では、ユーザは不明なアイテムとユーザが現在分かっているアイテムとの間の関係を通して不明な一連の情報、エンティティ、属性等の識別を試みる。そのような制約は、概して、本明細書では、暗示的コネクション指向型制約と呼ばれ、指定されていないエンティティは、概して、本明細書では、制約の暗示的エンティティと呼ばれる。
【0052】
例えば、ユーザは、映画中の2人の登場人物の名前を挙げることを介して、探している映画の識別を所望し得る。しかしながら、ユーザは、登場人物のうちの1人の名前を思い出せないが、特定の俳優がその登場人物を演じたことを思い出す。したがって、そのクエリでは、一方の登場人物を名前で述べ、かつ、不明な登場人物を、その登場人物が特定の俳優によって演じられたことを述べることによって、識別する。しかしながら、特定の情報読み出し目標のために、以下のユーザ制約を検討する。ユーザは、指定された役(例えば、登場人物「Tony Montana」)に関する、指定されていない映画中の指定された俳優(例えば、「Michelle Pfeiffer」)によって演じられた役(意図)を所望する。この場合、ユーザの制約は、映画「Scarface」に対応する、指定されていないまたは暗示的エンティティを含む。同様に、ユーザが、指定された俳優「Scarlett Johannsen」と、指定された映画「Star Wars」中で「Obe Wan Kanobi」の指定された役を演じた指定されていない俳優とが主演する映画(意図)を所望すると仮定する。この場合、暗示的エンティティは、俳優「Ewan McGregor」であり、意図エンティティは、「Scarlett Johannsen」と「EwanMc Gregor」とが主演する映画「The Island」である。
【0053】
電子メールリポジトリに関連して、例として、先週、電子メール(属性指定子)を介して紹介された、指定された会社「Intel」からの指定されていない男性からの最後の電子メール(意図)を見つけることを所望するユーザが挙げられる。この場合、暗示的エンティティは、先週、ユーザとの初めての一般電子メール受信者となった従業員/会社関係を介して、「Intel」からの取引先担当者を調べることによって発見されることができる、取引先担当者である。
【0054】
前述の3つの実施例は、コネクション指向型制約であるが、制約明細の一部として、指定されていないまたは暗示的エンティティを含む。そのような制約を暗示的コネクション指向型制約と呼び、指定されていないエンティティを制約の暗示的エンティティと呼ぶ。
【0055】
コネクション指向型制約に関連して、情報リポジトリのエンティティおよび関係をグラフのノードおよびエッジに基本的にマップすることは有用である。エンティティ関係モデルの代わりに、グラフモデルを特に採用する動機は、単に、リンク距離、ある場合には、最短経路および最小加重ツリー等の概念によって、自然な言語会話における関連性、近接性、および同系性が、モデル化されることができるという観察によるものである。会話の間、ユーザ対話が、実際に求められるエンティティに関連する他のエンティティを伴うとき、単純グラフ検索問題として、情報読み出しに対処するサブルーチンは、文構造の深い明確な理解に依存することを低減させるのに効果的に役立ち、これは、大きな実装利点であり得る。ユーザの意図計算が、曖昧または不確定である場合でも、エンティティがユーザの発話内で認識される限り、問題のグラフ解釈ベースの処理は、我々のシステムが、それ以外の可能なものよりはるかに知的な様式において応答することを可能にする。
【0056】
(ユーザの意図/入力の曖昧性を解消するための会話型相互作用インターフェース)
ここで、ユーザの意図/入力の曖昧性を解消するために使用される、本発明の実施形態の会話型相互作用インターフェースを説明する。ユーザが、話し掛けること、随意に、タッチすることあるいはキーパッドまたはマウスを用いて選択肢を選択することによりクエリまたは命令を投げ掛けることによって、情報読み出しシステムと相互作用可能である場合、それは、会話型相互作用インターフェースと見なされる。ユーザクエリへの応答は、発話するための機械生成音声テキストによって行われ得、ユーザ画面上に表示される情報によって補完され得る。会話相互作用インターフェースは、一般に、情報読み出しセッションが、その各々がユーザに最初にクエリまたは命令を投げ掛けさせ、システムに、ユーザに応答を提示させる一連の動作であるように、ほぼ常時、ユーザが、前のクエリに対する情報読み出しシステムの応答に反応して、次の情報読み出しクエリまたは命令を投げ掛けることを可能にする。
【0057】
本質的に、本開示に説明される会話型相互作用インターフェースの実装は、ユーザ入力/意図の曖昧性を解消するためのグラフィカルUIより効果的かつ表現的な理論的枠組みである。多くの状況では、特に、多数の可能な属性、または明示的および暗示的に接続されたノードの存在の中から柔軟に選択を行うとすると、グラフィカルUIアプローチは、良好に機能しないかまたは全く機能しない。そのような場合、会話型相互作用インターフェースは、はるかに自然に調和し、さらに、改良された音声認識技法の進化に伴って、ユーザを満足させるであろう。
【0058】
ここで、会話型相互作用のための情報読み出しシステムのアーキテクチャ、構成要素、および実装を説明する。
【0059】
(会話型システムアーキテクチャ)
図1は、本発明の実施形態の全体的システムアーキテクチャおよび基本情報フローを表す。ユーザ10は、音声テキストエンジン302にフィードされる質問を投げ掛ける。入力は、音声であり得るが、本発明は、入力が直接テキスト入力であることも除外しない。ユーザ入力からのテキストは、セッション対話コンテンツモジュール103にフィードされる。このモジュールは、会話を通して状態を維持する役割を果たし、その使用の1つは、以下に説明されるように、会話の間、ユーザの意図を理解することに役立つことである。セッション対話は、言語分析器(または、音声タガーの一部)106および以下に説明される他のエンティティ認識モジュールと併せて、(1)意図-映画を探す、曲を演奏する、チャンネルに合わせる、電子メールに応答する等のユーザの実際の意図、(2)エンティティ-意図を記述する名詞または代名詞語句、および(3)属性-「最新」映画、「あまり」暴力的ではない等のエンティティに対する修飾語句等として大まかに分類され得る、その構成要素に文を分解する。知的および有意義な会話を提供する目標に関連して、意図は、時として、全3つのカテゴリの中で最も重要である。任意の優れた検索エンジンは、文法または意図を理解せずに、単に、文からエンティティを抽出することによって、情報読み出しタスクを非常に良好に行うことができる。
【0060】
例えば、ユーザが、「娘とpulp fictionを見ることができるかな?」と質問すると、ほとんどの検索エンジンは、pulp fictionのリンクを示し、これは、評価がそのリンクの検討から利用可能である場合、充足し得る。しかし、会話型インターフェースでは、期待は、より高いものであり、システムは、理想的には、映画の評価および適切な年齢層の期待される応答に対応する(映画、評価)意図を理解しなければならない。検索エンジンのそれに成り下がった会話型インターフェースの応答は、ユーザの視点からは、システムの故障も同然である。検索エンジンではなくヒトの相互作用により近くあることに努力する会話型インターフェースにとって、意図決定と、さらに重要なこととして、意図が不明であるかまたは明確に判別不能であるときのヒトの応答により近く見えるユーザの質問への応答とが、重要である。
【0061】
意図分析器108は、ドメインに対する意図を分析および分類し、他のモジュール、すなわち、ドメイン特定エンティティ認識器107、ユーザの個人の選好に基づいて意図を分類する個人化ベースの意図分析器109、およびドメイン特定グラフエンジン110と協働するドメイン特定モジュールである。属性特定検索エンジン111は、属性を認識する支援をし、その重みは、絞り込むエンティティに影響を及ぼす。図1は、特定のドメインに対するモジュールを示す会話アーキテクチャであるが、本発明の実施形態は、ユーザ入力を取り込み、ユーザの意図が複数のドメインに及び得る対話に従事することができる会話インターフェースを含む。本発明のある実施形態では、これは、図1に示されるドメイン特定アーキテクチャの複数のインスタンスを有し、ドメインにわたって意図の重みをスコア化し、ユーザの意図を決定することによって達成される。このスコア化機構はまた、会話の話題の切り替えを暗示的に決定するためにも使用される(例えば、エンターテイメント情報読み出しセッションの間、ユーザは、単に、「お腹が空いた」と述べ得る)。新しい会話の開始が暗示的に決定される別の実施例は、以下である。
ユーザ:Yankeesの試合はいつ?
応答:New York Yankeesは、7月6日金曜日(7pm)にBoston
Red Soxと試合を行います。ESN HDで視聴可能です。
ユーザ:試合を録画してくれる?
応答:7月6日金曜日(7pm)のNew York Yankees対Boston Red Soxの録画を予約しました。
ユーザ:映画Iron Manは、Netflixで利用可能?
応答:Iron ManおよびIron Man 2は、Netflix Instantで利用可能です。インスタントキューに追加しますか?
異なるドメインからの応答が、等しく可能である状況では、本開示に説明されるシステムの実施形態は、曖昧性を解消する質問をユーザに投げ掛ける。
ユーザ:良い音楽アプリはないかな?
応答:音楽配信を希望ですか、音楽に関するニュースや情報を希望ですか?
この例では、本開示に説明される例証的システムは、ジャンル「音楽」を識別し、知識グラフが、音楽ジャンルにおける人気のあるアプリケーションにわたる2つの異なる要因、すなわち、配信無線型提供とニュースおよび情報アプリとを算出するために使用される。ユーザ:いろいろなアーティストやバンドの情報が欲しい。
応答:last.fm、allmusic等の人気のアプリのリストです。
システムは、語句情報を識別し、アプリ結果のリストをよりニュースおよび情報に基づくものにフィルタリングする。
【0062】
言語分析モジュール106は、アーキテクチャ内のプラガブルモジュールであり、システムが、複数の言語をサポートすることを可能にする。ユーザ入力の意味論の理解は、言語モジュール106のみに制約されないが、対話コンテキストモジュール103またはグラフエンジン110等のアーキテクチャのコアモジュールは、言語独立型である。前述のように、言語モジュールのみでは、文を分析し、代名詞をその主語/目的語等に関連させる等のタスクを行う程度しかできず(例えば、「最近のDaniel Craigの映画のオリジナルサウンドトラック(OST)中のLed Zeppelinの曲って、誰が演奏しているの?」)、それは、孤立していては、やりとりを通して代名詞を関連付けるために、非効果的である。セッション対話コンテキストモジュール103との相互作用は、以下のように、やりとりを通して代名詞の解決を可能にする。
Q1:新しいスターウォーズでobi-wan Kenobiを演じたのは?
A:Ewan McGregor
Q2:Scarlet Johanssonとの彼の映画は?
一見、この対話セッションコンテキストは、最後のアクティブエンティティまたは複数のエンティティの単純状態維持に見えるが、以下の実施例は、対話セッションコンテキストにおける潜在的な複雑性を示す。
Q1:Kramer vs Kramerで主役を演じたのは誰?
Al:Meryl StreepとDustin Hoffmanです。
Q2:彼の他の映画は?
A2:こちらが、Dustin Hoffmanの映画の一部です・・・[Dustin
Hoffmanの映画のリスト]
Q3:彼女の他の映画は?
A3:[該当する場合、映画のリスト]
Q4:彼の初期の映画だけは?
A4:[該当する場合、映画のリスト]
Q5:彼女の最近の映画は?
A5:[該当する場合、映画のリスト]
Q6:最近、2人が再び共演したものは?
A6:[該当する場合、映画のリスト]
Q7:それ以降、2人が再び共演したものは?
前述の例では、エンティティMeryl StreepおよびDustin Hoffmanは、6つの質問において、時として、一緒に、時として、別個に、間接的に参照される。前述の例はまた、本発明の実施形態と、中心テーマの周囲での探索的やりとりに従事する単純要求応答システムとの重要な区別の1つを例証する。本発明の実施形態は、やりとりにおける曖昧性を解決するだけではなく、同時に、会話の早い段階で述べられたエンティティおよび/または意図の暗示的参照を用いた探索的やりとり、すなわち、高度なヒトの相互作用において自然に行われるものを促進する。
【0063】
以下の実施例は、ユーザが、前のやりとりにおいて明示的にさえ指定されていないエンティティを参照するもの(暗示的コネクション指向型制約)を例証する。
Q1:身体的障害を抱えた科学者が非炭素系生命体の可能性を示唆した番組は?
A:それは宇宙人に関するStephen Hawkingのディスカバリーチャンネルの番組です。
Q2:彼はDavid Attenboroughが作製した別の番組にも出演している?
エンティティおよびその属性のみに制限されない対話状態維持の別の例は、以下の例において明白であるように、システムは、意図の状態も維持し、したがって、意図が、会話のやりとりを通して維持される場合である。
Q1:娘とpulp fictionを見ることができるかな?
Al:Quentin Tarantino監督によるPulp fictionは、生々しい暴力とヌードのため、R指定されています。
Q2:彼の他の映画は?
A2:Reservoir Dogs、Jackie Brown、Kill Bill、Death Proof、全てR指定されています。
【0064】
本実施例では、システムが、Q2における(「彼」の形態で)彼の代名詞の参照を理解することを可能にする、エンティティ「Quentin Tarantino」の状態維持に加え、システムはまた、やりとりを通して、ユーザの意図、すなわち、ユーザの意図が「評価」であることを把握している。このような維持は、A2におけるように、簡潔かつ方向性をもった応答を促進し、ヒトの相互作用にほぼ一致する。
【0065】
前述に例証される方向性をもった応答は、個人化ベースの意図分析器109と密接に連携して、ドメイン特定意図およびエンティティ分析器108、109を用いて可能である。これらのモジュールは全て、関連属性(例えば、最新、あまり暴力的ではない、アクションが多い)を決定し、それらに重みを割り当てることを支援する、用途特定属性検索エンジン111によって支援される。したがって、音声テキストエンジン102から生じるユーザ入力やりとりは、前述の全モジュールが連携する(クエリ実行エンジン104は、調整役を担う)処理後、ユーザ入力の1つ以上の候補解釈をもたらすであろう。例えば、「Bombay爆弾事件に関するKay Menonの映画はある?」という質問に対する応答では、システムは、2つの代替候補表現を有し得、1つは、「爆弾事件」が別の属性であり、「Bombay」をエンティティ(Bombayと呼ばれる映画が存在する)として有し、もう1つは、「Bombay爆弾事件」を単一エンティティとして有するものである。システムは、次いで、他の認識されるエンティティである、俳優のKay Menonの存在に基づいて、ユーザとの対話に従事することによって、これらの候補表現間の解決を試みる。
【0066】
いくつかの事例では、曖昧性の解決は、ユーザの選好を把握することによって、対話に従事せずに行われることができる。例えば、ユーザは、「今夜soxの試合がある?」と尋ね得る。本質問は、曖昧な部分、すなわち、チームがBoston Red Soxであるか、Chicago White Soxであるかの曖昧性を有するが、システムが、ユーザの選好がRed Soxであることを把握している場合、応答は、その夜に試合がある場合、Red Soxの試合スケジュールを表示することを対象とすることができる。ドメインにわたって複数の一致が存在する事例では、より高い全体的信頼性スコアをもたらすドメイン一致が、残るであろう。結果の個人化もまた、適用可能であるとき、クエリの性質に基づいて、行われることができる。例えば、ユーザが、「今夜、Tom Cruiseの映画を見せて」と述べる場合、このクエリは、個人化を適用すべきではなく、Tom Cruiseの最新の映画を単に返すべきである。しかしながら、ユーザが、「今夜、スポーツを見せて」と述べる場合、システムは、個人化を適用し、ユーザアクティビティ情報の種々のソースから捕捉されたその明示的選好または暗示的アクションに基づいて、ユーザに関心があると把握されるスポーツおよび試合を表示すべきである。
【0067】
ユーザの選好(暗示的または明示的に推測される)が2値様式(オンまたはオフ「スイッチ」のように)で適用される、既存のシステムと異なり、本発明の実施形態は、コンテキスト依存様式において、ユーザ選好のシグネチャ(本開示では、個人用グラフとも称され、それは、暗示的および明示的の両方で決定される、ユーザのアクティビティおよび関心を捕捉する)を使用して、ユーザ入力における曖昧性を解決し、適用可能である場合、個人化もまた結果選択に適用し、ユーザの意図に一致する高い可能性を有する、最良の応答をもたらす。本発明のある実施形態は、利用可能である場合、ユーザ選好のシグネチャを使用して、ユーザの入力における曖昧性を解決する。しかしながら、結果を調整するためのシグネチャの使用は、前述の曖昧性解消ステップに続くユーザ入力において指定されたエンティティの定義における精度のレベルに大きく依存する。
【0068】
ユーザ選好シグネチャは、そのようなユーザ選好情報を発見および記憶するための公知の技法を使用して、システムによって提供されることができる。例えば、2010年8月10日発行の米国特許第7,774,294号「Methods and Systems for Selecting and Presenting Content Based on Learned Periodicity of User Content Selections」、2010年11月16日発行の米国特許第7,835,998号「Methods and Systems for Selecting and Presenting Content on a First System Based on User Preferences Learned on a Second System」、2008年12月2日発行の米国特許第7,461,061号「User Interface Methods and Systems for Selecting and Presenting Content Based on User Navigation and Selection Actions Associated with the Content」、および2012年2月7日発行の米国特許第8,112,454号「Methods and Systems for Ordering Content Items According to Learned User Preferences」(それぞれ、参照することによって本明細書に組み込まれる)に記載のシステムおよび方法は、本明細書に開示される技法とともに使用されることができる。しかしながら、ユーザの選好シグネチャおよび/または情報の使用は、組み込まれた出願に記載の技法に限定されない。
【0069】
関係またはコネクションエンジン110は、ユーザ入力を理解し、方向性をもった応答をもたらす役割を果たす、モジュールのうちの1つである。関係エンジンは、多くの方法で実装され得、グラフデータ構造は、名前グラフエンジンによって関係エンジンを呼び出し得るような1つのインスタンスである。グラフエンジンは、エンティティ間の既知の重み付けられたコネクションを背景として、ユーザ入力を評価する。
【0070】
エンティティの定義の精度レベルは、グラフエンジン110のノードにおいて捕捉される。グラフエンジン110における各エンティティノードは、曖昧性インデックスが割り当てられ、曖昧性インデックスは、エンティティに対する統計的決定スコアであり、例えば、「低」値から「高」値のような値の連続範囲(「低」は、低曖昧性を意味し、「高」は、高曖昧性を意味する)と、これらの終端限間の全中間値であり得る。この曖昧性インデックスは、個人用グラフ(利用可能である場合)が利用され得るとき、それを決定するために使用される。一実施例は、以下の会話である。
ユーザ:今夜試合がある?(または)私達は今夜試合する?
応答:Boston Red Soxは、今夜(7pm)Florida Marlinsと試合します。ESPN HDで視聴可能です。この例では、ユーザ入力「sox」は、高曖昧性インデックスを有する。システムは、動詞句「試合がある?」をエンティティタイプスポーツにマップし、その個人用グラフに基づいて、このユーザに対するエンティティBoston Red Soxを関連付ける。個人化するための決定は、曖昧性インデックス「sox」によって駆動されている。形容詞「今夜」は、クエリを精緻化するための時間指定子として作用する。ユーザの入力は、曖昧性を有するが、個人の選好に基づいて、ユーザの意図が「red sox」であると解決後、入力は、もはや曖昧ではないことに留意されたい(「red sox」の「低」曖昧性スコアを前提として)。故に、結果は、曖昧性インデックスが現時点において低であるため(Boston red soxにマッピング後)、個人化されない。代替変形例では、代名詞「私達」が、エンティティBoston Red Soxに関連付けられる。
別の例は、以下である。
ユーザ:私達はYankeesといつ試合する?
応答:New York Yankeesは、7月6日金曜日(7pm)にBoston
Red Soxと試合します。NESN HDで視聴可能です。
ユーザ:試合を録画してくれる?
応答:7月6日金曜日(7pm)のNew York Yankees対Boston Red Soxの録画を予約しました。
この例では、システムは、エンティティNew York Yankeesと「私達」とを抽出し、代名詞「私達」は、ユーザ個人用グラフに基づいて、エンティティBoston Red Soxに帰属させられる。
【0071】
前述で行われる個人化は、ソーシャルネットワーキングサイト、メディア消費、SMS、ツイートアクティビティ等、また、電子メールのユーザの個人用コーパス、カレンダ予定入力、タスク/トゥドゥリスト、文書等のシグネチャを含む、ユーザの過去のアクティビティのシグネチャに基づく。前述のように、ユーザの選好のシグネチャは、ある場合には、ユーザ入力(例えば、今夜「sox」の試合がある?「私達」は今夜試合する?)における曖昧性を解決するために使用されるが、ユーザ入力曖昧性の解決後、依然として、高い曖昧性インデックスを有するエンティティの発生は、ユーザの個人用グラフが、ユーザの意図に一致する結果を調整するために利用されるべき場合を決定する。例えば、ユーザが、Tom CruiseおよびDemi Mooreをその個人用グラフに有する場合でも、以下のクエリは、結果の個人化をトリガしないであろう。これは、ユーザの意図が明白かつ明確であるためである。
【0072】
ユーザ:Tom Cruiseは、Demi Mooreと共演したことがある?
これに対する応答は、このクエリにおけるエンティティが低い曖昧性インデックスを有するので、ユーザの個人用グラフ情報に該当しないであろう。しかしながら、以下のクエリの場合は、該当する。
ユーザ:今夜soxの試合がある?
個人化は、「sox」がそれに関連付けられた曖昧性インデックスを有するため、適用されるであろう。以下は、ユーザ入力における曖昧性の解決し、結果をユーザの関心に一致させるように個人化するために支援するユーザの個人用グラフのさらなる実施例を提供する。
ユーザ:「soxがSan Francisco Giantsと試合をするのはいつ?」
例1:Red Soxが、ユーザのシグネチャ内にある。
応答:「Boston Red Soxは、このシーズンは、San Francisco Giantsと試合しません。」
例2:Red Soxが、ユーザのシグネチャ内にない。
A:「Boston Red Soxですか、Chicago White Soxですか?」
エンティティのうちの1つであるSan Francisco Giantsが、明確に指定されている(曖昧性インデックスが「低」である)が、依然として、個人化を使用して、他のエンティティ「sox」(「高」曖昧性インデックスを有する)の曖昧性を解消する必要があることに留意されたい。要約すると、「高」の「曖昧性インデックス」は、「個人用グラフ」を使用して、曖昧性を解決することを意味するが、曖昧性が解決されると、「非常に精密に指定されたエンティティ」の場合、「個人化」は、回答の算出のために使用されない。しかしながら、曖昧性インデックスが、曖昧性解消ステップ後でも、高いままである場合、個人化が、適用される。
【0073】
(曖昧性解消例)
図4は、名前付きエンティティ間のコネクションおよびリンクのグラフの一部を図示する。ユーザが、「Beethovenの映画を見せて」という要求を行う場合、曖昧性は、性質上、語彙的である。すなわち、質問は、作曲家であるBeethovenに関する映画およびBeethovenと名付けられた犬の映画に一致する。図4は、抽象的意味において、作曲家であるBeethovenに対するシステム「メンタルモデル」を表す、このノードとのリンクを伴う名前付きエンティティ「Beethoven」を示す。そのリンクおよび属性が、それを犬として明確に識別する、「Beethoven」と呼ばれるエンティティと同等サブグラフが存在する。ユーザ入力が、そのような異種エンティティと一致する場合(これらのノードの属性の相関と組み合わせられたこれらの2つの間のグラフ距離は、これらのエンティティの近接性の指標である)、システムは、曖昧性が語彙的である可能性が最も高いと認識し、その重要となる異なる属性、すなわち、人間対犬を使用して、これらの2つのノードの曖昧性を解消する適切な応答を投げ掛ける。この重要となる曖昧性を解消する差異が、システムによって推定されると、生成される応答は、異なり得る。一実施形態では、システムは、曖昧性を解消する質問「作曲家ですか、Beethovenと名付けられた犬のことですか?」を投げ掛け、次いで、ユーザのフィードバックに応答し得る。
【0074】
別の実施形態では、システムは、「音楽家である場合、彼に関する2つの映画があります<かつ映画を列挙する/伝達する>。犬である場合、犬に関する2つの映画があります<かつ映画を列挙する/伝達する>」と言うことによって、曖昧性解消と回答とを単一応答に組み合わせ得る。この応答は、「検索エンジンレベル知能」と明らかに異なり、両ユーザの質問に人間と犬との間の曖昧性が存在するという理解がシステムによって提示されることなく、ある関連性の順序で、結果が列挙され、さらに混合され得る(作曲家Beethovenの結果の後、犬の映画、別のBeethovenの映画が続く)。
【0075】
別の例「Micheal Jonesって誰?」では、ユーザは、特定のMicheal Jonesに関して知ることを所望しているが、ユーザの質問に対して複数の語彙的一致が存在する。一致のうちの1つは、アメリカ人医療機関役員および退嬰政策アナリストである。他は、TV番組「American idol」に参加したオーストラリア人シンガーソングライターである。ユーザの真の意図は、「Micheal Jonesって誰?」であるため、システムにとって、曖昧性を解消する質問「American idol参加者ですか、保守的政策アナリストですか?」と応答することは、非常に滑稽であろう。これは、ユーザの真の質問は、ユーザがいずれも知らないことを示すためである。この場合、本実施形態は、ユーザが尋ねた質問に対する真の回答を兼ねる、曖昧性を解消する応答「その名前の著名な人物が2人います。1人は、American Idolに参加したシンガーソングライターで、もう1人は、保守的政策アナリストです」を立案するであろう。
【0076】
別の例「who wants to be a millionaireを見たい」の場合、米国のクイズ番組、英国のクイズ番組、およびシンガポールのクイズ番組の3つの適合する一致が存在する。1つのシナリオでは、ユーザ選好のシグネチャが、不明であるが、ユーザの場所が既知である場合、正しいクイズ番組が、暗示的に取り上げられることができる(例えば、米国にいる人の場合であれば、米国の番組等)。しかしながら、ユーザ選好のシグネチャが存在する場合、シグネチャは、ユーザの場所に優先し得る。例えば、ユーザが、仕事で英国を訪問しているが、依然として、自国、例えば、米国バージョンの視聴を希望し得る。場所またはユーザ選好のいずれも利用可能ではない場合、システムは、以下のタイプの曖昧性を解消する質問を投げ掛けるであろう「同一の名前で3つの国に3つの異なる番組が存在します。どれを視聴したいですか?<かつ3つの番組を表示する/伝達する>」。
【0077】
別の実施例「オーストラリアについて教えて」では、本開示に説明されるドメイン特定構造知識が、システムが、国であるオーストラリアと、同一の名前の2つの映画(1989年に撮影された英語の映画「Australia」および1992年に撮影された同一の名前のMalayalam語のインド映画)との間に衝突があることを識別することに役立つ。この場合、ユーザ選好のシグネチャおよび履歴、特に、ユーザの個人用コーパスから集められた情報は、ユーザが、近い将来、オーストラリアに旅行することを示し得る。この情報は、オーストラリアが国であることを指すという理解と組み合わせられ、システムによって、オーストラリアが国であることを表すユーザの質問の曖昧性を暗示的に解消するために使用され、直接、国に関する応答を表示するであろう。本明細書では、個人用コーパスおよびドメイン特定知識を使用する曖昧性解消は、やりとりを明確化することさえ排除し、システム応答をヒトの相互作用により近いものにする。
【0078】
本明細書に開示される技法およびシステムは、コンピュータシステムまたはコンピュータ化電子デバイスとの使用のためのコンピュータプログラム製品として実装され得る。そのような実装は、コンピュータ読み取り可能な媒体(例えば、ディスケット、CD-ROM、ROM、フラッシュメモリまたは他のメモリ、あるいは固定ディスク)等の有形メディア上に固定されるか、あるいは媒体を経由してネットワークに接続された通信アダプタ等のモデムまたは他のインターフェースデバイスを介して、コンピュータシステムに伝送可能であるかのいずれかである、一連のコンピュータ命令または論理を含み得る。
【0079】
媒体は、有形媒体(例えば、光学またはアナログ通信ライン)または無線技法(例えば、Wi-Fi、セルラー、マイクロ波、赤外線、または他の伝送技法)を用いて実装される媒体のいずれかであり得る。一連のコンピュータ命令は、システムに関して本明細書に前述の機能性の少なくとも一部を具現化する。当業者は、そのようなコンピュータ命令が、多くのコンピュータアーキテクチャまたはオペレーティングシステムとの使用のために、いくつかのプログラミング言語で書かれることができることを理解するはずである。
【0080】
さらに、そのような命令は、半導体、磁気、光学、または他のメモリデバイス等の任意の有形メモリデバイス内に記憶され得、光学、赤外線、マイクロ波、または他の伝送技術等の任意の通信技術を使用して伝送され得る。
【0081】
そのようなコンピュータプログラム製品は、付随の印刷または電子説明書(例えば、市販のソフトウェア)を伴う取り外し可能な媒体として配信される、コンピュータシステムに予め搭載される(例えば、システムROMまたは固定ディスク上)か、あるいはネットワーク(例えば、インターネットまたはWorld Wide Web)を経由して、サーバまたは電子掲示板から配信され得ることが予想される。当然ながら、本発明のいくつかの実施形態は、ソフトウェア(例えば、コンピュータプログラム製品)およびハードウェアの両方の組み合わせとして実装され得る。本発明のさらに他の実施形態は、全体的にハードウェアまたは全体的にソフトウェア(例えば、コンピュータプログラム製品)として実装される。
【0082】
さらに、本明細書に開示される技法およびシステムは、種々のモバイルデバイスと併用されることができる。例えば、本明細書で論じられる信号を受信可能な携帯電話、スマートフォン、携帯情報端末、および/またはモバイルコンピューティングデバイスが、本発明の実装において使用されることができる。
【0083】
本発明の種々の側面および実施形態は、以下の出願に記載され、全て、参照することによって本明細書に組み込まれる技法とともに使用されることができる。
2012年7月20日出願の米国仮出願第61/673,867号「A Conversational Interaction System for Large Corpus Information Retrieval」、
2010年9月10日出願の米国特許出願第12/879、141号「Method of and System for Presenting Enriched Video Viewing Analytics」、および
米国特許第7,774,294号「Methods and Systems for Selecting and Presenting Content Based on Learned Periodicity of User Content Selections」。
【0084】
本開示の熟読から当業者に明白となるであろうように、本開示は、前述に具体的に開示されるもの以外の形態で具現化されることができる。前述の特定の実施形態は、したがって、制限ではなく、例証と見なされる。当業者は、ルーチンにすぎない実験を使用して、本明細書に説明される特定の実施形態の多数の均等物を認識または解明可能であろう。本発明の範囲は、添付の請求項およびその均等物に記載され、前述の説明に含有される実施例に限定されない。
図1
図2
図3
図4