JP2001249931A - 要求確認型情報提供方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 利用者が入力する情報要求の誤認識や、情報
量増大に伴う利用者の不満足度を軽減する。 【解決手段】 利用者側が入力する情報要求から初期要
求条件を生成する手段１１０と、初期要求条件を緩和し
た緩和要求条件を生成する手段１２０と、初期要求条件
および緩和要求条件に対する応答文節列を生成する手段
１３０と、初期要求条件に対する応答文節列の長さを長
さ基準として、緩和要求条件に応答文節列の長さが予め
定めた出力量制約を満足する場合、当該緩和要求条件を
最終要求条件、その応答文節列を最終応答文節列と決定
する手段１４０と、最終要求条件を確認するための確認
文節列を生成する手段１５０と、生成された確認文節列
を利用者側に出力し、利用者側から確認の承認を意味す
る文節列が入力されると、最終応答文節列を利用者側に
出力する手段１６０を設ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は要求確認型情報提供
サービスシステムに係り、詳しくは、利用者が情報要求
を意味する文節列を文字列または音声として入力すると
き、該情報要求を確認するための文節列を文字列または
音声として利用者に対し出力し、利用者が確認の承認を
意味する文節列を文字列または音声として入力する場合
には、先の情報要求を満たす情報の内容を表した文節列
を文字列または音声として利用者に対し出力し、利用者
が確認の否認を意味する文節列を文字列または音声とし
て入力する場合には、利用者が新たな情報要求を意味す
る文節列を文字列または音声として入力するのを待つよ
うな要求確認型情報提供方法および装置に関するもので
ある。

【０００２】

【従来の技術】要求確認型情報提供サービスシステムで
は、図２に動作シーケンス例を示すように、例えば、気
象情報、テレビ番組表、スケジュール表、交通機関の時
刻表、といった様々な情報を蓄積したデータベースがあ
るとき、データベースに蓄積された情報を要求すること
を意味する文節列を、利用者が計算機端末のキーボー
ド、マウス、音声認識装置、或いは、これらの組み合わ
せを介して、文字列または音声として入力すると、情報
提供側は、まず、利用者の情報要求を確認するための文
節列を、計算機端末のディスプレイ、プリンタ、タイプ
ライタ、音声合成装置、或いは、これらの組み合わせを
介して、利用者に対し出力し、利用者が確認の承認を意
味する文節列を、同様に文字列または音声として入力す
る場合には、情報提供側は、情報要求を満たす情報の内
容を表した文節列を、同様に文字列または音声として利
用者に対し出力し、利用者が確認の否認を意味する文節
列を、同様に文字列または音声として入力する場合に
は、情報提供側は、利用者が情報要求を意味する文節列
を入力するのを待つような、動作シーケンスをとる。な
お、図２では、利用者が確認の否認を意味する文節列を
入力した場合のシーケンスは省略してある。

【０００３】従来、この種の要求確認型情報提供サービ
スシステムにおいては、情報提供側は、利用者が情報要
求を意味した文節列を入力したときに、情報要求の内容
を表す要求条件を生成し、その要求条件の内容の全てを
確認するための文節列を利用者に対し出力し、利用者が
確認の承認を意味する文節列が入力した時点で、その要
求条件に適合する情報の内容を表す文節列を利用者に対
し出力していた。

【０００４】

【発明が解決しようとする課題】従来の技術では、利用
者により入力された文節列から生成した要求条件の内容
を全て確認するための文節列を出力する。その後、利用
者が確認の承認を意味する文節列を入力した場合に、要
求条件に適合する情報の内容を表す文節列を利用者に対
し出力する。要求条件に適合する情報が空（無し）の場
合は、要求条件に適合する情報の内容が空であることを
表す文節列を利用者に対し出力する。

【０００５】従来の技術では、利用者が入力した文節列
から生成した要求条件の内容を全て確認するため、誤認
識に伴う利用者不満度を増大させるという問題がある。
以下に、これについて説明する。

【０００６】利用者が文字列または音声として入力した
文節列から要求条件を生成する際には、文字列または音
声の誤認識などの理由により、利用者が意図する要求条
件とは異なる要求条件が生成される場合がある。その場
合には、システムが確認のために出力する要求条件の内
容は、利用者が意図する情報要求と異なるので、利用者
は確認の否認を意味する文節列を入力することになり、
利用者の情報要求を満たす情報は利用者に出力されな
い。

【０００７】一般に、確認する要求条件の内容が多いほ
ど、その中に誤りが含まれる可能性が高くなり、利用者
が確認を否認する可能性が高くなり、利用者が要求する
情報が利用者に対し出力されない可能性が高くなり、誤
認誠に伴う利用者の不満足度は増すことになる。

【０００８】もし、利用者入力から生成された要求条件
（以下、初期要求条件）を緩和した要求条件（以下、緩
和要求条件）をつくり、その緩和要求条件の内容を利用
者に対し確認するとすると、緩和要求条件の内容は、初
期要求条件の内容よりも小さいので、誤りが含まれる可
能性は小さくなり、利用者が確認を否認する可能性が小
さくなり、誤認識に伴う利用者の不満足度が増すことを
避けることができる。

【０００９】この一方で、要求条件を緩和すると、緩和
要求条件は初期要求条件より弱い条件なので、緩和要求
条件に適合する情報の量は、初期要求条件に適合する情
報の量よりも大きくなる。したがって、確認が承認され
た後、利用者に対し出力される情報の量が増えることに
なる。利用者が要求してもいない情報が大量に利用者に
対し出力されると、利用者に対する出力量の増大に伴う
利用者の不満足度が増すおそれがある。

【００１０】しかし、初期要求条件に適合する情報の内
容を表した文節列の長さを長さ基準としたとき、初期要
求条件を緩和した緩和要求条件に適合する情報の内容を
表した文節列の長さが、長さ基準と比べて、等しい、或
いは、利用者の不満足度を増すほどには長くならないと
いった出力量の上限を規定した制約を満たす場合が存在
する。この場合には、緩和要求条件の内容を確認するこ
とによって、利用者が確認を否認する可能性が小さくな
り、且つ、利用者に対し出力される情報の量も、文節列
の長さという観点からみたときに、増大しない。したが
って、初期要求条件の代わりに緩和要求条件を使うこと
により、誤認識に伴う利用者の不満足度が軽減し、なお
かつ、利用者に対する出力量の増大に伴う利用者不満足
度が増すことを避けることもできる。

【００１１】従来の技術では、このように利用者に対す
る出力量の上限を規定する制約が満たされているような
場合であっても、初期要求条件の内容を全て確認しよう
とするので、誤認識に伴う利用者の不満足度の増大を避
けることができない。

【００１２】例えば、気象情報に関する情報要求につい
て考える。利用者が、図４に示す文節列（例１）を入力
したとする。利用者の意図は、「横浜市の明日午後の天
気についての情報を要求する」ということである。この
とき、文字列または音声の認識誤りなどの理由により、
「午後の」が「午前の」と誤って認識され、「横浜市の
明日午前の天気を要求する」という初期の要求条件Ａが
生成される場合を想定する。

【００１３】従来の技術では、「横浜市の明日午前の天
気を要求する」という初期要求条件Ａの内容の全てを確
認するための、図５に示すような文節列（例２）を出力
する。これは、利用者意図とは異なっているので、利用
者は、「いいえ」、「ちがいます」といった否認のため
の文節列を入力する。否認を意味する文節列が入力され
たので、次の利用者からの情報要求を待つ状態になる。
利用者は横浜市の明日午後の天気を知るために、再度、
情報要求を繰り返さなければならず、誤認識に伴う利用
者不満足度が増す。

【００１４】今、気象情報として、横浜市の明日の天気
は、午前０時から午前３時まで晴れ、午前３時から明後
日の午前０時まで雨という内容の情報が存在したとす
る。誤って生成された初期の要求条件Ａに適合する情報
を文節列で表すと、図６のような文節列（例３）にな
る。すなわち、午前であることが初期の要求条件Ａには
含まれているので、午前０時から正午までの天気を表す
文節列となっている。

【００１５】ここで、誤って生成された「横浜市の明日
午前の天気を要求する」という初期要求条件Ａを緩和し
た「横浜市の明日の天気を要求する」という緩和要求条
件Ｂについて考える。緩和要求条件Ｂの内容を確認する
とすると、図７に示すような文節列（例４）を出力する
ことになる。また、緩和要求条件Ｂに適合する情報の内
容を文節列で表すと、図８のような文節列（例５）にな
る。

【００１６】緩和要求条件Ｂの内容を確認するための文
節列である例４（図７）は、「午前の」という部分を含
まないだけ、初期要求条件Ａの内容を確認するための文
節である例２（図５）と比べて、誤りが含まれている可
能性が小さいので、利用者が確認を否認する可能性が小
さくなり、誤認識に伴う利用者不満足度を減少させるこ
とができる。しかも、緩和要求条件Ｂに適合する情報を
表した文節列である例５（図８）の長さは６であり、初
期要求条件Ａに適合する情報を表した文節列である例３
（図６）の長さも６であり、両方の長さは等しい。した
がって、初期要求条件Ａの場合に比べて、緩和要求条件
Ｂの場合の方が、もし確認の承認が行われた場合に、利
用者に対する出力量の増大に伴う利用者不満足度が増加
するとはいえない。

【００１７】こういった緩和要求条件Ｂが存在するにも
かかわらず、従来の技術では、常に要求条件Ａの内容を
全て確認し、緩和要求条件Ｂを使えば避けることのでき
るはずの利用者不満足度の増大を避けることができない
という問題がある。

【００１８】本発明は、要求確認型情報提供サービスシ
ステムにおいて、上述のような従来の技術の問題点に鑑
みなされたもので、従来の技術では、利用者が入力する
情報要求から生成される初期要求条件の内容を全て確認
する文節列を出力する場合であっても、初期要求条件を
緩和した緩和要求条件の内容を確認するための文節列を
生成することによって、誤認識に伴う利用者の不満足度
を軽減させ、且つ、緩和要求条件に適合する情報の出力
量増大に伴う利用者の不満足度の増大を避けることを可
能とする要求確認型情報提供方法おわび装置を提供する
ことを目的とする。

【００１９】

【課題を解決するための手段】本発明の一実施例では、
利用者からの情報要求、確認の承認、確認の否認を受け
取る入力手段、利用者が情報要求を意味する文節列を入
力するとき、情報要求の内容を表す要求条件を初期要求
条件として生成し、利用者が確認の承認を意味する文節
列を入力するとき、承認信号を生成し、利用者が確認の
否認を意味する文節列を入力するとき、否認信号を生成
する言語理解手段、初期要求条件を段階的に緩和するこ
とによって、緩和要求条件を１個以上生成する要求条件
緩和手段、初期要求条件および緩和要求条件に適合する
情報を検索し、その要求条件に適合する情報が存在する
場合は、その要求条件に適合する情報の内容を表した文
節列を、その要求条件に適合する情報が存在しない場
合、その要求条件に適合する情報が存在しないというこ
とを表す文節列を、それぞれ応答文節列として生成する
応答文生成手段、初期要求条件、緩和要求条件、及び、
それらから生成される応答文節列を対応づけて保持し、
初期要求条件の応答文節列の長さを長さ基準として、緩
和要求条件の応答文節列の長さと長さ基準との差の上限
を規定した出力量制約により、緩和要求条件の応答文節
列の長さが出力量制約を満たすような緩和要求条件が存
在する場合には、そのような緩和要求条件の中で最も弱
い緩和要求条件を最終要求条件として決定し、その応答
文節列の長さが出力量制約を満たすような緩和要求条件
が存在しない場合には、初期要求条件を最終要求条件と
して決定し、この決定した最終要求条件の応答文節列を
最終応答文節列として決定する要求条件決定手段、最終
要求条件を確認するための確認文節列を生成する確認文
生成手段、最終応答文節列または確認文生成手段５０が
生成する確認文節列を利用者に対し出力する出力手段、
これら各手段の動作を制御する制御手段などを具備す
る。

【００２０】本発明では、利用者が入力する情報要求か
ら初期要求条件を生成し、初期要求条件を緩和して得ら
れた緩和要求条件の集合を緩和要求条件集合として生成
し、初期要求条件が適合する情報の内容を表した文節列
の長さを長さ基準とし、緩和要求条件集合に含まれる各
緩和要求条件に適合する情報の内容を表す文節列を各緩
和要求条件の応答文節列とし、緩和要求条件の応答文節
列の長さと長さ基準との差の上限を規定した出力量制約
により、緩和要求条件の応答文節列の長さが出力量制約
を満たすような緩和要求条件が存在するなら、その緩和
要求条件を最終要求条件として決定する。この結果、初
期要求条件の内容を全て確認することなく、最終要求条
件として決定された緩和要求条件の内容を確認すること
によって、誤認識に伴う利用者不満足度を軽減させ、利
用者が確認の承認を入力した後、最終要求条件として決
定された緩和要求条件の応答文節列を出力することによ
って、利用者に対する出力量の増大に伴う利用者不満足
度の増大を避けることが可能となる。

【００２１】

【発明の実施の形態】以下、本発明の一実施の形態につ
いて図面により詳細に説明する。図１は、本発明による
要求確認型情報提供装置の構成例を示す。本要求確認型
情報提供装置は、入力部１００、言語理解部１１０、要
求条件緩和生成部１２０、応答文生成部１３０、要求条
件決定部１４０、確認文生成部１５０、出力部１６０、
制御部１７０、及びデータベース１８０により構成され
る。入力部１００と出力部１６０は、通信回線などによ
り利用者の端末と接続されるが、図１では省略してあ
る。なお、本発明による要求確認型情報提供方法は、基
本的には図１の１００〜１６０などを処理ステップで置
き替えればよい。

【００２２】入力部１００は、利用者が計算機端末のキ
ーボード、マウス、音声認識装置、或いは、これらの組
み合せを介して、文字列または音声として入力する、情
報要求または確認の承認または確認の否認を意味する文
節列を取り込む。

【００２３】言語理解部１１０は、利用者が情報要求を
意味する文節列を文字列または音声として入力するとき
は、情報要求の内容を表す要求条件を初期要求条件とし
て生成し、この生成した初期要求条件を要求条件緩和生
成部１２０と要求条件決定部１４０に転送する。また、
言語理解部１１０は、利用者が確認の承認を意味する文
節列を文字列または音声として入力するとき承認信号を
生成し、利用者が確認の否認を意味する文節列を文字列
または音声として入力するとき否認信号を生成し、この
生成した承認信号あるいは否認信号を制御部１７０に送
る。

【００２４】要求条件緩和生成部１２０は、言語理解部
１１０から転送されてきた初期要求条件を段階的に緩和
することによって、初期要求条件を緩和した緩和要求条
件を１個以上生成し、この生成した緩和要求要求条件を
要求条件決定部１４０に転送する。この要求条件緩和生
成部１２０では、初期要求条件に含まれている要求項目
を、例えば、あらかじめ定めた優先順位に基づいて、順
次、削除していくことで、初期要求条件を緩和した緩和
要求条件を段階的に１個以上生成する。

【００２５】応答文生成部１３０は、要求条件決定部１
４０から初期要求条件および緩和要求条件を受け取り、
その要求条件に適合する情報をデータベース１８０から
検索し、その要求条件に適合する情報が存在したなら
ば、その要求条件に適合する情報の内容を表した文節列
を応答文節列として生成し、また、その要求条件に適合
する情報が存在しないならば、その要求条件に適合する
情報が存在しないということを表す文節列を応答文節列
として生成し、この生成した応答文節列を要求条件決定
部１４０に返送する。

【００２６】要求条件決定部１４０は、まず、言語理解
部１１０から転送される要求条件を初期要求条件として
記憶し、この初期要求条件を応答文生成部１３０に転送
し、応答文生成部１３０から返送される応答文節列を初
期要求条件の応答文節列として記憶する。また、この初
期要求条件の応答文節列の長さを長さ基準として記憶す
る。次に、要求条件緩和生成部１２０から転送される１
個以上の緩和要求条件から成る緩和要求条件集合を生成
し、この緩和要求条件集合に含まれる各緩和要求条件を
応答文生成部１３０に転送し、応答文生成部１３０から
返送される応答文節列を各緩和要求条件の応答文節列と
して記憶する。要求条件決定部１４０には、緩和要求条
件の応答文節列の長さと長さ基準との差の上限を規定し
た出力量制約が前もって与えられおり、その出力量制約
を記憶している。要求条件決定部１４０は、次に、緩和
要求条件集合に含まれ、且つ、その応答文節列の長さが
出力量制約を満たすような緩和要求条件が存在する場合
には、そのような緩和要求条件の中で最も弱い緩和要求
条件を最終要求条件として決定し、最終要求条件の応答
文節列を最終応答文節列として決定し、この最終要求条
件を確認文生成部１５０に転送し、最終応答文節列を出
力部１６０に転送する。一方、緩和要求条件集合の各応
答文節列の長さが出力量制約を満たすような緩和要求条
件が存在しない場合には、初期要求条件を最終要求条件
として決定し、この最終要求条件の応答文節列を最終応
答文節列として決定し、最終要求条件を確認文生成部１
５０に転送し、最終応答文節列を出力部１６０に転送す
る。図３は、この要求条件決定部１４０の処理フローチ
ャートを示したものである。

【００２７】確認文生成部１５０は、要求条件決定部１
４０から転送される最終要求条件を確認するための確認
文節列を生成し、その確認文節列を出力部１６０に転送
する。

【００２８】出力部１６０は、要求条件決定部１４０か
ら転送される最終応答文節列または確認文生成部１５０
から転送される確認文節列を、制御部１７０からの指令
に従って利用者に対し出力する。

【００２９】制御部１７０は、１００〜１６０の各部の
動作を以下のように制御する。 （１） 言語理解生成部１１０が初期要求条件を要求条
件決定部１４０に転送した後で、要求条件緩和生成部１
２０が緩和要求条件を生成するように言語理解部１１０
と要求条件緩和生成部１２０とを動作させる。 （２） 言語理解部１１０が初期要求条件を要求条件決
定部１４０に転送し、要求条件緩和生成部１２０が緩和
要求条件の全てを要求条件決定部１４０に転送した後、
要求条件決定部１４０が初期要求条件と各緩和要求条件
を応答文生成部１３０に転送するように、言語理解部１
１０と要求条件緩和生成部１２０と応答文生成部１３０
と要求条件決定部１４０とを動作させる。 （３） 応答文生成部１３０が初期要求条件の応答文節
と各緩和要求条件の応答文節を要求条件決定部１４０に
返送した後、要求条件決定部１４０が最終要求条件と最
終応答文節列を決定するように、応答文生成部１３０と
要求条件決定部１４０とを動作させる。 （４） 要求条件決定部１４０が最終要求条件を確認文
生成部１５０に転送した後で、確認文生成部１５０が最
終要求条件を確認するための文節列を生成するように、
要求条件決定部１４０と確認文生成部１５０とを動作さ
せる。 （５） 確認文生成部１５０が最終要求条件を確認する
ための文節列を出力部１６０に転送した後で、出力部１
６０が最終要求条件を確認するための文節列を利用者に
対し出力するように、確認文生成部１５０と出力部１６
０とを動作させる。 （６） 出力部１６０が最終要求条件を確認するための
確認文節列を利用者に対し出力した後に、言語理解部１
１０から承認信号を受け取った場合には、出力部１６０
が最終応答文節列を利用者に対し出力するように指令
し、言語理解部１１０から否認信号を受け取った場合に
は、利用者が次に情報要求を意味する文節列を文字列ま
た音声として入力するのを待つように入力部１００に指
令を送る。

【００３０】以下に、具体例とともに本発明の実施例の
詳細な動作について説明する。言語理解部１１０が生成
する要求条件は、スロットと値の対のリストとして表さ
れるとする。例えば、利用者が、図９のような文節列
（例６）を入力したとする（図５の例１）。この文節列
は、情報要求を意味するので、言語理解部１１０は初期
要求条件を生成する。ここで、「午後の」が「午前の」
と誤認識きれたとする。このとき、初期要求条件は、図
１０に示すようなスロットと値の対のリスト（例７）と
して表される。図１０において、場所、日、時間、情報
種別がスロットであり、横浜市、明日、午前、天気とい
うのが値である。

【００３１】図１０の初期要求条件の内容は、「横浜市
の明日午前の天気についての情報を要求する」という内
容をもっており、図９の利用者が意図する情報要求の内
容とは異なっている。

【００３２】要求条件緩和生成部１２０は、図１０の初
期要求条件を緩和した緩和要求条件を生成する。例え
ば、図１１の例８、図１２の例９の緩和要求条件を生成
する。図１１の例８は、「横浜市の明日の天気に関する
情報を要求する」という内容の緩和要求条件であり、図
１２の例９は、「横浜市の天気に関する情報を要求す
る」という内容の緩和要求条件である。

【００３３】図１０の例７の初期要求条件は、要求条件
決定部１４０に転送され、引き続き、図１１と図１２の
例８、例９の２つの緩和要求条件も要求条件決定部１４
０に転送される。

【００３４】要求条件決定部１４０は、まず、初期要求
条件である図１０の例７を応答文生成部１３０に送信す
る。応答文生成部１３０は、図１０（例７）の初期要求
条件に適合する情報をデータベース１８０から検索す
る。今、気象情報として、横浜市の明日の天気は、午前
０時から午前３時まで晴れ、午前３時から明後日の午前
０時まで雨という内容の情報が存在したとする。この場
合、図１０（例７）の初期要求条件に適合する情報を表
す文節列は、図１３の例１０のようになる。この文節列
は、要求条件決定部１４０において、先の図１０の例７
の初期要求条件の応答文節列として記憶される。

【００３５】次に、要求条件決定部１４０は、図１１と
図１２の例８、例９の２つの緩和要求条件を順次、応答
文生成部１３０に転送する。図１１の例８の緩和要求条
件に適合する情報の内容を表す文節列は、図１４の例１
１のようになる。この文節列は、要求条件決定部１４０
において、図１１の例８の緩和要求条件の応答文節列と
して記憶される。

【００３６】次に、図１２の例９の緩和要求条件に適合
する情報を検索する。この緩和要求条件は「日」のスロ
ットが指定されていない。今、横浜市の天気に関する情
報は、向こう一週間の情報しか存在しないとして、横浜
市の向こう一週間は、明日の天気は、午前０時から午前
３時まで晴れ、午前３時から明後日の午前０時まで雨で
あり、明後日から７日後までは通して曇りであるとす
る。このとき、図１２の例９の緩和要求条件に適合する
情報の内容を表す文節列は、図１５の例１２のようにな
る。この文節列は、要求条件決定部１４０において、図
１２の例９の緩和要求条件の応答文節列として記憶され
る。

【００３７】要求条件決定部１４０は、図１０の例７の
初期要求条件の応答文節列、すなわち、図１３の例１０
の長さを長さ基準とする。図１３より、初期要求条件の
応答文節列の長さは６であるので、長さ基準は６とな
る。

【００３８】要求条件決定部１４０には、緩和要求条件
の応答文節列の長さと長さ基準との差の上限を規定した
出力量制約が前もって与えられている。たとえば、その
出力量制約が、緩和要求条件の応答文節列の長さは長さ
基準と等しいか小さくなくてはいけないという制約であ
ったとする。

【００３９】要求条件決定部１４０では、図１１と図１
２の例８、例９の２つの緩和要求条件から、その応答文
節列の長さが、長さ基準（ここでは６）と同じものを探
す。図１１の例８の緩和要求条件の応答文節列である図
１４の例１１の長さは６であり、図１２の例９の緩和要
求条件の応答文節列である。図１５の例１２の長さは１
０である。結局、図１１の例８の緩和要求条件が最終要
求条件として決定され、図１４の例１１の応答文節列が
最終応答文節列として決定される。

【００４０】確認文生成部１５０は、最終要求条件であ
る図１１の例８の内容を確認するための文節列を確認文
節列として生成する。その確認文節列は、図１６の例１
３のようになる。

【００４１】図１６の例１３の確認文節列は、出力部１
６０によって利用者に対し出力され、利用者が、「は
い」、「そうです」といった確認の承認を意味する文節
列を入力してきた場合には、出力部１６０は、図１４の
例１１の応答文節列を出力することになる。

【００４２】従来の技術では、誤って生成された初期要
求条件である図１０の例７の内容を確認するための確認
文節列として、図１７の文節列（例１４）が出力される
ことになる（図５の例２）。

【００４３】利用者の意図は、「横浜市の明日午後の天
気についての情報を要求する」ことであり、図１７の例
１４の確認文節列は利用者意図に矛盾するので、利用者
は、確認を否認する意味の文節、たとえば、「いい
え」、「ちがいます」といった文節列を入力するであろ
う。結局、利用者の意図した情報は、利用者に対し出力
されないことになる。結果として、誤認識に伴う利用者
不満足度が増大することになる。

【００４４】これに対し、本実施例では、緩和要求条件
の図１１の例８が最終要求条件として決定され、確認文
節列として、図１６の例１３が出力される。緩和要求条
件の方が初期要求条件よりも小さな内容をもつので、そ
れだけ含まれる誤りも少ない。したがって、初期要求条
件の代わりに緩和要求条件を使うことにより、誤認識に
伴う利用者不満足度を削減することができる。実際、図
１６に示す例１３の確認文節列は、誤りの部分である
「午前」という情報が、要求条件を緩和した結果、発話
されないので、利用者は、図１６の例１３の確認文節列
に対し、承認の意味をもつ文節列を発話するであろうと
予想される。

【００４５】一方、初期要求条件を緩和した緩和要求条
件に適合する情報は、初期要求条件に適合する情報より
も多くなるので、緩和要求条件に適合する情報を利用者
に対し出力すると、大量の情報が出力されてしまい、利
用者に対する出力量の増大に伴う利用者不満足度が増す
ことになりかねないという問題がある。しかし、本発明
の手法によれば、緩和要求条件の応答文節列の長さと長
さ基準との差の上限を規定する出力量制約が与えられて
いるので、利用者に対する出力量の増大に伴う利用者不
満足度の増大を避けることができる。

【００４６】実際、上述の具体例では、図１１の例８の
緩和要求条件の応答文節列の長さは、図１４の例１１に
示すように、図１０の例７の初期要求条件に対する図１
３の例１０に示す応答文節列の長さと等しい。

【００４７】出力量制約としては、様々なものを考える
ことができる。たとえば、緩和要求条件の応答文節列の
長さと長さ基準との差が５以下であるという出力量制約
が与えられているとする。この出力量制約を満たす緩和
要求条件は、ここでは、図１１の例８と図１２の例９の
２つが存在するが、図１２の例９の方が図１１の例８よ
りも弱い要求条件なので、結局、最終要求条件として図
１２の例９が選ばれ、最終応答文節列として図１５の例
１２が選ばれる。このとき、確認文節列は、図１８の例
１５のものとなる。

【００４８】図１２の例９の緩和要求条件は、図１１の
例８の緩和要求条件よりもさらに弱い要求条件であるの
で、確認文節列に誤りが含まれる可能性はさらに小さく
なり、誤認識に伴う利用者不満足度をさらに軽減するこ
とができる。なおかつ、出力量制約を満たしているとい
う意味で、利用者に対する出力量の増大に伴う利用者不
満足度の増大を避けることができる。

【００４９】以上、本発明の実施の形態を説明したが、
図１の構成は一般にコンピュータシステムを利用して構
築される。この場合、１００〜１６０などの各部の機能
（処理ステップ）を実現するプログラムを、コンピュー
タで実行可能な言語で記述し、コンピュータで読み取り
可能な記録媒体、例えば、フロッピー（登録商標）ディ
スク、ＣＤ−ＲＯＭ、メモリカード等に記録して提供す
ることが可能である。

【００５０】また、本発明は、上記の実施例に限定され
ることなく、特許請求の範囲で種々の変更あるいは応用
が可能であることは云うまでもない。

【００５１】

【発明の効果】以上説明したように、本発明の要求確認
型情報提供方法および装置によれば、利用者が情報要求
を意味する文節列を文字列または音声として入力すると
きに、初期要求条件の内容を全て確認することなく、最
終要求条件として決定された緩和要求条件の内容を確認
することによって、誤認識に伴う利用者不満足度を軽減
させ、また、利用者が確認の承認を入力した後、最終要
求条件として決定された緩和要求条件の応答文節列を出
力することによって、利用者に対する出力量の増大に伴
う利用者不満足度の増大を避けることが可能となる。

【図面の簡単な説明】

【図１】本発明の装置構成例を示すブロック図である。

【図２】要求確認型情報提供サービスシステムの動作シ
ーケンス例を示す図である。

【図３】図１の要求条件決定部の処理フローの概要を示
す図である。

【図４】情報要求文節例の一例（例１）である。

【図５】初期要求条件に対する確認文節列の一例（例
２）である。

【図６】初期要求条件に対する確認文節列の一例（例
３）である。

【図７】緩和要求条件に対する応答文節列の一例（例
４）である。

【図８】緩和要求条件に対する応答文節列の一例（例
５）である。

【図９】情報要求文節列の一例（例６）である。

【図１０】誤認生成された初期要求条件の一例（例７）
である。

【図１１】図１０の初期要求条件を緩和した緩和要求条
件の一例（例８）である。

【図１２】同じく緩和要求条件の一例（例９）である。

【図１３】図１０の初期要求条件に対する応答文節列の
一例（例１０）である。

【図１４】図１１の緩和要求条件に対する応答文節列の
一例（例１１）である。

【図１５】図１２の緩和要求条件に対する応答文節列の
一例（例１２）である。

【図１６】最終要求条件と決定された図１１の緩和要求
条件に対する確認文節列の一例（例１３）である。

【図１７】図１０の初期要求条件に対する確認文節列の
一例（例１４）である。

【図１８】図１２の緩和要求条件を最終要求条件とした
ときの確認文節列の一例（例１５）である。

【符号の説明】

１００ 入力部 １１０ 言語理解部 １２０ 要求条件緩和生成部 １３０ 応答文生成部 １４０ 要求条件決定部 １５０ 確認文生成部 １６０ 出力部 １７０ 制御部 １８０ データベース

───────────────────────────────────────────────────── フロントページの続き (72)発明者 中野 幹生 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 宮崎 昇 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 安田 宜仁 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B075 PP02 PP03 PP07 PP24 PP26 PQ02 PQ04

Claims (6)

【特許請求の範囲】
1. 【請求項１】 利用者側が情報要求を意味する文節列を
   入力すると、前記情報要求の内容を確認するための確認
   文節列を利用者側に出力し、利用者側が確認の承認を意
   味する文節列を入力すると、前記情報要求に対する応答
   文節列を利用者側に出力する要求確認型情報提供方法に
   おいて、 利用者側が入力する情報要求から初期要求条件を生成す
   るステップと、 前記初期要求条件を緩和した緩和要求条件を生成するス
   テップと、 前記初期要求条件に対する応答文節列、前記緩和要求条
   件に対する応答文節列を生成するステップと、 前記初期要求条件に対する応答文節列の長さを長さ基準
   として、前記緩和要求条件に対する応答文節列の長さが
   予め定めた出力量制約を満足する場合、当該緩和要求条
   件を最終要求条件と決定し、当該緩和要求条件に対する
   応答文節列を最終応答文節列と決定するステップと、 前記最終要求条件を確認するための確認文節列を生成す
   るステップと、 前記生成された確認文節列を利用者側に出力し、利用者
   側から確認の承認を意味する文節列が入力されると、前
   記最終応答文節列を利用者側に出力するステップと、を
   有することを特徴とする要求確認型情報提供方法。
2. 【請求項２】 請求項１記載の要求確認型情報提供方法
   において、応答文節列の長さが出力量制約を満足するの
   に対応する、緩和要求条件が複数存在する場合、その中
   で最も弱い緩和要求条件を最終要求条件と決定すること
   を特徴とする要求確認型情報提供方法。
3. 【請求項３】 請求項１、２記載の要求確認型情報提供
   方法において、応答文節列の長さが出力量制約を満足す
   るのに対応する、緩和要求条件が存在しない場合、初期
   要求条件を最終要求条件と決定することを特徴とする要
   求確認型情報提供方法。
4. 【請求項４】 利用者側が情報要求を意味する文節列を
   入力すると、前記情報要求の内容を確認するための確認
   文節列を利用者側に出力し、利用者側が確認の承認を意
   味する文節列を入力すると、前記情報要求に対する応答
   文節列を利用者側に出力する要求確認型情報提供装置に
   おいて、 利用者側が入力する情報要求から初期要求条件を生成す
   る第１手段と、 前記初期要求条件を緩和した緩和要求条件を生成する第
   ２手段と、 前記初期要求条件に対する応答文節列、前記緩和要求条
   件に対する応答文節列を生成する第３手段と、 前記初期要求条件に対する応答文節列の長さを長さ基準
   として、前記緩和要求条件に対する応答文節列の長さが
   予め定めた出力量制約を満足する場合、当該緩和要求条
   件を最終要求条件と決定し、当該緩和要求条件に対する
   応答文節列を最終応答文節列と決定する第４手段と、 前記最終要求条件を確認するための確認文節列を生成す
   る第５手段と、 前記生成された確認文節列を利用者側に出力し、利用者
   側から確認の承認を意味する文節列が入力されると、前
   記最終応答文節列を利用者側に出力する第６手段と、を
   有することを特徴とする要求確認型情報提供装置。
5. 【請求項５】 請求項４記載の要求確認型情報提供装置
   において、第４手段は、応答文節列の長さが出力量制約
   を満足するのに対応する、緩和要求条件が複数存在する
   場合、その中で最も弱い緩和要求条件を最終要求条件と
   決定することを特徴とする要求確認型情報提供装置。
6. 【請求項６】 請求項４、５記載の要求確認型情報提供
   装置において、第４手段は、応答文節列の長さが出力量
   制約を満足するのに対応する、緩和要求条件が存在しな
   い場合、初期要求条件を最終要求条件と決定することを
   特徴とする要求確認型情報提供装置。