(57)【要約】対話システムにおけるユーザの待ち時間を有効に利用する。対話装置は、ユーザと第１対話を行い、第１対話の途中でユーザの待ち時間が発生すると第２対話を開始するかどうかを判断する。例えば、第１対話の途中でそれ以上の第１対話の継続に必要な情報をネットワークを介して取得する場合、待ち時間が発生する。待ち時間が長そうであれば、待ち時間の間に第２対話を行い、その終了後に第１対話を再開する。これにより、ユーザは、対話の途中での待ち時間が短くなり、接続時間を有効に活用することができる。
2004092967.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが操作するユーザ端末と対話を行う対話装置であって、
前記ユーザ端末と第１対話及び第２対話を行う対話部と、
前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御部と、
前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信部と、
を備える対話装置。
【請求項２】
実行中の対話の継続に用いる情報を取得するための１または複数の情報取得処理の実行状態を監視する第１監視部と、
情報取得処理の開始に先立ち情報の取得に要する時間を予測する予測部と、をさらに備え、
前記制御部は、前記第１対話の継続に用いる情報の取得に要すると予測された予測時間に基づいて前記第２対話を開始するか否かを判断する、
請求の範囲第１項記載の対話装置。
【請求項３】
対話の継続に用いる情報を取得するのに要した時間の履歴を記憶しておく履歴部をさらに備え、
前記予測部は、前記情報取得時間の履歴に基づいて、情報の取得に要する時間を予測する、
請求の範囲第２項記載の対話装置。
【請求項４】
前記予測部は、前記情報を検索する情報検索装置に対して前記情報の検索に要する時間の予測を要求し、前記要求に対する前記情報検索装置からの応答を受信し、
前記制御部は、前記応答に基づいて前記第２対話を開始するか否かを判断する、
請求の範囲第２項記載の対話装置。
【請求項５】
対話の実行状態を監視する第２監視部をさらに備え、
前記制御部は、実行中の対話のうちいずれか１の対話を前記ユーザ端末との間で行い、その他の対話を一旦停止の状態とするよう、実行中の対話の実行状態を管理する、
請求の範囲第１項記載の対話装置。
【請求項６】
前記実行中の対話の継続に用いる情報を取得するための１または複数の情報取得処理の実行状態を監視する第１監視部をさらに備え、
前記制御部は、対話の実行状態と情報取得処理の実行状態とに基づいて、前記ユーザ端末との間で行う対話を選択及び／または切り替える、
請求の範囲第５項記載の対話装置。
【請求項７】
前記制御部は、一旦停止させた対話について、停止時点までに実行された前記対話に関する情報をさらに記憶し、前記情報取得処理の終了後に記憶した情報と前記対話の継続のために取得した情報とに基づいて前記対話を再開させる、請求の範囲第６項記載の対話装置。
【請求項８】
対話の識別子を記憶する対話記憶部と、
前記ユーザ端末を識別するユーザ識別子と前記ユーザ端末との間で実行中の対話の識別子とを対応付けて記憶する対話履歴記憶部と、をさらに備え、
前記制御部は、前記ユーザ端末との間で実行中の対話以外の対話の中から前記第２対話を選択する、
請求項１に記載の対話装置。
【請求項９】
ユーザが操作するユーザ端末と対話を行うコンピュータが実行する対話プログラムであって、
前記ユーザ端末と第１対話及び第２対話を行う対話ステップと、
前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御ステップと、
前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信ステップと、
を前記コンピュータに実行させる対話プログラム。
【請求項１０】
ユーザが操作するユーザ端末とコンピュータが対話を行う対話方法であって、
前記ユーザ端末と第１対話及び第２対話を行う対話工程と、
前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御工程と、
前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信工程と、
を含む対話方法。
【発明の詳細な説明】
【技術分野】  本発明は、人間とコンピュータとの対話における利便性を高める技術に関する。
本発明において、対話には音声対話及びテキスト対話を含む。対話は、少なくとも１つの人間側からのメッセージと、少なくとも１つのコンピュータ側からのメッセージとを含む。以下では、人間側からコンピュータに入力されるメッセージをユーザメッセージという。また、コンピュータから出力されるメッセージをシステムメッセージという。
【背景技術】  近年では、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）上で提供される情報の一部を、音声対話システムを使って提供する音声ポータルが一般的になりつつある。音声ポータルにおいては、対話シナリオを記述する言語としてＶｏｉｃｅＸＭＬが使用されることが多い。音声ポータルなどで使われている音声対話システムは、音声による対話をユーザと行い、検索処理に必要な情報を獲得した後、データベースを用いた情報検索処理を行う。データベースを含む検索システムに検索を依頼してから応答を得るまでには、数秒から数十秒の待ち時間が発生することがある。とりわけ、音声ポータルからネットワークを介して情報を取得する場合には、検索時間に加え、ネットワークによる遅延が発生する。この待ち時間中のユーザのストレスを解消するために、従来の音声対話システムでは、情報検索中であることを伝えるプロンプトを流したり、企業の広告音声を流すといったことが行われている。
しかし、前記プロンプトを流したり広告音声を流すだけでは、ユーザは待ち時間の間に一方的にシステム出力を聞いているだけである。これでは、ユーザは音声対話システムとの接続時間を有効に利用していることにならない。
本発明は、ユーザと対話システムとの接続時間を有効に活用できる技術を提供することを目的とする。
【発明の開示】
前記の課題を解決するために、本願第１発明は、ユーザが操作するユーザ端末と対話を行う対話装置を提供する。この対話装置は、以下の構成要素を有する。
・前記ユーザ端末と第１対話及び第２対話を行う対話部、
・前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御部、
・前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信部。
対話装置は、ユーザと第１対話を行い、第１対話の途中でユーザの待ち時間が発生すると第２対話を開始するかどうかを判断する。例えば、第１対話の途中でそれ以上の第１対話の継続に必要な情報をネットワークを介して取得する場合、待ち時間が発生する。待ち時間が長そうであれば、待ち時間の間に第２対話を行い、その終了後に第１対話を再開する。これにより、ユーザは、対話の途中での待ち時間が短くなり、接続時間を有効に活用することができる。
本願第２発明は、前記第１発明において、実行中の対話の継続に用いる情報を取得するための１または複数の情報取得処理の実行状態を監視する第１監視部と、情報取得処理の開始に先立ち情報の取得に要する時間を予測する予測部と、をさらに備える対話装置を提供する。この装置において、前記制御部は、前記第１対話の継続に用いる情報の取得に要すると予測された予測時間に基づいて前記第２対話を開始するか否かを判断する。
対話装置は、待ち時間がある程度長い場合に第２対話を行い、待ち時間が短い場合には第２対話を行わない。その判断は、第１対話の途中で必要となった情報を取得するのに要する時間を予測し、その予測時間が所定のしきい値Ｔ０より長いか否かにより行うことができる。
本願第３発明は、前記第２発明において、対話の継続に用いる情報を取得するのに要した時間の履歴を記憶しておく履歴部をさらに備え、前記予測部は、前記情報取得時間の履歴に基づいて、情報の取得に要する時間を予測する対話装置を提供する。
情報取得時間の予測は次のようにして行うことができる。過去の情報取得時間の履歴を蓄積しておき、例えばその平均値を予測時間とする。
本願第４発明は、前記第２発明において、前記予測部は、前記情報を検索する情報検索装置に対して前記情報の検索に要する時間の予測を要求し、前記要求に対する前記情報検索装置からの応答を受信し、前記制御部は、前記応答に基づいて前記第２対話を開始するか否かを判断する対話装置を提供する。
情報取得時間の別の予測方法として次の方法がある。情報検索時間の予測機能を有する情報検索装置に対し、検索の依頼に先立って情報取得時間の予測を依頼する。情報検索装置は、その依頼に基づいて予測時間を算出し、対話装置に返す。対話装置は、その予測時間が長ければ、情報の検索を依頼すると共に第２対話を開始する。なお、情報検索装置が情報検索時間を予測する方法としては、情報検索装置が自分自身による情報検索時間の履歴を記憶しておき、その履歴に基づいて情報検索時間の予測値を算出する方法が挙げられる。
本願第５発明は、前記第１発明において、対話の実行状態を監視する第２監視部をさらに備える対話装置を提供する。この装置において、前記制御部は、実行中の対話のうちいずれか１の対話を前記ユーザ端末との間で行い、その他の対話を一旦停止の状態とするよう実行中の対話の実行状態を管理する。
制御部は、対話装置でどの対話が実行されているかを監視する。第１対話と第２対話とが実行中であれば、第１対話または第２対話のどちらかをユーザ端末との間で行い、一方の対話を一旦停止状態とする。例えば、第１対話の一旦停止中に第２対話を実行させることができる。また例えば、第１対話の情報取得待ちの間は第１対話を一旦停止させ、第２対話を開始させてもよい。
本願第６発明は、前記第５発明において、前記実行中の対話の継続に用いる情報を取得するための１または複数の情報取得処理の実行状態を監視する第１監視部をさらに備える対話装置を提供する。この装置において、前記制御部は、対話の実行状態と情報取得処理の実行状態とに基づいて、前記ユーザ端末との間で行う対話を選択及び／または切り替える。
例えば、第１対話の途中でさらなる情報が対話の継続のために必要になった場合、その情報の取得処理の間は第１対話を一旦停止し、その後に第２対話を開始させることができる。第２対話による対話中に情報取得処理が終了した場合には、第２対話を一旦停止して第１対話を再開させても良いし、第２対話の終了を待って第１対話を再開させても良い。逆に、第２対話が情報取得処理の終了前に終了した場合、情報取得処理の終了を待って第１対話を開始させても良いし、別の第３対話を開始させても良い。
第６発明の対話装置において、前記制御部は、前記第１対話の継続に用いる情報を取得するための情報取得処理が前記第１対話の実行中に開始された場合、前記第１対話を一旦停止させた後に前記第２対話を開始させることもできる。例えば、第１対話の途中でさらなる情報が対話の継続のために必要になった場合、第１対話を一旦停止し、その後に第２対話を開始させることができる。制御部は、前記予測時間に応じ、第１対話を一旦停止するか否かを判断しても良い。すなわち、予測時間がしきい値Ｔ０以上であれば、第１対話を一旦停止し、第２対話を開始させるのでもよい。
本願第７発明は、前記第６発明において、前記制御部が、一旦停止させた対話について、停止時点までに実行された前記対話に関する情報をさらに記憶し、前記情報取得処理の終了後に記憶した情報と前記対話の継続のために取得した情報とに基づいて前記対話を再開させる対話装置を提供する。
制御部は、第１対話を一旦停止する場合、それまでの対話中に得られた情報やどこまで対話を行ったかを示す情報などを記憶しておく。これらの情報と取得した情報とに基づいて、第１対話が再開される。
前記第７発明における対話装置において、前記制御部は、前記ユーザ端末との間で行われている別の対話が一旦停止した後または終了した後、一旦停止させた前記対話を再開させることもできる。必要な情報を取得した時点で第２対話がまだ実行中の場合、第１対話の再開の方法は２通り考えられる。１つ目は、第２対話の実行の終了を待って再開する方法である。２つ目は、情報を取得できた時点で第２対話を一旦停止させて第１対話を再開する方法である。２つ目の方法を採るときには、例えば第１対話の終了後に第２対話を再開させればよい。
本願第８発明は、前記第１発明において、対話の識別子を記憶する対話記憶部と、前記ユーザ端末を識別するユーザ識別子と前記ユーザ端末との間で実行中の対話の識別子とを対応付けて記憶する対話履歴記憶部と、をさらに備える対話装置を提供する。この装置において、前記制御部は、前記ユーザ端末との間で実行中の対話以外の対話の中から前記第２対話を選択する。
ユーザが対話装置と行っている対話を記憶しておき、その対話が一旦停止している間には同じ対話ではなく別の対話を第２対話として選択する。対話記憶部を２種類設けておき、対話が一旦停止している間に実行するための比較的短い対話を、待機用対話として一方の対話記憶部に蓄積しておいてもよい。例えば、第１対話が一旦停止している時間が長い場合には、待機用対話を次々に実行することにより、ユーザを待たせずにすむ。
本願第９発明は、ユーザが操作するユーザ端末と対話を行うコンピュータが実行する対話プログラムであって、下記ステップを前記コンピュータに実行させる対話プログラムを提供する。
・前記ユーザ端末と第１対話及び第２対話を行う対話ステップ、
・前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御ステップ、
・前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信ステップ。
本願第１０発明は、ユーザが操作するユーザ端末とコンピュータが対話を行う対話方法であって、下記工程を含む対話方法を提供する。
・前記ユーザ端末と第１対話及び第２対話を行う対話工程、
・前記第２対話を前記第１対話の実行中に開始するか否かを判断し、前記判断結果に応じて前記第１対話の実行中に前記第２対話を開始させる制御工程、
・前記第１対話の結果である第１結果及び前記第２対話の結果である第２結果を、前記ユーザ端末に送信する結果送信工程。
【図面の簡単な説明】  図１は、本発明の第１実施形態に係る対話装置１の機能構成図である。
図２は、第１対話と第２対話とが並列的に行われる例を示す説明図である。
図３（ａ）は、時間履歴ＤＢ２３に蓄積される情報の概念説明図である。
図３（ｂ）は、検索装置ごとに情報取得時間の平均を取る方法を示す説明図である。
図３（ｃ）は、時間帯ごとに平均取得時間を求める方法をを示す説明図である。
図４は、予測時間の取得方法を示す説明図である。
図５は、図１の対話管理ユニットが行う対話処理の管理方法の説明図（１）である。
図６は、図１の対話管理ユニットが行う対話処理の管理方法の説明図（２）である。
図７は、図１の監視テーブルが対話の実行状態及び検索要求の実行状態に応じて遷移する状態を示す説明図（１）である。
図８は、図１の監視テーブルが対話の実行状態及び検索要求の実行状態に応じて遷移する状態を示す説明図（２）である。
図９は、図１の対話履歴テーブルの概念説明図である。
図１０は、ユーザＤＢに蓄積される情報の概念説明図である。
図１１は、図１の対話装置が行う処理の流れの一例を示すフローチャートである。
図１２は、本発明の別の実施形態に係る対話装置を含む対話システムの全体構成図である。
図１３は、本発明のさらに別の実施形態に係る対話装置を含む対話システムの全体構成図である。
図１４は、プログラムを記憶するコンピュータ読み取り可能な記録媒体の説明図である。
【発明を実施するための最良の形態】  ＜第１実施形態例＞
（１）全体構成
図１は、本発明の第１実施形態に係る対話装置１の機能構成図を示す。対話装置１は、ユーザが操作するユーザ端末２とネットワーク５を介して対話を行う。また、対話装置１は、ネットワーク６を介してＷＷＷサーバ３などのネットワーク上のサーバと接続されており、予約データベース（ＤＢ）４に蓄積された情報をＷＷＷサーバ３から取得する。以下では説明を容易にするために、音声対話を例に取り説明する。
対話装置１は、ユーザ端末２との間で音声対話を行う（後述する（２−１）「対話処理」）。対話装置１は、ユーザ端末２との間で第１対話を実行中に生じた待ち時間の間に前記第２対話を開始するか否かを判断する（後述する（２−２）「開始判断処理」）。前記判断結果に応じて前記第２対話を開始し、複数の対話を平行して実行する。ただし、実行中のいずれか１つの対話がユーザ端末との間で行われ、その他の対話は一旦停止した状態となるよう、複数の対話の実行状態を管理する（後述する（２−３）「対話管理処理」）。対話装置１は、待ち時間中に行う対話により、ユーザに関する情報を取得することもできる（後述する（２−４）「システム属性変更処理」）。各対話の結果は、各対話がそれぞれ終了した時点で、または全ての対話が終了した後に、ユーザ端末２に送信される。
図２は、対話装置１とユーザ端末２との間で第１対話と第２対話とが並列的に行われる例を示す説明図である。この例では第１対話は交通機関の予約に関する対話であり、第２対話は対話装置１の発話スピード、音量などの対話属性に関する対話である。第１対話の途中で交通機関のデータベースを参照するための待ち時間の間に、第２対話が実行される。第２対話の終了後、第１対話が再開されている。これにより、ユーザは、対話の途中での待ち時間が短くなり、接続時間を有効に活用することができる。また対話装置１は、待ち時間を利用してユーザごとの対話属性を取得することができる。
（２）対話装置
（２−１）対話処理
対話装置１は、ユーザ端末２との間で音声対話を行う。対話処理に必要な対話シナリオは、シナリオＤＢ１４に蓄積されている。各対話シナリオは、例えばＶｏｉｃｅＸＭＬにより記述され、シナリオＩＤにより識別される。ユーザ端末２の音声入力部２１にマイクなどから入力された音声信号は、入出力制御部２２からネットワーク５を介して対話装置１の入出力制御部１１に音声ユーザメッセージとして受信される。音声ユーザメッセージは、音声認識部１２により音声データからテキストデータに変換される。対話部１０は、テキストデータに変換されたユーザメッセージに基づいていずれかの対話シナリオに従った対話処理を行い、出力するシステムメッセージを決定する。対話部１０から出力されたシステムメッセージは、音声合成部１３によりテキストデータから音声データに変換され、入出力制御部１１から送信される。音声システムメッセージは、ユーザ端末２の入出力制御部２２に受信され、音声出力部２３からスピーカなどの出力デバイスに出力される。
（２−２）開始判断処理
対話装置１の制御部２０は、対話の実行中に別の対話を開始するか否かを判断する。具体的には、制御部２０の開始判断ユニット２１は、対話の実行中に発生する検索要求により生じる待ち時間の長さを予測する。検索要求とは、実行中の対話の継続に用いる情報の検索を外部の検索装置（本例ではＷＷＷサーバ３）に要求する処理である。例えば、飛行機のチケット予約のための対話を行っている場合、ユーザが希望する便の空き情報を予約ＤＢ４から取得する必要がある。このような場合、開始判断ユニット２１は、検索処理の要求から応答までに要する情報取得時間を予測し、予測時間に基づいて別の対話を開始するか否かを判断する。例えば第１対話を実行中の対話装置１は、待ち時間がある程度長い場合に第２対話を開始し、待ち時間が短い場合には第２対話を開始しない。その判断は、予測時間が所定のしきい値Ｔ０より長いか否かにより行うことができる。
（２−２−１）平均値による予測時間の算出
予測時間を求める１つの方法としては、過去の情報取得時間の平均値を予測時間とする方法が挙げられる。情報取得時間の履歴を蓄積する時間履歴ＤＢ２３を設けておき、記憶された情報取得時間の平均値を予測時間とするのである。図３（ａ）は、時間履歴ＤＢ２３に蓄積される情報の概念説明図である。図３（ａ）に示すように、時間履歴ＤＢ２３には情報取得時間に加え、検索処理を要求した日時、検索装置の識別子などを蓄積しても良い。
図３（ｂ）、（ｃ）は、同図（ａ）に示す時間履歴ＤＢ２３に基づいて情報取得時間の平均値（平均取得時間）を求める一例を示す説明図である。同図（ｂ）は、検索装置ごとに情報取得時間の平均を取る方法を示している。例えばこの図では、検索装置ｗｗｗ．ｆｕｊｉａｉｒ．ｃｏｍに検索処理を要求した場合の平均取得時間は１４．３秒である。対話実行中にこの検索装置への検索要求が生じた場合、予測時間は１４．３秒となる。図３（ｃ）は、時間帯ごとに平均取得時間を求める方法を示している。例えばこの図では、１２：００〜１３：００の検索時間帯の平均取得時間は３０．３秒である。検索要求が生じた時間帯が１２：００〜１３：００であれば、予測時間は３０．３秒となる。なお、図３（ｂ）、（ｃ）に示す検索装置ごとの平均取得時間や、時間帯ごとの平均取得時間は、検索要求が生じるごとに演算することができる。また、演算結果を保持して検索要求が生じた場合にはすぐに参照できるようにしておくこともできる。この場合は、新たに検索結果を取得するごとに演算結果を更新するとよい。
（２−２−２）検索装置からの予測時間の取得
開始判断ユニット２１は、検索結果の取得に要する予測時間を、検索装置から取得しても良い。図４は、この場合の予測時間の取得方法を示す説明図である。開始判断ユニット２１は、検索装置、この場合はＷＷＷサーバ３に対し、情報の検索に要する時間の予測を要求する（＃１）。この要求は、検索要求に先立って行う。要求を受信したＷＷＷサーバ３の予測部３１は、検索時間履歴ＤＢ３２を参照し（＃２）、例えば時間帯ごとの平均検索時間を演算する。なお、検索時間ＤＢ３２には、検索日時と検索時間とが対応付けて記憶されている。演算結果はバッファ３３に一時的に保持される。次いで、検索時間の予測要求を受信した時間帯に応じた平均検索時間がバッファ３３から読み出され（＃３３）、開始判断ユニット２１に送信される。開始判断ユニット２１はこの値がしきい値Ｔ０を超えていれば別の対話を開始すると判断する。なお、検索装置が平均検索時間を予測する方法としては、時間帯ごとに平均値を求める方法に限定されない。
（２−３）対話管理処理
（２−３−１）対話管理
対話装置１の制御部２０は、第１対話と第２対話とが実行されている場合、いずれか１つの対話をユーザ端末２との間で行うように、実行中の対話を管理する。その他の対話は一時停止状態となる。より具体的には、制御部２０の対話管理ユニット２２は、対話の実行状態及び検索処理の実行状態を監視し、監視結果を監視テーブル２４に一時的に記憶する。さらに、対話管理ユニット２２は、監視テーブル２４に基づいて、前記ユーザ端末との間で１の対話を行うように複数の対話処理を管理する。
図５，６は、対話管理ユニット２２が行う対話処理の管理方法の説明図である。図５（ａ）、（ｃ）、（ｄ）は、第１対話処理中に実行される検索処理の間に第２対話処理を行う場合の管理方法を示す。図５（ｂ）は、予測時間が短いため、第２対話を行わない場合を示す。
図５（ａ）、（ｃ）、（ｄ）についてさらに詳述する。例えば、第１対話の途中でさらなる情報が第１対話の継続のために必要になった場合を考える。まずその情報の検索要求を出し、検索処理の結果待ちの間は第１対話を一旦停止して第２対話を開始させることができる（状態Ｓ２）。第２対話が検索処理の応答受信前に終了した場合（状態Ｓ３）、検索処理の応答受信を待って第１対話を開始させることができる（状態Ｓ４）（同図（ａ））。また、別の第３対話を開始させても良い。逆に、第２対話による対話中に情報取得処理が終了した場合は、第２対話の終了を待って（状態Ｓ５）第１対話を再開させても良いし（状態Ｓ４）（同図（ｃ））、第２対話を一旦停止して第１対話を再開させても良い（状態Ｓ６）（同図（ｄ））。
図５に示すように、第１対話情報に対応する検索処理の応答後に第２対話がまだ実行中の場合、第１対話の再開の方法は２通り考えられる。１つ目は、第２対話の実行の終了を待って再開する方法である。２つ目は、応答を受信した時点で第２対話を一旦停止させて第１対話を再開する方法である。２つ目の方法を採るときには、例えば第１対話の終了後に第２対話を再開させればよい。
図６（ａ）は、第２対話の実行中に、第２対話の継続に必要な情報が必要になった場合の管理方法の一例を示す説明図である。対話管理ユニット２２は、第１対話に対応する第１検索処理と同様に、第２対話に対応する第２検索処理を管理することも可能である。第２対話に必要な情報を検索する第２検索処理の応答待ちの間に既に第１検索処理が終了していれば第１対話処理を再開させ（状態Ｓ８）、第１対話処理が終了するのを待って（状態Ｓ９）第２対話を再開及び終了させる（状態Ｓ７）。
図６（ｂ）は、第２検索処理の間にさらに第３対話処理を実行させる管理方法の一例を示す説明図である。第１対話に対する第２対話と同様に、第２対話に対して第３対話を実行することも可能である。第１検索処理の応答待ちと第２検索処理の応答待ちとが重なった場合（状態Ｓ９）、第３対話処理を実行させる。第１検索処理が終了しても（状態Ｓ１０）、さらに第２検索処理が終了しても（状態Ｓ１１）、第３対話処理の終了を待ってから第２対話処理及び第１対話処理を再開させる（状態Ｓ５，Ｓ４）。上記の管理方法は、実行中の対話処理とそれに対応する検索処理の応答待ちとの関係に基づいて１つの対話処理がユーザ端末２との間で行われることを示す一例である。
図７，８は、監視テーブル２４が対話の実行状態及び検索要求の実行状態に応じて遷移する状態を示す説明図である。各監視テーブル２４は、図５，６中の状態Ｓ１、Ｓ２・・・Ｓ１１における状態を示す。各監視テーブル２４は、以下の情報を含む。
ａ）その時点で対話装置１が実行中の対話シナリオのシナリオＩＤ、
ｂ）実行中の対話シナリオが一旦停止／対話中のいずれの状態であるか、
ｃ）各対話シナリオに対応して実行され応答待ちである検索処理の識別子、
この図では、第１対話シナリオの識別子がｒｅｓｅｒｖａｔｉｏｎ．ｘｍｌで有り、第２対話シナリオの識別子がｕｐｄａｔｅ．ｘｍｌの場合を示す。
（２−３−２）対話の再開
対話管理ユニット２２は、停止させた対話の再開に必要な再開情報を、再開情報テーブル２５に一時的に記憶する。再開情報は、停止させた対話の継続に用いる情報である。再開情報としては、対話をどこまで実行したかや、検索要求に対する検索結果が挙げられる。再開情報は対話部１０に渡され、どこまで対話を実行したかや検索結果に応じ、次のシステムメッセージが出力される。
（２−３−３）対話履歴
対話管理ユニット２２は、ユーザ端末２ごとに実行中の対話を管理する。図９は、対話履歴テーブル２６の概念説明図である。対話履歴テーブル２６は、ユーザ端末２の識別子であるユーザＩＤと、そのユーザ端末２との間で実行中の対話シナリオのシナリオＩＤとを一時的に記憶する。待ち時間が発生した場合、対話管理ユニット２２は、対話履歴テーブル２６を参照し、ユーザ端末２との間で実行している対話シナリオを特定する。次いで、ユーザ端末２が実行していない対話シナリオを、シナリオＤＢ１４の中から選択する。これにより、ユーザは同じ対話を繰り返さずにすむ。
なお、シナリオＤＢ１４を２種類設けておいてもよい。つまり、対話が一旦停止している間に実行するための比較的短い対話シナリオを、待機用対話シナリオとして一方のシナリオＤＢに別途蓄積しておいてもよい。例えば、待ち時間が長い場合には、待機用対話シナリオを次々に実行することにより、同じ対話をユーザに対して繰り返さずにすみ、しかも待機用対話シナリオの決定が容易である。
（２−４）システム属性変更処理
制御部２０のシステム属性ユニット２７は、待機用対話シナリオの実行によりユーザに関する情報を取得し、ユーザＤＢ２８に蓄積することができる。図１０は、ユーザＤＢ２８に蓄積される情報の概念説明図である。ユーザＤＢ２８には、ユーザＩＤの他に氏名、性別などの個人情報や、対話属性を蓄積することができる。対話属性とは、例えばシステムメッセージの出力スピード、システムメッセージの音量、合成音声の性別を挙げることができる。取得する情報は待機用対話シナリオの作り方に依存し、特に限定されない。例えば前記図２に示す待機用対話シナリオを用いれば、対話属性を取得することができる。ユーザＤＢ２８に蓄積した情報は、ユーザ端末２との対話を行う場合や待機用対話シナリオを選択するのに用いることができる。
（３）処理の流れ
図１１は、対話装置１が行う処理の流れの一例を示すフローチャートである。説明を容易にするために、この図では第１対話中に発生した情報検索処理の間に第２対話が開始される場合を例に取る。また、第１対話の再開のタイミングは、情報を取得後かつ第２対話の終了後の場合を例に取る。
ステップＳ１０１：まず対話部１０がユーザ端末２との間で第１対話処理を開始する。第１対話処理は、本処理とは独立に実行される。
ステップＳ１０２：第１対話処理中に、第１対話の継続に必要な情報の検索の必要性が生じると、検索の指示が対話部１０から制御部２０に渡される。制御部２０の対話管理ユニット２２は、この指示に基づいて、外部の検索システムに情報の検索を依頼する。
ステップＳ１０３：制御部２０は、別の対話を開始するか否かを判断する。具体的には、開始判断ユニット２１により検索される情報の取得時間を予測し、予測時間がしきい値Ｔ０より長ければ別の対話を開始すると判断してステップＳ１０４に移行する。その他の場合には第１対話のみをする。
ステップＳ１０４：制御部２０は、第１対話の一旦停止中に行う対話を対話シナリオ１４から選択する。具体的には、対話管理ユニット２２が対話履歴テーブルを参照し、既に実行中の対話以外の第２対話を選択する。
ステップＳ１０５：制御部２０の対話管理ユニット２２は、対話部１０に対し、第１対話処理の一旦停止を指示する。また対話管理ユニット２２は、第１対話の再開に必要な情報、言い換えれば第１対話の継続に必要な情報を、第１対話シナリオの識別子と対応付けて再開情報テーブルに書き込む。
ステップＳ１０６：対話管理ユニット２２は、対話部１０に第２対話処理の開始を指示する。
ステップＳ１０７、１０８：対話管理ユニット２２は、検索の要求に対する応答を受信し（Ｓ１０７の“Ｙｅｓ”）、かつ第２対話処理が終了すれば（Ｓ１０８の“Ｙｅｓ”）、ステップＳ１０９に移行する。検索結果を受信していても第２対話処理が終了していない場合は、第２対話処理を続行する（Ｓ１０８の“Ｎｏ”）。
ステップＳ１０９：対話管理ユニット２２は、再開情報テーブルに書き込まれた情報と検索結果とを対話部１０に渡し、第１対話処理を再開させる。
この処理により、ユーザは第１対話の間に生じる待ち時間を有効に利用して他の対話を行うことができる。また、対話システムは、その待ち時間の間に行う対話により、そのユーザに関する情報を取得することができる。
＜その他の実施形態例＞
（Ａ）前記第１実施形態は、音声対話システムを例に取り説明したが、本発明はテキスト対話にも適用できる。テキスト対話は、システムメッセージとユーザメッセージとが交互、つまり１つのシステムメッセージが出力されると、それに対してユーザメッセージが入力される形態でも良い。また、１画面に出力されている複数のシステムメッセージに対して複数のユーザメッセージを入力することにより行う形態でも良い。
（Ｂ）前記第１実施形態は、対話シナリオが対話装置１上にある場合を示しているが、対話シナリオの全部または一部は、対話装置１が接続可能な別のコンピュータ上にあっても良い。
図１２は、待機用シナリオＤＢ１４１が対話装置１に、第１対話シナリオＤＢ１４２が対話装置１以外の任意のコンピュータに設けられている場合の全体構成図を示す。待機用シナリオＤＢ１４１は、待ち時間に行う待機用シナリオを蓄積したデータベースである。第１対話シナリオＤＢ１４２は、待機用シナリオ以外のシナリオの一部または全部を蓄積しているデータベースである。第１対話シナリオＤＢ１４２は、１つまたは複数存在しても良い。各第１対話シナリオＤＢ１４２は、それぞれ別のコンピュータに設けられていても良い。なお、対話装置１の機能構成は、シナリオＤＢ１４に代えて待機用シナリオＤＢ１４１が設けられていることを除き、第１実施形態と同様である（図示せず）。
この場合、対話装置１は、第１対話シナリオＤＢ１４２のいずれかから対話シナリオを取得して実行する。その実行中に待機用シナリオを待機用シナリオＤＢ１４１から読み出して実行する。
図１３は、第１対話シナリオＤＢ１４３及び第２対話シナリオＤＢ１４４が、それぞれ対話装置１以外の任意のコンピュータに設けられている場合の全体構成図を示す。第１対話シナリオＤＢ１４３及び第２対話シナリオＤＢ１４４のそれぞれには、任意の対話シナリオが少なくとも１つ蓄積されている。対話装置１は、シナリオＤＢ１４に代えて、対話シナリオＩＤと対話シナリオのアドレスとを記憶していることを除き、第１実施形態と同様の機能構成を有している（図示せず）。実行しようとする対話シナリオは、記憶しているアドレスにアクセスすることにより取得する。ただし、待ち時間中に実行する対話は短い方が好ましいので、いずれかのデータベースを待機用対話シナリオを蓄積したデータベースとすることが好ましい。または、待機用対話シナリオとして適当な長さを有する対話シナリオの対話シナリオＩＤと対応付けて、待機用シナリオマークを記憶しておくことが好ましい。
（Ｃ）前述の対話方法をコンピュータ上で実行するための対話プログラム及びその対話プログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
なお図１４に示すように、前記対話プログラムを記録したコンピュータ読み取り可能な記録媒体は、対話プログラムを実行するコンピュータ１７３上にあっても、また別の場所にあっても良い。つまり、対話プログラムを格納する記録媒体は、ＣＤ−ＲＯＭ１７２−１やフレキシブルディスク１７２−２等の可搬型記録媒体１７２、通信回線の先に備えられた他の記憶装置１７１、コンピュータ１７３のハードディスクやＲＡＭなどの記録媒体１７４のいずれであってもよい。プログラム実行時には、プログラムはコンピュータ１７３にローディングされ、メインメモリ上で実行される。
また本発明の実施の形態に係る対話装置により生成された処理可能情報等のデータを格納するコンピュータ読み取り可能な記録媒体についても、図１４に示すように、対話プログラムを実行するコンピュータ１７３上にあっても、また別の場所にあっても良い。つまり、データを記憶する記録媒体は、ＣＤ−ＲＯＭ１７２−１やフレキシブルディスク１７２−２等の可搬型記録媒体１７２、通信回線の先に備えられた他の記憶装置１７１、コンピュータ１７３のハードディスクやＲＡＭなどの記録媒体１７４のいずれであってもよい。これらの記録媒体に記憶されたデータは、対話プログラムを実行するコンピュータ１７３により読みとられる。
【産業上の利用可能性】  本発明を利用すれば、ユーザはユーザ端末と対話システムとの接続時間を有効に活用することができる。
【図１】
2004092967.tif 000003
【図２】
2004092967.tif 000004
【図３】
2004092967.tif 000005
【図４】
2004092967.tif 000006
【図５】
2004092967.tif 000007
【図６】
2004092967.tif 000008
【図７】
2004092967.tif 000009
【図８】
2004092967.tif 000010
【図９】
2004092967.tif 000011
【図１０】
2004092967.tif 000012
【図１１】
2004092967.tif 000013
【図１２】
2004092967.tif 000014
【図１３】
2004092967.tif 000015
【図１４】
2004092967.tif 000016
【国際調査報告】
2004092967.tif 000017
2004092967.tif 000018
2004092967.tif 000019
2004092967.tif 000020