JP5142720B2

JP5142720B2 - デバイスの認知的に過負荷なユーザのインタラクティブ会話型対話

Info

Publication number: JP5142720B2
Application number: JP2007533468A
Authority: JP
Inventors: ウェン，フリアン; ケイブドン，ローレンス; ラグフナサン，バドリ; ミルコヴィッチ，ダニーロ; ハイアット，ローラ; シュミット，ホーク; グルエンステイン，アレクサンダー; ピーターズ，スタンリー
Original assignee: ロバートボッシュコーポレーション
Priority date: 2004-09-27
Filing date: 2005-08-10
Publication date: 2013-02-13
Anticipated expiration: 2025-08-10
Also published as: CN101189659A; EP1794747A1; CN102298928B; WO2006036328A1; JP2008514983A; CN101189659B; CN102298928A; EP1794747B1; US20060074670A1; US7716056B2; EP2296141A1

Description

［発明の分野］
本発明は、デバイスの認知的に過負荷なユーザのインタラクティブ会話型対話のための方法及びシステムに関する。

［背景情報］
音声対話インターフェースを有するシステムは、広範な用途でますます多く受け入れられてきている。しかしながら、音声対話インターフェースシステムは、限られた言語及びスクリプトによる対話のやりとりを使用することがある。詳細には、音声言語対話システムは、狭く的を絞った言語理解、及び対話のやりとりの簡単なモデルを伴うことがある。しかしながら、実際の人間の対話は、高い文脈依存性及び高い状況依存性を有し、形を成していない発話及び文の断片で満ち、高度にインタラクティブ且つ協調的である場合がある。たとえば、話者は互いに割り込み合って、互いの文に磨きをかけ、共有された文脈に共同で貢献する場合がある。

言語を理解すること及び自然な対話をモデリングすることは、使いやすい音声言語インターフェースの構築に重要な場合があり、ユーザがヘリコプタの操縦又は車の運転等の外部の仕事に集中している環境では非常に重要となる場合がある。このようなシナリオでは、ユーザは、前もって自身の発話を計画することも、適切な時刻まで「その考えを保っておく」こともできない場合がある。その代わり、ユーザは対話システムに割り込んで、文脈及び状況をもとにした命令を発行できることが必要な場合がある。逆に、対話システムは、文脈におけるこれらの貢献を解釈しなければならず、適切な場合に（たとえば、重要な状況等において）のみユーザに割り込むべきであり、システムからのどの質問も、できるだけ的を絞ったものとすべきである。したがって、高いストレスのかかったドメイン又は認知的に過負荷なドメイン、すなわち、ユーザが他の仕事に集中することを伴うドメインにおける音声インターフェースは、ロバストで広い適用範囲の言語理解を有する、より柔軟な対話を必要とする場合がある。

たとえば、自動車産業では、対話システムは、デバイスのコマンド及び制御を提供することができる。しかしながら、これらのシステムは、言語理解及び対話管理についてキーワードスポッティング（key word spotting）技法及び有限状態技法に依拠している場合がある。これらのシステムは、新しいデータベースの更新又は新しいデバイス／アプリケーションへの移植に関連する困難に遭遇する場合もある。したがって、これらのシステムによって使用される技術の限界のために、制限された音声言語表現しか扱うことができない。さらに、たとえば代名詞、あいまいさ、及び修正等のより頻繁に発生する言語現象を適切に処理することができない。

［発明の概要］
本発明の一例示の実施の形態及び／又は一例示の方法は、柔軟性を有し、ユーザがさまざまなデバイスと口頭でやりとりすることを可能にし、完全な音声言語理解、マルチスレッド化された対話管理、情報の動的更新、部分的な固有名詞の認識による豊かな対話を可能にすると共に簡単且つ効率的なプラグアンドプレイのドメイン移植を可能にする、一例示の対話システム及び／又は方法を提供する。

この点に関して、本発明による例示の対話システム及び／又は例示の方法は、人間の対話に広く行き渡っている可能性があるが既存の技術では容易にハンドリングできない一定の言語現象を理解する。詳細には、本発明による例示の対話システムは、この例示のシステムが「a」、「the」、「this」、「that」、「other」等の内容のない単語の微細な区別を理解する、完全な言語解析を提供することができる。その上、一例示の対話システムは、ユーザの発話の状況に依存した解釈及び文脈に依存した解釈も提供することができる。

本発明の一例示の実施の形態及び／又は一例示の方法は、デバイス及び情報の内容を動的に追加又は拡張できるように、動的な更新を提供することができる。この点に関して、本発明は、新しい内容の動的な更新及び新しいドメインへの高速適合を可能にする一組の技術を使用することができる。本発明の例示の実施の形態及び／又は例示の方法は、爆発的な量の内容を管理する点において、ユーザに対する使いやすさを増加させることができ、その結果、それらの技術の市場の受け入れを高速化することができる。本発明の例示の実施の形態及び／又は例示の方法は、多数のアプリケーションを可能にし、企業が、たとえば、自動車、ハンドヘルドデバイス、携帯電話等の業界で市場シェアを得ることができるように、新しいアプリケーションを迅速に追加することを可能にする。本発明の例示の実施の形態及び／又は例示の方法は、動的な内容更新を可能にすると共にユーザの好みの内容の細目（item）を管理する際により多くの便宜をユーザに提供する、新しい一組の技術を使用する。また、これらの新しい技術は、開発者／企業が、より迅速且つ費用効果のある方法で新しいアプリケーションを考え出すことも可能にすることができる。

本発明の例示の実施の形態及び／又は例示の方法は、ロバストで完全な文解析を提供する統計的自然言語理解（ＮＬＵ）モジュール、及び、文脈依存解釈をサポートし且つユーザとシステムとのやりとりを管理する対話マネージャ（ＤＭ）を含むことができる。本発明の一例示のシステム及び／又は一例示の方法は、たとえば、部分的な固有名詞への不完全な参照を伴った入力を含む、音声認識（ＳＲ）モジュール及び人間のユーザからの不完全な入力に直面した際にロバスト性を提供することができる。

本発明の一例示の対話システム及び／又は一例示の方法は、ＭＰ３音楽プレイヤ（固有名詞を取り扱う際の課題を有するドメイン）、携帯電話、ナビゲーションシステム、及び／又は他のポイントオブインタレスト（ＰＯＩ）サービスの制御を伴う対話をサポートすることができる。

［詳細な説明］
図１は、複数のデバイス１５１とのユーザのやりとりのためのエンドツーエンド音声言語処理を提供する一例示の会話型対話システム１００を示している。この例示のシステム１００は、音声強調器モジュール１０１、音声認識モジュール１０２、自然言語理解（ＮＬＵ）モジュール１０３、対話管理モジュール１０４、応答生成モジュール１０５、音声合成モジュール１０６、知識ベースモジュール１０７、知識管理モジュール１０８、韻律検出モジュール１０９、及びデバイス／アプリケーションマネージャ１１０を含む。

音声強調器モジュール１０１は、この例示の対話システム１００によって受信された音声を強調する。詳細には、強調器モジュール１０１は、たとえば、雑音低減及び／又はエコーキャンセルを提供することができる。

音声認識モジュール１０２は、音響信号を受け取り、たとえば信頼スコア等の追加ラベルを有する単語シーケンス又は単語ラティス(lattice)を出力する。この点に関して、音声認識モジュール１０２は、クラスベースのｎグラム（class-based n-gram）及び動的文法（dynamic grammar）を有するＮｕａｎｃｅ（ニュアンス）音声認識エンジンを含むことができる。ｎグラムは、確率に基づいて単語及びクラスを関係付ける統計アルゴリズムに関するものである。自然言語理解モジュール１０３は、信頼スコアが付随した単語シーケンス又は単語ラティスを受け取り、ドメイン内言語データ（in-domain linguistic data）に基づいてトレーニングされた統計モデルに基づく構造化された意味表現を出力する。この点に関して、自然言語理解モジュール１０３は、柔軟且つロバストな音声言語能力を提供することを目的としている。

対話管理モジュール１０４は、構造化意味表現を取り込み、会話の文脈及び知識ベース１０７から得られた知識に基づいて他のモジュールへ適切な命令を発行する。
知識ベース１０７は、たとえば、ユーザ、デバイス、外部環境、及び現在の文脈状況に関する知識を記憶する。知識ベース１０７は、たとえば、リレーショナルデータベース及びオントロジーデータベース（ontological database）の双方を含む１つ又は複数のデータベースを含むことができる。詳細には、知識ベース１０７は、たとえば、曲、ジャンル、アーティスト、及び他の属性の間のオントロジー関係のデータベースを含むことができる。また、知識ベース１０７は、たとえば、ナビゲーションタスク及びポイントオブインタレスト（ＰＯＩ）サービスのオントロジー関係のデータベースも含むことができる。この点に関して、知識ベース１０７は、言語理解で使用される統計モデルをトレーニングするためのドメインデータ／知識を獲得することができる。ドメインデータ／知識は、たとえば、ユーザの振る舞いをプロファイルして予測するための統計値を含むことができる。また、知識ベース１０７は、たとえば、あいまい表現を解決するための言語知識も含むことができる。この点に関して、この言語知識は、たとえば、Longman Publishing社によって出版されている「Longman Dictionary of Contemporary English (LDOCE)」又は、プリンストン大学のGeorge Miller教授及び彼の仲間によって提供されている（認知科学グループの下のプリンストン大学ウェブサイトを参照されたい）オープンリソースであるWordnetを含む、一般に利用可能な辞書及び他のソースから構築することができる。

知識管理モジュール１０８は、知識ベース１０７、一般的なオントロジー、ドメイン特有のオントロジー、及び任意のアクティブなドメインの任意のデータベースを管理する。また、知識管理モジュール１０８は、異なるモジュール間の現在の知識ベース１０７を更新すると共に同期させる。

応答生成モジュール１０５は、対話管理モジュール１０４からの内容を取り込み、この文脈の関連のある部分を選択し、それらの関連のある部分を簡潔且つ文法的に正しい様式で編成し、音声合成モジュール１０６へ入力する。この点に関して、内容選択方法を使用することができる。この内容選択方法は、たとえば、２００４年８月２０日に出願された「METHOD AND SYSTEM FOR ADAPTIVE NAVIGATION USING A DRIVER'S ROUTE KNOWLEDGE」と題する米国特許出願第１０／９２３，５９０号（この米国特許出願の全開示は、参照により本明細書に援用される）に記載されている。

音声合成モジュール１０６は、タグ付けされた特徴を有する単語シーケンスを取り入れ、音声波形を生成する。詳細には、音声合成モジュール１０６は、たとえば、ＮｕａｎｃｅＶｏｃａｌｉｚｅｒ（ニュアンスボーカライザ）を使用して実施されるテキスト／音声変換（text-to-speech）（ＴＴＳ）エンジンを含むことができる。

韻律検出モジュール１０９は、たとえば、抑揚、休止、及び継続期間の検出等の追加機能を提供して、例示のシステム１００のいくつかのモジュールの性能を改善する。このいくつかのモジュールには、たとえば、音声認識モジュール１０２、自然言語理解モジュール１０３、及び対話マネージャモジュール１０４が含まれる。この点に関して、Venkataraman他著「Training a prosody-based dialog act tagger from unlabeled data」（IEEE Intl. Conf. on Acoustics, Speech and Signal Processing, 2003）に記載された技法を使用することができる。

例示のシステム対話システム１００は、非集中的な方法で実施することができる。たとえば、Seneff他著「Galaxy-II: A Reference Architecture for Conversational System Development」（Proc. ICLSP '98, 1998）に記載されたような他のシステムによって使用されるハブアーキテクチャではなく、たとえば、イベントベースのメッセージ指向ミドルウェアを有する分散された方法で例示のシステム１００を構成して、たとえば、新しいモジュール及び／又はデバイス１５１の動的な登録を可能にすることができる。

例示の対話システム１００は、既成のコンポーネントを使用することができる。詳細には、例示の対話システム１００の構成部分は、ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＣ＋＋６．０、ＮｕａｎｃｅＶｏｃａｌｉｚｅｒ４．０、及びＮｕａｎｃｅＲｅｃｏｇｎｉｚｅｒ８．５を使用して実施することができる。例示の対話システム１００は、たとえば、任意の適した処理設備を含むことができ、たとえば、Ｉｎｔｅｌベースのマイクロプロセッサを有するパーソナルコンピュータ等を含むことができる。この適した処理設備は、たとえば、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓバージョン２０００又はＬｉｎｕｘベースの環境を含む多種多様な動作環境及び／又はアプリケーション開発環境によってサポートすることができる。例示の対話システム１００のモジュール１０１〜１０９は、共通のプラットフォーム上の同じ位置に配置してもよく、又は別法では、これらのモジュールの一部若しくは全部は別々に存在することもできることが十分理解されよう。
ＮＬＵモジュール
図１Ｂは、柔軟且つロバストな音声言語能力を提供する一例示の自然言語理解モジュール１０３を示している。この例示の自然言語理解モジュール１０３は、統計タガー（tagger）１０３ａ、統計依存パーサ(parser)１０３ｂ、特徴マッパ(mapper)１０３ｃ、及び意味分類器１０３ｄの４つのサブモジュールを含む。

統計タガー１０３ａは、隠れマルコフモデル（ＨＭＭ）を使用して、履歴に基づき品詞（ＰＯＳ）タグを予測する際の確率を表す。このモデルは、たとえば、依存テキストデータ及び／又は注釈付きテキストデータからトレーニングを受けることができる。この点に関して、統計タガー１０３ａは、たとえば、Dermataso及びKokkinakis著「Automatic Stochastic Tagging of Natural Language Texts」（Computational Linguistics, Volume 21, No. 2, 1995）に記載されているような技法を使用して実施することができ、また、ビタビアルゴリズムを使用して、適したタグシーケンスを見つけることができる。

統計依存パーサ１０３ｂは、統計タガー１０３ａによって表された統計確率を使用して、条件付き確率成分及び相互情報量成分を含む言語モデルを構築する。条件付き確率成分は、２つの主要部の２つの対応する部分木が与えられると、それらの２つの主要部の文法関係の確率を見積もる。これは、たとえば、２００３年７月３日に出願された「A FAST FEATURE SELECTION METHOD AND SYSTEM FOR MAXIMUM ENTROPY MODELING」と題する米国特許出願第１０／６１３、３６６号（この米国特許出願の全開示は、参照により本明細書に援用される）に記載されているような条件付き最大エントロピーモデリングのための選択的利得計算（selective gain computation）（ＳＧＣ）方法を使用して計算することができる。

最大エントロピー（ＭＥ）モデリングは、言語モデリング及び自然言語処理において、情報を提供するさまざまな一定の特徴を組み込むことによって言語行動を予測するのに適用することができる一般的な統計モデリングパラダイムである。各特徴は、データのコーパスからの或る言語的な統計イベントを条件付きモデルの共通のフレームワークに符号化する。この点に関して、この条件付き最大エントロピーモデルは、

の形を取ることができる。ここで、ｙは文法関係であり、ｘは、主要語、タグ、及び文法関係を含む１０次元配列によって定義される左部分木及び右部分木を表し、ｆ_ｊ（ｘ，ｙ）、λ_ｊ、及びＺ（ｘ）は、それぞれ特徴、重み、及び正規化因子である。

相互情報量成分は、左部分木の代表と右部分木の代表との間の冗長性を特徴付け、主要部タグの因子分解及びタグを与えられた単語の条件付き相互情報成分を通じて計算されることができる。

特徴マッパ１０３ｃは、統計依存パーサ１０３ｂからの依存関係を取り込み、ｆ−構造体と類似した特徴構造体の拡張可能マークアップ言語（ＸＭＬ）表現を生成する。この表現では、主要語、述語、さまざまな修飾語、並びに叙法、相及び時制等の文の特徴が明示的にリストアップされる。このマッピングは、主要部及び修飾語の一組のパターンに基づいている。これらのパターンは、単語、タグ、又は文法関係を含むことができる。

従来の他の対話システムと異なり、自然言語理解モジュール１０３は、入力文のロバストな完全解析を提供する。従来認識されていた内容のある単語が抽出されるだけでなく、他のさまざまな単語の微妙な意味も抽出される。たとえば、冠詞「a」、「the」、「this」、「that」、及び「other」は、自然言語モジュール１０３によって区別され、対話管理モジュール１０４によって適切に解釈される。たとえば、Jackson他著「A Template Matcher for Robust Natural Language Interpretation」（Darpa Speech and Natural Language Workshop, 1991）、又は「Method And System For Building and Running Natural Language Understanding Systems」と題する米国特許第６，２９２，７６７号に記載されたものを含む、従来の他のシステムのテンプレート照合器は、このような冠詞を無視すると考えられる。

自然言語理解モジュール１０３は、知識ベース１０７の動的な更新をサポートする。依存パーサ１０３ｂは、テンプレートデータに基づいてトレーニングされる。たとえば、ＭＰ３のドメインでは、トレーニングデータは、具体的な曲名は何ら含まないが、ｓｏｎｇｎａｍｅと呼ばれる汎用クラス名を含む。これは、他のクラスにも同様に当てはまり得る。構文解析中、新しい曲データベースが供給又は更新される。入力文が完全な曲名を含む場合、その名前は、最初に識別されて、そのクラス名ｓｏｎｇｎａｍｅが、代替パスとして既存の単語シーケンスに追加される。より難しいケースは、曲名が不完全な場合に起こり得る（注意散漫なユーザによくあるケース）。

たとえば曲名等の名前クラスを、曲名の集合のみに基づいてトレーニングされた別のｎグラムモデルにより定義できるクラスベースの文法（統計的又は非統計的）と、トレーニングされたｎグラムモデルとを有する音声認識器が、クラスベースの文法に動的又は静的に挿入される。この点に関して、たとえば、２００４年７月１５日に出願された「A METHOD AND APPARATUS FOR PROPER AND PARTIAL PROPER NAME RECOGNITION」と題する米国特許出願第１０／８９２，７２４号（この米国特許出願の全開示は、参照により本明細書に援用される）に記載されたような曲名データベースの場合に、９０％を超える正確度で対応する単語サブシーケンスをラベル付けする、部分的な固有名詞の認識器を設けることができる。固有名詞を有する変更された入力ラティスは、次に、解析のためにパーサに与えられる。この点に関して、本発明の例示の実施の形態及び／又は例示の方法は、たとえば、Weng他著「Parsing a Lattice with Multiple Grammers」（6^th International Workshop on Parsing Technologies, ACL/SIGPARSE, Trento, 2000）に記載されているいくつかの技法を使用することができる。

意味的話題（semantic topic）分類器１０３ｄは、統計タガー１０３ａ及び統計依存パーサ１０３ｂからの入力に基づいて話題を識別する。意味的話題分類器１０３ｄは、条件付き最大エントロピーモデリング、メモリベースのモデリング、及び／又は他の方法等の技法を使用して、入力文を意味カテゴリーに分類することができる。意味的話題分類器１０３ｄで使用されるこれらのモデルは、ラベル付けされたデータを使用してトレーニングすることができる。
対話管理モジュール
図１Ｃは、例示のシステム１０１のモジュールのやりとりを管理すると共に調停する一例示の対話管理モジュール１０４を示している。この点に関して、この例示の対話管理モジュール１０４は、たとえば、スタンフォード大学言語情報インターラクション研究センター（ＣＳＬＩ（Center for Study of Language and Information Interaction））から入手可能な対話管理アプリケーションを使用して実施することができる。この対話管理アプリケーションは、時に、「ＣＬＳＩ対話マネージャ」又は簡単に「ＣＤＭ」と呼ばれることがある。ＣＤＭは、たとえば、Larsson及びTraum著「Information state and dialogue management in the TRINDI dialogue move engine toolkit」（Natural Language Engineering, No. 6(3-4) 2000）に記載されている対話移動（dialogue-move）手法を使用して、その後に入力される発話（断片及び修正を含む）の解釈、ＮＰの分解、顕著な応答（salient response）の組み立て、発行の追跡等に使用される対話の文脈を維持する。対話の状態は、音声認識予想にバイアスをかけて、音声認識性能を改善するのに使用することもできる。ＣＤＭのより詳細な説明は、たとえば、Lemon他著「Collaborative activities and multi-tasking in dialogue systems」（Traitement Automatique des Langues (TAL), No. 43(2), 2002）に見出すことができる。
マルチドメイン設計
対話管理モジュール１０４はマルチドメイン環境をサポートし、たとえば、知的デバイスの制御及び個別指導を含む幅広い用途に対話管理モジュール１０４を適用することができる。種々の用途のドメインは、表層レベル生成（surface-level generation）の異なる文法及びデバイス特有のアクティビティモデル（ＡＭ）を指定することを伴う場合がある。アクティビティモデルは、タスクが対話管理モジュール１０４によって管理されていること及びそれらのタスクのステータスを表し、タスクへの明示的な参照を提供できるようにしている（たとえば「cancel that（それをキャンセルする）」）。アクティビティモデルは、対話管理モジュール１０４がインターフェースするエージェント又はデバイスの能力の宣言的仕様であり、動詞及びそれらの動詞の項（argument）からデバイス動作へのマッピング等の言語情報を含む。これについては、たとえば図３を参照されたい。図３は、一例示のアクティビティモデル及び言語マッピングの実施態様の例示の擬似コードを示している。「required（必要とされる）」としてマーキングされた項は、項が欠けたユーザコマンドが与えられている場合にサブ対話を生成することができる。この点に関して、例示の対話システムが新しいドメインに適用される場合に、対話管理モジュール１０４全体を取り替える必要がないように、アクティビティモデル手法は、「プラグアンドプレイ」機能を達成することを可能にする。

対話管理モジュール１０４は意味解析器コンポーネント１０４ａを含む。この意味解析器コンポーネント１０４ａは、自然言語理解モジュール１０３からの擬似ｆ−構造体から意味論理形式（semantic logical form）を組み立てて、文脈情報を必要とする対話移動タイプを取得する。たとえば、対話管理モジュール１０４が、自然言語理解モジュール１０３から発話を受け付ける時、現在の文脈を使用して意味論的な意味を抽出することができ、「顕著リスト（salience list）」を使用して指示対象を満たすことができる。この顕著リストは、会話に持ち込まれている名詞句（ＮＰ）及び目的語の表現を保持する。対話移動のタイプに応じて、新しいコマンドをアクティビティモデル（ＡＭ）に追加することもできるし、入力された発話が質問であった場合には、知識管理モジュール１０８を調べることができ、その結果の回答を自然言語理解モジュール１０３へ送ることができる。内部の対話管理モジュール１０４のコンポーネントのいくつかは、ドメイン依存プロセス及びドメイン独立プロセスを混合したものを許容することができる。ドメイン依存プロセス及びドメイン独立プロセスを混合したものでは、デフォルトプロシージャが、特定のドメインから独立に実施されるが、それらのサブプロセスのいくつかは、ドメイン依存情報を利用するように容易に構成することができる。同様に、新しいアプリケーションの場合、現在の実施態様は、コアのＣＤＭ実施態様を混乱させることなく、論理形式又は対話移動演算子の拡張も許容することができる。
マルチスレッド化された文脈管理
対話管理モジュール１０４は、マルチスレッド化された複数の話題の会話を管理するように構成される。これは、車内の状況では特に重要となり得る。この車内の状況では、ドライバは、インターリーブされる可能性のある複数のデバイスとやりとりする。たとえば、レストランを選んで予約するやりとりは、携帯電話の要求によって中断される場合がある。この点に関して、ユーザは、複数のデバイスとやりとりする時、各デバイスと個々にやりとりするのではなく、中央コントローラとやりとりしたい場合があることに留意されたい。

マルチスレッド化された会話をサポートするための対話管理モジュール１０４のコンポーネントには、対話移動木１０４ｂ及びアクティビティ木１０４ｃが含まれる。これらは、たとえば、会話の小休止後におけるタスク報告の作成及びユーザに基礎を教えること（ground）（たとえば「What were we talking about？（我々は何について話していたのか？）」）等、他の対話文脈機能のフレームワークとして機能する。

対話移動木１０４ｂは、対話の履歴文脈を表す。入力された発話は、対話移動として分類され、それ自体を、対話移動木の適切なアクティブノードにアタッチすることにより文脈において解釈される。たとえば、回答は、対応するアクティブな質問ノードにアタッチすることができる。新しい会話の話題は、新しい枝を発生させ、それ自体を最も近時のアクティブノードにアタッチすることができない対話移動は、別の枝のアクティブノードにアタッチすることができる。この別の枝は、再開された会話に対応する。

アクティビティ木１０４ｃは、現在の対話に関連のあるアクティビティを管理する。ユーザがコマンドを発行すると、この結果、新しいアクティビティが作成されて、アクティビティ木１０４ｃに追加され得る。アクティビティが実行のため実際にデバイスへ送信可能となる前に、例示のシステム１００は、たとえば、すべての名詞句（ＮＰ）を分解しようとする試み、又は、さらなる情報を引き出すサブ対話を発生させることを含めて、そのアクティビティを十分に分解しようと試みる。修正及び訂正（たとえば、「I meant/said …（つまり）」）は、既存のアクティビティ表現を編集することを伴う場合がある。アクティビティ実行は、アクティビティ木１０４ｃ上で監視され、変化の結果、たとえば失敗した完了時又は成功した完了時に出力が生成され得る。

対話移動木１０４ｂ及びアクティビティ木１０４ｃは、たとえば、会話の小休止後におけるタスク報告の生成及びユーザに基礎を教えること等、他の対話文脈機能のフレームワークとして機能する（たとえば、例示のシステム１００は、「What were we talking about？」のプロンプトでユーザに指示することができる）。また、対話移動木１０４ｂは、参照解決等のタスクの暗黙的な開示構造も提供する。
知識管理モジュール
知識マネージャ（ＫＭ）１０８は、知識ベースソース（ドメインに一般的な知識及びデバイス情報等）へのアクセス及びそれらのソースの更新を制御する。ドメイン知識は、ドメインに依存したオントロジーに従って構造化される。知識管理モジュール１０８は、たとえば、スタンフォード大学から入手可能なドメイン独立オントロジーツールであるＰｒｏｔｅｇｅを使用して実施することができる。Ｐｒｏｔｅｇｅに関するさらに詳細な内容は、たとえば、「protege.stanford.edu」のウェブサイトアドレスにおいて入手可能である。

知識管理モジュール１０８には、対話管理モジュールが、コマンド又はクエリーから組み立てられた意味記述と一致するインスタンスの問い合わせを行うことができる。たとえば、ＭＰ３ドメインでは、「play some rock music by Cher（Cherによるロック音楽の再生）」のコマンドの結果、genre=rock（ジャンル＝ロック）及びartist=Cher（アーティスト＝Cher）を有するクラスsong（曲）のオブジェクトのクエリーが生成され得る。ここで、genre及びrockは、クラスsongの（継承された）プロパティである。多数の結果が、ユーザからの制約条件を満たす場合、対話管理モジュール１０４は、オントロジー階層を使用して、それらの結果を分類し、簡潔な方法でそれらの結果を出力して、ユーザの認知的負荷を低減することができる。上述したように、知識ベースモジュール１０７は、どの時点においても新しいインスタンスによって動的に更新することができる。

加えて、知識管理モジュール１０８は、アクティビティモデル（ＡＭ）等のデバイス情報のレポジトリとしての機能も果たす。或いは、アクティビティモデル（ＡＭ）は、デバイス／アプリケーションマネージャ１１０内に存在することもできる。新しいデバイスが利用可能になると、その新しいデバイスは、自身の情報を知識管理モジュール１０８に登録する。知識管理モジュール１０８は、次に、そのデバイスをＣＤＭ１０４に利用可能にする。
デバイス／アプリケーションマネージャ
デバイス／アプリケーションマネージャ１１０は、ファクタに基づいて所与の発話（たとえば、コマンド又は質問）をハンドリングするのにどのデバイスが最も適しているかを判断する。このファクタは、たとえば、文脈における現在のデバイス、文脈の変化を示す言語的手掛かり、明示的なアドレス指定、及び／又は、特定のデバイスのアクティビティモデルに関連する言語テンプレートとのその発話の最も良い一致等である。この点に関して、デバイス／アプリケーションマネージャ１１０は、プラグアンドプレイ能力を提供するために、デバイス及び／又はアプリケーションに依存する情報を一般対話管理モジュール１０４から分離することができる。デバイス／アプリケーション管理モジュール１１０は状態情報を含む。この状態情報は、一定のデバイス又はアプリケーションのさまざまな可能な状態、及び、それらの状態の可能な一組の値を記述する。デバイス／アプリケーションに適用可能なアクティビティ、そこから提供される機能、又は特定のアクティビティ又は機能に使用される可能な言語表現は、デバイス／アプリケーションマネージャ１１０が保持して調整することができる。この点に関して、デバイス／アプリケーション特有のアイテムをドメインモデルにカプセル化することができる。ドメインモデルは、アプリケーションが最初に使用される時に公開することができる。詳細には、言語表現は、「タグ」モジュールである自然言語理解モジュール１０３に関連する統計モデルを介して、又は、他の形式を介して獲得することができる。

図４Ａは、デバイスの認知的に過負荷なユーザとインタラクティブに会話する一例示の方法４００を示している。ステップＳ４０１において、この例示のシステム１００は、デバイス及びドメインに関する情報の知識ベースを保持する。ステップＳ４０２において、例示のシステム１００は、リレーショナル形式及び／又はオントロジー形式で情報を編成する。ステップＳ４０３において、例示のシステム１００は、ユーザから音声を受け取る。ステップＳ４０４において、例示のシステム１００は、受け取った音声の雑音を低減し、エコーをキャンセルする。ステップＳ４０５において、例示のシステム１００は、受け取った音声において、休止、口ごもり、及び／又は持続時間を識別する。ステップＳ４０６において、例示のシステム１００は、音声を単語シーケンスに変換し、その単語シーケンスにおいて部分的な固有名詞を認識する。ステップＳ４０７において、例示のシステム１００は、部分的な固有名詞の境界を調整して、意味構造の正確度を高める。ステップＳ４０８において、例示のシステム１００は、ドメイン情報のモデルを使用して単語シーケンスから意味構造を識別する。ステップＳ４０９において、例示のシステム１００は、知識ベースを使用して、認知的に過負荷なユーザとの会話の文脈において意味構造を解釈する。ステップＳ４１０において、例示のシステム１００は、現在の文脈及び意味構造の解釈に基づき、デバイスに関連して実行されるオペレーションを決定する。ステップＳ４１１において、例示のシステム１００は、デバイスオペレーションを実行する。ステップＳ４１２において、例示のシステム１００は、認知的に過負荷なユーザに対する応答の内容を選択する。ステップＳ４１３において、例示のシステム１００は、選択された内容、会話の文脈、及び文法規則に基づいて応答を生成する。ステップＳ４１４において、例示のシステム１００は、応答の音声波形を合成する。

図４Ｂは、認知的に過負荷なデバイスユーザから受け取った音声から変換された単語シーケンスにおいて意味構造を識別する一例示の方法４５０を示している。ステップＳ４１５において、例示のシステムは、単語シーケンスの各単語の品詞タグを識別する。ステップＳ４１６において、例示のシステム１００は、単語シーケンスから依存構造を導出して、ドメイン情報のモデルを動的に適合させる。ステップＳ４１７において、例示のシステム１００は、依存構造を特徴構造に変換する。ステップＳ４１８において、例示のシステム１００は、品詞タグ及び特徴構造を単語シーケンスの意味的話題に関連付ける。

図５は、例示のシステム１００のユーザ１５１と複数のデバイスエージェント１６０ａ、１６０ｂ、及び１６０ｃとの間の一例示の統合インターフェースを示している。この例示の実施の形態では、ユーザ１５１には、複数のデバイスエージェント１６０ａ、１６０ｂ、及び１６０ｃとやりとりする共通インターフェースが提供される。この点に関して、対話管理モジュール１０４の単一のインスタンスが、ユーザ１５１とデバイスエージェント１６０ａ、１６０ｂ、及び１６０ｃとの間の通信を容易にすることができる。デバイス管理モジュール１１０は、各デバイスの経過を追跡でき、対話管理モジュール１０４と個々のエージェント１６０ａ、１６０ｂ、及び１６０ｃとの間のバッファとして機能することができる。したがって、デバイス管理モジュール１１０は、それ自体、ユーザ１５１が通信していると考えることができる統合されたエージェントとすることができる。

一方、デバイスの自律性を維持するには、各デバイスエージェント１６０ａ、１６０ｂ、及び１６０ｃが、自身に適用されたコマンドを独立して処理すること、それ自身のタスクを管理すること、及び、より上首尾で且つ自然なタスク対話及び実行を行うことができるようにデバイス特有の発話を対話管理モジュール１０４に追加することが必要とされる場合がある。

対話管理モジュール１０４は、ＣＳＬＩ対話マネージャ（ＣＤＭ）からの適合（adaptation）を使用して実施することができる。ＣＤＭは、対話マネージャ、対話移動木、タスク木、及びシミュレーションタスク木を使用して対話管理及びタスク実行をハンドリングする単一デバイスシステムを提供する。

本発明の一例示の実施の形態によれば、例示のシステム１００は、複数のデバイスをサポートするにもかかわらず、ユーザ１５１とデバイスエージェント１６０ａ、１６０ｂ、及び１６０ｃとの間のすべての言語通信をハンドリングする１つの対話管理モジュール１０４のみで構成することができる。この点に関して、ユーザは、あたかも単一のエージェント／デバイスのみをアドレス指定しているように感じることができる。これは、より有効なユーザインターフェースになることが明らかにされている。したがって、ユーザ１５１は、たとえば「drive to the restaurant（レストランへ車で行く）」又は「turn up the volume（音量を上げる）」等のコマンドを単に発行することができ、ＧＰＳシステム及びラジオにそれぞれ話しかけるのではなく、単一のエージェントに話しかけているように感じることができる。

例示のシステム１００が単一の対話管理モジュール１０４で構成される場合、この対話管理モジュール１０４は、タスク指向型手法を使用して、発話を正しいエージェントへルーティングする。たとえば、ユーザ１５１が発話を行うと、対話管理モジュール１０４は、その発話を取り込み、単一デバイス対話システムで行うように、その発話を対話移動木に配置する。その発話が前のどの発話にも関係しない場合（たとえば、デバイスの１つに対するコマンド）、対話管理モジュール１０４は、デバイス管理モジュール１１０と通信して、どのデバイスがこの発話を受け取るべきかを調べることができる。この例では、デバイス管理モジュール１１０は、その発話をハンドリングする適切なデバイスを識別でき、それに従って動作することができる。一方、発話が、すでに存在する会話スレッドに応答したものである場合、その発話の影響は、適切なデバイスへ自動的にルーティングすることができる。
文脈デバイス
対話管理モジュール１０４は、加えて、現在の言語文脈においてデバイスの経過を追跡することができる。デバイスが明示的にアドレス指定されるごとに、又は、一定のデバイスに対応するコマンドを行うことができるごとに、そのデバイスは、文脈における現在のデバイスとなる。また、デバイスは、それ自身が発話を行うことによって現在の文脈デバイスになることもできる。これは、たとえば、デバイス文脈管理モジュール１１１によって保持することができる。デバイス文脈管理モジュール１１１は、文脈におけるデバイスが、リセット前の論理的な時間の間、文脈に留まるのみであることを確実にする。換言すれば、或るデバイスが文脈におけるデバイスになると、そのデバイスが文脈にあり続ける期間を記録するタイマが始動される。一定の期間の終了時に、文脈におけるデバイスは、ヌルにリセットされる。タイマは、そのデバイス又は異なるデバイスがアドレス指定されるごとに、又は、発話するごとに再始動する。したがって、デバイス文脈管理モジュール１１１は、持ち回りを調整及び／又は規制することができる。この点に関して、文脈におけるデバイスは、ＭｕｌｔｉｄｅｖｉｃｅＡｐｐ又はＮＩＳＴプロジェクト（NIST project）のＣａｒＡｐｐを実行する時に現れる「ＣＡＲ」のメインパネルに出現する場合がある。
タスクに関係する対話
ユーザ１５１とデバイスとの間のタスクに関係する通信を容易にするために、統合されたＴａｓｋＴｒｅｅ（タスク木）を対話管理モジュール１０４は保持することができる。この統合されたＴａｓｋＴｒｅｅは、各エージェントがハンドリングしてきたすべてのタスクを表す。このＴａｓｋＴｒｅｅは、後述するように、対話管理モジュール１０４が、ありとあらゆるエージェントに属するタスクの進行、成功、及び失敗についてのフィードバックをユーザに提供できるように、それらのエージェントのＳｉｍＴａｓｋＴｒｅｅにおける各エージェントのタスク実行管理と同期させることができる。したがって、タスクのステータス、完了、失敗等についての報告は、ＴａｓｋＴｒｅｅが依然として生成することができる。

或いは、各デバイスが、デバイス特有のタスク指向型対話を担当することもできる。たとえば、あいまいなコマンドが与えられると、そのあいまいさを解決してタスクの実行を続けることをそのデバイスの担当とすることができる。これらの発話及びクエリーは、たとえば、単一デバイス対話システムにおける同様のクエリーと同じ方法でハンドリングすることができる。このようなデバイス生成クエリーを伴うサンプル対話を図６に示す。
分散タスク管理
本発明の一例示の実施の形態及び／又は例示の方法によれば、タスク管理は、各デバイス及び／又は各デバイスエージェントが自律的且つ別個に自身のタスクを管理することを必要とすることを伴うことができる。この点に関して、デバイス管理モジュール１１０は、対話管理１０４によってユーザコマンドが最初に与えられると、クラスＭｕｌｔｉＤｅｖｉｃｅＴａｓｋＰｒｏｐｅｒｔｉｅｓ（マルチデバイスタスクプロパティ）を使用して、一組の汎用タスクプロパティを構築することができる。これらのプロパティは、ユーザコマンドに対応するタスクの基本的なドメイン独立アイデア（domain-independent idea）を表す。これらのプロパティのスロットは、「command（コマンド）」、「direct_object（直接目的語）」、「adjectives（形容詞）」等の通常のＮＬスロットである。これらのプロパティが構築されると、デバイス管理モジュール１１０は、これらのプロパティのコピーをデバイスへ送信し、デバイスは、それぞれ、コマンドを確実にハンドリングすることができるのか、場合によってはコマンドをハンドリングすることができるのか、又は、コマンドを確実にハンドリングすることができないのかを返答する。文脈における現在のデバイスは、そのデバイスがハンドリングすることができることを告げる最初の機会を与えられ、そのデバイスがコマンドを確実にハンドリングできることを返すと、そのデバイスにタスクが自動的に与えられる。それ以外の場合には、すべてのデバイスからの回答が編集されて、あいまいさが存在する（すなわち、２つのデバイスがタスクを「確実に」ハンドリングすることができる）場合、どのデバイスに発話をハンドリングさせたいかをユーザに尋ねるクエリーが生成される。適切なデバイスが見つかった場合、そのコマンドはそのデバイスに割り当てられ、適切なノードがＴａｓｋＴｒｅｅ及びそのデバイスのＳｉｍＴａｓｋＴｒｅｅに追加され、デバイスは、それ自身でタスクの実行及び通信の残りをハンドリングする。
デバイス登録
デバイスが統合システム１００に参加するには、デバイスは、たとえば、識別、タスク機能、及びシステム特有の機能に関係する要件を含むいくつかの要件を満たすことを必要とされる場合がある。

識別に関係する要件に関して、デバイスは、デバイス管理モジュール１１０が各デバイスの経過を追跡できるように、一意の識別文字列を有することを必要とされる場合がある。各デバイスは、ＤｅｖｉｃｅＴｙｐｅ（デバイスタイプ）（すなわち、ＵＡＶ）及び一意のＤｅｖｉｃｅＮａｍｅ（デバイス名）（すなわち、ＵＡＶ１）を有することができる。ｌｆｓ、タスク管理等のあらゆるものが、識別タグとしてＤｅｖｉｃｅＮａｍｅを使用することができる。

タスク機能に関係する要件に関して、デバイスは、汎用タスク記述が与えられると、デバイスが上述しようにそのタスクをハンドリングして実行する能力を有するか否かを判定する能力を有することを必要とされる場合がある。この機能は、単一デバイスタスク及び単一エージェントタスクの双方で使用できるだけでなく、マルチデバイスタスクでも使用することができる。この機能は、デバイスのコードに見られる一連のデバイス特有の機能が実施することができる。それらの一連のデバイス特有の機能は、それらのプロパティをＭｕｌｔｉＤｅｖｉｃｅＴａｓｋＰｒｏｐｅｒｔｉｅｓ（マルチデバイスタスクプロパティ）又はＧｅｎｅｒｉｃＳｌｏｔＳｅｔ（汎用スロットセット）に取り込み、それらのプロパティを使用して、プロパティにより記述されたタスクを実行できるように感じるか否かを判断する。

システム特有の機能に関係する要件に関して、例示のシステム１００と互換性を有するために、デバイスは、他のシステム特有のクラス及び機能を供給することを必要とされる場合がある。これは、たとえば、ＴａｓｋＬＦＰａｒｓｅｒ（タスクＬＦパーサ）を含むことができる。このＴａｓｋＬＦＰａｒｓｅｒは、汎用タスクプロパティを取り込み、それらの汎用タスクプロパティから、デバイス特有のタスクプロパティ、デバイスのアクティビティモデル、ＮＰＲｅｓｏｌｖｅｒ（ＮＰ分解器）等を構築する。これらのクラスのすべて（実施しなければならないものの一例のＲｅｓｔａｕｒａｎｔＤｅｖｉｃｅ（レストランデバイス）を見る）は、デバイス特有のタスク及び対話のハンドリングを提供するのに利用することができる。各デバイス自身のＤｅｖｉｃｅＳｔａｒｔｅｒ（デバイススタータ）クラスも、このカテゴリーに入ることができる。

タスク割り当て
タスクをデバイスに割り当てる信頼性を最大にするか又は少なくとも改善するために、デバイス管理モジュール１１０は、タスクをハンドリングするデバイスを選ぶ時に、いくつかのファクタを考慮することができる。デバイス管理モジュール１１０は、文脈における現在のデバイスに第１の優先順位を与えることができる。そのデバイスがユーザコマンドをハンドリングできる場合に、そのユーザコマンドは自動的にそのデバイスに割り当てられ、続いて、タスクの実行が行われる。そうでない場合、デバイス管理モジュール１１０は、各デバイスがこのタスクをハンドリングする能力を有するか否かを各デバイスに尋ねることができ、肯定応答をしたデバイスのリストを編集する。２つの以上のデバイスが、一定のタスクをハンドリングできると考えている場合、ユーザが使用したいデバイスをより具体的に指定するようにユーザに要求するクエリーを生成することができる。サンプル対話を図６に示す。このクエリーが回答されると、選ばれたデバイスは、コマンドのハンドリングを開始できるように、通知を受ける。タスク割り当ての一例示の実施態様の例示の擬似コードを図７に提供する。
タスクのハンドリング及び実行
前述したように、各タスクは、それ自身のタスクを実行して保持する役割を有することができる。各タスクは、それ自身のＳｉｍＴａｓｋＴｒｅｅを保持することによってこれを行うことができる。これらのＳｉｍＴａｓｋＴｒｅｅは、前述したように、対話管理モジュールの単一のＴａｓｋＴｒｅｅとの同期を維持して、タスクに関係する対話、すなわち更新及び報告を容易にする。このように、各デバイスは、その実行がどのように進行しているか（すなわち、タスクが現在行われているのか、完了したのか、又は失敗したのか）に応じて、自身のＳｉｍＴａｓｋＴｒｅｅにおいて連続的にタスクを更新することができ、これらの更新は、その後、ＴａｓｋＴｒｅｅが自身を最新に維持するためにピックアップすることもできる。前述したように、これによって、対話管理モジュール１０４が、すべてのタスクの進行についてのフィードバックをユーザに提供することが可能になり得る。換言すれば、ＴａｓｋＴｒｅｅは、それぞれの個々のデバイスのＳｉｍＴａｓｋＴｒｅｅを合成したものと考えることができる。個々のデバイスは、後述するチームタスクに関するほんのわずかな場合を除いて、自身のＳｉｍＴａｓｋＴｒｅｅにのみ、自身で実行している（又は実行していた等）タスクを有する。一方、ＴａｓｋＴｒｅｅは、すべてのデバイスからのすべてのタスクの組み合わせを有し、したがって、或る意味で、それぞれの個々のＳｉｍＴａｓｋＴｒｅｅの寄せ集めであり、システムで起こっているあらゆるものを表現したものである。
対話例
図２は、ＭＰ３音楽プレイヤの制御を伴う、ユーザと図１Ａの例示のシステム１００との間の一例示の対話２００を示している。例示の対話２００は、たとえば、文脈及び外部状況に基づく広範囲にわたる名詞句（ＮＰ）の分解、動的な内容更新、あいまいさ解消、マルチスレッド化された会話、及び複雑な固有名詞を含む、例示のシステム１００がハンドリングすることができる一定の機能及びやりとりを示している。

主要な機能は、ＭＰ３音楽プレイヤを制御するための実際のサンプル対話を介して示されている。
データ収集
例示のシステム１００の性能の改善及び評価を行うために、特定のタスクの対話データを収集することができる。この点に関して、「オズの魔法使い」（ＷＯＺ）手法を使用することができる。この手法では、実験の被験者が、スマートマシンのふりをする別の部屋の人間に話し掛ける。この設定は、タスク指向型のやりとりにおける人間の振る舞いをシミュレーションする高品質対話システムの設計に必要とされる場合がある。これは、部分的には、ＷＯＺ手法が、言語の複雑さの点で会話中にユーザに対する正しい予想を設定できるからである。その結果、ＷＯＺ手法は、人対人の会話を理解するという困難な問題によってトラップされることを回避することができる。これは、最新のＮＬＰ技法の能力を超えることができる。

認知的に過負荷なシナリオをシミュレーションするために、運転シミュレータを占有タスクとして使用することができる。シミュレータの一部として、ＭｉｄｔｏｗｎＭａｄｎｅｓｓ１（ミッドタウンマッドネス１）と呼ばれるビデオゲームを使用することができる。このビデオゲームは、シカゴの中心街を舞台としている。フォースフィードバックを有するステアリングホイールが、ゲームディスプレイの前面に設置される。被験者及び魔法使いが互いを見ないように、２つの分割された部屋（被験者部屋及び魔法使い部屋と呼ばれる）を設定することができる。魔法使いは、「ディール（deal）」対話システムとして機能し、被験者は、魔法使いを知ることも見ることもなく魔法使いとやりとりする。魔法使いは、運転シーンにおける被験者の現在の状況を知るように、ビデオスプリッタを通じてゲームスクリーンを見ることができる。被験者は、ナビゲーション又は娯楽情報を必要とする時、ホイールのプッシュトゥトーク（ＰＴＴ）ボタンを押して、ヘッドマウントマイクに話し掛ける。魔法使いには、ＰＴＴが押された時にのみ、被験者の音声が聞こえる。

被験者及び魔法使いの双方からの音声は、録音ソフトウェアによってハードディスクに録音される。ＭＰ３プレイヤを動作させるための或るシナリオを組み立てることができる。このシナリオでは、被験者は、街を運転して回っている間、２つの曲リストを作成するように要求される。曲リストを作成するために、被験者は、自身のコレクションの曲について問い合わせを行い、曲を聴いて、そのリストに曲を追加するか又はそのリストから曲を削除することができる。このシナリオは、マルチスレッド化された対話を提供する。

本発明による一例示の対話システムを示す図である。一例示の自然言語理解モジュールを示す図である。一例示の対話管理モジュールを示す図である。ＭＰ３音楽プレイヤの制御を伴う、ユーザと図１Ａの例示のシステムとの間の簡単な対話を示す図である。一例示のアクティビティモデル及び言語マッピングの実施態様の例示の擬似コードを示す図である。デバイスの認知的に過負荷なユーザとインタラクティブに会話する一例示の方法を示す図である。認知的に過負荷なデバイスユーザから受け取った音声から変換された単語シーケンスにおいて意味構造を識別する一例示の方法を示す図である。図１の例示のシステムのユーザに提供される、複数のデバイスを統合する一例示のインターフェースを示す図である。図１の例示のシステムとこの例示のシステムのユーザとの間の一例示の対話を示す図である。図１の例示のシステムによって実行される一例示のタスク割り当てプロシージャの一例示の擬似コードを示す図である。

Claims

複数のデバイス及び対応するドメインに関するデバイス情報を記憶すると共にリレーショナル形式及びオントロジー形式の少なくとも一方で該デバイス情報を分類する知識ベースと、
（ａ）現在の会話の文脈で用いられるデバイスと、（ｂ）特定のデバイスのアクティビティモデルに関連する言語表現との音声の一致と、のうちの少なくとも１つに基づいて、複数のデバイスのなかから音声の内容に適した１つのデバイスを選択するとともに、
前記対応するドメインのプラグアンドプレイのために、前記知識ベース中のデバイスに依存しない情報および前記知識ベース中の他のデバイス情報から分離されている、前記知識ベース中の前記複数のデバイスの各デバイスについてのそれぞれのデバイス情報を対応するドメイン内言語表現としてカプセル化する、
デバイス／アプリケーションマネージャと、
ユーザからの音声を受け取り、該音声を単語シーケンスに変換し、完全な固有名詞及び部分的な固有名詞の少なくとも一方を認識し、かつ前記部分的な固有名詞の境界を調整する音声認識モジュールと、
前記複数のデバイスのなかから選択されたひとつのデバイスに対応する１つのドメインのドメイン内言語表現に基づいてトレーニングされた統計的依存モデルを使用し、部分的な固有名詞の境界が調整された前記単語シーケンスから得られる意味構造を出力する自然言語理解モジュールと、
前記意味構造を取り込み、会話の文脈及び前記対応するドメインに関連する前記知識ベース中の前記デバイス情報を使用して、前記意味構造を解釈すると共に応答の内容を組み立てる対話管理モジュールと、
前記対話管理モジュールからの内容を取り込み、前記文脈の関連のある部分を選択し、前記関連のある部分を文法的に正しい様式で編成して、前記応答を生成する応答生成モジュールと、
該応答の音声波形を合成する音声合成モジュールと、
を備える、対話システム。
前記デバイスは、移動電話、ナビゲーションシステム、ポイントオブインタレストサービス、オーディオデバイス、車内デバイス、及びＭＰ３プレイヤの少なくとも１つを含む、請求項１に記載の対話システム。
前記受け取った音声の雑音低減及びエコーキャンセルを提供する音声強調器をさらに備える、請求項１に記載の対話システム。
前記音声認識モジュール、前記自然言語理解モジュール、および、前記対話管理モジュールのうちの少なくとも１つのモジュールの性能を向上させるために、前記受け取った音声の抑揚、休止、及び継続期間の少なくとも１つを検出する韻律検出モジュールをさらに備える、請求項１に記載の対話システム。
新しいモジュール及び新しいデバイスの少なくとも一方の動的な登録を可能にする、請求項１に記載の対話システム。
前記自然言語理解モジュールは、前記単語シーケンスに品詞タグを割り当てる統計タガーと、条件付き確率及び相互情報量を使用して依存関係を形成する統計依存パーサと、前記依存関係を使用する、前記単語シーケンスの拡張可能マークアップ言語表現への特徴マッパとを含む、請求項１に記載の対話システム。
前記対話管理モジュールは、マルチドメイン環境をサポートする、請求項１に記載の対話システム。
前記対話管理モジュールは、マルチスレッド会話を管理する、請求項１に記載の対話システム。
前記対話管理モジュールは、デバイス特有のアクティビティモデルをサポートする、請求項１に記載の対話システム。
前記対話管理モジュールは意味解析器を含む、請求項１に記載の対話システム。
前記対話管理モジュールは、対話移動木をサポートする、請求項１に記載の対話システム。
前記対話管理モジュールは、複数の話題の会話をサポートする、請求項１に記載の対話システム。
デバイスの認知的に過負荷なユーザとインタラクティブに会話する方法であって、
複数のデバイス及び対応するドメインに関するデバイス情報の知識ベースを保持すること、
リレーショナル形式及びオントロジー形式の少なくとも一方で前記デバイス情報を編成すること、
前記ユーザからの音声を受け取ること、
該音声を単語シーケンスに変換すること、
該単語シーケンスにおいて、完全な固有名詞及び部分的な固有名詞の少なくとも一方を認識すること、
前記部分的な固有名詞の境界を調整すること、
（ａ）現在の会話の文脈で用いられるデバイスと、（ｂ）特定のデバイスのアクティビティモデルに関連する言語表現との音声の一致と、のうちの少なくとも１つに基づいて、複数のデバイスのなかから音声の内容に適した１つのデバイスを選択すること、
前記複数のデバイスのなかから選択されたひとつのデバイスに対応する１つのドメインのドメイン内言語表現に基づいてトレーニングされた統計的依存モデルを使用し、部分的な固有名詞の境界が調整された前記単語シーケンスから意味構造を得ること、
前記知識ベースを使用して、前記認知的に過負荷なユーザとの前記会話の文脈において前記意味構造を解釈するとともに前記認知的に過負荷なユーザへの応答の内容を選択すること、
該選択された内容、前記会話の前記文脈、及び文法規則に基づいて前記応答を生成すること、並びに、
前記応答の音声波形を合成すること、
を含む、デバイスの認知的に過負荷なユーザとインタラクティブに会話する方法。
前記受け取った音声の雑音を低減すること、及び
前記受け取った音声のエコーをキャンセルすること、
の少なくとも一方をさらに含む、請求項１３に記載の方法。
前記デバイスを登録することであって、それによって、該デバイスの能力を言語的意味論形式で広告する、登録すること、及び
すべてのタイプのユーザ要求について、言語的意味論形式による前記デバイスの前記能力及び前記会話の前記文脈の少なくとも一方に基づいて前記デバイスを選択すること、
をさらに含む、請求項１３に記載の方法。
前記音声認識モジュール、前記自然言語理解モジュール、および、前記対話管理モジュールのうちの少なくとも１つのモジュールの性能を向上させるために、前記受け取った音声の休止、口ごもり、及び継続期間の少なくとも１つを識別することをさらに含む、請求項１３に記載の方法。
ｎグラムモデルを名前付きセットのみに基づいてトレーニングすることにより、クラスベースの文法で固有名詞クラスを形成すること、及び
前記トレーニングされたｎグラムモデルを前記固有名詞クラスとして前記クラスベースの文法に動的に挿入すること、
をさらに含む、請求項１３に記載の方法。
前記意味構造を得ることは、
前記単語シーケンスの各単語の品詞タグを識別すること、
前記単語シーケンスから依存構造を導出することであって、それによって、前記ドメイン情報の前記モデルを動的に適合させる、導出すること、
前記依存構造を特徴構造に変換すること、及び
前記品詞タグ及び特徴構造を前記単語シーケンスの意味的話題に関連付けること、
をさらに含む、請求項１３に記載の方法。
プロセッサによって実行可能な命令のセットを記録した記憶媒体であって、該命令は以下の：
複数のデバイス及び対応するドメインに関するデバイス情報の知識ベースを保持すること、
リレーショナル形式及びオントロジー形式の少なくとも一方で前記デバイス情報を編成すること、
前記デバイスのユーザからの音声を受け取ること、
該音声を単語シーケンスに変換すること、
該単語シーケンスにおいて部分的な固有名詞を認識すること、
前記部分的な固有名詞の境界を調整すること、
（ａ）現在の会話の文脈で用いられるデバイスと、（ｂ）特定のデバイスのアクティビティモデルに関連する言語表現との音声の一致と、のうちの少なくとも１つに基づいて、複数のデバイスのなかから音声の内容に適した１つのデバイスを選択すること、
前記複数のデバイスのなかから選択されたひとつのデバイスに対応する１つのドメインのドメイン内言語表現に基づいてトレーニングされた統計的依存モデルを使用し、部分的な固有名詞の境界が調整された前記単語シーケンスから意味構造を得ること、
前記知識ベースを使用して、前記認知的に過負荷なユーザとの前記会話の文脈において前記意味構造を解釈するとともに前記認知的に過負荷なユーザへの応答の内容を選択すること、
該選択された内容、前記会話の前記文脈、及び文法規則に基づいて前記応答を生成すること、並びに、
前記応答の音声波形を合成すること、
を実行するようにさせる、プロセッサによって実行可能な命令のセットを記録した記憶媒体