図面 (/)

技術 ストレージ制約付きの同期エンジン

出願人 ドロップボックス,インコーポレイテッド
発明者 ゴールドベルグ,アイザックニュウハウス,ベンジャミン
出願日 2017年4月22日 (2年10ヶ月経過) 出願番号 2018-545642
公開日 2019年6月6日 (9ヶ月経過) 公開番号 2019-515365
状態 不明
技術分野
  • -
主要キーワード 作業用コンピュータ 保存基準 重み付けスコア 通常用途 同期バー ローカル属性 ファイルアイテム 所定時間期間
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年6月6日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

コンテンツ管理システムは、ネットワークによって接続されるクライアントコンピューティングシステムに渡ってコンテンツアイテムを同期する。クライアントデバイス上の共有コンテンツアイテムストレージ割り当てが、コンテンツアイテムを追加若しくはコンテンツアイテムを拡大するような編集を行う要求によって超えてしまう場合、クライアントアプリケーション又はコンテンツ管理システムのホストは、クライアントデバイス上の常駐から削除する一方で、コンテンツ管理システム上ではリモートに維持するコンテンツアイテムを選択する。選択されたコンテンツアイテムを削除すると、クライアントアプリケーションは、当該コンテンツアイテムを表すもののコンテンツアイテムのメタデータを含むのみのシャドウアイテムを作成する。これは、全ての同期される共有コンテンツアイテムへのユーザアクセスを維持しながら、十分なスペース創出する。ファイルジャーナルエントリは、格納アイテムがコンテンツアイテム又はシャドウアイテムかどうかを追跡しアンリするために使用されてもよい。

概要

背景

[0003]コンテンツ管理システムは、ユーザがあるクライアントから他のクライアントへコンテンツアイテム共有することを可能にする。当該クライアントは、記憶及び他のクライアントとの同期のために、コンテンツアイテムをコンテンツ管理システムに提供するコンピューティングデバイスである。他のクライアントは、他のユーザによって操作されてもよく、同一のユーザによって登録又は管理されるデバイスであってもよい。ユーザは、いずれのコンテンツアイテムが、又は、コンテンツアイテムを含むいずれのディレクトリが他のユーザと共有されるのに利用できるか、即ち、そのようなユーザのクライアントデバイスと同期されるかを指定する。通常、コンテンツ管理システムは、当該コンテンツアイテムを共有するように設計されている全てのクライアントデバイスで所定のコンテンツを同期する。結果として、それらのクライアントデバイスのそれぞれは、非常に大容量の共有コンテンツアイテムを格納することになる。いくつかのケースにおいて、共有コンテンツアイテムによってクライアントデバイス上の占有されるストレージの容量は、実質的に、非同期のコンテンツアイテムやアプリケーションなどの他のアイテムのための、クライアントデバイス上の利用可能なストレージの容量を低減することになる。

概要

コンテンツ管理システムは、ネットワークによって接続されるクライアントコンピューティングシステムに渡ってコンテンツアイテムを同期する。クライアントデバイス上の共有コンテンツアイテムのストレージ割り当てが、コンテンツアイテムを追加若しくはコンテンツアイテムを拡大するような編集を行う要求によって超えてしまう場合、クライアントアプリケーション又はコンテンツ管理システムのホストは、クライアントデバイス上の常駐から削除する一方で、コンテンツ管理システム上ではリモートに維持するコンテンツアイテムを選択する。選択されたコンテンツアイテムを削除すると、クライアントアプリケーションは、当該コンテンツアイテムを表すもののコンテンツアイテムのメタデータを含むのみのシャドウアイテムを作成する。これは、全ての同期される共有コンテンツアイテムへのユーザアクセスを維持しながら、十分なスペース創出する。ファイルジャーナルエントリは、格納アイテムがコンテンツアイテム又はシャドウアイテムかどうかを追跡しアンリするために使用されてもよい。

目的

[0002]本開示の実施形態は、一般的には、コンテンツアイテムの同期を提供する

効果

実績

技術文献被引用数
- 件
牽制数
- 件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

方法であって、ローカルファイルジャーナルクライアントデバイスに格納することであって、前記ローカルファイルジャーナルは複数のローカルエントリを含み、前記複数のローカルエントリのそれぞれは前記クライアントデバイス上の同期アイテムと対応し、かつ、前記同期アイテムのローカルネームスペースIDと、前記同期アイテムのローカルジャーナルIDと、前記同期アイテムのローカルブロックリストと、前記同期アイテムの複数のローカル属性とを有し、各同期アイテムは前記クライアントデバイス上のコンテンツアイテム又はシャドウアイテムに対応する、ことと、前記クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリはコンテンツアイテムの更新ネームスペースIDと、前記コンテンツアイテムの更新ジャーナルIDと、前記コンテンツアイテムの更新ブロックリストと、前記コンテンツアイテムの複数の更新属性と、前記コンテンツアイテムの更新同期タイプとを含む、ことと、前記コンテンツ管理システムに格納された前記コンテンツアイテムを表す前記クライアントデバイス上のシャドウアイテムを特定するために、前記受信した更新エントリを前記ローカルファイルジャーナルの前記複数のローカルエントリと比較することであって、前記シャドウアイテムは、前記表されるコンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記表されるコンテンツアイテムの前記ネームスペースID及び前記表されるコンテンツアイテムの前記ジャーナルIDを含む、ことと、前記シャドウアイテムの前記ネームスペースIDを前記更新ネームスペースIDと置き換え、前記シャドウアイテムの前記ジャーナルIDを前記更新ジャーナルIDと置き換えることによって、前記特定したシャドウアイテムを更新することと、前記シャドウアイテムに対応する前記ローカルエントリを前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項2

請求項1に記載の方法であって、さらに、前記更新ブロックリストと前記特定したシャドウアイテムの前記ブロックリストとの間の差異を特定する比較に基づいて、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることを判定することと、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、前記クライアントデバイスにおいて、前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記表されるコンテンツアイテムと置き換えることとを含むことを特徴とする方法。

請求項3

請求項1に記載の方法であって、さらに、前記更新エントリと関連付けられる強制再構成値に基づいて、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることを判定することと、前記コンテンツ管理システムから、前記コンテンツアイテムの前記更新ブロックリストによって示されるブロックをダウンロードすることと、前記クライアントデバイスにおいて、前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記表されるコンテンツアイテムと置き換えることとを含むことを特徴とする方法。

請求項4

請求項1に記載の方法であって、前記更新エントリは更新ファイルパスを含み、前記複数のローカルエントリのそれぞれはローカルファイルパスを含み、前記受信した更新エントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とする方法。

請求項5

請求項4に記載の方法であって、さらに、前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに置き換えられるべきであることを判定することと、前記更新ファイルパスによって特定される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することとを含むことを特徴とする方法。

請求項6

請求項1に記載の方法であって、さらに、前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、前記更新エントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うこととを含むことを特徴とする方法。

請求項7

請求項6に記載の方法であって、さらに、前記シャドウアイテムの前記変更時刻が前記更新変更時刻よりも遅いとの判定に応じて、前記クライアントデバイスのユーザによる前記変更を前記コンテンツ管理システムへコミットすることとを含むことを特徴とする方法。

請求項8

命令を格納する非一時的コンピュータ可読記憶媒体であって、クライアントデバイスによって実行されると、該クライアントデバイスに動作を実行させ、前記動作は、前記クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリは更新ネームスペースIDと、更新ジャーナルIDと、更新ブロックリストと、複数の更新属性と、更新同期タイプとを含む、ことと、前記受信した更新エントリを複数のローカルエントリと比較することであって、前記複数のローカルエントリのそれぞれはローカルネームスペースID、ローカルジャーナルID、ローカルブロックリスト、及び複数のローカル属性を有し、それぞれのローカルエントリは前記クライアントデバイス上のコンテンツアイテム又はシャドウアイテムと対応する、ことと、前記比較に基づいて、前記クライアントデバイス上のシャドウアイテムを特定することであって、前記シャドウアイテムは前記コンテンツ管理システム上に格納されたコンテンツアイテムを表し、前記シャドウアイテムは、前記表されるコンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記表されるコンテンツアイテムの前記ネームスペースID及び前記表されるコンテンツアイテムの前記ジャーナルIDを含む、ことと、前記シャドウアイテムの前記ネームスペースIDを前記更新ネームスペースIDと置き換え、前記シャドウアイテムの前記ジャーナルIDを前記更新ジャーナルIDと置き換えることによって、前記特定したシャドウアイテムを更新することと、前記シャドウアイテムに対応する前記ローカルエントリを前記更新エントリと置き換えることとを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項9

請求項8に記載の非一時的コンピュータ可読記憶媒体であって、さらに、前記比較に基づいて、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることを判定することと、前記コンテンツ管理システムから、前記更新ブロックリストによって特定されるブロックをダウンロードすることと、前記クライアントデバイスにおいて、前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記表されるコンテンツアイテムと置き換えることとを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項10

請求項9に記載の非一時的コンピュータ可読記憶媒体であって、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることの前記判定は、前記更新エントリに関連付けられた強制再構成値に基づいて行われることを特徴とする非一時的コンピュータ可読記憶媒体。

請求項11

請求項8に記載の非一時的コンピュータ可読記憶媒体であって、前記更新エントリは更新ファイルパスと、ローカルファイルパスを含む前記複数のローカルエントリのそれぞれとを含み、前記受信した更新エントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項12

請求項11に記載の非一時的コンピュータ可読記憶媒体であって、さらに、前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに置き換えられるべきであることを判定することと、前記更新ファイルパスによって特定される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することとを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項13

請求項8に記載の非一時的コンピュータ可読記憶媒体であって、さらに、前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、前記更新エントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うこととを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項14

請求項13に記載の非一時的コンピュータ可読記憶媒体であって、さらに、前記シャドウアイテムの前記変更時刻が前記更新変更時刻よりも遅いとの判定に応じて、前記クライアントデバイスのユーザによる前記変更を前記コンテンツ管理システムへコミットすることとを含むことを特徴とする非一時的コンピュータ可読記憶媒体。

請求項15

ステムであって、プロセッサと、命令を格納する非一時的コンピュータ可読記憶媒体であって、前記プロセッサによって実行されると、前記プロセッサに、クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリは更新ネームスペースIDと、更新ジャーナルIDと、更新ブロックリストと、複数の更新属性と、更新同期タイプとを含む、ことと、前記受信した更新エントリを複数のローカルエントリと比較することであって、前記複数のローカルエントリのそれぞれはローカルネームスペースID、ローカルジャーナルID、ローカルブロックリスト、及び複数のローカル属性を有し、それぞれのローカルエントリは前記クライアントデバイス上のコンテンツアイテム又はシャドウアイテムと対応する、ことと、前記比較に基づいて、前記クライアントデバイス上のシャドウアイテムを特定することであって、前記シャドウアイテムは前記コンテンツ管理システム上に格納されたコンテンツアイテムを表し、前記シャドウアイテムは、前記表されるコンテンツアイテムのコンテンツデータを含むことなく、少なくとも前記表されるコンテンツアイテムの前記ネームスペースID及び前記表されるコンテンツアイテムの前記ジャーナルIDを含む、ことと、前記シャドウアイテムの前記ネームスペースIDを前記更新ネームスペースIDと置き換え、前記シャドウアイテムの前記ジャーナルIDを前記更新ジャーナルIDと置き換えることによって、前記特定したシャドウアイテムを更新することと、前記シャドウアイテムに対応する前記ローカルエントリを前記更新エントリと置き換えることとを含む非一時的コンピュータ可読記憶媒体とを備えることを特徴とするシステム。

請求項16

請求項15に記載のシステムであって、さらに、前記比較に基づいて、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることを判定することと、前記コンテンツ管理システムから、前記更新ブロックリストによって特定されるブロックをダウンロードすることと、前記クライアントデバイスにおいて、前記シャドウアイテムを、前記ダウンロードしたブロックを含む前記表されるコンテンツアイテムと置き換えることとを含むことを特徴とするシステム。

請求項17

請求項16に記載のシステムであって、前記シャドウアイテムが前記表されるコンテンツアイテムと置き換えられるべきであることの前記判定は、前記更新エントリに関連付けられた強制再構成値に基づいて行われることを特徴とするシステム。

請求項18

請求項15に記載のシステムであって、前記更新エントリは更新ファイルパスと、ローカルファイルパスを含む前記複数のローカルエントリのそれぞれとを含み、前記受信した更新エントリを、前記複数のローカルエントリと比較することは、さらに、前記更新ファイルパスを、前記複数のローカルエントリのぞれぞれの前記ローカルファイルパスと比較することを含むことを特徴とするシステム。

請求項19

請求項18に記載のシステムであって、さらに、前記比較に基づいて、前記シャドウアイテムが新たなファイルパスに置き換えられるべきであることを判定することと、前記更新ファイルパスによって特定される場所に、前記クライアントデバイス上の前記シャドウアイテムを再配置することとを含むことを特徴とするシステム。

請求項20

請求項15に記載のシステムであって、さらに、前記比較に基づいて、前記シャドウアイテムが前記クライアントデバイスのユーザによる変更に基づいて保留中であることを判定することと、前記更新エントリに含まれる更新変更時刻と、前記シャドウアイテムに含まれる変更時刻とに基づいて、競合解決を行うこととを含むことを特徴とするシステム。

請求項21

方法であって、クライアントデバイスによって、プレースホルダアイテムとコンテンツアイテムとを含む複数の同期アイテムを格納することと、前記クライアントデバイスによって、複数のローカルエントリを含むローカルファイルジャーナルを格納することであって、各ローカルエントリは複数の同期アイテムの1つを表し、各ローカルエントリは前記同期アイテムのローカルジャーナルID、前記同期アイテムについてのローカルブロックリスト、前記同期アイテムの複数のローカル属性、及びローカル同期タイプを含み、前記ローカル同期タイプは前記同期アイテムがプレースホルダアイテム又はコンテンツアイテムかどうかを示す、ことと、前記クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリは前記複数の同期アイテムのうちのある同期アイテムの新たなバージョンを表し、かつ、前記ある同期アイテムについての更新ジャーナルIDと、前記ある同期アイテムの更新ブロックリストと、前記ある同期アイテムの複数の更新属性と、更新同期タイプとを含む、ことと、前記複数のローカルエントリから対応するローカルエントリを特定するために、前記受信した更新エントリを、前記複数のローカルエントリと比較することと、前記対応するローカルエントリによって表される前記ある同期アイテムが前記対応するローカルエントリのローカル同期タイプに基づくプレースホルダアイテムであることを判定することと、前記ある同期アイテムの前記新たなバージョンがコンテンツアイテムであることを示す前記更新同期タイプに応じて、前記コンテンツ管理システムから前記クライアントデバイスへ、前記更新ブロックリストによって示される前記ある同期アイテムの前記新たなバージョンについてのブロックをダウンロードすることと、前記クライアントデバイスにおいて、前記プレースホルダアイテムを、前記ダウンロードしたブロックを含む新たなコンテンツアイテムと置き換えることと、前記ローカルファイルジャーナルにおいて、前記ある同期アイテムについての前記対応するローカルエントリを、前記同期アイテムについての前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項22

請求項21に記載の方法であって、前記受信した更新エントリを前記複数のローカルエントリと比較することは、さらに、前記複数のローカルエントリからの前記ローカルジャーナルID、前記ローカルブロックリスト、及び前記複数のローカル属性と、前記更新エントリの前記更新ジャーナルID、前記更新ブロックリスト、及び前記複数の更新属性とを比較することによって、前記受信した更新エントリを前記複数のローカルエントリと比較することを含むことを特徴とする方法。

請求項23

請求項21に記載の方法であって、前記対応するローカルエントリによって表される前記ある同期アイテムが前記対応するローカルエントリのローカル同期タイプに基づくプレースホルダアイテムであることを判定することは、さらに、前記対応するローカルエントリの前記ローカルジャーナルIDが前記ある同期アイテムについての保留状態を示すかどうかを判定することと、前記コンテンツ管理システムからの前記対応するローカルエントリについての新たなローカルジャーナルIDと、関連するローカル変更時刻とを受信することと、前記ローカル変更時刻を、前記更新エントリと関連付けられた更新変更時刻と比較することと、前記更新エントリによって表される前記ある同期アイテムの前記新たなバージョンと、前記対応するローカルエントリによって表される前記ある同期アイテムとの間の競合を解決することとを含むことを特徴とする方法。

請求項24

請求項21に記載の方法であって、前記受信した更新エントリを、前記複数のローカルエントリと比較することは、更新機能を用いて完了され、前記更新機能は、前記ある同期アイテムの更新ファイルパスを、前記複数のローカルエントリのそれぞれのローカルファイルパスと比較し、前記ある同期アイテムの更新ジャーナルIDを、前記複数のローカルエントリのそれぞれの前記ローカルジャーナルIDと比較し、前記ある同期アイテムについての更新ブロックリストを、前記複数のローカルエントリのそれぞれの前記ローカルブロックリストと比較し、前記更新エントリに関連付けられる強制再構成値が前記同期アイテムが再構成されるべきであることを示すかどうかを判定することを特徴とする方法。

請求項25

請求項21に記載の方法であって、さらに、前記コンテンツ管理システムから前記更新エントリの強制再構成値を受信することと、前記強制再構成値が前記ある同期アイテムが再構成されるべきであることを示すことを判定することと、前記ある同期アイテムの前記新たなバージョンがコンテンツアイテムであることを、前記更新同期タイプに基づいて判定することと、前記コンテンツ管理システムから、前記更新ブロックリストによって示される前記ある同期アイテムの前記新たなバージョンのブロックをダウンロードすることと、前記ある同期アイテムを、前記ダウンロードしたブロックを含む新たなコンテンツアイテムと置き換えることと、前記対応するローカルエントリを前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項26

請求項25に記載の方法であって、前記更新ジャーナルIDが前記ローカルジャーナルIDと一致すること、前記更新ブロックリストが前記ローカルブロックリストと一致すること、前記複数の更新属性が前記複数のローカル属性と一致することを示す、前記更新エントリと前記対応するローカルエントリとの前記比較に関わらず、前記強制再構成値は、前記ある同期アイテムが再構成されるべきであることを示すことを特徴とする方法。

請求項27

請求項26に記載の方法であって、前記ある同期アイテムにういての前記複数の更新属性は、前記ある同期アイテムについての更新ファイルパスを含み、前記複数のローカル属性は、前記クライアントデバイス上で前記ある同期アイテムについてのローカルファイルパスを含むことを特徴とする方法。

請求項28

方法であって、クライアントデバイスによって、プレースホルダアイテムとコンテンツアイテムとを含む複数の同期アイテムを格納することと、前記クライアントデバイスによって、複数のローカルエントリを含むローカルファイルジャーナルを格納することであって、各ローカルエントリは複数の同期アイテムの1つを表し、各ローカルエントリは前記同期アイテムのローカルジャーナルID、前記同期アイテムについてのローカルブロックリスト、前記同期アイテムの複数のローカル属性、及びローカル同期タイプを含み、前記ローカル同期タイプは前記同期アイテムがプレースホルダアイテム又はコンテンツアイテムかどうかを示す、ことと、前記クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリは前記格納された同期アイテムのうちのある同期アイテムの新たなバージョンを表し、かつ、前記ある同期アイテムについての更新ジャーナルIDと、前記ある同期アイテムの更新ブロックリストと、前記ある同期アイテムの複数の更新属性と、更新同期タイプとを含む、ことと、前記複数のローカルエントリから対応するローカルエントリを特定するために、前記受信した更新エントリを、前記複数のローカルエントリと比較することと、前記対応するローカルエントリによって表される前記ある同期アイテムが前記対応するローカルエントリのローカル同期タイプに基づくコンテンツアイテムであることを判定することと、前記ある同期アイテムの前記新たなバージョンがプレースホルダアイテムであることを示す前記更新同期タイプに応じて、前記クライアントデバイスにおいて、前記コンテンツアイテムを、新たなプレースホルダアイテムと置き換えることと、前記ローカルファイルジャーナルにおいて、前記対応するローカルエントリを前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項29

請求項28に記載の方法であって、前記受信した更新エントリを前記複数のローカルエントリと比較することは、さらに、前記複数のローカルエントリからの前記ローカルジャーナルID、前記ローカルブロックリスト、及び前記複数のローカル属性と、前記更新エントリの前記更新ジャーナルID、前記更新ブロックリスト、及び前記複数の更新属性とを比較することによって、前記受信した更新エントリを前記複数のローカルエントリと比較することを含むことを特徴とする方法。

請求項30

請求項28に記載の方法であって、前記対応するローカルエントリによって表される前記ある同期アイテムが前記対応するローカルエントリのローカル同期タイプに基づくプレースホルダアイテムであることを判定することは、さらに、前記対応するローカルエントリの前記ローカルジャーナルIDが前記ある同期アイテムについての保留状態を示すかどうかを判定することと、前記コンテンツ管理システムからの前記対応するローカルエントリについての新たなローカルジャーナルIDと、関連するローカル変更時刻とを受信することと、前記ローカル変更時刻を、前記更新エントリと関連付けられた更新変更時刻と比較することと、前記更新エントリによって表される前記ある同期アイテムの前記新たなバージョンと、前記対応するローカルエントリによって表される前記ある同期アイテムとの間の競合を解決することとを含むことを特徴とする方法。

請求項31

請求項28に記載の方法であって、前記受信した更新エントリを、前記複数のローカルエントリと比較することは、更新機能を用いて完了されることを特徴とする方法。

請求項32

請求項28に記載の方法であって、さらに、前記コンテンツ管理システムから前記更新エントリを受信することであって、前記更新エントリは強制再構成値を含む、ことと、前記強制再構成値が前記ある同期アイテムが再構成されるべきであることを示すことに応じて、前記ある同期アイテムの前記新たなバージョンがプレースホルダアイテムであることを、前記更新同期タイプに基づいて判定することと、前記コンテンツアイテムを、新たなプレースホルダアイテムと置き換えることと、前記対応するローカルエントリを前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項33

請求項32に記載の方法であって、前記更新ジャーナルIDが前記ローカルジャーナルIDと一致すること、前記更新ブロックリストが前記ローカルブロックリストと一致すること、前記複数の更新属性が前記複数のローカル属性と一致することを示す、前記更新エントリと前記対応するローカルエントリとの前記比較に関わらず、前記強制再構成値は、前記ある同期アイテムが再構成されるべきであることを示すことを特徴とする方法。

請求項34

請求項33に記載の方法であって、前記ある同期アイテムにういての前記複数の更新属性は、前記ある同期アイテムについての更新ファイルパスを含み、前記複数のローカル属性は、前記クライアントデバイス上で前記ある同期アイテムについてのローカルファイルパスを含むことを特徴とする方法。

請求項35

方法であって、クライアントデバイスによって、プレースホルダアイテムとコンテンツアイテムとを含む複数の同期アイテムを格納することと、前記クライアントデバイスによって、複数のローカルエントリを含むローカルファイルジャーナルを格納することであって、各ローカルエントリは複数の同期アイテムの1つを表し、各ローカルエントリは前記同期アイテムのローカルジャーナルID、前記同期アイテムについてのローカルブロックリスト、前記同期アイテムの複数のローカル属性、及びローカル同期タイプを含み、前記ローカル同期タイプは前記同期アイテムがプレースホルダアイテム又はコンテンツアイテムかどうかを示す、ことと、前記クライアントデバイスによって、コンテンツ管理システムから更新エントリを受信することであって、前記更新エントリは前記格納された同期アイテムのうちのある同期アイテムの新たなバージョンを表し、かつ、前記ある同期アイテムについての更新ジャーナルIDと、前記ある同期アイテムの更新ブロックリストと、前記ある同期アイテムの複数の更新属性と、更新同期タイプとを含む、ことと、前記複数のローカルエントリから対応するローカルエントリを特定するために、前記受信した更新エントリを、前記複数のローカルエントリと比較することと、前記対応するローカルエントリによって表される前記ある同期アイテムが前記対応するローカルエントリのローカル同期タイプに基づくプレースホルダアイテムであることを判定することと、前記ある同期アイテムの前記新たなバージョンがプレースホルダアイテムであることを示す前記更新同期タイプに応じて、前記更新エントリに従って、前記対応するローカルエントリによって表される前記プレースホルダアイテムの前記属性を変更することと、前記ローカルファイルジャーナルにおいて、前記ある同期アイテムについての前記対応するローカルエントリを、前記同期アイテムについての前記更新エントリと置き換えることとを含むことを特徴とする方法。

請求項36

請求項35に記載の方法であって、前記複数の更新属性は更新ファイルパスを含み、前記複数のローカル属性はローカルファイルパスを含むことを特徴とする方法。

請求項37

請求項36に記載の方法であって、前記更新エントリに従って、前記対応するローカルエントリによって表される前記プレースホルダアイテムの前記属性を変更することは、前記更新エントリの前記更新ファイルパスに基づいて、前記プレースホルダアイテムのファイルパスを変更することをさらに含むことを特徴とする方法。

請求項38

請求項35に記載の方法であって、前記更新エントリに従って、前記対応するローカルエントリによって表される前記プレースホルダアイテムの前記属性を変更することは、前記更新ジャーナルIDに従って前記対応するローカルエントリの前記ローカルジャーナルIDを変更することをさらに含むことを特徴とする方法。

請求項39

請求項35に記載の方法であって、前記更新エントリに従って、前記対応するローカルエントリによって表される前記プレースホルダアイテムの前記属性を変更することは、前記更新ブロックリストに従って前記ローカルエントリの前記ローカルブロックリストを変更することをさらに含むことを特徴とする方法。

請求項40

請求項35に記載の方法であって、前記更新エントリに従って、前記対応するローカルエントリによって表される前記プレースホルダアイテムの前記属性を変更することは、前記更新エントリに関連付けられた変更時刻に従って前記ローカルエントリに関連付けられた変更時刻を変更することをさらに含むことを特徴とする方法。

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

0001

[0001]本出願は、2016年4月29日に出願の米国仮特許出願第62/327,379号、2016年12月30日に出願の米国特許出願第15/396,254号、及び2017年1月30日に出願の米国特許出願15,420,014号のそれらの全ては参照によりその全体が本明細書に組み込まれる。

技術分野

0002

[0002]本開示の実施形態は、一般的には、コンテンツアイテムの同期を提供するコンピュータシステムパフォーマンスを改善することに関し、とりわけ、同期されたコンテンツアイテムのストレージ割り当てが制限される、クライアントデバイスコンテンツ管理システムとの間のコンテンツアイテムの同期を改善することに関する。

背景技術

0003

[0003]コンテンツ管理システムは、ユーザがあるクライアントから他のクライアントへコンテンツアイテムを共有することを可能にする。当該クライアントは、記憶及び他のクライアントとの同期のために、コンテンツアイテムをコンテンツ管理システムに提供するコンピューティングデバイスである。他のクライアントは、他のユーザによって操作されてもよく、同一のユーザによって登録又は管理されるデバイスであってもよい。ユーザは、いずれのコンテンツアイテムが、又は、コンテンツアイテムを含むいずれのディレクトリが他のユーザと共有されるのに利用できるか、即ち、そのようなユーザのクライアントデバイスと同期されるかを指定する。通常、コンテンツ管理システムは、当該コンテンツアイテムを共有するように設計されている全てのクライアントデバイスで所定のコンテンツを同期する。結果として、それらのクライアントデバイスのそれぞれは、非常に大容量の共有コンテンツアイテムを格納することになる。いくつかのケースにおいて、共有コンテンツアイテムによってクライアントデバイス上の占有されるストレージの容量は、実質的に、非同期のコンテンツアイテムやアプリケーションなどの他のアイテムのための、クライアントデバイス上の利用可能なストレージの容量を低減することになる。

0004

図面の簡単な説明

0005


[0004]図1A及び図1Bは、制約付きの同期の一実施形態を示す概念図である。
[0005]図2は、クライアントデバイス間でコンテンツアイテムを同期するコンテンツ管理システムについてのシステム環境を示す図である。
[0006]図3は、クライアントデバイスのソフトウェアアーキテクチャを示す図である。
[0007]図4は、ローカルコンテンツディレクトリの既存のコンテンツアイテムにアクセスするための制約された同期の相互作用図である。
[0008]図5は、ローカルコンテンツディレクトリに格納される新たなコンテンツアイテムを作成するための制約付きの同期の相互作用図である。
[0009]図6は、制約付きの同期に基づくホストのシステム環境を示す図である。
[0010]図7は、ホストデバイスによって管理される制約付きの同期の相互作用図を示す図である。
[0011]図8は、リモート及びローカルのコンテンツアイテムを表すアイコンを有するローカルコンテンツディレクトリのためのユーザインタフェースを示す図である。
[0012]図9は、予測されたコンテンツアイテムの重要度を用いた制約付きの同期を示す概念図である。
[0013]図10は、制約付きの同期のための予測されたコンテンツアイテムの重要度を用いるコンテンツ管理システムのシステム環境を示す図である。
[0014]図11は、アイドル状態トリガされたコンテンツ管理を使用するクライアントデバイスのソフトウェア構成を示す図である。
[0015]図12は、アイドル状態でトリガされたコンテンツ管理を使用するコンテンツ管理システムについてのシステム環境を示す図である。
[0016]図13は、アイドル状態でトリガされたコンテンツ管理で使用される処理を示すフローチャートである。
[0017]図14は、一実施形態に係るファイルジャーナルの構造を示すブロック図である。
[0018]図15は、一実施形態に係る、コンテンツアイテムをコミットする詳細な処理を示すフローチャートである。
[0019]図16は、一実施形態に係る、コンテンツアイテムとプレースホルダアイテムとを置き換える詳細な処理を示すフローチャートである。
[0020]図17は、一実施形態に係る、コンテンツアイテムとプレースホルダアイテムとを置き換える詳細な処理を示すフローチャートである。
[0021]図18は、一実施形態に係る、プレースホルダアイテムをコンテンツアイテムへ変換する詳細な処理を示すフローチャートである。
[0022]図19は、更新ファイルジャーナルの更新エントリを受信すると、コンテンツ同期モジュールによって実行される更新機能アルゴリズムの一例を示すフローチャートである。
[0023]図20は、一実施形態に係る、共有ファイルパスにおいてアイテムを再構成するアルゴリズムを示すフローチャートである。
[0024]図21は、一実施形態に係る、共有ブロックリストでアイテムを再構成するアルゴリズムを示すフローチャートである。
[0025]図22は、一実施形態に係る、新たなアイテムとして更新アイテムを構成するアルゴリズムを示すフローチャートである。
[0026]図23は、一実施形態に係る、共有ジャーナルIDでアイテムを再構成するアルゴリズムを示すフローチャートである。 [0027]これらの図は説明の目的のためのみに本発明の様々な実施形態を図示するものである。当業者は、以下に示される構成及び方法の他の代替的な実施形態が以下に説明される発明の原理から乖離することなく用いられ得ることを以降の記載から容易に理解する。

実施例

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

[0044]図1Bを参照すると、クライアントデバイス100Aからコンテンツ管理システム110へコンテンツアイテム140Eが同期された後の、クライアントデバイス100A及びコンテンツ管理システム110が示される。

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

[0056]これらの処理は表1でさらに説明する。本例において、75MBのストレージがコンテンツアイテムを格納するために必要とされる。コンテンツアイテムA及びBのトータルが70MBしかないため、それらの2つのコンテンツアイテムの削除は当該アイテムについての十分な量のストレージを提供することはできない。従って、トータルの累積サイズが150MBとなるコンテンツアイテムA、B及びCが、(最右列の指定によって示されるように)対応するインデックス00、01、及び02で選択される。

0035

0036

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

0037

[0058]表2は、リモートLRAがどのように実装されうるかの一例である。本例において、コンテンツアイテムB及びCは、異なるクライアントデバイス上で、それぞれ2014/5/24と2014/4/5において最後にリモートにアクセスされているが、(表1に記載するように)両方とも2014/3/24において最後にローカルにアクセスされている。それらのリモートアクセスに起因するアイテムB及びCについての最新アクセスの日付の変更は、基本的なLRAの選択が使用される場合と比較して、キューの中でそれらをさらに遠くに移動させる。結果として、本例において、アイテムA及びDがA、B及びCの代わりに選択される。

0038

0039

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

0040

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

0041

0042

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

0043

[0060]表3は、当該選択方法の一例である。本例では、40MBのストレージがコンテンツアイテムを格納するために必要とされる。アイテムBが40MBの必要なストレージ値を超える、キューインデックスによる第1のコンテンツアイテムであるため、クライアント100から削除するように選択される。
Score = w1S+w2A
ここで、Sはコンテンツアイテムのサイズを表すメトリックであり、Aはコンテンツアイテムに最後にアクセスしてからの時間を表すメトリックであり、w1及びw2は重みである。A及びSへの重み付けは、ユーザによって決定されるように、それらの相対的な重要度に基づくことができ、或いは、特定のクライアントデバイス100上のコンテンツアイテムに対するアクセスパターンを示す履歴コンテンツアイテムに基づくことができる。その後、キューはスコアによって順序付けされ、キューの最初のコンテンツアイテムは削除用に選択される。

0044

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

0045

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

0046

0047

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

0048

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

0049

[0066]表5は本選択方法の一例である。本例において、必要なストレージスペースは40MBであり、重みw1及びw2は両方1である。当該キューはトータルスコアによって順序付けされ、累積和が必要なストレージスペースと比較される。これは、クライアントデバイス100からの削除用に選択されたアイテムC及びEの結果となる。

0050

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

[0099]図7は、ホスト管理の制約付きのストレージ同期のプロセスの一実施形態を示す相互作用図である。クライアントデバイス100上のアプリケーションは、コンテンツアイテムについて、クライアントデバイス上で同期されるフォルダに保存されるように要求する(700)。ストレージカーネル拡張部は、要求ID、ファイルパス、及びコンテンツアイテムのサイズを記録し(702)、当該情報をクライアントアプリケーション200へ転送する(704)。クライアントアプリケーション200は、制約付きのコンテンツ管理システム600上のストレージ管理モジュール350へコンテンツアイテムのサイズ情報を転送する(706)。ストレージ管理モジュール350は、クライアント構成ファイル610からコンテンツアイテムサイズを受信した特定のクライアントについてストレージ制限を要求する(708)。ストレージ管理モジュール350は、クライアントデバイス100上に常駐する他のコンテンツアイテムに追加したサイズを、クライアント構成ファイル610から受信したストレージ割り当てと比較することによって、ストレージ制限が超過するかどうかを判定する(712)。ストレージ管理モジュール350は、同期テーブル620からクライアント上のコンテンツデータを要求し(714)、これにより、クライアント上の同期されたコンテンツアイテムから、クライアントから削除されるコンテンツアイテムが選択されうる。同期テーブルは特定のクライアントについての同期されるコンテンツデータを応答する(716)。ストレージ管理モジュール350は、LRAコンテンツアイテムを決定するために使用するホストデバイス上に格納されたユーザデータ630からユーザアクセスデータを要求する(718)。当該データはすぐにユーザデータテーブル630から受信される(820)。ストレージ管理モジュール350は、LRAコンテンツアイテムを決定し(722)、必要なストレージスペースを提供するために、クライアントから削除されるべきそれらを選択する(724)。ストレージ管理モジュール350は、コンテンツアイテム削除し、プレースホルダアイテムを作成する(728)要求をクライアントアプリケーション200に送信する。コンテンツアイテムを保存する元の要求700を完了するために、クライアントアプリケーション200に許可を与える(730)。最後に、ストレージ管理モジュールは、保存したコンテンツアイテムへの第1のコンテンツアイテムへのアクセスを反映するようにユーザデータを更新し(732)、その後、新たなコンテンツアイテムがアップロードするのに利用可能であるため、メタデータサーバ212からクライアントデバイス100の同期を要求する(734)。

0084

[00100]図8は、制約付きの同期を提供するコンテンツ管理システムと連携して動作するクライアントデバイス100のユーザインタフェースの一例を示す。同期ファイルフォルダ800は、共有コンテンツストレージディレクトリ120のように動作する。フォルダ800は、それぞれが対応するアイコン810A、.m4a音楽ファイル810B、.xlsxスプレッドシート810C、.docxワード処理ファイル810D、.mat Matlabファイル810E、及び.jpg画像ファイルで表される、多数のコンテンツアイテムを含む。各アイコン810は、コンテンツアイテムのストレージ状態を示す状態アイコン820で重畳される。

0085

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

0086

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

0087

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

0088

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

0089

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

0090

[0101]段階9.1は、コンテンツアイテムへのユーザアクセスを予測する、コンテンツ管理システムの典型的な状態を示す。この図例において、コンテンツ管理システム110は、2つのクライアントデバイス100A及び100Bを管理している。共有コンテンツストレージディレクトリ120A及び120Bがそれぞれのクライアントデバイス内に配置される。共有コンテンツストレージディレクトリ120Aは、コンテンツアイテム140A、140B及び140Cを格納し、一方、共有コンテンツストレージディレクトリ120Bは、コンテンツアイテム140Dと、コンテンツアイテム140Aのシャドウアイテム表現160Aを格納する。全てのコンテンツアイテム140の同期バージョンは、コンテンツ管理システム110に格納される。

0091

[0102]さらに、各コンテンツアイテム140は、対応する保存スコア900を有し、900Aはコンテンツアイテム140Aの保存スコアであり、900Bはコンテンツアイテム140Bの保存スコアである。各共有コンテンツストレージディレクトリはまた、保存スコア閾値910で構成され、910Aは共有コンテンツストレージディレクトリ120Aについての保存スコア閾値であり、910Bは共有コンテンツストレージディレクトリ120Bについての保存スコア閾値である。

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

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

0107

[0118]システムアクティビティの測定値が所定のアクティビティ閾値を下回る場合、システム状態モジュール1150は、クライアントデバイスが現在アイドル状態であると保存スコアモジュール1110に報告する。このアクティビティ閾値はアクティビティメトリックによって定義されるように、クライアントデバイスのトータルの計算リソースの割合として定義されてもよく、或いは、アクティビティ閾値はアクティビティメトリックの特有の値として定義されてもよい。例えば、アクティビティ閾値は、利用可能な処理リソースの25%より低いものを用いる、クライアントデバイス100の状態として定義されてもよい。或いは、アクティビティ閾値は、クライアントデバイス100の他のプロセスがトータルで2GBより少ないメモリを用いる状態として、又は、クライアントデバイス上で少なくとも4GBの利用可能なトータルメモリが存在するように、定義されてもよい。

0108

[0119]クライアントデバイス100がシステム状態モジュール1150によってアイドル状態であると判定されると、状態計算モジュール1120は、共有コンテンツストレージディレクトリ120の保存状態を判定する。通常、保存状態は、クライアントデバイス上に常駐するコンテンツアイテムと、それらのコンテンツアイテムに対応する属性のセットとを含んで構成される。それらの属性は、コンテンツアイテムのサイズ、最新アクセス時刻、アクセス頻度、ディレクトリ場所、又は、クライアントデバイス上での保存についてコンテンツアイテムの重要度を示す任意の他の適切な属性を含んでもよい。さらに、保存状態は、上述した属性の少なくとも1つを用いて計算された統計値のセットによって表されてもよい。

0109

[0120]比較モジュール1130は、状態計算モジュール1120から保存状態を受信し、その後、共有コンテンツストレージディレクトリ120の現在の保存状態を、構成ファイル368で定義された、ユーザによって指定されてもよい、所定の閾値保存状態と比較する。閾値保存状態は、属性に関連する基準のセットであってもよく、或いは、保存状態に含まれるクライアントデバイスの計算された統計値であってもよい。比較モジュール1130は、現在の保存状態が閾値保存状態の基準を満足するかどうかを判定する。これらの基準に反する(例えば、満足されない)場合、比較モジュール1130は、閾値保存状態の基準に反する属性に対応するコンテンツアイテム、又はそれらの属性に基づいて計算された統計値を、アクションモジュール1140に報告する。

0110

[0121]アクションモジュール1140は、比較モジュール1130からの報告を受信する。その後、保持状態を閾値保存状態の基準内に戻すためのアクションを判定する。それらのアクションは、共有コンテンツストレージディレクトリ120からコンテンツアイテムを削除することと、それらとシャドウアイテムとを置き換えること又はリモートコンテンツアイテムを表すシャドウアイテムとコンテンツアイテム自身とを置き換えることとを含んでもよい。それらのアクションが決定されると、アクションモジュール1140は、コンテンツ同期モジュール310が必要なアクションを完了するように要求する。

0111

[0122]或いは、クライアントデバイス上の計算負荷を低減し、かつ、他のユーザにおけるデバイスの利用可能性を増大する、アイドル状態をトリガとした制約付きの同期がコンテンツ管理システム自身によって行われてもよい。図12は、本タスクを完了するシステム環境を示す。制約付きのコンテンツ管理システム1200は、メタデータサーバ212、ブロックサーバ214、通知サーバ216、データストア218、保留ブロックテーブル220、ネームスペーステーブル222、ストレージ管理モジュール350、クライアント構成ファイル610、同期テーブル620、ユーザデータ630、保存状態テーブル1210、及び保存状態モジュール1220を含んで構成される。別段の指定がない限り、前述のモジュール及びデータテーブルの全ては、新たなモジュールを適合するために当業者が認識するように僅かに変更されるものの、前述したものと同じ機能を有する。任意の主要は変更について以下で説明する。

0112

[0123]本バージョンの実施形態において、コンテンツ管理システム1200に接続されるクライアントデバイス上のクライアントアプリケーション200は、クライアントデバイスの状態について、コンテンツ管理システム1200へ報告する。クライアントデバイスがアイドルである場合、コンテンツ管理システム1200は、保存状態モジュール1220を用いて、アイドルのクライアントデバイス上の共有コンテンツストレージディレクトリ120の保存状態を判定する。保存状態モジュールはその後、コンテンツ管理システム1200に接続される全てのクライアントデバイスの現在の保存状態を含む、保存状態テーブル1210を更新する。保存状態モジュール1220はその後、図11の記載で説明したように、潜在的に同様のサブモジュールを用いて、保存状態モジュール1110と同様のステップを行う。

0113

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

0114

[0125]各クライアントデバイスをチェックするために使用される期間は、ユーザによって設定された、コンテンツ管理システムの所定値であってもよく、或いは、特定のクライアントデバイスの使用パターンに基づいて判定されてもよい。例えば、ユーザが平均24時間ごとにそれらのクライアントデバイス上のコンテンツアイテムにアクセスする場合、当該期間は、共有コンテンツストレージディレクトリが24時間が経過するまで維持されることを保証するように設定されてもよい。

0115

[0126]共有コンテンツディレクトリを周期的にチェックする代わりに、共有コンテンツディレクトリが、例えばハードウェアストレージ制限に近い緊急性を示す第2の基準のセットを満たす場合にのみ、共有コンテンツディレクトリを維持するようにしてもよい。

0116

[0127]ストレージスペース基準:1つの可能性のある基準のセットは、ストレージ割り当ての基準を有することである。例えば、ストレージ割当ては、20GBに設定することができるが、上記実施形態と同様に動作する代わりに、コンテンツ管理システムは、当該デバイスがアイドルとなるまで、共有コンテンツストレージディレクトリに格納されたコンテンツアイテムが基準値(この例では20GB)を超えることを許容する。その後、放置コンテンツアイテムを判定する同様の処理が適切なコンテンツアイテムを削除し、共有コンテンツストレージディレクトリのストレージスペース基準を満足するために使用される。

0117

[0128]アクセス時刻基準第2の基準はアクセス時刻基準であってもよい。例えば、当該基準は、これまでに所定の時間間隔よりも前の最新のアクセス時刻を有するコンテンツアイテムが共有コンテンツストレージディレクトリ内に常駐することができない状態であるとしてもよい。それらのコンテンツアイテムは、クライアントデバイスがアイドルとなるまで、共有コンテンツストレージディレクトリ内にそのまま常駐することが許容されるであろう。この時点で、保存状態モジュールは、所定の時間間隔より前の最新アクセス時刻を有する全てのコンテンツアイテムの削除を単に要求するであろう。

0118

[0129]コンテンツアイテムのサイズ基準基準のその他のセットは、コンテンツアイテムのサイズ基準である。この方法では、個々のコンテンツアイテムのサイズについて閾値が設定される。従って、デバイスがアイドルである場合には、閾値を超える又は下回る任意のコンテンツアイテムは、クライアントデバイス上での常駐から除外される。

0119

[0130]アクセス頻度基準:最後に、アクセス頻度基準が、クライアントデバイス上で常駐を維持するために必要とされる所定の時間間隔内での最小のアクセス数を設定するために使用される。特定のコンテンツアイテムが十分な頻度でアクセスされない場合、アイドル状態の際に、クライアントデバイスから削除される。

0120

[0131]なお、保存基準のリストは完全に網羅されているわけではない。さらに、それらの基準が他のものと組み合わせて使用されることにより、より複雑な規則となるようにしてもよい。

0121

[0132]図13は、アイドル状態をトリガとした制約付きコンテンツ管理の機能を示すフローチャートである。先ず、システムは、特定のクライアントデバイスがアイドルであるかどうかを判定するチェックを行う(1300)。当該ステップは、周期的に又はコンテンツストレージディレクトリが所定の閾値に到達することに応じての何れかで行われる。デバイスがアイドルであれば、システムは、クライアントデバイスの保存状態を判定する(1310)。その後、システムは、共有コンテンツストレージディレクトリの現在の保存状態と、共有コンテンツストレージディレクトリについての保存状態基準とを比較する。基準が共有コンテンツストレージディレクトリの現在の保存状態によって満足されれば、システムは、クライアントデバイスがアイドルどうかを判定するためにチェック(1300)を再度行う。保存状態の基準に反していれば、システムは、保存状態の基準に合うように共有コンテンツストレージディレクトリに対して必要とされる、共有コンテンツストレージディレクトリ上で実行するアクション特定する(1330)。システムはその後、所定の保存状態基準に一致させるように共有コンテンツストレージディレクトリ上でそれらのアクションを実行する(1340)。

0122

<コンテンツアイテムと並行したプレースホルダアイテムの同期>
[0133]図14は、一実施形態に係るファイルジャーナル360の構造を示すブロック図である。ファイルジャーナル360は、クライアントデバイスの共有コンテンツストレージディレクトリに各コンテンツアイテム又はプレースホルダについてのエントリを含む。ファイルジャーナルは、ローカルファイルジャーナル1400と、更新ファイルジャーナル1410との2つのセクションを含む。各ジャーナルは、ファイルアイテムのリストについてのメタデータを含む(リストされたアイテムは同じアイテム又は異なるアイテムを含んでもよい。)。ローカルファイルジャーナル1400は、クライアントデバイス上に現在常駐しているアイテムのメタデータを含む。当該メタデータは、ローカルネームスペースID、ローカルジャーナルID、ローカルファイルパス、ローカルブロックリスト、ローカル拡張属性ローカルサイズ、ローカル変更時刻、及びローカル同期種別を含んでもよい。アイテムの各バージョンは、ネームスペースID及びジャーナルIDのペアによって一意に識別される。ローカルファイルジャーナルの各フィールドについて以下で説明する。

0123

[0134]ローカルネームスペースID:当該アイテムに関連付けられるネームスペースを示すメタデータ値

0124

[0135]ローカルジャーナルID:アイテムのバージョンに対応する特定のジャーナルエントリを示すメタデータ値。

0125

[0136]ローカルファイルパス:共有のコンテンツストレージディレクトリにおける当該アイテムの場所を示すメタデータ値。

0126

[0137]ローカルブロックリスト:当該アイテムを含むブロックを示すメタデータ値。

0127

[0138]ローカル拡張属性:当該アイテムの追加属性を含むメタデータ値。これらは、当該アイテムの最新アクセス時刻、作成時刻、又は任意の他の属性を含んでもよい。

0128

[0139]ローカルサイズ:当該アイテムのサイズを示すメタデータ値。当該アイテムがプレースホルダアイテムとして分類される場合、当該アイテムのローカルサイズは、プレースホルダアイテムによって表されるコンテンツのサイズである。

0129

[0140]ローカル変更時刻:当該アイテムへの最新の変更が発生した時刻を示すメタデータ値。

0130

[0141]ローカル同期タイプ:当該アイテムがコンテンツアイテムであるか又はプレースホルダアイテムであるかを示すメタデータ値。

0131

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

0132

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

0133

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

0134

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

0135

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

0136

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

0137

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

0138

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

0139

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

0140

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

0141

[0151]コンテンツ管理ステム110は、新たなコンテンツアイテム又はコンテンツアイテムのバージョンがネームスペースに追加された場合に、新たなジャーナルIDを作成する。これが発生すると、コンテンツ管理システム110は、新たなコンテンツアイテム又はメタデータサーバ212からのコンテンツアイテムバージョンに関連付けられたメタデータを、当該ネームスペースに関連付けられるクライアントデバイス100にプッシュ送信する。送信したメタデータがクライアントデバイス100によって受信されると、コンテンツ同期モジュール310は、更新ファイルジャーナル1410のエントリとして当該メタデータを保存する。結果としてエントリの更新同期タイプは、送信したメタデータに含まれなくてもよく、代わりに、一実施形態に従ってクライアントアプリケーション200によって判定されてもよい。

0142

[0152]更新ファイルジャーナル1410のエントリとしてメタデータを保存すると、更新機能1900は、更新ファイルジャーナル1410のエントリ(アイテムの変更又は新たなバージョンを表す)と、ローカルファイルジャーナル1400に含まれるエントリとの間の差異を解決するために、以下のステップを実行する。更新機能は、まず1910で、更新ファイルジャーナルエントリの更新ファイルパスがクライアントデバイス100上に格納された任意のローカルジャーナルエントリのローカルファイルパスと等しいかどうかを判定する。同一のファイルパスを有するローカルジャーナルエントリがあれば、更新機能はその後、1920で、更新エントリの更新ジャーナルIDがローカルエントリのローカルジャーナルIDと一致するかどうかを判定することによって、更新ジャーナルエントリによって表されるアイテムがクライアントデバイス100上に配置されるアイテムの新たなバージョンであるかどうかを判定する。更新ジャーナルIDがローカルジャーナルIDと一致しなければ、コンテンツ同期モジュール310は、ローカルジャーナルエントリによって表される当該アイテムの新たなバージョンが存在することを確定し、共有ファイルパスにおいてアイテムを再構成するための処理を開始する。当該処理については図20を参照して詳細に後述する。

0143

[0153]一方、コンテンツ同期モジュール310が1920で更新ジャーナルIDがローカルジャーナルIDと等しいと判定する場合、コンテンツ同期モジュール310は、1940で、強制再構成値が更新エントリについてtrueであるかどうかを判定する。強制再構成値がtrueである場合、コンテンツ同期モジュール310は、共有ジャーナルIDでアイテムを再構成するための処理を開始する。当該処理については図23を参照して詳細に後述する。

0144

[0154]コンテンツ同期モジュール310が1940で強制再構成値がfalseであると判定すると、その結果、更新ジャーナルエントリは、1990で、それが重複した更新と見なされて、クライアントアプリケーション200による更なるアクションなしで、削除される。

0145

[0155]ステップ1910に戻り、更新機能1900はまた、1910で、更新ファイルパスがローカルファイルジャーナル1400に格納されるエントリのいずれのローカルファイルパスも同一でないと判定する。この場合、コンテンツ同期モジュール310は、1930で、更新エントリの更新ブロックリストがローカルファイルジャーナル1400のローカルブロックリストの何れかと一致するかどうかを判定する。更新ブロックリストが固有のものであれば、その結果、更新機能1900は、更新エントリが新たなアイテムを示し、図22を参照して詳細に後述する処理に従って新たなアイテムとして当該更新アイテムを構成すると判定する。

0146

[0156]コンテンツ同期モジュール310が1930で更新ブロックリストがローカルファイルジャーナル1400のローカルブロックリストと一致すると判定すると、その結果、コンテンツ同期モジュールは、1950で、更新ジャーナルIDが、一致するブロックリストを有するローカルエントリのローカルジャーナルIDと一致するかどうかを判定する。それらのジャーナルIDが一致しない場合、その結果、コンテンツ同期モジュール310は、共有のブロックリストを用いてアイテムを再構成する。当該処理については図21を参照して詳細に後述する。

0147

[0157]一方、コンテンツ同期システムが1950で更新ジャーナルIDが、一致するブロックリストを有するローカルジャーナルエントリからのローカルジャーナルIDと一致すると判定すると、その結果、更新機能1900は、ステップ1940に戻り、上述したように進む。

0148

<共有ファイルパスにおけるアイテムの再構成>
[0158]図20は、共有ファイルパスにおいてアイテムを再構成するアルゴリズムの一実施形態を示すフローチャートである。図20によって説明されるアルゴリズムは、更新機能1900のステップ1920の否定的な判定の結果として発生する。共有ファイルパスにおいてのアイテムの再構成は、コンテンツアイテムの新たなバージョンがコンテンツ管理システム110へアップロードされた場合、又は、コンテンツアイテムが同じファイルパスに残っている場合にコンテンツアイテムがプレースホルダアイテムに変換されている場合若しくはその逆の場合に発生する。当該アルゴリズムの第1のステップは、2000で、ローカルエントリに対応するコンテンツアイテムが現在編集されていることを示す、共有のファイルパスを有するローカルファイルジャーナルエントリのローカルジャーナルIDが保留されているかどうかを判定する。対応するローカルジャーナルIDが保留されている場合、当該システムは、2005で、コンテンツアイテムへの任意の更なる変更が完了するまでと、ローカルエントリがコンテンツ管理システム110から新たなローカルジャーナルIDを受信するまで待機する。新たなジャーナルIDを受信すると、2010で、何れの変更がより最近行われたかを判定するために、更新エントリの更新された変更時刻と、ローカルエントリの新たなローカル変更時刻とが比較される。2015で、変更時刻の比較と当該アイテムに行われた特定の編集とに基づいて、競合が解決される。競合解決中に、更新ブロックリストにリストされた同一のブロックがまだ関連する場合、それらは、ダウンロードされ、共有ファイルパスに格納されるであろう。競合解決処理の結果、ローカル又は更新された変更の最終的なプロダクトとは異なるアイテムをもたらす場合、その結果、当該アイテムは、再度ハッシュ値が計算され、図15を通じて新たなブロックリストが生成される。当該アイテムへのローカルの変更が遠隔で行われた変更(更新エントリに表される)に優先する場合、その結果、当該更新エントリは、破棄されてもよい。

0149

[0159]ステップ2000に戻り、コンテンツ同期モジュール310は、2000で、共有ファイルパスを有するローカルエントリのローカルジャーナルIDが保留されていないと判定し、その結果、当該エントリに対応する当該アイテムが現在編集されていないことを示す。当該判定に基づいて、コンテンツ同期モジュール310は、2020で、更新された同期タイプが”プレースホルダアイテム”又は”コンテンツアイテム”に設定されているかどうかを判定する。更新同期タイプが”コンテンツアイテム”を示す場合、その結果、コンテンツ同期モジュール310は、2030で、更新ブロックリストが共有ファイルパスを有するローカルジャーナルエントリのローカルブロックリストと等しいかどうかを判定する確認を行う。2つのブロックリストが等しい場合、コンテンツ同期モジュール310は、コンテンツ管理システム110から追加のブロックをダウンロードする必要はなく、代わりに、更新ファイルジャーナル1410から更新ジャーナルエントリを削除する前に、単にローカルジャーナルエントリの属性と更新ジャーナルエントリの属性とを置き換えるだけである。

0150

[0160]2030で2つのブロックリストが異なっていると判定されると、コンテンツ同期モジュール310は、2045で、コンテンツ管理システム110から更新ブロックリストのブロックを要求する更新ブロックを受信すると、コンテンツ同期モジュール310は、2050で、受信したブロックに基づいて、共有ファイルパスにおいて更新したコンテンツアイテムを作成する。最後に、ローカルジャーナルエントリは、2055で、更新エントリが更新ファイルジャーナル1410から削除される前に、更新したジャーナルエントリと置き換えられる。

0151

[0161]ステップ2020に戻り、コンテンツ同期モジュール310が2020で、当該アイテムが”プレースホルダアイテム”になるべきことを示す更新同期タイプであると判定すると、その結果、コンテンツ同期モジュール310は、2025で、共有ファイルパスにおいて、当該アイテムのローカル同期タイプを判定する。ローカル同期タイプが当該アイテムが既にプレースホルダアイテムであることを示す場合、2035で、オリジナルのプレースホルダアイテムに置き換える、更新されたプレースホルダアイテムが、共有ファイルパスにおいて作成される。更新されたプレースホルダアイテムは、更新されたネームスペースID及びジャーナルIDについてのメタデータを含む。更新されたプレースホルダアイテムを2035で作成した後、ローカルジャーナルエントリは、2055で、更新したジャーナルエントリと置き換えられ、更新ジャーナルエントリは更新ファイルジャーナル1410から削除される。

0152

[0162]ステップ2025に戻り、コンテンツ同期モジュール310が、ローカル同期タイプが”コンテンツアイテム”、即ち、コンテンツアイテムを表すと判定した場合、コンテンツ同期システムは、2040で、共有ファイルパスにおけるコンテンツアイテムを、更新されたネームスペース及びジャーナルIDのペアを有するプレースホルダアイテムと置き換える。コンテンツアイテムが2040でプレースホルダアイテムと置き換えられた後、コンテンツ同期モジュール310は、2055で、ローカルジャーナルエントリを、更新したジャーナルエントリと置き換え、更新ファイルジャーナル1410から更新ジャーナルエントリを削除する。

0153

<共有ブロックリストでのアイテムの再構成>
[0163]図21は、共有ブロックリストでアイテムを再構成するアルゴリズムの一実施形態を示すフローチャートである。図21のアルゴリズムは、更新機能1900のステップ1950の否定的な判定の結果として発生する。アイテムが共有ブロックリストの異なるファイルパスに位置するが、更新ブロックリストと同じブロックリストを有する場合、コンテンツ同期モジュール310は、アイテムを共有ブロックリストで再構成する。この状況は、アイテムが1つのファイルパスから他のファイルパスに移動した場合に発生する。

0154

[0164]まず、コンテンツ同期モジュール310は、2100で、ローカルジャーナルIDが保留中かどうかを判定する。ローカルジャーナルIDが保留中であれば、コンテンツ同期モジュール310は、前述した競合解決ステップ(図21の2105、2110、2115及び図20の2005、2010、2015を参照)に進む。競合解決の結果、共有ブロックリストを有するローカルジャーナルエントリに対応するコンテンツアイテムは、更新ファイルパスへ移動されてもよく、新たなファイルパスへ移動されてもよく、或いは、当該アイテムが新たなファイルパスへ移動されたと同時にコンテンツが変更されてもよい。

0155

[0165]ローカルジャーナルIDが2100で保留中でないと判定されると、その結果、コンテンツ同期モジュール310は、2120で、更新エントリの更新同期タイプを判定する。更新同期タイプが当該更新アイテムが”コンテンツアイテム”であるべきことを示す場合、その結果、共有ブロックリストを有するコンテンツアイテムは、2125で、ローカルファイルパスから、更新ジャーナルエントリに示される更新ファイルパスへ移動される。コンテンツ同期モジュール310は、その後、2130で、ローカルジャーナルエントリを更新ジャーナルエントリと置き換え、更新ファイルジャーナル1410から更新ジャーナルエントリを削除する。

0156

[0166]ステップ2120に戻り、コンテンツ同期モジュール310が2120で、当該更新アイテムが”プレースホルダアイテム”であることを指定する更新同期タイプであると判定する場合、コンテンツ同期モジュール310は、2135で、ローカル同期タイプと判定する。ローカル同期タイプが”コンテンツアイテム”である場合、その結果、ローカルエントリに対応し、かつ、共有ブロックリストを有するコンテンツアイテムは、2140で、更新ネームスペースID及びジャーナルIDを有するプレースホルダアイテムと置き換えられる。当該プレースホルダアイテムは、その後、更新ファイルパスによって示される位置に移動される。コンテンツアイテムをプレースホルダアイテムと置き換えると、コンテンツ同期モジュール310は、2130で、ローカルジャーナルエントリを、更新したジャーナルエントリと置き換え、更新ファイルジャーナル1410から更新ジャーナルエントリを削除する。

0157

[0167]ローカル同期タイプが2135で”プレースホルダアイテム”であるべきと判定されると、ローカルネームスペースID及びジャーナルIDのペアを有するローカルプレースホルダアイテムは、2145で、更新ネームスペースID及びジャーナルIDのペアを有する更新プレースホルダアイテムと置き換えられる。コンテンツ同期モジュールは、その後、更新プレースホルダアイテムを更新ファイルパスに保存する。2145でローカルプレースホルダアイテムを更新プレースホルダアイテムと置き換え、プレースホルダアイテムを新たなファイルパスに再配置すると、コンテンツ同期モジュール310は、2130で、ローカルジャーナルエントリを、更新したジャーナルエントリと置き換え、更新ファイルジャーナル1410から更新ジャーナルエントリを削除する。

0158

<新たなアイテムとして更新アイテムを構成>
[0168]図22は、新たなアイテムとして更新アイテムを構成するアルゴリズムの一実施形態を示すフローチャートである。図22のアルゴリズムは、更新機能1900のステップ1930の否定的な判定の結果として発生する。ローカルファイルジャーナル1400のエントリが、更新エントリの更新ファイルパス又は更新ブロックリストと一致する、ローカルファイルパス又はブロックリストを有していない場合、コンテンツ同期モジュール310は、新たなアイテムとして更新アイテムを構成する。

0159

[0169]新たなアイテムを構成する場合、コンテンツ同期モジュール310は、まず、2200で、更新アイテムについての更新同期タイプを判定する。更新同期タイプがプレースホルダアイテムについてのものである場合、コンテンツ同期モジュール310は、2220で、当該更新ファイルパスにおいて、更新ネームスペースID及び更新ジャーナルIDのペアを有するプレースホルダアイテムを作成する当該更新エントリは、その後、2215で、ローカルファイルジャーナル1400へコピーされ、当該更新エントリは更新ファイルジャーナル1410から削除される。

0160

[0170]コンテンツ同期モジュール310が2200で、当該更新アイテムがコンテンツアイテムであることを示す更新同期タイプであると判定する場合、その結果、コンテンツ同期モジュール310は、2205で、コンテンツ管理システム110から更新ブロックリストによって指定されるブロックを要求する。要求したブロックを受信すると、コンテンツ同期モジュール310は、2210で、要求したブロックを用いて、更新ファイルパスにおいて更新したコンテンツアイテムを作成する。当該コンテンツアイテムが作成されるとすぐに、当該更新エントリは、その後、2215で、ローカルファイルジャーナル1400へコピーされ、当該更新エントリは更新ファイルジャーナル1410から削除される。

0161

<共有ジャーナルIDでのアイテムの再構成>
[0171]図23は、共有ジャーナルIDでアイテムを再構成するアルゴリズムの一実施形態を示すフローチャートである。図23によって説明されるアルゴリズムは、更新機能1900のステップ1940の肯定的な判定の結果として発生する。強制再構成値が”true”と識別されると、共有ジャーナルIDでのアイテムの再構成が行われる。これは、更新ジャーナルエントリがコンテンツ同期モジュール310自身によって作成された場合に、共有コンテンツストレージディレクトリのアイテムがコンテンツアイテムからプレースホルダアイテムへ変換されているか、又はその逆が行われていることを意味する。

0162

[0172]まず、コンテンツ同期モジュール310は、2300で、更新エントリによって示される更新同期タイプを判定する。更新同期タイプがプレースホルダアイテムを示す場合、コンテンツ同期モジュール310は、2320で、共有ジャーナルIDを有するローカルジャーナルエントリに対応するコンテンツアイテムを、共有ネームスペースID及びジャーナルIDのペアを含むプレースホルダアイテムに置き換える。2320でコンテンツアイテムをプレースホルダアイテムへ置き換えると、ローカルファイルジャーナル1400のローカルエントリは、その後、2315で、更新エントリと置き換えられ、当該更新エントリは更新ファイルジャーナル1410から削除される。

0163

[0173]コンテンツ同期モジュール310が2300で、更新同期タイプがコンテンツアイテムを示すと判定する場合、コンテンツ同期モジュール310は、2305で、コンテンツ管理システム110から更新ブロックリストのブロックを要求する。要求したブロックを受信すると、コンテンツ同期モジュール310は、2310で、共有ジャーナルIDを有するローカルジャーナルに対応するプレースホルダアイテムを、要求したブロックから作成されるコンテンツアイテムと置き換える。2320でプレースホルダアイテムをコンテンツアイテムへ置き換えると、ローカルファイルジャーナル1400のローカルエントリは、その後、2315で、更新エントリと置き換えられ、当該更新エントリは更新ファイルジャーナル1410から削除される。

0164

[0174]本発明の実施形態に係る前述の説明は、説明の目的で提示されており;本発明を網羅する又はここで開示される同一の形態に限定することを意図していない。当業者であれば、上記開示に照らして種々の変更及び変形が可能であることを理解することができる。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

この 技術と関連性が強い技術

該当するデータがありません

この 技術と関連性が強い法人

該当するデータがありません

この 技術と関連性が強い人物

該当するデータがありません

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ