特表-18179307IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 本田技研工業株式会社の特許一覧
再表2018-179307メンテナンス通知システムおよびその制御方法、並びにプログラム
<>
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000003
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000004
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000005
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000006
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000007
  • 再表WO2018179307-メンテナンス通知システムおよびその制御方法、並びにプログラム 図000008
< >
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2018年10月4日
【発行日】2019年12月26日
(54)【発明の名称】メンテナンス通知システムおよびその制御方法、並びにプログラム
(51)【国際特許分類】
   G06Q 10/00 20120101AFI20191129BHJP
   G06Q 10/04 20120101ALI20191129BHJP
   G16Z 99/00 20190101ALI20191129BHJP
   B60S 5/00 20060101ALI20191129BHJP
【FI】
   G06Q10/00 300
   G06Q10/04
   G16Z99/00
   B60S5/00
【審査請求】有
【予備審査請求】有
【全頁数】24
【出願番号】特願2019-508082(P2019-508082)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2017年3月31日
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ
(71)【出願人】
【識別番号】000005326
【氏名又は名称】本田技研工業株式会社
(74)【代理人】
【識別番号】100076428
【弁理士】
【氏名又は名称】大塚 康徳
(74)【代理人】
【識別番号】100115071
【弁理士】
【氏名又は名称】大塚 康弘
(74)【代理人】
【識別番号】100112508
【弁理士】
【氏名又は名称】高柳 司郎
(74)【代理人】
【識別番号】100116894
【弁理士】
【氏名又は名称】木村 秀二
(74)【代理人】
【識別番号】100134175
【弁理士】
【氏名又は名称】永川 行光
(74)【代理人】
【識別番号】100166648
【弁理士】
【氏名又は名称】鎗田 伸宜
(72)【発明者】
【氏名】神戸 佑太
(72)【発明者】
【氏名】米川 公博
【テーマコード(参考)】
3D026
5L049
【Fターム(参考)】
3D026BA03
3D026BA21
5L049AA04
5L049CC15
5L049DD01
5L049DD04
(57)【要約】
メンテナンス通知システムであって、複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段と、メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段と、前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段とを有する。
【特許請求の範囲】
【請求項1】
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段と、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段と
を有することを特徴とするメンテナンス通知システム。
【請求項2】
請求項1に記載のメンテナンス通知システムであって、
前記状況情報は、車両に対してメンテナンスを行った履歴を含み、
前記生成手段は、前記運転履歴情報と前記メンテナンスを行った履歴とに基づいて、車両が備える部品の消耗度合いを推定するための指標情報を生成することを特徴とするメンテナンス通知システム。
【請求項3】
請求項1または2に記載のメンテナンス通知システムであって、
前記生成手段は、前記運転履歴情報に基づいて、ユーザーの操作の傾向に対応した複数のカテゴリー分けを行うための1または複数の指標情報を生成することを特徴とするメンテナンス通知システム。
【請求項4】
請求項1乃至3のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は、前記運転履歴情報と前記指標情報とに基づいて、前記対象車両のユーザーと、同一または類似の操作の傾向があるユーザーを特定することを特徴とするメンテナンス通知システム。
【請求項5】
請求項4に記載のメンテナンス通知システムであって、
前記特定手段は、前記同一または類似の操作の傾向があるユーザーがメンテナンスを行った履歴に基づいて、前記対象車両のメンテナンスを行うべきタイミングを特定することを特徴とするメンテナンス通知システム。
【請求項6】
請求項1乃至5のいずれか一項に記載のメンテナンス通知システムであって、
前記蓄積手段は、インターネットを介して、前記複数の車両それぞれから前記状況情報および前記運転履歴情報を収集することを特徴とするメンテナンス通知システム。
【請求項7】
請求項1乃至6のいずれか一項に記載のメンテナンス通知システムであって、
前記状況情報は、前記メンテナンスに関する通知に対して対応を行ったか否かの情報を含むことを特徴とするメンテナンス通知システム。
【請求項8】
請求項1乃至7のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は、ユーザーの設定に応じて、メンテナンスを行うべきタイミングを特定する際に用いる指標情報を切り替えることを特徴とするメンテナンス通知システム。
【請求項9】
請求項1乃至8のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、メンテナンスに関連する部品の情報を特定し、
前記通知手段は更に、特定した前記部品の情報を通知する
ことを特徴とするメンテナンス通知システム。
【請求項10】
請求項1乃至9のいずれか一項に記載のメンテナンス通知システムであって、
前記通知手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、前記対象車両のユーザー以外の通知先に、当該メンテナンスに関する情報を通知すること特徴とするメンテナンス通知システム。
【請求項11】
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積工程と、
前記蓄積工程にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成工程と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成工程にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定工程と、
前記特定工程にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知工程と
を有することを特徴とするメンテナンス通知システムの制御方法。
【請求項12】
コンピューターを、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、メンテナンス通知システムおよびその制御方法、並びにプログラムに関する。
【背景技術】
【0002】
従来、車両データを蓄積し、そのデータおよびメンテナンス(故障修理)情報をサーバー登録することで、類似データを有している運転者に対し故障予測を行う発明が開示されている(特許文献1等)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2004−272375号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に示すように、故障した車両のデータを用いることで、類似のデータを有した車両に通知することで故障予測を行う技術は知られている。しかし、車両のデータだけでなく、運転者の運転特性(運転の仕方など)によって車両の適切なメンテナンスタイミングには差が生じ得る。
【0005】
そこで、本願発明では、車両データと運転者の操作情報に基づいて、車両に対する適切なメンテナンスタイミングを判断し、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とすることを目的とする。
【課題を解決するための手段】
【0006】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、メンテナンス通知システムであって、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段と、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段と
を有することを特徴とする。
【発明の効果】
【0007】
本願発明により、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とする。
【0008】
発明のその他の特徴及び利点は、添付図面を参照として以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。
【図面の簡単な説明】
【0009】
添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
図1】本願発明に係るシステム構成の例を示す図。
図2】本願発明に係るサーバーおよび情報処理装置のハードウェア構成の例を示す図。
図3】本願発明に係る車両のハードウェア構成の例を示す図。
図4】本願発明に係るサーバーのソフトウェア構成の例を示す図。
図5】本願発明に係るシステムのシーケンス図。
図6】本願発明に係るサーバーにおける処理を示すフローチャート。
【発明を実施するための形態】
【0010】
以下、本願発明に係る一実施形態について、図面を用いて説明する。なお、以下に示す構成等は一例であり、これに限定するものではない。
【0011】
<第1の実施形態>
[システム構成]
図1は、本実施形態に係るメンテナンス通知システムにおけるシステム全体の構成例を示す図である。本実施形態に係るメンテナンス通知システムは、サーバー10、情報処理装置20、および複数の車両30を含んで構成される。サーバー10、情報処理装置20は、インターネット60を介して通信可能に接続される。また、車両30も、アクセスポイント50を介した無線通信により、インターネット60に通信可能に接続される。
【0012】
なお、車両30が無線通信を可能にするために、車載、もしくは車両30の操作者が保持可能な携帯端末により通信機能を実現してもよい。ここでの携帯端末は、スマートフォンやタブレットなどの機器が相当するが、これに限定するものではなく、他の機器であってもよい。また、車両30(もしくは携帯端末)では、各種情報が可搬媒体40にて保持されており、アクセスポイント50を介した通信の他、可搬媒体40の情報を情報処理装置20などの提供可能なように構成される。情報処理装置20は、例えばPC(Personal Computer)などの一般的なコンピューターが該当するが、その構成については特に限定するものではない。本実施形態において、車両30は、自動二輪車(いわゆる、バイク)を例に挙げて説明する。
【0013】
なお、図1において、車両30以外の各機器は、1つずつが示されているがこの構成に限定するものではなく、必要に応じて複数の機器が備えられるものとする。また、サーバー10は、各処理を1台で処理するものではなく、機能やサービスに応じて複数の機器にて分散処理を行うように構成してもよい。車両30についても、図1に示したものに限定するものではなく、更に多くの車両を含んでよく、また、これらの特性(車種や装備品等)は必ずしも同じでなくてよい。
【0014】
[ハードウェア構成]
図2は、本願発明に係るサーバー10および情報処理装置20のハードウェア構成の例を示す図である。なお、ここでは、サーバー10と情報処理装置20のハードウェア構成は同一であるものとし、サーバー10を例に挙げて説明する。
【0015】
サーバー10は、CPU101、ROM102、RAM103、外部記憶部104、表示部105、入力部106、及び通信部107を含んで構成される。各部位は、バス100を介して通信可能に接続される。
【0016】
CPU101は、サーバー10の制御全体を司り、外部記憶部104等に格納されたプログラムを読み出して実行することにより、本願発明に係る処理等を実現する。ROM102は、不揮発性の記憶領域であり、各種プログラムやデータが保持される。RAM103は、揮発性の記憶領域であり、プログラムの実行時のワークエリアなどとして利用される。外部記憶部104は、不揮発性の記憶領域であり、例えば、本願発明に係る処理に用いられる各種プログラムやデータが保持される。表示部105は、各種画面を表示するための部位である。入力部106は、ユーザー等により、各種情報や設定を入力するための部位である。通信部107は、外部装置との通信を行う部位であり、通信方法は有線/無線は問わない。
【0017】
図3は、本願発明に係る車両30のハードウェア構成の例を示す図である。車両30は、処理部301、記憶部302、検知部303、UI部304、通信部305、及び駆動部306を含んで構成される。処理部301は、本実施形態に係る処理の制御全体を司る。なお、上述したように、本実施形態において、車両30は、自動二輪車を例に挙げて説明するが、自動二輪車の走行等の制御は処理部301における処理とは別に構成してよい。
【0018】
記憶部302は、不揮発性の記憶領域であり、本実施形態に係る各種データが保持される。本実施形態では、記憶部302は、車両30に対して着脱可能な可搬媒体として構成され、例えば、情報処理装置20にも接続可能なUSB接続などに対応しているものとする。検知部303は、本実施形態に係る車両30が備える各種動作に対する検知手段(センサ)であり、その種類および機能、検知方法は問わない。検知手段が検知する情報の例としては、アクセルもしくはブレーキの動作、燃料の残量、車体の傾き、走行中もしくは停止中の環境情報(気温、湿度など)、車体に対する衝撃、ハンドルの向き、消耗部材(タイヤや燃料など)の状態などが挙げられる。検知部303にて検知された情報は、生データとして記憶部302に保持されてもよいし、処理部301により加工データとして処理された上で記憶部302に保持されてもよい。
【0019】
UI部304は、車両30におけるユーザー等から各種情報や指示を受け付けるための部位である。通信部305は、外部装置との無線通信を行う部位であり、その通信方式は特に限定しない。また、通信部305を介して送受信するデータや通信タイミングも特に限定するものではない。駆動部306は、車両の走行等に関する駆動および操作を司る部位である。なお、駆動部306には、ハンドルやブレーキなどの部位を含むものとし、ここでの詳細な説明は省略する。
【0020】
なお、本実施形態では、処理部301や記憶部302、UI部304、もしくは通信部305を、車両30が備える構成として説明するがこれに限定するものではない。例えば、車載の装置(カーナビゲーション装置など)や、スマートフォンなどの携帯端末などを用いて、これらの機能を実現するようにしてもよい。
【0021】
[ソフトウェア構成]
図4は、本願発明に係るサーバー10のソフトウェア構成の例を示す図である。サーバー10は、車両状況情報取得部201、運転履歴情報取得部202、蓄積データ処理部203、部品管理部204、車両情報管理部205、ユーザー情報管理部206、メンテナンス予測部207、およびメンテナンス通知部208を含んで構成される。
【0022】
車両状況情報取得部201は、車両30から(もしくは、情報処理装置20を介して)、車両状況情報を取得する。車両状況情報とは、車両30に装着された部品に関する情報(交換時期や消耗度合いを含む)や車両30を管理するユーザーが実際に行ったメンテナンスに関する情報を示す。なおメンテナンスに関する情報には、給油のタイミングや量に関する情報を含んでもよい。また、ここでのメンテナンスに関する情報の提供者は、車両30の管理者(所有者)に限定するものではなく、例えば、メンテナンス作業を請け負った販売店や車検を行う工場等の担当者であってもよい。車両状況情報取得部201は、情報処理装置20を介して情報を取得する場合には、情報処理装置20に対して、Webアプリケーションとしての入力画面を提供し、これを介してデータの入力を受け付けてもよい。
【0023】
運転履歴情報取得部202は、車両30から(もしくは、情報処理装置20を介して)、運転履歴情報を取得する。運転履歴情報とは、ユーザーが車両30に対して行った運転の履歴に関する情報(走行経路、走行距離、運転頻度、操作履歴などを含む)を示す。また、操作履歴には、ブレーキやアクセルの制御、ギアの変更、ハンドルに対する操作、スピードの変化、車体の傾け方、連続乗車時間、運転時の天候などが含まれてもよい。運転履歴情報取得部202は、情報処理装置20を介して情報を取得する場合には、情報処理装置20に対して、Webアプリケーションとしての入力画面を提供し、これを介してデータの入力を受け付けてもよい。
【0024】
蓄積データ処理部203は、複数の車両30から収集(取得)されて蓄積されたデータから、車両(および、車両が備える各部品)に対するメンテナンスに関する指標を生成する。ここでの指標とは、操作履歴と部品の消耗に関する相関関係や、操作履歴に適した部品の種類を特定するための判断基準などが該当する。例えば、蓄積データ処理部203は、蓄積されたデータの中から、同一または類似の車両を有する他のユーザーであって、かつ、車両の利用目的や頻度もしくは操作方法(操作の傾向)が近いユーザーが行ったメンテナンス履歴を特定し、取得する。そして、蓄積データ処理部203は、これらの情報に基づき、適するメンテナンスの時期や対象を判断するための基準を求める(生成する)。なお、相関関係の求め方や、操作履歴に適した部品の種類の求め方は特に限定するものではなく、周知の統計手法や機械学習、ディープラーニング、予め定義された閾値(消費期限情報や経年劣化に関する情報)との比較などにより決定してよい。また、指標は、1つに限定されるものではなく、蓄積データに対する処理に応じて、複数の指標が設けられてもよい。また、用いる蓄積データの種類や、指標の種類を、車両のユーザーが指定できるようにしてもよい。
【0025】
部品管理部204は、各車両に装着可能な各部品の情報を管理する。部品情報としては、例えば、部品のカテゴリー(種類)、性能や用途、消耗度合いの傾向、普及度合い、価格、製造元などが該当する。また、ここでの部品情報とは、タイヤやミラーなどの部品に限定するものではなく、エンジンオイルや燃料の性能などを含めてもよい。また、部品情報は、例えばメーカーが提供している情報の他、蓄積データ処理部203にて処理した情報を踏まえて更新されるようにしてもよい。
【0026】
車両情報管理部205は、各車両の車両情報を管理する。ここでの車両情報とは、車両に固有の情報(製造番号や機種)などの情報が該当する。また、車両情報には、車両ごとの、車両状況情報取得部201にて取得した車両状況情報、および運転履歴情報取得部202にて取得した運転履歴情報を含むものとする。
【0027】
ユーザー情報管理部206は、各車両の管理者であるユーザーのユーザー情報を管理する。ユーザー情報としては、ユーザーの嗜好や、現在所有している車両の情報、これまでに所有した(もしくは、操作したことのある)車両の情報を含んでもよい。もしくは、興味のある車両に関する情報を含んでもよい。ユーザー情報については、ユーザーが予め設定した内容を含んでよく、例えば、後述するメンテナンス通知の通知先情報を含む。
【0028】
メンテナンス予測部207は、部品管理部204、車両情報管理部205、およびユーザー情報管理部206にて管理している情報、および、蓄積データ処理部203にて処理した指標に基づき、車両30に対するメンテナンスに関する予測を行う。ここでの詳細は後述するが、例えば、メンテナンス対象の部品、部位、タイミング(時期)などが予測される。
【0029】
メンテナンス通知部208は、メンテナンス予測部207にて予測された情報に基づいて、ユーザーに対してメンテナンス情報の通知を行う。ここでの通知先は、ユーザー情報管理部206にて管理されているユーザー情報に示されているものとする。通知方法は、メールやレターなどが挙げられるが、これらに限定するものではない。
【0030】
[処理シーケンス]
図5は、本実施形態に係るメンテナンス予測システムにおける処理のシーケンスを示す図である。
【0031】
S501にて、車両30は、車両状況情報および運転履歴情報を適時記録する。なお、各情報の記録は必ずしも同時に行う必要があるものではなく、記録する周期や記録するタイミングはそれぞれ異なっていてよい。記録するタイミングは、予め定義された間隔にて記録するようにしてもよいし、所定の動作(操作)が行わされた際に記録するようにしてもよい。例えば、車両30側にてメンテナンスが行われたこと(例えば、部品が交換されたこと)を検知し、その情報を記録しておいてもよい。
【0032】
S502にて、車両30は、記録した車両状況情報および運転履歴情報をサーバー10に対して送信する。なお、各情報の送信は必ずしも同時に行う必要はなく、いずれか一方のみを送信するようにしてもよい。また、送信するタイミングは、例えば、所定量のデータが蓄積した場合や前回の送信から所定期間が経過したタイミングで送信するようにしてもよい。また、無線通信が可能となったタイミングでまとめて送信してもよいし、分割して送信するようにしてもよい。
【0033】
S511にて、情報処理装置20は、ユーザーからの入力、もしくは、可搬媒体40の接続を介した入力により、車両状況情報および運転履歴情報の入力を受け付ける。
【0034】
S512にて、情報処理装置20は、入力された各情報をサーバー10に対して送信する。なお、送信履歴を情報処理装置20内で管理するようにしてもよい。上述したように、サーバー10が各情報を入力するための画面(例えば、Webアプリケーションによる画面)を情報処理装置20に対して提供するようにしてもよい。
【0035】
S531にて、サーバー10は、任意のタイミングにおいて、ユーザーからのユーザー情報および車両情報の入力および更新を受け付け、登録を行う。ユーザー情報および車両情報の更新タイミングは特に限定するものではなく、ユーザーが必要に応じて行ってよい。
【0036】
S532にて、サーバー10は、部品情報を取得する。部品情報は、サーバー10の管理者やメーカー等が提供する情報を取得するようにしてもよいし、外部サーバー(不図示)と通信を行うことにより定期的に取得するようにしてもよい。
【0037】
S533にて、サーバー10は、車両30もしくは情報処理装置20から送信された各種情報を取得する。取得した情報は、車両情報管理部205において車両30に対応付けて保持する他、情報の種類に応じて分類し、蓄積データとして保持する。
【0038】
S534にて、サーバー10は、蓄積データに対する処理を行う。具体的には、蓄積データ処理部203により、メンテナンスの内容や時期を判定する際に用いられる指標を、蓄積データを用いて生成する。なお、本処理工程は、各種情報を受信したタイミングで行うものに限定するものではない。例えば、前回処理してから所定の時間が経過した際に処理するようにしてもよいし、サーバー10の管理者による指示があった際に実行するようにしてもよい。また、所定量のデータ更新(追加)があった際に実行するようにしてもよい。つまり、時間の経過とともに、複数の車両からデータが逐次収集され、更新されていくため、そのデータの収集状況および処理状況に応じて、後述のメンテナンス予測に用いられる情報(指標)は変化していくこととなる。
【0039】
S535にて、サーバー10は、メンテナンス予測の対象となるある車両30(対象車両)に関し、車両30の各種情報、および、S533にて行った処理により求められた情報(指標)に基づいて、メンテナンスに関する予測処理を行う。本処理の詳細は、図6を用いて後述する。本工程は、S534の処理の実行タイミングとは独立して行われてよく、所定の時間間隔にて実行してもよいし、S532にて各種情報を受信した際に実行してもよい。本実施形態の予測処理は、メンテナンスの内容の他、通知するタイミング(時期)についても決定する。
【0040】
S536にて、サーバー10は、S535の処理により求められたメンテナンス情報をユーザーに対して通知する。ここでは、車両30の情報に対応付けられたユーザー情報が示す通知先にメンテナンス情報を送信するものとする。例えば、ユーザー情報に通知先としてメールアドレスが登録されている場合には、サーバー10は、メンテナンス情報を含むメールを通知先に送信する。本通知のタイミングは、ユーザーが設定した間隔に通知するようにしてもよいし(例えば、一日1回)、緊急度の高い通知については即時に通知するようにしてもよい。
【0041】
S541にて、ユーザーは、任意のタイミングにおいて、ユーザー情報および車両情報の入力および更新を行う。上述したように、ユーザー情報および車両情報の更新タイミングは特に限定するものではなく、ユーザーが必要に応じて行ってよい。また、車両に対するメンテナンスを行った際には、適時入力を行うものとする。また、ここでの入力/更新は、必ずしも車両の管理者(所有者)に限定するものではなく、車両の販売者などが行ってもよい。また、各情報の入力画面は、サーバー10がアプリケーション(例えば、Webアプリケーション)として提供してもよい。また、本実施形態におけるメンテナンス通知に起因してメンテナンスを行った場合には、その情報を併せて登録してもよい。
【0042】
S542にて、ユーザーは、サーバー10から通知されたメンテナンス情報を受信する。例えば、携帯端末(不図示)にて、メールを受信する。更に、ユーザーは受信したメンテナンス情報を表示する。
【0043】
[処理フロー]
(メンテナンス予測処理)
以下、本実施形態に係るサーバー10におけるメンテナンス予測処理について、図6を用いて説明する。本処理フローは、サーバー10において、CPU101が、外部記憶部104等に格納されたプログラムを読み出して実行されることで実現される。なお、以下に示す処理の流れは一例であり、必要に応じて順序を入れ替えてもよい。
【0044】
S601にて、サーバー10は、車両情報管理部205にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両の車両状況情報を取得する。ここで取得する情報は、最新の情報のみを取得してもよいし、所定の範囲での経過情報を含めて取得してもよい。
【0045】
S602にて、サーバー10は、車両情報管理部205にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両の運転履歴情報を取得する。
【0046】
S603にて、サーバー10は、蓄積データ処理部203が蓄積データから生成した指標情報を取得する。指標情報は、車両の車両状況情報や運転履歴情報の中から所定の項目をキーとして、関連する情報のみを取得してもよい。
【0047】
S604にて、サーバー10は、取得した各情報に基づき、車両の状態を推定する。ここでの車両の状態とは、車両状況情報にて示された情報をそのまま車両の状態として扱ってもよいし、複数の項目からある部位(パーツ)や機能の状態を推定してもよい。例えば、タイヤに関し、前回の交換時期、走行距離、ユーザーの車両の利用目的、およびユーザーの操作傾向から、タイヤの状態(例えば、消耗度合い)を推定するようにしてもよい。更に、本工程において、車両を操作するユーザーの特性を特定してもよい。例えば、運転履歴情報が示す走行経路や頻度からその車両の使用目的を推定してもよいし、ユーザーの運転技術の変化(向上、低下)についても推定してよい。また、過去のユーザーのメンテナンス状況や、部品の交換履歴などから、ユーザーの車両に対する収支(お金のかけ具合)を推定し、車両に対する金銭的負担の期待値を推定するようにしてもよい。
【0048】
S605にて、サーバー10は、S604にて推定した車両の状態と、S603にて取得した指標情報とに基づいて、車両に対するメンテナンスの時期および内容の候補を特定する。ここでの候補としては、「ブレーキオイルの補給」を「X日以内」に行う、「タイヤの交換」を「Yヶ月以内」に行う、など同じ部位(部品、消耗品)に限らず複数のメンテナンス内容の候補を特定する。
【0049】
S606にて、サーバー10は、ユーザー情報管理部206にて管理している情報の中から、メンテナンス予測処理を行う対象としての車両のユーザーのユーザー情報を取得する。
【0050】
S607にて、サーバー10は、S606にて特定した候補の中から、ユーザー情報に基づいて、現時点でユーザーに提供するべきメンテナンスの内容を決定する。例えば、緊急度の高いメンテナンスの内容については必ず通知するようにしてもよいし、ユーザーが前回のメンテナンスにて行った部分については通知の優先度を低くして他の通知を優先するようにしてもよい。また、現時点でユーザーがしばらく車両を利用しない旨の設定がなされている場合には、通知を行わないようにしてもよい。
【0051】
S608にて、サーバー10は、決定したメンテナンスの内容に関連する更なる情報の提供を行うか否かを判定する。ここでの判定は、例えば、ユーザーによる設定に基づいてもよいし、メンテナンスの内容に応じて判定してもよい。本実施形態では、更なる情報として、メンテナンスにて利用可能な(交換可能な)部品の情報を提供する例について説明する。更なる情報を提供すると判定した場合には(S608にてYES)S609へ進み、更なる情報を提供しないと判定した場合には(S608にてNO)本処理フローを終了する。
【0052】
S609にて、サーバー10は、部品管理部204が管理する部品情報を取得する。ここでは、メンテナンスの内容やユーザー情報に応じて、取得する情報を決定してもよい。例えば、タイヤのメンテナンスが必要であるとS605にて特定した場合、タイヤに関する情報(例えば、製品名や販売店、性能情報)を取得する。
【0053】
S610にて、サーバー10は、取得した部品情報の中から、メンテナンス情報と併せて提供する情報を決定する。例えば、ユーザー設定にて設定されたユーザーの好みや、推定されたユーザーの特性(技術レベル、使用目的)などに応じて、適する部品の情報を決定する。また、推定したユーザーの特性と同一または類似のユーザーを蓄積データに基づいて特定し、そのユーザーが使用している部品をお勧めの部品として決定してもよい。その後、本処理フローを終了する。
【0054】
[本実施形態に係る情報の例]
本実施形態に係るシステムにて扱う情報の一例について説明する。上述したように本実施形態では、車両に関するメンテナンス通知を行うために、本車両の車両状況情報および運転履歴情報を用いる。更に本車両以外から収集した車両状況情報および運転履歴情報を処理することで得られた情報(指標)、および、部品に関する情報を用いる。
【0055】
車両状況情報としては、以下のような情報が挙げられる。各部品の交換履歴、装着している部品の種類および性能、給油のタイミングおよび回数、など。
【0056】
運転履歴情報としては、以下のような情報が挙げられる。アクセルやブレーキの操作履歴、ギアの変更回数、車体の傾け方、操作中の姿勢、操作中の重心移動、操作回数、操作時間、走行距離、事故(衝撃や振動)の有無、操作頻度、前回操作してから次回操作するまでの時間間隔、走行場所、道路上での走行位置、など。
【0057】
指標情報としては、操作者の運転履歴情報から、その運転者の運転傾向を特定するためのカテゴリー分類が挙げられる。例えば、操作者を複数のカテゴリーA(安全運転傾向)、カテゴリーB(スピード優先傾向)、およびカテゴリーC(あおり運転傾向)など、のようなカテゴリーが挙げられる。これは、蓄積データを処理することで、操作履歴から複数のカテゴリーを生成する。カテゴリーの分類は人が予め与えておいてもよいし、自動生成するようにしてもよい。更に、各カテゴリーに対応付けて、メンテナンスの傾向や利用する部品などを蓄積データから求める。これにより、あるメンテナンス予測を行う対象のユーザーに関し、そのユーザーの操作傾向と指標情報とから、適切なメンテナンス時期や推奨する部品などが特定できる。
【0058】
上記を踏まえ、指標情報としては、例えば、「ある操作傾向のあるユーザー(カテゴリーA)に対し、消耗部品A(例えば、タイヤ)の消耗度合いがX%であると推定される場合には、Y日以内に交換することを推奨する」といった情報でもよい。また、「前回操作してからZヶ月以上経過している場合には、部品Wの交換を推奨する」といった情報でもよい。また、「アクセルの回数に対し、ブレーキの回数が所定割合以上である傾向のユーザーは操作に関する特性をカテゴリーCとする」といった、カテゴリー分けの操作傾向の類似性を指標情報として用いてもよい。
【0059】
部品情報としては、部品の性能および機能、製造元などが該当する。なお、メンテナンス通知において、通知する内容は部品に限定するものではないため、例えば、サービス内容など通知内容に応じて、管理する情報は変更してよい。
【0060】
以上、本実施形態により、車両データと運転者の操作情報に基づいて車両に対する適切なメンテナンスタイミングを判断することで、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とすることができる。
【0061】
<第2の実施形態>
第1の実施形態では、メンテナンス情報の通知先は、ユーザー情報に通知先として設定された車両のユーザー(管理者)に対して行っていた。これに限定せずに、他の所定の通知先にも通知(情報共有)するようにしてもよい。例えば、車両の製造元や、メンテナンスを行うことが可能な工場や販売店などにも通知するようにしてよい。この場合、過去のメンテナンス情報やユーザー情報(好みなど)を併せて提供するようにしてよい。
【0062】
また、通知先としては、ユーザーが登録している通知先の他、ユーザーの操作傾向や頻度などに基づいて、類似性の高い他のユーザーが利用している店へ通知するようにしてもよい。
【0063】
更にこの通知を受け取った通知先は、その情報を利用して、メンテナンスに関する更なるサービス(例えば、好みに合った部品情報の提供やメンテナンススケジュールに対する予約処理の効率化など)を提供するようにしてもよい。
【0064】
これにより、車両のユーザーのみならず他の関係者においても、メンテナンスに関する部品などの情報を得ることができ、メンテナンスの効率を向上せさせることが可能になる。また、車両の操作履歴およびその操作傾向に基づく情報の共有が可能となり、ユーザーの利便性を高めることが可能となる。
【0065】
<その他の実施形態>
上記の実施形態では、部品の消耗等に応じたメンテナンスを行ったが、これに限定するものではない。例えば、事故歴や免許のクラスに応じたメンテナンス情報を提供してもよい。また、ユーザー自身によるメンテナンスの頻度や、工場等によるユーザー以外によるメンテナンスの頻度の割合を考慮して、ユーザーが自分でメンテナンスを行うか否かを考慮し、通知内容を切り替えてもよい。更に、この情報に基づいて、操作傾向のみならず、メンテナンスの傾向(メンテナンス技術)を推定し、通知内容を切り替えてもよい。例えば、乗車自体の頻度は低くても、メンテナンス(例えば、改造など)の頻度が高いようなユーザーについては、その内容に応じた通知を行うようにしてもよい。
【0066】
また、ユーザーから、車両に対して支出可能な予算の情報を予め受け付け、その情報に基づいて部品の情報を提供してもよい。
【0067】
また、車検や自賠責保険の期間など、予め期間が決められているものを考慮し、その期間に近い場合には、メンテナンス情報を送ったり、逆に送らなかったりするようにしてもよい。
【0068】
また、車両が中古車(所有者が複数回変わっている車両)である場合などには、車台番号などに基づいて、その車両自体の履歴を新たなユーザーに引継ぎができるようにしてもよい。
【0069】
また、車両間にて通信を行い、その通信頻度や走行間隔(車間距離)などを含めて、運転履歴情報を記録してもよい。
【0070】
また、第2の実施形態では、情報の共有先の例として、製造元やメンテナンス工場などを例に挙げたが、その他にも、例えば、インターネットショッピングを行うためのECサイトとの連携を行うような構成であってもよい。この場合、ユーザーの操作履歴や好み、操作傾向に併せて、ECサイトから各種商品の情報を提供するような構成が該当する。
【0071】
<実施形態のまとめ>
1.上記実施形態のメンテナンス通知システム(例えば、10)は、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段(例えば、201、202、205)と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段(例えば、203)と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段(例えば、207)と、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段(例えば、208)と
を有することを特徴とする。
【0072】
この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。
【0073】
2.上記実施形態のメンテナンス通知システムは、
前記状況情報は、車両に対してメンテナンスを行った履歴を含み、
前記生成手段は、前記運転履歴情報と前記メンテナンスを行った履歴とに基づいて、車両が備える部品の消耗度合いを推定するための指標情報を生成することを特徴とする。
【0074】
この実施形態によれば、メンテナンスの履歴を反映した、より精度の高いメンテナンス通知を行うことができる。
【0075】
3.上記実施形態のメンテナンス通知システムは、
前記生成手段は、前記運転履歴情報に基づいて、ユーザーの操作の傾向に対応した複数のカテゴリー分けを行うための1または複数の指標情報を生成することを特徴とする。
【0076】
この実施形態によれば、ユーザーの操作の特性ごとのメンテナンス通知を行うことができる。
【0077】
4.上記実施形態のメンテナンス通知システムは、
前記特定手段は、前記運転履歴情報と前記指標情報とに基づいて、前記対象車両のユーザーと、同一または類似の操作の傾向があるユーザーを特定することを特徴とする。
【0078】
この実施形態によれば、自身と同一又は類似のユーザーの情報に基づいて、メンテナンス通知を受けることが可能となる。
【0079】
5.上記実施形態のメンテナンス通知システムは、
前記特定手段は、前記同一または類似の操作の傾向があるユーザーがメンテナンスを行った履歴に基づいて、前記対象車両のメンテナンスを行うべきタイミングを特定することを特徴とする。
【0080】
この実施形態によれば、自身と同一又は類似のユーザーの情報に基づいて、メンテナンス通知を受けることが可能となる。
【0081】
6.上記実施形態のメンテナンス通知システムは、
前記蓄積手段は、インターネット(例えば、60)を介して、前記複数の車両それぞれから前記状況情報および前記運転履歴情報を収集することを特徴とする。
【0082】
この実施形態によれば、メンテナンス通知の際に用いられるデータを、外部ネットワークを介して、より多く収集することが可能となる。
【0083】
7.上記実施形態のメンテナンス通知システムは、
前記状況情報は、前記メンテナンスに関する通知に対して対応を行ったか否かの情報を含むことを特徴とする。
【0084】
この実施形態によれば、メンテナンス通知に対するユーザーの対応結果を収集でき、その情報を反映した更なるメンテナンス通知が可能となる。
【0085】
8.上記実施形態のメンテナンス通知システムは、
前記特定手段は、ユーザーの設定に応じて、メンテナンスを行うべきタイミングを特定する際に用いる指標情報を切り替えることを特徴とする。
【0086】
この実施形態によれば、ユーザーの意向に沿ったメンテナンス通知を行うことができる。
【0087】
9.上記実施形態のメンテナンス通知システムは、
前記特定手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、メンテナンスに関連する部品の情報を特定し(例えば、204)、
前記通知手段は更に、特定した前記部品の情報を通知する
ことを特徴とする。
【0088】
この実施形態によれば、よりユーザーの利便性の高いメンテナンス通知を行うことができる。
【0089】
10.上記実施形態のメンテナンス通知システムは、
前記通知手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、前記対象車両のユーザー以外の通知先に、当該メンテナンスに関する情報を通知すること特徴とする。
【0090】
この実施形態によれば、車両のユーザーとは別のユーザー等においてもメンテナンスに関する情報共有を行うことができる。
【0091】
11.上記実施形態のメンテナンス通知システムの制御方法は、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積工程と、
前記蓄積工程にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成工程と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成工程にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定工程と、
前記特定工程にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知工程と
を有することを特徴とする。
【0092】
この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。
【0093】
12.上記実施形態のプログラムは、
コンピューターを、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを予測するために用いられる指標情報を生成する生成手段、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報と、前記生成手段にて生成した指標情報とに基づいて、当該対象車両のメンテナンスを行うべきタイミングを特定する特定手段、
前記特定手段にて特定したメンテナンスを行うべきタイミングに基づき、当該メンテナンスに関する通知を行う通知手段
として機能させる。
【0094】
この実施形態によれば、車両のユーザーにとってより精度の高いメンテナンス通知の提供を可能とすることができる。
【0095】
本発明は上記実施の形態に制限されるものでは無く、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。
図1
図2
図3
図4
図5
図6

【手続補正書】
【提出日】2018年5月2日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第1の推定手段と、
前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第2の推定手段と、
前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第1の推定手段にて推定された状態と、前記第2の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段と、
前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段と
を有することを特徴とするメンテナンス通知システム。
【請求項2】
請求項1に記載のメンテナンス通知システムであって、
前記状況情報は、車両に対してメンテナンスを行った履歴を含み、
前記生成手段は、前記運転履歴情報と前記メンテナンスを行った履歴とに基づいて、指標情報を生成することを特徴とするメンテナンス通知システム。
【請求項3】
請求項1または2に記載のメンテナンス通知システムであって、
前記生成手段は、前記運転履歴情報に基づいて、ユーザーの操作の傾向に対応した複数のカテゴリー分けを行うための1または複数の指標情報を生成することを特徴とするメンテナンス通知システム。
【請求項4】
請求項1乃至3のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は、前記運転履歴情報と前記指標情報とに基づいて、前記対象車両のユーザーと、同一または類似の操作の傾向があるユーザーを特定することを特徴とするメンテナンス通知システム。
【請求項5】
請求項4に記載のメンテナンス通知システムであって、
前記特定手段は、前記同一または類似の操作の傾向があるユーザーがメンテナンスを行った履歴に基づいて、前記対象車両のメンテナンスを行うべきタイミングを特定することを特徴とするメンテナンス通知システム。
【請求項6】
請求項1乃至5のいずれか一項に記載のメンテナンス通知システムであって、
前記蓄積手段は、インターネットを介して、前記複数の車両それぞれから前記状況情報および前記運転履歴情報を収集することを特徴とするメンテナンス通知システム。
【請求項7】
請求項1乃至6のいずれか一項に記載のメンテナンス通知システムであって、
前記状況情報は、前記メンテナンスに関する通知に対して対応を行ったか否かの情報を含むことを特徴とするメンテナンス通知システム。
【請求項8】
請求項1乃至7のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は、ユーザーの設定に応じて、メンテナンスを行うべきタイミングを特定する際に用いる指標情報を切り替えることを特徴とするメンテナンス通知システム。
【請求項9】
請求項1乃至8のいずれか一項に記載のメンテナンス通知システムであって、
前記特定手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、メンテナンスに関連する部品の情報を特定し、
前記通知手段は更に、特定した前記部品の情報を通知する
ことを特徴とするメンテナンス通知システム。
【請求項10】
請求項1乃至9のいずれか一項に記載のメンテナンス通知システムであって、
前記通知手段は更に、前記対象車両の状況情報および運転履歴情報に基づいて、前記対象車両のユーザー以外の通知先に、当該メンテナンスに関する情報を通知すること特徴とするメンテナンス通知システム。
【請求項11】
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積工程と、
前記蓄積工程にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成工程と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第1の推定工程と、
前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第2の推定工程と、
前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成工程にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第1の推定工程にて推定された状態と、前記第2の推定工程にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定工程と、
前記特定工程にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知工程と
を有することを特徴とするメンテナンス通知システムの制御方法。
【請求項12】
コンピューターを、
複数の車両それぞれの車両の状況情報と、前記複数の車両それぞれに対する運転履歴情報を収集して蓄積する蓄積手段、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第1の推定手段、
前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第2の推定手段、
前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第1の推定手段にて推定された状態と、前記第2の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記選択された指標情報とを用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段、
前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段
として機能させるためのプログラム。
【請求項13】
請求項1乃至10のいずれか一項に記載のメンテナンス通知システムであって、
前記通知手段は、前記メンテナンスに関する通知を当該メンテナンスの対応が可能な通知先へ通知することで、当該通知先における前記メンテナンスの予約処理を要求することを特徴とするメンテナンス通知システム。
【請求項14】
請求項1乃至10のいずれか一項に記載のメンテナンス通知システムであって、
前記メンテナンスに関する通知のタイミングおよび内容は、前記対象車両のユーザーの事故歴、免許の情報、前記対象車両の保険情報、前記対象車両の車検情報、前記対象車両の過去のユーザーの情報の少なくともいずれかに基づいて、制御されることを特徴とするメンテナンス通知システム。
【請求項15】
請求項1乃至10のいずれか一項に記載のメンテナンス通知システムであって、
前記通知手段は、前記メンテナンスに関する通知を当該メンテナンスに用いられる部品の提供が可能な通知先へ通知することで、当該通知先にて提供可能な前記メンテナンスに利用可能な部品に関する情報を前記対象車両のユーザーへ提供するように要求することを特徴とするメンテナンス通知システム。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0002
【補正方法】変更
【補正の内容】
【0002】
る運転履歴情報を収集して蓄積する蓄積手段と、
前記蓄積手段にて蓄積された情報を用いて、メンテナンスを行うべきタイミングを特定するために用いられる指標情報を生成する生成手段と、
メンテナンスの対象となる対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、当該対象車両の状態を推定する第1の推定手段と、
前記対象車両の状況情報に基づいて、当該対象車両のユーザーのメンテナンスの傾向を推定する第2の推定手段と、
前記対象車両の状況情報および運転履歴情報の少なくともいずれかに基づいて、前記生成手段にて生成された指標情報の中から、当該対象車両のメンテナンスを行うべきタイミングを特定する際に用いる指標情報を選択し、前記第1の推定手段にて推定された状態と、前記第2の推定手段にて推定された前記対象車両のユーザーのメンテナンスの傾向と、前記推定された指標情報を用いて前記対象車両のメンテナンスを行うべきタイミングおよび内容を特定する特定手段と、
前記特定手段にて特定したメンテナンスを行うべきタイミングおよび内容に基づき、当該メンテナンスに関する通知を行う通知手段と
を有することを特徴とする。
発明の効果
[0007]
本願発明により、車両の操作者にとってより精度の高いメンテナンス通知の提供を可能とする。
[0008]
発明のその他の特徴及び利点は、添付図面を参照として以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。
図面の簡単な説明
[0009]
添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
図1]本願発明に係るシステム構成の例を示す図。
図2]本願発明に係るサーバーおよび情報処理装置のハードウェア構成の例を示す図。
図3]本願発明に係る車両のハードウェア構成の例を示す図。
図4]本願発明に係るサーバーのソフトウェア構成の例を示す図。
図5]本願発明に係るシステムのシーケンス図。
図6]本願発明に係るサーバーにおける処理を示すフローチャート。
発明を実施するための形態
[0010]
以下、本願発明に係る一実施形態について、図面を用いて説明する。なお、以下に示す構成等は一例であり、これに限定するものではない。
【国際調査報告】