JP2021124687A

JP2021124687A - 車載装置及び提案出力方法

Info

Publication number: JP2021124687A
Application number: JP2020020066A
Authority: JP
Inventors: 智春片岡; Tomoharu Kataoka
Original assignee: Denso Ten Ltd
Current assignee: Denso Ten Ltd
Priority date: 2020-02-07
Filing date: 2020-02-07
Publication date: 2021-08-30

Abstract

【課題】装置側からの提案に対する乗員の受容度を向上させる。【解決手段】車両に搭載される車載装置は、乗員の発話の内容を認識する音声認識部と、乗員に対して音声を出力する音声出力部と、音声認識部及び音声出力部を用いて乗員と会話を行い、会話の中で提案通知（Ｓ１５）により乗員に対して提案を行う会話処理部と、を備える。会話処理部は、提案を行う際、提案に関連し且つ乗員の同意を求める提案前通知（Ｓ１１）を乗員に対して行い、その後に提案通知を行う。【選択図】図５

Description

本発明は、車載装置及び提案出力方法に関する。

人工知能を有し、ユーザと対話する機械（チャットボット）が実用化されている。この技術を車載装置に適用すれば、車載装置と乗員との間で会話を行うことが可能となり、会話の中で車載装置から乗員に対し何らかの提案（休憩の提案等）を行うことも可能となる。

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

乗員に対し、例えば“休憩をとること”を提案する際、単純には「休憩しましょう」や「休憩しませんか」といった内容を車載装置から乗員に伝えることになる。しかしながら、このような単純な方法では提案が受け入れられないことも多いと考えられ、提案の行い方に工夫の余地があると考えられる。

本発明は、装置側からの提案に対する乗員の受容度向上に寄与する車載装置及び提案出力方法を提供することを目的とする。

本発明に係る車載装置は、車両に搭載される車載装置において、乗員の発話の内容を認識する音声認識部と、前記乗員に対して音声を出力する音声出力部と、前記音声認識部及び前記音声出力部を用いて前記乗員と会話を行い、前記会話の中で提案通知により前記乗員に対して提案を行う会話処理部と、を備え、前記会話処理部は、前記提案を行う際、前記提案に関連し且つ前記乗員の同意を求める提案前通知を前記乗員に対して行い、その後に前記提案通知を行う構成（第１の構成）である。

上記第１の構成に係る車載装置において、前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、前記会話処理部は、否定形の疑問文を用いて前記提案通知を行い、前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案に対して同意したとみなす構成（第２の構成）であっても良い。

上記第１の構成に係る車載装置において、前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、前記会話処理部は、肯定形の疑問文を用いて前記提案通知を行い、前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案を拒否したとみなす構成（第３の構成）であっても良い。

上記第１の構成に係る車載装置において、前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、前記会話処理部は、否定形の疑問文又は肯定形の疑問文を用いて前記提案通知を行い、前記否定形の疑問文を用いて前記提案通知を行った場合における前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案に対して同意したとみなし、前記肯定形の疑問文を用いて前記提案通知を行った場合における前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案を拒否したとみなす構成（第４の構成）であっても良い。

上記第４の構成に係る車載装置において、前記会話処理部は、前記提案として第１種類の提案又は第２種類の提案を行うことが可能であり、前記提案の種類に応じ、前記提案通知における疑問文を否定形にするか肯定形にするかを切り替える構成（第５の構成）であっても良い。

上記第５の構成に係る車載装置において、前記会話処理部は、前記提案の内容と推定用情報に基づき前記提案に対する前記乗員の同意しやすさを推定する同意推定部を有し、前記提案に対し前記乗員が相対的に同意しやすいと推定されるとき前記提案を前記第１種類に分類して前記提案通知における疑問文の形を肯定形に設定し、前記提案に対し前記乗員が相対的に同意しにくいと推定されるとき前記提案を前記第２種類に分類して前記提案通知における疑問文の形を否定形に設定する構成（第６の構成）であっても良い。

上記第６の構成に係る車載装置において、前記推定用情報は履歴情報を含み、前記履歴情報は、過去に前記乗員に対して行った提案通知の夫々に対する前記乗員の回答結果を含む構成（第７の構成）であっても良い。

上記第２〜第７の構成の何れかに係る車載装置において、前記会話処理部は、前記車両に前記乗員と他の乗員が搭乗している場合、前記回答受付処理の後、前記提案に関連する情報を前記他の乗員に通知する構成（第８の構成）であっても良い。

上記第１〜第８の構成の何れかに係る車載装置において、前記提案前通知は、事実に基づいた通知を含む構成（第９の構成）であっても良い。

上記第１〜第９の構成の何れかに係る車載装置において、前記乗員は、前記車両のドライバである構成（第１０の構成）であっても良い。

本発明に係る提案出力方法は、車両に搭載される車載装置にて用いられる提案出力方法において、乗員の発話の内容を認識する音声認識ステップと、前記乗員に対して音声を出力する音声出力ステップと、前記音声認識ステップ及び前記音声出力ステップを通じて前記乗員と会話を行い、前記会話の中で提案通知により前記乗員に対して提案を行う会話処理ステップと、を備え、前記会話処理ステップは、前記提案を行う際、前記提案に関連し且つ前記乗員の同意を求める提案前通知を前記乗員に対して行い、その後に前記提案通知を行う構成（第１１の構成）である。

本発明によれば、装置側からの提案に対する乗員の受容度向上に寄与する車載装置及び提案出力方法を提供することが可能となる。

本発明の実施形態に係り、車両の車室内の様子を概略的に示した図である。本発明の実施形態に係り、複数の乗員と各乗員が所持する端末装置を示した図である。本発明の実施形態に係り、車両に搭載される車載システムの構成図である。本発明の実施形態に係り、車室内に２つの表示部が設けられる様子を示した図である。本発明の実施形態に係る提案シーケンスのフローチャートである。本発明の実施形態に係り、車室内にドライバと一人の同乗者が搭乗している様子を示す図である。本発明の実施形態に属する第１実施例に係り、提案シーケンスの流れを示す図である。本発明の実施形態に属する第２実施例に係り、提案シーケンスの流れを示す図である。本発明の実施形態に属する第３実施例に係り、会話処理部の機能ブロック図である。本発明の実施形態に属する第５実施例に係り、提案履歴アイコンの例を示す図である。本発明の実施形態に属する第５実施例に係り、提案履歴アイコンの他の例を示す図である。

以下、本発明の実施形態の例を、図面を参照して具体的に説明する。参照される各図において、同一の部分には同一の符号を付し、同一の部分に関する重複する説明を原則として省略する。尚、本明細書では、記述の簡略化上、情報、信号、物理量又は部材等を参照する記号又は符号を記すことによって、該記号又は符号に対応する情報、信号、物理量又は部材等の名称を省略又は略記することがある。例えば、後述の“２１”によって参照される地図情報は（図３参照）、地図情報２１と表記されることもあるし、情報２１と略記されることもあり得るが、それらは全て同じものを指す。

図１は本実施形態に係る車両ＣＲの車室内の様子を概略的に示した図である。以下、車両ＣＲの車室を単に車室と称することがある。本実施形態に係るアシスタント装置１は車両ＣＲに設置される。ここでは、車両ＣＲとして路面上を走行可能な車両（自動車等）を主として想定するが、車両ＣＲは任意の種類の車両であって良い。車両ＣＲの運転席からステアリングホイールに向かう向きを「前方」と定義し、車両ＣＲのステアリングから運転席に向かう向きを「後方」と定義する。前後方向に直交し且つ路面に平行な方向を左右方向と定義する。

アシスタント装置１は、ユーザと会話したり、その会話を通じて車両ＣＲに搭載された様々な機器（車両ＣＲに設置された照明装置、ワイパ、エアコンディショナ等）を制御することができる。本実施形態において、ユーザとは車両ＣＲの乗員（以下、単に乗員と称することがある）を指す。車両ＣＲの乗員は、車両ＣＲの運転操作を行うドライバ（運転手）又はドライバ以外の同乗者である。アシスタント装置１は、車両ＣＲの運転席の前方など、車室内の適所に設置される。

車両ＣＲに最大でｎ人の乗員が搭乗することができ、車両ＣＲにはｎ人の乗員が着席可能な座席が設けられる。ｎは１以上の任意の整数であって良いが、本実施形態では特に断りなき限り、“ｎ＝４”であるとし、車室内に４つの座席ＳＴ［１］〜ＳＴ［４］が設置されているものとする。座席ＳＴ［１］は、車両ＣＲの運転操作を行うドライバ（運転手）が着席すべき運転席である。ドライバは前を向いて座席ＳＴ［１］に座っているものとし、ドライバから見て座席ＳＴ［１］の左側に助手席に相当する座席ＳＴ［２］が設置される。座席ＳＴ［１］の後方に座席ＳＴ［３］が設置され、座席ＳＴ［２］の後方に座席ＳＴ［４］が設置される。尚、座席ＳＴ［１］〜ＳＴ［４］の内、２以上の座席は互いに分離されない１つの幅広座席により構成されていても良い。例えば、座席ＳＴ［３］及びＳＴ［４］は１つの幅広座席にて構成されていても良い。

図２を参照し、座席ＳＴ［１］〜ＳＴ［４］に着席しうる乗員を、夫々、乗員ＰＳ［１］〜ＰＳ［４］と称する。本実施形態では、少なくとも乗員ＰＳ［１］としてのドライバは座席ＳＴ［１］に着席しているが、乗員ＰＳ［２］〜ＰＳ［４］の内、一部又は全部は存在しない場合もある。図２では、乗員ＰＳ［１］〜ＰＳ［４］が存在すると仮定されている。図２において、装置ＴＤ［１］〜ＴＤ［４］は、夫々、乗員ＰＳ［１］〜ＰＳ［４］が所持している端末装置を表す。各端末装置は、例えば、タブレットのような情報端末、又は、携帯電話機（スマートホンに分類されるものを含む）である。但し、各乗員が端末装置を所持していることは必ずしも必要ではなく、乗員ＰＳ［１］〜ＰＳ［４］の内、１以上の乗員は端末装置を所持していないこともある。

車室内において座席ごとにマイクロホン及びスピーカが設置される。座席ＳＴ［ｉ］に対して設置されたマイクロホン及びスピーカを夫々マイクロホンＭＣ［ｉ］及びスピーカＳＰ［ｉ］と称する（ｉは任意の整数）。マイクロホンＭＣ［ｉ］及びスピーカＳＰ［ｉ］は乗員ＰＳ［ｉ］（換言すれば座席ＳＴ［ｉ］）に対して割り当てられたマイクロホン及びスピーカである。各マイクロホンは、対応する乗員の発話内容を音声信号に変換してアシスタント装置１に出力する。各スピーカは、アシスタント装置１から提供される音声信号に基づく音を、対応する乗員に対して出力する。

図３に車両ＣＲに搭載される車載システムＳＹＳの構成図を示す。車載システムＳＹＳは、上述のアシスタント装置１に加えて、カメラ部ＣＭ、マイク部ＭＣ及びスピーカ部ＳＰと、車載センサ部２、ＧＰＳ処理部３及び計時部４と、を備える。アシスタント装置１と、カメラ部ＣＭ、マイク部ＭＣ及びスピーカ部ＳＰの夫々とは、互いに直接接続されるか、或いは、車両ＣＲ内に形成されたＣＡＮ（Controller Area Network）を通じて接続される。アシスタント装置１と車載センサ部２、ＧＰＳ処理部３及び計時部４との接続についても同様である。アシスタント装置１は、主制御部１０、記憶部２０、通信モジュール３０及びインターフェース部４０を備える。

カメラ部ＣＭは、車内カメラ及び車外カメラを備えていて良い。車内カメラは車室内の領域を撮影領域（視野）として持ち、車外カメラは車両ＣＲの外部領域（例えば、車両ＣＲの前方又は後方の領域）を撮影領域として持つ。車内カメラ及び車外カメラは、夫々に、自身の撮影領域内の様子を所定のフレームレートで順次撮影して、撮影結果を示すカメラ画像の画像情報（画像データ）を順次主制御部１０に送る。車内カメラの撮影結果を示すカメラ画像を車内カメラ画像と称し、車外カメラの撮影結果を示すカメラ画像を車外カメラ画像と称する。

マイク部ＭＣは、乗員ごとの発話内容を収音可能な収音部であり、図１に示したマイクロホンＭＣ［１］〜ＭＣ［４］から成る。マイクロホンＭＣ［ｉ］は、対応する乗員ＰＳ［ｉ］の発話内容を収音し、収音した音を音声信号に変換して出力する。マイクロホンＭＣ［１］〜ＭＣ［４］の出力音声信号は主制御部１０に入力される。マイクロホンＭＣ［ｉ］は、対応する乗員ＰＳ［ｉ］の発話内容を効率的に収音できるよう、座席ＳＴ［ｉ］以外の各座席よりも座席ＳＴ［ｉ］に近い位置に設置される。対応する乗員の発話内容の収音に適するような指向性を各マイクロホンに持たせても良い。

スピーカ部ＳＰは図１に示したスピーカＳＰ［１］〜ＳＰ［４］から成る。スピーカＳＰ［ｉ］は、アシスタント装置１から提供される音声信号に基づく音を、対応する乗員ＰＳ［ｉ］に対して出力する。スピーカＳＰ［ｉ］の出力音が、対応する乗員ＰＳ［ｉ］に対して聞き取りやすくなるよう且つ他の乗員に聞こえにくくなるよう、座席ＳＴ［ｉ］以外の各座席よりも座席ＳＴ［ｉ］に近い位置にスピーカＳＰ［ｉ］が設置される。対応する乗員が存在する向きに対し感度が高まるような指向性を各スピーカに持たせても良い。

尚、座席ごとのマイクロホンが車両ＣＲに設置されない場合もある。この場合においては、各乗員が所持する端末装置に内蔵されたマイクロホンを用いてマイク部ＭＣが構成されて良い。即ち、端末装置ＴＤ［ｉ］に内蔵されたマイクロホンをマイクロホンＭＣ［ｉ］として用いるようにしても良い。同様に、座席ごとのスピーカが車両ＣＲに設置されない場合もある。この場合においては、各乗員が所持する端末装置に内蔵されたスピーカを用いてスピーカ部ＳＰが構成されて良い。即ち、端末装置ＴＤ［ｉ］に内蔵されたスピーカをスピーカＳＰ［ｉ］として用いるようにしても良い。

アシスタント装置１と端末装置ＴＤ［１］〜ＴＤ［４］の夫々とは、Ｂｌｕｅｔｏｏｔｈ（登録商標）などによる無線通信回線を介して双方向通信が可能である。端末装置ＴＤ［ｉ］に内蔵されたマイクロホンをマイクロホンＭＣ［ｉ］として用いる場合、マイクロホンＭＣ［ｉ］の出力音声信号を上記無線通信回線を介してアシスタント装置１（主制御部１０）に送信すれば良く、端末装置ＴＤ［ｉ］に内蔵されたスピーカをスピーカＳＰ［ｉ］として用いる場合、アシスタント装置１（主制御部１０）はスピーカＳＰ［ｉ］から出力されるべき音の音声信号を上記無線通信回線を介して端末装置ＴＤ［ｉ］に送信すれば良い。

車載センサ部２は、車両ＣＲに設置された複数の車載センサから成り、各車載センサを用いて車両情報を生成する。車両情報は所定周期で順次生成され、取得された車両情報は順次主制御部１０に送られる。車両情報は、車両ＣＲの速度を表す車速情報、車両ＣＲに設けられたアクセルペダルの踏み込み量を表すアクセル情報、車両ＣＲに設けられたブレーキペダルの踏み込み量を表すブレーキ情報、及び、車両ＣＲに設けられたステアリングホイールの操舵角を表す操舵角情報などを含む。

ＧＰＳ処理部３は、ＧＰＳ（Global Positioning System）を形成する複数のＧＰＳ衛星からの信号を受信することで車両ＣＲの位置（現在地）を検出し、検出位置を示す位置情報を生成する。車両ＣＲの位置とは車両ＣＲの存在位置を意味する。位置情報では、車両ＣＲの位置（現在地）が、地球上における経度及び緯度によって表現される。位置情報は所定周期で順次生成され、生成された位置情報は順次主制御部１０に送られる。

計時部４は、現在の日付及び時刻を示す時刻情報を生成して主制御部１０に送る。ＧＰＳ処理部３の受信信号を用いて時刻情報が生成又は修正されても良い。

主制御部１０は、エージェント処理部１１を備える他、アシスタント装置１の各部位の動作を統括的に制御する機能を備える。主制御部１０は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read only memory）及びＲＡＭ（Random access memory）等にて構成され、ＲＯＭに格納されたプログラムをＣＰＵが実行することで、エージェント処理部１１の機能が実現されて良い。

記憶部２０は、主制御部１０の制御の下で任意の情報及びデータの読み書きを行う。記憶部２０には、地図情報２１、個人識別用情報２２及び履歴情報２３が記憶される。地図情報２１は道路及び建造物等の位置を示す地図の情報である。個人識別用情報２２には、乗員が誰であるのかを特定するために有益な情報が格納されている。履歴情報２３には車両ＣＲの各乗員についての履歴情報が格納されている（詳細は後述）。

通信モジュール３０は、アシスタント装置１以外の装置（例えばインターネット網に接続されたサーバ装置）とアシスタント装置１との間で情報を送受信するための通信機能を備え、その情報の送受信は任意の無線通信回線を介して行われる。主制御部１０と端末装置ＴＤ［１］〜ＴＤ［４］との間の通信も、通信モジュール３０を介して実現されるものであっても良い。

インターフェース部４０は、アシスタント装置１と車両ＣＲの各乗員との間のマンマシンインターフェースであり、表示部４１及び操作部４２を備える。尚、アシスタント装置１と車両ＣＲの各乗員との間のマンマシンインターフェースの構成要素には、マイク部ＭＣ及びスピーカ部ＳＰも含まれる。表示部４１は液晶ディスプレイパネル等にて構成される表示装置であり、主制御部１０の制御の下で任意の画像を表示できる。操作部４２は操作者から任意の操作の入力を受け付ける。操作者は車両ＣＲの乗員（ドライバ又は同乗者）である。表示部４１及び操作部４２によりタッチパネルが構成されていても良く、操作部４２への操作はタッチパネルに対する操作であっても良い。

表示部４１は、座席ＳＴ［１］の前方に配置された単一の表示部であって良い。或いは、表示部４１は、図４に示す如く、乗員ＰＳ［１］及びＰＳ［２］から視認容易な位置に配置された表示部４１ａと、乗員ＰＳ［３］及びＰＳ［４］から視認容易な位置に配置された表示部４１ｂと、で構成されていても良い。更に或いは、表示部４１は、座席ごとに設置された計４つの表示部にて構成されていても良い。端末装置ＴＤ［ｉ］に内蔵された表示部を表示部４１として用いるようにしても良く、この場合、アシスタント装置１（主制御部１０）は表示部４１にて表示されるべき映像の映像信号を無線通信回線を介して端末装置ＴＤ［ｉ］に送信すれば良い。以下では、図４に示される表示部４１ａ及び４１ｂにて表示部４１が構成されるものとする。

アシスタント装置１は、エージェント処理部１１によるエージェント機能に加え、地図情報２１に基づき車両ＣＲの目的地までの経路を案内するナビゲーション機能、オーディオデータやビデオデータを再生する機能、テレビ放送波又はラジオ放送波を受信して受信放送波による映像又は音声を出力する機能など、各種の機能を備えていて良いが、以下では、エージェント機能に注目して、エージェント処理部１１の詳細を説明する。

エージェント処理部１１は、車両ＣＲの乗員とコミュニケーションをとったり、車両ＣＲ内の機器の操作等を自律的に行ったりするエージェント機能を実現する。エージェント処理部１１では人工知能を有する疑似人格であるソフトウェアエージェント（以下、エージェントと称する）が形成される。本実施形態において、エージェント処理部１１とエージェントは、同じものを指すと解して良く、エージェント処理部１１とエージェントとを互いに読み替え可能である。

エージェントと乗員との意思疎通は、エージェント及び乗員間の会話（音声のやり取り）を通じて実現される。つまり、エージェント処理部１１は（換言すればエージェントは）、マイク部ＭＣを用いて乗員の発話内容を受け取り、スピーカ部ＳＰを用いて乗員に対し通知すべき内容を音声にて出力する。エージェント処理部１１（換言すればエージェント）において、マイクロホンＭＣ［ｉ］の出力音声信号にて示される音声は乗員ＰＳ［ｉ］の発話による音声であると認識され、乗員ＰＳ［ｉ］に対して何らかの通知を行う際には、スピーカＳＰ［ｉ］を通じて乗員ＰＳ［ｉ］に当該通知を行う。

エージェント処理部１１は、エージェント機能を実現するための機能ブロックとして、音声認識部１２、乗員検出部１３、会話処理部１４及び音声出力部１５を備える。

音声認識部１２は、マイクロホンから出力される音声信号に基づき、乗員の発話内容を認識してテキストデータ（即ち文字列）に変換する。これは、マイクロホンごとに（換言すれば乗員ごとに）行われる。即ち、音声認識部１２は、マイクロホンＭＣ［ｉ］の出力音声信号に基づき乗員ＰＳ［ｉ］の発話内容を認識してテキストデータに変換する処理を、マイクロホンＭＣ［１］〜ＭＣ［４］の夫々に対して（換言すれば乗員ＰＳ［１］〜ＰＳ［４］の夫々に対して）行う。エージェントは、変換によって得られたテキストデータに基づき、乗員ＰＳ［１］〜ＰＳ［４］の発話内容を個別に認識する。

乗員検出部１３は、座席ＳＴ［１］〜ＳＴ［４］に乗員が座っているのか否か等を示す乗員管理情報を検出する。乗員管理情報は、座席に乗員が座っているのか否かを座席ごとに表す乗員存否情報を少なくとも含み、乗員ごとに乗員が誰であるのかを特定する個人特定情報を更に含みうる。

乗員管理情報の検出方法は任意である。例えば、エージェントが、乗員管理情報を得るための質問を車両ＣＲの何れかの乗員（例えばドライバ）に対して行い、その質問に対する回答内容から、乗員管理情報を検出しても良い。或いは例えば、車両ＣＲの何れかの乗員が操作部４２に対して乗員管理情報を入力することで、乗員検出部１３にて乗員管理情報が検出されても良い。

或いは例えば、乗員検出部１３は、車内カメラ画像の画像情報に基づき乗員存否情報を検出しても良く、更には、個人識別用情報２２と車内カメラ画像の画像情報に基づく個人識別処理により個人特定情報を検出しても良い。個人識別用情報２２は、上述したように、乗員が誰であるのかを特定するために有益な情報を含み、登録人物の顔の特徴データを含む。乗員検出部１３は、座席ＳＴ［ｉ］に座っている乗員ＰＳ［ｉ］の顔の画像情報をカメラ部ＣＭにおける車内カメラから取得し、取得した画像情報と登録人物の顔の特徴データとの照合により、乗員ＰＳ［ｉ］が登録人物と一致するか否かを判断できる。登録人物を複数設定しておけば、個人識別処理により、乗員ＰＳ［１］〜ＰＳ［４］が誰であるのかを夫々に特定することが可能である。

会話処理部１４は、各乗員とエージェントとの間において会話を成立させるための会話処理を行う。本実施形態における会話とは、特に記述なき限り、何れかの乗員とエージェントとの間の会話を指す。会話処理では、音声認識部１２を用いて各乗員の発話を受け取ると共に、各乗員の発話の内容に応じた通知又は各乗員の発話内容に依存しない通知を生成し、生成した通知の内容が音声として各乗員に出力されるよう音声出力部１５を制御する。乗員の発話から会話が始まることもあるし、エージェントの発話から会話が始まることもある。エージェントの発話とは、音声出力部１５を用いた音声出力を指す。会話処理部１４による通知は、乗員への提案でありうるし、単なる情報の通知でありうる。

音声出力部１５は、スピーカ部ＳＰを用い、各乗員に対して音声を出力する。より詳細には、音声出力部１５は、会話処理部１４の制御の下、会話処理部１４が生成した通知の内容が音声として各乗員に出力されるよう、スピーカ部ＳＰに当該通知の内容に応じた音声信号を出力する（音声出力部１５による、この音声信号の出力を、以下単に、音声出力と称する）。

会話処理部１４は、音声認識部１２及び音声出力部１５を用いて実現される乗員ＰＳ［ｉ］との会話の中で、乗員ＰＳ［ｉ］に対し各種の提案を行う提案機能を備える。提案を受けることとなる乗員ＰＳ［ｉ］を特に対象乗員と称する。提案機能に関し、会話処理部１４は、所定の提案トリガ条件の成立有無を判断し、提案トリガ条件が成立したときに対象乗員を設定して対象乗員に対する提案（提案事項）を発生させ、その提案への同意を対象乗員から得るための提案シーケンスを実行する。

提案トリガ条件は、様々な指標に基づいて成否が判定される。提案トリガ条件は、例えば、現在の日付及び時刻、乗員の連続乗車時間、カメラ部３１から得られる車内カメラ画像及び車外カメラ画像の画像情報、車載センサ部３２から得られる車両情報、ＧＰＳ処理部３３から得られる位置情報（即ち車両ＣＲの現在地）、地図情報２１、個人識別用情報２２、履歴情報２３又はネットワーク情報に基づいて、或いは、それらの組み合わせに基づいて、成否が判定される。ネットワーク情報とは、通信モジュール３０を用いてネットワーク上のサーバ装置等から得られる情報を指す。例えば、車両ＣＲの現在地における天候の情報及び渋滞情報、車両ＣＲの周辺の店舗情報が、ネットワーク情報に含まれうる。

提案シーケンスにおける提案の内容は、提案シーケンスの実行の契機となる提案トリガ条件の内容に依存する。

例えば、現在時刻が１２時になると提案トリガ条件が成立するようにしても良く、この場合における提案の内容は“昼食をとること”である。尚、本実施形態で記述される時刻は、２４時間表記における時刻であるとする。従って１２時と正午を意味する。
また例えば、会話処理部１４においてドライバ及び同乗者の連続乗車時間を計測し、連続乗車時間が所定時間（例えば２時間）に達すると提案トリガ条件が成立するようにしても良い。この場合における提案の内容は“休憩をとること”である。会話処理部１４は車両ＣＲのエンジンの駆動状態や車内カメラ画像の画像情報に基づき連続乗車時間を計測可能である。
或いは例えば、車両ＣＲの現在地と特定の場所（観光スポット等）との距離が所定距離以下となると提案トリガ条件が成立するようにしても良く、この場合における提案の内容は“特定の場所へ向かうこと”である。

会話処理部１４は、乗員ＰＳ［１］〜ＰＳ［４］の内、任意の乗員を対象乗員に設定することができるが、以下では、対象乗員がドライバ（即ちＰＳ［１］）であるものとする。

図５は提案シーケンスのフローチャートである。図５を参照して提案シーケンスの流れを説明する。ステップＳ１０において提案トリガ条件が成立することで、提案シーケンスが開始される。提案シーケンスはステップＳ１１〜Ｓ１９の処理から成る。提案シーケンスでは、後述されるよう、ステップＳ１５にて対象乗員（ここではドライバ）に対する提案が音声出力される。ステップＳ１５における、提案を音声出力することによる通知を、提案通知と称する。提案通知は、音声出力部１５を用いて実現される、エージェント（会話処理部１４）から対象乗員への提案の音声出力に相当する。

提案シーケンスでは、提案通知を行うに先立ち、ステップＳ１１にて提案前通知を行う。提案前通知では、エージェントからの提案前通知の内容が、音声出力部１５を用いて対象乗員に対し音声出力される。提案前通知は、提案に関連する通知（ステップＳ１５での提案の内容に基づいて生成される通知）であって且つ対象乗員からの同意を求める通知である。ここにおける同意は、提案前通知の内容に対する同意である。

提案前通知は、対象乗員からの同意が得られやすい通知（対象乗員が同意する可能性が高い通知）であると良い。従って例えば、提案前通知は事実に基づく通知であると良い。事実に基づく通知は、基本的に同意されるはずだからである。
即ち例えば、提案の内容が「昼食をとること」であって且つ提案前通知を行うときの時刻が１２時ちょうどである場合、提案に関連し且つ事実に基づき且つ対象乗員から同意を求める（同意が得やすい）通知として、「ドライバさん、１２時になりましたね」という文の提案前通知を行う。
また例えば、提案の内容が「昼食をとること」であって且つ車両ＣＲが現在位置している道路の右側に隣接して飲食店が並んでいる場合、提案に関連し且つ事実に基づき且つ対象乗員から同意を求める（同意が得やすい）通知として、「ドライバさん、右手に飲食店が並んでいますね」という文の提案前通知を行う。
また例えば、提案の内容が「休憩をとること」であって且つ提案前通知を行うときにおけるドライバの連続乗車時間（即ち、ドライバが連続して運転操作を継続している時間）が２時間に達している場合、提案に関連し且つ事実に基づき且つ対象乗員から同意を求める（同意が得やすい）通知として、「ドライバさん、走行してから２時間ぐらい経ちますね」という文の提案前通知を行う。

ステップＳ１１の提案前通知を行った後、ステップＳ１２において会話処理部１４は、提案前通知に対する対象乗員からの回答を受け付ける第１回答受付処理を行う。第１回答受付処理では、提案前通知による音声出力の終了から起算して所定の第１待機時間内に対象乗員からの回答を受け付け、第１待機時間内に対象乗員からの回答があると、又は、対象乗員からの回答がない状態で第１待機時間が経過すると、ステップＳ１３を経由して、ステップＳ１４に進む。提案前通知に対する対象乗員の回答は、対象乗員の発話によって行われ、対象乗員の発話内容が音声認識部１２で認識されることで対象乗員の回答が会話処理部１４及びエージェントに提供される（提案通知に対する対象乗員の回答についても同様）。

ステップＳ１４において、会話処理部１４は第１相槌処理を行う。第１相槌処理では、第１回答受付処理にて受けた対象乗員からの回答に対し、相槌を打つ文を音声出力部１５を用いて対象乗員に音声出力する。例えば、「ドライバさん、１２時になりましたね」、「ドライバさん、右手に飲食店が並んでいますね」又は「ドライバさん、走行してから２時間ぐらい経ちますね」という提案前通知に対し、対象乗員から「うん」や「そうだね」という回答があった場合、第１相槌処理において「そうですよねぇ」という相槌を打つ文を音声出力する。尚、「うん」や「そうだね」という回答は、提案前通知に対する同意を示している。

対象乗員からの回答がない状態で第１待機時間が経過したことによりステップＳ１４に至った場合においては、提案前通知での文に繋がるような文をステップＳ１４にて音声出力すると良い。例えば、「ドライバさん、１２時になりましたね」という提案前通知に対し、対象乗員からの回答がなかった場合、会話処理部１４はステップＳ１４にて「そろそろお腹すいてきたんじゃないですか」といった文や「お腹すいたなぁ」といった文をステップＳ１４にて音声出力すると良い。

ステップＳ１４の後、ステップＳ１５に進む。ステップＳ１５において、会話処理部１４は対象乗員に対して提案通知を行う。提案通知により、対象乗員に対し提案が音声出力される。提案の内容は例えば「昼食をとること」又は「休憩をとること」であり、提案通知により提案の内容に応じた文が対象乗員に対し音声出力される（具体例は後述）。

ステップＳ１５の提案通知を行った後、ステップＳ１６において会話処理部１４は、提案通知に対する対象乗員からの回答を受け付ける第２回答受付処理を行う。第２回答受付処理では、提案通知による音声出力の終了から起算して所定の第２待機時間内に対象乗員からの回答を受け付け、第２待機時間内に対象乗員からの回答があると、又は、対象乗員からの回答がない状態で第２待機時間が経過すると、ステップＳ１７を経由して、ステップＳ１８に進む。

ステップＳ１８において、会話処理部１４は第２相槌処理を行う。第２相槌処理では、第２回答受付処理にて受けた対象乗員からの回答に対し、相槌を打つ文を音声出力部１５を用いて対象乗員に音声出力する。対象乗員からの回答がない状態で第２待機時間が経過したことによりステップＳ１８に至った場合においては、提案通知での文に繋がるような文をステップＳ１８にて音声出力すると良い。

ステップＳ１８の後、ステップＳ１９に進んで提案後処理が実行される。提案後処理の内容は、提案通知の内容に依存し且つ提案通知に対する対象乗員からの回答の内容に依存するが、具体例については後述される。

人間は一度同意すると、次の提案に対しても同意しやすくなるという心理学上のテクニックがある。エージェント処理部１１では、このテクニックを利用し、実際の提案に先立ち、提案に関連する提案前通知を行い、この際、事実に基づく通知など、同意が得られやすい通知を提案前通知に設定する。これにより、エージェント処理部１１が発生した提案に対して対象乗員からの同意が得られやすくなる（提案に対して対象乗員から同意を得るという目的が達成されやすくなる）、と考えられる。

また、対象乗員の回答に対し相槌をうつ（即ち対象乗員の回答に対しエージェントが同意する）ことで、提案通知に対する対象乗員の受容度が高まると考えられる。

尚、提案前通知及び提案通知の各文に、対象乗員を名指しする用語を含めておくと良い。即ち例えば「ドライバさん、１２時になりましたね」という提案前通知の文であれば、「ドライバさん」は、対象乗員を名指しする用語である。乗員検出部１３においてドライバが誰であるかが特定されている場合にあっては、ドライバの名前やニックネームを、対象乗員を名指しする用語として提案前通知及び提案通知の各文に含めておいても良い。名指しにより、エージェントの発話に対する気付きの度合いが高まる。

また、同乗者がいる場合には、提案前通知及び提案通知による音声出力をドライバだけでなく同乗者にも出力するようにしても良く、名指しにより、ドライバへ注目が集まりやすくなる。運転タスクに意識を割く必要のあるドライバは、同乗者間の会話に入りづらいこともあり、孤立しやすい傾向にある。ドライバへ注目が集まりやすくすることで、ドライバの孤立感又は疎外感が軽減されると期待される。

以下、複数の実施例の中で、車載システムＳＹＳ又はアシスタント装置１の具体的な動作例、応用技術、変形技術等を説明する。本実施形態にて上述した事項は、特に記述無き限り且つ矛盾無き限り、以下の各実施例に適用され、各実施例において、上述した事項と矛盾する事項については各実施例での記載が優先されて良い。また矛盾無き限り、以下に示す複数の実施例の内、任意の実施例に記載した事項を、他の任意の実施例に適用することもできる（即ち複数の実施例の内の任意の２以上の実施例を組み合わせることも可能である）。

［第１実施例］
第１実施例を説明する。第１実施例及び後述の各実施例では、特に記述なき限り、図６に示す如く、ドライバである乗員ＰＳ［１］と、一人の同乗者である乗員ＰＳ［３］のみが、車両ＣＲに搭乗しているものとし、且つ、図４を参照して上述したように、乗員ＰＳ［１］が視認容易な表示部４１ａ及び乗員ＰＳ［３］が視認容易な表示部４１ｂが車室内に設けられているものとする。

第１実施例に係る会話処理部１４は、否定形の疑問文を用いて提案通知を行う。即ち、否定文の形態を有する疑問文にて提案通知を行う。否定形の疑問文は、会話処理部１４が発生した提案に対し、ドライバが拒否する意思を有しているかを問い合わせる第１質問文により構成される。第１実施例に係る提案通知は、第１質問文の音声出力に相当する。

例えば、提案の内容が“昼食をとること”である場合、“昼食をとりたくない”という意思を対象乗員が有しているか問い合わせる文（例えば「まだ昼食をとりたくないですよね」や「まだお昼ごはんは食べたくないですよね」という文）を、提案通知（第１質問文）に設定する。或いは例えば、提案の内容が“休憩をとること”である場合、“休憩をとりたくない”という意思を対象乗員が有しているか問い合わせる文（例えば「まだ休憩をとりたくないですよね」や「まだ休憩したくないですよね」という文）を、提案通知（第１質問文）に設定する。尚、第１実施例に係る提案通知は、第１質問文を含みつつ、更に別の文を含んでいても良い。

提案通知後におけるステップＳ１６の第２回答受付処理において、会話処理部１４は、提案通知による音声出力の終了から起算して所定の第２待機時間内に対象乗員からの回答を受け付ける。第２回答受付処理において、会話処理部１４は、第２待機時間内の対象乗員からの回答の有無及び回答の内容に基づき、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。

第２待機時間内に対象乗員からの回答があった場合には、その回答の内容により、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。提案通知に対し第２待機時間内に対象乗員からの回答が無いこと、即ち、提案通知の後、対象乗員からの回答がない状態で第２待機時間が経過することを、無回答と称する（後述の他の各実施例においても同様）。否定形の疑問文による提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案に同意したとみなす。ステップＳ１６の第２回答受付処理の後、図５のステップＳ１７を経てステップＳ１８及びＳ１９の各処理が実行される。尚、対象乗員からの回答がない状態とは、詳細には、対象乗員からの回答がないと会話処理部１４にて判断される状態を指す。実際は対象乗員が何らかの回答を行った場合でも、その回答の音声が小さすぎる又は不明瞭である等によって回答がないと判断される場合もある。故に、任意の提案通知に対し無回答であるとは、当該提案通知に対し対象乗員から回答が得られなかったと判断されることと同義である。

図７に、第１実施例に係るステップＳ１５以降の処理の具体例を示す。図７のステップＳ１５ａ〜Ｓ１７ａは、夫々、図５のステップＳ１５〜Ｓ１７の例である。図５のステップＳ１８における第２相槌処理は図７ではステップＳ１８ａ＿１又はＳ１８ａ＿２にて実現され、図５のステップＳ１９における提案後処理は図７ではステップＳ１９ａ＿１又はＳ１９ａ＿２にて実現される。

図７の具体例では、提案の内容が“昼食をとること”である。更に、時刻情報、車両ＣＲの位置情報、地図情報２１及びネットワーク情報に基づき、提案前通知を行うときの時刻が１２時ちょうどであって且つ車両ＣＲの現在地付近にレストランＲＲが存在していて且つレストランＲＲが現在営業中であることがエージェント処理部１１にて分かっているものとする。

この場合、ステップＳ１５に先立つステップＳ１１にて、「ドライバさん、１２時になりましたね」という文の提案前通知を対象乗員に対して行い、ステップＳ１２〜Ｓ１４の処理を経て、ステップＳ１５に進む（図５参照）。そして、図７に示す如く、ステップＳ１５ａにおいて、会話処理部１４は、エージェントからの提案通知（提案通知用のエージェントの発話）として、「ドライバさん、この先におすすめのレストランＲＲがあるのですが、まだお昼ごはんを食べたくないですよね」という否定形の疑問文を、対象乗員であるドライバに音声出力する。この音声出力は同乗者である乗員ＰＳ［３］にも聞こえるよう行われて良い。

ステップＳ１５ａの後、ステップＳ１６ａにおいて、会話処理部１４は上述の第２回答受付処理を行う。ステップＳ１６ａの第２回答受付処理では、提案通知による音声出力の終了から起算して所定の第２待機時間内に対象乗員からの回答を受け付ける。会話処理部１４は、第２待機時間内に対象乗員からの回答があった場合には、その回答の内容により、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。例えば、ステップＳ１５ａの提案通知に対して、対象乗員から「いや、お腹がすいた。そこで昼食をとろう」との発話があった場合には対象乗員が提案に同意したと判断し、「そうだな。まだ昼食はいいや」との発話があった場合には対象乗員が提案を拒否したと判断する。

否定形の疑問文による提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案に同意したとみなす。対象乗員が提案に同意したとみなされることは、対象乗員が提案に同意したと判断されることに属する。

対象乗員が提案に同意したとみなされる場合を含め、対象乗員が提案に同意していると判断された場合、ステップＳ１６ａからステップＳ１７ａを経由してステップＳ１８ａ＿１に進み、ステップＳ１８ａ＿１及びＳ１９ａ＿１の処理が実行される。ステップＳ１８ａ＿１において、会話処理部１４は、エージェントの相槌（相槌用のエージェントの発話）として、「じゃあ、私のおすすめするレストランＲＲでお昼を食べましょう」という文を、対象乗員であるドライバに音声出力する。

続くステップＳ１９ａ＿１において、会話処理部１４は、エージェントからの情報の通知（同乗者への情報展開）として、「ドライバさんは、この先のレストランＲＲでお昼を食べたいそうです。私もドライバさんの意見に賛成です。そこのハンバーグセットは絶品らしいですよ」という文を同乗者（ここでは乗員ＰＳ［３］）に音声出力すると共に、レストランＲＲに関する情報（食事のメニュー等）を表示部４１ｂに表示する。

対象乗員が提案を拒否していると判断された場合、ステップＳ１６ａからステップＳ１７ａを経由してステップＳ１８ａ＿２に進み、ステップＳ１８ａ＿２及びＳ１９ａ＿２の処理が実行される。ステップＳ１８ａ＿２において、会話処理部１４は、エージェントの相槌（相槌用のエージェントの発話）として、「そうですねぇ、じゃあ、お昼はもう少しあとにしましょう」という文を、対象乗員であるドライバに音声出力する。

続くステップＳ１９ａ＿２において、会話処理部１４は、エージェントからの情報の通知（同乗者への情報展開）として、「周辺のおすすめ情報を提示します」という文を同乗者（ここでは乗員ＰＳ［３］）に音声出力すると共に、レストランＲＲに関する情報（食事のメニュー等）を表示部４１ｂに表示する。

車両ＣＲの走行中に、システムＳＹＳからの提案を音声によって通知し、発話によって応答することは、画面注視やタッチパネル操作等が不要なことから、運転操作への負荷軽減及び安全性向上に寄与すると期待される。しかしながら、ドライバは運転操作に従事する必要があることから、与えられた情報を素早く理解したり、与えられた情報に対して素早く回答したりすることが難しいこともある。回答が遅れるとシステムによってはシステム提案から始まるシーケンスが終了してしまうこともあり、ドライバにとって提案サービスそのものが不要なものと感じられる惧れもある。これらを考慮し、第１実施例の提案シーケンスでは、否定形の疑問文で提案通知を行うようにし、無回答の場合には提案が同意されたとみなすようにする。否定形の疑問文に対する無回答は、提案を否定する意思が無いことに相当する、と推定されるからである。これにより、運転操作の従事により無回答にならざるを得なくなった場合でも、提案シーケンスが終了することなく完結され、またドライバの負担軽減にも繋がる（ドライバは回答に焦る必要がなくなる）。

また、ステップＳ１９ａ＿１における音声出力及び表示部４１ｂへの表示は、対象乗員に対して行った提案に関連する情報を対象乗員以外の乗員（ここでは乗員ＰＳ［３］）に通知する処理に相当する。

この処理により乗員全体の合意形成が促進されると期待される。上述の具体例であれば、ドライバのレストランＲＲに行きたいという意思を同乗者に伝えると共にレストランＲＲについての情報を同乗者に伝達することで、乗員全体の合意形成が促進されると期待される。

また、ステップＳ１９ａ＿１における音声出力及び表示部４１ｂへの表示において、提案通知に対する対象乗員からの回答に対しエージェントが同意する意見（「私もドライバさんの意見に賛成です」の音声出力等）を含めておくと良く、更に提案に関する追加的情報（「そこのハンバーグセットは絶品らしいですよ」の音声出力や表示部４１ｂでの表示）を含めておくと良い。これにより、同乗者の意見の同調が促され、乗員全体の合意形成が促進されると期待される。

ステップＳ１９ａ＿１と同様、ステップＳ１９ａ＿２における音声出力及び表示部４１ｂへの表示も、対象乗員に対して行った提案に関連する情報を対象乗員以外の乗員（ここでは乗員ＰＳ［３］）に通知する処理に相当する。

この処理により、エージェントの提案が最終的に受け入れられる可能性が生まれる。上述の具体例であれば、提案に関連する情報の通知を受けて、同乗者がレストランＲＲに興味を持ち、同乗者がドライバに働きかける可能性がある。そうすると、結果として、エージェントの提案が受け入れられる可能性がある（提案に対して対象乗員から同意を得るという目的が達成されやすくなる）。

尚、第１実施例では、同乗者として乗員ＰＳ［３］のみが存在する場合を想定したが、複数の同乗者が車両ＣＲに搭乗している場合の提案シーケンスの内容も、第１実施例で上述したものと同様である。また、同乗者が一人も存在していない場合にも第１実施例の動作は適用可能であり、この場合には、ステップＳ１９ａ＿１及びＳ１９ａ＿２の処理を非実行とすれば足る。

［第２実施例］
第２実施例を説明する。第２実施例に係る会話処理部１４は、肯定形の疑問文を用いて提案通知を行う。即ち、肯定文の形態を有する疑問文にて提案通知を行う。肯定形の疑問文は、会話処理部１４が発生した提案に対し、ドライバが同意する意思を有しているかを問い合わせる第２質問文により構成される。第２実施例に係る提案通知は、第２質問文の音声出力に相当する。

例えば、提案の内容が“昼食をとること”である場合、“昼食をとる”という意思を対象乗員が有しているか問い合わせる文（例えば「昼食をとりましょうか」や「お昼ごはんを食べませんか」という文）を、提案通知（第２質問文）に設定する。或いは例えば、提案の内容が“休憩をとること”である場合、“休憩をとる”という意思を対象乗員が有しているか問い合わせる文（例えば「休憩をとりましょうか」や「休憩をしませんか」という文）を、提案通知（第２質問文）に設定する。尚、第２実施例に係る提案通知は、第２質問文を含みつつ、更に別の文を含んでいても良い。

第２待機時間内に対象乗員からの回答があった場合には、その回答の内容により、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。肯定形の疑問文による提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案を拒否したとみなす。ステップＳ１６の第２回答受付処理の後、図５のステップＳ１７を経てステップＳ１８及びＳ１９の各処理が実行される。

図８に、第２実施例に係るステップＳ１５以降の処理の具体例を示す。図８のステップＳ１５ｂ〜Ｓ１７ｂは、夫々、図５のステップＳ１５〜Ｓ１７の例である。図５のステップＳ１８における第２相槌処理は図８ではステップＳ１８ｂ＿１又はＳ１８ｂ＿２にて実現され、図５のステップＳ１９における提案後処理は図８ではステップＳ１９ｂ＿１又はＳ１９ｂ＿２にて実現される。

図８の具体例では、提案の内容が“昼食をとること”である。更に、時刻情報、車両ＣＲの位置情報、地図情報２１及びネットワーク情報に基づき、提案前通知を行うときの時刻が１２時ちょうどであって且つ車両ＣＲの現在地付近にレストランＲＲが存在していて且つレストランＲＲが現在営業中であることがエージェント処理部１１にて分かっているものとする。

この場合、ステップＳ１５に先立つステップＳ１１にて、「ドライバさん、１２時になりましたね」という文の提案前通知を対象乗員に対して行い、ステップＳ１２〜Ｓ１４の処理を経て、ステップＳ１５に進む（図５参照）。そして、図８に示す如く、ステップＳ１５ｂにおいて、会話処理部１４は、エージェントからの提案通知（提案通知用のエージェントの発話）として、「ドライバさん、この先におすすめのレストランＲＲがあるのですが、そこで昼食をとりましょうか」という肯定形の疑問文を、対象乗員であるドライバに音声出力する。この音声出力は同乗者である乗員ＰＳ［３］にも聞こえるよう行われて良い。

ステップＳ１５ｂの後、ステップＳ１６ｂにおいて、会話処理部１４は上述の第２回答受付処理を行う。ステップＳ１６ｂの第２回答受付処理では、提案通知による音声出力の終了から起算して所定の第２待機時間内に対象乗員からの回答を受け付ける。会話処理部１４は、第２待機時間内に対象乗員からの回答があった場合には、その回答の内容により、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。例えば、ステップＳ１５ｂの提案通知に対して、対象乗員から「そうだね。そこで昼食をとろう」との発話があった場合には対象乗員が提案に同意したと判断し、「いや、昼食はまだでいいよ」との発話があった場合には対象乗員が提案を拒否したと判断する。

肯定形の疑問文による提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案を拒否したとみなす。対象乗員が提案を拒否したとみなされることは、対象乗員が提案を拒否したと判断されることに属する。

対象乗員が提案に同意していると判断された場合、ステップＳ１６ｂからステップＳ１７ｂを経由してステップＳ１８ｂ＿１に進み、ステップＳ１８ｂ＿１及びＳ１９ｂ＿１の処理が実行される。図８のステップＳ１８ｂ＿１及びＳ１９ｂ＿１の処理は、夫々、図７のステップＳ１８ａ＿１及びＳ１９ａ＿１の処理と同じであって良い。

対象乗員が提案を拒否したとみなされる場合を含め、対象乗員が提案を拒否していると判断された場合、ステップＳ１６ｂからステップＳ１７ｂを経由してステップＳ１８ｂ＿２に進み、ステップＳ１８ｂ＿２及びＳ１９ｂ＿２の処理が実行される。図８のステップＳ１８ｂ＿２及びＳ１９ｂ＿２の処理は、夫々、図７のステップＳ１８ａ＿２及びＳ１９ａ＿２の処理と同じであって良い。

車両ＣＲの走行中に、システムＳＹＳからの提案を音声によって通知し、発話によって応答することは、画面注視やタッチパネル操作等が不要なことから、運転操作への負荷軽減及び安全性向上に寄与すると期待される。しかしながら、ドライバは運転操作に従事する必要があることから、与えられた情報を素早く理解したり、与えられた情報に対して素早く回答したりすることが難しいこともある。回答が遅れるとシステムによってはシステム提案から始まるシーケンスが終了してしまうこともあり、ドライバにとって提案サービスそのものが不要なものと感じられる惧れもある。これらを考慮し、第２実施例の提案シーケンスでは、肯定形の疑問文で提案通知を行うようにし、無回答の場合には提案が拒否されたとみなすようにする。肯定形の疑問文に対する無回答は、提案を肯定する意思が無いことに相当する、と推定されるからである。これにより、運転操作の従事により無回答にならざるを得なくなった場合でも、提案シーケンスが終了することなく完結され、またドライバの負担軽減にも繋がる（ドライバは回答に焦る必要がなくなる）。

尚、第２実施例では、同乗者として乗員ＰＳ［３］のみが存在する場合を想定したが、複数の同乗者が車両ＣＲに搭乗している場合の提案シーケンスの内容も、第２実施例で上述したものと同様である。また、同乗者が一人も存在していない場合にも第２実施例の動作は適用可能であり、この場合には、ステップＳ１９ｂ＿１及びＳ１９ｂ＿２の処理を非実行とすれば足る。

［第３実施例］
第３実施例を説明する。第３実施例に係る会話処理部１４は、否定形の疑問文又は肯定形の疑問文を選択的に用いて提案通知を行う。

上述したように、否定形の疑問文は、会話処理部１４が発生した提案に対し、ドライバが拒否する意思を有しているかを問い合わせる第１質問文により構成される。否定形の疑問文による提案通知は第１質問文の音声出力に相当し、否定形の疑問文の意義及び具体例は第１実施例で示した通りである。否定形の疑問文による提案通知は、第１質問文を含みつつ、更に別の文を含んでいても良い。
上述したように、肯定形の疑問文は、会話処理部１４が発生した提案に対し、ドライバが同意する意思を有しているかを問い合わせる第２質問文により構成される。肯定形の疑問文による提案通知は第２質問文の音声出力に相当し、肯定形の疑問文の意義及び具体例は第２実施例で示した通りである。肯定形の疑問文による提案通知は、第２質問文を含みつつ、更に別の文を含んでいても良い。

第２待機時間内に対象乗員からの回答があった場合には、その回答の内容により、対象乗員が提案に同意したか或いは提案を拒否したかを判断する。
否定形の疑問文にて提案通知を行った場合において、提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案に同意したとみなす。
肯定形の疑問文にて提案通知を行った場合において、提案通知に対し無回答であった場合、会話処理部１４は、対象乗員が提案を拒否したとみなす。

これにより、第１実施例で実現される作用・効果と第２実施例で実現される作用・効果を奏することが可能となる。

ステップＳ１６の第２回答受付処理の後、図５のステップＳ１７を経てステップＳ１８及びＳ１９の各処理が実行される。否定形の疑問文にて提案通知を行う場合におけるステップＳ１５〜Ｓ１９の処理の具体例は、第１実施例（図７）で示した通りである。肯定形の疑問文にて提案通知を行う場合におけるステップＳ１５〜Ｓ１９の処理の具体例は、第２実施例（図８）で示した通りである。

会話処理部１４が行う提案は第１種類の提案と第２種類の提案に分類され、会話処理部１４は、実際に行う提案の種類に応じ、否定形の疑問文にて提案通知を行うのか或いは肯定形の疑問文にて提案通知を行うのかを切り替える。

これにより、提案の種類に適応した文にて提案通知を行うことができ、以って、提案への同意が得られやすくなることが期待される。

提案の種類の分類方法について説明する。図９に示す如く、会話処理部１４は、同意推定部１４ａ、提案種類分類部１４ｂ及び提案文作成部１４ｃを内包している、と考えることができる。同意推定部１４ａは、提案の内容と所定の推定用情報とに基づいて提案に対する対象乗員の同意しやすさ（対象乗員からの同意の得やすさ）を推定する。提案種類分類部１４ｂは、対象乗員の同意しやすさを２段階で量子化する。即ち、提案通知における提案に関し、対象乗員が当該提案に相対的に同意しやすいのか、同意しにくいのかを２段階で峻別する。提案種類分類部１４ｂは、提案に対し対象乗員が相対的に同意しやすいと推定されるときには当該提案を第１種類に分類し、提案に対し対象乗員が相対的に同意しにくいと推定されるときには当該提案を第２種類に分類する。
提案が第１種類に分類されると、提案文作成部１４ｃにより提案通知における疑問文の形が肯定形に設定されて（即ち提案通知における疑問文が肯定形の疑問文に設定されて）肯定形の疑問文が作成され、第２実施例に示した提案通知が行われる。
提案が第２種類に分類されると、提案文作成部１４ｃにより提案通知における疑問文の形が否定形に設定されて（即ち提案通知における疑問文が否定形の疑問文に設定されて）否定形の疑問文が作成され、第１実施例に示した提案通知が行われる。

対象乗員から同意が得られやすいと推定される提案は、ストレートに肯定形の疑問文（図８のステップＳ１５ｂ参照）で対象乗員に問い合わせを行った方が自然である。逆に、対象乗員から同意が得られにくいと推定される提案は、否定形の疑問文（図７のステップＳ１５ａ参照）で対象乗員に問い合わせを行うことも不自然ではなく、むしろ自然とも言える。第３実施例では、このような自然な疑問文を用いることで違和感の少ない提案通知を実現することができ、更に第１及び第２実施例で示した作用・効果を奏することもできる。

推定用情報は履歴情報２３（図３参照）を含んでいると良い。履歴情報２３を用いた推定方法を説明する。会話処理部１４は、提案シーケンスを行うたびに、提案通知における提案の内容、提案通知に対する対象乗員の回答結果及び提案通知を行ったときの状況（以下、提案時状況と称する）を、互いに関連付けた状態で履歴情報２３に格納する。提案時状況は、提案通知を行ったときの時刻、外気温、天候及び曜日や、提案通知を行ったときの車両ＣＲの位置（位置情報）及び乗員管理情報など、提案通知を行ったときの状況を表す様々な情報を含む。

過去に第１〜第（ｎ―１）回目の提案通知（換言すれば第１〜第（ｎ―１）回目の提案）が行われたとし、第ｎ回目の提案通知が行われるタイミングを、便宜上、特定タイミングと称する。ｎは２以上の任意の整数である。特定タイミングに至る前に、第１〜第（ｎ−１）回目の提案通知に対する対象乗員の回答結果が履歴情報２３に順次蓄積されてゆき、特定タイミングでは、第１〜第（ｎ−１）回目の提案通知の夫々に対する対象乗員の回答結果が履歴情報２３に保持されている。特定タイミングにおいて、同意推定部１４ａは、第ｎ回目の提案に対する対象乗員の同意のしやすさを履歴情報２３に基づいて推定することができる。

単純な具体例をあげる。第１〜第９回目の提案通知が行われた後、特定タイミングにて第１０回目の提案通知が行われることを考える。そして、第１〜第１０回目の提案通知における提案の内容は全て“昼食をとること”であることとし、提案時状況は第１〜第１０回目の提案通知間で互いに同じであるものとする。また、第１〜第１０回目の提案通知を受ける対象人物は共通して特定の登録人物であるとする。この想定の下、第１〜第９回目の提案通知に対する対象乗員の回答の内、過半数以上の回答が提案へ同意するものであったとき、第１０回目の提案通知における提案は対象乗員が同意しやすい提案であると推定されて第１種類に分類され、逆に、過半数以上の回答が提案を拒否するものであったとき、第１０回目の提案通知における提案は対象乗員が同意しにくい提案であると推定されて第２種類に分類される。

履歴情報２３を利用することで、上述の推定の精度が高まることが期待される。

実際には、様々な情報を用いて推定部１４ａによる推定処理及び分類部１４ｂによる分類処理が実行され、推定スコアの算出を通じて、これらの推定処理及び分類処理が行われると良い。即ち、推定部１４ａは、推定スコアを算出することで提案に対する対象乗員の同意しやすさを数値化して良く、この際、分類部１４ｂは、算出された推定スコアが所定の基準値以上であるときには当該提案を第１種類に分類し、そうでないときには当該提案を第２種類に分類すると良い（履歴情報２３を利用する場合においても同様）。

例えば、推定用情報は、乗員検出部１３から得られる乗員管理情報、カメラ部ＣＭから得られる画像情報（車内カメラ画像又は車外カメラ画像の画像情報）、車両センサ部２から得られる車両情報、ＧＰＳ処理部３から得られる位置情報、計時部４から得られる時刻情報、記憶部２０に記憶された情報（情報２１〜２３を含む）、通信モジュール３０を用いて得られるネットワーク情報、ドライバ及び同乗者の連続乗車時間の情報の内、全部又は一部を含んでいて良く、様々な情報を総合的に考慮して推定スコアを算出すると良い。

例えば、提案の内容が“昼食をとること”である場合、時刻情報にて示される現在時刻に基づいて推定スコアを増減させると良い。また例えば、提案の内容が“昼食をとること”又は“休憩をとること”である場合、連続乗車時間に基づいて推定スコアを増減させると良い。また例えば、提案の内容が“昼食をとること”である場合、ネットワーク情報から得られる車両ＣＲの現在位置周辺のレストラン情報と、対象乗員の食に関する嗜好とに基づいて、推定スコアを増減させてもと良い（対象乗員の食に関する嗜好は、記憶部２０に予め登録されているものとする）。

更に例えば、推定用情報は、対象乗員の感情の推定結果を示す感情情報を含んでいて良い。この場合、車内カメラ画像の画像情報や発汗計測センサ（不図示）及び心拍数センサ（不図示）等を用いて対象乗員の感情が推定され、対象乗員がいらいらしていると推定される場合には推定スコアを低下させ、対象乗員が落ち着いていると推定される場合には推定スコアを増加させる、といった方法が考えられる。

この他例えば、ナビゲーション機能にて車両ＣＲの目的地が設定されているか否か及び目的地はどこであるかも、推定用情報に含まれうる。例えば提案の内容が“休憩をとること”であるとき、車両ＣＲの目的地と車両ＣＲの現在位置との距離に基づいて、推定スコアを増減させると良い。

［第４実施例］
第４実施例を説明する。履歴情報２３は、提案シーケンスを開始させるか否かの判断（即ち提案トリガ条件の成否判断）及び提案する内容の決定にも、利用される。つまり、会話処理部１４は、履歴情報２３に基づいて対象乗員への提案を行っても良い。

上述の如く、提案シーケンスを行うたびに、提案通知における提案の内容、提案通知に対する対象乗員の回答結果及び提案時状況を、互いに関連付けた状態で履歴情報２３に格納及び蓄積してゆき、履歴情報２３に基づいて対象乗員への提案を行うようにすれば、受容度の高いサービス（同意されやすい提案）を提供可能なシステムを構築できると考えられる。

また、乗員の発話に対して相槌をうったり、乗員及びエージェント間の会話の中でどのような提案が受け入れられたかを学習したりすることで、ドライバや同乗者が受け入れやすい会話モデルを構築できると考えられる。

［第５実施例］
第５実施例を説明する。提案シーケンスにおいてエージェントからの提案が拒否された場合、提案があったことを対象乗員（ここではドライバ）又は他の乗員に知らせるための提案履歴通知画像を表示部４１ａ又は４１ｂに表示するようにしても良い。図１０の提案履歴アイコンＩＣＯＮ_１は提案履歴通知画像の例である。

即ち、図７の具体例であればステップＳ１８ａ＿２への移行後の任意のタイミングで、提案履歴アイコンＩＣＯＮ_１を表示部４１ａ又は４１ｂの所定位置に表示する。このとき、提案履歴アイコンＩＣＯＮ_１は、図７のステップＳ１５ａにおける提案通知の内容と対応付けられている。
その後、乗員ＰＳ［１］が表示部４１ａに表示された提案履歴アイコンＩＣＯＮ_１を指定する操作を入力すると、エージェント処理部１１は、提案履歴アイコンＩＣＯＮ_１に対応付けられた提案通知の内容を乗員ＰＳ［１］に対して通知する。この通知は、音声出力又は表示部４１ａでの表示により実現され、レストランＲＲに関する情報（食事のメニュー等）の通知を含んで良い。同様に、乗員ＰＳ［３］が表示部４１ｂに表示された提案履歴アイコンＩＣＯＮ_１を指定する操作を入力すると、エージェント処理部１１は、提案履歴アイコンＩＣＯＮ_１に対応付けられた提案通知の内容を乗員ＰＳ［３］に対して通知する。この通知は、音声出力又は表示部４１ｂでの表示により実現され、レストランＲＲに関する情報（食事のメニュー等）の通知を含んで良い。

同様に、図８の具体例であればステップＳ１８ｂ＿２への移行後の任意のタイミングで、提案履歴アイコンＩＣＯＮ_１を表示部４１ａ又は４１ｂの所定位置に表示すれば良く、この際の提案履歴アイコンＩＣＯＮ_１は、図８のステップＳ１５ｂにおける提案通知の内容と対応付けられる。提案履歴アイコンＩＣＯＮ_１を指定する操作が入力されたときのエージェント処理部１１の動作は、上述したものと同様である。

複数回の提案シーケンスの夫々においてエージェントからの提案が拒否された場合、提案が拒否された回数の情報を含んだ提案履歴通知画像を表示部４１ａ又は４１ｂに表示するようにしても良い。図１１の提案履歴アイコンＩＣＯＮ_２は、提案が拒否された回数の情報を含んだ提案履歴通知画像の例である。提案履歴アイコンＩＣＯＮ_２には、拒否された複数の提案通知の内容が対応付けられている。表示部４１ａ、４１ｂ表示された提案履歴アイコンＩＣＯＮ_２を指定する操作が入力されると、エージェント処理部１１は、提案履歴アイコンＩＣＯＮ_２に対応付けられた提案通知の内容を乗員ＰＳ［１］、乗員ＰＳ［３］に対して通知する。

提案履歴通知画像は、エージェントからの提案が拒否される状況が続いた場合に限り表示部４１ａ又は４１ｂに表示されるものであっても良い。

提案履歴通知画像の表示及び上述のエージェント処理部１１の動作により、乗員は過去の提案通知の内容を後から見返すことができる。

［第６実施例］
第６実施例を説明する。第６実施例では、ステップＳ１５にて対象乗員（ここではドライバ）に対し提案通知を行った後、ステップＳ１６の第２回答受付処理において、対象乗員が提案を拒否したと判断されたケース（以下、拒否ケースと称する）を想定する。また上述したように、ここでは、ドライバである乗員ＰＳ［１］と同乗者である乗員ＰＳ［３］が車両ＣＲに搭乗しているものとする（図６参照）。

拒否ケースでは、ステップＳ１９の提案後処理において、同乗者がステップＳ１５での提案に対して同意する発話を行うことがある。この際、会話処理部１４は、同乗者の発話を受け、再度同じ提案をドライバに行う再説得通知を行うようにいても良い。

例えば、図７のステップＳ１９ａ＿２又は図８のステップＳ１９ｂ＿２での音声出力及び表示部４１ｂでの表示を受け、同乗者が「このレストランＲＲでお昼ごはんを食べたい」と発話したとき、会話処理部１４は、同乗者がステップＳ１５での提案に対して同意する発話を行ったと判断する。そうすると、会話処理部１４は、エージェントからの再説得通知として、「ドライバさん、同乗者さんはレストランＲＲでお昼ごはんを食べたいそうですよ。私も食べたいです。やっぱり、レストランＲＲでお昼ごはんにしませんか」という文を、対象乗員であるドライバに音声出力する。この音声出力は同乗者である乗員ＰＳ［３］にも聞こえるよう行われて良い。再説得通知により、提案が最終的に受け入れられる可能性がある。

同乗者の意見に対しエージェントが同意する意見（「私も食べたいです」）を再説得通知に含めておいても良い。これにより、エージェントを人間であるとみなせば、提案に同意するものが二人且つ提案を拒否するものが一人となり、多数決判断で、提案へ同意するという合意形成が促進されやすくなる。

尚、ドライバに提案通知を行うエージェントと、同乗者と会話して再説得通知を行うエージェントが、互いに同じエージェントである場合、再説得通知の段階で、ドライバの意見に同調するものが存在しなくなり（ドライバを除けば、ドライバの意見の反対意見をもつものしか存在しなくなり）、ドライバが孤立することになる。これを避けるべく、ドライバに提案通知を行う第１エージェントと、同乗者と会話して再説得通知を行う第２エージェントを、互いに異なるエージェントとすると良い。これにより、ドライバの孤立化を抑制できる。

但し、ドライバが孤立することになるが、再説得通知の段階で、第１エージェントと第２エージェントの双方が同乗者の意見に同調する意見を発話し、提案を受け入れるようドライバを説得することも可能である。第１及び第２エージェントが互いに異なるエージェントであることが各乗員に理解されやすいよう、第１エージェントの発話における声色（音の高さ等）と第２エージェントの発話における声色を互いに異ならせておくと良い。

［第７実施例］
第７実施例を説明する。車両ＣＲの運転における安全性等を高める用途にも本発明は適用可能である。例えば、事故多発地点に車両ＣＲが近づいているとき、会話処理部１４は、運転に注意すべきことをドライバに提案（通知）することができるが、この際、提案前通知を行ってから、運転に注意すべきことをドライバに提案すると良い。

即ち例えば、会話処理部１４は、エージェントからの提案前通知として、「ドライバさん、事故は起こしたくないですよね」という文をドライバに音声出力する（ステップＳ１１）。この提案前通知を受け、ドライバが「うん」と発話すると、会話処理部１４は、エージェントの相槌として「そうですよね」という文をドライバに音声出力する（ステップＳ１４）。その後、会話処理部１４は、エージェントからの提案通知として、「次のカーブの先は、事故多発時点なので気をつけてくださいね」という文をドライバに音声出力する（ステップＳ１５）。提案通知だけを行う場合と比べ、提案前通知、ドライバ回答及びエージェント相槌を経てから提案通知を行った方が、ドライバが提案内容を受け入れやすくなると考えられる。

［第８実施例］
第８実施例を説明する。

対象乗員がドライバである場合、同乗者への通知を含むステップＳ１９の提案後処理（図５参照）を削除することも可能である。そして、この場合、マイク部ＭＣからマイクロホンＭＣ［２］〜ＭＣ［４］を削除することが可能であると共にスピーカ部ＳＰからスピーカＳＰ［２］〜ＳＰ［４］を削除することが可能である。

乗員ごと（換言すれば座席ごと）のマイクロホンがマイク部ＭＣに設けられていることを想定したが、マイク部ＭＣにおいて、複数の乗員（換言すれば複数の座席）に対し共通のマイクロホンが割り当てられるようにしても良い。最も単純には、マイク部ＭＣにおいて乗員ＰＳ［１］〜ＰＳ［４］に対して共通の単一のマイクロホンを設けておき、単一のマイクロホンにて乗員ＰＳ［１］〜ＰＳ［４］の発話内容の収音を行うようにしても良い。同様に、スピーカ部ＳＰにおいて、複数の乗員（換言すれば複数の座席）に対し共通のスピーカが割り当てられるようにしても良い。最も単純には、スピーカ部ＳＰにおいて乗員ＰＳ［１］〜ＰＳ［４］に対して共通の単一のスピーカを設けておき、単一のスピーカから乗員ＰＳ［１］〜ＰＳ［４］の何れかに通知されるべき音声を出力するようにしても良い。

上述の各実施例では、提案通知を受ける対象乗員がドライバに設定されているが、対象乗員はドライバ以外の任意の同乗者であっても良い。

図１の車載システムＳＹＳの構成要素の一部又は全部によって、本発明に係る車載装置が構成される。例えば、本発明に係る車載装置はアシスタント装置１そのものに相当する、と考えることができる。或いは例えば、本発明に係る車載装置は、アシスタント装置１を構成要素として含みつつ、更に、マイク部ＭＣ、スピーカ部ＳＰ、車載センサ部２、ＧＰＳ処理部３及び計時部４の内の、任意の何れか１以上を構成要素として更に含むと考えても良い。

システムＳＹＳ及びシステムＳＹＳにて具体化された本発明を、車載用途とは異なる任意の用途に適用することも可能である。

本発明の実施形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。以上の実施形態は、あくまでも、本発明の実施形態の例であって、本発明ないし各構成要件の用語の意義は、以上の実施形態に記載されたものに制限されるものではない。上述の説明文中に示した具体的な数値は、単なる例示であって、当然の如く、それらを様々な数値に変更することができる。

１アシスタント装置
２車載センサ部
３ＧＰＳ処理部
４計時部
１０主制御部
１１エージェント処理部
１２音声認識部
１３乗員検出部
１４会話処理部
１５音声出力部
２０記憶部
３０通信モジュール
４０インターフェース部
ＣＲ車両
ＳＹＳ車載システム
ＣＭカメラ部
ＭＣマイク部
ＳＰスピーカ部
ＭＣ［１］〜ＭＣ［４］マイクロホン
ＳＰ［１］〜ＳＰ［４］スピーカ
ＰＳ［１］〜ＰＳ［４］乗員
ＳＴ［１］〜ＳＴ［４］座席

Claims

車両に搭載される車載装置において、
乗員の発話の内容を認識する音声認識部と、
前記乗員に対して音声を出力する音声出力部と、
前記音声認識部及び前記音声出力部を用いて前記乗員と会話を行い、前記会話の中で提案通知により前記乗員に対して提案を行う会話処理部と、を備え、
前記会話処理部は、前記提案を行う際、前記提案に関連し且つ前記乗員の同意を求める提案前通知を前記乗員に対して行い、その後に前記提案通知を行う
ことを特徴とする車載装置。
前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、
前記会話処理部は、否定形の疑問文を用いて前記提案通知を行い、前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案に対して同意したとみなす
ことを特徴とする請求項１に記載の車載装置。
前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、
前記会話処理部は、肯定形の疑問文を用いて前記提案通知を行い、前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案を拒否したとみなす
ことを特徴とする請求項１に記載の車載装置。
前記会話処理部は、前記提案通知の後、前記提案通知に対する前記乗員の回答を受け付けて前記乗員が前記提案に同意したか或いは前記提案を拒否したかを判断する回答受付処理を行い、
前記会話処理部は、否定形の疑問文又は肯定形の疑問文を用いて前記提案通知を行い、
前記否定形の疑問文を用いて前記提案通知を行った場合における前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案に対して同意したとみなし、
前記肯定形の疑問文を用いて前記提案通知を行った場合における前記回答受付処理にて前記乗員からの回答を得られなかったと判断したとき、前記乗員が前記提案を拒否したとみなす
ことを特徴とする請求項１に記載の車載装置。
前記会話処理部は、前記提案として第１種類の提案又は第２種類の提案を行うことが可能であり、前記提案の種類に応じ、前記提案通知における疑問文を否定形にするか肯定形にするかを切り替える
ことを特徴とする請求項４に記載の車載装置。
前記会話処理部は、前記提案の内容と推定用情報に基づき前記提案に対する前記乗員の同意しやすさを推定する同意推定部を有し、前記提案に対し前記乗員が相対的に同意しやすいと推定されるとき前記提案を前記第１種類に分類して前記提案通知における疑問文の形を肯定形に設定し、前記提案に対し前記乗員が相対的に同意しにくいと推定されるとき前記提案を前記第２種類に分類して前記提案通知における疑問文の形を否定形に設定する
ことを特徴とする請求項５に記載の車載装置。
前記推定用情報は履歴情報を含み、
前記履歴情報は、過去に前記乗員に対して行った提案通知の夫々に対する前記乗員の回答結果を含む
ことを特徴とする請求項６に記載の車載装置。
前記会話処理部は、前記車両に前記乗員と他の乗員が搭乗している場合、前記回答受付処理の後、前記提案に関連する情報を前記他の乗員に通知する
ことを特徴とする請求項２〜７の何れかに記載の車載装置。
前記提案前通知は、事実に基づいた通知を含む
ことを特徴とする請求項１〜８の何れかに記載の車載装置。
前記乗員は、前記車両のドライバである
ことを特徴とする請求項１〜９の何れかに記載の車載装置。
車両に搭載される車載装置にて用いられる提案出力方法において、
乗員の発話の内容を認識する音声認識ステップと、
前記乗員に対して音声を出力する音声出力ステップと、
前記音声認識ステップ及び前記音声出力ステップを通じて前記乗員と会話を行い、前記会話の中で提案通知により前記乗員に対して提案を行う会話処理ステップと、を備え、
前記会話処理ステップは、前記提案を行う際、前記提案に関連し且つ前記乗員の同意を求める提案前通知を前記乗員に対して行い、その後に前記提案通知を行う
ことを特徴とする提案出力方法。