JP7209067B2 - ストレージ制約付きの同期エンジン - Google Patents

Description

関連出願へのクロスリファレンス

[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]これらの図は説明の目的のためのみに本発明の様々な実施形態を図示するものである。当業者は、以下に示される構成及び方法の他の代替的な実施形態が以下に説明される発明の原理から乖離することなく用いられ得ることを以降の記載から容易に理解する。

＜制約付きの同期の機能概要＞
[0028]制約付きの同期システムの一般的な機能概要と処理を以下で説明する。予備的条件として、ユーザがコンテンツアイテムをクライアントデバイスに格納し、コンテンツアイテムが他のクライアントデバイス上のコンテンツアイテムのインスタンスや、ホストシステム、概してコンテンツ管理システムと同期される。クライアントデバイスは、ローカルコンテンツディレクトリのコンテンツアイテムを格納する。ローカルコンテンツディレクトリに格納されたコンテンツアイテムは、コンテンツ管理システムと同期され、コンテンツアイテムのコピーを保持し、コンテンツアイテムを他のクライアントデバイスと同期する。各クライアントデバイスは、クライアントアプリケーションを実行し、ユーザがコンテンツ管理システムにアクセスすることを可能にする。クライアントアプリケーションは、さらに、ユーザが、最大ストレージの割り当て、又は、ローカルコンテンツディレクトリのサイズを設定することを可能にする。

[0029]一形態において、クライアントデバイスは、クライアントデバイス上においてローカルで利用可能に維持され、かつ、コンテンツ管理システム上のみでそれらの全体が格納される同期されたコンテンツアイテムを選択的に決定するように構成される。一実施形態において、クライアントデバイスは、コンテンツアイテムへアクセスする要求を、例えばコンテンツアイテムへアクセスする必要のあるアプリケーションから受信する。クライアントデバイスは、要求されたコンテンツアイテムが、プレースホルダアイテムであるか、又はクライアントデバイス上にローカルに格納されたコンテンツアイテムであるかを判定する。プレースホルダアイテムは、コンテンツアイテムを表すか、又は実行するアイテムであるが、コンテンツアイテムのアプリケーションデータを含まないものである。一般的に、イメージデータ、ビデオデータ、オーディオデータ、データベーステーブル、スプレッドシートデータ、グラフィックデータ、ソース若しくはオブジェクトコード、又は他のタイプのコンテンツデータなどの実際のアプリケーションコンテンツを格納することなく、プレースホルダアイテムは、コンテンツアイテムの名前などのコンテンツアイテムのメタデータ属性と、コンテンツアイテムの種別、パス情報、アクセス権、変更情報、及びサイズなどの様々な属性とを複製する。プレースホルダアイテムはコンテンツアイテムのメタデータを格納するのみであるため、それらは、数百メガバイト又は数ギガバイトのサイズとなりうるコンテンツアイテムと比較して、少量のストレージ、例えば一般的に約４キロバイトのみを必要とする。したがって、コンテンツアイテムを表すプレースホルダアイテムを使用することは、多量のストレージスペースを節約するように動作し、これによりクライアントデバイスの機能を改善する。

[0030]要求されたコンテンツアイテムがプレースホルダアイテムであるとクライアントデバイスが判定した場合、これは、要求されたコンテンツアイテムが現在クライアントデバイスに格納されていないが、コンテンツ管理システムに格納されていることを示す。従って、クライアントデバイスは、要求したプレースホルダアイテムに対応するコンテンツアイテムをコンテンツ管理システムからダウンロードする。クライアントデバイスはさらに、ローカルコンテンツディレクトリにおいてコンテンツアイテムを格納することが当該ディレクトリのために規定された最大ストレージサイズを超えるかどうかを判定する。この場合、クライアントデバイスは、ローカルコンテンツディレクトリのコンテンツアイテム又はアイテムがローカルコンテンツディレクトリから削除できるか、コンテンツアイテムを表すプレースホルダアイテムと置き換えられるかを判定する。一般に、クライアントデバイスは、クライアントデバイスのユーザ、又はコンテンツ管理システムを介してコンテンツアイテムにアクセスするユーザによって放置されていると判定されたローカルコンテンツディレクトリからコンテンツアイテムを選択するために、クライアントデバイス上の最新のアクセス時刻（例えば、クライアントデバイスのユーザのアクション又はそれ上で実行するアプリケーション）、コンテンツアイテムが共有される他のクライアントデバイス上の最新のアクセス時刻（例えば、それらのクライアントデバイスのユーザのアクション）、コンテンツアイテムのサイズ、及びアクセス頻度を含む、共有コンテンツアイテムの1以上の属性を使用する。これらの要因の組み合わせはまた、放置されたコンテンツアイテムを判定するために使用されてもよい。クライアントデバイスは、ダウンロードしたコンテンツアイテムが最大ストレージサイズを超えることなく、その中に格納すべく、ローカルコンテンツディレクトリのストレージスペースの十分な量を生成するように、これらのコンテンツアイテムを削除する、ローカルコンテンツディレクトリからのコンテンツアイテムの数を選択する。一実施形態において、クライアントデバイスは、共有したコンテンツディレクトリにおいてそれらのコンテンツアイテムによって使用されるストレージの総量がダウンロードしたコンテンツアイテムを格納するのに必要なストレージ量と少なくとも等しいか又は超えるように、コンテンツアイテムの数を選択する。

[0031]クライアントデバイスは、選択したコンテンツアイテムを削除し、削除したコンテンツアイテムのそれぞれについての対応するプレースホルダアイテムを作成する。クライアントデバイスは、削除したコンテンツアイテムに対応するディレクトリの場所にプレースホルダアイテムを格納する。対応する場所へのプレースホルダアイテムの格納は、要求したアプリケーションに見える方法で削除したコンテンツアイテムのその後の検索を可能にする。

[0032]本実施形態は、各クライアントデバイスが他のコンテンツアイテムやアプリケーションについてのより多くのスペースを有する一方で、コンテンツ管理システムで共有された全てのコンテンツアイテムへのアクセスを維持することができ、各クライアントデバイスのストレージ効率やコンテンツ管理システムの全体としてのストレージ効率を改善する、制約付きの共有ストレージシステムを提供する。より具体的には、本実施形態は、クライアントデバイスが実際よりも大容量のストレージ容量を有するかのように、効果的に動作することを可能にする。例えば、ローカルコンテンツディレクトリ用に１０ＧＢのみのストレージ割り当てを有するクライアントデバイスが、当該ディレクトリ用に、有効なストレージとして４００倍の増加となる４，０００ＧＢ（４TB）を超えるストレージ割り当てを有するかのように、動作することができる。従来は、限定されたローカルストレージ容量に対するそのような解決策はネットワークの接続性や帯域幅制限によって不可能であったが、インターネットインフラストラクチャにおける最近の発展の結果としてそのような問題が解決され、広範囲にわたる接続性と、速いアップロード及びダウンロード速度を許容している。

[0033]インターネットインフラストラクチャの最近の発展にもかかわらず、コンテンツアイテムの削除、それらとプレースホルダアイテムとの置換、及びユーザの要求に基づくそれらの復元に必要となる、計算、アップロード及びダウンロード時間は、依然としてデバイス性能に影響を与える可能性がある。従って、従来の共有コンテンツ同期方法におけるクライアントデバイス上のストレージ負荷を低減する一方で、ユーザに見えるようなデバイス性能への影響を低減する代替の実施形態についてもまた説明する。一実施形態において、計算、アップロード、及びダウンロードは、プレースホルダアイテムとして表される共有コンテンツアイテムへの予測されるユーザアクセスに基づいて完了される。コンテンツアイテムへのユーザアクセスを予測するために、クライアントアプリケーション又はコンテンツ管理システムは、各コンテンツアイテムの保存スコアを保持する。ここで、当該保存スコアは、各コンテンツアイテムのユーザに対して予測された重要度の尺度である。各クライアントデバイスは、保存スコアの閾値を有するように構成され、非常に高く予測された重要度（保存スコアの閾値を超える保存スコアによって表される）を有する任意のコンテンツアイテムは対応するクライアントデバイスにダウンロードされる。保存スコアは、最新のアクセス時刻、場所、種別、サイズ、アクセス頻度、共有状況、アクセスを有するアカウント数、アクセスを有するデバイス数、又はコンテンツアイテムを格納するデバイス数を含む種々の属性に基づいて算出されうる。

[0034]代替的に、その他の実施形態は、クライアントデバイスのアクティビティを監視しながら（コンテンツ管理システムによるか、又はクライアントアプリケーションによるか）、クライアントデバイスのストレージ割り当てを超えるクライアントデバイス上の共有コンテンツアイテムによって占有されるストレージスペースを許容する。クライアントデバイスがアイドル状態であると判定されると、クライアントアプリケーションは、クライアントデバイス上に格納されたコンテンツアイテムによって占有される有効なストレージスペースを低減するために、上述したように、コンテンツアイテムを削除し、それらをプレースホルダアイテムと置き換える。それらの実施形態において、ストレージ割り当ては、常には保持されず、即ち、占有されるストレージが他のコンテンツアイテムの属性に従って低減されうる。ストレージ割り当てを維持する代わりに、例えば、クライアントデバイスがアイドル状態である場合にはいつでも、特定の期間（例えば、２週間）より古い最新のアクセスを有する全てのコンテンツアイテムが削除され、プレースホルダアイテムに置き換えられてもよい。当該プロセスは、ストレージ割り当ての下、占有されるストレージスペースを維持しないものの、クライアントデバイスがアイドル状態である、即ち、ユーザによってアクティブに使用されない間は動作が行われるため、ユーザが所望するであろう方法で低減するものであり、これにより、有効なストレージ容量の同様の増加を提供する一方で、上述した実施形態よりも改善されたユーザ経験を提供することによって、制約付きの同期システムを使用するように構成されたクライアントデバイスを改善することができる。

[0035]図１A及び図１Bは、制約付きの同期の実施形態を示す概略図である。図１Aは、ストレージ制約付きの同期フォルダにおいてコンテンツアイテムを保存するプロセスを示す図である。図１Bは、ストレージ制約付きのクライアントデバイス上のプレースホルダアイテムを開くプロセスを示す図である。

[0036]図１A及び図１Bにおいて、クライアントデバイス１００Ａは、コンテンツ管理システム１１０に接続され、同期されうる、複数のユーザ制御デバイスの一つである。コンテンツ管理システム１１０は、ネットワークを用いて複数のクライアントデバイスからのコンテンツを同期するインスタンス化されたサーバである。共有コンテンツストレージディレクトリ１２０は、コンテンツ管理システム１１０と同期されるコンテンツを含むクライアントデバイス１００上に位置するディレクトリである。ストレージ割り当て１３０は、共有コンテンツストレージディレクトリ１２０の全てのコンテンツアイテムに対して許容されるストレージスペースの量を特定するパラメータ値である。ストレージ割り当て１３０は、クライアントデバイス１００Ａのユーザ、クライアントデバイス１００のオペレーティングシステム、コンテンツ管理システム１１０のクライアントアプリケーション、システム管理者、又は、コンテンツ管理システム１１０を設立したポリシーによって設定されうる。ストレージ割り当て１３０の例示の値は１０ＧＢであり、これは、ユーザが共有コンテンツストレージディレクトリ１２０にそれらの全体として（全てのコンテンツアイテムの属性及びデータ）、１０ＧＢのコンテンツアイテムまで格納することができることを意味する。コンテンツアイテム１４０は、共有コンテンツストレージディレクトリ１２０内に保存され、クライアントデバイス１００とコンテンツ管理システム１１０との間の同期後に、共有コンテンツストレージディレクトリ１２０の各コンテンツアイテム１４０のバージョンもまたコンテンツ管理システム１１０によって保持される。

[0037]ここで使用されるように、用語”コンテンツアイテム”は、任意のファイル、ファイルのグループ、又はファイルの集合を示す。単一のファイルのみからなる任意のコンテンツアイテムは、代替的にファイルとして参照されうる。さらに、”ファイルテーブル”などの用語は、個別のファイル又はコンテンツアイテムの量を参照するように使用されてもよい。

[0038]図１において、共有コンテンツストレージディレクトリ１２０は、コンテンツアイテム１４０を含むボックスとして図示されている。ストレージ割り当て１３０は、コンテンツストレージディレクトリ１２０を表すボックスの特定の長さによって表される。

[0039]クライアントデバイス１００Ａ及びコンテンツ管理システム１１０の第１の図示は、２つのエンティティの典型的な状態を表す。クライアントデバイスは、その共有コンテンツストレージディレクトリ１２０内にコンテンツアイテム１４０Ａ、１４０Ｂ、及び１４０Ｃを有する（より少ない数のコンテンツアイテム１４０のみが説明の目的で示されるが、実際には、コンテンツアイテム１４０の数は、数千、数万、又はそれ以上であってもよい）。クライアントデバイス１００Ａと同期されるように、コンテンツ管理システム１１０が表され、そこで、ストレージ割り当て１３０を有していないにもかかわらず、クライアントデバイス１００Ａ上に格納されるコンテンツアイテムのそれぞれの同一バージョンを保持する。さらに、コンテンツ管理システム１１０は、コンテンツアイテム１４０Ａが共有されるその他のクライアントデバイス１００Ｂをサポートする。クライアントデバイス１００Ｂの識別子に関連付けられるコンテンツアイテム１４０Ｄの存在は、クライアントデバイス１００Ｂがまたコンテンツアイテム１４０Ｄをコンテンツ管理システム１１０と同期していることを示す。従って、各クライアントデバイス１００は、コンテンツ管理システム１１０のみと、或いは、コンテンツ管理システム１１０及び他のクライアントデバイス１００と、コンテンツアイテム１４０を同期することができる。

[0040]段階１．１は、コンテンツアイテム１４０Ｅを共有コンテンツストレージディレクトリ１２０に保存するクライアントデバイスAからの要求の動作を示す。しかしながら、図示するように、コンテンツアイテム１４０Ｅの共有コンテンツストレージディレクトリ１２０への追加は、コンテンツアイテム１４０Ｅのサイズがストレージ割り当て１３０によって制限される共有コンテンツストレージディレクトリ１２０の利用可能な残スペースを超えるため、コンテンツアイテム１４０によって占有される総ストレージスペースがストレージ割り当て１３０を超えてしまう。

[0041]段階１．２は、コンテンツアイテム１４０Ｅを格納できる利用可能な十分なストレージを確保するように、クライアントデバイス１００から削除すべき放置されているコンテンツアイテム１４０Ｃの選択の動作を示す。一実施形態によれば、クライアントデバイス１００、又はコンテンツ管理システム１１０の何れかは、何れのコンテンツアイテム１４０を放置されているものとして選択するかを決定する。後述する種々の方法が、何れのコンテンツアイテムが放置されているものとして選択されるかを決定するために使用されうる。本例では単一のコンテンツアイテム１４０Ｃのみが選択される一方で、実際には、利用可能とするべき必要のあるストレージ容量に従って、任意の数のコンテンツアイテム１４０が選択されてもよい。

[0042]段階１．３は、クライアントデバイス１００Ａから選択されたコンテンツアイテム１４０Ｃを削除する動作を示す。各削除されたコンテンツアイテムに代わって、クライアントデバイス１００Ａは、削除されたコンテンツアイテム１４０Ｃを表すプレースホルダアイテム１６０Ｃを作成し、削除されたコンテンツアイテム１４０Ｃと、共有コンテンツストレージディレクトリ１２０の同じ場所にプレースホルダアイテムを格納する。代替的には、コンテンツ管理システム１１０は、プレースホルダアイテム１６０を作成し、その後、プレースホルダファイル１６０Ｃをコンテンツストレージディレクトリ１２０にダウンロードしてもよい。プレースホルダアイテムは、コンテンツ名、パス情報、コンテンツ属性、及びコンテンツサイズなどの削除したコンテンツアイテム１４０Ｃを表す属性を含むが、コンテンツアイテム１４０Ｃの実データは含まない。それらの対応するコンテンツアイテムの実データを含まないことによって、プレースホルダアイテムは、非常に少ないストレージしか必要としない。例えば、プレースホルダアイテムは、一般的には、４ＫＢなどのオペレーティングシステムによって提供される最小のファイルサイズ割り当てしか必要としない。この小さいサイズは、縦線を用いて図１で仮想的に示され、コンテンツアイテム１４０Ｃ自身と比較してプレースホルダアイテムのサイズがごく僅かなサイズであることを示す。例えば、削除したコンテンツアイテム１４０Ｃが数メガバイト又は数ギガバイト（オーディオファイルやビデオファイルで共通する）となる一方で、そのようなコンテンツアイテムを表すプレースホルダアイテムに必要なストレージは、僅か４ＫＢ程度のものである。結果として、クライアントデバイス１００は、共有コンテンツアイテムに使用されるローカルストレージの容量をストレージ割り当て１３０を下回る容量に低減することができ、これにより、新たに作成された（又は、より大きなコンテンツアイテムの新たなバージョンに更新された）コンテンツアイテム１４０Ｅを格納するために利用可能な十分なスペースを確保することができる。選択された（及び削除された）コンテンツアイテムを識別する情報は、クライアントデバイス１００Ａに保持され、それらのアイテムが後に選択的に検索されることを許容する。当該情報は、コンテンツ管理システム１１０のリモートコンテンツアイテムテーブル３６６（図１Ａには不図示であるが、詳細が後述される）にリモートで格納される格納コンテンツアイテムのリスト１５０に、クライアントデバイス１００のローカルに格納される。

[0043]段階１．４は、十分なスペースが共有コンテンツストレージディレクトリ１２０において利用可能にされるとすぐに、クライアントデバイス１００Ａにコンテンツアイテム１４０Ｅを保存する動作を示す。クライアントデバイス１００Ａがコンテンツアイテム１４０Ｅの共有コンテンツストレージディレクトリ１２０への保存を成功するとすぐに、コンテンツ管理システム１１０との同期が開始され、コンテンツアイテム１４０Ｅがコンテンツ管理システム１１０にアップロードされる。コンテンツ管理システム１１０は、クライアントデバイス１００Ａ上の全てのコンテンツアイテム（プレースホルダアイテムを含む）のフルコピーを常に保持する。

[0044]図１Ｂを参照すると、クライアントデバイス１００Ａからコンテンツ管理システム１１０へコンテンツアイテム１４０Ｅが同期された後の、クライアントデバイス１００Ａ及びコンテンツ管理システム１１０が示される。

[0045]段階１．５は、コンテンツアイテム１４０Ｃへのアクセスを要求するクライアントデバイス１００Ａの動作を示す（例えば、ワードプロセッサを使用してコンテンツアイテム１４０Ｃを開くか、又はファイルブラウザでコンテンツアイテムを閲覧する）。ここで、クライアントデバイス１００は、要求したコンテンツアイテムがプレースホルダアイテムによって表されていると判定する。コンテンツアイテムがローカルで格納されている場合、クライアントデバイス１００Ａ上の要求アプリケーションへ提供される。この場合、要求したコンテンツアイテムは、クライアントデバイス１００Ａから削除され、コンテンツ管理システム１１０上にリモートで格納されるのみであり、そこで、クライアントデバイス１００は、コンテンツ管理システム１１０へ、要求したコンテンツアイテムをダウンロードするよう要求する。共有コンテンツストレージディレクトリ１２０に十分なスペースがある場合、コンテンツ管理システム１１０は、要求されたコンテンツアイテムをクライアントデバイス１００Ａにダウンロードし、クライアントは、その後、コンテンツアイテム１４０Ｃ表すプレースホルダアイテム１６０Ｃをコンテンツアイテム１４０Ｃそのものと置き換え、任意の要求アプリケーションがコンテンツアイテムに透過的にアクセスすることを可能にする。しかしながら、この場合、共有コンテンツストレージディレクトリ１２０へのコンテンツアイテム１４０Ｃの追加は、当該共有コンテンツストレージディレクトリ１２０の境界の外側にコンテンツアイテム１４０Ｃが延在して示されるように、ストレージ割り当て１３０を超えることになる。

[0046]段階１．６は、クライアントデバイス１００Ａから削除するために、放置されているコンテンツアイテムを選択する動作を示す。この場合、選択された放置されているコンテンツアイテムは、コンテンツアイテム１４０Ａである。

[0047]段階１．７は、コンテンツアイテム１４０Ａを削除し、それをそのプレースホルダアイテム１６０Ａに置き換える動作を示す。この削除は、ストレージ割り当て１３０を超えることなく、コンテンツ管理システム１１０からダウンロードされ、そのプレースホルダアイテムのレプリゼンテーションに付加されるコンテンツアイテム１４０Ｃのための、共有コンテンツストレージディレクトリ１２０の十分なスペースを創出する。削除されるコンテンツアイテム１４０Ａは、リモートで格納されるコンテンツアイテムのリスト１５０に含められ、共有コンテンツストレージディレクトリ１２０に復元されたため、コンテンツアイテム１４０Ｃはリスト１５０から削除される。

[0048]段階１．８は、コンテンツアイテム１４０Ｃがクライアントデバイス１００Ａに常駐するとすぐに、要求アプリケーションによって開かれうることを示す。クライアントデバイス上で図１Ａ及び図１Ｂに示されるプロセスが完了するとすぐに、通常の同期が、クライアントデバイス１００Ａとコンテンツ管理システム１１０との間で発生し、クライアントデバイス１００Ａ上でのコンテンツアイテム１４０への全ての変更がコンテンツ管理システム１１０上にミラーリングされる。全てのコンテンツアイテム１４０（プレースホルダアイテムによって表される場合であっても）は、それらが共有コンテンツストレージディレクトリ１２０から削除されるまでは、コンテンツ管理システム１１０上に保持される。

＜システムアーキテクチャの概要＞
[0049]図２は、制約付きの同期システムのシステムアーキテクチャを示す図である。各コンポーネントの詳細は後述するが、制約付きの同期の説明を提供すべく、いくつかの要素についてはここで紹介する。さらに、当業者には明らかなように、制約付きの同期に使用される動作および方法は、必然的にコンピュータを必要とし、いかなる実施形態においても、人間の動作による精神的ステップによっては実行されない。さらに、当該動作は情報の記憶及び検索、情報の送受信、又は情報の処理のためのコンピュータの容易さを利用する一方で、当業者は、このような動作が、ここで説明したアルゴリズムを用いて特別に定義したデータに関して特定の方法で実行され、従って、オペレーティングシステム及び標準アプリケーションだけでそのようなコンピュータをネイティブに供給する方法とは異なる方法でコンピュータを構成する必要があるため、単に一般的なコンピュータ動作ではないことを理解する。さらに、当該必要とされる構成は、後述するステップを通じて、従来のオペレーティングシステム及びファイル管理システムで構成された一般的な通常用途のコンピュータを超えて、コンピュータのストレージ容量を強化する。

[0050]クライアントデバイス１００は、コンテンツ管理システム１１０から遠隔に位置するクライアントデバイス１００間のインターネットワーキングを提供する任意の適切な通信手段となりうる、不図示のネットワーク、例えば、LAN、WAN、又はWANを通じて、コンテンツ管理システム１１０と通信する。一般的には、インストールされたクライアントアプリケーション２００Ａを有するクライアントデバイス１００Ａは、コンテンツアイテムをコンテンツ管理システム１１０へ提供する。クライアントアプリケーション２００Ａは、ストレージ制約付きの同期と関連する機能を実行するために、クライアントデバイス１００Ａに必要とされるプログラム及びプロトコルを含む。従って、クライアントデバイス１００Ａは、クライアントアプリケーション２００Ａによって要求されるアクションを頻繁に実行する。しかしながら、クライアントデバイス１００Ａ及びクライアントアプリケーション２００Ａが共に動作するため、説明を容易にするため、それらのいくつかの動作は、動作要素として、”クライアントデバイス１００Ａ”を用いて参照される。クライアントデバイス１００Ａのユーザは、例えば、同一のユーザによって管理されるその他のコンピュータ、又は異なるユーザによって操作されるコンピュータとなりうるクライアントデバイス１００Ｂと共有すべき所定のコンテンツアイテムを指定している。コンテンツ管理システム１１０は、クライアントデバイス１００Ｂに通知し、クライアントデバイス１００Ｂに格納されるローカルコンテンツとしてクライアントデバイス１００Ａから受信した、指定されたコンテンツアイテムを同期する。

[0051]コンテンツ管理システム１１０は、各コンテンツアイテムをコンテンツアイテムの集合に対応するネームスペースに関連付ける。ネームスペースは、所定のコンテンツアイテムが格納されるディレクトリ構造内のディレクトリ（又は、”フォルダ”）を指定する。コンテンツアイテムの特定のネームスペースへの関連付けは、ネームスペーステーブル２２２に格納される。コンテンツ管理システム１１０は、各クライアントを、各ネームスペースにおいてコンテンツアイテムへのアクセス、変更、及び削除を行う特定の権利の識別とともに、アクセスを有するネームスペースに関連付ける。クライアント１００がネームスペースに同期されると、当該クライアントは、ネームスペースに関連付けられるコンテンツアイテムのローカルコピーを格納し、利用可能であればコンテンツの場所に従ってコンテンツアイテムを構造化（organize）する。ユーザは個別のクライアントデバイス１００又は複数のクライアント１００と関連付けられ、例えば、ユーザは、家庭用コンピュータ、作業用コンピュータ、ポータブルコンピュータ、スマートフォン、及びタブレットコンピュータを全て一緒に同期させることができる。コンテンツアイテムを共有するために、ユーザは、他のユーザ及び／又はクライアントと共有すべきネームスペースを指定する。コンテンツ管理システム１１０はその後、共有ネームスペースのコンテンツアイテムを、共有ネームスペースと関連するクライアントに渡って同期する。コンテンツ管理システム１１０に格納されるコンテンツアイテムは、ドキュメント、データ、映画、アプリケーション、コード、画像、音楽などを含む任意のタイプのコンテンツアイテムを含むことができる。コンテンツアイテムはまた、コレクション、プレイリスト、アルバム、ファイルアーカイブなどと共に、コンテンツアイテムをグループ化するフォルダまたは他のメカニズムであってもよい。

[0052]各ユーザは、コンテンツ管理システム１１０上でコンテンツアイテムを格納するために使用されるべきストレージの容量を特定する情報を含む、コンテンツ管理システム１１０上のアカウントに関連付けられる。クライアントデバイスはまた、同期されるコンテンツアイテムを格納するための、共有コンテンツストレージディレクトリ１２０のサイズとなるローカルストレージの指定された容量を有し、当該指定される容量は、上述したストレージ割り当てのパラメータ１３０である。例えば、ユーザアカウントは、ユーザがコンテンツ管理システム１１０上で利用可能な５０ＧＢのストレージを有するように特定してもよいが、１０ＧＢのみのクライアントデバイス１００上のストレージ割り当てを有する。このような状況において、ユーザがローカルに格納された共有コンテンツアイテムを変更すると、当該コンテンツアイテムは、サイズが増加し、これにより、クライアントデバイス１００上のストレージ割り当てを超える可能性もある。同様に、ユーザは、共有コンテンツストレージディレクトリ１２０に、コンテンツ管理システム１１０と共有され、かつ、同期されるべき新なコンテンツアイテムを作成して格納することによって、クライアントデバイス１００上のストレージ割り当てを超えてもよい。これらの場合、クライアントデバイス１００がストレージ制限されており、コンテンツ管理システム１１０によって同期される全てのコンテンツアイテムのローカルコピーをもはや保持できなくなり、共有されるコンテンツアイテムの量が、クライアントデバイス１００用のストレージ割り当てを超える。

[0053]クライアントデバイス１００又はコンテンツ管理システム１１０の何れかは、ローカルストレージから削除するために１以上のコンテンツアイテムを選択するように構成される一方で、それらはコンテンツ管理システム１１０上でリモートに依然保持され、それらはその後に検索され、クライアントデバイス１００に復元されうる。一般的には、選択されたコンテンツアイテムは、コンテンツアイテムへのアクセスの要求を行った特定のクライアントデバイス１００、又は当該コンテンツアイテムが共有される全てのクライアントデバイス１００に渡る何れかで、最後にアクセスされて最も長い時間が経過したものであり、選択の他の方法については後述する。クライアントベースの実施形態において、クライアントアプリケーション２００は、クライアントデバイス１００に格納された各共有コンテンツアイテムに対する最新のアクセスを特定する情報を保持する。ストレージが制限されている場合、クライアントアプリケーション２００は、最後にアクセスされて最も長い時間が経過している１以上のコンテンツアイテム（以下では、”ＬＲＡ”と略記する。）を選択する。ホストベースの実施形態において、コンテンツ管理システム１１０は、全てのコンテンツアイテムについてのアクセスデータを保持し、当該システム１１０は、コンテンツアイテムが共有される任意のクライアントデバイス１００上でコンテンツアイテムがアクセスされると、いつでもこの情報を更新する。ＬＲＡの選択は、多数の可能な放置コンテンツアイテムの選択方法（ここでは、”ＵＣＳＭ”と称する。）のうちの1つに過ぎず、それぞれはホストベース又はクライアントベースのシステムとして実装することができる。任意のＵＣＳＭは、削除するにふさわしいかどうかを判定するために各コンテンツアイテムについてのｖｎｏｄｅリファレンスを調べてもよい。各コンテンツアイテムのｖｎｏｄｅは、コンテンツアイテムへのアクセス数と、コンテンツアイテムが現在使用中又は開かれているかどうかを含む他のコンテンツアイテムの状態指標とに関する情報を含む。

[0054]説明を容易にすべく、ストレージ制限に応じてコンテンツアイテムがクライアントデバイス１００上の常駐から削除するために選択された際には常に、当該動作は、ほとんどのＵＣＳＭがユーザによってアクセスされる可能性が最も低いコンテンツアイテムを特定するように動作するため、”放置コンテンツアイテムを選択する”としてここでは参照される。放置コンテンツアイテムは、以下の説明で概説する任意のＵＣＳＭによって選択されたコンテンツアイテムを参照する。

[0055]基本的なＬＲＡ選択：基本的なＬＲＡ選択を実行するために、クライアントアプリケーション２００は、最後にローカルアクセスされた日付によって順序付けされたコンテンツアイテムのキューであって、当該キューの先頭にアクセスされて最も長い時間が経過したコンテンツアイテムがくるキューを保持する。各コンテンツアイテムの最後にアクセスされた日時は、コンテンツアクセス履歴テーブルに保持される。コンテンツアイテムへのアクセスは、コンテンツアイテムの作成、開く、プレビュー、又は変更を行う動作を含む。任意の数のそれらの動作が、アクセスとみなされ、例えば、本実施形態では、コンテンツアイテムを開く、変更する、又は保存するの何れかをアクセスとみなす一方で、コンテンツアイテムのプレビューはアクセスとみなさなくてもよい。ストレージサイズの累積合計（例えば、現在までの合計）は、キューに特定された、最後にアクセスされて最も長い時間が経過したコンテンツアイテム（即ち、キューの先頭のコンテンツアイテム）から開始して、キューの最後に位置するコンテンツアイテムまでのキューにリストされた各コンテンツアイテムについて算出される。ストレージが制限されている場合、クライアントアプリケーション２００は、コンテンツアイテムを格納するのに必要なストレージスペースの容量を判定し、従って、累積ストレージサイズがストレージスペース要件を超えるコンテンツアイテムのインデックスを特定するためにキューを進ませる。特定したインデックスは、上述した、クライアントデバイス１００上の共有コンテンツストレージディレクトリ１２０から削除するキューの当該インデックスを含む、全てのコンテンツアイテムを選択するために使用される。

[0056]これらの処理は表１でさらに説明する。本例において、７５ＭＢのストレージがコンテンツアイテムを格納するために必要とされる。コンテンツアイテムＡ及びＢのトータルが７０ＭＢしかないため、それらの２つのコンテンツアイテムの削除は当該アイテムについての十分な量のストレージを提供することはできない。従って、トータルの累積サイズが１５０ＭＢとなるコンテンツアイテムＡ、Ｂ及びＣが、（最右列の指定によって示されるように）対応するインデックス００、０１、及び０２で選択される。

[0057]リモートLRA選択：ＬＲＡ選択はまた、コンテンツ管理システム１１０を通じて、それ上で直接的な、又は、当該コンテンツアイテムのバージョンを共有しているクライアントデバイス１００上での、コンテンツアイテムへのアクセスを有する他のユーザによるリモートアクセスに基づくことができる。これを達成するために、一実施形態において、各クライアントデバイス１００は、例えば通常のコンテンツアイテムの同期操作のとき又は他のときに、それ自身のコンテンツアクセス履歴テーブルをコンテンツ管理システム１１０と同期する。この実施形態は、各クライアントデバイス１００が、任意の他のクライアントデバイスと共有する全てのコンテンツアイテムについての現在のアクセス情報を保持することを可能にする。或いは、ホストベースの実施形態では、コンテンツ管理システム１１０は、同期及び共有するように指定された全てのクライアントデバイスに渡って各コンテンツアイテムについてのアクセス履歴を含むコンテンツアクセス履歴テーブルを保持してもよく、それにより、ＬＲＡ選択で使用するために現状更新されたリストを有する。従って、リモートＬＲＡ選択は、コンテンツ管理システム１１０が、累積ストレージサイズが必要なストレージスペースを超える、最後にアクセスされて最も長い時間が経過したコンテンツアイテムを選択することを含む。この実施形態において、当該キューは、コンテンツアイテムに関して同期される全てのクライアントデバイスからの最新のアクセス時刻によって順序付けられる。

[0058]表２は、リモートLRAがどのように実装されうるかの一例である。本例において、コンテンツアイテムＢ及びＣは、異なるクライアントデバイス上で、それぞれ２０１４／５／２４と２０１４／４／５において最後にリモートにアクセスされているが、（表１に記載するように）両方とも２０１４／３／２４において最後にローカルにアクセスされている。それらのリモートアクセスに起因するアイテムＢ及びＣについての最新アクセスの日付の変更は、基本的なLRAの選択が使用される場合と比較して、キューの中でそれらをさらに遠くに移動させる。結果として、本例において、アイテムＡ及びＤがＡ、Ｂ及びＣの代わりに選択される。

[0059]コンテンツアイテムのサイズ選択：削除するコンテンツアイテムを選択するために使用されうる他の要因は、それらのサイズである。一実施形態において、サイズは、削除され、かつ、クライアントデバイス１００から遠隔に格納されるコンテンツアイテムの数を最小化するために使用される。これは、アクセスした日付の代わりに、サイズによるキューの順序付け（最小から最大）によって達成しうる。次に、必要なストレージスペースの値は、必要なストレージスペースを超えるサイズを有するコンテンツアイテムが特定されるまで、個々のサイズと比較されうる。クライアントアプリケーション２００はその後、削除する当該コンテンツアイテムを選択するであろう。必要なストレージスペースよりも大きい単一のコンテンツアイテムがない場合には、最大のコンテンツアイテムが選択され、そのサイズは必要なストレージスペースの値から差し引かれ、当該処理はキューの初めから繰り返される。

[0060]表３は、当該選択方法の一例である。本例では、４０ＭＢのストレージがコンテンツアイテムを格納するために必要とされる。アイテムＢが４０ＭＢの必要なストレージ値を超える、キューインデックスによる第１のコンテンツアイテムであるため、クライアント１００から削除するように選択される。

[0061]コンテンツアイテムサイズ及びアクセス時刻に基づく選択：上記説明したサイズ選択方法は、削除用に頻繁にアクセスされたコンテンツアイテムを選択することがある。サイズ及びアクセス時刻の両方を考慮に入れることによって、コンテンツ管理システムは、近い将来ユーザによって要求されうるコンテンツアイテムをクライアントデバイス１００から削除することを回避することができる。一実施形態において、この二変数による選択方法は、必要なストレージ割り当てに達するのに寄与する各コンテンツアイテムのストレージ量と、その最新アクセス日時とに基づいて、各コンテンツアイテムの重み付けスコアを算出することによって達成される。例えば、
Score = w₁S+w₂Ａ
ここで、Ｓはコンテンツアイテムのサイズを表すメトリックであり、Ａはコンテンツアイテムに最後にアクセスしてからの時間を表すメトリックであり、ｗ_１及びｗ_２は重みである。Ａ及びＳへの重み付けは、ユーザによって決定されるように、それらの相対的な重要度に基づくことができ、或いは、特定のクライアントデバイス１００上のコンテンツアイテムに対するアクセスパターンを示す履歴コンテンツアイテムに基づくことができる。その後、キューはスコアによって順序付けされ、キューの最初のコンテンツアイテムは削除用に選択される。

[0062]本実施形態の方法の一実施例を以下の表４に示す。例示の説明を容易にするため、アクセス時刻のメトリックＡは、現在時刻及び特定のコンテンツアイテムに対する最新のアクセス時刻の差分と、現在時刻及び最後にアクセスされたアイテムの時刻（ここでは、最後に使用されたのは2014/9/3）の差分との比率である。本例において、サイズメトリックは以下の関係を有する。
For s＞＝r: S= r/s
For s＜r: S=s²/r²
ここで、ｓはコンテンツのアイテムサイズであり、ｒは必要なストレージスペースであり、Ｓはサイズメトリックである。この区分的関数はｓ＝ｒのときに最大１を有する。

[0063]表4に表示される例では、必要なストレージスペースは４０ＭＢであり、重みｗ１及びｗ２は両方１である。サイズメトリック及びアクセス時刻のメトリックが計算され、その後、各コンテンツアイテムの合計スコアを計算するために使用される。本例において、アイテムＢは最も高いスコアを有し、クライアントデバイス１００からの削除用に選択される。選択されたコンテンツアイテムが必要なストレージスペースよりも小さいサイズである場合、新たに必要なストレージスペースが古いストレージスペースと最初に選択したコンテンツアイテムのサイズとの差分として計算され、当該スコアは再計算され、新たなキューが、新たに算出された必要なストレージスペースを用いて全てのコンテンツアイテムに対して生成され、選択処理が繰り返される。

[0064]アクセス頻度及び最新の選択放置コンテンツアイテムをよりよく選択するために、頻度などの他の要因がアクセス時刻に加えて考慮されうる。高頻度で低リセンシーのコンテンツアイテムは、過去（6か月以上前）に頻繁に選択されたコンテンツアイテムであるが、最近は選択されておらず、低頻度で低リセンシーのコンテンツアイテムは頻繁にアクセスされたことのないコンテンツアイテムである。アクセスの頻度は、特定のクライアントデバイス若しくは複数のクライアントデバイスの任意の集合での平均頻度、種別、ネームスペース、ソースドメイン、又は他のコンテンツアイテムの属性に関連して測定されうる。例えば、コンテンツアイテムが最近4か月でクライアントデバイス上でアクセスされていないが当該時刻前に25回アクセスされている場合、過去に1回しかアクセスがなく類似のリセンシーであるコンテンツアイテムよりもユーザにより関連がある可能性がある。

[0065]一実施形態において、各コンテンツアイテムへの最新のアクセスに加えて、各コンテンツアイテムに対するアクセス数が（クライアントデバイス１００又はコンテンツ管理システム１１０のいずれかで）保持される。スコアは、それぞれの変数を表すメトリクスの重み付けの組合せとして各コンテンツアイテムについて決定される。例えば、各コンテンツアイテムについての重み付けスコアは、コンテンツアイテムのアクセス頻度及びその最新のアクセス日に基づく。例えば、
Score = w₁F+w₂Ａ
ここで、Ｆはアクセス頻度を表すメトリックであり、Ａは最後にコンテンツアイテムにアクセスしてからの時間を表すメトリックであり。ｗ_１及びｗ_２は重みである。ＡおよびFの重みは、ユーザによって、システム管理者によって、又は特定のクライアントデバイス１００上のコンテンツアイテムの履歴コンテンツアイテムアクセスパターンに基づいて決定されるような、それらの相対的重要度に基づくことができる。キューはその後、スコアによって順序付けされる。累積和は各インデックスで計算され、必要なストレージスペースと比較される。必要なストレージスペースが累積和によって超されると、キュー内のインデックス及び上記当該インデックスの全てのコンテンツアイテムがクライアントデバイス１００からの削除用に選択される。

[0066]表５は本選択方法の一例である。本例において、必要なストレージスペースは４０ＭＢであり、重みｗ_１及びｗ_２は両方１である。当該キューはトータルスコアによって順序付けされ、累積和が必要なストレージスペースと比較される。これは、クライアントデバイス１００からの削除用に選択されたアイテムＣ及びＥの結果となる。

[0067]上記ＵＳＣＭの何れも、単一の個別のファイルの代わりに単一のキューインデックス内の全体のフォルダを考慮してもよい。例えば、LRA UCSMが使用され、フォルダに複数のファイルが含まれている場合、そのフォルダ内の最近アクセスされたファイルは、共有コンテンツディレクトリ内の他のすべてのコンテンツアイテムより以前のアクセス日時を有するため、（特にかなりのストレージスペースが必要な場合は）放置されているフォルダ全体を選択することがより効果的であろう。或いは、フォルダについて組み合わされたメトリックは、フォルダ内のコンテンツアイテムを一般化してキューへ配置することを可能にする、平均値、中央値、又は他の統計値であってもよい。

[0068]以下で記載するように、前述の方法の何れかが、クライアントデバイス１００から削除するための放置コンテンツアイテムを選択するために使用されてもよい。放置コンテンツアイテムを選択する当該プロセスは、制約付きのコンテンツ管理システム１００によって提供されるように、クライアントデバイス上で強化されたストレージ容量を可能にする。

＜コンテンツ管理システムの概要＞
[0069]クライアントデバイス１００Ａ及び１００Ｂ間でコンテンツ管理システム１１０を用いる同期方法は、図２によって示されるアーキテクチャを参照して説明されうる。ストレージ制約付きの同期に使用されうる、多数の可能な同期方法の１つを以下で説明する。

[0070]コンテンツ管理システム１１０は、データストア２１８にコンテンツアイテムを格納する。コンテンツアイテムは、ブロックと呼ばれる固定サイズの部分に格納される。ブロックのサイズ実装に従って変化し、一実施形態においては、ブロックは４メガバイトのサイズである。従って、小さいサイズのコンテンツアイテムは、単一のブロックに格納される一方で、大きいサイズのコンテンツアイテムは、コンテンツ管理システム１１０のストレージについて、数十、数百、又はそれ以上のブロックに分割されて格納されうる。メタデータはコンテンツアイテムの複数のブロック及びコンテンツアイテムにおけるブロックの順序を定義するブロックリストを含む。

[0071]保留ブロックテーブル２２０は、コンテンツ管理システムで受信されることが予期される保留ブロックのリストを保持する。保留ブロックテーブル２２０は、複数のブロック（ブロック識別子によって識別される）と、クライアント１００が示す送信されるブロックが属するネームスペースとの関連付けを格納する。

[0072]ネームスペーステーブル２２２は、個別のコンテンツアイテムをネームスペースに関連付けるデータを格納し、各ネームスペースをクライアントに関連付けるデータを保持する。

[0073]メタデータサーバ２１２は、新たなコンテンツアイテムをコンテンツ管理システムへ追加する（”コミットする（commit）”）クライアントからの要求を管理する責任を負う。メタデータサーバ２１２はまた、コンテンツアイテムを同期する要求をクライアントデバイス１００から受信する。メタデータサーバ２１２は、クライアントデバイス１００がコンテンツ管理システム１１０と同期された最新時刻の記録を保持する。クライアントデバイス１００から同期する要求が受信されると、メタデータサーバ２１２は、最新の同期時刻スタンプ以後に、当該クライアントデバイス１００へ同期されたネームスペースにコミットされている任意のコンテンツアイテムを判定する。さらに、メタデータサーバ２１２は、最新の同期時刻スタンプ以後に、受信された任意の保留ブロックを判定する。

[0074]通知サーバ２１６は、クライアント１００との通信を行い、特に、新たなデータが利用可能であることをクライアントへ通知する。通知サーバ２１６は、ネームスペーステーブル２２２で各ネームスペースに関連付けられるクライアント１１０のリストを保持する。通知サーバ２１６が、新たなブロックが所定のネームスペースについて利用可能であるというアラートをブロックサーバ２１４又はメタデータサーバ２１２から受信すると、当該通知サーバ２１６は、ネームスペーステーブル２１２から当該ネームスペースと関連付けられるクライアントを特定する。通知サーバ２１６は、ネームスペースに関連付けられたクライアント１００に当該クライアント１００を活動させるように通知し、新たなブロックが特定したネームスペースについて利用可能であることを示す。

[0075]２つのクライアント１００、クライアント１００Ａ及びクライアント１００Ｂの間の通常の同期は以下のように発生する。まず、クライアントデバイス１００Ａが共有データに追加のコンテンツアイテムを追加する。追加のコンテンツアイテムはその後、コンテンツ管理システム１１０へ送信される。コンテンツ管理システム１１０は、追加のコンテンツアイテムが共有データにあることをクライアントデバイス１００Ｂに通知し、クライアントデバイス１００Ｂは、コンテンツ管理システム１１０から追加のコンテンツアイテムをクライアントデバイス１００Ｂとして取り出す。コンテンツ管理システム１１０は、コンテンツアイテムと、保留ブロックテーブル２２０を用いてコンテンツ管理システム１１０で受信されることが予期される保留ブロックとのリストを保持し、クライアントデバイス１００Ｂにコンテンツ管理システム１１０によって受信されるブロックとしてコンテンツアイテムに対応するブロックをダウンロードするように通知する。保留ブロックは、コンテンツ管理システム１１０によって受信されることが予期されるコンテンツアイテムに対応するそれらのブロックであり、コンテンツアイテムがコンテンツ管理システム１１０にコミットされる前に、クライアントデバイス１００Ｂに受信するために提供されうるブロックを特定するために使用される。

[0076]転送中のコンテンツアイテムを管理するために、コンテンツ管理システム１１０は、保留ブロックに関連付けられるネームスペースとともに、保留ブロックのリストを保有する。保留ブロックが受信されると、ネームスペースに関連付けられるクライアントに通知され、受信されたブロックについての転送を開始することができる。従って、アップロードするクライアント（新たなコンテンツアイテムを提供する）と、ダウンロードするクライアント（新たなコンテンツアイテムを受信する）は、コンテンツ管理システム１１０に対して非同期でブロックを転送する。

＜クライアントデバイスの概要＞
[0077]各クライアントデバイス１００は、デスクトップ、ラップトップ、タブレット、モバイルデバイス、又は、コンテンツ管理システム１１０及びインストールされたクライアントアプリケーション２００を用いる他のクライアントと同期される共有データのローカルコピーを保持する他のシステムなどのコンピューティングデバイスである。共有データは、単一のユーザに関連付けられるクライアントのみと同期されてもよく、複数のユーザと関連付けられるクライアントと同期されてもよい。クライアントデバイス１００は、図３に関してさらに説明されるように、共有データを扱い、当該データを追加するためのモジュール及びアプリケーションを含む。

[0078]図３は、クライアントアプリケーション２００のモジュールを示す。クライアントアプリケーション２００は、種々のモジュールと、コンテンツ管理システム１１０とデータを同期するためのデータストアを含む。クライアントアプリケーション２００は、コンテンツ同期モジュール３１０、ハッシングモジュール３２０、ダウンロードモジュール３３０、アップロードモジュール３４０、及びストレージ管理モジュール３５０を含む。さらに、クライアントアプリケーション２００は、ファイルジャーナル３６０、常駐ファイルテーブル３６２、共有データ３６４、リモートファイルテーブル３６６、構成ファイル３６８、及びブロックキャッシュ３７０を含むデータストアを保持する。クライアントアプリケーション２００に追加して、図３はまた、クライアントデバイスのオペレーティングシステム上に存在するストレージカーネル拡張部３８４を示す。クライアントアプリケーション２００と、特定のコンピュータとしてモジュールインスタンスのクライアントアプリケーション２００を用いる、その関連するカーネル拡張部とは、ここで説明する機能を実行することができ、クライアントデバイスのストレージ容量及び機能性能の説明される改善を可能にする。

[0079]共有データ３６４はコンテンツ管理システム１１０で同期されているデータであり、コンテンツ管理システム１１０から受信したコンテンツアイテムを含む。ユーザが共有データ３６４内のコンテンツアイテムを追加、修正又は削除すると、それらの変更はコンテンツ管理システム１１０と同期される。ハッシングモジュール３２０及びブロックキャッシュ３７０は、コンテンツ管理システム１１０へアップロードされるコンテンツアイテムを含むブロックを特定するように作動する。ハッシングモジュールは、MD5又はSHA-1などの任意の適切なハッシングアルゴリズムを実行することによってブロック識別子を割り当てる。コンテンツ同期モジュール３１０はその後、ブロックキャッシュ３７０内に位置する常駐ブロックと、コンテンツ管理システム１１０によって保持されるブロックとを比較するために、それらの識別子を使用する。それらのモジュールは、ここでの実施形態に存在するものの、このブロックの実装は、ストレージ制約付きの同期の本発明に必ずしも必須のものではない。

[0080]クライアントアプリケーション２００内で、クライアントデバイス１００上の共有データ３６４のデータが修正されるか又は共有データ３６４へデータが追加されると、共有データ３６４への修正は、コンテンツ管理システム１１０へ送信される。クライアントデバイス１００はまた、コンテンツ管理システム１１０からの通知を受信するように構成される。クライアントデバイス１００は通知を受信すると、クライアントデバイス１００は、共有データ３６４への修正についてコンテンツ管理システム１１０に問い合わせる。共有データが修正されると、クライアントデバイス１００は、クライアントデバイス１００上で共有データを格納するためにコンテンツ管理システム１１０からの修正を要求する。いくつかのケースにおいて、修正したデータは、プレースホルダアイテムによって表されるコンテンツアイテムと関連付けられてもよい。この場合、クライアントデバイス１００は、プレースホルダアイテムによって表されるコンテンツアイテムへのアクセスがクライアントデバイス１００上のアプリケーションによって要求されるまで、コンテンツ管理システム１１０からの修正データの要求を保留してもよい。或いは、共有コンテンツアイテムがその他のクライアントデバイス１００によって修正されると、コンテンツ管理システム１１０は、制約付きのクライアントデバイス１００がプレースホルダアイテムによって表されるコンテンツアイテムを復元するよう要求してもよく、その結果、当該修正が制約付きのクライアントに常駐する他のコンテンツアイテムを犠牲にして同期されうる。

[0081]クライアントアプリケーション２００内において、ファイルジャーナル３６０は、クライアントアプリケーション２００を使用してアカウントにアクセス可能な全てのコンテンツアイテムのメタデータをリストしたテーブルを格納する。メタデータは、リビジョン日時と、ネームスペースと、各コンテンツアイテムに対応するブロックリストとを含む。常駐していない又は同期していないコンテンツアイテムが、依然としてファイルジャーナル３６０に含まれている。

[0082]常駐ファイルテーブル３６２は、ストレージ制限に関わらず、クライアントデバイス１００に常駐するファイルのリストを格納する。

[0083]リモートファイルテーブル３６６は、クライアントデバイスから削除されてプレースホルダアイテムに置き換えられるように選択されたファイルのリストを格納する。それらのファイルは、コンテンツ管理システム１１０によって、他のユーザが当該ファイルにアクセス可能に保持されるのみである。

[0084]構成ファイル３６８は、クライアントアプリケーション２００によって保持されるファイルであり、クライアントデバイスにおけるストレージ割り当て１２０を含む。いくつかの実施形態において、ストレージ割り当て１２０は、ユーザによって、又は、クライアントアプリケーション２００を介した制御を有するコンピュータシステムによって作成されうる。例えば、オペレーティングシステムは、ストレージ割り当て１２０を変更して、他のアプリケーションによって使用される十分なストレージ容量を維持するようにしてもよい。

[0085]ストレージカーネル拡張部３８４は、コンテンツアイテムへアクセスするための、アプリケーションからオペレーティングシステム３８０への要求を監視し、要求されたコンテンツアイテムがプレースホルダアイテムであるかどうかを判定するように構成され、当該機能を実行するための一手段である。ストレージカーネル拡張部３８４は、直接的な修正を、クライアントデバイス上の有効なストレージ容量の増大を可能にするように、オペレーティングシステムの構造及び機能に制定する。

[0086]カーネル拡張部３８４は、クライアントアプリケーション２００によって管理されるコンテンツアイテムを開かせる要求を監視する。カーネル拡張部３８４は、オペレーティングシステム３８０上のファイルシステム３８２監視することによって、クライアントアプリケーション２００によって管理されるコンテンツアイテムを開かせる要求がいつ行われるかを判定する。コンテンツアイテムへの要求がファイルシステム３８２内で行われると、カーネル拡張部３８４は、共有コンテンツストレージディレクトリ１２０内に格納されるコンテンツアイテム内であるかどうかを判定するために、コンテンツアイテムのパス名を調べる。

[0087]カーネル拡張部３８４は、そのサイズが閾値サイズより下であるかどうかを判定することによって、要求されたコンテンツアイテムがプレースホルダアイテムであるかどうかを判定する或いは、プレースホルダアイテムの特定は、クライアントアプリケーション２００によって管理されるコンテンツアイテムについての拡張されたファイル属性に基づいて達成されうる。カーネル拡張部が要求されたコンテンツアイテムのサイズを調べることなくプレースホルダアイテムを特定することができるように、プレースホルダアイテムを示すファイル属性がプレースホルダアイテムに割り当てられてもよい。カーネル拡張部３８４によって当該ファイルがプレースホルダアイテムであると判定されると、カーネル拡張部は、クライアントアプリケーション２００へ識別情報を通知する。

[0088]図４は、クライアントデバイス１００に常駐していないものの、コンテンツアイテムがクライアントデバイス１００へ常駐していたかのようにファイルシステムに含まれる、コンテンツアイテムへアクセスするための処理の一実施形態を示す相互作用図である。ファイルシステム３８２は、クライアントデバイス１００上の同期されるフォルダ内のコンテンツアイテムを開く要求を受信する（４００）。当該要求は、ファイルエクスプローラ、ワードプロセッサ、ドキュメントリーダ、画像編集などの任意のアプリケーションからであってもよい。ストレージカーネル拡張部３８４は、そのようなファイルシステムの要求を傍受し、要求されたコンテンツアイテムのパス名を取得する（４０２）。ストレージカーネル拡張部３８４は、コンテンツアイテムがプレースホルダアイテムであるかどうかを判定する（４０４）ためにパスネームを使用する。ストレージカーネル拡張部３８４は、所定の閾値を下回るかどうか、さもなければ、シャドウアイテムのサイズ（４KB）に一致するかどうかを判定するために、要求されたコンテンツアイテムのサイズを確認することによって、プレースホルダアイテムであるかどうかを判定してもよい。或いは、ストレージカーネル拡張部３８４は、コンテンツアイテムがプレースホルダアイテムであるか又は通常のコンテンツアイテムであるかどうかを示す値を格納するファイル属性拡張情報を読み込むことができる。コンテンツアイテムがプレースホルダアイテムでなければ、その結果、ストレージカーネル拡張部３８４は、通常通り当該要求を継続することを許容し、ファイルハンドルをファイルシステムへ与え、それによりコンテンツアイテムが開かれる。

[0089]コンテンツアイテムがプレースホルダアイテムであると判定すると、ストレージカーネル拡張部３８４は、要求識別子番号（要求種別を含む当該要求についての情報）と、ストレージ管理モジュール３５０へのファイルパスとを送信し（４０６）、ファイル名を渡す。ストレージ管理システム３５０は、リモートファイルテーブル３６６からファイル名を削除する（４０８）。ストレージ管理システム３５０はその後、コンテンツアイテムからの同期を必要とするコンテンツアイテムを確認するダウンロードスレッドを作動する（４１２）。要求されたコンテンツアイテムがリモートファイルテーブル４０８から削除されるとすぐに、ダウンロードスレッドは、ダウンロードに備えて要求されたコンテンツアイテムのサイズを含む、コンテンツ管理システム１１０からのコンテンツ情報を要求することができる（４１４）。ストレージ管理モジュール３５０は、サイズ情報をコンテンツ管理システム１１０から受信し（４１６）、クライアントデバイス１００上にコンテンツアイテムを格納することが所定のストレージ制限を超過するかどうかを判定する（４１８）。要求されたコンテンツアイテムの追加によってストレージ制限を超過する場合、ストレージ管理モジュール３５０は、削除用にクライアントデバイス１００上に格納された１以上のコンテンツアイテムを選択する（４２２）。しかしながら、ストレージ制限を超過しなければ、ストレージ管理モジュール３５０は、コンテンツアイテムをダウンロードする（４３０）処理に進む。

[0090]ストレージ割り当て１３０が要求されたコンテンツアイテムを共有コンテンツストレージディレクトリ１２０へ追加することによって超過する場合、ストレージ管理モジュール３５０は、ダウンロード（４３０）を要求する前に、要求されたコンテンツアイテムについて利用可能な十分なストレージスペースを確保するように、移動する１以上のコンテンツアイテムを選択し、これにより、共有コンテンツストレージディレクトリ１２０がその割り当てられたスペースより大きく占有されることを防ぐことができる。ストレージ管理モジュール３５０は、上述した任意のUCSMを用いて、放置コンテンツアイテムをまず判定する（４２０）ことによって、削除するコンテンツアイテムを選択する（４２２）。特定のコンテンツアイテムのアクセス履歴又は各選択方法に関連する他の情報がホストシステムに格納される場合、当該情報のクライアントアプリケーション３００のバージョンを更新するために要求がホストシステムへ行われる（図４では不図示）。コンテンツ管理システム１１０の各コンテンツアイテムについての、アクセス履歴の現在のバージョン又は任意の他の必要な情報が取得されるとすぐに、ストレージ管理モジュール３５０は、放置コンテンツアイテムを判定することができる（４２０）。

[0091]ストレージ管理モジュールはその後、クライアントデバイスから削除する放置コンテンツアイテムを選択する（４２２）。本実施形態において、削除するコンテンツアイテムを選択するために（４２２）、ストレージ管理モジュール３５０は、ダウンロードする要求されたコンテンツアイテムのサイズと少なくとも同等のストレージスペースを作成するための使用において、USCMによって生成されるキューを詳細に検討する。削除用の放置コンテンツアイテムの選択は、上述の任意の方法を用いて行われうる。

[0092]ストレージ管理モジュール３５０はその後、選択したコンテンツアイテムの名前をリモートファイルテーブル３６６に追加する。当該追加（４２４）が完了すると（４２６）すぐに、ストレージ管理モジュール３５０は、選択したコンテンツアイテムを共有コンテンツストレージディレクトリ１２０から削除し（４２８）、その後、それぞれの削除したコンテンツアイテムについて、削除したコンテンツアイテムと同じメタデータ及び場所を有するがコンテンツアイテムについてのコンテンツ情報を含まない、対応するプレースホルダアイテムを作成する。プレースホルダアイテムは、それらが依然としてクライアントデバイス１００上に常駐しているかのように、クライアントのユーザインタフェースに表されてもよい。図８は、クライアントデバイス１００のユーザインタフェースにおいて、どのようにプレースホルダアイテム表されるかを示す図である。

[0093]選択されたコンテンツアイテムが削除されると、クライアントデバイス１００上には十分なストレージスペースができ、要求されたコンテンツアイテムが、共有コンテンツストレージディレクトリ１２０のストレージ制限を超えることなくコンテンツ管理システム１１０からダウンロードされうる。従って、ストレージ管理モジュール３５０は、ダウンロードリクエスト４３０をダウンロードモジュール３３０へ送信する。ダウンロードモジュール３３０はその後、コンテンツ管理システム１１０とダウンロード（４３２）を開始する。コンテンツアイテムがダウンロードモジュール３３０にダウンロードされる（４３４）と、ストレージ管理モジュール３５０に渡され（４３６）、要求したコンテンツアイテムを前回の特定した場所に保存（４３８）し、ストレージカーネル拡張部３８４にダウンロードが完了したことを通知する（４４０）。一実施形態において、ストレージ管理モジュール３５０は、ダウンロードされたコンテンツアイテムの内容をプレースホルダアイテムのメタデータに付与し、コンテンツアイテムがもはやプレースホルダアイテムでないことを示すようにコンテンツアイテムの属性を更新する。これは、要求アプリケーションが、コンテンツアイテムへのアクセスを最初に要求するのに使用された同じファイルハンドル及び識別情報を用いて、要求したコンテンツアイテムに対して透過的にアクセスすることを可能とする。ストレージカーネル拡張部３８４はその後、ファイルシステム３８２へのファイルハンドル（４４２）を通し、要求アプリケーションがコンテンツアイテムを開く（４４４）ことを許可する。

[0094]図５は、ストレージ割り当て１３０に近づくように、コンテンツアイテムを共有コンテンツストレージディレクトリ１２０に保存する処理の一実施形態を示す相互作用図である。当該コンテンツアイテムは共有コンテンツストレージディレクトリ１２０内に新たに作成したコンテンツアイテム、共有コンテンツストレージディレクトリ１２０へ再配置されているコンテンツアイテム、又は、共有コンテンツストレージディレクトリ１２０に既にあり、そのサイズを増大するような方法で修正されたコンテンツアイテムであってもよい。当該プロセスは、アプリケーションがオペレーティングシステムのファイルシステム３８２へ同期フォルダ内のコンテンツアイテムを保存する要求を行う（５００）ことにより開始される。ストレージカーネル拡張部３８４は、この要求を監視し、ファイルシステムから要求ＩＤ、ファイルパス及びサイズを受信する（５０２）。ストレージカーネル拡張部３８４はその後、当該情報をストレージ管理モジュール３５０に送信する（５０４）。ストレージ管理モジュールは、新たなコンテンツアイテムの追加が同期フォルダのストレージ制限を超過させるかどうかを判定する（５０６）。ストレージ制限を超過しない場合は、ファイルシステム３８２は、コンテンツアイテムを通常通り保存することを許容する。ストレージ制限を超過する場合、ストレージ管理モジュール３５０は、放置コンテンツアイテムを判定し（５０８）、クライアントデバイスから削除するコンテンツアイテムとして選択する。放置コンテンツアイテムが選択されると、それらの名前がリモートファイルテーブル３６６に追加され（５１２）、これにより、コンテンツ管理システム１１０によってコンテンツが同期されなくなる。ストレージ管理モジュールはその後、クライアントデバイス１００から選択したコンテンツアイテムを削除し、削除したコンテンツアイテムと同じメタデータ及び場所を有するが内容は含まないプレースホルダアイテムと置き換える（５１４）。当該プロセスが完了すると、オリジナルのコンテンツアイテムが保存できるように、ストレージ管理モジュールにおける制限フォルダ内に十分なストレージスペースが存在することになる（５１６）。ストレージ管理モジュールその後、アップロードスレッドを起動し（５１８）、メタデータにアクセスする（５２０）ことにより、保存されたコンテンツアイテムの内容がコンテンツ管理システム１１０にアップロードされる（５２２）。

[0095]コンテンツアイテムを自動的に削除してプレースホルダアイテムを作成することに加えて、いくつかの実施形態はまた、ユーザに対して、コンテンツ管理システム１１０にリモートでのみ格納される特定のコンテンツアイテムを選択することを許容する。これは、ユーザが特定の同期したコンテンツアイテム上でコンテキストメニュー（例えば、”右クリック”）から選択することを単に許容することによって実施されてもよい。クライアントアプリケーション２００はその後、選択したコンテンツアイテムをリモートにするオプションをユーザに提示する。ユーザが当該オプションを選択すると、コンテンツアイテムがクライアントデバイス１００から削除され、コンテンツアイテムの名前がリモートファイルテーブル３６６に追加され、オリジナルのコンテンツアイテムと同じメタデータ及び場所を有するプレースホルダアイテムがオリジナルのコンテンツアイテムを表すように作成される。ユーザがその後コンテンツアイテムへのアクセスを望む場合、図５に示したのと同じプロセスがコンテンツ管理システム１１０からコンテンツアイテムを取り出すために使用されてもよい。

[0096]いくつかの実施形態において、実際にUCSMがクライアントデバイス１００から削除するコンテンツアイテムを選択するかどうかに関わらず、ストレージ割り当て１３０に到達すると、ユーザがクライアントデバイスでの常駐を維持する特定のコンテンツアイテムを選択することを可能にするようにクライアントデバイスは構成される。本実施形態は、ユーザが特定の重要なコンテンツアイテムへの迅速なアクセスを維持することを許容する動作上の改良を提供する。本実施形態において、クライアントアプリケーション２００は、ユーザがコンテキストメニューにアクセスし、その後、クライアントデバイス１００上に常駐することを維持するコンテンツアイテムを強制するオプションを選択することを可能にする。選択されると、コンテンツアイテムの名前が常駐ファイルテーブル３６２に加えられる。常駐ファイルテーブル３６２は、４２２に示されるように、ストレージ管理モジュール３５０によって使用されるUCSM中において、後にアクセスされ、テーブル内の全てのコンテンツアイテムは当該選択プロセスから除外される。例えば、所定のコンテンツアイテムが削除用に選択されると、常駐ファイルテーブル３６２が選択されたコンテンツアイテムがそこに記載されているかどうかを判定するために調べられ、もしそうであれば、選択されたコンテンツアイテムは無視され、その他のコンテンツアイテムがUCSMによって実際に選択される。

[0097]クライアントデバイス１００上のプレースホルダアイテムと関連するコンテンツは同期されないため、コンテンツ管理をより複雑にしてしまう。例えば、クライアントデバイス上のユーザが第２のクライアントデバイス上でプレースホルダアイテムとして表されるコンテンツアイテムを移動する場合、その後、第２のクライアントデバイスがプレースホルダアイテムに関する同期データを受信しなければ、その場所は、第１のクライアントデバイス上で変更されるものの、他のクライアントデバイス上では変更されないことになる。例えば、コンテンツアイテムは、１つのクライアントデバイス１００によって完全にコンテンツ管理システム１１０から削除される一方で、異なるクライアントデバイス１００上のプレースホルダアイテムによって表される可能性がある。この状況が発生した場合、第２のクライアントデバイス１００のユーザは、もはや存在しないことを見つけるのみのために、プレースホルダアイテムによって表されるコンテンツアイテムへアクセスすることを試みることができる。このような混乱する状況を回避するために、いくつかの実施形態において、コンテンツ管理システム１１０は、メタデータについてのみプレースホルダアイテムを同期するように構成され、つまり、プレースホルダアイテムの任意の属性が変更されると、コンテンツ管理システム１１０は、コンテンツアイテムがそれらのクライアントデバイスの何れかでプレースホルダアイテムとして表されているかどうかに関わらず、当該コンテンツアイテムへのアクセスを有する全てのクライアントデバイス１００に修正された属性を同期する。従って、コンテンツアイテムが１つのクライアントデバイスから削除された場合、当該コンテンツアイテムを表すプレースホルダアイテムが任意の他のクライアントデバイス１００上においても削除される。代替的に、いくつかの実施形態において、クライアントデバイス１００上の共有コンテンツストレージディレクトリ１２０内の残りのストレージ内に収まるようにそのサイズが変更されるように、コンテンツアイテムコンテンツアイテムが他のクライアントデバイス上で修正された場合、コンテンツアイテムへのアクセスが要求されない場合であってもクライアントデバイス１００へダウンロードされてもよい。

[0098]前述の実施形態のいくつかは、クライアントアプリケーション２００が所定のストレージ割り当て１３０を超過しないことを保証し、かつ、コンテンツ管理システム１１０からのデータを要求するように動作する、クライアントベースの制約付きの同期システムを表す。ホストベースの実施形態が図６に示され、コンテンツ管理システム１１０は、各クライアントデバイス１００におけるリモート及び常駐のコンテンツアイテムの情報を特定する情報を保持することを含む、制約付きの同期プロセスを管理する。ホストベースの実施形態は、クライアントデバイス１００上の有効なストレージ容量を増加させる同様の利益を提供する一方で、クライアントデバイスから必要とされる計算を低減し、これにより、他の実施形態と比較してクライアントデバイス１００の性能を改善する。制約付きのコンテンツ管理システム６００は、図２に示されるコンテンツ管理システム１１０の要素を含み、さらに、ストレージ管理モジュール３５０が適切に機能するために必要な必要データファイルとともに、ストレージ管理モジュール３５０を利用するように修正される。制約付きのコンテンツ管理システム内において、メタデータサーバ２１２、ブロックサーバ２１４、通知サーバ２１６、データストア２１８、保留ブロックテーブル２２０及びネームスペーステーブル２２２がコンテンツ管理システム１１０で実施されるのと同様の方法で機能する。さらに、ストレージ管理モジュール３５０は、クライアントデバイスに常駐するときと同様の方法で機能し、ストレージスペース制限が超過するときを判定し、適切にプレースホルダアイテムを作成するように動作する。ストレージ管理モジュール３５０はまた、オペレーティングシステム３８０によって行われた要求についての情報をクライアントデバイス１００から受信するように動作する。１以上のコンテンツアイテムを開くように要求が行われると、要求についての情報がストレージ管理モジュール３５０によってリモートで監視するコンテンツ管理システム１１０へ送信され、それにより、クライアントデバイス１００上のプレースホルダアイテムへのアクセスを提供するために必要なダウンロードが行われる。ストレージ管理モジュール３５０は、制約付きのコンテンツ管理システムに関連付けられる各クライアントデバイス上のストレージ構成に関する情報を提供するために、クライアント構成ファイル６１０を使用する。同期テーブル６２０は、制約付きのコンテンツ管理システム６００との同期を要求する、クライアントデバイスクライアントデバイス上の全てのコンテンツアイテムの記録であり、コンテンツアイテムのいくつかがプレースホルダアイテムであってメタデータの同期のみを必要とするため、このテーブルに含まれるコンテンツアイテムはデータストア２１８に位置するコンテンツアイテムのサブセットとなる。さらに、本実施形態において、同期テーブル６２０は、各コンテンツアイテムがリモートで保持されるべき又は常駐されるべきクライアントデバイス１００を示すように構成される、常駐ファイルテーブル３６２とリモートファイルテーブル３６６との両方を用いることによって置き換えられてもよい。後者の構成を用いる実施形態について、プレースホルダアイテムについてのメタデータの同期の実装は、プレースホルダアイテムが各クライアントデバイス１００のリモートファイルテーブル３６６において直接的に特定される場合には、より容易となる。ユーザデータ６３０は、制約付きのコンテンツ管理システム６００上に格納され、これにより、ストレージ管理モジュール３５０は、放置コンテンツアイテムを判定することができる。

[0099]図７は、ホスト管理の制約付きのストレージ同期のプロセスの一実施形態を示す相互作用図である。クライアントデバイス１００上のアプリケーションは、コンテンツアイテムについて、クライアントデバイス上で同期されるフォルダに保存されるように要求する（７００）。ストレージカーネル拡張部は、要求ＩＤ、ファイルパス、及びコンテンツアイテムのサイズを記録し（７０２）、当該情報をクライアントアプリケーション２００へ転送する（７０４）。クライアントアプリケーション２００は、制約付きのコンテンツ管理システム６００上のストレージ管理モジュール３５０へコンテンツアイテムのサイズ情報を転送する（７０６）。ストレージ管理モジュール３５０は、クライアント構成ファイル６１０からコンテンツアイテムサイズを受信した特定のクライアントについてストレージ制限を要求する（７０８）。ストレージ管理モジュール３５０は、クライアントデバイス１００上に常駐する他のコンテンツアイテムに追加したサイズを、クライアント構成ファイル６１０から受信したストレージ割り当てと比較することによって、ストレージ制限が超過するかどうかを判定する（７１２）。ストレージ管理モジュール３５０は、同期テーブル６２０からクライアント上のコンテンツデータを要求し（７１４）、これにより、クライアント上の同期されたコンテンツアイテムから、クライアントから削除されるコンテンツアイテムが選択されうる。同期テーブルは特定のクライアントについての同期されるコンテンツデータを応答する（７１６）。ストレージ管理モジュール３５０は、ＬＲＡコンテンツアイテムを決定するために使用するホストデバイス上に格納されたユーザデータ６３０からユーザアクセスデータを要求する（７１８）。当該データはすぐにユーザデータテーブル６３０から受信される（８２０）。ストレージ管理モジュール３５０は、ＬＲＡコンテンツアイテムを決定し（７２２）、必要なストレージスペースを提供するために、クライアントから削除されるべきそれらを選択する（７２４）。ストレージ管理モジュール３５０は、コンテンツアイテム削除し、プレースホルダアイテムを作成する（７２８）要求をクライアントアプリケーション２００に送信する。コンテンツアイテムを保存する元の要求７００を完了するために、クライアントアプリケーション２００に許可を与える（７３０）。最後に、ストレージ管理モジュールは、保存したコンテンツアイテムへの第１のコンテンツアイテムへのアクセスを反映するようにユーザデータを更新し（７３２）、その後、新たなコンテンツアイテムがアップロードするのに利用可能であるため、メタデータサーバ２１２からクライアントデバイス１００の同期を要求する（７３４）。

[00100]図８は、制約付きの同期を提供するコンテンツ管理システムと連携して動作するクライアントデバイス１００のユーザインタフェースの一例を示す。同期ファイルフォルダ８００は、共有コンテンツストレージディレクトリ１２０のように動作する。フォルダ８００は、それぞれが対応するアイコン８１０Ａ（．ｍ４ａ音楽ファイル）、８１０Ｂ（．xlsxスプレッドシート）、８１０Ｃ（．docxワード処理ファイル）、８１０Ｄ（．mat Matlabファイル）、及び８１０Ｅ（ｊｐｇ画像ファイル）で表される、多数のコンテンツアイテムを含む。各アイコン８１０は、コンテンツアイテムのストレージ状態を示す状態アイコン８２０で重畳される。

[00101]状態アイコン８２０Ａ（”チェックアイコン”）は、コンテンツアイテムがクライアントデバイス１００上に現在常駐しており、コンテンツ管理システム１１０によって保持されるコンテンツアイテムの現在のバージョンで同期されていることを示す。

[00102]状態アイコン８２０Ｂは、コンテンツ管理システムとの同期が完了すると、コンテンツアイテムがクライアントデバイス１００上に常駐されることを示す。

[00103]状態アイコン８２０Ｃは、コンテンツアイテムがプレースホルダアイテムであり、クライアントデバイス上に現在常駐していないが、依然としてコンテンツ管理システム１１０上には保持されていることを示す。

[00104]状態アイコン８２０Ｄは、コンテンツアイテムがクライアントデバイス上に常駐しており、コンテンツ管理システム１１０によって保持されるそのバージョンで同期されていることを示す。さらに、ピンアイコン８４０を有する緑色の丸印は、コンテンツアイテムがストレージ制限中のクライアントデバイス８００上に常駐したままにすることが選択されたことを示す。

[0100]図９は、クライアントデバイスにリモートでの特定のコンテンツアイテムへのユーザアクセスを予測し、当該アクセスに先立って、予測したコンテンツアイテムをダウンロードする、制約付きの同期の代替の実施形態を示す概念図である。当該アプローチは、コンテンツ管理システム１１０からネットワークを介してコンテンツアイテムを取り出す際のユーザの待機時間をほとんどの場合において除去することによって、クライアントデバイスの動作においてさらなる改良を提供する。保存スコア９００は、共有コンテンツストレージディレクトリ１２０内で各コンテンツアイテム１４０について算出される。当該スコアは、以下で説明するように、コンテンツアイテムの予測される重要度の尺度であり、最新のアクセス時刻、又はユーザの要求が予期されると判定された多くの他の要因の関数として算出されうる。さらに、各コンテンツストレージディレクトリ１２０は、ユーザによって指定された又は所定値で設定された保存スコア閾値で構成される。同じコンテンツアイテムの保存スコア９００によって測定されるように、コンテンツアイテムの予測された重要度が、コンテンツアイテムへのアクセスを有するクライアントデバイス１００上の特定の共有コンテンツストレージディレクトリ１２０の保存スコア閾値９１０を超えるたびに、コンテンツアイテムは、クライアントデバイスにリモートである場合には、共有コンテンツストレージディレクトリにダウンロードされ、クライアントデバイスに常駐している場合には共有コンテンツディレクトリで保持される。

[0101]段階９．１は、コンテンツアイテムへのユーザアクセスを予測する、コンテンツ管理システムの典型的な状態を示す。この図例において、コンテンツ管理システム１１０は、２つのクライアントデバイス１００Ａ及び１００Ｂを管理している。共有コンテンツストレージディレクトリ１２０Ａ及び１２０Ｂがそれぞれのクライアントデバイス内に配置される。共有コンテンツストレージディレクトリ１２０Ａは、コンテンツアイテム１４０Ａ、１４０Ｂ及び１４０Ｃを格納し、一方、共有コンテンツストレージディレクトリ１２０Ｂは、コンテンツアイテム１４０Ｄと、コンテンツアイテム１４０Ａのシャドウアイテム表現１６０Ａを格納する。全てのコンテンツアイテム１４０の同期バージョンは、コンテンツ管理システム１１０に格納される。

[0102]さらに、各コンテンツアイテム１４０は、対応する保存スコア９００を有し、９００Ａはコンテンツアイテム１４０Ａの保存スコアであり、９００Ｂはコンテンツアイテム１４０Ｂの保存スコアである。各共有コンテンツストレージディレクトリはまた、保存スコア閾値９１０で構成され、９１０Ａは共有コンテンツストレージディレクトリ１２０Ａについての保存スコア閾値であり、９１０Ｂは共有コンテンツストレージディレクトリ１２０Ｂについての保存スコア閾値である。

[0103]段階９．１において、コンテンツアイテム１４０Ａは、共有コンテンツストレージディレクトリ１２０Ｂにおいては保持されない。この場合、保存スコア閾値９１０よりも低い保存スコア９００を有する共有コンテンツストレージディレクトリ１２０内に存在するコンテンツアイテムは存在しないが、このシナリオは、前述又は後述する、他の実施形態の特徴が本実施形態に加えて使用される可能性がある。例えば、ストレージ割り当てが依然として影響しているため、ストレージ割り当てが十分に大きい場合に、保存スコア９００が保存スコア閾値９１０より低い場合であってもリモートでファイルを維持する必要はないかもしれない。

[0104]段階９．２において、クライアントデバイス１００Ａのユーザは、コンテンツアイテム１４０Ａへのアクセスと見なされる当該コンテンツアイテム１４０Ａについてのユーザアクション９２０を実行する。本例において、保存スコア９００が最新のアクセス時刻の関数として計算されるため、コンテンツアイテム１４０Ａの保存スコア９００Ａは２０から６０に増やされる（本変更の大きさは本例の目的について任意である。保存スコアの計算についての詳細は後述するが、同じスコアへの変更とならない可能性もある。）。

[0105]段階９．３において、コンテンツ管理システム１１０、又は、いくつかの実施形態においてクライアント１００Ｂのクライアントアプリケーションは、コンテンツアイテム１４０Ａの保存スコア９００Ａが、コンテンツアイテム１４０Ａがリモートである共有コンテンツストレージディレクトリ１２０Ｂの保存スコア閾値９１０Ｂ以上であるかどうかを判定する。保存スコア９００Ａが保存スコア閾値９１０Ｂを超えているため、コンテンツアイテム１４０Ａがクライアントデバイス１００Ｂにダウンロードされ、共有コンテンツストレージディレクトリ１２０Ｂに格納される。

[0106]上記UCSMと同様に、多くの保存スコア計算方法がある。通常、保存スコアはユーザの行動属性に対して正規化されえ、結果として同じコンテンツアイテムに対する保存スコアが各クライアントデバイスで異なるか、或いは、スコアが各クライアントデバイスで同じとなるようにグローバル化される。正規化された保存スコアの利点は、ユーザの行動の差分を平均化することにある。例えば、保存スコアが現在時刻と最新アクセス時刻との時間差が減少するにつれて増加するような、コンテンツアイテムの最新のアクセス時刻の関数である場合、あまりアクティブでないユーザと共有されるコンテンツアイテムと比較すると、よりアクティブなユーザは、当該ユーザと共有されるコンテンツアイテムの保存スコアを押し上げることとなる。アクティブなユーザとアクティブでないユーザの両方と共有する第３のユーザについて、保存スコアが正規化されていない場合、アクティブユーザによる最近のアクセスがアクティブでないユーザによる最近のアクセスよりも第３のユーザによるアクセスの予測が少ないにもかかわらず、アクティブユーザからのアイテムのみが最も高い保存スコアを有するようになるため、保存スコアはそれらの予測品質を失うことになる。保存スコアが正規化される際には、特定のユーザ又は特定のコンテンツアイテムの属性に正規化されうる。

[0107]以下の方法は、保存スコア、或いは、コンテンツアイテムへのユーザアクセスを予測するスコアを決定するための方法の例示である。さらに、保存スコアは、後述する複数の方法の組み合わせを使用して、予測される重要度の最も予測的な尺度を作成してもよい。典型的には、保存スコアはコンテンツアイテムの予測される重要度が増す場合に増加するものの、しかしながら、本実施形態について都合が良いのであればその反対もまた真となる。この場合、対応する保存スコア閾値が最小値となり、コンテンツアイテムの保存スコアが保存スコア閾値以下の場合に対応する共有コンテンツストレージディレクトリにダウンロードされることになる。本開示の目的のため、増加させる保存スコアをデフォルトケースとして以下では想定している。

[0108]最新のアクセススコアリング：最新のアクセススコアリングでは、コンテンツアイテムの保存スコアは、当該コンテンツアイテムの最新アクセス時刻の関数である。保存スコアは単に、現在時刻と最新アクセス時刻との秒での差分の逆数であってもよい：
RS = 1 / (t_C - t_A)
ここで、RSは保存スコアであり、t_Cは現在時刻であり、t_Aは最新アクセス時刻である。

[0109]特定の実施形態において正規化が必要となる場合、所定時間期間内の特定のユーザ又は特定のクライアントデバイスによる任意の共有コンテンツアイテムへのアクセス数として定義される、ユーザの又はクライアントデバイスのアクセス頻度などの種々のユーザ属性が使用されてもよい。或いは、特定のユーザ又はクライアントデバイスで共有される複数のコンテンツアイテムの平均最新アクセス時刻が使用されてもよい。

[0110]アクセス頻度スコアリング：アクセス頻度スコアリングでは、所定時間期間内に同一のコンテンツアイテムへのアクセス数の増加に伴って、コンテンツアイテムの保存スコアは増加する。アクセス頻度スコアリングを正規化するために、所定のコンテンツアイテムに対するアクセス頻度は、クライアントデバイス上の又はユーザと共有される全てのコンテンツアイテムについての平均アクセス頻度によって、除算されるか、或いはその反対で拡大されてもよい。

[0111]ロケーション（場所）関連のアクセススコアリングロケーション関連のアクセススコアリングでは、第１のコンテンツアイテムの保存スコアは、当該コンテンツアイテム自身の最新アクセス時刻、アクセス頻度、又は任意の他の特性と、第１のコンテンツアイテムと同じフォルダに格納される追加のコンテンツアイテムの同様の特性との重み付けされた組み合わせである。これは、フォルダ内のコンテンツアイテムへのアクセスが同一のフォルダ内の他のコンテンツアイテムへのアクセスの予測となることを意味している。

[0112]類似アクセススコアリング類似アクセススコアリングでは、第１のコンテンツアイテムの保存スコアは、当該コンテンツアイテム自身の最新アクセス時刻、アクセス頻度と、第１のコンテンツアイテムと類似の属性を有する追加のコンテンツアイテムの同様の特性との重み付けされた組み合わせである。属性は、コンテンツアイテムの種別、サイズ、場所、当該コンテンツアイテムへのアクセスを有するユーザ等である。これは、類似のコンテンツアイテムへのアクセスが当該コンテンツアイテムへの他のアクセスの予測となることを意味している。

[0113]基準ベースの保存スコアリング：基準ベースの保存スコアリングでは、コンテンツアイテムの保存スコアは、コンテンツアイテムによって満足される、以前に特定された予測基準の数に基づくものである。例えば、２４時間以内の他のユーザによるコンテンツアイテムのアクセス、先週の５アクセスよりも大きいアクセス頻度、及び、最近３日以内での十分に類似したコンテンツアイテムへのアクセスが全て、次の６時間でリモートコンテンツアイテムにアクセスを試みる予測となる所定の基準となってもよい。従って、コンテンツアイテムの保存スコアは、コンテンツアイテムによって満足される基準のそれぞれについての所定の大きさによって増加してもよい。特定の基準を満足したことに対する増加する大きさは、特定の基準の予測強度に比例してもよい。

[0114]図１０は、制約付きの同期のための予測されたコンテンツアイテムの重要度を用いるコンテンツ管理システムのシステム環境を示す図である。図１０に示される制約付きコンテンツ管理システムのモジュールの大部分は、前述の記載を除いて、図６を参照して説明したそれらの類似の又は同一の機能を実行する。従って、コンテンツ管理システム１０００内の全てのモジュールの機能について、ここでは詳細に説明しない。

[0115]コンテンツ管理システム１０００は、メタデータサーバ２１２、ブロックサーバ２１４、通知サーバ２１６、データストア２１８、保留ブロックテーブル２２０、ネームスペーステーブル２２２、ストレージ管理モジュール３５０、クライアント構成ファイル６１０、同期テーブル６２０、ユーザデータ６３０、保存スコアテーブル１０１０、及び保存スコアモジュール１０２０を含む。クライアント構成ファイル６１０及びユーザデータ６３０は、図６に示される前述のバージョンから重大な変更を有する。クライアント構成ファイル６１０は、各クライアントデバイスの各共有コンテンツストレージディレクトリについての保存スコア閾値を含むように変更される一方で、ユーザデータは使用される保存スコアリング方法に関連したユーザデータを含むように変更される。保存スコアモジュール１０２０は、保存スコアテーブル１０１０を生成するために、ユーザデータ６３０及びデータストア２１８からのデータを取り込む。保存スコアテーブルは、コンテンツ管理システム１０００によって管理される各コンテンツアイテムの保存スコアを列挙するテーブルである。別個の保存スコアテーブルは、正規化が保存スコアを計算するために使用されている場合には、各クライアントデバイスについて閉じていてもよい。コンテンツアイテムの保存スコアが更新された際には、保存スコアモジュール１０２０は、最近変更された保存スコアに対応するコンテンツアイテムが任意のクライアントデバイス上でリモートであるかどうかと、それらのクライアントデバイスの保存スコア閾値の何れかを超えるかどうかを判定するために、クライアント構成ファイル６１０及び同期テーブル６２０を調べる。保存スコア閾値を超える場合、保存スコアモジュールは、ストレージ管理モジュール３５０は必要なダウンロードと、表示のシャドウアイテムの置き換えとを実行する。

[0116]図１１は、他の実施形態に係る制約付きの同期についてのクライアントアプリケーション１１００のソフトウェアアーキテクチャを示す。本実施形態は、クライアントデバイスがクライアントアプリケーションによってアイドルであると判定されている間に、リモートコンテンツアイテムのダウンロード、放置コンテンツアイテムの削除、シャドウファイルの作成の全てを行う。制約付き同期プロセスのタイミングにおける当該変更は、前述した実施形態上の機能の改善を提供することによってクライアントデバイスを改善する一方で、有効なストレージ容量の同様の増大を提供する。それらの機能を実行するために、本実施形態のトリガとなるアイドル状態は、図３に示されるシステムアーキテクチャを変更する。本実施形態において、クライアントアプリケーション１１００は、同期モジュール３１０、保存状態モジュール１１１０、ファイルジャーナル３６０、常駐ファイルテーブル３６２、共有データ３６４、リモートファイルテーブル３６６、構成ファイル３６８、及びブロックキャッシュ３７０を含んで構成される。コンテンツ同期モジュール３１０は、さらに、ハッシングモジュール３２０、ダウンロードモジュール３３０、アップロードモジュール３４０、及びストレージ管理モジュール３５０を含んで構成される。保存状態モジュール１１１０は、さらに、計算モジュール１１２０、状態比較モジュール１１３０、アクションモジュール１１４０、及びシステム状態モジュール１１５０を含んで構成される。別段の指定がない限り、前述のモジュール及びデータテーブルの全ては、新たなモジュールを適合するために当業者が認識するように僅かに変更されるものの、前述したものと同じ機能を有する。任意の主要は変更について以下で説明する。

[0117]システム状態モジュール１１５０は、オペレーティングシステム３８０のシステムアクティビティを測定するためにストレージカーネル拡張部３８２を使用する。システムアクティビティは、限定はしないものの、プロセッサ周波数又は他のCPU利用メトリックの割合として、非アイドルプロセッサのサイクル数（複数プロセッサコアの調整の有無に関わらず）、クライアントデバイス１００のスレッド数、又はプロセス数を含む、プロセスアクティビティを用いて測定することができる。ネットワークアクティビティメトリックはまた、特定のポート又は接続についての最大速度の割合として、ビット毎秒又はパケット毎秒で定義されるネットワーク利用を含んで使用されてもよい。さらに、システムアクティビティを測定するために、利用可能又はフリーのランダムアクセスメモリ（RAM）の容量を含むメモリ使用メトリックが使用されてもよい。システム状態モジュール１１５０は、上述したアクティビティメトリック又は任意の他の適切なアクティビティメトリックを、システム全体のアクティビティを測定するために、個別に又は組み合わせて使用してもよい。

[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]更新ファイルジャーナル１４１０は、コンテンツ管理システム１１０から受信した、又は、クライアントアプリケーション２００の機能によって作成された、クライアントデバイスに常駐するアイテムについての更新メタデータで追加される。特定のアイテムに対する更新がなければ、当該アイテム１４００についての更新ファイルジャーナルのエントリはないであろう。更新メタデータは、更新ネームスペースＩＤ、更新ジャーナルＩＤ、更新ファイルパス、更新ブロックリスト、更新拡張属性、更新サイズ、更新変更時刻、更新同期タイプ、及び強制再構成値（force reconstruct value）を含んでもよい。

[0143]強制再構成値を除いて、更新ファイルジャーナルエントリのフィールドはローカルファイルジャーナルエントリに対応する。ローカルファイルジャーナルエントリのエントリと更新ファイルジャーナルエントリの間の差異は、当該エントリに関連付けられたコンテンツアイテムが何らかの方法で変更されたことを示す。例えば、更新ファイルパスがローカルファイルパスと異なる場合、当該エントリと関連付けられた（当該エントリのジャーナルＩＤによって）アイテムがローカルファイルパスから更新ファイルパスへ移動したことを示す。

＜クライアントデバイスからコンテンツ管理システムへのコンテンツアイテムのコミット（追加）＞
[0144]図１５は、コンテンツアイテムをコミットするアルゴリズムの一実施形態を示すフローチャートである。コンテンツ同期モジュール３１０は、１５００で、共有コンテンツストレージディレクトリ１２０の新たなコンテンツアイテム又は変更コンテンツアイテムを検出する。変更コンテンツアイテムは、ファイルパス（又はファイルネーム）、ブロックリスト、拡張属性、サイズ、及び最新変更時刻の少なくとも１つを含む、当該コンテンツアイテムの属性の１つが変更されていることを示す。新たなコンテンツアイテムの作成とは対照的に、コンテンツ同期モジュール３１０が既存のコンテンツアイテムへの変更を検出すると、１５１０で、ローカルジャーナルＩＤは、競合解決の目的で当該コンテンツアイテムの保留状態を表す値（例えば、ゼロ）に設定される。

[0145]新たなコンテンツアイテム又は変更コンテンツアイテムが検出されるとすぐに、ハッシュモジュール３２０は、１５２０で、ブロックリストを再作成する新たなブロックとして、任意の新たなデータ又は変更データのハッシュ値を計算し、当該コンテンツアイテムの任意の新な属性又は変更属性を決定する。新たなコンテンツアイテム又は変更コンテンツアイテムの当該ブロックリスト及び属性は、その後、１５３０で、コンテンツ管理システム１１０にコミットされる。クライアントデバイスは、その後、１５４０で、検出したコンテンツアイテムの新たなバージョン又は変更バージョンについてのネームスペース上で、新たなジャーナルＩＤを含むローカルファイルジャーナル１４００に新たなエントリを作成するためのローカルメタデータのセットを、コンテンツ管理システム１１０から受信する。クライアントデバイス１００は、１５５０で、受信したメタデータに基づいて、新たなローカルファイルジャーナルエントリを作成する。コンテンツ管理システム１１０は、ネームスペーステーブル２２２の関連付けに基づいて、新たなコンテンツアイテム又は変更コンテンツアイテムのネームスペースに関連付けられた他のクライアントデバイス１００の更新ファイルジャーナル１４１０へ、更新エントリを伝達する。更新ファイルジャーナル１４１０のエントリを管理するためのアルゴリズムについては、以下で図１９を参照して説明する。

＜クライアントデバイスからコンテンツ管理システムへのプレースホルダアイテムのコミット（追加）＞
[0146]図１６は、プレースホルダアイテムをコミットするアルゴリズムの一実施形態を示すフローチャートである。コンテンツ同期モジュール３１０は、１６００で、共有コンテンツストレージディレクトリの新たなプレースホルダアイテム又は変更プレースホルダアイテムを検出する。プレースホルダアイテムは、ＪＳＯＮディクショナリであってもよく、或いは、ネームスペースＩＤ及びジャーナルＩＤを含む少なくとも２つのフィールドを有する他の表現であってもよい。プレースホルダアイテムに格納される、ネームスペース及びジャーナルＩＤは、ローカルファイルジャーナル１４００のローカルネームスペースＩＤ及びローカルジャーナルＩＤに対応する。プレースホルダアイテムが変更又は作成されると、対応するローカルジャーナルＩＤは、１６１０で、競合解決の目的で、当該プレースホルダアイテムにおける保留状態を表す値（例えば、０）に設定される。

[0147]当該プレースホルダの新たな属性又は変更属性は、１６２０で、コンテンツ同期モジュール３１０によって決定される。プレースホルダアイテムへ発生しうる変更は、プレースホルダアイテムの名称変更や、プレースホルダアイテムのファイルパスの変更を含む。新たなプレースホルダアイテムの作成の結果となりうるアクションは、プレースホルダアイテムをコピーすること、又は、１つのネームスペースから他のネームスペースへコンテンツアイテムを移動することを含んでもよい。

[0148]新たな属性又は変更属性がコンテンツ同期モジュール３１０によって決定されると、プレースホルダアイテムのジャーナルＩＤ及びネームスペースＩＤは、１６３０で、プレースホルダアイテムの属性をコンテンツ管理システム１１０へコミットするために使用される。クライアントデバイスは、その後、１６４０で、検出したプレースホルダアイテムの新たなバージョン又は変更バージョンについてのネームスペース上で、新たなジャーナルＩＤを含むローカルファイルジャーナル１４００に新たなエントリを作成するためのローカルメタデータのセットを、コンテンツ管理システム１１０から受信する。クライアントデバイス１００は、１６５０で、受信したメタデータに基づいて、新たなローカルファイルジャーナルエントリを作成する。プレースホルダアイテム自身はまた、新たなジャーナルＩＤを反映するように更新される。コミットイベントに対応する更新エントリは、その後、ネームスペーステーブル２２２の関連付けに基づいて、新たなプレースホルダアイテム又は変更プレースホルダアイテムのネームスペースに関連付けられた他のクライアントデバイス１００へ伝達される。更新ファイルジャーナル１４１０のエントリを管理するためのアルゴリズムについては、以下で図１９を参照して説明する。

＜クライアントデバイスでのコンテンツアイテムのプレースホルダアイテムとの置き換え＞
[0149]クライアントデバイス１００に常駐するコンテンツアイテムは、プレースホルダアイテムによってマークされてもよい。これは、直接的なユーザアクション、又は、意図しないコンテンツアイテムを判定するための前述した方法の１つに従った、クライアントアプリケーション２００若しくはコンテンツ管理システム１１０の判定によって発生しうる。図１７は、コンテンツアイテムをプレースホルダアイテムとを置き換えるアルゴリズムの一実施形態を示すフローチャートである。コンテンツアイテムが代理のプレースホルダアイテムとの置き換えによって特定されると、コンテンツ同期モジュール３１０は、１７００で、更新同期タイプのフィールドを除いて、ローカルファイルジャーナル１４００から更新ファイルジャーナル１４１０へ当該コンテンツアイテムについてのエントリをコピーする。コンテンツ同期モジュール３１０は、１７１０で、プレースホルダアイテムを示すように、エントリの更新同期タイプのフィールドを設定する。続いて、更新ファイルジャーナルエントリの強制再構成フィールドには、コンテンツアイテムの更新バージョンがオリジナルのコンテンツアイテムと同じ属性を有する事実にもかかわらず、コンテンツアイテムの再構成が必要であることをコンテンツ同期モジュール３１０に示す”ｔｒｕｅ”が設定される。

＜クライアントデバイスでのプレースホルダアイテムのコンテンツアイテムとの置き換え＞
[0150]プレースホルダアイテムをコンテンツアイテムと置き換えるための処理は、基本的には、コンテンツアイテムを代理のプレースホルダアイテムと置き換えるための処理の逆となる。クライアントデバイス１００上でコンテンツアイテムを表すプレースホルダアイテムは、コンテンツアイテムへ復元されるようにマークされてもよい。これは、直接的なユーザアクションから、又は、意図しないコンテンツアイテムを判定するための前述した方法の１つに従った、クライアントアプリケーション２００若しくはコンテンツ管理システム１１０の判定によって発生しうる。図１８は、プレースホルダアイテムをコンテンツアイテムと置き換えるアルゴリズムの一実施形態を示すフローチャートである。プレースホルダアイテムがコンテンツアイテムへの復元用に特定されると、コンテンツ同期モジュール３１０は、１８００で、更新同期タイプのフィールドを除いて、ローカルファイルジャーナル１４００から更新ファイルジャーナル１４１０へ当該プレースホルダアイテムについてのエントリをコピーする。コンテンツ同期モジュール３１０は、１８１０で、コンテンツアイテムを示すように、エントリの更新同期タイプのフィールドを設定する。続いて、更新ファイルジャーナルエントリの強制再構成フィールドには、プレースホルダアイテムについての更新エントリがローカルジャーナルエントリと同じ属性を有する事実にもかかわらず、プレースホルダアイテムの再構成が必要であることをコンテンツ同期モジュール３１０に示す”ｔｒｕｅ”が設定される。

＜更新機能＞
[00105]図１９は、更新ファイルジャーナル１４１０の更新エントリを受信すると、コンテンツ同期モジュール３１０によって実行される更新機能１９００のアルゴリズムの一例を示すフローチャートである。更新機能１９００は、コンテンツ管理システム１１０から受信された、又は、コンテンツ同期モジュール３１０自身によって生成された、更新ファイルジャーナルエントリを解決するためにどのような変更が行われる必要があるかを判定すべく、コンテンツ同期モジュール３１０によって実行される一連のステップである。更新ジャーナルは、限定はしないが、ネームスペースに関連付けられた異なるクライアントデバイスからのコミットに基づいて新たなジャーナルＩＤが当該ネームスペース上で作成された場合、クライアントデバイス上に常駐するコンテンツアイテムが（直接的なユーザアクションによって、又は、クライアントアプリケーション２００若しくはコンテンツ管理システム１１０による決定によっての何れかで）置き換えられるようにマークされた場合、及び、クライアントデバイス上のコンテンツアイテムを表すプレースホルダアイテムが（直接的なユーザアクションによって、又は、クライアントアプリケーション若しくはコンテンツ管理システムの決定によっての何れかで）その表すコンテンツアイテムによって置き換えられるようにマークされた場合を含む多くの状況で作成されてもよい。

[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]最後に、明細書において使用された言葉は主に可読性及び説明の目的のために選択されたものであり、本発明の主題の輪郭を描いたり制限を加えたりするために選択されたものではない。従って、本発明の範囲は、この詳細な説明によって限定されるのではなく、ここでの記載に基づく本出願で公表される任意の請求項によって限定されることが意図される。従って、本発明の実施形態の開示は説明のためを意図したものであって、以下の請求項において明らかにされる本発明の範囲を限定するものではない。

Claims (20)

1. 方法であって、
   クライアントデバイスによって、コンテンツ管理システムから更新ファイルジャーナルエントリを受信することであって、前記更新ファイルジャーナルエントリは、複数のパラメータとして、少なくとも前記コンテンツ管理システムに格納されたコンテンツアイテムの更新ネームスペースＩＤと、前記コンテンツアイテムの更新ブロックリストとを含む、ことと、
   前記コンテンツ管理システムによって格納される前記コンテンツアイテムを表す前記クライアントデバイス上のシャドウアイテムを特定する、前記クライアントデバイスによって格納されるローカルファイルジャーナルの複数のローカルエントリの対応するパラメータと、前記更新ファイルジャーナルエントリの前記複数のパラメータの少なくとも１つを比較することであって、前記シャドウアイテムは、前記コンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記コンテンツアイテムのネームスペースＩＤを含む、ことと、
   前記比較の結果に基づき、前記シャドウアイテムの前記ネームスペースＩＤを前記更新ネームスペースＩＤと置き換えることによって、前記特定されるシャドウアイテムを更新することと、
   前記シャドウアイテムに対応するローカルファイルジャーナルエントリを前記更新ファイルジャーナルエントリと置き換えることと
   を含むことを特徴とする方法。
2. 請求項１に記載の方法であって、さらに、
   前記コンテンツアイテムの前記更新ブロックリストと前記シャドウアイテムのブロックリストとの間の比較に基づいて、前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致するかを判定することと、
   前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致しない場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
   前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
   を含むことを特徴とする方法。
3. 請求項１に記載の方法であって、さらに、
   前記更新ファイルジャーナルエントリと関連付けられる強制再構成値及び更新同期タイプに基づいて、前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであることを判定することと、
   前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであると判定された場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
   前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
   を含むことを特徴とする方法。
4. 請求項１に記載の方法であって、
   前記更新ファイルジャーナルエントリは更新ファイルパスを含み、前記複数のローカルエントリのそれぞれはローカルファイルパスを含み、
   前記更新ファイルジャーナルエントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とする方法。
5. 請求項４に記載の方法であって、さらに、
   前記更新ファイルパス及び前記ローカルファイルパスの前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに再配置されるべきであることを判定することと、
   前記シャドウアイテムが前記新たなファイルパスに再配置されるべきであると判定された場合、前記更新ファイルパスによって示される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することと
   を含むことを特徴とする方法。
6. 請求項１に記載の方法であって、さらに、
   前記更新ファイルジャーナルエントリ及び前記複数のローカルエントリの前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、
   前記シャドウアイテムが前記クライアントデバイスのユーザによる前記変更に基づいて保留中であると判定された場合、前記更新ファイルジャーナルエントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うことと
   を含むことを特徴とする方法。
7. 請求項６に記載の方法であって、さらに、
   前記シャドウアイテムの前記変更時刻が前記更新変更時刻よりも遅いとの判定に応じて、前記クライアントデバイスのユーザによる前記変更を前記コンテンツ管理システムへコミットすることと
   を含むことを特徴とする方法。
8. コンピュータプログラムであって、クライアントデバイスによって実行されると、該クライアントデバイスに動作を実行させ、前記動作は、
   前記クライアントデバイスによって、コンテンツ管理システムから更新ファイルジャーナルエントリを受信することであって、前記更新ファイルジャーナルエントリは、複数のパラメータとして、少なくとも前記コンテンツ管理システムに格納されたコンテンツアイテムの更新ネームスペースＩＤと、前記コンテンツアイテムの更新ブロックリストとを含む、ことと、
   前記コンテンツ管理システムによって格納される前記コンテンツアイテムを表す前記クライアントデバイス上のシャドウアイテムを特定する、前記クライアントデバイスによって格納されるローカルファイルジャーナルの複数のローカルエントリの対応するパラメータと、前記更新ファイルジャーナルエントリの前記複数のパラメータの少なくとも１つを比較することであって、前記シャドウアイテムは、前記コンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記コンテンツアイテムのネームスペースＩＤを含む、ことと、
   前記比較の結果に基づき、前記シャドウアイテムの前記ネームスペースＩＤを前記更新ネームスペースＩＤと置き換えることによって、前記特定されるシャドウアイテムを更新することと、
   前記シャドウアイテムに対応するローカルファイルジャーナルエントリを前記更新ファイルジャーナルエントリと置き換えることと
   を含むことを特徴とするコンピュータプログラム。
9. 請求項８に記載のコンピュータプログラムであって、さらに、
   前記コンテンツアイテムの前記更新ブロックリストと前記シャドウアイテムのブロックリストとの間の比較に基づいて、前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致するかを判定することと、
   前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致しない場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
   前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
   を含むことを特徴とするコンピュータプログラム。
10. 請求項９に記載のコンピュータプログラムであって、
    前記更新ファイルジャーナルエントリに関連付けられる強制再構成値及び更新同期タイプに基づいて、前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであることを判定することと、
    前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであると判定された場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
    前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
    を含むことを特徴とするコンピュータプログラム。
11. 請求項８に記載のコンピュータプログラムであって、
    前記更新ファイルジャーナルエントリは更新ファイルパスと、ローカルファイルパスを含む前記複数のローカルエントリのそれぞれとを含み、
    前記更新ファイルジャーナルエントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とするコンピュータプログラム。
12. 請求項１１に記載のコンピュータプログラムであって、さらに、
    前記更新ファイルパス及び前記ローカルファイルパスの前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに再配置されるべきであることを判定することと、
    前記シャドウアイテムが前記新たなファイルパスに再配置されるべきであると判定された場合、前記更新ファイルパスによって特定される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することと
    を含むことを特徴とするコンピュータプログラム。
13. 請求項８に記載のコンピュータプログラムであって、さらに、
    前記更新ファイルジャーナルエントリ及び前記複数のローカルエントリの前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、
    前記シャドウアイテムが前記クライアントデバイスのユーザによる前記変更に基づいて保留中であると判定された場合、前記更新ファイルジャーナルエントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うことと
    を含むことを特徴とするコンピュータプログラム。
14. 請求項１３に記載のコンピュータプログラムであって、さらに、
    前記シャドウアイテムの前記変更時刻が前記更新変更時刻よりも遅いとの判定に応じて、前記クライアントデバイスのユーザによる前記変更を前記コンテンツ管理システムへコミットすることと
    を含むことを特徴とするコンピュータプログラム。
15. システムであって、
    プロセッサと、
    命令を格納するコンピュータ可読記憶媒体であって、前記プロセッサによって実行されると、前記プロセッサに、
    クライアントデバイスによって、コンテンツ管理システムから更新ファイルジャーナルエントリを受信することであって、前記更新ファイルジャーナルエントリは、複数のパラメータとして、少なくとも前記コンテンツ管理システムに格納されたコンテンツアイテムの更新ネームスペースＩＤと、前記コンテンツアイテムの更新ブロックリストとを含む、ことと、
    前記コンテンツ管理システムによって格納される前記コンテンツアイテムを表す前記クライアントデバイス上のシャドウアイテムを特定する、前記クライアントデバイスによって格納されるローカルファイルジャーナルの複数のローカルエントリの対応するパラメータと、前記更新ファイルジャーナルエントリの前記複数のパラメータの少なくとも１つを比較することであって、前記シャドウアイテムは、前記コンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記コンテンツアイテムのネームスペースＩＤを含む、ことと、
    前記比較の結果に基づき、前記シャドウアイテムの前記ネームスペースＩＤを前記更新ネームスペースＩＤと置き換えることによって、前記特定されるシャドウアイテムを更新することと、
    前記シャドウアイテムに対応するローカルファイルジャーナルエントリを前記更新ファイルジャーナルエントリと置き換えることと
    の操作を実行させる命令を含むコンピュータ可読記憶媒体と
    を備えることを特徴とするシステム。
16. 請求項１５に記載のシステムであって、さらに、
    前記コンテンツアイテムの前記更新ブロックリストと前記シャドウアイテムのブロックリストとの間の比較に基づいて、前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致するかを判定することと、
    前記シャドウアイテムの前記ブロックリストが前記コンテンツアイテムの前記更新ブロックリストと一致しない場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
    前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
    を含むことを特徴とするシステム。
17. 請求項１６に記載のシステムであって、
    前記更新ファイルジャーナルエントリに関連付けられる強制再構成値及び更新同期タイプに基づいて、前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであることを判定することと、
    前記シャドウアイテムが前記コンテンツアイテムと置き換えられるべきであると判定された場合、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、
    前記クライアントデバイス上の前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記コンテンツアイテムと置き換えることと
    を含むことを特徴とするシステム。
18. 請求項１５に記載のシステムであって、
    前記更新ファイルジャーナルエントリは更新ファイルパスと、ローカルファイルパスを含む前記複数のローカルエントリのそれぞれとを含み、
    前記更新ファイルジャーナルエントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とするシステム。
19. 請求項１８に記載のシステムであって、さらに、
    前記更新ファイルパス及び前記ローカルファイルパスの前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに再配置されるべきであることを判定することと、
    前記シャドウアイテムが前記新たなファイルパスに再配置されるべきであると判定された場合、前記更新ファイルパスによって特定される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することと
    を含むことを特徴とするシステム。
20. 請求項１５に記載のシステムであって、さらに、
    前記更新ファイルジャーナルエントリ及び前記複数のローカルエントリの前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、
    前記シャドウアイテムが前記クライアントデバイスのユーザによる前記変更に基づいて保留中であると判定された場合、前記更新ファイルジャーナルエントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うこととを含むことを特徴とするシステム。

Images