特開 2024-79599 車両ＯＴＡアップデートの効率性を向上させるためのＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法、及びこれを利用する装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024079599

(43)【公開日】2024-06-11

(54)【発明の名称】車両ＯＴＡアップデートの効率性を向上させるためのＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法、及びこれを利用する装置

(51)【国際特許分類】

   G06F 8/65 20180101AFI20240604BHJP

【ＦＩ】

G06F8/65

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

(21)【出願番号】P 2023188152

(22)【出願日】2023-11-02

(31)【優先権主張番号】10-2022-0164366

(32)【優先日】2022-11-30

(33)【優先権主張国・地域又は機関】KR

(71)【出願人】

【識別番号】505112037

【氏名又は名称】ペンタ・セキュリティ株式会社

(71)【出願人】

【識別番号】319016563

【氏名又は名称】アウトクリプト カンパニー リミテッド

(74)【代理人】

【識別番号】100121728

【弁理士】

【氏名又は名称】井関 勝守

(74)【代理人】

【識別番号】100165803

【弁理士】

【氏名又は名称】金子 修平

(74)【代理人】

【識別番号】100179648

【弁理士】

【氏名又は名称】田中 咲江

(74)【代理人】

【識別番号】100222885

【弁理士】

【氏名又は名称】早川 康

(74)【代理人】

【識別番号】100140338

【弁理士】

【氏名又は名称】竹内 直樹

(74)【代理人】

【識別番号】100227695

【弁理士】

【氏名又は名称】有川 智章

(74)【代理人】

【識別番号】100170896

【弁理士】

【氏名又は名称】寺薗 健一

(74)【代理人】

【識別番号】100219313

【弁理士】

【氏名又は名称】米口 麻子

(74)【代理人】

【識別番号】100161610

【弁理士】

【氏名又は名称】藤野 香子

(72)【発明者】

【氏名】呉珍赫

(72)【発明者】

【氏名】尹健

(72)【発明者】

【氏名】尹▲ソン▼佑

(72)【発明者】

【氏名】李相旻

(72)【発明者】

【氏名】林明哲

(72)【発明者】

【氏名】金泰均

(72)【発明者】

【氏名】沈相奎

(72)【発明者】

【氏名】金義錫

(72)【発明者】

【氏名】金徳洙

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376CA05

5B376CA15

5B376CA18

5B376GA07

(57)【要約】      （修正有）

【課題】車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノードを拡張する方法及びこれを利用する装置を提供する。
【解決手段】サーバによって行われるＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法は、車両のクライアントから車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージを受信するステップと、ＤｅｖＩｎｆｏに含まれた車両登録地域に関する情報を定義するフィールド、車両の年式に関する情報を定義するフィールド及びソフトウェアの拡張を定義するフィールドの情報に基づいて、クライアントが保有しているソフトウェアのアップデート状態を確認するステップと、を含む。
【選択図】図８

【特許請求の範囲】

【請求項1】

車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためにサーバによって行われるＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法であって、
車両のクライアントから車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージを受信するステップと、
前記ＤｅｖＩｎｆｏに含まれた車両登録地域に関する情報を定義するフィールド、車両の年式に関する情報を定義するフィールド、及びソフトウェアの拡張を定義するＳＷフィールドからの情報に基づいて、前記クライアントが保有しているソフトウェアのアップデート状態を確認するステップと、を含む、メッセージノード拡張方法。

【請求項2】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するフィールド、対象ソフトウェアの現在バージョンを定義するフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するフィールド、及び最終アップデート日を定義するフィールドを含む、請求項１に記載のメッセージノード拡張方法。

【請求項3】

前記確認するステップは、前記サーバに格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較するステップを含む、請求項１に記載のメッセージノード拡張方法。

【請求項4】

前記確認するステップは、前記比較するステップでの比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが同一でない場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証するステップをさらに含む、請求項３に記載のメッセージノード拡張方法。

【請求項5】

アップデートが必要なソフトウェアファイルのみを前記クライアントに送信するステップをさらに含み、前記クライアントは、前記ソフトウェアファイルを介して前記車両でアップデートが必要なソフトウェアのみをアップデートする、請求項１に記載のメッセージノード拡張方法。

【請求項6】

車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるために車両のクライアントによって行われるＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法であって、
車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージを生成するステップと、
前記パッケージをサーバに送信するステップと、を含み、
前記ＤｅｖＩｎｆｏは、車両登録地域に関する情報を定義するフィールド、車両の年式に関する情報を定義するフィールド、及びソフトウェアの拡張を定義するＳＷフィールドに関する情報を含み、
前記サーバは、前記ＤｅｖＩｎｆｏに基づいて車両のクライアントが保有しているソフトウェアのアップデート状態を確認する、メッセージノード拡張方法。

【請求項7】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するフィールド、対象ソフトウェアの現在バージョンを定義するフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するフィールド、及び最終アップデート日を定義するフィールドを含む、請求項６に記載のメッセージノード拡張方法。

【請求項8】

前記サーバは、既に格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較し、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが異なる場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証する、請求項６に記載のメッセージノード拡張方法。

【請求項9】

前記サーバからアップデートが必要なソフトウェアファイルのみを受信するステップをさらに含む、請求項６に記載のメッセージノード拡張方法。

【請求項10】

前記ソフトウェアファイルを介して前記車両でアップデートが必要なソフトウェアのみをアップデートするステップをさらに含む、請求項９に記載のメッセージノード拡張方法。

【請求項11】

車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法を利用するサーバであるメッセージノード拡張装置であって、
サーバに搭載され、ネットワークを介して車両のクライアントに接続される送受信装置と、
前記送受信装置と接続され、前記送受信装置の動作を制御するプロセッサと、を含み、
前記プロセッサは、前記クライアントから車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージを受信するステップと、前記ＤｅｖＩｎｆｏに含まれた車両登録地域に関する情報を定義するフィールド、車両の年式に関する情報を定義するフィールド、及びソフトウェアの拡張を定義するＳＷフィールドからの情報に基づいて、前記クライアントが保有しているソフトウェアのアップデート状態を確認するステップと、を行うように構成される、メッセージノード拡張装置。

【請求項12】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するフィールド、対象ソフトウェアの現在バージョンを定義するフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するフィールド、及び最終アップデート日を定義するフィールドを含む、請求項１１に記載のメッセージノード拡張装置。

【請求項13】

前記プロセッサは、前記確認するステップで、前記サーバに格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較するように構成される、請求項１１に記載のメッセージノード拡張装置。

【請求項14】

前記プロセッサは、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが同一でない場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証するステップをさらに行うように構成される、請求項１３に記載のメッセージノード拡張装置。

【請求項15】

前記プロセッサは、アップデートが必要なソフトウェアファイルを前記クライアントに送信するステップをさらに含み、ここで前記ソフトウェアファイルは、前記クライアントによって前記車両でアップデートが必要なソフトウェアのみをアップデートするために用いられる、請求項１１に記載のメッセージノード拡張装置。

【請求項16】

車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法を利用する車両のクライアントであるメッセージノード拡張装置であって、
車両に搭載され、ネットワークを介してサーバと接続される送受信装置と、
前記送受信装置と接続され、前記送受信装置の動作を制御するプロセッサと、を含み、
前記プロセッサは、車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージを生成するステップと、前記パッケージを前記送受信装置を介して前記サーバに送信するステップと、を行うように構成され、
前記ＤｅｖＩｎｆｏは、車両登録地域に関する情報を定義するフィールド、車両の年式に関する情報を定義するフィールド、及びソフトウェアの拡張を定義するＳＷフィールドに関する情報を含み、前記車両のクライアントが保有しているソフトウェアのアップデート状態を前記サーバで確認するために用いられる、メッセージノード拡張装置。

【請求項17】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するフィールド、対象ソフトウェアの現在バージョンを定義するフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するフィールド、及び最終アップデート日を定義するフィールドを含む、請求項１６に記載のメッセージノード拡張装置。

【請求項18】

前記サーバは、既に格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較し、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが異なる場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証する、請求項１６に記載のメッセージノード拡張装置。

【請求項19】

前記プロセッサは、前記送受信装置を介して前記サーバからアップデートが必要なソフトウェアファイルを受信するステップをさらに行うように構成される、請求項１６に記載のメッセージノード拡張装置。

【請求項20】

前記プロセッサは、前記ソフトウェアファイルを介して前記車両でアップデートが必要なソフトウェアのみをアップデートするステップをさらに行うように構成される、請求項１９に記載のメッセージノード拡張装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノードを拡張する方法、及びこれを利用する装置に関する。

【背景技術】

【0002】

オープンモバイルアライアンス（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ、ＯＭＡ）は、無線産業分野に関連するオプーン標準を確立する組織である。この組織の任務は、国家間、事業者間、モバイル端末間に相互運用可能なサービスを提供することである。ＯＭＡは、実用的なプロトコルの標準化のみに関心を有しており、外部組織によって規定されたネットワーキング技術の存在を仮定する。ＯＭＡ標準は、ネットワーキングや実在的なデータ転送を提供するために用いられている特定のセルラーネットワーク技術について何でも構わない。

【0003】

オーバーディエア（ｏｖｅｒ－ｔｈｅ ａｉｒ、ＯＴＡ）は、ファームウエアアップデート方式の１つである。ＯＴＡは、コンピュータに接続せずに、Ｗｉ－Ｆｉや移動通信網などの無線でファームウエアをアップデートする技術を意味する。最近、車両のＯＴＡアップデート技術は、新しいソフトウェア、ファームウエア、設定、暗号化キーのアップデートをオフラインの介入なしに遠隔で配布する車両の遠隔管理に適用されている。

【0004】

車両ＯＴＡアップデートを用いることで、車両のソフトウェアアップデートのための訪問修理、ＵＳＢ（登録商標）の配送などにかかるコストや時間を省略又は削減でき、ほとんどの車両の欠陥をソフトウェアアップデートで解決するか、車両のソフトウェアアップデートを通じて車両の新しい機能を効率的に提供することができる。

【0005】

一方、車両ＯＴＡアップデートを用いる場合、攻撃者はパーソナルコンピュータ（ＰＣ）やスマートフォンに対する攻撃手法を自律走行車両にそのまま適用することができるので、このような攻撃者の悪意のある攻撃を防御又は防止する必要がある。このような悪意のある攻撃を防御又は防止する最も効率的な方法は、車両のソフトウェアを迅速にアップデートすることであると知られている。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】韓国公開特許第１０－２０２１－０１３３５８７号公報（２０２１．１１．０８）

【発明の概要】

【発明が解決しようとする課題】

【0007】

本発明の目的は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノードを拡張する方法、及びこれを利用する装置を提供することである。

【0008】

本発明の他の目的は、ＯＭＡ－ＤＭ標準で機器の状態情報を同期させるＤｅｖＩｎｆｏ項目が自律走行車両のアップデートに不向きであるという問題を解決し、自律走行車両のＯＴＡアップデート時に十分な車両情報同期のためのＤｅｖＩｎｆｏノードを提供できるＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法、及びこれを利用する装置を提供することである。

【0009】

本発明のまた他の目的は、大容量のＯＴＡアップデート時に発生し得る問題を解決できる、すなわち大容量のＯＴＡアップデート時にアップデート時間を短縮し、データ容量及び通信コストを削減できる、ＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法、及びこれを利用する装置を提供することである。

【0010】

本発明のさらに他の目的は、管理サーバが自律走行車両の管理情報を正確に把握できる標準規格を拡張して定義することで、自律走行車両に適した機器管理オブジェクトの定義と自律走行車両の状態に応じた差分アップデートを行うことができる、ＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法、及びこれを利用する装置を提供することである。

【課題を解決するための手段】

【0011】

上記技術的課題を解決するための本発明の一態様によるメッセージノード拡張方法は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためにサーバによって行われるＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法であって、車両のクライアントから車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１を受信するステップと、前記ＤｅｖＩｎｆｏに含まれた車両登録地域に関する情報を定義するＶｅＬｏｃフィールド、車両の年式に関する情報を定義するＶｅＹｅａｒフィールド、及びソフトウェアの拡張を定義するＳＷフィールドからの情報に基づいて、前記クライアントが保有しているソフトウェアのアップデート状態を確認するステップと、を含む。

【0012】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するＳｗＩＤフィールド、対象ソフトウェアの現在バージョンを定義するＳｗＶフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するＬａｓｔＶフィールド、及び最終アップデート日を定義するＬａｓｔＵｐｄａｔｅフィールドを含んでもよい。

【0013】

前記確認するステップは、サーバに格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較するステップを含んでもよい。

【0014】

前記確認するステップは、前記比較するステップでの比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが同一でない場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証するステップをさらに含んでもよい。

【0015】

前記メッセージノード拡張方法は、アップデートが必要なソフトウェアファイルのみを前記クライアントに送信するステップをさらに含んでもよい。ここで、前記クライアントは、前記ソフトウェアファイルを介して車両でアップデートが必要なソフトウェアのみをアップデートすることができる。

【0016】

上記技術的課題を解決するための本発明の他の態様によるメッセージノード拡張方法は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるために車両のクライアントによって行われるＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭプロトコルのメッセージノード拡張方法であって、車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１を生成するステップと、前記パッケージ＃１をサーバに送信するステップと、を含む。ここで、前記ＤｅｖＩｎｆｏは、車両登録地域に関する情報を定義するＶｅＬｏｃフィールド、車両の年式に関する情報を定義するＶｅＹｅａｒフィールド、及びソフトウェアの拡張を定義するＳＷフィールドに関する情報を含む。また、前記ＤｅｖＩｎｆｏは、車両のクライアントが保有しているソフトウェアのアップデート状態を前記サーバで確認するために用いることができる。

【0017】

前記メッセージノード拡張方法において、前記サーバは、既に格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較し、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが異なる場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証してもよい。

【0018】

前記メッセージノード拡張方法は、前記サーバからアップデートが必要なソフトウェアファイルのみを受信するステップをさらに含んでもよい。

【0019】

前記メッセージノード拡張方法は、前記ソフトウェアファイルを介して車両でアップデートが必要なソフトウェアのみをアップデートするステップをさらに含んでもよい。

【0020】

上記技術的課題を解決するための本発明のまた他の態様によるメッセージノード拡張装置は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭプロトコルのメッセージノード拡張方法を利用するサーバであるメッセージノード拡張装置であって、サーバに搭載され、ネットワークを介して車両のクライアントに接続される送受信装置と、前記送受信装置と接続され、前記送受信装置の動作を制御するプロセッサと、を含む。ここで、前記プロセッサは、前記クライアントから車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１を受信するステップと、前記ＤｅｖＩｎｆｏに含まれた車両登録地域に関する情報を定義するＶｅＬｏｃフィールド、車両の年式に関する情報を定義するＶｅＹｅａｒフィールド、及びソフトウェアの拡張を定義するＳＷフィールドからの情報に基づいて、前記クライアントが保有しているソフトウェアのアップデート状態を確認するステップと、を行うように構成されてもよい。

【0021】

前記プロセッサは、前記確認するステップで、前記サーバに格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較するように構成されてもよい。

【0022】

前記プロセッサは、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが同一でない場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証するステップをさらに行うように構成されてもよい。

【0023】

前記プロセッサは、アップデートが必要なソフトウェアファイルを前記クライアントに送信するステップをさらに行うように構成されてもよい。ここで、前記ソフトウェアファイルは、前記クライアントによって前記車両でアップデートが必要なソフトウェアのみをアップデートするために用いられてもよい。

【0024】

上記技術的課題を解決するための本発明のさらに他の態様によるメッセージノード拡張装置は、車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭプロトコルのメッセージノード拡張方法を利用する車両のクライアントであるメッセージノード拡張装置であって、車両に搭載され、ネットワークを介してサーバと接続される送受信装置と、前記送受信装置と接続され、前記送受信装置の動作を制御するプロセッサと、を含む。ここで、前記プロセッサは、車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１を生成するステップと、前記パッケージ＃１を前記送受信装置を介して前記サーバに送信するステップと、を行うように構成される。また、前記ＤｅｖＩｎｆｏは、車両登録地域に関する情報を定義するＶｅＬｏｃフィールド、車両の年式に関する情報を定義するＶｅＹｅａｒフィールド、及びソフトウェアの拡張を定義するＳＷフィールドに関する情報を含んでもよく、前記車両のクライアントが保有しているソフトウェアのアップデート状態を前記サーバで確認するために用いられてもよい。

【0025】

前記ＳＷフィールドは、対象ソフトウェア識別子を定義するＳｗＩＤフィールド、対象ソフトウェアの現在バージョンを定義するＳｗＶフィールド、最後にダウンロードしたソフトウェアのバージョンを定義するＬａｓｔＶフィールド、及び最終アップデート日を定義するＬａｓｔＵｐｄａｔｅフィールドを含んでもよい。

【0026】

前記サーバは、既に格納されているソフトウェアの最新バージョンと、前記車両のソフトウェアインストールバージョンである前記ＤｅｖＩｎｆｏの対象ソフトウェアの現在バージョンとを比較し、比較の結果、前記サーバが保有しているソフトウェアの最新バージョンと前記対象ソフトウェアの現在バージョンとが異なる場合、前記サーバが保有しているソフトウェアの最新バージョンと、前記ＤｅｖＩｎｆｏの最後にダウンロードしたソフトウェアのバージョンとを比較検証してもよい。

【0027】

前記プロセッサは、前記送受信装置を介して前記サーバからアップデートが必要なソフトウェアファイルを受信するステップをさらに行うように構成されてもよい。

【0028】

前記プロセッサは、前記ソフトウェアファイルを介して車両でアップデートが必要なソフトウェアのみをアップデートするステップをさらに行うように構成されてもよい。

【発明の効果】

【0029】

本発明によると、ＯＭＡ－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）の標準拡張によって車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させることができる。

【0030】

また、本発明によると、ＯＭＡ－ＤＭ標準で機器の状態情報を同期させるＤｅｖＩｎｆｏ項目を拡張させて定義することで、自律走行車両のＯＴＡアップデート時に十分な車両情報同期のためのＤｅｖＩｎｆｏノードを提供することができる。

【0031】

また、本発明によると、ＤｅｖＩｎｆｏ項目の拡張によって、大容量のＯＴＡアップデート時に発生し得る問題を解決することができる。すなわち、大容量のＯＴＡアップデート時にアップデート時間を短縮し、データ容量及び通信コストを削減することができる。

【0032】

また、本発明によると、管理サーバが自律走行車両の管理情報を正確に把握できる標準規格を拡張して定義することで、自律走行車両に適した機器管理オブジェクトの定義と自律走行車両の状態による差分アップデートを効果的に行うことができる。

【図面の簡単な説明】

【0033】

【図1】ＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）で提案するＯＭＡ－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルの設定段階（ｓｅｔｕｐ ｐｈａｓｅ）を説明するための図である。

【図2】ＯＭＡ－ＤＭプロトコルの管理段階（ｍａｎａｇｅｍｅｎｔ ｐｈａｓｅ）を説明するための図である。

【図3】ＯＭＡ－ＤＭプロトコルに従う端末内のデータにサーバが遠隔でアクセスできる規格をＳｙｎｃＭＬ形式で定義した例示図である。

【図4】ＯＭＡ－ＤＭプロトコルによる大容量オブジェクト処理（ｌａｒｇｅ ｏｂｊｅｃｔ ｈａｎｄｌｉｎｇ）のために大容量のオブジェクトを追加するＤＭパッケージの流れを示す例示図である。

【図5】図４のパッケージ＃１（Ｐｋｇ＃１）のアラート（Ａｌｅｒｔ）１２０１、置換（Ｒｅｐｌａｃｅ）メッセージの機器情報（ＤｅｖＩｎｆｏ）項目に対するアドレス指定スキーム（ａｄｄｒｅｓｓｉｎｇ ｓｃｈｅｍｅ）を示す図である。

【図6】本発明の一実施形態による車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法（単に「メッセージノード拡張方法」という）に採用できる機器情報（ＤｅｖＩｎｆｏ）の拡張構造（単に「拡張ＤｅｖＩｎｆｏ」という）を説明するための図である。

【図7】図６の拡張ＤｅｖＩｎｆｏを用いるメッセージノード拡張方法を説明するためのフローチャートである。

【図8】本発明の他の実施形態によるメッセージノード拡張方法を説明するためのフローチャートである。

【図9】図８の確認過程で採用できる詳細過程に対するフローチャートである。

【図10】本発明のまた他の実施形態による車両ＯＴＡアップデートの効率性を向上させるためのＯＭＡ－ＤＭプロトコルのメッセージノード拡張装置（単に「メッセージノード拡張装置」という）に採用できる構成に対する概略図である。

【発明を実施するための形態】

【0034】

本発明は、様々な変更を加えることができ、様々な実施形態を有することができるため、特定の実施形態を図面に例示して詳細に説明する。しかし、これは、本発明を特定の実施形態に限定することを意図するものではなく、本発明の思想および技術の範囲に含まれるすべての変更、均等物又は代替物を含むことを理解されたい。

【0035】

第１、第２などの用語は、様々な構成要素を説明するために使用することができるが、上記構成要素は上記用語によって限定されてはならない。上記用語は、ある構成要素を他の構成要素から区別する目的でのみ使用される。例えば、本発明の権利範囲を逸脱することなく、第１構成要素は第２構成要素と命名することができ、同様に第２構成要素も第１構成要素と命名することができる。「及び／又は」という用語は、複数の関連する記載項目の組み合わせ又は複数の関連する記載項目のうちのいずれかの項目を含む。

【0036】

本出願の実施形態において、「Ａ及びＢのうち少なくとも１つ」は、「Ａ又はＢのうち少なくとも１つ」又は「Ａ及びＢのうち１つ以上の組み合わせのうちで少なくとも１つ」を意味することができる。また、本出願の実施形態において、「Ａ及びＢのうち１つ以上」は、「Ａ又はＢのうち１つ以上」又は「Ａ及びＢのうち１つ以上の組み合わせのうちで１つ以上」を意味することができる。

【0037】

ある構成要素が他の構成要素に「連結されて」又は「接続されて」いると言及された場合は、他の構成要素に直接的に連結又は接続されていてもよいが、それらの間にまた他の構成要素が存在してもよいと理解すべきである。一方、ある構成要素が他の構成要素に「直接連結されて」又は「直接接続されて」いると言及された場合は、それらの間にまた他の構成要素が存在しないと理解すべきである。

【0038】

本出願で使用される用語は、単に特定の実施形態を説明するために使用されたものであり、本発明を限定することを意図していない。単数の表現は文脈上明らかに他に意味がない限り、複数の表現を含む。本出願で、「含む」又は「有する」などの用語は、明細書に記載の特徴、数字、ステップ、動作、構成要素、部品又はこれらを組み合わせたものが存在することを指定しようとするものであり、１つ又はそれ以上の他の特徴、数字、ステップ、動作、構成要素、部品又はこれらを組み合わせたものなどの存在又は付加の可能性をあらかじめ排除しないことを理解されたい。

【0039】

他に定義されない限り、技術的又は科学的な用語を含んで本明細書で使用されるすべての用語は、本発明が属する技術分野における通常の知識を有する者であれば一般に理解するような意味を有している。一般に使用される辞書で定義されているような用語は、関連技術の文脈上の意味と一致する意味を有するものとして解釈されるべきであり、本出願で明白に定義しない限り、理想的または過度に形式的な意味として解釈されてはならない。

【0040】

以下、添付の図面を参照して、本発明の好ましい実施形態をより詳細に説明する。以下の詳細な説明は例示の目的でのみ提供されており、本発明の概念を任意の特定された物理的構成に限定するものと解釈されてはならない。本発明を説明する際の全体的な理解を容易にするために、図面上の同一の構成要素には同一の参照符号を用い、同一の構成要素について重複する説明は省略する。

【0041】

図１は、ＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）で提案するＯＭＡ－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルの設定段階（ｓｅｔｕｐ ｐｈａｓｅ）を説明するための図である。

【0042】

図１を参照すると、ＯＭＡ－ＤＭプロトコルの設定段階で、クライアント（Ｃｌｉｅｎｔ）２０は、サーバ（Ｓｅｒｖｅｒ）１０からパッケージ０（Ｐａｃｋａｇｅ ０）を受信する（Ｓ１１）。パッケージ０は、管理初期化アラート（ｍａｎａｇｅｍｅｎｔ ｉｎｉｔｉａｔｉｏｎ ａｌｅｒｔ）メッセージを含む。パッケージは、少なくとも１つ以上のメッセージを含む。また、サーバ１０は、ＯＭＡ－ＤＭプロトコルに従うＤＭサーバであってもよく、クライアント２０は、ＯＭＡ－ＤＭプロトコルに従うＤＭクライアントであってもよい。

【0043】

次いで、クライアント２０は、パッケージ１（ｐａｃｋａｇｅ １）をサーバ１０に送信する（Ｓ１３）。パッケージ１は、ＤＭクライアントのクライアント初期化のための初期化パッケージ（ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｐａｃｋａｇｅ）であり、クライアント資格証明（ｃｌｉｅｎｔ ｃｒｅｄｅｎｔｉａｌｓ）と機器情報（ｄｅｖｉｃｅ ｉｎｆｏｒｍａｔｉｏｎ）に関するメッセージを含む。

【0044】

次いで、クライアント２０は、サーバ１０からパッケージ２（ｐａｃｋａｇｅ ２）を受信する（Ｓ１５）。パッケージ２は、ＤＭサーバのサーバ初期化（ｓｅｒｖｅｒ ｉｎｉｔｉａｌｉｚａｔｉｏｎ）のための初期化パッケージであり、サーバ資格証明（ｓｅｒｖｅｒ ｃｒｅｄｅｎｔｉａｌｓ）と、サーバ１０からの初期管理動作（ｉｎｉｔｉａｌ ｍａｎａｇｅｍｅｎｔ ｏｐｅｒａｔｉｏｎｓ）又はユーザ相互作用コマンド（ｕｓｅｒ ｉｎｔｅｒａｃｔｉｏｎ ｃｏｍｍａｎｄｓ）に関するメッセージを含む。

【0045】

図２は、ＯＭＡ－ＤＭプロトコルの管理段階（ｍａｎａｇｅｍｅｎｔ ｐｈａｓｅ）を説明するための図である。

【0046】

図２を参照すると、ＯＭＡ－ＤＭプロトコルの管理段階で、クライアント（ｃｌｉｅｎｔ）２０は、パッケージ３（ｐａｃｋａｇｅ ３）をサーバ（ｓｅｒｖｅｒ）１０に送信する（Ｓ１７）。パッケージ３は、ＤＭサーバに送信されるＤＭクライアント応答であり、管理動作に関するメッセージを含む。

【0047】

次いで、クライアント２０は、サーバ１０からパッケージ４（ｐａｃｋａｇｅ ４）を受信する（Ｓ１９）。パッケージ４は、ＤＭサーバの追加管理作業のためのパッケージであり、セッションの継続中に追加のユーザ相互作用及び管理作業に対する少なくとも１つ以上のメッセージを含む。

【0048】

図３は、ＯＭＡ－ＤＭプロトコルに従う端末内のデータにサーバが遠隔でアクセスできる規格をＳｙｎｃＭＬ形式で定義した例示図である。

【0049】

図３を参照すると、ＯＭＡ－ＤＭプロトコルに従うＤＭサーバは、ＳｙｎｃＭＬメッセージを介してＤＭクライアント内のデータに遠隔でアクセスすることができる。このようなＳｙｎｃＭＬメッセージは、プラットフォームに依存しないデータ同期標準であり、マイクロソフト（登録商標）ウィンドウを用いるパーソナルコンピュータ（ＰＣ）、リヌックス（ｌｉｎｕｘ）（登録商標）を用いるＰＣ、パーム（Ｐａｌｍ）（登録商標）ＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、携帯電話、アイポット、アイフォン、車両などどの機器とも自由にデータを同期させることができる。ＳｙｎｃＭＬは、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）に基づいている。また、ＳｙｎｃＭＬメッセージは、ＤＭクライアントから送信されるパッケージ１や、ＤＭクライアントから送信されるパッケージ２などに適用することができる。メッセージは、１つ以上のコマンドを含むことができる。

【0050】

各メッセージは、ＳｙｎｃＨｄｒ要素（ｅｌｅｍｅｎｔ）と指定されたヘッダーと、ＳｙｎｃＢｏｄｙ要素と指定されたメッセージ本文とで構成される。すなわち、メッセージコンテナ要素は、＜ＳｙｎｃＭＬ＞、＜ＳｙｎｃＨｄｒ＞及び＜ＳｙｎｃＢｏｄｙ＞を含む。

【0051】

＜ＳｙｎｃＭＬ＞は、最上位要素としてＭＩＭＥコンテンツタイプを含んでもよい。

【0052】

＜ＳｙｎｃＨｄｒ＞は、ＤＭサービスのために必要な認証情報、文書タイプの定義（ｄｏｃｕｍｅｎｔ ｔｙｐｅ ｄｅｆｉｎｉｔｉｏｎ、ＤＴＤ）（ＶｅｒＤＴＤ）、プロトコルタイプ（ＶｅｒＰｒｏｔｏ）、セッション識別子（ＳｅｓｓｉｏｎＩＤ）、メッセージ識別子（ＭｓｇＩＤ）、対象（Ｔａｒｇｅｔ）経路情報などを指定するための要素を含む。＜ＳｙｎｃＨｄｒ＞は、データ同期サービスと同一の意味で使用される。

【0053】

＜ＳｙｎｃＢｏｄｙ＞は、実際に実行が必要なコマンドを含む要素であり、コマンド識別子（ＣｍｄＩＤ）、データ（Ｄａｔａ）などの要素を含んでもよい。

【0054】

図４は、ＯＭＡ－ＤＭプロトコルによる大容量オブジェクト処理（ｌａｒｇｅ ｏｂｊｅｃｔ ｈａｎｄｌｉｎｇ）のために大容量のオブジェクトを追加するＤＭパッケージの流れを示す例示図である。

【0055】

図４を参照すると、ＯＭＡ－ＤＭプロトコルは、複数のＤＭメッセージを用いて１つのＳｙｎｃＭＬパッケージを送信する機能を提供する。これは、１つのＳｙｎｃＭＬパッケージが大きくなりすぎ、１つのＳｙｎｃＭＬメッセージとして送信できない場合に必要である。例えば、このような制限は、送信プロトコル又は小型のフットプリント装置の制限によって発生し得る。

【0056】

ＯＭＡ－ＤＭプロトコルで項目の論理的なグループ化としてパッケージの役割は非常に制限的である。ほとんどの制限はパッケージでなくメッセージで発生する。例えば、コマンドは１つのメッセージに完全に対応しなければならない。これには、シーケンスコマンド（ｓｅｑｕｅｎｃｅ ｃｏｍｍａｎｄ）及びアトミックコマンド（ａｔｏｍｉｃ ｃｏｍｍａｎｄ）が含まれており、各コマンドは１つのメッセージに完全に対応しなければならない。

【0057】

制限されたリソースでＤＭクライアントを圧倒することを避けるために、ＤＭサーバが以前のコマンドに対する状態をまだ返していないクライアントに新しいコマンドを送信することは許容されない。すなわち、ＤＭサーバからＤＭクライアントに送信するほとんどのメッセージは、少なくとも１つのメッセージを含むパッケージに該当する。ただし、ＤＭサーバが大きい個体を送信するか、又はより多くのメッセージを要求する場合、すなわちアラート（Ａｌｅｒｔ）１２２２を使用する場合は例外である。大容量の個体データを含むパッケージには、大きい個体を送信するために必要なだけのメッセージが含まれている。

【0058】

サーバ（Ｓｅｒｖｅｒ）１０で表されるＤＭサーバは、パッケージ境界に関して常に以下の１）から３）の状態のいずれか１つの状態を有する。

【0059】

１）ＤＭサーバが完全なパッケージをクライアント（Ｃｌｉｅｎｔ）２０で表されるＤＭクライアントに送信する（Ｓ４２、Ｓ４４ｃ、Ｓ４６、Ｓ４８）。この状態で、ＤＭサーバは、パッケージに送信されたコマンドに対してＤＭクライアントの状態を待つ。Ｇｅｔコマンドの結果のように、状態及び結果が大きい可能性があるため、ＤＭクライアントは応答を完了する前に複数のメッセージをＤＭサーバにまた送信することができる。

【0060】

２）ＤＭサーバがＤＭクライアントから完全なパッケージ、すなわちパッケージ応答を受信する（Ｓ４１、Ｓ４３ｂ、Ｓ４５ｂ、Ｓ４７）。この状態で、ＤＭサーバは、ＤＭクライアントに新しいコマンドを送信することができる。

【0061】

３）ＤＭサーバが同一のパッケージの一部である１つ以上のメッセージを送信し、まだ現在パッケージの最終メッセージを送信していない（Ｓ４４ａ、Ｓ４４ｂ）。この状態は、ＤＭサーバが大きい個体を送信する場合にのみ有効であり、大きい個体の最後のチャンクが送信されるとパッケージが終了する。

【0062】

一方、ＤＭサーバは、ＤＭクライアントから最終メッセージを含んでいない不完全なパッケージ応答を受信することがある（Ｓ４３ａ、Ｓ４５ａ）。

【0063】

ＤＭメッセージに対する基本的な送信には要請／応答形式があるため、ＤＭクライアント又はＤＭサーバは、要請／応答周期を継続して維持するために、新しいコマンドや最終フラグを含んでいないメッセージを送信してもよい。例えば、ＤＭサーバが状態１、すなわち、上記１）の状態である場合、状態及び結果を含むＤＭクライアントから多くのメッセージを受信することがある。ＤＭサーバは、ＤＭクライアントが送信した各メッセージに応答するが、該応答に新しいコマンドを含んでいなくてもよい。この状態で、ＤＭサーバが送信したメッセージには、ＤＭクライアントが送信したＳｙｎｃＨｄｒに対する状態とアラート（Ａｌｅｒｔ）１２２２メッセージ、すなわち追加のメッセージが含まれることがある。状態は、アラートに対する応答として送信されなければならないが、結果に対する応答としては送信されない。ＤＭサーバがセッションを中断しようとする場合、アラート（Ａｌｅｒｔ）１２２２メッセージがアラート（Ａｌｅｒｔ）１２２３メッセージ、すなわちセッション中断メッセージに置き換えられ得る。

【0064】

このように、図４は、上述の複数のメッセージを用いることができる方法を例示する。

【0065】

図５は、図４のパッケージ＃１（Ｐｋｇ＃１）のアラート（Ａｌｅｒｔ）１２０１メッセージである置換（Ｒｅｐｌａｃｅ）メッセージの機器情報（ＤｅｖＩｎｆｏ）項目に対するアドレス指定スキーム（ａｄｄｒｅｓｓｉｎｇ ｓｃｈｅｍｅ）を示す図である。

【0066】

図５を参照すると、既存のメッセージ内の機器情報（ＤｅｖＩｎｆｏ）５０は、Ｅｘｔフィールド５１、Ｂｅａｒｅｒフィールド５２、ＤｅｖＩｄフィールド５３、Ｍａｎフィールド５４、Ｍｏｄフィールド５５、ＤｍＶフィールド５６、Ｌａｎｇフィールド５７で構成される。

【0067】

ここで、Ｅｘｔフィールド５１は選択的（ｏｐｔｉｏｎａｌ、ｏｐ）フィールドであり、ＤｅｖＩｎｆｏフォーマットで拡張可能なサーブツリーを定義する。Ｂｅａｒｅｒフィールド５２は選択的フィールドであり、ネットワークベアラーに関する項目を定義する。ＤｅｖＩｄフィールド５３は機器識別子を定義する。Ｍａｎフィールド５４は機器メーカーを定義する。Ｍｏｄフィールド５５は機器モデルＩＤを定義する。ＤｍＶフィールド５６は機器が支援するＤＭバージョン情報を定義する。Ｌａｎｇフィールド５７は機器に表示されるユーザインターフェース言語を定義する。

【0068】

上述のＯＭＡ－ＤＭプロトコルは、ＤＭツリー変更アラート（ＤＭ ｔｒｅｅ ｃｈａｎｇｅ ａｌｅｒｔ）メッセージを介して、ＤＭツリーの変更をＤＭサーバがＤＭクライアントに、またはＤＭクライアントがＤＭサーバに通知するように構成されてもよい。

【0069】

図６は、本発明の一実施形態による車両ＯＴＡ（ｏｖｅｒ－ｔｈｅ ａｉｒ）アップデートの効率性を向上させるためのＯＭＡ（ｏｐｅｎ ｍｏｂｉｌｅ ａｌｌｉａｎｃｅ）－ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）プロトコルのメッセージノード拡張方法（単に「メッセージノード拡張方法」という）に採用できる機器情報（ＤｅｖＩｎｆｏ）の拡張構造（単に「拡張ＤｅｖＩｎｆｏ」という）を説明するための図である。

【0070】

図６を参照すると、メッセージモード拡張方法は拡張ＤｅｖＩｎｆｏフォーマットを用いることができる。拡張ＤｅｖＩｎｆｏフォーマットは、車両ＯＴＡアップデート時に、クライアントがサーバに車両機器の状態情報を同期させるために用いることができる。

【0071】

クライアントは、機器管理（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ、ＤＭ）を支援するＤＭクライアントに対応し、クライアント機器又は車両機器と称されてもよい。また、サーバは、機器管理（ＤＭ）を支援するＤＭサーバに対応し、サーバ装置などと称されてもよい。

【0072】

拡張ＤｅｖＩｎｆｏ６０は、Ｅｘｔフィールド６１、Ｂｅａｒｅｒフィールド６２、ＶｅＩＤフィールド６３、ＶｅＭａｎフィールド６４、ＶｅＭｏｄフィールド６５、ＶｅＬｏｃフィールド６６、ＶｅＹｅａｒフィールド６７、ＤｍＶフィールド６８、Ｌａｎｇフィールド６９、ＳＷフィールド７０、ＳｗＩＤフィールド７１、ＳｗＶフィールド７２、ＬａｓｔＶフィールド７３及びＬａｓｔＵｐｄａｔｅフィールド７４を含んで構成されてもよい。

【0073】

ここで、Ｅｘｔフィールド６１は選択的（ｏｐｔｉｏｎａｌ、ｏｐ）フィールドであり、ＤｅｖＩｎｆｏフォーマットで拡張可能なサーブツリーを定義することができる。Ｂｅａｒｅｒフィールド６２は選択的（ｏｐ）フィールドであり、ネットワークベアラーに関する項目を定義することができる。ＶｅＩＤフィールド６３は、車両識別子を定義することができる。ＶｅＭａｎフィールド６４は、車両メーカーを定義することができる。ＶｅＭｏｄフィールド６５は、車両のモデルＩＤを定義することができる。ＶｅＬｏｃフィールド６６は、車両登録地域を定義することができる。ＶｅＹｅａｒフィールド６７は、車両の年式を定義することができる。ＤｍＶフィールド６８は、車両のＤＭクライアントが支援するＤＭバージョン情報を定義することができる。Ｌａｎｇフィールド６９は、車両のＤＭクライアントに表示されるユーザインターフェース言語を定義することができる。ＳＷフィールド７０は、ソフトウェアの拡張を定義することができる。ＳｗＩＤフィールド７１は、対象ソフトウェア識別子を定義することができる。ＳｗＶフィールド７２は、対象ソフトウェアの現在バージョンを定義することができる。ＬａｓｔＶフィールド７３は、最後にダウンロードしたソフトウェアのバージョンを定義することができる。また、ＬａｓｔＵｐｄａｔｅフィールド７４は、最終アップデート日を定義することができる。

【0074】

上述の拡張ＤｅｖＩｎｆｏフォーマットを示すと下記の表１の通りである。

【表1】

【0075】

上述のＶｅＬｏｃフィールド６６が車両登録地域として「ソウル」を定義する場合、これをＳｙｎｃＭＬ（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）形式で表すと下記の通りである。

【0076】

<Item>
<Source><LocURI> ./DevInfo/VeLoc </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> ソウル </Data>
</Item>

【0077】

また、上述のＶｅＹｅａｒフィールド６７が車両の年式として「２０２０年１２月１２日」を定義する場合、これをＳｙｎｃＭＬ形式で表すと下記の通りである。

【0078】

<Item>
<Source><LocURI> ./DevInfo/VeYear </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> 2020-12-12 </Data>
</Item>

【0079】

また、上述のＳＷフィールド７０のＳｗＩＤフィールド７１が対象ソフトウェア識別子として「８８０ｆ３６５７０」を定義する場合、これをＳｙｎｃＭＬ形式で表すと下記の通りである。

【0080】

<Item>
<Source><LocURI> ./DevInfo/SW/SwID </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> 880f36570 </Data>
</Item>

【0081】

また、上述のＳＷフィールド７０のＳｗＶフィールド７２が対象ソフトウェアの現在バージョンとして「ｖｅｒｓｉｏｎ １（ｖ１）」を定義する場合、これをＳｙｎｃＭＬ形式で表すと下記の通りである。

【0082】

<Item>
<Source><LocURI> ./DevInfo/SW/SwV </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> v1 </Data>
</Item>

【0083】

また、上述のＳＷフィールド７０のＬａｓｔＶフィールド７３が車両機器で最後にダウンロードしたソフトウェアのバージョンとして「ｖｅｒｓｉｏｎ １（ｖ１）」を定義する場合、これをＳｙｎｃＭＬ形式で表すと下記の通りである。

【0084】

<Item>
<Source><LocURI> ./DevInfo/SW/LastV </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> v1 </Data>
</Item>

【0085】

また、上述のＳＷフィールド７０のＬａｓｔＵｐｄａｔｅフィールド７４が最終アップデート日として「２０２０年１２月２４日」を定義する場合、これをＳｙｎｃＭＬ形式で表すと下記の通りである。

【0086】

<Item>
<Source><LocURI> ./DevInfo/SW/LastUpdate </LocURI><Source>
<Meta>
<Format xmlns=“syncml:metinf”> chr </Format>
<Type xmlns=““syncml:metinf”> text/plain </Type>
</Meta>
<Data> 2020-12-24 </Data>
</Item>

【0087】

本実施形態によると、ＯＭＡ－ＤＭ標準で自律走行車両の機器状態情報を同期させるＤｅｖＩｎｆｏ項目を拡張させて定義することで、自律走行車両のＯＴＡアップデート時に十分な車両情報同期のためのＤｅｖＩｎｆｏノードを提供することができる。

【0088】

図７は、図６の拡張ＤｅｖＩｎｆｏを用いるメッセージノード拡張方法を説明するためのフローチャートである。

【0089】

図７を参照すると、メッセージノード拡張方法は、自律走行車両のＤＭクライアント（ＤＭ Ｃｌｉｅｎｔ）２００とＤＭサーバ（ＤＭ Ｓｅｒｖｅｒ）１００との間のパッケージ送受信と、ＤＭサーバ１００及びＤＭクライアント２００のそれぞれの動作によって実現することができる。

【0090】

ＤＭクライアント２００を中心にメッセージノード拡張方法を説明すると、ＤＭクライアント２００はまず、車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１を生成することができる。ここで、車両機器情報（ＤｅｖＩｎｆｏ）は、単に機器情報又はＤｅｖＩｎｆｏと称することができる。

【0091】

次いで、ＤＭクライアント２００は、車両機器情報（ＤｅｖＩｎｆｏ）を含むパッケージ＃１をＤＭサーバ１００に送信することができる（Ｓ７１）。パッケージ＃１は、アラート１２０１（Ａｌｅｒｔ １２０１）、置換最終（Ｒｅｐｌａｃｅ ｆｉｎａｌ）メッセージを含んでもよい。

【0092】

本実施形態において、車両機器情報（ＤｅｖＩｎｆｏ）は、車両登録地域に関する情報を定義するフィールド（ＶｅＬｏｃフィールド）、車両の年式に関する情報を定義するフィールド（ＶｅＹｅａｒフィールド）、ソフトウェアの拡張を定義するフィールド（ＳＷフィールド）に関する情報を含んでもよい。また、車両機器情報（ＤｅｖＩｎｆｏ）は、表１に列挙されたフィールドを備えてもよく、このようなＤｅｖＩｎｆｏは、自律走行車両などの車両のＤＭクライアント２００が保有しているソフトウェアのアップデート状態をＤＭサーバ１００で確認するために用いることができる。

【0093】

次いで、ＤＭクライアント２００は、ＤＭサーバ１００からパッケージ＃２を受信することができる（Ｓ７２）。パッケージ＃２は、基本的にＤＭサーバ１００からＤＭクライアント２００に送信される初期化のためのパッケージである。パッケージ＃２は、ＳｙｎｃＨｄｒ要素の状態、アラート（Ａｌｅｒｔ）と置換（Ｒｅｐｌａｃｅ）要素、コマンド（Ｃｏｍｍａｎｄｓ）要素、最終（Ｆｉｎａｌｓ）要素に対する状態情報を含んでもよい。

【0094】

ここで、ＤＭクライアント２００は、ＤＭサーバ１００からパッケージ＃２を介してアップデートが必要なソフトウェアファイルのみを受信することができる。

【0095】

次いで、ＤＭクライアント２００は、受信したソフトウェアファイルを用いてアップデートが必要なソフトウェアファイルのみをアップデートすることができる。

【0096】

図８は、本発明の他の実施形態によるメッセージノード拡張方法を説明するためのフローチャートである。

【0097】

図８を参照すると、メッセージノード拡張方法は、ＤＭサーバによって行われる方法であって、車両のＤＭクライアント（ＤＭ Ｃｌｉｅｎｔ）から車両機器情報を含むパッケージ＃１（Ｐａｃｋａｇｅ＃１）を受信することができる（Ｓ８１）。車両機器情報は、ＯＭＡ－ＤＭ標準で定義している機器情報（ｄｅｖｉｃｅ ｉｎｆｏｒｍａｔｉｏｎ、ＤｅｖＩｎｆｏ）であり、本実施形態で新しく提案される拡張ＤｅｖＩｎｆｏを称することができる。本実施形態で車両機器情報は単に機器情報又はＤｅｖＩｎｆｏと称されてもよい。

【0098】

次いで、ＤＭサーバ（ＤＭ Ｓｅｒｖｅｒ）は、ＤｅｖＩｎｆｏ内の情報を確認することによって、ＤＭクライアントが保有しているソフトウェア（ｓｏｆｔｗａｒｅ、ＳＷ）のアップデート状態を確認することができる（Ｓ８３）。ＤｅｖＩｎｆｏは、車両登録地域に関する情報を定義するフィールド（ＶｅＬｏｃフィールド）、車両の年式に関する情報を定義するフィールド（ＶｅＹｅａｒフィールド）、ソフトウェアの拡張を定義するフィールド（ＳＷフィールド）などを含んでもよい。また、ＳＷフィールドは、対象ソフトウェア識別子を定義するフィールド（ＳｗＩＤフィールド）、対象ソフトウェアの現在バージョンを定義するフィールド（ＳｗＶフィールド）、最後にダウンロードしたソフトウェアのバージョンを定義するフィールド（ＬａｓｔＶフィールド）、及び最終アップデート日を定義するフィールド（ＬａｓｔＵｐｄａｔｅフィールド）を含んでもよい。

【0099】

次いで、ＤＭサーバは、ＤｅｖＩｎｆｏ内の情報を通じて確認された車両、例えば、自律走行車両のソフトウェアアップデート状態によってさらにアップデートが必要なソフトウェアに対するアップデート用ソフトウェアファイルのみを抽出し、抽出したソフトウェアファイルをＤＭクライアントに送信することができる（Ｓ８５）。

【0100】

図９は、図８の確認過程に採用できる詳細過程に対するフローチャートである。

【0101】

図９を参照すると、ＤＭサーバ（ＤＭ Ｓｅｒｖｅｒ）は、ＤｅｖＩｎｆｏ内の情報に基づいてＤＭクライアント（ＤＭ Ｃｌｉｅｎｔ）が保有しているソフトウェアのアップデート状態を確認した後、ＤＭサーバに格納又は保有しているソフトウェア（ＳＷ）の最新バージョンと、車両のソフトウェアインストールバージョンであるＤｅｖＩｎｆｏのＳｗＶフィールド内の対象ソフトウェアの現在バージョン（Ｓｗインストールバージョン）とを比較することができる（Ｓ９１）。

【0102】

次いで、上記の比較ステップ（Ｓ９１）での比較の結果、ＤＭサーバが保有しているソフトウェアの最新バージョンと対象ソフトウェアの現在バージョンとが同一でない場合（Ｓ９３のＮｏ）、ＤＭサーバは、ＤＭサーバが保有しているソフトウェアの最新バージョンと、ＤｅｖＩｎｆｏのＬａｓｔＶフィールド内の最後にダウンロードしたソフトウェアのバージョンとを比較検証してもよい（Ｓ９５）。

【0103】

一方、上記比較ステップ（Ｓ９１）での比較の結果、ＤＭサーバが保有しているソフトウェアの最新バージョンと対象ソフトウェアの現在バージョンとが同一である場合（Ｓ９３のＹｅｓ）、ＤＭサーバは、ＤｅｖＩｎｆｏ内の情報を通じて確認された車両、例えば、自律走行車両のソフトウェアアップデート状態によってさらにアップデートが必要なソフトウェアに対するアップデート用ソフトウェアファイルのみを抽出し、抽出したソフトウェアファイルをＤＭクライアントに送信してもよい（図８のＳ８５を参照）。

【0104】

次いで、ＤＭサーバは、上記比較検証ステップ（Ｓ９５）での比較検証の結果、ＤＭサーバが保有しているソフトウェアの最新バージョンとＤｅｖＩｎｆｏのＬａｓｔＶフィールド内の最後にダウンロードしたソフトウェアのバージョンとが異なる場合、ＤＭサーバは、対象ソフトウェアに対してＤＭサーバが保有しているソフトウェアの最新バージョンのソフトウェアを抽出してＤＭクライアントに送信してもよい。

【0105】

一方、上記比較検証ステップ（Ｓ９５）での比較検証の結果、ＤＭサーバが保有しているソフトウェアの最新バージョンとＤｅｖＩｎｆｏのＬａｓｔＶフィールド内の最後にダウンロードしたソフトウェアのバージョンとが同一である場合、ＤＭサーバは、対象ソフトウェアが正常又は最新バージョンであることを確認し、本プロセスを終了してもよい。

【0106】

本実施形態のメッセージノード拡張方法の適用過程を例を挙げて説明すると、自律走行車両のＤＭクライアントが第１のソフトウェア（ＳＷ）、第２のＳＷ及び第３のＳＷを保有し、第１のＳＷの現在バージョン（ＳｗＶ）がｖ１で第１のＳＷの最後にダウンロードしたソフトウェアのバージョン（ＬａｓｔＶ）がｖ１であり、第２のＳＷの現在バージョンがｖ１で第２のＳＷの最後にダウンロードしたソフトウェアのバージョンがｖ２であり、第３のＳＷの現在バージョンがｖ２で第３のＳＷの最後にダウンロードしたソフトウェアのバージョンがｖ３であると確認された場合、また自身が保有している最新ソフトウェアアップデートバージョンがｖ２である場合、ＤＭサーバは、第１のＳＷをアップデートするためのアップデートファイル（ｖ２）を送信し、第２のＳＷに対するアップデート推奨を送信するように動作してもよい。

【0107】

図１０は、本発明のまた他の実施形態による車両ＯＴＡアップデートの効率性を向上させるためのＯＭＡ－ＤＭプロトコルのメッセージノード拡張装置（単に「メッセージノード拡張装置」という）に採用できる構成に対する概略図である。

【0108】

図１０を参照すると、メッセージノード拡張装置１０００は、車両ＯＴＡアップデートの効率性を向上させるためのＯＭＡ－ＤＭプロトコルのメッセージノード拡張方法を実現する少なくとも１つのプロセッサ１１００を含んでもよい。少なくとも１つのプロセッサ１１００は、ＤＭクライアント又はＤＭサーバに搭載されてもよい。

【0109】

また、メッセージノード拡張装置１０００は、メモリ１２００、送受信装置１３００、入力インタフェース装置１４００、出力インタフェース装置１５００、記憶装置１６００又はこれらを組み合わせた構成をさらに備えてもよい。メッセージノード拡張装置１０００に含まれたそれぞれの構成要素は、バス（ｂｕｓ）１７００によって接続されて互いに通信を行ってもよい。

【0110】

また、メッセージノード拡張装置１０００に含まれた構成要素は、共通のバス１７００でなく、プロセッサ１１００を中心に個々のインタフェース又は個々のバスを介して接続されてもよい。例えば、プロセッサ１１００は、メモリ１２００、送受信装置１３００、入力インタフェース装置（１４００）、出力インタフェース装置１５００、記憶装置１６００の少なくとも１つと専用のインタフェースを介して接続されてもよい。

【0111】

上述のプロセッサ１１００は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、グラフィック処理装置（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、又は本発明の実施形態による方法が行われる専用のプロセッサを意味してもよい。また、メモリ１２００及び記憶装置１６００のそれぞれは、揮発性記憶媒体及び不揮発性記憶媒体のうちの少なくとも１つで構成されてもよい。例えば、メモリ１２００は、読み出し専用メモリ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）及びランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）のうちの少なくとも１つで構成されてもよい。

【0112】

送受信装置１３００は、ネットワークを介してＤＭサーバと信号及びデータを送受信する通信を支援するか、又はネットワークを介してＤＭクライアントと信号及びデータを送受信する通信を支援するためのサーブ通信システムを含んでもよい。サーブ通信システムは、無線通信方式を支援するか、又は無線と有線の通信方式が混合したハイブリッド通信方式を支援するように構成されてもよい。

【0113】

ここで、ネットワークは、Ｄ２Ｄ（ｄｅｖｉｃｅ ｔｏ ｄｅｖｉｃｅ）通信、サイドリンク（ｓｉｄｅｌｉｎｋ）通信、ＮＲ（ｎｅｗ ｒａｄｉｏ）Ｖ２Ｘ（ｖｅｈｉｃｕｌａｒ ｔｏ ｅｖｅｒｙｔｈｉｎｇ）通信などを支援するネットワークを含んでもよい。また、ネットワークは、コアネットワークやエッジネットワーク上のＤＭサーバ又はＤＭサーバを含む特定のサービスサーバと移動通信網、無線通信網、衛星網又はこれらの組み合わせを介して接続されるＤＭクライアント、又はＤＭクライアントが搭載された車両間で形成可能なすべての通信網を含んでもよい。車両は自律走行車両を含んでもよい。

【0114】

入力インタフェース装置１４００は、キーボード、マイク、タッチパッド、タッチスクリーン、遠隔制御手段などから選択される少なくとも１つの入力手段と、少なくとも１つの入力手段によって入力される信号を既に格納されているコマンドとマッピング又は処理する入力信号処理部を含んでもよい。

【0115】

出力インタフェース装置１５００は、プロセッサ１１００の制御によって出力される信号を既に格納されている信号形態やレベルにマッピング又は処理する出力信号処理部と、出力信号処理部の信号によって振動、光、音、熱などの形態で信号や情報を出力する少なくとも１つの出力手段を含んでもよい。少なくとも１つの出力手段は、スピーカー、ディスプレイ装置、プリンタ、光出力装置、振動出力装置などの出力手段から選択される少なくとも１つを含んでもよい。

【0116】

上述のプロセッサ１１００は、メモリ１２００及び記憶装置１６００のうち少なくとも１つに格納されたプログラム命令（ｐｒｏｇｒａｍ ｃｏｍｍａｎｄ）やプログラム命令を有するソフトウェアモジュールを実行してもよい。すなわち、プロセッサ１１００が実行されるとき、プログラム命令によってプロセッサ１１００は、図７ないし図９のいずれかに示すようなメッセージノード拡張方法を行うことができる。

【0117】

本実施形態によると、ＤｅｖＩｎｆｏフォーマットに対するデータフォーマットに基づいて自律走行車両などの車両に搭載されたＤＭクライアントの各ソフトウェアのアップデート状態を確認し、アップデートが必要なソフトウェアのためのソフトウェアファイルのみ選択的にＤＭクライアントに送信することができ、それによってデータ容量及び通信コストを削減することができると共に、ソフトウェア全体をアップデートする場合に比べて、アップデートに必要な遅延時間を大幅に短縮でき、ＯＴＡアップデートの効率性を大きく向上させることができる。

【0118】

一方、上述のメッセージノード拡張方法は、アップデート情報提供方法と称されてもよい。これと同様に、上述のメッセージノード拡張装置は、アップデート情報提供装置と称されてもよい。

【0119】

本発明の実施形態による方法の動作は、コンピュータで読み取り可能な記録媒体にコンピュータが読み取り可能なプログラム又はコードとして実現することが可能である。コンピュータが読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能な情報が記憶されるすべての種類の記録装置を含む。またコンピュータが読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なプログラム又はコードが記憶されて実行可能である。

【0120】

また、コンピュータが読み取り可能な記録媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）などのようにプログラム命令を記憶して実行するように特に構成されたハードウェア装置を含んでもよい。プログラム命令は、コンパイラー（ｃｏｍｐｉｌｅｒ）によって作成されるような機械語コードだけでなく、インタプリタ（ｉｎｔｅｒｐｒｅｔｅｒ）などを用いてコンピュータによって実行することができる高級言語コードを含んでもよい。

【0121】

本発明の一部の態様は装置に関連して説明されたが、それに対応する方法に応じた説明も示すことができ、この場合ブロック又は装置は方法のステップ又は方法のステップの特徴に対応する。同様に、方法に関連して説明された態様は、また対応するブロック又は装置、或いは対応する装置の特徴として示すことができる。方法のステップの一部又は全部は、例えば、マイクロプロセッサ、プログラム可能なコンピュータ又は電子回路のようなハードウェア装置によって（又は用いて）行われてもよい。一部の実施形態では、最も重要な方法のステップの少なくとも１つ以上は、このような装置によって行われてもよい。

【0122】

実施形態において、プログラム可能なロジック装置（例えば、フィールドプログラマブルゲートアレイ）を本明細書に説明された方法の機能の一部又は全部を行うために用いることができる。実施形態において、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）は、本明細書に説明された方法のうちいずれかを行うためのマイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）と共に作動することができる。一般に、方法はあるハードウェア装置によって行われることが好ましい。

【0123】

以上、本発明の好ましい実施形態を参照して説明したが、該当の技術分野の熟練した当業者であれば、下記の特許請求の範囲に記載の本発明の思想及び領域から逸脱しない範囲内で本発明を多様に修正及び変更可能なことを理解することができるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】