特許 7731885 パッケージベースリモートファームウェアアップデート

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-08-22

(45)【発行日】2025-09-01

(54)【発明の名称】パッケージベースリモートファームウェアアップデート

(51)【国際特許分類】

   G06F 8/65 20180101AFI20250825BHJP

   G06F 21/57 20130101ALI20250825BHJP

【ＦＩ】

G06F8/65

G06F21/57

【請求項の数】 14

(21)【出願番号】P 2022535248

(86)(22)【出願日】2020-12-11

(65)【公表番号】

(43)【公表日】2023-02-13

(86)【国際出願番号】 US2020064516

(87)【国際公開番号】W WO2021119430

(87)【国際公開日】2021-06-17

【審査請求日】2023-11-13

(31)【優先権主張番号】16/712,310

(32)【優先日】2019-12-12

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

(73)【特許権者】

【識別番号】523325484

【氏名又は名称】ランディス・ギア・テクノロジー・インコーポレイテッド

【氏名又は名称原語表記】ＬＡＮＤＩＳ＋ＧＹＲ ＴＥＣＨＮＯＬＯＧＹ， ＩＮＣ．

(74)【代理人】

【識別番号】100145403

【弁理士】

【氏名又は名称】山尾 憲人

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部 英隆

(74)【代理人】

【識別番号】100189544

【弁理士】

【氏名又は名称】柏原 啓伸

(72)【発明者】

【氏名】シャック，オーガスト ダブリュー

【審査官】西間木 祐紀

(56)【参考文献】

【文献】米国特許出願公開第２０１３／０１８５５４８（ＵＳ，Ａ１）

【文献】特開２０１７－０９７８０９（ＪＰ，Ａ）

【文献】特開２００９－１３９９９７（ＪＰ，Ａ）

【文献】特開２０１７－０２１４３４（ＪＰ，Ａ）

【文献】特表２０１６－５０７８０６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６５

Ｇ０６Ｆ ２１／５７

(57)【特許請求の範囲】

【請求項1】

ファームウェアをアップデートする方法であって、
デバイスにて、該デバイスにファームウェアをインストールするために該デバイスに格納されたインストールパッケージのセットに属する、インストールパッケージのアップデートされたバージョンを含む、アップデートされたインストールパッケージを受信するステップと、
前記デバイスに格納されたインストールパッケージのセットにて、前記インストールパッケージを前記アップデートされたインストールパッケージと置換することにより、前記インストールパッケージのセットをアップデートするステップと、
前記アップデートされたインストールパッケージを含む前記アップデートされたインストールパッケージのセットに基づいて、アップデートされたファームウェアを前記デバイスの揮発性メモリにインストールするステップと、
前記デバイスにて、該デバイスにインストールされた前記アップデートされたファームウェアの真正バージョンの署名付きバリデーションハッシュを受信するステップと、
前記デバイスにインストールされた前記アップデートされたファームウェアのハッシュを生成するステップと、
前記ハッシュが前記アップデートされたファームウェアの真正バージョンの前記署名付きバリデーションハッシュと一致することを確認するステップと、
前記アップデートされたファームウェアのイメージを前記デバイスの不揮発性ストレージに格納するステップと、並びに、
前記デバイスのブートの間には、
前記揮発性メモリから前記アップデートされたファームウェアを実行できるように、前記アップデートされたファームウェアの前記イメージを前記デバイスの前記不揮発性ストレージから前記デバイスの前記揮発性メモリにロードするステップと、
前記アップデートされたファームウェアをハッシュ化し、現在のハッシュを生成するステップと、及び、
前記アップデートされたファームウェアの前記現在のハッシュが、前記アップデートされたファームウェアの真正バージョンの前記署名付きバリデーションハッシュと一致するか否かを確認することにより、前記アップデートされたファームウェアの真正性を検証することを試みるステップと
を、含む、方法。

【請求項2】

インストールパッケージの前記セットが、複数のインストールパッケージを含み、
インストールパッケージの前記セットをアップデートするステップは、
インストールパッケージの前記セットの適切なサブセットを、アップデートされたバージョンで置換するステップを、含む、
請求項１記載の方法。

【請求項3】

前記アップデートされたファームウェアが、ファイルシステムである、
請求項１又は請求項２に記載の方法。

【請求項4】

前記デバイスが、ユーティリティメータであり、
前記アップデートされたインストールパッケージが、無線ネットワークを介して受信される、
請求項１又は請求項２に記載の方法。

【請求項5】

サーバを含むシステムであって、
コンピュータ可読命令を実行するように構成されたサーバプロセッサと、
前記サーバプロセッサによって実行されると、
アップデートされたインストールパッケージを特定するステップと、
前記アップデートされたインストールパッケージをインストールパッケージのセットに挿入して、前記アップデートされたインストールパッケージの既存のバージョンを置換することにより、インストールパッケージの前記セットを、インストールパッケージのアップデートされた前記セットにアップデートするステップと、
前記アップデートされたインストールパッケージを含む、インストールパッケージのアップデートされた前記セットをインストールして、リファレンスファームウェアを生成するステップと、
インストールされた前記リファレンスファームウェアに基づいて署名付きバリデーションハッシュを生成するステップと、
前記アップデートされたインストールパッケージと前記署名付きバリデーションハッシュを前記サーバからリモートで一つ以上のノードに提供して、前記一つ以上のノードが前記アップデートされたインストールパッケージを利用して前記一つ以上のノードをアップデートするステップと、を含む動作を、
前記サーバプロセッサに実行させるコンピュータ可読命令を、格納するように構成されたサーバメモリと
を、前記サーバが含み、
さらに、
前記ノードは、該ノードの動作を実行するためにコンピュータ可読命令を実行するように構成されたノードプロセッサを含み、
前記ノードの動作は、
アップデートされたファームウェアのイメージを前記ノードの不揮発性ストレージに格納するステップと、並びに、
前記ノードのブートの間に、
前記ファームウェアの前記イメージを前記ノードの前記不揮発性ストレージから前記ノードの揮発性メモリにロードして、前記揮発性メモリから前記ファームウェアを実行できるようにするステップと、
アップデートされた前記ファームウェアをハッシュ化し、現在のハッシュを生成するステップと、及び、
アップデートされた前記ファームウェアの前記現在のハッシュが、アップデートされた前記ファームウェアの真正バージョンの前記署名付きバリデーションハッシュと一致するか否かを確認することにより、前記ファームウェアの真正性を再検証することを試みるステップと、
を含む、システム。

【請求項6】

さらに、
前記ノードの動作は、
前記アップデートされたインストールパッケージと前記署名付きバリデーションハッシュを受信するステップと、
前記ノードに格納されたインストールパッケージのローカルセットにて、前記アップデートされたインストールパッケージの既存のバージョンを前記アップデートされたインストールパッケージと置換することによって、インストールパッケージの前記ローカルセットをアップデートするステップと、
前記アップデートされたインストールパッケージを含むインストールパッケージの前記ローカルセットに基づいて、前記ノードの前記揮発性メモリに前記ファームウェアをインストールして、前記揮発性メモリから前記ファームウェアを実行できるようにするステップと、
前記ファームウェアのハッシュを、前記署名付きバリデーションハッシュと比較することによって、前記ファームウェアの真正性を検証するステップと
を含む、
請求項５に記載のシステム。

【請求項7】

前記ファームウェアの前記真正性を再検証することを試みるステップは、
前記ファームウェアの前記現在のハッシュが前記署名付きバリデーションハッシュと等しくないことを検出するステップを含み、
さらに、
前記ノードの動作は、
前記ファームウェアの前記現在のハッシュが前記署名付きバリデーションハッシュと等しくないことに基づいて、インストールパッケージの前記ローカルセット内の一つ以上のインストールパッケージの置換を前記サーバから要求するステップを、含む、
請求項６に記載のシステム。

【請求項8】

インストールパッケージの前記ローカルセットは、複数のインストールパッケージを含み、
インストールパッケージの前記ローカルセットをアップデートするステップは、
インストールパッケージの前記ローカルセットの適切なサブセットを、アップデートされたバージョンで置換するステップを含む、
請求項６又は請求項７に記載のシステム。

【請求項9】

前記ノードが、ユーティリティメータである、
請求項５又は請求項６に記載のシステム。

【請求項10】

前記ファームウェアは、前記ユーティリティメータのためのファイルシステムである、請求項９に記載のシステム。

【請求項11】

ファイルシステムをアップデートする方法であって、
デバイスにて、該デバイスのファイルシステムのインストールのために該デバイスに格納されたインストールパッケージのセットに属する、インストールパッケージのアップデートされたバージョンを含む、アップデートされたインストールパッケージを受信するステップと、
前記デバイスに格納されたインストールパッケージのセットにおいて、前記インストールパッケージを前記アップデートされたインストールパッケージと置換することによって、インストールパッケージの前記セットをアップデートするステップと、
前記アップデートされたインストールパッケージを含む、前記アップデートされたインストールパッケージのセットに基づいて、前記デバイスの揮発性メモリ内に、アップデートされたファイルシステムをインストールするステップと、
前記デバイスにて、前記デバイスにインストールされた前記アップデートされたファイルシステムの真正バージョンの署名付きバリデーションハッシュを受信するステップと、
前記デバイスにインストールされた前記アップデートされたファイルシステムのハッシュを生成するステップと、
前記アップデートされたファイルシステムのハッシュを、前記署名付きバリデーションハッシュと比較することによって、前記アップデートされたファイルシステムをバリデーションするステップと、
前記アップデートされたファイルシステムのイメージを前記デバイスの不揮発性ストレージ内に格納するステップと、並びに、
前記デバイスのブートの間に、
前記揮発性メモリから前記アップデートされたファイルシステムを実行できるように、前記アップデートされたファイルシステムの前記イメージを前記デバイスの前記不揮発性ストレージから前記デバイスの前記揮発性メモリにロードするステップと、
前記アップデートされたファイルシステムをハッシュ化し、アップデートされたハッシュを生成するステップと、及び、
前記アップデートされたファイルシステムのアップデートされたハッシュを前記アップデートされたファイルシステムの真正バージョンの前記署名付きバリデーションハッシュと比較することによって、前記アップデートされたファイルシステムの再バリデーションを試みるステップと
を含む、方法。

【請求項12】

前記アップデートされたファイルシステムの再バリデーションを試みるステップは、
前記デバイスの前記不揮発性ストレージから前記デバイスの前記揮発性メモリに、前記アップデートされたファイルシステムの前記イメージをロードした後に、前記揮発性メモリに格納された前記アップデートされたファイルシステムをハッシュ化することによって、前記アップデートされたハッシュを生成するステップを、含む、
請求項１１に記載の方法。

【請求項13】

前記アップデートされたファイルシステムの再バリデーションを試みるステップは、
前記アップデートされたファイルシステムの前記イメージを、前記デバイスの前記不揮発性ストレージから前記デバイスの前記揮発性メモリにロードする前に、前記アップデートされたファイルシステムの前記イメージをハッシュ化することによって、前記アップデートされたハッシュを生成するステップを、含む、
請求項１１に記載の方法。

【請求項14】

前記アップデートされたインストールパッケージを受信するステップは、無線メッシュネットワークを介して前記アップデートされたインストールパッケージをダウンロードするステップを含む、
請求項１１から請求項１３のいずれか１項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
本明細書で説明する様々な実装は、ファームウェアアップデートに関し、より詳細には、ファームウェアのインストールが多数の組み合わせ可能なインストールパッケージに分割され、さらに、ファームウェアの真正性が任意に検証可能であるようなパッケージベースであるファームウェアアップデートに関連する。

【背景技術】

【0002】

背景
ファームウェアは、ハードウェアデバイスの低レベル制御を提供するソフトウェアの一種である。典型的には、ハードウェアデバイスと相互作用するために、ソフトウェアアプリケーションは、ファームウェアと通信し、ファームウェアは、ソフトウェアアプリケーションがハードウェアデバイスを利用できるようにするために必要に応じてハードウェアデバイスと相互作用することになる。デバイスのファームウェアは、新機能のインストールやバグの修正など、様々な理由でアップデートする必要がある場合がある。デバイスのファームウェアのアップデートは、様々な方法で実行することができる。例えば、ユニバーサルシリアルバス（ＵＳＢ）ケーブルやイーサネットケーブルなどのケーブルを介して、アップデートされたファームウェアを受信することができる。別の例として、リモートファームウェアアップデートの場合、ファームウェアは、ワイヤレスフィデリティ（ＷｉＦｉ）などを介してワイヤレスに受信することができる。

【発明の概要】

【0003】

一実施態様では、ファームウェアをアップデートする方法は、デバイスにおいて、アップデートされたインストールパッケージを受信することを含む。アップデートされたインストールパッケージは、デバイスにファームウェアをインストールするためにデバイス上に格納されたインストールパッケージのセットに属する、インストールパッケージのアップデートされたバージョンを含む。本方法はさらに、デバイスに格納されたインストールパッケージのセットにおいて、インストールパッケージをアップデートされたインストールパッケージと置換することによって、インストールパッケージのセットをアップデートすることを含む。本方法はさらに、アップデートされたインストールパッケージを含むアップデートされたインストールパッケージのセットに基づいて、デバイスの揮発性メモリにアップデートされたファームウェアをインストールすることを含む。本方法はさらに、アップデートされたファームウェアのイメージをデバイスの不揮発性ストレージに格納することを含む。さらに、本方法は、ブートプロセスの間に、アップデートされたファームウェアのイメージをデバイスの不揮発性メモリからデバイスの揮発性メモリにロードして、揮発性メモリからアップデートされたファームウェアを実行できるようにし、アップデートされたファームウェアの真正性を検証しようと試みることを含む。

【0004】

別の実施態様では、システムは、プロセッサとメモリとを含むサーバを含む。プロセッサは、コンピュータ可読命令を実行するように構成され、メモリは、プロセッサによって実行されたとき、プロセッサに動作を実行させるコンピュータ可読命令を格納するように構成される。かかる動作は、アップデートされたインストールパッケージを識別することと、アップデートされたインストールパッケージをインストールパッケージのセットに挿入して、アップデートされたインストールパッケージの既存のバージョンと置換することとを含む。動作はさらに、アップデートされたインストールパッケージを含むインストールパッケージのセットをインストールして、リファレンスファームウェアを生成することを含む。動作はさらに、リファレンスファームウェアに基づいて署名付きバリデーションハッシュを生成し、アップデートされたインストールパッケージと署名付きバリデーションハッシュをサーバからリモートで一つ以上のノードに提供することを含む。一つ以上のノードは、アップデートされたインストールパッケージを利用して、一つ以上のノードをアップデートする。

【0005】

さらに別の実施態様では、ファイルシステムをアップデートする方法は、デバイスにおいて、アップデートされたインストールパッケージを受信することを含む。アップデートされたインストールパッケージは、インストールパッケージのアップデートされたバージョンを含み、インストールパッケージは、デバイス上のファイルシステムのインストール用にデバイス上に格納されたインストールパッケージのセットに属する。本方法はさらに、ファイルシステムに関連付けられる署名付きバリデーションハッシュを受信することを含む。本方法はさらに、デバイス上に格納されたインストールパッケージのセットにおいて、インストールパッケージをアップデートされたインストールパッケージと置換することによって、インストールパッケージのセットをアップデートすることを含む。本方法はさらに、アップデートされたインストールパッケージを含む、アップデートされたインストールパッケージのセットに基づいて、デバイスの揮発性メモリ内にアップデートされたファイルシステムをインストールすることと、アップデートされたファイルシステムのハッシュを署名付きバリデーションハッシュと比較することによって、アップデートされたファイルシステムをバリデーションすることとを含む。本方法はさらに、アップデートされたファイルシステムのイメージをデバイスの不揮発性ストレージ内に格納することを含む。さらに、本方法は、デバイスのブートの間に、デバイスの不揮発性メモリからデバイスの揮発性メモリ上にアップデートされたファイルシステムのイメージをロードして、揮発性メモリからのアップデートされたファイルシステムの実行を可能にし、アップデートされたファイルシステムのアップデートされたハッシュを署名付きバリデーションハッシュと比較することによって、アップデートされたファイルシステムの再バリデーションを試みることを、含む。

【0006】

これらの例示的な態様および特徴は、現在説明されている主題を制限または定義するためではなく、本願で説明される概念の理解を助けるために例を提供するために言及されている。現在説明されている主題の他の態様、利点、および特徴は、本出願全体を検討した後に明らかになるであろう。

【図面の簡単な説明】

【0007】

本開示のこれらおよび他の特徴、態様、および利点は、以下の詳細な説明を添付図面を参照しながら読むと、よりよく理解される。

【0008】

【図1】図１は、本明細書に記載されるいくつかの実装に係る、一つ以上のノードにインストールされたファームウェアをアップデートするためのアップデートシステムの図である。

【図2】図２は、本明細書に記載されるいくつかの実装に係る、一つ以上のノードのためのファームウェアアップデートパッケージを生成する方法を示す図である。

【図3】図３は、本明細書に記載されるいくつかの実装に係る、ファームウェアアップデートパッケージを生成する際のプロバイダサーバの通信フローを示す図である。

【図4】図４は、本明細書に記載されるいくつかの実施態様に係る、ノードでのファームウェアをアップデートする方法を示す図である。

【図5】図５は、本明細書に記載されるいくつかの実装に係る、ファームウェアアップデートパッケージ内のアップデートされたインストールパッケージに基づいてファームウェアをインストールするときの、ノードの通信フローを描写している。

【図6】図６は、本明細書に記載されるいくつかの実装に係る、ノード、具体的にユーティリティメータの図を示す。

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

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

図２に示すように、ブロック２０５で、プロバイダサーバ１１０は、ファームウェア１４０をアップデートするためのアップデートされたインストールパッケージ１５５を特定する。一例では、プロバイダサーバ１１０は、アップデートされたインストールパッケージ１５５がセットのメンバーであるように、ファームウェア１４０のアップデートされたバージョンに対する統合インストールパッケージをパッケージセット１５０（すなわち、インストールパッケージ１５５のセット）に分割することによって、アップデートされたインストールパッケージ１５５を生成する。その場合、統合インストールパッケージ１５５は、プロバイダサーバ１１０によって生成されたか、または管理者によるアップロードを介してなど、プロバイダサーバ１１０に提供されたものであってもよい。別の例では、プロバイダサーバ１１０は、管理者によるアップロードなどによって、アップデートされたインストールパッケージ１５５を単に受信するだけでよい。アップデートされたインストールパッケージ１５５をプロバイダサーバ１１０に提供するために様々な技術が利用可能であることが理解されよう。

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

本主題は、その態様の側面に関して詳細に説明されてきたが、当業者は、前述の理解を得た時点で、そのような態様に対する変更、変形、および等価物を容易に作り出すことができることが理解されよう。したがって、本開示は、限定ではなく例示の目的で提示されており、当業者に容易に明らかになるような本主題に対する変更、変形、および／または追加を含めることを排除するものではないことを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】