(57)【要約】【課題】操作を提案するための提案条件を自動的に構築する。【解決手段】操作提案装置（１００）は、車両（１）に搭載され、複数の提案条件のうち一の提案条件が満たされた場合に、該一の提案条件に対応する操作を提案する。当該操作提案装置は、ドライバ状態を取得するドライバ状態取得部（１１）と、車両状態を取得する車両状態取得部（１２）と、ドライバにより一の操作が行われた際に、該一の操作、該一の操作が行われた際のドライバ状態、及び該一の操作が行われた際の車両状態により示される条件に該当する提案条件が、複数の提案条件に含まれていない場合、該条件を新たな提案条件として加える提案条件追加部（１５）と、を備える。【選択図】図１
2018149861.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載され、複数の提案条件のうち一の提案条件が満たされた場合に、前記一の提案条件に対応する操作を提案する操作提案装置であって、
前記車両のドライバの状態であるドライバ状態を取得するドライバ状態取得部と、
前記車両の状態である車両状態を取得する車両状態取得部と、
前記ドライバにより一の操作が行われた際に、前記一の操作、前記一の操作が行われた際のドライバ状態、及び前記一の操作が行われた際の車両状態により示される条件に該当する提案条件が、前記複数の提案条件に含まれていない場合、前記条件を新たな提案条件として加える提案条件追加部と、
を備えることを特徴とする操作提案装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された機器の操作を提案する操作提案装置の技術分野に関する。
【背景技術】
【０００２】
この種の装置として、例えば、外部状態項目（天気、外気温、外気の湿度、渋滞、交通規制等）及び車両内状態項目（窓の開閉状態、エアコンのＯＮ／ＯＦＦ状態、その他各種スイッチのＯＮ／ＯＦＦ状態等）の今後の状態を予測して、ドライバに提案すべき一次操作を決定するとともに、該決定された一次操作が行われた後の状態を予測して、ドライバに提案すべき二次操作を決定し、決定された一次操作及び二次操作を示すメッセージを出力する装置が提案されている（特許文献１参照）。
【０００３】
尚、ユーザの自動車の利用を補助する又はユーザを楽しませるためのもてなし動作をシーン毎に行う装置であって、もてなし動作が行われたときに、不足又は不満を感じたユーザにより手動操作された機能を随伴もてなし機能として抽出して分析することによって、次回以降の同じシーンにおける随伴もてなし機能の動作自動化のための学習を行う装置が提案されている（特許文献２参照）。
【０００４】
また、前照灯のロービームとハイビームとを自動的に切り替える装置であって、ユーザにより手動でロービームとハイビームとが切り替えられた場合に、手動で切り替えられた時の走行状態に基づいて、ロービームとハイビームとを自動的に切り替えるための閾値の学習を行う装置が提案されている（特許文献３参照）。また、車両の内外で予め定めたトリガ事象が検出された場合に、情報提示のタイミングを決定して、情報を車両の乗員に提示する装置が提案されている（特許文献４参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−１６０５２２号公報
【特許文献２】特開２００９−１２６３３５号公報
【特許文献３】特開２００７−３０８０１２号公報
【特許文献４】特開２０１６−００８９１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の技術では、ドライバに提案すべき操作を提案するために、外部状態項目及び内部状態項目の組合せから成る提案ルールを事前に定義する必要がある。更に、車両の状態やドライバの状態に相応しい操作を提案するためには、膨大な提案ルールを事前に定義する必要がある。しかしながら、あらゆる状態を想定して予め提案ルールを定義することは極めて困難である。
【０００７】
本発明は、上記問題点に鑑みてなされたものであり、操作を提案するための提案ルールを自動的に構築することができる操作提案装置を提供することを課題とする。
【課題を解決するための手段】
【０００８】
本発明の操作提案装置は、上記課題を解決するために、車両に搭載され、複数の提案条件のうち一の提案条件が満たされた場合に、前記一の提案条件に対応する操作を提案する操作提案装置であって、前記車両のドライバの状態であるドライバ状態を取得するドライバ状態取得部と、前記車両の状態である車両状態を取得する車両状態取得部と、前記ドライバにより一の操作が行われた際に、前記一の操作、前記一の操作が行われた際のドライバ状態、及び前記一の操作が行われた際の車両状態により示される条件に該当する提案条件が、前記複数の提案条件に含まれていない場合、前記条件を新たな提案条件として加える提案条件追加部と、を備える。
【０００９】
当該操作提案装置によれば、提案条件（上述の提案ルールに相当）を自動的に構築することができる。尚、「車両状態」は、例えば直進走行、右左折等の車両自身の状態に限らず、例えば周辺車両や障害物の有無、走行している道路の種別等の車両の走行環境の状態も含む概念である。
【００１０】
本発明の作用及び他の利得は次に説明する実施するための形態から明らかにされる。
【図面の簡単な説明】
【００１１】
【図１】実施形態に係る操作提案装置の構成を示すブロック図である。
【図２】実施形態に係るルールベースデータベースの構成を示す概念図である。
【図３】実施形態に係るルール生成処理を示すフローチャートである。
【図４】実施形態に係る操作提案処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
本発明の操作提案装置に係る実施形態について、図１乃至図４を参照して説明する。
【００１３】
（構成）
実施形態に係る操作提案装置の構成について、図１及び図２を参照して説明する。図１は、実施形態に係る操作提案装置の構成を示すブロック図である。図２は、実施形態に係るルールベースデータベースの構成を示す概念図である。
【００１４】
図１において、操作提案装置１００は、車両１に搭載されている。操作提案装置１００は、ドライバ状態推定部１１、周辺／車両状態推定部１２、操作監視部１３、レコメンド機能部１４、ルール生成部１５及びルールベースデータベース（以降、適宜“ルールベース”と称する）１６を備えて構成されている。
【００１５】
ドライバ状態推定部１１は、例えば車内カメラ等であるドライバモニタ２１、マイク２２、及び、例えば温度センサ、脈拍センサ等を含むその他センサ２３各々の出力結果に基づいて、車両１のドライバのドライバ状態を推定する。具体的には、ドライバ状態推定部１１は、ドライバ状態として、例えばドライバの感情や覚醒度、寒暖等の内部状態と、例えばドライバの顔向き、ジェスチャー及び音声等の外部状態とを推定する。
【００１６】
内部状態の一例としての、ドライバの感情や覚醒度の推定方法には、既存の技術を適用可能であるので、その詳細についての説明は省略する。内部状態の一例としての、寒暖は、例えば温度センサにより検出された車内温度、湿度センサにより検出された車内湿度、日差しの有無等に基づいて推定すればよい。外部状態の一例としての、ドライバの顔向き、ジェスチャー及び音声の推定方法には、既存の技術を適用可能であるので、その詳細についての説明は省略する。
【００１７】
周辺／車両状態推定部１２は、周辺監視カメラ２４、ミリ波レーダ２５、ＬＩＤＡＲ（Ｌｉｇｈｔ  Ｄｅｔｅｃｔｉｏｎ  ａｎｄ  Ｒａｎｇｉｎｇ）２６及び車両ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）２７各々の出力結果に基づいて、車両１の車両状態及び車両１の周辺の周辺状態を推定する。
【００１８】
具体的には、周辺／車両状態推定部１２は、車両状態として、例えば直進走行、左折、右折、停止、停車等の走行状態と、例えば一般道、高速道路等の車両１が走行している道路の種別を示す位置情報とを推定（又は取得）する。尚、走行状態及び位置情報の推定又は取得方法には、既存の技術を適用可能であるので、その詳細についての説明は省略する。
【００１９】
周辺／車両状態推定部１２は、周辺状態として、例えば車両１の周辺の他車両、歩行者及び障害物等の有無及び多寡を推定（又は検出）する。車両１の周辺の他車両等の推定又は検出方法には、既存の技術を適用可能であるので、その詳細についての説明は省略する。
【００２０】
操作監視部１３は、例えばエアコンのスイッチ、ヘッドライトのスイッチ等のスイッチ類３１のＯＮ／ＯＦＦ状態、ナビゲーション装置３２の操作情報、その他ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）３３の出力結果を監視することにより、ドライバによる操作を監視する。
【００２１】
尚、ドライバモニタ２１、マイク２２、その他センサ２３、周辺監視カメラ２４、ミリ波レーダ２５及びＬＩＤＡＲ２６は、車両１に搭載された他の装置又はシステムと共用されてよい。
【００２２】
レコメンド機能部１４は、ドライバ状態推定部１１により推定されたドライバ状態、並びに、周辺／車両状態推定部１２により推定された周辺状態及び車両状態と、ルールベース１６に予め格納されている、本発明に係る「提案条件」の一例としての、提案ルールとに基づいて、推奨する操作をドライバに提案する。推奨する操作の提案は、例えばディスプレイ（図示せず）上に推奨する操作を示す画像や文字を表示することにより、或いは、音声により行われる。
【００２３】
ルール生成部１５は、ドライバ状態推定部１１により推定されたドライバ状態、周辺／車両状態推定部１２により推定された車両状態及び周辺状態、並びに、操作監視部１３による監視結果に基づいて、提案ルールを生成する。
【００２４】
ルールベース１６は、複数の提案ルールを格納する。ここで、ルールベース１６について、図２を参照して説明を加える。
【００２５】
図２に示すように、ルールベース１６では、ドライバ状態、車両状態及び周辺状態各々について、スイッチ類３１、ナビゲーション装置３２及びその他ＥＣＵ３３のいずれかの状態に変化があったときの変化前の状態（図２の“前状態”）と変化後の状態（図２の“現状態”）とが互いに対応付けられた上で、一つの状態（又は状態変化）情報として記録されている。ルールベース１６では、このような状態情報が互いに紐付けられることにより、一つの提案ルールが形成（記述）されている。図２の矢印は、「紐付け（リンク）」を示している。
【００２６】
具体的には例えば、ドライバ状態の「前状態１→現状態１」という状態情報と、車両状態の「前状態１→現状態１」という状態情報と、周辺状態の「前状態１→現状態１」という状態情報との組み合わせにより、操作Ａについての提案ルールが形成されている。或いは、ドライバ状態の「前状態２→現状態２」という状態情報と、車両状態の「前状態３→現状態３」という状態情報と、周辺状態の「前状態４→現状態４」という状態情報との組み合わせにより、操作Ｃについての提案ルールが形成されている。
【００２７】
（ルール生成処理）
次に、ルール生成部１５が実施するルール生成処理について、図３のフローチャートを参照して説明する。ルール生成処理は、ルール生成部１５が、ドライバ状態推定部１１により推定されたドライバ状態、周辺／車両状態推定部１２により推定された車両状態及び周辺状態、並びに、操作監視部１３による監視結果に基づいて、提案ルールを生成し、該生成された提案ルールをルールベース１６に追加する（即ち、ルールベース１６を更新する）処理である。
【００２８】
図３において、ルール生成部１５は、操作監視部１３による監視結果に基づいて、ドライバによる（新たな）操作があるか否かを判定する（ステップＳ１０１）。この判定において、ドライバによる操作がないと判定された場合（ステップＳ１０１：Ｎｏ）、図３に示す処理は終了される。その後、ルール生成部１５は、第１所定期間（例えば、数ミリ秒から数十ミリ秒）が経過した後に再度図３に示す処理を開始する。つまり、図３に示す処理は、第１所定期間に応じた周期で繰り返し行われる。
【００２９】
他方、ステップＳ１０１の判定において、ドライバによる操作があると判定された場合（ステップＳ１０１：Ｙｅｓ）、ルール生成部１５は、操作監視部１３による監視結果から操作内容を取得する（ステップＳ１０２）。ルール生成部１５は、ドライバにより操作が行われた時点の前後の、ドライバ状態推定部１１により推定されたドライバ状態を取得する（ステップＳ１０３）。ルール生成部１５は、ドライバにより操作が行われた時点の前後の、周辺／車両状態推定部１２により推定された周辺状態を取得する（ステップＳ１０４）。ルール生成部１５は、ドライバにより操作が行われた時点の前後の、周辺／車両状態推定部１２により推定された車両状態を取得する（ステップＳ１０５）。尚、ステップＳ１０２〜Ｓ１０５の処理は、並行して又は相前後して行われてよい。
【００３０】
次に、ルール生成部１５は、上記ステップＳ１０２〜Ｓ１０５の処理において取得された、操作内容、ドライバ状態、周辺状態及び車両状態を紐付ける（ステップＳ１０６）。次に、ルール生成部１５は、ルールベース１６に、今回取得されたドライバ状態と同じ状態を示す状態を示す状態情報が存在するか否かを判定する（ステップＳ１０７）。この判定において、今回取得されたドライバ状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ１０７：Ｙｅｓ）、後述するステップＳ１０９の処理が行われる。
【００３１】
他方、ステップＳ１０７の判定において、今回取得されたドライバ状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ１０７：Ｎｏ）、ルール生成部１５は、ルールベース１６に、今回取得されたドライバ状態を、ドライバ状態についての新たな状態情報として登録する（ステップＳ１０８）。
【００３２】
次に、ルール生成部１５は、ルールベース１６に、今回取得された車両状態と同じ状態を示す状態情報が存在するか否かを判定する（ステップＳ１０９）。この判定において、今回取得された車両状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ１０９：Ｙｅｓ）、後述するステップＳ１１１の処理が行われる。
【００３３】
他方、ステップＳ１０９の判定において、今回取得された車両状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ１０９：Ｎｏ）、ルール生成部１５は、ルールベース１６に、今回取得された車両状態を、車両状態についての新たな状態情報として登録すると共に、対応するドライバ状態についての状態情報と（可能であれば、周辺状態についての状態情報とも）紐付ける（ステップＳ１０９）。
【００３４】
次に、ルール生成部１５は、ルールベース１６に、今回取得された周辺状態と同じ状態を示す状態情報が存在するか否かを判定する（ステップＳ１１１）。この判定において、今回取得された周辺状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ１１１：Ｙｅｓ）、後述するステップＳ１１３の処理が行われる。
【００３５】
他方、ステップＳ１１１の判定において、今回取得された周辺状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ１１１：Ｎｏ）、ルール生成部１５は、ルールベース１６に、今回取得された周辺状態を、周辺状態についての新たな状態情報として登録すると共に、対応する車両状態についての状態情報と（可能であれば、操作とも）紐付ける（ステップＳ１１２）。
【００３６】
次に、ルール生成部１５は、ルールベース１６に、今回取得された操作内容と同じ操作が存在するか否かを判定する（ステップＳ１１３）。この判定において、同じ操作が存在すると判定された場合（ステップＳ１１３：Ｙｅｓ）、図３に示す処理は終了される。その後、ルール生成部１５は、第１所定期間が経過した後に再度図３に示す処理を開始する。
【００３７】
他方、ステップＳ１１３の判定において、同じ操作は存在しないと判定された場合（ステップＳ１１３：Ｎｏ）、ルール生成部１５は、ルールベース１６に、今回取得された操作内容を、新たな操作として登録すると共に、対応する周辺状態についての状態情報と紐付ける（ステップＳ１１４）。その後、ルール生成部１５は、第１所定期間が経過した後に再度図３に示す処理を開始する。
【００３８】
（操作提案処理）
次に、レコメンド機能部１４が実施する操作提案処理について、図４のフローチャートを参照して説明する。操作提案処理は、レコメンド機能部１４が、ドライバ状態推定部１１により推定されたドライバ状態、並びに、周辺／車両状態推定部１２により推定された周辺状態及び車両状態と、ルールベース１６に格納されている提案ルールとに基づいて、推奨する操作をドライバに提案する処理である。
【００３９】
図４において、レコメンド機能部１４は、ドライバ状態推定部１１により推定されたドライバ状態、並びに、周辺／車両状態推定部１２により推定された周辺状態及び車両状態を取得する（ステップＳ２０１）。ステップＳ２０１の処理では、現時点の状態（即ち、ドライバ状態、周辺状態及び車両状態）と、現時点から第１所定時間だけ前の時点の状態とが取得される。次に、レコメンド機能部１４は、取得されたドライバ状態と同じ状態を示す状態情報がルールベース１６に存在するか否かを判定する（ステップＳ２０２）。
【００４０】
ステップＳ２０２の判定において、取得されたドライバ状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ２０２：Ｙｅｓ）、後述するステップＳ２０４の処理が行われる。他方、ステップＳ２０２の判定において、取得されたドライバ状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ２０２：Ｎｏ）、レコメンド機能部１４は、取得されたドライバ状態のうち、現時点のドライバ状態と同じ状態を含む状態情報がルールベース１６に存在するか否かを判定する（ステップＳ２０３）。
【００４１】
ステップＳ２０３の判定において、現時点のドライバ状態と同じ状態を含む状態情報は存在しないと判定された場合（ステップＳ２０３：Ｎｏ）、図４に示す処理は終了される。その後、レコメンド機能部１４は、第２所定期間（例えば、数ミリ秒から数十ミリ秒）が経過した後に再度図４に示す処理を開始する。つまり、図４に示す処理は、第３所定期間に応じた周期で繰り返し行われる。
【００４２】
他方、ステップＳ２０３の判定において、現時点のドライバ状態と同じ状態を含む状態情報が存在すると判定された場合（ステップＳ２０３：Ｙｅｓ）、レコメンド機能部１４は、取得された車両状態と同じ状態を示す状態情報が、取得されたドライバ状態と同じ状態を示す状態情報、又は、該取得されたドライバ状態のうち現時点のドライバ状態と同じ状態を含む状態情報が紐付けられた車両状態についての一又は複数の状態情報に存在するか否かを判定する（ステップＳ２０４）。
【００４３】
ステップＳ２０４の判定において、取得された車両状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ２０４：Ｙｅｓ）、後述するステップＳ２０６の処理が行われる。他方、ステップＳ２０４の判定において、取得された車両状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ２０４：Ｎｏ）、レコメンド機能部１４は、取得された車両状態のうち、現時点の車両状態と同じ状態を含む状態情報が、取得されたドライバ状態と同じ状態を示す状態情報、又は、該取得されたドライバ状態のうち現時点のドライバ状態と同じ状態を含む状態情報が紐付けられた車両状態についての一又は複数の状態情報に存在するか否かを判定する（ステップＳ２０５）。
【００４４】
ステップＳ２０５の判定において、現時点の車両状態と同じ状態を含む状態情報は存在しないと判定された場合（ステップＳ２０５：Ｎｏ）、図４に示す処理は終了される。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。
【００４５】
他方、ステップＳ２０５の判定において、現時点の車両状態と同じ状態を含む状態情報が存在すると判定された場合（ステップＳ２０５：Ｙｅｓ）、レコメンド機能部１４は、取得された周辺状態と同じ状態を示す状態情報が、取得された車両状態と同じ状態を示す状態情報、又は、該取得された車両状態のうち現時点の車両状態と同じ状態を含む状態情報が紐付けられた周辺状態についての一又は複数の状態情報に存在するか否かを判定する（ステップＳ２０６）。
【００４６】
ステップＳ２０６の判定において、取得された周辺状態と同じ状態を示す状態情報が存在すると判定された場合（ステップＳ２０６）、後述するステップＳ２０８の処理が行われる。他方、ステップＳ２０６の判定において、取得された周辺状態と同じ状態を示す状態情報は存在しないと判定された場合（ステップＳ２０６：Ｎｏ）、レコメンド機能部１４は、取得された周辺状態のうち、現時点の周辺状態と同じ状態を含む状態情報が、取得された車両状態と同じ状態を示す状態情報、又は、該取得された車両状態のうち現時点の車両状態と同じ状態を含む状態情報が紐付けられた周辺状態についての一又は複数の状態情報に存在するか否かを判定する（ステップＳ２０７）。
【００４７】
ステップＳ２０７の判定において、現時点の周辺状態と同じ状態を含む状態情報は存在しないと判定された場合（ステップＳ２０７：Ｎｏ）、図４に示す処理は終了される。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。
【００４８】
他方、ステップＳ２０７の判定において、現時点の周辺状態と同じ状態を含む状態情報が存在すると判定された場合（ステップＳ２０７：Ｙｅｓ）、レコメンド機能部１４は、取得された周辺状態と同じ状態を示す状態情報、又は、該取得された周辺状態のうち現時点の周辺状態と同じ状態を含む状態情報が紐付けられた操作を、推奨する操作として提案する（ステップＳ２０８）。
【００４９】
次に、レコメンド機能部１４は、ステップＳ２０８の処理において提案された操作がドライバに受け入れられたか否かを判定する（ステップＳ２０９）。レコメンド機能部１４は、提案された操作がドライバにより行われた場合に、受け入れられたと判定する。他方、レコメンド機能部１４は、ステップＳ２０８の処理が行われた後、第２所定時間経過しても提案された操作が行われない場合、受け入れられないと判定する。
【００５０】
ステップＳ２０９の判定において、ドライバに受け入れられたと判定された場合（ステップＳ２０９：Ｙｅｓ）、レコメンド機能部１４は、今回、ステップＳ２０８の処理において推奨する操作が提案されるまでに、ステップＳ２０３、Ｓ２０５及びＳ２０７のいずれかの処理が行われたか否かを判定する（ステップＳ２１０）。この判定おいて、ステップＳ２０３、Ｓ２０５及びＳ２０７の処理のいずれも行われていないと判定された場合（ステップＳ２１０：Ｎｏ）、図４に示す処理は終了される。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。
【００５１】
他方、ステップＳ２１０の判定において、ステップＳ２０３、Ｓ２０５及びＳ２０７のいずれかの処理が行われたと判定された場合（ステップＳ２１０：Ｙｅｓ）、レコメンド機能部１４は、今回取得されたドライバ状態、周辺状態及び車両状態、並びに、今回ドライバに受け入れられた操作に基づいて新しい提案ルールを生成し、ルールベース１６に追加する（ステップＳ２１１）。なぜなら、完全に一致する提案ルールが、ルールベース１６に含まれていなかったからである。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。
【００５２】
ステップＳ２０９の判定において、ドライバに受け入れられないと判定された場合（ステップＳ２０９：Ｎｏ）、レコメンド機能部１４は、今回の推奨する操作の提案の根拠となった提案ルールに係る拒否カウンタをカウントアップする（ステップＳ２１２）。次に、レコメンド機能部１４は、拒否カウンタの値が所定値以上であるか否かを判定する（ステップＳ２１３）。
【００５３】
ステップＳ２１３の判定において、拒否カウンタの値が所定値未満であると判定された場合（ステップＳ２１３：Ｎｏ）、図４に示す処理は終了される。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。他方、ステップＳ２１３の判定において、拒否カウンタの値が所定値以上であると判定された場合（ステップＳ２１３：Ｙｅｓ）、レコメンド機能部１４は、ルールベース１６から、今回の推奨する操作の提案の根拠となった提案ルールを削除する（ステップＳ２１４）。なぜなら、ドライバに拒否された回数が所定値以上であり、不適切な提案ルールであるとみなせるからである。その後、レコメンド機能部１４は、第２所定期間が経過した後に再度図４に示す処理を開始する。
【００５４】
（技術的効果）
実施形態に係る操作提案装置１００によれば、図３のフローチャートを参照して説明したように、ドライバに推奨する操作を提案するための提案ルールを自動的に構築することができる。加えて、当該操作提案装置１００によれば、図４のフローチャートを参照して説明したように、不適切な提案ルールを自動的に削除することができる。
【００５５】
実施形態に係る「ドライバ状態推定部１１」、「周辺／車両状態推定部１２」及び「ルール生成部１５」は、夫々、本発明に係る「ドライバ状態取得部」、「車両状態取得部」及び「提案条件追加部」の一例である。
【００５６】
本発明は、上述した実施形態に限られるものではなく、特許請求の範囲及び明細書全体から読み取れる発明の要旨或いは思想に反しない範囲で適宜変更可能であり、そのような変更を伴う操作提案装置もまた本発明の技術的範囲に含まれるものである。
【符号の説明】
【００５７】
１…車両、１１…ドライバ状態推定部、１２…周辺／車両状態推定部、１３…操作監視部、１４…レコメンド機能部、１５…ルール生成部、１６…ルールベースデータベース、１００…操作提案装置
【図１】
2018149861.tif 000003
【図２】
2018149861.tif 000004
【図３】
2018149861.tif 000005
【図４】
2018149861.tif 000006