JP4533705B2 - 車載対話装置 - Google Patents

Description

本発明は、画面上に表示されたキャラクタ同士の対話を視聴しながらユーザに新たな知識の発見を促し、また、ユーザ自身も対話に参加することを可能にする対話装置等に関する。

近年、音声認識技術が実用化に耐えうる水準に達してきており、音声対話機能を備えた機器が開発されている。このような機器としてユーザの発声した音声を認識し、画面に表示されたキャラクタとの対話を通じて目的地設定を行ったり、ユーザをアシストしたりする機能を有するナビゲーションシステムがある（特許文献１参照）。ユーザは運転中、ハンドルを握っているため自由な機器操作ができず、また、視力を周囲の障害物監視に割かねばならないためナビゲーションシステムの画面を見て複雑な操作を行うことができないが、このシステムによれば、ユーザは通常の運転動作を妨げられることなくシステムへの入力を行い所定の目的を達成することができる。

また、インターネットの世界ではチャットシステムが広く利用されており、その中ではバーチャルなコミュニケーションに臨場感を出すために自分の分身であるアバタを用いる技術が開示されている（特許文献２参照）。この技術では、自分の画像などを取り込んで自分のアバタとし、その画像の動作を制御したり、また音声合成技術を利用してアバタがあたかもしゃべっているようにみせかけたりすることでリアリティを持たせている。
特開２００３−２２０９２号公報 特開２００１−２３０８０１号公報

しかしながら、このように音声による入力手段を設けても、音声による入力は必ずしもユーザにとってメリットがあるものではない。というのも、音声による入力すら手間であると感じるユーザも多く、運転中にわざわざナビゲーションシステムと対話することを避けることもある。このような場合、ユーザが発声しない限り、ユーザは自分にとって必要な情報を得る、目的の機能をシステムに指示するなど、目的を達せられないという事態が起こる。

一方、自分が対話をする代わりに自分の分身であるアバタが自動的に対話を行って、必要な情報の取得や機能の実行を代理で行わせようとしても、特許文献２に開示されたアバタの技術では不可能である。

ユーザによる入力がない場合でもユーザが必要とする情報の提供や機能の実行を自動的に行おうとした場合には、そのタイミング、つまりユーザはいつそのような欲求を感じるのか、また、ユーザのモデリング、つまりユーザはどのような特性をもちどのような情報や機能を欲しているのか、などの問題を解決する必要がある。さらにはこのような自動化機能が実現され、ユーザにとって必要な情報や機能が提供された場合、ユーザにとってはなぜそのような情報が提供されたのかが示されなければ、いぶかしく感じてしまう。

そこで、本発明は、このような問題に鑑みてなされてものであり、ユーザが情報を必要としているタイミングでキャラクタ同士の自律的な対話が自動実行される対話装置を提供することを目的とする。

また、ユーザが特に入力したいという欲求を持った場合には、キャラクタ同士の対話に割り込み、自分の意思を伝えることのできる対話装置を提供することをも目的とする。

上記目的を達成するために、ユーザの嗜好や行動などのモデルを把握したユーザの分身でありユーザの意思を代弁、提案するユーザアバタと、ユーザの要求に応えてくれるエージェントという２つのキャラクタ同士の自律的な対話をユーザが視聴し、ユーザが特に入力をしない場合であっても、ユーザが情報や特定の機能を欲するタイミングを検出してそれらを提供することで、その提供プロセスを明らかにしながらユーザにとって未知の知識の発見を促したり、機能の自動実行を可能にしている。

つまり、上記目的を達成するために、本発明に係る対話装置は、画面に表示されるキャラクタによる対話を、車両を運転するユーザに対して表示する車載対話装置であって、ユーザが運転する車両の速度と方向指示器の少なくとも１つから車両の状況を検出する状況検出手段と、検出された車両の状況に基づいて、ユーザに代わってユーザが知りたいと思われることを代弁する役割を果たすキャラクタであるユーザアバタとその対話相手となるキャラクタであるエージェントとの対話からなるシナリオを決定するキャラクタ管理手段と、前記キャラクタ管理手段による決定に基づいて、前記ユーザアバタと前記エージェントを表示し、前記ユーザアバタと前記エージェントとの対話を音声出力する表示手段とを備え、前記キャラクタ管理手段は、複数の異なるシナリオを特定する複数のシナリオデータを記憶しているシナリオデータ記憶手段に記憶されたシナリオデータの中から、シナリオデータを選択するシナリオデータ選択手段と、前記選択されたシナリオデータに対応した、前記ユーザアバタと前記エージェントとの対話を制御する対話制御手段とを備え、前記対話制御手段は、前記状況検出手段により検出される車両の状況が変化し、前記シナリオデータ選択手段により選択されたシナリオデータに、ユーザからの入力を受け付ける旨の情報が存在している場合には、所定の時間だけ対話の進行を停止することを特徴とする。

これによって、ユーザの運転状況を加味した対話が実現され、運転者が慌てて対話に介入することがなくなるため、安全運転が確保される。

ここで、前記対話制御手段は、前記状況検出手段により検出される車両の速度情報から車両が後退状況にあることを検出したときには、ユーザから入力を受け付ける時間を長くしてもよい。

また、前記対話制御手段は、前記状況検出手段によって方向指示器が作動中であると検出されたときには、前記車両が右左折中であると判断し、ユーザから入力を受け付ける時間を長くしてもよい。

また、前記対話制御手段は、前記状況検出手段によって車両の速度情報が所定の閾値より小さいことが検出されたときにユーザから入力を受け付ける時間を長くする制御規則を有し、運転者の車載オーディオ機器に対する操作履歴と車両の速度履歴とを蓄積し、蓄積している操作履歴と速度履歴とに依存させて、前記所定の閾値を変更してもよい。

なお、本発明は、このような対話装置として実現することができるだけでなく、その特徴的な構成要素（手段）をステップとする対話方法、そのようなステップをコンピュータに実行させるプログラム等として実現することもできる。そして、そのプログラムをインターネット等の伝送媒体やＤＶＤ等の記録媒体を介して配布することができるのは言うまでもない。

本発明によれば、ユーザは特に何も入力をしなくても、現在おかれている状況を把握しているアバタとエージェントとの対話を俯瞰するだけで、自分に必要な情報を適切なタイミングで取得することができ、また、必要となる機能がタイミングよく代理実行なされることになる。さらには、ユーザごとの嗜好や行動をモデル化することで、ユーザに応じた対話がなされることになる。これにより、例えば運転中など他の作業に集中しなければならず対話や入力に手間を割けない場合や、その他手間をかけるのが面倒な場合であっても、ユーザは所望の要求を達成することが可能となる。

また、これらの処理がユーザの関知しないところで勝手になされた場合、ユーザは不信感を抱くことも考えられるが、本発明によればユーザはキャラクタ同士の対話を常に把握できるため、自動的になされる処理に透明性をもたせ、ユーザへの納得性を増すことができる。

さらに、キャラクタ同士の対話が必ずしも自分の思い通りではない場合には、対話に介入して自分の意思を伝えることも可能である。
以上のように、本発明によればユーザに負担をかけることなく、ユーザにとって有益な機能を提供し、ユーザの満足度を高めることができ、本発明の実用的価値は極めて高い。

以下、本発明の実施の形態について図面を用いて詳細に説明する。なお、本実施の形態では、対話装置をナビゲーション機能や音楽再生機能を有する車載装置に適用した例について述べる。

（実施の形態１）
図１は、本発明の実施の形態１（実施の形態２及び３についても共通）における対話装置１００の全体構成を示す機能ブロック図である。この対話装置１００は、キャラクタを表示させるためのイベントを検知するイベント検出部１０２、イベント検出部１０２の出力に従ってキャラクタの表示やシナリオを管理するキャラクタ管理部１０３、音声を出力するスピーカー１０４、キャラクタを表示する表示部１０１、音声による入力を行う入力部１０５を備える。本図において、エージェント１０６は、表示部１０１に表示されたキャラクタの一つであるエージェントである。ユーザアバタ１０７は、表示部１０１に表示されたキャラクタの一つであるユーザのアバタである。

なお、本実施の形態では、キャラクタとは、画面に表示される仮想人物であり、エージェント１０６とユーザアバタ１０７を指す。エージェント１０６はユーザにとって必要な情報をユーザに伝える役割を果たし、ユーザアバタ１０７はユーザに代わってユーザが知りたいと思われることを代弁する役割を果たす。また、イベントとは、ユーザの状態における変化とユーザが置かれている状況（環境）における変化とが含まれる。

図２は、図１に示された対話装置１００におけるイベント検出部１０２の構成を示した機能ブロック図である。このイベント検出部１０２は、対話装置１００の位置情報を検出する位置検出部２０１、ユーザにより設定された目的地や経路に従って経路案内を行う経路案内部２０２、ユーザが設定された経路から逸脱したことのある地点を記憶しておく逸脱地点記憶部２０３、位置検出部２０１により検出された対話装置１００の位置情報が、経路案内部２０２により案内される経路から逸脱しているか、また、逸脱地点記憶部２０３により記憶されている地点と同一であるか、を判定する判定部２０４及び判定部２０４に基づいて所定の情報をキャラクタ管理部１０３へと送信する送信部２０５から構成される。

図３は、判定部２０４により経路の逸脱が判定される例を示した図である。図中、黒い実線矢印で示されたものが、設定されている経路を表す。位置検出部２０１はＧＰＳなどのセンサを利用して自車の位置情報を検出し、検出された位置情報は図中の黒い三角で表される自車に反映される。設定された経路では交差点Ａを直進し、次の交差点で左折する必要があるが、自車が図のように交差点Ａを左折する、つまり設定されている経路ではない道を走行すると、判定部２０４は経路の逸脱、および逸脱の状況を判定する。逸脱の状況とは、例えば図３では早く左折しすぎたことであったり、また逆に左折すべき箇所を通過してしまったり、など様々に存在する。逸脱した地点に関する情報と、逸脱の状況に関する情報は、逸脱地点記憶部２０３において記憶される。

経路案内部２０２は、ユーザにより設定された目的地や経路までの経路案内をするとともに、判定部２０４により経路の逸脱が判定されると、逸脱して走行している位置や道路に関する情報と、あらかじめ設定されている目的地情報とを利用することで新たな経路を設定（リルート）し直す機能を有する。

判定部２０４はまた、自車の現在位置が逸脱地点記憶部２０３に記憶された地点、つまり過去に経路を逸脱して走行したことのある地点の近傍を走行しているかどうかの判定も行う。図４に示すように、ユーザが現在の走行を継続すると過去に経路を逸脱したことのある交差点Ａに達すると予想される場合などはその例である。さらに、現在位置が交差点Ａから所定の範囲（例えば半径２００ｍ）であることを基準として設けてもよい。

経路を逸脱した場合に経路案内部２０２によりリルートされた経路に関する情報と逸脱した状況を表す情報、または、逸脱地点記憶部２０３に記憶された地点の近傍を走行している場合にその地点に関する情報と逸脱した状況を表す情報は、送信部２０５によりキャラクタ管理部１０３へ送信される。

図５は、図１に示された対話装置１００におけるキャラクタ管理部１０３の構成を示した図である。このキャラクタ管理部１０３は、イベント検出部１０２から所定の情報を受信する受信部５０１、キャラクタが対話を行うためのシナリオを１つ以上記憶しているシナリオデータ５０３、イベント検出部１０２から受信した情報に応じてシナリオデータ５０３からシナリオを選択するシナリオ選択部５０２、ユーザに表示するエージェント、ユーザアバタの画像や動画を記憶しておくキャラクタ記憶部５０６、表示部１０１においてキャラクタを表示する位置を決定するキャラクタ位置決定部５０４、及び、シナリオ選択部５０２により選択されたシナリオと、キャラクタ記憶部５０６に記録されているキャラクタと、キャラクタ位置決定部５０４により決定されるキャラクタの表示位置に基づいて表示部１０１に出力する内容を決定する出力内容決定部５０５とから構成される。

受信部５０１は、イベント検出部１０２の送信部２０５から、ユーザが経路を逸脱した場合に経路案内部２０２によりリルートされた経路に関する情報と逸脱した状況を表す情報、または、ユーザが逸脱地点記憶部２０３に記憶された地点の近傍を走行している場合にその地点に関する情報と逸脱した状況を表す情報、を受信する。

シナリオ選択部５０２は受信部５０１の受信情報に基づいてキャラクタが対話を行うシナリオを選択する。
図６に、シナリオデータ５０３の一例を示す。図中、シナリオ５０３ａはユーザが曲がるべき交差点の手前で交差点を曲がったためにリルートが必要になったというイベントに対応したシナリオデータであり、シナリオ５０３ｂはユーザが曲がるべき交差点を過ぎてしまったためにリルートが必要になったというイベントに対応したシナリオデータ、シナリオ５０３ｃはユーザが曲がるべき交差点の手前で曲がったことのある交差点の近傍を走行しているというイベントに対応したシナリオデータである。例えば、受信部５０１が受信した情報が、ユーザが図３のように曲がるべき交差点の手前で左折してしまったことによるリルート情報である場合はシナリオ５０３ａ（ｔｕｒｎｅｄ ｅａｒｌｉｅｒ）が選択され、逆に交差点を通過してしまった場合にはシナリオ５０３ｂ（ｔｕｒｎｅｄ ｌａｔｅｒ）が選択される。

シナリオ５０３ａを例にとって詳細に説明する。なお、受信したリルート情報は、最初に「次の交差点を右折」、その後「しばらく直進」であるとする。エージェントとユーザアバタは、シナリオ５０３ａに従うと次のように対話が進行する。まず、ユーザアバタに相当するキャラクタは、シーケンスの１である「早く曲がりすぎた」と発話する。次にエージェントはシーケンスの２に従ってリルート情報を発話する。このリルート情報１や後に述べるリルート情報２はパラメータであり、シナリオ選択部５０２により、受信部５０１で受信したリルート情報が充当される。ユーザアバタはシーケンス３に従って再び「その先は？」と発話し、エージェントがそれに続くリルート情報２を発話する。

具体的には次のようなものがある。
＜ユーザアバタ＞：早く曲がりすぎた。
＜エージェント＞：次の交差点を右折だ。（リルート情報１）
＜ユーザアバタ＞：その先は？
＜エージェント＞：しばらく直進だ。（リルート情報２）
ここで、受信したリルート情報「次の交差点を右折」、「しばらく直進」は上述したような口語調に変換する文体変換技術を利用することが考えられる。それ以外にも、単に文体のフォーマットを用意しておいてリルート情報を充当するだけでもよい。

またリルート情報は、ユーザがどこで、どのように経路を逸脱したのかによって異なるため、それらに応じて充当される。さらに、同一の逸脱状況（例えば、リルート ｔｕｒｎｅｄ ｅａｒｌｉｅｒ）であっても、それに対応するシナリオ、例えば、シナリオ５０３ａのバリエーションを複数もっておき、逸脱の度にシナリオを選択するようにすることも可能である。この場合は、ランダムに選択してもよいし、最近最も選択されていないものから順に選択するのでもよい。

このように、逸脱した状況をアバタの台詞に取り入れることで、アバタがユーザの分身、代弁者であることにリアリティを増すことができる。
キャラクタ位置決定部５０４は、表示部１０１におけるエージェント、ユーザアバタの表示位置を決定する。決定するための基準は様々に考えることができる。例えば、運転席の位置が左であるか右であるかを識別する手段を設け表示部１０１において運転席に近いほうにユーザアバタ、遠いほうにエージェントを、対面させるように表示させることができるし、その逆であってもよい。前者の場合は、自分の分身であるアバタを近くにもってくることでより親密度が増し、エージェントが運転者の方を向いているように表示できるので運転者に向かって話しかけているような雰囲気をつくることができる。運転席が右にある場合の表示例を図７に示す。また後者の場合は、エージェントを近くに配置することで運転者にとってエージェントにより提供される情報が表示情報である場合に見やすくなるという効果がある。これは、運転者にとってよく知らない土地を走行している場合には特に有効となる。そこで、運転者の走行履歴を蓄積しておいて、運転者がその土地に対してどれくらい知っているか、を判定する基準を設けて、あまり知らない場合にはエージェントを近くに配置するようにしてもよい。

さらに、ユーザが過去に経路を逸脱したことのある交差点の近傍を走行している場合には、表示部１０１に表示されている地図におけるその交差点の位置に相当する場所から、ユーザアバタまたはエージェントを登場させるようにすることも考えられる。図８にその表示例を示す。このようにすることで以前ユーザが経路を逸脱した地点をユーザに明示することになり、現在の走行において注意を促すことが可能になる。

また自車位置にユーザアバタを表示し自車の走行にしたがってユーザアバタも移動するようにしておき、ユーザに通知したい情報がある地点（例えば上述した過去の経路逸脱地点や、特売情報がある店舗の位置など）にエージェントを配置しておき、自車位置とその地点の距離が一定以内になる、つまり、ユーザアバタとエージェントの間隔が表示上一定以内になったときに、所定のシナリオにしたがって対話を行うようにしてもよい。

なお、このような表示位置を決定する構成はなく、必ず定まった位置に表示されてもよいことは言うまでもない。
出力内容決定部５０５は、表示部１０１に表示すべきエージェントとユーザアバタの画像や動画をキャラクタ記憶部５０６から抽出し、キャラクタ位置決定部５０４により定められた位置にそれぞれのキャラクタを表示し、シナリオ選択部５０２により選択、充当されたシナリオに従って図７や図８に示すように対話内容を出力する。

なお、エージェントやユーザアバタにどのようなキャラクタを利用するかは様々に考えることができる。擬人化されたものを利用してもよいし、それ以外にも動物やアニメなどのキャラクタなどユーザが自由に設定できるようにしてもよい。また、本発明を車載機器へ適用する場合には、エージェントの画像として車や車載機器をイメージさせるようなものを利用してもよいし、本発明をＴＶや携帯電話などに適用した場合は、それぞれＴＶや携帯電話をイメージさせるような画像にしてもよい。ユーザアバタについても同様である。いずれにしても、対話を行う２つのキャラクタに対して、ユーザが、自分のアバタ、エージェントを識別できるのであればよい。

次に、このように構成されるイベント検出部１０２およびキャラクタ管理部１０３の一連の動作について、図９および図１０をそれぞれ参照して述べる。
まず、図９を参照してイベント検出部１０２の動作を説明する。

位置検出部２０１では、所定のタイミングにおいて自車の位置情報が検出される（ステップＳ９０１）。
現在、経路案内部２０２による経路案内が行われている場合（ステップＳ９０２でＹｅｓ）、判定部２０４において、位置検出部２０１により検出された自車位置情報と案内中の経路を対比し、経路を逸脱しているかどうかの判定がなされる（ステップＳ９０３）。

逸脱していないと判定された場合（ステップＳ９０３でＮｏ）は、再び位置検出部２０１による自車位置検出が行われる。
逸脱していると判定されると（ステップＳ９０３でＹｅｓ）、逸脱地点記憶部２０３では、逸脱した地点に関する情報と、逸脱した状況に関する情報が記憶される（ステップＳ９０４）。また、経路案内部２０２では改めて経路の設定が行われる（ステップＳ９０５）。

そして逸脱地点記憶部２０３に記憶される情報と、リルートに関する情報は送信部２０５によりキャラクタ管理部１０３へ送信される（ステップＳ９０６）。
一方、経路案内中でない場合（ステップＳ９０２でＮｏ）、現在地が逸脱地点記憶部２０３に記憶されている、過去に経路を逸脱した地点の近傍であるかどうかの判定が、判定部２０４により行われる（ステップＳ９０７）。

過去に経路を逸脱した地点の近傍である場合（ステップＳ９０７でＹｅｓ）、その地点に関する情報と、逸脱した状況に関する情報は、送信部２０５によりキャラクタ管理部１０３へ送信される（ステップＳ９０６）。

次に、図１０を参照してキャラクタ管理部１０３の動作を説明する。
受信部５０１は、イベント検出部１０２の送信部２０５から情報の受信待ちを行う（ステップＳ１００１）。

情報を受信すると（ステップＳ１００１でＹｅｓ）、シナリオ選択部５０２は、シナリオデータの中から受信した状況に該当するシナリオを選択し、リルート情報など、受信した情報の中から補充すべき内容がある場合はそれらの情報でシナリオを完成させる（ステップＳ１００２）。

一方、キャラクタ位置決定部５０４では、受信した情報に応じてエージェント、およびユーザアバタを表示部１０１のどの場所に表示するか、また、どの場所から登場させるか、に関する決定が行われる（ステップＳ１００６）。

出力内容決定部５０５では、表示部１０１に表示するユーザアバタとエージェントの画像や動画をキャラクタ記憶部５０６から抽出し（ステップＳ１００３）、キャラクタ位置決定部５０４により決められた位置に表示させ、シナリオ選択部５０２で選択、充当されたシナリオに基づいて表示部１０１に表示する内容が決定され（ステップＳ１００４）、表示部１０１に表示される（ステップＳ１００５）。

以上のように、本実施の形態によれば、ユーザは特に何も入力をしなくても、現在おかれている状況を把握しているアバタとエージェントとの対話を俯瞰するだけで、自分に必要な情報を適切なタイミングで取得することができ、また、必要となる機能がタイミングよく代理実行なされることになる。これにより、例えば運転中など他の作業に集中しなければならず対話や入力に手間を割けない場合や、その他手間をかけるのが面倒な場合であっても、ユーザは所望の要求を達成することが可能となる。

なお本実施の形態では、過去に経路を逸脱した箇所は経路案内を行っていないときに表示する例を述べたが、当然経路案内中であっても表示してもよい。経路案内中でなければ特に注意が必要であるし、案内中であっても注意すべきポイントであるので、ユーザに通知することは有効である。

また、イベント検出部１０２が検出するイベントとしては上述した以外にも、渋滞に遭遇した、トンネルを抜けたのにヘッドライトが点いている、などを考えることができる。渋滞に遭遇しているというイベントの検出は、車速が一定速度以下で所定の時間走行しているという状態の検出やＶＩＣＳなどによる交通情報の取得により可能となり、キャラクタ同士の対話の中で現在地周辺の渋滞を回避するルート情報をユーザに提供することが考えられる。また、トンネルを抜けたのにヘッドライトが点いているというイベントは、時刻が昼間でありマップマッチングの結果すでにトンネルを過ぎているという状態の検出により可能であり、ヘッドライトの消し忘れを通知する対話を行うことが考えられる。

また、キャラクタの表示は、イベント検出部１０２によるイベント検出により行われる例について示したが、それ以外にも、ユーザからのキャラクタ表示要求の入力に応じてキャラクタ管理部１０３が動作し、その後、そのときにユーザに起こっているイベント（経路を逸脱した、渋滞に遭遇している）を検出して対話を行うのでもよい。

さらに、キャラクタ管理部１０３（キャラクタ位置決定部５０４及び出力内容決定部５０５）は、イベント検出部１０２が検出したイベントの種類に応じて、表示部１０１に表示するキャラクタの出現タイミング、出現画面位置、出現方法、表情等を変化させてもよい。

例えば出現のタイミングとしては、自車の走行により、過去に経路を逸脱した箇所が画面内に表示されたタイミングが考えられる。また、自車位置と逸脱箇所との距離が所定の範囲になったときに、画面に表示されている地図の縮尺をそれら２つの位置が表示可能な縮尺に変更しキャラクタを出現させてもよい。これは、所定の距離を３００ｍとした場合、画面に表示されている地図が５０ｍの範囲しか表示できない縮尺であれば、これを少なくとも自車位置から３００ｍの範囲表示可能な縮尺に変更するというものである。

また出現画面位置としては、設定されたルート上や、ユーザの走行履歴に基づいて走行が予想されるルート上にキャラクタが重ならないような位置に表示することなどが考えられる。

（実施の形態２）
本発明の第二の実施の形態について説明する。なお、本実施の形態における対話装置１００の全体構成は図１に示された実施の形態１と同様であるが、イベント検出部とキャラクタ管理部の機能が異なる（ここでは、それぞれ、イベント検出部１０２ａ、キャラクタ管理部１０３ａとする）。

図１１は、本実施の形態におけるイベント検出部１０２ａの構成を示した機能ブロック図である。このイベント検出部１０２ａは、地図データを記憶している地図データ記憶部１１０１、対話装置１００が搭載されている車の車内外の状況を検出する状況検出部１１０２、状況検出部１１０２により検出された状況を蓄積しておく履歴データ記憶部１１０３、目的地設定がなされない場合にユーザが向かおうとしている目的地や、ユーザに推薦するとメリットがあると考えられる目的地（例えば、昼食や夕食の時間帯であればレストランなど）、さらにはそれらの目的地が属するジャンルを予測する予測部１１０４、ネットワークを介して情報を取得する情報取得部１１０５、情報取得部１１０５で取得した情報の中で、予測部１１０４により予測された目的地やそのジャンルに関連する情報があるかどうかを判定する判定部２０４、経路案内を行う経路案内部２０２及び判定部２０４に従って、予測された目的地やそのジャンルに関する名称や情報取得部１１０５により取得した情報の中でそれらに関連する情報をキャラクタ管理部１０３へ送信する送信部２０５から構成される。

地図データ記憶部１１０１は、対話装置１００に用いられる地図データ１１０１ａや、走行経路を特定するためのノードデータベース１１０１ｂ等を記憶しているハードディスク等である。ノードデータベース１１０１ｂは、図１２に示されるように、全国における予め設定された主要な地点をノードとし、ノードごとの「ノード番号」、「種別、名称」、「東経」及び「北緯」を記録したデータベースである。ノードには、交差点やランドマーク、またエリアなどがある。

状況検出部１１０２は、その時点での車及び車がおかれた状況を検出する各種センサ等からなり、エンジンの状態（起動／停止）、車の位置、運転者、同乗者、天気等を検出する。具体的には、エンジンキーの位置等からエンジンの状態を検出し、対話装置１００が備えるＧＰＳによって現在位置を検出し、内蔵するカレンダー・タイマーによって日時を検出し、各座席に組み込まれた着座センサ、運転席のシート位置、ミラーの調整位置、エンジンキーと一体化された赤外線送信器からのＩＤ信号、乗車する人が所有する携帯電話機からの無線信号によるＩＤ又は電話番号等から運転者及び同乗者を検出し、ワイパーの動作状態、雨滴センサ、温度・湿度センサ等から天気を検出する。

履歴データ記憶部１１０３は、状況検出部１１０２から送られてくる状況信号に基づいて、走行状況の履歴データを蓄積する。履歴データは、図１３に示されるように、エンジンが始動してから停止されるまで（あるいは、出発地から目的地に到着するまで）の走行に関する情報を集めたものを１つのエントリ（単位）として蓄積されたものであり、エントリごとに、その「日時」、エンジン始動から停止までの「所要時間」、「出発地」、「目的地」、ノードの連なりからなる「経路」、「天気」、「運転者」、「同乗者」等の項目を記録した情報である。状況検出部１１０２により検出された位置情報は、該当するノードのＩＤの系列に変換されて蓄積されることになる。また図１３には図示していないが、ノードの系列には、そのノードを出発、通過、滞在した時刻、または、ノード間の走行に要した所要時間を合わせて蓄積しておくことが望ましい。

予測部１１０４は、状況検出部１１０２で検知された状況（日時、現在地、運転者、同乗者等）を履歴データ記憶部１１０３に記憶されたデータと照合することによって、現在の走行における目的地を予測する。例えば、現在状況における日時（時間帯、曜日）、現在地、運転者、同乗者それぞれと一致する「日時（時間帯、曜日）」「出発地」、「運転者」、「同乗者」が記録された全てのエントリを履歴データ記憶部１１０３に記憶されたデータから抽出し、抽出したエントリに記録された全ての「目的地」のうち最も頻度の多い「目的地」を予測目的地として予測する処理部である。予測部１１０４はさらに、蓄積されている経路情報を利用して目的地までの経路を予測することも可能である。

このとき、検索に用いる状況パラメータは必ずしも蓄積しているもの全てを用いる必要はない。例えば、全てのパラメータを利用した場合、履歴を検索して抽出されるエントリが１０であったとする。この数値は統計的に信頼できる数値とはならない。そこで、「出発地」パラメータを除いて残りの状況パラメータで検索した場合にエントリが５０抽出されたとする。これは全てのパラメータを利用するよりも統計的な確信度が高まるため、この５０エントリの中から最も頻度の多い「目的地」を予測するということも考えられる。このように利用するパラメータは柔軟に変化させることが可能である。

また、図１４に示すように、ランドマークとその属するジャンルが定義された情報が地図データ１１０１ａ内に記憶されている場合、ユーザの目的地の履歴をジャンルとして把握することができるため、予測部１１０４は目的地の名称ではなく、目的地が属するジャンルを予測することも可能となる。例えば、休日の１２時から１３時半の間に、「エムバーガー」、「ル・フラン」によく行っている場合、これを「レストラン」というジャンルを利用して、レストランによく行くというように予測をすることができる。

さらに、このようにユーザごとの履歴情報のみを利用するのではなく、一般的な知識を利用してもよい。一般的な知識とは、「昼食や夕食の時間帯であればレストランに行きやすい」、「休日であればレジャー施設やショッピングに行きやすい」、「雨が降っていれば屋内型レジャー施設に行きやすい」、「特売情報のあるスーパーには行きやすい」などの多くの人に適用できると考えられる規則である。このような一般的な知識と、ユーザごとの履歴情報を併用することで、例えば、夕食の時間帯であれば、レストランの中で、ユーザがよく行っているフランス料理の店舗を目的地として予測する、というようなことが可能である。

予測部１１０４による予測処理が行われるタイミングとしては、エンジンが起動された時、交差点を通過した時、情報取得部１１０５が情報を取得した時、など様々に考えることができる。

情報取得部１１０５は、ネットワークやＶＩＣＳなどを介して交通情報や商用情報、施設情報など様々な情報を取得することができる。
判定部２０４は、情報取得部１１０５が取得した情報の中で、予測部１１０４により予測された目的地、ジャンル、経路に関連のある情報があるかどうかの判定処理を行う。情報の関連性は、例えば次のように判定される。予測部１１０４により経路が予測された場合、その経路に関連する交通情報や道路情報、また経路に沿った店舗や施設の情報などは、関連性があると判定される。また、目的地として固有名称（甲子園やエキスポランドなど）が予測された場合には、その施設の情報、ジャンル（運動施設やレストランなど）が予測された場合には、そのジャンルに属する施設や店舗の情報、は関連性があると判定される。

予測部１１０４と判定部２０４の処理の具体例として次のようなものを考える。
予測部１１０４は、現在以降のユーザの走行経路および目的地としてノード系列「Ｃ２→Ｃ８→Ｃ１０→Ｃ１８→Ｃ１５→Ｌ１２４（職場）」と予測する。履歴データ記憶部１１０３に記憶されている過去のエントリからノード間の走行所要時間の平均を計算することができ、Ｃ８からＣ１８までの予想所要時間が１０分と算出される。

情報取得部１１０５は、ノードＣ８に相当する交差点名称「清滝東」とノードＣ１８に相当する交差点名称「生駒登山口」を含んだ「清滝東〜生駒登山口まで、２５分」という交通情報を受信する。

判定部２０４では、予測部１１０４により予測された経路と情報取得部１１０５により取得された情報に関連があると判定する。この場合交通情報により、Ｃ８からＣ１８を走行するのに、予想された走行所要時間以上必要となるため、経路案内部２０２に対してＣ８からＣ１８を回避するルートを探索するよう指示が出される。そして、予測された経路と目的地、関連する交通情報（受信情報や、予想所要時間と実際の所要時間の差に関する情報など）を送信部２０５へ通知する。

次に、本実施の形態におけるキャラクタ管理部１０３ａの構成について図１５の機能ブロック図を用いて説明する。このキャラクタ管理部１０３ａは、受信部５０１、シナリオ選択部５０２、シナリオデータ５０３、キャラクタ位置決定部５０４、出力内容決定部５０５、キャラクタ記憶部５０６及びキャラクタ選択部１５０１から構成される。図中、実施の形態１に示した構成と同一の機能のものは同一番号を付与し、詳細な説明は省く。

図中、キャラクタ選択部１５０１は受信部５０１においてイベント検出部１０２ａから受信した情報に応じて表示部１０１に表示するエージェント、ユーザアバタの画像や動画を選択するキャラクタ選択部である。

キャラクタ記憶部５０６には、図１６のようにエージェント、およびユーザアバタに関するキャラクタが複数記憶されている。これらは、あらかじめ記憶されているものの他に、ネットワークや記録媒体を経由して外部から取り込むことも可能である。例えば、商用情報を提供したい店舗や施設などが、それらに応じたキャラクタを対話装置１００内部に送り込んでもよい。さらには、ユーザアバタにはユーザの似顔絵や画像を利用すると、ユーザにとってはよりアバタに親近感がわくという効果もある。

キャラクタ選択部１５０１は、受信部５０１においてイベント検出部１０２ａから受信した情報、および選択基準に基づいてキャラクタ記憶部５０６に記憶しているキャラクタの中から表示すべきキャラクタを選択する。

選択基準の例を図１７に示す。選択基準には、キャラクタ選択基準１７０１ａに示すようなイベントに応じて選択キャラクタが異なるという基準と、キャラクタ選択基準１７０１ｂに示すようにユーザの状態に応じて選択キャラクタが異なるという基準が設けられている。例えば、キャラクタ選択基準１７０１ａでは、イベントとして「渋滞」を受信した場合に、通常の所要時間との差が１０分未満であれば、ユーザアバタは「Ａｖａｔａｒ２」、エージェントは「Ａｇｅｎｔ１」が選択され、１０分以上かかるのであればユーザアバタは「Ａｖａｔａｒ３」、エージェントは「Ａｇｅｎｔ３」が選択されることを表す。この他にも取得した商用情報が１０％Ｏｆｆ未満であるか以上であるか、さらには商用情報の対象となる店舗までの距離や所要時間の長さに応じて選択基準を設けてもよい。

また、キャラクタ選択基準１７０１ｂでは、ユーザの状態を定義しており、ユーザの疲労度や現在走行している地域にどれくらい詳しいかを判定するユーザモデリング部を新たに設け、ユーザモデリング部によって状態を判定し、それに応じてキャラクタを選択する基準を設けている。ユーザの疲労度は、走行を開始してからの運転時間の長さや、どのような道路、例えば、交通量の多い道、山道、平坦な道など、を走行してきたかによって定義することが考えられる。具体的には、運転時間と走行道路のそれぞれに対する疲労度合いを「運転時間が３０分未満なら疲労度は１」、「運転時間が６０分未満なら疲労度は２」、「運転時間が６０分以上なら疲労度は４」、「走行道路が平坦な道なら疲労度は０」、「走行道路が交通量の多い道なら疲労度は２」、「走行道路が山道、細い道なら疲労度は３」のようにテーブルで定義しておけばよい。ここで、ユーザが実際に走行した道路の種別はデータベースとしてもっておくとよい。また地域にどれくらい詳しいか、は地図データ記憶部１１０１や履歴データ記憶部１１０３を参照して、ある地域を過去にどのくらいの頻度で走行しているか、その地域をどのくらいカバーしているか、などにより定義できる。ユーザの状態としてはこの他にも、実施の形態３で示すような現在聴いている音楽の好き嫌いの度合いや、目的地があらかじめ分かっている場合には目的地なども考えることができる。

上述したような、取得した情報の内容による外的要因やユーザの状態のほかに、システムの内部状態、例えば予測部１１０４による目的地の予測確率が８０％を超えるか超えないか、というものや、状況検出部１１０２で検出される運転者や同乗者、日時、天候、現在地などのセンサ情報による選択基準を設けてもよい。

このような選択基準を設けることで具体例として以下のような選択が実現される。
◆ユーザの疲労度が強い場合には、ユーザアバタとして疲れている状態を表すキャラクタ、エージェントとして強い調子で注意を促す役割のキャラクタを選択する。
◆渋滞が１０分以上かかる場合には、ユーザアバタとしてイライラしている状態を表すキャラクタ、エージェントとしてなだめる役割のキャラクタを選択する。
◆昼食時で食事に行くことが予測される場合には、ユーザアバタとして空腹状態を表すキャラクタ、エージェントとして飲食店を象徴するキャラクタを選択する。さらに商用情報と組み合わせることで、各店舗や施設が支払った広告料金に応じて表示するエージェントの優先度を決定する。また、各店舗や施設を象徴するキャラクタはネットワークなどを利用して取得することができる。各店舗や施設を象徴するようなキャラクタの出現位置としては、画面に表示される地図上におけるそれらの位置であることが考えられる。

このような選択基準により、エージェントとユーザアバタを表示したときに受ける印象に整合性を持たせることが可能となる。
ここでは選択基準を用いることで、ユーザアバタ、エージェントのキャラクタを変更する例について述べたが、この他にも同一キャラクタであってもその大きさや色、表情を変更するようにしてもよいし、ユーザアバタとエージェントの関係を指定するようにしてもよい。ここで述べる関係とは、それぞれのキャラクタが担う立場やキャラクタの大きさなどのことであり、立場に関しては、エージェントの立場を強くする、ユーザアバタの立場を強くする、それらを対等にする、というもの、大きさに関しては、ユーザアバタの大きさをエージェントより大きくする、エージェントの大きさをユーザアバタより大きくする、それらを同じ大きさにする、という指定の方法が考えられる。

受信部５０１により受信された情報が、イベントとして渋滞であり、所要時間が通常より１５分多く要するというものであった場合には、キャラクタ選択部１５０１は選択基準１７０１ｂに基づいてユーザアバタとして「Ａｖａｔａｒ３」、エージェントとして「Ａｇｅｎｔ３」を選択する。

次に、図１８に本実施の形態におけるシナリオデータの例を示す。シナリオ選択部５０２においても、受信部５０１により受信された情報に基づいてシナリオの選択が行われる。同様に、シナリオ５０３ｅが選択されることになる。５０３ｅを詳細に説明する。まず、ユーザアバタがシナリオ１に従って「（Ｄｅｓｔｉｎａｔｉｏｎ）へ行くんだけど。」と発話する。ここで（Ｄｅｓｔｉｎａｔｉｏｎ）はパラメータであり、シナリオ選択部５０２は、予測部１１０４により予測された目的地をここに充当する。今回の例では、目的地はＬ１２４（職場）である。次にエージェントはシナリオ２に従って、渋滞情報を発話する。この渋滞情報と後で述べるリルート情報は、実施の形態１で述べたようにパラメータである。さらにユーザアバタが「回避ルートは？」と発話してエージェントがリルート情報を述べる。

具体的には次のようになる。
＜ユーザアバタ＞：職場へ行くんだけど。
＜エージェント＞：清滝東〜生駒登山口まで、２５分です。（渋滞情報）
＜ユーザアバタ＞：回避ルートは？
＜エージェント＞：清滝西交差点を右折です。（リルート情報）
出力内容決定部５０５は、キャラクタ選択部１５０１で選択されたキャラクタを、キャラクタ位置決定部５０４により決定された位置に表示し、シナリオ選択部５０２で選択されたシナリオをキャラクタに発話させる。

次に、このように構成されるイベント検出部１０２ａおよびキャラクタ管理部１０３ａの一連の動作について、図１９および図２０をそれぞれ参照して述べる。
まず、図１９を参照してイベント検出部１０２ａの動作を説明する。イベント検出部１０２ａの動作は、図１９（ａ）に示す履歴情報を蓄積する処理と、図１９（ｂ）に示す目的地を予測する処理に分かれる。

＜履歴蓄積処理＞
状況検出部１１０２は、まず、エンジンが始動されたことを検出すると（ステップＳ１９０１でＹｅｓ）、車の位置と現在日時とを検出し（ステップＳ１９０２）、検出した位置と地図データ記憶部１１０１のノードデータベース１１０１ｂに登録された各ノードの位置とを照合することによって、車がいずれかのノードに位置するか否かの判断を繰り返す（ステップＳ１９０３）。たとえば、検出した位置がノードデータベース１１０１ｂに登録されたノードの位置から一定範囲内に位置する場合に、その車は、そのノードに位置すると判断し（ステップＳ１９０３でＹｅｓ）、続いて、運転者の検出（ステップＳ１９０４）、同乗者の検出（ステップＳ１９０５）、天気の検出（ステップＳ１９０６）を行い、その検出結果を履歴データ記憶部１１０３に蓄積する（ステップＳ１９０７）。

具体的には、履歴データ記憶部１１０３は、状況検出部１１０２によってエンジン始動後に最初に検出された日時及び車の位置（ノード）を、それぞれ、履歴データの「日時」及び「出発地」として記録し、目的地に到達するまでの各ノードにおいて状況検出部１１０２によって検出された車の位置（ノード）、天気、運転者、同乗者を、それぞれ、履歴データの「経路」、「天気」、「運転者」、「同乗者」として記録し、状況検出部１１０２によってエンジン停止直前に検出された車の位置（ノード）及び日時から算出される所要時間を、それぞれ、履歴データの「目的地」及び「所要時間」として記録する。

そしてエンジンが停止すれば（ステップＳ１９０８でＹｅｓ）作業を終了する。
＜目的地予測処理＞
状況検出部１１０２において、現在が予測を行うタイミングであると検出すると（ステップＳ１９１０でＹｅｓ）、その時点における車の状況を検出する（ステップＳ１９１１）。具体的には、日時、現在地、運転者、同乗者等を検出し、予測部１１０４に通知する。

予測部１１０４は、状況検出部１１０２から通知された状況データ（日時、現在地、運転者、同乗者等）を履歴データ記憶部１１０３に記憶された履歴データと照合することによって目的地やジャンル、経路などを予測する（ステップＳ１９１２）。

次に、情報取得部１１０５は受信情報があるかどうかの確認を行い、情報があった場合には（ステップＳ１９１３でＹｅｓ）、判定部２０４により、受信情報と、予測結果に対して関連があるかどうかの判定が行われる。

関連ありと判定された場合には（ステップＳ１９１４でＹｅｓ）、送信部２０５は、所定の情報をキャラクタ管理部１０３ａに対して送信する（ステップＳ１９１５）。
次に、図２０を参照してキャラクタ管理部１０３ａの動作を説明する。

受信部５０１は、イベント検出部１０２ａの送信部２０５から情報の受信待ちを行う（ステップＳ２００１）。
情報を受信すると（ステップＳ２００１でＹｅｓ）、シナリオ選択部５０２は、シナリオデータの中から受信した状況に該当するシナリオを選択し、リルート情報など、受信した情報の中から補充すべき内容がある場合はそれらの情報でシナリオを完成させる（ステップＳ２００３）。

一方、キャラクタ位置決定部５０４では、受信した情報に応じてエージェント、およびユーザアバタを表示部１０１のどの場所に表示するか、また、どの場所から登場させるか、に関する決定が行われる（ステップＳ２００４）。

また、キャラクタ選択部１５０１では、受信した情報に応じて選択基準をもとにキャラクタ記憶部５０６から所定のキャラクタを選択する（ステップＳ２００２）。
出力内容決定部５０５では、表示部１０１に表示するユーザアバタとエージェントの画像や動画をキャラクタ記憶部５０６から抽出し、キャラクタ位置決定部５０４により決められた位置に表示させ、シナリオ選択部５０２で選択、充当されたシナリオに基づいて表示部１０１に表示する内容が決定され（ステップＳ２００５）、表示部１０１に表示される（ステップＳ２００６）。

以上のように、本実施の形態によれば、必要なタイミングで自動的にアバタとエージェントとの対話が開始されるだけでなく、ユーザごとの嗜好や行動がモデル化され（ユーザに性質に対応したキャラクタの選択とシナリオの選択が行われ）、ユーザにとって親近感をもてる仮想対話がなされることになる。これにより、必要なタイミングでユーザの注意が喚起され、例えば、運転中において、安全運転を確保するための各種情報が確実にユーザに提供されることになる。

なお、判定部２０４の基準としては、予測部１１０４により予測された経路や目的地、ジャンルと関連のある情報を取得するというもの以外に、情報の緊急度や重要度、さらにキャラクタ選択部１５０１の選択基準で述べたユーザモデリング部の判定に応じて関連性を判定してもよい。例えば、情報の緊急度という観点では、情報に対応する位置と現在の自車位置との距離が選択基準となり得るし、また情報が指し示す日時または有効期限であってもよい。また重要度という観点では、予測部１１０４による予測確率を選択基準として予測確率が高いほど重要度を高くするようにしてもよい。そして、シナリオデータを階層化しておき、そのような重要度や緊急度に応じて、対応するシナリオデータを選択してもよい。

また、図１９のフローチャートにおいて、予測部１１０４による予測は一度だけでなく、予測のタイミングの度に、関連情報を取得するまでの間に何度行ってもよい。つまり、予測処理と情報取得処理は並列で動作し、それぞれが更新されるたびに関連情報があるかどうかの判断がなされるのでもよい。

また、履歴データ記憶部１１０３において記憶される経路情報は、本実施の形態で示したように交差点をノードとして、ノードの系列で蓄積する以外にも、走行した道路情報（交差点と交差点を結ぶリンク）を利用して蓄積してもよい。ノードＣ２とＣ８を結ぶ道路をリンクＬ（２，８）と表現すると、例えば図１３における「２００３年５月１６日８時２０分」のエントリにおける経路は、「Ｌ（２，８）→Ｌ（８，５）→Ｌ（５，６）→Ｌ（５，１７)→Ｌ（１７，２７）」というように記録されることになる。このような表現であっても、予測部１１０４による予測は、交差点を蓄積する場合と同様の方法で可能である。

なお、予測部１１０４による目的地や経路の予測は、今後走行する可能性のある広範囲な経路を把握できるため、実施の形態１で述べたような現在地近辺の経路において渋滞を回避する以上の効果を生むことができる。

また、キャラクタやシナリオデータの選択は、本実施の形態で述べた要因だけに限られず、車の走行に関連するあらゆるイベント、例えば、走行時間、道路状況（信号が多い等）、時間帯（夕方、夜等）、交通状況、走行状態（速度、蛇行等）、天気・湿度、現在地等の要因に依存して決定されてもよい。

（実施の形態３）
本発明の第三の実施の形態について説明する。なお、本実施の形態における対話装置１００の全体構成は図１に示された実施の形態１と同様であるが、イベント検出部とキャラクタ管理部の機能が異なる（ここでは、それぞれ、イベント検出部１０２ｂ、キャラクタ管理部１０３ｂとする）。

本実施の形態におけるイベント検出部１０２ｂの構成について図２１の機能ブロック図を用いて説明する。図中、実施の形態２に示した構成と同一の機能のものは同一番号を付与し、詳細な説明は省く。

このイベント検出部１０２ｂは、地図データ記憶部１１０１、状況検出部１１０２、判定部２０４、音楽データを記憶しておく音楽データ記憶部２１０１、音楽データ記憶部２１０１に記憶されている音楽を再生する再生部２１０２、実施の形態２で示した履歴データに加えて再生部２１０２により再生されている音楽の履歴を記憶しておく履歴データ記憶部１１０３、履歴データ記憶部１１０３に記憶されている履歴データをもとに、状況検出部１１０２により検出される状況と、再生部２１０２により再生される音楽との相関を抽出する相関抽出部２１０３及びキャラクタ管理部１０３ａとデータの送受信を行うデータ送受信部２１０４から構成される。

音楽データ記憶部２１０１は、音楽コンテンツであるコンテンツデータ２１０１ａ及びその一覧を示すメタデータ２１０１ｂを記憶しているＨＤＤやＣＤ、ＤＶＤ−ＲＡＭ等の記憶装置である。メタデータ２１０１ｂは、図２２に示されるように、記憶されているコンテンツデータ２１０１ａに含まれる全ての曲を識別する「曲ＩＤ」、「アーティスト」、「ジャンル」及び「曲調」等の属性が記録されたディレクトリデータである。

図２３は、本実施の形態において履歴データ記憶部１１０３に記憶されている履歴データの一例である。実施の形態２に示した履歴データに比べて、さらに再生部２１０２により再生された音楽の履歴が記憶されている。音楽の履歴は、図のように再生された音楽のみをエントリ単位で記憶しておく以外にも、演奏が開始された時刻や経路（例えば、Ｃ８→Ｃ５）や、スキップやリピートなどその音楽に対してユーザによりなされた操作とともに記憶しておくのでもよい。ここで、スキップとは再生されている音楽を聴くのを中止してそれ以外の音楽を聴くための操作であり、リピートとは再生されている音楽を２回以上繰り返して聴くための操作である。

図２４は、相関抽出部２１０３による相関の抽出及び最も強い相関の特定の詳細な処理手順を示すフローチャートである。
まず、相関抽出部２１０３は、現在状況を構成する項目（「運転者」、「同乗者」、「目的地」、「曜日」など）のうち、予め設定された項目の組み合わせ（図２５に示されたＮｏ．１〜ｎまでの「相関抽出に使用する項目」）を１つ選択し（ステップＳ２４０１）、内容が一致する全てのエントリを履歴データ記憶部１１０３の履歴データから抽出し（ステップＳ２４０２）、それらエントリに記録された「曲」について、最も選曲件数の多いアーティスト、ジャンル及び曲調それぞれを特定し（ステップＳ２４０３）、特定した最頻度のアーティスト、ジャンル及び曲調の選曲比率（それぞれ、抽出した全エントリに記録された全アーティスト、全ジャンル、全曲調に対する最頻度のアーティスト、最頻度のジャンル、最頻度の曲調が選択された割合）を算出する（ステップＳ２４０４）。

そしてまだ選択されていない組み合わせがあれば（ステップＳ２４０５でＹｅｓ）、ステップＳ２４０１から同様の処理を繰り返す。
そして、予め設定された全ての組み合わせ（図２５に示されたＮｏ．１〜ｎまでの「相関抽出に使用する項目」）について算出した最頻度のアーティスト、ジャンル、曲調の選曲比率の中から、最も高い選曲比率の特性（具体的なアーティスト、ジャンル、曲調）を最も相関の強い曲の特性として決定する（ステップＳ２４０６）。

たとえば、現在状況の「運転者」が「お父さん」、「同乗者」が「なし」、「目的地」が「会社」、「曜日」が「平日」である場合には、相関抽出部２１０３は、以下のようにして、最も相関の強い曲の特性を決定する。

まず、図２５に示されたＮｏ．１の項目の組み合わせ（「運転者」及び「目的地」）について現在状況と一致するエントリ、つまり、「運転者」が「お父さん」で、かつ、「目的地」が「会社」である全てのエントリを履歴データから読み出し、それらのエントリに記録された全ての「曲」について、アーティスト、ジャンル及び曲調ごとに集計することで、最も多く選曲されたアーティスト、ジャンル及び曲調とそれぞれの選曲比率（例えば、最頻度で選択されたアーティストが「Ｆ」でその選択比率が２５％、最頻度で選択されたジャンルが「Ｊ−ＰＯＰ」で選択比率が４２％、最頻度で選択された曲調が「躍動感」でその選択比率が３４％）を算出する。

同様にして、図２５に示されたＮｏ．２の項目の組み合わせ（「運転者」、「目的地」及び「同乗者」）について現在状況と一致するエントリ、つまり、「運転者」が「お父さん」で、かつ、「目的地」が「会社」で、かつ、「同乗者」が「なし」である全てのエントリを履歴データから読み出し、それらのエントリに記録された全ての「曲」について集計することで、最も多く選曲されたアーティスト、ジャンル及び曲調とそれぞれの選曲比率を算出する。

以下、同様にして、図２５に示されたＮｏ．３〜Ｎｏ．ｎの項目の組み合わせそれぞれについて、最も多く選曲されたアーティスト、ジャンル及び曲調とそれぞれの選曲比率を算出し、最後に、算出された合計３ｎ個の選曲比率の中から最も高いものを特定し、その選曲比率に対応する曲の特性（例えば、ジャンル「Ｊ−ＰＯＰ」）が現在状況と最も相関が強い曲の特性と決定する。

図２６は、以上のような手順によって自動選曲される曲と現在状況との組み合わせの例を示す図である。ここでは、例えば、車で、「平日」に「お父さん」が「会社」に行くときには、ジャンル「Ｊ−ＰＯＰ」の曲が自動演奏され、「お母さん」が「スーパーＡ」に行くときには、ジャンル「洋楽」の曲が自動演奏され、「休日（「土・日」）」に「家族（運転者が「お父さん」で同乗者が「お母さん」）で経路「Ｃ６−Ｃ８（海岸沿いの道）」を走行するときには、曲調「爽快」な曲が自動演奏され、食事（「目的地」が「レストランＢ」）に行くときには、ジャンル「バラード」の曲が自動演奏され、「長男Ａ」が運転するときには、「アーティストＣ」の曲が自動演奏される例が示されている。

相関抽出部２１０３はまた、データ送受信部２１０４によりキャラクタ管理部１０３ａから受信したデータに基づいて、履歴データ記憶部１１０３から抽出した相関の修正を行う。具体的には、図２６の相関において、曜日が「土・日」であり、経路が「Ｃ６―Ｃ８」、運転手が「お父さん」、同乗者が「お母さん」という状況での好みの音楽は「爽快」であるが、この状況においてキャラクタ管理部１０３ａから「躍動」に相当する音楽を再生するよう指示が与えられると（詳細については後述する）、図２７で示される相関を図２８のように修正する。さらにこの指示に従って再生部２１０２に対して「躍動」の音楽を再生するよう指示し、再生部２１０２は、音楽データ記憶部２１０１から「躍動」の音楽を選択して再生を行うことになる。

判定部２０４は、履歴データ記憶部１１０３に記憶されている履歴に基づいてイベントの発生を判定する。イベントとは具体的には、曲ＩＤ００１からＩＤ０１０の音楽をまとまりとしたときにこのまとまりが複数回繰り返して再生されている、ユーザが複数回繰り返してスキップ操作を行った、同じ音楽が累計で幾度となく再生されておりユーザにとって目新しさがなくなった、などユーザが現在再生されている音楽に対して食傷気味であると判断される状態である。これ以外にも、自動選曲機能や音楽検索機能などが備わっている場合には、ユーザがこの機能の実行を明示的に指示してもよい。さらには、音楽再生機能を所定時間以上利用していない、ＦＭやＡＭ放送、音楽再生機能などをザッピングしている、渋滞している、運転者や同乗者が眠くなっている、などの状態を検出するのでもよい。このうち眠くなっている状態の検出方法は、カメラでユーザの顔を撮影し解析するのでもよいし、ユーザの体と接触している箇所に脈拍を検知するセンサを設けて、脈拍が安定している状態を検出するのでもよい。

データ送受信部２１０４は判定部２０４の判定に従って、相関抽出部２１０３により抽出されたユーザの好みの音楽に関する情報をキャラクタ管理部１０３ａへ送信する。また、キャラクタ管理部１０３ａから所定の情報を受信する。

次にこのように構成されるイベント検出部１０２ｂにおけるイベント検知、およびデータの送受信に関する動作について、図２８のフローチャートを用いて説明する。
相関抽出部２１０３により、履歴データ記憶部１１０３のデータから現在の状況において好まれる音楽に関する相関が抽出されると（ステップＳ２８０１）、判定部２０４において上述したイベントが発生しているかどうかの判定が行われる。イベントが発生したと判定されると（ステップＳ２８０２でＹｅｓ）、データ送受信部２１０４により現在の状況においてユーザに好まれる音楽に関する情報がキャラクタ管理部１０３ａに送信される（ステップＳ２８０３）。

データ送受信部２１０４では、キャラクタ管理部１０３ａからのデータ受信待ち状態にはいり、データを受信すると（ステップＳ２８０４でＹｅｓ）、相関抽出部２１０３では現在の状況と好みの音楽の相関を修正する必要があるかどうか判定する。修正する必要があれば（ステップＳ２８０５でＹｅｓ）、相関を修正し（ステップＳ２８０７）、データ送受信部２１０４において受信したデータに基づいて音楽の再生を行う（ステップＳ２８０５）。

次に、本実施の形態におけるキャラクタ管理部１０３ｂの構成について図２９の機能ブロック図を用いて説明する。図中、実施の形態１、２に示した構成と同一の機能のものは同一番号を付与し、詳細な説明は省く。

このキャラクタ管理部１０３ｂは、表示部１０１、シナリオ選択部５０２、シナリオデータ５０３、出力内容決定部５０５、キャラクタ記憶部５０６、イベント検出部１０２ｂとデータの送受信を行う送受信部２９０１、ユーザと対話装置１００との対話を制御する対話制御部２９０６、ユーザからの入力を受け付ける入力部１０５、入力される語彙の一覧を記憶しておく入力語彙記憶部２９０４、入力語彙記憶部２９０４に記憶されている語彙の一覧の中で現在の状態においてユーザからの入力の可能性がある候補を作成する入力候補作成部２９０５、及び、入力部１０５に入力された内容を解釈する解釈部２９０３から構成される。

本実施の形態においてシナリオデータに記憶されるシナリオの例を図３０に示す。図中、シーケンス１とシーケンス４（Ｙｅｓ）の後に設けられた「Ｗａｉｔ ｕｓｅｒ ｉｎｐｕｔ」は、それぞれの発話が終わった後、所定の時間（例えば、５秒）ユーザからの入力待ち状態に入ることを示している。詳しく述べると、シーケンス１の後はエージェントによる問いかけの後の肯定、否定に関するユーザからの入力を、そして、シーケンス４（Ｙｅｓ）の後はユーザの好みの音楽ジャンルに関する自由な入力を待つことになる。また、シーケンス１の後は、ユーザからの肯定、否定の入力に応じてその後のシナリオが変化する。ユーザから肯定的な入力があった場合は、図のシーケンス２（Ｙｅｓ）からシーケンス６（Ｙｅｓ）までのシナリオが実行され、否定的な入力があった場合は、シーケンス２（Ｎｏ）からシーケンス３（Ｎｏ）が実行される。ユーザからの入力は必ずしも必要ではなく、ユーザからの入力がない場合には、デフォルトとしてシーケンス２（Ｙｅｓ）からシーケンス６（Ｙｅｓ）のシナリオを実行するようにするとよい。また、図中シーケンス３（Ｙｅｓ）の後に設けられた「Ｄｉｓｐｌａｙ ｆａｖｏｒｉｔｅ ｇｅｎｒｅ Ｌｉｓｔ」は、相関抽出部２１０３により抽出される、現在のシチュエーションにおいてユーザが好むと考えられる音楽のジャンルがリスト形式でユーザに提示されることを示している。シーケンス５（Ｙｅｓ）、６（Ｙｅｓ）において（ｇｅｎｒｅ）はパラメータであり、ユーザから入力された音楽ジャンル、または、入力がない場合にユーザの好みにしたがって自動的に選択されたジャンルの名称が充当される。

次にこのように構成されるキャラクタ管理部１０３ｂの一連の動作について、図３１のフローチャートを用いて説明する。
送受信部２９０１において、イベント検出部１０２ｂからデータを受信すると（ステップＳ３１０１でＹｅｓ）、シナリオ選択部５０２は、シナリオデータ５０３の中から所定のシナリオを選択する（ステップＳ３１０２）。なお、本実施の形態では簡単のためシナリオを１種類にしているが、当然、実施の形態１や２のように、イベント検出部１０２ｂからの受信内容に応じてシナリオを選択するようにしてもよい。

対話制御部２９０６では、選択されたシナリオに基づいて発話内容を順次決定していく（ステップＳ３１０３）。図３０のシナリオに従うと、まずシーケンス１の「そろそろ違う曲にしましょか」というエージェントの発話が行われる。表示部１０１における表示例を図３２に示す。

シーケンス１の後は「Ｗａｉｔ ｕｓｅｒ ｉｎｐｕｔ」により入力待ち状態にはいるため（ステップＳ３１０４でＹｅｓ）、入力候補作成部２９０５ではユーザからの入力の可能性にしたがって入力語彙記憶部２９０４の語彙の取捨選択が行われる（ステップＳ３１０５）。

入力候補作成部２９０５の動作について説明する。図３３の２９０４ａに入力語彙記憶部２９０４に記憶されている語彙の例を示す。シーケンスに基づくと、シーケンス１の発話のあとは、ユーザからの肯定、否定を表す表現の入力があると予想されるため、入力候補作成部２９０５は２９０４ａの中からカテゴリ「Ｙｅｓ／Ｎｏ」に属する３３０１に示される語彙のみを抽出して、入力候補として作成する。このとき、入力の可能性のある語彙を完全に３３０１に限定してしまうのではなく、他の語彙に比べて入力可能性の優先度を高めるという処理を施すのでもかまわない。

対話制御部２９０６では所定時間以内に入力があるかどうかの判定を行い、なければ（ステップＳ３１０６でＮｏ）シナリオにしたがってシーケンス２（Ｙｅｓ）、シーケンス３（Ｙｅｓ）の発話を行う。表示例を図３４に示す。

シーケンス３（Ｙｅｓ）の発話のあとは、「Ｄｉｓｐｌａｙ ｆａｖｏｒｉｔｅ ｇｅｎｒｅ Ｌｉｓｔ」であるので、送受信部２９０１で受信したユーザの好みの音楽のリストを表示し、シーケンス４（Ｙｅｓ）の発話を行い、さらに「Ｗａｉｔ ｕｓｅｒ ｉｎｐｕｔ」によりユーザからの入力待ちを行う（ステップＳ３１０４でＹｅｓ）。表示例を図３５に示す。

入力候補作成部２９０５では、同様に入力候補の取捨選択が行われる（ステップＳ３１０５）。ここでは、（Ｕｓｅｒ Ｆａｖｏｒｉｔｅ ｇｅｎｒｅ）の入力待ちであるので、２９０４ａに示す語彙の中から、送受信部２９０１で受信したユーザの好みの音楽を表す語彙を抽出する。抽出された語彙を３６０１に示す。

ここで、図３７に示すように所定時間内にユーザから入力「躍動」があると（ステップＳ３１０６でＹｅｓ）、対話制御部２９０６では入力内容を記憶しておき（ステップＳ３１０７）、シナリオに発話内容が残っていれば（ステップＳ３１０８でＹｅｓ）、残りの発話を行う。表示例を図３８に示す。

シーケンスが終了すると（ステップＳ３１０８でＮｏ）、対話制御部２９０６に記憶されているユーザからの入力内容は、送受信部２１０６によりイベント検出部１０２ｂへ送信される（ステップＳ３１０９）。

なお、図３０に示したシナリオのほかに、図３９に示すようなシナリオを考えることができる。このシナリオでは、ジャンルリストをユーザに提示して選択してもらうのではなく、エージェントがジャンルを１つずつ提示し、それに対するユーザの反応や応答に応じて対話が進んでいく。図中、（ｇｅｎｒｅ１）や（ｇｅｎｒｅ２）は、ユーザが好む音楽のジャンルを表すパラメータであり、シーケンス３においてエージェントが（ｇｅｎｒｅ１）を提示したあと、「Ｗａｉｔ ｕｓｅｒ ｉｎｐｕｔ」により入力待ち状態となり、ユーザから肯定的な入力があれば、シーケンス４（Ｙｅｓ）に進み、エージェントが発話をしてシナリオは終了する。一方、否定的な入力があった場合や入力がなにもない場合には、シーケンス４（Ｎｏ）に進み、ユーザアバタが他にジャンルを推薦するように働きかける発話を行う。それに対してエージェントはシーケンス５（Ｎｏ）で、別のジャンルである（ｇｅｎｒｅ２）を提示し、入力待ち状態に入る。肯定的な入力があればシーケンス６（Ｙｅｓ）で終了し、それ以外であればシーケンス６（Ｎｏ）で終了する。このように、エージェントが順にジャンルを提示するようなシナリオでは、ユーザは特に表示部１０１に視線を向ける必要がなく、その他の行為を阻害することがなくなるという利点がある。

以上のように、本実施の形態によれば、キャラクタ同士の対話が必ずしも自分の思い通りではない場合には、ユーザは、対話に介入して自分の意思を伝えることができる。したがって、ユーザにとって興味のもてないキャラクタ同士の対話が勝手に進んでいくという不具合が回避される。

なお、データ送受信部２１０４によって車の外部からダウンロードする情報は、音楽データ等のコンテンツだけに限られず、キャラクタ記憶部５０６に記憶させるキャラクタデータやシナリオデータ５０３であってもよい。これによって、車載の対話装置１００が保持するキャラクタデータやシナリオデータを動的に増加させたり更新したりすることが可能になる。例えば、走行している地域に合ったキャラクをエージェントやユーザアバタとして採用することで、ユーザによる注目度を向上させ、その結果として、ユーザに有益な情報が提供され得る。

また、シナリオデータを構成しているシーケンスの構造によっては、シナリオデータの選択（切り替え）によって、シナリオ全体が異なる内容になったり、シナリオの一部だけだ異なる内容になったりする。これらは、シナリオを構成するシーケンスをいかに定義するかによって、適宜決定されることになる。

（実施の形態４）
実施の形態１から３においては、車両の状況に応じてアバタとエージェントの対話のシナリオを選択する方法について述べた。本実施の形態においては、シナリオが選択された後に、さらに、アバタとエージェントが対話の間隔を制御する例について述べる。

本実施の形態における対話装置の構成を図４０に示す。この対話装置は、シナリオデータ記憶部４１０１、キャラクタ記憶部４１０２、シナリオ選択部４１０３、キャラクタ位置決定部４１０４、車両状況検出部４１０５、対話間隔制御部４１０６、出力内容制御部４１０７及び表示部４１０８を備える。なお、これらの構成要素のうち、シナリオデータ記憶部４１０１、キャラクタ記憶部４１０２、シナリオ選択部４１０３、キャラクタ位置決定部４１０４、出力内容制御部４１０７及び表示部４１０８は、それぞれ、実施の形態１におけるシナリオデータ５０３、キャラクタ記憶部５０６、シナリオ選択部５０２、キャラクタ位置決定部５０４、出力内容決定部５０５及び表示部１０１と同様であるため、ここでは説明を省略する。

車両状況検出部４１０５は、ウインカー、ブレーキペダル、アクセルペダル、ハンドブレーキ、ハンドル、ライト、スピードメータ等、車両の状況に関する情報を検出するものである。これにより、ドライバの運転状況を検出することができる。例えば、交差点のカーブを走行中であったり、車線を変更している途中であったり、バックにて車両を後退させようとしている状態であるなどの状況を検出することが可能である。

対話間隔制御部４１０６は、車両状況検出部４１０５の状況に応じてアバタとエージェントとの対話間隔を制御するものである。実施の形態３でも述べたように、エージェントからの情報提供に対して、ユーザに代わってアバタが応答を生成する。これにより、運転者がエージェントからの情報に対して、逐次、応答することなく、自動的に対話が進行する。さらに、エージェントとアバタとの対話において、ユーザはエージェントから提供された情報に対して介入することが可能である。しかしながら、ユーザが運転に集中しなければならないときには、ユーザが対話に対して介入するタイミングを逃してしまうことがある。そこで、ユーザの運転状況に応じてアバタとエージェントとの対話の間隔を制御することで、ユーザが運転に集中しなければならないときには、介入できるタイミングを多くとり、ユーザが運転にそれほど集中する必要がないとき（停車中等）は、テンポよく対話をすすめることが好ましい。

いま、図４２の画面表示例に示されるように、エージェントからの提案である「そろそろポップ系の楽曲にしましょうか？」という発話に対して、アバタが「他のジャンルがいいなぁ」という発話をするシナリオがシナリオ選択部４１０３によって選択され、出力内容制御部４１０７によって表示されるとする。もし、ユーザがポップ系の楽曲の再生を希望したときには、音声入力等により、アバタとエージェントとの対話に介入することができる。しかしながら、運転に集中しなければならないときには、対話に介入するタイミングを逃してしまう。そこで、例えば、車両の速度が時速２０ＫＭ以上で方向指示器（ウインカー）が作動中であると車両状況検出部４１０５によって検出された場合は、対話間隔制御部４１０６は、車両が車線変更を行っているか、交差点の右左折中であると判断し、エージェントの発話から２０秒経過してからアバタが発話を生成するように、出力内容制御部４１０７を制御する。一方、車両が停車中または、上記の車両の速度が時速２０ＫＭ以下であると車両状況検出部４１０５によって検出された場合には、対話間隔制御部４１０６は、エージェントの発話から３秒経過した時点でアバタが発話を生成するように、出力内容制御部４１０７を制御する。

このようにして、車両の状況に応じて、対話の間隔を制御することで、ユーザの運転状況を加味した対話を実現することが可能になる。運転者が慌てて、対話に介入することがなくなるため、安全運転を実現することが可能になる。

上記の動作を図４１のフローを用いて説明する。はじめに、実施の形態１と同様に、シナリオ選択部４１０３及びキャラクタ位置決定部４１０４は、それぞれ、対話のシナリオ及びキャラクタを選択・決定する（ステップＳ４２０１）。この選択・決定に基づいて、出力内容制御部４１０７により、エージェントまたは、アバタの発話が開始される（ステップＳ４２０２）。出力内容制御部４１０７は、エージェントまたはアバタの発話が完了したか否かを検出し、発話が完了している場合には、次のステップ（ステップＳ４２０４）へ進む（ステップＳ４２０３）。発話が完了していない場合には、本ステップを繰り返す。

次の発話があるか否かを判断する（ステップＳ４２０４）。次の発話がある場合には、ステップＳ４２０５へ進む。一方、本発話で終了の場合には、フローを終了する。
次の発話がある場合には、車両状況検出部４１０５は、車両の状況を検出する（ステップＳ４２０５）。検出された車両の状況に応じて、対話間隔制御部４１０６は、対話の間隔を制御する。例えば、車両の速度が時速２０ＫＭ以上で方向指示器を出している場合は、車両の状況が運転に集中しなければならない状況と判断し、次の発話まで２０秒の間隔をとる。車両がそれ以外の状態の場合には、次の発話まで３秒の時間をとる。そして、ステップＳ４２０２へ戻る。

以上の操作を繰り返すことにより、車両の状況に応じて、対話の間隔を制御することが可能になる。特に、アバタとエージェントとの対話に対して、運転者が介入できる場合には、運転者の状況に応じて、対話の間隔を制御する必要がある。

なお、本実施の形態においては、車両の速度と方向指示器の操作に応じて、対話の間隔の制御規則をあらかじめ設定されており、全ての運転者に対して同一の制御を行っている。しかしながら運転者の運転技能は、全ての運転者にとって同一ではないため、運転者毎に制御規則を設定する必要がある。そこで、普段の運転時の車載機器に対する操作履歴から、対話を制御するための制御規則を抽出することも可能である。例えば、車載オーディオ機器の操作履歴を蓄積し、その操作履歴と車両の速度との関係を抽出することで、対話の間隔を制御する規則を決定することも可能である。具体的には、車載オーディオ機器に対する操作の９０％が車両の速度が時速１０KM以下であることが検出できた場合には、対話制御の間隔を制御する閾値を時速１０KMと設定することも可能である。これにより、運転者の技能に応じて対話制御の間隔を決定することが可能になる。

なお、本実施の形態においては、車両の状況として、車両の速度と方向指示器のセンサ情報から車両の状況を判断したが、さらに、車両の走行履歴を蓄積し、運転者が慣れている道路であるかどうかをもとに、対話の間隔を制御してもよい。また、周辺の地図情報を取得し、単位面積あたりの交差点が多い状況では、運転に集中すべきと判断し、対話の間隔を長めにとるようにしてもよい。なお、単位面積あたりの道路の数等により道路の複雑度を評価し、運転者が運転に集中すべき度合いをもとに対話の間隔を制御してもよい。

また、本実施の形態においては、２０秒と３秒という不連続な対話間隔で制御していたが、車両の状況を連続的な値で評価できる場合には、度合いを用いて連続的に対話間隔を制御してもよい。

なお、本実施の形態においては、車両の状況に応じて対話間隔を制御する例について述べた。しかし、地図情報によってエージェントとアバタのキャラクタの位置関係（表示上の位置関係）を制御することも可能である。そのような変形例に係る対話装置の構成を図４３に示す。図４３においては、地図情報検出部４４０５、キャラクタ位置決定部４４０４以外の部分は、図４０に示された同一名の構成要素と同じ機能であるため説明を省略する。

地図情報検出部４４０５は、現在、表示部において表示されている地図情報を検出する。
キャラクタ位置決定部４４０４は、対話シナリオが地図情報に関連するものである場合には、地図情報検出部４４０５で検出された地図情報を用いてエージェントを表示する位置を決定する。一方、地図情報と関連のないシナリオの場合には、地図情報とは独立してエージェントとアバタの位置関係を決定する。例えば、図４４（ａ）の画面表示例に示されるように、ハンバーガー店に関する情報をエージェントが発話する場合には、表示されている地図上に所定のハンバーガー店がある場合には、そこにエージェントを表示させ、それに対応して、対話できる位置にアバタを表示させる。また逆に、地図情報に関連のない、音楽の推薦情報に関する対話シナリオの場合には、図４４（ｂ）の画面表示例に示されるようにエージェントとアバタを横に並べて対話するような位置関係に表示する。このように対話する内容に応じてエージェントとアバタの位置関係を変更することにより、対話によって提供される情報を容易に確認することが可能になる。

なお、上記の実施の形態においては、エージェントとアバタの位置関係の決定例について述べた。しかし、エージェントやアバタは常に表示されている必要がなく、対話の音声のみを確認できたらいい場合もある。そのような要求に応える変形例に係る対話装置の構成を図４５に示す。図４５において、キャラクタ表示制御部４６０５以外の部分は、図４０に示された同一名の構成要素と同様であるため説明を省略する。

キャラクタ表示制御部４６０５は、車両状況検出部４６０４によって車両が停車中であるか否かが検出されると、図４６（ａ）の画面表示例に示されるように、車両が走行中のときには、キャラクタを画面上に表示することなく、音声のみで対話を運転者に伝える。逆に、車両が停車中の場合には、図４６（ｂ）の画面表示例に示されるように、キャラクタを表示し、音声と画像で対話内容を運転者に伝える。このようなキャラクタ表示のＯＮ／ＯＦＦ制御により、走行中は、画面の変化を少なくし、運転に集中することができ、停車中は対話内容から情報を取得しやすくなるという効果がある。なお、エージェントとアバタの表示に関しては、独立で表示の制御を行ってもよい。

（実施の形態５）
上記実施の形態４においては、シナリオに基づく対話の間隔の制御やキャラクタの表示位置・表示／非表示の制御を車両の状況や地図情報を基に行った。本実施の形態においては、対話中に他の情報を取得した場合の対話制御について述べる。

一般に、道路ビーコンから取得される情報は、道路を通過したときに取得され、同時に、その情報を音声等で再生するものである。そのため、対話中に情報を取得した場合には、対話が中断されてしまうことになる。そこで、本実施の形態は、ＶＩＣＳ等で取得された情報であっても、対話と整合がとれる形で、運転者に情報を提供できるようにしたものである。

本実施の形態における対話装置の構成を図４７に示す。この対話装置は、シナリオデータ記憶部４８０１、キャラクタ記憶部４８０２、シナリオ選択部４８０３、キャラクタ位置決定部４８０４、情報読上げ制御部４８０５、対話進行制御部４８０６、出力内容制御部４８０７及び表示部４８０８を備える。なお、これらの構成要素のうち、情報読上げ制御部４８０５及び対話進行制御部４８０６以外は、図４０に示された同一名の構成要素と同様であるため、説明を省略する。

情報読上げ制御部４８０５は、ＶＩＣＳ、ネットワーク等により、取得した情報の読上げを制御する処理部である。例えば、道路ビーコンから渋滞状況等の交通情報を取得し、その情報を読上げることがある。また、ＦＭ多重放送等から天気予報を取得し、明日の天気を読上げることも可能である。

対話進行制御部４８０６は、情報読上げ制御部で読上げる情報があった場合に、エージェントとアバタとの対話の進行を制御するものである。例えば、図４９に示されるように、いま、情報読上げ制御部４８０５が、エージェントとアバタとの対話中にＶＩＣＳ交通情報を取得したとする。エージェントとアバタとの対話は、エージェントからの提案に対して、アバタが応答するというシナリオになっており、対話のクラスタがあらかじめ設定されているものとする。このとき、本図に示されるように、（エージェント提案１−アバタ応答１）および（エージェント提案２−アバタ応答２）の間のタイミングでＶＩＣＳ交通情報を取得した場合には、取得したタイミングで交通情報の読上げをおこない、エージェントとアバタとの対話の妨げになることがない。

しかしながら、図５０に示されるように、情報読上げ制御部４８０５が、エージェント提案１とアバタ応答１との間でＶＩＣＳ情報を取得したとする。このとき、取得と同時に、読上げ再生を行うと、エージェントとアバタとの対話の途中で、異なる情報が挿入され、運転者に混乱を招くおそれがある。そこで、取得した情報が天気予報等の、すぐに運転者に伝えなければならない情報でない場合には、対話進行制御部４８０６は、アバタ応答１の再生後に、ＶＩＣＳ情報の読上げを行うように出力内容制御部４８０７を制御する。これにより、エージェントとアバタの対話の途中で、異なる情報が挿入されることがなくなる。

一方、ＶＩＣＳ等で取得した情報が、交通情報等で、ユーザに早急に知らせる必要がある情報である場合もある。このときの対話制御を、図５１を用いて説明する。図５１は、図５０と同様に、対話の途中で交通情報を取得した例を示している。この場合、ＶＩＣＳで取得した交通情報をエージェント提案１とアバタ応答１の間に再生し、その後、アバタによる補間応答を挿入するように、対話進行制御部４８０６は出力内容制御部４８０７を制御する。具体的には、図５１の例に示されるように、「さっき、なんて？」というようなアバタからの補間応答を再生し、再び、エージェント提案１からのシーケンスを再生するに出力内容制御部４８０７を制御する。これにより、早急に伝えなければならない交通情報を優先して即座にユーザに伝え、自然な対話も実現することが可能になる。

上記の動作を図４８のフローチャートを用いて説明する。対話進行制御部４８０６は、情報読上げ制御部４８０５がＶＩＣＳやネットワークにより割り込み読上げ情報を取得したか否かを判断する（ステップＳ４９０１）。取得していた場合には、次のステップ（ステップＳ４９０２）へ進む。取得していない場合には、本ステップを繰り返す。

割り込み情報を取得したときに、対話進行制御部４８０６は、提案―応答のような組となる対話中であるか否かを判断する（ステップＳ４９０２）。対話中でない場合には、読上げ情報を再生するように出力内容制御部４８０７を制御する（ステップＳ４９０３）。対話の途中である場合には、次のステップ（ステップＳ４９０４）へ進み、対話進行制御部４８０６は、割り込み情報が交通情報のように即時性を重視する情報であるか否かを判断する（ステップＳ４９０４）。即時性のない情報の場合には、ステップＳ４９０５へすすみ、対話が終了してから、読上げ情報を再生するように出力内容制御部４８０７を制御する。即時性のある情報である場合には、ステップＳ４９０６へ進み、取得した情報の読上げ再生を行い、読上げ後、「さっき、なんて」というような補間応答を再生し、再び、対話の組の再生を行うように出力内容制御部４８０７を制御する（ステップＳ４９０７）。

以上の動作により、エージェントとアバタの対話中に、他の情報の読上げ等を行わなければならないときでも、自然な対話を実現することが可能になる。
なお、本実施の形態では、単一の補間応答の例について説明したが、さらに、自然な対話を実現するためには、複数の補間応答を状況によって選択することも可能である。例えば、図５１において「ポップ系は、いかがでしょう」の発話と「○○交差点渋滞しております」という発話との間の時間によって、アバタの補間応答を変更してもよい。具体的には、エージェントの発話と割り込み発話との間の時間が２秒間と短いときには、アバタの補間応答は「もう、一回言って」という応答が補間され、５秒間以上と長いときには、アバタのほか応答は「さっき、なんていいましたっけ」という応答が補間されてもよい。これにより、エージェントとアバタの対話に割り込み発話が挿入されたときにでも、自然な対話を実現することができる。

（実施の形態６）
上記実施の形態４及び５においては、対話の制御について説明した。しかしながら、エージェントとアバタとの対話は、自動的に進行するため、ユーザが聞き逃すことなく、全ての対話を聞き取れる保証はない。そこで、対話した内容について、車両を停車したときには、ユーザが、自動的に進行した情報を振り返ることができるようにした形態を、本実施の形態で説明する。

本実施の形態における対話装置の構成を図５２に示す。この対話装置は、シナリオデータ記憶部５３０１、キャラクタ記憶部５３０２、シナリオ選択部５３０３、キャラクタ選択部５３０４、車両状況検出部５３０５、対話内容蓄積部５３０６、出力内容制御部５３０７及び表示部５３０８を備える。なお、本図においては、対話内容蓄積部５３０６以外は、４１に示された同一名の構成要素と同様であるため説明を省略する。

対話内容蓄積部５３０６は、シナリオにそってエージェントとアバタとの対話内容を蓄積する。そして、車両状況検出部５３０５によって車両が停車したことが確認されると、対話内容蓄積部５３０６は、蓄積した対話内容を表示部５３０８に出力することで、これまでの対話において提供した情報の概要を表示部５３０８に表示させる。

例えば、図５４の画面表示例に示されるように、ユーザが車両を運転中にエージェントとアバタとの間で、いくつかの対話がなされた場合において、対話内容蓄積部５３０６は、それらの対話履歴を蓄積し、車両状況検出部５３０５によって、車両のサイドブレーキ等がかけられ、車両が停止したと判断された場合には、蓄積した対話履歴を表示部５３０８に送ることで、図５４の右下に示される画面表示例のように、それまでの対話で提供された楽曲に関する情報のインデクス（「ジャンル」、「ポップ」、「ジャズ」、「演歌」）を表示させる。これにより、エージェントとアバタとの対話中には、運転に集中していたために、聞き逃した情報であっても、車両を停車したときには、確認することが可能になる。

上記の動作を図５３のフローチャートを用いて説明する。シナリオ選択部５３０３及びキャラクタ選択部５３０４は、それぞれ、シナリオとキャラクタを選択する（ステップＳ５４０１）。選択されたシナリオとキャラクタに応じて、出力内容制御部５３０７により、エージェントまたは、アバタの対話が開始される（ステップＳ５４０２）。車両状況検出部５３０５は、サイドブレーキがかけられているか否かを検出することで、車両が停車しているかを判断する（ステップＳ５４０３）。車両が停止していていない場合には、対話内容蓄積部５３０６は、エージェントとアバタが対話している内容を蓄積する（ステップＳ５４０４）。さらに、対話を継続させ（ステップＳ５４０５）、ステップＳ５４０３へ戻る。

車両が停止していた場合には、ステップＳ５４０６へ進む。対話内容蓄積部５３０６は、蓄積した対話の内容（履歴）を表示部５３０８に出力して表示する。表示された内容に対しては、ユーザはリモコンや音声等の手段を用いて、選択し、その内容を確認することが可能である。

このように、車両が停止してから、エージェントとアバタによって対話された内容を確認することができるため、対話中に聞き逃した内容であっても、車両を停車することで確認することが可能になる。

本発明にかかる対話装置は、キャラクタによる対話を表示する表示装置等として、特に、ナビゲーションや音楽の再生を行う車載装置等として有用である。またＴＶや携帯電話、ＰＤＡ等、表示部を有する機器全般にも応用できる。

本発明の実施の形態全体における対話装置の構成図である。 本発明の実施の形態１におけるイベント検出部の構成図である。 経路間違いを示す図である。 経路逸脱個所の近傍を示す図である。 本発明の実施の形態１におけるキャラクタ管理部の構成図である。 シナリオデータを示す図である。 キャラクタの表示例を示す図である。 キャラクタの表示例を示す図である。 本発明の実施の形態１におけるイベント検出部の動作を示すフローチャートである。 本発明の実施の形態１におけるキャラクタ管理部の動作を示すフローチャートである。 本発明の実施の形態２におけるイベント検出部の構成図である。 地図データ記憶部に記憶されているノードデータを示す図である。 履歴データ記憶部に記憶されている履歴データを示す図である。 ランドマークと、その属するジャンルを定義した図である。 本発明の実施の形態２におけるキャラクタ管理部の構成図である。 キャラクタ記憶部に記憶されているエージェント、ユーザアバタの一例を示す図である。 キャラクタ選択部によるキャラクタ選択の基準を示す図である。 シナリオデータを示す図である。 本発明の実施の形態２におけるイベント検出部の動作を示すフローチャートであり、（ａ）は履歴情報を蓄積する処理を、（ｂ）は目的地を予測する処理のフローチャートである。 本発明の実施の形態２におけるキャラクタ管理部の動作を示すフローチャートである。 本発明の実施の形態３におけるイベント検出部の構成図である。 音楽データ記憶部に記憶されたメタデータの一例を示す図である。 履歴データ記憶部に記憶されている履歴データを示す図である。 相関抽出部の動作を示すフローチャートである。 相関抽出部による相関抽出に使用される項目の例を示す図である。 現在状況とその状況で好む曲との組み合わせの例を示す図である。 現在状況とその状況で好む曲との組み合わせが修正された様子を示す図である。 本発明の実施の形態３におけるイベント検出部の動作を示すフローチャートである。 本発明の実施の形態２におけるキャラクタ管理部の構成図である。 シナリオデータを示す図である。 本発明の実施の形態３におけるキャラクタ管理部の動作を示すフローチャートである。 キャラクタの表示例を示す図である。 入力語彙記憶部に記憶されている語彙と、入力候補作成部により作成される語彙の例を示す図である。 キャラクタの表示例を示す図である。 キャラクタの表示例を示す図である。 入力語彙記憶部に記憶されている語彙と、入力候補作成部により作成される語彙の例を示す図である。 キャラクタの表示例と、ユーザによる入力を示す図である。 キャラクタの表示例を示す図である。 シナリオデータを示す図である。 本発明の実施の形態４における対話装置の構成を示すブロック図である。 実施の形態４における対話装置の動作を示すフローチャートである。 キャラクタの表示例を示す図である。 変形例に係る対話装置の構成を示すブロック図である。 キャラクタの表示例を示す図である。 変形例に係る対話装置の構成を示すブロック図である。 キャラクタの表示例を示す図である。 本発明の実施の形態５における対話装置の構成を示すブロック図である。 実施の形態５における対話装置の動作を示すフローチャートである。 エージェントとアバタとの対話の進行例を示す図である。 エージェントとアバタとの対話の進行例を示す図である。 エージェントとアバタとの対話の進行例を示す図である。 本発明の実施の形態６における対話装置の構成を示すブロック図である。 実施の形態６における対話装置の動作を示すフローチャートである。 キャラクタの表示例を示す図である。

符号の説明

１００ 対話装置
１０１、４１０８、４４０７、４６０７、４８０８、５３０８ 表示部
１０２、１０２ａ、１０２ｂ イベント検出部
１０３、１０３ａ、１０３ｂ キャラクタ管理部
１０４ スピーカー
１０５ 入力部
１０６ エージェント
１０７ ユーザアバタ
２０１ 位置検出部
２０２ 経路案内部
２０３ 逸脱地点記憶部
２０４ 判定部
２０５ 送信部
５０１ 受信部
５０２、４１０３、４４０３、４６０３、４８０３、５３０３ シナリオ選択部
５０３ シナリオデータ
５０３ａ シナリオデータの一例
５０３ｂ シナリオデータの一例
５０３ｃ シナリオデータの一例
５０３ｄ シナリオデータの一例
５０３ｅ シナリオデータの一例
５０３ｆ シナリオデータの一例
５０３ｇ シナリオデータの一例
５０３ｈ シナリオデータの一例
５０４ キャラクタ位置決定部
５０５ 出力内容決定部
５０６、４１０２、４４０２、４６０２、４８０２、５３０２ キャラクタ記憶部
１１０１ 地図データ記憶部
１１０１ａ 地図データ
１１０１ｂ ノードデータ
１１０２ 状況検出部
１１０３ 履歴データ記憶部
１１０４ 予測部
１１０５ 情報取得部
１５０１ キャラクタ選択部
１７０１ａ キャラクタ選択基準
１７０１ｂ キャラクタ選択基準
２１０１ 音楽データ記憶部
２１０１ａ コンテンツデータ
２１０１ｂ メタデータ
２１０２ 再生部
２１０３ 相関抽出部
２１０４ データ送受信部
２９０１ 送受信部
２９０３ 解釈部
２９０４ 入力語彙記憶部
２９０４ａ 入力語彙記憶部の語彙の一例
２９０５ 入力候補作成部
２９０６ 対話管理部
３３０１ 入力候補作成部により作成される入力候補の一例
３６０１ 入力候補作成部により作成される入力候補の一例
４１０１、４４０１、４６０１、４８０１、５３０１ シナリオデータ記憶部
４１０７、４４０６、４６０６、４８０７、５３０７ 出力内容制御部
４１０４ キャラクタ位置決定部
４１０５、４６０４、５３０５ 車両状況検出部
４１０６ 対話間隔制御部
４４０４、４８０４ キャラクタ位置決定部
４４０５ 地図情報検出部
４６０５ キャラクタ表示制御部
４８０５ 情報読上げ制御部
４８０６ 対話進行制御部
５３０６ 対話内容蓄積部

Claims (4)

1. 画面に表示されるキャラクタによる対話を、車両を運転するユーザに対して表示する車載対話装置であって、
   ユーザが運転する車両の速度と方向指示器の少なくとも１つから車両の状況を検出する状況検出手段と、
   検出された車両の状況に基づいて、ユーザに代わってユーザが知りたいと思われることを代弁する役割を果たすキャラクタであるユーザアバタとその対話相手となるキャラクタであるエージェントとの対話からなるシナリオを決定するキャラクタ管理手段と、
   前記キャラクタ管理手段による決定に基づいて、前記ユーザアバタと前記エージェントを表示し、前記ユーザアバタと前記エージェントとの対話を音声出力する表示手段とを備え、
   前記キャラクタ管理手段は、
   複数の異なるシナリオを特定する複数のシナリオデータを記憶しているシナリオデータ記憶手段に記憶されたシナリオデータの中から、シナリオデータを選択するシナリオデータ選択手段と、
   前記選択されたシナリオデータに対応した、前記ユーザアバタと前記エージェントとの対話を制御する対話制御手段とを備え、
   前記対話制御手段は、前記状況検出手段により検出される車両の状況が変化し、前記シナリオデータ選択手段により選択されたシナリオデータに、ユーザからの入力を受け付ける旨の情報が存在している場合には、所定の時間だけ対話の進行を停止する
   ことを特徴とする車載対話装置。
2. 前記対話制御手段は、前記状況検出手段により検出される車両の速度情報から車両が後退状況にあることを検出したときには、ユーザから入力を受け付ける時間を長くする
   ことを特徴とする請求項１記載の車載対話装置。
3. 前記対話制御手段は、前記状況検出手段によって方向指示器が作動中であると検出されたときには、前記車両が右左折中であると判断し、ユーザから入力を受け付ける時間を長くする
   ことを特徴とする請求項１記載の車載対話装置。
4. 前記対話制御手段は、
   前記状況検出手段によって車両の速度情報が所定の閾値より小さいことが検出されたときにユーザから入力を受け付ける時間を長くする制御規則を有し、
   運転者の車載オーディオ機器に対する操作履歴と車両の速度履歴とを蓄積し、蓄積している操作履歴と速度履歴とに依存させて、前記所定の閾値を変更する
   ことを特徴とする請求項１記載の車載対話装置。

Images