特開 2024-131791 ソフトウェア更新装置及びシステム

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

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

(11)【公開番号】P2024131791

(43)【公開日】2024-09-30

(54)【発明の名称】ソフトウェア更新装置及びシステム

(51)【国際特許分類】

   G06F 8/65 20180101AFI20240920BHJP

   B60R 16/02 20060101ALI20240920BHJP

【ＦＩ】

G06F8/65

B60R16/02 660U

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023042256

(22)【出願日】2023-03-16

(71)【出願人】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】ロペス ハイロ

(72)【発明者】

【氏名】堀田 勇樹

(72)【発明者】

【氏名】片岡 幹雄

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

5B376

【Ｆターム（参考）】

5B376CA47

5B376DA28

5B376FA13

5B376GA07

(57)【要約】

【課題】ターゲットシステムのソフトウェアユニットを別のユニットに変更する際に、ユーザアプリケーションデータを維持できるようにするか、少なくともソフトウェアユニットの変更後にデータが失われる可能性があることを認識可能なソフトウェア更新装置及びシステムを提供する。
【解決手段】ソフトウェア更新装置は、アプリケーションのデータバージョンを変更する際にアプリケーションのユーザデータを含むデータのデータ形式を変換する変換機能を記憶する記憶部と、アプリケーションの変更の要求に適合する変換機能を取得する変換機能取得部と、受信した変換機能を用いて、アプリケーションのデータ形式を所望のデータ形式へ変換するデータ変換部と、を備え、データ変換部は、アプリケーション変更時に変換機能の有無に応じてアプリケーションのユーザデータに対する処理を変更する。
【選択図】図２

【特許請求の範囲】

【請求項1】

アプリケーションのデータバージョンを変更する際に前記アプリケーションのユーザデータを含むデータのデータ形式を変換する変換機能を記憶する記憶部と、
前記アプリケーションの前記変更の要求に適合する前記変換機能を取得する変換機能取得部と、
受信した前記変換機能を用いて、前記アプリケーションの前記データ形式を所望のデータ形式へ変換するデータ変換部と、を備え、
前記データ変換部は、前記アプリケーションの変更時に前記変換機能の有無に応じて前記アプリケーションの前記ユーザデータに対する処理を変更する、
ことを特徴とするソフトウェア更新装置。

【請求項2】

請求項１に記載のソフトウェア更新装置であって、
前記アプリケーションに前記変更を適用した後、前記アプリケーションのデータバージョンをロールバックするロールバック管理部をさらに備え、
前記データ変換部は、前記ロールバックにおいて前記アプリケーションのデータ形式を前記所望のデータ形式に変換する、
ことを特徴とするソフトウェア更新装置。

【請求項3】

請求項２に記載のソフトウェア更新装置であって、
前記データ変換部は、前記変換機能が存在するとき、前記変換機能により前記ユーザデータの前記データ形式を変換し、前記変換機能が存在しないとき、前記ユーザデータのデータ形式を変換せず前記アプリケーションの無効化および前記ロールバックの停止を行う、または、ユーザの許可に基づき前記ユーザデータを削除し前記ロールバックを実行する、
ことを特徴とするソフトウェア更新装置。

【請求項4】

アプリケーションのデータバージョンを変更する際に前記アプリケーションのデータ形式を変換する変換機能を記憶する記憶部と、
前記アプリケーションの前記変更の要求に適合する前記変換機能を取得するデータ変換部と、を備え、
前記データ変換部は、前記データ形式を所望のデータ形式へ変換する前記変換機能の有無に応じて前記アプリケーションが搭載された電子装置への前記変換機能の送信の要否を決定する、
ことを特徴とするソフトウェア更新装置。

【請求項5】

請求項４に記載のソフトウェア更新装置であって、
前記変換機能が存在しないとき、前記アプリケーションのユーザデータの損失に関する情報を出力する通知部をさらに備える、
ことを特徴とするソフトウェア更新装置。

【請求項6】

請求項４に記載のソフトウェア更新装置であって、
前記変換機能が存在しないとき、前記アプリケーションを変更せずに該アプリケーションを無効化する無効化部をさらに備える、
ことを特徴とするソフトウェア更新装置。

【請求項7】

請求項６に記載のソフトウェア更新装置であって、
前記無効化部は、前記変換機能の有無に関わらず、ユーザの選択によって前記アプリケーションの無効化の要否を決定する、
ことを特徴とするソフトウェア更新装置。

【請求項8】

請求項４に記載のソフトウェア更新装置であって、
前記記憶部は、前記アプリケーションの更新データを配信するサーバから受信した過去に使用した変換機能を保持し、
前記データ変換部は、前記アプリケーションの前記変更に必要な変換機能を示す更新可能なテーブルを有する、
ことを特徴とするソフトウェア更新装置。

【請求項9】

請求項８に記載のソフトウェア更新装置であって、
前記データ変換部は、前記変換機能を取得できないとき、前記サーバに前記変換機能の送信を要求する、
ことを特徴とするソフトウェア更新装置。

【請求項10】

サーバと少なくとも一つの車載装置を備えるソフトウェア更新システムであって、
前記サーバは、前記車載装置に搭載されたアプリケーションのデータバージョンを変更する際に前記アプリケーションのユーザデータを含むデータのデータ形式を変換する変換機能を含む更新パッケージを前記車載装置に配信し、
前記少なくとも一つの車載装置は、
前記サーバから受信した前記変換機能を記憶する記憶部と、
前記アプリケーションの前記変更の要求に適合する前記変換機能を取得する変換機能取得部と、
前記変換機能取得部から前記変換機能を取得し、前記データ形式を所望のデータ形式へ変換するデータ変換部と、
前記アプリケーションに前記変更を適用した後、前記アプリケーションのデータバージョンをロールバックするロールバック管理部と、を備え、
前記データ変換部は、前記ロールバックにおいて前記アプリケーションのユーザデータも含めて前記データ形式を前記所望のデータ形式に変換し、前記アプリケーションの変更時に前記変換機能の有無に応じて前記ユーザデータに対する処理を変更する、
ことを特徴とするソフトウェア更新システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ターゲットシステムのライフサイクル中に行われるソフトウェア変更にかかわらず、ユーザアプリケーションデータがターゲットシステム上で継続的に有用であることをコンポーネントが保証することが可能なソフトウェア更新装置及びシステムに関する。

【背景技術】

【0002】

ソフトウェアは、消費者や車両提供者毎にパーソナライズされた拡張機能を提供するために、従来の機能安全領域でますます多用されている。これらの機能は、ユーザが生成したアプリケーションデータを使用することでますます活用されている。自動車分野では、ここ数年、自動運転支援システム（ＡＤ：Ａｕｔｏｎｏｍｏｕｓ Ｄｒｉｖｉｎｇ Ｓｙｓｔｅｍ）と同様に、アダプティブクルーズコントロール(ＡＣＣ：Ａｄａｐｔｉｖｅ Ｃｒｕｉｓｅ Ｃｏｎｔｒｏｌ)、自動緊急ブレーキ(ＡＥＳ：Ａｕｔｏｍａｔｉｃ Ｅｍｅｒｇｅｎｃｙ Ｓｔｅｅｒｉｎｇ)、自動駐車(ＡＰ：Ａｕｔｏｍａｔｉｃ Ｐａｒｋｉｎｇ)、及び先進運転支援システム(ＡＤＡＳ：Ａｄｖａｎｃｅｄ Ｄｒｉｖｉｎｇ Ａｓｓｉｓｔａｎｔ Ｓｙｓｔｅｍ)等のソフトウェアベースの機能をより適切にパーソナライズするために、ユーザアプリケーションデータの使用が増加している。

【0003】

これらの機能が導入されている車両は増加し続けており、自動車メーカーが競合他社との差別化を図る必要性から、特定のユーザが慣れ親しんだパーソナライズされたユーザエクスペリエンスを継続的かつシームレスに維持または改善する必要がある。ユーザアプリケーションデータの長期的なメンテナンスは、パーソナライズされたユーザエクスペリエンスを実現する上で大きな役割を果たすことになる。

【0004】

多くの機能安全分野では、安全要件はほぼ確立されており、ソフトウェアの複雑化が進んでも容易に検査できる。しかし、ソフトウェア関連のエラーは製品の販売後に発見され、その都度修正される。自動車分野では、ソフトウェア関連のエラーは多くの車両の主要な機能に直接影響を及ぼし、自動車供給者のサービス停止を引き起こし、ユーザ経験の質を低下させる可能性を高める。この点に関して、２０１９年に生じた車両のリコールの半数がソフトウェアベースの欠陥に関係していた。

【0005】

４Ｇおよび５Ｇ携帯電話技術によるユビキタス接続の台頭、および多くの家庭でのＷｉ－Ｆｉ（登録商標）と組み合わせたより高い帯域幅のインターネットの使用の増加により、Ｆｉｒｍｗａｒｅ Ｏｖｅｒ Ｔｈｅ Ａｉｒ（ＦＯＴＡ）およびＳｏｆｔｗａｒｅ Ｏｖｅｒ ｔｈｅ Ａｉｒ（ＳＯＴＡ）によるソフトウェアの更新が可能になった。そして、これらの更新メカニズムにより、デバイスの製造元は、デバイスを製造元に返送することなくソフトウェアを更新することが可能になった。この技術は、主に次の２つの理由から、自動車分野において非常に重要である。

【0006】

まず、ＦＯＴＡ／ＳＯＴＡソリューションでは、ほとんどの機能がソフトウェア対応であるため、ユーザは最新の機能を利用できる。次に、ユーザはＦＯＴＡ／ＳＯＴＡソリューションを使用して最新の修正プログラムを取得し、車両が正しく機能するように修正することが可能である。これらを実行するための唯一の要件は、インターネットに接続可能なことである。特に自動車分野では、あらゆる種類のソフトウェア更新は、従来、ユーザが自動車販売店などの場所に物理的に行くことによって行われてきた。これは、製造業者にとってロジスティクス上の負担であり、消費者のユーザエクスペリエンスにとっても懸念事項であった。

【0007】

ＦＯＴＡ／ＳＯＴＡ技術を使用している場合でも、複雑なソフトウェアが実装されたデバイスの更新時にソフトウェア関連のエラーが発生する可能性がある。このような場合、更新対象のソフトウェアは複雑であるため、問題の解決に数週間かかる場合がある。特に、更新されるデバイスが政府機関によって規制される車両である自動車分野の場合、更新を実行するための認証と許可が必要であり、最終ユーザが更新を完了するためにさらなる時間を要する。

【0008】

これらの特定のケースでは、ユーザエクスペリエンスに重点を置いた解決方法は、既知の安全でセキュアなアプリケーションバージョンにロールバックすることである。しかしながら自動車分野では、パーソナライズされたユーザエクスペリエンスがますます重要になっているため、アプリケーションをロールバックするだけでは十分ではなく、ユーザアプリケーションデータも維持され、可能な限り使用可能であることを保証する必要がある。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０１０－２８７０５５号公報

【特許文献2】特開２００５－３３２３０１号公報

【特許文献3】特開２００５－３０９５４８号公報

【発明の概要】

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

【0010】

本発明は、ターゲットシステムのソフトウェアユニットを別のユニットに変更する際に、ユーザアプリケーションデータを維持できるようにするか、少なくともソフトウェアユニットの変更後にデータが失われる可能性があることを認識可能なソフトウェア更新装置及びシステムを提供することを目的とする。

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

【0011】

上記の課題を解決するために、本発明に係るソフトウェア更新装置は、アプリケーションのデータバージョンを変更する際にアプリケーションのユーザデータを含むデータのデータ形式を変換する変換機能を記憶する記憶部と、アプリケーションの変更の要求に適合する変換機能を取得する変換機能取得部と、受信した変換機能を用いて、アプリケーションのデータ形式を所望のデータ形式へ変換するデータ変換部と、を備え、データ変換部は、アプリケーション変更時に変換機能の有無に応じてアプリケーションのユーザデータに対する処理を変更する。

【発明の効果】

【0012】

本発明によれば、ターゲットシステムのソフトウェアユニットを別のユニットに変更する際に、ユーザアプリケーションデータを維持できるようにするか、少なくともソフトウェアユニットの変更後にデータが失われる可能性があることを認識可能なソフトウェア更新装置及びシステムを提供することが可能になる。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0013】

【図1】本発明に係るソフトウェア更新装置が適用されるソフトウェア更新システムの全体構成を示す概略ブロック図。

【図2】ターゲットシステムＶ１０００の構成を示す機能ブロック図。

【図3】データ変換管理ユニットＸＹＺ３００の構成を示す機能ブロック図。

【図4】データ変換ユニットＸＹＺ３２０の構成を示す機能ブロック図。

【図5】ＯＴＡセンターＣ１０００の構成を示す機能ブロック図。

【図6】ロールバック用の画面Ｉ１２００を提示するインフォテインメントシステムＩ１０００の構成を示す機能ブロック図。

【図7】更新用の画面Ｉ１３００を提示するインフォテインメントシステムＩ１０００の構成を示す機能ブロック図。

【図8】置換用の画面Ｉ１４００を提示するインフォテインメントシステムＩ１０００の構成を示す機能ブロック図。

【図9】ソフトウェアユニットＵＸ０００の構成を示す機能ブロック図。

【図10】通知Ｎ１０００の構成を示す機能ブロック図。

【図11】ソフトウェア更新装置が実行する処理を示すフローチャート。

【図12】ソフトウェア保存部を更新する処理を示すフローチャート。

【図13】ターゲットデバイスによる通知処理を示すフローチャート。

【図14】更新のデータ変換処理を示すフローチャート。

【図15】アプリケーションデータの更新処理を示すフローチャート。

【図16】アプリケーションデータの変換処理を示すフローチャート。

【図17】アプリケーションの無効化処理を示すフローチャート。

【図18】データ変換管理ユニットのエントリが有効である場合のアプリケーション変換処理を示すフローチャート。

【図19】データ変換が失敗した場合のロールバック処理を示すフローチャート。

【図20】アプリケーションのロールバック／置換中のアプリケーションデータ変換処理を示すフローチャート。

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

【0014】

［実施例１］
以下に、本発明の一実施例について図面を用いて説明する。図１は、本発明の一実施例に係るソフトウェア更新装置が適用されるソフトウェア更新システム全体の構成要素を示す図である。ソフトウェア更新システムは、ターゲットシステムＶ１０００、これと所定の通信システムを介して接続されるＯＴＡセンターＣ１０００（図５に詳述）を有する。ＯＴＡセンターＣ１０００は通知Ｎ１０００（図１０に詳述）を介して必要なソフトウェアをターゲットシステムＶ１０００に転送可能である。図２に詳述されるターゲットシステムＶ１０００は、特定の機能を実行するために、別個のデバイスである場合もある情報処理ユニットで構成される任意のシステムである。

【0015】

図２は、ターゲットシステムＶ１０００の構成を示すブロック図である。ターゲットシステムＶ１０００は、それぞれが独自のソフトウェアを持つ複数のデバイスで構成できるシステムである。ターゲットシステムＶ１０００は、ユーザとシステム間とのインターフェイスを提供するインフォテインメントシステムＩ１０００、ソフトウェアの変更、ユーザアプリケーションのデータ変換、システムのロールバック機能を提供するソフトウェア更新装置Ｅ１０００、およびターゲットシステムＶ１０００によって提供される機能を実装する任意の数のＥＣＵ ＥＸ０００によって構成される。

【0016】

インフォテインメントシステムＩ１０００は、図６にブロック図として示されている。システムは、ターゲットシステムＶ１０００内のコンポーネントと通信するための内部ネットワークユニットＩ１１００、外部デバイスと通信するためのネットワークユニットＩ１３００、およびユーザに情報を表示し、ユーザから情報を受け取るためのユーザインターフェイスとしての画面によって構成される。ソフトウェアユニットの変更のタイプに応じて、画面上に表示される情報が変わる。図６はソフトウェアユニットのロールバックの例として画面Ｉ１２００を示し、図７はソフトウェアユニットの更新の例として画面Ｉ１３００を示し、図８はソフトウェアユニットの置換の例として画面Ｉ１４００を示している。

【0017】

ソフトウェア更新装置Ｅ１０００の構成を図２に示す。ソフトウェア更新装置Ｅ１０００は、ターゲットシステムＶ１０００の外部のネットワークアクセスを許可するネットワークユニットＥ１１０００、ターゲットシステムＶ１０００内のネットワークアクセスを許可する内部ネットワークユニットＥ１２０００、ターゲットシステムＶ１０００内のソフトウェアユニットの変更を担う更新制御ユニットＥ１４０００、初期ソフトウェアユニット管理ユニットＥ１５０００、およびロールバック管理ユニットＥ１６０００を有する。初期ソフトウェアユニット管理ユニットＥ１５０００は、ターゲットシステムＶ１０００内にインストールされているソフトウェアユニットと、それが実行されているＥＣＵ ＥＸ０００の追跡を担当する。

【0018】

初期ソフトウェアユニット管理ユニットＥ１５０００はさらに、ソフトウェアユニット保存部Ｅ１５２００を有する。この保存部には、ターゲットシステムＶ１０００のライフサイクルの後半で使用される可能性のあるソフトウェアユニットＥ１５３ＸＸと、ターゲットシステムＶ１０００のライフサイクル中に使用される可能性のあるあらゆる形式のファイルが格納される。ロールバック管理ユニットＥ１６０００は、通知Ｎ１０００の処理を担当する。このユニットは、通知Ｎ１０００を直接処理する通知管理ユニットＥ１６１００と、初期ソフトウェアユニット管理ユニットＥ１５０００およびＥＣＵ ＥＸ０００固有のソフトウェア管理ユニットＥＸ２００と連携して特定のアプリケーションＥＸ４０Ｙを無効にしたい場合に信号を送信する場所を決定するアプリケーション無効化ユニットＥ１６２００を有する。このユニットには、特定のアプリケーションＥＸ４０Ｙで使用されるユーザアプリケーションデータの変換に関する情報の維持を担当するデータ変換管理ユニットＥ１６３００も含まれる。

【0019】

図３にデータ変換管理ユニットの詳細を示す。データ変換管理ユニットＸＹＺ３００は、アプリケーションデータ変換管理テーブルＸＹＺ３１０を有する。このテーブルは、特定のアプリケーションＥＸ４０Ｙで使用されるユーザアプリケーションデータの変換を許可するために必要な情報を示している。このテーブルは、アプリケーション名ＸＹＺ３１１（ＥＣＵ ＥＸ０００内の特定のバイナリを識別する固有の名前）、バイナリの作成者が指定したバージョンであるバージョンＸＹＺ３１２、バイナリによって格納されたユーザアプリケーションデータの作成者が指定したバージョンであるアプリケーションデータバージョンＸＹＺ３１３、アプリケーション名ＸＹＺ３１１が変換される宛先の固有の名前である変換宛先アプリケーション名ＸＹＺ３１４、変換された宛先のバージョンである変換宛先アプリケーションバージョンＸＹＺ３１５、アプリケーション名ＸＹＺ３１１が変換される宛先バイナリに対して作成者が指定したバージョンである変換宛先データバージョンＸＹＺ３１６、ユーザアプリケーションデータの物理的な変換を可能にする関数の固有の名前である変換関数ＸＹＺ３１７、および変換関数ＸＹＺ３１７にアクセスできる位置を通知するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）である変換関数ロケーションＸＹＺ３１８から構成される。

【0020】

バイナリバージョンの違いにより、ユーザアプリケーションデータの変換が必要になる場合があるため、変換宛先アプリケーション名ＸＹＺ３１４がアプリケーション名ＸＹＺ３１１と同じである可能性がある。同様に、異なるバイナリが同一のユーザアプリケーションデータを使用する可能性があるため、バージョンＸＹＺ３１２と変換宛先データバージョンＸＹＺ３１６も同一になり得る。変換関数ロケーションＸＹＺ３１８は、その実装に制限はない。この情報は、ユーザアプリケーションのデータ変換を完了できる別のツール、バイナリ、またはＡＰＩにつながる可能性がある。データ変換管理ユニットＥ１６３００には、図４に示す、データ変換リソースユニットＸＹＺ３２１とコンポーネントを介して特定のシステムでユーザアプリケーションのデータ変換を実行できるかどうかを判断するためにリソースを追跡するデータ変換ユニットＸＹＺ３２０及びデータ変換実行ユニットＸＹＺ３２２を介して、特定のシステムでユーザアプリケーションのデータ変換を実行することを担当する構成要素も含まれる。データ変換ユニットＸＹＺ３２０には、システム内のアプリケーションＥＸ４０Ｙによって使用されているユーザアプリケーションデータを追跡するテーブルであるデータロケーションユニットＸＹＺ３２３も含まれる。

【0021】

ＥＣＵ ＥＸ０００は、ソフトウェアユニットＵＸ０００を介してインストールされた、ターゲットシステムＶ１０００の機能を実装する任意の数のアプリケーションＥＸ４０Ｙ、ＥＣＵ ＥＸ０００上のソフトウェアユニットＵＸ０００を追跡するソフトウェア管理ユニットＥＸ２００、およびターゲットシステムＶ１０００内の構成要素間を接続するネットワークユニットＥＸ１００から構成される。ＥＣＵ ＥＸ０００には、ソフトウェア更新装置Ｅ１０００にあるコンポーネントを模倣するローカルデータ変換ユニットＥＸ３００を含めることもできる。

【0022】

ＯＴＡセンターＣ１０００の詳細を図５に示す。ＯＴＡセンターＣ１０００には、ターゲットシステムＶ１０００上のソフトウェアインストールを変更するために必要な情報と認証が含まれる。ＯＴＡセンターＣ１０００は、ターゲットシステムＶ１０００と通信してシステムを変更するための情報を提供するために使用されるネットワークユニットＣ１１００、ターゲットシステムＶ１０００上のソフトウェアを変更するために使用されるソフトウェアユニットＵＸ０００を格納するために使用されるソフトウェアユニット保存部Ｃ１２００、ターゲットシステムＶ１０００の情報を維持するために使用されるターゲットシステム管理部Ｃ１３０００、必要な通知Ｎ１０００およびソフトウェアユニットＵＸ０００をターゲットシステムＶ１０００に送信するソフトウェアユニット配布部Ｃ１４００、通知Ｎ１０００を作成する通知ユニットＣ１５００、及び特定のアプリケーションＥＸ４０Ｙで使用されるユーザアプリケーションデータの変換に関する情報の維持を担当するデータ変換管理ユニットＣ１６００から構成される。

【0023】

ターゲットシステム管理部Ｃ１３０００は、ターゲットシステムＣ１３Ｘ００のリストによって構成される。各エントリには、システムＩＤ Ｃ１３Ｘ１０、ターゲットシステムＶ１０００の一意の識別子、システムソフトウェア情報Ｃ１３Ｘ２０、及びターゲットシステムＶ１０００およびその論理的または物理的な内部コンポーネント内で使用されているソフトウェアユニットに関する詳細情報に関する情報が含まれる。

【0024】

通知Ｎ１０００の詳細を図１０に示す。通知Ｎ１０００は、ターゲットシステムＶ１０００がシステムのソフトウェア変更要求を正しく処理できるように、ＯＴＡセンターＣ１０００からターゲットシステムＶ１０００に情報を送信するために使用されるフォーマットである。具体的には、通知Ｎ１０００は、ソフトウェアユニットＵＸ０００をターゲットシステムＶ１０００の初期ソフトウェアユニット管理ユニットＥ１５０００およびリンクされたソフトウェア管理ユニットＥＸ２００に転送して処理する。通知Ｎ１０００は、送信される通知のタイプを決定する通知タイプＮ１１００、通知を認証するためにターゲットシステムＶ１０００によって使用される認証情報Ｎ１３００、および通知にリンクされたソフトウェアユニットＵＸ０００であるユニットＮ１５００で構成される。

【0025】

ソフトウェアユニットＵＸ０００は、ターゲットシステムＶ１０００にインストールされたソフトウェアを変更するために必要な情報を送信するために、ソフトウェアユニット保存部および通知Ｎ１０００で使用されるフォーマットである。このフォーマットに従って、ターゲットシステムＶ１０００内でユーザアプリケーションのデータ変換を追跡できるコンポーネントを作成する。本発明では、ソフトウェアユニットＵＸ０００が図９に示されている。

【0026】

ソフトウェアユニットＵＸ０００には、ソフトウェアの一般名であるアプリケーション名ＵＸ１００、バイナリおよびソースコードへの通常の変更を通知するために使用されるバージョニングスキームであるバージョンＵＸ２００、ターゲットシステムＶ１０００内の指定されたバイナリを置き換えるために使用されるバイナリデータを実質的に含むバイナリデータＵＸ３００、ユーザアプリケーションデータが収集および保存される方法に対する通常の変更を通知するために使用されるバージョニングスキームであるアプリケーションデータバージョンＵＸ４００、ソフトウェアユニット内においてデータ変換を行うべきであることを通知するフラグである変換試行部ＵＸ５００、関連するソフトウェアユニットを無効にする必要があることを通知するフラグである無効化部ＵＸ６００、およびユーザアプリケーションのデータ変換に関連する情報を含む０個以上のデータ変換部ＵＸＹ００が含まれる。

【0027】

データ変換部ＵＸ７００には、ユーザアプリケーションデータが変換された後に使用される共通アプリケーション名を決定する変換アプリケーション名ＵＸ７１０、共通アプリケーション名のバージョンを決定する変換アプリケーションバージョンＵＸ７２０、現在のデータが変換されるアプリケーションデータバージョンである変換データバージョンＵＸ７３０、ユーザアプリケーションデータ変換を許可する関数の一般名である変換関数ＵＸ７４０及びデータ変換を可能にする関数へのアクセスを与えるＵＲＩである変換関数ロケーションＵＸ７５０を含む。

【0028】

通知Ｎ１０００で使用されているソフトウェアユニットの場合、バイナリデータＵＸ３００は、通知タイプＮ１１００がその使用を要求する場合にのみ含まれる。これはそのデータ含有はデータ伝送の際の不必要なコストをもたらしうるからである。フラグである変換試行部ＵＸ５００および無効化部ＵＸ６００も、通知タイプＮ１１００がその使用を要求した場合にのみ使用される。データ変換部ＵＸＹ００を使用する場合、アプリケーション名ＵＸ１００、バージョンＵＸ２００、およびアプリケーションデータバージョンＵＸ４００が含まれている必要がある。

【0029】

実施例１において、特定のソフトウェアユニットが修正を必要とするという通知Ｎ１０００を取得するＯＴＡセンターＣ１０００が実行する処理を図１１に示す。必要な通信技術を使用して、通知はＯＴＡセンターＣ１０００、具体的には通知ユニットＣ１５００によって受信される（ステップＳ１０００）。この時点で、通知ユニットＣ１５００は、通知タイプＮ１１００が更新（ステップＳ１１００）、置換（ステップＳ１２００）、またはロールバック（ステップＳ１３００）のうちいずれかであるかを判断する。通知タイプＮ１１００が更新または置換であった場合にはＯＴＡセンターＣ１０００は、そのソフトウェアユニット保存部Ｃ１２００を更新しなければならない。通知タイプＮ１１００がロールバックの場合には、ソフトウェアユニット保存部Ｃ１２００の更新はスキップされる。

【0030】

ソフトウェアユニット保存部Ｃ１２００の更新には、図１２に示すフローが使用される。通知Ｎ１０００内のソフトウェアユニットＵＸ０００は、通知ユニットＣ１５００によって抽出され、ソフトウェアユニット保存部Ｃ１２００に転送される（ステップＳ１４１０）。ソフトウェアユニット保存部Ｃ１２００では、ソフトウェアユニットＵＸ０００のアプリケーション名ＵＸ１００、バージョンＵＸ２００、アプリケーションデータバージョンＵＸ４００、変換試行部ＵＸ５００、無効化部ＵＸ６００、および使用可能なデータ変換部ＵＸＹ００が抽出され、抽出された情報は、ソフトウェアユニット保存部Ｃ１２００で既に利用可能な情報と比較するために使用される（ステップＳ１４２０）。

【0031】

ステップＳ１４２０でソフトウェアユニットＵＸ０００のバージョンＵＸ２００が見つからない場合、すなわちステップＳ１４３０で“Ｎｏ”の場合には、ソフトウェアユニットＵＸ０００がソフトウェアユニット保存部Ｃ１２００に格納される（ステップＳ１４４０）。ソフトウェアユニットＵＸ０００のアプリケーション名ＵＸ１００、バージョンＵＸ２００、アプリケーションデータバージョンＵＸ４００、およびデータ変換部ＵＸＹ００に関する情報は、そのような情報がアプリケーションデータ変換管理テーブルＸＹＺ３１０に既にあるかどうかのチェックに使用される（ステップＳ１４５０）。テーブルＸＹＺ３１０に情報がない場合には、後で使用するために情報がテーブルに追加される（ステップＳ１４６０）。

【0032】

図１１のフローチャート中通知タイプＮ１１００がロールバックである場合には、ＯＴＡセンターＣ１０００のターゲットシステム管理部Ｃ１３０００が内部構造を検索し、ユニットＮ１５００で見つかったソフトウェアユニットを使用するシステムを見つけることによってシステムソフトウェア情報Ｃ１３Ｘ２０を取得する。この検索から、ＯＴＡセンターＣ１０００は、通知Ｎ１０００が配布されなければならないターゲットシステムＣ１３Ｘ００のリストを取得する（ステップＳ１５００）。

【0033】

この情報はソフトウェアユニット配布部Ｃ１４００に渡される。ソフトウェアユニット配布部Ｃ１４００はリストを使用して必要な通知Ｎ１０００、特に通知ユニットＮ１５００で使用されるソフトウェアユニットを作成する。これは、各ターゲットシステムＶ１０００が、特定の変更に必要な追加のソフトウェアユニットまたは追加の認証を行うために異なる構成を持つ可能性があるためである（ステップＳ１６００）。通知Ｎ１０００が作成されると、ＯＴＡセンターＣ１０００のネットワークユニットＣ１１００を介して対応するターゲットシステムＣ１３Ｘ００に通知Ｎ１０００が送信される（ステップＳ１７００）。

【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】

（２）アプリケーションに変更を適用した後、アプリケーションのデータバージョンをロールバックするロールバック管理部をさらに備え、データ変換部は、ロールバックにおいてアプリケーションのデータ形式を所望のデータ形式に変換する。これにより、ロールバックの際にデータが削除されてしまうことを防止できる。

【0075】

（３）データ変換部は、変換機能が存在するとき、変換機能によりユーザデータのデータ形式を変換し、変換機能が存在しないとき、ユーザデータのデータ形式を変換せずアプリケーションの無効化およびロールバックの停止を行う、または、ユーザの許可に基づきユーザデータを削除しロールバックを実行する。これにより、変換機能の有無によってデータの取り扱い方法を変更することが可能になり、柔軟な対応が期待できる。

【0076】

（４）また、本発明の他の実施例に係るソフトウェア更新装置は、アプリケーションのデータバージョンを変更する際にアプリケーションのデータ形式を変換する変換機能を記憶する記憶部と、アプリケーションの変更の要求に適合する変換機能を取得するデータ変換部と、を備え、データ変換部は、データ形式を所望のデータ形式へ変換する変換機能の有無に応じてアプリケーションが搭載された電子装置への変換機能の送信の要否を決定する。

【0077】

上記構成により、（１）と同様に、ターゲットシステムのソフトウェアユニットを別のユニットに変更する際に、ユーザアプリケーションデータを維持できるようにするか、少なくともソフトウェアユニットの変更後にデータが失われる可能性があることを認識することが可能になる。

【0078】

（５）変換機能が存在しないとき、アプリケーションのユーザデータの損失に関する情報を出力する通知部をさらに備える。これにより、ユーザにその後の処理を選択させることが可能になる。

【0079】

（６）変換機能が存在しないとき、アプリケーションを変更せずに該アプリケーションを無効化する無効化部をさらに備える。これにより、無効化すべきアプリケーションを確実に無効化することが可能になる。

【0080】

（７）無効化部は、変換機能の有無に関わらず、ユーザの選択によってアプリケーションの無効化の要否を決定する。これにより、アプリケーションの無効化はユーザが選択することになり、例えば後で更新する可能性のあるアプリケーションは無効化させずに保存しておく等の対応が可能になる。

【0081】

（８）記憶部は、アプリケーションの更新データを配信するサーバから受信した過去に使用した変換機能を保持し、データ変換部は、アプリケーションの変更に必要な変換機能を示す更新可能なテーブルを有する。これにより、上述した機能を容易かつ迅速に発揮することが可能になる。

【0082】

（９）データ変換部は、変換機能を取得できないとき、サーバに変換機能の送信を要求する。これにより、変換機能の未受信によるアプリケーションの変換忘れを防止することが可能になる。

【0083】

（１０）さらに本発明の他の実施例に係るソフトウェア更新システムは、サーバと少なくとも一つの車載装置を備えるソフトウェア更新システムであって、サーバは、車載装置に搭載されたアプリケーションのデータバージョンを変更する際にアプリケーションのユーザデータを含むデータのデータ形式を変換する変換機能を含む更新パッケージを車載装置に配信し、少なくとも一つの車載装置は、サーバから受信した変換機能を記憶する記憶部と、アプリケーションの変更の要求に適合する変換機能を取得する変換機能取得部と、データ変換部から変換機能を取得し、データ形式を所望のデータ形式へ変換するデータ変換部と、アプリケーションに変更を適用した後、アプリケーションのデータバージョンをロールバックするロールバック管理部と、を備え、データ変換部は、ロールバックにおいてアプリケーションのユーザデータも含めてデータ形式を所望のデータ形式に変換し、アプリケーション変更時に変換機能の有無に応じてユーザデータに対する処理を変更する。

【0084】

上記構成により、（１）と同様に、ターゲットシステムのソフトウェアユニットを別のユニットに変更する際に、ユーザアプリケーションデータを維持できるようにするか、少なくともソフトウェアユニットの変更後にデータが失われる可能性があることを認識することが可能になる。

【0085】

なお、本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、上記の実施例は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備える態様に限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能である。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、削除したり、他の構成を追加・置換したりすることが可能である。

【符号の説明】

【0086】

Ｃ１０００ ＯＴＡセンター（ソフトウェア管理システム）、Ｃ１２００ ソフトウェアユニット保存部（記憶部）、Ｃ１５００ 通知ユニット（通知部）、Ｅ１６０００ ロールバック管理ユニット（ロールバック管理部）、ＥＸ０００ ＥＣＵ（車載装置）、ＵＸ５００ 変換試行部（変換機能取得部）、ＵＸ６００ 無効化部、ＵＸ７００ データ変換部、ＵＸ７４０ 変換関数（変換機能）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】