JP2006506747A - 電子ファイル更新中におけるデバイス・メモリ管理 - Google Patents

Abstract

メモリ管理を実行する際、ホスト・デバイスのアップグレード・クライアント（１３０）は、第１および第２メモリ・エリアの順次探索を実行することによって、新ソフトウェア・コンポーネントを収容できる十分な大きさのメモリ・ブロックを特定し予約する。新ソフトウェア・コンポーネントは、元のソフトウェア・ファイル（１１０）のコンポーネントの更新バージョンである。新コンポーネントのサイズが、第１および第２メモリ・エリアで使用可能なブロックのサイズを超過する場合、アップグレード・クライアント（１３０）は、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、第１および第２メモリ・エリアを再分配し、新コンポーネントを第２メモリ・エリアに書き込み、ベクトル・テーブルを更新する。ホスト・デバイスのソフトウェア・コンポーネントにアクセスするには、アップグレード・クライアントは、ホスト・デバイス（１０４）の主プログラムから、対応するソフトウェア・ファイルの識別情報を含む関数コールを受け取り、ベクトル・テーブルから対応するソフトウェア・ファイルの開始アドレスを読み取り、対応するソフトウェア・ファイルに対するコールを発生する。

Description

開示する実施形態は、電子ファイル更新中におけるメモリ管理に関する。

関連出願
本願は、以下の米国特許出願に関連がある。２００２年５月１３日に出願された出願番号第１０／１４６，５４５号、２００２年９月３０日に出願された特許出願第１０／２６１，１５３号、２００２年１１月１２日に出願された特許出願第１０／２９２，２４５号、２００２年１１月１８日に出願された出願番号１０／２９８，３９３号、２００２年１１月１８日に出願された出願番号１０／２９８，８６３号、２００２年１１月１８日に出願された出願番号１０／２９８，８６２号、および２００２年１１月１８日に出願された出願番号第１０／２９８，８９６号。これらの全ては、現在係属中である。

ホスト・デバイスのある機能を実現するために中央演算装置（ＣＰＵ）上で実行するソフトウェアは、時間と共に変化していくことが多い。この変化は、ソフトウェア・バグを訂正する必要性から生じたり、発展する技術に適合するためであったり、あるいはホスト・デバイスに新たな特徴を追加するためであると考えられる。特に、移動ワイヤレス・デバイス上に常駐する埋め込みソフトウェア・コンポーネントは、多数のソフトウェア・バグを含み、訂正しなければならないことが多い。

ソフトウェアは、人が読むことができる情報相互交換用アメリカ標準コード（ＡＳＣＩＩ）の平文ファイルまたは二進コードの形態の１つ以上のファイルを含む。ソフトウェア・ファイルは、更に小さな単位に分割することができ、多くの場合これらをモジュールまたはコンポーネントと呼ぶ。ＵＮＩＸ（登録商標）プラットフォームまたはパーソナル・コンピュータ（ＰＣ）は、多数のソフトウェア・コンポーネントを含み、これらソフトウェア・コンポーネントの各々は、対応するオペレーティング・システム（ＯＳ）が対応するファイル・システムを通じて独立して管理および更新が行われる。ＵＮＩＸ（登録商標）プラットフォームまたはＰＣ上に常駐するソフトウェア・ファイルまたはソフトウェア・コンポーネントを更新する際に用いられる情報は、インターネットを通じて転送したり、あるいはフロッピ・ディスク、コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、またはコンパクト・フラッシュ・カードのような二次的な記憶媒体からロードすることができる。

対照的に、移動ワイヤレス・デバイスでは、リアル・タイム・オペレーティング・システムＯＳ（ＲＴＯＳ）が使われるのが通例であり、この場合全てのソフトウェア・コンポーネントは単一の大きなファイルとしてリンクされている。更に、これらの移動ワイヤレス・デバイスには、ファイル・システムの対応は設けられていないのが通例である。加えて、単一の大きなファイルは、無線、赤外線、またはシリアル・リンクのような低速通信リンクを用いて、デバイス内に予めロードする、即ち、埋め込む必要がある。

低速通信リンクを通じて移動ワイヤレス・デバイスの大きなファイルを更新する場合の障害には、更新したファイルをデバイスに配信するのに伴う時間が含まれる。差分ファイルを、更新／改訂の目標となるファイルが常駐するデバイスに転送する場合、この時間は、差分ファイルを転送するための通信時間、ならびに受信側装置が差分ファイルを処理し、目標のファイルを更新／改訂するために用いられる時間の双方を含む。これを、ここでは、ホスト・デバイス処理時間と呼ぶ。関連出願に記載されているように、更新したソフトウェア・ファイルまたはソフトウェア・コンポーネントを転送するためにデルタ・ファイルを用いると、通信時間が大幅に短縮するが、ホスト・デバイスの処理時間の短縮は、少なくとも部分的に、ホスト・デバイスのアーキテクチャによって決まる。

ホスト・デバイスは、プロセッサを用いた多数のデバイスのいずれでも可能であり、セルラ電話機およびその他の移動通信デバイス、パーソナル・ディジタル・アシスタント（ＰＤＡ）、ならびにパーソナル・コンピュータを含む。一例としてセルラ電話機を用いると、典型的なセルラ電話機のアーキテクチャは、ここではフラッシュＲＯＭまたはフラッシュ・メモリと呼ばれる、フラッシュ・リード・オンリ・メモリ（ＲＯＭ）と、ＲＴＯＳとを含む。フラッシュ・メモリおよびＲＴＯＳの双方は、ホスト・デバイスの処理時間を短縮するという目標に対して障害を招く潜在性がある。

ホスト・デバイスの処理時間を短縮する際にフラッシュ・メモリに関して発生する問題は、フラッシュ・メモリに対して書き込みを行うやり方に関係する。フラッシュ・メモリは、ブロック、セクタ、セグメントと呼ばれることが多い単位で割り当てられ、その各々は多数のバイトを含む。典型的なフラッシュ・メモリへの書き込み（または書き換え）は、ユニット全体の消去および書き込み（または書き換え）を必要とし、単一ビットまたはバイトの書き込み（または書き換え）はできないことを意味する。したがって、フラッシュ・メモリ内に格納されている１バイトの更新または改訂には、当該バイトが格納されている単位全体の消去および書き換えが必要となる。このため、フラッシュ・メモリに格納されているファイルを更新または改訂するために必要となる時間は、単一のバイトを書き込む（または書き換えを行う）ことができる他の種類のストレージ即ちメモリに格納されているファイルを更新または改訂するために必要な時間よりも長いのが通例である。

ホスト・デバイスの処理時間を短縮する際にＲＴＯＳに関して発生する問題は、ホスト・デバイス・ソフトウェアを編成し管理するやり方に関係する。典型的なセルラ電話機のＲＴＯＳは、実行時における関数コールに対するファイル管理および動的アドレス解明(dynamic address resolution)をサポートしていない。したがって、セルラ電話機に埋め込まれている全てのソフトウェア・コンポーネントまたはプログラムは、単一の大きなホスト・プログラムにリンクされており、ホスト・プログラム内にある機能は、ホスト・プログラムのいずれの部分からでも、予めコンパイルされている当該機能の開始アドレスを介して直接コールされる。このため、機能管理のためにファイル管理および動的アドレス解明をサポートする典型的なコンピュータＯＳとは対照的に、典型的なセルラ電話機のＲＴＯＳは、多数のソフトウェア・コンポーネントを別個のファイルとして管理することや、実行時コール元アドレス解明によって、ソフトウェア・コンポーネントの１つから他のソフトウェア・コンポーネントへの関数コールをサポートすることができない。その結果、ＲＴＯＳを含むシステムのホストは、単一の大きなプログラムを管理し、プログラムの機能に直接アクセスするために静的アドレッシングを用いている。

この典型的なデバイス・アーキテクチャは、ソフトウェア・コンポーネントを更新および改訂する際に、問題を生ずる可能性がある。何故なら、改訂または更新の結果ホスト・プログラム・サイズが変化した場合、ホスト・システムにおいて更新／改訂したソフトウェア・コンポーネントに続くソフトウェア・コンポーネントのアドレスも変化する結果となる。このソフトウェア・コンポーネントの開始アドレスの変化の結果、ホスト・プログラムにおいて対応するコール元アドレス、およびソフトウェア・コンポーネント内にある命令／データ・アドレスを更新する必要性が生ずる。これは、処理時間に関して費用が嵩む可能性がある。このように、埋め込みソフトウェアの更新／改訂に伴うホスト・デバイスの処理時間は、大部分が、フラッシュ・メモリへの非効率的なデータの書き換え、およびソース・コード・レベルでの埋め込みソフトウェアの小さな変化が、二進コード・レベルでの埋め込みソフトウェアに対する大きな変化となり得るという事実によるものである。

図面においては、同じ参照番号は、同一のまたは実質的に同様のエレメントあるいはアクトを識別するものとする。いずれの特定のエレメントまたはアクトの論述であっても容易に識別するために、参照番号の内最上位の１つまたは複数の桁は、当該エレメントが最初に紹介された図番を示す（例えば、エレメント１３０は、図１において最初に紹介され、これについて論ぜられた）。

以下で特に記載しない限り、図に示す種々のブロックおよび構造の構成および動作は、従来の設計通りとする。その結果、このようなブロックは、ここでは更に詳細に説明する必要はなくなる。何故なら、これらは、当業者には理解されるはずであるからである。そのような更なる詳細は、簡潔性のため、そして本発明の詳細な説明を曖昧にしないようにするために、省略する。図に必要なあらゆる変更は、ここに示す詳細な説明に基づけば、当業者には容易に行うことができよう。

これより、メモリ管理システムおよび方法について詳細に説明する。メモリ管理を実行する際、ホスト・デバイスのアップグレード・クライアントは、第１おおび第２メモリ・エリアの順次探索を実行することによって、新たなソフトウェア・コンポーネントを収容できる十分な大きさのメモリ・ブロックを特定し予約する。新たなソフトウェア・コンポーネントは、元のソフトウェア・ファイルの更新またはアップグレード・バージョンである。新たなコンポーネントのサイズが、元の電子ファイルの対応するコンポーネントのサイズと同等以下の場合、アップデータ・クライアントは、第１メモリ・エリアの元のメモリ・ブロックを割り当て、この中に、受け取ったコンポーネントを書き込む。元のメモリ・ブロックは、元の電子ファイルの対応するコンポーネントを含む。

新たなコンポーネントのサイズが、元の電子ファイルの対応するコンポーネントのサイズを超過した場合、アップグレード・クライアントは、第１メモリ・エリアの未使用部分を探索して、受け取ったコンポーネントを格納できる十分な大きさのメモリ・ブロックを求める。第１メモリ・エリア内で突き止められた場合、アップグレード・クライアントは、しかるべきサイズのメモリ・ブロックを予約し、それ以外の場合、アップグレード・クライアントは第２メモリ・エリアを探索する。第２メモリ・エリア内で突き止められた場合、アップグレード・クライアントは、しかるべきサイズのメモリ・ブロックを予約する。

しかしながら、新たなコンポーネントのサイズが、第１および第２メモリ・エリアの使用可能なブロックのサイズを超過した場合、アップグレード・クライアントは、第１メモリ・エリアを書き換え、未使用メモリ・ブロックを排除する。第１メモリ・エリアの書き換えに続いて、アップグレード・クライアントは、順次第２メモリ・エリアのソフトウェア・コンポーネントを、第１メモリ・エリアのコンポーネント・サイズおよび使用可能なブロックが許される、第１メモリ・エリアの未使用部分に書き込むことによって、第１および第２メモリ・エリアを再分配する。続いて、アップグレード・クライアントは、第１メモリ・エリアの残りの未使用部分を、第２メモリ・エリアの一部として指定し直す。再分配に続いて、アップグレード・クライアントは、新たなコンポーネントを第２メモリ・エリアに書き込み、ベクトル・テーブルを更新する。

ホスト・デバイスのソフトウェア・コンポーネントへのアクセスに関して、アップグレード・クライアントは、ホスト・デバイスの主プログラムから関数コールを受け取る。ここで、関数コールは、対応するソフトウェア・ファイルの識別情報を含む。アップグレード・クライアントは、識別情報を用いてベクトル・テーブルにアクセスし、ベクトル・テーブルから対応するソフトウェア・ファイルの開始アドレスを読み出す。識別情報と共にベクトル・テーブルからの開始アドレスを用いて、アップグレード・クライアントは、対応するソフトウェア・ファイルに対するコールを発生する。

図１は、一実施形態の下において、バイト・レベル・ファイル差別化および更新（ＦＤＵ）アルゴリズムを用いて電子ファイルを更新するシステムのブロック図である。このアルゴリズムを、ここではＦＤＵアルゴリズムと呼ぶ。ＦＤＵアルゴリズムは、差別化コンポーネントと更新コンポーネントを含む。差別化コンポーネントは、ここではファイル差別化アルゴリズムと呼び関連出願において詳細に記載されているが、電子ファイルの元のバージョンおよび新バージョンから、第１コンピュータ・システムにおいて差分ファイルを生成する。更新コンポーネントは、ここではファイル更新アルゴリズムと呼び関連出願において詳細に記載されているが、差分ファイルおよび元のファイルの常駐コピー(hosted copy)を用いて、第２コンピュータ・システム上に新ファイルのコピーを生成する。以下の説明では、本発明の実施形態を完全に理解するため、そしてその説明を可能にするために、多数の具体的な詳細を紹介する。しかしながら、本発明は、これら具体的な詳細の１つ以上が無くても、または他のコンポーネント、システム等を用いても実施できることを、当業者は認めよう。その他の場合には、周知の構造または動作については、本発明の態様を曖昧にするのを防ぐために、図示も詳細な説明も行わない。

図１を参照すると、第１コンピュータ・システム１０２および第２コンピュータ・システム１０４は、通信経路１０６を通じて通信する。これらのコンピュータ１０２および１０４は、一緒に動作する計算デバイスのあらゆる集合体を含む。これは、当技術分野では周知である。通信経路１０６は、コンピュータ・システム１０２および１０４間でファイルを伝達または転送するためのあらゆる媒体を含む。したがって、この経路１０６は、ワイヤレス接続、ワイヤード接続、ハイブリッド・ワイヤレス／ワイヤード接続を含む。また、通信経路１０６は、ローカル・エリア・ネットワーク（ＬＡＮ）、市内区域ネットワーク（ＭＡＮ：metropolitan area network)、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有のネットワーク、オフィス間またはバックエンド・ネットワーク、およびインターネットを含むネットワークに対する結合部即ち接続部も含む。更に、通信経路１０６は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクのような、着脱可能な固定媒体、ならびに電話線、バス、および電子メール・メッセージを含む。

第１通信システム１０２は、元の、即ち、古いバージョン１１０および新バージョン１１２の電子ファイルを受信する。新ファイル１１２は、一般には、元のファイル１１０の更新または改訂バージョンであるが、そのように限定される訳ではない。電子ファイル１１０および１１２に含まれるソフトウェア・ファイルには、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人使用データを含むファイルが含まれるが、これらに限定される訳ではない。いずれの形式のファイルでもバイト・ストリームと見なすことができるので、以後文脈によってはファイルのことを、バイト・ストリームと記載することもあり得る。

ファイル差別化アルゴリズム１１４は、新ファイル１１２を受信し、それを元のファイル１１０と比較し、比較したファイル間におけるバイト・レベルの差を計算する。これについては以下で説明する。また、ファイル差別化アルゴリズム１１４は、元のファイル１１０および新ファイル１１２の前処理も行い、ファイルの差を計算するのに先だって、ファイル・サイズを縮小することもできる。ファイル差別化アルゴリズム１１４は、比較の間に、差ファイル１１６を生成する。ここでは、これをデルタ・ファイルと呼ぶ。

デルタ・ファイル１１６の内容は、新ファイルおよび元のファイル間のバイト・レベルの相違を効率的に表す。デルタ・ファイル１１６は、実際の置換データおよび／または関連するファイルの新即ち現バージョンとそのファイルの以前のバージョンとの間の差を表す挿入動作と共に、メタデータを含む。これについては以下で説明する。ファイル差別化アルゴリズム１１４は、最少数のバイトおよび以下で説明する既定のフォーマットまたはプロトコルを用いて、デルタ・ファイル１１６の中に、元のファイル１１０と新ファイル１１２との間のあらゆる相違を提示することによって、空間的に最適化したデルタ・ファイルを供給する。

デルタ・ファイル１１６は、通信経路１０６を通じて、別のコンピュータ・システムに転送または送信される。転送の前に、当技術分野では公知の圧縮技法を用いて、デルタ・ファイル１１６を圧縮することもできるが、そのように限定される訳ではない。受信側のコンピュータ・システム上に常駐(host)するファイル更新アルゴリズム１１８は、デルタ・ファイル１１６を、常駐する元のファイル１１０と共に用いて、新ファイル１１２のコピーを生成即ち作成する。この新ファイル１１２のコピーは、次に、改訂または更新の対象である、クライアント・デバイス上に常駐する元のファイル１１０を更新する際に用いられる。この更新プロセスの完了時に、第２コンピュータ・システム上に現在格納されている新ファイルは、第１コンピュータ・システムにおいて受信した新ファイルと同一となる。

元のファイルと新ファイルとの間の相違は、通例では、新ファイル自体よりも小さいので、新たなバイト・ストリーム全体の代わりに、差分を送信し格納すれば、格納および送信において大幅な節約となる。これは、通例では遅くしかも費用がかかる可能性が高い接続部、例えば、ワイヤレスまたはセルラ接続部を通じて更新するプログラムを常駐させる移動電子デバイスにとっては、特に重要である。

図２は、一実施形態のソフトウェア・アップグレード・システム２００のブロック図である。このシステムを、ここではアップグレード・システムと呼ぶ。アップグレード・システム２００は、一実施形態のデルタ・ファイルおよびファイル更新アルゴリズムを用いて、クライアント・デバイスのためにソフトウェア保守およびアプリケーション管理をサポートする。クライアント・デバイスには、移動電子デバイス、移動通信デバイス、セルラ電話機、パーソナル・ディジタル・アシスタント、コンピュータ、およびプロセッサを用いたデバイスが含まれる。このサポートは、通信業者(carrier)およびデバイス製造業者に、ワイヤレス・インフラストラクチャを通じて効率的に電子ファイル・コンポーネントやアプリケーションを流通することを可能にすることによって、ファームウェアから埋め込みアプリケーションまでの範囲に及ぶあらゆるデバイス・ソフトウェアに対して提供されている。

アップグレード・システム２００は、サービス・プロバイダのワイヤレス・インフラストラクチャの種々の機構を用いて、新たなおよび改訂したソフトウェアのファイルの供給をサポートすることによって、デバイスのリコールを防止する。これらのシステムは、新たなおよび改訂したソフトウェアをソフトウェア流通業者から受け取り、ファイル差別化アルゴリズムを用いて新たなソフトウェアからデルタ・ファイルを生成することによって機能する。デルタ・ファイルは、サービス・プロバイダのインフラストラクチャを通じて、クライアント・デバイスに転送される。受信側即ちクライアント・デバイスのアップグレード・クライアントは、ファイル更新アルゴリズムを含み、デルタ・ファイルを用いて、クライアント・デバイス上に常駐し目標とされているソフトウェアを更新する。

アップグレード・システム２００は、デバイスのソフトウェアおよびハードウェア間の異なるライフ・サイクルを可能にする。したがって、このアップグレード・システムは、Ｊａｖａ（登録商標）Connected Limited Device Configuration（ＣＬＤＣ：接続限定デバイス・コンフィギュレーション）ライブラリ、ムービング・ピクチャ・エキスパーツ・グループ−１（ＭＰＥＧ−１）レイヤＩＩＩ（ＭＰ３）ドライバ、通信ソフトウェア、およびブラウザ・アプリケーションが、ホスト・デバイスのハードウェアよりも速く発展し、その結果、移動デバイスの製造業者が新世代のデバイスを配給するよりも頻繁に更新されるという事実に鑑み、最新のデバイス機能をサポートする。アップグレード・システム２００については、以下で更に詳細に説明する。

図２を参照すると、アップグレード・システム２００は、デバイス２１２とのワイヤレス接続部を介して、クライアント・デバイス１０４上の埋め込みソフトウェア・コンポーネントを維持することによって、ワイヤレス通信業者が連続的に最新のデータ・サービスを全てのユーザに提供できるようにしている。アップグレード・システム２００は、ソフトウェア・コンポーネント分配部（ＳＣＤ）２０２、サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５、およびクライアント・デバイス１２２上にホストされているアップグレード・クライアント１３０を含むが、これらに限定される訳ではない。サービス・プロバイダ・アップグレード・コンポーネントは、ソフトウェア・コンポーネント証明サーバ２０３およびアップグレード・マネージャ２０５との間に結合されているアップグレード・サーバ２０４を含む。

一実施形態のソフトウェア・コンポーネント分配部２０２は、ウェブに基づいたユーザ・インターフェースを設け、これによってソフトウェア供給業者は、改良したＭＰ３ドライバ、アップグレードしたＪａｖａ（登録商標）２プラットフォーム、Micro Edition (J2ME^TM) Mobile Information Device Profile（ＭＩＤＰ：移動情報デバイス特性）、または特徴付加アドレス・ブック・アプリケーションのような新たな埋め込みデバイス・ソフトウェア・コンポーネントをパッケージ化し、公表する。ソフトウェア・コンポーネント分配部２０２の機能には、デバイス情報を登録すること、およびデバイス情報をソフトウェア・コンポーネント証明サーバに提出することが含まれる。また、ソフトウェア・コンポーネント分配部２０２は、新ＥＢＳＣおよび元のＥＢＳＣを受信し、ファイル差別化アルゴリズムを用いてこれらからファイル差を生成し、埋め込みソフトウェアを登録およびパッケージ化し、埋め込みソフトウェア・パッケージをソフトウェア・コンポーネント証明サーバに提出する。新たなソフトウェアは、公表に続いて、ワイヤード、ワイヤレス、あるいは混成ワイヤード／ワイヤレス・ネットワーク結合部または接続部２２０を通じて、サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５に供給されるが、そのように限定される訳ではない。

一実施形態のソフトウェア・コンポーネント分配部２０２は、クライアント・デバイス製造業者の処理システム上に常駐している。代替実施形態では、ソフトウェア・コンポーネント分配部２０２は、アプリケーションまたはシステム・ソフトウェア供給業者の処理システム上に常駐している。別の代替実施形態では、ソフトウェア・コンポーネント分配部２０２は、通信サービス・プロバイダの処理システム上、例えば、アップグレード・コンポーネント２０３〜２０５上に常駐している。

サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５は、ソフトウェア・コンポーネント分配部２０２、クライアント・デバイス１０４、既存のゲートウェイ２１０や通信インフラストラクチャ２１２、請求書発行サーバ２１４、ロギング・サーバ(logging server)２１６、および認証サーバ２１８を含むサービス・プロバイダのインフラストラクチャ２０１〜１２８の既存のコンポーネント間で結合されている。ソフトウェア・コンポーネント証明サーバ２０３は、クライアント・デバイスの製造業者へのインターフェースを設け、したがって、デバイス製造業者からの埋め込みソフトウェア・パッケージに関する新たなデバイス情報を受信する。また、ソフトウェア・コンポーネント証明サーバ２０３は、ソフトウェア・コンポーネント分配部からソフトウェア・コンポーネント提出要求を受け、新たなソフトウェア・パッケージの承認／拒絶を、提出したアップグレード・サーバに通知し、提出され承認されたソフトウェア・パッケージに対してディスク管理を行い、承認されたソフトウェア・パッケージを再パッケージ化(repackage)しアップグレード・サーバに分配する。更に、ソフトウェア・コンポーネント証明サーバ２０３は、潜在的に可能性がある侵入やデータ改竄に対して、ソフトウェア・コンポーネント提出プロセスの間に通信業者級のセキュリティ制御を行う。

アップグレード・マネージャ２０５は、ソフトウェア・コンポーネント証明サーバ２０３およびアップグレード・サーバ２０４間でインターフェースとして機能し、ウェブに基づくユーザ・インターフェースを設け、これによってワイヤレス・キャリア・システム管理運営者は、埋め込みデバイスのソフトウェア・コンポーネントのアップグレードを検証し承認する。また、アップグレード・マネージャ２０５は、最適なデバイス管理のためにソフトウェアおよびデータのパッケージングを行い、遠隔変更通知(remote change notification)のスケジューリングを行い、更新ポリシ・モニタ・システムを制御する。更に、アップグレード・マネージャ２０５は、既存のインフラストラクチャのシステム、即ち、バック・エンド・システム（請求書発行、ユーザ・データベース認証、ウェブ・ポータル）との統合を行うことによって、認証、アクセス制御、ならびにそれらの既存の請求書発行サーバ２１４およびロギング・サーバ２１６への統合を判定するワークフローを備えている。

アップグレード・サーバ２０４は、認証、接続、移動クライアント・デバイス１２２との通信を含む機能を備えており、埋め込みソフトウェア・コンポーネントのアップグレードを行う。クライアント・デバイス１０４との通信は、クライアント・デバイス１２２とのワイヤレス結合部２１２、ワイヤード結合部、混成ワイヤード／ワイヤレス結合部、および対応するサービス・プロバイダに適したその他のネットワーク結合部を介して行うことができる。加えて、アップグレード・サーバ２０４は、サービス・プロバイダの既存の請求書発行、データ収集、およびロギング・サービスにも対応する。

アップグレード・サーバ２０４およびクライアント・デバイス１０４間の通信の一例として、アップグレード・ファイルがアップグレード・サーバ２０４からクライアント・デバイス１２２に転送できるようになったときに、サーバ２０４はユーザ通知を送って、クライアント・デバイスのユーザに、更新に利用できるソフトウェア・コンポーネントがあることを通知する。ユーザ通知は、ショート・メッセージ・サービス（ＳＭＳ）プッシュ・プロトコル、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）、またはワイヤレス・アプリケーション・プロトコル（ＷＡＰ）によるテキスト・メッセージの形態を取ることができるが、そのように限定されるのではない。ハンドセット・ユーザからの確認を受信すると、アップグレード・サーバ２０４は、元のハンドセット・データ通信プロトコルを用いて、アップグレード・ファイルを要求元のハンドセットに送る。

ハンドセットからの確認の受信に応答して、アップグレード・サーバ２０４は、ユーザおよび／または要求元デバイスを認証および許可し、要求元デバイスの欠くことができない機能および制限を検証する。認証に続いて、アップグレード・サーバ２０４は、クライアント・デバイス・コンフィギュレーション・データのマネージャとして、要求元デバイス１０４の埋め込みソフトウェア・コンポーネントの現バージョンを特定し、該当するデルタ・ファイルを特定し要求元デバイス１０４に転送し、アップグレード・トランザクションのステータスを記録し、結果をアップグレード・マネージャ２０５に報告する。アップグレード・サーバ２０４の一実施形態は、自動故障復元機構を含む。加えて、アップグレード・サーバ２０４は、無線によってソフトウェア・アップグレード・サービスの活性化／不活性化を行い、遠隔ユーザにソフトウェアの変更を通知する。

図１を参照すると、アップグレード・クライアント１３０は、クライアント・デバイス１０４のデバイス・メモリ３００に埋め込まれているが、そのように限定される訳ではない。アップグレード・クライアント１３０は、ホスト・デバイス１０４のコンフィギュレーション・データを格納し維持し、ファイル更新アルゴリズム１１８を用いて、埋め込みデバイス・ソフトウェア・コンポーネントの維持および更新を担う。アップグレード・クライアント１３０は、単純なユーザ・インターフェースをサポートし、移動デバイスのソフトウェアに組み込まれる。実行時に、アップグレード・クライアント１３０は、自動的にあらゆる埋め込みソフトウェア・コンポーネントの起こりそうにない変化(remote change)を検出し、ユーザに埋め込みソフトウェア・コンポーネントのアップグレードを通知し、通信業者および／またはユーザの制御に基づいて、個々のサービス・プロバイダに対してしかるべくソフトウェア・コンポーネントをアップグレードする。また、アップグレード・クライアントは、自動障害復元機構も含む。

クライアント・デバイスは、更新手順に関与する前に、多数のデバイス・パラメータのステータスを判断する。これを行うのは、更新手順にデバイスが適格性があるか予め調べるため、またはクライアント・デバイスの状態が、更新手順を一旦開始したなら完了できるようになっていることを検証するためである。クライアント・デバイスの事前適格性検査は、クライアント・デバイスがクレードルまたは充電モードにあるか否か、クライアント・デバイスがシリアル・ケーブルに接続されているか否か、バッテリ充電の状態が更新プロセスを実行するのに十分か、受信信号強度指示（ＲＳＳＩ）または信号強度がデータ転送のために十分か、そして目標のＥＢＳＣが現在使用中かについての判断を含む。

一実施形態のアップグレード・システム２００は、デルタ・ファイルによって、種々の形式のソフトウェア・ファイルまたはコンポーネントの更新をサポートする。更新をサポートするファイル形式には、実行可能ファイル、バイト・ストリーム・ファイル、およびデータ・ファイルが含まれるが、このように限定されるのではない。実行可能ファイル、または画像ファイルは、クライアント・デバイス内において用いられて、タスク、例えば、オペレーティング・システム（ＯＳ）、ハードウェア・デバイス・ドライバ、およびＫ仮想機械（ＫＶＭ）ファイルを実行するソフトウェア・ファイルが含まれる。バイト・ストリーム・ファイルには、他の実行可能ファイルが用いるファイル、例えば、アイコン・ファイル、ロゴ・ファイル、およびＭＰ３ファイルが含まれる。データ・ファイルには、個人使用データを収容したファイル、ならびにハンドセット基準ファイル、例えば、較正コンフィギュレーション・ファイル、プロトコル独立マルチキャスト（ＰＩＭ）ファイル、およびシステム・コンフィギュレーション・ファイルが含まれる。

図３は、一実施形態の下における、デバイス・メモリ３００のブロック図である。一実施形態のデバイス・メモリ３００はフラッシュＲＯＭであるが、デバイス・メモリ３００の代替実施形態では、多くの形式のメモリおよび／またはメモリ形式の組み合わせを用いることもできる。デバイス・メモリ３００は、埋め込みソフトウェア・エリア３０２、アップグレード・クライアント・デバイス・パラメータのエリア３０６、およびデバイス・メモリ管理エリア３０８を含む。アップグレード・クライアント１３０は、ファイル更新アルゴリズム１１８と共に、一実施形態の埋め込みソフトウェア・エリア３０２に格納されている。デバイス・メモリ管理エリア３０８は、デバイス・メモリ管理（ＤＭＭ）ライブラリ３１０、ベクトル・テーブル３１２、およびガベージ・テーブル３１４を常駐させている。これらについては、以下で詳しく説明する。

データ・ファイル、または代わりに新ＥＢＳＣの受信時に、アップグレード・クライアント１３０は、埋め込みソフトウェア、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、およびＥＢＳＣグループを含むファイルの改訂および更新を制御する。アップグレード・クライアントは、更新するファイル形式、およびこれらの更新をサポートするためにクライアント・デバイスの製造業者によって割り当てられたリソースに応じて、ＥＢＳＣを更新する多数の方法を用いる。これらの更新方法には、上記の関連する出願に記載された以下のものが含まれるが、それらに限定される訳ではない。即ち、オペレーティング・システム（ＯＳ）、通信プロトコル、およびその他のクリティカル・ソフトウェア・コンポーネントの、予約したＲＡＭを用いての更新、予約ＲＯＭやＲＡＭがない場合の通信プロトコルの更新、および非クリティカルＥＢＳＣの単一線更新(single-line update)である。

一実施形態の更新方法は、非クリティカル・コンポーネントの更新およびクリティカル・コンポーネントの更新を含む。これらの分類は、更新の目標としたクライアント・デバイスのソフトウェア・コンポーネントの使用に基づいており、以下で更に説明する。

非クリティカル・コンポーネントは、更新プロセス中の障害に続いて無線で容易に復元される、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）を含む。非クリティカル・コンポーネントの例には、ブラウザおよびＫＶＭファイルが含まれるが、そのように限定される訳ではない。図４は、一実施形態の下における非クリティカル・コンポーネントの更新のフロー図４００である。デルタ・ファイルを用いて更新するとき、クライアント・デバイスは、ブロック４０２において、ネットワーク接続部を介してアップグレード・サーバからデルタ・ファイルを受信する。デルタ・ファイルは、クライアント・デバイスに受信されると、４０４において、デバイス・メモリ、例えば、ＲＡＭおよび／またはＲＯＭストレージの指定エリアに書き込まれる。次に、クライアント・デバイスのアップグレード・クライアントは、ブロック４０６において、デルタ・ファイルを用いて、元のファイルまたはＥＢＳＣから新ファイルまたはＥＢＳＣのコピーを生成する。ブロック４０８において、新ファイルのコピーは、予約したＲＡＭまたはＲＯＭに書き込まれる。ブロック４１０において、新ファイルのコピーを、予約メモリから、元のファイルまたはＥＢＳＣを収容するメモリ位置に順次書き込む。

クリティカル・コンポーネントは、更新手順で用いられるソフトウェア・コンポーネント、またはデバイスの動作に対して重要なＥＢＳＣを含む。更に、クリティカル・コンポーネントは、更新プロセス中の障害に続いて無線で容易に復元されないＥＢＳＣも含む。クリティカル・コンポーネントの例には、オペレーティング・システムのファイル、プロトコル・スタック、アップグレード・クライアント・ファイル、通信ライブラリ、およびディスプレイまたはＬＣＤドライバ・ファイルが含まれるが、そのように限定される訳ではない。更新手順は、これら２つの分類間で多少異なる。

図５は、一実施形態の下におけるクリティカル・コンポーネントの更新のフロー図５００である。デルタ・ファイルを用いて更新を行うとき、クライアント・デバイスは、ブロック５０２において、ネットワーク接続部を介してアップグレード・サーバからデルタ・ファイルを受信する。前述のように、デルタ・ファイルは、実行可能ファイル、バイト・ストリーム・ファイル、およびデータ・ファイルのファイルまたはＥＢＳＣアップグレードを含むことができる。一実施形態のワイヤレス・ネットワークは、セルラ・サービス・プロバイダのそれであるが、そのように限定される訳ではない。

デルタ・ファイルの受信時、一般に、更新の目標とされた元のファイルまたはＥＢＳＣを、ブロック５０４において、クライアント・デバイスのフラッシュＲＯＭから更新プロセス中の使用に指定されたメモリ・エリア、例えば、ＲＡＭおよび／またはＲＯＭストレージに適宜コピーする。クライアント・デバイスは、この指定したメモリ・エリアを、更新ソフトウェア・コンポーネントを格納する際に用いるために割り当てる。また、ブロック５０６において、デルタ・ファイルも、更新プロセス中の使用に指定されたメモリ・エリアに書き込まれる。

次に、ブロック５０８において、クライアント・デバイスのアップグレード・クライアントは、元のファイルの常駐ホストを、デルタ・ファイルと共に用いて、新ファイルのコピーを生成する。ブロック５１０において、新ファイルのコピーを、クライアント・デバイスの、予め指定したメモリ・エリア、例えば、クライアント・デバイスの予約メモリ内に書き込む。このプロセスを必要に応じて繰り返す。

生成に続いて、ブロック５１２において、新ファイルのコピーを、予約メモリから、元のファイルを収容している元のメモリ位置に書き込む。新ファイルのサイズが元のファイルのサイズ以下である場合、新ファイルを元のファイルのメモリ位置に書き込むことによって、元のファイルを置き換える。

前述のように、ファイルの改訂には、新ＥＢＳＣおよび更新したＥＢＳＣをホスト・デバイスのメモリ位置に書き込むことを伴う。多くの場合、新ＥＢＳＣは、正確に同じサイズではなく、それと置き換える元のＥＢＳＣと正確に同じ開始アドレスを有していない。一実施形態のアップグレード・クライアントは、デバイス・メモリ管理選択肢を与える。選択肢には、ＥＢＳＣサイズや開始アドレスには関係なく、新ＥＢＳＣの書き込みに対処するためのアップグレード可能なＥＢＳＣの静的アドレッシングおよび動的アドレッシングを含む。

アップグレード可能なＥＢＳＣの静的アドレッシングは、一般に、開始アドレスは不変のままにしつつ、予約メモリ・エリアを用いて、更新の間にＥＢＳＣまたはＥＢＳＣグループのサイズを変更することができる。したがって、ＥＢＳＣまたはＥＢＳＣグループの開始アドレスの変更を必要とする場合静的アドレッシングを用いる場合、埋め込みソフトウェア（ＥＥＢＳ）ファイル全体を書き換えるが、この実施形態はそのように限定される訳ではない。

アップグレード可能ＥＢＳＣの動的アドレッシングは、一層進んだメモリ管理を可能にしつつ、一般に各更新中ＥＢＳＣおよびＥＢＳＣグループの開始アドレスおよびサイズ双方の更新をサポートする。一実施形態のアップグレード・クライアントは、１組のアプリケーション・プログラムまたはプログラミング・インターフェース（ＡＰＩ）および少なくとも１つのデータ・テーブルの間での相互作用を用いて、動的アドレッシングをサポートする。つまり、動的アドレッシングは、メモリ利用およびデバイス・メモリ・マップの設計の効率を高めつつ、更新障害の確率を低くして、更新処理の高速化をサポートする。静的および動的アドレッシングについては、以下で更に詳しく説明する。

一実施形態の静的アドレッシングは、２つの選択肢があり、１つはアップグレード可能なＥＢＳＣ毎に予約メモリの割り当てを含み、もう１つはＥＢＳＣの特定のグループに対する予約メモリの割り当てを含む。予約メモリの割り当ては、ソフトウェア更新に対処するためのＥＢＳＣまたはＥＢＳＣグループ毎のメモリ割り当てを変更する。したがって、ソフトウェアの今後の成長に対処するために、追加のＲＯＭを予約するが、追加のメモリはＲＯＭに限られる訳ではない。

図６は、一実施形態の下におけるアップグレード可能ＥＢＳＣ毎に予約メモリの割り当てを用いた静的アドレッシングのフロー図６００である。動作において、アップグレード・クライアントは、ブロック６０２において、新ＥＢＳＣを受信する。新ＥＢＳＣは、ソフトウェア・コンポーネント分配部から受信することができ、あるいは元のＥＢＳＣおよびデルタ・ファイルからアップグレード・クライアントによって生成することもできる。ブロック６０４において、アップグレード・クライアントは、新ＥＢＳＣのサイズを決定する。ブロック６０６において、アップグレード・クライアントは、新ＥＢＳＣのサイズが、それと置き換えることになっている対応するＥＢＳＣのサイズを超過しているか否か判定を行う。新ＥＢＳＣのサイズが元のＥＢＳＣのサイズを超過しない場合、アップグレード・クライアントは、ブロック６０８において、元のＥＢＳＣを格納しているメモリ・ブロックを予約し、続いてこれに新ＥＢＳＣを書き込む。新ＥＢＳＣサイズが元のＥＢＳＣのサイズを超過する場合、アップグレード・クライアントは、ブロック６１０において、メモリ・ブロックおよび元のＥＢＳＣを格納している関連の予約メモリ・エリアに新ＥＢＳＣを最終的に書き込む。新ＥＢＳＣの書き込みに続いて、動作は、ブロック６１２における追加の新ＥＢＳＣの受信に戻る。

図７は、図６の実施形態の下において、静的アドレッシング・メモリ管理をサポートするように構成された、ホスト・デバイス・メモリ７０２のブロック図である。比較のために、静的アドレッシングをサポートするように構成されていないホスト・デバイス・メモリ７０４の部分が示されている。静的アドレッシングをサポートするメモリ７０２は、各々のアップグレード可能なＥＢＳＣに対し予約メモリ・エリアを含んでいる。この例では、アップグレード可能なＥＢＳＣを、デバイスの製造時点で特定する。次いで、各アップグレード可能なＥＢＳＣに対応する予約メモリ・エリアを設ける。予約メモリ・エリアは、対応するＥＢＳＣと同じ位置にあるように示されているが、これらはデバイス・メモリ内のどこに配置しても、または分散してもよい。予約メモリ量を最少に抑えるという観点からは、予約メモリ・エリアは非更新可能ＥＢＳＣには設けられないが、実施形態はそのように限定される訳ではない。

この例を続けると、更新可能ＥＢＳＣは、ＥＢＳＣ１、ＥＢＳＣ２、およびＥＢＳＣ５として特定され、予約メモリ・エリア１、２、および５がこれらの更新可能ＥＢＳＣ毎に設けられている。各予約メモリ・エリア１、２、および５は、デバイスの製造業者によって決定されたサイズである。今後の更新可能ＥＢＳＣに対するアップグレードおよび改訂では、更新／改訂によって、更新したＥＢＳＣのサイズが元のＥＢＳＣのサイズを超過した場合に、対応する更新メモリ・エリアを用いる。これは、前述の通りである。

図８は、一実施形態の下において、アップグレード可能なＥＢＳＣのグループへの予約メモリの割り当てを用いた、静的アドレッシングのフロー図８００である。この場合も、新ＥＢＳＣをソフトウェア・コンポーネント分配部から受信するか、あるいは元のＥＢＳＣおよびデルタ・ファイルからアップグレード・クライアントが生成してもよい。ブロック８０４において、アップグレード・クライアントは、新ＥＢＳＣのサイズを判定する。ブロック８０６において、アップグレード・クライアントは、新ＥＢＳＣのサイズが、それと置き換えることになる対応するＥＢＳＣのサイズを超過したか否か判定を行う。新ＥＢＳＣのサイズが元のＥＢＳＣのそれを超過していない場合、アップグレード・クライアントは、ブロック８０８において、対応する元のＥＢＳＣを含むＥＢＳＣグループを格納するメモリ・ブロックを予約し、これに新ＥＢＳＣを書き込む。新ＥＢＳＣのサイズが元のＥＢＳＣのそれを超過する場合、アップグレード・クライアントは、ブロック８１０において、メモリ・ブロック、および元のＥＢＳＣを格納する関連の予約メモリ・エリアを予約し、最終的に新ＥＢＳＣを書き込む。新ＥＢＳＣの書き込みに続いて、動作は、ブロック８１２において、追加の新ＥＢＳＣを受信するために戻る。

図９は、図８の実施形態の下において、静的アドレッシング・メモリ管理をサポートするように構成されたホスト・デバイス・メモリ９０２の一部のブロック図である。比較のために、静的アドレッシングをサポートするように構成されていないホスト・デバイス・メモリ９０４の部分が示されている。静的アドレッシングをサポートするホスト・メモリ９０２は、グレードアップ可能なＥＢＳＣの予め指定されたグループのために予約メモリ・エリアを含む。この代替案では、アップグレード可能なＥＢＳＣは、デバイスの製造時点で特定する。この例では、ＥＢＳＣ１、２、４、５、および８がアップグレード可能である。

デバイス製造業者は、多数のファクタのうちの少なくとも１つを使用してアップグレード可能なＥＢＳＣをグループ化する。例えば、類似のアップグレード頻度のＥＢＳＣが１つのグループを形成するようにできる。また、アップグレードまたは改訂を受ける類似の確率をもつＥＢＳＣが、１つのグループを形成するようにもできる。さらに、関係するあるいは相互に作用する機能をもつＥＢＳＣが１つのグループを形成するようにできる。以下のグループ分けは、本例のために行った。すなわち、ＥＢＳＣ１，４，５はＥＢＳＣグループ１を構成し、ＥＢＳＣ３，７はＥＢＳＣグループ２を構成し、ＥＢＳＣ６，９はＥＢＳＣグループ３を構成し、ＥＢＳＣ２，８はＥＢＳＣグループ４を構成する。

グループ化に続いて、デバイスの製造業者は、各アップグレード可能ＥＢＳＣグループに対応する予約メモリ・エリアを設ける。予約メモリ・エリアは、対応するＥＢＳＣグループと同じ位置にあるものとして示されているが、これらはデバイス・メモリ内のどこに位置してもよい。非アップグレード可能ＥＢＳＣの１つ以上のグループに置かれているが、予約メモリの量を極力抑える目的のために、予約エリアは設けられていない。しかし、実施形態はそのように限定される訳ではない。

この例では、アップグレード可能ＥＢＳＣグループは、ＥＢＳＣグループ１、およびＥＢＳＣグループ４として識別され、予約メモリ・エリアＧ１およびＧ４がこれらアップグレード可能ＥＢＳＣグループの各々に、それぞれ、設けられている。各予約メモリ・エリアＧ１およびＧ４は、デバイス製造業者が決定したサイズとなっている。アップグレード可能ＥＢＳＣグループの今後のアップグレードおよび改訂の際、アップグレード／改訂によってアップグレードされたＥＢＳＣグループのサイズが元のＥＢＳＣグループのサイズを超過した場合、対応する予約メモリを用いる。

前述のＥＢＳＣまたはＥＢＳＣグループの再書き込みの結果、再書き込みしたＥＢＳＣまたはＥＢＳＣグループを含むファイル内にあるサブルーチンの開始アドレスが変化する可能性がある。サブルーチンの開始アドレスが変化すると、常に、ホスト・デバイスの他のサブルーチンが再書き込みしたサブルーチンにアクセスする際に用いる、対応のコール・アドレスも変化する。したがって、一実施形態では、アップグレード・クライアントは、再書き込みしたあらゆるＥＢＳＣまたはＥＢＳＣグループに対応するコール・アドレスのアップグレードもサポートする。このコール・アドレスのアップグレードは、再書き込みしたＥＢＳＣまたはＥＢＳＣグループにおけるサブルーチンに対応するコール・アドレスを含む、ホスト・デバイス・メモリ内の任意のブロックの再書き込みを含む。これらのコール・アドレスの変化は通例数バイトを伴うに過ぎないので、コール・アドレスを含むブロックのみをアップグレードすることは、コール・アドレスを収容するＥＢＳＣを更新することよりも効率的であることがわかるが、実施形態はそのように限定される訳ではない。

図１０は、一実施形態の下において、静的アドレッシングをサポートするクライアント・デバイスＲＯＭマップ１０００のブロック図である。ＲＯＭは、以下のエリア、ブート・コード・エリア１００２、埋め込みソフトウェア・エリア１００４、ＥＢＳＣワーキング・メモリ・エリア１００６、アップグレード・クライアント・デバイス・パラメータ・エリア１００８、および指定されていない目的のための少なくとも１つの予約エリア１０１０を含むが、そのように限定される訳ではない。

ブート・コード・エリア１００２は、デバイス・ブーティング・シーケンス・コードを格納する。埋め込みソフトウェア・エリア１００４は、クライアント・デバイスの埋め込みソフトウェアを格納する。埋め込みソフトウェアは、例えば、ブラウザのソフトウェア、Ｋ仮想機械（ＫＶＭ）、通信ライブラリ、リアル・タイムＯＳ、グラフィック・ドライバ、およびアップグレード・クライアントを含むが、実施形態はそのように限定される訳ではない。前述のように、ソフトウェアの更新に対処するために、各アップグレード可能ＥＢＳＣまたはＥＢＳＣグループに対するメモリ割り当てを変更する。したがって、ソフトウェアの今後の成長に対処するために予約された追加のＲＯＭがある。この追加の予約ＲＯＭは、対応するＥＢＳＣまたはＥＢＳＣグループの初期バージョンのサイズの約５％から２０％であるが、そのように限定される訳ではない。

ＥＢＳＣワーキング・メモリ・エリア１００６は、アップグレード・クライアントがこれらを生成した後で、新バージョンが、現在元のバージョンのＥＢＳＣまたはＥＢＳＣグループが占有している埋め込みソフトウェア・エリア１００４のメモリ位置に書き込まれる前に、一時的に新バージョンのＥＢＳＣまたはＥＢＳＣグループを格納する。ワーク・エリア１００６の推定サイズは、このメモリ・エリアを用いる全てのＥＢＳＣまたはＥＢＳＣグループの内少なくとも最大のもののサイズであり、クリティカルおよび非クリティカル・コンポーネントを含む。

アップグレード・クライアント・デバイス・パラメータ・エリア１００８は、アップグレード・クライアントに特定のクライアント・デバイス・コンフィギュレーション・データおよびパラメータを格納する。このエリア１００８の推定サイズは、クライアント・デバイス上に常駐するデバイス・コンフィギュレーションに関連するアップグレード可能ＥＢＳＣの数に対応するが、そのように限定される訳ではない。

図１１は、一実施形態の下において、静的アドレッシングを用いた埋め込みソフトウェアの開発および展開(deployment)プロセス１１００のブロック図である。この図は、例えば、ソフトウェア・コンポーネント分配部１１０２によるＥＢＳＣの開発から、静的アドレッシングに基づくデバイス・メモリ管理を備えた一実施形態のアップグレード・クライアントを用いたデバイスＲＯＭの初期化までのプロセスを図示する。

ソフトウェア・コンポーネント分配部のコンポーネントは、新ＥＢＳＣのソース・コードを受信し（１１０２）、新ＥＢＳＣソース・コードをコンパイルする（１１０３）。コンパイル（１１０３）によって、得られたＥＢＳＣオブジェクト・コードを、リンク１１０６および１１１６に結合し、新ＥＢＳＣの登録の一部として、新ＥＢＳＣオブジェクト・コードから新たな１６進ファイル（テキスト）または二進ファイル１１１８を生成する。新たな１６進ファイルは、新ＥＢＳＣに対応する。

静的アドレッシングをサポートするにあたり、ソフトウェア・コンポーネント分配部またはサービス・プロバイダは、元のマップ・ファイルを変更し、アップグレード可能ＥＢＳＣ毎に追加のメモリを挿入する。一実施形態において、リンカ１１０６は、変更マップ・ファイル１１０４を生成する。ＥＢＳＣグループ化を用いる場合、元のマップ・ファイルを変更して、ＥＢＳＣをグループ化し、アップグレード可能ＥＢＳＣグループ毎に追加のメモリを挿入する。このマップ・ファイル１１０４の変更は、リンカ１１０６を用いてリンク・ファイルを編集し、空ファイルまたはグループを対応するオブジェクト・ファイルと共に挿入することを含む。

ベクトル生成ツール１１０５が、変更マップ・ファイル１１０４からベクトル・テーブル・ファイル１１０８を生成する。ベクトル・テーブル・ファイル１１０８は、クライアント・デバイス１１１２におけるアップグレード・クライアント・デバイス・パラメータ用予約ＲＯＭエリア１１１０にダウンロードされる。図１を参照すると、アップグレード・クライアント１３０は、ベクトル・テーブル１１０８を維持しており、これは、一般に、埋め込みソフトウェア（ＥＥＢＳ）全体を書き換えるのでなければ、不変のままでいる。また、リンカ１１１６も変更マップ・ファイル１１０４を用いて、新たな１６進または二進ファイル１１１８を生成する。更に、リンカ１１１６は、１６進ファイル／マップ・ファイル・パスの対の連携リストを指定または生成する。１６進ファイル１１１８は、クライアント・デバイス１１１２の埋め込みソフトウェア・エリア１１２０にダウンロードされるが、代替実施形態では、クライアント・デバイス・メモリの他のエリアにダウンロードしてもよい。

前述の静的アドレッシングは、ホスト・デバイスの処理時間を短縮し、クリティカル・ソフトウェア・コンポーネントの更新を可能にするが、全てのアップグレードおよび改訂に対処する訳ではない。加えて、静的アドレッシングを用いると、いずれのＥＢＳＣの再書き込みによって対応する予約メモリ・エリアのサイズを超過した場合には、デバイス・メモリ全体の書き換えが必要となる。したがって、動的アドレッシングを静的アドレッシングの代わりに用いる実施形態もある。

動的アドレッシングでは、新ファイル・バージョンのサイズが元のファイル・バージョンのそれを超過しても、電子ファイルの更新および改訂が可能である。動的アドレッシングをサポートする際、一実施形態のアップグレード・クライアントは、ファイル更新プロセス、および主プログラムが更新ＥＢＳＣを含む機能をコールする関数コール・プロセスの双方において、デバイス・メモリを効果的に管理する。

動的アドレッシングを用いてメモリ管理を実行する際、アップグレード・クライアントは、新たなソフトウェア・コンポーネントを収容できる程に十分大きなメモリ・ブロックを識別し予約する。その際、少なくとも１つの第１および第２メモリ・エリアを含むホスト・デバイスのメモリ・エリアの順次探索を行う。新たなコンポーネントのサイズが、探索したメモリ・エリアの使用可能なブロックのサイズを超過する場合、以下に述べるように、アップグレード・クライアントは第１メモリ・エリアを書き換えて、使用されていないメモリ・ブロックをなくし、第１および第２メモリ・エリアを再分配し、新たなコンポーネントを第２メモリ・エリアに書き込み、ベクトル・テーブルを更新する。

図１２は、一実施形態の下において動的アドレッシングを用いてＥＢＳＣまたはＥＢＳＣグループをアップグレードするためのフロー図１２００である。アップグレード・クライアントは、ブロック１２０２において、新ＥＢＳＣバージョンを受信する。新ＥＢＳＣバージョンは、元のＥＢＳＣバージョンおよび対応するデルタ・ファイルから生成するか、あるいはソフトウェア・コンポーネント分配部から受信する。ステップ１２０４において、クライアント・デバイス内で、新ＥＢＳＣバージョンの格納に対処するメモリ・エリアを特定し予約する。ブロック１２０６において、アップグレード・クライアントのコンポーネントは、新ＥＢＳＣバージョンを予約したメモリ・エリアに書き込む。ブロック１２０８において、ベクトル・テーブルに更新を行い、新ＥＢＳＣバージョンによって生じた、ベクトル・テーブルの情報に対するあらゆる必要な変更を行う。また、ブロック１２１０において、ガベージ・テーブルにも変更を行い、新ＥＢＳＣバージョンの書き込みによって生じた、未使用メモリ・エリアにおけるあらゆる変化を反映させる。

動的アドレッシングを用いてホスト・デバイスにおいてソフトウェア・コンポーネントにアクセスするために、アップグレード・クライアントは、対応するソフトウェア・ファイルの識別情報を含む関数コールを、ホスト・デバイスの主プログラムから受信し、ベクトル・テーブルから対応するソフトウェア・ファイルの開始アドレスを読み出し、対応するソフトウェア・ファイルにコールを生成する。こうして、第１ＥＢＳＣが第２ＥＢＳＣをコールすると、アップグレード・クライアントは関数コール・シーケンスを変更し、静的アドレスを用いて直接第２ＥＢＳＣをコールする代わりに、第１ＥＢＳＣが静的アドレスを用いて更新クライアントのＡＰＩをコールするようにする。コールされたＡＰＩは、対応する静的アドレスおよび実行時ベクトル・テーブルの引数を用いて、受け取ったコールを、第２ＥＢＳＣへのコールに変換する。

図１３は、一実施形態の下において、動的アドレッシングを用いた関数コールのフロー図１３００である。ホスト・デバイスの主プログラムは、ホスト・デバイス・メモリに格納されているＥＢＳＣを用いて、ユーザが要求する機能をサポートする。ユーザが機能を要求したとき、ホスト・デバイスの主プログラムのＥＢＳＣは、静的アドレスを用いてアップグレード・クライアントのコンポーネントを直接コールすることによって、特定の機能に伴うＥＢＳＣをコールする。コールに応答して、アップグレード・クライアントは、ブロック１３０２において、機能またはＥＢＳＣの識別と当該機能に対する引数とを含む情報を、主プログラムから受け取る。ブロック１３０４において、アップグレード・クライアントは、ＥＢＳＣの対応する開始アドレスと共に、主プログラムに得られるＥＢＳＣ毎のエントリを含むベクトル・テーブルにアクセスする。ブロック１３０６において、アップグレード・クライアントは、ベクトル・テーブルから、開始アドレスおよび付随する引数を読み出す。ブロック１３０８において、主プログラムから受け取った、コールしたＥＢＳＣの情報と共に開始アドレス情報を用いて、アップグレード・クライアントは実際の関数に対するコール、および対応するＥＢＳＣを、受け取った全引数と共に生成する。

図１４は、一実施形態の下において、動的アドレッシングをサポートするクライアント・デバイスＲＯＭマップ１４００のブロック図である。ＲＯＭは、以下のエリア、ブート・コード・エリア１４０２、埋め込みソフトウェア・エリア１４０４、ＥＢＳＣ更新エリア１４０６、アップグレード・クライアント・デバイス・パラメータ・エリア１４０８、デバイス・メモリ管理エリア１４１０、および未指定の目的のために予約してある少なくとも１つのエリア１４１２を含むが、そのように限定される訳ではない。これらのメモリ・エリアの各々について以下で説明するが、代替実施形態では、当業者には認められる多くの異なるエリア・コンフィギュレーションを用いることができる。

ブート・コード・エリア１４０２は、デバイス・ブーティング・シーケンス・コードを格納する。埋め込みソフトウェア・エリア１４０４は、クライアント・デバイスの埋め込みソフトウェアを格納する。埋め込みソフトウェアには、例えば、ブラウザのソフトウェア、ＫＶＭ、通信ライブラリ、リアル・タイムＯＳ、グラフィクス・ドライバ、およびアップグレード・クライアントが含まれるが、そのように限定される訳ではない。

ＥＢＳＣ更新エリア１４０６は、新バージョンの埋め込みソフトウェア・コンポーネントを格納する。このエリア１４０６の推定サイズは、デバイス間で変動する。しかしながら、一般に、ＥＢＳＣ更新エリア１４０６は、埋め込みソフトウェア・エリア１４０４のサイズの約１０％から２０％である。

アップグレード・クライアント・デバイス・パラメータ・エリア１４０８は、アップグレード・クライアントに特定のクライアント・デバイス・コンフィギュレーション・データおよびパラメータを格納する。アップグレード・クライアント・デバイス・パラメータ・エリア１４０８の推定サイズは、クライアント・デバイス上に常駐するデバイス・コンフィギュレーションに関係するアップグレード可能なＥＢＳＣの数に対応する。

デバイス・メモリ管理エリア１４１０は、メモリ・パラメータ、ベクトル・テーブル、およびガベージ・エントリ・テーブルを格納するが、そのように限定される訳ではない。このエリア１４１０の推定サイズは、クライアント・デバイス上に常駐するデバイス・メモリ管理に関係するアップグレード可能なＥＢＳＣの数に対応する。

デバイス・メモリ管理エリア１４１０のメモリ・パラメータは、デバイス・メモリ管理のＲＯＭ番号、開始アドレス、および予約ＲＯＭエリアのサイズ、ならびにデバイス・メモリ管理１４１０のために予約したＲＯＭエリアにおける開始アドレスおよび次に使用可能なメモリのサイズを含む。また、メモリ・パラメータは、ベクトル・テーブルおよびガベージ・エントリ・テーブルのサイズ、ならびにガベージ・エントリ・テーブルにおける有効エントリ数も含む。ベクトル・テーブルは、アップグレード可能ＥＢＳＣのＥＢＳＣ識別、ＲＯＭ番号、開始、アドレス、およびサイズを含む。ガベージ・エントリ・テーブルは、全てのガベージ・エントリのＲＯＭ番号、開始アドレス、およびサイズを含む。

図１５は、図３および図１４の実施形態の下における、アップグレード・クライアント１３０、埋め込みソフトウェア・エリア３０２、ＤＭＭライブラリ３１０、ベクトル・テーブル３１２、およびガベージ・テーブル３１４を含むメモリのコンポーネント間の相互作用の一例を示すメモリ・デバイス３００のブロック図である。ＤＭＭライブラリ３１０は、３つのＡＰＩ５０２〜１５０６を含む。これらのＡＰＩ１５０２〜１５０６は、デバイス・メモリの管理のために予約したＲＯＭエリア、ＥＢＳＣのために予約したメモリ、およびＥＢＳＣ更新のために予約したエリアを操作する際に用いられる。これらのＡＰＩは、関数アドレス変換用ＡＰＩ１５０２、ＥＢＳＣの新バージョンの予約のためのＡＰＩ１５０４、およびガベージ・コレクション用ＡＰＩ１５０６を含み、その各々について以下に説明する。

関数アドレス変換ＡＰＩ１５０２は、図１３を参照して先に説明したように、特定のホスト・デバイス機能に関連するＥＢＳＣに対するホスト・デバイスの主プログラム１５１０からのコールを発生する。ホスト・デバイスの主プログラム１５１０は、関数アドレス変換ＡＰＩ１５０２を直接コールすることによって、特定の機能に関連するＥＢＳＣをコールする。ＡＰＩ１５０２の直接コールは、ＥＢＳＣの直接コールの代わりに行われる。コールの時点において、関数アドレス変換ＡＰＩ１５０２は主プログラム１５１０から情報を受け取る。この情報は、機能識別情報、および機能に対する引数を含む。

コールに応答して、関数アドレス変換ＡＰＩ１５０２は、ベクトル・テーブル３１２にアクセスする。ベクトル・テーブル３１２は、主プログラム１５１０に使用可能な関数毎のエントリを、デバイス・メモリ３０２における当該関数の対応する開始アドレスと共に含む。関数アドレス変換ＡＰＩ１５０２は、主プログラム１５１０が要求する関数の開始アドレスをベクトル・テーブル３１２から読み取り、この開始アドレス情報を、主プログラム１５１０から受け取ったコール先ＥＢＳＣの情報と共に用いて、受け取った引数と共に実際の関数に対するコールを発生する。

一実施形態のアップグレード・クライアント１３０は、ここでは予約ＡＰＩ１５０４と呼ぶ、ＥＢＳＣ１５０４の新バージョンの予約のためにＡＰＩを用いて、新バージョンのＥＢＳＣまたはＥＢＳＣグループを収容するために、メモリ内のエリアを突き止めて予約する。図１５を参照すると、予約ＡＰＩ１５０４は、アップグレード・クライアント１３０によってコールされると、新ＥＢＳＣバージョンの識別情報、即ち、この新バージョンのファイル・サイズを含む情報を受け取る。新ＥＢＳＣバージョンのファイル・サイズは、新ＥＢＳＣバージョンを格納するためにデバイスＲＯＭ３０２内に予約するエリアのサイズである。予約ＡＰＩ１５０４は、メモリ３０２内の該当するエリアを突き止め、メモリ・エリアの予約に成功したときに、要求された予約エリアの開始アドレスを返す。図１６は、一実施形態の下において、予約ＡＰＩ１５０４を用いてＥＢＳＣの新バージョンを収容するためのメモリ・エリアを予約するためのフロー図１６００である。

要求されたサイズのメモリ・ブロックを割り当てる際、予約ＡＰＩ１５０４は、１組のルールを以下のように適用するが、代替実施形態では、異なるルールを適用して同等の結果を得ることもできる。図１７は、一実施形態の下において、予約ＡＰＩ１５０４のルールを用いてＥＢＳＣの新バージョンを収容するためのメモリ・ブロックを突き止めるためのフロー図１７００である。ブロック１７０２において、新ＥＢＳＣのサイズに関する情報を受けると、予約ＡＰＩ１５０４は、新ＥＢＳＣのサイズが元のＥＢＳＣのそれを超過するか否か、ブロック１７０４において判定を行う。新ＥＢＳＣのサイズが対応する元のＥＢＳＣのサイズ以下であれば、ブロック１７０６において、予約ＡＰＩ１５０４は、対応する元のＥＢＳＣが現在占有しているメモリ・ブロックを、新ＥＢＳＣを受けるために割り当てる。そうでなければ、予約ＡＰＩ１５０４は、要求されたサイズを有するメモリ・ブロックを、予約されているメモリ・エリア内にある使用可能なメモリから突き止めようとする。

探索を続ける際、予約ＡＰＩ１５０４は、ブロック１７０８において、クライアント・デバイスの予約されているメモリ・エリアを探索し、要求されたサイズを有するメモリ・ブロックを求める。適切なサイズのブロックが予約メモリ・エリア内で見つかった場合、ブロック１７１０において、予約ＡＰＩ１５０４はそのメモリ・ブロックを、新ＥＢＳＣを受け取るために割り当てる。予約メモリ・エリア内に適切なサイズのメモリ・ブロックが得られない場合、ブロック１７１２において、予約ＡＰＩ１５０４はガベージ・テーブル３１４にアクセスする。ブロック１７１４において、予約ＡＰＩ１５０４は、ガベージ・テーブル３１４内のエントリに対応する未使用エリア間で、要求されたサイズのメモリ・ブロックを突き止める試みの中で、ガベージ・テーブル３１４の情報を用いて、主メモリ・プログラムの未使用メモリ・エリアを探索する。一実施形態の未使用エリアを、ここではガベージ・エリアと呼び、主プログラムの未使用エリアを含むが、実施形態はそのように限定されている訳ではない。適切なサイズのメモリ・ブロックが未使用メモリ・エリア内で見つかった場合、ブロック１７１６において、予約ＡＰＩ１５０４はそのブロックを、新ＥＢＳＣを受け取るために割り当てる。

一実施形態の予約ＡＰＩ１５０４は、適切なサイズのメモリ・ブロックを突き止めることができない場合、ブロック１７１８において、ガベージ・コレクションとここでは呼ばれているプロセスを開始する。また、予約ＡＰＩ１５０４は、ガベージ・テーブル２１４のエントリ全てが塞がっているときにも、ガベージ・コレクションを開始する。一実施形態では、ガベージ・コレクション用ＡＰＩ１５０６、ここではガベージ・コレクション１５０６と呼び、予約ＡＰＩ１５０４によってコールされるが、そのように限定される訳ではない。ガベージ・コレクション用ＡＰＩは、一般に引数を受け取らず、ＥＢＳＣおよびＥＢＳＣ更新のために予約したエリアにおける全てのガベージを消去するが、そのように限定される訳ではない。

前述のように、予約ＡＰＩ１５０４は、要求された予約サイズに十分なメモリを見つけることができない場合、またはガベージ・エントリ・テーブルが満杯になったときに、ガベージ・コレクションを開始する。図１８は、一実施形態の下におけるガベージ・コレクションのフロー図１８００である。ガベージ・コレクションを開始する際、予約ＡＰＩ１５０４はガベージ・コレクションＡＰＩ１５０６をコールする。コールされると、ブロック１８０２において、ガベージ・コレクションＡＰＩ１５０６はガベージ・テーブル・エントリを読み取り、ブロック１８０４において、デバイス・メモリの埋め込みソフトウェア・エリアを書き直させ、メモリのＥＢＳＣを順次メモリの上に向かってパックしていく。代替実施形態では、ＥＢＳＣを主メモリの下に向かってパックしてもよいが、実施形態はそのように限定されている訳ではない。このパッキング処理により、埋め込みソフトウェア・エリアにおける未使用エリアを除去する。

このパッキング処理に続いて、ガベージ・コレクションＡＰＩ１５０６は、ブロック１８０６において、予約メモリ・エリアに格納されている各ＥＢＳＣのサイズを評価し、そのサイズを、その書き換え以後における埋め込みソフトウェア・エリアの主プログラムに残っているあらゆる未使用メモリ・ブロックと比較する。この評価は、埋め込みソフトウェア・エリアの書き換えの後に残っている未使用メモリの量が、予約メモリ・エリアのいずれのＥＢＳＣでも収容可能であり、可能であれば、ＥＢＳＣを予約メモリ・エリアから、デバイス・メモリの埋め込みソフトウェア・エリアに移動させることができるか否か判定を行う。予約メモリ・エリアのＥＢＳＣは順次評価されるが、実施形態はそのように限定される訳ではない。ブロック１８０８において、ＥＢＳＣは、予約メモリ・エリアからＥＢＳＣのサイズが許す埋め込みソフトウェア・エリアに書き直される。一実施形態において、ＥＢＳＣが書き直されると、これらは順次、パックされたＥＢＳＣに続いて埋め込みソフトウェア・エリアに格納される。

予約メモリ・エリアに格納されたＥＢＳＣの評価は、全てのＥＢＳＣを埋め込みソフトウェア・エリアに移動し終えるまで、または埋め込みソフトウェア・エリア内に、予約メモリ・エリアのＥＢＳＣを収容できる程大きな埋め込みソフトウェア・エリアが残っていないと判定されるまで継続する。埋め込みソフトウェア・エリア内に収容することができないＥＢＳＣはいずれも、予約メモリ・エリア内に残るが、実施形態はそのように限定される訳ではない。

パッキングおよび移動処理が完了すると、ブロック１８１０において、ガベージ・コレクションＡＰＩ１５０６は、ホスト・デバイスの主メモリの未使用メモリ・ブロックを予約メモリ・エリアとして指定し直すことにより、ホスト・デバイス・メモリを再分配する。更に、ステップ１８１２において、予約メモリ・エリア・ポインタをリセットして、予約メモリ・エリア内で使用可能なメモリの開始アドレスを維持する。加えて、ブロック１８１４において、ガベージ・テーブルを書き換え、未使用メモリ・エリアのステータスを反映させる。また、アップグレード・クライアント１３０は、同じＥＢＳＣの元のバージョンが占有するメモリ・エリア以外のいずれかのメモリ・エリアへのＥＢＳＣの新バージョンの書き込みの後に、ベクトル・テーブル３１２を更新する。

更新およびガベージ・コレクション処理の一例を、図１５、図１７、図１９、および図２０を参照しながら、以下に続ける。図１９は、一実施形態の下において、予約ＡＰＩのアップグレード処理の前１９０２および後１９０４におけるホスト・メモリ・デバイスの一例のブロック図である。図２０は、一実施形態の下において、アップグレードおよびガベージ・コレクション処理の後におけるホスト・デバイス・メモリ２００４のブロック図である。

この例は、予約ＡＰＩによるＥＢＳＣ８の新バージョンに関する情報の受信から始まる。新バージョンのＥＢＳＣ８のファイル・サイズを受け取ると、この新バージョンのサイズは元のＥＢＳＣのサイズ以下か否か判定を行う。この例では、ＥＢＳＣ８の元のバージョンは４００バイトを収容し、一方ＥＢＳＣ８の新バージョンは３８０バイトを収容する。したがって、予約ＡＰＩは、現在ＥＢＳＣ８の元のバージョンが占有しているエリア１９２０を、ＥＢＳＣ８の新バージョンを受け取るために割り当てる。

本例は、予約ＡＰＩによるＥＢＳＣ５の新バージョンについての情報の受信に続く。ＥＢＳＣ５の新バージョンのファイル・サイズを受け取ると、この新バージョンのサイズが元のＥＢＳＣのサイズ以下か否か判定を行う。この例では、ＥＢＳＣ５の元のバージョンは３００バイトを収容し、一方ＥＢＳＣ５の新バージョンは３６０バイトを収容する。新バージョンのサイズの方が元のバージョンのそれよりも大きいので、予約ＡＰＩは、予約メモリ・エリア１９１０内で使用可能なメモリから、要求された合図を有するメモリ・ブロックを突き止めようとする。この例では、予約メモリ・エリア１９１０においてメモリが使用可能であるので、予約ＡＰＩは、ＥＢＳＣ５の新バージョンを受け取るために、予約メモリ１９１０内のエリア１９２２を割り当てる。更に、予約ＡＰＩは、ＥＢＳＣ５の元のバージョンが現在占有しているエリアを、未使用エリア１９２４として割り当てる。

次に、予約ＡＰＩはＥＢＳＣ７の新バージョンに関する情報を受け取る。ＥＢＳＣ７の元のバージョンは５５０バイトを収容し、一方ＥＢＳＣ７の新バージョンは５６０バイトを収容する。新バージョンのサイズが元のバージョンのそれよりも大きいので、予約ＡＰＩは予約メモリ・エリア１９１０内の使用可能なメモリから、要求されたサイズを有するメモリ・ブロックを突き止めようとする。この例では、予約メモリ・エリア１９１０内でメモリが使用可能であるので、予約ＡＰＩは、ＥＢＳＣ７の新バージョンを受け取るために、予約メモリ１９１０内で次に使用可能なエリア１９２６を割り当てる。更に、予約ＡＰＩは、ＥＢＳＣ７の元のバージョンが現在占有しているエリアを、未使用エリア１９２８として割り当てる。

本例が継続すると、予約ＡＰＩがＥＢＳＣ２の新バージョンに関する情報を受け取る。ＥＢＳＣ２の元のバージョンは３３０バイトを収容し、ＥＢＳＣ２の新バージョンは３６０バイトを収容する。予約ＡＰＩは、予約メモリ・エリア１９１０内では適切なサイズのエリアが得られないと判断し、ガベージ・テーブル３１４にアクセスする。ガベージ・テーブル３１４は、ガベージ・テーブル３１４内のエントリを用いて識別されるガベージ・エリア間で、要求されたサイズのメモリ・ブロックを突き止める試みにおいて用いられる。この例では、該当するサイズの未使用エリア１９３０が特定され、予約ＡＰＩは、ＥＢＳＣ２の新バージョンを受け取るために、未使用エリア１９３０を割り当てる。

前述のように、予約ＡＰＩは、要求された予約サイズに十分なメモリを見つけることができない場合、またはガベージ・エントリ・テーブルが満杯のときに、ガベージ・コレクションを開始する。この例では、ＥＢＳＣ２の新バージョンのための予約メモリ・エリア内での割り当てに続いて受け取った次の新ＥＢＳＣバージョンで、ガベージ・コレクションが開始されたと仮定する。一実施形態のガベージ・コレクションは、ＥＢＳＣをホスト・デバイス・メモリにおいて上に向けてパックし、新たなホスト・デバイス・メモリ・コンフィギュレーション１９０４を得る。この中では、ＥＢＳＣの順序は、ＥＢＳＣ１、ＥＢＳＣ４、ＥＢＳＣ２、ＥＢＳＣ３、ＥＢＳＣ６、ＥＢＳＣ５、およびＥＢＳＣ７となる。代替実施形態のガベージ・コレクション・ルーチンは、ＥＢＳＣをホスト・デバイス・メモリにおいて下に向けてパックする。

図２１は、一実施形態の下において、動的アドレッシングを用いた埋め込みソフトウェアの開発および展開プロセスのブロック図２１００である。この図は、ソフトウェア・コンポーネント分配部２１０２によるＥＢＳＣの開発から、動的アドレッシングに基づくデバイス・メモリ管理を行う一実施形態のアップグレード・クライアントを用いたデバイスＲＯＭの初期化までのプロセスを示す。

ソフトウェア・コンポーネント分配部２１０２のコンポーネントは、新ＥＢＳＣのソース・コードを受信し、新ＥＢＳＣソース・コードをコンパイルする（２１０３）。コンパイル（２１０３）によって、得られたＥＢＳＣオブジェクト・コードをリンカ２１０６および２１１６と結合し、新ＥＢＳＣの登録の一部として、新ＥＢＳＣオブジェクト・コードから新たな１６進ファイル（テキスト）または二進ファイル２１１８を生成する。新たな１６進ファイルは、新ＥＢＳＣに対応する。

動的アドレッシングをサポートするに当たり、ソフトウェア・コンポーネント分配部２１０２は、コンパイラ２１０３およびリンカ２１０６を用いて、マップ・ファイル２１０４を生成する。このマップ・ファイル２１０４は、ベクトル生成ツール２１０５が、ＥＢＳＣの対応する初期ベクトル・テーブル２１０８を生成するために用いる。次いで、ベクトル・テーブル２１０８は、リンカ２１１６に供給され、リンカ２１１６は、初期ベクトル・テーブル２１０８を用いて、１６進（テキスト）または二進ファイル２１１８を生成する。１６進（テキスト）または二進ファイル２１１８は、クライアント・デバイス２１１２の埋め込みソフトウェア・エリア２１２０にダウンロードされるが、代替実施形態では、１６進ファイル２１１８をクライアント・デバイス２１１２の他のメモリ・エリアに書き込んでもよい。アップグレード・クライアントのＤＭＭライブラリのコンポーネントは、ベクトル・テーブル２２０８を維持し、こうして、ＥＢＳＣの動的アドレッシングをサポートする。ＤＭＭライブラリは、アップグレード・クライアントのデバイス・パラメータ２１１０のために予約したエリアに格納されているベクトル・テーブル２１０８と重複する。

前述の電子ファイル更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、電子ファイルの更新システムを含み、このシステムは、デルタ・ファイルを生成する、ファイル差別化および更新システムの第１コンポーネントを含む第１デバイスと、第１デバイスから第１デルタ・ファイルを少なくとも１つの結合部を介して受け取る第２デバイスであって、ファイル差別化および更新システムの第２コンポーネントを含む第２デバイスとを備えている。

第２デバイスは、ファイル差別化および更新システムの第２コンポーネントを含み、元の電子ファイルの更新バージョンである新電子ファイルの少なくとも１つの新たなコンポーネントをデルタ・ファイルから読み出し、第１および第２メモリ・エリアの順次探索を行うことにより、新コンポーネントを収容するのに十分大きいメモリ・ブロックを識別し、予約し、未使用メモリ・ブロックを排除するために第１メモリ・エリアを書き換え、新コンポーネントのサイズが第１および第２メモリ・エリアの使用可能なメモリ・ブロックのサイズを超過するとき、第１および第２メモリ・エリアを再分配し、新コンポーネントを予約したメモリ・ブロックに書き込み、新コンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込んだときに、ベクトル・テーブルを更新することによって第２デバイスの電子ファイルを更新するように構成されている。

また、第２デバイスは、ファイル差別化および更新システムの第２コンポーネントも含み、デバイスの主プログラムからの、対応する電子ファイルの識別情報を含む関数コールを受け、ベクトル・テーブルから対応する電子ファイルの開始アドレスを読み取り、開始アドレスおよび識別情報を用いて、対応する電子ファイルに対するコールを生成することによってデバイスの電子ファイルにアクセスするように構成されている。

一実施形態のシステムの第２デバイスは、更に、電子ファイルを更新する際に用いるための第１および第２アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含む。

一実施形態のシステムの第２デバイスは、更に、電子ファイルにアクセスする際に用いるための第３アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含む。
一実施形態のシステムの第１デバイスは、第２デバイス上に常駐するソフトウェアの少なくとも１つのプロバイダによってアクセス可能な、プロセッサに基づくデバイスを含む。

一実施形態のシステムの第２デバイスは、パーソナル・コンピュータ、携帯用計算機、セルラ電話機、携帯用通信デバイス、およびパーソナル・ディジタル・アシスタントの中から選択した、少なくとも１つのプロセッサに基づくデバイスを含む。

一実施形態のシステムの結合部は、ワイヤレス結合部、ワイヤード結合部、混合ワイヤレス／ワイヤード結合部、およびローカル・エリア・ネットワーク（ＬＡＮ）、都市区域ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有のネットワーク、バックエンド・ネットワーク、インターネットを含む少なくとも１つのネットワークとの結合部、ならびにフロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクを含む着脱可能固定媒体、更に電話回線、バス、および電子メール・メッセージの内少なくとも１つである。

一実施形態の元のファイルおよび新ファイルは、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人的使用データを含むファイルを含むソフトウェア・ファイルを含む。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、ホスト・デバイスにおけるデバイス・メモリ管理方法を含み、この方法は、新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信するステップであって、新電子ファイルが元の電子ファイルの更新バージョンであり、識別情報が受信したコンポーネントのサイズを含む、ステップと、第１および第２メモリ・エリアの順次探索を行うことによって、受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約するステップであって、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、サイズが第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、第１および第２メモリ・エリアを再分配する、ステップと、予約したメモリ・ブロックのアドレスを与えるステップと、受信したコンポーネントを予約メモリ・ブロックに書き込むことによって、元の電子ファイルを更新するステップとを含む。

ホスト・デバイスにおけるデバイス・メモリ管理方法は、更に、受信したコンポーネントを、元の電子ファイルの対応するコンポーネントを含む第１メモリ・エリア内の元のメモリ・ブロック以外のメモリ・ブロックに書き込む場合、第１テーブルを更新するステップを含み、第１テーブルは、ホスト・デバイスの電子ファイルのコンポーネントのコンポーネント情報を含み、このコンポーネント情報は、コンポーネント識別、リード・オンリ・メモリ（ＲＯＭ）番号、開始アドレス、およびサイズを含む。

一実施形態の方法では、識別および予約するステップは、元の電子ファイルの対応するコンポーネントのサイズよりもサイズが小さい場合、第１メモリ・エリアの元のメモリ・ブロックを予約することを含み、元のメモリ・ブロックは、元の電子ファイルの対応するコンポーネントを含む。

一実施形態の方法では、識別および予約するステップは、サイズが元の電子ファイルの対応するコンポーネントのサイズを超過する場合、第２メモリ・エリアと第１メモリ・エリアの未使用部分との少なくとも一方を探索して、受信したコンポーネントを格納できる十分大きなメモリ・ブロックを求めることを含む。

一実施形態の方法では、第１メモリ・エリアの書き換えおよび第２メモリ・エリアの再分配のステップは、更に、第１エリアの未使用メモリ・ブロックに対応する少なくとも１つのエントリを含む第２テーブルを読み取り、第１メモリ・エリアのコンポーネントを順次パックし、未使用メモリ・ブロックを統合するために、第１メモリ・エリアのコンポーネントを書き換え、第２メモリ・エリアの各コンポーネントのサイズを順次評価し、第２メモリ・エリアのコンポーネントを、第２メモリ・エリアのコンポーネントのサイズおよび統合した未使用メモリ・ブロックのサイズが許す、第１メモリ・エリアに再書き込みし、順次評価および再書き込みに続いて、統合した未使用メモリ・ブロックの残りのブロックを識別し、統合した未使用メモリ・ブロックの残りのブロックを、第２メモリ・エリアの一部として指定することによって、第２メモリ・エリアを再分配し、再分配した第２メモリ・エリアの使用可能なメモリの開始アドレスを維持するために、第２メモリ・エリアのポインタを設定することを含む。

一実施形態の方法では、第２テーブルのエントリは、リード・オンリ・メモリ（ＲＯＭ）番号、開始アドレス、およびサイズを含む未使用メモリ・ブロックの情報を含む。
前述のホスト・デバイスにおけるデバイス・メモリ管理方法は、更に、ホスト・デバイスの主プログラムからの関数コールを受け、この関数コールが対応する電子ファイルの識別情報を含み、対応する電子ファイルの開始アドレスをベクトル・テーブルから読み出し、開始アドレスおよび識別情報を用いて、対応する電子ファイルに対するコールを発生することによって、ホスト・デバイスの電子ファイルによって与えられる機能にアクセスするステップを含む。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、ファイル更新中におけるデバイス・メモリ管理方法を含み、この方法は、受信コンポーネントの識別情報を用いて、新たな電子ファイルの少なくとも１つの受信コンポーネントのサイズを判定するステップであって、新たな電子ファイルが、元の電子ファイルの更新バージョンである、ステップと、サイズが元の電子ファイルの対応するコンポーネントのサイズ以下である場合、受信コンポーネントを書き込む第１メモリ・エリアの元のメモリ・ブロックを割り当て、元のメモリ・ブロックが元の電子ファイルの対応するコンポーネントを含む、ステップと、サイズが元の電子ファイルの対応するコンポーネントのサイズを超過する場合、第２メモリ・エリアと第１メモリ・エリアの未使用部分とを探索して、受信コンポーネントを格納できる十分に大きなメモリ・ブロックを求めるステップと、サイズが第１および第２メモリ・エリアの使用可能なメモリ・ブロックのサイズを超過する場合、未使用部分を除去するように第１メモリ・エリアを書き換え、第１および第２メモリ・エリアを再分配し、受信コンポーネントを書き込む、第２メモリ・エリアのメモリ・ブロックを割り当てるステップとを含む。

一実施形態の方法では、第１メモリ・エリアの書き換えは、更に、第１メモリ・エリアの未使用部分に対応する少なくとも１つのエントリを含むテーブルを読み込み、第１メモリ・エリアのコンポーネントを順次パックし、未使用メモリ・ブロックを統合するために、第１メモリ・エリアのコンポーネントを書き直すことを含む。

一実施形態の方法では、第１および第２メモリ・エリアを再分配するステップは、更に、第２メモリ・エリアの各コンポーネントのサイズを順次評価し、第２メモリ・エリアのコンポーネントのサイズおよび書き換えた第２メモリ・エリアの統合した未使用メモリ・ブロックのサイズが許すとき、第２メモリ・エリアのコンポーネントを書き換えた第１メモリ・エリアに書き込み、順次評価および書き込みに続いて、統合した未使用メモリ・ブロックの残りのブロックを特定し、統合した未使用メモリ・ブロックの残りのブロックを第２メモリ・エリアの一部として指定することにより、第１および第２メモリ・エリアを再分配し、再分配した第２メモリ・エリアの使用可能なメモリの開始アドレスを維持するために、第２メモリ・エリアのポインタを設定し、テーブルを評価することを含む。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、電子デバイスのメモリを管理する方法を含み、この方法は、元の電子ファイルの更新バージョンであある新電子ファイルの少なくとも１つの新コンポーネントを受信し、第１および第２メモリ・エリアの順次探索を行うことによって、受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、サイズが第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、第１および第２メモリ・エリアを再分配し、新コンポーネントを予約したメモリ・ブロックに書き込み、新コンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込んだときに、ベクトル・テーブルを更新することによって、デバイスの電子ファイルを更新するステップを含む。

前述の電子デバイスのメモリ管理方法は、更に、デバイスの主プログラムからの関数コールを受け、関数コールは対応する電子ファイルの識別情報を含み、ベクトル・テーブルから対応する電子ファイルの開始アドレスを読み取り、開始アドレスおよび識別情報を用いて、対応する電子ファイルに対するコールを生成することによって、デバイスの電子ファイルにアクセスするステップを備えている。

一実施形態の方法では、識別情報は、関数識別、および関数に対する引数を含む。
前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、新電子ファイルの少なくとも１つの新コンポーネントを受信する手段であって、新電子ファイルは、元の電子ファイルの更新バージョンである、手段と、第１および第２メモリ・エリアの順次探索を行うことによって、受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約する手段であって、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、サイズが第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、第１および第２メモリ・エリアを再分配する、手段と、新コンポーネントを予約したメモリ・ブロックに書き込むことによって、元の電子ファイルを更新する手段と、新コンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込む場合、ベクトル・テーブルを更新する手段とを備えている装置を含む。

一実施形態の装置は、パーソナル・コンピュータ、携帯用計算機、セルラ電話機、携帯用通信デバイス、およびパーソナル・ディジタル・アシスタントの中から選択した、少なくとも１つのプロセッサに基づくデバイスを含む、装置。

一実施形態の装置は、第１アプリケーション・プログラミング・インターフェース（ＡＰＩ）を、メモリ・ブロックを識別し予約する手段として含む。
一実施形態の装置は、更に、デバイスの主プログラムから関数コールを受け取る手段であって、関数コールは、対応する電子ファイルの識別情報を含む、手段と、ベクトル・テーブルから対応する電子ファイルの開始アドレスを読み取る手段と、開始アドレスおよび識別情報を用いて、対応する電子ファイルに対するコールを発生する手段とを備えている。

一実施形態の装置は、第２アプリケーション・プログラミング・インターフェース（ＡＰＩ）を、関数コールを受け取る手段として含む。
前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、実行可能な命令を含むコンピュータ読み取り可能媒体を含み、処理システムにおいて実行すると、新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信し、新電子ファイルは、元の電子ファイルの更新バージョンであり、識別情報は受信したコンポーネントのサイズを含み、第１および第２メモリ・エリアの順次探索を行うことによって、受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、サイズが第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、第１および第２メモリ・エリアを再分配し、予約したメモリ・ブロックのアドレスを与え、受信したコンポーネントを予約メモリ・ブロックに書き込むことによって、元の電子ファイルを更新することによって電子ファイルおよびファイル・コンポーネントを更新する。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、実行可能な命令を含む電磁媒体を含み、処理システムにおいて実行すると、新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信し、新電子ファイルは元の電子ファイルの更新バージョンであり、識別情報は受信したコンポーネントのサイズを含み、第１および第２メモリ・エリアの順次探索を行うことによって、受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように第１メモリ・エリアを書き換え、サイズが第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、第１および第２メモリ・エリアを再分配し、予約したメモリ・ブロックのアドレスを与え、受信したコンポーネントを予約メモリ・ブロックに書き込むことによって、元の電子ファイルを更新する、ことによって電子ファイルおよびファイル・コンポーネントを更新する。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、電子ファイルの更新システムを含み、このシステムは、デルタ・ファイルを生成する、ファイル差別化および更新システムの第１コンポーネントを含む第１デバイスと、第１デバイスから第１デルタ・ファイルを少なくとも１つの結合部を介して受け取る第２デバイスとを備えている。一実施形態の第２デバイスは、デルタ・ファイルを通じて新電子ファイルの少なくとも１つのコンポーネントを受信し、新電子ファイルは、元の電子ファイルの更新バージョンであり、受信したコンポーネントのサイズを判定し、サイズが元の電子ファイルの対応するコンポーネントのサイズ以下である場合、受信したコンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込み、サイズが元の電子ファイルの対応するコンポーネントのサイズを超過する場合、受信したコンポーネントを、元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込むことにより第２デバイスの電子ファイルを更新するように構成されているファイル差別化および更新システムの第２コンポーネントを含む。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、電子ファイルの更新方法を含み、この方法は、新電子ファイルの少なくとも１つのコンポーネントを受信するステップであって、新電子ファイルは、元の電子ファイルの更新バージョンである、ステップと、受信したコンポーネントのサイズを判定するステップと、サイズが元の電子ファイルの対応するコンポーネントのサイズ以下である場合、受信したコンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込むステップと、サイズが元の電子ファイルの対応するコンポーネントのサイズを超過する場合、受信したコンポーネントを、元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込むステップとを含む。一実施形態の方法では、少なくとも１つの成分は、コンポーネントのグループを含む。

前述の電子ファイルの更新中におけるデバイス・メモリ管理のためのシステムおよび関連する方法は、新電子ファイルの少なくとも１つのコンポーネントを受信する手段であって、新電子ファイルは、元の電子ファイルの更新バージョンである、手段と、受信したコンポーネントのサイズを判定する手段と、サイズが元の電子ファイルの対応するコンポーネントのサイズ以下である場合、受信したコンポーネントを、元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込む手段と、サイズが元の電子ファイルの対応するコンポーネントのサイズを超過する場合、受信したコンポーネントを、元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込む手段とを備えている装置を含む。

本発明の態様は、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、プログラマブル・アレイ・ロジック（ＰＡＬ）デバイス、電気的プログラム可能ロジックおよびメモリ・デバイスのようなプログラマブル・ロジック・デバイス（ＰＤＬ）、標準的なセルに基づくデバイス、ならびに特定用途集積回路（ＡＳＩＣ）を含む種々の回路のいずれにもプログラムされる機能として実現することができる。更に、本発明の態様は、ソフトウェアに基づく回路エミュレーション、ディスクリート・ロジック（連続および組み合わせ）、カスタム・デバイス、ファジイ（ニューラル）デバイス、量子デバイス、および上述のデバイスの種類のいずれのハイブリッドを有するマイクロプロセッサにおいても具体化することができる。勿論、基盤となるデバイス技術は、種々のコンポーネントの種類、例えば、相補金属酸化物半導体（ＣＭＯＳ）のような金属酸化物半導体電界効果トランジスタ（ＭＯＳＦＥＴ）技術、エミッタ結合ロジック（ＥＣＬ）のようなバイポーラ技術、ポリマ技術（例えば、シリコン共役ポリマおよび金属共役ポリマ−金属構造）、混合アナログおよびディジタルなどにおいて提供することができる。

文脈上特に必要であることが明らかでない限り、明細書および特許請求の範囲を通じて、「備える」、「備えている」等の言葉は、排他的または網羅的意味ではなく、包含的意味で解釈するものとする。即ち、「含むが、限定されない」という意味である。単数または複数を用いる単語も、それぞれ、複数および単数を含むものとする。加えて、「ここでは」、「以下で」という単語、および同様な意義の単語は、本願において用いられる場合、本願全体を指すのであり、本願のいずれの特定部分を指すのではないとする。

本発明の例示した実施例についてのこれまでの説明は、それで全てであることも、開示した正確な形態に本発明を限定することも意図していない。本発明の具体的な実施形態および例を例示の目的のためにここで記載したが、種々の等価な変更も本発明の範囲内で可能であることは、当業者は認めよう。ここに提示した本発明の教示は、他の処理システムや通信システムにも適用することができ、前述のＦファイル更新のみに適用できるのではない。

前述した種々の実施形態のエレメントおよび作用を組み合わせれば、更に別の実施形態も得ることができる。これらおよびその他の変更は、前述の詳細な説明に鑑みれば、容易に行うことができる。

先の引例は全て、ここで引用したことにより、本願にも含まれるものとする。必要であれば、本発明の態様を変更して前述の種々の特許および出願のシステム、機能および概念を採用すれば、本発明の更に別の実施形態を得ることができる。

一般に、特許請求の範囲においては、用いられる用語は、明細書に開示される具体的な実施形態および特許請求の範囲に本発明を限定するように解釈するのではなく、特許請求の範囲の下で動作してファイル差別化および更新方法を実施するあらゆる処理システムを含むように解釈するのが当然である。したがって、本発明は、本開示に限定されるのではなく、むしろ発明の範囲は特許請求の範囲によって全体的に決定されるものとする。

本発明のある種の態様をある請求項の形式で提示するが、本願の発明者は、本発明の種々の態様をいかなる数の請求項形式でも想定している。例えば、本発明の一態様のみを、コンピュータ読み取り可能媒体に具体化するものとして明記するが、他の態様も同様にコンピュータ読み取り可能媒体に具体化することができる。したがって、本発明は、本願を出願した後でも、更に別の請求項を追加し、本発明の別の態様に対する、このような更に別の請求項を追求する権利を保有するものとする。

図１は、一実施形態の下における、バイト・レベルのファイル差別化および更新（ＦＤＵ）アルゴリズムを用いて、電子ファイルを更新するシステムのブロック図である。 図２は、一実施形態の下における、ソフトウェア更新システムのブロック図である。 図３は、一実施形態の下における、デバイス・メモリのブロック図である。 図４は、一実施形態の下における、非クリティカル・コンポーネント更新のフロー図である。 図５は、一実施形態の下におけるクリティカル・コンポーネントの更新のフロー図である。 図６は、一実施形態の下において、更新可能なＥＢＳＣ毎に予約メモリ割り当てを用いた静的アドレッシングのフロー図である。 図７は、図６の実施形態の下において、静的アドレッシング・メモリ管理をサポートするように構成したホスト・デバイス・メモリの一部のブロック図である。 図８は、一実施形態の下において、更新可能なＥＢＳＣのグループ単位での予約メモリ割り当てを用いた静的アドレッシングのフロー図である。 図９は、図８の実施形態の下において、静的アドレッシング・メモリ管理をサポートするように構成したホスト・デバイス・メモリの一部のブロック図である。 図１０は、一実施形態の下において、静的アドレッシングをサポートするクライアント・デバイスＲＯＭマップのブロック図である。 図１１は、一実施形態の下において、静的アドレッシングを用いた埋め込みソフトウェアの開発および展開プロセスのブロック図である。 図１２は、一実施形態の下において、動的アドレッシングを用いてＥＢＳＣまたはＥＢＳＣグループを更新するためのフロー図である。 図１３は、一実施形態の下において、動的アドレッシングを用いた関数コールのフロー図である。 図１４は、一実施形態の下において、動的アドレッシングをサポートするクライアント・デバイスのＲＯＭメモリ・マップのブロック図である。 図１５は、図３および図１４の実施形態の下において、アップグレード・クライアント、埋め込みソフトウェア・エリア、ＤＭＭライブラリ、ベクトル・テーブル、およびガベージ・テーブルを含むメモリのコンポーネント間の相互作用の一例を示すホスト・デバイス・メモリのブロック図である。 図１６は、一実施形態の下において、予約ＡＰＩを用いてＥＢＳＣの新バージョンを収容するためにメモリ・エリアを予約するためのフロー図である。 図１７は、一実施形態の下において、予約ＡＰＩのルールを用いて、ＥＢＳＣの新バージョンを収容するためにメモリ・エリアを突き止めるためのフロー図である。 図１８は、一実施形態の下における、埋め込みソフトウェア・エリア（ガベージ・コレクション）の未使用エリアの収集のためのソフトウェアである。 図１９は、一実施形態の下における、予約ＡＰＩの更新処理の前後でのホスト・デバイス・メモリの一例のブロック図である。 図２０は、一実施形態の下において、アップグレードおよびガベージ・コレクション処理の後におけるホスト・デバイスのブロック図である。 図２１は、一実施形態の下において、動的アドレッシングを用いた埋め込みソフトウェアの開発および展開プロセスのブロック図である。

Claims (30)

1. 電子ファイルの更新システムであって、
   デルタ・ファイルを生成する、ファイル差別化および更新システムの第１コンポーネントを含む第１デバイスと、
   前記第１デバイスから前記第１デルタ・ファイルを少なくとも１つの結合部を介して受け取る第２デバイスであって、前記ファイル差別化および更新システムの第２コンポーネントを含む第２デバイスと、
   を備えており、前記システムは、
   前記デルタ・ファイルから新電子ファイルの少なくとも１つの新コンポーネントを読み出し、前記新電子ファイルが、元の電子ファイルの更新バージョンであり、
   第１および第２メモリ・エリアの順次探索を行うことにより、前記新コンポーネントを収容するのに十分大きいメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するために前記第１メモリ・エリアを書き換え、前記新コンポーネントのサイズが前記第１および第２メモリ・エリアの使用可能なメモリ・ブロックのサイズを超過するとき、前記第１および第２メモリ・エリアを再分配し、
   前記新コンポーネントを予約したメモリ・ブロックに書き込み、
   前記新コンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込んだときに、ベクトル・テーブルを更新する、
   ことによって前記第２デバイスの電子ファイルを更新するように構成されており、
   更に、前記システムは、
   前記デバイスの主プログラムからの関数コールを受け、前記関数コールは対応する電子ファイルの識別情報を含み、
   前記ベクトル・テーブルから前記対応する電子ファイルの開始アドレスを読み取り、
   前記開始アドレスおよび前記識別情報を用いて、前記対応する電子ファイルに対するコールを生成することによって、
   前記デバイスの電子ファイルにアクセスするように構成されている、システム。
2. 請求項１記載のシステムにおいて、前記第２デバイスは、更に、電子ファイルを更新する際に用いるための第１および第２アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含む、システム。
3. 請求項１記載のシステムにおいて、前記第２デバイスは、更に、電子ファイルにアクセスする際に用いるための第３アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含む、システム。
4. 請求項１記載のシステムにおいて、前記第１デバイスは、前記第２デバイス上に常駐するソフトウェアの少なくとも１つのプロバイダによってアクセス可能な、プロセッサに基づくデバイスを含む、システム。
5. 請求項１記載のシステムにおいて、前記第２デバイスは、パーソナル・コンピュータ、携帯用計算機、セルラ電話機、携帯用通信デバイス、およびパーソナル・ディジタル・アシスタントの中から選択した、少なくとも１つのプロセッサに基づくデバイスを含む、システム。
6. 請求項１記載のシステムにおいて、前記少なくとも１つの結合部は、ワイヤレス結合部、ワイヤード結合部、混合ワイヤレス／ワイヤード結合部、およびローカル・エリア・ネットワーク（ＬＡＮ）、都市区域ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業固有のネットワーク、バックエンド・ネットワーク、インターネットを含む少なくとも１つのネットワークとの結合部、ならびにフロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクを含む着脱可能固定媒体、更に電話回線、バス、および電子メール・メッセージの中から選択する、システム。
7. 請求項１記載のシステムにおいて、前記元のファイルおよび新ファイルは、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人的使用データを含むファイルを含むソフトウェア・ファイルを含む、システム。
8. ホスト・デバイスにおけるデバイス・メモリ管理方法であって、
   新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信するステップであって、前記新電子ファイルは、元の電子ファイルの更新バージョンであり、前記識別情報は前記受信したコンポーネントのサイズを含む、ステップと、
   第１および第２メモリ・エリアの順次探索を行うことによって、前記受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約するステップであって、未使用メモリ・ブロックを排除するように前記第１メモリ・エリアを書き換え、前記サイズが前記第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、前記第１および第２メモリ・エリアを再分配する、ステップと、
   前記予約したメモリ・ブロックのアドレスを与えるステップと、
   前記受信したコンポーネントを前記予約メモリ・ブロックに書き込むことによって、前記元の電子ファイルを更新するステップと、
   を備えた方法。
9. 請求項８記載の方法であって、前記受信したコンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む前記第１メモリ・エリア内の元のメモリ・ブロック以外のメモリ・ブロックに書き込む場合、第１テーブルを更新するステップを含み、前記第１テーブルは、前記ホスト・デバイスの電子ファイルのコンポーネントのコンポーネント情報を含み、該コンポーネント情報は、コンポーネント識別、リード・オンリ・メモリ（ＲＯＭ）番号、開始アドレス、およびサイズを含む、方法。
10. 請求項８記載の方法において、識別および予約するステップは、前記元の電子ファイルの対応するコンポーネントのサイズよりも前記サイズが小さい場合、前記第１メモリ・エリアの元のメモリ・ブロックを予約することを含み、前記元のメモリ・ブロックは、前記元の電子ファイルの対応するコンポーネントを含む、方法。
11. 請求項１０記載の方法において、識別および予約するステップは、前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズを超過する場合、前記第２メモリ・エリアと前記第１メモリ・エリアの未使用部分との少なくとも一方を探索して、前記受信したコンポーネントを格納できる十分大きなメモリ・ブロックを求めることを含む、方法。
12. 請求項８記載の方法において、前記第１メモリ・エリアの書き換えおよび前記第２メモリ・エリアの再分配のステップは、更に、
    前記第１エリアの未使用メモリ・ブロックに対応する少なくとも１つのエントリを含む第２テーブルを読み取り、
    前記第１メモリ・エリアのコンポーネントを順次パックし、前記未使用メモリ・ブロックを統合するために、前記第１メモリ・エリアのコンポーネントを書き換え、
    前記第２メモリ・エリアの各コンポーネントのサイズを順次評価し、前記第２メモリ・エリアのコンポーネントを、前記第２メモリ・エリアの前記コンポーネントのサイズおよび前記統合した未使用メモリ・ブロックのサイズが許す、前記第１メモリ・エリアに再書き込みし、
    前記順次評価および再書き込みに続いて、前記統合した未使用メモリ・ブロックの残りのブロックを識別し、
    前記統合した未使用メモリ・ブロックの残りのブロックを、前記第２メモリ・エリアの一部として指定することによって、前記第２メモリ・エリアを再分配し、
    前記再分配した第２メモリ・エリアの使用可能なメモリの開始アドレスを維持するために、前記第２メモリ・エリアのポインタを設定することを含む、方法。
13. 請求項１２記載の方法において、前記第２テーブルのエントリは、リード・オンリ・メモリ（ＲＯＭ）番号、開始アドレス、およびサイズを含む前記未使用メモリ・ブロックの情報を含む、方法。
14. 請求項８記載の方法であって、更に、
    前記ホスト・デバイスの主プログラムからの関数コールを受け、該関数コールが対応する電子ファイルの識別情報を含み、
    前記対応する電子ファイルの開始アドレスをベクトル・テーブルから読み出し、
    前記開始アドレスおよび前記識別情報を用いて、前記対応する電子ファイルに対するコールを発生することによって、
    前記ホスト・デバイスの電子ファイルによって与えられる機能にアクセスするステップを含む、方法。
15. ファイル更新中におけるデバイス・メモリ管理方法であって、
    受信コンポーネントの識別情報を用いて、新たな電子ファイルの少なくとも１つの受信コンポーネントのサイズを判定するステップであって、前記新たな電子ファイルが、元の電子ファイルの更新バージョンである、ステップと、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズ以下である場合、前記受信コンポーネントを書き込む、第１メモリ・エリアの元のメモリ・ブロックを割り当て、前記元のメモリ・ブロックが前記元の電子ファイルの対応するコンポーネントを含む、ステップと、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズを超過する場合、第２メモリ・エリアと前記第１メモリ・エリアの未使用部分とを探索して、前記受信コンポーネントを格納できる十分に大きなメモリ・ブロックを求めるステップと、
    前記サイズが前記第１および第２メモリ・エリアの使用可能なメモリ・ブロックのサイズを超過する場合、未使用部分を除去するように前記第１メモリ・エリアを書き換え、前記第１および第２メモリ・エリアを再分配し、前記受信コンポーネントを書き込む、前記第２メモリ・エリアのメモリ・ブロックを割り当てるステップと、
    を備えた方法。
16. 請求項１５記載の方法において、前記第１メモリ・エリアの書き換えは、更に、
    前記第１メモリ・エリアの未使用部分に対応する少なくとも１つのエントリを含むテーブルを読み込み、
    前記第１メモリ・エリアのコンポーネントを順次パックし、前記未使用メモリ・ブロックを統合するために、前記第１メモリ・エリアのコンポーネントを書き直すことを含む、方法。
17. 請求項１５記載の方法において、前記第１および第２メモリ・エリアを再分配するステップは、更に、
    前記第２メモリ・エリアの各コンポーネントのサイズを順次評価し、前記第２メモリ・エリアの前記コンポーネントのサイズおよび前記書き換えた第２メモリ・エリアの統合した未使用メモリ・ブロックのサイズが許すとき、前記第２メモリ・エリアのコンポーネントを前記書き換えた第１メモリ・エリアに書き込み、
    前記順次評価および書き込みに続いて、前記統合した未使用メモリ・ブロックの残りのブロックを特定し、
    前記統合した未使用メモリ・ブロックの残りのブロックを前記第２メモリ・エリアの一部として指定することにより、前記第１および第２メモリ・エリアを再分配し、
    前記再分配した第２メモリ・エリアの使用可能なメモリの開始アドレスを維持するために、前記第２メモリ・エリアのポインタを設定し、
    前記テーブルを評価すること、
    を含む、方法。
18. 電子デバイスのメモリを管理する方法であって、
    新電子ファイルの少なくとも１つの新コンポーネントを受信し、該新電子ファイルは、元の電子ファイルの更新バージョンであり、
    第１および第２メモリ・エリアの順次探索を行うことによって、前記受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように前記第１メモリ・エリアを書き換え、前記サイズが前記第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、前記第１および第２メモリ・エリアを再分配し、
    前記新コンポーネントを予約したメモリ・ブロックに書き込み、
    前記新コンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込んだときに、ベクトル・テーブルを更新することによって、
    前記デバイスの電子ファイルを更新するステップと、
    前記デバイスの主プログラムからの関数コールを受け、前記関数コールは対応する電子ファイルの識別情報を含み、
    前記ベクトル・テーブルから前記対応する電子ファイルの開始アドレスを読み取り、
    前記開始アドレスおよび前記識別情報を用いて、前記対応する電子ファイルに対するコールを生成することによって、
    前記デバイスの電子ファイルにアクセスするステップと、
    を備えた方法。
19. 請求項１８記載の方法において、前記識別情報は、関数識別、および該関数に対する引数を含む、方法。
20. 新電子ファイルの少なくとも１つの新コンポーネントを受信する手段であって、該新電子ファイルは、元の電子ファイルの更新バージョンである、手段と、
    第１および第２メモリ・エリアの順次探索を行うことによって、前記受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約する手段であって、未使用メモリ・ブロックを排除するように前記第１メモリ・エリアを書き換え、前記サイズが前記第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、前記第１および第２メモリ・エリアを再分配する、手段と、
    前記新コンポーネントを前記予約したメモリ・ブロックに書き込むことによって、前記元の電子ファイルを更新する手段と、
    前記新コンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・ブロック以外のメモリ・ブロックに書き込む場合、ベクトル・テーブルを更新する手段と、
    を備えている装置。
21. 請求項２０記載の装置において、該装置は、パーソナル・コンピュータ、携帯用計算機、セルラ電話機、携帯用通信デバイス、およびパーソナル・ディジタル・アシスタントの中から選択した、少なくとも１つのプロセッサに基づくデバイスを含む、装置。
22. 請求項２０記載の装置において、前記メモリ・ブロックを識別し予約する手段は、第１アプリケーション・プログラミング・インターフェース（ＡＰＩ）である、装置。
23. 請求項２０記載の装置であって、更に、
    前記デバイスの主プログラムから関数コールを受け取る手段であって、該関数コールは、対応する電子ファイルの識別情報を含む、手段と、
    前記ベクトル・テーブルから前記対応する電子ファイルの開始アドレスを読み取る手段と、
    前記開始アドレスおよび前記識別情報を用いて、前記対応する電子ファイルに対するコールを発生する手段と、
    を含む、装置。
24. 請求項２３記載の装置において、関数コールを受け取る前記手段は、第２アプリケーション・プログラミング・インターフェース（ＡＰＩ）である、装置。
25. 実行可能な命令を含むコンピュータ読み取り可能媒体であって、処理システムにおいて実行すると、
    新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信し、前記新電子ファイルは、元の電子ファイルの更新バージョンであり、前記識別情報は前記受信したコンポーネントのサイズを含み、
    第１および第２メモリ・エリアの順次探索を行うことによって、前記受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように前記第１メモリ・エリアを書き換え、前記サイズが前記第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、前記第１および第２メモリ・エリアを再分配し、
    前記予約したメモリ・ブロックのアドレスを与え、
    前記受信したコンポーネントを前記予約メモリ・ブロックに書き込むことによって、前記元の電子ファイルを更新する、
    ことによって電子ファイルおよびファイル・コンポーネントを更新する、コンピュータ読み取り可能媒体。
26. 実行可能な命令を含む電磁媒体であって、処理システムにおいて実行すると、
    新電子ファイルの少なくとも１つの受信コンポーネントの識別情報を受信し、前記新電子ファイルは、元の電子ファイルの更新バージョンであり、前記識別情報は前記受信したコンポーネントのサイズを含み、
    第１および第２メモリ・エリアの順次探索を行うことによって、前記受信したコンポーネントを収容することができる十分大きなメモリ・ブロックを識別し予約し、未使用メモリ・ブロックを排除するように前記第１メモリ・エリアを書き換え、前記サイズが前記第１および第２メモリ・エリアの使用可能メモリ・ブロックのサイズを超過する場合、前記第１および第２メモリ・エリアを再分配し、
    前記予約したメモリ・ブロックのアドレスを与え、
    前記受信したコンポーネントを前記予約メモリ・ブロックに書き込むことによって、前記元の電子ファイルを更新する、
    ことによって電子ファイルおよびファイル・コンポーネントを更新する、電磁媒体。
27. 電子ファイルの更新システムであって、
    デルタ・ファイルを生成する、ファイル差別化および更新システムの第１コンポーネントを含む第１デバイスと、
    前記第１デバイスから前記第１デルタ・ファイルを少なくとも１つの結合部を介して受け取る第２デバイスであって、前記ファイル差別化および更新システムの第２コンポーネントを含む第２デバイスと、
    を備えており、
    前記デルタ・ファイルを通じて新電子ファイルの少なくとも１つのコンポーネントを受信し、前記新電子ファイルは、元の電子ファイルの更新バージョンであり、
    前記受信したコンポーネントのサイズを判定し、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズ以下である場合、前記受信したコンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込み、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズを超過する場合、前記受信したコンポーネントを、前記元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込む、
    ことにより前記第２デバイスの電子ファイルを更新するように構成されている、システム。
28. 電子ファイルの更新方法であって、
    新電子ファイルの少なくとも１つのコンポーネントを受信するステップであって、前記新電子ファイルは、元の電子ファイルの更新バージョンである、ステップと、
    前記受信したコンポーネントのサイズを判定するステップと、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズ以下である場合、前記受信したコンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込むステップと、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズを超過する場合、前記受信したコンポーネントを、前記元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込むステップと、
    を備えた方法。
29. 請求項２８記載の方法において、前記少なくとも１つの成分は、コンポーネントのグループを含む、方法。
30. 新電子ファイルの少なくとも１つのコンポーネントを受信する手段であって、前記新電子ファイルは、元の電子ファイルの更新バージョンである、手段と、
    前記受信したコンポーネントのサイズを判定する手段と、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズ以下である場合、前記受信したコンポーネントを、前記元の電子ファイルの対応するコンポーネントを含む元のメモリ・エリアに書き込む手段と、
    前記サイズが前記元の電子ファイルの対応するコンポーネントのサイズを超過する場合、前記受信したコンポーネントを、前記元のメモリ・エリアと関連付けられた予約メモリ・エリアに書き込む手段と、
    を備えている、装置。

Images