(57)【要約】【課題】  ソフトウェア・アップデートを、自己充足型の、信頼できるエンティティの形で、内蔵デバイスの不揮発性ストレージに対して、フェイルセーフな方法で適用すること。【解決手段】  様々なソフトウェア・アップデートに適用でき、アップデートには実行可能コードおよび／またはデータを含むことができる。再ブート後に、イニシャル・プログラム・ローダーがアップデート・モードを確認し、専用のアップデート・ローダーにブートする。アップデート・ローダーはアップデート・パッケージを処理してアップデートを適用する。カーネル・パーティション、システム・パーティション、予約セクションの各アップデートは、ファイル全体又はバイナリ差分ファイルの使用が可能で、双方にエラー処理メカニズムが提供される。アップデートをコミットする前にアップデートのシミュレーションを実行できる。アップデートは、デバイスに応じてメモリ内に再配置される。【選択図】  図３
2005196747.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・デバイスにおいて、デバイスをオペレーティング・システム・モードにブートするかアップデート・モードにブートするかを決定すること、および
前記デバイスが前記アップデート・モードにブートした場合に、アップデート中に発生する可能性のある障害の復旧を可能にするために、前記アップデートの状態をログに記録しながら前記デバイスのストレージ内のイメージに対する少なくとも１つのアップデートを実行すること
を備えることを特徴とする方法。
【請求項２】
前記デバイスをオペレーティング・システム・モードにブートするかアップデート・モードにブートするかを決定することは、再ブートの前に設定されるフラグを検査することを備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記イメージは少なくとも２つのパーティションに分割されており、前記パーティションの代替イメージを作成し、前記代替イメージを前記パーティションの既存のイメージに上書きすることによって、選択されたパーティションはアップデートされることを特徴とする請求項１に記載の方法。
【請求項４】
前記パーティション内の前記既存のイメージをバックアップ・イメージにバックアップすること、
前記代替イメージの書き込みが正常に終了したかどうかを確認すること、および
正常に終了しなかった場合に前記バックアップ・イメージから前記既存のイメージをリストアすること
をさらに備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記既存のイメージをバックアップすることは、前記バックアップ・イメージを圧縮形式で格納することを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記イメージは、少なくとも２つのパーティションに分割されており、前記イメージ内の少なくとも２つのコンポーネントについて個別にアップデートすることによって、選択されたパーティションはアップデートされることを特徴とする請求項１に記載の方法。
【請求項７】
前記パーティションの１つはシステム・パーティションであり、イメージ内の前記少なくとも２つのコンポーネントについて個別にアップデートすることは、オペレーティング・システム・ファイルを前記パーティションに書き込むことを備えることを特徴とする請求項６に記載の方法。
【請求項８】
前記少なくとも１つのアップデートを実行することは、既存のコンポーネントにバイナリ差分ファイルを適用することを備えることを特徴とする請求項１に記載の方法。
【請求項９】
既存のコンポーネントにバイナリ差分ファイルを適用することは、前記既存のコンポーネントのサブセットに前記バイナリ差分ファイルのサブセットを適用することを備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記サブセットは指定されたサイズのデータのブロックを備えることを特徴とする請求項９に記載の方法。
【請求項１１】
イメージへの少なくとも１つのアップデートを実行することは、アップデート・プロセスのシミュレーションを行うこと、およびアップデートをコミットする前にシミュレーションが成功したことを確認することを備えることを特徴とする請求項９に記載の方法。
【請求項１２】
一連のアップデートにおけるそれぞれの前記アップデートは、パッケージおよびファイル中のファイルについて、個別に実行され、前記個々のパッケージおよびファイルの情報が、障害を辿ることができるようにログ・ファイルに記録され、前記ログ・ファイルにアクセスすることでどのパッケージおよびそのパッケージのどのファイルで前記障害が発生したかを決定できることを特徴とする請求項１に記載の方法。
【請求項１３】
実行すると請求項１に記載の方法を実現するコンピュータで実行可能な命令を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項１４】
コンピューティング環境において、オペレーティング・システム・イメージを別々のアップデート可能な複数のパーティションに分割すること、および
別のパーティションから分離した少なくとも１つのパーティションをアップデートすること
を備えることを特徴とする方法。
【請求項１５】
前記少なくとも１つのアップデートを実行することは、コンピューティング・デバイスをアップデート・モードにブートすることを備えることを特徴とする請求項１４に記載の方法。
【請求項１６】
別のパーティションから孤立した少なくとも１つのパーティションをアップデートすることは、
第１のパーティションの代替イメージを作成すること、
前記第１のパーティション内の既存のイメージに前記代替イメージを上書きで書き込むこと、および
第２のパーティションを、前記第２のパーティション内のイメージの少なくとも２つのコンポーネントを個別にアップデートすることによって、アップデートすること
を備えることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記第１のパーティション内の前記既存のイメージをバックアップ・イメージにバックアップすること、
前記代替イメージを書き込むことが正常に終了したかどうかを判断すること、および
正常に終了しなかった場合に前記バックアップ・イメージから前記イメージをリストアすること
をさらに備えることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記既存のイメージをバックアップすることは、前記バックアップ・イメージを圧縮形式で格納することを含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記第２のパーティションをアップデートすることは、アップデートされた各コンポーネントのＩＤをログ・ファイルに記録することを備え、その結果、障害が発生した場合に、ログ・ファイルにアクセスしてどのコンポーネントのアップデートで前記障害が発生したかを決定することができることを特徴とする請求項１６に記載の方法。
【請求項２０】
前記第２のパーティションをアップデートすることは、既存のコンポーネントにバイナリ差分ファイルを適用することを備えることを特徴とする請求項１６に記載の方法。
【請求項２１】
既存のコンポーネントにバイナリ差分ファイルを適用することは、前記既存のコンポーネントのサブセットに前記バイナリ差分ファイルのサブセットを適用することを備えることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記サブセットは、指定されたサイズのデータのブロックを備えることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記第２のパーティションをアップデートすることは、アップデート・プロセスのシミュレーションを行うこと、前記第２のパーティションへのアップデートをコミットする前に前記シミュレーションが成功したことを確認することを備えることを特徴とする請求項１６に記載の方法。
【請求項２４】
実行すると請求項１４に記載の方法を実現する、コンピュータで実行可能な命令を格納したことを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項２５】
コンピューティング・デバイスにおいて、
ブート・メカニズムと、
保留中のアップデートを検出すると前記ブート・メカニズムがブートするアップデート・ローダーと
を備えるシステムであって
前記アップデート・ローダーは前記デバイス・コード内でデバイスの保護されたストレージに対する書き込みのアクセス権を持つ唯一のエンティティを備え、前記保護されたストレージは少なくとも２つのパーティションを収容し、前記アップデート・ローダーは各パーティションを個別にアップデートすることを特徴とするシステム。
【請求項２６】
有効性確認プロセスをさらに備えるシステムであって、前記有効性確認プロセスは、前記アップデート・ローダーへのブートに先立って少なくとも１つのアップデート・パッケージの有効性を確認し、少なくとも１つのアップデート・パッケージが有効な場合に、前記有効性確認プロセスは、有効な個々のアップデート・パッケージをキューに配置し、前記ブート・メカニズムに対して保留中のアップデートを検出するメカニズムを設定することを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記有効性確認プロセスは、少なくとも１つのアップデート・パッケージのそれぞれが適切に署名されていることを確認することで前記パッケージの有効性を確認することを特徴とする請求項２６に記載のシステム。
【請求項２８】
前記有効性確認プロセスは少なくとも１つのアップデート・パッケージのそれぞれが適切に構成されていることを確認することで前記パッケージの有効性を確認することを特徴とする請求項２６に記載のシステム。
【請求項２９】
前記ブート・メカニズムは、再ブートの前に、設定されているフラグの値に基づいて前記デバイスをアップデート・モードにブートすることを特徴とする請求項２５に記載のシステム。
【請求項３０】
前記デバイスの前記保護されたストレージは、複数のパーティションに分割されており、選択されたパーティションの代替イメージを作成し、前記代替イメージを前記選択されたパーティションの既存のイメージに上書きすることによって、前記選択されたパーティションがアップデート・コンポーネントによってアップデートされることを特徴とする請求項２５に記載のシステム。
【請求項３１】
前記アップデート・コンポーネントは、前記選択されたパーティション内の前記既存のイメージをバックアップ・イメージにバックアップし、前記選択されたパーティションへの前記代替イメージの書き込みが正常に実行されない場合に、前記選択されたパーティションをリストアすることを特徴とする請求項３０に記載のシステム。
【請求項３２】
前記アップデート・コンポーネントは、前記既存のイメージを圧縮形式でバックアップすることを特徴とする請求項３１に記載のシステム。
【請求項３３】
前記デバイスの前記保護されたストレージは、複数のパーティションに分割されており、前記選択されたパーティション内の少なくとも２つのコンポーネントをおいて個別にアップデートすることによって前記選択されたパーティションが、前記アップデート・コンポーネントによってアップデートされることを特徴とする請求項３０に記載のシステム。
【請求項３４】
前記アップデート・ローダーは、既存のコンポーネントにバイナリ差分ファイルを適用することによって、前記選択されたパーティション内の前記コンポーネントのうちの少なくとも１つをアップデートすることを特徴とする請求項３３に記載のシステム。
【請求項３５】
前記アップデート・ローダーは、前記既存のコンポーネントのサブセットに前記バイナリ差分ファイルのサブセットを適用することによって、前記バイナリ差分ファイルを適用することを特徴とする請求項３４に記載のシステム。
【請求項３６】
前記アップデート・ローダーは、アップデートをコミットする前に、少なくとも一つのアップデートのシミュレーションを実行することを特徴とする請求項３３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピューティング・デバイスに関し、より詳細には、コンピューティング・デバイスの不揮発性ストレージのアップデートに関する。
【背景技術】
【０００２】
パーソナル・デジタル・アシスタント（ＰＤＡ：personal digital assistant）、最新の携帯電話、ハンドヘルド・コンピュータまたはポケット・サイズ・コンピュータなどのモバイル・コンピューティング・デバイスは、重要かつポピュラーなユーザ向けツールになってきている。一般に、こうしたデバイスは小型化が進んで非常に便利になっており、バッテリの消費が低減されていると同時に、ますます強力なアプリケーションを実行できるようになっている。
【０００３】
こうしたデバイスを製造するプロセス中に、埋め込みのオペレーティング・システム・イメージは一般にモノリシック構造の（monolithic）イメージ・ファイルに組み立てられており、各デバイスの不揮発性ストレージ（ＮＡＮＤまたはＮＯＲフラッシュ・メモリ、ハードディスクなど）に格納される。したがって、このようなデバイスのアップデートは、これまで、非常に複雑で、リソースを集中的に使用する作業であり、一般にはカスタム・ソリューションが必要であった。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
例えば、こうしたデバイスをアップデートするには、一連のデバイス（collection of devices）上で動作するように開発され、リリースされた単一の静的イメージを備えるまったく新しいモノリシックなイメージ・ファイルをダウンロードすることを必要とした。言うまでもないが、何を変更したかにかかわらず、大量のシステム・リソース（例えば、アップデート・イメージを一時的に保管するためのストレージやイメージ・ファイル全体を受信するためのネットワーク帯域幅など）が必要になるので、デバイスのアップデート・プロセスは１度限りのカスタム・ソリューションの使用を通常余儀なくされる。
【０００５】
求められているのは、コンピューティング・デバイスの不揮発性ストレージをアップデートするためのより優れた方法、すなわち現在のアップデート・メカニズムより柔軟でダイナミックで効率的で、しかもフェイルセーフな方法である。
【課題を解決するための手段】
【０００６】
簡単に言えば、本発明はソフトウェア・アップデートを、自己充足型の、信頼できるエンティティ（self-contained, secure entities）の形で、埋め込みのデバイスの不揮発性ストレージに対して、フェイルセーフな方法で適用するシステムおよび方法を対象とする。以前のアップデートへの変更のみを含むアップデートなどを含み、様々なソフトウェア・アップデートに対して適用できる。さらに、ソフトウェア・アップデートには実行可能コードとデータの両方を含めることができる。
【０００７】
ある実装形態では、再ブートの後に、イニシャル・プログラム・ローダーは、アップデートが要求されているか、または進行中であるかを、確認する。それらが確認された場合は、標準のオペレーティング・システム・コードでなくアップデート・ローダーをブートする（立ち上げる）。アップデート・ローダーが動作して、必要に応じて、まだ適用されていないアップデートの有効性を確認し、フラッシュ（あるいはその他の記憶媒体）に、そのアップデートを適用する。セキュリティと制御に関しては、アップデート・ローダーは、保護されたストレージ（protected storage）（例えば、ＮＫパーティションやシステム・パーティション）への書き込みのアクセス権を持つ、システム内で唯一のエンティティである。ただし、アップデート・アプリケーションも、また、フラッシュ内の予約された領域への書き込みのアクセス権を持っていることに注意されたい。
【０００８】
アップデートのために、アップデート・パッケージ（様々な形をとり得る）が、システムにダウンロードされ、パッケージの有効性確認プロセスで有効性が確認される。有効性確認プロセスには、各パッケージがセキュリティの理由で適切に署名されていることと、そのパッケージが一般的に適切に構成されていること、を確認することが含まれる。有効な場合は、アップデートがキューに入り、アップデートが要求されていることをイニシャル・プログラム・ローダーが確認するためのフラグが設定される。その後、そのデバイスが再ブートされる。
【０００９】
再ブート後に、イニシャル・プログラム・ローダーはアップデート・フラグが設定されていることを確認し、例えばアップデート・ローダーをＲＡＭに解凍し（圧縮されている場合）、アップデート・ローダーのコードにジャンプすることでアップデート・ローダーを起動させる。まずカーネル・パッケージから（カーネル・パッケージがある場合）始めて、パッケージごとに、アップデート・ローダーがそのパッケージを処理し、有効性を再確認し、必要に応じてフラッシュ・メモリに配慮しながらＲＡＭのセクションに書き込むファイルを準備（fix up）し、対応するパーティションにファイルを書き込む。イニシャル・プログラム・ローダーはフラッシュのロックを解除した状態にしているので、アップデート・ローダーがそこに書き込むことができることに注意されたい。
【００１０】
パッケージのコンテンツを説明するために、各パッケージにはパッケージに関する詳細情報を記載するデバイス・マニフェスト・ファイル（device manifest file）が含まれており、アップデート・ローダーは、パッケージ識別用の大域的に一意のＩＤ、パッケージのバージョン、他のパッケージに関連する依存情報、様々な設定、パッケージに含まれるファイルとそのバージョンのリストなどのコンテンツ（contents）を読み込む。マニフェスト・ファイルは、パッケージに含まれており、これによりパッケージは自己記述的になり、最終的にはインストールに続いてデバイスに格納される。デバイスに格納された一連のマニフェスト・ファイルは、デバイス上のパッケージのインストール状態に関する、列挙可能なデータベースを備える。
【００１１】
アップデート・ローダーは、パーティション／イメージからイメージに関する様々な情報を取得することで、圧縮イメージと非圧縮イメージを操作し、そのイメージをＲＡＭに解凍する。圧縮されていない場合は、例えばアップデートするアクティブなパーティションのロケーションを示すマスター・ブート・レコードの所在に関する事前の知識を使用して、情報をそのまま読み込む。
【００１２】
ある実装形態では、まず、カーネル・アップデートがフェイルセーフの態様で適用されて、既存のカーネルをＲＡＭに読み込んで圧縮した形でユーザ・ストレージに格納することで、本質的に既存のカーネルをバックアップする。アップデートは全体としてこのパーティションに適用され、正常に実行された場合、バックアップ・カーネルは削除され、問題が発生した場合はバックアップ・カーネルが解凍され、リストアされる。
【００１３】
システム・パーティションは、一般にカーネル・パーティションより大きく、このため通常はフェイルセーフに関連する理由でバックアップするには大きすぎる。代わりに、ＩＭＧＦＳファイル・システムを使用して、個々のモジュールやファイルに対するアップデートを１度に１つずつに適用する。個々のモジュールやファイルは全体として処理するには大きすぎる場合があるので、小さなブロックごとにアップデートを適用してよい。
【００１４】
ＩＭＧＦＳは、まずアップデート・プロセスをシミュレートする。このプロセスには２つのパスが必要である。つまり、第１のパスではＩＭＧＦＳとアップデート・アプリケーションはフラッシュへのコミットを実行しない。シミュレーションが正常に終了すると、第２のパスが実行されて実際に変更をコミットする。シミュレーションでエラーが発生した場合は、パッケージ・バリデータを再実行するとシミュレーションが再試行され、問題が発生したパッケージを除くパッケージのリストが作成される。ここで、パッケージ・バリデータが返した新しいリストを使用して、もう一度シミュレーションが実行される。シミュレーションが正常に実行されるか、適用するパッケージがなくなるまで、シミュレーションが再試行される。このことによって、署名されたパッケージ内で発生する可能性のあるデータの破損が、その破損にもかかわらず、防止される。
【００１５】
既存のデバイス・マニフェスト・ファイルを使用してＩＭＧＦＳ内のすべてのモジュールについて繰り返す際、このプロセスは、そのファイルが、そのパッケージ用の新しいデバイス・マニフェスト・ファイルに含まれているかどうかをチェックし、確認する。含まれていない場合は、そのファイルはＩＭＧＦＳパーティションから削除され、次のファイルに進む。この場合は、新しいモジュールのフラグが、新しいデバイス・マニフェスト・ファイルから取得され、モジュール・ヘッダがモジュール構造体にロードされる。
【００１６】
アップデートを達成するために、アップデート・アプリケーションは、パッケージ内のファイルを個別に処理する入れ子構造のループ（nested loop）の態様で、パッケージごとにループする。このプロセスの間に電力が失われると、ログ・ファイルは、どのパッケージのどのファイルでプロセスが中断し正確に記録され、電力が復旧した際にアップデートをレジュームできるロケーションを、教えることになる。前述の処理の一部には、アップデート・モジュールの仮想アドレス割当てコードのアップデートすること（実行可能コードに対する）が含まれる。
【００１７】
アップデートは、標準形（canonical form）でもバイナリ差分（デルタ）形式でもよい。モジュールでない場合は、仮想アドレスの設定（virtual address fix-ups）は不要であり、バイナリ・アップデートが実行されるとストレージに書き込むことができる。ファイルがモジュールの場合は、各セクションが一度に１つずつ処理され、各セクションが新しいストリームに書き込まれる（ただし、「ストリーム」はファイル・システムに関する概念であり、ＩＭＧＦＳの要素である）。ファイルが通常のデータ・ファイルの場合は、デフォルトのストリームにデータが書き込まれる。
【００１８】
モジュールが標準アップデート（canonical update）の場合は、モジュール内の各セクションが処理される。このプロセスには、仮想アロケータによって割り当てられたアドレスにセクション全体を再配置することと、セクション全体を新しいストリームとして新しいＩＭＧＦＳファイルに書き込むこと、が含まれる。古いモジュールは、古いストレージ・ブロックの割当てが解除され、新しいブロックが書き込まれるにつれて、適切にアップデートされる。標準アップデートの場合は、新しいファイル内の書き出された各ストリームのサイズを得て、標準のファイル内の該当するセクションのサイズと比較することで電源障害のリカバリが実行される。新しいファイル内のストリームが標準のファイル（canonical file）より小さい場合、それはプロセスが中断したロケーションであり、ここからデータのコピーをレジュームすればよい。
【００１９】
バイナリ差分の場合は、パッチのプロセスが一度に１ブロックずつ実行される。ただし、ブロックはページ／セクターと同じサイズでよい。これは、セクション周辺に、古いバージョンと新しいバージョンの両方を保持するための十分なフラッシュ領域がないためである。新しいブロックが作成されると、古いブロックは必要なくなるので割当てを解除できる。バイナリ差分アップデートの場合は、新しいモジュール・ファイル内の該当するセクションについてスパース・ストリーム（sparse stream）が作成され、古いセクションがＲＡＭに読み込まれる。古いセクション全体は元のベース・アドレスに再配置される。バイナリ差分ファイルの新しいブロックごとに、バイナリ差分コマンドに基づいて新しいブロックが構築され、仮想アドレス・アロケータによって割り当てられたアドレスにこの新しいブロックが再配置され、スパース・ストリームに書き出される。古いファイル・ストリームに不要になった古いブロックがある場合は、その割当てが解除される。
【００２０】
ｂｉｎｄｉｆｆの場合は、ストリーム・サイズとヘッダで指定されたストリーム・サイズを比較して中断したセクションを絞り込むことで、電源障害が処理される。中断したセクションがわかると、パッチが次のブロックに戻り、ブロックがコミットされたかどうかがチェックされる。ブロックがすでにコミットされている場合は、検証が行われ、該当する古いブロックがコミットを解除されているかどうかがチェックされる。中断したブロック（つまり、まだコミットされていないブロック）が検出されると、プロセスは通常どおり継続する。
【００２１】
予約されたメモリ・セクション（例えばパーティションの外部）をアップデートする場合は、カーネル・パーティションのアップデートと同様に、同じアップデート・コンポーネントを使用して、予約セクションのアップデートが実行される。各予約関連パッケージのアップデートは、パッケージ内の各ファイルが処理されて、ファイルがバイナリ差分モジュールかどうかが判断されることで、処理される。バイナリ差分モジュールでない場合は、単にファイル・データがファイルから読み込まれて予約された領域に書き出される。バイナリ差分モジュールの場合は、既存の領域が（例えばＲＡＭに）読み込まれ、バイナリ差分が適用されてから、アップデートされたデータが、予約された領域にもう一度書き出される。
【００２２】
その他の利点は、以下の発明を実施するための最良の形態と添付の図面を関連付けることで明らかになるであろう。
【発明を実施するための最良の形態】
【００２３】
図１に、上述したようなハンドヘルド・コンピューティング・デバイス１２０の機能上のコンポーネントを示し、それらは、プロセッサ１２２、メモリ１２４、ディスプレイ１２６、キーボード１２８（実際のキーボードまたは仮想キーボード、場合によってはその両方を表す）などを含む。マイクロフォン１２９は、音声入力を受信するために存在する。メモリ１２４は、一般に揮発性メモリ（ＲＡＭなど）と不揮発性メモリ（ＲＯＭ、ＰＣＭＣＩＡカードなど）を備えている。Ｍｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓ（登録商標）オペレーティング・システムやその他のオペレーティング・システムのようなオペレーティング・システム１３０はメモリ１２４に常駐し、プロセッサ１２２上で動作する。
【００２４】
１つまたは複数のアプリケーション・プログラム１３２はメモリ１２４にロードされ、オペレーティング・システム１３０の上で動作する。アプリケーションの例には、電子メール・プログラム、スケジュール管理プログラム、ＰＩＭ（personal information management：個人情報管理）プログラム、ワード・プロセッサ・プログラム、スプレッドシート・プログラム、インターネット・ブラウザ・プログラムなどがある。ハンドヘルド・パーソナル・コンピュータ１２０は、メモリ１２４内にロードされ、プロセッサ１２２上で動作する通知マネージャ１３４を備えていてもよい。通知マネージャ１３４は、例えばアプリケーション・プログラム１３２からの通知要求（notification requests）を処理する。また、以下に示すように、ハンドヘルド・パーソナル・コンピュータ１２０は、ハンドヘルド・パーソナル・コンピュータ１２０をネットワークに接続するための（例えば電話をかけるための）適切なネットワーキング・ソフトウェア１３６（例えばハードウエア・ドライバのような）とネットワーク・コンポーネント１３８（例えば無線やアンテナ）を備えている。
【００２５】
ハンドヘルド・パーソナル・コンピュータ１２０は、１つまたは複数のバッテリとして実装される電源１４０を備えている。電源１４０は、内蔵のバッテリに優先するか、あるいは内蔵のバッテリを再充電する外付けの電源（ＡＣアダプタや電源付き格納台（powered docking cradle）など）を備えていてもよい。
【００２６】
図１に示す例示的なハンドヘルド・パーソナル・コンピュータ１２０は、３種類の外部通知メカニズム、すなわち１つまたは複数の発光ダイオード（ＬＥＤ）１４２とオーディオ・ジェネレータ１４４を備えている。このようなデバイスは、ハンドヘルド・パーソナル・コンピュータのプロセッサ１２２やその他のコンポーネントがバッテリ電力を節約するためにシャットダウンしても、起動した際に、通知メカニズムで指定された期間は、その起動状態が引き続き起動状態であり続けるように、電源１４０に直接接続できる。ＬＥＤ１４２は、ユーザが対処するまで無期限にオンであるのが好ましい。ただしオーディオ・ジェネレータ１４４の最新版は、現在のハンドヘルド・コンピュータのバッテリで使用するには消費電力が大きすぎるので、システムの停止がなされた際に、あるいは起動後特定の時間が経過する、とオフになるように設定される。
【００２７】
ここでは基本的なハンドヘルド・パーソナル・コンピュータが表示されているが、移動電話など、実質的には、データ通信を受信する機能と、プログラムで使用できるように何らかの方法で処理する機能と、を備える任意のデバイスでも、本発明を実装することに対しては、等価である。
【００２８】
カスタム・ソフトウェア・イメージ・アップデートをフェイルセーフに適用する方法
本発明は、一般に、フラッシュ・メモリなど、内蔵のデバイスの不揮発性メモリに、イニシャル・ソフトウェアまたはソフトウェア・アップデートが書き込まれたポータルデバイスを含めて、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＣＥ  ＮＥＴベースのポータブル・デバイスなど、小型のモバイル・コンピューティング・デバイスに格納されるインストール・ソフトウェアおよび／またはアップデート・ソフトウェアを対象とする。それにもかかわらず、本発明は一般的にコンピューティング上の効果を提供するので、各種メモリおよび／またはハードディスク・ドライブなど様々な記憶媒体を含むその他のコンピューティング・デバイスやその他のストレージ・タイプにも適用できる。簡単のために、以下で使用する「フラッシュ」という用語は、デバイスのアップデート可能なストレージを表すものとする。ただし、任意のストレージ・メカニズムが同等であることは言うまでもない。また、「イメージ」という用語は、既存のイメージの一部のみがアップデートされた場合でも、一般に、イニシャル・ソフトウェア・インストール・イメージと、イメージに対するその後ソフトウェア・アップデートの概念を含む。
【００２９】
本発明の一態様に従って、自己充足型の、信頼できるエンティティの形のソフトウェア・アップデートは、内蔵デバイスの不揮発性ストレージに対して、フェイルセーフな方法で適用される。以前のアップデートに対する変更のみを含むアップデートを含めて、様々なソフトウェア・アップデートを適用できる。さらに、ソフトウェア・アップデートには実行可能コードとデータの両方を含めることができる。言うまでもないが、実行可能コードはインストール時に埋め込みのデバイスの仮想アドレス空間の環境に合わせてカスタマイズされる。本発明に沿って、フェイルセーフな方法でソフトウェア・アップデートがインストールされ、アップデートのステージに依存して、ロール・フォワードとロールバックの両方のリカバリ・オプションを利用できる。
【００３０】
以下の表に、一部の用語についての一般的な限定されない定義と、ここで説明するファイル形式を示す。
【００３１】
【表１】
2005196747.tif 000003
【００３２】
【表２】
2005196747.tif 000004
【００３３】
「Creating File Systems Within a File In a Storage Technology-Abstracted Manner」という名称の関連米国特許出願にも記述されるように、初期イメージはコンポーネント・パーツ（パッケージを含む、後述）から構成され、製造プロセスの間にカスタマイズされた方法でデバイスにインストールされる。そのイメージは図２に一般的に示すように独立したパーティションで構成され、モノリシックなイメージの置換を必要とすると言うよりも、後述するようにパーツごとにアップデートすることができる。
【００３４】
このパーティション分割スキーマは、既存の内蔵デバイスに加えて、今後組み込まれるデバイスに関して信頼できるソフトウェア・アップデートを可能にする。デバイスの集合の上で動作するように意図されたソフトウェアの開発およびリリースのプロセスの間に１つの静的イメージを生成する代わりに、本発明では、アップデート可能イメージのより適切なコンポーネント化を容易にし、しかもフェイルセーフの、より動的なイメージ・アップデート・メカニズムを提供する。このために、本発明では、オペレーティング・システム・イメージを、コンポーネント間の依存性を保持しながらコンポーネントごとに単独でアップデートできる、アップデート可能な独立したコンポーネントに分割する、より柔軟なメカニズムを提供する。この概念をサポートするために、イニシャル・オペレーティング・システム・イメージは、特定のキーアーキテクチャの特徴（key architectural features）を備えて構築される。
【００３５】
図２に、フラッシュおよび／または他の適切な不揮発性記憶媒体にインストールされるオペレーティング・システム・イメージ２０２のパーティション分割スキーマの例を示す。カーネル・パーティション２０４は、カーネル・イメージを格納するための制限付き／保護付きパーティション（restricted/protected partition）として示されている。カーネル／ＮＫパーティションには、オペレーティング・システム・イメージの中核部（カーネル、ファイル・システムなど）が格納され、ブート・プロセス中に実行されるコードが含まれている。制限付き／保護付きシステム・パーティション２０６には、オペレーティング・システム・イメージのシステム・コンポーネント・アプリケーションおよびその他の要素（ドライバ、アプリケーション、データ・ファイルなど）が格納される。こうしたパーティション２０４と２０６のコンテンツは、ストレージの物理的なマッピングを表すファイル・システム・ドライバで管理され、システム・パーティション２０６内で処理するコンポーネント・アップデートをサポートするので、以下に示すように本発明に従ったフェイルセーフなリカバリ・ソリューションが可能となる。保護付きカーネル・パーティションのコンテンツへのアクセスはバイナリ・ファイル・システム（ＢＩＮＦＳ: binary file system）を介して制御され、保護付きシステム・パーティションのコンテンツへのアクセスはイメージ・ファイル・システム（ＩＭＧＦＳ：image file system）を介して制御される。
【００３６】
図２には、（実際にはオペレーティング・システム・イメージ２０２の一部ではないが）ＵｓｅｒＳｔｏｒｅパーティション２１０も示されている。このパーティションは、必要に応じてシステム／ユーザが利用でき、基本的に任意のファイル・システム・フォーマットでよい（例えばＴＦＡＴ）。以下に説明するように、このパーティションは、他の様々な用途の中でも特に、アップデート手続の間にインストールするパッケージの一部を一時的に格納するために使用してもよい。例えばオフセット／サイズなど、パーティションを定義するマスター・ブート・レコードが書き込まれることに留意されたい。
【００３７】
また、図２はローダー環境についての機能的なビューを提供している。一般に、ローダーは、標準のオペレーティング・システム・ブートとアップデート・ブートのどちらが行われるかについて（イニシャル・プログラム・ローダー２２２によって、ブート・ローダー２２４がすでに存在している場合はこれと連動して）決定がなされるポイントに埋め込みシステムをブートすることを担当する。ただし、「すでに存在している」ブート・ローダーは新しいデバイスには必要ないが、デバイスのメーカーがオプションで、それを存在すべきであると決定することもできる。
【００３８】
アップデート・ブートの場合は、そのローダーの一部は、アップデート・ローダー（ＵＬ２２０）を備え、これがフラッシュ・アップデートのゲート・キーパー（gatekeeper）の役割を果たす。アップデート・ローダー２２０は、まだ適用されていないアップデートの有効性確認を担当し、有効性が確認されると必要に応じてフラッシュに適用する。セキュリティと制御に関しては、アップデート・ローダー２２０は、保護付きストレージ（例えば、ＮＫパーティションやシステム・パーティション）への書き込みのアクセス権を持つシステム内で唯一のエンティティである。したがって、システムのストレージの完全性も保護を担当する唯一のポイントを提供する。アップデート・ローダーは比較的大きく、アップデートを適用する場合にしか使用しないので、ある実装形態では、圧縮した形式で格納し、必要に応じてＲＡＭに解凍する。
【００３９】
図３は、アップデートのインストール・メカニズム／プロセスを表している。ただし、図３では、イニシャル・プログラム・ローダー、マスター・ブート・レコード（ＭＢＲ：master boot record）、アップデート・ローダー（ＵＬ：update loader）コンポーネントが、以前に、（例えば製造時にＪＴＡＧインターフェース、またはギャング・プログラマー（gang programmer）によって）デバイスに最初にインストールされた後のアップデートの観点から開始していることに留意されたい。また、標準パッケージ（canonical packages、後述）は永続的なストレージ／ＲＡＭからカーネル・パーティションとシステム・パーティションに適用される。
【００４０】
図３で、アップデート・パッケージ３０２（後述のように標準パッケージ（canonical packages）、差分アップデート、スーパー・パッケージのいずれでもよい）は、システムのＲＡＭ３０４および／またはユーザ・データ・ストア２１０にダウンロードされる。これは、デバイスのユーザにアップデートを利用できることの通知を伴って、おそらく手動または自動でなされる。これは、図３に矢印（１）として一般的に示してある。
【００４１】
こうして、いったん初期製造イメージ（initial manufacturing image）がデバイスにインストールされると、そのイメージへのその後のアップデートは、パッケージにカプセル化されている、イメージの個々の部分をアップデートすることで、なされる。一般に、パッケージは自己記述型のイメージ・ファイル（コード、データ、スクリプトなど）の集まりであり、ある実装形態は、署名付きのパッケージ化された配布用の、コンポーネントの集まりである。パッケージは、オペレーティング・システム・イメージ・ソフトウェア・ファイルを機能上の小さなファイル・グループに分割する手段を提供する。ある実装形態では、オペレーティング・システム・イメージ全体が１つまたは複数のパッケージで構成されているので（ローダー・コンポーネント以外）、個々に管理され、構築され、アップデートされる小さなパッケージの集まりとして単純に処理できる。個々のパッケージは、パッケージごとの要件に従って、個別にアップデートしてもよいし、他のパッケージと組み合わせてアップデートしてもよい。こうして、本発明に沿って、オペレーティング・システム・イメージ領域全体のイメージ・アップデートは行う必要がなくなる。
【００４２】
パッケージは、「標準（canonical）」、「差分（delta/difference）」、「スーパー（super）」の形式を含めて、様々な方法で構成でき、それぞれは、ソフトウェア・アップデートに関しての様々な目的を果たすことができる。例えば、標準パッケージにはパッケージ内の各ファイルの完全なコピーが含まれ、差分パッケージには旧版のファイルに基づくバイナリの差分のみを含む１つまたは複数のファイルが含まれる。差分パッケージは、通常は他のパッケージに比べてサイズが小さいので、ダウンロード・コストとダウンロード時間を最適化する場合に使用する。スーパー・パッケージには他のパッケージが含まれており、複数のパッケージ（相互依存（interdependent）パッケージなど）をダウンロードする必要がある場合に使用する。ある実装形態では、パッケージ・ファイルは、例えば、マニフェスト・ファイル（後述）とインストールされるべきパッケージを定義するファイルを含むＷｉｎ３２  ＣＡＢファイルである。
【００４３】
標準のパッケージは、オペレーティング・システムの機能とメタデータ（例えば、特定のアプリケーションの実行可能コードや関連データと構成情報のすべて）をパッケージの定義に関連付けることによって、ビルド・プロセスに期間に生成される。２つの標準パッケージのコンテンツにバイナリ差分アルゴリズムを適用し、差分パッケージのベース・ライン標準パッケージ・バージョンへの依存関係を取得することで、標準パッケージから差分パッケージが生成される。オペレーティング・システム・イメージの機構（operating system features）とメタデータが個々のパッケージにマップされると、パッケージング・ツールを使用してパッケージのコンテンツを列挙し、実行可能ファイルを（ＲｅｌＭｅｒｇｅという再配置ツールを使用して）処理することで、実行可能ファイルを、メモリ関連の修正（memory-related fix-ups）について将来にアップデートできるように処理することによって、前述の「Self-Describing Software Image Update Components」という名称の米国特許出願で一般的に記述するように、各パッケージが生成される。
【００４４】
ユーザがアップデート・プロセスを開始すると、パッケージ・バリデータは、パッケージを「Determining the Maximal Set of Dependent Software Updates Valid for Installation」と「Ensuring that a Software Update may only be Installed or Run on a Specific Device or Class of Devices」という名称の関連特許出願に記述するように、検証する。有効性が確認されると、システムは、フラッシュにアップデート・フラグを設定して再ブートする。ただし、後述のように、アップデート・フラグがそのまま残る（生き残る）ので、電源断のイベント中でアップデート・ローダー・コードが開始されると、デバイスは再びアップデート・モードに入る、ことに留意されたい。
【００４５】
再ブート後に、イニシャル・プログラム・ローダー２２２はアップデート・フラグが設定されていることを確認し、図３で解凍されたアップデート・ローダー・コード３０８として示すように、圧縮されているアップデート・ローダーをＲＡＭ３０４に解凍し、アップデート・ローダー・コード３０８に制御を渡す。これは、図３に矢印（２）として一般的に示してある。ただし、アップデート・ローダーがアップデート・アプリケーションを起動すると、アップデート・アプリケーションは、ファイルのリストまたは一連のディレクトリ仕様を使用して有効性確認プロセスを再実行する。これは、デバイスが再ブートする前にｕｐｄａｔｅｂｉｎ．ｅｘｅでセットされている。この有効性確認プロセスの再実行は、パッケージの不正な置き換えを防止するために、実行される。
【００４６】
カーネル・パッケージがある場合はまずカーネル・パッケージが処理され、パッケージごとにアップデート・ローダーがパッケージを処理し、必要に応じてフラッシュ・メモリに配慮しながらＲＡＭのセクション３１０に書き込むファイルを準備（fix up）し、ＢＩＮＦＳサービスを利用して対応するパーティションにファイルを書き込む。これは、図３に矢印（３）から（６）として一般的に示してある。ｆｉｘｕｐについては、以下において説明され、また「Self-Describing Software Image Update Components」という名称の関連特許出願に一般的に説明されている。
【００４７】
図４に一般的に示すように、各パッケージにはパッケージに関する詳細情報を記載するデバイス・マニフェスト・ファイル（device manifest file）４００が含まれている。マニフェスト・ファイルは基本的に各パッケージの仕様を表すファイルであり、パッケージを識別するための大域的に一意のＩＤ、パッケージのバージョン、他のパッケージに関連する依存情報、設定、パッケージに含まれるファイルとファイル・バージョンのリスト、および共有する他の一般的な特性が記載される。マニフェスト・ファイル４００は、各パッケージに含まれており、したがって、そのパッケージを自己記述的（self-describing）にしており、インストール・プロセスの期間に確認されて、最終的にデバイスに格納される。デバイスに格納された一連のマニフェスト・ファイルの集合は、デバイス上のパッケージのインストール状態に関する列挙可能なデータベースを構成する。
【００４８】
図４に示すデバイス・マニフェスト・ファイルに記載されるフォーマットと情報に対応するある実装形態では、デバイス・マニフェスト・ファイルは以下の構造体の定義を使用しても説明できる。
【００４９】
【表３−１】
2005196747.tif 000005
【００５０】
【表３−２】
2005196747.tif 000006
【００５１】
作成される各パッケージは、セキュリティ保護のために署名されると、ダウンロード／インストールが可能になる。パッケージ生成プロセス／パッケージ・ジェネレータは、「Self-Describing Software Image Update Components」という名称の米国特許出願に記述するように、パッケージ記述ファイルで定義するフル・バージョンのファイルを含むパッケージ・ファイルの作成を自動化する。一般に、パッケージ・ジェネレータは、パッケージ定義ファイルを入力し（例えば、コマンド・ライン引数で指定）、他の入力ファイルは、指定されたパッケージ定義ファイルのコンテンツに基づいて決定される。パッケージ・ジェネレータは、パッケージ定義ファイル（例えば、１つまたは複数のパッケージ定義で構成され、各パッケージはＸＭＬドキュメント・エントリとしてエンコードされている）を解析し、さらにレジストリ設定などの設定用の他のパッケージ・ファイルに対する優先順位に関するデータを含むパッケージ・シャドウ・ファイルを解析することもある。さらに、パッケージ・ジェネレータはビルド・マニフェスト・ファイルを解析し、このファイルで指定された各ファイルを検出し、ファイルのタイプを確認する。実行可能ファイル形式の場合、パッケージ・ジェネレータは再配置関連の操作とフォーマット（例えば、実行可能ファイル形式からＷｉｎｄｏｗｓ（登録商標）ＣＥファイル形式への変換）を実行するプロセス（ＲｅｌＭｅｒｇｅ）を呼び出す。
【００５２】
ある実装形態では、パッケージ・ジェネレータは、例えばＰｋｇＣｏｍｍｏｎという．ＮＥＴクラス・ライブラリを使用するアプリケーション・プログラムを備えている。パッケージ・ジェネレータ・アプリケーションは複数のサブディレクトリを作成する。作成するサブディレクトリの数は、コマンド・ラインで指定されたパッケージ・コレクション・ファイルで検出される有効なパッケージの数に等しい。各パッケージは、パッケージ生成プロセス中に作成される一意のサブディレクトリを有する。さらに、パッケージ・ジェネレータはパッケージ定義内の情報を使用してサブディレクトリごとに追加のファイルを作成する。パッケージごとにデバイス・マニフェスト・ファイルが作成され、パッケージのＧＵＩＤから抽出されたデバイス・マニフェスト・ファイルの名前が付けられる。有効なパッケージ定義ごとに、デバイス・マニフェスト・ファイルを含めてパッケージを構成するファイルを含むパッケージ・ファイルが作成される。こうしたパッケージ・ファイルは、Ｍｉｃｒｏｓｏｆｔ  ＣＡＢファイル・バージョン１．３形式に適合する。
【００５３】
インストール・プロセスでは、デバイスにすでにインストールされているパッケージとキューに入ってこれからデバイスにインストールされるパッケージの両方について、デバイス・マニフェスト・ファイルのコンテンツを頻繁に使用する。パッケージ情報ＡＰＩは、パッケージ情報を照会する抽象的な手段を提供するように設計されており、デバイス上とビルド・ホスト上の両方で使用される。このＡＰＩの詳細については、上述した「Determining the Maximal Set of Dependent Software Updates Valid for Installation」という名称の関連特許出願を参照されたい。
【００５４】
カーネル・パーティションまたはシステム・パーティションのアップデートは、パッケージ・メカニズムを使用して管理され、デバイスに配信される。パッケージは、デバイスに転送され、一時記憶域に格納され、既存のオペレーティング・システム・イメージのコンポーネントなどの適切な手段を介してインストールのキューに入る。パッケージをデバイスに配信するのに適した任意の転送手段（物理プロトコルおよび／またはインターフェースプロトコル）を使用でき、アップデートするデバイス（例えば、ＳｍａｒｔＰｈｏｎｅｓ用には無線、スマート・ディスプレイ用にはＵＳＢ、何らかのデスクトップ・アップデート・アプリケーション用には何らかの物理接続、など）によって変わる。エンド・ユーザ・インターフェースの使い心地は、アップデートするデバイスの種類と、デバイスのメーカーでカスタマイズされたアップデート・プロセスによって変わる。本発明のフェイルセーフな側面に沿って、個々の一時パッケージは永続的なストレージに格納されるので、その結果、電源断のイベント中でシステムが復旧し、その後インストールを続行することができる。
【００５５】
パッケージ・バリデータ・ライブラリ（package validator library）が呼び出されると、アップデート・プロセスがトリガされる。ある実装形態では、ＵｐｄａｔｅＢｉｎ．ｅｘｅという実行可能ファイルは、．ｐｋｇ．ｃａｂ、．ｐｋｕ．ｃａｂ、および．ｐｋｓ．ｃａｂというファイル拡張子に関連付けられる。この実行可能ファイルは、パッケージ・バリデータ・ライブラリを利用して、デバイスのアップデートに使用する一連のパッケージを決定する。
【００５６】
パッケージ・バリデータ（package validator）は、パッケージの署名（１つまたは複数）の確認、パッケージのコンテンツの有効性確認、バージョンの検証などの作業を行う。アップデート・パッケージが適切だと認識される場合は、パッケージがインストール・キューに入る。パッケージ・バリデータは、アップデート・フラグを設定して、アップデートが利用できることをデバイスに通知し、さらにシステムを再ブートする。
【００５７】
再ブートする際に、イニシャル・プログラム・ローダー２２２はＣＰＵのリセット・ベクトルから実行するコードの最初の部分である（一部のデバイスでは、イニシャル・プログラム・ローダーが既存のブート・ローダー・イメージによってブートされる）。イニシャル・プログラム・ローダー２２２は、デバイスがアップデート・モードにあるかどうか、あるいはデバイスが標準ブート・モードにあるかどうかの判断を担当する。デバイスが標準ブート・モードの場合は、イニシャル・プログラム・ローダーがオペレーティング・システム・イメージを探し出し、これにブートする。それ以外の場合はイニシャル・プログラム・ローダーが、アップデート・ローダー・イメージを探し出し、解凍し、解凍されたアップデート・ローダー・イメージ３０８にブートする。図５Ａと５Ｂは、イニシャル・プログラム・ローダーのブート・プロセスを説明している。図５Ａに示すように、ステップ５０２で特定の初期化（例えば、ＣＰＵを初期化すること、ＮＡＮＤ（型フラッシュ・メモリ）であれば、そのコントローラを初期化すること、ＳＤＲＡＭの初期化をすること、など）に続いて、イニシャル・プログラム・ローダーはステップ５０４と５０６でリセットの理由を判断する。より具体的には、一時停止の状態（suspended state）からレジューム（resume：再開する）場合は、特定のＣＰＵアーキテクチャは再ブート・シーケンスを模倣する。次に、起動コードは通常はＣＰＵレジスタの値に基づいてレジュームと「標準」ブートを区別する。イニシャル・プログラム・ローダーは、レジューム・オペレーションに対応できる。ステップ５０４〜５０８にこの詳細を示す。
【００５８】
レジュームでない場合は、ステップ５０６でステップ５１０〜５２８に分岐する。図に示すように、アップデート・モードが検出され、アップデートの場合はアップデート・ローダー・パーティションがスキャンされ（ステップ５２０）、それ以外の場合はステップ５１８でオペレーティング・システム・パーティションがスキャンされる。ステップ５２２に示すように、イニシャル・プログラム・ローダーがデバイス上にオペレーティング・システム・イメージを探し出せない場合は、イニシャル・プログラム・ローダーは、アップデート・ローダーをロードして実行する。適切なパーティションが見つからない場合は、エラーが出力される（ステップ５３２）。ただし、この時点でデバイスは標準のディスプレイ・ドライバや同種のものでは動作していないので、この時点で表示されたイメージはデータ・ストアからのビットマップであることに留意されたい。
【００５９】
さらに、オペレーティング・システムにブートする場合は、フラッシュはステップ５２４を介してロックされ、このステップではアップデート・ローダーへのブートを実行しない。この後、プロセスは図５Ｂのステップ５３８に続き、圧縮イメージと非圧縮イメージを操作する。ただし、図５Ｂはアップデート・ローダーまたはオペレーティング・システムのいずれかを示している。アップデート・ローダーは（通常のデバイス上では）圧縮形式で格納されているが、一方、オペレーティング・システムは、デバイスがＸＩＰ（execute-in-place：直接実行）に対応するかどうかによって、圧縮されている場合とされていない場合がある（対応する場合は、圧縮されてはいない）。
【００６０】
圧縮されている場合は、イメージに関する様々な情報をパーティション／イメージから取り出して、そのイメージをＲＡＭに解凍し、ステップ５４０〜５４６で実行を開始する。ただし、圧縮の種類と圧縮されたデータのフォーマットをイニシャル・プログラム・ローダーで認識している限り、任意の適切な圧縮アルゴリズムを使用できる。ステップ５３８で圧縮されていない場合は、ステップ５４４でイメージに関する情報をパーティション・セクターから読み込み、目次（ＴＯＣ：table of contents）、オフセット、署名をそのセクターから探し出す。このために、イニシャル・プログラム・ローダーはマスター・ブート・レコードが存在するロケーション（イニシャル・プログラム・ローダー・イメージの次に続く有効なフラッシュ・ブロックの先頭）に関する情報を事前に把握しており、アクティブなパーティションをマスター・ブート・レコードに格納されているパーティション・テーブルに、位置決めする。こうして、イニシャル・プログラム・ローダーは、オペレーティング・システム・イメージのＸＩＰ領域内と、アップデート・ローダー・イメージ内の両方に適切に探し出された目次（ＴＯＣ：table of contents）を有するＲＯＭイメージ／ディスク・イメージに依存する。ある実装形態では、ロケーションとして以下が提供される。
【００６１】
At byte offset (Image Start + 0x40):  
UINT32 ROMSignature;  
UINT32 *pTOC;
この情報は、オペレーティング・システム・イメージによって使用され、（ＲＯＭイメージ／ディスク・イメージとして配置された）ＴＯＣを位置決めする。ポインタは、メモリ管理ユニット（ＭＭＵ: memory management unit）がオンになっており、オペレーティング・システム・イメージが構築されたアドレスとマッピングが互換可能な場合にのみ、意味がある。あるいは、次のような実装もある。  
At byte offset (Image Start + 0x40):  
UINT32 ROMSignature;  
UINT32 *pTOC;  
UINT32 TOCOffset;  
ただし、ＴＯＣＯｆｆｓｅｔは、イメージ開始位置からＴＯＣまでのバイト・オフセットであり、イニシャル・プログラム・ローダー（またはアップデート・ローダー・アプリケーション）で使用され、そのイメージが稼働するように構築されたロケーションを知ることなく、ＴＯＣを探し出すことができる。
【００６２】
また、ステップ５４８に示すようにイニシャル・プログラム・ローダーは、署名を確認することもできる。ステップ５４８で無効な場合は、ステップ５５０でブート・プロセスが一時停止し、それ以外の場合は、ステップ５５２と５５４で目次（ＴＯＣ）が読み込まれ、イメージの開始位置、イメージ長、目次からのジャンプ・アドレスが検出される。必要に応じて、ステップ５５８で、必要ならばメーカー提供のデータ・テーブルに基づいて、アドレスを設定（fix up）する。より具体的には、イニシャル・プログラム・ローダーは多くの場合にデバイスの物理アドレス空間で動作する（、あるいは、オペレーティング・システム・イメージともアップデート・ローダー・イメージとも異なってもよい仮想アドレス空間で動作する場合もある）。このルーチンは、任意のイメージに固有の仮想アドレス（例えば、オペレーティング・システム・イメージのＴＯＣの値）を、イニシャル・プログラム・ローダーと互換可能なアドレスに変換することを担当する。メーカーの起動ルーチンがメモリ管理ユニットを有効にしない場合は、このことは、仮想アドレスから物理アドレスへの変換を意味する。メモリ管理ユニットが有効になり、マッピングがオペレーティング・システムまたはアップデート・ローダーの構成方法と互換可能な場合は、変換が不要である。
【００６３】
ステップ５５８で、イメージをＲＡＭにロードする必要があるか（ロードが必要な場合はステップ５６２でロードする）、あるいは直接実行できる（ＸＩＰ）か、を判断する。次に、ステップ５６４に示すように、そのイメージ（ロードされたもの、またはそのロケーションにあるもの）にジャンプして実行を開始する。アクティブ・パーティションのロケーションによって、イニシャル・プログラム・ローダーは（設計されたとおり）ＮＡＮＤ（場合によってはＮＯＲ）の場合はアクティブ・パーティション（カーネル・パーティション）のコンテンツをＲＡＭにロードし、ＮＯＲ（ＸＩＰ）カーネル・パーティションの場合は、パーティション内の開始アドレスにジャンプする。標準ブートの場合は、カーネルが、カーネル・パーティションにも配置されたオペレーティング・システム・コンポーネントの、オペレーティング・システムがシステム・パーティションから読み込みできるポイントへの、ロードを開始し、継続する。その時点で、カーネル・パーティション内のこうしたポイントに配置されていないものは、オペレーティング・システム・イメージが完全にブートされるまで、システム・パーティションからフェッチされる（ロードされるか、またはＸＩＰされる）。
【００６４】
ある実装形態では、イニシャル・プログラム・ローダーは相対的に非常に小さなソフトウェア・コンポーネントであり、ＣＰＵのリセット・ベクトルからブートし、条件によってオペレーティング・システム・イメージまたはアップデート・ローダー・イメージをロードし／起動する、ことを担当する。前述のように、イニシャル・プログラム・ローダーは、ＲＡＭフラグ、フラッシュ／不揮発性フラグ、ハードウエア・スイッチなど、様々なレジスタを読み込んで、標準のオペレーティング・システム・イメージにブートするかアップデート・ローダー・イメージにブートするかを決定できることが必要である。より具体的には、イニシャル・プログラム・ローダーは、（例えば、有効性確認に続いて）ＵｐｄａｔｅＢＩＮアプリケーション、またはアップデート・ローダー・アプリケーションで設定したフラグを調べる必要がある。その理由は、通常、オペレーティング・システム・イメージが読み取り専用フラッシュ・ファイル・システムを使用して動作するためである。電源障害の状態に対応するために、アップデート・モード・フラグは、不揮発性である。したがって、再ブートの前に不揮発性のフラグを格納できない場合は、アップデート・ローダー・アプリケーションが最初に実行されたときに不揮発性のフラグを設定し、インストールが正常に完了するとこのフラグをクリアする。このことによって、そのフラグは電源障害が発生しても、生き残る。
【００６５】
さらに、イニシャル・プログラム・ローダーは、イメージを突きとめるために、様々なストレージ技術によるストレージ・パーティションの構造体を解析する必要があり、圧縮イメージ形式だけでなくフラッシュＸＩＰ（フラッシュ内で直接実行）やＲＡＭイメージ（ＲＡＭにコピーして実行）も操作できる。イニシャル・プログラム・ローダーは、任意のストレージ技術の仕様（ＮＯＲフラッシュ、ＮＡＮＤフラッシュ、ＨＤＤ、ＤＯＣなどのＯＥＭで提供するコード）に加えて、一般に、パーティション構造、予約ブロック、不良ブロックなどのストレージ属性だけでなく、を抽出する。イニシャル・プログラム・ローダーは、オペレーティング・システム・イメージおよび／またはアップデート・ローダー・イメージにブートする前に、該当するイメージの整合性を検証することが、例えば、不正なアップデートを検出することができる（例えば、チェックサムまたは署名の検証による）。このことによって、デジタル権利管理のための信頼できるコードを、すなわち、カーネル・イメージから返されるＵＵＩＤが不正に改ざんされていないコードで提供されていることを確認するために必要なコードを検証する手段を提供する。
【００６６】
こうして、図３に示し、図５からわかるように、アップデート・モードでは、イニシャル・プログラム・ローダー２２２は圧縮されたアップデート・ローダー２２０を解凍されたアップデート・ローダー３０８としてＲＡＭ３０４に解凍し、フラッシュのロックを解除した状態で解凍されたアップデート・ローダー３０８にシステム・フラッシュへの書き込みのアクセス権を付与し、解凍されたアップデート・ローダーのコードにジャンプして実行を開始する。イニシャル・プログラム・ローダーによる最初のブート時に、アップデート・ローダー・アプリケーションはフラグを不揮発性のストレージに格納し、デバイスがアップデート・モードにあることを示す必要があることになる。これは、オペレーティング・システム・イメージが、多分、読み取り専用フラッシュ・ファイル・システムを備えており、電源が失われた場合の復旧に重要なこのフラグを設定できないためである。アップデート・ローダー・イメージをロードするかオペレーティング・システム・イメージをロードするかする際に、イニシャル・プログラム・ローダーは、ＲＡＭのフラグだけでなく、この不揮発性のフラグがあるかどうかを確認することになる。ここで、ＲＡＭフラグは、（直接または間接的に）ＵｐｄａｔｅＢＩＮアプリケーションによって設定される。
【００６７】
アップデート・プロセスの説明に戻ると、前述のようにカーネル・パーティションまたはシステム・パーティションのコンテンツをアップデートするプロセスは、アップデート・ローダーが完全にブートされ、ＲＡＭにロードされてから実行され、ユーザ・ストア内の（バリデータで指定された）適切なパッケージを検出するように動作する。
【００６８】
ただし、アップデート・ローダーには必要なファイル・システム・ドライバが含まれており、１度に１パッケージずつアップデート・プロセスを開始する、ことに留意されたい。アップデート・パッケージのパッケージ情報は、ファイル・システム内に記録されその後のアップデートにおいて、バリデータによって使用される。本発明の一態様に従って、フェイル・セーフなアップデートを可能にするために、イニシャル・プログラム・ローダーは、ロード・プロセス中の任意のポイントでのランダムな電源障害から復旧できる。このために、アップデート中に電源障害が発生してもロール・フォワード・アップデートが可能になるように、トランザクション・ログでアップデートの進行が追跡される。
【００６９】
アップデート・モードでは、アップデート・ローダーが動作してアップデート・アプリケーションを起動する。このアプリケーションは、アップデート・ローダー・イメージ３０８（図３）の一部となる実行可能ファイルであり、パッケージのコンテンツをＮＫ／カーネル・パーティション２０４とシステム・パーティション２０６に適用する作業を担当する。換言すれば、アップデート・プロセスの間にイニシャル・プログラム・ローダーによってロードされたアップデート・アプリケーションは、パッケージ・アップデートのイメージへの適用を受け持つ。ただし、アップデート・ローダー・イメージには、ｎｋ、ｆｉｌｅｓｙｓ、フラッシュ・ドライバ、ｃｏｒｅｄｌｌ、ＩＭＧＦＳなど、アップデート・アプリケーションに必要な最小限のモジュールの組が含まれる。
【００７０】
図６〜８に、それぞれ、アップデート・プロセス全体、ＮＫ／カーネル・パーティション・アップデートのアプリケーション、システム・パーティション・アップデートを示す。アップデート・アプリケーションは、パッケージとの有効性を確認するパッケージ・バリデータ、仮想および物理的な割当て、ｆｉｘｕｐｓ、配置の関数を処理するＲＯＭＩＭＡＧＥモジュールと連携する。図６からわかるように、ステップ６００でアップデート・アプリケーションはパッケージ・インストール・リストを取得し（例えば、レジストリから）、バリデータを使用してパッケージの有効性を確認する（ステップ６０２）。アップデート・モードでは、アップデート・アプリケーションは、ＮＫ／カーネル・パーティションとシステム・パーティションにパッケージのコンテンツを適用する作業を担当する。
【００７１】
アップデート・アプリケーションが不揮発性のストレージにパッケージのコンテンツを適用する前に、パッケージの有効性が確認される。この処理には、（特に）署名を調べて、このアップデートが信頼できる供給元からのものであることを確認するステップが含まれる。言うまでもないが、パッケージ・アップデートの供給元が信頼できることを認識し、フラッシュへの書き込みアクセス権を持つ唯一の信頼できるゲート・キーパー（gatekeeper）が存在することを確認することは、デバイスのフラッシュの整合性を維持しようとする場合に重要である。アップデート・パッケージは作成のプロセス中に署名され、アップデート・パッケージができるだけ多くの異なるパッケージごとの信頼できる供給元の１つによって署名されている限り、このアップデート・パッケージは、前述のパッケージの有効性確認プロセスで継続を許可される。署名がない場合、あるいは信頼できる供給元の署名ではない場合は、パッケージの有効性を確認できないのでアップデートは実行されない。句読点
ただし、システムの設計によって、フラッシュのコンテンツをアップデートできる唯一のソフトウェア・コンポーネントは、インストール・キューに入った任意のパッケージの有効性の確認（署名の確認を含む）を担当するのと同じコンポーネント（アップデート・ローダー）である、ことに留意された。また、アップデート・ローダーには、汎用のオペレーティング・システムのように、信頼できないコードも第三者のコードも一切含めることができない、ことにも留意されたい。したがって、このシステムは、信頼できるコードのみを実行するので、改ざんによる影響を受けにくい。アップデート・ローダーを実行しない場合は、フラッシュ・パーツを最初にリセットせずに（通常はＣＰＵに関連するので両方をリセットする）、フラッシュ・パーツへの書き込みを禁止する（ハードウエアレベルの）ハードウエア・ロック・メカニズムを利用するように設計されている。さらに、オペレーティング・システム・イメージには、読み取り専用のファイル・システムが含まれるので、システムによってパッケージの有効性確認とセキュリティ・チェックの実行が保証され、実行されるアップデート・ローダー・コンテキスト内にそのシステムがない場合は、フラッシュのコンテンツがアップデートされないことがさらに保証される。
【００７２】
検証には、パッケージのコンテンツが正しいかどうかを確認することと、デバイス・マニフェスト・ファイル内の情報をパッケージのコンテンツに対応付けることと、ファイルが１つで、しかも唯一のパッケージ内に存在することを（名前で）確認するステップ、が含まれる。さらに、有効性確認によって、必要なパッケージのバージョンがすでにシステム上にインストールされているか、あるいはインストールのキューに入っているかを確認する。例えば、バージョン１．０のパッケージＡがすでにシステムにインストールされ、差分パッケージＡがバージョン２．０をバージョン３．０にするとした場合に、この差分パッケージをインストールするには、パッケージＡをバージョン２．０にアップデートするパッケージをインストールのキューに入れる必要がある。さらに、他の検証には、必要なパッケージの依存関係を満足するかどうかを確認するステップも含まれる。例えば、パッケージＡのバージョン２．０がパッケージＢのバージョン３．０のコンテンツに依存する場合は、後者のパッケージがすでにインストールされているか、あるいはインストールのキューに入り、有効性が確認されているかをチェックする。パッケージの有効性確認プロセスについては、「Determining the Maximal Set of Dependent Software Updates Valid for Installation」という名称の米国特許出願も参照されたい。
【００７３】
デバイス上での有効性確認プロセスの結果、有効性確認の要件を満足しているのでデバイス上にインストールできるパッケージ（とそれに含まれるファイル）のリストが作成される。有効性確認プロセスでは、特定のパッケージごとに、有効性確認プロセスが正常に実行されなかった理由についてのデータに加えて、インストールできないパッケージのリストも生成される。これら以外のインストール・プロセスでは、これ以降、有効性確認をクリアしたパッケージのみを使用する。
【００７４】
図６に戻り、アップデート・ローダーはカーネル・パーティションにアップデートを適用し（ステップ６０４と６０６）、システム・パーティションにシステム・アップデートを適用する（ステップ６０８と６１０）作業を行う。（パーティションの範囲外にある、つまり予約された領域の「周囲」に定義されたパーティション構造を使用してフラッシュ内の指定されたロケーションに一意に配置される）メモリ内の予約された無線セクションなど、他のアップデートがある場合、こうしたアップデートはステップ６１２と６１４で同様に処理される。このことについては、図１０を参照しながらもう一度説明する。
【００７５】
ステップ６１６で、これらのパッケージは削除することができる。ステップ６１８で、フラグに値が設定され（ｃｌｅａｒｅｄなど）、オペレーティング・システム・イメージをブートする。カーネル・アップデートまたはシステム・アップデートが作成されている場合は、ここでオペレーティング・システム・イメージのアップデートが実行され、システムが再ブートする（ステップ６２０）。図７Ａと７Ｂにカーネル・アップデートの一般的なロジックを示す。ここでは、（ＸＩＰを想定した場合）既存のカーネルをＲＡＭに読み込んでユーザ・ストレージに圧縮することで、既存のカーネルがバックアップされる。これをステップ７００に示す。ここでは、デフォルトのファイルを１つ含むＸＩＰフォルダとしてファイル・システムを通して顕在化される、ＸＩＰパーティションはイメージ全体をローカル・バッファに読み込むためのハンドルを取得する。新しいファイルがユーザ・ストレージに作成され、圧縮ルーチンが呼び出されてそのイメージを圧縮し、そのご圧縮ファイル・データが新しいファイルに書き込まれる。
【００７６】
ステップ７０２でヘッダとその他のメタデータが読み込まれる。この目的のために、プロセスはｐＴｏｃ（目次構造）を探索して各セクションのロケーションを確認し、古いモジュール・リストにモジュール情報を埋め込み、バックアップとして作成したＲＡＭ内のコピーの適切なロケーションを示すようにセクション・データ・ポインタを設定する。既存のＴＯＣの要素が保持され、ＮＫ／ＸＩＰパーティション・アップデートの終わり近くの新しいＴＯＣにコピーされる。ただし、プロセスは、モジュールのヘッダを読み込む間に、古いデバイス・マニフェスト・ファイルからその他のフラグ（圧縮、カーネル・モジュール、スロット１オーバーライド［Ｌフラグ］など）も読み込む、ことに留意されたい。
【００７７】
ステップ７０４と７２２で、パッケージ内の各モジュールが処理され（ステップ７０６と７２０）、ファイルがｂｉｎｄｉｆｆ（バイナリ差分）モジュールかどうかが決定されることで、各パッケージが処理される。これには、各パッケージ内のモジュールごとのループ処理が含まれ、新しいファイル全体のコピーが提供された場合は標準アップデート（canonical update）が適用され、ファイルのバイナリ差分のみが提供された場合はｂｉｎｄｉｆｆアップデートが適用される。ｂｉｎｄｉｆｆを適用するプロセスはｐａｔｃｈｂｉｎと呼ばれ、セクションごとに別々のｂｉｎｄｉｆｆが１度に１つずつ実行される。新しいモジュールのヘッダがそのまま標準形式（raw canonical form）で提供される。ファイルは、１つずつアップデートされるにつれて、（ファイル・オブジェクトの形で）新しいファイル・リストに追加される。このステップの終わりには、アップデートされた未修正バージョン（unfixed up versions）のモジュールとファイルが記載された新しいファイル・リストが存在することになる。これらが既存のファイルであった場合は古いリストから削除されるので、このステップの終わりには古いリストにアップデートがなかったファイルのみが記載される。このプロセスは、パーティション内にパッケージ・マニフェスト・ファイル（１つ以上）が存在するかどうかに基づいて、そのパーティションにどのパッケージ（１つ以上）が関連付けられているかを確認する、ことに留意されたい。まだデバイスにインストールされていない新しいパッケージは（ある場合）、ＩＭＧＦＳパーティションに保存される。
【００７８】
こうして、ステップ７０８でｂｉｎｄｉｆｆモジュールでない場合は、ステップ７１８で単にモジュールが新しいリストに追加される。ｂｉｎｄｉｆｆモジュールの場合は、古いコードに差分を適用する必要があり、この適用は、ステップ７１０−７１６でセクションごとに実行される。
【００７９】
より具体的に言えば、前述のとおり、デルタ／差分パッケージには１つ以上のバイナリ差分ファイルが含まれており、各バイナリ差分ファイルは特定のファイル／モジュールに対応する。差分ファイルは、インストール時に適用された特定のベース・ラインのリビジョンに基づいており、差分ファイルは通常は結果として得られる標準のファイル全体より小さいので、ダウンロードの時間と費用を節約でき、インストール時に必要な一時記憶域のオーバーヘッドの量が少なくなる。バイナリ差分ファイルは、２つの異なる標準パッケージ間のファイル／モジュールの差分を検出する作業に基づいて、ビルド時に生成される。ファイルが実行可能モジュールの場合は、リンカーで処理され、リンカーが定義したアドレスに配置される。それらは、最終的なロケーションに再配置されておらず、それらは、前述のようにインストール時にデバイス上に再配置される。
【００８０】
デバイス上にすでに存在するベースライン・バージョンに実行可能モジュールのバイナリ差分を適用するには、リンカーが生成したベース・アドレス（バイナリ差分の計算を開始したアドレス）へのこのベースライン・モジュールの再配置を解除する必要がある。再配置を解除されたモジュールにバイナリ差分が適用されると、このモジュールを適切なベース仮想アドレスに再配置できる。再配置を解除するプロセスと再配置するプロセスは同じ操作であり、いずれもベース・アドレスを特定のロケーションにシフトすることによる。
【００８１】
各パッケージが処理されると、カーネル・アップデートは図７Ｂのステップ７２４に進み、ここで変更されないモジュールがあればこれを新しいモジュール・リストに追加する。この時点で、古いファイル・リストにはアップデートされないモジュールとファイルが含まれており、こうしたモジュールは元のベース・アドレスに戻して未修正（un-fixed up）とし、全体として処理できる統一された唯一の未修正モジュールおよびファイル・リストが存在するようにしておく必要がある。新しいデバイス・マニフェスト・ファイルに記載された古いファイル・リストのオブジェクトは、新しいファイル・リスト中に転送される。ただし、ファイルが削除される場合は、新しいデバイス・マニフェスト・ファイルには記載されず、その結果新しいモジュール・リストには追加されない。
【００８２】
ステップ７２６と７２８でメモリ割当てと修正（fixups）が実行され、ステップ７３０で新しいＸＩＰカーネル・イメージが再びフラッシュに書き込まれる。この作業は、ディスク・イメージ・ツールでも実行され、ｒｏｍｉｍａｇｅ．ｄｌｌで実装される（後述）。ｒｏｍｉｍａｇｅには、モジュール・リストを取得してイメージを構築する機能がある。その機能は、新しいバッファを割り当てて新しいイメージを構成し、目次（ＴＯＣ）で指定されたとおりにモジュール・リスト全体をループして、データ・ポインタとコピー・ヘッダとファイル名で指定された該当するロケーションのセクション・データを適切なロケーションにコピーする。後述のとおり、イメージの終わりに新しいＴＯＣが書き込まれ、ｐＴＯＣポインタが新しいＴＯＣのロケーションを示すようにアップデートされる。さらに後述するとおり、ＮＫ／ＸＩＰイメージについてスロット０のデータ・セクションの各バンドが追跡され、これがＩＭＧＦＳの各バンドに連結されて、ＩＭＧＦＳアップデート中にＲＯＭＩＮＦＯ構造体を含むＩＭＧＦＳファイル中に出力される。
【００８３】
フラッシュに書き出す前に、このプロセスは、書き出し中であることをログ・ファイルに記録する。書き出しが完了すると完了したことが記録される。したがって、バックアップ・ファイルが削除される前に電源が失われた場合にも、正しい状態が認識される。
【００８４】
すべてが正常に終了すると、ステップ７３２でバックアップ・ファイルが削除される。このステップには、ファイルを削除した後にＸＩＰパーティションが完成したことをログ・ファイルに書き込む操作も含まれる。イメージがパーティション・サイズより大きくなった場合など、ＮＫ／ＸＩＰアップデート・プロセスのいずれかのステップでエラーが発生した場合は、イメージのバックアップ・バージョンがリストアされ、適切なユーザ・インターフェースを使用して、アップデート中にエラーが発生して、元のイメージがリストアされたことが示される。バックアップ・バージョンが正常に書き込みできなかった場合は（フラッシュ・エラーなど）、別のＵＩメッセージが表示され、アップデート中にエラーが発生し、元のイメージがリストアできなかったので、壊れている可能性があることが示される。
【００８５】
アップデートのステータスは、ＵｐｄａｔｅＢｉｎに対しても記録される。ただし、これは、トランザクション・ログを記録するためにアップデート・アプリケーションが内部的に利用するログ・ファイルとは異なる、ことに留意されたい。
【００８６】
この時点では、イメージを構成するモジュールとファイルについての唯一のファイル・リストが存在している。これは、「Creating File Systems Within a File In a Storage Technology-Abstracted Manner」という名称の関連米国特許出願で説明するように、ｒｏｍｉｍａｇｅ．ｄｌｌと連動して、ディスク・イメージ・ツールによって実行される初期インストールと同様である。
【００８７】
高度なパッケージ・インストール・プロセスには、パッケージのコンテンツを抽出するステップと、それをデバイスに適用するステップが含まれる。ただし、この技術には、主に、コードの修正（code fix-ups）またはコードの再配置の概念を中心として展開される多くのステップが含まれる。本発明では、修正／再配置（fix-ups/relocations）を、ビルド時にビルド・システム上で行うのではなく、デバイス上でインストール時に行う。利点は、特定のシステムへのパッケージ・インストールの適応能力にあり、そのインストールが、デバイス・イメージ全体がビルド時に利用可能であることを要求しないことである。それどころか、パッケージ・アップデートは、デバイスにインストールされた特定のオペレーティング・システム・イメージ構成からほとんど孤立したエンティティとして処理されることを可能にする。
【００８８】
実行可能モジュールが再配置可能であるためには、そのモジュールには、ベース・アドレスのロケーションが変更されるようにアップデートされることを必要とするモジュール内のアドレスをロケータに指示する情報が含まれている必要がある。イメージ・アップデート・モデルでは、再配置情報のエンコード・スキーマを利用して、実行可能モジュール自体の中に、圧縮した形で、この情報を提供する。
【００８９】
ＲｅｌＭｅｒｇｅツールは、「Self-Describing Software Image Update Components」という名称の米国特許出願で一般的に説明するように、モジュール（．ＥＸＥまたは．ＤＬＬ）をパッケージに含めるのに適した形式、したがってデバイスへのインストールに追加するのに適した形式に変換する。この作業には、再配置情報をデバイス上の長期の保存に適した圧縮形式に変換するステップと、ファイル・ヘッダをデバイス上のＲＯＭＦＳファイル・システムで使用する＿ｒｏｍバリアント（variants）に変換するステップが含まれる。さらに、中継する場合は、余分のパディングはファイルのすべてのセクションから削除される。
【００９０】
こうした情報を伴ってエンコードされると、実行可能モジュールのベースとなる仮想アドレスが変更され、モジュール内の関連のアドレス参照は、すべてベース・アドレスの変更に対して責任を持つように、変更されることになる。再配置のプロセスでは、デバイスとデスクトップの間で共有するコード・ライブラリを利用する。デスクトップの場合は、コード・ライブラリを使用して、コード・モジュール上で実際の再配置を実行する最初の製造イメージを作成すること、また個々のアップデート・モジュールをインストールするときに使用する仮想アドレス空間のリストを作成することが行われる。こうすることにより、このモジュールの再配置が重複しないことをＡＰＩのユーザが確認することができる。ディスク・イメージ・ツールとｒｏｍｉｍａｇｅ．ｄｌｌコンポーネントによる、初期製造イメージの作成については、「Creating File Systems Within a File In a Storage Technology-Abstracted Manner」という名称の関連米国特許出願を参照されたい。
【００９１】
一般に、仮想割当て／物理割当てと修正（fixing up）はディスク・イメージ・ツールと同様なこと、つまり、ＮＫ／ＸＩＰイメージの古い目次（ＴＯＣ）探し出すことを行い、古いＲＯＭＩＮＦＯを探し出す。ＴＯＣへのポインタは、イメージ内の設定されたロケーション（例えばオフセット０ｘ４４）に位置決めされる。古いＲＯＭＩＮＦＯ構造体は「．ｒｏｍ」というＩＭＧＦＳファイルから読み込まれる。
【００９２】
仮想アドレスを割り当てるために、スロット０のアロケータはスロット０のトップで開始され、ＩＭＧＦＳ  ＲＯＭＩＮＦＯ構造体内の値ｄｗＳｌｏｔ＿０  ＤｌｌＢａｓｅに基づいて終了する。スロット１のアロケータはスロット１のトップで開始され、ＩＭＧＦＳ  ＲＯＭＩＮＦＯ構造体内の値ｄｗＳｌｏｔ＿１＿ＤｌｌＢａｓｅに基づいて終了する。これでコードとデータは新しいＶＡ割当てに修正（Fix up）され、モジュール・リスト全体が使用可能になる。圧縮とマーク付けされたセクションは圧縮され、モジュール・オブジェクト内にサイズが記録される。
【００９３】
イメージに対して物理スペースを割り当てるには、ＲＡＭにはＲＡＭＩＭＡＧＥを、フラッシュにはＲＯＭＩＭＡＧＥを割り当てる。ＲＡＭの場合は、ＲＡＭＩＭＡＧＥ物理アロケータが古いＴＯＣのｐｈｙｓｆｉｒｓｔを開始アドレスとして使用する。物理アロケータの終了は、まず古いＴＯＣのｕｌＲＡＭＥｎｄとして指定される。ＲＡＭＩＭＡＧＥの場合は、ＲａｍＳｔａｒｔ＝ＰｈｙｓＦｉｒｓｔ＋ＰｈｙｓＬｅｎｇｔｈ（イメージに必要な実際の長さ）が物理アロケータから返される。つまり、コピー・セクションの仮想アドレスのロケーションは、ＲａｍＳｔａｒｔから開始されると決定され、そこから、コピー・セクションを参照するテキスト／データが修正（fix up）される。
【００９４】
ＲＯＭの場合は、ＲＯＭＩＭＡＧＥ物理アロケータが古いＴＯＣのｐｈｙｓｆｉｒｓｔを物理アロケータの開始アドレスとして使用する。物理アロケータの終了は、ＧｅｔＰａｒｔｉｔｉｏｎＩｎｆｏを使用してフラッシュ上のパーティションの長さを取得することで決定する。
【００９５】
ただし、物理割当てプロセスの間にアップデートされたＴＯＣが生成されることに留意されたい。
【００９６】
ＩＭＧＦＳパーティションでは、ＸＩＰパーティションとは異なり、イメージ全体はバックアップするには大きすぎるので再作成されない。代わりに、ＩＭＧＦＳファイル・システムを使用して、個々のモジュールやファイルに、同時に１つずつ、アップデートを同時に適用する。さらに、個々のモジュールやファイルは全体として非常に大きくなるので、アップデートは小さなブロックを介して適用されることにも留意されたい。このことについては図９を参照しながら以下に説明する。
【００９７】
ＩＭＧＦＳアップデートでは、一つのリストがプロセスの進行に伴ってアップデートされるけれども、ＮＴアップデートで実行したのと同じファイル・リストを使用する。以下に説明するように、ＩＭＧＦＳは、プロセス全体で２つのパスを必要とし、まず、アップデートのプロセスをシミュレートすることになる。第１のパスでは、ＩＭＧＦＳとアップデート・アプリケーションの両方がフラッシュに何もコミットしない。シミュレーションが正常に終了すると、第２のパスが実行されて実際に変更をコミットする。シミュレーションで問題が発生した場合は、パッケージ・バリデータと問題が発生したパッケージを除くパッケージのリストのパスを再実行した後にシミュレーションが再試行される。ここで、パッケージ・バリデータが返す新しいリストを使用して、もう一度シミュレーションが実行される。シミュレーションが正常に実行されるか、適用するパッケージがなくなるまで、シミュレーションが再試行される。このことによって、異常が発生しても署名されたパッケージ内のデータの破損が防止される。
【００９８】
図８Ａと８Ｂに、システム・パーティション・アップデートの一般的なロジックを示す。このロジックにおいてアップデート・アプリケーションは、読み取り／書き込みバージョンのイメージ・ファイル・システム・ドライバ（ＩＭＧＦＳ）とインターフェースし、システム・パーティションを管理する。ただし、一般的なシステムの標準の（アップデート以外の）オペレーションで、システム・パーティションは、ＩＭＧＦＳドライバへの読み取り専用である（したがって、フラッシュがロックされている）。さらに、システム・アップデートは、カーネル・アップデートと異なり、全体としてはバックアップされないが、トランザクション・ログによってシステム・アップデート・プロセスのエラー（例えば電源障害）が発生する前の状態にデバイスをリストアでき、このポイントからシステム・アップデートをレジュームできる、ことに留意されたい。
【００９９】
ステップ８００で、システム・パーティション（ＩＭＧＦＳ領域）内の既存のモジュールがスキャンされ、仮想アドレス（ＶＡ）アロケータに追加される。スキャンのプロセスの期間に、削除するケースも検出される。より具体的には、既存のデバイス・マニフェスト・ファイルを使用してＩＭＧＦＳ内のすべてのモジュールについて繰り返す際に、このプロセスでパッケージ用の新しいデバイス・マニフェスト・ファイルにファイルが見出されるかどうかを確認するチェックを行う。見出されない場合は、そのファイルはＩＭＧＦＳパーティションから削除され、このプロセスは、次のファイルに進む。見出される場合は、ＩＯＣＴＬ＿ＢＩＮ＿ＧＥＴ＿Ｅ３２とＩＯＣＴＬ＿ＢＩＮ＿ＧＥＴ＿Ｏ３２を使用して、新しいモジュールのフラグが新しいデバイス・マニフェスト・ファイルから取得され、モジュール・ヘッダがモジュール構造にロードされる。ただし、この時点では、モジュールとファイルのデータは必要ないので読み込まれない。各モジュール・ヘッダが読み込まれると、モジュール・リストがアロケータに渡され、（フラッシュに格納された予約テーブルから認識される予約されたセクションを含む）仮想アドレスが予約される。
【０１００】
既存のモジュールがスキャンされ、現在割り当てられている仮想アドレスが定義されると、プロセスはアップデートを開始できる。このために、このプロセスはパッケージごとにループして（ステップ８０２と８２８）、パッケージ内の各ファイルごとにループし（ステップ８０４と８２６）、各ファイルは１つずつ処理される。ファイルはサイズにおけるｎｅｔ  ｇａｉｎの順に処理される。つまり、その多くが縮小するファイルから開始し、その多くが増大するファイルで終了する。ファイル・サイズの変動は、古いデバイス・マニフェスト・ファイルと新しいデバイス・マニフェスト・ファイルを比較して決定する。
【０１０１】
このプロセスの間に電力が失われると、ログ・ファイルから、どのパッケージのどのファイルでプロセスが中断したかを正確にわかることになる。中断したファイルからプロセスがレジュームされ、電源障害が発生するまでにアップデートを完了したファイルは、既存のファイルとして処理される。復旧のために、アップデート処理中だった新しいモジュールは最初の予約には追加されず、古いモジュールが予約に追加されることになる。古いモジュールの仮想アドレス空間は通常どおり割当てが解除される。新しいヘッダがすでに書き出されている場合は、このヘッダが新しいモジュール用の仮想アドレス空間の割当てに追加される。この場合は、予約関数を使用して、ヘッダが仮想アドレス空間アロケータに追加される。新しいヘッダがまだ書き出されていない場合は、割当て関数を使用して通常どおり新しい仮想アドレス空間が割り当てられる。
【０１０２】
上の処理の一部には、（データ・ファイルでなく実行可能ファイルの場合）、ステップ８０６に示すように、仮想アドレスが変更されたかどうかを決定し、変更された場合は古い仮想アドレス空間の割当てを解除し、新しいモジュールの仮想アドレス空間を割り当てることで、アップデート・モジュールの仮想アドレス割当てをアップデートするステップが含まれる。仮想アドレスのサイズが変わる場合は、割当て解除関数が呼び出されて古い仮想アドレス空間をアロケータから削除し、コードまたはデータによって適切なアライメントの要件が渡される状態で、割当て関数が呼び出されて新しいモジュールの新しい仮想アドレス空間を割り当てる。割当て解除はモジュールを削除するコマンドに対応してもよい。この場合はステップ８０８と８２４で古いモジュールが削除される（ただし、インストールしたばかりの新しいモジュールの場合は削除されない）。削除コマンドでない場合は、ステップ８１０でＩＭＧＦＳ内のＣｒｅａｔｅＦｉｌｅ関数が呼び出され、例えばｎｅｗ＿＜ｍｏｄｕｌｅ  ｎａｍｅ＞．＜ｍｏｄｕｌｅ＿ｅｘｔｅｎｓｉｏｎ＞を使用して新しいファイルの名前を指定し、イメージ・ファイル・システム内に新しいファイル・システムを作成する（この操作に関連して電源障害が発生した場合に、復旧するために、このファイルが存在する場合は、このファイルは再作成されることはない）。
【０１０３】
実行可能ファイルの場合は、ステップ８１２で適切なヘッダがそれに書き込まれる。これは、新しいヘッダをモジュール・オブジェクトに読み込み、ステップ８１２を介して示すようにＩＯＣＴＬ＿ＢＩＮ＿ＳＥＴ＿Ｅ３２とＩＯＣＴＬ＿ＢＩＮ＿ＳＥＴ＿Ｏ３２を使用して新しい仮想アドレス空間割当てを使用してヘッダをアップデートすることで、なされる。各オペレーションはＩＭＧＦＳ内ではアトミック（atomic）である。この時点でヘッダは完成するはずである。カーネルがＥ３２／Ｏ３２を要求するとＩＭＧＦＳがこの値を偽造するので、データ・ポインタ（dataptr）が単独で残される（ゼロになって）。このヘッダは、ｂｉｎｄｉｆｆファイルの場合も、標準形式（canonical form）である。
【０１０４】
ヘッダの書き込みに関連して電力が失われた場合は、両方のヘッダが存在すればリカバリを実行する必要はない。Ｅ３２のみが書き出されている場合は、Ｏ３２ヘッダのみがもう一度書き出される。各ヘッダが存在するかどうかは、ＩＯＣＴＬ＿ＢＩＮ＿ＧＥＴ＿Ｅ３２とＩＯＣＴＬ＿ＢＩＮ＿ＧＥＴ＿Ｏ３２から認識される。
【０１０５】
アップデートを適用する場合、ファイルへのアップデートは標準形式（canonical form）とｂｉｎｄｉｆｆ形式のいずれでもよいことに留意されたい。アップデート・ファイルがモジュールでない場合は、このファイルのデータが個々のセクションと同様に処理される。ファイルがモジュールの場合は、各セクションが、ｎｅｔ  ｇａｉｎの順で一度に１つずつ処理され、その多くが縮小するセクションから開始される。まず、．ｃｒｅｌｏｃセクションが処理される。各セクションは新しいストリームに書き込まれる。ファイルが通常のデータ・ファイルの場合は、そのデータはデフォルトのストリームに書き込まれる。
【０１０６】
ステップ８１４でモジュールが標準アップデートと評価された場合は、ステップ８１６〜８２２でモジュール内の各セクションが処理される。このプロセスには、仮想アロケータによって割り当てられたアドレスに全体を再配置するステップ（ステップ８１８）と、セクション全体を新しいストリームとして新しいＩＭＧＦＳファイルに書き込むステップ（ステップ８２０）が含まれる。次に、ここでも「古い」モジュールが実際に新しいモジュールでない場合に、ステップ８２４で古いモジュールが削除される。
【０１０７】
標準アップデートの場合、電源障害の復旧は、書き出されている新しいファイル内の各ストリームのサイズを取得し、それを標準のファイル内の該当するセクションのサイズと比較することで実現する。新しいファイル内のストリームが標準のファイルより小さい場合、それはプロセスが中断したロケーションであり、ここからデータのコピーをレジュームできる。
【０１０８】
ｂｉｎｄｉｆｆアップデートの場合は、ｐａｔｃｈｂｉｎプロセスが一度に１ブロックずつ実行される（図９を参照しながら以下で説明する）。ただし、ブロックはページ／セクターと同じサイズである。これは、セクション周辺に古いバージョンと新しいバージョンの両方を保持するための十分なフラッシュ領域がないためである。新しいファイルのブロックはｂｉｎｄｉｆｆファイルに指定された任意の順序で作成できるので、フラッシュ空間を最適に利用しながらｐａｔｃｈｂｉｎプロセスを実行できる。新しいブロックが作成されると、古いブロックは必要なくなるので割当てが解除される。
【０１０９】
このために、ステップ８１４でモジュールが標準モジュールでない場合、プロセスは図８Ｂのステップ８３２に分岐し、ここでステップ８５２と連動してモジュール内のセクションごとにループを処理して１ブロックずつバイナリ・アップデートを適用する。より具体的には、ステップ８３４で新しいモジュール・ファイル内に該当するセクションのスパース・ストリームが作成され、古いセクションがＲＡＭに読み込まれる（ステップ８３６）。古いセクション全体は元のベース・アドレスに再配置される（ステップ８３８）。
【０１１０】
ｂｉｎｄｉｆｆファイル内の新しいブロックごとに（ステップ８４０と８５０）、ｂｉｎｄｉｆｆコマンドに基づいて新しいブロックが作成される（ステップ８４２）。ステップ８４４で仮想アドレス・アロケータによって割り当てられたアドレスに新しいブロックが再配置され、ステップ８４６でスパース・ストリームに書き出される。ステップ８４８に示すように、古いファイル・ストリームに不要になった古いブロックがある場合は、その割当てが解除される。ブロック・アップデートの概念については、以下でも図９を参照しながら説明する。
【０１１１】
ｂｉｎｄｉｆｆの場合は、ストリーム・サイズとヘッダで指定されたストリーム・サイズを比較して中断したセクションを絞り込むことで、電源障害が処理される。そのセクションが特定されると、通常どおりｐａｔｃｈｂｉｎのインスタンスが作成される。このインスタンスが順序どおりに次のブロックに戻り（ｐａｔｃｈｂｉｎの出力が再生可能／決定論的であることが必要）、ブロックがコミットされたかどうかがチェックされる。ブロックの書き込みはアトミックなので、一部のブロックをコミットすることはできない。ブロックがすでにコミットされている場合は、ｐａｔｃｈｂｉｎから返されたデータが破棄され、検証が行われ、該当する古いブロックがコミットを解除されているかどうかがチェックされる。中断したブロック（つまり、まだコミットされていないブロック）が検出されると、プロセスは通常どおり継続する。
【０１１２】
最終的に、これが既存のファイルまたはモジュールで、かつｂｉｎｄｉｆｆアップデートの場合は、古いモジュールが削除され（標準アップデートの場合は、ファイルがすでに削除されている）、モジュールが終了したことがログ・ファイルに記録される。パッケージが終了した場合は、モジュールでなくパッケージが終了したことが記録される。すべてのパッケージが終了すると、．ｒｏｍファイルが、ＮＫ／ＸＩＰとＩＭＧＦＳの両方のイメージのＳｌｏｔ０ベース、Ｓｌｏｔｌベース、およびＳ１ｏｔ０データの帯域幅を含むＲＯＭＩＮＦＯ構造体で、アップデートされる。
【０１１３】
ｂｉｎｄｉｆｆが十分なフラッシュ・ブロックを利用できないなど、ＩＭＧＦＳアップデート・プロセスのステップ中にエラーが発生した場合は、このエラーは復旧できない可能性が高いので、適切なエラーメッセージが表示されてアップデート・プロセスがキャンセルされ、復旧は試行されない。ただし、あらかじめシミュレーションを実行することでこうした問題が回避されることに留意されたい。
【０１１４】
理解されるように、カーネル・パーティションのアップデートはシステム・パーティションのアップデートとビルドおよびパッケージ化の観点からは同じであるが、処理は異なる。より具体的には、カーネル・パーティションをアップデートする場合はＮＫ．ＮＢ０（署名付きのカーネルパーティションイメージ）ファイルの一部がフラッシュからＲＡＭにフェッチされ、必要に応じて構成要素がアップデートされて修正（fix up）され、変更された．ＮＢＯコンテンツが隣接するブロックのフラッシュに書き戻される。このことは、必要に応じて不良ブロックをスキップすることを可能にする。
【０１１５】
本発明の別の態様に従って、前述メカニズムに記載したように、バイナリ差分ファイルを適用する最適な順序の概念を考慮する。理解されるように、スクラッチパッド・メモリの一部が、ベースライン・イメージにバイナリ差分ファイルを適用するために必要とされ、その結果、最終的なアップデートされたモジュール／ファイルが生成される。ビルド時に、バイナリ差分ファイルが生成される際、アレンジメントのプロセスが、結果として得られたイメージ上で実行され、バイナリ差分ファイル内のどのブロックが適用されるかについての方法が指定され、必要なスクラッチパッド・メモリの使用可能なサイズが特定の最大値に保持される。ビルド・システム上でこうした最適化を実行することにより、本発明は、デバイスが、イメージの全体的な増大（または縮小）を行うのに十分なメモリを備えており、且つ必要なスクラッチ・パッド・スペースがある場合に、デバイスが、アップデート・プロセスを完了するための十分なメモリを有していることが確実であるにことを保証する。アップデートを開始する前に、有効性確認プロセス中に、サイズを調べるチェックが実行される。
【０１１６】
図９は、ブロック・アップデートの概念を一般的に表している。一般的には、システム・ファイルは大きく、そうでない場合でも、新しいファイルが全体として作成されたり、古いファイル全体にバイナリ差分が適用されたりすると、大きな（空領域を上回る）一時記憶域を使用する可能性がある。そのようにしないで、アップデートされるブロックがアップデートされるファイル・ストリームにコピーされ、その後古いブロックが不要になった場合にその割当てが解除される状態で、差分アップデートが、アップデートされるファイルの既存のブロックに適用され、結果として新しいアップデートされたブロックが得られる。
【０１１７】
ブロック・アップデートを実行するために、古いブロックと新しいブロックの依存関係を表すグラフを作成する。これを図９のグラフ９００に一般的に示す。理解されるように、差分ファイル９０２が、この図式内のノードで表されるデータの実際のブロックに適用される。ある実装形態では、ブロックのサイズが４ＫＢであり、１度に最大３２ブロックを処理できる。つまり、システムをアップデートできることを保証するのに必要な容量は１２８ＫＢにすぎない。ただし、上の例でブロック・サイズと全体の上限は任意の値でよいが、システム・アップデートおよびデバイス上のアップデート・アプリケーションのプロバイダによって同意される必要がある。特定のアップデートが同意された制限を満足しない場合は、ベンダーのサイトでアップデートを構築する間に、ベンダーが依存性のリンク（dependency links）を切断する必要がある（こうしたブロックには差分でないアップデートが必要である）。
【０１１８】
図９に示すように、１つの古いアップデート・ブロックが１つまたは複数の新しいアップデート・ブロックに依存データ（異なるファイルが適用される）を提供でき、１つの新しいアップデート・ブロックが１つまたは複数の古いアップデート・ブロックに依存することができる。一般に、アップデートは、該当する差分ファイル（１つ以上）をこの古いブロックに、すべての差分ファイルが古いブロックに適用されるまで、適用することで進行する。この時点で、新しいブロックが古いブロックを必要としなくなるので、依存性のリンクを切断することができる（例えば、図９に示すように古いブロックＸと新しいブロックＹの間のリンクの切断）。これは古いブロックＸに関連付けられた唯一のリンクなので、古いブロックＸの割当てを解除して別のブロックに領域を解放することができる。同様に、依存性リンクは、差分ファイルを古いブロックに適用した後で切断されるので、新しいブロックに古いブロックへの依存性リンクがなくなると、つまり差分アップデートのプロセスで新しいブロックの記述が完了すると、必要に応じてこの新しいブロックをフラッシュにコピーでき、ＲＡＭの割当てを解除して別のブロックに領域を解放できる。ただし、複数のブロックの割当てを同時に解除してもよいことに留意されたい。
【０１１９】
言うまでもないが、差分アップデートを適用する順序は、メモリを解放するのに有効である。一般に、この順序は、まず、差分アップデートが、依存性が最大のリンクを有する新しいブロックへの、依存性が最小のリンクを有する古いブロックに適用される。アルゴリズムによって、（例えば、ｌｉｎｋ  ｃｏｕｎｔｅｒ  ａｒｒａｙの）２レベル検索が、最も高いカウントの新しいブロックを有する、最も低いカウントの古いブロックに対して、実行される。
【０１２０】
ブロック・アップデートに関するプレ・フラッシュシ・ミュレーション（pre-flash simulation）の実行に関連して、１回のシミュレーションにおいてどのような時点においてもファイル全体は存在しないので、各ブロックの書き込みに基づいてチェックサム（checksums）が計算され、結果としてのチェックサムが各アップデートのチェックサムに対して照合される。このシミュレーションで生成したチェックサムが適切な場合は、フラッシュへの実際のアップデートを実行することができる。
【０１２１】
次に、予約セクションのアップデートの説明に入る。図１０は、予約セクションのアップデート（例えばパーティションの外部）がＮＫパーティションのアップデートと同様の方法で、同じアップデート・コンポーネントを使用して実行される様子を示している。ステップ１０００と１０１６を介して、各予約関連のパッケージ・アップデートが、パッケージ内の各ファイルが処理され（ステップ１００２と１０１４）、ファイルがｂｉｎｄｉｆｆ（バイナリ差分）モジュールかどうかが判断されることで、処理される。バイナリ差分モジュールでない場合は、ステップ１０１０と１０１２で単にファイルからファイル・データが読み込まれて予約された領域に書き出される。ｂｉｎｄｉｆｆモジュールの場合は、既存の領域が読み込まれ（例えばＲＡＭに）、バイナリ差分が適用されてから、アップデートされたデータを予約された領域にもう一度書き出す。この様子をステップ１００６、１００８、１０１２に一般的に表す。
【０１２２】
キューに入ったパッケージのそれぞれについて、パッケージのコンテンツが（パッケージのバージョン別に）適切な順序で適用され、アップデートが完了すると、オプションでパッケージ・ファイルをユーザ・ストレージから削除したり、完了のマークを付けたりできる。この時点で、有効性を確認されたパッケージのコンテンツは適切なフラッシュパーティションにインストールされ、アップデート・アプリケーションはアップデート・モードを無効にする（フラッシュ・アップデート・フラグをクリアする）ことで作業を完了し、デバイスが再ブートする。前と同様に、イニシャル・プログラム・ローダーは現在のシステム・モードを検出するが、この時点ではフラグがクリアされているので、前述のようにアップデートされたオペレーティング・システム・イメージが、フラッシュをロックした状態でブートし、インストールが完了する。
【０１２３】
本発明の一態様に従って、フェイルセーフ／リカバリ・アップデートの方法が提供される。このために、予期しない電源喪失などによってアップデート・プロセスが中断した場合に、イメージ・アップデート設計の１つの要素によってフェイルセーフなリカバリが可能になる。フェイルセーフなリカバリを実装する手段には、アップデート・ローダーと、再入可能でログおよびファイル・システム・アーティファクト（例えば、ロールオーバー・リカバリ）を介してアップデート・オペレーションが中断したロケーションを決定できるようにするアップデート・アプリケーションを含む。トランザクション・ファイル・システムについても、新しいアップデートがストレージにコミットされるまで、ストレージへの古いコピーのコミットを完全に解除することなくファイルへのアップデートの書き込みをサポートするという改良が行われる（これは、例えばシステム・パーティション内のブロックなど、サブファイルの増大によって実現する）。ストレージにコミットされるポイントまでのインストール・プロセス全体のシミュレーションが、対応するコード・パスのほとんどすべてが使用されていることを、実際のアップデートの障害モードがハードウエア障害（例えばフラッシュの障害）または低レベルのフラッシュ・ソフトウェア・ルーチンの障害に縮小する状態で、確実にするように実行される。ＮＫ／カーネルおよび予約（例えば無線）領域のバックアップが提供され、その結果、指定可能な再試行回数の後にアップデートに失敗した場合に、元のイメージ・パーティションのコンテンツのバックアップがリストアされ、インストールが中断（すなわちロールバック・リカバリ）される。
【０１２４】
アップデート・アプリケーションはインストールの進行を追跡し、予期しない中断が発生した場合にその状態で復旧し、ＮＫ／カーネルおよび予約領域をバックアップ（および、可能な限り、リストア）される。アップデート・アプリケーションは、ＲＡＭＩＭＡＧＥ、ＲＯＭＩＭＡＧＥ、ＩＭＧＦＳ、予約イメージをアップデートする。ＲＡＭＩＭＡＧＥパーティションとＲＯＭＩＭＡＧＥパーティションは、デスクトップ・ディスク・イメージ・ツールでパーティションが生成されるのと同様の方法で生成される。つまり、既存のレイアウトを処理し、ＩＭＧＦＳとアロケータへの呼出しを作成してアップデートされたモジュールを仮想的および物理的に適切にアレンジすることでＩＭＧＦＳパーティションがアップデートされる。上で図１０を参照しながら説明した予約アップデートは、領域全体を上書きすることで実行される。
【０１２５】
ある実装形態では、アップデート・アプリケーションが起動すると、インストールするパッケージが、アップデート・アプリケーションの入力を収容する、ユーザ・ストア内のアップデート・アプリケーション入力ファイルで指定されたとおり、一時ディレクトリに保持される、と想定される。アップデート・アプリケーション入力ファイルのパスは、レジストリで指定される。アップデート・アプリケーションでは、保持ディレクトリのフル・パスが指定される限り、パッケージがどこに格納されているかも、内部データ・ストアかそれとも外付けのストレージ・カードかも、管理されない。アップデートに使用するビットマップ・ファイルへのパスも提供される。ただし、通常のオペレーティング・システム・コードは実行されないので、このようなビットマップは、ユーザ・インターフェース用（例えば、進捗バー、どのファイルをアップデートするか、エラーメッセージなどを表示するため）に提供されることに留意されたい。
【０１２６】
保持ディレクトリのパスをパッケージ・バリデータに渡すことでアップデート・アプリケーションが起動し、パッケージ・バリデータは、パッケージをインストールする順序を指定するリストを返す。このことについては、前述した「Determining the Maximal Set of Dependent Software Updates Valid for Installation」という名称の関連米国特許出願に記載されている。ここで、アップデート・ローダーは、ＸＩＰ、ＩＭＧＦＳ、および／または予約のいずれの場合も、図６を参照し上述したように、パッケージごとに適切なアップデートを繰り返し適用する。
【０１２７】
アップデート・アプリケーションは、ＮＫ／ＸＩＰパーティションのアップデートを担当するＮＫ／ＸＩＰアップデート・プロセスを含めて複数のプロセス／コンポーネントを備えていると考えることができる。このパーティション内のイメージはＲＯＭＩＭＡＧＥまたはＲＡＭＩＭＡＧＥのいずれでもよい（ここで、ＲＯＭＩＭＡＧＥはフラッシュから直接実行するイメージであり、ＮＯＲフラッシュが必要である。一方、ＲＡＭＩＭＡＧＥはＲＡＭにロードされるイメージであり、ＮＯＲフラッシュとＮＡＮＤフラッシュのいずれに格納してもよい）。イメージの種類にかかわらず、領域アップデートは読み出しと書き込みの際にブロック・ドライバに直接インターフェースする。
【０１２８】
イメージ・アップデートのもう１つのプロセス／コンポーネントはＩＭＧＦＳアップデートである。これは、イメージ・ファイル・システム（ＩＭＧＦＳ：Image File System）で管理するオペレーティング・システム・パーティションのアップデートを担当する。予約アップデート・プロセスは、無線または他の予約領域のアップデートを担当する。予約領域のアップデートは、読み出しと書き込みの際にブロック・ドライバに直接インターフェースする。
【０１２９】
Ｒｏｍｉｍａｇｅはデバイス製造時に初期インストール・イメージを提供するデスクトップ・ディスクイメージ・ツールとの共有コンポーネントであり、仮想および物理的な（ストレージ）割当てとモジュールの修正（fixup）を担当する。Ｒｏｍｉｍａｇｅ．ｄｌｌには、アロケータ・クラスの階層と複数のアロケータを作成して管理する機能、（ファイルまたはモジュールに関するメタデータを格納する）ファイル・クラスの階層と複数のファイルのリストを作成して管理する機能、およびアップデートとビルドのプロセスをサポートする機能を収容する。Ｐａｔｃｈｂｉｎコンポーネントは、ｂｉｎｄｉｆｆアップデートを適用して新しいファイルを生成するプロセスを提供する。古いモジュールのデータとｂｉｎｄｉｆｆのデータがこのコンポーネントへの入力として提供され、出力は新しいモジュールのデータである。ＵＩコンポーネントが提供され、アップデート・プロセスで適切なユーザ・インターフェース・データが表示される。ただし、ビジュアルなコンテンツはオペレーティング・システムのロケール設定に基づいて事前に生成されていてもよいことに留意されたい。
【０１３０】
ＮＫ／ＸＩＰアップデート・プロセスは、適用するＮＫ／ＸＩＰパッケージのリストを作成するアップデート・アプリケーションのメイン関数で呼び出される機能であってよい。ＮＫ／ＸＩＰパーティションへのアップデートには、イメージ全体を再作成するアップデート・アプリケーションが必要である（ディスク・イメージ・ツールはデバイスを効果的に処理する）。ＮＫ／ＸＩＰアップデートの間は、古いファイル・リストと新しいファイル・リストが保持される。古いファイル・リストはＮＫ／ＸＩＰパーティション内の現在のモジュールを使用して初期化され、この情報をパッケージと組み合わせて最終結果として新しいファイル・リストを作成する。新しいファイル・リストには、イメージを作成するのに必要な情報（ヘッダ、セクション・データ、フラグなど）が記載される。このリストは割当てプロセスを再実行できるように仮想および物理アロケータに渡される。
【０１３１】
前述の図７Ａと７Ｂは、カーネル領域がアップデートされる方法を説明している。図７Ａと７Ｂのステップを要約すると、このプロセスはＸＩＰ（または他の）領域全体をＲＡＭに読み込み、圧縮されたファイルとしてユーザ・ストレージにバックアップし、ＸＩＰ領域内の既存のモジュールをスキャンしてヘッダや他のメタデータを読み込み、アップデートされたモジュールとファイルの未修正版（unfixed-up versions）が作成される。次に、プロセスは、残りの変更されないモジュールとファイルを新しいモジュール・リストに追加し、仮想／物理割当てとモジュールの修正（module fixup）を実行し、新しいイメージをもう一度フラッシュに書き込む。
【０１３２】
プロセスの終了まで、フラッシュには何もコミットされないので、このステップのフェイルセーフな方法は非常に簡単である。したがって、新しいイメージが書き込まれる前に電源障害が発生した場合は、単にプロセスを再実行すればよい。新しいイメージの書き出し中に電源障害が発生した場合は、古いイメージのバックアップ・コピーが存在するのでこれを使用してイメージのリカバリを行う（新しいイメージを書き出し中であったことがログ・ファイルに記録されている場合は、圧縮されたバックアップ・ファイルを使用して古いイメージのコピーをリストアする）。処理中のステップがログ・ファイルに記録されるので、プロセスがエラーになったロケーションを簡単に確認できる。
【図面の簡単な説明】
【０１３３】
【図１】本発明を組み込むことができるコンピュータ・システムの一般的な例を示すブロック図である。
【図２】本発明の一態様に従ってフェイルセーフなコンポーネント・アップデートを可能にするための、パーティションに分割されたオペレーティング・システム・イメージとローダー・コンポーネントを示すブロック図である。
【図３】本発明の一態様に従ってデバイスのストレージにアップデート・パッケージを適用する方法を示すブロック図である。
【図４】本発明の一態様に従ったパッケージを説明するデバイス・マニフェスト・ファイルのフォーマットを表すブロック図である。
【図５Ａ】本発明の態様に従ってアップデート・モードを決定するイニシャル・プログラム・ローダーのブート・プロセスのロジックの例を表す流れ図である。
【図５Ｂ】本発明の態様に従ってアップデート・モードを決定するイニシャル・プログラム・ローダーのブート・プロセスのロジックの例を表す流れ図である。
【図６】本発明の一態様に従ったアップデート・プロセス全体のロジックの例を示す流れ図である。
【図７Ａ】本発明の一態様に従ったカーネル・パーティション・アップデートのロジックの例を示す流れ図である。
【図７Ｂ】本発明の一態様に従ったカーネル・パーティション・アップデートのロジックの例を示す流れ図である。
【図８Ａ】本発明の一態様に従ったオペレーティング・システム・パーティション・アップデートのロジックの例を示す流れ図である。
【図８Ｂ】本発明の一態様に従ったオペレーティング・システム・パーティション・アップデートのロジックの例を示す流れ図である。
【図９】本発明の一態様に従った依存関係の図式を使用してブロック内のデバイスにアップデートを適用する方法を示すブロック図である。
【図１０】本発明の態様に従った予約メモリセクションアップデートのロジックの例を示す流れ図である。
【符号の説明】
【０１３４】
１２０  ハンドヘルド・コンピューティング・デバイス
１２２  プロセッサ
１２４  メモリ
１２６  タッチ・スクリーン・ディスプレイ
１２８  キーボード
１２９  マイクロフォン
１３０  ＯＳ
１３２  アプリケーション
１３４  通知マネージャ
１３６  ネットワーク・スイッチ
１３８  ネットワーク・コンポーネント
１４０  電源
１４２  ＬＥＤ（ｓ）
１４４  オーディオ・ジェネレータ
９００  古いブロックと新しいブロックの依存関係を表すグラフ
９０２  差分アップデート
【図１】
2005196747.tif 000007
【図２】
2005196747.tif 000008
【図３】
2005196747.tif 000009
【図４】
2005196747.tif 000010
【図５Ａ】
2005196747.tif 000011
【図５Ｂ】
2005196747.tif 000012
【図６】
2005196747.tif 000013
【図７Ａ】
2005196747.tif 000014
【図７Ｂ】
2005196747.tif 000015
【図８Ａ】
2005196747.tif 000016
【図８Ｂ】
2005196747.tif 000017
【図９】
2005196747.tif 000018
【図１０】
2005196747.tif 000019
【外国語明細書】
2005196747000001.pdf