JP3998443B2 - 対話システム - Google Patents
対話システム Download PDFInfo
- Publication number
- JP3998443B2 JP3998443B2 JP2001244617A JP2001244617A JP3998443B2 JP 3998443 B2 JP3998443 B2 JP 3998443B2 JP 2001244617 A JP2001244617 A JP 2001244617A JP 2001244617 A JP2001244617 A JP 2001244617A JP 3998443 B2 JP3998443 B2 JP 3998443B2
- Authority
- JP
- Japan
- Prior art keywords
- dialog
- dialogue
- frame
- data
- slot
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は対話システム、例えば車載情報機器の１つであるナビゲーション装置やファーストフード店における自動接客装置におけるガイダンス機能部としての対話システムに関する。
【０００２】
【従来の技術】
上記のガイダンスの機能を果すために、対話システムにおいては音声認識処理部、対話エンジン、音声合成部、対話データベース等を備え、システム内での対話データ処理が行われる。
【０００３】
この場合、音声合成部からユーザへ音声ガイダンスとしての問い掛けをし、ユーザがこれに応えて発声すると、音声認識処理部はその発声の意味を分析する。そして対話エンジンはその分析結果に応じて、アプリケーション（例えば既述のナビゲーションや自動接客）に従い、そのユーザの発声に見合う次の音声ガイダンスを生成し、上記音声合成部を通して再び新たな問い掛けをユーザに対して行う。以下、同様の繰り返しによって対話の流れができ上がる。この対話の流れはシステムの内部的なデータ処理にて行われる。
【０００４】
上記の内部的なデータ処理の実行形態にはいろいろあるが、本発明ではいわゆる「フレーム処理」によって実行する形態に立脚した対話システムについて述べる。この「フレーム処理」におけるフレームとは、一連のスロットの並びのことであり、ナビゲーションについて一例を挙げれば、「何県に行きますか」→スロット＜２＞＝「兵庫県」→「兵庫県内の何市に行きますか」→スロット＜４＞＝「神戸市」→「施設種類を教えて下さい」→スロット＜６＞＝「ポートアイランド」といった一連のスロット＜２＞＜４＞＜６＞が１つのフレームであり、このようにスロットを組み上げることをフレーム処理と呼ぶ。
【０００５】
あるいはファーストフード店について一例を挙げれば、「食べ物は何にしますか」→スロット＜２＞＝「ハンバーガー」→スロット＜３＞＝「２つ」→「こちらでお召し上がりですか」→…といった一連のスロット＜２＞＜３＞を組み上げてフレームにすることをフレーム処理と呼ぶ。
【０００６】
このフレーム処理についてみると、従来は次のような処理が含まれている。
【０００７】
１）ある１つの対話のフレームをなす所定の一連のスロットが全て、それぞれ対応する発話データ（上述の「兵庫県」等）で埋まることによって、次の対話へ遷移する。
【０００８】
２）一連のスロットの全てが埋まった後、予め定めた１つの遷移先対話に固定的に遷移する。
【０００９】
３）上記２）の制約を解除するときは、対話遷移データすなわちオートマトンでプログラムを記述しておく。
【００１０】
【発明が解決しようとする課題】
１）上記の１）に起因して、一連のスロットの全てがそれぞれの発話データで埋まらない限り、次の対話へ遷移することができない。つまり、対話設計の自由度がきわめて小さい、という問題がある。
【００１１】
２）上記の２）に起因して、一連のスロットの全てがそれぞれの発話データで埋まったとき、次に遷移できる対話は１つに定められてしまう。つまり、対話設計の柔軟性に欠ける、という問題がある。
【００１２】
３）上記の３）に起因して、オートマトンの記述が混在するため全ての対話をフレーム処理で統一的にデータ処理することができない。つまり、対話設計が複雑化する、という問題がある。
【００１３】
４）さらには、上述のオートマトンの記述が混在することから、上述した内部的なデータ処理に使用する各発話データのデータサイズが大きくなってしまう、という問題がある。
【００１４】
したがって本発明は、上記諸問題点に鑑み、全ての対話をフレーム処理で実現して対話設計の自由度、柔軟性および簡易性を同時に満足することのできる対話システムを提供することを目的とするものである。
【００１５】
【課題を解決するための手段】
図１は本発明が適用される対話システムの一構成例を示す図である。
【００１６】
本図において、対話システム１０は、マイクＭＣを通してユーザから入力されたユーザ発声を分析してその意味を認識辞書１４を参照しながら認識する音声認識処理部１１と、その認識結果をもとにアプリケーション１３（前述のナビゲーションや自動接客）に従って対話データベース（対話ＤＢ）１５を参照しながら対話の流れを生成する対話エンジン１２と、生成された対話を音声として合成しスピーカＳＰよりユーザに提供する音声合成部１６と、対話に係る画面をディスプレイ１８に出力するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）制御部１７とからなる。
【００１７】
これらの構成要素１１〜１８の中で、本発明に特に関係するのは対話エンジン１２および該対話エンジン１２と協働する対話データベース１５である。
【００１８】
図２は本発明の主要部を表す図である。
【００１９】
特に図１における対話エンジン１２および対話データベース１５の部分を取り出して具体的に示す。
【００２０】
図２において特に注目すべき構成要素は対話遷移制御手段２１である。すなわち、対話を構成するフレームをなす一連のスロットを順次埋める対話データの埋まり具合に応じて対話の遷移先を特定する対話遷移制御手段である。
【００２１】
さらに注目すべき構成要素は、フレームデータ領域２２およびフレーム参照テーブル２３である。具体的には、まず、対話を構成するフレームをなす一連のスロットの各々にそれぞれ対応する対話データを、該当のスロットに埋めていくためのフレームデータ領域２２と、このフレームデータ領域２２内に埋められた対話データの埋まり具合によって定まる複数のフレームパターンのそれぞれに対応する対話の遷移先をフレームパターン毎に定義したフレーム参照テーブル２３と、を対話データベース１５内に構築しておく。
【００２２】
そして、フレームデータ領域２２とフレーム参照テーブル２３とを用いて、対話データの埋まり具合に応じた対話の遷移先を特定する対話遷移制御手段２１を、対話エンジン１２内に形成する。
【００２３】
これにより、スロットの埋まり具合に応じて対話の遷移先を変更することができるため、対話設計の自由度を大にし、また、対話設計に柔軟性を持たせることができる。
【００２４】
【発明の実施の形態】
図３は図２のフレームデータ領域２２の詳細例を示す図である。
【００２５】
本図においてフレームデータ領域２２は、分かりやすいように、複数のブロックを多段に積み上げて描いている。
【００２６】
１つの対話をなすフレームは、対話ＩＤと対話状態ＩＤで特定される。
【００２７】
対話ＩＤは、対話システムが今どういう対話をしているかを表示するためのものである。例えば、ユーザから「行き先」を聞き出すための対話とか、ユーザから「食べ物の注文」を聞き出すための対話であることを表すためのＩＤである。
【００２８】
また対話状態ＩＤは、対話システムが今、１つの対話の流れの中で何番目の状態にいるかを表示するためのものである。例えば、ユーザから「行き先」を聞き出すための対話であれば、「何県ですか」（１番目）、「何市ですか」（２番目）…の流れの中のどこ（状態）にいるかを表すためのＩＤである。
【００２９】
上記の対話ＩＤと対話状態ＩＤとの組を、対話エンジン１２からアプリケーション１３に送ると、アプリケーション１３はその組に相当する案内をユーザに提供するように、音声合成部１６を制御する。
【００３０】
図４は対話ＩＤと対話状態ＩＤの一例を示す図である。
【００３１】
本図において、Ｓ−０は上述の対話ＩＤであり、それに付加された数字（１，２…）が上述の対話状態ＩＤである。なお、同図右側のＳはシステム側の発話を表し、Ｕはユーザ側の発話を表す。
【００３２】
図３に戻ると、上記の対話ＩＤおよび対話状態ＩＤが、同図の最上段（第１段)に示されている。その第２段にはスロット数Ｍが記述される。既述したスロット＜１＞、スロット＜２＞、スロット＜３＞…の数である。Ｍ＝６ならば、１フレームが一連の６スロットから構成される。
【００３３】
図３の第３段以降が各スロットに対応し、Ｍ個のスロット１，２…Ｍよりなる。
【００３４】
第３段のスロット値属性１Ａは、ナビゲーションにおける「県名」や自動接客における「食べ物」を問う対話に相当する。そして、それに答える「兵庫県」や「ハンバーガ」が、第３段に示す「値１」となる。
【００３５】
なお、スロット値属性１Ａに付随するスロット値属性１Ｂは常に必要となるデータではないが、スロット値属性１Ａである上記の「県名」が、例えば“目的地設定”なのかあるいは“中継点設定”なのかについてアプリケーション１３がさらに知る必要がある場合に、そのスロット値属性１Ｂに、「兵庫県」が“目的地設定”であることあるいは“中継点設定”であることを表示することができる。
【００３６】
図３の第４段以降も、上記第３段と同種のデータが記述される。
【００３７】
図５は図２のフレーム参照テーブル２３の詳細例を示す図である。
【００３８】
本図において、フレーム参照テーブル２３は、第１段、第２段〜第Ｎ段のコラムからなり、各コラムは各フレームパターン対応になっている。
【００３９】
最上段（第１段）を例にとると、フレームパターン１は、ある対話ＩＤ例えばＳ−０でその対話状態ＩＤは例えば１である（Ｓ−０：１）。つまりフレームデータ領域２２に埋まった対話データはＳ−０：１に相当する。
【００４０】
フレーム参照テーブル２３は、対話の流れがこのようなフレームパターン（Ｓ−０：１）になったならば、“次はどの対話ＩＤ／対話状態ＩＤに進め”ということを指示するものである。この指示の内容が同テーブル２３内の“遷移先対話ＩＤ”／“遷移先対話状態ＩＤ”である。上記のフレームパターン１（＝Ｓ−０：１）の例であると、その“遷移先対話ＩＤ”／“遷移先対話状態ＩＤ”には、例えばＳ−０：２が記述される。
【００４１】
図６は図５のフレームパターンの検索の仕方を図解的に表す図である。
【００４２】
ただし簡素化のために１フレームが３スロットからなる場合について示す。したがって、採り得るフレームパターンの種類は８種である。
【００４３】
前述したフレームデータ領域２２（図３）においてスロット（対話データ）の埋まり具合に応じて、スロット＜１＞のみが埋まっていればフレームパターン１のコラムを参照する。同様に、スロット＜１＞＜２＞のみ、スロット＜１＞＜３＞のみ、スロット＜１＞＜２＞＜３＞の全てが埋まっていれば、それぞれ、フレームパターン２、３および８の各コラムを参照する。そしてそれぞれのコラムに示される遷移先ＩＤ／遷移先状態ＩＤに従って対話を遷移させる。以上が本発明の第１の態様である。
【００４４】
図７は本発明に係る第１の態様の動作を表すフローチャートである。
【００４５】
本図において、
ステップＳ１１：図３に示したフレームデータ領域２２での動作である。
【００４６】
ステップＳ１２：図５および図６において説明したフレーム参照テーブル２３の検索動作である。
【００４７】
図８の（ａ）および（ｂ）は第１の態様に従う対話モデルの簡単な２例を示す遷移図である。
【００４８】
図８（ａ）は、発話内容に応じて（フレームパターンに応じて）引き続き同じ対話ＩＤ内で対話状態が遷移する様子を表し、
図８（ｂ）は、発話内容に応じて、これまでの対話ＩＤとは違う対話ＩＤへ遷移する様子を表す。
【００４９】
図９は本発明に係る第２の態様の動作を表すフローチャートである。
【００５０】
この第２の態様の特徴は、フレームをなす一連のスロットの全てにそれぞれの対話データが埋まり切る前に、進行中の対話の対話ＩＤと異なる対話ＩＤへ遷移する場合、これまで進行してきたフレーム処理を終了することを特徴とするものである。
【００５１】
従来のフレーム処理によれば、フレームをなす一連のスロットの全てにそれぞれの対話データが埋まり切る前には、他の対話ＩＤに遷移することはできない。つまり、該対話データが埋まり切らない限りフレーム処理を終了できない作りになっていた。
【００５２】
ところが本発明では図５に示すフレーム参照テーブル２３に従って、他の対話にフレキシブルに移行可能としたので、そのような対話の移行が発生するときには、全スロットが埋まったか否かに拘わらず、それまでのフレーム処理は終了させてしまう、という構成を採ることにする。
【００５３】
これにより、対話設計の自由度は大になり、また、柔軟な対話設計が可能となる。
【００５４】
ここで図９を参照すると、
ステップＳ２１およびＳ２２は、それぞれ、図７に示したステップＳ１１およびＳ１２と同じである。
【００５５】
第２の態様の特徴の１つは、ステップＳ２３を介在させ、１つの対話から他の対話へ（例えば、Ｓ−０→Ｓ−１）遷移するか否かを判断することである。
【００５６】
対話ＩＤが変化しなければ（同一の対話が進行中）、そのままフレーム処理を継続する。つまり、ステップＳ２３の判断結果がＹｅｓならば、ステップＳ２４に進む。このことは従来と余り変わらないが、第２の態様のさらなる特徴は、フレーム参照テーブル２３に従って１つの対話ＩＤが他の対話ＩＤに遷移するときは（ステップＳ２３の判断結果がＮｏ）、現在進行しているフレーム処理を終了してしまうことである（ステップＳ２６およびＳ２７の各々の前半参照）。
【００５７】
ステップＳ２６およびＳ２７の各々の後半の処理は、フレーム参照テーブル２３（図５）を参照したときに、対応のテーブル部分に“対話終了コード”が記入されているか否か（ステップＳ２５）によって変わってくる。
【００５８】
つまり、ステップＳ２５の判断結果がＹｅｓの場合（対話終了コードあり）、対話を終了させてしまう。一方そのステップＳ２５の判断結果がＮｏの場合（対話終了コードなし）、対話は遷移先の対話へ移動して続行される。
【００５９】
図１０は第２の態様に従う対話モデルの一例を示す遷移図である。
【００６０】
スロットとしては、「肯定」「否定」「県名」の対話データに関係する３個のスロットが用意されているものとして、以下の３つのケースについて説明する。
【００６１】
ケース１）
図１０の対話状態０の状態で、ユーザが“県名”に関係する「兵庫県」を発声したとすると、スロットの１つである「県名」に関係するスロットが埋まる。そして対話状態３へ移動する。
【００６２】
この対話状態３で、フレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００６３】
この場合、「肯定」「否定」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００６４】
ケース２）
図１０の対話状態０の状態で、ユーザが“否定”に関係する「いいえ」を発声したとすると、スロットの１つである「否定」に関係するスロットが埋まる。そして対話状態２へ移動する。
【００６５】
この対話状態２でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００６６】
この場合、「肯定」「県名」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００６７】
ケース３）
図１０の対話状態０の状態で、ユーザが“肯定”に関係する「はい」を発声したとすると、スロットの１つである「肯定」に関係するスロットが埋まる。この状態でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤ：同じＩＤ、遷移先対話状態ＩＤ：１に遷移する。
【００６８】
この場合アプリケーションが遷移した対話ＩＤおよび対話状態ＩＤデータを元にユーザへ案内を出した後、遷移先対話状態：５の状態になる。
【００６９】
この対話状態５の状態で、ユーザが“県名”に関係する「兵庫県」を発声したとすると、スロットの１つである「県名」に関係するスロットが埋まる。そして対話状態３へ移動する。
【００７０】
この対話状態３でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００７１】
この場合、「否定」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００７２】
図１１は本発明に係る第３の態様を表す図である。
【００７３】
本図に示すとおり、第３の態様に基づくフレーム参照テーブル２３は、遷移先ＩＤ領域２５（図５と同じ）と拡張領域２６とからなる。
【００７４】
すなわち第３の態様は、フレーム参照テーブル２３における各フレームパターンは、各該フレームパターン毎に定義される遷移先対話ＩＤおよび遷移先対話状態ＩＤからなる遷移先ＩＤ領域２５に加えて、各該フレームパターン毎に定義される特定のイベントへの遷移先を記述する拡張領域２６を有することを特徴とするものである。なお、図１１では、拡張領域２６を拡張領域ＩおよびIIの対として示す。
【００７５】
ここで上記の特定のイベントを、第１例および第２例をもって説明する。
【００７６】
第１例によれば、そのイベントはアシスト対話である。アシスト対話とは、システム側からの問い掛けに対し所定の時間（例えば５秒）が経過してもユーザから何の応答もなかったり、あるいは、ユーザからの応答が「助け」を求めるようなものであったような場合に、システム側からもっと回答しやすい形で問い掛け直すときの対話をいう。
【００７７】
そこで拡張領域Ｉには、上記のアシスト対話の対話ＩＤを記述し、拡張領域IIには、該アシスト対話の対話状態ＩＤを記述できるようにする。なお、これら対話ＩＤおよび対話状態ＩＤは、対話の進行具合すなわちフレームパターンの種類に応じて異なる。
【００７８】
また第２例によればそのイベントは、例えばアプリケーションへ移行するためのイベント、例えばタイマーを起動させるための制御コードである。
【００７９】
かくして、第３の態様によれば対話設計の自由度および柔軟性を向上させることができる。
【００８０】
図１２は本発明に係る第４の態様の動作を表すフローチャート（その１）、
図１３は同フローチャート（その２）である。
【００８１】
この第４の態様の特徴は、第１の対話についてフレーム処理をしている途中で第２の対話に遷移するとき、その第１の対話においてスロットに埋めた対話データをそのまま保持し、かつ、上記の第２の対話でのフレーム処理にてスロットに埋めるべき対話データのうち、その保持している対話データと重複するものについては、当該保持データを流用することを特徴とするものである。
【００８２】
図１２を参照すると、
ステップＳ３１およびＳ３２はそれぞれ、図９に示したステップＳ２１およびＳ２２と同じである。
【００８３】
図１３を参照すると、
ステップＳ３３、Ｓ３４、Ｓ３５およびＳ３６はそれぞれ、図９に示したステップＳ２３、Ｓ２４、Ｓ２５およびＳ２７と同じである。
【００８４】
したがってこの第４の態様の特徴は、図１３のステップＳ３７およびＳ３８で表される。
【００８５】
第１の対話についてフレーム処理をしている途中で第２の対話に遷移するとき、そして対話が終了せず継続するとき、すなわち、図１２におけるステップＳ３３の判断結果がＮｏでさらに、図１３におけるステップＳ３５の判断結果もＮｏのときである。
【００８６】
このときに、第１の対話におけるフレーム処理においてスロットに埋めた対話データをそのまま保持する（図１３のステップＳ３７）。
【００８７】
さらに、遷移先の上記第２の対話でのフレーム処理にてスロットに埋めるべき対話のうち、その保持した対話データと重複するものについては、その保持対話データを流用する。すなわち遷移先で使用するフレームデータをフレームデータ領域２２から読み込む（図１３のステップＳ３８）。
【００８８】
このように第４の態様では、共通する対話データの使いまわしをし、これにより対話データベース１５におけるメモリ量を削減することが可能となる。
【００８９】
図１４は本発明に係る第４の態様の特例についての動作を表すフローチャート（その１）、
図１５は同フローチャート（その２）である。
【００９０】
この第４の態様の特例は、前述した第４の態様における「第２の対話」が既述（図１１）のアシスト対話である場合を規定したものである。したがって第４の態様における「第１の対話」はメイン対話である。
【００９１】
すなわちこの第４の態様の特例は、メイン対話についてフレーム処理をしている途中で、音声認識処理部１１（図１）が、ユーザに対するアシストが必要であるものと判定し、これによりアシスト対話に遷移するとき、そのメイン対話においてスロットに埋めた対話データをそのまま保持し、かつ、そのアシスト対話でのフレーム処理にてスロットに埋めるべき対話データのうち、上記の保持している対話データと重複するものについては、当該保持データを流用することを特徴とするものである。
【００９２】
図１４および図１５を参照すると、図１４に示すステップＳ２２と図１５に示すステップＳ２３〜Ｓ２７は、それぞれ、図９に示したステップＳ２２およびＳ２３〜Ｓ２７と同じである。
【００９３】
したがって第４の態様の特例において注目すべきステップは、図１４に示すステップＳ４１、Ｓ４２、Ｓ４３およびＳ４４である。ただし、このステップＳ４３およびＳ４４は、それぞれ、図１３に示した第４の態様におけるステップＳ３７およびＳ３８と同じである。
【００９４】
このため、ステップＳ４１およびＳ４２が特に注目すべきステップとなる。
【００９５】
ユーザがシステム側からの問い掛けに応答せず所定の時間（例えば５秒）が経過すると（タイムアウト）、上記ステップＳ４１の判断結果はＹｅｓとなり、アシスト対話への遷移が開始して、上記第４の態様の特徴をなすステップＳ４３に至り、さらにはステップＳ４４に至る。
【００９６】
上記のタイムアウトにはならないが、ユーザからの応答が「助け」を求めるものであって、アシスト対話へ遷移することとなる場合も、上記第４の態様の特徴をなすステップ４３に至り、さらにはステップＳ４４に至る。
【００９７】
これにより、第４の態様で得られる効果（対話データの使いまわしにより、対話データベース１５のメモリ量を削減する）と同様の効果が、アシスト対話への遷移時において得ることができる。
【００９８】
図１６は第４の態様の特例における対話モデル例Ｉを示す遷移図であり、
図１７は第４の態様の特例における対話モデル例IIを示す遷移図であり、
図１８は第４の態様の特例における対話モデル例III を示す遷移図である。
【００９９】
図１６では、上記アシスト対話において、上記メイン対話で必要な、図３で説明したスロット値属性Ａ、同じく図３で説明したスロット値属性Ｂを取得する場合を表している。
【０１００】
図１６の左側はメイン対話の遷移系列であり、その右側はアシスト対話の遷移系列である。
【０１０１】
アシスト対話の遷移系列で取得されたフレームデータ（スロット値属性Ａ、スロット値属性Ｂ）を、メイン対話のフレーム処理におけるフレームデータとして利用するものである。
【０１０２】
図１７および図１８の見方は上記の図１６の見方と同様である。
【０１０３】
図１９は本発明に係る第５の態様の動作を表すフローチャート（その１）であり、
図２０は同フローチャート（その２）である。
【０１０４】
この第５の態様の特徴は、前述した図１２〜図１８の態様において、フレームをなす複数のスロットのうち、対話データで埋められたスロットのみについて、その埋められた対話データを保持することを特徴とするものである。
【０１０５】
これにより、図１２〜図１８の態様により得られる、対話データの使いまわしにより、対話データベース１５のメモリ量を削減する、という効果がより一層顕著なものとなる。
【０１０６】
図１９および図２０を参照すると、まず図１９において、ステップＳ３１、Ｓ３２、Ｓ３３およびＳ３５は、前述した図１２および図１３で示した同一番号のステップと同様である。
【０１０７】
次に図２０において、ステップＳ３４およびＳ３６は、前述した図１３で示した同一番号のステップと同様である。したがってステップＳ５１およびＳ５２が第５の態様において注目すべきステップである。ただしステップＳ５２については図９に示したステップＳ２７と同様である。
【０１０８】
このステップＳ５１では、フレームをなす複数のスロットのうち、対話データで埋められたスロットのみについて、その埋められた対話データを、対話データベース１５内に保持しておく。
【０１０９】
なお本第５の態様以前の各態様のもとでは、図３に示すフレームデータ構造のフレームを構成する全てのスロットを、そのスロットが空であると否とを問わず、保持するようにしている。
【０１１０】
しかし第５の態様では、上記ステップＳ５１に示すごとく、スロット値（値１、値２等）の結果と属性のみを保持することとする。例えば、スロットを埋めている「兵庫県」と「目的地設定」をそれぞれ示すデータのみを保持するようにする。
【０１１１】
これにより前述のように、メモリ量は一層削減可能となる。
【０１１２】
図２１は本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）であり、
図２２は同フローチャート（その２）である。
【０１１３】
まず第６の態様について説明すると、この第６の態様は、遷移先の第２の対話またはアシスト対話でのフレーム処理においてスロットに埋めるべき対話データと、前述の保持している対話データとが一致するか否か判断し、一致すると判断したときは、その保持している対話データを用いて当該スロットを埋めることを特徴とするものである。「保持している対話データ」とは、図１３のステップＳ３７や図１４のステップＳ４３で保持するデータのことである。
【０１１４】
図２１および図２２を参照するとこの第６の態様は、ステップＳ６１→Ｓ６２→Ｓ６３→Ｓ６４で表される。
【０１１５】
上述の図１３と図１４では、それぞれ、ステップＳ３８とＳ４４で終了するように表しているが、ここで説明する第６（および第７、第８）の態様は、これらステップＳ３８やＳ４４以降についての態様である。つまり図２１のステップＳ６１から処理が開始する。
【０１１６】
ステップＳ６２では、遷移先のフレーム処理でスロットに埋めるべき対話データ、例えばスロット値属性１Ａ，１Ｂ，２Ａ，２Ｂ…（図３参照）と、上記の保持している対話データ（この例ではスロット値属性１Ａ，１Ｂ，２Ａ，２Ｂ…）とが一致するか否か判断する。
【０１１７】
一致していれば、ステップＳ６３にて、その一致したスロットの内容で、遷移先でのフレームにおける該当スロットを埋める。
【０１１８】
このようにしてスロットが埋まったフレームのフレームパターンをもってフレーム参照テーブル２３（図５）を参照し、次の遷移先の対話ＩＤ／対話状態ＩＤを検索して、対話をさらに先に進めていく。これが図２２のステップＳ６４である。
【０１１９】
これにより第６の態様においても、対話データの使いまわしによるメモリ量の削減効果が得られる。
【０１２０】
続いて、図２１および図２２を参照して、第７の態様を説明する。
【０１２１】
第７の態様は、既述した遷移先の第２の対話またはアシスト対話でのフレーム処理においてスロットに埋めるべき対話データと、上述の保持している対話データとが一致するか否か判断し、一致しないと判断したとき、かつ、当該遷移先の現状のフレーム処理がフレーム処理開始から既に進んでいると判断したときは、そこから元に戻って対話データの逆検索を実行することを特徴とするものである。
【０１２２】
図２１を参照すると、前記ステップＳ６２の判断結果がＮｏすなわち不一致であると、まずステップＳ６３′において現状の対話ＩＤ／対話状態ＩＤがどうなっているか判断する。この判断をもとに図２２のステップＳ６５に移る。
【０１２３】
このステップＳ６５では、当該遷移先の現状のフレーム処理がフレーム処理を開始する状態にあるか否か判断する。
【０１２４】
第７の態様は、このステップＳ６５とこれに続くステップＳ６７に特徴がある。好ましくはステップＳ６６を取り入れる。ステップＳ６５の判断結果がＹｅｓ、すなわち現状のフレーム処理がフレーム処理の開始であれば、該ステップＳ６６に移り、前述した保持している対話データをクリアしてしまう。改めてフレーム処理を開始するので、保持していた対話データは不要となるからである。
【０１２５】
一方、上記ステップＳ６５の判断結果がＮｏ、すなわち現状のフレーム処理はフレーム処理開始から既に進んでいるときは、既にスロット群に所要の対話データが埋まっているから、そこから元に戻ってフレームデータの逆検索を行う。ここまでが第７の態様である。
【０１２６】
次に第８の態様が開始する。この第８の態様は、上記の逆検索を実行し（ステップＳ６７）、そこで得た対話データを用いて、既述の第１の対話またはメイン対話でのフレーム処理におけるスロットを埋める（ステップＳ６８）ことを特徴とするものである。
【０１２７】
図２２を参照すると、この第８の態様はステップＳ６８→Ｓ６９→Ｓ６４（前出）により表される。
【０１２８】
かくして得たフレームパターンについてフレーム参照テーブル２３により遷移先の対話ＩＤ／対話状態ＩＤを検索し、第１の態様等と同様にさらに対話を進める。
【０１２９】
これにより、第７および第８の態様もまた、メモリ量の削減という効果をもたらす。
【０１３０】
図２３は本発明に係る第９の態様の動作を示すフローチャートである。
【０１３１】
この第９の態様は、遷移先の対話の種類が遷移前の対話の種類と同一のときは、この遷移前の対話でのフレーム処理で生成したフレーム内の対話データを全てクリアしてから、再度この遷移前の対話でのフレーム処理を実行することを特徴とするものである。
【０１３２】
図２３において、ステップＳ７１では、遷移先の対話が遷移前の対話と同一か否か判断する。
【０１３３】
同一ならば（Ｙｅｓ）、ステップＳ７２に移って、その遷移前のフレーム処理で埋めたスロットの内容を全てクリアする。
【０１３４】
その後、再度、その遷移前のフレーム処理を初めから行う。
【０１３５】
もし上記遷移前におけるフレームのスロットのデータを残したままにしておくと、この埋まったままのフレームで特定されるフレームパターン（図５のフレームパターン１，２…）を別途用意しなければならなくなるからである。
【０１３６】
したがって第９の態様によれば、同一形式のデータを繰り返し持つ必要がなくなり、メモリ量の削減という効果がもたらされる。
【０１３７】
図２４は第９の態様が利用される対話モデルの一例を示す図である。
【０１３８】
これはナビゲーションにおけるある対話Ｓ−５を取り出したものである。
【０１３９】
Ｓ−５：５に対するユーザの返事が「はい」であるので、また、同じ対話Ｓ−５に戻る。この戻ったときに、Ｓ−５：２とＳ−５：４の「いいえ」とＳ−５：６「はい」を共にクリアする。
【０１４０】
図２５は本発明に係る第１０の態様の動作を表すフローチャートである。
【０１４１】
この第１０の態様は、フレーム参照テーブル２３によって特定された対話の遷移先の指示内容が、当該対話システム１０が連係するアプリケーション１３に応じて分岐すべきことを表しているとき、直前まで進行していた対話処理を一旦終了して、このアプリケーション１３から対話開始の命令と共に指示される遷移先にて対話処理を継続することを特徴とするものである。
【０１４２】
図２５を参照すると、ステップＳ８１では、上記の対話の遷移先の指示内容が特定の制御コード、すなわちアプリケーション（アプリとも称す）によって遷移先を決めるべきことを表すコードであると（Ｙｅｓ）、ステップＳ８３へ移る。この制御コードは、拡張領域２６（図１１）に記述しておくことができる。
【０１４３】
なお特定の制御コードでなければ（Ｎｏ）、ステップＳ８２に移り、前述した通常処理を行う。
【０１４４】
特定の制御コードが記述されているときはステップＳ８３に移り、一旦対話処理を終了する。このときは“対話終了”のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）が呼び出される。
【０１４５】
そしてステップＳ８４にて、アプリケーションから対話開始の命令が出されるのを待つ。
【０１４６】
この対話開始命令が出ると、ステップＳ８５にて、この命令と共に送られる対話ＩＤ／対話状態ＩＤ（遷移先の指定データ）で定まる対話から対話処理を開始する。
【０１４７】
このように、第１０の態様によれば、様々な対話状態を指示するアプリケーションが自ら指示を出すので、対話データベース１５に格納すべきデータのデータ量を大幅に減少させることができる。
【０１４８】
図２６は第１０の態様が適用される対話モデルの一例を示す図である。
【０１４９】
本図は、アプリケーションの指示に従って遷移先が分岐する様子を示している。
【０１５０】
図２７は本発明に係る第１１の態様の動作を表すフローチャートである。
【０１５１】
この第１１の態様は、一連のスロット（図３のフレームデータ領域２２）の一部を、当該対話システムが連係するアプリケーション１３への要求に基づいて該アプリケーション１３から提供される対話データによって埋めることを特徴とするものである。
【０１５２】
従来のナビゲーション装置においては、対話データの入力を、音声ではなく、操作パネルの操作スイッチ（図１の右上のＳＷ参照）で行うときは、一連の操作が終了するまで全てその操作スイッチによらなければ対話を行うことができなかった。
【０１５３】
ところがこの第１１の態様によれば、アプリケーションに従ってスイッチ操作で得られた対話データ、例えばＵ：「兵庫県」やＵ：「神戸市」が存在していれば、これをアプリケーション１３側に要求し該アプリケーション１３から受け取るようにする。
【０１５４】
これにより、スイッチ操作で得た対話データも対話遷移制御手段２１にて管理することができ、対話設計の柔軟性が高まる。
【０１５５】
図２７を参照すると、ステップＳ９１で、アプリケーション１３から“対話開始”の命令が出されると、
ステップＳ９２で、その命令と共に出力される遷移先の指定データを分析し、操作の途中から対話を開始するのか否か判断する。
【０１５６】
ステップＳ９３では、ステップＳ９２の判断結果がＮｏであると、現在の対話状態に至るまでにまだ埋まっていないスロットを埋めるのに必要な値を、アプリケーション１３に対して要求し、
ステップＳ９４で、上記の必要な値を該当スロットに埋める。
【０１５７】
ステップＳ９５では、入手済みの値で埋め切ったフレームデータのフレームパターンがフレーム参照テーブル２３に存在するか否か判断し、存在すれば
ステップＳ９６にて、対話を続行する。
【０１５８】
図２８は本発明に係る第１２の態様の動作を表すフローチャートである。
【０１５９】
この第１２の態様は、ある対話状態Ｓを経て音声合成部１６が起動されてユーザに案内を行っている途中で、当該対話システム１０が連係するアプリケーション１３に割り込みが生じた場合、対話遷移制御手段２１は、該アプリケーション１３によりその対話状態Ｓに戻れという命令を受けて遷移先をその対話状態Ｓに特定することを特徴とするものである。
【０１６０】
この場合、その対話状態Ｓで蓄積したフレームデータはクリアしておくのが好ましい。
【０１６１】
このように状態遷移の制御の一部を、アプリケーション１３側に移すことにより、対話エンジン（対話遷移制御手段２１）の負荷を軽くすることができる、という効果がもたらされる。すなわち、戻れというフレームデータ（スロット）を用意する必要がない。
【０１６２】
図２８を参照すると、
ステップＳ１０１で、対話エンジン１２は、アプリケーション１３に割り込みが発生したか判断する。一例を挙げると、音声認識処理部１１において誤認識が行われたことが判明したような場合に、その割り込みが発生する。そうすると、ステップＳ１０２において、前の対話に戻れという命令が出されているか判断する。出されていれば、
ステップＳ１０３において、対話遷移制御手段２１は、上記の誤認識に至った対話をなすフレームに戻り、フレームを再構築する。
【０１６３】
図２９は本発明に係る第１３の態様を表す図である。
【０１６４】
この第１３の態様は、図２の構成にグローバル発話専用フレームメモリ３１を付加した構成を有する。
【０１６５】
以上述べてきたいろいろな対話の中で、いずれの対話においても必ず共通する発話が存在する。これがグローバル発話である。いくつかの例を挙げてみると、“戻る”、“認識エラー”、“中止”、“一旦停止”、“誤認識”、“ヘルプ”等々に起因してユーザから入力される発話である。
【０１６６】
このような発話も含めて、フレームデータ領域２２およびフレーム参照テーブル２３を形成すると、そのデータサイズは大となってしまう。したがってメモリ量が増大してしまう。また既述したメンテナンスも難しくなる。
【０１６７】
そこで第１３の態様は、上記のグローバル発話のみを専用に記憶するグローバル発話メモリ３１を設けることを特徴とするものである。
【０１６８】
かくして、メモリ量の削減とメンテナンスの向上を可能とする、という効果を得ることができる。
【０１６９】
【発明の効果】
以上説明したように本発明によれば、全ての対話をフレーム処理で実現可能とし、これにより対話設計の自由度、柔軟性ならびに簡易性を向上させた対話システムを実現することができる。
【図面の簡単な説明】
【図１】本発明が適用される対話システムの一構成例を示す図である。
【図２】本発明の主要部を表す図である。
【図３】図２のフレームデータ領域２２の詳細例を示す図である。
【図４】対話ＩＤと対話状態ＩＤの一例を示す図である。
【図５】図２のフレーム参照テーブル２３の詳細例を示す図である。
【図６】図５のフレームパターンの検索の仕方を図解的に表す図である。
【図７】本発明に係る第１の態様の動作を表すフローチャートである。
【図８】（ａ）および（ｂ）は第１の態様に従う対話モデルの簡単な２例を示す遷移図である。
【図９】本発明に係る第２の態様の動作を表すフローチャートである。
【図１０】第２の態様に従う対話モデルの一例を示す遷移図である。
【図１１】本発明に係る第３の態様の動作を表す図である。
【図１２】本発明に係る第４の態様の動作を表すフローチャート（その１）である。
【図１３】本発明に係る第４の態様の動作を表すフローチャート（その２）である。
【図１４】本発明に係る第４の態様の特例についての動作を表すフローチャート（その１）である。
【図１５】本発明に係る第４の態様の特例についての動作を表すフローチャート（その２）である。
【図１６】第４の態様の特例における対話モデル例Ｉを示す遷移図である。
【図１７】第４の態様の特例における対話モデル例IIを示す遷移図である。
【図１８】第４の態様の特例における対話モデル例III を示す遷移図である。
【図１９】本発明に係る第５の態様の動作を表すフローチャート（その１）である。
【図２０】本発明に係る第５の態様の動作を表すフローチャート（その２）である。
【図２１】本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）である。
【図２２】本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）である。
【図２３】本発明に係る第９の態様の動作を表すフローチャートである。
【図２４】第９の態様が利用される対話モデルの一例を示す図である。
【図２５】本発明に係る第１０の態様の動作を表すフローチャートである。
【図２６】第１０の態様が利用される対話モデルの一例を示す図である。
【図２７】本発明に係る第１１の態様の動作を表すフローチャートである。
【図２８】本発明に係る第１２の態様の動作を表すフローチャートである。
【図２９】本発明に係る第１３の態様の動作を表す図である。
【符号の説明】
１０…対話システム
１１…音声認識処理部
１２…対話エンジン
１３…アプリケーション
１４…認識辞書
１５…対話データベース
１６…音声合成部
１７…ＧＵＩ制御部
１８…ディスプレイ
２１…対話遷移制御手段
２２…フレームデータ領域
２３…フレーム参照テーブル
２５…遷移先ＩＤ領域
２６…拡張領域
３１…グローバル発話専用メモリ
【発明の属する技術分野】
本発明は対話システム、例えば車載情報機器の１つであるナビゲーション装置やファーストフード店における自動接客装置におけるガイダンス機能部としての対話システムに関する。
【０００２】
【従来の技術】
上記のガイダンスの機能を果すために、対話システムにおいては音声認識処理部、対話エンジン、音声合成部、対話データベース等を備え、システム内での対話データ処理が行われる。
【０００３】
この場合、音声合成部からユーザへ音声ガイダンスとしての問い掛けをし、ユーザがこれに応えて発声すると、音声認識処理部はその発声の意味を分析する。そして対話エンジンはその分析結果に応じて、アプリケーション（例えば既述のナビゲーションや自動接客）に従い、そのユーザの発声に見合う次の音声ガイダンスを生成し、上記音声合成部を通して再び新たな問い掛けをユーザに対して行う。以下、同様の繰り返しによって対話の流れができ上がる。この対話の流れはシステムの内部的なデータ処理にて行われる。
【０００４】
上記の内部的なデータ処理の実行形態にはいろいろあるが、本発明ではいわゆる「フレーム処理」によって実行する形態に立脚した対話システムについて述べる。この「フレーム処理」におけるフレームとは、一連のスロットの並びのことであり、ナビゲーションについて一例を挙げれば、「何県に行きますか」→スロット＜２＞＝「兵庫県」→「兵庫県内の何市に行きますか」→スロット＜４＞＝「神戸市」→「施設種類を教えて下さい」→スロット＜６＞＝「ポートアイランド」といった一連のスロット＜２＞＜４＞＜６＞が１つのフレームであり、このようにスロットを組み上げることをフレーム処理と呼ぶ。
【０００５】
あるいはファーストフード店について一例を挙げれば、「食べ物は何にしますか」→スロット＜２＞＝「ハンバーガー」→スロット＜３＞＝「２つ」→「こちらでお召し上がりですか」→…といった一連のスロット＜２＞＜３＞を組み上げてフレームにすることをフレーム処理と呼ぶ。
【０００６】
このフレーム処理についてみると、従来は次のような処理が含まれている。
【０００７】
１）ある１つの対話のフレームをなす所定の一連のスロットが全て、それぞれ対応する発話データ（上述の「兵庫県」等）で埋まることによって、次の対話へ遷移する。
【０００８】
２）一連のスロットの全てが埋まった後、予め定めた１つの遷移先対話に固定的に遷移する。
【０００９】
３）上記２）の制約を解除するときは、対話遷移データすなわちオートマトンでプログラムを記述しておく。
【００１０】
【発明が解決しようとする課題】
１）上記の１）に起因して、一連のスロットの全てがそれぞれの発話データで埋まらない限り、次の対話へ遷移することができない。つまり、対話設計の自由度がきわめて小さい、という問題がある。
【００１１】
２）上記の２）に起因して、一連のスロットの全てがそれぞれの発話データで埋まったとき、次に遷移できる対話は１つに定められてしまう。つまり、対話設計の柔軟性に欠ける、という問題がある。
【００１２】
３）上記の３）に起因して、オートマトンの記述が混在するため全ての対話をフレーム処理で統一的にデータ処理することができない。つまり、対話設計が複雑化する、という問題がある。
【００１３】
４）さらには、上述のオートマトンの記述が混在することから、上述した内部的なデータ処理に使用する各発話データのデータサイズが大きくなってしまう、という問題がある。
【００１４】
したがって本発明は、上記諸問題点に鑑み、全ての対話をフレーム処理で実現して対話設計の自由度、柔軟性および簡易性を同時に満足することのできる対話システムを提供することを目的とするものである。
【００１５】
【課題を解決するための手段】
図１は本発明が適用される対話システムの一構成例を示す図である。
【００１６】
本図において、対話システム１０は、マイクＭＣを通してユーザから入力されたユーザ発声を分析してその意味を認識辞書１４を参照しながら認識する音声認識処理部１１と、その認識結果をもとにアプリケーション１３（前述のナビゲーションや自動接客）に従って対話データベース（対話ＤＢ）１５を参照しながら対話の流れを生成する対話エンジン１２と、生成された対話を音声として合成しスピーカＳＰよりユーザに提供する音声合成部１６と、対話に係る画面をディスプレイ１８に出力するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）制御部１７とからなる。
【００１７】
これらの構成要素１１〜１８の中で、本発明に特に関係するのは対話エンジン１２および該対話エンジン１２と協働する対話データベース１５である。
【００１８】
図２は本発明の主要部を表す図である。
【００１９】
特に図１における対話エンジン１２および対話データベース１５の部分を取り出して具体的に示す。
【００２０】
図２において特に注目すべき構成要素は対話遷移制御手段２１である。すなわち、対話を構成するフレームをなす一連のスロットを順次埋める対話データの埋まり具合に応じて対話の遷移先を特定する対話遷移制御手段である。
【００２１】
さらに注目すべき構成要素は、フレームデータ領域２２およびフレーム参照テーブル２３である。具体的には、まず、対話を構成するフレームをなす一連のスロットの各々にそれぞれ対応する対話データを、該当のスロットに埋めていくためのフレームデータ領域２２と、このフレームデータ領域２２内に埋められた対話データの埋まり具合によって定まる複数のフレームパターンのそれぞれに対応する対話の遷移先をフレームパターン毎に定義したフレーム参照テーブル２３と、を対話データベース１５内に構築しておく。
【００２２】
そして、フレームデータ領域２２とフレーム参照テーブル２３とを用いて、対話データの埋まり具合に応じた対話の遷移先を特定する対話遷移制御手段２１を、対話エンジン１２内に形成する。
【００２３】
これにより、スロットの埋まり具合に応じて対話の遷移先を変更することができるため、対話設計の自由度を大にし、また、対話設計に柔軟性を持たせることができる。
【００２４】
【発明の実施の形態】
図３は図２のフレームデータ領域２２の詳細例を示す図である。
【００２５】
本図においてフレームデータ領域２２は、分かりやすいように、複数のブロックを多段に積み上げて描いている。
【００２６】
１つの対話をなすフレームは、対話ＩＤと対話状態ＩＤで特定される。
【００２７】
対話ＩＤは、対話システムが今どういう対話をしているかを表示するためのものである。例えば、ユーザから「行き先」を聞き出すための対話とか、ユーザから「食べ物の注文」を聞き出すための対話であることを表すためのＩＤである。
【００２８】
また対話状態ＩＤは、対話システムが今、１つの対話の流れの中で何番目の状態にいるかを表示するためのものである。例えば、ユーザから「行き先」を聞き出すための対話であれば、「何県ですか」（１番目）、「何市ですか」（２番目）…の流れの中のどこ（状態）にいるかを表すためのＩＤである。
【００２９】
上記の対話ＩＤと対話状態ＩＤとの組を、対話エンジン１２からアプリケーション１３に送ると、アプリケーション１３はその組に相当する案内をユーザに提供するように、音声合成部１６を制御する。
【００３０】
図４は対話ＩＤと対話状態ＩＤの一例を示す図である。
【００３１】
本図において、Ｓ−０は上述の対話ＩＤであり、それに付加された数字（１，２…）が上述の対話状態ＩＤである。なお、同図右側のＳはシステム側の発話を表し、Ｕはユーザ側の発話を表す。
【００３２】
図３に戻ると、上記の対話ＩＤおよび対話状態ＩＤが、同図の最上段（第１段)に示されている。その第２段にはスロット数Ｍが記述される。既述したスロット＜１＞、スロット＜２＞、スロット＜３＞…の数である。Ｍ＝６ならば、１フレームが一連の６スロットから構成される。
【００３３】
図３の第３段以降が各スロットに対応し、Ｍ個のスロット１，２…Ｍよりなる。
【００３４】
第３段のスロット値属性１Ａは、ナビゲーションにおける「県名」や自動接客における「食べ物」を問う対話に相当する。そして、それに答える「兵庫県」や「ハンバーガ」が、第３段に示す「値１」となる。
【００３５】
なお、スロット値属性１Ａに付随するスロット値属性１Ｂは常に必要となるデータではないが、スロット値属性１Ａである上記の「県名」が、例えば“目的地設定”なのかあるいは“中継点設定”なのかについてアプリケーション１３がさらに知る必要がある場合に、そのスロット値属性１Ｂに、「兵庫県」が“目的地設定”であることあるいは“中継点設定”であることを表示することができる。
【００３６】
図３の第４段以降も、上記第３段と同種のデータが記述される。
【００３７】
図５は図２のフレーム参照テーブル２３の詳細例を示す図である。
【００３８】
本図において、フレーム参照テーブル２３は、第１段、第２段〜第Ｎ段のコラムからなり、各コラムは各フレームパターン対応になっている。
【００３９】
最上段（第１段）を例にとると、フレームパターン１は、ある対話ＩＤ例えばＳ−０でその対話状態ＩＤは例えば１である（Ｓ−０：１）。つまりフレームデータ領域２２に埋まった対話データはＳ−０：１に相当する。
【００４０】
フレーム参照テーブル２３は、対話の流れがこのようなフレームパターン（Ｓ−０：１）になったならば、“次はどの対話ＩＤ／対話状態ＩＤに進め”ということを指示するものである。この指示の内容が同テーブル２３内の“遷移先対話ＩＤ”／“遷移先対話状態ＩＤ”である。上記のフレームパターン１（＝Ｓ−０：１）の例であると、その“遷移先対話ＩＤ”／“遷移先対話状態ＩＤ”には、例えばＳ−０：２が記述される。
【００４１】
図６は図５のフレームパターンの検索の仕方を図解的に表す図である。
【００４２】
ただし簡素化のために１フレームが３スロットからなる場合について示す。したがって、採り得るフレームパターンの種類は８種である。
【００４３】
前述したフレームデータ領域２２（図３）においてスロット（対話データ）の埋まり具合に応じて、スロット＜１＞のみが埋まっていればフレームパターン１のコラムを参照する。同様に、スロット＜１＞＜２＞のみ、スロット＜１＞＜３＞のみ、スロット＜１＞＜２＞＜３＞の全てが埋まっていれば、それぞれ、フレームパターン２、３および８の各コラムを参照する。そしてそれぞれのコラムに示される遷移先ＩＤ／遷移先状態ＩＤに従って対話を遷移させる。以上が本発明の第１の態様である。
【００４４】
図７は本発明に係る第１の態様の動作を表すフローチャートである。
【００４５】
本図において、
ステップＳ１１：図３に示したフレームデータ領域２２での動作である。
【００４６】
ステップＳ１２：図５および図６において説明したフレーム参照テーブル２３の検索動作である。
【００４７】
図８の（ａ）および（ｂ）は第１の態様に従う対話モデルの簡単な２例を示す遷移図である。
【００４８】
図８（ａ）は、発話内容に応じて（フレームパターンに応じて）引き続き同じ対話ＩＤ内で対話状態が遷移する様子を表し、
図８（ｂ）は、発話内容に応じて、これまでの対話ＩＤとは違う対話ＩＤへ遷移する様子を表す。
【００４９】
図９は本発明に係る第２の態様の動作を表すフローチャートである。
【００５０】
この第２の態様の特徴は、フレームをなす一連のスロットの全てにそれぞれの対話データが埋まり切る前に、進行中の対話の対話ＩＤと異なる対話ＩＤへ遷移する場合、これまで進行してきたフレーム処理を終了することを特徴とするものである。
【００５１】
従来のフレーム処理によれば、フレームをなす一連のスロットの全てにそれぞれの対話データが埋まり切る前には、他の対話ＩＤに遷移することはできない。つまり、該対話データが埋まり切らない限りフレーム処理を終了できない作りになっていた。
【００５２】
ところが本発明では図５に示すフレーム参照テーブル２３に従って、他の対話にフレキシブルに移行可能としたので、そのような対話の移行が発生するときには、全スロットが埋まったか否かに拘わらず、それまでのフレーム処理は終了させてしまう、という構成を採ることにする。
【００５３】
これにより、対話設計の自由度は大になり、また、柔軟な対話設計が可能となる。
【００５４】
ここで図９を参照すると、
ステップＳ２１およびＳ２２は、それぞれ、図７に示したステップＳ１１およびＳ１２と同じである。
【００５５】
第２の態様の特徴の１つは、ステップＳ２３を介在させ、１つの対話から他の対話へ（例えば、Ｓ−０→Ｓ−１）遷移するか否かを判断することである。
【００５６】
対話ＩＤが変化しなければ（同一の対話が進行中）、そのままフレーム処理を継続する。つまり、ステップＳ２３の判断結果がＹｅｓならば、ステップＳ２４に進む。このことは従来と余り変わらないが、第２の態様のさらなる特徴は、フレーム参照テーブル２３に従って１つの対話ＩＤが他の対話ＩＤに遷移するときは（ステップＳ２３の判断結果がＮｏ）、現在進行しているフレーム処理を終了してしまうことである（ステップＳ２６およびＳ２７の各々の前半参照）。
【００５７】
ステップＳ２６およびＳ２７の各々の後半の処理は、フレーム参照テーブル２３（図５）を参照したときに、対応のテーブル部分に“対話終了コード”が記入されているか否か（ステップＳ２５）によって変わってくる。
【００５８】
つまり、ステップＳ２５の判断結果がＹｅｓの場合（対話終了コードあり）、対話を終了させてしまう。一方そのステップＳ２５の判断結果がＮｏの場合（対話終了コードなし）、対話は遷移先の対話へ移動して続行される。
【００５９】
図１０は第２の態様に従う対話モデルの一例を示す遷移図である。
【００６０】
スロットとしては、「肯定」「否定」「県名」の対話データに関係する３個のスロットが用意されているものとして、以下の３つのケースについて説明する。
【００６１】
ケース１）
図１０の対話状態０の状態で、ユーザが“県名”に関係する「兵庫県」を発声したとすると、スロットの１つである「県名」に関係するスロットが埋まる。そして対話状態３へ移動する。
【００６２】
この対話状態３で、フレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００６３】
この場合、「肯定」「否定」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００６４】
ケース２）
図１０の対話状態０の状態で、ユーザが“否定”に関係する「いいえ」を発声したとすると、スロットの１つである「否定」に関係するスロットが埋まる。そして対話状態２へ移動する。
【００６５】
この対話状態２でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００６６】
この場合、「肯定」「県名」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００６７】
ケース３）
図１０の対話状態０の状態で、ユーザが“肯定”に関係する「はい」を発声したとすると、スロットの１つである「肯定」に関係するスロットが埋まる。この状態でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤ：同じＩＤ、遷移先対話状態ＩＤ：１に遷移する。
【００６８】
この場合アプリケーションが遷移した対話ＩＤおよび対話状態ＩＤデータを元にユーザへ案内を出した後、遷移先対話状態：５の状態になる。
【００６９】
この対話状態５の状態で、ユーザが“県名”に関係する「兵庫県」を発声したとすると、スロットの１つである「県名」に関係するスロットが埋まる。そして対話状態３へ移動する。
【００７０】
この対話状態３でフレーム参照テーブル２３を参照して、そこに記述されている遷移先対話ＩＤおよび遷移先対話状態ＩＤに遷移する。
【００７１】
この場合、「否定」に関係するスロットが埋まっていないにも拘わらず、違う対話ＩＤに遷移することが可能となる。このとき遷移前のフレームは破棄される。
【００７２】
図１１は本発明に係る第３の態様を表す図である。
【００７３】
本図に示すとおり、第３の態様に基づくフレーム参照テーブル２３は、遷移先ＩＤ領域２５（図５と同じ）と拡張領域２６とからなる。
【００７４】
すなわち第３の態様は、フレーム参照テーブル２３における各フレームパターンは、各該フレームパターン毎に定義される遷移先対話ＩＤおよび遷移先対話状態ＩＤからなる遷移先ＩＤ領域２５に加えて、各該フレームパターン毎に定義される特定のイベントへの遷移先を記述する拡張領域２６を有することを特徴とするものである。なお、図１１では、拡張領域２６を拡張領域ＩおよびIIの対として示す。
【００７５】
ここで上記の特定のイベントを、第１例および第２例をもって説明する。
【００７６】
第１例によれば、そのイベントはアシスト対話である。アシスト対話とは、システム側からの問い掛けに対し所定の時間（例えば５秒）が経過してもユーザから何の応答もなかったり、あるいは、ユーザからの応答が「助け」を求めるようなものであったような場合に、システム側からもっと回答しやすい形で問い掛け直すときの対話をいう。
【００７７】
そこで拡張領域Ｉには、上記のアシスト対話の対話ＩＤを記述し、拡張領域IIには、該アシスト対話の対話状態ＩＤを記述できるようにする。なお、これら対話ＩＤおよび対話状態ＩＤは、対話の進行具合すなわちフレームパターンの種類に応じて異なる。
【００７８】
また第２例によればそのイベントは、例えばアプリケーションへ移行するためのイベント、例えばタイマーを起動させるための制御コードである。
【００７９】
かくして、第３の態様によれば対話設計の自由度および柔軟性を向上させることができる。
【００８０】
図１２は本発明に係る第４の態様の動作を表すフローチャート（その１）、
図１３は同フローチャート（その２）である。
【００８１】
この第４の態様の特徴は、第１の対話についてフレーム処理をしている途中で第２の対話に遷移するとき、その第１の対話においてスロットに埋めた対話データをそのまま保持し、かつ、上記の第２の対話でのフレーム処理にてスロットに埋めるべき対話データのうち、その保持している対話データと重複するものについては、当該保持データを流用することを特徴とするものである。
【００８２】
図１２を参照すると、
ステップＳ３１およびＳ３２はそれぞれ、図９に示したステップＳ２１およびＳ２２と同じである。
【００８３】
図１３を参照すると、
ステップＳ３３、Ｓ３４、Ｓ３５およびＳ３６はそれぞれ、図９に示したステップＳ２３、Ｓ２４、Ｓ２５およびＳ２７と同じである。
【００８４】
したがってこの第４の態様の特徴は、図１３のステップＳ３７およびＳ３８で表される。
【００８５】
第１の対話についてフレーム処理をしている途中で第２の対話に遷移するとき、そして対話が終了せず継続するとき、すなわち、図１２におけるステップＳ３３の判断結果がＮｏでさらに、図１３におけるステップＳ３５の判断結果もＮｏのときである。
【００８６】
このときに、第１の対話におけるフレーム処理においてスロットに埋めた対話データをそのまま保持する（図１３のステップＳ３７）。
【００８７】
さらに、遷移先の上記第２の対話でのフレーム処理にてスロットに埋めるべき対話のうち、その保持した対話データと重複するものについては、その保持対話データを流用する。すなわち遷移先で使用するフレームデータをフレームデータ領域２２から読み込む（図１３のステップＳ３８）。
【００８８】
このように第４の態様では、共通する対話データの使いまわしをし、これにより対話データベース１５におけるメモリ量を削減することが可能となる。
【００８９】
図１４は本発明に係る第４の態様の特例についての動作を表すフローチャート（その１）、
図１５は同フローチャート（その２）である。
【００９０】
この第４の態様の特例は、前述した第４の態様における「第２の対話」が既述（図１１）のアシスト対話である場合を規定したものである。したがって第４の態様における「第１の対話」はメイン対話である。
【００９１】
すなわちこの第４の態様の特例は、メイン対話についてフレーム処理をしている途中で、音声認識処理部１１（図１）が、ユーザに対するアシストが必要であるものと判定し、これによりアシスト対話に遷移するとき、そのメイン対話においてスロットに埋めた対話データをそのまま保持し、かつ、そのアシスト対話でのフレーム処理にてスロットに埋めるべき対話データのうち、上記の保持している対話データと重複するものについては、当該保持データを流用することを特徴とするものである。
【００９２】
図１４および図１５を参照すると、図１４に示すステップＳ２２と図１５に示すステップＳ２３〜Ｓ２７は、それぞれ、図９に示したステップＳ２２およびＳ２３〜Ｓ２７と同じである。
【００９３】
したがって第４の態様の特例において注目すべきステップは、図１４に示すステップＳ４１、Ｓ４２、Ｓ４３およびＳ４４である。ただし、このステップＳ４３およびＳ４４は、それぞれ、図１３に示した第４の態様におけるステップＳ３７およびＳ３８と同じである。
【００９４】
このため、ステップＳ４１およびＳ４２が特に注目すべきステップとなる。
【００９５】
ユーザがシステム側からの問い掛けに応答せず所定の時間（例えば５秒）が経過すると（タイムアウト）、上記ステップＳ４１の判断結果はＹｅｓとなり、アシスト対話への遷移が開始して、上記第４の態様の特徴をなすステップＳ４３に至り、さらにはステップＳ４４に至る。
【００９６】
上記のタイムアウトにはならないが、ユーザからの応答が「助け」を求めるものであって、アシスト対話へ遷移することとなる場合も、上記第４の態様の特徴をなすステップ４３に至り、さらにはステップＳ４４に至る。
【００９７】
これにより、第４の態様で得られる効果（対話データの使いまわしにより、対話データベース１５のメモリ量を削減する）と同様の効果が、アシスト対話への遷移時において得ることができる。
【００９８】
図１６は第４の態様の特例における対話モデル例Ｉを示す遷移図であり、
図１７は第４の態様の特例における対話モデル例IIを示す遷移図であり、
図１８は第４の態様の特例における対話モデル例III を示す遷移図である。
【００９９】
図１６では、上記アシスト対話において、上記メイン対話で必要な、図３で説明したスロット値属性Ａ、同じく図３で説明したスロット値属性Ｂを取得する場合を表している。
【０１００】
図１６の左側はメイン対話の遷移系列であり、その右側はアシスト対話の遷移系列である。
【０１０１】
アシスト対話の遷移系列で取得されたフレームデータ（スロット値属性Ａ、スロット値属性Ｂ）を、メイン対話のフレーム処理におけるフレームデータとして利用するものである。
【０１０２】
図１７および図１８の見方は上記の図１６の見方と同様である。
【０１０３】
図１９は本発明に係る第５の態様の動作を表すフローチャート（その１）であり、
図２０は同フローチャート（その２）である。
【０１０４】
この第５の態様の特徴は、前述した図１２〜図１８の態様において、フレームをなす複数のスロットのうち、対話データで埋められたスロットのみについて、その埋められた対話データを保持することを特徴とするものである。
【０１０５】
これにより、図１２〜図１８の態様により得られる、対話データの使いまわしにより、対話データベース１５のメモリ量を削減する、という効果がより一層顕著なものとなる。
【０１０６】
図１９および図２０を参照すると、まず図１９において、ステップＳ３１、Ｓ３２、Ｓ３３およびＳ３５は、前述した図１２および図１３で示した同一番号のステップと同様である。
【０１０７】
次に図２０において、ステップＳ３４およびＳ３６は、前述した図１３で示した同一番号のステップと同様である。したがってステップＳ５１およびＳ５２が第５の態様において注目すべきステップである。ただしステップＳ５２については図９に示したステップＳ２７と同様である。
【０１０８】
このステップＳ５１では、フレームをなす複数のスロットのうち、対話データで埋められたスロットのみについて、その埋められた対話データを、対話データベース１５内に保持しておく。
【０１０９】
なお本第５の態様以前の各態様のもとでは、図３に示すフレームデータ構造のフレームを構成する全てのスロットを、そのスロットが空であると否とを問わず、保持するようにしている。
【０１１０】
しかし第５の態様では、上記ステップＳ５１に示すごとく、スロット値（値１、値２等）の結果と属性のみを保持することとする。例えば、スロットを埋めている「兵庫県」と「目的地設定」をそれぞれ示すデータのみを保持するようにする。
【０１１１】
これにより前述のように、メモリ量は一層削減可能となる。
【０１１２】
図２１は本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）であり、
図２２は同フローチャート（その２）である。
【０１１３】
まず第６の態様について説明すると、この第６の態様は、遷移先の第２の対話またはアシスト対話でのフレーム処理においてスロットに埋めるべき対話データと、前述の保持している対話データとが一致するか否か判断し、一致すると判断したときは、その保持している対話データを用いて当該スロットを埋めることを特徴とするものである。「保持している対話データ」とは、図１３のステップＳ３７や図１４のステップＳ４３で保持するデータのことである。
【０１１４】
図２１および図２２を参照するとこの第６の態様は、ステップＳ６１→Ｓ６２→Ｓ６３→Ｓ６４で表される。
【０１１５】
上述の図１３と図１４では、それぞれ、ステップＳ３８とＳ４４で終了するように表しているが、ここで説明する第６（および第７、第８）の態様は、これらステップＳ３８やＳ４４以降についての態様である。つまり図２１のステップＳ６１から処理が開始する。
【０１１６】
ステップＳ６２では、遷移先のフレーム処理でスロットに埋めるべき対話データ、例えばスロット値属性１Ａ，１Ｂ，２Ａ，２Ｂ…（図３参照）と、上記の保持している対話データ（この例ではスロット値属性１Ａ，１Ｂ，２Ａ，２Ｂ…）とが一致するか否か判断する。
【０１１７】
一致していれば、ステップＳ６３にて、その一致したスロットの内容で、遷移先でのフレームにおける該当スロットを埋める。
【０１１８】
このようにしてスロットが埋まったフレームのフレームパターンをもってフレーム参照テーブル２３（図５）を参照し、次の遷移先の対話ＩＤ／対話状態ＩＤを検索して、対話をさらに先に進めていく。これが図２２のステップＳ６４である。
【０１１９】
これにより第６の態様においても、対話データの使いまわしによるメモリ量の削減効果が得られる。
【０１２０】
続いて、図２１および図２２を参照して、第７の態様を説明する。
【０１２１】
第７の態様は、既述した遷移先の第２の対話またはアシスト対話でのフレーム処理においてスロットに埋めるべき対話データと、上述の保持している対話データとが一致するか否か判断し、一致しないと判断したとき、かつ、当該遷移先の現状のフレーム処理がフレーム処理開始から既に進んでいると判断したときは、そこから元に戻って対話データの逆検索を実行することを特徴とするものである。
【０１２２】
図２１を参照すると、前記ステップＳ６２の判断結果がＮｏすなわち不一致であると、まずステップＳ６３′において現状の対話ＩＤ／対話状態ＩＤがどうなっているか判断する。この判断をもとに図２２のステップＳ６５に移る。
【０１２３】
このステップＳ６５では、当該遷移先の現状のフレーム処理がフレーム処理を開始する状態にあるか否か判断する。
【０１２４】
第７の態様は、このステップＳ６５とこれに続くステップＳ６７に特徴がある。好ましくはステップＳ６６を取り入れる。ステップＳ６５の判断結果がＹｅｓ、すなわち現状のフレーム処理がフレーム処理の開始であれば、該ステップＳ６６に移り、前述した保持している対話データをクリアしてしまう。改めてフレーム処理を開始するので、保持していた対話データは不要となるからである。
【０１２５】
一方、上記ステップＳ６５の判断結果がＮｏ、すなわち現状のフレーム処理はフレーム処理開始から既に進んでいるときは、既にスロット群に所要の対話データが埋まっているから、そこから元に戻ってフレームデータの逆検索を行う。ここまでが第７の態様である。
【０１２６】
次に第８の態様が開始する。この第８の態様は、上記の逆検索を実行し（ステップＳ６７）、そこで得た対話データを用いて、既述の第１の対話またはメイン対話でのフレーム処理におけるスロットを埋める（ステップＳ６８）ことを特徴とするものである。
【０１２７】
図２２を参照すると、この第８の態様はステップＳ６８→Ｓ６９→Ｓ６４（前出）により表される。
【０１２８】
かくして得たフレームパターンについてフレーム参照テーブル２３により遷移先の対話ＩＤ／対話状態ＩＤを検索し、第１の態様等と同様にさらに対話を進める。
【０１２９】
これにより、第７および第８の態様もまた、メモリ量の削減という効果をもたらす。
【０１３０】
図２３は本発明に係る第９の態様の動作を示すフローチャートである。
【０１３１】
この第９の態様は、遷移先の対話の種類が遷移前の対話の種類と同一のときは、この遷移前の対話でのフレーム処理で生成したフレーム内の対話データを全てクリアしてから、再度この遷移前の対話でのフレーム処理を実行することを特徴とするものである。
【０１３２】
図２３において、ステップＳ７１では、遷移先の対話が遷移前の対話と同一か否か判断する。
【０１３３】
同一ならば（Ｙｅｓ）、ステップＳ７２に移って、その遷移前のフレーム処理で埋めたスロットの内容を全てクリアする。
【０１３４】
その後、再度、その遷移前のフレーム処理を初めから行う。
【０１３５】
もし上記遷移前におけるフレームのスロットのデータを残したままにしておくと、この埋まったままのフレームで特定されるフレームパターン（図５のフレームパターン１，２…）を別途用意しなければならなくなるからである。
【０１３６】
したがって第９の態様によれば、同一形式のデータを繰り返し持つ必要がなくなり、メモリ量の削減という効果がもたらされる。
【０１３７】
図２４は第９の態様が利用される対話モデルの一例を示す図である。
【０１３８】
これはナビゲーションにおけるある対話Ｓ−５を取り出したものである。
【０１３９】
Ｓ−５：５に対するユーザの返事が「はい」であるので、また、同じ対話Ｓ−５に戻る。この戻ったときに、Ｓ−５：２とＳ−５：４の「いいえ」とＳ−５：６「はい」を共にクリアする。
【０１４０】
図２５は本発明に係る第１０の態様の動作を表すフローチャートである。
【０１４１】
この第１０の態様は、フレーム参照テーブル２３によって特定された対話の遷移先の指示内容が、当該対話システム１０が連係するアプリケーション１３に応じて分岐すべきことを表しているとき、直前まで進行していた対話処理を一旦終了して、このアプリケーション１３から対話開始の命令と共に指示される遷移先にて対話処理を継続することを特徴とするものである。
【０１４２】
図２５を参照すると、ステップＳ８１では、上記の対話の遷移先の指示内容が特定の制御コード、すなわちアプリケーション（アプリとも称す）によって遷移先を決めるべきことを表すコードであると（Ｙｅｓ）、ステップＳ８３へ移る。この制御コードは、拡張領域２６（図１１）に記述しておくことができる。
【０１４３】
なお特定の制御コードでなければ（Ｎｏ）、ステップＳ８２に移り、前述した通常処理を行う。
【０１４４】
特定の制御コードが記述されているときはステップＳ８３に移り、一旦対話処理を終了する。このときは“対話終了”のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）が呼び出される。
【０１４５】
そしてステップＳ８４にて、アプリケーションから対話開始の命令が出されるのを待つ。
【０１４６】
この対話開始命令が出ると、ステップＳ８５にて、この命令と共に送られる対話ＩＤ／対話状態ＩＤ（遷移先の指定データ）で定まる対話から対話処理を開始する。
【０１４７】
このように、第１０の態様によれば、様々な対話状態を指示するアプリケーションが自ら指示を出すので、対話データベース１５に格納すべきデータのデータ量を大幅に減少させることができる。
【０１４８】
図２６は第１０の態様が適用される対話モデルの一例を示す図である。
【０１４９】
本図は、アプリケーションの指示に従って遷移先が分岐する様子を示している。
【０１５０】
図２７は本発明に係る第１１の態様の動作を表すフローチャートである。
【０１５１】
この第１１の態様は、一連のスロット（図３のフレームデータ領域２２）の一部を、当該対話システムが連係するアプリケーション１３への要求に基づいて該アプリケーション１３から提供される対話データによって埋めることを特徴とするものである。
【０１５２】
従来のナビゲーション装置においては、対話データの入力を、音声ではなく、操作パネルの操作スイッチ（図１の右上のＳＷ参照）で行うときは、一連の操作が終了するまで全てその操作スイッチによらなければ対話を行うことができなかった。
【０１５３】
ところがこの第１１の態様によれば、アプリケーションに従ってスイッチ操作で得られた対話データ、例えばＵ：「兵庫県」やＵ：「神戸市」が存在していれば、これをアプリケーション１３側に要求し該アプリケーション１３から受け取るようにする。
【０１５４】
これにより、スイッチ操作で得た対話データも対話遷移制御手段２１にて管理することができ、対話設計の柔軟性が高まる。
【０１５５】
図２７を参照すると、ステップＳ９１で、アプリケーション１３から“対話開始”の命令が出されると、
ステップＳ９２で、その命令と共に出力される遷移先の指定データを分析し、操作の途中から対話を開始するのか否か判断する。
【０１５６】
ステップＳ９３では、ステップＳ９２の判断結果がＮｏであると、現在の対話状態に至るまでにまだ埋まっていないスロットを埋めるのに必要な値を、アプリケーション１３に対して要求し、
ステップＳ９４で、上記の必要な値を該当スロットに埋める。
【０１５７】
ステップＳ９５では、入手済みの値で埋め切ったフレームデータのフレームパターンがフレーム参照テーブル２３に存在するか否か判断し、存在すれば
ステップＳ９６にて、対話を続行する。
【０１５８】
図２８は本発明に係る第１２の態様の動作を表すフローチャートである。
【０１５９】
この第１２の態様は、ある対話状態Ｓを経て音声合成部１６が起動されてユーザに案内を行っている途中で、当該対話システム１０が連係するアプリケーション１３に割り込みが生じた場合、対話遷移制御手段２１は、該アプリケーション１３によりその対話状態Ｓに戻れという命令を受けて遷移先をその対話状態Ｓに特定することを特徴とするものである。
【０１６０】
この場合、その対話状態Ｓで蓄積したフレームデータはクリアしておくのが好ましい。
【０１６１】
このように状態遷移の制御の一部を、アプリケーション１３側に移すことにより、対話エンジン（対話遷移制御手段２１）の負荷を軽くすることができる、という効果がもたらされる。すなわち、戻れというフレームデータ（スロット）を用意する必要がない。
【０１６２】
図２８を参照すると、
ステップＳ１０１で、対話エンジン１２は、アプリケーション１３に割り込みが発生したか判断する。一例を挙げると、音声認識処理部１１において誤認識が行われたことが判明したような場合に、その割り込みが発生する。そうすると、ステップＳ１０２において、前の対話に戻れという命令が出されているか判断する。出されていれば、
ステップＳ１０３において、対話遷移制御手段２１は、上記の誤認識に至った対話をなすフレームに戻り、フレームを再構築する。
【０１６３】
図２９は本発明に係る第１３の態様を表す図である。
【０１６４】
この第１３の態様は、図２の構成にグローバル発話専用フレームメモリ３１を付加した構成を有する。
【０１６５】
以上述べてきたいろいろな対話の中で、いずれの対話においても必ず共通する発話が存在する。これがグローバル発話である。いくつかの例を挙げてみると、“戻る”、“認識エラー”、“中止”、“一旦停止”、“誤認識”、“ヘルプ”等々に起因してユーザから入力される発話である。
【０１６６】
このような発話も含めて、フレームデータ領域２２およびフレーム参照テーブル２３を形成すると、そのデータサイズは大となってしまう。したがってメモリ量が増大してしまう。また既述したメンテナンスも難しくなる。
【０１６７】
そこで第１３の態様は、上記のグローバル発話のみを専用に記憶するグローバル発話メモリ３１を設けることを特徴とするものである。
【０１６８】
かくして、メモリ量の削減とメンテナンスの向上を可能とする、という効果を得ることができる。
【０１６９】
【発明の効果】
以上説明したように本発明によれば、全ての対話をフレーム処理で実現可能とし、これにより対話設計の自由度、柔軟性ならびに簡易性を向上させた対話システムを実現することができる。
【図面の簡単な説明】
【図１】本発明が適用される対話システムの一構成例を示す図である。
【図２】本発明の主要部を表す図である。
【図３】図２のフレームデータ領域２２の詳細例を示す図である。
【図４】対話ＩＤと対話状態ＩＤの一例を示す図である。
【図５】図２のフレーム参照テーブル２３の詳細例を示す図である。
【図６】図５のフレームパターンの検索の仕方を図解的に表す図である。
【図７】本発明に係る第１の態様の動作を表すフローチャートである。
【図８】（ａ）および（ｂ）は第１の態様に従う対話モデルの簡単な２例を示す遷移図である。
【図９】本発明に係る第２の態様の動作を表すフローチャートである。
【図１０】第２の態様に従う対話モデルの一例を示す遷移図である。
【図１１】本発明に係る第３の態様の動作を表す図である。
【図１２】本発明に係る第４の態様の動作を表すフローチャート（その１）である。
【図１３】本発明に係る第４の態様の動作を表すフローチャート（その２）である。
【図１４】本発明に係る第４の態様の特例についての動作を表すフローチャート（その１）である。
【図１５】本発明に係る第４の態様の特例についての動作を表すフローチャート（その２）である。
【図１６】第４の態様の特例における対話モデル例Ｉを示す遷移図である。
【図１７】第４の態様の特例における対話モデル例IIを示す遷移図である。
【図１８】第４の態様の特例における対話モデル例III を示す遷移図である。
【図１９】本発明に係る第５の態様の動作を表すフローチャート（その１）である。
【図２０】本発明に係る第５の態様の動作を表すフローチャート（その２）である。
【図２１】本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）である。
【図２２】本発明に係る第６、第７および第８の態様の動作を表すフローチャート（その１）である。
【図２３】本発明に係る第９の態様の動作を表すフローチャートである。
【図２４】第９の態様が利用される対話モデルの一例を示す図である。
【図２５】本発明に係る第１０の態様の動作を表すフローチャートである。
【図２６】第１０の態様が利用される対話モデルの一例を示す図である。
【図２７】本発明に係る第１１の態様の動作を表すフローチャートである。
【図２８】本発明に係る第１２の態様の動作を表すフローチャートである。
【図２９】本発明に係る第１３の態様の動作を表す図である。
【符号の説明】
１０…対話システム
１１…音声認識処理部
１２…対話エンジン
１３…アプリケーション
１４…認識辞書
１５…対話データベース
１６…音声合成部
１７…ＧＵＩ制御部
１８…ディスプレイ
２１…対話遷移制御手段
２２…フレームデータ領域
２３…フレーム参照テーブル
２５…遷移先ＩＤ領域
２６…拡張領域
３１…グローバル発話専用メモリ
Claims (7)
- ユーザからの発声の内容を認識する音声認識処理部と、その認識結果に応じてアプリケーションに従いユーザへの案内を生成する対話エンジンと、その生成された案内の内容を音声として合成してユーザに提供する音声合成部と、前記案内を生成するために前記対話エンジンと協働する対話データベースと、を少なくとも備えてなる対話システムにおいて、
対話を構成するフレームをなす一連のスロットの各々にそれぞれ対応する対話データを、該当のスロットに埋めていくためのフレームデータ領域と、該フレームデータ領域内に埋められた前記対話データの埋まり具合によって定まる複数のフレームパターンのそれぞれに対応する対話の遷移先を該フレームパターン毎に定義したフレーム参照テーブルと、を前記対話データベース内に構築し、
前記フレームデータ領域と前記フレーム参照テーブルとを用いて、前記対話データの埋まり具合に応じた対話の遷移先を特定する対話遷移制御手段を、前記対話エンジン内に形成し、
第１の対話についてフレーム処理をしている途中で第２の対話に遷移するとき、該第１の対話において前記スロットに埋めた前記対話データをそのまま保持し、かつ、該第２の対話でのフレーム処理にてスロットに埋めるべき対話データのうち、前記の保持している対話データと重複するものについては、当該保持データを流用し、ここに、進行中の対話がどのようなジャンルの対話を行っているかを特定する対話ＩＤは、前記第１の対話と第２の対話とで異なることを特徴とする対話システム。 - ユーザからの発声の内容を認識する音声認識処理部と、その認識結果に応じてアプリケーションに従いユーザへの案内を生成する対話エンジンと、その生成された案内の内容を音声として合成してユーザに提供する音声合成部と、前記案内を生成するために前記対話エンジンと協働する対話データベースと、を少なくとも備えてなる対話システムにおいて、
対話を構成するフレームをなす一連のスロットの各々にそれぞれ対応する対話データを、該当のスロットに埋めていくためのフレームデータ領域と、該フレームデータ領域内に埋められた前記対話データの埋まり具合によって定まる複数のフレームパターンのそれぞれに対応する対話の遷移先を該フレームパターン毎に定義したフレーム参照テーブルと、を前記対話データベース内に構築し、
前記フレームデータ領域と前記フレーム参照テーブルとを用いて、前記対話データの埋まり具合に応じた対話の遷移先を特定する対話遷移制御手段を、前記対話エンジン内に形成し、
メイン対話についてフレーム処理をしている途中で、前記音声認識処理部が、ユーザに対するアシストが必要であるものと判定し、これによりアシスト対話に遷移するとき、該メイン対話において前記スロットに埋めた前記対話データをそのまま保持し、かつ、該アシスト対話でのフレーム処理にてスロットに埋めるべき対話データのうち、前記の保持している対話データと重複するものについては、当該保持データを流用することを特徴とする対話システム。 - 遷移先の対話の種類が遷移前の対話の種類と同一のときは、該遷移前の対話でのフレーム処理で生成したフレーム内の対話データを全てクリアしてから再度該遷移前の対話でのフレーム処理を実行することを特徴とする請求項１または２に記載の対話システム。
- 前記フレームをなす複数の前記スロットのうち、前記対話データで埋められたスロットのみについて、その埋められた対話データを保持することを特徴とする請求項１または２に記載の対話システム。
- 遷移先の前記第２の対話またはアシスト対話でのフレーム処理において前記スロットに埋めるべき対話データと、前記の保持している対話データとが一致するか否か判断し、一致すると判断したときは、その保持している対話データを用いて当該スロットを埋めることを特徴とする請求項１または２に記載の対話システム。
- 遷移先の前記第２の対話またはアシスト対話でのフレーム処理において前記スロットに埋めるべき対話データと、前記の保持している対話データとが一致するか否か判断し、一致しないと判断したとき、かつ、当該遷移先の現状のフレーム処理がフレーム処理開始から既に進んでいると判断したときは、そこから元に戻って対話データの逆検索を実行することを特徴とする請求項１または２に記載の対話システム。
- 前記逆検索を実行しそこで得た対話データを用いて、前記第１の対話またはメイン対話でのフレーム処理におけるスロットを埋めることを特徴とする請求項６に記載の対話システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001244617A JP3998443B2 (ja) | 2001-08-10 | 2001-08-10 | 対話システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001244617A JP3998443B2 (ja) | 2001-08-10 | 2001-08-10 | 対話システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003058187A JP2003058187A (ja) | 2003-02-28 |
| JP3998443B2 true JP3998443B2 (ja) | 2007-10-24 |
Family
ID=19074520
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001244617A Expired - Fee Related JP3998443B2 (ja) | 2001-08-10 | 2001-08-10 | 対話システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3998443B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2018021987A (ja) * | 2016-08-02 | 2018-02-08 | ユニロボット株式会社 | 会話処理装置、及びプログラム |
| CN111128121B (zh) * | 2019-12-20 | 2021-04-30 | 贝壳找房(北京)科技有限公司 | 语音信息生成方法和装置、电子设备和存储介质 |
-
2001
- 2001-08-10 JP JP2001244617A patent/JP3998443B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003058187A (ja) | 2003-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4090040B2 (ja) | 双方主導マルチモーダル対話及び関連ブラウジング機構を作成するための方法及びシステム | |
| US6243675B1 (en) | System and method capable of automatically switching information output format | |
| KR101709187B1 (ko) | 계층적 대화 태스크 라이브러리를 이용한 이중 대화관리 기반 음성대화시스템 | |
| US8495562B2 (en) | System and method to graphically facilitate speech enabled user interfaces | |
| JP2001296943A (ja) | 対話型ユーザインターフェース装置 | |
| JP3178426B2 (ja) | 自然言語対話システム及び自然言語対話プログラム記録媒体 | |
| US20080255838A1 (en) | Audible presentation and verbal interaction of html-like form constructs | |
| JP2008203559A (ja) | 対話装置及び方法 | |
| US20110258543A1 (en) | Dialog system | |
| CN106030701A (zh) | 用于通过语音对话装置检测至少两个具有待关联信息内容的待检测信息的方法、语音对话装置以及机动车 | |
| JP2007079397A (ja) | 対話方法、対話装置、対話プログラムおよび記録媒体 | |
| JP4694198B2 (ja) | 対話装置、対話方法、対話プログラムおよびコンピュータに読み取り可能な記録媒体 | |
| JP3998443B2 (ja) | 対話システム | |
| JP2006155086A (ja) | ユーザインタフェース設計装置およびその制御方法 | |
| JP2007193422A (ja) | 対話型の情報処理システム、およびサービス・シナリオ用のヘルプ・シナリオを提供する方法 | |
| JP4585759B2 (ja) | 音声合成装置、音声合成方法、プログラム、及び記録媒体 | |
| JP3615309B2 (ja) | データ検索装置および方法、情報記憶媒体 | |
| JP3846896B2 (ja) | 音声入力された複合名詞の検索装置、検索方法およびデータベース | |
| JPH0844384A (ja) | 連続単語音声認識装置 | |
| JPH07168691A (ja) | 表示図形領域選択方式 | |
| JP3576511B2 (ja) | 音声対話装置 | |
| JP4535804B2 (ja) | 音声対話シーケンス状態表記方法、プログラム、および音声対話装置 | |
| JP3755941B2 (ja) | 音声対話装置及び対話方法 | |
| JP4056546B2 (ja) | 音声入力された複合名詞の検索装置、検索方法およびデータベース | |
| JP4682322B2 (ja) | 対話情報処理装置及び対話情報処理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041215 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061215 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070109 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070309 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070410 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070510 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070621 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070710 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070807 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110817 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |