(57)【特許請求の範囲】
【請求項１】
利用者側が情報要求を意味する文節列を音声入力すると、前記情報要求の内容を確認するための確認文節列を利用者側に出力し、利用者側が確認の承認を意味する文節列を入力すると、前記情報要求に対する応答文節列を利用者側に出力する要求確認型情報提供装置において、
利用者側が音声入力する情報要求から初期要求条件を生成する第１手段と、
前記初期要求条件に含まれている要求項目を、あらかじめ定めた優先順位に基づいて、順次、削除していくことで、前記初期要求条件を緩和した緩和要求条件を段階的に１個以上生成する第２手段と、
前記初期要求条件に対する応答文節列、前記緩和要求条件に対する応答文節列を生成する第３手段と、
前記初期要求条件に対する応答文節列の長さを長さ基準として、前記初期要求条件を緩和した前記緩和要求条件に対する応答文節列の長さが、あらかじめ緩和要求条件の応答文節列の長さと前記長さ基準との差の上限を規定した出力量制約を満足する場合、当該緩和要求条件を最終要求条件と決定し、当該緩和要求条件に対する応答文節列を最終応答文節列と決定する第４手段と、
前記最終要求条件を確認するための確認文節列を生成する第５手段と、
前記生成された確認文節列を利用者側に出力し、利用者側から確認の承認を意味する文節列が入力されると、前記最終応答文節列を利用者側に出力する第６手段と、
を有することを特徴とする要求確認型情報提供装置。
【請求項２】
請求項１記載の要求確認型情報提供装置において、第４手段は、応答文節列の長さが出力量制約を満足するのに対応する、緩和要求条件が複数存在する場合、その中で最も弱い緩和要求条件を最終要求条件と決定することを特徴とする要求確認型情報提供装置。
【請求項３】
請求項１もしくは２記載の要求確認型情報提供装置において、第４手段は、応答文節列の長さが出力量制約を満足するのに対応する、緩和要求条件が存在しない場合、初期要求条件を最終要求条件と決定することを特徴とする要求確認型情報提供装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は要求確認型情報提供サービスシステムに係り、詳しくは、利用者が情報要求を意味する文節列を音声入力するとき、該情報要求を確認するための文節列を利用者に対し出力し、利用者が確認の承認を意味する文節列を入力する場合には、先の情報要求を満たす情報の内容を表した文節列を利用者に対し出力し、利用者が確認の否認を意味する文節列を入力する場合には、利用者が新たな情報要求を意味する文節列を音声入力するのを待つような要求確認型情報提供装置に関するものである。
【０００２】
【従来の技術】
要求確認型情報提供サービスシステムでは、図２に動作シーケンス例を示すように、例えば、気象情報、テレビ番組表、スケジュール表、交通機関の時刻表、といった様々な情報を蓄積したデータベースがあるとき、データベースに蓄積された情報を要求することを意味する文節列を、利用者が計算機端末のキーボード、マウス、音声認識装置、或いは、これらの組み合わせを介して、文字列または音声として入力すると、情報提供側は、まず、利用者の情報要求を確認するための文節列を、計算機端末のディスプレイ、プリンタ、タイプライタ、音声合成装置、或いは、これらの組み合わせを介して、利用者に対し出力し、利用者が確認の承認を意味する文節列を、同様に文字列または音声として入力する場合には、情報提供側は、情報要求を満たす情報の内容を表した文節列を、同様に文字列または音声として利用者に対し出力し、利用者が確認の否認を意味する文節列を、同様に文字列または音声として入力する場合には、情報提供側は、利用者が情報要求を意味する文節列を入力するのを待つような、動作シーケンスをとる。なお、図２では、利用者が確認の否認を意味する文節列を入力した場合のシーケンスは省略してある。
【０００３】
従来、この種の要求確認型情報提供サービスシステムにおいては、情報提供側は、利用者が情報要求を意味した文節列を入力したときに、情報要求の内容を表す要求条件を生成し、その要求条件の内容の全てを確認するための文節列を利用者に対し出力し、利用者が確認の承認を意味する文節列が入力した時点で、その要求条件に適合する情報の内容を表す文節列を利用者に対し出力していた。
【０００４】
【発明が解決しようとする課題】
従来の技術では、利用者により入力された文節列から生成した要求条件の内容を全て確認するための文節列を出力する。その後、利用者が確認の承認を意味する文節列を入力した場合に、要求条件に適合する情報の内容を表す文節列を利用者に対し出力する。要求条件に適合する情報が空（無し）の場合は、要求条件に適合する情報の内容が空であることを表す文節列を利用者に対し出力する。
【０００５】
従来の技術では、利用者が入力した文節列から生成した要求条件の内容を全て確認するため、音声による入力の場合、誤認識に伴う利用者不満度を増大させるという問題がある。以下に、これについて説明する。
【０００６】
利用者が音声入力した文節列から要求条件を生成する際には、文字列または音声の誤認識などの理由により、利用者が意図する要求条件とは異なる要求条件が生成される場合がある。その場合には、システムが確認のために出力する要求条件の内容は、利用者が意図する情報要求と異なるので、利用者は確認の否認を意味する文節列を入力することになり、利用者の情報要求を満たす情報は利用者に出力されない。
【０００７】
一般に、確認する要求条件の内容が多いほど、その中に誤りが含まれる可能性が高くなり、利用者が確認を否認する可能性が高くなり、利用者が要求する情報が利用者に対し出力されない可能性が高くなり、誤認誠に伴う利用者の不満足度は増すことになる。
【０００８】
もし、利用者入力から生成された要求条件（以下、初期要求条件）を緩和した要求条件（以下、緩和要求条件）をつくり、その緩和要求条件の内容を利用者に対し確認するとすると、緩和要求条件の内容は、初期要求条件の内容よりも小さいので、誤りが含まれる可能性は小さくなり、利用者が確認を否認する可能性が小さくなり、誤認識に伴う利用者の不満足度が増すことを避けることができる。
【０００９】
この一方で、要求条件を緩和すると、緩和要求条件は初期要求条件より弱い条件なので、緩和要求条件に適合する情報の量は、初期要求条件に適合する情報の量よりも大きくなる。したがって、確認が承認された後、利用者に対し出力される情報の量が増えることになる。利用者が要求してもいない情報が大量に利用者に対し出力されると、利用者に対する出力量の増大に伴う利用者の不満足度が増すおそれがある。
【００１０】
しかし、初期要求条件に適合する情報の内容を表した文節列の長さを長さ基準としたとき、初期要求条件を緩和した緩和要求条件に適合する情報の内容を表した文節列の長さが、長さ基準と比べて、等しい、或いは、利用者の不満足度を増すほどには長くならないといった出力量の上限を規定した制約を満たす場合が存在する。この場合には、緩和要求条件の内容を確認することによって、利用者が確認を否認する可能性が小さくなり、且つ、利用者に対し出力される情報の量も、文節列の長さという観点からみたときに、増大しない。したがって、初期要求条件の代わりに緩和要求条件を使うことにより、誤認識に伴う利用者の不満足度が軽減し、なおかつ、利用者に対する出力量の増大に伴う利用者不満足度が増すことを避けることもできる。
【００１１】
従来の技術では、このように利用者に対する出力量の上限を規定する制約が満たされているような場合であっても、初期要求条件の内容を全て確認しようとするので、誤認識に伴う利用者の不満足度の増大を避けることができない。
【００１２】
例えば、気象情報に関する情報要求について考える。利用者が、図４に示す文節列（例１）を入力したとする。利用者の意図は、「横浜市の明日午後の天気についての情報を要求する」ということである。このとき、音声の認識誤りなどの理由により、「午後の」が「午前の」と誤って認識され、「横浜市の明日午前の天気を要求する」という初期の要求条件Ａが生成される場合を想定する。
【００１３】
従来の技術では、「横浜市の明日午前の天気を要求する」という初期要求条件Ａの内容の全てを確認するための、図５に示すような文節列（例２）を出力する。これは、利用者意図とは異なっているので、利用者は、「いいえ」、「ちがいます」といった否認のための文節列を入力する。否認を意味する文節列が入力されたので、次の利用者からの情報要求を待つ状態になる。利用者は横浜市の明日午後の天気を知るために、再度、情報要求を繰り返さなければならず、誤認識に伴う利用者不満足度が増す。
【００１４】
今、気象情報として、横浜市の明日の天気は、午前０時から午前３時まで晴れ、午前３時から明後日の午前０時まで雨という内容の情報が存在したとする。誤って生成された初期の要求条件Ａに適合する情報を文節列で表すと、図６のような文節列（例３）になる。すなわち、午前であることが初期の要求条件Ａには含まれているので、午前０時から正午までの天気を表す文節列となっている。
【００１５】
ここで、誤って生成された「横浜市の明日午前の天気を要求する」という初期要求条件Ａを緩和した「横浜市の明日の天気を要求する」という緩和要求条件Ｂについて考える。緩和要求条件Ｂの内容を確認するとすると、図７に示すような文節列（例４）を出力することになる。また、緩和要求条件Ｂに適合する情報の内容を文節列で表すと、図８のような文節列（例５）になる。
【００１６】
緩和要求条件Ｂの内容を確認するための文節列である例４（図７）は、「午前の」という部分を含まないだけ、初期要求条件Ａの内容を確認するための文節である例２（図５）と比べて、誤りが含まれている可能性が小さいので、利用者が確認を否認する可能性が小さくなり、誤認識に伴う利用者不満足度を減少させることができる。しかも、緩和要求条件Ｂに適合する情報を表した文節列である例５（図８）の長さは６であり、初期要求条件Ａに適合する情報を表した文節列である例３（図６）の長さも６であり、両方の長さは等しい。したがって、初期要求条件Ａの場合に比べて、緩和要求条件Ｂの場合の方が、もし確認の承認が行われた場合に、利用者に対する出力量の増大に伴う利用者不満足度が増加するとはいえない。
【００１７】
こういった緩和要求条件Ｂが存在するにもかかわらず、従来の技術では、常に要求条件Ａの内容を全て確認し、緩和要求条件Ｂを使えば避けることのできるはずの利用者不満足度の増大を避けることができないという問題がある。
【００１８】
本発明は、要求確認型情報提供サービスシステムにおいて、上述のような従来の技術の問題点に鑑みなされたもので、従来の技術では、利用者が音声入力する情報要求から生成される初期要求条件の内容を全て確認する文節列を出力する場合であっても、初期要求条件を緩和した緩和要求条件の内容を確認するための文節列を生成することによって、誤認識に伴う利用者の不満足度を軽減させ、且つ、緩和要求条件に適合する情報の出力量増大に伴う利用者の不満足度の増大を避けることを可能とする要求確認型情報提供装置を提供することを目的とする。
【００１９】
【課題を解決するための手段】
本発明の一実施例では、利用者からの情報要求、確認の承認、確認の否認を受け取る入力手段、利用者が情報要求を意味する文節列を音声入力するとき、情報要求の内容を表す要求条件を初期要求条件として生成し、利用者が確認の承認を意味する文節列を入力するとき、承認信号を生成し、利用者が確認の否認を意味する文節列を入力するとき、否認信号を生成する言語理解手段、初期要求条件を段階的に緩和することによって、緩和要求条件を１個以上生成する要求条件緩和生成手段、初期要求条件および緩和要求条件に適合する情報を検索し、その要求条件に適合する情報が存在する場合は、その要求条件に適合する情報の内容を表した文節列を、その要求条件に適合する情報が存在しない場合、その要求条件に適合する情報が存在しないということを表す文節列を、それぞれ応答文節列として生成する応答文生成手段、初期要求条件、緩和要求条件、及び、それらから生成される応答文節列を対応づけて保持し、初期要求条件の応答文節列の長さを長さ基準として、緩和要求条件の応答文節列の長さと長さ基準との差の上限を規定した出力量制約により、緩和要求条件の応答文節列の長さが出力量制約を満たすような緩和要求条件が存在する場合には、そのような緩和要求条件の中で最も弱い緩和要求条件を最終要求条件として決定し、その応答文節列の長さが出力量制約を満たすような緩和要求条件が存在しない場合には、初期要求条件を最終要求条件として決定し、この決定した最終要求条件の応答文節列を最終応答文節列として決定する要求条件決定手段、最終要求条件を確認するための確認文節列を生成する確認文生成手段、最終応答文節列または確認文生成手段５０が生成する確認文節列を利用者に対し出力する出力手段、これら各手段の動作を制御する制御手段などを具備する。
【００２０】
本発明では、利用者が音声入力する情報要求から初期要求条件を生成し、初期要求条件を緩和して得られた緩和要求条件の集合を緩和要求条件集合として生成し、初期要求条件が適合する情報の内容を表した文節列の長さを長さ基準とし、緩和要求条件集合に含まれる各緩和要求条件に適合する情報の内容を表す文節列を各緩和要求条件の応答文節列とし、緩和要求条件の応答文節列の長さと長さ基準との差の上限を規定した出力量制約により、緩和要求条件の応答文節列の長さが出力量制約を満たすような緩和要求条件が存在するなら、その緩和要求条件を最終要求条件として決定する。この結果、初期要求条件の内容を全て確認することなく、最終要求条件として決定された緩和要求条件の内容を確認することによって、誤認識に伴う利用者不満足度を軽減させ、利用者が確認の承認を入力した後、最終要求条件として決定された緩和要求条件の応答文節列を出力することによって、利用者に対する出力量の増大に伴う利用者不満足度の増大を避けることが可能となる。
【００２１】
【発明の実施の形態】
以下、本発明の一実施の形態について図面により詳細に説明する。
図１は、本発明による要求確認型情報提供装置の構成例を示す。本要求確認型情報提供装置は、入力部１００、言語理解部１１０、要求条件緩和生成部１２０、応答文生成部１３０、要求条件決定部１４０、確認文生成部１５０、出力部１６０、制御部１７０、及びデータベース１８０により構成される。入力部１００と出力部１６０は、通信回線などにより利用者の端末と接続されるが、図１では省略してある。なお、本発明による要求確認型情報提供方法は、基本的には図１の１００〜１６０などを処理ステップで置き替えればよい。
【００２２】
入力部１００は、利用者が計算機端末のキーボード、マウス、音声認識装置、あるいは、これらの組合せを介して、文字列または音声として入力する情報要求または確認の承認または確認の否認を意味する文節列を取り込む。
【００２３】
言語理解部１１０は、利用者が情報要求を意味する文節列を音声入力するときは、情報要求の内容を表す要求条件を初期要求条件として生成し、この生成した初期要求条件を要求条件緩和生成部１２０と要求条件決定部１４０に転送する。また、言語理解部１１０は、利用者が確認の承認を意味する文節列を文字列または音声として入力するとき承認信号を生成し、利用者が確認の否認を意味する文節列を文字列または音声として入力するとき否認信号を生成し、この生成した承認信号あるいは否認信号を制御部１７０に送る。
【００２４】
要求条件緩和生成部１２０は、言語理解部１１０から転送されてきた初期要求条件を段階的に緩和することによって、初期要求条件を緩和した緩和要求条件を１個以上生成し、この生成した緩和要求要求条件を要求条件決定部１４０に転送する。この要求条件緩和生成部１２０では、初期要求条件に含まれている要求項目を、あらかじめ定めた優先順位に基づいて、順次、削除していくことで、初期要求条件を緩和した緩和要求条件を段階的に１個以上生成する。
【００２５】
応答文生成部１３０は、要求条件決定部１４０から初期要求条件および緩和要求条件を受け取り、その要求条件に適合する情報をデータベース１８０から検索し、その要求条件に適合する情報が存在したならば、その要求条件に適合する情報の内容を表した文節列を応答文節列として生成し、また、その要求条件に適合する情報が存在しないならば、その要求条件に適合する情報が存在しないということを表す文節列を応答文節列として生成し、この生成した応答文節列を要求条件決定部１４０に返送する。
【００２６】
要求条件決定部１４０は、まず、言語理解部１１０から転送される要求条件を初期要求条件として記憶し、この初期要求条件を応答文生成部１３０に転送し、応答文生成部１３０から返送される応答文節列を初期要求条件の応答文節列として記憶する。また、この初期要求条件の応答文節列の長さを長さ基準として記憶する。次に、要求条件緩和生成部１２０から転送される１個以上の緩和要求条件から成る緩和要求条件集合を生成し、この緩和要求条件集合に含まれる各緩和要求条件を応答文生成部１３０に転送し、応答文生成部１３０から返送される応答文節列を各緩和要求条件の応答文節列として記憶する。
要求条件決定部１４０には、緩和要求条件の応答文節列の長さと長さ基準との差の上限を規定した出力量制約が前もって与えられおり、その出力量制約を記憶している。
要求条件決定部１４０は、次に、緩和要求条件集合に含まれ、且つ、その応答文節列の長さが出力量制約を満たすような緩和要求条件が存在する場合には、そのような緩和要求条件の中で最も弱い緩和要求条件を最終要求条件として決定し、最終要求条件の応答文節列を最終応答文節列として決定し、この最終要求条件を確認文生成部１５０に転送し、最終応答文節列を出力部１６０に転送する。一方、緩和要求条件集合の各応答文節列の長さが出力量制約を満たすような緩和要求条件が存在しない場合には、初期要求条件を最終要求条件として決定し、この最終要求条件の応答文節列を最終応答文節列として決定し、最終要求条件を確認文生成部１５０に転送し、最終応答文節列を出力部１６０に転送する。
図３は、この要求条件決定部１４０の処理フローチャートを示したものである。
【００２７】
確認文生成部１５０は、要求条件決定部１４０から転送される最終要求条件を確認するための確認文節列を生成し、その確認文節列を出力部１６０に転送する。
【００２８】
出力部１６０は、要求条件決定部１４０から転送される最終応答文節列または確認文生成部１５０から転送される確認文節列を、制御部１７０からの指令に従って利用者に対し出力する。
【００２９】
制御部１７０は、１００〜１６０の各部の動作を以下のように制御する。
（１）  言語理解生成部１１０が初期要求条件を要求条件決定部１４０に転送した後で、要求条件緩和生成部１２０が緩和要求条件を生成するように言語理解部１１０と要求条件緩和生成部１２０とを動作させる。
（２）  言語理解部１１０が初期要求条件を要求条件決定部１４０に転送し、要求条件緩和生成部１２０が緩和要求条件の全てを要求条件決定部１４０に転送した後、要求条件決定部１４０が初期要求条件と各緩和要求条件を応答文生成部１３０に転送するように、言語理解部１１０と要求条件緩和生成部１２０と応答文生成部１３０と要求条件決定部１４０とを動作させる。
（３）  応答文生成部１３０が初期要求条件の応答文節と各緩和要求条件の応答文節を要求条件決定部１４０に返送した後、要求条件決定部１４０が最終要求条件と最終応答文節列を決定するように、応答文生成部１３０と要求条件決定部１４０とを動作させる。
（４）  要求条件決定部１４０が最終要求条件を確認文生成部１５０に転送した後で、確認文生成部１５０が最終要求条件を確認するための文節列を生成するように、要求条件決定部１４０と確認文生成部１５０とを動作させる。
（５）  確認文生成部１５０が最終要求条件を確認するための文節列を出力部１６０に転送した後で、出力部１６０が最終要求条件を確認するための文節列を利用者に対し出力するように、確認文生成部１５０と出力部１６０とを動作させる。
（６）  出力部１６０が最終要求条件を確認するための確認文節列を利用者に対し出力した後に、言語理解部１１０から承認信号を受け取った場合には、出力部１６０が最終応答文節列を利用者に対し出力するように指令し、言語理解部１１０から否認信号を受け取った場合には、利用者が次に情報要求を意味する文節列を音声入力するのを待つように入力部１００に指令を送る。
【００３０】
以下に、具体例とともに本発明の実施例の詳細な動作について説明する。
言語理解部１１０が生成する要求条件は、スロット（項目）と値の対のリストとして表されるとする。例えば、利用者が、図９のような文節列（例６）を音声入力したとする（図４の例１）。この文節列は、情報要求を意味するので、言語理解部１１０は初期要求条件を生成する。ここで、「午後の」が「午前の」と誤認識きれたとする。このとき、初期要求条件は、図１０に示すようなスロットと値の対のリスト（例７）として表される。図１０において、場所、日、時間、情報種別がスロットであり、横浜市、明日、午前、天気というのが値である。
【００３１】
図１０の初期要求条件の内容は、「横浜市の明日午前の天気についての情報を要求する」という内容をもっており、図９の利用者が意図する情報要求の内容とは異なっている。
【００３２】
要求条件緩和生成部１２０は、図１０の初期要求条件を緩和した緩和要求条件を生成する。例えば、図１１の例８、図１２の例９の緩和要求条件を生成する。図１１の例８は、「横浜市の明日の天気に関する情報を要求する」という内容の緩和要求条件であり、図１２の例９は、「横浜市の天気に関する情報を要求する」という内容の緩和要求条件である。
【００３３】
図１０の例７の初期要求条件は、要求条件決定部１４０に転送され、引き続き、図１１と図１２の例８、例９の２つの緩和要求条件も要求条件決定部１４０に転送される。
【００３４】
要求条件決定部１４０は、まず、初期要求条件である図１０の例７を応答文生成部１３０に送信する。応答文生成部１３０は、図１０（例７）の初期要求条件に適合する情報をデータベース１８０から検索する。今、気象情報として、横浜市の明日の天気は、午前０時から午前３時まで晴れ、午前３時から明後日の午前０時まで雨という内容の情報が存在したとする。この場合、図１０（例７）の初期要求条件に適合する情報を表す文節列は、図１３の例１０のようになる。この文節列は、要求条件決定部１４０において、先の図１０の例７の初期要求条件の応答文節列として記憶される。
【００３５】
次に、要求条件決定部１４０は、図１１と図１２の例８、例９の２つの緩和要求条件を順次、応答文生成部１３０に転送する。図１１の例８の緩和要求条件に適合する情報の内容を表す文節列は、図１４の例１１のようになる。この文節列は、要求条件決定部１４０において、図１１の例８の緩和要求条件の応答文節列として記憶される。
【００３６】
次に、図１２の例９の緩和要求条件に適合する情報を検索する。この緩和要求条件は「日」のスロットが指定されていない。今、横浜市の天気に関する情報は、向こう一週間の情報しか存在しないとして、横浜市の向こう一週間は、明日の天気は、午前０時から午前３時まで晴れ、午前３時から明後日の午前０時まで雨であり、明後日から７日後までは通して曇りであるとする。このとき、図１２の例９の緩和要求条件に適合する情報の内容を表す文節列は、図１５の例１２のようになる。この文節列は、要求条件決定部１４０において、図１２の例９の緩和要求条件の応答文節列として記憶される。
【００３７】
要求条件決定部１４０は、図１０の例７の初期要求条件の応答文節列、すなわち、図１３の例１０の長さを長さ基準とする。図１３より、初期要求条件の応答文節列の長さは６であるので、長さ基準は６となる。
【００３８】
要求条件決定部１４０には、緩和要求条件の応答文節列の長さと長さ基準との差の上限を規定した出力量制約が前もって与えられている。たとえば、その出力量制約が、緩和要求条件の応答文節列の長さは長さ基準と等しいか小さくなくてはいけないという制約であったとする。
【００３９】
要求条件決定部１４０では、図１１と図１２の例８、例９の２つの緩和要求条件から、その応答文節列の長さが、長さ基準（ここでは６）と同じものを探す。図１１の例８の緩和要求条件の応答文節列である図１４の例１１の長さは６であり、図１２の例９の緩和要求条件の応答文節列である図１５の例１２の長さは１０である。結局、図１１の例８の緩和要求条件が最終要求条件として決定され、図１４の例１１の応答文節列が最終応答文節列として決定される。
【００４０】
確認文生成部１５０は、最終要求条件である図１１の例８の内容を確認するための文節列を確認文節列として生成する。その確認文節列は、図１６の例１３のようになる。
【００４１】
図１６の例１３の確認文節列は、出力部１６０によって利用者に対し出力され、利用者が、「はい」、「そうです」といった確認の承認を意味する文節列を入力してきた場合には、出力部１６０は、図１４の例１１の応答文節列を出力することになる。
【００４２】
従来の技術では、誤って生成された初期要求条件である図１０の例７の内容を確認するための確認文節列として、図１７の文節列（例１４）が出力されることになる（図５の例２）。
【００４３】
利用者の意図は、「横浜市の明日午後の天気についての情報を要求する」ことであり、図１７の例１４の確認文節列は利用者意図に矛盾するので、利用者は、確認を否認する意味の文節、たとえば、「いいえ」、「ちがいます」といった文節列を入力するであろう。結局、利用者の意図した情報は、利用者に対し出力されないことになる。結果として、誤認識に伴う利用者不満足度が増大することになる。
【００４４】
これに対し、本実施例では、緩和要求条件の図１１の例８が最終要求条件として決定され、確認文節列として、図１６の例１３が出力される。緩和要求条件の方が初期要求条件よりも小さな内容をもつので、それだけ含まれる誤りも少ない。したがって、初期要求条件の代わりに緩和要求条件を使うことにより、誤認識に伴う利用者不満足度を削減することができる。実際、図１６に示す例１３の確認文節列は、誤りの部分である「午前」という情報が、要求条件を緩和した結果、発話されないので、利用者は、図１６の例１３の確認文節列に対し、承認の意味をもつ文節列を発話するであろうと予想される。
【００４５】
一方、初期要求条件を緩和した緩和要求条件に適合する情報は、初期要求条件に適合する情報よりも多くなるので、緩和要求条件に適合する情報を利用者に対し出力すると、大量の情報が出力されてしまい、利用者に対する出力量の増大に伴う利用者不満足度が増すことになりかねないという問題がある。しかし、本発明の手法によれば、緩和要求条件の応答文節列の長さと長さ基準との差の上限を規定する出力量制約が与えられているので、利用者に対する出力量の増大に伴う利用者不満足度の増大を避けることができる。
【００４６】
実際、上述の具体例では、図１１の例８の緩和要求条件の応答文節列の長さは、図１４の例１１に示すように、図１０の例７の初期要求条件に対する図１３の例１０に示す応答文節列の長さと等しい。
【００４７】
出力量制約としては、様々なものを考えることができる。たとえば、緩和要求条件の応答文節列の長さと長さ基準との差が５以下であるという出力量制約が与えられているとする。この出力量制約を満たす緩和要求条件は、ここでは、図１１の例８と図１２の例９の２つが存在するが、図１２の例９の方が図１１の例８よりも弱い要求条件なので、結局、最終要求条件として図１２の例９が選ばれ、最終応答文節列として図１５の例１２が選ばれる。このとき、確認文節列は、図１８の例１５のものとなる。
【００４８】
図１２の例９の緩和要求条件は、図１１の例８の緩和要求条件よりもさらに弱い要求条件であるので、確認文節列に誤りが含まれる可能性はさらに小さくなり、誤認識に伴う利用者不満足度をさらに軽減することができる。なおかつ、出力量制約を満たしているという意味で、利用者に対する出力量の増大に伴う利用者不満足度の増大を避けることができる。
【００４９】
以上、本発明の実施の形態を説明したが、図１の構成は一般にコンピュータシステムを利用して構築される。この場合、１００〜１６０などの各部の機能（処理ステップ）を実現するプログラムを、コンピュータで実行可能な言語で記述し、コンピュータで読み取り可能な記録媒体、例えば、フロッピーディスク、ＣＤ−ＲＯＭ、メモリカード等に記録して提供することが可能である。
【００５０】
また、本発明は、上記の実施例に限定されることなく、特許請求の範囲で種々の変更あるいは応用が可能であることは云うまでもない。
【００５１】
【発明の効果】
以上説明したように、本発明の要求確認型情報提供装置によれば、利用者が情報要求を意味する文節列を音声入力するときに、初期要求条件の内容を全て確認することなく、最終要求条件として決定された緩和要求条件の内容を確認することによって、誤認識に伴う利用者不満足度を軽減させ、また、利用者が確認の承認を入力した後、最終要求条件として決定された緩和要求条件の応答文節列を出力することによって、利用者に対する出力量の増大に伴う利用者不満足度の増大を避けることが可能となる。
【図面の簡単な説明】
【図１】  本発明の装置構成例を示すブロック図である。
【図２】  要求確認型情報提供サービスシステムの動作シーケンス例を示す図である。
【図３】  図１の要求条件決定部の処理フローの概要を示す図である。
【図４】  情報要求文節例の一例（例１）である。
【図５】  初期要求条件に対する確認文節列の一例（例２）である。
【図６】  初期要求条件に対する確認文節列の一例（例３）である。
【図７】  緩和要求条件に対する応答文節列の一例（例４）である。
【図８】  緩和要求条件に対する応答文節列の一例（例５）である。
【図９】  情報要求文節列の一例（例６）である。
【図１０】  誤認生成された初期要求条件の一例（例７）である。
【図１１】  図１０の初期要求条件を緩和した緩和要求条件の一例（例８）である。
【図１２】  同じく緩和要求条件の一例（例９）である。
【図１３】  図１０の初期要求条件に対する応答文節列の一例（例１０）である。
【図１４】  図１１の緩和要求条件に対する応答文節列の一例（例１１）である。
【図１５】  図１２の緩和要求条件に対する応答文節列の一例（例１２）である。
【図１６】  最終要求条件と決定された図１１の緩和要求条件に対する確認文節列の一例（例１３）である。
【図１７】  図１０の初期要求条件に対する確認文節列の一例（例１４）である。
【図１８】  図１２の緩和要求条件を最終要求条件としたときの確認文節列の一例（例１５）である。
【符号の説明】
１００  入力部
１１０  言語理解部
１２０  要求条件緩和生成部
１３０  応答文生成部
１４０  要求条件決定部
１５０  確認文生成部
１６０  出力部
１７０  制御部
１８０  データベース
【図１】
0003646783.tif 000002
【図２】
0003646783.tif 000003
【図３】
0003646783.tif 000004
【図４】
0003646783.tif 000005
【図５】
0003646783.tif 000006
【図６】
0003646783.tif 000007
【図７】
0003646783.tif 000008
【図８】
0003646783.tif 000009
【図９】
0003646783.tif 000010
【図１０】
0003646783.tif 000011
【図１１】
0003646783.tif 000012
【図１２】
0003646783.tif 000013
【図１３】
0003646783.tif 000014
【図１４】
0003646783.tif 000015
【図１５】
0003646783.tif 000016
【図１６】
0003646783.tif 000017
【図１７】
0003646783.tif 000018
【図１８】
0003646783.tif 000019