(57)【要約】【課題】優先的に運転診断すべき、ユーザからの診断結果の要求の発生を推定する。【解決手段】本発明の車両情報処理システムは、車両から車両情報を受信し、車両の運転診断の診断結果を送信するデータ送受信部、データ送受信部により、診断結果を車両へ送信した提供履歴を格納する提供履歴管理部、提供履歴管理部に格納される診断結果の提供履歴から利用傾向を求める利用傾向判定部、受信した車両情報から車両の走行状態を求める走行状態判定部、求めた利用傾向と走行状態とに応じた優先度に基づいて、車両情報を用いて車両を運転診断する運転診断部、及び、運転診断部による運転診断の診断結果を、データ送受信部を用いて送信する診断結果提供部を有する。【選択図】図１
2011012968.tif 000002
【特許請求の範囲】
【請求項１】
車両の運転診断を実行する車両情報処理システムにおける車両情報処理方法であって、
前記車両から車両情報を収集し、
前記車両への前記運転診断の診断結果の提供履歴から前記診断結果の利用傾向を求め、
収集した前記車両情報から前記車両の走行状態を求め、
求めた前記利用傾向と前記走行状態とに応じた優先度に基づいて、収集した前記車両情報を用いて前記車両の運転診断を実行することを特徴とする車両情報処理方法。
【請求項２】
前記利用傾向は、前記車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、前記提供履歴に含まれる前記診断結果を提供した、「回数」及び「間隔」で表すことを特徴とする請求項１記載の車両情報処理方法。
【請求項３】
前記「候補地点」、前記「候補曜日」及び前記「候補時間帯」は、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯であることを特徴とする請求項２記載の車両情報処理方法。
【請求項４】
前記利用傾向は、少なくとも直近の所定期間分を含む前記提供履歴から求めることを特徴とする請求項２記載の車両情報処理方法。
【請求項５】
前記走行状態は、前記車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「前記車両が特定地点の近辺を走行中か否か」を表すことを特徴とする請求項１記載の車両情報処理方法。
【請求項６】
前記特定地点は、前記車両へ搭載された機器に登録され、前記車両情報に含まれる場所、及び、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかであることを特徴とする請求項５記載の車両情報処理方法。
【請求項７】
車両から車両情報を受信し、前記車両の運転診断の診断結果を送信するデータ送受信部、前記データ送受信部により、前記診断結果を前記車両へ送信した提供履歴を格納する提供履歴管理部、
前記提供履歴管理部に格納される前記診断結果の提供履歴から利用傾向を求める利用傾向判定部、
受信した前記車両情報から前記車両の走行状態を求める走行状態判定部、
求めた前記利用傾向と前記走行状態とに応じた優先度に基づいて、前記車両情報を用いて前記車両を運転診断する運転診断部、及び
前記運転診断部による運転診断の診断結果を、前記データ送受信部を用いて送信する診断結果提供部を有することを特徴とする車両情報処理サーバ。
【請求項８】
前記利用傾向判定部が求める前記利用傾向は、前記車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、前記提供履歴に含まれる前記診断結果を提供した、「回数」及び「間隔」であることを特徴とする請求項７記載の車両情報処理サーバ。
【請求項９】
前記「候補地点」、前記「候補曜日」及び前記「候補時間帯」は、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯であることを特徴とする請求項８記載の車両情報処理サーバ。
【請求項１０】
前記利用傾向判定部は、前記提供履歴管理部に格納される、少なくとも直近の所定期間分を含む前記提供履歴から求めることを特徴とする請求項８記載の車両情報処理サーバ。
【請求項１１】
前記走行状態判定部が求める前記走行状態は、前記車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「前記車両が特定地点の近辺を走行中か否か」であることを特徴とする請求項７記載の車両情報処理サーバ。
【請求項１２】
前記特定地点は、前記車両へ搭載された機器に登録され、前記データ送受信部が受信する前記車両情報に含まれる場所、及び、前記提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかであることを特徴とする請求項１１記載の車両情報処理サーバ。
【請求項１３】
前記診断結果提供部は、前記診断結果の送信に対応して、前記診断結果を提供したログを、前記提供履歴管理部に格納される前記診断結果の提供履歴として追加することを特徴とする請求項７記載の車両情報処理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両情報処理方法および車両情報処理サーバに係り、特に車両からアップロードされる車両情報に基づいて、運転診断する順序を決定する技術に係わる。
【背景技術】
【０００２】
自動車に取り付けた車載端末とセンタサーバとを無線ネットワークで接続し、渋滞情報や音楽コンテンツなどの配信を行うテレマティクスサービスが注目されている。センタのコンテンツをダウンロードするだけでなく、車載端末で収集した車両情報をアップロードし、アップロードした車両情報でエコ運転診断や安全運転診断を行うテレマティクスサービスも注目されてきている。エコ運転診断や安全運転診断の結果を車載端末へ提供するテレマティクスサービスでは、自動車からセンタサーバへアップロードされる車両情報を迅速に診断、車載端末からの診断結果の要求に応答しなければならない。また、ドライバが診断結果に基づいて運転を改善するためには、運転と診断結果の対応をドライバが理解しやすい形で診断結果を提供しなければならない。
【０００３】
ユーザであるドライバからの要求に対する応答性能を確保したまま、莫大な量の情報を処理するための方法の一つとして、ユーザ毎に事前に優先度を決めておき、そのユーザのリクエストを優先的に処理する方法がある。例えば、特許文献１（特開２００３−２１６５８３）に開示されているように、一台のｗｗｗサーバ装置において一時的な利用者からのリクエストメッセージの集中による処理負荷を吸収するためにリクエストメッセージに対するキューを用い、特定のユーザのリクエストメッセージを優先して処理を行うことで、応答性能を保証したサービスを提供する。また、他の優先制御に関する技術として、情報に優先度をつけ、優先度の高い情報から処理する方法がある。例えば、特許文献２（特開２００９−２０６６２）に開示されているように、配信制御情報に優先度を含むことで、情報提供判定装置が登録する配信制御情報を用いて、情報配信制御装置の配信順序を動的に変更することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２１６５８３
【特許文献２】特開２００９−２０６６２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
センタサーバを用いた車両情報処理システムのサービス対象の自動車の数が莫大なため、それらの全ての車両情報を対象に運転診断するには時間がかかる。そのため、車両情報処理システムが効率的に運転診断するためには、診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断する必要がある。診断結果の要求の発生を推定するためには、要求しやすい状況(場所など)、要求しやすい人(ユーザ)を判定する必要がある。
【０００６】
これに対して特許文献１では、ユーザ毎に設定した優先度に応じて運転診断を優先制御している。ユーザであるドライバは必要に応じて診断結果を要求するので、診断結果の要求頻度などの要求状況は変化し、設定した固定的な優先度では対応できない。
【０００７】
特許文献２では、配信制御情報に設定した優先度に基づいて配信制御しているが、優先度の決定方法は考慮されていないので、要求状況の変化に対応できない。
【課題を解決するための手段】
【０００８】
開示された車両情報処理方法および車両情報処理サーバは、車両から車両情報を受信し、車両の運転診断の診断結果を送信するデータ送受信部、データ送受信部により、診断結果を車両へ送信した提供履歴を格納する提供履歴管理部、提供履歴管理部に格納される診断結果の提供履歴から利用傾向を求める利用傾向判定部、受信した車両情報から車両の走行状態を求める走行状態判定部、求めた利用傾向と走行状態とに応じた優先度に基づいて、車両情報を用いて車両を運転診断する運転診断部、及び、運転診断部による運転診断の診断結果を、データ送受信部を用いて送信する診断結果提供部を有する車両情報処理サーバにより具現化される。
【０００９】
車両情報処理方法および車両情報処理システムの、他の望ましい態様によれば、利用傾向判定部が求める利用傾向は、車両が前記診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、提供履歴に含まれる診断結果を提供した、「回数」及び「間隔」である。
【００１０】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、「候補地点」、「候補曜日」及び「候補時間帯」は、提供履歴の中で、前記診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯である。
【００１１】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、利用傾向部は、提供履歴管理部に格納される、少なくとも直近の所定期間分を含む提供履歴から求める。
【００１２】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、走行状態判定部が求める走行状態は、車両の位置と特定地点との位置関係として、「前記車両が特定地点へ接近中か否か」及び「車両が特定地点の近辺を走行中か否か」である。
【００１３】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、特定地点は、車両へ搭載された機器に登録され、データ送受信部が受信する車両情報に含まれる場所、及び、提供履歴の中で、診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い場所の何れかである。
【００１４】
車両情報処理方法および車両情報処理システムの、さらに他の望ましい態様によれば、診断結果提供部は、診断結果の送信に対応して、診断結果を提供したログを、提供履歴管理部に格納される診断結果の提供履歴として追加する。
【発明の効果】
【００１５】
本発明によれば、ユーザからの診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断できる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態の車両情報処理システムの構成図を示す。
【図２】本実施形態の車載端末のハードウェア構成図を示す。
【図３】本実施形態の車両情報蓄積部のテーブル構成を示す。
【図４】本実施形態の認証情報管理部のテーブル構成を示す。
【図５】本実施形態の車両情報管理部のテーブル構成を示す。
【図６】本実施形態のルール管理部のテーブル構成を示す。
【図７】本実施形態の診断結果管理部のテーブル構成を示す。
【図８】本実施形態の提供履歴管理部のテーブル構成を示す。
【図９】本実施形態の優先度に応じた運転診断処理のフローを示す。
【図１０】本実施形態のドライバへのコンテンツ提供のシーケンスを示す。
【図１１】本実施形態のコンテンツ生成部の処理フローを示す。
【図１２Ａ】本実施形態のドライバへ提供する、ディスプレイの画面例を示す。
【図１２Ｂ】本実施形態のドライバへ提供する、ディスプレイの画面例を示す。
【発明を実施するための形態】
【００１７】
以下に、本発明の実施形態について、図を用いて詳細に説明する。図１は、本実施形態における車両情報処理システムの構成図を示す。車両１０１には、車載端末１０２、通信装置１０９、車内ネットワーク１１０、ECU１１１、GPS１１２、ナビゲーション装置１１３、ディスプレイ１１４、入力装置１１５が搭載される。ECU１１１はElectric Control Unit（電子制御装置）で、車両１０１の走行を制御する装置である。車載端末１０２とECU１１１とは、車内ネットワーク１１０で接続されており、車載端末１０２は、車内ネットワーク１１０を介して、車両１０１の走行速度（以下、車速）や燃料噴射量のような、ECU１１１が制御に使用している情報（制御対象に対する制御情報と制御対象の状態情報）を車両情報として取得する。車載端末１０２は、GPS１１２から位置情報や時刻情報を、ナビゲーション装置１１３から自宅や会社、目的地などの地点情報を取得する。
【００１８】
本実施形態では車両情報の取得先としてECU１１１、GPS１１２、ナビゲーション装置１１３を説明するが、必要に応じて各種センサなども、車内ネットワーク１１０を介して、または直接接続して車両情報の取得先とする。車載端末１０２は、ディスプレイ１１４や入力装置１１５と専用線で接続される。車載端末１０２は通信装置１０９と接続され、ネットワーク１１９を介してセンタサーバ１２０とデータを送受信する。通信装置１０９は、車両１０１に組込みの通信モジュールでも良いし、外付けで接続された携帯電話などでも良い。
【００１９】
以下に説明する各処理は、車載端末１０２が有するCPUによりプログラムを実行することで実現される。車載端末１０２は、車両情報収集部１０３、データ送受信部１０５、コンテンツ生成部１０６および診断結果取得部１０７の各処理を実行する。車載端末１０２は、車両情報収集部１０３で収集した車両情報を格納する車両情報蓄積部１０４を有する。車両情報収集部１０３は、１秒間隔などの周期で、GPS１１２からの車両１０１の現在位置や現在時刻、車内ネットワーク１１０を介したECU１１１からの車速などの情報、及びナビゲーション装置１１３からの自宅、会社、目的地などの地点情報の各情報を取得し、車両情報蓄積部１０４に格納する。
【００２０】
データ送受信部１０５は、センタサーバ１２０のデータ送受信部１２１と通信してデータを送受信する。データ送受信部１０５は、10分周期など、定期的にネットワーク１１９を介した回線を接続して車両情報蓄積部１０４に蓄積されたデータを送信する。このとき、車載端末１０２に事前に割当てられている車載端末固有のID(識別子)である車載機IDを併せてセンタサーバ１２０へ送信する。車両１０１からデータを送信するタイミングは、定期的ではなく、ユーザからの入力装置１１５を介したトリガーによるタイミング(通信接続の機会)でも良いし、ユーザがセンタサーバ１２０から情報を取得するタイミングでデータを送信しても良い。車両情報蓄積部１０４に格納されている未アップロード情報（未だセンタサーバ１２０へ送信していない情報）の全てを一回の通信接続（ネットワーク１１９を介した回線の接続）で送信しても良いし、一回の通信接続で送信するデータサイズの上限を設定するようにしても良い。
【００２１】
ユーザが運転診断の結果を含むコンテンツをディスプレイ１１４へ表示するためにボタン押下すると、診断結果取得部１０７がデータ送受信部１０５を経由してセンタサーバ１２０から診断結果を取得する。コンテンツ生成部１０６では、取得した診断結果と、車両情報蓄積部１０４に格納されている車両１０１の走行履歴（情報蓄積部１０４に格納されている車両情報に含まれる位置や時刻情報を基にした車両の走行の軌跡）とに基づいて、ユーザに提供するコンテンツを生成し、ディスプレイ１１４に表示する。
【００２２】
以下に説明する各処理は、車両情報処理サーバであるセンタサーバ１２０が有するCPUによりプログラムを実行することで実現される。センタサーバ１２０は、データ送受信部１２１、走行状態判定部１２３、優先度決定部１２５、運転診断部１２６、利用傾向判定部１２８、診断結果提供部１３０、認証部１３１の各処理を実行する。センタサーバ１２０は、これらの各処理の実行に用いるデータを格納する、車両情報管理部１２２、ルール管理部１２４、診断結果管理部１２７、提供履歴管理部１２９、認証情報管理部１３２を有する。
【００２３】
データ送受信部１２１では、車載端末１０２と通信する場合には、最初に認証部１３１で認証処理を行う。認証部１３１では、車載端末１０２から送られた車載機IDと、通信に利用された携帯電話番号などの通信装置１０９を識別する識別情報を用いて認証を行う。認証部１３１は、車載機IDと携帯電話番号などの識別情報をキーとして認証情報管理部１３２を検索し、ユーザを特定するユーザIDを取得する。認証成功後、データ送受信部１２１は、車載端末１０２からアップロードされた車両情報を、認証部１３２で特定されたユーザIDと対応付けて車両情報管理部１２２に蓄積する。
【００２４】
なお、認証部１３１は、車載機IDと携帯電話番号などの識別情報とからユーザを特定するので、特定するユーザは、人としてのドライバではなく、車両１０１であるとも言える。以下の説明において、分かり易くするために「ユーザ」を用いるが、車両１０１を示す場合もある。人としてのユーザであるか、車両１０１としてのユーザであるか、それらのいずれでも良いのかは、文脈から理解されるだろう。
【００２５】
運転診断部１２６では、車両情報管理部１２２の車両情報を用いて、ユーザの運転がエコドライブであるか否かを診断し、診断結果を診断結果管理部１２７に格納する。このとき、車両情報管理部１２２には複数ユーザの車両情報が蓄積されているため、優先度決定部１２５で決定された優先度に基づいて、優先度の高いユーザから運転診断を行う。運転診断は、エコドライブか否かを診断するエコ運転診断だけでなく、安全運転か否かを診断する安全運転診断でも良い。診断結果提供部１３０は、車載端末１０２からの要求に応じて、認証部１３２で特定したユーザの診断結果を診断結果管理部１２７から取得して車載端末１０２へ提供する。診断結果を提供したログを、提供履歴管理部１２９に記録する。
【００２６】
走行状態判定部１２３では、車両情報管理部１２２に格納されている車両情報に基づいて、ユーザは、「自宅に接近している」、「目的地まであと1kmである」、「17時12分に走行中である」などの、場所や時間に関する走行状態を判定する。利用傾向判定部１２８では、提供履歴管理部１２９に格納されているログを統計処理することで、「最近の診断結果取得回数」、「ユーザが診断結果を取得する可能性の高い場所や時間帯」などの利用傾向を判定する。優先度決定部１２５では、走行状態判定部１２３と利用傾向判定部１２８で判定した走行状態と利用傾向とに基づいて、運転診断部１２６での運転診断の処理順序を決定するための優先度を決定する。走行状態と利用傾向とは、ユーザからの診断結果の要求状況を表すので、優先度は要求状況の変化に対応したものとなる。すなわち、診断結果の要求の発生が近い将来に推定されるユーザの運転診断ほど、高い優先度が与えられる。
【００２７】
図２は、車載端末１０２のハードウェア構成図を示す。車載端末１０２は、CPU(プロセッサ)２０１、RAM２０２、ROM２０３、外部記憶装置としてのHDD(ハードディスクドライブ)２０４、車内ネットワーク１１０を介してECU１１１とデータ送受信する車内通信インタフェース２０５、通信装置１０７とデータ送受信する外部通信インタフェース２０６、GPS１１２、ナビゲーション装置１１３、ディスプレイ１１４、入力装置１１５とデータ送受信する専用通信インタフェース２０７により構成される。外部記憶装置は、HDDに限らず、光ディスク（DVDなど）装置、フラッシュメモリ装置などを用いても良い。車載端末１０２は、必要に応じてマニュアル・スイッチにより電源ON/OFFできるようにしてもよいが、車両１０１のエンジン始動に伴い電源がON(蓄電池に接続)になり、エンジン停止に伴い電源がOFFされ、エンジン作動中は電源ON/OFFのためのマニュアル・スイッチの動作は無効となるように制御されることが望ましい。
【００２８】
図１に示した車両情報収集部１０３、データ送受信部１０５、コンテンツ生成部１０６および診断結果取得部１０７の各プログラムと、車両情報蓄積部１０４のデータは、HDD２０４に格納されている。これらのプログラムは、車載端末１０２の電源ONに伴って、HDD２０４からRAM２０２にロードされ、実行される。この場合、ROM２０３には、プログラム及びプログラムの実行開始時に必要なデータをRAM２０２にロードするためのローダプログラムが格納される。車両情報蓄積部１０４にすでに格納されている車両情報は、ローダプログラムによってRAM２０２にロードされてもよいが、各プログラムの実行に伴い、必要に応じてRAM２０２にロードされるようにすることにより、RAM２０２の記憶容量を小さくできる。車両１０１のエンジン停止に伴い電源がOFFするが、RAM２０２にあるデータをHDD２０４に格納する時間は短時間であるので、電源OFFの過渡的な時間でも十分であるが、格納するデータ量が大きい場合などには、電源OFF（車両の蓄電池からの切断）を遅らせればよい。また、エンジン始動状況も含めてデータ収集するような場合には、エンジンの始動準備段階を検知(たとえば、エンジンキーの挿入の検知やユーザの乗車の検知)して電源ON（車両の蓄電池へ接続）し、プログラムの実行を開始すればよい。この場合、ROM２０３にプログラムを格納しておき、CPU２０１がROM２０３のプログラムを実行するようにすれば、プログラムのロードに要する時間が短縮できると共に、その短縮に応じて蓄電池の電力使用量を削減できる。
【００２９】
図３は、車両情報蓄積部１０４のテーブル構成を示す。このテーブル１０４は、時刻３０１、車速３０２、座標３０３、自宅３０４、目的地３０５、アップロード状況３０６の項目を有する。時刻３０１は、GPS１１２から取得する、車両情報を取得した時刻である。車速３０２は、ECU１１１から取得する、時刻３０１で示される時点での車速である。ECU１１１から取得する情報として車速３０２を示しているが、センタサーバ１２０の運転診断部１２６での診断処理内容に応じた、エンジン回転数、燃料噴射量などの情報も取得する。座標３０３はGPS１１２から取得する、時刻３０１で示される時点で車両１０１の位置を示す緯度・経度である。自宅３０４は、ナビゲーション装置１１３から取得する、「自宅」として予めナビゲーション装置１１３に登録されている場所の緯度・経度である。目的地３０５は、ナビゲーション装置１１３から取得する、時刻３０１で示される時点で、経路探索のために「目的地」としてナビゲーション装置１１３に登録されている場所の緯度・経度である。ここでは、自宅３０４と目的地３０５を示しているが、「会社」「経由地」など、ナビゲーション装置１１３に登録されている地点情報も取得するようにしても良い。
【００３０】
アップロード状況３０６は、時刻３０１〜目的地３０５の車両情報がセンタサーバ１２０にアップロードされたか否かを示している。「済」の場合には、時刻３０１で示される車両情報はアップロード済みであり、「未」の場合には、まだアップロードされていないので、次回以降のセンタサーバ１２０との通信接続時にアップロードされる。車両情報収集部１０３が車両情報を蓄積する時に、その車両情報のアップロード状況３０６は「未」とする。データ送受信部１０５がセンタサーバ１２０に車両情報をアップロードした時に、アップロード状況３０６は「済」に更新される。
【００３１】
図４は、センタサーバ１２０の認証情報管理部１３２のテーブル構成を示す。このテーブルは、認証のための情報を管理するテーブルであり、ユーザID４０１、車載機ID４０２、携帯電話番号４０３（通信装置１０９の識別情報）から構成される。ユーザID４０１はユーザを一意に識別するための識別子であり、車載機IDは車載端末１０２を一意に識別するための識別子である。認証部１３１では、車載機ID４０２と携帯電話番号４０３からユーザを一意に特定して、ユーザID４０１を取得する。
【００３２】
図５は、センタサーバ１２０の車両情報管理部１２２のテーブル構成を示す。このテーブル１２２は、車載端末１０２からアップロードされた車両情報を管理するテーブルであり、アップロードされた車両情報に認証部１３１で特定したユーザIDを付加した構成である。このテーブル１２２は、ユーザID５０１、時刻５０２、車速５０３、座標５０４、自宅５０５、目的地５０６、診断状況５０７の項目を有する。時刻５０２、車速５０３、座標５０４、自宅５０５、目的地５０６は、図３の車両情報蓄積部１０４の項目に対応する。ユーザID５０１は、車両情報である時刻５０２〜目的地５０６がどのユーザの情報であるかを示す。
【００３３】
診断状況５０７は、車両情報が運転診断部１２６で運転診断に用いられたか否かを示している。「済」は運転診断に使用済みを示し、「未」は、まだ運転診断に使用されていないことを示す。車載端末１０２から車両情報がアップロードされた時点では、診断状況５０７は「未」として蓄積される。運転診断部１２６で診断が完了し、結果が診断結果管理部１２７に蓄積されてから「済」に更新される。時間経過や走行の軌跡を用いる診断項目では、診断状況５０７が「済」に更新された車両情報が繰返して運転診断に用いられる。
【００３４】
図６は、センタサーバ１２０のルール管理部１２４のテーブル構成を示す。このテーブル１２４は、優先度決定部１２５で優先度スコアを求めるためのルールを管理するテーブルであり、番号６０１、ルール６０２、得点６０３の項目を有する。番号６０１はルールを識別するための番号で、ルール６０２はルールの具体的内容、得点６０３はルールを満たした場合の得点(スコア)を示す。優先度決定部１２５は、条件を満たしたルール６０２に対応する得点６０３を合計した値を優先度スコアとする。図６の例の、番号1のルールで、「自宅」「会社」「目的地」は車載端末１０２から取得する車両情報である。「リクエスト候補地点」は、提供履歴管理部１２９のログから統計的に求めるもので、ユーザが診断結果を要求する可能性の高い場所を示す。番号2の「リクエスト候補曜日」、番号3の「リクエスト候補時間帯」も同様で、ユーザが診断結果を要求する可能性の高い曜日と時間帯を示す。
【００３５】
図７は、センタサーバ１２０の診断結果管理部１２７のテーブル構成を示す。このテーブル１２７は、運転診断部１２６で運転診断した結果を格納するテーブルであり、ユーザID７０１、診断区間７０２、診断結果７０３の項目を有する。ユーザID７０１で示されるユーザの、診断区間７０２で示される期間の車両情報を使って診断した結果が、診断結果７０３に格納される。例えば、図の例では、ID=100のユーザは、2009年3月25日10時3分23秒〜11時1分17秒までに、急発進を2回、急加速を3回、アイドリングを35秒行った結果、57ccの燃料を無駄に消費し、無駄がなければ15.3km/Lの燃費で走行できたことを示している。なお、診断区間７０２は、図7では時間を示しているが、車両１０１がディスプレイに地図表示に診断結果を重ね合わせて表示する場合には、診断区間７０２に位置としての区間も含み、診断結果と共に車両１０１に送信することが望ましい。
【００３６】
図８は、センタサーバ１２０の提供履歴管理部１２９のテーブル構成を示す。このテーブル１２９は、ユーザに診断結果を提供した履歴(ログ)を管理しておくテーブルであり、ユーザID８０１、提供日時８０２、提供場所８０３から構成される。提供日時８０２は、ユーザID８０１で表されるユーザに診断結果を提供した日時を、提供場所５０３はユーザに診断結果を提供した場所を示している。提供場所５０３の位置情報は、車載端末１０２がセンタサーバ１２０へ診断結果を要求するときに、その要求に含まれる情報である。例えば、図の例では、ID=100のユーザが、2009年3月29日12時30分40秒に座標(X1,Y1)で、2009年3月30日12時10分32秒に座標(X2,Y2)で診断結果を取得したことを示している。
【００３７】
図９は、センタサーバ１２０での優先度に応じた運転診断処理のフロー図を示す。初めに、運転診断部１２６は、運転診断に使用していない車両情報を取得するために、車両情報管理部１２２から診断状況５０７が「未」の車両情報を検索し、検索結果のユーザID５０１から、診断対象のユーザの一覧を取得する（ステップ９０１）。次に、優先度決定部１２５に問合せて、ステップ９０１で取得した診断対象ユーザの優先度スコアを決定する。優先度決定部１２５では、初めに、利用傾向判定部１２８に問合せて、診断対象ユーザの利用傾向を取得する（ステップ９０２）。利用傾向判定部１２８では、提供履歴管理部１２９から診断対象ユーザの診断結果の提供履歴を検索し、提供履歴を統計処理して、図６のルール６０２で利用する「リクエスト候補地点」「リクエスト候補曜日」「リクエスト候補時間帯」「リクエスト回数」「リクエスト間隔」を得る。本実施形態では、利用傾向は、提供履歴管理部１２９を基に求める、車両(ユーザ)が診断結果を要求する、「候補地点」、「候補曜日」及び「候補時間帯」、並びに、提供履歴管理部１２９に含まれる診断結果を提供した、「回数」及び「間隔」によって表す。これは、ユーザからの要求(リクエスト)に応じて診断結果を提供した履歴から、そのユーザの診断結果の利用傾向を求め、近い将来に診断結果の提供を要求してくる可能性の高さを求めるためである。この可能性の高さを示す指標が、後述する優先度スコアである。
【００３８】
リクエスト候補地点を得る方法を示す。まず、提供履歴管理部１２９から診断対象ユーザへの診断結果の提供履歴を検索し、提供場所８０３に対応する提供回数を集計する。このとき、提供場所８０３から一定距離以内にある提供場所は、提供場所８０３が示す地点と同一地点であると見なす。提供回数の多い地点から順に、一定数の地点をリクエスト候補地点としても良いし、全体の提供回数に対する一定割合の提供回数の地点をリクエスト候補地点としても良いし、提供回数が一定数以上の地点をリクエスト候補地点としても良い。
【００３９】
リクエスト候補曜日を得る方法もリクエスト候補地点を得る方法と同様である。診断対象ユーザへの診断結果の提供履歴を提供履歴管理部１２９から検索し、提供日時を曜日単位で集計し、提供回数の多い曜日から順に、一定数または一定割合の曜日をリクエスト候補曜日としても良いし、提供回数が一定数以上の曜日をリクエスト候補曜日としても良い。また、リクエスト候補時間帯を得る方法も同様であり、診断対象ユーザへの診断結果の提供履歴を検索し、提供日時を時間帯で集計し、提供回数の多い時間帯から順に、一定数または一定割合の時間帯をリクエスト候補時間帯としても良いし、提供回数が一定数以上の時間帯をリクエスト候補時間帯としても良い。ここで、「曜日」は“月曜日”、“火曜日”のようにしても良いし、“平日”と“休日”のようにしても良い。また、「時間帯」は、“17時台”などのように1時間毎にしても良いし、“6〜12時”のように時間間隔を指定しても良いし、午前、午後のようにしても良い。
【００４０】
以上例示したように、「候補地点」、「候補曜日」及び「候補時間帯」は、提供履歴の中で、診断結果を提供した回数および比率の少なくとも一方の値が他に比べて高い、場所、曜日及び時間帯である。
【００４１】
リクエスト回数は診断対象ユーザへの診断結果の提供回数であり、リクエスト間隔は、診断結果を提供してから、次の診断結果を提供するまでの間隔の平均時間である。
【００４２】
「リクエスト候補地点」「リクエスト候補曜日」「リクエスト候補時間帯」「リクエスト回数」「リクエスト間隔」は、対象ユーザの全履歴を対象として算出しても良いし、直近の所定期間、たとえば1ヶ月というように期間を限定して算出しても良い。
【００４３】
次に、優先度決定部１２５は、走行状態判定部１２３に問合せて診断対象ユーザの走行状態を取得する（ステップ９０３）。走行状態判定部１２３では、「特定地点との位置関係」「車両情報の最新時刻」を得る。ここで、特定地点は、車両情報から得た自宅・会社・目的地の何れかの場所、又は、利用傾向判定部１２８で算出したリクエスト候補地点(場所)を示す。車両１０１の特定地点との位置関係として、「特定地点に接近中か否か」「特定地点から一定距離以内か否か」を判定する。特定地点に接近中か否か判定を得る方法を示す。まず、車両情報管理部１２２から、診断対象ユーザの直近の車両情報を取得し、特定地点との距離が徐々に短くなっているか否かで、特定地点に接近中か否かを判定する。直近の車両情報は、時刻５０２が新しい順に一定数の車両情報としても良いし、最新の10分間というように時間で決定しても良い。また、距離が徐々に短くなるという判定は、特定地点とのユークリッド距離が単調的に短くなるという判定でも良いし、時間と距離のデータにおける回帰直線を求めた場合に距離が短くなっているという判定でも良い。
【００４４】
次に、ステップ９０２とステップ９０３で取得した利用傾向と走行状態を用いて、ルール管理部１２４のルールに基づいて優先度スコアを算出する（ステップ９０４）。例えば、ユーザＡの利用傾向が「リクエスト候補曜日＝日曜日」「リクエスト候補時間帯＝17〜19時台」「リクエスト回数＝5回」「リクエスト間隔＝3日」で、走行状態が「自宅に接近中である」「自宅から一定距離以内である」「車両情報の最新時刻＝2009年3月29日 日曜日 12時20分38秒」であるとする。この時、優先度スコアを計算すると、図６の番号1、番号2、番号5のルールを満たすので、満たしたルールの得点を加算し、３＋２＋１＝６点が優先度スコアとなる。結果として、ルール管理部１２４のいずれのルールも満足せずに、優先度スコアの合計が０のユーザも発生する。ステップ９０１で取得した全ユーザの優先度スコアを算出した場合（Yes）にはステップ９０６に進み、まだ優先度スコアを算出していないユーザがいる場合（No）にはステップ９０２に戻る（ステップ９０５）。
【００４５】
ステップ９０１のユーザ一覧を、ステップ９０４で算出した優先度スコアの降順に並べ替える（ステップ９０６）。優先度スコアの高いユーザからその車両情報を対象に、ユーザの運転を診断し、診断結果を診断結果管理部１２７に格納する（ステップ９０７）。診断を終了した車両情報の診断状況５０７を「済」に更新する（ステップ９０８）全ユーザの診断処理が終了した場合（Yes）には処理を終了し、終了していない場合（No）にはステップ９０７へ戻る（ステップ９０９）。
【００４６】
図１０は、ドライバ(ユーザ)へのコンテンツ(運転診断結果)提供のシーケンスを示す。ドライバはコンテンツを要求するためにボタンを押す。車載端末１０２は、そのボタン押下を入力装置１１５を介して検知する（ステップ１００１）。ドライバからのコンテンツ要求として、ボタン押下ではなく、音声コマンドによる入力を検知するようにしても良い。次に、車載端末１０２は、センタサーバ１２０と通信するために、ネットワーク１１９を介した回線の接続要求を送る（ステップ１００２）。この接続要求には、車載端末１０２を一意に識別するための車載機IDを含む。センタサーバ１２０では、送られてきた車載機IDと、通信に使用されている携帯電話の番号（通信装置１０９の識別情報）を用いて、認証部１３１でドライバ(ユーザ)を認証する（ステップ１０１１）。このユーザ認証は、車載機IDと携帯電話の番号などの通信装置１０９の識別情報とによりユーザ(ドライバ又は車両)を特定したと見なす。ユーザを特定できれば通信接続を確立し、特定できなければ通信を切断する（ステップ１０１２）。
【００４７】
通信接続を確立後、診断結果取得部１０７は、センタサーバ１２０に対して診断結果の取得要求を送る（ステップ１００３）。診断結果の取得要求には、取得したい診断結果の日付、および、車両情報蓄積部１０４の車両情報に含まれる車両の位置情報を含む。センタサーバ１２０の診断結果提供部１３０では、診断結果管理部１２７から、対象ユーザの指定日付の診断結果を取得して（ステップ１０１３）、取得した診断結果を応答データとしてデータ送受信部１２１を介して送信する（ステップ１０１４）。送信する診断結果は、診断結果管理部１２７の診断区間７０２と診断結果７０３を併せたものである。指定日付の診断結果は一つとは限らず、複数の場合もある。診断結果を受け取った車載端末１０２は通信を切断する（ステップ１００４）。診断結果提供部１３０は、診断結果を提供したログとして、提供日時や、車載端末１０２から取得した座標（車両の位置情報）を提供履歴管理部１２９に蓄積する（ステップ１０１５）。
【００４８】
車載端末１０２では、コンテンツ生成部１０６で、受け取った診断結果に基づいて、ディスプレイ１１４へ表示するコンテンツを生成し（ステップ１００５）、生成したコンテンツをディスプレイ１１４に表示する（ステップ１００６）。
【００４９】
図１１は、コンテンツ生成部１０６の処理フローを示す。まず、車両情報蓄積部１０４から、車両１０１の走行履歴として、診断結果を取得した時刻３０１の車両情報を取得する（ステップ１１０１）。次に、診断結果取得部１０７から診断結果を取得し、診断区間を特定する（ステップ１１０２）。例えば、図7の上欄の診断結果の場合、診断区間が2009年3月25日10時3分23秒〜11時1分17秒である。次に、地図を含むコンテンツを生成する場合は、走行区間を含む地図情報を取得する（ステップ１１０３）。ステップ１１０１で取得した走行履歴から、走行区間の時系列での位置情報（走行経路）を取得、その時系列での位置情報に基づいて、ナビゲーション装置１１３から地図情報を取得する。最後に、診断結果、走行区間の地図情報などを用いて表示コンテンツを生成する（ステップ１１０４）。
【００５０】
図１２Ａ及び図１２Ｂは、ドライバへ提供する、ディスプレイ１１４の画面例を示す。図１２Ａは、メニュー画面であり、ドライバは「今日のエコドライブ結果」ボタンを押すことで、その日の運転診断結果を見る。図１２Ｂは、3月25日の運転診断結果を表示した画面例である。「エコドライブ度」は、診断日がエコ運転であったか否かを点数化したものであり、センタサーバ１２０の運転診断部１２６で計算されたものである。「過剰消費量」は、発進や急加速などの非エコ運転によって無駄に消費された燃料量を、「推定燃費」は過剰消費量が0だった場合の燃費を示しており、どちらも運転診断部１２６で算出されたものである。図示を省略するが、走行経路を含む地図を必要に応じてディスプレイ１１４に表示する。
【００５１】
以上のように本実施形態によれば、ユーザからの診断結果の要求の発生を推定し、その要求に対応する車両情報を対象に優先的に運転診断できる。
【符号の説明】
【００５２】
１０１：車両、１０２：車載端末、１０３：車両情報収集部、１０４：車両情報蓄積部、１０５：データ送受信部、１０６：コンテンツ生成部、１０７：診断結果取得部、１０９：通信装置、１１０：車内ネットワーク、１１１：ECU、１１２：GPS、１１３：ナビゲーション装置、１１４：ディスプレイ、１１５：入力装置、１１９：ネットワーク、１２０：センタサーバ、１２１：データ送受信部、１２２：車両情報管理部、１２３：走行状態判定部、１２４：ルール管理部、１２５：優先度決定部、１２６：運転診断部、１２７：診断結果管理部、１２８：利用傾向判定部、１２９：提供履歴管理部、１３０：診断結果提供部、１３１：認証部、１３２：認証情報管理部。
【図１】
2011012968.tif 000003
【図２】
2011012968.tif 000004
【図３】
2011012968.tif 000005
【図４】
2011012968.tif 000006
【図５】
2011012968.tif 000007
【図６】
2011012968.tif 000008
【図７】
2011012968.tif 000009
【図８】
2011012968.tif 000010
【図９】
2011012968.tif 000011
【図１０】
2011012968.tif 000012
【図１１】
2011012968.tif 000013
【図１２Ａ】
2011012968.tif 000014
【図１２Ｂ】
2011012968.tif 000015