JP2005148724A - 音声認識を用いた情報入力を伴う情報処理装置 - Google Patents

Abstract

【課題】 情報処理装置が単なる機械であることを利用者が認識してしまう音声解析結果のオウム返しをできるだけ回避し、しかも、利用者の要求を確認しつつ目的としている情報処理を確実に遂行することができる情報処理装置を提供すること。【解決課題】 キャラクタ映像と音声による質問を発し、利用者の音声を認識することによって並列的な複数の処理の１つを選択して実行する情報処理装置において、複数の処理のいずれを実行しているかおよび／または実行する予定であるかを判定する処理判定手段と、処理判定手段の判定結果に応じてキャラクタの容姿を変更するキャラクタ表示制御部と、を備える。【選択図】 図７

Description

本発明は、キャラクタの画像の表示、音声による質問、利用者からの音声による回答の音声認識を併用して、並列的な複数の情報処理の１つを選択して実行する情報処理装置に関する。

利用者とのインタフェースをより簡便なものとする情報処理装置として、キャラクタの画像および音声を用いて、処理過程で要求される情報の入力を案内する技術が提案されている。

例えば、特許文献１記載の技術では、利用者に応じた性格（世話好き、ひかえめ、泣き虫、正義感が強い、美人秘書風、優秀なマネージャー風、女子高生風など）のキャラクタ映像と音声を模擬し、自然に利用者の要求を引き出そうとしている。

また、特許文献２記載の技術では、それまでの学習結果に基づいて、キャラクタが運転者や車両に対して様々なバリエーションを持った対応（行動と音声）を採ることで、利用者の癖や環境に配慮し、あたかも対話しているかのようにして利用者の要求を引き出そうとしている。

特許文献３には、上述したようなキャラクタを用いて利用者と装置とが情報の授受を行うための手順、いわゆるシナリオの作成に関する技術が開示されている。特許文献１〜３には、利用者からの情報入力方法として、ボタン操作その他の装置に対する機械的な操作による方法の他、音声認識を利用する方法が開示されている。

特開平１１−２５９２７１号公報 特開平１１−２５９４４６号公報 特開２００４−５３２５１号公報

しかし、雑音の多い一般的な生活環境にある利用者の音声を判別することは比較的困難であり、認識不能や誤認識による誤動作が生じたりする恐れがある。これに対処するため従来の情報処理装置は、入力した音声を解析した結果に間違いがないかを確認するための質問文を利用者に発するように構成されている。例えば、「何か食べたい」という音声入力に対して、キャラクタは「お腹が減ったのですか」あるいは「何か食べたいのですか」という確認の質問を行う。利用者の回答と実質的に同じ意味の質問が返されることから、かかる質問を「オウム返し」と呼ぶものとする。

このようなオウム返しが用いられる結果、利用者は、同じ意味のことを違った言い回しで喋るなどの不便を強いられている。かかる状況では、利用者は、情報処理装置を単なる機械として認識しているに過ぎず、音声認識の本来の目的、即ち人間を相手にしているかのような自然なコミュニケーションを通じた情報入力という目的は実現されてはいない。特許文献１〜３記載の技術では、音声による入力を利用する場合に実用上、生じるこれらの課題については十分な検討がなされていなかった。このため、従来の情報処理装置は、キャラクタを用いてはいるものの、利用者と装置との間で音声を媒介とした実用的で円滑なコミュニケーションを実現することはできなかった。

本発明の情報処理装置は、上記問題点を解決するためになされたものであり、情報処理装置が単なる機械であることを利用者が認識してしまう音声解析結果のオウム返しを抑制し、装置と利用者との間で円滑な情報授受を実現することを目的とする。

本発明は、利用者からの音声入力に応じて動作する情報処理装置として構成することができる。この情報処理装置には、利用者との情報授受を通じて、予め規定された情報処理を実行するエージェントが、情報処理の種類に応じて一つ又は複数用意されている。複数用意されている場合には、情報処理装置は、これらのエージェントを選択的に使い分けることにより、複数種類の情報処理を実現することができる。本発明では、これらの情報処理の入出力時に、スピーカ等の音声出力装置から音声による質問を出力させる。これに対する回答は、マイク等を通じて利用者からの音声を取得し、その音声によって表される指示内容を認識することで入力する。予め用意されたエージェントは、この認識の結果に応じて稼働し、情報処理を進める。情報処理装置は、情報の音声入力時に、音声認識可能な語彙の範囲を利用者に推測させるための認識レベル情報を表示させる。

本発明によれば、利用者は音声入力時に使用可能な語彙の範囲を推測できるため、円滑な音声入力を実現することができる。また、回答が認識されなかった場合でも、「情報処理装置が認識可能な語彙範囲を超えていたことが原因である」と容易に推測可能となり、同じ回答の無用な繰り返しを抑制することができる。

認識レベル情報としては、例えば、「大人／子供」などの年齢区分、「日本語／英語」などの言語区分、「関西、関東・・・」などの地域区分の表示が挙げられる。また、認識レベル情報の別の態様として、質問に対する回答例を表示させてもよい。回答例とは、情報処理装置が理解・処理可能な回答の集合である「回答群」の一部または全部を意味する。一般に、音声による質問および回答では、回答方法の自由度が高いため、利用者が質問の真意に応じた適格な回答をすることができない場合がある。本態様では、回答例を表示することにより、利用者は容易に適切な回答を行うことができ、情報処理を円滑に進めることが可能となる。

回答例は、質問と合わせて音声出力させることも可能ではあるが、発明者による検討の結果、文字で表示する方法が最も実用的であることが見いだされた。音声出力させた場合には、回答例の読み上げに時間を要し、却って円滑な回答を妨げることになるからである。但し、本態様は、回答例の音声出力を完全に排除する趣旨ではない。例えば、回答が得られないまま一定期間経過した後などの条件下で、回答の音声出力を行うようにしてもよい。

上述の回答例には、概念範囲が異なる複数種類の回答を混在させてもよい。例えば、飲食店の種類を指定する回答については、「肉料理、魚料理、脂っこいもの」のように飲食店の種類を十分に限定できない回答や、「しゃぶしゃぶ、お寿司」のように種類を十分に限定可能な回答を混在させてもよい。前者の回答の場合には、飲食店の種類を段階的に特定するために次の質問を行えばよいし、後者の回答の場合には、かかる質問を省略すればよい。かかる構成によれば、利用者は、回答として要求される概念範囲に拘束されることなく自然な会話感覚で質問への回答を行うことができる。また、回答によっては、無用な質問が回避されるため、効率的に音声入力を進めることが可能となる。

情報処理装置には、音声認識可能な語彙の範囲が異なる複数の動作モードを設けても良い。この場合、認識レベル情報は、動作モードを表す情報とすることができる。動作モードの切り換えは、例えば、音声認識および情報処理に使用される辞書その他のデータベースを切り換えることにより実現することができる。このように複数の動作モードを設けることにより、利用者は、音声入力時に自分になじみのある言語を用いることが可能となり、より自然な会話を実現することができる。

情報処理装置は、スタンドアロンで稼働する装置として構成してもよいし、入出力用の端末とネットワーク等を介して接続してもよい。後者の態様では、情報処理装置は、端末に画像表示データや音声出力データを送信することで、端末のディスプレイへの表示、音声出力の制御を行う。また、端末から音声データを受信して、その音声認識を行い、情報処理を進めることになる。

本発明では、情報処理装置が、ディスプレイ等の表示装置に擬人化されたキャラクタを含む画像を表示させられるようにし、こうしたエージェントの選択を含む情報処理過程に応じて、キャラクタの容姿を変更するようにしてもよい。

かかる態様によれば、音声入力の解析中、解析の結果、その結果に基づく次の処理内容などの情報処理過程に応じてキャラクタの容姿が変更される。ここでキャラクタの容姿とは、例えば、キャラクタである擬人の服装、体型の他、キャラクタ顔の表情、腕、手、指の動き、足の動きおよびこれらの組み合わせとすることができる。

容姿は、あたかもキャラクタに内在する感情を利用者に感じ取らせるような視覚的表現としてもよい。こうすることにより、キャラクタの動きは極めて人間的となり、音声認識結果のオウム返しをできるだけ回避することができる。

本発明は、例えば、予め用意された所定のデータベースの検索処理を行う情報処理装置として構成してもよい。例えば、検索目的、検索条件の入力項目が異なるデータベースが複数用意されている場合、各データベースに対応してエージェントを用意しておくことにより、複数種類の検索処理を提供することができる。かかる情報処理装置では、音声によって、検索処理に関する質問を出力させ、それに対する回答に応じて検索処理を進めることができる。情報処理装置は、キャラクタの容姿を、検索処理過程に応じて変更する。

検索処理としては、例えば、経路案内装置における目的地の検索が挙げられる。かかる場合には、グルメ、旅行、ホテルなどのジャンルに応じてデータベースを使い分けることによって、それぞれの検索目的に最適の目的地を検索する。検索処理の別の例として、いわゆるオンラインショッピングにおける商品カタログの検索も挙げられる。かかる場合には、食品、ファッション、書籍などのジャンルに応じてデータベースを使い分けることによって、それぞれの検索目的に最適の商品を検索することが可能となる。このように本発明の情報処理装置は、データベースの使い分けを伴う種々の検索処理を対象とすることができる。

情報処理装置においてキャラクタを表示させる場合、キャラクタの容姿の変更は、感情を表し得るものには限られない。キャラクタが、複数の人物、動物、架空のロボットなど複数種類用意されている場合には、キャラクタの種類を変更するようにしてもよい。また、キャラクタの服装や持ち物などの外観を変更するようにしてもよい。利用者は、これらの変化によって、音声の認識が正常に認識されていることを知ることができ、円滑に検索処理を進めることができる。

検索処理を対象とするか否かに関わらず、本発明の情報処理装置には、更に、以下に示す種々の特徴を備えるようにしてもよい。第１に、音声認識による指示内容に応じた処理（以下、「特定処理」と呼ぶ）、例えば、エージェントの選択や各エージェントでの処理について、推奨および／または忌避するか否かを判断し、その判断結果に応じてキャラクタの容姿を変更するようにしてもよい。容姿変更の例として、キャラクタは特定処理を好んだり、嫌がったりするように振る舞うようにしてもよい。こうすることで、より好ましい処理を利用者に示唆することが可能となり、情報処理装置として特定処理の実行確率を高めることができる。また、キャラクタに人間的な癖、嗜好を与えることにより、利用者の心理に作用して、利用者がより自然にキャラクタに要望を伝えることが出来る利点もある。

ここでキャラクタが好んだり、嫌がったりする特定処理とは、予め定められている固定の処理に限らず、日時、現在地などの外部条件や情報処理装置がそれまでに辿った一連の処理の流れに応じて流動的に変化する処理あるいはこれらを組み合わせたものであってもよい。例えば、経路探索で目的地を探す際、特定の広告料が支払われた店舗や、現在地からアクセスが容易な店舗を推奨するようにしたり、渋滞が予想される経路上にある店舗を忌避したりするようにできる。

第２の特徴として、キャラクタの容姿を変更する方法が挙げられる。情報処理装置は、キャラクタを構成する構成部位ごとに相互に異なる印象を与える複数の構成部位を予め記憶し、この構成部位の組み合わせを変更することにより、キャラクタの容姿を変更することが好ましい。この様に構成される情報処理装置によれば、構成部位の組み合わせによってキャラクタの容姿が変更されるため、多様なキャラクタの容姿を構成部位の組み合わせという簡単な処理で実現することが出来る。また、一つの構成部位をキャラクタの複数の容姿に利用することが出来るため、構成部位の記憶容量が僅かであってもキャラクタに多様な容姿の変化を与えることができる。

第３に、キャラクタの容姿変更のタイミングが挙げられる。本発明においては、音声認識およびエージェントで使用されるデータベースの切り換えに応じてキャラクタの容姿を変更するようにしてもよい。双方のデータベースの切換時を対象としてもよいし、音声認識用のデータベースまたはエージェントで使用されるデータベースのいずれかの切換時のみを対象としてもよい。これらの態様では、キャラクタの容姿変更が、データベースの切換時に制限される。もっとも、制限とはいえ、処理の再起動時やエラー発生時などの異常時にキャラクタの容姿が変更されることを排除するものではない。

このように容姿の変更を制限することにより、利用者は、キャラクタの各容姿の意味を容易に理解することができ、円滑なコミュニケーションを実現することが可能となる。本態様を採らず、仮に、極端な例として、情報処理の過程で、利用者が何らかの回答を行うたびに頻繁にキャラクタの服装が変化したとする。この時、服装の変化によって利用者に与えられる情報は精密なものとなっているものの、利用者は、こうした変化に鈍感となり、与えられている情報を活用することができなくなる。これに対し、本態様のように、容姿の変化を制限した場合には、利用者は、与えられた情報を容易に理解、活用することができるようになる。

発明者は、本発明の開発
過程において、上記態様は、以下に示す点で、音声認識を介した情報授受に固有の効果、即ち情報授受をより円滑にすることができる効果が存在することを見いだした。一般に人間が使用する言語は多義的であり、単純な単語であっても会話のジャンルによって意味が異なる場合がある。例えば、「シングル」という用語は、宿泊施設については「部屋のベッド数」を意味し、ゴルフでは「ハンディキャップ」を意味し、お酒については「量」を意味する。また、状況によっては、「独身」を意味することもある。情報処理において、ジャンルを特定することなくこのような単語が用いられた場合には、その多義性に起因して、情報処理装置が指示内容を誤解する恐れがある。音声認識では、文字で直接入力された場合に比べて、音声から文字列への変換過程での誤差が含まれ得るため、誤解の可能性は更に増大する。

上記態様では、キャラクタの容姿を変更することで利用者に与えられる心理作用を通じて、こうした問題を解決することができる。まず、利用者は、キャラクタの容姿が変化することによって、多義的な用語であっても正しく理解されたことを容易に知ることができる。また、キャラクタの容姿が変化することによって、特定のジャンルに特化された処理が行われることを期待できるため、多義的な単語であっても安心して使用することができる。例えば、キャラクタの容姿が、ホテルのコンシェルジュスタイルなど宿泊施設の検索を表すものとなっている場合には、「ベッド数が一つ」などの回りくどい表現を考える必要なく、安心して「シングル」という用語を用いることが可能となる。こうした効果は、利用者に対して単語の選択範囲を規定する「ジャンル」を意識させる程度に大きな単位、即ちデータベース切換という単位で、キャラクタの容姿が変化することによって実現される。

第４の特徴として、エージェントに受け渡すための情報の生成方法が挙げられる。エージェントは、予め用意された複数種類のコードに応じて動作するよう構成されている場合が多い。コードは、狭義には一定の文字・数字の組み合わせからなる符号を意味し、広義には固定的なキーワード、コマンドも含む。このような場合、規定のコードと異なる情報が与えられてもエージェントは正常には動作しない。例えば、目的地の検索用のキーワードとして「動物園」を受け付けるよう構成されたエージェントでは、「ズー（ＺＯＯ）」と入力したり、「熊」や「象」などの動物名を入力したりしても、正しい目的地を検索することはできない。

そこで、本態様では、情報処理装置は、音声入力された指示内容の認識結果から所定のキーワードを抽出し、そのキーワードを、予め用意された対応関係に基づいて、エージェントが使用するコードのいずれかに変換する。こうすることにより、エージェントが使用するコードを認識していない利用者でも、所望の情報処理を容易に実行させることが可能となる。例えば、利用者が「熊が見たい」と言えば、情報処理装置は、「熊」というキーワードを抽出し、「動物園」というコードに変換してエージェントに受け渡すことにより、動物園の所在地を検索することが可能となる。

音声認識では、ボタン操作等による機械的な入力に比較して、利用者の回答の自由度が非常に高いため、本態様の変換機能は特に有用性が高い。上述の「対応関係」では、一つのコードに対して複数のキーワードが対応づけられていることが好ましい。こうすることで、回答の自由度を十分に補って、適正なコードを生成することが可能となる。なお、一つのキーワードが複数のコードに対応づけられていても構わない。

第５の特徴として、本発明の情報処理装置は、情報処理過程において、従前に入力された指示内容の少なくとも一部を表示させるようにしてもよい。音声での情報授受においては、利用者は従前の指定内容を忘れ、処理状況の把握に混乱を招くおそれがある。本態様では、従前の情報を表示することにより、こうした弊害を緩和し、適切な情報処理を促進することができる。

従前の指示内容の表示は、種々の態様を採ることができる。例えば、データベースの検索処理に条件Ａ、条件Ｂ…という複数の検索条件を指定可能である場合を考える。この場合、条件Ａ、条件Ｂ…の各条件に対応した表示部を設け、それぞれの表示部に指定内容を表示する方法を採っても良い。また、一つの表示部内に、指定済みの条件を、「条件Ａ」、「条件Ｂ」等のラベルとその内容の組み合わせで、一括して表示するようにしてもよい。各条件に表示部を設ける前者の態様では、利用者に対して全条件の指定を強いているかのような心理的圧迫が生じるのに対し、一つの表示部を用いる後者の態様では、かかる心理的圧迫を緩和することができる利点がある。

一つの表示部内に、入力済みの複数の指定内容を表示する場合、その順序は、種々の設定が可能である。例えば、入力された時間的順序と無関係に、予め設定された優先順位に従って表示するようにしてもよい。この優先順位は、状況に応じて可変としてもよい。例えば、表示部内に表示すべき情報の中に、「ジャンル」のように併せて表示されたキャラクタの容姿によって判断可能な情報が含まれている場合、キャラクタが表示されている時は表示部内での優先順位を下げ、キャラクタが表示されていない時は優先順位を上げるようにしてもよい。

一つの表示部を用いる場合、情報処理の過程で、従前に入力されていた指定が削除された時には、その内容のみならず、指定に対応するラベルも併せて削除することが好ましい。こうすることにより、表示内容が把握しやすくなるとともに、先に説明した心理的圧迫を緩和することができる。

第６の特徴として、本発明の情報処理装置は、処理の結果をソートするためのソート条件を利用者が入力可能とし、このソート条件に従って処理結果をソートして一覧表示させるようにしてもよい。この場合、ソート条件と、情報処理過程で入力される指示内容とは、相互に重複しない範囲に制限することが好ましい。例えば、経路探索の目的地を検索する処理の場合、ソート条件として、近い順、目的地での平均予算順などを指定し得る。本態様では、かかる場合には、検索時の検索条件からは、目的地までの距離、平均予算が除かれることになる。このようにすることで、検索条件を用いて対象を絞り込んだ後、結果をソートすることで、候補を最終的に確定するという、段階的な検索が可能となる。

仮に検索条件とソート条件に重複がある場合には、検索時に対象が過度に絞られたり、ソートが無用の機能となったりして非効率となりやすい。音声での情報授受は、一般に、質問の表示やボタン操作などの機械的な入出力に比較して、時間を要する傾向があるため、全過程の効率化に対する要請が特に強くなる。本態様では、上述した条件の区分によって、こうした要請に応えうる処理効率の向上を実現することができる。本態様において、ソート条件は任意に設定可能であるが、利用者にとって検索条件よりも優先度の低い条件、許容範囲の広い条件などを用いることが好ましい。

第７の特徴として、本発明の情報処理装置は、所定の条件下で、音声認識に異常がないことを利用者に報知するための応答を行うようにしてもよい。かかる条件としては、音声認識された指示内容が、エージェントの選択処理やエージェント自体の処理で用いられない内容（以下、「処理対象外」と称する）という条件が挙げられる。例えば、「クレジットカードの使用可否」という条件では検索不能なデータベースを利用した処理を行っている際に、利用者によって「クレジットカード」が指定された場合が相当する。

本態様では、かかる場合に、所定の応答によって、音声認識自体には異常がないことを利用者に報知することができる。応答は、例えば、「その条件は扱えません」などの音声出力や表示で行うことができる。一般に、音声認識を用いた情報入力において、利用者の意図した動作が行われない場合、利用者は音声認識が異常であったのか、指示した内容が不適切であったのか判断しかねることが多い。音声認識の異常が原因であると判断した場合、利用者は、同じ指示を声の大きさや速度を変えて繰り返し入力を試みるという無用な操作を行うことになる。本態様では、利用者は、少なくとも音声認識が正常に行われたことを把握できるため、こうした無用な操作を回避でき、処理の効率化を図ることができる。

第８の特徴として、本発明の情報処理装置においては、音声認識の結果から情報処理に利用可能なコードを生成するための処理に次の構成を適用してもよい。まず、音声認識の結果としては、発声内容を表す文字列が出力される。情報処理装置は、この文字列を受け取り、この文字列に基づいて、エージェントの選択やエージェント自体の処理に使用されるコードを生成する。コードの生成を、音声認識とは別のモジュールで実行することにより、音声認識とコードの生成を並列処理可能とする。こうすることにより、音声認識を行うモジュールの処理負荷を軽減することができ、リアルタイムでの音声認識を実現することができる。また、上述のコード体系に変更・追加が生じた場合でも、本態様によれば、音声認識用のモジュールを改変するまでなく、文字列とコードとの対応関係を修正するだけで容易に対処可能となる利点もある。

更に他の特徴として、情報処理装置は、過去の処理結果を記憶可能とし、この処理結果を再利用可能としてもよい。こうすることにより、過去の処理結果を有効活用することが可能となり、情報処理装置の利便性を向上させることができる。例えば、所定のデータベースの検索を行う機能を奏する情報処理装置の場合、検索結果や検索条件を再利用可能とする態様が挙げられる。検索条件を再利用する場合は、その一部について変更可能とすることが好ましい。

本発明は、上述した情報処理装置としての態様のみならず、種々の態様で構成することができる。たとえば、コンピュータを用いて、音声による質問を発し、利用者の音声による回答を認識することによって並列的な複数の処理の１つを選択して実行する情報処理方法として構成してもよい。また、かかる情報処理機能をコンピュータに実現させるためのコンピュータプログラム、およびかかるコンピュータプログラムを記録した記録媒体として構成してもよい。

ここで、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等の、コンピュータが読取り可能な種々の媒体を利用できる。

本発明の実施例について、次の項目に分けて説明する。 Ａ．実施例 Ａ１．ナビゲーションシステム Ａ２．処理（シナリオ）ＤＢのデータ構造 Ａ３．音声認識による情報入力処理 Ａ４．キャラクタ容姿ＤＢのデータ構造 Ａ５．ログＤＢのデータ構造 Ａ６．ナビゲーション処理 Ａ７．目的地特定処理 Ａ８．評価結果入力処理 Ａ９．飲食店検索処理 Ｂ．変形例 Ｂ１〜Ｂ１５．変形例１〜変形例１５

Ａ．実施例 以下の実施例では、本発明を経路探索および経路案内を行うためのナビゲーションシステムとして構成した場合を例にとって説明する。本発明は、ナビゲーションシステムに限らず、種々の装置に適用可能である。

Ａ１．ナビゲーションシステム 図１は、ナビゲーションシステムの構成を説明する説明図である。本ナビゲーションシステムは、ナビゲーション装置１００と、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００と、地図ＤＢ４００、ログＤＢ５００とを備えている。本ナビゲーションシステムは、車両に搭載され、車両の運転者（以下、ナビゲーションシステムを利用する者の総称として、「利用者」という）に対し、ナビゲーション機能を果たす。各ＤＢ２００，３００，４００，５００は、ナビゲーション装置１００が読み取り可能な記録媒体の形式で提供してもよいし、無線のネットワーク等を介して提供してもよい。

本ナビゲーションシステムの構成要素うち、ナビゲーション装置１００は、内部にＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたマイクロコンピュータを搭載しており、複数の機能ブロックから構成される。これらの機能ブロックは、このコンピュータ内において、ソフトウェア的に構成されているものとする。なお、もちろん、各機能ブロックを、適宜ハードウェア的に構成することも可能である。

ナビゲーション装置１００の各機能ブロックのうち、現在地取得手段１１０は、車両の現在地を取得する。現在地の取得には、種々の方法を適用可能であり、たとえば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を利用して検出する方法を適用することができる。この場合、ＧＰＳは、ＤＧＰＳ（Ｄｉｆｆｅｒｅｎｔｉａｌ ＧＰＳ）、ＲＴＫ−ＧＰＳ（Ｒｅａｌ Ｔｉｍｅ Ｋｉｎｅｍａｔｉｃ−ＧＰＳ）、ＶＲＳ（Ｖｉｒｔｕａｌ Ｒｅｆｅｒｅｎｃｅ Ｓｔａｔｉｏｎ）、ＶＲＳ−ＲＴＫ−ＧＰＳ（Ｖｉｒｔｕａｌ Ｒｅｆｅｒｅｎｃｅ Ｓｔａｔｉｏｎ−Ｒｅａｌ Ｔｉｍｅ Ｋｉｎｅｍａｔｉｃ−ＧＰＳ）を利用する方法も可能である。

目的地特定手段１２０は、入力手段１５０、出力手段１６０、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００、ログＤＢ５００との協働により、目的地を特定する。また、目的地特定手段１２０は、目的地の特定結果やその際に利用された検索条件などを、次回の特定時に利用可能にログＤＢ５００に格納する。

目的地の特定は、利用者とキャラクタとの一連の会話を通じて行われる。具体的には、まず、入力手段１５０の音声認識部１５２により、マイク１５１から入力された利用者の音声が認識される。音声の認識結果は、目的地特定手段１２０に送られる。エージェント制御部１２２は、送られた認識結果に基づいて、処理（シナリオ）ＤＢ２００に用意された複数の処理（シナリオ）データのいずれかを選択する。

ここで、処理（シナリオ）データとは、キャラクタによる質問に対し、利用者が回答すると想定される回答群、およびこの回答群に対する更なる質問という、シナリオ的に用意されたデータをいう。処理（シナリオ）データの詳細については後述する。本実施例では、目的地特定手段１２０内に、処理（シナリオ）データの種類に応じて、処理を実現するためのエージェントが複数設けられているが、図の煩雑化を回避するため、図１では図示を省略した。エージェントの構成についても処理（シナリオ）データと併せて後述する。上記処理（シナリオ）データの選択時には、併せて、その処理（シナリオ）データに対応したエージェントが選択される。

処理（シナリオ）データの選択結果は、キャラクタ表示制御部１２４に受け渡される。キャラクタ表示制御部１２４は、ディスプレイ１６４に表示すべきキャラクタの容姿を変更（決定）する機能を奏する。この機能としては、第１に、キャラクタ表示処理（シナリオ）データの選択結果に応じて、キャラクタの服装を決定する機能が含まれる。第２に、シナリオの実行中に、その処理過程に応じて、キャラクタの表情や動作を決定する機能が含まれる。

エージェント制御部１２２からの処理（シナリオ）データの選択結果、各シナリオの実行状況、およびキャラクタ表示制御部１２４からのキャラクタの容姿の決定結果は、データ取得手段１２６に受け渡される。データ取得手段１２６は、これらの情報に応じて、処理（シナリオ）ＤＢ２００およびキャラクタ容姿ＤＢ３００から、それぞれ処理（シナリオ）データおよびキャラクタ容姿データを取得し、出力手段１６０に受け渡す。データ取得手段１２６は、エージェントによる目的地の検索結果や、特定された目的地の表示に必要な地図データを、地図ＤＢ４００等から取得し、出力手段１６０に受け渡す。

出力手段１６０の映像／音声出力部１６２は、送られた処理（シナリオ）データおよびキャラクタ容姿データに基づき、ディスプレイ１６４にキャラクタ映像を表示するとともに、スピーカ１６３から音声による質問を発する。また、後述する通り、これらの質問に対する回答例や、目的地を検索する処理において利用者が従前に指定した条件なども併せて表示する。更に、目的地の検索結果の一覧や、目的地を示す地図なども表示する。

経路探索手段１３０は、現在地取得手段１１０が取得した現在地に関する情報と、目的地特定手段１２０が特定した目的地に関する情報を受けて、地図ＤＢ４００を参照しつつ、現在地から目的地までの経路を探索する。探索された経路に関するデータは、出力手段１６０に送られる。出力手段１６０は、送られた経路データに基づき、経路を出力（表示）する。

経路誘導手段１４０は、経路探索手段１３０により探索された経路を受けて、地図ＤＢ４００を参照しつつ、経路に関する誘導データを取得する。取得された誘導データは、出力手段１６０に送られる。

出力手段１６０の映像／音声出力部１６２は、送られた誘導データに基づき、映像や音声により、利用者を目的地まで誘導する。

Ａ２．処理（シナリオ）ＤＢのデータ構造 図２は、処理（シナリオ）ＤＢ２００のデータ構造を説明する説明図である。本実施例の処理（シナリオ）ＤＢ２００のデータには、目的地特定処理（シナリオ）データ２２０が用意されている。

ここで、目的地特定処理（シナリオ）データ２２０は、利用者の要求を確認し、経路探索の目的地の設定を支援することを目的とした処理（シナリオ）データであり、キャラクタによる質問とその質問への想定される回答群が、いわばシナリオ的に用意されているデータである。

本目的地特定処理（シナリオ）データ２２０は、具体的には、「どのお店にしますか？」との質問に対し、「お腹がすいた」、「ゴルフがしたい」、「宿泊先を探したい」、「温泉に行きたい」・・・などといった回答群で構成される。これらの回答のそれぞれには、グルメ処理（シナリオ）データ２４０、レジャー処理（シナリオ）データ２６０、ホテル処理（シナリオ）データ２８０、温泉処理（シナリオ）データ２９０が関連付けされており、利用者からの回答に応じて、関連付けされた処理（シナリオ）データが選択されるようになっている。

上記グルメ処理（シナリオ）データ２４０と、レジャー処理（シナリオ）データ２６０と、ホテル処理（シナリオ）データ２８０と、温泉処理（シナリオ）データ２９０は、目的地特定処理（シナリオ）データ２２０に、並列的に用意されている。

このうち、グルメ処理（シナリオ）データ２４０は、利用者の要求する食事（料理）のジャンルを確認することを目的の一つとした処理（シナリオ）データであり、キャラクタによる質問とその質問への想定される回答群が、いわばシナリオ的に用意されたデータである。グルメ処理（シナリオ）データ２４０内には、更に、料理のジャンルに応じて、ラーメン店検索処理（シナリオ）データ２４２、中華店検索処理（シナリオ）データ２４４、洋食店検索処理（シナリオ）データ２４６、和食店検索処理（シナリオ）データ２４８、イタリアン店検索処理（シナリオ）データ２５０などが用意されている。これらのデータ２４２〜２５０は、料理のメニュー等に応じて更に細分化したものを用意するようにしてもよいし、データ２４２〜２５０を省略し、グルメ処理（シナリオ）データ２４０で全ての料理店を統一的に扱うようにしても良い。

グルメ処理（シナリオ）データ２４０は、具体的には、「何かお店で買いますか？それともお店で食べますか？」との質問に対し、「買う」、「食べる」といった回答群で構成される。さらに、「食べる」との回答を得た場合に用意された、「ファーストフード、ファミリーレストラン、それともその以外」といった質問に対し、「ファーストフード」、「ファミリーレストラン」、「ラーメンが食べたい」、「中華がいい」、「洋食」・・・などといった回答群で構成される。なお、「ラーメンが食べたい」、「中華がいい」、「洋食」・・・などの回答のそれぞれには、ファーストフード店検索処理（シナリオ）、ファミリーレストラン検索処理（シナリオ）（いずれも図示省略）、ラーメン店検索処理（シナリオ）データ２４２、中華店検索処理（シナリオ）データ２４４、洋食店検索処理（シナリオ）データ２４６・・・が関連付けされており、利用者からの回答に応じて、関連付けされたデータが選択されるようになっている。

このうち、ラーメン店検索処理（シナリオ）データ２４２は、利用者の要求するラーメン店を確認することを目的とした処理（シナリオ）データであり、キャラクタによる質問とその質問への想定される回答群が、いわばシナリオ的に用意されたデータである。

本ラーメン店検索処理（シナリオ）データ２４２は、具体的には、「自分で探す？それともおまかせ？」との質問に対し、「自分」、「おまかせ」といった回答群である。さらに、「おまかせ」との回答を得た場合に用意された、「近くにする？それともちょっと遠くでもいい？」といった質問に対し、「近く」、「遠くでもいい」・・・などといった回答群で構成される。中華店検索処理（シナリオ）データ２４４など、その他の処理（シナリオ）データも同様に、各ジャンルに応じた料理店を検索するための質問と回答群から構成されている。

図の上方に示す通り、各処理（シナリオ）データ２４０、２６０、２８０、２９０には、それぞれグルメ処理エージェント２４０ａ、レジャー処理エージェント２６０ａ、ホテル処理エージェント２８０ａ、温泉処理エージェント２９０ａが設けられている。これらのエージェント群２４０ａ〜２９０ａは、図１で示した目的地特定手段１２０の内部に個別のモジュールとして設けられている。

グルメ処理エージェント２４０ａは、グルメ処理（シナリオ）データ２４０に沿って、利用者からの要望に沿う飲食店を検索する処理を実行するモジュールである。その他のエージェント２６０ａ、２８０ａ、２９０ａもそれぞれ、対応する処理（シナリオ）データを用いてレジャー施設、ホテル、温泉などの検索処理を実行する。本実施例では、このように検索のジャンルごとに処理（シナリオ）データおよびエージェントを個別に用意することにより、それぞれのジャンルに沿った検索処理を実現することができ、利用者の要望をより適切にかなえることが可能となっている。図中に示したエージェントの構成は一例に過ぎず、ジャンル等に応じ
て、ここに示した以外のエージェントを設けても良いし、図示したエージェントの一部を単一のエージェントで兼ね備える構成としてもよい。

後述する通り、本実施例では、利用者との情報授受を音声によって行う。この際、ナビゲーションシステムのディスプレイ１６４には、コンピュータグラフィックスで生成された女性（以下、「キャラクタ」と称する）の画像が表示される。このキャラクタは、目的地の検索処理の過程で、所定の条件下で、服装および表情を変化させる。本実施例では、図中に示すエージェントの選択時に、各エージェントのジャンルに応じた服装に変化させるものとした。図中に示す通り、グルメ処理エージェント２４０ａに対してはレストランのウェイトレス風の服装、レジャー処理エージェント２６０ａに対してはカジュアルな服装、ホテル処理エージェント２８０ａに対してはホテルのコンシェルジュ風の服装、温泉処理エージェント２９０ａに対しては温泉旅館の女将風の服装となっている。服装だけでなくアクセサリや帽子などを併せて変化させてもよいし、キャラクタの背景画像を変化させてもよい。キャラクタの画像を変化させるための処理方法については、後述する。

Ａ３．音声認識による情報入力処理 図３は音声認識による情報入力過程の処理を示す説明図である。図１の目的地特定手段１２０の構造において、音声認識部１５２からエージェント制御部１２２に情報を伝達するインタフェース部分のモジュール構成を詳細に示したものに相当する。このインタフェース部分には、ワード変換部１２７ａ、およびコード生成部１２８ａというモジュールが用意されている。また、これらのモジュールが利用するテーブルとして、ワード変換テーブル１２７ｂ、およびコード変換テーブル１２８ｂが用意されている。

ワード変換テーブル１２７ｂは、規定ワードとキーワードとを対応付けるテーブルである。規定ワードとは、エージェント制御部１２２および各エージェント２４０ａ〜２９０ａでの処理に用いられる予め固定的に設定されたキーワードである。本発明における広義のコードに相当する。図の例では、グルメ処理エージェント２４０ａが利用するキーワードである「ラーメン」を規定ワードの例として示した。

キーワードには、規定ワードの類義語が登録されている。この例では、「ラーメン」自体の他、「ヌードル」、「替え玉」などが登録されている。音声による情報入力では、利用者の回答に自由度が高いため、利用者は、必ずしも規定ワードに一致する回答を行うとは限らない。本実施例のワード変換テーブル１２７ｂを用いることにより、利用者が回答し得る広汎な用語を、規定ワードに関連づけることが可能となる。

コード変換テーブル１２８ｂは、規定ワードと、データ区分およびコードとを対応づけるテーブルである。データ区分とは、エージェント制御部１２２および各エージェント２４０ａ〜２９０ａの処理中のどの過程で用いられるべきかを表す情報である。「ｍｅｎｕ」はグルメ処理エージェント２４０ａが、料理店を特定するために用いられるべき情報であることを意味する。「ｇｅｎｒｅ」は、エージェント制御部１２２がエージェント２４０ａ〜２９０ａの選択に使用すべき情報であることを意味する。コードは、規定ワードを表す符号である。データ区分およびコードは、本発明における狭義のコードに相当する。

図示する通り、音声認識部１５２からは、利用者の音声に対応した情報が「文字列」の形で入力される。ワード変換部１２７ａは、この文字列から、ワード変換テーブル１２７ｂに存在するキーワードを抽出し、これに対応する規定ワードを出力する。この機能により、例えば、利用者が、「替え玉ができる店がいいなぁ」と応えた場合には、「替え玉」というキーワードに基づいて、「ラーメン」という規定ワードが出力されることになる。つまり、利用者は、人間同士の自然な会話をする感覚で必要な情報をナビゲーションシステムに入力することが可能となる。

こうして設定された規定ワードは、コード生成部１２８ａに受け渡される。コード生成部１２８ａは、コード変換テーブル１２８ｂを参照し、規定ワードに対応するデータ区分、コードを特定し、エージェント制御部１２２および各エージェント２４０ａ〜２９０ａに受け渡す。もっとも、ここで生成されるデータ区分、コードは、エージェント制御部１２２および各エージェント２４０ａ〜２９０ａの処理の便宜上設定するものであるため、コード生成部１２８ａを省略し、全て規定ワードで処理を実現するようにしてもよい。

上述したワード変換部１２７ａおよびコード生成部１２８ａは、音声認識部１５２内に設ける構成を採ることも可能であるが、本実施例では、図示する通り、目的地特定手段１２０の内部に、音声認識部１５２とは別モジュールとして設けた。こうすることにより、音声認識と並行して、規定ワードへの変換、およびコードの生成を実行することができるため、音声認識のリアルタイム性を保証しやすくなる利点がある。

図の下方には、グルメ処理（シナリオ）データ２４０を例にとって、その内部構造を示した。既に説明した通り、グルメ処理（シナリオ）データ２４０は、利用者に発せられるべき質問内容と、それに対する回答群とから構成されている。この例では、質問＃１「何かお店で買いますか？」に対する回答群として、「お店で食べる」、「お店で買う」が規定されている。この回答群が、先に説明した規定ワードに対応する。この回答群の文字列と併せて、コード変換テーブル１２８ｂ中に示したコードも設定されており、エージェント内での処理は、このコードに基づいて行われる。

各回答群には、それぞれ分岐先が設定されている。図の例によれば、利用者が「お店で食べる」と回答した場合には、分岐先である質問＃２「ファーストフード、ファミリーレストラン、その他？」の質問が展開されることになる。他の各エージェント２６０ａ〜２９０ａが利用する処理（シナリオ）データ２６０〜２９０でも同様に、質問、回答、分岐先がそれぞれ対応づけられている。また、図示を省略したが、回答群には、分岐先と併せて各エージェントが実行すべき処理を指定するコマンドも設定されている。これらのコマンドに応じて、エージェントは、利用者から選択された「回答」を、料理店などの検索条件として入力したり、後述する通り、ログＤＢ５００の検索を行ったりすることができる。処理（シナリオ）データは、図中に示した構造に限らず、質問、回答、分岐先の対応関係が特定可能な種々の構造を採ることが可能である。

図４は検索項目の指定方法を示す説明図である。グルメ処理（シナリオ）データについて、料理店の検索項目として、図の右側に示す各項目が指定可能である場合を例示した。例えば、「何が食べたい？」という質問に対し、利用者が「こってりしたもの」という回答をした場合を考える。この回答の「こってり」というキーワードは、ワード変換テーブル１２７ｂで予め対応づけられた規定ワード「脂っこいもの」に変換されるものとする。

グルメ処理エージェント２４０ａは、グルメ処理（シナリオ）データ２４０のうち、「脂っこいもの」という回答に対応する分岐先＃２１を参照する。この回答に対しては、単に「次の質問を発する」というコマンドが対応づけられているものとする。「脂っこいもの」という回答は、検索項目の入力条件としては不十分な情報だからである。

グルメ処理エージェント２４０ａは、次に＃２１欄に規定された質問を発する。この質問に対する回答群では、次の分岐先として＃３１が指定されるとともに、結果を検索項目のメニュー欄に入力する動作コマンドが設定されているとする。利用者が回答群にある「焼き肉、しゃぶしゃぶ、ステーキ」のいずれかを選択すると、グルメ処理エージェント２４０ａは、上述の設定に従い、選択された結果を検索項目のメニュー欄に入力し、＃３１欄の質問を発する。

＃３１欄の質問に対する回答群には、次の分岐先として＃４１が指定されるとともに、結果を検索項目の「目的」欄に入力する動作コマンドが設定されているとする。利用者が、「ファミリー」等の回答を選択すると、グルメ処理エージェント２４０ａは、利用者が選択した結果を検索項目の目的欄に入力する。このように、グルメ処理（シナリオ）データにおいて、ある質問に対する回答群に、次の分岐先および動作コマンドを設定しておくことにより、ナビゲーション装置１００と利用者との会話を通じて、目的地特定処理に必要な情報を順次、入力することが可能となる。

本実施例のグルメ処理（シナリオ）データでは、回答群に用意された回答ごとに、分岐先および動作コマンドを設定可能である。例えば、図中の＃１１の質問に対する回答群のように、各回答で異なる分岐先が指定可能である。同様にして、回答ごとに異なる動作コマンドも指定可能である。この結果、＃１１の質問に対して、利用者が、「フレンチ」や「イタリアン」のように、検索項目に直接入力可能な回答をした場合には、＃２１などのような詳細な質問をするまでなく、検索項目への入力を行うことができる。このように、回答群の中で、回答に応じてその後の処理を柔軟に制御することが可能となり、無用な質問および回答を省略できるため、利便性を向上することができる。

先に説明した通り、各回答群における規定ワードには、ワード変換テーブル１２７ｂにおいて複数のキーワードを対応づけることが可能であるため、利用者の広汎な回答に対処可能となり、それぞれの回答に対して適切な処理を実現することが可能となる。この結果、より自然な会話による円滑な情報入力を実現することができる。ここでは、グルメ処理（シナリオ）データ２４０を例示したが、他の処理（シナリオ）データも同様である。

Ａ４．キャラクタ容姿ＤＢのデータ構造 図５は、実施例にかかるキャラクタ容姿ＤＢ３００のデータ構造を説明する説明図である。本実施例のキャラクタ容姿ＤＢ３００のデータには、顔データ、手データ、体（服装）データ、足データといった、キャラクタ容姿を構成する構成要素が用意されている。

ここで、顔データには、我々人間が会話を通じて意思疎通を図るときに行なうしぐさ（表情）、たとえば、「普通の表情」はもちろん、「笑ったり」、「怒ったり」、「うなづいたり」などの表情を表したデータが用意されている。図５では、このうち、パターン１として「普通の表情」、パターン２として、「笑った表情」・・・が示されている。

また、手データには、我々人間が会話を通じて意思疎通を図るときに行なう手を用いたジェスチャー、たとえば、質問をする場合や何かを提案するの意を表現する「手を広げたジェスチャー」、喜びや祝福の意を表現する「拍手」、困難に直面している場合や受け入れ難いの意を表現する「腕組み」などのデータが用意されている。図５では、このうち、パターン１として「手を広げたジェスチャー」、パターン２として、「拍手」・・・が示されている。

また、体（服装）データには、利用者にナビゲーションサービスを提供する場面として相応しい服装（姿）、たとえば、図２中に示した各服装や、「レースクイーン服姿」、「チャイナ服姿」、「和服姿」・・・などのデータが用意されている。図５では、このうち、パターン１として「レースクイーン服姿」、パターン２として、「チャイナ服姿」・・・が示されている。

さらに、足データには、我々人間が会話を通じて意思疎通を図るときに行なう足によるジェスチャー、たとえば、「直立姿」はもちろん、「片足上げ姿」を表したデータが用意されている。図５では、このうち、パターン１として「直立姿」、パターン２として、「片足上げ姿」・・・が示されている。

キャラクタ容姿は、これらの部品の組み合わせで自然人の全身または半身が構成され、映像として映し出されるため、あたかもキャラクタに内在する感情を利用者に感じ取らせるような視覚的な表
現を指すことができる。

なお、上記顔データ、手データ、体（服装）データ、足データの各部品はその外形（静止画）であってもよいが、本実施例においては、よりキャラクタ容姿をより自然人のしぐさに近づけるため、顔の表情、手、足の動きを含むもの（動画）としている。

図５では、体（服装）データも含めて各パターンを構成する例を示した。これに対し、顔データ、手データ、足データで各パターンを構成し、体（服装）データはこれらと独立に扱うようにしてもよい。こうすることにより、各パターン、即ち顔データ、手データ、足データの組み合わせを、それぞれの服装で流用することができるため、データ容量を抑制することが可能となる。

Ａ５．ログＤＢのデータ構造 図６はログＤＢ５００のデータ構造を示す説明図である。ログＤＢ５００には、利用者が検索し、訪問した店舗についてのデータが格納されている。本実施例では、検索日、店情報、検索条件の各データを保存するものとした。店情報としては、店名、電話番号、住所、および緯度、経度などの位置情報を保存する。検索条件としては、図４で例示した検索項目を保存する。もっとも、これらは例示に過ぎず、更に詳細な情報を保存するようにしてもよいし、これらの情報の一部を省略してもよい。また、ログＤＢ５００には、利用者が訪問した店舗のみならず、検索した全結果を保存するようにしてもよい。

図中には、ログＤＢ５００の管理方法について併せて示した。ログＤＢ５００は、各エージェント２４０ａ〜２９０ａによって管理される。ここでは、グルメ処理エージェント２４０ａが管理する場合を例示した。各エージェント２４０ａ〜２９０ａとは別に、ログＤＢ５００の管理専用のエージェントを設ける方法を採ってもよい。但し、本実施例の構成によれば、検索条件など、保存すべきデータを、各エージェント２４０ａ〜２９０ａによって共通にする必然性がなくなるため、必要なデータを効率的に管理することが可能となる利点がある。

本実施例では、ログＤＢ５００のデータの有用性を高めるため、店舗利用後に、店舗に対する評価等を入力可能とした。グルメ処理エージェント２４０ａは、店舗利用後に、グルメ処理（シナリオ）データ２４０を参照して、スピーカ１６３から、検索条件のうち未入力の項目を入力するための質問や、店舗に対する評価等に関する質問を発する。図中では質問のみを示したが、グルメ処理（シナリオ）データ２４０の構造は、先に図４で示したのと同様、質問、回答群、分岐先から構成されている。

図中に示した質問の内、例えば、「誰と行ったの？」という質問は、検索条件の「目的」を埋めるために使用される。同様に、「雰囲気はどうだった？」、「おいしかった？」、「店員さんの感じは？」という質問は、それぞれ検索条件の「雰囲気」、「味」、「接客」を埋めるために使用される。これらの質問は、検索条件のうち未入力となっている全ての項目について行うようにしてもよいし、一部の項目を選択して行うようにしてもよい。利用者がマイク１５１を通じて音声入力した回答は、ワード変換部１２７ａで規定ワードに変換され、グルメ処理エージェント２４０ａによって、ログＤＢ５００に格納される。店舗評価等の入力処理およびログＤＢ５００の利用方法については、後述する。

Ａ６．ナビゲーション処理 図７は、ナビゲーション処理のフローチャートである。ナビゲーション装置１００のＣＰＵが実行する処理である。本処理は、利用者からナビゲーションシステムにナビゲーション実行の要求があった場合に起動し、現在地の取得から目的地の特定、現在地から目的地までの経路の誘導までの一連のナビゲーションが行われる。

まず、ステップＳ１００において、現在地取得手段１１０を用いた車両の現在地取得処理が行われる。ステップＳ１００において、車両の現在地が取得されると、次に、ステップＳ２００において、目的地特定手段１２０、入力手段１５０、出力手段１６０、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００、ログＤＢ５００の協働により目的地特定処理が行われる。本目的地特定処理（ステップＳ２００）においては、目的地の特定が、キャラクタ映像と音声による質問を発し、利用者の音声を認識するという一連の会話を通じて行われる。目的地特定処理の内容は後で詳述する。

ナビゲーション装置１００は、目的地特定処理によって目的地が特定されると、ステップＳ３００にて、経路探索手段１３０により、現在地取得手段１１０により取得された現在地から、目的地特定手段１２０により特定された目的地までの経路を探索する。この探索においては、地図ＤＢ４００が参照される。参照される地図ＤＢ４００には、道の繋がりを、ノードとリンクで表現した、いわゆる道路ネットワークデータが含まれている。また、探索のアルゴリズムとしては、周知のダイクストラ法を採用することができる。

最後に、ナビゲーション装置１００は、ステップＳ４００にて、経路誘導手段１４０により、経路探索手段１３０にて探索された経路の利用者に対する経路の誘導を行う。

この誘導においても、地図ＤＢ４００が参照される。参照される地図ＤＢ４００には、上記道路ネットワークのノードとリンクにそれぞれ関連づけされた音声や映像（画像）などの誘導データが含まれている。

Ａ７．目的地特定処理 以下、最初に、図５図８を用いて目的地特定処理（図７中のステップＳ２００）で用いられる画面表示例について説明した後、図９〜図１１のフローチャートを用いて、キャラクタと利用者との一連の会話を通じて、目的地が特定されるまでを、詳細に説明する。

図５図８は目的地特定処理時の画面表示例である。ナビゲーション装置１００のディスプレイ１６４の表示内容を例示した。図示する通り、目的地特定処理時に使用される表示は、地図の周囲に配置されたウィンドウＷａ１〜Ｗａ４を用いて行われる。ウィンドウＷａ１〜Ｗａ４は、全てを備えている必要はなく、その一部を省略したり、利用者が表示／非表示を切換可能としたりしてもよい。ウィンドウＷａ１は、処理中に音声で発せられる質問の内容を表示する。ウィンドウＷａ２は、この質問に対する回答例を表示する。図の例では、ウィンドウＷａ１に表示された「ご希望のお料理ジャンルは？」という質問に対し、「フレンチ／イタリアン…」が回答例となることを表している。

回答例とは、グルメ処理（シナリオ）データ２４０に用意された回答群の一部を例示したものを意味する。先に説明した通り、本実施例のナビゲーション装置１００は、ワード変換テーブル１２７ｂにキーワードとして登録されている単語も含めると、非常に広汎な語を認識可能となっている。回答例は、このように広汎な語の一部に相当する。図４に例示した通り、この回答例には、検索項目に直接入力可能な種類の回答、更に質問を重ねることで段階的な絞り込みが要求される種類の回答など、概念範囲が異なる回答が混在している。このように概念範囲が広狭混じった回答例を示すことにより、利用者は、ナビゲーション装置１００が理解可能な語の範囲を概ね把握することができ、こうした把握に基づいて自然な感覚で回答することが可能となる。

ウィンドウＷａ３は、利用者が従前に入力済みの条件を表示する。この例では、ジャンル、メニュー、施設サービスなどについての条件が表示されている。利用者が未指定の項目については、表示されない。ウィンドウＷａ３は、これらの項目に対応した個別の表示枠を設ける構成とすることも可能であるが、本実施例では、敢えてこれら全体を一つのウィンドウ内にまとめて表示する態様を採用した。各項目は、ジャンル、メニュー等の項目ラベルと、指定内容の組み合わせで表示される。

こうすることにより、例えば、施設サービスのように、複数指定される可能性がある条件について、表示枠の制約を受けずに漏れなく表示することができる利点がある。また、表示枠を用いた場合には、ブランクの項目について、入力を強制する心理的圧迫が利用者に与えられるが、本実施例の態様では未指定の項目は表示されないため、こうした心理的圧迫を緩和することができる。かかる観点から、例えば、入力済みのいずれかの項目が、処理の途中で利用者によってキャンセルされた場合には、ウィンドウＷ３から、その項目の内容のみならず項目ラベル自体も削除することが好ましい。

一般に音声での情報授受では、利用者は従前に指定した条件を忘れがちであり、検索処理の現状を誤解する可能性がある。ウィンドウＷａ３に表示される情報は、こうした誤解を回避し、効率的な検索処理を支援することができる。

ウィンドウＷａ４には、キャラクタの画像が表示される。先に図２で説明した通り、キャラクタの服装は、検索処理の過程で、特にエージェント２４０ａ〜２９０ａの選択に伴って変更される。いずれかのエージェントが選択された後は、他のエージェントが改めて選択されない限り、服装は変化しない。本実施例では、このようにキャラクタの服装を制限的に変化させるものとしている。こうすることにより、利用者は、各服装の意味を容易に理解することができ、自己が意図した通りのエージェントによる処理が実行されていることを容易に認識することが可能となる。もっとも、服装の変化は、エージェントの選択時にのみ制限する必要はなく、例えば、音声認識に使用されるデータベースや検索処理に使用されるデータベースの変更に伴って変化させるようにしてもよい。以下で示すフローチャートは、以上で説明した表示を併用して実行される。

図９は、目的地特定処理（シナリオ）のフローチャートである。ナビゲーション装置１００は、まず、ステップＳ２０２にて、初期状態のキャラクタ容姿データ（映像データ）と最初の質問を発するための処理データ（音声データ）を取得し、ステップＳ２０４にて、キャラクタ映像と音声を出力する。この場合、出力される映像は、初期状態の容姿であり、例えば、顔「普通の表情」、手「手を広げたジャスチャー」、体（服装）「レースクイーン服姿」、足「直立姿」であるものとする。また、最初の質問は、「どんなお店に行きますか？」であるものとする。

この質問内容は、ナビゲーション装置１００のウィンドウＷａ１に表示されるとともに、「グルメ」、「レジャー」などの回答例がウィンドウＷａ２に表示される。この時点では、入力済みの情報は存在しないため、ウィンドウＷａ３はブランクの状態である。

これを受けて、利用者が音声で回答を行うと、ナビゲーション装置１００は、ステップＳ２０６にて、利用者の音声を入力する。この場合、「お腹がすいたなー」が入力されたものとする。入力された音声データは、ステップＳ２０８にて、ナビゲーション装置１００の音声認識部１５２に受け渡される。音声認識部１５２は、この音声データの音声認識を行い（ステップＳ２１０）、認識の結果に基づいて処理（シナリオ）ＤＢ２００に用意されたいずれかのシナリオおよびそれに対応するエージェントの選択を行う（ステップＳ２１２）。

例えば、「お腹がすいたなー」との回答を受けた場合には、ナビゲーション装置１００は、利用者が空腹であると判断し、グルメ処理（シナリオ）データ２４０およびグルメ処理エージェント２４０ａを選択する。先に図３で説明した手順に即して、この処理を説明する。まず、「お腹がすいたなー」という文字列を受け、ワード変換部１２７ａが、これを規定ワードに変換する。例えば、「お腹がすいた」というフレーズをキーワードとして、「グルメ」という規定ワードに変換する態様を採ることができる。次に、コード生成部１２８ａは、この規定ワード「グルメ」に対して、データ区分およびコードを設定する。図３に示した通り、データ区分としては「ｇｅｎｒｅ」が設定されるため、この規定ワードに対応するコードは、エージェントの選択に使用されることになる。

エージェ
ント制御部１２２による処理（シナリオ）データの選択結果を受け、キャラクタ表示制御部１２４が作動して、選択結果に応じた容姿を決定する。例えば、グルメ処理（シナリオ）が選択された場合には、顔「笑い表情」、手「拍手」、体（服装）「ウェイトレス姿」、足「片足上げ姿」の容姿に変更（決定）される。また、利用者の回答に応じて、処理（シナリオ）データに従って、次に発すべき質問が決定される。ナビゲーション装置１００は、こうして決定された容姿を表示するための画像データ、および質問内容に相当する音声データを取得し（ステップＳ２１４）、出力する（ステップＳ２１６）。

ここで、顔が「笑い表情」、手が「拍手」、足が「片足上げ姿」に変更されたのは、ナビゲーション装置１００が、利用者の回答に同意していることを意味する。このキャラクタの容姿の変更により、利用者は、自己の要望に対して適切な検索結果が得られると期待してもよいと推測することができる。

こうした同意の表情および動作は、例えば、利用者の要望を実現するための困難度を指標化し、この困難度指標に基づいて制御する方法を採ることができる。困難度指標は、一例として、利用者の要望に添う目的地までの距離、目的地の混雑予想、目的地までの混雑予想などの項目と、指標との関係を予めマップとして用意しておくことにより、求めることができる。混雑予想は、例えば、時間帯との関係で設定することができる。困難度指標が所定値を超える場合には、キャラクタに、非同意の表情や動作をさせるようにしてもよい。

上述の処理に引き続いて、図９のステップＳ２１２で選択された各エージェントの処理が実行される。ここでは、グルメ処理（シナリオ）が選択された場合を例にとって、処理内容を説明する。他の処理が選択された場合も、処理（シナリオ）データの内容に応じて質問内容等が相違するのみであり、フローチャートとしては同等である。

図１０は、グルメ処理（シナリオ）のフローチャートである。まず、ステップＳ２３２にて、ナビゲーション装置１００は、キャラクタ容姿データ（映像データ）と処理データ（音声データ）を取得し、ステップＳ２３４にて、キャラクタ映像と音声を出力する。ここで、出力される映像は、顔「笑いの表情」、手「手を広げたジェスチャー」、体（服装）「ウェイトレス姿」、足「直立姿」であり、出力される音声は、「何かお店で買いますか？それともお店で食べますか？」である。

これを受けて、ステップＳ２３６にて、利用者の音声が入力される。この場合、「お店で食べる」が入力されたものとする。ナビゲーション装置１００の音声認識部１５２は、入力された音声を受け取り（ステップＳ２３８）、音声認識を行う（ステップＳ２４０）。認識の結果、利用者はお店で食べることを要求していると判断されるため、グルメ処理（シナリオ）データ２４０に用意された次の質問「ファーストフード、ファミリーレストラン、それともそれ以外」が出力される（ステップＳ２４２）（図３参照）。

これを受けて、ステップＳ２４４にて、ナビゲーション装置１００は、利用者の音声を入力する。この場合、「ラーメン」が入力されたものとする。音声認識部１５２は、入力された音声データを、ステップＳ２４６にて受け取り、音声認識を行う（ステップＳ２４８）。認識の結果、利用者はラーメンを食べることを要求していると判断されるため、ナビゲーション装置１００は、グルメ処理（シナリオ）ＤＢ２４０に用意された処理（シナリオ）のうち、ラーメン検索処理（シナリオ）データ２４２を選択する（ステップＳ２５０）。ナビゲーション装置１００は、この処理に応じて、キャラクタの表情、動作および次の質問事項を決定し、それに対応するデータを取得して、キャラクタの画像および質問を出力する（ステップＳ２５２、Ｓ２５４）。

本実施例では、ラーメン検索処理への移行時には、検索に使用されるデータベースが変更されていないため、服装は変化させないものとした。これに対し、ラーメン店検索用のデータベースが用意されている場合には、「チャイナ服姿」など、ラーメン検索処理（シナリオ）に相応しい服装に変更させてもよい。これにより、利用者は、自分がラーメンを食べたいという要望がキャラクタに伝わったと認識することができる。

図１１は、ラーメン店検索処理（シナリオ）のフローチャートである。なお、図１１においては、キャラクタ容姿データや処理（シナリオ）データの取得方法は、図９、図１０と同じであり、ここで繰り返し説明すると冗長となり、かえって分かりにくくなるため、説明の便宜上、省略することとする。

まず、ステップＳ２５２にて、ナビゲーション装置１００は、キャラクタ映像と音声による質問を出力する。質問は、「自分で探す？それともおまかせ？」であり、ここでは、会話の主導権をどちらが握るかを確認している。

これを受けて、ステップＳ２５４にて、利用者の音声が入力される。この場合、「おまかせ」が入力されたものとする。ナビゲーション装置１００は、入力された音声を認識し、次の「近くにする？それともちょっと遠くでもいい？」という質問を出力する（ステップＳ２５６）。

これを受けて、ステップＳ２５８にて、利用者の音声が入力される。この場合、「近くでお願い」が入力されたものとする。ナビゲーション装置１００は、入力された音声を認識し、近くのラーメン店の検索を開始する。ナビゲーション装置１００は、まず、現在地を取得し（ステップＳ２６０）、地図ＤＢ４００に用意されたラーメン店のうち、近くのラーメン店を検索し（ステップＳ２６２）、その店の映像（たとえば、店舗の雰囲気、メニュー、実際のラーメンの写真）を現在地に近い順に表示する（ステップＳ２６４）。利用者が、表示されたラーメン店から好みを選んで指定すると（ステップＳ２６６）、目的地の設定が完了する（ステップＳ２６８）。

図１１では、ラーメン店の検索条件として、「近く」という条件のみを指定する場合を例示したが、複数の検索条件を指定可能としてもよい。例えば、施設サービスに関する条件として、「個室有り」、「駐車場有り」、「クレジットカード利用可能」などの条件を並行して指定する態様が考えられる。このように多彩な条件を指定可能とする場合、指定内容によっては、データベースの検索項目として不適当な条件が含まれるおそれがある。このような例としては、検索項目として「クレジットカードの使用可否」が登録されていないデータベースを用いているにもかかわらず、利用者から「クレジットカード使用可能」という条件が指定されるという態様が挙げられる。

本実施例では、処理（シナリオ）データに、「その条件には対応しておりません」などのデフォルトの応答を用意しておくものとした。この応答は、処理（シナリオ）データに規定されている内容以外の回答がなされた場合に行われる。こうしておくことにより、利用者は、自己の指定した条件が認識されない場合、音声認識の不良が原因ではなく、指定した条件自体が不適切である点に原因があることを容易に知ることができる。従って、再度、同じ条件を発声するという無駄な操作を回避することができ、円滑に条件入力を完了させることができる。

本実施例においては、検索結果は、「近い順」に提示されるものとしたが、このようなソート条件は、検索が完了した後、検索条件とは別に指定可能としてもよい。かかる態様では、現在地点から○○ｍ以内など、距離に関する条件は検索条件から削除し、検索条件とソート条件との重複を回避することが好ましい。こうすることにより、検索条件による検索と、ソート条件によるソートを用いた２段階での評価を効率的に行うことができ、所望の目的地を比較的容易に見つけることが可能となる。ソート条件としては、利用者の重要度が比較的低い条件や、許容度が比較的緩やかな条件を用いることが好ましい。かかる条件としては、上述の「近い順」という条件や、「値段の安い順」という条件などが挙げられる。

Ａ８．評価結果入力処理 図１２は評価結果入力処理のフローチャートである。ナビゲーション装置１００のＣＰＵが実行する処理である。本処理は、利用者から評価結果入力の要求があった場合に起動する。また、現在地取得手段１１０によって、ナビゲーション装置１００が案内した店舗から利用者が移動したことを検出した時点で自動的に起動するようにしてもよい。

この処理が開始されると、ナビゲーション装置１００は、ログＤＢ５００を読み込み（ステップＳ３００）、処理対象となっている店舗の検索条件を点検する。そして、この中に未入力の項目がある場合には（ステップＳ３０１）、検索項目に該当する質問を出力する（ステップＳ３０２）。そして、この質問に対して利用者が入力した回答を音声認識し（ステップＳ３０３）、処理の終了指示でなければ（ステップＳ３０４）、回答に応じて検索項目を入力し、ログＤＢ５００に保存する（ステップＳ３０５）。例えば、先に図６で示した通り、検索項目「目的」が未入力となっている場合には、「誰と行ったの？」という質問を発する。利用者が、これに対し、「家族と」というような回答をすれば、ナビゲーション装置１００は、「目的」の項目に「ファミリー」と入力することになる。

ナビゲーション装置１００は、上述の処理を、未入力の検索項目が無くなるか（ステップＳ３０１）、利用者が処理の終了を指示する間で（ステップＳ３０４）、繰り返し実行する。もっとも、検索項目は必ずしも全てを入力する必要はないため、未入力の検索項目のうち一定数または一定割合の項目の入力が完了した時点で、未入力の検索項目が残っているか否かに関わらず処理を終了するようにしてもよい。

Ａ９．飲食店検索処理 図１３は飲食店検索時におけるログＤＢ５００の活用方法を示す説明図である。目的地特定処理（図９）の過程で、グルメ処理エージェント２４０ａが飲食店の検索を行う際の処理、即ち図１０のステップＳ２４０以降の処理（以下、「飲食店検索処理」と呼ぶ）での活用方法に相当する。

ワード変換テーブル１２７ｂ、グルメ処理（シナリオ）データ２４０において、飲食店検索処理に用いられる情報を例示した。ワード変換テーブル１２７ｂには、規定ワード「先日」、「付近」、「似たお店」などに対して、「この前」など、それぞれ図示するキーワードが登録されている。グルメ処理（シナリオ）データ２４０には、「どんなお店がいい？」などの質問に対し、上述の規定ワードが回答群として登録されている。グルメ処理エージェント２４０ａは、グルメ処理（シナリオ）データ２４０に従って、質問を発し、それに対する回答に応じて、分岐先に規定された次の質問を発するという処理を繰り返す。この過程で、「先日」、「付近」という回答がなされた場合には、ログＤＢ５００を検索して、最近訪れた店舗や現在位置に近い店舗の情報を、利用者に適宜、表示する。

図１４は飲食店検索処理のフローチャートである。グルメ処理エージェント２４０ａが、図１３で示したワード変換テーブル１２７ｂ、グルメ処理（シナリオ）データ２４０に沿って、ログＤＢ５００を有効活用しながら、飲食店検索を実行する処理である。

処理が開始されると、グルメ処理エージェント２４０ａは、グルメ処理（シナリオ）データ２４０の＃５１の質問「どんなお店がいい？」を発し（ステップＳ４００）、利用者の回答を音声認識する（ステップＳ４０１）。例えば、ユーザが「この前、行ったお店がいいなあ」と回答すれば、ワード変換テーブル１２７ｂの規定ワード「先日」が回答されたものとして扱われる。「この辺にいいお店がなかったかなあ」と回答すれば、規定ワード「付近」が回答されたものとして扱われる。図の例では、「先日」と「付近」を回答群として例示したが、図４に示した「フレンチ／イタリアン・・・」など飲食店のメニューを特定するための回答を回答群に含めても良い。

「先日」が回答された場合は（ステップＳ４０２）、グルメ処理エージェント２４０ａは、検索日をキーとしてログＤＢ５００を検索し、訪れた日が近い順に５つデータを抽出する（ステップＳ４０３）。「付近」が回答された場合には（ステップＳ４０２）、グルメ処理エージェント２４０ａは、現在地取得手段１１０（図１参照）を用いて、現在位置を取得し（ステップＳ４０４）、ログＤＢ５００から、現在位置に近い順に５つデータを抽出する（ステップＳ４０５）。ステップＳ４０３、Ｓ４０５において、抽出するデータ数は５つに限らず任意に設定可能である。

こうしてログＤＢ５００からのデータ抽出が完了すると、グルメ処理エージェント２４０ａは、その結果を表示して、分岐先＃６１の質問「このお店？」を発し（ステップＳ４０６）、利用者の回答を音声認識する（ステップＳ４０７）。ログＤＢ５００から複数のデータを抽出している場合、本実施例では、これらのデータを一定時間おきに順次表示しながら、「このお店？」という質問を発する方法を採った。他の方法として、複数のデータを番号その他のインデックスとともに、一覧表示し、利用者にはインデックスで店舗を指定させるようにしてもよい。

ユーザが「このお店」と回答すれば、目的地が決定するため（ステップＳ４０８）、飲食店検索処理を終了する。上述のインデックス等で店舗を指定した上で、「このお店」と回答した場合も同様である。

一方、「似たお店」と回答すれば（ステップＳ４０８）、表示された検索条件を流用して、別の店舗を検索することになる。先に、ステップＳ４０２で、「先日」や「付近」以外の回答をした場合も同様である。店舗の検索時には、ナビゲーション装置１００は、目的地特定処理（図９〜１１）と同様の会話を通じて、検索条件を入力する（ステップＳ４０９）。ログＤＢ５００から店舗のデータが抽出されている時は、検索条件の全てを新規に指定する必要はなく、利用者は、そのデータに登録された検索条件の変更指示を行えばよい。例えば、「この条件で検索する？」という質問に対し、「今度は家族じゃなくてデートなんだ」と回答することにより、検索項目の「目的」を「ファミリー」から「デート」に変更することができる。こうした変更指示も、グルメ処理（シナリオ）データ２４０およびワード変換テーブル１２７ｂの設定によって実現することができる。

グルメ処理エージェント２４０ａは、指定された検索条件で店舗の検索を行って（ステップＳ４１０）、目的地が決定するまで、ステップＳ４０６以降の処理を繰り返し実行する。以上の説明では、グルメ処理エージェント２４０ａによる処理例を例示したが、ログＤＢ５００の活用は、他のエージェントでも同様に可能である。

以上で説明した本実施例においては、キャラクタの動きは極めて人間的となり、音声解析結果のオウム返しを回避することができる。また、エージェントの選択をトリガとして、キャラクタの服装が変化するため、利用者は複数の処理（シナリオ）のうち、自己の意図した処理が実行されていることを容易に認識することができる。こうした作用の少なくとも一部による効果として、本実施例によれば、利用者は、音声による情報入力を円滑に行うことができる。

Ｂ．変形例Ｂ１．変形例１ 上記実施例（特に、図１）において、ナビゲーションシステムの全ての構成要素、すなわち、ナビゲーション装置１００、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００を車両に搭載するようにしたが、これに限らず、頻繁に更新処理がなされる処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００を車両から切り離し、車両外に設置する構成とすることも可能である。すなわち、図１に示すナビゲーションシステムについて、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００に格納されたデータを車両外のサーバ装置等から無線通信により、提供するのである。こうすることにより、各利用者が、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００のデータを個別に管理する必要がなくなるとともに、常に最新のデータを利用可能となるメリットがある。

Ｂ２．変形例２ 変形例１に加え、更に、目的地特定手段１２０、経路探索手段１３０、経路誘導手段１４０の少なくとも一部を車両から切り離し、車両外に設置する構成とすることも可能である。すなわち、図１に示すナビゲーションシステムについて、目的地特定手段１２０、経路探索手段１３０、経路誘導手段１４０の少なくとも一部を車両外のサーバ装置等に用意し、ナビゲーション装置１００に対して、無線通信により、ナビゲーションサービスを提供するのである。こうすることにより、各ナビゲーション装置の処理能力が低くても本発明を実現することができるとともに、常に最新の状態に機能アップされた目的地特定手段１２０、経路探索手段１３０、経路誘導手段１４０を利用することができるメリットがある。

Ｂ３．変形例３ キャラクタの容姿を表すためのデータは、実施例で例示した顔データ、手データ、足データからなる構成よりも、さらに細分化してもよい。たとえば、顔データを、目データ、鼻データ、口データ、耳データ、輪郭データ、髪型データなど、自然人の顔を構成する要素をそれぞれ部品に細分化して用意するのである。これにより、さらに、キャラクタの表情・動作を多様に変化させることができる。

Ｂ４．変形例４ 上記実施例（特に、図５）において、キャラクタ容姿ＤＢ３００によって用意されるデータは、全て自然人をモデルとしたものであったが、これに限らず、意志疎通を図るモデルとして利用者に好適なものであれば、動物、植物、その他有名なキャラクタであっても構わない。

Ｂ５．変形例５ 上記実施例（特に、図９）の目的地特定処理（シナリオ）において、キャラクタは、最初から店舗を案内する目的で、「どのお店にしますか？」と質問しているが、お店以外、たとえば、勤務する会社、通学する学校、その他駅などの具体的な施設であることも想定し、「どこに行きますか？」と質問するよう構成してもよい。この場合、想定される回答群としても、「会社」、「学校」、「○○」・・・などの回答群を用意しておくことが好ましい。このような構成にすることにより、利用者の多様な要求に応えることができる。

Ｂ６．変形例６ 上記実施例（特に、図１１）のラーメン店検索処理（シナリオ）において、利用者がラーメン店の選択を「おかませ」とした場合、キャラクタは、車両の現在地近辺のラーメン店を現在地に近い順に推奨する構成としたが、これに限らず、特定の広告料が支払われたラーメン店を優先して推奨してもよい。推奨の基準は、広告料のみに限らず、商品の割引率、駐車場の有無など、多数の利用者が好むものを採用することができる。このような構成であれば、利用者に対し、適切な店舗を案内できるメリットがある。

Ｂ７．変形例７ 変形例３において、キャラクタが行う案内は、店舗の推奨に限らず、店舗の忌避であってもよい。忌避の基準は、渋滞が予想経路や地域のほか、店舗自体の込み具合など、多数の利用者が嫌がるものを採用することができる。このような構成であれば、利用者に対し、不適切な店舗を案内せずにすむメリットがある。

Ｂ８．変形例８ 特定の店舗の推奨および忌避の基準は、多数の利用者の好みに限らず、車両の利用者個人の好みであってもよい。この場合、利用者個人の好みは、実際に店舗に行った後に感想を質問し、その回答内容に応じてポイントを関連づけておき、この関連づけられたポイントを基準として推奨や忌避を行う構成を採用することができる。このような構成であれば、利用者個人に応じた店舗を案内することができる。

Ｂ９．変形例９ 上記実施例（特に、図９〜７）において、キャラクタが発する質問は、「〜しますか？」のように丁寧な言葉であったが、これに限らず、「〜する？」のように親しい間柄で用いられる言葉（俗に言う、ため口）としてもよい。これらの言葉は、同伴者の有無によって使い分けることが効果的であり、たとえば、ナビゲーション処理の開始時や、処理中に適宜問い合わせる構成を採ることができる。このような構成であれば、利用者との会話が、より自然なものとなるし、同伴者に不愉快を与えることもない。

Ｂ１０．変形例１０ 上記実施例において、会話の主導権をどちらが握るかの確認は、ラーメン店検索処理（シナリオ）におけるステップＳ２５２で行うよう構成したが、これに限らず、ナビゲーション処理の開始時や、処理中に適宜問い合わせる構成を採ることができる。また、会話の主導権の確認は、どちらか一方といったような両極端のものだけでなく、その中間的なものを組み込む構成を採ることもできる。たとえば、食事をとれるお店を決める場面でも、そのようなお店が近づいた場合に知らせるのみの利用者主導と、食事をとるお店がラーメン店であり、しかも二番目に近いお店であることまでを決めるキャラクタ主導（いわゆる、おかませモード）の両極端があった場合に、その中間として、食事をとるお店としてラーメン店が相応しいことを決めるまでのものを組み込むのである。このような構成であれば、キャラクタとの会話に過不足が発生することなく、利用者の要求を満たすような会話を成立させることができる。

Ｂ１１．変形例１１ 上記実施例（特に、図９〜７）において、キャラクタ表示制御部による容姿の変更（決定）は、実行中の処理（シナリオ）または実行予定の処理（シナリオ）などといったような、単一の処理（シナリオ）に基づく処理判定手段の判定結果に応じて行う構成としたが、これに限らず、実行中と実行予定の処理（シナリオ）の両者を加味し、複数の処理（シナリオ）に基づく処理判定手段の判定結果に応じて行う構成を採ることもできる。たとえば、グルメ処理（シナリオ）を実行中であって、主導権がキャラクタにあることが確認され、さらにラーメン店検索処理（シナリオ）を実行予定といった場面においては、キャラクタは、自信満々の表情を継続させ、反対に、グルメ処理（シナリオ）を実行中であって、主導権が利用者にあることが確認され、さらにラーメン店検索処理（シナリオ）を実行予定といった場面においては、キャラクタは、普通の表情を継続させるなどである。このような構成であれば、利用者との会話を、より自然なものとすることができる。

Ｂ１２．変形例１２ 上記実施例において、ナビゲーションシステムは、車両用に特化して説明したが、これに限らず、歩行者用とすることも可能である。この場合、経路探索手段１３０、経路誘導手段１４０、処理（シナリオ）ＤＢ２００、キャラクタ容姿ＤＢ３００、地図ＤＢ４００を車両外の一箇所に集約し、集約したシステムをサーバ装置として構成し、ナビゲーション装置１００に対して、無線通信により、ナビゲーションサービスを提供する変形例２の方式が好適である。このような構成であれば、歩行者が持ち運ぶナビゲーション装置１００を小型、軽量でき、歩行者が持ち運び易いメリットがあるからである。

Ｂ１３．変形例１３ 上記実施例において、本発明に係る情報処理装置は、ナビゲーションシステムとして実現された態様で説明したが、これに限らず、利用者の要求を確認しつつ目的としている情報処理を確実に逐行することが必要な装置、たとえば、地図表示装置などにも適用可能である。

図１５は地図表示装置に適用した場合の表示画面例を示す説明図である。この例では、地図表示装置の表示画面ＤＳＰｂにおいて、地図の左側に、情報授受用のウィンドウＷｂ１〜Ｗｂ４をまとめて表示する構成とした。ウィンドウＷｂ１はキャラクタからの質問を表示し、ウィンドウＷｂ２はその回答例を表示する。ウィンドウＷｂ３は従前に指定された条件を表示し、ウィンドウＷｂ４はキャラクタの画像を表示する。このように地図の表示部と、情報授受のための表示部とを並列的に配置することにより、従来の地図表示
装置に対して比較的容易に、情報授受用のウィンドウＷｂ１〜Ｗｂ４を付加することが可能となる。

Ｂ１４．変形例１４ 本実施例は、ナビゲーションシステムとしての構成例を説明した。本発明は、複数種類のデータベースを使い分けて検索処理を行う種々のシステムに適用可能である。例えば、いわゆるオンラインショッピングにおいて、商品のジャンルに応じて商品カタログを使い分けて、所望の商品を検索するシステムとして構成してもよい。

Ｂ１５．変形例１５ 図１６は変形例１５における画面表示例を示す説明図である。図の左側に、表示画面ＤＩＳＰｃの一部を示した。この例では、先に図１５で示した表示画面と同様のウィンドウＷｂ１〜Ｗｂ４に加え、キャラクタの属性を示すウィンドウＷｃ５を設けた。この属性は、ナビゲーション装置１００が理解可能な言語の範囲を表している。図中の例では、ウィンドウＳｃ５に「大人／関西」と表示されており、この表示は、関西にいる成人が用いる言語を理解可能であることを意味する。

図の右側に、変形例における目的地特定手段１２０ａ、およびワード変換テーブル１２７ｂ１の構成を示した。ワード変換部１２７ａその他の機能ブロックについては、実施例と同様である。変形例では、図示する通り、ワード変換テーブル１２７ｂ１において、「モード」欄が設けられており、動作モードに応じて、登録されたデータの有効／無効が切換可能となっている。図の例では、「油揚げ入りそば」という規定ワードに対して登録された各種キーワードのうち、「油揚げ入りそば」、「揚げ入りそば」は全モードに関わらず有効となる。「きつね」、「きつねそば」は関西以外のモードが選択されている時に有効となる。「たぬき」は関西モードで有効となる。

図１６の例では、「関西」モードが設定されているから、利用者が「たぬき」と回答すれば、「油揚げ入りそば」という規定ワードを意味するものと理解されることになる。一方、「きつね」または「きつねそば」と回答しても、このようには理解されないことになる。従って、関西モードにおいては、例えば、「きつね」というキーワードは、混乱無く「油揚げ入りうどん」を意味する用語としてワード変換テーブル１２７ｂ１に登録することが可能となる。

このように、ナビゲーション装置１００の音声認識についての動作モードを可変とし、その動作モードをウィンドウＷｃ５に表示することにより、利用者は、より普段なじみの深い用語を用いることが可能となり、自然な会話が可能となる。動作モードは、「関西」などの地域による指定に限らず、「大人／子供」、「男性／女性」、「日本語／英語」など種々の態様での指定が可能である。

本発明は、更に、検索処理に限らず、複数種類のエージェントを使い分けて、種々のサービスを提供するシステムとして構成してもよい。例えば、複数種類の家電製品をネットワークで接続し、各家電製品に対応したエージェントを使い分けてその制御を実現する家電製品ネットワークシステムに適用することもできる。

以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。

ナビゲーションシステムの構成を説明する説明図である。 処理（シナリオ）ＤＢのデータ構造を説明する説明図である。 音声認識による情報入力過程の処理を示す説明図である。 検索項目の指定方法を示す説明図である。 キャラクタ容姿ＤＢのデータ構造を説明する説明図である。 ログＤＢ５００のデータ構造を示す説明図である。 ナビゲーション処理のフローチャートである。 目的地特定処理時の画面表示例である。 目的地特定処理（シナリオ）のフローチャートである。 グルメ処理（シナリオ）のフローチャートである。 ラーメン店検索処理（シナリオ）のフローチャートである。 評価結果入力処理のフローチャートである。 飲食店検索時におけるログＤＢ５００の活用方法を示す説明図である。 飲食店検索処理のフローチャートである。 地図表示装置に適用した場合の表示画面例を示す説明図である。 変形例１５における画面表示例を示す説明図である。

符号の説明

１００・・・ナビゲーション装置１１０・・・現在地取得手段１２０，１２０ａ・・・目的地特定手段１２２・・・エージェント制御部１２４・・・キャラクタ表示制御部１２６・・・データ取得手段１２７ａ…ワード変換部１２７ｂ，１２７ｂ１…ワード変換テーブル１２８ａ…コード生成部１２８ｂ…コード変換テーブル１３０・・・経路探索手段１４０・・・経路誘導手段１５０・・・入力手段１５１…マイク１５２・・・音声認識部１６０・・・出力手段１６２・・・映像／音声出力部１６３…スピーカ１６４…ディスプレイ２００・・・処理（シナリオ）ＤＢ２２０・・・目的地特定処理（シナリオ）データ２４０・・・グルメ処理（シナリオ）データ２４０ａ…グルメ処理エージェント２４２・・・ラーメン店検索処理（シナリオ）データ２４４・・・中華店検索処理（シナリオ）データ２４６・・・洋食店検索処理（シナリオ）データ２４８・・・和食店検索処理（シナリオ）データ２５０・・・イタリアン店検索処理（シナリオ）データ２６０・・・レジャー処理（シナリオ）データ２６０ａ…レジャー処理エージェント２８０・・・ホテル処理（シナリオ）データ２８０ａ…ホテル処理エージェント２９０・・・温泉処理（シナリオ）データ２９０ａ…温泉処理エージェント３００・・・キャラクタ容姿ＤＢ
４００・・・地図ＤＢ
５００・・・ログＤＢ

Claims (6)

1. 利用者からの音声入力に応じて動作する情報処理装置であって、 音声による質問を出力させる音声出力制御部と、 利用者からの音声を取得し、その音声によって表される指示内容を認識する音声認識部と、 前記利用者との情報授受を通じて、予め規定された情報処理を実行するエージェント部と、 前記音声認識部が認識可能な語彙の範囲を利用者に推測させるための認識レベル情報を表示させる表示制御部とを備える情報処理装置。
2. 請求項１記載の情報処理装置であって、 前記表示制御部は、前記認識レベル情報として、前記質問に対する回答例を表示させる情報処理装置。
3. 請求項２記載の情報処理装置であって、 前記回答例には、概念範囲が異なる複数種類の回答が混在している情報処理装置。
4. 請求項１〜３いずれか記載の情報処理装置であって、 前記音声認識部は、認識可能な語彙の範囲が異なる複数の動作モードを有し、 前記認識レベル情報は、前記動作モードを表す情報である情報処理装置。
5. 利用者からの音声入力に応じて情報処理を行う情報処理方法であって、 コンピュータが実行する工程として、 音声による質問を出力させる音声出力工程と、 利用者からの音声を取得し、その音声によって表される指示内容を認識する音声認識工程と、 前記利用者との情報授受を通じて、予め規定された情報処理を実行するエージェント工程と、 前記音声認識工程で認識可能な語彙の範囲を利用者に推測させるための認識レベル情報を表示させる表示制御工程とを備える情報処理方法。
6. 利用者からの音声入力に応じて情報処理を行うためのコンピュータプログラムであって、 音声による質問を出力させる音声出力プログラムと、 利用者からの音声を取得し、その音声によって表される指示内容を認識する音声認識プログラムと、 前記利用者との情報授受を通じて、予め規定された情報処理を実行するエージェントプログラムと、 前記音声認識プログラムが認識可能な語彙の範囲を利用者に推測させるための認識レベル情報を表示させる表示制御プログラムとを備えるコンピュータプログラム。