(57)【要約】【課題】  原画像のブロックの部分レベルの差異検出およびブロック・レベルの更新を含む、ＣＲＡＭＦＳファイル・システム差異検出および更新のためのシステムおよび方法を提供する。【解決手段】  差異検出および更新は、ＣＲＡＭＦＳファイル・システム構造情報およびブロック情報を用いて、ＣＲＡＭＦＳ画像を部分に分割し、ＣＲＡＭＦＳ分割モジュールからのヒント／リスト・ファイルを用いて、従属性分析を実行する。新ＣＲＡＭＦＳ画像の部分毎にデルタ・ファイルを生成する（部分レベルの差異検出）。デルタ・ファイルは、新ＣＲＡＭＦＳ画像の部分と、当該新ＣＲＡＭＦＳ画像部分が対応する原ＣＲＡＭＦＳ画像の部分との間の差異の情報を含む。デルタ・ファイルをデバイスに転送し、デルタ・ファイルの情報を用いて、デバイスの目標ＣＲＡＭＦＳ画像をブロック毎に更新する。更新により、ホスト・デバイスＲＡＭにおいてブロック内の新ＣＲＡＭＦＳ画像の全部分を再現し、再現したブロックをホスト・デバイスのＲＯＭに書き込む。【選択図】      図１
2008519360.tif 000002
【特許請求の範囲】
【請求項１】
スタティック・ファイル・システム画像の差異を検出するデバイスであって、
スタティック・ファイル・システムの画像を受信する受信部であって、前記画像が原画像および新画像を含む、受信部と、
前記受信部に結合され、前記画像を第１フォーマットから複数の分割ファイルに変換するプリプロセッサであって、分割ファイルが、前記原画像および前記新画像の少なくとも１つの部分のデータと、前記部分の少なくとも１つの場所パラメータとを含む、プリプロセッサと、
前記プリプロセッサに結合され、前記新画像の１つの部分と前記原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部と、
前記従属性生成部に結合され、前記新画像の少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンであって、前記デルタ・ファイルが、前記新画像の前記少なくとも１つの部分と前記原画像の少なくとも１つの部分との間の差異を含む、差異エンジンと、
を備えている、デバイス。
【請求項２】
請求項１記載のデバイスにおいて、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、デバイス。
【請求項３】
請求項１記載のデバイスであって、更に、前記差異エンジンに結合され、前記新画像の全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている、デバイス。
【請求項４】
スタティック・ファイル・システムの画像を受信するステップであって、該画像が原画像および新画像を含み、前記画像が複数のブロックを含む、ステップと、
前記画像を複数の分割ファイルに変換するステップであって、前記変換は、前記複数のブロックの情報を用いて前記画像を分割して前記画像を複数の部分に分割し、、前記変換は、前記分割のヒント情報を生成する、ステップと、
前記原画像および前記新画像の前記複数の部分間の差異を判定することによって、前記画像の内容間の差異を判定するステップと、
少なくとも１つの部分についての前記差異を含むデルタ・ファイルを生成するステップと、
を備えている、方法。
【請求項５】
請求項４記載の方法において、前記受信画像は、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項６】
請求項４記載の方法であって、更に、前記部分のデータを前記分割ファイルに書き込むステップを備えており、前記データは、前記部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分およびブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分およびブロックのうちの少なくとも１つのサイズ情報、のうちの少なくとも１つを含む、方法。
【請求項７】
請求項４記載の方法であって、更に、前記ヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項８】
請求項７記載の方法であって、更に、
前記新画像の少なくとも１つの部分と、前記原画像の少なくとも１つの部分との間におけるあらゆる従属性を識別するステップと、
前記識別の従属性情報を含む部分従属性テーブルを生成するステップであって、前記部分従属性テーブルは、前記識別が、内容および部分名が前記新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、新部分およびその対応する従属原部分を除外する、ステップと、
を備えている、方法。
【請求項９】
請求項７記載の方法であって、更に、
前記原画像と同じ内容および異なる部分名を有する前記新画像のあらゆる同一部分を特定するステップと、
前記同一部分の場所およびサイズを含む前記同一部分の前記情報を生成するステップであって、前記デルタ・ファイルが、前記同一部分の情報を含む、ステップと、
を備えている、方法。
【請求項１０】
請求項８記載の方法であって、更に、前記部分従属性テーブルと、前記ヒント情報とを組み合わせるステップを備えている、方法。
【請求項１１】
請求項１０記載の方法であって、更に、ブロック優先グラフを生成し、該ブロック優先グラフにおけるあらゆるサイクルを分解することによって、非周期的ブロック優先グラフを形成するステップを備えている、方法。
【請求項１２】
請求項１１記載の方法であって、更に、前記非周期的ブロック優先グラフの情報を用いて、前記部分従属性テーブルを並べ換えることによって、再整列部分従属性テーブルを生成するステップを備えている、方法。
【請求項１３】
請求項４記載の方法であって、更に、
前記デルタ・ファイルを、前記原画像をホストするクライアント・デバイスに転送するステップと、
前記ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で前記新画像の部分全てを再現し、前記デバイス・ブロックを前記ホスト・デバイスのリード・オンリ・メモリに書き込むことによって、前記デルタ・ファイルの情報を用いて前記クライアント・デバイスの目標画像を更新するステップと、
を備えている、方法。
【請求項１４】
請求項１３記載の方法において、前記更新するステップは、更に、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記従属する原部分のうち、前記受信したデルタ・ファイルに対応する少なくとも１つを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１５】
請求項４記載の方法であって、更に、複数のデルタ・ファイルを組み立ててデルタ・パッケージにするステップを備えている、方法。
【請求項１６】
請求項１５記載の方法であって、更に、前記デルタ・パッケージを、前記原画像をホストするクライアント・デバイスに転送するステップを備えている、方法。
【請求項１７】
請求項１６記載の方法であって、更に、
前記クライアント・デバイスにおいて、少なくとも１つのワイヤレス結合部を介して、前記デルタ・パッケージを受信するステップと、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記デルタ・パッケージのうち、前記従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１８】
スタティック・ファイル・システムの画像を受信するステップであって、前記画像が原画像および新画像を含む、ステップと、
前記画像を第１フォーマットから複数の分割ファイルに変換するステップであって、分割ファイルが、前記原画像および新画像の少なくとも１つの部分のデータと、前記部分の少なくとも１つの場所パラメータとを含む、ステップと、
前記新画像の１つの部分と前記原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成するステップと、
前記新画像の少なくとも１つの部分についてデルタ・ファイルを生成するステップであって、前記デルタ・ファイルが、前記新画像の少なくとも１つの部分と前記原画像の少なくとも１つの部分との間の差異を含む、ステップと、
を備えている、方法。
【請求項１９】
請求項１８記載の方法において、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項２０】
請求項１８記載の方法において、前記画像は、圧縮ファイルおよび非圧縮ファイルの少なくとも１つを含む、方法。
【請求項２１】
請求項１８記載の方法において、前記変換するステップは、更に、
スーパー・ヘッダおよびディレクトリ・ヘッダのうちの少なくとも１つを前記分割ファイルにコピーするステップと、
前記少なくとも１つのスーパー・ヘッダおよびディレクトリ・ヘッダに名称を割り当てるステップと、
を備えている、方法。
【請求項２２】
請求項１８記載の方法において、前記変換するステップは、更に、
前記画像の複数のブロックの情報を用いて前記画像を分割して前記画像を複数の部分に分割するステップと、
前記複数の部分のうち、１つのブロックの同じ境界内にある少なくとも１つの部分を判定するステップと、
前記同じ境界内にある前記少なくとも１つの部分を伸張し、該伸張した部分を前記分割ファイルに出力するステップと、
を備えている、方法。
【請求項２３】
請求項２２記載の方法であって、更に、前記分割ファイルが同じＣＲＡＭＦＳ  Ｌｉｎｕｘファイルに属し（ファイルの制約）、同じデバイス・ブロック内に位置し（ＲＯＭの制約）、かつ前記分割ファイルの伸張バージョンの総サイズが閾値未満である（ＲＡＭの制約）場合、前記分割ファイルを併合するステップを備えている、方法。
【請求項２４】
請求項１８記載の方法であって、更に、前記部分のデータを前記分割ファイルに書き込むステップを備えており、前記データは、前記部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分およびブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分およびブロックのうちの少なくとも１つのサイズ情報、のうち少なくとも１つを含む、方法。
【請求項２５】
請求項１８記載の方法であって、更に、前記分割ファイルの分割毎にヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項２６】
請求項２５記載の方法において、部分従属性テーブルを生成するステップは、更に、
前記ヒント・ファイルのファイル名をソートするステップと、
前記原画像および新画像の間で共通するファイル名を特定するステップと、
を備えている、方法。
【請求項２７】
請求項２６記載の方法において、前記ソートするステップは、前記原画像のファイル名および前記新画像のファイル名のうち少なくとも一方のアルファベット順のソートを含む、方法。
【請求項２８】
請求項２６記載の方法であって、更に、前記原画像の少なくとも１つの部分と前記新画像の少なくとも１つの部分との間におけるいずれの部分従属性も判定するステップを備えている、方法。
【請求項２９】
請求項２８記載の方法であって、更に、各新部分の内容を、該新部分が従属する対応の原部分の内容と比較するステップを備えており、前記新部分が１つの原部分のみに従属する、方法。
【請求項３０】
請求項２９記載の方法であって、更に、前記比較によって、内容および部分名が同一であることが示された場合、前記新部分および前記対応する原部分を前記部分従属性テーブルから除去することにより、修正部分従属性テーブルを生成するステップを備えている、方法。
【請求項３１】
請求項３０記載の方法であって、更に、前記比較によって、内容が同一であり、部分名が異なることが示された場合、フラグを設定するステップを備えており、前記部分は、前記新画像において場所がシフトされた同一部分であり、前記フラグは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)は、原ファイルの内容の一部として扱われる。これが意味するのは、ＸＩＰファイル区間に対応する分割ファイルは、実データ内容、およびパディング・バイトも含むということであるが、実施形態はそのように限定されるのではない。
【００３０】
一実施形態の画像処理モジュール１０２は、特殊ノードに対して分割されたデータ区間は生成しない。その理由は、特殊ノードはＣＲＡＭＦＳ画像のディレクトリ区間におけるエントリのみを有し、したがって画像のデータ区間における区間を有していないからである。
【００３１】
ＣＲＡＭＦＳ画像の内容は、画像のために予約されている領域全体を消費しない。したがって、ＣＲＡＭＦＳ画像の末尾は、ＣＲＡＭＦＳ画像のデータの終端と画像の予約エリアの終端との間に、パディング・バイトを含むことができる。一実施形態の画像処理モジュール１０２は、以下で説明するように、ＣＲＡＭＦＳ画像のいずれのパディング・バイトでも、分割ファイルにコピーする。
【００３２】
前述のように、分割ファイルは、画像の１つまたは複数の特定部分のデータを、その部分の追加情報と共に含む。これらの部分の追加情報は、例えば、その部分のＲＯＭにおける場所、ブロックおよびその部分を含むブロックのサイズ、その部分および／またはブロックのオフセットの情報、その部分および／またはブロックのサイズ情報、その部分の非圧縮サイズ（その部分が圧縮されている場合）、および／またはヘッダおよびテール・バイトを含み、これら以外にも様々な情報がある。分割ファイルのファイル名フォーマットは、一実施形態では、次の通りである。
【００３３】
【表１】
2008519360.tif 000003
【００３４】
この分割ファイル・ファイル名フォーマットのコンポーネントは、次のように、分割ファイル部分の情報を表す。「＜Ｒｎ＞」は、ＲＯＭ番号を表す。「＜Ｂｎ＞」は、ブロック番号を表す。「＜Ｂｚ＞」は、ブロック・サイズを表す。［＜Ｏｆ＞」は、（ＲＯＭ上の）データ・部分のオフセットを表す。「＜Ｓｚ＞」は、（ＲＯＭ上の）データ部分のサイズを表す。「＜ＵＳｚ＞」は、（伸張したデータの）（ＲＡＭ上の）分割部分のサイズを表す（任意）。「＜Ｏｓ＞」は、オフセットからの圧縮データの始点のオフセット（４バイト単位で）を表す（任意）（このフィールドの範囲は、１から２５５であるが、この範囲に限定されるのではない）。「＜Ｏｅ＞」は、利用可能なデータの終端からの圧縮データのオフセット（バイト単位）を表す（任意）（このフィールドの範囲は、１から３であるが、この範囲に限定されるのではない）。
【００３５】
画像処理モジュール１０２の変換および分割動作の間に生成した分割毎に、対応するヒント情報も生成する。このヒント情報は、キー値対であるが、そのように限定されるのではない。一実施形態のキー値対では、キーは分割ファイルの名称であり、値は、最大パスを有するＣＲＡＭＦＳ画像におけるファイルの名称である。ヒント情報の一例は、「１＿２＿０＿６５５３６＿２３５＼ｒｏｏｔ＼ｂｉｎ＼ｌｓ．ｂｉｎ」であり、ここで、１＿２＿０＿６５５３６＿２３５は分割ファイルの名称であり、＼ｒｏｏｔ＼ｂｉｎ＼ｌｓ．ｂｉｎはＣＲＡＭＦＳ画像における対応するＬｉｎｕｘファイルの名称である。スーパー・ヘッダ、ディレクトリ・ヘッダ、およびテール・データのような区間には、それぞれ、「ＳＵＰＥＲ＿ＨＥＡＤＥＲ」、「ＤＩＲ＿ＨＥＡＤＥＲ」および「ＴＡＩＬ＿ＨＥＡＤＥＲ」のような、特殊な値が与えられる。
【００３６】
従属性生成モジュール１０４は、ここでは従属性分析モジュールまたは従属性生成部とも呼ばれ、原画像および新画像間のマッピングまたは一致(alignment)を判定または生成する。一致は、原画像の部分に従属する新画像の部分に関する情報を含む。また、一実施形態の一致は、プロセッサに基づく携帯デバイス内にホストされている原画像の内部更新の間に新画像の部分を更新すべきシーケンスに関する情報も含む。従属性生成モジュール１０４は、照合を実行する際に、ＳＦＳの特定構造の情報をドメイン知識（例えば、ヒント・ファイルからの情報）として用い、一致は、画像のブロック境界に関して判定されるが、そのように限定されるのではない。
【００３７】
図５は、一実施形態における、従属性生成５００のフロー図である。従属性生成５００は、一実施形態では、従属性分析アルゴリズムまたはプログラムであり、図１を参照して先に説明したようなＳＦＳ差異検出システムにおいて用いられるが、他の差異検出システムにおいても用いることができる。一実施形態の従属性生成５００は、原ＣＲＡＭＦＳ画像のヒント・ファイルにおけるＬｉｎｕｘファイル名をアルファベット順にソートし（５０２）、新ＣＲＡＭＦＳ画像のヒント・ファイルにおけるＬｉｎｕｘファイル名をアルファベット順にソートする（５０４）。
【００３８】
Ｌｉｎｕｘファイルが１つよりも多い部分を占める場合、部分従属性計算またはプロセスを用いて、これらの部分間における従属性を判定する（５０８）（例えば、最も長い共通サブストリング（ＬＣＳ）分析のような判断基準を用いる）。当該部分が圧縮および／または暗号化されている場合、一致度を高めるために、従属性の計算に先だって、またはこれと同時に、この部分を伸張および／または解読する。図６は、一実施形態において、従属性生成５００を用いて識別した部分従属性の一例６００である。この例では、Ｌｉｎｕｘファイルの新バージョン（Ｎｅｗ）の部分３が、同じファイルの原バージョン（Ｏｒｉｇｉｎａｌ）の部分２および部分３に従属する。
【００３９】
従属性生成５００は、少なくとも１つのファイル部分従属性テーブルを形成または生成する（５１０）。１つの原部分のみに従属する新部分毎に、内容を、その従属する原部分のそれと比較する（５１２）。比較結果が、内容および部分の名称双方が同一であることを示し、内容に変化もずれもないことを意味する場合、新部分および原部分双方をリストから除去する。
【００４０】
従属性生成５００は、ファイル部分従属性テーブルと、原ＣＲＡＭＦＳ画像および新ＣＲＡＭＦＳ画像のヒント・ファイルを組み合わせ（５１４）、ブロック優先グラフ(block precedence graph)を生成する。例えば、カラー・マーキングのようなしかるべきアルゴリズムを用いて、ブロック優先グラフにおけるループ／サイクルを特定する（５１６）または見出す。ブロック優先グラフにおいて特定したいずれのループ／サイクルも、次に、例えば、最小デルタを有するブロックの除去というような、少なくとも１つの判断基準にしたがって分解する（５１８）。その結果得られた非周期的有向ブロック優先グラフ(acyclic directed block precedence graph)を位相的にソートし（５２０）、ソートしたブロック従属性優先度に応じて、ファイル部分従属性テーブルを再度並べ換える（５２２）。次いで、従属性生成５００は、ファイル部分従属性テーブルを出力する（５２４）。ここで、このテーブルを従属性テーブルと呼ぶ。一実施形態のテーブルは、２つの列を含む。第１列は新部分分割ファイル名のためにあり、一方第２列は旧部分分割ファイル名のためにある。一例は、以下の通りである。
【００４１】
【表２】
2008519360.tif 000004
【００４２】
先の例では、ブロック１００の新部分、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フラグである。一実施形態の方法は、同一部分の場所およびサイズを含む同一部分の情報を生成するステップを備えており、デルタ・データは、同一部分の情報を含む。
【０１０３】
一実施形態の方法は、修正部分従属性テーブルおよび画像についてのヒント・ファイルを組み合わせるステップを備えている。一実施形態の方法は、ブロック優先グラフを生成するステップを備えている。一実施形態の方法は、ブロック優先グラフにおいてあらゆるサイクルを特定するステップを備えている。一実施形態の方法は、ブロック優先グラフにおけるあらゆるサイクルを分解し、非周期的ブロック優先グラフを形成するステップを備えている。
【０１０４】
一実施形態の方法は、非周期的ブロック優先グラフの情報をソートすることにより、ソートした非周期的ブロック優先グラフを生成するステップを備えている。一実施形態の方法は、ソートした非周期的ブロック優先グラフの情報を用いて、修正部分従属性テーブルを並べ換えることにより、再整列部分従属性テーブルを生成するステップを備えている。一実施形態の方法は、再整列部分従属性テーブルを出力するステップを備えている。
【０１０５】
一実施形態のＳＦＳ差異検出および更新は、スタティック・ファイル・システムの画像を受信する受信部を備え、画像が原画像および新画像を含むシステムを含む。一実施形態のシステムは、受信部に結合され、画像を第１フォーマットから複数の分割ファイルに変換するプリプロセッサを備えており、分割ファイルは、原画像および新画像の少なくとも一方のデータと、部分の少なくとも１つの場所パラメータとを含む。一実施形態のシステムは、プリプロセッサに結合され、新画像の部分と原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部を備えている。一実施形態のシステムは、従属性生成部に結合され、新画像の少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンを備えており、デルタ・ファイルは、新画像の少なくとも１つの部分と原画像の少なくとも１つの部分との間の差異を含む。一実施形態のシステムは、差異エンジンに結合され、新画像の全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている。
【０１０６】
一実施形態のシステムは、携帯デバイスにおける更新エンジンを備えており、携帯デバイスは、少なくとも１つの結合部を介して、デルタ・パッケージを受信し、更新エンジンは、携帯デバイス上にホストされている複数の原区間の従属する原区間を組み立て、デルタ・パッケージのうち、従属する原区間の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定し、特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新区間を再現する。
【０１０７】
一実施形態の更新エンジンは、デルタ・パッケージを受信し、デルタ・パッケージの少なくとも１つのデルタ・ファイルの内容の完全性を検証する。
一実施形態の更新エンジンは、携帯デバイスの第１メモリ・エリアにおいて少なくとも１つの新区間を再現する。
【０１０８】
一実施形態の第１メモリ・エリアは、ランダム・アクセス・メモリ（ＲＡＭ）内にある。
一実施形態の更新エンジンは、従属する原区間の少なくとも１つに対応するデルタ・パッケージのデルタ・ファイルを特定し続け、該特定したデルタ・ファイルに対応する新区間を再現し続ける。
【０１０９】
一実施形態の更新エンジンは、デルタ・パッケージのデルタ・ファイル全てを、携帯デバイス上にホストされている原区間に適応し終えたことを判定し、この判定に応答して、携帯デバイスの第２メモリ・エリアに、前記再現した新区間を書き込む。
【０１１０】
一実施形態の第２メモリ・エリアは、リード・オンリ・メモリ（ＲＯＭ）内にある。
一実施形態のＳＦＳ差異検出および更新は、処理システムにおいて実行すると、スタティック・ファイル・システムの画像を受信することによって画像間の差異を判定する実行可能命令を含むコンピュータ読み取り可能媒体を含み、前述の画像は原画像および新画像を含み、更にこの画像は複数のブロックを含む。本媒体は、更に、画像を複数の分割ファイルに変換することによって画像間の差異を判定し、変換は、複数のブロックの情報を用いて画像を分割して画像を複数の部分に分割し、変換により、分割のヒント情報を生成する。本媒体は、更に、原画像の複数の部分と新画像との間の差異を判定することによって、画像の内容間の差異を判定することにより、画像間の差異を判定する。本媒体は、更に、少なくとも１つの部分についての差異を含むデルタ・ファイルを生成することによって画像間の差異を判定する。
【０１１１】
一実施形態において受信する画像は、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである。
本媒体は、更に、部分のデータを分割ファイルに書き込むことによって、画像間の差異を判定し、データは、前述の部分のメモリの場所、一部分を含むブロックのブロック情報、前述の部分およびブロックの少なくとも１つのオフセット情報、ならびに前述の部分およびブロックの少なくとも１つのサイズ情報のうち少なくとも１つを含む。
【０１１２】
本媒体は、更に、ヒント情報を含む少なくとも１つのヒント・ファイルを生成することによって画像間の差異を判定する。
本媒体は、更に、新画像の少なくとも１つの部分と、原画像の少なくとも１つの部分との間におけるあらゆる従属性を識別することによって画像間の差異を判定する。本媒体は、更に、識別の従属性情報を含む部分従属性テーブルを生成することによって画像間の差異を判定し、部分従属性テーブルは、識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、新部分およびその対応する従属原部分を除外する。
【０１１３】
本媒体は、更に、原画像と同じ内容および異なる部分名を有する新画像のあらゆる同一部分を特定することによって画像間の差異を判定する。本媒体は、更に、同一部分の場所およびサイズを含む同一部分の情報を生成することによって画像間の差異を判定し、デルタ・ファイルが、同一部分の情報を含む。
【０１１４】
本媒体は、更に、デルタ・ファイルを、原画像をホストするクライアント・デバイスに転送することによって画像間の差異を判定する。本媒体は、更に、ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で新画像の部分全てを再現し、デバイス・ブロックをホスト・デバイスのリード・オンリ・メモリに書き込むことによって、デルタ・ファイルの情報を用いて、クライアント・デバイスの目標画像を更新することにより、画像間の差異を判定する。
【０１１５】
前述したＳＦＳ差異検出および更新の態様は、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、プログラマブル・アレイ・ロジック（ＰＡＬ）デバイス、電気的プログラム可能ロジックおよびメモリ・デバイスのようなプログラマブル・ロジック・デバイス（ＰＬＤ）、標準的なセルに基づくデバイス、ならびに特定用途集積回路（ＡＳＩＣ）を含む種々の回路のいずれにもプログラムされる機能として実現することができる。ＳＦＳ差異検出および更新の態様を実施するその他の可能性は、その一部に、メモリ（電子的消去可能プログラム可能リード・オンリ・メモリ（ＥＥＰＲＯＭ））を有するマイクロコントローラ、埋め込みプロセッサ、ファームウェア、ソフトウェア等を含む。更に、ＳＦＳ差異検出および更新の態様は、ソフトウェアに基づく回路エミュレーション、ディスクリート・ロジック（連続および組み合わせ）、カスタム・デバイス、ファジイ（ニューラル）デバイス、量子デバイス、および上述のデバイスの種類のいずれのハイブリッドを有するマイクロプロセッサにおいても具体化することができる。勿論、基盤となるデバイス技術は、種々のコンポーネントの種類、例えば、相補金属酸化物半導体（ＣＭＯＳ）のような金属酸化物半導体電界効果トランジスタ（ＭＯＳＦＥＴ）技術、エミッタ結合ロジック（ＥＣＬ）のようなバイポーラ技術、ポリマ技術（例えば、シリコン共役ポリマおよび金属共役ポリマ−金属構造）、混合アナログおよびディジタルなどにおいて提供することができる。
【０１１６】
文脈上特に必要であることが明らかでない限り、明細書および特許請求の範囲を通じて、「備える」、「備えている」等の言葉は、排他的または網羅的意味ではなく、包含的意味で解釈するものとする。即ち、「含むが、限定されない」という意味である。単数または複数を用いる単語も、それぞれ、複数および単数を含むものとする。加えて、「ここでは」、「以下で」という単語、および同様な意義の単語は、本願において用いられる場合、本願全体を指すのであり、本願のいずれの特定部分を指すのではないとする。「または」という用語が２つ以上の項目のリストを引用して用いられる場合、この用語は当該用語の以下の解釈全てに該当するものとする。リストにおける品目のいずれか、リストにおける品目の全て、およびリストにおける品目のあらゆる組み合わせ。
【０１１７】
本発明の例示した実施例についてのこれまでの説明は、それで全てであることも、開示した正確な形態に本発明を限定することも意図していない。ＳＦＳ際検出および更新の具体的な実施形態およびその例を例示の目的のためにここで記載したが、種々の等価な変更もＳＦＳ際検出および更新の範囲内で可能であることは、当業者は認めよう。ここに提示したＳＦＳ際検出および更新の教示は、他の処理システムや通信システムにも適用することができ、前述のＳＦＳ際検出および更新のみに適用できるのではない。
【０１１８】
前述の種々の実施形態の要素や作用は、組み合わせると更に別の実施形態を設けることができる。以上の詳細な説明に鑑みれば、これらおよびその他の変更をＳＦＳ差異検出および更新に行うことができる。更に、必要であれば、ＳＦＳ差異検出および更新の態様は、前述の種々の特許および出願のシステム、機能および概念を採用して、ＳＦＳ差異検出および更新の更に別の実施形態を提供するように、変更することが可能である。
【０１１９】
一般に、以下の特許請求の範囲では、用いられる用語がＳＦＳ際検出および更新を、明細書および特許請求の範囲に開示されている特定の実施形態に限定すると解釈してはならず、特許請求の範囲の下で動作する処理システム全てを含むように解釈してしかるべきである。したがって、ＳＦＳ差異検出および更新は、開示に限定されるのではなく、代わりに、ＳＦＳ差異検出および更新の範囲は、特許請求の範囲によってその全体が決定されるものとする。
【０１２０】
ＳＦＳ差異検出および更新のある種の態様を、請求項の形態で提示するが、本発明者は、ＳＦＳ差異検出および更新の種々の態様を、いずれの数の請求項の形態でも想定している。例えば、ＳＦＳ差異検出および更新の一態様のみが、機械読み取り可能媒体に具体化したものとして明記されているが、他の態様も同様に機械読み取り可能媒体に具体化することもできる。したがって、本発明者は、本願を出願した後でも、更に別の請求項を追加し、ＳＦＳ差異検出および更新の別の態様に対する、このような更に別の請求項を追求する権利を保有するものとする。
【図面の簡単な説明】
【０１２１】
【図１】図１は、一実施形態におけるスタティック・ファイル・システム（ＳＦＳ）差異検出システムのブロック図である。
【図２】図２は、一実施形態におけるＳＦＳ差異検出のフロー図である。
【図３】図３は、別の実施形態におけるＳＦＳ差異検出のフロー図である。
【図４】図４は、一実施形態における、画像ブロックの部分への分割後のＳＦＳ画像の一例である。
【図５】図５は、一実施形態における従属性生成のフロー図である。
【図６】図６は、一実施形態における、従属性生成を用いて識別した部分従属性の一例である。
【図７】図７は、新ＳＦＳ画像のブロック３の第２部分が、原ＳＦＳ画像のブロック２の第３部分と全く同じコピーである例である。
【図８】図８は、一実施形態におけるＣＲＡＭＦＳ画像差異検出プロセスを示す。
【図９】図９は、一実施形態におけるＳＦＳ差異検出および更新システムのブロック図である。
【図１０】図１０は、一実施形態におけるＳＦＳ更新のフロー図である。
【図１１】図１１は、一実施形態における、デバイス内でのＳＦＳ画像の内部更新のフロー図である。
【図１】
2008519360.tif 000005
【図２】
2008519360.tif 000006
【図３】
2008519360.tif 000007
【図４】
2008519360.tif 000008
【図５】
2008519360.tif 000009
【図６】
2008519360.tif 000010
【図７】
2008519360.tif 000011
【図８】
2008519360.tif 000012
【図９】
2008519360.tif 000013
【図１０】
2008519360.tif 000014
【図１１】
2008519360.tif 000015
【手続補正書】
【提出日】平成19年11月22日(2007.11.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ファイル・システム画像の差異を検出するデバイスであって、
スタティック・ファイル・システムの画像を受信する受信部であって、前記画像が原画像および新画像を含む、受信部と、
前記受信部に結合され、前記画像を第１フォーマットから複数の分割ファイルに変換するプリプロセッサであって、分割ファイルが、前記原画像および前記新画像の少なくとも１つの部分のデータと、前記部分の少なくとも１つの場所パラメータとを含む、プリプロセッサと、
前記プリプロセッサに結合され、前記新画像の１つの部分と前記原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部と、
前記従属性生成部に結合され、前記新画像の少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンであって、前記デルタ・ファイルが、前記新画像の前記少なくとも１つの部分と前記原画像の少なくとも１つの部分との間の差異を含む、差異エンジンと、
を備えている、デバイス。
【請求項２】
請求項１記載のデバイスにおいて、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、デバイス。
【請求項３】
請求項１記載のデバイスであって、更に、前記差異エンジンに結合され、前記新画像の全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンを備えている、デバイス。
【請求項４】
スタティック・ファイル・システムの画像を受信するステップであって、該画像が原画像および新画像を含み、前記画像が複数のブロックを含む、ステップと、
前記画像を複数の分割ファイルに変換するステップであって、前記変換は、前記複数のブロックの情報を用いて前記画像を分割して前記画像を複数の部分に分割し、前記変換は、前記分割のヒント情報を生成する、ステップと、
前記原画像および前記新画像の前記複数の部分間の差異を判定することによって、前記画像の内容間の差異を判定するステップと、
少なくとも１つの部分についての前記差異を含むデルタ・ファイルを生成するステップと、
を備えている、方法。
【請求項５】
請求項４記載の方法において、前記受信画像は、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項６】
請求項４記載の方法であって、更に、前記部分のデータを前記分割ファイルに書き込むステップを備えており、前記データは、前記部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうちの少なくとも１つを含む、方法。
【請求項７】
請求項４記載の方法であって、更に、前記ヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項８】
請求項７記載の方法であって、更に、
前記新画像の少なくとも１つの部分と、前記原画像の少なくとも１つの部分との間におけるあらゆる従属性を識別するステップと、
前記識別の従属性情報を含む部分従属性テーブルを生成するステップであって、前記部分従属性テーブルは、前記識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、前記新部分および前記対応の従属原部分を除外する、ステップと、
を備えている、方法。
【請求項９】
請求項７記載の方法であって、更に、
前記原画像と同じ内容および異なる部分名を有する前記新画像のあらゆる同一部分を特定するステップと、
前記同一部分の場所およびサイズを含む前記同一部分の情報を生成するステップであって、前記デルタ・ファイルが、前記同一部分の前記情報を含む、ステップと、
を備えている、方法。
【請求項１０】
請求項８記載の方法であって、更に、前記部分従属性テーブルと、前記ヒント情報とを組み合わせるステップを備えている、方法。
【請求項１１】
請求項１０記載の方法であって、更に、ブロック優先グラフを生成し、該ブロック優先グラフにおけるあらゆるサイクルを分解することによって、非周期的ブロック優先グラフを形成するステップを備えている、方法。
【請求項１２】
請求項１１記載の方法であって、更に、前記非周期的ブロック優先グラフの情報を用いて、前記部分従属性テーブルを並べ換えることによって、再整列部分従属性テーブルを生成するステップを備えている、方法。
【請求項１３】
請求項４記載の方法であって、更に、
前記デルタ・ファイルを、前記原画像をホストするクライアント・デバイスに転送するステップと、
前記ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロック内で前記新画像の部分全てを再現し、前記デバイス・ブロックを前記ホスト・デバイスのリード・オンリ・メモリに書き込むことによって、前記デルタ・ファイルの情報を用いて前記クライアント・デバイスの目標画像を更新するステップと、
を備えている、方法。
【請求項１４】
請求項１３記載の方法において、前記更新するステップは、更に、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記従属する原部分のうち、前記受信したデルタ・ファイルに対応する少なくとも１つを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１５】
請求項４記載の方法であって、更に、複数のデルタ・ファイルを組み立ててデルタ・パッケージにするステップを備えている、方法。
【請求項１６】
請求項１５記載の方法であって、更に、前記デルタ・パッケージを、前記原画像をホストするクライアント・デバイスに転送するステップを備えている、方法。
【請求項１７】
請求項１６記載の方法であって、更に、
前記クライアント・デバイスにおいて、少なくとも１つのワイヤレス結合部を介して、前記デルタ・パッケージを受信するステップと、
前記クライアント・デバイス上にホストされている前記複数の原部分の従属する原部分を組み立てるステップと、
前記デルタ・パッケージのうち、前記従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定するステップと、
前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現するステップと、
を備えている、方法。
【請求項１８】
スタティック・ファイル・システムの画像を受信するステップであって、前記画像が原画像および新画像を含む、ステップと、
前記画像を第１フォーマットから複数の分割ファイルに変換するステップであって、分割ファイルが、前記原画像および新画像の少なくとも１つの部分のデータと、前記部分の少なくとも１つの場所パラメータとを含む、ステップと、
前記新画像の１つの部分と前記原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成するステップと、
前記新画像の少なくとも１つの部分についてデルタ・ファイルを生成するステップであって、前記デルタ・ファイルが、前記新画像の前記少なくとも１つの部分と前記原画像の少なくとも１つの部分との間の差異を含む、ステップと、
を備えている、方法。
【請求項１９】
請求項１８記載の方法において、前記第１フォーマットは、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、方法。
【請求項２０】
請求項１８記載の方法において、前記画像は、圧縮ファイルおよび非圧縮ファイルの少なくとも１つを含む、方法。
【請求項２１】
請求項１８記載の方法において、前記変換するステップは、更に、
スーパー・ヘッダおよびディレクトリ・ヘッダのうちの少なくとも１つを前記分割ファイルにコピーするステップと、
前記少なくとも１つのスーパー・ヘッダおよびディレクトリ・ヘッダに名称を割り当てるステップと、
を備えている、方法。
【請求項２２】
請求項１８記載の方法において、前記変換するステップは、更に、
前記画像の複数のブロックの情報を用いて前記画像を分割して前記画像を複数の部分に分割するステップと、
前記複数の部分のうち、１つのブロックの同じ境界内にある少なくとも１つの部分を判定するステップと、
前記同じ境界内にある前記少なくとも１つの部分を伸張し、該伸張した部分を前記分割ファイルに出力するステップと、
を備えている、方法。
【請求項２３】
請求項２２記載の方法であって、更に、前記分割ファイルが同じＣＲＡＭＦＳ  Ｌｉｎｕｘファイルに属し（ファイルの制約）、同じデバイス・ブロック内に位置し（ＲＯＭの制約）、かつ前記分割ファイルの伸張バージョンの総サイズが閾値未満である（ＲＡＭの制約）場合、前記分割ファイルを併合するステップを備えている、方法。
【請求項２４】
請求項１８記載の方法であって、更に、前記部分のデータを前記分割ファイルに書き込むステップを備えており、前記データは、前記部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうち少なくとも１つを含む、方法。
【請求項２５】
請求項１８記載の方法であって、更に、前記分割ファイルの分割毎にヒント情報を含む少なくとも１つのヒント・ファイルを生成するステップを備えている、方法。
【請求項２６】
請求項２５記載の方法において、部分従属性テーブルを生成するステップは、更に、
前記ヒント・ファイルのファイル名をソートするステップと、
前記原画像および新画像の間で共通するファイル名を特定するステップと、
を備えている、方法。
【請求項２７】
請求項２６記載の方法において、前記ソートするステップは、前記原画像のファイル名および前記新画像のファイル名のうち少なくとも一方のアルファベット順のソートを含む、方法。
【請求項２８】
請求項２６記載の方法であって、更に、前記原画像の少なくとも１つの部分と前記新画像の少なくとも１つの部分との間におけるいずれの部分従属性も判定するステップを備えている、方法。
【請求項２９】
請求項２８記載の方法であって、更に、各新部分の内容を、該新部分が従属する対応の原部分の内容と比較するステップを備えており、前記新部分が１つの原部分のみに従属する、方法。
【請求項３０】
請求項２９記載の方法であって、更に、前記比較によって、内容および部分名が同一であることが示された場合、前記新部分および前記対応する原部分を前記部分従属性テーブルから除去することにより、修正部分従属性テーブルを生成するステップを備えている、方法。
【請求項３１】
請求項３０記載の方法であって、更に、前記比較によって、内容が同一であり、部分名が異なることが示された場合、フラグを設定するステップを備えており、前記部分は、前記新画像において場所がシフトされた同一部分であり、前記フラグはWHOLE＿IS＿COPYフラグである、方法。
【請求項３２】
請求項３１記載の方法であって、更に、前記同一部分の場所およびサイズを含む同一部分の情報を生成するステップを備えており、前記デルタ・ファイルは、前記同一部分の前記情報を含む、方法。
【請求項３３】
請求項３０記載の方法であって、更に、前記画像について前記修正部分従属性テーブルおよび前記ヒント・ファイルを組み合わせるステップを備えている、方法。
【請求項３４】
請求項３３記載の方法であって、更に、
ブロック優先グラフを生成するステップと、
前記ブロック優先グラフにおいてあらゆるサイクルを特定するステップと、
前記ブロック優先グラフにおけるあらゆるサイクルを分解し、非周期的ブロック優先グラフを形成するステップと、
を備えている、方法。
【請求項３５】
請求項３４記載の方法であって、更に、
前記非周期的ブロック優先グラフの情報をソートすることにより、ソートした非周期的ブロック優先グラフを生成するステップと、
前記ソートした非周期的ブロック優先グラフの情報を用いて、前記修正部分従属性テーブルを並べ換えることにより、再整列部分従属性テーブルを生成するステップと、
前記再整列部分従属性テーブルを出力するステップと、
を備えている、方法。
【請求項３６】
スタティック・ファイル・システムの画像を受信する受信部であって、前記画像が原画像および新画像を含む、受信部と、
前記受信部に結合され、前記画像を第１フォーマットから複数の分割ファイルに変換するプリプロセッサであって、分割ファイルが、前記原画像および新画像の少なくとも１つの部分のデータと、前記部分の少なくとも１つの場所パラメータとを含む、プリプロセッサと、
前記プリプロセッサに結合され、前記新画像の１つの部分と前記原画像の少なくとも１つの部分との間の従属性の情報を含む部分従属性テーブルを生成する従属性生成部と、
前記従属性生成部に結合され、前記新画像の少なくとも１つの部分についてデルタ・ファイルを生成する差異エンジンであって、前記デルタ・ファイルが、前記新画像の前記少なくとも１つの部分と前記原画像の少なくとも１つの部分との間の差異を含む、差異エンジンと、
前記差異エンジンに結合され、前記新画像の全ての部分についてのデルタ・ファイルを組み立てるパッケージング・エンジンと、
を備えている、システム。
【請求項３７】
請求項３６記載のシステムであって、更に、携帯デバイスにおいて更新エンジンを備えており、該携帯デバイスは、少なくとも１つの結合部を介して、前記デルタ・パッケージを受信し、前記更新エンジンは、前記携帯デバイス上にホストされている前記原画像の従属する原部分を組み立て、前記デルタ・パッケージのうち、前記従属する原部分の少なくとも１つに対応する少なくとも１つのデルタ・ファイルを特定し、前記特定した少なくとも１つのデルタ・ファイルに対応する少なくとも１つの新部分を再現する、システム。
【請求項３８】
請求項３７記載のシステムにおいて、前記更新エンジンは、前記デルタ・パッケージを受信し、該デルタ・パッケージの少なくとも１つのデルタ・ファイルの内容の完全性を検証する、システム。
【請求項３９】
請求項３７記載のシステムにおいて、前記更新エンジンは、前記携帯デバイスの第１メモリ・エリアにおいて前記少なくとも１つの新部分を再現する、システム。
【請求項４０】
請求項３９記載のシステムにおいて、前記第１メモリ・エリアは、ランダム・アクセス・メモリ（ＲＡＭ）内にある、システム。
【請求項４１】
請求項３９記載のシステムにおいて、前記更新エンジンは、前記原部分のうちの少なくとも１つに対応する前記デルタ・パッケージのデルタ・ファイルを特定し、該特定したデルタ・ファイルに対応する新部分を再現し続ける、システム。
【請求項４２】
請求項４１記載のシステムにおいて、前記更新エンジンは、前記デルタ・パッケージのデルタ・ファイル全てを、前記携帯デバイス上にホストされている前記原部分に適用し終えたことを判定し、この判定に応答して、前記携帯デバイスの第２メモリ・エリアに、前記再現した新部分を書き込む、システム。
【請求項４３】
請求項４２記載のシステムにおいて、前記第２メモリ・エリアは、リード・オンリ・メモリ（ＲＯＭ）内にある、システム。
【請求項４４】
処理システムにおいて実行されると、
スタティック・ファイル・システムの画像を受信し、該画像が原画像および新画像を含み、前記画像が複数のブロックを含み、
前記画像を複数の分割ファイルに変換し、該変換は、前記複数のブロックの情報を用いて前記画像を分割して前記画像を前記複数の部分に分割し、前記変換は、前記分割のヒント情報を生成し、
前記原画像と前記新画像の複数の部分間の差異を判定することによって、前記画像の内容間の差異を判定し、
少なくとも１つの部分についての前記差異を含むデルタ・ファイルを生成する、
ことによって画像間の差異を判定する実行可能命令を含むコンピュータ読み取り可能媒体。
【請求項４５】
請求項４４記載の媒体において、前記受信画像は、圧縮リード・オンリ・メモリ・ファイル・システム（ＣＲＡＭＦＳ）フォーマットである、媒体。
【請求項４６】
請求項４４記載の媒体であって、前記媒体は、更に、前記部分のデータを前記分割ファイルに書き込むことによって、画像間の差異を判定し、前記データは、前記部分のメモリの場所、１つの部分を含むブロックのブロック情報、前記部分および前記ブロックのうちの少なくとも１つのオフセット情報、ならびに前記部分および前記ブロックのうちの少なくとも１つのサイズ情報、のうちの少なくとも１つを含む、媒体。
【請求項４７】
請求項４４記載の媒体において、前記媒体は、更に、前記ヒント情報を含む少なくとも１つのヒント・ファイルを生成することによって画像間の差異を判定する、媒体。
【請求項４８】
請求項４７記載の媒体において、前記媒体は、更に、
前記新画像の少なくとも１つの部分と、前記原画像の少なくとも１つの部分との間におけるあらゆる従属性を識別し、
前記識別の従属性情報を含む部分従属性テーブルを生成し、前記部分従属性テーブルは、前記識別が、内容および部分名が新部分と該新部分が従属する対応の原部分との間で同一であることを示す場合、前記新部分および前記対応の従属原部分を除外する、
ことによって画像間の差異を判定する、媒体。
【請求項４９】
請求項４７記載の媒体において、前記媒体は、更に、
前記原画像と同じ内容および異なる部分名を有する前記新画像のあらゆる同一部分を特定し、
前記同一部分の場所およびサイズを含む前記同一部分の情報を生成し、前記デルタ・ファイルが、前記同一部分の前記情報を含む、
ことによって画像間の差異を判定する、媒体。
【請求項５０】
請求項４４記載の媒体において、前記媒体は、更に、
前記デルタ・ファイルを、前記原画像をホストするクライアント・デバイスに転送し、
前記ホスト・デバイスのランダム・アクセス・メモリにおけるデバイス・ブロックに前記新画像の部分全てを再現し、前記デバイス・ブロックを前記ホスト・デバイスのリード・オンリ・メモリに書き込むことによって、前記デルタ・ファイルの情報を用いて、前記クライアント・デバイスの目標画像を更新する、
ことによって画像間の差異を判定する、媒体。