(57)【要約】【課題】車両の状態を適切に把握して、それに応じた遠隔制御を実行することができる車載デバイス管理システムを提供すること。【解決手段】車両に搭載された通信端末は、状態チェック処理Ｆ４を実行し、各ＥＣＵから状態情報、ログ情報、ソフトウェア情報、ファームウェア情報、ハードウェア情報などを収集し、それらの情報をプレゼンス情報として含むＳＩＰメッセージをサーバに対して送信する（Ｓ０９〜Ｓ１１）。サーバは、通信端末から取得したプレゼンス情報に基づき、各ＥＣＵに対する制御が必要か否かおよび可能か否かを判断し、必要かつ可能な場合には、ＯＭＡプロトコルによる制御情報を含むＳＩＰレスポンスを通信端末へ送信する（Ｓ１２〜Ｓ１４）。通信端末は、受信したＳＩＰレスポンスに基づき、レスポンス処理Ｆ３を実行し、ＥＣＵに対する制御を実行する。【選択図】図４
2010273181.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された車載デバイスを、前記車両とは別の場所に設けられた管理装置から遠隔制御を実行可能に構成された車載デバイス管理システムであって、
前記車両には、車載ネットワークを介して前記車載デバイスと通信可能、かつ、無線通信路を介して前記管理装置と通信可能な通信端末が搭載されており、
前記管理装置および前記通信端末は、いずれか一方から他方への通信要求を契機として通信を開始して、双方間で認証が成立したら前記双方間で暗号化通信を実行し、
しかも、前記通信端末は、前記車載デバイスまたは前記車両の状態を示すプレゼンス情報を前記管理装置へと伝送し、
前記管理装置は、前記通信端末から伝送されてきた前記プレゼンス情報に基づき、前記車載デバイスの遠隔制御を実行するか否かを判断し、
前記管理装置において前記遠隔制御を実行するとの判断がなされた場合に、前記管理装置が、前記遠隔制御を実行する上で必要となる制御情報を前記通信端末へと伝送するとともに、前記通信端末が、前記管理装置から伝送されてきた前記制御情報に基づき、前記制御情報に応じた処理を実行することで、前記遠隔制御が実行される
ことを特徴とする車載デバイス管理システム。
【請求項２】
前記管理装置および前記通信端末は、ＩＥＴＦ（Internet Engineering Task Force）で規定されたＲＦＣ（Request For Comment）３８５６に準拠した方式にて、前記プレゼンス情報を前記通信端末から前記管理装置へと伝送する
ことを特徴とする請求項１に記載の車載デバイス管理システム。
【請求項３】
前記管理装置および前記通信端末は、ＯＭＡ（Open Mobile Alliance）で規定されたＯＭＡ−ＤＭ（Open Mobile Alliance Device Management）に準拠した方式にて、前記制御情報を前記管理装置から前記通信端末へと伝送する
ことを特徴とする請求項１または請求項２に記載の車載デバイス管理システム。
【請求項４】
前記通信端末は、前記制御情報に応じた処理として、「前記車載デバイスに関するデバイス情報を前記車載デバイスから取得して、そのデバイス情報を前記管理装置へと伝送する処理」を実行する
ことを特徴とする請求項１〜請求項３のいずれかに記載の車載デバイス管理システム。
【請求項５】
前記車両には、複数の前記車載デバイスが搭載されており、
前記通信端末は、前記制御情報に応じた処理として、「複数の前記車載デバイスそれぞれに関するデバイス情報を複数の前記車載デバイスそれぞれから取得して、それらのデバイス情報を一括して前記管理装置へと伝送する処理」を実行する
ことを特徴とする請求項４に記載の車載デバイス管理システム。
【請求項６】
前記通信端末は、前記制御情報に応じた処理として、「前記車載デバイスを停止させる処理」を実行する
ことを特徴とする請求項１〜請求項５のいずれかに記載の車載デバイス管理システム。
【請求項７】
前記通信端末は、前記制御情報に応じた処理として、「前記車載デバイスのファームウェアまたはソフトウェアを更新する処理」を実行する
ことを特徴とする請求項１〜請求項６のいずれかに記載の車載デバイス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載デバイス管理システムに関する。
【背景技術】
【０００２】
従来、自動車の位置や走行状態を車両センターで把握するために、車両に搭載された移動端末と基地局との間において無線通信で情報を伝送する技術は、既に提案されている。
例えば、このような情報伝送技術として、下記特許文献１には、複数の車両それぞれに、パケット通信方式によるデータ通信を行うことが可能な車載情報端末を配置し、パケット通信網を介して車載情報端末と情報通信センターがデータ通信を行うことにより、各車両に関する情報を情報通信センターへ伝送する技術が記載されている。
【０００３】
また、特許文献１には、ひとつのキャリアを３つのチャネルに分割してパケット単位で通信を行うことで、従来に比較して格段に通信のセキュリティが高くなる旨の記載がある（特許文献１：段落［００１６］，［００５３］参照。）。この他、特許文献１には、車両の故障診断やドアの開閉制御を遠隔から実行する事例も記載されている。
【０００４】
さらに、通信のセキュリティを高める技術として、下記特許文献２には、移動端末とサーバが公開鍵を利用して暗号化通信を行う技術も提案されている。特許文献２に記載の技術の場合、サーバは移動端末の公開鍵をあらかじめ記憶しており、基地局は自局の通信エリア内に位置する移動端末の公開鍵をサーバから取得して、その公開鍵を移動端末からの要求に応じて送信する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３１０８９６号公報
【特許文献２】特開２００８−０６０７８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、上記特許文献１に記載の技術を利用すれば、車両の電子制御ユニットを情報通信センターから遠隔から制御可能で、これにより、サスペンション装置、パワーウインドウ、サンルーフ、ドア開閉装置などの各種装置を駆動することができるとされている（特許文献１：段落［００５５］参照。）。
【０００７】
しかし、一般に、上記のような各種装置を駆動してもよいかどうかは、車両の状態によっても変わるはずであり、そのような車両の状態を情報通信センターが把握していないにもかかわらず、情報通信センターが遠隔制御で各種装置を駆動できてしまうと、様々な問題が生じるおそれがある。
【０００８】
一例を挙げれば、例えば、車両が走行中であるにもかかわらず、そのような車両の状態を把握していない情報通信センターが、遠隔制御でドア開閉装置を駆動した結果、ドアが開放されてしまうと危険である。
【０００９】
また、このような危険を回避するには、車両の状態を把握していない情報通信センターが、遠隔制御でドア開閉装置を駆動しようとしても、そのような制御を車両側で無視または拒否する、といった対応をするのも一案である。しかし、情報通信センターからの制御指令を単に無視したり拒否したりするだけでは、情報通信センター側では車両の状態を把握できないという問題がある。
【００１０】
さらに、上記特許文献１に記載の技術では、携帯電話経由でのデータ送信についてセキュリティが低いことを問題視し（特許文献１：段落［０００７］参照。）、その改善策として、無線パケット通信方式でデータ通信を行うことを提案しているが（特許文献１：段落［００１６］参照。）、この程度の改善策では、必ずしも十分に秘匿性の高い通信を実現することができない。
【００１１】
より具体的には、無線パケット通信方式でデータ通信を行うだけでは、通信データが傍受されて解読される危険性があり、仮にこのような解読が行われたとすれば、正規ユーザとは別の不正ユーザが正規ユーザのふりをしてサービスを利用する、といった不正行為（いわゆる「なりすまし」と呼ばれる不正行為）の被害に遭うおそれがあり、その対策が必要となる。
【００１２】
このような問題については、上記特許文献２に記載の技術を利用すれば、通信の暗号化が行われるので、上記のような「なりすまし」を防止するための対策にはなり得るが、車載デバイス（例えば、車載ＥＣＵ）を遠隔から制御・管理する技術について、上記特許文献２には具体的な提案がなされていない。
【００１３】
したがって、これらの従来技術を組み合わせても、やはり、車両の状態を適切に把握した上で、それに応じた遠隔制御を実行する、といったことは実現できない、という問題があった。
【００１４】
本発明は、上記問題を解決するためになされたものであり、その目的は、車両の状態を適切に把握して、それに応じた遠隔制御を実行することができる車載デバイス管理システムを提供することにある。
【課題を解決するための手段】
【００１５】
以下、本発明において採用した構成について説明する。
請求項１に記載の車載デバイス管理システムは、車両に搭載された車載デバイスを、車両とは別の場所に設けられた管理装置から遠隔制御を実行可能に構成されたシステムで、車両には、車載ネットワークを介して車載デバイスと通信可能、かつ、無線通信路を介して管理装置と通信可能な通信端末が搭載されている。
【００１６】
この車載デバイス管理システムにおいて、管理装置および通信端末は、いずれか一方から他方への通信要求を契機として通信を開始して、双方間で認証が成立したら双方間で暗号化通信を実行する。
【００１７】
しかも、この車載デバイス管理システムにおいて、通信端末は、車載デバイスまたは車両の状態を示すプレゼンス情報を管理装置へと伝送する。このプレゼンス情報としては、車載デバイスまたは車両の状態を示す様々な情報を考えることができ、例えば、車載デバイスまたは車両の動作状況、ソフトウェアやファームウェアのバージョン情報などが、プレゼンス情報として伝送される。
【００１８】
このようなプレゼンス情報が通信端末から伝送されてきたら、管理装置は、プレゼンス情報に基づき、車載デバイスの遠隔制御を実行するか否かを判断する。ここで、車載デバイスの遠隔制御を実行するとの判断がなされる場合としては、例えば、車載デバイスの遠隔制御を実行可能な場合、あるいは、車載デバイスの遠隔制御を実行する必要がある場合などを挙げることができる。
【００１９】
車載デバイスの遠隔制御を実行可能な場合の具体例としては、例えば、車両の停止中しか遠隔制御ができない機能（＝例えば、ドアの開閉機能や、車両の走行中に機能を停止させることができないＥＣＵのファームウェア更新機能など）については、車両が停止中である旨を示すプレゼンス情報が管理装置へ伝送されてきた場合が、車載デバイスの遠隔制御を実行可能な場合に該当する。
【００２０】
また、車載デバイスの遠隔制御を実行する必要がある場合の具体例としては、例えば、カーナビゲーションシステム（＝車載デバイスのひとつに相当）の地図データのバージョンが古い旨を示すプレゼンス情報が管理装置へ伝送されてきた場合が、車載デバイスの遠隔制御（＝地図データの更新制御）を実行する必要がある場合に該当する。
【００２１】
こうした判断が管理装置においてなされた結果、遠隔制御を実行するとの判断がなされた場合、管理装置は、遠隔制御を実行する上で必要となる制御情報を通信端末へと伝送する。そして、通信端末が、管理装置から伝送されてきた制御情報に基づき、制御情報に応じた処理を実行することで、遠隔制御が実行される。なお、通信端末が、制御情報に応じた処理を実行する際には、通信端末自体が各種処理を実行してもよいし、通信端末が車載デバイスに対して「各種処理の実行を指示する処理」を実行してもよい。
【００２２】
以上のように構成された車載デバイス管理システムによれば、管理装置および通信端末は暗号化通信を実行し、しかも、通信端末から管理装置へと伝送されるプレゼンス情報に基づいて、遠隔制御を実行するとの判断がなされた場合に、管理装置から通信端末へ制御情報が伝送される。
【００２３】
したがって、単にパケット通信を行うだけの従来技術に比べ、よりセキュアな無線通信を実行することができ、しかも、管理装置側で車載デバイスまたは車両の状態を適切に把握した上で、それに応じた適切な遠隔制御を実行することができる。
【００２４】
ところで、本発明において、プレゼンス情報を伝送するためのプロトコルとしては、様々なものを利用し得るが、一例を挙げれば、請求項２に記載のように、管理装置および通信端末は、ＩＥＴＦ（Internet Engineering Task Force）で規定されたＲＦＣ（Request For Comment）３８５６に準拠した方式にて、プレゼンス情報を通信端末から管理装置へと伝送すると好ましい。
【００２５】
このＲＦＣ３８５６で規定されたプロトコルは、ＳＩＭＰＬＥ（SIP for Instant Messaging and Leveraging Extensions）と呼ばれるものである。このＳＩＭＰＬＥは、ＶｏＩＰ（Voice Over IP）技術に用いられるＳＩＰ（Session Initiation Protocol）と呼ばれるプロトコル（＝ＲＦＣ３２６１で規定されたプロトコル）の拡張機能として規定されたもので、端末のプレゼンス情報をサーバへ提供可能なプロトコルである。
【００２６】
このＳＩＭＰＬＥでは、ＳＩＰに規定されるＲＥＧＩＳＴＥＲメソッドによってＤｉｇｅｓｔ認証が行われている。また端末のプレゼンス情報は、ＳｕｂｓｃｒｉｂｅメソッドおよびＮｏｔｉｆｙメソッドによってプレゼンス要求・プレゼンス配信が可能となる。
【００２７】
したがって、このような規格に準拠した方式で、プレゼンス情報を通信端末から管理装置へと伝送すれば、新たに独自の規格を策定しなくても、所期のプレゼンス情報を通信端末から管理装置へと伝送することができる。
【００２８】
ただし、請求項２に記載の構成を採用することは本発明において必須の事項ではなく、例えば、公知のプロトコルの中には、プレゼンス情報を伝送可能なプロトコルもあるので（例えば、ＰＩＰ；Presence Information Protocol）、そのようなプロトコルを利用して本発明を構成してもよい。あるいは、公知のプロトコルを利用することなく、新たに独自の規格を策定してもよい。
【００２９】
また、本発明において、遠隔制御を実行する上で必要となる制御情報を管理装置から通信端末へ伝送するためのプロトコルについても、様々なものを利用し得るが、一例を挙げれば、請求項３に記載のように、管理装置および通信端末は、ＯＭＡ（Open Mobile Alliance）で規定されたＯＭＡ−ＤＭ（Open Mobile Alliance Device Management）に準拠した方式にて、制御情報を管理装置から通信端末へと伝送すると好ましい。
【００３０】
このＯＭＡ−ＤＭでは、様々なデバイス管理用のプロトコルが規定されており、例えば、ＬＡＷＭＯ（Lock And Wipe Management Object）、ＦＵＭＯ（Firmware Update Management Object）、ＳＣｏＭＯ（Software Component Management Object）、ＤｉａｇＭｏｎ（Diagnostics and Monitoring Management Object）といった規格が規定されている。
【００３１】
これらのうち、ＬＡＷＭＯを利用すれば、遠隔操作によって端末の有する機能をロックすることが可能となる。また、ＦＵＭＯを利用すれば、ファームウェア更新が可能となり、ＳＣｏＭＯを利用すれば、ソフトウェア更新が可能となる。さらに、ＤｉａｇＭｏｎを利用すれば、端末のソフトウェアやハードウェアの障害を診断することが可能となる。
【００３２】
したがって、このような規格に準拠した方式で、制御情報を管理装置から通信端末へと伝送すれば、新たに独自の規格を策定しなくても、所期の制御情報を通信端末から管理装置へと伝送することができる。
【００３３】
ただし、請求項３に記載の構成を採用することは本発明において必須の事項ではなく、例えば、公知のプロトコルを利用することなく、新たに独自の規格を策定し、その独自規格に準拠した方式で、制御情報を管理装置から通信端末へと伝送してもよい。
【００３４】
なお、上述の通り、ＤｉａｇＭｏｎを利用すれば、端末のソフトウェアやハードウェアの障害を診断することが可能となるので、例えば、請求項４に記載したようなシステムを構成でき、通信端末が、制御情報に応じた処理として、車載デバイスに関するデバイス情報（例えば、障害情報、診断情報、その他の動作ログなど）を車載デバイスから取得して、そのデバイス情報を管理装置へと伝送する処理を実行する、といったシステムを実現できる。
【００３５】
この場合、請求項５に記載の如く、車両に複数の前記車載デバイスが搭載されていれば、通信端末は、制御情報に応じた処理として、複数の車載デバイスそれぞれに関するデバイス情報を複数の車載デバイスそれぞれから取得して、それらのデバイス情報を一括して管理装置へと伝送する処理を実行すると、通信回数を減らすことができる点で好ましく、また、管理装置が複数のデバイス情報に基づいて車両の状態を判断できるので、より的確で詳細な判断ができるようになる点でも好ましい。
【００３６】
ただし、請求項４または請求項５に記載の発明において、ＤｉａｇＭｏｎを利用することは必須の事項ではなく、例えば、公知のプロトコルを利用することなく、新たに独自の規格を策定し、その独自規格に準拠した方式で、デバイス情報を管理装置から通信端末へと伝送してもよい。
【００３７】
また、ＬＡＷＭＯを利用すれば、遠隔操作によって端末の有する機能をロックすることが可能となるので、例えば、請求項６に記載したようなシステムを構成でき、通信端末が、制御情報に応じた処理として、車載デバイスを停止させる処理を実行する、といったシステムを実現できる。
【００３８】
ただし、請求項６に記載の発明において、ＬＡＷＭＯを利用することは必須の事項ではなく、例えば、公知のプロトコルを利用することなく、新たに独自の規格を策定し、その独自規格に準拠した方式で、車載デバイスを停止させる制御を実現してもよい。
【００３９】
さらに、ＦＵＭＯを利用すれば、ファームウェア更新が可能となり、ＳＣｏＭＯを利用すれば、ソフトウェア更新が可能となるので、例えば、請求項７に記載したようなシステムを構成でき、通信端末が、制御情報に応じた処理として、車載デバイスのファームウェアまたはソフトウェアを更新する処理を実行する、といったシステムを実現できる。
【００４０】
ただし、請求項７に記載の発明において、ＦＵＭＯを利用することは必須の事項ではなく、例えば、公知のプロトコルを利用することなく、新たに独自の規格を策定し、その独自規格に準拠した方式で、車載デバイスを停止させる制御を実現してもよい。
【図面の簡単な説明】
【００４１】
【図１】車載デバイス管理システムの構成を示すブロック図。
【図２】通信端末の構成を示すブロック図。
【図３】サーバの構成を示すブロック図。
【図４】システム内で実行される処理の遷移を示すシーケンス図。
【図５】認証情報作成処理のフローチャート。
【図６】認証処理のフローチャート。
【図７】レスポンス処理のフローチャート（その１）。
【図８】レスポンス処理のフローチャート（その２）。
【図９】状態チェック処理のフローチャート。
【図１０】プレゼンス更新処理のフローチャート。
【図１１】プレゼンス登録処理のフローチャート（その１）。
【図１２】プレゼンス登録処理のフローチャート（その２）。
【図１３】端末側自己診断処理のフローチャート。
【図１４】端末側異常発生時処理のフローチャート。
【図１５】（ａ）はサーバ側端末状態診断処理のフローチャート、（ｂ）はサーバ側異常発生時処理のフローチャート。
【発明を実施するための形態】
【００４２】
次に、本発明の実施形態について一例を挙げて説明する。
［車載デバイス管理システムの構成］
図１は、車載デバイス管理システムの構成を示すブロック図である。
【００４３】
この車載デバイス管理システムは、１または２以上の車両（図１には、車両１Ａ，１Ｂを例示。）、通信機２、通信ネットワーク３、およびサーバ４（本発明でいう管理装置に相当。）によって構成される。
【００４４】
車両１Ａには、通信端末１０、およびＥＣＵ群（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３；本発明でいう車載デバイスに相当。）が搭載され、これらが車載ネットワーク１４を介して通信可能に構成されている。
【００４５】
通信端末１０は、アンテナ、ＣＡＮ、ＧＰＳ、および他の通信インターフェースを介して様々なデバイスと通信可能な統合通信端末で、別の車両１Ｂとは無線通信路を介して車車間通信を実行可能、通信機２とは無線通信路を介して路車間通信を実行可能となっている。通信機２は通信ネットワーク３に接続されており、これにより、通信端末１０は、通信機２および通信ネットワーク３を介して、車両１Ａ，１Ｂとは別の場所に設けられたサーバ４と通信可能となっている。なお、車両１Ｂには、車両１Ａと同等な通信端末１０およびＥＣＵ群（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３）が搭載されている。
【００４６】
［通信端末の構成］
図２は、通信端末１０の構成を示すブロック図である。
通信端末１０は、ＥＣＵ群（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３）との通信を実行可能な車内ネットワーク接続デバイス１０１と、通信機２との通信を実行可能な車外ネットワーク接続デバイス１０３と、これら車内ネットワーク接続デバイス１０１および車外ネットワーク接続デバイス１０３を制御する通信ドライバ１０５とを備えている。
【００４７】
また、通信端末１０は、車外ネットワーク接続デバイス１０３経由で車外へ送信するデータの暗号化処理、および車外ネットワーク接続デバイス１０３経由で車外から受信したデータの復号処理を実行する暗号・復号処理部１１１を備え、公開鍵データベース１１３に登録された公開鍵と、秘密鍵データベース１１５に登録された秘密鍵を利用して、公開鍵暗号方式により、暗号化通信を実行可能となっている。
【００４８】
また、通信端末１０は、ＳＩＰスタック１２１、ＳＩＰ処理部１２３、および認証情報データベース１２５などを備え、ＩＥＴＦのＲＦＣ３２６１で規定されたＳＩＰに準拠した方式で通信を実行し、ＩＥＴＦのＲＦＣ３８５６で規定されたＳＩＭＰＬＥに準拠した方式にて、プレゼンス情報を通信端末１０からサーバ４へ伝送可能に構成されている。
【００４９】
また、通信端末１０は、ＯＭＡスタック１３１、ＯＭＡ処理部１３３、ＬＡＷＭＯ処理部１３５、ＦＵＭＯ処理部１３６、ＳＣｏＭＯ処理部１３７、およびＤｉａｇＭｏｎ処理部１３８などを備え、ＯＭＡ−ＤＭに準拠した方式にて、サーバ４から伝送されてくる制御情報に対応する処理を実行可能に構成されている。
【００５０】
さらに、通信端末１０は、ＥＣＵ群（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３）との通信を行って、各ＥＣＵの状態をチェックする状態チェック処理部１４１や、その他の処理を実行する「その他のアプリケーション群１４３」などを備えている。
【００５１】
［サーバの構成］
図３は、サーバ４の構成を示すブロック図である。
サーバ４は、通信ネットワーク３経由での通信を制御する通信ドライバ４０５を備えている。また、サーバ４は、通信端末１０へ送信するデータの暗号化処理、および通信端末１０から受信したデータの復号処理を実行する暗号・復号処理部４１１を備え、公開鍵データベース４１３に登録された公開鍵と、秘密鍵データベース４１５に登録された秘密鍵を利用して、公開鍵暗号方式により、暗号化通信を実行可能となっている。
【００５２】
また、サーバ４は、ＳＩＰスタック４２１、ＳＩＰ処理部４２３、および認証情報データベース４２５などを備え、ＲＦＣ３２６１で規定されたＳＩＰに準拠した方式で通信を実行し、ＲＦＣ３８５６で規定されたＳＩＭＰＬＥに準拠した方式にて、通信端末１０から伝送されてくるプレゼンス情報を取得可能に構成されている。
【００５３】
また、サーバ４は、ＯＭＡスタック４３１、ＯＭＡ処理部４３３、ＬＡＷＭＯ処理部４３５、ＦＵＭＯ処理部４３６、ＳＣｏＭＯ処理部４３７、およびＤｉａｇＭｏｎ処理部４３８などを備え、ＯＭＡ−ＤＭ（Open Mobile Alliance Device Management）に準拠した方式にて、ＥＣＵ群（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３）に対する各種制御を通信端末１０に対して指令するための制御情報を、通信端末１０に対して伝送可能に構成されている。
【００５４】
［車載デバイス管理システムの動作の概要と各装置が実行する処理］
次に、車載デバイス管理システムの動作の概要と各装置が実行する処理について説明する。図４は、システム内で実行される処理の遷移を示すシーケンス図である。
【００５５】
通信端末１０とサーバ４が通信を開始する場合、図４に示すように、通信端末１０は、まず、認証情報作成処理Ｆ１を実行する。図５は、この認証情報作成処理Ｆ１のフローチャートである。
【００５６】
認証情報作成処理Ｆ１を開始すると、通信端末１０は、認証情報データベース１２５から認証情報を取得する（Ｓ１０１）。この認証情報としては、車両に対して割り当てられた車両ＩＤと、車両毎に発行・管理されるパスワードとで構成されたデータが用いられる。
【００５７】
続いて、通信端末１０は、公開鍵データベース１１３から自端末公開鍵を取得する（Ｓ１０３）。そして、認証方法および公開鍵を含むＲＥＧＩＳＴＥＲメソッドを作成して（Ｓ１０５）、ＳＩＰメッセージを送信し（Ｓ１０７）、認証情報作成処理Ｆ１を終了する。
【００５８】
以上のような認証情報作成処理Ｆ１によって作成された認証情報は、図４に示すように、通信ドライバ１０５にハンドルされ（Ｓ０１）、通信ドライバ１０５は、車外ネットワーク接続デバイス１０３を介してサーバ４にＳＩＰメソッドとして送信される（Ｓ０２）。本実施形態においては、この通信端末１０からサーバ４への通信を契機として、双方間での通信が開始される。
【００５９】
このような認証情報をサーバ４が受信すると、サーバ４では、プレゼンス登録処理Ｆ６が実行される（Ｓ０３）。図１１は、プレゼンス登録処理Ｆ６のフローチャート（その１）、図１２は、プレゼンス登録処理Ｆ６のフローチャート（その２）である。
【００６０】
プレゼンス登録処理Ｆ６を開始すると、サーバ４は、ＳＩＰメソッドを受信し（Ｓ６０１）、暗号化されたデータを含むか否かを判断する（Ｓ６０３）。この段階では、まだデータの暗号化が行われていないので、Ｓ６０３では、暗号化されたデータを含まないとの判断がなされ（Ｓ６０３：ＮＯ）、サーバ４は、データをＳＩＰスタック４２１へハンドルし（Ｓ６０５）、認証処理Ｆ２へと進む。
【００６１】
図６は、認証処理Ｆ２のフローチャートである。認証処理Ｆ２を開始すると、サーバ４は、ＲＥＧＩＳＴＥＲメソッドを受信し（Ｓ２０１）、認証情報データベース４２５から認証情報を取得する（Ｓ２０３）。そして、認証情報の照合処理を実行して（Ｓ２０５）、認証結果がＯＫかＮＧか（すなわち、正規の通信相手か不正な通信相手か）を判断する（Ｓ２０７）。
【００６２】
Ｓ２０７で、認証結果がＯＫの場合（Ｓ２０７：認証結果ＯＫ）、サーバ４は、公開鍵データベース１１３に端末側公開鍵を登録し（Ｓ２０９）、公開鍵データベース１１３からサーバ側公開鍵を取得する（Ｓ２１１）。そして、サーバ側公開鍵を含むＳＩＰレスポンスを作成して（Ｓ２１３）、そのＳＩＰレスポンスを送信し（Ｓ２１５）、認証処理Ｆ２を終了する。
【００６３】
一方、Ｓ２０７において、認証結果がＮＧの場合（Ｓ２０７：認証結果ＮＧ）、サーバ４は、サーバ側公開鍵を含まないエラー応答用のＳＩＰレスポンスを作成して（Ｓ２１７）、そのＳＩＰレスポンスを送信し（Ｓ２１９）、認証処理Ｆ２を終了する。
【００６４】
こうして認証処理Ｆ２を終了すると、図４に示すように、認証処理Ｆ２によって作成されたＳＩＰレスポンスが出力されると（Ｓ０４）、そのＳＩＰレスポンスは通信端末１０に送信される（Ｓ０５）。
【００６５】
通信端末１０がＳＩＰレスポンスを受信すると、通信端末１０では、通信ドライバ１０５、ＳＩＰスタック１２１、ＳＩＰ処理部１２３、暗号・復号処理部１１１、ＯＭＡスタック１３１、ＯＭＡ処理部１３３、ＬＡＷＭＯ処理部１３５、ＦＵＭＯ処理部１３６、ＳＣｏＭＯ処理部１３７、ＤｉａｇＭｏｎ処理部１３８などが機能し、レスポンス処理Ｆ３が実行される（Ｓ０６）。
【００６６】
図７は、レスポンス処理Ｆ３のフローチャート（その１）、図８は、レスポンス処理Ｆ３のフローチャート（その２）である。
レスポンス処理Ｆ３を開始すると、通信端末１０は、まず、サーバ４から送信されてくるＳＩＰレスポンスを受信し（Ｓ３０１）、ＳＩＰレスポンス待ちのタイマーを初期化し（Ｓ３０３）、暗号化されたデータを含むか否かを判断する（Ｓ３０５）。
【００６７】
この段階では、まだデータの暗号化が行われていないので、Ｓ３０５では、暗号化されたデータを含まないとの判断がなされ（Ｓ３０５：ＮＯ）、通信端末１０は、データをＳＩＰスタック１２１へハンドルする（Ｓ３０７）。これにより、ＳＩＰスタック１２１でのデータ処理が行われて、ＳＩＰレスポンス内に組み込まれたデータが抽出されるので、通信端末１０は、サーバ側公開鍵が含まれているか否かを判断する（Ｓ３０９）。
【００６８】
ここでサーバ側公開鍵が含まれていなければ（Ｓ３０９：ＮＯ）、何らかの事情により、サーバ４との間で認証が成立しなかったことを意味するので、この場合は、認証情報作成処理Ｆ１を再試行する。
【００６９】
一方、Ｓ３０９において、サーバ側公開鍵が含まれていれば（Ｓ３０９：ＹＥＳ）、サーバ４との間で認証が成立したことを意味するので、この場合は、公開鍵データベース１１３にサーバ側公開鍵を登録する（Ｓ３１１）。そして、ＳＩＰ処理部１２３へデータをハンドルすることにより（Ｓ３１３）、ＳＩＰ処理部１２３でデータ処理を行って、状態チェック処理Ｆ４へと進む。なお、以上説明した処理を実行した結果、通信端末１０とサーバ４は互いの公開鍵を双方共有した状態となる。そのため、以降の通信はデータが暗号化されたセキュアな通信が可能となる。
【００７０】
図９は、状態チェック処理Ｆ４のフローチャートである。状態チェック処理Ｆ４を開始すると、通信端末１０は、状態チェック実施時間か否かを判断する（Ｓ４０１）。この状態チェック実施時間は、あらかじめ設定された時間であり、Ｓ４０１において、状態チェック実施時間に至っていない場合（Ｓ４０１：ＮＯ）、Ｓ４０１へと戻ることにより、そのまま待機する。一方、Ｓ４０１において、状態チェック実施時間に至った場合は（Ｓ４０１：ＹＥＳ）、各ＥＣＵ（制御系ＥＣＵ１１、情報系ＥＣＵ１２、および操作系ＥＣＵ１３などのＥＣＵ群）に状態チェック要求を送信する（Ｓ４０３）。
【００７１】
続いて、通信端末１０は、各ＥＣＵから送信されてくる状態チェック要求結果を受信済みか否かを判断し（Ｓ４０５）、受信済みでない場合は（Ｓ４０５：ＮＯ）、Ｓ４０５へと戻ることにより、各ＥＣＵから状態チェック要求結果が送信されてくるまで待機する。
【００７２】
そして、各ＥＣＵから送信されてくる状態チェック要求結果の受信を完了したら（Ｓ４０５：ＹＥＳ）、通信端末１０は、状態チェック要求結果の分析処理を実行する（Ｓ４０７）。
【００７３】
Ｓ４０７による分析を終えたら、通信端末１０は、デバイスを止める必要があるか否かを判断する（Ｓ４０９）。ここで、デバイスを止める必要があると判断された場合は（Ｓ４０９：ＹＥＳ）、ＬＡＷＭＯ処理部１３５へデータをハンドルすることにより（Ｓ４１１）、ＬＡＷＭＯ処理部１３５でのデータ処理を行って、プレゼンス更新処理Ｆ５へと進む。
【００７４】
一方、Ｓ４０９において、デバイスを止める必要がないと判断された場合（Ｓ４０９：ＮＯ）、通信端末１０は、ファームウェア更新の必要があるか否かを判断する（Ｓ４１３）。ここで、ファームウェア更新の必要があると判断された場合は（Ｓ４１３：ＹＥＳ）、ＦＵＭＯ処理部１３６へデータをハンドルすることにより（Ｓ４１５）、ＦＵＭＯ処理部１３６でのデータ処理を行って、プレゼンス更新処理Ｆ５へと進む。
【００７５】
一方、Ｓ４１１において、ファームウェア更新の必要がないと判断された場合（Ｓ４１３：ＮＯ）、通信端末１０は、ソフトウェア更新の必要があるか否かを判断する（Ｓ４１７）。ここで、ソフトウェア更新の必要があると判断された場合は（Ｓ４１７：ＹＥＳ）、ＳＣｏＭＯ処理部１３７へデータをハンドルすることにより（Ｓ４１９）、ＳＣｏＭＯ処理部１３７でのデータ処理を行って、プレゼンス更新処理Ｆ５へと進む。
【００７６】
一方、Ｓ４１７において、ソフトウェア更新の必要がないと判断された場合（Ｓ４１７：ＮＯ）、通信端末１０は、デバイス動作ログアップデートの必要があるか否かを判断する（Ｓ４２１）。ここで、デバイス動作ログアップデートの必要があると判断された場合は（Ｓ４２１：ＹＥＳ）、ＤｉａｇＭｏｎ処理部１３８へデータをハンドルすることにより（Ｓ４２３）、ＤｉａｇＭｏｎ処理部１３８でのデータ処理を行って、プレゼンス更新処理Ｆ５へと進む。なお、Ｓ４２１において、デバイス動作ログアップデートの必要がないと判断された場合は（Ｓ４２１：ＮＯ）、Ｓ４３２を実行しないままプレゼンス更新処理Ｆ５へと進む。
【００７７】
以上説明した状態チェック処理Ｆ４により、図４に示すように、各ＥＣＵに対して通信端末１０から情報提供が要求され（Ｓ０７）、その結果、各ＥＣＵの状態情報、ログ情報、ソフトウェア情報、ファームウェア情報、あるいはハードウェア情報など（これらの情報が、本発明でいうデバイス情報に相当。）が、車内ネットワーク接続デバイス１０１経由でプレゼンス情報として収集されることになる（Ｓ０８）。また、このとき、ＥＣＵ以外の各種センサ等からプレゼンス情報が収集されてもよい。
【００７８】
収集されるプレゼンス情報には、エンジンの状態（作動、停止、あるいは何らかの異常等）、ブレーキの状態、各種ランプ類（前照灯、ブレーキ灯、方向指示灯など）の状態、各種情報機器（カーナビゲーションシステム、オーディオ機器、車載モニタ類）の状態など、車両において状態が変化し得る様々な機器の状態情報が含まれ得る。
【００７９】
また、これら複数の車載デバイスから収集された情報は、一括して通信端末１０からサーバ４へと送信される。このような一括送信を行うと、これら複数の情報を個別に送信する場合に比べ、通信回数を減らすことができる点で好ましく、また、サーバ４が複数の情報に基づいて車両の状態を判断できるので、より的確で詳細な判断ができるようになる点でも好ましい。
【００８０】
例えば、単にファームウェアのバージョン情報だけを単独で送信した場合、ファームウェアの更新が必要か否かは判断できても、直ちに更新を開始しても構わないかどうかは判断ができない。これに対し、ファームウェアのバージョン情報とともに、エンジンが停止中であることや、サイドブレーキがかかっていること、変速機がＰレンジにあることなど、複数の情報が提供されれば、これらの情報から総合的に車両が走行中ではないことを判断できる。したがって、この時点でファームウェアの更新を開始しても問題がないことを把握でき、安全性も考慮した適切なタイミングでファームウェアの更新を実施することができる。
【００８１】
さて、異常のような様々な情報を一括してプレゼンス情報として、サーバ４に対して提供するため、通信端末１０においては、ＯＭＡ処理部１３３、ＯＭＡスタック１３１、ＳＩＰ処理部１２３、ＳＩＰスタック１２１、暗号・復号処理部１１１などが機能して、プレゼンス更新処理Ｆ５が実行される。図１０は、プレゼンス更新処理Ｆ５のフローチャートである。
【００８２】
プレゼンス更新処理Ｆ５を開始すると、通信端末１０は、ＯＭＡメッセージを含むプレゼンス発行要求か否かを判断する（Ｓ５０１）。このＳ５０１では、状態チェック処理Ｆ４においてＳ４１１，Ｓ４１５，Ｓ４１９，またはＳ４２３のいずれかが実行されていた場合に、ＯＭＡメッセージを含むプレゼンス発行要求であると判断される。
【００８３】
Ｓ５０１において、ＯＭＡメッセージを含むプレゼンス発行要求であると判断された場合（Ｓ５０１：ＹＥＳ）、通信端末１０は、ＯＭＡ処理部１３３へプレゼンスデータをハンドルし（Ｓ５０３）、ＯＭＡメッセージを作成し（Ｓ５０５）、作成されたＯＭＡメッセージをＯＭＡスタック１３１へハンドルする（Ｓ５０７）。そして、ＯＭＡメッセージをＳＩＰスタック１２１へハンドルし（Ｓ５０９）、ＳＩＰメッセージのボディ部にＯＭＡメッセージを組み込む。
【００８４】
続いて、通信端末１０は、公開鍵データベース１１３から端末側公開鍵を取得して（Ｓ５１１）、ＳＩＰメッセージの一部またはすべてを暗号化し（Ｓ５１３）、その暗号化されたＳＩＰメッセージを送信し（Ｓ５１５）、プレゼンス更新処理Ｆ５を終了する。
【００８５】
一方、Ｓ５０１において、ＯＭＡメッセージを含むプレゼンス発行要求ではないと判断された場合（Ｓ５０１：ＮＯ）、通信端末１０は、ＳＩＰ処理部１２３へプレゼンスデータをハンドルし（Ｓ５１７）、ＳＩＰメッセージを作成して（Ｓ５１９）、作成されたＳＩＰメッセージをＳＩＰスタック１２１へハンドルする（Ｓ５２１）。
【００８６】
続いて、通信端末１０は、公開鍵データベース１１３から端末側公開鍵を取得し（Ｓ５２３）、ＳＩＰメッセージの一部またはすべてを暗号化し（Ｓ５２５）、その暗号化されたＳＩＰメッセージを送信して（Ｓ５２７）、プレゼンス更新処理Ｆ５を終了する。
【００８７】
以上のようなプレゼンス更新処理Ｆ５が実行される結果、図４に示すように、通信端末１０内では、ＳＩＰメッセージが通信ドライバ１０５へハンドルされ（Ｓ０９）、ハンドルされたデータは、通信端末１０の通信ドライバ１０５を経由してサーバ４にＳＩＰメソッドとして送信される（Ｓ１０）。
【００８８】
このデータを受信したサーバ４内では、受信したデータがサーバ４の通信ドライバ４０５を経由してプレゼンス登録処理Ｆ６へハンドルされる（Ｓ１１）。プレゼンス登録処理Ｆ６は、既に一部を説明した図１１および図１２に示す処理となる。
【００８９】
このプレゼンス登録処理Ｆ６を開始すると、サーバ４は、ＳＩＰメソッドを受信し（Ｓ６０１）、暗号化されたデータを含むか否かを判断する（Ｓ６０３）。この段階では、データの暗号化が行われているので、既に説明したケースとは異なり、Ｓ６０３では、暗号化されたデータを含むとの判断がなされる（Ｓ６０３：ＹＥＳ）。
【００９０】
そこで、サーバ４は、秘密鍵データベース４１５から秘密鍵を取得し（Ｓ６０７）、その秘密鍵を用いて、暗号化された情報の復号処理を実行し（Ｓ６０９）、復号したデータをＳＩＰスタック４２１へハンドルする（Ｓ６１１）。
【００９１】
続いて、サーバ４は、ＯＭＡプロトコルが含まれているか否かを判断する（Ｓ６１３）。ここで、ＯＭＡプロトコルが含まれていない場合とは、先に説明した状態チェック処理Ｆ４においてＳ４１１，Ｓ４１５，Ｓ４１９，およびＳ４２３のいずれもが実行されていない場合に該当する。この場合は、ＯＭＡプロトコルを利用したデバイス管理を行う必要がないプレゼンス情報（例えば、イグニッションＯＮ／ＯＦＦ、各種車載機器のＯＮ／ＯＦＦなど）がサーバ４に伝送されてくる。
【００９２】
そこで、Ｓ６１３において、ＯＭＡプロトコルが含まれていないと判断された場合（Ｓ６１３：ＮＯ）、サーバ４は、ＳＩＰ処理部４２３へデータをハンドルし（Ｓ６１５）、ＳＩＰ処理部４２３でデータを解析して（Ｓ６１７）、端末状態管理データベース４２７にプレゼンスを登録する（Ｓ６１９）。そして、ＳＩＰレスポンスを作成して（Ｓ６２１）、ＳＩＰレスポンスを送信し（Ｓ６２３）、プレゼンス登録処理Ｆ６を終了する。
【００９３】
一方、Ｓ６１３において、ＯＭＡプロトコルが含まれていると判断された場合（Ｓ６１３：ＹＥＳ）、図１２に示す処理へと進み、サーバ４は、ＬＡＷＭＯメッセージか否かを判断する（Ｓ６５１）。Ｓ６５１において、ＬＡＷＭＯメッセージであると判断された場合（Ｓ６５１：ＹＥＳ）、サーバ４は、ＬＡＷＭＯ処理部４３５へデータをハンドルし（Ｓ６５３）、プレゼンス登録処理Ｆ６を終了する。その結果、対象となるデバイスを停止させる際に必要な処理がＬＡＷＭＯ処理部４３５において実行される。
【００９４】
また、Ｓ６５１において、ＬＡＷＭＯメッセージではないと判断された場合（Ｓ６５１：ＮＯ）、サーバ４は、ＦＵＭＯメッセージか否かを判断する（Ｓ６５５）。Ｓ６５５において、ＦＵＭＯメッセージであると判断された場合（Ｓ６５５：ＹＥＳ）、サーバ４は、ＦＵＭＯ処理部４３６へデータをハンドルし（Ｓ６５７）、プレゼンス登録処理Ｆ６を終了する。その結果、対象となるデバイスのファームウェアを更新する際に必要な処理がＦＵＭＯ処理部４３６において実行される。
【００９５】
また、Ｓ６５５において、ＦＵＭＯメッセージではないと判断された場合（Ｓ６５５：ＮＯ）、サーバ４は、ＳＣｏＭＯメッセージか否かを判断する（Ｓ６５９）。Ｓ６５９において、ＳＣｏＭＯメッセージであると判断された場合（Ｓ６５９：ＹＥＳ）、サーバ４は、ＳＣｏＭＯ処理部４３７へデータをハンドルし（Ｓ６６１）、プレゼンス登録処理Ｆ６を終了する。その結果、対象となるデバイスのソフトウェアを更新する際に必要な処理がＳＣｏＭＯ処理部４３７において実行される。
【００９６】
また、Ｓ６５９において、ＳＣｏＭＯメッセージではないと判断された場合（Ｓ６５９：ＮＯ）、サーバ４は、ＤｉａｇＭｏｎメッセージか否かを判断する（Ｓ６６３）。Ｓ６６３において、ＤｉａｇＭｏｎメッセージであると判断された場合（Ｓ６６３：ＹＥＳ）、サーバ４は、ＤｉａｇＭｏｎ処理部４３８へデータをハンドルし（Ｓ６６５）、プレゼンス登録処理Ｆ６を終了する。その結果、対象となるデバイスのログを収集する際に必要な処理がＤｉａｇＭｏｎ処理部４３８において実行される。
【００９７】
なお、Ｓ６６３において、ＤｉａｇＭｏｎメッセージではないと判断された場合（Ｓ６６３：ＮＯ）、本実施形態においては、サーバ４がサポートしていないＯＭＡメッセージであると見なし、サーバ４は、ＯＭＡメッセージを破棄する処理を実行する（Ｓ６６７）。そして、ＳＩＰレスポンスを作成して（Ｓ６６９）、ＳＩＰレスポンスを送信し（Ｓ６７１）、プレゼンス登録処理Ｆ６を終了する。
【００９８】
以上説明したプレゼンス登録処理Ｆ６を経て受信したプレゼンス情報については、サーバ４の暗号・復号処理部４１１、ＳＩＰスタック４２１、ＳＩＰ処理部４２３、ＯＭＡスタック４３１、ＯＭＡ処理部４３３、ＬＡＷＭＯ処理部４３５、ＦＵＭＯ処理部４３６、ＳＣｏＭＯ処理部４３７、ＤｉａｇＭｏｎ処理部４３８にて分析され、必要に応じたレスポンスが作成されることになる。
【００９９】
そして、その出力結果は、図４に示すように、サーバ４の通信ドライバ４０５に出力され（Ｓ１２）、サーバ４は、出力された結果をサーバ４の通信ドライバ４０５を使ってＳＩＰレスポンスとして通信端末１０へと送信する（Ｓ１３）。
【０１００】
通信端末１０において、受信したＳＩＰレスポンスは、通信端末１０の通信ドライバ１０５によってレスポンス処理Ｆ３へとハンドルされ（Ｓ１４）、通信端末１０ではＳＩＰレスポンスに基づいた処理が行われることになる。
【０１０１】
レスポンス処理Ｆ３は、既に一部を説明した図７および図８に示す処理となる。レスポンス処理Ｆ３を開始すると、通信端末１０は、まず、サーバ４から送信されてくるＳＩＰレスポンスを受信し（Ｓ３０１）、ＳＩＰレスポンス待ちのタイマーを初期化し（Ｓ３０３）、暗号化されたデータを含むか否かを判断する（Ｓ３０５）。この段階では、データの暗号化が行われているので、既に説明したケースとは異なり、Ｓ３０５では、暗号化されたデータを含むとの判断がなされる（Ｓ３０５：ＹＥＳ）。
【０１０２】
そこで、通信端末１０は、秘密鍵データベース１１５から秘密鍵を取得し（Ｓ３１５）、その秘密鍵を用いて、暗号化された情報の復号処理を実行し（Ｓ３１７）、復号したデータをＳＩＰスタック１２１へハンドルする（Ｓ３１９）。
【０１０３】
続いて、通信端末１０は、ＯＭＡプロトコルが含まれているか否かを判断する（Ｓ３２１）。ここで、ＯＭＡプロトコルが含まれていない場合とは、先に説明したプレゼンス登録処理Ｆ６においてＳ６５３，Ｓ６５７，Ｓ６６１，およびＳ６６５のいずれもが実行されていない場合に該当する。
【０１０４】
Ｓ３２１において、ＯＭＡプロトコルが含まれていないと判断された場合（Ｓ３２１：ＮＯ）、通信端末１０は、ＳＩＰ処理部１２３へデータをハンドルし（Ｓ３２３）、ＳＩＰ処理部１２３でデータを解析する（Ｓ３２５）。そして、その他のアプリケーション群１４３に通知すべき情報か否かを判断し（Ｓ３２７）、通知すべき情報であれば（Ｓ３２７：ＹＥＳ）、その他のアプリケーション群１４３に情報を通知して（Ｓ３２９）、レスポンス処理Ｆ３を終了する。なお、Ｓ３２７において、その他のアプリケーション群１４３に通知すべき情報でなければ（Ｓ３２７：ＮＯ）、Ｓ３２９を実行することなく、レスポンス処理Ｆ３を終了する。
【０１０５】
一方、Ｓ３２１において、ＯＭＡプロトコルが含まれていると判断された場合は（Ｓ３２１：ＹＥＳ）、図８に示す処理へと進み、通信端末１０は、ＬＡＷＭＯメッセージか否かを判断する（Ｓ３５１）。Ｓ３５１において、ＬＡＷＭＯメッセージであると判断された場合（Ｓ３５１：ＹＥＳ）、通信端末１０は、ＬＡＷＭＯ処理部１３５へデータをハンドルし（Ｓ３５３）、レスポンス処理Ｆ３を終了する。その結果、対象となるデバイスを停止させる処理がＬＡＷＭＯ処理部１３５において実行される。
【０１０６】
また、Ｓ３５１において、ＬＡＷＭＯメッセージではないと判断された場合（Ｓ３５１：ＮＯ）、通信端末１０は、ＦＵＭＯメッセージか否かを判断する（Ｓ３５５）。Ｓ３５５において、ＦＵＭＯメッセージであると判断された場合（Ｓ３５５：ＹＥＳ）、通信端末１０は、ＦＵＭＯ処理部１３６へデータをハンドルし（Ｓ３５７）、レスポンス処理Ｆ３を終了する。その結果、対象となるデバイスのファームウェアを更新する処理がＦＵＭＯ処理部１３６において実行される。
【０１０７】
また、Ｓ３５５において、ＦＵＭＯメッセージではないと判断された場合（Ｓ３５５：ＮＯ）、通信端末１０は、ＳＣｏＭＯメッセージか否かを判断する（Ｓ３５９）。Ｓ３５９において、ＳＣｏＭＯメッセージであると判断された場合（Ｓ３５９：ＹＥＳ）、通信端末１０は、ＳＣｏＭＯ処理部１３７へデータをハンドルし（Ｓ３６１）、レスポンス処理Ｆ３を終了する。その結果、対象となるデバイスのソフトウェアを更新する処理がＳＣｏＭＯ処理部１３７において実行される。
【０１０８】
また、Ｓ３５９において、ＳＣｏＭＯメッセージではないと判断された場合（Ｓ３５９：ＮＯ）、通信端末１０は、ＤｉａｇＭｏｎメッセージか否かを判断する（Ｓ３６３）。Ｓ３６３において、ＤｉａｇＭｏｎメッセージであると判断された場合（Ｓ３６３：ＹＥＳ）、通信端末１０は、ＤｉａｇＭｏｎ処理部１３８へデータをハンドルし（Ｓ３６５）、レスポンス処理Ｆ３を終了する。その結果、対象となるデバイスのログをサーバ４に伝送する処理がＤｉａｇＭｏｎ処理部１３８において実行される。
【０１０９】
なお、Ｓ３６３において、ＤｉａｇＭｏｎメッセージではないと判断された場合（Ｓ３６３：ＮＯ）、本実施形態においては、通信端末１０がサポートしていないＯＭＡメッセージであると見なし、通信端末１０は、ＯＭＡメッセージを破棄する処理を実行し（Ｓ３６７）、レスポンス処理Ｆ３を終了する。
【０１１０】
さて、以上説明したような各種処理が、図４に示すような順序で実行される中、図４に示すＳ０６以降、通信端末１０側では、定期的または不定期に端末側自己診断処理Ｆ７が実行される。図１３は、端末側自己診断処理Ｆ７のフローチャートである。
【０１１１】
この端末側自己診断処理Ｆ７を開始すると、通信端末１０は、まず、認証情報期限満了か否かを判断する（Ｓ７０１）。Ｓ７０１での判定対象となる認証情報の有効期限は、認証情報作成処理Ｆ１において認証情報が作成された際に設定された期限である。この期限は、理論上は短い場合ほどセキュリティが高いといえるが、実用上は極端に短期にしなくても問題はなく、むしろ、ある程度は長期にする方が認証情報の更新頻度を抑えることができる。
【０１１２】
Ｓ７０１において、認証情報期限満了であれば（Ｓ７０１：ＹＥＳ）、通信端末１０は、異常原因を記録して（Ｓ７０３）、端末側異常発生時処理Ｆ８へと進む。一方、Ｓ７０１において、認証情報期限満了でなければ（Ｓ７０１：ＮＯ）、通信端末１０は、ＥＣＵの状態チェックでタイムアウトが発生したか否かを判断する（Ｓ７０５）。ここで、タイムアウトが発生していなければ（Ｓ７０５：ＮＯ）、再び端末側自己診断処理Ｆ７へと進む。
【０１１３】
一方、Ｓ７０５において、タイムアウトが発生していれば（Ｓ７０５：ＹＥＳ）、通信端末１０は、タイムアウト回数が規定回数を超えたか否かを判断する（Ｓ７０７）。規定回数は、より小さい値にするほどタイムアウトを問題視する頻度が高くなるので、異常の早期発見には寄与するが、過剰に小さくすると、単にＥＣＵがビジー状態で応答を返せなかっただけでも異常との判定がなされてしまう機会が増大するので、その点も考慮して最適な値が設定される。この点、ＥＣＵ毎に規定回数を変えることもできるので、例えば、複数のＥＣＵそれぞれの制御対象を考慮して、異常の早期発見が重要視されるＥＣＵについては規定回数を小さめの値とし、過敏な異常通知を避けたいＥＣＵについては規定回数を大きめの値にする、といった設定にしてもよい。
【０１１４】
Ｓ７０７において、タイムアウト回数が規定回数を超えていなければ（Ｓ７０７：ＮＯ）、通信端末１０は、タイムアウト回数を記録して（Ｓ７０９）、再び端末側自己診断処理Ｆ７へと進む。一方、Ｓ７０７において、タイムアウト回数が規定回数を超えていれば（Ｓ７０７：ＹＥＳ）、通信端末１０は、異常原因を記録して（Ｓ７０３）、端末側異常発生時処理Ｆ８へと進む。
【０１１５】
つまり、以上のような端末側自己診断処理Ｆ７により、異常が検出されない場合は、端末側自己診断処理Ｆ７が定期的または不定期に繰り返されることになり、一方、異常が検出された場合は、端末側異常発生時処理Ｆ８へと進むことになる。図１４は、端末側異常発生時処理Ｆ８のフローチャートである。
【０１１６】
端末側異常発生時処理Ｆ８を開始すると、通信端末１０は、Ｓ７０３で記録された異常原因を取得・分析して（Ｓ８０１）、デバイスを止める必要があるか否かを判断する（Ｓ８０３）。ここで、デバイスを止める必要があると判断された場合（Ｓ８０３：ＹＥＳ）、ＬＡＷＭＯ処理部１３５へデータをハンドルして（Ｓ８０５）、認証情報作成処理Ｆ１へと進む。Ｓ８０５を実行すると、デバイスを止める必要がある旨をサーバ４へ伝達するためのＯＭＡメッセージが作成され、そのメッセージが、以降の処理によりサーバ４へと伝達されることになる。
【０１１７】
一方、Ｓ８０３において、デバイスを止める必要がないと判断された場合（Ｓ８０３：ＮＯ）、ファームウェア更新の必要があるか否かを判断する（Ｓ８０７）。ここで、ファームウェア更新の必要があると判断された場合（Ｓ８０７：ＹＥＳ）、ＦＵＭＯ処理部１３６へデータをハンドルして（Ｓ８０９）、認証情報作成処理Ｆ１へと進む。Ｓ８０７を実行すると、ファームウェア更新の必要がある旨をサーバ４へ伝達するためのＯＭＡメッセージが作成され、そのメッセージが、以降の処理によりサーバ４へと伝達されることになる。
【０１１８】
一方、Ｓ８０７において、ファームウェア更新の必要がないと判断された場合（Ｓ８０７：ＮＯ）、ソフトウェア更新の必要があるか否かを判断する（Ｓ８１１）。ここで、ソフトウェア更新の必要があると判断された場合（Ｓ８１１：ＹＥＳ）、ＳＣｏＭＯ処理部１３７へデータをハンドルして（Ｓ８１３）、認証情報作成処理Ｆ１へと進む。Ｓ８１３を実行すると、ソフトウェア更新の必要がある旨をサーバ４へ伝達するためのＯＭＡメッセージが作成され、そのメッセージが、以降の処理によりサーバ４へと伝達されることになる。
【０１１９】
一方、Ｓ８１１において、ソフトウェア更新の必要がないと判断された場合（Ｓ８１１：ＮＯ）、ログをサーバ４に送信する必要があるか否かを判断する（Ｓ８１５）。ここで、ログをサーバ４に送信する必要があると判断された場合（Ｓ８１５：ＹＥＳ）、ＤｉａｇＭｏｎ処理部１３８へデータをハンドルして（Ｓ８１７）、認証情報作成処理Ｆ１へと進む。Ｓ８１７を実行すると、ログをサーバ４に送信する必要がある旨をサーバ４へ伝達するためのＯＭＡメッセージが作成され、そのメッセージが、以降の処理によりサーバ４へと伝達されることになる。なお、Ｓ８１５において、ログをサーバ４に送信する必要がないと判断された場合は（Ｓ８１５：ＮＯ）、Ｓ８１７を実行しないまま認証情報作成処理Ｆ１へと進む。
【０１２０】
さて一方、以上のような端末側自己診断処理Ｆ７や端末側異常発生時処理Ｆ８が実行されている際、サーバ４側においても、図４に示すＳ０６以降、定期的または不定期にサーバ側端末状態診断処理Ｆ９やサーバ側異常発生時処理Ｆ１０が実行される。
【０１２１】
図１５（ａ）はサーバ側端末状態診断処理Ｆ９のフローチャート、図１５（ｂ）はサーバ側異常発生時処理Ｆ１０のフローチャートである。
サーバ側端末状態診断処理Ｆ９を開始すると、サーバ４は、認証情報期限満了か否かを判断する（Ｓ９０１）。ここで、認証情報期限満了でなければ（Ｓ９０１：ＮＯ）、再びサーバ側端末状態診断処理Ｆ９へと進む。一方、Ｓ９０１において、認証情報期限満了であれば（Ｓ９０１：ＹＥＳ）、異常原因を記録して（Ｓ９０３）、サーバ側異常発生時処理Ｆ１０へと進む。
【０１２２】
サーバ側異常発生時処理Ｆ１０へと進んだ場合、サーバ４は、Ｓ９０３で記録された異常原因を取得・分析して（Ｓ１００１）、異常が発生した端末に関する情報のうち、動的に更新された項目について情報を削除し（Ｓ１００３）、サーバ側異常発生時処理Ｆ１０を終了する。
【０１２３】
Ｓ１００３では、後日あらためて車両側との通信が再開されたときに必要となる最小限の項目についてはデータが残され、それ以外のデータが削除される。このようにすることで、例えば、廃車その他の事情によって長期にわたって通信が行われていない車両について、不要なデータが削除されることになる。
【０１２４】
［車載デバイス管理システムの具体的な利用例（その１）］
次に、上記車載デバイス管理システムの具体的な利用例について説明する。
第１の事例として、法規で決められた機能を制御するＥＣＵと、それ以外のＥＣＵ、双方が搭載されている車両１Ａにおいて、法規で決められた機能に問題が生じた場合を想定して、車載デバイス管理システムの挙動について説明する。
【０１２５】
車両１Ａに搭載された各ＥＣＵは、異常時、ダイアグデータを出力するように構成されている。このとき、通信端末１０の車内ネットワーク接続デバイス１０１は、各ＥＣＵからのデータを受信し、受信されたデータに基づき、データの層別を行う。
【０１２６】
具体的には、ＥＣＵには、上述の通り、法規で決められた機能を制御するＥＣＵと、それ以外のＥＣＵとがあり、いずれのＥＣＵに該当するかは、ＥＣＵアドレスに含まれる層別データに基づいて判別可能となっている。したがって、ＥＣＵアドレスを参照してデータ処理を行えば、法規で決められた機能を制御するＥＣＵなのか否かを判別し、データを分類することができる。
【０１２７】
法規上必要なＥＣＵからダイアグデータが送られてきた場合、通信端末１０は、状態チェック処理部１４１によってデータの分析を行い、これにより、状況の緊急性が把握される。法規で決められた機能が作動しなくなったときの時刻、ＥＣＵが実施した自己診断データ、機能の制御推移ログデータなどがＥＣＵに記憶されていれば、状態チェック処理部１４１は、それらのデータをテンポラリの記憶手段に記憶する。そして、状態チェック処理部１４１の診断結果データを、サーバ４に送信するように通信ドライバ１０５に依頼する。
【０１２８】
通信ドライバ１０５は、緊急度が高いと判断すると、車外のサーバ４に診断結果データを優先的に送信するように、通信順を変更して、サーバ４への通信を行う。通信ドライバ１０５は、最初に状態チェック処理部１４１が作成した診断要約データを送る。サーバ４側で、より具体的なデータが必要な場合、通信ドライバ１０５が、テンポラリ記憶手段に記憶された必要なデータをサーバ４に送信する。
【０１２９】
各診断用のログデータには、タイムスタンプと識別子が設けられており、サーバ４側で時刻と識別子を指定することで、どの機能のどの部分がいつ、どのように変化したかを把握できるようになっている。
【０１３０】
このようにすると、車両１Ａとサーバ４側での通信データのやり取りが簡潔になり、データ量も小さくできるため、通信時間の短縮も図れ効率的である。また、ダイアグデータの取得において、車載ネットワーク１４を使う頻度が減るため、車載ネットワーク１４の安定した利用が可能になる。
【０１３１】
サーバ４は、通信端末１０から診断要約データを受け取り、その内容が正しいと判定すると、その診断内容に応じた処理を選択する。また、サーバ４は通信端末１０から、診断要約データを受け取ると、通信端末１０の搭載された車両状況を「車両ＩＤ：車両ユーザ」を参照して、遠隔チェックを行う。
【０１３２】
チェックの結果、問題が生じている機能の代わりに利用可能な代替手段が当該車両１Ａにある場合で、それがまだ使われていない場合に、車両１Ａのユーザに代替手段を使うように報知する。具体的には、手動で代替手段に切り替える必要がある場合、ユーザに代替手段への切り替えを指示するための情報を報知する。代替手段への切り替えを指示しても、それが使われていなかったときに、サーバ４側から再度案内を行ってもよい。また、サーバ４側からの遠隔制御で代替手段に切り替えることができる場合は、サーバ４側での判断で遠隔的に代替手段に切り替えるようにしてもよい。
【０１３３】
代替手段への切り替えを指示した際、ユーザがそれを実施できるにもかかわらず、代替手段への切り替えが実施されない場合は、さらにサーバ４から警告を出すようにしてもよい。そして、それでもユーザが処置を行わない場合は、車両１Ａの走行を制御するようにしてもよい。加えて、代替手段により安全走行ができるようになったら、ユーザに修理をどこで行えばよいかを案内（提案）するようにしてもよい。
【０１３４】
［車載デバイス管理システムの具体的な利用例（その２）］
第２の事例としては、車載機器の機能改良、機能追加、あるいは品質向上を図るためのファームウェアアップデートを、サーバ４により遠隔から実施する事例について説明する。
【０１３５】
昨今、様々なエンターテイメント用のメディア（音楽メディア・映像メディア等）が、車載機器で利用される機会が増えている。そのため、車両側においても、常に新しいメディアに対応可能なファームウェアを導入することが望ましい。しかし、従来、このようなファームウェアのアップデートを行うには、車両の所有者がディーラーに赴き、ファームウェアをアップデートしてもらうという作業が必要であった。この点、上記車載デバイス管理システムを利用すれば、きわめて簡単にファームウェアのアップデートを実施することができる。
【０１３６】
すなわち、上述の状態チェック処理Ｆ４によって得られる各ＥＣＵの情報のうち、ファームウェアバージョン情報をＳＩＰプレゼンス情報のひとつとしてサーバ４に提供する。
また、ファームウェアバージョン情報をＳＩＰプレゼンス情報としてサーバ４に提供する際には、他のＥＣＵの情報や車両の状態を示す情報をも併せて提供し、例えば、車両が走行中であるとか、あるいは、イグニッションがＯＦＦの状態である、といった情報もプレゼンス情報として提供される。
【０１３７】
こうした情報が提供されたら、サーバ４では、提供された情報を元にそのバージョンよりも新しいバージョンのファームウェアがあるかどうかを判断する。また、車両の状態がファームウェアのアップデートを実施可能な状態（＝対象となるＥＣＵを一時的に利用できなくなっても問題がない状態；例えば、イグニッションＯＦＦの状態）かどうかも判断し、これら複数のチェック項目に基づき、ファームウェアのアップデートを実施可能な環境が整っているかどうかを判断する。
【０１３８】
そして、ファームウェアのアップデートを実施可能な環境が整っていれば、サーバ４は、ＦＵＭＯ処理部４３６での処理により、新しいバージョンのファームウェアを通信端末１０側へと伝送し、それを通信端末１０がＥＣＵへと転送することにより、車両１ＡにおいてＥＣＵのファームウェアを更新することができる。
【０１３９】
［車載デバイス管理システムの具体的な利用例（その３）］
第３の事例としては、ＥＣＵ故障情報の詳細についての通知を、サーバ４により遠隔から実施する事例について説明する。
【０１４０】
具体的には、ＥＣＵ自身が有する自己診断機能で異常を検知した場合、従来は車両１Ａの表示系にアラームランプを点灯させるだけに留まっており、このような方式では、車両１Ａの所有者に対して警告を発することしかできなかった。
【０１４１】
そのため、車両の所有者には、何のＥＣＵがどのような異常を報知しているのか、わからないこともあり、最悪の場合、故障した車両の運転をすることについて、危険性があることを十分に考慮しないまま、故障車両を運転して自らディーラーに赴いてしまうこともあった。
【０１４２】
このような問題に対し、上記車載デバイス管理システムを利用すれば、きわめて簡単に故障箇所の診断を行い、利用者に対して的確な指示を出すことができる。すなわち、上記車載デバイス管理システムにおいては、各ＥＣＵが自己診断機能で異常を検知した場合、異常を検知したＥＣＵを示すＩＤとその異常を示すコードを出力するので、通信端末１０は、状態チェック処理Ｆ４によって各ＥＣＵから情報を取得し、その情報をＳＩＰプレゼンス情報としてサーバ４に送信する。
【０１４３】
サーバ４側では、受信した情報を分析して異常を示すＥＣＵのＩＤと異常コードを元に、最も適切だと思われる処理をデータベースから検索して、通信端末１０に対して処理の実行を指示することができる。また、車両１Ａの所有者に対して、どのＥＣＵがどういう異常を検出したのかを、カーナビゲーションシステムの画面等の車載表示器に表示させる命令を出すこともできる。
【０１４４】
したがって、例えば、ディーラーでの修理が必須であるような故障を検出した場合は、カーナビゲーションシステムの画面等の車載表示器上に故障したＥＣＵ種別、故障内容、その対策、リスクなどを表示させることが可能となる。
【０１４５】
よって、こうした情報を見た車両１Ａの所有者は、点灯したアラームランプの意味を正確に把握することができるので、危険な状態にある車を運転してディーラーまで持っていくべきかどうか、その判断を容易に下すことが可能となる。
【０１４６】
［車載デバイス管理システムの具体的な利用例（その４）］
第４の事例としては、カーナビゲーションシステムの車載機が有する地図情報の更新を、サーバ４により遠隔から実施する事例について説明する。
【０１４７】
カーナビゲーションシステムの車載機が有する地図情報は、数年単位で新しい地図データが出されているが、従来、最新の地図データをカーナビゲーションシステムの車載機に適用するには、車両１Ａの所有者はディーラーに赴き、これらの最新地図データを自車の機器に適用してもらう必要があった。
【０１４８】
これに対し、上記車載デバイス管理システムを利用すれば、状態チェック処理Ｆ４を通して得られる地図データの版数情報とカーナビゲーションシステムの車載機のＩＤを、サーバ４に対してＳＩＰプレゼンスとして送信できる。
【０１４９】
そのため、サーバ４側に最新の地図データがあるかどうかは、車両１Ａ側から得た版数情報を元に、サーバ４側で検索することができる。この判断の結果、適用できる最新の地図データがサーバ４側ある場合、ＳＣｏＭＯ処理部１３７を通して地図データ更新の指示を通信端末１０に対して発行することが可能となる。
【０１５０】
［効果］
以上説明した通り、上記車載デバイス管理システムによれば、サーバ４および通信端末１０は公開鍵暗号方式にて暗号化通信を実行し、しかも、通信端末１０からサーバ４へと伝送されるプレゼンス情報に基づいて、サーバ４が遠隔制御を実行するか否かを判断し、実行するとの判断がなされた場合に、サーバ４から通信端末１０へ各種制御情報が伝送される。
【０１５１】
したがって、単にパケット通信を行うだけの従来技術に比べ、よりセキュアな無線通信を実行することができ、しかも、プレゼンス情報に基づいて、サーバ４側でＥＣＵなどの車載デバイスまたは車両の状態を適切に把握した上で、それに応じた適切な遠隔制御を実行することができる。
【０１５２】
また、上記車載デバイス管理システムでは、異なるプロトコルであるＳＩＰ（ＳＩＭＰＬＥ）、ＯＭＡ−ＤＭ、および公開鍵暗号方式を組み合わせて採用しているので、これらが単独で動作しただけでは解決できない車車間通信における課題を解決し、プレゼンス情報によるタイムリーな状態管理、暗号化による「なりすまし、不正傍受」といった不正行為対策、ＯＭＡ−ＤＭによる車載デバイスの遠隔制御を実施することができる。
【０１５３】
さらに、ＯＭＡプロトコルに対応したサーバで管理可能な通信端末は、一般に、ＯＭＡプロトコルが実装されている通信端末に限定されているが、上記車載デバイス管理システムにおいては、通信端末１０にＯＭＡプロトコルが実装されているので、ＥＣＵなどの車載デバイスにＯＭＡプロトコルが実装されていなくても、通信端末１０経由で車載デバイスの停止制御、ソフトウェア・ファームウェアの更新、ログの収集などを実施でき、サーバ４によるセキュアで高度なデバイス管理が可能となる。
【０１５４】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１５５】
例えば、上記実施形態では、通信端末１０が認証情報作成処理Ｆ１を実行した後、通信端末１０からサーバ４への通信を契機として、双方間での通信が開始される例を示したが、クライアントとサーバの立場は必要に応じて逆転してもよく、例えば、サーバ４相当の管理装置がクライアントとなり、この管理装置から通信端末１０への通信を契機として、双方間での通信が開始される構成になっていてもよい。すなわち、本発明でいう管理装置と通信端末は、いずれか一方から他方への通信要求を契機として通信を開始するものであり、これらはどちらが通信要求を先に発行しても構わない。
【０１５６】
また、上記実施形態において、Ｓ４０１では、状態チェック実施時間が、複数のＥＣＵそれぞれについてあらかじめ設定されている旨を説明したが、これについては、例えば、状態変化を迅速に検知すべきＥＣＵについては、比較的短い時間が設定され、状態変化後にその変化を遅れて検出しても問題がないＥＣＵについては、比較的長い時間が設定されていてもよい。
【符号の説明】
【０１５７】
１Ａ，１Ｂ・・・車両、２・・・通信機、３・・・通信ネットワーク、４・・・サーバ、１０・・・通信端末、１１・・・制御系ＥＣＵ、１２・・・情報系ＥＣＵ、１３・・・操作系ＥＣＵ、１４・・・車載ネットワーク、１０１・・・車内ネットワーク接続デバイス、１０３・・・車外ネットワーク接続デバイス、１０５，４０５・・・通信ドライバ、１１１，４１１・・・暗号・復号処理部、１１３，４１３・・・公開鍵データベース、１１５，４１５・・・秘密鍵データベース、１２１，４２１・・・ＳＩＰスタック、１２３，４２３・・・ＳＩＰ処理部、１２５，４２５・・・認証情報データベース、１３１，４３１・・・ＯＭＡスタック、１３３，４３３・・・ＯＭＡ処理部、１３５，４３５・・・ＬＡＷＭＯ処理部、１３６，４３６・・・ＦＵＭＯ処理部、１３７，４３７・・・ＳＣｏＭＯ処理部、１３８，４３８・・・ＤｉａｇＭｏｎ処理部、１４１・・・状態チェック処理部、１４３・・・その他のアプリケーション群、４２７・・・端末状態管理データベース。
【図１】
2010273181.tif 000003
【図２】
2010273181.tif 000004
【図３】
2010273181.tif 000005
【図４】
2010273181.tif 000006
【図５】
2010273181.tif 000007
【図６】
2010273181.tif 000008
【図７】
2010273181.tif 000009
【図８】
2010273181.tif 000010
【図９】
2010273181.tif 000011
【図１０】
2010273181.tif 000012
【図１１】
2010273181.tif 000013
【図１２】
2010273181.tif 000014
【図１３】
2010273181.tif 000015
【図１４】
2010273181.tif 000016
【図１５】
2010273181.tif 000017