特許 7588011 車両異常通知装置及び車両異常通知方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-13

(45)【発行日】2024-11-21

(54)【発明の名称】車両異常通知装置及び車両異常通知方法

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20241114BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 9

(21)【出願番号】P 2021042216

(22)【出願日】2021-03-16

(65)【公開番号】P2022142167

(43)【公開日】2022-09-30

【審査請求日】2023-11-07

(73)【特許権者】

【識別番号】000003997

【氏名又は名称】日産自動車株式会社

(73)【特許権者】

【識別番号】507308902

【氏名又は名称】ルノー エス．ア．エス．

【氏名又は名称原語表記】ＲＥＮＡＵＬＴ Ｓ．Ａ．Ｓ．

【住所又は居所原語表記】１２２－１２２ ｂｉｓ， ａｖｅｎｕｅ ｄｕ Ｇｅｎｅｒａｌ Ｌｅｃｌｅｒｃ， ９２１００ Ｂｏｕｌｏｇｎｅ－Ｂｉｌｌａｎｃｏｕｒｔ， Ｆｒａｎｃｅ

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100101247

【弁理士】

【氏名又は名称】高橋 俊一

(74)【代理人】

【識別番号】100095500

【弁理士】

【氏名又は名称】伊藤 正和

(74)【代理人】

【識別番号】100098327

【弁理士】

【氏名又は名称】高松 俊雄

(72)【発明者】

【氏名】田中 康裕

【審査官】池田 聡史

(56)【参考文献】

【文献】国際公開第２０１９／１８０４７４（ＷＯ，Ａ１）

【文献】特開平１０－２６００５０（ＪＰ，Ａ）

【文献】特開平０７－０７２２４６（ＪＰ，Ａ）

【文献】特開２００４－２６８６３３（ＪＰ，Ａ）

【文献】特開２００８－２２２１６７（ＪＰ，Ａ）

【文献】特開２０１２－０６９０３７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１２／０１３０８４４（ＵＳ，Ａ１）

【文献】米国特許第０５９３１８７８（ＵＳ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

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

【請求項1】

車両に対する所定の行動に関する第１通知が行われてからユーザが前記行動を行うまでの行動履歴を記憶する記憶装置と、
コントローラとを備え、
前記コントローラは、
前記車両の異常を検出し、
前記記憶装置に記憶された前記行動履歴を参照し、前記第１通知から前記行動を行うまでの時間または走行距離に応じて、前記ユーザに対して前記車両の前記異常に関する、前記第１通知とは異なる第２通知を送信するタイミングを決定し、
決定された前記タイミングにて、前記ユーザに対して前記第２通知を行う
ことを特徴とする車両異常通知装置。

【請求項2】

前記コントローラは、
前記第１通知から前記行動を行うまでの時間または走行距離が短いユーザほど、前記第２通知を行うタイミングを遅くする
ことを特徴とする請求項１に記載の車両異常通知装置。

【請求項3】

前記コントローラは、
前記異常が検出された場合、前記車両の修理が必要となるまでの残り走行可能距離を決定し、
前記残り走行可能距離と、前記第１通知から前記行動を行うまでの時間または走行距離に応じて、前記第２通知を送信するタイミングを決定し、
前記ユーザに対して前記第２通知を行う際に前記残り走行可能距離を表示させる
ことを特徴とする請求項１または２に記載の車両異常通知装置。

【請求項4】

前記所定の行動は、前記車両を所定の場所にて修理の依頼、予約もしくは実施を行うことと定義され、
前記行動履歴には修理履歴が含まれる
ことを特徴とする請求項１～３のいずれか１項に記載の車両異常通知装置。

【請求項5】

前記行動履歴には、ユーザが給油する際の燃料の残量を示す給油履歴が含まれる
ことを特徴とする請求項１～４のいずれか１項に記載の車両異常通知装置。

【請求項6】

前記コントローラは、
前記車両を所有するユーザを特定し、
特定されたユーザに対して前記第２通知を行う
ことを特徴とする請求項１～５のいずれか１項に記載の車両異常通知装置。

【請求項7】

前記コントローラは、
前記特定されたユーザの行動履歴を参照し、前記第２通知を送信するタイミングを決定する
ことを特徴とする請求項６に記載の車両異常通知装置。

【請求項8】

前記コントローラは、
前記記憶装置に記憶された、ユーザの運転特性を示す運転特性履歴を参照してユーザを特定する
ことを特徴とする請求項１～７のいずれか１項に記載の車両異常通知装置。

【請求項9】

車両に対する所定の行動に関する第１通知が行われてからユーザが前記行動を行うまでの行動履歴を記憶する記憶装置と、コントローラとを備える車両異常通知装置の車両異常通知方法であって
前記コントローラが、前記車両の異常を判定し、
前記コントローラが、前記記憶装置に記憶された前記行動履歴を参照し、前記第１通知から前記行動を行うまでの時間または走行距離に応じて、前記ユーザに対して前記車両の前記異常に関する、前記第１通知とは異なる第２通知を送信するタイミングを決定し、
前記コントローラが、決定された前記タイミングにて、前記ユーザに対して前記第２通知を行う
ことを特徴とする車両異常通知方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両異常通知装置及び車両異常通知方法に関する。

【背景技術】

【0002】

従来より、顧客に対して故障前に注意を促す発明が知られている（特許文献１）。特許文献１に記載された発明は故障予測対象車両からの車両データと他の車両からの車両データとを比較し、比較結果に基づいて故障の発生を予測する。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００４－２６８６３３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１に記載された発明のように故障が予測された時点でユーザに通知すると、行動が早いユーザはすぐに車両を修理するため、部品の利用率が低くなってしまい、ユーザの負担が増えるおそれがある。

【0005】

本発明は、上記問題に鑑みて成されたものであり、その目的は、部品の利用率を高めユーザの負担を軽減することが可能な車両異常通知装置及び車両異常通知方法を提供することである。

【課題を解決するための手段】

【0006】

本発明の一態様に係る車両異常通知装置は、車両の異常を検出し、記憶装置に記憶された行動履歴を参照し、第１通知から行動を行うまでの時間または走行距離に応じて、ユーザに対して車両の異常に関する、第１通知とは異なる第２通知を送信するタイミングを決定し、決定されたタイミングにて、ユーザに対して第２通知を行う。

【発明の効果】

【0007】

本発明によれば、部品の利用率を高めユーザの負担を軽減することが可能となる。

【図面の簡単な説明】

【0008】

【図1】図１は、本発明の第１実施形態に係る車両異常通知システム１０の概略構成図である。

【図2】図２は、データベース２８に格納された行動履歴を説明する図である。

【図3】図３は、通知タイミングの一例を説明する図である。

【図4】図４は、本発明の第１実施形態に係る車両異常通知装置２０の一動作例を説明するフローチャートである。

【図5】図５は、本発明の第２実施形態に係る車両異常通知システム１０の概略構成図である。

【図6】図６は、データベース２８に格納された給油履歴を説明する図である。

【図7】図７は、本発明の第２実施形態に係る車両異常通知装置２０の一動作例を説明するフローチャートである。

【発明を実施するための形態】

【0009】

以下、本発明の実施形態について、図面を参照して説明する。図面の記載において同一部分には同一符号を付して説明を省略する。

【0010】

（第１実施形態）
図１を参照して、第１実施形態に係る車両異常通知システム１０の構成例を説明する。図１に示すように、車両異常通知システム１０は、車両異常通知装置２０と、通信ネットワーク３０と、車両４０と、を含む。

【0011】

車両異常通知装置２０は、通信ネットワーク３０を介して車両４０と通信する。車両異常通知装置２０は、通信Ｉ／Ｆ２１と、コントローラ２２と、記憶装置２７とを備える。車両異常通知装置２０の設置場所は特に限定されないが、例えば車両異常通知装置２０は車両４０を管理するための管理センタに設置される。

【0012】

通信Ｉ／Ｆ２１は、ネットワークアダプタなどのハードウェア、各種の通信用ソフトウェア、及びこれらの組み合わせとして実装され、通信ネットワーク３０を介した有線または無線の通信を実現できるように構成されている。また、通信Ｉ／Ｆ２１はデータを送受信するための入力部及び出力部としての機能を有する。

【0013】

通信ネットワーク３０は、無線または有線の何れかの方式、あるいは両方の方式によって構成されてもよく、通信ネットワーク３０には、インターネットが含まれてもよい。本実施形態では、車両異常通知装置２０と車両４０は、無線通信方式によって通信ネットワーク３０と接続する。

【0014】

コントローラ２２は、ＣＰＵ（中央処理装置）、メモリ、及び入出力部を備える汎用のマイクロコンピュータである。マイクロコンピュータには、車両異常通知装置２０として機能させるためのコンピュータプログラムがインストールされている。コンピュータプログラムを実行することにより、マイクロコンピュータは車両異常通知装置２０が備える複数の情報処理回路として機能する。なおここでは、ソフトウェアによって車両異常通知装置２０が備える複数の情報処理回路を実現する例を示すが、もちろん以下に示す各情報処理を実行するための専用のハードウェアを用意して情報処理回路を構成することも可能である。また複数の情報処理回路を個別のハードウェアにより構成してもよい。コントローラ２２は、複数の情報処理回路の一例として、送信制御部２３と、異常判定部２４と、通知決定部２５と、メッセージ選定部２６とを備える。

【0015】

記憶装置２７は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの記憶媒体である。記憶装置２７にはデータベース２８が格納されている。データベース２８には車両に対する所定の行動に関する通知が行われてからユーザが行動を行うまでの行動履歴が車両ごとに記憶されている。車両に対する所定の行動に関する通知とは、「○○に異常が検出されました。点検してください」というアラート通知である。この場合、所定の行動とは車両を所定の場所にて修理の依頼、予約もしくは実施を行うことを意味する。つまりデータベース２８には過去においてアラート通知が行われてから、ユーザがいつ修理したかという行動履歴（修理履歴）が記憶されている。これにより法定点検、車検のタイミングで修理しているユーザかどうかを判別することができる。行動履歴にはアラート通知履歴も含まれる。またデータベース２８には車両ごとのアラートの通知方法が記憶されている。車両は複数のユーザによって利用される場合がある。車両とユーザとを紐付けた状態で上記の履歴、情報が記憶されてもよい。

【0016】

送信制御部２３は、通知決定部２５によって決定されたタイミングで車両４０にメッセージを送信する。

【0017】

異常判定部２４は、車両４０から受信したデータに基づいて異常が発生しているか否かを判定する。

【0018】

通知決定部２５は、車両４０に対して異常が発生している旨の通知を行うタイミングを決定する。このタイミングを以下では単に通知タイミングと呼ぶ場合がある。

【0019】

メッセージ選定部２６は、車両４０に対して異常が発生している旨の通知を行う際の、メッセージを選定する。このメッセージはディスプレイ４２、あるいはユーザが所持する携帯端末（例えばスマートフォン）に表示される。

【0020】

車両４０は通信Ｉ／Ｆ４１と、ディスプレイ４２と、ＥＣＵ４３（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）とを備える。通信Ｉ／Ｆ４１の機能は通信Ｉ／Ｆ２１と同じため説明を省略する。ディスプレイ４２には車両異常通知装置２０から送信されたメッセージが表示される。ＥＣＵ４３も異常判定部２４と同様に車両４０に異常が発生しているか否かを判定する。ＥＣＵ４３及び異常判定部２４は異常種別もしくは異常の緊急度合に応じて異常判定を分担している。なおＥＣＵ４３に異常判定機能を持たせることは必須ではない。車両４０は自動運転機能を有する車両でもよく、自動運転機能を有しない車両でもよい。また、車両４０は自動運転と手動運転とを切り替えることが可能な車両でもよい。

【0021】

次に図２を参照して、データベース２８に記憶されている「車両に対する所定の行動に関する通知が行われてからユーザが行動を行うまでの行動履歴」の一例を説明する。

【0022】

車両ＸのユーザはＸ１である。車両ＹのユーザはＹ１である。図２に示す「内容」とは、過去において車両異常通知装置２０から車両Ｘ及び車両Ｙに対して通知されたメッセージの内容である。メッセージの具体的な内容は「スターターに異常が発生しました。点検してください」というものである。このようなメッセージはディスプレイ４２に表示される。

【0023】

図２に示すように、車両Ｘに対して最初に通知が行われた日時は２０１９年１月１日１４時１分３０秒である。このような通知は異常が解消されるまで所定の周期で繰り返し行われる。図２に示す「最新の通知日時」とは最後に通知が行われた日時を示す。ユーザＸ１の場合、「最初の通知日時」と「最新の通知日時」が同じため、通知回数は１回となる。ユーザＸ１は２０１９年１月３日１８時２１分３０秒に修理している。つまり、ユーザＸ１は最初の通知を受けてから２日後に修理していることになる。最初の通知を受けてから車両Ｘが走行した距離は２０ｋｍである。

【0024】

図２に示すように、車両Ｙに対して最初に通知が行われた日時は２０１９年１月１日１４時２分３０秒である。最新の通知日時は２０１９年１月２１日１６時２分３０秒である。図２では省略されているが最初の通知と最新の通知との間でさらに１回通知が行われているため、通知回数は３回となる。ユーザＹ１は２０１９年１月２２日１０時１２分３０秒に修理している。つまり、ユーザＹ１は最初の通知を受けてから２１日後に修理していることになる。最初の通知を受けてから車両Ｙが走行した距離は１９５ｋｍである。

【0025】

図２から分かるように、ユーザのタイプとして早めに修理したいユーザ（ユーザＸ１）と、なるべく修理を遅らせたいユーザ（ユーザＹ１）に分類できる。言い換えると、仮に図２に示すスターター異常の修理費用をユーザが負担すると想定した場合、基本的にはまだ十分に使えるものを修理するといったことはしないという前提のもと、ユーザのタイプとして、大きく故障する可能性があるのであれば早めに修理して安心したいユーザ（ユーザＸ１）と、故障する寸前まで部品を使い切りたいユーザ（ユーザＹ１）の２つに分類できる。もちろん分類は２つに限定されないが、ここでは２つとして説明する。

【0026】

ここで最初の通知が行われてから、実際にスターターが故障するまでの走行距離が２００ｋｍであったと仮定する。この場合ユーザＸ１は最初の通知から２０ｋｍ走行した時点で修理しているためスターターの利用率が低いといえる。その結果、長期的な視点にたてば、ユーザＸ１の負担（修理費用負担、買い替え費用負担など）が増加するといえる。したがって、スターターの利用率を高めユーザＸ１の負担を軽減するためには、ユーザＸ１に対しては最初の通知を遅らせることが考えられる。なお異常判定部２４は異常を検出した場合、検出された異常に対応する、車両の修理が必要となるまでの残り走行可能距離を決定することができる。上記の２００ｋｍが残り走行可能距離に相当する。検出された異常に対応する残り走行可能距離は実験、シミュレーションを通じて予め設定されている。

【0027】

一方で、ユーザＹ１は最初の通知から１９５ｋｍ走行した時点で修理しているためスターターの利用率は高いといえる。ただし、故障するリスクがあるため、ユーザＹ１に対しては早めに通知する、もしくは通知メッセージを変更することで故障リスクを緩和することが考えられる。

【0028】

そこで本実施形態に係る車両異常通知装置２０は、ユーザのタイプに応じて通知タイミングを変更する、もしくは通知メッセージを変更する。具体例を図３を参照して説明する。なお「ユーザのタイプ」は行動履歴を参照することにより分類可能である。

【0029】

図３に示すように、早めに修理するユーザＸ１に対しては、最初の通知は故障するまでの走行距離が残り１００ｋｍになったときに通知する。図２に示す例では最初の通知は故障するまでの走行距離が残り２００ｋｍになったときに通知していたため、図２と比較して通知タイミングを遅らせている。その後ユーザＸ１が修理しないまま故障するまでの走行距離が残り５０ｋｍになった場合は、２回目の通知が行われる。もちろんユーザＸ１が故障するまでの走行距離が残り５０ｋｍになる前に修理した場合、２回目の通知は行われない。

【0030】

故障する寸前まで部品を使い切りたいユーザＹ１に対しては、最初の通知は余裕を持たせつつ具体的な内容で行う。例えば図３に示すように「スターターがあとおよそ２００ｋｍで故障します」と通知する。このメッセージは図２で説明した「スターターに異常が発生しました。点検してください」と比較して具体性を有しているため、ユーザＹ１に対して早めの修理を促すことが可能となる。その後ユーザＹ１が修理しないまま故障するまでの走行距離が残り１００ｋｍになった場合は、２回目の通知が行われる。もちろんユーザＹ１が故障するまでの走行距離が残り１００ｋｍになる前に修理した場合、２回目の通知は行われない。なお１回目の通知のタイミングは例えば異常が検出されたタイミングと同時である。通常、異常が検出されてから通知までに多少の遅れが発生することが考えられるが、同時にすることにより早めの通知が実現する。

【0031】

図３に示すようにユーザのタイプに応じて通知タイミングを変更する、もしくは通知メッセージを変更することにより、部品の利用率を高めユーザの負担を軽減すること、故障リスクを緩和することが可能となる。

【0032】

なおユーザのタイプを最初の通知が行われてから修理までに走行した距離に応じて分類したが、分類方法はこれに限定されない。最初の通知が行われてから修理までの時間に応じてユーザのタイプを分類してもよい。修理までの時間が短いほど、早めに修理したいタイプとなる。一方修理までの時間が長いほど、故障する寸前まで部品を使い切りたいタイプとなる。修理までの時間の長短の一例として図２に示すように、最初の通知が行われてから修理までの時間が２日であれば短いと判断され、２１日であれば長いと判断される。ただし、この時間は異常の種類に応じて適宜変更されうる。

【0033】

次に、図４のフローチャートを参照して、第１実施形態に係る車両異常通知装置２０の一動作例を説明する。

【0034】

ステップＳ１０１において、コントローラ２２はデータベース２８を参照して、車両に対する所定の行動に関する通知が行われてからユーザが行動を行うまでの行動履歴を収集する。処理はステップＳ１０３に進みコントローラ２２は収集した行動履歴に基づいてユーザを分類し、通知メッセージなどのデータと紐付けて教師データを作成する。処理はステップＳ１０５に進みコントローラ２２は勾配ブースティングを用いて車両及びユーザを所定のパターンに分類する学習モデルを作成する。このようなモデル作成処理は機械学習による分類精度を向上させるためであるが、必ずしも必須ではない。

【0035】

処理はステップＳ１０７に進み、異常判定部２４は、車両４０から受信したデータに基づいて異常が発生しているか否かを判定する。検出された異常において緊急性が高い場合（ステップＳ１０９でＹＥＳ）、処理はステップＳ１２１に進み、送信制御部２３は通知を行う。緊急性が高い異常とはただちに走行安全性に影響を及ぼすものを指す。例えばステアリングホイールが固まった、ブレーキペダルが固まったなどである。緊急性が高い異常が検出された場合の通知メッセージは、例えば「緊急停止してください」である。

【0036】

検出された異常において緊急性が低い場合（ステップＳ１０９でＮＯ）、処理はステップＳ１１１に進み、通知決定部２５はデータベース２８を参照する。緊急性が低い異常とは例えば図２～３で説明したスターターの異常である。本実施形態では緊急性が低い異常に対して通知タイミングを変更したり、通知メッセージを変更したりする。過去の行動履歴において、今回異常が検出された車両のユーザが最初の通知から５０ｋｍ走行するまでに修理している場合（ステップＳ１１３でＹＥＳ）、処理はステップＳ１１７に進む。過去の行動履歴において、最初の通知から５０ｋｍ走行するまでに修理しているユーザとは図２で説明したユーザＸ１である。ユーザＸ１は最初の通知から２０ｋｍ走行した時点で修理している。ユーザＸ１は早めに修理するタイプであるから、通知タイミングを遅らせる（ステップＳ１１７）。つまりこのフローチャートでは最初の通知から５０ｋｍ走行するまでに修理しているユーザを早めに修理するタイプに分類し、最初の通知から５０ｋｍ走行するまでに修理していないユーザを故障する寸前まで部品を使い切りたいタイプに分類している。

【0037】

過去の行動履歴において、今回異常が検出された車両のユーザが最初の通知から５０ｋｍ走行するまでに修理していない場合（ステップＳ１１３でＮＯ）、処理はステップＳ１１５に進む。最初の通知から５０ｋｍ走行するまでに修理していないユーザとは図２で説明したユーザＹ１である。ユーザＹ１は故障する寸前まで部品を使い切りたいタイプであるため、通知決定部２５は早めに通知することを決定する。例えば１回目の通知のタイミングは異常が検出されたタイミングと同時である。

【0038】

ステップＳ１１９において、メッセージ選定部２６は通知タイミングに応じて通知メッセージを選定する。通知タイミングを遅らせる場合、通知メッセージは図３に示すように「スターターがもうすぐ故障します」となる。早めに通知する場合、通知メッセージは図３に示すように「スターターがあとおよそ２００ｋｍで故障します」となる。

【0039】

ステップＳ１２１において、送信制御部２３はステップＳ１１５もしくはステップＳ１１７で決定されたタイミングで、ステップＳ１１９で選定されたメッセージを車両に送信する。ディスプレイ４２にはこのメッセージが表示される。

【0040】

（作用効果）
以上説明したように、第１実施形態に係る車両異常通知装置２０によれば、以下の作用効果が得られる。

【0041】

車両異常通知装置２０は車両に対する所定の行動に関する第１通知が行われてからユーザが行動を行うまでの行動履歴を記憶する記憶装置２７と、コントローラ２２とを備える。コントローラ２２は、車両の異常を検出し、記憶装置２７に記憶された行動履歴を参照し、第１通知から行動を行うまでの時間または走行距離に応じて、ユーザに対して車両の異常に関する、第１通知とは異なる第２通知を送信するタイミングを決定する。コントローラ２２は決定されたタイミングにて、ユーザに対して第２通知を行う。第１通知とは過去における通知である。行動履歴からユーザのタイプとして早めに修理したいタイプなのかなるべく修理を遅らせたいタイプなのか分類可能である。早めに修理したいユーザに対しては通知タイミングを遅らせる。これにより部品の利用率を高めユーザの負担を軽減することが可能となる。一方でなるべく修理を遅らせたいユーザに対しては早めに通知する。これにより故障リスクを緩和することが可能となる。

【0042】

またコントローラ２２は、第１通知から行動を行うまでの時間または走行距離が短いユーザほど、第２通知を行うタイミングを遅くする。図３に示すように早めに修理したいユーザＸ１に対しては、実際にスターターが故障するまでの走行距離が２００ｋｍになった時点で通知するのではなく、実際にスターターが故障するまでの走行距離が１００ｋｍになった時点で最初の通知を行う。これにより部品の利用率を高めユーザの負担を軽減することが可能となる。

【0043】

またコントローラ２２は、異常が検出された場合、車両の修理が必要となるまでの残り走行可能距離を決定し、残り走行可能距離と、第１通知から行動を行うまでの時間または走行距離に応じて、第２通知を送信するタイミングを決定し、ユーザに対して第２通知を行う際に残り走行可能距離を表示させる。これにより部品の利用率を高めユーザの負担を軽減することが可能となる。

【0044】

所定の行動は、車両を所定の場所にて修理の依頼、予約もしくは実施を行うことと定義され、行動履歴には修理履歴が含まれる。コントローラ２２はこのような行動履歴を参照することにより、ユーザがどちらのタイプなのか精度よく分類できる。

【0045】

（第２実施形態）
次に、図５～７を参照して、本発明の第２実施形態を説明する。第２実施形態が第１実施形態と異なるのは、図５に示すようにコントローラ２２が、ユーザ特定部２９をさらに備えることである。第１実施形態と重複する構成については符号を引用してその説明は省略する。以下、相違点を中心に説明する。

【0046】

ユーザ特定部２９は、車両の運転席に座っているユーザを特定する。データベース２８にはユーザとそのユーザの運転特性が紐付けられて記憶されている。運転特性とはアクセルペダルを踏みタイミング、ブレーキペダルを踏みタイミング、ステアリングホイールの切り返し方、などである。ユーザ特定部２９はデータベース２８に記憶された運転特性を参照することにより車両の運転席に座っているユーザを特定することが可能となる。ユーザを特定する方法は運転特性に限定されず、ユーザが所持する携帯端末（例えばスマートフォン）との連携による個人認証技術によってユーザが特定されてもよい。

【0047】

またデータベース２８にはユーザが給油する際の燃料の残量（以下、給油時残量とよぶ場合がある）と実際に給油を行ったユーザとが紐付けられて記憶されている。このような給油履歴を用いることにより、初めて異常を通知する場合であってもユーザタイプに応じた適切なタイミングでの通知が可能となる。

【0048】

次に図６を参照して給油履歴を用いたユーザの分類方法の一例を説明する。給油時残量について図６に示すようにユーザＸ１の平均は８．４Ｌ、最大は１５．５Ｌ、最小は１．２Ｌ、標準偏差は３．２Ｌである。またユーザＸ２の平均は６．７Ｌ、最大は１４．１Ｌ、最小は３．０Ｌ、標準偏差は２．５Ｌである。またユーザＹ１の平均は１．１Ｌ、最大は３．１Ｌ、最小は０．１Ｌ、標準偏差は０．５Ｌである。このような給油履歴を用いることにより、ユーザＸ１，Ｘ２は早めに給油するタイプに分類され、ユーザＹ１は枯渇寸前まで給油しないタイプに分類される。上述の修理に関するタイプに照らせば、ユーザＸ１，Ｘ２は早めに修理したいタイプに分類され、ユーザＹ１は故障する寸前まで部品を使い切りたいタイプに分類される。よってデータベース２８に行動履歴（修理履歴）が蓄積されていない状態であっても、給油履歴を用いて通知タイミング、もしくは通知メッセージを変更することにより、行動履歴（修理履歴）を参照した場合と同じ効果が得られる。

【0049】

なお、図６に示す例ではユーザＸ１とＸ２は同じタイプであったが、仮にユーザＸ２がＹ１と同様に枯渇寸前まで給油しないタイプだった場合を考える。この場合、ユーザＸ１とＸ２は異なるタイプとなる。ユーザＸ１とＸ２は車両Ｘを利用する（例えば家族であれば同じ車両を複数人で利用する場合がある）。この場合車両Ｘを運転しているユーザがＸ１なのかもしくはＸ２なのかに応じて通知タイミングは異なる。車両Ｘを運転しているユーザがＸ１であれば通知タイミングは遅くなり、Ｘ２であれば通知タイミングは早くなる。この場合ユーザ特定部２９は上述の方法で車両Ｘを運転しているユーザを特定する。これにより、車両異常通知装置２０は車両Ｘを運転しているユーザのタイプに応じた通知が可能となる。ユーザが乗車して運転している場合、車両異常通知装置２０はディスプレイ４２を介してユーザに通知すればよく、ユーザが乗車していない場合は、ユーザが所持する携帯端末に通知すればよい。なおユーザが乗車していないときに通知する場合、車両異常通知装置２０は最後に運転したユーザを特定し、特定されたユーザの携帯端末に通知すればよい。

【0050】

なおデータベース２８に車両に対する所定の行動に関する通知が行われてからユーザが行動を行うまでの行動履歴と給油履歴の両方が記憶されている場合、通知決定部２５は両方のデータを用いて通知タイミング、もしくは通知メッセージを変更してもよい。両方のデータを用いることによりユーザのタイプが精度よく分類される。

【0051】

次に、図７のフローチャートを参照して、第２実施形態に係る車両異常通知装置２０の一動作例を説明する。ただし、ステップＳ２０３～２１１、２１５～２２１の処理は、図４に示すステップＳ１０３～１１１、１１５～１２１に示す処理と同様であるため、適宜説明を省略する。

【0052】

ステップＳ２０１において、コントローラ２２はデータベース２８を参照して給油履歴を収集する。今回異常が検出された車両のユーザが早めに給油するタイプである場合（ステップＳ２１３でＹＥＳ）、処理はステップＳ２１７に進む。一方、今回異常が検出された車両のユーザが枯渇寸前まで給油しないタイプである場合（ステップＳ２１３でＮＯ）、処理はステップＳ２１５に進む。ステップＳ２１７において通知決定部２５は通知タイミングを遅らせる。一方ステップＳ２１５において通知決定部２５は早めに通知することを決定する。

【0053】

（作用効果）
以上説明したように、第２実施形態に係る車両異常通知装置２０によれば、以下の作用効果が得られる。

【0054】

コントローラ２２は、車両を所有するユーザを特定し、特定されたユーザに対して第２通知を行う。ユーザを特定する際、ユーザが乗車して運転していることは必須ではない。ユーザは乗車していてもよく乗車していなくてもよい。１台の車両を複数人で共有している場合は、最後に運転したユーザが「車両を所有するユーザ」に該当する。１台の車両を１人で所有する場合は運転者イコール所有者となる。ユーザを特定することによりそのユーザに適した通知タイミングで通知を行うことが可能となる。

【0055】

コントローラ２２は、特定されたユーザの行動履歴を参照し、第２通知を送信するタイミングを決定する。これにより特定されたユーザに適した通知タイミングで通知を行うことが可能となる。

【0056】

行動履歴には、ユーザが給油する際の燃料の残量を示す給油履歴が含まれる。給油履歴を用いることにより修理履歴が蓄積されていない状態であってもユーザがどちらのタイプなのか精度よく分類できる。

【0057】

コントローラ２２は、記憶装置２７に記憶された、ユーザの運転特性を示す運転特性履歴を参照してユーザを特定する。これにより精度よくユーザを特定できる。

【0058】

上述の実施形態に記載される各機能は、１または複数の処理回路により実装され得る。処理回路は、電気回路を含む処理装置等のプログラムされた処理装置を含む。処理回路は、また、記載された機能を実行するようにアレンジされた特定用途向け集積回路（ＡＳＩＣ）や回路部品等の装置を含む。

【0059】

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

【符号の説明】

【0060】

１０ 車両異常通知システム
２０ 車両異常通知装置
２２ コントローラ
２３ 送信制御部
２４ 異常判定部
２５ 通知決定部
２６ メッセージ選定部
２７ 記憶装置
２８ データベース
２９ ユーザ特定部
３０ 通信ネットワーク
４０ 車両

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】