通信装置
【課題】単方向通信で送信される情報の検証の処理による負荷を軽減する。
【解決手段】パケットの正当性の検証を行うための証明書および署名を付加して単方向通信で無線送信されたパケットを受信した場合に、パケットに含まれるメッセージの内容、メッセージに付加されたパケット種別フラグ、同一の送信元からの受信頻度、受信したときの受信電力などをもとに、検証の要否を判断し、検証が必要と判断したパケットについては検証を行う一方、検証が不要と判断したパケットについては検証を行わない。
【解決手段】パケットの正当性の検証を行うための証明書および署名を付加して単方向通信で無線送信されたパケットを受信した場合に、パケットに含まれるメッセージの内容、メッセージに付加されたパケット種別フラグ、同一の送信元からの受信頻度、受信したときの受信電力などをもとに、検証の要否を判断し、検証が必要と判断したパケットについては検証を行う一方、検証が不要と判断したパケットについては検証を行わない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、単方向通信で送信される情報を受信する通信装置に関するものである。
【背景技術】
【０００２】
従来から、各車両の端末間で行われる通信（以下、車車間通信）や車両の端末と路側機との間で行われる通信（以下、路車間通信）によって情報を送受信する技術が知られている。
【０００３】
これら車車間通信や路車間通信が双方向通信である場合には、通信相手の信頼性の証明や通信データの改竄防止に必要な証明書や秘匿に必要な鍵の交換を複数回のハンドシェイクによって行うことで、悪意のあるなりすまし端末（以下、不正端末）から送信された偽の通信データを判別することができる。
【０００４】
しかしながら、これら車車間通信や路車間通信がブロードキャスト型の通信（つまり、単方向通信）であった場合には、不正端末から送信された偽の通信データを、上記ハンドシェイクを行って判別することができないという問題点があった。
【０００５】
そこで、この問題を解決する手段として、不正端末から送信された偽の通信データを受信側のみで判別する技術が提案されている。例えば、特許文献１には、車両に関する情報に加えて署名、公開鍵、公開鍵証明書を含むフレームを送信側の車両から送信し、受信側の車両でこのフレームを受信した後に、公開鍵証明書から公開鍵を検証して正しい公開鍵であるか否かを判断するとともに、署名と公開鍵とを用いてフレームの内容が改竄されていないかを検証する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−８１５２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に開示の技術では、受信側での検証の処理にかかる負荷が大きくなってしまうという問題を有していた。詳しく説明すると、車車間通信における車両の端末からの情報の送信は１秒間に１０回程度であり、路車間通信における路側機からの情報の送信は１秒間に７０回程度であるが、受信側は複数の通信相手から情報を受信することがあるため、１秒間に１０００回以上の受信を行う可能性がある。検証の処理には多くの計算が必要であるため、送信されてくる情報全てをリアルタイムに検証しようとすると、膨大な量の計算を高速で行わなくてはならないことになる。
【０００８】
また、将来的に半導体技術の進歩でプロセッサ処理能力がさらに向上した場合であっても、なりすましや改竄を防止するために例えば証明書や署名の方式がアップデートされていき、検証の処理に必要な計算の量も増えていくため、受信側での検証の処理にかかる負荷の増大は将来に渡って問題となると考えられる。
【０００９】
本発明は、上記従来の問題点に鑑みなされたものであって、その目的は、単方向通信で送信される情報の検証の処理による負荷を軽減することを可能にする通信装置を提供することにある。
【課題を解決するための手段】
【００１０】
請求項１の通信装置によれば、受信手段で受信した他機器由来情報（つまり、証明書および署名の少なくともいずれかの検証用情報を付加して単方向通信で無線送信された情報）については、検証要否判断手段で正当性の検証の要否を判断し、検証が不要と判断した他機器由来情報については検証を行わないので、受信する他機器由来情報の全てについて検証を行う必要がなくなる。よって、通信装置での検証の回数を減らすことができ、単方向通信で送信される情報の検証の処理による負荷を軽減することが可能になる。
【００１１】
また、受信した他機器由来情報の検証の要否を判断する場合には、請求項２のように、受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の内容をもとに検証の要否を判断することが可能になる。
【００１２】
請求項２のようにする場合には、請求項３のように、他車両の位置に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他車両の位置に関する情報をもとに検証の要否を判断することが可能になる。例えば、自車両との距離が近い他車両や交差点との距離が近い他車両からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１３】
請求項２のようにする場合には、請求項４のように、他車両の位置に関する情報および当該他車両の運動に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他車両の位置に関する情報および当該他車両の運動に関する情報をもとに検証の要否を判断することが可能になる。例えば、自車両に接近してきている他車両からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１４】
請求項２のようにする場合には、請求項５のように、その他機器由来情報の鮮度に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の鮮度に関する情報をもとに検証の要否を判断することが可能になる。例えば、生成されてからの時間経過が短く、鮮度の高い他機器由来情報のように、自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１５】
請求項２のようにする場合には、請求項６のように、他機器由来情報の内容をもとに、その他機器由来情報が不正な送信元から送信されたものか否かを判定し、不正な送信元から送信されたと判定した場合には、その他機器由来情報についての検証を不要と判断し、検証を行わずにその他機器由来情報を破棄する態様とすることが好ましい。これによれば、不正な送信元から送信されたと判定される他機器由来情報の検証を行わずに破棄することが可能になるので、信頼に値しない他機器由来情報について検証を行う手間を軽減することができる。
【００１６】
受信した他機器由来情報の検証の要否を判断する場合には、請求項７のように、他機器由来情報に付加された付加情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の送信元の種別に関する情報、当該他機器由来情報自体の種別に関する情報、および当該他機器由来情報のマルチホッピング通信におけるホッピングを要求する情報のうちの少なくともいずれの情報をもとに検証の要否を判断することが可能になる。
【００１７】
例えば、機器由来情報の送信元の種別に関する情報をもとに、緊急車両や路側機からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。また、他機器由来情報自体の種別に関する情報をもとに、広告の情報である他機器由来情報のように、自車両にとって緊急性や重要性が低いと思われる他機器由来情報については検証が不要と判断することが可能になる。さらに、マルチホッピング通信におけるホッピングを要求する情報をもとに、ホッピングが要求されている他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１８】
受信した他機器由来情報の検証の要否を判断する場合には、請求項８のように、同一の送信元から送信された他機器由来情報を受信手段で受信した頻度に応じて、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、同一の送信元からの他機器由来情報の受信頻度に応じて検証の要否を判断することが可能になる。例えば、同一の送信元からの前回受信時からの経過時間が長かったり、初めて受信したりする他機器由来情報のように、自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１９】
受信した他機器由来情報の検証の要否を判断する場合には、請求項９のように、受信手段で他機器由来情報を受信したときの受信電力に応じて、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、受信電力に応じて検証の要否を判断することが可能となる。例えば、受信電力が高いほど、自車両に近い他車両からの他機器由来情報であると言えるので、自車両に近い他車両から受信した他機器由来情報のように、受信電力が高い自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００２０】
請求項１０の構成によれば、検証要否判断手段において段階で判定した重要度の高さに応じて、他機器由来情報についての検証の要否を判断することが可能になるので、受信した他機器由来情報の重要度を考慮しながら、検証の処理による負荷を軽減することが可能になる。
【００２１】
請求項１０のようにする場合には、請求項１１のように、重要度を４段階で判定し、重要度が最も高い段階であると判定した他機器由来情報については、検証が必要であると判断して、優先して検証を行うものとして一時格納手段に格納する態様とすることが好ましい。さらに、重要度が２番目に高い段階であると判定した他機器由来情報については、検証が必要であると判断して、一時格納手段への格納順に従って検証を行うものとして一時格納手段に格納する態様とすることが好ましい。また、重要度が２番目に低い段階であると判定した他機器由来情報については、一時格納手段の容量に当該他機器由来情報を格納する空きがある場合には、検証が必要であると判断して、一時格納手段への格納順に従って検証を行うものとして一時格納手段に格納する一方、一時格納手段の容量に当該他機器由来情報を格納する空きがない場合には、検証が不要であると判断して、検証を行わない態様とすることが好ましい。そして、重要度が最も低い段階であると判定した他機器由来情報については、検証が不要であると判断して、検証を行わない態様とすることが好ましい。
【００２２】
これによれば、重要度の高いものほど優先して検証を行う一方、重要度の低いものほど検証を省くことによって、受信した他機器由来情報の重要度を考慮しながら、検証の処理による負荷を軽減することができる。また、重要度が２番目に低い段階であると判定した他機器由来情報については、一時格納手段の容量に空きがある場合にのみ検証を行うので、検証の処理による負荷が一定の限度を越えないようにしながらも、より多くの他機器由来情報についての検証を行うことが可能になる。
【００２３】
請求項１２の構成によれば、受信した他機器由来情報について検証が行われたか否かに応じて、その他機器由来情報のアプリケーションソフトウェアでの利用の有無および用い方のうちのいずれかを変えることができる。例えば、検証が行わなかった他機器由来情報についてはアプリケーションソフトウェアに利用しなかったり、補助的な利用に止めたりすることが可能になる。
【図面の簡単な説明】
【００２４】
【図１】運転支援システム１００の概略的な構成を示すブロック図である。
【図２】路側機１の概略的な構成を示すブロック図である。
【図３】（ａ）〜（ｃ）は、配信情報を送信する場合のパケットの生成の手順を説明するための模式図である。
【図４】ナビゲーション装置２の概略的な構成を示すブロック図である。
【図５】車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローを示すフローチャートである。
【図６】配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係の一例を示す表である。
【図７】車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について図面を用いて説明する。図１は、本発明が適用された運転支援システム１００の概略的な構成を示すブロック図である。図１に示す運転支援システム１００は、路側機１、車両Ａに搭載されているナビゲーション装置２、および車両Ｂに搭載されているナビゲーション装置２を含んでいる。
【００２６】
運転支援システム１００においては、路側機１と車両Ａ・Ｂのナビゲーション装置２との間での路車間通信によって情報をやり取りしたり、車両Ａのナビゲーション装置２と車両Ｂに搭載されたナビゲーション装置２との間での車車間通信によって情報をやり取りしたりすることが可能となっている。
【００２７】
以降では、特に路側機１や車両Ｂのナビゲーション装置２から車両Ａのナビゲーション装置２に向けてブロードキャスト型の無線通信（つまり、無線での単方向通信）を行うものとして説明を行う。
【００２８】
路側機１は、交差点付近の路側等の所定の場所に固定されて設置され、路車間通信を行う無線通信装置としての機能を備えている。ここで、図２を用いて路側機１の概略的な構成について説明を行う。図２は、路側機１の概略的な構成を示すブロック図である。図２に示すように路側機１は、路側機側路車間通信部１１、センタ通信部１２、および路側機側制御部１３を備えている。
【００２９】
路側機側路車間通信部１１は、ナビゲーション装置２との間で通信を行うものである。例えば、路側機側路車間通信部１１は、車両Ｂのナビゲーション装置２から車両Ｂの速度、加速度、進行方向、現在位置等の情報が送信されてきた場合には、これを受信して路側機側制御部１３に送る。なお、車両Ｂの速度、加速度、進行方向の情報が請求項の他車両の運動に関する情報に相当し、車両Ｂの現在位置の情報が請求項の他車両の位置に関する情報に相当する。
【００３０】
また、路側機側路車間通信部１１は、路側機側制御部１３から後述する配信情報が送られてきた場合は、路側機側制御部１３の指示に従って、この配信情報を車両Ａのナビゲーション装置２に向けて無線での単方向通信で送信する。路側機側路車間通信部１１は、例えばナビゲーション装置２に接続されている通信アンテナや通信機を介してナビゲーション装置２との間で通信を行うものとする。
【００３１】
路側機１とナビゲーション装置２との間での通信は、例えばＶＩＣＳ（登録商標）（Vehicle Information andCommunication System）を利用して行う構成であってもよいし、ＤＳＲＣ（Dedicate Short RangeCommunication）、無線ＬＡＮなどによって行う構成としてもよい。また、路側機１から配信される配信情報としては、例えば、車両の進行を妨げる可能性のある歩行者や他車両などの速度、加速度、進行方向、現在位置等の情報といった障害物情報、道路標識や道路標示によって規制されている一時停止場所の情報といった規制標識情報、一時停止場所での一時停止を指示する車両制御情報等の交通に関連した交通関連情報や広告の情報である広告情報などの様々な情報がある。
【００３２】
センタ通信部１２は、配信情報を統合的に管理する情報センタとの通信を行うものである。センタ通信部１２は、例えばネットワークを介して情報センタとの通信を行い、情報センタから配信情報を取得したり、路側機１が車両Ｂのナビゲーション装置２から受信した車両Ｂの速度、加速度、進行方向、現在位置等の情報を情報センタに送ったりする。
【００３３】
路側機側制御部１３は、通常のコンピュータとして構成されており、内部には周知のＣＰＵ、ＲＯＭやＲＡＭ等のメモリ、Ｉ／Ｏ及びこれらの構成を接続するバスライン（いずれも図示せず）が備えられている。路側機側制御部１３は、路側機側路車間通信部１１、センタ通信部１２から入力された各種情報に基づき各種処理を実行する。
【００３４】
例えば、路側機側制御部１３は、センタ通信部１２で情報センタから取得した配信情報や路側機側路車間通信部１１でＢ車両のナビゲーション装置２から取得した車両Ｂの速度、加速度、進行方向、現在位置等の情報といった配信情報をもとに、無線での単方向通信で配信情報の送信を行うためのパケットを生成する。
【００３５】
ここで、図３（ａ）〜図３（ｃ）を用いて、配信情報を送信する場合のパケットの生成の手順についての説明を行う。図３（ａ）〜図３（ｃ）は、配信情報を送信する場合のパケットの生成の手順を説明するための模式図である。
【００３６】
図３（ａ）に示すように、配信情報をもとに送信用のメッセージを生成する。メッセージは暗号化されない平文の状態であるものとする。メッセージには、例えば前述した配信情報や路側機１を個別に識別するための路側機ＩＤやメッセージを生成した時刻の情報である情報生成時刻等を含むようにすればよい。また、メッセージの後部にパケット種別フラグ（図中のＦ）を付加する。
【００３７】
パケット種別フラグとは、メッセージの送信元の種別に関する情報やメッセージ自体の種別に関する情報やメッセージのマルチホッピング通信におけるホッピングを要求する情報（以下、ホッピングフラグ）などの付加情報である。例えば、メッセージの送信元の種別が路側機の場合には、メッセージの送信元の種別に関する情報として路側機フラグが付加される。また、メッセージ自体の種別が広告の場合には、メッセージ自体の種別の情報として広告フラグが付加され、メッセージ自体の種別が一時停止の指示等の車両制御の場合には、車両制御フラグが付加される。
【００３８】
続いて、図３（ｂ）に示すように、電子証明書（以下、証明書）と電子署名（以下、署名）とをパケット種別フラグの後部に付加する。ここで言うところの証明書とは、例えば第３者機関が発行するルート証明書であって、正規の端末であることを表すデータである。また、署名とは、メッセージに付与する電子的な徴証であって、メッセージが改竄されていないことを保証するためのデータである。そして、図３（ｃ）に示すように、パケットの先頭にヘッダを付加することで配信情報の送信を行うためのパケットの生成を完了する。
【００３９】
なお、証明書と署名とのうちのいずれか一方のみを付加する構成としてもよいが、セキュリティの向上の点から、証明書と署名との両方をメッセージに付加する構成がより好ましい。これら証明書や署名が請求項の検証用情報に相当する。
【００４０】
図２に戻って、路側機側制御部１３は、生成したパケットを路側機側路車間通信部１１から車両Ａのナビゲーション装置２に向けて送信させる。路側機側制御部１３は、パケットを例えば定期的（１秒間に７０回程度など）に送信させるものとする。
【００４１】
ナビゲーション装置２は、前述したように車両Ａ・Ｂに搭載されるものである。ナビゲーション装置２は、経路探索や経路案内等のナビゲーション機能を有している他に、例えば、前述の路車間通信や車車間通信を行うための通信機能を有している。なお、車両Ａのナビゲーション装置２が請求項の通信装置に相当する。
【００４２】
ここで、図４を用いてナビゲーション装置２の概略的な構成について説明を行う。図４は、ナビゲーション装置２の概略的な構成を示すブロック図である。図４に示すようにナビゲーション装置２は、位置検出器２１、地図データ入力器２６、記憶媒体２７、外部メモリ２８、表示装置２９、音声出力装置３０、操作スイッチ群３１、リモートコントロール端末（以下リモコン）３２、リモコンセンサ３３、車両側路車間通信部３４、車車間通信部３５、および車両側制御装置３６を備えている。
【００４３】
位置検出器２１は、自車両の加速度を検出する加速度センサ２２、自車両の鉛直方向周りの角速度を検出するジャイロスコープ２３、各転動輪の回転速度から自車両の速度を検出する車輪速センサ２４、および人工衛星からの電波に基づいて自車両の現在位置を検出するＧＰＳ（Global Positioning System）のためのＧＰＳ受信機２５を有しており、定期的に自車両の現在位置および進行方向の検出を行う。なお、各センサの精度によっては位置検出器２１を上述した内の一部で構成してもよく、さらに、図示しない地磁気センサ、ステアリングの回転センサ等を用いてもよい。
【００４４】
地図データ入力器２６は、記憶媒体２７が装着され、その記憶媒体２７に格納されている位置検出の精度向上のためのいわゆるマップマッチング用データ、地図データ、および目印データを含む各種データを入力するための装置である。地図データには、道路を示すリンクデータとノードデータとが含まれる。
【００４５】
なお、リンクとは、地図上の各道路を交差・分岐・合流する点等の複数のノードにて分割したときのノード間を結ぶものである。リンクデータは、リンクを特定する固有番号（リンクＩＤ）、リンクの長さを示すリンク長、リンク方向、リンク方位、リンクの始端及び終端ノード座標（緯度・経度）等の各データから構成される。
【００４６】
一方、ノードデータは、地図上の各道路が交差、合流、分岐するノード毎に固有の番号を付したノードＩＤ、ノード座標、ノード名称、ノードに接続するリンクのリンクＩＤが記述される接続リンクＩＤ等の各データから構成される。
【００４７】
外部メモリ２８は、書き込み可能なＨＤＤ等の大容量記憶装置である。外部メモリ２８には大量のデータや電源をオフしても消去してはいけないデータを記憶したり、頻繁に使用するデータを地図データ入力器２６からコピーして利用したりする等の用途がある。
【００４８】
表示装置２９は、テキストや画像を表示するものであって、液晶ディスプレイ、有機ＥＬディスプレイ、プラズマディスプレイ等を用いて構成することができる。また、音声出力装置３０は、スピーカ等から構成され、車両側制御装置３６の指示に基づいて、音声や警告音等を出力する。
【００４９】
操作スイッチ群３１は、例えば表示装置２９と一体になったタッチスイッチもしくはメカニカルなスイッチ等が用いられ、スイッチ操作により車両側制御装置３６へ各種機能の操作指示を行う。リモコン３２には複数の操作スイッチ（図示せず）が設けられ、スイッチ操作によりリモコンセンサ３３を介して各種指令信号を車両側制御装置３６に入力することにより、操作スイッチ群３１と同じ機能を車両側制御装置３６に対して実行させることが可能である。
【００５０】
車両側路車間通信部３４は、路側機１との間で通信を行うものである。例えば、車両Ａの車両側路車間通信部３４は、路側機１から送信される前述のパケットを受信する。また、車両Ｂの車両側路車間通信部３４は、車両Ｂの速度、加速度、進行方向、現在位置等の情報を路側機１に送信する。速度の情報については車輪速センサ２４、加速度の情報については加速度センサ２２、進行方向および現在位置の情報については位置検出器２１から得る構成とすればよい。
【００５１】
車車間通信部３５は、他車両に搭載されたナビゲーション装置２の車車間通信部３５との間で無線通信によってデータの送受信を行う（つまり、車車間通信を行う）ものである。例えば、車両Ｂの車車間通信部３５は、車両側制御装置３６から配信情報が送られてきた場合は、路側機側制御部１３の指示に従って、この配信情報を車両Ａのナビゲーション装置２に向けて無線での単方向通信で送信する。また、車両Ａの車車間通信部３５は、車両Ｂの車車間通信部３５から送信されてくる配信情報を受信して車両Ａの車両側制御装置３６に送る。なお、車車間通信部３５は、無線ＬＡＮ等の無線通信によって情報の送受信を行う構成とすればよい。
【００５２】
例えば、車両側路車間通信部３４および車車間通信部３５は、ナビゲーション装置２に接続された通信アンテナやナビゲーション装置２に接続された通信機を利用して通信を行う構成とすればよい。また、車両側路車間通信部３４および車車間通信部３５は、別体に設けられる構成であってもよいし、一体に設けられる構成であってもよい。
【００５３】
車両側制御装置３６は通常のコンピュータとして構成されており、内部には周知のＣＰＵ、ＲＯＭやＲＡＭ等のメモリ、Ｉ／Ｏ、およびこれらの構成を接続するバスライン（いずれも図示せず）が備えられている。車両側制御装置３６は、位置検出器２１、地図データ入力器２６、外部メモリ２８、操作スイッチ群３１、リモコンセンサ３３、車両側路車間通信部３４、車車間通信部３５から入力された各種情報に基づき、ナビゲーション機能としての処理やパケットの送信に関連する処理や受信したパケットに含まれる配信情報の重要度の判定の処理やパケットの検証の要否の判断の処理などを実行する。
【００５４】
例えば、車両Ｂの車両側制御装置３６は、位置検出器２１や各センサ２２〜２５などから得られる車両Ｂの速度、加速度、進行方向、現在位置等の情報を配信情報とし、この配信情報をもと、無線での単方向通信で配信情報の送信を行うためのパケットを生成する。このパケットの生成は、前述した路側機側制御部１３でのパケットの生成と同様にして行われる。
【００５５】
以下では、車両Ｂから送信するパケットにおいて特有の構成について説明を行い、路側機１から送信するパケットと同様の構成については説明を省略する。車両Ｂから送信するパケットのメッセージには、例えば上記配信情報や車両Ｂを個別に識別するための車両ＩＤやメッセージを生成した時刻の情報である情報生成時刻等を含むようにすればよい。
【００５６】
パケット種別フラグとしては、メッセージの送信元の種別が緊急車両の場合には、メッセージの送信元の種別に関する情報として緊急車両フラグが付加され、緊急車両以外の一般車両の場合には、メッセージの送信元の種別に関する情報として一般車両フラグが付加される。
【００５７】
また、車両Ｂの車両側制御装置３６は、生成したパケットを車両Ｂの車車間通信部３５から車両Ａの車車間通信部３５に向けて送信させる。車両Ｂの車両側制御装置３６は、パケットを例えば定期的（１秒間に１０回程度など）に送信させるものとする。
【００５８】
車両Ａの車両側制御装置３６は、受信したパケットに含まれる配信情報を用いる各種のアプリケーションソフトウェア（以下、アプリ）を保持しており、配信情報に応じたアプリを実行し、各種のサービスを提供する。例えば、車両Ｂの速度、加速度、進行方向、現在位置の情報をもとに車両Ｂの位置を更新するアプリ（以下、車両位置更新アプリ）や車両Ａ・Ｂの速度、加速度、進行方向、現在位置の情報をもとに車両Ａ・Ｂの接触危険性を判定して報知するアプリがある。また、前述の障害物情報、規制標識情報、広告情報等を表示装置２９や音声出力装置３０から提示するアプリなどがある。
【００５９】
また、車両Ａの車両側制御装置３６は、車両Ｂからのパケットを車車間通信部３５で受信したり、路側機１からのパケットを車両側路車間通信部３４から受信したりした場合に、このパケットに含まれる配信情報の重要度を段階で判定する重要度判定処理を実行する。なお、車両Ｂや路側機１から送信されるメッセージが請求項の他機器由来情報に相当し、車両Ａの車両側路車間通信部３４や車車間通信部３５が請求項の受信手段に相当する。
【００６０】
重要度判定処理では、例えば重要度を４段階に分け、重要度が最も高い段階を「緊急」、重要度が２番目に高い段階を「重要」、重要度が２番目に低い段階を「通常」、重要度が最も低い段階を「非重要」と判定するものとする。
【００６１】
重要度の判定は、パケットに含まれるメッセージの内容をもとに行う構成としてもよい。一例としては、車両Ｂの現在位置の情報をもとに重要度を判定する構成とすればよい。具体的には、車両Ａの位置検出器２１から得られる車両Ａの現在位置の情報とパケットに含まれる車両Ｂの現在位置の情報とから車両Ａと車両Ｂとの距離を算出する。そして、車両Ａと車両Ｂとの距離が所定の閾値以下であった場合に、車両Ｂが近傍車両であるものとみなして重要度を「重要」と判定し、所定の閾値以下でなかった場合に、車両Ｂが遠方車両であるものとみなして重要度を「通常」と判定する構成とすればよい。ここで言うところの所定の閾値とは、車両Ａと車両Ｂとの接触の危険性を考慮して定められる値であって、任意に設定可能な値である。
【００６２】
また、車両Ａの地図データ入力器２６から得られるノードデータとパケットに含まれる車両Ｂの現在位置の情報とから車両Ｂの直近の交差点と車両Ｂとの距離を算出して、当該交差点と車両Ｂとの距離が所定の閾値以下であった場合に、重要度を「重要」と判定し、所定の閾値以下でなかった場合に、重要度を「通常」と判定する構成としてもよい。ここで言うところの所定の閾値とは、任意に設定可能な値である。
【００６３】
さらに、車両Ｂの現在位置の情報および車両Ｂの速度、加速度、進行方向の情報をもとに重要度を判定する構成としてもよい。具体的には、車両Ａの車輪速センサ２４、加速度センサ２２、位置検出器２１からそれぞれ得られる車両Ａの速度、加速度、進行方向、および現在位置の情報とパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報とから車両Ａと車両Ｂとの接近度合いを算出する。そして、車両Ａと車両Ｂとの接近度合いが所定の閾値以下であった場合に、重要度を「重要」と判定し、所定の閾値以下でなかった場合に、重要度を「通常」と判定する構成とすればよい。ここで言うところの所定の閾値とは、車両Ａと車両Ｂとの接触の危険性を考慮して定められる値であって、任意に設定可能な値である。
【００６４】
また、メッセージの情報生成時刻をもとに重要度を判定する構成としてもよい。具体的には、パケットに含まれる情報生成時刻をもとに、メッセージが生成されてからの経過時間を算出する。そして、経過時間が所定の時間以下であった場合に、鮮度が高いものとして重要度を「重要」と判定し、所定の閾値以下でなかった場合に、鮮度が低いものとして重要度を「通常」と判定する構成とすればよい。よって、情報生成時刻が請求項の鮮度に関する情報に相当する。ここで言うところの所定の時間とは、任意に設定可能な時間である。
【００６５】
さらに、パケットに含まれるメッセージの内容をもとに、そのメッセージが、所謂なりすまし端末といった不正な送信元から送信されたものか否かを判定し、その判定結果に応じて重要度を判定する構成としてもよい。
【００６６】
具体的には、予め不正な送信元が使用している車両ＩＤや路側機ＩＤなどのリスト（以下、不正端末リスト）を保持しておき、パケットに含まれる車両ＩＤや路側機ＩＤが不正端末リストに存在するか否かに応じて不正な送信元から送信されたものか否かを判定する。そして、不正端末リストにＩＤが存在した場合には、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定する。不正端末リストにＩＤが存在しなかった場合には、不正な送信元から送信されたものと判定せず、パケットに含まれるメッセージの内容などの他の要素をもとに重要度を判定する。
【００６７】
不正端末リストについては、ＤＣＭ等の通信モジュールや携帯電話機を介したり、車車間通信や路車間通信を介したりして、ナビゲーション装置２が不正端末リストを管理しているサーバから取得する構成とすればよい。
【００６８】
また、複数回の受信分における車両Ｂの現在位置の情報および車両Ｂの速度、加速度、進行方向の情報をもとに、車両Ｂの現在位置の変化を求め、その変化が不自然か否かに応じて不正な送信元から送信されたものか否かを判定する構成としてもよい。この場合、車両Ｂの走行軌跡が途中でジャンプしていたり、速度、加速度から算出される位置から誤差範囲を超えて逸脱していたりしたことをもって変化が不自然であるとすればよい。そして、変化が不自然であった場合には、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定する。
【００６９】
他にも、重要度の判定は、メッセージに付加されたパケット種別フラグをもとに行う構成としてもよい。一例としては、前述の緊急車両フラグや車両制御フラグが付加されていた場合には、車両Ａが緊急に対応しなければならないものとして、重要度を「緊急」と判定する。また、ホッピングフラグが付加されていた場合には、ホッピングにより遠距離まで伝えなければならない重要なメッセージであるものとして、重要度を「重要」と判定する。路側機フラグが付加されていた場合にも、重要度を「重要」と判定する。さらに、広告フラグが付加されていた場合には、重要度を「非重要」と判定する。
【００７０】
また、重要度の判定は、同一の送信元から送信されたパケットを受信した頻度をもとに行う構成としてもよい。同一の送信元から送信されたパケットか否かについては、メッセージに含まれる車両ＩＤや路側機ＩＤが一致する場合に同一の送信元から送信されたものと車両Ａの車両側制御装置３６で判別する構成とすればよい。受信した頻度の検出については、受信したパケットのメッセージと図示しないタイマー回路のカウントとをもとに、車両Ａの車両側制御装置３６で行う構成とすればよい。よって、車両Ａの車両側制御装置３６が請求項の受信頻度検出手段に相当する。
【００７１】
一例としては、同一の送信元から受信したパケットの受信間隔が一定時間以上であった場合や同一の送信元から初めて受信したパケットであった場合といった、受信した頻度が所定の閾値以下であった場合に、似た情報を既に受信している可能性が低いものとして、重要度を「重要」と判定する。そして、同一の送信元から受信したパケットの受信間隔が一定時間未満であった場合といった、受信した頻度が所定の閾値以下でなかった場合に、似た情報を既に受信している可能性が高いものとして、重要度を「通常」と判定する。ここで言うところの一定時間および所定の閾値とは、任意に設定可能な値である。
【００７２】
さらに、重要度の判定は、車両Ａの車両側路車間通信部３４や車車間通信部３５でパケットを受信したときの受信電力をもとに行う構成としてもよい。受信電力については、車両Ａの車両側路車間通信部３４や車車間通信部３５に検波器を設け、その検波器によって検出する構成とすればよい。よって、車両Ａの車両側路車間通信部３４や車車間通信部３５が請求項の受信電力検出手段に相当する。
【００７３】
一例としては、受信電力が所定の閾値以上であった場合に、パケットの送信元が近くにあるものとして、重要度を「重要」と判定し、所定の閾値以上でなかった場合に、パケットの送信元が近くにないものとして、重要度を「通常」と判定する。これは、車車間通信や路車間通信において、送信電力は一般的に一定の値であるため、送信元から近い位置でパケットを受信するほど受信電力が大きくなることをもとにしている。送信元が車両Ｂである場合には、受信電力が所定の閾値以上であった場合に車両Ｂは近傍車両とみなされ、所定の閾値以上でなかった場合に車両Ｂは遠方車両とみなされる。また、ここで言うところの所定の閾値とは、任意に設定可能な値である。
【００７４】
なお、前述の例では、所定の閾値を基準にして「重要」と「通常」との２種類の重要度を判定する構成を示したが、必ずしもこれに限らない。例えば、複数の閾値を基準にして「重要」および「通常」以外の重要度を判定する構成としてもよい。この場合には、距離の値が小さくなるほど、接近度合いが増すほど、経過時間が短いほど、受信の頻度が低くなるほど、受信電力が大きくなるほど、重要度を高く判定する構成とすればよい。
【００７５】
また、同一のメッセージについて、メッセージの内容、パケット種別フラグ、同一の送信元からのパケットを受信した頻度（以下、受信頻度）、パケットを受信したときの受信電力（以下、受信電力）といった重要度を判定する要素ごとでの重要度の判定結果が異なった場合には、以下のようにすればよい。
【００７６】
例えば、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定した場合には、他の要素による「非重要」以外の判定結果があった場合でも重要度を「非重要」と判定する。また、不正な送信元から送信されたものと判定されていない場合には、各要素による判定結果のうち、最も重要度が高かったものを選択する構成とすればよい。例えば、同一のメッセージについて、メッセージの内容からは普通と判定されたが、パケット種別フラグからは「重要」と判定された場合には、判定結果は「重要」となる。他にも、広告フラグをもとに「非重要」と判定した場合には、他の要素による「非重要」以外の判定結果があった場合でも重要度を「非重要」と判定する構成としてもよい。
【００７７】
また、車両Ａの車両側制御装置３６は、重要度判定処理で判定した重要度の高さに応じて、パケットに含まれる配信情報についての正当性の検証の要否を判断する検証要否判断処理を実行する。よって、車両Ａの車両側制御装置３６が請求項の検証要否判断手段に相当する。
【００７８】
ここで、図５を用いて、車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローについての説明を行う。図５は、車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローを示すフローチャートである。なお、本フローは、車両Ａの車両側路車間通信部３４や車車間通信部３５でパケットを受信したときに開始される。
【００７９】
まず、ステップＳ１では、前述した重要度判定処理を実行し、ステップＳ２に移る。ステップＳ２では、重要度判定処理での重要度の判定結果が「緊急」であった場合（ステップＳ２でＹＥＳ）には、ステップＳ３に移る。また、重要度判定処理での重要度の判定結果が「緊急」でなかった場合（ステップＳ２でＮＯ）には、ステップＳ５に移る。
【００８０】
ステップＳ３では、検証が必要であると判断し、ステップＳ４に移る。ステップＳ４では、該当するパケットについて優先して検証を行うものとして、車両Ａの車両側制御装置３６のＲＡＭ等の電気的に書き換えが可能なメモリ（以下、一時格納メモリ）に格納する。詳しくは、例えば一時格納メモリの優先度付きキューに最も高い優先度として追加し、フローを終了する。よって、車両Ａの車両側制御装置３６が請求項の一時格納手段に相当する。
【００８１】
ステップＳ５では、重要度判定処理での重要度の判定結果が「重要」であった場合（ステップＳ５でＹＥＳ）には、ステップＳ６に移る。また、重要度判定処理での重要度の判定結果が「重要」でなかった場合（ステップＳ５でＮＯ）には、ステップＳ８に移る。
【００８２】
ステップＳ６では、検証が必要であると判断し、ステップＳ７に移る。ステップＳ７では、該当するパケットについて一時格納メモリへの格納順に検証を行うものとして、一時格納メモリに格納する。詳しくは、例えば一時格納メモリの優先度付きキューに「緊急」よりも低い優先度として追加し、フローを終了する。なお、判定結果が「重要」であったパケットについては、例えば一律に同じ優先度が与えられ、優先度付きキューへの追加順に検証が行われる構成とすればよい。
【００８３】
ステップＳ８では、重要度判定処理での重要度の判定結果が「通常」であった場合（ステップＳ８でＹＥＳ）には、ステップＳ９に移る。また、重要度判定処理での重要度の判定結果が「通常」でなかった場合（ステップＳ８でＮＯ）には、「非重要」であるものとして、ステップＳ１２に移る。
【００８４】
ステップＳ９では、一時格納メモリの優先度付きキューの空きがあるか否かを判定する。そして、キューの空きがあると判定した場合（ステップＳ９でＹＥＳ）には、ステップＳ１０に移る。また、キューの空きがあると判定しなかった場合（ステップＳ９でＮＯ）には、ステップＳ１２に移る。
【００８５】
ステップＳ１０では、検証が必要であると判断し、ステップＳ１１に移る。ステップＳ１１では、該当するパケットについて一時格納メモリへの格納順に検証を行うものとして、一時格納メモリに格納する。詳しくは、例えば一時格納メモリの優先度付きキューに「重要」と同じ優先度として追加し、フローを終了する。なお、「重要」と同じ優先度として優先度付きキューに追加されたパケットについては、「重要」と判定された場合のパケットと同様に、優先度付きキューへの追加順に検証が行われる。ステップＳ１２では、検証が不要であると判断し、フローを終了する。
【００８６】
なお、本実施形態では、重要度を４段階に分ける構成を示したが、必ずしもこれに限らず、３段階や２段階など他の複数段階に分ける構成としてもよい。例えば、３段階に分ける場合には、「通常」を「重要」に含めて、「緊急」、「重要」、「非重要」の３段階としてもよいし、「重要」を「通常」に含めて「緊急」、「通常」、「非重要」の３段階としてもよい。また、２段階に分ける場合には、「緊急」を「重要」に含めるとともに、「通常」を「非重要」に含めて「重要」と「非重要」の２段階とするなどの構成としてもよい。なお、判定結果に応じた検証の要否の判断の処理としては、前述したのと同様にして行う構成とすればよい。
【００８７】
図４に戻って、車両Ａの車両側制御装置３６は、検証要否判断処理で検証が必要と判断したパケットについて、そのパケットに含まれる証明書および署名を用いて、そのパケットの正当性の検証を行う検証処理を実行する。検証処理については、特許文献１に記載の検証処理と同様にして行うなど、周知の方法と同様にして行うものとする。
【００８８】
検証処理を実行したパケットのうち、正当性が検証された正規のパケットについては、前述のアプリの処理（以下、アプリ処理）に用いられ、正当性が検証されなかった不正なパケットについては破棄される。正当性が検証された正規のパケットについては、例えば一時格納メモリに一時的にキャッシュしておく構成とすればよい。これによれば、複数種類のアプリで同じパケットの検証を要求された場合であっても、キャッシュしておいた検証済みのパケットを利用することができ、検証の処理による負荷を軽減することができる。
【００８９】
なお、重要度判定処理、検証要否判断処理、およびアプリ処理と検証処理とは、同一のプロセッサで実行する構成としてもよいし、それぞれ異なるプロセッサで実行する構成としてもよい。
【００９０】
ここで、図６を用いて、配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係について説明を行なう。図６は、配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係の一例を示す表である。
【００９１】
図６中の配信情報の種別のうち、緊急回避情報は緊急車両フラグが付加された配信情報であって、車両制御情報は車両制御フラグが付加された配信情報である。また、路側機情報は路側機フラグが付加された配信情報であって、近傍車両情報は近傍車両のものとみなされた配信情報であって、マルチホップ要求情報はホッピングフラグが付加された配信情報である。
【００９２】
さらに、遠方車両の定期送信情報は、遠方車両のものとみなされた配信情報のうち、ホッピングフラグが付加されていなかったり、緊急であることを示すフラグが付加されていなかったりするなど、定期送信用の配信情報である。そして、不正車両情報は不正な送信元から送信されたものと判定された配信情報であって、広告情報は広告フラグが付加された配信情報である。なお、図６に示した配信情報の種別はあくまでも一例であって、他にも様々なものが存在する。
【００９３】
図６に示すように、配信情報の種別が緊急回避情報や車両制御情報である場合には、重要度は「緊急」と判定される。そして、検証処理では優先的に検証が行われ、アプリ処理では検証済みのパケットを用いて処理が行われる。
【００９４】
また、配信情報の種別が路側機情報や近傍車両情報やマルチホップ要求情報である場合には、重要度は「重要」と判定される。そして、検証処理では一時格納メモリのキューに追加された順（つまり、キュー順）に検証が行われ、アプリ処理では検証済みのパケットを用いて処理が行われる。
【００９５】
さらに、配信情報の種別が遠方車両の定期送信情報である場合には、重要度は「通常」と判定される。そして、検証処理では一時格納メモリのキューに空きがある場合にのみ、キュー順に検証が行われ、アプリ処理ではキューに空きがあった場合には検証済みのパケットを用いて処理が行われる一方、キューに空きがなかった場合には未検証パケットとして処理が行われる。
【００９６】
また、配信情報の種別が不正車両情報や広告情報である場合には、重要度は「非重要」と判定される。そして、検証処理では検証が行われず、アプリ処理では未検証パケットとして処理が行われる。
【００９７】
続いて、未検証パケットの処理についての説明を行う。検証済みのパケットに含まれる配信情報がアプリ処理に用いられるのに対して、未検証パケットに含まれる配信情報はアプリ処理に用いなかったり、アプリ処理において補助的に用いるように用い方を変えたりする構成とすればよい。また、未検証パケットに含まれる配信情報をアプリ処理に用いたり、一時格納メモリのキューに空きがある場合に未検証パケットの検証を行って検証済みとした後でそのパケットに含まれる配信情報をアプリ処理に用いたりする構成としてもよい。
【００９８】
例えば、配信情報の種別が不正車両情報であった場合の未検証パケットについては、未検証パケットに含まれる配信情報をアプリ処理に用いず、破棄する構成とすればよい。また、配信情報の種別が広告情報であった場合の未検証パケットについては、未検証パケットに含まれる配信情報をアプリ処理に用いる構成としてもよい。
【００９９】
ここで、図７を用いて、車両Ａの車両側制御装置３６での前述の車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例の説明を行う。図７は、車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例を説明するためのフローチャートである。
【０１００】
パケットには、配信情報として車両Ｂの速度、加速度、進行方向、および現在位置の情報が含まれているものとし、既に受信していたパケットに含まれていた車両Ｂの現在位置の情報に従って、車両Ｂの現在位置が予め登録・更新（以下、更新）されていたものとする。また、本フローは検証処理が完了したときに開始される。
【０１０１】
まず、ステップＳ２１では、検証処理において対象とするパケットの検証が行われたか否かを判定する。そして、パケットの検証が行われていた場合には、検証済みであったものとして（ステップＳ２１でＹＥＳ）、ステップＳ２２に移る。また、パケットの検証が行われていなかった場合には、未検証であるものとして（ステップＳ２１でＮＯ）、ステップＳ２３に移る。
【０１０２】
ステップＳ２２では、検証済みのパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報に従った位置に車両Ｂの現在位置を更新（つまり、位置更新）し、フローを終了する。更新した車両Ｂの現在位置については、例えば表示装置２９の電子地図上に表示したりなどする構成とすればよい。
【０１０３】
ステップＳ２３では、前回の車両Ｂの現在位置の更新時（つまり、前回更新時）からの経過時間が一定時間以下か否かを判定する。経過時間については、図示しないタイマー回路などでカウントする構成とすればよい。ここで言うところの一定時間とは任意に設定可能な時間であって、例えば１秒間とすればよい。そして、前回更新時からの経過時間が一定時間以下であると判定した場合（ステップＳ２３でＹＥＳ）には、ステップＳ２４に移る。また、前回更新時からの経過時間が一定時間以下であると判定しなかった場合（ステップＳ２３でＮＯ）には、ステップＳ２６に移る。
【０１０４】
ステップＳ２４では、前回更新時の車両Ｂの現在位置から、未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向をもとに予測される車両Ｂの現在位置を算出し、前回更新時の車両Ｂの現在位置からの乖離が一定距離以下か否かを判定する。ここで言うところの一定距離とは任意に設定可能な時間であって、例えば１０メートルとすればよい。そして、前回更新時からの現在位置の乖離が一定距離以下であると判定した場合（ステップＳ２４でＹＥＳ）には、ステップＳ２５に移る。また、前回更新時からの現在位置の乖離が一定距離以下であると判定しなかった場合（ステップＳ２４でＮＯ）には、ステップＳ２６に移る。
【０１０５】
ステップＳ２５では、前回更新時の車両Ｂの現在位置を、例えば未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向をもとに補正（つまり、位置補正）し、フローを終了する。このように、ステップＳ２５では、未検証のパケットに含まれる配信情報に従った位置への車両Ｂの位置更新までは行わないが、車両Ｂの現在位置の補正といった補助的な利用を行う。
【０１０６】
ステップＳ２６では、前述の一時格納メモリの優先度付きキューの空きがあるか否かを判定する。そして、キューの空きがあると判定した場合（ステップＳ２６でＹＥＳ）には、ステップＳ２７に移る。また、キューの空きがあると判定しなかった場合（ステップＳ２６でＮＯ）には、ステップＳ２８に移る。
【０１０７】
ステップＳ２７では、キュー順に従って未検証のパケットの検証を行う。そして、正当性が検証された場合（ステップＳ２７でＹＥＳ）には、ステップＳ２２に移る。また、正当性が検証されなかった場合（ステップＳ２７でＮＯ）には、ステップＳ２８に移る。
【０１０８】
ステップＳ２８では、未検証のパケットを破棄し、この未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報を車両位置更新アプリに利用せずにフローを終了する。
【０１０９】
以上の構成によれば、車両Ａの車両側路車間通信部３４や車車間通信部３５で受信したパケットについては、重要度判定処理から検証要否判断処理までの処理で正当性の検証の要否を判断し、検証が不要と判断したパケットについては検証を行わないので、受信するパケットの全てについて検証を行う必要がなくなる。よって、ナビゲーション装置２での検証の回数を減らすことができ、単方向通信で送信される情報の検証の処理による負荷を軽減することが可能になる。
【０１１０】
また、重要度判定処理において段階で判定した重要度の高さに応じて、パケットについての検証の要否を判断するので、自車両にとって緊急性や重要性が高いと思われるものほど優先して検証を行う一方、緊急性や重要性が低いと思われるものほど検証を省くことによって、受信したパケットに含まれる配信情報の重要度を考慮しながら、検証の処理による負荷を軽減することが可能になる。
【０１１１】
さらに、重要度が「通常」であると判定したパケットについては、一時格納メモリの優先度付きキューに空きがある場合にのみ検証を行うので、検証の処理による負荷が一定の限度を越えないようにしながらも、より多くのパケットについての検証を行うことが可能になる。
【０１１２】
なお、前述の実施形態では、請求項の通信装置をナビゲーション装置に適用する構成を示したが、必ずしもこれに限らない。例えば、位置検出器２１や地図データ入力器２６や各センサ２２〜２５等から必要な情報を取得する機能、および路側機１や他車両から無線での単方向通信で送信されるパケットを受信する機能を備える車載装置であれば、ナビゲーション装置以外に適用する構成としてもよい。
【０１１３】
また、請求項の通信装置を車載装置に適用する構成に限らず、路側機１に適用する構成としてもよい。例えば、路側機１の路側機側制御部１３が、車両から無線での単方向通信によって送信されてくるパケットについて重要度判定処理から検証要否判断処理までの処理を行って、検証の要否を判断する構成とすればよい。この場合には、路側機側路車間通信部１１が請求項の受信手段および受信電力検出手段に相当し、路側機側制御部１３が請求項の受信頻度検出手段、検証要否判断手段、および一時格納手段に相当することになる。
【０１１４】
なお、本発明は、上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【符号の説明】
【０１１５】
１ 路側機（通信装置）、１１ 路側機側路車間通信部（受信手段、受信電力検出手段）、１２ センタ通信部、１３ 路側機側制御部（受信頻度検出手段、検証要否判断手段、一時格納手段）、２ ナビゲーション装置（通信装置）、２１ 位置検出器、２２ 加速度センサ、２３ ジャイロスコープ、２４ 車輪速センサ、２５ ＧＰＳ受信機、２６ 地図データ入力器、２７ 記憶媒体、２８ 外部メモリ、２９ 表示装置、３０ 音声出力装置、３１ 操作スイッチ群、３２ リモコン、３３ リモコンセンサ、３４ 車両側路車間通信部（受信手段、受信電力検出手段）、３５ 車車間通信部（受信手段、受信電力検出手段）、３６ 車両側制御装置（受信頻度検出手段、検証要否判断手段、一時格納手段）、１００ 運転支援システム
【技術分野】
【０００１】
本発明は、単方向通信で送信される情報を受信する通信装置に関するものである。
【背景技術】
【０００２】
従来から、各車両の端末間で行われる通信（以下、車車間通信）や車両の端末と路側機との間で行われる通信（以下、路車間通信）によって情報を送受信する技術が知られている。
【０００３】
これら車車間通信や路車間通信が双方向通信である場合には、通信相手の信頼性の証明や通信データの改竄防止に必要な証明書や秘匿に必要な鍵の交換を複数回のハンドシェイクによって行うことで、悪意のあるなりすまし端末（以下、不正端末）から送信された偽の通信データを判別することができる。
【０００４】
しかしながら、これら車車間通信や路車間通信がブロードキャスト型の通信（つまり、単方向通信）であった場合には、不正端末から送信された偽の通信データを、上記ハンドシェイクを行って判別することができないという問題点があった。
【０００５】
そこで、この問題を解決する手段として、不正端末から送信された偽の通信データを受信側のみで判別する技術が提案されている。例えば、特許文献１には、車両に関する情報に加えて署名、公開鍵、公開鍵証明書を含むフレームを送信側の車両から送信し、受信側の車両でこのフレームを受信した後に、公開鍵証明書から公開鍵を検証して正しい公開鍵であるか否かを判断するとともに、署名と公開鍵とを用いてフレームの内容が改竄されていないかを検証する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−８１５２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に開示の技術では、受信側での検証の処理にかかる負荷が大きくなってしまうという問題を有していた。詳しく説明すると、車車間通信における車両の端末からの情報の送信は１秒間に１０回程度であり、路車間通信における路側機からの情報の送信は１秒間に７０回程度であるが、受信側は複数の通信相手から情報を受信することがあるため、１秒間に１０００回以上の受信を行う可能性がある。検証の処理には多くの計算が必要であるため、送信されてくる情報全てをリアルタイムに検証しようとすると、膨大な量の計算を高速で行わなくてはならないことになる。
【０００８】
また、将来的に半導体技術の進歩でプロセッサ処理能力がさらに向上した場合であっても、なりすましや改竄を防止するために例えば証明書や署名の方式がアップデートされていき、検証の処理に必要な計算の量も増えていくため、受信側での検証の処理にかかる負荷の増大は将来に渡って問題となると考えられる。
【０００９】
本発明は、上記従来の問題点に鑑みなされたものであって、その目的は、単方向通信で送信される情報の検証の処理による負荷を軽減することを可能にする通信装置を提供することにある。
【課題を解決するための手段】
【００１０】
請求項１の通信装置によれば、受信手段で受信した他機器由来情報（つまり、証明書および署名の少なくともいずれかの検証用情報を付加して単方向通信で無線送信された情報）については、検証要否判断手段で正当性の検証の要否を判断し、検証が不要と判断した他機器由来情報については検証を行わないので、受信する他機器由来情報の全てについて検証を行う必要がなくなる。よって、通信装置での検証の回数を減らすことができ、単方向通信で送信される情報の検証の処理による負荷を軽減することが可能になる。
【００１１】
また、受信した他機器由来情報の検証の要否を判断する場合には、請求項２のように、受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の内容をもとに検証の要否を判断することが可能になる。
【００１２】
請求項２のようにする場合には、請求項３のように、他車両の位置に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他車両の位置に関する情報をもとに検証の要否を判断することが可能になる。例えば、自車両との距離が近い他車両や交差点との距離が近い他車両からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１３】
請求項２のようにする場合には、請求項４のように、他車両の位置に関する情報および当該他車両の運動に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他車両の位置に関する情報および当該他車両の運動に関する情報をもとに検証の要否を判断することが可能になる。例えば、自車両に接近してきている他車両からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１４】
請求項２のようにする場合には、請求項５のように、その他機器由来情報の鮮度に関する情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の鮮度に関する情報をもとに検証の要否を判断することが可能になる。例えば、生成されてからの時間経過が短く、鮮度の高い他機器由来情報のように、自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１５】
請求項２のようにする場合には、請求項６のように、他機器由来情報の内容をもとに、その他機器由来情報が不正な送信元から送信されたものか否かを判定し、不正な送信元から送信されたと判定した場合には、その他機器由来情報についての検証を不要と判断し、検証を行わずにその他機器由来情報を破棄する態様とすることが好ましい。これによれば、不正な送信元から送信されたと判定される他機器由来情報の検証を行わずに破棄することが可能になるので、信頼に値しない他機器由来情報について検証を行う手間を軽減することができる。
【００１６】
受信した他機器由来情報の検証の要否を判断する場合には、請求項７のように、他機器由来情報に付加された付加情報をもとに、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、他機器由来情報の送信元の種別に関する情報、当該他機器由来情報自体の種別に関する情報、および当該他機器由来情報のマルチホッピング通信におけるホッピングを要求する情報のうちの少なくともいずれの情報をもとに検証の要否を判断することが可能になる。
【００１７】
例えば、機器由来情報の送信元の種別に関する情報をもとに、緊急車両や路側機からの他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。また、他機器由来情報自体の種別に関する情報をもとに、広告の情報である他機器由来情報のように、自車両にとって緊急性や重要性が低いと思われる他機器由来情報については検証が不要と判断することが可能になる。さらに、マルチホッピング通信におけるホッピングを要求する情報をもとに、ホッピングが要求されている他機器由来情報のように、自車両にとって緊急性や重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１８】
受信した他機器由来情報の検証の要否を判断する場合には、請求項８のように、同一の送信元から送信された他機器由来情報を受信手段で受信した頻度に応じて、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、同一の送信元からの他機器由来情報の受信頻度に応じて検証の要否を判断することが可能になる。例えば、同一の送信元からの前回受信時からの経過時間が長かったり、初めて受信したりする他機器由来情報のように、自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００１９】
受信した他機器由来情報の検証の要否を判断する場合には、請求項９のように、受信手段で他機器由来情報を受信したときの受信電力に応じて、その他機器由来情報についての検証の要否を判断する態様とすることが好ましい。これによれば、受信電力に応じて検証の要否を判断することが可能となる。例えば、受信電力が高いほど、自車両に近い他車両からの他機器由来情報であると言えるので、自車両に近い他車両から受信した他機器由来情報のように、受信電力が高い自車両にとって重要性が高いと思われる他機器由来情報については検証が必要と判断することが可能になる。
【００２０】
請求項１０の構成によれば、検証要否判断手段において段階で判定した重要度の高さに応じて、他機器由来情報についての検証の要否を判断することが可能になるので、受信した他機器由来情報の重要度を考慮しながら、検証の処理による負荷を軽減することが可能になる。
【００２１】
請求項１０のようにする場合には、請求項１１のように、重要度を４段階で判定し、重要度が最も高い段階であると判定した他機器由来情報については、検証が必要であると判断して、優先して検証を行うものとして一時格納手段に格納する態様とすることが好ましい。さらに、重要度が２番目に高い段階であると判定した他機器由来情報については、検証が必要であると判断して、一時格納手段への格納順に従って検証を行うものとして一時格納手段に格納する態様とすることが好ましい。また、重要度が２番目に低い段階であると判定した他機器由来情報については、一時格納手段の容量に当該他機器由来情報を格納する空きがある場合には、検証が必要であると判断して、一時格納手段への格納順に従って検証を行うものとして一時格納手段に格納する一方、一時格納手段の容量に当該他機器由来情報を格納する空きがない場合には、検証が不要であると判断して、検証を行わない態様とすることが好ましい。そして、重要度が最も低い段階であると判定した他機器由来情報については、検証が不要であると判断して、検証を行わない態様とすることが好ましい。
【００２２】
これによれば、重要度の高いものほど優先して検証を行う一方、重要度の低いものほど検証を省くことによって、受信した他機器由来情報の重要度を考慮しながら、検証の処理による負荷を軽減することができる。また、重要度が２番目に低い段階であると判定した他機器由来情報については、一時格納手段の容量に空きがある場合にのみ検証を行うので、検証の処理による負荷が一定の限度を越えないようにしながらも、より多くの他機器由来情報についての検証を行うことが可能になる。
【００２３】
請求項１２の構成によれば、受信した他機器由来情報について検証が行われたか否かに応じて、その他機器由来情報のアプリケーションソフトウェアでの利用の有無および用い方のうちのいずれかを変えることができる。例えば、検証が行わなかった他機器由来情報についてはアプリケーションソフトウェアに利用しなかったり、補助的な利用に止めたりすることが可能になる。
【図面の簡単な説明】
【００２４】
【図１】運転支援システム１００の概略的な構成を示すブロック図である。
【図２】路側機１の概略的な構成を示すブロック図である。
【図３】（ａ）〜（ｃ）は、配信情報を送信する場合のパケットの生成の手順を説明するための模式図である。
【図４】ナビゲーション装置２の概略的な構成を示すブロック図である。
【図５】車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローを示すフローチャートである。
【図６】配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係の一例を示す表である。
【図７】車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について図面を用いて説明する。図１は、本発明が適用された運転支援システム１００の概略的な構成を示すブロック図である。図１に示す運転支援システム１００は、路側機１、車両Ａに搭載されているナビゲーション装置２、および車両Ｂに搭載されているナビゲーション装置２を含んでいる。
【００２６】
運転支援システム１００においては、路側機１と車両Ａ・Ｂのナビゲーション装置２との間での路車間通信によって情報をやり取りしたり、車両Ａのナビゲーション装置２と車両Ｂに搭載されたナビゲーション装置２との間での車車間通信によって情報をやり取りしたりすることが可能となっている。
【００２７】
以降では、特に路側機１や車両Ｂのナビゲーション装置２から車両Ａのナビゲーション装置２に向けてブロードキャスト型の無線通信（つまり、無線での単方向通信）を行うものとして説明を行う。
【００２８】
路側機１は、交差点付近の路側等の所定の場所に固定されて設置され、路車間通信を行う無線通信装置としての機能を備えている。ここで、図２を用いて路側機１の概略的な構成について説明を行う。図２は、路側機１の概略的な構成を示すブロック図である。図２に示すように路側機１は、路側機側路車間通信部１１、センタ通信部１２、および路側機側制御部１３を備えている。
【００２９】
路側機側路車間通信部１１は、ナビゲーション装置２との間で通信を行うものである。例えば、路側機側路車間通信部１１は、車両Ｂのナビゲーション装置２から車両Ｂの速度、加速度、進行方向、現在位置等の情報が送信されてきた場合には、これを受信して路側機側制御部１３に送る。なお、車両Ｂの速度、加速度、進行方向の情報が請求項の他車両の運動に関する情報に相当し、車両Ｂの現在位置の情報が請求項の他車両の位置に関する情報に相当する。
【００３０】
また、路側機側路車間通信部１１は、路側機側制御部１３から後述する配信情報が送られてきた場合は、路側機側制御部１３の指示に従って、この配信情報を車両Ａのナビゲーション装置２に向けて無線での単方向通信で送信する。路側機側路車間通信部１１は、例えばナビゲーション装置２に接続されている通信アンテナや通信機を介してナビゲーション装置２との間で通信を行うものとする。
【００３１】
路側機１とナビゲーション装置２との間での通信は、例えばＶＩＣＳ（登録商標）（Vehicle Information andCommunication System）を利用して行う構成であってもよいし、ＤＳＲＣ（Dedicate Short RangeCommunication）、無線ＬＡＮなどによって行う構成としてもよい。また、路側機１から配信される配信情報としては、例えば、車両の進行を妨げる可能性のある歩行者や他車両などの速度、加速度、進行方向、現在位置等の情報といった障害物情報、道路標識や道路標示によって規制されている一時停止場所の情報といった規制標識情報、一時停止場所での一時停止を指示する車両制御情報等の交通に関連した交通関連情報や広告の情報である広告情報などの様々な情報がある。
【００３２】
センタ通信部１２は、配信情報を統合的に管理する情報センタとの通信を行うものである。センタ通信部１２は、例えばネットワークを介して情報センタとの通信を行い、情報センタから配信情報を取得したり、路側機１が車両Ｂのナビゲーション装置２から受信した車両Ｂの速度、加速度、進行方向、現在位置等の情報を情報センタに送ったりする。
【００３３】
路側機側制御部１３は、通常のコンピュータとして構成されており、内部には周知のＣＰＵ、ＲＯＭやＲＡＭ等のメモリ、Ｉ／Ｏ及びこれらの構成を接続するバスライン（いずれも図示せず）が備えられている。路側機側制御部１３は、路側機側路車間通信部１１、センタ通信部１２から入力された各種情報に基づき各種処理を実行する。
【００３４】
例えば、路側機側制御部１３は、センタ通信部１２で情報センタから取得した配信情報や路側機側路車間通信部１１でＢ車両のナビゲーション装置２から取得した車両Ｂの速度、加速度、進行方向、現在位置等の情報といった配信情報をもとに、無線での単方向通信で配信情報の送信を行うためのパケットを生成する。
【００３５】
ここで、図３（ａ）〜図３（ｃ）を用いて、配信情報を送信する場合のパケットの生成の手順についての説明を行う。図３（ａ）〜図３（ｃ）は、配信情報を送信する場合のパケットの生成の手順を説明するための模式図である。
【００３６】
図３（ａ）に示すように、配信情報をもとに送信用のメッセージを生成する。メッセージは暗号化されない平文の状態であるものとする。メッセージには、例えば前述した配信情報や路側機１を個別に識別するための路側機ＩＤやメッセージを生成した時刻の情報である情報生成時刻等を含むようにすればよい。また、メッセージの後部にパケット種別フラグ（図中のＦ）を付加する。
【００３７】
パケット種別フラグとは、メッセージの送信元の種別に関する情報やメッセージ自体の種別に関する情報やメッセージのマルチホッピング通信におけるホッピングを要求する情報（以下、ホッピングフラグ）などの付加情報である。例えば、メッセージの送信元の種別が路側機の場合には、メッセージの送信元の種別に関する情報として路側機フラグが付加される。また、メッセージ自体の種別が広告の場合には、メッセージ自体の種別の情報として広告フラグが付加され、メッセージ自体の種別が一時停止の指示等の車両制御の場合には、車両制御フラグが付加される。
【００３８】
続いて、図３（ｂ）に示すように、電子証明書（以下、証明書）と電子署名（以下、署名）とをパケット種別フラグの後部に付加する。ここで言うところの証明書とは、例えば第３者機関が発行するルート証明書であって、正規の端末であることを表すデータである。また、署名とは、メッセージに付与する電子的な徴証であって、メッセージが改竄されていないことを保証するためのデータである。そして、図３（ｃ）に示すように、パケットの先頭にヘッダを付加することで配信情報の送信を行うためのパケットの生成を完了する。
【００３９】
なお、証明書と署名とのうちのいずれか一方のみを付加する構成としてもよいが、セキュリティの向上の点から、証明書と署名との両方をメッセージに付加する構成がより好ましい。これら証明書や署名が請求項の検証用情報に相当する。
【００４０】
図２に戻って、路側機側制御部１３は、生成したパケットを路側機側路車間通信部１１から車両Ａのナビゲーション装置２に向けて送信させる。路側機側制御部１３は、パケットを例えば定期的（１秒間に７０回程度など）に送信させるものとする。
【００４１】
ナビゲーション装置２は、前述したように車両Ａ・Ｂに搭載されるものである。ナビゲーション装置２は、経路探索や経路案内等のナビゲーション機能を有している他に、例えば、前述の路車間通信や車車間通信を行うための通信機能を有している。なお、車両Ａのナビゲーション装置２が請求項の通信装置に相当する。
【００４２】
ここで、図４を用いてナビゲーション装置２の概略的な構成について説明を行う。図４は、ナビゲーション装置２の概略的な構成を示すブロック図である。図４に示すようにナビゲーション装置２は、位置検出器２１、地図データ入力器２６、記憶媒体２７、外部メモリ２８、表示装置２９、音声出力装置３０、操作スイッチ群３１、リモートコントロール端末（以下リモコン）３２、リモコンセンサ３３、車両側路車間通信部３４、車車間通信部３５、および車両側制御装置３６を備えている。
【００４３】
位置検出器２１は、自車両の加速度を検出する加速度センサ２２、自車両の鉛直方向周りの角速度を検出するジャイロスコープ２３、各転動輪の回転速度から自車両の速度を検出する車輪速センサ２４、および人工衛星からの電波に基づいて自車両の現在位置を検出するＧＰＳ（Global Positioning System）のためのＧＰＳ受信機２５を有しており、定期的に自車両の現在位置および進行方向の検出を行う。なお、各センサの精度によっては位置検出器２１を上述した内の一部で構成してもよく、さらに、図示しない地磁気センサ、ステアリングの回転センサ等を用いてもよい。
【００４４】
地図データ入力器２６は、記憶媒体２７が装着され、その記憶媒体２７に格納されている位置検出の精度向上のためのいわゆるマップマッチング用データ、地図データ、および目印データを含む各種データを入力するための装置である。地図データには、道路を示すリンクデータとノードデータとが含まれる。
【００４５】
なお、リンクとは、地図上の各道路を交差・分岐・合流する点等の複数のノードにて分割したときのノード間を結ぶものである。リンクデータは、リンクを特定する固有番号（リンクＩＤ）、リンクの長さを示すリンク長、リンク方向、リンク方位、リンクの始端及び終端ノード座標（緯度・経度）等の各データから構成される。
【００４６】
一方、ノードデータは、地図上の各道路が交差、合流、分岐するノード毎に固有の番号を付したノードＩＤ、ノード座標、ノード名称、ノードに接続するリンクのリンクＩＤが記述される接続リンクＩＤ等の各データから構成される。
【００４７】
外部メモリ２８は、書き込み可能なＨＤＤ等の大容量記憶装置である。外部メモリ２８には大量のデータや電源をオフしても消去してはいけないデータを記憶したり、頻繁に使用するデータを地図データ入力器２６からコピーして利用したりする等の用途がある。
【００４８】
表示装置２９は、テキストや画像を表示するものであって、液晶ディスプレイ、有機ＥＬディスプレイ、プラズマディスプレイ等を用いて構成することができる。また、音声出力装置３０は、スピーカ等から構成され、車両側制御装置３６の指示に基づいて、音声や警告音等を出力する。
【００４９】
操作スイッチ群３１は、例えば表示装置２９と一体になったタッチスイッチもしくはメカニカルなスイッチ等が用いられ、スイッチ操作により車両側制御装置３６へ各種機能の操作指示を行う。リモコン３２には複数の操作スイッチ（図示せず）が設けられ、スイッチ操作によりリモコンセンサ３３を介して各種指令信号を車両側制御装置３６に入力することにより、操作スイッチ群３１と同じ機能を車両側制御装置３６に対して実行させることが可能である。
【００５０】
車両側路車間通信部３４は、路側機１との間で通信を行うものである。例えば、車両Ａの車両側路車間通信部３４は、路側機１から送信される前述のパケットを受信する。また、車両Ｂの車両側路車間通信部３４は、車両Ｂの速度、加速度、進行方向、現在位置等の情報を路側機１に送信する。速度の情報については車輪速センサ２４、加速度の情報については加速度センサ２２、進行方向および現在位置の情報については位置検出器２１から得る構成とすればよい。
【００５１】
車車間通信部３５は、他車両に搭載されたナビゲーション装置２の車車間通信部３５との間で無線通信によってデータの送受信を行う（つまり、車車間通信を行う）ものである。例えば、車両Ｂの車車間通信部３５は、車両側制御装置３６から配信情報が送られてきた場合は、路側機側制御部１３の指示に従って、この配信情報を車両Ａのナビゲーション装置２に向けて無線での単方向通信で送信する。また、車両Ａの車車間通信部３５は、車両Ｂの車車間通信部３５から送信されてくる配信情報を受信して車両Ａの車両側制御装置３６に送る。なお、車車間通信部３５は、無線ＬＡＮ等の無線通信によって情報の送受信を行う構成とすればよい。
【００５２】
例えば、車両側路車間通信部３４および車車間通信部３５は、ナビゲーション装置２に接続された通信アンテナやナビゲーション装置２に接続された通信機を利用して通信を行う構成とすればよい。また、車両側路車間通信部３４および車車間通信部３５は、別体に設けられる構成であってもよいし、一体に設けられる構成であってもよい。
【００５３】
車両側制御装置３６は通常のコンピュータとして構成されており、内部には周知のＣＰＵ、ＲＯＭやＲＡＭ等のメモリ、Ｉ／Ｏ、およびこれらの構成を接続するバスライン（いずれも図示せず）が備えられている。車両側制御装置３６は、位置検出器２１、地図データ入力器２６、外部メモリ２８、操作スイッチ群３１、リモコンセンサ３３、車両側路車間通信部３４、車車間通信部３５から入力された各種情報に基づき、ナビゲーション機能としての処理やパケットの送信に関連する処理や受信したパケットに含まれる配信情報の重要度の判定の処理やパケットの検証の要否の判断の処理などを実行する。
【００５４】
例えば、車両Ｂの車両側制御装置３６は、位置検出器２１や各センサ２２〜２５などから得られる車両Ｂの速度、加速度、進行方向、現在位置等の情報を配信情報とし、この配信情報をもと、無線での単方向通信で配信情報の送信を行うためのパケットを生成する。このパケットの生成は、前述した路側機側制御部１３でのパケットの生成と同様にして行われる。
【００５５】
以下では、車両Ｂから送信するパケットにおいて特有の構成について説明を行い、路側機１から送信するパケットと同様の構成については説明を省略する。車両Ｂから送信するパケットのメッセージには、例えば上記配信情報や車両Ｂを個別に識別するための車両ＩＤやメッセージを生成した時刻の情報である情報生成時刻等を含むようにすればよい。
【００５６】
パケット種別フラグとしては、メッセージの送信元の種別が緊急車両の場合には、メッセージの送信元の種別に関する情報として緊急車両フラグが付加され、緊急車両以外の一般車両の場合には、メッセージの送信元の種別に関する情報として一般車両フラグが付加される。
【００５７】
また、車両Ｂの車両側制御装置３６は、生成したパケットを車両Ｂの車車間通信部３５から車両Ａの車車間通信部３５に向けて送信させる。車両Ｂの車両側制御装置３６は、パケットを例えば定期的（１秒間に１０回程度など）に送信させるものとする。
【００５８】
車両Ａの車両側制御装置３６は、受信したパケットに含まれる配信情報を用いる各種のアプリケーションソフトウェア（以下、アプリ）を保持しており、配信情報に応じたアプリを実行し、各種のサービスを提供する。例えば、車両Ｂの速度、加速度、進行方向、現在位置の情報をもとに車両Ｂの位置を更新するアプリ（以下、車両位置更新アプリ）や車両Ａ・Ｂの速度、加速度、進行方向、現在位置の情報をもとに車両Ａ・Ｂの接触危険性を判定して報知するアプリがある。また、前述の障害物情報、規制標識情報、広告情報等を表示装置２９や音声出力装置３０から提示するアプリなどがある。
【００５９】
また、車両Ａの車両側制御装置３６は、車両Ｂからのパケットを車車間通信部３５で受信したり、路側機１からのパケットを車両側路車間通信部３４から受信したりした場合に、このパケットに含まれる配信情報の重要度を段階で判定する重要度判定処理を実行する。なお、車両Ｂや路側機１から送信されるメッセージが請求項の他機器由来情報に相当し、車両Ａの車両側路車間通信部３４や車車間通信部３５が請求項の受信手段に相当する。
【００６０】
重要度判定処理では、例えば重要度を４段階に分け、重要度が最も高い段階を「緊急」、重要度が２番目に高い段階を「重要」、重要度が２番目に低い段階を「通常」、重要度が最も低い段階を「非重要」と判定するものとする。
【００６１】
重要度の判定は、パケットに含まれるメッセージの内容をもとに行う構成としてもよい。一例としては、車両Ｂの現在位置の情報をもとに重要度を判定する構成とすればよい。具体的には、車両Ａの位置検出器２１から得られる車両Ａの現在位置の情報とパケットに含まれる車両Ｂの現在位置の情報とから車両Ａと車両Ｂとの距離を算出する。そして、車両Ａと車両Ｂとの距離が所定の閾値以下であった場合に、車両Ｂが近傍車両であるものとみなして重要度を「重要」と判定し、所定の閾値以下でなかった場合に、車両Ｂが遠方車両であるものとみなして重要度を「通常」と判定する構成とすればよい。ここで言うところの所定の閾値とは、車両Ａと車両Ｂとの接触の危険性を考慮して定められる値であって、任意に設定可能な値である。
【００６２】
また、車両Ａの地図データ入力器２６から得られるノードデータとパケットに含まれる車両Ｂの現在位置の情報とから車両Ｂの直近の交差点と車両Ｂとの距離を算出して、当該交差点と車両Ｂとの距離が所定の閾値以下であった場合に、重要度を「重要」と判定し、所定の閾値以下でなかった場合に、重要度を「通常」と判定する構成としてもよい。ここで言うところの所定の閾値とは、任意に設定可能な値である。
【００６３】
さらに、車両Ｂの現在位置の情報および車両Ｂの速度、加速度、進行方向の情報をもとに重要度を判定する構成としてもよい。具体的には、車両Ａの車輪速センサ２４、加速度センサ２２、位置検出器２１からそれぞれ得られる車両Ａの速度、加速度、進行方向、および現在位置の情報とパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報とから車両Ａと車両Ｂとの接近度合いを算出する。そして、車両Ａと車両Ｂとの接近度合いが所定の閾値以下であった場合に、重要度を「重要」と判定し、所定の閾値以下でなかった場合に、重要度を「通常」と判定する構成とすればよい。ここで言うところの所定の閾値とは、車両Ａと車両Ｂとの接触の危険性を考慮して定められる値であって、任意に設定可能な値である。
【００６４】
また、メッセージの情報生成時刻をもとに重要度を判定する構成としてもよい。具体的には、パケットに含まれる情報生成時刻をもとに、メッセージが生成されてからの経過時間を算出する。そして、経過時間が所定の時間以下であった場合に、鮮度が高いものとして重要度を「重要」と判定し、所定の閾値以下でなかった場合に、鮮度が低いものとして重要度を「通常」と判定する構成とすればよい。よって、情報生成時刻が請求項の鮮度に関する情報に相当する。ここで言うところの所定の時間とは、任意に設定可能な時間である。
【００６５】
さらに、パケットに含まれるメッセージの内容をもとに、そのメッセージが、所謂なりすまし端末といった不正な送信元から送信されたものか否かを判定し、その判定結果に応じて重要度を判定する構成としてもよい。
【００６６】
具体的には、予め不正な送信元が使用している車両ＩＤや路側機ＩＤなどのリスト（以下、不正端末リスト）を保持しておき、パケットに含まれる車両ＩＤや路側機ＩＤが不正端末リストに存在するか否かに応じて不正な送信元から送信されたものか否かを判定する。そして、不正端末リストにＩＤが存在した場合には、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定する。不正端末リストにＩＤが存在しなかった場合には、不正な送信元から送信されたものと判定せず、パケットに含まれるメッセージの内容などの他の要素をもとに重要度を判定する。
【００６７】
不正端末リストについては、ＤＣＭ等の通信モジュールや携帯電話機を介したり、車車間通信や路車間通信を介したりして、ナビゲーション装置２が不正端末リストを管理しているサーバから取得する構成とすればよい。
【００６８】
また、複数回の受信分における車両Ｂの現在位置の情報および車両Ｂの速度、加速度、進行方向の情報をもとに、車両Ｂの現在位置の変化を求め、その変化が不自然か否かに応じて不正な送信元から送信されたものか否かを判定する構成としてもよい。この場合、車両Ｂの走行軌跡が途中でジャンプしていたり、速度、加速度から算出される位置から誤差範囲を超えて逸脱していたりしたことをもって変化が不自然であるとすればよい。そして、変化が不自然であった場合には、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定する。
【００６９】
他にも、重要度の判定は、メッセージに付加されたパケット種別フラグをもとに行う構成としてもよい。一例としては、前述の緊急車両フラグや車両制御フラグが付加されていた場合には、車両Ａが緊急に対応しなければならないものとして、重要度を「緊急」と判定する。また、ホッピングフラグが付加されていた場合には、ホッピングにより遠距離まで伝えなければならない重要なメッセージであるものとして、重要度を「重要」と判定する。路側機フラグが付加されていた場合にも、重要度を「重要」と判定する。さらに、広告フラグが付加されていた場合には、重要度を「非重要」と判定する。
【００７０】
また、重要度の判定は、同一の送信元から送信されたパケットを受信した頻度をもとに行う構成としてもよい。同一の送信元から送信されたパケットか否かについては、メッセージに含まれる車両ＩＤや路側機ＩＤが一致する場合に同一の送信元から送信されたものと車両Ａの車両側制御装置３６で判別する構成とすればよい。受信した頻度の検出については、受信したパケットのメッセージと図示しないタイマー回路のカウントとをもとに、車両Ａの車両側制御装置３６で行う構成とすればよい。よって、車両Ａの車両側制御装置３６が請求項の受信頻度検出手段に相当する。
【００７１】
一例としては、同一の送信元から受信したパケットの受信間隔が一定時間以上であった場合や同一の送信元から初めて受信したパケットであった場合といった、受信した頻度が所定の閾値以下であった場合に、似た情報を既に受信している可能性が低いものとして、重要度を「重要」と判定する。そして、同一の送信元から受信したパケットの受信間隔が一定時間未満であった場合といった、受信した頻度が所定の閾値以下でなかった場合に、似た情報を既に受信している可能性が高いものとして、重要度を「通常」と判定する。ここで言うところの一定時間および所定の閾値とは、任意に設定可能な値である。
【００７２】
さらに、重要度の判定は、車両Ａの車両側路車間通信部３４や車車間通信部３５でパケットを受信したときの受信電力をもとに行う構成としてもよい。受信電力については、車両Ａの車両側路車間通信部３４や車車間通信部３５に検波器を設け、その検波器によって検出する構成とすればよい。よって、車両Ａの車両側路車間通信部３４や車車間通信部３５が請求項の受信電力検出手段に相当する。
【００７３】
一例としては、受信電力が所定の閾値以上であった場合に、パケットの送信元が近くにあるものとして、重要度を「重要」と判定し、所定の閾値以上でなかった場合に、パケットの送信元が近くにないものとして、重要度を「通常」と判定する。これは、車車間通信や路車間通信において、送信電力は一般的に一定の値であるため、送信元から近い位置でパケットを受信するほど受信電力が大きくなることをもとにしている。送信元が車両Ｂである場合には、受信電力が所定の閾値以上であった場合に車両Ｂは近傍車両とみなされ、所定の閾値以上でなかった場合に車両Ｂは遠方車両とみなされる。また、ここで言うところの所定の閾値とは、任意に設定可能な値である。
【００７４】
なお、前述の例では、所定の閾値を基準にして「重要」と「通常」との２種類の重要度を判定する構成を示したが、必ずしもこれに限らない。例えば、複数の閾値を基準にして「重要」および「通常」以外の重要度を判定する構成としてもよい。この場合には、距離の値が小さくなるほど、接近度合いが増すほど、経過時間が短いほど、受信の頻度が低くなるほど、受信電力が大きくなるほど、重要度を高く判定する構成とすればよい。
【００７５】
また、同一のメッセージについて、メッセージの内容、パケット種別フラグ、同一の送信元からのパケットを受信した頻度（以下、受信頻度）、パケットを受信したときの受信電力（以下、受信電力）といった重要度を判定する要素ごとでの重要度の判定結果が異なった場合には、以下のようにすればよい。
【００７６】
例えば、不正な送信元から送信されたものと判定し、重要度を「非重要」と判定した場合には、他の要素による「非重要」以外の判定結果があった場合でも重要度を「非重要」と判定する。また、不正な送信元から送信されたものと判定されていない場合には、各要素による判定結果のうち、最も重要度が高かったものを選択する構成とすればよい。例えば、同一のメッセージについて、メッセージの内容からは普通と判定されたが、パケット種別フラグからは「重要」と判定された場合には、判定結果は「重要」となる。他にも、広告フラグをもとに「非重要」と判定した場合には、他の要素による「非重要」以外の判定結果があった場合でも重要度を「非重要」と判定する構成としてもよい。
【００７７】
また、車両Ａの車両側制御装置３６は、重要度判定処理で判定した重要度の高さに応じて、パケットに含まれる配信情報についての正当性の検証の要否を判断する検証要否判断処理を実行する。よって、車両Ａの車両側制御装置３６が請求項の検証要否判断手段に相当する。
【００７８】
ここで、図５を用いて、車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローについての説明を行う。図５は、車両Ａの車両側制御装置３６での重要度判定処理から検証要否判断処理にかけてのフローを示すフローチャートである。なお、本フローは、車両Ａの車両側路車間通信部３４や車車間通信部３５でパケットを受信したときに開始される。
【００７９】
まず、ステップＳ１では、前述した重要度判定処理を実行し、ステップＳ２に移る。ステップＳ２では、重要度判定処理での重要度の判定結果が「緊急」であった場合（ステップＳ２でＹＥＳ）には、ステップＳ３に移る。また、重要度判定処理での重要度の判定結果が「緊急」でなかった場合（ステップＳ２でＮＯ）には、ステップＳ５に移る。
【００８０】
ステップＳ３では、検証が必要であると判断し、ステップＳ４に移る。ステップＳ４では、該当するパケットについて優先して検証を行うものとして、車両Ａの車両側制御装置３６のＲＡＭ等の電気的に書き換えが可能なメモリ（以下、一時格納メモリ）に格納する。詳しくは、例えば一時格納メモリの優先度付きキューに最も高い優先度として追加し、フローを終了する。よって、車両Ａの車両側制御装置３６が請求項の一時格納手段に相当する。
【００８１】
ステップＳ５では、重要度判定処理での重要度の判定結果が「重要」であった場合（ステップＳ５でＹＥＳ）には、ステップＳ６に移る。また、重要度判定処理での重要度の判定結果が「重要」でなかった場合（ステップＳ５でＮＯ）には、ステップＳ８に移る。
【００８２】
ステップＳ６では、検証が必要であると判断し、ステップＳ７に移る。ステップＳ７では、該当するパケットについて一時格納メモリへの格納順に検証を行うものとして、一時格納メモリに格納する。詳しくは、例えば一時格納メモリの優先度付きキューに「緊急」よりも低い優先度として追加し、フローを終了する。なお、判定結果が「重要」であったパケットについては、例えば一律に同じ優先度が与えられ、優先度付きキューへの追加順に検証が行われる構成とすればよい。
【００８３】
ステップＳ８では、重要度判定処理での重要度の判定結果が「通常」であった場合（ステップＳ８でＹＥＳ）には、ステップＳ９に移る。また、重要度判定処理での重要度の判定結果が「通常」でなかった場合（ステップＳ８でＮＯ）には、「非重要」であるものとして、ステップＳ１２に移る。
【００８４】
ステップＳ９では、一時格納メモリの優先度付きキューの空きがあるか否かを判定する。そして、キューの空きがあると判定した場合（ステップＳ９でＹＥＳ）には、ステップＳ１０に移る。また、キューの空きがあると判定しなかった場合（ステップＳ９でＮＯ）には、ステップＳ１２に移る。
【００８５】
ステップＳ１０では、検証が必要であると判断し、ステップＳ１１に移る。ステップＳ１１では、該当するパケットについて一時格納メモリへの格納順に検証を行うものとして、一時格納メモリに格納する。詳しくは、例えば一時格納メモリの優先度付きキューに「重要」と同じ優先度として追加し、フローを終了する。なお、「重要」と同じ優先度として優先度付きキューに追加されたパケットについては、「重要」と判定された場合のパケットと同様に、優先度付きキューへの追加順に検証が行われる。ステップＳ１２では、検証が不要であると判断し、フローを終了する。
【００８６】
なお、本実施形態では、重要度を４段階に分ける構成を示したが、必ずしもこれに限らず、３段階や２段階など他の複数段階に分ける構成としてもよい。例えば、３段階に分ける場合には、「通常」を「重要」に含めて、「緊急」、「重要」、「非重要」の３段階としてもよいし、「重要」を「通常」に含めて「緊急」、「通常」、「非重要」の３段階としてもよい。また、２段階に分ける場合には、「緊急」を「重要」に含めるとともに、「通常」を「非重要」に含めて「重要」と「非重要」の２段階とするなどの構成としてもよい。なお、判定結果に応じた検証の要否の判断の処理としては、前述したのと同様にして行う構成とすればよい。
【００８７】
図４に戻って、車両Ａの車両側制御装置３６は、検証要否判断処理で検証が必要と判断したパケットについて、そのパケットに含まれる証明書および署名を用いて、そのパケットの正当性の検証を行う検証処理を実行する。検証処理については、特許文献１に記載の検証処理と同様にして行うなど、周知の方法と同様にして行うものとする。
【００８８】
検証処理を実行したパケットのうち、正当性が検証された正規のパケットについては、前述のアプリの処理（以下、アプリ処理）に用いられ、正当性が検証されなかった不正なパケットについては破棄される。正当性が検証された正規のパケットについては、例えば一時格納メモリに一時的にキャッシュしておく構成とすればよい。これによれば、複数種類のアプリで同じパケットの検証を要求された場合であっても、キャッシュしておいた検証済みのパケットを利用することができ、検証の処理による負荷を軽減することができる。
【００８９】
なお、重要度判定処理、検証要否判断処理、およびアプリ処理と検証処理とは、同一のプロセッサで実行する構成としてもよいし、それぞれ異なるプロセッサで実行する構成としてもよい。
【００９０】
ここで、図６を用いて、配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係について説明を行なう。図６は、配信情報の種別と重要度判定処理の結果と検証処理およびアプリ処理との関係の一例を示す表である。
【００９１】
図６中の配信情報の種別のうち、緊急回避情報は緊急車両フラグが付加された配信情報であって、車両制御情報は車両制御フラグが付加された配信情報である。また、路側機情報は路側機フラグが付加された配信情報であって、近傍車両情報は近傍車両のものとみなされた配信情報であって、マルチホップ要求情報はホッピングフラグが付加された配信情報である。
【００９２】
さらに、遠方車両の定期送信情報は、遠方車両のものとみなされた配信情報のうち、ホッピングフラグが付加されていなかったり、緊急であることを示すフラグが付加されていなかったりするなど、定期送信用の配信情報である。そして、不正車両情報は不正な送信元から送信されたものと判定された配信情報であって、広告情報は広告フラグが付加された配信情報である。なお、図６に示した配信情報の種別はあくまでも一例であって、他にも様々なものが存在する。
【００９３】
図６に示すように、配信情報の種別が緊急回避情報や車両制御情報である場合には、重要度は「緊急」と判定される。そして、検証処理では優先的に検証が行われ、アプリ処理では検証済みのパケットを用いて処理が行われる。
【００９４】
また、配信情報の種別が路側機情報や近傍車両情報やマルチホップ要求情報である場合には、重要度は「重要」と判定される。そして、検証処理では一時格納メモリのキューに追加された順（つまり、キュー順）に検証が行われ、アプリ処理では検証済みのパケットを用いて処理が行われる。
【００９５】
さらに、配信情報の種別が遠方車両の定期送信情報である場合には、重要度は「通常」と判定される。そして、検証処理では一時格納メモリのキューに空きがある場合にのみ、キュー順に検証が行われ、アプリ処理ではキューに空きがあった場合には検証済みのパケットを用いて処理が行われる一方、キューに空きがなかった場合には未検証パケットとして処理が行われる。
【００９６】
また、配信情報の種別が不正車両情報や広告情報である場合には、重要度は「非重要」と判定される。そして、検証処理では検証が行われず、アプリ処理では未検証パケットとして処理が行われる。
【００９７】
続いて、未検証パケットの処理についての説明を行う。検証済みのパケットに含まれる配信情報がアプリ処理に用いられるのに対して、未検証パケットに含まれる配信情報はアプリ処理に用いなかったり、アプリ処理において補助的に用いるように用い方を変えたりする構成とすればよい。また、未検証パケットに含まれる配信情報をアプリ処理に用いたり、一時格納メモリのキューに空きがある場合に未検証パケットの検証を行って検証済みとした後でそのパケットに含まれる配信情報をアプリ処理に用いたりする構成としてもよい。
【００９８】
例えば、配信情報の種別が不正車両情報であった場合の未検証パケットについては、未検証パケットに含まれる配信情報をアプリ処理に用いず、破棄する構成とすればよい。また、配信情報の種別が広告情報であった場合の未検証パケットについては、未検証パケットに含まれる配信情報をアプリ処理に用いる構成としてもよい。
【００９９】
ここで、図７を用いて、車両Ａの車両側制御装置３６での前述の車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例の説明を行う。図７は、車両位置更新アプリにおける検証済みのパケットと未検証パケットとのそれぞれの処理についての一例を説明するためのフローチャートである。
【０１００】
パケットには、配信情報として車両Ｂの速度、加速度、進行方向、および現在位置の情報が含まれているものとし、既に受信していたパケットに含まれていた車両Ｂの現在位置の情報に従って、車両Ｂの現在位置が予め登録・更新（以下、更新）されていたものとする。また、本フローは検証処理が完了したときに開始される。
【０１０１】
まず、ステップＳ２１では、検証処理において対象とするパケットの検証が行われたか否かを判定する。そして、パケットの検証が行われていた場合には、検証済みであったものとして（ステップＳ２１でＹＥＳ）、ステップＳ２２に移る。また、パケットの検証が行われていなかった場合には、未検証であるものとして（ステップＳ２１でＮＯ）、ステップＳ２３に移る。
【０１０２】
ステップＳ２２では、検証済みのパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報に従った位置に車両Ｂの現在位置を更新（つまり、位置更新）し、フローを終了する。更新した車両Ｂの現在位置については、例えば表示装置２９の電子地図上に表示したりなどする構成とすればよい。
【０１０３】
ステップＳ２３では、前回の車両Ｂの現在位置の更新時（つまり、前回更新時）からの経過時間が一定時間以下か否かを判定する。経過時間については、図示しないタイマー回路などでカウントする構成とすればよい。ここで言うところの一定時間とは任意に設定可能な時間であって、例えば１秒間とすればよい。そして、前回更新時からの経過時間が一定時間以下であると判定した場合（ステップＳ２３でＹＥＳ）には、ステップＳ２４に移る。また、前回更新時からの経過時間が一定時間以下であると判定しなかった場合（ステップＳ２３でＮＯ）には、ステップＳ２６に移る。
【０１０４】
ステップＳ２４では、前回更新時の車両Ｂの現在位置から、未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向をもとに予測される車両Ｂの現在位置を算出し、前回更新時の車両Ｂの現在位置からの乖離が一定距離以下か否かを判定する。ここで言うところの一定距離とは任意に設定可能な時間であって、例えば１０メートルとすればよい。そして、前回更新時からの現在位置の乖離が一定距離以下であると判定した場合（ステップＳ２４でＹＥＳ）には、ステップＳ２５に移る。また、前回更新時からの現在位置の乖離が一定距離以下であると判定しなかった場合（ステップＳ２４でＮＯ）には、ステップＳ２６に移る。
【０１０５】
ステップＳ２５では、前回更新時の車両Ｂの現在位置を、例えば未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向をもとに補正（つまり、位置補正）し、フローを終了する。このように、ステップＳ２５では、未検証のパケットに含まれる配信情報に従った位置への車両Ｂの位置更新までは行わないが、車両Ｂの現在位置の補正といった補助的な利用を行う。
【０１０６】
ステップＳ２６では、前述の一時格納メモリの優先度付きキューの空きがあるか否かを判定する。そして、キューの空きがあると判定した場合（ステップＳ２６でＹＥＳ）には、ステップＳ２７に移る。また、キューの空きがあると判定しなかった場合（ステップＳ２６でＮＯ）には、ステップＳ２８に移る。
【０１０７】
ステップＳ２７では、キュー順に従って未検証のパケットの検証を行う。そして、正当性が検証された場合（ステップＳ２７でＹＥＳ）には、ステップＳ２２に移る。また、正当性が検証されなかった場合（ステップＳ２７でＮＯ）には、ステップＳ２８に移る。
【０１０８】
ステップＳ２８では、未検証のパケットを破棄し、この未検証のパケットに含まれる車両Ｂの速度、加速度、進行方向、および現在位置の情報を車両位置更新アプリに利用せずにフローを終了する。
【０１０９】
以上の構成によれば、車両Ａの車両側路車間通信部３４や車車間通信部３５で受信したパケットについては、重要度判定処理から検証要否判断処理までの処理で正当性の検証の要否を判断し、検証が不要と判断したパケットについては検証を行わないので、受信するパケットの全てについて検証を行う必要がなくなる。よって、ナビゲーション装置２での検証の回数を減らすことができ、単方向通信で送信される情報の検証の処理による負荷を軽減することが可能になる。
【０１１０】
また、重要度判定処理において段階で判定した重要度の高さに応じて、パケットについての検証の要否を判断するので、自車両にとって緊急性や重要性が高いと思われるものほど優先して検証を行う一方、緊急性や重要性が低いと思われるものほど検証を省くことによって、受信したパケットに含まれる配信情報の重要度を考慮しながら、検証の処理による負荷を軽減することが可能になる。
【０１１１】
さらに、重要度が「通常」であると判定したパケットについては、一時格納メモリの優先度付きキューに空きがある場合にのみ検証を行うので、検証の処理による負荷が一定の限度を越えないようにしながらも、より多くのパケットについての検証を行うことが可能になる。
【０１１２】
なお、前述の実施形態では、請求項の通信装置をナビゲーション装置に適用する構成を示したが、必ずしもこれに限らない。例えば、位置検出器２１や地図データ入力器２６や各センサ２２〜２５等から必要な情報を取得する機能、および路側機１や他車両から無線での単方向通信で送信されるパケットを受信する機能を備える車載装置であれば、ナビゲーション装置以外に適用する構成としてもよい。
【０１１３】
また、請求項の通信装置を車載装置に適用する構成に限らず、路側機１に適用する構成としてもよい。例えば、路側機１の路側機側制御部１３が、車両から無線での単方向通信によって送信されてくるパケットについて重要度判定処理から検証要否判断処理までの処理を行って、検証の要否を判断する構成とすればよい。この場合には、路側機側路車間通信部１１が請求項の受信手段および受信電力検出手段に相当し、路側機側制御部１３が請求項の受信頻度検出手段、検証要否判断手段、および一時格納手段に相当することになる。
【０１１４】
なお、本発明は、上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【符号の説明】
【０１１５】
１ 路側機（通信装置）、１１ 路側機側路車間通信部（受信手段、受信電力検出手段）、１２ センタ通信部、１３ 路側機側制御部（受信頻度検出手段、検証要否判断手段、一時格納手段）、２ ナビゲーション装置（通信装置）、２１ 位置検出器、２２ 加速度センサ、２３ ジャイロスコープ、２４ 車輪速センサ、２５ ＧＰＳ受信機、２６ 地図データ入力器、２７ 記憶媒体、２８ 外部メモリ、２９ 表示装置、３０ 音声出力装置、３１ 操作スイッチ群、３２ リモコン、３３ リモコンセンサ、３４ 車両側路車間通信部（受信手段、受信電力検出手段）、３５ 車車間通信部（受信手段、受信電力検出手段）、３６ 車両側制御装置（受信頻度検出手段、検証要否判断手段、一時格納手段）、１００ 運転支援システム
【特許請求の範囲】
【請求項１】
証明書および署名の少なくともいずれかの検証用情報を付加して単方向通信で無線送信された情報である他機器由来情報を受信する受信手段を備え、
前記受信手段で受信された他機器由来情報に付加されている前記検証用情報をもとに、その他機器由来情報の正当性の検証を行う通信装置であって、
前記受信手段で受信した他機器由来情報についての前記検証の要否を判断する検証要否判断手段を備え、
前記検証要否判断手段で前記検証が必要と判断した他機器由来情報については前記検証を行う一方、前記検証要否判断手段で前記検証が不要と判断した他機器由来情報については前記検証を行わないことを特徴とする通信装置。
【請求項２】
請求項１において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項３】
請求項２において、
前記通信装置は車両に搭載されるものであって、
前記他機器由来情報は、前記車両以外の他車両の位置に関する情報を少なくとも含むものであって、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記他車両の位置に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項４】
請求項２または３において、
前記通信装置は車両に搭載されるものであって、
前記他機器由来情報は、前記車両以外の他車両の位置に関する情報および当該他車両の運動に関する情報を少なくとも含むものであって、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記他車両の位置に関する情報および当該他車両の運動に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項５】
請求項２〜４のいずれか１項において、
前記他機器由来情報は、その他機器由来情報の鮮度に関する情報を少なくとも含むものであって
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記鮮度に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項６】
請求項２〜５のいずれか１項において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報が不正な送信元から送信されたものか否かを判定し、不正な送信元から送信されたと判定した場合には、その他機器由来情報についての前記検証を不要と判断し、前記検証を行わずにその他機器由来情報を破棄することを特徴とする通信装置。
【請求項７】
請求項１〜６のいずれか１項において、
前記無線送信された他機器由来情報には、当該他機器由来情報の送信元の種別に関する情報、当該他機器由来情報自体の種別に関する情報、および当該他機器由来情報のマルチホッピング通信におけるホッピングを要求する情報のうちの少なくともいずれの情報である付加情報が付加されており、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報に付加されているその付加情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項８】
請求項１〜７のいずれか１項において、
同一の送信元から送信された前記他機器由来情報を前記受信手段で受信した頻度を検出する受信頻度検出手段を備え、
前記検証要否判断手段は、前記受信頻度検出手段で検出した頻度に応じて、前記受信手段で受信した他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項９】
請求項１〜８のいずれか１項において、
前記受信手段で他機器由来情報を受信したときの受信電力を検出する受信電力検出手段を備え、
前記検証要否判断手段は、前記受信電力検出手段で検出した受信電力に応じて、前記受信手段で受信した他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項１０】
請求項１〜９のいずれか１項において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の重要度を段階で判定し、判定した重要度の高さに応じて、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項１１】
請求項１０において、
前記重要度の段階は４段階であって、
前記検証の処理待ちの前記他機器由来情報を一時的に格納する一時格納手段を備え、
前記検証要否判断手段は、
前記重要度が最も高い段階であると判定した他機器由来情報については、前記検証が必要であると判断して、優先して前記検証を行うものとして前記一時格納手段に格納し、
前記重要度が２番目に高い段階であると判定した他機器由来情報については、前記検証が必要であると判断して、前記一時格納手段への格納順に従って前記検証を行うものとして前記一時格納手段に格納し、
前記重要度が２番目に低い段階であると判定した他機器由来情報については、前記一時格納手段の容量に当該他機器由来情報を格納する空きがある場合には、前記検証が必要であると判断して、前記一時格納手段への格納順に従って前記検証を行うものとして前記一時格納手段に格納する一方、前記一時格納手段の容量に当該他機器由来情報を格納する空きがない場合には、前記検証が不要であると判断して、前記検証を行わず、
前記重要度が最も低い段階であると判定した他機器由来情報については、前記検証が不要であると判断して、前記検証を行わないことを特徴とする通信装置。
【請求項１２】
請求項１〜１１のいずれか１項において、
前記通信装置は、前記他機器由来情報を用いてアプリケーションソフトウェアを実行するものであって、
前記受信手段で受信した前記他機器由来情報について前記検証が行われたか否かに応じて、その他機器由来情報の当該アプリケーションソフトウェアでの利用の有無および用い方のうちのいずれかを変えることを特徴とする通信装置。
【請求項１】
証明書および署名の少なくともいずれかの検証用情報を付加して単方向通信で無線送信された情報である他機器由来情報を受信する受信手段を備え、
前記受信手段で受信された他機器由来情報に付加されている前記検証用情報をもとに、その他機器由来情報の正当性の検証を行う通信装置であって、
前記受信手段で受信した他機器由来情報についての前記検証の要否を判断する検証要否判断手段を備え、
前記検証要否判断手段で前記検証が必要と判断した他機器由来情報については前記検証を行う一方、前記検証要否判断手段で前記検証が不要と判断した他機器由来情報については前記検証を行わないことを特徴とする通信装置。
【請求項２】
請求項１において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項３】
請求項２において、
前記通信装置は車両に搭載されるものであって、
前記他機器由来情報は、前記車両以外の他車両の位置に関する情報を少なくとも含むものであって、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記他車両の位置に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項４】
請求項２または３において、
前記通信装置は車両に搭載されるものであって、
前記他機器由来情報は、前記車両以外の他車両の位置に関する情報および当該他車両の運動に関する情報を少なくとも含むものであって、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記他車両の位置に関する情報および当該他車両の運動に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項５】
請求項２〜４のいずれか１項において、
前記他機器由来情報は、その他機器由来情報の鮮度に関する情報を少なくとも含むものであって
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報のうちの前記鮮度に関する情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項６】
請求項２〜５のいずれか１項において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の内容をもとに、その他機器由来情報が不正な送信元から送信されたものか否かを判定し、不正な送信元から送信されたと判定した場合には、その他機器由来情報についての前記検証を不要と判断し、前記検証を行わずにその他機器由来情報を破棄することを特徴とする通信装置。
【請求項７】
請求項１〜６のいずれか１項において、
前記無線送信された他機器由来情報には、当該他機器由来情報の送信元の種別に関する情報、当該他機器由来情報自体の種別に関する情報、および当該他機器由来情報のマルチホッピング通信におけるホッピングを要求する情報のうちの少なくともいずれの情報である付加情報が付加されており、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報に付加されているその付加情報をもとに、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項８】
請求項１〜７のいずれか１項において、
同一の送信元から送信された前記他機器由来情報を前記受信手段で受信した頻度を検出する受信頻度検出手段を備え、
前記検証要否判断手段は、前記受信頻度検出手段で検出した頻度に応じて、前記受信手段で受信した他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項９】
請求項１〜８のいずれか１項において、
前記受信手段で他機器由来情報を受信したときの受信電力を検出する受信電力検出手段を備え、
前記検証要否判断手段は、前記受信電力検出手段で検出した受信電力に応じて、前記受信手段で受信した他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項１０】
請求項１〜９のいずれか１項において、
前記検証要否判断手段は、前記受信手段で受信した他機器由来情報の重要度を段階で判定し、判定した重要度の高さに応じて、その他機器由来情報についての前記検証の要否を判断することを特徴とする通信装置。
【請求項１１】
請求項１０において、
前記重要度の段階は４段階であって、
前記検証の処理待ちの前記他機器由来情報を一時的に格納する一時格納手段を備え、
前記検証要否判断手段は、
前記重要度が最も高い段階であると判定した他機器由来情報については、前記検証が必要であると判断して、優先して前記検証を行うものとして前記一時格納手段に格納し、
前記重要度が２番目に高い段階であると判定した他機器由来情報については、前記検証が必要であると判断して、前記一時格納手段への格納順に従って前記検証を行うものとして前記一時格納手段に格納し、
前記重要度が２番目に低い段階であると判定した他機器由来情報については、前記一時格納手段の容量に当該他機器由来情報を格納する空きがある場合には、前記検証が必要であると判断して、前記一時格納手段への格納順に従って前記検証を行うものとして前記一時格納手段に格納する一方、前記一時格納手段の容量に当該他機器由来情報を格納する空きがない場合には、前記検証が不要であると判断して、前記検証を行わず、
前記重要度が最も低い段階であると判定した他機器由来情報については、前記検証が不要であると判断して、前記検証を行わないことを特徴とする通信装置。
【請求項１２】
請求項１〜１１のいずれか１項において、
前記通信装置は、前記他機器由来情報を用いてアプリケーションソフトウェアを実行するものであって、
前記受信手段で受信した前記他機器由来情報について前記検証が行われたか否かに応じて、その他機器由来情報の当該アプリケーションソフトウェアでの利用の有無および用い方のうちのいずれかを変えることを特徴とする通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−１０００２４（Ｐ２０１２−１０００２４Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４５３８４（Ｐ２０１０−２４５３８４）
【出願日】平成２２年１１月１日（２０１０．１１．１）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１１月１日（２０１０．１１．１）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
[ Back to top ]