JP2005141756A - バイナリ比較を用いたファイル複製の最適化 - Google Patents

Abstract

【課題】 ファイルに対して変更が行われたときに、クライアントサーバベースのファイルのコピーの同期を維持する。
【解決手段】 データは、クライアントとサーバにとって共に既知の前バージョンと比較され、その２つの差分の高圧縮表現が生成される。次いでこうした差分、すなわち「ｄｉｆｆ」が送信され、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）プロトコルに対する拡張を使用することができる。
【選択図】 図２

Description

本発明は、一般にはコンピュータファイル複製の分野に関する。特に、本発明はバイナリ比較を用いたファイル複製に関する。

複製は、ファイルまたは文書のクライアントバージョンとサーババージョンの同期を保つことにより、データへのローカルアクセスとリモートアクセスを共に可能にする。この機能はアプリケーションにとって有用かつ不可欠であるが、クライアントとサーバの間で伝送しなければならないデータ量のために高コストでもある。ファイルおよび文書の全体と、それらの様々なバージョンがサーバに格納され、サーバとそのクライアントの間で伝送される。したがって、多くの複製システムは、データを伝送する前にデータを圧縮することによって帯域幅を節約しようと試みる。しかし、この従来の圧縮形式は、データの大部分が前バージョンの一部として転送された場合であっても、ファイル全体に対してデータを符号化する。したがって、ファイルまたは文書中のデータに対するマイナチェンジでも、データの多くが宛先に既に存在しているのに、やはりファイルまたは文書の全体を初期に受け取ったバージョンの形で圧縮および伝送する必要がある。

上記に鑑みて、従来技術の制限および欠点を克服するシステムおよび方法が求められている。

本発明は、ファイルに対して変更が行われたときに、クライアント／サーバベースのファイルコピーの同期を維持する機構を提供する。データは、クライアントとサーバにとって共に既知の前バージョンと比較され、その２つの差分の高圧縮表現が生成される。

一実施形態によれば、ベースファイルの第１コピーおよび第２コピーが、クライアントで受信され格納される。この２つのコピーは同一である。クライアントが１つのコピーを受信し、そのコピーの２つのインスタンスを保存する。次いでクライアントは第１コピーに対して変更を行い、変更後の第１コピーと第２コピーの差分（バイナリ差分など）を求める。この差分が、ベースファイルを維持するサーバに送信される。サーバは、サーバのベースファイルが第１装置に格納されたベースファイルと同一である場合、その差分を受け入れる。そうでない場合、サーバはその差分を拒絶する。

本発明の諸態様によれば、差分がサーバで拒絶された場合、サーバは第２の差分をクライアントに送信する。次いでクライアントは、第１装置に格納されたベースファイルの第２コピーに第２の差分を適用する。これにより、サーバに存在するベースファイルに対してクライアントのベースファイルが最新となる。次いでクライアントは、この更新したベースファイルに対して変更を行い、新しい差分を生成し、その新しい差分をサーバに送信することができる。

本発明の追加の特徴および利点は、添付の図面を参照しながら行われる以下の例示的実施形態の詳細な説明から明らかとなるであろう。

好ましい実施形態の上記の概要ならびに以下の詳細な説明は、添付の図面と共に読むときにより良く理解することができる。本発明を説明するために、図面では本発明の例示的構成を示す。しかし、本発明は、開示の特定の方法および手段に限定されない。

（概要）
本発明は、ファイルに対して変更が行われたときに、ファイルのローカル（本明細書では「クライアント」とも呼ぶ）およびサーバベースのコピーの同期を維持することを対象とする。本明細書で説明する例示的システムおよび方法は、現在の技法よりも効率的であり、同期を実施する帯域幅要件と時間要素を共に最小に保つ。

データは、クライアントとサーバにとって共に既知の前バージョンと比較され、その２つの差分の高圧縮表現が生成される。次いでこうした差分、すなわち「ｄｉｆｆ」が送信され、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）ハイパーテキストトランスポートプロトコル）プロトコルに対する拡張を使用することができる。

（例示的コンピューティング環境）
図１に、本発明を実施することができる適切なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用法または機能の範囲に関して何らかの制限を示唆することも意図したものでもない。例示的動作環境１００に図示する構成要素のうちのいずれか１つまたはそれらの組合せに関係する何らかの依存関係も要件もコンピューティング環境１００が有すると解釈すべきではない。

本発明は、他の多くの汎用または専用のコンピューティングシステム環境または構成で動作可能である。本発明と共に使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、コンピュータにより実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークまたはその他のデータ伝送媒体を介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールおよびその他のデータは、メモリ記憶装置を含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体のどちらにも置くことができる。

図１を参照すると、本発明を実施する例示的システムは、コンピュータ１１０の形式の汎用コンピューティング装置を含む。コンピュータ１１０の構成要素は、限定はしないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理装置１２０に接続するシステムバス１２１を含むことができる。システムバス１２１は、様々なバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺（ｐｅｒｉｐｈｅｒａｌ）バス、およびローカルバスを含むいくつかのタイプのバス構造のうちのいずれでもよい。例えば、限定はしないが、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、および(メザニンバスとも呼ばれる)ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。

コンピュータ１１０は、一般に様々なコンピュータ読み取り可能な媒体を含む。コンピュータ読み取り可能な媒体は、コンピュータ１１０でアクセスすることができる入手可能などんな媒体でもよく、それには揮発性媒体と不揮発性媒体の両方、取外し可能媒体と固定媒体の両方が含まれる。例えば、限定はしないが、コンピュータ読み取り可能な媒体はコンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納するための任意の方法または技術で実装される、揮発性媒体および不揮発性媒体の両方、取外し可能媒体および固定媒体の両方を含む。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋｓ）、またはその他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、またはその他の磁気記憶装置、あるいは、所望の情報を格納するのに使用することができ、コンピュータ１１０でアクセスすることができるその他のどんな媒体も含まれる。 通信媒体は、典型的には、搬送波やその他の搬送メカニズムなどの変調されたデータ信号中のコンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどを具現化するものであり、任意の情報伝達媒体を含む。「変調されたデータ信号」という用語は、信号内に情報を符号化するような方法で、１つまたは複数の特性が設定または変更された信号を意味する。限定するものではないが、通信媒体には、例として、有線ネットワーク、直接ワイヤ接続などの有線媒体と、音響、無線、赤外線などの無線媒体が挙げられる。上記の任意の組合せも、コンピュータ読み取り可能な媒体の範囲内に含まれるものとする。

システムメモリ１３０は、ＲＯＭ１３１およびＲＡＭ１３２などの揮発性メモリおよび／または不揮発性メモリという形をとるコンピュータ記憶媒体を含む。起動中などにコンピュータ１１０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、通常ＲＯＭ１３１内に格納される。ＲＡＭ１３２は通常、処理装置１２０によって即座にアクセス可能であり、かつ／または処理装置１２０が現在操作しているデータおよび／またはプログラムモジュールが入っている。例えば、限定はしないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０はまた、その他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単なる一例として、図１に、固定の不揮発性磁気媒体に読み書きするハードディスクドライブ１４０と、取外し可能不揮発性磁気ディスク１５２に読み書きする磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたはその他の光媒体などの取外し可能不揮発性光ディスク１５６に読み書きする光ディスクドライブ１５５を示す。例示的動作環境で使用することのできるその他の取外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体には、限定はしないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インタフェース１４０などの固定のメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０などの取外し可能メモリインタフェースによってシステムバス１２１に接続される。

上記で議論し、図１に図示するドライブとその関連するコンピュータ記憶媒体は、コンピュータ１１０に対してコンピュータ読取可能命令、データ構造、プログラムモジュール、およびその他のデータの記憶を実現する。例えば図１では、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているように描かれている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じでも、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが相異なるコピーであることを示すためにここでは異なる番号を付けてある。ユーザは、キーボード１６２や、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ（ｓａｔｅｌｌｉｔｅ ｄｉｓｈ）、スキャナなどを含めることができる。これらの入力装置やその他の入力装置はしばしば、システムバスに結合されるユーザ入力インタフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などのその他のインタフェースおよびバス構造によって接続することもできる。モニタ１９１またはその他の種類のディスプレイ装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６などのその他の周辺出力装置も含むことができ、その周辺出力装置は、出力周辺インタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置（ｐｅｅｒ ｄｅｖｉｃｅ）、または他の共通ネットワークノードでよく、通常、コンピュータ１１０に関して上述した構成要素のうちの多くまたはすべてを含むが、図１にはメモリ記憶装置１８１だけを示してある。図示する論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークも含めることができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的なものである。

ＬＡＮネットワーキング環境で使用する際、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２またはその他の手段を含む。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。例えば、限定はしないが、図１では、リモートアプリケーションプログラム１８５がメモリ装置１８１上にあるものとして示す。図示するネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立するその他の手段も使用できることを理解されよう。

（例示的分散コンピューティングフレームワークまたはアーキテクチャ）
パーソナルコンピューティングとインターネットの集中（ｃｏｎｖｅｒｇｅｎｃｅ）に照らしてみると、様々な分散コンピューティングフレームワークが開発されており、または開発中である。個人ユーザとビジネスユーザは一様に、コンピューティング活動をますますウェブブラウザ指向またはネットワーク指向にする、アプリケーションおよびコンピューティング装置用のシームレスに相互運用可能（ｉｎｔｅｒｏｐｅｒａｂｌｅ）かつウェブ使用可能（ｗｅｂ−ｅｎａｂｌｅｄ）なインタフェースを備える。

例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）の．ＮＥＴプラットフォームは、サーバ、ウェブベースのデータストレージなどのビルディングブロックサービス（ｂｕｉｌｄｉｎｇ−ｂｌｏｃｋ ｓｅｒｖｉｃｅｓ）、およびダウンロード可能なデバイスソフトウェアを含む。一般的に言えば、．ＮＥＴプラットフォームは、（１）コンピューティング装置の全範囲を共に動作させ、すべてのコンピューティング装置上でユーザ情報を自動的に更新および同期させる能力、（２）ＨＴＭＬではなくＸＭＬをより多く使用することによって可能となる、ウェブサイトの対話能力の向上、（３）例えばＥメールなどの様々なアプリケーションまたはＭｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ（登録商標）などのソフトウェアを管理するための、中央の開始点からユーザへの製品およびサービスのカスタマイズされたアクセスおよび配信を特徴とするオンラインサービス、（４）情報へのアクセスの効率および容易さ、ならびにユーザおよび装置間の情報の同期を向上させる集中データストレージ、（５）Ｅメール、ファックス、電話などの様々な通信媒体を統合する能力、（６）開発者のために、再利用可能なモジュールを作成し、それによって生産性を向上させ、プログラミングエラーの数を削減する能力、および（７）多くの他のクロスプラットフォーム統合機能も提供する。

本明細書では、例示的実施形態を、コンピューティング装置上に存在するソフトウェアに関連して説明するが、本発明の１つまたは複数の部分は、オペレーティングシステム、ＡＰＩ、またはコプロセッサと要求側オブジェクト間の「ミドルマン（ｍｉｄｄｌｅ ｍａｎ）」オブジェクトを介して実装することもでき、その結果、サービスは、．ＮＥＴの言語およびサービスのすべてによって実行され、サポートされ、アクセスされる。他の分散コンピューティングフレームワークにおいても同様である。

（例示的実施形態）
図２は、本発明による、更新後ファイルを維持する例示的方法の流れ図である。この例示的実施形態では、クライアントがファイルを修正し、その変更をサーバにアップロードする。ステップ２００では、クライアントが、サーバに格納されたベースファイルの最新バージョン（「バージョンＡ」）のコピーを受信する。ステップ２１０では、クライアントは、バージョンＡに対して、その変更を行い、バージョンＡ’を作成する。ステップ２２０では、クライアントは、元のバージョンＡのコピーおよび新バージョンＡ’を保存する。したがって、クライアントは、ユーザがファイルを更新した場合であっても、最後の既知のサーバ状態を維持する。ステップ２１０の前またはステップ２１０のどちらかの後に、バージョンＡのコピーをクライアントに格納することができることが考慮されている。

次いでステップ２３０では、バージョンＡとＡ’を比較することにより、差分すなわち「ｄｉｆｆ」を生成する。ｄｉｆｆは、１つのファイルの２つのバージョンを比較して圧縮ｄｉｆｆを生成する機構であり、その圧縮ｄｉｆｆを旧ファイルに適用して新ファイルを生成することができる。差分生成（ｄｉｆｆｅｒｅｎｃｉｎｇ）は、ベース形式と修正形式間の差分を求めるための、当業者に周知のいずれの方法、技法、またはシステムでも実行することができる。生成される好ましい差分はバイナリ差分である。ファイルはバイトの連続と考えられる。従来の圧縮アルゴリズムを使用して、シャドーコピーまたはベースコピーと修正後のコピー間の差分を計算することによってバイナリ差分を生成する。次いでこの差分をサーバに送信し、サーバでは、この差分は拒絶されるか受諾される。拒絶は、サーバ上のベースが変更されている場合に起こり、この場合、差分はサーバにとって全く役に立たない。本発明に従って任意の差分エンジンまたは技法を使用できることが考慮されている。本明細書では、例示的目的でバイナリ差分技法の使用法を提供する。

具体的には、ステップ２４０で、クライアントがｄｉｆｆをサーバに送信する。ステップ２５０では、サーバは、サーバのベースファイルの最新バージョンが、クライアントが修正を行う際に使用したバージョンＡから変化していないことが確かであることをチェックした後に、バージョンＡにｄｉｆｆを適用して、新しい、ファイルの最新バージョンであるバージョンＢを生成する。サーバにより実行されるバージョンのチェックについては、図３〜６に関連して以下でさらに説明する。

ステップ２６０では、サーバは、新バージョンＢならびにクライアント提供のｄｉｆｆ（任意選択）を格納する。新バージョンＢは、ベースファイルの最新アップデートとみなされ、図３〜６に関連して以下でさらに説明するように、ｄｉｆｆは、元のバージョンＡに対して変更を行う可能性のある他のクライアントによる使用のために保持される。サーバは、任意選択で、最適化されたアップデートを他のクライアントに提供するためにｄｉｆｆを格納する。複数の修正が行われた場合、旧バージョンから最新バージョンを得るのに複数のｄｉｆｆが必要となる場合がある。ｄｉｆｆは、変更を行う意図はないが、最新バージョンＢを読み出すことを望み、既にバージョンＡを有しているクライアントにとっても有用である場合があることに留意されたい。

ステップ２７０では、サーバは、新バージョン識別子（例えば「バージョンＢ」）をクライアントに通知する。次いでステップ２８０で、クライアントは、ステップ２３０で求めたｄｉｆｆ、ならびにクライアントが格納していたバージョンＡを廃棄し、クライアントは、バージョンＡ’を新バージョン識別子でマークする。したがって、クライアントは、バージョンＡ’をバージョンＢとリネームする。

図３は、更新後ファイルを維持する別の例示的方法の流れ図である。この例では、サーバが、ｄｉｆｆファイルの形の最新の変更をクライアントに提供する。ステップ３００では、ファイルのバージョンＡを有するクライアントがファイルの更新を要求する。クライアントは、例えばクライアントがファイルの最新バージョンに変更を行うことを望むためにそのような要求を行うことがある。クライアントは、クライアントがバージョンＡを有することをサーバに通知し、それに応答して、ステップ３１０では、サーバはＡのｄｉｆｆを返す。サーバは、以前のクライアントアップデート（例えば図２のステップ２６０）からのＡのｄｉｆｆを維持している場合がある。ステップ３２０では、クライアントは、Ａのｄｉｆｆを、格納されているバージョンＡに適用し、ファイルの最新バージョン（例えば「バージョンＢ」）を生成する。

図４に、本発明の諸態様を説明する際に役立つ例示的システムのブロック図を示し、図５および６に、２人のユーザが同一のベースファイルに対して変更を行っているときに更新後ファイルを維持する例示的方法の流れ図を示す。この例では、サーバ４００がベースファイル（バージョンＡ）を維持し、２つのクライアント４１０、４２０（本明細書ではそれぞれクライアント１および２と呼ぶ）が共に、同一のベースファイルに変更を行うことを望んでいると仮定する。

ステップ５００では、クライアント１とクライアント２が共に、ベースファイルの最新バージョン（「バージョンＡ」）をサーバ４００に要求し、サーバ４００から受信する（すなわち、クライアント１および２はベースファイルをダウンロードする）。クライアント１および２がベースファイルに同時または順次に変更を行えることが考慮されている。 しかし、一方のクライアントだけが、元のベースファイルに対する変更をサーバに送信する際に最初のものとなる。こうした変更は元のベースファイルに適用される。したがって、サーバに差分を送信する最初のクライアントが、サーバによって受け入れられるその差分を有する。ベースファイルに基づく後続のクライアントの差分は、サーバによって拒絶される。したがって、以下でより詳細に説明するように、元のベースファイルに対する変更を後で送信するクライアントは、まず更新後のベースファイルを受信し、次いでその更新後のベースファイルに対して変更を行わなければならない。

クライアント１が最初に変更を行うと仮定すると、この方法は、図２で説明したステップ２００から２６０と同様に進む。すなわち、ステップ５０５で、クライアント１は、バージョンＡに対して変更を行い、バージョンＡ’を作成する。ステップ５１０では、クライアント１は、元のバージョンＡのコピーおよび新バージョンＡ’を保存する。ステップ５０５の前またはステップ５０５の後のどちらかで、バージョンＡのコピーをクライアント１に格納できることが考慮されている。次いでステップ５１５では、バージョンＡとＡ’を比較することによってｄｉｆｆ（好ましくはバイナリｄｉｆｆ）を作成する。

ステップ５２０では、クライアント１がｄｉｆｆをサーバ４００に送信する。変更をサーバと同期するとき、クライアントは、サーバがｄｉｆｆ機構をサポートすることを検証し、次いで「ｄｉｆｆ」を、元のファイルのバージョンを指定するバージョン情報と共にアップロードする。ステップ５２５では、サーバ４００は、ベースファイルの最新バージョンが、クライアントが修正を行う際に使用したバージョンＡから変化していないことが確かであることをチェックした後に、クライアント１提供のバージョンＡのｄｉｆｆを適用して、新しい、ファイルの最新バージョンであるバージョンＢを生成する。

ステップ５３０では、サーバは、新バージョンＢならびにクライアント１提供のｄｉｆｆを格納する。新バージョンＢは、ベースファイルの最新アップデートとみなされ、ｄｉｆｆは、元のバージョンＡに対して変更を行う可能性のある他のクライアント（例えばクライアント２）による使用のために保持される。

図５には図示していないが、ステップ２７０および２８０と同様に、サーバ４００は、新バージョン識別子（例えば「バージョンＢ」）をクライアント１に通知する。次いでクライアント１は、求めたｄｉｆｆ、ならびに格納されているバージョンＡを廃棄し、このクライアントは、バージョンＡ’を新バージョン識別子でマークする。したがって、このクライアントは、バージョンＡ’をバージョンＢとリネームする。

一方、ステップ５３５で、クライアント２は、受信した元のベースファイルのバージョンＡを修正し、新バージョンであるバージョンＡ”を生成する。ステップ５４０では、クライアント２は、元のバージョンＡのコピーおよび新バージョンＡ”を保存する。ステップ５４０の前またはステップ５４０の後のどちらかで、バージョンＡのコピーをクライアント２に格納できることが考慮されている。次いでステップ５４５では、バージョンＡとＡ”を比較することによってｄｉｆｆを作成する。

ステップ５５０で、クライアント２は、バージョンＡのｄｉｆｆをサーバ４００に送信する。サーバ４００は、サーバ４００が格納しているベースファイルが、クライアント２がクライアント２の修正の基礎として使用したベースファイルから変化したか否かを確かめる。

ベースファイルに関するサーバの状態が、要求側クライアントに関連するローカルストアにキャッシュされている場合、ローカルストア内のファイルと、サーバ上の対応するファイルの状態との間で比較が行われる。この比較は、ローカルストア内に格納されたファイルのコピーが最新バージョンであるか、それとももっと新しいバージョンがサーバに存在するかを判定するために実施される。言い換えれば、この比較により、要求側クライアントがファイルのコピーを最後に得たときから、別のクライアントが要求されたファイルを修正および更新した可能性に対処する。この比較は、クライアントとサーバの間でファイル全体の伝送を必要とすることなく、望ましくは、ファイルの状態を表す識別子の伝送を含むものであることに留意されたい。このようにして、この比較により、別のやり方では必要となる場合があるネットワークトラフィックが低減され、同一のファイルのバージョンを複数回伝送することが回避される。

したがって、ステップ５５５では、サーバは、ベースファイルの最新バージョンが、クライアント２が修正を行う際に使用したバージョンＡから変化していないことが確かであることをチェックする。ベースファイルが変化していない場合、ステップ５９０で、サーバ４００は、クライアント２提供のｄｉｆｆを、サーバが格納するベースファイルに適用して、新しい、ファイルの最新バージョンを生成し、ステップ５９５で、サーバは、このファイルの最新バージョンを、クライアント２提供のｄｉｆｆと共に格納する。サーバ４００は、新バージョン識別子をクライアント２に通知し、次いでクライアント２は、求めたｄｉｆｆ、ならびにクライアント２が格納しているバージョンＡを廃棄し、修正されたバージョンＡ”を新バージョン識別子でマークする。

しかし、この例では、クライアント１が既にサーバ４００に変更を与えており、したがってサーバに格納されたベースファイルがバージョンＢに変化している。クライアント２は、バージョンＢのコピーをもっておらず、ファイルのバージョンＡに対して変更を行った。したがって、ベースファイルが変化しているので、ステップ５６０では、サーバ４００はクライアント２提供のｄｉｆｆを拒絶し、サーバ４００が先に（ステップ５３０で）受信および格納した、クライアント１提供のバージョンＡに対するｄｉｆｆをクライアント２に送信する。

ステップ５６５では、クライアント２は、クライアント１提供のバージョンＡのｄｉｆｆを、格納しているバージョンＡに適用し、サーバが格納する最新のバージョンのファイルを得る（ここではバージョンＢ）。次いでクライアント２は、ステップ５７０および５７５でそれぞれ、最新バージョンと修正したバージョンＡ”間のｄｉｆｆを求め、そのｄｉｆｆをサーバ４００に送信する。ステップ５８０で、サーバ４００は、新しいｄｉｆｆを、格納している最新バージョン（バージョンＢ）に適用し、新しい最新バージョン（ここではバージョンＣ）を生成する。ステップ５８５では、サーバ４００は、新しい最新バージョンならびに新しく受信したｄｉｆｆを格納する。図５には図示していないが、ステップ２７０および２８０と同様に、サーバ４００は、新バージョン識別子（例えば「バージョンＣ」）をクライアント２に通知する。次いでクライアント２は、求めたｄｉｆｆ、ならびにクライアント２が格納するバージョンを廃棄し、バージョンＡ”を新バージョン識別子でマークする。したがって、クライアントは、バージョンＡ”をバージョンＣとリネームする。

修正後のバージョンをサーバで自動的に保存するのではなく、管理者などのユーザが、どのように変更を統合すべきかを決定できることも考慮されている。これにより、以前のユーザの変更との間の内容の矛盾を回避することができる。

サーバがｄｉｆｆの受け入れを承認することを示す前または後のどちらかに、そのｄｉｆｆを求めることができることに留意されたい。したがって、効率を高めるために、クライアントは、サーバが現在最新バージョンとして維持しているベースファイルの同一のバージョンに対してクライアントが変更を行ったことをサーバが示すまで待機することができる。その場合にのみ、クライアントはｄｉｆｆを求めそれをサーバに提供する。望ましくは、サーバは差分を計算せず、代わりに差分を適用するだけである。

別のクライアントが変更を提供するためにサーバと接続する前に、あるクライアントが、複数のアップロードを行う状況が考慮されている。例えば、元のベースファイルがバージョンＡであると仮定する。その場合、クライアント１が変更を行い、こうした変更がバージョンＢとして受け入れられる。クライアント１がさらに変更を行って、それをサーバに提供した場合、この新しい最新バージョンはバージョンＣとして保存される。望ましくは、サーバは、バージョンＡとＢの差分、およびバージョンＢとＣの差分を保存する。したがって、別のクライアントが変更を行ったとき、サーバは、バージョンＡとＢの差分、およびバージョンＢとＣの差分を、好ましくは同一のメッセージでそのクライアントに送信する。次いでクライアントは、バージョンＢ、次いでバージョンＣを再現し、バージョンＣとその変更の差分を求め、この差分をサーバに提供する。

期限切れのクライアントがサーバに接続して最新バージョンを取得した場合、そのクライアントは、どのバージョンを有するかをサーバに伝え、格納されたｄｉｆｆがそのバージョンまでさかのぼる場合、適切な１つまたは複数のｄｉｆｆが現バージョンＩＤと共に返される。好ましくは、旧バージョン（すなわち、ベースファイルの旧バージョンに対して「下位互換性」のある）に対してまだ変更を行っている可能性のあるクライアントに対処するために、サーバは、処理中にサーバが受信する様々なバージョン間のすべてのｄｉｆｆを維持する。しかし、ある時点では、サーバは、以前に格納した維持しているｄｉｆｆを削除するかさもなければ除去することができる。このような動作は、例えば日付または記憶容量によって促すことができる。

望ましくは、ｄｉｆｆを送信するのにハイパーテキストトランスポートプロトコル（ＨＴＴＰ）が使用される。具体的には、プロトコル拡張を使用して、ｄｉｆｆが送信され、あるいは別の方法で実施され、またはメッセージ内に組み込まれていることをサーバに警告することができる。

ＨＴＴＰは、インターネット、イントラネット、エクストラネットなどのＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）互換ネットワークを介して情報を移送する標準的機構として出現した。ＨＴＴＰは、より具体的には、分散協調ハイパーメディア情報システム向けのアプリケーションレベルプロトコルである。ＨＴＴＰは、その要求方法、エラーコード、およびヘッダの拡張により、そのハイパーテキスト向けの用途を超えて、ネームサーバや分散オブジェクト管理システムなどの多くのタスクに使用することができる汎用のステートレスなプロトコルである。ＨＴＴＰは、情報がその仕様に従って移送されるのでトランスポートプロトコルと呼ばれ、クライアントへの応答を生成するサーバに要求を行うクライアントによって情報が交換されるので、要求−応答プロトコルとも呼ばれる。本明細書で述べるＨＴＴＰは、ＨＴＴＰの任意の規格を一般的に参照するものであり、これはウェブサイトｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇで入手できる。

ＨＴＴＰの一般的な用途は、マークアップ言語に従ってフォーマットされた情報の移送である。例えば、インターネットのよく知られている応用は、インターネットのワールドワイドウェブページのブラウジングである。このような例では、通常、ＨＴＴＰに従って移送されるとき、取り出される情報は、ハイパーテキストマークアップ言語（ＨＴＭＬ）フォーマットである。しかし他の標準マークアップ言語も出現してきている。そのような１つのマークアップ言語は、拡張可能マークアップ言語（ＸＭＬ）である。ＸＭＬは、ＸＭＬ文書と呼ばれるデータオブジェクトのクラスを記述し、それらを処理するコンピュータプログラムの挙動を部分的に記述する。ＨＴＭＬとＸＭＬの間の主な違いは、例えば、前者の中では情報コンテンツがコンテンツのレイアウトと絡み合い、それらの分離が難しいことである。逆に、ＸＭＬの中では、コンテンツの格納レイアウト（ｓｔｏｒａｇｅ ｌａｙｏｕｔ）および論理構造の記述が、コンテンツ自体から分離して維持される。しかし、ＸＭＬとＨＴＭＬはどちらも、標準汎用マークアップ言語（ＳＧＭＬ）と呼ばれるマークアップ言語の派生物である。本明細書で述べるＸＭＬは、ウェブサイトｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ上で説明されているような、ＸＭＬの任意の標準を一般的に参照するものである。

下位互換性および相互運用性を維持するために、例えば、サーバがバイナリｄｉｆｆをサポートすることをクライアントが発見することが可能となるように、ＯＰＴＩＯＮＳ応答内の拡張ＨＴＴＰヘッダを使用することができる。ＧＥＴ要求内の拡張ヘッダが、クライアントがｄｉｆｆを受け入れることをサーバに通知する。

クライアントまたはサーバのどちらかは、バイナリｄｉｆｆを使用しないことを選択することができる。ある場合には、ｄｉｆｆを送信するメッセージ（例えばＨＴＴＰバイナリｄｉｆｆヘッダ）がファイル自体よりも大きくなる可能性がある。そのような場合には、サーバとクライアント間のｄｉｆｆの代わりに文書を送信することがより望ましい場合がある。クライアントは、ｄｉｆｆサイズが新しいファイルよりも大きいことを判定することができる。これは、例えば新しいファイルが０バイトである場合に生じる可能性がある。サーバは、ｄｉｆｆを廃棄して記憶空間を節約するよう決定することができる。ｄｉｆｆが使用されない場合、ファイル全体が送信される。ｄｉｆｆが送信されるときを知らせるために、クライアントは、拡張ヘッダをそのＰＵＴ要求と共に送信して、本文中のバイナリｄｉｆｆの存在、およびｄｉｆｆが生成されたベースファイルのバージョン番号を示すことができる。サーバは、拡張ヘッダをそのＧＥＴ応答と共に送信し、バイナリｄｉｆｆチェーンの存在、ベースファイルのバージョン番号、およびチェーン中のｄｉｆｆの数を示す。

クライアントファイルを最新にするのに複数のｄｉｆｆが必要であるとき、サーバは、単一の応答中にｄｉｆｆをつなぎ合わせるか、またはｄｉｆｆの和が新バージョンよりも大きい場合、その新バージョン自体を送り返すかのどちらかを選ぶことができる。

ｄｉｆｆを計算し適用するエンジンが、クライアントおよび／またはサーバ内に設けられることが好ましい。発見およびｄｉｆｆ／バージョン管理のためのプロトコルも実装されることが好ましい。拡張ＨＴＴＰヘッダにより、クライアントおよびサーバは差分生成に関する能力を表現することが可能となる。例えば、クライアントは、拡張ヘッダをそのＰＵＴ要求と共に送信して、本文中のバイナリｄｉｆｆの存在、およびｄｉｆｆが生成されたベースファイルのバージョン番号を示す。サーバは、拡張ヘッダをそのＧＥＴ応答と共に送信し、バイナリｄｉｆｆチェーンの存在、ベースファイルのバージョン番号、およびチェーン中のｄｉｆｆの数を示す。

サーバコードは、（エンジンを使用して）ｄｉｆｆを適用し、格納し、返すようにｄｉｆｆを管理できることが望ましく、各クライアントは、サーバ状態を維持し、ｄｉｆｆを生成し、ｄｉｆｆをサーバに送信し、返されたｄｉｆｆを適用する能力を有することが好ましい。

複製は、多種多様なアプリケーションにより広く使用されるが、こうしたシステムのコストおよび性能は常に課題である。本発明は、複製の性質（既知のクライアント／サーバ状態）を活用して、システムの効率を大きく向上させる。本発明は、サーバベースの文書またはファイルにオフラインでアクセスすることを可能にする製品などの定期的に更新される大きなファイルを複製するシステムに適用することができる。

上述のように、様々なコンピューティング装置に関連して本発明の例示的実施形態を説明したが、基礎となる概念は、任意のコンピューティング装置またはシステムにも適用することができる。

本明細書で説明した様々な技法は、ハードウェアまたはソフトウェア、あるいは適切ならばその両者の組合せと共に実装することができる。したがって、本発明の方法および装置、またはそれらのある態様または部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、その他の任意の機械読み取り可能な記憶媒体などの有形媒体中に具現化されたプログラムコード（すなわち命令）の形を取ることができ、この場合、プログラムコードがコンピュータなどのマシン内にロードされ、マシンによって実行されたとき、そのマシンが本発明を実施する装置となる。プログラム可能コンピュータ上でプログラムコードを実行する場合、コンピューティング装置は一般に、プロセッサ、プロセッサによって読み取り可能な記憶媒体（揮発性／不揮発性メモリおよび／または記憶素子を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。望むならアセンブリ言語または機械語でプログラムを実装することもできる。いずれの場合も、言語はコンパイル型言語またはインタプリタ型言語でよく、ハードウェア実装と組み合わせることができる。

本発明の方法および装置は、電気配線またはケーブリング（ｃａｂｌｉｎｇ）、光ファイバ、あるいは他の任意の形態の伝送などの、何らかの伝送媒体を介して伝送されるプログラムコードの形態で具現化された通信を介して実施することもでき、この場合は、プログラムコードが、ＥＰＲＯＭ、ゲートアレイ、プログラマブルロジックデバイス（ＰＬＤ）、クライアントコンピュータなどのマシンで受信され、ロードされ、実行されたとき、そのマシンが本発明を実施する装置になる。汎用プロセッサ上に実装するとき、このプログラムコードは、プロセッサと組み合わされ、本発明の機能を起動するように動作する固有の装置を提供する。加えて、本発明に関連して使用する任意の記憶技法は常にハードウェアとソフトウェアの組合せでよい。

様々な図の好ましい実施形態に関連して本発明を説明したが、他の類似の実施形態も使用することができ、あるいは本発明から逸脱することなく本発明と同じ機能を実施するために記載の実施形態に修正や追加を行うことができることを理解されたい。したがって、本発明はどの単一の実施形態にも限定されず、添付の特許請求の範囲による幅と範囲において解釈すべきである。

本発明の諸態様を実施することのできる例示的コンピューティング環境を示すブロック図である。 本発明による更新後ファイルを維持する例示的方法の流れ図である。 本発明による更新後ファイルを維持する別の例示的方法の流れ図である。 本発明の諸態様を説明する際に役立つ例示的システムのブロック図である。 本発明による更新後ファイルを維持する別の例示的方法の流れ図である。 本発明による更新後ファイルを維持する別の例示的方法の流れ図である。

符号の説明

１００ コンピューティング環境
１１０ コンピュータ
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ ＢＩＯＳ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定の、不揮発性メモリインタフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ 取外し可能、不揮発性メモリインタフェース
１５１ 磁気ディスクドライブ
１５２ 取外し可能不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ 取外し可能不揮発性光ディスク
１６０ ユーザ入力インタフェース
１６１ マウス
１６２ キーボード
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ

Claims (40)

1. 更新後ファイルを維持する方法であって、
   ベースファイルの第１コピーおよび第２コピーを第１装置に格納するステップと、
   前記第１コピーに対する変更を前記第１装置で受信するステップと、
   前記変更した第１コピーと前記第２コピーとの間の第１の差分を求めるステップと、
   前記第１の差分をサーバに送信するステップと、
   前記サーバの前記ベースファイルが前記第１装置に格納された前記ベースファイルと同一である場合、前記サーバで前記第１の差分を受け入れ、そうでない場合、前記サーバで前記第１の差分を拒絶するステップとを備えることを特徴とする方法。
2. 前記第１装置の前記ファイルの前記第１コピーを前記サーバから受信するステップと、前記ファイルの前記第１コピーおよび前記第２コピーを前記第１装置に格納する前に、前記第１装置で前記ファイルの第２コピーを作成するステップとをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記第１の差分を求めるステップは、前記変更した第１コピーと前記第２コピーとの間のバイナリ比較を使用するステップを含むことを特徴とする請求項１に記載の方法。
4. 前記第１の差分がバイナリｄｉｆｆであることを特徴とする請求項１に記載の方法。
5. 前記差分が前記サーバで拒絶された場合、前記サーバから前記第１装置に第２の差分を送信し、前記第１装置に格納された前記ベースファイルの前記第２コピーに対し前記第２の差分を適用することを特徴とする請求項１に記載の方法。
6. 前記サーバの前記ベースファイルが前記第１装置に格納された前記ベースファイルと同一であるか否かを判定するステップをさらに含むことを特徴とする請求項１に記載の方法。
7. 前記第１の差分を送信するステップは、ＨＴＴＰプロトコルに対する拡張を使用するステップを含むことを特徴とする請求項１に記載の方法。
8. 前記ベースファイルの第１コピーおよび第２コピーを第２装置に格納するステップと、
   前記第１コピーに対する変更を前記第２装置で受信するステップと、
   前記変更した第１コピーと前記第２コピーとの間の第２の差分を求めるステップと、
   前記第２の差分を前記サーバに送信するステップと、
   前記サーバの前記ベースファイルが前記第２装置に格納された前記ベースファイルと同一である場合、前記サーバで前記第２の差分を受け入れ、そうでない場合、前記サーバで前記第２の差分を拒絶するステップとをさらに含むことを特徴とする請求項１に記載の方法。
9. 前記第２の差分が前記サーバで拒絶された場合、第２クライアントに第３の差分を送信し、前記第２装置に格納された前記ベースファイルの前記第２コピーに対し前記第３の差分を適用するステップをさらに含むことを特徴とする請求項８に記載の方法。
10. 前記第２装置の前記ファイルの前記第１コピーを前記サーバから受信するステップと、前記ファイルの前記第１コピーおよび前記第２コピーを前記第２装置に格納する前に、前記第２装置で前記ファイルの第２コピーを作成するステップとをさらに含むことを特徴とする請求項８に記載の方法。
11. 前記第２の差分を求めるステップは、前記第２装置の前記変更した第１コピーと前記第２コピーとの間のバイナリ比較を使用するステップを含むことを特徴とする請求項８に記載の方法。
12. 前記第２の差分がバイナリｄｉｆｆであることを特徴とする請求項８に記載の方法。
13. 前記サーバの前記ベースファイルが前記第２装置に格納された前記ベースファイルと同一であるか否かを判定するステップをさらに含むことを特徴とする請求項８に記載の方法。
14. 前記第２の差分を送信するステップは、ＨＴＴＰプロトコルに対する拡張を使用するステップを含むことを特徴とする請求項８に記載の方法。
15. 更新後ファイルを維持する方法を実行するコンピュータ実行可能命令が格納されたコンピュータ読み取り可能な媒体であって、前記コンピュータ実行可能命令は、
    ベースファイルの第１コピーおよび第２コピーを第１装置に格納するステップと、
    前記第１コピーに対する変更を前記第１装置で受信するステップと、
    前記変更した第１コピーと前記第２コピーとの間の第１の差分を求めるステップと、
    前記第１の差分をサーバに送信するステップと、および
    前記サーバの前記ベースファイルが前記第１装置に格納された前記ベースファイルと同一である場合、前記サーバで前記第１の差分を受け入れ、そうでない場合、前記サーバで前記第１の差分を拒絶するステップとを含むことを特徴とするコンピュータ読み取り可能な媒体。
16. 前記第１装置の前記ファイルの前記第１コピーを前記サーバから受信し、前記ファイルの前記第１コピーおよび前記第２コピーを前記第１装置に格納する前に、前記第１装置で前記ファイルの第２コピーを作成するコンピュータ実行可能命令をさらに含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
17. 前記第１の差分を求めるステップとは、前記変更した第１コピーと前記第２コピーとの間のバイナリ比較を使用することを含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
18. 前記第１の差分がバイナリｄｉｆｆであることを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
19. 前記差分が前記サーバで拒絶された場合、前記サーバから前記第１装置に第２の差分を送信し、前記第１装置に格納された前記ベースファイルの前記第２コピーに前記第２の差分を適用するコンピュータ実行可能命令をさらに含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
20. 前記サーバの前記ベースファイルが前記第１装置に格納された前記ベースファイルと同一であるか否かを判定するコンピュータ実行可能命令をさらに含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
21. 前記第１の差分を送信するステップとは、ＨＴＴＰプロトコルに対する拡張を使用するステップとを含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
22. 前記ベースファイルの第１コピーおよび第２コピーを第２装置に格納し、
    前記第１コピーに対する変更を前記第２装置で受信し、
    前記変更した第１コピーと前記第２コピーとの間の第２の差分を求め、
    前記第２の差分を前記サーバに送信し、
    前記サーバの前記ベースファイルが前記第２装置に格納された前記ベースファイルと同一である場合、前記サーバで前記第２の差分を受け入れ、そうでない場合、前記サーバで前記第２の差分を拒絶するコンピュータ実行可能命令をさらに含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。
23. 前記第２の差分が前記サーバで拒絶された場合、第２クライアントに第３の差分を送信し、前記第２装置に格納された前記ベースファイルの前記第２コピーに前記第３の差分を適用するコンピュータ実行可能命令をさらに含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
24. 前記第２装置の前記ファイルの前記第１コピーを前記サーバから受信し、前記ファイルの前記第１コピーおよび前記第２コピーを前記第２装置に格納する前に、前記第２装置で前記ファイルの第２コピーを作成するコンピュータ実行可能命令をさらに含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
25. 前記第２の差分を求めるステップは、前記第２装置の前記変更した第１コピーと前記第２コピーとの間のバイナリ比較を使用するステップを含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
26. 前記第２の差分がバイナリｄｉｆｆであることを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
27. 前記サーバの前記ベースファイルが前記第２装置に格納された前記ベースファイルと同一であるか否かを判定するコンピュータ実行可能命令をさらに含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
28. 前記第２の差分を送信するステップは、ＨＴＴＰプロトコルに対する拡張を使用するステップを含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な媒体。
29. ファイル同期システムで使用するシステムであって、
    ベースファイルの第１コピーおよび第２コピーを格納する記憶装置と、
    前記ベースファイルの前記第１コピーに対する変更を受信する入力装置と、
    前記受信した変更に基づいて前記第１コピーを変更し、前記変更した第１コピーと前記第２コピーの差分を求めるプロセッサとを備えることを特徴とするシステム。
30. 前記差分はバイナリ差分であることを特徴とする請求項２９に記載のシステム。
31. 前記ベースファイルがサーバ上に常駐し、前記差分を前記サーバに送信する出力装置をさらに備えることを特徴とする請求項２９に記載のシステム。
32. 前記差分が、前記ＨＴＴＰプロトコルに対する拡張を使用して前記サーバに送信されることを特徴とする請求項２９に記載のシステム。
33. 第２の差分を受信する装置をさらに備え、前記プロセッサは、前記第２の差分を前記ベースファイルの前記第２コピーに適用して修正後第２コピーを生成し、前記受信した変更を前記修正後第２コピーに適用して第３コピーを生成し、前記第３コピーと前記修正後第２コピーとの間の第３の差分を求めることを特徴とする請求項２９に記載のシステム。
34. 前記第３差分をサーバに送信する出力装置をさらに備えることを特徴とする請求項３３に記載のシステム。
35. ファイル同期システムで使用するシステムであって、
    ベースファイルを格納する記憶装置と、
    クライアント装置から差分を受信する入力装置と、
    前記差分が前記格納したベースファイルに適用可能であるか否かを判定し、適用可能である場合、前記差分を前記ベースファイルに適用し、そうでない場合、前記差分が拒絶されたことを前記クライアントに示すプロセッサとを備えることを特徴とするシステム。
36. 前記差分はバイナリ差分であることを特徴とする請求項３５に記載のシステム。
37. 前記差分が、前記ＨＴＴＰプロトコルに対する拡張の形で受信されることを特徴とする請求項３５に記載のシステム。
38. 前記差分が前記プロセッサによって拒絶された場合、前記記憶装置から第２の差分を取り出し、出力装置を介して前記クライアント装置に送信することを特徴とする請求項３５に記載のシステム。
39. 前記第２の差分が第２クライアントから受信されることを特徴とする請求項３８に記載のシステム。
40. 前記ベースファイルが、前記クライアント装置が前記差分を生成するのに使用したクライアントベースファイルと同一である場合、前記差分は、前記格納したベースファイルに適用可能であることを特徴とする請求項３５に記載のシステム。

Images