JP6802359B2 - メンテナンス通知システムおよびその制御方法、並びにプログラム - Google Patents

Description

本発明は、メンテナンス通知システムおよびその制御方法、並びにプログラムに関する。

従来、車両データを蓄積し、そのデータおよびメンテナンス（故障修理）情報をサーバー登録することで、類似データを有している運転者に対し故障予測を行う発明が開示されている（特許文献１等）。

特開２００４−２７２３７５号公報

特許文献１に示すように、故障した車両のデータを用いることで、類似のデータを有した車両に通知することで故障予測を行う技術は知られている。しかし、車両のデータだけでなく、運転者の運転特性（運転の仕方など）によって車両の適切なメンテナンスタイミングには差が生じ得る。

そこで、本願発明では、車両データと運転者の操作情報に基づいて、車両に対する適切なメンテナンスタイミングを判断し、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とすることを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、メンテナンス通知システムであって、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第１の推定手段と、
前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第２の推定手段と、
前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第１の推定手段にて推定された状態と、前記第２の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記推定された指標情報を用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段と、
前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段と
を有することを特徴とする。

本願発明により、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とする。

発明のその他の特徴及び利点は、添付図面を参照として以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
本願発明に係るシステム構成の例を示す図。 本願発明に係るサーバーおよび情報処理装置のハードウェア構成の例を示す図。 本願発明に係る車両のハードウェア構成の例を示す図。 本願発明に係るサーバーのソフトウェア構成の例を示す図。 本願発明に係るシステムのシーケンス図。 本願発明に係るサーバーにおける処理を示すフローチャート。

以下、本願発明に係る一実施形態について、図面を用いて説明する。なお、以下に示す構成等は一例であり、これに限定するものではない。

＜第１の実施形態＞
［システム構成］
図１は、本実施形態に係るメンテナンス通知システムにおけるシステム全体の構成例を示す図である。本実施形態に係るメンテナンス通知システムは、サーバー１０、情報処理装置２０、および複数の車両３０を含んで構成される。サーバー１０、情報処理装置２０は、インターネット６０を介して通信可能に接続される。また、車両３０も、アクセスポイント５０を介した無線通信により、インターネット６０に通信可能に接続される。

なお、車両３０が無線通信を可能にするために、車載、もしくは車両３０の操作者が保持可能な携帯端末により通信機能を実現してもよい。ここでの携帯端末は、スマートフォンやタブレットなどの機器が相当するが、これに限定するものではなく、他の機器であってもよい。また、車両３０（もしくは携帯端末）では、各種情報が可搬媒体４０にて保持されており、アクセスポイント５０を介した通信の他、可搬媒体４０の情報を情報処理装置２０などの提供可能なように構成される。情報処理装置２０は、例えばＰＣ(Personal Computer)などの一般的なコンピューターが該当するが、その構成については特に限定するものではない。本実施形態において、車両３０は、自動二輪車（いわゆる、バイク）を例に挙げて説明する。

なお、図１において、車両３０以外の各機器は、１つずつが示されているがこの構成に限定するものではなく、必要に応じて複数の機器が備えられるものとする。また、サーバー１０は、各処理を１台で処理するものではなく、機能やサービスに応じて複数の機器にて分散処理を行うように構成してもよい。車両３０についても、図１に示したものに限定するものではなく、更に多くの車両を含んでよく、また、これらの特性（車種や装備品等）は必ずしも同じでなくてよい。

［ハードウェア構成］
図２は、本願発明に係るサーバー１０および情報処理装置２０のハードウェア構成の例を示す図である。なお、ここでは、サーバー１０と情報処理装置２０のハードウェア構成は同一であるものとし、サーバー１０を例に挙げて説明する。

サーバー１０は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶部１０４、表示部１０５、入力部１０６、及び通信部１０７を含んで構成される。各部位は、バス１００を介して通信可能に接続される。

ＣＰＵ１０１は、サーバー１０の制御全体を司り、外部記憶部１０４等に格納されたプログラムを読み出して実行することにより、本願発明に係る処理等を実現する。ＲＯＭ１０２は、不揮発性の記憶領域であり、各種プログラムやデータが保持される。ＲＡＭ１０３は、揮発性の記憶領域であり、プログラムの実行時のワークエリアなどとして利用される。外部記憶部１０４は、不揮発性の記憶領域であり、例えば、本願発明に係る処理に用いられる各種プログラムやデータが保持される。表示部１０５は、各種画面を表示するための部位である。入力部１０６は、ユーザー等により、各種情報や設定を入力するための部位である。通信部１０７は、外部装置との通信を行う部位であり、通信方法は有線／無線は問わない。

図３は、本願発明に係る車両３０のハードウェア構成の例を示す図である。車両３０は、処理部３０１、記憶部３０２、検知部３０３、ＵＩ部３０４、通信部３０５、及び駆動部３０６を含んで構成される。処理部３０１は、本実施形態に係る処理の制御全体を司る。なお、上述したように、本実施形態において、車両３０は、自動二輪車を例に挙げて説明するが、自動二輪車の走行等の制御は処理部３０１における処理とは別に構成してよい。

記憶部３０２は、不揮発性の記憶領域であり、本実施形態に係る各種データが保持される。本実施形態では、記憶部３０２は、車両３０に対して着脱可能な可搬媒体として構成され、例えば、情報処理装置２０にも接続可能なＵＳＢ接続などに対応しているものとする。検知部３０３は、本実施形態に係る車両３０が備える各種動作に対する検知手段（センサ）であり、その種類および機能、検知方法は問わない。検知手段が検知する情報の例としては、アクセルもしくはブレーキの動作、燃料の残量、車体の傾き、走行中もしくは停止中の環境情報（気温、湿度など）、車体に対する衝撃、ハンドルの向き、消耗部材（タイヤや燃料など）の状態などが挙げられる。検知部３０３にて検知された情報は、生データとして記憶部３０２に保持されてもよいし、処理部３０１により加工データとして処理された上で記憶部３０２に保持されてもよい。

ＵＩ部３０４は、車両３０におけるユーザー等から各種情報や指示を受け付けるための部位である。通信部３０５は、外部装置との無線通信を行う部位であり、その通信方式は特に限定しない。また、通信部３０５を介して送受信するデータや通信タイミングも特に限定するものではない。駆動部３０６は、車両の走行等に関する駆動および操作を司る部位である。なお、駆動部３０６には、ハンドルやブレーキなどの部位を含むものとし、ここでの詳細な説明は省略する。

なお、本実施形態では、処理部３０１や記憶部３０２、ＵＩ部３０４、もしくは通信部３０５を、車両３０が備える構成として説明するがこれに限定するものではない。例えば、車載の装置（カーナビゲーション装置など）や、スマートフォンなどの携帯端末などを用いて、これらの機能を実現するようにしてもよい。

［ソフトウェア構成］
図４は、本願発明に係るサーバー１０のソフトウェア構成の例を示す図である。サーバー１０は、車両状況情報取得部２０１、運転履歴情報取得部２０２、蓄積データ処理部２０３、部品管理部２０４、車両情報管理部２０５、ユーザー情報管理部２０６、メンテナンス予測部２０７、およびメンテナンス通知部２０８を含んで構成される。

車両状況情報取得部２０１は、車両３０から（もしくは、情報処理装置２０を介して）、車両状況情報を取得する。車両状況情報とは、車両３０に装着された部品に関する情報（交換時期や消耗度合いを含む）や車両３０を管理するユーザーが実際に行ったメンテナンスに関する情報を示す。なおメンテナンスに関する情報には、給油のタイミングや量に関する情報を含んでもよい。また、ここでのメンテナンスに関する情報の提供者は、車両３０の管理者（所有者）に限定するものではなく、例えば、メンテナンス作業を請け負った販売店や車検を行う工場等の担当者であってもよい。車両状況情報取得部２０１は、情報処理装置２０を介して情報を取得する場合には、情報処理装置２０に対して、Ｗｅｂアプリケーションとしての入力画面を提供し、これを介してデータの入力を受け付けてもよい。

運転履歴情報取得部２０２は、車両３０から（もしくは、情報処理装置２０を介して）、運転履歴情報を取得する。運転履歴情報とは、ユーザーが車両３０に対して行った運転の履歴に関する情報（走行経路、走行距離、運転頻度、操作履歴などを含む）を示す。また、操作履歴には、ブレーキやアクセルの制御、ギアの変更、ハンドルに対する操作、スピードの変化、車体の傾け方、連続乗車時間、運転時の天候などが含まれてもよい。運転履歴情報取得部２０２は、情報処理装置２０を介して情報を取得する場合には、情報処理装置２０に対して、Ｗｅｂアプリケーションとしての入力画面を提供し、これを介してデータの入力を受け付けてもよい。

蓄積データ処理部２０３は、複数の車両３０から収集（取得）されて蓄積されたデータから、車両（および、車両が備える各部品）に対するメンテナンスに関する指標を生成する。ここでの指標とは、操作履歴と部品の消耗に関する相関関係や、操作履歴に適した部品の種類を特定するための判断基準などが該当する。例えば、蓄積データ処理部２０３は、蓄積されたデータの中から、同一または類似の車両を有する他のユーザーであって、かつ、車両の利用目的や頻度もしくは操作方法（操作の傾向）が近いユーザーが行ったメンテナンス履歴を特定し、取得する。そして、蓄積データ処理部２０３は、これらの情報に基づき、適するメンテナンスの時期や対象を判断するための基準を求める（生成する）。なお、相関関係の求め方や、操作履歴に適した部品の種類の求め方は特に限定するものではなく、周知の統計手法や機械学習、ディープラーニング、予め定義された閾値（消費期限情報や経年劣化に関する情報）との比較などにより決定してよい。また、指標は、１つに限定されるものではなく、蓄積データに対する処理に応じて、複数の指標が設けられてもよい。また、用いる蓄積データの種類や、指標の種類を、車両のユーザーが指定できるようにしてもよい。

部品管理部２０４は、各車両に装着可能な各部品の情報を管理する。部品情報としては、例えば、部品のカテゴリー（種類）、性能や用途、消耗度合いの傾向、普及度合い、価格、製造元などが該当する。また、ここでの部品情報とは、タイヤやミラーなどの部品に限定するものではなく、エンジンオイルや燃料の性能などを含めてもよい。また、部品情報は、例えばメーカーが提供している情報の他、蓄積データ処理部２０３にて処理した情報を踏まえて更新されるようにしてもよい。

車両情報管理部２０５は、各車両の車両情報を管理する。ここでの車両情報とは、車両に固有の情報（製造番号や機種）などの情報が該当する。また、車両情報には、車両ごとの、車両状況情報取得部２０１にて取得した車両状況情報、および運転履歴情報取得部２０２にて取得した運転履歴情報を含むものとする。

ユーザー情報管理部２０６は、各車両の管理者であるユーザーのユーザー情報を管理する。ユーザー情報としては、ユーザーの嗜好や、現在所有している車両の情報、これまでに所有した（もしくは、操作したことのある）車両の情報を含んでもよい。もしくは、興味のある車両に関する情報を含んでもよい。ユーザー情報については、ユーザーが予め設定した内容を含んでよく、例えば、後述するメンテナンス通知の通知先情報を含む。

メンテナンス予測部２０７は、部品管理部２０４、車両情報管理部２０５、およびユーザー情報管理部２０６にて管理している情報、および、蓄積データ処理部２０３にて処理した指標に基づき、車両３０に対するメンテナンスに関する予測を行う。ここでの詳細は後述するが、例えば、メンテナンス対象の部品、部位、タイミング（時期）などが予測される。

メンテナンス通知部２０８は、メンテナンス予測部２０７にて予測された情報に基づいて、ユーザーに対してメンテナンス情報の通知を行う。ここでの通知先は、ユーザー情報管理部２０６にて管理されているユーザー情報に示されているものとする。通知方法は、メールやレターなどが挙げられるが、これらに限定するものではない。

［処理シーケンス］
図５は、本実施形態に係るメンテナンス予測システムにおける処理のシーケンスを示す図である。

Ｓ５０１にて、車両３０は、車両状況情報および運転履歴情報を適時記録する。なお、各情報の記録は必ずしも同時に行う必要があるものではなく、記録する周期や記録するタイミングはそれぞれ異なっていてよい。記録するタイミングは、予め定義された間隔にて記録するようにしてもよいし、所定の動作（操作）が行わされた際に記録するようにしてもよい。例えば、車両３０側にてメンテナンスが行われたこと（例えば、部品が交換されたこと）を検知し、その情報を記録しておいてもよい。

Ｓ５０２にて、車両３０は、記録した車両状況情報および運転履歴情報をサーバー１０に対して送信する。なお、各情報の送信は必ずしも同時に行う必要はなく、いずれか一方のみを送信するようにしてもよい。また、送信するタイミングは、例えば、所定量のデータが蓄積した場合や前回の送信から所定期間が経過したタイミングで送信するようにしてもよい。また、無線通信が可能となったタイミングでまとめて送信してもよいし、分割して送信するようにしてもよい。

Ｓ５１１にて、情報処理装置２０は、ユーザーからの入力、もしくは、可搬媒体４０の接続を介した入力により、車両状況情報および運転履歴情報の入力を受け付ける。

Ｓ５１２にて、情報処理装置２０は、入力された各情報をサーバー１０に対して送信する。なお、送信履歴を情報処理装置２０内で管理するようにしてもよい。上述したように、サーバー１０が各情報を入力するための画面（例えば、Ｗｅｂアプリケーションによる画面）を情報処理装置２０に対して提供するようにしてもよい。

Ｓ５３１にて、サーバー１０は、任意のタイミングにおいて、ユーザーからのユーザー情報および車両情報の入力および更新を受け付け、登録を行う。ユーザー情報および車両情報の更新タイミングは特に限定するものではなく、ユーザーが必要に応じて行ってよい。

Ｓ５３２にて、サーバー１０は、部品情報を取得する。部品情報は、サーバー１０の管理者やメーカー等が提供する情報を取得するようにしてもよいし、外部サーバー（不図示）と通信を行うことにより定期的に取得するようにしてもよい。

Ｓ５３３にて、サーバー１０は、車両３０もしくは情報処理装置２０から送信された各種情報を取得する。取得した情報は、車両情報管理部２０５において車両３０に対応付けて保持する他、情報の種類に応じて分類し、蓄積データとして保持する。

Ｓ５３４にて、サーバー１０は、蓄積データに対する処理を行う。具体的には、蓄積データ処理部２０３により、メンテナンスの内容や時期を判定する際に用いられる指標を、蓄積データを用いて生成する。なお、本処理工程は、各種情報を受信したタイミングで行うものに限定するものではない。例えば、前回処理してから所定の時間が経過した際に処理するようにしてもよいし、サーバー１０の管理者による指示があった際に実行するようにしてもよい。また、所定量のデータ更新（追加）があった際に実行するようにしてもよい。つまり、時間の経過とともに、複数の車両からデータが逐次収集され、更新されていくため、そのデータの収集状況および処理状況に応じて、後述のメンテナンス予測に用いられる情報（指標）は変化していくこととなる。

Ｓ５３５にて、サーバー１０は、メンテナンス予測の対象となるある車両３０（対象車両）に関し、車両３０の各種情報、および、Ｓ５３３にて行った処理により求められた情報（指標）に基づいて、メンテナンスに関する予測処理を行う。本処理の詳細は、図６を用いて後述する。本工程は、Ｓ５３４の処理の実行タイミングとは独立して行われてよく、所定の時間間隔にて実行してもよいし、Ｓ５３２にて各種情報を受信した際に実行してもよい。本実施形態の予測処理は、メンテナンスの内容の他、通知するタイミング（時期）についても決定する。

Ｓ５３６にて、サーバー１０は、Ｓ５３５の処理により求められたメンテナンス情報をユーザーに対して通知する。ここでは、車両３０の情報に対応付けられたユーザー情報が示す通知先にメンテナンス情報を送信するものとする。例えば、ユーザー情報に通知先としてメールアドレスが登録されている場合には、サーバー１０は、メンテナンス情報を含むメールを通知先に送信する。本通知のタイミングは、ユーザーが設定した間隔に通知するようにしてもよいし（例えば、一日１回）、緊急度の高い通知については即時に通知するようにしてもよい。

Ｓ５４１にて、ユーザーは、任意のタイミングにおいて、ユーザー情報および車両情報の入力および更新を行う。上述したように、ユーザー情報および車両情報の更新タイミングは特に限定するものではなく、ユーザーが必要に応じて行ってよい。また、車両に対するメンテナンスを行った際には、適時入力を行うものとする。また、ここでの入力／更新は、必ずしも車両の管理者（所有者）に限定するものではなく、車両の販売者などが行ってもよい。また、各情報の入力画面は、サーバー１０がアプリケーション（例えば、Ｗｅｂアプリケーション）として提供してもよい。また、本実施形態におけるメンテナンス通知に起因してメンテナンスを行った場合には、その情報を併せて登録してもよい。

Ｓ５４２にて、ユーザーは、サーバー１０から通知されたメンテナンス情報を受信する。例えば、携帯端末（不図示）にて、メールを受信する。更に、ユーザーは受信したメンテナンス情報を表示する。

［処理フロー］
（メンテナンス予測処理）
以下、本実施形態に係るサーバー１０におけるメンテナンス予測処理について、図６を用いて説明する。本処理フローは、サーバー１０において、ＣＰＵ１０１が、外部記憶部１０４等に格納されたプログラムを読み出して実行されることで実現される。なお、以下に示す処理の流れは一例であり、必要に応じて順序を入れ替えてもよい。

Ｓ６０１にて、サーバー１０は、車両情報管理部２０５にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両の車両状況情報を取得する。ここで取得する情報は、最新の情報のみを取得してもよいし、所定の範囲での経過情報を含めて取得してもよい。

Ｓ６０２にて、サーバー１０は、車両情報管理部２０５にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両の運転履歴情報を取得する。

Ｓ６０３にて、サーバー１０は、蓄積データ処理部２０３が蓄積データから生成した指標情報を取得する。指標情報は、車両の車両状況情報や運転履歴情報の中から所定の項目をキーとして、関連する情報のみを取得してもよい。

Ｓ６０４にて、サーバー１０は、取得した各情報に基づき、車両の状態を推定する。ここでの車両の状態とは、車両状況情報にて示された情報をそのまま車両の状態として扱ってもよいし、複数の項目からある部位（パーツ）や機能の状態を推定してもよい。例えば、タイヤに関し、前回の交換時期、走行距離、ユーザーの車両の利用目的、およびユーザーの操作傾向から、タイヤの状態（例えば、消耗度合い）を推定するようにしてもよい。更に、本工程において、車両を操作するユーザーの特性を特定してもよい。例えば、運転履歴情報が示す走行経路や頻度からその車両の使用目的を推定してもよいし、ユーザーの運転技術の変化（向上、低下）についても推定してよい。また、過去のユーザーのメンテナンス状況や、部品の交換履歴などから、ユーザーの車両に対する収支（お金のかけ具合）を推定し、車両に対する金銭的負担の期待値を推定するようにしてもよい。

Ｓ６０５にて、サーバー１０は、Ｓ６０４にて推定した車両の状態と、Ｓ６０３にて取得した指標情報とに基づいて、車両に対するメンテナンスの時期および内容の候補を特定する。ここでの候補としては、「ブレーキオイルの補給」を「Ｘ日以内」に行う、「タイヤの交換」を「Ｙヶ月以内」に行う、など同じ部位（部品、消耗品）に限らず複数のメンテナンス内容の候補を特定する。

Ｓ６０６にて、サーバー１０は、ユーザー情報管理部２０６にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両のユーザーのユーザー情報を取得する。

Ｓ６０７にて、サーバー１０は、Ｓ６０６にて特定した候補の中から、ユーザー情報に基づいて、現時点でユーザーに提供するべきメンテナンスの内容を決定する。例えば、緊急度の高いメンテナンスの内容については必ず通知するようにしてもよいし、ユーザーが前回のメンテナンスにて行った部分については通知の優先度を低くして他の通知を優先するようにしてもよい。また、現時点でユーザーがしばらく車両を利用しない旨の設定がなされている場合には、通知を行わないようにしてもよい。

Ｓ６０８にて、サーバー１０は、決定したメンテナンスの内容に関連する更なる情報の提供を行うか否かを判定する。ここでの判定は、例えば、ユーザーによる設定に基づいてもよいし、メンテナンスの内容に応じて判定してもよい。本実施形態では、更なる情報として、メンテナンスにて利用可能な（交換可能な）部品の情報を提供する例について説明する。更なる情報を提供すると判定した場合には（Ｓ６０８にてＹＥＳ）Ｓ６０９へ進み、更なる情報を提供しないと判定した場合には（Ｓ６０８にてＮＯ）本処理フローを終了する。

Ｓ６０９にて、サーバー１０は、部品管理部２０４が管理する部品情報を取得する。ここでは、メンテナンスの内容やユーザー情報に応じて、取得する情報を決定してもよい。例えば、タイヤのメンテナンスが必要であるとＳ６０５にて特定した場合、タイヤに関する情報（例えば、製品名や販売店、性能情報）を取得する。

Ｓ６１０にて、サーバー１０は、取得した部品情報の中から、メンテナンス情報と併せて提供する情報を決定する。例えば、ユーザー設定にて設定されたユーザーの好みや、推定されたユーザーの特性（技術レベル、使用目的）などに応じて、適する部品の情報を決定する。また、推定したユーザーの特性と同一または類似のユーザーを蓄積データに基づいて特定し、そのユーザーが使用している部品をお勧めの部品として決定してもよい。その後、本処理フローを終了する。

［本実施形態に係る情報の例］
本実施形態に係るシステムにて扱う情報の一例について説明する。上述したように本実施形態では、車両に関するメンテナンス通知を行うために、本車両の車両状況情報および運転履歴情報を用いる。更に本車両以外から収集した車両状況情報および運転履歴情報を処理することで得られた情報（指標）、および、部品に関する情報を用いる。

車両状況情報としては、以下のような情報が挙げられる。各部品の交換履歴、装着している部品の種類および性能、給油のタイミングおよび回数、など。

運転履歴情報としては、以下のような情報が挙げられる。アクセルやブレーキの操作履歴、ギアの変更回数、車体の傾け方、操作中の姿勢、操作中の重心移動、操作回数、操作時間、走行距離、事故（衝撃や振動）の有無、操作頻度、前回操作してから次回操作するまでの時間間隔、走行場所、道路上での走行位置、など。

指標情報としては、操作者の運転履歴情報から、その運転者の運転傾向を特定するためのカテゴリー分類が挙げられる。例えば、操作者を複数のカテゴリーＡ（安全運転傾向）、カテゴリーＢ（スピード優先傾向）、およびカテゴリーＣ（あおり運転傾向）など、のようなカテゴリーが挙げられる。これは、蓄積データを処理することで、操作履歴から複数のカテゴリーを生成する。カテゴリーの分類は人が予め与えておいてもよいし、自動生成するようにしてもよい。更に、各カテゴリーに対応付けて、メンテナンスの傾向や利用する部品などを蓄積データから求める。これにより、あるメンテナンス予測を行う対象のユーザーに関し、そのユーザーの操作傾向と指標情報とから、適切なメンテナンス時期や推奨する部品などが特定できる。

上記を踏まえ、指標情報としては、例えば、「ある操作傾向のあるユーザー（カテゴリーＡ）に対し、消耗部品Ａ（例えば、タイヤ）の消耗度合いがＸ％であると推定される場合には、Ｙ日以内に交換することを推奨する」といった情報でもよい。また、「前回操作してからＺヶ月以上経過している場合には、部品Ｗの交換を推奨する」といった情報でもよい。また、「アクセルの回数に対し、ブレーキの回数が所定割合以上である傾向のユーザーは操作に関する特性をカテゴリーＣとする」といった、カテゴリー分けの操作傾向の類似性を指標情報として用いてもよい。

部品情報としては、部品の性能および機能、製造元などが該当する。なお、メンテナンス通知において、通知する内容は部品に限定するものではないため、例えば、サービス内容など通知内容に応じて、管理する情報は変更してよい。

以上、本実施形態により、車両データと運転者の操作情報に基づいて車両に対する適切なメンテナンスタイミングを判断することで、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とすることができる。

＜第２の実施形態＞
第１の実施形態では、メンテナンス情報の通知先は、ユーザー情報に通知先として設定された車両のユーザー（管理者）に対して行っていた。これに限定せずに、他の所定の通知先にも通知（情報共有）するようにしてもよい。例えば、車両の製造元や、メンテナンスを行うことが可能な工場や販売店などにも通知するようにしてよい。この場合、過去のメンテナンス情報やユーザー情報（好みなど）を併せて提供するようにしてよい。

また、通知先としては、ユーザーが登録している通知先の他、ユーザーの操作傾向や頻度などに基づいて、類似性の高い他のユーザーが利用している店へ通知するようにしてもよい。

更にこの通知を受け取った通知先は、その情報を利用して、メンテナンスに関する更なるサービス（例えば、好みに合った部品情報の提供やメンテナンススケジュールに対する予約処理の効率化など）を提供するようにしてもよい。

これにより、車両のユーザーのみならず他の関係者においても、メンテナンスに関する部品などの情報を得ることができ、メンテナンスの効率を向上せさせることが可能になる。また、車両の操作履歴およびその操作傾向に基づく情報の共有が可能となり、ユーザーの利便性を高めることが可能となる。

＜その他の実施形態＞
上記の実施形態では、部品の消耗等に応じたメンテナンスを行ったが、これに限定するものではない。例えば、事故歴や免許のクラスに応じたメンテナンス情報を提供してもよい。また、ユーザー自身によるメンテナンスの頻度や、工場等によるユーザー以外によるメンテナンスの頻度の割合を考慮して、ユーザーが自分でメンテナンスを行うか否かを考慮し、通知内容を切り替えてもよい。更に、この情報に基づいて、操作傾向のみならず、メンテナンスの傾向（メンテナンス技術）を推定し、通知内容を切り替えてもよい。例えば、乗車自体の頻度は低くても、メンテナンス（例えば、改造など）の頻度が高いようなユーザーについては、その内容に応じた通知を行うようにしてもよい。

また、ユーザーから、車両に対して支出可能な予算の情報を予め受け付け、その情報に基づいて部品の情報を提供してもよい。

また、車検や自賠責保険の期間など、予め期間が決められているものを考慮し、その期間に近い場合には、メンテナンス情報を送ったり、逆に送らなかったりするようにしてもよい。

また、車両が中古車（所有者が複数回変わっている車両）である場合などには、車台番号などに基づいて、その車両自体の履歴を新たなユーザーに引継ぎができるようにしてもよい。

また、車両間にて通信を行い、その通信頻度や走行間隔（車間距離）などを含めて、運転履歴情報を記録してもよい。

また、第２の実施形態では、情報の共有先の例として、製造元やメンテナンス工場などを例に挙げたが、その他にも、例えば、インターネットショッピングを行うためのＥＣサイトとの連携を行うような構成であってもよい。この場合、ユーザーの操作履歴や好み、操作傾向に併せて、ＥＣサイトから各種商品の情報を提供するような構成が該当する。

＜実施形態のまとめ＞
１．上記実施形態のメンテナンス通知システム（例えば、１０）は、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段（例えば、２０１、２０２、２０５）と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段（例えば、２０３）と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段（例えば、２０７）と、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段（例えば、２０８）と
を有することを特徴とする。

この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。

２．上記実施形態のメンテナンス通知システムは、
前記状況情報は、車両に対してメンテナンスを行った履歴を含み、
前記生成手段は、前記運転履歴情報と前記メンテナンスを行った履歴とに基づいて、車両が備える部品の消耗度合いを推定するための指標情報を生成することを特徴とする。

この実施形態によれば、メンテナンスの履歴を反映した、より精度の高いメンテナンス通知を行うことができる。

３．上記実施形態のメンテナンス通知システムは、
前記生成手段は、前記運転履歴情報に基づいて、ユーザーの操作の傾向に対応した複数のカテゴリー分けを行うための１または複数の指標情報を生成することを特徴とする。

この実施形態によれば、ユーザーの操作の特性ごとのメンテナンス通知を行うことができる。

４．上記実施形態のメンテナンス通知システムは、
前記特定手段は、前記運転履歴情報と前記指標情報とに基づいて、前記対象車両のユーザーと、同一または類似の操作の傾向があるユーザーを特定することを特徴とする。

この実施形態によれば、自身と同一又は類似のユーザーの情報に基づいて、メンテナンス通知を受けることが可能となる。

５．上記実施形態のメンテナンス通知システムは、
前記特定手段は、前記同一または類似の操作の傾向があるユーザーがメンテナンスを行った履歴に基づいて、前記対象車両のメンテナンスを行うべきタイミングを特定することを特徴とする。

この実施形態によれば、自身と同一又は類似のユーザーの情報に基づいて、メンテナンス通知を受けることが可能となる。

６．上記実施形態のメンテナンス通知システムは、
前記蓄積手段は、インターネット（例えば、６０）を介して、前記複数の車両それぞれから前記状況情報および前記運転履歴情報を収集することを特徴とする。

この実施形態によれば、メンテナンス通知の際に用いられるデータを、外部ネットワークを介して、より多く収集することが可能となる。

７．上記実施形態のメンテナンス通知システムは、
前記状況情報は、前記メンテナンスに関する通知に対して対応を行ったか否かの情報を含むことを特徴とする。

この実施形態によれば、メンテナンス通知に対するユーザーの対応結果を収集でき、その情報を反映した更なるメンテナンス通知が可能となる。

８．上記実施形態のメンテナンス通知システムは、
前記特定手段は、ユーザーの設定に応じて、メンテナンスを行うべきタイミングを特定する際に用いる指標情報を切り替えることを特徴とする。

この実施形態によれば、ユーザーの意向に沿ったメンテナンス通知を行うことができる。

９．上記実施形態のメンテナンス通知システムは、
前記特定手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、メンテナンスに関連する部品の情報を特定し（例えば、２０４）、
前記通知手段は更に、特定した前記部品の情報を通知する
ことを特徴とする。

この実施形態によれば、よりユーザーの利便性の高いメンテナンス通知を行うことができる。

１０．上記実施形態のメンテナンス通知システムは、
前記通知手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、前記対象車両のユーザー以外の通知先に、当該メンテナンスに関する情報を通知すること特徴とする。

この実施形態によれば、車両のユーザーとは別のユーザー等においてもメンテナンスに関する情報共有を行うことができる。

１１．上記実施形態のメンテナンス通知システムの制御方法は、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積工程と、
前記蓄積工程にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成工程と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成工程にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定工程と、
前記特定工程にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知工程と
を有することを特徴とする。

この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。

１２．上記実施形態のプログラムは、
コンピューターを、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段
として機能させる。

この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。

本発明は上記実施の形態に制限されるものでは無く、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

Claims (15)

1. 複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、
   前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段と、
   メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第１の推定手段と、
   前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第２の推定手段と、
   前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第１の推定手段にて推定された状態と、前記第２の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段と、
   前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段と
   を有することを特徴とするメンテナンス通知システム。
2. 請求項１に記載のメンテナンス通知システムであって、
   前記状況情報は、車両に対してメンテナンスを行った履歴を含み、
   前記生成手段は、前記運転履歴情報と前記メンテナンスを行った履歴とに基づいて、指標情報を生成することを特徴とするメンテナンス通知システム。
3. 請求項１または２に記載のメンテナンス通知システムであって、
   前記生成手段は、前記運転履歴情報に基づいて、ユーザーの操作の傾向に対応した複数のカテゴリー分けを行うための１または複数の指標情報を生成することを特徴とするメンテナンス通知システム。
4. 請求項１乃至３のいずれか一項に記載のメンテナンス通知システムであって、
   前記特定手段は、前記運転履歴情報と前記指標情報とに基づいて、前記対象車両のユーザーと、同一または類似の操作の傾向があるユーザーを特定することを特徴とするメンテナンス通知システム。
5. 請求項４に記載のメンテナンス通知システムであって、
   前記特定手段は、前記同一または類似の操作の傾向があるユーザーがメンテナンスを行った履歴に基づいて、前記対象車両のメンテナンスを行うべきタイミングを特定することを特徴とするメンテナンス通知システム。
6. 請求項１乃至５のいずれか一項に記載のメンテナンス通知システムであって、
   前記蓄積手段は、インターネットを介して、前記複数の車両それぞれから前記状況情報および前記運転履歴情報を収集することを特徴とするメンテナンス通知システム。
7. 請求項１乃至６のいずれか一項に記載のメンテナンス通知システムであって、
   前記状況情報は、前記メンテナンスに関する通知に対して対応を行ったか否かの情報を含むことを特徴とするメンテナンス通知システム。
8. 請求項１乃至７のいずれか一項に記載のメンテナンス通知システムであって、
   前記特定手段は、ユーザーの設定に応じて、メンテナンスを行うべきタイミングを特定する際に用いる指標情報を切り替えることを特徴とするメンテナンス通知システム。
9. 請求項１乃至８のいずれか一項に記載のメンテナンス通知システムであって、
   前記特定手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、メンテナンスに関連する部品の情報を特定し、
   前記通知手段は更に、特定した前記部品の情報を通知する
   ことを特徴とするメンテナンス通知システム。
10. 請求項１乃至９のいずれか一項に記載のメンテナンス通知システムであって、
    前記通知手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、前記対象車両のユーザー以外の通知先に、当該メンテナンスに関する情報を通知すること特徴とするメンテナンス通知システム。
11. 複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積工程と、
    前記蓄積工程にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成工程と、
    メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第１の推定工程と、
    前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第２の推定工程と、
    前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成工程にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第１の推定工程にて推定された状態と、前記第２の推定工程にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定工程と、
    前記特定工程にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知工程と
    を有することを特徴とするメンテナンス通知システムの制御方法。
12. コンピューターを、
    複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段、
    前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段、
    メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第１の推定手段、
    前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第２の推定手段、
    前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第１の推定手段にて推定された状態と、前記第２の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段、
    前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段
    として機能させるためのプログラム。
13. 請求項１乃至１０のいずれか一項に記載のメンテナンス通知システムであって、
    前記通知手段は、前記メンテナンスに関する通知を当該メンテナンスの対応が可能な通知先へ通知することで、当該通知先における前記メンテナンスの予約処理を要求することを特徴とするメンテナンス通知システム。
14. 請求項１乃至１０のいずれか一項に記載のメンテナンス通知システムであって、
    前記メンテナンスに関する通知のタイミングおよび内容は、前記対象車両のユーザーの事故歴、免許の情報、前記対象車両の保険情報、前記対象車両の車検情報、前記対象車両の過去のユーザーの情報の少なくともいずれかに基づいて、制御されることを特徴とするメンテナンス通知システム。
15. 請求項１乃至１０のいずれか一項に記載のメンテナンス通知システムであって、
    前記通知手段は、前記メンテナンスに関する通知を当該メンテナンスに用いられる部品の提供が可能な通知先へ通知することで、当該通知先にて提供可能な前記メンテナンスに利用可能な部品に関する情報を前記対象車両のユーザーへ提供するように要求することを特徴とするメンテナンス通知システム。

Images