(57)【特許請求の範囲】
【請求項１】
ファイル・システム・イメージの差異を検出する、少なくとも１つのプロセッサと少なくとも１つのメモリとを含むデバイスであって、
スタティック・ファイル・システムのイメージを受信する受信部であって、前記イメージが原イメージおよび新イメージを含む、受信部と、
前記受信部に結合され、前記イメージを第１フォーマットから複数の分割ファイルに、前記イメージの構造の情報を用いて変換するプリプロセッサであって、前記複数の分割ファイルが、非圧縮イメージ部分と圧縮イメージ部分とを含み、前記非圧縮イメージ部分は、同じブロック境界内に入る受信イメージ部分に対応し、前記圧縮イメージ部分は、ブロック境界を跨る他の受信イメージ部分に対応し、分割ファイルが、前記原イメージおよび前記新イメージの少なくとも１つの部分のデータと、前記少なくとも１つの部分の場所情報を含む前記少なくとも１つの部分の追加の情報とを含む、プリプロセッサと、
前記プリプロセッサに結合され、前記新イメージの１つの部分と前記原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部と、
前記従属性生成部に結合され、前記新イメージの少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンであって、前記デルタ・ファイルが、前記新イメージの前記少なくとも１つの部分と前記原イメージの前記少なくとも１つの部分との間の差異を含む、差異エンジンと、
を備えている、デバイス。
【請求項２】
請求項１記載のデバイスにおいて、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、デバイス。
【請求項３】
請求項１記載のデバイスであって、更に、前記差異エンジンに結合され、前記新イメージの全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている、デバイス。
【請求項４】
プロセッサに基づくデバイスを用いてスタティック・ファイル・システムのイメージを受信するステップであって、該イメージが原イメージおよび新イメージを含み、前記イメージが複数のブロックを含む、ステップと、
前記イメージを複数の分割ファイルに、前記複数のブロックの情報を用いて変換するステップであって、前記複数の分割ファイルが、非圧縮イメージ部分と圧縮イメージ部分とを含み、前記非圧縮イメージ部分は、同じブロック境界内に入る受信イメージ部分に対応し、前記圧縮イメージ部分は、ブロック境界を跨る他の受信イメージ部分に対応し、前記変換は、前記複数のブロックの前記情報を用いて前記イメージを分割して前記イメージを複数の部分に分割し、前記変換は、前記分割のヒント情報を生成し、前記複数の分割ファイルは前記複数の部分を含む、ステップと、
前記新イメージの少なくとも１つの部分と、前記原イメージの少なくとも１つの部分との間における従属性を識別し、前記識別の従属性情報を含む部分従属性テーブルを生成するステップと、
前記部分従属性の情報を使用して前記原イメージおよび前記新イメージの前記複数の部分間の差異を判定することによって、前記イメージの内容間の差異を判定するステップと、
少なくとも１つの部分についての前記差異を含むデルタ・ファイルを生成するステップと、
を備えている、方法。
【請求項５】
請求項４記載の方法において、前記受信イメージは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項６】
請求項４記載の方法であって、更に、前記複数の部分のデータを前記複数の分割ファイルに書き込むステップを備えており、前記データは、前記複数の部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうちの少なくとも１つを含む、方法。
【請求項７】
請求項４記載の方法であって、更に、前記ヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項８】
請求項７記載の方法であって、
前記部分従属性テーブルの生成は、前記識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、前記新部分および前記対応の従属原部分を除外することを含む、
方法。
【請求項９】
請求項７記載の方法であって、更に、
前記原イメージと同じ内容および異なる部分名を有する前記新イメージのあらゆる同一部分を特定するステップと、
前記同一部分の場所およびサイズを含む前記同一部分の情報を生成するステップであって、前記デルタ・ファイルが、前記同一部分の前記情報を含む、ステップと、
を備えている、方法。
【請求項１０】
請求項８記載の方法であって、更に、前記部分従属性テーブルと、前記ヒント情報とを組み合わせるステップを備えている、方法。
【請求項１１】
請求項１０記載の方法であって、更に、ブロック優先グラフを生成し、該ブロック優先グラフにおけるあらゆるサイクルを分解することによって、非周期的ブロック優先グラフを形成するステップを備えている、方法。
【請求項１２】
請求項１１記載の方法であって、更に、前記非周期的ブロック優先グラフの情報を用いて、前記部分従属性テーブルを並べ換えることによって、再整列部分従属性テーブルを生成するステップを備えている、方法。
【請求項１３】
請求項４記載の方法であって、更に、
前記デルタ・ファイルを、前記原イメージをホストするクライアント・デバイスに転送するステップと、
前記クライアント・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で前記新イメージの部分全てを再現し、前記デバイス・ブロックを前記クライアント・デバイスのリード・オンリ・メモリに書き込むことによって、前記デルタ・ファイルの情報を用いて前記クライアント・デバイスの目標イメージを更新するステップと、
を備えている、方法。
【請求項１４】
請求項１３記載の方法において、前記更新するステップは、更に、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記従属する原部分のうち、前記受信したデルタ・ファイルに対応する少なくとも１つを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１５】
請求項４記載の方法であって、更に、複数のデルタ・ファイルを組み立ててデルタ・パッケージにするステップを備えている、方法。
【請求項１６】
請求項１５記載の方法であって、更に、前記デルタ・パッケージを、前記原イメージをホストするクライアント・デバイスに転送するステップを備えている、方法。
【請求項１７】
請求項１６記載の方法であって、更に、
前記クライアント・デバイスにおいて、少なくとも１つのワイヤレス結合部を介して、前記デルタ・パッケージを受信するステップと、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記デルタ・パッケージのうち、前記従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１８】
プロセッサに基づくデバイスを用いてスタティック・ファイル・システムのイメージを受信するステップであって、前記イメージが原イメージおよび新イメージを含む、ステップと、
前記イメージを第１フォーマットから複数の分割ファイルに、前記イメージの構造の情報を用いて変換するステップであって、前記複数の分割ファイルが、非圧縮イメージ部分と圧縮イメージ部分とを含み、前記非圧縮イメージ部分は、同じブロック境界内に入る受信イメージ部分に対応し、前記圧縮イメージ部分は、ブロック境界を跨る他の受信イメージ部分に対応し、分割ファイルが、前記原イメージおよび新イメージの少なくとも１つの部分のデータと、前記少なくとも１つの部分の場所情報を含む前記少なくとも１つの部分の追加の情報とを含む、ステップと、
前記新イメージの１つの部分と前記原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成するステップと、
前記新イメージの少なくとも１つの部分についてデルタ・ファイルを生成するステップであって、前記デルタ・ファイルが、前記新イメージの前記少なくとも１つの部分と前記原イメージの前記少なくとも１つの部分との間の差異を含む、ステップと、
を備えている、方法。
【請求項１９】
請求項１８記載の方法において、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項２０】
請求項１８記載の方法において、前記イメージは、圧縮ファイルおよび非圧縮ファイルの少なくとも１つを含む、方法。
【請求項２１】
請求項１８記載の方法において、前記変換するステップは、更に、
スーパー・ヘッダおよびディレクトリ・ヘッダのうちの少なくとも１つを前記複数の分割ファイルにコピーするステップと、
前記少なくとも１つのスーパー・ヘッダおよびディレクトリ・ヘッダに名称を割り当てるステップと、
を備えている、方法。
【請求項２２】
請求項１８記載の方法において、前記変換するステップは、更に、
前記イメージの複数のブロックの情報を用いて前記イメージを分割して前記イメージを複数の部分に分割するステップと、
前記複数の部分のうち、１つのブロックの前記同じ境界内にある少なくとも１つの部分を判定するステップと、
前記同じ境界内にある前記少なくとも１つの部分を伸張し、該伸張した部分を前記複数の分割ファイルに出力するステップと、
を備えている、方法。
【請求項２３】
請求項２２記載の方法であって、更に、前記複数の分割ファイルが同じＣＲＡＭＦＳ  Ｌｉｎｕｘファイルに属し（ファイルの制約）、同じデバイス・ブロック内に位置し（ＲＯＭの制約）、かつ前記分割ファイルの伸張バージョンの総サイズが閾値未満である（ＲＡＭの制約）場合、前記分割ファイルを併合するステップを備えている、方法。
【請求項２４】
請求項１８記載の方法であって、更に、前記複数の部分のデータを前記複数の分割ファイルに書き込むステップを備えており、前記データは、前記複数の部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうち少なくとも１つを含む、方法。
【請求項２５】
請求項１８記載の方法であって、更に、前記複数の分割ファイルの分割毎にヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項２６】
請求項２５記載の方法において、部分従属性テーブルを生成するステップは、更に、
前記ヒント・ファイルのファイル名をソートするステップと、
前記原イメージおよび新イメージの間で共通するファイル名を特定するステップと、
を備えている、方法。
【請求項２７】
請求項２６記載の方法において、前記ソートするステップは、前記原イメージのファイル名および前記新イメージのファイル名のうち少なくとも一方のアルファベット順のソートを含む、方法。
【請求項２８】
請求項２６記載の方法であって、更に、前記原イメージの前記少なくとも１つの部分と前記新イメージの前記少なくとも１つの部分との間におけるいずれの部分従属性も判定するステップを備えている、方法。
【請求項２９】
請求項２８記載の方法であって、更に、各新部分の内容を、該新部分が従属する対応の原部分の内容と比較するステップを備えており、前記新部分が１つの原部分のみに従属する、方法。
【請求項３０】
請求項２９記載の方法であって、更に、前記比較によって、内容および部分名が同一であることが示された場合、前記新部分および前記対応する原部分を前記部分従属性テーブルから除去することにより、修正部分従属性テーブルを生成するステップを備えている、方法。
【請求項３１】
請求項３０記載の方法であって、更に、前記比較によって、内容が同一であり、部分名が異なることが示された場合、フラグを設定するステップを備えており、前記部分は、前記新イメージにおいて場所がシフトされた同一部分であり、前記フラグはWHOLE＿IS＿COPYフラグである、方法。
【請求項３２】
請求項３１記載の方法であって、更に、前記同一部分の場所およびサイズを含む同一部分の情報を生成するステップを備えており、前記デルタ・ファイルは、前記同一部分の前記情報を含む、方法。
【請求項３３】
請求項３０記載の方法であって、更に、前記イメージについて前記修正部分従属性テーブルおよび前記ヒント・ファイルを組み合わせるステップを備えている、方法。
【請求項３４】
請求項３３記載の方法であって、更に、
ブロック優先グラフを生成するステップと、
前記ブロック優先グラフにおいてあらゆるサイクルを特定するステップと、
前記ブロック優先グラフにおけるあらゆるサイクルを分解し、非周期的ブロック優先グラフを形成するステップと、
を備えている、方法。
【請求項３５】
請求項３４記載の方法であって、更に、
前記非周期的ブロック優先グラフの情報をソートすることにより、ソートした非周期的ブロック優先グラフを生成するステップと、
前記ソートした非周期的ブロック優先グラフの情報を用いて、前記修正部分従属性テーブルを並べ換えることにより、再整列部分従属性テーブルを生成するステップと、
前記再整列部分従属性テーブルを出力するステップと、
を備えている、方法。
【請求項３６】
少なくとも１つのプロセッサと少なくとも１つのメモリとを含むシステムであって、
スタティック・ファイル・システムのイメージを受信する受信部であって、前記イメージが原イメージおよび新イメージを含む、受信部と、
前記受信部に結合され、前記イメージを第１フォーマットから複数の分割ファイルに、前記イメージの構造の情報を用いて変換するプリプロセッサであって、前記複数の分割ファイルが、非圧縮イメージ部分と圧縮イメージ部分とを含み、前記非圧縮イメージ部分は、同じブロック境界内に入る受信イメージ部分に対応し、前記圧縮イメージ部分は、ブロック境界を跨る他の受信イメージ部分に対応し、分割ファイルが、前記原イメージおよび新イメージの少なくとも１つの部分のデータと、前記少なくとも１つの部分の場所情報を含む前記少なくとも１つの部分の追加の情報とを含む、プリプロセッサと、
前記プリプロセッサに結合され、前記新イメージの１つの部分と前記原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部と、
前記従属性生成部に結合され、前記新イメージの少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンであって、前記デルタ・ファイルが、前記新イメージの前記少なくとも１つの部分と前記原イメージの前記少なくとも１つの部分との間の差異を含む、差異エンジンと、
前記差異エンジンに結合され、前記新イメージの全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンと、
を備えている、システム。
【請求項３７】
請求項３６記載のシステムであって、更に、携帯デバイスにおいて更新エンジンを備えており、該携帯デバイスは、少なくとも１つの結合部を介して、前記デルタ・パッケージを受信し、前記更新エンジンは、前記携帯デバイス上にホストされている前記原イメージの従属する原部分を組み立て、前記デルタ・パッケージのうち、前記従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定し、前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現する、システム。
【請求項３８】
請求項３７記載のシステムにおいて、前記更新エンジンは、前記デルタ・パッケージを受信し、該デルタ・パッケージの少なくとも１つのデルタ・ファイルの内容の完全性を検証する、システム。
【請求項３９】
請求項３７記載のシステムにおいて、前記更新エンジンは、前記携帯デバイスの第１メモリ・エリアにおいて前記少なくとも１つの新部分を再現する、システム。
【請求項４０】
請求項３９記載のシステムにおいて、前記第１メモリ・エリアは、ランダム・アクセス・メモリ（ＲＡＭ）内にある、システム。
【請求項４１】
請求項３９記載のシステムにおいて、前記更新エンジンは、前記原部分のうちの少なくとも１つに対応する前記デルタ・パッケージのデルタ・ファイルを特定し、該特定したデルタ・ファイルに対応する新部分を再現し続ける、システム。
【請求項４２】
請求項４１記載のシステムにおいて、前記更新エンジンは、前記デルタ・パッケージのデルタ・ファイル全てを、前記携帯デバイス上にホストされている前記原部分に適用し終えたことを判定し、この判定に応答して、前記携帯デバイスの第２メモリ・エリアに、前記再現した新部分を書き込む、システム。
【請求項４３】
請求項４２記載のシステムにおいて、前記第２メモリ・エリアは、リード・オンリ・メモリ（ＲＯＭ）内にある、システム。
【請求項４４】
実行可能命令を格納したコンピュータ読み取り可能記憶媒体であって、前記実行可能命令が処理システムによって実行されると、前記処理システムにイメージ間の差異を判定する方法を実行させ、該方法が、
スタティック・ファイル・システムのイメージを受信し、該イメージが原イメージおよび新イメージを含み、前記イメージが複数のブロックを含み、
前記イメージを複数の分割ファイルに、前記複数のブロックの情報を用いて変換し、前記複数の分割ファイルが、非圧縮イメージ部分と圧縮イメージ部分とを含み、前記非圧縮イメージ部分は、同じブロック境界内に入る受信イメージ部分に対応し、前記圧縮イメージ部分は、ブロック境界を跨る他の受信イメージ部分に対応し、該変換は、前記複数のブロックの情報を用いて前記イメージを分割して前記イメージを前記複数の部分に分割し、前記変換は、前記分割のヒント情報を生成し、前記複数の分割ファイルは前記複数の部分を含み、
前記新イメージの少なくとも１つの部分と、前記原イメージの少なくとも１つの部分との間における従属性を識別し、前記識別の従属性情報を含む部分従属性テーブルを生成し、
前記部分従属性の情報を使用して前記原イメージと前記新イメージの前記複数の部分間の差異を判定することによって、前記イメージの内容間の差異を判定し、
少なくとも１つの部分についての前記差異を含むデルタ・ファイルを生成する、
こと、を含むコンピュータ読み取り可能媒体。
【請求項４５】
請求項４４記載の媒体において、前記受信イメージは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、媒体。
【請求項４６】
請求項４４記載の媒体であって、前記媒体は、更に、前記複数の部分のデータを前記複数の分割ファイルに書き込むことによって、イメージ間の差異を判定し、前記データは、前記複数の部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうちの少なくとも１つを含む、媒体。
【請求項４７】
請求項４４記載の媒体において、前記媒体は、更に、前記ヒント情報を含む少なくとも１つのヒント・ファイルを生成することによってイメージ間の差異を判定する、媒体。
【請求項４８】
請求項４７記載の媒体において、
前記部分従属性テーブルを生成することは、前記識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、前記新部分および前記対応の従属原部分を除外することを含む、
媒体。
【請求項４９】
請求項４７記載の媒体において、前記媒体は、更に、
前記原イメージと同じ内容および異なる部分名を有する前記新イメージのあらゆる同一部分を特定し、
前記同一部分の場所およびサイズを含む前記同一部分の情報を生成し、前記デルタ・ファイルが、前記同一部分の前記情報を含む、
ことによってイメージ間の差異を判定する、媒体。
【請求項５０】
請求項４４記載の媒体において、前記媒体は、更に、
前記デルタ・ファイルを、前記原イメージをホストするクライアント・デバイスに転送し、
前記クライアント・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロックに前記新イメージの部分全てを再現し、前記デバイス・ブロックを前記クライアント・デバイスのリード・オンリ・メモリに書き込むことによって、前記デルタ・ファイルの情報を用いて、前記クライアント・デバイスの目標イメージを更新する、
ことによってイメージ間の差異を判定する、媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本願は、米国特許出願第６０／６２６，２５２号、第６０／６２６，２９２号、および第６０／６２６，２９３号の優先権を主張する。これらは全て、２００４年１１月８日に出願されている。本願は、"Static File System Differencing and Updating"（スタティック・ファイル・システムの差異検出および更新）と題する代理人整理番号がＤＯＧＯ．Ｐ０１９である米国特許出願（番号は未だ割り当てられていない）、および"Reorganizing Images in Static File System Differencing and Updating"（スタティック・ファイル・システムの差異検出および更新におけるイメージ認識）と題する代理人整理番号がＤＯＧＯ．Ｐ０２１である米国特許出願（番号は未だ割り当てられていない）に関連がある。これらは共に２００５年１１月８日に出願されている。
（技術分野）
開示する実施形態は、差異ファイルを用いたスタティック・ファイル・システムの更新に関し、更に特定すれば、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマット・イメージの更新に関する。
【背景技術】
【０００２】
ある種の機能を提供するためにプロセッサ、マイクロプロセッサ、および／または演算装置上において走るソフトウェアは、時と共に変更し、更に複雑になることが多い。変更は、ソフトウェア・ファイルにおけるバグ即ち誤りを訂正し、発展しつつある技術に適応し、新たな特徴を追加する必要性等によって生ずる可能性がある。特に、移動処理デバイス、例えば、移動ワイヤレス・デバイス上にホストされているソフトウェアは、多数のソフトウェア・バグを含み、訂正する必要がある場合が多い。ソフトウェアは、１つ以上のコンピュータ・プログラム、アルゴリズム、ファイル、および／またはホスト・デバイスの動作に関連するコードを含む。ソフトウェアは、モジュールまたはコンポーネントと呼ばれる小さな単位に分割することができる。
【０００３】
移動処理デバイスのような、携帯プロセッサに基づくデバイスは、通例、リアル・タイム・オペレーティング・システム（ＲＴＯＳ）を含み、このオペレーティング・システムの中では、デバイスのソフトウェア・コンポーネント全てが、単一の大きな実行可能イメージとしてリンクされている。更に、最近、小型のストレージが入手可能になったこと、そしてこれらの移動ワイヤレス・デバイスにおいて機能の要求が増大していることのため、ファイル・システム・サポートが普及しつつある。加えて、単一の大きなイメージは、無線、赤外線、またはシリアル・リンクのような低速通信を用いて、デバイス内に予めロードする、または埋め込む必要がある。
【０００４】
移動処理デバイスのソフトウェアを更新することに対する障害には、更新ファイルをデバイスに配信することに伴う時間、大域幅、およびコスト、ならびに一旦受信した新たなファイルを更新する際に用いることができるデバイスのリソースの制約が含まれる。一例として、スタティック・ファイル・システム・イメージは、ホスト・デバイスのリソースの制約（例えば、ＲＡＭ、ＲＯＭ、イメージをダウンロードするための時間、電力消費等に関する制約）のためにその場で（例えば、リード・オンリ・メモリ（ＲＯＭ）内）で更新しなければならない。その結果、ホスト・デバイスへの効率的な転送のためおよびリソースに限界があるデバイスのソフトウェアを更新する際に用いるためにしかるべき大きさとした差異ファイルを生成することが必要となる。
（援用）
本明細書において言及する各刊行物、特許、および／または特許出願は、個々の各刊行物および／または特許出願を特定し個々に援用によって含まれると指摘する場合と同様に、援用によりその全体が本願に含まれるものとする。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
スタティック・ファイル・システム（ＳＦＳ）差異検出および更新のためのシステムおよび方法を提供する。
【課題を解決するための手段】
【０００６】
ＳＦＳ差異検出および更新のためのシステムおよび方法は、以下に説明するように、原イメージの更新単位（デバイス・ブロックまたはブロックと呼ぶ）の部分レベルの差異検出およびブロック・レベルの更新を含む。一実施形態の差異検出および更新では、ブロック情報およびＳＦＳイメージ構造に基づいて、ＳＦＳイメージを一連の部分に分割する。新たなＳＦＳイメージの部分毎に、デルタ・ファイルを生成する。デルタ・ファイルは、新しいＳＦＳイメージの部分と、新しいＳＦＳイメージ部分が対応する原ＳＦＳイメージの部分（複数の部分）との間の差異の情報を含む（新しい部分は、１つよりも多い原部分に従属する可能性があり、加えて、原部分（複数の部分）新しい部分と同じ場所にはない場合もある）。デルタ・ファイルをデバイスに転送し、デバイスのイメージを新しいＳＦＳイメージに更新する際に用いる。デバイスの目標ＳＦＳイメージは、デルタ・ファイルの情報を用いて、ブロック毎に更新する。一実施形態のブロック毎の更新により、ホスト・デバイスのランダム・アクセス・メモリ（ＲＡＭ）において、デバイス・ブロックにおける新しいＳＦＳイメージの全ての部分を再現し、次いで、再現したブロックをホスト・デバイスのＲＯＭに書き込む。
【０００７】
ＳＦＳは、リード・オンリ・ファイル・システムとも呼ばれ、実行時間中は修正することができないファイル・システムである。ＳＦＳの例には、限定ではなく、Symbian Z drive（「ＲＯＭドライブ」とも呼ぶ）、Linux 圧縮ＲＯＭファイル・システム（ＣＲＡＭＦＳ）、暗号化ファイル・システム、オペレーティング・システム・エクゼキュータブル、内蔵アプリケーション、必須マルチメディア情報、デフォルト言語ファイルが含まれ、これら以外にも多数ある。
【発明を実施するための最良の形態】
【０００８】
図面において、同じ参照番号は、同一または実質的に同様の要素または作用を識別することとする。いずれの特定の要素またはアクトの論述でも容易に識別できるように、参照番号の上位１桁以上は、当該要素が最初に紹介された図の番号を示す（例えば、要素１００は、図１に関して最初に紹介され論じられている）。
【０００９】
以下に説明する実施形態のＳＦＳ差異検出および更新では、スタティック・ファイル・システムのイメージを受信する。イメージは、原イメージおよび新イメージを含み、各々、多数のブロック、例えば、スーパー・ブロック、データ・ブロック等を含む。ＳＦＳ差異検出では、ブロックの情報を用いることによってイメージを分割し、イメージを多数の部分に分割する。原イメージおよび新イメージの部分間の差異を判定することにより、イメージの内容間における差異を判定し、新イメージの部分毎に差異を生成する。差異は、部分間におけるバイト・レベルの差異を含むが、これに限定されるのではない。新イメージの部分毎の差異を含むデルタ・ファイルを生成する。
【００１０】
実施形態のＳＦＳ差異検出および更新は、更新することを含み、これによって携帯デバイス上にホストされているイメージのＳＦＳを、携帯デバイスの内部で更新する。更新の際、少なくとも１つの結合部(coupling)を介して、携帯デバイスにおいてデルタ・ファイルを受信する。携帯デバイス上にホストされている原部分の従属するものを組み立て、そのうちの、受信したデルタ・ファイルに対応する少なくとも１つを特定する。ここで、一実施形態では、ＲＯＭにおける新部分の場所を、その対応するデルタ・ファイルに関連するＳＦＳデルタ・パッケージの中にエンコードする。更新によって、携帯デバイス上において、特定したデルタ・ファイルに対応する少なくとも１つの新部分を再現する。新イメージの再現した新部分を、携帯デバイスのリード・オンリ・メモリ（ＲＯＭ）に書き込む。
【００１１】
以下の説明では、多数の具体的な詳細を紹介して、ＳＦＳ差異検出および更新の実施形態の完全な理解が得られるようにし、それを実施可能にする説明を行う。しかしながら、本発明はこれら具体的な詳細が１つ以上なくても、または他のコンポーネント、システムなどでもＳＦＳ差異検出および更新実施可能であることは、当業者は認めよう。その他の場合には、周知の構造や動作については、ＳＦＳ差異検出および更新を曖昧にするのを避けるために、図示も詳細な説明も行わない。
【００１２】
図１は、一実施形態におけるＳＦＳ差異検出システム１００のブロック図である。ＳＦＳ差異検出システムは、イメージ処理モジュール１０２、従属性生成モジュール１０４、差異エンジンまたはモジュール１０６、およびパッケージング・エンジンまたはモジュール１０８を含むが、そのように限定されるのではない。一実施形態の従属性生成モジュールは、イメージ処理モジュール１０２に結合されている。一実施形態の差異エンジン１０６は、従属性生成モジュール１０４に結合されている。一実施形態のパッケージング・エンジン１０８は、差異エンジン１０６に結合されている。
【００１３】
一実施形態のＳＦＳ差異検出システム１００は、ホスト・コンピュータ・システム（図示せず）のコンポーネント間で結合し、これらのコンポーネントは、プロセッサ、コントローラ、メモリ・デバイス、および／またはバスのうち少なくとも１つを含むことができるが、そのように限定されるのではない。ＳＦＳ差異検出システム１００のコンポーネント即ちモジュール１０２〜１０８の１つ以上は、少なくとも１つのアルゴリズム、プログラム、またはルーチンの制御の下で走る。ホスト・コンピュータ・システムのプロセッサは、プログラム制御の下で、ホスト・コンピュータ・システムのコンポーネント、およびＳＦＳ差異検出システムのコンポーネント１０２〜１０８の間で結合する。イメージ処理モジュール１０２、従属性生成モジュール１０４、差異エンジン１０６、およびパッケージング・エンジン１０８は別個のブロックとして示されているが、これらのブロック１０２〜１０８の一部または全部は、単一チップ上にモノリシックに集積すること、ホスト・システムの多数のチップまたはコンポーネント間で分散すること、および／またはプログラムまたはアルゴリズムの１つまたは何らかの組み合わせによって設けることができる。プログラムまたはアルゴリズムがある場合、ソフトウェア・アルゴリズム（複数のアルゴリズム）、ファームウェア、ならびにソフトウェア、ファームウェア、およびハードウェアのいずれの組み合わせでも実施することができる。
【００１４】
「モジュール」という用語は、ここで用いる場合、一般に論理的に分離可能なプログラムの一部を意味し、ソフトウェア、アルゴリズム、プログラム、コンポーネント、ユニットを含む１つ以上の用語と相互交換可能である。「コンポーネント」という用語は、ここで用いる場合、一般にシステムを構成する部分の１つ以上を意味し、コンポーネントはソフトウェアおよび／またはハードウェアとすることができ、他のコンポーネントに再分割することもできる。「モジュール」、「コンポーネント」、および「ユニット」という用語は、相互交換可能に用いることができ、あるいは文脈に応じて異なる方法で互いの下位要素であると定義することができる。「プロセッサ」という用語は、ここで用いる場合、一般に、１つ以上の中央演算装置（ＣＰＵ）、ディジタル信号プロセッサ（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）等のような、いずれの論理演算装置をも意味する。
【００１５】
動作において、ＳＦＳ差異検出システム１００は、少なくとも１つの原ＳＦＳイメージ１１２および少なくとも１つの新ＳＦＳイメージ１１４を受信し、部分レベルの差異検出を行う。一実施形態の新ＳＦＳイメージ１１４は、ＣＲＡＭＦＳイメージ１１４Ｃを含むが、そのように限定されるのではない。ＣＲＡＭＦＳイメージ１１４Ｃは、スーパー・ヘッダ(SupHdr)区間、ディレクトリ・ヘッダ(DirHdr)区間、およびデータ区間を含む。スーパー・ヘッダは、固定の７２バイト・ヘッダであり、イメージ・サイズ、完全性チェック・シグネーチャ(integrity check signature)、構成、およびルート・ノード情報のような情報を含み、これ以外にも様々な情報も含む。ディレクトリ・ヘッダは、可変区間であり、ディレクトリ、ファイル、シンボル等の名称を含む。ディレクトリ・ヘッダ区間は、データ区間における各ファイルのポインタ／場所も含む。加えて、ディレクトリ・ヘッダは、ディレクトリの階層およびその内容というような情報を含む。データ区間は、ディレクトリ・ヘッダにおいて指定されるファイル／シンボルのデータを含むが、そのように限定されるのではない。
【００１６】
ＣＲＡＭＦＳイメージ１１４Ｃは、圧縮ファイルおよび非圧縮ファイルを含む。一例として、ＣＲＡＭＦＳイメージ１１４Ｃの一部の区間または部分は、ｚｌｉｂ汎用圧縮ライブラリを用いて圧縮することができる。しかしながら、スーパー・ヘッダ、ディレクトリ・ヘッダ、およびeXecute-In-Place（ＸＩＰ）ファイルのような、ＣＲＡＭＦＳイメージ１１４Ｃのその他の区間は、圧縮しなくてもよい。
【００１７】
ＳＦＳ差異検出システム１００は、原ＳＦＳイメージ１１２および新ＳＦＳイメージ１４を受信すると、部分レベルの差異検出を実行して、以下に述べるように１つ以上のデルタ・ファイルを生成する。デルタ・ファイルを組み立ててデルタ・パッケージ１２２とし、携帯即ち移動デバイスに転送する。移動デバイスのことをクライアント・デバイスと呼ぶこともある。これらの差異は、比較するイメージのブロックの１つ以上の部分間におけるバイト・レベルの差異を含むが、そのように限定されるのではない。ＳＦＳ差異検出システム１００は、プロセッサに基づくまたはコンピュータ・システムにおいてデルタ・ファイルを生成するか、あるいはプロセッサに基づくまたはコンピュータ・システムの下で走る。ＳＦＳ差異検出システムが走る基盤であるコンピュータ・システムは、共に動作する計算コンポーネントおよびデバイスのいずれかの集合体を含む。これは、当技術分野では周知である。また、コンピュータ・システムは、更に大きなコンピュータ・システムまたはネットワーク内部の一コンポーネントまたはサブシステムであることもできる。
【００１８】
デルタ・ファイルの内容は、原イメージ１１２および新イメージ１１４間における差異の効率的な表現を与える。デルタ・ファイルは、置換および／または挿入動作の実際のデータと共にメタデータも含むことができ、関連するファイルのバージョン新即ち現バージョンとそのファイルの以前のバージョンとの間の差異を表す。これについては、２００５年８月２日にカリフォルニア州、SunnyvaleのInnoPath Software, Inc.に発行された米国特許第６，９２５，４６７号に記載されている。ＳＦＳ差異検出システム１００は、最小数のバイトおよび既定のフォーマットまたはプロトコルを用いて、デルタ・パッケージ１２２のデルタ・ファイル内において、原イメージ１１２および新イメージ１１４間のあらゆる差異を得ることによりデルタ・ファイルを空間的に最適化する。
【００１９】
ＳＦＳ差異検出システム１００は、部分レベルの差異検出を行い、図２は、一実施形態におけるＳＦＳ差異検出２００のフロー図である。ＳＦＳ差異検出は、例えば、先に説明し更に別のところでも説明するＳＦＳ差異検出システム１００を用いて行われる。ＳＦＳ差異検出２００では、スタティック・ファイル・システムのイメージを受信する（２０２）。イメージは、原イメージおよび新イメージを含むが、そのように限定されるのではない。また、各イメージは、ある数のブロック、例えば、スーパー・ヘッダ・セクションまたはブロック、ディレクトリ・ブロック、またはデータ・ブロック等も含む。ブロックは、予め指定されたサイズ（例えば、６４ＫＢ、１２８ＫＢ等）であるが、そのように限定されるのではない。受信したイメージのブロックを、例えば、ブロックの情報を用いて、ある数の部分に分割する（２０４）。ＳＦＳ差異検出２００は、原イメージおよび新イメージの各々の部分間において差異を判定することにより、イメージの内容間の差異を判定する（２０６）。新イメージの各部分と原イメージの１つ以上の一致部分との間の内容またはデータの差異の情報を含むデルタ・ファイルを生成する（２０８）。
【００２０】
別の一例として、図３は、一実施形態におけるＳＦＳ差異検出３００のフロー図である。ＳＦＳ差異検出３００では、図２を参照して先に説明したように、スタティック・ファイル・システムのイメージを受信する（３０２）。受信した原イメージを１つ以上の原区間即ち部分に分割し（３０４）、受信した新イメージを１つ以上の新区間即ち部分に分割する（３０４）。ＳＦＳ差異検出は、原区間および新区間の間における従属性一致(dependency alignment)を識別する（３０６）。新区間の少なくとも１つについて、デルタ・ファイルを生成する（３０８）。デルタ・ファイルは、限定ではないが、新区間と１つ以上の原区間との間の差異を含み、新区間は原区間（複数の区間）に従属する。代替実施形態のデルタ・ファイルは、少なくとも１つの新区間と、当該心区間が従属する少なくとも１つの原区間との間の差異を含むこともできる。
【００２１】
図１を参照して先に説明したように、イメージ処理モジュール１０２は、現ＳＦＳイメージ１１２および新ＳＦＳイメージ１１４の各々を受信する。一実施形態のイメージ処理モジュール１０２は、受信したイメージの部分レベルの差異検出を開始するために動作する際、特定のイメージ・エリアを解析し、イメージの情報を抽出する。イメージについて抽出した情報は、差異検出および更新動作において用いられる。この解析は、スタティック・ファイル・システムおよび内部フォーマットの情報をデコードし、ＳＦＳイメージ差異検出および更新に用いるための関連情報を取得することを含む。解析から得られる情報には、限定ではないが、イメージのブロックの場所およびサイズ（例えば、スーパー・ブロック、データ・ブロック等）、用いられた圧縮ライブラリ（圧縮されている場合）、イメージを暗号化するために用いられた暗号化の種類（例えば、暗号化アルゴリズム、暗号化キー等）（暗号化されている場合）が含まれ、これら以外にも多数ある。
【００２２】
目標デバイス・ブロック情報に基づいて、イメージ処理モジュール１０２は、ＳＦＳイメージを多数の一連の部分に分割(divide or split)する。図４は、一実施形態において、イメージ処理モジュール１０２が部分４０２に分割した後のＳＦＳイメージ４００の一例である。部分４０２は、イメージの１ブロック（例えば、「ブロック４」）の部分(portion or part)を含むが、そのように限定されるのではない。例えば、一実施形態の分割後、ブロック２は、部分４０２−２ａ、４０２−２ｂ、および４０２−４ｃを含み、ブロック４は、部分４０２−４ａおよび４０２−４ｂを含む。分割動作の後、ブロックは、ブロックのデータ内容および／またはＳＦＳイメージの特定の構造に対してしかるべき数の部分であれば、いくつでも収容することができる。これらの部分は、例えば、スーパー・ブロック／ヘッダ部分、制御メタデータ部分、ファイル部分等を含む。ＳＦＳイメージ処理モジュール１０２は、圧縮（イメージが圧縮されている場合）、解読（イメージが暗号化されている場合）、および／またはイメージ処理モジュール１０２が受信したイメージからデータを抽出するために必要な他のいずれの処理でも実行することができる。
【００２３】
また、一実施形態のイメージ処理モジュール１０２は、例えば、ＳＦＳイメージ／ファイル名、ならびにＳＦＳイメージ／ファイル名の１つ以上の場所というような、マッピング情報を含むファイルも出力する。このファイルを、ここでは、ヒント・ファイルと呼ぶが、そのように限定されるのではない。
【００２４】
更新しようとするイメージが、前述のようなＣＲＡＭＦＳイメージである場合、一実施形態のイメージ処理モジュール１０２は、ＣＲＡＭＦＳイメージをデコードし、イメージをＣＲＡＭＦＳフォーマットから分割ファイルに変換する。分割ファイルは、イメージの１つまたは複数の特定部分のデータを、その部分の追加情報と共に含む。これらの部分の追加情報は、例えば、その部分のＲＯＭにおける場所、ブロックおよびその部分を含むブロックのサイズ、その部分および／またはブロックのオフセットの情報、その部分および／またはブロックのサイズ情報、その部分の非圧縮サイズ（その部分が圧縮されている場合）、および／またはヘッダおよびテール・バイトを含み、これら以外にも様々な情報がある。分割ファイルの名称は、ここに記載するように、分割ファイルの情報の全てを提供する。命名における規則を以下に説明する。
【００２５】
ＣＲＡＭＦＳイメージを変換し分割する際、イメージ処理モジュール１０２は、スーパー・ヘッダおよびディレクトリ・ヘッダの各々を分割ファイルにコピーする。更に、以下に規定するように、これらのヘッダに名称を割り当てる。
【００２６】
ＣＲＡＭＦＳイメージのシンボル・データ区間は、圧縮されている特殊なファイル・データ区間である。したがって、イメージ処理モジュールは、シンボル・データ区間を圧縮ファイルとして処理する。
【００２７】
イメージ処理モジュール１０２は、ＣＲＡＦＭＳイメージの圧縮ファイルを変換し分割する。ＣＲＡＭＦＳイメージの圧縮ファイル区間は、ヘッダと、一連の圧縮データ区間とを含むが、そのように限定されるのではない。各圧縮部分は、伸張した場合、ページ・キャッシュ・サイズ（例えば、ＣＲＡＭＦＳイメージのページ・キャッシュ・サイズは、４０９６バイトである）以下である。イメージ処理モジュール１０２は、ヘッダを、イメージのその他の部分とは別個にコピーする。同じブロック境界内に入るファイルの部分を伸張し、繋ぎ合わせ、スプリット・ファイルに出力する。伸張した部分の総和が、開始および終了オフセットを含んで、１物理ブロック・サイズ未満である限りにおいて（例えば、ＲＡＭの制約）、これを併合技法と呼ぶ。ブロックの境界を跨るイメージの部分は、伸張せず、代わりに、境界で切断し、分割ファイルとして出力する。
【００２８】
伸張した分割ファイルの１つ以上の部分に対して、一実施形態のイメージ処理モジュール１０２は、分割ファイルの圧縮コピーも生成する。この追加の分割ファイルは、差異ファイルおよび／またはデルタ・パッケージを計算する差異に用いるために、差異エンジン１０６に供給することができる。
【００２９】
一実施形態のイメージ処理モジュール１０２は、eXecute In Place（ＸＩＰ）ファイル区間を変換し、ブロックの境界において分割して、ＸＩＰファイル区間を二進イメージとして扱う。ＸＩＰファイルは圧縮されていない。ＸＩＰ区間におけるパディング(padding)は、原ファイルの内容の一部として扱われる。これが意味するのは、ＸＩＰファイル区間に対応する分割ファイルは、実データ内容、およびパディング・バイトも含むということであるが、実施形態はそのように限定されるのではない。
【００３０】
一実施形態のイメージ処理モジュール１０２は、特殊ノードに対して分割されたデータ区間は生成しない。その理由は、特殊ノードはＣＲＡＭＦＳイメージのディレクトリ区間におけるエントリのみを有し、したがってイメージのデータ区間における区間を有していないからである。
【００３１】
ＣＲＡＭＦＳイメージの内容は、イメージのために予約されている領域全体を消費しない。したがって、ＣＲＡＭＦＳイメージの末尾は、ＣＲＡＭＦＳイメージのデータの終端とイメージの予約エリアの終端との間に、パディング・バイトを含むことができる。一実施形態のイメージ処理モジュール１０２は、以下で説明するように、ＣＲＡＭＦＳイメージのいずれのパディング・バイトでも、分割ファイルにコピーする。
【００３２】
前述のように、分割ファイルは、イメージの１つまたは複数の特定部分のデータを、その部分の追加情報と共に含む。これらの部分の追加情報は、例えば、その部分のＲＯＭにおける場所、ブロックおよびその部分を含むブロックのサイズ、その部分および／またはブロックのオフセットの情報、その部分および／またはブロックのサイズ情報、その部分の非圧縮サイズ（その部分が圧縮されている場合）、および／またはヘッダおよびテール・バイトを含み、これら以外にも様々な情報がある。分割ファイルのファイル名フォーマットは、一実施形態では、次の通りである。
【００３３】
【表１】
0005173427.tif 000002
【００３４】
この分割ファイル・ファイル名フォーマットのコンポーネントは、次のように、分割ファイル部分の情報を表す。「＜Ｒｎ＞」は、ＲＯＭ番号を表す。「＜Ｂｎ＞」は、ブロック番号を表す。「＜Ｂｚ＞」は、ブロック・サイズを表す。［＜Ｏｆ＞」は、（ＲＯＭ上の）データ・部分のオフセットを表す。「＜Ｓｚ＞」は、（ＲＯＭ上の）データ部分のサイズを表す。「＜ＵＳｚ＞」は、（伸張したデータの）（ＲＡＭ上の）分割部分のサイズを表す（任意）。「＜Ｏｓ＞」は、オフセットからの圧縮データの始点のオフセット（４バイト単位で）を表す（任意）（このフィールドの範囲は、１から２５５であるが、この範囲に限定されるのではない）。「＜Ｏｅ＞」は、利用可能なデータの終端からの圧縮データのオフセット（バイト単位）を表す（任意）（このフィールドの範囲は、１から３であるが、この範囲に限定されるのではない）。
【００３５】
イメージ処理モジュール１０２の変換および分割動作の間に生成した分割毎に、対応するヒント情報も生成する。このヒント情報は、キー値対であるが、そのように限定されるのではない。一実施形態のキー値対では、キーは分割ファイルの名称であり、値は、最大パスを有するＣＲＡＭＦＳイメージにおけるファイルの名称である。ヒント情報の一例は、「１＿２＿０＿６５５３６＿２３５＼ｒｏｏｔ＼ｂｉｎ＼ｌｓ．ｂｉｎ」であり、ここで、１＿２＿０＿６５５３６＿２３５は分割ファイルの名称であり、＼ｒｏｏｔ＼ｂｉｎ＼ｌｓ．ｂｉｎはＣＲＡＭＦＳイメージにおける対応するＬｉｎｕｘファイルの名称である。スーパー・ヘッダ、ディレクトリ・ヘッダ、およびテール・データのような区間には、それぞれ、「ＳＵＰＥＲ＿ＨＥＡＤＥＲ」、「ＤＩＲ＿ＨＥＡＤＥＲ」および「ＴＡＩＬ＿ＨＥＡＤＥＲ」のような、特殊な値が与えられる。
【００３６】
従属性生成モジュール１０４は、ここでは従属性分析モジュールまたは従属性生成部とも呼ばれ、原イメージおよび新イメージ間のマッピングまたは一致(alignment)を判定または生成する。一致は、原イメージの部分に従属する新イメージの部分に関する情報を含む。また、一実施形態の一致は、プロセッサに基づく携帯デバイス内にホストされている原イメージの内部更新の間に新イメージの部分を更新すべきシーケンスに関する情報も含む。従属性生成モジュール１０４は、照合を実行する際に、ＳＦＳの特定構造の情報をドメイン知識（例えば、ヒント・ファイルからの情報）として用い、一致は、イメージのブロック境界に関して判定されるが、そのように限定されるのではない。
【００３７】
図５は、一実施形態における、従属性生成５００のフロー図である。従属性生成５００は、一実施形態では、従属性分析アルゴリズムまたはプログラムであり、図１を参照して先に説明したようなＳＦＳ差異検出システムにおいて用いられるが、他の差異検出システムにおいても用いることができる。一実施形態の従属性生成５００は、原ＣＲＡＭＦＳイメージのヒント・ファイルにおけるＬｉｎｕｘファイル名をアルファベット順にソートし（５０２）、新ＣＲＡＭＦＳイメージのヒント・ファイルにおけるＬｉｎｕｘファイル名をアルファベット順にソートする（５０４）。
【００３８】
Ｌｉｎｕｘファイルが１つよりも多い部分を占める場合、部分従属性計算またはプロセスを用いて、これらの部分間における従属性を判定する（５０８）（例えば、最も長い共通サブストリング（ＬＣＳ）分析のような判断基準を用いる）。当該部分が圧縮および／または暗号化されている場合、一致度を高めるために、従属性の計算に先だって、またはこれと同時に、この部分を伸張および／または解読する。図６は、一実施形態において、従属性生成５００を用いて識別した部分従属性の一例６００である。この例では、Ｌｉｎｕｘファイルの新バージョン（Ｎｅｗ）の部分３が、同じファイルの原バージョン（Ｏｒｉｇｉｎａｌ）の部分２および部分３に従属する。
【００３９】
従属性生成５００は、少なくとも１つのファイル部分従属性テーブルを形成または生成する（５１０）。１つの原部分のみに従属する新部分毎に、内容を、その従属する原部分のそれと比較する（５１２）。比較結果が、内容および部分の名称双方が同一であることを示し、内容に変化もずれもないことを意味する場合、新部分および原部分双方をリストから除去する。
【００４０】
従属性生成５００は、ファイル部分従属性テーブルと、原ＣＲＡＭＦＳイメージおよび新ＣＲＡＭＦＳイメージのヒント・ファイルを組み合わせ（５１４）、ブロック優先グラフ(block precedence graph)を生成する。例えば、カラー・マーキングのようなしかるべきアルゴリズムを用いて、ブロック優先グラフにおけるループ／サイクルを特定する（５１６）または見出す。ブロック優先グラフにおいて特定したいずれのループ／サイクルも、次に、例えば、最小デルタを有するブロックの除去というような、少なくとも１つの判断基準にしたがって分解する（５１８）。その結果得られた非周期的有向ブロック優先グラフ(acyclic directed block precedence graph)を位相的にソートし（５２０）、ソートしたブロック従属性優先度に応じて、ファイル部分従属性テーブルを再度並べ換える（５２２）。次いで、従属性生成５００は、ファイル部分従属性テーブルを出力する（５２４）。ここで、このテーブルを従属性テーブルと呼ぶ。一実施形態のテーブルは、２つの列を含む。第１列は新部分分割ファイル名のためにあり、一方第２列は旧部分分割ファイル名のためにある。一例は、以下の通りである。
【００４１】
【表２】
0005173427.tif 000003
【００４２】
先の例では、ブロック１００の新部分、1＿100＿65536＿32768＿32768が２つの旧部分1＿108＿65536＿32768＿32768および1＿109＿65536＿0＿65536に従属する。ブロック１０１の新部分1＿101＿65536＿0＿65536は、１つの部分1＿110＿65536＿0＿65536 のみに従属する。
【００４３】
差異エンジン１０６は、概略的には、新イメージの各新部分のデータと原イメージの原部分のデータとの間の部分レベルでの差異を計算する。更に具体的には、差異エンジン１０６は、従属性生成モジュール１０４からの情報を用いて、新イメージの各部分が従属する旧イメージの１つ以上の部分を読み取る、即ち、集める。一実施形態の差異エンジン１０６は、新部分の内容と、新部分が従属する原部分の内容との間の差異を計算する。原部分および新部分間のデータにおいて特定した差異をファイルにエンコードする。このファイルをここではデルタ・ファイルと呼ぶ。原部分および新部分間のデータにおけるエンコードされた差異に加えて、デルタ・ファイルは、新部分および原部分間の従属性の従属性情報のような、制御情報を含むことができる。更に、デルタ・ファイルは、デルタ本体の検証情報（例えば、チェックサム値、巡回冗長コード（ＣＲＣ）等）、更新するイメージの原部分、および対応する従属性情報を含むことができる。
【００４４】
前述の差異エンジン１０６は、部分レベルで原イメージおよび新イメージ間の差異を判定するが、代替実施形態の差異エンジンは、異なる粒度（例えば、多数の部分等）を用いて差異を判定することもできる。更に、前述の差異エンジン１０６は従属する原イメージの部分とは異なる新イメージの部分毎にデルタ・ファイルを生成するが、代替実施形態では、部分毎に１つよりも多いデルタ・ファイルを生成することもでき、あるいは１つのデルタ・ファイルの中に多数の部分の差異情報を含むこともできる。
【００４５】
パッケージング・エンジン１０８は、差異エンジン１０６が生成したデルタ・ファイルを受け取り、デルタ・ファイルを組み立ててデルタ・パッケージまたは差異パッケージを作成する。一実施形態のパッケージング・エンジン１０８は、更新順序即ちシーケンスに応じて、デルタ・ファイルを組み立ててデルタ・パッケージを作成するが、そのように限定されるのではない。また、パッケージング・エンジン１０８は、デルタ・ファイルおよび／またはデルタ・パッケージに対して追加の動作、例えば、デルタ・パッケージの暗号化も実行することができる。
【００４６】
ＳＦＳイメージ更新の間、イメージの一部を単に、イメージの原バージョンにおけるある場所からイメージの新バージョンにおける異なる場所に移動させる、即ち、ずらすことが頻繁に行われる。１バイトのずれに対してでも、更新プロセスのコンポーネントは、デバイス・ブロック全体を書き換えて、ＳＦＳイメージを更新しなければならない。図７は、ＩＮＳＦＳイメージのブロック３の第２部分が、原ＳＦＳイメージのブロック２の第３部分と全く同一のコピーである例７００を示す。加えて、変化（複数の変化）がイメージの後続のブロックに伝搬する場合、後続のブロックも書き換えなければならない。一実施形態のイメージ更新では、どこにコピーするか、そしてシフトした新部分に対してどれくらいのバイトをコピーするのかに関するシフト情報をエンコードすることによって、シフトした部分の情報をエンコードする。このシフト情報のエンコードを、ここでは、WHOLE＿IS＿COPYと呼ぶが、そのように限定されるのではない。WHOLE＿IS＿COPYの使用により、デルタ・ファイルおよび／またはデルタ・パッケージのサイズを縮小し、更新を行うのに必要な時間を短縮する。
【００４７】
加えて、部分ファイル名が、その部分の圧縮のために、任意のフィールドを有する場合、差異エンジン１０６は、WHOLE＿IS＿COPYを用いて、これら任意のフィールドを除去し、ＣＲＡＭＦＳイメージ更新中における圧縮／伸張のオーバーヘッドを回避する。任意フィールドの除去によって、一実施形態の更新を実行する時間を短縮することができる。例えば、新バージョンのブロック３の部分２が原バージョンにおけるブロック２の部分３のWHOLE＿IS＿COPYである場合、一実施形態の差異エンジン１０６は、デルタ・パッケージを生成するときに、新バージョンにおけるブロック３の部分２、および原バージョンにおけるブロック２の部分３の部分ファイル名における任意フィールドを除去する。
【００４８】
図８は、一実施形態におけるＣＲＡＭＦＳイメージの差異検出プロセス８００を示す。米国特許出願第１０／１４５，５４５号に記載されているように、新ソフトウェア・コンポーネント流通業者（ＮＳＣＤ）から、新イメージを受信する。差異検出プロセス８００では、受信したイメージがＣＲＡＭＦＳイメージであるか否か判定し、当力したイメージがＣＲＡＭＳＦイメージであると判定した場合、一実施形態の差異検出システム（例えば、差異検出システム１００）を自動的にコールする。登録したイメージがＣＲＡＭＦＳイメージでない場合、イメージ・フォーマット毎にイメージを区別する。ＣＲＡＭＦＳ分割アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、差異検出システム１００を参照して説明したように、イメージ予備処理モジュール１０２とすることができ、ＣＲＡＭＦＳイメージをホストするクライアント・デバイスのソフトウェアおよびデバイス情報ならびにメモリの制約に合わせて、ＣＲＡＭＦＳイメージを分割する。前述した分割ファイルおよびリスト／ヒント・ファイルから分割が得られるが、実施形態はそのように限定されるのではない。
【００４９】
差異検出プロセス８００は、イメージの部分を併合して、デルタ・パッケージのオーバーヘッドおよび更新時間を削減する。一実施形態では、イメージの部分併合を行うのは、当該部分が同じＬｉｎｕｘファイルに属するとき、イメージの同じ物理ブロック内に位置するとき（ＲＯＭの制約）、開始および終端オフセットを含むそれらのサイズ（伸張時）が１物理ブロック・サイズ以下であるとき（ＲＡＭの制約）、および／またはデータ・ヘッダが予め指定したサイズ（例えば、バイト数、例えば、（２５５×４）バイト）を超過しないときである。何故なら、一実施形態では、この値を格納するためにわずか１バイトしか割り当てられていないからである。
【００５０】
従属性ＡＰＩは、差異検出システム１００を参照して説明したような、従属性生成モジュール１０４とすることができ、ＣＲＡＭＦＳ分割ＡＰＩからのヒント・ファイルを用いて従属性を判定し、優先情報を更新し、前述のような従属性テーブルを生成する。差異エンジンＡＰＩは、差異検出システム１００を参照して説明したような、差異エンジン１０６とすることができ、前述のようにイメージの新部分毎に差異ファイルを生成する。ＮＳＣＤは、例えば、図１を参照して先に説明したようなパッケージング・エンジン１０８を用いて、デルタ・ファイルをパッケージしデルタ・パッケージを生成する。
【００５１】
前述のＳＦＳ差異検出システム１００は、イメージ処理モジュール１０２、従属性生成モジュール１０４、差異エンジン１０６、およびパッケージング・エンジン１０８を別個のモジュールまたはコンポーネントとして含むように記載したが、実施形態はそのように限定されるのではない。例えば、代替実施形態は、モジュール１０２〜１０８の機能を１つ以上のモジュールに含むことができ、および／またはモジュール１０２〜１０８の機能をいずれの数のモジュールまたはシステム・コンポーネント間にも分散することができる。
【００５２】
実施形態のＳＦＳ差異検出および更新では、更新を含み、これによって、前述のように、携帯電子デバイスのようなデバイス上にホストされているＳＦＳイメージをデバイス上において内部で更新する。更新では、少なくとも１つの結合部を介して携帯デバイスにおいてデルタ・ファイルを受信する。携帯デバイス上にホストされている原部分のうち、従属部分を組み立て、従属する原区間のうち、受信したデルタ・ファイルに対応する少なくとも１つを特定する。更新により、携帯デバイス上において、特定したデルタ・ファイルに対応する少なくとも１つの新部分を再現する。再現した新イメージの新部分を、携帯デバイスのＲＯＭに書き込む。
【００５３】
図９は、一実施形態におけるＳＦＳ差異検出および更新システム５００のブロック図である。システム９００は、ＳＦＳ差異検出システム１００と、ＳＦＳ更新システム５５０とを含む。ＳＦＳ差異検出システム１００は、図１を参照して前述したように、イメージ処理モジュール１０２、従属性生成モジュール１０４、差異エンジン１０６、およびパッケージング・エンジン１０８を含むが、そのように限定されるのではない。動作において、ＳＦＳ差異検出システム１００は、少なくとも１つの原ＳＦＳイメージおよび少なくとも１つの新ＳＦＳイメージ１１４を受信し、部分レベルの差異検出を行い、ここで述べたように１つ以上のデルタ・ファイルを含むデルタ・パッケージ１２２を生成する。
【００５４】
ＳＦＳ差異検出システム１００は、プロセッサに基づくまたはコンピュータ・システムにおいてデルタ・ファイルを生成するか、あるいはプロセッサに基づくまたはコンピュータ・システムの下で走る。ＳＦＳ差異検出システムが走る基盤であるコンピュータ・システムは、共に動作する計算コンポーネントおよびデバイスのいずれかの集合体を含む。これは、当技術分野では周知である。また、コンピュータ・システムは、更に大きなコンピュータ・システムまたはネットワーク内部の一コンポーネントまたはサブシステムであることも可能である。
【００５５】
ＳＦＳ更新システム５５０は、プロセッサに基づくデバイス上にホストされており、デルタ・ファイルを受信し、携帯デバイス上にホストされている原イメージに対して更新を行う。ＳＦＳ更新システム５５０が走る、プロセッサに基づくデバイスまたはシステムは、共に動作する計算コンポーネントおよびデバイスのいずれかの集合体を含む。これは、当技術分野では周知である。また、コンピュータ・システムは、更に大きなコンピュータ・システムまたはネットワーク内部の一コンポーネントまたはサブシステムであることも可能である。プロセッサに基づくデバイスまたはシステムは、移動デバイス、例えば、セルラ電話機、パーソナル・コンピュータ、携帯計算デバイス、携帯電話機、携帯通信デバイス、加入者デバイスまたはユニット、およびパーソナル・ディジタル・アシスタント（ＰＤＡ）を含む。移動デバイスは、「移動通信デバイス」、「携帯通信デバイス」、および「通信デバイス」とも呼ばれ、このようなデバイスおよび同等物全てを含み、ワイヤレスの通信デバイスに限定されるのではない。
【００５６】
ＳＦＳ差異検出システム１００およびＳＦＳ更新システム５５０は、通信経路５０６を通じて通信する。通信経路５０６は、プロセッサに基づくデバイスまたはシステム間でファイルを通信または転送する媒体であればいずれでも含む。したがって、通信経路５０６は、ワイヤレス結合部または接続部、有線結合部または接続部、および混成ワイヤレス／有線結合部または接続部を含む。また、通信経路５０６は、ネットワークまたはネットワークコンポーネントへの結合部または接続部、および／またはこれらを経由する結合部または接続部も含み、ネットワークには、ローカル・エリア・ネットワーク（ＬＡＮ）、市内エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業所有のネットワーク、オフィス間またはバックエンド・ネットワーク、およびインターネットが含まれる。通信経路５０６は、通信サービス・プロバイダまたは通信会社の種々のネットワークコンポーネント（図示せず）を含むことができるが、そのように限定されるのではない。更に、通信経路５０６は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクのような、取り外し可能な固定媒体、ならびに電話回線、バス、および電子メール・メッセージを含む。
【００５７】
デルタ・パッケージ１２２は、通信経路５０６を通じて、ＳＦＳ更新システム５５０に転送または送信される。ＳＦＳ更新システム５５０は、更新モジュール５５２を含む。更新モジュール５５２は、デルタ・パッケージ１２２の情報を用いて、携帯デバイス上にホストされているＳＦＳイメージ１１２Ｐの内部更新５５４を実行する。更新モジュール５５２は、概略的に、デルタ・パッケージ１２２の内容を、携帯デバイス上にホストされている原ＳＦＳイメージ１１２Ｐの部分に適用することにより、携帯デバイスにおいて新イメージ１１４Ｐを再現する。再現された新イメージ１１４Ｐの部分は、例えば、ホストされている原イメージ１１２Ｐ上に新イメージ１１４Ｐを上書きすることにより、携帯デバイスのＲＯＭに書き込む。このＳＦＳ更新プロセスを完了すると、この時点で携帯デバイス上にホストされているＳＦＳイメージは、第１ＳＦＳ差異検出システム１００において受信した新ＳＦＳイメージ１１４と実質的に同一となる。
【００５８】
図１０は、一実施形態におけるＳＦＳ更新１０００のフロー図である。一実施形態のＳＦＳ更新１０００は、例えば、リソースに制限のある計算デバイスにおいて用いられる。ＳＦＳ更新では、少なくとも１つの結合部を介して携帯デバイスにおいてデルタ・ファイルを受信する（１００２）。携帯デバイス上にホストされているＳＦＳイメージの従属する原部分を組み立てる（１００４）。更新１０００は、受信したデルタ・ファイルに対応する従属原区間の少なくとも１つを特定する（１００６）。更新１０００は、携帯デバイス上において、特定したデルタ・ファイルに対応する少なくとも１つの新部分を再現する（１００８）。続いて、再現した新イメージの新部分を、例えば、デルタ・パッケージにおいて受信した全てのデルタ・ファイルの処理と同時に、またはこれに続いて、携帯デバイスのメモリ（例えば、ＲＯＭ）に書き込む。
【００５９】
図１１は、一実施形態における、デバイス内でのＳＦＳイメージの内部更新１１００のフロー図である。更新１１００は、例えば、図９を参照して前述したように、更新モジュール５５２によって実行することができる。更新１１００では、受信したデルタ・パッケージ内にエンコードされている制御情報を用いて、デルタ・パッケージのデータが破損していないことを判断する（１１０２）ことにより、デルタ・パッケージの内容の完全性を検証する。更新する各ＳＦＳイメージ部分の完全性も検証することができる。デルタ・パッケージにいずれかのデータが破損している場合、誤りを報告する（１１０４）。
【００６０】
デルタ・パッケージのデータが破損していないと判断した場合（１１０２）、更新１１００は、更新を開始するために、デルタ・パッケージの始点にポインタを設定する（１１０６）。部分更新順序およびデバイス・ブロック更新順序は、一実施形態のデルタ・ファイル内に暗示的にエンコードされている。更新の開始時にデルタ・ファイルがあることを判定し（１１０８）、更新を進める。デルタ・ファイルは、セキュリティの目的のために暗号化することもでき、その場合、更新プロセスの開始の前またはそれと同時に、デルタ・ファイルを解読する（しかるべきキーを用いる）。更新１１００は、デルタ・ファイルの内容の情報（例えば、制御情報）を用いて、従属性形成情報をデコードし（１１１２）、更に（必要であれば）原イメージの関連部分を読み取り（１１１２）、原イメージの従属部分を解凍 (unzip)即ち解読し（１１１２）、携帯デバイス上にホストされている原イメージの原部分の従属する内容を組み立てる（１１１２）。
【００６１】
更新１１００において、新イメージの部分が、イメージの原バージョンにおけるある場所からイメージの新バージョンにおける異なる場所に移動即ちシフトされた原イメージの一部と同一のコピーであるか否か判定を行う（１１１３）。更新において、新イメージの部分が原イメージの部分と同一のコピーであると判定した場合（１１１３）、一実施形態の更新では、シフトした新部分について、どこにコピーするか、そして何バイトをコピーするかに関するシフト情報をエンコードすることにより、シフトした部分の情報をエンコードする。シフト情報のこのエンコードは、本明細書では、上で詳述したようにWHOLE＿IS＿COPYと呼ぶ。シフトした部分のエンコード情報を用いて、新イメージの部分を、原イメージのブロックにおいて予め指定されている場所、即ち、特定の場所にコピーし（１１１５）、それが対応する原部分と置き換える。
【００６２】
更新１１００では、デルタ・ファイルの内容を原イメージの原部分の従属する内容に適用する（１１１４）ことにより、更新するイメージの新部分を再現する。一旦再現した新部分は、ホスト・デバイスにおいてＲＡＭのエリアに書き込まれ、適宜ＳＦＳイメージに封鎖(zip)および／または暗号化される（１１１４）。新部分は、原イメージのブロック内の特定の場所に収容され（１１１５）、対応する原部分と交換する。新イメージの各ブロックを作成または再現した後、その個々のブロックをＲＯＭに書き込む。代替実施形態では、再現したブロックを更新プロセスにおける他の時点でＲＯＭに書き込んでもよい。次いで、更新プロセスは、次のブロックに対するデルタ・ファイルの処理に進む。
【００６３】
前述の更新１１１２、１１１３、１１１４および１１１５は、デルタ・パッケージの終点に達し、デルタ・パッケージのデルタ・ファイル全てが処理され終えるまで継続する。このようにする際に、デルタ・パッケージが、原イメージの追加部分を更新する差異に用いるために、別のデルタ・ファイルを含むか否か判定を行う（１１１６）。デルタ・パッケージが、更新する原イメージの追加部分に対応する未処理のデルタ・ファイルを含む場合、動作は、これら未処理のデルタ・ファイルを読み取り適用するために戻る。デルタ・パッケージのデルタ・ファイル全てを処理し終え、原イメージに適用したと判定した場合（１１１６）、更新１１００は、新ＳＦＳイメージを携帯デバイスのＲＯＭに書き込む（１１１８）。一実施形態の更新では、原ＳＦＳイメージを新ＳＦＳイメージで上書きするが、代替実施形態では、新ＳＦＳイメージをＲＯＭの１つ以上のその他エリアまたはその他のデバイス・メモリ・エリアに書き込むことができる。
【００６４】
図１、図２、図３、図５、図８、図９、図１０、および図１１を参照すると、前述のプロセスの動作は、少なくとも１つのプロセッサの制御下にあるが、そのように限定されるのではない。当業者であれば、これらのフロー図およびここに提示した詳細な説明に基づいて、ソース・コード、マイクロコード、プログラム・ロジック・アレイを作成することができ、あるいは、実施形態のＳＦＳ差異検出およびＳＦＳ更新をそれ以外でも実現することができる。これらのフロー図にしたがって動作するアルゴリズムまたはルーチンは、あるいは関連するプロセッサの一部をなすコンピュータ・システムの機械読み取り可能あるいはコンピュータ読み取り可能メモリ・エリアまたはデバイス（例えば、不揮発性メモリ）、関連するメモリ・エリア内、ディスクのような着脱可能媒体内に格納するか、あるいはハードワイヤ状とするか、電子的消去可能プログラム可能ＲＯＭ（「ＥＥＰＲＯＭ」）半導体チップのようなチップ内またはこれらのコンポーネントのいずれかの組み合わせに格納するが、そのように限定されるのではない。
【００６５】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムイメージの差異を検出するデバイスを含む。一実施形態のデバイスは、スタティック・ファイル・システムのイメージを受信する受信部を備えており、このイメージが原イメージおよび新イメージを含む。また、一実施形態のデバイスは、原イメージを複数の原区間に分割し、新イメージを複数の新区間に分割するプリプロセッサも備えている。一実施形態のデバイスは、複数の原区間と複数の新区間との間の従属性一致を識別する従属性生成部を備えている。一実施形態のデバイスは、新区間の少なくとも１つについてデルタ・ファイルを生成する差異エンジンを備えており、デルタ・ファイルは、少なくとも１つの新区間と、少なくとも１つの新区間が従属する、原区間の少なくとも１つとの間の差異を含む。
【００６６】
一実施形態のデバイスは、更に、更新シーケンスにしたがって、新区間の少なくとも１つについて、デルタ・ファイルを組み立てるパッケージング・エンジンを備えている。
一実施形態のＳＦＳ差異検出および更新は、ブロック情報およびイメージ構造情報に基づいて、ＳＦＳイメージのブロックを部分に分割するステップを備え、ＳＦＳイメージが原イメージおよび新イメージを含む、方法を含む。一実施形態の方法は、新イメージの新部分についてデルタ・ファイルを生成することにより、部分レベルの差異検出を実行するステップを備えており、デルタ・ファイルは、新部分と、原イメージの１つ以上の対応する原部分との間の差異の情報を含む。一実施形態の方法は、デルタ・ファイルをクライアント・デバイスに転送するステップを備えている。一実施形態の方法は、ホスト・デバイスのランダム・アクセス・メモリ内のデバイス・ブロックにおいて新イメージの全ての部分を再現し、デバイス・ブロックをホスト・デバイスのリード・オンリ・メモリに書き込むことによって、デルタ・ファイルの情報を用いて、クライアント・デバイスの目標ＳＦＳイメージを更新するステップを備えている。
【００６７】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信するステップを備え、このイメージが原イメージおよび新イメージを含む、方法を含む。一実施形態の方法は、原イメージを複数の原区間に分割し、新イメージを複数の新区間に分割するステップを備えている。一実施形態の方法は、複数の原区間と複数の新区間との間の従属性一致を識別するステップを備えている。一実施形態の方法は、新区間の少なくとも１つについてデルタ・ファイルを生成するステップを備えており、デルタ・ファイルが、少なくとも１つの新区間と、原区間のうち少なくとも１つの新区間が従属する少なくとも１つの原区間との間の差異を含む。
【００６８】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信する受信部を備え、イメージが原イメージおよび新イメージを含む、システムを含む。一実施形態のシステムは、受信部に結合され、原イメージを複数の原区間に分割し、新イメージを複数の新区間に分割するプリプロセッサを備えている。一実施形態のシステムは、プリプロセッサに結合され、複数の原区間と複数の新区間との間の従属性一致を識別する従属性生成部を備えている。一実施形態のシステムは、従属性生成部に結合され、新区間の少なくとも１つについてデルタ・ファイルを生成する差異エンジンを備えており、デルタ・ファイルは、少なくとも１つの新区間と、少なくとも１つの新区間が従属する、原区間の少なくとも１つとの間の差異を含む。一実施形態のシステムは、差異エンジンに結合され、デルタ・ファイルを組み立ててデルタ・パッケージを作成するパッケージング・エンジンを備えている。
【００６９】
一実施形態のシステムは、携帯デバイスにおいて更新エンジンを備えており、この携帯デバイスは、少なくとも１つの結合部を介して、デルタ・パッケージを受信し、更新エンジンは、携帯デバイス上にホストされている複数の原区間の従属する原区間を組み立て、デルタ・パッケージのうち、従属する原区間の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定し、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新区間を再現する。
【００７０】
一実施形態の更新エンジンは、デルタ・パッケージを受信し、このデルタ・パッケージの少なくとも１つのデルタ・ファイルの内容の完全性を検証する。
一実施形態の更新エンジンは、携帯デバイスの第１メモリ・エリアにおいて少なくとも１つの新区間を再現する。
【００７１】
一実施形態の第１メモリ・エリアは、ランダム・アクセス・メモリ（ＲＡＭ）内にある。
一実施形態の更新エンジンは、従属する原区間の少なくとも１つに対応するデルタ・パッケージのデルタ・ファイルを特定し続け、特定したデルタ・ファイルに対応する新区間を再現し続ける。
【００７２】
一実施形態の更新エンジンは、デルタ・パッケージのデルタ・ファイル全てを、携帯デバイス上にホストされている原区間に適応し終えたことを判定し、この判定に応答して、携帯デバイスの第２メモリ・エリアに、前記再現した新区間を書き込む。
【００７３】
一実施形態のエンジンは、再現した新区間の各ブロックを、第２メモリ・エリアに書き込む。
一実施形態の第２メモリ・エリアは、リード・オンリ・メモリ（ＲＯＭ）内にある。
【００７４】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信するステップを備え、このイメージが原イメージおよび新イメージを含み、イメージが複数のブロックを含む、方法を含む。一実施形態の方法は、複数のブロックの情報を用いることによって原イメージを分割してイメージを複数の部分に分割するステップを備えている。一実施形態の方法は、原イメージおよび新イメージの複数の部分間における差異を判定することによって、イメージの内容間の差異を判定するステップを備えている。一実施形態の方法は、少なくとも１つの部分についての差異を含むデルタ・ファイルを生成するステップを備えている。
【００７５】
一実施形態の方法は、デルタ・ファイルを、原イメージをホストする携帯ワイヤレス・デバイスに転送するステップを備えている。
一実施形態の方法は、少なくとも１つの結合部を介して、携帯デバイスにおいてデルタ・ファイルを受信するステップを備えている。一実施形態の方法は、携帯デバイス上にホストされている複数の原部分のうち従属する原部分を組み立てるステップを備えている。一実施形態の方法は、従属する原部分のうち、受信したデルタ・ファイルに対応する少なくとも１つの部分を特定するステップを備えている。一実施形態の方法は、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップを備えている。
【００７６】
一実施形態の方法は、複数のデルタ・ファイルを組み立ててデルタ・パッケージを作成するステップを備えている。
一実施形態の方法は、デルタ・パッケージを、原イメージをホストする携帯ワイヤレス・デバイスに転送するステップを備えている。
【００７７】
一実施形態の方法は、携帯デバイスにおいて、少なくとも１つの結合部を介して、デルタ・パッケージを受信するステップを備えている。一実施形態の方法は、携帯デバイス上にホストされている複数の原部分のうち、従属する原部分を組み立てるステップを備えている。一実施形態の方法は、デルタ・パッケージのうち、従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定するステップを備えている。一実施形態の方法は、少なくとも１つの特定したデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップを備えている。
【００７８】
一実施形態のＳＦＳ差異検出および更新は、実行可能命令を含むコンピュータ読み取り可能媒体を含み、処理システムにおいて実行すると、スタティック・ファイル・システムのイメージを受信することによってイメージ間の差異を判定し、このイメージが原イメージおよび新イメージを含み、イメージが複数のブロックを含む。更に、本媒体は、複数のブロックの情報を用いることによって原イメージを分割してイメージを複数の部分に分割することにより、イメージ間の差異を判定する。本媒体は、更に、原イメージおよび新イメージの複数の部分間における差異を判定することによって、イメージの内容間の差異を判定することにより、イメージ間の差異を判定する。本媒体は、更に、少なくとも１つの部分についての差異を含むデルタ・ファイルを生成することによってイメージ間の差異を判定する。
【００７９】
本媒体は、更に、デルタ・ファイルを、原イメージをホストする携帯ワイヤレス・デバイスに転送することによって、イメージ間の差異を判定する。
本媒体は、更に、少なくとも１つの結合部を介して、携帯デバイスにおいてデルタ・ファイルを受信することによって、イメージ間の差異を判定する。本媒体は、更に、携帯デバイス上にホストされている複数の原部分の内従属する原部分を組み立てることによってイメージ間の差異を判定する。本媒体は、更に、従属する原部分のうち、受信したデルタ・ファイルに対応する少なくとも１つの部分を特定することによって、イメージ間の差異を判定する。本媒体は、更に、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現することによって、イメージ間の差異を判定する。
【００８０】
本媒体は、更に、複数のデルタ・ファイルを組み立ててデルタ・パッケージを作成することによって、イメージ間の差異を判定する。
一実施形態の媒体は、デルタ・パッケージを、原イメージをホストする携帯ワイヤレス・デバイスに転送することもできる。
【００８１】
一実施形態の媒体は、携帯デバイスにおいて、少なくとも１つの結合部を介して、デルタ・パッケージを受信する。一実施形態の媒体は、携帯デバイス上にホストされている複数の原部分のうち、従属する原部分を組み立てる。一実施形態の媒体は、デルタ・パッケージのうち、従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定する。一実施形態の媒体は、少なくとも１つの特定したデルタ・ファイルに対応する少なくとも１つの新部分を再現する。
【００８２】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムイメージの差異を検出するデバイスを含む。一実施形態のデバイスは、スタティック・ファイル・システムのイメージを受信する受信部を備えており、このイメージは原イメージおよび新イメージを含む。一実施形態のデバイスは、受信部に結合され、イメージを第１フォーマットから複数の分割ファイルに変換するプリプロセッサを備えており、分割ファイルは、原イメージの少なくとも１つの部分のデータと、部分の少なくとも１つの場所パラメータとを含む。一実施形態のデバイスは、は、プリプロセッサに結合され、新イメージの部分と原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部を備えている。一実施形態のデバイスは、従属性生成部に結合され、新イメージの少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンを備えており、デルタ・ファイルは、新イメージの少なくとも１つの部分と原イメージの少なくとも１つの部分との間の差異を含む。
【００８３】
一実施形態の第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである。
一実施形態のデバイスは、更に、差異エンジンに結合され、新イメージの全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている。
【００８４】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信するステップを備え、このイメージが原イメージおよび新イメージを含み、更にイメージが複数のブロックを含む方法を含む。一実施形態の方法は、イメージを複数の分割ファイルに変換するステップを備えており、この変換は、複数のブロックの情報を用いてイメージを分割してイメージを複数の部分に分割し、変換により、分割のヒント情報を生成する。一実施形態の方法は、原イメージの複数の部分と新イメージとの間の差異を判定することによって、イメージの内容間の差異を判定するステップを備えている。一実施形態の方法は、少なくとも１つの部分についての差異を含むデルタ・ファイルを生成するステップを備えている。
【００８５】
一実施形態における受信イメージは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである。
一実施形態の方法は、部分のデータを分割ファイルに書き込むステップを備えており、このデータは、前述の部分のメモリの場所、一部分を含むブロックのブロック情報、前述の部分およびブロックの少なくとも１つのオフセット情報、ならびに前述の部分およびブロックの少なくとも１つのサイズ情報のうち少なくとも１つを含む。
【００８６】
一実施形態の方法は、ヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている。
一実施形態の方法は、新イメージの少なくとも１つの部分と、原イメージの少なくとも１つの部分との間におけるあらゆる従属性を識別するステップを備えている。一実施形態の方法は、識別の従属性情報を含む部分従属性テーブルを生成するステップを備えており、部分従属性テーブルは、識別が、内容および部分名が新部分と新部分が従属する対応の原部分との間で同一であることを示す場合、新部分およびその対応する従属原部分を除外する。
【００８７】
一実施形態の方法は、原イメージと同じ内容および異なる部分名を有する新イメージのあらゆる同一部分を特定するステップを備えている。一実施形態の方法は、同一部分の場所およびサイズを含む同一部分の情報を生成するステップを備えており、デルタ・ファイルは、同一部分の情報を含む。
【００８８】
一実施形態の方法は、部分従属性テーブルと、ヒント情報とを組み合わせるステップを備えている。
一実施形態の方法は、ブロック優先グラフを生成し、ブロック優先グラフにおけるあらゆるサイクルを分解することによって、非周期的ブロック優先グラフを形成するステップを備えている。
【００８９】
一実施形態の方法は、非周期的ブロック優先グラフの情報を用いて、部分従属性テーブルを並べ換えることによって、再整列部分従属性テーブルを生成するステップを備えている。
【００９０】
一実施形態の方法は、デルタ・ファイルを、原イメージをホストするクライアント・デバイスに転送するステップを備えている。一実施形態の方法は、ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で新イメージの部分全てを再現し、デバイス・ブロックをホスト・デバイスのリード・オンリ・メモリに書き込むことによって、デルタ・ファイルの情報を用いて、クライアント・デバイスの目標イメージを更新するステップを備えている。
【００９１】
一実施形態の更新するステップは、クライアント・デバイス上にホストされている複数の原イメージの従属する原部分を組み立てるステップを備えている。一実施形態の更新するステップは、従属する原部分から、受信したデルタ・ファイルに対応する少なくとも１つを特定するステップを備えている。一実施形態の更新するステップは、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップを備えている。
【００９２】
一実施形態の方法は、複数のデルタ・ファイルを組み立ててデルタ・パッケージを作成するステップを備えている。
一実施形態の方法は、デルタ・パッケージを、原イメージをホストするクライアント・デバイスに転送するステップを備えている。
【００９３】
一実施形態の方法は、クライアント・デバイスにおいて、少なくとも１つのワイヤレス結合部を介して、デルタ・パッケージを受信するステップを備えている。一実施形態の方法は、クライアント・デバイス上にホストされている複数の原部分の従属する原部分を組み立てるステップを備えている。一実施形態の方法は、デルタ・パッケージから、従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定するステップを備えている。一実施形態の方法は、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップを備えている。
【００９４】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信するステップを備え、イメージが原イメージおよび新イメージを含む方法を含む。一実施形態の方法は、イメージを第１フォーマットから複数の分割ファイルに変換するステップを備えており、分割ファイルは、原イメージおよび新イメージの少なくとも１つの部分のデータと、この部分の少なくとも１つの場所パラメータとを含む。一実施形態の方法は、新イメージの部分と原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成するステップを備えている。一実施形態の方法は、新イメージの少なくとも１つの部分についてデルタ・ファイルを生成するステップを備えており、デルタ・ファイルは、新イメージの少なくとも１つの部分と原イメージの少なくとも１つの部分との間の差異を含む。
【００９５】
一実施形態の第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである。
一実施形態のイメージは、圧縮ファイルおよび非圧縮ファイルの少なくとも１つを含む。
【００９６】
一実施形態の変換するステップは、スーパー・ヘッダおよびディレクトリ・ヘッダの少なくとも１つを分割ファイルにコピーするステップを備えている。一実施形態の変換するステップは、少なくとも１つのスーパー・ヘッダおよびディレクトリ・ヘッダに名称を割り当てるステップを備えている。
【００９７】
一実施形態の変換するステップは、イメージの複数のブロックの情報を用いてイメージを分割してイメージを複数の部分に分割するステップを備えている。一実施形態の変換するステップは、複数の部分から、ブロックの同じ境界内にある少なくとも１つの部分を判定するステップを備えている。一実施形態の変換するステップは、同じ境界内にある少なくとも１つの部分を伸張し、該伸張した部分を分割ファイルに出力するステップを備えている。
【００９８】
一実施形態の方法は、分割ファイルが同じＣＲＡＭＦＳ  Ｌｉｎｕｘファイルに属し（ファイルの制約）、同じデバイス・ブロック内に位置し（ＲＯＭの制約）、かつ分割ファイルの伸張バージョンの総サイズが閾値未満である（ＲＡＭの制約）場合、分割ファイルを併合するステップを備えている。
【００９９】
一実施形態の方法は、部分のデータを分割ファイルに書き込むステップを備えており、データは、前述の部分のメモリの場所、一部分を含むブロックのブロック情報、前述の部分およびブロックの少なくとも１つのオフセット情報、ならびに前述の部分およびブロックの少なくとも１つのサイズ情報のうち少なくとも１つを含む。
【０１００】
一実施形態の方法は、分割ファイルの分割毎にヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている。
一実施形態の部分従属性テーブルを生成するステップは、ヒント・ファイルのファイル名をソートするステップを備えている。一実施形態の部分従属性テーブルを生成するステップは、原イメージおよび新イメージの間で共通するファイル名を特定するステップを備えている。
【０１０１】
一実施形態のソートするステップは、原イメージのファイル名および新イメージのファイル名の少なくとも一方のアルファベット順のソートを含む。
一実施形態の方法は、原イメージの少なくとも１つの部分と新イメージの少なくとも１つの部分との間におけるいずれの部分従属性も判定するステップを備えている。
【０１０２】
一実施形態の方法は、各新部分の内容を、該新部分が従属する対応の原部分の内容と比較するステップを備えており、新部分は１つの原部分のみに従属する。
一実施形態の方法は、比較によって、内容および部分名が同一であることが示された場合、新部分および対応する原部分を部分従属性テーブルが除去することにより、修正部分従属性テーブルを生成するステップを備えている。一実施形態の方法は、比較によって、内容が同一であり、部分名が異なることが示された場合、フラグを設定するステップを備えており、前述の部分は、新イメージにおいて場所がシフトされた同一部分であり、フラグはWHOLE＿IS＿COPYフラグである。一実施形態の方法は、同一部分の場所およびサイズを含む同一部分の情報を生成するステップを備えており、デルタ・データは、同一部分の情報を含む。
【０１０３】
一実施形態の方法は、修正部分従属性テーブルおよびイメージについてのヒント・ファイルを組み合わせるステップを備えている。一実施形態の方法は、ブロック優先グラフを生成するステップを備えている。一実施形態の方法は、ブロック優先グラフにおいてあらゆるサイクルを特定するステップを備えている。一実施形態の方法は、ブロック優先グラフにおけるあらゆるサイクルを分解し、非周期的ブロック優先グラフを形成するステップを備えている。
【０１０４】
一実施形態の方法は、非周期的ブロック優先グラフの情報をソートすることにより、ソートした非周期的ブロック優先グラフを生成するステップを備えている。一実施形態の方法は、ソートした非周期的ブロック優先グラフの情報を用いて、修正部分従属性テーブルを並べ換えることにより、再整列部分従属性テーブルを生成するステップを備えている。一実施形態の方法は、再整列部分従属性テーブルを出力するステップを備えている。
【０１０５】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムのイメージを受信する受信部を備え、イメージが原イメージおよび新イメージを含むシステムを含む。一実施形態のシステムは、受信部に結合され、イメージを第１フォーマットから複数の分割ファイルに変換するプリプロセッサを備えており、分割ファイルは、原イメージおよび新イメージの少なくとも一方のデータと、部分の少なくとも１つの場所パラメータとを含む。一実施形態のシステムは、プリプロセッサに結合され、新イメージの部分と原イメージの少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部を備えている。一実施形態のシステムは、従属性生成部に結合され、新イメージの少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンを備えており、デルタ・ファイルは、新イメージの少なくとも１つの部分と原イメージの少なくとも１つの部分との間の差異を含む。一実施形態のシステムは、差異エンジンに結合され、新イメージの全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている。
【０１０６】
一実施形態のシステムは、携帯デバイスにおける更新エンジンを備えており、携帯デバイスは、少なくとも１つの結合部を介して、デルタ・パッケージを受信し、更新エンジンは、携帯デバイス上にホストされている複数の原区間の従属する原区間を組み立て、デルタ・パッケージのうち、従属する原区間の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定し、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新区間を再現する。
【０１０７】
一実施形態の更新エンジンは、デルタ・パッケージを受信し、デルタ・パッケージの少なくとも１つのデルタ・ファイルの内容の完全性を検証する。
一実施形態の更新エンジンは、携帯デバイスの第１メモリ・エリアにおいて少なくとも１つの新区間を再現する。
【０１０８】
一実施形態の第１メモリ・エリアは、ランダム・アクセス・メモリ（ＲＡＭ）内にある。
一実施形態の更新エンジンは、従属する原区間の少なくとも１つに対応するデルタ・パッケージのデルタ・ファイルを特定し続け、該特定したデルタ・ファイルに対応する新区間を再現し続ける。
【０１０９】
一実施形態の更新エンジンは、デルタ・パッケージのデルタ・ファイル全てを、携帯デバイス上にホストされている原区間に適応し終えたことを判定し、この判定に応答して、携帯デバイスの第２メモリ・エリアに、前記再現した新区間を書き込む。
【０１１０】
一実施形態の第２メモリ・エリアは、リード・オンリ・メモリ（ＲＯＭ）内にある。
一実施形態のＳＦＳ差異検出および更新は、処理システムにおいて実行すると、スタティック・ファイル・システムのイメージを受信することによってイメージ間の差異を判定する実行可能命令を含むコンピュータ読み取り可能媒体を含み、前述のイメージは原イメージおよび新イメージを含み、更にこのイメージは複数のブロックを含む。本媒体は、更に、イメージを複数の分割ファイルに変換することによってイメージ間の差異を判定し、変換は、複数のブロックの情報を用いてイメージを分割してイメージを複数の部分に分割し、変換により、分割のヒント情報を生成する。本媒体は、更に、原イメージの複数の部分と新イメージとの間の差異を判定することによって、イメージの内容間の差異を判定することにより、イメージ間の差異を判定する。本媒体は、更に、少なくとも１つの部分についての差異を含むデルタ・ファイルを生成することによってイメージ間の差異を判定する。
【０１１１】
一実施形態において受信するイメージは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである。
本媒体は、更に、部分のデータを分割ファイルに書き込むことによって、イメージ間の差異を判定し、データは、前述の部分のメモリの場所、一部分を含むブロックのブロック情報、前述の部分およびブロックの少なくとも１つのオフセット情報、ならびに前述の部分およびブロックの少なくとも１つのサイズ情報のうち少なくとも１つを含む。
【０１１２】
本媒体は、更に、ヒント情報を含む少なくとも１つのヒント・ファイルを生成することによってイメージ間の差異を判定する。
本媒体は、更に、新イメージの少なくとも１つの部分と、原イメージの少なくとも１つの部分との間におけるあらゆる従属性を識別することによってイメージ間の差異を判定する。本媒体は、更に、識別の従属性情報を含む部分従属性テーブルを生成することによってイメージ間の差異を判定し、部分従属性テーブルは、識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、新部分およびその対応する従属原部分を除外する。
【０１１３】
本媒体は、更に、原イメージと同じ内容および異なる部分名を有する新イメージのあらゆる同一部分を特定することによってイメージ間の差異を判定する。本媒体は、更に、同一部分の場所およびサイズを含む同一部分の情報を生成することによってイメージ間の差異を判定し、デルタ・ファイルが、同一部分の情報を含む。
【０１１４】
本媒体は、更に、デルタ・ファイルを、原イメージをホストするクライアント・デバイスに転送することによってイメージ間の差異を判定する。本媒体は、更に、ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で新イメージの部分全てを再現し、デバイス・ブロックをホスト・デバイスのリード・オンリ・メモリに書き込むことによって、デルタ・ファイルの情報を用いて、クライアント・デバイスの目標イメージを更新することにより、イメージ間の差異を判定する。
【０１１５】
前述したＳＦＳ差異検出および更新の態様は、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、プログラマブル・アレイ・ロジック（ＰＡＬ）デバイス、電気的プログラム可能ロジックおよびメモリ・デバイスのようなプログラマブル・ロジック・デバイス（ＰＬＤ）、標準的なセルに基づくデバイス、ならびに特定用途集積回路（ＡＳＩＣ）を含む種々の回路のいずれにもプログラムされる機能として実現することができる。ＳＦＳ差異検出および更新の態様を実施するその他の可能性は、その一部に、メモリ（電子的消去可能プログラム可能リード・オンリ・メモリ（ＥＥＰＲＯＭ））を有するマイクロコントローラ、埋め込みプロセッサ、ファームウェア、ソフトウェア等を含む。更に、ＳＦＳ差異検出および更新の態様は、ソフトウェアに基づく回路エミュレーション、ディスクリート・ロジック（連続および組み合わせ）、カスタム・デバイス、ファジイ（ニューラル）デバイス、量子デバイス、および上述のデバイスの種類のいずれのハイブリッドを有するマイクロプロセッサにおいても具体化することができる。勿論、基盤となるデバイス技術は、種々のコンポーネントの種類、例えば、相補金属酸化物半導体（ＣＭＯＳ）のような金属酸化物半導体電界効果トランジスタ（ＭＯＳＦＥＴ）技術、エミッタ結合ロジック（ＥＣＬ）のようなバイポーラ技術、ポリマ技術（例えば、シリコン共役ポリマおよび金属共役ポリマ−金属構造）、混合アナログおよびディジタルなどにおいて提供することができる。
【０１１６】
文脈上特に必要であることが明らかでない限り、明細書および特許請求の範囲を通じて、「備える」、「備えている」等の言葉は、排他的または網羅的意味ではなく、包含的意味で解釈するものとする。即ち、「含むが、限定されない」という意味である。単数または複数を用いる単語も、それぞれ、複数および単数を含むものとする。加えて、「ここでは」、「以下で」という単語、および同様な意義の単語は、本願において用いられる場合、本願全体を指すのであり、本願のいずれの特定部分を指すのではないとする。「または」という用語が２つ以上の項目のリストを引用して用いられる場合、この用語は当該用語の以下の解釈全てに該当するものとする。リストにおける品目のいずれか、リストにおける品目の全て、およびリストにおける品目のあらゆる組み合わせ。
【０１１７】
本発明の例示した実施例についてのこれまでの説明は、それで全てであることも、開示した正確な形態に本発明を限定することも意図していない。ＳＦＳ際検出および更新の具体的な実施形態およびその例を例示の目的のためにここで記載したが、種々の等価な変更もＳＦＳ際検出および更新の範囲内で可能であることは、当業者は認めよう。ここに提示したＳＦＳ際検出および更新の教示は、他の処理システムや通信システムにも適用することができ、前述のＳＦＳ際検出および更新のみに適用できるのではない。
【０１１８】
前述の種々の実施形態の要素や作用は、組み合わせると更に別の実施形態を設けることができる。以上の詳細な説明に鑑みれば、これらおよびその他の変更をＳＦＳ差異検出および更新に行うことができる。更に、必要であれば、ＳＦＳ差異検出および更新の態様は、前述の種々の特許および出願のシステム、機能および概念を採用して、ＳＦＳ差異検出および更新の更に別の実施形態を提供するように、変更することが可能である。
【０１１９】
一般に、以下の特許請求の範囲では、用いられる用語がＳＦＳ際検出および更新を、明細書および特許請求の範囲に開示されている特定の実施形態に限定すると解釈してはならず、特許請求の範囲の下で動作する処理システム全てを含むように解釈してしかるべきである。したがって、ＳＦＳ差異検出および更新は、開示に限定されるのではなく、代わりに、ＳＦＳ差異検出および更新の範囲は、特許請求の範囲によってその全体が決定されるものとする。
【０１２０】
ＳＦＳ差異検出および更新のある種の態様を、請求項の形態で提示するが、本発明者は、ＳＦＳ差異検出および更新の種々の態様を、いずれの数の請求項の形態でも想定している。例えば、ＳＦＳ差異検出および更新の一態様のみが、機械読み取り可能媒体に具体化したものとして明記されているが、他の態様も同様に機械読み取り可能媒体に具体化することもできる。したがって、本発明者は、本願を出願した後でも、更に別の請求項を追加し、ＳＦＳ差異検出および更新の別の態様に対する、このような更に別の請求項を追求する権利を保有するものとする。
【図面の簡単な説明】
【０１２１】
【図１】図１は、一実施形態におけるスタティック・ファイル・システム（ＳＦＳ）差異検出システムのブロック図である。
【図２】図２は、一実施形態におけるＳＦＳ差異検出のフロー図である。
【図３】図３は、別の実施形態におけるＳＦＳ差異検出のフロー図である。
【図４】図４は、一実施形態における、イメージブロックの部分への分割後のＳＦＳイメージの一例である。
【図５】図５は、一実施形態における従属性生成のフロー図である。
【図６】図６は、一実施形態における、従属性生成を用いて識別した部分従属性の一例である。
【図７】図７は、新ＳＦＳイメージのブロック３の第２部分が、原ＳＦＳイメージのブロック２の第３部分と全く同じコピーである例である。
【図８】図８は、一実施形態におけるＣＲＡＭＦＳイメージ差異検出プロセスを示す。
【図９】図９は、一実施形態におけるＳＦＳ差異検出および更新システムのブロック図である。
【図１０】図１０は、一実施形態におけるＳＦＳ更新のフロー図である。
【図１１】図１１は、一実施形態における、デバイス内でのＳＦＳイメージの内部更新のフロー図である。
【図１】
0005173427.tif 000004
【図２】
0005173427.tif 000005
【図３】
0005173427.tif 000006
【図４】
0005173427.tif 000007
【図５】
0005173427.tif 000008
【図６】
0005173427.tif 000009
【図７】
0005173427.tif 000010
【図８】
0005173427.tif 000011
【図９】
0005173427.tif 000012
【図１０】
0005173427.tif 000013
【図１１】
0005173427.tif 000014