JP3316826B2

JP3316826B2 - 情報案内方法及びその装置

Info

Publication number: JP3316826B2
Application number: JP15254096A
Authority: JP
Inventors: 正信東田; 雅博奥
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 1996-06-13
Filing date: 1996-06-13
Publication date: 2002-08-19
Anticipated expiration: 2016-06-13
Also published as: JPH09330195A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は電話番号案内など
に利用され、１つのキーに複数の文字が割当てられた入
力手段により入力すべき１文字と対応するキーを１度操
作することにより得られるキーシーケンス、つまり曖昧
さを含むキー列を受付けて、そのキーシーケンスにデー
タベースを検索して利用者が所望する検索結果を提供す
る情報案内方法及びその装置に関する。

【０００２】

【従来の技術】電話機のように日本語文字の数や英文字
の数よりも少ないキーしかない入力手段により日本語の
読み情報を入力することが提案されている。つまり例え
ば図１３に示すように電話機１１に設けられている１０
個の数字キー１２のうちの数字「１」に対応するキー１
２₁に日本語５０音文字表のあ行の文字「あいうえお」
と長音（ー）を割当て、数字「２」に対応するキー１２
₂にか行の文字「かきくけこ」と英文字「ＡＢＣ」を割
当て、数字「３」に対応するキー１２₃にさ行の文字
「さしすせそ」と「ＤＥＦ」を割当て、以下同様に順次
割当て、更に「＊」印キー１３₁に濁音（゛）と半濁音
（°）を割当て、「＃」印キー１３₂に「スペース」と
「終了」及び「区切り」を割当てる。このような入力手
段を用いて日本語情報を入力する方法として以下の方法
が考えられる。（Ａ）「あ」を入力する場合は「あ」が表記されている
キー１２₁を１回、「い」を入力する場合は「あ」が表
記されているキー１２₁を２回という様に行を指定する
キーを選択してそのキーを押す回数で文字を指定する方
法。（Ｂ）「あ」は「０１」「い」は「０２」といったよう
にそれぞれの文字を数字２桁を使って符号化して「あ
い」を入力する場合はキー１２₀，１２₁，１２₀，１
２₂を順次操作する方法。（Ｃ）「ひかり４９号」は「１２３４」、「東京駅」は
「９８７６」などのように複合語、単語などを一つの数
字に対応させて符号化しておき、対応する番号キーを押
下することで入力する。（Ｄ）特開昭６３−２１１０１０号公報に示すように、
人名情報Ｓｍｉｔｈを、その綴りの順にその英文字が表
示されたキー１２₇，１２₆，１２₄，１２₈，１２₄
を順次操作して入力し、その入力された曖昧さを含むキ
ー列（キーシーケンス）によりデータベースを検索して
情報を得ることが提案されている。この場合は１文字に
ついてキー操作は１回でよく、また、文字と符号との対
応を知らなくてもよい。しかし例えばキー１２₇が操作
されても、文字「Ｐ」が入力されたか、「Ｒ」が入力さ
れたか、「Ｓ」が入力されたか不明であり、つまり曖昧
さがある。この曖昧さの問題を解決するため、例えば電
話番号案内において、案内対象となる名義の特定に必要
と思われる住所情報、名義情報のほぼ全てを利用者に要
求し、その入力されたキーシーケンスで図１４に示すよ
うに、データベースを検索し、検索結果が１つであれ
ば、その情報を利用者へ提供し、検索結果が複数であれ
ば、例えば「名は文字Ｊで始まりますか」というように
はい／いいえで答えられる質問（ブール排他質問）を利
用者に行い、その回答に応じて検索結果中の正しくない
候補を排除し、その残りが１つになるまで順次各種のブ
ール排他質問を行う。各種の質問をしても候補を所定数
以下に絞ることができない場合は、新たな情報の入力を
利用者に要求する。

【０００３】

【発明が解決しようとする課題】しかしながら、上記の
従来の方法には、以下のような問題がある。従来の
（Ａ）の方法は、入力する文字を指定する方式であるた
め、入力文字の正確性は、保証されている。但し、「あ
列」の文字はボタンキー１回、「い列」の文字列はボタ
ンキーを２回、「う列」の文字はボタンキー３回、「え
列」の文字列はボタンキーを４回、「お列」の文字はボ
タンキー５回押すことになり、全ての列の文字が略同頻
度で利用されると仮定すれば、平均のボタンキー押下回
数は、３回となり、ボタンを多く押す必要がある。ま
た、表示装置がない場合は、ボタンキーを何回押したか
わからなくなることもあり、誤入力を起こす確率が大き
くなる。また、「うえ」のように同じ行の文字を続けて
入力する時には、「う」は「あ行」のボタン３回、
「え」は「あ行」を４回押すことになるが、「あ行」を
７回続けて押すと誤入力となる（「あお」、「いえ」、
「うえ」、「えい」等の可能性がある）ので、「あ行」
のボタン３回押して入力が確定するのを待った後で、
「え」の「あ行」を４回押すことになり、入力に時間が
かかることになる。

【０００４】従来の（Ｂ）の方法は、文字を２桁の数字
列でコード化する方式でも入力自体の正確性は保証され
る。但し、それぞれの文字に対してコード表を参考にし
て２回づつボタンキーを押下することになるので、入力
時間が長くなる、長い文字列の入力ではボタンの押下回
数が文字数の２倍になるので、入力ミスの確率が増える
等の問題がある。

【０００５】従来の（Ｃ）の方法は、投入する日本語の
文字列に対応して予め数字列にコード化した変換表を参
考にしてコードを求め投入する方法もある。この方法
は、入力する情報毎にコード表を参照することになり、
投入に手間がかかるという問題がある。従来の（Ｄ）の
方法のように曖昧さを含むキー入力では、必要と思われ
る全ての情報を１度に入力させ、データベースの検索を
１回で済ませるため、検索結果が１つになる可能性が高
いが、１回に入力させる情報量が多く、利用者の負担が
大きい。

【０００６】また、全ての検索対象に対して、検索条件
として好ましい情報は必ずしも一致していない。このた
め検索結果に多くの候補が生じ、その絞り込みに多くの
質問が必要となり、この点で利用者の負担を増し、場合
によっては更に情報入力を要求することになり、更に利
用者の負担を増加させる。

【０００７】

【課題を解決するための手段】この発明によれば１つの
キーに複数の文字が割当てられた入力手段により、名義
情報又は場所情報の一部がかな文字での読みの各文字と
対応する各１つのキーを１度操作して入力されたキーシ
ーケンスを受付け、その受付けたキーシーケンスを検索
キーとしてデータベースの検索を行い、その検索により
複数の検索結果が得られると、ａ．これら複数の検索結果に関連する追加情報の入力を
促するガイダンスを提供する過程と、ｂ．その追加情報が上記入力手段により同様の手法で入
力された追加キーシーケンスを受付ける過程と、ｃ．その追加キーシーケンスとこれまでに得られた検索
結果とを用いて複数の検索結果を絞り込む過程と、その
絞り込み結果が複数ある間ａ乃至ｃの過程を繰返し、絞
り込み結果が１つになると、その結果の情報を利用者へ
提供する。

【０００８】追加情報はそれまでの入力情報から利用者
が聞いて当然と思われる事項を選択する。つまり追加情
報の要求は利用者には検索条件が少ないために検索結果
が複数になったのか、あるいは入力方法に曖昧性を許容
したために検索結果が複数になったのかの区別を意識さ
せないような対話制御が行われる。追加情報は検索条件
（検索キー）とそれまでに得られている検索結果とから
決る条件とこれと対応する追加情報との各種のものがそ
のシナリオ辞書に記憶され、このシナリオ辞書からその
条件と合致するものを検索し、合致するその追加情報の
入力を促する。その追加情報としては利用者にその追加
情報を促するメッセージとして記憶されていることもあ
る。

【０００９】前記ａ乃至ｃの過程の繰返しによって１つ
に絞り込むことができない場合は、残った複数の検索結
果を構成する情報を順次利用者に提供して、二者択一の
指定をさせる。

【００１０】

【発明の実施の形態】図１Ａにこの発明の方法を実施す
る情報案内装置の機能構成例を示す。入力部２１に利用
者２２から例えば図１３に示した入力手段により入力さ
れた曖昧性のあるキー列（キーシーケンス）が受付けら
れ、この受付けがなされると、情報データベース２３の
検索が行われたか否か、追加情報の要求が行われたか否
か、利用者２２が既に入力した情報が何であるかといっ
た利用者２２との対話の状況を対話制御部２４により監
視し、利用者２２とこの情報案内装置２５との対話が行
われる。

【００１１】入力部２１により受付けたキーシーケンス
を検索キーとしてデータベース検索部２６により情報デ
ータベース２３が検索され、その検索結果（候補）は曖
昧性解消部２７により一意であるか否か判別され、一意
でない場合に利用者に対して追加情報として何を要求す
るかの決定がなされる。この決定は検索条件（検索キ
ー）と検索結果とにより決る条件と、その条件に応じた
追加情報の入力を利用者に促すメッセージが記憶されて
いるシナリオ／メッセージ辞書２８を参照して行われ
る。キーシーケンスの受付けにもとづく応答、質問、追
加情報のメッセージ、検索結果を利用者２２へ提供でき
るように出力用データ作成部２９により加工され、その
加工された出力用データは通常音声情報として出力部３
１を通じて利用者２２へ送出される。情報データベース
２３では１つのレコードは検索するための１つ以上のイ
ンデックス部分とそれらの情報本体部分とから構成され
る。

【００１２】次にこの発明による情報案内方法の実施例
の処理手順を図２を参照して説明する。ステップ１：入力部２１では曖昧性のあるキー列（キー
シーケンス）の入力を受け付け、それを対話制御部２４
へ送る。対話制御部２４では、現在の状態が以下の状態
のいずれであるのかを識別しており、（１）情報データベース検索前の状態。（２）情報データベース検索後であって、追加情報が要
求されている状態。（３）候補が確定し、利用者に情報を提供可能な状態。

【００１３】さらに対話制御部２４では、上記の状態と
入力部２１で得られた曖昧性のあるキー列とをデータベ
ース検索部２６へ送る。ステップ２：データベース検索部２６では、前記（１）
の状態の場合には入力部２１で得られた曖昧性のあるキ
ー列によって情報データベース２３を検索し、候補（検
索結果）を獲得する。（２）の状態の場合にはすでに検
索してある候補に対して入力部２１で得られた曖昧性の
あるキー列を満たす候補のみを選択する。ステップ３：対話制御部２４では、現在の候補の中に曖
昧性が残っているか、つまり複数の候補が得られている
かをチェックし、そのチェック結果に応じて処理を分け
る。曖昧性が残っていない、すなわち、候補が１つの場
合には、その候補を出力用データ作成部２９に送る（ス
テップ１０へ移る）。曖昧性が残っている場合には、曖
昧性解消部２７にその候補を送る（ステップ４へ移
る）。ステップ４：曖昧性解消部２７では、利用者２２に要求
可能な追加情報がまだ存在するか否かで処理を分ける。
要求可能な追加情報がまだ存在する場合には、候補間の
差から追加情報として利用者に何を要求するかを決定す
る。この場合、それまでに得られた検索結果と、各種の
検索キー（検索条件）をシナリオ／メッセージ辞書２８
のシナリオ部の条件部を照合して条件が合致したシナリ
オのアクションを取得する。メッセージ部には利用者に
その条件と対応してどの追加情報を要求したらよいか
が、その要求のための雛形となるメッセージが記録され
ている。前記条件と合致したシナリオのアクション、つ
まりメッセージを対話制御部２４へ送る（ステップ５へ
移る）。要求可能な追加情報がシナリオ／メッセージ辞
書２８で見付けることができなかった場合は、その旨を
対話制御部２４へ送る（ステップ６へ移る）。ステップ５：対話制御部２４では、追加情報として求め
る項目（メッセージ）を出力用データ作成部２９に送
り、利用者２２に追加情報を求めるためのデータを受け
取る。さらに、このデータを出力部３１に送って、利用
者２２に追加情報の入力を要求する。ステップ６：候補の数によって処理を分ける。候補の数
がＮ個以上の場合にはステップ７へ、Ｎ個未満の場合に
はステップ８へ移る。ここでＮは可変値であり、４や５
といった整数値を取る。ステップ７：対話制御部２４では、候補がＮ個以上あっ
て、これ以上特定することができないので、結果を「候
補多数」とする。ステップ８：対話制御部２４では、Ｎ個未満の候補を出
力用データ作成部２９に送り、候補を利用者に選択させ
るためのデータ（音声データであれば「Ａですか、Ｂで
すか、それともＣですか」といったガイダンス）を受け
取り、出力部３１を通して利用者２２に選択を求める。
さらに、入力部２１を通して利用者の選択結果を取得す
る。ステップ９：対話制御部２４では、利用者が選択した候
補を結果とする。ステップ１０：対話制御部２４では、結果を出力用デー
タ作成部２９に送り、適切な結果提供のためのデータを
受け取る。さらに、このデータを出力部３１に送って、
利用者２２に検索結果としての情報を提供する。［具体例１］次に追加情報を用いて、順次候補（検索結
果）を絞り込んでゆく過程を具体例を用いて説明する。
入力部２１はプッシュトーン送出可能なプッシュボタン
付き電話機よりのダイヤルトーンデータを受付け、出力
部３１は前記電話機の受話器へ音声信号を出力する。従
って情報案内装置２５から利用者２２へ送出されるデー
タは音声データである。図３に具体例の説明に用いるた
めの情報データベース２３の内容例を示す。この例は架
空のものであり、以下の例も同様に架空のものである。
図３中の住所キー列３３、姓名キー列３４は、それぞれ
図に示した各キー１２への文字割り当て例に基づいて、
住所の読みおよび姓名の読みをそれぞれ数字列に置き換
えた情報データベース２３中のインデックス部分であ
り、図３中の電話番号列３５が情報データベース２３の
情報本体部分である。例えば、「しがけん」は図の文字
割り当てによって「３２＊２０」となる。なお、「３２
＊２０」は「しがけん」だけでなく、「さがけん」に対
するキー列となる。このように住所キー列（姓名キー列
についても同様）には曖昧性が存在する。

【００１４】これら曖昧性を解消するための制御用に各
種のフラグやレジスタが本装置内には装備されている。
例えば、曖昧性解消部２７には、図１Ｂに示すように、
住所、姓名などの各項目の入力状態をチェックする住所
＊県入力フラグ、住所＊市区入力フラグ、住所＊町村入
力フラグ、姓入力フラグ、名入力フラグが設けられてい
て、これら入力フラグは情報が入力されていないときは
ＯＦＦ状態であり、情報が入力されるとＯＮ状態となる
よう構成されている。これら入力フラグから各検索項目
の入力状態がチェックされる。

【００１５】また、データベース検索部２６には、キー
検索の結果、このキー列に該当する候補数を収容する候
補数レジスタと、これら候補に相当するデータ数を収容
する検索結果数レジスタが設けられている。例えば、上
記のようにキー列「３２＊２０」で検索した場合には、
候補数レジスタには２が収容され、これらの候補に対す
るデータ数が検索結果数レジスタ内に収容される。

【００１６】対話制御部２４には、サービスフラグが設
けられていて、このサービスフラグはシステムが稼働し
ていない状態ではＯＦＦとなっていて、利用者から本装
置が起動されるとＯＮとなり、さらに利用者に所望の情
報を提供するとＯＦＦとなるよう構成されている。これ
らフラグやレジスタの設定の仕方は検索項目、検索など
によって如何様にも増設することができる。これらフラ
グやレジスタについては図４のシナリオ／メッセージ辞
書には示されていないが、本装置ではこれらのフラグや
レジスタを用いることによって入出力状態や検索状態を
検知する手段を実現することができる。これらすべての
フラグのＯＮ、ＯＦＦ状態やレジスタ内容を総称してシ
ステム状態といっている。

【００１７】図４に具体例の説明に用いるシナリオ／メ
ッセージ辞書２８の内容例を示す。シナリオ／メッセー
ジ辞書２８は利用者にこの情報案内装置２５で確定した
情報を確認したり、利用者に要求する追加情報を確定し
たりするために利用され、シナリオ部３６とメッセージ
部３７とよりなり、シナリオ部３６は条件部とアクショ
ン部に分けられ、つまりシナリオ部３６中の始めから記
号→までは条件部であり、記号→の後、（右側）はアク
ション部である。条件部はそれまでに得られている検索
結果と、検索条件（検索キー）とにより決る各種の条件
が示され、その条件が成立（条件と合致）するものがあ
るかどうかを照合できるような形式で記述されている。

【００１８】例えば｜（条件１）＆（条件２）＆（条件
３）｜／（条件４）と記述され、＆はその両側の条件が
同時に成立することを要求し、／はその両側の条件のど
ちらかが成立すれば良いことを示す。更に具体的に述べ
ると、図４中のシナリオ番号４の条件部及びアクション
部は次の通りである。（市区郡候補数＝複数）＆（検索結果数＞Ｍ）＆（姓入
力＝Ｎ）＆（名入力＝Ｎ）→町村入力要求これは受付けられたキー列（キーシーケンス）の市区郡
候補が複数あり、かつその候補による検索結果数がＭよ
り多く、かつ姓情報は入力されてなく、かつ名情報も入
力されていないという条件を表わし、この場合のアクシ
ョン部は町村入力要求であって、追加情報として町村情
報の入力を要求することを示し、当該欄のメッセージ部
３７は「今入力された市区郡のどこの町、村でしょう
か、わからない時は「わからない」と入力してくださ
い」とメッセージを利用者へ出して、町村情報の入力を
要求することを示している。つまり条件部にはそれまで
に入力された検索キー（項目）と、その検索結果と、未
入力の検索キー（項目）との各種組合せよりなり、その
各条件と対応してアクション部に好ましい追加情報（検
索キー、つまり項目）又は確認が記述され、更にその追
加情報又は確認を利用者に要求するためのメッセージの
モデルがメッセージ部に記述されている。なお、この図
４に示したシナリオ／メッセージ辞書のシナリオは、検
索時に地域（住所）の絞り込みをまず重点的に行い、次
に名義の絞り込みを実施する戦略で構成されている。

【００１９】ここで、図５に示すシステム処理フローを
用いて、検索キー（項目）の入力・未入力状態、検索結
果の数などによって変わるシステム状態をチェックし、
例えば図４に示すようなシナリオ／メッセージ辞書２８
を利用して、検索結果を１つに絞り込むまでの情報案内
装置の動作を説明する。装置が動作していない状態で
は、サービスフラグがＯＦＦとなっていて、利用者から
電話番号の問い合わせがあるのを待機する。ステップＳ₁ 利用者から電話番号を問い合わせる呼が受付けられる
と、装置が起動され、図４のシナリオ番号１にあるよう
にシステム状態がリセットされ、サービスフラグがＯＮ
となる。ステップＳ₂ このステップでは、住所・姓名などの情報の入力状態を
取得する。

【００２０】初めは全検索項目が未入力であるので各項
目の入力フラグがＯＦＦ状態である。そして、利用者が
市区などの情報を入力したときに、後述するステップＳ
₁₂で住所＊市区入力フラグなど入力情報に応じたフラグ
がＯＦＦ状態からＯＮ状態となり、システム状態が変更
される。このステップＳ₂では、これら入力フラグのＯ
Ｎ，ＯＦＦ状態や、その他システムの動作状態を検知す
るために必要に応じて設けられたフラグなどのＯＮ，Ｏ
ＦＦ状態を取得する。ステップＳ₃ 前記システム状態とシナリオ／メッセージ辞書２８の条
件部とを照合して、条件部の全項目に合致しているシナ
リオ項目があるか否かを判断し、あればステップＳ
₄へ、無い場合にはステップＳ₁₃へ移る。

【００２１】初めは全入力フラグがＯＦＦ状態、つま
り、全検索項目が未入力であるので、この場合はシナリ
オ番号２の条件部を満たしているので、ステップＳ₄の
処理へ移る。ステップＳ₄ ここでシナリオ番号２１のように最終的に検索結果が一
意に特定されて電話番号案内を送出したときには、サー
ビスフラグをＯＦＦにする。情報を検索している状態で
はサービスフラグはＯＮ状態のままである。また、同一
の検索項目に対して何度も利用者から入力がありなが
ら、検索結果が０件のとき、即ちシステム状態に合致し
たシナリオ項目がないときなどには、その入力回数をカ
ウントし、その入力回数が所定回数を超えた時に、「入
力方法が間違っているようです。もう一度使用方法を確
かめられてからご利用ください。」との警告メッセージ
を利用者へ送出するようにすることもできる。ステップＳ₅ システム状態に合致したシナリオ項目にあるメッセージ
部を取り出し、このメッセージ部に利用者からの入力情
報を盛り込んで出力用のメッセージを編集する。このメ
ッセージは利用者からの入力情報の確認や、新項目（追
加情報）の入力を要求する内容を含んでいる。

【００２２】たとえば、初めは図４のシナリオ番号２の
メッセージ部に記述されている「市、区、郡の名前を入
力して下さい。分からないときは県名を入力して下さ
い。」の入力を要求するメッセージを取り出す。また、
利用者から市名で「富山市」のつもりで「４８７３」の
キー入力があり、後述するステップＳ₁₁，Ｓ₁₂にてこの
キー列で検索した結果、「富山市」のほかに同じキー列
「４８７３」を持つ「津山市」も検索されて、シナリオ
番号４のように複数の市の候補が検索されたときには、
「今入力された市のどこの町、村でしょうか？わからな
いときは“わからない”と入力して下さい。」と別の検
索項目（追加情報）を入力する要求のメッセージが取り
出される。

【００２３】あるいは、利用者から市名で「横須賀市」
のつもりで「８２３２３」のキー入力があり、このキー
列で検索した結果、シナリオ番号３のように１つの市名
に絞れたときには、「入力された住所は“神奈川県横須
賀市”ですね。」と利用者への確認を要求するメッセー
ジを編集する。ステップＳ₆ ステップＳ₅で取り出し、あるいは編集したメッセージ
を利用者に音声出力する。ステップＳ₇ サービスフラグがＯＮ状態であるか否かをチェックす
る。また、利用者に情報をまだ提供していないので同フ
ラグがＯＮ状態であればステップＳ₈へ進み、一方、利
用者に電話番号を案内してしまってサービスフラグがＯ
ＦＦ状態となっていて、もう装置を稼働させる必要が無
くなっている場合には動作を終了させる。ステップＳ₈ ステップＳ₆で出力したメッセージ内容に応じて入力さ
れた利用者からの情報を受け付ける。ステップＳ₉ 利用者からの入力状況によりシステム状態を変更する。
例えば、ステップＳ₈により利用者から市名の入力があ
ったときには、住所＊市区入力フラグをＯＦＦからＯＮ
にする。つまり、入力があった項目の入力フラグをＯＮ
にする。なお確認事項に対する「はい」、「いいえ」の
返答についてもフラグを持ち、返事の有無によりＯＮに
したりＯＦＦにしたりする。ステップＳ₁₀ 利用者からの入力情報によって情報データベース２３の
検索が必要か否かを判断し、必要であればステップＳ₁₁
へ進んで検索を行い、必要でなければステップＳ₂へ戻
り、このシステム状態における処理を行う。例えば、利
用者からの入力が確認事項に対する「はい」、「いい
え」だけの返答であれば、情報データベース２３の検索
は必要ないのでステップＳ₂へ戻る。ステップＳ₁₁ 利用者の入力情報から情報データベース２３を検索し
て、利用者の意図する候補へ絞りこみ、その検索結果と
して得られた候補を記憶して格納すると共に、この検索
結果から候補が複数あがったのか、あるいは１つに絞り
込めたのか、どんな項目を利用者から入力してもらえば
候補が絞り込まれるかなどを分析する。ステップＳ₁₂ ステップＳ₁₁で得られた結果より、システム状態を変更
する。つまり、上記のようにある検索項目の結果がいく
つ得られたかなどによりデータベース検索部２６内の所
定の項目の候補数レジスタや検索結果レジスタが選択さ
れてその内容が変更されたり、どの検索項目まで絞り込
まれているから次に必要な入力項目は何の項目である
か、などがわかるフラグが選択されてその状態が変更さ
れる。

【００２４】そして、ステップＳ₂に戻ってこの時のこ
のシステム状態が取得され、上記のように以降のステッ
プでシステム／メッセージ辞書を利用して検索候補が絞
りこまれ、検索候補が１つになるようにステップＳ₂か
らステップＳ₁₂までの動作が繰り返される。ステップＳ₁₃ このステップでは前記ステップＳ₃にてシナリオ／メッ
セージ辞書内に現在のシステム状態に合致したシナリオ
項目が無い場合、つまり検索不可能な場合に、利用者に
「あいにくお探しの情報が見つかりません。」とのメッ
セージを流してシステムを終了する。

【００２５】図４に示すシナリオ／メッセージ辞書は利
用者に次々と追加情報を質問して、例えば大阪府に１０
万件の候補があったのを、池田市で１０００件の候補に
減少させるように検索結果の数を減少させて検索結果を
１つに絞り込む例を中心としたものである。以下具体例
を述べる。具体例１−１（入力情報から市区郡に曖昧性が生じない
ケース）利用者２２からこの情報案内装置２５を呼び出す特定の
番号が入力部で受付けられると、これが対話制御部２４
に送られてサービスフラグがＯＮとなり、装置がセット
される（図５のステップＳ₁）。対話制御部２４は、装
置が起動されたことを検知して（ステップＳ₂）この時
のシステム状態が図４や図８に示すシナリオ／メッセー
ジ辞書のシナリオ番号の１番の条件部に相当することを
検出して（ステップＳ₃）、このシナリオ番号１番のメ
ッセージ「電話番号案内システムです」を出力用データ
作成部２９で取り出す（ステップＳ₅）。（初期状態で
ありサービスフラグがＯＮ状態であるのでステップＳ₄
はスキップする。）サービスフラグがＯＮのままであるので（ステップ
Ｓ₇）、利用者入力を受け付けるが（ステップＳ₈）、初
めは入力がないのでシステム状態は変更されず（ステッ
プＳ₉）、データベースの検索は必要がなく（ステップ
Ｓ₁₀）、変更のないシステム状態、つまり、住所＊県入
力フラグ、住所＊市区入力フラグ、住所＊町村入力フラ
グ、姓入力フラグ、名入力フラグが全てＯＦＦとなって
いて未入力のシステム状態であることが対話制御部２４
で取得される（ステップＳ₂）。そして、このシステム
状態が図４のシナリオ／メッセージ辞書のシナリオ番号
２番の条件部に相当することが検出される（ステップＳ
₃）。

【００２６】シナリオ番号２番のアクション部にある市
区郡入力要求としてのメッセージ「市、区、郡の名前を
入力して下さい」を出力用データ作成部で取り出し（ス
テップＳ₅）、このメッセージを利用者２２へアナウン
スする（ステップＳ₆）。利用者２２から市区郡名とし
て「１２４＊３」が入力されたとする。入力部２１では
曖昧性のあるキー列「１２４＊３」入力を受け付け（ス
テップＳ₈）、これを対話制御部２４へ送る。対話制御
部２４では、現在の状態が情報検索前の状態であること
を認識している。さらに対話制御部２４では、入力部２
１から市区郡名が入力されたことを受けて住所＊市区入
力フラグをＯＮにして（ステップＳ₈）、この市区郡名
のキー列により情報検索が必要だと判断して（ステップ
Ｓ₁₀）、上記の状態（検索前状態）と曖昧性のあるキー
列「１２４＊３」とをデータベース検索部２６へ送る。
（図２のステップ１）。

【００２７】データベース検索部２６では、入力部２１
で得られた曖昧性のあるキー列「１２４＊３」によって
情報データベース２３を検索し、候補を獲得する（図５
のステップＳ₁₁、図２ステップ２）。情報データベース
２３の内容は図３のようになっているので、住所キー列
のうち市区郡に「１２４＊３」を持つものが候補として
挙がってくる。ここで、市区郡で「１２４＊３」に相当
するキー列を有する住所は池田市しかない。従って、こ
の時点で住所は「大阪府池田市」であることまで確定す
ることができる。

【００２８】ここで住所キー列の市区郡で「１２４＊
３」を持つ名義レコード（検索結果）が１０００件得ら
れたとする。つまり、市区郡候補数＝１、検索結果数＝
１０００という検索結果より、市区郡の候補数レジスタ
＝１、検索結果数レジスタ＝１０００、姓入力フラグと
名入力フラグはそれぞれＯＦＦというシステム状態にな
る（ステップＳ₁₂）。

【００２９】対話制御部２４では現在の候補の中に曖昧
性が残っているか（すべての情報が候補内で同一でない
か）をチェックするが、１０００件の検索結果数が存在
するので、この時点での検索結果数は複数あって更に検
索結果を絞り込む必要がある。よって対話制御部２４は
これらの検索結果の候補を曖昧性解消部２７へ送る（図
５のステップＳ₁₂，図２のステップ３）。

【００３０】曖昧性解消部２７では、上記のようなシス
テム状態を取得して（図５のステップＳ₂）、利用者２
２にまだ要求可能な追加情報がまだ存在するか否かで処
理を分ける。ここでは図４のシナリオ／メッセージ辞書
２８を参照して前記シテム状態とシナリオ条件部との照
合を行う。この場合、検索により市区郡候補は池田市の
１つのみであり、かつ検索結果は１０００件（ｎ＝５個
以上）であり、かつ姓情報及び名情報の何れもまだ入力
されていないから図４のシナリオ番号３の条件と合致す
る（ステップＳ₃）。この条件に対するアクションを取
るように指示する。ここではアクション部は住所の確認
後、追加情報として姓の入力を要求する事を示している
（図２のステップ４）。

【００３１】対話制御部２４は曖昧性解消部２７から入
力されたアクションの「住所確認＆姓入力要求」と対応
メッセージと、それまでの検索結果「池田市」からその
メッセージに必要な住所データ「大阪府池田市」を埋め
込んでメッセージを生成して出力用データ作成部２９へ
送る。ここで「入力された住所は“大阪府池田市”です
ね、次にお探しの方の姓を入力してください」というメ
ッセージを生成して（ステップＳ₅）音声データとして
出力部３１より利用者２２へ送出して追加情報として姓
の入力を要求する（図２のステップ５，図５のステップ
Ｓ₆）。ここで、前記メッセージの住所の埋め込み生成
を出力用データ作成部２９で行ってもよい。また出力用
データ作成部２９での音声データ生成は音声合成による
場合、録音音声の再生による場合がある。

【００３２】以降の説明では図５の流れ図による説明は
省略して図２の流れ図に従って説明する。利用者２２か
ら姓として「１１２」が入力されたとする。入力部２１
ではこの曖昧性のあるキー列「１１２」の入力を受け付
け、それを対話制御部２４へ送る。対話制御部２４で
は、現在の状態が、情報データベース検索後であって追
加情報が要求されている状態であることを認識してい
る。さらに対話制御部２４では、上記の状態（追加情報
要求状態）と入力部２１で得られた曖昧性のあるキー列
「１１２」とをデータベース検索部２６へ送る（図５の
ステップ１）。データベース検索部２６では、すでに検
索してある候補１０００件に対して入力部２１で得られ
た曖昧性のあるキー列「１１２」を満たす姓を持つ候補
のみを選択する（ステップ２）。ここでは検索キーとし
ては「１１３２６♯１２４＊３♯１１２」を使用するこ
とになる。「大阪府池田市」の中で姓名キー列３４の姓
に「１１２」を持つレコードのみが候補として残る。こ
こで情報データベース２３の内容は図３のようになって
いるので、“大阪府池田市伏尾台２丁目の植木功”だけ
が候補として得られる。候補が１つだけとなった（図２
のステップ３）のでステップ１０へ移る。

【００３３】次に曖昧性解消部２７はこれまでの検索結
果、池田市のみ、検索結果が１個、姓入力済みと、未だ
名情報（検索キー）が入力されていないという条件は、
図４のシナリオ／メッセージ辞書２８中のシナリオ番号
１１の条件と合致していることを検出し、これと対応す
るアクションとして「大阪府池田市にお住まいの植木さ
んは一人で植木功さんでよろしいですか」というメッセ
ージが利用者２２へ送出される。

【００３４】対話制御部２４は利用者２２からの間違い
ないことを示す回答データ、例えばＹを表わすキー１２
₉のデータの受付けにより確認後、電話番号を利用者２
２へ伝える。つまり図４のシナリオ／メッセージ辞書２
８中のシナリオ番号２１のメッセージ部を取出して、
「植木功さんの電話番号は０７２７−８８−９９９９で
す」を音声データで利用者２２へ伝える。

【００３５】以上の処理により、曖昧性のある入力キー
列「１２４＊３」から得られた多数の名義候補に対し
て、姓の入力を利用者に求めることにより、その候補の
中から利用者が求める１つの候補を検索結果として利用
者に提供することができる。すなわち、利用者にとって
は１つの追加情報の入力だけで所望の情報を得ることが
できる。

【００３６】しかも要求情報も、市区郡、姓であり、利
用者にとって要求されて当然の情報である。具体例１−２（住所情報に曖昧さが生じるケース）利用者から都道府県名として「３２＊２０」が入力され
たとする。入力部２１ではこの曖昧性のあるキー列「３
２＊２０」の入力を受け付け、それを対話制御部２４へ
送る。対話制御部２４では、現在の状態が情報データベ
ース検索前の状態であることを認識している。さらに対
話制御部２４では、上記の状態（検索前状態）と入力部
２１で得られた曖昧性のあるキー列「３２＊２０」とを
データベース検索部２６へ送る。

【００３７】データベース検索部２６では、入力部２１
で得られた曖昧性のあるキー列「３２＊２０」によって
情報データベース２３を検索し、候補を獲得する。情報
データベース２３の内容は図３のようになっているの
で、住所キー列３３の都道府県に「３２＊２０」を持つ
レコードとして、「滋賀県」と「佐賀県」の全レコード
が候補としてあがって来る。ここで入力された県名レベ
ルで曖昧性が生じていることがわかる。

【００３８】対話制御部２４では、現在の候補の中に曖
昧性が残っているか（すべての情報が候補間で同一でな
いか）をチェックするが、３件以上の候補が存在するの
で、現在の候補の中に曖昧性が残っている。従って対話
制御部２４ではこれらの候補を曖昧性解消部２７に送
る。曖昧性解消部２７では、利用者２２に要求可能な追
加情報がまだ存在するか否かで処理を分けるが、図４の
シナリオ／メッセージ辞書２８を参照してシナリオ番号
５と条件が合致し、そのアクション部より市区郡名を追
加情報として要求する処理に入り、「お探しの方がお住
まいの市区郡名を入力して下さい」というアナウンスが
利用者２２へ送られる。

【００３９】利用者２２から市区郡名として「１１４
３」が入力されたとする。入力部２１ではこの曖昧性の
あるキー列「１１４３」の入力を受け付け、それを対話
制御部２４へ送る。対話制御部２４では、現在の状態
が、情報データベース検索後であって追加情報が要求さ
れている状態であることを認識している。さらに対話制
御部２４では、上記の状態（追加情報要求状態）と入力
部２１で得られた曖昧性のあるキー列「１１４３」とを
データベース検索部２６へ送る。

【００４０】データベース検索部２６では、すでに検索
してある候補に対して入力部２１で得られた曖昧性のあ
るキー列「１１４３」を満たす市区郡名を持つ候補のみ
を選択する。情報データベース２３の内容は図３のよう
になっているので、県名に「３２＊２０」のキー列をも
つ住所キー列の市区郡名に「１１４３」を持つレコード
のみが候補として残る。この段階で県名が持っていた曖
昧性が解消されたことになる。しかし図３より「滋賀県
大津市」だけでは２件以上の候補が残る。

【００４１】この候補の絞り込みのための追加情報を求
めるため、シナリオ／メッセージ辞書２８のシナリオ番
号８の条件と合致し、姓情報の入力が要求され、利用者
２２から「１１２」が入力されたとする。これを受付け
て「３２＊２０♯１１４３♯１１２」を検索キーとして
情報データベース２３が検索され、この結果、図３より
まだ４件以上の候補が残る。

【００４２】ところでこれまでの入力情報（受付情報）
から、住所キー列３３中の都道府県、市区郡と姓名キー
列３４中の姓とが入力されているから、要求可能な追加
情報は住所キー列３３中の区町村と姓名キー列３４中の
名が残っている。４つの候補間の差（違い）で区町村は
「石山寺」と「本町」とであるが、その何れかであるか
が判明しても、図３からまだ候補が２件づつ残る。しか
し４つの候補間の差で名は「４４＊３（忠）」と、「６
９３（浩）」と、「１３１（勇夫）」及び「１３１
（功）」とであるから、名を入力してもらった方が曖昧
性が一度で解消できる可能性がある。このようなことも
考慮してシナリオ／メッセージ辞書２８は作成されてい
る。

【００４３】これまでに得られた検索結果と検索条件と
から、図４のシナリオ番号９が条件に合致し、「続いて
名前の入力をお願いします」という利用者２２に対して
アナウンスがなされる。（ケース１）利用者からの入力情報が「４４＊３」であ
れば、図３の情報データベース２３の検索結果、候補の
数が「石山寺」の「青木忠」だけになるので、後は確
認後電話番号を案内する処理に移る。（ケース２）利用者からの入力が「１３１」であれば、
情報データベース２３の検索は図３から「石山寺青木
勇夫」と「本町大木功」の２件に絞り込まれる。
しかし、この時点でもまだ「１１２」に対応する姓が
「あおき」か「おおき」かの区別はついていない。

【００４４】この時は、「区町村」の情報を聞くか、
「名」の漢字情報を聞くかで情報を特定できる。この場
合は２件なのでどちらの情報を聞いてもよいが、一般的
には名義候補の数によってどちらの情報を優先して聞く
かを戦略として定めてシナリオを構成しておく。この場
合には、通常住所を先に聞く。

【００４５】利用者からの入力が「１３８７４＊９」で
あれば、「石山寺の青木勇夫」であることが特定でき
る。また、「６０４８１」であれば、「本町の大木
功」であることが特定出来る。「区町村」の情報の取得
に失敗する（利用者が知らない時など）場合や、区町村
の情報取得後もまだ「姓名」の情報が確定出来ず、漢字
情報が頼りになるときなどの条件が揃った時には、
「名」の漢字情報で「姓」の曖昧さも同時に解消できる
ことになる。

【００４６】例えば、「いさおの漢字はいさましいにお
っとですか？」と利用者に聞いて「はい」であれば、
「１１２♯１３１」は「青木勇夫」であると特定出来
るし、また「いさおの漢字は成功のこうですか？」のよ
うに字種を質問する文章を、生成し、利用者に呈示し
て、その答えが「はい」であれば、「１１２♯１３１」
は「大木功」であることが出来ることになる。

【００４７】以上の処理により、利用者からの入力だけ
では特定できない場合でも、利用者にどの候補が所望の
ものであるかを確認することによって、利用者が求める
１つの候補を検索結果として利用者に提供することがで
きる。また「都道府県名」の情報を要求した後、その下
位概念と云える「市区郡名」の情報を要求するため、利
用者は、違和感なく、つまり聞かれて当然と思われ、利
用者は心理的ストレスを感じることなく、追加情報を提
供でき、かつ利用者は自分が入力したと信じている入力
キー列に対する複数のレコード（候補）から所望するレ
コードを一意に同定する処理に対して装置２５が協力し
ていることを信じており、装置２５は利用者のそのよう
な期待と信頼を裏切ることのないような対話誘導が行わ
れ、曖昧性解消のための情報を利用者から抵抗感なく取
得できる。具体例２次に利用者の保有している情報に応じて対話制御をどの
ように行うかの具体例を示す。この具体例ではシナリオ
／メッセージ辞書２８の内容は図８に示したものとす
る。図８のシナリオはある程度まで地域（住所）の絞り
込みを行った後、名義の曖昧性を後述する経験則によっ
て重点的に絞り込む戦略で構成されている。例えば姓に
対する同一のキー入力「１１２」に対し、「青木」、
「植木」、「大木」などの曖昧性があるが、この曖昧性
を利用者に知られずに解消するために、現在検索してい
る項目に関連する周辺情報を質問することによって検索
結果を１つに絞り込む例を中心に示したものである。

【００４８】このように同じ装置構成であり、かつ処理
アルゴリズム自体が図５に示したものと変わらないが、
図４や図８に示した各種の辞書を設けておくことにより
利用者群の情報入力上の特性や、ある地域には同姓が多
いなどの地域の実情に合致した情報案内を実現すること
ができる。以下、日本語読みに対応してボタンキーを一
度づつ押下する方式の入力方式（ＰＢ方式）を採用し、
電話機を入力手段とした電話番号案内サービスの具体的
な例を示す。

【００４９】ボタンキーへの５０音の割り当ては具体例
１と同じく図１３とする。番号案内で利用者の所望する
加入名義のある住所を指定するために必要な住所の読み
情報と対応する数字記号列は、本装置の情報データベー
ス２３の一部分を構成する住所データベース２３ａとし
て、図６に示すようにすでに収録されているとする。ま
た、加入者名義の名前と住所、電話番号の情報を格納し
たレコードから構成される個人宅電話番号データベース
２３ｔも情報データベース２３の一部分として図７に示
すように収録されているとする。

【００５０】また、曖昧性解消部２７では、図８に示す
ようなシナリオ／メッセージ辞書２８を検索することに
よって利用者に対して追加情報を要求するものとする。
個人宅の電話番号を案内するサービス例として、利用者
に「富山県富山市相生町（とやまけん／とやまし／あい
おいちょう）の青木昭夫（あおきあきお）」さんの
電話番号を案内する場合を考える。具体例２−１（利用者が必要な情報を保持している場
合）利用者が、利用時点で「富山市相生町の青木昭夫」のす
べての情報を持っている場合を考える。

【００５１】まず、電話番号を検索する地域をある程度
の広さに限定する（市区郡レベル）ために、住所情報を
利用者から入力させる。対話制御部２４からの「市、
区、郡の名前を入力して下さい」のメッセージに対して
利用者２２は、市名を入力する。「とやまし」という文
字列に対応して「４８７３」のボタンキーを押すことで
入力し、入力部２１で「４８７３」と認識され、データ
ベース検索部２６へ送られる。データベース検索部２６
は、この数字列「４８７３」を検索キーとして住所デー
タベース２３ａを検索し、この数字に対応する住所をす
べて検索し、格納する。この場合、「とやまし」と「つ
やまし」の２件が検索され、読みが異なっていることが
わかる。

【００５２】このため、曖昧性解消部２７が、この時点
で曖昧性が残っていることを利用者に知らせないで曖昧
性の解消を行うことを試みる手段を探索する。検索結果
の状況を記述した状況を元に対応策を記述した図８のシ
ナリオ／メッセージ辞書２８を検索する。この結果図８
からシナリオ番号４の条件となり、市区郡の検索結果の
読みが複数ある時に利用するメッセージ「今入力された
（市区郡の区別）のどこの町、村でしょうか？わからな
い時は“わからない”と入力してください」を図８のシ
ナリオ／メッセージ辞書２８から読みだす。選択された
メッセージに対して必要な情報を挿入して、更に必要な
情報を利用者に要求するように対話制御部２４に要求す
る。

【００５３】対話制御部２４は、「今入力された（市区
郡の区別）のどこの町、村か、入力してください。わか
らない時は“わからない”と入力してください」という
メッセージに「市区郡」のうちの「市」を入力して、
「今入力された（市）のどこの町、村でしょうか。わか
らない時は“わからない”と入力してください」という
メッセージを出力する。

【００５４】利用者２２は「とやまし」は認識されたと
信じているが、富山市では検索範囲が広く検索が大変だ
ろうと推測し、次に「あいおいちょう」に相当する「１
１１１４８１」を入力する。システムは「４８７３」と
いう情報と「１１１１４８１」の二つの情報を同時に満
たす情報を住所データベース２３ａから検索し、「とや
まけん／とやまし／あいおいちょう」であることを同定
する事が出来る。

【００５５】曖昧性が解消できたので曖昧性解消部２７
は住所確認の手順を取る。シナリオ／メッセージ辞書２
８（図８）からシナリオ番号６の条件が成立し、「お調
べする住所は（市区郡名、町村名）ですね」を読み出
し、対話制御部２４に送る。対話制御部２４は、上記メ
ッセージを「富山市、相生町」を挿入して、「お調べす
る住所は（とやましあいおいちょう）ですね」として利
用者２２へアナウンスして確認を取る。

【００５６】この段階で探索する範囲が「富山県富山市
相生町」に限定できた。この時の検索キーは「４８７２
０♯４８７３♯１１１１４８１」である。次に名義の入
力を利用者に要求する。上記と同様の手順を取って、図
８のシナリオ番号８にもとづき情報案内装置２５からは
「それでは、お探しする人の姓を入れて下さい。」と利
用者２２へ要求する。利用者２２は電話機から「あお
き」として「１１２」を入力する。

【００５７】上記住所キー「４８７２０♯４８７３♯１
１１１４８１」と姓のキー「１１２」の条件で個人宅電
話番号データベース２３ｔ（図７）を検索した結果、相
生町には６人の該当者がおり、その姓の読みに関しても
４通りあることがわかる。曖昧性解消部２７では読みに
曖昧性のあることは利用者に知らせないで、曖昧性解消
のために名の入力を求めることを決め、シナリオ／メッ
セージ辞書２８（図８）からシナリオ番号１１のメッセ
ージを読みだし、対話制御部２４から、「該当する方が
６人います。名前を入れてください。」と利用者２２に
伝える。

【００５８】ここで利用者２２は、昭夫のよみ（あき
お）「１２１」を電話機から入力したとする。この条件
を付加して再度検索をすると、候補は１件になる。すな
わち、図７から明らかなように、姓だけの入力では「１
１２」に対しては「あおき」のほかに「おおき」「うえ
き」「いおか」などの可能性があり、名だけの入力では
「１２１」にたいして「あきお」のほかにも「いくえ」
「いくお」「あきえ」などの可能性が存在するが、たと
えば、富山市相生町に限ってみれば、この条件を同時に
満たす、実在の姓名を有する人は、「あおき−あきお」
しかいない。この時点で利用者の所望する検索相手が同
定できる。

【００５９】さらに対話制御部２４では、シナリオ／メ
ッセージ辞書２８（図８）のシナリオ番号９から、「そ
の方は、（市＋町名）にお住まいの（姓＋名）さんです
か？」のメッセージを読み出し、「その方は、富山市相
生町にお住まいの青木昭夫さんですか？」と確認処理を
利用者に対し行い、確認後、シナリオ番号２１から「そ
の方の電話番号は（０７６４−３１−１１１１）で
す。」と電話番号を案内する。

【００６０】以上の処理により、この発明の情報案内方
法は、入力の曖昧性を解消すると同時に探索範囲を狭小
化する事に成功する。一方、利用者は必要な情報を効率
的な入力方法で提供したという気持ちで心理的な抵抗感
を感じない。このように、利用者は短時間で入力できる
メリットを享受できる利点があり、情報案内装置２５は
利用者の持つ情報を最大限引き出せて、曖昧性を解消
し、探索範囲を狭小化することで検索の効率を上げるこ
とができる。具体例２−２（利用者の情報が不足する場合（１））利用者が、利用時点で「富山市の青木昭夫」の情報しか
持っていない場合を考える。すなわち、利用者は町名に
ついて明確には覚えていないとする。

【００６１】住所の入力に関しては、具体例２−１と同
様に「４７８３」が入力された時点では「とやまし」と
「つやまし」の区別がついていない。利用者が相生町の
情報を持っていないので、利用者との応対は以下の様に
なる。情報案内装置２５からは、利用者２２に市内の詳
細な住所を問い合わせるが、利用者は「わからない」に
対応する「０２９５１」を入力する。情報案内装置２５
は、市の候補が複数あって、市の中の詳細情報がわから
ない時はシナリオ／メッセージ辞書２８（図８）のシナ
リオ番号５から「それでは、どこの都道府県にあるかお
わかりですか？入力してください。」を読み出して、都
道府県名の入力要求をする。利用者は「とやまし」は、
日本にはほかにもあるのかと思いつつ「とやまけん」と
入力する（事実、「せんだいし」は、宮城県と鹿児島県
に存在するし、「中央区」や「北区」は各地に存在す
る）。利用者からの情報「４８７２０−４８７３」で住
所データベース２３ａ（図６）を検索、「富山県富山市
（市内住所不明）」というところまで確認する事ができ
る。

【００６２】または、「とやまし」と「つやまし」の両
方を候補として残したまま、姓名を聞く処理に入ること
も考えられるが、ここでは富山市が同定できる処理を考
える。この場合は、住所に関しては「富山県富山市（４
８７２０♯４８７３）」が検索キーになり、姓名に関し
ては「あおき、あきお（１１２♯１２１）」が検索キー
になる。この条件で個人宅電話番号データベース２３ｔ
（図７）を検索すると、「相生町１丁目の青木昭夫」と
「荒川の青木郁男」の２件が存在する。この時点で姓は
「青木」と同定できたが、名は同定できていない。この
ような場合には「（あおき）さんは富山市には、（相生
町）と（荒川）にいます。どこか教えてください。」と
いって利用者に入力させ、候補を一つに絞り込むことが
できる。

【００６３】以上の処理により、町名を明確には覚えて
いなくても所望の電話番号を案内することができる。ま
た、大抵の場合、候補名をあげられてどこかと聞かれた
場合は答えられることを考えれば、利用者に大きな負担
を強いているとはいえない。６文字の（あおきあきお）
を従来の手法で符号化して入力するには１２回ボタンを
押すことを考えると、この発明方法では（あおきあき
お）＋（あいおいちょう）の場合で１３回、（あおきあ
きお）＋（あらかわ）で１０回であり、この情報でさら
に詳しい住所情報まで確定できることを考えると、同等
以上の効果が期待できる。具体例２−３（利用者の情報が不足する場合（２））利用者が、利用時点で「富山市相生町の青木」しか情報
を持ち合わせていない場合を考える。すなわち、利用者
は名について明確には覚えていないとする。

【００６４】利用者から入力される情報は、富山市相生
町の「４８７３♯１１１１４８１」と、青木の「１１
２」である。これで個人宅電話番号データベース２３ｔ
（図７）を検索すると、６件のレコードが検索される。
名を一応問い合わせるが、これに対する回答は「わから
ない」になる。従って、次に問い合わせる情報は丁目情
報になる。

【００６５】利用者が１丁目という情報を覚えていたと
する。この場合は候補は２件に絞り込まれる。しかし、
姓はいぜんとして「あおき」と「うえき」の２件あるた
め、姓の読みは利用者に知らせないで、「名前が、（あ
きお）さんと（みのる）さんという方がおられます。
（あきお）さんでしょうか？」と利用者に問い合わせる
ことで、曖昧性の解消を行う。

【００６６】利用者が丁目情報を持っていないときは、
検索解の数が多すぎる場合には案内を断念する（図２中
のステップ７）。また、検索解の数が多すぎずかつ複数
である場合には、名前を列挙することにより利用者の選
択を促すことによって解消する（図２中のステップ８，
９）。上述したように追加情報の選択はシナリオに組込
まれた方法で行われるが、おおよそ以下の基準で選択さ
れる。・利用者が聞かれて当然だと思う事項・姓を入力
した後で、名を要求する。

【００６７】・市の名を入力した後で、その市内の詳細
な町名や区の名称を要求する。・会社名や店名を入力した後で、職種を要求する。・上位概念と下位概念に相当する事項・同じ市名や区名がある場合に、その市や区がある都道
府県名を要求する。・会社の内部の組織など。

【００６８】・飲食店とその具体的な飲食の種類を示す
店など。・利用者にとって印象的な事項・何丁目か、字は何かよりは、姓名の名前の方が印象に
残っている可能性が大。・店、病院、会社などは住所情報よりも、近くの目標物
などが記憶に残っている。

【００６９】このように利用者にとって聞かれても不自
然でなく、抵抗なく、答えられる事項を追加情報として
選択している。次に上記における上位概念と下位概念に
相当する事項を検索の対象にした場合の具体例について
説明する。上位概念と下位概念の一具体例を図９に示
す。

【００７０】図９Ａでは東京都の下位概念として世田谷
区、新宿区、・・・千代田区があり、世田谷区の下位概
念として下北沢、代田、経堂などがあり、図９Ｂでは病
院の下位概念として大学病院、総合病院、個人病院があ
り、大学病院の下位概念として東大病院、慶応病院など
があり、図９Ｃでは会社の下位概念として商社、メーカ
ー、販売業、サービス業などがあり、商社の下位概念と
して総務部、広報部、営業部などがあり、総務部の下位
概念として人事部、労働部などがある。図１０では飲食
店の下位概念として食堂、喫茶店、料亭、飲み屋、接客
女性付酒場などがあり、食堂の下位概念としてそば屋、
レストランなどがあり、喫茶店の下位概念として店名セ
ーヌ、ロアールなどがあり、飲み屋の下位概念として酒
場、居酒屋などがあり、接客女性付酒場の下位概念とし
てバー、キャバレー、クラブなどがある。これらの下位
概念の下に更にそれぞれ店名などがある。上述の具体例
では個人の電話番号の案内を例としたので住所、（場
所）情報と人名情報を要求したが、法人としての会社、
病院・・・飲食店、官庁などについては名称を示す名義
情報、場所情報の他に、例えば飲食店名が入力されてい
る状態で、フランス料理、日本料理、インド料理など料
理の種類を追加情報として入力させるなど、また会社名
が入力された状態で、鉄鋼業、化学工業、電気産業、金
融業などの業種を追加情報として入力させるなど、追加
情報としては各種のものを利用でき、入力された情報に
応じて適切な追加情報の選択がなされ、少ない入力で曖
昧性を絞り込むことができる。

【００７１】更に電話番号の案内を受けると共に、情報
データベース２３に他の付帯情報も記憶しておき、検索
結果が一意に決定された後に、その付帯情報を要求させ
ることもできる。例えば個人宅電話番号データベースと
して図１１に示すように住所キー列３３、姓名キー列３
４の他に付帯情報列３８が設けられ、付帯情報列３８に
はその加入者の家族構成、趣味、勤務先などが記憶され
ている。前記具体例と同様にして、例えば富山市相生町
の青木昭夫さんに対する検索が一意に決定されると、こ
の情報案内装置２５から、「電話番号を知りたいです
か」、「奥様の名前と趣味を知りたいですか」、「家族
構成を知りたいですか」などの問合せを利用者へ送り、
例えばその３番目の問合せに「はい」の回答が入力され
ると、「夫妻と長男、次男の子供二人です」と回答す
る。

【００７２】付帯情報としては名義情報が飲食店などの
商店の場合、その営業時間や、道案内のための目印とな
る物の情報、病院の場合、専門科目など名義情報に応じ
て各種のものが考えられる。以下の具体例では、法人の
電話番号の案内を行う過程を簡単に説明する。情報デー
タベース２３には図１２に示すような法人電話番号案内
データベース２３ｋが一部に収録されている。具体例３−１（町名までが既知の郵便局を調べるケー
ス）情報案内装置２５からの住所入力の要求に対して、利用
者が「市区郡」として新宿区の「３０３＊８２２」を入
力したとする。この場合、情報データベース２３とのマ
ッチングにより「市区郡」のレベルでは「３０３＊８２
２」に該当するのは新宿区しかないため、本装置２５か
ら「東京都新宿区でお探しします。」とメッセージが流
れ、「引き続き名義を入力して下さい。」と次の入力が
要求される。

【００７３】利用者は、何という名かわからないが郵便
局の電話番号を調べたいので「郵便局」に相当する「８
１６＊０２８２」と入力する。この名義情報より、末尾
からの一致検索により、つまり末尾が「郵便局」である
ものを検索することにより検索結果として「牛込郵便
局」と「牛込第二郵便局」があげられる。両郵便局とも
「職種」では当然同じ「郵便局」であるので、これを区
別するための追加情報が利用者に要求される。ここでは
「区町村」の情報が区別するのに有効であるので「どの
町にある郵便局ですか？」と利用者に質問する。そし
て、利用者が「山伏町」にあたる「８７６＊３４８１」
とキー入力すると、「東京都＋新宿区＋山伏町＋郵便
局」にあたる「４１２８１４♯３０３＊８２２♯８７６
＊３４８１♯８１６＊０２８２」でキー検索される。こ
れにより、その郵便局は「牛込第二郵便局」の名義であ
ると一意に決定され、「新宿区山伏町にある牛込第二郵
便局の電話番号は０３♯３２６９♯２２２２です。」と
のメッセージが利用者に提供される。具体例３−２（存在する市区郡と店名だけから検索する
ケース）利用者が、本装置からの住所入力の要求に対して新宿区
の「３０３＊８２２」と入力したとする。この場合は、
前記同様に新宿区が特定され、本装置から「東京都新宿
区でお探しします。」とメッセージが流れ、「引き続き
名義を入力して下さい。」と次の入力が要求される。そ
して、利用者が名義の「たぬき」に相当する「４５２」
とキー入力すると、この「東京都新宿区のたぬき」に相
当するキー列「４１２８１４♯３０３＊８２２♯４５
２」で情報データベースを検索した結果は、図１２に示
すように「つねこ」、「たなか」、「たぬき」の３つの
名義候補があげられ、さらに、「たぬき」には下部名義
としての「新宿東口店」、「新宿東口２号店」、「新宿
３丁目店」の３支店があり、合計５店舗の候補があるこ
とがわかる。

【００７４】そこで、この検索結果の候補を絞るための
有効な追加情報として「職種」が曖昧解消部２７で選択
され、「そのお店の職種を入力してください。」と利用
者に入力を要求する。利用者が「飲み屋」だと思ってこ
の言葉に相当する「５７８」と入力すると、「５７８」
を含む下位の職種（「酒場」、「居酒屋」など）と前記
検索結果の５候補の「職種」とがＡＮＤ条件で絞り込ま
れて、その結果、「たぬき」の「新宿東口店」と「新宿
東口２号店」と「新宿３丁目店」の３候補が残る。さら
に候補を絞るために「何か近くに目印か目標となるもの
がありますか？」と追加情報の入力を利用者に要求す
る。利用者が、新宿御苑に近かったことを思い出して
「新宿御苑」に相当する「３０３＊８２２＊８１０」と
入力すれば、本装置は「東京都＋新宿区＋たぬき＋飲み
屋＋新宿御苑」に相当する「４１２８１４♯３０３＊８
２２♯４５２♯５７８♯３０３＊８２２＊８１０」のキ
ー列で情報データベースの検索がなされ、検索結果は１
件となり、「たぬき新宿３丁目店」と特定される。そし
て利用者には、「新宿御苑近くにある“たぬき新宿３丁
目店”の電話番号は０３−３５０７−９９９９です。」
との情報を提供する。さらに続いて「このお店の情報を
お知りになりたいときは所定の入力をお願いします。」
と質問することによってサービス情報の提供の有無を確
認することもできる。利用者がその店についての付帯情
報を要求する所定の入力を行ったときには、「今、生ビ
ール祭り開催中です。」とのサービス情報を提供する。具体例３−３（存在する町名と名義より情報を提供する
ケース）利用者が、本装置からの住所入力の要求に対して千代田
区大手町に相当する「４８４＊２♯１１４７４」と入力
したとする。このキー列で情報データベースを検索する
と、「市区郡」と「区町村」のレベルでは「４８４＊２
♯１１４７４」に該当するものは「千代田区大手町」し
かないため、「東京都千代田区大手町でお探ししま
す。」とメッセージが流れ、「引き続き名義を入力して
下さい。」と次の入力が要求される。

【００７５】そして、利用者が「三ツ星商事」に相当す
る「７４６＊３３８１３＊」と入力すると、この検索結
果は３件となり、図１２にあるように三ツ星商事の下部
名義として「総務部」、「広報部」、「営業部」などが
ある。この場合は、職種を利用者に質問しても曖昧性解
消にはならないので、本装置は追加情報として下部名義
の入力を要求する。利用者がこの下部名義まで知ってい
れば、この下部名義を入力することによって、これに相
当する情報を提供できる。そこで、本装置から「三ツ星
商事の部署名を入力して下さい。部署名がわからないと
きは所定の入力をしてください。」とのメッセージを利
用者に流す。（ケース１）利用者が「広報部」に相当する「２１６１
６＊」と入力すると、「東京都＋千代田区＋大手町＋三
ツ星商事＋広報部」に相当するキー列「４１２８１４♯
４８４＊２１１４７４♯７４６＊３３８１３＊♯２１６
１６＊」によって情報データベースの検索がされる。そ
の結果、三ツ星商事の広報部の電話番号が一意に決定さ
れ、「千代田区大手町にある三ツ星商事の広報部の電話
番号は０３−３５０５−１１１２です。」とのメッセー
ジを利用者に提供する。（ケース２）利用者から三ツ星商事のどの部署か不明で
あるとの入力がされたときは、「三ツ星商事の総務部の
電話番号を提供します。その電話番号は、０３−３５０
５−１１１１です。」とのメッセージを提供する。

【００７６】以上の法人（職業別）電話番号案内に用い
るシナリオ／メッセージ辞書の具体例を示さなかった
が、上記の例から個人電話番号案内のそれ、つまり図４
又は図８と同様に作ればよいことは容易に理解されよ
う。更に個人用シナリオ／メッセージ辞書を用いるか、
法人用シナリオ／メッセージ辞書を用いるかは、例え
ば、電話番号案内を受け付けた時に、最初に「個人電話
番号を知りたいのですか？」又は「法人（職業別）電話
番号を知りたいのですか？」の何れかの質問をし、その
返事に応じて、使用する辞書を選択する。あるいは、電
話番号案内装置へアクセスを、個人用と、法人（職業
別）用とにより異なる電話番号で利用者に行わせ、その
アクセスに応じて利用する辞書を選択する。

【００７７】また最近は、通信開始時に、発信端末の番
号に代表される発信端末の識別情報が交換機へ送られる
機能を有する、ＩＳＤＮ（デジタル綜合通信網）のよう
な通信システムが用いられるようになってきた。この機
能を利用すれば、この発明の利点を更に高めるとができ
る。例えば具体例３に類似したケースで、利用者が最寄
りの郵便局の番号を知りたいために、この発明の機能を
有したセンタにアクセスしたとする。その時に発信端末
情報も同時に到達していれば、電話番号の市外局番に当
たる情報から、発信端末の設置地域を特定することが出
来る。それによって、都道府県ないし丁目等までの地域
に関する情報が得られ、この場所情報を利用者に要求せ
ずに済ませられる可能性がある。利用者から見れば「郵
便局」という名義相当情報さえ入力すれば、この情報案
内装置が最寄りの郵便局を検索してくれ、その番号を得
る可能性がある。

【００７８】上述においてキー１２に表示文字は仮名文
字のみならず図１３に示したように英文字も表示する場
合は、例えば名義情報としてＮＴＴ株式会社を入力する
場合その「ＮＴＴ」に対しての読み「えぬていてい」に
対応する「１５４１４１」と入力せずに英文字「ＮＴ
Ｔ」に対応するキーを利用して「６８８」と入力しても
よく、同様に後者の場合、キー操作の回数が少ない利益
が得られる。また入力を仮名文字で行う場合に限らず、
ローマ字綴りで入力してもよい。このようなことは、仮
名文字及び英文字に対応するキーシーケンスをデータベ
ースに登録しておくことによって仮名文字入力か、英文
字入力かのどちらもアクセス可能（データ入力可能）と
することができる。

【００７９】更に入力手段として電話機のキーボードに
限らず、他の例えばパソコンのキーボードによる入力、
その他のものでもよく、また２周波トーン信号によるキ
ー入力のみならず、ダイヤルパルスにより行ってもよ
く、更に入力手段のキー上には必ずしも数字を表示しな
くてもよい。

【００８０】

【発明の効果】以上述べたようにこの発明によれば、１
つのキーが複数の文字を表わし、そのキーを１文字につ
いて１度しか操作しないで読みの文字を入力し、つまり
曖昧なキーシーケンスとして入力し、入力操作数が少な
く、操作性が良いものとし、しかも名義情報、場所情報
の一部ずつ入力し、情報データベースの検索を行い、そ
れまでに得られた検索結果を用いて追加情報の入力を要
求し、その追加情報を含めてデータベースの検索を行う
ことを繰返すようにしているため、全ての場合に必要と
思われる全ての情報を一度に入力させるよりも少ないキ
ー操作で目的とする検索結果を得る場合が多いので、利
用者から見て、より短い時間で目的の番号ないし情報に
到達できるという顕著な効果を生む。また、番号ならび
に情報検索に必要な情報を最初に一度に入力させるより
も、この発明のように都道府県名の次に市区群名のよう
に、想起し易い情報から逐次尋ねていく方が、認知心理
学の観点からも、利用者の心理的負担が少ない方法であ
ることが分かっている。

【００８１】特に追加情報を、それまでの入力情報と検
索結果に応じた適切なものを選択することにより少ない
キー操作で目的の検索結果を得ることができる。そのた
めにはシナリオ／メッセージ辞書として説明したように
それまで入力情報と、検索結果と未入力検索キーとによ
り決る条件と、これに適切な追加情報（アクション）と
の関係を辞書としておくことにより、効率的に検索を行
うことができる。またブール排他質問で候補を絞るより
も、少ない回数で候補を絞ることができる。

【００８２】また追加情報の要求として入力させるが、
その追加情報の内容を適切に選択することにより利用者
に当然の質問と思われ、心理的負担を掛けることもな
い。さらに、シナリオを装置本体と独立させたことによ
りシナリオを変更することによって装置構成を変えずと
も、サービス環境に合致した情報案内を実施できる長所
もある。

【図面の簡単な説明】

【図１】Ａはこの発明の情報案内装置の機能構成例を示
すブロック図、Ｂは装置内に保持するフラグの例を示す
図である。

【図２】この発明の方法の処理手順の例を示す流れ図。

【図３】個人宅用電話番号データベースの例を示す図。

【図４】シナリオ／メッセージ辞書の例を示す図。

【図５】曖昧性解消処理の手順例を示す流れ図。

【図６】住所データベースの例を示す図。

【図７】個人宅電話番号データベースの他の例を示す
図。

【図８】シナリオ／メッセージ辞書の他の例を示す図。

【図９】上位概念と下位概念との関係例を示す図。

【図１０】上位概念と下位概念との他の関係例を示す
図。

【図１１】付帯情報をもつ個人宅電話番号データベース
の例を示す図。

【図１２】法人電話番号データベースの例を示す図。

【図１３】電話機のキーに仮名文字と英文字を割当てた
例を示す図。

【図１４】従来の方法の処理手順を示す流れ図。

フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩＨ０３Ｍ 11/08 Ｈ０４Ｍ 11/08 Ｈ０４Ｍ 3/42 Ｇ０６Ｆ 3/023 ３１０Ｋ 11/08 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/00 G06F 3/02 - 3/023 G06F 3/14 - 3/153 G06F 17/30 H03M 11/08 H04M 3/42

Claims

(57)【特許請求の範囲】

【請求項１】１つのキーに複数の文字が割当てられた
入力手段により、名義情報又は場所情報の一部がかな文
字での読みの各文字と対応する各１つのキーを１度操作
して利用者により入力されたキーシーケンスを受付ける
過程と、この受付けたキーシーケンスを検索キーとしてデータベ
ースの検索を行う過程と、その検索により複数の検索結果が得られると、ａ．これら複数の検索結果に関連する追加情報の入力を
上記利用者に促すガイダンスを提供する過程と、ｂ．上記追加情報が上記入力手段により上記と同様の手
法で上記利用者により入力された追加キーシーケンスを
受付ける過程と、ｃ．上記追加キーシーケンスとこれまでに得られた検索
結果とを用いて、上記複数の検索結果を絞り込む過程
と、その絞り込み結果が複数ある間は上記ａ乃至ｃの過程を
繰返す過程と、上記絞り込み結果が１つになると、その結果の情報を上
記利用者に提供する過程とを有し、上記ガイダンスを提供する過程における上記追加情報の
選択は、それまでの入力情報と検索結果と未入力の検索
キーとにより決る条件と、その条件に対応する適切な追
加情報とが各種記述された辞書を参照して条件と合致す
るものを探し、その合致した条件の追加情報により求
め、上記辞書には各追加情報を利用者に要求するためのメッ
セージも記述され、上記合致した条件と対応するメッセ
ージに対してその条件の追加情報、それまでに検出され
た検索結果を編集して利用者へ追加情報要求のメッセー
ジを送出する情報案内方法。
【請求項２】上記ａ乃至ｃの過程の繰返しによって
も、１つに絞り込むことができない場合は、残った複数
の検索結果を構成する情報を順次提供して、二者択一の
指定を受け付け、その指定により１つに絞り込むことを
特徴とする請求項１に記載の情報案内方法。
【請求項３】上記絞り込みの途中における検索結果
で、上記キーシーケンスのもつ情報の曖昧性がなくなっ
た時に、その時得られた情報の確認を利用者に求めるガ
イダンスを提供する過程を有することを特徴とする請求
項１又は２に記載の情報案内方法。
【請求項４】上記追加情報に名義情報及び場所情報以
外の情報をも用いることを特徴とする請求項１乃至３の
何れかに記載の情報案内方法。
【請求項５】上記絞込みが１つになった状態で、その
１つになった情報が有する各付帯情報ごとにそれを必要
とするかの問合せを順次行う過程と、上記問合せで必要
とする回答を検出して、対応する付帯情報を送出する過
程とを含むことを特徴とする請求項１乃至４の何れかに
記載の情報案内方法。
【請求項６】上記各キーに互いに異なる複数の英文字
も割当てられている入力手段により上記キーシーケンス
は入力されたものであることを特徴とする請求項１乃至
５の何れかに記載の情報案内方法。
【請求項７】最初に入力されたキーシーケンスと共に
入力されたその発信端末の識別情報からその発信端末の
設置地域を特定する過程と、その特定された地域情報を上記利用者により入力された
場所情報の少くとも一部として用いる過程とを含むこと
を特徴とする請求項１乃至６の何れかに記載の情報案内
方法。
【請求項８】利用者から曖昧性のあるキーシーケンス
の入力を受付ける入力手段と、情報が格納された情報データベースと、その情報データベースを検索する検索手段と、それまでの検索結果を条件とし、その条件と対応して次
に要求する追加情報が記述された辞書と、上記検索手段による検索結果が一意でない場合は上記辞
書を参照して追加情報を決定する曖昧性解消手段と、利用者に情報を要求する質問文データ、検索結果を利用
者へ提供する文のデータなどの出力用データを作成する
出力用データ作成手段と、上記出力用データを音声信号として利用者へ出力する出
力手段と、利用者より入力されたキーシーケンスと、利用者への質
問文データとにより表現される利用者との対話状況の監
視、その監視に基づく上記検索手段による検索の実行、
その検索の可否及び結果に基づく上記曖昧性解消手段の
動作制御、上記出力用データ手段及び上記出力手段の動
作制御を司る対話制御手段とを具備し、上記辞書には上記質問文データを作成するためのメッセ
ージの雛形がそれぞれ記述され、上記対話制御手段はそ
れまでの検索結果と、上記決定された追加情報と、これ
と対応するメッセージ雛形とから質問文データを編集し
て上記出力用データ作成手段へ供給する手段を有する情
報案内装置。
【請求項９】上記辞書の上記メッセージ離形に、上記
検索結果で上記キーシーケンスのもつ情報の曖昧性がな
くなった時に、その時得られた情報の確認を利用者に求
める確認メッセージ離形を含み、上記対話制御手段は上記決定された追加情報と対応する
確認メッセージ離形と、それまでの検索結果とから確認
文用データを編集して上記出力用データ作成手段へ供給
する手段を有することを特徴とする請求項８記載の情報
案内装置。
【請求項１０】上記辞書は、それまでに入力された検
索キーと、それまでに得られた検索結果との条件に対応
して、上記追加情報の入力を要求するアクションが記述
され、そのアクションに対応するメッセージ雛形が記述
されていることを特徴とする請求項８または９に記載の
情報案内装置。
【請求項１１】上記利用者からの最初のキーシーケン
スと共に入力されたその発信端末の識別情報からその発
信端末設置地域を特定する手段と、その特定された地域情報を、上記利用者からキーシーケ
ンスにより入力された場所情報の少くとも一部として用
いる手段とを有することを特徴とする請求項８乃至１０
の何れかに記載の情報案内装置。