JP2015528165A - ファイル間差分コンテンツ同期 - Google Patents

Abstract

ファイルなどのコンテンツを、１つ又は複数のクライアントと１つ又は複数のサーバとの間で、同期させるための方法、システム、及び技法が提供される。例示的な実施形態は、ファイルのコンテンツ全体の移送を必要とすることなしに、ほぼ即時の方法で、リモート・システム間でファイルを同期させるために、ファイル間差分コンテンツ同期システム（ＣＤＣＳＳ）を提供する。これらの構成要素が協働して、受信者がすでにアクセスを有するコンテンツに基づいて、修正された、又は新しいデータ・コンテンツを構築するように、受信者に命令するパッチ機構を提供することによって、可能な限り、データ・コンテンツ中の差分のみを受信者システムへ移送する。加えて、一実施形態では、ＣＤＣＳＳ同期ソリューションは、パッチ及びファイルを追跡するために、サーバ・ベースのインデックスではなく、クライアント・ベースのインデックスを提供し、それによって、サーバ上の計算及びＩ／Ｏオーバーヘッドの量を低減し、更新を提供するためにクライアントとサーバとの間のネゴシエーションを必要としない。

Description

本開示は、ファイル同期のための方法、技法、及びシステムに関する。

典型的な企業環境では、ユーザは、様々なクライアント・デバイス及びクライアント・コンピューティング・システムを採用して、たとえば、パブリック又はプライベート・コンピューティング「クラウド」にリモートで記憶されているユーザのファイルを使用、共有、及び更新することができる。ここで、コンピューティング・クラウドとは、典型的にはインターネットなどのネットワーク上でサービスとして配信される、ソフトウェアを含むコンピューティング・リソースを指す。ファイルは、１つ又は複数のサーバ・コンピューティング・システム上で、たとえば、ネットワーク・ファイル・システム又は他のネットワーク・ストレージにリモートで記憶され、ネットワーク、たとえば、インターネットなどのワイド・エリア・ネットワーク（ＷＡＮ）、プライベートＷＡＮ、又はローカル・エリア・ネットワーク（ＬＡＮ）を介してアクセス可能である。クライアント・デバイスには、パーソナル・コンピュータ、タブレット、ラップトップ・コンピュータ、スマート・フォン、及び他のモバイル・デバイスなどのデバイスが含まれてもよく、それらのうちのいくつかは、リソース容量が限られている。

ファイルへのリモート・アクセスは、特にＷＡＮ上では、待ち時間の問題、及び最終的に効果的でなく苛立たしいユーザ・エクスペリエンスにつながり得る、帯域幅の問題（低速接続を介して移送されるデータが多すぎるなど）を受けることがある。これらの問題は、なおファイル全体が１つ又は複数のクライアント・デバイスと１つ又は複数のサーバ・コンピューティング・システムとの間で往復して移送される結果となる、ファイルに対する小さい増分的変更があるとき、特に苛立たしいものとなり得る。たとえば、典型的な企業ユーザは、１日に多数の修正を同じ表計算ファイル、プレゼンテーション、又は文書に対して行うことがあり、ユーザは、協力の目的でそれらの修正を別のユーザと共有することを望む。修正されたファイルは、したがって、１日に数回往復して移送され得る。

したがって、効率的なデータ移送を提供できることは、ユーザ・エクスペリエンスを左右することがあり、加えて、使用ベースのデータ・プランに加入する、モバイル・ユーザなどの限られたリソース・クライアント・プラットフォームのためのコスト節約につながり得る。

本願明細書で説明する実施形態は、ファイルなどのコンテンツを、１つ又は複数のクライアント（たとえば、クライアント・コンピューティング・システム）と、１つ又は複数のサーバ（たとえば、サーバ・コンピューティング・システム）との間で同期させるための、向上したコンピュータ・ベース及びネットワーク・ベースの方法、システム、及び技法を提供する。例示的な実施形態は、ファイルのコンテンツ全体の移送を必要とすることなしに、ほぼ即時の方法で、リモート・システム間でファイルを同期させるために、ファイル間差分コンテンツ同期システム（ＣＤＣＳＳ）を提供する。具体的には、ＣＤＣＳＳは、受信者がすでにアクセスを有するコンテンツに基づいて、修正された、又は新しいデータ・コンテンツを構築するように、受信者に命令するパッチ機構を提供することによって、可能な限り、データ・コンテンツ中の差分のみを受信者システムへ移送する。加えて、一実施形態では、ＣＤＣＳＳ同期ソリューションは、パッチ及びファイルを追跡するた
めに（他の実施形態において提供され得る、サーバ・ベースのインデックス、又は共有のクライアント及びサーバ・インデックスではなく）クライアント・ベースのインデックスを提供し、それによって、サーバ上の計算及びＩ／Ｏ（入出力）オーバーヘッドの量を低減し、更新を提供するためにクライアントとサーバとの間のネゴシエーションを必要としない。これは、サーバから作業をオフロードするために十分なコンピューティング能力を有する、デスクトップ・コンピュータ及びラップトップ・コンピュータなどの「シック」クライアントでは、特に効果がある。加えて、サーバによって移送され、リモート・クライアントにおいて最終的に記憶される、重複データの量を制限することによって、更新を携帯電話にダウンロードするときなど、更新がサーバからリモート・クライアントへ効率的に提供され得る。

ファイル間差分コンテンツ同期システムを展開するための例示的な環境のブロック図。 ファイル間差分コンテンツ同期システムを使用して、例示的なサーバと、及び互いに、ファイルを同期させる例示的なクライアントのブロック図。 クライアント上で修正されたファイルへの更新を同期させるために、ファイル間差分コンテンツ同期システムによって製作された、例示的な単一ファイル・パッチを示すブロック図。 別のクライアントによって生成されたファイルへの更新を同期させるために、ファイル間差分コンテンツ同期システムによって製作された、例示的なファイル間パッチを示すブロック図。 例示的なファイル間差分コンテンツ同期クライアント処理、及び例示的なファイル間差分コンテンツ同期サーバ処理の、構成要素を示すブロック図。 ファイル間差分コンテンツ同期システムにおいて使用するためのパッチを生成するための論理の例示的なフローチャート。 ファイル間差分コンテンツ同期システムにおいて使用するためのパッチを処理するための論理の例示的なフローチャート。 本願明細書で説明するファイル間差分コンテンツ同期システムの実施形態を実施するために使用され得る、例示的なコンピューティング・システムの例示的なブロック図。

例示的な実施形態では、ＣＤＣＳＳは、ファイル間差分コンテンツ同期（ＣＤＣＳ）クライアントと呼ばれるクライアント部分、及び、ファイル間差分コンテンツ同期（ＣＤＣＳ）サーバと呼ばれるサーバ部分からなり、それらの部分は、同期が望まれるとき、協働して、２つのコンピューティング・システム間で「パッチ」を移送する。パッチは、変更になった（又は、さもなければ、別のファイル中で位置を特定することができない）ファイル・コンテンツの部分のための新しいデータと、変更になっておらず、他の場所で位置が特定可能であるデータのロケーションへの参照とを含む、ファイル・コンテンツの表現である。パッチは、したがって、「差分同期」又は「差分ｓｙｎｃ」−すなわち、コンテンツが更新又は作成された前及び後の、コンテンツ中の差分のみの同期（又は「ｓｙｎｃ」）を提供する。本願明細書で使用されるとき、「ファイル」は、どのように記憶されるか（たとえば、ファイルの１部分、オブジェクト、記憶されたデータなど）にかかわらず、任意のタイプのファイル・コンテンツを指し、テキスト、ビデオ、画像、バイナリ、又は他のデータなどのコンテンツを含み得る。各パッチは、複数のセグメント（たとえば、レコード、部分など）を含み、各セグメントは、データ・コンテンツ（直接）、又は、データ・コンテンツの位置が特定され得る別のファイル・ロケーションへの参照（たとえば、インジケータ、ポインタ、記述など）を含む。

パッチは、１つ又は複数の他のファイルに記憶されるデータを参照することができるので、「ファイル間」パッチと見なされ得る。たとえば、ある会社のレターヘッド・テンプレートを使用して製作されるレターを考えられたい。会社のロゴは、あるファイルにおいて記憶され、位置が特定可能であり得るものであり、レターの受取人の住所は、連絡先ディレクトリにおいて記憶され、位置が特定可能であり得るものであり、レターのコンテンツはさらに、第３のファイルにおいて記憶され、位置が特定可能であり得る。ＣＤＣＳＳによって製作される例示的なパッチは、レターの実際のコンテンツと、（具体的なロケーション情報を含む）会社のロゴを含む第２のファイル中のエリアへの参照と、受取人情報を含む第３のファイルへの参照とを含み得る。第２のファイル及び第３のファイルが受信者コンピューティング・システム上にすでに存在するとき、第２のファイル及び第３のファイル内のロケーションへの参照を使用することによって、パッチ機構は、受信者コンピューティング・システム上にすでに存在する重複データを送信することを回避する。

ファイルが、たとえば、情報の「製作者」として働くクライアント・デバイス（たとえば、製作者クライアント・デバイス）によって、新たに作成又は修正されるとき、クライアント・デバイスは、パッチを計算し、パッチを宛先又は受信者サーバへ送信する。サーバは、すでに記憶されたデータとともにパッチを処理して、新しい又は修正されたファイルを作成する。後に、別のクライアント・デバイス（たとえば、データの「消費者」）が、新しい又は修正されたファイルで更新されるとき（たとえば、ファイルの同期、要求などが行われるとき）、ファイル全体を送信する代わりに、サーバは、製作者クライアント・デバイスによってすでに計算されたパッチのみを、消費者として働くクライアント・デバイス（たとえば、消費者クライアント・デバイス）へ送信することができる。消費者クライアント・デバイスは、すでに有するファイルを使用してパッチを処理することによって、かつ／又は、任意の欠落した情報をダウンロードすることによって、それ自体の新しい又は修正されたファイルを作成することを担う。したがって、新しい又は修正されたファイルは、（差分ｓｙｎｃ機構を使用して）パッチを計算すること、及び、パッチを（たとえば、クラウド中の）サーバにアップロードすることによって、他者と共有することができ、サーバは、ファイルを構成／再構成し、パッチをキャッシュし、（たとえば、ダウンロードすることによって）他のコンピューティング・システムへ伝搬され得るようにする。

いくつかの実施形態では、パッチは、（たとえば、設定された、プリセットされた、構成されたなどの）ある時間期間の間に、又は、あるアルゴリズム（たとえば、最長時間未使用、最低使用頻度、ＦＩＦＯなど）に従ってキャッシュされ、次いで、時間期間が満了するか、又はアルゴリズムがそのように指図するとき、キャッシュからフラッシュされる。パッチをキャッシュから削除すると、更新を受信する消費者クライアントは、パッチの代わりにファイル・コンテンツ全体を受信し得る。加えて、いくつかの実施形態では、たとえば、パッチがもはやキャッシュされていないか、又は利用可能でないとき、サーバは、必要に応じてパッチを再計算し得る。いずれの場合も、消費者クライアントが処理するためにパッチを受信するとき、消費者クライアントは、それが製作者クライアント・デバイスによって作成された元のパッチであったか、サーバによって作成された新しいパッチであったかを知る必要はない。いくつかの実施形態では、ストレージが、事実上、無制限である場合、パッチは、削除又は満了なしにキャッシュされ得る。

場合によっては、クライアント・デバイスは、他者（たとえば、発行者の立場で働くクライアント・デバイス）によって作成された情報を、この情報をサーバに効率的にアップロードし、パッチを通して広めることによって、さらに発行することができる。発行されるべき情報が、発行者クライアント・デバイス上にすでに存在する他の情報に依存する範囲で、パッチは計算可能であり、広められ得る。発行されるべき情報がそのように依存しない範囲では、発行されるべき情報全体がサーバへ送信される必要があり得る。

説明するように展開されるとき、ＣＤＣＳＳは、システム間で移送される重複データの量を低減することによって、移送される情報を最適化する。これは、データ移送が低速であるか、又はコストがかかり得る環境において特に有用であり、増分的に修正されたコンテンツの即時に近い（たとえば、リアルタイムに近い）同期を提供する。ＣＤＣＳＳ技法は、類似データが特定のコンピューティング・システム上に存在する高い確率を活用し、それに応じて、大規模なグローバル重複排除方式を管理するのではなく、分散ベース（各クライアント）のより小さいインデックスを管理する。加えて、ＣＤＣＳＳは、構成要素がファイル・システム及び他のシステム態様から分離しているので、重複排除を念頭に置くことなしに設計されたアーキテクチャに組み込むことができる。

図１は、ファイル間差分コンテンツ同期システムを展開するための例示的な環境のブロック図である。環境１００は、少なくとも１つのクライアント・コンピューティング・システム（クライアント）１０１と、少なくとも１つのサーバ・コンピューティング・システム（サーバ）１２０とを含む。クライアント１０１は、サーバ１２０と通信して、ファイルを同期させる。上述のように、そのような通信及び同期は、ＬＡＮ、ＷＡＮなどのネットワークであり得る通信機構１３０を介して、又は、ある通信ゲートウェイを介して行われ得る。サーバ１２０は、「クラウド」中のサーバであってもよく、クライアント１０１に知られていないあるホスト・コンピューティング・システム上のサービス型ソフトウェア（ＳＡＡＳ：ｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ）アプリケーションとして展開され得る。

クライアント１０１は、ＣＤＣＳクライアント１０２の使用を通して、パッチ１１０などの１つ又は複数のパッチを、通信機構１３０を介してサーバ１２０へ送信する。クライアント１０１が生成した（又は、ファイル・ストレージ１０３にファイルとして記憶した）、新しい又は修正されたファイルを同期させるために、クライアント１０１は、図３、図４、及び図６を参照して以下でさらに詳細に説明するように、修正の前及び後の、ファイル・コンテンツ中の差分を記述するパッチ１１０を計算する。サーバ１２０は、ＣＤＣＳサーバ１２１の使用を通して、パッチ１１０などの１つ又は複数のパッチを、通信機構１３０を介してクライアント１０１から受信する。図７に関してさらに説明するように、パッチ１１０は、セグメント（たとえば、レコード、部分など）において受信され、パイプラインで（たとえば、逐次的に、又は流れ処理を介して）処理され得る。各パッチが処理されて、ファイル・システム１２２に記憶されるファイル（又は、ファイル・バージョン）が生成される。加えて、パッチ１１０のコピーが、他のクライアント（図示せず）を同期させる／更新するためのさらなる配信のために、パッチ・キャッシュ１２３にキャッシュされる。加えて、サーバ１２０が（たとえば、別のパッチ１１０を送信して、クライアント１０１を更新するために）さらにパッチを配信して、クライアント同期させる／更新するとき、サーバ１２０は、パッチ１１０中で参照されるすべてのファイルのリスティングを含む、パッチ・マニフェスト１１５を計算及び送信する。このようにして、受信者コンピューティング・システムは、被参照ファイルが実際に存在することを最初に検証し、被参照ファイルが存在しない場合、ファイル全体を全部要求するか、又は、ただ参照を処理するのではなく、被参照ファイルからのデータ・コンテンツを要求するかのいずれかを選ぶことができる。

クライアント１０１は、クライアント１０１がそれについて知っており、サーバ１２０上に存在すると考える、ファイルの部分へのインデックスを含む、ローカル・チャンク・インデックス１０４に基づいて、パッチ１１０を計算する。一実施形態では、ＣＤＣＳＳの各ファイルが、線形にバイト１〜Ｎまでのデータ（データ・コンテンツ）の１つ又は複数のチャンクに分割される。可変サイズのデータの重複しないチャンクが、「コンテンツ定義チャンキング」（ＣＤＣ：ｃｏｎｔｅｎｔ−ｄｅｆｉｎｅｄ ｃｈｕｎｋｉｎｇ）と
呼ばれる技法を使用して、それらのコンテンツに基づいて決定される。「ラビン・フィンガープリンティング」などの異なるアルゴリズムが、ファイルをチャンクに分割するため、及び、ファイル・コンテンツを表現するために、ＣＤＣＳＳに組み込まれ得る。ファイルがチャンクに分割されると、チャンクごとに、ハッシュが計算され、ローカル・チャンク・インデックス１０４中でインデックス付けされる。各チャンクのためのハッシュは、そのチャンクについてのロケーション情報、たとえば、ファイル識別子及びオフセットに関連付けられるので、インデックス付けされたハッシュに基づいて、チャンクについてのロケーション情報が識別され得る。いくつかの実施形態では、ハッシュは、チャンクのコンテンツの強力暗号学的ハッシュ（たとえば、ＳＨＡ−２５６）であるが、他の実施形態では、他のハッシュ及び／又は他の識別子が組み込まれてもよい。

ファイル・コンテンツが修正又は作成されるとき、ＣＤＣＳＳは、（たとえば、ラビン・フィンガープリンティング・アルゴリズムを使用して）ファイルをチャンクに分割し、チャンク・インデックス１０４中のチャンクのハッシュをルック・アップすることによって、各チャンクがローカル・チャンク・インデックス１０４中にすでに存在するかどうかを判断する。ローカル・チャンク・インデックス１０４を表現するための任意のデータ構造が使用されてもよく、たとえば、リスト、ファイル、データベース、アレイ、テーブルなどが含まれる。チャンクがローカル・チャンク・インデックス１０４中にすでに存在する場合では、ＣＤＣＳＳは、ファイルのそのチャンクを表現する参照情報をパッチ１１０中に生成する。チャンクがすでに存在するのではない場合では、ＣＤＣＳＳは、そのチャンクについてのデータ・コンテンツ情報をパッチ１１０に記憶する。このようにして、ＣＤＣＳＳは、ファイルをチャンクごとに検査することによって、パッチ１１０を逐次的に構築する。結果として、パッチ１１０は、作成されるときに（又は、いくつかの実施形態では、パッチ全体が計算された後に）、分けて受信者へ転送（たとえば、送信、移送、通信など）されて、受信されるときに、逐次的に、たとえば、パイプラインにおいて処理され得る。注目すべきことに、パッチのフォーマットは、使用されるチャンキング・アルゴリズム、及び、パッチがどのように作成されるかとは無関係である。したがって、パッチは、どのようにパッチが作成されたかの詳細の知識なしに、受信されるときに処理され得るものであり−単に、パッチがコンテンツ及びコンテンツへの参照を含むこと、ならびに、パッチ自体をどのように処理するかである。

一実施形態では、「ラビン・フィンガープリンティング」アルゴリズムは、ファイルのチャンク境界を決定するために、及び、したがって、ファイルのためのチャンクを選択するために採用される。コンテンツをフィンガープリンティングする処理はまた、「チャンキング」とも呼ばれる。ラビン・フィンガープリンティングは、ラビン，マイケル オー（Ｒａｂｉｎ，Ｍｉｃｈａｅｌ Ｏ．），Ｆｉｎｇｅｒｐｒｉｎｔｉｎｇ ｂｙ Ｒａｎｄｏｍ Ｐｏｌｙｎｏｍｉａｌｓ，Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−１５−８１，コンピューティング技術研究センター（Ｃｅｎｔｅｒ ｆｏｒ Ｒｅｓｅａｒｃｈ ｉｎ Ｃｏｍｐｕｔｉｎｇ Ｔｅｃｈｎｏｌｏｇｙ），ハーバード大学（Ｈａｒｖａｒｄ
Ｕｎｉｖ．），１９８１に詳述されており、その全体を本願明細書に援用する。コンテンツ定義チャンキング（ＣＤＣ）のためのラビン・フィンガープリンティングの使用は、Ｍｕｔｈｉｔａｃｈａｒｏｅｎら（Ｍｕｔｈｉｔａｃｈａｒｏｅｎ ｅｔ ａｌ．），Ａ
Ｌｏｗ−Ｂａｎｄｗｉｄｔｈ Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ，Ｐｒｏｃ．１８ｔｈ Ｓｙｍｐ．Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｐｒｉｎｃｉｐｌｅｓ，Ｂａｎｆｆ，ＣＡ，Ｏｃｔｏｂｅｒ，２００１に記載されており、その全体を本願明細書に援用する。要約すれば、ラビン・フィンガープリントは、あらかじめ選択された既約多項式によって除算されたバイト列の多項式表現の除算からのリマインダとして定義される。フィンガープリントは、２つの異なるバイト列が異なるフィンガープリントを有することになる強い確率を提供する。ファイルのバイト（４０バイトと６４バイトとの間）のスライディング・ウィンドウのフィンガープリントは、ローリング・チェックサムとほぼ同様に
計算される。ウィンドウのフィンガープリントの最下位１３ビットが、あらかじめ選択された「マジック」値に等しいとき、ウィンドウの終了オフセットがチャンク境界であると見なされる。チャンクの最小サイズ及び最大サイズは、必要に応じて構成及び調整され得る。一実施形態では、それらは、それぞれ４ＫＢ及び１６ＫＢに設定される。ロビン・フィンガープリント・アルゴリズム及び同様のアルゴリズムに存在する計算のようなローリング・チェックサムは、信頼性と速度とのバランスを提供する。

注目すべきことに、他のアルゴリズムが例示的なＣＤＣＳＳに組み込まれてもよい。たとえば、適度な一様分布による任意のハッシング・アルゴリズムが、ファイル・データのフィンガープリンティング／チャンキングを行うために使用され得る。たとえば、ＳＨＡ−１又はＭＤ５などのセキュアなハッシュ・アルゴリズム・ファミリーからのハッシュが使用され得るが、それらは一般に、計算のためにより費用がかかる。

パッチが送信されると、パッチは、たとえば、受信者（サーバ又は消費者クライアント）によって、受信されるときに「オン・ザ・フライ」で処理され得る。図７に関してさらに説明するように、サーバ又は他の受信者は、パッチを線形に処理して、それ自体のチャンク・インデックスを必要としないことを含めて、いかなるチャンク・インデックスも必要とすることなしに、そのコンテンツからファイルを生成することができる。パッチ・フォーマットは、単体で、そのコンテンツからファイルを生成するためのレシピを記述する。新しい又は修正されたファイルは、パッチに埋め込まれるデータ・コンテンツを追加することによって、及び、パッチ中で参照される他のファイルからのデータ・コンテンツのチャンクをコピーすることによって、構築される。結果として、ＣＤＣＳ技法は、差分ｓｙｎｃのために、又は重複排除処理を使用するためにセット・アップされなかったコンピューティング・システムとともに使用され、又はそれに組み込まれ得る。具体的には、クライアントがＣＤＣＳクライアント（たとえば、ｓｙｎｃデーモン処理）を実行し、サーバがＣＤＣＳサーバ（たとえば、ｓｙｎｃプロセッサ）を実行する限り、クライアント及びサーバが通信して、さらなる修正なしに差分ｓｙｎｃを提供することができる。

パッチ・フォーマット、ならびに、チャンク・インデックスを生成及び転送するための技法のために、ＣＤＣＳＳは、コンテンツがサーバ上で利用可能であるかどうかを確かめるための、受信者サーバとのいかなるネゴシエーションもなしに、何がインデックス中に含まれているかについてのクライアント側の知識のみに基づいて、ファイル・コンテンツの差分ｓｙｎｃを行うことができる。具体的には、サーバがあらゆるファイルを不変に記憶する（たとえば、すべてのファイル、バージョンなどが、永久に記憶され、又はアクセス可能である）環境では、製作者クライアントは、（クライアントの通知によって確定され得る、チャンク・インデックス中のエラーがない限り）ファイルがそのチャンク・インデックスによって参照される場合、ファイルがサーバ上に存在すると仮定し得る。さらに、チャンク・インデックスの設計及び実装形態に応じて、クライアント上で削除された可能性のあるファイルが、依然として、ある時間期間の間に、又は無期限に、クライアントのチャンク・インデックスによって参照されることがある。これらのファイルは、サーバ上で不変である（たとえば、アーカイブされ得るが、実質的な意味においては決して削除されない）ので、ファイルがクライアント上にもはや存在しないとしても、依然としてサーバ上にあるファイルの存在を活用するパッチを作成して、ｓｙｎｃ動作においてクライアントによって転送されるデータの量を低減することができる。この態様は、「新しいファイルとして保存する＆元のファイルを削除する」シナリオにおいて、特に有用であり得る。

図２は、ファイル間差分コンテンツ同期システムを使用して、例示的なサーバと、及び互いに、ファイルを同期させる例示的なクライアントのブロック図である。例２００によれば、複数のクライアント・コンピューティング・システム２０１ａ、２０１ｂ、及び２
０１ｃが、サーバ・コンピューティング・システム２２０に通信可能に接続される。図示しないが、クライアント２０１ａ〜２０１ｃはまた、様々な他のサーバに接続されてもよく、様々な他のサーバのうちの複数にファイルを同期させてもよい。各クライアント２０１ａ〜２０１ｃは、それぞれ、それ自体のチャンク・インデックス２０２ａ、２０２ｂ、及び２０２ｃと、それぞれ、それ自体のｓｙｎｃデーモン（ＣＤＣＳクライアント）２０３ａ、２０３ｂ、及び２０３ｃとを有する。チャンク・インデックス２０２ａ〜２０２ｃ及びｓｙｎｃデーモン２０３ａ〜２０３ｃは、図１に関して説明したように動作する。ｓｙｎｃデーモン２０３ａ〜２０３ｃは、クライアントがその製作者の役割で働いている（ファイルを修正中又は作成中である）とき、パッチを生成し、サーバ２２０へ転送することを担い、クライアントがその消費者の役割で働いている（ファイルに対する更新又は新しいファイルを受信中である）とき、パッチを受信及び処理することを担う。

ファイルを記憶するためのサーバ・ファイル・システム２２３は、サーバ２２０に関連付けられ、各クライアント２０１ａ〜２０１ｃは、そのファイルが最新に保たれ、他のクライアントと共有され得るように、そのファイルをサーバ２２０と同期させることを担う。いくつかの実施形態では、ファイル・システム２２３が分散されるが、同期方法はなお、すべてのシステム上のファイルを最新に保つために採用され得る。サーバ２２０はまた、受信されたパッチを処理して、サーバに関連付けられたファイル・システム２２３に記憶される、ファイル２２４ａ〜２２４ｄなどのファイルを作成することを担う、ｓｙｎｃプロセッサ（ＣＤＣＳサーバ）２２１を実行する。

図示の例では、クライアント２０１ａは、ファイル「Ａ」２０４を含み、それを修正しており−ファイル「Ａ’」２０５として示す。図３において説明するように、ファイルＡ’２０５は、いくつかの修正とともにファイルＡ２０４に基づくコンテンツを有する。クライアント２０１Ａは、ｓｙｎｃデーモン２０３ａの使用を通して、サーバ２２０へアップロードするパッチ２１５を生成する。サーバ２２０は、そのｓｙｎｃプロセッサ２２１を通して、パッチ２１５を処理して、新しいファイル（又はバージョン）である、ファイルＡ’２２４ｂを生成し、それをファイル・システム２２３に記憶する。ｓｙｎｃプロセッサ２２１はまた、パッチ２１４のコピーを構築し、かつ／又はパッチ・キャッシュ２２２に記憶する。

例２００では、クライアント２０１ｂは、そのｓｙｎｃデーモン２０３ｂを使用して、ファイルＡ’を生成するために使用されるパッチのコピー（ここでは、パッチ・インスタンス２１６）をダウンロードする。パッチ２１６がｓｙｎｃデーモン２０３ｂによって処理されて、ファイルＡ’のそれ自体のコピー２０７が、ファイルＡのそれ自体のコピーへの参照（図示せず）に基づいて生成される。ここで、クライアント２０１ｂは、消費者クライアントとして働いている。別の例では、クライアント２０１ｂは、パッチ（図示せず）を送信して、同じく共有及び同期のために、サーバ２２０上でファイルＢ２０６を生成又は更新する。この場合は、クライアント２０１ｂは、製作者クライアントとして働いている。

また、例２００では、クライアント２０１ｃは、サーバ・ファイルＢ２２４ｃストレージからファイルＢのコピー２０９を、及び、サーバ・ファイルＢ２２４ｂストレージからファイルＡ’２１０を（全ファイル・コンテンツ・ダウンロードを通して、又は、１つもしくは複数のパッチを以前に受信及び処理することによって）以前にダウンロード／更新しており、パッチ２１７を受信して、新しいファイルであるファイルＣ２０８を生成する。ファイルＣ２０８のためのパッチは、図４を参照して説明するように、ファイルＢ２０９中で発見され得るあるコンテンツと、ファイルＡ’２１０中で発見され得るあるコンテンツとを含む。

図３は、クライアント上で修正されたファイルへの更新を同期させるために、ファイル間差分コンテンツ同期システムによって製作された、例示的な単一ファイル・パッチを示すブロック図である。例３００は、ファイルＡ２０４に対して行われた変更をアップロードして、たとえば、新しいバージョンであるファイルＡ’２２４ｂとしてサーバ２２０上に記憶されるようにするために、図２におけるクライアント２０１ａにおいてパッチがどのように生成されるかを示す。この例では、ファイルＡ’は、ファイルＡの修正されたバージョンを示す。チャンク３０１は、ファイルをデータ・コンテンツのセグメントに分割するチャンキング・アルゴリズムを適用した結果として生じる、ファイルＡのチャンクを表現する。ファイルＡは、５つの別々のチャンク、すなわち、Ａ_０からＡ_５に分割されるように示される。チャンク３０２によって表現されたファイルＡ’は、７つの異なるチャンクを含むように示され、そのうちの４つは、ファイルＡ中に含まれるものと同一であり、すなわち、チャンクＡ_０、Ａ_１、Ａ_３、及びＡ_４である。チャンク３０２のうちの３つは、新しいか又は修正されており、その理由は、それらがチャンクＡ’_０などのまったく新しいデータ（グレーの点描によって図示）を含むから、又は、それらが、ファイルＡからのチャンクＡ_２に対するいくつかの修正を含むチャンクＡ’_５など、修正されたファイルＡのチャンクからのデータを含むからである。具体的には、チャンクＡ_２は、ファイルＡ’において２つの新しいチャンク、すなわち、修正を含むチャンクＡ’_５と、ファイルＡからのデータを含むチャンクＡ’_６とに分離されている。

パッチ３０５は、クライアント２０１ａによって、差分ｓｙｎｃを行い、ここではファイルＡ’と命名される、ファイルＡに対する修正を作成するために生成される、例示的なパッチである。（実装形態に応じて、修正は、新しいファイル、新しいファイル・バージョン、又はファイルＡに対する修正であると考えられ得ることに留意されたい。）図３の目的では、ファイルＡ’は、ファイルＡのより最近のバージョンとして扱われる。ＣＤＣＳＳ技法による例示的なパッチ・フォーマットでは、パッチ３０５は、ヘッダと、その後に続くファイルＡ中のチャンクＡ_０への参照と、その後に続くチャンクＡ’_０のためのデータ・コンテンツと、その後に続くファイルＡ中のチャンクＡ_１への参照と、その後に続くチャンクＡ’_５のためのデータ・コンテンツと、その後に続くチャンクＡ’_６のためのデータ・コンテンツと、その後に続くファイルＡ中のチャンクＡ_３への参照と、その後に続くファイルＡ中のチャンクＡ_４への参照とからなる。

一般に、一実施形態によれば、パッチは、ヘッダの後に続く１つ又は複数のセグメント（たとえば、レコード、アイテムなど）からなり、ヘッダは、パッチ識別子、フォーマット・インジケータ、パッチを適用した結果として生じるべきであるファイルの長さのインジケータ、及び、結果として生じるファイルのメディア・タイプのインジケータなど、パッチについてのある情報を与える。パッチの各セグメントは、その中に含まれているデータ・コンテンツのそのサイズ及びタイプを識別するデータ・レコード、又は、データを含むファイルの一意のファイル識別子（たとえば、ファイルＩＤ又はＵＵＩＤ）と、バージョン識別子と、オフセット（たとえば、被参照ファイル中のデータのチャンクへのバイト・オフセット）と、チャンクのハッシュ（たとえば、ＳＨＡ−２５６ハッシュ）とを示す、タプルを含む、参照レコードのいずれかである。受信者は、ファイルＩＤ及びオフセットに基づいて、検索されたデータのハッシュを計算すること、ならびに、そのハッシュを記憶されたハッシュ値と比較することによって、ハッシュを使用して、検索されたデータを検証することができる。それらが同じではない場合、受信者は、パッチ中、又は記憶されたファイル中でエラーを検出することができる。この場合、受信者（たとえば、サーバ）は、パッチをアップロードしたクライアントに、そのパッチが不正確であると通知することができる。いくつかの実施形態では、参照レコードを含むパッチ・セグメントは、（ファイルＩＤ／ＵＵＩＤ及びバージョンを使用して）参照を定義する別のレコード、及び、参照内のチャンクのロケーション（オフセット、長さ、ハッシュ）を示す別のレコードを実際に記憶し得る。これにより、パッチ内に含まれた参照のリストを提供するマニフェ
ストの容易な作成が可能になる。

図３から顕著であるように、ファイルＡ’は、「単一ファイル」パッチ３０５の生成を引き起こす。すなわち、このパッチは、パッチ・フォーマットが複数のファイルをハンドリング可能であり−よって「ファイル間」パッチという用語であるにもかかわらず、２以上のファイルを参照する参照を有していない。１つのファイルのみが参照されるそのような場合、必ずではないが、パッチの表現に対する単純化が採用されてもよい。加えて、他のクライアントへパッチを送信することを伴うか、又はそれに先行するように後に作成されるマニフェストは、１つのファイルのみを参照するので、単純化されてもよい。

他のシナリオでは、ある他の最適化又は向上が、パッチ及び／又はパッチ・マニフェストに組み込まれてもよい。たとえば、パッチは、自己参照的であってもよく、すなわち、パッチの部分がパッチの他の部分を参照することができる、パッチが圧縮され得るか、もしくは圧縮されるデータ・コンテンツを含み得る、又は、パッチが、上記で識別されたフォーマット（データ・レコード及び参照レコード）に加えて、もしくはその代わりに、挿入／削除命令もしくは他のタイプの演算子を含み得る。他の最適化が組み込まれてもよい。たとえば、ファイルが、それらの特定のフォーマット（たとえば、フォーマット・アウェアなチャンキング）に基づいて、チャンクにセグメント化されてもよい。１例として、ｚｉｐファイルは、当然、サブ・ファイル境界に分割されてもよく、サブ・ファイル境界はさらに分割され得る。同様に、特定のフォーマットのチャンキングが、ＭＰ３などのフォーマットのために、オーディオ・データからメタデータを分離するために開発されてもよい。また、いくつかの実施形態では、増分／差分ｓｙｎｃの目的のためのパッチが、潜在的に構成可能な、あるサイズを上回るファイルのためにのみ生成されてもよい。

図４は、別のクライアントによって生成されたファイルへの更新を同期させるために、ファイル間差分コンテンツ同期システムによって製作された、例示的なファイル間パッチを示すブロック図である。例４００は、ファイルＢ及びファイルＡ’からファイルＣを生成するために使用され得るパッチをダウンロードするために、図２におけるクライアント２０１ｃにおいてパッチがどのように処理されるかを示す。この例では、ファイルＡ’は、ファイルＡの直近のバージョンを示す。チャンク４０１は、図３を参照して説明したファイルＡ’のチャンクを表現する。ファイルＡ’は、７つの別々のチャンクに分割されるように示される。チャンク４０２は、以前にクライアント２０１ｃにダウンロードされたファイルＢ（図２のファイルＢ２０９）のチャンクを表現する。チャンク４０５は、新しいデータ・コンテンツ・チャンクＣ_０，Ｃ_１から、ならびに、ファイルＡ’及びファイルＢ内のデータ（それぞれ、チャンクＡ_３，Ａ_４、ならびに、チャンクＢ_１，Ｂ_３）から形成された、ファイルＣ（図２のファイルＣ２０８）のデータ・チャンクを表現する。

ＣＤＣＳＳ技法による例示的なパッチ・フォーマットでは、パッチ４０６は、ヘッダと、その後に続くチャンクＣ_０のためのデータ・コンテンツと、その後に続くファイルＢ中のチャンクＢ_１への参照と、その後に続くファイルＡ’中のチャンクＡ_３への参照と、その後に続くファイルＡ’中のチャンクＡ_４への参照と、その後に続くチャンクＣ_１のためのデータ・コンテンツと、その後に続くファイルＢ中のチャンクＢ_３への参照とからなる。

図５は、例示的なファイル間差分コンテンツ同期クライアント処理、及び例示的なファイル間差分コンテンツ同期サーバ処理の、構成要素を示すブロック図である。一実施形態では、ファイル間差分コンテンツ同期システムは、最適化された方法でコンテンツ差分を同期させるためにともに働く、１つ又は複数の機能的な構成要素／モジュールからなる。これらの構成要素は、ソフトウェアもしくはハードウェア、又は両方の組合せで実装され得る。例示５００によれば、ファイル間差分コンテンツ同期システムは、ＣＤＣＳクライ
アント５０１及びＣＤＣＳサーバ５１０からなる。ＣＤＣＳクライアント５０１は、コンテンツ同期デーモン処理５０２、パッチ・インデックス５０６、チャンク・ロケーション情報５０７、及びパッチ生成作業空間からなる。ＣＤＣＳサーバ５１０は、コンテンツ同期プロセッサ５１１、パッチ・キャッシュ５１５、及びファイル生成作業空間５１６からなる。

図１を参照して説明したように、コンテンツ同期デーモン（処理）５０２は、クライアント上で実行し、新しいファイル及び修正されたファイルをサーバにアップロードするためにパッチを生成すること、ならびに、新しいファイル及び修正されたファイルをダウンロードするためにパッチを処理することを担う。一実施形態では、処理５０２は、クライアント・システム上の既知のフォルダを監視して、いつファイルが変更されたかを判断する。監視はまた、あるオペレーティング・システム・イベント・ハンドリングをサブスクライブすることによっても達成され得る。（サブスクライブされたシステム・イベントに従って）変更がファイルに対して行われるとき、ファイルが読み出され、インデックス付けされ、処理５０２は、変更を同期させるかどうか、及び、いつ同期させるかを判断する。代替実施形態では、処理５０２は、Ｉ／Ｏドライバ又は階層の一部として実行し得る。加えて、処理５０２は、フォルダ階層を走査して、いつファイルが変更されたかを判断し得る。これは、イベントをサブスクライブすること、もしくはドライバ階層の一部として実行することに関連して起こり得るものであり、又は、他の実施形態では、監視のための単独の機構を提供し得る。他の機構が、デーモン５０２がいつパッチを生成又は処理するかを判断するために、同様に組み込まれてもよい。

処理５０２は、さらに、マニフェスト・ハンドラ５０３、パッチ・ハンドラ５０４、及びファイル・アセンブラ５０５を備え、又はそれらに関連付けられる。マニフェスト・ハンドラは、たとえば、マニフェストがサーバから受信されるとき、マニフェストを処理して、今度の又は付随するパッチによって参照される、参照される（被参照）ファイルが、真に利用可能であることを確認する。それらが利用可能でないか、又はさもなければエラーである場合、クライアント５０１は、ファイルのための完全ファイル・コンテンツがダウンロードされることを要求するオプション、又は、いずれにせよパッチを受け入れ、欠落したパートを充填することによって破損している参照を「修復」するために（ロケーション及びバイト数によって指定もされる）特定のコンテンツを、たとえばサーバから要求するオプションを有する。そのような場合、サーバは、エラーをハンドリングし、記憶されたパッチ（たとえば、パッチ・キャッシュ５１５にキャッシュされたパッチ）を修復するように、プログラムされ得る。一実施形態では、受信者クライアントが、マニフェストを処理することによってパッチが適用され得ることを検証するまで、及びそうでない限り、パッチはダウンロードされない。

パッチ・ハンドラ５０４は、受信されたパッチを処理することを担う。（受信者サーバによるか、受信者クライアントによるかにかかわらず）パッチを処理することを、図７を参照してさらに説明する。パッチは、逐次パイプラインの方法で、１度に１セグメントずつ処理され得るものであり、結果のファイルは、ファイル・アセンブラ５０５によって構築され得る。

図１を参照して説明したように、パッチ・インデックス５０６（ローカル・チャンク・インデックス）は、クライアント上のすべてのファイルのコンテンツ・チャンクを、典型的には、暗号学的ハッシュを使用してインデックス付けする。これらのインデックス付けされたハッシュ値は、ファイルをチャンクにセグメント化することを助けるために使用される、いかなるハッシュ又は他のアルゴリズムとも無関係であり、別々のアルゴリズムを使用して導出され得る。各インデックス・キー（たとえば、ハッシュ値）は、コンテンツのチャンクについてのロケーション情報に帰着する。いくつかの実施形態では、ロケーシ
ョン情報は、別のリポジトリ５０７に記憶される。他の実施形態では、ロケーション情報は、直接、パッチ・インデックス５０６の一部として記憶される。パッチ・インデックス５０６は、パッチを転送してファイルを同期させるために、新しい又は修正されたファイル・データの製作者として働くクライアントのために、パッチを生成するために使用される。他の場所で説明したように、新しい又は修正されたデータに遭遇するとき、そのチャンクのハッシュが、パッチ・インデックス５０６中でインデックス・キーとしてルック・アップされ、ハッシュが存在する場合、既存のデータへの参照が生成中のパッチに入れられ、ハッシュが存在しない場合、データ・コンテンツ自体が生成中のパッチに記憶される。いくつかの実施形態では、パッチ生成作業空間５０８が、パッチの生成を援助するために、ＣＤＣＳクライアント５０１中に含まれる。

同様に、ＣＤＣＳサーバ５１０のコンテンツ同期プロセッサ５１１は、マニフェスト・ハンドラ５１２、パッチ・ハンドラ５１３、及びファイル・アセンブラ５１４を含む。マニフェスト・ハンドラ５１２は、受信されたパッチのためのマニフェストを（たとえば、パッチが別のクライアントに伝搬される前に）生成することを担う。パッチ・ハンドラ５１３は、ファイルをｓｙｎｃ中であるクライアントからパッチを受信し、パッチ・キャッシュ５１５に記憶された、キャッシュされたパッチを、受信者である他のクライアントへ転送（たとえば、送信、搬送、通信など）する。ファイル・アセンブラ５１４は、パッチが処理中であるとき、新しい又は修正されたファイルをアセンブルするために使用される。パッチから新しい（又は、新しいバージョンの）ファイルへデータを直接コピーすることによって、又は、記憶されたロケーション情報、サイズなどに従って、パッチによって参照されるファイルからデータを検索することによって、ファイルがファイル生成作業空間５１６中でアセンブルされる。

一実施形態では、ＣＤＣＳサーバ５１０のコンテンツ同期プロセッサ５１１は、ＲＥＳＴアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して実装され、したがって、サービス型ソフトウェア（ＳＡＡＳ）として、又は他のウェブで利用可能なリソースとして、利用可能である。プロセッサ５１１として働くウェブ・サーバは、ファイルの要求に対応し、可能な限り、パッチを返す。

ＣＤＣＳＳの技法は、一般に、任意のタイプのファイルに適用可能であるが、「ファイル」という言い回しは、一般に、そこから差分コンテンツが決定され得る任意のタイプのオブジェクトを暗示するために使用される。また、本願明細書で説明する例は、しばしば、サーバ・ファイル・システムに言及するが、本願明細書で説明する技法はまた、ローカルで、ネットワーク・ファイル・システムとともにリモートで、又は、重複排除を促進するための他のアーキテクチャにおいても使用され得る。たとえば、本願明細書で説明する技法は、任意のタイプのファイル・システムに記憶されたファイル、任意のタイプのデータ・ストアに記憶されたオブジェクト、又は、任意の線形バイト・ストリームのデータとともに使用され得る。加えて、説明する概念及び技法は、他のアーキテクチャ、パッチ・プロトコル、デバイスなどに適用可能である。本質的に、説明する概念及び技法は、任意のファイル又はオブジェクト同期に適用可能である。

また、いくつかの用語が本願明細書で主に使用されるが、他の用語が、均等な実施形態及び例を生じるために、互換的に使用され得る。加えて、用語は、明示的に記載されることもされないこともある代替スペリングを有することがあり、すべてのそのような用語の変形が含まれることが意図される。

本願明細書で説明する例示的な実施形態は、ファイルのコンテンツを同期させるために使用されるようにファイル間差分コンテンツ同期システムを実装するためのアプリケーション、ツール、データ構造、及び他のサポートを提供する。説明する技法の他の実施形態
は、一般に重複排除を含む他の目的のために使用され得る。以下の説明では、説明する技法の完全な理解を提供するために、データ・フォーマット及びコード・シーケンスなど、多数の具体的詳細を示す。説明する実施形態はまた、本願明細書で説明する具体的詳細のうちのいくつかなしに、又は、論理の順序に関する変更、異なる論理など、他の具体的詳細とともに実施され得る。したがって、説明する技法及び／又は機能の範囲は、任意の特定のルーチン、モジュール、構成要素などを参照して説明する態様の特定の順序、選択、又は分解によって限定されない。

図６は、ファイル間差分コンテンツ同期システムにおいて使用するためのパッチを生成するための論理の例示的なフローチャートである。図６の論理は、新しい又は修正されたファイルのためのパッチを生成するために、ＣＤＣＳクライアント、たとえば、図１のｓｙｎｃデーモン１０２によって使用され得る。ブロック６０１で、パッチ・データ構造が初期化され、パッチを識別するヘッダ情報が追加される。随意に、パッチ・フォーマットのバージョン、結果として生じるファイルの長さ、及び生成中のファイルのメディア・タイプなど、追加の情報もまた、ヘッダ中に含まれ得る。ブロック６０２〜６１１で、論理が、新しい又は修正されたファイルのデータ・コンテンツの各チャンクを処理するためのループを実行する。具体的には、ブロック６０２で、論理が、処理するべきチャンクがさらにあるかどうかを判断し、そうである場合、ブロック６０３で継続し、それ以外の場合、ブロック６１２で終了する。パッチ全体の処理の最後に、パッチが返され、たとえば、サーバへ転送される場合には、ブロック６１２で、パッチが返される。そうでない場合、論理は単に、パッチがすでに転送されたときに戻る。

ブロック６０３で、論理が、どのようなチャンキング・アルゴリズムが使用されるかに基づいて、ファイルのデータ・コンテンツの次のチャンクを取得する。以前に説明したように、一実施形態では、コンテンツ定義チャンキング（ＣＤＣ）を実装するラビン・フィンガープリンティング・アルゴリズムが、ファイルのデータ・コンテンツを、どのコンテンツが変更になったかを判断するために比較され得るセグメントに分解するために、使用される。他の実施形態では、たとえば、ＭＤ５又はＳＨＡ−１ハッシュを含む、他のアルゴリズムが使用され得る。選ばれたアルゴリズムを、クライアント側のみのキャッシュをサポートするシステムにおいて実装することができ、サーバは、パッチを処理するために、キャッシュのコピーを有する必要も、チャンキング・アルゴリズムを承知している必要もない。

ブロック６０４で、チャンク境界アルゴリズムに従って以前に決定されたチャンクをインデックス付けするために、別の表現値、たとえば、ＳＨＡ−２５６などの強力暗号学的ハッシュ値が計算される。ブロック６０５で、論理が、この値をパッチ・インデックスへの「キー」として使用して、その値（ハッシュ）によって表現されたデータ・コンテンツがすでにインデックス付けされているかどうかを判断する。そうである場合、論理が、ブロック６０６で継続して、生成中のパッチ中の参照において使用するために、データ・コンテンツについてのロケーション情報を取得し、そうでない場合、ブロック６０８で継続して、新しいインデックス付けされたレコードを編成し、生成中のパッチに直接、データ・コンテンツを記憶する。

具体的には、（ハッシュ）キーが、データ・コンテンツがパッチ・インデックス中にすでに存在することを示す場合、ブロック６０６で、論理が、インデックス付けされた（ハッシュ）値に関連付けられたロケーション情報からチャンク・ロケーション情報を取得する。次いで、ブロック６０７で、この検索されたロケーション情報が、生成中のパッチ中にパッチ参照データとして追加される。いくつかの実施形態では、生成中のパッチのためのマニフェストもまた、パッチが生成中である間に生成される。そのような場合、ブロック６０７とともに、論理が、パッチ中で新たに作成されたパッチ参照に対応する、マニフ
ェスト中のレコードを生成することができる。さらに、逐次的、又はストリームライン処理をサポートする実施形態では、生成中のパッチの新しいセグメントがサーバへ（直接又は間接的に）転送（たとえば、送信、通信など）される。論理が、次いで、ブロック６０２におけるループの先頭に戻る。

一方、（ハッシュ）キーが、データ・コンテンツがパッチ・インデックス中で発見されないことを示す場合、ブロック６０８で、新しい又は修正されたコンテンツ・チャンクのための（ハッシュ）キーがインデックス付けされ、ブロック６０９で、新しい又は修正されたコンテンツ・チャンクに関連付けられたロケーション情報が記憶される。たとえば、ファイルのためのＵＵＩＤ、チャンクが発見され得るファイル内の位置、及び、チャンクの長さが記憶され得る。ブロック６１０で、この記憶されたロケーション情報が、次いで、新たにインデックス付けされた（ハッシュ）キーに関連付けられる。一実施形態では、ブロック６０９，６１０が、ロケーション・データがパッチ・インデックスに直接記憶されるとき、同時に行われる。他の実施形態では、ロケーション情報は、個別に、たとえば、パッチ・インデックスから相互参照される別のデータ・リポジトリに記憶され得る。

ブロック６１１で、新しい又は修正されたコンテンツが、生成中のパッチのセグメントにパッチ・データとして記憶される。次いで、逐次的、又はストリームライン処理をサポートする実施形態では、生成中のパッチの新しいセグメントがサーバへ（直接又は間接的に）転送される。論理が、次いで、ブロック６０２におけるループの先頭に戻る。

図７は、ファイル間差分コンテンツ同期システムにおいて使用するためのパッチを処理するための論理の例示的なフローチャートである。図７の論理は、新しい又は修正されたファイルのための受信されたパッチを処理するために、ＣＤＣＳクライアント、たとえば、図１のｓｙｎｃデーモン１０２、又はＣＤＣＳサーバ、たとえば、ｓｙｎｃプロセッサ１２１によって使用され得る。わずかな違いが、サーバによる処理、又は消費者クライアントによる処理に適用され得るが、本願明細書で説明する基本的な論理は、両方に適用可能である。

ブロック７０１で、マニフェストが利用可能であると仮定して、マニフェストが受信される。ブロック７０２で、論理が、マニフェスト・レコード中に含まれたファイルのリストを検討して、その中で参照されるファイルのすべてへのアクセスを有すると判断する。そうである場合、又は、論理が、いずれにせよパッチを処理すると判断する場合、論理がブロック７０４で継続し、そうでない場合、ブロック７０３で継続する。ブロック７０３で、論理が、ファイル・コンテンツ全体がアップロード／ダウンロードされる必要があると判断及び要求し、次いで、論理が７１４で終了する。

ブロック７０４で、論理が、パッチの少なくとも１部分を受信し、作成されるべきファイルの最初の部分を生成し、パッチ・ヘッダを処理する。
ブロック７０５乃至７１３は、パッチの各セグメントを処理するためのループを実施する。具体的には、ブロック７０５で、論理が、パッチ中に処理するべきセグメントがさらにあるかどうかを判断する。そうでない場合、論理がブロック７０６で継続し、さもなければブロック７０７で継続する。

ブロック７０６で、論理が、作成中のファイルを終了し、又はさもなければ閉じ、（論理がサーバによって実行される場合には）キャッシュ中のパッチを閉じ、又はさもなければ終了する。いくつかのサーバ実施形態では、（将来の消費者のために）パッチを処理中に、マニフェストが作成され、そうである場合、マニフェストが閉じられる。論理が、次いでブロック７１４へ進み、処理を終了する。

ブロック７０７で、論理が、次のパッチ・セグメントがデータ・セグメントである（データ・コンテンツを含む）かどうかを判断し、そうである場合、ブロック７０８で継続し、そうでない場合、ブロック７０９で継続する。ブロック７０８で、論理が、データ・コンテンツをパッチから読み出し、ここまで生成されたファイル部分の最後にデータ・コンテンツを追加し、ブロック７１３で継続する。

ブロック７０９で、論理が、次のパッチ・セグメントが参照（又はエラー）であるかどうかを判断（そうであると推定）し、ブロック７１０へ進む。ブロック７１０で、論理が、参照されるファイル中のデータの位置が特定されたかどうかを判断する。そうである場合、論理がブロック７１２で継続し、そうでない場合、ブロック７１１で継続して、エラーをハンドリングする。エラーをハンドリングすることは、たとえば、ファイルの特定の部分のためのデータを要求すること、パッチ処理をアボートすること、又は、ファイル全体を要求することさえも含み得る。次いで、論理がブロック７１２で継続する。

いくつかの実施形態では、ブロック７１０で、論理が、被参照データを検索し、検索されたデータのためのそれ自体のハッシュ値を計算し、次いで、計算されたハッシュを、データへの参照を提供したパッチ・レコードとともに記憶されたハッシュ値と比較する。このようにして、論理は、発見されたデータが、パッチによって指定されたデータに一致することを、検証することができる。そうでない場合、ブロック７１１に従って、エラーがハンドリングされる。

ブロック７１２で、論理が、引き続き、ここまで生成されたファイル部分の最後に、位置が特定された／検索されたデータを連結（追加）し、ブロック７１３で継続する。
ブロック７１３で、論理が、キャッシュ中のパッチに、処理されたパッチ・セグメントを連結（追加）し、ブロック７０５におけるパッチ・セグメント処理ループの先頭に戻る。（たとえば、将来の消費者のために）パッチを処理中に、マニフェストが作成される実施形態では、次いで、レコードが、ブロック７０９で検査されたパッチ・セグメントに含まれた参照に対応するように、マニフェストに追加される。論理が、次いで、ブロック７０５で次のパッチ・セグメントを処理するために、ループの先頭に戻る。

図８は、本願明細書で説明するファイル間差分コンテンツ同期システムの実施形態を実施するために使用され得る、例示的なコンピューティング・システムの例示的なブロック図である。適切に命令された１つもしくは複数の仮想もしく物理的な汎用コンピューティング・システム、又は専用コンピューティング・システムが、ＣＤＣＳＳを実装するために使用され得ることに留意されたい。さらに、ＣＤＣＳＳは、本願明細書で説明する能力を達成するために、ソフトウェア、ハードウェア、ファームウェア、又はある組合せで実装され得る。

コンピューティング・システム８００は、１つ又は複数のサーバ・コンピューティング・システム及び／又はクライアント・コンピューティング・システムからなり得るものであり、分散ロケーションに広がり得る。加えて、図示の各ブロックは、特定の実施形態に適するような１つ又は複数のブロックを表現することができ、又は、他のブロックと組み合わせられてもよい。また、ＣＤＣＳＳ８１０の様々なブロックは、規格（たとえば、ＴＣＰ／ＩＰ）又はプロプライエタリな処理間通信機構を使用して互いに通信する、１つ又は複数のマシン上に物理的に存在し得る。

図示の実施形態では、クライアントとして、又はサーバとして使用するための、コンピュータ・システム８００は、コンピュータ・メモリ（「メモリ」）８０１、ディスプレイ８０２、１つ又は複数の中央処理装置（「ＣＰＵ」）８０３、入出力デバイス８０４（たとえば、キーボード、マウス、ＣＲＴ又はＬＣＤディスプレイなど）、他のコンピュータ
可読媒体８０５、及び、１つ又は複数のネットワーク接続８０６からなる。ＣＤＣＳＳ（クライアント又はサーバ）８１０は、メモリ８０１中に存在するように示される。他の実施形態では、コンテンツのある部分、ＣＤＣＳＳ８１０の構成要素のうちの一部、又は全部が、他のコンピュータ可読媒体８０５上に記憶され、かつ／又はそれを介して送信され得る。ＣＤＣＳＳ８１０の構成要素は、好適には、１つ又は複数のＣＰＵ８０３上で実行し、本願明細書で説明するように、パッチの生成及び処理を管理する。他のコード又はプログラム８３０、及び、潜在的にデータ・リポジトリ８０６などの他のデータ・リポジトリもまた、メモリ８０１中に存在し、好適には、１つ又は複数のＣＰＵ８０３上で実行する。注目すべきことに、図８の構成要素のうちの１つ又は複数は、任意の特定の実装形態において存在しなくてもよい。たとえば、他のソフトウェアに埋め込まれたいくつかの実施形態は、ユーザ入力又は表示のための手段を提供しなくてもよい。

典型的な実施形態では、ＣＤＣＳＳ（クライアント又はサーバ）８１０は、１つ又は複数のマニフェスト・ハンドラ８１１、１つ又は複数のパッチ・ハンドラ８１２、及び、１つ又は複数のファイル・アセンブラ８１３を含む。少なくともいくつかの実施形態では、パッチは、ＣＤＣＳＳクライアント又はサーバの外部で提供され、潜在的に、１つ又は複数のネットワーク８５０を介して利用可能である。他の及び／又は異なるモジュールが実装され得る。加えて、ＣＤＣＳＳは、ＣＤＣＳクライアント８１０によって計算されたパッチを使用するアプリケーションもしくはクライアント・コード８５５、１つもしくは複数のクライアント・コンピューティング・システム８６０、及び／又は、１つもしくは複数のサード・パーティ・パッチ・プロバイダ８６５と、ネットワーク８５０を介して対話することができる。また、注目すべきことに、ＣＤＣＳクライアント・コードをホストするコンピューティング・システムでは、パッチ・データ８１６は、ネットワーク８５０を介して他のシステムにとってアクセス可能にされ得るパッチ・インデックスを含み得る。

例示的な実施形態では、ＣＤＣＳＳ８１０の構成要素／モジュールは、標準的なプログラミング技法を使用して実装される。たとえば、それらは、１つ又は複数の静的又は動的ライブラリとともに、ＣＰＵ８０３上で実行する「ネイティブ」の実行ファイルとして実装され得る。他の実施形態では、ＣＤＣＳクライアント又はＣＤＣＳサーバ８１０の構成要素は、仮想マシンによって処理される命令として実装され得る。当技術分野で知られている様々なプログラミング言語が、そのような例示的な実施形態を実装するために採用されてもよく、それらのプログラミング言語には、限定されないが、オブジェクト指向（たとえば、ＪＡＶＡ（登録商標）、Ｃ＋＋、Ｃ＃、Ｖｉｓｕａｌ Ｂａｓｉｃ．ＮＥＴ、Ｓｍａｌｌｔａｌｋなど）、関数型（たとえば、ＭＬ、Ｌｉｓｐ、Ｓｃｈｅｍｅなど）、手続き型（たとえば、Ｃ、Ｐａｓｃａｌ、Ａｄａ、Ｍｏｄｕｌａなど）、スクリプト（たとえば、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、ＪＡＶＡＳＣＲＩＰＴ（登録商標）、ＶＢＳｃｒｉｐｔなど）、及び宣言型（たとえば、ＳＱＬ、Ｐｒｏｌｏｇなど）を含む、様々なプログラミング言語パラダイムの代表的な実装形態が含まれる。

上記で説明した実施形態はまた、よく知られているか又はプロプライエタリな、同期又は非同期クライアント−サーバ・コンピューティング技法も使用し得る。また、様々な構成要素は、よりモノリシックなプログラミング技法を使用して、たとえば、シングルＣＰＵコンピュータ・システム上で実行する実行ファイルとして実装されてもよく、又は別法として、限定されないが、各々が１つもしくは複数のＣＰＵを有する１つもしくは複数のコンピュータ・システム上で実行する、マルチプログラミング、マルチスレッディング、クライアント−サーバ、もしくはピアツーピアを含む、当技術分野で知られている様々な構造化技法を使用して分解されてもよい。いくつかの実施形態は、同時及び非同期的に実行し、メッセージ・パッシング技法を使用して通信し得る。均等な同期実施形態もまたサポートされる。

加えて、ＣＤＣＳＳクライアント又はＣＤＣＳＳサーバ８１０の一部として（たとえば、データ・リポジトリ８１６に）記憶されたデータへのプログラミング・インターフェースは、Ｃ、Ｃ＋＋、Ｃ＃、及びＪａｖａ ＡＰＩを通して、ファイル、データベース、もしくは他のデータ・リポジトリにアクセスするためのライブラリ、ＸＭＬなどのスクリプト言語を通して、又は、記憶されたデータへのアクセスを提供するウェブ・サーバ、ＦＴＰサーバ、もしくは他のタイプのサーバを通してなど、標準的な機構によって利用可能であり得る。パッチ・データ８１６は、コンピューティング・システム８００がクライアントであるとき、パッチ・インデックスを含み、１つもしくは複数のデータベース・システム、ファイル・システム、もしくはそのような情報を記憶するための任意の他の技法、又は、分散コンピューティング技法を使用する実装形態を含む上記の任意の組合せとして、実装され得る。

また、例示的なＣＤＣＳＳ８１０は、複数の、異種でさえある、コンピュータ・システム及びネットワークからなる分散環境において実装され得る。プログラム及びデータの異なる構成及びロケーションが、本願明細書で説明する技法とともに使用するために企図される。加えて、サーバ及び／又はクライアントは、物理的又は仮想コンピューティング・システムであってもよく、同じ物理的システム上に存在してもよい。また、モジュールのうちの１つ又は複数は、負荷分散、信頼性又はセキュリティの理由などのために、それ自体が分散され、プールされ、又はさもなければグループ化されてもよい。様々な分散コンピューティング技法が、例示した実施形態の構成要素を分散的な方法で実装するために適しており、限定されないが、ＴＣＰ／ＩＰソケット、ＲＰＣ、ＲＭＩ、ＨＴＴＰ、ウェブ・サービス（ＸＭＬ−ＲＰＣ、ＪＡＸ−ＲＰＣ、ＳＯＡＰなど）などが含まれる。他の変形形態が可能である。また、他の機能性が、各構成要素／モジュールによって提供可能であり、又は、既存の機能性が、異なる方法で構成要素／モジュール間で分散され得るが、それでもなお、ＣＤＣＳＳの機能を達成することができる。

さらに、いくつかの実施形態では、ＣＤＣＳＳ８１０の構成要素のうちの一部又は全部が、少なくとも部分的にファームウェア及び／又はハードウェアにおいてなど、他の方法で実装又は提供されてもよく、ファームウェア及び／又はハードウェアには、限定されないが、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）、標準集積回路、適切な命令を実行するコントローラが含まれ、ならびに、マイクロコントローラ及び／又は埋込みコントローラ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、複合プログラマブル論理デバイス（ＣＰＬＤ：ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ
ｄｅｖｉｃｅ）などが含まれる。システム構成要素及び／又はデータ構造のうちの一部又は全部はまた、コンテンツとして（たとえば、実行ファイル、又は他のマシン可読ソフトウェア命令、又は構造化データとして）、コンピュータ可読媒体（たとえば、ハード・ディスク、メモリ、ネットワーク、他のコンピュータ可読媒体、又は、ＤＶＤもしくはフラッシュ・メモリ・デバイスなど、適切なドライブによって、もしくは適切な接続を介して読み取られる他のポータブル媒体品）上に記憶されて、コンピュータ可読媒体が、説明した技法のうちの少なくともいくつかを行うために、コンテンツを実行するか、又はさもなければ使用もしくは提供することが可能にされ得る。構成要素及び／又はデータ構造のうちの一部又は全部は、有形の、非一時的ストレージ媒体上に記憶され得る。システム構成要素及びデータ構造のうちの一部又は全部はまた、（たとえば、搬送波の一部として符号化されるか、又は、アナログもしくはデジタル伝搬信号の一部として含まれることによって）データ信号として、ワイヤレス・ベース及びワイヤード／ケーブル・ベースの媒体にわたることを含めて、次いで送信される、様々なコンピュータ可読伝送媒体上に記憶されてもよく、（たとえば、単一もしくは多重化アナログ信号の一部として、又は、複数の個別のデジタル・パケットもしくはフレームとしての）様々な形態を取り得る。そのようなコンピュータ・プログラム製品はまた、他の実施形態では他の形態を取り得る。したがって、本開示の実施形態は、他のコンピュータ・システム構成とともに実施され得る。

本願明細書で参照された、かつ／又は出願データ・シートにリストされた、上記の米国特許、米国特許出願公開、米国特許出願、外国特許、外国特許出願、及び非特許刊行物のすべてについては、それらの全体を本願明細書に援用する。

例示のために特定の実施形態を本願明細書で説明したが、様々な修正が本開示の趣旨及び範囲から逸脱することなく行われ得ることは、上記から諒解されよう。たとえば、本願明細書で論じたファイル同期を行うための方法及びシステムは、クライアント−サーバ・アーキテクチャ以外の他のアーキテクチャに適用可能である。また、本願明細書で論じた方法及びシステムは、異なるプロトコル、通信媒体（光、ワイヤレス、ケーブルなど）、及びデバイス（ワイヤレス・ハンドセット、電子手帳、携帯情報端末、タブレット、ポータブル電子メール・マシン、ゲーム・マシン、ページャ、ＧＰＳ受信機などのナビゲーション・デバイスなど）に適用可能である。

Claims (15)

1. クライアント・コンピューティング・システム上に存在し、かつ、前記クライアント・コンピューティング・システムの複数のファイルのデータ・コンテンツをインデックス付けする、ローカル・データ・コンテンツ・インデックスを使用して、ファイルのコンテンツを別個の及び分離したサーバ・コンピューティング・システムと同期させるための、前記クライアント・コンピューティング・システムにおいて、コンピュータによって実行するための方法において、
   前記ファイルの１つ又は複数の部分を決定するステップと、
   前記ローカル・データ・コンテンツ・インデックスへのインデックス・ルックアップを行うことによって、かつ、どのようなデータ・コンテンツが前記サーバ・コンピューティング・システム上にすでに存在するかを見いだすために前記サーバ・コンピューティング・システムに問い合わせることなしに、前記ファイルの前記決定された１つ又は複数の部分のうちのどれが、前記サーバ・コンピューティング・システム上にすでに存在すると見なされるデータ・コンテンツに対応するかを判断するステップと、
   前記ファイルの前記決定された１つ又は複数の部分に対応し、各セグメントが、データ・コンテンツ又はデータ・コンテンツへの参照のいずれかを含んでなり、前記ファイルの前記対応する部分が前記サーバ・コンピューティング・システム上にすでに存在すると見なされないデータ・コンテンツに対応すると判断されるとき、データ・コンテンツを含んでなり、かつ、前記ファイルの前記対応する部分が前記サーバ・コンピューティング・システム上にすでに存在すると見なされるデータ・コンテンツに対応すると判断されるとき、データ・コンテンツへの参照を含んでなる、１つ又は複数のセグメントからなるパッチを生成するステップと、
   前記生成されたパッチを転送し、前記サーバ・コンピューティング・システム上にすでに存在するデータ・コンテンツとともに、前記パッチから前記サーバ・コンピューティング・システム上で前記ファイルを生成させ、それによって、前記ファイルの前記データ・コンテンツ全体を転送することなしに、前記ファイルの前記コンテンツを同期させるステップと、を備える、方法。
2. 前記生成されたパッチが、前記ファイルの前記データ・コンテンツ全体よりも少ない全データ・コンテンツを含んでなる、請求項１に記載の方法。
3. 前記ファイルの前記１つ又は複数の部分を前記決定するステップは、
   チャンキング又はフィンガープリンティング・アルゴリズムを使用して、前記ファイルのデータ・コンテンツの１つ又は複数のチャンクを決定することからなる、請求項１又は２に記載の方法。
4. 前記ローカル・データ・コンテンツ・インデックスが、前記クライアント・コンピューティング・システムの前記複数のファイルのためのデータ・コンテンツのチャンクのハッシュ値をインデックス付けし、前記方法は、
   前記ファイルのデータ・コンテンツの前記決定された１つ又は複数のチャンクの各々のためのハッシュ値を決定するステップと、
   前記ファイルのデータ・コンテンツの前記決定された１つ又は複数のチャンクの各々のための前記決定されたハッシュ値をルック・アップすることによって、前記ローカル・データ・コンテンツ・インデックスへの前記インデックス・ルックアップを行い、前記ファイルのデータ・コンテンツの前記決定されたチャンクが、前記クライアント・コンピューティング・システム上の別のファイル中にすでに存在するデータを参照するかどうかを判断するステップとをさらに備える、請求項３に記載の方法。
5. 前記ファイルのデータ・コンテンツの前記チャンクが、前記クライアント・コンピューテ
   ィング・システム上の前記別のファイル中にすでに存在するデータを参照すると判断することが、前記データを前記サーバ・コンピューティング・システム上にすでに存在すると見なすために使用される、請求項４に記載の方法。
6. データ・コンテンツへの参照を含んでなる、前記生成されたパッチの各セグメントがまた、前記参照によって参照される前記データ・コンテンツのハッシュ値をも記憶し、前記パッチの受信者が、前記データ・コンテンツへの参照を評価した結果として検索されたデータ・コンテンツのハッシュ値を計算し、前記計算されたハッシュ値を、前記セグメントに記憶された前記ハッシュ値に対して比較して、前記検索されたデータ・コンテンツの正確性を検証し得る、請求項１乃至５のいずれか１項に記載の方法。
7. 前記パッチが、ヘッダと、その後に続く、データ・コンテンツ又はデータ・コンテンツへの参照のいずれかの１つ又は複数のセグメントとからなる、請求項１乃至６のいずれか１項に記載の方法。
8. 前記生成されたパッチの少なくとも１つのセグメントが、前記クライアント・システムから削除されたファイルのデータ・コンテンツへの参照、及び、第１のファイルからのデータ・コンテンツへの参照のうちの少なくとも一方を含んでなり、及び、少なくとも１つのセグメントが、前記第１のファイルとは別個でありかつ分離した第２のファイルからのデータ・コンテンツへの参照を含んでなる、請求項１乃至７のいずれか１項に記載の方法。
9. 前記生成されたパッチの前記転送を、前記パッチが生成されるときに行うこと、及び、前記生成されたパッチの各セグメントを、前記パッチが生成されるときに転送することのうちの少なくとも一方を行うことと、
   前記生成されたパッチの前記１つ又は複数のセグメント中に含まれるデータ・コンテンツのための前記参照によって参照されるすべてのファイルの指示を含んでなる、マニフェストを転送することとのうちの少なくとも一方を行う、請求項１乃至８のいずれか１項に記載の方法。
10. 請求項１乃至９に記載の方法の少なくとも１つを行うことによって、ファイルを同期させるように、クライアント・コンピューティング・システム中のコンピュータ・プロセッサを制御するコンテンツを含んでなる、コンピュータ可読ストレージ媒体。
11. ファイルのコンテンツを同期させるためのサーバ・コンピューティング・システム、あるいは、方法を行うことによって前記ファイルの前記コンテンツを同期させるようにサーバ中のコンピュータ・プロセッサを制御するコンテンツを備えるコンピュータ・ストレージ媒体のうちのいずれか一方において、コンピュータによって実行するための方法であって、
    請求項１乃至１０に記載の方法の少なくとも１つに従って生成されるパッチであって、同期されるべき前記ファイルの１つ又は複数の部分に対応し、かつ、各セグメントがデータ・コンテンツ又はデータ・コンテンツへの参照を含んでなる、１つ又は複数のセグメントからなるパッチを、前記サーバ・コンピューティング・システムとは分離しておりかつ別個であるクライアント・コンピューティング・システムから受信するステップと、
    前記受信されたパッチの終わりが検出されるまで、前記受信されたパッチの各セグメントを処理して、新しいファイルを作成することからなり、前記処理するステップとを備え、
    前記処理するステップは、
    前記セグメントがデータ・コンテンツを含んでなるとき、前記データ・コンテンツを前記新しいファイルに追加すること、
    前記セグメントがデータ・コンテンツへの参照を含んでなるとき、前記被参照データ
    ・コンテンツの位置を特定するように試みること、及び、前記被参照データ・コンテンツの位置が特定されるとき、前記位置が特定されたデータ・コンテンツを前記新しいファイルに追加すること、及び、
    そうでない場合、前記被参照データ・コンテンツの位置が特定されないとき、前記被参照データ・コンテンツを含んでなる、前記クライアント・コンピューティング・システムからの参照ファイルのコピーを要求すること、及び、前記参照ファイルが受信されるとき、前記参照ファイル中で前記被参照データ・コンテンツの位置を特定し、前記参照ファイル中で位置が特定された前記データ・コンテンツを前記新しいファイルに追加すること、からなる、コンピュータによって実行するための方法。
12. 前記受信されたパッチを、前記サーバ・コンピューティング・システム上のローカル・キャッシュに記憶するステップと、
    前記新しいファイルを求める要求を受信すると、前記記憶されたパッチを、別のクライアント・コンピューティング・システムに提供すること、及び
    前記記憶されたパッチが前記ローカル・キャッシュから除去された後、前記新しいファイルを求める要求が受信されるとき、前記新しいファイルの前記データ・コンテンツ全体のコピーを提供することのうちの少なくとも一方からなるステップと、をさらに備える、請求項１１に記載の方法。
13. 前記受信されたパッチが、ある期間の間に記憶され、前記期間が満了するとき、前記記憶されたパッチが前記ローカル・キャッシュから除去されることと、
    前記受信されたパッチを記憶するための前記時間期間が構成可能であることと、
    前記受信されたパッチが、アルゴリズムに従って前記ローカル・キャッシュから消去されることと、
    前記受信されたパッチを消去するための前記アルゴリズムが、最低使用頻度、最長時間未使用、又は先入れ先出しのうちの少なくとも１つであることとのうちの少なくとも１つが行われる、請求項１１又は１２に記載の方法。
14. 前記新しいファイルを求める要求を、別のクライアント・コンピューティング・システムから受信するステップと、
    前記新しいファイルの前記データ・コンテンツ全体の代わりに、前記受信されたパッチを前記別のクライアント・コンピューティング・システムに提供するステップとをさらに備える、請求項１１乃至１３の少なくとも１項に記載の方法。
15. 前記受信されたパッチ中に含まれるデータ・コンテンツへの任意の参照によって参照されるすべてのロケーションへの指示を含んでなる、マニフェストを受信するステップと、
    前記受信されたパッチの各セグメントを処理する前に、前記受信されたマニフェストを処理して、前記指示されたロケーションが実際に利用可能であるかどうかを判断するステップとのうちの少なくとも一方をさらに備える、請求項１１乃至１４のいずれか１項に記載の方法。