知財求人 - 知財ポータルサイト「IP Force」
特表2024-528481パッチ・パッケージを生成および適用するためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-30
(54)【発明の名称】パッチ・パッケージを生成および適用するためのシステムおよび方法
(51)【国際特許分類】
G06F 8/658 20180101AFI20240723BHJP
【ＦＩ】
G06F8/658
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023579376
(86)(22)【出願日】2022-06-22
(85)【翻訳文提出日】2024-02-06
(86)【国際出願番号】 IL2022050670
(87)【国際公開番号】W WO2022269612
(87)【国際公開日】2022-12-29
(31)【優先権主張番号】284315
(32)【優先日】2021-06-22
(33)【優先権主張国・地域又は機関】IL
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
２．ＪＡＶＡ
３．ＢＬＵＥＴＯＯＴＨ
(71)【出願人】
【識別番号】523480680
【氏名又は名称】フィロ システムズ リミテッド
【氏名又は名称原語表記】ＦＩＬＯ ＳＹＳＴＥＭＳ ＬＴＤ．
(74)【代理人】
【識別番号】110000729
【氏名又は名称】弁理士法人ユニアス国際特許事務所
(72)【発明者】
【氏名】ラロン、エタマル エイチ．
(72)【発明者】
【氏名】マイ、ミカエル ジェイ．
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376AB28
5B376AB40
5B376CA02
5B376CA06
5B376CA14
5B376CA60
5B376CA76
5B376CA89
5B376FA13
(57)【要約】
【課題】元のソフトウェア・バージョンに対してパッチを適用することによって、ソフトウェア・パッケージのアップデート・バージョンをより効率的に作成することを可能にする、ソフトウェア・パッケージ（一般に「パッチ」または「パッチ・パッケージ」と呼ばれる）を作成および適用するシステムおよび方法を提供すること。
【解決手段】本発明の実施形態は、各バージョンの論理構造を分析するのにより多くの時間を費やすので、（当技術分野の差分モジュールと比較して）パッチを準備する（作成する）ために、例えば、時間、処理能力、およびストレージ空間など、より多くのリソースを要求することもあるが、結果は、より小さくより効率的なパッチ・パッケージであることが多い。アップデートとして、または単一アーカイブ入力を使用することによって、パッチ・パッケージを圧縮および解凍するシステムおよび方法も開示される。
【選択図】図１ａ
【解決手段】本発明の実施形態は、各バージョンの論理構造を分析するのにより多くの時間を費やすので、（当技術分野の差分モジュールと比較して）パッチを準備する（作成する）ために、例えば、時間、処理能力、およびストレージ空間など、より多くのリソースを要求することもあるが、結果は、より小さくより効率的なパッチ・パッケージであることが多い。アップデートとして、または単一アーカイブ入力を使用することによって、パッチ・パッケージを圧縮および解凍するシステムおよび方法も開示される。
【選択図】図１ａ
【特許請求の範囲】
【請求項1】
パッチ生成コンピューティング・システムであって、少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、該少なくとも１つのプロセッサによって実行されると、パッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成する方法を該コンピューティング・システムに実施させるコンピュータ可読命令を備え、該パッチ・パッケージが、元のアーカイブ要素１３０を目的アーカイブ要素１３２にアップデートするように適合される、少なくとも１つのメモリとを備え、該方法が、
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素１３０を割り当て、該マッチング・ペアにおける目的要素として目的アーカイブ要素１３２を割り当てるステップ、
（ｉｉ）該マッチング・ペアにおける該元の要素と該目的要素とを比較し、異なる場合、該目的要素に関する追加、削除、またはアップデートのいずれかのパッチ動作を指示するアクションを備える対応するパッチ命令１７４を準備するステップ、
（ｉｉｉ）該元の要素および該目的要素の構造タイプを識別するステップであって、該構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）該構造タイプが、複合的なアーカイブ要素である場合、
ａ．該元の要素および該目的要素に適用されるように適合された少なくとも１つの解凍モジュール１４４またはアンパック・モジュール１４５を識別するステップ、
ｂ．該識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを該元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造１５２に保存するステップ、
ｃ．該識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを該目的要素に適用し、該結果として生じた０個以上の内部アーカイブ要素を複数のアーカイブ要素を備える目的アーカイブ構造１５４に保存するステップ、
（ｖ）該目的要素に対するパッチ命令１７４をアップデートするステップであって、該パッチ命令が、該パッチ命令アクション、構造タイプ、該目的要素の識別子、および該識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の該結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の該結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）該さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュール１６０を該元のアーカイブ構造および該目的アーカイブ構造に適用し、該パッチ・データ１７２を該パッチ命令１７４と一緒に該対応する元のアーカイブ要素１３０に適用することによって該目的アーカイブ要素１３２を構築できるように、パッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成するステップ
を含む、パッチ生成コンピューティング・システム。
【請求項2】
アーカイブ要素の前記識別された構造タイプが「データ」であるとき、前記方法が、ａ．前記目的要素のデータ・タイプを識別し、該識別されたデータ・タイプをデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュール１４６を識別するステップ、
ｂ．該識別されたデコード・モジュール１４６を前記目的要素に適用し、前記目的アーカイブ構造１５４における前記目的要素を置き換えるための前記目的要素のデコード済みバージョンを生成するステップ、
ｃ．該識別されたデコード・モジュール１４６を前記元の要素に適用し、前記元のアーカイブ構造１５２における前記元の要素を置き換えるための前記元の要素のデコード済みバージョンを生成するステップ、および
ｄ．該データ・タイプもしくは該デコード・モジュール１４６または両方を前記パッチ命令１７４で指示するステップ
をさらに含む、請求項１記載のパッチ生成コンピューティング・システム。
【請求項3】
ステップ（ｖｉｉｉ）の前に、前記アーカイブ要素が、配列尺度に従って１回または複数回、グループ化されたシーケンスのアーカイブ要素に配列され、ステップ（ｖｉ）において、前記アーカイブ要素が、該グループ化されたシーケンスで１回または複数回、前記差分モジュール１６０に入力され、１つまたは複数のパッチ・パッケージ１７０を生じる、請求項１記載のパッチ生成コンピューティング・システム。
【請求項4】
配列尺度が、自然の順序、ソート順、アーカイブ要素のマッチング・ペアがその識別されたデータ・タイプに応じてグループ化されたもの、マッチング・ペアがそのアーカイブ要素のプロパティに応じてグループ化されたもの、前記パッチ命令１７４内のアーカイブ要素のプロパティに応じたマッチング・ペア、またはその任意の組合せを含む、請求項３記載のパッチ生成コンピューティング・システム。
【請求項5】
ステップ（ｖｉｉｉ）において、複数の差分モジュール１６０が適用され、複数のパッチ・パッケージ１７０を生じる、請求項１記載のパッチ生成コンピューティング・システム。
【請求項6】
ステップ（ｖｉｉｉ）において、前記差分モジュール１６０が、辞書サイズおよび／または圧縮レベルを備える異なる差分モジュール・パラメータを使用して複数回実行され、実行された差分モジュール１６０毎に複数のパッチ・パッケージ１７０を生じる、請求項１記載のパッチ生成コンピューティング・システム。
【請求項7】
所定の選択尺度に従って、前記結果として生じたパッチ・パッケージ１７０から最も効率的なパッチを識別するステップをさらに含む、請求項３から６のいずれかに記載のパッチ生成コンピューティング・システム。
【請求項8】
前記元のアーカイブ要素１３０がｎｕｌｌであり、前記目的アーカイブ要素１３２の圧縮形式であるパッチ・パッケージ１７０を生じる、請求項１記載のパッチ生成コンピューティング・システム。
【請求項9】
前記パッチ・パッケージ１７０をどのように生成するかについてのルールおよび設定を指定するパッチ生成器ポリシ１３４をさらに備える、請求項１記載のパッチ生成コンピューティング・システム。
【請求項10】
前記パッチ生成器ポリシ１３４が、変換モジュール１４０に関する論理述語、構造タイプ、内容識別モジュール１４８、差分モジュール１６０、データ・タイプ、およびアーカイブ要素のプロパティを備える、請求項９記載のパッチ生成コンピューティング・システム。
【請求項11】
ステップ（ｉｉｉ）において、「リンク」という構造タイプが識別されることが可能である、請求項１記載のパッチ生成コンピューティング・システム。
【請求項12】
別のアーカイブ要素が前記目的要素と同じデータを含むという指示、または別のパッチ命令１７４が前記目的要素を生じるという指示を前記パッチ命令１７４にさらに含む、請求項１１記載のパッチ生成コンピューティング・システム。
【請求項13】
コンピューティング・システムで実施されるパッチ生成方法であって、該コンピューティング・システムが、少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、該少なくとも１つのプロセッサによって実行されると、パッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成する方法を該コンピューティング・システムに実施させるコンピュータ可読命令を備え、該パッチ・パッケージが、元のアーカイブ要素１３０を目的アーカイブ要素１３２にアップデートするように適合される、少なくとも１つのメモリとを備え、該方法が、
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素１３０を割り当て、該マッチング・ペアにおける目的要素として目的アーカイブ要素１３２を割り当てるステップ、
（ｉｉ）該マッチング・ペアにおける該元の要素と該目的要素とを比較し、異なる場合、該目的要素に関する追加、削除、またはアップデートのいずれかのパッチ動作を指示するアクションを備える対応するパッチ命令１７４を準備するステップ、
（ｉｉｉ）該元の要素および該目的要素の構造タイプを識別するステップであって、該構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）該構造タイプが、複合的なアーカイブ要素である場合、
ａ．該元の要素および該目的要素に適用されるように適合された少なくとも１つの解凍モジュール１４４またはアンパック・モジュール１４５を識別するステップ、
ｂ．該識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを該元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造１５２に保存するステップ、
ｃ．該識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを該目的要素に適用し、該結果として生じた０個以上の内部アーカイブ要素を複数のアーカイブ要素を備える目的アーカイブ構造１５４に保存するステップ、
（ｖ）該目的要素に対するパッチ命令１７４をアップデートするステップであって、該パッチ命令が、該パッチ命令アクション、構造タイプ、該目的要素の識別子、および該識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の該結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の該結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）該さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュール１６０を該元のアーカイブ構造および該目的アーカイブ構造に適用し、該パッチ・データ１７２を該パッチ命令１７４と一緒に該対応する元のアーカイブ要素１３０に適用することによって該目的アーカイブ要素１３２を構築できるように、パッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成するステップ
を含む、パッチ生成方法。
【請求項14】
パッチ・アプリケーション・コンピューティング・システムであって、少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、該少なくとも１つのプロセッサによって実行されると、元のアーカイブ要素１３０、ならびに複数のパッチ命令１７４およびパッチ・データ１７２を備えるパッチ・パッケージ１７０に基づいて、目的アーカイブ要素１３２を生成する方法を該コンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、該方法が、
該パッチ命令１７４のパッチ命令毎に、該パッチ命令によって指示された該要素に対して、
（ｉ）該要素の構造タイプを識別することであって、該構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、「リンク」、または「データ」、および該要素に対するアクションを備える、識別すること、
（ｉｉ）該元のアーカイブ要素内の該要素を元の要素として識別し、必要であれば、該要素がアーカイブ内または圧縮済みロケーション内にある場合、該要素を取得するために、ステップ（ｉｉｉ）および（ｉｖ）をそのロケーションに適用すること、
（ｉｉｉ）該構造タイプが圧縮済みの場合、
ａ．該元の要素を解凍する能力がある解凍モジュール１４４を識別すること、
ｂ．該元の要素を目的要素に解凍し、目的アーカイブ構造１５４に該目的要素を格納すること、
ｃ．圧縮のために該元の要素をマークすること、
（ｉｖ）該構造タイプがアーカイブの場合、
ａ．該元の要素をアンパックする能力があるアンパック・モジュール１４５を識別すること、
ｂ．該元の要素を目的要素にアンパックし、目的アーカイブ構造１５４に該目的要素を格納すること、
ｃ．アーカイブのために該元の要素をマークすること、
ｄ．該アクションが「リンク」を指示している場合、該パッチ命令１７４で指示された該目的アーカイブ構造１５４における別の要素を取得し、該要素のデータを該目的アーカイブ構造１５４における該他の要素のデータで置き換えること、
（ｖ）該元の要素がアーカイブまたは圧縮のためにマークされた場合、該元の要素のロケーションにおけるロケーションを有する全てのパッチ命令１７４を識別し、このようなロケーションを有する該パッチ命令のそれぞれに対してステップ（ｉ）から（ｖ）までを実行すること、
（ｖｉ）該アクションが「追加」または「アップデート」を指示している場合、該目的要素のアップデート・バージョンを生じるパッチ・データ１７２を使用して、該目的要素に対してパッチ・アプリケーション・モジュール１８０を実行すること、
（ｖｉｉ）命令アクションが「削除」を指示している場合、該要素を削除すること、そうでない場合、
ａ．該構造タイプがアーカイブであるか、該要素がアーカイブのためにマークされた場合、該要素をアーカイブする能力があるアーカイブ・モジュール１４２を識別し、パッチ命令１７４における指示および／またはメタデータに従って該要素をアーカイブすること、ならびに
ｂ．該構造タイプが圧縮済みであるか、該要素が圧縮のためにマークされた場合、該要素を圧縮する能力がある圧縮モジュール１４１を識別し、パッチ命令１７４における指示および／またはメタデータに従って該要素を圧縮すること
を実施することを含む、パッチ・アプリケーション・コンピューティング・システム。
【請求項15】
ステップ（ｖ．）の前に、前記パッチ命令１７４がデコードを指示している場合、（ｉ）マッチング・デコード・モジュール１４６を前記要素に適用してデコード済み要素を生じ、前記目的要素を前記デコード済み要素で置き換え、エンコードのために前記目的要素をマークすること、
（ｉｉ）ステップ（ｖｉｉ．ｂ）を実施した後、前記パッチ命令１７４がエンコードを指示しているか、前記要素がエンコードのためにマークされた場合、マッチング・エンコード・モジュール１４３を前記アップデート・バージョンに適用し、前記目的要素を前記アップデート・バージョンで置き換え、エンコードのために前記目的要素をマークすること
を行う、請求項１４記載のパッチ・アプリケーション・コンピューティング・システム。
【請求項16】
目的アーカイブ要素１３２を生成することが、パッチ適用器ポリシ１３６にも基づく、請求項１４記載のパッチ・アプリケーション・コンピューティング・システム。
【請求項17】
前記パッチ適用器ポリシ１３６が、変換モジュール１４０に関する論理述語、構造タイプ、データ・タイプ、アーカイブ要素のプロパティ、パッチ適用モジュール１８０に関する論理述語、またはその任意の組合せに関するルールを備える、請求項１４記載のパッチ・アプリケーション・コンピューティング・システム。
【請求項18】
圧縮コンピューティング・システムであって、少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、該少なくとも１つのプロセッサによって実行されると、複数の目的アーカイブ要素１３２をパッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０に圧縮する方法を該コンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、該方法が、
（ｉ）マッチング・ペアにおける目的要素として目的アーカイブ要素１３２を、および該マッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）該複数の目的アーカイブ要素における目的アーカイブ要素１３２毎に、
ａ．該目的アーカイブ要素１３０の構造タイプを識別することであって、該構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」を備える、識別すること、
ｂ．構造タイプが「圧縮済み」の場合、
Ａ．該目的要素と互換性のある少なくとも１つの解凍モジュール１４４を識別すること、
Ｂ．該少なくとも１つの解凍モジュール１４４を該目的要素に適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造１５４における内部アーカイブ要素である、格納すること、
ｃ．構造タイプが「アーカイブ」の場合、
Ａ．該目的要素と互換性のある少なくとも１つのアンパック・モジュール１４５を識別すること、
Ｂ．該少なくとも１つのアンパック・モジュール１４５を、アーカイブ要素を備える目的アーカイブ構造１５４に適用することであって、各アーカイブ要素が、内部アーカイブ要素である、適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造１５４における内部アーカイブ要素である、格納すること、
ｄ．該目的要素に対するパッチ・データ１７０およびパッチ命令１７４をアップデートし、該構造タイプ、該目的要素の識別子、適用可能な場合、該識別された少なくとも１つの解凍モジュール、および適用可能な場合、該識別された少なくとも１つのアンパック・モジュール１４５を追加すること
を実施するステップ、
（ｉｉｉ）複数の該アーカイブ要素のためにステップ（ｉｉ）を繰り返すステップであって、各アーカイブ要素が、該目的アーカイブ構造１５４における内部アーカイブ要素である、ステップ、ならびに
（ｉｖ）選択された圧縮モジュール１４１または差分モジュール１６０を該目的アーカイブ構造１５４に適用し、該複数の目的アーカイブ要素１３２を再構築することに適合されたパッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成するステップ
を含む、圧縮コンピューティング・システム。
【請求項19】
ステップ（ｉｖ）において、前記選択された圧縮モジュール１４１または差分モジュール１６０を適用する前に、アーカイブ・モジュール１４２を使用して、前記目的アーカイブ構造１５４をアーカイブにパッケージ化するステップをさらに含む、請求項１８記載の圧縮コンピューティング・システム。
【請求項20】
圧縮コンピューティング・システムであって、少なくとも１つのプロセッサと、
該少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、該少なくとも１つのプロセッサによって実行されると、複数の目的アーカイブ要素１３２をパッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０に圧縮する方法を該コンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、該方法が、
（ｉ）該マッチング・ペアにおける目的要素として目的アーカイブ要素１３２を、および該マッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）ｎｕｌｌ指示を元の要素として、および該複数の目的要素の１つのアーカイブ要素を目的要素として備えるマッチング・ペア毎に、
ａ．該目的要素のデータ・タイプを識別し、該目的要素をデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュール１４６のマッチングを試行するステップ、
ｂ．デコード・モジュール１４６のマッチングに成功した場合、該目的要素をデコード済みデータ・フォーマットにデコードし、パッチ・データ１７０およびパッチ命令１７４を適宜アップデートするステップ、
ｃ．利用可能な場合、該デコード済みデータ・フォーマットをアーカイブ要素として目的アーカイブ構造１５４に格納し、利用可能でない場合、該目的要素を格納するステップ、
（ｉｉｉ）適用可能な場合、アーカイブ・モジュール１４２を使用して、該目的アーカイブ構造１５４をアーカイブにパッケージ化するステップ、ならびに
（ｉｖ）選択された圧縮モジュール１４１または差分モジュール１６０を該目的アーカイブ構造１５４に適用し、該複数の目的アーカイブ要素１３２を再構築することに適合されたパッチ・データ１７２およびパッチ命令１７４を備えるパッチ・パッケージ１７０を生成するステップ
を含む、圧縮コンピューティング・システム。
【請求項21】
前記選択された圧縮モジュール１４１または差分モジュール１６０を適用する前に、アーカイブ・モジュール１４２を使用して、前記目的アーカイブ構造１５４をアーカイブにパッケージ化するステップをさらに含む、請求項２０記載の圧縮コンピューティング・システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に、増分アップデートのソフトウェア・システムおよび方法に関し、詳細には、元のソフトウェアの内容および構造を考慮した効率的なパッチ・パッケージを生成するためのソフトウェア・システムおよび方法に関する。
【背景技術】
【0002】
コンピューティングの一部の分野は、時々アップデートされる必要があるコレクションである、ファイルのさらに大きいコレクションに依存する。アップデートは用途が広く、したがって、新しい特徴を追加すること、特徴を除去すること、バグを訂正すること、セキュリティ問題を解決することなどを含むことがある。他のケースでは、アップデートは、変更を経時的に追跡するために使用される。これは、文書管理システム、バージョン制御、バックアップおよびリストア・システム、ならびにログ・ベースのデータベース・アップデートにおいて明らかである。
【0003】
コンピューティングの初期の頃、新しいバージョンはあまり頻繁にリリースされず、サイズがより小さく、ＣＤ－ＲＯＭなどのハード媒体で提供された。今日、オンライン・アップデートは、サイズがより大きく、より頻繁にリリースされ、例えば、新たに発見されたセキュリティ違反に対する重要なセキュリティ・アップデートをリリースしたとき、または人気のあるゲームもしくはアプリケーションの新しいバージョンが利用可能になったときなど、そのリリース直後、多くのユーザによって時々ダウンロードされる。
【0004】
これらのアップデートは、既存のソフトウェア・バージョンをより新しいバージョンにアップグレードするために、既存のソフトウェア・バージョンに適用される「パッチ」と呼ばれる単一の要素にグループ化される。典型的には、ユーザがパッチをダウンロードし、既存のソフトウェア・バージョンに対してパッチを適用することによって、より新しいバージョンにアップグレードする。パッチを送ることは、ユーザによってダウンロードされるファイルのサイズの観点から、全く新しいバージョン全体を送ることより効率的であると考えられている。
【0005】
このようなアップデートが、何十万ものコンピューティング・デバイスに、または場合によっては、短期間に何億ものコンピューティング・デバイスに送られることになるとき、データ通信コストおよび帯域幅要件を低減させることが高い優先度になる。また、ダウンロードし、これらのコンピューティング・デバイスをアップデートするのに要求される時間を低減させることは、ユーザ体験を改善する。
【発明の概要】
【課題を解決するための手段】
【0006】
本発明は、パッチ生成コンピューティング・システムに関し、パッチ生成コンピューティング・システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、少なくとも１つのプロセッサによって実行されると、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成する方法をコンピューティング・システムに実施させるコンピュータ可読命令を備え、パッチ・パッケージが、元のアーカイブ要素を目的アーカイブ要素にアップデートするように適合される、少なくとも１つのメモリとを備え、方法は、
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素を割り当て、マッチング・ペアにおける目的要素として目的アーカイブ要素を割り当てるステップ、
（ｉｉ）マッチング・ペアにおける元の要素と目的要素とを比較し、異なる場合、目的要素に関する追加、削除、またはアップデートのいずれかのパッチ動作を指示するアクションを備える対応するパッチ命令を準備するステップ、
（ｉｉｉ）元の要素および目的要素の構造タイプを識別するステップであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）構造タイプが、複合的なアーカイブ要素である場合、
ａ．元の要素および目的要素に適用されるように適合された少なくとも１つの解凍モジュールまたはアンパック・モジュールを識別するステップ、
ｂ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造に保存するステップ、
ｃ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを目的要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える目的アーカイブ構造に保存するステップ、
（ｖ）目的要素に対してパッチ命令をアップデートするステップであって、パッチ命令が、パッチ命令アクション、構造タイプ、目的要素の識別子、および識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュールを元のアーカイブ構造および目的アーカイブ構造に適用し、パッチ・データをパッチ命令と一緒に、対応する元のアーカイブ要素に適用することによって目的アーカイブ要素を構築できるように、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素を割り当て、マッチング・ペアにおける目的要素として目的アーカイブ要素を割り当てるステップ、
（ｉｉ）マッチング・ペアにおける元の要素と目的要素とを比較し、異なる場合、目的要素に関する追加、削除、またはアップデートのいずれかのパッチ動作を指示するアクションを備える対応するパッチ命令を準備するステップ、
（ｉｉｉ）元の要素および目的要素の構造タイプを識別するステップであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）構造タイプが、複合的なアーカイブ要素である場合、
ａ．元の要素および目的要素に適用されるように適合された少なくとも１つの解凍モジュールまたはアンパック・モジュールを識別するステップ、
ｂ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造に保存するステップ、
ｃ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを目的要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える目的アーカイブ構造に保存するステップ、
（ｖ）目的要素に対してパッチ命令をアップデートするステップであって、パッチ命令が、パッチ命令アクション、構造タイプ、目的要素の識別子、および識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュールを元のアーカイブ構造および目的アーカイブ構造に適用し、パッチ・データをパッチ命令と一緒に、対応する元のアーカイブ要素に適用することによって目的アーカイブ要素を構築できるように、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
【0007】
いくつかの実施形態では、アーカイブ要素の識別された構造タイプが「データ」であるとき、方法は、
ａ．目的要素のデータ・タイプを識別し、識別されたデータ・タイプをデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュールを識別するステップ、
ｂ．識別されたデコード・モジュールを目的要素に適用し、目的アーカイブ構造における目的要素を置き換えるための目的要素のデコード済みバージョンを生成するステップ、
ｃ．識別されたデコード・モジュールを元の要素に適用し、元のアーカイブ構造における元の要素を置き換えるための元の要素のデコード済みバージョンを生成するステップ、および
ｄ．データ・タイプもしくはデコード・モジュールまたは両方をパッチ命令で指示するステップ
をさらに含む。
ａ．目的要素のデータ・タイプを識別し、識別されたデータ・タイプをデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュールを識別するステップ、
ｂ．識別されたデコード・モジュールを目的要素に適用し、目的アーカイブ構造における目的要素を置き換えるための目的要素のデコード済みバージョンを生成するステップ、
ｃ．識別されたデコード・モジュールを元の要素に適用し、元のアーカイブ構造における元の要素を置き換えるための元の要素のデコード済みバージョンを生成するステップ、および
ｄ．データ・タイプもしくはデコード・モジュールまたは両方をパッチ命令で指示するステップ
をさらに含む。
【0008】
いくつかの実施形態では、ステップ（ｖｉｉｉ）の前に、アーカイブ要素は、配列尺度に従って１回または複数回、アーカイブ要素のグループ化されたシーケンスに配列され、ステップ（ｖｉ）において、アーカイブ要素は、グループ化されたシーケンスで１回または複数回、差分モジュールに入力され、１つまたは複数のパッチ・パッケージを生じる。
【0009】
いくつかの実施形態では、配列尺度は、自然の順序、ソート順、アーカイブ要素のマッチング・ペアがその識別されたデータ・タイプに応じてグループ化されたもの、マッチング・ペアがそのアーカイブ要素のプロパティに応じてグループ化されたもの、パッチ命令内のアーカイブ要素のプロパティに応じたマッチング・ペア、またはそのいずれかの組合せを含む。
【0010】
いくつかの実施形態では、ステップ（ｖｉｉｉ）において、複数の差分モジュールが適用され、複数のパッチ・パッケージを生じる。
【0011】
いくつかの実施形態では、ステップ（ｖｉｉｉ）において、差分モジュールが、辞書サイズおよび／または圧縮レベルを備える異なる差分モジュール・パラメータを使用して複数回実行され、実行された差分モジュール毎に複数のパッチ・パッケージを生じる。
【0012】
いくつかの実施形態では、コンピューティング・システムは、所定の選択尺度に従って、結果として生じたパッチ・パッケージから最も効率的なパッチを識別するステップをさらに含む。
【0013】
いくつかの実施形態では、元のアーカイブ要素はｎｕｌｌであり、目的アーカイブ要素の圧縮形式であるパッチ・パッケージを生じる。
【0014】
いくつかの実施形態では、コンピューティング・システムは、パッチ・パッケージをどのように生成するかについてのルールおよび設定を指定するパッチ生成器ポリシをさらに備える。
【0015】
いくつかの実施形態では、パッチ生成器ポリシは、変換モジュールに関する論理述語、構造タイプ、内容識別モジュール、差分モジュール、データ・タイプ、およびアーカイブ要素のプロパティを備える。
【0016】
いくつかの実施形態では、ステップ（ｉｉｉ）において、「リンク」という構造タイプが識別されることが可能である。
【0017】
いくつかの実施形態では、コンピューティング・システムは、別のアーカイブ要素が目的要素と同じデータを含むという指示、または別のパッチ命令が目的要素を生じるという指示をパッチ命令にさらに含む。
【0018】
別の態様では、本発明は、コンピューティング・システムにおいて実施されるパッチ生成方法に関し、コンピューティング・システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、少なくとも１つのプロセッサによって実行されると、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成する方法をコンピューティング・システムに実施させるコンピュータ可読命令を備え、パッチ・パッケージが、元のアーカイブ要素を目的アーカイブ要素にアップデートするように適合される、少なくとも１つのメモリとを備え、方法は、
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素を割り当て、マッチング・ペアにおける目的要素として目的アーカイブ要素を割り当てるステップ、
（ｉｉ）マッチング・ペアにおける元の要素と目的要素とを比較し、異なる場合、目的要素に関する追加、削除、またはアップデートのパッチ動作を指示するアクションを備える対応するパッチ命令を準備するステップ、
（ｉｉｉ）元の要素および目的要素の構造タイプを識別するステップであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）構造タイプが、複合的なアーカイブ要素である場合、
ａ．元の要素および目的要素に適用されるように適合された、少なくとも１つの解凍モジュールまたはアンパック・モジュールを識別するステップ、
ｂ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造に保存するステップ、
ｃ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを目的要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える目的アーカイブ構造に保存するステップ、
（ｖ）目的要素に対してパッチ命令をアップデートするステップであって、パッチ命令が、パッチ命令アクション、構造タイプ、目的要素の識別子、および識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュールを元のアーカイブ構造および目的アーカイブ構造に適用し、パッチ・データをパッチ命令と一緒に、対応する元のアーカイブ要素に適用することによって目的アーカイブ要素を構築できるように、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
（ｉ）マッチング・ペアにおける元の要素として元のアーカイブ要素を割り当て、マッチング・ペアにおける目的要素として目的アーカイブ要素を割り当てるステップ、
（ｉｉ）マッチング・ペアにおける元の要素と目的要素とを比較し、異なる場合、目的要素に関する追加、削除、またはアップデートのパッチ動作を指示するアクションを備える対応するパッチ命令を準備するステップ、
（ｉｉｉ）元の要素および目的要素の構造タイプを識別するステップであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」のうちの１つである、ステップ、
（ｉｖ）構造タイプが、複合的なアーカイブ要素である場合、
ａ．元の要素および目的要素に適用されるように適合された、少なくとも１つの解凍モジュールまたはアンパック・モジュールを識別するステップ、
ｂ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを元の要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える元のアーカイブ構造に保存するステップ、
ｃ．識別された少なくとも１つの解凍モジュールまたはアンパック・モジュールを目的要素に適用し、結果として生じた０個以上の内部アーカイブ要素を、複数のアーカイブ要素を備える目的アーカイブ構造に保存するステップ、
（ｖ）目的要素に対してパッチ命令をアップデートするステップであって、パッチ命令が、パッチ命令アクション、構造タイプ、目的要素の識別子、および識別された少なくとも１つの解凍またはアンパック・モジュールを備える、ステップ、
（ｖｉ）さらなる１つまたは複数のマッチング・ペアを識別するステップであって、各さらなる１つまたは複数のマッチング・ペアが、内部要素として割り当てられた、ステップ（ｉｖ．ｂ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素、および目的要素として割り当てられた、ステップ（ｉｖ．ｃ）の結果として生じた０個以上の内部アーカイブ要素からの１つの内部アーカイブ要素を備え、元の要素および目的要素が、同一の識別子を識別することによってマッチングされる、ステップ、
（ｖｉｉ）さらなる１つまたは複数のマッチング・ペアのためにステップ（ｉｉ）から（ｖｉ）までを繰り返すステップ、
（ｖｉｉｉ）差分モジュールを元のアーカイブ構造および目的アーカイブ構造に適用し、パッチ・データをパッチ命令と一緒に、対応する元のアーカイブ要素に適用することによって目的アーカイブ要素を構築できるように、パッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
【0019】
さらなる態様では、本発明は、パッチ・アプリケーション・コンピューティング・システムに関し、パッチ・アプリケーション・コンピューティング・システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、少なくとも１つのプロセッサによって実行されると、元のアーカイブ要素、ならびに複数のパッチ命令およびパッチ・データを備えるパッチ・パッケージに基づいて、目的アーカイブ要素を生成する方法をコンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、方法は、
パッチ命令のうちのパッチ命令毎に、パッチ命令によって指示された要素に対して、
（ｉ）要素の構造タイプを識別することであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、「リンク」、または「データ」、および要素に対するアクションを備える、識別すること、
（ｉｉ）元のアーカイブ要素内の要素を元の要素として識別し、必要であれば、要素がアーカイブ内または圧縮済みロケーション内にある場合、要素を取得するために、ステップ（ｉｉｉ）および（ｉｖ）をそのロケーションに適用すること、
（ｉｉｉ）構造タイプが圧縮済みの場合、
ａ．元の要素を解凍する能力がある解凍モジュールを識別すること、
ｂ．元の要素を目的要素に解凍し、目的アーカイブ構造に目的要素を格納すること、
ｃ．圧縮のために元の要素をマークすること、
（ｉｖ）構造タイプがアーカイブの場合、
ａ．元の要素をアンパックする能力があるアンパック・モジュールを識別すること、
ｂ．元の要素を目的要素にアンパックし、目的アーカイブ構造に目的要素を格納すること、
ｃ．アーカイブのために元の要素をマークすること、
ｄ．アクションが「リンク」を指示している場合、パッチ命令で指示された目的アーカイブ構造における別の要素を取得し、要素のデータを目的アーカイブ構造における他の要素のデータで置き換えること、
（ｖ）元の要素がアーカイブまたは圧縮のためにマークされた場合、元の要素のロケーションにおけるロケーションを有する全てのパッチ命令を識別し、このようなロケーションを有するパッチ命令のそれぞれに対してステップ（ｉ）から（ｖ）までを実行すること、
（ｖｉ）アクションが「追加」または「アップデート」を指示している場合、目的要素のアップデート・バージョンを生じるパッチ・データを使用して、目的要素に対してパッチ・アプリケーション・モジュールを実行すること、
（ｖｉｉ）命令アクションが「削除」を指示している場合、要素を削除すること、そうでない場合、
ａ．構造タイプがアーカイブであるか、要素がアーカイブのためにマークされた場合、要素をアーカイブする能力があるアーカイブ・モジュールを識別し、パッチ命令における指示および／またはメタデータに従って要素をアーカイブすること、ならびに
ｂ．構造タイプが圧縮済みであるか、要素が圧縮のためにマークされた場合、要素を圧縮する能力がある圧縮モジュールを識別し、パッチ命令における指示および／またはメタデータに従って要素を圧縮すること
を実施することを含む。
パッチ命令のうちのパッチ命令毎に、パッチ命令によって指示された要素に対して、
（ｉ）要素の構造タイプを識別することであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、「リンク」、または「データ」、および要素に対するアクションを備える、識別すること、
（ｉｉ）元のアーカイブ要素内の要素を元の要素として識別し、必要であれば、要素がアーカイブ内または圧縮済みロケーション内にある場合、要素を取得するために、ステップ（ｉｉｉ）および（ｉｖ）をそのロケーションに適用すること、
（ｉｉｉ）構造タイプが圧縮済みの場合、
ａ．元の要素を解凍する能力がある解凍モジュールを識別すること、
ｂ．元の要素を目的要素に解凍し、目的アーカイブ構造に目的要素を格納すること、
ｃ．圧縮のために元の要素をマークすること、
（ｉｖ）構造タイプがアーカイブの場合、
ａ．元の要素をアンパックする能力があるアンパック・モジュールを識別すること、
ｂ．元の要素を目的要素にアンパックし、目的アーカイブ構造に目的要素を格納すること、
ｃ．アーカイブのために元の要素をマークすること、
ｄ．アクションが「リンク」を指示している場合、パッチ命令で指示された目的アーカイブ構造における別の要素を取得し、要素のデータを目的アーカイブ構造における他の要素のデータで置き換えること、
（ｖ）元の要素がアーカイブまたは圧縮のためにマークされた場合、元の要素のロケーションにおけるロケーションを有する全てのパッチ命令を識別し、このようなロケーションを有するパッチ命令のそれぞれに対してステップ（ｉ）から（ｖ）までを実行すること、
（ｖｉ）アクションが「追加」または「アップデート」を指示している場合、目的要素のアップデート・バージョンを生じるパッチ・データを使用して、目的要素に対してパッチ・アプリケーション・モジュールを実行すること、
（ｖｉｉ）命令アクションが「削除」を指示している場合、要素を削除すること、そうでない場合、
ａ．構造タイプがアーカイブであるか、要素がアーカイブのためにマークされた場合、要素をアーカイブする能力があるアーカイブ・モジュールを識別し、パッチ命令における指示および／またはメタデータに従って要素をアーカイブすること、ならびに
ｂ．構造タイプが圧縮済みであるか、要素が圧縮のためにマークされた場合、要素を圧縮する能力がある圧縮モジュールを識別し、パッチ命令における指示および／またはメタデータに従って要素を圧縮すること
を実施することを含む。
【0020】
いくつかの実施形態では、ステップ（ｖ．）の前に、パッチ命令がデコードを指示している場合、
（ｉ）マッチング・デコード・モジュールを要素に適用してデコード済み要素を生じ、目的要素をデコード済み要素で置き換え、エンコードのために目的要素をマークすること、
（ｉｉ）ステップ（ｖｉｉ．ｂ）を実施した後、パッチ命令がエンコードを指示しているか、要素がエンコードのためにマークされた場合、マッチング・エンコード・モジュールをアップデート・バージョンに適用し、目的要素をアップデート・バージョンで置き換え、エンコードのために目的要素をマークすること
を実施する。
（ｉ）マッチング・デコード・モジュールを要素に適用してデコード済み要素を生じ、目的要素をデコード済み要素で置き換え、エンコードのために目的要素をマークすること、
（ｉｉ）ステップ（ｖｉｉ．ｂ）を実施した後、パッチ命令がエンコードを指示しているか、要素がエンコードのためにマークされた場合、マッチング・エンコード・モジュールをアップデート・バージョンに適用し、目的要素をアップデート・バージョンで置き換え、エンコードのために目的要素をマークすること
を実施する。
【0021】
いくつかの実施形態では、目的アーカイブ要素を生成するコンピューティング・システムは、パッチ適用器ポリシにも基づく。
【0022】
一部の実施形態では、パッチ適用器ポリシは、変換モジュールに関する論理述語、構造タイプ、データ・タイプ、アーカイブ要素のプロパティ、パッチ適用モジュールに関する論理述語、またはそのいずれかの組合せに関するルールを備える。
【0023】
さらなる態様では、本発明は、圧縮コンピューティング・システムに関し、圧縮コンピューティング・システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、少なくとも１つのプロセッサによって実行されると、複数の目的アーカイブ要素を、パッチ・データおよびパッチ命令を備えるパッチ・パッケージに圧縮する方法をコンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、方法は、
（ｉ）マッチング・ペアにおける目的要素として目的アーカイブ要素を、およびマッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）複数の目的アーカイブ要素における目的アーカイブ要素毎に、
ａ．目的アーカイブ要素の構造タイプを識別することであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」を備える、識別すること、
ｂ．構造タイプが「圧縮済み」の場合、
Ａ．目的要素と互換性のある少なくとも１つの解凍モジュールを識別すること、
Ｂ．少なくとも１つの解凍モジュールを目的要素に適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、格納すること、
ｃ．構造タイプが「アーカイブ」の場合、
Ａ．目的要素と互換性のある少なくとも１つのアンパック・モジュールを識別すること、
Ｂ．少なくとも１つのアンパック・モジュールを、アーカイブ要素を備える目的アーカイブ構造に適用することであって、各アーカイブ要素が、内部アーカイブ要素である、適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、格納すること、
ｄ．目的要素に対するパッチ・データおよびパッチ命令をアップデートし、構造タイプ、目的要素の識別子、適用可能な場合、識別された少なくとも１つの解凍モジュール、および適用可能な場合、識別された少なくとも１つのアンパック・モジュールを追加すること
を実施するステップ、
（ｉｉｉ）複数のアーカイブ要素のためにステップ（ｉｉ）を繰り返すステップであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、ステップ、ならびに
（ｉｖ）選択された圧縮モジュールまたは差分モジュールを目的アーカイブ構造に適用し、複数の目的アーカイブ要素を再構築することに適合されたパッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
（ｉ）マッチング・ペアにおける目的要素として目的アーカイブ要素を、およびマッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）複数の目的アーカイブ要素における目的アーカイブ要素毎に、
ａ．目的アーカイブ要素の構造タイプを識別することであって、構造タイプが、「ディレクトリ」、「アーカイブ」、「圧縮済み」、または「データ」を備える、識別すること、
ｂ．構造タイプが「圧縮済み」の場合、
Ａ．目的要素と互換性のある少なくとも１つの解凍モジュールを識別すること、
Ｂ．少なくとも１つの解凍モジュールを目的要素に適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、格納すること、
ｃ．構造タイプが「アーカイブ」の場合、
Ａ．目的要素と互換性のある少なくとも１つのアンパック・モジュールを識別すること、
Ｂ．少なくとも１つのアンパック・モジュールを、アーカイブ要素を備える目的アーカイブ構造に適用することであって、各アーカイブ要素が、内部アーカイブ要素である、適用すること、
Ｃ．アーカイブ要素を備えるＢの結果を格納することであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、格納すること、
ｄ．目的要素に対するパッチ・データおよびパッチ命令をアップデートし、構造タイプ、目的要素の識別子、適用可能な場合、識別された少なくとも１つの解凍モジュール、および適用可能な場合、識別された少なくとも１つのアンパック・モジュールを追加すること
を実施するステップ、
（ｉｉｉ）複数のアーカイブ要素のためにステップ（ｉｉ）を繰り返すステップであって、各アーカイブ要素が、目的アーカイブ構造における内部アーカイブ要素である、ステップ、ならびに
（ｉｖ）選択された圧縮モジュールまたは差分モジュールを目的アーカイブ構造に適用し、複数の目的アーカイブ要素を再構築することに適合されたパッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
【0024】
いくつかの実施形態では、コンピューティング・システムは、ステップ（ｉｖ）において、選択された圧縮モジュールまたは差分モジュールを適用する前に、アーカイブ・モジュールを使用して、目的アーカイブ構造をアーカイブにパッケージ化するステップをさらに含む。
【0025】
別の態様では、本発明は、圧縮コンピューティング・システムに関し、圧縮コンピューティング・システムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信連結された少なくとも１つのメモリであって、少なくとも１つのプロセッサによって実行されると、複数の目的アーカイブ要素を、パッチ・データおよびパッチ命令を備えるパッチ・パッケージに圧縮する方法をコンピューティング・システムに実施させるコンピュータ可読命令を備える、少なくとも１つのメモリとを備え、方法は、
（ｉ）マッチング・ペアにおける目的要素として目的アーカイブ要素を、およびマッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）ｎｕｌｌ指示を元の要素として、および複数の目的要素の１つのアーカイブ要素を目的要素として備えるマッチング・ペア毎に、
ａ．目的要素のデータ・タイプを識別し、目的要素をデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュールのマッチングを試行するステップ、
ｂ．デコード・モジュールのマッチングに成功した場合、目的要素をデコード済みデータ・フォーマットにデコードし、パッチ・データおよびパッチ命令を適宜アップデートするステップ、
ｃ．利用可能な場合、デコード済みデータ・フォーマットをアーカイブ要素として目的アーカイブ構造に格納し、利用可能でない場合、目的要素を格納するステップ、
（ｉｉｉ）適用可能な場合、アーカイブ・モジュールを使用して、目的アーカイブ構造をアーカイブにパッケージ化するステップ、ならびに
（ｉｖ）選択された圧縮モジュールまたは差分モジュールを目的アーカイブ構造に適用し、複数の目的アーカイブ要素を再構築することに適合されたパッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
（ｉ）マッチング・ペアにおける目的要素として目的アーカイブ要素を、およびマッチング・ペアにおける元の要素としてｎｕｌｌ指示を割り当てるステップ、
（ｉｉ）ｎｕｌｌ指示を元の要素として、および複数の目的要素の１つのアーカイブ要素を目的要素として備えるマッチング・ペア毎に、
ａ．目的要素のデータ・タイプを識別し、目的要素をデコード済みデータ・フォーマットに変換させる能力があるデコード・モジュールのマッチングを試行するステップ、
ｂ．デコード・モジュールのマッチングに成功した場合、目的要素をデコード済みデータ・フォーマットにデコードし、パッチ・データおよびパッチ命令を適宜アップデートするステップ、
ｃ．利用可能な場合、デコード済みデータ・フォーマットをアーカイブ要素として目的アーカイブ構造に格納し、利用可能でない場合、目的要素を格納するステップ、
（ｉｉｉ）適用可能な場合、アーカイブ・モジュールを使用して、目的アーカイブ構造をアーカイブにパッケージ化するステップ、ならびに
（ｉｖ）選択された圧縮モジュールまたは差分モジュールを目的アーカイブ構造に適用し、複数の目的アーカイブ要素を再構築することに適合されたパッチ・データおよびパッチ命令を備えるパッチ・パッケージを生成するステップ
を含む。
【0026】
いくつかの実施形態では、コンピューティング・システムは、選択された圧縮モジュールまたは差分モジュールを適用する前に、アーカイブ・モジュールを使用して、目的アーカイブ構造をアーカイブにパッケージ化するステップをさらに含む。
【図面の簡単な説明】
【0027】
【図1a】本発明の実施形態によるパッチ生成器のブロック図である。
【図1b】本発明の実施形態によるパッチ適用器のブロック図である。
【図2a】本発明の実施形態による、デコード済みアーカイブ構造をそれぞれ準備するために元のおよび目的アーカイブ要素をトラバースするためのプロセスのフローチャートである。
【図2b】本発明の実施形態による、デコード済みアーカイブ構造をそれぞれ準備するために元のおよび目的アーカイブ要素をトラバースするためのプロセスのフローチャートである。
【図3】典型的には目的および元のアーカイブ構造といったアーカイブ要素のマッチング・ペアをトラバースし、効率的パッチ・パッケージを構築するためのプロセスのフローチャートである。
【図4】本発明の実施形態による、元のアーカイブ要素およびパッチ命令から目的アーカイブ要素を再構築するためのプロセスのフローチャートである。
【発明を実施するための形態】
【0028】
様々な実施形態の以下の詳細な説明では、その一部を形成する、および本発明が実践され得る例証固有の実施形態として示された、添付の図面への参照が行われる。他の実施形態が利用されてもよいこと、および、本発明の範囲から逸脱することなく構造的変更が行われてもよいことを理解されたい。
【0029】
増分アップデート、差分アップデート、バージョン制御、バージョニング・ファイル・システムなどを実施するための市販ツールは、典型的には、第１の多数のファイル／オブジェクト（任意の構造タイプ形式、すなわち圧縮済み、アーカイブ済みなどでもよい）を、これらのファイル／オブジェクトの後のバージョンに見直す。これらの差分ツールは、典型的には、第１のバージョンを、第２のバイナリ・スイートと比較されることになる１つのバイナリ・スイートとみなす（内部の論理構造には気付いていない）。
【0030】
本発明は、元のソフトウェア・バージョンに対してパッチを適用することによって、ソフトウェア・パッケージのアップデート・バージョンをより効率的に作成することを可能にする、ソフトウェア・パッケージ（一般に「パッチ」または「パッチ・パッケージ」と呼ばれる）を作成および適用するシステムおよび方法に関する。本発明の実施形態は、各バージョンの論理構造を分析するのにより多くの時間を費やすので、（当技術分野の差分モジュールと比較して）パッチを準備する（作成する）ために、例えば、時間、処理能力、およびストレージ空間など、より多くのリソースを要求することもあるが、結果は、より小さくより効率的なパッチ・パッケージであることが多い。
【0031】
本発明はまた、下記に記載のように、アップデートとして、または単一アーカイブ入力を使用することによって、パッチ・パッケージを圧縮および解凍するシステムおよび方法に関する。
【0032】
業界適用可能実施例１
ソフトウェア・パッケージ「Ｅｃｌｉｐｓｅ」（元々ＩＢＭ（商標）によるもの）は、バージョン４．１８（２０２０－１２、２０２１年４月に１，６００，０００回以上ダウンロードされた）からバージョン４．１９（２０２１－０３、２０２１年４月に１，２００，０００回以上ダウンロードされた）までアップデートされた。バージョン４．１９は、新しいバージョン全体のスタンド・アロン・ダウンロード（バージョン４．１８から利用可能な増分または差分アップロードはない）としてのみｅｃｌｉｐｓｅ．ｏｒｇにおいて利用可能であり、ダウンロードされるパッケージ・サイズは、約３４１ＭＢであった。
ソフトウェア・パッケージ「Ｅｃｌｉｐｓｅ」（元々ＩＢＭ（商標）によるもの）は、バージョン４．１８（２０２０－１２、２０２１年４月に１，６００，０００回以上ダウンロードされた）からバージョン４．１９（２０２１－０３、２０２１年４月に１，２００，０００回以上ダウンロードされた）までアップデートされた。バージョン４．１９は、新しいバージョン全体のスタンド・アロン・ダウンロード（バージョン４．１８から利用可能な増分または差分アップロードはない）としてのみｅｃｌｉｐｓｅ．ｏｒｇにおいて利用可能であり、ダウンロードされるパッケージ・サイズは、約３４１ＭＢであった。
【0033】
本発明の実施形態は、バージョン４．１８からバージョン４．１９にアップグレードするためのパッチ・パッケージ１７０を作成した。パッチ・パッケージのサイズは、バージョン４．１９の元のサイズのおおよそ３．９５％である、１３．５ＭＢしかなく、ｅｃｌｉｐｓｅ．ｏｒｇウェブ・サイトにおける同じサーバが、４．１９バージョン全体の単一パッケージを現在送るのにかかる時間に、約２５個のパッチを送る（２５人のユーザをサーブする）ことができることを意味する。これは、ウェブ・サイトのサーバおよび通信ラインのコストを低減させることになり、ダウンロード・プロセスがユーザにとって速くなるので、ユーザ満足度を向上させることになる。
【0034】
比較すると、最新技術の「ｖｃｄｉｆｆ」仕様（ｘｄｅｌｔａ３）を使用して準備されたパッチ・パッケージは、同じパッケージの場合、サイズが５９ＭＢであるか、または４．１９のフル・バージョンのサイズの約１８％、および本発明によって準備されたパッケージより４倍以上大きかった（本発明の１３．５ＭＢと比較して５９ＭＢ）。
【0035】
業界適用可能実施例２
人気のあるＡｎｄｒｏｉｄ（商標）ゲーム「Ｃｌａｓｈ Ｒｏｙａｌｅ（商標）」は、例えば、インターネット・アクセス可能なＧｏｏｇｌｅ Ｐｌａｙ（商標）ストア上で、一千万（１０，０００，０００＋）ものゲーマーのためにアップデートされることが非常に多い。圧縮された．ｘａｐｋ－ｆｏｒｍａｔ圧縮アーカイブを使用したＣｌａｓｈ Ｒｏｙａｌｅ（商標）の２０２１年５月のアップデートは、およそ１４１メガバイトのストレージ・ボリュームを有する。
人気のあるＡｎｄｒｏｉｄ（商標）ゲーム「Ｃｌａｓｈ Ｒｏｙａｌｅ（商標）」は、例えば、インターネット・アクセス可能なＧｏｏｇｌｅ Ｐｌａｙ（商標）ストア上で、一千万（１０，０００，０００＋）ものゲーマーのためにアップデートされることが非常に多い。圧縮された．ｘａｐｋ－ｆｏｒｍａｔ圧縮アーカイブを使用したＣｌａｓｈ Ｒｏｙａｌｅ（商標）の２０２１年５月のアップデートは、およそ１４１メガバイトのストレージ・ボリュームを有する。
【0036】
本発明の実施形態は、以前のバージョン３．４．２から当時最新のバージョン３．５．０にアップグレードするためのパッチ・パッケージ１７０を作成した。このパッチ・パッケージ１７０のサイズは、市場にリリースされたバージョン３．５．０の実際の元のサイズのおよそ３．７％である、およそ５．０ＭＢ（メガバイト）しかなく、Ｇｏｏｇｌｅ Ｐｌａｙ（商標）における同じサーバは、３．５．０パッケージ全体の単一パッケージを送るのに現在かかる同じ時間で、約２７個のパッチを送る（２７人のユーザをサーブする）ことができたことを意味する。パッチ・サイズのこの低減は、ウェブ・サイトのサーバおよび通信ラインのコストを低減させ、ダウンロード・プロセスがユーザにとって速くなるので、ユーザ満足度を向上させるはずである。
【0037】
比較すると、最新技術の「ｖｃｄｉｆｆ」仕様（ｘｄｅｌｔａ３）を使用して準備された競合するパッチ・パッケージは、５１ＭＢ（メガバイト）、すなわちＧｏｏｇｌｅ Ｐｌａｙ（商標）ストアによって送られるような３．５．０のフル・バージョンのサイズの約３８％であり、本発明によって準備されたパッチ・パッケージ１７０よりおよそ１０倍大きかった（本発明の５ＭＢと比較して５１ＭＢ）。
【0038】
パッチ・パッケージ１７０を生成する例示的実施形態を示した図１ａへの参照がここで行われる。入力１２０は、元のアーカイブ要素１３０（「ソース」とも呼ばれる）を含んでもよく、少なくとも１つの目的アーカイブ要素１３２（「目的」とも呼ばれる）を含まなければならない。任意選択で、パッチ生成器ポリシ１３４は、パッチ・パッケージ１７０をどのように生成するかについての設定を指定するために提供され得る。
【0039】
元のアーカイブ要素１３０は、（例えば、上記の例におけるＥｃｌｉｐｓｅバージョン４．１８を備える圧縮アーカイブ「．ｔａｒ．ｇｚ」のような）アップデートされることになる元のデータ構造であり、典型的にはいくつかのフォルダに配置されることもある多数のファイルであり、いくつかまたは全てのファイルが圧縮および／またはアーカイブ可能である。
【0040】
アーカイブ要素は、以下の５つの構造タイプのうちのいずれか１つまたは複数として分類可能である。
１．「リンク」－リンクは、別のアーカイブ要素へのポインタにすぎず、別のアーカイブ要素は、これらの５つの構造タイプのいずれかでもよい。
２．「ディレクトリ」－ディレクトリ（別名「フォルダ」）は、ファイル、ディレクトリ、アーカイブ、および／またはリンクなど、さらなるアーカイブ要素を論理的に含むまたは指すファイル・システム内で使用される用語であるか、あるいは、ディレクトリの論理要素が、（例えば、ハード・ディスク・タイプ媒体とは対照的に）内部メモリに常駐しているとき、ディレクトリは、アレイ、リスト、ツリー、ハッシュ・テーブル、ハッシュ・マップ、または、少なくとも１つもしくは複数の内部アーカイブ要素を含むもしくはそれらを（例えば、メモリ参照によって）指す能力がある任意の他の類似のデータ構造などの、メモリ内のデータ構造として表される。
３．「アーカイブ」－アーカイブは、アーカイブ要素が、「内部アーカイブ要素」としてその中に含まれる少なくとも１つの他のアーカイブ要素の組合せであることを指示する構造タイプである。「ディレクトリ」構造タイプと違って、「アーカイブ」構造タイプは、実際には、いくつかの他のアーカイブ要素を一緒にパックし、これらを指すまたは参照するだけではない。アーカイブの内部アーカイブ要素を使用する（関連したものとして見る、編集する、実行する）ために、内部アーカイブ要素は、アンパック・モジュール１４５を使用することによって、アーカイブから最初にアンパックされる必要がある。
４．「圧縮済み」－圧縮済みアーカイブ要素は、下記で説明されるように、圧縮モジュール１４１を前もって使用することによってサイズが低減されたアーカイブ要素であり、アーカイブ要素は、解凍モジュール１４４を使用することによって後で解凍されてもよい。
５．「データ」－タイプ・データのアーカイブ要素は、ファイルシステム上のファイル、メモリ内のオブジェクト、データベース内のレコード、および、４つの、上記で言及された構造タイプではない任意の論理的同等物であることが可能である。
１．「リンク」－リンクは、別のアーカイブ要素へのポインタにすぎず、別のアーカイブ要素は、これらの５つの構造タイプのいずれかでもよい。
２．「ディレクトリ」－ディレクトリ（別名「フォルダ」）は、ファイル、ディレクトリ、アーカイブ、および／またはリンクなど、さらなるアーカイブ要素を論理的に含むまたは指すファイル・システム内で使用される用語であるか、あるいは、ディレクトリの論理要素が、（例えば、ハード・ディスク・タイプ媒体とは対照的に）内部メモリに常駐しているとき、ディレクトリは、アレイ、リスト、ツリー、ハッシュ・テーブル、ハッシュ・マップ、または、少なくとも１つもしくは複数の内部アーカイブ要素を含むもしくはそれらを（例えば、メモリ参照によって）指す能力がある任意の他の類似のデータ構造などの、メモリ内のデータ構造として表される。
３．「アーカイブ」－アーカイブは、アーカイブ要素が、「内部アーカイブ要素」としてその中に含まれる少なくとも１つの他のアーカイブ要素の組合せであることを指示する構造タイプである。「ディレクトリ」構造タイプと違って、「アーカイブ」構造タイプは、実際には、いくつかの他のアーカイブ要素を一緒にパックし、これらを指すまたは参照するだけではない。アーカイブの内部アーカイブ要素を使用する（関連したものとして見る、編集する、実行する）ために、内部アーカイブ要素は、アンパック・モジュール１４５を使用することによって、アーカイブから最初にアンパックされる必要がある。
４．「圧縮済み」－圧縮済みアーカイブ要素は、下記で説明されるように、圧縮モジュール１４１を前もって使用することによってサイズが低減されたアーカイブ要素であり、アーカイブ要素は、解凍モジュール１４４を使用することによって後で解凍されてもよい。
５．「データ」－タイプ・データのアーカイブ要素は、ファイルシステム上のファイル、メモリ内のオブジェクト、データベース内のレコード、および、４つの、上記で言及された構造タイプではない任意の論理的同等物であることが可能である。
【0041】
構造タイプが、「ディレクトリ」、「アーカイブ」、または「圧縮済み」のうちの少なくとも１つであり、したがって、少なくとも１つの内部アーカイブ要素を備える能力があるときはいつでも、構造タイプによって分類された関係のある対応するアーカイブ要素は、簡潔さのために下記の説明で使用される用語である「複合的なアーカイブ要素」として定義される。
【0042】
目的アーカイブ要素１３２は、例えばプロセス４００を使用して、元のアーカイブ要素１３０と共にパッチ・パッケージ１７０を適用することによって再作成可能な、目的データ構造の結果である。元のアーカイブ要素１３０のように、目的アーカイブ要素１３２は、上記で開示された同じ５つの構造タイプのうちの少なくとも１つである。
【0043】
任意選択で、パッチ生成器ポリシ１３４が使用されてもよい。これらのポリシは、下記で論じられるプロセス２００および３００をどのように実施するかに関するルールのセットを含む。ルールは、変換モジュール１４０に関する任意の論理述語、構造タイプ、内容識別モジュール１４８、差分モジュール１６０、データ・タイプ、ならびに、プロセス２００およびプロセス３００によって処理されるアーカイブ要素のプロパティを含んでもよい。
【0044】
変換モジュール１４０は、本質的には、圧縮－解凍、アーカイブ－アンパック、およびエンコード－デコードという３つの主要なペア・タイプのコーデック、またはフィルタである。変換モジュール１４０の１つ１つは、入力データを利用し、これを出力データにコンバートすることが可能であり、したがって、変換モジュール１４０のペア・モジュールは、この出力データを利用し、これを元の入力データに戻す。変換モジュール１４０のペアは、解凍モジュール１４４を伴う圧縮モジュール１４１、アーカイブ・モジュール１４２とアンパック・モジュール１４５、およびエンコード・モジュール１４４とデコード・モジュール１４７である。加えて、差分モジュール１６０およびパッチ適用モジュール１８０も、ペア・モジュールである。典型的には、業界では、データを変換させるモジュールと、データを圧縮または解凍するモジュールとの間の明らかな区別はないが、本発明は、このような区別を大規模に使用する。
【0045】
本発明のために、データを圧縮および解凍するモジュールと、１つのフォーマットから別のフォーマットにデータをエンコードおよびデコードするモジュールとの間の重要な区別を紹介する。本発明のために行う第１の区別は、圧縮モジュール１４１が、バイナリ・ビットを備える任意の入力データを、より少ないバイナリ・ビットを備えることが多い出力データにエンコード可能であるが、エンコーダ１４３は、特定のフォーマットのデータを他の特定のフォーマットの出力データに変換させることしかできないことである。別の区別は、圧縮が、データ要素が除去されるか、または数学的に近似される不可逆圧縮であってもよく、したがって、結果としてサイズが小さくなり、したがって、解凍後、まさにその元のデータが、その一体性を保持しないことがあり、例えば、完全に同一のフォーマットに解凍されないことがある。例えば、ビットマップ・フォーマットの画像を、ＪＰＥＧフォーマットのより小さいサイズの画像に変換させるとき、画像品質が低減され、元のビットマップ画像は、ＪＰＥＧバージョンから単に再構築不可能である。一方、例えば全ての元の画像データを保持するＰＮＧフォーマットの、ファイルまたはオブジェクトをエンコード／デコードするとき、データ損失がない。
【0046】
例えば、「ｂｒｏｔｌｉ」（Ｇｏｏｇｌｅ（商標）Ｃｏｒｐｏｒａｔｉｏｎによるもの）などの人気のある圧縮モジュールは、例えばファイルなどの任意の入力を、そのデータ内容に関わらず、ｂｒｏｔｌｉ辞書および解凍命令を含む例えば別のファイルなどの出力に変換させることが可能である。しかし、「ｐｎｇ２ｂｍｐ」などのフィルタ・モジュールは、公的に利用可能な「ＰＮＧ」フォーマットでエンコードされ、これに忠実に従う、例えばファイルなどのデータを利用することしかできず、既存の「ｂｍｐ」フォーマットのうちの１つでのみ、そのデータを出力することができる。
【0047】
利用可能な変換モジュール１４０をここで参照する。
【0048】
圧縮モジュール１４１は、ファームウェア、ソフトウェア、および／またはハードウェアに実装され、入力ビット（例えば、ファイル、メモリ・オブジェクト、レコード、またはストリーミング・ビットストリームでさえ）を変換させる能力があり、これらの入力ビットを、入力ビットより、例えばサイズがより小さいなど、より効率的であることが多い出力ビットにコンバートしてもよい。
【0049】
注意：圧縮モジュールの目的は、その入力と比較してサイズがより小さい出力を生み出すことである。しかし、いくつかのケースでは、入力ファイルは、使用される圧縮モジュールのアルゴリズムで効率的に圧縮されるのに適していないことがあり、結果として生じた出力（例えば辞書および解凍命令など、圧縮の一部のオーバヘッドを含む）は、実際には、入力ファイルより大きいこともある。
【0050】
今日存在する圧縮モジュール１４１の多くは、「辞書コーダ」として分類され、「辞書コーダ」は、そのアップグレードされた効率の一部を達成するための、本主題の鍵である。
【0051】
辞書コーダである人気のある圧縮モジュールは、（アルファベット順に）、Ａｂｒａｈａｍ ＬｅｍｐｅｌおよびＪａｃｏｂ Ｚｉｖによるバイト－ペア・コーデックおよびＩｓｒａｅｌｉ ＬＺ圧縮ファミリＬＺ７７およびＬＺ７８と、Ｂｒｏｔｌｉ、Ｄｅｆｌａｔｅ、ＬＺ４、ＬＺＦＳＥ、ＬＺＪＢ、ＬＺＭＡ（ｘｚ）、ＬＺＯ、ＬＺＲＷ、ＬＺＳＳ、ＬＺＷ、ＬＺＷＬ、ＬＺＸ、ならびにＳｎａｐｐｙおよびＺｓｔａｎｄａｒｄといった、その国際的な派生物とを含む。
【0052】
「エントロピ・コーダ」として分類される他の圧縮モジュールも、そのアップグレードされた効率の一部を達成するために本主題によって使用される出力を生じる。本開示のために、全てのメタデータ、インデックス、テーブル（例えば、統計および頻度テーブル）、ならびに、エントロピ・コーダによって生成される任意の他の非有益データも、単に「辞書」と呼ばれる。
【0053】
エントロピ・コーダである人気のある圧縮モジュール１４１は、（アルファベット順に）、最近ではまた、アルゴリズムの非対称記数法ファミリに基づくモジュールにおける算術符号化、Ｈｕｆｆｍａｎ符号、およびＺｓｔａｎｄａｒｄの一部分を同様に含む。
【0054】
上記とは異なって分類されるさらなる圧縮モジュール１４１があり、典型的には、入力ビットより効率的な（例えば、より少ない）出力ビットを生ずる。これらの最新の圧縮モジュールの例は、ＢＺｉｐ２、ＲＬＥ、ＰＰＭなどを含む。メタデータ、インデックス、テーブル、および、これらが生成する任意の他の非有益データを前記さらなる圧縮モジュール１４１が使用するときはいつでも、これは、本開示のために単に「辞書」とも呼ばれる。
【0055】
エンコード・モジュール１４３は、１つまたは複数の特定のフォーマットの入力を受け入れ、この入力を別の１つまたは複数の特定のフォーマットの出力へと処理し、その結果、出力が典型的に入力より効率的になる変換器（フィルタ）である。
【0056】
エンコード・モジュール１４３は、典型的には、特定のコンテキスト／トピックまたは業界に適合される。例えば、オーディオ（音）エンコード・モジュール１４３は、ＦＬＡＣ、ＭＰ３、ＱＴ、ＷＭＡＬなどの、オーディオ・フォーマットを出力するモジュールを含む。
【0057】
文書用の多くのエンコード・モジュール１４３が、例えばその最終ステージに、圧縮モジュール１４１を含み、複数の文書要素を圧縮フォーマットの１つの文書にパッケージ化するために圧縮モジュール１４１を使用することに留意されたい。この本発明は、複数の文書にわたる、例えば圧縮などの、より良い効率に到達するために、この特徴を広範囲に使用する。または、エンコーダが圧縮モジュール１４１を使用して複数の文書要素をパッケージ化するときはいつでも、解凍モジュール１４４は、複数の文書要素を正しく抽出可能である。抽出されるとすぐに、抽出された要素のそれぞれは、デコード・モジュール１４６のモジュールによってさらに処理されてもよい。このようなフォーマットは、とりわけ、ＤＯＣＸ、ＯＤＰ、ＯＤＳ、ＯＤＴ、ＯＸＰＳ、ＰＰＴＸ、ＸＬＳＸ、ＸＰＳなどを含む。
【0058】
コンピュータ・グラフィックスの分野におけるエンコード・モジュール１４３の例は、ラスター・グラフィックス用のＢＭＰ、Ｅｘｉｆ、ＧＩＦ、ＪＰＧ（ｊｐｅｇ）、ＰＮＧ、ＰＮＭ（ＰＰＭ、ＰＧＭ、ＰＢＭ）、ＴＩＦＦなど、ベクトル・グラフィックス用のＡＩ、ＣＧＭ、Ｇｅｒｂｅｒ、ＳＶＧなど、３Ｄベクトル・グラフィックス・フォーマット用のＡＭＦ、ＤＷＧ、ＤＸＦ、ＦＬＴ、ＩＧＥＳ、ＶＲＭＬ、ｘＶＲＭＬなどの、グラフィカル・フォーマットを出力するモジュールを含む。
【0059】
文書処理の分野におけるエンコード・モジュール１４３の例は、ＤＯＣ、ＨＴＭＬ、ＰＤＦ、ＰＰＴ、ＷＰＤ、ＸＬＳ、ＸＭＬなどの、文書処理フォーマットを出力するモジュールを含んでもよいが、例えば、ＤＯＣＸ、ＸＬＳＸなど、ＯｐｅｎＯｆｆｉｃｅ（オープン・ソース）およびＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（Ｍｉｃｒｏｓｏｆｔ（商標）Ｃｏｒｐｏｒａｔｉｏｎによる）などのオフィス・スイートの現代のバージョンで使用されるフォーマットは、実際には、本発明の文脈では、解凍モジュール１４４によって最初に処理されるべき圧縮フォーマットである。
【0060】
典型的には、上記で挙げられたものなどの任意のエンコード・モジュール１４３が、対応するデコード・モジュール１４６を有するはずである。所与のフォーマットに対して、２つ以上のエンコード・モジュール１４３が利用可能なこともあり、２つ以上のデコード・モジュール１４６も利用可能なことがある。
【0061】
解凍モジュール１４４は、ファームウェア、ソフトウェア、および／またはハードウェアで実施され、入力ビット（例えば、ファイル、メモリ・オブジェクト、データベース・レコード、またはストリーミング・ビットストリームでさえ）を変換させる能力があり、圧縮モジュール１４１の入力と同一（非不可逆圧縮の）または同等（不可逆圧縮インスタンスの）である出力ビットにこの入力ビットをコンバートしてもよい。例示的解凍モジュール１４４が、任意の圧縮モジュール１４１によって実施された圧縮を逆転させるために提供され、典型的には、圧縮モジュール１４１が、例えばバンドルされて、提供される。注目すべき現在の例は、ＢＺｉｐ２（オープン・ソース）、Ｇｕｎｚｉｐ（上記で言及されたＧＺＩＰを解凍するためのもの）、Ｉｎｆｌａｔｅ（上記で言及されたＤｅｆｌａｔｅを解凍するためのもの）、例えば、＿ｕｎｘｚおよびｘｚなどのツールを介してアクセス可能なような、ＬＺＭＡおよびＸＺを含む。
【0062】
デコード・モジュール１４６は、マッチング・エンコード・モジュール１４３から出力された入力を受け入れ、出力を生成するためにこの入力を処理する変換器（フィルタ）である。デコード・モジュール１４６の出力は、エンコード・モジュール１４３によって受け取られた入力と同一である。一般に受け入れられている観念によって、デコード・モジュール１４６は、前記マッチング・エンコード・モジュール１４３によって生成された出力を前記マッチング・エンコード・モジュール１４３の入力と同一のデータに逆転させることによって、独自の出力を生成する。
【0063】
典型的には、上記で挙げられたものなどの任意のエンコード・モジュール１４３が、対応するデコード・モジュール１４６を有するはずである。所与のフォーマットに対して、２つ以上のエンコード・モジュール１４３が利用可能なこともあり、２つ以上のデコード・モジュール１４６も利用可能なことがある。
【0064】
アーカイブ・モジュール１４２は、少なくとも「データ」要素の、上記で定義されたような、複数のアーカイブ要素を、「データ」構造タイプの単一のアーカイブ要素（例えば、メモリ内のファイルまたはオブジェクト）に、パックすることができる。
【0065】
コンピューティング業界における多くの分野で使用中の広く普及したアーカイブ・モジュール１４２の例は、ｔａｒ（テープ・アーカイブ、Ｕｎｉｘシステムで広く普及したアーカイブ・フォーマットであり、例えば圧縮モジュール１４１への入力として典型的に使用される）、ａｒ（Ｕｎｉｘシステムの従来のアーカイブ・フォーマット）、ｉｓｏ（元々、ＣＤ－ＲＯＭまたはＤＶＤ－ＲＯＭなどの光ストレージ媒体の正確な、ほぼ正確な、またはカスタム修正された内容のアーカイブおよび配布のために主に使用されるアーカイブ・フォーマット）を含む。
【0066】
アンパック・モジュール１４５は、「データ」構造タイプの入力アーカイブ要素（例えば、メモリ内のファイルまたはオブジェクト）から複数のアーカイブ要素をアンパックまたは抽出可能である。
【0067】
元のアーカイブ要素１３０を目的アーカイブ要素１３２に変換させるためにパッチ・パッケージ１７０を使用するとき、ほとんどのケースでは、アップグレード・プロセスが意図的または偶然に割り込まれた場合、元のアーカイブ要素１３０の古い方のバージョンが無傷であり、動作可能であるように、元のアーカイブ要素１３０を直接的に修正（例えばアップグレード）しない方がより賢明である。したがって、ほとんどの実装形態が、別個のロケーションであるステージング領域１５０でアップグレード作業を実施し、アップグレードが成功した後だけ、目的アーカイブ要素を使用すること（任意選択で、目的アーカイブ要素を異なるロケーションにコピーすること）、およびこれ以上要求されないインストール・ファイル／オブジェクトを一掃することを始めることを選ぶはずである。
【0068】
アンパック・モジュール１４５は、典型的には、入力アーカイブからの１つまたは複数のアーカイブ要素をステージング領域１５０にアンパック可能であり、ステップに応じて、元のアーカイブ構造１５２または目的アーカイブ構造１５４へのこのようなアンパックが実施される。
【0069】
内容識別モジュール１４８は、これを記載するメタデータを読み取ることによって、またはアーカイブ要素内に含まれる実際のデータの全てもしくは一部分を読み取ることによって、「データ・タイプ」－前記アーカイブ要素内に含まれるデータのタイプ－を識別する能力がある特別に作られたソフトウェア、ハードウェア、および／またはファームウェアである。
【0070】
アーカイブ要素のデータ・タイプを決定するための、本技術分野における広く普及した方式は、「ファイルシステム・テスト」、「マジック・ナンバ」、および言語テストに対するタイプをテストすることによるものである。例えば、（Ｕｎｉｘにおいて）「ファイル」と呼ばれる広く普及したオペレーティング・システム実行可能ユーティリティは、ファイル内のデータのパターンをマッチングすることによってファイルタイプを検出するためのシステムの例である。例えば、ファイルの実際の内容を観察してそのフォーマットを決定し、できない場合、これに可能な限りマッチするフォーマットを決定してもよい、より厳密なソリューションが存在する。
【0071】
例えば、文書アーカイブ要素を文書オブジェクト・モデル（ＤＯＭ）に分解すること、データからアトミック・データ要素を抽出可能な、フォーマットに依存して作られた構成要素を使用すること、などによって、データのより洗練された分析を考慮した、さらに洗練された内容識別モジュール１４８が存在する。パッチ生成システム１１０は、２つ以上の内容識別モジュール１４８を含んでもよく、前記内容識別モジュール１４８は、過剰なアルゴリズムおよび構成要素を利用して、そのタスクを実行してもよい。
【0072】
ステージング領域１５０は、その仕様に応じて、プロセス２００、３００、および４００によってアクセス可能な、パッチ生成システム１１０およびパッチ適用システム１１２の動作のために要求されるストレージ空間を含む論理ユニットである。
【0073】
ステージング領域１５０は、単一のロケーションにおいて、または例えばいくつかのデータベースなどいくつかのストレージ媒体にわたって分割されて、分散データベースにおいて、単一のファイルシステムにおいて、いくつかのストレージ媒体またはいくつかのストレージ・ボリュームに及ぶファイルシステムにおいて、ＲＡＭにおいて、仮想メモリにおいて、オンチップ・メモリ・キャッシュにおいて、など、異なる方式で実施されてもよい。
【0074】
パッチ生成システム１１０の動作のために要求されるストレージ空間は、プロセス２００もしくはプロセス４００が始まるとすぐに予め準備されてもよく、または、プロセス２００もしくはプロセス４００がさらなるストレージ空間を要求するとアロケートされてもよい。ステージング領域１５０のために要求されるストレージ空間は、プロセス３００もしくはプロセス４００を完了した後、またはその内容を利用するステップがその実行を完了した後に解放されてもよい。
【0075】
時には、ステージング領域１５０は、目的アーカイブ要素１３２によってアロケートされた同じ空間上で直接的に定義される。このようなケースでは、多くの人によって危険であると考えられるが、当技術分野でよく知られているように、例えば、プロセスが何らかの理由で（意図的または偶然に）割り込まれた場合、目的アーカイブ要素およびパッチ・パッケージ１７０のデータ破損を回避するために、特別な考慮が実施されるべきである。
【0076】
ステージング領域１５０は、下記で指定されるような、少なくとも１つのアーカイブ構造から成る。
【0077】
元のアーカイブ構造１５２および目的アーカイブ構造１５４は、以下に記載のように、トラバース可能なデータ構造（例えば、ツリー、リンクされたリスト、ハッシュ・マップ、ファイルシステムなど）における０個以上のアーカイブ要素のセットのそれぞれを備える。以下に記載のようなアーカイブ要素識別子を使用することによって、前記各セット内の前記０個以上のアーカイブ要素にアクセス可能でもよい。
【0078】
差分モジュール１６０は、データの２つのセットの間の差の技術的説明を生成する特別に作られたモジュールである。差分モジュール１６０は、典型的には、パッチ・データ１７２に到達するためにデルタ圧縮アルゴリズムを採用し、デルタ圧縮アルゴリズムは、典型的には、当技術分野では、「デルタ」、「デルタ・アップデート」、「アップデート」、「ペイロード」、または「パッチ」と呼ばれ、本開示ではパッチ・データ１７２と呼ばれる。
【0079】
差分モジュール１６０は、元のアーカイブ要素１３０（ソース）および目的アーカイブ要素１３２（目的）を入力として受け取り、典型的には、これらに対する、デルタ圧縮差分データ、すなわちパッチ・データ１７２を出力する。
【0080】
デルタは、対称デルタおよびディレクテッド・デルタという、２つの方式で定義可能である。対称デルタは、
Δ（ｖ１，ｖ２）＝（ｖ１＼ｖ２）∪（ｖ２＼ｖ１）
として表現可能であり、ここで、ｖ１およびｖ２は、２つのバージョン、すなわち本発明の文脈では、元のアーカイブ要素１３０および目的アーカイブ要素１３２を表す。
Δ（ｖ１，ｖ２）＝（ｖ１＼ｖ２）∪（ｖ２＼ｖ１）
として表現可能であり、ここで、ｖ１およびｖ２は、２つのバージョン、すなわち本発明の文脈では、元のアーカイブ要素１３０および目的アーカイブ要素１３２を表す。
【0081】
ディレクテッド・デルタは、上記で論じられたように、変更またはアップデートとも呼ばれ、１つのバージョンｖ１に適用されたときに別のバージョンｖ２を生ずる、（初歩的な）変更動作のシーケンスである。コンピュータ実装形態では、これらは、典型的には、ｖ１からデータをコピーすること、および文字データを書き込むことという、少なくとも２つのコマンドを伴う言語の形式をしている。
【0082】
よく知られた差分モジュール１６０は、定義済みのＲＦＣ３２８４のようなＶＣＤｉｆｆ、その文書化のパック・フォーマット・ページで定義されているようなＧｉｔ ｒｅｐａｃｋ、例えば「Ｎａｉｖｅ ｄｉｆｆｅｒｅｎｃｅｓ ｏｆ ｅｘｅｃｕｔａｂｌｅ ｃｏｄｅ」および世界中の複数の公開コード・リポジトリにおける、例えばＣｏｌｉｎ Ｐｅｒｃｉｖａｌによって定義されているような、ＢＳＤｉｆｆ、ならびに、ＵｎｉｘおよびＬｉｎｕｘ（登録商標）オペレーティング・システムの「ｄｉｆｆ」コマンドのようなビンテージ・モジュールをも含む。
【0083】
差分モジュール１６０の多くの実装形態は、構造タイプ「データ」の単一のアーカイブ要素を処理することしかできず、したがって、この限界を克服し、本発明によってハンドリングされる構造タイプの多様性に対処できるように、下記で両方論じられるプロセス２００およびプロセス４００によって特別なハンドリングが実施される。
【0084】
図１ｂに示されたパッチ適用モジュール１８０は、目的アーカイブ要素１３２を再構築するために、元のアーカイブ要素１３０ならびにパッチ・データ１７２およびパッチ命令１７４を入力として受け取ることが可能な、特別に作られたモジュールである。
【0085】
いくつかのケースでは、パッチ適用モジュール１８０は、構造タイプ「データ」のただ１つのアーカイブ要素を受け取ることが可能である。他のケースでは、パッチ適用モジュール１８０は、複数のアーカイブ要素を受け取ることが可能である。さらなるケースでは、パッチ適用モジュール１８０は、「ディレクトリ」構造タイプのアーカイブ要素を受け取ることが可能である。さらなるケースでは、パッチ適用モジュール１８０は、「アーカイブ」構造タイプのアーカイブ要素を受け取ってもよい。最後に、他のさらなるケースでは、パッチ適用モジュール１８０は、「圧縮済み」構造タイプのアーカイブ要素を受け取ってもよい。
【0086】
任意選択で、図１ｂに示された適用器ポリシ１３６が使用されてもよい。これらのポリシは、下記で論じられるプロセス４００をどのように実施するかについてのルールのセットを含む。ルールは、変換モジュール１４０に関する任意の論理述語、構造タイプ、データ・タイプ、および、プロセス４００によって処理されるアーカイブ要素のプロパティ、ならびに、パッチ適用モジュール１８０に関する論理述語、および、プロセス４００中に使用される任意のモジュールに渡されるパラメータを含んでもよい。
【0087】
よく知られたパッチ適用モジュール１８０は、ＵｎｉｘおよびＬｉｎｕｘ（登録商標）オペレーティング・システムのビンテージ「パッチ」コマンドから、ＶＣＤｉｆｆパッチ・データを処理するためのｘｄｅｌｔａ３、ＢＳＤｉｆｆが生成したパッチ・データを処理するためのｂｓｐａｔｃｈなどのより洗練されたモジュールに及ぶ。
【0088】
本発明の実施形態による、デコード済みアーカイブ構造をそれぞれ準備するために、元のおよび目的アーカイブ要素１３０、１３２をトラバースするプロセス２００を示す図２への参照がここで行われる。
【0089】
プロセス２００は、好ましくはステージング領域１５０で、デコード済みアーカイブ構造をそれぞれ準備するために、元のアーカイブ要素１３０および目的アーカイブ要素１３２をトラバースする。次いで、プロセス２００は、前記デコード済みアーカイブ構造のそれぞれをトラバースし、前記デコード済みアーカイブ構造のそれぞれに含まれるアーカイブ要素をさらにアンパック、解凍、およびデコードする。
【0090】
このプロセスの最初の２つの結果は、元のアーカイブ構造１５２および目的アーカイブ構造１５４である。両方は、以下に記載のような、トラバース可能なデータ構造に（例えば、ファイルシステム、ツリー、リンクされたリスト、ハッシュ・マップなどにおける）０個以上のアーカイブ要素のセットを備える。追加の結果は、プロセス２００が元のアーカイブ要素１３０および目的アーカイブ要素１３２、ならびに元のアーカイブ構造１５２および目的アーカイブ構造１５４をトラバースすると、プロセス２００によって構築されるパッチ命令のセット、パッチ命令１７４である。１つの元の要素および１つの目的要素を備えるマッチング・ペアに関する、ならびに、例えばプロセス２００のさらなる実行ステップにおいて元のアーカイブ要素１３０内および目的アーカイブ要素１３２内で遭遇された内部アーカイブ要素を備えるマッチング・ペアに関するパッチ命令が構築される。
【0091】
そのそれぞれのアーカイブ要素の構造タイプおよびデータ・タイプに関するパッチ命令も構築され、以下に詳細に記載されているような、アクション、選択されたデコード・モジュール１４１、選択された圧縮モジュール１４１およびその動作のためのメタデータなど、さらなるデータも含んでもよい。好ましい実施形態では、パッチ命令１７４は、プロセス２００が進むとプロセス２００によって、または代替もしくは追加として、プロセス３００によって、パッチ・パッケージ１７０に組み込まれてもよい。
【0092】
プロセス２００は、例えば、ヒープ・メモリを使用すること、スタック・メモリを使用すること、などによって、再帰的または段階的に、１つまたは複数のプロセッサによって実行可能である。２つ以上のプロセッサまたは２つ以上の処理コアもしくはスレッドを使用してプロセス２００が実行されるケースでは、プロセス２００は、例えば、プロセス２００動作中に明らかにされたアーカイブ要素を処理するために、例えばフォーク動作を使用して例えばマルチタスク化すること、マルチスレッド化すること、などによって、適用可能な場合、別個のコアまたはスレッドにおいてステップを実行してもよい。
【0093】
プロセス２００はまた、その機能、ステップ、および結果が維持されるように準備された、異なる、場合によっては、より複雑な配置で、または異なるハードウェアを使用して、実行するように構成可能である。プロセス２００は、典型的には、パッチ生成システム１１０によって実施される。
【0094】
ステップ２０１において、パッチ生成システム１１０は、典型的には、例えばユーザまたはアプリケーション・ソフトウェアから、元のアーカイブ要素１３０および目的アーカイブ要素１３２という２つの主な入力、ならびに任意選択でパッチ生成器ポリシ１３４も同様に、受け取る。これら２つの主な入力は、アーカイブ要素の「マッチング・ペア」であると考えられる。一般に、ほとんどの処理ステップがマッチング・ペアに対して実施され、いくつかの処理ステップが、マッチング・ペアにおける１つのアーカイブ要素、またはマッチング・ペアにおける両方のアーカイブ要素に対して実施される。
【0095】
元のアーカイブ要素１３０が完全に省略されるか、「ｎｕｌｌ」として指定されるか、そうでなければ、元のアーカイブ要素１３０が存在しないことがパッチ生成システム１１０に指示され得る、特別な実施形態が存在する。このような特別な実施形態は、典型的には、目的アーカイブ要素１３２の圧縮フォーマットを生じるが、プロセス３００の説明の後に説明される。
【0096】
ファイル、レコード、メモリ－入力アーカイブ要素が、例えばストレージ媒体に常駐するファイルシステム上のファイルであるとき、入力の識別子は、入力ファイルへのフル・パス、入力ファイルへの相対パス、ＭＦＴレコードなどのストレージ・インデックス番号、またはｉ－アーカイブ要素番号（Ｕｎｉｘスタイル・ファイルシステムにおけるインデックス・アーカイブ要素）などでもよい。入力がメモリ・ロケーションであるケースでは、入力の識別子は、例えば、適用可能な場合、指名されたプロセッサ上のプロセスの実行コンテキスト内の絶対メモリ参照、相対メモリ参照などであることが可能である。入力がデータベースのレコードであるケースでは、入力は、データベース固有表記法を使用することまたはドライバ固有表記法（例えばセキュリティ証明書を伴う、例えばＯＤＢＣ／ＪＤＢＣデータベース接続およびデータベース・アクセス・ノーテーション）を使用すること、データベースのテーブル内のレコード番号、文書データベースにおけるデータベース・レコードのＩＤ、グラフ・データベースの場合のアーカイブ要素ＩＤ、などによって、指定されてもよい。
【0097】
ロケーション－通常、初めてプロセス２００を実行するとき、元のアーカイブ要素１３０自体にセットされた元の要素、および目的アーカイブ要素１３２自体にセットされた目的要素を備える、第１のマッチング・ペアが構築される。例えば、目的アーカイブ要素１３２は、圧縮アーカイブ・ファイル「ｂ．ｔａｒ．ｇｚ」を指し示してもよい。
【0098】
しかし、多くのケースでは、プロセス２００は、例えばアーカイブのほんの一部分など、アーカイブのより多くの固有の部分を指示する出発点で、パッチ生成システム１１０またはパッチ適用システム１１２によって実行されてもよい。これらのケースでは、プロセス２００は、目的アーカイブ要素１３２のサブセットのための目的アーカイブ構造１５４を構築する。例えば、目的アーカイブ要素１３２は、圧縮アーカイブ・ファイル「ｂ．ｔａｒ．ｇｚ」内のディレクトリ「／ｉｍａｇｅｓ／ｐｎｇｓ」を、すなわち、「ｂ．ｔａｒ．ｇｚ：／ｉｍａｇｅｓ／ｐｎｇｓ」と同様の表記法で指し示してもよい。
【0099】
一般に、任意のアーカイブ要素の識別子は、ネストされたレベルの抑制を指示してもよく、例えば、「ｂ．ｔａｒ．ｇｚ：／ｉｍａｇｅｓ／ｐｎｇｓ／２０２０－ｉｍａｇｅｓ．ｊａｒ：／ｊａｎｕａｒｙ／」と同様の識別子が、．ｊａｒ圧縮アーカイブ・ファイル内に含まれるディレクトリ「ｊａｎｕａｒｙ」を指示することになり、この場合、．ｊａｒ圧縮アーカイブ・ファイルは、圧縮アーカイブ・ファイル「ｂ．ｔａｒ．ｇｚ」内の「／ｉｍａｇｅｓ／ｐｎｇｓ／」ディレクトリに置かれる。
【0100】
プロセス４００のコンテキストでは、内部アーカイブ要素を含み得るネストされたアーカイブ済みアーカイブ要素および圧縮アーカイブ要素は、このようなネストされたレベルの抑制を使用するロケーション識別子で表記されることが多い。このようなケースでは、プロセス４００は、ネストされたロケーションを少なくとも再作成することを要求されてもよい。ネストされたロケーションを再作成するために、プロセス４００は、その後、ロケーションにおける各ネストされたレベルの抑制を処理し、それぞれに対して正しい構造タイプを使用して適切なアーカイブ要素を再作成してもよい。
【0101】
例えば、上記で言及された非限定的例では、圧縮アーカイブ「ｂ．ｔａｒ．ｇｚ」のためのロケーションは、最初に、例えば目的アーカイブ構造１５２で、次いで、前記圧縮アーカイブ内のディレクトリ／ｉｍａｇｅで、次いで、前者の／ｉｍａｇｅディレクトリ内の別のディレクトリ／ｐｎｇｓで、次いで、次の、名前２０２０－ｉｍａｇｅｓ．ｊａｒを有するｊａｒ圧縮アーカイブで、および最後に、ｊａｒ圧縮アーカイブ内の最後のディレクトリ／ｊａｎｕａｒｙで再作成されるはずである。
【0102】
ネストされたロケーションは、再作成されたとき、その最終的なフォーマットである必要はなく、むしろ、目的アーカイブ構造１５４がファイルシステム上にある場合、単に特別に作られたディレクトリであること、または、目的アーカイブ構造１５４がメモリ内にあるケースでは、単に関連データ構造としてあることが可能である。プロセス４００は、典型的には、例えば、下記のプロセス４００で指定されるような変換モジュール１４０を使用して、あらゆるネストされたレベルをその正しい構造タイプに変換させるはずである。
【0103】
アロケート（ＰＩ）－典型的には、ステップ２０１は、ステージング領域１５０に現在のパッチ命令１７４およびパッチ・データ１７２のためのストレージ空間を少なくともアロケートするはずである。パッチ命令１７４は、パッチ・アプリケーション・システム１１２を使用して、およびいくつかのケースでは、パッチ・データ１７２も同様に使用して、現在のパッチ命令１７４を元の要素に適用することによって目的要素を再構築するために、プロセス４００において使用可能になる。
【0104】
ステップ２１０において、パッチ生成システム１１０は、（上記で開示の）５つの構造タイプのうちのどれが、目的要素のアーカイブ要素に、および任意選択で元の要素のアーカイブ要素に関連付けられるかを識別する。まず、パッチ生成システム１１０は、構造タイプを識別してもよい。構造タイプは、パッチ・プロセス４００において、トラバース・プロセス２００において、およびパッケージ化プロセス３００において特別な考慮が行われ、前記プロセスの実行フロー、およびその出力に影響する。ステップ２１０によって識別された５つの構造タイプは、元のアーカイブ要素１３０のために上記で開示された。
【0105】
構造タイプの識別－構造タイプを識別するための多くのアプローチがある。時には、これは、ステップ２１０によって処理された入力から明らかであり、例えば、ステップ２１０が、ファイル・システムＡＰＩなどの関連ＡＰＩを通じてアーカイブ要素を処理するとき、ステップ２１０は、ステップ２１０がファイルをハンドリングするか、ディレクトリをハンドリングするかについての情報を既に有している。パッチ生成システム１１０はまた、上記で言及された例においてアーカイブ要素のファイル拡張子を単純に検査して、例えば、「アーカイブ」のための「．ｔａｒ」、および「Ｄｅｆｌａｔｅ」法を使用したさらなる「圧縮済み」の「アーカイブ」のための「ｊａｒ」など、その構造タイプを識別しようとすることができる。
【0106】
しかし、このようなアプローチは、アーカイブ要素内に含まれるデータが読み取られず、有効な既知のデータ・フォーマットと比較されない場合、しばしば失敗することがある。したがって、ステップ２１０において、構造タイプを識別することに加えて、ステップ２１０は、構造タイプを正しく識別する、より高い確実性を有し、ならびにアーカイブ要素におけるデータのフォーマットの、より高い確実性を有するように、内容識別モジュール１４８を使用することによってアーカイブ要素のデータ・タイプを識別することに進んでもよい。
【0107】
加えて、ステップ２１０はまた、識別された構造タイプに関係のあるいずれかのメタデータを読み取り、このようなメタデータが、識別された構造タイプの仕様と互換性があることを検証してもよい。
【0108】
パッチ命令１７４の構築－目的要素および元の要素の検査済みアーカイブ要素の構造タイプ、ならびに任意の関連付けられたメタデータを識別した後、プロセス２００は、元の要素にパッチを当てて目的要素にすることに関する、検査済みアーカイブ要素のための少なくとも初期のパッチ命令１７４を構築するための十分な情報を既に有しており、初期のパッチ命令を構築してもよい（しかし、これは、ステップ２６０および２７０の前にこれが実施される限り、他のステップまで延期されてもよい）。パッチ命令１７４は、以下のように構築される。
【0109】
アクション－（例えば「ｎｕｌｌ」ポインタによって表された）目的アーカイブ構造１５４に元の要素がないケースでは、元の要素の識別子のために「削除」アクションが構築されたという指示が、パッチ命令１７４に追加される。目的アーカイブ構造１５４に元の要素がないケースでは、「追加」アクションの指示が構築され、および目的要素の識別子が、パッチ命令１７４に追加される。典型的には、同一の識別子を有するアーカイブ要素が存在するが、前記任意のアーカイブ要素の少なくとも１つの他のプロパティが、元のアーカイブ構造１５２および目的アーカイブ構造１５４の両方において同一でないとき、これらは、「アップデート」アクションを構築し、これをパッチ命令１７４に追加することによって指示されてもよい。
【0110】
典型的には、同一の識別子を有する元の要素に対して、目的アーカイブ構造１５４に目的要素がないとき、例えば「削除」アクションのケースにおいて、プロセス２００は、ステップ２７０に直接的に進んでもよい。１つまたは複数のデコード・モジュール１４６がステップ２３０によって識別されたケースでは、パッチ生成システム１１０はステップ２４０に続き、そうでなければ、ステップ２７０に直接的に進む。元の要素および目的要素の両方が同一であるという特定のケースでは、そのアクションを「不変」として指示することが可能であるが、このような指示は冗長であり、したがって、典型的には、２つの要素が同一であるとき、現在のパッチ命令にいかなるアクションも含まないことが、より効率的である（例えば、ストレージ空間を節約する、実行時間を節約する）。アクションに対する指示は、ストレージ空間の１バイト未満しか占有しないように簡潔な形式、または、例えば英語の言語を表すＵＴＦ－８文字列など、精巧な形式で符号化されてもよい。
【0111】
構造タイプが「アーカイブ」タイプであるケースでは、典型的には、例えばこのアーカイブ要素のデータ・フォーマットなど、このアーカイブ要素のデータ・タイプをパッチ命令１７４において明示的に指示することが有益である。例えば異なる（たとえ関係があっても）フォーマットとして解釈され得る「ＢＭＰ」などの曖昧なノーテーションに単に依存するのではなく、例えば、ｍｉｍｅタイプ、ＩＳＯ定義などを使用するなど、国際的に受け入れられた規格などのよく定義されたフォーマット指標を使用することによって、構造タイプの前記明示的な指示をフォーマットすることが助言される。
【0112】
構造タイプが「リンク」タイプであるケースでは、例えば前記他のアーカイブ要素の識別子を含めることなどによって、目的要素において／よって、どの他のアーカイブ要素にリンクされるかについての指示をパッチ命令１７４に含めることが有益である。
【0113】
識別されたデータ・タイプが、プロセス４００によって同一に再構築されるようにさらなるメタデータを要求するケースでは、または、これがプロセス４００によって同一に再構築不可能であるか、下記で説明されるように、プロセス４００によって可能な限り同様に再構築されることになるケースでは、－任意のさらなるメタデータの明示的指示が、次いで、パッチ命令１７４に追加される。
【0114】
いくつかの実施形態は、デフォルト構造タイプ（例えば「データ」）を有し、さらなる空間を節約するために、パッチ命令１７４でこれを指示しないことを選んでもよい。
【0115】
データ・タイプの例
非限定的例として、ステップ２４０から２４１までを示すために使用する基準例を考え、ここでは、そのマッチング・ペアのための目的アーカイブ要素１３２における対応する他のアーカイブ要素を有する目的アーカイブ要素１３２におけるアーカイブ要素が、ＰＮＧデータの内容を含むファイルとして識別された。この基準例では、ステップ２１０は、内容識別モジュール１４８を使用することによって「ｆｉｌｅ１．ｐｎｇ」という名のファイルであるアーカイブ要素のデータ・タイプを「ＰＮＧ画像データ」として、および、そのメタデータの一部を、例えば「５００×５００，８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ」として識別してもよい。しかし、ＰＮＧフォーマットおよびＢＭＰフォーマットの両方は既に、画像の寸法に関する十分な情報を含んでおり、したがって、第１のメタデータ「５００×５００」は、明示的に要求されなくてもよい。このケースでは、パッチ命令は、｛ａｃｔｉｏｎ＝Ｕｐｄａｔｅ；Ｄｔｙｐｅ＝“ｄａｔａ”；ｎａｍｅ＝“ｆｉｌｅ１．ｐｎｇ”；ｍｅｔａｄａｔａ＝“８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ”｝を指示するように構築されてもよい。
非限定的例として、ステップ２４０から２４１までを示すために使用する基準例を考え、ここでは、そのマッチング・ペアのための目的アーカイブ要素１３２における対応する他のアーカイブ要素を有する目的アーカイブ要素１３２におけるアーカイブ要素が、ＰＮＧデータの内容を含むファイルとして識別された。この基準例では、ステップ２１０は、内容識別モジュール１４８を使用することによって「ｆｉｌｅ１．ｐｎｇ」という名のファイルであるアーカイブ要素のデータ・タイプを「ＰＮＧ画像データ」として、および、そのメタデータの一部を、例えば「５００×５００，８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ」として識別してもよい。しかし、ＰＮＧフォーマットおよびＢＭＰフォーマットの両方は既に、画像の寸法に関する十分な情報を含んでおり、したがって、第１のメタデータ「５００×５００」は、明示的に要求されなくてもよい。このケースでは、パッチ命令は、｛ａｃｔｉｏｎ＝Ｕｐｄａｔｅ；Ｄｔｙｐｅ＝“ｄａｔａ”；ｎａｍｅ＝“ｆｉｌｅ１．ｐｎｇ”；ｍｅｔａｄａｔａ＝“８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ”｝を指示するように構築されてもよい。
【0116】
ステップ２２０において、パッチ生成システム１１０は、目的要素および元の要素の構造タイプを考慮して、これらのいずれかが、内部アーカイブ要素を含み得る複合的なアーカイブ要素であるかどうかを決定し、これらが含まれるケースでは、以後の本明細書に従って、ステップ２５０、２５１、２６０、および２６１を実施する。
【0117】
内部アーカイブ要素を含み得るアーカイブ要素の多くの例がある。例えば、広く普及したＭＳ Ｗｏｒｄアプリケーションによって保存された文書はＤＯＣＸフォーマットで保存され、ＤＯＣＸフォーマットは、本質的には、Ｄｅｆｌａｔｅアルゴリズム、および、固有の実行パラメータで構成された圧縮モジュールを使用する、適合された圧縮アーカイブ・ファイルである。このＤＯＣＸフォーマットは、例えば、ＤＯＣＸファイルの内容に対して、またはＤＯＣＸファイルを表すデータ・ストリームの内容に対して、「ＩＮＦＬＡＴＥ」解凍モジュール１４４を単に実行することによって、解凍可能である。
【0118】
別の例では、アーカイブ要素は、広く普及した「ｔａｒ」Ｕｎｉｘユーティリティによって構築されたファイルであり、これは、これに対して「ｇｚｉｐ」エンコーダを適用することによって圧縮されることが多い。結果は、多くのインターネット・ダウンロード・ウェブサイトで見られる（２重）拡張子「．ｔａｒ．ｇｚ」をしばしば有する、圧縮アーカイブ・ファイルである。このケースでは、２つの変換モジュール１４６および１４４が、このようなアーカイブ要素を変換するために順番に使用されるべきであり、第１の解凍モジュール１４４は、Ｕｎｉｘコンピューティング・デバイス上の「ｇｕｎｚｉｐ」ユーティリティなどのものであり、第２のデコード・モジュール１４６は、適切なコマンドおよび／またはフラグを伴う広く普及した「ｔａｒ」Ｕｎｉｘユーティリティである。
【0119】
他のケースでは、パッチ生成システム１１０は、アーカイブ要素をその内部アーカイブ要素にデコードするのに必要なデコーダのシーケンスを直接指示しないアーカイブ要素に遭遇することがある。したがって、結果として生じた内部アーカイブ要素をトラバースするために再び（例えば回帰によって）プロセス２００を適用することは、下記で説明されるように、前記アーカイブ要素を完全にデコードするという予想結果を生ずる。
【0120】
入力の目的要素または元の要素が複合的なアーカイブ要素であるケースでは、パッチ生成システム１１０は、ステップ２５０を実施する。そうではなく、目的要素および元の要素が複合的なアーカイブ要素でないとき、（図２ｂへの継続指標２２５で図に指示されているように）ステップ２３０が実行される。
【0121】
ステップ２３０において、パッチ生成システム１１０は、マッチング・ペアにおけるアーカイブ要素の内容をデコード可能な少なくとも１つのデコード・モジュール１４１を識別しようとする。
【0122】
このステップでは、パッチ生成システム１１０は、目的要素および元の要素が「ディレクトリ」または「アーカイブ」構造タイプでないこと、ならびに、識別された変換モジュール１４１が、所与のアーカイブ要素をデコード・フォーマットに変換させる能力があることを既に決定しているので、パッチ生成システム１１０は、目的要素および／または元の要素が、いくつかのレベルの効率（例えば圧縮）でエンコードされたデータを含み得ることを決定している。
【0123】
したがって、ステップ２３０から２４１までの目的は、目的要素および／または元の要素を、より圧縮されたものではなく、より精巧なアーカイブ要素に変換させることである。この目標は、当初、専門家が、今日ソフトウェア・パッケージ、アーカイブ、およびアップデートについて考える方式、ならびに、今日これらがどのようにしてパッケージ化され、ネットワークで送られるか（例えば、．ｔａｒ．ｇｚまたは「．ｃａｂ」データ構造でのインターネット・ダウンロード）とは対照的なので、直観に反するように見えることがある。これは、現在の文書アーカイブが保管される方式（例えば、圧縮ＤＯＣＸデータ構造においてそれぞれ複数だが別個のファイル）とも対照的である。
【0124】
しかし、これらの以下のステップは、下記で説明されるように、より良い圧縮率またはより低いストレージ空間要件など、より高い効率を後で達成するために、不可欠である。
【0125】
ステップ２３０から２４１までは、プロセス２００の全体効率を向上させることができるが、これらのステップは任意選択であり、プロセスは、これらがない状態で実行されてもよい。
【0126】
典型的には、ステップ２３０は、例えば、下記で論じられるような、個別のアトミック・ユニットの形式のデータを表現したものなど、目的要素の最も精巧なバージョンを提供することになるデコード・モジュール１４６を可能な限り選択する。個別のアトミック・ユニットの形式のデータを表現することは、差分モジュール１６０が同一データ部分をロケートし、目的要素においてこれらの部分が元々エンコードされたものより効率的に、（下記で論じられるような）プロセス３００においてこれらの部分をエンコードする機会を提供する。デコード・モジュール１４６を選択するための別の方式は、同じ個別のアトミック・ユニットを使用して可能な限りほとんどのアーカイブ要素を処理できるものを選択することである。
【0127】
アトミック・ユニット－アーカイブ要素を備える個別のアトミック・ユニットは、既にアーカイブ要素がエンコード形式であるケースでは、前記アーカイブ要素内の特定のエンコード・フォーマットで配置されたデータではなく、実際の含まれるデータを表現したものである。本開示のために、アトミック・ユニットはまた、特定のデータ・タイプのデータの大部分が、同一のデータ・タイプを有する２つ以上のアーカイブ要素にわたって技術的に表現され得るデータ・フォーマットとして定義されてもよい。
【0128】
例えば、コンピュータ・グラフィックス画像のデータ・タイプのケースにおける個別のアトミック・ユニットは、前記コンピュータ・グラフィックス画像を備える着色ピクセルであることが可能である。このケースでは、パッチ生成システム１１０は、コンピュータ・グラフィック画像（例えば、ＰＮＧ、ＪＰＧなどのフォーマットのものを含む）を備えるアーカイブ要素の全てまたは一部を表現するためのアトミック・ユニットとして、および、データ・フォーマットを指示するためにｍｉｍｅタイプが使用される場合、アーカイブ要素を「ｉｍａｇｅ／ｂｍｐ」として表すためのデータ・フォーマットとして、ピクセル－ビットマップを選択してもよい。
【0129】
パッチ生成システム１１０が個別のアトミック・ユニットの少なくとも１つの形式を選択すると、パッチ生成システム１１０は、目的要素の内容をより精巧な形式にデコード可能な適切なデコード・モジュール１４６を描写する。パッチ生成システム１１０は、次いで、精巧なフォーマットの選択の指示をパッチ命令１７４に含めてもよく、次いで、プロセス４００がパッチ命令１７４および元のアーカイブ要素１３０から目的要素を再構築することができるように、この特定のエンコード・フォーマットを含んでもよい。例えば、上記の例において、例示的パッチ命令１７４を｛ａｃｔｉｏｎ＝Ｕｐｄａｔｅ；ｎａｍｅ＝“ｆｉｌｅ１．ｐｎｇ”；ｍｅｔａｄａｔａ＝“８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ”；ｆｏｒｍａｔ＝“ＰＮＧ”；ｅｎｃｏｄｉｎｇ＝“ｉｍａｇｅ／ｂｍｐ”｝にアップデートするさらなる指示を、パッチ命令１７４｛ａｃｔｉｏｎ＝Ｕｐｄａｔｅ；ｎａｍｅ＝“ｆｉｌｅ１．ｐｎｇ”；ｍｅｔａｄａｔａ＝“８－ｂｉｔ／ｃｏｌｏｒ ＲＧＢＡ，ｎｏｎ－ｉｎｔｅｒｌａｃｅｄ”｝に含める。
【0130】
複数のデコード・モジュール－この時点までに、ステップ２３０は、単一のデコード・モジュール１４６を識別した。しかし、例えば、差分モジュール１６０がデコード・モジュール１４６に適用されるとすぐに、どのデコード・モジュール１４６が最善の効率を生じることになるかなど、好ましい出力データ・フォーマットを容易に決定できない状況がある。これらのケースでは、ステップ２３０は、２つ以上のデコード・モジュール１４６を選択してもよく、ステップ２４０は、次いで、下記で指定されるように調節することになる。
【0131】
時には、パッチ生成器ポリシ１３４は、デコード・モジュール１４６の選択における指示のためのルールを含んでもよい。例えば、場合によっては、パッチ・パッケージ１７０を実行するコンピューティング・デバイスにおいて利用可能なリソース、またはこのコンピューティング・デバイスにおける既知の制約を考慮して、所与のデコード・モジュール１４６を義務付ける、使用されることになる特定のパラメータまたはオプションを指定する、所与のデコード・モジュール１４６を禁止する、などである。
【0132】
ステップ２４０において、ステップ２３０が成功した後、識別された少なくとも１つのデコード・モジュール１４６毎に適用することによって、元の要素および目的要素の内容をデコード形式にデコードし、ステージング領域１５０上で、使用されるデコード・モジュール１４６毎に、デコード済みの目的アーカイブ要素を構築することが可能な少なくとも１つのデコード・モジュール１４６を識別する。
【0133】
元の要素をデコードするとき、デコード・モジュール１４６の結果として生じた出力は、ステージング領域１５０における、元のアーカイブ構造１５２内のデコード済みの元の要素１３０に置かれてもよい。デコード済みの元の要素は、次いで、その後の処理における、すなわち、元の要素を含むマッチング・ペアにおける元の要素を置き換えてもよい。
【0134】
目的要素をデコードするとき、デコード・モジュール１４６の結果として生じた出力は、ステージング領域１５０における、目的アーカイブ構造１５４内のデコード済みの目的要素に置かれてもよい。デコード済みの目的要素は、次いで、その後の処理における、すなわち目的要素を含むマッチング・ペアにおける目的要素を置き換えてもよい。
【0135】
ステップ２１０において記載された非限定的な基準例への参照が行われ、ステップ２１０において、アーカイブ要素（例えば目的要素）がＰＮＧフォーマットのコンピュータ・グラフィックスとして識別された。パッチ生成システム１１０は、グラフィックス内のあらゆる単一のピクセルをそのデータとして詳述し得るフォーマットであるＢＭＰフォーマットの出力に、ＰＮＧエンコード入力をデコード可能な「ｐｎｇ２ｂｍｐ」によって識別されたデコード・モジュール１４６を選択してもよい。パッチ生成システム１１０は、次いで、目的アーカイブ構造１５４へ、「ｐｎｇ２ｂｍｐ」という名前のデコード・モジュール１４６を使用して目的要素をデコード済みの目的要素にデコードし、元のアーカイブ構造１５２へ、「ｐｎｇ２ｂｍｐ」という名前のデコード・モジュール１４６を使用して元の要素をデコード済みの元の要素にデコードすることになる。
【0136】
任意の結果として生じたデコード済みアーカイブ要素が構築されたとき、ステップ２３０～２４０は、これ以上デコーダ１４６が識別されなくなるまで、構築されたデコード済みアーカイブ要素を入力として用いて繰り返してもよい。いくつかの実施形態では、これは、最後のデコード・モジュール１４６のみを指示するのに十分であり、エンコード・モジュール１４３のエンコード形式を再生成するために要求されるエンコード・モジュール１４３のシーケンスを決定するために、エンコード・モジュール１４３をパッチ適用システム１１２に任せてもよい。他の実施形態では、全ての前記繰返しが、パッチ命令１７４に記録されてもよい。
【0137】
ステップ２４１において、パッチ生成システム１１０は、保持するマッチング・ペアとして、デコード済みの元のアーカイブ要素およびデコード済みの目的アーカイブ要素から最後のデコード形式を選択する。この時点で、ステップ２４１は、任意の他のデコード済みの元のおよび目的アーカイブ要素を配置してもよい（例えば、ステージング領域１５０から削除または解放してもよい）。
【0138】
これは、パッチ生成器ポリシ１３４におけるルールに従って、もしくはパッチ生成システム１１０において構成されたように、または、例えばただ１つのデコード・モジュール１４６が使用された場合など、デコード済みの元のおよび目的アーカイブ要素のただ１つのセットが存在するケースにおいて、既存のデコード形式だけを選択することによって、実施されてもよい。
【0139】
パッチ生成器ポリシ１３４のルールは、結果として生じたデコード済みの元のアーカイブ要素およびデコード済みの目的アーカイブ要素の任意の可読のプロパティを使用してもよい。例えば、簡単なルールが、所与のデコーダ１４６を選択することになるはずである。
【0140】
１つまたは複数のルールは、実装形態に直接的に構築されてもよく、したがって、１つまたは複数のルールは、パッチ生成システム１１０に「ハード・コード」され、パッチ生成器ポリシ１３４に従う必要はない。
【0141】
実装形態の設定および実施形態に応じて、ステップ２４１は、選択された要素以外の全ての目的アーカイブ要素１３２を除去すること、例えばステージング領域１５０上で、メモリおよび／またはストレージ空間を取り戻すことなどを含む、「ハウスキーピング」ステップを実施することを要求されてもよい。これらのハウスキーピング活動はまた、ステップ２４１、２５２、または２９９など、その後のステップにおいて、いつ実施されてもよい。
【0142】
パッチ生成システム１１０は、次いで、どのデコーダ１４６が使用されたかを記載するメタデータ、および要求される任意のさらなるメタデータ、ならびに目的要素の元のフォーマットをパッチ命令に追加する。いくつかの実施形態では、元の要素についてのメタデータが同様に追加されてもよいが、このような情報は、ほとんどの目的には冗長であると考えられることもある。
【0143】
いくつかの実施形態では、ステップ２３０から２４１までは、目的アーカイブ構造１５４全体が抽出された後にだけ行われ、したがって、少なくとも１つのデコード・モジュール（モジュール）１４６の選択プロセスが、プロセス２００によって発見された内部アーカイブ要素のセット全体を考慮に入れることが可能である。これらの実施形態は、個別のアトミック・ユニットを有する内部アーカイブ要素を表現する２つ以上の精巧なフォーマットがあるケースにおいて、より効率的なパッチ・パッケージ１７０を生じてもよい。
【0144】
他の実施形態では、ステップ２３０から２４１までは、図２に記載のような、プロセス２００のあらゆる反復中に行われる。これらの他の実施形態は、内部アーカイブ要素を表現するパッチ生成システム１１０に利用可能な１つの精巧なフォーマットしかないケースにおいて、より効率的なパッチ・パッケージ１７０を生じてもよい。
【0145】
ステップ２７０において、パッチ生成システム１１０は、パッチ命令１７４を記録し、パッチ命令１７４は、適用可能な場合、元の要素から目的要素の前記最も精巧な形式を再構築するために最低限要求されるものとして、元の要素の識別子および／または目的要素の識別子、目的要素の識別された構造および／またはデータ・タイプのタイプ、上に記載のように行われることになるアクション、任意選択で、元の要素から目的要素を再構築するために要求されるメタデータ、任意選択で、どのデコード・モジュール１４６が使用されたかを記載するメタデータ、ならびに、任意選択で、パッチ命令１７４に対する目的要素の元のエンコード・フォーマット、をここで含めるべきである。
【0146】
ここで、目的要素または元の要素の構造タイプがディレクトリまたはアーカイブであることを識別したときに行われる、ステップ２２０からの他の分岐に向かう。
【0147】
ステップ２５０において、パッチ生成システム１１０は、マッチング・ペアにおける各アーカイブ要素の構造タイプを、すなわち、元の要素に対して１度、およびマッチした目的要素に対して１度、考える。マッチング・ペアにおけるアーカイブ要素毎に、構造タイプが「アーカイブ」であるとき、ステップ２５０は、元の要素内および目的要素内に含まれる内部アーカイブ要素を抽出可能な、少なくとも１つの解凍モジュール１４１またはアンパック・モジュール１４５を識別しようとする。
【0148】
ステップ２５１において、パッチ生成システム１１０は、まず、ステップ２２０における前記アクションが「削除」を表さないことを保証し、したがって、パッチ生成システム１１０は、ここでは、ステップ２５０において識別された少なくとも１つのデコード・モジュール１４６またはアンパック・モジュール１４５を使用して、ステージング領域１５０上で目的要素をデコードまたはアンパックし、ステージング領域１５０上で元の要素をデコードまたはアンパックすることが可能である。
【0149】
このステップの結果は、典型的には、元のアーカイブ要素１３０に対する１つの元のアーカイブ構造１５２、および、目的アーカイブ要素１３２に対する１つの目的アーカイブ構造１５４であり、それぞれが、そのそれぞれのアーカイブ要素１３０、１３２からアンパックされた内部アーカイブ要素を備える。
【0150】
ステップ２３０～２５１の背後の推論
以下の数学的議論は、本発明を理解するのに必要な範囲を超えているが、より多くの数学的議論が、科学および工学コミュニティの、後のアカデミックな論文の中で提供されることが計画されている。下記でステップ２３０～２５１の推論および利益の簡単な説明を提示する。
以下の数学的議論は、本発明を理解するのに必要な範囲を超えているが、より多くの数学的議論が、科学および工学コミュニティの、後のアカデミックな論文の中で提供されることが計画されている。下記でステップ２３０～２５１の推論および利益の簡単な説明を提示する。
【0151】
しばしば、圧縮モジュール１４１は、例えば統計回帰モデルを使用して、（典型的には、より短い、または「より効率的な」）圧縮データに元のデータをマッピングした少なくとも１つの内部辞書を構築する。この辞書は、次いで、例えばマッチング解凍モジュール１４４によって、この辞書をどのように使用するかについての命令と共に圧縮データ内に格納される。
【0152】
例えば、大きいソフトウェア・パッケージのアップデート・パッチ１７０、またはアーカイブのために格納された文書のセットに、複数のアーカイブ要素がアーカイブされたとき、これらのうちのいくつかは、典型的には、既に圧縮形式である。適切なケースは、２０２１年０３月にリリースされたＥｃｌｉｐｓｅバージョン４．１９の公的に利用可能なソフトウェア・パッケージであり、ここでは、過剰な「ｊａｒ」タイプのファイルが１つの大きいパッケージで配布され、各「ｊａｒ」タイプのアーカイブ要素は、典型的にはｊａｖａクラス・オブジェクト・コードである内部アーカイブ要素の個別に圧縮されたアーカイブである。
【0153】
個別に圧縮され、その後一緒にアーカイブされた複数のアーカイブ要素を検査したとき、このような各アーカイブ要素が、典型的には、独自の辞書と、元のデータを再構築するためにこの辞書をどのように使用するかについての独自の命令とを有することに気付くことがある。
【0154】
しかし、通信ネットワークを介して送られることになる一緒にパッケージ化された複数の「ｊａｒ」タイプ・アーカイブなどの、関係のあるアーカイブ要素のセットを考える場合、複数の「ｊａｒ」タイプ・アーカイブにまたがる、全体としての元のデータの多くの部分が同一であることが示されることが可能である。元のアーカイブ構造１５２および目的アーカイブ構造１５４が圧縮アーカイブ要素からデコードされた場合、これらのアーカイブ構造に対して動作する差分モジュール１６０は、ここでは、目的要素または元の要素を備える既に圧縮されたデータではなく、あらゆる内部アーカイブ要素の元のデータに対して動作する機会を有しているはずである。
【0155】
したがって、より良い効率（例えば圧縮）を達成するための１つの鍵は、最終的には、パッチ・パッケージ１７０全体あたりただ１つの辞書である、より少ない辞書を準備するために、一緒にパッケージ化された２つ以上のこのような関係のあるアーカイブを変換させることによるものであり、したがって、前記より少ない辞書が、全てのアーカイブ要素を十分に表現する。
【0156】
内部アーカイブ要素のこの抽出は、いくつかの方式で有益であり、利益をもたらすものであり、これについて３つの主要な利点を強調する。
（１）第１の利益は、２つ以上の内部アーカイブ要素にわたって同一であるデータ部分を見つける機会を差分モジュール１６０に提供することであるが、内部アーカイブ要素のうちの１つの中で必ずしもしばしば行われるわけではない。非限定的例として、同じカメラ・モデルおよび同じ画像寸法（例えば、２０００×３０００ピクセル）で全てが撮られた何百もの写真のセットを考える。このデータは、内部アーカイブ要素毎に１度だけ繰り返してもよいが、このデータは、過剰な内部アーカイブ要素にわたって繰り返し、したがって、データ部分を繰り返す差分モジュール１６０のコンピューティングは、ここでは、データ部分を繰り返すものとしてこのデータを考える機会を有してもよい。同様に、同じ色の長いピクセル・ストリップが、いくつかのこのような画像の中に存在してもよいが、個別に圧縮されたとき、このような長いピクセル・ストリップは、例えば１度だけなど、非常に少ない回数、再発してもよい。
（２）第２の利益は、内部アーカイブ要素におけるデータ部分をマッピングする辞書の数（例えば、マップ、頻度テーブルなど）を低減させる機会を差分モジュール１６０に提供することである。典型的には、各内部アーカイブ要素は、別個に（例えば、別個の「．ｘｚ」または「．ｐｐｔｘ」ファイルとして）圧縮され、したがって、独自の辞書を含む。しかし、差分モジュール１６０によって一緒に計算されるとき、しばしば、２つ以上の内部アーカイブ要素によって共有されるただ１つの辞書にさえ、辞書の数を低減させる機会がある。
（３）第３の利益は、全ての内部アーカイブ要素にわたって繰り返す内部アーカイブ要素を識別することである。例えば、全てが、同じ組織の同じ部門に属し、したがって、ファイル毎に個別にエンコードおよび／または圧縮された、色定義、フォント定義、背景画像、ヘッダおよびフッタなどを備える会社ロゴおよび部門の「テーマ」などの同一の複数の画像を有する、「．ｐｐｔｘ」フォーマットのプレゼンテーション文書のセットを考える。内部アーカイブ要素の中にこのような繰り返す内部アーカイブ要素があるケースでは、少なくとも以下の２つの改善が導入可能である。
（３ａ）第１に、パッチ生成システム１１０は、繰り返す内部アーカイブ要素のうちの最初だけを維持することによって繰り返す内部アーカイブ要素を指示する一方で、前記繰り返す内部アーカイブ要素の最初への「リンク」として、パッチ命令の中で、残りの繰り返す内部アーカイブ要素を指示する機会を有する。繰り返す内部アーカイブ要素がまだ圧縮形式のとき、異なる圧縮アーカイブにわたって異なるように見えるはずの圧縮データを見ているだけなので、その存在は差分モジュール１６０には見えない。
（３ｂ）第２に、ステップ２３０～２５１への入力として供給することによって、繰り返すアーカイブ要素がプロセス２００によって抽出されるとすぐに、反復するアーカイブ要素は、このステップにおいて記載された第１の利益および第２の利益に寄与することがある。
（１）第１の利益は、２つ以上の内部アーカイブ要素にわたって同一であるデータ部分を見つける機会を差分モジュール１６０に提供することであるが、内部アーカイブ要素のうちの１つの中で必ずしもしばしば行われるわけではない。非限定的例として、同じカメラ・モデルおよび同じ画像寸法（例えば、２０００×３０００ピクセル）で全てが撮られた何百もの写真のセットを考える。このデータは、内部アーカイブ要素毎に１度だけ繰り返してもよいが、このデータは、過剰な内部アーカイブ要素にわたって繰り返し、したがって、データ部分を繰り返す差分モジュール１６０のコンピューティングは、ここでは、データ部分を繰り返すものとしてこのデータを考える機会を有してもよい。同様に、同じ色の長いピクセル・ストリップが、いくつかのこのような画像の中に存在してもよいが、個別に圧縮されたとき、このような長いピクセル・ストリップは、例えば１度だけなど、非常に少ない回数、再発してもよい。
（２）第２の利益は、内部アーカイブ要素におけるデータ部分をマッピングする辞書の数（例えば、マップ、頻度テーブルなど）を低減させる機会を差分モジュール１６０に提供することである。典型的には、各内部アーカイブ要素は、別個に（例えば、別個の「．ｘｚ」または「．ｐｐｔｘ」ファイルとして）圧縮され、したがって、独自の辞書を含む。しかし、差分モジュール１６０によって一緒に計算されるとき、しばしば、２つ以上の内部アーカイブ要素によって共有されるただ１つの辞書にさえ、辞書の数を低減させる機会がある。
（３）第３の利益は、全ての内部アーカイブ要素にわたって繰り返す内部アーカイブ要素を識別することである。例えば、全てが、同じ組織の同じ部門に属し、したがって、ファイル毎に個別にエンコードおよび／または圧縮された、色定義、フォント定義、背景画像、ヘッダおよびフッタなどを備える会社ロゴおよび部門の「テーマ」などの同一の複数の画像を有する、「．ｐｐｔｘ」フォーマットのプレゼンテーション文書のセットを考える。内部アーカイブ要素の中にこのような繰り返す内部アーカイブ要素があるケースでは、少なくとも以下の２つの改善が導入可能である。
（３ａ）第１に、パッチ生成システム１１０は、繰り返す内部アーカイブ要素のうちの最初だけを維持することによって繰り返す内部アーカイブ要素を指示する一方で、前記繰り返す内部アーカイブ要素の最初への「リンク」として、パッチ命令の中で、残りの繰り返す内部アーカイブ要素を指示する機会を有する。繰り返す内部アーカイブ要素がまだ圧縮形式のとき、異なる圧縮アーカイブにわたって異なるように見えるはずの圧縮データを見ているだけなので、その存在は差分モジュール１６０には見えない。
（３ｂ）第２に、ステップ２３０～２５１への入力として供給することによって、繰り返すアーカイブ要素がプロセス２００によって抽出されるとすぐに、反復するアーカイブ要素は、このステップにおいて記載された第１の利益および第２の利益に寄与することがある。
【0157】
ステップ２６０において、パッチ生成システム１１０は、パッチ命令１７４に従ってプロセス４００が目的要素を正しく再作成するために要求される全てのメタデータを追加する。その後、ステップ２６０は、前記パッチ命令１７４における、ステップ２５０～２５１において使用される解凍モジュール１４４およびアンパック・モジュール１４５の指示を記録する。
【0158】
ステップ２６１において、パッチ生成システム１１０は、元の要素および目的要素をそれぞれが備える、マッチング・ペアの新しいセットを構築し、ここで、各マッチング・ペアは、ステップ２５１においてアンパックまたは解凍された内部アーカイブ要素に対応する。
【0159】
マッチング・ペアのこの新しいセットは、典型的には、ステップ２５１においてアンパックおよび解凍された全ての内部アーカイブ要素をトラバースし、両方において同一の識別子を見つけることによって構築される。典型的には、元のアーカイブ構造１５２における内部アーカイブ要素毎に１つのループが反復し、これを、目的アーカイブ構造１５４における同一の識別子を有する１つの内部アーカイブ要素とマッチすることになる。同一の識別子がマッチしたときはいつでも、ステップ２６１によってマッチング・ペアが構築される。
【0160】
典型的には、目的アーカイブ構造１５４における少なくとも残りの（マッチしない）アーカイブ要素に対して第２のループが反復するはずであり、元のアーカイブ構造１５２において同一の識別子がマッチしたときはいつでも、ステップ２６１によってマッチング・ペアが構築される。
【0161】
マッチング・ペアの準備ができるとすぐに、前記マッチング・ペアが新しい入力として使用され、元のおよび目的アーカイブ要素としてのその観点から、新しいマッチング・ペアとしての前記新しい入力で、ステップ２１０から２７０までが実行される。好ましい実施形態では、これは、例えば再帰的に、ステップ２５０においてさらなるアンパックまたは解凍された内部アーカイブ要素が見つからなくなるまで、ステップ２６１によって繰り返される。
【0162】
いくつかの実施形態では、パッチ生成システム１１０は、例えば適用器ポリシ１３６におけるルールを使用して、いつマッチング・ペアを新しい入力としてステップ２１０から２７０に渡すか、およびいつそうすることを回避するかを決定してもよい。
【0163】
全ての（例えば、生成器ポリシ１３４によって）要求される内部アーカイブ要素がアンパックおよび解凍されるとすぐに、プロセス２００は、パッチ命令１７４によって指示されるように、要求される内部アーカイブ要素のそれぞれのためにステップ２１０～２６０を再び実行する。
【0164】
ステップ２７０において、パッチ命令１７４およびパッチ・データ１７２の準備ができ、上記で説明されたような任意の要求されるメタデータを含むその最終的な形式でパッチ・パッケージ１７０に記録されてもよい。
【0165】
いくつかの実施形態では、ステップ２７０は、任意の以前に遭遇したパッチ・データ１７２が、準備ができたパッチ・データ１７２と同一であるかどうかをチェックしてもよく、同一の場合、前記パッチ・データ１７２をパッチ・パッケージ１７０に記録する代わりに、パッチ命令１７４を、「リンク」構造タイプ、および前記以前に遭遇したパッチ・データ１７２を参照する指示に適合させ、したがって、同じパッチ・データ１７２を２回以上記録しないですむようにする。
【0166】
いくつかの実施形態では、十分なストレージ空間が利用可能であること、十分なメモリ空間が利用可能であること、ならびに中間のアーチファクトの除去が、その後のステップおよびプロセス（例えば、プロセス３００）に要求されないことを保証することを含む、より円滑な実行のために要求されるようなよく知られたハウスキーピング動作が行われてもよい。このようなハウスキーピング動作は当技術分野でよく知られており、とりわけ、ヒープ・メモリ・アロケーションの処分、ファイル・ハンドリングの解放など、ステップ２５１またはステップ２４１後の目的アーカイブ要素１３２の解放または削除などのプロセス関連のハウスキーピング動作、ステップ２５１またはステップ２４１後の元のアーカイブ要素１３０の解放または削除などを含む。
【0167】
さらなる実施形態では、例えば、元のアーカイブ構造１５２および目的アーカイブ構造１５４を回帰への入力として使用して、例えば再帰的に、プロセス２００を２回以上実施することは、元のアーカイブ要素１３０に、および／もしくは目的アーカイブ要素１３２に、ならびに／またはこれらのいずれかを備える任意の内部アーカイブ要素に含まれ、トラバーサルにおいて発見された、任意のアーカイブおよび圧縮アーカイブ要素が、それぞれ、順番にアンパックおよびデコードされ、したがって、その内部アーカイブ要素がこれらから抽出されることを保証してもよい。これは、本主題の多くの実施形態の重要な性質であり、パッチ・パッケージ１７０の効率をしばしば強化する。好ましい実施形態または最適な実行において、プロセス２００は、あらゆる単一のアーカイブおよび複合的なアーカイブ要素をデコードおよび抽出するが、例えば課された生成器ポリシ１３４によって、いくつかの制約がその動作に課されることがあり、したがって、アーカイブまたは複合的なアーカイブ要素のサブセットだけがデコードされるか、その内部アーカイブ要素をトラバースすることになる。
【0168】
典型的には、このような制約は、パッチ生成器ポリシ１３４にルールを含めることによって課されてもよい。このようなルールの例は、以下の種類の制約を含むがこれらに限定されない。
１．トラバースのレベルが、例えば、パッチ生成システム１１０によって採用されるＤＦＳまたはＢＦＳトラバース・アルゴリズムにおける、Ｎ個のレベルに制限される、制約ルール。
２．複合的なアーカイブ要素のデータ・フォーマットを、例えば、ｔａｒ．ｇｚ、ｂｚ２、ｊａｒおよびｘｚのデータ・フォーマットに限定する制約ルール。
３．アーカイブのデータ・フォーマットを、例えば、ｔａｒおよびａｒのデータ・フォーマットに限定する制約ルール。
４．トラバースを複合的なアーカイブ要素だけ、アーカイブだけ、またはその組合せに限定する制約ルール。
５．例えば、動作の前にトラバースするストレージの量を限定すること、トラバースされた複合的なまたはアーカイブ要素の数を限定することによって、プロセス３００がトラバースされたデータに対していつ動作するべきかを管理する制約ルール。
１．トラバースのレベルが、例えば、パッチ生成システム１１０によって採用されるＤＦＳまたはＢＦＳトラバース・アルゴリズムにおける、Ｎ個のレベルに制限される、制約ルール。
２．複合的なアーカイブ要素のデータ・フォーマットを、例えば、ｔａｒ．ｇｚ、ｂｚ２、ｊａｒおよびｘｚのデータ・フォーマットに限定する制約ルール。
３．アーカイブのデータ・フォーマットを、例えば、ｔａｒおよびａｒのデータ・フォーマットに限定する制約ルール。
４．トラバースを複合的なアーカイブ要素だけ、アーカイブだけ、またはその組合せに限定する制約ルール。
５．例えば、動作の前にトラバースするストレージの量を限定すること、トラバースされた複合的なまたはアーカイブ要素の数を限定することによって、プロセス３００がトラバースされたデータに対していつ動作するべきかを管理する制約ルール。
【0169】
パッチ生成システム１１０が動作するハードウェア、ファームウェア、ソフトウェア、ストレージ、オペレーティング・システムおよびファイルシステムの固有の構成に従って、さらなる制約ルールがパッチ生成器ポリシ１３４に記載されてもよい。
【0170】
アーカイブ要素のマッチング・ペア、典型的には、目的および元のアーカイブ構造１５２、１５４をトラバースし、本発明の実施形態による、効率的パッチ・パッケージ１７０を構築するためのプロセス３００のフローチャートを示した図３への参照がここから行われる。
【0171】
ハードウェア限定－プロセス３００の好ましい実施形態は、典型的には、元のアーカイブ要素１３０のサイズの何倍もある、および／または目的アーカイブ要素１３２のサイズの何倍もある、大量のＲＡＭおよび／またはストレージ媒体を要求する。要求される実際のボリュームは、とりわけ、選択されたデコード・モジュール１４６、元のアーカイブ１３０を作成するために使用される圧縮レベル、圧縮モジュール１４０によって使用される圧縮レベル、圧縮モジュール１４０を実行するために使用される他のパラメータなどを含む、数多くの因子の影響を受けることになる。
【0172】
プロセス３００の好ましい実施形態は、例えば、プロセス２００の最後の反復（回帰）において、またはその選択されたステップの直後に、１度だけ実行するものとして本明細書に記載されている。しかし、当業者は、例えば、ステップ２５２もしくはステップ２５３を完了させた後にプロセス３００を呼び出すことによって、または、例えば、目的アーカイブ構造１５４における異なるロケーションおよび／もしくは元のアーカイブ構造１５２における異なるロケーションに対してプロセス３００の動作をマルチタスク化することによって、または、２つ以上のハードウェア・プロセッサもしくは仮想プロセッサの中から、または、例えば、差し挟むパターンでプロセス２００およびプロセス３００におけるステップを実施することによって、ステップのデコードされた実行シーケンスを有する他の実施形態を容易に構築してもよく、その結果、生成された目的アーカイブ構造１５４の部分は、プロセス２００によってトラバースおよびデコードされ、次いで、以下に記載のようにプロセス３００によって再構築されるなどである。これらの他の実施形態は、１つの工程で好ましい実施形態を実行するために、および、目的アーカイブ構造１５４であっても元のアーカイブ構造１５２であっても処理されるＤＡＴの一部を準備するために２つ以上のプロセッサを利用するために、ステージング領域１５０のためのＲＡＭおよび／またはストレージ媒体のボリュームが限定的すぎる場合など、特に、リソースが制約された環境で動作する場合に、有益であることを証明することがある。
【0173】
プロセス３００は、任意選択で、好ましい実施形態において、下記で指定されるような、複数の工程、本質的にループまたは再帰を含む。各工程は、下記の教示に従って「ｓ」（以下では要するにＰＳ）で識別された配列を使用して構築されたターゲット要素のパッチ毎の、目的アーカイブ構造１５４のアーカイブ要素の（本明細書および以下で文字「ｓ」で指名された）異なる順序選択に関連付けられている。例えばｓ＝０で識別され得るプロセス３００の第１の工程において、目的アーカイブ要素１３２および元のアーカイブ要素１３０の元の配列のためのパッチ・パッケージ１７０が計算される。したがって、前記第１の工程から生じたパッチ・パッケージ１７０は、「Ｐ０」と呼ばれてもよい。
【0174】
目的アーカイブ構造１５４または元のアーカイブ構造１５２におけるプロセス３００によってトラバースされたアーカイブ要素は、必ずしも目的アーカイブ要素１３２とも元のアーカイブ要素１３２とも同一ではないので、プロセス３００において異なる表記法を使用して、元のアーカイブ要素１３０および目的アーカイブ要素１３２において元々現れる内部アーカイブ要素（「元のアーカイブ要素」）と、プロセス２００から生じた内部アーカイブ要素とを区別する。
【0175】
目標および利益－数学的領域は、本主題の実施形態を構築するために当業者によって要求される範囲を超えているが、目的アーカイブ構造１５４に対してプロセス３００を実施することによって得られる利益および／または効率に関するいくつかのポイントを簡潔に強調する。
【0176】
プロセス３００の目標のうちの１つは、２つ以上の元の要素または目的要素が圧縮形式であるときに、過剰な個別の辞書を有することに関連付けられ得るオーバヘッドを低減させることである。
【0177】
プロセス３００の別の目標は、パッチ・データ１７２にほとんど辞書がないにもかかわらず異なる結果を典型的に生じる、より大きい多様性または量のデータを圧縮モジュール１４１および／またはエンコード・モジュール１４３に入力することによってより良い圧縮結果に到達しようとすることである。
【0178】
プロセス３００のさらに別の目標は、平凡またはデフォルトのトラバース・アルゴリズムが圧縮モジュール１４１および／またはエンコード・モジュール１４３に入力するはずのものとは異なる順序で、アーカイブ要素を圧縮モジュール１４１および／またはエンコード・モジュール１４３に入力することによって、より良い圧縮結果に到達しようとすることである。
【0179】
プロセス３００のさらなる目標は、異なる圧縮モジュール１４１／エンコード・モジュール１４３によって、または、異なるパラメータ（例えば、圧縮レベル、辞書サイズ、例えばアルゴリズムＸＺおよび／もしくはＬＺＭＡにおける「マッチ・ファインダ」のタイプなど）で実行された同じエンコード・モジュール１４３によって、より効率的にエンコードされたパッチ・データ１７２で、あまり効率的でない元のエンコード済みのパッチ・データ１７２を置き換えることによって、改善された圧縮効率に到達しようとすることである。
【0180】
プロセス３００は、次いで、これが構築する異なる代替のパッチ１７０の効率（絶対であるかまたは相対であるか）を考慮することによって、最も効率的なパッチ・データ１７２（「ＭＥＰ」：ｔｈｅ ｍｏｓｔ－ｅｆｆｉｃｉｅｎｔ Ｐａｔｃｈ ｄａｔａ）を選択しようとする。
【0181】
プロセス３００の目標のいくつかに部分的に対処するステップ３１０～３４０を実行することから得られるいくつかの利益がある。
【0182】
（１）代替のパッチ・パッケージ１７０（ＰＳ）を構築することによって、例えばＰ０のための元の圧縮より効率的な圧縮が見つかることがある。
【0183】
（２）代替のパッチ・パッケージ１７０（ＰＳ）を構築することによって、例えば目的アーカイブ要素１３２における、以前に圧縮された、いくつかの元のアーカイブ要素が、ここで、例えば、単一の元の圧縮アーカイブ要素毎に要求されたデータ辞書が少ないなど、オーバヘッド・データが少ない状態で圧縮されてもよい。
【0184】
（３）内部アーカイブ要素の代替の配置を変換モジュール１４０に入力することによって代替のパッチ・パッケージ１７０（ＰＳ）を構築することはまた、以下の２つの主な利益を生じ得る。
（３．１）内部アーカイブ要素のデータをより効率的に記載する代替の辞書、および
（３．２）（例えば、異なる圧縮アーカイブの内部アーカイブ要素として）異なるアーカイブ要素において圧縮され、したがって、（辞書の差により、異なって表されることにより）差分モジュール１６０によって同一として発見されない、同一のアーカイブ要素が、ここでは可視であり、第１の発生へのリンクへの参照により、より良く圧縮されるか、または置き換えられることが可能である。例えば、同じアーカイブ要素の２０個の発生が発見されたと想定すると、第１のアーカイブ要素は、そのようなものとして圧縮および保存されることが可能であり、その一方で、残りの１９個の発生は、圧縮形式ではなく、むしろ、アーカイブ要素の圧縮形式を含む第１の発生へのリンクとして、書かれることになる。
（３．１）内部アーカイブ要素のデータをより効率的に記載する代替の辞書、および
（３．２）（例えば、異なる圧縮アーカイブの内部アーカイブ要素として）異なるアーカイブ要素において圧縮され、したがって、（辞書の差により、異なって表されることにより）差分モジュール１６０によって同一として発見されない、同一のアーカイブ要素が、ここでは可視であり、第１の発生へのリンクへの参照により、より良く圧縮されるか、または置き換えられることが可能である。例えば、同じアーカイブ要素の２０個の発生が発見されたと想定すると、第１のアーカイブ要素は、そのようなものとして圧縮および保存されることが可能であり、その一方で、残りの１９個の発生は、圧縮形式ではなく、むしろ、アーカイブ要素の圧縮形式を含む第１の発生へのリンクとして、書かれることになる。
【0185】
プロセス３００の上記で言及された目標は、実施される実施形態に含まれる実際のステップ、ＰＳを作成するために使用される変換モジュール１４０、内部アーカイブ要素のセットに対して変換モジュール１４０を実行するときに使用されるパラメータなどを含むがこれらに限定されない、数多くの因子に完全または部分的に依存して、求められてもよい。
【0186】
ステップ３０２において、パッチ・システム１１０には、元の要素および目的要素という２つのデータ・ストリームを備えるマッチング・ペアが入力される。
【0187】
プロセス３００を実行する前にプロセス２００が実行された場合、両方の入力データ・ストリームが、プロセス２００から生じた２つのアーカイブ構造１５２および１５４を処理するための出発点であり、そうでなければ、出発点は、元のおよび目的アーカイブ要素１３０、１３２自体として扱われる。
【0188】
プロセス２００と同様に、元の要素１３０における第１の入力ロケーションは、これとの比較のためまたはこれへの参照のために、アーカイブ要素を読み取るための元のアーカイブ構造１５２における初期位置である。目的要素における第２の入力ロケーションは、これとの比較のためまたはこれへの参照のために、アーカイブ要素を読み取るための目的アーカイブ構造１５４における初期位置である。
【0189】
プロセス２００と同様に、プロセス３００にはまた、ただ１つの入力ロケーションが入力されてもよい。このようなケースは、プロセス３００の説明の後、「単一アーカイブ入力」ケースとして以下に記載される。
【0190】
ステップ３１０において、パッチ・システム１１０は、内部アーカイブ要素の配列を選択するべきである。このステップは、結果として生じたパッチ・データ１７２の、例えば圧縮などのさらなる効率を達成するための鍵である。
【0191】
プロセス２００では、パッチ・システム１１０は、アンパックおよび解凍済みアーカイブ要素を含むアーカイブ構造を準備したことに留意されたい。
【0192】
配列についてのアイデアは、モジュールへの入力としてマッチング・ペアの異なる配列を実行することによって１つ１つが作成される、代替のパッチ・パッケージ１７０を作成するためのものである。各配列は、２つの選択に従って生成される－一方は、マッチング・ペアの「シーケンシング」であり、他方は、マッチング・ペアのシーケンシングの、サブグループへの「グルーピング」である。
【0193】
配列は、プロセス３００の目的が差分であるか圧縮であるかを記した、すなわち、差分モジュール１６０、圧縮モジュール１４１（例えば、以下に記載のように単一アーカイブ入力のケースの）、または両方を実行するための、ルールを含んでもよい。
【0194】
パッチ・システム１１０は、全ての以前の処理ステップによって構築されたアーカイブ要素を利用すること、および、下記で説明されるように、入力のその順序を入れ替えることによって、これを実施する。
【0195】
このシーケンスでアーカイブ要素の順序を入れ替えるために、出力としてこれをフィットさせるアーカイブ要素の結果セットを作成するためにクエリが使用されてもよい。その後のステップ（または可能であれば、クエリ内）は、１つまたは複数のグルーピング尺度に従ってアーカイブ要素のマッチング・ペアをグループ化することになる。
【0196】
アーカイブ要素をシーケンス化およびグループ化するための数多くの方式がある。パッチ・システム１１０は、ルールのセットにおいて定義可能な任意のシーケンシングおよびグルーピングを受け入れるように構築されることが可能である。いくつかの例は、以下を含む。
１．自然の順序－アーカイブ要素のマッチング・ペアは、例えば、元のアーカイブ構造１５２および目的アーカイブ構造１５４など、そのそれぞれのロケーションから読み取られると、差分モジュール１６０（または圧縮モジュール１４１）に追加される。これは、第１のＰＳ（Ｐ０）を構築するために典型的に使用される。
２．ソート順－アーカイブ要素のマッチング・ペアは、例えば生成器ポリシ１３４における尺度に従ってソートされる。尺度は、例えば、サイズによるもの、親ディレクトリ名によるもの、ファイル名によるもの、データ・タイプによるものなど、任意のアーカイブ要素のプロパティについてのものであることが可能である。例えば、最大ファイルの辞書を最初に構築するためのファイルサイズによるソート。
３．タイプ順－アーカイブ要素のマッチング・ペアは、その識別されたデータ・タイプに従ってグループ化される。例えば、全てのＢＭＰを最初に入力し、次いでＸＭＬを入力する。
４．Ｎオフ－マッチング・ペアは、昇順または降順形式にソートされた、例えば、データ・タイプ、ファイル名の第１の文字など、そのアーカイブ要素のプロパティに従ってグループ化され、次いで一番上からＮ個が選択される。例えば、５つのグループの中で、そのデータ・タイプに従って最大サイズから最小サイズまで全てのアーカイブ要素をマッチングすることは、例えば、２つのデータ・タイプ（ＢＭＰ、ＸＭＬ）のアーカイブ要素だけを含むアーカイブ構造のグルーピングを生ずることになり、これは、５つの最大ＢＭＰを最初に、その後５つの最大ＸＭＬ文書、その後再び次の最大５つのＢＭＰ、その後５つの次の最大ＸＭＬ、などを返す。
５．パッチ命令要素－パッチ命令１７４内の要素、および特に、要求されるメタデータは、グルーピングおよびシーケンシングにおいて重要な役割を演じることが可能である。
１．自然の順序－アーカイブ要素のマッチング・ペアは、例えば、元のアーカイブ構造１５２および目的アーカイブ構造１５４など、そのそれぞれのロケーションから読み取られると、差分モジュール１６０（または圧縮モジュール１４１）に追加される。これは、第１のＰＳ（Ｐ０）を構築するために典型的に使用される。
２．ソート順－アーカイブ要素のマッチング・ペアは、例えば生成器ポリシ１３４における尺度に従ってソートされる。尺度は、例えば、サイズによるもの、親ディレクトリ名によるもの、ファイル名によるもの、データ・タイプによるものなど、任意のアーカイブ要素のプロパティについてのものであることが可能である。例えば、最大ファイルの辞書を最初に構築するためのファイルサイズによるソート。
３．タイプ順－アーカイブ要素のマッチング・ペアは、その識別されたデータ・タイプに従ってグループ化される。例えば、全てのＢＭＰを最初に入力し、次いでＸＭＬを入力する。
４．Ｎオフ－マッチング・ペアは、昇順または降順形式にソートされた、例えば、データ・タイプ、ファイル名の第１の文字など、そのアーカイブ要素のプロパティに従ってグループ化され、次いで一番上からＮ個が選択される。例えば、５つのグループの中で、そのデータ・タイプに従って最大サイズから最小サイズまで全てのアーカイブ要素をマッチングすることは、例えば、２つのデータ・タイプ（ＢＭＰ、ＸＭＬ）のアーカイブ要素だけを含むアーカイブ構造のグルーピングを生ずることになり、これは、５つの最大ＢＭＰを最初に、その後５つの最大ＸＭＬ文書、その後再び次の最大５つのＢＭＰ、その後５つの次の最大ＸＭＬ、などを返す。
５．パッチ命令要素－パッチ命令１７４内の要素、および特に、要求されるメタデータは、グルーピングおよびシーケンシングにおいて重要な役割を演じることが可能である。
【0197】
ルールおよび設定の任意のセットに従って並べ替えが行われることが可能であり、単一のルールに限定されず、ルールは、任意のシーケンスで組み合わされてもよい。加えて、配列は、アーカイブ要素の同一のシーケンスが使用されるケースであっても、使用される実際の変換モジュール１４０および差分モジュール１６０を入れ替えてもよい。このようにして、異なる差分モジュール１６０のため、および／または異なる圧縮モジュールのための結果が、システムによって作成可能である。
【0198】
最初に実行されたとき、ステップ３１０は、第１の配列を単に選択する。例えばパッチ生成器ポリシ１３４においてパッチ・システム１１０のためにただ１つの配列が指定されるか、そのプロセスの中に「ハード・コードされる」場合、ステップ３１０は、この配列を選択する。そうでなければ、ステップ３１０は、パッチ生成器ポリシ１３４の支援により、どの配列が次に起こるべきかを決定する。
【0199】
さらなる反復において次が実行されたとき、ステップ３１０は、例えばパッチ生成器ポリシ１３４における、ルールのセットから起こる次の配列を計算することになる。
【0200】
ステップ３２０において、パッチ・システム１１０は、現在の配列における関連ルールに従って、全てのアーカイブ要素をアーカイブ要素の別個のシーケンスにグループ化する。アーカイブ要素のこれらのシーケンスは、ステップ３３０においてパッチ・パッケージ１７０を構築するために使用されることになる。
【0201】
アーカイブ要素は、例えば、パッチ生成器ポリシ１３４において定義されるような、異なるグルーピング・ルールを使用することによって、（例えば、異なるアーカイブ要素のプロパティに応じて）１つまたは複数の異なる軸を使用することによってグループ化されてもよい。
【0202】
例えば、ファイルタイプによるグルーピングは、ステップ３２２において、全てのＰＮＧファイルのための１つのアーカイブ、全てのＰＤＦのための別のアーカイブ、および残りのアーカイブ要素のためのさらなるアーカイブを備えることになる、アーカイブ要素のシーケンスを作成してもよい。
【0203】
別の例では、サイズ・ルールによる要素のグルーピングは、ステップ３２２において、サイズで限定されたアーカイブを作成してもよく、例えば、ステップ３２２は、アーカイブが、例えば２５６メガバイトなどの特定のサイズに達し、アーカイブによって超過されると、アーカイブを閉じることになる。
【0204】
さらに別の非限定的例では、名前ルールによるグルーピングは、例えば、「ａ」、「ｂ」、「１」など、その最初の文字に従って全てのファイル名をグループ化するアーカイブを作成してもよい。
【0205】
グルーピングは、元のアーカイブ要素１３０の内部アーカイブ要素、および目的アーカイブ要素１３２の内部アーカイブ要素の両方に、または利用可能な場合、元のアーカイブ構造１５２および目的アーカイブ構造１５４におけるアーカイブ要素に適用される。
【0206】
ステップ３２２において、パッチ・システム１１０は、少なくとも１つのアーカイブ・モジュール１４２を使用することによって、グループ毎に２つのグループ化されたアーカイブを構築し、２つのアーカイブのうちの第１のアーカイブが構築される。
【0207】
ステップ３２２は、選択された差分モジュール１６０に、２つ以上のアーカイブ要素を備える入力の能力があるかどうかを識別し、２つ以上のアーカイブ要素を入力する能力がないケースでは、ステップ３２２は、元のアーカイブ構造１５２における全てのアーカイブ要素が、１つのグループ化されたアーカイブにグループ化されることになり、目的アーカイブ構造１５４における全てのアーカイブ要素が、別のグループ化されたアーカイブにアーカイブされることになる、１つのグルーピング・ルール（したがって別のステップ３２２の反復）を追加する。
【0208】
次いで、ステップ３２０において構築されたグループに対応する元のアーカイブ構造１５２からのアーカイブ要素のために第１のアーカイブが作成される。ステップ３２０において構築されたグループに対応する元のアーカイブ構造１５２からのアーカイブ要素のために第２のアーカイブが作成される。
【0209】
各アーカイブは、典型的には、ステージング領域１５０における指名されたロケーションに格納され、例えばステップ３３０を実施した後、さらに要求されない場合、削除されてもよい。代替として、各アーカイブは、ＲＡＭに、仮想メモリに、ストレージ媒体のファイルシステムもしくはメモリ内のファイル・システムに、または、ステップ３３０によってアクセス可能な任意の別のロケーションに、格納されてもよい。
【0210】
ステップ３３０において、パッチ・システム１１０は、ステップ３２０および３２２によって適切にグループ化された後、選択された配列に対応するパッチ・パッケージＰＳ１７０を構築する。
【0211】
パッチ・パッケージ１７０を構築するために、パッチ・システム１１０は、グループ化されたアーカイブがステップ３２２において準備されたかどうかをチェックし、準備された場合、全てのグループ化されたアーカイブを選択する。
【0212】
次に、ステップ３３０は、元のアーカイブ構造１５２のグループ化されたアーカイブを差分モジュール１６０へのソース入力として、および目的アーカイブ構造１５４のグループ化されたアーカイブを差分モジュール１６０への目的入力として入力し、差分モジュール１６０を実行する。
【0213】
差分モジュール１６０は、ソース入力および目的入力のセット毎に１つのパッチ・データ１７２を生成するはずである。ソース入力および目的入力のただ１つのセットが存在するケースでは、差分モジュール１６０は、単一のパッチ・データ１７２を作成し、そうでなければ、複数のパッチ・データ１７２を作成する。後者では、パッチ・システム１１０は、各パッチ・データ１７２について１つのパッチ命令１７４を生成し、これをパッチ・パッケージ１７０に追加する。
【0214】
パッチ・システム１１０は、ここで、１つのパッチ・パッケージＰＳ１７０を構築し、ここで、「ｓ」は、この特定のパッチ・パッケージの一意の識別子である。
【0215】
下記で定義されるいくつかの「単一アーカイブ入力」の実施形態では、ステップ３３０への入力は、例えば目的入力だけなど、１つのアーカイブ入力だけを備えてもよい。このようなケースでは、ステップ３３０は、実装形態に応じて元の入力を「ｎｕｌｌ」、「ｎｉｌ」、または「空」として扱うか、元の入力を存在しないものとして扱ってもよい。ステップ３３０が元の入力を存在しないものとして扱う場合、ステップ３３０は、入力に対して差分モジュール１６０ではなく圧縮モジュール１４１を実行し、前記圧縮モジュール１４１の出力をパッチ・データ１７２に格納してもよく、任意選択で、対応するパッチ命令１７４の中でそのように指示する。
【0216】
ステップ３４０において、パッチ・システム１１０は、例えば生成器ポリシ１３４に従って、さらなる配列が要求されるかどうかをチェックし、要求される場合、そのタイプ（整数、ハッシュ鍵など）に従って、適用可能であるとして、「ｓ」をインクリメントし、ステップ３１０から３４０までを繰り返す。
【0217】
ステップ３５０において、パッチ・システムは、パッチ・パッケージＰ１．．Ｓのうちの最も効率的なパッチ・パッケージを識別し、その一意の識別子「Ｄ」を使用してこれを識別する。前記最も効率的なパッチ・パッケージ（「ＭＥＰ」またはＰＤ）が、ここでは維持される一方で、任意選択で、ＰＤを除いて他のパッチ・パッケージＰ１．．Ｓを放棄する。
【0218】
以前のステップによって要求および／または使用されたいずれかのステージング領域１５０のストレージ空間は、典型的には、メモリ、ＲＡＭ、もしくはストレージ媒体にあっても、またはステージング領域１５０によって使用される任意の他のロケーションにあっても、この時点で解放される。
【0219】
図２に示されたプロセス２００への参照がここで再び行われ、このケースでは、例えば目的アーカイブ要素１３２など、ただ１つのアーカイブ要素がプロセスに入力される。本開示の文脈では「単一アーカイブ入力」ケースと呼ばれる、上述のプロセス２００のこのような特別なケースでは、区別することになる元のアーカイブ要素１３０がないか、または元のアーカイブ要素１３０は、アーカイブ要素もデータも含まない。したがって、プロセス２００は、上述のような「追加」アクションを典型的に指示する、目的要素の全てのデータが実際には受け取り側にないことを暗示するために、プロセス２００および／または３００の実行中にどのマッチング・ペアにも元の要素がないことを想定することによって動作してもよい。
【0220】
「単一アーカイブ入力」のケースは、その全体に目的要素がないか、または内部アーカイブ要素がないケースとは異なる－プロセス２００は、このような、アーカイブ要素がない場合に対して「削除」アクションを指示することになる。
【0221】
元のアーカイブ要素１３０にデータが含まれないプロセス２００および／または３００を実行することによって用意されたパッチ・パッケージ１７０は、全ての上述の利益または目標から利益を得ることがある。
【0222】
このようなパッチ・パッケージ１７０は、多くのユース・ケースにおいて有益である。注目すべき例は、以下を含む。
（１）例えば圧縮モジュール１４１を使用して目的アーカイブ要素１３２における２つ以上の内部アーカイブ要素が以前に別々に圧縮されており、一緒にアーカイブされることになるケースでは、しばしば通常の圧縮アーカイブより良く圧縮される圧縮アーカイブを用意すること。
（２）オープン・ドキュメント（ＸＭＬベース）圧縮フォーマットのうちの１つの文書である関連アーカイブ要素のセットをアーカイブすること。これは、特に、米国特許第８，７６８，９６２号などの文書管理およびバージョン制御システムのコンテキストで有益である。
（３）例えばバックアップおよび後のリストアのために、過剰なアーカイブ要素のスナップショットを準備することであって、この場合、２つ以上のアーカイブ要素が、同一のデータ部分を含むか、上述のような同一の内部アーカイブ要素を含むか、または同一のアーカイブ要素を含む。これは、特に、バックアップおよびリストアのシステムおよび方法のコンテキストで有益である。
（１）例えば圧縮モジュール１４１を使用して目的アーカイブ要素１３２における２つ以上の内部アーカイブ要素が以前に別々に圧縮されており、一緒にアーカイブされることになるケースでは、しばしば通常の圧縮アーカイブより良く圧縮される圧縮アーカイブを用意すること。
（２）オープン・ドキュメント（ＸＭＬベース）圧縮フォーマットのうちの１つの文書である関連アーカイブ要素のセットをアーカイブすること。これは、特に、米国特許第８，７６８，９６２号などの文書管理およびバージョン制御システムのコンテキストで有益である。
（３）例えばバックアップおよび後のリストアのために、過剰なアーカイブ要素のスナップショットを準備することであって、この場合、２つ以上のアーカイブ要素が、同一のデータ部分を含むか、上述のような同一の内部アーカイブ要素を含むか、または同一のアーカイブ要素を含む。これは、特に、バックアップおよびリストアのシステムおよび方法のコンテキストで有益である。
【0223】
単一アーカイブ入力プロセス２００および３００の異なる実施形態が構築されてもよい。好ましい実施形態では、プロセス２００の全てのステップおよびプロセス３００の全てのステップが実施され、したがって、最大効率が求められてもよい。
【0224】
一般に、上述の単一アーカイブ入力のケースをハンドリングすることは、以下に記載のように、本開示を読む当業者には明らかになる小さな適合で、プロセス２００および／または３００のステップを実行することによって実施されてもよい。
【0225】
例えば、いくつかの単一アーカイブ入力の実施形態では、差分モジュール１６０には、例えばアーカイブ要素を含まない、空の元のアーカイブ構造１５２が入力されてもよく、その一方で、いくつかの他の単一アーカイブ入力の実施形態では、差分モジュール１６０には、差分モジュール１６０の仕様に従って、元のアーカイブ構造１５２がないことを指示するｎｕｌｌ参照またはｎｉｌポインタが入力されてもよい。
【0226】
さらなる単一アーカイブ入力の実施形態では、ステップ３３０において、差分モジュール１６０を実行することは、代わりに圧縮モジュール１４１の実行で、および、上述のような差分モジュール１６０を指示するのではなく前記圧縮モジュール１４１が使用されたことをパッチ・パッケージ１７０において指示することで、完全に置き換えられてもよい。
【0227】
加えて、元の要素がない場合、パッチ・パッケージ１７０の、パッチ・データ１７２の、およびパッチ命令１７４のデータ構造に対して、いくつかの最適化が行われてもよい。例えば、このような最適化は、とりわけ、前記データ構造内の特定のフィールドの除去を含んでもよい。
【0228】
前記パッチ・データ１７２およびパッチ命令１７４を使用して、結果として生じたパッチ・パッケージ１７０を適用または解凍し得る実施形態が、図４の説明の後、以下に記載されている。
【0229】
元のアーカイブ要素１３０、ならびにパッチ・データ１７２およびパッチ命令１７４を含むパッチ・パッケージ１７０から、目的アーカイブ要素１３２を再構築するための例示的プロセス４００を示す図４への参照がここで行われる。
【0230】
プロセス４００の目標は、プロセス２００によって実施される構造抽出を逆転させること、プロセス２００によってデコードされたアーカイブ要素をエンコードすること、および、適用可能な場合、元のアーカイブ要素１３０内またはアーカイブ要素１３０におけるアーカイブ要素に、プロセス３００によって構築されたＭＥＰを適用することである－最終的に、正しく構築された目的アーカイブ構造１５４を生じる。
【0231】
プロセス４００の実行における１つの主要な要素は、パッチ・システム１１０のコンピュータ上でプロセス２００、３００中に以前にアンパック、デコード、または解凍されたアーカイブ要素を正しくアーカイブ、エンコード、または圧縮することである。このようなアーカイブ要素のいくつかは、元々、「ディレクトリ」、「アーカイブ」、または「圧縮済み」構造タイプを有するコンテナ・アーカイブ要素の一部であったので、前記コンテナ・アーカイブ要素を再構築するために、前記このようなアーカイブ要素は、まず、例えば変換モジュール１４０によって、その元のフォーマットに変換されるべきである。いくつかの実施形態では、これは、逆転した順序でパッチ命令１７４をトラバースすることによって達成されてもよく、その一方で、他の実施形態では、これは、プロセス２００、３００が、そのパッチ適用順に従ったシーケンスでパッチ命令１７４を記録したケースで、パッチ命令１７４をトラバースすることによって達成されてもよい。
【0232】
ステップ４０１において、パッチ適用器１１２は、元のアーカイブ要素１３０、元のアーカイブ要素１３０を使用して目的アーカイブ要素１３２を再構築するためのパッチ命令１７４を備えるパッチ・パッケージ１７０であるＰ０、および、プロセス４００のステップによって処理されることになるパッチ・データ（別名「ペイロード」）１７２という、３つの入力を受け取る。いくつかの実施形態では、ステップ４０１は、まず、当技術分野で知られているように、２つの入力１３０、１７０が、例えば、正しいフォーマットであること、有効なデータを含むこと、悪意の内容の「注入された」データを含まないことなど、有効であることを確保してもよい。
【0233】
典型的には、最初に実行されたとき、元のアーカイブ要素１３０は、実行コンピューティング・デバイス（ＯＡ）上に存在する元のアーカイブ要素１３０を指名し、Ｐ０は、Ｐ０を使用して元のアーカイブ要素１３０から目的アーカイブ要素１３２を構築することに関する全てのパッチ命令１７４およびパッチ・データ１７２を備え、元のアーカイブ要素１３０およびＰ０の両方は、Ｐ０におけるパッチ命令１７４に従って、アップデート、追加、または削除されることになる内部アーカイブ要素を含む。
【0234】
いくつかの実施形態では、前記パッチ命令１７４は、例えば、両方のデータ要素をより効率的に伝送すること、１つのデータ構造におけるプロセス４００に要求される全ての入力をパッケージ化することなどのために、Ｐ０のデータと共に同じファイルまたはデータ構造でパッケージ化されてもよい。いくつかの実施形態では、前記パッチ命令１７４は、パッチ・パッケージＰ０内の内部アーカイブ要素（例えばファイル）内に格納される。
【0235】
いくつかの実施形態では、プロセス４００は、ステージング領域１５０内の、指名された領域、すなわち目的アーカイブ構造１５４における、元のアーカイブ要素１３０の、すなわちＯＡの、作業用コピーを用意する。いくつかの実施形態では、プロセス４００は、次いで、ステージング領域１５０における前記コピーに対してその処理ステップをまず実施し、実施されたときだけ、次いで、結果として生じた目的アーカイブ構造１５４を元のアーカイブ構造１５２に適用することになる。例えば、プロセス４００が、「Ｃ：￥Ｐｒｏｇｒａｍ Ｆｉｌｅｓ」下のサブディレクトリをアップデートするとき、プロセス４００は、ステージング領域１５０上に、抽出された元のアーカイブ構造１５２として、元のアーカイブ要素１３０の内部アーカイブ要素のコピーをしばしば作成し、ならびにステージング領域１５０上に結果の目的アーカイブ構造を備える空のコピーを作成してもよい。いくつかのさらなる実施形態では、プロセス４００は、ステージング領域１５０上に、例えば結果の目的アーカイブ構造１５４など、１つのコピーしか作成せず、プロセス４００のステップを前記結果の目的アーカイブ構造１５４に適用してもよい。さらなる実施形態では、プロセス４００のステップは、適所で実施され、したがって、元のアーカイブ要素１３０の内部アーカイブ要素のコピーは作成されず、プロセス４００のステップは、元のアーカイブ要素１３０のストレージ・ロケーションにおける内部アーカイブ要素に対して直接的に動作する。しばしば、前記さらなる実施形態は、データ全体が例えばＲＡＭなどのメモリに常駐しているときに好まれる。
【0236】
一般に、プロセス４００は、パッチ命令１７４に対して行われるステップの４つの主要なクラスタにセグメント化されることが可能であり、ステップ４０１～４２０は、メモリ・アロケーションおよび内部プロセス・テストを含む、パッチ適用器１２０のためのハウスキーピング活動を実施し、ステップ４３０～４４０は、例えばパッチ・データ１７２を適用可能なデータ・フォーマットで、ステージング領域１５０上に、アップデートされることになるアーカイブ要素の準備ができたことを保証し、ステップ４５０は、目的アーカイブ構造１５４におけるパッチ済みアーカイブ要素を構築するためにパッチ・データ１７２を適用し、最後にステップ４６０～４８０は、前記パッチ済みアーカイブ要素がその最終的なデータ・フォーマットであることを保証する。典型的には、プロセス４００は、さらなるパッチ命令１７４が存在しなくなるまで繰り返すが、プロセス４００は、例えば適用器ポリシ１３６においてセットされたルールに従って、繰り返すのを止めてもよい。
【0237】
ステップ４１０において、パッチ適用器１１２は、パッチ命令１７４全てを通じて反復し、全ての反復において、次のパッチ命令１７４をパッチ・パッケージ１７０から読み取る。ステップ４１０の第１の実行において、これは、典型的には、第１のパッチ命令であるはずである。
【0238】
好ましい実施形態では、そのトラバース・アルゴリズムが深度優先探索（ＤＦＳ）アルゴリズムに従うプロセス２００および３００によって作成されるようなパッチ命令の順序は、例えば、パッチ命令によって記載された圧縮アーカイブ要素など、１つのアーカイブ要素に関連した全ての命令は、１つずつ従い、したがって、オープン・アーカイブを追跡する負担を、例えばスタック・データ構造に簡素化することを示唆するはずである。しかし、例えば幅優先探索（ＢＦＳ）のケースなど、特定の実施形態では、オープン・アーカイブの、より洗練された追跡が必要になることがあり、したがって、任意選択のハウスキーピング・ステップ４２０は、このような状況が適切にハンドリングされることを保証することになる。
【0239】
典型的には、この時点で、パッチ適用器１１２は、ＯＡにおけるマッチング・アーカイブ要素をテストする。マッチング・アーカイブ要素は、前記アーカイブ要素識別子の識別子を、前記パッチ命令に格納された識別子と比較することによって、パッチ命令が適用されるもの、すなわちパッチである。いくつかのケースでは、マッチング・アーカイブ要素が、ＯＡの中で見つからず、したがって、ＯＡの中に空のマッチング・アーカイブ要素を作成することを要求する。他のいくつかのケースでは、ＯＡにおけるアーカイブ要素のためのマッチング・アーカイブ要素がパッチ命令の中で見つからず、例えば、ＯＡにおける前記アーカイブ要素への変更が行われなかったことを指示する。
【0240】
次のパッチ命令１７４がない場合、プロセスが全てのパッチ命令１７４を実行したこと、およびプロセスが、したがって、ステップ４９９を実行することによって終了することを理解されたい。
【0241】
任意選択的なステップ４２０では、パッチ適用器１１２は、いずれかのハウスキーピング活動が待ち状態であるかどうかをチェックする。待ち状態のハウスキーピング活動は、プロセス４００の以前の反復から残された任意のアーカイブ要素に進むことを含む。
【0242】
パッチ適用器１１２は、アーカイブ（「アーカイブ済みアーカイブ要素」）および／または解凍済みアーカイブ要素を備えるように、プロセス４００によって使用されるアーカイブ要素を閉鎖および／または削除し、前記アーカイブおよび／または解凍済みアーカイブ要素にはプロセス４００においてさらなる用途がなく、解放されてもよいことを指示するために要求される任意のハウスキーピング（例えば、メモリ解放、ＡＰＩコール）を実施してもよい。
【0243】
１つの非限定的例では、例えば「．ｔａｒ」フォーマット・アーカイブに既にアーカイブされたアーカイブ済みアーカイブ要素は、これらが、「リンク」構造タイプを有する任意のさらなるパッチ命令１７４によって参照されないケースでは、削除されてもよい。
【0244】
別の非限定的例では、例えば「．ｘｚ」フォーマットから解凍されたアーカイブ要素は、これらが、「リンク」構造タイプを有する任意のさらなるパッチ命令１７４によって参照されないケースでは、削除されてもよい。
【0245】
さらに別の非限定的例では、プロセス４００の実行中に用意された、および（パッチ・パッケージ１７０における）パッチ命令１７４において指定された任意のアーカイブ要素を構築することが要求されない、アーカイブ済みアーカイブ要素および解凍済みアーカイブ要素は、これらが、「リンク」構造タイプを有する任意のさらなるパッチ命令１７４によっても参照されないケースでは、削除されてもよい。
【0246】
さらなる非限定的例では、さらなるパッチ命令１７４をハンドリングすることをプロセス４００によってさらに要求されないステージング領域１５０用にアロケートされたストレージ空間は、例えばプロセス４００のストレージ要求を低減させるために、安全に解放されてもよい。
【0247】
１つのディレクトリ、１つのアーカイブ、または１つの圧縮アーカイブ要素に関連する全てのパッチ命令が、互いに従うためにグループ化されるように、パッチ命令１７４が配列された場合、好ましい実施形態のステップ４２０では、現在アンパックされていないアーカイブ要素を新しいパッチ命令が参照するかどうかを検査することによって、および、パッチ適用器１１２がアーカイブ・ロケーションへのトラバースを完了したかどうかを決定することによっても、実施可能である。
【0248】
パッチ命令の配列が異なる実施形態では、例えば、ハッシュ・マップ、アレイ、リンク・リスト、パッチ・パッケージ１７０内の指示、または、どのアーカイブがアンパックされているかを指示するためのメモリ・スタックを使用することによって、どのアーカイブ済みアーカイブ要素および／または解凍済みアーカイブ要素がまだ使用されているかを追跡するために、より複合的なトラバースおよびレコード・キーピングが要求されるはずである。
【0249】
ステップ４３０は、パッチ・データ１７２を適用するためにパッチ命令１７４で指示されたロケーションが利用可能であることを保証するために要求されるステップのシーケンスにおける１番目であり、例えば、パッチ適用器１１２は、例えばそのロケーションおよび識別子によって、パッチ命令１７４で指示されたアーカイブ要素が、構造変換を要求するかどうかをチェックする。
【0250】
ステップ４３０において、パッチ適用器１１２は、パッチ命令１７４におけるロケーションが、元のアーカイブにおける圧縮アーカイブ要素を指示するかどうかをチェックし、指示しない場合、ステップ４３２に進む。そうであることを決定するために、パッチ適用器１１２は、上記で説明されたような、パッチ命令１７４または内容識別モジュール１４８における指示を使用する。
【0251】
ステップ４３０は、次いで、少なくとも、パッチ命令１７４から、指示されたアーカイブ要素を解凍する。いくつかの実施形態では、例えば、圧縮モジュール１４１または解凍モジュール１４４の内蔵の限界により、前記ロケーションにおいて指示された圧縮アーカイブ要素を備える全ての内部アーカイブ要素を解凍することが必要である。
【0252】
ステップ４３０は、例えば、パッチ・データ１７２が前記アーカイブ要素に適用された後、（再）圧縮が要求されることをステップ４８０に指示するために、後で使用するために前記アーカイブ要素を解凍されたものとしてマークしてもよい。
【0253】
ステップ４３０は、例えば、パッチを当てられることになるアーカイブ要素が圧縮アーカイブ要素内に存在し、圧縮アーカイブ要素が、別の圧縮アーカイブ要素内に含まれるアーカイブ要素であるケースにおいて、前記ロケーションによって指示されたアーカイブ要素を抽出するために、必要に応じて何度も繰り返してもよい。したがって、ステップ４３０は、例えば、パッチ命令１７４で指示されたロケーションが完全に解凍されるまで、繰り返してもよい。
【0254】
ステップ４３０は、典型的には、目的アーカイブ構造１５４上の前記アーカイブ要素がアンパックされているかどうか、および（例えば、元のアーカイブ構造１５２における）元のアーカイブ上の前記アーカイブ要素がアンパックされているかどうかをチェックし、そうでない場合、前記アーカイブ要素がさらに処理される前に前記アーカイブ要素がアンパックを要求するかどうかをチェックする。
【0255】
アーカイブ要素がアンパックされたかどうかを決定するために、パッチ適用器１１２は、当技術分野で適用可能な場合、アーカイブ要素のタイプを決定するときのプロセス２００のような、またはパッチ命令１７４における指示に従うか、またはシステム・コール（例えばＡＰＩ）を介してそのロケーションにおける実際のアーカイブ要素をテストすることによって指示されるような、など、類似のシステムおよび方法を利用してもよい。
【0256】
ステップ４３２において、パッチ適用器１１２は、アーカイブ要素がアーカイブであるかどうかをチェックする。そうであることを決定するために、パッチ適用器１１２は、例えば内容識別モジュール１４８など、アーカイブ要素のタイプを決定するときのプロセス２００のような、またはパッチ命令１７４における指示に従う、類似のシステムおよび方法を利用する。
【0257】
アンパック済みアーカイブ要素がアーカイブである場合、ステップ４３２は、例えば、パッチ命令１７４において指示されたロケーションが完全にアンパックされるまで、パッチ命令１７４において指示されたアップデートされることになるアーカイブ要素がアップデートのために利用可能になるまで、繰り返されてもよい。
【0258】
ステップ４３２において、パッチ適用器１１２は、適切なアンパック・モジュール１４５を使用することによって、アーカイブであるアーカイブ要素から内部アーカイブ要素を指名されたロケーションにアンパックする。好ましい実施形態では、この抽出プロセスは、ステージング領域１５０における独自の指名されたロケーション（例えば、動作が内部メモリにおいて実施され、ファイルシステムにおいて実施されないケースでは、新たに作成されたフォルダまたはアロケートされたメモリ・ロケーション）に前記内部アーカイブ要素のそれぞれが置かれるように、ステージング領域１５０にある目的アーカイブ構造１５４に対して実施される。
【0259】
他の実施形態では、アンパックは、メモリにおいて直接的に行われてもよく、処理ステップは、次いで、メモリにおいて実施されてもよい。
【0260】
さらなる実施形態では、アンパックは、アンパックされた要素を適所に置くことによって、元のアーカイブ１３０に対して直接的に行われてもよい。これは、特に、パッチ命令１７４が、例えばエラーなく、完全に実施されることが予想されるとき、または例えば、適所に十分な空間があるとき、有益である。
【0261】
例えば、「．ｃａｂ」（Ｍｉｃｒｏｓｏｆｔ（商標）Ｃａｂｉｎｅｔ）ファイルとしてステップ４３１によって識別されたアーカイブ要素にステップ４３２が遭遇したケースでは、好ましい実施形態は、ステージング領域１５０に新しいロケーション（例えば一時ディレクトリ）を作成し、前記アーカイブ要素をその含まれる内部アーカイブ要素ＩＡＥＯ１．．ｎにアンパックしてもよく、ここで、「ｎ」は、例えばシーケンシャル番号など、ＩＡＥＯ毎の一意の識別子である。
【0262】
ステップ４３２において、パッチ適用器１１２は、後で再パックするためにステップ４３１の前記指名されたロケーションをマークしてもよい。これは、ステップ４３２によって抽出された内部アーカイブ要素ＩＡＥＯｎに対して実施されることになるアクションをパッチ命令１７４が指示する典型的なケースにおいて重要である。
【0263】
ステップ４３２の非限定的例を続けるために、好ましい実施形態は、例えば、スタック、リンク・リスト、またはアレイに前記指名されたロケーションを置くことによって、前記指名されたロケーションをマークする。
【0264】
ステップ４４０において、パッチ適用器１１２は、目的アーカイブ要素１３２のパッチ・データ１７２を適用する前に、目的アーカイブ要素１３２をデコードするというパッチ命令１７４における指示があるかどうかをチェックする。このような指示が存在しない場合、パッチ適用器１１２は、ステップ４４２を実行することに進む。
【0265】
ステップ４４０における指示は、パッチ命令１７４におけるアーカイブ要素をデコードするという指示を含むパッチ命令１７４における明示的なデータでもよい。前記指示はまた、アーカイブ要素のタイプを、元のアーカイブにおける対応するアーカイブ要素と比較することによって、暗示的に誘導されてもよい。指示はまた、ファイル拡張子がパッチ適用器１１２によって信頼されている場合、アーカイブ要素を表すファイル拡張子から誘導されてもよい。指示の別のタイプは、（例えば、Ｕｎｉｘユーティリティ「ファイル」におけるトリプル・テストを使用して）内容識別モジュール１４８を利用することによって暗示的に誘導されてもよい。
【0266】
次に、パッチ適用器１１２は、アーカイブ要素をデコードする能力があるデコード・モジュール１４６を選択する。適切なデコード・モジュール１４６を選択するために、パッチ適用器１１２は、前記指示を使用してもよい。
【0267】
デコード・モジュール１４６を選択した後、ステップ４３４は、デコード・モジュール１４６を動作させて、アーカイブ要素の内容をデコード済みデータにデコードする。デコードのプロセス中、デコード・モジュール１４６は、含まれるエンコード済みデータを記載する、アーカイブ要素内に含まれる固有のメタデータを読み取り利用する。例えば、デコード・モジュール１４６は、ＰＮＧ画像がピクセルで表現された特定のＸ軸およびＹ軸寸法ならびに特定の色深度を有すること、ならびに、透明性（アルファ・チャネル）が存在するかどうか、およびＰＮＧ画像を圧縮するためにどの圧縮レベルが使用されたか、を指定するメタデータを読み取ることができる。パッチ適用器１１２は、典型的には、このメタデータを、例えばステップ４８１においてアーカイブ要素を再構築するときなど、後で再使用し、したがって、ステップ４３４は、このような後の使用のために前記メタデータを維持してもよく、任意選択で、ハウスキーピング・ステップ４２０中にそのストレージ空間を解放する。
【0268】
デコードされたデータは、次いで、例えば、目的アーカイブ構造１５４における元のアーカイブ要素を置き換えることによって、または、ステージング領域１５０にデコードされたデータを置くことによって、または、メモリ内にデコードされたデータを格納することによって、適所に格納される。
【0269】
ステップ４３４は、パッチ命令１７４で指示されたロケーションが完全にデコードされるまで繰り返してもよい。
【0270】
ネストされたロケーションは、複数のネストされたレベルのものでもよく、それぞれのこのようなネストされたレベルは、圧縮済み、アーカイブ済み、またはエンコード済みの構造タイプであるので、ステップ４３０、４３２、および４３４は、パッチ命令１７４で指示されたロケーションが、特定のロケーションに従って、完全にアンパック、解凍、および／またはデコードされるまで、繰り返してもよい。
【0271】
ステップ４４０は、例えば、パッチ命令１７４に従うように、そのロケーションがアンパック、解凍、およびデコードされていることなど、パッチ命令１７４で指示されたアーカイブ要素がアップデートされる準備ができているかどうかをチェックする。チェックが失敗したケースでは、ステップ４３０から４３４までは、目的アーカイブ要素１３２がアップデートのために利用可能になり、そのように指示されたフォーマットにデコードされるまで繰り返される。次いで、実行は、ステップ４４２に続く。
【0272】
このステージでは、好ましい実施形態は、上記で定義されたように、アーカイブ要素がパッチを当てられる準備ができており、したがって、プロセス４００は、パッチ命令１７４に従って、そのパッチ・データ１７２を適用すること、パッチ・データ１７２をエンコードすること、パッチ・データ１７２をアーカイブすること、パッチ・データ１７２を圧縮すること、またはパッチ・データ１７２を削除することに進んでもよい。
【0273】
ステップ４４２において、パッチ適用器１１２は、パッチ命令１７４におけるアクション指示が「削除」動作を指名しているかどうかをチェックし、指名しているケースでは、ステップ４４４に進み、ここで、パッチ適用器１１２は、前に選ばれたロケーションに従って、ステージング領域１５０におけるそのロケーションにおける、または目的アーカイブ構造１５４におけるアーカイブ要素を削除する。ステップ４４４が実行されたケースでは、プロセスは、次に、次のパッチ命令を得るためにステップ４１０に進み、そうでなければ、ステップ４５０に進む。
【0274】
ステップ４５０において、パッチ適用器１１２は、パッチ命令１７４における指示に従って、パッチ適用器１１２に利用可能な、パッチ適用モジュール１８０を選択する。この指示は、例えば「ｂｓｄｉｆｆ」などの明示的な指示でもよく、または、例えば、ただ１つのパッチ適用モジュール１８０がパッチ適用システム１１２に関連付けられているケース、もしくは、例えば、Ｐ０におけるデータが１つのパッチ適用モジュール１８０にだけ正しく入力され得るケースでは、暗黙的な指示でもよい。
【0275】
選択されると、パッチ適用モジュール１８０は、パッチ・データ（ペイロード）１７２を使用して元の要素に対して実行される。パッチ・モジュール１８０の前記実行から結果として生じたデータは、次いで、目的要素に格納される。
【0276】
実施される実施形態に応じて、および／または適用器ポリシ１３６で指示されるように、前記目的要素は、次いで、目的アーカイブ構造１５４におけるパッチ命令１７４で指示されたロケーションに、ステージング領域１５０に、または元のアーカイブ要素１３０に直接的に格納される（適用される）。
【0277】
ステップ４６０において、パッチ適用器１１２は、ステップ４５０から結果として生じた目的要素のエンコードが実施されるべきかどうかをチェックする。
【0278】
好ましい実施形態が目的アーカイブ要素１３２をエンコードするいくつかのケースがある。
ａ）例えば、ＰＮＧ画像など、結果として生じた目的アーカイブ要素１３２に対する、要求されたデータ・フォーマットの指示によってパッチ命令１７４がそうすることを明示的に要求するケースで、
ｂ）ステップ４３４が元のアーカイブ要素１３０をデコードし、パッチ・ペイロードＰ０をこれに適用したときはいつでも、デフォルトで、
ｃ）例えば、アップデートされた、元のアーカイブ要素のファイル・フォーマットとは異なる目的ファイル・フォーマットの指示によって、パッチ命令１７４がそうすることを暗示的に要求するケースで。
ａ）例えば、ＰＮＧ画像など、結果として生じた目的アーカイブ要素１３２に対する、要求されたデータ・フォーマットの指示によってパッチ命令１７４がそうすることを明示的に要求するケースで、
ｂ）ステップ４３４が元のアーカイブ要素１３０をデコードし、パッチ・ペイロードＰ０をこれに適用したときはいつでも、デフォルトで、
ｃ）例えば、アップデートされた、元のアーカイブ要素のファイル・フォーマットとは異なる目的ファイル・フォーマットの指示によって、パッチ命令１７４がそうすることを暗示的に要求するケースで。
【0279】
いくつかの実施形態では、目的要素をエンコードすることはまた、ステップ４６１においてデコードが実施されなかったとしても、行われてもよい。さらなる実施形態では、目的要素をエンコードすることはまた、例えば、データを何も含まない選択されたエンコードの技術的説明だけを備えるアーカイブ要素を結果として生じるように、パッチ・ペイロード１７２にデータがなくても、行われてもよい。
【0280】
このようなケースは、特に、（例えばネットワークを介して）前記目的要素の内容を実際には何も格納することも送ることもなく、結果として生じたタイプの目的要素をパッチ適用器１１２が単にコンバートするために有益であり得る。これは、例えば、パッチ・ペイロード１７２においてデータを何もばらまくことなく、ソフトウェア公開者が、ファイル・フォーマットを、例えばＪＰＧからＰＮＧに置き換えるだけのケースにおいて、例示されている。例として、このようなケースでは、ＪＰＧフォーマットに１００個の画像を備える元のアーカイブ（ＯＡ）のディレクトリにおける全てのファイルのデータ構造全体を、ＰＮＧフォーマットにエンコードすることは、そのように指示する１００個のパッチ命令１７４を単に送ることによって容易に実施可能である。
【0281】
実施形態によって採用されるデータ構造に応じて、これは、ディレクトリまたはアーカイブに関するパッチ命令に対して直接的に、デコードする元のデータ・フォーマット、およびエンコードする、結果として生じたデータ・フォーマットを指示することによって、より簡潔に表現可能である。例えば、｛ｎａｍｅ＝“ａｒｃｈｉｖｅ．ｔａｒ”；ａｃｔｉｏｎ＝“ｕｐｄａｔｅ”；Ｄｔｙｐｅ＝“ＪＰＧ”；Ｅｔｙｐｅ＝“ＰＮＧ”｝。
【0282】
パッチ適用器１１２は、適切なエンコード・モジュール１４３をまず選択し、次いで、このエンコード・モジュール１４３を使用して目的要素の内容をエンコードすることによって、目的要素を、指示されたエンコード・タイプにエンコードする。
【0283】
これは、パッチ命令１７４においてキャプチャされたメタデータが使用される場合である。ステップ４８１によって実行されるエンコード・モジュール１４３は、典型的には、特に、例えばステップ４６０において、最初にデコードされた場合、目的要素をその元の形式にエンコードまたは再エンコードするためのいくつかのパラメータを要求するはずである。
【0284】
例えばステップ４６０において、最初にデコードされた場合、パッチ適用器１１２は、ステップ４３４によって識別されたメタデータを使用して、目的アーカイブ要素１３２を再エンコードする。他のケースでは、パッチ命令１７４は、どのようにこれを再作成するかを命令するメタデータを含んでもよく、次いで、パッチ適用器１１２は、このメタデータを使用して、アーカイブ要素をエンコードし、例えば元の形式に戻す。
【0285】
ステップ４６０の、結果として生じたエンコード済みアーカイブ要素は、追加されるか、または任意の以前に存在したアーカイブ要素を、目的アーカイブ構造１５４における同一の識別子（例えば、ロケーション）と置き換えるべきである。
【0286】
ステップ４７０において、パッチ適用器１１２は、以前のステップからの目的アーカイブ要素がアーカイブされるべきかどうかをチェックする。そのように決定するために、ステップ４７０は、ステップ４３２によってセットされたマークである、パッチ命令１７４における指示を使用してもよい。
【0287】
好ましい実施形態では、目的アーカイブ要素１３２の実際のアーカイブは、備える全ての目的アーカイブ要素１３２が、例えばステップ４３０～４５０によって、アップデートを完了するまで、延期されてもよい。
【0288】
目的要素をアーカイブするために、ステップ４７０は、アーカイブ・モジュール１４２を最初に決定する。そのように決定するために、ステップ４７０は、パッチ命令１７４における指示、適用器ポリシ１３６における指示もしくはルール、またはステップ４３２によって付けられたマークを使用してもよい。決定されたアーカイブ・モジュール１４２に応じて、目的アーカイブ要素１３２、または、アーカイブが上記の仕様に従って延期されたケースにおける全ての関連目的要素、および、パッチ命令１７４で指示されたアーカイブ要素が、アーカイブ・モジュール１４２に入力され、次いでアーカイブ・モジュール１４２が実行される。
【0289】
ステップ４７０の結果として生じたアーカイブは、追加されるか、任意の以前に存在したアーカイブを、目的アーカイブ構造１５４における同一の識別子（例えばロケーション）と置き換えるべきである。その後の反復において、ハウスキーピング・ステップ４２０は、ステップ４２０の仕様に従って、例えばメモリまたはファイルシステムから、全ての前記目的要素が解放されることを保証してもよい。
【0290】
ステップ４８０において、パッチ適用器１１２は、以前のステップからの目的アーカイブ要素が圧縮されるべきかどうかを決定する。そのように決定するために、ステップ４８０は、パッチ命令１７４における指示、またはステップ４３０によってセットされたマークを使用してもよい。
【0291】
目的要素を圧縮するために、ステップ４８０は、次に、圧縮モジュール１４１を選択する。そのように選択するために、ステップ４８０は、パッチ命令１７４における指示（例えば「ｘｚ」）、適用器ポリシ１３６における指示もしくはルール、またはステップ４３０によって付けられたマークを使用してもよい。
【0292】
好ましい実施形態では、目的要素の実際の圧縮は、同じ圧縮アーカイブ要素を備える全ての目的要素が、例えばステップ４３０～４５０によって、アップデートを完了するまで、延期されてもよい。いくつかのケースでは、しかし、選択された圧縮モジュール１４１は、２つ以上の要素を処理することができない。これらのケースでは、選択された圧縮モジュール１４１は、目的要素毎に別個に実行されるべきである。
【0293】
前記目的要素を圧縮するために、ステップ４８０は、次に、パッチ命令１７４に格納され得る任意の関連メタデータと共に前記目的要素を圧縮モジュール１４１に入力する。ステップ４８０は、次いで、圧縮モジュール１４１を実行し、典型的には、圧縮アーカイブ要素を結果として生じる。
【0294】
結果として生じた圧縮アーカイブ要素は、追加されるか、目的アーカイブ構造１５４における同一の識別子（例えばロケーション）を有する任意の以前に存在した圧縮アーカイブ要素を置き換えるべきである。その後の反復において、ハウスキーピング・ステップ４２０は、ステップ４２０の仕様に従って、例えばメモリまたはファイルシステムから、同じ圧縮アーカイブ要素を備える全ての前記目的アーカイブ要素１３２が解放されることを保証してもよい。
【0295】
最後のステップ４９０において、パッチ適用器１１２は、さらなるパッチ命令１７４が存在しないことを決定し、プロセス４００を終えてもよい。
【0296】
好ましい実施形態では、ステップ４９０は、最終的な目的アーカイブ要素１３４の一部であるはずのないデータ、メタデータ、または内容（例えば、ディレクトリ、ファイル、メモリ・オブジェクトなど）を目的アーカイブ構造１５４が含まないことを保証するべきである。ステップ４９０は、プロセス４００によって以前に使用された任意の残りのデータおよびストレージ空間をハウスキーピングするために（例えば、ステップ４３０に続かずに）ステップ４２０を呼び出すことによって、例えば、全てのパッチ命令１７４を、結果として生じた目的アーカイブ構造１５４と比較することによって、これを達成してもよい。いくつかの実施形態では、特に、元のアーカイブ要素１３０および目的アーカイブ要素１３２が、圧縮フォーマット、アーカイブ・フォーマット、または両方（例えば、「ｔａｒ．ｇｚ」圧縮アーカイブ）であるケースにおいて、最後のパッチ命令１７４のためのステップ４３０～４８０の最終的な実行が要求されることがある。
【0297】
最後に、ステップ４９０は、パッチ・パッケージ１７０において技術的に記載されたような目的アーカイブを、結果として生じた目的アーカイブ構造１５４が正しく表すことを保証する。典型的には、例えば目的アーカイブ要素１３２自体とは異なるステージング領域１５０上の、目的アーカイブのコピーをプロセス４００が使用しているとき、ステップ４９０は、目的アーカイブ構造１５４における全ての変更されたアーカイブ要素を目的アーカイブ１３２にコピーするはずであり、その一方で、目的アーカイブ構造１５４に存在しない目的アーカイブ１３２における任意のアーカイブ要素を削除する。
【0298】
いくつかの実施形態では、プロセス４００は、単一アーカイブ入力ケースに従って、プロセス２００および／または３００によって生成されたパッチ・パッケージ１７０を受け取ってもよい。一般に、上述の単一アーカイブ入力ケースのハンドリングは、以下に記載のように、小さな適合でプロセス４００のステップを実行することによって実施されてもよい。
【0299】
例えば、いくつかの単一アーカイブ入力実施形態では、パッチ適用モジュール１８０には、例えばアーカイブ要素を含まない、空の元のアーカイブ構造１５２が入力されてもよく、その一方で、他のいくつかの単一アーカイブ入力実施形態では、差分モジュール１６０には、パッチ適用モジュール１８０の仕様に従って、元のアーカイブ構造１５２を指示しないｎｕｌｌ参照またはｎｉｌポインタが入力されてもよい。
【0300】
さらなる単一アーカイブ入力実施形態では、ステップ４５０において、パッチ適用モジュール１８０の実行は、特に、上述のような差分モジュール１６０ではなく、圧縮モジュール１４１が使用されたことをパッチ・パッケージ１７０において指示された場合、代わりに解凍モジュール１４４の実行で完全に置き換えられてもよい。
【0301】
加えて、元のアーカイブ要素１３０がない場合、パッチ・パッケージ１７０に、パッチ・データ１７２に、およびパッチ命令１７４に、最適化されたデータ構造が存在してもよい。例えば、このような最適化は、とりわけ、例えば、存在していない元のアーカイブ要素に関連した、前記データ構造内の特定のフィールドの除去を含んでもよい。
【0302】
本発明は詳細に記載されてきたが、それでも、本発明の教示から逸脱しない変更および修正が当業者には明らかであろう。このような変更および修正は、本発明および添付の特許請求の範囲内に入るものと考えられる。
【0303】
本明細書に記載の様々な方法およびアルゴリズムは、例えば、適切にプログラムされた汎用コンピュータおよびコンピューティング・デバイスによって実施されてもよいことが容易に明らかであろう。典型的には、プロセッサ（例えば、１つまたは複数のマイクロプロセッサ）は、メモリまたは同様のデバイスから命令を受け取り、これらの命令を実行し、これにより、これらの命令によって定義された１つまたは複数のプロセスを実施する。さらに、このような方法およびアルゴリズムを実装するプログラムは、いくつかの様式の様々な媒体を使用して格納および伝送されてもよい。いくつかの実施形態では、様々な実施形態のプロセスの実施のためのソフトウェア命令の代わりにまたはソフトウェア命令と組み合わせて、配線で接続された回路機器またはカスタム・ハードウェアが使用されてもよい。したがって、実施形態は、ハードウェアおよびソフトウェアのどの特定の組合せにも限定されない。
【0304】
「プロセッサ」は、任意の１つまたは複数のマイクロプロセッサ、中央処理ユニット（ＣＰＵ）、コンピューティング・デバイス、マイクロコントローラ、デジタル・シグナル・プロセッサ、または同様のデバイスを意味する。
【0305】
用語「コンピュータ可読媒体」は、コンピュータ、プロセッサ、または同様のデバイスによって読み取られ得るデータ（例えば命令）の提供に関与する任意の媒体のことを言う。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに限定されない多くの形式をしていてもよい。不揮発性媒体は、例えば、光または磁気ディスク、および他の永続メモリを含む。揮発性媒体は、典型的にメイン・メモリの構成要素となるダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）を含む。伝送媒体は、プロセッサに連結されたシステム・バスを備えるワイヤを含む、同軸ケーブル、銅ワイヤ、および光ファイバを含む。伝送媒体は、無線周波数（ＲＦ）および赤外線（ＩＲ）データ通信中に生成されたものなどの、音響波、光波、および電磁放射線を含むか、または伝えてもよい。コンピュータ可読媒体の共通の形式は、例えば、フロッピー・ディスク、フレキシブル・ディスク、ハード・ディスク、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤ、任意の他の光媒体、パンチ・カード、紙テープ、穴のパターンを有する任意の他の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ－ＥＥＰＲＯＭ、任意の他のメモリ・チップもしくはカートリッジ、以下に記載のような搬送波、またはコンピュータが読み取り可能な任意の他の媒体を含む。
【0306】
様々な形式のコンピュータ可読媒体が、プロセッサへの命令のシーケンスの搬送に関与されてもよい。例えば、命令のシーケンスは、（ｉ）ＲＡＭからプロセッサに配送されてもよい、（ｉｉ）ワイヤレス伝送媒体を介して搬送されてもよい、および／または（ｉｉｉ）Ｂｌｕｅｔｏｏｔｈ、ＴＤＭＡ、ＣＤＭＡ、３Ｇなど、数多くのフォーマット、規格、もしくはプロトコルに従ってフォーマットされてもよい。
【0307】
データベースが記載される場合、（ｉ）記載されたものに対する代替のデータベース構造が容易に採用されてもよいこと、および（ｉｉ）データベースの他に他のメモリ構造が容易に採用されてもよいことが、当業者によって理解されよう。本明細書で提示される任意のサンプル・データベースの任意の例証または記述は、情報の格納された表現のための例証的な配置である。例えば、図面または他の場所で例示されたテーブルによって示唆されたものの他に、任意の数の他の配置が採用されてもよい。同様に、データベースの任意の例示のエントリは、例示的情報だけを表し、当業者は、エントリの数および内容が、本明細書に記載のものとは異なることが可能であることを理解するであろう。さらに、テーブルとしてのデータベースの任意の描写にもかかわらず、他のフォーマット（リレーショナル・データベース、オブジェクト・ベース・モデル、および／または分散型データベースを含む）が、本明細書に記載のデータ・タイプを格納および操作するために使用されてもよい。同じように、データベースのオブジェクト方法または行動が、本明細書に記載のような様々なプロセスを実施するために使用可能である。加えて、データベースは、既知の様式で、このようなデータベースのデータにアクセスするデバイスからローカルまたはリモートに格納されてもよい。
【0308】
本発明は、１つまたは複数のデバイスと通信ネットワークを介して通信中のコンピュータを含むネットワーク環境で動作するように構成可能である。コンピュータは、インターネット、ＬＡＮ、ＷＡＮもしくはイーサネット、トークン・リングなどの有線もしくはワイヤレス媒体を介して、または、任意の適切な通信手段もしくは通信手段の組合せを介して、デバイスと直接的または間接的に通信してもよい。デバイスのそれぞれは、コンピュータと通信するように適合された、Ｉｎｔｅｌ（登録商標）Ｘｅｏｎ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）、またはＣｅｎｔｒｉｎｏ（商標）プロセッサに基づくものなどの、コンピュータを備えてもよい。任意の数およびタイプの機械が、コンピュータと通信中でもよい。
【図1a】
【図1b】
【図2a】
【図2b】
【図3】
【図4】
【国際調査報告】