(57)【要約】サービス情報通知システム（１００）は、車両（２０）において用いられる消耗品の交換を推奨するサービス情報を通知する。サービス情報通知システム（１００）は、消耗品の消耗状態データを車両（２０）から取得し、消耗品の次回交換タイミングを予測する。また、サービス情報通知システム（１００）は、車両（２０）と対応付けられたユーザのサービス情報に対する必要度を含むユーザデータを取得する。サービス情報通知システム（１００）は、予測した次回交換タイミングに合わせて、当該必要度が所定値を超えるユーザ（３０）と対応付けられている所定の宛先に対してサービス情報を通知する。
2019180474.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを少なくとも含み、車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムであって、
前記プロセッサは、
前記消耗品の消耗状態を示す消耗状態データを前記車両から取得し、前記メモリに保持させる消耗状態データ取得部と、
前記消耗状態データに基づいて、前記消耗品の次回交換タイミングを予測する交換タイミング予測部と、
前記車両と対応付けられたユーザの前記サービス情報に対する必要度を含むユーザデータを取得し、前記メモリに保持させるユーザデータ取得部と、
前記次回交換タイミングに合わせて、前記必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知する通知部と
を構成するサービス情報通知システム。
【請求項２】
前記プロセッサは、前記車両において現在用いられている前記消耗品のグレード及び前記車両の使用状況の少なくとも何れかを示す関連データを取得し、前記メモリに保持させる関連データ取得部を構成し、
前記交換タイミング予測部は、
前記消耗状態データに基づいて、前記消耗品の次回交換タイミングの標準である標準交換タイミングを予測し、
前記関連データ取得部によって取得された前記関連データを用いて、前記標準交換タイミングを補正する請求項１に記載のサービス情報通知システム。
【請求項３】
前記交換タイミング予測部は、前記グレードが所定値を超える前記消耗品の次回交換タイミングを前記標準交換タイミングよりも遅らせる請求項２に記載のサービス情報通知システム。
【請求項４】
前記交換タイミング予測部は、前記使用状況が所定条件を超える場合、前記消耗品の次回交換タイミングを前記標準交換タイミングよりも早める請求項２に記載のサービス情報通知システム。
【請求項５】
前記通知部は、前記必要度が所定値以下のユーザと対応付けられている所定の宛先に対して、前記標準交換タイミングよりも早いタイミングにおいて、前記サービス情報を通知する請求項２に記載のサービス情報通知システム。
【請求項６】
前記消耗状態データ取得部は、前記消耗品が交換されたことを示す交換済データを取得し、前記メモリに保持させ、
前記通知部は、前記消耗状態データ取得部が前記交換済データを取得した場合、前記サービス情報の通知を中止する請求項１に記載のサービス情報通知システム。
【請求項７】
前記必要度は、前記消耗品の交換コストに対するセンシティビティと、前記車両のメーカーまたはディーラに対するロイヤルティとを含み、
前記通知部は、前記センシティビティの高さと、前記ロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、前記サービス情報を通知する請求項１に記載のサービス情報通知システム。
【請求項８】
車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムにおいて用いられるデータ構造であって、
交換が推奨される前記消耗品の名称データと、
前記消耗品の消耗程度を示す消耗度データと
を含み、
前記サービス情報通知システムが、前記車両から取得された前記消耗品の消耗状態を示す消耗状態データに基づいて前記消耗品の次回交換タイミングを予測し、前記次回交換タイミングに合わせて、前記車両と対応付けられたユーザの前記サービス情報に対する必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知する
処理に用いられるデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システム、及び当該サービス情報通知システムにおいて用いられるデータ構造に関する。
【背景技術】
【０００２】  使用に応じて消耗する自動車の部品（消耗品）の交換タイミングを通知するシステムが知られている（特許文献１参照）。【０００３】  具体的には、車載端末は、前回の消耗品の交換タイミングからの自動車の走行距離を取得し、取得した走行距離と基準データとを比較する。車載端末は、走行距離と基準データとが一致し、かつ情報提供サーバから送信されたサービス情報によって示されるキャンペーン期間に該当する場合、消耗品の交換を推奨する当該サービス情報の着信をドライバ（ユーザ）に報知する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１００１５５号公報
【発明の概要】
【０００５】  上述したシステムでは、消耗品が交換された場合、正規ディーラが、自動車に対して前回の交換タイミングをリセットすることを前提としている。このため、正規ディーラ以外の場所（カー用品店など）において消耗品が交換されると、次回の交換タイミングを判定することが難しくなる。
【０００６】  さらに、消耗品の交換を推奨するサービス情報の必要度は、個々のユーザによって異なる。消耗品を交換する場所（正規ディーラまたはカー用品店）及び実際に消耗品を交換するタイミングは、ユーザによって異なっているためである。
【０００７】  したがって、当該必要度が低いユーザにサービス情報を通知することは、結果的にシステムや通信ネットワークのリソースを浪費する。また、そのようなユーザは、当該サービス情報を煩わしいと感じ得る。
【０００８】  そこで、本発明は、このような状況に鑑みてなされたものであり、前回の交換タイミングを用いることなく、自動車などの車両において用いられる消耗品の交換タイミングを予測し、個々のユーザに対して、より適切なタイミングに消耗品の交換を推奨し得るサービス情報通知システム、及び当該サービス情報通知システムにおいて用いられるユーザデータのデータ構造の提供を目的とする。
【０００９】  本発明の一態様に係わるサービス情報通知システムは、車両において用いられる消耗品の交換を推奨するサービス情報を通知する。サービス情報通知システムは、消耗品の消耗状態データを車両から取得し、メモリに保持させ、消耗品の次回交換タイミングを予測する。また、サービス情報通知システムは、車両と対応付けられたユーザのサービス情報に対する必要度を含むユーザデータを取得し、メモリに保持させる。サービス情報通知システムは、予測した次回交換タイミングに合わせて、必要度が所定値を超えるユーザと対応付けられている所定の宛先に対してサービス情報を通知する。
【図面の簡単な説明】
【００１０】
【図１】  図１は、サービス情報通知システム１００を含む車両管理ネットワーク１０の全体概略構成図である。
【図２】  図２は、消耗状態データの取得に関連する車両２０の機能ブロック構成図である。
【図３】  図３は、サービス情報通知システム１００の機能ブロック構成図である。
【図４】  図４は、サービス情報通知システム１００を含む車両管理ネットワーク１０によるサービス情報の通知フローを示す図である。
【図５】  図５は、エンジンオイルの次回交換タイミングの補正動作フローを示す図である。
【図６】  図６は、バッテリの次回交換タイミングの補正動作フローを示す図である。
【図７】  図７は、タイヤの次回交換タイミングの補正動作フローを示す図である。
【図８】  図８は、消耗品の次回交換タイミングの予測に用いられる劣化モデルの例を示す図である。
【図９Ａ】  図９Ａは、顧客ＤＢ２００に蓄積されるデータベースの構成例を示す図である。
【図９Ｂ】  図９Ｂは、ユーザデータのデータ構造の例（その１）を示す図である。
【図９Ｃ】  図９Ｃは、ユーザデータのデータ構造の例（その２）を示す図である。
【図１０】  図１０は、サービス情報の必要度クラスの構成例を示す図である。
【図１１Ａ】  図１１Ａは、サービス情報のデータ構造の例（その１）を示す図である。
【図１１Ｂ】  図１１Ｂは、サービス情報のデータ構造の例（その２）を示す図である。
【図１１Ｃ】  図１１Ｃは、サービス情報のデータ構造の例（その３）を示す図である。
【図１２】  図１２は、端末装置３５に表示されるサービス情報の例を示す図である。
【発明を実施するための形態】
【００１１】  以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。
【００１２】  （サービス情報通知システムを含む車両管理ネットワークの全体構成）
【００１３】  図１は、サービス情報通知システム１００を含む車両管理ネットワーク１０の全体概略構成図である。
【００１４】  図１に示すように、車両管理ネットワーク１０は、車両２０、端末装置３５、端末装置５５、ネットワーククラウド６０、サービス情報通知システム１００及び顧客データベース２００（以下、顧客ＤＢ２００）を含む。
【００１５】  車両管理ネットワーク１０は、車両２０の状態を管理する。特に、本実施形態では、車両管理ネットワーク１０は、車両２０において用いられる消耗品（エンジンオイル、バッテリ及びタイヤなど）の消耗状態を管理し、当該消耗品の交換を車両２０のユーザ３０に対して推奨する。
【００１６】  車両２０は、無線通信機能を用いてサービス情報通知システム１００と無線通信を実行することができる。車両２０は、典型的には、四輪の乗用自動車（ミニバン及びＳＵＶを含む）だが、トラック及びバスでもよい。
【００１７】  本実施形態では、車両２０は、エンジン（内燃機関）を備えている。但し、車両２０は、ハイブリッド車でもよいし、電気自動車としても構わない。車両２０は、消耗品の消耗状態を検出できるセンサを備えている。
【００１８】  ユーザ３０は、車両２０を日常的に使用する者、典型的には、車両２０のドライバーである。なお、ユーザ３０は、車両２０のメンテナンスに対する権限を有する者であれば、必ずしも車両２０を日常的に使用する者でなくても構わない。
【００１９】  端末装置３５は、ユーザ３０と対応付けられており、サービス情報通知システム１００から通知される車両２０関連のサービス情報を受信することができる。端末装置３５としては、ユーザ３０が使用する携帯電話端末またはタブレット型のパーソナルコンピュータが挙げられる。なお、ユーザ３０と対応付けられていれば、端末装置３５は、デスクトップ型のパーソナルコンピュータなどでも構わない。
【００２０】  端末装置３５は、ユーザ３０を一意に識別可能な電子メールアドレス宛ての情報を受信及び表示などすることができる。
【００２１】  ディーラ５０は、車両２０の販売、販売後のサービス及びメンテナンスを提供する。ディーラ５０は、自動車販売店（新車）であり、特定の自動車メーカーの車両のみを扱ってもよいし、複数の自動車メーカーの車両を扱ってもよい。
【００２２】  端末装置５５は、ディーラ５０（店舗）に配備されているパーソナルコンピュータまたは携帯型通信端末である。端末装置５５は、車両２０の消耗品の交換記録、及びユーザ３０の属性（後述する価格センシティビティ及びロイヤルティなど）の入力に用いられる。
【００２３】  ネットワーククラウド６０は、有線通信または無線通信によって情報伝送を可能にする通信ネットワークである。ネットワーククラウド６０は、典型的にはインターネットを含み、インターネット上において提供される各種の情報提供サービス（気象、交通渋滞など）、ストレージサービス、及びアプリケーションサービスなどを含む。車両管理ネットワーク１０に含まれる各エンティティ（車両２０、端末装置３５、端末装置５５、サービス情報通知システム１００及び顧客ＤＢ２００）間の通信もネットワーククラウド６０経由で提供されても構わない。また、サービス情報通知システム１００及び顧客ＤＢ２００の機能の一部または全部は、ネットワーククラウド６０上で提供される当該サービスによって、仮想的に提供されても構わない。
【００２４】  サービス情報通知システム１００は、車両２０関連のサービス情報を通知する。特に、本実施形態では、サービス情報通知システム１００は、車両２０において用いられる消耗品の交換を推奨するサービス情報を通知する。
【００２５】  具体的には、サービス情報通知システム１００は、車両２０から取得した消耗品の消耗状態を示すデータ（消耗状態データ）に基づいて、当該消耗品の次回交換タイミングを予測する。サービス情報通知システム１００は、予測された次回交換タイミングに合わせて、サービス情報に対する必要度が高いユーザ（具体的には、当該ユーザと対応付けられている端末装置）に対してサービス情報を通知する。
【００２６】  顧客ＤＢ２００は、車両２０のユーザ３０（顧客）に関する情報が蓄積されるデータベースである。特に、本実施形態では、顧客ＤＢ２００は、車両２０の消耗品の交換履歴に関する情報、及びユーザ３０の属性に関する情報（図９参照）を蓄積する。
【００２７】  なお、顧客ＤＢ２００は、ディーラ５０主導で構築されてもよいし、車両２０のメーカー主導で構築されても構わない。
【００２８】  （車両及びサービス情報通知システムの機能ブロック構成）
【００２９】  次に、消耗状態データの取得に関連する車両２０の機能ブロック構成、及びサービス情報通知システム１００の機能ブロック構成について説明する。
（１）車両２０
【００３０】  図２は、消耗状態データの取得に関連する車両２０の機能ブロック構成図である。つまり、図２は、サービス情報通知システム１００が、車両２０において用いられている消耗品の消耗状態データを取得するために関連する機能ブロックのみを示している。
【００３１】  図２に示すように、車両２０は、通信部２１、消耗状態測定部２３、車両使用状況取得部２４及びインフォティメントシステム２５を備える。
【００３２】  通信部２１は、車両２０近傍のアクセスポイント（無線基地局など）と無線信号を送受信し、当該アクセスポイントを経由してサービス情報通知システム１００などと通信を実行する。
【００３３】  通信部２１は、通信モジュールとして車両２０に備えられてもよいし、ユーザ３０が使用する端末装置３５を用いて実現してもよい。端末装置３５を用いて実現する場合、典型的には、４Ｇ（ＬＴＥ）などの移動通信ネットワークの利用が挙げられる。なお、他の無線通信方式（無線ＬＡＮなど）であっても構わない。
【００３４】  消耗状態測定部２３は、車両２０において用いられている各種消耗品の消耗状態を測定する。本実施形態では、消耗品として、エンジンオイル、バッテリ及びタイヤを対象としている。
【００３５】  但し、消耗品は、このような例に限られず、比較的交換頻度が高い消耗品としては、エアコンのフィルタ、ワイパーブレード、ブレーキパッド、エンジンオイルフィルタなども含まれる。また、広義には、ファンベルト、タイミングベルト、スパークプラグ、ショックアブソーバー、クラッチ、ウォーターポンプなども含まれる。
【００３６】  具体的には、消耗状態測定部２３は、エンジンオイルの消耗状態（劣化状態と呼んでもよい）の指標として、ブローバイガス中の炭化水素（ＨＣ）の発生量を測定する。
【００３７】  消耗状態測定部２３は、バッテリの消耗状態（劣化状態と呼んでもよい）の指標として、バッテリの内部抵抗（Ｓｔａｔｅ  ｏｆ  Ｈｅａｌｔｈ）をする。なお、車両２０において用いられるバッテリの種類は、特に限定されない。具体的には、バッテリ液を補充可能なタイプまたは補充できないタイプ（メンテナンスフリー）、及びドライバッテリが含まれる。また、ハイブリッド車用の補機バッテリも含まれる。
【００３８】  消耗状態測定部２３は、タイヤの消耗状態（摩耗状態と呼んでもよい）の指標として、車両２０の駆動輪と従動輪との回転差から求められるスリップ率を測定する。なお、ＨＣ、ＳｏＨ及びスリップ率の具体的な測定方法については、さらに後述する。
【００３９】  消耗状態測定部２３は、車両２０の識別情報を含む消耗状態データを、通信部２１を介してサービス情報通知システム１００に送信する。車両２０の識別情報は、車台番号または自動車登録番号（ライセンスプレート）を用い得るが、車両２０を一意に識別できれば、他の情報を用いても構わない。
【００４０】  また、消耗状態測定部２３は、車両２０において消耗品が交換され、当該消耗品の交換タイミングがリセットされた場合、当該消耗品が交換されたことを示す交換済データを、通信部２１を介してサービス情報通知システム１００に送信することができる。
【００４１】  車両使用状況取得部２４は、車両２０の使用状況を取得する。具体的には、車両使用状況取得部２４は、車両２０に備えられているセンサ群から提供される信号に基づいて、加速Ｇ・減速Ｇ、角速度（ヨーレート）、操舵量、スロットル開度及びブレーキ圧など、車両２０の使われ方を示す情報を取得する。
【００４２】  また、車両使用状況取得部２４は、当該センサ群を用いて車両２０の積載重量を算出（推定）すること、及び車両２０に搭載されているバッテリの充放電回数を取得することができる。なお、ここでいう「積載重量」とは、車両２０の乗員及び車両２０に積載される荷物などの合計重量を意味する。
【００４３】  インフォティメントシステム２５は、車両２０に備えられ、カーナビゲーション、オーディオビジュアル（ＡＶ）、ネットワーククラウド６０との連携した情報提供サービスなどの機能を提供する。
【００４４】  特に、本実施形態では、インフォティメントシステム２５は、サービス情報通知システム１００から送信されるサービス情報を表示することができる。
（２）サービス情報通知システム１００
【００４５】  図３は、サービス情報通知システム１００の機能ブロック構成図である。図３に示すように、サービス情報通知システム１００は、消耗状態データ取得部１１０、ユーザデータ取得部１２０、関連データ取得部１３０、交換タイミング予測部１４０及び通知部１５０を備える。
【００４６】  サービス情報通知システム１００は、プロセッサ、メモリ、入力デバイス、ディスプレイ及び通信インタフェース（通信ＩＦ）を備える汎用のサーバコンピュータ上においてプログラム（ソフトウェア）を実行することによって実現される。なお、上述したように、サービス情報通知システム１００の一部（または全部）は、ネットワーククラウド６０上で提供されても構わない。
【００４７】  消耗状態データ取得部１１０は、消耗品の消耗状態を示す消耗状態データ（ＨＣ、ＳｏＨ及びスリップ率）を車両２０から取得する。また、消耗状態データ取得部１１０は、取得した消耗状態データをメモリに保持させる。
【００４８】  また、消耗状態データ取得部１１０は、車両２０において、消耗品が交換されたことを示す交換済データを車両２０から取得し、取得した交換済データをメモリに保持させることができる。なお、消耗状態データ取得部１１０は、交換済データを顧客ＤＢ２００経由で取得してもよい。
【００４９】  ユーザデータ取得部１２０は、車両２０と対応付けられたユーザ３０に関するデータであるユーザデータを取得する。本実施形態では、ユーザデータ取得部１２０は、顧客ＤＢ２００からユーザ３０のユーザデータを取得する。なお、ユーザデータ取得部１２０は、一部のユーザデータについては、ネットワーククラウド６０上のサービスから取得してもよい。
【００５０】  特に、ユーザデータ取得部１２０は、ユーザ３０のサービス情報に対する必要度を含むユーザデータを取得し、取得したユーザデータをメモリに保持させる。「サービス情報に対する必要度」とは、ユーザ３０が、消耗品の交換を推奨するサービス情報をどの程度必要としているかを意味する。
【００５１】  また、本実施形態では、当該必要度は、ユーザ３０の消耗品の交換コスト（作業工賃も含む総価格）に対するセンシティビティ（以下、本実施形態では、価格センシティビティと呼ぶ）と、車両２０のメーカーまたはディーラに対するロイヤルティとを含む。なお、必要度の具体的な内容についてはさらに後述する。
【００５２】  ユーザデータ取得部１２０が取得するユーザデータは、車両２０と対応付けられたユーザ３０の識別情報と、当該必要度とを含む。ユーザ３０の識別情報としては、典型的には、ユーザ３０を一意に識別可能な電子メールアドレスが挙げられる。但し、ユーザ３０（実際には、ユーザ３０が使用する端末装置３５など）を一意に識別できる情報であれば、電子メールアドレス以外でも構わない。
【００５３】  関連データ取得部１３０は、車両２０において現在用いられている消耗品のグレード及び車両２０の使用状況の少なくとも何れかを示すデータ（以下、関連データ）を取得し、取得した関連データをメモリに保持させる。
【００５４】  具体的には、関連データ取得部１３０は、消耗品のグレードを示すデータについては、顧客ＤＢ２００から取得する。
【００５５】  ここでは、「グレード」は、消耗品の種類及び等級を含むものとして定義する。また、エンジンオイルの場合、グレードには、エンジンオイルとは別個の添加剤の有無が含まれ、タイヤの場合、グレードには、タイヤの種別（サマータイヤ、ウインター（スタッドレス）タイヤ、低転がり抵抗（ＲＲ）タイヤ）及びタイヤサイズ（トレッド幅、偏平率及びタイヤ径）が含まれる。
【００５６】  また、関連データ取得部１３０は、車両２０の使用状況を示すデータについては、車両２０またはネットワーククラウド６０から取得する。
【００５７】  ここでは、「使用状況」とは、車両２０が走行する地域に関する情報（気候（気温、湿度、日射量）、地形及び道路構成など）、及び車両２０の使われ方に関する情報（加速Ｇ・減速Ｇ、積載重量、操舵量及びバッテリの充放電回数など）を含むものとして定義する。
【００５８】  なお、車両２０（またはネットワーククラウド６０）は、当該情報を直接的または間接的に検出できる機能を備えている。
【００５９】  交換タイミング予測部１４０は、取得した消耗状態データに基づいて、消耗品の次回交換タイミングを予測する。具体的には、交換タイミング予測部１４０は、消耗品の種別毎の劣化モデル（図８参照）を用いて、当該消耗品の次回交換タイミングを予測する。なお、本実施形態に係る消耗品（エンジンオイル、バッテリ及びタイヤ）毎の次回交換タイミングの予測方法については、さらに後述する。
【００６０】  また、交換タイミング予測部１４０は、このように予測した次回交換タイミングを、当該消耗品の次回交換タイミングの標準である標準交換タイミングとして用いる。つまり、交換タイミング予測部１４０は、取得した消耗状態データに基づいて、当該消耗品の次回交換タイミングの標準である標準交換タイミングを予測する。
【００６１】  さらに、交換タイミング予測部１４０は、関連データ取得部１３０によって取得された関連データ（消耗品のグレード、及び車両２０の使用状況）を用いて、当該標準交換タイミングを補正する。
【００６２】  具体的には、交換タイミング予測部１４０は、グレードが所定値を超える消耗品、つまり、グレードが高く、ライフタイムが標準よりも長いと想定される消耗品の次回交換タイミングを標準交換タイミングよりも遅らせることができる。
【００６３】  逆に、交換タイミング予測部１４０は、グレードが低く、ライフタイムが標準よりも短いと想定される消耗品の次回交換タイミングを標準交換タイミングよりも早めることができる。
【００６４】  同様に、交換タイミング予測部１４０は、使用状況が所定条件を超える場合、つまり、車両２０の使用状況がシビアであり、消耗が進行し易いと考えられる場合、当該消耗品の次回交換タイミングを標準交換タイミングよりも早めることができる。
【００６５】  逆に、交換タイミング予測部１４０は、車両２０の使用状況がマイルドであり、消耗が遅いと考えられる場合、当該消耗品の次回交換タイミングを標準交換タイミングより遅らせることができる。
【００６６】  通知部１５０は、ユーザ３０と対応付けられている所定の宛先（本実施形態では、端末装置３５）に対してサービス情報を通知する。具体的には、通知部１５０は、交換タイミング予測部１４０によって予測された消耗品の次回交換タイミングに合わせて、上述したサービス情報の必要度が所定値を超えるユーザを対象として、サービス情報を通知する。
【００６７】  より具体的には、通知部１５０は、価格センシティビティの高さと、ロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、サービス情報を通知することができる。
【００６８】  通知部１５０は、予測された次回交換タイミングを基準とした前後の所定時間（例えば、１週間〜１ヶ月）内にサービス情報を通知する。なお、車両２０に備えられているインフォティメントシステム２５が所定の宛先として対応付けられている場合、通知部１５０は、インフォティメントシステム２５に対してサービス情報を通知する。
【００６９】  本実施形態では、サービス情報は、交換が推奨される消耗品の名称と、当該消耗品の消耗程度（劣化程度）とを示すデータによって構成れる。但し、当該消耗品の消耗程度を示すデータは、必ずしも必須ではない。
【００７０】  また、サービス情報は、当該消耗品の交換期限、または当該消耗品などの価格を値引きするクーポンの情報を含んでもよい。
【００７１】  また、通知部１５０は、ディーラ５０での消耗品の交換を促すため、上述したサービス情報の必要度が所定値以下のユーザと対応付けられている所定の宛先（端末装置）に対して、交換タイミング予測部１４０によって予測された標準交換タイミングよりも早いタイミングにおいて、サービス情報を通知することができる。
【００７２】  なお、通知部１５０は、消耗品が交換されたことを示す交換済データが消耗状態データ取得部１１０によって取得された場合、サービス情報の通知を中止する。つまり、通知部１５０は、予測された次回交換タイミングを基準とした前後の所定時間内であっても、交換済データが取得された場合には、サービス情報を通知しない。
【００７３】  （サービス情報通知システムの動作）
【００７４】  次に、サービス情報通知システム１００の動作について説明する。具体的には、サービス情報通知システム１００を含む車両管理ネットワーク１０によるサービス情報の通知動作、及び消耗品の次回交換タイミングを補正する動作について説明する。
（１）サービス情報の通知
【００７５】  図４は、サービス情報通知システム１００を含む車両管理ネットワーク１０によるサービス情報の通知フローを示す。
【００７６】  図４に示すように、車両２０は、消耗品の消耗状態を測定する（Ｓ１０）。本実施形態では、車両２０は、エンジンオイル、バッテリ及びタイヤの消耗状態を測定する。各消耗品の具体的な消耗状態の測定方法は、上述したとおりである（図２の消耗状態測定部２３に関する説明を参照）。なお、次回交換タイミング（標準交換タイミング）を含めたＨＣ、ＳｏＨ及びスリップ率の具体的な測定方法については、後述する。
【００７７】  車両２０は、消耗状態の測定結果に基づいて、消耗品の消耗状態を示す消耗状態データをサービス情報通知システム１００に送信する（Ｓ２０）。消耗状態データには、車両２０の識別情報が含まれる。
【００７８】  また、車両２０は、車両２０が発生する加速Ｇ・減速Ｇ、車両２０への積載重量など、車両２０の使用状況を示すデータ（関連データ）をサービス情報通知システム１００に送信してもよい。
【００７９】  サービス情報通知システム１００は、消耗状態データを受信する（Ｓ３０）。サービス情報通知システム１００は、受信した消耗状態データに基づいて、消耗品の次回交換タイミングを予測する（Ｓ３５）。
【００８０】  ここで、図８は、消耗品の次回交換タイミングの予測に用いられる劣化モデルの例を示す。図８の横軸は時間を示し、縦軸は消耗品の劣化度合を示す。
【００８１】  サービス情報通知システム１００は、車両２０から繰り返し送信される消耗状態データの値に基づいて、劣化モデルにおける現状値を特定する。なお、「劣化モデル」は、消耗品毎にデフォルトで規定されたモデルでもよいし、取得した大量の消耗状態データを用いて学習し、適宜更新されるモデルでもよい。
【００８２】  サービス情報通知システム１００は、所定の消耗状態データの値と対応付けられている劣化度合を消耗品の交換推奨レベルとして保持している。サービス情報通知システム１００は、劣化モデルに基づいて、当該交換推奨レベルに到達するタイミングを次回交換タイミング、具体的には、標準交換タイミングｔｓとして予測する。
【００８３】  なお、サービス情報通知システム１００は、ユーザ３０のサービス情報に対する必要度、消耗品のグレード、または車両２０の使用状況に応じて、標準交換タイミングｔｓを交換タイミングｔ１（早める場合）または交換タイミングｔ２（遅らせる場合）に補正することができる。
【００８４】  サービス情報通知システム１００は、予測した次回交換タイミングに基づいて、当該消耗品の交換が必要か否かを判定する（Ｓ４０）。
【００８５】  具体的には、サービス情報通知システム１００は、現時点と、予測した次回交換タイミングの時点とが所定時間内であれば、当該消耗品の交換が必要と判定する。
【００８６】  サービス情報通知システム１００は、当該消耗品の交換が必要と判定した場合、顧客ＤＢ２００に対してユーザデータを要求する（Ｓ５０）。
【００８７】  具体的には、サービス情報通知システム１００は、車両２０の識別情報を顧客ＤＢ２００に送信し、車両２０の識別情報と対応付けられているユーザ３０のユーザデータを要求する。
【００８８】  顧客ＤＢ２００は、サービス情報通知システム１００からの要求に応じて、ユーザ３０のユーザデータをサービス情報通知システム１００に送信する（Ｓ６０）。ここで、図９Ａは、顧客ＤＢ２００に蓄積されるデータベースの構成例を示す。
【００８９】  図９Ａに示す例では、当該データベースは、「車両識別情報」（例えば、車台番号、）、「ユーザ識別情報」（例えば、電子メールアドレス）、「来店日」、「作業内容」、「価格センシティビティ（価格Ｓｅｎｓ．）」、「ロイヤルティ」及び「サービス情報必要度クラス」の項目を含む。
【００９０】  顧客ＤＢ２００は、図９Ａに示したデータベースの内容に基づいて、ユーザ３０のユーザデータをサービス情報通知システム１００に送信する。
【００９１】  図９Ｂ及び図９Ｃは、ユーザデータのデータ構造の例を示す。顧客ＤＢ２００は、図９Ｂに示すように、「ユーザ識別情報」（ａａａａ＠ｘｘｘ）と、「サービス情報必要度クラス」（１）とを含むユーザデータを送信することができる。或いは、顧客ＤＢ２００は、図９Ｃに示すように、「ユーザ識別情報」（ａａａａ＠ｘｘｘ）と、「価格センシティビティ」（Ｌｏｗ）と、「ロイヤルティ」（Ｈｉｇｈ）とを含むユーザデータを送信することもできる。
【００９２】  サービス情報通知システム１００は、当該ユーザデータを受信する（Ｓ７０）。サービス情報通知システム１００は、受信したユーザデータに基づいて、ユーザ３０に対してサービス情報を通知するか否かを判定する（Ｓ８０）。
【００９３】  具体的には、サービス情報通知システム１００は、図９Ｂに示したユーザデータに含まれている「サービス情報必要度クラス」の値が所定値（例えば、サービス情報必要度クラス＝１）と一致する場合、サービス情報を通知すると判定する。
【００９４】  或いは、サービス情報通知システム１００は、図９Ｃに示したユーザデータに含まれている「価格センシティビティ」の高さと、「ロイヤルティ」の高さとの組合せに基づいて、「サービス情報必要度クラス」を判定してもよい。
【００９５】  図９Ｂ及び図９Ｃに示した何れのデータ構造のうち、何れを用いるかは、価格センシティビティ及びロイヤルティの段階数、または必要度を設定したいクラスの範囲などに応じて定めてもよい。
【００９６】  図１０は、サービス情報の必要度クラスの構成例を示す。図１０に示すように、サービス情報の必要度クラスは、消耗品に対する価格センシティビティと、車両２０のメーカーまたはディーラに対するロイヤルティとの組合せによって構成される。
【００９７】  図１０に示す例では、価格センシティビティ及びロイヤルティとも３段階（Ｌｏｗ（Ｌ），Ｍｉｄ（Ｍ），Ｈｉｇｈ（Ｈ））に設定されている。例えば、価格センシティビティ＝Ｌｏｗ、ロイヤルティ＝Ｈｉｇｈの組合せは、必要度クラス＝１（ディーラ５０での交換可能性が最も高いクラス）と分類される。以下、同様に、必要度クラス２〜９に分類される。例えば、価格センシティビティ＝Ｈｉｇｈ、ロイヤルティ＝Ｌｏｗの組合せは、必要度クラス＝９（図１０において黒丸で表示、ディーラ５０での交換可能性が最も低いクラス）と分類される。
【００９８】  サービス情報通知システム１００は、サービス情報を通知すると判定した場合、ユーザ３０と対応付けられた所定の宛先、具体的には、ユーザ３０の電子メールアドレス宛てのメールを受信可能な端末装置３５に対してサービス情報を送信する（Ｓ９０）。
【００９９】  サービス情報通知システム１００は、サービス情報を直接表示する電子メールを送信してもよいし、サービス情報の詳細を表示する特定のサイトへのリンクを送信してもよい。
【０１００】  或いは、サービス情報通知システム１００は、端末装置３５にインストールされている専用のアプリケーションに対してサービス情報を送信してもよい。なお、当該サービス情報には、消耗品の消耗程度（劣化程度）を示す情報を含んでもよい。
【０１０１】  また、サービス情報通知システム１００は、当該消耗品が交換されたことを示す交換済データを、車両２０または顧客ＤＢ２００から取得した場合、ステップＳ４０において、当該消耗品の交換が必要と判定した場合でも、サービス情報の送信を中止する。
【０１０２】  また、本動作例では、サービス情報通知システム１００は、ディーラ５０に配備される端末装置５５に対しても同様のサービス情報を送信する。なお、このサービス情報は、端末装置３５に送信されるサービス情報の複製でもよいし、ユーザ３０に対してサービス情報を発行したことを示す発行通知でも構わない。
【０１０３】  端末装置５５は、当該サービス情報（または発行通知）を受信する（Ｓ１００）。同様に、端末装置３５も、当該サービス情報を受信する（Ｓ１１０）。
【０１０４】  図１１Ａ〜図１１Ｃは、サービス情報のデータ構造の例を示す。サービス情報通知システム１００は、図１１Ａに示すように、交換が推奨される消耗品の名称データ（エンジンオイル）と、当該消耗品の消耗程度（劣化程度）を示す消耗度データ（レベル２）とを含むサービス情報を送信することができる。
【０１０５】  また、サービス情報通知システム１００は、図１１Ｂに示すように、複数の消耗品の名称データと、消耗度データとを含むサービス情報を送信することができる。この場合、一部の消耗品（ここでは、バッテリ）については、必ずしも交換が推奨されるものでなくても構わない。つまり、特定の消耗品の交換が推奨される場合、合わせて他の消耗品の消耗程度をユーザ３０（具体的には、端末装置３５またはインフォティメントシステム２５）に通知するようにしてもよい。
【０１０６】  さらに、サービス情報通知システム１００は、図１１Ｃに示すように、当該消耗品の価格、或いは関連する他の消耗品またはサービス（工賃など）を値引く、無料にする、或いは特典を与えるクーポンを含むサービス情報を送信することができる。
【０１０７】  また、当該サービス情報には、当該消耗品の交換期限（図１１Ｃの「２０１８／０３／３１」）が含まれてもよい。なお、当該交換期限は、当該消耗品の消耗程度に基づいて決定されるものでもよいし、当該クーポンの適用可能期限と対応付けられているものでもよい。
【０１０８】  図１２は、端末装置３５に表示されるサービス情報の例を示す。図１２に示すように、サービス情報は、消耗品（エンジンオイル）の交換を推奨するメッセージを含む。さらに、図１２に示す例では、サービス情報は、価格を値引きする（１０％オフ）クーポンの機能も有している。なお、クーポンの機能は必須ではない。
【０１０９】  また、サービス情報は、消耗品の消耗程度（劣化程度）を示す情報（「エンジンオイルの劣化レベルは「２」です」）を含んでいる。
【０１１０】  その後、車両２０がディーラ５０に入庫し、当該消耗品（エンジンオイル）の交換が完了すると、ディーラ５０の作業者は、車両２０が保持している前回のエンジンオイルの交換タイミングをリセットし、交換記録（交換日、グレードなど）を、端末装置５５を用いて入力する（Ｓ１２０）。入力された交換記録は、顧客ＤＢ２００に反映される。
【０１１１】  また、ディーラ５０の作業者は、ユーザ３０の属性、具体的には、価格センシティビティ及びロイヤルティを入力してもよい。或いは、ユーザ３０の属性は、入庫日、選択した消耗品のグレード、過去の交換記録などから、自動または半自動で入力されるようにしてもよい。
【０１１２】  さらに、サービス情報通知システム１００は、ディーラ５０への来店頻度の低いユーザに対しては、標準交換タイミングｔｓを交換タイミングｔ１に早めるようにしてもよい。
【０１１３】  また、ディーラ５０において車両２０を点検した場合、消耗品の消耗状態（例えば、ブレーキパッド、タイヤの溝残量）に基づいて車両の使い方をランク分けし、使用状況がシビアと想定されるユーザに対しても、標準交換タイミングｔｓを交換タイミングｔ１に早めるようにしてもよい。
【０１１４】  また、サービス情報通知システム１００は、ディーラ５０だけでなく、ディーラ５０の周辺に存在する他のディーラにもサービス情報（または発行通知）を送信するようにしてもよい。
（２）次回交換タイミングの補正動作
【０１１５】  次に、図５〜図７を参照して、消耗品の次回交換タイミングの補正動作について説明する。具体的には、エンジンオイル、バッテリ及びタイヤの次回交換タイミングの補正動作について説明する。図５〜図７は、エンジンオイル、バッテリ及びタイヤの次回交換タイミングの補正動作フローについてそれぞれ示す。
【０１１６】  なお、図５〜図７に示す動作フローは、何れも図４に示した次回交換タイミングの予測処理（Ｓ３５）のサブフローとして実行されるものであり、必ずしも必須ではない。
（２．１）エンジンオイル
【０１１７】  図５は、エンジンオイルの次回交換タイミングの補正動作フローを示す。図５に示すように、サービス情報通知システム１００は、ブローバイガス中の炭化水素（ＨＣ）の発生量を取得する（Ｓ２１０）。車両２０は、エンジンのクランクケース内のブローバイガスに含まれるＨＣを検出する検出器を備える。また、車両２０は、発生するブローバイガス量（排ガス量）を、エンジン（冷却水）の水温、回転数及び充填効率に基づいて推定する。
【０１１８】  サービス情報通知システム１００は、エンジンオイルの標準交換タイミングｔｓ（図８参照）を予測する（Ｓ２２０）。当該予測方法は、上述したとおりである。
【０１１９】  サービス情報通知システム１００は、エンジンオイルに添加された添加剤の有無、及び添加剤の種類を取得する（Ｓ２３０）。添加剤の有無及び種類は、上述したように、消耗品の「グレード」に該当する。
【０１２０】  サービス情報通知システム１００は、車両２０の「使用状況」を取得する（Ｓ２４０）。ここでは、サービス情報通知システム１００は、車両２０が主に走行する地域及び気温の情報を取得する。また、サービス情報通知システム１００は、車両２０の加速Ｇ・減速Ｇなどを取得してもよい。上述したように、地域及び気温の情報は、顧客ＤＢ２００から取得されてもよいし、ネットワーククラウド６０上のサービス経由で取得されてもよい。
【０１２１】  サービス情報通知システム１００は、添加剤の有無及び種類と、車両２０の使用状況に基づいて、標準交換タイミングｔｓを補正する（Ｓ２５０）。
【０１２２】  具体的には、上述したように、サービス情報通知システム１００は、消耗品の「グレード」または「使用状況」に基づいて、標準交換タイミングｔｓを交換タイミングｔ１に早めたり、交換タイミングｔ２に遅らせたりする。
【０１２３】  なお、上述した例以外には、車両２０が、道路の勾配が大きく登坂路が多い地域、積雪が多い地域を走行する場合、標準交換タイミングｔｓを交換タイミングｔ１に早めてもよい。また、車両２０の加速Ｇ・減速Ｇに基づいて、車両２０のエンジンが高負荷状態になり易いと判定された場合には、グレードに関わらず、標準交換タイミングｔｓを交換タイミングｔ１に早めてもよい。
【０１２４】  サービス情報通知システム１００は、このように補正された交換タイミングをエンジンオイルの次回交換タイミングとして設定し、処理を終了する。
（２．２）バッテリ
【０１２５】  図６は、図５と類似したフローであるため、以下、図５と異なる部分について主に説明する。図６に示すように、サービス情報通知システム１００は、車両２０に備えられているバッテリの内部抵抗（ＳｏＨ）を取得する（Ｓ３１０）。車両２０は、バッテリの内部抵抗を測定する測定回路を備える。また、車両２０は、バッテリの充放電回数を記録することができる。
【０１２６】  サービス情報通知システム１００は、バッテリの標準交換タイミングｔｓを予測し、バッテリの種類を取得する（Ｓ３２０，Ｓ３３０）。なお、サービス情報通知システム１００は、バッテリの容量（Ａｈ）や等級などをさらに取得してもよい。
【０１２７】  また、ここでは、サービス情報通知システム１００は、バッテリの充放電回数、車両２０が主に走行する地域及び気温の情報を車両２０の使用状況として取得する（Ｓ３４０）。
【０１２８】  サービス情報通知システム１００は、バッテリの種類と、車両２０の使用状況に基づいて、標準交換タイミングｔｓを補正する（Ｓ３５０）。
【０１２９】  なお、上述した例以外には、車両２０が、エンジン停止状態（イグニッションスイッチのオフ状態）においてアクセサリ（ＡＣＣ）の使用電力が高い場合、標準交換タイミングｔｓを交換タイミングｔ１に早めてもよい。また、バッテリの充放電回数がバッテリのライフタイムに大きな影響があることを考慮し、バッテリの充放電回数が所定値を超えた場合には、バッテリの種類に関わらず、標準交換タイミングｔｓを交換タイミングｔ１に早めてもよい。
（２．３）タイヤ
【０１３０】  図７も図５と類似したフローであるため、以下、図５と異なる部分について主に説明する。図７に示すように、サービス情報通知システム１００は、車両２０に備えられているタイヤ（４輪分）のスリップ率を取得する（Ｓ４１０）。車両２０は、駆動輪（例えば、前輪）と、従動輪（後輪）との回転差を検出する検出回路を備える。また、車両２０は、発生する加速Ｇ・減速Ｇ、積載重量及び操舵量を検出することができる。
【０１３１】  サービス情報通知システム１００は、タイヤの標準交換タイミングｔｓを予測し、タイヤの種類を取得する（Ｓ４２０，Ｓ４３０）。なお、サービス情報通知システム１００は、タイヤサイズ（トレッド幅、偏平率及びタイヤ径）をさらに取得してもよい。
【０１３２】  また、ここでは、サービス情報通知システム１００は、車両２０が発生する加速Ｇ・減速Ｇ、車両２０への積載重量、車両２０が主に走行する地域における日射量を車両２０の使用状況として取得する（Ｓ４４０）。
【０１３３】  サービス情報通知システム１００は、タイヤの種類と、車両２０の使用状況に基づいて、標準交換タイミングｔｓを補正する（Ｓ４５０）。
【０１３４】  なお、車両２０の加速Ｇ・減速Ｇ、操舵量及び積載重量などに基づいて、車両２０に装着されているタイヤに所定値以上の負荷が恒常的に掛かっていると判定された場合には、タイヤの種類などに関わらず、標準交換タイミングｔｓを交換タイミングｔ１に早めてもよい。
【０１３５】  上述した実施形態によれば、以下の作用効果が得られる。
【０１３６】  サービス情報通知システム１００によれば、車両２０から繰り返し取得した消耗状態データに基づいて、当該消耗品の次回交換タイミングが予測される。さらに、予測された次回交換タイミングに合わせて、サービス情報に対する必要度が所定値を超えるユーザと対応付けられている所定の宛先（例えば、端末装置３５）に対して、当該サービス情報が通知される。
【０１３７】  このため、当該消耗品の前回の交換タイミングを用いることなく、次回交換タイミングを予測するこができる。また、サービス情報を必要度が高いユーザに対して選択的にサービス情報を通知することができる。これにより、個々のユーザに対して、より適切なタイミングに消耗品の交換を推奨できる。このようなサービス情報の通知は、結果的に消耗品のタイムリーな交換に貢献し、車両２０の良好な状態の維持、及び安全性の向上に寄与し得る。
【０１３８】  また、サービス情報を必要度が低いユーザに対しては、サービス情報の通知が抑制されるため、システムや通信ネットワークのリソースの浪費を防止し得る。また、当該ユーザが当該サービス情報を煩わしいと感じることも回避できる。
【０１３９】  さらに、サービス情報通知システム１００によれば、個々のユーザに対して、より適切なタイミングに消耗品の交換を推奨できるため、当該サービス情報を受信したユーザが、ディーラ５０において消耗品を交換する機会を増大し得る。
【０１４０】  本実施形態では、サービス情報通知システム１００は、車両２０から取得した消耗状態データに基づいて標準交換タイミングｔｓを予測し、関連データ（消耗品のグレード及び車両２０の使用状況）を用いて、標準交換タイミングｔｓを交換タイミングｔ１（早める場合）または交換タイミングｔ２（遅らせる場合）に補正できる（図８参照）。これにより、実際の消耗品の消耗状態（劣化状態）に応じた、より正確な消耗品の次回交換タイミングを設定できる。
【０１４１】また、ユーザに対して、さらに適切なタイミングに消耗品の交換を推奨できるため、当該ユーザに対する消耗品の交換の訴求力を高める。
【０１４２】  本実施形態では、サービス情報通知システム１００は、消耗品が交換されたことを示す交換済データを取得した場合、サービス情報の通知を中止する。これにより、実際には必要のないサービス情報が通知されることを防止でき、ユーザが煩わしさを感じることもない。また、これにより、システムや通信ネットワークのリソースの浪費を防止し得る。
【０１４３】  本実施形態では、サービス情報通知システム１００は、サービス情報に対する必要度が、ユーザの消耗品に対する価格センシティビティの高さと、車両２０のメーカーまたはディーラに対するロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、サービス情報を通知することができる。これにより、ユーザを細かくセグメント化することができ、特定のクラスに属するユーザに対して、より適切なタイミングにおいてサービス情報を通知することができる。また、これにより、有効性が低いサービス情報の送信を回避できるため、システムや通信ネットワークのリソースの浪費を防止し得る。
【０１４４】  本実施形態では、サービス情報通知システム１００は、ディーラ５０への来店頻度の低いユーザに対しては、標準交換タイミングｔｓを交換タイミングｔ１に早めることができる。これにより、ディーラ５０以外の場所（カー用品店など）において消耗品が交換される前に、ユーザにサービス情報を通知し得る。また、これにより、当該消耗品の早期交換が促進され、車両２０の良好な状態の維持、及び安全性の向上に寄与し得る。
【０１４５】  本実施形態では、サービス情報通知システム１００は、使用状況がシビアと想定されるユーザに対しても、標準交換タイミングｔｓを交換タイミングｔ１に早めることができる。これにより、消耗品が使用限界を超える前に確実にサービス情報を通知し得る。また、これにより、使用限界を超える前に当該消耗品が交換され得るため、車両２０の良好な状態の維持、及び安全性の向上に寄与し得る。
【０１４６】  本実施形態では、サービス情報通知システム１００は、ディーラ５０だけでなく、ディーラ５０の周辺に存在する他のディーラにもサービス情報（または発行通知）を送信することができる。これにより、ディーラ５０の周辺に存在する他のディーラも、当該ユーザに対してサービス情報（クーポンを含む）を通知することができ、当該ユーザは、複数のディーラのサービスを比較できる。また、これにより、複数のディーラに関するサービス情報を纏めて送信できるため、システムや通信ネットワークのリソースの浪費を防止し得る。
【０１４７】  本実施形態では、サービス情報通知システム１００は、インフォティメントシステム２５にサービス情報を通知することができる。これにより、ディーラ５０以外（カー用品店）からのサービス情報（クーポン）と明確に区別して、ユーザにサービス情報の内容を知らしめることができる。また、これにより、インフォティメントシステム２５及び端末装置３５への重複したサービス情報の送信が回避できるため、システムや通信ネットワークのリソースの浪費を防止し得る。
【０１４８】  （その他の実施形態）
【０１４９】  以上、実施例に沿って本発明の内容を説明したが、本発明はこれらの記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。
【０１５０】  例えば、上述した実施形態では、ユーザ３０のサービス情報に対する必要度は、サービス情報に対する必要度が、ユーザの消耗品に対する価格センシティビティの高さと、車両２０のメーカーまたはディーラに対するロイヤルティの高さとの組合せに基づくクラスであったが、当該必要度は、単純な複数のレベル（１〜５など）でもよい。
【０１５１】  上述した実施形態では、サービス情報通知システム１００の機能ブロックが複数のハードウェア（サーバコンピュータ）に分散して配置され得るものとして説明したが、サービス情報通知システム１００によって提供される機能ブロック（図３参照）は、単体のハードウェア上で実現される装置であっても構わない。さらに、この場合、サービス情報通知システム１００の機能の一部または全部は、車両２０のハードウェアで実現されても構わない。
【０１５２】  また、サービス情報通知システム１００の各機能は、コンピュータプログラム、或いは当該コンピュータプログラムが記憶された媒体として提供されても構わない。
【０１５３】  上述したように、車両２０は、電気自動車でもよいが、その場合、エンジンオイルに関するサービス情報の通知は適用されない。
【０１５４】  上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。
【符号の説明】
【０１５５】  １０  車両管理ネットワーク
２０  車両
２１  通信部
２３  消耗状態測定部
２４  車両使用状況取得部
２５  インフォティメントシステム
３０  ユーザ
３５  端末装置
５０  ディーラ
５５  端末装置
６０  ネットワーククラウド
１００  サービス情報通知システム
１１０  消耗状態データ取得部
１２０  ユーザデータ取得部
１３０  関連データ取得部
１４０  交換タイミング予測部
１５０  通知部
２００  顧客ＤＢ
【図１】
2019180474.tif 000003
【図２】
2019180474.tif 000004
【図３】
2019180474.tif 000005
【図４】
2019180474.tif 000006
【図５】
2019180474.tif 000007
【図６】
2019180474.tif 000008
【図７】
2019180474.tif 000009
【図８】
2019180474.tif 000010
【図９Ａ】
2019180474.tif 000011
【図９Ｂ】
2019180474.tif 000012
【図９Ｃ】
2019180474.tif 000013
【図１０】
2019180474.tif 000014
【図１１Ａ】
2019180474.tif 000015
【図１１Ｂ】
2019180474.tif 000016
【図１１Ｃ】
2019180474.tif 000017
【図１２】
2019180474.tif 000018
【手続補正書】
【提出日】平成31年1月23日(2019.1.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを少なくとも含み、車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムであって、
前記プロセッサは、
前記消耗品の消耗状態を示す消耗状態データを前記車両から取得し、前記メモリに保持させる消耗状態データ取得部と、
前記消耗状態データに基づいて、前記消耗品の次回交換タイミングを予測する交換タイミング予測部と、
前記車両と対応付けられたユーザの前記サービス情報に対する必要度を含むユーザデータを取得し、前記メモリに保持させるユーザデータ取得部と、
前記次回交換タイミングに合わせて、前記必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知する通知部と
を構成し、
前記通知部は、前記消耗品の次回交換タイミングの標準である標準交換タイミングよりも早いタイミングにおいて、前記サービス情報を通知するサービス情報通知システム。
【請求項２】
前記プロセッサは、前記車両において現在用いられている前記消耗品のグレード及び前記車両の使用状況の少なくとも何れかを示す関連データを取得し、前記メモリに保持させる関連データ取得部を構成し、
前記交換タイミング予測部は、
前記消耗状態データに基づいて、前記標準交換タイミングを予測し、
前記関連データ取得部によって取得された前記関連データを用いて、前記標準交換タイミングを補正する請求項１に記載のサービス情報通知システム。
【請求項３】
前記交換タイミング予測部は、前記グレードが所定値を超える前記消耗品の次回交換タイミングを前記標準交換タイミングよりも遅らせる請求項２に記載のサービス情報通知システム。
【請求項４】
前記交換タイミング予測部は、前記使用状況が所定条件を超える場合、前記消耗品の次回交換タイミングを前記標準交換タイミングよりも早める請求項２に記載のサービス情報通知システム。
【請求項５】
（削除）
【請求項６】
前記消耗状態データ取得部は、前記消耗品が交換されたことを示す交換済データを取得し、前記メモリに保持させ、
前記通知部は、前記消耗状態データ取得部が前記交換済データを取得した場合、前記サービス情報の通知を中止する請求項１に記載のサービス情報通知システム。
【請求項７】
前記必要度は、前記消耗品の交換コストに対するセンシティビティと、前記車両のメーカーまたはディーラに対するロイヤルティとを含み、
前記通知部は、前記センシティビティの高さと、前記ロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、前記サービス情報を通知する請求項１に記載のサービス情報通知システム。
【請求項８】
車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムにおいて用いられるデータ構造であって、
交換が推奨される前記消耗品の名称データと、
前記消耗品の消耗程度を示す消耗度データと
を含み、
前記サービス情報通知システムが、前記車両から取得された前記消耗品の消耗状態を示す消耗状態データに基づいて前記消耗品の次回交換タイミングを予測し、前記次回交換タイミングに合わせて、前記車両と対応付けられたユーザの前記サービス情報に対する必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知する
処理に用いられ、
前記消耗品の次回交換タイミングの標準である標準交換タイミングよりも早いタイミングにおいて、前記サービス情報が通知されるデータ構造。
【手続補正書】
【提出日】平成31年4月25日(2019.4.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを少なくとも含み、車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムであって、
前記プロセッサは、
前記消耗品の消耗状態を示す消耗状態データを前記車両から取得し、前記メモリに保持させる消耗状態データ取得部と、
前記消耗状態データに基づいて、前記消耗品の次回交換タイミングを予測する交換タイミング予測部と、
前記車両と対応付けられたユーザの前記サービス情報に対する必要度を含むユーザデータを取得し、前記メモリに保持させるユーザデータ取得部と、
前記必要度が所定値以下のユーザと対応付けられている所定の宛先に対して、前記消耗品の次回交換タイミングの標準である標準交換タイミングよりも早いタイミングにおいて、前記サービス情報を通知する通知部と、
前記車両において現在用いられている前記消耗品のグレード及び前記車両の使用状況の少なくとも何れかを示す関連データを取得し、前記メモリに保持させる関連データ取得部と
を構成し、
前記交換タイミング予測部は、
前記消耗状態データに基づいて、前記標準交換タイミングを予測し、
前記関連データ取得部によって取得された前記関連データを用いて、前記標準交換タイミングを補正するサービス情報通知システム。
【請求項２】
（削除）
【請求項３】
前記交換タイミング予測部は、前記グレードが所定値を超える前記消耗品の次回交換タイミングを前記標準交換タイミングよりも遅らせる請求項１に記載のサービス情報通知システム。
【請求項４】
前記交換タイミング予測部は、前記使用状況が所定条件を超える場合、前記消耗品の次回交換タイミングを前記標準交換タイミングよりも早める請求項１に記載のサービス情報通知システム。
【請求項５】
（削除）
【請求項６】
前記消耗状態データ取得部は、前記消耗品が交換されたことを示す交換済データを取得し、前記メモリに保持させ、
前記通知部は、前記消耗状態データ取得部が前記交換済データを取得した場合、前記サービス情報の通知を中止する請求項１に記載のサービス情報通知システム。
【請求項７】
（削除）
【請求項８】
車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムにおいて用いられるデータ構造であって、
交換が推奨される前記消耗品の名称データと、
前記消耗品の消耗程度を示す消耗度データと
を含み、
前記サービス情報通知システムが、
前記車両から取得された前記消耗品の消耗状態を示す消耗状態データに基づいて前記消耗品の次回交換タイミングを予測し、
前記車両と対応付けられたユーザの前記サービス情報に対する必要度が所定値以下のユーザと対応付けられている所定の宛先に対して、前記消耗品の次回交換タイミングの標準である標準交換タイミングよりも早いタイミングにおいて、前記サービス情報を通知し、
前記車両において現在用いられている前記消耗品のグレード及び前記車両の使用状況の少なくとも何れかを示す関連データを取得し、
前記消耗状態データに基づいて、前記標準交換タイミングを予測し、
取得した前記関連データを用いて、前記標準交換タイミングを補正する
処理に用いられるデータ構造。
【請求項９】
プロセッサとメモリとを少なくとも含み、車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムであって、
前記プロセッサは、
前記消耗品の消耗状態を示す消耗状態データを前記車両から取得し、前記メモリに保持させる消耗状態データ取得部と、
前記消耗状態データに基づいて、前記消耗品の次回交換タイミングを予測する交換タイミング予測部と、
前記車両と対応付けられたユーザの前記サービス情報に対する必要度を含むユーザデータを取得し、前記メモリに保持させるユーザデータ取得部と、
前記次回交換タイミングに合わせて、前記必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知する通知部と
を構成し、
前記必要度は、前記消耗品の交換コストに対するセンシティビティと、前記車両のメーカーまたはディーラに対するロイヤルティとを含み、
前記通知部は、前記センシティビティの高さと、前記ロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、前記サービス情報を通知するサービス情報通知システム。
【請求項１０】
車両において用いられる消耗品の交換を推奨するサービス情報を通知するサービス情報通知システムにおいて用いられるデータ構造であって、
交換が推奨される前記消耗品の名称データと、
前記消耗品の消耗程度を示す消耗度データと
を含み、
前記サービス情報通知システムが、
前記車両から取得された前記消耗品の消耗状態を示す消耗状態データに基づいて前記消耗品の次回交換タイミングを予測し、
前記次回交換タイミングに合わせて、前記車両と対応付けられたユーザの前記サービス情報に対する必要度が所定値を超えるユーザと対応付けられている所定の宛先に対して前記サービス情報を通知し、
前記必要度は、前記消耗品の交換コストに対するセンシティビティと、前記車両のメーカーまたはディーラに対するロイヤルティとを含み、
前記サービス情報通知システムが、前記センシティビティの高さと、前記ロイヤルティの高さとの組合せに基づく所定のクラスに属するユーザを対象として、前記サービス情報を通知する
処理に用いられるデータ構造。
【国際調査報告】
2019180474.tif 000019
2019180474.tif 000020
2019180474.tif 000021
2019180474.tif 000022