JP6852148B2

JP6852148B2 - ソフトウェアアップデートシステム、ファームウェアオーバーザエアーアップデートシステム、及び、クライアントデバイスをアップデートする方法

Info

Publication number: JP6852148B2
Application number: JP2019512904A
Authority: JP
Inventors: デイビッド、オコナー; ロバート、ヤマグチ; ジースハン、マフムード; ジャネル、ポールソン; サビー、ザファル、ウッラ
Original assignee: U Blox AG
Current assignee: U Blox AG
Priority date: 2016-09-14
Filing date: 2016-09-14
Publication date: 2021-03-31
Anticipated expiration: 2036-09-14
Also published as: CN109690478A; WO2018050216A1; JP2019535060A; US20180074808A1; CN109690478B; US10101990B2; EP3513282A1

Description

本発明は、例えば、クライアントデバイスに非オペレーティングシステム（ＯＳ：Operating System）アップデートを伝達することができるクライアントアップデートサーバを備えるタイプのソフトウェアアップデートシステムに関する。また、本発明は、例えば、クライアントデバイスに非ＯＳアップデートを伝達することができるクライアントアップデートサーバを備えるタイプのエアーアップデートシステムにおけるファームウェアに関する。さらに、本発明は、クライアントデバイスをアップデートする方法に関し、例えば、クライアントデバイスに非ＯＳアップデートを伝達するクライアントアップデートサーバを備えるタイプの方法に関する。

無線通信の分野では、いくつかの応用分野においては、いわゆるファームウェアオーバーザエアー（ＦＯＴＡ：Firmware Over-The-Air）システムを提供することが知られている。ＦＯＴＡシステムは、アップデートシステムにおける通信可能なデバイスを、最新のファームウェアバージョンにアップデートされた状態に維持するために使用される。オーバーザエアーアップデートアプローチでは、通信機能を備えたデバイスを、サーバ、例えば専用のファームウェアをアップデートするサーバとの無線接続を使用して、アップデートすることができる。したがって、デバイスは、アップデートや別のコンピューティング装置への物理的接続のために、それらを取り戻したり、回収したりする必要なしに、もとの場所のままでよい。しかしながら、多くの制約がオーバーザエアーアプローチに伴う。例えば、デバイスは通信という観点からターゲット到達可能である必要があり、適切なデータ転送速度が利用可能である必要があり、また、電池式のビーコンの場合のようにデバイスへの電源供給が適切である必要がある。

従って、デバイスへ送信されたアップデートは、アップデートサーバとデバイスとの間の接続に関する制限のある帯域幅を考慮して、及び、デバイスによって行なわれる通常のタスクと比較して、デバイスによる無線受信が比較的大量の電力を消費するという事実を考慮して、一般的には処理される。このため、アップデートは、例えば、含まれているデータ型に適したパッケージングアルゴリズムを使用してパッケージすることにより、処理することができる。しかしながら、これは、処理されたアップデートを受信するデバイスが、それを使用するために、データの処理を復元できなければならないという要求に結びつく。

さらに、アップデートシステムを使用するすべてのデバイスに共通のアップデートは、利用できないかもしれない。代わりに、デバイスのためのアップデートは、個別ベースでの要求となり得て、あるいは、１つを超えるデバイスのグループが、それぞれ異なるアップデートがそれらに適用されることを要求し得る。さらに、いくつかのシナリオでは、デバイスは、アップデートの目的のために、１つを超えるサーバによってアクセス可能になり得て、したがって、所定のデバイスのファームウェア構成は、単一のアップデートサーバの排他的な制御の下にはない。また、いくつかのデバイスについては、例えば、アップデートを適用するための別のコンピューティング装置にデバイスを拘束することにより、ローカルにファームウェアをアップデートすることが可能となる。

したがって、アップデートサーバ（以下に「コンテンツサーバ」と呼ぶ）は、所定のデバイス用のファームウェアのアップデートステータス及びバージョンを記録し、そして追跡するようにプログラムされる一方で、そのようなアプローチは、コンテンツサーバがアップデートする目的ためにデバイスにアクセスする、ただ一つのサーバであると仮定している。したがって、コンテンツサーバによって保持された情報が常に最新であるという仮定が存在する。同様に、コンテンツサーバからデバイスへのアップデート通信の目的のために、コンテンツサーバは、各デバイスあるいはデバイスのグループによりサポートされた処理の記録を維持することができる。これは、コンテンツサーバが、必ずしも所定のデバイスによって格納された処理へアクセスする、ただ一つの実体ではないからである。また、デバイスあるいはデバイスのグループが、別のサーバあるいは他の複数のサーバによってコントロールされることが可能であり、あるいは、それらは、アップデートのためにローカルにアクセスされることができる。これは、コンテンツサーバの検知の範囲外で、デバイスになされた変更を導くことになり得る。したがって、コンテンツサーバにサポートされた処理の記録は不正確になる。

そのような困難を克服するために、既存のデバイスアップデートプロシージャは、アップデートするサーバに利用可能で、アップデートされるデバイスにサポートされた処理テクニックを識別するために、アップデートされるデバイスに照会をすることをコンテンツサーバに要求することができ、この処理テクニックを、処理された形式で、デバイスのためのアップデートの伝達に、コンテンツサーバは使用することができる。しかしながら、既存のアップデートプロシージャは、共通の処理テクニックを見つけることができると仮定している。さらに、デバイスの問合せでは、デバイスにサポートされた処理テクニックに関するクエリーに応答して、デバイスはコンテンツサーバにデータを返信する必要があり、デバイスはそのために電力を消費する。

本発明の第１態様によれば、アップデートされる非ＯＳシステムソフトウェアを有するクライアントデバイスと、前記クライアントデバイスから遠隔に位置して、前記クライアントデバイスと通信可能なクライアントアップデートサーバと、前記クライアントデバイスに関するテクニカルケーパビリティデータにアクセスするように構成されたデバイスケーパビリティーマネージャーと、を備えるソフトウェアアップデートシステムであって、前記クライアントアップデートサーバは、前記クライアントデバイスの非ＯＳシステムソフトウェアの少なくとも一部をアップデートするのに必要な第１アップデートを検索するように構成されており、前記クライアントアップデートサーバは、前記デバイスケーパビリティーマネージャーと協働して、前記クライアントデバイスのアップデートを最適化するように、前記第１アップデートに適用する編制スキームを決定するように構成されたアップデートオプティマイザーを備えており、前記決定した編制スキームは、前記クライアントデバイスのテクニカルケーパビリティーと互換性を有しており、前記アップデートオプティマイザーは、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから、前記第１アップデートをリカバリーするリカバリーファンクションを識別するように構成されており、前記デバイスケーパビリティーマネージャーは、前記クライアントデバイスに求められる必要なファンクショナリティを決定するために前記ケーパビリティーデータを使用して、前記アップデートオプティマイザーによって識別された前記リカバリーファンクションを実行するように構成されており、
前記クライアントアップデートサーバは、前記アップデートオプティマイザーに応じてアップデートパッケージジェネレーターを備えており、前記クライアントデバイスがリカバリーファンクションをサポート可能にする第２アップデートを備えるアップデートパッケージを生成するように構成されており、前記クライアントアップデートサーバは、前記クライアントデバイスに前記アップデートパッケージを伝達するように構成されたアップデート通信ユニットを備えており、前記クライアントデバイスは、前記アップデートパッケージを受信し、前記第２アップデートを抽出して、インストールするように構成されている、システムが提供される。

アップデートパッケージジェネレーターは、アップデートオプティマイザーを備えていてもよい。

前記クライアントアップデートサーバは、前記第１アップデートの前に、前記クライアントデバイスに前記アップデートパッケージを伝達するように前記アップデート通信ユニットに命じるように構成されてもよい。

前記クライアントアップデートサーバは、前記アップデートパッケージと前記選択された編制スキームに従って編制された第１アップデートのインスタンスとを、前記クライアントデバイスへ別々に伝達するように、アップデート通信ユニットに命じるように構成されてもよい。

前記アップデート通信ユニットは、前記選択された編制スキームに従って編制された第１アップデートのインスタンスから前記第１アップデートのリカバリーを促進するために、前記アップデートパッケージを受信することを期待する前記クライアントデバイスに、アドバイスを送信するように構成されてもよい。

前記アップデート通信ユニットは、前記アップデートパッケージの前に、前記選択された編制スキームに従って編制された第１アップデートのインスタンスを送信するように構成されており、前記クライアントデバイスへの前記アドバイスは、前記選択された編制スキームに従って編制された第１アップデートのインスタンスに付随するようにしてもよい。

前記クライアントアップデートサーバは、アップデートのリポジトリから前記第１アップデートを検索するように構成されてもよい。

前記クライアントアップデートサーバは、前記デバイスケーパビリティーマネージャーによってアクセス可能なケーパビリティーデータレポジトリを備えており、前記ケーパビリティーデータレポジトリは、クライアントデバイスにサポートされた既存のファンクショナリティを記録してもよい。

前記デバイスケーパビリティーマネージャーは、前記ケーパビリティーデータレポジトリを参照して、前記リカバリーファンクションを実行するのに前記クライアントデバイスに求められる前記必要なファンクショナリティを判定するように構成されてもよい。

前記デバイスケーパビリティーマネージャーは、前記クライアントデバイスに求められる前記必要なファンクショナリティを構成するファンクショナリティ差異を識別するために、前記クライアントデバイスにサポートされている既存のファンクショナリティを、前記クライアントデバイスに求められるターゲットファンクショナリティと、比較するように構成されてもよい。

前記クライアントアップデートサーバは、ファンクショナリティリポジトリを備えており、前記ファンクショナリティリポジトリは、複数のオペレーティングファンクションを備えてもよい。

前記アップデートパッケージジェネレーターは、前記ファンクショナリティリポジトリからオペレーティングファンクションを検索するために前記ファンクショナリティリポジトリにアクセスし、前記ファンクショナリティ差異のファンクショナリティの少なくとも一部を提供するように構成されてもよい。

前記第２アップデートは、前記オペレーティングファンクションを備えてもよい。

前記ケーパビリティーデータは、前記クライアントデバイスの前記テクニカルケーパビリティーと、前記クライアントデバイスにサポートされた既存のファンクショナリティとを備えてもよい。

前記アップデートパッケージは、選択された編制スキームに従って編制された第１アップデートを備えてもよい。

前記アップデートパッケージジェネレーターは、前記選択された編制スキームに従って編制された前記第１アップデートを備える別のアップデートパッケージを生成するように構成されてもよい。

前記アップデートオプティマイザーは、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから前記第１アップデートをリカバリーするリカバリーファンクションと結合して適用される別のリカバリーファンクションを識別するように構成されてもよい。

前記非ＯＳシステムソフトウェアは、ファームウェアであってもよい。

前記クライアントデバイスは、通信モジュールを備えており、前記第１アップデートは、前記通信モジュールに関連してもよい。

前記編制スキームは、圧縮スキームと、暗号化スキームと、データデファレンシングスキームと、デルタ符号化スキームと、のうちの少なくとも１つを備えてもよい。

前記アップデートパッケージジェネレーターは、前記デバイスケーパビリティーマネージャーによって判定された前記クライアントデバイスに求められる前記必要なファンクショナリティに応答することにより、前記デバイスケーパビリティーマネージャーに応答してもよい。

求められる前記必要なファンクショナリティの前記デバイスケーパビリティーマネージャーによる判定は、前記アップデートオプティマイザーによって識別された前記リカバリーファンクションを実行するためにクライアントデバイスに欠いているファンクショナリティの判定であってもよい。

前記ケーパビリティーデータは、１又は複数のテーブル、アレイ及び／又はデータベースとして保存されてもよい。

前記アップデートオプティマイザーは、揮発性メモリ使用、不揮発性メモリ使用、メモリの物理ブロックのサイズ、前記第１アップデートの実行に関連した変更の分布の程度、アップデートパッケージのサイズ、及び／又は、クライアントデバイスに要求される処理時間、のうちの１つ以上の基準に基づいて、前記編制スキームを選択するようにしてもよい。

前記リカバリーファンクションは、コンパイルされたコード、コンパイルされたスクリプト、解釈可能なコード、又は、解釈可能なスクリプトであってもよい。

前記第１アップデートは、前記クライアントデバイスの非アップデートメンテナンスファンクショナルアスペクトに関連してもよい。

前記ファンクショナルアスペクトは、乱数を生成するための方法、チェックサムを算出するための方法、後のアップデートパッケージに続くデータをデコードする方法、前記アップデートパッケージを解凍する方法、ＧＮＳＳレシーバーの機能、ボコーダープラグイン、新機能、新しいＡＴコマンド、又は、セキュリティパッチであってもよい。

前記クライアントアップデートサーバは、前記クライアントデバイスを備える一群のクライアントデバイスをアップデートするのに必要な前記第１アップデートを識別するように構成されており、前記アップデート通信ユニットは、前記一群のクライアントデバイスのすべてのクライアントデバイスの前記アップデートパッケージに、無線で通信するように構成されてもよい。

前記アップデートパッケージ及び／又は第１アップデートは、前記クライアントデバイスからのレスポンスを要求するクエリーがなくてもよい。

前記アップデートパッケージジェネレーターは、デルタファイルジェネレーターを備えてもよい。

前記アップデートパッケージジェネレーターは、前記ケーパビリティーデータレポジトリの参照により前記リカバリーファンクションを実行するために、前記クライアントデバイスに求められる前記必要なファンクショナリティを判定するように構成されてもよい。

前記アップデートパッケージジェネレーターは、前記クライアントデバイスに求められる前記必要なファンクショナリティを構成するファンクショナリティ差異を識別するために、前記クライアントデバイスにサポートされた既存のファンクショナリティを、前記クライアントデバイスに求められる目標ファンクショナリティと、比較するように構成されてもよい。

前記デバイスケーパビリティーマネージャーは、前記アップデートパッケージジェネレーターからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されてもよい。

前記クライアントアップデートサーバは、オープンモバイルアライアンスデータマネージメント（ＯＭＡＤＭ）サーバ及び前記ＯＭＡＤＭサーバによってアクセス可能なケーパビリティーデータレポジトリを備え、前記ケーパビリティーデータレポジトリは、前記クライアントデバイスにサポートされた既存のファンクショナリティを記録してもよい。

前記ＯＭＡＤＭサーバは、前記アップデートパッケージジェネレーターからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されてもよい。

前記デバイスケーパビリティーマネージャーは、ファンクションリスト依頼メッセージを受信し、これに応じて、ＯＭＡＤＭサーバへファンクションリスト依頼を送るように構成されており、前記ＯＭＡＤＭサーバは、前記デバイスケーパビリティーマネージャーからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されてもよい。

前記アップデートパッケージは、データ構造定義に従って前記クライアントデバイスに伝達され、前記データ構造定義は、前記アップデートパッケージを含むために予約された、必要なファンクショナリティコンテンツフィールドを備えてもよい。

前記アップデートパッケージは、データ構造定義に従って前記クライアントデバイスに伝達され、前記データ構造定義は、前記別のアップデートパッケージを含むために予約された、必要なファンクショナリティコンテンツフィールドを備えてもよい。

前記データ構造定義は、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスを含むために予約された、アップデートコンテンツフィールドをさらに備えてもよい。

前記データ構造定義は、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスのリカバリーに関連したファンクションの識別子を含むために予約された、ファンクションインディケーターフィールドをさらに備え、前記ファンクションインディケーターフィールドは、前記必要なファンクショナリティコンテンツフィールドに付随するように構成されてもよい。

前記データ構造定義は、別のアップデートパッケージ含むために予約された、別の必要なファンクショナリティコンテンツフィールドをさらに備えてもよい。

前記データ構造定義は、別の編制されたアップデートのインスタンスを含むために予約された、別のアップデートコンテンツフィールドをさらに備えてもよい。

前記データ構造定義は、前記別の編制されたアップデートのインスタンスのリカバリーに関連した別のファンクションの別の識別子を含むために予約された、別のファンクションインディケーターフィールドをさらに備え、前記別のファンクションインディケーターフィールドは、前記別の必要なファンクショナリティコンテンツフィールドに付随するように構成されてもよい。

本発明の第２態様によれば、第１態様に関する上記のソフトウェアアップデートシステムを備えるエアーアップデートシステムにおけるファームウェアが提供される。

本発明の第４態様によれば、アップデートされる非ＯＳシステムソフトウェアを有するクライアントデバイスをアップデートする方法であって、前記クライアントデバイスに関するケーパビリティーデータにアクセスするステップと、前記クライアントデバイスの前記非ＯＳシステムソフトウェアの少なくとも一部をアップデートするのに必要な第１アップデートを検索するステップと、前記クライアントデバイスのアップデートを最適化するように、前記第１アップデートに適用される、編制スキームを決定するステップであって、前記決定された編制スキームは、前記クライアントデバイスのテクニカルケーパビリティーと互換性がある、ステップと、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから前記第１アップデートをリカバリーするためのリカバリーファンクションを識別するステップと、アップデートオプティマイザーによって識別されたリカバリーファンクションを実行するために前記クライアントデバイスに求められる必要なファンクショナリティを判定するために、前記ケーパビリティーデータを使用するステップと、前記クライアントデバイスに求められる前記必要なファンクショナリティの判定に応じて、アップデートパッケージを生成するステップであって、前記アップデートパッケージは、前記クライアントデバイスがリカバリーファンクションをサポート可能にする第２アップデートを備えている、ステップと、前記クライアントデバイスに前記アップデートパッケージを伝達するステップと、前記クライアントデバイスが前記アップデートパッケージを受信し、前記第２アップデートを抽出し、インストールするステップと、を備える方法が提供される。

いくつかのケースにおいては、クライアントデバイスに照会をする必要性を無くした、ソフトウェアアップデートシステム及びクライアントデバイスをアップデートする方法を提供することができる。それによって、帯域幅の減少による起こる通信障害、及び／又は、クライアントデバイスによる消費電力の保存の必要を回避することができる。さらに、このシステムと方法は、クライアントデバイスへのアップデートの通信を最適化する一方で、クライアントアップデートサーバ及びクライアントデバイスがともに、アップデートに適用する共通の編制スキームをサポートすることを保証して、クライアントデバイスへの通信を促進する。さらに、クライアントデバイスは、クライアントデバイスのプロセッシングケーパビリティーに最適化された編制スキームを、そのデバイスがサポートできる状態に置かれる。さらに、このシステムと方法は、コンテンツの最小のアップデートを実現し、これにより、無線信号ロス、及び／又は、電力損のような、例えば物理的なゆらぎに起因する、データ転送中断の危険を減らすことができる。転送されているデータを破壊する危険も、より少ないデータがあることから抑制され、また、アップデートパッケージを格納するのに必要なメモリの量も抑制される。

本発明の少なくとも１つの実施形態が、添付した図面を参照しつつ、単なる例示として、開示される。
図１は、本発明の実施形態を構成するソフトウェアアップデートシステムの概要図である。図２は、図１のシステム中で使用されるクライアントデバイスの概要図である。図３は、図１及び本発明の別の実施形態を構成するシステムの第１部分の動作方法の第１部分のフローダイアグラムである。図４は、図３の方法の第２部分のフローダイアグラムである。図５は、図４及び本発明のその他の実施形態を構成する方法の第２部分の代替のフローダイアグラムである。図６は、図１のシステムについての種々のデータ構造体定義構造の概要図である。図７は、図１及び本発明のさらに別の実施形態を構成するシステムの第２部分の動作方法のフローダイアグラムである。図８は、図１及び本発明の別の実施形態を構成するシステムについての代替アーキテクチャの概要図である。図９は、図１及び本発明のその他の実施形態を構成するシステムについてのさらに別のアーキテクチャの概要図である。図１０は、図１及び本発明のさらに別の実施形態を構成するシステムについてのその他のアーキテクチャの概要図である。図１１は、図１及び本発明のその他の実施形態をさらに構成するシステについてのその他のアーキテクチャの概要図である。

次の記述の全体にわたって、同一の参照数字は同種の部分を識別するために使用される。

図１を参照して、ソフトウェアアップデートシステム１００（例えば、ファームウェアオーバーザエアーアップデートシステム）は、クライアントアップデートサーバ１０２を備えており、クライアントアップデートサーバ１０２は、無線通信インターフェース１０８を介して、クライアントデバイス１０４あるいは一群のクライアントデバイス１０６と通信することができる。クライアントデバイス１０４あるいは一群のクライアントデバイス１０６は、クライアントアップデートサーバ１０２から遠隔に位置している。クライアントデバイスはそれぞれ、アップデートすることができるそれぞれの非ＯＳソフトウェア１１０を備える。アップデートサーバ１０２は、任意の適切なコンピューティング装置とすることができ、例えば、パーソナルコンピュータ（ＰＣ）、ワークステーション、ミニコンピュータ、メインフレームコンピューターなどである。アップデートサーバ１０２は、例えば、何らかの適切なバス構成、ネットワークプラットフォーム、及び／又は、マルチプロセッサプラットフォームを備えることができる。ＵＮＩＸ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ＭａｃＯＳ（登録商標）あるいは他の適切なオペレーティングシステムを含む、様々なオペレーティングシステムを使用することができる。

任意ではあるが、ソフトウェアアップデートシステム１００の外部で提供される、別のアップデートサーバ１１２（例えば設備メーカーサーバ）は、無線通信インターフェース１０８あるいは別の無線通信インターフェース１１４を介して、１又は複数のクライアントデバイス１０４と通信することができる。このような観点で、クライアントデバイス１０４は、アップデートサーバ１１２から無線通信を受信するための無線通信モジュール（図示せず）を備える。

変わって図２に示すように、この例示においては、クライアントデバイス１０４は、無線通信デバイスであり、プロセッシングリソース１７０（例えば、マイクロプロセッサー）と、揮発性メモリ１７２（例えば、ＲＡＭ）と、不揮発性メモリ１７４（例えば、ＲＯＭ）とを備えて、各々がプロセッシングリソース１７０に結合された、例えば、移動電話のユーザ装置（ＵＥ：User Equipment）ユニットである。また、プロセッシングリソース１７０は、マイクロホン１７６、スピーカーユニット１７８、キーパッド１８０及びディスプレイ１８２に結合されている。さらに、プロセッシングリソース１７０は、送信チェーン１８４及び受信チェーン１８６を備えるトランシーバーに結合され、送信チェーン及び受信チェーン１８４及び１８６は、デュプレキシングコンポーネント１８８に結合されている。デュプレキシングコンポーネント１８８は、アンテナ１９０に結合されている。当業者は、上述のクライアントデバイス１０４のアーキテクチャが、他の要素を備えることを認識するべきである。しかし、そのような追加の要素は、記述の簡明さと明瞭さを維持するために、ここに開示されていない。当業者は、さらにクライアントデバイス１０４が必ずしも無線通信能力を備える必要がなく、又は、無線通信と有線通信の能力を備えることができることを認識するべきである。このような観点で、クライアントデバイス１０４との通信は、有線通信による場合がある。

図１に戻り、クライアントアップデートサーバ１０２は、ＬＡＮインターフェース１２０などのネットワークインターフェースを介して、例えばローカルエリアネットワーク（ＬＡＮ：Local Area Network）などの通信網１１８に動作可能に結合された、アップデートパッケージジェネレーター１１６を備えている。また、無線通信インターフェース１０８における通信をサポートするために、アップデートパッケージジェネレーター１１６は、アップデート通信ユニット１２２に動作可能に結合されている。

さらに、クライアントアップデートサーバ１０２は、アップデートパッケージジェネレーター１１６及びデバイスケーパビリティーマネージャー１２６に動作可能に結合されたアップデートオプティマイザー１２４を備えており、また、デバイスケーパビリティーマネージャー１２６は、ケーパビリティーデータをケーパビリティーデータレポジトリ１２８に格納するができる。ケーパビリティーデータレポジトリは、ソフトウェアアップデートシステム１００を使用する各クライアントデバイス又はクライアントデバイス１０４の各タイプのテクニカルケーパビリティーの記録を備えており、この例示においては、クライアントデバイス又はクライアントデバイスの各タイプにサポートされた既存のファンクショナリティを含んでいる。ケーパビリティーデータは、任意の適切な形式、例えばテーブル、アレイ及び／又はデータベースで保存することができる。この例示において、ケーパビリティーデータレポジトリに含まれている情報は、製造者によって予め決定されている。また、アップデートストア１３０は、アップデートパッケージジェネレーター１１６に動作可能に結合されており、例えばファームウエアイメージなどのアップデートデータのイメージを格納する。ファンクショナリティリポジトリ１３１は、アップデートパッケージジェネレーター１１６に動作可能に結合されており、複数のオペレーティングファンクションを格納する。オペレーティングファンクションは、単独で又は組み合わせで、様々なクライアントデバイスによって用いられ得るファンクションの集合体又はライブラリであり、必要なタスク（例えば、後述する選択された編制スキームに従って編制されたアップデートのリカバリーに関連したタスク）を実行する。複数のオペレーショナルファンクションが、ファンクションのツールキットを構成する。

動作（図３）については、１つ以上のクライアントデバイス１０４の非ＯＳソフトウェアの少なくとも一部をアップデートするために、アップデートパッケージジェネレーター１１６は、ネットワークインターフェース１２０を介してアップデートを受信し、アップデートストア１３０に受信したアップデートを格納する。これが、アップデートのリポジトリを構成する。一旦、アップデートパッケージジェネレーター１１６が第１アップデートの受信を認識する（ステップ２００）と、アップデートパッケージジェネレーター１１６は、第１アップデートが適用されるターゲットデバイスを識別する（ステップ２０２）。これは、個々のクライアントデバイス１０４あるいはクライアントデバイス１０６のグループとすることができる。

第１アップデートは、この例示においては、ファームウェアアップデートであり、クライアントデバイス１０４の通信モジュールに関係している。しかしながら、第１アップデートは任意の適切な非ＯＳソフトウェアでもよく、それは、例えば、データ、設定ファイルのようなファイル、アルゴリズム、アルゴリズムライブラリ、コンピュータープログラム、コードイメージ、及び、命令を含むことを意図しており、それらはオーバーザエアーでアップデートされ得るクライアントデバイス１０４の任意の動作部分に関係することができる。アップデートされる非ＯＳソフトウェアは、クライアントデバイス１０４の非アップデートメンテナンスファンクショナルアスペクトに関するものであり、例えば、乱数を生成する方法、チェックサムを算出する方法、後のアップデートパッケージに続くデータをデコードする方法、アップデートパッケージを解凍する方法、ＧＮＳＳレシーバーの機能、ボコーダープラグイン、新機能あるいは新しいＡＴコマンドである。第１アップデートは、ソフトウェアアップデート、新しい又は置換ファイル、新しい又は置換入出力デバイスコンフィグレーション、セキュリティパッチ及び／又は実行すべきクライアントデバイス１０４のための特定のコマンドでもよい。このような観点で、クライアントデバイス１０４は、アップデートするメカニズム（後述する第２アップデートに関連する）の維持に関係するファンクショナルアスペクトを有すると認識されるべきであり、また、クライアントデバイス１０４をアップデートするメカニズムの維持に関係しない他のファンクショナルアスペクトを有すると認識されるべきである。第１アップデートは、アップデートするメカニズムの維持に関係しないこれらの他のファンクショナルアスペクトに関係する。

一旦、第１アップデートが適用される１又は複数のクライアントデバイスが識別される（ステップ２０２）と、アップデートパッケージジェネレーター１１６は、第１アップデートを、アップデートオプティマイザー１２４及びクライアントデバイス１０４あるいはクライアントデバイス１０６のグループの識別部に伝達し、また、アップデートオプティマイザー１２４は、デバイスケーパビリティーマネージャー１２６と協働して、クライアントデバイス１０４あるいはクライアントデバイス１０６のグループのテクニカルケーパビリティーを識別する（ステップ２０４）。いくつかの例示において、アップデートパッケージジェネレーター１１６は、アップデートされる非ＯＳソフトウェアの既存バージョンと受信したアップデートとの間の差異を生成する、デルタファイルジェネレーターを備えることができ、この差異は、アップデートオプティマイザー１２４に伝達される第１アップデートを構成する。その後、デバイスケーパビリティーマネージャー１２６は、ケーパビリティーデータ１２８にアクセスし、クライアントデバイス１０４あるいはクライアントデバイス１０６のグループのテクニカルケーパビリティーを判定する。記述の簡明のために、以下においては、クライアントデバイス１０４あるいはクライアントデバイス１０６のグループの参照は、クライアントデバイス１０４の参照に略記される。しかしながら、当業者は、必要であれば、適切な修正と共に、動作原理がクライアントデバイス１０６のグループに適用されることを認識するであろう。

デバイスケーパビリティーマネージャー１２６によって一旦判定されたクライアントデバイス１０４のテクニカルケーパビリティーは、アップデートオプティマイザー１２４に伝達され、アップデートオプティマイザー１２４は、アップデートパッケージジェネレーター１１６によって識別された第１アップデートと結合してクライアントデバイス１０４に関連したテクニカルケーパビリティデータを使用し、最適の態様で第１アップデートを伝達するために、クライアントデバイス１０４のテクニカルケーパビリティーの範囲内で編制することのできる第１アップデートに従った編制スキームを識別する（ステップ２０６）。これにより、例えば、クライアントデバイス１０４のアップデートを最適化する。編制スキームは、クライアントデバイスのテクニカルケーパビリティーの１つ以上に基づいて選択することができ、例えば、メモリ、揮発性メモリ、不揮発性メモリ、又は、メモリの物理ブロックのサイズ、第１アップデートの実行に関連した変更の分布の程度、要求される処理時間、プロセッサー能力及び／又はバッテリ寿命に基づいて選択することができる。クライアントデバイス１０４に現在常駐しているソースファームウエアイメージと、アップデート処理の結果としてクライアントデバイス１０４に常駐させることを意図したターゲットファームウエアイメージとの間の差異を、考慮に入れることができる。同様に、アップデートパッケージのサイズも、メモリ使用量の観点からだけでなく、送信時間及び電力消費の観点から、考慮に入れることができる。この例示において、編制スキームは圧縮スキームであるが、しかし、当業者は、例えば最適な送信のために、第１アップデートを編制するその他の技術を採用できることを認識すべきである。他の編制スキームの例としては、暗号化スキーム、データディファレンシャルスキーム及び／又はデルタエンコーディングスキームがある。

その後、アップデートオプティマイザー１２４は、リカバリーファンクションを判定する（ステップ２０８）。これは、識別された編制スキームに従って編制された第１アップデートの構成を復元させるために、クライアントデバイス１０４が実行しなければならない１つ以上の処理ステップであり、なぜなら、クライアントデバイス１０４への伝達に先立って、アップデートオプティマイザー１２４によって選択された編制スキームに従って、第１アップデートが編制されるからである。リカバリーファンクションは、編制スキームの反対又は復元と考えることができ、また、クライアントデバイス１０４の技術的な仕様は、リカバリーファンクションの実行をサポートする必要がある。リカバリーファンクションは、選択された編制スキームに従って編制された第１アップデートのインスタンスから、第１アップデートをリカバリーできるようにする。リカバリーファンクションは、コンパイルされたコード、コンパイルされたスクリプト、解釈可能なコードあるいは解釈可能なスクリプトとして実現することができる。

アップデートオプティマイザー１２４は、デバイスケーパビリティーマネージャー１２６に、リカバリーファンクションあるいはリカバリーファンクションの識別子を伝達する。要求されるリカバリーファンクションについての情報及びクライアントデバイス１０４のテクニカルケーパビリティーを用いて、デバイスケーパビリティーマネージャー１２６は、クライアントデバイス１０４がリカバリーファンクションを実行するために保持することを要求されるファンクショナリティを識別する（ステップ２１０）。この点で、デバイスケーパビリティーマネージャー１２６は、クライアントデバイス１０４に要求されるターゲットファンクショナリティを、クライアントデバイス１０４にサポートされている既存のファンクショナリティと比較するように構成されており、クライアントデバイス１０４に求められる必要なファンクショナリティを構成する何らかのファンクショナリティ障害あるいは差異を識別する。いくつかの例示において、差異は、クライアントにサポートされた「ソース」ファンクショナリティとクライアントデバイス１０４にサポートされる必要のある「ターゲット」ファンクショナリティについての先験的な情報に基づいて、予め決定することができる。ファンクショナリティ差異情報は、ファンクショナリティ差異の識別を容易にするために、例えば、データベース又はルックアップテーブルに、格納することができる。

障害が存在しない場合、アップデートパッケージマネージャー１１６は、第１アップデートを、選択された編制スキームに従って構成された、第１アップデートのインスタンスに編制して（ステップ２１２）、アップデートパッケージを構成し、そして、更なるアップデートの受信を待つ処理（ステップ２００）に戻る前に、クライアントデバイス１０４に、アップデートパッケージを伝達する（ステップ２１４）。さもなければ、単一のファンクション又は複数のファンクションである必要なファンクショナリティは、アップデートパッケージジェネレーター１１６に伝達され、アップデートパッケージジェネレーター１１６は、簡潔に上述した第２アップデートの形式の必要なファンクショナリティを提供する。したがって、必要なファンクショナリティを提供するために、アップデートパッケージジェネレーター１１６は、この例示において、ナリティリポジトリ１３１にアクセスし、１つ以上のオペレーショナルファンクションを検索し、少なくとも一部のファンクショナリティ障害（クライアントデバイス１０４が、既に必要なファンクショナリティの一部をサポートしてもよい）を削減する。すなわち、ファンクショナルリポジトリ１３１からの検索は、クライアントデバイス１０４に欠如しているファンクショナリティの少なくとも一部を提供して、リカバリーファンクションを実現し、ファンクショナリティ差異の架け橋となる。そのため、第２アップデートは、この例示においては、少なくとも１つのオペレーティングファンクションを備える、又は、提供する。

いくつかの状況で、リカバリーファンクションが必要なファンクショナリティをすべて提供するには不十分である場合、アップデートオプティマイザー１２４は、第１アップデートをリカバリーするリカバリーファンクションと結合して適用される別のリカバリーファンクションを識別するように構成される。したがって、１又は複数のオペレーショナルファンクションは、アップデートパッケージジェネレーター１１６によってファンクショナリティリポジトリ１３１から検索されて、アップデートパッケージに組み入れられる。それらの詳細は、後述する。

アップデートパッケージジェネレーター１１６は、第２アップデートを受信あるいはリカバリーすると、クライアントデバイス１０４にサポートされた既存のファンクショナリティのケーパビリティーの範囲内でクライアントデバイス１０４への最適な通信に適している形式の第２アップデートを構成すること（ステップ２１６）による、応答を行う。図４を参照すると、第２アップデートの構成は、アップデートパッケージを構成する。その後、アップデートパッケージジェネレーター１１６は、アップデート通信ユニット１２２にアップデートパッケージを伝達し、アップデート通信ユニット１２２は、採用されている１つ以上の通信プロトコルにサポートされたデータ構造定義に従ってアップデートパッケージを構成し、クライアントデバイス１０４に第２アップデートを伝達する（ステップ２１８）。

この例示において、アップデート通信ユニット１２２は、第１アップデートの通信に先立って、且つ、独立して、アップデートパッケージの形式の第２アップデートを伝達するように指令されている。その後、この点で、アップデートパッケージジェネレーター１１６は、アップデートオプティマイザー１２４によって決定された編制スキームに従って第１アップデートを編制し（ステップ２２０）、次に、アップデートパッケージジェネレーター１１６は、アップデート通信ユニット１２２及び無線通信インターフェース１０８を介して、クライアントデバイス１０４へ、編制された形式の第１アップデートを伝達する（ステップ２２２）。この例示において、アップデートパッケージジェネレーター１１６は、選択された編制スキームに従って編制された第１アップデートを備える別のアップデートパッケージを生成する。

上記に示唆されるように、第１アップデート及び第２アップデートは、多くの異なる方法でクライアントデバイス１０４に、伝達することができる。例えば（図５）、第１及び第２アップデートは、ともに単一の通信の一部として、クライアントデバイスに伝達することができ、その場合には、アップデートパッケージジェネレーター１１６は、アップデートオプティマイザー１２４によって決定された編制スキームに従って第１アップデートを編制し（ステップ２２０）、次に、アップデートパッケージジェネレーター１１６は、編制された形式の第１アップデートのインスタンス及び第２アップデートを備えるアップデートパッケージを、アップデート通信ユニット１２２へ伝達する。アップデート通信ユニット１２２は、採用されている１つ以上の通信プロトコルにサポートされたデータ構造定義に従ってアップデートパッケージを構成し、また、無線通信インターフェース１０８を介して、クライアントデバイス１０４（あるいは第２アップデートを要求するすべてのデバイス）に、アップデートパッケージを伝達する（ステップ２２２）。

あるいは、適切なプロトコルの実行で、第１アップデートは個別の通信としてクライアントデバイス１０４に伝達することができ、これは上述した別のアップデートパッケージであり、また、第２アップデートが受信され処理されるまでの実行に先立って、クライアントデバイス１０４に保持される。この点では、アップデート通信ユニット１２２は、選択された編制スキームに従って編制された第１アップデートのインスタンスからの第１アップデートのリカバリーを促進するためにアップデートパッケージを受信することを期待するクライアントデバイス１０４に、アドバイスを送信するように構成される。さらに、第１アップデートのインスタンスの通信は、クライアントデバイス１０４へのアドバイスを付随することができる。

アップデートパッケージを伝達する場合、編制された第１アップデートとともに、あるいは無しで、データ構造定義に従って、データ構造定義は、多くの異なる方法で構成することができ、また、アップデートパッケージを含むための予約された必要なファンクショナリティフィールドを備えることができる。図６を参照すると、第１データ構造定義３００は、必要なファンクショナリティコンテンツフィールド３０２を備えており、この例示において、必要なファンクショナリティコンテンツフィールド３０２は、ファンクショナリティキー識別子又はインディケーターフィールド３０４を付随している。また、第１データ構造定義３００は、第１アップデートコンテンツフィールド３０６、第２アップデートコンテンツフィールド３０８及び第３アップデートコンテンツフィールド３１０を備えており、必要なファンクショナリティフィールド３０２に第２アップデートが付随する場合における、クライアントデバイス１０４に伝達される第１アップデートあるいはその一部のインスタンスのために予約されている。

クライアントデバイス１０４がリカバリーファンクションをサポートすることを可能にするためにクライアントデバイス１０４に１つより多いファンクションを伝達する必要がある場合には、第２データ構造定義３１２を採用することができる。第１データ構造定義３００と同様に、第２データ構造定義３１２は、ファンクショナリティキー識別子又はインディケーターフィールド３０４を付随する、必要なファンクショナリティフィールド３０２を備える。この例示において、クライアントデバイス１０４は、リカバリーファンクションをサポートするのに必要な１つのファンクションを既に保持するが、非ＯＳソフトウェアへの異なるアップデートあるいは同じ第１アップデートの異なる部分と共に使用されるために、別のリカバリーファンクションをサポートする、別のファンクションを必要とする。この点では、第２データ構造定義３１２は、第１アップデートフィールド３０６に先行する、第１ファンクション識別子あるいはインディケーターフィールド３１４を備えており、クライアントデバイス１０４に対して、第１アップデートフィールド３０６含まれているアップデートに関連したリカバリーファンクションをサポートするのに特定のファンクションが要求されることを示している。同様に、第２データ構造定義３１２は、第２アップデートフィールド３０８に先行する、第２ファンクション識別子又はインディケーターフィールド３１６をさらに備えており、クライアントデバイス１０４に対して、第２アップデートフィールド３０８に含まれているアップデートに関連したリカバリーファンクションをサポートするのに特定のファンクションが要求されることを示す。しかしながら、この例示において、クライアントデバイス１０４は、第２ファンクション識別子あるいはインディケーターフィールド３１６で識別されたファンクションを既にサポートしており、したがって、データ構造は、第２ファンクション識別子あるいはインディケーターフィールド３１６に示されたファンクションのために予約されたフィールドを保持しない。

クライアントデバイス１０４が第１アップデートに関するリカバリーファンクションをサポートすることができるようにするためにクライアントデバイス１０４に１つを超えるアップデートパッケージを伝達することが必要な場合には、第３データ構造定義３２２が採用される。また、この例示において、第１及び第２ファンクションに加えて、クライアントデバイス１０４が第１アップデートに関するリカバリーファンクションをサポートするのに必要な第３ファンクションをサポートすると仮定される。この点で、第３データ構造定義３２２は、第１ファンクションのために予約されたファンクショナリティキー識別子又はインディケーターフィールド３０４を付随する必要なファンクショナリティフィールド３０２を備えるだけでなく、別のファンクショナリティキー識別子あるいはインディケーターフィールド３２６を付随する別の必要なファンクショナリティフィールド３２４を備える。さらに、第３データ構造定義３１２は、第１アップデートフィールド３０６に先行する、第３ファンクション識別子又はインディケーターフィールド３２８を備えており、クライアントデバイス１０４に伝達するファンクションに加えて、クライアントデバイス３０６に対して、特定の他のファンクション（第３ファンクション識別子又はインディケーターフィールド３２８で識別される）が、第１アップデートフィールド３０６に含まれていたアップデートに関連したリカバリーファンクションをサポートするのに要求されることを示す。

第２アップデートを含んでいるアップデートパッケージが第１アップデートとは別に伝達される実施形態において、第１の二部形式データ構造定義３３０を、第１データ構造定義３００の二部形式の類似体として採用することができる。第１の二部形式データ構造定義３３０は、同一の第１アップデートに対応する２つのアップデートフィールドと共にアップデートパッケージの伝達をサポートする。それらは、第２アップデートを含んでいるアップデートパッケージとは別々に送信される。

同様に、第２の二部形式データ構造定義３４０を、採用することができる。第２データ構造定義３１２のコンテキストでは、第２の二部形式データ構造定義３４０は、二部形式の等価な類似体であり、第１アップデートに対応する２つのアップデートフィールドと共に、アップデートパッケージの伝達をサポートする。それらは、第２アップデートを含んでいるアップデートパッケージとは別々に送信され、クライアントデバイス１０４が第２アップデートに関連したファンクショナリティに加えて必要なファンクションをサポートする可能性をサポートする。

クライアントデバイス１０４は、任意の適切な通信対応のデバイスでもよく、例えば、排他的でなく、オーバーザエアーソフトウェアアップデートを実行することができる、移動体通信ハンドセットのような無線通信デバイスでもよい。この例示において、図７を参照すると、クライアントデバイス１０４は、無線通信の受信（ステップ４００）を待つように構成される。その後、クライアントデバイス１０４は、受信したデータが非ＯＳソフトウェアのアップデートに関係するかどうか判定する（ステップ４０２）。受信したデータが非ＯＳソフトウェアのアップデートに関係しない場合、クライアントデバイス１０４は、クライアントデバイス１０４の設計に従って受信データを処理する（ステップ４０４）。この点で、記述の簡明のために、クライアントデバイス１０４の動作の記述は、クライアントデバイス１０４の非ＯＳソフトウェアのアップデートに関係する処理に制限している。

さらに、記述の明瞭さ及び簡明のために、クライアントデバイス１０４の動作は、第２アップデートを備えるアップデートパッケージのコンテキストの中で開示され、このアップデートパッケージは、別のアップデートパッケージとして編制された形式の第１アップデートに先立って、且つ、別の通信で、受信される。この点で、第２アップデートは、編制された第１アップデートを通信するために使用される、個別の通信バーストあるいはビットストリームを使用して、送信される。従って、受信したデータがアップデート（ステップ４０２）に関係する場合、任意の非ＯＳソフトウェアアップデートの処理に先立って、クライアントデバイス１０４は、通信が、インストールされる必要のあるアップデートパッケージに関係するかどうかを判定する（ステップ４０６）。受信したデータがアップデートパッケージを備える場合、クライアントデバイス１０４は、アップデートパッケージから第２アップデートを抽出するか、あるいは、クライアントデバイス１０４に第２アップデートを伝達するためにクライアントアップデートサーバ１０２によって用いられた第２アップデートの何らかの構成を復元する。クライアントデバイス１０４にサポートされた既存のファンクショナリティを使用して、クライアントデバイス１０４がアップデートパッケージから第２アップデートをリカバリーすることができるように、アップデートパッケージは構成される。第２アップデートの抽出は、単純なインタープリテーション、復号及び／又は解凍とすることができる。その後、クライアントデバイス１０４は、第２アップデートをインストールするか、又は、実行する（ステップ４０８）。

その後、クライアントデバイス１０４は、クライアントデバイス１０４によって受信されたデータが、編制された形式の第１アップデートを含んでいるかどうかを判定する（ステップ４１０）。受信したデータが編制された形式の第１アップデートを含んでいた場合、あるいは、受信したデータが第１アップデートを備えるだけであるとクライアントデバイス１０４によって判定された（ステップ４０６）場合、クライアントデバイスがリカバリーファンクションを実行するのに必要なファンクショナリティを既に保持しているので、クライアントデバイス１０４は、受信したデータから第１アップデートをリカバリーし始める（ステップ４１２）。そうでなければ、クライアントデバイス１０４は、非ＯＳソフトウェアのアップデートに関連する更なるデータの受信を待つ（ステップ４００）。一旦、第１アップデートが通信目的に用いられた第１アップデートの編制された形式からリカバリーされたならば、クライアントデバイス１０４は、第１アップデートを実施するか実行する（ステップ４１４）。それは、クライアントデバイス１０４の非ＯＳソフトウェアをアップデートする役割を果たす。

他の実施形態（図８）においては、クライアントアップデートサーバ１０２は、本質的に分散することができ、及び／又は、特定の実行アーキテクチャをサポートするために他のファンクションユニットを備えることができる。この点で、アップデートオプティマイザー１２４のファンクショナリティは、アップデートパッケージジェネレーター１１６に組み入れることができる。さらに、又は、択一的に、コンテンツサーバ１４０は、アップデートパッケージジェネレーター１１６と通信する能力を有するように提供することができる。コンテンツサーバ１４０は仲介者として働き、アップデートパッケージジェネレーター１１６によって生成されたアップデートを処理する。さらに、コンテンツサーバ１４０は、クライアントデバイス１０４と無線で通信する能力を有しており、また、コンテンツサーバ１４０は、この例示においては無線で、クライアントデバイス１０４と通信する能力を有している。

動作については、デバイスケーパビリティーマネージャー１２６に照会するアップデートオプティマイザー１２４の代わりに、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティに関する情報のために、アップデートパッケージジェネレーター１１６は、コンテンツサーバ１４０へ、クエリー１６０（例えばファンクションリスト依頼メッセージ）を送信する。これに対するレスポンスで、コンテンツサーバ１４０が、クライアントデバイス１０４へ照会１６２をすることができ、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティを判定する。一旦、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティが、クライアントデバイス１０４により、コンテンツサーバ１４０へ伝達１６４されたならば、コンテンツサーバ１４０は、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティを、アップデートパッケージジェネレーター１１６に戻して伝達１６６する。この点では、上述した分散化アプローチに従って、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及びファンクショナリティに関する情報のうちのいくらかを、デバイスケーパビリティーマネージャー１２６が提供することができることは、認識されるべきである。一旦、アップデートパッケージジェネレーター１１６が要求した情報を保持すると、アップデートパッケージジェネレーター１１６は、編制された形式で第１アップデートを備えるアップデートパッケージを生成する。この点で、リカバリーファンクション及び編制スキームの識別に関係する第２アップデートは、前述の実施形態に関して開示されるのと同じである。その後、第１アップデートを備えるアップデートパッケージが、第１通信１４２にて、コンテンツサーバ１４０へ伝達される。その後、コンテンツサーバ１４０は、この例示では、実施の便宜に依存するが、例えば第２通信１４４をプッシュすることによって、第２通信１４４にて、編制された形式の第１アップデート及び第２アップデート備えるアップデートパッケージを、クライアントデバイス１０４へ伝達する。この点で、恒久的な又は一時的な記憶デバイスを、第２通信１４４のコンテンツを保持するために使用することができる。これは、コンテンツサーバ１４０によって格納され、クライアントデバイス１０４によってアクセスすることができる。どのような場合でも、一旦、クライアントデバイス１０４が第２通信１４４のコンテンツを得たならば、クライアントデバイス１０４は、既に上述した態様で、受信した第１アップデート及び第２アップデートを処理することができる。この例示において、単一のアップデートパッケージで第１及び第２アップデートがともに伝達されるが、もちろん、当業者は、他の如何なる通信フォーマットにも従って、例えば個別のアップデートパッケージとして、編制された形式の第１アップデート及び第２アップデートを、クライアントデバイス１０４に伝達することができると認識するであろう。

上述の実施形態（図９）の変形では、オープンモバイルアライアンスデータマネージメント（ＯＭＡＤＭ：Open Mobile Alliance Data Management）サーバ１４６を提供することができ、これは、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティに関係する情報を得る目的で、コンテンツサーバ１４０とクライアントデバイス１０４との間の仲介者の役割を果たす。このため、コンテンツサーバ１４０によって受信されたアップデートパッケージジェネレーター１１６からのクエリー１６０は、要求された情報を得るために、ＯＭＡＤＭサーバ１４６へ転送される。従って、クライアントデバイス１０４又はクライアントデバイス１０４のタイプにサポートされたテクニカルケーパビリティー及び／又はファンクショナリティを判定するために、ＯＭＡＤＭサーバ１４６は、照会１６２をクライアントデバイス１０４にすることができる。一旦、クライアントデバイスにサポートされたテクニカルケーパビリティー及び／又はファンクショナリティが、クライアントデバイス１０４により、ＯＭＡＤＭサーバ１４６への伝達１６４されると、ＯＭＡＤＭサーバ１４６は、この情報をコンテンツサーバ１４０へ戻して伝達１６６することができ、上述の実施形態に関して開示されるのと同じ方法で処理される。あるいは、クライアントデバイス１０４に照会する代わりに、ＯＭＡＤＭサーバ１４６は、クライアントデバイス１０４あるいはクライアントデバイス１０４のタイプにサポートされたテクニカルケーパビリティー及び／又はファンクショナリティのデータベース１４８（リポジトリを構成する）に、アクセスできることができる。そして、コンテンツサーバ１４０によって転送されたクエリー１６０に応じて、ＯＭＡＤＭサーバ１４６は、データベース１４８にアクセスすることができ、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティを検索でき、また、コンテンツサーバ１４０へこの情報を戻して伝達１６６することができる。この点に関して、上述したように、クライアントデバイス１０４にサポートされたテクニカルケーパビリティー及び／又はファンクショナリティに関する情報は、前述の実施形態の開示と同じ方法で処理される。一旦、生成されたならば、アップデートパッケージは、クライアントデバイス１０４に伝達することができる。１つの例示において、アップデートパッケージは、無線で伝達することができるが、しかし、他のモードを考慮すると、例えば、ＯＭＡＤＭサーバ１４６によるクライアントデバイス１０４への後の通信のために、ポータブルメモリデバイス（図示せず）によりＯＭＡＤＭサーバ１４６へ転送することができる。

他の実施形態では、クエリーが特にアップデートパッケージジェネレーター１１６から生成される必要はなく、クライアントアップデートサーバ１０２又はソフトウェアアップデートシステム１００における他の適切なエンティティから生成できることは、認識されるべきであり、例えば、クエリー（例えばファンクションリストリクエスト）を受信することができるデバイスケーパビリティーマネージャー１２６から生成できる。ＯＭＡＤＭサーバ１４６への照会の通信は、直接的でも間接的でもよい。

さらに別の実施形態では、ＯＭＡＤＭサーバ１４６は必要としない。この実施形態では、クライアントデバイス１０４にサポートされたファンクショナリティを判定する代わりに、又は、そのような情報の蓄積を維持する代わりに、第１アップデートは、引き続き又は先行して、リカバリーファンクションを実行するのに必要な第２アップデートを常に付随すると仮定されている。従って、どんな場合も、リカバリーファンクションがクライアントデバイス１０４に既にサポートされているかどうかに拘わらず、第２アップデートはクライアントデバイス１０４へ伝達される。このアプローチをサポートするために、図１０を参照すると、アップデートパッケージジェネレーター１１６及びコンテンツサーバ１４０は、アップデートパッケージジェネレーター１１６からコンテンツサーバ１４０へのアップデートパッケージの結合した通信１５０をサポートする。さらに、アップデートパッケージジェネレーター１１６及び／又はコンテンツサーバ１４０は、コンテンツサーバ１４０からクライアントデバイス１０４へのアップデートパッケージの結合した通信１５２をサポートする。一旦、何らかの適切な実装（例えば、既に開示されたタイプ）を用いて判定されたならば、アップデートパッケージジェネレーター１１６は、第１アップデートと、アップデートパッケージの一部あるいは別のアップデートパッケージとしての第２アップデートとを、コンテンツサーバ１４０に伝達するように構成されている。同様に、コンテンツサーバ１４０は、第１アップデートと、アップデートパッケージの一部あるいは別のアップデートパッケージとしての第２アップデートとを、クライアントデバイス１０４に伝達するように構成される。実装のニーズに依存して、別のアップデートパッケージ及び／又はアップデートパッケージの１又は複数の一時的な（あるいは恒久的な）コピーが、アップデートパッケージジェネレーター１１６及びコンテンツサーバ１４０によるシェアされた使用のために、及び、コンテンツサーバ１４０及びクライアントデバイス１０４によるシェアされた使用のために、格納しておくことができる。アップデートの１又は複数のコピーは、実装（例えば共有のハードドライブ、メモリ、クラウドリソース）の何らかの適切な態様を用いて、格納することができる。

従って、動作において、一旦、アップデートパッケージジェネレーター１１６が、クライアントデバイス１０４に適用される第１アップデートと、第２アップデートの形式で要求されたファンクショナリティのデータとを識別したならば、これらは、既に開示された方法で、生成されて、コンテンツサーバ１４０へ伝達１５０され、そして、コンテンツサーバ１４０からクライアントデバイス１０４へ伝達１５２される。

ここで、図１１に示すように、図１０の実装は、第２アップデートを備えるアップデートパッケージと、編制された形式で第１アップデートを備える別のアップデートパッケージとの個別の通信のコンテキストにおいて、開示される。この点で、一旦、何らかの適切な実装（例えば、既に開示されたタイプ）を用いて判定されたならば、第１の個別の通信１５４が、アップデートパッケージジェネレーター１１６からコンテンツサーバ１４０への第２アップデート及び他の何らかのファンクション（別のアップデートパッケージを構成する）を伝達するために使用され、また、第２の個別の通信１５６が、第１アップデートを格納して伝達するために使用される。第１及び第２の個別の通信１５４及び１５６は、図１０の第１の結合した通信１５０と同じ役割を果たす。そして、第２アップデート及び第１アップデートをそれぞれ備えるアップデートパッケージ及び別のアップデートパッケージは、第３の個別の通信１５８及び第４の個別の通信１６０として、クライアントデバイス１０４へ伝達され、図１０の第２結合した通信１５２と同じ役割を果たす。再び、実装のニーズに依存して、別のアップデートパッケージ及び／又はアップデートパッケージの１又は複数の一時的な（あるいは恒久的な）コピーが、アップデートパッケージジェネレーター１１６及びコンテンツサーバ１４０によりシェアされる使用のために、及び、コンテンツサーバ１４０及びクライアントデバイス１０４によりシェアされる使用のために、格納することができる。アップデートの１又は複数のコピーは、実装（例えば共有のハードドライブ、メモリ、クラウドリソース）の何らかの適切な態様を用いて、格納することができる。

図１０の例示と比較して、この例示のこの装置は、データの通信の異なる編制であるが、しかし、一方で、ファンクションは前述の例示と同様である。

上記の実施形態に関して、第１アップデートは、クライアントデバイス１０４からのレスポンスを要求するクエリーがないことは認識されるべきである。同様に、アップデートパッケージは、クライアントデバイス１０４からのレスポンスを要求するクエリーがない。

当業者は、上述の実装が、添付されたクレームの範囲内で考えられる様々な実装の単なる例示であることを認識するべきである。

例えば、デバイスケーパビリティーマネージャー１２６が、クライアントデバイス１０４によってリカバリーファンクションを実行するのに求められる必要なファンクショナリティを判定する代わりに、アップデートパッケージジェネレーター１１６が、ケーパビリティーデータレポジトリ１２８を参照することにより、必要なファンクショナリティを判定することができる。同様に、デバイスケーパビリティーマネージャー１２６の代わりに、アップデートパッケージジェネレーター１１６が、クライアントデバイス１０４にサポートされた既存のファンクショナリティを、クライアントデバイス１０４に要求されるターゲットファンクショナリティと比較することができ、クライアントデバイス１０４に求められる必要なファンクショナリティを構成するファンクショナリティ障害又は差異を識別することができる。しかしながら、デバイスケーパビリティーマネージャー１２６は、アップデートパッケージジェネレーター１１６から受信したファンクションリスト依頼メッセージに応じて、クライアントデバイスあるいはクライアントデバイス１０４のタイプに保持していたファンクショナリティを判定することができる。

上記の例示において、デバイスケーパビリティーマネージャー１２６及びケーパビリティーデータレポジトリ１２８は、クライアントアップデートサーバ１０２にサポートされているが、当業者は、デバイスケーパビリティーマネージャー１２６がクライアントアップデートサーバ１０２と共同設置される必要はないことを認識するべきである。同様に、ケーパビリティーデータレポジトリ１２８は、クライアントアップデートサーバ１０２と共同設置される必要はない。この点では、デバイスケーパビリティーマネージャー１２６及びケーパビリティーデータレポジトリ１２８は、それぞれ、クライアントアップデートサーバ１０２から互いに離れて遠隔に設置することができ、例えば、個別のサーバにサポートされる。

上述した例示において、クライアントデバイス１０４は、アップデート処理を行うためには無線通信インターフェースに依存している。しかしながら、上記で示唆されているように、有線通信は、クライアントデバイス１０４の接続を確実にするために使用することができる。当業者は、非ＯＳソフトウェアが、クライアントデバイス１０４の無線通信ケーパビリティーあるいは有線通信ケーパビリティーと関係する必要はないことを認識するべきであり、また、非ＯＳソフトウェアは、クライアントデバイス１０４の他のアスペクトに関係づけることができ、例えば、上記で示唆したような全地球測位システム（ＧＰＳ）レシーバーのようなＧＮＳＳレシーバー、又は、クライアントデバイス１０４のメーカーによって提供されるようなアプリケーションプロセッサと、関係づけることができる。

アーキテクチャの分散化を開示したが、クライアントアップデートサーバ１０２は、ＯＭＡＤＭサーバ１４６を備えることができる。さらに、ＯＭＡＤＭサーバ１４６は、上記に開示された、いくつかの実施形態で用いることができるサーバの種類の単なる例示であり、当業者は、他の適切な種類のサーバを用いることができることを認識するべきであり、例えば、オープンモバイルアライアンス（ＯＭＡ：Open Mobile Alliance）に従って通信をサポートするサーバ、軽量のマシントゥマシンの（ＬＷＭ２Ｍ：Lightweight Machine to Machine）プロトコルなどを用いることができる。

上述の実施形態の装置及び方法は、コンピュータシステム（特に、コンピューターハードウェア又はコンピューターソフトウェア）として、又は、特別に生産された若しくは適用された集積回路として、さらには、開示された構造のコンポーネント及びユーザとの相互動作として、実現されてもよい。

上記の実施形態の方法は、コンピュータープログラムとして提供されてもよく、又は、コンピューター若しくは他のプロセッサー上で実行された時に、上記に開示された方法を行なうように構成されたコンピュータープログラムを搬送するコンピュータプログラムプロダクトあるいはコンピューター読取り可能な媒体として提供されてもよい。

用語「コンピューター読取り可能な媒体」は、限定をするものではなく、コンピューター又はコンピュータシステムによって直接読まれてアクセスすることができる、あらゆる１又は複数の媒体を含んでいる。媒体は、制限をするものではないが、フロッピーディスク、ハードディスク記憶媒体及び磁気テープのような磁気記憶媒体を含むことができ、光ディスクまたはＣＤ−ＲＯＭのような光学的記憶媒体を含むことができ、ＲＡＭ、ＲＯＭ及びフラッシュメモリーを含むメモリのような電気的記憶媒体を含むことができ、さらには、磁気／光学記憶媒体のような上記のハイブリッド及び組合せを含むことができる。

本発明の特定の例示は上記に開示されているが、当業者は多くの等価な変形及び変更が可能性であることを認識するだろう。従って、上述された本発明の典型的な実施形態は、実例であり、制限をするものではないと考えられる。開示された実施形態への様々な修正は、本発明の精神及び範囲から外れることなく、行なわれてもよい。

Claims

ソフトウェアアップデートシステムであって、
アップデートされる非ＯＳシステムソフトウェアを有するクライアントデバイスと、
前記クライアントデバイスから遠隔に位置して、前記クライアントデバイスと通信可能なクライアントアップデートサーバと、
前記クライアントデバイスに関するテクニカルケーパビリティーデータにアクセスするように構成されたデバイスケーパビリティーマネージャーと、
を備え、
前記クライアントアップデートサーバは、前記クライアントデバイスの非ＯＳシステムソフトウェアの少なくとも一部をアップデートするのに必要な第１アップデートを検索するように構成されており、
前記クライアントアップデートサーバは、前記デバイスケーパビリティーマネージャーと協働して、前記クライアントデバイスのアップデートを最適化するように、前記第１アップデートに適用する編制スキームを決定するように構成されたアップデートオプティマイザーを備えており、前記決定した編制スキームは、前記クライアントデバイスのテクニカルケーパビリティーと互換性を有しており、前記アップデートオプティマイザーは、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから、前記第１アップデートをリカバリーするリカバリーファンクションを識別するように構成されており、
前記デバイスケーパビリティーマネージャーは、前記クライアントデバイスに求められる必要なファンクショナリティを判定するために前記テクニカルケーパビリティーデータを使用して、前記アップデートオプティマイザーによって識別された前記リカバリーファンクションを実行するように構成されており、
前記クライアントアップデートサーバは、前記アップデートオプティマイザーに応じてアップデートパッケージジェネレーターを備えており、前記クライアントデバイスがリカバリーファンクションをサポート可能にする第２アップデートを備えるアップデートパッケージを生成するように構成されており、
前記クライアントアップデートサーバは、前記クライアントデバイスに前記アップデートパッケージを伝達するように構成されたアップデート通信ユニットを備えており、
前記クライアントデバイスは、前記アップデートパッケージを受信し、前記第２アップデートを抽出して、インストールするように構成されている、システム。
前記クライアントアップデートサーバは、前記第１アップデートの前に、前記クライアントデバイスに前記アップデートパッケージを伝達するように前記アップデート通信ユニットに命じるように構成されている、
請求項１に記載のシステム。
前記クライアントアップデートサーバは、前記アップデートパッケージと前記選択された編制スキームに従って編制された第１アップデートのインスタンスとを、前記クライアントデバイスへ別々に伝達するように、アップデート通信ユニットに命じるように構成される、
請求項１又は請求項２に記載のシステム。
前記アップデート通信ユニットは、前記選択された編制スキームに従って編制された第１アップデートのインスタンスから前記第１アップデートのリカバリーを促進するために、前記アップデートパッケージを受信することを期待する前記クライアントデバイスに、アドバイスを送信するように構成されている、
請求項１に記載のシステム。
前記アップデート通信ユニットは、前記アップデートパッケージの前に、前記選択された編制スキームに従って編制された第１アップデートのインスタンスを送信するように構成されており、前記クライアントデバイスへの前記アドバイスは、前記選択された編制スキームに従って編制された第１アップデートのインスタンスに付随している、
請求項４に記載のシステム。
前記クライアントアップデートサーバは、アップデートのリポジトリから前記第１アップデートを検索するように構成されている、
請求項１乃至請求項５のいずれかに記載のシステム。
前記クライアントアップデートサーバは、前記デバイスケーパビリティーマネージャーによってアクセス可能なケーパビリティーデータレポジトリを備えており、前記ケーパビリティーデータレポジトリは、クライアントデバイスにサポートされた既存のファンクショナリティを記録する、
請求項１乃至請求項６のいずれかに記載のシステム。
前記デバイスケーパビリティーマネージャーは、前記ケーパビリティーデータレポジトリを参照して、前記リカバリーファンクションを実行するのに前記クライアントデバイスに求められる前記必要なファンクショナリティを判定するように構成されている、
請求項７に記載のシステム。
前記デバイスケーパビリティーマネージャーは、前記クライアントデバイスに求められる前記必要なファンクショナリティを構成するファンクショナリティ差異を識別するために、前記クライアントデバイスにサポートされている既存のファンクショナリティを、前記クライアントデバイスに求められるターゲットファンクショナリティと、比較するように構成されている、
請求項８に記載のシステム。
前記クライアントアップデートサーバは、ファンクショナリティリポジトリを備えており、前記ファンクショナリティリポジトリは、複数のオペレーティングファンクションを備えている、
請求項１乃至請求項９のいずれかに記載のシステム。
前記アップデートパッケージジェネレーターは、前記ファンクショナリティリポジトリからオペレーティングファンクションを検索するために前記ファンクショナリティリポジトリにアクセスし、前記ファンクショナリティ差異のファンクショナリティの少なくとも一部を提供するように構成されている、
請求項９に従属する場合における請求項１０に記載のシステム。
前記第２アップデートは、前記オペレーティングファンクションを備える、
請求項１１に記載のシステム。
前記アップデートパッケージジェネレーターは、前記選択された編制スキームに従って編制された前記第１アップデートを備える別のアップデートパッケージを生成するように構成されている、
請求項１乃至請求項１２のいずれかに記載のシステム。
前記アップデートオプティマイザーは、前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから前記第１アップデートをリカバリーするリカバリーファンクションと結合して適用される別のリカバリーファンクションを識別するように構成されている、
請求項１乃至請求項１３のいずれかに記載のシステム。
前記非ＯＳシステムソフトウェアは、ファームウェアである、
請求項１乃至請求項１４のいずれかに記載のシステム。
前記クライアントデバイスは、通信モジュールを備えており、前記第１アップデートは、前記通信モジュールに関連する、
請求項１乃至請求項１５のいずれかに記載のシステム。
前記編制スキームは、
圧縮スキームと、
暗号化スキームと、
データデファレンシングスキームと、
デルタ符号化スキームと、
のうちの少なくとも１つを備える、
請求項１乃至請求項１６のいずれかに記載のシステム。
前記アップデートパッケージジェネレーターは、前記デバイスケーパビリティーマネージャーによって判定された前記クライアントデバイスに求められる前記必要なファンクショナリティに応答することにより、前記デバイスケーパビリティーマネージャーに応答する、
請求項１乃至請求項１７のいずれかに記載のシステム。
求められる前記必要なファンクショナリティの前記デバイスケーパビリティーマネージャーによる判定は、前記アップデートオプティマイザーによって識別された前記リカバリーファンクションを実行するためにクライアントデバイスに欠いているファンクショナリティの判定である、
請求項１乃至請求項１８のいずれかに記載のシステム。
前記アップデートオプティマイザーは、
揮発性メモリ使用、
不揮発性メモリ使用、
メモリの物理ブロックのサイズ、
前記第１アップデートの実行に関連した変更の分布の程度、
アップデートパッケージのサイズ、及び／又は、
クライアントデバイスに要求される処理時間、
のうちの１つ以上の基準に基づいて、前記編制スキームを選択する、
請求項１乃至請求項１９のいずれかに記載のシステム。
前記リカバリーファンクションは、コンパイルされたコード、コンパイルされたスクリプト、解釈可能なコード、又は、解釈可能なスクリプトである、
請求項１乃至請求項２０のいずれかに記載のシステム。
前記第１アップデートは、前記クライアントデバイスの非アップデートメンテナンスファンクショナルアスペクトに関連する、
請求項１乃至請求項２１のいずれかに記載のシステム。
前記非アップデートメンテナンスファンクショナルアスペクトは、
乱数を生成するための方法、チェックサムを算出するための方法、後のアップデートパッケージに続くデータをデコードする方法、前記アップデートパッケージを解凍する方法、ＧＮＳＳレシーバーの機能、ボコーダープラグイン、新機能、新しいＡＴコマンド、又は、セキュリティパッチである、
請求項２２に記載のシステム。
前記クライアントアップデートサーバは、前記クライアントデバイスを備える一群のクライアントデバイスをアップデートするのに必要な前記第１アップデートを識別するように構成されており、
前記アップデート通信ユニットは、前記一群のクライアントデバイスのすべてのクライアントデバイスの前記アップデートパッケージに、無線で通信するように構成されている、
請求項１乃至請求項２３のいずれかに記載のシステム。
前記アップデートパッケージ及び／又は第１アップデートは、前記クライアントデバイスからのレスポンスを要求するクエリーがない、
請求項１乃至請求項２４のいずれかに記載のシステム。
前記アップデートパッケージジェネレーターは、デルタファイルジェネレーターを備える、
請求項１乃至請求項２５のいずれかに記載のシステム。
前記アップデートパッケージジェネレーターは、前記ケーパビリティーデータレポジトリの参照により前記リカバリーファンクションを実行するために、前記クライアントデバイスに求められる前記必要なファンクショナリティを判定するように構成されている、
請求項７に記載のシステム。
前記アップデートパッケージジェネレーターは、前記クライアントデバイスに求められる前記必要なファンクショナリティを構成するファンクショナリティ差異を識別するために、前記クライアントデバイスにサポートされた既存のファンクショナリティを、前記クライアントデバイスに求められるターゲットファンクショナリティと、比較するように構成されている、
請求項８に記載のシステム。
前記デバイスケーパビリティーマネージャーは、前記アップデートパッケージジェネレーターからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されている、
請求項２７又は請求項２８に記載のシステム。
前記クライアントアップデートサーバは、ＯＭＡＤＭサーバ（オープンモバイルアライアンスデータマネージメントサーバ）及び前記ＯＭＡＤＭサーバによってアクセス可能なケーパビリティーデータレポジトリを備え、
前記ケーパビリティーデータレポジトリは、前記クライアントデバイスにサポートされた既存のファンクショナリティを記録している、
請求項１乃至請求項６のいずれかに記載のシステム。
前記ＯＭＡＤＭサーバは、前記アップデートパッケージジェネレーターからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されている、
請求項３０に記載のシステム。
前記デバイスケーパビリティーマネージャーは、ファンクションリスト依頼メッセージを受信し、これに応じて、ＯＭＡＤＭサーバへファンクションリスト依頼を送るように構成されており、
前記ＯＭＡＤＭサーバは、前記デバイスケーパビリティーマネージャーからのファンクションリスト依頼メッセージの受信に応じて、前記クライアントデバイス又はクライアントデバイスのタイプに保持されているファンクショナリティを判定するように構成されている、
請求項３０に記載のシステム。
前記アップデートパッケージは、データ構造定義に従って前記クライアントデバイスに伝達され、
前記データ構造定義は、前記アップデートパッケージを含むために予約された、必要なファンクショナリティコンテンツフィールドを備える、
請求項１乃至請求項３２のいずれかに記載のシステム。
前記データ構造定義は、
前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスを含むために予約された、アップデートコンテンツフィールドをさらに備える、
請求項３３に記載のシステム。
前記データ構造定義は、
前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスのリカバリーに関連したファンクションの識別子を含むために予約された、ファンクションインディケーターフィールドをさらに備え、
前記ファンクションインディケーターフィールドは、前記必要なファンクショナリティコンテンツフィールドに付随するように構成される、
請求項３３に記載のシステム。
前記データ構造定義は、
別のアップデートパッケージ含むために予約された、別の必要なファンクショナリティコンテンツフィールドをさらに備える、
請求項３５に記載のシステム。
前記データ構造定義は、
別の編制されたアップデートのインスタンスを含むために予約された、別のアップデートコンテンツフィールドをさらに備える、
請求項３４、請求項３５又は請求項３６に記載のシステム。
前記データ構造定義は、
前記別の編制されたアップデートのインスタンスのリカバリーに関連した別のファンクションの別の識別子を含むために予約された、別のファンクションインディケーターフィールドをさらに備え、
前記別のファンクションインディケーターフィールドは、前記別の必要なファンクショナリティコンテンツフィールドに付随するように構成される、
請求項３６に従属する場合における請求項３７に記載のシステム。
請求項１乃至請求項３８のいずれかに記載のソフトウェアアップデートシステムを備える、ファームウェアオーバーザエアーアップデートシステム。
アップデートされる非ＯＳシステムソフトウェアを有するクライアントデバイスをアップデートする方法であって、
前記クライアントデバイスに関するケーパビリティーデータにアクセスするステップと、
前記クライアントデバイスの前記非ＯＳシステムソフトウェアの少なくとも一部をアップデートするのに必要な第１アップデートを検索するステップと、
前記クライアントデバイスのアップデートを最適化するように、前記第１アップデートに適用される、編制スキームを決定するステップであって、前記決定された編制スキームは、前記クライアントデバイスのテクニカルケーパビリティーと互換性がある、ステップと、
前記選択された編制スキームに従って編制された前記第１アップデートのインスタンスから前記第１アップデートをリカバリーするためのリカバリーファンクションを識別するステップと、
アップデートオプティマイザーによって識別されたリカバリーファンクションを実行するために前記クライアントデバイスに求められる必要なファンクショナリティを判定するために、前記ケーパビリティーデータを使用するステップと、
前記クライアントデバイスに求められる前記必要なファンクショナリティの判定に応じて、アップデートパッケージを生成するステップであって、前記アップデートパッケージは、前記クライアントデバイスがリカバリーファンクションをサポート可能にする第２アップデートを備えている、ステップと、
前記クライアントデバイスに前記アップデートパッケージを伝達するステップと、
前記クライアントデバイスが前記アップデートパッケージを受信し、前記第２アップデートを抽出し、インストールするステップと、
を備える方法。