サーバ、車載装置、及び、評価システム
【課題】サーバで受信される診断情報の鮮度にばらつきがある場合でも、一定の信頼性のある評価情報を車載装置のユーザに提供することができる技術を提供する。
【解決手段】サーバは、更新処理を月単位と日単位とでそれぞれ実行し、このうち、月単位の更新処理では、前月の診断データを記憶部より抽出し（Ｓ４０５）、診断ポイントをユーザＩＤ単位でまとめ、累計ポイントを算出する（Ｓ４１０）。そして、この累計ポイントに基づいて、相対的な順位やステータス（Ｇｏｌｄ，Ｓｉｌｖｅｒ，Ｂｌｕｅ）等の評価データを算出する（Ｓ４１５）。したがって、特定の期間（前月）に対応する診断データに基づいてこれらの評価データが算出されるため、サーバへ診断データが集まってくるタイミングにばらつきがある場合でも、一定の信頼性のある評価データを提供することができる。
【解決手段】サーバは、更新処理を月単位と日単位とでそれぞれ実行し、このうち、月単位の更新処理では、前月の診断データを記憶部より抽出し（Ｓ４０５）、診断ポイントをユーザＩＤ単位でまとめ、累計ポイントを算出する（Ｓ４１０）。そして、この累計ポイントに基づいて、相対的な順位やステータス（Ｇｏｌｄ，Ｓｉｌｖｅｒ，Ｂｌｕｅ）等の評価データを算出する（Ｓ４１５）。したがって、特定の期間（前月）に対応する診断データに基づいてこれらの評価データが算出されるため、サーバへ診断データが集まってくるタイミングにばらつきがある場合でも、一定の信頼性のある評価データを提供することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載装置より送られてきた診断情報に基づく評価情報を生成し、生成した評価情報を車載装置に提供するサーバ、そのサーバに対して診断情報を提供するとともにサーバから評価情報の提供を受けてユーザに報知する車載装置、及び、これらをシステムとして構成した評価システムに関する。
【背景技術】
【０００２】
近年、地球環境に関する関心や社会貢献が世界的なブームとなっており、このような時代背景の中、地球環境問題に関する活動は避けて通れない状況にある。また、自動車関連メーカーにとって、それら地球環境に関する諸問題をクリアすることは、安全に関する取組みと同様、社会的使命となっている。
【０００３】
しかし、これら取組みは企業努力だけでは限界があり、個々のドライバーが環境に優しい運転を行うことが望まれる。また、環境に優しい運転は、安全運転にも繋がることから、各ドライバーの運転技術を向上させることは非常に重要テーマである。
【０００４】
運転技術を向上させる一つの方法として、ドライバーの運転内容を診断して数値化し、それを評価ポイントとしてドライバーに付与することが考えられる。そして、その評価ポイントによってドライバーのランク付けを行ったり、評価ポイントの累積値に応じて車両等の購入の際に割引を行ったりすることが考えられる。
【０００５】
このような評価ポイントを応用した仕組みを実現するシステムの一つとして、車両に搭載された診断装置で各ドライバーの診断を行い、その診断結果をセンタサーバ（以下、単に「サーバ」と称す。）に送信し、サーバで診断結果に基づいて各ドライバーの評価（例えばランク付け）を行うシステムが考えられる。このようなシステムでは、診断結果をサーバに送信する方法として大きく二つの方法が考えられる。
【０００６】
一つ目の方法は、車両に搭載されたＤＣＭ（Data Communication Module）を介して評価結果をサーバに送信する方法である。この方法であれば、ＤＣＭが基地局と通信可能な状況でありさえすれば、診断結果の算出を終えたタイミングで診断装置がサーバに診断結果を送信することができる。したがって、サーバで受信された診断結果は、直近に診断された結果である可能性が高く、鮮度の良い診断結果であると言える。
【０００７】
二つ目の方法は、乗員が車両に持ち込んだ携帯電話等の携帯端末（通信機能を有する携帯端末）を介し、診断結果をサーバに送信する方法である。この方法であれば、車両にＤＣＭが搭載されていなくても、乗員が車両に携帯端末を持ち込むことによって診断結果をサーバに送信することができる。しかしながら、診断結果が診断装置からサーバに送信されるタイミングは、ユーザの意思に左右されやすく、サーバで受信された診断結果の鮮度は安定しない。また、未送信の診断結果がまとまって送信される場合もある。
【０００８】
サーバへの診断結果の送信方法について、このように二つの方法があると、現時点でサーバに集まっている診断結果に基づいて例えばドライバーの相対的なランキング表を生成すると、ランキングが時々刻々と変化してしまうため、ランキングの信頼性が低下する。
【０００９】
ところで、このようにサーバにおいてランキング情報を生成するシステムに関しては、下記の特許文献１〜５に記載された技術が知られている。
特許文献１に記載された技術は、インターネット網や携帯電話を用いた通信ゲームに関するもので、そのゲームのランキングを閲覧できるようにしたものである。しかしながら、このゲーム端末は常時接続されることが前提となっており、その結果もセンタ側に逐次蓄積されるものであるため、上述したような問題は発生しない。
【００１０】
また、特許文献２に記載された技術は、移動体に通信網を介して情報を提供する情報提供サービスシステムにおいて、移動体から通信網を介して取得した移動体情報に基づいて運転技術情報を作成し、少なくとも１つのランキンググループ（例えば、車種、車両タイプ、走行環境等を考慮したグループ）内での順位付けを行い、その順位付けされた運転技術情報を各移動体へ提供するものである。この文献には、「運転技術ランキング」「燃費ランキング」に関する内容が記載されているが、このランキングをどのような時間間隔でランキングするか、また、どのような仕組みで移動体情報をアップロードするかについて具体的に記載されていない。
【００１１】
また、特許文献３に記載された技術は、エコ活動参加者の環境負荷削減活動を評価し、報償を与えることによってさらにエコ活動に関わる動機付けを行うことを可能にするエコ活動支援方法に関する技術である。この文献には、「エコ活動参加者に与えられる報償は、報償スポンサ−が提供する金銭や製品、また、エコ活動実績を二酸化炭素排出量に換算した後、二酸化炭素排出権取引市場で売却して得る利益、または、実績をランキング表示してインターネットを介して公表することによって得られる名誉がある」との記載があるが（特許文献３の段落「００６７」）、ランキングについての具体的な内容は記載されていない。
【００１２】
また、特許文献４に記載された技術は、運転者による車両の運転操作から安全運転度を算出し、その算出された安全運転度に基づいてランク付けを行い、安全運転を励行するものである。本文献の中には「センタ１０５では、ナビゲーション装置１００から送信されデータベース６０ｃに蓄積された各運転者の安全運転度を基に運転者のランク付けを行い、データベース６０ｃに運転者毎に記憶する」との記載はあるが（引用文献４の段落「０１５１」）、安全運転度に関するデータ送信は、１日毎に行われることが前提になっている。このため、センタで受信されるデータの鮮度には１日以上のばらつきはなく、鮮度のばらつきに関する工夫は引用文献４には記載されていない。
【特許文献１】特開２００２−２２４４５３号公報
【特許文献２】特開２００３−２０８６９６号公報
【特許文献３】特開２００５−９２８７１号公報
【特許文献４】特開２００７−１７２４８７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、上述した問題にかんがみなされたものであり、サーバで受信される診断情報の鮮度にばらつきがある場合でも、一定の信頼性のある評価情報を車載装置のユーザに提供することができる技術を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するためになされた請求項１に記載のサーバは、サーバ側通信手段と、受信情報記憶手段と、評価情報生成手段と、送信手段とを備える。サーバ側通信手段は、車載装置と通信を行うための手段である。受信情報記憶手段は、診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を、サーバ側通信手段を介して車載装置より取得し、これらを対応付けて受信情報として記憶する手段である。評価情報生成手段は、受信情報記憶手段が記憶する受信情報を参照し、過去の所定の期間に含まれるタイムスタンプに対応する診断情報より、所定の期間の評価情報をユーザと対応付けて生成し、生成した評価情報をユーザと対応付けて記憶する手段である。送信手段は、評価情報生成手段が記憶する評価情報のうち、サーバ側通信手段を介して車載装置が要求したユーザに対応する評価情報を、サーバ側通信手段を介して要求元の車載装置へ送信する手段である。なお、評価情報としては、車載装置において行われた評価の結果の情報であってもよいし、評価に用いられる情報であって車載装置において収集された情報であってもよい。
【００１５】
このような手段を備えるサーバであれば、所定の期間に対応する診断情報に基づいて評価情報が生成されるため、サーバへ情報が集まってくるタイミングにばらつきがある場合でも、所定の期間を適切に設定することにより、一定の信頼性のある評価情報を提供することができる。
【００１６】
ところで、上述したように、診断情報をサーバに送信する方法としては、車両に常時搭載された通信装置、例えば、ＤＣＭ（Data Communication Module）を介して評価情報をサーバに送信する方法と、乗員が車両に持ち込んだ携帯電話等の携帯端末を介して診断情報をサーバに送信する方法とが考えられる。この場合、ＤＣＭを介してサーバに送られてくる診断情報は、携帯端末を介してサーバに送られてくる診断情報に比較して鮮度が良い。そのような鮮度が良い診断情報を送信してくるＤＣＭを介して通信を行う車載装置に対しては、携帯端末を介して通信を行う車載装置よりも何らかの優遇を提供できると良い。そして、優遇が提供できれば、ＤＣＭを介して通信を行う車載装置が増え、ひいては鮮度の良い診断情報がサーバにさらに集まることとなる。
【００１７】
そのような優遇策を提供できるサーバの一つとして、例えば、請求項２に記載のようなサーバを構成することが考えられる。すなわち、サーバ側通信手段が車載装置と通信を行う際、その車載装置が車両に常時搭載された通信装置経由で通信を行う車載装置であるか否かを判定する判定手段をさらに備えるようにサーバを構成し、評価情報生成手段は、所定の期間の一つであって、上記通信装置経由で通信を行う車載装置向けの期間により、上記通信装置経由で通信を行う車載装置向けの評価情報をさらに生成して記憶し、送信手段は、上記通信装置経由で通信を行う車載装置であると判定手段により判定された車載装置に対してのみ、上記通信装置経由で通信を行う車載装置向けの評価情報を送信するようにサーバを構成することが考えられる。具体的には例えば、携帯端末を介して通信を行う車載装置に対しては、先月の診断情報に基づいて生成された評価情報と先週の診断情報に基づいて生成された評価情報を提供し、ＤＣＭを介して通信を行う車載装置に対しては、さらに、昨日の診断情報に基づいて生成された評価情報を提供することが考えられる。
【００１８】
このようなサーバであれば、鮮度が良い診断情報を送信してくる可能性が高い車載装置、すなわち、車両に常時搭載された通信装置経由で通信を行う車載装置に対して、特別な評価情報を提供することができる。その結果、車両に常時搭載された通信装置経由で通信を行う車載装置が増え、鮮度の良い診断情報がより集まることとなる。
【００１９】
ところで、上記所定の期間は、その長さによって繰り返されるとよい。つまり、請求項３に記載のように、評価情報生成手段は、上記所定の期間の長さで繰り返し評価情報を生成するようになっているとよい。具体的には例えば、所定の期間として「一週間」と設定した場合、毎週、前週に対応する評価情報を生成するとよい。
【００２０】
このようになっていれば、期間毎の評価情報を比較することができ、例えば、前の期間よりも評価が上がったとか下がったとかという比較ができる。
ところで、「ユーザ」を個人という単位ではなく、サーバにおける登録ユーザという単位で捉えると、例えば、夫婦で１つのユーザをサーバへ登録することを許容する運用も考えられる。このような場合、夫婦で複数台の車両を保有している場合や、夫婦のうちのどちらかが保有車両以外にレンタカーを運転した場合等には、複数の車載装置から同時期に同一のユーザについての診断情報がサーバに送信される可能性がある。「ユーザ」を個人という単位で捉えているならば、同時期に同一のユーザについての診断情報がサーバに送信された場合、異常情報としてその診断情報を破棄することもできる。しかし、「ユーザ」をサーバにおける登録ユーザという単位で捉えている場合には、同時期に同一のユーザについての診断情報がサーバに送信されたということをもって、診断情報を破棄することはできない。けれども、車載装置の故障等によって複数回、同一の診断情報がサーバに送信されてしまう場合が想定され、このような場合は異常情報としてその診断情報を破棄することが好ましい。
【００２１】
そこで、請求項４に記載のようなサーバが考えられる。つまり、受信情報記憶手段が、受信情報と共に、車載装置を特定することができる車載装置特定情報を、サーバ側通信手段を介して車載装置より取得し、受信情報と対応付けて記憶し、評価情報生成手段が、タイムスタンプ、ユーザ特定情報及び車載装置特定情報の組み合わせが重複する診断情報については、評価情報を生成しないようになったサーバが考えられる。
【００２２】
このようなサーバであれば、「ユーザ」をサーバにおける登録ユーザという単位で捉えている場合であっても、車載装置の故障等によって重複して送信された診断情報が用いられて、評価情報が生成されることを防止できる。
【００２３】
ところで、評価情報としては、診断情報に基づくものであればどのような情報であってもよいが、例えば、ユーザの相対的な順位であるとよい。すなわち、請求項５に記載のように、評価情報生成手段は、期間内に係る診断情報毎にポイントを求め、期間内におけるポイントの累計値である第一の累計値により、ユーザの相対的な順位を決定し、その決定した順位を評価情報とし、ユーザと対応付けて記憶するようになっているとよい。
【００２４】
このようになっていれば、相対的な順位を知ったユーザは、より順位を上げたいと考え、運転技術の向上を図る努力をすると考えられる。
また、評価情報は、相対的なものではなく絶対的なもの、例えば、ステータスであってもよい。すなわち、請求項６に記載のように、評価情報生成手段は、期間内に係る診断情報毎にポイントを求め、期間内におけるポイントの累計値である第二の累計値により、ユーザが複数の絶対的なステータスのうちのいずれのステータスに属するかを決定し、その決定したステータスを特定する情報であるステータス情報を評価情報とし、ユーザと対応付けて記憶するようになっているとよい。
【００２５】
このようになっていれば、自身のステータスを知ったユーザは、より上位のステータスを得ようと考え、運転技術の向上を図る努力をすると考えられる。
ところで、車載装置のユーザは、上述したような信頼性の高い評価情報としてのステータスが得られるのであれば、たとえ多少信頼性が劣ったとしても、より現在の状況に近い
評価情報や、より努力結果が細かくわかる評価情報について、さらに得たいと考える。
【００２６】
そこで、請求項７に記載のようなサーバが考えられる。つまり、評価情報生成手段が、直前の期間以降に係る前断情報毎にポイントを求め、直前の期間以降のポイントの累計値である第三の累計値により、上記ステータスが細分化された複数のランクのうちのいずれのランクにユーザが属するかを決定し、その決定したランクを特定する情報であるランク情報についても評価情報とし、ユーザと対応付けてさらに記憶するようになったサーバが考えられる。
【００２７】
このようなサーバであれば、車載装置のユーザは、現在の状況に近く、努力結果が細かくわかる情報（ランク）についても知ることができる。
なお、上述したようなステータスとの関係を有するランクについても、評価情報として算出するようになったサーバであると、車載装置に送信されるステータスと、車載装置に送信されるランクが属するステータスとで、齟齬が生じるケースが発生し得る。具体的には、決定されたステータスと、決定されたランクが属するステータスとが異なる場合があり得る。これは、ステータスを算出した際に利用した診断情報の期間と、ランクを算出した際に利用した期間が異なるからであるが、このような齟齬が生じると、ステータスとランクとを同時に並べてユーザに表示するような場合に、ユーザに混乱を生じさせるおそれがある。
【００２８】
そこで、請求項８に記載のようなサーバが考えられる。つまり、評価情報生成手段が、ランクの決定に際し、第三の累計値が、直前の期間のステータスにおける最低ランクの条件に満たない場合でも、直前の期間のステータスにおける最低ランクに属するものとしてランクを決定し、第三の累計値が、直前の期間のステータスにおける最高ランクの条件を超える場合でも、直前の期間のステータスにおける最高ランクに属するものとしてランクを決定するようになったサーバが考えられる。
【００２９】
このようなサーバであれば、上述した齟齬の発生を防止することができる。
ところで、上述したサーバに対応する車載装置とてしては、例えば、請求項９に記載のような、車載装置側通信手段と、車載装置側記憶手段と、報知手段と、第一制御手段と、第二制御手段とを備えた車載装置が考えられる。車載装置側通信手段はサーバと通信を行う手段である。車載装置側記憶手段は、診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を記憶する手段である。報知手段は、情報を報知する手段である。第一制御手段は、車載装置側記憶手段に記憶されている診断情報、タイムスタンプ、及び、ユーザ特定情報を、車載装置側通信手段を介してサーバへ送信する手段である。第二制御手段は、車載装置側通信手段に記憶されているユーザ特定情報に対応する評価情報を、車載装置側通信手段を介してサーバに要求し、車載装置側通信手段を介してサーバより送信されてきた評価情報を報知手段に報知させる手段である。
【００３０】
このような車載装置であれば、サーバへ情報を送信するタイミングにばらつきがある場合でも、サーバより一定の信頼性のある評価情報を受信し、ユーザに提供（報知）することができる。
【００３１】
なお、何らかの事情、例えばユーザの操作ミス等により、サーバに対して診断情報を重複して送信することを防ぐためには、例えば、請求項１０に記載のように、第一制御手段は、車載装置側記憶手段に記憶されている診断情報をサーバへ送信すると、車載装置側記憶手段に記憶されている診断情報を削除するようになっているとよい。
【００３２】
このようになっていれば、サーバに診断情報が重複して送信されることを防止することができる。
ところで、上述したサーバと上述した車載装置とを組み合わせた評価システムとして発明を構成してもよい（請求項１１）。なお、このような評価システムであっても、上述したサーバの効果や車載装置の効果を得ることができることは言うまでもない。
【発明を実施するための最良の形態】
【００３３】
以下、本発明が適用された実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００３４】
［構成の説明］
図１は、本発明の実施形態である評価システム５を表すブロック図である。評価システム５は、サーバ１０と、診断装置２０ａ，２０ｂと、ＤＣＭ４０と、携帯電話５０と、公衆ネットワーク６０とを有する。サーバ１０は、公衆ネットワーク６０と接続され、その公衆ネットワーク６０を介してＤＣＭ４０及び携帯電話５０と通信を行う。そして、ＤＣＭ４０は診断装置２０ａと接続され、携帯電話５０は診断装置２０ｂと接続されているため、サーバ１０は、結果として、診断装置２０ａと診断装置２０ｂとも通信を行うことができる。なお、サーバ１０と公衆ネットワーク６０は、有線接続されている。また、ＤＣＭ４０と公衆ネットワーク６０、及び、携帯電話５０と公衆ネットワーク６０は、携帯電話事業者等が提供する広域無線通信パケット網によって接続されている。また、ＤＣＭ４０と診断装置２０ａは、有線接続されている。また、携帯電話５０と診断装置２０ｂは、Ｂｌｕｅｔｏｏｔｈ（登録商標）によって接続されている。また、図１には、ＤＣＭ４０と診断装置２０ａ、携帯電話５０と診断装置２０ｂは、それぞれ一組ずつしか描かれていないが、実際は複数存在する。
【００３５】
（１）サーバ１０
まず、サーバ１０の構成について、図２のブロック図を用いて説明する。サーバ１０は、通信部１１と、記憶部１２と、操作部１３と、制御部１４とを備える。
【００３６】
通信部１１は、公衆ネットワーク６０と通信を行うための機能を有しており、制御部１４によって制御される。
記憶部１２は、不揮発性の記憶媒体（例えば、ハードディスク等）を有しており、後述する診断データ、後述する評価データ、及び、制御部１４が実行するプログラム等を記憶する。
【００３７】
操作部１３は、キーボード、マウス等を備え、サーバ１０の管理者からの指令を受け付けることができる。
制御部１４は、ＣＰＵ，ＤＲＡＭ，ＲＯＭ，フラッシュメモリ，Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭ及びフラッシュメモリ等に記憶されたプログラムに基づいて各種処理を実行する。具体的な処理内容については後述する。
【００３８】
（２）診断装置２０ａ，２０ｂ
次に、診断装置２０ａ，２０ｂについて説明する。なお、以下においては、診断装置２０ａと診断装置２０ｂとを区別する必要がある場合を除き、診断装置２０としてまとめて説明する。
【００３９】
図３は、診断装置２０の概略構成を示すブロック図である。診断装置２０は車両に搭載され、車両の現在位置を検出する検出部２１と、Ｂｌｕｅｔｏｏｔｈによる無線通信を行うＢＴ通信部２５と、ユーザからの各種指示を入力するための操作スイッチ群２８と、操作スイッチ群２８と同様に各種指示を入力可能であって診断装置２０の本体とは別体となったリモートコントロール端末（以下、リモコンと称す）２７と、リモコン２７からの信号を入力するリモコンセンサ２６と、地図データや音声データ等が記録された地図記憶媒体からデータを入力する地図データ入力部２９と、地図や各種情報の表示を行うための表示部３０と、各種のガイド音声等を出力するための音声出力部３１と、ユーザ等が発話した音声を入力して音声信号に変換する音声入力部３２と、車内ＬＡＮに接続された各種ＥＣＵ等と通信を行う車内ＬＡＮ通信部３３と、各種情報を記憶する記憶部３４と、上述した検出部２１，ＢＴ通信部２５，操作スイッチ群２８，リモコンセンサ２６，地図データ入力部２９，音声入力部３２，車内ＬＡＮ通信部３３，記憶部３４からの入力に応じて各種処理を実行し、ＢＴ通信部２５，表示部３０，音声出力部３１，車内ＬＡＮ通信部３３，記憶部３４を制御する制御部３９とを備えている。
【００４０】
検出部２１は、ＧＰＳ（Global Positioning System）用の人工衛星からの電波を図示しないＧＰＳアンテナを介して受信してその受信信号を制御部３９へ出力するＧＰＳ信号受信部２２と、車両に加えられる回転運動の大きさを検出してその検出結果を制御部３９へ出力するジャイロスコープ２３と、車両の走行した距離を検出してその検出結果を制御部３９へ出力する距離センサ２４とを備えている。そして、これら各部２２〜２４からの出力信号に基づいて制御部３９が、車両の位置，方位，速度等を算出する。なお、ＧＰＳ信号受信部２２からの出力信号に基づいて現在位置を求める方式は様々な方式があるが、単独測位方式、相対測位方式のいずれであってもよい。
【００４１】
操作スイッチ群２８は、表示部３０の表示面と一体に構成されたタッチパネル及び表示部３０の周囲に設けられたメカニカルなキースイッチ等から構成される。なお、タッチパネルと表示部３０とは積層一体化されており、タッチパネルには、感圧方式，電磁誘導方式，静電容量方式，あるいはこれらを組み合わせた方式など各種の方式があるが、そのいずれを用いてもよい。
【００４２】
リモコン２７は、複数のボタンから構成されており、いずれかのボタンが押下されるとそのボタンの種類に応じた信号が赤外線等の近距離無線通信を介してリモコンセンサ２６に届くように構成されている。
【００４３】
リモコンセンサ２６は、リモコン２７から送られる信号を受信し、受信した信号を制御部３９へ出力するようになっている。
ＢＴ通信部２５は、Ｂｌｕｅｔｏｏｔｈによって携帯電話と通信を行う機能を有する。
【００４４】
地図データ入力部２９は、図示しない地図データ記憶媒体（例えばハードディスクやＤＶＤ−ＲＯＭ等）に記憶された各種データを入力するための装置である。地図データ記憶媒体には、地図データ（ノードデータ、リンクデータ、道路幅員データ、道路種別データ、通行規制データ、リンク旅行時間、道路名称データ、交差点データ等）、ＰＯＩデータ（ＰＯＩ名称データ、ジャンルデータ、位置データ等）、案内用の音声データ、音声認識データ等が記憶されている。なお、地図データ記憶媒体からこれらのデータを入力する代わりに、通信ネットワークを介してこれらのデータを入力するようになっていてもよい。
【００４５】
表示部３０は、液晶ディスプレイや有機ＥＬディスプレイ等からなり、表示部３０の表示画面には、検出部２１にて検出した車両の現在位置と地図データ入力部２９より入力された地図データとから特定した現在地を示すマーク、目的地までの誘導経路、名称、目印、各種施設のマーク等の付加データとを重ねて表示することができる。また、施設のガイド等も表示できる。
【００４６】
音声出力部３１は、スピーカを有し、制御部３９より入力された音声信号をスピーカより音声として出力することができる。
音声入力部３２は、マイクを有し、マイクに入力された利用者の音声に基づく音声信号を制御部３９に出力することができる。利用者は、マイクに対して発話することにより、診断装置２０に対して音声による指令を入力することができる。
【００４７】
車内ＬＡＮ通信部３３は、車内ＬＡＮ（図示せず）に接続された各種のＥＣＵ（エンジンＥＣＵ、ＡＴ−ＥＣＵ、ブレーキＥＣＵ等）や各種のセンサ（車速センサ、シフトポジションセンサ、前照灯センサ等）との通信を担う。
【００４８】
記憶部３４は、不揮発性の記憶媒体（例えば、ハードディスク、ＳＳＤ等）からなり、各種の情報を記憶することができる。
制御部３９は、ＣＰＵ，ＤＲＡＭ，ＲＯＭ，フラッシュメモリ，Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭ及びフラッシュメモリ等に記憶されたプログラムに基づいて各種処理を実行する。例えば、検出部２１からの各検出信号に基づき座標及び進行方向の組として車両の現在位置を算出する現在位置算出処理や、地図データ入力部２９を介して読み込んだ現在走行中の道路の交通規則を特定する交通規則特定処理や、検出部２１からの各検出信号に基づいて算出した車速が交通規則特定処理によって特定された交通規則に合致しているかどうかといった種々の診断をしてその診断結果を記憶部３４に記憶する診断処理等を実行する。
【００４９】
（３）ＤＣＭ４０
ＤＣＭ４０は、診断装置２０ａが搭載された車両と同一の車両に搭載された通信モジュール（Data Communication Module）であり、車両のドライバー等が容易に車両から取り外すことができないものである。ＤＣＭ４０は、診断装置２０ａと有線接続されるとともに、公衆ネットワーク６０と無線パケット通信を行い、公衆ネットワーク６０につながったサーバ１０と通信を行うことができる。したがって、診断装置２０とサーバ１０との間での通信を可能にする。
【００５０】
（４）携帯電話５０
通話機能、メール送受信機能、Ｗｅｂ閲覧機能、Ｂｌｕｅｔｏｏｔｈ通信機能、無線パケット通信機能等を有する周知の携帯電話である。なお、Ｂｌｕｅｔｏｏｔｈ通信機能というのは、携帯電話５０の近傍（１０ｍ以下）に存在する他の装置（例えば診断装置２０）とＢｌｕｅｔｏｏｔｈ通信によってデータを送受信する機能である。また、無線パケット通信機能というのは、公衆ネットワーク６０に接続された他の装置（例えばサーバ１０）と広域無線通信によってデータを送受信する機能である。携帯電話５０は、Ｂｌｕｅｔｏｏｔｈ通信機能と無線パケット通信機能とを組み合わせて動作させることもできる（つまり、診断装置２０とサーバ１０との間で通信を可能にする）。
【００５１】
［診断装置２０の動作の説明］
まず、診断装置２０の動作について説明する。診断装置２０は、下記の診断装置側送信処理Ａと診断装置側送信処理Ｂについて、択一的に実行する。なお、診断装置２０ａは、ＤＣＭ４０と接続されていることが予め登録されているため、診断装置側送信処理Ａを実行し、診断装置２０ｂは、ＤＣＭ４０と接続されていることが予め登録されていないため、診断装置側送信処理Ｂを実行する。また、診断装置２０は、診断装置側送信処理Ａ，Ｂ以外にも診断処理を実行する。この診断処理は、例えば、車両が停止した毎に、前回の停止時以降になされた運転操作を診断し、その診断結果を点数化して診断データとして記憶する処理である。具体的な診断方法については、周知の技術を利用することとし、説明は省略する。
【００５２】
（１）診断装置側送受信処理Ａ
診断装置２０ａの制御部３９が実行する車載装置側送受信処理Ａについて、図４のフローチャートを用いて説明する。なお、診断装置側送受信処理Ａは、診断装置２０ａへの電力供給が開始された際、例えば、搭載車両のアクセサリスイッチがオンになった際に、実行が開始される処理である。
【００５３】
診断装置２０ａの制御部３９は、診断装置側送受信処理Ａの実行を開始すると、まず、ＤＣＭ４０が公衆ネットワーク６０に接続可能な状態か否かを判定する（Ｓ１０５）。例えば、制御部３９が主導し、サーバ１０へ所定のパケットをＤＣＭ４０に送信させ、そのパケットの応答が所定時間内にサーバ１０よりＤＣＭ４０に届いたか否かを判定することによって上記判定を行うことが考えられる。制御部３９は、このＳ１０５において、ＤＣＭ４０は公衆ネットワーク６０に接続可能な状態であると判定した場合は（Ｓ１０５：Ｙｅｓ）、Ｓ１１０へ処理を移行し、ＤＣＭ４０は公衆ネットワーク６０に接続可能な状態でないと判定した場合は（Ｓ１０５：Ｎｏ）、ＤＣＭ４０が公衆ネットワーク６０に接続可能になるまで本ステップにとどまる。
【００５４】
ＤＣＭ４０を介して通信可能と判定した場合に進むＳ１１０では、記憶部３４に診断データがあるか否か否かを判定する。なお、本実施形態でいう「診断データ」は、以下の情報から構成される。
【００５５】
・ユーザＩＤ：ユーザを一意に識別するためのＩＤ
・診断装置ＩＤ：診断装置を一意に識別するためのＩＤ
・タイムスタンプ：診断データが生成された日時を示す情報
・診断ポイント：診断を行った結果の点数（ポイント）
このような診断データが、診断タイミング毎（例えば、車両が停車したタイミング毎）に生成されて記憶部３４に逐次記憶される。
【００５６】
制御部３９は、Ｓ１１０において、診断データが記憶部３４にあると判定した場合は（Ｓ１１０：Ｙｅｓ）、Ｓ１１５へ処理を移行し、一方、診断データは記憶部３４にないと判定した場合は（Ｓ１１０：Ｎｏ）、Ｓ１２５へ処理を移行する。
【００５７】
診断データが記憶部３４にあると判定した場合に進むＳ１１５では、制御部３９は、その診断データを記憶部３４より読み出し、ＤＣＭ４０を介してサーバ１０へ送信することを開始する。なお、診断データをサーバ１０へ送信することに先立ち、サーバ１０に対して診断データの受信要求を送信する。また、送信した診断データについては、記憶部３４から削除する。
【００５８】
続いて、制御部３９は、記憶部３４に記憶されている診断データを全て送信したか否かを判定する（Ｓ１２０）。診断データを全て送信したと判定した場合は（Ｓ１２０：Ｙｅｓ）、Ｓ１２５へ処理を移行し、一方、診断データがまだ残っていると判定した場合は（Ｓ１２０：Ｎｏ）、記憶部３４に記憶されている診断データが全て送信されるまで本ステップにとどまる。
【００５９】
Ｓ１１０で否定判定された場合、又は、Ｓ１２０で肯定判定された場合に進むＳ１２５では、制御部３９は、記憶部３４に記憶されている評価データの更新日時を調べ、評価データが所定期間以上前のものか否かを判定する。ここでいう「所定期間」というのは、例えば、１日や１週間といった程度の期間が考えられる。ここで「評価データ」について説明する。評価データは、サーバ１０で生成されて診断装置１０に送られてくるデータである。そして、評価データは、以下の情報から構成されており、ユーザ単位で存在するデータである。
【００６０】
・ユーザＩＤ：ユーザを識別するためのＩＤ
・月間順位：前月の相対的な順位である。
・累計ポイント点数：年初から前日までの診断データに含まれる診断ポイントの累計
ポイント
・ステータス情報：前月の診断データに基づいて決定されたステータスを表す情報
（例：「Ｇｏｌｄ」）
・ランク情報：月初から前日までの診断データに基づいて決定されたランクを表す情
報（例：「３」）
・前年自己ベスト：前年の最も良かった月間順位とその月である。
【００６１】
・本年自己ベスト：本年の最も良かった月間順位とその月である。
・更新日時：評価データが更新された日時である。
制御部３９は、このＳ１２５において、記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものであると判定した場合は（Ｓ１２５：Ｙｅｓ）、Ｓ１３５へ処理を移行し、一方、記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものでないと判定した場合は（Ｓ１２５：Ｎｏ）、Ｓ１３０へ処理を移行する。
【００６２】
記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものでないと判定した場合に進むＳ１３０では、記憶部３４に記憶されている評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、本処理（診断装置側送受信処理Ａ）を終了する。
【００６３】
一方、記憶部３４に記憶されている評価データの更新日時が所定期間以上前のものであると判定された場合に進むＳ１３５では、制御部３９は、最新の評価データを送信する旨の要求である送信要求を、ＤＣＭ４０を介してサーバ１０へ送信する。なお、この送信要求は、制御部３９のフラッシュメモリに予め登録されているユーザＩＤを含めて送信する。
【００６４】
続いて、制御部３９は、ＤＣＭ４０を介してサーバ１０より評価データを受信する（Ｓ１４０）。なお、受信した評価データは記憶部３４に上書き記憶させる。
続いて、制御部３９は、サーバ１０より評価データの受信を完了したか否かを判定する（Ｓ１４５）。これは、例えば、サーバ１０より送信終了を意味する指令を受信した場合に、評価データの受信を完了したと判定することが考えられる。制御部３９は、このＳ１４５において、サーバ１０より評価データの受信を完了したと判定した場合は（Ｓ１４５：Ｙｅｓ）、Ｓ１５０へ処理を移行し、一方、サーバ１０より評価データの受信を完了していないと判定した場合は（Ｓ１４５：Ｎｏ）、Ｓ１５５へ処理を移行する。
【００６５】
サーバ１０より評価データの受信を完了したと判定した場合に進むＳ１５０では、受信した最新の評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、本処理（診断装置側送受信処理Ａ）を終了する。
【００６６】
一方、サーバ１０より評価データの受信を完了していないと判定した場合に進むＳ１５５では、受信がタイムアウトしたか否かを判定する。具体的には、例えば、サーバ１０より評価データ又は送信終了を意味する指令を受信することなく、所定時間（例えば、１分間）経過したか否かを判定することにより、受信がタイムアウトしたか否かを判定することが考えられる。制御部３９は、このＳ１５５において、受信がタイムアウトとしたと判定した場合は（Ｓ１５５：Ｙｅｓ）、Ｓ１６０へ処理を移行し、一方、受信はタイムアウトしていないと判定した場合は（Ｓ１５５：Ｎｏ）、Ｓ１４５へ処理を戻す。
【００６７】
受信はタイムアウトとしたと判定した場合に進むＳ１６０では、記憶部３４に記憶されている評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、Ｓ１２５へ処理を戻す。
【００６８】
（２）診断装置側送受信処理Ｂ
次に、診断装置２０ｂの制御部３９が実行する診断装置側送受信処理Ｂについて、図５のフローチャートを用いて説明する。なお、診断装置側送受信処理Ｂは、診断装置２０ｂへの電力供給が開始された際、例えば、搭載車両のアクセサリスイッチがオンになった際に、実行が開始される処理である。
【００６９】
診断装置２０ｂの制御部３９は、診断装置側送受信処理Ｂの実行を開始すると、まず、ＢＴ通信部２５を介して携帯電話５０と通信可能であるか否かを判定する（Ｓ２０５）。例えば、所定のパケットを、ＢＴ通信部２５を介して携帯電話５０へ送信し、その応答が所定時間内に得られるか否かで判定する方法が考えられる。制御部３９は、このＳ２０５において、ＢＴ通信部２５を介して携帯電話５０と通信可能であると判定した場合は（Ｓ２０５：Ｙｅｓ）、Ｓ２１０へ処理を移行し、一方、ＢＴ通信部２５を介して携帯電話５０と通信可能でないと判定した場合は（Ｓ２０５：Ｎｏ）、ＢＴ通信部２５を介して携帯電話５０と通信可能になるまで本ステップにとどまる。
【００７０】
ＢＴ通信部２５を介して携帯電話５０と通信可能であると判定した場合に進むＳ２１０では、診断データを送信する旨の操作が操作スイッチ群２８に対してユーザよりなされたか否かを判定する。診断データを送信する旨の操作がなされたと判定した場合は（Ｓ２１０：Ｙｅｓ）、Ｓ２１５へ処理を移行し、診断データを送信する旨の操作はなされていないと判定した場合は（Ｓ２１０：Ｎｏ）、Ｓ２０５へ処理を戻す。
【００７１】
診断データを送信する旨の操作がなされたと判定した場合に進むＳ２１５では、制御部３９は、携帯電話５０が、公衆ネットワーク６０に接続可能な状態であるか否かを判定する。例えば、制御部３９が主導し、サーバ１０へ所定のパケットを携帯電話５０に送信させ、そのパケットの応答がサーバ１０より携帯電話５０に届いたか否かを判定することによって上記判定を行うことが考えられる。制御部３９は、このＳ２１５において、携帯電話５０は公衆ネットワーク６０に接続可能な状態であると判定した場合は（Ｓ２１５：Ｙｅｓ）、上述した診断装置側送受信処理ＡのＳ１１０及びＳ１１０に続く処理を実行し、一方、携帯電話５０は公衆ネットワーク６０に接続可能な状態でないと判定した場合は（Ｓ２１５：Ｎｏ）、上述したＳ２０５に処理を戻す。なお、上述した診断装置側送受信処理ＡのＳ１１０及びＳ１１０に続く処理を実行する場合は、診断装置側送受信処理Ａの説明において記載したＤＣＭ４０を携帯電話５０と読み替えて実行するものとする。
【００７２】
［サーバ１０の動作の説明］
次にサーバ１０の動作について説明する。
（１）サーバ側送受信処理
サーバ１０の制御部１４が実行するサーバ側送受信処理について、図６のフローチャートを用いて説明する。なお、サーバ側送受信処理は、診断装置２０より何らかの要求、具体的には、受信要求又は送信要求を受け付けた際に実行が開始される。なお、ここでいう「受信要求」というのは、診断装置２０より送信される受信要求であり、上述した診断装置側送受信処理ＡのＳ１１５で送信される受信要求である。また、ここでいう「送信要求」というのは、診断装置２０より送信される送信要求であり、上述した診断装置側送受信処理ＡのＳ１３５で送信される送信要求である。
【００７３】
制御部１４は、サーバ側送受信処理の実行を開始すると、まず受けた要求は受信要求か否かを判定する（Ｓ３０５）。受けた要求は受信要求であると判定した場合は（Ｓ３０５：Ｙｅｓ）、Ｓ３１０へ処理を移行し、受けた要求は受信要求ではないと判定した場合は（Ｓ３０５：Ｎｏ）、Ｓ３１５へ処理を移行する。
【００７４】
受けた要求は受信要求であると判定した場合に進むＳ３１０では、制御部１４は、診断装置２０より診断データを受信して記憶部１２に記憶する。記憶を終えると、制御部１４は、Ｓ３１５へ処理を移行する。
【００７５】
Ｓ３１５では、制御部１４は送信要求を診断装置２０より受けたか否かを判定する。送信要求を受けたと判定した場合は（Ｓ３１５：Ｙｅｓ）、Ｓ３２５へ処理を移行し、送信要求を受けていないと判定した場合は（Ｓ３１５：Ｎｏ）、Ｓ３２０へ処理を移行する。
【００７６】
送信要求を受けていないと判定した場合に進むＳ３２０では、最初にＳ３１５の判定を行ってから所定時間が経過したか否かを判定する。ここで言う「所定時間」としては、例えば、１分程度が考えられる。制御部１４は、このＳ３２０において、所定時間経過したと判定した場合は（Ｓ３２０：Ｙｅｓ）、本処理（サーバ側送受信処理）を終了し、まだ所定時間経過していないと判定した場合は（Ｓ３２０：Ｎｏ）、Ｓ３１５へ処理を戻す。
【００７７】
送信要求を受けたと判定した場合に進むＳ３２５では、制御部１４は、送信要求の中に含まれるユーザＩＤに対応する評価データを記憶部１２より読み出して送信する。送信が完了すると、制御部１４は、本処理（サーバ側送受信処理）を終了する。
【００７８】
（２）更新処理（月単位）
次に、サーバ１０の制御部１４が実行する更新処理について、図７のフローチャートを用いて説明する。なお、更新処理（月単位）は、毎月の始めに実行が開始される処理である。
【００７９】
制御部１４は、更新処理（月単位）の実行を開始すると、前月の診断データを記憶部１２より抽出する（Ｓ４０５）。
続いて、制御部１４は、Ｓ４０５で抽出された診断データ毎に診断ポイントを特定し、その特定した診断ポイントをユーザＩＤ単位でまとめ、各ユーザの合計診断ポイントを累計ポイントとして算出する（Ｓ４１０）。
【００８０】
続いて、制御部１４は、Ｓ４１０で算出した各ユーザの累計ポイントに応じて、相対的な順位及びステータスを決定し、その情報を記憶部１２に記憶させる（Ｓ４１５）。制御部１４は、相対的な順位及びステータスの情報を記憶部１２に記憶させると、本処理（更新処理（月単位））を終了する。
【００８１】
（３）更新処理（日単位）
次に、サーバ１０の制御部１４が実行する更新処理（日単位）について、図８のフローチャートを用いて説明する。なお、更新処理（日単位）は、毎日の０：００に実行が開始される処理である。
【００８２】
制御部１４は、更新処理（日単位）の実行を開始すると、今月の始めから昨日までの診断データを記憶部１２より抽出する（Ｓ５０５）。
続いて、制御部１４は、Ｓ５０５で抽出された診断データ毎に診断ポイントを特定し、その特定した診断ポイントをユーザＩＤ単位でまとめ、各ユーザの合計診断ポイントを累計ポイントとして算出する（Ｓ５１０）。
【００８３】
続いて、制御部１４は、Ｓ５１０で算出した各ユーザの累計ポイントに応じて、ランクを決定し、その情報を記憶部１２に記憶させる（Ｓ４１５）。なお、ランクの決定の際には、今月の始めから昨日までの診断データに基づいて決定されたランクが、前月の診断データに基づいて決定されたステータス内に含まれるようにランクを決定する。この具体例については後述する。制御部１４は、ランクの情報を記憶部１２に記憶させると、本処理（更新処理（日単位））を終了する。
【００８４】
［ステータスとランクについて］
次に、図９の説明表を用いて、ステータスとランクについて説明する。
ステータスとしては、「Ｇｏｌｄ」、「Ｓｉｌｖｅｒ」、「Ｂｌｕｅ」の３つのステータスが存在する。「Ｇｏｌｄ」は、ハイクラスとしての位置づけである。「Ｓｉｌｖｅｒ」は、ミドルクラスとしての位置づけである。「Ｂｌｕｅ」はエントリークラスとしての位置づけである。
【００８５】
また、各ステータスには、ランクとして「１」「２」「３」が存在する。数字が小さいほど評価は高い。
なお、ステータス「Ｂｌｕｅ」、ランク「３」が、評価の初期ステータス及びランクである。
【００８６】
［ステータスとランクが変動する様子について］
次に、図１０のグラフを用いて、ステータスとランクの変動について説明する。
図１０（ａ）は、ステータスの変動を示すグラフである。１月１日から２月１日の期間に表示部１０に表示されるステータスは、当該期間の累計ポイントにかかわらず初期の評価ステータスである「Ｂｌｕｅ」である（１月１日から診断を開始した場合）。２月１日から３月１日の期間に表示されるステータスは、直前の期間である１月１日から２月１日の期間の累計ポイントに基づいて決定される「Ｂｌｕｅ」である。３月１日から４月１日の期間に表示されるステータスは、直前の期間である２月１日から３月１日の期間の累計ポイントに基づいて決定される「Ｓｉｌｖｅｒ」である。４月１日から５月１日の期間に表示されるステータスは、直前の期間である３月１日から４月１日の期間の累計ポイントに基づいて決定される「Ｂｌｕｅ」である。
【００８７】
このように、直前の期間（前月）の累計ポイントに基づいて決定されるステータスが翌期間（当月）のステータスとして表示部３０に表示される。
図１０（ｂ）は、ランクの変動を示すグラフである。５月の累計ポイントは、５月１０日にステータス「Ｂｌｕｅ」に属するランク「２」（以下、ランクについて、「Ｂ−２」といった形式で記載する。）の閾値に達し、５月２０日に「Ｂ−１」のランクの閾値に達し、５月２５日頃に「Ｓ−３」の閾値に達している。実際に表示部３０に表示されるランクは、５月１日から５月１０日は、「Ｂ−３」が表示され（実際にはランクとしては「３」のみが表示部３０に表示される）、５月１０日から５月２０日は「Ｂ−２」が表示され（実際にはランクとしては「２」のみが表示部３０に表示される）、５月２０日から６月１日までは「Ｂ−１」が表示される（実際にはランクとしては「１」のみが表示部３０に表示される）。このように、月が変わるまでは、別のステータスに属するランクには移行しない。
【００８８】
６月１日以降に表示部３０に表示されるランクは、前月末の時点で前月の累計ポイントがステータス「Ｓｉｌｖｅｒ」の閾値を超えているため、当該月の累計ポイントが「Ｓ−３」の閾値に満たなくても「Ｓ−３」が表示され（６月１日から６月２５日）、当該月の累計ポイントが「Ｓ−２」の閾値を超えた時点（６月２５日）から月末までは、「Ｓ−２」が表示される（実際にはランクとしては「２」のみが表示される）。
【００８９】
７月１日以降に表示部３０に表示されるランクは、前月末の時点で前月の累計ポイントがステータス「Ｓｉｌｖｅｒ」の閾値を超えているため、当該月の累計ポイントが「Ｓ−３」の閾値に満たなくても「Ｓ−３」が表示される（実際にはランクとしては「３」のみが表示される）。
【００９０】
［診断装置に表示される診断結果について］
次に、図１１の画面例を用いて、評価データに基づいて表示部３０に表示される評価画面を説明する。
【００９１】
図１１に示すように、評価画面には、ユーザＩＤより特定されるユーザ名と、前月の月間順位と、前年の月間順位の自己ベストと、当月の累計ポイントと、前月のステータスと、当月のランクと、評価データの更新日時とが表示される。
【００９２】
［実施形態の効果］
サーバ１０は、更新処理を月単位と日単位とでそれぞれ実行し、このうち、月単位の更新処理では、前月の診断データを記憶部１２より抽出し（Ｓ４０５）、診断ポイントをユーザＩＤ単位でまとめ、累計ポイントを算出する（Ｓ４１０）。そして、この累計ポイントに基づいて、相対的な順位やステータス（Ｇｏｌｄ，Ｓｉｌｖｅｒ，Ｂｌｕｅ）等の評価データを算出する（Ｓ４１５）。したがって、特定の期間（前月）に対応する診断データに基づいてこれらの評価データが算出されるため、サーバへ診断データが集まってくるタイミングにばらつきがある場合でも、一定の信頼性のある評価データを提供することができる。
【００９３】
また、サーバ１０は、累計ポイントに基づいてユーザの相対的な順位を決定し、その決定した順位を、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９４】
したがって、相対的な順位を知ったユーザは、より上位の順位を得ようと考え、運転技術の向上を図る努力をすると考えられる。
また、サーバ１０は、累計ポイントに基づいてユーザのステータスを決定し、その決定したステータスを、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９５】
したがって、ステータスを知ったユーザは、より上位のステータスを得ようと考え、運転技術の向上を図る努力をすると考えられる。
また、サーバ１０は、今月の初めから前日までに対応する診断データを記憶部１２より抽出し（Ｓ５０５）、診断ポイントをユーザ単位でまとめ、累計ポイントを算出する（Ｓ５１０）。そして、サーバ１０は、この累計ポイントに基づいてユーザのランクを決定し、その決定したランクを、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９６】
したがって、ユーザは、一定の信頼性のあるステータスに加え、現在の状況に近く、努力結果が細かくわかる情報（ランク）についても知ることができる。
また、サーバ１０は、ランクの決定の際、今月の始めから昨日までの診断データに基づいて決定されたランクが、前月の診断データに基づいて決定されたステータス内に含まれるようにランクを決定する（図１０（ｂ）の６月１日以降を参照）。
【００９７】
したがって、ステータスと、ランクが属するステータスとで、齟齬が生じるケースが発生することを防止できる。
［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲に記載した用語との対応を示す。
【００９８】
サーバ１０の通信部１１がサーバ側通信手段に相当し、サーバ１０の記憶部１２が受診情報記憶手段に相当する。
診断データが受信情報に相当し、診断データにおける診断ポイントが診断情報に相当し、診断データにおけるユーザＩＤがユーザ特定情報に相当し、診断データにおける車載装置ＩＤが車載装置特定情報に相当する。
【００９９】
評価データが評価情報に相当し、サーバ１０の制御部１４が評価情報生成手段に相当し、サーバ１０の通信部１１が送信手段に相当する。
サーバ１０の制御部１４が実行する更新処理（月単位）のＳ４１０において算出する累計ポイントが第一の累計値及び第二の累計値に相当する。また、サーバ１０の制御部１４が実行する更新処理（日単位）のＳ５１０において算出する累計ポイントが第一の累計値及び第三の累計値に相当する。
【０１００】
診断装置２０が車載装置に相当し、診断装置２０の記憶部３４が車載装置側記憶手段に相当し、診断装置２０の表示部３０が報知手段に相当する。また、診断装置２０の制御部３９が実行する診断装置側送受信処理ＡのＳ１１５が第一制御手段としての機能に相当する。また、診断装置２０の制御部３９が実行する診断装置側送受信処理ＡのＳ１４０が第二制御手段としての機能に相当する。
【０１０１】
［他の実施形態］
（１）上記実施形態では、サーバ１０は、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａにも、携帯電話５０経由で診断データを送信してくる診断装置２０ｂにも、前月の診断データに基づいて決定したステータスや順位を提供していた。しかし、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａと、携帯電話５０経由で診断データを送信してくる診断装置２０ｂとで、ステータスや順位の決定に用いる診断データの期間を変更してもよい。例えば、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａに対しては、上述した前月の診断データに基づいて決定したステータスや順位に加え、前週の診断データに基づいてステータスや順位を決定し、その決定したステータスや順位についても提供するようにしてもよい。なお、サーバ１０には、通信相手がＤＣＭ４０経由で診断データを送信してくる診断装置２０ａであるか、それとも携帯電話５０経由で診断データを送信してくる診断装置２０ｂであるかを判定する機能が必要になるが、この機能が、特許請求の範囲に記載した判定手段としての機能に相当する。
【０１０２】
このように、ＤＣＭ経由で診断データを送信してくる診断装置２０ａと、携帯電話５０経由で診断データを送信してくる診断装置２０ｂとで、提供する情報を変え、ＤＣＭ経由で診断データを送信してくる診断装置２０ａを優遇すれば、ＤＣＭ４０経由で通信を行う診断装置２０ａが増え、結果として鮮度の良い診断データがサーバ１０に集まりやすくなる。
【０１０３】
（２）サーバ１０は、診断装置２０より診断データを受信して記憶部１２に記憶する際（Ｓ３１０）、新たに受信した診断データに含まれる診断装置ＩＤとタイムスタンプの組み合わせが、既に記憶部１２に記憶されている場合には、その新たに受信した診断データを記憶部１２に記憶させないようにするとよい。つまり、診断装置ＩＤとタイムスタンプの組み合わせが重複する診断データについては、評価データを生成する際に利用できないようにするとよい。
【０１０４】
このようになっていれば、「ユーザ」をサーバ１０における登録ユーザという単位で捉えている場合であっても、診断装置２０の故障等によって診断データが重複して送信された場合に、重複した診断データが用いられて評価データが生成されることを防止できる。
【図面の簡単な説明】
【０１０５】
【図１】評価システムの構成を示すブロック図である。
【図２】サーバの構成を説明するためのブロック図である。
【図３】診断装置の構成を説明するためのブロック図である。
【図４】診断装置側送受信処理Ａを説明するためのフローチャートである。
【図５】診断装置側送受信処理Ｂを説明するためのフローチャートである。
【図６】サーバ側送受信処理を説明するためのフローチャートである。
【図７】更新処理（月単位）を説明するためのフローチャートである。
【図８】更新処理（日単位）を説明するためのフローチャートである。
【図９】ステータス及びランクの説明表である。
【図１０】ステータス及びランクが変動する様子を説明するための説明図である。
【図１１】診断装置の表示部に表示される評価結果画面の一例である。
【符号の説明】
【０１０６】
５…評価システム、１０…サーバ、１１…通信部、１２…記憶部、１３…操作部、１４…制御部、２０，２０ａ，２０ｂ…診断装置、２１…検出部、２２…ＧＰＳ信号受信部、２３…ジャイロスコープ、２４…距離センサ、２５…ＢＴ通信部、２６…リモコンセンサ、２７…リモコン、２８…操作スイッチ群、２９…地図データ入力部、３０…表示部、３１…音声出力部、３２…音声入力部、３３…車内ＬＡＮ通信部、３４…記憶部、３９…制御部、４０…ＤＣＭ、５０…携帯電話、６０…公衆ネットワーク。
【技術分野】
【０００１】
本発明は、車載装置より送られてきた診断情報に基づく評価情報を生成し、生成した評価情報を車載装置に提供するサーバ、そのサーバに対して診断情報を提供するとともにサーバから評価情報の提供を受けてユーザに報知する車載装置、及び、これらをシステムとして構成した評価システムに関する。
【背景技術】
【０００２】
近年、地球環境に関する関心や社会貢献が世界的なブームとなっており、このような時代背景の中、地球環境問題に関する活動は避けて通れない状況にある。また、自動車関連メーカーにとって、それら地球環境に関する諸問題をクリアすることは、安全に関する取組みと同様、社会的使命となっている。
【０００３】
しかし、これら取組みは企業努力だけでは限界があり、個々のドライバーが環境に優しい運転を行うことが望まれる。また、環境に優しい運転は、安全運転にも繋がることから、各ドライバーの運転技術を向上させることは非常に重要テーマである。
【０００４】
運転技術を向上させる一つの方法として、ドライバーの運転内容を診断して数値化し、それを評価ポイントとしてドライバーに付与することが考えられる。そして、その評価ポイントによってドライバーのランク付けを行ったり、評価ポイントの累積値に応じて車両等の購入の際に割引を行ったりすることが考えられる。
【０００５】
このような評価ポイントを応用した仕組みを実現するシステムの一つとして、車両に搭載された診断装置で各ドライバーの診断を行い、その診断結果をセンタサーバ（以下、単に「サーバ」と称す。）に送信し、サーバで診断結果に基づいて各ドライバーの評価（例えばランク付け）を行うシステムが考えられる。このようなシステムでは、診断結果をサーバに送信する方法として大きく二つの方法が考えられる。
【０００６】
一つ目の方法は、車両に搭載されたＤＣＭ（Data Communication Module）を介して評価結果をサーバに送信する方法である。この方法であれば、ＤＣＭが基地局と通信可能な状況でありさえすれば、診断結果の算出を終えたタイミングで診断装置がサーバに診断結果を送信することができる。したがって、サーバで受信された診断結果は、直近に診断された結果である可能性が高く、鮮度の良い診断結果であると言える。
【０００７】
二つ目の方法は、乗員が車両に持ち込んだ携帯電話等の携帯端末（通信機能を有する携帯端末）を介し、診断結果をサーバに送信する方法である。この方法であれば、車両にＤＣＭが搭載されていなくても、乗員が車両に携帯端末を持ち込むことによって診断結果をサーバに送信することができる。しかしながら、診断結果が診断装置からサーバに送信されるタイミングは、ユーザの意思に左右されやすく、サーバで受信された診断結果の鮮度は安定しない。また、未送信の診断結果がまとまって送信される場合もある。
【０００８】
サーバへの診断結果の送信方法について、このように二つの方法があると、現時点でサーバに集まっている診断結果に基づいて例えばドライバーの相対的なランキング表を生成すると、ランキングが時々刻々と変化してしまうため、ランキングの信頼性が低下する。
【０００９】
ところで、このようにサーバにおいてランキング情報を生成するシステムに関しては、下記の特許文献１〜５に記載された技術が知られている。
特許文献１に記載された技術は、インターネット網や携帯電話を用いた通信ゲームに関するもので、そのゲームのランキングを閲覧できるようにしたものである。しかしながら、このゲーム端末は常時接続されることが前提となっており、その結果もセンタ側に逐次蓄積されるものであるため、上述したような問題は発生しない。
【００１０】
また、特許文献２に記載された技術は、移動体に通信網を介して情報を提供する情報提供サービスシステムにおいて、移動体から通信網を介して取得した移動体情報に基づいて運転技術情報を作成し、少なくとも１つのランキンググループ（例えば、車種、車両タイプ、走行環境等を考慮したグループ）内での順位付けを行い、その順位付けされた運転技術情報を各移動体へ提供するものである。この文献には、「運転技術ランキング」「燃費ランキング」に関する内容が記載されているが、このランキングをどのような時間間隔でランキングするか、また、どのような仕組みで移動体情報をアップロードするかについて具体的に記載されていない。
【００１１】
また、特許文献３に記載された技術は、エコ活動参加者の環境負荷削減活動を評価し、報償を与えることによってさらにエコ活動に関わる動機付けを行うことを可能にするエコ活動支援方法に関する技術である。この文献には、「エコ活動参加者に与えられる報償は、報償スポンサ−が提供する金銭や製品、また、エコ活動実績を二酸化炭素排出量に換算した後、二酸化炭素排出権取引市場で売却して得る利益、または、実績をランキング表示してインターネットを介して公表することによって得られる名誉がある」との記載があるが（特許文献３の段落「００６７」）、ランキングについての具体的な内容は記載されていない。
【００１２】
また、特許文献４に記載された技術は、運転者による車両の運転操作から安全運転度を算出し、その算出された安全運転度に基づいてランク付けを行い、安全運転を励行するものである。本文献の中には「センタ１０５では、ナビゲーション装置１００から送信されデータベース６０ｃに蓄積された各運転者の安全運転度を基に運転者のランク付けを行い、データベース６０ｃに運転者毎に記憶する」との記載はあるが（引用文献４の段落「０１５１」）、安全運転度に関するデータ送信は、１日毎に行われることが前提になっている。このため、センタで受信されるデータの鮮度には１日以上のばらつきはなく、鮮度のばらつきに関する工夫は引用文献４には記載されていない。
【特許文献１】特開２００２−２２４４５３号公報
【特許文献２】特開２００３−２０８６９６号公報
【特許文献３】特開２００５−９２８７１号公報
【特許文献４】特開２００７−１７２４８７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、上述した問題にかんがみなされたものであり、サーバで受信される診断情報の鮮度にばらつきがある場合でも、一定の信頼性のある評価情報を車載装置のユーザに提供することができる技術を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するためになされた請求項１に記載のサーバは、サーバ側通信手段と、受信情報記憶手段と、評価情報生成手段と、送信手段とを備える。サーバ側通信手段は、車載装置と通信を行うための手段である。受信情報記憶手段は、診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を、サーバ側通信手段を介して車載装置より取得し、これらを対応付けて受信情報として記憶する手段である。評価情報生成手段は、受信情報記憶手段が記憶する受信情報を参照し、過去の所定の期間に含まれるタイムスタンプに対応する診断情報より、所定の期間の評価情報をユーザと対応付けて生成し、生成した評価情報をユーザと対応付けて記憶する手段である。送信手段は、評価情報生成手段が記憶する評価情報のうち、サーバ側通信手段を介して車載装置が要求したユーザに対応する評価情報を、サーバ側通信手段を介して要求元の車載装置へ送信する手段である。なお、評価情報としては、車載装置において行われた評価の結果の情報であってもよいし、評価に用いられる情報であって車載装置において収集された情報であってもよい。
【００１５】
このような手段を備えるサーバであれば、所定の期間に対応する診断情報に基づいて評価情報が生成されるため、サーバへ情報が集まってくるタイミングにばらつきがある場合でも、所定の期間を適切に設定することにより、一定の信頼性のある評価情報を提供することができる。
【００１６】
ところで、上述したように、診断情報をサーバに送信する方法としては、車両に常時搭載された通信装置、例えば、ＤＣＭ（Data Communication Module）を介して評価情報をサーバに送信する方法と、乗員が車両に持ち込んだ携帯電話等の携帯端末を介して診断情報をサーバに送信する方法とが考えられる。この場合、ＤＣＭを介してサーバに送られてくる診断情報は、携帯端末を介してサーバに送られてくる診断情報に比較して鮮度が良い。そのような鮮度が良い診断情報を送信してくるＤＣＭを介して通信を行う車載装置に対しては、携帯端末を介して通信を行う車載装置よりも何らかの優遇を提供できると良い。そして、優遇が提供できれば、ＤＣＭを介して通信を行う車載装置が増え、ひいては鮮度の良い診断情報がサーバにさらに集まることとなる。
【００１７】
そのような優遇策を提供できるサーバの一つとして、例えば、請求項２に記載のようなサーバを構成することが考えられる。すなわち、サーバ側通信手段が車載装置と通信を行う際、その車載装置が車両に常時搭載された通信装置経由で通信を行う車載装置であるか否かを判定する判定手段をさらに備えるようにサーバを構成し、評価情報生成手段は、所定の期間の一つであって、上記通信装置経由で通信を行う車載装置向けの期間により、上記通信装置経由で通信を行う車載装置向けの評価情報をさらに生成して記憶し、送信手段は、上記通信装置経由で通信を行う車載装置であると判定手段により判定された車載装置に対してのみ、上記通信装置経由で通信を行う車載装置向けの評価情報を送信するようにサーバを構成することが考えられる。具体的には例えば、携帯端末を介して通信を行う車載装置に対しては、先月の診断情報に基づいて生成された評価情報と先週の診断情報に基づいて生成された評価情報を提供し、ＤＣＭを介して通信を行う車載装置に対しては、さらに、昨日の診断情報に基づいて生成された評価情報を提供することが考えられる。
【００１８】
このようなサーバであれば、鮮度が良い診断情報を送信してくる可能性が高い車載装置、すなわち、車両に常時搭載された通信装置経由で通信を行う車載装置に対して、特別な評価情報を提供することができる。その結果、車両に常時搭載された通信装置経由で通信を行う車載装置が増え、鮮度の良い診断情報がより集まることとなる。
【００１９】
ところで、上記所定の期間は、その長さによって繰り返されるとよい。つまり、請求項３に記載のように、評価情報生成手段は、上記所定の期間の長さで繰り返し評価情報を生成するようになっているとよい。具体的には例えば、所定の期間として「一週間」と設定した場合、毎週、前週に対応する評価情報を生成するとよい。
【００２０】
このようになっていれば、期間毎の評価情報を比較することができ、例えば、前の期間よりも評価が上がったとか下がったとかという比較ができる。
ところで、「ユーザ」を個人という単位ではなく、サーバにおける登録ユーザという単位で捉えると、例えば、夫婦で１つのユーザをサーバへ登録することを許容する運用も考えられる。このような場合、夫婦で複数台の車両を保有している場合や、夫婦のうちのどちらかが保有車両以外にレンタカーを運転した場合等には、複数の車載装置から同時期に同一のユーザについての診断情報がサーバに送信される可能性がある。「ユーザ」を個人という単位で捉えているならば、同時期に同一のユーザについての診断情報がサーバに送信された場合、異常情報としてその診断情報を破棄することもできる。しかし、「ユーザ」をサーバにおける登録ユーザという単位で捉えている場合には、同時期に同一のユーザについての診断情報がサーバに送信されたということをもって、診断情報を破棄することはできない。けれども、車載装置の故障等によって複数回、同一の診断情報がサーバに送信されてしまう場合が想定され、このような場合は異常情報としてその診断情報を破棄することが好ましい。
【００２１】
そこで、請求項４に記載のようなサーバが考えられる。つまり、受信情報記憶手段が、受信情報と共に、車載装置を特定することができる車載装置特定情報を、サーバ側通信手段を介して車載装置より取得し、受信情報と対応付けて記憶し、評価情報生成手段が、タイムスタンプ、ユーザ特定情報及び車載装置特定情報の組み合わせが重複する診断情報については、評価情報を生成しないようになったサーバが考えられる。
【００２２】
このようなサーバであれば、「ユーザ」をサーバにおける登録ユーザという単位で捉えている場合であっても、車載装置の故障等によって重複して送信された診断情報が用いられて、評価情報が生成されることを防止できる。
【００２３】
ところで、評価情報としては、診断情報に基づくものであればどのような情報であってもよいが、例えば、ユーザの相対的な順位であるとよい。すなわち、請求項５に記載のように、評価情報生成手段は、期間内に係る診断情報毎にポイントを求め、期間内におけるポイントの累計値である第一の累計値により、ユーザの相対的な順位を決定し、その決定した順位を評価情報とし、ユーザと対応付けて記憶するようになっているとよい。
【００２４】
このようになっていれば、相対的な順位を知ったユーザは、より順位を上げたいと考え、運転技術の向上を図る努力をすると考えられる。
また、評価情報は、相対的なものではなく絶対的なもの、例えば、ステータスであってもよい。すなわち、請求項６に記載のように、評価情報生成手段は、期間内に係る診断情報毎にポイントを求め、期間内におけるポイントの累計値である第二の累計値により、ユーザが複数の絶対的なステータスのうちのいずれのステータスに属するかを決定し、その決定したステータスを特定する情報であるステータス情報を評価情報とし、ユーザと対応付けて記憶するようになっているとよい。
【００２５】
このようになっていれば、自身のステータスを知ったユーザは、より上位のステータスを得ようと考え、運転技術の向上を図る努力をすると考えられる。
ところで、車載装置のユーザは、上述したような信頼性の高い評価情報としてのステータスが得られるのであれば、たとえ多少信頼性が劣ったとしても、より現在の状況に近い
評価情報や、より努力結果が細かくわかる評価情報について、さらに得たいと考える。
【００２６】
そこで、請求項７に記載のようなサーバが考えられる。つまり、評価情報生成手段が、直前の期間以降に係る前断情報毎にポイントを求め、直前の期間以降のポイントの累計値である第三の累計値により、上記ステータスが細分化された複数のランクのうちのいずれのランクにユーザが属するかを決定し、その決定したランクを特定する情報であるランク情報についても評価情報とし、ユーザと対応付けてさらに記憶するようになったサーバが考えられる。
【００２７】
このようなサーバであれば、車載装置のユーザは、現在の状況に近く、努力結果が細かくわかる情報（ランク）についても知ることができる。
なお、上述したようなステータスとの関係を有するランクについても、評価情報として算出するようになったサーバであると、車載装置に送信されるステータスと、車載装置に送信されるランクが属するステータスとで、齟齬が生じるケースが発生し得る。具体的には、決定されたステータスと、決定されたランクが属するステータスとが異なる場合があり得る。これは、ステータスを算出した際に利用した診断情報の期間と、ランクを算出した際に利用した期間が異なるからであるが、このような齟齬が生じると、ステータスとランクとを同時に並べてユーザに表示するような場合に、ユーザに混乱を生じさせるおそれがある。
【００２８】
そこで、請求項８に記載のようなサーバが考えられる。つまり、評価情報生成手段が、ランクの決定に際し、第三の累計値が、直前の期間のステータスにおける最低ランクの条件に満たない場合でも、直前の期間のステータスにおける最低ランクに属するものとしてランクを決定し、第三の累計値が、直前の期間のステータスにおける最高ランクの条件を超える場合でも、直前の期間のステータスにおける最高ランクに属するものとしてランクを決定するようになったサーバが考えられる。
【００２９】
このようなサーバであれば、上述した齟齬の発生を防止することができる。
ところで、上述したサーバに対応する車載装置とてしては、例えば、請求項９に記載のような、車載装置側通信手段と、車載装置側記憶手段と、報知手段と、第一制御手段と、第二制御手段とを備えた車載装置が考えられる。車載装置側通信手段はサーバと通信を行う手段である。車載装置側記憶手段は、診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を記憶する手段である。報知手段は、情報を報知する手段である。第一制御手段は、車載装置側記憶手段に記憶されている診断情報、タイムスタンプ、及び、ユーザ特定情報を、車載装置側通信手段を介してサーバへ送信する手段である。第二制御手段は、車載装置側通信手段に記憶されているユーザ特定情報に対応する評価情報を、車載装置側通信手段を介してサーバに要求し、車載装置側通信手段を介してサーバより送信されてきた評価情報を報知手段に報知させる手段である。
【００３０】
このような車載装置であれば、サーバへ情報を送信するタイミングにばらつきがある場合でも、サーバより一定の信頼性のある評価情報を受信し、ユーザに提供（報知）することができる。
【００３１】
なお、何らかの事情、例えばユーザの操作ミス等により、サーバに対して診断情報を重複して送信することを防ぐためには、例えば、請求項１０に記載のように、第一制御手段は、車載装置側記憶手段に記憶されている診断情報をサーバへ送信すると、車載装置側記憶手段に記憶されている診断情報を削除するようになっているとよい。
【００３２】
このようになっていれば、サーバに診断情報が重複して送信されることを防止することができる。
ところで、上述したサーバと上述した車載装置とを組み合わせた評価システムとして発明を構成してもよい（請求項１１）。なお、このような評価システムであっても、上述したサーバの効果や車載装置の効果を得ることができることは言うまでもない。
【発明を実施するための最良の形態】
【００３３】
以下、本発明が適用された実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００３４】
［構成の説明］
図１は、本発明の実施形態である評価システム５を表すブロック図である。評価システム５は、サーバ１０と、診断装置２０ａ，２０ｂと、ＤＣＭ４０と、携帯電話５０と、公衆ネットワーク６０とを有する。サーバ１０は、公衆ネットワーク６０と接続され、その公衆ネットワーク６０を介してＤＣＭ４０及び携帯電話５０と通信を行う。そして、ＤＣＭ４０は診断装置２０ａと接続され、携帯電話５０は診断装置２０ｂと接続されているため、サーバ１０は、結果として、診断装置２０ａと診断装置２０ｂとも通信を行うことができる。なお、サーバ１０と公衆ネットワーク６０は、有線接続されている。また、ＤＣＭ４０と公衆ネットワーク６０、及び、携帯電話５０と公衆ネットワーク６０は、携帯電話事業者等が提供する広域無線通信パケット網によって接続されている。また、ＤＣＭ４０と診断装置２０ａは、有線接続されている。また、携帯電話５０と診断装置２０ｂは、Ｂｌｕｅｔｏｏｔｈ（登録商標）によって接続されている。また、図１には、ＤＣＭ４０と診断装置２０ａ、携帯電話５０と診断装置２０ｂは、それぞれ一組ずつしか描かれていないが、実際は複数存在する。
【００３５】
（１）サーバ１０
まず、サーバ１０の構成について、図２のブロック図を用いて説明する。サーバ１０は、通信部１１と、記憶部１２と、操作部１３と、制御部１４とを備える。
【００３６】
通信部１１は、公衆ネットワーク６０と通信を行うための機能を有しており、制御部１４によって制御される。
記憶部１２は、不揮発性の記憶媒体（例えば、ハードディスク等）を有しており、後述する診断データ、後述する評価データ、及び、制御部１４が実行するプログラム等を記憶する。
【００３７】
操作部１３は、キーボード、マウス等を備え、サーバ１０の管理者からの指令を受け付けることができる。
制御部１４は、ＣＰＵ，ＤＲＡＭ，ＲＯＭ，フラッシュメモリ，Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭ及びフラッシュメモリ等に記憶されたプログラムに基づいて各種処理を実行する。具体的な処理内容については後述する。
【００３８】
（２）診断装置２０ａ，２０ｂ
次に、診断装置２０ａ，２０ｂについて説明する。なお、以下においては、診断装置２０ａと診断装置２０ｂとを区別する必要がある場合を除き、診断装置２０としてまとめて説明する。
【００３９】
図３は、診断装置２０の概略構成を示すブロック図である。診断装置２０は車両に搭載され、車両の現在位置を検出する検出部２１と、Ｂｌｕｅｔｏｏｔｈによる無線通信を行うＢＴ通信部２５と、ユーザからの各種指示を入力するための操作スイッチ群２８と、操作スイッチ群２８と同様に各種指示を入力可能であって診断装置２０の本体とは別体となったリモートコントロール端末（以下、リモコンと称す）２７と、リモコン２７からの信号を入力するリモコンセンサ２６と、地図データや音声データ等が記録された地図記憶媒体からデータを入力する地図データ入力部２９と、地図や各種情報の表示を行うための表示部３０と、各種のガイド音声等を出力するための音声出力部３１と、ユーザ等が発話した音声を入力して音声信号に変換する音声入力部３２と、車内ＬＡＮに接続された各種ＥＣＵ等と通信を行う車内ＬＡＮ通信部３３と、各種情報を記憶する記憶部３４と、上述した検出部２１，ＢＴ通信部２５，操作スイッチ群２８，リモコンセンサ２６，地図データ入力部２９，音声入力部３２，車内ＬＡＮ通信部３３，記憶部３４からの入力に応じて各種処理を実行し、ＢＴ通信部２５，表示部３０，音声出力部３１，車内ＬＡＮ通信部３３，記憶部３４を制御する制御部３９とを備えている。
【００４０】
検出部２１は、ＧＰＳ（Global Positioning System）用の人工衛星からの電波を図示しないＧＰＳアンテナを介して受信してその受信信号を制御部３９へ出力するＧＰＳ信号受信部２２と、車両に加えられる回転運動の大きさを検出してその検出結果を制御部３９へ出力するジャイロスコープ２３と、車両の走行した距離を検出してその検出結果を制御部３９へ出力する距離センサ２４とを備えている。そして、これら各部２２〜２４からの出力信号に基づいて制御部３９が、車両の位置，方位，速度等を算出する。なお、ＧＰＳ信号受信部２２からの出力信号に基づいて現在位置を求める方式は様々な方式があるが、単独測位方式、相対測位方式のいずれであってもよい。
【００４１】
操作スイッチ群２８は、表示部３０の表示面と一体に構成されたタッチパネル及び表示部３０の周囲に設けられたメカニカルなキースイッチ等から構成される。なお、タッチパネルと表示部３０とは積層一体化されており、タッチパネルには、感圧方式，電磁誘導方式，静電容量方式，あるいはこれらを組み合わせた方式など各種の方式があるが、そのいずれを用いてもよい。
【００４２】
リモコン２７は、複数のボタンから構成されており、いずれかのボタンが押下されるとそのボタンの種類に応じた信号が赤外線等の近距離無線通信を介してリモコンセンサ２６に届くように構成されている。
【００４３】
リモコンセンサ２６は、リモコン２７から送られる信号を受信し、受信した信号を制御部３９へ出力するようになっている。
ＢＴ通信部２５は、Ｂｌｕｅｔｏｏｔｈによって携帯電話と通信を行う機能を有する。
【００４４】
地図データ入力部２９は、図示しない地図データ記憶媒体（例えばハードディスクやＤＶＤ−ＲＯＭ等）に記憶された各種データを入力するための装置である。地図データ記憶媒体には、地図データ（ノードデータ、リンクデータ、道路幅員データ、道路種別データ、通行規制データ、リンク旅行時間、道路名称データ、交差点データ等）、ＰＯＩデータ（ＰＯＩ名称データ、ジャンルデータ、位置データ等）、案内用の音声データ、音声認識データ等が記憶されている。なお、地図データ記憶媒体からこれらのデータを入力する代わりに、通信ネットワークを介してこれらのデータを入力するようになっていてもよい。
【００４５】
表示部３０は、液晶ディスプレイや有機ＥＬディスプレイ等からなり、表示部３０の表示画面には、検出部２１にて検出した車両の現在位置と地図データ入力部２９より入力された地図データとから特定した現在地を示すマーク、目的地までの誘導経路、名称、目印、各種施設のマーク等の付加データとを重ねて表示することができる。また、施設のガイド等も表示できる。
【００４６】
音声出力部３１は、スピーカを有し、制御部３９より入力された音声信号をスピーカより音声として出力することができる。
音声入力部３２は、マイクを有し、マイクに入力された利用者の音声に基づく音声信号を制御部３９に出力することができる。利用者は、マイクに対して発話することにより、診断装置２０に対して音声による指令を入力することができる。
【００４７】
車内ＬＡＮ通信部３３は、車内ＬＡＮ（図示せず）に接続された各種のＥＣＵ（エンジンＥＣＵ、ＡＴ−ＥＣＵ、ブレーキＥＣＵ等）や各種のセンサ（車速センサ、シフトポジションセンサ、前照灯センサ等）との通信を担う。
【００４８】
記憶部３４は、不揮発性の記憶媒体（例えば、ハードディスク、ＳＳＤ等）からなり、各種の情報を記憶することができる。
制御部３９は、ＣＰＵ，ＤＲＡＭ，ＲＯＭ，フラッシュメモリ，Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭ及びフラッシュメモリ等に記憶されたプログラムに基づいて各種処理を実行する。例えば、検出部２１からの各検出信号に基づき座標及び進行方向の組として車両の現在位置を算出する現在位置算出処理や、地図データ入力部２９を介して読み込んだ現在走行中の道路の交通規則を特定する交通規則特定処理や、検出部２１からの各検出信号に基づいて算出した車速が交通規則特定処理によって特定された交通規則に合致しているかどうかといった種々の診断をしてその診断結果を記憶部３４に記憶する診断処理等を実行する。
【００４９】
（３）ＤＣＭ４０
ＤＣＭ４０は、診断装置２０ａが搭載された車両と同一の車両に搭載された通信モジュール（Data Communication Module）であり、車両のドライバー等が容易に車両から取り外すことができないものである。ＤＣＭ４０は、診断装置２０ａと有線接続されるとともに、公衆ネットワーク６０と無線パケット通信を行い、公衆ネットワーク６０につながったサーバ１０と通信を行うことができる。したがって、診断装置２０とサーバ１０との間での通信を可能にする。
【００５０】
（４）携帯電話５０
通話機能、メール送受信機能、Ｗｅｂ閲覧機能、Ｂｌｕｅｔｏｏｔｈ通信機能、無線パケット通信機能等を有する周知の携帯電話である。なお、Ｂｌｕｅｔｏｏｔｈ通信機能というのは、携帯電話５０の近傍（１０ｍ以下）に存在する他の装置（例えば診断装置２０）とＢｌｕｅｔｏｏｔｈ通信によってデータを送受信する機能である。また、無線パケット通信機能というのは、公衆ネットワーク６０に接続された他の装置（例えばサーバ１０）と広域無線通信によってデータを送受信する機能である。携帯電話５０は、Ｂｌｕｅｔｏｏｔｈ通信機能と無線パケット通信機能とを組み合わせて動作させることもできる（つまり、診断装置２０とサーバ１０との間で通信を可能にする）。
【００５１】
［診断装置２０の動作の説明］
まず、診断装置２０の動作について説明する。診断装置２０は、下記の診断装置側送信処理Ａと診断装置側送信処理Ｂについて、択一的に実行する。なお、診断装置２０ａは、ＤＣＭ４０と接続されていることが予め登録されているため、診断装置側送信処理Ａを実行し、診断装置２０ｂは、ＤＣＭ４０と接続されていることが予め登録されていないため、診断装置側送信処理Ｂを実行する。また、診断装置２０は、診断装置側送信処理Ａ，Ｂ以外にも診断処理を実行する。この診断処理は、例えば、車両が停止した毎に、前回の停止時以降になされた運転操作を診断し、その診断結果を点数化して診断データとして記憶する処理である。具体的な診断方法については、周知の技術を利用することとし、説明は省略する。
【００５２】
（１）診断装置側送受信処理Ａ
診断装置２０ａの制御部３９が実行する車載装置側送受信処理Ａについて、図４のフローチャートを用いて説明する。なお、診断装置側送受信処理Ａは、診断装置２０ａへの電力供給が開始された際、例えば、搭載車両のアクセサリスイッチがオンになった際に、実行が開始される処理である。
【００５３】
診断装置２０ａの制御部３９は、診断装置側送受信処理Ａの実行を開始すると、まず、ＤＣＭ４０が公衆ネットワーク６０に接続可能な状態か否かを判定する（Ｓ１０５）。例えば、制御部３９が主導し、サーバ１０へ所定のパケットをＤＣＭ４０に送信させ、そのパケットの応答が所定時間内にサーバ１０よりＤＣＭ４０に届いたか否かを判定することによって上記判定を行うことが考えられる。制御部３９は、このＳ１０５において、ＤＣＭ４０は公衆ネットワーク６０に接続可能な状態であると判定した場合は（Ｓ１０５：Ｙｅｓ）、Ｓ１１０へ処理を移行し、ＤＣＭ４０は公衆ネットワーク６０に接続可能な状態でないと判定した場合は（Ｓ１０５：Ｎｏ）、ＤＣＭ４０が公衆ネットワーク６０に接続可能になるまで本ステップにとどまる。
【００５４】
ＤＣＭ４０を介して通信可能と判定した場合に進むＳ１１０では、記憶部３４に診断データがあるか否か否かを判定する。なお、本実施形態でいう「診断データ」は、以下の情報から構成される。
【００５５】
・ユーザＩＤ：ユーザを一意に識別するためのＩＤ
・診断装置ＩＤ：診断装置を一意に識別するためのＩＤ
・タイムスタンプ：診断データが生成された日時を示す情報
・診断ポイント：診断を行った結果の点数（ポイント）
このような診断データが、診断タイミング毎（例えば、車両が停車したタイミング毎）に生成されて記憶部３４に逐次記憶される。
【００５６】
制御部３９は、Ｓ１１０において、診断データが記憶部３４にあると判定した場合は（Ｓ１１０：Ｙｅｓ）、Ｓ１１５へ処理を移行し、一方、診断データは記憶部３４にないと判定した場合は（Ｓ１１０：Ｎｏ）、Ｓ１２５へ処理を移行する。
【００５７】
診断データが記憶部３４にあると判定した場合に進むＳ１１５では、制御部３９は、その診断データを記憶部３４より読み出し、ＤＣＭ４０を介してサーバ１０へ送信することを開始する。なお、診断データをサーバ１０へ送信することに先立ち、サーバ１０に対して診断データの受信要求を送信する。また、送信した診断データについては、記憶部３４から削除する。
【００５８】
続いて、制御部３９は、記憶部３４に記憶されている診断データを全て送信したか否かを判定する（Ｓ１２０）。診断データを全て送信したと判定した場合は（Ｓ１２０：Ｙｅｓ）、Ｓ１２５へ処理を移行し、一方、診断データがまだ残っていると判定した場合は（Ｓ１２０：Ｎｏ）、記憶部３４に記憶されている診断データが全て送信されるまで本ステップにとどまる。
【００５９】
Ｓ１１０で否定判定された場合、又は、Ｓ１２０で肯定判定された場合に進むＳ１２５では、制御部３９は、記憶部３４に記憶されている評価データの更新日時を調べ、評価データが所定期間以上前のものか否かを判定する。ここでいう「所定期間」というのは、例えば、１日や１週間といった程度の期間が考えられる。ここで「評価データ」について説明する。評価データは、サーバ１０で生成されて診断装置１０に送られてくるデータである。そして、評価データは、以下の情報から構成されており、ユーザ単位で存在するデータである。
【００６０】
・ユーザＩＤ：ユーザを識別するためのＩＤ
・月間順位：前月の相対的な順位である。
・累計ポイント点数：年初から前日までの診断データに含まれる診断ポイントの累計
ポイント
・ステータス情報：前月の診断データに基づいて決定されたステータスを表す情報
（例：「Ｇｏｌｄ」）
・ランク情報：月初から前日までの診断データに基づいて決定されたランクを表す情
報（例：「３」）
・前年自己ベスト：前年の最も良かった月間順位とその月である。
【００６１】
・本年自己ベスト：本年の最も良かった月間順位とその月である。
・更新日時：評価データが更新された日時である。
制御部３９は、このＳ１２５において、記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものであると判定した場合は（Ｓ１２５：Ｙｅｓ）、Ｓ１３５へ処理を移行し、一方、記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものでないと判定した場合は（Ｓ１２５：Ｎｏ）、Ｓ１３０へ処理を移行する。
【００６２】
記憶部３４に記憶されている評価データの更新日時は所定期間以上前のものでないと判定した場合に進むＳ１３０では、記憶部３４に記憶されている評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、本処理（診断装置側送受信処理Ａ）を終了する。
【００６３】
一方、記憶部３４に記憶されている評価データの更新日時が所定期間以上前のものであると判定された場合に進むＳ１３５では、制御部３９は、最新の評価データを送信する旨の要求である送信要求を、ＤＣＭ４０を介してサーバ１０へ送信する。なお、この送信要求は、制御部３９のフラッシュメモリに予め登録されているユーザＩＤを含めて送信する。
【００６４】
続いて、制御部３９は、ＤＣＭ４０を介してサーバ１０より評価データを受信する（Ｓ１４０）。なお、受信した評価データは記憶部３４に上書き記憶させる。
続いて、制御部３９は、サーバ１０より評価データの受信を完了したか否かを判定する（Ｓ１４５）。これは、例えば、サーバ１０より送信終了を意味する指令を受信した場合に、評価データの受信を完了したと判定することが考えられる。制御部３９は、このＳ１４５において、サーバ１０より評価データの受信を完了したと判定した場合は（Ｓ１４５：Ｙｅｓ）、Ｓ１５０へ処理を移行し、一方、サーバ１０より評価データの受信を完了していないと判定した場合は（Ｓ１４５：Ｎｏ）、Ｓ１５５へ処理を移行する。
【００６５】
サーバ１０より評価データの受信を完了したと判定した場合に進むＳ１５０では、受信した最新の評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、本処理（診断装置側送受信処理Ａ）を終了する。
【００６６】
一方、サーバ１０より評価データの受信を完了していないと判定した場合に進むＳ１５５では、受信がタイムアウトしたか否かを判定する。具体的には、例えば、サーバ１０より評価データ又は送信終了を意味する指令を受信することなく、所定時間（例えば、１分間）経過したか否かを判定することにより、受信がタイムアウトしたか否かを判定することが考えられる。制御部３９は、このＳ１５５において、受信がタイムアウトとしたと判定した場合は（Ｓ１５５：Ｙｅｓ）、Ｓ１６０へ処理を移行し、一方、受信はタイムアウトしていないと判定した場合は（Ｓ１５５：Ｎｏ）、Ｓ１４５へ処理を戻す。
【００６７】
受信はタイムアウトとしたと判定した場合に進むＳ１６０では、記憶部３４に記憶されている評価データに基づく評価を表示部３０に表示する。表示例については後述する。その後、制御部３９は、Ｓ１２５へ処理を戻す。
【００６８】
（２）診断装置側送受信処理Ｂ
次に、診断装置２０ｂの制御部３９が実行する診断装置側送受信処理Ｂについて、図５のフローチャートを用いて説明する。なお、診断装置側送受信処理Ｂは、診断装置２０ｂへの電力供給が開始された際、例えば、搭載車両のアクセサリスイッチがオンになった際に、実行が開始される処理である。
【００６９】
診断装置２０ｂの制御部３９は、診断装置側送受信処理Ｂの実行を開始すると、まず、ＢＴ通信部２５を介して携帯電話５０と通信可能であるか否かを判定する（Ｓ２０５）。例えば、所定のパケットを、ＢＴ通信部２５を介して携帯電話５０へ送信し、その応答が所定時間内に得られるか否かで判定する方法が考えられる。制御部３９は、このＳ２０５において、ＢＴ通信部２５を介して携帯電話５０と通信可能であると判定した場合は（Ｓ２０５：Ｙｅｓ）、Ｓ２１０へ処理を移行し、一方、ＢＴ通信部２５を介して携帯電話５０と通信可能でないと判定した場合は（Ｓ２０５：Ｎｏ）、ＢＴ通信部２５を介して携帯電話５０と通信可能になるまで本ステップにとどまる。
【００７０】
ＢＴ通信部２５を介して携帯電話５０と通信可能であると判定した場合に進むＳ２１０では、診断データを送信する旨の操作が操作スイッチ群２８に対してユーザよりなされたか否かを判定する。診断データを送信する旨の操作がなされたと判定した場合は（Ｓ２１０：Ｙｅｓ）、Ｓ２１５へ処理を移行し、診断データを送信する旨の操作はなされていないと判定した場合は（Ｓ２１０：Ｎｏ）、Ｓ２０５へ処理を戻す。
【００７１】
診断データを送信する旨の操作がなされたと判定した場合に進むＳ２１５では、制御部３９は、携帯電話５０が、公衆ネットワーク６０に接続可能な状態であるか否かを判定する。例えば、制御部３９が主導し、サーバ１０へ所定のパケットを携帯電話５０に送信させ、そのパケットの応答がサーバ１０より携帯電話５０に届いたか否かを判定することによって上記判定を行うことが考えられる。制御部３９は、このＳ２１５において、携帯電話５０は公衆ネットワーク６０に接続可能な状態であると判定した場合は（Ｓ２１５：Ｙｅｓ）、上述した診断装置側送受信処理ＡのＳ１１０及びＳ１１０に続く処理を実行し、一方、携帯電話５０は公衆ネットワーク６０に接続可能な状態でないと判定した場合は（Ｓ２１５：Ｎｏ）、上述したＳ２０５に処理を戻す。なお、上述した診断装置側送受信処理ＡのＳ１１０及びＳ１１０に続く処理を実行する場合は、診断装置側送受信処理Ａの説明において記載したＤＣＭ４０を携帯電話５０と読み替えて実行するものとする。
【００７２】
［サーバ１０の動作の説明］
次にサーバ１０の動作について説明する。
（１）サーバ側送受信処理
サーバ１０の制御部１４が実行するサーバ側送受信処理について、図６のフローチャートを用いて説明する。なお、サーバ側送受信処理は、診断装置２０より何らかの要求、具体的には、受信要求又は送信要求を受け付けた際に実行が開始される。なお、ここでいう「受信要求」というのは、診断装置２０より送信される受信要求であり、上述した診断装置側送受信処理ＡのＳ１１５で送信される受信要求である。また、ここでいう「送信要求」というのは、診断装置２０より送信される送信要求であり、上述した診断装置側送受信処理ＡのＳ１３５で送信される送信要求である。
【００７３】
制御部１４は、サーバ側送受信処理の実行を開始すると、まず受けた要求は受信要求か否かを判定する（Ｓ３０５）。受けた要求は受信要求であると判定した場合は（Ｓ３０５：Ｙｅｓ）、Ｓ３１０へ処理を移行し、受けた要求は受信要求ではないと判定した場合は（Ｓ３０５：Ｎｏ）、Ｓ３１５へ処理を移行する。
【００７４】
受けた要求は受信要求であると判定した場合に進むＳ３１０では、制御部１４は、診断装置２０より診断データを受信して記憶部１２に記憶する。記憶を終えると、制御部１４は、Ｓ３１５へ処理を移行する。
【００７５】
Ｓ３１５では、制御部１４は送信要求を診断装置２０より受けたか否かを判定する。送信要求を受けたと判定した場合は（Ｓ３１５：Ｙｅｓ）、Ｓ３２５へ処理を移行し、送信要求を受けていないと判定した場合は（Ｓ３１５：Ｎｏ）、Ｓ３２０へ処理を移行する。
【００７６】
送信要求を受けていないと判定した場合に進むＳ３２０では、最初にＳ３１５の判定を行ってから所定時間が経過したか否かを判定する。ここで言う「所定時間」としては、例えば、１分程度が考えられる。制御部１４は、このＳ３２０において、所定時間経過したと判定した場合は（Ｓ３２０：Ｙｅｓ）、本処理（サーバ側送受信処理）を終了し、まだ所定時間経過していないと判定した場合は（Ｓ３２０：Ｎｏ）、Ｓ３１５へ処理を戻す。
【００７７】
送信要求を受けたと判定した場合に進むＳ３２５では、制御部１４は、送信要求の中に含まれるユーザＩＤに対応する評価データを記憶部１２より読み出して送信する。送信が完了すると、制御部１４は、本処理（サーバ側送受信処理）を終了する。
【００７８】
（２）更新処理（月単位）
次に、サーバ１０の制御部１４が実行する更新処理について、図７のフローチャートを用いて説明する。なお、更新処理（月単位）は、毎月の始めに実行が開始される処理である。
【００７９】
制御部１４は、更新処理（月単位）の実行を開始すると、前月の診断データを記憶部１２より抽出する（Ｓ４０５）。
続いて、制御部１４は、Ｓ４０５で抽出された診断データ毎に診断ポイントを特定し、その特定した診断ポイントをユーザＩＤ単位でまとめ、各ユーザの合計診断ポイントを累計ポイントとして算出する（Ｓ４１０）。
【００８０】
続いて、制御部１４は、Ｓ４１０で算出した各ユーザの累計ポイントに応じて、相対的な順位及びステータスを決定し、その情報を記憶部１２に記憶させる（Ｓ４１５）。制御部１４は、相対的な順位及びステータスの情報を記憶部１２に記憶させると、本処理（更新処理（月単位））を終了する。
【００８１】
（３）更新処理（日単位）
次に、サーバ１０の制御部１４が実行する更新処理（日単位）について、図８のフローチャートを用いて説明する。なお、更新処理（日単位）は、毎日の０：００に実行が開始される処理である。
【００８２】
制御部１４は、更新処理（日単位）の実行を開始すると、今月の始めから昨日までの診断データを記憶部１２より抽出する（Ｓ５０５）。
続いて、制御部１４は、Ｓ５０５で抽出された診断データ毎に診断ポイントを特定し、その特定した診断ポイントをユーザＩＤ単位でまとめ、各ユーザの合計診断ポイントを累計ポイントとして算出する（Ｓ５１０）。
【００８３】
続いて、制御部１４は、Ｓ５１０で算出した各ユーザの累計ポイントに応じて、ランクを決定し、その情報を記憶部１２に記憶させる（Ｓ４１５）。なお、ランクの決定の際には、今月の始めから昨日までの診断データに基づいて決定されたランクが、前月の診断データに基づいて決定されたステータス内に含まれるようにランクを決定する。この具体例については後述する。制御部１４は、ランクの情報を記憶部１２に記憶させると、本処理（更新処理（日単位））を終了する。
【００８４】
［ステータスとランクについて］
次に、図９の説明表を用いて、ステータスとランクについて説明する。
ステータスとしては、「Ｇｏｌｄ」、「Ｓｉｌｖｅｒ」、「Ｂｌｕｅ」の３つのステータスが存在する。「Ｇｏｌｄ」は、ハイクラスとしての位置づけである。「Ｓｉｌｖｅｒ」は、ミドルクラスとしての位置づけである。「Ｂｌｕｅ」はエントリークラスとしての位置づけである。
【００８５】
また、各ステータスには、ランクとして「１」「２」「３」が存在する。数字が小さいほど評価は高い。
なお、ステータス「Ｂｌｕｅ」、ランク「３」が、評価の初期ステータス及びランクである。
【００８６】
［ステータスとランクが変動する様子について］
次に、図１０のグラフを用いて、ステータスとランクの変動について説明する。
図１０（ａ）は、ステータスの変動を示すグラフである。１月１日から２月１日の期間に表示部１０に表示されるステータスは、当該期間の累計ポイントにかかわらず初期の評価ステータスである「Ｂｌｕｅ」である（１月１日から診断を開始した場合）。２月１日から３月１日の期間に表示されるステータスは、直前の期間である１月１日から２月１日の期間の累計ポイントに基づいて決定される「Ｂｌｕｅ」である。３月１日から４月１日の期間に表示されるステータスは、直前の期間である２月１日から３月１日の期間の累計ポイントに基づいて決定される「Ｓｉｌｖｅｒ」である。４月１日から５月１日の期間に表示されるステータスは、直前の期間である３月１日から４月１日の期間の累計ポイントに基づいて決定される「Ｂｌｕｅ」である。
【００８７】
このように、直前の期間（前月）の累計ポイントに基づいて決定されるステータスが翌期間（当月）のステータスとして表示部３０に表示される。
図１０（ｂ）は、ランクの変動を示すグラフである。５月の累計ポイントは、５月１０日にステータス「Ｂｌｕｅ」に属するランク「２」（以下、ランクについて、「Ｂ−２」といった形式で記載する。）の閾値に達し、５月２０日に「Ｂ−１」のランクの閾値に達し、５月２５日頃に「Ｓ−３」の閾値に達している。実際に表示部３０に表示されるランクは、５月１日から５月１０日は、「Ｂ−３」が表示され（実際にはランクとしては「３」のみが表示部３０に表示される）、５月１０日から５月２０日は「Ｂ−２」が表示され（実際にはランクとしては「２」のみが表示部３０に表示される）、５月２０日から６月１日までは「Ｂ−１」が表示される（実際にはランクとしては「１」のみが表示部３０に表示される）。このように、月が変わるまでは、別のステータスに属するランクには移行しない。
【００８８】
６月１日以降に表示部３０に表示されるランクは、前月末の時点で前月の累計ポイントがステータス「Ｓｉｌｖｅｒ」の閾値を超えているため、当該月の累計ポイントが「Ｓ−３」の閾値に満たなくても「Ｓ−３」が表示され（６月１日から６月２５日）、当該月の累計ポイントが「Ｓ−２」の閾値を超えた時点（６月２５日）から月末までは、「Ｓ−２」が表示される（実際にはランクとしては「２」のみが表示される）。
【００８９】
７月１日以降に表示部３０に表示されるランクは、前月末の時点で前月の累計ポイントがステータス「Ｓｉｌｖｅｒ」の閾値を超えているため、当該月の累計ポイントが「Ｓ−３」の閾値に満たなくても「Ｓ−３」が表示される（実際にはランクとしては「３」のみが表示される）。
【００９０】
［診断装置に表示される診断結果について］
次に、図１１の画面例を用いて、評価データに基づいて表示部３０に表示される評価画面を説明する。
【００９１】
図１１に示すように、評価画面には、ユーザＩＤより特定されるユーザ名と、前月の月間順位と、前年の月間順位の自己ベストと、当月の累計ポイントと、前月のステータスと、当月のランクと、評価データの更新日時とが表示される。
【００９２】
［実施形態の効果］
サーバ１０は、更新処理を月単位と日単位とでそれぞれ実行し、このうち、月単位の更新処理では、前月の診断データを記憶部１２より抽出し（Ｓ４０５）、診断ポイントをユーザＩＤ単位でまとめ、累計ポイントを算出する（Ｓ４１０）。そして、この累計ポイントに基づいて、相対的な順位やステータス（Ｇｏｌｄ，Ｓｉｌｖｅｒ，Ｂｌｕｅ）等の評価データを算出する（Ｓ４１５）。したがって、特定の期間（前月）に対応する診断データに基づいてこれらの評価データが算出されるため、サーバへ診断データが集まってくるタイミングにばらつきがある場合でも、一定の信頼性のある評価データを提供することができる。
【００９３】
また、サーバ１０は、累計ポイントに基づいてユーザの相対的な順位を決定し、その決定した順位を、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９４】
したがって、相対的な順位を知ったユーザは、より上位の順位を得ようと考え、運転技術の向上を図る努力をすると考えられる。
また、サーバ１０は、累計ポイントに基づいてユーザのステータスを決定し、その決定したステータスを、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９５】
したがって、ステータスを知ったユーザは、より上位のステータスを得ようと考え、運転技術の向上を図る努力をすると考えられる。
また、サーバ１０は、今月の初めから前日までに対応する診断データを記憶部１２より抽出し（Ｓ５０５）、診断ポイントをユーザ単位でまとめ、累計ポイントを算出する（Ｓ５１０）。そして、サーバ１０は、この累計ポイントに基づいてユーザのランクを決定し、その決定したランクを、ユーザと対応づけられた評価データの一つとして記憶し、診断装置２０に提供する。
【００９６】
したがって、ユーザは、一定の信頼性のあるステータスに加え、現在の状況に近く、努力結果が細かくわかる情報（ランク）についても知ることができる。
また、サーバ１０は、ランクの決定の際、今月の始めから昨日までの診断データに基づいて決定されたランクが、前月の診断データに基づいて決定されたステータス内に含まれるようにランクを決定する（図１０（ｂ）の６月１日以降を参照）。
【００９７】
したがって、ステータスと、ランクが属するステータスとで、齟齬が生じるケースが発生することを防止できる。
［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲に記載した用語との対応を示す。
【００９８】
サーバ１０の通信部１１がサーバ側通信手段に相当し、サーバ１０の記憶部１２が受診情報記憶手段に相当する。
診断データが受信情報に相当し、診断データにおける診断ポイントが診断情報に相当し、診断データにおけるユーザＩＤがユーザ特定情報に相当し、診断データにおける車載装置ＩＤが車載装置特定情報に相当する。
【００９９】
評価データが評価情報に相当し、サーバ１０の制御部１４が評価情報生成手段に相当し、サーバ１０の通信部１１が送信手段に相当する。
サーバ１０の制御部１４が実行する更新処理（月単位）のＳ４１０において算出する累計ポイントが第一の累計値及び第二の累計値に相当する。また、サーバ１０の制御部１４が実行する更新処理（日単位）のＳ５１０において算出する累計ポイントが第一の累計値及び第三の累計値に相当する。
【０１００】
診断装置２０が車載装置に相当し、診断装置２０の記憶部３４が車載装置側記憶手段に相当し、診断装置２０の表示部３０が報知手段に相当する。また、診断装置２０の制御部３９が実行する診断装置側送受信処理ＡのＳ１１５が第一制御手段としての機能に相当する。また、診断装置２０の制御部３９が実行する診断装置側送受信処理ＡのＳ１４０が第二制御手段としての機能に相当する。
【０１０１】
［他の実施形態］
（１）上記実施形態では、サーバ１０は、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａにも、携帯電話５０経由で診断データを送信してくる診断装置２０ｂにも、前月の診断データに基づいて決定したステータスや順位を提供していた。しかし、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａと、携帯電話５０経由で診断データを送信してくる診断装置２０ｂとで、ステータスや順位の決定に用いる診断データの期間を変更してもよい。例えば、ＤＣＭ４０経由で診断データを送信してくる診断装置２０ａに対しては、上述した前月の診断データに基づいて決定したステータスや順位に加え、前週の診断データに基づいてステータスや順位を決定し、その決定したステータスや順位についても提供するようにしてもよい。なお、サーバ１０には、通信相手がＤＣＭ４０経由で診断データを送信してくる診断装置２０ａであるか、それとも携帯電話５０経由で診断データを送信してくる診断装置２０ｂであるかを判定する機能が必要になるが、この機能が、特許請求の範囲に記載した判定手段としての機能に相当する。
【０１０２】
このように、ＤＣＭ経由で診断データを送信してくる診断装置２０ａと、携帯電話５０経由で診断データを送信してくる診断装置２０ｂとで、提供する情報を変え、ＤＣＭ経由で診断データを送信してくる診断装置２０ａを優遇すれば、ＤＣＭ４０経由で通信を行う診断装置２０ａが増え、結果として鮮度の良い診断データがサーバ１０に集まりやすくなる。
【０１０３】
（２）サーバ１０は、診断装置２０より診断データを受信して記憶部１２に記憶する際（Ｓ３１０）、新たに受信した診断データに含まれる診断装置ＩＤとタイムスタンプの組み合わせが、既に記憶部１２に記憶されている場合には、その新たに受信した診断データを記憶部１２に記憶させないようにするとよい。つまり、診断装置ＩＤとタイムスタンプの組み合わせが重複する診断データについては、評価データを生成する際に利用できないようにするとよい。
【０１０４】
このようになっていれば、「ユーザ」をサーバ１０における登録ユーザという単位で捉えている場合であっても、診断装置２０の故障等によって診断データが重複して送信された場合に、重複した診断データが用いられて評価データが生成されることを防止できる。
【図面の簡単な説明】
【０１０５】
【図１】評価システムの構成を示すブロック図である。
【図２】サーバの構成を説明するためのブロック図である。
【図３】診断装置の構成を説明するためのブロック図である。
【図４】診断装置側送受信処理Ａを説明するためのフローチャートである。
【図５】診断装置側送受信処理Ｂを説明するためのフローチャートである。
【図６】サーバ側送受信処理を説明するためのフローチャートである。
【図７】更新処理（月単位）を説明するためのフローチャートである。
【図８】更新処理（日単位）を説明するためのフローチャートである。
【図９】ステータス及びランクの説明表である。
【図１０】ステータス及びランクが変動する様子を説明するための説明図である。
【図１１】診断装置の表示部に表示される評価結果画面の一例である。
【符号の説明】
【０１０６】
５…評価システム、１０…サーバ、１１…通信部、１２…記憶部、１３…操作部、１４…制御部、２０，２０ａ，２０ｂ…診断装置、２１…検出部、２２…ＧＰＳ信号受信部、２３…ジャイロスコープ、２４…距離センサ、２５…ＢＴ通信部、２６…リモコンセンサ、２７…リモコン、２８…操作スイッチ群、２９…地図データ入力部、３０…表示部、３１…音声出力部、３２…音声入力部、３３…車内ＬＡＮ通信部、３４…記憶部、３９…制御部、４０…ＤＣＭ、５０…携帯電話、６０…公衆ネットワーク。
【特許請求の範囲】
【請求項１】
車載装置と通信を行うためのサーバ側通信手段と、
診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を、前記サーバ側通信手段を介して前記車載装置より取得し、これらを対応付けて受信情報として記憶する受信情報記憶手段と、
前記受信情報記憶手段が記憶する前記受信情報を参照し、過去の所定の期間に含まれる前記タイムスタンプに対応する前記診断情報より、前記所定の期間の評価情報をユーザと対応付けて生成し、生成した前記評価情報をユーザと対応付けて記憶する評価情報生成手段と、
前記評価情報生成手段が記憶する前記評価情報のうち、前記サーバ側通信手段を介して前記車載装置が要求したユーザに対応する前記評価情報を、前記サーバ側通信手段を介して要求元の前記車載装置へ送信する送信手段と、
を備えることを特徴とするサーバ。
【請求項２】
請求項１に記載のサーバにおいて、
前記サーバ側通信手段が前記車載装置と通信を行う際、その車載装置が車両に常時搭載された通信装置経由で通信を行う車載装置であるか否かを判定する判定手段をさらに備え、
前記評価情報生成手段は、前記所定の期間の一つであって、前記通信装置経由で通信を行う前記車載装置向けの期間により、前記通信装置経由で通信を行う前記車載装置向けの前記評価情報をさらに生成して記憶し、
前記送信手段は、前記通信装置経由で通信を行う前記車載装置であると前記判定手段により判定された前記車載装置に対してのみ、前記通信装置経由で通信を行う前記車載装置向けの前記評価情報を送信すること、
を特徴とするサーバ。
【請求項３】
請求項１又は請求項２に記載のサーバにおいて、
前記評価情報生成手段は、前記期間の長さで繰り返し前記評価情報を生成すること、
を特徴とするサーバ。
【請求項４】
請求項１〜請求項３のいずれかに記載のサーバにおいて、
前記受信情報記憶手段は、前記受信情報と共に、車載装置を特定することができる車載装置特定情報を、前記サーバ側通信手段を介して前記車載装置より取得し、前記受信情報と対応付けて記憶し、
前記評価情報生成手段は、前記タイムスタンプ及び前記車載装置特定情報の組み合わせが重複する前記診断情報については、前記評価情報を生成しないこと、
を特徴とするサーバ。
【請求項５】
請求項１〜請求項４のいずれかに記載のサーバにおいて、
前記評価情報生成手段は、前記期間内に係る前記診断情報毎にポイントを求め、前記期間内における前記ポイントの累計値である第一の累計値により、前記ユーザの相対的な順位を決定し、その決定した順位を前記評価情報とし、前記ユーザと対応付けて記憶すること、
を特徴とするサーバ。
【請求項６】
請求項１〜請求項４のいずれかに記載のサーバにおいて、
前記評価情報生成手段は、前記期間内に係る前記診断情報毎にポイントを求め、前記期間内における前記ポイントの累計値である第二の累計値により、前記ユーザが複数の絶対的なステータスのうちのいずれのステータスに属するかを決定し、その決定したステータスを特定する情報であるステータス情報を前記評価情報とし、前記ユーザと対応付けて記憶すること、
を特徴とするサーバ。
【請求項７】
請求項６に記載のサーバにおいて、
前記評価情報生成手段は、直前の前記期間以降に係る前記診断情報毎にポイントを求め、直前の前記期間以降の前記ポイントの累計値である第三の累計値により、前記ステータスが細分化された複数のランクのうちのいずれのランクに前記ユーザが属するかを決定し、その決定したランクを特定する情報であるランク情報についても前記評価情報とし、前記ユーザと対応付けてさらに記憶すること、
を特徴とするサーバ。
【請求項８】
請求項７に記載のサーバにおいて、
前記評価情報生成手段は、前記ランクの決定に際し、前記第三の累計値が、直前の前記期間のステータスにおける最低ランクの条件に満たない場合でも、直前の前記期間のステータスにおける最低ランクに属するものとしてランクを決定し、前記第三の累計値が、直前の前記期間のステータスにおける最高ランクの条件を超える場合でも、直前の前記期間のステータスにおける最高ランクに属するものとしてランクを決定すること、
を特徴とするサーバ。
【請求項９】
請求項１〜請求項８のいずれかに記載のサーバと通信を行う車載装置側通信手段と、
診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を記憶する車載装置側記憶手段と、
情報を報知する報知手段と、
前記車載装置側記憶手段に記憶されている前記診断情報、前記タイムスタンプ、及び、前記ユーザ特定情報を、前記車載装置側通信手段を介して前記サーバへ送信する第一制御手段と、
前記車載装置側通信手段に記憶されている前記ユーザ特定情報に対応する前記評価情報を、前記車載装置側通信手段を介して前記サーバに要求し、前記車載装置側通信手段を介して前記サーバより送信されてきた前記評価情報を前記報知手段に報知させる第二制御手段と、
を備えることを特徴とする車載装置。
【請求項１０】
請求項９に記載の車載装置において、
前記第一制御手段は、前記車載装置側記憶手段に記憶されている前記診断情報を前記サーバへ送信すると、前記車載装置側記憶手段に記憶されている前記診断情報を削除すること、
を特徴とする車載装置。
【請求項１１】
請求項１〜請求項８のいずれかに記載のサーバと、請求項９又は請求項１０に記載の車載装置とを備える評価システム。
【請求項１】
車載装置と通信を行うためのサーバ側通信手段と、
診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を、前記サーバ側通信手段を介して前記車載装置より取得し、これらを対応付けて受信情報として記憶する受信情報記憶手段と、
前記受信情報記憶手段が記憶する前記受信情報を参照し、過去の所定の期間に含まれる前記タイムスタンプに対応する前記診断情報より、前記所定の期間の評価情報をユーザと対応付けて生成し、生成した前記評価情報をユーザと対応付けて記憶する評価情報生成手段と、
前記評価情報生成手段が記憶する前記評価情報のうち、前記サーバ側通信手段を介して前記車載装置が要求したユーザに対応する前記評価情報を、前記サーバ側通信手段を介して要求元の前記車載装置へ送信する送信手段と、
を備えることを特徴とするサーバ。
【請求項２】
請求項１に記載のサーバにおいて、
前記サーバ側通信手段が前記車載装置と通信を行う際、その車載装置が車両に常時搭載された通信装置経由で通信を行う車載装置であるか否かを判定する判定手段をさらに備え、
前記評価情報生成手段は、前記所定の期間の一つであって、前記通信装置経由で通信を行う前記車載装置向けの期間により、前記通信装置経由で通信を行う前記車載装置向けの前記評価情報をさらに生成して記憶し、
前記送信手段は、前記通信装置経由で通信を行う前記車載装置であると前記判定手段により判定された前記車載装置に対してのみ、前記通信装置経由で通信を行う前記車載装置向けの前記評価情報を送信すること、
を特徴とするサーバ。
【請求項３】
請求項１又は請求項２に記載のサーバにおいて、
前記評価情報生成手段は、前記期間の長さで繰り返し前記評価情報を生成すること、
を特徴とするサーバ。
【請求項４】
請求項１〜請求項３のいずれかに記載のサーバにおいて、
前記受信情報記憶手段は、前記受信情報と共に、車載装置を特定することができる車載装置特定情報を、前記サーバ側通信手段を介して前記車載装置より取得し、前記受信情報と対応付けて記憶し、
前記評価情報生成手段は、前記タイムスタンプ及び前記車載装置特定情報の組み合わせが重複する前記診断情報については、前記評価情報を生成しないこと、
を特徴とするサーバ。
【請求項５】
請求項１〜請求項４のいずれかに記載のサーバにおいて、
前記評価情報生成手段は、前記期間内に係る前記診断情報毎にポイントを求め、前記期間内における前記ポイントの累計値である第一の累計値により、前記ユーザの相対的な順位を決定し、その決定した順位を前記評価情報とし、前記ユーザと対応付けて記憶すること、
を特徴とするサーバ。
【請求項６】
請求項１〜請求項４のいずれかに記載のサーバにおいて、
前記評価情報生成手段は、前記期間内に係る前記診断情報毎にポイントを求め、前記期間内における前記ポイントの累計値である第二の累計値により、前記ユーザが複数の絶対的なステータスのうちのいずれのステータスに属するかを決定し、その決定したステータスを特定する情報であるステータス情報を前記評価情報とし、前記ユーザと対応付けて記憶すること、
を特徴とするサーバ。
【請求項７】
請求項６に記載のサーバにおいて、
前記評価情報生成手段は、直前の前記期間以降に係る前記診断情報毎にポイントを求め、直前の前記期間以降の前記ポイントの累計値である第三の累計値により、前記ステータスが細分化された複数のランクのうちのいずれのランクに前記ユーザが属するかを決定し、その決定したランクを特定する情報であるランク情報についても前記評価情報とし、前記ユーザと対応付けてさらに記憶すること、
を特徴とするサーバ。
【請求項８】
請求項７に記載のサーバにおいて、
前記評価情報生成手段は、前記ランクの決定に際し、前記第三の累計値が、直前の前記期間のステータスにおける最低ランクの条件に満たない場合でも、直前の前記期間のステータスにおける最低ランクに属するものとしてランクを決定し、前記第三の累計値が、直前の前記期間のステータスにおける最高ランクの条件を超える場合でも、直前の前記期間のステータスにおける最高ランクに属するものとしてランクを決定すること、
を特徴とするサーバ。
【請求項９】
請求項１〜請求項８のいずれかに記載のサーバと通信を行う車載装置側通信手段と、
診断情報、その診断情報に係るタイムスタンプ、及び、ユーザ特定情報を記憶する車載装置側記憶手段と、
情報を報知する報知手段と、
前記車載装置側記憶手段に記憶されている前記診断情報、前記タイムスタンプ、及び、前記ユーザ特定情報を、前記車載装置側通信手段を介して前記サーバへ送信する第一制御手段と、
前記車載装置側通信手段に記憶されている前記ユーザ特定情報に対応する前記評価情報を、前記車載装置側通信手段を介して前記サーバに要求し、前記車載装置側通信手段を介して前記サーバより送信されてきた前記評価情報を前記報知手段に報知させる第二制御手段と、
を備えることを特徴とする車載装置。
【請求項１０】
請求項９に記載の車載装置において、
前記第一制御手段は、前記車載装置側記憶手段に記憶されている前記診断情報を前記サーバへ送信すると、前記車載装置側記憶手段に記憶されている前記診断情報を削除すること、
を特徴とする車載装置。
【請求項１１】
請求項１〜請求項８のいずれかに記載のサーバと、請求項９又は請求項１０に記載の車載装置とを備える評価システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−３９６４２（Ｐ２０１０−３９６４２Ａ）
【公開日】平成２２年２月１８日（２０１０．２．１８）
【国際特許分類】
【出願番号】特願２００８−２０００３５（Ｐ２００８−２０００３５）
【出願日】平成２０年８月１日（２００８．８．１）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２２年２月１８日（２０１０．２．１８）
【国際特許分類】
【出願日】平成２０年８月１日（２００８．８．１）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]