(57)【要約】  集中ＤＡマネージャを用いて、関数コール、グローバル変数、および定数変数参照を、ソフトウェア・コードのコンポーネント間で管理する、ダイナミック・アドレシング（ＤＡ）を提供する。ＤＡマネージャは、コンポーネントをリンクする過程の間に生成され、コードと共に、クライアント・デバイスのメモリにロードされる。１つのコンポーネントから別のコンポーネントへの参照を、各コンポーネントのアドレスと共に、ＤＡマネージャに格納する。ＤＡマネージャは、ソフトウェアの実行中、集中ルータ・リンク・コンポーネントとして作用するので、１つのコンポーネントから別のコンポーネントへの参照は、コンポーネント間で直接ではなく、ＤＡマネージャを介して導かれる。したがって、メモリにおけるコンポーネントの位置変更が生ずるファイル・アップグレードの間、コンポーネントに対する変更がＤＡマネージャによって記録され、これによってコード内にあるコンポーネントに対する参照の完全性を維持する。
2007511816.tif 000002
【特許請求の範囲】
【請求項１】
ダイナミック・アドレシング・マネージャと、プロセッサに結合された複数のソフトウェア・コンポーネントとを備えている携帯通信デバイスであって、前記ダイナミック・アドレシング・マネージャが１つ以上のリンクを含み、各リンクが、コンポーネントにおいて識別された各参照と、該識別された参照に対応するソフトウェア・コンポーネントの別の１つとの間にプログラム・リンクを形成し、前記ダイナミック・アドレシング・マネージャが、前記コードの実行中前記リンクを用いて前記複数のソフトウェア・コンポーネントをリンクする、携帯通信デバイス。
【請求項２】
請求項１記載のデバイスにおいて、各リンクは、前記ダイナミック・アドレシング・マネージャにおいて固定アドレスを有する、デバイス。
【請求項３】
請求項１記載のデバイスにおいて、前記参照は、関数コールおよび変数参照の内少なくとも一方を含む、デバイス。
【請求項４】
請求項１記載のデバイスにおいて、前記変数参照は、グローバル変数参照および定数変数参照の内少なくとも一方を含む、デバイス。
【請求項５】
請求項１記載のデバイスにおいて、前記ダイナミック・アドレシング・マネージャは、関数コールおよび変数参照の少なくとも一方についての集中ジャンプ・テーブルである、ベクトル・テーブルを備えている、デバイス。
【請求項６】
請求項５記載のデバイスにおいて、前記複数のソフトウェア・コンポーネントをリンクする場合、
第１コンポーネントから前記ベクトル・テーブルのエントリに参照を誘導し、
前記エントリの情報を用いて、前記参照を第２コンポーネントに誘導し直す、
デバイス。
【請求項７】
請求項１記載のデバイスにおいて、前記ダイナミック・アドレシング・マネージャは、少なくとも１つの集中セクションを備えている、デバイス。
【請求項８】
請求項７記載のデバイスにおいて、少なくとも１つの変数参照を前記集中セクションに割り当てる、デバイス。
【請求項９】
請求項８記載のデバイスにおいて、前記複数のソフトウェア・コンポーネントをリンクする場合、前記変数参照への参照を、前記変数参照に対応する前記集中セクションのアドレスに誘導することを含む、デバイス。
【請求項１０】
請求項１記載のデバイスであって、更に、アップグレード・クライアントを備えており、該アップグレード・クライアントは、前記複数のソフトウェア・コンポーネントをアップグレードし、アップグレードは、
ワイヤレス結合を介してアップグレード・ファイルを受信し、
前記アップグレード・ファイルの内容に対して適切に、前記複数のソフトウェア・コンポーネントの少なくとも１つをアップグレードし、
前記ダイナミック・アドレシング・マネージャのリンクの情報をアップグレードすることにより、前記複数のソフトウェア・コンポーネント間で前記リンクをアップグレードする、
ことを含む、デバイス。
【請求項１１】
請求項１記載のデバイスであって、更に、１つ以上のメモリ・エリアを含むメモリを備えており、前記ダイナミック・アドレシング・マネージャを前記メモリに格納してある、デバイス。
【請求項１２】
請求項１１記載のデバイスにおいて、前記メモリは、ランダム・アクセス・メモリおよびリード・オンリ・メモリの内少なくとも一方を含む、デバイス。
【請求項１３】
請求項１記載のデバイスにおいて、前記クライアント・デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つである、デバイス。
【請求項１４】
クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成するステップと、
前記複数のコンポーネントの各々に含まれている１つ以上の参照を識別するステップであって、各参照が前記コードの１つ以上の他のコンポーネントに対する参照である、ステップと、
１つ以上のリンクを含むマネージャ・コンポーネントを生成するステップであって、各リンクが、１つのコンポーネントにおいて識別された各参照と、該識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成する、ステップと、
前記コードの実行中に、前記マネージャ・コンポーネントのリンクを用いて、前記複数のコンポーネントをリンクするステップと、
を備えている方法。
【請求項１５】
請求項１４記載の方法において、各リンクが、前記マネージャ・コンポーネントにおいて固定アドレスを有する、方法。
【請求項１６】
請求項１４記載の方法において、前記参照が、関数コール、グローバル変数参照、および定数変数参照の内少なくとも１つを含む、方法。
【請求項１７】
請求項１４記載の方法において、前記参照は、相対オフセット・ジャンプ／分岐命令、および絶対オフセット・ジャンプ／分岐命令の少なくとも一方を含む、方法。
【請求項１８】
請求項１４記載の方法において、前記参照は、グローバル定数変数、グローバル・リード／ライト・データ・アドレス、およびグローバル・ゼロ初期化データ・アドレスの内少なくとも１つを含む、方法。
【請求項１９】
請求項１４記載の方法において、前記マネージャ・コンポーネントを生成するステップは、更に、関数コールおよびグローバル変数の少なくとも一方に対する集中ジャンプ・テーブルである、ベクトル・テーブルを生成するステップを含む、方法。
【請求項２０】
請求項１９記載の方法において、前記複数のコンポーネントをリンクするステップは、更に、
第１コンポーネントから前記ベクトル・テーブルのエントリに参照を誘導するステップと、
前記エントリの情報を用いて、前記参照を第２コンポーネントに誘導し直すステップと、
を含む、方法。
【請求項２１】
請求項１９記載の方法において、前記参照は、関数コールおよび変数の少なくとも一方を含む、方法。
【請求項２２】
請求項１４記載の方法において、前記マネージャ・コンポーネントを生成するステップは、更に、
前記マネージャ・コンポーネントの少なくとも１つの集中セクションを生成するステップと、
グローバル定数変数を前記生成した集中セクションに割り当てるステップと、
を含む、方法。
【請求項２３】
請求項２２記載の方法において、前記複数のコンポーネントをリンクするステップは、更に、前記グローバル定数変数への参照を、該グローバル定数変数に対応する前記集中セクションのアドレスに誘導するステップを含む、方法。
【請求項２４】
請求項２２記載の方法において、前記マネージャ・コンポーネントを生成するステップは、更に、グローバル・リード／ライト・データ・アドレスを前記生成した集中セクションに割り当てるステップを含む、方法。
【請求項２５】
請求項２４記載の方法において、前記複数のコンポーネントをリンクするステップは、更に、前記グローバル・リード／ライト・データ・アドレスへの参照を、該グローバル・リード／ライト・データ・アドレスに対応する前記集中セクションのアドレスに誘導するステップを含む、方法。
【請求項２６】
請求項２２記載の方法において、前記マネージャ・コンポーネントを生成するステップは、更に、グローバル・ゼロ初期化データ・アドレスを前記生成した集中セクションに割り当てるステップを含む、方法。
【請求項２７】
請求項２６記載の方法において、前記複数のコンポーネントをリンクするステップは、更に、前記グローバル・ゼロ初期化データ・アドレスへの参照を、該グローバル・ゼロ初期化データ・アドレスに対応する前記集中セクションのアドレスに誘導するステップを含む、方法。
【請求項２８】
請求項１４記載の方法であって、更に、前記クライアント・デバイスの１つ以上のメモリ・エリアに、前記マネージャ・コンポーネントを格納するステップを含む、方法。
【請求項２９】
請求項２８記載の方法において、前記メモリ・エリアは、ランダム・アクセス・メモリおよびリード・オンリ・メモリの少なくとも１つにおけるエリアを含む、方法。
【請求項３０】
請求項１４記載の方法であって、更に、前記コードをアプグレードするステップを含み、該アップグレードは、
ワイヤレス結合を介して、アップグレード・ファイルを受信するステップと、
前記アップグレード・ファイルの内容に対して適切に、前記複数のコンポーネントの少なくとも１つをアップグレードするステップと、
前記マネージャ・コンポーネントをアップグレードすることにより、アップグレードしたコードの前記複数のコンポーネント間で前記リンクをアップグレードするステップを、
を含む、方法。
【請求項３１】
請求項１４記載の方法において、前記クライアント・デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つである、方法。
【請求項３２】
アップグレード・ファイルを生成する第１アップグレード・コンポーネントを含む第１デバイスであって、前記アップグレード・ファイルが、電子ファイルにおけるエラーを修復するための情報と、前記電子ファイルに機能性を追加するための情報の内少なくとも一方を含む、第１デバイスと、
第２アップグレード・コンポーネントと、ダイナミック・アドレシング・マネージャと、複数のソフトウェア・コンポーネントとを備えている移動通信デバイスであって、前記ダイナミック・アドレシング・マネージャが１つ以上のリンクを含み、各リンクが、１つのコンポーネントにおいて識別される各参照と、該識別された参照に対応する前記ソフトウェア・コンポーネントの別の１つとの間にプログラム・リンクを形成し、前記ダイナミック・アドレシング・マネージャが、前記コードの実行中、前記リンクを用いて、前記複数のソフトウェア・コンポーネントをリンクする、移動通信デバイスと、
を備えている、システム。
【請求項３３】
請求項３２記載のシステムであって、更に、ワイヤレス結合を備えており、前記第２アップグレード・コンポーネントは、前記ワイヤレス結合を介して、前記アップグレード・ファイルを受信し、前記第２アップグレード・コンポーネントは、前記アップグレード・ファイルの情報を用いて、前記複数のソフトウェア・コンポーネントを自動的にアップグレードする、システム。
【請求項３４】
請求項３３記載のシステムにおいて、前記アップグレードは、前記アップグレード・ファイルの内容に対して適切に、前記複数のソフトウェア・コンポーネントの少なくとも１つをアップグレードすることと、前記ダイナミック・アドレシング・マネージャのリンクの情報をアップグレードすることにより、前記複数のソフトウェア・コンポーネント間で前記リンクをアップグレードするとから成る、システム。
【請求項３５】
請求項３２記載のシステムにおいて、各リンクが、前記ダイナミック・アドレシング・マネージャにおいて固定アドレスを有する、システム。
【請求項３６】
請求項３２記載のシステムにおいて、前記参照は、関数コールおよび変数参照の少なくとも１つを含む、システム。
【請求項３７】
請求項３２記載のシステムにおいて、前記ダイナミック・アドレシング・マネージャは、関数コールおよび変数参照の少なくとも一方に対する集中ジャンプ・テーブルであり、ベクトル・テーブルを備えている、システム。
【請求項３８】
請求項３２記載のシステムにおいて、前記ダイナミック・アドレシング・マネージャは、少なくとも１つの集中セクションを備えており、少なくとも１つの変数参照を前記集中セクションに割り当てる、システム。
【請求項３９】
請求項３２記載のシステムにおいて、前記第１デバイスは、前記第２デバイス上にホストされているソフトウェア・コンポーネントの少なくとも１つのプロバイダによってアクセス可能な、プロセッサに基づくデバイスである、システム。
【請求項４０】
請求項３２記載のシステムにおいて、前記移動通信デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つを含む、システム。
【請求項４１】
請求項３２記載のシステムにおいて、前記複数のソフトウェア・コンポーネントは、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人使用データを含むファイルを含む、ソフトウェア・ファイルから成る、システム。
【請求項４２】
移動通信デバイスであって、
クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成する手段と、
前記複数のコンポーネントの各々に含まれている１つ以上の参照を識別する手段であって、各参照が前記コードの１つ以上の他のコンポーネントに対する参照である、手段と、
１つ以上のリンクを含むマネージャ・コンポーネントを生成する手段であって、各リンクが、１つのコンポーネントにおいて識別された各参照と、該識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成する、手段と、
前記コードの実行中に、前記マネージャ・コンポーネントのリンクを用いて、前記複数のコンポーネントをリンクする手段と、
を備えている移動通信デバイス。
【請求項４３】
請求項４２記載のデバイスにおいて、前記マネージャ・コンポーネントを生成する手段は、更に、関数コールおよびグローバル変数の少なくとも一方に対する集中ジャンプ・テーブルである、ベクトル・テーブルを生成する手段を備えている、デバイス。
【請求項４４】
請求項４３記載のデバイスにおいて、前記複数のコンポーネントをリンクする前記手段は、更に、
第１コンポーネントから前記ベクトル・テーブルのエントリに参照を誘導する手段と、
前記エントリの情報を用いて、前記参照を第２コンポーネントに誘導し直す手段と、
を備えている、デバイス。
【請求項４５】
請求項４２記載のデバイスにおいて、前記マネージャ・コンポーネントを生成する前記手段は、更に、
前記マネージャ・コンポーネントの少なくとも１つの集中セクションを生成する手段と、
前記生成した集中セクションに対して変数参照を割り当てる手段と、
を備えている、デバイス。
【請求項４６】
請求項４５記載のデバイスにおいて、前記複数のコンポーネントをリンクする手段は、更に、前記変数参照への参照を、該変数参照に対応する前記集中セクションのアドレスに誘導する手段を備えている、デバイス。
【請求項４７】
請求項４２記載のデバイスであって、更に、前記コードをアップグレードする手段を備えており、
ワイヤレス結合を介してアップグレード・ファイルを受信する手段と、
前記アップグレード・ファイルの内容に適切なように、前記複数のコンポーネントの少なくとも１つをアップグレードする手段と、
前記マネージャ・コンポーネントをアップグレードすることによって、前記複数のアップグレードしたコードのコンポーネント間におけるリンクをアップグレードする手段と、
を含む、デバイス。
【請求項４８】
実行可能命令を含む機械読み取り可能媒体であって、処理システムにおいて実行すると、
クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成し、
前記複数のコンポーネントの各々に含まれている１つ以上の参照を識別し、各参照が前記コードの１つ以上の他のコンポーネントに対する参照であり、
１つ以上のリンクを含むマネージャ・コンポーネントを生成し、各リンクが、１つのコンポーネントにおいて識別された各参照と、該識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成し、
前記コードの実行中に、前記マネージャ・コンポーネントのリンクを用いて、前記複数のコンポーネントをリンクする、
ことによって、携帯デバイスにおけるソフトウェア・コンポーネントをリンクする、機械読み取り可能媒体。
【請求項４９】
請求項４８記載の媒体であって、更に、
ワイヤレス結合を介してアップグレード・ファイルを受信し、
前記アップグレード・ファイルの内容に適切なように、前記複数のコンポーネントの少なくとも１つをアップグレードし、
前記マネージャ・コンポーネントをアップグレードすることによって、前記複数のアップグレードしたコードのコンポーネント間におけるリンクをアップグレードする、
ことによって、前記コードをアップグレードすることを含む、媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
開示する実施形態は、電子ファイルをアップグレードおよび維持する間におけるメモリ管理に関する。
【背景技術】
【０００２】
関連出願
本願は、２００３年１０月２３日に出願された米国特許出願第６０／５１３，７６４号の優先権を主張する。また、本願は、２００２年１１月１８日に出願された、米国特許出願第１０／２９８，４５８号の一部継続出願でもあり、双方とも現在係属中である。
【０００３】
本願は、２００２年５月１３日に出願された米国特許出願第１０／１４６，５４５号、２００２年９月３０日に出願された第１０／２６１，１５３号、２００２年１１月１２日に出願された第１０／２９２，２４５号、２００２年１１月１８日に出願された第１０／２９８，３９３号、２００３年７月９日に出願された第１０／６１６，６１５号に関連がある。これらの全ては現在係属中である。
【０００４】
ソフトウェアは、殆どの電子デバイス上でホストされ実行し、人が読むことができる情報相互交換用米国規格コード（「ＡＳＣＩＩ」）平文テキスト・ファイルまたは二進コードの形式の１つ以上のファイルを含む。ホストされたソフトウェアは、プロセッサ即ち中央演算装置（「ＣＰＵ」）上で実行し、ホスト・デバイス内において機能性を設けるが、時と共に変わっていくことが多い。ソフトウェアの変更は、ソフトウェア・ファイルにおけるバグ、即ち、誤りを訂正する必要性、発展する技術に合わせる必要性、または新たな特徴および機能を追加する必要性等、様々な必要性の結果生じる可能性がある。即ち、移動処理デバイス、例えば、移動ワイヤレス・デバイス上にホストされている埋め込みソフトウェア・コンポーネントは、多数のソフトウェア・バグを含むことが多く、訂正が必要である。
【０００５】
デバイスのソフトウェア即ちプログラムは、多くの場合モジュールまたはコンポーネントと呼ばれている小さい単位に分割されたソフトウェア・ファイルを含む。移動ワイヤレス・デバイスでは、リアル・タイム・オペレーティング・システム（「ＲＴＯＳ」）が用いられるのが通例であり、デバイスにホストされているソフトウェア・モジュールまたはコンポーネントは、単一の大型ファイルとしてリンクされている。この大型のソフトウェア・ファイルは、デバイスにロードされ、または埋め込まれ、通例ワイヤレス・デバイスのリード・オンリ・メモリ（「ＲＯＭ」）またはフラッシュＲＯＭに格納する。
【０００６】
ワイヤレス・デバイスにホストされているソフトウェア・ファイルは、無線リンクのように、ワイヤレス通信リンクまたはオーバーディエア（「ＯＴＡ」：overthe-air）リンクを用いて、誤りを訂正したり、または新たな機能を追加するために更新することができる。帯域幅、メモリ、およびワイヤレス・デバイスに関係するその他の制約のために、デバイスを販売によって放出した後に、ホストされているソフトウェアを更新するには、特殊な企業固有のアプリケーションが必要となる。これら企業固有のアプリケーションの一例には、カリフォルニア州ＡｌｖｉｓｏのＩｎｎｏｐａｔｈ  Ｓｏｆｔｗａｒｅ，Ｉｎｃ．から入手可能なＤｅｌｔａＵｐｄａｔｅＴＭおよびＤｅｌｔａＲｅｗｒｉｔｅＴＭと呼ばれる、アップグレードまたは更新のアプリケーションが含まれる。これらのアップグレード・アプリケーションは、関連出願の主題でもある。
【０００７】
ワイヤレス・デバイス用プログラムをデバイス・メモリに格納するには、通例、スタティック・アドレシングと呼ばれる方法を用いる。プログラムを書き込んだ後、これをコンピュータ読み取り可能コードにコンパイルし、その間にコードの異なるモジュールまたはコンポーネントをリンクする。その結果、画像またはメモリ画像と呼ばれるものが得られる。ここで、画像とは、ホスト・デバイスのＲＯＭに格納されている、機械語の実行可能命令セットである。これらのプログラムは、通例、命令の連続ストリームに編成されており、その一部は、ホスト・デバイスＲＯＭの他の部分にある命令への参照を有する。この連続的な相互接続アーキテクチャのため、ホスト・デバイスＲＯＭ内にある特定のマシン・コードの場所は大抵固定であり、そのため「スタティック・アドレシング」という用語が生まれた。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ＯＴＡリンクを通じて受信したファイルを用いて、ホスト・デバイスのコードの一部分をアップグレードする場合、変更が小規模であっても、コードにおける参照を並び替えて(re-sequence)調節するためには、ホスト・デバイスＲＯＭの大部分を書き換える必要がある。このため、典型的な更新プロセスは、厄介で、誤りが生じやすく、時間がかかる。その結果、セルラ電話機やその他の移動通信デバイスのようなワイヤレス・デバイス、パーソナル・ディジタル・アシスタント（「ＰＤＡ」）、およびパーソナル・コンピュータ上にホストされているソフトウェア・アプリケーションをアップグレードする際に用いるダイナミック・アドレシングが求められている。
【発明を実施するための最良の形態】
【０００９】
図面においては、同じ参照番号は、同一または実質的に同様の要素または作用を識別する。いずれの個々の要素または作用の論述をも容易に識別するために、参照番号における最上位桁は、当該要素が最初に紹介される図番を示すこととする（例えば、要素１２６は、図１において始めて紹介され、図１に関して論じられるものとする）。
【００１０】
ここでは、ワイヤレス・ハンドセットまたは同様のクライアント・デバイス上にホストされているソフトウェアの更新に用いるダイナミック・アドレシングについて記載する。一実施形態のＤＡは、デバイス・メモリ内に格納されているコードを、関連するコンポーネントのグループに編成することを含む。この関連コンポーネントのことを、ここでは、埋め込みソフトウェア・コンポーネント「ＥＢＳＣ」）とも呼ぶ。あるコンポーネントから別のコンポーネントへのいずれの参照も特定して、集中および分離プログラムに、各コンポーネントの位置即ちアドレスと共に、格納する。このプログラムを、ここでは、「ＤＡマネージャ」または「集中ＤＡマネージャ」と呼ぶ。ＤＡマネージャは、ＥＢＳＣをリンクするプロセス中に生成され、クライアント・デバイス・プログラムと共に、クライアント・デバイス・メモリにロードされる。
【００１１】
動作において、ＤＡマネージャは、全体的に、集中ルータまたはスイッチボードとして機能し、クライアント・デバイスの各ＥＢＳＣのシンボル位置を把握し、クライアント・デバイス・プログラムの実行中に、必要に応じてＥＢＳＣをリンクする。あるＥＢＳＣから別のＥＢＳＣへのいずれの参照も、これらＥＢＳＣ間で直接行われる代わりに、ＤＡマネージャを介して導かれる。したがって、ファイル・アップグレードの最中にコンポーネントを修正し、アップグレードの結果、クライアント・デバイス・メモリにおいてＥＢＳＣの局所的な変化が生じた場合、この変化をＤＡマネージャが記録するので、クライアント・デバイス・プログラム内にあるＥＢＳＣへの参照即ち連結(linkage)の完全性を維持する。
【００１２】
その結果、ＤＡマネージャは、クライアント・デバイス・メモリにおいてマシン・コードを編成する効率的で論理的な方法を設ける。一実施形態のＤＡマネージャは、マシン・コードの１つ以上の部分（ＥＢＳＣ）に対する追加、削除および修正を可能としつつ、クライアント・デバイス・メモリに格納されているコードの残り部分に波及したり影響を及ぼすことはない。対照的に、スタティック・アドレシングを用い、メモリに格納されているプログラムを変更し、この変更が新たな数行のコードの追加を含む場合、変更したコード以降にある全てのコードを、メモリ・レイアウトにおいてずらしていくことになる。このようにコードをずらすには、変更したコード内にあるあらゆる参照または連結に対しても変更が必要となる。このため、小規模なプログラムの変更が、クライアント・デバイス・メモリに格納されているマシン・コードの多くにおいて、対応する変更や補うための変更が生ずる可能性がある。
【００１３】
ＤＡは、スタティック・アドレシングに伴う問題を回避する。何故なら、ＥＢＳＣアドレスに対する変更は、ＤＡマネージャにおいて一度だけ行えばよく、クライアント・デバイス・プログラムの全てにわたって行う必要はないからである。再アドレシングは一層効率的であるので、特定のブロックに割り当てられるクライアント・デバイス・メモリのエリアを縮小することもでき、クライアント・デバイスの利用可能なメモリの利用度が高まることになる。更に、アドレス変更の書き換えをＤＡマネージャのみに限定することによって、デバッグ、修正、およびその他のクライアント・デバイス・ソフトウェアのアップグレードは、遥かに短い時間で遂行される。この結果、効率が向上し、コストや失われる収益が大幅に低減する。また、典型的なスタティック・アドレシングで可能なソフトウェア・ダウンロードおよび更新よりも遥かに大きく複雑にすることができる。
【００１４】
以下の説明では、ＤＡおよびＤＡマネージャの実施形態の完全な理解が得られ、実施可能な説明が得られるように、多数の具体的な詳細を導入する。しかしながら、ＤＡおよびＤＡマネージャは、これら具体的な詳細の１つ以上がなくても、または他のコンポーネント、システム等を用いても実施可能であることを、当業者は認めよう。他方では、ＤＡおよびＤＡマネージャの特徴面を曖昧にするのを避けるために、周知の構造や動作については図示も、詳細な説明も行わないこととする。
【００１５】
図１は、一実施形態の下における、ＤＡマネージャを備えたクライアント・デバイスを含むシステム１００のブロック図である。一実施形態のシステム１００は、ファイル・アップグレード・システム１００であるが、そのように限定されるのではない。概略的に、ファイル・アップグレード・システム１００は、第１コンピュータ・システム１０２、即ち、ホスト・システムと、クライアント・デバイスまたはコンピュータ１２２を含む、１つ以上の第２コンピュータ・システムとを含む。ホスト・システム１０２およびクライアント・デバイス１２２は、各々、プログラム制御の下で動作する少なくとも１つのプロセッサ１０４および１２４をそれぞれ含むが、そのように限定されるのではない。ホスト・システム１０２およびクライアント・デバイス１２２は、通信路１９９を通じて通信する。これらのコンピュータ・システム１０２および１２２は、当技術分野では周知のように、共に動作する計算機のいずれの集合体でも含む。また、コンピュータ・システム１０２および１２２は、更に大きなコンピュータ・システム内にあるコンポーネントを含むこともできる。
【００１６】
ホスト・システム１０２のプロセッサ１０４は、プログラム制御の下で、データベース１０６およびファイル差別化アルゴリズム１１４の間を結合する。あるいは、ホスト・システム１０２の種々の他のコンポーネントが、プロセッサ１０４、データベース１０６、およびファイル差別化アルゴリズム１１４間を結合し、プログラム制御の下でファイル更新機能を備えることができる。１つのプロセッサ１０４、１つのデータベース１０６、および１つのファイル差別化アルゴリズム１１４を示すが、種々の代替実施形態では、当業者には想起される種々の構成に結合されたこれらのコンポーネントの各々が、いずれの数および／または形式でも含まれる。更に、プロセッサ１０４、データベース１０６、およびファイル差別化アルゴリズム１１４は、別個のブロックとして示されているが、これらのブロックの一部または全部をモノリシックに単一のチップに集積すること、多数のチップまたはホスト・システムのコンポーネント間で分散すること、および／またはアルゴリズムの何らかの組み合わせで備えることも可能である。ファイル差別化アルゴリズム１１４は、ソフトウェア・アルゴリズム（複数のソフトウェア・アルゴリズム）、ファームウェア、ハードウェア、ならびにソフトウェア、ファームウェア、およびハードウェアのいずれの組み合わせでも実現することができる。この中で全体的に用いている「プロセッサ」という用語は、１つ以上のＣＰＵ、ディジタル信号プロセッサ（「ＤＳＰ」）、特定用途集積回路「ＡＳＩＣ」）等のような、いずれの論理処理ユニットをも意味するものとする。
【００１７】
同様に、一実施形態のクライアント・デバイス１２２は、プログラム制御の下で、デバイス・メモリ１３０間に結合されたプロセッサ１２４を含む。デバイス・メモリ１３０は、ＲＴＯＳ１３２（ここでは「主プログラム１３２」とも呼ぶ）、１つ以上の画像３００、デバイス・メモリ・マネージャ（「ＤＭＭ」）クライアント５００（「ＤＭＭクライアント」）、およびアップグレード・クライアント１２６を含む。画像３００は、ここではソフトウェア画像または二進画像とも呼ぶが、実行可能ファイルであり、１つ以上の埋め込みソフトウェア・コンポーネント（「ＥＢＳＣ」）ＥＢＳＣ１〜ＥＢＳＣＮ、予約メモリ・エリア３２０、および集中ＤＡマネージャ３１０を含む。ここでは、集中ＤＡマネージャ３１０を「ＤＡマネージャ３１０」とも呼ぶこととする。二進画像は、一般に、異なるコンポーネントによるリンク時間動作(link time operation)によって構成することができる。ＥＢＳＣのようなソフトウェア・コンポーネントは、独立して構築された二進画像であり、その機能は、故意に、互いに特別にグループ化されている。ＤＡマネージャ３１０は画像３００のコンポーネントとして示されているが、ＤＡマネージャは、ＤＭＭクライアント５００、アップグレード・クライアント１２６のコンポーネント、および／またはクライアント・デバイス１２２のその他のいずれのコンポーネントとすることができる。
【００１８】
あるいは、クライアント・デバイス１２２の種々のその他のコンポーネントが、プロセッサ１２４とデバイス・メモリ１３０との間に結合し、プログラム制御の下でファイル更新機能を備えることもできる。１つのプロセッサ１２４および１つのデバイス・メモリ１３０を示すが、種々の代替実施形態では、当業者によって想起される種々の構成に結合されたこれらのコンポーネントの各々は、いずれの数および／または形式でも含まれる。更に、プロセッサ１２４およびデバイス・メモリ１３０は別個のブロックとして示すが、これらのブロックの一部または全部は、モノリシックに単一チップ上に集積すること、多数のチップまたはホスト・システムのコンポーネント間で分散すること、および／またはアルゴリズムの何らかの組み合わせで備えることも可能である。デバイス・メモリ１３０のアルゴリズムまたはアプリケーションは、ソフトウェア・アルゴリズム（複数のソフトウェア・アルゴリズム）、ファームウェア、ハードウェア、ならびにソフトウェア、ファームウェア、およびハードウェアのいずれの組み合わせでも実現することができる。デバイス・メモリは、ＲＯＭおよびランダム・アクセス・メモリ（「ＲＡＭ」）を含むがこれらには限定されない、いずれの数および／または組み合わせ、あるいはメモリ形式でも含むことができる。
【００１９】
通信経路１９９は、コンピュータ・システム１０２および１２２間でファイルを伝達または転送するためのいずれの媒体でも含む。したがって、この経路１９９は、ワイヤレス接続、有線接続、および混合ワイヤレス／有線接続を含む。また、通信経路１９９は、ローカル・エリア・ネットワーク（「ＬＡＮ」）、都市エリア・ネットワーク（「ＭＡＮ」）、ワイド・エリア・ネットワーク（ＷＡＮ）、特定企業のネットワーク、オフィス間またはバックエンド(backend)ネットワーク、およびインターネットを含むネットワークへの結合部または接続部も含む。更に、通信経路１９９は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭのような、着脱可能な固定媒体、ならびにフラッシュ・メモリ、ユニバーサル・シリアル・バス（「ＵＳＢ」）接続、ＲＳ−２３２接続、電話回線、バス、および電子メール・メッセージを含む。
【００２０】
ホスト・システム１０２およびクライアント・デバイス１２２は、各々、電子ファイルの元バージョン１１０を含む。ここでは、これを元ファイル１１０または旧ファイルと呼ぶ。ホスト・システム１０２は、元ファイル１１０をデータベース１０６またはその他のメモリ・エリア、あるいはメモリ・エリアまたはデバイスの組み合わせに格納するが、そのように限定されるのではない。クライアント・デバイス１２２は、動作において使用するために、元ファイルをデバイス。メモリ１３０に格納する。
【００２１】
例えば、追加の機能性を提供するため、またはソフトウェア・バグを解決するために、ソフトウェア・プロバイダが元ファイル１１０をアップグレードするようなときに、電子ファイルの新バージョン１１２を生成する。電子ファイルの新バージョン１１２を、ここでは新ファイル１１２と呼ぶ。新ファイル１１２は、一般には、元ファイル１１０の更新または改訂バージョンであるが、そのように限定されるのではない。ソフトウェア・プロバイダは新ファイル１１２をホスト・システム１０２に転送する。
【００２２】
電子ファイル１１０および１１２は、ソフトウェア・ファイルを含み、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、ＥＢＳＣ、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人使用データを含むファイルを含むが、これらに限定されるのではない。いずれの種類のファイルでもバイト・ストリームと見なすことができるので、以後ファイルをバイト・ストリームと記述できることにする。
【００２３】
少なくとも１つのプロセッサ１０４を含むホスト・システム１０２のコンポーネントは、クライアント・デバイス１２２上にホストされている元ファイルをアップグレードする際に用いるアップグレード情報を生成するために、新ファイル１１２を受信し処理する。一実施形態では、プロセッサ１０４は、アップグレードの情報をクライアント・デバイス１２２に転送する際に用いるために、アップグレード・ファイル１１８を生成する。アップグレード・ファイル１１８は、新ファイル１１２と元ファイル１１０との間の差を符号化した差異ファイルを含むことができ、あるいは、代わりに、新ファイル１１２のあらゆる数および／または組み合わせのコンポーネントまたはモジュールを含むことができる。ホスト・システム１０２は、アップグレード情報を、通信路１９９を通じたアップグレード・ファイル１１８の転送によって、クライアント・デバイス１２２に供給する。
【００２４】
アップグレード・ファイル１１８が差異ファイルを含む実施形態では、プロセッサ１０４およびファイル差別化アルゴリズム１１４を含むホスト・システム１０２のコンポーネントが、新ファイル１１２と対応する元ファイル１１０との間の比較を処理することによって、新ファイル１１２と元ファイル１１０との間の差を計算する。ファイル差別化アルゴリズム１１４は、比較の間に差異ファイルを生成し、差異ファイルの情報をアップグレード・ファイル１１８に書き込む。
【００２５】
アップグレード・ファイル１１８は、通信路１１９を通じてクライアント・デバイス１２２に転送または送信する。転送の前に、当技術分野では公知の多数の圧縮技法のいずれかを用いて、アップグレード・ファイル１１８を圧縮してもよいが、そのように限定されるのではない。
【００２６】
プロセッサ１２４およびアップグレード・クライアント１２６を含むクライアント・デバイス１２２のコンポーネントは、アップグレード・ファイル１１８を受信し、アップグレード・ファイル１１８を用いて、クライアント・デバイス１２２に関する元ファイルのアップグレードを制御する。クライアント・デバイス１２２のアプグレード・クライアント１２６は、関連出願に記載されているように、ダウンロード・サブクライアント（「ＳＣ」）（「ダウンロードＳＣ」）、アップグレードＳＣ、および自己アップグレードＳＣ（図示せず）の少なくとも１つを含むが、そのように限定されるのではない。ダウンロードＳＣは、ホスト・システム１０２から転送されてくるアップグレード・ファイル１１８をダウンロード即ち受信するように機能する。アップグレードＳＣは、ホスト・システム１０２から転送され受信したファイルの情報を用いて、クライアント・デバイス１２２のソフトウェアに対してアップグレードを行う。自己アップグレードＳＣは、アップグレード・クライアント１２６のソフトウェアをアップグレードするように機能する。一実施形態の自己アップグレードＳＣは、ダウンロードＳＣまたはアップグレードＳＣのいずれとも異なる物理的メモリ・ブロックまたはエリアに格納されているが、そのように限定されるのではない。アップグレード・クライアント１２６のソフトウェアは、ダウンロードＳＣ、アップグレードＳＣ、および自己アップグレードＳＣのソフトウェアを含むが、これらに限定されるのではない。
【００２７】
一実施形態では、アップグレード・クライアント１２６は、アップグレード・ファイル１１８の情報を、ホストされている元ファイル１１０と共に処理して、クライアント・デバイス１２２において新ファイルのコピーを生成する。この新ファイルのコピーは、後に、アップグレード・クライアント１２６が、クライアント・デバイス１２２上にホストされている、目標の元ファイルをアップグレードするために用いられる。関連出願に記載されているように、一実施形態のアップグレード・クライアント１２６は、更新するファイルの種類、およびこれらの更新に対応するためにクライアント・デバイスの製造業者が割り当てたリソースに応じて、多数の方法を用いてＥＢＳＣを更新する。この更新プロセスが完了すると、この時点でクライアント・デバイス１２２に格納されている元ファイルは、ホスト・システム１０２において受信した新ファイル１１２と同一となっている。
【００２８】
当業者は、アップグレード・システム１００に関連する機能、およびアップグレード・システム１００を参照してここで説明したその他の機能および方法は、ホスト・システム１０２のコンポーネント、クライアント・デバイス１２２のコンポーネントによって実行することができ、あるいはホスト・システム１０２およびクライアント・デバイス１２２のコンポーネントのいずれの組み合わせの間で分散することもできることを認めよう。ホスト・システム１０２およびクライアント・デバイス１２２のコンポーネントは、ＤＳＰ集積回路によって、および／または従来のプログラム・ロジック・アレイまたは回路要素を介して、ＡＳＩＣとして実現することができる。ここに記載する実施形態は、ハードウェア、ファームウェア、および１つ以上のプロセッサ上で実行するソフトウェアのいずれの組み合わせを用いても実現することができ、この場合、ソフトウェアは、半導体チップ、コンピュータ読み取り可能ディスクに格納されたマイクロコードのような、いずれの適したコンピュータ読み取り可能媒体上にも格納することができ、あるいはサーバからダウンロードし、クライアントの内部に格納することができる。
【００２９】
図２は、一実施形態のファイル・アップグレード・システム１００のコンポーネントを含む、サービス・プロバイダ・インフラストラクチャ２００の一例のブロック図である。この実施形態では、サービス・プロバイダ・インフラストラクチャは、セルラ電話ネットワークまたはインフラストラクチャに関連して説明するが、代替実施形態では、そのように限定されることはない。サービス・プロバイダ・インフラストラクチャ２００は、ソフトウェア・コンポーネント分配部（ＳＣＤ）２０２、サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５、およびクライアント・デバイス１２２上にホストされているアップグレード・クライアント１２６を含むが、これらに限定されるのではない。サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５は、ソフトウェア・コンポーネント証明サーバ２０３およびアップグレード・マネージャ２０５との間に結合されているアップグレード・サーバ２０４を含む。
【００３０】
図１を更に参照すると、サービス・プロバイダ・インフラストラクチャ２００の一実施形態のＳＣＤ２０２は、ホスト・システム１０２のコンポーネントまたは機能を含む。代替実施形態では、サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５は、ホスト・システム１０２のコンポーネントまたは機能の上位装置として動作する。他の代替実施形態では、ホスト・システム１０２のコンポーネントまたは機能は、ＳＣＤ２０２のコンポーネントおよびサービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５間で分散されている。
【００３１】
一実施形態のサービス・プロバイダ・インフラストラクチャ２００は、移動電子デバイス、移動通信デバイス、セルラ電話機、パーソナル・ディジタル・アシスタント、コンピュータ、およびその他のプロセッサを用いたデバイスを含むクライアント・デバイス１２２上の多数のタイプのソフトウェア・ファイルまたはコンポーネント・アップグレードに、サービス・プロバイダのワイヤレス・インフラストラクチャのアップグレード・システム・コンポーネントおよび種々の機構によって対応する。これらのシステムは、新たなソフトウェアおよび改訂されたソフトウェアをソフトウェア流通業者から受け取り、新たなソフトウェアからアップグレード・ファイルを生成し、サービス・プロバイダ・インフラストラクチャを通じてアップグレード・ファイルをクライアント・デバイス１２２に転送することによって機能する。クライアント・デバイス１２２のアップグレード・クライアント１２６は、アップグレード・ファイルを用いて、クライアント・デバイス１２２上にホストする目標のソフトウェアを更新する。
【００３２】
一実施形態のＳＣＤ２０２は、ユーザ・インターフェースを設け、これによってソフトエア・プロバイダは、新たな埋め込みデバイス・ソフトウェア・コンポーネントを包装し、公表する。ＳＣＤ２０２の機能には、デバイス情報を登録すること、およびデバイス情報をソフトウェア・コンポーネント証明サーバに提出することが含まれる。また、ＳＣＤ２０２は、新たなＥＢＳＣおよび元のＥＢＳＣを受信し、新たなＥＢＳＣおよび元のＥＢＳＣを用いてファイル差を計算または生成し、埋め込みソフトウェアを登録および包装し、埋め込みソフトウェア・パッケージをソフトウェア・コンポーネント証明サーバ２０３に提出する。新たなソフトウェアまたは改訂したソフトウェアは、公表に続いて、ワイヤード・ワイヤレス、あるいは混成ワイヤード／ワイヤレス・ネットワーク結合部または接続部２２０を通じて、サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５に供給されるが、そのように限定されるのではない。
【００３３】
一実施形態のＳＣＤ２０２は、クライアント・デバイス製造業者の処理システム上にホストされている。代替実施形態では、ＳＣＤ２０２は、アプリケーションまたはシステム・ソフトウェア・プロバイダの処理システム上にホストしている。別の代替実施形態では、ＳＣＤ２０２は、サービス・キャリアまたはプロバイダの処理システム上にホストされており、例えば、アップグレード・コンポーネント２０３〜２０５上にホストされているか、またはそれらの間に分散されている。
【００３４】
サービス・プロバイダ・アップグレード・コンポーネント２０３〜２０５は、ソフトウェア・コンポーネント分配部２０２、クライアント・デバイス１２２、既存のゲートウェイ２１０や通信インフラストラクチャ２１２を含むサービス・プロバイダのインフラストラクチャ２０１〜１２８の既存のコンポーネント、請求書発行サーバ２１４、ロギング・サーバ２１６、および認証サーバ２１８間で結合されている。
【００３５】
ソフトウェア・コンポーネント証明サーバ２０３は、クライアント・デバイスの製造業者へのインターフェースを設け、したがって、デバイス製造業者からの埋め込みソフトウェア・パッケージに関する新たなデバイス情報を受信する。また、ソフトウェア・コンポーネント証明サーバ２０３は、承認されたソフトウェア・パッケージを再包装(repackage)しアップグレード・サーバに分配する。
【００３６】
アップグレード・マネージャ２０５は、ソフトウェア・コンポーネント証明サーバ２０３およびアップグレード・サーバ２０４の間でインターフェースとして機能しつつ、最適なデバイス管理のためにソフトウェアおよびデータのパッケージングを行い、遠隔変更通知(remote change notification)のスケジューリングを行い、更新ポリシ・モニタ・システムを制御する。更に、アップグレード・マネージャ２０５は、既存のインフラストラクチャのシステムとの統合を行う。
【００３７】
アップグレード・サーバ２０４は、認証、接続、移動クライアント・デバイス１２２との通信を含む機能を備えており、埋め込みソフトウェア・コンポーネントのアップグレードを行う。クライアント・デバイス１２２との通信は、クライアント・デバイス１２２との結合部２１２を介して行うことができる。この結合部２１２は、ワイヤレス結合部、ワイヤード結合部、混成ワイヤード／ワイヤレス結合部、および対応するサービス・プロバイダに適したその他のネットワーク結合形式を含む。加えて、アップグレード・サーバ２０４は、サービス・プロバイダの既存の請求書発行、データ収集、およびロギング・サービスにも対応する。
【００３８】
アップグレード・サーバ２０４およびクライアント・デバイス１２２間の通信の一例として、アップグレード・ファイルがアップグレード・サーバ２０４からクライアント・デバイス１２２に転送できるようになったときに、サーバ２０４はユーザ通知を送って、クライアント・デバイスのユーザに、更新に利用できるソフトウェア・コンポーネントがあることを通知する。ユーザ通知は、ショート・メッセージ・サービス（「ＳＭＳ」）プッシュ・プロトコル、ハイパーテキスト・トランスファ・プロトコル（「ＨＴＴＰ」）、またはワイヤレス・アプリケーション・プロトコル（「ＷＡＰ」）によるテキスト・メッセージの形態を取ることができるが、そのように限定されるのではない。ハンドセット・ユーザからの確認を受信すると、アップグレード・サーバ２０４は、元のハンドセット・データ通信プロトコルを用いて、アップグレード・ファイルを要求元のデバイスに送る。
【００３９】
そのデバイスからの確認の受信に応答して、アップグレード・サーバ２０４は、ユーザおよび／または要求元デバイスを認証および許可し、要求元デバイスの欠くことができない機能および制限を検証する。認証に続いて、アップグレード・サーバ２０４は、クライアント・デバイス・コンフィギュレーション・データのマネージャとして、要求元デバイス１０４の埋め込みソフトウェア・コンポーネントの現バージョンを特定し、該当するデルタ・ファイルを特定し要求元デバイス１０４に転送し、アップグレード・トランザクションのステータスを記録し、結果をアップグレード・マネージャ２０５に報告する。加えて、アップグレード・サーバ２０４は、オーバーディエアによってソフトウェア・アップグレード・サービスの活性化／不活性化を行い、遠隔ユーザにソフトエアの変更を通知する。
【００４０】
図１を参照すると、アップグレード・クライアント１２６は、クライアント・デバイス１２２に埋め込まれているが、そのように限定されるのではない。アップグレード・クライアント１２６は、クライアント・デバイス１２２のコンフィギュレーション・データを格納および維持し、埋め込みデバイス・ソフトウェア・コンポーネントの保守およびアップグレードを行う。アプグレード・クライアント１２６は、単純なユーザ・インターフェースに対応し、移動デバイス・ソフトウェア内に組み込まれる。実行時に、アップグレード・クライアント１２６は、いずれの埋め込みソフトウェア・コンポーネントの遠隔変更をも自動的に検出し、ユーザに埋め込みソフトウェア・コンポーネントのアップグレードを通知し、通信事業者(carrier)および／またはユーザ制御に基づいて、個々のサービス・プロバイダに対してしかるべく、ソフトウェア・コンポーネントをアップグレードする。
【００４１】
一実施形態のアップグレード・システム１００およびサービス・プロバイダ・インフラストラクチャ２００は、多数の形式のソフトウェア・ファイルまたはコンポーネント更新に対応し、実行可能ファイル、バイト・ストリーム・ファイル、およびデータ・ファイルに対する更新を含むが、そのように限定されるのではない。実行可能ファイル、または画像ファイルは、クライアント・デバイスにおいて用いられ、タスク、例えば、オペレーティング・システム（「ＯＳ」）を実行するソフトウェア・ファイル、ハードウェア・デバイス・ドライバ、およびＫ仮想機械（「ＫＶＭ」）ファイルを含む。バイト・ストリーム・ファイルは、その他の実行可能ファイル、例えば、アイコン・ファイル、ロゴ・ファイル、およびＭＰ３ファイルによって用いられるファイルを含む。データ・ファイルは、個人使用データ、およびハンドセット参照データを含むファイル、例えば、較正コンフィギュレーション・ファイル、プロトコル独立マルチキャスト（「ＰＩＭ」）ファイル、およびシステム・コンフィギュレーション・ファイルを含む。
【００４２】
一実施形態のアップグレード・クライアント１２６は、関連出願に記載されているように、アップグレードするファイル・タイプ、およびアップグレードに対応するためにクライアント・デバイスの製造業者が割り当てるリソースに応じて、ＥＢＳＣをアップグレードするために多数の方法を用いる。一実施形態のこれら更新方法は、非クリティカル・コンポーネントの更新、クリティカル・コンポーネントの更新、およびクライアント・コンポーネントの更新を含み、これらのカテゴリは、更新の目標であるソフトウェア・コンポーネントによって設けられる機能に基づく。
【００４３】
一般に、ソフトウェアのアップグレードは、前述のように、プログラムの新バージョンを旧バージョンと比較し、マシン・コードの変更または差異のみを分離する技法を使用することによってホスト・クライアント・デバイスのＲＯＭを書き直すのに要する時間を削減する。クライアント・デバイスのアップグレード・クライアントは、アップグレード・ファイル内において受信した、これら差異の情報を用いて、デバイスＲＯＭをアップグレードする。その際、ＲＯＭ全体を書き換えるのではなく、差異のみ、即ち変更したＥＢＳＣまたは画像の部分を書き換える。
【００４４】
差異ファイルを含むアップグレード・ファイルの使用に加えて、ＤＡおよびＤＡマネージャを用いたファイルのアップグレードの間に、クライアント・デバイスのプログラムをアップグレードするために必要なアップグレード・ファイルのサイズおよび時間の削減を達成することができる。一実施形態のＤＡは、デバイスＲＯＭ内に格納されているコードを、関連ＥＢＳＣのグループに編成することを含む。あるコンポーネントから別のコンポーネントへのいずれの参照でも、識別して、各コンポーネントの位置即ちアドレスと共に、ＤＡマネージャに格納する。ＤＡマネージャは、ＥＢＳＣをリンクするプロセスの間に生成され、クライアント・デバイス・プログラムと共に、クライアント・デバイス・メモリにロードする。したがって、ＤＡおよびＤＡマネージャは、画像のＥＢＳＣを孤立させ、独立して構築することを可能にする。
【００４５】
ＤＡマネージャは、コンポーネント関数コール、グローバル変数参照、および一定変数参照(constant variable reference)を管理し、集中ルータまたはスイッチボードとして機能し、クライアント・デバイスの各ＥＢＳＣのシンボル位置を把握し、クライアント・デバイス・プログラムの実行中に、必要に応じてＥＢＳＣをリンクする。あるＥＢＳＣから別のＥＢＳＣへのいずれの参照も、これらＥＢＳＣ間で直接行われる代わりに、ＤＡマネージャを介して導かれる。したがって、ファイル・アップグレードの最中にコンポーネントを修正し、アップグレードの結果、ＲＯＭ内においてＥＢＳＣの局所的な変化が生じた場合、この変化をＤＡマネージャが記録するので、クライアント・デバイス・プログラム内にあるＥＢＳＣへの参照即ち連結(linkage)の完全性を維持する。
【００４６】
ここに記載するＤＡマネージャは、例えば、ＡＲＭプロセッサ・コア、即ち、Ａｒｍ  Ｄｅｖｅｌｏｐｅｒ  Ｓｕｉｔｅ（ＡＤＳ）バージョン１．２ソフトウェア・パッケージをホストするプロセッサと共に実行するが、代替実施形態は種々の他のプロセッサ上／と共に実行することができる。一実施形態のＤＡおよびＤＡマネージャは、多数の埋め込みシステム・プラットフォームと互換性があり、ここに記載する埋め込みシステムだけと互換性があるのではない。
【００４７】
一実施形態のＤＡおよびＤＡマネージャの説明において多数の用語を用い、これらの用語の説明を一例として以下に行うが、実施形態はこれらの説明に限定されるのではない。ＤＡおよびＤＡマネージャについて説明する際、「画像」とは、プロセッサ上にロードする実行可能ファイルであり、代わりに「二進画像」または「ソフトウェア画像」とも呼ぶ。「セクション」とは、ソフトウェア・コードのブロックまたは画像のデータである。「領域」とは、１つから３つの出力セクションの隣接する連続体であり（画像のリード・オンリ・メモリ・アドレス（「ＲＯ」）、リード／ライト・メモリ・アドレス（「ＲＷ」）、およびゼロ初期化メモリ・アドレス（「ＺＩ」））、領域は、一般に、ＲＯＭ、ＲＡＭのような物理的メモリ・デバイス、および／または周辺機器にマップする。「ロード・ビュー」(load view)とは、メモリにロードされているがまだ実行を開始していない画像のセクションおよび領域のアドレスである。「実行ビュー」(execution view)とは、メモリにロードされ実行中の画像のセクションおよび領域のアドレスである。「散乱ロード」(scatter loading)は、単一の大きなブロックを用いるのではなく、個々にコードおよびデータ・セクションのアドレスおよびグループ化を割り当てることを含む。「ＲＯ−ＣＯＤＥ」は、リード・オンリ・コード・アドレスを意味する。［ＲＯ−ＤＡＴＡ」は、リード・オンリ・データ・アドレスを意味する。「ＲＷ−ＤＡＴＡ」は、リード／ライト・データ・アドレスを意味する。「ＺＩ−ＤＡＴＡ」は、初期値を有さない変数を保持するために用いられるゼロ初期化リード／ライト・メモリを意味する。「ｓｙｍｄｅｆファイル」とは、グローバル・シンボルおよび関連する最終実行時アドレスを含むシンボル定義ファイルである。
【００４８】
一実施形態のＤＡは、二進画像のＤＡマネージャにおける固定位置に共通コンポーネントを挿入することにより機能コール依存性を解消するように機能するので、コードの変更により機能コール宛先アドレスが変化したとき、コール側機能は、ＤＡマネージャの共通コンポーネントをコールし続け、ＤＡマネージャはそのコールを画像内のしかるべきコンポーネントに誘導する。ＤＡマネージャの共通コンポーネントの情報は、したがって、いずれの関数コール宛先アドレスの変更に応じて変化し、共通コンポーネントへの機能コールを、新しい宛先アドレスに誘導する。
【００４９】
ここに示す、コンポーネントに基づくメモリ管理の一例として、図３は、一実施形態の下におけるＤＡマネージャ３１０と画像３００のＥＢＳＣ、ＥＢＳＣ１／ＥＢＳＣ２／ＥＢＳＣ３との間の相互作用を示すＤＡのブロック図である。前述のように、一実施形態の画像は、ソフトウェア・コンポーネント（ＥＢＳＣ）および少なくとも１つのＤＡマネージャを含む。画像は、リンク・コンポーネント(linked component)を含み、ＥＢＳＣのようなコンポーネントは、独立して構築された画像を含み、その機能は故意に、特別に一緒にグループ化されている。画像を異なるコンポーネントに分割するので、以下で説明するように、１つのコンポーネントから他のコンポーネントへの関数コール、グローバル変数参照、および一定変数参照がある。
【００５０】
一実施形態のＤＡは、関数コールおよびグローバル参照を画像のコンポーネント間で識別し、個々のコンポーネント間の依存性を断ち切り、ソフトウェア・アップグレードまたは変更を画像に対して行うとき、ＤＡマネージャおよび修正されたコンポーネントのみをアップグレードするようにしている。ＤＡマネージャは、続いて、関数コールおよびグローバル参照を管理し誘導し直すことにより、画像の実行中コンポーネント間のアクティビティを制御または管理する。
【００５１】
ＤＡマネージャの一動作例として、図３を参照すると、動作をＥＢＳＣ１の関数２に誘導するＥＢＳＣ２におけるコール３５０が、ＤＡマネージャ３１０のコンポーネント３７０をコールする。一方、ＤＡマネージャ３１０のコールされたコンポーネント３７０は、動作３５２をＥＢＳＣ１の関数２に誘導する。ＤＡマネージャの別の動作例として、動作をＥＢＳＣ３の関数１に誘導するＥＢＳＣ１におけるコール３６０は、ＤＡマネージャ３１０のコンポーネント３８０をコールする。一方、ＤＡマネージャ３１０のコールされたコンポーネント３８０は、動作３６２をＥＢＳＣ３の関数１に誘導する。
【００５２】
この例について続けると、クライアント・デバイスのソフトウェア・アップグレードが、画像３００のＥＢＳＣ１に対する変更を必要とし、その結果メモリにおいてＥＢＳＣ１の位置が変更する場合、例えば、このアップグレードによって、ＥＢＳＣ１に関連するリンクを有するＥＢＳＣ１へのアップグレード、およびＤＡマネージャ３１０のコンポーネント３７０へのアップグレードのみが行われる。その結果、ＤＡマネージャ３１０は画像３００のＥＢＳＣ間の参照または連結の完全性を維持するように機能するので、ＤＡマネージャ３１０は、ＥＢＳＣ１のような特定のＥＢＳＣへのアップグレードのため、画像３００の全てのＥＢＳＣをアップグレードまたは書き換えるあらゆる必要性を軽減する。
【００５３】
画像３００のＥＢＳＣ間のリンクを管理する際、一実施形態のＤＡマネージャは、多数の技法を用いて、異なる種類のグローバル参照を管理する。即ち、ＤＡマネージャは、関数コールおよびグローバル変数を含むグローバル参照を管理するが、そのように限定されるのではない。
【００５４】
コンポーネントの関数コールは、一般に、相対的なオフセット・ジャンプ／分岐命令または絶対アドレス・ジャンプ／分岐命令のフォーマットとなっており、画像の１つ以上のその他のコンポーネント内に宛先オフセット／アドレスが位置する。二進コードは、リード・オンリ・コード・アドレスを含むＲＯ−ＣＯＤＥ／テキストセクションに位置する。実行ビュー・アドレスおよびコンポーネント境界に基づいて、関数コールは、コンポーネント間関数コール、またはコンポーネント内関数コールのいずれかに分類され処理される。これについて、以下に説明する。
【００５５】
コンポーネント間関数コールに関して、そしてジャンプ／分岐命令の特色の結果、一実施形態のＤＡマネージャは、ここではベクトル・テーブル（ＶＴ）と呼ぶ、集中ジャンプ・テーブルを含み、コンポーネント間関数コールを管理し、それに伴う誘導のし直しを扱う。実行中、あるコンポーネントから他のコンポーネント内に位置する関数に対して関数コールが行われると、以下に説明するように、ＶＴ内のエントリをコールすることになる。次いで、ＶＴはこのコールを、コールされたコンポーネント／関数に対応する、メモリ・デバイス内のしかるべき位置に誘導し直す。一例として、コンポーネント間関数コールに対して、ＶＴエントリのサンプルＡＲＭモード・コードが続くが、本実施形態はこのサンプル・コードに限定されるのではない。
【００５６】
【表１】
2007511816.tif 000003
【００５７】
コンポーネント間関数コールとは対照的に、コンポーネント内関数コール（コンポーネント内部のローカル関数への関数コール）は、コンポーネントに対するアップグレードの影響を受けない。コンポーネント内関数コールが影響を受けないのは、アップグレードの結果、コンポーネント全体がアップグレードされるので、コンポーネントのアップグレードは、コンポーネント内関数コールに対してしかるべきアップグレードを含むからである。したがって、コンポーネント内関数コールはＶＴを検索しない。更に、コンポーネント内関数コールのコール・シーケンスを実行する際にＶＴを用いないが、本実施形態はそのように限定されるのではない。
【００５８】
グローバル変数および一実施形態のＤＡおよびＤＡマネージャを用いた、関連する参照に移ると、グローバル変数には、３つのサブタイプがあり、グローバル定数変数、グローバルＲＷ変数、およびグローバルＺＩ変数を含む。グローバル定数変数は、画像コードのＲＯ−ＤＡＴＡ／．ｃｏｎｓｔセクションにあり、これらを「変数」と呼ぶが、デバイスＲＯＭから参照することができ、実行時における修正はできない。グローバルＲＷ変数は、ＲＡＭ変数であり、実行時に修正することができ、システムの初期化の間にそれらの初期値に設定される。グローバルＺＩ変数も、ＲＡＭ変数であり、実行時に修正することができ、そしてＲＷ変数とは対照的に、システムの初期化の間にゼロ（０）の値にクリアされる。
【００５９】
一実施形態のＤＡおよびＤＡマネージャは、ここでは「グローバル参照」と呼ぶ、コンポーネント間およびコンポーネント内グローバル参照の１つまたはその組み合わせを用いて、コンポーネントのグローバル変数への参照を管理する。コンポーネント間グローバル変数参照に関して、グローバル変数参照は、前述の関数コールとは異なる。何故なら、これは、ジャンプ／分岐命令の代わりに、直接アドレスの内容をロードするからである。
【００６０】
一実施形態のＤＡは、ＤＡマネージャの集中位置特定(centralized location)を用いてコンポーネント間グローバル参照を管理する。集中ＤＡ管理位置特定を用いて、あらゆるコンポーネント間グローバル定数変数、グローバルＲＷ変数、およびグローバルＺＩ変数を新たな種類のセクションに割り当てることができる。一例として、グローバル定数変数を、「ｇｌｏｂａｌＣｏｎｓｔ」セクションと呼ばれる新たなセクションに割り当てることができ、グローバルＲＷ変数を、「ｇｌｏｂａｌＲＷ」セクションと呼ばれる新たなセクションに割り当てることができ、グローバルＺＩ変数を、「ｇｌｏｂａｌＺＩ」セクションと呼ばれる新たなセクションに割り当てることができる。これらの新たなセクション／変数は、次に、リンク時に、ロード・ビューおよび実行ビュー双方に対して、集中セクションに分散ロード(scatter load)される。アップグレードの間不変のコンポーネントの変数のアドレスを維持するのは有用であるので、集中位置特定は、変数の位置を管理し検証し易くし、これによってＤＡマネージャのプロセス構築を簡略化する。
【００６１】
代替実施形態のＤＡおよびＤＡマネージャは、アクセス関数を用いて、コンポーネント間グローバル参照を管理する。アクセス関数は、ソース・コード・レベルで生成するラップ関数(wrap function)であり、グローバル変数の参照を関数コールに変換するので、これらの参照を処理するためにＶＴを用いることが可能となる。アクセス関数を用いるのに適した状況は、ソース・コードが利用できない場合、ソース・コードの変更が非常に望ましくない場合、およびコンポーネント間変数参照の数が非常に限られているため、別個のセクションが不要な場合を含む。
【００６２】
ファイルｆｏｏ．ｃにおけるアクセス関数の一例は、次の通りである。
【００６３】
【表２】
2007511816.tif 000004
【００６４】
そして、ファイルｆｏｏ．ｃまたはその他のファイルにおけるアクセス関数の一例は、次の通りである。
【００６５】
【表３】
2007511816.tif 000005
【００６６】
一例として、アクセス関数では、ＶＴエントリのサンプルＡＲＭモード・コードが続くが、本実施形態はこのサンプル・コードに限定されるのではない。
【００６７】
【表４】
2007511816.tif 000006
【００６８】
アクセス関数を用いる場合、前述のアクセス関数の１つを用いるために、「interCompGlobalVarA」への参照を変更する。
コンポーネント間変数とは対照的に、コンポーネント内変数、またはコンポーネント内部のローカル関数は、コンポーネントへのアップグレードによる影響を受けない。何故なら、コンポーネントのアップグレードは、コンポーネント内変数に対するしかるべきアップグレードを含むからである。したがって、コンポーネント内変数は、globalConst変数／セクション、globalRW変数／セクション、およびglobalZI変数／セクションを検索しない。更に、コンポーネント内部関数コールの一連の参照を行う際、globalConst変数／セクション、GlobalRW変数／セクション、およびglobalZI変数／セクションを用いないが、本実施形態はそのように限定されるのではない。
【００６９】
一実施形態のＤＡマネージャは、ＤＡマネージャを含む画像を生成する際に用いる画像構築プロセスを含む。一例として、図４Ａおよび図４Ｂは、一実施形態の下において、ＤＡマネージャを含む画像を構築する際のフロー図４００を示す。ＤＡ画像構築手順は、非常に信頼性が高く、誤りがない二進画像を生成し、この手順は概略的に、予備コンパイル段階、リンカ後段階、およびコード生成段階に分割することができるが、そのように限定されるのではない。画像構築の予備コンパイル段階は、ＤＡプロセスのために本来の構築環境を用意する。リンカ後段階は、ＤＡマネージャを含む画像を信頼性高く生成できるまで、多数回実行することができる。コード生成段階は、画像のＤＡマネージャ・コンポーネントのアセンブリ・コードを生成する。
【００７０】
一実施形態の構築プロセスが用いるリソースは、断面基準(Cross Section References)情報を備えた画像メモリ・マップ・ファイル、本来のコンポーネント認識分散ロード・ファイル、本来のコール・グラフ・ファイル、および第三者ライブラリ・オブジェクト・ファイルを備えた製造業者オブジェクト・ファイルを含む。代替実施形態は、追加のリソースおよび／または他の種類のリソースやその組み合わせを用いることができる。ＤＡマネージャを含む画像を構築するためには、ソース・コード・ファイルが利用できる必要はないが、ソース・コード・ファイルは、二進画像の動作、および実行時リソース要求に役立つことができる。
【００７１】
ＤＡマネージャを含む画像を構築する際のフロー図４００を参照する。クライアント・デバイスのコンポーネントは、構築プロセスを開始すると、ブロック４０２において、ＶＴのロード・ビューおよび実行ビュー、ならびにグローバル参照を含む、ＤＡマネージャをホストするデバイス・メモリ内の位置を指定する。クライアント・デバイスのコンポーネントは、ブロック４０４において、本来の画像マップ・ファイル、本来のコンポーネント認識分散ロード・ファイル、コール・グラフ・ファイル、および本来のソース・コード・ファイル（任意）の内少なくとも１つの情報を用いて、コンポーネント間関数コールおよびコンポーネント間グローバル変数参照を特定する。ブロック４０６において、特定したコンポーネント間関数コールおよびコンポーネント間グローバル変数参照の内少なくとも１つの情報を用いて、ＤＡマネージャのエントリが大き過ぎるために、デバイス・メモリの指定位置に納まらないか否か判定を行う。ＤＡマネージャは、一般に、クライアント・デバイス・メモリにおいて１ブロックのメモリを占有する、独立したコンポーネント即ちＥＢＳＣであるが、そのように限定されるのではない。
【００７２】
ブロック４０６において、ＤＡマネージャのエントリが大き過ぎて、デバイス・メモリの指定位置に納まらない場合、コンポーネント間参照を削減するために、コンポーネントの再配置を行う。コンポーネントの再配置は、ブロック４５０において、全てのコンポーネント間グローバル定数変数（ＲＯ＿ＤＡＴＡ）を新たなGlobalConstセクションに再グループ化するまたは再割り当てすることを含むが、そのように限定されるのではない。ブロック４５２において、元のソース・コード・ファイルが利用できるか否か判定を行う。元のソース・コード・ファイルが利用できる場合、ブロック４５４において、全てのコンポーネント間グローバルＲＷ変数（ＲＷ−ＤＡＴＡ）およびグローバルＺＩ変数（ＺＩ−ＤＡＴＡ）を、元のソース・コードにおいて、外部参照「ｅｘｔｅｒｎ」に変更即ち再定義する。ブロック４５６において、コンポーネント間グローバルＲＷ変数（ＲＷ−ＤＡＴＡ）およびグローバルＺＩ変数（ＺＩ−ＤＡＴＡ）の集中宣言を有する新たなソース・コード・ファイル（ｇｌｏｂａｌＩｎｔｅｒ．ｃ）を生成する。集中宣言は、グローバルＲＷ変数を新たなｇｌｏｂａｌＲＷセクションに割り当てること、およびグローバルＺＩ変数を新たなｇｌｏｂａｌＺＩセクションに割り当てることを含むが、そのように限定されるのではない。また、ブロック４５８において、分散ロード・ファイルも変更し、再グループ化したコンポーネント間グローバル定数変数（ｇｌｏｂａｌＣｏｎｓｔ）を、ｇｌｏｂａｌＲＷおよびｇｌｏｂａｌＺＩセクションと共に含むようにし、Ｍａｋｅファイルを修正する。新たなソース・コード・ファイル（ｇｌｏｂａｌＩｎｔｅｒ．ｃ）の生成に続いて、ブロック４７０において、新たなソース・コード・ファイルを再コンパイルし、オブジェクト・ファイルを再リンクする。次いで、動作はブロック４０２に戻り、ＶＴのロード・ビューおよび実行ビュー、ならびにグローバル参照を含む、ＤＡマネージャをホストするための位置をデバイス・メモリ内において指定する。
【００７３】
元のソース・コード・ファイルがブロック４５４、４５６、および４５８の動作のために利用できないとブロック４５２において判定した場合、ブロック４６０において、コンポーネント間参照を削減するためのコンポーネントの再配置（ブロック４５０）に続いて、アクセス関数を生成する。前述のように、アクセス関数は、グローバル変数の参照を、関数コールに変換する。アクセス関数の生成に続いて、ブロック４７０において、ソース・コード・ファイルを再コンパイルし、オブジェクト・ファイルを再リンクする。次いで、動作はブロック４０２に戻り、ＶＴのロード・ビューおよび実行ビュー、ならびにグローバル参照を含む、ＤＡマネージャをホストするための位置をデバイス・メモリ内において指定する。ブロック４５０〜４７０の動作は、ＤＡマネージャ・エントリのサイズがデバイス・メモリにおいて指定された位置に納まるまで（ブロック４０６）、クライアント・デバイスのコンポーネントによって繰り返される。
【００７４】
ＤＡマネージャのエントリが、デバイス・メモリ内に指定された位置に納まったとブロック４０６において判定されたようなとき、動作は続いてブロック４０８において、各コンポーネントのコンポーネント間関数コールに対してＶＴソース・コードを生成する。また、ブロック４１０において、クライアント・デバイスは、コンポーネント毎に、新たなまたは修正した分散ロード・ファイルを生成する。更に、ブロック４１２において、クライアント・デバイスは、コンポーネント毎に、シンボル定義ファイルｓｙｍｄｅｆを生成する。ここで、各ｓｙｍｄｅｆファイルは、ＶＴテーブル・エントリ・アドレスを用いて、対応するコンポーネントに対して外部参照を定義する。ｓｙｍｄｅｆファイルは、ＶＴにおいて用いられないコンポーネントには不要である。ブロック４０８、４１０、および４１２の動作は、元の画像マップ・ファイルおよび修正した分散ロード・ファイルの少なくとも一方の情報を用いるが、そのように限定されるのではない。
【００７５】
続いて、クライアント・デバイスの動作は、ブロック４１４において、画像のコンポーネントをコンパイル／アセンブルし再リンクし、コンポーネント毎に画像およびメモリ・マップを生成する。一実施形態の再リンク動作は、ＤＡマネージャ・コンポーネントへのリンクを含まないが、そのように限定されるのではない。また、ブロック４１６において、クライアント・デバイスは、最終シンボル位置を含む、ＤＡマネージャ・コンポーネントのｓｙｍｄｅｆファイルを生成する。ブロック４１８において、クライアント・デバイスは、次に、ＶＴオブジェクト・ファイルを各コンポーネントのローカル・シンボルと共にコンパイルし、再リンクして、ＶＴコンポーネント画像を生成する。また、ブロック４２０において、クライアント・デバイスは、ＤＡマネージャ・コンポーネントをコンパイルおよびリンクして、ＤＡマネージャ画像を生成する。ブロック４２２において、ＤＡマネージャ画像を含む画像をクライアント・デバイス・メモリにロードする。
【００７６】
クライアント・デバイスを製造した後に、クライアント・デバイスの特定のまたは予め指定したコンポーネントへのアップグレードを含むソフトウェア・アップグレードを実行する場合、一実施形態のクライアント・デバイスは、前述のＤＡを用いる。アップグレードしたコンポーネントの１つ以上がコンポーネント間参照を含む場合、ソフトウェア・アップグレードの間、前述の構築プロセスを用いて、ＤＡマネージャを変更即ちアップグレードする。
【００７７】
画像の新バージョンを生成したクライアント・デバイスのソフトウェア・アップグレードの間、前述の構築プロセスは、アップグレードしたコンポーネントの画像を生成する。修正されないコンポーネントは、それらの以前のバージョンと同一のはずであるが、コンポーネント間関数コールに対応するＤＡマネージャのエントリを検証しなければならない。コードの変更により対応する元のコンポーネントに納まらなくなった、新たなコンポーネント間関数コールおよびグローバル変数は、画像の最終バージョンが占有するロットの端部に追加するが、そのように限定されるのではない。更に、ＤＡマネージャの既存のシンボル全ては、特に指定されていない限り、その元のアドレスを保持している。
【００７８】
ＤＡマネージャの構築に続いて、ＤＡマネージャは、集中ルータまたはスイッチボードとして機能し、必要に応じて、クライアント・デバイス・プログラムの実行中に、各ＥＢＳＣおよびリンクＥＢＳＣのシンボル位置を把握する。１つのＥＢＳＣから別のＥＢＳＣへのいずれの参照も、直接ＥＢＳＣ間で行う代わりに、ＤＡマネージャを介して導かれる。ファイル・アップグレードの間にコンポーネントを修正し、アップグレードの結果ＲＯＭにおいてＥＢＳＣの位置が変化した場合、この変化をＤＡマネージャが記録し、こうしてデバイス・プログラム内にあるＥＢＳＣに対する参照または連結の完全性を維持する。
【００７９】
前述のように、ファイルの改訂は、新たなそして更新したＥＢＳＣをホスト・デバイスのメモリ位置に書き込むことを伴う。多くの場合、新たなＥＢＳＣは、それと交換する元のＥＢＳＣとは正確に同じサイズではく、正確に同じ開始アドレスも有さない。一実施形態のアップグレード・クライアントは、デバイス・メモリ管理の選択肢を備えており、ＥＢＳＣサイズまたは開始アドレスには関係なく、新たなＥＢＳＣの書き込みに対処するアップグレード可能なＥＢＳＣのＤＡを含む。
【００８０】
デバイス・メモリのコンポーネントのアップグレードの間にＤＡを用いるデバイス・メモリの一例として、図５は、デバイス・メモリ１３０のブロック図であり、図１および図３の実施形態の下における、ソフトウェア画像３００のコンポーネントを含むメモリ１３０のコンポーネント（埋め込みソフトウェア・エリアにおける）、アップグレード・クライアント１２６、およびＤＭＭクライアント５００間における相互作用の一例を示す。一実施形態のデバイス・メモリ１３０はフラッシュＲＯＭであるが、デバイス・メモリ１３０のこの実施形態または代替実施形態では、多くの形式のメモリおよび／またはメモリ形式の組み合わせを使用することができる。
【００８１】
一実施形態のＤＭＭクライアント５００は、ＤＭＭライブラリ５１０、ＶＴ５１２、およびガベージ・コレクション５１４を含むが、そのように限定されるのではない。ＶＴ５１２は、ＤＭＭクライアント５００の一コンポーネントとして示されているが、ＶＴ５１２は、ＤＡマネージャ３１０と同じ位置に配置してもよく、あるいは画像３００またはＤＭＭクライアント５００の別のセクションでもよい。ＤＭＭライブラリ５１０は、関数アドレス変換アプリケーション・プログラマ・インターフェース（「ＡＰＩ」）５２０、予約ＡＰＩ５２２、およびガベージ・コレクションＡＰＩ５２４の内１つ以上を含む。ＤＭＭライブラリ５１０は、関数アドレス変換ＡＰＩ５２０、予約ＡＰＩ５２２、およびガベージ・コレクションＡＰＩ５２４の内１つ以上との何らかの組み合わせで、１つ以上の追加のＡＰＩを含んでもよい。
【００８２】
ソフトウェア・アップグレードの間、ＤＡは、より進んだメモリ管理を可能にしつつ、全体的に各更新の間ＥＢＳＣおよびＥＢＳＣグループの開始アドレスおよびサイズ双方の変更に対応する。一実施形態のアップグレード・クライアントは、ＤＭＭクライアント５００のＡＰＩおよび少なくとも１つのデータ・テーブル間の相互作用を用いて、ダイナミック・アドレシングに対応する。したがって、ＤＡは、ＲＯＭ利用およびデバイス・メモリ・マップ設計の効率を高めつつ、更新処理の高速化、および更新失敗の確率低下に対応する。
【００８３】
ＤＡを用いてメモリ管理を行う際、アプグレード・クライアントは、少なくとも１つの第１および第２メモリ・エリアを含むホスト・デバイス・メモリ・エリアの連続探索を行うことにより、新たなソフトウェア・コンポーネントを収容できるだけの十分に大きいメモリ・ブロックを特定し予約する。新たなコンポーネント・サイズが、探索したメモリ・エリアの利用可能なブロックのそれを超過する場合、アップグレード・クライアントは、未使用のメモリ・ブロックを排除するように第１メモリ・エリアを書き換え、第１および第２メモリ・エリアを割り当てし直し、新たなコンポーネントを第２メモリ・エリアに書き込み、ベクトル・テーブルを更新する。これについては、以下で説明する。
【００８４】
図６は、一実施形態の下において、ダイナミック・アドレシングを用いてＥＢＳＣまたはＥＢＳＣグループをアップグレードする際のフロー図６００である。アップグレード・クライアントは、ブロック６０２において、新ＥＢＳＣバージョンを受信する。新ＥＢＳＣバージョンは、元のＥＢＳＣバージョンおよび対応するアップグレード・ファイルから生成するか、あるいはソフトウェア・コンポーネント流通業者から受信する。ブロック６０４において、新ＥＢＳＣバージョンの格納に対処するために、クライアント・デバイス内でメモリ・エリアを特定し予約する。ブロック６０６において、アップグレード・クライアントのコンポーネントは、新ＥＢＳＣバージョンを予約したメモリ・エリアに書き込む。ブロック６０８において、新ＥＢＳＣバージョンに起因するあらゆる必要な変更をＶＴの情報に行うために、ＶＴに対して更新を行う。また、ブロック６１０において、新ＥＢＳＣバージョンの書き込みに起因する、未使用メモリ・エリアのあらゆる変化を反映するために、ガベージ・テーブルに更新を行う。
【００８５】
ＤＡを用いてクライアント・デバイスにおいてソフトウェア・コンポーネントにアクセスするために、アップグレード・クライアントは、対応するソフトウェア・コンポーネントの識別情報を含む関数コールを、クライアント・デバイスの主プログラムから受け取り、ＶＴから対応するソフトウェア・コンポーネントのスタート・アドレスを読み取り、対応するソフトウェア・コンポーネントに対するコールを生成する。したがって、第１ＥＢＳＣが第２ＥＢＳＣをコールすると、アップグレード・クライアントは関数コール・シーケンスを変更し、スタティック・アドレスを用いて直接第２ＥＢＳＣをコールする代わりに、第１ＥＢＳＣがスタティック・アドレスを用いてアップグレード・クライアントのＡＰＩをコールするようにする。コールされたＡＰＩは、ランタイムＶＴの対応するスタティック・アドレスおよび引数を用いて、受け取ったコールを第２ＥＢＳＣのコールに変換する。
【００８６】
図７は、一実施形態の下における、ＤＡを用いた関数コールのフロー図７００である。ホスト・デバイスの主プログラムは、デバイス・メモリ内に格納されているＥＢＳＣを用いて、ユーザが要求する機能に対応する。ユーザによって機能が要求された場合、クライアント・デバイスの主プログラムのＥＢＳＣは、スタティック・アドレスを用いて、アップグレード・クライアントのコンポーネントを直接コールすることによって、特定の機能と関連付けられたＥＢＳＣをコールする。ブロック７０２において、コールに応答して、アップグレード・クライアントは、主プログラムから、関数またはＥＢＳＣ識別、およびこの機能に対する引数を含む情報を受ける。ブロック７０４において、アップグレード・クライアントはＶＴにアクセスする。ＶＴは、主プログラムに利用可能なＥＢＳＣ毎のエントリを、当該ＥＢＳＣの対応する開始アドレスと共に含む。アップグレード・クライアントは、ブロック７０６において、開始アドレスと、関連する引数をＶＴから読み出す。開始アドレス情報を、主プログラムから受け取った、コールされＥＢＳＣの情報と共に用いて、アップグレード・クライアントは、ブロック７０８において、実際の関数に対するコール、および対応するＥＢＳＣを、受信した全ての引数と共に生成する。
【００８７】
図５およびメモリ１３０のコンポーネント間の相互作用に戻り、関数アドレス変換ＡＰＩ５２０は、図７を参照して先に説明したように、特定のホスト・デバイス関数に伴うＥＢＳＣに対して、クライアント・デバイスの主プログラム１３２からコールを生成する。クライアント・デバイスの主プログラム１３２は、直接関数アドレス変換ＡＰＩ５２０をコールすることによって、特定の関数に伴うＥＢＳＣをコールする。ＡＰＩ５２０の直接コールは、ＥＢＳＣの直接コールの代わりに行われる。コールの時点において、関数アドレス変換ＡＰＩ５２０は、主プログラム１３２から、関数識別情報およびこの関数に対する引数を含む情報を受け取る。
【００８８】
コールに応答して、関数アドレス変換ＡＰＩ５２０は、ＶＴ３１２にアクセスする。ＶＴ５１２は、主プログラム１３２に利用可能な関数毎のエントリを、デバイス・メモリ１３０における当該関数の対応する開始アドレスと共に含む。関数アドレス変換ＡＰＩ５２０は、主プログラム１３２が要求する関数の開始アドレスをＶＴ５１２から読み取り、この開始アドレス情報を、主プログラム１３２から受け取った、コールされたＥＢＳＣの情報と共に用いて、実際の関数に対するコールを、受け取った全ての引数と共に生成する。
【００８９】
一実施形態のアップグレード・クライアント１２６は、ここでは予約ＡＰＩ５２２と呼ぶ、ＥＢＳＣ５２２の新バージョンの予約のためにＡＰＩを用いて、ＥＢＳＣまたはＥＢＳＣグループの新バージョンを収容するために、メモリ内のエリアを特定し予約する。図５を参照すると、予約ＡＰＩ５２２は、アップグレード・クライアント１２６によってコールされると、新ＥＢＳＣバージョンに対する識別情報、この新バージョンのファイル・サイズを含む情報を受け取る。新ＥＢＳＣバージョンのファイル・サイズは、新ＥＢＳＣバージョンを格納するためにデバイス・メモリ１３０に予約すべきエリアのサイズである。予約ＡＰＩ５２２は、メモリ１３０内にしかるべきエリアを特定し、メモリ・エリアの予約に成功すると、要求した予約エリアの開始アドレスを戻す。図８は、一実施形態の下において、予約ＡＰＩ５２２を用いて、ＥＢＳＣの新バージョンを収容するためのメモリ・エリアを予約する際のフロー図である。
【００９０】
要求されたサイズのメモリ・ブロックを割り当てる際、予約ＡＰＩ５２２は、１組のルールを以下のように適用するが、代替実施形態では、異なるルールを適用して同等の結果を得ることもできる。図９は、一実施形態の下において、予約ＡＰＩのルールを用いてＥＢＳＣの新バージョンを収容するためのメモリ・ブロックを突き止める際のフロー図９００である。ブロック９０２において、新たなＥＢＳＣのサイズに関する情報を受けると、予約ＡＰＩは、新たなＥＢＳＣのサイズが元のＥＢＳＣのそれを超過するか否か、ブロック９０４において判定を行う。新たなＥＢＳＣのサイズが対応する元のＥＢＳＣのサイズ以下であれば、ブロック９０６において、予約ＡＰＩは、対応する元のＥＢＳＣが現在占有しているメモリ・ブロックを、新たなＥＢＳＣを受けるために割り当てる。そうでなければ、予約ＡＰＩは、要求されたサイズを有するメモリ・ブロックを、予約されているメモリ・エリア内にある使用可能なメモリから突き止めようとする。
【００９１】
探索を続ける際、予約ＡＰＩは、ブロック９０８において、クライアント・デバイスの予約されているメモリ・エリアを探索し、要求されたサイズを有するメモリ・ブロックを求める。適切なサイズのブロックが予約メモリ・エリア内で見つかった場合、ブロック９１０において、予約ＡＰＩはそのメモリ・ブロックを、新たなＥＢＳＣを受け取るために割り当てる。予約メモリ・エリア内に適切なサイズのメモリ・ブロックが得られない場合、ブロック９１２において、予約ＡＰＩはガベージ・テーブルにアクセスする。ブロック９１４において、予約ＡＰＩは、ガベージ・テーブル内のエントリに対応する未使用エリア間で、要求されたサイズのメモリ・ブロックを突き止める試みの中で、ガベージ・テーブルの情報を用いて、主メモリ・プログラムの未使用メモリ・エリアを探索する。一実施形態の未使用エリアを、ここではガベージ・エリアと呼び、主プログラムの未使用エリアを含むが、実施形態はそのように限定されているのではない。適切なサイズのメモリ・ブロックが未使用メモリ・エリア内で見つかった場合、ブロック９１６において、予約ＡＰＩはそのブロックを、新たなＥＢＳＣを受け取るために割り当てる。
【００９２】
一実施形態の予約ＡＰＩは、適切なサイズのメモリ・ブロックを突き止めることができない場合、ブロック９１８において、ガベージ・コレクションとここでは呼ばれているプロセスを開始する。また、予約ＡＰＩは、ガベージ・テーブルのエントリ全てが塞がっているときにも、ガベージ・コレクションを開始する。図５を参照すると、ガベージ・コレクション用ＡＰＩ５２４は、ここではガベージ・コレクションＡＰＩ５２４と呼ぶが、予約ＡＰＩ５２２によってコールされるが、そのように限定されるのではない。ガベージ・コレクション用ＡＰＩ５２４は、一般に引数を受け取らず、ＥＢＳＣおよびＥＢＳＣ更新のために予約したエリアにおける全てのガベージを消去するが、そのように限定されるのではない。
【００９３】
前述のように、予約ＡＰＩ５２２は、要求された予約サイズに十分なメモリを見つけることができない場合、またはガベージ・エントリ・テーブルが満杯になったときに、ガベージ・コレクションを開始する。図１０は、一実施形態の下におけるガベージ・コレクションのフロー図１０００である。ガベージ・コレクションを開始する際、予約ＡＰＩはガベージ・コレクションＡＰＩをコールする。コールされると、ブロック１００２において、ガベージ・コレクションＡＰＩはガベージ・テーブル・エントリを読み取り、ブロック１００４において、デバイス・メモリの埋め込みソフトウェア・エリアを書き直させ、メモリのＥＢＳＣを順次メモリの上に向かってパックしていく。代替実施形態では、ＥＢＳＣを主メモリの下に向かってパックしてもよいが、実施形態はそのように限定されているのではない。このパッキング処理により、埋め込みソフトウェア・エリアにおける未使用エリアを除去する。
【００９４】
このパッキング処理に続いて、ガベージ・コレクションＡＰＩは、ブロック１００６において、予約メモリ・エリアに格納されている各ＥＢＳＣのサイズを評価し、そのサイズを、その書き直し以後における埋め込みソフトウェア・エリアの主プログラムに残っているあらゆる未使用メモリ・ブロックと比較する。この評価は、埋め込みソフトウェア・エリアの書き換えの後に残っている未使用メモリの量が、予約メモリ・エリアのいずれのＥＢＳＣでも収容可能であり、可能であれば、ＥＢＳＣを予約メモリ・エリアから、デバイス・メモリの埋め込みソフトウェア・エリアに移動させることができるか否か判定を行う。予約メモリ・エリアのＥＢＳＣは順次評価されるが、実施形態はそのように限定されるのではない。ブロック１００８において、ＥＢＳＣは、予約メモリ・エリアからＥＢＳＣのサイズが許す埋め込みソフトウェア・エリアに書き直される。一実施形態において、ＥＢＳＣが書き直されると、これらは順次、パックされたＥＢＳＣに続いて埋め込みソフトウェア・エリアに格納される。
【００９５】
予約メモリ・エリアに格納されたＥＢＳＣの評価は、全てのＥＢＳＣを埋め込みソフトウェア・エリアに移動し終えるまで、または埋め込みソフトウェア・エリア内に、予約メモリ・エリアのＥＢＳＣを収容できる程大きな埋め込みソフトウェア・エリアが残っていないと判定されるまで継続する。埋め込みソフトウェア・エリア内に収容することができないＥＢＳＣはいずれも、予約メモリ・エリア内に残るが、実施形態はそのように限定されるのではない。
【００９６】
パッキングおよび移動処理が完了すると、ブロック１０１０において、ガベージ・コレクションＡＰＩは、ホスト・デバイスの主メモリの未使用メモリ・ブロックを予約メモリ・エリアとして指定し直すことにより、ホスト・デバイス・メモリを再分配する。更に、ステップ１０１２において、予約メモリ・エリア・ポインタをリセットして、予約メモリ・エリア内で使用可能なメモリの開始アドレスを維持する。加えて、ブロック１０１４において、ガベージ・テーブルを書き直し、未使用メモリ・エリアのステータスを反映させる。また、アップグレード・クライアントは、同じＥＢＳＣの元のバージョンが占有するメモリ・エリア以外のいずれかのメモリ・エリアへのＥＢＳＣの新たなバージョンの書き込みの後に、ベクトル・テーブルを更新する。
【００９７】
図１１は、一実施形態の下において、動的アドレシングを用いた埋め込みソフトウェアの開発および展開プロセスのブロック図１１００である。この図１１００は、ソフトウェア・コンポーネント分配部１１０２によるＥＢＳＣの開発から、ＤＡに基づくデバイス・メモリ管理を行う一実施形態のアップグレード・クライアントを用いたデバイスＲＯＭの初期化までのプロセスを示す。
【００９８】
ソフトウェア・コンポーネント分配部１１０２のコンポーネントは、新ＥＢＳＣのソース・コードを受信し、前述のように、ソース・コードをクライアント・デバイスに配信する。クライアント・デバイスは、新ＥＢＳＣソース・コードをコンパイルする（１１０３）。ソース・コードのコンパイル（１１０３）に続いて、得られたＥＢＳＣオブジェクト・コードは、第１リンカ１１０６に転送し、第１リンカ１１０６は、新ＥＢＳＣの登録の一部として、新ＥＢＳＣに対応するマップ・ファイル１１０４を生成する。
【００９９】
ベクトル生成ツール１１０５は、マップ・ファイル１１０４の情報を用いて、ＥＢＳＣに対応する初期ＶＴ１１０８を生成し、ＶＴ１１０８を第２リンカ１１１６に転送する。第２リンカ１１１６は、ＶＴ１１０８をマップ・ファイル１１０４の情報と共に、更に第１リンカ１１０６からの元の画像マップ・ファイルの情報を用いて、１６進（テキスト）または二進ファイル１１１８を生成する。
【０１００】
１６進（テキスト）または二進ファイル１１１８は、クライアント・デバイス１２２の埋め込みソフトウェア・エリア１１２０内にダウンロードされるが、代替実施形態では、１６進ファイル１１１８をクライアント・デバイス１２２の他のメモリ・エリアに書き込むこともできる。クライアント・デバイス１２２のＤＭＭクライアントのコンポーネントは、後続のクライアント・デバイス・ソフトウェアのソフトウェア・アップグレードの間、ベクトル・テーブル１１０８を保持し、したがってＥＢＳＣのダイナミック・アドレシングに対応する。
【０１０１】
図４Ａおよび図４Ｂを参照すると、フロー図の動作が、少なくとも１つのプロセッサの制御の下で行われるが、そのように限定されるのではない。これらのフロー図に示されているブロックの各々は、当技術分野では周知の種類であり、それ自体が含むことができる一連の動作は、ここでは説明する必要はない。当業者は、これらのフロー図、およびこの中で行った詳細な説明に基づいて、ソース・コード、マイクロコード、プログラム・ロジック・アレイを作成することができ、あるいはそれ以外でもブロック機能を実現することができる。これらのフロー図にしたがって動作するアルゴリズムまたはルーチンは、関連するプロセッサの一部をなす不揮発性メモリ内、関連するメモリ・エリア内、ディスクのような着脱可能媒体内に格納するか、あるいはハードワイヤ状とするか、電子的消去可能プログラム可能ＲＯＭ（「ＥＥＰＲＯＭ」）半導体チップのようなチップ内またはこれらのコンポーネントのいずれかの組み合わせに予めプログラムするが、そのように限定されるのではない。
【０１０２】
前述の集中ＤＡマネージャのコンポーネントは、共に動作する計算コンポーネントおよびデバイスのあらゆる集合体を含む。ＤＡマネージャのコンポーネントは、更に大きなコンピュータ・システムまたはネットワーク内にあるコンポーネントまたはサブシステムとすることもできる。また、ＤＡマネージャのコンポーネントは、あらゆる数のコンポーネント（図示せず）、例えば、他のバス、コントローラ、メモリ・デバイス、データ入出力（Ｉ／Ｏ）デバイスの間でも、いずれの数の組み合わせでも結合することができる。ＤＡマネージャ・コンポーネントの機能は、あらゆる数／組み合わせの他のプロセッサ系のコンポーネントの間で分散することもできる。前述のメモリ・システムは、例えば、当技術分野では公知の種々のメモリ・システムを含む。
【０１０３】
ここに記載するＤＡおよびＤＡマネージャは、ダイナミック・アドレシング・マネージャと、プロセッサに結合されている複数のソフトウェア・コンポーネントとを備えている携帯通信デバイスを含み、ダイナミック・アドレシング・マネージャが１つ以上のリンクを含む、各リンクが、コンポーネントにおいて識別された各参照と、この識別された参照に対応するソフトウェア・コンポーネントの別の１つとの間にプログラム・リンクを形成し、ダイナミック・アドレシング・マネージャが、コードの実行中リンクを用いて複数のソフトウェア・コンポーネントをリンクする。
【０１０４】
一実施形態の各リンクは、ダイナミック・アドレシング・マネージャにおいて固定アドレスを有する。
一実施形態の参照は、関数コールおよび変数参照の内少なくとも一方を含む。
【０１０５】
一実施形態の変数参照は、グローバル変数参照および定数変数参照の内少なくとも一方を含む。
一実施形態のダイナミック・アドレシング・マネージャは、関数コールおよび変数参照の少なくとも一方についての集中ジャンプ・テーブルである、ベクトル・テーブルを備えている。
【０１０６】
一実施形態の複数のソフトウェア・コンポーネントをリンクする場合、第１コンポーネントからベクトル・テーブルのエントリに参照を誘導すること、およびエントリの情報を用いて、参照を第２コンポーネントに誘導し直すことの少なくとも一方から成る。
【０１０７】
一実施形態のダイナミック・アドレシング・マネージャは、少なくとも１つの集中セクションを備えている。一実施形態の変数参照を集中セクションに割り当てる。一実施形態の複数のソフトウェア・コンポーネントをリンクする場合、変数参照への参照を、変数参照に対応する集中セクションのアドレスに誘導することを含む。
【０１０８】
一実施形態のデバイスは、更に、アップグレード・クライアントを備えており、アップグレード・クライアントは、複数のソフトウェア・コンポーネントをアップグレードし、アップグレードは、ワイヤレス結合を介してアップグレード・ファイルを受信すること、アップグレード・ファイルの内容に対して適切に、複数のソフトウェア・コンポーネントの少なくとも１つをアップグレードすること、ダイナミック・アドレシング・マネージャのリンクの情報をアップグレードすることにより、複数のソフトウェア・コンポーネント間でリンクをアップグレードすることの内少なくとも１つを含む。
【０１０９】
一実施形態のデバイスは、更に、１つ以上のメモリ・エリアを含むメモリを備えており、ダイナミック・アドレシング・マネージャをメモリに格納してある。一実施形態のメモリは、ランダム・アクセス・メモリおよびリード・オンリ・メモリの内少なくとも一方を含む。
【０１１０】
一実施形態のクライアント・デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つである。
ここに記載するＤＡおよびＤＡマネージャは、クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成するステップと、複数のコンポーネントの各々に含まれている１つ以上の参照を識別するステップであって、各参照がコードの１つ以上の他のコンポーネントに対する参照である、ステップと、１つ以上のリンクを含むマネージャ・コンポーネントを生成するステップであって、各リンクが、１つのコンポーネントにおいて識別された各参照と、識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成する、ステップと、コードの実行中に、マネージャ・コンポーネントのリンクを用いて、複数のコンポーネントをリンクするステップとの内少なくとも１つを備えている方法を含む。
【０１１１】
一実施形態の各リンクは、マネージャ・コンポーネントにおいて固定アドレスを有する。
一実施形態の参照は、関数コール、グローバル変数参照、および定数変数参照の内少なくとも１つを含む。
【０１１２】
一実施形態の参照は、相対オフセット・ジャンプ／分岐命令、および絶対オフセット・ジャンプ／分岐命令の少なくとも一方を含む。
一実施形態の参照は、グローバル定数変数、グローバル・リード／ライト・データ・アドレス、およびグローバル・ゼロ初期化データ・アドレスの内少なくとも１つを含む。
【０１１３】
一実施形態のマネージャ・コンポーネントを生成するステップは、更に、関数コールおよびグローバル変数の少なくとも一方に対する集中ジャンプ・テーブルである、ベクトル・テーブルを生成するステップを含む。一実施形態の複数のコンポーネントをリンクするステップは、更に、第１コンポーネントからベクトル・テーブルのエントリに参照を誘導するステップと、エントリの情報を用いて、参照を第２コンポーネントに誘導し直すステップとの少なくとも１つを含む。一実施形態の参照は、関数コールおよび変数の少なくとも一方を含む。
【０１１４】
一実施形態のマネージャ・コンポーネントを生成するステップは、更に、マネージャ・コンポーネントの少なくとも１つの集中セクションを生成するステップと、グローバル定数変数を生成した集中セクションに割り当てるステップとの少なくとも１つを含む。一実施形態の複数のコンポーネントをリンクするステップは、更に、グローバル定数変数への参照を、グローバル定数変数に対応する集中セクションのアドレスに誘導するステップを含む。一実施形態のマネージャ・コンポーネントを生成するステップは、更に、グローバル・リード／ライト・データ・アドレスを生成した集中セクションに割り当てるステップを含んでもよい。一実施形態の複数のコンポーネントをリンクするステップは、更に、グローバル・リード／ライト・データ・アドレスへの参照を、グローバル・リード／ライト・データ・アドレスに対応する集中セクションのアドレスに誘導するステップを含んでもよい。また、一実施形態のマネージャ・コンポーネントを生成するステップは、更に、グローバル・ゼロ初期化データ・アドレスを生成した集中セクションに割り当てるステップを含んでもよい。また、一実施形態の複数のコンポーネントをリンクするステップは、更に、グローバル・ゼロ初期化データ・アドレスへの参照を、このグローバル・ゼロ初期化データ・アドレスに対応する集中セクションのアドレスに誘導するステップを含んでもよい。
【０１１５】
一実施形態の方法は、更に、クライアント・デバイスの１つ以上のメモリ・エリアに、マネージャ・コンポーネントを格納するステップを含む。一実施形態のメモリ・エリアは、ランダム・アクセス・メモリおよびリード・オンリ・メモリの少なくとも１つにおけるエリアを含む。
【０１１６】
一実施形態の方法は、更に、コードをアプグレードするステップを含み、このアップグレードは、ワイヤレス結合を介して、アップグレード・ファイルを受信するステップと、アップグレード・ファイルの内容に対して適切なように、複数のコンポーネントの少なくとも１つをアップグレードするステップと、マネージャ・コンポーネントをアップグレードすることにより、アップグレードしたコードの複数のコンポーネント間でリンクをアップグレードするステップとの内少なくとも１つを含む。
【０１１７】
一実施形態のクライアント・デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つである。
ここに記載するＤＡおよびＤＡマネージャは、アップグレード・ファイルを生成する第１アップグレード・コンポーネントを含む第１デバイスであって、アップグレード・ファイルが、電子ファイルにおけるエラーを修復するための情報と、電子ファイルに機能性を追加するための情報の内少なくとも一方を含む、第１デバイスと、第２アップグレード・コンポーネントと、ダイナミック・アドレシング・マネージャと、複数のソフトウェア・コンポーネントとを備えている移動通信デバイスの内少なくとも一方を備えているシステムを含み、ダイナミック・アドレシング・マネージャが１つ以上のリンクを含み、各リンクが、１つのコンポーネントにおいて識別される各参照と、識別された参照に対応するソフトウェア・コンポーネントの別の１つとの間にプログラム・リンクを形成し、ダイナミック・アドレシング・マネージャが、コードの実行中、リンクを用いて、複数のソフトウェア・コンポーネントをリンクする。
【０１１８】
一実施形態のシステムは、更に、ワイヤレス結合を備えており、第２アップグレード・コンポーネントは、ワイヤレス結合を介して、アップグレード・ファイルを受信し、第２アップグレード・コンポーネントは、アップグレード・ファイルの情報を用いて、複数のソフトウェア・コンポーネントを自動的にアップグレードする。一実施形態のアップグレードは、アップグレード・ファイルの内容に対して適切に、複数のソフトウェア・コンポーネントの少なくとも１つをアップグレードすることと、ダイナミック・アドレシング・マネージャのリンクの情報をアップグレードすることにより、複数のソフトウェア・コンポーネント間でリンクをアップグレードすることとから成る。
【０１１９】
一実施形態のシステムは、ダイナミック・アドレシング・マネージャにおいて固定アドレスを有するリンクを含む。
一実施形態のシステムの参照は、関数コールおよび変数参照の少なくとも１つを含む。
【０１２０】
一実施形態のシステムのダイナミック・アドレシング・マネージャは、関数コールおよび変数参照の少なくとも一方に対する集中ジャンプ・テーブルであり、ベクトル・テーブルを備えている。
【０１２１】
一実施形態のシステムのダイナミック・アドレシング・マネージャは、少なくとも１つの集中セクションを備えており、少なくとも１つの変数参照を集中セクションに割り当てる。
【０１２２】
一実施形態のシステムの第１デバイスは、第２デバイス上にホストされているソフトウェア・コンポーネントの少なくとも１つのプロバイダによってアクセス可能な、プロセッサに基づくデバイスである。
【０１２３】
一実施形態のシステムの移動通信デバイスは、セルラ電話機、携帯計算デバイス、およびパーソナル・ディジタル・アシスタントの内少なくとも１つを含む。
一実施形態の複数のソフトウェア・コンポーネントは、ダイナミック・リンク・ライブラリ・ファイル、共有オブジェクト・ファイル、埋め込みソフトウェア・コンポーネント（ＥＢＳＣ）、ファームウェア・ファイル、実行可能ファイル、１６進データ・ファイルを含むデータ・ファイル、システム・コンフィギュレーション・ファイル、および個人使用データを含むファイルを含む、ソフトウェア・ファイルから成る。
【０１２４】
ここに記載するＤＡおよびＤＡマネージャは、移動通信デバイスを含み、クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成する手段と、複数のコンポーネントの各々に含まれている１つ以上の参照を識別する手段であって、各参照がコードの１つ以上の他のコンポーネントに対する参照である、手段と、１つ以上のリンクを含むマネージャ・コンポーネントを生成する手段であって、各リンクが、１つのコンポーネントにおいて識別された各参照と、識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成する、手段と、コードの実行中に、マネージャ・コンポーネントのリンクを用いて、複数のコンポーネントをリンクする手段との内少なくとも１つを備えている。
【０１２５】
一実施形態のデバイスのマネージャ・コンポーネントを生成する手段は、更に、関数コールおよびグローバル変数の少なくとも一方に対する集中ジャンプ・テーブルである、ベクトル・テーブルを生成する手段を備えている。一実施形態のデバイスの複数のコンポーネントをリンクする手段は、更に、第１コンポーネントからベクトル・テーブルのエントリに参照を誘導する手段と、エントリの情報を用いて、参照を第２コンポーネントに誘導し直す手段との内少なくとも１つを備えている。
【０１２６】
一実施形態のデバイスのマネージャ・コンポーネントを生成する手段は、更に、マネージャ・コンポーネントの少なくとも１つの集中セクションを生成する手段と、生成した集中セクションに対して変数参照を割り当てる手段との内少なくとも１つを備えている。一実施形態のデバイスの複数のコンポーネントをリンクする手段は、更に、変数参照への参照を、変数参照に対応する集中セクションのアドレスに誘導する手段を備えてもよい。
【０１２７】
一実施形態のデバイスは、更に、コードをアップグレードする手段を備えており、ワイヤレス結合を介してアップグレード・ファイルを受信する手段と、アップグレード・ファイルの内容に適切なように、複数のコンポーネントの少なくとも１つをアップグレードする手段と、マネージャ・コンポーネントをアップグレードすることによって、複数のアップグレードしたコードのコンポーネント間におけるリンクをアップグレードする手段の内少なくとも１つを含む。
【０１２８】
ここに記載するＤＡおよびＤＡマネージャは、実行可能命令を含む機械読み取り可能媒体を含み、処理システムにおいて実行すると、クライアント・デバイスのデバイス・メモリに格納されているコードを、複数のコンポーネントに編成し、複数のコンポーネントの各々に含まれている１つ以上の参照を識別し、各参照がコードの１つ以上の他のコンポーネントに対する参照であり、１つ以上のリンクを含むマネージャ・コンポーネントを生成し、各リンクが、１つのコンポーネントにおいて識別された各参照と、この識別された参照に対応する他のコンポーネントとの間のプログラム・リンクを形成し、および／または、コードの実行中に、マネージャ・コンポーネントのリンクを用いて、複数のコンポーネントをリンクすることによって、携帯デバイスにおけるソフトウェア・コンポーネントをリンクする。
【０１２９】
一実施形態の媒体は、更に、ワイヤレス結合を介してアップグレード・ファイルを受信し、アップグレード・ファイルの内容に適切なように、複数のコンポーネントの少なくとも１つをアップグレードし、および／または、マネージャ・コンポーネントをアップグレードすることによって、複数のアップグレードしたコードのコンポーネント間におけるリンクをアップグレードすることによって、コードをアップグレードすることを含む。
【０１３０】
ここに記載する集中ＤＡマネージャの態様は、フィールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）、プログラマブル・アレイ・ロジック（「ＰＡＬ」）デバイス、電気的プログラム可能ロジックおよびメモリ・デバイスのようなプログラマブル・ロジック・デバイス（「ＰＬＤ」）、標準的なセルに基づくデバイス、ならびに特定用途集積回路（「ＡＳＩＣ」）を含む種々の回路のいずれにもプログラムされる機能性として実現することができる。ＤＡマネージャの態様を実施するためのその他の可能性には、メモリを有するマイクロコントローラ（ＥＥＰＲＯＭのような）、埋め込みマイクロプロセッサ、ファームウェア、ソフトウェア等を含む。更に、本発明の態様は、ソフトウェアに基づく回路エミュレーション、ディスクリート・ロジック（連続および組み合わせ）、カスタム・デバイス、ファジイ（ニューラル）ロジック、量子デバイス、および上述のデバイスの種類のいずれのハイブリッドを有するマイクロプロセッサにおいても具体化することができる。勿論、基盤となるデバイス技術は、種々のコンポーネントの種類、例えば、相補金属酸化物半導体（ＣＭＯＳ）のような金属酸化物半導体電界効果トランジスタ（ＭＯＳＦＥＴ）技術、エミッタ結合ロジック（ＥＣＬ）のようなバイポーラ技術、ポリマ技術（例えば、シリコン共役ポリマおよび金属共役ポリマ−金属構造）、混合アナログおよびディジタルなどにおいて提供することができる。
【０１３１】
尚、ここに開示した種々の機能は、その挙動、レジスタ転送、論理コンポーネント、および／またはその他の特性に関して、ハードウェア、ファームウェア、および／またはデータとして、および／または種々の機械読み取り可能またはコンピュータ読み取り可能媒体内に具体化された命令のあらゆる数の組み合わせを用いても記述可能であることを注記しておく。このようなフォーマット化したデータおよび／または命令を具体化することができるコンピュータ読み取り可能媒体は、限定ではなく、種々の形態の不揮発性記憶媒体（例えば、光学、磁気、または半導体記憶媒体）、ならびにワイヤレス、光学、または有線シグナリング媒体あるいはそのいずれの組み合わせを通じてでもこのようなフォーマット化データおよび／または命令を転送するために用いることができる搬送波を含む。搬送波によるこのようなフォーマット化データおよび／または命令の転送の例には、限定ではなく、１つ以上のデータ転送プロトコル（例えば、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ等）によるインターネットおよび／またはその他のコンピュータ・ネットワークを通じた転送（アップロード、ダウンロード、電子メール等）が含まれる。
【０１３２】
文脈上特に必要であることが明らかでない限り、明細書および特許請求の範囲を通じて、「備える」、「備えている」等の言葉は、排他的または網羅的意味ではなく、包含的意味で解釈するものとする。即ち、「含むが、限定されない」という意味である。単数または複数を用いる単語も、それぞれ、複数および単数を含むものとする。加えて、「ここでは」、「以下で」「先に」、「以下に」という単語、および同様な意義の単語は、本願において用いられる場合、本願全体を指すのであり、本願のいずれの特定部分を指すのではないこととする。「または」という単語が、２つ以上の項目のリストについて用いられる場合、この単語は、リスト内にある項目のいずれか、リストにある項目の全て、およびリストにある項目のあらゆる組み合わせという、この単語の解釈全てを包含することとする。
【０１３３】
ＤＡマネージャの例示した実施形態についての以上の説明は、それで全てであることも、ＤＡマネージャを正確に開示した形態に限定することも意図していない。ここでは例示の目的のために、ＤＡマネージャの具体的な実施形態およびその例について記載したが、当業者には認められるように、ＤＡマネージャの範囲内で種々の同等な変更が可能である。ここに示したＤＡマネージャの教示は、前述のメモリ・システムや方法だけでなく、その他の処理システムや方法にも適用可能である。
【０１３４】
前述の種々の実施形態の要素や作用は、組み合わせると更に別の実施形態を設けることができる。以上の詳細な説明に鑑みれば、これらおよびその他の変更をＤＡマネージャに行うことができる。
【０１３５】
一般に、以下の特許請求の範囲では、用いられる用語がＤＡマネージャを、明細書および特許請求の範囲に開示されている特定の実施形態に限定すると解釈してはならず、特許請求の範囲の下で動作する処理システム全てを含むように解釈してしかるべきである。したがって、ＤＡマネージャは、開示に限定されるのではなく、代わりに、ＤＡマネージャの範囲は、特許請求の範囲によってその全体が決定されるものとする。
【０１３６】
ＤＡマネージャの数種類の態様を、請求項の形態で提示するが、本発明者は、ＤＡマネージャの種々の態様を、いずれの数の請求項の形態でも想定している。例えば、ＤＡマネージャの一態様のみが、機械読み取り可能媒体に具体化したものとして明記されているが、他の態様も同様に機械読み取り可能媒体に具体化することもできる。したがって、本発明者は、本願を出願した後でも、更に別の請求項を追加し、ＤＡマネージャの別の態様に対する、このような更に別の請求項を追求する権利を保有するものとする。
【図面の簡単な説明】
【０１３７】
【図１】図１は、一実施形態の下における、ダイナミック・アドレシング（「ＤＡ」）マネージャを有するクライアント・デバイスを含むシステムのブロック図である。
【図２】図２は、一実施形態の下における、サービス・プロバイダ・インフラストラクチャ例のブロック図である。
【図３】図３は、一実施形態の下における、ＤＡマネージャと画像のソフトウェア・コンポーネントとの間の相互作用を示す、ＤＡのブロック図である。
【図４Ａ】図４Ａは、一実施形態の下における、ＤＡマネージャを含む画像を構築する際のフロー図を示す。
【図４Ｂ】図４Ｂは、一実施形態の下における、ＤＡマネージャを含む画像を構築する際のフロー図を示す。
【図５】図５は、図１および図３の実施形態の下における、ソフトウェア画像のコンポーネントを含むメモリのコンポーネント、アップグレード・クライアント、およびＤＭＭクライアント間の相互作用の一例を示す、デバイス・メモリのブロック図である。
【図６】図６は、一実施形態の下において、ＤＡを用いてＥＢＳＣまたはＥＢＳＣグループをアップグレードする際のフロー図である。
【図７】図７は、一実施形態の下における、ＤＡを用いた関数コールのフロー図である。
【図８】図８は、一実施形態の下において、新たなバージョンのＥＢＳＣを収容するためのメモリ・エリアを予約する際のフロー図である。
【図９】図９は、一実施形態において、新たなバージョンのＥＢＳＣを収容するためのメモリ・ブロックの位置を特定する際のフロー図である。
【図１０】図１０は、一実施形態の下における、ガベージ・コレクションのフロー図である。
【図１１】図１１は、一実施形態の下における、ＤＡを用いての埋め込みソフトウェア開発および展開プロセスのブロック図である。
【図１】
2007511816.tif 000007
【図２】
2007511816.tif 000008
【図３】
2007511816.tif 000009
【図４Ａ】
2007511816.tif 000010
【図４Ｂ】
2007511816.tif 000011
【図５】
2007511816.tif 000012
【図６】
2007511816.tif 000013
【図７】
2007511816.tif 000014
【図８】
2007511816.tif 000015
【図９】
2007511816.tif 000016
【図１０】
2007511816.tif 000017
【図１１】
2007511816.tif 000018
【国際調査報告】
2007511816.tif 000019
2007511816.tif 000020