JP2019505025A - 制約付き同期システムにおける共有コンテンツアイテムの選択的ダウンロード - Google Patents

Abstract

コンテンツ管理システムは、コンテンツアイテムを、ネットワークに接続されたクライアントコンピューティングシステム間で同期させる。各クライアントデバイスは、同期させられる共有コンテンツアイテムのためのストレージ割り当てを有する。増大するようにコンテンツアイテムを追加又は編集することを求める要求により、クライアントデバイス上の共有コンテンツアイテムに対するストレージ割り当てを超過すると、クライアントアプリケーション又はコンテンツ管理システムのホストは、コンテンツアイテムを、コンテンツ管理システム上にはリモートで保持するがクライアントデバイス上での常駐からは削除するために選択する。選択されたコンテンツアイテムの削除に応じて、クライアントアプリケーションは、コンテンツアイテムを示すが当該コンテンツアイテムのメタデータのみを含むシャドウアイテムを作成する。これにより、同期させられる全ての共有コンテンツアイテムに対するユーザのアクセスを保持しながら十分な空間が作られる。クライアントデバイス上で動作しているアプリケーションによってシャドウアイテムが要求されると、クライアントアプリケーションは、当該要求を承認又は拒否しうる。

Description

説明される実施形態は、全体として、コンテンツアイテムの同期を提供するコンピュータシステムの性能の改善に関するものであり、特に、クライアントデバイスと、同期されたコンテンツアイテムに対するストレージ割り当てに制約があるコンテンツ管理システムとの間の、コンテンツアイテムの同期の改善に関するものである。

コンテンツ管理システムは、ユーザが１つのクライアントから他のクライアントにコンテンツアイテムを共有することを可能にする。クライアントは、ストレージのために、又は他のクライアントとの同期のためにコンテンツアイテムをコンテンツ管理システムへ提供するコンピューティングデバイスである。他のクライアントは、他のユーザによって操作されうるか、又は、同じユーザによって登録若しくは管理されるデバイスでありうる。ユーザは、どのコンテンツアイテム又はコンテンツアイテムを含むディレクトリが、他のユーザと共有されて、それによりそのようなユーザのクライアントデバイスと同期するために利用可能であるかを指定する。一般に、コンテンツ管理システムは、所与のコンテンツアイテムを、当該コンテンツアイテムを共有するよう指定されているクライアントデバイスの全てと同期させる。その結果、これらのクライアントデバイスのそれぞれは、非常に多くの共有コンテンツアイテムを蓄えうる。場合によっては、クライアントデバイス上で共有コンテンツアイテムによって占められるストレージ量によって、当該クライアントデバイス上で、同期していないコンテンツアイテム及びアプリケーション等の他のアイテムのために利用可能なストレージ量が大幅に減少する。

、 図１Ａ及び図１Ｂは、制約付き同期の一実施形態を示す概念図である。

図２は、クライアントデバイス間でコンテンツアイテムを同期させるコンテンツ管理システムのためのシステム環境を示す。

図３は、クライアントデバイスのソフトウェアアーキテクチャを示す。

図４は、ローカルコンテンツディレクトリにおける既存のコンテンツアイテムにアクセスするための、制約付き同期のインタラクションダイアグラムである。

図５は、ローカルコンテンツディレクトリに格納される新しいコンテンツアイテムを作成するための、制約付き同期のインタラクションダイアグラムである。

図６は、ホストベースの制約付き同期のためのシステム環境を示す。

図７は、ホストデバイスによって管理される、制約付き同期のインタラクションダイアグラムである。

図８は、アイコンがリモートコンテンツアイテム及びローカルコンテンツアイテムを表す、ローカルコンテンツディレクトリについてのユーザインタフェースの図である。

図９は、予測されたコンテンツアイテム重要度を用いた制約付き同期を示す概念図である。

図１０は、予測されたコンテンツアイテム重要度を制約付き同期のために用いるコンテンツ管理システムのためのシステム環境を示す。

図１１は、アイドル状態トリガ型のコンテンツ管理を用いるクライアントデバイスのソフトウェアアーキテクチャを示す。

図１２は、アイドル状態トリガ型のコンテンツ管理を用いるコンテンツ管理システムのためのシステム環境を示す。

図１３は、アイドル状態トリガ型のコンテンツ管理に使用されるプロセスを示すフロー図である。

図１４は、制約付き同期を利用するコンテンツ管理システムのために選択的ダウンロードを使用する、クライアントデバイスのソフトウェアアーキテクチャを示す。

図１５は、対応するシャドウアイテムが要求された場合にダウンロードのためにコンテンツアイテムを承認するために使用されるプロセスの例を示すフロー図である。

図面は例示のみを目的として種々の実施形態を表現している。当業者であれば、本明細書に示される構成及び方法の代替の実施形態が、本明細書に記載の発明の原理から逸脱することなく採用されうることを、以下の議論から容易に理解しよう。

制約付き同期の機能概要
制約付き同期システム及びプロセスの全体的な機能概要について以下で説明する。予備的条件として、ユーザはクライアントデバイスにコンテンツアイテムを格納し、当該コンテンツアイテムは、他のクライアントデバイス上のコンテンツアイテムのインスタンスと同期させられ、典型的にはコンテンツ管理システムであるホストシステムと同期させられる。クライアントデバイスは、ローカルコンテンツディレクトリにコンテンツアイテムを格納する。ローカルコンテンツディレクトリに格納されたコンテンツアイテムは、コンテンツ管理システムと同期させられ、当該コンテンツ管理システムは、コンテンツアイテムのコピーを保持し、かつ、当該コンテンツアイテムを他のクライアントデバイスと同期させる。各クライアントデバイスは、クライアントアプリケーションを実行し、当該クライアントアプリケーションはユーザがコンテンツ管理システムにアクセスすることを可能にする。クライアントアプリケーションは、更に、ローカルコンテンツディレクトリに対して最大ストレージ割り当て又はサイズをユーザが設定することを可能にする。

一態様において、クライアントデバイスは、いずれの同期済みコンテンツアイテムがクライアントデバイスにローカルで利用可能に残っているか、及び、いずれがコンテンツ管理システムのみにその全体が格納されているかを選択的に判定するよう構成される。一実施形態において、クライアントデバイスは、コンテンツアイテムへのアクセス要求を、例えば、当該コンテンツアイテムへのアクセスを必要とするアプリケーションから受け付ける。クライアントデバイスは、要求されたコンテンツアイテムが、シャドウアイテムであるか、当該クライアントデバイスにローカルに格納されたコンテンツアイテムであるかを判定する。シャドウアイテムは、コンテンツアイテムを表す又はエミュレートするが当該コンテンツアイテムのアプリケーションデータを含まないアイテムである。一般に、シャドウアイテムは、テキスト、画像データ、映像データ、音声データ、データベーステーブル、スプレッドシートデータ、グラフィックデータ、ソースコード、オブジェクトコード、又はコンテンツデータの他のタイプのような、実際のアプリケーションコンテンツを格納することなく、コンテンツアイテムのタイプ、パス情報、アクセス権、修正情報、及びサイズのような、種々の属性とともに、コンテンツアイテムの名称のような、コンテンツアイテムのメタデータ属性を複製する。シャドウアイテムは、コンテンツアイテムについてのメタデータのみを格納するため、サイズが数百メガバイトになりうるか又は数ギガバイトにさえなりうるコンテンツアイテムと比べて、例えば典型的には約４キロバイトの少量のストレージのみを必要とする。このため、シャドウアイテムを使用してコンテンツアイテムを表すことは、かなりのストレージ空間を節約する効果があり、それにより、クライアントデバイスの機能が改善される。

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

クライアントデバイスは、選択されたコンテンツアイテムを削除し、削除したクライアントデバイスごとに、対応するシャドウアイテムを作成する。クライアントデバイスは、シャドウアイテムを、削除したコンテンツアイテムに対応するディレクトリロケーションに格納する。当該対応するロケーションにおけるシャドウアイテムの格納により、要求中のアプリケーションに対して透過的な方法で、削除されたコンテンツアイテムのその後の回復が可能になる。

本実施形態は、各クライアントデバイスが、他のコンテンツアイテム及びアプリケーションに対してより多くの空間を有しながら、コンテンツ管理システムと共有される全コンテンツアイテムへのアクセスを維持することができる、制約付き共有ストレージシステムを提供し、各クライアントデバイス及びコンテンツ管理システムのストレージ効率を改善する。より具体的には、当該実施形態は、クライアントデバイスが、実際に有しているストレージ容量よりもかなり大きなストレージ容量を有しているかのように効率的に動作することを可能にする。例えば、ローカルコンテンツディレクトリに対して１０ＧＢのストレージ割り当てのみを有するクライアントデバイスは、当該ディレクトリに対して４０００ＧＢ（４ＴＢ）を超えるストレージ割り当てを有しているかのように動作でき、これは、有効ストレージの４００倍の増加を表す。これまで、限られたローカルストレージ容量に対するそのようなソリューションは、ネットワーク接続性及び帯域幅の制限によって不可能とされてきたが、このため、解決された課題は、広範囲にわたる接続性と速いアップロード及びダウンロード速度とを可能にするインターネット・インフラストラクチャの近年の開発の結果として生じる。

インターネット・インフラストラクチャの近年の開発にかかわらず、コンテンツアイテムの削除、当該コンテンツアイテムのシャドウアイテムとの置き換え、及びユーザの要求を受けての当該コンテンツアイテムの復元に要する計算時間、アップロード時間、及びダウンロード時間は、依然としてデバイス性能に影響を与えうる。したがって、これまでの共有コンテンツ同期方法を通じたクライアントデバイスに対するストレージ負荷を更に低減しつつ、デバイス性能に与える影響をユーザに見えるように低減する代替の実施形態についても説明する。一実施形態において、計算、アップロード及びダウンロードは、シャドウアイテムとして表される共有コンテンツアイテムへの予測されたユーザアクセスに基づいて、完了される。コンテンツアイテムへのユーザアクセスを予測するために、クライアントアプリケーション又はコンテンツ管理システムは、コンテンツアイテムごとにリテンションスコア（retention score）を維持し、当該リテンションスコアは、ユーザに対する各コンテンツアイテムの予測重要度の測度である。（リテンションスコア閾値を上回るリテンションスコアによって表される）十分に高い予測重要度を有するあらゆるコンテンツアイテムが、対応するクライアントデバイスへダウンロードされるように、各クライアントデバイスにリテンションスコア閾値が設定される。リテンションスコアは、最新のアクセス時刻、ロケーション、タイプ、サイズ、アクセス頻度、共有ステータス、アクセス可能なアカウントの数、アクセス可能なデバイスの数、又はコンテンツアイテムを格納したデバイスの数を含む、様々な属性に基づいて、計算されうる。

あるいは、他の実施形態では、（コンテンツ管理システムによって、又はクライアントアプリケーションによって）クライアントデバイスのアクティビティがモニタリングされる間に、当該クライアントデバイス上の共有コンテンツアイテムによって占有されるストレージ空間が、ストレージ割り当てを上回ることが可能になる。クライアントデバイスがアイドルであると判定されると、クライアントアプリケーションは、前述のように、クライアントデバイスに格納されたコンテンツアイテムによって占有された有効ストレージ空間を減らすために、コンテンツアイテムを削除し、当該コンテンツアイテムをシャドウアイテムに置き換える。これらの実施形態では、ストレージ割り当てが常に維持されることはなく、それ故に、占有ストレージを他のコンテンツアイテムの属性に応じて減らすことが可能である。ストレージ割り当てを維持する代わりに、クライアントデバイスがアイドルである限り、例えば特定の時間（例えば、２週間）より古い最後のアクセス日を有する全てのコンテンツアイテムを削除し、シャドウアイテムと置き換えることができよう。このプロセスは、クライアントデバイスがアイドルではなく、そのためユーザによってアクティブには使用されていない間に動作が行われるため、占有ストレージ空間をストレージ割り当てより少なくし続けることはないが、ユーザに対して好ましいであろう方法で占有ストレージ空間を減らすであろうし、その結果として、有効ストレージ容量の同様の増加を提供しながら、前述の実施形態と比較してユーザエクスペリエンスの向上をもたらすことによって、制約付き同期システムを使用するよう構成されたクライアントデバイスを向上させる。

図１Ａ及び図１Ｂは、制約付き同期の実施形態を更に示す概念図である。図１Ａは、ストレージ制約がある同期フォルダにコンテンツアイテムを保存するプロセスを示している。図ＢＡは、ストレージ制約があるクライアントデバイス上のシャドウアイテムを開くプロセスを示している。

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

「コンテンツアイテム」との用語は、本明細書で用いられるように、任意のファイル、ファイルのグループ、又はファイルのコレクションを示す。単一のファイルのみから成る任意のコンテンツアイテムは、代替的には、ファイルと称されてもよい。追加的には、「ファイルテーブル」のような用語は、個別のファイル又はコンテンツアイテムの両方を示すために使用されてもよい。

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

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

ステージ１．１は、クライアントデバイス１００Ａからの、コンテンツアイテム１４０Ｅを共有コンテンツストレージ・ディレクトリ１２０に保存することを求める要求の動作を示している。しかし、図示されるように、ストレージ割り当て１３０によって制限される、共有コンテンツストレージ・ディレクトリ１２０における残りの利用可能な空間をコンテンツアイテム１４０Ｅのサイズが超えるため、コンテンツアイテム１４０Ｅの共有コンテンツストレージ・ディレクトリ１２０への追加は、コンテンツアイテム１４０によって占有される総ストレージ空間がストレージ割り当て１３０を超えることを生じさせうる。

ステージ１．２は、コンテンツアイテム１４０Ｅを格納できる、利用可能な十分なストレージを作り出すように、クライアントデバイス１００から削除されるべき放置コンテンツアイテム１３０Ｃの選択の動作を示している。実施形態に依存して、クライアントデバイス１００又はコンテンツ管理システム１１０は、いずれのコンテンツアイテム１４０を放置されているものとして選択するかを判定する。以下で説明する様々な方法を、いずれのコンテンツアイテムが放置されているものとして選択されるかを判定するために使用可能である。本例では単一のコンテンツアイテム１４０Ｃのみが選択されるが、実際には、利用可能とされる必要があるストレージ容量に応じて、任意の数のコンテンツアイテム１４０が選択されうる。

ステージ１．３は、選択されたコンテンツアイテム１４０Ｃをクライアントデバイス１００Ａから削除する動作を示している。削除された各コンテンツアイテムの代わりに、クライアントデバイス１００Ａは、削除されたコンテンツアイテム１４０Ｃを表すシャドウアイテム１６０Ｃを作成し、当該シャドウアイテムを、共有コンテンツストレージ・ディレクトリ１２０内の、削除されたコンテンツアイテム１４０Ｃと同じロケーションに格納する。あるいは、コンテンツ管理システム１１０がシャドウアイテム１６０Ｃを作成し、その後にシャドウアイテム１６０Ｃをコンテンツストレージディレクトリ１２０へダウンロードしてもよい。シャドウアイテムは、コンテンツ名、パス情報、コンテンツ属性、及びコンテンツサイズのような、削除されたコンテンツアイテムを表す属性を含むが、コンテンツアイテム１４０Ｃの実際のデータを含むことはない。対応するコンテンツアイテムの実際のデータを含まないことによって、シャドウアイテムは、大幅に少ないストレージしか必要としない。例えば、シャドウアイテムは、典型的には、４ＫＢのような、オペレーティングシステムによって提供される最小ファイルサイズ割り当てしか必要としない。この小さなサイズは、図１において縦線を用いて視覚的に示されており、当該シャドウアイテムのサイズが、コンテンツアイテム１４０Ｃ自体と比べた場合にごくわずかであることを示している。例えば、削除されたコンテンツアイテム１４０Ｃが（音声又はビデオファイルではよく見られる）何メガバイト又は更には何ギガバイトのサイズでありうる一方、そのようなコンテンツアイテムを表すシャドウアイテムに必要となるストレージはそれでも４ＫＢ程度だけであろう。その結果、クライアントデバイス１００は、共有コンテンツアイテムのために使用されるローカルストレージの量を、ストレージ割り当て１３０を下回る量に減らすことができ、その結果として、新たに作成された（又はコンテンツアイテムの新しいバージョンがより大きくなるように更新された）コンテンツアイテム１４０Ｅを格納するために利用可能な十分な空間を作れる。選択された（及び削除された）コンテンツアイテムを識別する情報が、それらのアイテムがその後に選択的に回復できるようにするために、クライアントデバイス１００Ａで保持される。この情報は、コンテンツ管理システム１１０内の（図１には示していないが以下で更に説明するような）リモートコンテンツアイテムテーブル３６６にリモートで格納されている、格納されたコンテンツアイテムのリスト１５０に、クライアントデバイス１００においてローカルで格納される。

ステージ１．４は、共有コンテンツストレージ・ディレクトリ１２０において十分な空間が利用可能にされるとコンテンツアイテム１４０Ｅをクライアントデバイス１４０Ａに保存する動作を示している。クライアントデバイス１００Ａが、共有コンテンツストレージ・ディレクトリ１２０へのコンテンツアイテム１４０Ｅの保存に成功すると、コンテンツ管理システム１１０との同期が開始され、コンテンツアイテム１４０Ｅが、コンテンツ管理システム１１０へアップロードされる。コンテンツ管理システム１１０は、クライアントデバイス１００Ａ上の全てのコンテンツアイテム（シャドウアイテムを含む。）の完全なコピーを更に保持している。

ここで図１Ｂを参照すると、クライアントデバイス１００Ａとコンテンツ管理システム１１０との間でコンテンツアイテム１４０Ｅの同期が行われた後の、クライアントデバイス１００Ａ及びコンテンツ管理システム１１０が示されている。

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

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

ステージ１．７は、コンテンツアイテム１４０Ａを削除して、それをシャドウアイテム１６０Ａで置き換える動作を示している。この削除により、コンテンツ管理システム１１０からダウンロードされ、ストレージ割り当て１３０を超えることなく、シャドウアイテム表現に付加されることになるコンテンツアイテム１４０Ｃのために、共有コンテンツストレージ・ディレクトリ１２０内に十分な空間が作られる。削除されたコンテンツアイテム１４０Ａは、リモートで格納されたコンテンツアイテムのリスト１５０内に含まれ、コンテンツアイテム１４０Ｃは、共有コンテンツストレージ・ディレクトリ１２０に復元されたため、このリスト１５０から削除される。

ステージ１．８は、コンテンツアイテム１４０Ｃがクライアントデバイス１００Ａにいったん常駐すると、要求アプリケーションが当該コンテンツアイテムを開くことができることを示している。図１Ａ及び図１Ｂに示されるプロセスがクライアントデバイス１００Ａ上でいったん完了すると、クライアントデバイス１００Ａとコンテンツ管理システム１１０との間で、クライアントデバイス１００Ａ上のコンテンツアイテム１４０に対するあらゆる変更がコンテンツ管理システム１１０上に反映されるように、通常の同期が行われうる。（シャドウアイテムによって表されていても）全てのコンテンツアイテム１４０が、共有コンテンツストレージ・ディレクトリ１２０から削除されるまで、コンテンツ管理システム１１０上で保持される。

システムアーキテクチャの概要
図２は、制約付き同期システムのシステムアーキテクチャを示している。以降のセクションでは各構成要素に関する詳細について更に説明するが、ここでは、制約付き同期の説明用のコンテキストを提供するために、いくつかの要素を導入する。更に、当業者には明らかなように、制約付き同期に使用される動作及び方法は必然的にコンピュータを必要とし、いずれの実施形態においても人間オペレータによる精神的ステップでは実行されない。更に、当該動作は、情報の格納及び取り出し、情報の送信及び送出、又は情報の処理のためにコンピュータの設備を利用しうるが、そのような動作が、本明細書では固有に定義されたデータに対して本明細書で説明されるアルゴリズムを用いて特定の方法で実行されるため、単なる汎用コンピュータの動作ではないこと、及び、それ故に、そのようなコンピュータがオペレーティングシステム及び標準的なアプリケーション単独によって自然にプロビジョニングされる方法とは異なる方法で、コンピュータを構成することを必要とすることを、当業者は理解する。また、必要とされる構成は、従来のオペレーティングシステム及びファイル管理システムが設定された一般的な汎用コンピュータ上で、以下で詳しく述べるステップを通じて、コンピュータのストレージ容量を強化する。

クライアントデバイス１００は、ネットワーク（図示せず）を通じてコンテンツ管理システム１１０と通信し、当該ネットワークは、コンテンツ管理システム１１０から遠く離れて配置されたクライアントデバイス１００間のインターネットワーキングを提供する任意の適切な通信手段であってもよく、例えば、ＬＡＮ、ＷＡＮ又はＷＡＮである。一般に、インストールされたクライアントアプリケーション２００Ａを有するクライアントデバイス１００Ａは、コンテンツ管理システム１１０へコンテンツアイテムを提供する。クライアントアプリケーション２００Ａは、ストレージ制約付き同期に関連する機能をクライアントデバイス１００Ａが実行するために必要なプログラム及びプロトコルを含む。したがって、クライアントデバイス１００Ａは、多くの場合、クライアントアプリケーション２００Ａによって要求された動作を実行する。しかし、クライアントデバイス１００Ａ及びクライアントアプリケーション２００Ａは一緒に動作するため、説明ごとに、それらの動作の一部は「クライアントデバイス１００Ａ」を動作エレメントとして参照されている。クライアントデバイス１００Ａのユーザは、クライアントデバイス１００Ｂと共有されるべき特定のコンテンツアイテムを指定しており、当該クライアントデバイス１００Ｂは、例えば、同じユーザによって管理される他のコンピュータであってもよいし、異なるユーザによって操作されるコンピュータであってもよい。コンテンツ管理システム１１０は、クライアントデバイス１００Ｂに通知し、クライアントデバイス１００Ａから受信した指定コンテンツアイテムを、クライアントデバイス１００Ｂに格納されたローカルコンテンツと同期させる。

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

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

クライアントデバイス１００又はコンテンツ管理システム１１０は、１つ以上のコンテンツアイテムを、後で取り出してクライアントデバイス１００に復元できるようにコンテンツ管理システム１１０に遠隔で保持しながら、ローカルストレージからの削除のために当該１つ以上のコンテンツアイテムを選択するよう構成される。通常、選択されるコンテンツアイテムは、コンテンツアイテムにアクセスする要求が行われた特定のクライアントデバイス１００上で、又はコンテンツアイテムが共有される全クライアントデバイス１００上で、最も長くアクセスされていないコンテンツアイテムであり、その他の選択方法については以下のセクションで更に説明する。クライアントベースの実施形態では、クライアントアプリケーション２００は、クライアントデバイス１００上に格納されている各共有コンテンツアイテムに対する最新のアクセスを特定する情報を保持する。ストレージに制約がある場合、クライアントアプリケーション２００は、最も長くアクセスされていない（least recently accessed）（以下、「ＬＲＡ」）コンテンツアイテムの１つ以上を選択する。ホストベースの実施形態では、コンテンツ管理システム１１０は、全てのコンテンツアイテムについてのアクセスデータを保持し、当該システム１１０は、コンテンツアイテムが共有される任意のクライアントデバイス１００上でコンテンツアイテムがアクセスされるたびに、この情報を更新する。ＬＲＡ選択は、ホストベースのシステム又はクライアントベースのシステムとしてそれぞれ実装可能な、可能性のある複数の放置コンテンツアイテム選択方法（unattended content item selection methods）（以下、「ＵＣＳＭ」）のうちの１つのみである。ＵＣＳＭは、各コンテンツアイテムが削除に適しているかどうかを判定するために、各コンテンツアイテムについてのｖｎｏｄｅリファレンスを調べうる。コンテンツアイテムごとのｖｎｏｄｅは、コンテンツアイテムへのアクセス数に関する情報と、コンテンツアイテムが現在使用されている又は開かれているか否かを含む、他のコンテンツアイテム・ステータス・インジケータとを含む。

簡潔のため、コンテンツアイテムを、ストレージの制約に応じてクライアントデバイス１１０上の常駐から削除のために選択するごとに、当該動作を本明細書では「放置コンテンツアイテムを選択する」と称し、これは、ＵＣＳＭの多くが、最も長くユーザによりアクセスされていないコンテンツアイテムを特定するよう動作するためである。放置コンテンツアイテムは、以下の説明で概説される任意のＵＣＳＭによって選択されるコンテンツアイテムを示す。

基本ＬＲＡ選択：基本ＬＲＡ選択を行うために、クライアントアプリケーション２００は、最新のローカルアクセス日で順序付けされたコンテンツアイテムのキューを保持し、最も長くアクセスされていないコンテンツアイテムが当該キューの先頭にある。コンテンツアイテムごとの最新のアクセス日時は、コンテンツアクセス履歴テーブル内に保持される。コンテンツアイテムへのアクセスは、コンテンツアイテムを作成する動作、開く動作、プレビューする動作、又は変更する動作を含む。任意の数のこれらの動作がアクセスとみなされてもよく、例えば、実施形態は、アクセスを、コンテンツアイテムを開く、変更する、又は保存することであるとしてもよく、ただし、コンテンツアイテムをプレビューすることはアクセスではないとしてもよい。キュー内で特定される最も長くアクセスされていないコンテンツアイテム（即ち、キューの先頭にあるコンテンツアイテム）から始まり、当該キューの最後にあるコンテンツアイテムで終わる、キュー内にリスト化されている各コンテンツアイテムについて、ストレージサイズの累積和（例えば、ランニング合計）が計算される。ストレージに制約がある場合、クライアントアプリケーション２００は、コンテンツアイテムを格納するのに要するストレージ空間の量を判定し、累積ストレージサイズがストレージ空間の要求条件を超えるコンテンツアイテムのインデックスを特定するために、そのようにしてキューを進める。特定されたインデックスは、クライアントデバイス１００上の共有コンテンツストレージ・ディレクトリ１２０からの削除のために、キュー内の当該インデックスを含み、当該インデックスを上回る全てのコンテンツアイテムを選択するために使用される。

表１では、これらのプロセスについて更に説明する。この例では、７５ＭＢのストレージが、コンテンツアイテムを格納するために必要とされる。コンテンツアイテムＡ及びＢのみでは合計で７０ＭＢであるため、これら２つのコンテンツアイテムの削除によってはコンテンツアイテムに対して十分な量のストレージを提供することはできない。したがって、対応するインデックス００、０１及び０２における、（一番右の欄の指定によって示されるように）１５０ＭＢの総累積サイズを有するコンテンツアイテムＡ、Ｂ及びＣが選択される。

リモートＬＲＡ選択：ＬＲＡ選択は、コンテンツ管理システム１１０を通じて、当該システム上のコンテンツアイテムへのアクセスを有する、又は当該コンテンツアイテムのバージョンを共有したクライアントデバイス１００上の当該コンテンツアイテムへのアクセスを有する他のユーザによるリモートアクセスにも基づきうる。これを実現するため、一実施形態では、各クライアントデバイス１００は、その独自のコンテンツアクセス履歴テーブルを、例えば、通常のコンテンツアイテム同期動作を行う間に、又はその他の時間に、コンテンツ管理システム１１０と同期させる。この実施形態は、各クライアントデバイス１００が、他のクライアントデバイスと共有するコンテンツアイテムごとに現在のアクセス情報を保持できるようにする。あるいは、ホストベースの実施形態では、コンテンツ管理システム１１０は、ＬＲＡ選択に使用するための現在の最新のリストを有するように、同期及び共有のために指定された全てのクライアントデバイスにわたって、コンテンツアイテムごとのアクセス履歴を含むコンテンツアクセス履歴テーブルを保持してもよい。リモートＬＲＡ選択は、更に、累積ストレージサイズが所要ストレージ空間を上回る、最も長くアクセスされていないコンテンツアイテムを、コンテンツ管理システム１１０が選択することを含む。この実施形態では、当該キューは、コンテンツアイテムに対して同期している全てのクライアントデバイスからの最新のアクセス時刻によって順序付けされる。

表２は、どのようにリモートＬＲＡが実装されうるかの例である。この例では、コンテンツアイテムＢ及びＣは、それぞれ５／２４／２０１４及び４／５に異なるクライアントデバイス上でリモートから最後にアクセスされているが、（表１にリスト化されているように）両方ともローカルでは３／２４／２０１４にアクセスされている。リモートアクセスに起因した、アイテムＢ及びＣについての最新のアクセス時刻のこの変化は、基本ＬＲＡ選択が使用される場合と比べて、それらのアイテムをキュー内で更に下へ移動させる。その結果、この例では、アイテムＡ、Ｂ及びＣに代えてアイテムＡ及びＢが選択される。

コンテンツアイテムサイズ選択：削除用のコンテンツアイテムを選択するために使用されうる他の要素は、そのサイズである。一実施形態において、クライアントデバイス１００からリモートで削除及び格納されるコンテンツアイテムの数を最小限にするために、サイズが使用される。これは、アクセス日時に代えてサイズで（最小から最大まで）キューの順序付けを行うことによって達成されうる。更に、所要ストレージ空間の値は、所要ストレージ空間を上回るサイズを有するコンテンツアイテムが特定されるまで、個別のサイズと比較されうる。クライアントアプリケーション２００は、その後、当該コンテンツアイテムを削除用に選択しうる。所要ストレージ空間より大きな単一のコンテンツアイテムが無い場合、最大のコンテンツアイテムが選択されて、そのサイズが所要ストレージ空間の値から差し引かれ、キューの最初からプロセスが繰り返されることになろう。

表３は、このセクションの方法の例である。この例では、４０ＭＢのストレージが、コンテンツアイテムを格納するために必要とされる。アイテムＢは、４０ＭＢの所要ストレージ空間の値を上回る、キューインデックスでの一番目のコンテンツアイテムであり、それ故に、当該コンテンツアイテムはクライアント１００からの削除のために選択される。

コンテンツアイテムサイズ及びアクセス時刻ベースの選択：ここで説明したサイズ選択方法は、場合によっては、頻繁にアクセスされるコンテンツアイテムを削除用に選択してもよい。サイズ及びアクセス時刻の両方を考慮することで、コンテンツ管理システムは、近いうちにユーザによって要求されうるコンテンツアイテムを、クライアントデバイス１００から削除することを避けることが可能である。一実施形態において、二変数選択方法は、各コンテンツアイテムが所要のストレージ割り当てに達することに寄与するストレージ量と、その最後のアクセス時刻とに基づいて、コンテンツアイテムごとに重み付けされたスコアを計算することによって実現される。例えば、
スコア＝ｗ₁Ｓ＋ｗ₂Ａ
であり、ここで、Ｓは、コンテンツアイテムのサイズを表すメトリックであり、Ａは、当該コンテンツアイテムへの最後のアクセスからの時間を表すメトリックであり、ｗ₁及びｗ₂は、重みである。Ａ及びＳに対する重みは、ユーザ又はシステム管理者によって定められるような、それらの相対的な重要度に基づいてもよいし、あるいは、特定のクライアントデバイス１００上でのコンテンツアイテムに対するそれまでのコンテンツアイテム・アクセスパターンに基づいてもよい。更に、キューは、スコアによって順序付けされ、キュー内の一番目のコンテンツアイテムが削除用に選択される。

以下の表４には、この選択方法の実装例が示されている。この簡易な例のために、アクセス時刻メトリックＡは、現在の時刻と特定のコンテンツアイテムに対する最後のアクセスとの差分と、現在の時刻と最も長くアクセスされていないアイテムのアクセスとの差分の比である（このケースにおいて使用された日付は９／３／２０１４）。この例では、サイズメトリックは、以下の関係である。
ｓ≧ｒの場合：Ｓ＝ｒ／ｓ
ｓ＜ｒの場合：Ｓ＝ｓ²／ｒ²
ここで、ｓは、コンテンツアイテムのサイズであり、ｒは、所要ストレージ空間であり、Ｓは、サイズメトリックである。この区分関数は、ｓ＝ｒの場合に最大の１を有する。

表４に示された例では、所要ストレージ空間は４０ＭＢであり、重みｗ₁及びｗ₂は両方とも１である。サイズメトリック及びアクセス時刻メトリックが計算され、その後、合計スコアをコンテンツアイテムごとに計算するために使用される。この例では、アイテムＢが、最大スコアを有しており、それ故に、クライアントデバイス１００からの削除用に選択される。選択されたコンテンツアイテムが、所要ストレージ空間よりも小さいサイズを有する場合、新たな所要ストレージ空間が、古い所要ストレージ空間と、最初に選択されたコンテンツアイテムのサイズとの差分として計算され、新たに計算された所要ストレージ空間を用いて、全てのコンテンツアイテムに対してスコアが再計算されて新たなキューが生成され、選択プロセスが繰り返される。

アクセス頻度及び最新性選択：放置コンテンツアイテムをより好ましく選択するために、アクセス時刻に加えて、頻度等の他の要素が考慮されてもよい。高頻度・低最新性のコンテンツアイテムは、過去のあるときには頻繁に選択されていたが（例えば、７ヶ月以上前）、最近はそうではないコンテンツアイテムであり、低頻度・低最新性のコンテンツアイテムは、頻繁にアクセスされたことがないコンテンツアイテムである。アクセスの頻度は、特定のクライアントデバイスにおける、又はクライアントデバイスの任意の集団にわたる、又はタイプ、ネームスペース、ソースドメイン、若しくはその他のコンテンツアイテム属性による、平均頻度に対して測定される。例えば、コンテンツアイテムが最近４か月においてクライアントデバイス上でアクセスされていないが、それより前に２５回アクセスされたことがある場合、過去に１回だけアクセスされた、同様の最新性のコンテンツアイテムよりも、ユーザに関連している可能性がある。

一実施形態では、各コンテンツアイテムに対する最新のアクセスに加えて、コンテンツアイテムごとのアクセス数が（クライアントデバイス１００又はコンテンツ管理システム１１０）で保持される。各変数を表すメトリックの重みづけ合成として、コンテンツアイテムごとにスコアが判定される。例えば、コンテンツアイテムごとの重み付けされたスコアは、コンテンツアイテムのアクセス頻度のメトリック及びその最新のアクセス日時に基づく。例えば、
スコア＝ｗ₁Ｆ＋ｗ₂Ａ
であり、ここで、Ｆは、アクセス頻度を表すメトリックであり、Ａは、コンテンツアイテムへの最後のアクセスからの時間を表すメトリックであり、ｗ₁及びｗ₂は、重みである。Ａ及びＦに対する重みは、ユーザ又はシステム管理者によって定められるような、それらの相対的な重要度に基づいてもよいし、あるいは、特定のクライアントデバイス１００上でのコンテンツアイテムに対するそれまでのコンテンツアイテム・アクセスパターンに基づいてもよい。更に、キューはスコアによって順序付けされる。累積和が、各インデックスにおいて計算され、所要ストレージ空間と比較される。累積和が所要ストレージ空間を上回る場合、インデックスとキュー内で当該インデックスより上の全てのコンテンツアイテムとが、クライアントデバイス１００からの削除のために選択される。

表５は、このセクションの方法の一例を示している。この例では、所要ストレージ空間は４０ＭＢであり、重みｗ₁及びｗ₂は両方とも１である。キューは合計スコアによって順序付けされ、累積和は所要ストレージ空間と比較される。その結果、アイテムＣ及びＥが、クライアントデバイス１００からの削除用に選択される。

上記のＵＣＳＭのいずれも、個別のファイルのみに代えて、単一キューインデックス内のフォルダ全体を考慮してもよい。例えば、ＬＲＡ ＵＣＳＭが使用中であり、かつ、フォルダが複数のファイルを含み、当該フォルダ内でごく最近アクセスされたファイルが、共有コンテンツディレクトリ内の他の全てのコンテンツアイテムよりも早いアクセス日時を有する場合に、（特に、かなりのストレージ空間が必要とされる場合に）フォルダ全体を、放置されているものとして選択することがより効率的でありうる。あるいは、当該フォルダに対する合成メトリックは、平均値、中央値、又は、フォルダ内のコンテンツアイテムを一般化する他の統計値であってもよく、それをキュー内に置くことが可能になる。

以下の説明では、上述の方法は、放置コンテンツアイテムをクライアントデバイス１００からの削除用に選択するために使用されうる。放置コンテンツアイテムを選択するこのプロセスにより、制約付きコンテンツ管理システム１１０によって提供されるような、クライアントデバイス上の改善されたストレージ能力が実現される。

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

コンテンツ管理システム１１０は、コンテンツアイテムをデータストア２１８に格納する。コンテンツアイテムは、ブロックと称される固定サイズ部分に格納される。ブロックのサイズは、実装に応じて変化し、一実施形態ではブロックは４メガバイトのサイズである。このため、小さいコンテンツアイテムは単一のブロックとして格納される一方、大きいコンテンツアイテムは、コンテンツ管理システム１１０におけるストレージのために数十、数百、又はそれ以上の数のブロックに分割されうる。メタデータは、コンテンツアイテム内のブロックと、当該コンテンツアイテム内のブロックの順序とを定めるブロックリストを含む。

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

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

メタデータサーバ２１２は、クライアントからの、新しいコンテンツアイテムをコンテンツ管理システム１１０へ追加（「収容」）することを求める要求を管理する役割を担う。メタデータサーバ２１２は更に、コンテンツアイテムを同期させることを求める要求をクライアントデバイス１００から受信する。メタデータサーバ２１２は、クライアントデバイス１００がコンテンツ管理システム１１０と同期した、前回のレコードを保持する。クライアントデバイス１００から同期要求が受信されると、メタデータサーバ２１２は、前回の同期のタイムスタンプ以降に、クライアントデバイス１００へ同期したネームスペースに収容されたコンテンツアイテムを判定する。また、メタデータサーバ２１２は、前回の同期のタイムスタンプ以降に受信されたペンディングブロックを判定する。

通知サーバ２１６は、クライアントと通信する役割を担い、具体的には、新しいデータが利用可能であることをクライアントに通知する。通知サーバ２１６は、ネームスペース・テーブル２２２の各ネームスペースに関連付けられているクライアント１１０のリストを保持する。新しいブロックが所与のネームスペースに対して利用可能であるとの、ブロックサーバ２１４又はメタデータサーバ２１２からのアラートを、通知サーバ２１６が受信すると、通知サーバ２１６は、ネームスペース・テーブル２１２から、当該ネームスペースに関連するクライアントを識別する。通知サーバ２１６は、当該ネームスペースに関連する（複数の）クライアント１００と活動させるために当該（複数の）クライアントに通知し、識別されたネームスペースに対して新しいブロックが利用可能であることを知らせる。

２つのクライアント１００間の典型的な同期は、クライアントデバイス１００Ａとクライアントデバイス１００Ｂに以下のように生じる。まず、クライアントデバイス１００Ａは、追加のコンテンツアイテムを共有データに追加する。その後、追加のコンテンツアイテムは、コンテンツ管理システム１１０へ送信される。コンテンツ管理システム１１０は、追加のコンテンツアイテムが共有データ内にあることをクライアントデバイス１００Ｂに通知し、クライアントデバイス１００Ｂは、当該追加のコンテンツアイテムを、コンテンツ管理システム１１０からクライアントデバイス１００Ｂとして取り出す。コンテンツ管理システム１１０は、コンテンツアイテムのリストと、コンテンツ管理システム１１０で受信される予定のペンディングブロックとを、ペンディングブロック・テーブル２２０を用いて保持し、コンテンツ管理システム１１０によってブロックとして受信されるコンテンツアイテムに対応するブロックをダウンロードするよう、クライアントデバイス１１０Ｂに通知する。ペンディングブロックは、コンテンツ管理システム１１０が受信する予定のコンテンツアイテムに対応するブロックであり、コンテンツアイテムがコンテンツ管理システム１１０に収容される前に受信クライアントデバイス１００Ｂに提供されうるブロックを識別するために使用される。

送信中のコンテンツアイテムを管理するために、コンテンツ管理システム１１０は、ペンディングブロックのリストを、当該ペンディングブロックと関連するネームスペースとともに持ち続ける。ペンディングブロックの受信時に、ネームスペースに関連するクライアントは通知を受けて、受信ブロックについての転送を開始できる。このため、（新しいコンテンツアイテムを提供する）アップロードするクライアントと（当該新しいコンテンツアイテムを受信する）ダウンロードするクライアントは、非同期でコンテンツ管理システム１１０へブロックを転送しうる。

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

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

共有データ３６４は、コンテンツ管理システム１１０と同期化されたデータであり、コンテンツ管理システム１１０から受信されたコンテンツアイテムを含む。ユーザが、共有データ３６４におけるコンテンツアイテムの追加、変更、又は削除を行った場合、それらの変更は、コンテンツ管理システム１１０と同期させられる。ハッシュ化モジュール３２０及びブロックキャッシュ３７０は、コンテンツ管理システム１１０へアップロードされるコンテンツアイテムを含むブロックを識別するよう動作する。ハッシュ化モジュールは、ＭＤ５又はＳＨＡ−１といった、任意の適切なハッシュ化アルゴリズムを実行することで、ブロック識別子を割り当てる。コンテンツ同期モジュール３１０は、その後、これらの識別子を、ブロックキャッシュ３７０内にある常駐ブロックを、コンテンツ管理システム１１０によって保持されるブロックと比較するために使用する。これらのモジュールは現在の実施形態に存在するが、このブロックの実装はストレージ制約付き同期の発明には必要ではない。

クライアントアプリケーション２００内で、クライアントデバイス１００上の共有データ３６４へのデータの追加又はデータの変更が行われると、共有データ３６４への変更は、コンテンツ管理システム１１０へ送信される。クライアントデバイス１００は更に、コンテンツ管理システム１１０から通知を受信するよう構成される。クライアントデバイス１００が通知を受信すると、クライアントデバイス１００は、共有データ３６４に対する変更についてコンテンツ管理システム１１０に問い合わせを行う。共有データが変更された場合、クライアントデバイス１００は、当該共有データをクライアントデバイス１００上に格納するために、コンテンツ管理システム１１０に変更情報を要求する。場合によっては、変更されたデータは、シャドウアイテムによって表されるコンテンツアイテムに関連していてもよい。この場合、クライアントデバイス１００は、シャドウアイテムによって表されるコンテンツアイテムへのアクセスが、クライアントデバイス１００上のアプリケーションによって要求されるまで、変更されたデータについてのコンテンツ管理システム１１０への要求を控えてもよい。あるいは、共有コンテンツアイテムが他のクライアントデバイス１００によって変更された場合、コンテンツ管理システム１１０は、制約のあるクライアントデバイスに常駐している他のコンテンツアイテムを代償にして変更の同期化ができるように、シャドウアイテムによって表されるコンテンツアイテムを制約のあるクライアントデバイス１００が復元することを要求してもよい。

クライアントアプリケーション２００内では、ファイルジャーナル３６０は、クライアントアプリケーション２００を用いてアカウントがアクセス可能な全てのコンテンツアイテムについてのメタデータをリスト化するテーブルを格納する。メタデータは、各コンテンツアイテムに対応する改訂日時、ネームスペース、及びブロックリストを含む。常駐していない又は同期化されていないコンテンツアイテムは、それでもファイルジャーナル３６０に含まれる。

常駐ファイルテーブル３６２は、ストレージの制約には関係なく、常にクライアントデバイス１００に常に常駐し続けているファイルのリストを格納する。

リモートファイルテーブル３６６は、クライアントデバイスから削除されてシャドウアイテムと置き換えられるように選択されたファイルのリストを格納する。これらのファイルは、コンテンツ管理システム１１０によってのみ保持され、場合によっては当該ファイルにアクセス可能な他のユーザによって保持される。

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

ストレージカーネル拡張３８４は、コンテンツアイテムにアクセスするためのアプリケーションからオペレーティングシステム３８０への要求をモニタリングし、要求されたコンテンツアイテムがシャドウアイテムであるか否かを判定するように構成され、この機能を実行する一手段である。ストレージカーネル拡張３８４は、クライアントデバイス上の有効ストレージ容量の増加を可能にする、オペレーティングシステムの構成及び機能に対する直接の変更を構成する。

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

カーネル拡張３８４は、要求されたコンテンツアイテムがシャドウアイテムであるかを、そのサイズが閾値サイズを下回るかを判定することによって判定する。代替的には、シャドウアイテムの識別は、クライアントアプリケーション２００によって管理されるコンテンツアイテムについての拡張されたファイル属性に基づいて達成されうる。カーネル拡張が、要求されたコンテンツアイテムのサイズを調べることなくシャドウアイテムを識別できるように、シャドウアイテムを示すファイル属性がシャドウアイテムに対して割り当てられうる。ファイルがシャドウアイテムであるとカーネル拡張３８４が判定した場合、カーネル拡張は、識別情報をクライアントアプリケーション２００へ伝える。

図４は、クライアントデバイス１００に常駐はしていないがあたかもクライアントデバイス１００上に常駐しているかのようにファイルシステムに含まれるコンテンツアイテムにアクセスするためのプロセスの一実施形態を示す、インタラクションダイアグラムである。ファイルシステム３８２は、クライアントデバイス１００上の同期フォルダ内のコンテンツアイテムを開くことを求める要求を受信する（４００）。当該要求は、ファイルエクスプローラ、ワードプロセッサ、ドキュメントリーダ、イメージエディタ等の、任意のアプリケーションから生じうる。ストレージカーネル拡張３８４は、そのようなファイルシステム要求をインターセプトし、要求されたコンテンツアイテムのパス名を取得する（４０２）。ストレージカーネル拡張３８４は、パス名を使用して、コンテンツアイテムがシャドウアイテムであるかどうかを判定する（４０４）。ストレージカーネル拡張３８４は、要求されたコンテンツアイテムのサイズをチェックして、当該サイズが所定の閾値を下回るかどうか、さもなければシャドウアイテムのサイズ（４ＫＢ）と一致するかどうかを判定することによって、それを行う。あるいは、ストレージカーネル拡張３８４は、コンテンツアイテムがシャドウアイテムであるか、正規のコンテンツアイテムであるかを示す値を格納したファイル属性拡張を読み込みうる。コンテンツアイテムがシャドウアイテムではない場合、ストレージカーネル拡張３８４は、要求を通常どおりに続けさせ、当該コンテンツアイテムを開くことが可能になるよう、ファイルシステムに対してファイル・ハンドルを与える。

コンテンツアイテムがシャドウアイテムであるとの判定に応じて、ストレージカーネル拡張４８４は、要求識別番号（要求タイプを含む要求に関する情報）とファイルパスとを管理モジュール３５０へ送り、ファイル名を渡す（４０６）。ストレージ管理モジュール３５０は、リモートファイルテーブル３６６からファイル名を削除する（４０８）。ストレージ管理モジュール３５０は、その後、コンテンツ管理システム１１０からの同期を必要とするコンテンツアイテムをチェックするダウンロードスレッドを立ち上げる。要求されたコンテンツアイテムはリモートファイルテーブルから削除されているため（４０８）、ダウンロードスレッドは、ここで、ダウンロードに備えて、要求されたコンテンツアイテムのサイズを含む、コンテンツアイテム情報を、コンテンツ管理システム１１０に要求する（４１４）。ストレージ管理モジュール３５０は、サイズ情報をコンテンツ管理システム１１０から受信し（４１６）、クライアントデバイス１００へのコンテンツアイテムの格納により、所定のストレージ上限を超過することが生じるかどうかを判定する（４１８）。要求されたコンテンツアイテムの追加によってストレージ上限を超過する場合、ストレージ管理モジュール３５０は、クライアントデバイス１００に格納されている１つ以上のコンテンツアイテムを削除用に選択する（４２２）。しかし、ストレージ上限を超過しない場合、ストレージ管理モジュール３５０は、コンテンツアイテムのダウンロードに進む。

要求されたコンテンツアイテムの共有コンテンツストレージ・ディレクトリ１２０への追加によってストレージ割り当て１３０を超過する場合には、ストレージ管理モジュール３５０は、ダウンロードの要求（４３０）の前に、要求されたコンテンツアイテムに対して十分なストレージ空間を使用可能にするために、削除のために１つ以上のコンテンツアイテムを選択し、それにより、共有コンテンツディレクトリが、割り当てられた空間を超えて常に占有することを防止する。ストレージ管理モジュール３５０は、上述のＵＣＳＭのいずれかを使用して、放置コンテンツアイテムを最初に判定することで（４２０）、削除用のコンテンツアイテムを選択する（４２２）。特定のコンテンツアイテムのアクセス履歴又は各選択方法に関連する他の情報が、ホストシステムに格納されている場合、その情報のクライアントアプリケーション３００のバージョンを更新するよう求める要求が、当該ホストシステム（図４には図示せず）に対して行われる。コンテンツ管理システム１１０内のコンテンツアイテムごとのアクセス履歴又は他の必要な情報の最新バージョンが一旦取得されると、ストレージ管理モジュール３５０は、放置コンテンツアイテムを判定できる（４２０）。

その後、ストレージ管理モジュールは、クライアントデバイスから削除用の放置コンテンツアイテムを選択する（４２２）。この実施形態では、削除のためのコンテンツアイテムを選択（４２２）するために、ストレージ管理モジュール３５０は、使用中のＵＣＳＭによって生成されたキューをトラバースして、少なくともダウンロード対象の要求されたコンテンツアイテムのサイズと同じ大きさのストレージ空間を作り出す。削除用の放置コンテンツアイテムの選択は、上述の方法のいずれかを用いて行うことが可能である。

ストレージ管理モジュール３５０は、その後、選択されたコンテンツアイテムの名前をリモートファイルテーブル３６６に加える（４２４）。一旦、この追加（４２４）が確認されると（４２６）、ストレージ管理モジュール３５０は、選択されたコンテンツアイテムを、クライアントデバイス上の共有コンテンツストレージ・ディレクトリ１２０から削除し（４２８）、その後、削除されたコンテンツアイテムごとに、当該削除されたコンテンツアイテムと同じメタデータ及びロケーションを有するが、当該コンテンツアイテムについてのコンテンツ情報を含まない、対応するシャドウアイテムを作成する。シャドウアイテムは、クライアントのユーザインタフェース内で、あたかもクライアントデバイス１００上に依然として常駐しているかのように表現されうる。図８は、クライアントデバイス１００のユーザインタフェース内でシャドウアイテムがどのように表現されうるかの例を示している。

選択されたコンテンツアイテムの削除に応じて、十分なストレージ空間がクライアントデバイス１００上に生じ、共有コンテンツストレージ・ディレクトリ１２０のストレージ上限を超過することなく、要求されたコンテンツアイテムがコンテンツ管理システム１１０からダウンロードすることが可能である。したがって、ストレージ管理モジュール３５０は、ダウンロード要求をダウンロードモジュール３３０へ送る（４３０）。ダウンロードモジュール３３０は、その後、コンテンツ管理システム１１０からのダウンロードを始める（４３２）。一旦、コンテンツアイテムがダウンロードモジュール３３０へダウンロードされると（４３４）、当該コンテンツアイテムはストレージ管理モジュール３５０へ渡され（４３６）、ストレージ管理モジュール３５０は、要求されたコンテンツアイテムを、以前に特定されたロケーションに保存し（４３８）、ダウンロードが完了したことをストレージカーネル拡張３８４へ通知する（４４０）。一実施形態において、ストレージ管理モジュール３５０は、ダウンロードされたコンテンツアイテムのコンテンツを、シャドウアイテムのメタデータに付加し、コンテンツアイテムが現在、もはやシャドウアイテムではないことを示すためにようにコンテンツアイテム属性を更新する。これにより、要求アプリケーションが、コンテンツアイテムへのアクセスを当初要求するために使用した同じファイル・ハンドル及び識別情報を使用して、要求されたコンテンツアイテムに透過的にアクセスすることが可能になる。ストレージカーネル拡張３８４は、その後、ファイル・ハンドルをファイルシステム３８２に渡し（４４２）、当該ファイルシステムは、要求アプリケーションに、コンテンツアイテムを開くためのパーミッションを与える（４４４）。

図５は、ストレージ割り当て１３０に近づいている共有コンテンツストレージ・ディレクトリ１２０にコンテンツアイテムを保存するプロセスの一実施形態を示すインタラクションダイアグラムである。当該コンテンツアイテムは、共有コンテンツストレージ・ディレクトリ１２０内に新たに作成されたコンテンツアイテム、共有コンテンツストレージ・ディレクトリ１２０に移動させられたコンテンツアイテム、又は、共有コンテンツストレージ・ディレクトリ１２０に既に存在し、その後にサイズが増加するように変更されたコンテンツアイテムでありうる。プロセスは、アプリケーションが、同期フォルダ内にコンテンツアイテムを保存することを求める要求を、ファイルシステム３８２のオペレーティングシステムに対して行う（５００）ことから始まる。ストレージカーネル拡張３８４は、ファイルシステムから、この要求をモニタリングし、要求ＩＤ、ファイルパス、及びサイズを受け付ける（５０２）。次に、ストレージカーネル拡張３８４は、この情報をストレージ管理モジュール３５０へ送る（５０４）。ストレージ管理モジュールは、新しいコンテンツアイテムの追加によって、同期フォルダがそのストーレージ上限を超過することが生じるかどうかを判定する（５０６）。ストレージ上限を超過しない場合、ファイルシステム３８２は、コンテンツアイテムを通常どおり保存することを許可される。ストレージ上限を超過する場合、ストレージ管理モジュール３５０は、放置コンテンツアイテムを判定し（５０８）、それをクライアントデバイスからの削除用に選択する。一旦、放置コンテンツアイテムが選択されると、そのコンテンツがコンテンツ管理システム１１０によって同期させられないように、その名前がリモートファイルテーブル３６６に追加される（５１２）。次に、ストレージ管理モジュールは、選択されたコンテンツアイテムをクライアントデバイス１００から削除し、それを、削除されたコンテンツアイテムと同じメタデータ及びロケーションを有するがコンテンツを含まないシャドウアイテムに置き換える（５１４）。このプロセスが完了した際、ストレージ管理モジュールが、元のコンテンツアイテムを保存するために（５１６）十分なストレージ空間が、制約付きフォルダ内に存在する。次に、ストレージ管理モジュールは、アップロードスレッドを立ち上げ（５１８）、当該アップロードスレッドは、保存されたコンテンツアイテムのコンテンツがコンテンツ管理システム１１０にアプロード（５２２）されるよう、メタデータにアクセスする（５２０）。

コンテンツアイテムの削除及びシャドウアイテムの作成を自動的に行うのに加えて、いくつかの実施形態は、更に、コンテンツ管理システム１１０上のみにリモートで格納すべき特定のコンテンツアイテムをユーザが選択することを可能にする。これは、単純に、特定の同期済みコンテンツアイテム上でコンテキストメニュー（例えば、「右クリック」）からユーザが選択できるようにすることで実現されうる。次に、クライアントアプリケーション２００は、ユーザに対して、選択されたコンテンツアイテムをリモートにするためのオプションを提示しうる。ユーザがこのオプションを選択した場合、コンテンツアイテムが、クライアントデバイス１００から削除され、当該コンテンツアイテムの名前が、リモートファイルテーブル３６６に加えられ、元のコンテンツアイテムと同じメタデータ及びロケーションを有するシャドウアイテムが、元のコンテンツを表すために作成される。将来、ユーザが当該コンテンツアイテムにアクセスすることを望んだ場合、コンテンツ管理システム１１０からコンテンツアイテムを取り出すために、図５で説明した同じプロセスが使用されうる。

いくつかの実施形態において、クライアントデバイスは、ストレージ割り当て１３０に達した際に、さもなければＵＣＳＭによって実際に特定のコンテンツアイテムがクライアントデバイス１００からの削除用に選択されるかどうかにかかわわらず、クライアントデバイスに常駐し続けるように当該特定のコンテンツアイテムをユーザが選択できるよう構成される。本実施形態は、特定の重要なコンテンツアイテムへの素早いアクセスをユーザが維持することを可能にする、操作の改善をもたらす。本実施形態では、クライアントアプリケーション２００は、ユーザが、コンテキストメニューにアクセスし、次に、コンテンツアイテムがクライアントデバイス１００に常駐し続けることを強制するオプションを選択できるようにする。選択に応じて、コンテンツアイテムの名前が常駐ファイルテーブル３６２に追加される。常駐ファイルテーブル３６２は、それ以降、４２２に示されるストレージ管理モジュール３５０によって使用されるＵＣＳＭの間にアクセスされ、テーブル内の全てのコンテンツアイテムが、選択プロセスから除外される。例えば、所与のコンテンツアイテムが削除用に選択された場合、常駐ファイルテーブル３６２は、選択されたコンテンツアイテムがその中にリストされているかどうかを判定するために調べられ、リストされている場合、選択されたコンテンツアイテムは無視され、他のコンテンツアイテムが実際にＵＣＳＭによって選択される。

クライアントデバイス１００上でシャドウアイテムに関連付けられたコンテンツは同期化されないため、コンテンツの管理がより複雑になりうる。例えば、１つのクライアントデバイスでユーザが、シャドウアイテムとして示されたコンテンツアイテムを第２のクライアントデバイスに移動させた場合において、当該第２のクライアントデバイスが、当該シャドウアイテムに関する同期用データを受信していないときには、そのロケーションは、第１のクライアントデバイスでは変化しうるが他のクライアントデバイスでは変化しえない。例えば、コンテンツアイテムは、異なるクライアントデバイス１００上でシャドウアイテムによって示されている間に、１つのクライアントデバイス１００によってコンテンツ管理システム１１０から完全に削除されることがある。この状況が生じた場合に、第２のクライアントデバイス１００のユーザは、シャドウアイテムによって示されるコンテンツアイテムへのアクセスにアクセスして、それがもはや存在しないことのみを発見しうる。こうした紛らわしい状況を避けるために、いくつかの実施形態において、コンテンツ管理システム１１０は、シャドウアイテムをメタデータのみについて同期させるよう構成され、即ち、シャドウアイテムの属性のいずれかが変化した場合に、コンテンツ管理システム１１０は、クライアントデバイスのいずれかにおいてコンテンツアイテムがシャドウアイテムとして示されているかどうかにかかわらず当該コンテンツアイテムにアクセス可能な全てのクライアントデバイス１００に対して、変更された属性を同期させる。これにより、１つのクライアントデバイスからコンテンツアイテムが削除された場合に、他の任意のクライアントデバイス１００上で、当該コンテンツアイテムを表すシャドウアイテムが同様に削除される。あるいは、いくつかの実施形態において、他のクライアントデバイス上で、コンテンツアイテムが、クライアントデバイス１００上の共有コンテンツストレージ・ディレクトリ１２０内の残りのストレージの範囲内に収まれることができるようにサイズが変化するよう、変更された場合に、当該コンテンツアイテムは、当該コンテンツアイテムへのアクセスが要求されていなくともクライアントデバイス１００へダウンロードされうる。

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

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

図８は、制約付き同期を提供するコンテンツ管理システムと連携して動作するクライアントデバイス１００のユーザインタフェースの例を示す。同期ファイルフォルダ８００は、共有コンテンツストレージ・ディレクトリ１２０として機能する。フォルダ８００は、対応したアイコン８１０Ａ（.m4a音楽ファイル）、アイコン８１０Ｂ（.xlsスプレッドシート）、アイコン８１０Ｃ（.docx文書処理ファイル）、アイコン８１０Ｄ（.mat Matlabファイル）、及びアイコン８１０Ｅ（.jpg画像ファイル）によってそれぞれ表される、複数のコンテンツアイテムを含む。各アイコン８１０には、コンテンツアイテムのストレージステータスを示すステータスアイコン８２０が重ねられている。

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

ステータスアイコン８２０Ｂは、コンテンツ管理システム１１０との同期が完了した時点でクライアントデバイス１００に常駐することになることを示す。

ステータスアイコン８２０Ｃは、コンテンツアイテムが、シャドウアイテムであり、かつ、現在、クライアントデバイスに常駐していないがコンテンツ管理システム１１０上には依然として保持されていることを示す。

ステータスアイコン８２０Ｄは、コンテンツアイテムが現在、クライアントデバイス１００上に常駐しており、かつ、コンテンツ管理システム１１０によって保持されているバージョンと同期していることを示す。更に、ピンアイコン８４０を有する緑の円は、コンテンツアイテムが、ストレージ制約の間にクライアントデバイス８００上に常駐し続けるように選択されていることを示す。

図９は、クライアントデバイスに対してリモートの特定のコンテンツアイテムへのユーザアクセスを予測して、予測したコンテンツアイテムを、アクセスに先立ってダウンロードする、制約付き同期の代替の実施形態を示す。このアプローチは、ネットワークを介してコンテンツ管理システム１１０からコンテンツアイテムを取り出すためにユーザが待つ必要がある時間を、ほとんどの場合に削減することによって、クライアントデバイスの動作の更なる改善をもたらす。リテンションスコア９００は、共有コンテンツストレージ・ディレクトリ１２０内の各コンテンツアイテム１４０に対して計算される。このスコアは、コンテンツアイテムの予測重要度の測度であり、最新のアクセス時刻の関数として、又は以降のセクションで説明されるように、ユーザの要求を予測すると判定される他の要素の関数として計算されうる。更に、各コンテンツストレージ・ディレクトリ１２０には、ユーザによって指定又は予め定められた値として設定されうるリテンションスコア閾値９１０が設定される。同じコンテンツアイテムのリテンションスコア９００によって測定される、コンテンツアイテムの予測重要度が、当該コンテンツアイテムにアクセス可能なクライアントデバイス１００上の特定の共有コンテンツストレージ・ディレクトリ１２０のリテンションスコア閾値９１０を超えるごとに、当該コンテンツアイテムがクライアントデバイスに対してリモートにある場合には、当該コンテンツアイテムは共有コンテンツストレージ・ディレクトリへダウンロードされ、当該コンテンツアイテムがクライアントデバイスに常駐している場合には、当該コンテンツアイテムは共有コンテンツストレージ・ディレクトリ内に保持される。

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

更に、各コンテンツアイテム１４０は、対応するリテンションスコア９００を有し、９００Ａはコンテンツアイテム１４０Ａについてのリテンションスコアであり、９００Ｂはコンテンツアイテム１４０Ｂについてのリテンションスコアである等である。各共有コンテンツストレージ・ディレクトリには、更に、リテンションスコア閾値９１０が設定されており、９１０Ａは共有コンテンツストレージ・ディレクトリ１２０Ａについてのリテンションスコア閾値であり、９１０Ｂは共有コンテンツストレージ・ディレクトリ１２０Ｂについてのリテンションスコア閾値である。

ステージ９．１で、コンテンツアイテム１４０Ａは、共有コンテンツストレージ・ディレクトリ１２０Ｂには保持されていない。このケースでは、共有コンテンツストレージ・ディレクトリ１２０内に常駐した、リテンションスコア閾値９１０より低いリテンションスコア９００を有する、コンテンツアイテムは存在しないが、このシナリオは、これまでに又は以降のセクションで説明される他の実施形態からの特徴が、本実施形態からの特徴に加えて使用される場合にあり得る。例えば、ストレージ割り当てが依然として影響しうるとともに、ストレージ割り当てが十分に大きい場合には、リテンションスコア閾値９１０より低いリテンションスコア９００を有していてもファイルをリモートにし続ける必要はないことがある。
ステージ９．２で、クライアントデバイス１００Ａのユーザは、クライアントデバイス１４０Ａへのアクセスとみなされるユーザアクション９２０を、コンテンツアイテム１４０Ａに対して実行する。この例では、リテンションスコア９００は、最新のアクセス時刻の関数として計算され、コンテンツアイテム１４０Ａのリテンションスコア９００Ａは、２０から６０に増加する。（この変化の大きさは、この例のために任意である。リテンションスコアの計算の詳細は、後ほど提供され、同じスコアの変化が得られることはない。）
ステージ９．３で、コンテンツ管理システム１１０は、又はいくつかの実施形態ではクライアント１００Ｂ上のクライアントアプリケーションは、コンテンツアイテム１４０Ａのリテンションスコア９００Ａが、コンテンツアイテムがリモートにある共有コンテンツストレージ・ディレクトリ１２０Ｂのリテンションスコア閾値９１０Ｂ以上であると判定する。リテンションスコア９００Ａがリテンションスコア閾値９１０Ｂを超えているため、コンテンツアイテム１４０Ａは、クライアントデバイス１００Ｂへダウンロードされて共有コンテンツストレージ・ディレクトリ１２０Ｂに格納される。

ＵＣＳＭと同様、複数のリテンションスコア計算方法が存在する。一般に、リテンションスコアは、ユーザ動作属性に対して正規化でき、それにより、同じコンテンツアイテムに対して、クライアントデバイスごとに異なるリテンションスコア又は各クライアントデバイスについてスコアが同じになるグローバルなリテンションスコアが得られる。正規化リテンションスコアの利点は、ユーザ動作の相違を均すことである。例えば、リテンションスコアが、コンテンツアイテムの最新のアクセス時刻の関数であり、現在時刻と最新のアクセス時刻との間の時間が減少するにつれてスコアが増加する場合には、よりアクティブなユーザと共有されるコンテンツアイテムのリテンションスコアは、それほどアクティブではないユーザと共有されるコンテンツアイテムに比べて、当該アクティブなユーザによって押し上げられる。アクティブなユーザ及びそれほどアクティブではないユーザの両方と共有する、第３のユーザに対してリテンションスコアが正規化されていない場合には、当該リテンションスコアは予測品質を失い、これは、それほどアクティブではないユーザによる最近のアクセスよりも、第３のユーザによるアクセスについて予測的ではなくても、アクティブなユーザからのアイテムのみが最大のリテンションスコアを有するためである。リテンションスコアが正規化されるごとに、それは、特定のユーザ又は特定のコンテンツアイテムの属性に正規化されうる。

以下の方法は、リテンションスコア、又はコンテンツアイテムへのユーザアクセスを予測するスコアを決定する方法の例である。更に、リテンションスコアは、予測重要度の最も予測的な測度を作り出すために以下の方法の組み合わせを使用してもよい。典型的には、リテンションスコアは、コンテンツアイテムの予測重要度が増加するにつれて増加するが、その逆は、実施形態に都合が良い場合に同様である。この場合、対応するリテンションスコア閾値は最小となり、コンテンツアイテムのリテンションスコアがリテンションスコア閾値以下である場合に、対応する共有コンテンツストレージ・ディレクトリにダウンロードされうる。この説明のために、リテンションスコアが増加するデフォルトケースを想定する。

最新のアクセス・スコアリング：最新のアクセス・スコアリングでは、コンテンツアイテムのリテンションスコアは、当該コンテンツアイテムの最新のアクセス時刻の関数である。リテンションスコアは、単純に、秒単位で現在時刻と最新のアクセス時刻との差分の逆数でありうる：
ＲＳ＝１／（ｔ_C−ｔ_A）
ここで、ＲＳはリテンションスコアであり、ｔ_Cは現在時刻であり、ｔ_Aは最新のアクセス時刻である。

特定の実施形態に対して正規化が必要である場合には、予め定められた期間内の、特定のユーザによる又は特定のクライアントデバイス上のアクセス回数として定義される、ユーザ又はクライアントデバイスのアクセス頻度といった、種々のユーザ属性が使用されうる。代替的には、特定のユーザ又はクライアントデバイスと共有されるコンテンツアイテムの最新のアクセス時刻の平均が使用されうる。

アクセス頻度スコアリング：アクセス頻度スコアリングでは、コンテンツアイテムのリテンションスコアは、予め定められた期間内の、同じコンテンツアイテムへのアクセス回数の増加に従って増加する。アクセス頻度スコアリングを正規化するために、所与のコンテンツアイテムについてのアクセス頻度が、クライアントデバイス上の又はユーザと共有される全コンテンツアイテムについての平均アクセス頻度で、除算又はさもなければスケーリングされうる。

ロケーション関連アクセススコアリング：ロケーション関連アクセス・スコアリングでは、第１のコンテンツアイテムのリテンションスコアは、最新のアクセス時刻、アクセス頻度、又はコンテンツアイテム自体の任意の特徴と、第１のコンテンツアイテムと同じフォルダに格納された更なるコンテンツアイテムの同じ特徴との重み付け合成である。これは、フォルダ内のコンテンツアイテムへのアクセスが、同じフォルダ内の他のコンテンツアイテムへのアクセスを予測することを示唆する。

類似アクセスス・スコアリング：類似アクセス・スコアリングでは、第１のコンテンツアイテムのリテンションスコアは、最新のアクセス時刻、アクセス頻度、又はコンテンツアイテム自体の任意の特徴と、第１のコンテンツアイテムと類似の属性を有する更なるコンテンツアイテムの同じ特徴との重み付け合成である。属性には、コンテンツアイテムのタイプ、サイズ、ロケーション、当該コンテンツアイテムにアクセス可能なユーザ等が含まれうる。これは、類似のコンテンツアイテムへのアクセスが、コンテンツアイテムへの将来のアクセスを予測することを示唆する。

基準ベース・リテンション・スコアリング：基準ベース・リテンション・スコアリングでは、コンテンツアイテムのリテンションスコアは、それ以前に特定された予測基準をコンテンツアイテムが満たした回数に基づく。例えば、２４時間以内の他のユーザによるコンテンツアイテムへのアクセス、先週の５回を上回るアクセス頻度、及び最近３日以内の十分に類似したコンテンツアイテムへのアクセスが、全て、以降の６時間以内のリモートコンテンツアイテムにアクセスする試行を予測するものとして予め定められた基準でありうる。したがって、コンテンツアイテムのリテンションスコアは、当該コンテンツアイテムが満たす基準のそれぞれに対する予め定められた大きさだけ増加しうる。満たされた特定の基準に対する増加の大きさは、特定の基準の予測強度に比例しうる。

図１０は、予測されたコンテンツアイテム重要度を制約付き同期のために用いるコンテンツ管理システムのためのシステム環境を示す。図１０に提示される制約付きコンテンツ管理システム６００のモジュールの大部分は、上述のセクションで言及した部分を除き、図６を参照して説明した機能と同様の又は類似の機能を実行する。したがって、コンテンツ管理システム１０００内の全てのモジュールの機能について、このセクションでは詳細には説明しない。

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

図１１は、制約付き同期の他の実施形態についてのクライアントアプリケーション１１００のソフトウェアアーキテクチャを示す。本実施形態は、クライアントアプリケーションによってクライアントデバイスがアイドルであると判定される間に、リモートコンテンツアイテムのダウンロード、放置コンテンツアイテムの削除、及びシャドウファイルの作成の全てを行う。制約付き同期プロセスのタイミングのこの変更は、実効ストレージ容量の同様の増加を提供しながら、これまでに説明した実施形態に対して機能改善をもたらすことによって、クライアントデバイスを改善する。これらの機能を実効するため、アイドル状態トリガ型の実施形態は、図３に示されるシステムアーキテクチャを変更する。本実施形態では、クライアントアプリケーション１１００は、コンテンツ同期モジュール３１０、リテンション状態モジュール１１１０、ファイルジャーナル３６０、常駐ファイルテーブル３６２、共有データ３６４、リモートファイルテーブル３６６、設定ファイル３６８、及びブロックキャッシュ３７０を含む。コンテンツ同期モジュール３１０は、ハッシュ化モジュール３２０、ダウンロードモジュール３３０、アップロードモジュール３４０、及びストレージ管理モジュール３５０を更に含む。リテンション状態モジュール１１１０は、状態計算モジュール１１２０、状態比較モジュール１１３０、アクションモジュール１１４０、及びシステムステータス・モジュール１１５０を更に含む。特に明記しない限り、これまでに言及した全てのモジュール及びデータテーブルは、新たなモジュールを収容することを当業者が認識するように、これまでに説明したわずかに変更されたものと同じ機能を有する。任意の主な変更について以下で説明する。

システムステータス・モジュール１１５０は、ストレージカーネル拡張３８２を使用して、オペレーティングシステム３８０上のシステムアクティビティを測定する。システムアクティビティは、プロセッサ周波数若しくは（複数のプロセッサコアの調整有り若しくは無しの）他のＣＰＵ利用メトリックの比としての非アイドルプロセッサ周期の数、スレッドの数、又はクライアントデバイス１００のプロセスの数を含む、プロセッサのアクティビティについてのメトリックを使用して測定されうる。ビット毎秒又はパケット毎秒で定義される、特定のポート又はコネクションについての最大速度の比としての、ネットワーク利用を含む、ネットワークアクティビティ・メトリックも使用されうる。更には、利用可能な又は空のランダムアクセスメモリ（ＲＡＭ）の量を含む、メモリ使用メトリックが、システムアクティビティの測定に使用されうる。システムステータス・モジュール１１５０は、全体のシステムアクティビティを測定するために、上述したアクティビティメトリック又は他の任意の適切なアクティビティメトリックを、個別に又は組み合わせて使用しうる。

システムアクティビティの測度が、予め定められたアクティビティ閾値を下回る場合、システムステータス・モジュール１１５０は、リテンションスコア・モジュール１１１０に、クライアントデバイスが現在アイドルであることを報告する。このアクティビティ閾値は、アクティビティメトリックによって定義されるような、クライアントデバイスの総計算リソースの割合として定義されてもよいし、あるいは、アクティビティ閾値は、アクティビティメトリックの特定の値として定義されてもよい。例えば、アクティビティ閾値は、利用可能な処理リソースの２５％未満を使用するクライアントデバイス１００の状態として定義されうる。あるいは、アクティビティ閾値は、クライアントデバイス１００の他のプロセスが、２ＧＢ未満のメモリを全体で使用している状態として、又は、クライアントデバイス上で使用可能な、総メモリのうちの少なくとも４ＧＢが存在する状態として定義されうる。

システムステータス・モジュール１１５０によって、クライアントデバイス１００がアイドル状態と判定された場合、状態計算モジュール１１２０は、共有コンテンツストレージ・ディレクトリ１２０のリテンション状態を判定する。一般に、リテンション状態は、クライアントデバイスに常駐するコンテンツアイテムと、それらのコンテンツアイテムに対応する属性のセットとで構成される。これらの属性は、コンテンツアイテムのサイズ、最新のアクセス時刻、アクセス頻度、ディレクトリのロケーション、又は、クライアントデバイス上のリテンションに対するコンテンツアイテムの重要度を示しうる任意の他の適切な属性を含みうる。更に、リテンション状態は、上記に記載した属性の少なくとも１つを用いて計算された統計値のセットで表現されうる。

比較モジュール１１３０は、状態計算モジュール１１２０からリテンション状態を受信し、共有コンテンツストレージ・ディレクトリ１２０の現在のリテンション状態を、ユーザによって指定されうる、設定ファイル３６８において定義された予め定められた閾値リテンション状態と比較する。閾値リテンション状態は、リテンション状態に含まれるクライアントデバイスの属性又は計算された統計値に関連する基準のセットである。比較モジュール１１３０は、現在のリテンション状態が、閾値リテンション状態の基準を満たすかどうかを判定する。これらの基準に違反する（例えば、満たさない）場合、比較モジュール１１３０は、属性に対応する、又は当該属性に基づく計算された統計値に対応する、閾値リテンション状態基準に違反するコンテンツアイテムを、アクションモジュール１１４０に対して報告する。

アクションモジュール１１４０は、比較モジュール１１３０からの報告を受信する。その後、どのアクションが、リテンション状態を閾値リテンション状態基準内に戻すかを判定する。これらのアクションには、共有コンテンツストレージ・ディレクトリ１２０からコンテンツアイテムを削除すること、コンテンツアイテムをシャドウアイテムに置き換えること、又は、リモートコンテンツアイテムを示すシャドウアイテムを、コンテンツアイテム自体に置き換えることが含まれうる。これらのアクションが判定された時点で、アクションモジュール１１４０は、要求されたアクションをコンテンツ同期モジュール３１０が完了させることを要求する。

あるいは、アイドル状態トリガ型の制約付き同期は、コンテンツ管理システム自体によって実行されもよく、クライアントデバイス上の計算負荷を更に低減し、他の用途へのデバイスの利用可能性を増加させる。図１２は、このタスクを完了させるシステム環境を示す。制約付きコンテンツ管理システム１２００は、メタデータサーバ２１２、ブロックサーバ２１４、通知サーバ２１６、データストア２１８、ペンディングブロック・テーブル２２０、ネームスペース・テーブル２２２、ストレージ管理モジュール３５０、クライアント設定ファイル６１０、同期テーブ６２０、ユーザデータ６３０、リテンション状態テーブル１２１０、リテンション状態モジュール１２２０を含む。特に明記しない限り、これまでに言及した全てのモジュール及びデータテーブルは、新たなモジュールを収容することを当業者が認識するように、これまでに説明したわずかに変更されたものと同じ機能を有する。任意の主な変更について以下で説明する。

実施形態のこのバージョンにおいて、コンテンツ管理システム１２００に接続されたクライアントデバイス上のクライアントアプリケーション２００は、クライアントデバイスのステータスをコンテンツ管理システム１２００へ報告する。クライアントデバイスがアイドルである場合、コンテンツ管理システム１２００は、リテンション状態モジュール１２２０を使用して、アイドル状態のクライアントデバイス上の共有コンテンツストレージ・ディレクトリ１２０のリテンション状態を判定する。リテンション状態モジュールは、更に、コンテンツ管理システム１２００に接続された全クライアントデバイスの現在のリテンション状態を含む、リテンション状態テーブル１２１０を更新する。リテンション状態モジュール１２２０は、更に、図１１の説明に記載したような、潜在的に類似したサブモジュールを使用して、リテンション状態モジュール１１１０と同様のステップを実行する。

共有コンテンツストレージ・ディレクトリのリテンション状態は、種々の方法を使用して判定されうる。一般に、リテンション状態は、基準ベースであり、クライアントデバイスがアイドルであるとクライアントアプリケーションが判定するごとに定期的に保持される。しかし、リテンション状態及び閾値リテンション状態を、各状態が、クライアントデバイスに常駐するコンテンツアイテムの属性を用いて計算された統計値によって表されるように、数値的に実現することも可能である。リテンション状態が基準ベースである場合、閾値リテンション状態は、共有コンテンツストレージ・ディレクトリ内のコンテンツアイテムが満たさなければならない基準のセットである。更に、基準ベースのリテンション状態の場合、ユーザは、リテンション状態基準を選択するオプションを与えられてよく、それにより、クライアントデバイス１００に常駐するコンテンツアイテムのカテゴリーのカスタマイズが可能になる。

各クライアントデバイス１００をチェックするために使用される期間は、コンテンツ管理システムの予め定められた値であってもよいし、ユーザによって設定されてもよいし、特定のクライアントデバイスの使用パターンに基づいて定められてもよい。例えば、ユーザが、平均で２４時間ごとに、クライアントデバイス１００上のコンテンツアイテムにアクセスする場合、当該期間は、２４時間が経過する前に共有コンテンツストレージ・ディレクトリが保持されるように設定されうる。

共有コンテンツディレクトリを定期的にチェックする代わりに、他の実施形態は、共有コンテンツディレクトリが、例えば、ハードウェアストレージ上限に近づいているといった緊急性を示す基準の第２のセットを満たした場合にのみ、共有コンテンツディレクトリを保持しうる。

ストレージ空間基準：可能性のある、基準の１つのセットは、ストレージ割り当て基準を有することである。例えば、ストレージ割り当ては２０ＧＢに設定されうるが、これまでの実施形態にように振る舞うのに代えて、コンテンツ管理システムは、デバイスがアイドルになるまで、共有コンテンツストレージ・ディレクトリに格納されたコンテンツアイテムが基準値（本例では２０ＧＢ）を超えることを可能にする。その後、放置コンテンツアイテムを判定する同様のプロセスが、適切なコンテンツアイテムを削除して、共有コンテンツストレージ・ディレクトリに対するストレージ空間基準を満たすために使用されうる。

アクセス時刻基準：第２の基準は、アクセス時刻基準でありうる。例えば、当該基準は、過去の予め定められた時間間隔より以前の最新のアクセス時刻を有するコンテンツアイテムが、共有コンテンツストレージ・ディレクトリ内に常駐できないことを記述しうる。これらのコンテンツアイテムは、クライアントデバイス１００がアイドルになるまで、共有コンテンツストレージ・ディレクトリ内に常駐し続けることが許されうる。その時点で、リテンション状態モジュールは、単純に、予め定められた時間間隔より以前の最新のアクセス時刻を有する全てのコンテンツアイテムの削除を要求しうる。

コンテンツアイテムサイズ基準：基準の他のセットは、コンテンツアイテムサイズ基準である。この方法では、個別のコンテンツアイテムのサイズに対する閾値が設定される。このため、クライアントデバイス１００がアイドルになるたびに、閾値を上回る又は下回るいずれかのコンテンツアイテムが、クライアントデバイス１００上の常駐から削除される。

アクセス頻度基準：最後に、アクセス頻度基準が、クライアントデバイス１００に常駐し続けるために必要となる予め定められた時間間隔内のアクセスの最小回数を設定するために使用される。特定のコンテンツアイテムがあまり頻繁にアクセスされていない場合、当該コンテンツアイテムは、クライアントデバイスがアイドルになるたびに当該クライアントデバイスから削除される。

なお、リテンション基準のこのリストは包括的ではない。更に、これらの基準は、互いに併用されもよく、その結果、より複雑な規則が得られる。

図１３は、アイドル状態トリガ型の制約付きコンテンツ管理の機能を示すフロー図である。まず、システムは、特定のクライアントデバイス１００がアイドルであるかどうかを判定することをチェックする（１３００）。このステップは、定期的に完了するか、又は、コンテンツストレージ・ディレクトリが予め定められた閾値に達したことに応じて完了する。デバイスがアイドルである場合、システムは、クライアントデバイスのリテンション状態を判定する（１３１０）。その後、システムは、共有コンテンツストレージ・ディレクトリの現在のリテンション状態を、共有コンテンツストレージ・ディレクトリに対するリテンション状態基準と比較する。共有コンテンツストレージ・ディレクトリの現在のリテンション状態が当該基準を満たす場合、システムは、クライアントデバイス１００がアイドルであるかどうかを判定することのチェックを再び行う（１３００）。リテンション状態基準に違反する場合、システムは、共有コンテンツストレージ・ディレクトリ１２０がリテンション状態基準を満たすために必要となる、共有コンテンツストレージ・ディレクトリ１２０に実行するためのアクションを識別する（１３３０）。その後、システムは、予め定められたリテンション状態基準に適合するために、それらのアクションを共有コンテンツストレージ・ディレクトリ１２０に実行する（１３４０）。

図１４は、クライアントデバイス１００上のシャドウアイテムに対応するコンテンツアイテムを選択的にダウンロードするように構成されたクライアントアプリケーション１４００のソフトウェアアーキテクチャを示す。この実施形態では、クライアントデバイス上のアプリケーションが、共有コンテンツストレージ・ディレクトリ１２０内のシャドウアイテムへのアクセスを要求すると、クライアントアプリケーション１４００は、シャドウアイテムに関連付けられたコンテンツアイテムをクライアントデバイスへダウンロードするかストリーミングするかを、複数の条件に基づいて判定する。これらの条件には、要求アプリケーションが、承認済みアプリケーションのリストにあるかどうか、ディレクトリ要求とコンテンツアイテム要求との間の時間が、人間の反応時間を近似する時間間隔内であるかどうか、アプリケーションの要求が、クライアントデバイス上のユーザインタフェースに関連付けられているかどうか、又は、ユーザが（クライアントアプリケーション１４００によって提示されるポップアップメニューを用いて）コンテンツアイテムをダウンロードするための明示的な許可を与えたかどうか、が含まれうる。コンテンツアイテムのダウンロードは、条件を満たさない場合、又は代替的には、アクセスを提供するクライアントデバイスに対してコンテンツアイテムがストリーミングされうる場合、拒否されうる。コンテンツアイテムがクライアントデバイスへダウンロードされるケースを限定することによって、クライアントアプリケーション１４００は、不要なダウンロードアクティビティをアプリケーションが生じさせることを防止し、それにより、プロセッサアクティビティ、ネットワークアクティビティ及び消費電力の削減に改善をもたらす。プロセッサアクティビティの削減は、より重要な他のタスクにプロセッサを利用できるようになり、消費電力を削減できるため有益であり、ネットワークアクティビティの削減は、帯域幅及びデータ消費の削減のために有益であり、これは、特に、過剰なデータ消費がネットワーク性能の低下とコスト及び料金の増加との両方につながるモバイルデバイスに対して有益であり、消費電力の低減は、バッテリー寿命を伸ばすため特にモバイルデバイスに対して有益である。例えば、写真ギャラリー・アプリケーションは、短期間に多数の写真ファイルを開くことを要求しうる。これらの写真の多くは、共有コンテンツストレージ・ディレクトリ上でシャドウアイテムとして示されることがあり、選択的なダウンロードなしで、クライアントアプリケーションが大量のデータのダウンロードを生じさせうる。これは、クライアントデバイスのネットワーク帯域幅及び／又は処理電力の大部分を必要とし、基準以下のユーザエクスペリエンスをもたらしうる。上記の状況で選択的ダウンロードが使用される場合、ユーザは、例えば、クライアントアプリケーション１４００が、写真ギャラリー・アプリケーションによって要求された全ての写真をダウンロードすべきかどうかを尋ねるメッセージで促される。その後、ユーザは、不要な場合にダウンロードアクティビティを防ぐ機会を得られうる。代替の例において、クライアントアプリケーション２００は、写真ギャラリー内の写真のプレビューを、それらのそれぞれをコンテンツ管理システム１１０からダウンロードする代わりにストリーミングでき、特定の写真の高解像度バージョンの閲覧を求める要求の受信に応じてだけフルダウンロードを実行しうる。これらは、以下で説明されるような選択的ダウンロードを用いて何が実現されうるのかの少数の例にすぎない。

選択的ダウンロードの実施形態は、図３に示されるシステムアーキテクチャへの追加である。本実施形態では、クライアントアプリケーション１４００は、コンテンツ同期モジュール３１０、選択的ダウンロードモジュール１４５０、ファイルジャーナル３６０、常駐ファイルテーブル３６２、共有データ３６４、リモートファイルテーブル３６６、設定ファイル３６８、及びブロックキャッシュ３７０を含む。コンテンツ同期モジュール３１０は、ハッシュ化モジュール３２０、ダウンロードモジュール３３０、アップロードモジュール３４０、及びストレージ管理モジュール３５０を更に含む。選択的ダウンロードモジュール１４５０は、アプリケーション特権モジュール１４１０、ユーザ意図モジュール１４２０、コンテンツアイテムアクセスモジュール１４３０、及びストリーミングモジュール１４４０を更に含む。特に明記しない限り、これまでに言及した全てのモジュール及びデータテーブルは、新たなモジュールを収容することを当業者が認識するように、これまでに説明したわずかに変更されたものと同じ機能を有する。任意の主な変更について以下で説明する。

選択的ダウンロードモジュール１４５０は、不要なダウンロードを防ぐためにストレージ管理モジュール３５０と協調して動作する。ストレージ管理モジュール３５０が、共有コンテンツストレージ・ディレクトリ１２０内のアイテムにアクセスするアプリケーションからの要求の受信に応じて、ストレージ管理モジュール３５０は、要求されたアイテムがシャドウアイテムであるかコンテンツアイテムであるかを判定する。要求されたアイテムがシャドウアイテムであるとの判定に応じて、ストレージ管理モジュール３５０は、コンテンツアイテムがコンテンツ管理システム１１０からダウンロードされうるかどうかを選択的ダウンロードモジュール１４５０が判定できるように、アプリケーションパス及びシャドウアイテムパスを、選択的ダウンロードモジュール１４５０に提供する。

アプリケーション特権モジュール１４１０は、識別されたアプリケーションが、承認済みアプリケーションであり、かつ、この機能を実行する一手段であるかどうかを判定するために、受け取ったアプリケーションパスを、クライアントデバイスに対する承認済みアプリケーションのリストと照合する。承認済みアプリケーションのリストは、クライアントデバイスのローカルメモリ内又はコンテンツ管理システム１１０内に格納されうるとともに、分類されていないアプリケーションからの要求の受信に応じて生成されたユーザインタフェース・プロンプトを通じて、又はユーザ設定を通じて、ユーザが変更可能でありうる。いくつかの実施形態において、アプリケーションモジュール特権モジュール１４１０によって保持されるリストは、コンテンツ管理システム１１０の管理者によって前もって選択されうるとともに、ユーザによって更に変更可能でありうる。承認済みアプリケーションのリストに加えて、アプリケーションモジュール特権モジュール１４１０は、制約付きアプリケーション（即ち、コンテンツアイテムのダウンロードをトリガすることが許可されていないアプリケーション）のリスト、ストリーミングアプリケーション（即ち、要求されたアイテムがコンテンツ管理システム１１０からストリーミングされうるアプリケーション）のリスト、又は、部分アクセスアプリケーション（即ち、コンテンツアイテムの一部がダウンロードされうるアプリケーション）のリストを保持しうる。アプリケーションモジュール特権モジュール１４１０は、任意の数の上述のリスト又はリモートコンテンツアイテムへの異なるレベルのアクセスを有する追加のリストを有しうる。上述のリストのそれぞれは、設定ファイル３６８又は他の適切なロケーションに格納されうる。

アプリケーションモジュール特権アプリケーション１４１０は、以下のように、リストのそれぞれに対してアプリケーションモジュールパスをテストするアルゴリズムのためのプログラムロジックを含む。アプリケーション特権モジュール１４１０が受信したアプリケーションパスが、承認済みアプリケーションのリスト内のアプリケーションと一致した場合、アプリケーション特権リスト１４１０は、ストレージ管理モジュール３５０に、要求されたコンテンツアイテムがコンテンツ管理システム１１０からダウンロードされうることを通知する。受信したアプリケーションパスが、制約付きアプリケーションのリスト内のアプリケーションと一致した場合、ダウンロードが拒否されて、クライアントアプリケーション１４００は、ポップアップメッセージ又は他の任意の適切な通知によって拒否をユーザに通知しうる。受信したアプリケーションパスが、ストリーミングアプリケーションのリスト内のアプリケーションと一致した場合、アプリケーションモジュール特権モジュール１４１０は、ストリーミングストリーミングモジュール１４４０に、コンテンツ管理システム１１０とのストリーミングの開始を通知しうる。いくつかの実施形態において、ストリーミングモジュール１４４０への通知前に、アプリケーションモジュール特権モジュールは、最初に、コンテンツアイテムがクライアントデバイスへストリーミングされるべきかダウンロードされるべきかを判定するコンテンツアイテムアクセスモジュール１４３０に通知を行いうる。

受信したアプリケーションパスが、部分アプリケーションのリスト内のアプリケーションと一致した場合、アプリケーションモジュール特権モジュール１４１０は、コンテンツ管理モジュール３５０に、要求されたコンテンツアイテムの部分ダウンロードの実行を許可しうる。部分ダウンロードの場合、ストレージ管理モジュール３５０は、コンテンツアイテムの要求された部分を含むブロックをダウンロード、又はブロックサイズより小さい部分をダウンロードしうる。ブロックキャッシュ３７０は、混合バージョンを有する複合アイテムの作成を防ぐために、部分ブロック又は単一ブロックを常駐ブロックリスト内にブロックとして含ませない場合がある。

いくつかの実施形態において、アプリケーションモジュール特権モジュール１４１０は、ダウンロード特権を有するアプリケーションについての個別のリストと、ストリーミング特権を有するアプリケーションについてのリストとを有していない。その代わりに、承認済みアプリケーションについての単一のリストが存在し、コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムをダウンロードするのが好ましいかコンテンツアイテムをストリーミングするのが好ましいかを判定する。

要求アプリケーションが、アプリケーションモジュール特権モジュール１４１０によって保持されているリストのうちの１つに含まれていない場合、選択的ダウンロードモジュール１４５０は、ユーザ意図モジュール１４２０を利用することによってユーザの意図（即ち、ユーザがアプリケーションにアクセスしようとしているかどうか、又は、自動化された若しくは予備の機能の一部としてアプリケーションが要求を実行中であるかどうか）を判定することを試みうる。

他の実施形態では、要求アプリケーションが、上述のリストのうちの１つにおいて分類されていない又は見つからなければ、アプリケーション特権モジュール１４１０は、分類オプションを有するユーザインタフェース・ウィンドウを表示することによって、当該アプリケーションを分類する機会をユーザに提供しうる。

ユーザ意図モジュール１４２０は、シャドウアイテムを要求することをユーザが要求アプリケーションに対して意図していたかどうかを判定するテストを行い、この機能を実行する一手段である。ユーザの意図についての最終的な判定は、ユーザ意図モジュール１４２０によって使用されたテストの全てについての肯定的な結果に基づいてもよいし、テストの結果に基づく重み付け平均若しくは他の計算値に基づいてもよい。一実施形態において、ユーザ意図モジュール１４２０は、ユーザの意図を判定するために個別に又はまとめて使用されうる複数のテストを含むアルゴリズムのためのプログラムロジックを含む。

反応時間：ユーザ意図モジュール１４２０は、要求アプリケーションからのディレクトリオープン要求とファイルオープン要求との時間差を測定することによって、ユーザの意図を判定しうる。この時間は、ストレージカーネル拡張３８４がファイルシステム３８２をモニタリングすることで測定されて、ユーザ意図モジュール１４２０へ伝えられうる。ディレクトリオープン要求とファイルオープン要求との間の測定された時間差の受信に応じて、ユーザ意図モジュール１４２０は、測定された当該時間差を、人間の平均反応時間を近似する時間間隔（例えば、２５０ミリ秒から１秒）と比較しうる。当該時間差が人間の平均反応時間より少なければ、ユーザは、要求を行うことを意図していない可能性があり、その場合、シャドウアイテムをダウンロードしないのが適切である。

関連ＵＩウィンドウ：ユーザ意図モジュール１４２０は、アプリケーションの現在のプロセスを、クライアントデバイス１００上で開かれている現在のウィンドウを有するかどうかを判定するために調べうる。現在のウィンドウが存在する場合、それは、コンテンツアイテムにアクセスしようとするアプリケーションの試みをユーザが認識している可能性があることを示唆する。アプリケーションの現在のプロセスに関連するウィンドウが存在しない場合には、アプリケーションの要求をユーザが認識している可能性は低い。ストレージカーネル拡張３８４は、アプリケーションのプロセスをモニタリングして、関連するウィンドウを判定しうる。

アプリケーションパス：ユーザ意図モジュール１４２０は、クライアントデバイスのファイルシステム３８２におけるアプリケーションのロケーションを判定することで、当該アプリケーションがユーザに面するアプリケーションである可能性を推定しうる。例えば、アプリケーションが、隠しフォルダ又はディレクトリとは対照的に「アプリケーション」フォルダ内に位置している場合、当該アプリケーションがユーザに面しており、かつ、それ故に、ユーザの指示の下で動作している可能性が高い。

ユーザアクティビティ：ユーザ意図モジュール１４２０は、マウスの移動量、ユーザの１分当たりのアクション（キーストローク、タッチスクリーンへのタッチ等）、又は、クライアントデバイス上でユーザがアクティブであるとの他の任意のインジケータといった、ユーザアクティビティをモニタリングしうる。アプリケーションの要求が生じた際にユーザがアクティブである場合、ユーザが、当該アプリケーションの要求を知っている可能性が高い。ユーザアクティビティは、アクティビティ状態を取得するためにオペレーティングシステム・プログラミングインタフェースを呼び出すことによってモニタリングされうる。

ユーザ意図の明示的インジケーション：ユーザ意図モジュール１４２０は、アプリケーション又はプロセスからの要求の受信に応じて、ダウンロードを承認するかどうかをユーザが指示することを可能にするための、ユーザへのメッセージを表示しうる。ユーザがｙｅｓ若しくはｎｏの質問で問い合わせられうるか、又は、ユーザが要求アプリケーションを、アプリケーション特権モジュール１４１０によって保持されるリストの１つに分類するためのオプションを、ユーザ意図モジュール１４２０が提示しうる。

ユーザの意図を判定する上述の方法の一部又は全てを用いることで、ユーザ意図モジュール１４２０は、ストレージ管理モジュール３５０に、要求アプリケーションの要求に対して許可するかどうかを通知する。代替的には、ユーザ意図モジュールは、コンテンツアイテムアクセスモジュール１４３０に、コンテンツアイテムの要求が許可されるべきであることを通知してもよい。

いくつかの実施形態において、コンテンツアイテムアクセスモジュール１４３０は、要求されたコンテンツアイテムが、アプリケーション特権モジュール１４１０又はユーザ意図モジュール１４２０によって許可されている、コンテンツアイテムへのアクセスを与えられたクライアントデバイス１００へダウンロードされるのが適切かストリーミングされるのが適切かを判定する。コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテム及び要求アプリケーションの属性と現在のネットワークメトリックとを、クライアントデバイスに対してコンテンツアイテムをストリーミングするのが最適であるかダウンロードするのが最適であるかを判定するために使用する。いくつかの実施形態において、コンテンツアイテムアクセスモジュール１４３０は、標準的なユーザエクスペリエンスに対して目立った妨げが最も少なくて済むオプションを選択するように構成される。例えば、合理的な時間内にダウンロードするにはファイルが大きすぎる場合、コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムのストリーミングを行うのが有効であると判定しうる。コンテンツアイテムアクセスモジュール１４３０は、基準のセットを使用して、ダウンロードのオプションとストリーミングのオプションとのいずれかの適合性を判定することによって、これを実現する。いくつかの実施形態において、コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムのダウンロードに要する時間を計算し、それを、ストリーミングセッションを開始する時間と比較してもよい。コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムの最大ダウンロードサイズ、コンテンツアイテムの最小ストリーミングサイズ、ストリーミングの最小ネットワーク帯域幅、ストリーミングの最大ネットワーク待ち時間、又は他の任意の適切な基準についての基準を有してもよい。

いくつかの実施形態において、コンテンツアイテムアクセスモジュール１４３０は、要求を行ったアプリケーションのタイプに基づいて、ダウンロードのオプションを使用するかストリーミングのオプションを使用するかを判定しうる。例えば、ワードプロセッシング・アプリケーションは、ストリーミングするには非効率でありうるので、そのタイプのアプリケーションに対してはダウンロードが有利でありうる。他の例として、ビデオアプリケーションは、より大きなファイルを要求する傾向がありうるので、ストリーミングが有利でありうる。同様に、コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムのタイプを、決定における追加の要因として使用しうる。例えば、特定のファイル拡張子を有するコンテンツアイテムは、ストリーミングがより有利であるか、又はダウンロードがより有利でありうる。

コンテンツアイテムアクセスモジュール１４３０が、要求されたコンテンツアイテムがクライアントデバイスへストリーミングされるべきであると判定した場合、コンテンツアイテムアクセスモジュール１４３０は、ストリーミングモジュール１４４０に、当該コンテンツアイテムが格納されたコンテンツ管理システム１１０とクライアントデバイスとの間でのストリーミングを開始するよう通知する。コンテンツアイテムアクセスモジュール１４３０が、コンテンツアイテムがダウンロードされるべきであると判定した場合、コンテンツアイテムアクセスモジュール１４３０は、ストレージ管理モジュール３５０に、コンテンツ管理システム１１０とのダウンロードをセットアップするよう通知する。

ストリーミングモジュール１４４０は、コンテンツ管理システム１１０とクライアントデバイス１００との間でストリームを始める役割を有する。コンテンツアイテムのストリーミングのためにメモリマッピングが使用されうる。メモリマッピングが使用された場合、コンテンツアイテムは、仮想メモリに直接ダウンロードされうる。仮想メモリにおけるコンテンツアイテムの受信に応じて、ストリーミングモジュール１４４０は、仮想メモリに一時的に格納されたコンテンツアイテムのコピーを、コンテンツ管理システム１１０と定期的に同期させうる。

図１５は、いくつかの実施形態に係る、対応するシャドウアイテムが要求された場合にダウンロードのためにコンテンツアイテムを承認するためのアルゴリズムの例を示すフロー図である。上述のモジュールが、図１５に示される機能と異なる機能を実行するために使用されうることを当業者は理解しよう。

アプリケーションからのシャドウアイテム１５００を開くことを求める要求の受信に応じて（１５００）、アプリケーション特権モジュール１４１０は、要求アプリケーションが、保持されているアプリケーションのリストのうちの１つにおいて分類されているかどうかを判定する。要求アプリケーションが、承認済みアプリケーションのリストにある場合、コンテンツアイテムは、コンテンツ管理システム１１０からダウンロードされる（１５０６）。要求アプリケーションが、ストリーミングアプリケーションのリストにある場合、コンテンツアイテムは、クライアントデバイス１００へストリーミングされる（１５０８）。アプリケーションが、制約付きアプリケーションのリストに含まれる場合、コンテンツアイテムを開くことを求める要求は拒否される（１５０４）。

要求アプリケーションが分類されていない場合、アプリケーション特権モジュールは、ユーザ意図モジュール１４２０に通知する。ユーザ意図モジュール１４２０は、上述のように、コンテンツアイテムを要求することをユーザが意図していたかどうかを確認するために種々のテストを使用する（１５１０）。ユーザ意図モジュール１４２０が、コンテンツアイテムを要求することをユーザが意図していなかったと判定した場合、当該要求は拒否される（１５０４）。ユーザ意図モジュール１４２０が、コンテンツアイテムを要求することをユーザが意図していた場合、ユーザ意図モジュールは、コンテンツアイテムアクセスモジュール１４３０に通知する。

コンテンツアイテムアクセスモジュール１４３０は、コンテンツアイテムの属性、アプリケーション、及び現在のネットワークメトリックに基づいて、コンテンツアイテムがダウンロードされるべきかストリーミングされるべきかを判定する（１５１２）。コンテンツアイテムアクセスモジュール１４３０が、要求されたコンテンツアイテムがダウンロードされるべきであると判定した場合、当該コンテンツアイテムがダウンロードされる（１５０６）。コンテンツアイテムアクセスモジュールが、当該コンテンツアイテムがストリーミングされるべきであると判定した場合、当該コンテンツアイテムがクライアントデバイスへストリーミングされる（１５０６）。

本発明の実施形態についての上述の説明は、例示を目的として提示されており、網羅的であること又は開示した形態そのもの本発明を限定することは意図されていない。関連技術の技術者は、上記の開示を踏まえて多くの変更及び変形が可能であることを理解できる。

明細書で使用された用語は、可読性及び教授を目的として主に選択されており、発明の主題を描写又は制限するためには選択されていない場合がある。したがって、本発明の範囲は、この詳細な説明によってではなく出願に基づいて当該出願に出てくるいずれかの請求項によって限定されることが意図されている。このため、本発明の実施形態の開示は、以下の請求項に記述された発明の範囲についての限定ではなく例示を目的としている。

Claims (20)

1. コンピュータで実施される方法であって、前記方法は、
   クライアントデバイスのメモリに、クライアントデバイス上の複数の承認済みアプリケーションのリストを保持することと、
   前記クライアントデバイスのファイルシステムが、コンテンツアイテムの要求を、前記クライアントデバイス上でローカルで実行されるアプリケーションから受信することと、ここで、当該要求されたコンテンツアイテムは、共有ローカルコンテンツディレクトリに格納されており、
   前記クライアントデバイスが、前記要求されたコンテンツアイテムがシャドウアイテムであることを、当該シャドウアイテムの属性を用いて判定することと、ここで、前記シャドウアイテムは、前記クライアントデバイスに対してリモートの、別個のホストデバイスに格納されたコンテンツアイテムを示し、前記シャドウアイテムは、前記コンテンツアイテムのコンテンツデータを含まずに、前記コンテンツアイテムのメタデータを含み、
   前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムを要求する要求アプリケーションが、承認済みアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
   前記要求アプリケーションが前記リストに含まれているとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムを、前記共有ローカルコンテンツディレクトリ内の前記シャドウアイテムに対応するコンテンツアイテムに置き換えることと、
   前記要求アプリケーションが承認済みアプリケーションの前記リストに含まれていないとの判定に応じて、
   前記要求アプリケーションからの前記要求が、前記クライアントデバイスのユーザによって始められたかどうかを判定することと、
   前記要求が前記クライアントデバイスの前記ユーザによって始められたとの判定に応じて、前記シャドウアイテムを、前記共有ローカルコンテンツディレクトリ内の前記シャドウアイテムに対応する前記コンテンツアイテムに置き換えることと、を含む方法。
2. 請求項１に記載の方法であって、更に、
   前記クライアントデバイス上の複数の制約付きアプリケーションのリストを保持することと、
   前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、制約付きアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
   前記シャドウアイテムが制約付きアプリケーションの前記リストに含まれているとの判定に応じて、前記シャドウアイテムに対応する前記コンテンツアイテムへのアクセスを拒否することと、を含む方法。
3. 請求項１に記載の方法であって、更に、
   前記クライアントデバイス上のシャドウアイテムの前記メタデータにアクセスすることを承認された複数のアプリケーションのリストを保持することと、
   前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、前記クライアントデバイス上のシャドウアイテムの前記メタデータにアクセスすることを承認されたアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
   前記要求アプリケーションに、前記シャドウアイテムへのアクセスを提供することと、を含む方法。
4. 請求項１に記載の方法であって、更に、
   前記クライアントデバイス上のコンテンツアイテムのストリーミングが承認された複数のアプリケーションのリストを保持することと、
   前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、コンテンツアイテムのストリーミングが承認されたアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
   前記要求アプリケーションが前記クライアントデバイス上のコンテンツアイテムのストリーミングを承認されたアプリケーションの前記リストに含まれているとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムに関連付けられた前記コンテンツアイテムの前記クライアントデバイスへのストリーミングを、前記要求アプリケーションによる使用のために行うことによって、前記クライアントデバイスとコンテンツ管理システムとの間でストリーミングセッションを開始することと、を含む方法。
5. 請求項４に記載の方法であって、ストリーミングセッションを開始することは、前記クライアントデバイス上のメモリマッピングを用いて、前記シャドウアイテムに対応する前記コンテンツアイテムに要求プロセスがアクセスすることを可能にすることを更に含む、方法。
6. 請求項４に記載の方法であって、ストリーミングセッションを開始することは、前記要求アプリケーションに対してアクセスを許可することを前記クライアントデバイスの前記ユーザが意図していないとのインジケーションの受信に応じて、前記ストリーミングセッションを終了することを更に含む、方法。
7. 請求項４に記載の方法であって、ストリーミングセッションを開始することは、前記シャドウアイテムに対応する前記コンテンツアイテムの属性に基づいて、前記ストリーミングを開始することを更に含む、方法。
8. 請求項４に記載の方法であって、前記クライアントデバイスと前記コンテンツ管理システムとの間でストリーミングセッションを開始することは、更に、
   前記クライアントデバイスと前記コンテンツ管理システムとの間のコネクションの帯域幅を判定することと、
   前記帯域幅が閾値帯域幅より小さいことに応じて、前記シャドウアイテムに対応する前記コンテンツアイテムへのストリーミングアクセスを拒否することと、を含む方法。
9. 請求項１に記載の方法であって、更に、
   前記要求アプリケーションが承認済みアプリケーションの前記リストに含まれていないとの判定に応じて、
   前記クライアントデバイスが、前記シャドウアイテムに関連付けられた前記コンテンツアイテムの前記クライアントデバイスへのストリーミングを、前記要求アプリケーションによる使用のために行うことによって、前記クライアントデバイスとコンテンツ管理システムとの間でストリーミングセッションを開始すること、を含む方法。
10. 請求項１に記載の方法であって、前記要求が前記クライアントデバイスの前記ユーザによって意図されたと判定することは、更に、
    前記クライアントデバイスが、前記シャドウアイテムへのアクセスを許可するためのユーザインタフェースを、前記ユーザに対して表示することと、
    前記シャドウアイテムへのアクセスを許可する、前記ユーザからのインタラクションの受け付けに応じて、前記シャドウアイテムに対応する前記コンテンツアイテムをダウンロードすることと、を含む方法。
11. 請求項１に記載の方法であって、前記要求が前記クライアントデバイスの前記ユーザによって意図されたと判定することは、更に、
    前記シャドウアイテムのディレクトリをオープンすることを求める要求と、前記シャドウアイテムにアクセスすることを求める前記要求との間の時間差を計算することと、
    前記計算された時間差が閾値反応時間に満たないかどうかを判定することと、
    前記判定に基づいて、前記シャドウアイテムに対応する前記コンテンツアイテムへのアクセスを拒否することと、を含む方法。
12. 請求項１に記載の方法であって、前記要求が前記クライアントデバイスの前記ユーザによって意図されたと判定することは、更に、
    前記要求アプリケーションが、前記クライアントデバイス上のユーザインタフェースウィンドウに関連付けられているかどうかを判定することと、
    前記要求アプリケーションが前記クライアントデバイス上の前記ユーザインタフェースウィンドウに関連付けられているとの判定に応じて、前記シャドウアイテムに対応する前記コンテンツアイテムをダウンロードすることと、を含む方法。
13. 請求項１に記載の方法であって、更に、
    シャドウアイテムに対応するコンテンツアイテムの一部にアクセスすることを求める要求を、前記クライアントデバイス上のアプリケーションから受信することと、
    前記要求アプリケーションが、承認済みアプリケーションの前記リストに含まれるとの判定に応じて、前記シャドウアイテムに対応する前記コンテンツアイテムの、前記要求された一部をダウンロードすることと、を含む方法。
14. 非一時的なコンピュータ読み取り可能媒体に格納されたコンピュータプログラムであって、１つ以上のプロセッサに、
    クライアントデバイスのメモリに、クライアントデバイス上の複数の承認済みアプリケーションのリストを保持することと、
    前記クライアントデバイスのファイルシステムが、コンテンツアイテムの要求を、前記クライアントデバイス上でローカルで実行されるアプリケーションから受信することと、ここで、当該要求されたコンテンツアイテムは、共有ローカルコンテンツディレクトリに格納されており、
    前記クライアントデバイスが、前記要求されたコンテンツアイテムがシャドウアイテムであることを、当該シャドウアイテムの属性を用いて判定することと、ここで、前記シャドウアイテムは、前記クライアントデバイスに対してリモートの、別個のホストデバイスに格納されたコンテンツアイテムを示し、前記シャドウアイテムは、前記コンテンツアイテムのコンテンツデータを含まずに、前記コンテンツアイテムのメタデータを含み、
    前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムを要求する要求アプリケーションが、承認済みアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
    前記要求アプリケーションが前記リストに含まれているとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムを、前記共有ローカルコンテンツディレクトリ内の前記シャドウアイテムに対応するコンテンツアイテムに置き換えることと、
    前記要求アプリケーションが承認済みアプリケーションの前記リストに含まれていないとの判定に応じて、
    前記要求アプリケーションからの前記要求が、前記クライアントデバイスのユーザによって始められたかどうかを判定することと、
    前記要求が前記クライアントデバイスの前記ユーザによって始められたとの判定に応じて、前記シャドウアイテムを、前記共有ローカルコンテンツディレクトリ内の前記シャドウアイテムに対応する前記コンテンツアイテムに置き換えることと、を実行させるよう構成された命令を含む、コンピュータプログラム。
15. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記クライアントデバイス上の複数の制約付きアプリケーションのリストを保持することと、
    前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、制約付きアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
    前記シャドウアイテムが制約付きアプリケーションの前記リストに含まれているとの判定に応じて、前記シャドウアイテムに対応する前記コンテンツアイテムへのアクセスを拒否することと、を実行させるよう構成された命令を更に含む、コンピュータプログラム。
16. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記クライアントデバイス上のシャドウアイテムの前記メタデータにアクセスすることを承認された複数のアプリケーションのリストを保持することと、
    前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、前記クライアントデバイス上のシャドウアイテムの前記メタデータにアクセスすることを承認されたアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
    前記要求アプリケーションに、前記シャドウアイテムへのアクセスを提供することと、を実行させるよう構成された命令を更に含む、コンピュータプログラム。
17. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記クライアントデバイス上のコンテンツアイテムのストリーミングが承認された複数のアプリケーションのリストを保持することと、
    前記要求されたコンテンツアイテムがシャドウアイテムであるとの判定に応じて、前記シャドウアイテムを要求する前記要求アプリケーションが、コンテンツアイテムのストリーミングが承認されたアプリケーションの前記保持されたリストに含まれているかどうかを判定することと、
    前記要求アプリケーションが前記クライアントデバイス上のコンテンツアイテムのストリーミングを承認されたアプリケーションの前記リストに含まれているとの判定に応じて、前記クライアントデバイスが、前記シャドウアイテムに関連付けられた前記コンテンツアイテムの前記クライアントデバイスへのストリーミングを、前記要求アプリケーションによる使用のために行うことによって、前記クライアントデバイスとコンテンツ管理システムとの間でストリーミングセッションを開始することと、を実行させるよう構成された命令を更に含む、コンピュータプログラム。
18. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記要求アプリケーションが承認済みアプリケーションの前記リストに含まれていないとの判定に応じて、
    前記クライアントデバイスが、前記シャドウアイテムに関連付けられた前記コンテンツアイテムの前記クライアントデバイスへのストリーミングを、前記要求アプリケーションによる使用のために行うことによって、前記クライアントデバイスとコンテンツ管理システムとの間でストリーミングセッションを開始すること、を実行させるよう構成された命令を更に含む、コンピュータプログラム。
19. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記クライアントデバイスが、前記シャドウアイテムへのアクセスを許可するためのユーザインタフェースを、前記ユーザに対して表示することと、
    前記シャドウアイテムへのアクセスを許可する、前記ユーザからのインタラクションの受け付けに応じて、前記シャドウアイテムに対応する前記コンテンツアイテムをダウンロードすることと、を実行させるよう構成された命令を更に含む、コンピュータプログラム。
20. 請求項１４に記載のコンピュータプログラムであって、１つ以上のプロセッサに、
    前記シャドウアイテムのディレクトリをオープンすることを求める要求と、前記シャドウアイテムにアクセスすることを求める前記要求との間の時間差を計算することと、
    前記計算された時間差が閾値反応時間に満たないかどうかを判定することと、
    前記判定に基づいて、前記シャドウアイテムに対応する前記コンテンツアイテムへのアクセスを拒否することと、を実行させるよう構成された命令を更に含む、コンピュータプログラム。

Images