JP4322907B2

JP4322907B2 - 対話装置、対話方法及びコンピュータプログラム

Info

Publication number: JP4322907B2
Application number: JP2006267981A
Authority: JP
Inventors: 武秀屋野
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2006-09-29
Filing date: 2006-09-29
Publication date: 2009-09-02
Anticipated expiration: 2026-09-29
Also published as: JP2008089729A; US8041574B2; US20080082692A1

Description

本発明は、複数のアプリケーションを操作するシステムにおいて利用可能なアプリケーションを削除された際に、ユーザに対して当該アプリケーションが利用不可能であることを通知する対話装置、対話方法及びコンピュータプログラムに関する。

従来、一つのシステム内で様々なアプリケーション（以下、アプリと称する。）が操作可能なシステムが存在する。例えば、携帯電話はネットワーク上の複数のサービス（アプリ）を操作できるシステムであり、他にも携帯電話を通じてアプリをダウンロード可能なカーナビゲーションシステムなどが開発されている。このようなシステムでは、ユーザ、或いはシステム管理者が操作するアプリを追加・削除し、操作するアプリ群の構成を変更することができる。

ところで、このようなシステムを自然言語対話で操作する方法として、アプリ毎に音声認識文法・対話手順を定義し、アプリの追加・変更と対応してアプリの音声認識文法・対話手順を追加・更新する方法が特許文献１に開示されている。この方法ではアプリの追加に伴い音声認識文法・対話手順を追加するようになっており、アプリを追加すると追加したアプリに関する音声対話が可能となっている。
特開２００４−２３４２７３号公報

ところが、特許文献１に開示される手法においては、アプリを追加・変更については動作を定義しているが、アプリが利用不可になった（削除された）場合については明らかとされていない。このため、特にユーザが意図していない状況でアプリが削除されてしまったような場合は、ユーザはそのアプリが削除されていないと認識しており、アプリの存在に関して誤解が生じる。例えば、複数ユーザが利用するシステムで利用可能であったアプリを管理者が削除する場合、管理者以外のユーザは削除されたアプリを利用可能であると認識している。或いは、アプリがサーバ上に存在する場合にはユーザが意図的に削除しなくとも、サーバ側でユーザのアプリへのアクセスを許可しないようにすると、そのアプリは利用不可となるのでユーザの意図しない所で削除されたものと同等になる。或いはユーザが意図的にアプリを削除した場合であっても、ユーザが削除したことを忘れてしまう場合もある。このような場合にアプリの存在に関する誤解が生じると、ユーザは利用不可なアプリにアクセスする入力をする場合もある。

アプリの削除が可能なシステムを自然言語で操作するためには、削除されたアプリに関する入力に対処し、削除されたアプリに関する入力を抑制せねばならない。従来方式ではアプリ追加と連動して対話手順を追加している。これと同様にアプリの消去と共に対話手順を消去すると、削除されたアプリに対する入力に対する対話手順が一切存在しなくなる。その結果、ユーザが削除されたアプリにアクセスする入力に対してシステムは確実に誤動作することになる。従ってアプリが削除されたことをユーザに通知する利用不可通知を行い、対象のアプリをユーザが利用できないことをユーザに認識させる必要がある。

アプリの削除をユーザに認識させるために、アプリを削除した時に利用不可通知をユーザに提示すると、ユーザとの対話進行とは無関係に利用不可通知を乱発することになる。このような方式ではユーザとの対話を頻繁に妨害することになる。また、ユーザが興味を持っていないアプリの利用不可通知にはユーザの関心は低いため、アプリが利用不可となったことをユーザに認識させる効果は期待できない。結果として、ユーザは削除されたアプリにアクセスする入力を繰り返し、システムは誤動作を続けるという問題がある。

本発明は上記事情に鑑みてなされたもので、ユーザとの対話中に、その対話進行に沿った利用不可通知をユーザに提示することにより、アプリが利用不可となったことを効果的にユーザに通知することができる対話装置、対話方法及びコンピュータプログラムを提供することを目的とする。

本発明に係る対話装置は、
ユーザと少なくとも音声入力により対話し、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する対話進行手段と、
前記ユーザとの対話で前記対話進行手段が参照する項目を正規項目と利用不可項目に分けて管理するとともに、前記対話進行手段が参照する項目に関連付けて音声認識文法を管理する項目管理手段と、
前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段と、
前記対話進行手段による項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する利用不可通知出力判定手段と
を具備し、
前記対話進行手段は、前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記利用不可通知出力判定手段による判定結果に基づいて利用不可通知を出力することを特徴とする。

本発明に係る対話方法は、
ユーザとの対話で参照される項目を正規項目と利用不可項目に分けて管理するとともに、前記参照される項目に関連付けて音声認識文法を管理する項目管理手段と、前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段を有する対話装置に適用される対話方法であって、
対話対象となる項目の目的を前記ユーザとの少なくとも音声入力による対話進行により達成するとともに、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する第１のステップと、
前記第１のステップによる前記項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する第２のステップと、
前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記第２のステップによる判定結果に基づいて利用不可通知を出力する第３のステップとを有することを特徴とする。

本発明に係るプログラムは、
ユーザとの対話で参照される項目を正規項目と利用不可項目に分けて管理するとともに、前記参照される項目に関連付けて音声認識文法を管理する項目管理手段と、前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段を有する対話装置を制御するためのプログラムであって、
コンピュータに、
対話対象となる項目の目的を前記ユーザとの少なくとも音声入力による対話進行により達成するとともに、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する第１のステップと、
前記第１のステップによる前記項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する第２のステップと、
前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記第２のステップによる判定結果に基づいて利用不可通知を出力する第３のステップとを実行させるためのプログラムであることを特徴とする。

本発明によれば、ユーザとの対話中に、その対話進行に沿った利用不可通知をユーザに提示することで、アプリが利用不可となったことを効果的にユーザに通知する対話装置を提供できる。

以下、本発明の実施の形態に係る対話装置、対話方法及びプログラムについて図面に従い詳細に説明する。

ところで、本発明による対話装置は何らかのアプリケーションのユーザインタフェースとなるものであり、アプリケーションにある機能を有効に動作させることを目的とするものである。特に本発明による対話装置はアプリケーションによる一つ以上の種類の機能を取り扱うために一つ以上の目的を取り扱うものであり、個々の目的を達成するためにそれぞれの目的と対応付けた話題についてユーザとの対話を行うものである。

（第１の実施の形態）
図１は、本発明の第１の実施の形態に係わる対話装置を示すブロック図である。

図１において、１００は対話装置で、この対話装置１００は、対話進行部１０１、利用不可通知出力判定部１０２、話題管理部１０３、話題更新部１０４を備えている。

対話進行部１０１は、対話対象となっている話題（項目）の目的をユーザとの対話によって達成する（話題を解決する）。対話進行部１０１は、現在の対話状態として話題情報を管理する。ここでの話題情報は話題の種類と対話の進行状態を含む情報である。対話進行部１０１は管理している話題情報（現在の話題情報）についてユーザとの対話を行い、現在の話題情報の話題（現在の話題）を解決する。対話進行部１０１は、ユーザとの対話の際には、ユーザ発話を話題情報に対応付けるなどといった入力解釈や、送出プロンプトの決定などの対話進行処理を行う。送出プロンプトは音声信号やテキスト表示・画像出力等によってユーザに提示される。対話進行部１０１は、現在の話題を解決した場合は解決時の話題情報の内容でアプリケーションの動作を実行させる。話題情報の例については後に詳述する。

対話進行部１０１は対話進行中に新規話題の導入が必要であると判定すると次に対話を行う(遷移する)可能性のある話題を収集する。この収集処理では、対話進行部１０１は、話題管理部１０３からアプリが削除されて利用不可となった話題である利用不可話題を含めた全ての話題から遷移可能性のある話題を収集する。新規話題導入の必要性判定については後に詳述する。

対話進行部１０１は遷移可能性のある話題の収集結果を利用不可通知出力判定部１０２に通知し、利用不可通知の内容等の出力判定結果を取得する。対話進行部１０１は、この判定結果に応じてユーザに利用不可通知を出力する。対話進行部１０１は遷移可能性のある話題の収集結果から、次に対話を行う話題情報(遷移話題情報)を決定する。この遷移話題情報を現在の話題情報に反映(上書き・代入等)させてユーザとの対話を継続する。

対話進行部１０１における入力解釈では、ユーザから入力される自然言語を解釈し、ユーザ入力を何らかの話題情報か或いは値に変換する。例えば、ユーザが話題の名称を入力した場合には対話進行状況が初期状態の話題情報に変換したり、ユーザが動作条件としての値を指定した場合には、例えば品詞情報などといったその値の種類の情報(データ型)を付与したりする。また、話題名称を省略した入力であっても話題を特定できる場合はある条件を指定された対話進行状況の話題情報に変換することもある。このような自然言語解釈方式は既存のものが使用できる。

対話進行部１０１は話題管理部１０３に格納されている各話題に対応付けられた対話手順と現在の話題情報にある対話進行状況を参照して対話を行う。対話手順が終了した時に対話進行部１０１はその話題を解決したと判断する。このような一つの話題を解決する対話処理は、各話題に関連付けられた対話の状態遷移図などのシナリオを参照して対話を進め、シナリオの終了まで対話状態が遷移すると話題の解決とみなす手法や、話題解決のために不足している情報を検出してユーザに要求し、不足情報がなくなれば話題の解決とみなす手法など、既存の手法を利用することができる。また、対話の際にユーザに提示する応答は入力対象の情報種別を強調表示するような画面での出力や、文章で出力するなど既存の手法を利用できる。また、応答の文章はシナリオ付随の定型文や、応答文のテンプレートに情報を与えて自動生成するなど既存の手法を利用して生成することが可能である。

利用不可通知判定部１０２は対話進行部１０１から遷移可能性のある話題の収集結果を取得し、利用不可通知の出力内容を判定する。この利用不可通知判定部１０２の動作の詳細は後に詳述する。

話題管理部１０３は現在利用可能な話題と、利用不可話題を管理する。話題はその話題の対話を進行する時に参照する情報を持ち、少なくともその話題の表現を含んでいる。この話題管理部１０３、及び話題の詳細については後に詳述する。

話題更新部１０４は対話装置１００から実行を指定できるアプリ群２００の構成を管理し、アプリ群２００の構成が変更された時に、その変更を話題管理部１０３に反映させる。例えば利用可能なアプリが追加された時に、そのアプリに関連する話題を話題管理部１０３に追加したり、利用可能なアプリが削除された時に、そのアプリに関連する話題を利用不可話題とする設定を行ったりする。管理するアプリ群２００はシステム内のアプリにアクセスする形式のアプリ（ａ）でも、ネットワークを介してアクセスする形式のアプリ（ｂ）でも良い。話題更新部１０４の詳細については後に詳述する。

次に、本発明の第１の実施の形態に係わる対話装置１００の動作について図２を参照して説明する。図２は、対話装置１００の動作を示すフローチャートである。

本対話装置１００は所定の話題についてユーザとの対話を行うものである。ユーザ或いは対話装置によって対話を開始した段階が図２に示した「Ｓｔａｒｔ」に相当し、対話を継続する必要性がなくなったときに対話を終了する。すなわち、図２の「Ｅｎｄ」で対話を終了する。

対話装置１００はユーザとの対話を開始すると、対話進行部１０１が、開始時の話題情報を現在の話題情報として設定し、この話題情報に関する対話を開始する（ステップＳ２０１）。対話進行中にはシステム応答を出力してユーザ入力を待ち受ける場合も含まれるが、このような状態はステップＳ２０１でユーザ入力まで一時停止している状態であると言える。この場合はユーザ入力やタイマイベント等を受理することでステップＳ２０１の処理が継続される。さらに対話進行部１０１は、対話が進行する各段階で、ユーザとの対話を終了するか（ステップＳ２０２）、新規話題情報の導入が必要か（ステップＳ２０３）を逐一確認する。ユーザとの対話を終了すると判定した場合は処理を終了する(Ｅｎｄ)。現在の話題を解決した後に新たに対話する話題情報が導入されなかった(見つからなかった)場合や、ユーザが対話終了の旨を通知した場合などに対話の終了と判定する。新規話題情報の導入が不要な場合は現在の話題を解決するための対話を継続する（ステップＳ２０１）。一方、ステップＳ２０３で新規話題情報の導入が必要であると判定されると、対話進行部１０１は遷移可能性のある話題を話題管理部１０３から収集する（ステップＳ２０４）。

ここで、新規話題導入が必要であるかどうかの判定（ステップＳ２０３）について説明する。対話処理部１０１が新規話題導入を行うべき状況は３種類ある。一つ目は（Ａ）ユーザが現在の話題とは異なる話題の入力をした時、二つ目は（Ｂ）現在の話題を解決するためのサブゴールとして別の話題を利用すると決定した時、三つ目は（Ｃ）現在の話題を解決した後に対話する話題を選択する時、である。対話進行部１０１はこれら（Ａ）（Ｂ）（Ｃ）に該当する状況の時に新規話題情報を導入すると判定し、話題の収集方法を決定する。

次に、ステップＳ２０５ではステップＳ２０４で収集した遷移可能性のある話題の収集結果から利用不可通知の内容について判定を行う。ステップＳ２０４、Ｓ２０５の詳細手順については後に詳述する。

ステップＳ２０５で利用不可通知を出力すると判定された場合（ステップＳ２０６でＹｅｓ）は、対話進行部１０１が利用不可通知を出力し（ステップＳ２０７）、ユーザとの対話を継続する（ステップＳ２０１）。利用不可通知を出力しないと判定された場合（ステップＳ２０６でＮｏ）は、そのままユーザとの対話を継続する（ステップＳ２０１）。

次に、対話装置１００で参照する話題情報の具体例について図３を参照して説明する。

図３では、話題情報の例として、話題「目的地設定」、「施設予約」、「レストラン検索」、「ローカルレストラン検索」の各話題情報３０１〜３０５を示している。これら話題情報３０１〜３０５は少なくとも話題の種類と各話題の対話進行状況に関する情報を含む情報である。対話進行状況に関する情報は各話題に関する対話手順の指定方法に依存する。例えば状態遷移図によるシナリオ指定の場合は対話によって遷移したノードに相当し、或いは話題を解決するために必要な情報を要求する対話処理の場合は、解決に必要な情報のリストなどが挙げられる。ここで本発明の説明に使用する話題情報及びその表記について図３を用いて説明する。話題情報は名称と引数に分割できる。名称は話題の種類を表す情報であり、“（”の左側に表記する。『目的地設定』や『レストラン検索』などがこれに相当する。引数は本対話装置１００が対話によってユーザから情報を取得すべき属性であり、“（）”の内部に相当する。引数の数は話題によって異なり、表記上では各引数を“、”によって区切る。各引数は属性の呼び名である属性名と実際に対話によって指定された値である属性値の組み合わせで定義されており、これを（属性名）：（属性値）と表記する。属性値を取得していない場合は“φ”を（属性値）に格納する。例えば図３における話題情報３０２は『話題「施設予約」において座席属性として「禁煙」という値をユーザから取得した』状態であることを意味する。話題情報３０１は、属性値を取得していないことを示している。また話題情報の属性値を取得するために別の話題情報を利用する場合には、利用する話題情報を取得対象の属性値に入れ子状に格納する。例えば図３における話題情報３０５は『話題「目的地設定」において目的地を話題「レストラン検索」を用いて決定している』状態であることを意味する。尚、詳細な属性情報の表記が必要ではない場合は、話題情報の表記を単純に話題の名称のみで表記する。

次に、図３に示す話題情報を用いた対話進行部１０１の対話処理方法の例について説明する。話題情報の属性には話題解決のために取得が必須である必須属性と必須ではない属性がある。対話進行部１０１は属性値が指定されていない必須属性が現在の話題情報の中にあれば、対話処理としてその必須属性に代入する属性値を取得するように動作する。例えば必須属性の値を入力するようにユーザに要求し、ユーザ入力を各属性に対応付けたり、ユーザに問い合わす必要がない情報であれば(現在時刻など)ユーザに要求せずに暗黙的に取得したりする。また、ユーザに情報を要求する過程において別の話題を使用する必要があるならば、その話題の話題情報を呼び出して対話を行い、呼び出した話題情報に関する対話の結果を属性値として使用する。一方、単純なコマンドの場合などには話題情報の属性数が０個の場合もあるが、そのような話題の場合は全必須属性が指定されているものとみなせる。そして、話題情報において不足している必須属性が無くなるとその話題は解決したと判定する。尚、以下では表記を簡単にするために各話題情報における属性は全て必須属性とし、全必須属性が指定されればその話題を解決したものとして説明する。

次に、話題管理部１０３及び話題更新部１０４の詳細な説明について図４、図５を用いて詳細に説明する。

この場合、話題管理部１０３は、図４に示すように利用不可話題管理部４０１と正規話題管理部４０２の２種類のデータベースから構成されている。利用不可話題管理部４０１は削除されたアプリに関する利用不可話題を管理するデータベースである。正規話題管理部４０２は対話装置１００から利用可能なアプリに関する話題を管理するデータベースである。話題の詳細については後述する。

話題更新部１０４は、利用可能なアプリの変更と連動して話題管理部１０３を更新する。新たに対話により利用可能とするアプリの追加を検出した時には、そのアプリに関する話題を正規話題管理部４０２に追加する。利用可能なアプリが削除された時には、そのアプリに関する話題を正規話題管理部４０２から利用不可話題管理部４０１に移動する。

次に、本実施の形態の説明で利用する話題の詳細な例を図５に示す。ここで、各話題（５０５，５０６，５０７、５０８）には、話題名称（例えば５０１）、話題定義（例えば５０２）、話題に対応付けられる入力解釈ルール（例えば５０３）、話題の対話進行手順（例えば５０４）が含まれる。

ここで、話題名称５０１は、その話題の表現を指定する。話題名称５０１は話題を指し示す表現として利用不可通知等で利用される。話題定義５０２は、話題情報のテンプレートとなる情報であり、本発明では「出力データ型話題名称（データ型：引数名称、・・・）」の形式で表記する。出力データ型とは、その話題を解決した時に新たに得る情報のデータ型を指定する。例えば話題「レストラン検索」の対話ではユーザとの対話によって検索条件を取得し、話題解決結果として検索結果のレストランを取得するので、出力データ型は「施設」を指定する。また、出力データ型「Void」はその話題を解決しても新たな情報を得ないことを意味する。各引数の定義には、その引数がとり得るデータ型と引数の名称を対にして記憶する。対話進行部１０１で話題「レストラン検索」の対話を開始すると判断した時には、話題定義５０２を参照して話題情報“レストラン検索（検索ジャンル：φ）”を作成し、現在の話題情報とする。引数「検索ジャンル」には話題定義５０２で指定されたデータ型であるジャンル型の値を代入できる。

入力解釈ルール５０３は、入力された表現をその話題の話題情報に変換するルールであり、本発明では「入力表現→変換結果」の形式で表記する。対話進行部１０１は話題情報に変換された結果を参照して対話進行を行う。入力表現「レストラン」は入力解釈ルール５０３に該当するので、“レストラン検索（ジャンル：φ）”に変換される。

話題の対話進行手順５０４には、その話題についてユーザとの対話を進めるための手順やルールが記載されている。進行手順には例えば対話の進行状態の遷移表などが考えられるが、本発明においては本質ではない情報なので、詳細は省略する。

図２に示すステップＳ２０４における対話進行部１０１の詳細動作について図６を用いて説明する。図６はステップＳ２０４の詳細フローチャートである。ステップＳ２０４は、対話進行部１０１において新規話題情報が必要であると判断された時に、遷移可能性のある話題を収集する動作である。図６において、まず、対話進行部１０１は収集の条件を設定する（ステップＳ６０１）。収集条件の設定方法は、新規話題情報が必要と判定されるパタンによって異なる。ステップＳ６０１の詳細動作は後述する。ステップＳ６０２ではステップＳ６０１で決定された収集条件に該当する話題を、正規話題管理部４０２から収集する。ステップＳ６０３では利用不可話題管理部４０１から収集条件に該当する話題を収集する。ステップＳ６０２で収集された話題群を『正規話題グループ』、ステップＳ６０３で収集された話題群を『利用不可話題グループ』として２種類のグループに分けた情報を全体の収集結果として出力する。

ここでステップＳ６０１の詳細動作について説明する。ステップＳ２０３において対話進行部１０１が新規話題情報の必要性について判定し、必要と判定された時にステップＳ６０１の処理を実行する。ステップＳ２０３で必要と判定するパタンは、（Ａ）ユーザが現在の話題とは異なる話題の入力をした時、（Ｂ）現在の話題を解決するためのサブゴールとして別の話題を利用すると決定した時、（Ｃ）現在の話題を解決した後に対話する話題を選択する時、の３種類である。ステップＳ６０１ではこれら（Ａ）（Ｂ）（Ｃ）のパタンによって３種類の収集条件を設定する。収集する条件の設定方法の一例として、ここでは上述の話題情報（図３）・話題の詳細（図５）を利用した収集条件設定方法について説明する。

パタン（Ａ）はユーザ入力が行われたときに確認される。ユーザ入力が現在の話題の進行とは関係の無い入力の場合に、ユーザによる新たな話題の導入である判断して新規話題の導入が必要と判定される。このパタンでは新規話題としてユーザ入力が指し示す話題を選択すればよい。従ってステップＳ６０１では、ユーザ入力に対して入力解釈ルールを適用可能な話題を収集するように収集条件を設定する。例えば「レストラン」というユーザ入力に対して入力解釈ルール（図５の５０３など）を適用して“レストラン検索（検索ジャンル：φ）”、“ローカルレストラン検索（検索ジャンル：φ）”へと話題情報に変換できるので、図５の話題群からは話題「レストラン検索」、「ローカルレストラン検索」が収集条件に合致する。

パタン（Ｂ）は対話進行部１０１がシステム応答の内容を決定している時に確認される。対話進行部１０１が現在の話題を解決するために取得すべき引数（サブゴール）を決定した時に、その取得方法として新規話題の導入が必要と判定される。このパタンでは新規話題として引数の値を取得できる話題を選択すればよい。従ってステップＳ６０１では、話題の話題定義（例えば、図５の５０２）の出力データ型と取得すべき引数のデータ型とが一致する話題を収集するように収集条件を設定する。例えば話題「目的地設定」の引数「施設」を取得するためには、図５の話題群からは新規話題として出力データ型が「施設」である話題「レストラン検索」、「ローカルレストラン検索」が収集条件に合致する。

パタン（Ｃ）は対話進行部１０１がシステム応答の内容を決定している時に確認される。対話進行部１０１が現在の話題を解決した時に、取得した対話結果を利用できる話題への遷移を促すために新規話題の導入が必要と判定される。このパタンでは新規話題として解決した話題に続けて違和感のない話題を選択すればよい。その一例として対話結果を利用して進行できる話題を選択する方法がある。そうすれば対話結果を引数に代入した選択結果の話題情報を作成し、それを現在の話題情報として利用できる。従ってステップＳ６０１では、話題の話題定義（例えば、図５の５０２）の引数のデータ型と、対話結果のデータ型が一致する話題を収集するように収集条件を選択する。例えば話題「レストラン検索」を解決して対話結果「レストランＡ」を取得した時には、図５の話題群からは新規話題としてデータ型が「施設」の引数を持つ話題「目的地設定」、「施設予約」が収集条件に合致する。

次に利用不可通知出力判定部１０２の詳細動作であるステップＳ２０５について説明する。対話進行部１０１からは話題の収集結果として正規話題グループと利用不可話題グループからなる情報が通知されている。本実施の形態では利用不可話題グループが空でなければ、利用不可話題グループに含まれる話題に関して利用不可通知を通知すると判定する。

次にステップＳ２０７について説明する。利用不可通知はユーザに対して通知対象の話題が利用不可であることを通知する役割を持つ。出力内容の生成方法としては、例えば「（話題名称）は利用できません」というテンプレートに該当する話題名称を代入し、文章を生成する手法が可能である。利用不可通知の出力方法については本発明の本質ではなく、画像等を利用した提示を含めて種々の出力方法を利用できる。

次に、具体例としてレストラン検索サービスを利用した対話システムに本発明を適用した場合を例に、本実施の形態の動作について図２、図５〜図１０を参照してより詳細に説明する。この対話システムではレストランを検索する「レストラン検索」と、特定の場所に関してより詳細なレストラン情報を持ち、詳細なレストラン検索が可能な「ローカルレストラン検索」と、一つの施設までの行き方を案内する「目的地設定」と、一つの施設の予約を行う「施設予約」の４つの話題について対話することが可能である。図５は各話題の詳細である。但し、以下の説明では、「ローカルレストラン検索」と「施設予約」の話題が利用不可となっている状況で行われるものとする（図１０）。従って、正規話題管理部４０２には、話題「目的地設定」と話題「レストラン検索」が、利用不可話題管理部４０１には、話題「施設予約」と話題「ローカルレストラン検索」が格納されている。

［対話例１］
ここでは、図７に示す対話例を説明する。

この場合、上述した（Ａ）、（Ｃ）パタンで利用不可通知を出力する例を示している。まず、ユーザ発話ＵＳＲ７−１によって対話が開始される（ステップＳ２０１）。初期状態でユーザ入力を受付けた時は終了と判定しない（ステップＳ２０２のＮｏ）。対話進行部１０１は、ユーザ入力に伴い（Ａ）パタンの新規話題情報の導入が必要かどうかを判定する（ステップＳ２０３）。初期段階では対話進行部１０１に現在の話題情報が登録されていないため、ユーザ入力は新たな話題の導入であると判定される（ステップＳ２０３のＹｅｓ）。

対話進行部１０１は遷移可能性のある話題の収集処理を実行する（ステップＳ２０４）。（Ａ）パタンで新規話題情報の導入の場合は、収集条件はＵＳＲ７−１（「レストラン」）が該当する入力解釈ルールを持つ話題である（ステップＳ６０１）。この収集条件で正規話題管理部４０２から該当する話題を収集し、正規話題グループとして{「レストラン検索」}を得る（ステップＳ６０２）。続いて同じ収集条件で利用不可話題管理部４０１から該当する話題を収集し、利用不可話題グループとして{「ローカルレストラン検索」}を得る（ステップＳ６０３）。遷移可能性のある話題の収集結果は、正規話題グループ＝{「レストラン検索」}、利用不可話題グループ＝{「ローカルレストラン検索」}である。尚“{}”はリストの表記である。

利用不可通知出力判定部１０２は、対話進行部１０１が収集した遷移可能性のある話題の収集結果に基づいて利用不可通知の有無を判定する（ステップＳ２０５）。収集結果の利用不可話題グループには「ローカルレストラン検索」があるので、「ローカルレストラン検索」が利用不可である旨をユーザに通知すると判定する。

ここでは、利用不可通知を出力すると判定したので（ステップＳ２０６のＹｅｓ）、ユーザに対して、「ローカルレストラン検索が利用できない」旨の利用不可通知ＳＹＳ７−１を出力する（Ｓ２０７）。その後もユーザとの対話処理を継続する（ステップＳ２０１）。

ステップＳ２０１では対話進行部１０１が続けて以下のような処理を行う。遷移可能性のある話題の収集結果において、正規話題グループに含まれる話題が「レストラン検索」のみであるので、新規話題を「レストラン検索」とし、それが利用できることをユーザに通知する（ＳＹＳ７−２）。その初期状態の話題情報“レストラン検索（検索ジャンル：φ）”を現在の話題情報に設定し、取得していない引数「検索ジャンル」を取得すると判定する。

引数「検索ジャンル」の値を取得すると判定すると、対話進行部１０１は（Ｂ）パタンの新規話題情報の導入が必要であると判定する（ステップＳ２０３のＹｅｓ）。この場合は取得対象のデータ型がジャンル型であるため、出力データ型がジャンル型の話題を収集条件とする（ステップＳ６０１）。しかしながら、対話対象の話題には出力データ型がジャンル型の話題は存在しないので、遷移可能性のある話題の収集結果は、正規話題グループ＝｛｝、利用不可話題グループ＝｛｝となる（ステップＳ６０２、ステップＳ６０３）。

利用不可通知出力判定部１０２は、収集結果の利用不可話題グループが空であるので利用不可通知を出力しないと判定し（Ｓ２０５、Ｓ２０６のＮｏ）、再び対話進行部１０１に処理が戻る（ステップＳ２０１）。引数「検索ジャンル」を取得するための利用可能な話題が存在しないので、対話進行部１０１は新規話題の導入を取り止めてユーザに対してジャンルの値の入力を促す（ＳＹＳ７−３）。ここでユーザの入力を待つため、ステップＳ２０１は一時停止状態となる。

続けてユーザ入力ＵＳＲ７−３が入力された。対話進行部１０１は、ユーザ入力に伴い（Ａ）パタンの新規話題情報の導入が必要かどうかを判定する（ステップＳ２０３）。ＵＳＲ７−３「和食」はＳＹＳ７−３に対する回答であるので、ユーザによる話題の変更はないと判断される（ステップＳ２０３Ｎｏ）。対話進行部１０１は「和食」を引数「ジャンル」に代入してステップＳ２０１を継続する。引数代入結果が“レストラン検索（検索ジャンル：和食）”となり、全引数を取得したので話題「レストラン検索」は解決したと判定する。対話進行部１０１は話題「レストラン検索」に対応するアプリを動作させて和食のレストランを検索し、その検索結果として得た「和食□屋」をユーザに提示する（ＳＹＳ７−４）。

現在の話題を解決すると、対話進行部１０１は（Ｃ）パタンの新規話題情報の導入が必要であると判定する（Ｓ２０３のＹｅｓ）。この場合は対話結果の施設型情報「和食□屋」を利用できる話題として、施設型の情報を引数に持つ話題を収集条件とする（ステップＳ６０１）。この収集条件によると遷移可能性のある話題の収集結果は、正規話題グループ＝｛「目的地設定」｝、利用不可話題グループ＝｛「施設予約」｝となる（ステップＳ６０２、ステップＳ６０３）。

利用不可通知出力判定部１０２は、遷移可能性のある話題の収集結果の利用不可話題グループに「施設予約」があるので、「施設予約は利用不可」である旨の利用不可通知を出力すると判定する（Ｓ２０５、Ｓ２０６のＹｅｓ）。そしてステップＳ２０７で利用不可通知ＳＹＳ７−５を出力する。その後もユーザとの対話処理を継続する（ステップＳ２０１）。

ステップＳ２０１では対話進行部１０１が続けて以下のような処理を行う。遷移可能性のある話題の収集結果において、正規話題グループに含まれる話題が「目的地設定」のみであるので、新規話題を「目的地設定」とし、それが利用できることをユーザに通知する（ＳＹＳ７−６）。その後も話題「目的地設定」を解決するためのユーザとの対話は継続していく。

この対話例のように、本実施の形態ではユーザが指定した可能性のある話題から利用不可となった話題を検出して通知することが可能であり（ＳＹＳ７−１）、また、ユーザに対話進行する話題の指定を促す前に、その状況で利用しうる話題から利用不可となった話題を予めユーザに提示することが可能である（ＳＹＳ７−５）。

［対話例２］
次に、図８に示す対話例を説明する。

この場合、上述した（Ａ）パタンで利用不可通知を出力する例で、そのまま終了する例を示している。

まず、ＵＳＲ８−１の入力で対話が開始する（ステップＳ２０１）。初期段階のユーザ入力は新規話題の導入であると判定される（ステップＳ２０３のＹｅｓ）。入力解釈ルールにＵＳＲ８−１を適用できる話題を収集条件として（ステップＳ６０１）、遷移可能性のある話題情報を収集する（ステップＳ６０２、ステップＳ６０３）。遷移可能性のある話題情報の収集結果は、正規話題グループ＝｛｝、利用不可話題グループ＝｛「ローカルレストラン検索」｝となる。

利用不可通知出力判定部１０２は、遷移可能性のある話題の収集結果の利用不可話題グループに「ローカルレストラン検索」があるので、「ローカルレストラン検索は利用不可」である旨の利用不可通知を出力すると判定する（Ｓ２０５、Ｓ２０６のＹｅｓ）。そしてステップＳ２０７で利用不可通知ＳＹＳ８−１を出力する。その後もユーザとの対話処理を継続する（ステップＳ２０１）。

ステップＳ２０１では対話進行部１０１が続けて以下のような処理を行う。遷移可能性のある話題の収集結果の正規話題グループが空であり、現在の話題情報も存在しないので、対話の継続が出来ないと判断しユーザとの対話を終了する（ステップＳ２０２のＹｅｓ）。

この対話例のように、本実施の形態ではユーザが指定した話題が利用不可となったことを通知することが可能である（ＳＹＳ８−１）。

［対話例３］
次に、図９に示す対話例を説明する。

この場合、上述した（Ｂ）パタンで利用不可通知を出力する例を示している。

まず、ＵＳＲ９−１の入力で対話が開始する（ステップＳ２０１）。初期段階のユーザ入力は新規話題の導入であると判定される（ステップＳ２０３のＹｅｓ）。入力解釈ルールにＵＳＲ９−１を適用できる話題を収集条件として（ステップＳ６０１）、遷移可能性のある話題情報を収集する（ステップＳ６０２、ステップＳ６０３）。遷移可能性のある話題情報の収集結果は、正規話題グループ＝｛「目的地設定」｝、利用不可話題グループ＝｛｝となる。

利用不可通知出力判定部１０２は、収集結果の利用不可話題グループが空であるので利用不可通知を出力しないと判定し（Ｓ２０５、Ｓ２０６のＮｏ）、再び対話進行部１０１に処理が戻る（ステップＳ２０１）。遷移可能性のある話題の収集結果において、正規話題グループに含まれる話題が「目的地設定」のみであるので、新規話題を「目的地設定」とし、それが利用できることをユーザに通知する（ＳＹＳ９−１）。その初期状態の話題情報“目的地設定（目的地：φ）”を現在の話題情報に設定し、取得していない引数「目的地」を取得すると判定する。

引数「目的地」の値を取得すると判定すると、対話進行部１０１は（Ｂ）パタンの新規話題情報の導入が必要であると判定する（ステップＳ２０３のＹｅｓ）。この場合は取得対象のデータ型が施設であるため、出力データ型が施設型の話題を収集条件とする（ステップＳ６０１）。その結果、遷移可能性のある話題の収集結果は正規話題グループ＝｛「レストラン検索」｝、利用不可話題グループ＝｛「ローカルレストラン検索」｝となる（ステップＳ６０２、ステップＳ６０３）。

利用不可通知出力判定部１０２は、遷移可能性のある話題の収集結果の利用不可話題グループに「ローカルレストラン検索」があるので、「ローカルレストラン検索は利用不可」である旨の利用不可通知を出力すると判定する（Ｓ２０５、Ｓ２０６のＹｅｓ）。そしてステップＳ２０７で利用不可通知ＳＹＳ９−２を出力する。その後もユーザとの対話処理を継続する（ステップＳ２０１）。

ステップＳ２０１では対話進行部１０１が続けて以下のような処理を行う。遷移可能性のある話題の収集結果において、正規話題グループに含まれる話題が「レストラン検索」のみであるので、新規話題を「レストラン検索」とし、それが利用できることをユーザに通知する（ＳＹＳ９−３）。現在の話題の対話進行状況が話題「目的地設定」の引数「目的地」を取得する状態なので、新規話題情報は引数「目的地」を取得するための話題であると判定され、現在の話題情報を“目的地設定（目的地：レストラン検索（検索ジャンル：φ））”と設定する。次に取得すべき引数は、入れ子となった話題で未解決な引数である「検索ジャンル」となる。その後も話題「レストラン検索」を解決するための話題が継続される。

この対話例のように、本実施の形態では、ユーザに対話進行する話題の指定を促す前に、その状況で利用しうる話題から利用不可となった話題を予めユーザに提示することが可能である（ＳＹＳ９−２）。

このように本実施の形態では、アプリが削除されても、関連する話題を削除せずに利用不可となった話題として利用不可話題管理部４０１に記憶し、ユーザ入力時や対話進行時に利用可能性のある話題を利用不可となっている話題も含めて探索し、その探索結果に利用不可話題を含めばその話題に関して利用不可通知を出力する。従って、対話進行に沿った話題に限定して利用不可通知を出力することが可能となる。

対話進行に沿った話題はユーザの関心度が高い話題であるため、そのような話題に限定した利用不可通知は、対話進行と無関係な話題を含む利用不可通知よりも効果的にユーザに伝わると考えられる。対話進行と無関係な話題を含む利用不可通知を出力する場合は、ユーザに対して対話開始時・或いは対話中の何らかのタイミングで「ローカルレストラン検索と施設予約はご利用になれません」と利用不可話題に関する利用不可通知を全て出力しなければならない。この出力では話題の個数が増加した時に、利用不可通知の情報量が多くなり、ユーザの関心がない情報の中に必要な情報が隠れてしまい、ユーザの関心のある話題が利用不可となったことをユーザが認識できなくなる。

以上のように本実施の形態では、利用可能な話題と共に利用不可となった話題も記憶し、対話進行中に利用可能性がある話題を探索する際に、利用可能・利用不可の両方の話題を対象として探索を行い、探索結果に利用不可となった話題が含まれている場合は利用不可通知を出力することにより、アプリの削除により利用不可となった話題を対話進行に沿って提示することが可能となる。

なお、対話装置１００でユーザによる音声入力を受け付けるためには、対話進行部１０１のユーザ入力解釈時に音声認識エンジンを利用した音声認識を行う必要がある。そして音声認識を行うためにはユーザ入力の内容を定める音声認識文法を音声認識エンジンに対して指定する必要がある。本実施の形態では（Ａ）パタンのように利用不可話題に関する入力も考えられるが、音声認識文法に利用不可話題に関するものがなければ、利用不可話題に関する内容の音声入力が必ず誤認識されてしまう。従って、本実施の形態の音声認識文法は利用不可話題に関する音声認識文法も含めておかねばならない。

ここで、本実施の形態の説明で利用する音声認識文法の詳細な例を図２６に示す。話題の文法２６０１は、その話題を表現する入力パタンを列挙したものであり、２６０１は３つの入力パタン（２６０４、２６０５、２６０６）からなる。各パタンの表記は“()”が話題の各引数に該当する値を読み込むものであり、“（店舗）”にはその引数に代入できる施設型の値の音声認識文法（２６０２、２６０３）を読み込める。また、“施設予約＜しせつよやく＞”のように“”で囲まれた箇所は、囲まれた文字列のみを対象とする表記であり、“表記文字列＜表記文字列の読み＞”と記述している。例えば『（店舗） “を予約＜をよやく＞”』の文法では、例えば「和食□屋を予約」といった内容の発話を受理でき、認識結果として表記文字列のリストを出力できる。値の文法２６０２、２６０３は、そのデータ型に該当する値の音声認識文法を列挙したものである。一つの値について複数の表現が割り当てられる可能性もある（２６０３）。個別の表記は話題の文法２６０１の各要素と同じものである。

本実施の形態では図２５のように音声認識文法を話題と関連付けて管理する(２５０１)。図２６の２６０１が話題「施設予約」を表現する音声認識文法であり、これは図２５の２５０１に格納されるものである。また、値の文法２６０２、２６０３は話題の文法の一部として２５０１に取り込んでもよいが、複数の話題で共有して利用可能な場合は話題と別のデータベースに記憶することも考えられる。

対話進行部１０１はユーザとの対話中に音声認識エンジンに対して音声認識文法を指定する。音声認識エンジンに対して設定する音声認識文法を話題の音声認識文法と区別するために「全体音声認識文法」と呼ぶ。指定するタイミングは対話開始段階や、ユーザに対して応答を出力してユーザ入力を待つ段階など様々なタイミングが考えられる。本実施の形態においては全体音声認識文法を話題管理部１０３に登録されている正規・利用不可を含めた全話題に関する音声認識文法を統合したものとする。このようにすれば話題管理部１０３の更新と連動した全体音声認識文法を設定することが可能になり、また、利用不可となった話題に関する音声認識文法も設定できるようになる。

音声認識を利用する上での別構成として図２７のような構成にすることも考えられる。この構成は話題別に音声認識文法を管理するのではなく、正規・利用不可を含めた全話題を加味した音声認識文法を音声認識文法管理部２７０５に記憶するというものである。この場合は話題管理部１０３の内容が更新された時に、その更新と連動して音声認識文法管理部２７０５を更新する。

以上のように、本実施の形態では話題と関連付けて音声認識文法を管理するので、アプリが削除されても利用不可話題に関連付けられた音声認識文法を設定できる。従って利用不可話題に関する音声入力を受理し、その話題に関する利用不可通知を出力することが可能となる。

（変形例）
なお、上述の例では話題管理部１０３や、話題更新部１０４が対話装置１００内に格納するかのように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば、図１と同一部分には、同符号を付して示す図１１のようにネットワークを介するなどして対話装置１００外に話題管理部１０３や、話題更新部１０４を配置することも可能である。このような場合はネットワークを介して話題にアクセスする。

また、上述の例では話題管理部１０３の構成が、利用不可話題管理部４０１と正規話題管理部４０２の二つのデータベースからなるように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば、話題管理部１０３で利用可能な話題と利用不可話題の両方をまとめて管理することも考えられる。このような場合は図１２のように話題に「利用不可フラグ」（１２０１）を持たせる。話題更新部１０４はアプリが削除された時に関連する話題の利用不可フラグを“TRUE”（利用不可）に反転させるようにする。そして図２のステップＳ２０４の詳細手続きを図１３のように動作させる。即ち、ステップＳ１３０２で利用不可フラグ等に関係なく収集条件に該当する話題を収集し、ステップＳ１３０３で利用不可フラグに基づき正規話題グループと利用不可話題グループに分類する。このようにすれば利用不可通知出力判定部１０２の動作は変更せずに利用不可通知出力の判定が可能となる。以上のように正規話題と利用不可話題を区別することができる構成であれば、そのような構成は本発明の主旨の範囲内である。

また、上述の例では話題更新部１０４では利用可能となった話題を正規話題管理部４０２に登録するとしているが、この処理を省略し、利用不可となった話題のみを利用不可話題管理部４０１に登録するように動作しても良い。上述の例では利用可能な話題も収集するので利用可能な話題の例示も可能であるが、利用不可話題のみを登録するようにすれば利用不可通知の出力のみが可能となる。

以上のように利用不可な話題を収集し、利用不可通知の出力に利用することが可能な構成であれば、そのような構成は本発明の主旨の範囲内である。

また、上述の例では話題の詳細例を図５のように話題名称・話題定義・入力解釈ルール・対話進行手順からなると記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば、対話進行部１０１が状態遷移形式のシナリオで動作する場合、話題定義が不要となりえる。また、入力解釈ルールも話題毎に定義しているが、入力解釈ルールが全話題を考慮して統合されたルールで構成されている場合は、話題毎の入力解釈ルールは不要となる。また、対話進行手順も話題毎に管理しているが、対話の動作を動的生成する場合には不要となる場合もある。或いは全話題を考慮して統合された対話進行手順が構成された場合は、話題毎の対話進行ルールは不要となる。

話題の詳細情報と同様に収集条件の設定方法も上述の例に限定されない。収集条件の設定パタンには（Ａ）（Ｂ）（Ｃ）の３種類があるが、各パタンで利用可能性のある話題を収集することが可能な条件であれば、それらは本発明の主旨の範囲内である。

例えば（Ａ）ユーザが現在の話題とは異なる話題の入力をした時については、ユーザ入力が指し示す可能性のある話題が利用可能性のある話題である。この方針に沿う方法として、実際に入力解釈処理を行い、入力解釈結果として出力された話題全てを収集する方法も考えられる。この手法であれば話題毎の入力解釈ルールでなく、全話題を統合した入力解釈ルールを参照しても実行できる。

例えば（Ｂ）現在の話題を解決するためのサブゴールとして別の話題を利用すると決定した時については、サブゴールを満たす値を取得する話題が利用可能性のある話題である。この方針に沿う方法として、引数を取得するための話題を対話進行手順に記載しておき、その記載に基づいて収集する方法も考えられる。この方法であれば話題定義を参照しなくとも対話進行手順を参照するのみで実行できる。

例えば（Ｃ）現在の話題を解決した後に対話する話題を選択する時については、解決した話題に続けて違和感の無い話題が利用可能性のある話題である。この方針に沿う方法として、対話進行手順における各話題の対話が終了する場面に、次に対話して違和感の無い話題を記載しておき、その記載に基づいて収集する方法も考えられる。この方法であれば話題定義を参照しなくとも対話進行手順を参照するのみで実行できる。

また、例えば（Ｂ）（Ｃ）の収集条件はデータ型の一致に基づいて収集条件を定めているが、データ型が階層的に表現される場合は、データ型の一致でなくてもその包含関係に基づき等価とされるデータ型に基づき収集する話題を決定しても良い。

以上のように新規話題の導入時に利用可能性のある話題を収集することができる話題の詳細情報・収集条件設定方法を採用するものであれば、それは本発明の主旨の範囲内である。また、話題名称も対象の話題の名前をテキストで指定するかのように記述しているが、ユーザに話題名称の表現がどの話題に対応付けられるかわかる情報であれば良い。例えば画面を利用してユーザに利用不可通知を出力する場合は、その話題を表す絵文字（アイコン）を話題名称とし、利用不可通知の際にはこの絵文字と“×”とを組み合わせた表示を見せても良い。或いは絵文字とテキストとの組み合わせといった方法も可能である。

また、ステップＳ２０３における新規話題情報の導入の必要性判定において、（Ｂ）現在の話題を解決するためのサブゴールとして別の話題を利用すると決定するタイミングについても上述の例に限定されない。上述の例では対話進行部１０１が特定の属性の属性値を取得することを決定した時にステップＳ２０３でＹｅｓと判定し、遷移可能性のある話題の収集処理（Ｓ２０４〜）に移行している。しかし、例えば対話進行部１０１が特定の属性の属性値を取得すると決定し、一旦ユーザに対して「目的地の場所を入力して下さい」のように出力し、この出力に対してユーザからのヘルプ要求や入力のタイムアウトが生じ、より詳細な手続きの提示が必要とされた時に、ステップＳ２０３でＹｅｓと判定することも可能である。

また、ステップＳ２０３における新規話題情報導入の可能性において、（Ｂ）（Ｃ）においてはサブゴール解決を決定した時、現在の話題を解決した時は全てＹｅｓと判断するように記述しているが、収集しても該当する話題が存在しないことが明らかな場合はＮｏと判断しても良い。例えば、上述の例ではジャンル型の引数の値を取得するための話題を収集し、空の収集結果を得てから「ジャンルをどうぞ」という出力となっているが、出力データ型にジャンル型がある話題定義が話題管理部１０３に存在しないことを確認すると、新規話題が必要と判断せず(Ｓ２０３のＮｏ)にそのまま「ジャンルをどうぞ」という出力を出しても良い。

以上のように新規話題への遷移可能性のタイミングを検出する手法をＳ２０３に採用している構成であれば、そのような構成は本発明の主旨の範囲内である。

また、利用不可メッセージは「対象のアプリは利用できない」旨だけではなく、「対象のアプリは削除された」旨を通知しても良い。削除された旨を通知すれば、以後ユーザが再アクセスしないようにする効果が強まる。

また、上述の例では話題更新部１０４はアプリ単位の追加・削除を扱うと記載しているが、話題と対応付けられている機能単位の追加・削除を扱っても良い。このような場合、話題更新部１０４は機能と対応付けられている個々の話題を対象として、利用不可に設定する等の更新処理を行う。

以上のように、利用可能な話題と共に利用不可話題も記憶しておき、ユーザとの対話進行中にその両者の話題群から利用可能性のある話題を収集し、収集結果の中に利用不可話題を検出すると利用不可通知を出力するものであれば、そのような実施の形態は本発明の主旨の範囲内である。

（第２の実施の形態）
第1の実施の形態では、利用不可話題を対象として利用不可通知を出力するものであったが、利用可・不可の管理を話題単位でなく、項目として値(データ)単位を用いても第1の実施の形態と同様に利用不可通知を出力することができる。本実施の形態では、値単位で利用不可通知を出力する対話装置１００を提供するものである。

ここで、値単位での利用不可通知とは、例えばある施設「レストランＡ」が移転等で存在しなくなった場合に、ユーザがレストランを検索する時に「レストランＡが利用できないデータである」ことを通知するものである。ユーザに対して出力する内容としては「レストランＡは利用できません」といったものが考えられる。

本実施の形態における対話装置１００の構成図を図１４に示す。この場合、対話装置１００は、対話進行部１４０１、利用不可通知出力判定部１４０２、呼称管理部１４０３、呼称更新部１４０４を備えている。第1の実施の形態との変更点は、対話進行部１４０１の詳細動作と、話題管理部１０３が呼称管理部１４０３に、話題更新部１０４が呼称更新部１４０４に変更されたことである。これらの違いは利用不可通知を出力するために管理する情報の単位が話題から値に変更されたことに起因するものである。

以下、第２の実施の形態について説明する。

本実施の形態における対話進行部１４０１の動作は基本的には第1の実施の形態における対話進行部１０１と同じである。第1の実施の形態における対話進行部１０１との違いは、本実施の形態における対話進行部１４０１では話題の変更が必須ではなく、第1の実施の形態における対話進行部１０１で実行していた新規話題導入に関する処理は不要となっていることである。

また、本実施の形態における対話進行部１４０１では、（Ｄ）ユーザ入力によって値が通知された時と、（Ｅ）あるデータ型の情報の入力をユーザに促すと決定した時に、それぞれに関する呼称データ群を呼称管理部１４０３から収集処理が追加されていることも、第1の実施の形態における対話進行部１０１と異なる点である。呼称データの詳細については後に詳述する。

本実施の形態における呼称管理部１４０３は、現在利用可能な呼称データと、利用不可となった呼称データ（利用不可呼称データ）を管理する。呼称データは対話装置１００からアクセスするデータベース３００に登録されている一つの値とそれを対話で利用する時に参照する情報を持ち、少なくともその値の表現を含んでいるデータ構造である。呼称管理部１４０３、及び呼称データの詳細については後に詳述する。

呼称更新部１４０４は対話装置１００からアクセスできるデータベース３００の内容を管理し、データベース３００の内容が変更された時に、その変更を呼称管理部１４０３に反映させる。例えば利用可能な値が追加された時に、その値に関連する話題を呼称管理部１４０３に追加したり、利用可能な値が削除された時に、その値の呼称データを利用不可呼称データとする設定を行ったりする。この動作は第1の実施の形態における話題更新部１０４の管理単位を話題から呼称データに変更したものと同じである。

次に、本実施の形態に係わる対話装置１００の動作について図１７を参照して説明する。図１７は対話装置１００の動作を示すフローチャートである。

本対話装置はユーザと対話を行うものであり、対話を開始した段階が図１７の「Ｓｔａｒｔ」に相当し、対話が終了した時に「Ｅｎｄ」に遷移する。ユーザとの対話進行（ステップＳ１７０１）、対話終了判定（ステップＳ１７０２）は第1の実施の形態におけるステップＳ２０１、ステップＳ２０２と同様である。

ステップＳ１７０３で呼称データの収集が必要であると判定されると、対話進行部１４０１は所定の条件に該当する呼称データを呼称管理部１４０３から収集する（ステップＳ１７０４）。

呼称データの収集が必要であるかどうかの判定（ステップＳ１７０３）について説明する。対話処理部１４０１が呼称データの収集を行うべき情報は上述の（Ｄ）（Ｅ）の２種類である。対話進行部１４０１はこれら（Ｄ）（Ｅ）に該当する状況の時に呼称データの収集を行うと判定し、呼称データの収集方法を決定する。

ステップＳ１７０５ではステップＳ１７０４で収集した呼称データの収集結果から利用不可通知の内容について判定を行う。ステップＳ１７０４、ステップＳ１７０５の詳細手順については後に詳述する。

利用不可通知の出力有無の確認（ステップＳ１７０６）、利用不可通知の出力（ステップＳ１７０７）の処理は、第1の実施の形態におけるステップＳ２０６、ステップＳ２０７と同様である。利用不可通知を出力しないと判定された場合（ステップＳ１７０６のＮｏ）は、そのままユーザとの対話を継続する。

ここで、呼称データについて詳細に説明する。図１５は呼称データの例である。呼称データにはデータベース３００に登録されている値(１５０３)と、その値の表現である値名称（１５０１）、値のデータ型（１５０２）を対にした情報である。値名称１５０１は、その値に対する利用不可通知を出力する際に利用される。

本実施の形態における呼称管理部１４０３の構成を図１６に示す。呼称管理部１４０３は、第1の実施の形態における話題管理部１０３と同様に、利用不可呼称管理部１６０１と正規呼称管理部１６０２の２種類のデータベースからなる。利用不可呼称管理部１６０１は削除された値に関する利用不可呼称データを管理するデータベースである。正規呼称データ管理部１６０２は本対話装置からアクセス可能な値に関する呼称データを管理するデータベースである。

呼称更新部１４０４は、第1の実施の形態における話題更新部１０４と同様にして利用可能な値の変更と連動して呼称管理部１４０３を更新する。新たに対話により利用可能とする値の追加を検出した時には、その値に関する話題を正規呼称管理部１６０２に追加する。利用可能な値が削除された時には、その値に関する呼称データを正規呼称管理部１６０２から利用不可呼称管理部１６０１に移動する。

次にステップＳ１７０４における対話進行部１４０１の詳細動作について図１８を用いて説明する。図１８はステップＳ１７０４の詳細フローチャートである。

ステップＳ１７０４は、対話進行部１４０１において呼称データの収集が必要とされた時に呼称データを収集する処理である。まず、対話進行部１４０１は収集の条件を設定する（ステップＳ１８０１）。収集条件の設定方法は、呼称データの収集が必要と判定されるパタンによって異なる。ステップＳ１８０１の詳細動作は後述する。ステップＳ１８０２、ステップＳ１８０３については、収集する情報の単位が話題から呼称データに変更された点以外は第1の実施の形態におけるステップＳ６０２、ステップＳ６０３と同様である。収集された呼称データ群は『正規呼称データグループ』・『利用不可呼称データグループ』のグループ分けした情報を全体の収集結果として出力する。

ここでステップＳ１８０１の詳細動作について説明する。ステップＳ１７０３において対話進行部１４０１が呼称データ収集の必要性について判定し、必要と判定された時にステップＳ１８０１の処理を実行する。ステップＳ１７０３で必要と判定するパタンは、（Ｄ）ユーザ入力によって値が通知された時、（Ｅ）あるデータ型の情報の入力をユーザに促すと決定した時、の２種類である。ステップＳ１８０１ではこれら（Ｄ）（Ｅ）のパタンによって２種類の収集条件を設定する。以下にそれぞれの収集条件設定方法について説明する。

パタン（Ｄ）はユーザ入力が行われたときに確認される。ユーザ入力によって何らかの値が通知されれば、その値が利用不可かを確認するために呼称データの収集が必要であると判定される。このパタンではユーザ入力によって通知された値に該当する呼称データを収集すれば良い。従ってステップＳ１８０１では、ユーザ入力で通知された値と呼称データに登録されている値が合致する呼称データを収集条件とする。

パタン（Ｅ）は対話進行部１４０１がシステム応答の内容を決定している時に確認される。対話進行部１４０１が現在の話題を解決するためにユーザに情報入力を促す引数を決定した時に、その引数に入力できる値の中に利用不可の値が含まれるかを確認するために呼称データの収集が必要であると判定される。このパタンでは入力を促す引数のデータ型に該当する値を収集すれば良い。従ってステップＳ１８０１では、入力を促す引数のデータ型と呼称データに登録されているデータ型が合致する呼称データを収集条件とする。

次に利用不可通知出力判定部１４０２の詳細動作であるステップＳ１７０５について説明する。このステップは第1の実施の形態におけるステップＳ２０５と同様に、利用不可呼称データグループが空でなければ、利用不可呼称データグループに含まれる呼称データ（値）に関して利用不可通知を通知すると判定する。

次に、具体例として施設情報検索を利用した対話システムに本発明を適用した場合を例に、本実施の形態の動作について図１７〜図２１を参照してより詳細に説明する。この対話システムは話題定義「詳細情報施設情報検索（施設：対象施設）」で表される話題のみしか扱えない。この話題による対話システムの動作はユーザから施設名を受け取るとその施設に関する情報を提供するというものである。また、対話システムのデータベースには施設データとして“restaurant-A”と“restaurant-B”が登録されている。

但し、以下の説明では、“restaurant-B”は利用不可となっている状況で行われるものとする（図１９）。従って、正規呼称データ管理部１６０２には、“restaurant-A”が、利用不可呼称データ管理部１６０１には“restaurant-B”が格納されている。

［対話例４］
ここでは、図２０に示す対話例を説明する。

この場合、（Ｅ）パタンで利用不可通知を出力する例を示している。まず、ＵＳＲ２０−１の入力で対話が開始する（ステップＳ１７０１）。このユーザ入力は話題情報“施設情報検索（対象施設：φ）”と解釈される。初期段階では対話の終了とは判定しない（ステップＳ１７０２のＮｏ）。この解釈結果は値ではないので、対話進行部１４０１は呼称データ収集を実行しないと判定する（ステップＳ１７０３のＮｏ）。対話進行部１４０１は、この解釈結果を現在の話題情報として登録し、ユーザとの対話を継続する。そして対話進行部１４０１が、引数「対象施設」の情報をユーザから取得すると決定する。この決定は呼称データ収集パタン（Ｅ）に該当するため、対話進行部１４０１は呼称データ収集を実行する（ステップＳ１７０３のＹｅｓ）。

ステップＳ１８０１では（Ｅ）パタンの収集条件を決定する。取得対象の引数のデータ型は「施設」であるので、対話進行部１４０１はデータ型が「施設」の呼称データを呼称管理部１４０３から収集すると決定する。対話進行部１４０１は対象の呼称データを正規呼称管理部１６０２から収集し、正規呼称データグループ＝{“restaurant-A”}を得る（ステップＳ１８０２）。続けて利用不可呼称管理部１６０１からも同様に呼称データを収集し、利用不可呼称データグループ＝{“restaurant-B”}を得る（ステップＳ１８０３）。

利用不可通知出力判定部１４０２は、利用不可呼称データグループに“restaurant-B”があるので、「“restaurant-B”は利用不可」である旨の利用不可通知を出力すると判定する（ステップＳ１７０５、ステップＳ１７０６Ｙｅｓ）。そしてステップＳ１７０７で利用不可通知ＳＹＳ２０−１を出力する。その後もユーザとの対話処理を継続する（ステップＳ１７０１）。

ステップＳ１７０１では対話進行部１４０１が続けて以下のような処理を行う。既に引数「対象施設」の情報を取得すると決定した状態であり、呼称データ収集が終了した段階であるため、ユーザに対して対象施設の入力を促す応答（ＳＹＳ２０−２）を出力する。その後もユーザとの対話を継続する。

この対話例のように、本実施の形態ではユーザに情報入力を促す前に、その情報に関して利用不可となった値を予めユーザに通知することが可能である。

［対話例５］
次に、図２１に示す対話例を説明する。

この場合、（Ｄ）パタンで利用不可通知を出力する例を示している。

まず、ＵＳＲ２１−１の入力で対話が開始する（ステップＳ１７０１）。このユーザ入力は値“restaurant-B”と解釈される。初期段階では対話の終了とは判定しない（ステップＳ１７０２Ｎｏ）。この解釈結果は値なので、対話進行部１４０１は呼称データ収集パタン（Ｄ）で呼称データを収集すると判定する（ステップＳ１７０３Ｙｅｓ）。

対話進行部１４０１は（Ｄ）パタンでの呼称データ収集条件として、値“restaurant-B”の呼称データを取得すると決定する（ステップＳ１８０１）。そして正規呼称管理部１６０２、利用不可呼称管理部１６０１から呼称データを収集する（ステップＳ１８０２、ステップＳ１８０３）。呼称データ収集の結果は、正規呼称データグループ＝｛｝、利用不可呼称データグループ＝｛“restaurant-B”｝となる。

利用不可通知出力判定部１４０２は、利用不可呼称データグループに“restaurant-B”があるので、「“restaurant-B”は利用不可」である旨の利用不可通知を出力すると判定する（ステップＳ１７０５、ステップＳ１７０６Ｙｅｓ）。そしてステップＳ１７０７で利用不可通知ＳＹＳ２１−１を出力する。その後もユーザとの対話処理を継続する（ステップＳ１７０１）が、現在の話題情報が設定されていないのでユーザとの対話を終了する（ステップＳ１７０２のＹｅｓ）。

このように、本実施の形態ではユーザが入力した値が利用不可であるかどうかを確認し、利用不可の場合はその旨をユーザに通知することができる。尚、この例では初期段階からユーザが値を通知する例であるが、（Ｄ）パタンの判定には対話進行状況は含まれていないので、対話装置１００からの質問に対する回答といったユーザ入力に対してもこの例と同様に利用不可か否かを判定して利用不可通知を出力することが可能である。

この対話例のように本実施の形態では、データベースの値が削除されても、関連する呼称データを削除せずに利用不可となった値の呼称データとして利用不可呼称管理部１６０１に記憶し、ユーザ入力時や対話進行時に利用可能性のある呼称データを利用不可の呼称データも含めて探索し、その探索結果に利用不可の呼称データを含めばその呼称データに関して利用不可通知を出力する。従って、対話進行に沿った値に限定して利用不可通知を出力することが可能となる。

対話進行に沿った値はユーザの関心度が高い情報であるため、そのような値に限定した利用不可通知は、対話進行と無関係な値を含む利用不可通知よりも効果的にユーザに伝わると考えられる。対話進行と無関係な値を含む利用不可通知を出力する場合は、ユーザに対して対話開始時・或いは対話中の何らかのタイミングで「レストランＢはご利用になれません」と利用不可な値に関する利用不可通知を全て出力しなければならない。この出力では利用不可な値の個数が増加した時に、利用不可通知の情報量が多くなり、ユーザの関心がない情報の中に必要な情報が隠れてしまい、ユーザの関心のある値が利用不可となったことをユーザが認識できなくなる。

以上のように本実施の形態は、利用可能な値と共に利用不可となった値も記憶し、対話進行中に利用可能性がある値を探索する際に、利用可能・利用不可の両方の値を対象として探索を行い、探索結果に利用不可となった値が含まれている場合は利用不可通知を出力することにより、データベースからの値の削除により利用不可となった値を対話進行に沿って提示することが可能となる。

なお、本対話装置１００でユーザによる音声入力を受け付けるためには、対話進行部１４０１のユーザ入力解釈時に音声認識エンジンを利用した音声認識を行う必要がある。そして音声認識を行うためには全体音声認識文法を音声認識エンジンに対して指定する必要がある。本実施の形態では（Ｄ）パタンのように利用不可な値に関する入力も考えられるが、音声認識文法に利用不可呼称データに関するものがなければ、利用不可呼称データに関する内容の音声入力が必ず誤認識されてしまう。従って、本実施の形態の全体音声認識文法は利用不可話題に関する音声認識文法も含めておかねばならない。

本実施の形態では図２８のように音声認識文法を呼称データと関連付けて管理する(２８０１)。図２６の２６０２が値「和食□屋」を表現する値の音声認識文法であり、これを２８０１に格納する。対話システムで利用可能な話題に関する音声認識文法は呼称データと別に管理する。

対話進行部１４０１はユーザとの対話中に音声認識エンジンに対して全体音声認識文法を指定する。指定するタイミングは対話開始段階や、ユーザに対して応答を出力してユーザ入力を待つ段階など様々なタイミングが考えられる。本実施の形態における全体音声認識文法は呼称管理部１４０３に登録されている正規・利用不可を含めた全呼称データに関する音声認識文法と、利用可能な話題に関する音声認識文法を統合したものとする。このようにすれば呼称管理部１４０３の更新と連動した音声認識文法を設定することが可能になり、また、利用不可となった値に関する音声認識文法も設定できるようになる。

音声認識を利用する上での別構成として第１の実施の形態における図２７のように音声認識文法管理部２７０５で音声認識文法を一元管理する手法も考えられるが、この場合は呼称管理部１４０３が更新された時にその更新と連動して音声認識文法管理部２７０５を更新する。

以上のように、本実施の形態では呼称データと関連付けて音声認識文法を管理するので、呼称データが削除されても利用不可呼称データに関連付けられた音声認識文法を設定できる。従って利用不可呼称データ（利用不可な値）に関する音声入力を受理し、関連する値に関する利用不可通知を出力することが可能となる。

（変形例）
なお、上述の例では呼称管理部１４０３や、呼称更新部１４０４が対話装置１００内に格納するかのように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば第1の実施の形態における図１１と同様に対話装置１００外に呼称管理部１０３や呼称更新部１０４を判定することも可能である。このような場合はネットワークを介して呼称データにアクセスする。

また、上述の例では呼称管理部１４０３の構成が、利用不可呼称管理部１６０１と正規呼称管理部１６０２の二つのデータベースからなるように記述しているが、これも第一の実施の形態の説明と同様に、呼称データに「利用不可フラグ」を追加し、呼称管理部１４０３で一元管理することも可能である。呼称更新部１４０４はデータベースの値が削除された時に関連する値の呼称データの利用不可フラグを更新して利用不可状態に設定する。対話進行部１４０１が呼称データを収集する時には利用不可フラグに基づいて正規呼称データグループか利用不可呼称グループに分類する。以上のように正規呼称データと利用不可呼称データを区別することができる構成であれば、そのような構成は本発明の主旨の範囲内である。

また、上述の例では呼称更新部１０４では利用可能となった値に関する呼称データを正規呼称管理部１６０２に登録するとしているが、この処理を省略し、利用不可となった値に関する呼称データのみを利用不可呼称管理部１６０１に登録するように動作しても良い。上述の例では利用可能な値に関する呼称データも収集するので利用可能な値の例示も可能であるが、利用不可呼称データのみを登録するようにすれば利用不可通知の出力のみが可能となる。

以上のように利用不可な値に関する呼称データを収集し、利用不可通知の出力に利用することが可能な構成であれば、そのような構成は本発明の主旨の範囲内である。

また、上述の例では呼称データの詳細例を図１５のように値名称・データ型・値からなると記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば値に名称やデータ型が付属していたり、自動生成できたりする場合は対応する情報が不要となる。また、呼称データ管理部１４０３外に全ての値とデータ型の対応を記憶したデータベースがあれば、それを参照してデータ型を取得することも可能であり、このような場合も呼称データからデータ型を省略することができる。

呼称データの詳細情報と同様に収集条件の設定方法も上述の例に限定されない。収集条件の設定パタンには（Ｄ）（Ｅ）の２種類があるが、各パタンで利用可能性のある呼称データを収集することが可能な条件であれば、それらは本発明の主旨の範囲内である。

例えば（Ｄ）ユーザ入力によって値が通知された時については、ユーザから指定された値が利用可能性のある値である。この方針に従えばユーザ入力に複数の値が含まれるような入力の場合は、入力に含まれる全ての値を対象として呼称データを収集することも考えられる。例えば、ユーザから複数の施設を列挙されたり（「レストランＡとレストランＢ」）、複数の属性の条件を指定されたり（「レストランＢ（施設）の営業時間情報（提供する情報の種類）」した場合がこれに該当する。前者の例ではレストランＡとレストランＢに関する呼称データを収集し、後者の例ではレストランＡと営業時間情報に関する呼称データを収集する。

例えば（Ｅ）あるデータ型の情報の入力をユーザに促すと決定した時については、そのデータ型の値が利用可能性のある値である。呼称データとは別に値とデータ型との対応を記憶したデータベースが存在する場合は、このデータベースを参照して該当する値の呼称データを収集しても（Ｅ）の利用可能性に合致する収集方針であると言える。このような場合は呼称データ内のデータ型情報を参照せずに呼称データの収集が可能となる。また、データ型が階層的に表現される場合は、データ型の一致でなくてもその包含関係に基づき等価とされるデータ型に所属する値の呼称データを収集しても良い。

以上のようにユーザによる値が入力された時、対話進行中にユーザに情報の入力を促す時に利用可能性のある値の呼称データを収集することができる呼称データの詳細情報・収集条件設定方法を採用するものであれば、それは本発明の主旨の範囲内である。

また、値名称も対象の値の名前をテキストで指定するかのように記述しているが、ユーザに値名称の表現がどの値に対応付けられるかわかる情報であれば良い。例えば画面を利用してユーザに利用不可通知を出力する場合は、その値を表す絵文字（アイコン）を値名称とし、利用不可通知の際にはこの絵文字と“×”とを組み合わせた表示を見せても良い。或いは絵文字とテキストとの組み合わせといった方法も可能である。

また、ステップＳ１７０３における呼称データ収集の必要性判定において、（Ｅ）あるデータ型の情報の入力をユーザに促すと決定するタイミングについても上述の例に限定されない。上述の例では対話進行部１４０１が特定の引数を取得することを決定した時にステップＳ１７０３でＹｅｓと判定し、呼称データの収集処理（ステップＳ１７０４〜）に移行している。しかし、例えば対話進行部１０１が特定の属性の属性値を取得すると決定し、一旦ユーザに対して「対象施設を入力して下さい」のように出力し、この出力に対してユーザからのヘルプ要求や入力のタイムアウトが生じ、より詳細な値の提示が必要とされた時に、ステップＳ１７０３でＹｅｓと判定することも可能である。

また、ステップＳ１７０３における呼称データ収集の必要性判定において、（Ｄ）ユーザ入力によって値が通知された場合についても上述の例に限定されない。上述の例ではユーザ入力の解釈結果が話題情報の場合には（Ｄ）パタンの対象外としているが、例えばユーザ入力の解釈結果が“施設情報検索（対象施設：restaurant-B）”（「レストランＢの施設情報を検索」）であった場合は、その引数に与えられている“restaurant-B”が利用不可かどうかを確認でき、ユーザ入力に値が含まれる場合は（Ｄ）パタンに該当し、ステップＳ１７０３でＹｅｓと判定できる。この場合の収集条件はユーザ入力に含まれる値全てを対象とできる。

以上のようにユーザ入力やシステムから情報収集を促すタイミングを検出する手法をＳ１７０３に採用している構成であれば、そのような構成は本発明の主旨の範囲内である。

また、利用不可通知は「対象の値は利用できない」旨だけではなく、「対象の値は削除された」旨を通知しても良い。削除された旨を通知すれば、以後ユーザが再アクセスしないようにする効果が強まる。

以上のように、利用可能な呼称データと共に利用不可呼称データも記憶しておき、ユーザとの対話進行中にその両者の呼称データ群から利用可能性のある呼称データを収集し、収集結果の中に利用不可呼称データを検出すると利用不可通知を出力するものであれば、そのような実施の形態は本発明の主旨の範囲内である。

ここで、上述した第1の実施の形態と第２の実施の形態との類似性について説明する。第１の実施の形態と第２の実施の形態は基本的には利用不可通知を出力するために管理する項目が異なるだけである。即ち、話題管理部１０３の管理する項目を話題から呼称データに変更したものが呼称管理部１４０３である。話題更新部１０４と呼称更新部１４０４や、利用不可通知出力判定部１０２と１４０２との関係も同様である。また、対話進行部１０１と１４０１については、上記項目を収集すると判定する詳細な条件や実際に項目を収集する際に詳細な収集条件は異なるものの、ユーザ入力や対話進行状況に応じて利用不可通知出力のための項目を収集すると決定し、項目を収集するという動作は同じである。

第１と第２の実施の形態の動作を図２、図６と図１７、図１８で比較すると、その動作が同じものであると言える。以下詳細に比較する。

対話進行部がユーザと対話し（ステップＳ２０１、ステップＳ１７０１）、対話中に対話の終了を逐次検出し（ステップＳ２０２、ステップＳ１７０２）、ユーザ入力や対話進行状況（主に対話進行部がユーザに入力を促すと決定した場面）に応じて利用不可通知出力のための項目（話題、呼称データ）を収集するか否かを判定する（ステップＳ２０３、ステップＳ１７０３）。

対話進行部が利用不可通知出力のために項目を収集すると決定すると（ステップＳ２０３、ステップＳ１７０３でＹｅｓ）、対話進行部が項目を収集するための条件を設定し（ステップＳ６０１、ステップＳ１８０１）、項目を管理するデータベースである話題管理部１０３、呼称管理部１４０３から利用不可通知出力のための項目を収集する（ステップＳ６０２およびステップＳ６０３、ステップＳ１８０２およびステップＳ１８０３）。

利用不可通知出力判定部が項目収集結果に利用不可となった項目（利用不可項目）が含まれるか否かに基づいて利用不可通知の出力内容を決定し（ステップＳ２０５、ステップＳ１７０５）、利用不可通知を出力するならば（ステップＳ２０６Ｙｅｓ、ステップＳ１７０６Ｙｅｓ）、決定された利用不可通知をユーザに対して出力する（ステップＳ２０７、ステップＳ１７０７）。

また、音声入力を利用する場合についても、第１、第２の実施の形態の何れも管理している各項目と対応付けて音声認識文法を管理し、音声認識エンジンに設定する音声認識文法を利用可能・利用不可を含めた全呼称データに関する音声認識文法を統合したものとするという動作であると言える。従って第１と第２の実施の形態は音声認識文法の操作に関して同じ動作であると言える。

以上のように第１の実施の形態と第２の実施の形態で異なる点は利用不可通知を出力するために管理する項目の内容が異なるだけであり、この他の種類の項目であっても項目の収集条件や収集方法が定まっていれば同様に動作すると考えられる。従って、利用不可となった項目を削除せずに管理しておき、ユーザ入力や対話進行状況に応じて項目を収集し、その収集結果に基づいて利用不可通知を出力する対話装置１００は本発明の主旨の範囲内である。

（第３の実施の形態）
第１及び第２の実施の形態では、利用不可となった項目全てについて利用不可通知を出力するものであったが、出力する項目数が多くなると利用不可通知そのものの量が増加するため、ユーザが把握しやすい内容の利用付加通知を出力できないことも考えられる。本実施の形態では利用不可通知の量を抑制する対話装置を提供する。

本実施の形態における対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２または図１７である。本実施の形態が第１及び第２の実施の形態と異なる部分は利用不可通知出力判定部１０２（１４０２）の詳細動作であり、フローチャートではステップＳ２０５、ステップＳ１７０５に相当する。以下、利用不可通知出力判定部１０２（１４０２）の動作について説明する。尚、以下では表記を簡単にするために第１の実施の形態の表記のみを使用する。

本実施の形態における利用不可通知出力判定部１０２は、利用不可通知の情報量を制限する。例えば対象とする項目の個数をしきい値処理によって限定する。しきい値は予め指定する。また、利用不可項目の選択方法は任意である。この選択結果について利用不可通知を出力するように対話進行部１０１に通知する。

或いは利用不可通知を文章として提示する場合は、その長さが一定量を下回るように利用不可通知を出力する対象を選択する。文章をテキスト表示する場合は文字数、音声出力する場合は出力の時間長に基づいて選択する。

以上のように本実施の形態では、利用不可通知の対象とする項目の個数を限定し、利用不可通知の情報量を削減することにより、ユーザが把握しやすい情報量の利用不可通知を提示することが可能となる。

（第４の実施の形態）
第３の実施の形態では、利用不可通知の情報量を抑制するために単純なしきい値処理によって、利用不可通知を出力する対象の項目の個数を限定するものであった。本実施の形態では各項目の利用状況に基づいて、より適切に利用不可通知の出力対象の項目を選択する対話装置を提供するものである。

本実施の形態における対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２または図１７である。本実施の形態が第１及び第２の実施の形態と異なる部分は利用不可通知出力判定部１０２（１４０２）の詳細動作であり、フローチャートではステップＳ２０５、ステップＳ１７０５に相当する。また、話題や呼称データといった項目の詳細内容も第１及び第２の実施の形態とは異なる。以下、それぞれについて説明する。尚、以下では表記を簡単にするために第１の実施の形態の表記のみを使用する。

本実施の形態における利用不可通知出力判定部１０２は、利用不可通知の対象とする項目を各項目の利用状況に基づいて限定する。この選択結果について利用不可通知を出力するように対話進行部１０１に通知する。項目の利用状況、利用不可通知出力判定部１０２の詳細動作は後述する。

図２２は本実施の形態における項目の詳細例である。この図では例として話題（２２０３）と呼称データ（２２０４）を示している。本実施の形態における項目には利用状況（２２０１、２２０２）が追加されていることが特徴である。

利用状況の例として、（１）各項目の利用頻度、（２）各項目の最終利用時刻、（３）利用不可通知の回数、（４）利用不可項目として収集された回数、が考えられる。これらの利用状況はユーザとの対話中に対話進行部１０１が検出することができる項目である。また、これらの利用状況は一回の対話毎にリセットするものではなく、対話装置１００の運用中の一つ以上の対話を通して集計される。以下それぞれの利用状況の詳細とそれを使用した利用不可通知出力判定部１０２の詳細動作（ステップS２０５）について説明する。

（１）各項目の利用頻度とは、対話装置１００の運用中に当該項目が利用された回数を表す。例えば、項目が話題の場合は、ユーザがその話題を対象として対話装置１００と対話した回数であり、項目が呼称データの場合は、ユーザがその呼称データに関連付けられた値を対話中に参照した回数である。

ユーザは利用頻度が多い項目をより強く記憶していると考えられ、利用頻度が多い項目が利用不可となった場合にはユーザに対して優先的に通知する必要がある。従って、利用不可通知出力判定部１０２はこの利用頻度が多い項目を利用不可通知の対象として優先的に採用する。例えば利用頻度のしきい値処理によってしきい値より大きい利用頻度を持つ項目について利用不可通知を出力すると判定する。

（２）各項目の最終利用時刻とは、対話装置１００の運用中に当該項目が最後に利用された時刻を表す。例えば、項目が話題の場合は、ユーザがその話題を対象として対話装置１００と対話した最後の時刻であり、項目が呼称データの場合は、ユーザが関連する値を参照した最後の時刻である。

ユーザはより最近に参照した項目を強く記憶していると考えられ、現在の時刻と最終利用時刻が近い値となっている(新しい)項目が利用不可となった場合にはユーザに対して優先的に通知する必要がある。従って、利用不可通知出力判定部１０２はこの最終利用時刻が新しい項目を利用不可通知の対象として優先的に採用する。例えば、最終利用時刻のしきい値処理によってしきい値より新しい最終利用時刻を持つ項目について利用不可通知を出力すると判定する。

（３）利用不可通知の回数とは、対話装置１００の運用中に当該項目に関する利用不可通知を出力した回数を表す。例えば、項目が話題の場合は、ユーザがその話題に関して対話装置１００から利用不可通知を受けた回数であり、項目が呼称データの場合は、ユーザが関連する値に関して対話装置１００から利用不可通知を受けた回数である。

ユーザはより多くの利用不可通知を受けた項目については、利用不可となったことを強く記憶していると考えられ、利用不可通知の回数が少ない項目があるならば、回数が少ない項目が利用不可となったことを優先的に通知する必要がある。従って、利用不可通知出力判定部１０２は、この利用不可通知の回数が少ない項目を利用不可通知の対象として優先的に採用する。例えば、利用不可通知の回数のしきい値処理によってしきい値より少ない利用不可通知回数を持つ項目について利用不可通知を出すと判定する。

（４）利用不可項目として収集された回数とは、対話装置１００の運用中において、ユーザとの対話中に利用不可通知を出力するために項目を収集した時に、当該項目が利用不可項目として収集された回数である。

利用不可項目として収集された回数が多い項目は、ユーザとの対話中に利用されうる可能性が多数あったものであり、その項目に対して利用不可通知を出していれば、ユーザはその項目が利用できないことを認識しており、その項目に対して利用不可通知を出していなければ、ユーザはその項目を利用せずに対話が進行していることになり、この項目に対してユーザ関心が少ないものと考えられる。いずれの場合にも利用不可項目として収集された回数が多ければ、今後ユーザがその項目を利用する可能性は少ないものとなる。従って、利用不可通知出力判定部１０２は、この利用不可項目として収集された回数が少ない項目を利用不可通知の対象として優先的に採用する。例えば、利用不可通知の回数のしきい値処理によってしきい値より少ない利用不可通知回数を持つ項目について利用不可通知を出すと判定する。

本実施の形態における利用不可通知出力判定部１０２は、以上に示した利用状況のうち一つ以上の条件を収集し、利用不可通知出力の判定に利用する。複数の利用状況による判定を組み合わせる場合は、使用する利用状況に優先順位を与える。例えば、（３）利用不可通知の回数よりも（１）利用頻度の方が、ユーザの関心がより強く現れる条件であるとして、利用頻度の条件を優先的に採用することなどが考えられる。

以上のように本実施の形態では、対話装置１００の運用中に集計される項目の利用状況を加味して利用不可通知の対象とする項目を選択し、適正に利用不可通知の情報量を短くすることにより、ユーザが把握しやすい情報量の利用不可通知を提示することが可能となる。

なお、上述の例では利用状況に関する情報を図２２のように各項目と関連付けて記憶させるように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば図１と同一部分には同符号を付した図２３のように各項目について利用状況を管理するデータベースである利用状況管理部２３０５を別途追加する構成も考えられる。

このような場合は各項目に関連付けられている利用状況の情報は不要となり、利用不可通知出力判定部１０２は利用状況管理部２３０５を参照して利用不可通知の出力対象となる項目を選択する。

また、利用状況管理部２３０５は対話装置１００内だけでなく、対話装置１００外に配置することも可能である。このような場合は利用状況管理部２３０５にはネットワークを介してアクセスする。

また、上述の例では利用状況の程度に関するしきい値を設定する方法について記載しているが、利用状況に基づいて優先順位を与え、その優先順位に従って一定個数内に収まるようにしきい値処理をすることや、利用不可通知の長さが一定長内に収まるようにしきい値処理をすることも可能である。

以上のように、対話装置１００の運用中に集計される項目の利用状況を加味して利用不可通知の対象とする項目を選択し、適正に利用不可通知の情報量を削減するものであれば、そのような構成は本発明の主旨の範囲内である。

（第５の実施の形態）
第１及び第２の実施の形態では、利用不可となった項目あれば利用不可通知を出力するものであったが、利用不可通知が必ずしも必要ではない状況もある。そのような場合に利用不可通知を出力すると対話が長くなり、ユーザにも不利益を与える。本実施の形態では利用不可項目だけしか見つからなかった場合だけ利用不可通知を出力することで、より適正に利用不可通知を出力する対話装置を提供する。

本実施の形態の対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２または図１７である。本実施の形態が第１、第２の実施の形態と異なる部分は利用不可通知出力判定部１０２（１４０２）の詳細動作であり、フローチャートではステップＳ２０５、ステップＳ１７０５に相当する。以下、利用不可通知出力判定部１０２（１４０２）の動作について説明する。尚、以下では表記を簡単にするために第１の実施の形態の表記のみを使用する。

対話進行部１０１からステップＳ２０４において利用不可通知のために収集した項目の集合を取得し、利用不可通知出力判定部１０２に通知する。この項目（話題・呼称データ）の収集結果は利用可能な項目で構成される正規項目グループと利用不可な項目で構成される利用不可項目グループの２つのグループで出力される。

本実施の形態における利用不可通知出力判定部１０２は、正規項目グループが空であれば利用不可通知を出力し、正規項目グループが空でなければ利用不可通知を出力しないと判定する。これは利用可能な項目があれば、その項目を利用して対話を継続することが可能であることと、ユーザがその利用可能な項目を利用することを意図していたのであれば、利用不可通知は冗長なものになることに基づく。尚、利用不可通知を出力すると判定した場合の、利用不可通知の対象とする項目の選択方法は任意である。

次に、具体例としてレストラン検索サービスを利用した対話システムに本発明を適用した場合を例に、本実施の形態の動作について図２、図５、図１０、図２４を参照してより詳細に説明する。この対話システムは第１の実施の形態の説明に利用したものと同様であり、話題の詳細は図５、この対話例における対話システムの状況は図１０となっている。

［対話例６］
図２４に示す対話例を説明する。

まず、ＵＳＲ２４−１で対話が始まる。対話進行部１０１はこの入力に対して利用不可通知のための項目（話題）収集を行うと決定する（ステップＳ２０３のＹｅｓ）。（Ａ）パタンの収集方針に基づき「レストラン」という入力が該当する話題を収集すると、収集結果は正規項目グループ＝｛「レストラン検索」｝、利用不可項目グループ＝｛「ローカルレストラン検索」｝となる（ステップＳ２０４）。

利用不可通知出力判定部１０２は、この収集結果を受け、正規項目グループが空ではないので利用不可通知を出力しないと判断し（ステップＳ２０５）、そのままユーザとの対話を継続する（ステップＳ２０６のＮｏ，ステップＳ２０１）。そして利用可能な項目についてユーザに対して提示（ＳＹＳ２４−１）し、更に「レストラン検索」を解決するためにユーザに入力を促す（ＳＹＳ２４−２）。

ここでユーザが「レストラン検索」の対話進行よりも「ローカルレストラン検索」の実行を希望したとして、「ローカルレストラン検索」を明示的に指定するＵＳＲ２４−２を入力したとする。対話進行部１０１はこの入力に対して利用不可通知のための項目収集を行うと決定する（ステップＳ２０３のＹｅｓ）。（Ａ）パタンの収集方針に基づき「ローカルレストラン検索」という入力が該当する話題を収集すると、収集結果は正規項目グループ＝｛｝、利用不可項目グループ＝｛「ローカルレストラン検索」｝となる（ステップＳ２０４）。

利用不可通知出力判定部１０２は、この収集結果を受け、正規項目グループが空なので利用不可通知を出力すると判断し、利用不可項目グループに含まれている項目に関する利用不可通知を出力すると判定する（ステップＳ２０５）。そして対話進行部１０１は利用不可通知出力ＳＹＳ２４−３を出力する（ステップＳ２０６Ｙｅｓ，ステップＳ２０７）。

このように、利用不可通知出力判定部１０２が、利用可能な項目が存在しない場合のみ利用不可通知を出力する。これにより不要な利用不可通知を出力しないようになる。

例えば、ＳＹＳ２４−２を出力した段階で、ユーザが「レストラン検索」での機能実行を許容するならば、ＵＳＲ２４−２の入力はなされずに、ユーザはシステムが要求するジャンルを指定する。この場合は利用不可通知が不要となる。本実施の形態は利用可能な項目が存在する場合に、ユーザがその項目の利用を許容する場合を考慮した動作となっている。

以上のように本実施の形態では、利用可能な項目が存在しない場合のみ利用不可通知を出力することにより、不要な利用不可通知の出力を抑制することが可能となる。

なお、上述の説明では利用不可通知の出力の際に利用可能項目を収集して、その収集結果に基づいて判定しているが、本実施の形態はそのような構成に限定されない。例えば、収集条件に合致する項目が存在するか否かを、項目を管理するデータベース（話題管理部１０３等）ではなくアプリや値のデータベースに別途問い合せることも可能である。

以上のように、利用可能な項目が存在しない場合のみ利用不可通知を出力するものであれば、そのような構成は全て本実施の形態の主旨の範囲内である。

（第６の実施の形態）
第1及び第２の実施の形態では、利用不可となった項目を消去せずに記憶し、常時利用不可通知の対象としている。しかし、利用不可通知を出力してユーザが利用不可となったことを把握すると、以後その項目に関する利用不可通知は不要となる。同じ項目について何度も利用不可通知を出力することは冗長で対話が長くなり、ユーザに不利益を与える。本実施の形態では利用不可項目を適宜削除する対話装置を提供する。

本実施の形態の対話装置１００の構成図は図１または図１４である。本実施の形態が第1、第２の実施の形態と異なる部分は対話進行部１０１（１４０１）、話題更新部１０４（呼称更新部１４０４）の詳細動作が追加されたことであり、これにより動作のフローチャートには新たなステップが追加される。しかしながら本実施の形態で追加された動作は管理する項目の種類によって変更されるものではなく、共通の動作である。従って以下では表記を簡単にするために第１の実施の形態からの変更のみで説明するが、この変更は第２の実施の形態についても有効である。

本実施の形態における話題更新部１０４は、第１の実施の形態における話題更新部１０４と同様の動作をする。第1の実施の形態からの変更点は、話題を話題管理部１０３から削除する機能を持つことである。削除する話題の指定は対話管理部１０１から通知される。

本実施の形態における対話進行部１０１は、第1の実施の形態における対話進行部１０１と同様の動作する。第1の実施の形態からの変更点は、削除する話題を特定し、話題更新部１０４に削除を指示することである。削除する話題の特定方法は後述する。

本実施の形態の動作を図２９を用いて説明する。なお、図２９は第６の実施の形態における動作のフローチャートである。第６の実施の形態の動作は基本的には第１の実施の形態の動作と同様であり、同じ動作をするステップは図２と同じ付箋を付与している。本実施の形態によって変更された部分はステップＳ２９０８が追加されたことである。

ステップＳ２９０８は、話題管理部１０３から不要な話題を削除するステップである。対話進行部１０１が不要な話題を特定し、話題更新部１０４に削除を依頼する。話題更新部１０４は対話進行部１０１から通知される不要な話題を話題管理部１０３から削除する。

以上が第６の実施の形態の動作である。

ここで、対話進行部１０１の不要な話題を特定する動作の詳細について説明する。第６の実施の形態では、対話進行部１０１はステップＳ２０７で出力した利用不可通知に関する話題を削除すると判定する。利用不可通知を出力していない話題に関しては削除しない。ユーザは利用不可通知の情報を受け取ると、その通知に関する話題は以後利用できないことを認識する。従って、出力した利用不可通知に関する話題の必要性は低いものとなり、不要な話題として削除しても問題は少ないと言える。

例えば、図７の対話例ではステップＳ２０７で利用不可通知ＳＹＳ７−１を出力すると、ステップＳ２９０８では利用不可通知の対象となった話題「ローカルレストラン検索」を話題管理部１０３から削除し、そのままユーザとの対話を継続する（ステップＳ２０１）。或いは、利用不可通知ＳＹＳ７−５を出力すると、ステップＳ２９０８では話題「施設予約」を話題管理部１０３から削除する。

このように、本実施の形態ではユーザに対して利用不可通知を出力した話題を話題管理部１０３から削除するので、ユーザが利用不可と認識した利用可能性の低い話題のみを削除すると共に、同じ話題に関する利用不可通知を何度も出力することを抑制することが可能となる。

上述のように本実施の形態は利用不可通知のために管理する項目の単位が話題ではなく、第２の実施の形態のような呼称データであっても動作する。例えば、図２０の対話例では利用不可通知ＳＹＳ２０−１を出力した後に、“restaurant-B”に関する呼称データを呼称管理部１４０３から削除することが可能である。結果として値“restaurant-B”に関する利用不可通知を何度も出力することを抑制することが可能である。

また、第１及び第２の実施の形態において音声入力を受理する場合には、音声認識エンジンにより音声認識をする必要があるが、利用不可項目の蓄積を続けていると蓄積された項目に関する音声認識文法も蓄積され、結果的に蓄積された音声認識文法を統合して作成される音声認識エンジンに設定する音声認識文法の規模が大きくなってしまう。音声認識文法の規模が大きくなると誤認識が生じやすくなり、誤動作を起こしやすくなるという問題がある。

しかし、本実施の形態においては、ステップＳ２９０８で項目を削除すると、削除された項目と関連付けて記憶された音声認識文法(例えば図２５や図２８)も削除することができる。従って、本実施の形態では、利用可能性の低い項目を削除することにより、利用可能性の低い音声認識文法を削除し、音声認識エンジンに設定する全体音声認識文法の規模の肥大化を抑制するように振舞うことが可能である。

以上のように、本実施の形態ではユーザに対して利用不可通知を出力した項目を削除するので、同じ項目に関する利用不可通知の出力を抑制すると共に、音声認識を利用する場合には削除された項目と関係する音声認識文法を削除し、全体の音声認識文法の肥大化を抑制することが可能となる。

なお、上述の例では項目を削除するステップＳ２９０８を利用不可通知の出力（ステップＳ２０７）の直後としているが、本実施の形態はそのような構成に限定されない。例えば利用不可通知を出力した後で、所定回数のユーザ入力が行われた時点で当該項目を削除すると判定したり、所定時間が経過した時点で当該項目を削除したりすると判定することも可能である。

また、音声認識文法や入力解釈ルールといった項目と関連付けられている情報を項目と独立に管理している場合は、項目削除と連動して関連する情報を削除することも考えられる。対話手順や入力解釈ルールや音声認識文法が対話システムで利用する全話題を網羅的に表現し、部分的な削除が困難であった場合は当該項目への遷移を抑制するように生起確率を減らすといった作業が可能であり、このような処理も削除とみなせる。

以上のように、ユーザに対して利用不可通知を出力した項目を削除し、音声認識を利用する場合には削除された項目と連動して音声認識文法を削除するものであれば、そのような構成は本実施の形態の主旨の範囲内である。

（第７の実施の形態）
第６の実施の形態は単純に利用不可通知を出力した項目を削除するものであった。本実施の形態は各項目の利用状況に基づいて、より適切に項目を削除し、不要な利用不可通知の出力を抑制したり、不要な音声認識文法を削除したりする対話装置を提供するものである。

本実施の形態の対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２９である。本実施の形態が第６の実施の形態と異なる部分は対話進行部１０１（１４０１）における削除する項目を決定する詳細動作であり、フローチャートではステップＳ２９０８に相当する。また、話題や呼称データといった項目の詳細内容も第６の実施の形態とは異なる。

以下、それぞれについて説明する。尚、以下では表記を簡単にするために第６の実施の形態の説明に使用した第1の実施の形態の表記のみを使用する。

本実施の形態における対話進行部１０１は、話題管理部１０３に記憶されている利用不可話題（項目）から削除する項目を選択する。選択する際に各項目の利用状況に基づいて選択する。選択結果を話題更新部１０４に通知し、話題管理部１０３から削除するように依頼する。項目の利用状況、対話進行部１０１の削除する項目の選択方法については後述する。

利用状況の例として第4の実施の形態と同様に、（１）各項目の利用頻度、（２）各項目の最終利用時刻、（３）利用不可通知の回数、（４）利用不可項目として収集された回数、が考えられる。これらの利用状況はユーザとの対話中に対話進行部１０１が検出することができる項目である。また、これらの利用状況は一回の対話毎にリセットするものではなく、対話装置１００の運用中の一つ以上の対話を通して集計される。以下それぞれの利用状況の詳細とそれを使用した対話進行部１０１の削除する項目を決定する詳細動作について説明する。

ユーザは利用頻度が多い項目をより強く記憶していると考えられ、利用頻度が多い項目が利用不可となっても、ユーザはこの項目を利用する可能性がある。逆に利用頻度が少ない項目はユーザから積極的に利用する可能性は少ない。従って対話進行部１０１はこの利用頻度が少ない項目を削除対象として選択する。例えば利用頻度のしきい値処理によってしきい値より小さい利用頻度を持つ項目を削除対象として選択する。特に利用頻度が０の項目はユーザその存在をしらないものと言えるので、利用不可通知の出力も不要となり削除すべき項目である。

ユーザはより最近に参照した項目を強く記憶していると考えられ、現在の時刻と最終利用時刻が近い値となっている(新しい)項目が利用不可となっても、ユーザはこの項目を利用する可能性がある。逆に古い項目はユーザの関心が離れているとみなせるので、ユーザから積極的に利用する可能性は少ない。従って対話進行部１０１はこの最終利用時刻が古い項目を削除対象として選択する。例えば、最終利用時刻のしきい値処理によってしきい値より古い最終利用時刻を持つ項目を削除対象として選択する。

ユーザはより多くの利用不可通知を受けた項目については、利用不可となったことを強く記憶していると考えられる。従って対話進行部１０１はこの利用不可通知の回数が多い項目を削除対象として選択する。例えば、利用不可通知の回数のしきい値処理によってしきい値より多い利用不可通知の回数を持つ項目を削除対象として選択する。

利用不可項目として収集された回数が多い項目は、ユーザとの対話中に利用されうる可能性が多数あったものであり、その項目に対して利用不可通知を出していれば、ユーザはその項目が利用できないことを認識しており、その項目に対して利用不可通知を出していなければ、ユーザはその項目を利用せずに対話が進行していることになり、この項目に対してユーザ関心が少ないものと考えられる。いずれの場合にも利用不可項目として収集された回数が多ければ、今後ユーザがその項目を利用する可能性は少ないものとなる。従って、利用不可通知出力判定部１０２は、この利用不可項目として収集された回数が多い項目を削除対象として選択する。例えば、利用不可通知の回数のしきい値処理によってしきい値より多い利用不可通知回数を持つ項目を削除対象として選択する。

本実施の形態における対話進行部１０１は、以上に示した利用状況のうち一つ以上の条件を収集し、削除する項目の選択に使用する。複数の利用状況による判定を組み合わせる場合は、使用する利用状況に優先順位を与える。例えば、（３）利用不可通知の回数よりも（１）利用頻度の方が、ユーザの関心がより強く現れる条件であるとして、利用頻度の条件を優先的に採用することなどが考えられる。

本実施の形態においても、第６の実施の形態のように項目の削除と連動した音声認識文法の削除を行うことが可能である。本実施の形態においては削除を判定する対象が利用不可項目全てであり、利用不可通知を出力していない項目も削除の対象となりうるので、全体音声認識文法の規模の肥大化をより効果的に抑制することが可能となる。

以上のように本実施の形態では、対話装置１００の運用中に集計される項目の利用状況を加味して利用不可項目から削除する項目を選択し、選択結果に応じて適正に項目を削除することにより不要な利用不可通知の出力を抑制したり、音声認識文法の肥大化を抑制したりすることが可能となる。

なお、上述の例では項目を削除する手続き（ステップＳ２９０８）を利用不可通知の出力（ステップＳ２０７）の後に配置しているが、これは（３）利用不可出力の回数や、（４）利用不可項目として収集された回数といった利用状況の更新を重視した構成に過ぎない。（１）利用頻度や（２）最終利用時刻といった利用状況の更新を重視する構成であれば利用不可通知の出力とは無関係に、アプリや値が削除されて利用不可項目が増加した時、ユーザ入力時、利用頻度を更新した時、一定時間毎、対話の開始時、等任意のタイミングで項目の削除が実行可能である。或いはこれらのタイミングを組み合わせて項目の削除を行っても良い。

なお、上述の例では対話進行部１０１が項目の削除を確認する対象を全利用不可項目としているが、利用不可通知のための項目収集結果に含まれる利用不可項目に限定しても良い。このようにすると項目の削除の判定にかかる実行時間の短縮につながる。

なお、上述の例では利用状況に関する情報を図２２のように各項目と関連付けて記憶させるように記述しているが、本実施の形態はそのような構成に限定されるものではない。例えば図２３のように各項目について利用状況を管理するデータベースである利用状況管理部２３０５を別途追加する構成も考えられる。このような場合は各項目に関連付けられている利用状況の情報は不要となり、利用不可通知出力判定部１０２は利用状況管理部２３０５を参照して利用不可通知の出力対象となる項目を選択する。

また、上記のように利用状況を項目と独立に管理している場合は、項目削除と連動して利用状況を削除することも考えられる。削除しない場合は残した利用頻度を利用して類似した項目の利用不可通知の出力判定に利用するなどの利用法が考えられる。

以上のように本実施の形態では、対話装置１００の運用中に集計される項目の利用状況を加味して利用不可項目から削除する項目を選択し、選択結果に応じて項目を削除するものであれば、そのような構成は本発明の主旨の範囲内である。

（第８の実施の形態）
第６及び第7の実施の形態は不要な項目を削除することにより、音声認識文法の肥大化を抑制する効果を持つ。但し、音声入力を考慮すると一つの項目に対して複数の表現が割り当てられる場合もあり、表現レベルでの音声認識文法の削除ができれば、適応的な音声認識文法の編集が可能となる。本実施の形態では利用不可となった項目を完全に削除するのではなく、利用不可となった項目に関する音声認識文法の一部を削除する対話装置を提供するものである。

本実施の形態の対話装置１００の構成図は図１または図１４である。本実施の形態が第６、第７の実施の形態と異なる部分は対話進行部１０１（１４０１）、話題更新部１０４（呼称更新部１４０４）の詳細動作が異なることであり、これにより動作のフローチャートに修正が加えられる。尚、以下では表記を簡単にするために第６、第７の実施の形態の説明に使用した第１の実施の形態の表記のみを使用する。

本実施の形態の対話進行部１０１の動作は基本的には第１の実施の形態の対話進行部１０１と同様であるが、本実施の形態では話題に関連付けられた音声認識文法から削除する入力パタン（図２６の２６０４等）を選択する。対話進行部１０１は選択結果を話題更新部１０４に通知し、入力パタンの削除を依頼する。削除する項目や入力パタンの選択方法については後述する。

本実施の形態の話題更新部１０４の動作は基本的には第１の実施の形態の話題更新部１０４と同様であるが、本実施の形態では話題に関連付けられた音声認識文法を入力パタン単位で編集（削除）することが可能となっている。入力パタンは各項目を表現する音声認識文法の部分文法に相当する。削除する入力パタンは対話進行部１０１から通知される。

本実施の形態の動作を図３０を用いて説明する。なお、図３０は第８の実施の形態における動作のフローチャートである。第８の実施の形態の動作は基本的には第１の実施の形態の動作と同様であり、同じ動作をするステップは図２と同じ付箋を付与している。本実施の形態によって変更された部分はステップＳ３００８が追加されたことである。

ステップＳ３００８は、話題管理部１０３から不要な入力パタンを削除するステップである。対話進行部１０１が入力パタンを削除する話題と、削除する入力パタンを選択し、話題更新部１０４に削除を依頼する。話題更新部１０４は対話進行部１０１から通知される不要な入力パタンを話題管理部１０３から削除する。以上が第８の実施の形態の動作である。

ここで、対話進行部１０１の入力パタンを削除する話題と、削除する入力パタンを選択する動作の詳細について説明する。入力パタンを削除する話題の特定方法は、第６、第７の実施の形態で提示した項目(話題)を削除する条件を利用する。但し、入力パタンを削除すると決定するしきい値は話題を削除するしきい値とは別のものであり、入力パタンを削除すると決定するしきい値は、話題を削除するしきい値より緩いものを採用する。例えば、第７の実施の形態で説明した利用頻度の条件であれば、項目削除のために設定したしきい値より多い利用頻度を持つ話題も入力パタンを削除する項目として選択する。これは削除され得る項目はユーザがその項目を発話する可能性も低くなるため、保持すべき入力パタンの数を削減しても良いという判断に基づく。

入力パタンを削除する話題を選択すると、続いてその話題に関する音声認識文法から削除する入力パタンを選択する。選択方法として「代表的な表現を残す」という手法が考えられる。代表的な表現として話題の名称が挙げられる。図２６を例にすると、話題「施設予約」の文法（２６０１）では２６０４が話題の名称である。或いは入力パタンの設計者により代表的な入力パタンを予め指定しておいても良い。対話進行部１０１は代表的な入力パタンではない入力パタンを削除する入力パタンとして選択する。

また、削除する入力パタンを選択する方法として、「利用頻度の高い入力パタンを残す」という手法が考えられる。この判定基準を利用するために、対話装置１００の運用中に各入力パタンについてユーザ入力と適合した頻度を記憶しておく。図２６の例では、記憶された利用頻度を元に「△△を予約」というユーザ入力が多ければ、対話進行部１０１は入力パタン２６０５を残すように、話題の文法２６０１から削除する入力パタンを選択する。

また、削除する入力パタンを選択する方法として、「最終利用時刻が新しい入力パタンを残す」という手法が考えられる。入力パタンに対する最終利用時刻は、各入力パタンがユーザ入力と適合した最後の時刻となる。この判定基準を利用するために、対話装置１００の運用中に入力パタン毎に最終利用時刻を記憶しておく。図２６の例では、記憶された利用頻度を元に「△△を予約」というユーザ入力の最終利用時刻が新しければ、対話進行部１０１は入力パタン２６０５を残すように、話題の文法２６０１から削除する入力パタンを選択する。

尚、上述の例では入力パタンを削除する項目として話題を例にして説明しているが、同様な方法で呼称データの入力パタンを削除することも可能である。例えば、呼称データに付与される音声認識文法２６０３には入力パタンが２個登録されているが、ユーザが「〇屋」の表現を多用する場合は、利用頻度の高い入力パタンを残す条件に基づいて「〇屋××店」の入力パタン２６０８を削除することもできる。

以上のように本実施の形態では、利用不可となった項目を完全に削除するのではなく、利用不可となった項目に関する音声認識文法の一部を削除することにより、項目数の減少を抑えつつ音声認識文法の肥大化を抑制することが可能となる。

なお、上述の例では図２５、図２８のように項目と音声認識文法を関連付けて記憶するように記述しているが、本実施の形態はそのような構成に限定されない。音声認識文法や入力解釈ルールといった項目と関連付けられている情報を項目と独立に管理している場合は、削除する入力パタンを決定した際に関連する音声認識文法を削除する。対話手順や入力解釈ルールや音声認識文法が対話システムで利用する全話題を網羅的に表現し、部分的な削除が困難であった場合は当該項目への遷移を抑制するように生起確率を減らすといった作業が可能であり、このような処理も削除とみなせる。

また、ある項目に対する入力パタンの削除は、一回だけ実行しても段階的に複数回実行しても良い。段階的に実行する場合は、入力パタン削除を決定するしきい値を複数種類設定しておき、ある項目について入力パタンを削除すると決定した場合には、複数種類設定したしきい値の中のどれに該当するかに基づいて、削除する入力パタンを決定する。

なお、上述の例では入力パタンを削除するステップＳ３００８を利用不可通知の出力（ステップＳ２０７）の直後としているが、本実施の形態はそのような構成に限定されない。

例えば、第６の実施の形態に示した条件を入力パタンの削除に適用する場合は、利用不可通知を出力した後で、所定回数のユーザ入力が行われた時点で当該項目の入力パタンを削除すると判定したり、所定時間が経過した時点で当該項目の入力パタンを削除したりすると判定することも可能である。

例えば、第７の実施の形態に示した条件を入力パタンの削除に適用する場合は、（１）利用頻度や（２）最終利用時刻といった利用状況の更新を重視する構成であれば利用不可通知の出力とは無関係に、アプリや値が削除されて利用不可項目が増加した時、ユーザ入力時、利用頻度を更新した時、一定時間毎、対話の開始時、等任意のタイミングで項目の入力パタンを削除できる。或いはこれらのタイミングを組み合わせて項目の入力パタンの削除を行っても良い。

以上のように、利用不可となった項目に関する音声認識文法の一部を削除するようなものであれば、そのような構成は本発明の主旨の範囲内である。

（第９の実施の形態）
これまでの実施の形態はユーザが一人だけの場合を考慮したものであった。しかしながら、複数のユーザが共通の対話装置１００を利用した場合には適切な利用不可通知を出力できないという問題がある。例えば、利用不可通知はユーザが実行した対話に基づき出力するものなので、対話を実行したユーザが異なれば利用不可通知は異なる内容となる。また、第４及び第７の実施の形態のようにユーザによる各項目の利用状況に基づき動作を判定するものもあり、別ユーザの利用状況に基づく判定では正しく動作しないこともある。本実施の形態はユーザ別の使用履歴を利用して利用不可通知の出力や利用不可項目の削除等を実行する対話装置を提供する。利用不可通知の出力や利用不可項目の削除等の判定は、全て項目を管理するデータベース（話題管理部１０３や呼称データ管理部１４０３）を参照して行う。このデータベースにおける利用不可項目を参照し、また各項目に関連付けられた利用状況に基づいて利用不可通知を出力する判定や、項目を削除する判定を行う。従って、ユーザ別の使用履歴に基づきこの項目を管理するデータベースを構成すれば、利用不可通知の出力や項目の削除等の処理は、そのユーザの使用履歴に沿った適切なものを実行することができる。本実施の形態ではユーザの使用履歴から項目を管理するデータベースを構成する使用履歴構成処理を実行する対話装置を提供するものである。

以後、第１の実施の形態に使用履歴構成処理を追加した構成を例にして説明するが、その他の実施の形態についても同様に動作することが可能である。

本実施の形態の対話装置１００の構成図を図３１に示す。本実施の形態は図１に示す第１の実施の形態と基本的な同じ構成・動作である。本実施の形態が異なる点は使用履歴構成部３１０５が追加されたことであり、これによりユーザとの対話の前後の処理が追加されている。

即ち、（i）ユーザとの対話前（ログイン時等）にそのユーザに関する使用履歴構成処理により話題管理部１０３を構成し、(ii)構成された話題管理部１０３に基づきユーザと対話し、(iii)対話が終了した後（ログアウト時等）に話題管理部１０３からユーザの使用履歴を構成し、ユーザ情報に記憶する処理を実行する。(ii)のユーザとの対話する処理は上述の実施の形態で説明した対話処理を実行する。本実施の形態の使用履歴構成部は(i)、(iii)の処理を実行するものである。以下、使用履歴構成部３１０５について説明する。

使用履歴構成部３１０５は、対話を実行するユーザに関する使用履歴構成処理を実行する。その結果構成された使用履歴情報を話題管理部１０３に設定する。使用履歴構成処理はユーザ情報から使用履歴情報を取得し、使用履歴情報と現在の対話装置１００の状況（話題の利用可・不可の状況）との差分に基づき使用履歴情報を更新する処理である。使用履歴情報、使用履歴構成処理については後に詳述する。また、ユーザから使用履歴情報を取得する方法は、ユーザが持つメディアから取得する方法や、ユーザＩＤに基づき所定の記憶領域やサーバから取得する方法など、様々な方法が適用可能である。

使用履歴構成部３１０５は、ユーザとの対話終了時に話題管理部１０３から話題登録状況を取得し、それを使用履歴情報としてユーザ情報に登録する。登録する先はユーザが持つメディアに登録する方法や、ユーザＩＤに基づき所定の記憶領域やサーバに登録する方法など、様々な方法が適用可能である。

ここで使用履歴情報について説明する。使用履歴情報は話題管理部１０３と同様に正規話題群と利用不可話題群からなる情報であり、これらの話題群はユーザと対話装置１００が最後に対話した時の状況が記憶されるため、そのユーザの使用履歴を表現する情報である。特に第４の実施の形態のように利用状況を話題と関連付けて記憶する場合は、各ユーザの対話進行による話題の使用履歴を詳細に記憶する情報となる。

ここで使用履歴構成処理について説明する。使用履歴構成処理は、あるユーザの使用履歴情報に登録されている正規話題群の中から、現時点(使用履歴構成処理をする時)で利用不可となっている話題を抽出し、その抽出結果をまとめて利用不可話題群に移動する処理である。正規話題群は現時点で利用可能な話題で構成する。ある話題が現在利用可能かどうかの確認は話題更新部１０４を経て、該当するアプリが利用可能かどうかを探索するなどして判定する。この処理は、ユーザが対話を終えてから対話を再開するまでに生じたアプリ群の構成をまとめて話題管理部１０３に反映させる処理と言える。

以上のように本実施の形態ではユーザ個人の使用履歴に基づいて話題管理部１０３を構成するので、対話中にはユーザ個人の使用履歴に基づいた利用不可通知を出力するなどが可能となる。

上述のように、本実施の形態は使用履歴情報の管理単位を話題に限定したものではない。図３１の対話装置１００の構成は第１の実施の形態の構成に使用履歴構成部３１０５を追加しただけであり、使用履歴情報も話題を正規と利用不可に分類しているだけの情報である。従って、第２の実施の形態の構成に使用履歴構成部３１０５を追加し、呼称データに関して正規と利用不可に分類する使用履歴情報を構成するようにすれば、上述の説明と同様の動作が可能となる。

以上のように本実施の形態ではユーザ個人の使用履歴に基づいて項目を管理するデータベースを構成するので、対話中にはユーザ個人の使用履歴に基づいて利用不可通知を出力するなどの処理が可能となる。

なお、上述の説明ではユーザから使用履歴情報を全て取得するように記述しているが、本実施の形態はそのような構成に限定されない。例えば、そのユーザと対話した最後の時刻を記憶しておき、対話装置１００側で利用可能な項目の変遷を記憶しておく。使用履歴構成処理時には、ユーザ情報から最後の時刻に基づきその当時利用可能な項目を取得し、取得結果と現在利用可能な項目を比較すれば利用不可となった項目を取得することが可能である。この場合はユーザが当時利用不可であった項目のリストを記憶しておけば使用履歴情報を構成できる。或いは、対話装置１００側で利用可・不可な項目の変遷を記憶しておけば、時刻情報のみで使用履歴情報の構成が可能となる。

また、本実施の形態では全ての利用可能な項目を記憶しておく必要もない。例えば、利用可能な項目としてユーザが利用したことのある項目のみを記憶しても良い。このような場合は、使用履歴構成処理によって利用したことのある話題が利用不可となったことを使用履歴情報に登録でき、第７の実施の形態における利用頻度を用いた項目削除処理と同等の効果が得られる。

以上のようにユーザ個人の使用履歴に基づいて項目を管理するデータベースを構成し、それを利用不可通知の出力判定等に利用するものであれば、そのような構成は本発明の主旨の範囲内である。

（第１０の実施の形態）
第1及び第２の実施の形態では、利用不可となった項目全てについて利用不可通知を出力するものであったが、あるグループとしてまとめられる項目が全て利用不可となった時に個別の項目について利用不可となったことを通知するよりも、そのグループ全てが利用不可となったことを通知した方がユーザにとってわかり易い。本実施の形態はグループ単位での利用不可通知を出力する対話装置を提供する。

本実施の形態の対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２または図１７である。本実施の形態が第１、第２の実施の形態と異なる部分は利用不可通知出力判定部１０２（１４０２）の詳細動作であり、フローチャートではステップＳ２０５、ステップＳ１７０５に相当する。また、項目に関連付ける情報が追加される。以下、利用不可通知出力判定部１０２（１４０２）の動作について説明する。尚、以下では表記を簡単にするために第１の実施の形態の表記のみを使用する。

本実施の形態で管理する項目の詳細例を図３２に示す。本実施の形態では各項目に「カテゴリ情報」を付与する（３２０１、３２０２）。カテゴリ情報は各項目が所属するカテゴリを表すデータであり、例えば話題「レストラン検索」は施設を検索する話題のカテゴリに含まれるとして「施設検索」カテゴリ、値「和食□屋」は和食料理店のカテゴリに含まれる値として「和食料理店」カテゴリに所属する。

本実施の形態における利用不可通知出力判定部１０２は、あるカテゴリに所属する項目が全て利用不可となった時に、カテゴリ単位で利用不可通知を出力する。例えば、「和食料理店」カテゴリに所属する値が全て利用不可となった時に、「和食料理店はご利用になれません」といった利用不可通知を出力する。この利用不可通知により、ユーザは個別の項目が利用不可なのではなく、そのカテゴリに所属しうる全ての項目が利用不可になったことを認識できる。

ここで、本実施の形態における利用不可通知出力判定部１０２の詳細な動作であるステップＳ２０５について説明する。対話進行部１０１からはステップＳ２０４における項目の収集結果として正規項目グループと利用不可項目グループからなる情報が通知されている。

利用不可通知出力判定部１０２は、利用不可項目グループにある各項目が所属するカテゴリに利用可能な項目が存在するか否かを判定する。即ち、正規項目グループを対象としてそのカテゴリに所属する項目を探索する。或いは正規話題管理部６０２を対象としても良い。探索結果として項目が得られれば利用可能な項目が存在すると判定する。

利用不可通知出力判定部１０２は、利用可能な項目が存在するならばカテゴリ単位の利用不可通知を出力しないと判定し、各項目に関する利用不可通知を出力する。利用可能な項目が存在しないならばカテゴリ単位の利用不可通知を出力する。この場合は同じカテゴリに所属する利用不可項目に関する利用不可通知の出力を省略することができる。

例えば、ステップＳ２０４の収集結果として、カテゴリ「施設検索」に所属する話題「レストラン検索」と「ローカルレストラン検索」が利用不可話題グループにあり、施設検索に所属する利用可能な話題が無かった場合には、利用不可通知出力判定部１０２は「施設検索はご利用になれません」というカテゴリ単位の利用不可通知を出力すると判定する。

また、例えば、ステップＳ２０４の収集結果として、カテゴリ「和食料理屋」に所属する呼称データ「和食□屋」と「和食〇屋」が利用不可呼称データグループにあり、和食料理屋に所属する利用可能な呼称データが無かった場合には、利用不可通知出力判定部１０２は「和食料理屋はご利用になれません」というカテゴリ単位の利用不可通知を出力すると判定する。

カテゴリ単位の利用不可通知の出力により、ユーザにはそのカテゴリに所属する全ての項目が利用不可となったことを通知できる。項目単位の利用不可通知であれば「Ａは駄目でも類似したＢは大丈夫」という考え方も可能であり、全て利用不可となった場合はカテゴリ単位の利用不可通知の方がユーザにとって状況がわかり易い。

以上のように、本実施の形態では管理対象の項目をカテゴリで分類し、利用不可通知を出力する対象の項目と同じカテゴリの項目に利用可能な項目が無かった場合は、カテゴリ単位の利用不可通知を出力することで、ユーザに対してよりわかり易い利用不可通知を出力することが可能となる。

なお、上述の実施の形態では、カテゴリ情報を各項目に関連付けて記憶するように記載しているが、本発明はそのような構成に限定されない。項目からカテゴリ情報を取得することが可能なデータベースを、項目を管理するデータベースとは別に準備しても良い。或いは話題の場合は出力データ型、呼称データの場合はその値のデータ型に基づいてカテゴリを分類し、カテゴリ情報を省略することも可能である。

また、上述の利用不可通知出力判定部１０２は、カテゴリの一致に基づいてカテゴリ単位の利用不可通知の出力判定をしているが、カテゴリの包含関係（「料理店」は「和食料理店」を包含する）を定義しておき、その包含関係に基づいて最も大きなカテゴリでの利用不可通知を出力しても良い。

なお、カテゴリ単位の利用不可通知を出力した時に、そのカテゴリに該当する項目単位の利用不可通知を省略することが可能である。

以上のように、管理対象の項目をカテゴリで分類し、利用不可通知を出力する対象の項目と同じカテゴリの項目に利用可能な項目が無かった場合は、カテゴリ単位の利用不可通知を出力するものであれば、そのような構成は本発明の主旨の範囲内である。

（第１１の実施の形態）
第１及び第２の実施の形態では、利用不可となった項目について利用不可通知を出力するものであったが、利用不可通知は利用できなくなったことを通知するだけであり、代替となる情報を提供できない。そのため、ユーザは入力する内容に困ることもありうる。本実施の形態では利用不可となった項目に対してユーザに代替案を提示する対話装置を提供する。

本実施の形態の対話装置１００の構成図は図１または図１４であり、動作のフローチャートは図２または図１７である。本実施の形態が第１、第２の実施の形態と異なる部分は対話進行部１０１（１４０１）の詳細動作であり、フローチャートではステップＳ２０７、ステップＳ１７０７に相当する。また、項目に関連付ける情報が追加される。以下、対話進行部１０１（１４０１）の動作について説明する。尚、以下では表記を簡単にするために第１の実施の形態の表記のみを使用する。

本実施の形態で管理する項目の詳細例を図３３に示す。本実施の形態では各項目に「代替情報」を付与する（３３０１、３３０２）。代替情報はある項目に関する利用不可通知をした時にユーザに提示する代替として利用可能な項目の情報である。例えば話題「ローカルレストラン検索」が利用不可であることをユーザに伝える場合の代替情報として「レストラン検索に統合されました」（３３０１）を準備する。或いは、値「和食□屋」が利用不可であることをユーザに伝える場合の代替情報として「和食□屋はリニューアル！ “Japanese Dining - Square”に生まれ変わりました。」（３３０２）を準備する。これらの代替案は話題更新部１０４に外部から通知され、話題更新部１０４がその項目の代替情報を更新する。

本実施の形態における対話進行部１０１はステップＳ２０７の利用不可通知を出力する際に、出力対象の項目に代替情報が登録されているかどうかを確認する。代替情報が登録されていれば、対話進行部１０１はその代替情報を取り出し、利用不可通知と併せて出力する。例えば、「ローカルレストラン検索はご利用になれません（利用不可通知）。レストラン検索に統合されました（代替情報）。」や、「和食□屋はご利用になれません（利用不可通知）。和食□屋はリニューアル！ “Japanese Dining - Square”に生まれ変わりました（代替情報）。」といった出力が可能となる。

このように利用不可通知と併せて代替情報を提供することで、効果的に利用可能な項目へとユーザを誘導することが可能となる。代替情報がなければ、例えば和食□屋が”Japanese Dining - Square”になったことをユーザは把握できず、結果としてリニューアル後の情報にはアクセスできなくなるということになる。

以上のように、本実施の形態では管理対象の項目にと関連付けて代替情報を管理し、利用不可通知と併せて代替情報を提示することで、ユーザを効果的に利用可能な項目へと誘導することが可能となる。
なお、上述の実施の形態では、代替情報を各項目に関連付けて記憶するように記載しているが、本発明はそのような構成に限定されない。項目から代替情報を取得することが可能なデータベースを、項目を管理するデータベースとは別に準備しても良い。

以上のように、管理対象の項目にと関連付けて代替情報を管理し、利用不可通知と併せて代替情報を提示するようなものであれば、そのような構成は本発明の主旨の範囲内である。

以上に示した実施の形態によれば、ユーザとの対話中を含めた対話装置１００の運用中にある項目が利用不可となったことを通知する利用不可通知を、ユーザ入力や対話進行に沿って出力することが可能となる。

なお、本発明の対話装置はアプリケーションと分離した構成であるかのように記述しているが、アプリケーションの機能を含有する対話装置であっても本発明の適用が可能である。例えばユーザに提示する情報を管理するデータベースを保持し、ユーザの要求する条件に基づいてそのデータベースを検索する機能を含有する対話装置の場合について考える。このような対話装置において、ユーザとの対話によってデータベース検索条件を取得し、取得した検索条件に基づいてそのデータベースを検索し、ユーザに対して回答を返す動作をする場合は、そのようなデータベース検索機能は本発明におけるアプリケーションの機能であり、データベース検索条件を取得することが本発明における話題に相当する。

また、データベース検索の他に種々の機能を保有する対話装置であっても、ユーザと対話をして各種機能の動作条件を決定しそれに基づいて各種機能を動作させる場合は、その機能は全て本発明におけるアプリケーションの機能と同一とみなせる。例えばユーザとの対話によって指定された条件で各種機能を動作させる構成や、対話装置から動作条件を提示してユーザからの承諾を得ることで各種機能を動作させる構成であっても、動作させる各種機能は本発明におけるアプリケーションの機能であると言える。

また、各実施の形態の説明においてはアプリケーションの機能を実行させることを話題解決時の一回だけ行うかのように記述しているが、本発明における話題は「アプリケーションにある機能を有効に動作させる」ことを目的とするものであり、その実行結果が有意なものでなければ（検索結果の件数が０件や多すぎる場合、コマンドの実行失敗など）話題を解決していないとみなし、再度その機能の実行条件の変更を行いアプリケーションの機能を複数回実行しても良い。実行条件はユーザから対話的に変更することも、対話装置から自動的に変更することも可能である。或いはある話題の対話中の途中経過において、ユーザとの対話進行のための手順として必要な機能を実行しても良い。

その他、本発明は、上記実施の形態に限定されるものでなく、実施段階では、その要旨を変更しない範囲で種々変形することが可能である。

さらに、上記実施の形態には、種々の段階の発明が含まれており、開示されている複数の構成要件における適宜な組み合わせにより種々の発明が抽出できる。例えば、実施の形態に示されている全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題を解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出できる。

また、上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいて実行されることが可能である。汎用の計算機システムが、このプログラムを予め記憶しておき、このプログラムを読み込むことにより、上述した実施形態の対話装置による効果と同様な効果を得ることも可能である。上述の実施形態で記述された指示は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷなど）、半導体メモリ、又はこれに類する記録媒体に記録される。コンピュータまたは組み込みシステムが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であってもよい。コンピュータは、この記録媒体からプログラムを読み込み、このプログラムに基づいてプログラムに記述されている指示をＣＰＵで実行させれば、上述した実施形態の対話装置と同様な動作を実現することができる。もちろん、コンピュータがプログラムを取得する場合又は読み込む場合はネットワークを通じて取得又は読み込んでもよい。
また、記憶媒体からコンピュータや組み込みシステムにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーションシステム）や、データベース管理ソフト、ネットワーク等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行してもよい。
さらに、本願発明における記憶媒体は、コンピュータあるいは組み込みシステムと独立した媒体に限らず、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
また、記憶媒体は１つに限られず、複数の媒体から本実施形態における処理が実行される場合も、本発明における記憶媒体に含まれ、媒体の構成は何れの構成であってもよい。

なお、本願発明におけるコンピュータまたは組み込みシステムは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するためのものであって、パソコン、マイコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であってもよい。
また、本願発明の実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の実施形態における機能を実現することが可能な機器、装置を総称している。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の第１の実施の形態の構成図。第１の実施の形態の動作を説明するフローチャート。第１の実施の形態の話題情報を説明する図。第１の実施の形態に用いられる話題管理部の構成図。第１の実施の形態の話題の例を説明する図。第１の実施の形態の動作を詳細に説明するフローチャート。第１の実施の形態の対話例を示す図。第１の実施の形態の対話例を示す図。第１の実施の形態の対話例を示す図。第１の実施の形態の対話例の説明における対話装置の状況を示す図。第１の実施の形態の他の例の構成図。第１の実施の形態の別構成の話題を説明する図。第１の実施の形態の動作を詳細に説明するフローチャート。本発明の第２の実施の形態の構成図。第２の実施の形態の呼称データの例を示す図。第２の実施の形態に用いられる呼称管理部の構成図。第２の実施の形態の動作を説明するフローチャート。第２の実施の形態の動作を詳細に説明するフローチャート。第２の実施の形態の対話例説明で利用する対話装置の状況を示す図。第２の実施の形態の対話例を示す図。第２の実施の形態の対話例を示す図。本発明の第４の実施の形態における項目の詳細例を示す図。第４の実施の形態の他の例の構成図。本発明の第５の実施の形態を説明する対話例を示す図。第１の実施の形態で音声入力利用を考慮した構成での話題の詳細例を示す図。音声認識文法の記述例を示す図。第１の実施の形態で音声認識を利用する場合の他の例の構成図。第２の実施の形態で音声入力を考慮した構成における呼称データの詳細例を示す図。本発明の第６の実施の形態の動作を説明するフローチャート。本発明の第８の実施の形態の動作を説明するフローチャート。本発明の第９の実施の形態の構成図。本発明の第１０の実施の形態で管理する項目の詳細例を示す図。本発明の第１１の実施の形態で管理する項目の詳細例を示す図。

符号の説明

１００…対話装置、１０１…対話進行部、
１０２…利用不可通知出力判定部、１０３…対話管理部、
１０４…対話更新部、２００…アプリ群、
４０１…利用不可話題管理部、４０２…正規話題管理部、
１４０１…対話進行部、１４０２…利用不可通知出力判定部、
１４０３…呼称管理部、１４０４…呼称更新部、
１６０１…利用不可呼称管理部、１６０２…正規呼称管理部、
２３０５…利用状況管理部、２７０５…音声認識文法管理部、
３１０３…使用履歴構成部、

Claims

ユーザと少なくとも音声入力により対話し、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する対話進行手段と、
前記ユーザとの対話で前記対話進行手段が参照する項目を正規項目と利用不可項目に分けて管理するとともに、前記対話進行手段が参照する項目に関連付けて音声認識文法を管理する項目管理手段と、
前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段と、
前記対話進行手段による項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する利用不可通知出力判定手段と
を具備し、
前記対話進行手段は、前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記利用不可通知出力判定手段による判定結果に基づいて利用不可通知を出力することを特徴とする対話装置。
前記項目更新手段は、前記ユーザとの対話により実行指定されるアプリケーションの構成を管理し、該アプリケーションの構成の変更にともなう前記項目の変更を前記項目管理手段の前記正規項目及び利用不可項目の管理に反映させることを特徴とする請求項１に記載の対話装置。
前記利用不可通知出力判定手段は、前記利用不可通知の情報量が所定の値を下回るように前記利用不可通知の出力対象の項目を選択することを特徴とする請求項１に記載の対話装置。
前記利用不可通知出力判定手段は、前記項目の利用状況に基づいて前記利用不可通知を出力する対象の項目を選択することを特徴とする請求項１に記載の対話装置。
前記利用不可通知出力判定手段は、前記対話進行手段により前記ユーザとの対話中に収集される前記対話進行内容に応じて参照する項目が利用不可な項目のみで構成されている場合に、利用不可通知を出力すると判定することを特徴とする請求項１に記載の対話装置。
前記項目更新手段は、利用不可通知を出力した後の該利用不可通知の対象となった項目を前記項目管理手段から削除することを特徴とする請求項１に記載の対話装置。
前記対話進行手段は、前記項目管理手段で管理される前記利用不可項目について各項目の利用状況を判断し、該利用状況に基づいて削除する項目を特定し、前記項目更新手段は、該特定された項目を前記前記項目管理手段から削除することを特徴とする請求項１に記載の対話装置。
前記項目更新手段は、音声認識文法の一部を前記項目管理手段から削除可能にしたことを特徴とする請求項１に記載の対話装置。
前記項目更新手段は、利用不可通知を出力した後の該利用不可通知の対象となった項目に関連付けられた音声認識文法の一部を前記項目管理手段から削除することを特徴とする請求項１に記載の対話装置。
前記対話進行手段は、前記項目管理手段で管理される前記利用不可項目について各項目の利用状況を判断し、該利用状況に基づいて音声認識文法を削除する項目を特定し、
前記項目更新手段は、該特定された項目に関連付けられた音声認識文法の一部を前記項目管理手段から削除することを特徴とする請求項１に記載の対話装置。
さらにユーザによる項目の使用履歴を構成する使用履歴構成手段を有し、
該使用履歴構成手段は、前記構成された項目の使用履歴から現時点で利用不可項目を抽出し、この結果を前記前記項目管理手段により管理される利用不可項目に移動することを特徴とする請求項１に記載の対話装置。
前記項目管理手段は、前記項目をさらにカテゴリで分類管理し、
前記利用不可通知出力判定手段は、前記利用不可通知を出力する対象の項目が所属する前記カテゴリの全ての項目が利用不可であったとき、前記カテゴリ単位で利用不可通知を出力することを特徴とする請求項１に記載の対話装置。
前記項目管理手段は、さらに各項目に関連付けて管理される代替情報を設定し、
前記利用不可通知出力判定手段は、前記利用不可通知を出力する際に、前記関連付けられた代替情報も出力することを特徴とする請求項１に記載の対話装置。
ユーザとの対話で参照される項目を正規項目と利用不可項目に分けて管理するとともに、前記参照される項目に関連付けて音声認識文法を管理する項目管理手段と、前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段を有する対話装置に適用される対話方法であって、
対話対象となる項目の目的を前記ユーザとの少なくとも音声入力による対話進行により達成するとともに、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する第１のステップと、
前記第１のステップによる前記項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する第２のステップと、
前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記第２のステップによる判定結果に基づいて利用不可通知を出力する第３のステップと
を有することを特徴とする対話方法。
ユーザとの対話で参照される項目を正規項目と利用不可項目に分けて管理するとともに、前記参照される項目に関連付けて音声認識文法を管理する項目管理手段と、前記収集された項目が利用不可になったことを検出し、前記利用不可になった項目を正規項目から利用不可項目に変更する項目更新手段を有する対話装置を制御するためのプログラムであって、
コンピュータに、
対話対象となる項目の目的を前記ユーザとの少なくとも音声入力による対話進行により達成するとともに、前記ユーザとの対話中に対話進行内容に応じて参照する項目を収集する第１のステップと、
前記第１のステップによる前記項目の収集結果により前記項目管理手段を参照し、前記収集結果に利用不可の項目が含まれている場合、利用不可通知の出力を判定する第２のステップと、
前記正規項目に分けられた項目と前記利用不可項目に分けられた項目の各々に関連付けられている音声認識文法を全て統合した音声認識文法により音声認識し、該認識結果に基づき対話進行内容を定め、参照する項目を収集するとともに、前記第２のステップによる判定結果に基づいて利用不可通知を出力する第３のステップと
を実行させるためのプログラム。