JP7075998B2 - クライアント同期サービスのためのリモートツリーの更新 - Google Patents

Description

関連出願の相互参照
本出願は、２０１８年１月５に出願された米国非仮出願第１５／８６３，７５１号、２０１８年１月５日に出願された米国非仮出願第１５／８６３，７４８号、及び２０１７年１２月２８日に出願された米国仮出願第６２／６１１，４７３号に優先権を主張し、これらのすべては、その全体が本明細書に参照により明示的に援用される。

コンテンツ管理システムは、ユーザがネットワークを使用して複数のデバイスにわたりコンテンツアイテムにアクセスし、これらを管理することを可能にする。いくつかのコンテンツ管理システムは、ユーザがコンテンツアイテムを共有することを可能にし、これらのコンテンツアイテムを使用してコラボレーションする際にユーザを支援する追加の特徴を提供することができる。コンテンツ管理システムは、コンテンツアイテムをサーバ上に一般的に格納し、ユーザがネットワーク経由でこれらのコンテンツアイテムにアクセスすることを可能にする。また、いくつかのコンテンツ管理システムは、より自然なインタフェース中のコンテンツアイテム（例えば、ネイティブアプリケーション、またはクライアントデバイスのファイルシステム内の）へのより高速なアクセスをユーザに提供するために、ローカルコピーをクライアントデバイス上に格納することを可能にする。加えて、これにより、ユーザがオフラインであるときに、ユーザがコンテンツアイテムへのアクセスを有することが可能である。コンテンツ管理システムは、複数のクライアントデバイス、及びサーバにわたりコンテンツアイテムのコピーを同期させることを試行するため、各コピーは、同一である。しかしながら、コンテンツアイテムの同期は、困難であり、複数の技術的な障害と関連している。

本技術の上記に列挙されている利点及び特徴、ならびに他の利点及び特徴は、添付の図面に示される具体的な実施態様によって明らかになるであろう。これらの図面は実施例を示すに過ぎず、本技術の範囲をこれらの実施例に限定しないことを当業者は理解するであろう。さらに、当業者は、添付の図面の使用を通じて追加の特殊性及び詳細が記述され、説明される通りに、本技術の原理を理解する。

いくつかの実施形態による、コンテンツ管理システム及びクライアントデバイスの実施例を示す。 いくつかの実施形態による、クライアント同期サービスの実施例を示す。 さまざまな実施形態による、ツリーデータ構造の実施例を示す。 さまざまな実施形態による、ツリーデータ構造の実施例を示す。 本技術のさまざまな実施形態による、ツリーデータ構造を使用してサーバ状態及びファイルシステム状態を同期させる例示的な方法を示す。 本技術のさまざまな実施形態による、ツリーデータ構造を使用してサーバ状態及びファイルシステム状態を同期させるときに競合を解消する例示的な方法を示す。 さまざまな実施形態による、追加操作についてのルール違反を図示するツリーデータ構造の実施例を示す。 本技術のさまざまな実施形態による、サーバ状態及びファイルシステム状態をインクリメンタルに収束させる例示的な方法を示す。 さまざまな実施形態による、ツリーデータ構造の実施例を示す。 例示的なシナリオを示す。 本技術のさまざまな実施形態による、２つの操作プランの例示的なベン図表現を示す。 本技術のさまざまな実施形態による、操作プランにおける変更を管理する例示的な方法を示す。 本技術のさまざまな実施形態による、例示的なシナリオを示す。 本技術のさまざまな実施形態による、ローカルツリーを更新する例示的な方法を示す。 本技術のさまざまな実施形態による、移動またはリネーム操作に応答してローカルツリーを更新する例示的な方法を示す。 さまざまな実施形態による、ツリーデータ構造の実施例を示す。 さまざまな実施形態による、ネームスペースをマウントする概念図を示す。 本技術のさまざま実施形態による、リモートツリーにネームスペースをマウントする例示的な方法を示す。 本技術のさまざま実施形態による、コンテンツ管理システムとクライアントデバイスとの間でコンテンツを同期させる例示的なアーキテクチャの概略図を示す。 本技術のさまざまな実施形態による、コンテンツ管理システムとクライアントデバイスとの間でコンテンツを同期させる例示的なアーキテクチャにおいて、コンテンツアイテムのブロックを格納して追跡するための例示的なコンフィグレーションを示す。 本技術のさまざまな実施形態による、コンテンツ管理システム上でクライアントデバイスとサーバファイルジャーナルとの間でファイルジャーナルインタフェースによって処理される例示的な通信の図を示す。 本技術のさまざまな実施形態による、コンテンツ管理システム上でクライアントデバイスとサーバファイルジャーナルとの間で通信を変換するための例示的なプロセスの図を示す。 本技術のさまざまな実施形態による、サーバファイルジャーナルデータを線形化された操作に変換するための例示的な変換及び線形化プロセスの図を示す。 本技術のさまざまな実施形態による、クライアントデバイスからの操作をサーバファイルジャーナルについてのリビジョンに変換するための例示的な変換及び線形化プロセスの図を示す。 コンテンツ管理システム上のサーバファイルジャーナルからのリビジョンをクライアントデバイスについての操作に変換する例示的な方法を示す。 本技術のさまざまな実施形態による、ネームスペース間操作の例示的な線形化を示す。 本技術のさまざまな実施形態による、イベントのために計算されるランポートクロックによって順序付けされるネームスペースにわたるイベントの図を示す。 本技術のある特定の態様を実装するためのシステムの実施例を示す。

本技術のさまざまな実施例は、以下に詳細に考察される。具体的な実施態様を考察するが、これが例示目的のみのために行われていることを理解するであろう。当業者は、本技術の趣旨及び範囲から逸脱することなく他の構成要素及び構成を使用することができることを認識するであろう。

コンピューティング及びネットワーキング技術におけるさまざまな進歩により、コンテンツ管理システムが複数のデバイスにわたるコンテンツアイテムへのアクセスをユーザに提供することが可能である。これらのコンテンツアイテムは、ファイル、ドキュメント、メッセージ（例えば、電子メールメッセージまたはテキストメッセージ）、メディアファイル（例えば、写真、ビデオ、及びオーディオファイル）、複数のファイルを有するフォルダ、またはいずれかの他のコンテンツユニットを含むことができるが、これらに限定されない。コンテンツアイテムは、複数のユーザと共有される、編集される、削除される、追加される、リネームされる、または移動し得る。しかしながら、いくつかのコンピューティングデバイス（例えば、サーバ及びクライアントデバイス）にわたり、そしていくつかのユーザアカウントにわたり、これらのコンテンツアイテムを同期させることにより、不具合が残り、技術的な障害が広まっている。

技術的な障害の一部を図示するよう、第一マシン（例えば、クライアントデバイスまたはサーバ）は、ユーザがコンテンツ管理システムによって管理されるコンテンツアイテムを修正した方法についての情報を提供する通信を、第二マシンに送信することができる。第一マシン上のコンテンツアイテムに実行されるアクションが第二マシンのコンテンツアイテムに反映され、第一マシン上のコンテンツアイテムが第二マシン上のコンテンツアイテムと実質的に同一であるように、これらの通信を第二マシンが使用して、コンテンツアイテムを第二マシン上で同期させることができる。

しかしながら、送信されるいくつかの通信があり得、これらの通信を送信するために使用される１つ以上のネットワーク、第一もしくは第二マシンの技術的な操作、またはいくつかの他の理由によって使用される、さまざまなネットワークルーティングプロトコルの結果として、これらの通信を順不同に受信する場合がある。さらに、ユーザは、多数の修正を多数のコンテンツアイテムに実行して、以前の修正を短時間に取り消す、または追加の修正を以前に修正されたコンテンツアイテム、もしくはコンテンツアイテムのセットに迅速に実行する場合がある。これは、これらの通信が順不同に受信される、ある特定の通信が古い、または第二マシンが最新ではないコンテンツアイテム上で操作を実行する尤度を増加させる。結果として、多くの操作は、コンテンツアイテムの現在の状態と互換性がない場合がある。実際に、いくつかの操作が他の操作と、またはコンテンツアイテムの現在の状態と競合しているかどうかを検出することさえ困難である可能性がある。

加えて、同期アクションに関して固有のレイテンシがある。例えば、第一マシン上で行われるこれらのアクションを第一マシンが最初に検出し、通信を生成した後に、ネットワークを介して送信する。以前の通信をまだ処理している可能性がある第二マシンが通信を受信して、処理し、通信に詳述されるアクションを第二マシンにおいて行う可能性がある。この例示的なシナリオにおいて、第一マシン、第二マシン、及びネットワークの限られたコンピューティングリソース（例えば、帯域幅、メモリ、処理時間、処理サイクルなど）によってレイテンシがもたらされる、いくつかのポイントがある。レイテンシが増加すると、通信が何らかの理由でコンテンツアイテムの現在の状態と競合する尤度も増加する。さらに、これらの競合した通信を処理して、そのうえ競合を解消することにより、処理時間、メモリ、エネルギー、または帯域幅などのコンピューティングリソースを不必要に消費し、さらにレイテンシを増加させる。

事態をさらに複雑にするように、第二マシン、及び／またはコンテンツアイテムへのアクセスを有する追加のマシン上の同一の、または異なるユーザも、コンテンツアイテムへの修正を実行している場合がある。結果として、上記の問題が増幅する可能性があり、ローカルアクションがリモートアクションと競合するかどうか、及び／またはローカルアクションが最新のコンテンツアイテム上で動作しているかどうかについて、さらなる技術的な問題が発生する。

開示された技術は、上記の、及び他の技術的な問題への技術的な解決策を提供するコンテンツ管理システム対するクライアント同期サービスについての当該技術における必要性に対処する。クライアント同期サービスは、クライアントデバイス上で動作し、コンテンツ管理システムのサーバ上のコンテンツアイテムと、クライアントデバイス上の対応するコンテンツアイテムとの間の同期ミスマッチを識別するように設定されることができる。各同期ミスマッチについて、クライアント同期サービスは、コンテンツアイテムを同期させ、これらの操作を開始するために必要とされる操作を識別することができる。

クライアント同期サービスは、サーバ上でのコンテンツアイテムのステータス、クライアントデバイス上でのコンテンツアイテムのステータス、及び１セットのツリーデータ構造（「ツリー」）を使用するそれらの同期状態を追跡することができる。いくつかの実施形態により、３つのツリーの１セットを使用することができる。これらの３つのツリーは、サーバ状態を表すリモートツリー、クライアントデバイス上でのファイルシステム状態を表すローカルツリー、ならびにこれらのローカルツリー及びリモートツリーについてマージベースを表す同期ツリーを含むことができる。マージベースは、ローカルツリー及びリモートツリーの共通祖先、またはローカルツリーとリモートツリーとの間の最後の既知の同期状態と考えられることができる。その結果、クライアント同期サービスは、３つのツリー（例えば、リモートツリー、同期ツリー、及びローカルツリー）すべてが同一であるときに、サーバ状態及びクライアントデバイス状態が同期すると判定することができる。

コンテンツアイテムのサーバ状態、またはコンテンツアイテムのクライアントデバイスファイルシステム状態（「ファイルシステム状態」）への修正を検出するときに、クライアント同期サービスは、適切なツリーを更新し、サーバ状態及びファイルシステム状態がツリーの３つの組に基づき同期しているかどうかを判定する。これらのツリーのうちの１つへの更新に基づき、サーバ状態及びファイルシステム状態は、同期するようになる、同期しないようになる、またはさらに同期しないようになる場合がある。サーバ状態及びファイルシステム状態が同期していない場合に、クライアント同期サービスは、サーバ状態及びファイルシステム状態を収束させ、サーバ状態及びファイルシステム状態が同期した状態にさらに近くなるために必要とされる最初の少なくとも１つの操作セットを識別することができる。

サーバ状態及びファイルシステム状態を監視するためにツリーデータ構造のセットに依存することによって、コンピューティング技術に根付いている代替物及び／または解決策をさまざまな技術的な問題に提供する。例えば、クライアント同期サービスは、サーバ状態及びファイル状態を追跡し、これら２つの状態のマージベースの表現を格納することができる。結果として、本技術のさまざまな実施形態は、ユーザがリモートにコンテンツアイテムを修正している方法を特定する複数の通信を受信することと関連する技術的な問題、ならびにこれらの修正がローカルに実装されるのはどの順序か、修正が他の修正と競合するか、古いかどうか、及びリモート修正がユーザによってローカルに実行されるローカル修正と競合するかどうかを判定する技術的な問題を回避する。関連するさまざまなアクター（例えば、サーバ及びクライアントデバイス）の状態を追跡することができないという、そしてこれらの状態が同期しているかどうかを迅速に判定することができないという、これらの問題の多くは、他の解決策から発生する。代替に、これらの他の解決策は、サーバ状態及びファイルシステム状態が同期しているかどうかのコンテキストなしで、ローカルにコンテンツアイテムを修正する方法についての命令を受信することに依存している。

さらに、サーバ状態及びファイルシステム状態が連続して監視されていることから、それらが同期しているかどうかを判定することは、プロシージャの複雑さ、ならびに計算時間及びリソースの点からさらにより効率的である。以下にさらに詳細に説明されているように、クライアント同期サービスは、さらに決定論的な方式におけるサーバ状態及びファイルシステム状態のインクリメンタルな、また系統的な同期を可能にする。結果として、コンテンツ管理システムの特徴のスケーリング及びテストも、さらに効率的になる。

コンテンツ管理システム
いくつかの実施形態において、開示されている科学技術は、とりわけ、コンテンツアイテム同期機能及びコラボレーション特徴を有するコンテンツ管理システムのコンテキストに展開される。例示的なシステムコンフィグレーション１００は、クライアントデバイス１５０とインタラクトするコンテンツ管理システム１１０を描く、図１Ａに示される。

アカウント
コンテンツ管理システム１１０は、アカウントと関連するコンテンツアイテムを格納し、コンテンツアイテム（複数可）を取得する、修正する、閲覧する、及び／または共有するなどの、さまざまなコンテンツアイテム管理タスクを実行することができる。さらに、コンテンツ管理システム１１０は、アカウントが複数のクライアントデバイスからコンテンツアイテム（複数可）にアクセスすることを可能にすることができる。

コンテンツ管理システム１１０は、複数のアカウントをサポートする。エンティティ（ユーザ、ユーザグループ、チーム、会社など）は、コンテンツ管理システムによってアカウントを作成することができ、アカウント詳細は、アカウントデータベース１４０に格納されることができる。アカウントデータベース１４０は、登録されたエンティティについてのプロファイル情報を格納することができる。いくつかの事例において、登録されたエンティティについてのプロファイル情報は、ユーザ名及び／または電子メールアドレスを含む。アカウントデータベース１４０は、アカウントタイプ（例えば、無料のアカウント、または有料のアカウントのさまざまなティア）、割り振られるストレージスペース、使用されるストレージスペース、それらの上に常駐する登録されたコンテンツ管理クライアントアプリケーション１５２を含むクライアントデバイス１５０、セキュリティ設定、パーソナルコンフィグレーション設定などのような、アカウント管理情報を含むことができる。

アカウントデータベース１４０は、エンティティと関連するアカウントグループを格納することができる。グループは、グループポリシー及び／またはアクセス制御リストに基づくパーミッションを有することができ、これらのグループのメンバーは、これらのパーミッションを継承することができる。例えば、マーケティンググループは、１セットのコンテンツアイテムへのアクセスを有することができ、エンジニアリンググループは、別の１セットのコンテンツアイテムへのアクセスを有することができる。管理者グループは、グループを修正すること、ユーザアカウントを修正することなどができる。

コンテンツアイテムストレージ
コンテンツ管理システム１１０の特徴は、コンテンツストレージ１４２に格納されることができる、コンテンツアイテムのストレージである。コンテンツアイテムは、ドキュメント、コラボレーションコンテンツアイテム、テキストファイル、オーディオファイル、画像ファイル、ビデオファイル、ウェブページ、実行可能ファイル、バイナリファイルなどのような、いずれかのデジタルデータであり得る。また、コンテンツアイテムは、フォルダ、ｚｉｐファイル、プレイリスト、アルバムなどのような、異なるビヘイビアと共にコンテンツアイテムをグループ化するためのコレクションまたは他のメカニズムを含むことができる。コレクションは、フォルダ、または共通属性によって関連する、またはグループ化される複数のコンテンツアイテムを指すことができる。いくつかの実施形態において、コンテンツストレージ１４２を他のタイプのストレージまたはデータベースと組み合わせ、特定の機能をハンドリングする。コンテンツストレージ１４２は、コンテンツアイテムを格納し、これらのコンテンツアイテムについてのメタデータは、メタデータデータベース１４６に格納されることができる。同様に、コンテンツアイテムをコンテンツストレージ１４２に格納する位置についてのデータを、コンテンツディレクトリ１４４に格納することができる。加えて、変更、アクセスなどについてのデータをサーバファイルジャーナル１４８に格納することができる。コンテンツストレージ１４２、コンテンツディレクトリ１４４、サーバファイルジャーナル１４８、及びメタデータデータベース１４６のような、さまざまなストレージ／データベースのそれぞれは、１つより多いこれらのようなストレージまたはデータベースから構成されることができ、多くのデバイス及び位置上に分散されることができる。他のコンフィグレーションも可能である。例えば、コンテンツストレージ１４２、コンテンツディレクトリ１４４、サーバファイルジャーナル１４８、及び／またはメタデータデータベース１４６からのデータは、１つまたは複数のコンテンツストレージもしくはデータベースに統合される、または追加のコンテンツストレージもしくはデータベースにさらにセグメント化されることができる。したがって、コンテンツ管理システム１１０は、図１に示されるものより多い、または少ないストレージ及び／またはデータベースを含むことができる。

いくつかの実施形態において、コンテンツストレージ１４２は、少なくとも１つのコンテンツストレージサービス１１６と関連付けられ、少なくとも１つのコンテンツストレージサービスは、ストレージ用のコンテンツアイテムを受信すること、ストレージ用のコンテンツアイテムを準備すること、コンテンツアイテム用のストレージ位置を選択すること、コンテンツアイテムをストレージから取得することなどを含むが、これらに限定されない、コンテンツアイテムのストレージを管理するために、ソフトウェアまたは他のプロセッサ実行可能命令を含む。いくつかの実施形態において、コンテンツストレージサービス１１６は、コンテンツストレージ１４２におけるストレージのために、コンテンツアイテムをより小さなチャンクに分割することができる。コンテンツアイテムを構成する各チャンクの位置をコンテンツディレクトリ１４４に記録することができる。コンテンツディレクトリ１４４は、コンテンツストレージ１４２に格納される各コンテンツアイテムについてのコンテンツエントリを含むことができる。コンテンツエントリは、コンテンツアイテムを識別する、一意のＩＤと関連付けられることができる。

いくつかの実施形態において、一意のＩＤは、コンテンツディレクトリ１４４中のコンテンツアイテムを識別するが、確定的ハッシュ関数から導出されることができる。コンテンツアイテムに対して一意のＩＤを導出するこの方法は、確定的ハッシュ関数が同一のコンテンツアイテムのすべてのコピーに対して同じ識別子を出力するが、異なるコンテンツアイテムに対して異なる識別子を出力することなどから、コンテンツアイテム重複を認識することを確保することができる。この方法論を使用して、コンテンツストレージサービス１１６は、各コンテンツアイテムに対して一意のＩＤを出力することができる。

また、コンテンツストレージサービス１１６は、メタデータデータベース１４６中のコンテンツアイテムについてのコンテンツパスを指定する、または記録することができる。コンテンツパスは、コンテンツアイテム及び／またはこのコンテンツアイテムと関連するフォルダ階層の名前を含むことができる。例えば、コンテンツパスは、コンテンツアイテムをクライアントデバイス上のローカルファイルシステムに格納するフォルダ、またはフォルダのパスを含むことができる。コンテンツアイテムをブロック中のコンテンツストレージ１４２に格納し、ディレクトリ構造のようなツリー下に格納しなくてもよいが、このようなディレクトリ構造は、ユーザにとって快適なナビゲーション構造である。コンテンツストレージサービス１１６は、ディレクトリ構造の「ルート」ノードが各アカウントについてのネームスペースであることができる、コンテンツアイテムについてのコンテンツパスを定義する、または記録することができる。ネームスペース内には、アカウント及び／またはコンテンツストレージサービス１１６のユーザによって定義されるディレクトリ構造があることができる。メタデータデータベース１４６は、各コンテンツアイテムについてのコンテンツパスをコンテンツエントリの部分として格納することができる。

いくつかの実施形態において、ネームスペースは、それらがルートノード内に格納されるかのようにディレクトリ構造にネストされる追加のネームスペースを含むことができる。これは、アカウントが共有されたコレクションへのアクセスを有するときに起こり得る。共有されたコレクションは、それら自体のネームスペースをコンテンツ管理システム１１０内に割り当てられ得る。いくつかの共有されたコレクションは、実際には共有されたコレクションについてのルートノードであるが、それらは、ディレクトリ構造中のアカウントネームスペースの下位に位置し、アカウント用のフォルダ内のフォルダとして出現することができる。上述されるように、ディレクトリ構造は、ユーザにとって単に快適なナビゲーション構造であるが、コンテンツストレージ１４２中のコンテンツアイテムのストレージ位置に相関しない。

アカウントがコンテンツアイテムを表示するディレクトリ構造は、コンテンツ管理システム１１０においてストレージ位置に相関しないが、ディレクトリ構造は、クライアントデバイス１５０によって使用されるファイルシステムに依存するクライアントデバイス１５０上のストレージ位置に相関することができる。

上述されるように、コンテンツディレクトリ１４４中のコンテンツエントリは、コンテンツアイテムを構成する各チャンクの位置をも含むことができる。より具体的に、コンテンツエントリは、コンテンツアイテムを構成するチャンクのコンテンツストレージ１４２中の位置を識別するコンテンツポインタを含むことができる。

コンテンツパス及びコンテンツポインタに加えて、コンテンツディレクトリ１４４中のコンテンツエントリは、コンテンツアイテムへのアクセスを有するユーザアカウントを識別するユーザアカウント識別子、及び／またはコンテンツアイテムへのアクセスを有するグループを識別するグループ識別子、及び／またはコンテンツエントリが属するネームスペースをも含むことができる。

コンテンツストレージサービス１１６は、コンテンツアイテム、またはコンテンツアイテムのバージョンを構成する、重複するコンテンツアイテム、または重複するブロックを識別することによってストレージスペースの所要量を減少させることができる。複数のコピーを格納する代替に、コンテンツストレージ１４２は、コンテンツアイテムの、またはコンテンツアイテムのブロックの、単一コピーを格納することができ、コンテンツディレクトリ１４４は、重複を単一コピーにリンクさせる、ポインタまたは他のメカニズムを含むことができる。

また、コンテンツストレージサービス１１６は、コンテンツアイテムの一意のＩＤと関連して、コンテンツアイテム、コンテンツアイテムタイプ、フォルダ、ファイルパス、及び／またはメタデータデータベース１４６中のさまざまなアカウント、コレクション、またはグループへのコンテンツアイテムの関係を記述するメタデータを格納することができる。

また、コンテンツストレージサービス１１６は、サーバファイルジャーナル１４８中の変更、アクセスなどについてのデータのログを格納することができる。サーバファイルジャーナル１４８は、タイムスタンプまたはバージョン番号及びいずれかの他の関連データに加えて、コンテンツアイテムの一意のＩＤ、及び変更またはアクセスアクションのディスクリプションを含むことができる。また、サーバファイルジャーナル１４８は、変更またはコンテンツアイテムアクセスによって影響されるブロックへのポインタを含むことができる。コンテンツストレージサービスは、コンテンツアイテムへの変更を追跡するコンテンツアイテムバージョン制御、コンテンツアイテムの異なるバージョン（分岐するバージョンツリーを含む）、及びサーバファイルジャーナル１４８から取得されることができる変更履歴を使用することによって、操作をアンドゥする機能を提供することができる。

コンテンツアイテム同期
コンテンツ管理システム１１０の別の特徴は、コンテンツアイテムの少なくとも１つのクライアントデバイス１５０との同期である。クライアントデバイス（複数可）は、異なる形を取り、異なる機能を有することができる。例えば、クライアントデバイス１５０１は、複数のアプリケーションによってアクセス可能な、それらの上に常駐するローカルファイルシステムを含むコンピューティングデバイスである。クライアントデバイス１５０２は、コンピューティングデバイスであり、そこでコンテンツアイテムは、特定のアプリケーションに、または特定のアプリケーションにより与えられるパーミッションによってのみアクセス可能であり、コンテンツアイテムは、典型的に、特定用途向けスペースか、クラウドかのいずれか一方に格納される。クライアントデバイス１５０３は、ウェブブラウザを介してコンテンツ管理システム１１０にアクセスし、またウェブインタフェースを介してコンテンツアイテムにアクセスする、いずれかのクライアントデバイスである。例示的なクライアントデバイス１５０１、１５０２、及び１５０３は、ラップトップ、モバイルデバイス、またはウェブブラウザなどのフォームファクタで描かれ、それらの記述がこれらの例示的なフォームファクタのデバイスに限定されないことを理解するであろう。例えば、クライアント１５０２などのモバイルデバイスは、複数のアプリケーションによってアクセス可能な、それらの上に常駐するローカルファイルシステムを含むことができる、またはクライアント１５０２は、ウェブブラウザを介してコンテンツ管理システム１１０にアクセスすることができる。このように、フォームファクタは、クライアント１５０の機能を考慮するときに制限するものとみなされるべきではない。クライアントデバイス１５０に関して本明細書に記述される１つ以上の機能は、デバイスの特定の機能（ファイルアクセスモデルがこのような機能の１つである）に依存するすべてのクライアントデバイス上で利用可能であってもよいし、利用可能でなくてもよい。

多くの実施形態において、クライアントデバイスは、コンテンツ管理システム１１０のアカウントと関連付けられるが、いくつかの実施形態において、クライアントデバイスは、共有されたリンクを使用してコンテンツにアクセスし得、アカウントを必要としないことがある。

上述されるように、いくつかのクライアントデバイスは、ウェブブラウザを使用してコンテンツ管理システム１１０にアクセスすることができる。しかしながら、クライアントデバイスは、クライアントデバイス１５０上で格納され、実行するクライアントアプリケーション１５２を使用して、コンテンツ管理システム１１０にもアクセスすることができる。クライアントアプリケーション１５２は、クライアント同期サービス１５６を含むことができる。

クライアント同期サービス１５６は、サーバ同期サービス１１２と通信し、クライアントデバイス１５０とコンテンツ管理システム１１０との間でコンテンツアイテムへの変更を同期させることができる。

クライアントデバイス１５０は、クライアント同期サービス１５６を介してコンテンツをコンテンツ管理システム１１０と同期させることができる。同期は、プラットフォームに依存しないことができる。すなわち、コンテンツは、さまざまなタイプ、機能、オペレーティングシステムなどの複数のクライアントデバイスにわたり同期することができる。クライアント同期サービス１５６は、クライアントデバイス１５０のファイルシステムの指定の位置におけるコンテンツアイテムへのいかなる変更（新規の、削除された、修正された、コピーされた、または移動されたコンテンツアイテム）をも同期させることができる。

コンテンツアイテムをクライアントデバイス１５０からコンテンツ管理システム１１０に同期させることができ、またその逆もできる。クライアントデバイス１５０からコンテンツ管理システム１１０への同期である実施形態において、ユーザは、クライアントデバイス１５０のファイルシステムから直接コンテンツアイテムを操作することができるが、クライアント同期サービス１５６は、監視されたフォルダ内のファイルへの変更についてディレクトリをクライアントデバイス１５０上で監視することができる。

クライアント同期サービス１５６が監視するディレクトリ中のコンテンツの書き込み、移動、コピー、または削除を検出するときに、クライアント同期サービス１５６は、コンテンツ管理システムサービス１１６への変更を同期させることができる。いくつかの実施形態において、クライアント同期サービス１５６は、コンテンツアイテムをブロックに分割すること、コンテンツアイテムをハッシュ化して一意の識別子を生成することなどのような上述される機能を有するコンテンツ管理システムサービス１１６のいくつかの機能を実行することができる。クライアント同期サービス１５６は、クライアントストレージインデックス１６４内でコンテンツをインデックス化し、結果をストレージインデックス１６４に保存することができる。インデックス化は、各コンテンツアイテムについての、パスと一意のサーバ識別子、及び一意のクライアント識別子を格納することを備えることができる。いくつかの実施形態において、クライアント同期サービス１５６は、一意のサーバ識別子をサーバ同期サービス１１２から学習し、一意のクライアント識別子をクライアントデバイス１５０のオペレーティングシステムから学習する。

クライアント同期サービス１５６は、ストレージインデックス１６４を使用して、コンテンツ管理システム１１０上のユーザアカウントと関連するコンテンツとの、クライアントストレージ内のコンテンツの少なくとも一部分の同期を容易にすることができる。例えば、クライアント同期サービス１５６は、ストレージインデックス１６４をコンテンツ管理システム１１０と比較し、クライアントストレージ上のコンテンツと、コンテンツ管理システム１１０上のユーザアカウントと関連するコンテンツとの間の差異を検出することができる。次いで、クライアント同期サービス１５６は、必要に応じてコンテンツをクライアントストレージ上で、アップロードし、ダウンロードし、修正し、そして削除することによって、差異のリコンサイルを試行することができる。コンテンツストレージサービス１１６は、必要に応じて、コンテンツアイテムについて変更されたブロック、または新規のブロックを格納し、サーバファイルジャーナル１４８、メタデータデータベース１４６、コンテンツディレクトリ１４４、コンテンツストレージ１４２、アカウントデータベース１４０などを更新することができる。

コンテンツ管理システム１１０からクライアントデバイス１５０に同期させるときに、サーバファイルジャーナル１４８に記録されるコンテンツアイテムのマウント、修正、追加、削除、移動は、通知サービス１１７を使用してクライアントデバイス１５０に送信される通知をトリガすることができる。クライアントデバイス１５０に変更を通知するときに、クライアントデバイスに知られている最後の同期ポイント以降に、サーバファイルジャーナル１４８に列挙されている要求を変更する。クライアントデバイス１５０がコンテンツ管理システム１１０と同期していないと判定するときに、クライアント同期サービス１５６は、変更を含むコンテンツアイテムブロックを要求し、変更されたコンテンツアイテムのそのローカルコピーを更新する。

いくつかの実施形態において、ストレージインデックス１６４は、ツリーデータ構造を格納し、そこで１つのツリーは、サーバ同期サービス１１２に従いディレクトリの最新の表現を反映し、もう１つのツリーは、クライアント同期サービス１５６に従いディレクトリの最新の表現を反映する。クライアント同期サービスは、データをサーバ同期サービス１１２から要求することによって、またはクライアントデバイス１５０上の変更をコンテンツ管理システム１１０にコミットすることによって、ツリー構造がマッチングすることを確保するように機能することができる。

ときとして、クライアントデバイス１５０は、利用可能なネットワーク接続を有さない場合がある。このシナリオにおいて、クライアント同期サービス１５６は、ネットワーク接続が利用可能であるときに、コンテンツアイテム変更についてリンクされたコレクションを監視し、後のコンテンツ管理システム１１０への同期のためにこれらの変更をキューイングすることができる。同様に、ユーザは、コンテンツ管理システム１１０との同期を手動で、開始する、停止する、一時停止する、または再開することができる。

クライアント同期サービス１５６は、特定のユーザアカウントと関連するすべてのコンテンツをコンテンツ管理システム１１０上で同期させることができる。代替的に、クライアント同期サービス１５６は、特定のユーザアカウントと関連する全コンテンツの一部のコンテンツをコンテンツ管理システム１１０上で選択的に同期させることができる。一部のコンテンツのみを選択的に同期させることにより、スペースをクライアントデバイス１５０上に保持し、帯域幅を節約することができる。

いくつかの実施形態において、クライアント同期サービス１５６は、コンテンツのリマインダ部分のためにクライアントストレージに、特定のユーザアカウントと関連するコンテンツの一部を選択的に格納し、プレースホルダコンテンツアイテムを格納する。例えば、クライアント同期サービス１５６は、プレースホルダコンテンツアイテムを格納することができ、このプレースホルダコンテンツアイテムは、コンテンツ管理システム１１０上の、そのそれぞれの完全なコンテンツアイテムの同じファイル名、パス、拡張子、メタデータを有するが、完全なコンテンツアイテムのデータを欠く。このプレースホルダコンテンツアイテムは、サイズが数バイト以下であることができるが、それぞれの完全なコンテンツアイテムは、著しくより大きくてもよい。クライアントデバイス１５０がコンテンツアイテムにアクセスすることを試行した後に、クライアント同期サービス１５６は、コンテンツアイテムのデータをコンテンツ管理システム１１０から取得し、完全なコンテンツアイテムを、アクセスするクライアントデバイス１５０に提供することができる。このアプローチは、有意なスペース、及び帯域幅節約を提供しながら、ユーザのコンテンツへのフルアクセスをコンテンツ管理システム１１０上に依然として提供することができる。

コラボレーション特徴
コンテンツ管理システム１１０の別の特徴は、ユーザ間のコラボレーションを容易にすることである。コラボレーション特徴は、コンテンツアイテムの共有、コンテンツアイテムについてのコメント、コンテンツアイテム上でのコワーキング、インスタントメッセージング、コンテンツアイテムについての存在及び表示状態情報を提供することなどを備える。

共有
コンテンツ管理システム１１０は、共有サービス１２８を介して共有コンテンツを管理することができる。コンテンツへのリンクを提供することによって共有するコンテンツは、コンテンツ管理システム１１０とネットワーク通信しているいずれかのコンピューティングデバイスからアクセス可能なコンテンツアイテムを作成することを含むことができる。しかしながら、いくつかの実施形態において、リンクは、コンテンツ管理システム１１０及びアクセス制御リスト１４５によって実施されるアクセス制限と関連付けられることができる。また、共有コンテンツは、共有サービス１２８を使用してコンテンツにリンクし、コンテンツ管理システム１１０内のコンテンツを少なくとも１つの追加のユーザアカウント（コンテンツアイテムと関連する元のユーザアカウントに加えて）と共有することを含むことができるので、各ユーザアカウントは、コンテンツアイテムへのアクセスを有する。追加のユーザアカウントは、コンテンツを許容することによってコンテンツへのアクセスを得ることができ、その後、ウェブインタフェースサービス１２４を介してか、直接にかのいずれか一方で、クライアントデバイス１５０上でそれらのアカウントと関連するディレクトリ構造内からアクセス可能である。プラットフォームに依存しない方式において、共有を実行することができる。すなわち、さまざまなタイプ、機能、オペレーティングシステムなどの複数のクライアントデバイス１５０にわたりコンテンツを共有することができる。また、ユーザアカウントのさまざまなタイプにわたりコンテンツを共有することができる。

コンテンツアイテムをコンテンツ管理システム１１０内で共有するために、共有サービス１２８は、１つのユーザアカウント識別子、または複数のユーザアカウント識別子を、コンテンツアイテムと関連するアクセス制御リストデータベース１４５中のコンテンツエントリに追加することができるので、コンテンツアイテムへの追加されたユーザアカウントアクセスを付与することができる。また、共有サービス１２８は、ユーザアカウント識別子をコンテンツエントリから除去し、コンテンツアイテムへのユーザアカウントのアクセスを制限することができる。共有サービス１２８は、コンテンツアイテム識別子、コンテンツアイテムへのアクセスを与えられるユーザアカウント識別子、及びアクセス制御リストデータベース１４５におけるアクセスレベルを記録することができる。例えば、いくつかの実施形態において、単一コンテンツエントリと関連するユーザアカウント識別子は、関連したコンテンツアイテムに関するそれぞれのユーザアカウント識別子に対して異なるパーミッションを指定することができる。

コンテンツ管理システム１１０の外部でコンテンツアイテムを共有するために、共有サービス１２８は、ユニフォームリソースロケータ（ＵＲＬ）などのカスタムネットワークアドレスを生成することができ、このカスタムネットワークアドレスにより、いかなる認証もなく、コンテンツ管理システム１１０においてコンテンツアイテムまたはコレクションにいかなるウェブブラウザもアクセスすることが可能である。これを達成するために、共有サービス１２８は、コンテンツ識別データを生成されたＵＲＬに含むことができ、このコンテンツ識別データを後に使用して、要求されたコンテンツアイテムを適切に識別し、返すことができる。例えば、共有サービス１２８は、アカウント識別子及びコンテンツパス、または生成されたＵＲＬ中でコードを識別するコンテンツアイテムを含むことができる。ＵＲＬの選択に際し、ＵＲＬに含まれるコンテンツ識別データをコンテンツ管理システム１１０に送信することができ、このコンテンツ管理システム１１０は、受信したコンテンツ識別データを使用して、適切なコンテンツアイテムを識別し、コンテンツアイテムを返すことができる。

ＵＲＬを生成することに加えて、共有サービス１２８は、コンテンツアイテムへのＵＲＬが作成されているアクセス制御リストデータベース１４５に記録されるように設定されることもできる。いくつかの実施形態において、コンテンツアイテムと関連するコンテンツエントリは、コンテンツアイテムへのＵＲＬが作成されているかどうかを示すＵＲＬフラグを含むことができる。例えば、ＵＲＬフラグは、コンテンツアイテムへのＵＲＬが作成されていないことを示す、０または偽に最初に設定されるブール値であり得る。共有サービス１２８は、コンテンツアイテムへのＵＲＬを生成した後に、フラグの値を１または真に変更することができる。

いくつかの実施形態において、共有サービス１２８は、１セットのパーミッションをコンテンツアイテムについてのＵＲＬに関連付けることができる。例えば、ユーザがＵＲＬを介してコンテンツアイテムにアクセスすることを試行する場合に、共有サービス１２８は、コンテンツアイテムに対して制限された１セットのパーミッションを提供することができる。制限されたパーミッションの実施例は、ユーザがコンテンツアイテムをダウンロードすることができない、コンテンツアイテムを保存することができない、コンテンツアイテムをコピーすることができない、コンテンツアイテムを修正することができないなどの制限を有する。いくつかの実施形態において、制限されたパーミッションは、特定のドメインから、すなわち、企業ネットワークドメイン内部から、または特定のドメインと関連するアカウント、例えば、企業アカウントと関連するアカウント（例えば、＠ａｃｍｅ．ｃｏｍ）によって、アクセスされるコンテンツアイテムだけにパーミッションを与える制限を含む。

いくつかの実施形態において、共有サービス１２８も、生成されたＵＲＬを非アクティブ化するように構成されることができる。例えば、各コンテンツエントリも、生成されたＵＲＬからの要求に応答してコンテンツを返すべきかどうかを示す、ＵＲＬアクティブフラグを含むことができる。例えば、ＵＲＬアクティブフラグが１または真に設定される場合に、共有サービス１２８は、生成されたリンクによって要求されるコンテンツアイテムのみを返すことができる。したがって、ＵＲＬが生成されているコンテンツアイテムへのアクセスは、ＵＲＬアクティブフラグの値を変更することによって容易に制限され得る。これにより、コンテンツアイテムを移動させる、または生成されたＵＲＬを削除することを必要とせずに、ユーザが共有されたコンテンツアイテムへのアクセスを制限することができる。同様に、共有サービス１２８は、ＵＲＬアクティブフラグの値を１または真に再度変更することによって、ＵＲＬを再アクティブ化することができる。したがって、ユーザは、新規のＵＲＬを生成する必要なく、コンテンツアイテムへのアクセスを容易に復元することができる。

いくつかの実施形態において、コンテンツ管理システム１１０は、コンテンツアイテムをアップロードするためにＵＲＬを指定することができる。例えば、ユーザアカウントを有する第一ユーザは、このようなＵＲＬを要求し、ＵＲＬを寄与するユーザに提供することができ、寄与するユーザは、このＵＲＬを使用して、コンテンツアイテムを第一ユーザのユーザアカウントにアップロードすることができる。

チームサービス
いくつかの実施形態において、コンテンツ管理システム１１０は、チームサービス１３０を含む。チームサービス１３０は、ユーザアカウントの定義されたチームを作成し、管理するための機能性を提供することができる。これらのチームは、サブチーム（例えば、ビジネスユニット、またはプロジェクトチームなど）とともに、企業用に作成されることができ、これらのチーム及びサブチームに、またはこれらのチームに割り当てられるユーザアカウントは、ユーザアカウントのいずれかの定義されたグループ用に作成され得る。これらのチームサービス１３０は、チーム用の共通の共有スペース、プライベートユーザアカウントフォルダ、及びアクセス制限された共有フォルダを提供することができる。また、チームのサービスは、管理者用に管理インタフェースを提供し、コレクション及びコンテンツアイテムをチーム内で管理することができ、このチームと関連付けられるユーザアカウントを管理することができる。

認可サービス
いくつかの実施形態において、コンテンツ管理システム１１０は、認可サービス１３２を含む。認可サービス１３２は、ネームスペースにアクセスすることを試行するユーザアカウントがネームスペースにアクセスする適切な権限を有することを確保する。認可サービス１３２は、ネームスペースにアクセスする要求に従うトークンをクライアントアプリケーション１５２から受信することができ、ユーザアカウントにパーミッションを与えられている機能を返すことができる。複数のアクセスレベルを有するユーザアカウント（例えば、ユーザ権限及び管理者権限を有するユーザアカウント）について、認可サービス１３２は、管理者による意図しないアクションを回避するために、明示的な特権昇格をも要求することができる。

存在及び表示状態
いくつかの実施形態において、コンテンツ管理システムは、コンテンツアイテムを共有するユーザがどのようにコンテンツアイテムとインタラクトしている、またはインタラクトしていたかについての情報を提供することができる。いくつかの実施形態において、コンテンツ管理システム１１０は、コンテンツアイテムを共有するユーザがコンテンツアイテムを現在閲覧していることを報告することができる。例えば、クライアントデバイス１５０がコンテンツアイテムにアクセスしているときに、クライアントコラボレーションサービス１６０は、通知サービス１１７に通知することができる。次いで、通知サービス１１７は、このコンテンツアイテムに関してクライアントデバイス１５０のユーザの存在する同一コンテンツアイテムへのアクセスを有する他のユーザのすべてのクライアントデバイスに通知することができる。

いくつかの実施形態において、コンテンツ管理システム１１０は、共有されたコンテンツアイテムとのユーザインタラクションの履歴を報告することができる。コラボレーションサービス１２６は、メタデータデータベース１４６及びサーバファイルジャーナル１４８などのデータソースにクエリを行い、ユーザがコンテンツアイテムを保存していること、ユーザがまだコンテンツアイテムを閲覧していることなどを判定し、通知サービス１１７を使用して、この状態情報を他のユーザに広めることができるので、それらのユーザは、コンテンツアイテムを現在閲覧している、または現在修正している、または閲覧していた、または修正したユーザを知ることができる。

コラボレーションサービス１２６は、コンテンツアイテムがコメント機能をネイティブにサポートしない場合でも、コンテンツと関連するコメントを容易にすることができる。これらのようなコメントをメタデータデータベース１４６に格納することができる。

コラボレーションサービス１２６は、ユーザに対して通知を発信し、送信することができる。例えば、ユーザは、コメント中に別のユーザについて言及することができ、コラボレーションサービス１２６は、ユーザがコメント中で言及されている通知をそのユーザに送信することができる。さまざまな他のコンテンツアイテムイベントは、コンテンツアイテムを削除すること、コンテンツアイテムを共有することなどを含む、通知をトリガすることができる。

コラボレーションサービス１２６は、メッセージングプラットフォームを提供することができ、このメッセージングプラットフォームにより、ユーザは、インスタントメッセージ、音声通話、電子メールなどを送信し、受信することができる。

コラボレーションコンテンツアイテム
いくつかの実施形態において、コンテンツ管理サービスは、コラボレーションドキュメントサービス１３４をも含むことができ、このコラボレーションドキュメントサービス１３４は、インタラクティブコンテンツアイテムコラボレーションプラットフォームを提供することができ、このインタラクティブコンテンツアイテムコラボレーションプラットフォームにより、ユーザは、コラボレーションコンテンツアイテム、これらのコラボレーションコンテンツアイテム中のコメントを同時に作成し、タスクをコラボレーションコンテンツアイテム内で管理することができる。コラボレーションコンテンツアイテムは、ユーザが作成し、コラボレーションコンテンツアイテムエディタを使用して編集することができ、コラボレーションコンテンツアイテム要素を含むことができるファイルであり得る。コラボレーションコンテンツアイテム要素は、コラボレーションコンテンツアイテム識別子、１つ以上のオーサー識別子、コラボレーションコンテンツアイテムテキスト、コラボレーションコンテンツアイテム属性、インタラクション情報、コメント、共有するユーザなどを含むことができる。コラボレーションコンテンツアイテム要素は、コラボレーションコンテンツアイテムを検索し、取得することを可能にする、データベースエンティティとして格納されることができる。複数のユーザは、同時に、または異なる時間に、コラボレーションコンテンツアイテムにアクセスし、これらのコラボレーションコンテンツアイテムを閲覧し、編集し、そしてコラボレーションすることができる。いくつかの実施形態において、これは、２人のユーザがウェブインタフェースを介してコンテンツアイテムにアクセスすることを要求することによって管理されることができ、そしてそこでこれら２人のユーザは、同時にコンテンツアイテムの同じコピー上で操作することができる。

コラボレーションコンパニオンインタフェース
いくつかの実施形態において、クライアントコラボレーションサービス１６０は、クライアントデバイス１５０上に提示されるコンテンツアイテムに関連する情報を表示する目的のために、ネイティブアプリケーションコンパニオンインタフェースを提供することができる。クライアントデバイス１５０に格納され、このクライアントデバイス１５０上で実行されるネイティブアプリケーションがコンテンツアイテムにアクセスする、いくつかの実施形態において、そこでコンテンツアプリケーション１５２がコンテンツアイテムを管理するように、コンテンツアイテムは、クライアントデバイス１５０のファイルシステムの指定の位置にあり、ネイティブアプリケーションは、上記のアドレス指定されたコラボレーションデータを表示するいかなるネイティブな方式も提供しない場合がある。これらのような実施形態において、クライアントコラボレーションサービス１６０は、ユーザがコンテンツアイテムを開いていることを検出することができ、コラボレーションデータなどのコンテンツアイテムについての追加情報をオーバーレイに提供することができる。例えば、追加情報は、コンテンツアイテムに対するコメント、コンテンツアイテムの状態、コンテンツアイテムを以前に閲覧していた、または現在閲覧している他のユーザのアクティビティを含むことができる。このようなオーバーレイは、別のユーザがコンテンツアイテムを現在編集しているため、変更が失われる可能性があることをユーザに警告することができる。

いくつかの実施形態において、パブリックまたはプライベートアプリケーションプログラミングインタフェースを使用して、上記に考察される、サービスまたはストレージ／データベースのうちの１つ以上にアクセスすることができる。

ある特定のソフトウェアアプリケーションは、コンテンツストレージ１４２にＡＰＩを介してユーザの代わりにアクセスすることができる。例えば、クライアントデバイス１５０上で実行するアプリケーションなどのソフトウェアパッケージは、ユーザが認証クレデンシャルを提供するときにコンテンツ管理システム１１０に直接ＡＰＩ呼び出しをプログラムに従い行い、コンテンツを読み出す、書き込む、作成する、削除する、共有する、またはその他の方法により操作することができる。

ユーザは、ウェブインタフェースサービス１２４によって生成され、サーブされるウェブインタフェースを介してユーザアカウントに格納されるコンテンツを閲覧する、または操作することができる。例えば、ユーザは、ウェブブラウザにおいて、コンテンツ管理システム１１０によって提供されるウェブアドレスにナビゲートすることができる。コンテンツアイテムの新規のバージョンをアップロードするなど、ウェブインタフェースを介して行われるコンテンツストレージ１４２中のコンテンツへの変更または更新は、伝播され、ユーザのアカウントと関連する他のクライアントデバイスに返されることができる。例えば、複数のクライアントデバイスは、これらのクライアントデバイス自体のそれぞれのクライアントソフトウェアとともに、単一アカウントと関連付けられることができ、このアカウント中のコンテンツアイテムは、複数のクライアントデバイスのそれぞれの間で同期することができる。

クライアントデバイス１５０は、ユーザの代わりにコンテンツ管理システム１１０に接続することができる。ユーザは、例えば、クライアントデバイス１５０がデスクトップまたはラップトップコンピュータ、電話、テレビ、モノのインターネットデバイスなどであるときに、クライアントデバイス１５０と直接インタラクトすることができる。代替的に、または追加的に、クライアントデバイス１５０は、例えば、クライアントデバイス１５０がサーバであるときに、ユーザがクライアントデバイス１５０への物理的なアクセスを有することなく、ユーザの代理を務めることができる。

クライアントデバイス１５０のいくつかの特徴は、クライアントデバイス１５０上にインストールされるアプリケーションによって有効にされる。いくつかの実施形態において、このアプリケーションは、コンテンツ管理システム専用コンポーネントを含むことができる。例えば、コンテンツ管理システム専用コンポーネントは、スタンドアロンアプリケーション１５２、１つ以上のアプリケーションプラグイン、及び／またはブラウザ拡張であることができる。しかしながら、ユーザも、ウェブブラウザなどの第三者アプリケーションを介してコンテンツ管理システム１１０とインタラクトすることができ、この第三者アプリケーションは、クライアントデバイス１５０上にあり、コンテンツ管理システム１１０と通信するように構成される。さまざまな実装において、クライアント側アプリケーション１５２は、ユーザに対してユーザインタフェース（ＵＩ）を提示し、コンテンツ管理システム１１０とインタラクトすることができる。例えば、ユーザは、ファイルシステムと統合されるファイルシステムエクスプローラを介して、またはウェブブラウザアプリケーションを使用して表示されるウェブページを介して、コンテンツ管理システム１１０とインタラクトすることができる。

いくつかの実施形態において、クライアントアプリケーション１５２は、コンテンツ管理システム１１０の１つより多いアカウントに対してコンテンツを管理し、同期させるように構成されることができる。これらのような実施形態において、クライアントアプリケーション１５２は、複数のアカウントにログインしたままで、複数のアカウントに対して通常のサービスを提供することができる。いくつかの実施形態において、各アカウントは、ファイルシステム中のフォルダとして現れることができ、そのフォルダ内のすべてのコンテンツアイテムは、コンテンツ管理システム１１０と同期することができる。いくつかの実施形態において、クライアントアプリケーション１５２は、プライマリアカウントまたはデフォルトアカウントである複数のアカウントのうちの１つを選ぶセレクタを含むことができる。

コンテンツ管理システム１１０に専用コンポーネントを提示しながら、当業者は、システム１００のアーキテクチャコンフィグレーションが唯一可能なコンフィグレーションであり、より多い、またはより少ないコンポーネントに関する他のコンフィグレーションが可能であることを理解するであろう。さらに、サービスは、別のサービスとともにあると記述される機能性さえも含む、多い、または少ない機能性を有することができる。さらに、１つの実施形態に関して本明細書に記述される特徴を、別の実施形態に関して記述される特徴と組み合わせることができる。

システム１００に専用コンポーネントを提示するが、当業者は、システム１００のアーキテクチャコンフィグレーションが唯一可能なコンフィグレーションであり、より多い、またはより少ないコンポーネントに関する他のコンフィグレーションが可能であることを理解するであろう。

クライアント同期サービス
図２は、いくつかの実施形態による、クライアント同期サービス１５６の実施例を示す。いくつかの実施形態により、クライアント同期サービス１５６は、図１のクライアントデバイス中に実装されることができる。しかしながら、他の実施形態において、クライアント同期サービス１５６は、別のコンピューティングデバイス上に実装されることができる。クライアント同期サービス１５６は、クライアント同期サービス１５６が実行する、コンテンツ管理システムとクライアントデバイスとの間のコンテンツアイテムへの変更を同期させるように構成される。

クライアント同期サービス１５６は、ファイルシステムインタフェース２０５、サーバインタフェース２１０、ツリーストレージ２２０、プランナ２２５、及びスケジューラ２３０を含むことができる。追加的な、または代替的なコンポーネントをも含むことができる。クライアント同期サービス１５６及びそのコンポーネントの高水準のディスクリプションを図２に関して下記に考察する。しかしながら、クライアント同期サービス１５６及びそのコンポーネントのさらなる詳細及び実施形態は、全体を通して考察される。

ファイルシステムインタフェース２０５は、クライアントデバイスのローカルファイルシステム上でコンテンツアイテムへの変更を処理し、ローカルツリーを更新するように構成される。例えば、ファイルシステムインタフェース２０５は、図１のクライアント同期サービス１５６と通信して、クライアントデバイスのローカルファイルシステム上でコンテンツアイテムへの変更を検出することができる。また、図１のクライアントアプリケーション１５２を介して、これらの変更を行い、検出することができる。ファイルシステムインタフェース２０５は、クライアントデバイス上のコンテンツアイテムへの変更（新規の、削除された、修正された、コピーされた、リネームされた、または移動されたコンテンツアイテム）に基づき行われることができる、ローカルツリーへの更新を行うことができる。

サーバインタフェース２１０は、コンテンツ管理システムのリモートストレージにおけるコンテンツアイテムへのリモート変更の処理、及びリモートツリーの更新の際に支援するように設定される。例えば、サーバインタフェース２１０は、図１のサーバ同期サービス１１２と通信し、クライアントデバイス１５０とコンテンツ管理システム１１０との間でコンテンツアイテムへの変更を同期させることができる。コンテンツ管理システム１１０におけるコンテンツアイテムへの変更（新規の、削除された、修正された、コピーされた、リネームされた、または移動されたコンテンツアイテム）を検出することができ、これらの変更をコンテンツ管理システム１１０に反映するために更新をリモートツリーに行うことができる。

ツリーストレージ２２０は、クライアント同期サービス１５６によって使用されるツリーデータ構造を格納し、維持するように構成される。例えば、ツリーストレージ２２０は、ローカルツリー、同期ツリー、及びリモートツリーを格納することができる。いくつかの実施形態により、ツリーストレージ２００は、レイテンシ及び応答時間を減少させるために、永続メモリ（例えば、ハードディスクまたは他のセカンダリストレージデバイス）に、またメインメモリ（例えば、ＲＡＭまたは他のプライマリストレージデバイス）にツリーデータ構造を格納することができる。例えば、クライアントデバイスまたはクライアント同期サービス１５６の起動時に、ツリーデータ構造を永続メモリから取得し、メインメモリにロードすることができる。ツリーストレージ２２０は、メインメモリ上でツリーデータ構造にアクセスし、これらのツリーデータ構造を更新し、クライアントデバイスまたはクライアント同期サービス１５６を停止する前に、ツリーストレージ２２０は、更新されたツリーデータ構造を永続メモリ上に格納することができる。メインメモリはコストが高く、ほとんどのクライアントデバイス上でサイズが制限されることが多いため、メインメモリ上のツリーデータ構造のフットプリントを減少させる追加の技術的な改善を実施する。これらの技術的な解決策を以下にさらに説明する。

プランナ２２５は、コンテンツ管理システムと関連するサーバ状態と、クライアントデバイスと関連するファイルシステム状態との間の差異をツリーデータ構造の状態に基づき検出するように構成される。例えば、プランナ２２５は、リモートツリーと同期ツリーとの間に差異があるかどうかを判定し得る。リモートツリーと同期ツリーとの間の差異は、コンテンツ管理システムに格納される１つ以上のコンテンツアイテム上にリモートに実行されるアクションにより、サーバ状態及びファイルシステム状態を同期させなくしたことを示す。同様に、プランナ２２５は、ローカルツリーと同期ツリーとの間の差異があるかどうかも判定し得る。ローカルツリーと同期ツリーとの間の差異は、クライアントデバイス上に格納される１つ以上のコンテンツアイテム上にローカルに実行されるアクションにより、サーバ状態及びファイルシステム状態を同期させなくしたことを示す。差異を検出した場合、プランナ２２５は、ツリーデータ構造を同期させる操作セットを生成する。

いくつかのシナリオにおいて、リモートツリーと同期ツリーとの間の差異に基づき生成される操作セット、及びローカルツリーと同期ツリーとの間の差異に基づき生成される操作セットは、競合する場合がある。また、プランナ２２５は、これら２つの操作セットを単一のマージされた操作プランにマージするように構成されることができる。

スケジューラ２３０は、生成された操作プランを行い、これらの操作の実行を管理するように構成される。いくつかの実施形態により、スケジューラ２３０は、操作プラン中の各操作を、操作を実行するために実行される必要がある一連の１つ以上のタスクに変換する。いくつかのシナリオにおいて、いくつかのタスクは、期限切れになる、またはもはや関連性がなくなる場合がある。スケジューラ２３０は、これらのタスクを識別し、それらをキャンセルするように構成される。

ツリーデータ構造
図３は、さまざまな実施形態による、ツリーデータ構造の実施例を示す。ツリーデータ構造は、クライアントデバイスに格納され、図２中のクライアント同期サービス１５６などのクライアント同期サービスによって管理されることができる。図３において、リモートツリー３１０、同期ツリー３３０、及びローカルツリー３５０を含む、ツリーデータ構造を示す。

リモートツリー３１０は、クライアントデバイスから遠隔に格納される（例えば、コンテンツ管理システムのサーバ上の）サーバ状態またはコンテンツアイテムの状態を表す。ローカルツリー３５０は、クライアントデバイス上でローカルに格納される、ファイルシステム状態、または対応するコンテンツアイテムの状態を表す。同期ツリー３３０は、ローカルツリー及びリモートツリーについてのマージベースを表す。マージベースは、ローカルツリー及びリモートツリーの共通祖先、またはローカルツリーとリモートツリーとの間で最後に既知の同期した状態であると考えられることができる。

各ツリーデータ構造（例えば、リモートツリー３１０、同期ツリー３３０、またはローカルツリー３５０）は、１つ以上のノードを含むことができる。各ノードは、１つ以上の子ノードを含むことができ、親子関係は、エッジによって表される。例えば、リモートツリー３１０は、ノード３１２及び３１４を含む。ノード３１２は、ノード３１４の親であり、ノード３１４は、ノード３１２の子である。この親子関係は、エッジ３１６によって表される。ルートノード３１２などのルートノードは、親ノードを含まない。ノード３１４などの葉ノードは、子ノードを含まない。

ツリーデータ構造中の各ノードは、コンテンツアイテム（例えば、ファイル、ドキュメント、フォルダなど）を表すことができる。例えば、ルートノード３１２は、コンテンツ管理システムと関連するルートフォルダを表すことができ、ノード３１４は、そのルートフォルダに位置しているファイル（例えば、「Ｆｏｏ．ｔｘｔ」と称されるテキストファイル）を表すことができる。ツリーデータ構造中の各ノードは、例えば、コンテンツアイテムの親ノードのファイル識別子を指定するディレクトリファイル識別子（「ＤｉｒＦｉｌｅＩＤ」）、コンテンツアイテムについてのファイル名、コンテンツアイテムについてのファイル識別子、及びコンテンツアイテムについてのメタデータなどのデータを含むことができる。いくつかの実施形態において、ツリーデータ構造中の各ノードは、入力され、そのファイル識別子によって参照され、ルートからノードへの一意のパスを含むことができる。

上述されるように、クライアント同期サービスは、３つのツリー（例えば、リモートツリー３１０、同期ツリー３３０、及びローカルツリー３５０）がすべて同一であるときに、クライアントデバイスのサーバ状態及びファイルシステム状態が同期していると判定することができる。換言すれば、ツリーは、それらのツリー構造、及びそれらが表現する関係が同一であり、またそれらのノードに含まれるデータが同様に同一であるときに同期している。一方、３つのツリーが同一ではない場合に、これらのツリーは、同期していない。図３に示される例示的なシナリオにおいて、リモートツリー３１０、同期ツリー３３０、及びローカルツリー３５０は、同一であり、同期している場合が示されているため、結果として、サーバ状態及びファイルシステム状態は、同期している。

ツリーデータ構造を使用する変更の追跡
図４は、さまざまな実施形態による、ツリーデータ構造の実施例を示す。図３に示されるツリーデータ構造と同様に、図４に示されるツリーデータ構造（リモートツリー４１０、同期ツリー４３０、及びローカルツリー４５０を含む）をクライアントデバイスに格納し、図２中のクライアント同期サービス１５６などのクライアント同期サービスによって管理することができる。図３に、ツリーデータ構造を示す。

図４は、図３に示されるシナリオなど、前に同期した状態の後のシナリオを示し、ツリーがもはや同期していないようにコンテンツアイテムを修正する、追加のアクションをツリーに表されるコンテンツアイテム上で実行する。同期ツリー４３０は、前の既知の同期した状態の表現を維持し、クライアント同期サービスによって、サーバ状態とファイルシステム状態との間の差異を識別するだけではなく、コンテンツ管理システム及び／またはクライアントデバイスについての操作を生成して実行し、サーバ状態及びファイルシステム状態が同期するように収束させるために使用されることができる。

例えば、ユーザ（クライアントデバイスと関連するユーザと同一のユーザ、またはコンテンツアイテムへのアクセスを有する異なるユーザ）は、コンテンツ管理システムによって格納される「ｆｏｏ．ｔｘｔ」コンテンツアイテムへの修正をすることができる。このコンテンツアイテムは、リモートツリー４１０中のノード４１４によって表される。リモートツリー４１０に示される修正は、ｆｏｏ．ｔｘｔコンテンツアイテムの除去（例えば、コンテンツ管理システムによって管理されるスペースからのコンテンツアイテムの除去）または削除である。これらの修正は、例えば、別のクライアントデバイス上で実行されることができ、これらの修正は、コンテンツ管理システムによって格納されるコンテンツアイテム、またはウェブブラウザを介してコンテンツ管理システムによって格納されるコンテンツアイテムに同期した。

コンテンツ管理システム上で変更を行うときに、コンテンツ管理システムは、行われる変更を指定する修正データを生成し、この修正データをクライアントデバイス上のクライアント同期サービスに送信する。クライアント同期サービスは、修正データに基づきコンテンツ管理システムによって格納されるコンテンツアイテムについてのサーバ状態を表すリモートツリーを更新する。例えば、リモートツリー４１０において、ｆｏｏ．ｔｘｔコンテンツアイテムを表すノード４１４が削除された場合を示す。

クライアント同期サービスは、リモートツリー４１０と同期ツリー４３０との間の差異を識別することができ、結果として、コンテンツ管理システムにおけるコンテンツアイテムの修正により、サーバ状態及びファイルシステム状態がもはや同期していないと判定することができる。クライアント同期サービスは、サーバ状態及びファイルシステム状態が同期しているようにそれらサーバ状態及びファイルシステム状態を収束させるように構成される、クライアントデバイス上に格納されるコンテンツアイテムについての操作セットまたはシーケンスをさらに生成して、実行することができる。

追加的に、または代替的に、ユーザ（コンテンツ管理システムにおける修正と関連するユーザと同一のユーザ、またはコンテンツアイテムへのアクセスを有する異なるユーザ）は、コンテンツ管理システムと関連付けられるクライアントデバイス上にローカルに格納されるコンテンツアイテムへの修正を行うことができる。例えば、ユーザは、フォルダ「／ｂａｒ」を「／ｒｏｏｔ」フォルダに追加し、「Ｈｉ．ｄｏｃ」ドキュメントを「／ｂａｒ」フォルダに追加することができる。

変更をクライアントデバイス上で行うときに、クライアントデバイス（例えば、図１のクライアント同期サービス１５６またはクライアントアプリケーション１５２）は、行われる変更を指定する修正データを生成し、修正データをクライアントデバイス上のクライアント同期サービスに渡す。クライアント同期サービスは、修正データに基づきクライアントデバイス上に格納されるコンテンツアイテムについてのファイルシステム状態を表すローカルツリーを更新する。例えば、ローカルツリー４５０において、ノード４５２及びノード４５４が追加される場合を示す。ノード４５２及びノード４５４は、それぞれ「／ｂａｒ」フォルダ及び「Ｈｉ．ｄｏｃ」ドキュメントを表す。

クライアント同期サービスは、ローカルツリー４５０と同期ツリー４３０との間の差異を識別し、結果として、クライアントデバイスにおけるコンテンツアイテムの修正により、サーバ状態及びファイルシステム状態がもはや同期していないと判定することができる。クライアント同期サービスは、サーバ状態及びファイルシステム状態を収束させることで、それらが同期しているように設定される、コンテンツ管理システムによって格納されるコンテンツアイテムについての操作セットまたはシーケンスをさらに生成することができる。これらの操作を実行のためにコンテンツ管理システムに送信することができる。

図４に示されるように、クライアントデバイス上に格納されるコンテンツアイテム、及びコンテンツ管理システムによって格納されるコンテンツアイテムへの修正は、実質的に同時に、または特定の期間内に起こる可能性がある。これらの修正をツリーデータ構造に反映し、クライアント同期サービスによって使用して、クライアントデバイスについての、またコンテンツ管理システムについての操作を並列して生成することができる。他のシナリオにおいて、しかしながら、修正は、同じ期間内に必ずしも起こらない場合があり、操作は、必要に応じた方式において生成されることができる。さらに、図４がコンテンツアイテムを追加するための、またコンテンツアイテムを削除するためのシナリオを示すが、コンテンツアイテムを編集する、リネームする、コピーする、または移動させるなどの他のタイプの修正をもサポートする。

さまざまな実施形態により、２つのツリーデータ構造間の差異を識別すること、そして操作を生成することは、両方のツリーデータ構造中の各ノードをチェックすること、そしてアクションがこのノード上で実行されているかどうかを判定することを伴うことがある。これらのアクションは、例えば、ノードの追加、ノードの削除、ノードの編集、またはノードの移動を含むことができる。次いで、これらのアクションを使用して、サーバ状態及びファイルシステム状態を収束させるように構成される操作を生成することができる。

例えば、２つのツリーデータ構造が同期ツリー及びリモートツリーである場合に、クライアント同期サービスは、例えば、同期ツリー中のすべてのノードのファイル識別子を要求することによって、同期ツリー中の各ノードを識別することができる。同期ツリー中の各ノード、またはこのノードについてのファイル識別子のために、クライアント同期サービスは、ノードまたはファイル識別子もリモートツリー中にあるかどうかを判定することができる。リモートツリー中に見つからない同期ツリー中のノードまたはファイル識別子は、ノードがリモートツリーによって表されるサーバ状態から削除されていることを示すことができる。その結果、クライアント同期サービスは、削除アクションがリモートツリー上に発生したと判定することができる。ノード、またはこのノードについてのファイル識別子がリモートツリー中に見つかる場合に、クライアント同期サービスは、リモートツリー中のノードが編集されているか、移動しているかをチェックすることができる。

リモートツリー中のノードが同期ツリー中のノードに関して編集されているかどうかを判定するために、クライアント同期サービスは、同期ツリー中のノードについてのメタデータを、リモートツリー中の対応するノード（例えば、同一のファイル識別子を有するノード）についてのメタデータと比較することができる。メタデータは、ノードによって表されるコンテンツアイテムが編集されているかどうかを判定するために使用され得る情報を含むことができる。例えば、メタデータは、コンテンツアイテム中のデータに基づき生成される１つ以上のハッシュ値、またはそれらの一部を含むことができる。メタデータは、追加的に、または代替的に、コンテンツアイテムについての、サイズ値、最後に修正された値、または他の値を含むことができる。同期ツリー中のノードについてのメタデータを、リモートツリー中のノードについてのメタデータと比較することができる。メタデータがマッチングしない場合、コンテンツアイテムの編集は、リモートツリーによって表されるサーバ状態において編集されている。その結果、クライアント同期サービスは、編集アクションがリモートツリー上のノードに発生していると判定することができる。メタデータがマッチングする場合に、編集は発生しなかった可能性がある。

リモートツリー中のノードが移動しているかどうかを判定するために、クライアント同期サービスは、同期ツリー中のノードについての位置を、リモートツリー中の対応するノード（例えば、同一のファイル識別子を含むノード）についての位置と比較することができる。この位置は、例えば、ノードが位置しているパス、ファイル名、及び／またはノードの親のファイル識別子を指定するディレクトリファイル識別子（「ＤｉｒＦｉｌｅＩＤ」）を含むことができる。これらの位置がマッチングする場合に、移動は、起こらなかった可能性がある。一方、これらの位置がマッチングしない場合に、コンテンツアイテムの移動は、リモートツリーによって表されるサーバ状態に起こった可能性がある。その結果、クライアント同期サービスは、移動アクションがリモートツリー上のノードに対して発生したと判定することができる。

ノードをリモートツリーに追加したかどうかを判定するために、クライアント同期サービスは、同期ツリー中に見つからない、リモートツリー中のいずれかのノードまたはファイル識別子を識別することができる。ノードまたはファイル識別子がリモートツリー中に見つかり、同期ツリー中に見つからない場合に、クライアント同期サービスは、このノードの追加アクションがサーバ状態を表すリモートツリー上に発生したと判定することができる。

上記の実施例が同期ツリー及びリモートツリーに関して記述されているが、他の実施形態において、同様のプロセスは、同期ツリーとローカルツリーとの間の差異を識別し、ファイルシステム状態を表すローカルツリー上に発生したアクションを判定するために、同期ツリー及びローカルツリーに関して発生することができる。

ツリーデータ構造を使用する同期
図５は、本技術のさまざまな実施形態により、ツリーデータ構造を使用してサーバ状態及びファイルシステム状態を同期させる例示的な方法を示す。本明細書に記載されるこれらの方法及びプロセスが特定の順序で、ある特定のステップ及び操作によって示されることができるが、同様の、もしくは代替の順序で、または並列して実行される追加の、より少ない、または代替のステップ及び操作は、別段の定めがない限り、さまざまな実施形態の範囲内にある。この方法５００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などのシステムによって実装されることができる。

このシステムは、コンテンツ管理システムによって格納されるコンテンツアイテムについてのサーバ状態を表すリモートツリーと、クライアントデバイス上に格納される対応するコンテンツアイテムについてのファイルシステム状態を表すローカルツリーと、サーバ状態及びファイルシステム状態の間の既知の同期した状態を表す同期ツリーとの間の差異を識別するように設定される。これらの差異に基づき、生成されることができる操作セットは、実行される場合に、３つのツリーデータ構造が同一である同期した状態に向けてサーバ状態及びファイルシステム状態を収束させるように構成される。

例えば、操作５０５において、システムは、コンテンツ管理システムによって、またはクライアントデバイス上に、格納されるコンテンツアイテムについての修正データを受信することができる。操作５１０において、この修正データを使用して、リモートツリーまたはローカルツリーを更新することができる。

修正データは、コンテンツ管理サービスと関連する１つ以上のコンテンツアイテムに行われる変更を指定する。その結果、修正データをコンテンツ管理システムから、またはクライアントデバイスから（例えば、図１中のクライアントデバイス１５０上で実行するクライアントアプリケーション１５２から）受信することができる。コンテンツ管理システムから受信する修正データは、サーバ修正データと称されることができる。サーバ修正データは、コンテンツ管理システムによって１つ以上のコンテンツアイテムに行われる変更を指定し、操作５１０において、リモートツリーを更新するために使用され得る。クライアントデバイスから受信する修正データは、クライアント修正データと称されることができる。クライアント修正データは、クライアントデバイス上で１つ以上のコンテンツアイテムに行われる変更を指定し、操作５１０においてローカルツリーを更新するために使用されることができる。

操作５１５において、システムは、コンテンツ管理システムによって格納されるコンテンツアイテムについてのサーバ状態、及びクライアントデバイス上に格納されるコンテンツアイテムについてのファイルシステム状態が同期しているかどうかを判定することができる。ローカルツリー及びリモートツリーがファイルシステム状態及びサーバ状態を表し、コンテンツ管理システム及びクライアントデバイスに発生する変更を追跡して、継続的に更新されているため、サーバ状態及びファイルシステム状態が同期しているかどうかを判定することは、ローカルツリー及び／またはリモートツリーを同期ツリーと比較して、ツリー間の差異を見つけることによって行われ得る。ツリー間の差異を見つける、このプロセスは、ときとしてツリーの「差分を取る」と称される。

いくつかの実施形態及びシナリオによる、サーバ状態及びファイルシステム状態が同期しているかどうかを判定することは、リモートツリーと同期ツリーとの間の差異を識別すること、及び／またはローカルツリーと同期ツリーとの間の差異を識別することのうちの１つ以上を含むことができる。リモートツリーと同期ツリーとの間の差異は、クライアントデバイスに反映されていない可能性がある、コンテンツ管理システムによって格納されるコンテンツアイテムへの変更の発生を示すことができる。同様に、ローカルツリーと同期ツリーとの間の差異は、コンテンツ管理システムに反映されていない可能性がある、クライアントデバイスに格納されるコンテンツアイテムへの変更の発生を示すことができる。

ツリー間に差異がない場合に、サーバ状態及びファイルシステム状態は、同期し、同期アクションは、必要とされない。その結果、この方法は、操作５０５に戻り、新規の修正データを待機することができる。一方で、これらの差異が検出される場合に、システムは、操作５２０においてサーバ状態及びファイルシステム状態を収束させるように設定される操作セットを生成することができる。

生成される操作セットは、検出される１つ以上の差異に依存する。例えば、２つのツリー間の差異が追加されたコンテンツアイテムである場合に、生成された操作セットは、追加されたコンテンツアイテムを取得して、それを追加することを含むことができる。２つのツリー間の差異がコンテンツアイテムの削除である場合に、生成された操作セットは、コンテンツアイテムを削除することを含むことができる。いくつかの実施形態により、また、操作セットは、ツリー制約が維持されていることを確保する複数のチェックを含むことができる。以下にさらに記述されるように、操作セットは、サーバ状態、ファイルシステム状態、または実行を保留している他の操作の現在の状態によって競合する場合がある。その結果、システムは、続行する前にこれらの競合をも解消することができる。

上述されるように、リモートツリーと同期ツリーとの間に差異がある場合に、クライアントデバイスに反映されていない可能性がある、コンテンツ管理システムによって格納されるコンテンツアイテムへの変更が発生している場合がある。その結果、このシナリオにおいて、システムは、クライアントデバイス上に格納されるコンテンツアイテム上で動作して、サーバ状態及びファイルシステム状態を収束させるように構成されるクライアント操作セットを生成することができ、このクライアント操作セットは、操作５２５において、実行のためにクライアントデバイスに提供され得る。

一方、ローカルツリーと同期ツリーとの間の差異がある場合に、コンテンツ管理システムに反映されていない可能性がある、クライアントデバイスに格納されるコンテンツアイテムへの変更が発生している可能性がある。その結果、このシナリオにおいて、システムは、コンテンツ管理システムによって格納されるコンテンツアイテム上で動作して、サーバ状態及びファイルシステム状態を収束させるように構成されるサーバ操作セットを生成することができ、このサーバ操作セットは、操作５２５において、実行のためにコンテンツ管理システムに提供されることができる。いくつかの事例において、両方の事例は、真であることができ、クライアント操作セット及びサーバ操作セットは、操作５２５において生成され、それらの意図されたレシピエントに提供され得る。

操作セット（複数可）が意図されたレシピエント（複数可）に提供されると、方法は、操作５０５に戻り、新規の修正データを待機することができる。操作セット（複数可）は、サーバ状態及びファイルシステム状態の収束に向けて１つ以上のステップを提供する、またはサーバ状態及びファイルシステム状態を同期させるために必要とされるすべてのステップを提供することができる。例えば、コンテンツ管理システムは、サーバ操作セットを受信し、サーバ操作セットをコンテンツ管理システムによって格納されるコンテンツアイテム上で実行することができる。サーバ操作セットのこの実行は、変更をコンテンツ管理システムによって格納されるコンテンツアイテムに引き起こし、これらの変更をサーバ修正データ中で検出し、指定し、システムに返送する。次いで、このシステムは、リモートツリーを更新し、サーバ状態及びファイルシステム状態が同期しているかどうかを判定することができる。

クライアントデバイスは、クライアント操作セットを受信し、クライアント操作セットをクライアントデバイス上に格納されるコンテンツアイテム上で実行することができる。クライアント操作セットのこの実行は、変更をクライアントデバイス上に格納されるコンテンツアイテムに引き起こし、これらの変更をクライアント修正データ中で検出し、指定し、システムに渡す。次いで、このシステムは、ローカルツリーを更新し、サーバ状態及びファイルシステム状態が同期しているかどうかを判定することができる。方法５００のこれらの操作は、サーバ状態及びファイルシステム状態が同期するまで継続することができる。

方法５００の操作は、クライアント側及びサーバ側（例えば、ローカルツリー及びリモートツリー、ファイルシステム状態及びサーバ状態、クライアント操作セット及びサーバ操作セット、クライアント修正データ及びサーバ修正データ）に関して記述されている。さまざまな実施形態において、これら２つの側と関連する操作は、並列して、順次に、他の側から切り離されて、または組み合わせて、発生し得る。

さらに詳細に考察されるように、いくつかの実施形態により、操作を実行のために提供する前に、システムは、操作をチェックし、それらが１セットのルールまたは不変条件に従うかどうかを判定することができる。操作がルールに違反する場合に、システムは、ルール違反と関連する解消プロセスを実行する。

加えて、いくつかの実施形態により、システム（例えば、図２中のクライアント同期サービス１５６のスケジューラ２３０）は、操作セットの実行を管理することができる。例えば、操作セット中の各操作は、タスク、実行スレッド、一連のステップ、または命令と関連付けられることができる。システムは、タスク、スレッド、ステップ、または命令を実行し、クライアントデバイス及び／またはコンテンツ管理システムとインタフェースし、操作セットを実行してサーバ状態及びファイルシステム状態を収束させるように設定されることができる。

競合ハンドリング
図５に関して上述されるように、同期ツリーとリモートツリーとの間の差異を識別し、使用して、サーバ状態及びファイルシステム状態を収束させるように構成されるクライアント操作セットを生成する。しかしながら、いくつかの事例において、クライアント操作セットは、ローカルツリーの現在の状態と競合する場合がある。同様に、同期ツリーとローカルツリーとの間の差異を識別し、使用して、サーバ状態及びファイルシステム状態を収束させるように構成されるサーバ操作セットを生成する。しかしながら、サーバ操作セットは、リモートツリーの現在の状態と競合する。追加的に、または代替的に、クライアント操作セット及びサーバ操作セットは、互いに競合する、またはシステムによって維持される別のルールもしくは不変条件に違反する場合がある。その結果、本発明の技術のさまざまな実施形態は、これらの競合を解消することによってさらなる技術的な改善を提供する。

例えば、図２のクライアント同期サービス１５６中のプランナ２２５は、ルールと競合する操作セット（例えば、クライアント操作セットまたはサーバ操作セット）中の操作を識別することができる。競合を識別するために使用される各ルールは、競合の解消とも関連付けられることができる。クライアント同期サービスは、実行のための操作セットを提供する前に、競合についての解消に基づき操作セットを更新する、または競合についての解消と関連する操作を実行することによって競合の解消を実行することができる。

図６は、本発明の技術のさまざまな実施形態による、ツリーデータ構造を使用して、サーバ状態及びファイルシステム状態を同期させるときに競合を解消するための例示的な方法６００を示す。ある特定のステップ及び操作を有する、本明細書に記述されるこれらの方法及びプロセスは、特定の順序で示されることができるが、同様の順序もしくは代替の順序で、または並列して、実行される追加の、より少数の、または代替のステップ及び操作は、特に明示されない限り、さまざまな実施形態の範囲内にある。この方法６００は、例えば、図２のクライアント同期サービス１５６などのシステムによって実装され、クライアントデバイス上で実行される。

システムは、操作６２０において、サーバ状態及びファイルシステム状態を収束させるように設定される操作セットを受信することができる。操作セットは、例えば、クライアント操作セット、サーバ操作セット、または図５の方法５００に関して生成され、記述される組み合わされた操作セットであることができる。

操作６５０において、システムは、ルールセットに基づき操作セット中で１つ以上の違反を識別する。このルールセットは、図２中のクライアント同期サービス１５６によって格納され、解消される必要がある操作について、複数の制約、不変式、または競合を指定することができる。このルールセットは、ツリーデータ構造に適用され、同期ビヘイビアの制御を援助することができる。また、このルールセットの中の各ルールは、そのルールの違反への解消に関連付けられる、またはその他の方法によりリンクされることができる。例えば、この解消は、操作セット中の１つ以上の操作の変更、１つ以上の操作の除去、１つ以上の操作の追加、サーバ状態もしくはファイル状態への１つ以上の追加アクション、またはアクションの組み合わせを備えることができる。

操作セット中の各操作について、システムは、ルールセットのうちのいずれかのルールに違反しているかどうかを判定することができる。ルールに違反している場合に、システムは、違反の解消を識別し、操作６５５において、解消を実行する。この解消は、操作セット中の１つ以上の操作を修正するようなアクション、１つ以上の操作を除去する、もしくは追加するアクション、またはサーバ状態もしくはファイル状態上の追加アクションを備えることができる。

解消アクションが実行されると、システムは、操作６６０において、解消及び操作セットに基づき、解消された、またはリベースされた操作セットを生成し、操作６６５において、解消された操作セットを実行のために適切なエンティティに提供することができる。例えば、管理された実行のために、解消された操作セットを図２中のクライアント同期サービス１４６のスケジューラ２３０に提供することができる。代替に、操作セットがクライアント操作セットである場合に、解消された操作セットは、クライアントデバイスに提供されることができる。操作セットがサーバ操作セットである場合に、解消された操作セットは、コンテンツ管理サービスに提供されることができる。加えて、図６の方法６００は、順次に、並列して、またはさまざまな異なる順序で、クライアント操作セット、及びサーバ操作セット上で実行されることができる。

いくつかの実施形態により、各操作タイプは、同一の、または異なる１セットのルールと関連付けられることができる。例えば、操作タイプは、例えば、コンテンツアイテムを追加すること、コンテンツアイテムを削除すること、コンテンツアイテムを編集すること、コンテンツアイテムを移動させること、コンテンツアイテムをリネームすることなどを含むことができる。操作セットは、上記の操作タイプのうちの１つに各属する操作からなることができる。各操作タイプは、特定の１セットのルールと関連付けられることができる。

例示的な目的のために、「Ａｄｄ」操作タイプについての１セットのルールは、コンテンツアイテムについてのファイル識別子がツリー中で一意でなければならない（例えば、１つのツリー中の２つのノードが同一のファイル識別子を含むことができない）ようなルールを有することができ、コンテンツアイテムの親ノードのファイル識別子を指定するディレクトリファイル識別子（「ＤｉｒＦｉｌｅＩＤ」）は、対向するツリーデータ構造中に存在しなければならず、コンテンツアイテムについてのＤｉｒＦｉｌｅＩＤ及びファイル名の組み合わせは、対向するツリー中に使用されない。

対向するツリーは、本明細書に使用される場合、対向するエンティティの状態を表すツリーデータ構造を指す。例えば、クライアントデバイス上で動作するように設定されるクライアント操作セット、及びクライアントデバイス上でのファイルシステムへの結果として生じる変更をローカルツリーに反映する。その結果、クライアント操作セットについて対向するツリーは、リモートツリーである。同様に、サーバ操作セットは、コンテンツ管理システムに送信され、実行されるように設定され、サーバ状態への結果として生じる変更は、リモートツリーに反映される。その結果、サーバ操作セットについて対向するツリーは、ローカルツリーである。

図７は、さまざまな実施形態により、追加操作についてのルール違反を示すツリーデータ構造の実施例を示す。ツリーデータ構造は、リモートツリー７１０、同期ツリー７５０、及びローカルツリー７７０を含む。ローカルツリー７７０を参照するときに、リモートツリー７１０が対向するツリーとみなされることができる。一方、リモートツリー７１０を参照するときに、ローカルツリー７７０は、対向するツリーとみなされることができる。図７は、ノード７１２によって表されるコンテンツアイテムをリモートツリー７１０中に追加する操作セットを示す。例えば、クライアント同期サービスは、リモートツリー７１０を同期ツリー７５０と比較して、これらの差異を識別し、ノード７１２の追加を含む操作セットを生成することができる。ノード７１２は、４のＦｉｌｅＩＤ、３のＤｉｒＦｉｌｅＩＤ（ノード７１２の親である、親ノード７１４を参照する）、及び「Ｈｉ」のファイル名と関連付けられる。親ノード７１４は、３のＦｉｌｅＩＤ、１のＤｉｒＦｉｌｅＩＤ（ノード７１４の親である、ルートノード７１６を参照する）、及び「Ｆｏｏ」のファイル名と関連付けられる。

クライアント同期サービスは、図６の方法６００を実行し、ノード７１２についての追加操作が「追加」操作タイプについての「コンテンツアイテムのディレクトリファイル識別子（「ＤｉｒＦｉｌｅＩＤ」）は対向するツリーデータ構造中に存在しなければならない」ルールに違反すると判定することができる。これは、ノード７１２の親ノード７１４を参照する、３のファイルＩＤを有するノードを含まないローカルツリー７７０によって図７に示される。これは、例えば、リモートツリー７１０と同期ツリー７５０との間の差異が判定され、操作セットが生成された後に、ノード７１４に対応する「Ｆｏｏ」ノードが対向するツリーから除去されるときに発生し得る。

このルールについて関連する解消は、ローカルツリー７７０から欠落するノードを同期ツリー７５０から削除して同期ツリー７５０及びローカルツリー７７０を同期させること、ならびにリモートツリー７１０及び同期ツリー７５０を再差分する（例えば、リモートツリー７１０と同期ツリー７５０との間の差分を見いだす）ことを備えることができる。図７に示されるシナリオにおいて、同期ツリー７５０中のノード７５４は、除去され７５８、差分操作は、リモートツリー７１０と同期ツリー７５０との間の差分を識別し始める。これは、操作セット中のノード７１４の追加操作、及びノード７１２についての追加操作の包含をもたらす。

同様に、「追加」操作タイプに対する「コンテンツアイテムについてのファイル識別子はツリー中で一意でなければならない」ルールの違反は、追加されるノードについて新規のファイルＩＤをコンテンツ管理システムから要求すること、及びノードを追加するときに新規のファイルＩＤを使用することを含む操作によって解消されることができる。「追加」操作タイプに対する「コンテンツアイテムについてＤｉｒＦｉｌｅＩＤ及びファイル名の組み合わせは対向するツリーに使用されない」ルールの違反は、これら２つのノードと関連するメタデータを介して、コンテンツアイテムが同一であるかどうかをチェックすることを含む操作によって解消されることができる。コンテンツアイテムが同一である場合に、追加されているコンテンツアイテムが他のアクション中にすでに追加されている可能性が高い。コンテンツアイテムが同一ではない場合に、追加されているコンテンツアイテムについてのファイル名をリネームすることができる。例えば、追加されているコンテンツアイテムについてのファイル名にｔｅｘｔ「（競合したバージョン）」をアペンドすることができる。

インクリメンタルプランナ
図３、４、及び７に示されるさまざまなツリーデータ構造が比較的に少ない数のノードを含み、構造において比較的に単純であるが、システムによってサポートされるツリーデータ構造は、複数のレベルについて、さらにより大きく複雑であり、各レベルにおいてノードの数が潜在的に多いことがある。その結果、操作中にツリーデータ構造を格納するために必要とされるメモリ使用量は、非常に大きい可能性があり、ツリーデータ構造上で動作するために必要とされる計算時間及びリソースは、非常に大きい可能性がある。例えば、リモートツリーと同期ツリーとの間の差異、及び／またはローカルツリーと同期ツリーとの間の差異を見いだすこと、ならびにリモートツリー及び同期ツリー、及び／またはローカルツリー及び同期ツリーを収束させるために必要とされる操作を生成することは、大量のメモリ、時間、及び他の計算リソースを必要とする可能性がある。

残念ながら、これらの計算リソースは、限られている。例えば、クライアントデバイスは、限られた利用可能なメモリ量を有することができ、ツリーを差分して操作を生成するために必要とされる時間長は、コンテンツ管理システムによって提供される、クライアントデバイス、クライアントアプリケーション、またはコンテンツ管理サービスのユーザビリティを妨げる可能性がある。さらに、サーバ状態及びファイルシステム状態を収束させるために必要とされる時間が長くなるほど、いずれかの状態への間に起こる変更が計算される、または実行される操作セットをレンダリングする可能性がより高くなる、及び／または標的同期状態が古くなる可能性がより高くなる。その結果、本発明の技術のさまざまな実施形態は、サーバ状態及びファイルシステム状態を、そしてそれらを表すツリーデータ構造と共にインクリメンタルに収束させることによってさらなる技術的な改善を提供する。

図８は、本発明の技術のさまざまな実施形態により、サーバ状態及びファイルシステム状態をインクリメンタルに収束させる例示的な方法８００を示す。本明細書に記述される、特定の順序で、ある特定のステップ及び操作を備える、これらの方法及びプロセスを示すことができるが、同様の、もしくは代替の順序で、または並列して実行される、追加の、少数の、または代替のステップ及び操作は、特に明示されない限り、さまざまな実施形態の範囲内にある。この方法８００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などの、システムによって実装されることができる。

操作８０５において、システムは、修正データを受信することができ、この修正データを使用して、リモートツリーまたはローカルツリーのいずれか一方を更新することができる。例えば、サーバ修正データは、コンテンツ管理サービスから受信され、コンテンツ管理システムによって格納される１つ以上のコンテンツアイテムと関連する修正または他のアクション（例えば、編集、追加、削除、移動、またはリネーム）を指定することができる。サーバ修正データを使用して、コンテンツ管理システムによって格納されるコンテンツアイテムのサーバ状態を表す、リモートツリーを更新することができる。同様にクライアント修正データは、クライアントデバイス（例えば、クライアントアプリケーション）から受信され、クライアントデバイス上に格納される１つ以上のコンテンツアイテムと関連する修正または他のアクションを指定することができる。クライアント修正データを使用して、クライアントデバイス上に格納されるコンテンツアイテムのファイルシステム状態を表す、ローカルツリーを更新することができる。

操作８１０において、コンテンツアイテムと関連する修正を指定する受信した修正データに基づき、システムは、修正されたコンテンツアイテムに対応するノードを識別し、これらのノードを修正されたコンテンツアイテムのリストに追加する（例えば、ノードと関連するファイル識別子を修正されたコンテンツアイテムのリストに追加する）ことができる。操作８０５及び８１０は、システムが方法８００の次の段階に進む前にしばらくの間、連続して発生する場合がある。例えば、追加の修正データを受信して使用し、システムによって管理されるツリーを更新し、ノードを修正されたコンテンツアイテムのリストに追加することができる。

サーバ状態及びファイルシステム状態をインクリメンタルに収束させるために、操作８１５において、システムは、修正されたコンテンツアイテムのリスト中の各ノードを取得し、ノードが修正された方法（例えば、どのアクションがノードと関連付けられるか）を判定する。いくつかの実施形態において、修正データは、ノードへの修正を指定することができる。しかしながら、他の実施形態において、システムは、リモートツリーの同期ツリーとの比較、及び／またはローカルツリーの同期ツリーとの比較に基づきノードへの修正を判定することができる。例えば、これらの修正は、ノードの追加、ノードの削除、ノードの編集、またはノードの移動を含むことができる。

修正されたコンテンツアイテムのリスト中の各ノード、またはこのノードについてのファイル識別子に対して、システムは、もしあれば、ノード上に実行された修正を判定する、一連のチェックを実行することができる。例えば、システムは、ファイル識別子が同期ツリー中にあるが、リモートツリー中にないかどうかを判定することができる。リモートツリー中に見いだされない同期ツリー中のファイル識別子は、ノードがリネームツリーによって表されるサーバ状態から削除されたことを示すことができる。その結果、クライアント同期サービスは、ノード上の削除修正がリモートツリー上で発生したと判定することができる。同様に、システムは、ファイル識別子が同期ツリー中にあるがローカルツリー中にないかどうかをも判定することができる。ローカルツリー中に見いだされない同期ツリー中のファイル識別子は、ノードがローカルツリーによって表されるファイルシステム状態から削除されたことを示すことができる。その結果、クライアント同期サービスは、ノード上の削除修正がローカルツリー上で発生したと判定することができる。

編集修正がノード上で実行されたかどうかを判定するために、システムは、同期ツリー中のノードについてのメタデータを、リモートツリー及び／またはローカルツリー中の対応するノード（例えば、同一のファイル識別子を有するノード）についてのメタデータと比較することができる。このメタデータは、ノードによって表されるコンテンツアイテムが編集されたかどうかを判定するために使用されることができる情報を含むことができる。例えば、メタデータは、コンテンツアイテム中のデータ、またはそれらの一部に基づき生成される１つ以上のハッシュ値を含むことができる。加えて、または代替に、メタデータは、コンテンツアイテムについてのサイズ値、最後に修正された値、または他の値を含むことができる。メタデータがマッチングしない場合に、コンテンツアイテムの編集は、リモートツリーによって表されるサーバ状態、及び／またはローカルツリーによって表されるファイルシステム状態において編集された可能性がある。その結果、システムは、編集アクションがリモートツリー及び／またはローカルツリー上のノードに対して発生したと判定することができる。

リモートツリー中のノードが移動したかどうかを判定するために、システムは、同期ツリー中のノードについての位置を、リモートツリー及び／またはローカルツリー中の対応するノード（例えば、同一のファイル識別子を有するノード）についての位置と比較することができる。この位置は、例えば、ノードが位置しているパス、ファイル名、及び／またはノードの親のファイル識別子を指定するディレクトリファイル識別子（「ＤｉｒＦｉｌｅＩＤ」）を含むことができる。これらの位置がマッチングする場合に、移動は、起こらなかった可能性がある。一方、これらの位置がマッチングしない場合に、コンテンツアイテムの移動は、リモートツリーまたはローカルツリーに起こった可能性がある。その結果、クライアント同期サービスは、移動アクションがリモートツリー及び／またはローカルツリー上のノードに対して発生したと判定することができる。

ノードをリモートツリーに追加したかどうかを判定するために、システムは、修正されたコンテンツアイテムのリスト中のファイル識別子がリモートツリー中に、またはローカルツリー中にあるが同期ツリー中にないかどうかを判定することができる。ファイル識別子がリモートツリーまたはローカルツリー中に見いだされ、同期ツリー中に見いだされない場合に、システムは、このノードについて追加修正が発生したと判定することができる。

修正されたコンテンツアイテムのリスト中のノードへの１つ以上の修正を判定すると、システムは、操作８２０において、これらの修正のいずれかが依存性を有するかどうかを判定することができる。図９に関してさらに説明されるように、例えば、修正は別の修正が最初に発生することなく実行されることができないときに、ノード上の修正は、依存性を有する。

修正が依存性を有さない場合に、操作８２５において、システムは、修正をアクションのブロックされていないリストに追加する。修正が依存性を有する場合に、修正は、操作８３０において当分の間ブロックされ、別の修正が最初に処理されることなく実行されることができない。各修正を処理した後に、システムは、これらの修正と関連するファイル識別子を、修正されたコンテンツアイテムのリストからクリアすることができる。

図９は、さまざまな実施形態により、ツリーデータ構造の実施例を示す。図９に示されるツリーデータ構造をクライアントデバイスに格納し、図２中のクライアント同期サービス１５６などのシステムによって管理することができる。説明目的のために、リモートツリー９１０及び同期ツリー９５０のみを図９に示し、説明する。また、同様の操作及び説明をローカルツリーにも適用することができる。

リモートツリー９１０は、１のファイル識別子を有するルートノード９１２、５のファイル識別子及び「Ｆｏｏ」のファイル名を有するノード９１４、６のファイル識別子及び「Ｂａｒ」のファイル名を有するノード９１６、ならびに７のファイル識別子及び「Ｂｙｅ」のファイル名を有するノード９１８を含む。同期ツリーは、１のファイル識別子を有するルートノード９５２を含む。

図９に示されるツリーデータ構造に基づき、システムは、５、６、及び７のファイル識別子を有するノードを操作８１０において修正したことを識別し、図９中の参照番号９８０によって示されるような、修正されたコンテンツアイテムのリストにこれらのノードを追加した可能性がある。操作８１５において、システムは、修正されたコンテンツアイテムのリスト中のノードへの修正リストを決定する。リモートツリー９１０及び同期ツリー９５０の比較によって示されるように、ノード９１４、９１６、及び９１８をリモートツリー９１０に追加した。より具体的に、図９中の参照番号９８２によって示されるように、ファイル識別子６及び名前「Ｂａｒ」を有するノード９１６を子として、ファイル識別子５を有するノード９１４に追加した。これは、参照番号９８２中の「Ａｄｄ（６，５，Ｂａｒ）」エントリによって表される。ファイル識別子７及び名前「Ｂｙｅ」を有するノード９１８を子として、ファイル識別子５を有するノード９１４に追加した。これは、参照番号９８２中の「Ａｄｄ（７，５，Ｂｙｅ）」によって表される。ファイル識別子５及び名前「Ｆｏｏ」を有するノード９１４を子として、ファイル識別子１を有するルートノード９１２に追加した。これは、参照番号９８２中の「Ａｄｄ（５，／ｒｏｏｔ，Ｆｏｏ）」エントリによって表される。

操作８２０において、システムは、ノード９１４の追加修正が依存性を有さず、結果としてブロックされていないと判定する。その結果、操作８２５において、システムは、ノード９１４と関連する修正（例えば、参照番号９８２中の「Ａｄｄ（５，／ｒｏｏｔ，Ｆｏｏ）」エントリによって表される修正）をブロックされていないアクションリストに追加する。これは、図９中の参照番号９８４に示される。一方、参照番号９８２中の「Ａｄｄ（６，５，Ｂａｒ）」及び「Ａｄｄ（７，５，Ｂｙｅ）」エントリによって表されるノード９１６及び９１８についての修正は、最初に発生する「Ａｄｄ（５，／ｒｏｏｔ，Ｆｏｏ）」によって表される修正に依存している。換言すれば、ノード９１４を追加するまで、ノード９１６及び／またはノード９１８を追加することができない。その結果、これらの修正を図９中の参照番号９８６によって示されるブロックされたアクションリスト中に含む。

図８の方法８００に戻り、操作８３５において、システムは、修正セットをブロックされていないアクションリストから選択し、選択された修正セットに基づき操作セットを生成することができる。操作セットは、サーバ状態及びファイルシステム状態を収束させるように設定される。生成される操作セットは、ブロックされていないリストから選択された修正セットに依存する。例えば、選択された修正セットが図９中のノード９１４と関連する追加修正（例えば、参照番号９８４中の「Ａｄｄ（５，／ｒｏｏｔ，Ｆｏｏ）」エントリによって表される修正）を含む場合に、生成された操作セットは、追加されたコンテンツアイテムをコンテンツ管理システムから取得すること、及びそれをクライアントデバイスのローカルファイルシステムに追加することを含むことができる。

いくつかの実施形態により、システムは、すべての修正を、ブロックされていないアクションリストから選択し、１つ以上の操作セットを生成することができる。しかしながら、いくつかのシナリオにおいて、ブロックされていないリスト中の修正数は、かなり多い可能性があり、すべての修正を処理するために必要とされる計算リソース（例えば、メモリ及び処理時間）は、相当である。これらの技術的な負担を軽減させるために、システムは、インクリメンタルに処理するためにブロックされていないアクションリスト中で、より少ない修正セットを選択することができる。例えば、システムは、修正の最初の、または上位のＸ番またはパーセントを選択し、操作を生成することができる。プロセスのさらなる繰り返しにおいて、ブロックされていないリスト中のリネーム修正を処理することができる。

いくつかの実施形態において、ブロックされていないリスト中の修正を処理についてランク付けすることができる。これらの修正は、例えば、修正タイプ（例えば、削除修正を追加修正より優先的に扱う）、この修正と関連するメタデータ（例えば、より小さいサイズのコンテンツアイテムの追加修正をより大きいサイズのコンテンツアイテムの追加修正より優先的に扱い、より大きいサイズのコンテンツアイテムの削除修正をより小さいサイズのコンテンツアイテムの削除修正より優先的に扱うなど）に基づきランク付けされることができる。

これらのランク付けルールは、システムによって格納されることができ、コンテンツ同期のためにさまざまなパフォーマンス目標を達成するように設計されることができる。例えば、新規のコンテンツアイテムを追加することができる前に、潜在的に限られたストレージスペースをユーザに対してできるだけ多く解放するために、削除修正を追加修正より優先的に扱うことができる。追加されるコンテンツアイテムの数に関してできる限りの進捗をできるだけ早く提供するために、より多いコンテンツアイテムより、より少ないコンテンツアイテムの追加を優先的に扱うことができる。

操作８３５において、システムは、操作セットをコンテンツ管理システム及び／またはクライアントデバイスに提供することができる。上述されるように、コンテンツ管理システムによって実行されるアクションと関連する修正を、クライアントデバイスに反映しない場合がある。その結果、このシナリオにおいて、システムは、クライアントデバイス上に格納されるコンテンツアイテム上で動作し、サーバ状態及びファイルシステム状態を収束させるように設定されるクライアント操作セットを生成することができ、操作８３５における実行のために、このクライアント操作セットをクライアントデバイスに提供することができる。

一方、クライアントデバイスによって実行されるアクションと関連する修正を、コンテンツ管理システムに反映しない場合がある。その結果、このシナリオにおいて、システムは、コンテンツ管理システムによって格納されるコンテンツアイテム上で動作し、サーバ状態及びファイルシステム状態を収束させるように設定されるサーバ操作セットを生成することができ、操作８３５における実行のために、このサーバ操作セットをコンテンツ管理システムに提供することができる。

いくつかの事例において、両方の事例は、真であることができ、操作８３５において、クライアント操作セット及びサーバ操作セットを生成し、それらの意図されたレシピエントに提供することができる。また、操作セットは、ツリー制約が維持されていることを確保するために、複数のチェックを含むことができる。例えば、操作セットは、図６に関して考察されるように、さまざまな競合または制約を解消することができる。

操作セット（複数可）を意図されたレシピエント（複数可）に提供すると、方法は、操作８０５に戻り、新規の修正データを待機することができる。例えば、図９に示されるシナリオに関して、操作セットは、ノード９１４と関連するコンテンツアイテムをコンテンツ管理システムから取得すること、及びそれをクライアントデバイスのローカルファイルシステムに追加することを備えることができる。これは、ローカルツリー（図９に示されない）及び同期ツリー９５０中のノード９１４に対応するノードの追加をもたらす。図８のプロセス８００の次の繰り返しに、参照番号９８２における「Ａｄｄ（６，５，Ｂａｒ）」及び「Ａｄｄ（７，５，Ｂｙｅ）」エントリによって表されるノード９１６及びノード９１８の追加修正は、それらの親ノード９１４を同期ツリーに既に追加したため、もはやブロックされない。その結果、参照番号９８２における「Ａｄｄ（６，５，Ｂａｒ）」及び「Ａｄｄ（７，５，Ｂｙｅ）」エントリによって表されるノード９１６及びノード９１８の追加修正は、ブロックされていないアクションリストに追加され、サーバ状態及びファイルシステム状態を収束させるように設定される１つ以上の操作セットを生成するために使用されることができる。

操作セット（複数可）は、サーバ状態及びファイルシステム状態のインクリメンタルな収束のために１つ以上のステップを提供することができる。インクリメンタルなプロセスを実装することにより、ときとしてさらに複雑になる可能性があるが、インクリメンタルなプロセスは、処理時間における短縮、及び必要とされるメモリにおける減少を達成することができる。これらの、また他の最初の技術的な改善は、さらなる技術的な改善に当然通じる。例えば、処理時間が短縮するため、もはや用いられない、または古い、ある特定の修正を行うクライアントデバイスまたはコンテンツ管理システムからの追加の変更の尤度も低下させる。

図９に関して、説明目的のために、コンテンツアイテム、修正、アクション、またはファイル識別子のさまざまなグループ化をリストとして記述する。他のタイプのデータ構造も互換性がある。例えば、ブロックされていないアクションリストは、データをソートし続け、対数時間中に検索、順次アクセス、挿入、及び削除を可能にするために、Ｂツリーデータ構造として実装されることができる。

スケジューラ
いくつかの実施形態において、クライアント同期サービスは、サーバ状態及びファイルシステム状態を収束させるように設定される操作セットまたは操作シーケンスを生成し、これらの操作を実行のためにコンテンツ管理システムまたはクライアントデバイスに提供することができる。しかしながら、いくつかのシナリオにおいて、クライアントデバイスのファイルシステム上での変更、またはコンテンツ管理システム上での変更は、操作セットが実行プロセス中である間に、生成された操作セットが古くなる、またはもはや用いられなくなる原因となる可能性がある。さまざまな実施形態は、これらの課題及び他の技術的な課題への技術的な解決策を提供することに向けられる。例えば、クライアント同期サービスは、クライアントデバイスのファイルシステム上での変更、またはコンテンツ管理システム上での変更を監視し、必要に応じてクライアントデバイス及び／またはコンテンツ管理を更新するように設定され得る。さらに、クライアント同期サービスは、操作の同時発生的な実行を可能にすることによって、パフォーマンスを改善し、処理時間を短縮するように設定され得る。

いくつかの実施形態により、図２に示されるクライアント同期サービス１５６のプランナ２２５は、順序付けされていない操作セットからなるプラン、または操作プランを生成することができる。プラン内のすべての操作は、依存性を有さず、結果として、別々のスレッドで、またはいずれかの順序で同時に実行され得る。プランにおけるこれらの操作は、いくつかの実施形態により、状態及びツリーデータ構造を収束させるために、コンテンツ管理システム及び／またはクライアントデバイスによって行われることができる抽象的な命令である。例示的な命令は、コンテンツアイテムのリモートもしくはローカル追加、コンテンツアイテムのリモートもしくはローカル削除、コンテンツアイテムのリモートもしくはローカル編集、またはコンテンツアイテムのリモートもしくはローカル移動を含むことができる。

図２に示されるクライアント同期サービス１５６のスケジューラ２３０は、プランナ２２５から操作プランを受信し、プラン中の操作の実行を管理し、プランが更新されたか、変更されたかどうかを判定し、更新された、または変更されたプランの実行を管理するように設定され得る。例えば、スケジューラ２３０は、ファイルシステムインタフェース２０５及びサーバインタフェース２１０を調整し、プラン中の操作を実装するために必要とされるタスク及びステップを実行することができる。これは、ファイルシステムもしくはコンテンツ管理システムから確認、またはネットワーク接続がないときの、もしくはコンテンツアイテムがいくつかの他のアプリケーションによってロックされているときの再試行のハンドリングなどの、エラーハンドリングアクティビティを受信することを含むことができる。

各操作は、タスクと称されるスクリプトまたはスレッドによって実装されることができる。タスクは、関連した操作のアプリケーションを調整し、この操作を実装するために必要とされる１つ以上のステップを含むことができる。例えば、「ローカル追加操作」は、コンテンツアイテムをクライアントデバイスのローカルファイルシステムに追加し、結果として、サーバ状態及びファイルシステム状態を同期させるために、コンテンツアイテムをコンテンツ管理システムに追加したことを示すことができる。その結果、ローカル追加操作は、ローカル追加操作を実装するために必要とされる１つ以上のステップを含む「ローカル追加タスク」と関連付けられることができる。これらのステップは、新規のコンテンツアイテムのコンテンツ管理システムに通知すること、１つ以上のデータブロック中のコンテンツアイテムをコンテンツ管理システムにアップロードすること、すべてのデータブロックをコンテンツ管理システムによって受信したことを確認すること、コンテンツアイテムが破損していないことを確かめること、コンテンツアイテムについてのメタデータをコンテンツ管理システムにアップロードすること、及びコンテンツアイテムの追加をコンテンツ管理システムにおける適切な位置にコミットすることのうちの１つ以上を備えることができる。

タスクは、実行を開始し、他のイベントの完了を待つ間に良定義ポイントでサスペンドし、イベントが発生したときに再開し、最終的に終了することができる。いくつかの実施形態により、スケジューラ２３０は、タスクをキャンセルする、再生成する、または置換するように設定される。例えば、サーバ状態またはファイルシステム状態への変更に基づき、タスクは、それが実行される前に古くなる可能性があり、スケジューラ２３０は、それが実行される前に古くなったタスクをキャンセルすることができる。

上述されるように、プランナ２２５は、１セットのツリーデータ構造（例えば、リモートツリー、同期ツリー、及びローカルツリー）に基づき操作プランを生成することができる。経時的に、プランナ２２５は、ツリーデータ構造のステータスに基づき操作プランを生成し続ける。ツリーデータ構造がサーバ状態及びファイルシステム状態の状態を反映するために変更される場合に、プランナ２２５は、前のプランと異なる新規に更新されたプランも生成することができる。スケジューラ２３０は、プランナ２２５によって生成される各操作プランを実行する。

いくつかのシナリオにおいて、後のプランの操作における変更は、意図されていないビヘイビアが実行プロセス中である前のプラン中の操作と競合する原因となる可能性がある。例えば、第一プラン中の操作を実行している場合に、これらの操作のうちの１つ以上は、第二プランにおいてキャンセルされる（または存在していない）。図示するように、図１０は、時間ｔ１に、リモートツリーによって表されるサーバ状態、及びローカルツリーによって表されるファイルシステム状態が、すべてマッチングするリモートツリー、同期ツリー、及びローカルツリーによって示されるように同期している例示的なシナリオを示す。この同期した状態に基づき、プランナ２２５は、ｔ１で操作（例えば、空のプラン）を含まないプランを生成することができる。

クライアントデバイス上のユーザは、コンテンツアイテムＡをローカルファイルシステムから削除する、またはクライアント同期サービス１５６によって管理されるフォルダからコンテンツアイテムＡを移動させることができ、これは、時間ｔ２におけるノードＡのローカルツリーからの除去によって反映される。プランナ２２５は、時間ｔ２にツリーデータ構造の状態に基づき操作ＬｏｃａｌＤｅｌｅｔｅ（Ａ）を含むプランを生成することができる。スケジューラ２３０は、ＬｏｃａｌＤｅｌｅｔｅ（Ａ）操作を実装するために必要とされるタスクまたはステップを開始することができる。これらのステップは、コンテンツアイテムＡを削除する命令をコンテンツ管理システムに送信することを備えることができる。

コンテンツアイテムＡを削除する命令をコンテンツ管理システムに送信した後に、クライアントデバイス上のユーザは、コンテンツアイテムＡの削除を取り消す、またはコンテンツアイテムＡを移動させて前の位置に戻すことができる。時間ｔ３にこの新規のアクションに基づきローカルツリーを更新し、プランナは、操作を含まない空である新規のプランを生成することができる。もう一度、ツリーデータ構造は、マッチングし、システムは、時間ｔ３に同期した状態にある。

しかしながら、コンテンツアイテムＡを削除する命令をコンテンツ管理システムに送信したため、コンテンツ管理システムは、コンテンツアイテムＡをサーバ状態から削除する。スケジューラ２３０がコンテンツアイテムＡの削除をキャンセルすることを試行する可能性があるが、これらの命令を既に送信し、コンテンツ管理システムによって完了した可能性がある。サーバにおけるこの変更をクライアント同期サーバ１５６に通信し、時間ｔ４にノードＡを削除することによってリモートツリーを更新する。プランナ２２５は、リモートツリー中の変更、及びリモートツリーと同期ツリーとの間の差異を認め、コンテンツアイテムＡをサーバ状態において除去したと判定することができる。その結果、プランナ２２５は、時間ｔ４におけるＲｅｍｏｔｅＤｅｌｅｔｅ（Ａ）操作をプランに作成する。サーバ状態及びファイルシステム状態を同期させる試みの中で、コンテンツアイテムＡをクライアントデバイス及びローカルツリーから最終的に削除する。

問題を起こすような方法で、コンテンツアイテムＡのサーバ状態からの除去、ＲｅｍｏｔｅＤｅｌｅｔｅ（Ａ）操作の生成、及びコンテンツアイテムＡのファイルシステム状態からの結果として起きる除去は、すべてが意図されず、ユーザに対して将来においてさらなる問題を引き起こす可能性がある。さらに、いくつかの事例において、アプリケーションまたはプロセスも、コンテンツアイテムにアクセスすることができ、意図しない同期ビヘイビアは、次々と追加の技術的な問題を引き起こす可能性がある。さまざまな実施形態は、サーバ状態とファイルシステム状態との間のコンテンツアイテムの同期における意図しない結果を防ぐことに向けられる。

いくつかの実施形態により、もはや操作プランにない古くなった操作についてのタスクをキャンセルするときに、スケジューラ２３０は、他のタスクの実行を開始することに取りかかる前に、キャンセルが完了するのを待機することができる。例えば、スケジューラ２３０は、他のタスクを進める前にクライアントデバイスまたはコンテンツ管理システムからキャンセルの確認を受信するために待機することができる。スケジューラ２３０は、タスクを開始したかどうかを判定することができ、そしてタスクを開始していない場合に、スケジューラは、タスクをキャンセルし、タスクがもはや実行を待機していないことを確認することができる。タスクを開始した場合に、この確認は、クライアントデバイスまたはコンテンツ管理システムからのものであり、キャンセルされたタスクと関連するすべてのステップが取り消されたことをスケジューラに通知することができる。いくつかの実装に従い、スケジューラ２３０は、タスクを開始するとタスクのキャンセルを許可しない。これは、すべてのタスク、またはタスクもしくはタスクタイプ（例えば、サーバ状態との同期のためにファイルシステム状態上の更新をコンテンツ管理システムに送信するコミットタスク）のある特定のサブセットについての事例にあり得る。

パフォーマンスを改善し、タスクの同時実行、及びタスクのキャンセルを可能にするために、スケジューラ２３０は、そのうえ、第一操作プランと更新された第二操作プランとの間の差異に基づきタスクの実行及びキャンセルを管理するように設定され得る。図１１は、本発明の技術のさまざまな実施形態による、２つの操作プランの例示的なベン図１１００表現を示す。プランナ２２５は、第一操作セットを含むプラン１ １１１０を生成し、ツリーデータ構造への更新を受信し、第二操作セットを含む更新されたプラン２ １１２０を生成することができる。

プラン１ １１１０及びプラン２ １１２０は、ベン図１１００の部分１１３０によって表される複数の共通操作を共有することができる。また、プラン１ １１１０及びプラン２ １１２０は、共通ではない複数の操作を共有することができる。例えば、プラン２ １１２０中にはないプラン１ １１１０中の操作は、古く、プランナ２２５によって検出されるツリー構造への更新に基づき、もはや最新ではない。プラン１ １１１０のこれらの古い操作は、ベン図１１００の部分１１４０によって表される。プラン１ １１１０中にないプラン２ １１２０中の新規の操作は、部分１１５０によって表される。プラン１ １１１０とプラン２ １１２０との間の差異及び共通性を表す、部分１１３０、１１４０、及び１１５０のそれぞれは、ツリーデータ構造中に反映されるサーバ状態及びファイルシステム状態への更新に依存する、操作を含まなくても、多くの操作を含んでもよい。

部分１１４０中の操作は、もはや最新のプランにはないため、スケジューラ２３０は、これらの操作と関連するタスクをキャンセルすることができる。意図されない同期ビヘイビアを防ぐために、プラン１中にはないプラン２中の（例えば、部分１１５０中の）操作と関連するタスクは、部分１１４０中の操作と関連するタスクのキャンセルが完了するまで延期される。しかしながら、各プラン中の操作は、同時に実行されることができるように設定されるため、部分１１３０によって表されるプラン１及びプラン２の共通部分中の操作と関連するタスクは、それらの完了を待機する必要なしに、部分１１４０中の操作と関連するタスクのキャンセルと同時に実行されることができる。部分１１４０と関連するタスクの同時キャンセル、及び部分１１３０と関連するタスクの実行を可能にすることによって、利用可能な計算リソースのさらに効率的な使用だけではなく、処理時間の短縮も達成することができる。

図１２は、本発明の技術のさまざまな実施形態による、操作プラン中の変更を管理する例示的な方法を示す。本明細書に記載されるこれらの方法及びプロセスが特定の順序で、ある特定のステップ及び操作によって示されることができるが、同様の、もしくは代替の順序で、または並列して実行される追加の、より少ない、または代替のステップ及び操作は、別段の定めがない限り、さまざまな実施形態の範囲内にある。この方法１２００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などのシステムによって実装されることができる。

このシステムは、コンテンツ管理サービスと関連するコンテンツアイテムについて、コンテンツ管理システム及び／またはクライアントデバイスから更新を受信するように設定されることができる。例えば、システムは、コンテンツ管理サービスによって格納されるコンテンツアイテムについてのサーバ修正データを受信し、このサーバ修正データに基づき、リモートツリーを更新することができる。このリモートツリーは、コンテンツ管理システムによって格納されるコンテンツアイテムについてのサーバ状態を表す。また、システムは、クライアントデバイス上に格納されるコンテンツアイテムについてのクライアント修正データを受信し、このクライアント修正データに基づきローカルツリーを更新することができる。ローカルツリーは、クライアントデバイス上に格納されるコンテンツアイテムについてのファイルシステム状態を表す。

操作１２０５において、システムは、コンテンツ管理システムと関連するサーバ状態、及びクライアントデバイスと関連するファイルシステム状態を収束させるように設定される第一操作セットを受信することができる。例えば、システムは、同期ツリーとリモートツリーとの間の、または同期ツリーとローカルツリーとの間の差異を識別し、これらのツリー間のいずれかの差異に基づき第一操作セットを生成することができる。同期ツリーは、サーバ状態とファイルシステム状態との間の既知の同期状態を表す。

システムは、第一操作セットを実装し始めることができる。例えば、いくつかの事例において、これらの操作は、実行のためにコンテンツ管理システム及び／またはクライアントデバイスに送信されるフォーマット準備中である。他の事例において、これらの操作は、システムによって管理されることができる１つ以上のタスク、スクリプト、または実行スレッドに変換されることができる。システムは、サーバ状態及びファイルシステム状態を収束させるために、タスク、スクリプト、または実行スレッドに従い、コンテンツ管理システム及び／またはクライアントデバイスとインタフェースすることができる。

この時間中に、システムは、コンテンツ管理サービスと関連するコンテンツアイテムについての修正データをコンテンツ管理システム及び／またはクライアントデバイスから受信し続けることができる。修正データに基づき、システムは、リモートツリーまたはローカルツリーを更新し、これらのツリーデータ構造への更新に基づき第二操作セットを生成することができる。操作１２１０において、システムは、第二操作セットを受信することができる。

操作１２１５において、システムは、もしあれば、第二操作セット中にはない第一操作セット中の第一操作を識別する。システムが第二操作セット中にはない第一操作セット中の操作を見いだす場合に、この操作は、修正データ中に指定される変更の結果として、古く、今は使われていない可能性がある。その結果、システムは、操作１２２０において第一操作のキャンセルを開始する。第一操作のキャンセルは、複数のステップ、これらのステップの複数の確認受信、及び自明でない処理時間量を有することができる。

操作１２２５において、システムは、もしあれば、第一操作セット及び第二操作セットの両方の中に含まれる第二操作を識別する。このシステムが第一操作セット及び第二操作セットの両方の中で操作を見いだす場合に、この操作は、修正データ中で指定された変更にもかかわらず、まだ有効であり得る。さらに、両方の操作セット中の操作がセット中の他の操作について同時に、またはいずれかの順序で実行されることができるように設定されることから、第二操作は、第一操作がキャンセルされていながら、実行を継続することができる。その結果、システムは、第一操作がキャンセルを完了するのを待機せずに、操作１２３０において第二操作の実行を開始する。

操作１２３５において、システムは、もしあれば、第二操作セット中にあるが第一操作セット中にない第三操作を識別する。このシステムが第一操作セット中にない操作を第二操作セット中に見いだす場合に、この操作は、修正データ中で指定される変更の結果として、新規の操作であり得る。意図されない結果を防ぐために、システムは、第一操作のキャンセルの完了について待機を開始する。操作１２４０において、システムは、第一操作がキャンセルを完了したと判定し、結果として、操作１２４５において第三操作の実行を開始することができる。

ローカルツリーの更新
上述されるように、ローカルツリーは、クライアントデバイスのローカルファイルシステム上に格納されるコンテンツアイテムについてのファイルシステム状態を反映するように設定される。例えば、図２中のクライアント同期サービス１５６のファイルシステムインタフェース２０５は、クライアントデバイスのローカルファイルシステムに変更（例えば、１つ以上のコンテンツアイテムの追加、削除、移動、編集、またはリネーム）を行い、ローカルファイルシステムへの変更を検出し、ローカルファイルシステムへの変更に基づきローカルツリーを更新するように設定される。これらの変更は、ファイルシステム上でのユーザアクション、クライアントデバイス上で実行する第三者のアプリケーション、またはファイルシステム状態をサーバ状態と同期させるクライアント同期サービスによって引き起こされることができる。

本発明の技術のさまざまな実施形態は、ローカルファイルシステムへの変更に基づきローカルツリーを更新することへのさまざまな技術的な解決策を提供する。ローカルツリーは、他のツリーデータ構造に加えて、さまざまな実施形態においてクライアントデバイスとコンテンツ管理システムとの間の同期プロセスにきわめて重要である。例えば、ローカルツリーへの更新が行われると、残りのシステムは、この更新に反応し、いくつかの事例では、コンテンツ管理システムにおいてサーバ状態にローカルツリーへの変更を同期させ、適用することができる。その結果、ローカルツリーが更新される方法について注意することが重要である。

例えば、ユーザがファイルをＡ．ｔｘｔからＢ．ｔｘｔにリネームする場合に、いくつかの事例で、システムは、コンテンツアイテムＡ．ｔｘｔの削除、及びコンテンツアイテムＢ．ｔｘｔの追加を検出することができる。これにより、Ａ．ｔｘｔについてのノードをローカルツリー上で削除させ、Ｂ．ｔｘｔについてのノードを追加させることができる。ただし、これにより、しばらくの間、リネームされたコンテンツアイテムについてのノードがローカルツリー上に存在しない事例をもたらす。これにより、Ｂ．ｔｘｔについてのノードを追加する前に、クライアントデバイス、クライアントアプリケーション、及び／またはクライアント同期サービスが遮断される、失敗する、またはリブートする可能性があるため、データ整合性への著しい損傷の原因となり、結果として、ユーザのコンテンツアイテムを損失する。次いで、ユーザのコンテンツアイテムの損失は、コンテンツ管理システムにおいてサーバ状態に同期することができる。同様のリスクは、ある位置から別の位置にコンテンツアイテムを移動させるユーザと関連付けられる。

加えて、ローカルファイルシステムへの変更は、順不同で検出されることができ、必ずしもユーザまたはアプリケーションによる単一のアクションにすべて関連していない多数の変更を含む可能性がある。また、クライアントアプリケーションは、ローカルファイルシステムへ多くの変更が行われている間、オフにされる、または実行されないことができる。起動時に、クライアントアプリケーションは、ローカルファイルシステムをクロールし、それをローカルツリーと比較し、クライアントアプリケーションがオフであった間に発生したローカルファイルシステムへの変更を判定することができる。これらの変更は、適切な経時的な順序にはない可能性がある。また、これらの因子は、ローカルツリーが注意深く更新されない場合に、意図されない同期ビヘイビアをもたらす可能性がある。

制約セットを使用して、ツリーデータ構造の整合性を確保し、意図されない同期ビヘイビアから保護することができる。これらの制約は、例えば、（１）ツリー中のすべてのノードがファイル識別子（ｆｉｌｅＩＤ）と関連付けられること、（２）ツリー中のすべてのノードが一意のファイル識別子を有すること、（３）空ではない親ノードが削除され得ないこと、（４）削除されたノードがクライアント同期サービスによって管理される位置から実際に削除される（移動するだけではなく）、または除去されること、（５）すべての兄弟ノードが大文字小文字に関係なく一意のファイル名を有すること、（６）すべてのノードが既存の親を含まなければならないこと、及び／または（７）すべての兄弟ノードがそれらの親のファイルＩＤ（ＤｉｒＦｉｌｅＩＤ）に一致することを備えることができる。いくつかの実装において、上記の制約サブセットを使用することができる、代替の、もしくは追加の制約を使用することができる、または組み合わせを使用することができる。制約の異なる１セットまたは複数セットを他のツリーデータ構造に適用することができながら、制約の１セットをすべてのツリーデータ構造、またはツリーデータ構造の１サブセットのみに適用することができる。

ローカルファイルシステムへの変更を検出するときに、この変更を制約セットに対してチェックすることができる。変更が制約セットと一貫性がある場合に、ローカルツリーは、ローカルファイルシステムへの変更に基づき更新されることができる。変更が制約のうちの１つに違反する場合に、この制約は、追加の条件が満たされる必要がある場合がある。例えば、制約は、これらの変更をローカルツリーに適用することができる前に追加のパスが観測される、もしくはファイルイベントが発生する、１つ以上の修復ステップが実行される、または組み合わせをする必要がある場合がある。ある特定の制約（例えば、修復ステップが行われる、追加のパスが観測される、またはファイルイベントが発生する）を満たすためにアクションが発生する場合に、他の制約に違反している可能性がある。その結果、すべての制約を満たすまで、制約セットを連続してチェックすることができる。これらの制約を満たすと、ファイルイベントと関連する変更をローカルツリーに適用することができる。

ファイルイベントは、ローカルファイルシステム上で検出される変更に応答してクライアント同期サービス１５６によって検出されることができる。各ファイルイベントは、コンテンツアイテム（例えば、コンテンツアイテムについてのファイル識別子）、及びイベントタイプ（例えば、追加、移動、削除、または編集イベントタイプ）と関連付けられることができる。また、各ファイルイベントは、関連したコンテンツアイテムのパスまたは位置を指定するパスと関連付けられることができる。検出されたファイルイベントと関連するパスは、クライアント同期サービスによって観測されるパスセットを投入することができる。しかしながら、いくつかの事例において、これらのパスは、１つ以上の制約違反によってファイルイベントに対応しないと観測されることができる。

図１３は、本発明の技術のさまざまな実施形態により、例示的なシナリオを示す。特に、図１３は、ファイルイベント１３１５を検出するときのローカルツリー１３１０の現在の状態を示す。例えば、クライアント同期サービスは、ファイルシステムをローカルツリー１３１０と比較し、ｐａｔｈ／ｒｏｏｔ／ａ／ｂ／ｃ．ｔｘｔにおいてファイルシステムにコンテンツアイテムが存在するが、／ｒｏｏｔ／ａ／ｂ／ｃ．ｔｘｔにおいてコンテンツアイテムについてのノードがローカルツリー１３１０に存在しないことを見いだすことができる。その結果、ローカルツリー１３１０上に必要とされる／ｒｏｏｔ／ａ／ｂ／ｃ．ｔｘｔにおけるノードの追加を指定する、ファイルイベント１３１５を生成することができる。

クライアント同期サービスは、更新のためにファイルイベント１３１５を観測されたパスセットに追加し、観測されたパス１３２０が制約セットと一貫性があるかどうかを判定し、観測されたパス１３２０またはファイルイベント１３１５がセット中の制約のうちの１つに違反することを見いだすことができる。図１３に示されるシナリオにおいて、観測されたパス１３２０は、「すべてのノードが既存の親を有さなければならない」制約に違反する。より具体的に、／ｒｏｏｔ／ａ／ｂ／ｃ．ｔｘｔに追加されるノードの親は、存在せず、ノードの祖父母も存在しない。その結果、追加のパス（親及び祖父母ノード）は、変更をローカルツリーに適用する前に観測されなければならない。

クライアント同期サービスは、更新のために、追加のファイルイベントを検出し、それらを観測されたパスセットに追加することができる。例えば、クライアント同期サービスは、／ｒｏｏｔ／ａのファイルイベント、及びＡｄｄ／ｒｏｏｔ／ａ／ｂのファイルイベントを検出し、／ｒｏｏｔ／ａのパス及びＡｄｄ／ｒｏｏｔ／ａ／ｂのパスを観測されたパスセットに追加することができる。これらのパスを観測すると、違反された制約を満たす（そして他の制約に違反していない）。結果として、更新のために観測されたファイルイベントのすべてをローカルツリーに適用することができる。より具体的に、ノードを／ｒｏｏｔ／ａに追加することができ、ノードを／ｒｏｏｔ／ａ／ｂに追加することができ、ノードを／ｒｏｏｔ／ａ／ｂ／ｃ．ｔｘｔに追加することができる。その結果、クライアント同期サービスは、アトミックまたはユニタリ更新について関連したファイルイベントを合わせてグループ化する。さらに詳細に記載されるように、ローカルツリーへのアトミック更新について関連したファイルイベントを合わせてグループ化することにより、ツリーデータ構造の整合性を向上させ、意図されていない同期ビヘイビアから保護し、ローカルツリーにおける中間状態を防ぐ。

図１４は、本発明の技術のさまざまな実施形態により、ローカルツリーを更新する例示的な方法を示す。本明細書に記載される、これらの方法及びプロセスが特定の順序で、ある特定のステップ及び操作によって示されることができるが、同様の、もしくは代替の順序で、または並列して実行される追加の、より少ない、または代替のステップ及び操作は、別段の定めがない限り、さまざまな実施形態の範囲内にある。この方法１４００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などのシステムによって実装されることができる。

操作１４０５において、システムは、ファイルイベントを検出し、このファイルイベントと関連するパスを観測されたパスセットに追加する。例えば、起動時に、システムは、クライアントデバイスのファイルシステムをクロールし、ファイルシステム上で情報を収集し、この収集された情報を、ファイルシステムの最新の既知の状態を表すローカルツリーと比較することができる。システムは、クライアントデバイスのローカルツリーとファイルシステムとの間の差異を識別し、これらの識別された差異に基づき複数のファイルイベントを生成することができる。代替に、または加えて、システムは、実行時間中にファイルシステムを監視し、ローカルツリー中に反映されていないファイルシステムに行われた変更を検出し、これらの検出されたファイルシステムへの変更に基づきファイルイベントを生成することができる。これらの生成されたファイルイベントは、システムによって行われるファイルシステムについての観測と考えられることができる。

操作１４１０において、システムは、ローカルツリー制約セットに対して観測されたパスセットをチェックし、観測されたパスのいずれかがローカルツリー制約に違反するかどうかを判定する。観測されたパスのいずれもローカルツリー制約セット中の制約のいずれかに違反していない場合に、操作１４３５において、観測されたパスセットを使用して、ローカルツリーを更新することができる。

各制約違反は、制約を満たすように設定される修復と関連付けられることができる。例えば、「すべてのノードが既存の親を含まなければならない」制約の違反は、図１３に示されるように、親ノードの追加が観測される要件と関連付けられることができる。

他の事例において、制約違反は、違反を解消して制約を満たすアクションが行われる必要がある場合がある。例えば、ユーザがファイルシステム中のコンテンツアイテムをコピーし、既存のコンテンツアイテムの新規のコピーを作成するときに、この新規のコンテンツアイテムは、元のコンテンツアイテムと同一のファイル識別子を有することができる。システムは、新規のコピーの追加を観測することができるが、この新規のコピーは、「ツリー中のすべてのノードが一意のファイル識別子を有する」という制約に違反する。この制約違反は、ローカルツリーを更新する前に、コンテンツアイテムについての新規のファイル識別子を要求する修復ステップ、及び新規のコンテンツ識別子をコンテンツアイテムに割り当てる修復ステップ、したがって、この違反を解消する修復ステップ、及び制約を満たす修復ステップと関連付けられることができる。その結果、ローカルツリーは、いずれかの制約に違反する状態にまったくない。

別の実施例において、ユーザは、大文字と小文字が異なっているが、ファイル名が既に存在するファイルシステムの位置の中に新規のコンテンツアイテムを作成することができる。図示するように、ユーザは、ファイル「ａ．ｔｘｔ」が同一のファイルシステムパスに関して既に存在するときに、「Ａ．ｔｘｔ」と名付けられたファイルを作成することができる。クライアントデバイスのオペレーティングシステムは、これを許可する場合があるが、クライアント同期サービスは、許可しない場合がある。システムは、新規のコンテンツアイテムの追加を観測することができるが、この新規のコンテンツアイテムは、「すべての兄弟ノードが大文字小文字にかかわらず一意のファイル名を有する」という制約に違反する。この制約違反は、大文字小文字の競合が存在することを示す新規のコンテンツアイテムの名前を編集する修復ステップと関連付けられることができる。例えば、「Ａ．ｔｘｔ」ファイルを、「Ａ（ｃａｓｅ ｃｏｎｆｌｉｃｔ）．ｔｘｔ」にリネームすることで、違反を解消し、制約を満たすことができる。ファイルイベント及びパスを観測されたパスセットから除去し、「Ａ（ｃａｓｅ ｃｏｎｆｌｉｃｔ）．ｔｘｔ」コンテンツアイテムの追加のための新規のファイルイベントを検出するようなプロセスを再開することができる、または「Ａ．ｔｘｔ」のためのファイルイベントを更新して新規の名前「Ａ（ｃａｓｅ ｃｏｎｆｌｉｃｔ）．ｔｘｔ」を反映することができる。

１つ以上の観測されたパスが１つ以上の制約に違反する場合に、システムは、違反された制約が操作１４１５において行われる修復アクションを必要とするかどうか、または違反された制約が操作１４２５において観測される追加のパスを必要とするかどうかを判定することができる。追加の修復アクションを必要とする場合に、操作１４２０において、システムは、追加の修復アクションを実行することができる。追加のパスが観測される場合に、操作１４３０において、システムは、追加のファイルイベントを検出し、ファイルイベントと関連するパスを操作１４３０において観測されたパスセットに追加することができる。

次いで、プロセスは、操作１４１０に戻り、観測されたパスセットがローカルツリー制約に違反するかどうかを判定する。いくつかの事例において、修復アクションの実行、検出される新規のファイルイベント、または観測されたパスセットに追加されるパスは、ローカルツリーへの更新を実行し得る前に、解消されなければならない１つ以上の制約の新規の違反の原因となる場合がある。その結果、ローカルツリー制約のさらなる違反が存在しなくなるまで、プロセスを繰り返すことができる。次いで、プロセスは、操作１４３５に進行することができ、そこでシステムは、観測されたパスセットに基づきローカルツリーを更新することができる。

移動またはリネーム変更に関するローカルツリーの更新
いくつかの実施態様により、ローカルファイルシステムについてのコンテンツアイテム上での移動またはリネーム操作は、追加の技術的な問題をもたらす可能性がある。例えば、いくつかの事例において、ファイルまたはフォルダなどのコンテンツアイテムがユーザまたはアプリケーションによって古い位置から新しい位置に移動するときに、操作は、コンテンツアイテムの古い位置からの削除、及び新しい位置への新しいコンテンツアイテムの追加としてファイルシステムまたはクライアントアプリケーションに出現することができる。同様に、古いファイル名から新しいファイル名へのコンテンツアイテムのリネームは、古いファイル名を有するコンテンツアイテムの削除、及び新しいファイル名を有する新しいコンテンツアイテムの追加として出現することができる。さらに、コンテンツアイテムが多くの他のコンテンツアイテムの親であり、潜在的に深く複雑なツリー構造を有するフォルダである場合に、コンテンツアイテムの移動またはリネームは、すべての子孫コンテンツアイテムのそれらの古い位置またはパスから新しい位置またはパスへの削除としても出現することができる。

上述されるように、コンテンツアイテムを新しい位置に、または新しい名前によって再追加する前に、ローカルツリーからコンテンツアイテムを削除する、または除去する中間状態は、望ましくはなく、ユーザのデータが失われる可能性があるデータ脆弱性を増大させる。加えて、移動またはリネーム操作は、対応する追加操作が検出されるまで、クライアント同期サービスへの削除操作として出現する。しかしながら、ローカルファイルシステムのサイズ及び複雑さに基づき削除操作を検出した後に長期間、追加操作を検出しない場合がある。例えば、クライアント同期サービスは、ローカルファイルシステムの１つの部分をクロールし、コンテンツアイテムの削除を見いだし、コンテンツアイテムをローカルファイルシステムの別の部分に追加したことを見いださないことにより、クライアント同期サービスがローカルファイルシステムのその部分をクロールするまで、移動操作を完了することができる。

本発明の技術の取り組みのさまざまな実施形態は、削除操作が移動またはリネーム操作の部分であるか、単に削除操作であるかどうかを判定する、より効率的で、より高速な方法を提供することによって技術的な解決策を、これらの、また他の技術的な問題に提供することに向けられる。

図１５は、本発明の技術のさまざまな実施形態により、移動またはリネーム操作に応答してローカルツリーを更新する例示的な方法を示す。本明細書に記載される、これらの方法及びプロセスが特定の順序で、ある特定のステップ及び操作によって示されることができるが、同様の、もしくは代替の順序で、または並列して実行される追加の、より少ない、または代替のステップ及び操作は、別段の定めがない限り、さまざまな実施形態の範囲内にある。この方法１５００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などのシステムによって実装されることができる。

操作１５０５において、システムは、コンテンツアイテムについての削除イベントを検出する。システムは、クライアントデバイスのローカルファイルシステム、またはシステムが管理するように設定されるローカルファイルシステムの一部（例えば、コンテンツ管理フォルダ）への変更をクロールする、または監視することができる。システムは、ローカルファイルシステムとローカルツリーとの間の差異を識別するために、ローカルファイルシステムをローカルツリーと比較することができる。この削除イベントは、１つ以上の識別された差異に基づき検出されることができる。例えば、コンテンツアイテムについてのノードは、特定の位置においてローカルツリー中に存在するが、ローカルファイルシステム上のその位置に存在しない。これは、コンテンツアイテムをその位置から除去させるアクションをユーザまたはアプリケーションが実行したことを示すことができ、システムに削除イベントを検出させる。

削除イベントを検出させたアクションは、ユーザまたはアプリケーションによって、コンテンツアイテムをシステムによって監視される別の位置に移動させること、コンテンツアイテムをシステムによって監視されていない別の位置に移動させること、コンテンツアイテムをリネームする（いくつかのファイルシステムによる移動として扱われることができる）こと、またはコンテンツアイテムを実際に削除することに起因し得る。削除イベントの原因とされるのはどのユーザアクションか、及び／または削除イベントと関連する追加イベントが検出されるか、既に検出されたかどうかを判定するために、システムは、操作１５１０において、コンテンツアイテムについてオペレーティングシステムが提供した識別子を識別することができる。

いくつかの実施形態において、オペレーティングシステムが提供した識別子は、ｉノード識別子であることができ、コンテンツ管理システム及び／またはクライアント同期サービスによって提供されるファイル識別子と異なる。多くの事例において、オペレーティングシステムは、とりわけ、ｉノード識別子に基づくコンテンツアイテムの位置の迅速なクエリ実行を可能にするために、ｉノード識別子を提供することができる。例えば、いくつかのオペレーティングシステムは、システムがキーとしてｉノード識別子を使用してコンテンツアイテムの現在のパスまたは位置にクエリを行うことができるインタフェースを提供することができる。操作１５１５において、システムは、コンテンツアイテムの位置についてオペレーティングシステムにクエリを行うことによってコンテンツアイテムの位置を決定することができる。クエリに応答して、オペレーティングシステムは、ノード識別子によって参照されるコンテンツアイテムのローカルファイルシステムに現在の位置またはパスを返すことができる。

コンテンツアイテムの現在の位置を使用して、システムは、削除イベントを引き起こしたアクションを判定することができる。例えば、現在の位置がヌル位置である場合に、またはその他の方法により、コンテンツアイテムがもはやローカルファイルシステム上にないことを示す場合に、削除イベントを引き起こしたアクションは、実際の削除である。その結果、システムは、コンテンツアイテムについてのノードをローカルツリーから適切に削除することができる。現在の位置がシステム（例えば、クライアント同期サービス）によって管理されていない位置である場合に、削除イベントを引き起こしたアクションは、コンテンツアイテムのその前の位置からその現在の位置への移動である可能性が高い。しかしながら、コンテンツアイテムがシステムによって管理されるテリトリ外に移動するため、システムは、コンテンツアイテムをもはや追跡する必要がなく、コンテンツアイテムについてのノードをローカルツリーから削除することができる。

現在の位置がシステムによってまだ管理されている新規の位置である場合に、削除イベントを引き起こしたアクションは、コンテンツアイテムのその前の位置からその現在の位置への移動でもある。しかしながら、コンテンツアイテムがシステムによって管理されるテリトリ内にまだあるため、システムは、対応する追加イベントの検出を待機し、削除イベント及び追加イベントを合わせて移動アクションとして扱い、ローカルツリーをアトミックに更新し、削除イベントを引き起こした実際のアクションをミラーリングする必要がある。

同様に、現在の位置がシステムによって管理されている古い位置と同一の位置である場合に、削除イベントを引き起こしたアクションは、コンテンツアイテムのその前の位置からその現在の位置へのリネームでもある。いくつかのファイルシステムにおいて、リネーム操作及び移動操作は、リネーム操作が１つの名前を含む１つの位置から新規の名前を含む同一の位置への移動操作として扱われているという点で関連する。その結果、システムは、対応する追加イベント（新規の名前を含む）の検出を待機し、削除イベント及び追加イベントを合わせて移動またはリネームアクションとして扱い、ローカルツリーをアトミックに更新し、削除イベントを引き起こした実際のアクションをミラーリングする必要がある。

その結果、操作１５２０において、システムは、削除イベントがコンテンツアイテムの位置に基づきコンテンツアイテムについての追加イベントと関連付けられるかどうかを判定する。削除イベントが追加イベントと関連付けられない場合に、削除イベントは、操作１５２５において処理され得る。削除イベントが追加イベントと関連付けられる場合に、システムは、追加イベントを待機し、操作１５３０においてコンテンツアイテムについての追加イベントを検出し、操作１５３５においてローカルツリーへのユニタリ更新における追加イベントと削除イベントを処理することができる。いくつかの実施態様により、ｉノードクエリがコンテンツアイテムについて現在の位置またはパスを既に提供した場合に、追加イベントを待機することは、必要ではない。その結果、システムは、コンテンツアイテムについてのそのパスを観測し、このパスを観測されたパスセットに追加することができる。

図１４の方法１４００及び図１５の方法１５００が別々に記述されているが、これら２つの方法は、ローカルツリーを更新するために互いに連携して機能し得る。例えば、削除イベントが追加イベントと関連付けられない場合に、削除イベントは、図１５の操作１５２５において削除イベントを対応する追加イベントと組み合わせることなく処理され得る。いくつかの実施形態により、削除イベントを処理することは、例えば、削除イベントを観測されたパスセットに追加してチェックし、ローカルツリー制約に違反していないかどうかを判定することができる、図１４に示される操作を含むことができる。

例えば、削除イベントと関連するコンテンツアイテムがローカルツリー中に１つ以上の子孫ノードを含む場合に、「空ではない親ノードを削除することができない」制約に違反している可能性がある。この違反に対する修復は、追加のパス（例えば、コンテンツアイテムのすべての子孫ノードについての削除イベント）を観測することを待機することを含むことができる。追加のファイルイベントが検出されると、これらの追加のファイルイベントまたはパスについての制約は、追加の削除ファイルイベントがさらなる対応する追加イベントと関連付けられるかどうかを判定するチェックを含む、チェックを行われる場合がある。観測されたファイルイベントのすべてがバリデートされると、これらのファイルイベントは、合わせてバッチ処理され、ローカルツリーを更新するために使用されることができる。

同様に、削除イベントが追加イベントと関連付けられる場合に、システムは、追加イベントを待機することができ、操作１５３５においてローカルツリーへのユニタリ更新中に追加イベントと削除イベントを処理することは、両方のイベントを観測されたファイルイベントセットに追加すること、いずれかのローカルツリー制約に違反するかどうかを判定すること、それらを行う場合に適切な修復を実行すること、及び観測されたファイルイベントセット全体に基づきローカルツリーを更新することを含むことができる。

リモートツリーの更新
上述されるように、リモートツリーは、コンテンツ管理システムによって格納されるコンテンツアイテムについてのサーバ状態を表す。例えば、図１中のサーバ同期サービス１１２は、クライアント同期サービス１５６と通信し、クライアントデバイス１５０とコンテンツ管理システム１１０との間でコンテンツアイテムへの変更を同期させるように設定される。

本発明の技術のさまざまな実施形態は、コンテンツ管理システムにおける変更に基づきリモートツリーを更新するさまざまな技術的な解決策を提供する。リモートツリーは、他のツリーデータ構造に加えて、さまざまな実施形態において、クライアントデバイスとコンテンツ管理システムとの間の同期プロセスにとって、きわめて重要である。例えば、リモートツリーへの更新が行われると、残りは、システムがこの更新に反応し、いくつかの事例では、クライアントデバイスにおいてファイルシステム状態に、リモートツリーへの変更を同期させて、適用することができる。したがって、リモートツリーが更新される方法について注意することが重要である。

さらに詳細に全体を通して説明されるように、ある特定の実施形態において、コンテンツ管理システム１１０は、サーバファイルジャーナル１４８における変更、アクセスなどについてのデータログも格納することができる。サーバファイルジャーナル１４８は、コンテンツストレージ１４２中のコンテンツアイテムへのリビジョンの１つ以上のジャーナルを維持することができる。１つ以上のジャーナルは、各ネームスペース上で各コンテンツアイテムのリビジョンを追跡することができる。サーバファイルジャーナル１４８上のジャーナル中の値のロウは、ネームスペース中でコンテンツアイテムを識別し、ネームスペース中にコンテンツアイテムの状態を反映することができる。ネームスペース中の同一のコンテンツアイテムに対応するジャーナル中の後のロウは、ネームスペース中にコンテンツアイテムへの後のリビジョンを反映することができる。

したがって、コンテンツアイテムと関連するサーバファイルジャーナル１４８中のロウは、コンテンツアイテムの現在の状態、及び作成から現在の状態までのコンテンツアイテムへのいずれかのリビジョンを識別することができる。コンテンツアイテム情報をサーバファイルジャーナル１４８と同期させるために、コンテンツ管理システム１１０は、サーバファイルジャーナル１４８に含まれる情報を、クライアントデバイス１５０に提供され得る操作データに変換し、クライアントデバイス１５０にサーバファイルジャーナル１４８からのコンテンツアイテムの最新のサーバ状態を提供することができる。

本発明の技術のさまざまな実施形態は、コンテンツ管理システム１１０から操作データを受信し、この操作データに基づきコンテンツ管理システム上に格納されるコンテンツアイテムについてのサーバ状態を表すリモートツリーを更新するクライアントデバイス１５０に関する。しかしながら、クライアントデバイス１５０に提供される操作データは、リモートツリーのようなツリーデータ構造にない場合がある。代替に、操作データは、操作ログを表す。その結果、クライアントデバイス１５０上で実行するクライアント同期サービス１５６は、操作ログを含む操作データを受信し、この操作ログをリモートツリー上で実行することにより、リモートツリーを更新するように設定される。

いくつかの実施形態により、コンテンツ管理システム１１０は、リモートツリー全体を再構築するように設定される操作データを生成し、提供することができる。これは、１つ以上のネームスペースについての操作ログ全体を含むことができる。いくつかの事例において、コンテンツ管理システム１１０は、もはや最新のものではない、またはリモートツリーを構築するために必要とされていない操作をログから除去することができる。例えば、後に削除されるコンテンツアイテムについての操作を操作データから除去することができる。クライアント同期サービス１５６は、操作ログを受信し、このログ中の各操作を通して、完全なリモートツリーを構築することをインクリメンタルに進めることができる。代替に、クライアント同期サービスは、既存のリモートツリーを操作ログと比較し、リモートツリーを最新にするために既存のリモートツリーに適用される必要があるログ中の操作を判定することができる。

他の実施形態において、コンテンツ管理システム１１０は、クライアントデバイスによって格納されるリモートツリーをインクリメンタルに更新するように設定される操作データを生成し、提供することができる。操作データを生成するために使用される必要があるログの部分を判定するために、コンテンツ管理システム１１０は、ネームスペースについてのタイムライン中のポイントを表すカーソルを使用する。カーソルは、例えば、特定のネームスペースに対応するサーバファイルジャーナル１４８中の操作ログ中のエントリ識別子を含むことができる。１つの実施形態において、エントリ識別子は、ネームスペースについての操作ログにおけるエントリごとに増加する、ＳＪ＿ＩＤであることができる。しかしながら、カーソルは、サーバ状態のライフサイクル中のポイントをマーク付けすることができる、論理クロック値、カウンタ、タイムスタンプ、またはいずれかの他の値としても実装されることができる。

例えば、コンテンツ管理システム１１０は、ネームスペースへの変更があったと判定し、通知をクライアント同期サービス１５６に送信することができる。変更の通知を受信することに応答して、クライアント同期サービス１５６は、リモートツリーが更新された最後の時間から、操作ログについての要求を送信することができる。この要求は、リモートツリーが更新された最後の時間、またはコンテンツ管理システム１１０から受信した最後の更新を示すカーソルを含むことができる。代替に、クライアント同期サービス１５６は、コンテンツ管理システム１１０からの通知を必要とせずに、カーソルを含む要求を送信することができる。さらに別の実施態様において、コンテンツ管理システム１１０は、操作データをクライアント同期サービス１５６に送信するたびにカーソルの追跡を続け、クライアント同期サービス１５６は、カーソルをコンテンツ管理システムに送信するために必要ではない。

このカーソルを使用して、コンテンツ管理システム１１０は、クライアント同期サービス１５６に送信する操作ログの部分を判定し、その部分を操作データとして送信することができる。クライアント同期サービス１５６は、操作ログの部分を操作データとして受信し、リモートツリーを更新するために、このログ中の各操作を通してインクリメンタルに進めることができる。

ある特定の機能を有効にするために、しかしながら、サーバ状態、及びそれを表すリモートツリーは、１つより多いネームスペースを含むことができる。例えば、複数のネームスペースを含むことにより、より組織中心のストレージモデル及び／または個人及びグループの間での共有を可能にし得る。図１６は、さまざまな実施形態により、ツリーデータ構造の実施例を示す。リモートツリー１６００を図１６に示すが、他のツリーデータ構造（例えば、同期ツリー及びローカルツリー）は、同様の構造及び特性を有し得る。リモートツリーは、４つのネームスペース１６０５、１６１０、１６１５、及び１６２０を含むことができる。ネームスペース１６０５は、ルートネームスペースを表すことができ、ネームスペース１６１０及び１６１５は、ネームスペース１６０５内にマウントされる。ネームスペース１６２０のネームスペース１６１０内のマウントによって示されるように、ネストされたネームスペースも可能である。

各ネームスペースは、１つ以上の個々のユーザ及び異なるパーミッションと関連付けられることができる。例えば、企業ネームスペース１６０５は、会社または組織全体と関連付けられることができ、ネームスペース１６１５は、組織における経理部門と関連付けられることができ、ネームスペース１６１０は、組織内のエンジニアリング部門と関連付けられることができる。ネームスペース１６２０は、エンジニアリング部門内のグループと関連付けられることができ、個々のユーザについてのネームスペースを含むさらなるネームスペースを有することができる。異なるネームスペースは、ユーザ間のコンテンツアイテムの共有及びアクセスのより良い連携及び制御を可能にする。

各ネームスペースは、そのネームスペースについてのタイムライン中のポイントを表すネームスペース識別子（例えば、ＮＳ＿ＩＤ）及びカーソル（例えば、ＳＪ＿ＩＤ）によって識別される別個の操作ログと関連付けられることができる。しかしながら、複数のネームスペースについてのＳＪ＿ＩＤを使用して、進捗を追跡すること、及び複数のネームスペースにわたりタイムラインを同期させることは、困難である。例えば、第一のネームスペースについての第一のＳＪ＿ＩＤが第二のネームスペースについての第二のＳＪ＿ＩＤに等しいことにより、第一及び第二のネームスペースが同一の状態または時点に対応することを保証することができない。

これは、ネームスペースにわたる操作があるときに深刻な技術的問題を提示する。例えば、１つのネームスペースの別のネームスペース中へのマウント操作は、これら２つのネームスペースの操作ログ間の依存性をもたらす。移動操作などのネームスペースにわたる操作は、ツリーデータ構造に課される制約に違反する可能性がある。例えば、ネームスペース１６２０中のコンテンツアイテム１６５０をネームスペース１６１５に移動させる、図１６に示される移動操作１６５５は、ネームスペース１６２０についての操作ログ中の操作（例えば、削除操作）、及びネームスペース１６１５についての操作ログ中の対応する操作（例えば、追加操作）として出現する。ファイル識別子がツリー中の１つより多い位置に存在することができない制約を守るために、ネームスペース１６２０中の削除操作は、ネームスペース１６１５中の追加操作前に発生する必要がある。しかしながら、各ネームスペースのログについてＳＪ＿ＩＤのみを使用してこれを保証することは困難である。

以下の節にさらに詳細に考察されるように、本発明の技術のさまざまな実施形態は、ランポートクロックを使用して複数のネームスペースの複数のログエントリ識別子（例えば、ＳＪ＿ＩＤ）を同期させ、複数のネームスペースのＳＪ＿ＩＤ間の順序付け制約を、そして結果として、ネームスペースにわたる全体の順序付けを符号化するように設定されるコンテンツ管理システムを使用する技術的な解決策を提供する。コンテンツ管理システムは、操作データ中に含まれ、クライアントデバイスに提供される、線形化された操作セット中に各ネームスペースについての操作ログを線形化するようにさらに設定され得る。

クライアントデバイスに関して、クライアント同期サービスは、複数のネームスペースにわたり線形化され、正しいシーケンスに順序付けされる操作セットを含む操作データを受信することができる。クライアント同期サービスは、カーソルを使用して、リモートツリーを更新するために線形化された操作セット中の各操作を通してインクリメンタルに進めることができる。

リモートツリー中のネームスペースのマウント
上述されるように、クライアント同期サービスは、コンテンツ管理システムから受信する操作データに基づき、リモートツリーをクライアントデバイス上で更新することができる。さらなる技術的な問題は、クライアント同期サービスが操作データ中の前の未知のネームスペースターゲットについてのマウント操作に遭遇するときに発生する。リモートツリーの整合性を保護するために、マウントターゲットのコンテンツを決定し、それをさまざまな制約またはルールに対して潜在的にバリデートする前に、クライアント同期サービスがネームスペースターゲットをマウントするのを防ぐ。しかしながら、マウントターゲットが前に未知であったため、クライアント同期サービスは、マウントターゲットのコンテンツを認識しない。本発明の技術のさまざまな実施形態は、これら、また他の技術的な問題に対処する。

図１７は、さまざまな実施形態による、ネームスペースをマウントする概念図を示す。コンテンツ管理システムは、クライアントデバイスに提供される、線形化された操作セット中に各ネームスペースについての操作ログを線形化するように設定される。図１７は、ネームスペースＮＳＩＤ１ １７１０について操作ログ、及びネームスペースＮＳＩＤ２ １７１５についての操作ログの表現を含む。これら２つのネームスペースの間のネームスペース間順序付けは、エントリログ識別子（例えば、ＳＪ＿ＩＤ）及びランポートクロック値の使用によって確立される。

最初の期間中に、コンテンツ管理システムは、ユーザアカウントと関連する２つのネームスペースを線形化している。イベント１７２０において、ネームスペースＮＳＩＤ２ １７１５についての操作ログは、新規のネームスペースがネームスペースＮＳＩＤ２ １７１５内にマウントされることを示す、ＳＪ＿ＩＤ９、クロック１５において処理される。この時点までに、クライアントデバイスは、新規のネームスペースと関連するいかなる情報も含まない可能性があるため、ネームスペースを直ちにマウントした場合、ツリー制約に違反していないという保証がない。

コンテンツ管理システムは、ターゲットネームスペース１７２５をマウントするためのマウント操作１７２０を検出する。マウント操作１７２０を検出することに応答して、コンテンツ管理システムは、ターゲットネームスペースについてのネームスペース識別子を含むマウント通知をクライアントデバイスに送信する。コンテンツ管理システムは、ネームスペースＮＳＩＤ１ １７１０及びネームスペースＮＳＩＤ２ １７１５に加えて、ターゲットネームスペース１７２５を線形化プロセスにさらに追加し、ターゲットネームスペース１７２５についての操作ログのプレフィックスをクライアントデバイスに送信する。このプレフィックスは、マウント操作１７２０までに追加されるターゲットネームスペース１７２５についての操作ログの最初の部分であることができ、ネームスペースをリモートツリーにマウントする前にターゲットネームスペース１７２５についてのサブツリーを構築するためにクライアントデバイスによって使用されることができる。

図１８は、本発明の技術のさまざまな実施形態による、ネームスペースをリモートツリー中にマウントする例示的な方法を示す。本明細書に記述される、これらの方法及びプロセスは、特定の順序で、ある特定のステップ及び操作によって示されることができるが、同様の、もしくは代替の順序で、または並列して実行される、追加の、より少ない、または代替のステップ及び操作は、特に明示されない限り、さまざまな実施形態の範囲内にある。この方法１８００は、クライアントデバイス上で実行する、例えば、図２のクライアント同期サービス１５６などのシステムによって実装されることができる。

操作１８０５において、システムは、ターゲットネームスペースについてのマウント通知を受信することができる。マウント通知をコンテンツ管理システムによってシステムに送信し、インカミングプレフィックス、またはターゲットネームスペースについての操作ログの最初の部分に基づきサブツリーを作成することをシステムに通知することができる。操作１８１０において、システムは、ターゲットネームスペースについての操作ログの最初の部分を受信することができる。

図１７に示されるように、プレフィックス、またはターゲットネームスペースについての操作ログの最初の部分１７３０をコンテンツ管理システムからシステム（例えば、クライアントデバイス）に送信する。操作１８１５において、システムは、操作ログの最初の部分に基づきターゲットネームスペースについてのサブツリーを構築し始めることができる。図１７に示されるように、システムがサブツリーを構築することを完了するまで、ターゲットネームスペース１７５０についてのサブツリーをプレリモート保持領域１７６０中に生成することができる。

プレリモート保持領域は、マウントターゲット（例えば、マウントされるネームスペース）と関連する１つ以上のサブツリーを格納して生成する、クライアントデバイスについての位置である。これらのマウントターゲットについてのサブツリーは、これらのサブツリーがリモートツリーの現在の状態（例えば、カーソル）に追いつくまで、プレリモート保持領域中に格納され、更新されることができる。マウントターゲットについてのサブツリーがリモートツリーの現在の状態に追いつくと、マウントターゲットについてのサブツリーは、リモートツリー中にマウントされ得る。

上述されるように、追加のネームスペースは、ターゲットネームスペース内にネストされ、クライアントデバイスに以前に知られていない可能性がある。操作ログの最初の部分１７３０が処理され、クライアントデバイスに送信されると、追加のマウントは、見いだされることができ、方法１８００は、再帰的に繰り返され得る。例えば、ターゲットネームスペースについての操作ログの最初の部分１７３０をシステムに送信し、追加のマウント操作をコンテンツ管理システムによって検出し、コンテンツ管理システムに別のターゲットネームスペースについての別のマウント通知を送信させることにより、方法１８００の最初の繰り返しの内に方法１８００の再帰的繰り返しを開始することができる。方法１８００の再帰的繰り返しが完了する（見いだされたさらにネストされたネームスペースについての任意のさらなる繰り返しに加えて）と、プロセスは、方法１８００の最初の繰り返しに戻ることができる。

ターゲットネームスペースについての操作ログの最初の部分１７３０がクライアントデバイスに送信されたときに、コンテンツ管理システムは、図１７のマウント操作１７２０を送信することができ、その検出により最初にプロセスを開始した。クライアントデバイスは、マウント操作を受信し、操作１８２０において、ターゲットネームスペースについてのサブツリーをリモートツリーのマウント位置にマウントする。いくつかの実施形態により、マウント位置は、マウント操作、マウント通知、または両方によって提供され得る。図１７に示されるように、ターゲットネームスペース１７５０についてのサブツリーは、リモートツリー１７８０のマウント位置１７７０にマウントされる。いくつかの実施形態により、追加のバリデーションチェックを実行し、マウントされたサブツリーを含むリモートツリーがリモートツリーに適用されるすべてのツリー制約と一貫性があることを確認することができる。

いくつかの実施形態による、プレフィックス、またはターゲットネームスペースについての操作ログの最初の部分は、もはや有効ではない、最新ではない、または最終サブツリーに反映されない操作を除去するために処理され得る。例えば、最初の部分は、最終サブツリーに反映されないコンテンツアイテムについての削除操作、最終サブツリーに反映されないコンテンツアイテムについての追加及び対応する削除操作、またはターゲットネームスペース外にコンテンツアイテムを移動させる移動操作を含むことができる。これらの操作タイプは、ターゲットネームスペースについての最終サブツリーに反映されず、スペース、帯域幅、処理時間、及び他の計算リソースを減少させるために、操作ログの最初の部分から除去されることができる。

コンテンツ管理システムのファイルジャーナル及びストレージシステム
コンテンツ管理システム１１０に我々の焦点を向けると、図１９Ａは、システムコンフィグレーション１００において、コンテンツ管理システム１１０とクライアントデバイス１５０との間でコンテンツを同期させるための例示的なアーキテクチャの概略図を示す。この実施例において、クライアントデバイス１５０は、コンテンツストレージインタフェース１９０６及びファイルジャーナルインタフェース１９０２を介してそれぞれコンテンツストレージ１４２及びサーバファイルジャーナル１４８とインタラクトする。コンテンツストレージインタフェース１９０６は、コンテンツストレージサービス１１６によって提供される、または管理されることができ、ファイルジャーナルインタフェース１９０２は、サーバ同期サービス１１２によって提供される、または管理されることができる。例えば、コンテンツストレージインタフェース１９０６は、コンテンツストレージサービス１１６のサブコンポーネントまたはサブサービスであり得、ファイルジャーナルインタフェース１９０２は、サーバ同期サービス１１２のサブコンポーネントまたはサブサービスであり得る。

コンテンツストレージインタフェース１９０６は、コンテンツ要求またはインタラクションなどの通信をクライアントデバイス１５０とコンテンツストレージ１４２との間で管理することができる。コンテンツストレージインタフェース１９０６は、コンテンツストレージ１４２に、またコンテンツストレージ１４２からコンテンツをアップロードし、ダウンロードする、クライアントデバイス１５０からの要求を処理することができる。コンテンツストレージインタフェース１９０６は、コンテンツ要求（例えば、ダウンロード、アップロードなど）をクライアントデバイス１５０から受信し、アクセス制御リスト１４５中のパーミッションを検証し、認可サービス１３２と通信してクライアントデバイス１５０（及び／またはクライアントデバイス１５０からの要求）がコンテンツストレージ１４２に、またはコンテンツストレージ１４２からコンテンツをアップロードする、またはダウンロードすることを認可されるかどうかを判定し、コンテンツストレージ１４２とインタラクトしてコンテンツストレージ１４２中のコンテンツをクライアントデバイス１５０にダウンロードする、またはアップロードすることができる。クライアントデバイス１５０からの要求がコンテンツアイテムをダウンロードする要求である場合に、コンテンツストレージインタフェース１９０６は、コンテンツアイテムをコンテンツストレージ１４２から取得し、コンテンツアイテムをクライアントデバイス１５０に提供することができる。クライアントデバイス１５０からの要求がコンテンツアイテムをアップロードする要求である場合に、コンテンツストレージインタフェース１９０６は、コンテンツアイテムをクライアントデバイス１５０から得て、コンテンツアイテムをストレージ用のコンテンツストレージ１４２にアップロードすることができる。

クライアントデバイス１５０からのコンテンツ要求を処理するときに、コンテンツストレージインタフェース１９０６は、ストレージインデックス１９１０と通信し、コンテンツストレージ１４２中の要求されたコンテンツの可用性及び／またはストレージ位置をチェックし、コンテンツストレージ１４２中でコンテンツアイテムを追跡することができる。ストレージインデックス１９１０は、コンテンツストレージ１４２上でコンテンツアイテムを識別する、コンテンツストレージ１４２上のコンテンツアイテムのインデックスを維持することができ、そのうえコンテンツアイテムのそれぞれの位置をコンテンツストレージ１４２内で識別することができる。したがって、ストレージインデックス１９１０は、コンテンツストレージ１４２上でコンテンツアイテムを、またコンテンツアイテムのストレージ位置を追跡することができる。ストレージインデックス１９１０は、ファイルなどのすべてのコンテンツアイテム、及び／またはブロックまたはチャンクなどのコンテンツアイテムの部分を追跡することができる。いくつかの事例において、コンテンツアイテムは、コンテンツストレージ１４２に格納され、ストレージインデックス１９１０において追跡されることができるブロックまたはチャンクに分割され得る。例えば、コンテンツストレージ１４２は、コンテンツアイテムのそれぞれのデータ部分を含むデータのブロックまたはチャンクとして、コンテンツアイテムを格納することができる。ストレージインデックス１９１０は、コンテンツストレージ１４２に格納されるコンテンツアイテムのブロックまたはチャンクを追跡することができる。下記の図１９Ｂは、コンテンツアイテムのブロックを格納して追跡するための例示的なコンフィグレーションを示す。

ファイルジャーナルインタフェース１９０２は、メタデータ要求、ならびにコンテンツ同期及び操作などの通信を、クライアントデバイス１５０とサーバファイルジャーナル１４８との間で管理することができる。例えば、ファイルジャーナルインタフェース１９０２は、操作、コンフィグレーション、及び状態情報を、クライアントデバイス１５０とサーバファイルジャーナル１４８との間で変換する、妥当性確認する、認証する、及び／または処理することができる。ファイルジャーナルインタフェース１９０２は、カーソル内の、もしくは認可サービス１３２を介してＦＳＡｕｔｈトークンからのパーミッションを検証し、クライアントデバイス１５０によってサーバファイルジャーナル１４８へ送信される要求を認可する、またはこれらの要求の認可を検証することができる。クライアントデバイス１５０からの要求または操作を処理するときに、ファイルジャーナルインタフェース１９０２は、ネームスペースメンバーシップストア１９０８にアクセスして、クライアントデバイス１５０からの要求または操作と関連するいずれかのネームスペースについてネームスペース所有権情報を判定し、または検証し、パーミッション情報をアクセス制御リスト１４５から取得してクライアントデバイス１５０からの要求または操作と関連するコンテンツのパーミッションを検証することができる。

ファイルジャーナルインタフェース１９０２中の変換サービス１９０４は、通信のための線形化操作及び変換操作をクライアントデバイス１５０とサーバファイルジャーナル１４８との間で実行することができる。例えば、変換サービス１９０４は、クライアントデバイス１５０からの通信を、サーバファイルジャーナル１４８中のデータの構造及びフォーマットと一貫性がある異なるフォーマットに、そしてその逆もまた同様に変換することができる。図示するように、いくつかの事例において、クライアントデバイス１５０は、コンテンツアイテム情報（例えば、状態、変更、バージョンなど）をクライアントデバイス１５０において操作として処理することができ、サーバファイルジャーナル１４８は、データベーステーブルなどのデータ構造中のロウによって反映されるコンテンツアイテムリビジョンと同一の情報を処理することができる。クライアントデバイス１５０とサーバファイルジャーナル１４８との間のコンテンツアイテム情報の同期を有効にするために、変換サービス１９０４は、クライアントデバイス１５０からの操作を、サーバファイルジャーナル１４８に適しているリビジョンに変換することができ、サーバファイルジャーナル１４８上でデータのロウ中に反映されるリビジョンを、クライアントデバイス１５０に適している操作に変換することができる。

いくつかの事例において、認可サービス１３２は、クライアントデバイス１５０が要求されたコンテンツアイテムにアクセスする、このコンテンツアイテムを更新する、ダウンロードする、またはアップロードすることを認可されることを検証する、または指示するトークンを生成することができる。このトークンは、クライアントデバイス１５０と関連するデバイス識別子、クライアントデバイス１５０に認証される、または認可されるユーザアカウントと関連するアカウント識別子、クライアントデバイス１５０に認可されたセッションと関連するセッション識別子、ビューコンテキスト、及び識別されたコレクションへのアクセスパーミッションを含むことができる。トークンは、以下により詳細に記述される、カーソルと称される暗号によって署名されたデータオブジェクト中に含まれ得る。コンテンツ管理システム１１０及び／または認可サービス１３２は、トークン（複数可）をクライアントデバイス１５０に送信することができ、クライアントデバイス１５０は、以下にさらに記述されるようなサーバファイルジャーナル１４８へのコンテンツアイテムのリビジョン及び／または更新を要求するときに、トークンをコンテンツ管理システム１１０に提供することができる。また、クライアントデバイス１５０は、トークンをコンテンツストレージインタフェース１９０６に提供し、いずれかのコンテンツ要求（例えば、ダウンロード、アップロードなど）を有効にすることができる。コンテンツストレージインタフェース１９０６は、トークンを使用して、ストレージインデックス１９１０へのクエリを認可し、コンテンツアイテムをコンテンツストレージ１４２に、またはコンテンツストレージ１４２からアップロードする、またはダウンロードすることができる。

例えば、クライアントデバイス１５０は、コンテンツストレージ１４２にコンテンツアイテムをアップロードする要求をコンテンツストレージインタフェース１９０６に送信することができる。この要求は、トークン、及びアップロードされるコンテンツアイテムを含むことができる。コンテンツストレージインタフェース１９０６は、トークンを使用して、コンテンツアイテムがコンテンツストレージ１４２に既に存在するかどうかをチェックするストレージインデックス１９１０へのクエリを認可し、そしてコンテンツストレージ１４２へのコンテンツアイテムのアップロードを認可することができる。また、クライアントデバイス１５０は、トークンをファイルジャーナルインタフェース１９０２に提供し、メタデータをサーバファイルジャーナル１４８上に格納してコンテンツアイテムのアップロード及びリビジョンを追跡する要求を認可することができる。

図１９Ｂは、例示的なブロックストレージ及び同期コンフィグレーションを示す。この実施例において、コンテンツストレージ１４２は、特定のサイズ（例えば、４ＭＢ）までコンテンツアイテム（例えば、ファイル）の不透明チャンクであることができる、データブロックを格納することができる。コンテンツアイテムは、ブロック中に分割されることができ、これらのブロックは、アクセス用にコンテンツストレージ１４２に格納されることができる。ストレージインデックス１９１０は、コンテンツストレージ１４２に格納されるブロックと、コンテンツストレージ１４２に格納されるブロックのそれぞれの位置とを追跡することができる。ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８とインタラクトし、コンテンツストレージ１４２に格納されるコンテンツアイテム及び／またはブロックへのリビジョンを追跡することができる。

例えば、コンテンツアイテム１９２０（例えば、ＭｙＦｉｌｅ．ａｂｃ）をブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎ中に分割することができる。コンテンツストレージインタフェース１９０６は、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎを受信して、コンテンツストレージ１４２におけるストレージのためにブロックデータ１９２２Ｂをコンテンツストレージ１４２に送信することができる。ブロックデータ１９２２Ｂは、コンテンツアイテム１９２０と関連するブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎを含むことができる。

ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎは、コンテンツストレージ１４２において１つ以上のストレージデバイスまたはボリューム上に格納される、及び／または１つ以上の論理ストレージコンテナ（例えば、バケット）またはデータクラスタ内に集約されることができる。いくつかの事例において、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎは、同一位置（例えば、ストレージデバイス、ボリューム、コンテナ、及び／またはクラスタ）上に合わせて格納されることができる。他の事例において、いくつかの、またはすべてのブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎは、２つ以上の異なる位置（例えば、２つ以上の異なるストレージデバイス、ボリューム、コンテナ、及び／またはクラスタ）上に格納されることができる。

また、コンテンツストレージインタフェース１９０６は、ブロックメタデータ１９２２Ａをストレージインデックス１９１０に格納することができる。ブロックメタデータ１９２２Ａは、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎを識別することができ、ストレージインデックス１９１０がブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎをコンテンツストレージ１４２において追跡することを可能にする。ブロックメタデータ１９２２Ａは、各ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎについての識別子を含むことができる。ブロックについての識別子は、ブロックを識別する、ブロックのハッシュなどの名前またはキーであることができる。

また、ブロックメタデータ１９２２Ａは、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎのそれぞれのストレージ位置を示す、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎについての位置情報を含むことができる。ブロックの位置情報は、ブロックが格納されているストレージデバイスまたはボリューム、及び／またはブロックが含まれている論理ストレージコンテナまたはデータクラスタを識別することができる。この位置情報を使用して、関連したブロックにアクセスする、またはこのブロックを取得することができる。

コンテンツストレージインタフェース１９０６は、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎをコンテンツストレージ１４２に格納する前に、またはこれらを格納した後に、ブロックメタデータ１９２２Ａをストレージインデックス１９１０に格納することができる。例えば、コンテンツストレージインタフェース１９０６は、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎをコンテンツストレージ１４２に格納した後に、ブロックメタデータ１９２２Ａをストレージインデックス１９１０に格納し、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎがコンテンツストレージ１４２に格納されていることを示すことができる。

いくつかの事例において、コンテンツストレージインタフェース１９０６は、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎをコンテンツストレージ１４２に格納する前に、ストレージインデックス１９１０にクエリを行い、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎがコンテンツストレージ１４２に格納されているかどうか（または格納されている位置）を判定することができる。例えば、コンテンツストレージインタフェース１９０６は、ブロックメタデータ１９２２Ａに基づきストレージインデックス１９１０にクエリを行い、ブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎがコンテンツストレージ１４２に格納されているかどうかをチェックすることができる。ストレージインデックス１９１０は、ブロックメタデータ１９２２Ａ中のブロック識別子をストレージインデックス１９１０におけるブロック識別子と比較して、任意のマッチをチェックすることができる。ブロック識別子間のマッチは、関連したブロックがコンテンツストレージ１４２に格納されていることを示す。

前述されるように、サーバファイルジャーナル１４８は、コンテンツアイテムの追加、編集、移動またはリネーム、削除などを有する、コンテンツアイテムリビジョンを追跡する。その結果、ファイルジャーナルインタフェース１９０２は、リビジョン１９２２Ｃをサーバファイルジャーナル１４８に格納し、コンテンツアイテム１９２０及び／またはブロック１９２０Ａ、１９２０Ｂ、１９２０Ｃ、１９２０Ｎをコンテンツストレージ１４２に追加したことを示すことができる。リビジョン１９２２Ｃは、サーバファイルジャーナル１４８においてコンテンツアイテムリビジョンのジャーナル内にコンテンツアイテム１９２０のリビジョンを表すことができる。

リビジョン１９２２Ｃは、コンテンツアイテム１９２０、及びコンテンツアイテム１９２０と関連する操作、例えば、追加操作（例えば、アップロード）、編集操作、移動またはリネーム操作、削除操作などを識別することができる。また、リビジョン１９２２Ｃは、コンテンツアイテム１９２０が格納されているコンテンツ管理システム１１０中のネームスペースと、リビジョン１９２２Ｃを格納するためのサーバファイルジャーナル１４８におけるコンテンツアイテムリビジョンのジャーナル中のロウとを識別することができる。コンテンツアイテムリビジョンのジャーナル内のロウは、コンテンツアイテム１９２０についてのリビジョン１９２２Ｃと関連するリビジョン番号を表すことができる。

ファイルジャーナルインタフェース
図１９Ｃは、ファイルジャーナルインタフェース１９０２によってクライアントデバイス１５０とサーバファイルジャーナル１４８との間で処理される通信の図を示す。サーバファイルジャーナル１４８は、ロウ中の値、及びサーバファイルジャーナル１４８中のフィールドとして、コンテンツアイテム状態及び変更（例えば、リビジョン）を追跡する。例えば、サーバファイルジャーナル１４８は、コンテンツストレージ１４２中でコンテンツアイテムへのリビジョンの１つ以上のジャーナルを維持することができる。１つ以上のジャーナルは、各コンテンツアイテムのリビジョンを各ネームスペース上で追跡することができる。サーバファイルジャーナル１４８上のジャーナル中の値のロウは、コンテンツアイテムをネームスペース中で識別することができ、このコンテンツアイテムの状態をネームスペース中に反映する。ネームスペース中の同一のコンテンツアイテムに対応するジャーナル中の後のロウは、コンテンツアイテムへの後のリビジョンをネームスペース中に反映することができる。したがって、コンテンツアイテムと関連するサーバファイルジャーナル１４８中のロウは、コンテンツアイテムの現在の状態と、このコンテンツアイテムへのいずれかのリビジョンの作成から現在の状態までとを識別することができる。

コンテンツアイテム情報（例えば、状態、変更またはリビジョンなど）をクライアントデバイス１５０と同期させるために、サーバファイルジャーナル１４８は、サーバファイルジャーナル１４８中で追跡される、または格納される、１つ以上のコンテンツアイテムについてのリビジョンを表すリビジョンデータ１９３４を、ファイルジャーナルインタフェース１９０２へ、またはこのファイルジャーナルインタフェース１９０２から送信する、または受信することができる。リビジョンデータ１９３４は、例えば、サーバファイルジャーナル１４８中のロウに対応するコンテンツアイテムリビジョンのログを含むことができる。サーバファイルジャーナル１４８は、リビジョンデータ１９３４をファイルジャーナルインタフェース１９０４に送信することができ、このファイルジャーナルインタフェース１９０４は、以下にさらに記述されるように、リビジョンデータ１９３４をクライアントデバイス１５０についての操作データ１９３２に変換することができる。

クライアントデバイス１５０は、クライアントデバイス１５０においてコンテンツアイテムを更新する、または修正するコンテンツ操作を実行することができる。コンテンツアイテム情報をサーバファイルジャーナル１４８と同期させるために、クライアントデバイス１５０は、操作データ１９３２をファイルジャーナルインタフェース１９０２へ、またはこのファイルジャーナルインタフェース１９０２から送信する、または受信することができる。クライアントデバイス１５０は、操作データ１９３２をファイルジャーナルインタフェース１９０２に送信し、コンテンツアイテムへの変更をクライアントデバイス１５０に報告し、操作データ１９３２をファイルジャーナルインタフェース１９０２から受信してコンテンツアイテムの最新の状態（例えば、リビジョンデータ１９３４）をサーバファイルジャーナル１４８から得ることができる。

例えば、クライアントデバイス１５０は、コンテンツアイテムＡをクライアントデバイス１５０において編集し、コンテンツアイテムＡへの編集を示す編集操作をファイルジャーナルインタフェース１９０２に報告することができる。この編集操作は、ファイルジャーナルインタフェース１９０２と通信して、コンテンツアイテムＡへのリビジョンを示す、操作データ１９３２中に含まれ得る。ファイルジャーナルインタフェース１９０２は、編集操作を含む操作データ１９３２を受信して、サーバファイルジャーナル１４８におけるストレージのためのリビジョンを生成し、このコンテンツアイテムＡへの編集を追跡することができる。ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８を更新してコンテンツアイテムＡの編集された状態を表すリビジョンを格納するために、リビジョンデータ１９３４中の編集操作と関連するリビジョンをサーバファイルジャーナル１４８に含むことができる。

以下にさらに記述されるように、操作データ１９３２は、クライアントデバイス１５０によってクライアントデバイス１５０と関連する各ネームスペースについて取得される最新の状態またはリビジョンを識別するカーソルを含むことができる。例えば、カーソルは、クライアントデバイス１５０によって、このクライアントデバイス１５０と関連する各ネームスペースについて取得される最新のリビジョンをサーバファイルジャーナル１４８中で識別することができる。このカーソル中の情報により、クライアントデバイス１５０からの操作データ１９３２中の操作がこの操作と関連するネームスペース（複数可）について最新の状態またはリビジョンをサーバファイルジャーナル１４８中で反映するかどうかをファイルジャーナルインタフェース１９０２が判定することが可能である。これは、サーバファイルジャーナル１４８中の既存のリビジョンと、操作データ１９３２から変換されるリビジョンとの間の競合を生じる可能性がある、より古いリビジョンに対応するクライアントデバイス１５０からの操作データ１９３２中の操作がサーバファイルジャーナル１４８に書き込まれていないことをファイルジャーナルインタフェース１９０２が確保することを援助することができる。

クライアントデバイス１５０とサーバファイルジャーナル１４８との間のコンテンツアイテム情報の同期を可能にするために、ファイルジャーナルインタフェース１９０２は、操作データ１９３２をリビジョンデータ１９３４に、そしてその逆も同様に変換する（例えば、変換サービス１９０４を介して）ことができる。操作データ１９３２をクライアントデバイス１５０から受信するときに、ファイルジャーナルインタフェース１９０２は、操作データ１９３２を、この操作データ１９３２中の操作から解釈されるコンテンツアイテムリビジョンを含むリビジョンデータ１９３４に変換することができる。リビジョンデータ１９３４をサーバファイルジャーナル１４８から受信するときに、ファイルジャーナルインタフェース１９０２は、リビジョンデータ１９３４を、リビジョンデータ１９３４中のリビジョンをクライアントデバイス１５０に実装するための操作を含む操作データ１９３２に変換することができる。リビジョンデータ１９３４は、１つ以上のコンテンツアイテムに起こっていること（すなわち、１つ以上のコンテンツアイテムへのリビジョン）を記述する、データをサーバファイルジャーナル１４８中に含み、操作データ１９３２は、クライアントデバイス１５０に実行されている、または実行されるであろう、１つ以上のコンテンツアイテムを修正する操作を含む。したがって、ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８からの１つ以上のコンテンツアイテムへのリビジョンを記述するデータ（例えば、操作データ１９３４）を、クライアントデバイス１５０に実行されている、または実行されるであろう１つ以上のコンテンツアイテムをクライアントデバイス１５０において修正する操作に変換することができる。

前述されるように、クライアントデバイス１５０からの操作データ１９３２をサーバファイルジャーナル１４８についてのリビジョンデータ１９３４に変換することに加えて、ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８からのリビジョンデータ１９３４をクライアントデバイス１５０についての操作データ１９３２に変換することができる。ファイルジャーナルインタフェース１９０２は、リビジョンデータ１９３４をサーバファイルジャーナル１４８から取得し、リビジョンデータ１９３４中のリビジョンを、これらのようなリビジョンに従いクライアントデバイス１５０において１つ以上コンテンツアイテムをリバイスする、クライアントデバイス１５０における実行のための操作に変換することができる。リビジョンデータ１９３４中のリビジョンから生成されるこれらの操作は、ファイルジャーナルインタフェース１９０２によってクライアントデバイス１５０に提供される操作データ１９３２に含まれる。操作データ１９３２とリビジョンデータ１９３４との間のこの変換により、クライアントデバイス１５０及びサーバファイルジャーナル１４８は、コンテンツアイテム情報を必要に応じて互いに同期させることが可能である。

クライアントデバイス１５０によって提供される操作データ１９３２から生成されるいずれかのリビジョンデータ１９３４をサーバファイルジャーナル１４８に書き込む前に、ファイルジャーナルインタフェース１９０２は、操作データ１９３２中のカーソルをチェックし、及び／またはサーバファイルジャーナル１４８にクエリを行い、リビジョンデータ１９３４中のいかなるリビジョンもサーバファイルジャーナル１４８中で競合を生じないことを確保することができる。例えば、ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８にクエリを行い、リビジョンデータ１９３４中のリビジョンと関連するコンテンツアイテムのバージョンがサーバファイルジャーナル１４８におけるコンテンツアイテムの同一のバージョンであるかどうか、またはリビジョンデータ１９３４中のリビジョンが関係するコンテンツアイテムとして、サーバファイルジャーナル１４８におけるコンテンツアイテムのバージョンが更新されたバージョンであるか、異なるバージョンであるかどうかをチェックすることができる。リビジョンデータ１９３４が関係するバージョンと、コンテンツアイテムの最新のバージョンが異なるバージョンであることをサーバファイルジャーナル１４８が示す場合に、これら２つのバージョンは、競合している。

ファイルジャーナルインタフェース１９０２は、サーバファイルジャーナル１４８を更新して、操作データ１９３２から導出されるリビジョンデータ１９３４に含まれる新規のリビジョンを格納することができる。サーバファイルジャーナル１４８中のリビジョンにクエリを行う、及び／またはこれらのリビジョンを更新するときに、ファイルジャーナルインタフェース１９０２は、ネームスペースメンバーシップストア１９０８にクエリを行い、リビジョンデータ１９３４中のリビジョンが影響するいずれのネームスペースと関連するネームスペース所有権情報を取得することができる。このネームスペース所有権情報は、所有するユーザアカウント（複数可）、または特定のネームスペースのメンバーであるユーザアカウント（複数可）を示すことができるため、特定のネームスペースにアクセスすることができる。したがって、ファイルジャーナルインタフェース１９０２は、ネームスペース所有権情報を分析し、サーバファイルジャーナル１４８がネームスペースのメンバーではないユーザアカウントからのネームスペースへのリビジョンを含むように更新されないことを確保することができる。

図１９Ｄを参照して、サーバファイルジャーナル１４８は、ジャーナル１９６０、１９６２を格納し、コンテンツアイテムのリビジョン及び状態を追跡し、識別することができる。この実施例において、ジャーナル１９６０は、ネームスペース識別子（ＮＳ＿ＩＤ）、サーバジャーナル識別子（ＳＪ＿ＩＤ）、パス、ブロック、前のリビジョン（Ｐｒｅｖ＿Ｒｅｖ）、及びターゲットネームスペース（Ｔａｒｇｅｔ＿ＮＳ）を有する記録を含む。ＮＳ＿ＩＤは、ネームスペースをサーバファイルジャーナル１４８中で一意に識別するために１つ以上の値を含むことができる。ＳＪ＿ＩＤは、ネームスペースについての所与のジャーナル中のロウにマッピングする、単調に増加する値を含み、そのネームスペース内で操作またはリビジョンの順序付けを提供することができる。パスは、関連したコンテンツアイテムを識別するネームスペース相対パスであることができる。Ｐｒｅｖ＿Ｒｅｖは、このパスと関連するコンテンツアイテムの前の状態に対応するロウのＳＪ＿ＩＤを識別する。Ｔａｒｇｅｔ＿ＮＳは、マウントされたネームスペースのマウントポイントについてのターゲットネームスペースのＮＳ＿ＩＤを識別する。Ｔａｒｇｅｔ＿ＮＳフィールドは、マウントポイントに対応していないロウ（例えば、リビジョン）に設定されない。

ジャーナル１９６２は、ＮＳ＿ＩＤ、ＳＪ＿ＩＤ、クロック（例えば、タイムスタンプ）、ファイル識別子（Ｆｉｌｅ＿ＩＤ）、拡張属性（複数可）（ｘａｔｔｒ）などを有する記録を含む。ｘａｔｔｒは、コンテンツアイテムまたは操作と関連するメタデータを格納することができる。

いくつかの事例において、ジャーナル１９６０は、関連したコンテンツアイテムのサイズを表すサイズフィールド、コンテンツアイテムがディレクトリであるときを示すように設定されることができるディレクトリフィールド（例えば、Ｉｓ＿Ｄｉｒ）、関連したファイルを一意に識別するファイル識別子、クロックまたはタイムスタンプフィールドなどのような他のフィールドを含むことができる。

ファイルジャーナルインタフェース１９０２は、前述されるように、操作データ１９３２及びリビジョンデータ１９３４に基づき変換１９７０を実行することができる。変換１９７０を実行するときに、変換サービス１９０４は、サーバファイルジャーナル１４８におけるストレージのために線形化されたリビジョンを含むリビジョン１９７２に、操作データ１９３２を変換することができる。また、変換サービス１９０４は、リビジョンデータ１９３４を線形化された操作１９７４Ａに変換することができ、これらの線形化された操作１９７４Ａは、クライアントデバイス１５０に送信される操作データ１９３２に含まれ、クライアントデバイス１５０によって適用され、クライアントデバイス１５０においてコンテンツアイテム情報（例えば、状態、変更など）を更新することができる。また、変換サービス１９０４は、カーソル１９７４Ｂを生成して、または更新して、操作データ１９３２中のカーソル１９７４Ｂをクライアントデバイス１５０に提供することができる。カーソル１９７４Ｂは、線形化された操作１９７４Ｂと関連する各ネームスペース及び／またはコンテンツアイテムに対応するそれぞれのリビジョンまたはロウをサーバファイルジャーナル１４８中で識別する。

例えば、カーソル１９７４Ｂは、そのネームスペース（例えば、ＳＪ＿ＩＤ）についてサーバファイルジャーナル１４８中でネームスペース（例えば、ＮＳ＿ＩＤ）及びロウを識別することができ、そのネームスペースについてサーバファイルジャーナル１４８中で最新のリビジョンを示す。カーソル１９７４Ｂ中のネームスペース及びロウは、線形化された操作１９７４Ａ中の操作と関連付けられることができる。カーソル１９７４Ｂは、線形化された操作１９７４Ａがクライアントデバイス１５０に適用された後に、及び／または適用される前に、サーバファイルジャーナル１４８中のネームスペースのリビジョンまたは状態を示す、特定のネームスペースについてのサーバファイルジャーナル１４８中のリビジョンのログ上の特定の位置を識別することができる。したがって、カーソル１９７４Ｂは、線形化された操作１９７４Ａの前または後に、サーバファイルジャーナル１４８中のネームスペース及び／またはコンテンツアイテムの状態を示すことができ、リビジョン競合を回避すること、ならびに線形化された操作１９７４Ａが適用される前に、及び適用された後に、リビジョンの順序を追跡することを援助することができる。

図２０Ａは、サーバファイルジャーナルデータを線形化された操作に変換するための例示的な変換及び線形化プロセスの図を示す。この実施例において、サーバファイルジャーナル１４８中のジャーナル１９６０は、サーバファイルジャーナル１４８によって追跡されるリビジョン１９７２を有するロウ２００２を含む。ジャーナル１９６０中のリビジョン１９７２は、ネームスペース１００及び１０１（すなわち、ＮＳ＿ＩＤ１００及び１０１）と関連付けられる。いくつかの事例において、サーバファイルジャーナル１４８は、それぞれのネームスペースに固有なリビジョンを追跡するネームスペース固有ジャーナルを格納することができる。ネームスペース固有ジャーナル中のこれらのロウ（例えば、２００２）は、そのネームスペースに固有なデータを含み、各ロウは、そのネームスペースに固有なリビジョンを反映する。

ジャーナル１９６０中の各ロウ（２００２）は、そのロウと関連するネームスペースを一意に識別するネームスペース識別子フィールド（ＮＳ＿ＩＤ）、所与のネームスペース中のロウにマッピングする単調に増加する値を含み、そのネームスペース内で操作またはリビジョンの順序付けを提供するサーバジャーナル識別子フィールド（ＳＪ＿ＩＤ）を含む。また、ジャーナル１９６０は、コンテンツアイテムのネームスペース相対パスを識別するためのパスフィールド（Ｐａｔｈ）、コンテンツアイテムと関連するブロックまたはブロックリストを識別するためのブロックフィールド（Ｂｌｏｃｋ）、コンテンツアイテムの前の状態またはリビジョンを表すジャーナル１９６０中のロウ（すなわち、ＳＪ＿ＩＤ）を識別するための前のリビジョンフィールド（Ｐｒｅｖ＿Ｒｅｖ）、及びマウントされたネームスペースのマウントポイントについてのターゲットネームスペースを識別する（ロウがマウントに対応する場合）ためのターゲットネームスペースフィールド（Ｔａｒｇｅｔ＿ＮＳ）を含む。マウントポイントに対応しないロウ（例えば、リビジョン）に対してＴａｒｇｅｔ＿ＮＳフィールドについてのデータはない。

ジャーナル１９６０中の最初のロウ２００２は、ブロック「ｈ１」に対応し、前のリビジョン（Ｐｒｅｖ＿Ｒｅｖ）またはターゲットネームスペース（Ｔａｒｇｅｔ＿ＮＳ）を含まない、ネームスペース「１００」（ＮＳ＿ＩＤ１００）中の「Ｆｉｌｅ１」（パスフィールド値Ｆｉｌｅ１）について最初のリビジョン（ＳＪ＿ＩＤ１）を識別する。ロウが前のリビジョンまたはターゲットネームスペースを含まないことから、ロウによって表されるリビジョンは、ブロック「ｈ１」と関連する「Ｆｉｌｅ１」のネームスペース「１００」における追加に対応する。ＳＪ＿ＩＤ「４」を含むジャーナル１９６０中のロウは、このロウがネームスペース「１００」上の「Ｆｉｌｅ１」に対応するジャーナル１９６０中の最後のロウまたはＳＪ＿ＩＤであることから、ネームスペース「１００」上の「Ｆｉｌｅ１」についてジャーナル１９６０中の最後のリビジョンを表す。ＳＪ＿ＩＤ「４」を含むこのロウは、ネームスペース「１００」上の「Ｆｉｌｅ１」がＳＪ＿ＩＤ「１」に加えられた後に編集され、この編集がブロック「ｈ４」に対応することを示す。

修正２００４は、リビジョン１９７２を表す修正の実施例を描く。この実施例において、修正２００４のそれぞれは、ジャーナル１９６０中の対応するロウ（２００２）からのコンテンツリビジョンを示す。各修正は、ジャーナル１９６０中のＳＪＩＤ及びＮＳＩＤに対応し、ジャーナル１９６０中のこれらの対応するＳＪＩＤ及びＮＳＩＤと関連するファイルに対応する。この実施例において、修正２００４と関連するコンテンツは、ジャーナル１９６０中のブロック（例えば、「ｈ１」、「ｈ２」、「ｈ３」、「ｈ４」）の例示的なコンテンツ値を表す。修正２００４におけるこれらのコンテンツ値を例示目的のために提供し、各リビジョンと関連するコンテンツへの例示的な修正を描く。

例えば、修正２００４における第一修正は、ジャーナル１９６０中のＳＪＩＤ「１」及びＮＳＩＤ「１００」を表し、加えられているネームスペース「１００」中の「Ｆｉｌｅ１」を描く。コンテンツ「ａａａ」は、ＮＳＩＤ「１００」のＳＪＩＤ「１」において「Ｆｉｌｅ１」についての「ｈ１」の値を表す。また、修正２００４は、「ａａ２」（例えば、「ｈ４」）に修正されているネームスペース「１００」中の「Ｆｉｌｅ１」と関連するコンテンツ「ａａａ」（例えば、「ｈ１」）を説明する、ジャーナル１９６０中のＳＪＩＤ「４」及びＮＳＩＤ「１００」を表す、ネームスペース「１００」中の「Ｆｉｌｅ１」の編集を描く。

変換１９７０において、ジャーナル１９６０中のロウ２００２からのリビジョン１９７２を、線形化された操作１９７４Ａに変換する。線形化された操作１９７４Ａは、ジャーナル１９６０中のリビジョン１９７２から生成され、線形化後の修正２００４を表す。線形化された操作１９７４Ａによって示されるように、線形化された操作１９７４Ａ中の操作は、複数のリビジョン（１９７２）及び／または修正（２００４）、または単一のリビジョン（１９７２）及び／または修正（２００４）に基づくことができる。

例えば、修正２００４は、ジャーナル１９６０中のＳＪＩＤ「１」及びＮＳＩＤ「１００」に対応する、「Ｆｉｌｅ１」をネームスペース「１００」に加えるリビジョンと、ジャーナル１９６０中のＳＪＩＤ「４」及びＮＳＩＤ「１００」に対応する、ネームスペース「１００」中の「Ｆｉｌｅ１」を編集するリビジョンとを描く。追加リビジョンは、「Ｆｉｌｅ１」及びＮＳＩＤ「１００」と関連するコンテンツ値「ａａａ」（例えば、「ｈ１」）、ならびに「Ｆｉｌｅ１」及びＮＳＩＤ「１００」についてのいずれかの前のリビジョンの欠如から推測されることができる。換言すれば、コンテンツ「ａａａ」は、コンテンツ（例えば、「ｈ１」）が加えられたか、編集されたかのいずれかであったことを示し、「Ｆｉｌｅ１」及びＮＳＩＤ「１００」についての前のリビジョンの欠如は、コンテンツ「ａａａ」が編集されているコンテンツとは対照的に追加されているコンテンツ（例えば、「ｈ１」）を表すことを示唆する。編集リビジョンは、「Ｆｉｌｅ１」及びＮＳＩＤ「１００」と関連するコンテンツ値「ａａ２」（例えば、「ｈ４」）と、「Ｆｉｌｅ１」及びＮＳＩＤ「１００」と関連する前のリビジョン（ＳＪＩＤ「１」及びＮＳＩＤ「１００」）とから推測されることができる。換言すれば、「Ｆｉｌｅ１」及びＮＳＩＤ「１００」と関連する、コンテンツ「ａａａ」から「ａａ２」への変更は、コンテンツ「ａａ２」が編集を表すことを示唆する。

線形化された操作１９７４Ａにおいて、ＮＳＩＤ「１００」についてのＳＪＩＤ「１」及びＳＪＩＤ「４」に対応する追加及び編集修正（２００４）を、「ａａａ」（例えば、「ｈ１」）から「ａａ２」（例えば、「ｈ４」）に「Ｆｉｌｅ１」と関連するコンテンツ値を編集する単一の線形化された操作（編集操作）に変換することができる。「Ｆｉｌｅ１」のコンテンツ（例えば、「ｈ１」）を「ａａ２」（例えば、「ｈ４」）に編集する、単一の線形化された操作は、コンテンツ「ａａａ」（例えば、「ｈ１」）と関連する「Ｆｉｌｅ１」をネームスペース「１００」に追加する修正と、ネームスペース「１００」中の「Ｆｉｌｅ１」と関連するコンテンツ「ａａａ」（例えば、「ｈ１」）を「ａａ２」（例えば、「ｈ４」）に編集する修正とを反映する。その結果、この線形化された操作は、２つの修正２００４、及びリビジョン１９７２中の２つの対応するリビジョンに基づく。

ジャーナル１９６０中のＳＪＩＤ「２」及びＮＳＩＤ「１００」に対応する修正２００４における修正は、コンテンツ「ｂｂｂ」（例えば、「ｈ２」）と関連する「Ｆｉｌｅ２」をネームスペース「１００」に追加するリビジョンを表す。この修正は、ネームスペース「１００」上で「Ｆｉｌｅ２」に対応するジャーナル１９６０からのリビジョン１９７２のみを表す。その結果、線形化された操作１９７４Ａは、コンテンツ「ｂｂｂ」（例えば、「ｈ２」）と関連する「Ｆｉｌｅ２」をネームスペース「１００」に追加し、単一の修正２００４（ネームスペース「１００」上での「Ｆｉｌｅ２」の追加）、及びリビジョン１９７２に基づく、ネームスペース「１００」上での「Ｆｉｌｅ２」についての単一の操作を含む。

また、この実施例において、修正２００４は、ジャーナル１９６０中のＳＪＩＤ「３」及びＮＳＩＤ「１００」に対応する、コンテンツ「ｃｃｃ」（例えば、「ｈ３」）と関連する「Ｆｉｌｅ３」をネームスペース「１００」に追加する修正と、ジャーナル１９６０中のＳＪＩＤ「５」及びＮＳＩＤ「１００」に対応する、ネームスペース「１００」からの「Ｆｉｌｅ３」の削除（「－１」として表される）とを含む。したがって、リビジョン１９７２は、ネームスペース「１００」上の「Ｆｉｌｅ３」と関連する２つの修正２００４を含む。「Ｆｉｌｅ３」及びネームスペース「１００」と関連するジャーナル１９６０中の最後のリビジョンがジャーナル１９６０中のＳＪＩＤ「５」及びＮＳＩＤ「１００」を表す削除修正に対応することから、リビジョン１９７２からの「Ｆｉｌｅ３」及びネームスペース「１００」と関連する追加及び削除修正２００４は、ネームスペース「１００」から「Ｆｉｌｅ３」を削除する単一の操作に線形化されることができる。その結果、線形化された操作１９７４Ａは、「Ｆｉｌｅ３」をネームスペース「１００」から削除する単一の操作である、「Ｆｉｌｅ３」及びネームスペース「１００」についての単一の操作を備える。

ジャーナル１９６０において、ＮＳＩＤ「１００」についてのＳＪＩＤ「６」及び「７」、ならびにＮＳＩＤ「１０１」についてのＳＪＩＤ「１」は、ネームスペース「１００」に加えられて、その後、ネームスペース「１００」からネームスペース「１０１」に移動する「Ｄｉｒ」を表す。例えば、ＳＪＩＤ「６」及びＮＳＩＤ「１００」は、「Ｄｉｒ」及びネームスペース「１００」を識別し、「Ｄｉｒ」がＳＪＩＤ「６」においてネームスペース「１００」に追加されたことを示す前のリビジョンを含まない。ＳＪＩＤ「７」は、ブロックフィールド（「－」）、前のリビジョンフィールド（ＳＪＩＤ「６」）、及びターゲットネームスペースフィールド（「１０１」）によって反映される場合、ネームスペース「１００」からネームスペース「１０１」に移動する「Ｄｉｒ」を識別する。次いで、ＮＳＩＤ「１０１」についてのＳＪＩＤ「１」は、「Ｄｉｒ」及びネームスペース「１０１」についての前のロウまたはリビジョンの欠如によって示される場合、ネームスペース「１０１」に追加される「Ｄｉｒ」を識別する。ＮＳＩＤ「１００」中のＳＪＩＤ「６」及び「７」、ならびにＮＳＩＤ「８」中のＳＪＩＤ「１」における追加及び移動リビジョンは、ＳＪＩＤ「６」及びＮＳＩＤ「１００」に対応するネームスペース「１００」への「Ｄｉｒ」の追加、ＳＪＩＤ「７」及びＮＳＩＤ「１００」に対応するネームスペース「１００」からの「Ｄｉｒ」の削除、ならびにＳＪＩＤ「１」及びＮＳＩＤ「１０１」に対応するネームスペース「１０１」への「Ｄｉｒ」の追加という、３つの修正２００４によって描かれる。

ジャーナル１９６０中のＮＳＩＤ「１００」のＳＪＩＤ「６」及び「７」にそれぞれ対応する、「Ｄｉｒ」及びネームスペース「１００」の追加及び削除修正２００４は、「Ｄｉｒ」及びネームスペース「１００」に対応するジャーナル１９６０中の最後のリビジョンがＳＪＩＤ「７」及びＮＳＩＤ「１００」におけるネームスペース「１００」からの「Ｄｉｒ」の削除であることから、「Ｄｉｒ」をネームスペース「１００」から削除する単一の操作に線形化される。ジャーナル１９６０中のＳＪＩＤ「１」及びＮＳＩＤ「１０１」に対応する、ネームスペース「１０１」への「Ｄｉｒ」の追加は、「Ｄｉｒ」及びネームスペース「１０１」に対応する修正２００４及びリビジョン１９７２のみである。その結果、「Ｄｉｒ」及びネームスペース「１０１」についての単一のマウント操作として、線形化された操作１９７４Ａに追加を提供する。したがって、ＮＳＩＤ「１００」中のＳＪＩＤ「６」及び「７」、ならびにＮＳＩＤ「１０１」中のＳＪＩＤ「１」に対応するリビジョン１９７２からの３つの修正２００４（すなわち、ネームスペース「１００」上での「Ｄｉｒ」の追加及び削除、ならびにネームスペース「１０１」上での「Ｄｉｒ」の追加）は、ネームスペース「１００」中の「Ｄｉｒ」についての削除操作、及びネームスペース「１０１」中の「Ｄｉｒ」についてのマウント操作という、線形化された操作１９７４Ａ中の２つの操作に線形化される。

上記に示されるように、線形化された操作１９７４Ａは、「Ｆｉｌｅ１」及びネームスペース「１００」についての編集操作、「Ｆｉｌｅ２」及びネームスペース「１００」についての追加操作、ネームスペース「１００」中の「Ｆｉｌｅ３」の削除操作、ネームスペース「１００」中の「Ｄｉｒ」についての削除操作、ならびに「Ｄｉｒ」をネームスペース「１０１」に追加するためのマウント操作を備える。線形化された操作１９７４Ａ中のこれらの操作は、リビジョン１９７２から生成され、ジャーナル１９６０中の各コンテンツアイテムの最新の状態を反映する。ファイルジャーナルインタフェース１９０２は、線形化された操作１９７４Ａを生成し、線形化された操作１９７４Ａをクライアントデバイス１５０に送信して、クライアントデバイス１５０がリビジョン１９７２からの最新の状態をジャーナル１９６０中に含むことを確保することができる。

線形化された操作１９７４Ａをクライアントデバイス１５０に提供するときに、ファイルジャーナルインタフェース１９０２は、クライアントデバイス１５０への線形化された操作１９７４Ａに加えてカーソル１９７４Ｂを含むことができる。カーソル１９７４Ｂは、ジャーナル１９６０中の各ネームスペース（ＮＳＩＤ）について最後のリビジョン（ＳＪＩＤ）を識別することができる。いくつかの実施形態において、カーソル１９７４Ｂは、ユーザＩＤを有するＦＳＡｕｔｈトークン、及びカーソルに提供されるＮＳ＿ＩＤへの最後に観測されたアクセスパーミッションをも含むことができる。各ネームスペースについての最後のリビジョンは、各ネームスペースに対してクライアントデバイス１５０に送信された最新のリビジョンに対応するジャーナル１９６０中の位置を示すことができる。

いくつかの事例において、カーソル１９７４Ｂは、線形化された操作１９７４Ａ中の各操作をジャーナル１９６０中のネームスペース（ＮＳＩＤ）及びロウ（ＳＪＩＤ）にマッピングすることができる。操作と関連するネームスペース及びロウは、この操作に対応するジャーナル１９６０中の位置を示すことができる。換言すれば、操作と関連するネームスペース及びロウは、ジャーナル１９６０中にその操作によって表されるリビジョン番号を示すことができる。カーソル１９７４Ｂ中のネームスペース及びロウは、線形化された操作１９７４Ａと関連する各ネームスペース及びコンテンツアイテムについてジャーナル１９６０中で最新の状態に対応する。クライアントデバイス１５０からの変更（例えば、操作データ１９３２を介して）を１つ以上のネームスペース及び／またはコンテンツアイテムに適用することを試みるときに、カーソル１９７４Ｂをクライアントデバイス１５０用のツールとしてクライアントデバイス１５０に提供し、１つ以上のネームスペース及び／またはコンテンツアイテムについてクライアントデバイス１５０によって取得される最新の状態またはリビジョンを、ファイルジャーナルインタフェース１９０２に対して識別することができる。ファイルジャーナルインタフェース１９０２がカーソル１９７４Ｂをクライアントデバイス１５０から受信するときに、それは、カーソル１９７４Ｂを使用して、ジャーナル１９６０においてクライアントデバイス１５０の位置（例えば、クライアントデバイス１５０によって取得されるジャーナル１９６０からの最新のリビジョン）を識別し、クライアントデバイス１５０からの操作によって引き起こされる競合を検出する、または回避することができる。

例えば、ファイルジャーナルインタフェース１９０２が「Ｆｉｌｅ１」をネームスペース「１００」中で修正する操作をクライアントデバイス１５０から受信する場合に、ファイルジャーナルインタフェース１９０２は、それが操作に加えてクライアントデバイス１５０から受信する、カーソル１９７４Ｂを使用して、ジャーナル１９６０がネームスペース「１００」中の「Ｆｉｌｅ１」に対して、クライアントデバイス１５０からカーソル１９７４Ｂ中で識別されるリビジョンよりも、新しいいずれかのリビジョンを含むかどうかをチェックすることができる。カーソル１９７４Ｂ中のリビジョンがジャーナル１９６０中で直近のリビジョンである場合に、ファイルジャーナルインタフェース１９０２は、ネームスペース「１００」中の「Ｆｉｌｅ１」についてジャーナル１９６０中の新規のリビジョン（例えば、ＮＳＩＤ「１００」中のＳＪＩＤ「８」）として編集操作をコミットすることができる。

代替に、カーソル１９７４Ｂ中のリビジョンがネームスペース「１００」中の「Ｆｉｌｅ１」に対してジャーナル１９６０中の直近のリビジョンではない場合に、ファイルジャーナルインタフェース１９０２は、クライアントデバイス１５０からの編集操作がネームスペース「１００」中の「Ｆｉｌｅ１」に対して、ジャーナル１９６０中で直近のバージョンに基づいていないと判定することができる。例えば、カーソル１９７４Ｂがジャーナル１９６０中でＳＪＩＤ「４」及びＮＳＩＤ「１００」を識別し、ジャーナル１９６０がネームスペース「１００」中の「Ｆｉｌｅ１」に対して、ＳＪＩＤ「１２」及びＮＳＩＤ「１００」におけるリビジョンを含むとファイルジャーナルインタフェース１９０２が判定する場合に、ファイルジャーナルインタフェース１９０２は、クライアントデバイス１５０からの編集操作がネームスペース「１００」上の「Ｆｉｌｅ１」のより古いバージョン（例えば、ＳＪＩＤ「４」及びＮＳＩＤ「１００」）に関係があると判定することができ、この編集操作は、その後修正されたファイルを編集する場合に競合を生じる可能性がある。ファイルジャーナルインタフェース１９０２は、この編集操作によって生じるこの競合を検出して編集操作を拒否し、この競合を調整することを試みる、または最新のリビジョンをクライアントデバイス１５０に提供してクライアントデバイス１５０が競合を調整することを可能にすることができる。

ファイルジャーナルインタフェース１９０２は、線形化された操作をクライアントデバイス１５０に送信するたびに、各ネームスペース及び／またはコンテンツアイテムについてのそれぞれの位置をジャーナル１９６０中で識別する、本明細書に記述されるようなカーソルを含むことができる。同様に、いつでもクライアントデバイス１５０は、操作をファイルジャーナルインタフェース１９０２に送信し、ファイルジャーナルインタフェース１９０２がクライアントデバイス１５０における状態をジャーナル１９６０における状態にマッピングするために使用することができる、その最新のカーソルを含むことができる。

この実施例におけるジャーナル１９６０は、複数のネームスペースを備えるジャーナルを描く。前述されるように、いくつかの実施例において、サーバファイルジャーナル１４８は、ネームスペース固有のジャーナルを維持することができる。カーソル１９７４Ｂは、各ネームスペースについてＳＪＩＤ及びＮＳＩＤを含み、各ネームスペースについての最新のリビジョンを示すことができる。カーソル１９７４Ｂに基づき、ファイルジャーナルインタフェース２００は、複数のジャーナルが維持されている実施形態において、本明細書にさらに説明されるように、複数のジャーナルにクエリを行う、及び／またはリビジョンを複数のジャーナルから取得することができる。

図２０Ｂは、クライアントデバイス１５０からの操作データ１９３２をサーバファイルジャーナル１４８においてジャーナル１９６０についてのリビジョン１９７２に変換する、線形化２０１０のための例示的なプロセスの図を示す。クライアントデバイス１５０は、操作データ１９３２をファイルジャーナルインタフェース１９０２に提供することができる。この実施例における操作データ１９３２は、コンテンツアイテムの編集、追加、リネーム、移動、マウント、または削除操作などの、操作２０１２をクライアントデバイス１５０に含む。いくつかの事例において、操作２０１２は、同一のコンテンツアイテムに対して複数の操作を含むことができる。例えば、操作２０１２は、ネームスペース「１００」上の「Ｆｉｌｅ４」を編集する操作、ネームスペース「１００」からの「Ｆｉｌｅ４」を削除する操作を備えることができる。

また、操作データ１９３２は、ファイルジャーナルインタフェース１９０２からクライアントデバイス１５０によって以前に受信されたカーソル１９７４Ｂを含む。カーソル１９７４Ｂは、ジャーナル１９６０において１つ以上のネームスペース及び／またはコンテンツアイテムについての状態（例えば、ＮＳＩＤ及びＳＪＩＤ）または最新のリビジョンを識別することができる。クライアントデバイス１５０は、カーソル１９７４Ｂを操作２０１２についての基準ポイントとしてファイルジャーナルインタフェース１９０２に提供することができる。この実施例において、カーソル１９７４Ｂは、ＳＪＩＤ「９」によって表されている、ネームスペース「１００」についての最新の状態を提供する。

いくつかの事例において、カーソルは、コンテンツ管理システム１１０によって暗号により署名され、カーソルが改ざんされていないことをファイルジャーナルインタフェース１９０２が判定することを可能にする。さらに、クライアントデバイス１５０がネームスペースについて直近のリビジョンをサーバファイルジャーナル１４８から受信したときに、クライアントデバイス１５０がリビジョンをサーバファイルジャーナル１４８にコミットすることから、ファイルジャーナルインタフェース１９０２は、ＮＳ＿ＩＤに対して最後に観測されたアクセスパーミッションがまだ有効であるため、クライアントデバイス１５０がネームスペースへのアクセスを有することを許容することができる。

ファイルジャーナルインタフェース１９０２は、操作２０１２及びカーソル１９７４Ｂを受信して線形化２０１０を実行し、クライアントデバイス１５０からの操作２０１２を線形化してジャーナル１９６０についてのリビジョン１９７２に変換することができる。操作２０１２に基づき、ファイルジャーナルインタフェース１９０２は、操作のログ２０１４を生成することができる。ログ２０１４は、ジャーナル１９６０中のそれぞれのネームスペース（複数可）にマッピングされる操作２０１２からの操作リストを含むことができる。いくつかの事例において、ログ２０１４は、以前に説明されるような操作２０１２から生成される線形化された操作を備えることができる。

ファイルジャーナルインタフェース１９０２は、ジャーナル１９６０を更新してログ２０１４に操作を反映する前に、カーソル１９７４Ｂを使用して、その操作２０１２がジャーナル１９６０に最新の状態またはリビジョンを反映することを検証することができる。カーソル１９７４Ｂがジャーナル１９６０においてログ２０１４と関連するネームスペース及び／またはコンテンツアイテムに対して最新の状態またはリビジョンを反映することをファイルジャーナルインタフェース１９０２が確認する場合に、ファイルジャーナルインタフェース１９０２は、ログ２０１４に基づきリビジョン１９７２をジャーナル１９６０に追加することができる。リビジョン１９７２は、ログ２０１４中の操作と関連する各コンテンツアイテム及び／またはネームスペースの最新の状態またはリビジョンを含むことができる。

ログ２０１４における操作は、「Ｆｉｌｅ５」についての追加及び編集操作を備える。その結果、リビジョン１９７２は、ファイルジャーナルインタフェース１９０２がジャーナル１９６０に「Ｆｉｌｅ５」の最新状態（すなわち、線形化方式において追加及び編集操作を「Ｆｉｌｅ５」に適用した後の状態）として書き込むことができる、「Ｆｉｌｅ５」の編集を備える。また、ログ２０１４におけるこれらの操作は、「Ｄｉｒ２」についての追加操作、ならびにネームスペース「１００」上での「Ｆｉｌｅ４」についての編集及び削除操作を備える。したがって、リビジョン１９７２は、「Ｄｉｒ２」をネームスペース「１００」に追加する操作、ならびに「Ｆｉｌｅ４」をネームスペース「１００」から削除する操作を、それぞれ「Ｄｉｒ２」及び「Ｆｉｌｅ４」の最新の状態として有することができる。

図２０Ｂにおいて、ジャーナル１９６０中に描かれるリビジョン（１９７２）は、操作２０１２と関連する各コンテンツアイテム（「Ｆｉｌｅ４」、「Ｆｉｌｅ５」、「Ｄｉｒ２」）の最新の状態を反映する。しかしながら、いくつかの事例において、ファイルジャーナルインタフェース１９０２がログ２０１４に起因する各ネームスペース及び／またはコンテンツアイテムの最新の状態のリビジョンだけではなく、最新の状態またはリビジョンまでに導出するいずれかの前の状態またはリビジョンをも反映するため、ログ２０１４によって表されるあらゆるリビジョンをジャーナル１９６０に書き込むことができることに留意するべきである。例えば、ファイルジャーナルインタフェース１９０２は、操作２０１２からの最新の状態を反映する「Ｆｉｌｅ４」の編集のみを書き込むこととは対照的に、ジャーナル１９６０に「Ｆｉｌｅ４」の編集についてのリビジョン、及び「Ｆｉｌｅ４」の削除についての後のリビジョンを書き込み、ジャーナル１９６０に操作２０１２からの「Ｆｉｌｅ４」のリビジョンのフルシーケンスを示すことができる。

ファイルジャーナルインタフェース１９０２は、ログ２０１４中の操作をリビジョン１９７２に変換し、ジャーナル１９６０を更新してリビジョン１９７２を含むことができる。ファイルジャーナルインタフェース１９０２は、ジャーナル１９６０中のそれぞれのロウにおいて、リビジョン１９７２をジャーナル１９６０に書き込むことができる。ファイルジャーナルインタフェース１９０２は、リビジョン１９７２をジャーナル１９６０中の次の利用可能なロウ（例えば、ＳＪＩＤ）に追加することができる。いくつかの事例において、ファイルジャーナルインタフェース１９０２は、線形化２０１０及び／またはそれぞれのタイムスタンプまたはクロックに基づき決定されることができる相対的な順序に基づきリビジョン１９７２を追加することができる。

図２０Ｂに示されるように、ネームスペース「１００」中の「Ｆｉｌｅ４」の削除操作は、ネームスペース「１００」についてのロウ「１１」またはＳＪＩＤ「１１」に含まれる。ジャーナル１９６０のＳＪＩＤ「１１」中のリビジョンは、ブロックフィールド中のマイナス記号によって反映される場合、ネームスペース「１００」中の「Ｆｉｌｅ４」が削除されていることを示し、ネームスペース「１００」中の「Ｆｉｌｅ４」についてのジャーナル１９６０において、ＳＪＩＤ「９」を前のリビジョンとして識別する。「Ｄｉｒ２」の追加、及び「Ｆｉｌｅ５」の編集は、ロウまたはＳＪＩＤ１２及び１４にそれぞれ含まれる。

図２０Ｂ中のジャーナル１９６０は、ログ２０１４及びカーソル１９７４Ｂに基づくリビジョン１９７２を含み、ログ２０１４中で修正される各コンテンツアイテムの状態を反映するように更新されている。ジャーナル１９６０中の各ロウにおけるパスフィールドは、関連したネームスペース（例えば、ネームスペース「１００」）内でコンテンツアイテムを識別する。ロウのパスフィールドは、ログ２０１４中の対応する操作からのファイル及びネームスペースに基づく。ジャーナル１９６０中のブロックフィールドは、コンテンツアイテムを表す。いくつかの事例において、ブロックフィールドは、それぞれのコンテンツアイテムまたはデータブロックのハッシュを含むことができる。コンテンツアイテムが削除されている、及び／またはディレクトリ、フォルダ、マウントなどである場合に、ブロックフィールドは、空であり得る。

ジャーナル１９６０がログ２０１４に基づくリビジョン１９７２、及びカーソル１９７４Ｂを含むように更新するときに、変換サービス１９０４は、ジャーナル１９６０のパスフィールド中に含む、各コンテンツアイテムのパスを識別することができる。いくつかの事例において、変換サービス１９０４は、コンテンツアイテムの識別子（例えば、ファイルＩＤ）をコンテンツアイテムのパス（例えば、／ｄｉｒｅｃｔｏｒｙ／ｆｉｌｅｎａｍｅ）に変換することができる。例えば、クライアントデバイス１５０は、コンテンツアイテムについてのそれぞれのパスを追跡する、または計算することなく、識別子を使用して、コンテンツアイテム（例えば、操作データ１９３２中のコンテンツアイテム）を識別することができる。ジャーナル１９６０は、コンテンツアイテムのパスを代替に使用して、コンテンツアイテムを識別することができる。変換サービス１９０４は、クライアントデバイス１５０からのコンテンツアイテムの識別子を使用してジャーナル１９６０についてのコンテンツアイテムのパスを計算し、コンテンツアイテムについて計算されるパスを使用してジャーナル１９６０を更新することができる。また、変換サービス１９０４は、逆変換を実行してコンテンツアイテムのパスに基づきコンテンツアイテムの識別子を取得し、クライアントデバイス１５０と通信するコンテンツアイテムを参照するときにコンテンツアイテムの識別子を使用することができる。

例えば、変換サービス１９０４は、ジャーナル１９６０中のパス、ジャーナル１９６０中のＮＳＩＤ、及び／またはジャーナル１９６０中のディレクトリフィールド（またはサーバファイルジャーナル１４８中の他の箇所）を使用して、コンテンツアイテムを識別し、そのコンテンツアイテムの識別子（例えば、ファイルＩＤ）を取得することができる。ファイルジャーナルインタフェース１９０２がそのコンテンツアイテムに関係がある更新または情報をクライアントデバイス１５０に送信する場合に、ファイルジャーナルインタフェース１９０２は、クライアントデバイス１５０がコンテンツアイテムのパスを含む、または含まないコンテンツアイテムを識別するために使用することができる、コンテンツアイテムの識別子をクライアントデバイス１５０に提供することができる。

前述されるように、操作２０１２からのリビジョン１９７２をジャーナル１９６０に書き込む前に、ファイルジャーナルインタフェース１９０２は、カーソル１９７４Ｂが操作２０１２と関連する各ネームスペース及び／またはコンテンツアイテムについてジャーナル１９６０中の最新の状態またはリビジョンを反映するかどうかをチェックすることができる。いくつかの事例において、カーソル１９７４Ｂがジャーナル１９６０中の最新の状態またはリビジョンを反映することを確認した後に、ファイルジャーナルインタフェース１９０２は、操作２０１２から生成されるリビジョンがジャーナル１９６０中の既存のリビジョンと競合しないことを確保する第二チェックも実行することができる。例えば、ジャーナル１９６０においてネームスペース「１００」中のＳＪＩＤ「５」が「Ｆｉｌｅ５」の削除操作を表す場合に、クライアントデバイス１５０からのファイルジャーナルインタフェース１９０２によって受信される操作２０１２から発行されるＳＪＩＤ「１４」中に描かれる「Ｆｉｌｅ５」の編集リビジョン１９７２は、「Ｆｉｌｅ５」がＳＪＩＤ「５」において削除された場合でも、「Ｆｉｌｅ５」を編集することを試みることによって競合を生じる。したがって、ファイルジャーナルインタフェース１９０２は、この実施例において編集操作及びリビジョンを拒否し、編集操作が無効であることをクライアントデバイス１５０に通信することができる。ファイルジャーナルインタフェース１９０２は、カーソル１９７４Ｂを更新し、更新されたカーソルをクライアントデバイス１５０に提供し、必要に応じて「Ｆｉｌｅ５」（及びいずれかの他のコンテンツアイテム）についてジャーナル１９６０中の最新の状態またはリビジョンのクライアントデバイス１５０に通知することができる。

新規のリビジョンをジャーナル１９６０及び／またはサーバファイルジャーナル１４８に追加するときに、ファイルジャーナルインタフェース１９０２は、更新されたカーソルをクライアントデバイス１５０に送信し、新規のリビジョンを報告して新規のリビジョンをクライアントデバイス１５０と同期させることができる。また、クライアントデバイス１５０は、クライアントデバイス１５０においてカーソルに更新を要求することができる。クライアントデバイス１５０は、ファイルジャーナルインタフェース１９０２から受信する最後カーソルのコピーを、クライアントデバイス１５０によって取得される最後のリビジョン（複数可）を示すジャーナル１９６０中の、クライアントデバイス１５０上のコンテンツアイテムの状態の反映、及び／またはクライアントデバイス１５０の位置として格納することができる。

図２０Ｃは、サーバファイルジャーナル１４８からのリビジョンをクライアントデバイス１５０についての操作に変換する例示的な方法を示す。ステップ２０５０において、ファイルジャーナルインタフェース１９０２は、コンテンツ管理システム１１０に登録されるユーザアカウントについてクライアントデバイス１５０に格納される１つ以上のコンテンツアイテムと関連する複数のリビジョン（例えば、１９７２）を、サーバファイルジャーナル１４８においてリビジョンのジャーナル１９６０から取得する。各リビジョンは、ネームスペース、フォルダ、ファイル、または任意のコンテンツアイテムを修正することができる。さらに、各リビジョンは、ネームスペース、及びそのネームスペースについてのジャーナル識別子（ＳＪＩＤ）と関連付けられることができる。

いくつかの事例において、ファイルジャーナルインタフェース１９０２は、クライアントデバイス１５０に利用可能ではないリビジョンを含む、ジャーナル１９６０を更新したという判定に基づきジャーナル１９６０から複数のリビジョンを取得することができる。例えば、ファイルジャーナルインタフェース１９０２は、ジャーナル１９６０に追加される新規のリビジョンを追跡すること、及び／またはジャーナル１９６０におけるリビジョンをクライアントデバイス１５０におけるカーソルと比較することができる。いくつかの事例において、ファイルジャーナルインタフェース１９０２は、ジャーナル１９６０にクエリを行い、複数のリビジョンを取得すること、及び／またはジャーナル１９６０に利用可能なリビジョンをチェックすることができる。

ステップ２０５２において、ファイルジャーナルインタフェース１９０２は、複数のリビジョンと関連する各コンテンツアイテムのそれぞれのリビジョンセットに基づきそれぞれの操作を決定する。例えば、ファイルジャーナルインタフェース１９０２は、コンテンツアイテムの任意のリビジョンを線形化し、これらのリビジョンを、そのコンテンツアイテムについての１つ以上のそれぞれの操作に変換することができる。いくつかの事例において、複数の操作が線形方式において実行されるときに、ファイルジャーナルインタフェース１９０２は、そのコンテンツアイテムについての複数の操作をも、コンテンツアイテムの状態または修正を定義する、または反映する単一操作に変換することができる。

いくつかの事例において、複数のリビジョンについてのそれぞれの操作を計算するときに、ファイルジャーナルインタフェース１９０２は、特定のコンテンツアイテムと関連するリビジョン数、及び／またはこれらのようなリビジョンと関連するコンテンツアイテムのタイプに基づき推測または計算を行うことができる。例えば、複数のリビジョンがコンテンツアイテムについて単一リビジョンを含む場合に、ファイルジャーナルインタフェース１９０２は、単一リビジョン（例えば、リビジョン１９７２）及び／またはこのリビジョンと関連するブロックまたはコンテンツ（例えば、ジャーナル１９６０のロウ２００２中のブロックまたはコンテンツ）から、そのリビジョンによって表されるコンテンツアイテムの修正（例えば、２００４）のタイプを推測し、リビジョンによって表される修正のタイプに基づき、そのコンテンツアイテムについてそれぞれの操作を計算することができる。

図示するために、図４Ａに示されるように、修正２００４は、ＳＪＩＤ「１」及びＮＳＩＤ「１００」に対応するネームスペース「１０１」における「Ｄｉｒ」についての修正を描く。この修正は、ネームスペース「１０１」についての修正（２００４）及びリビジョン（１９７２）のみである。したがって、ファイルジャーナルインタフェース１９０２は、それが「Ｄｉｒ」を含むように修正される、または改訂される、ネームスペース「１０１」の第一インスタンスを表す場合に、ネームスペース「１０１」に「Ｄｉｒ」を描く修正が「Ｄｉｒ」の追加またはマウントであると推測することができる。ジャーナル１９６０中のブロックフィールドによって示されるように、「Ｄｉｒ」がディレクトリまたはフォルダであることから、この修正は、ディレクトリまたはフォルダの追加またはマウントであり得る。「Ｄｉｒ」がネームスペースであった場合に、修正は、ネームスペース「１０１」においてネームスペース「Ｄｉｒ」のマウントを表す。一方、「Ｄｉｒ」が、ジャーナル１９６０中のブロックフィールドに基づき決定されることができる、特定のコンテンツまたはブロックと関連したファイルであった場合に、次いで、「Ｄｉｒ」についての修正は、ファイル「Ｄｉｒ」のネームスペース「１０１」への追加である。例えば、ＳＪＩＤ「１」及びＮＳＩＤ「１０１」が「ｈ１」と関連する「Ｆｉｌｅ１」を代替に示した場合に、対応する修正は、「Ｆｉｌｅ１」のネームスペース「１０１」への追加である。

したがって、ジャーナル１９６０中のリビジョン（１９７２）と関連するコンテンツまたはブロックフィールドが削除（例えば、ブロックまたはコンテンツフィールド中のマイナス記号）を示さない限り、コンテンツアイテムの最初の、または唯一のリビジョンについてのそれぞれの操作は、コンテンツアイテムがネームスペースであるか、コンテンツアイテムの別のタイプであるかによってマウントまたは追加操作を表すことができる。これは、編集、マウント解除、または削除操作などの他の操作が関連したコンテンツアイテムをマウントする、または追加するために前のリビジョンを含むことが予測されるという仮定に基づく。コンテンツアイテムがそれと関連する前のリビジョンを含まない場合に、ファイルジャーナルインタフェース１９０２は、コンテンツアイテムと関連するリビジョンが編集、マウント解除、または削除操作ではないが、むしろ追加またはマウント操作である可能性が高いと推測することができる。

いくつかの事例において、ファイルジャーナルインタフェース１９０２は、コンテンツアイテムについての操作を、そのコンテンツアイテムについての複数のリビジョン（１９７２）、及び関連したネームスペースに基づき計算することができる。例えば、ファイルジャーナルインタフェース１９０２は、コンテンツアイテムの追加またはマウントを表すリビジョン、及び削除、編集、またはマウント解除を表す後のリビジョンから、削除、編集、またはマウント解除操作を推測することができる。図示するために、図２０Ａに示されるように、ファイルジャーナルインタフェース１９０２は、ジャーナル１９６０中のネームスペース「１００」についてのＳＪＩＤ「１」及び「４」に対応する複数の修正（２００４）及びリビジョン（１９７２）に基づき、ネームスペース「１００」中の「Ｆｉｌｅ１」についての編集操作を計算する。修正２００４においてコンテンツ値「ａａａ」及び「ａａ２」を表すブロック「ｈ１」及び「ｈ４」を、ＳＪＩＤ「１」及び「４」が含むことから、ファイルジャーナルインタフェース１９０２は、ＳＪＩＤ「１」が追加操作を表し、ＳＪＩＤ「４」が編集操作を表し、結果として生じる状態がＳＪＩＤ「４」における編集操作に基づいていると判定することができる。

それぞれの操作に基づき、ステップ２０５４において、ファイルジャーナルインタフェース１９０２は、各コンテンツアイテムについて線形化された操作（例えば、１９７２）のセットを生成する。線形化された操作セットは、ジャーナル１９６０中の複数のリビジョンに基づき各コンテンツアイテムの修正２００４を反映することができる。ファイルジャーナルインタフェース１９０２は、相対クロック及び／または因果関係に基づき各コンテンツアイテムについて計算されるそれぞれの操作を線形化することによって線形化された操作（３２４Ａ）のセットに、複数のリビジョン（１９７２）を変換することができる。

ステップ２０５６において、ファイルジャーナルインタフェース１９０２は、線形化された操作セットによって表されるジャーナル１９６０中の位置を識別するカーソル（例えば、３２４Ｂ）を生成する。ステップ２０５８において、ファイルジャーナルインタフェース１９０２は、線形化された操作セット及びカーソルをクライアントデバイス１５０に送信する。カーソルは、各ネームスペース及び／または操作について、それぞれのネームスペース識別子（ＮＳＩＤ）及びジャーナル識別子（ＳＪＩＤ）を含むことができる。カーソル中のＮＳＩＤ及びＳＪＩＤの組み合わせは、特定のネームスペースについてジャーナル１９６０中にリビジョン番号を示すことができる。クライアントデバイス１５０は、カーソルを使用して、クライアントデバイス１５０によって取得されるリビジョンを、またクライアントデバイス１５０によって取得されたこれらのリビジョンに対応するジャーナル１９６０中のクライアントデバイス１５０の位置を識別することができる。また、クライアントデバイス１５０は、その最新のカーソルをファイルジャーナルインタフェース１９０２に提供し、ファイルジャーナルインタフェース１９０２に、ジャーナル１９６０中のクライアントデバイス１５０の現在の位置を報告することができる。例えば、クライアントデバイス１５０は、カーソルをファイルジャーナルインタフェース１９０２に提供し、クライアントデバイス１５０が新規のリビジョンを必要とするかどうかを判定することができる。

また、クライアントデバイス１５０はまた、クライアントデバイス１５０における操作をファイルジャーナルインタフェース１９０２に報告するときに、そのカーソルをファイルジャーナルインタフェース１９０２に提供することができる。カーソルは、これらの操作をジャーナル１９６０中の特定のリビジョン、及び／またはジャーナル１９６０中の位置にマッピングする。これにより、クライアントデバイス１５０からの操作が操作によって修正されたコンテンツアイテムへの最新のリビジョンに基づくかどうかをファイルジャーナルインタフェース１９０２が判定することが可能である。

クライアントデバイス１５０は、カーソル、及び線形化された操作セットを受信し、これらの操作に基づきクライアントデバイス１５０においてコンテンツアイテムを更新することができる。このように、クライアントデバイス１５０は、クライアントデバイス１５０とコンテンツ管理システム１１０との間でコンテンツアイテムを同期させることができる。クライアントデバイス１５０は、カーソルを格納し、ジャーナル１９６０中のその位置をファイルジャーナルインタフェース１９０２に提供することができる。

図２１は、ネームスペース間操作の例示的な線形化の図を示す。ネームスペース間の線形化、及びシャード間またはネームスペース間のリスト化は、クロック順序付けを介して実行されることができる。テーブル２１０２Ａ、２１０２Ｂ（合わせて「２１０２」）は、線形化のためのネームスペース間操作のバッチを示す。テーブル２１０２Ａ、２１０２Ｂは、テーブル２１０２Ａ、２１０２Ｂ中の記録用のネームスペースを識別するためのネームスペース（ＮＳＩＤ）フィールドであるカラム２１０６Ａ、２１０８Ａと、カラム２１０６Ａ、２１０８Ａ中のそれぞれのネームスペース用のテーブル２１０２Ａ、２１０２Ｂ中のロウまたはＳＪＩＤを識別するためのＳＪＩＤフィールドであるカラム２１０６Ｂ、２１０８Ｂと、各ＳＪＩＤと関連する操作を識別するための操作フィールドであるカラム２１０６Ｃ、２１０８Ｃと、カラム２１０６Ｃ、２１０８Ｃ中の操作と関連するタイムスタンプを識別するためのクロックフィールドであるカラム２１０６Ｄ、２１０８Ｄとをそれぞれ含む。

この実施例において、テーブル２１０２Ａは、ＮＳＩＤ「１」についてのＳＪＩＤ「１００」及び「１０１」を描く。ＳＪＩＤ「１００」は、タイムスタンプ「１０００」において「ｆｏｏ．ｔｘｔ」をネームスペース「１」に追加する操作と関連付けられ、そしてＳＪＩＤ「１０１」は、タイムスタンプ「１００１」においてネームスペース「２」をマウントする操作と関連付けられる。テーブル２１０２Ｂは、ＮＳＩＤ「２」についてのＳＪＩＤ「１」及び「２」を描く。ＳＪＩＤ「１」は、タイムスタンプ「２１００」において「ｂａｒ．ｔｘｔ」をネームスペース「２」に追加する操作と関連付けられ、そしてＳＪＩＤ「２」は、タイムスタンプ「１００２」において「ｂａｒ．ｔｘｔ」を編集する操作と関連付けられる。

リニアライザ（例えば、変換サービス１９０４）は、テーブル２１０２Ａ及び２１０２Ｂ（合わせて２１０２）中の操作のバッチを取得し、カーソル（２１１４）によって操作（２１１２）の単一のストリームを発行することができる。リニアライザは、テーブル２１０２中に少なくとも１つの操作を含むすべてのネームスペースを識別し、それぞれタイムスタンプ、ＮＳＩＤ、ＳＪＩＤに基づきすべてのネームスペースについての操作を線形化することができる。この実施例において、テーブル２１０２中の操作のバッチは、テーブル２１０４に示される操作のストリームに線形化する。

テーブル２１０４は、各操作のネームスペースを識別するためのＮＳＩＤフィールドを含むＮＳＩＤカラム２１１０、テーブル２１０４中の操作を識別するための操作フィールドを含む操作カラム２１１２、及び各操作についてのカーソル状態を識別するためのカーソルフィールドを含むカーソルカラム２１１４を含む。テーブル２１０４中のロウ２１０４Ａは、テーブル２１０２Ａ中のネームスペース「１」のＳＪＩＤ「１００」からの追加操作を備える。ロウ２１０４Ａについてのカーソルカラム２１１４中のカーソル状態は、追加操作がテーブル２１０２Ａに示されるネームスペース「１」中のＳＪＩＤ「１００」に対応することを示す、ネームスペース「１」及びＳＪＩＤ「１００」である。テーブル２１０４中のロウ２１０４Ｂは、ＮＳＩＤカラム２１１０または操作カラム２１１２中に値を含まないが、この実施例において、ネームスペース「２」についてＳＪＩＤ「０」を追加する、ネームスペース間のカーソル状態を含む、カーソルカラム２１１４中のカーソル状態を更新する。

テーブル２１０４中のロウ２１０４Ｃは、テーブル２１０２Ａに示されるネームスペース「２」中のＳＪＩＤ「１」からの追加操作を含む。ロウ２１０４Ｃについてのカーソルカラム２１１４中のカーソル状態は、ロウ２１０４Ｃ中の追加操作と関連するネームスペース「１」及び「２」についてそれぞれＳＪＩＤ「１００」及び「１」を含む。示されるように、カーソル状態は、カーソルがネームスペース「１」中のＳＪＩＤ「１００」、及びネームスペース「２」中のＳＪＩＤ「１」にあることを示す。換言すれば、ネームスペース「１」中のロウまたはＳＪＩＤは、追加操作がネームスペース「１」の状態に影響しない場合に増加しないが、ネームスペース「２」中のロウまたはＳＪＩＤは、追加操作がネームスペース「２」中のリビジョンを表し、ネームスペース「２」の状態に影響する場合に１つ増加した。したがって、ロウ２１０４Ｃ中のカーソル状態は、ネームスペース「２」中のＳＪＩＤ「１」における追加操作後に、ネームスペース「１」及びネームスペース「２」についてそれぞれのＳＪＩＤを追跡する。

テーブル２１０４中のロウ２１０４Ｄは、ＳＪＩＤ「１０１」におけるマウント操作、及びテーブル２１０２Ａにおけるネームスペース「１」を含む。マウント操作は、ネームスペース「２」をネームスペース「１」にマウントする。マウント操作は、ネームスペース「１」中のＳＪＩＤを「１００」から「１０１」に増加させるが、ネームスペース「２」中のＳＪＩＤを増加させない。その結果、ロウ２１０４Ｄについてのカーソルカラム２１１４中のカーソル状態は、ネームスペース「１」についてＳＪＩＤ「１０１」を含み、ネームスペース「２」についてＳＪＩＤ「１」を維持する。このカーソル状態は、ネームスペース「１」及び「２」における状態及び／または順序を反映する。

テーブル２１０４中のロウ２１０４Ｅは、マウント及び編集操作のそれぞれのタイムスタンプに従い、ネームスペース「１」中のＳＪＩＤ「１０１」におけるマウント操作後である、テーブル２１０２Ａ中のＳＪＩＤ「２」及びネームスペース「２」における編集操作を含む。ロウ２１０４Ｅのカーソルカラム２１１４中のカーソル状態は、ＳＪＩＤ「１０１」におけるネームスペース「１」についてのカーソル状態を維持するが、ＳＪＩＤ「２」へのネームスペース「２」についてのカーソル状態を増加させる。

テーブル２１０４中に示されるように、操作２１１２は、ネームスペース「１」及び「２」にわたる因果関係及びタイムスタンプに基づき線形化される操作のストリームとしてリスト化される。操作２１１２をテーブル２１０４中で線形化してネームスペース間の因果関係及び連鎖を反映すると、操作２１１２をサーバファイルジャーナル１４８中のリビジョン（例えば、ジャーナル１９６０中のリビジョン１９７２）に変換し、サーバファイルジャーナル１４８に書き込むことができる。

例えば、サーバファイルジャーナル１４８中のネームスペース「１」についてのジャーナルは、「ｆｏｏ．ｔｘｔ」をネームスペース「１」に追加する追加操作を表すＳＪＩＤ「１００」におけるリビジョン、及びネームスペース「２」をネームスペース「１」上にマウントするマウント操作を表すＳＪＩＤ「１０１」におけるリビジョンを含むように更新されることができる。さらに、サーバファイルジャーナル１４８中のネームスペース「２」についてのジャーナルは、「ｂａｒ．ｔｘｔ」をネームスペース「２」に追加する追加操作を表すＳＪＩＤ「１」におけるリビジョン、及びネームスペース「２」上の「ｂａｒ．ｔｘｔ」を編集する編集操作を表すＳＪＩＤ「２」におけるリビジョンを含むように更新されることができる。

ランポートクロック
図２２は、イベントのために計算されるランポートクロックに従い順序付けされるネームスペースにわたるイベントの図を示す。この実施例において、さまざまな操作は、ネームスペースＮＳＩＤ１、ＮＳＩＤ２、及びＮＳＩＤ３にわたり実行されている。各ネームスペースは、ネームスペース内の操作の順序付けを決定するために、そのネームスペースにおけるすべての操作に対してＳＪＩＤを維持する。しかしながら、ネームスペースのＳＪＩＤは、ネームスペースにわたる操作の順序付け及び因果関係を識別しない。その結果、ランポートクロックをネームスペースＮＳＩＤ１、２、３中の操作について計算し、因果関係を判定し、操作のネームスペース間順序付けを取得する。

ＮＳＩＤ１において、操作２２１０は、ＳＪＩＤ１及びクロック１を含む。ＮＳＩＤ２において、操作２２１６は、ＳＪＩＤ１及びクロック１を含む。ＮＳＩＤ３において、操作２２２０は、ＳＪＩＤ１及びクロック１を含む。操作２２１０、２２１６、２２２０は、複数のネームスペースにまたがり、因果関係を含まない。その結果、操作２２１０、２２１６、２２２０は、互いのクロックに影響しない。

ネームスペース内の操作の順序付けは、ネームスペースにおいてＳＪＩＤに基づき決定されることができる。同一のネームスペース内の操作についてのクロックは、１つ単にインクリメントされることができる。したがって、ＮＳＩＤ１中のＳＪＩＤ２において、操作２２１２についてのクロックは、２にインクリメントされる。

ＮＳＩＤ１中の操作２２１２は、Ｆｉｌｅ１からＮＳＩＤ２への移動である。その結果、操作２２１２は、Ｆｉｌｅ１のＮＳＩＤ２における追加である、操作２２１８をＮＳＩＤ２にトリガする。ＮＳＩＤ２における操作２２１８が異なるネームスペースからの別な操作、すなわち、ＮＳＩＤ１からの操作２２１２に因果関係によって依存していることから、操作２２１８についてのクロックは、ＮＳＩＤ１におけるクロック、及びＮＳＩＤ２におけるクロックに基づき計算される。このアルゴリズムは、ＴａｒｇｅｔＮＳ＿ｃｌｏｃｋｔ１＝ｍａｘ（Ｓｏｕｒｃｅ＿ＮＳｃｌｏｃｋ，ＴａｒｇｅｔＮＳ＿ｃｌｏｃｋｔ０）＋１として表現されることができる。したがって、この実施例において、ＮＳＩＤ２における操作２２１８についてのクロックは、３（例えば、ｍａｘ（２，１）＋１）である。その結果、ＮＳＩＤ２における操作２２１８は、ＳＪＩＤ２及びクロック３を含む。

同様に、ＮＳＩＤにおける操作２２１６は、ＮＳＩＤ２からＮＳＩＤ１へのＦｉｌｅ２の移動である。したがって、操作２２１６は、Ｆｉｌｅ２をＮＳＩＤ１に追加するための、ＮＳＩＤ１における操作２２２２をトリガする。操作２２２２についてのクロックは、クロックアルゴリズムに基づき計算され、３に等しい。したがって、操作２２２２は、ＮＳＩＤ１におけるＳＪＩＤ３、及びクロック３を含む。

ＮＳＩＤ３における操作２２２３は、同一のネームスペースにおける操作、すなわち、ＮＳＩＤ３における操作２２２０に因果関係によって依存している。したがって、操作２２２３についてのクロックは、ＮＳＩＤ３における操作２２２０のクロックをインクリメントすることによって計算され得る。この実施例において、したがって、操作２２２３についてのクロックは、２である。ＮＳＩＤ３における操作２２２３は、ＳＪＩＤ２及びクロック２を含む。操作２２２３がＤｉｒをＮＳＩＤ１に移動させるための移動操作であることから、操作２２２３は、ＤｉｒをＮＳＩＤ１に追加する、ＮＳＩＤ１における操作２２２４をトリガする。

操作２２２４が操作２２２２によって異なるネームスペース（ＮＳＩＤ３）にトリガされることから、操作２２２４についてのクロックは、ＮＳＩＤ１におけるクロック、及び操作２２２２についてのクロックに基づき計算される。その結果、操作２２２４についてのクロックは、４に設定される（例えば、ｍａｘ（２，３＋１）。したがって、操作２２２４は、ＮＳＩＤ１におけるＳＪＩＤ４、及びクロック４を含む。

ＮＳＩＤ１における操作２２２６は、Ｆｉｌｅ３をＮＳＩＤ１に追加し、ネームスペース間操作ではない。その結果、操作２２２６についてのクロックは、ＮＳＩＤ１においてクロックをインクリメントすることによって計算される。したがって、操作２２２６についてのクロックは、５に設定される。

操作２２２８は、ＮＳＩＤ１内で操作２２２６にも因果関係によって依存している。したがって、操作２２２８についてのクロックは、ＮＳＩＤ１において操作２２２６のクロックをインクリメントすることによって、６に設定される。操作２２２８は、ＮＳＩＤ１におけるＳＪＩＤ６、及びクロック６を含む。

操作２２２８は、Ｆｉｌｅ３をＮＳＩＤ３に移動させる移動操作である。したがって、操作２２２８は、ＮＳＩＤ３に操作２２３０をトリガする。操作２２３０が異なるネームスペースからの操作に基づくことから、そのクロックは、ＮＳＩＤ３におけるクロック、及び操作２２２８のクロックに基づくクロックアルゴリズムを使用して計算される。この事例において、操作２２３０についてのクロックは、７に設定される。したがって、操作２２３０は、ＮＳＩＤ３におけるＳＪＩＤ３、及びクロック７を含む。

操作２２３２、２２３４は、ネームスペース間操作ではなく、ＮＳＩＤ３における操作２２３０に因果関係によって関連がある。したがって、操作２２３２、２２３４についてのクロックは、操作２２３０のクロックをインクリメントすることによって計算されることができる。この実施例において、操作２２３２、２２３４についてのクロックは、それぞれ８及び９に設定される。

図２３は、コンピューティングシステム２３００の実施例を示し、このコンピューティングシステムは、クライアントデバイス１５０、コンテンツ管理システム１１０またはそれらのいずれかのコンポーネントを構成する、例えば、いずれかのコンピューティングデバイスであることができ、このシステムのこれらのコンポーネントは、接続２３０５を使用して互いに通信する。接続２３０５は、バスを介する物理的な接続、またはチップセットアーキテクチャなどの、プロセッサ２３１０中に直接接続であることができる。また、接続２３０５は、仮想接続、ネットワーク化された接続、または論理接続であることができる。

いくつかの実施形態において、コンピューティングシステム２３００は、本開示に記述される機能が１つのデータセンター、複数のデータセンター、ピアネットワークなどの内に分散されることができる分散システムである。いくつかの実施形態において、記述されたシステムのコンポーネントのうちの１つ以上は、コンポーネントが記述されている機能のうちのいくつか、またはすべてを各実行する、多くのこれらのようなコンポーネントを表す。いくつかの実施形態において、これらのコンポーネントは、物理デバイスまたは仮想デバイスであることができる。

例示的なシステム２３００は、少なくとも１つの処理ユニット（ＣＰＵまたはプロセッサ）２３１０、ならびに読み出し専用メモリ（ＲＯＭ）２３２０及びランダムアクセスメモリ（ＲＡＭ）２３２５などのシステムメモリ２３１５を含むさまざまなシステムコンポーネントをプロセッサ２３１０に結合する接続２３０５を備える。コンピューティングシステム２３００は、プロセッサ２３１０の部分と、直接に、近接して、または統合されて、接続される高速メモリ２３１２のキャッシュを含むことができる。

プロセッサ２３１０は、いずれかの汎用プロセッサ、ならびにストレージデバイス２３３０に格納され、プロセッサ２３１０を制御するように構成されるサービス２３３２、２３３４、及び２３３６などのハードウェアサービスまたはソフトウェアサービスだけではなく、ソフトウェア命令が実際のプロセッサ設計中に組み込まれる専用プロセッサをも含むことができる。プロセッサ２３１０は、本質的に、複数のコアまたはプロセッサ、１つのバス、メモリコントローラ、キャッシュなどを含む、完全に自己完結型コンピューティングシステムであることができる。マルチコアプロセッサは、対称または非対称であることができる。

ユーザインタラクションを可能にするために、コンピューティングシステム２３００は、入力デバイス２３４５を含み、この入力デバイスは、音声用のマイクロフォン、ジェスチャまたはグラフィカル入力用のタッチパネル、キーボード、マウス、モーション入力、音声などのような、いずれかの数の入力メカニズムを表すことができる。また、コンピューティングシステム２３００は、出力デバイス２３３５を含むことができ、この出力デバイスは、当業者に知られている複数の出力メカニズムのうちの１つ以上であることができる。いくつかの例において、マルチモーダルシステムは、コンピューティングシステム２３００と通信する複数のタイプの入力／出力をユーザが提供することを可能にする。コンピューティングシステム２３００は、通信インタフェース２３４０を含むことができ、この通信インタフェースは、ユーザ入力及びシステム出力を一般的に規制し、管理することができる。いずれかの特定のハードウェア配置上の操作に制約がないため、本明細書における基本機能は、それらが開発されているような改善されたハードウェアまたはファームウェア配置の代わりに容易に使用されることができる。

ストレージデバイス２３３０は、不揮発性メモリデバイスであることができ、ハードディスク、またはコンピュータによってアクセス可能であるデータを格納することができる、磁気カセット、フラッシュメモリカード、ソリッドステートメモリデバイス、デジタルバーサタイルディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、及び／またはこれらのデバイスのいくつかの組み合わせのような、他のタイプのコンピュータ可読媒体であることができる。

ストレージデバイス２３３０は、ソフトウェアサービス、サーバ、サービスなどを含むことができ、このようなソフトウェアを定義するコードがプロセッサ２３１０によって実行されるときに、そのコードがシステムに機能を実行させる。いくつかの実施形態において、特定の機能を実行するハードウェアサービスは、この機能を実行する、プロセッサ２３１０、接続２３０５、出力デバイス２３３５などのような、必要なハードウェアコンポーネントと関連するコンピュータ可読媒体に格納されるソフトウェアコンポーネントを含むことができる。

説明の明確さのために、いくつかの例において、本技術は、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせに具体化される方法において、デバイス、デバイスコンポーネント、ステップまたはルーチンを有する機能ブロックを含む個々の機能ブロックを備えるように提示されることができる。

本明細書に記述されるステップ、操作、機能、またはプロセスのいずれかは、ハードウェア及びソフトウェアサービスの組み合わせ、もしくはサービス単独で、または他のデバイスと組み合わせて実行される、または実装されることができる。いくつかの実施形態において、サービスは、クライアントデバイスのメモリ、及び／またはコンテンツ管理システムの１つ以上のサーバに存在するソフトウェアであり、プロセッサがサービスと関連するソフトウェアを実行するときに１つ以上の機能を実行することができる。いくつかの実施形態において、サービスは、特定の機能を実行するプログラムまたはプログラムコレクションである。いくつかの実施形態において、サービスは、サーバとみなされることができる。メモリは、非一時的なコンピュータ可読媒体であることができる。

いくつかの実施形態において、コンピュータ可読ストレージデバイス、媒体、及びメモリは、ビットストリーム及び同様のものを有するケーブルまたは無線信号を含むことができる。しかしながら、言及されるときに、非一時的なコンピュータ可読記憶媒体は、エネルギー、搬送信号、電磁波、及び信号自体を明確に除外する。

上述される実施例による方法は、格納される、またはその他の方法によりコンピュータ可読媒体から利用可能である、コンピュータ実行可能命令を使用して、実装されることができる。これらのような命令は、例えば、汎用コンピュータ、専用コンピュータ、もしくは専用処理デバイスに、ある特定の機能、もしくは機能群を実行させる、またはその他の方法により汎用コンピュータ、専用コンピュータ、もしくは専用処理デバイスがある特定の機能、もしくは機能群を実行するように設定する、命令及びデータを含むことができる。使用されているコンピュータリソースの部分は、ネットワーク経由でアクセス可能である。コンピュータ実行可能命令は、例えば、バイナリ、アセンブリ言語などの中間形式命令、ファームウェア、またはソースコードであり得る。命令、使用される情報、及び／または記述された実施例に従う方法中に作成される情報を格納するために使用されることができるコンピュータ可読媒体の実施例は、磁気または光ディスク、ソリッドステートメモリデバイス、フラッシュメモリ、不揮発性メモリによって提供されるＵＳＢデバイス、ネットワーク化されたストレージデバイスなどを含む。

これらの開示に従う方法を実装するデバイスは、ハードウェア、ファームウェア及び／またはソフトウェアを含むことができ、さまざまなフォームファクタのいずれかを取ることができる。これらのようなフォームファクタの典型的な実施例は、サーバ、ラップトップ、スマートフォン、スモールフォームファクタパーソナルコンピュータ、パーソナルデジタルアシスタントなどを含む。また、本明細書に記述される機能性は、周辺機器またはアドインカードに具体化されることができる。また、このような機能性は、さらなる実施例として、異なるチップ間回路基板、または単一のデバイス中で実行する異なるプロセスに実装されることができる。

これらの命令、これらのような命令を伝えるための媒体、それらを実行するためのコンピューティングリソース、及びこれらのようなコンピューティングリソースをサポートするための他の構造は、これらの開示に記述される機能を提供するための手段である。

さまざまな実施例及び他の情報を使用して、添付の特許請求の範囲内で態様を説明したが、特許請求の範囲の制限は、当業者がこれらの実施例を使用して多種多様な実施態様を導出することができる場合に、これらのような実施例における特定の特徴または配置に基づき黙示的に伝えられるべきではない。さらに、ある発明の主題が構造的特徴及び／または方法ステップの実施例に特有の言語で記述されている場合があるが、添付の特許請求の範囲に定義されている本発明の主題がこれらの記述された特徴また行為に必ずしも限定されないことを理解するであろう。例えば、このような機能性は、本明細書において特定されている構成要素以外の構成要素に、異なるように分散される、または実行されることができる。むしろ、記述された特徴及びステップは、添付の特許請求の範囲内でシステム及び方法の構成要素の実施例として開示されている。

Claims (17)

1. それぞれのステップがクライアントデバイスにより実行される、コンピュータで実施される方法であって、前記コンピュータで実施される方法は、
   コンテンツ管理システムから操作データを受信することであって、前記操作データは操作ログを含む、前記受信することと、
   前記コンテンツ管理システム上に格納されるコンテンツアイテムの状態を示すリモートツリーを前記操作ログと比較して、前記リモートツリーを最新にするために適用される前記操作ログのサブセットを決定することと、
   前記操作ログの前記サブセットを実行することと、
   前記操作ログのサブセットの実行に基づき、前記リモートツリーを更新することと、
   前記リモートツリーと同期ツリーとの間の差異に基づき、前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態とが同期していないと判定することであって、前記同期ツリーが、前記リモートツリーに関連付けられた状態とローカルツリーに関連付けられた状態との間の差異を表し、前記ローカルツリーが、前記クライアントデバイス上に格納されるコンテンツアイテムについての状態を示す、前記判定することと、
   前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態との間の前記差異に基づき、前記リモートツリーに関連付けられた状態及び前記ローカルツリーに関連付けられた状態を収束させるように設定される操作セットを生成することと、
   前記操作セットの実行を管理することと、
   を備える、コンピュータで実施される方法。
2. カーソルを前記コンテンツ管理システムに送信することをさらに備え、前記カーソルは、前記操作ログ中の最後に受信したエントリ識別子であり、前記操作ログのどの部分を前記クライアントデバイスへ送信するかを判定するために用いられる、請求項１に記載のコンピュータで実施される方法。
3. 前記操作データは、複数のネームスペースにわたり線形化された複数の操作を備え、前記複数の線形化された操作は正しいシーケンスに順序付けされている、請求項１に記載のコンピュータで実施される方法。
4. 前記操作データは、ネームスペースについてのリビジョンデータを備える、請求項１に記載のコンピュータで実施される方法。
5. 前記リモートツリー及び前記同期ツリーは、クライアントデバイスに格納される、請求項１に記載のコンピュータで実施される方法。
6. 前記コンテンツ管理システムから、リモートツリー中に表される既存のネームスペース内にターゲットネームスペースをマウントするためのマウント通知を受信することと、
   前記コンテンツ管理システムから、前記ターゲットネームスペースについての操作ログの第１の部分を受信することと、
   前記操作ログの前記第１の部分に基づき前記ターゲットネームスペースについてのサブツリーを構築することと、
   前記ターゲットネームスペースについての前記サブツリーを前記リモートツリーのマウント位置にマウントすることと、
   をさらに備える、請求項１に記載のコンピュータで実施される方法。
7. 前記操作ログの前記第１の部分は、前記コンテンツ管理システムによって検出されるマウント操作についてのカーソルにおいて、第１のデータに対する前記操作ログの開始によって区切られ、前記カーソルは前記操作ログにおける最後に受信したエントリの識別子であり、前記操作ログのどの部分を前記クライアントデバイスに送信するかを判定するために用いられる、請求項６に記載のコンピュータで実施される方法。
8. 前記ターゲットネームスペースについての前記サブツリーは、前記操作ログの前記第１の部分を処理して前記サブツリーを構築した後にマウントされる、請求項６に記載のコンピュータで実施される方法。
9. 前記コンテンツ管理システムから、前記ターゲットネームスペースについてのマウント操作を受信することであって、前記マウント操作は既存のネームスペースと関連付けられ、前記既存のネームスペース中で前記マウント位置を指定する、前記受信すること、
   をさらに備え、
   前記ターゲットネームスペースは前記マウント操作に応答して前記マウント位置にマウントされる、
   請求項６に記載のコンピュータで実施される方法。
10. 命令を含むコンピュータプログラムであって、
    前記命令は、コンピューティングシステムによって実行されるときに、前記コンピューティングシステムに、
    コンテンツ管理システムから操作データを受信することであって、前記操作データは操作ログを含む、前記受信することと、
    前記コンテンツ管理システム上に格納されるコンテンツアイテムの状態を示すリモートツリーを前記操作ログと比較して、前記リモートツリーを最新にするために適用される前記操作ログのサブセットを決定することと、
    前記操作ログの前記サブセットを実行することと、
    前記操作ログのサブセットの実行に基づき、前記リモートツリーを更新することと、
    前記リモートツリーと同期ツリーとの間の差異に基づき、前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態とが同期していないと判定することであって、前記同期ツリーが、前記リモートツリーに関連付けられた状態とローカルツリーに関連付けられた状態との間の差異を表し、前記ローカルツリーが、前記コンピューティングシステム上に格納されるコンテンツアイテムについての状態を示す、前記判定することと、
    前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態との間の前記差異に基づき、前記リモートツリーに関連付けられた状態及び前記ローカルツリーに関連付けられた状態を収束させるように設定される操作セットを生成することと、
    前記操作セットの実行を管理することと、
    を行わせる、コンピュータプログラム。
11. 前記命令は、前記コンピューティングシステムに、カーソルを前記コンテンツ管理システムに送信することをさらに行わせ、前記カーソルは、前記操作ログ中の最後に受信したエントリ識別子であり、前記操作ログのどの部分を前記コンピューティングシステムへ送信するかを判定するために用いられる、請求項１０に記載のコンピュータプログラム。
12. 前記操作データは、複数のネームスペースにわたり線形化された複数の操作を備え、前記複数の線形化された操作は正しいシーケンスに順序付けされている、請求項１０に記載のコンピュータプログラム。
13. 前記操作データは、ネームスペースについてのリビジョンを備える、請求項１０に記載のコンピュータプログラム。
14. システムであって、
    少なくとも１つのプロセッサと、
    命令を格納するコンピュータ可読媒体であって、前記命令が前記少なくとも１つのプロセッサによって実行されるときに、前記少なくとも１つのプロセッサに、
    コンテンツ管理システムから操作データを受信することであって、前記操作データは操作ログを含む、前記受信することと、
    前記コンテンツ管理システム上に格納されるコンテンツアイテムの状態を示すリモートツリーを前記操作ログと比較して、前記リモートツリーを最新にするために適用される前記操作ログのサブセットを決定することと、
    前記操作ログの前記サブセットを実行することと、
    前記操作ログのサブセットの実行に基づき、前記リモートツリーを更新することと、
    前記リモートツリーと同期ツリーとの間の差異に基づき、前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態とが同期していないと判定することであって、前記同期ツリーが、前記リモートツリーに関連付けられた状態とローカルツリーに関連付けられた状態との間の差異を表し、前記ローカルツリーが、前記システム上に格納されるコンテンツアイテムについての状態を示す、前記判定することと、
    前記リモートツリーに関連付けられた状態と前記同期ツリーに関連付けられた状態との間の前記差異に基づき、前記リモートツリーに関連付けられた状態及び前記ローカルツリーに関連付けられた状態を収束させるように設定される操作セットを生成することと、
    前記操作セットの実行を管理することと、
    を行わせる、コンピュータ可読媒体、
    を備える、システム。
15. 前記命令は、前記少なくとも１つのプロセッサに、カーソルを前記コンテンツ管理システムに送信することをさらに行わせ、前記カーソルは、前記操作ログ中の最後に受信したエントリ識別子であり、前記操作ログのどの部分を前記システムへ送信するかを判定するために用いられる、請求項１４に記載のシステム。
16. 前記操作データは、複数のネームスペースにわたり線形化された複数の操作を備え、前記複数の線形化された操作は正しいシーケンスに順序付けされている、請求項１４に記載のシステム。
17. 前記操作データは、ネームスペースについてのリビジョンデータを備える、請求項１４に記載のシステム。

Images