JP5611059B2 - ウェブベースのマルチユーザコラボレーション - Google Patents

Description

様々な理由により、互いに地理的に離れた異なるユーザが、ドキュメントに対して協調的に作業したいと望むことがある。

このタイプのリモートのコラボレーションを容易にするための従来の技術は、典型的に、これら異なるユーザが豊富な機能のクライアントをリモートワークステーション上にインストールすることを必要とする。

ウェブベースのマルチユーザコラボレーション（multiuser collaboration）ためのツールおよび方法を開示する。これらツールは、ユーザが、個々のブラウザを使用してドキュメントに対してリモートで協調的に作業できるようにする方法を提供することができる。これら方法は、所与のドキュメントの一部の表示をブラウザに送信し、ドキュメントの一部を特定のユーザに関連付けることができる。ブラウザは、ユーザによって提供されるコマンドの表示を受信し、該コマンドをブラウザで実行するかどうかを決定することができる。これらの方法は、ドキュメントの一部に対するリビジョン（revision）をブラウザから受信することと、ドキュメントのこれらの一部を、比較的最近変更したコンテンツを格納するように構成されたストレージエリアに格納することも含むことがある。

上述した本発明の主題は、方法、コンピュータ制御装置、コンピュータプロセス、コンピュータシステム、またはコンピュータ読取可能媒体などの製品として実装することもできる。これらの特徴および様々な他の特徴は、以下の詳細な説明を読み、関連する図面を検討することにより、明らかになるであろう。

この発明の概要は、以下の詳細な説明でさらに説明される概念の選択を簡単な形で紹介するために提供されるものである。この発明の概要は、特許請求される主題の重要な特徴または本質的な特徴を特定するようには意図されておらず、この発明の概要の記載が、特許請求される主題の範囲を限定するのに使用されることも意図されていない。さらに、特許請求される主題は、本開示の任意の部分において示される欠点の全てまたは全てを解決する実装には限定されない。

ウェブベースのマルチユーザコラボレーションを提供するためのシステムまたは動作環境を示すブロックとフローの組み合わせの図である。 図１に示されるコラボレーションプロセスを開始することに関連するコンポーネントおよびデータフローを示すブロックとフローの組み合わせの図である。 特定のドキュメントに対する協調作業（例えば、編集）を開始するための処理を示すフロー図である。 所与のブラウザにおいてコラボレーションを開始するためのコンポーネントおよびデータフローを示すブロックとフローの組み合わせの図である。 協調ユーザによるドキュメントに対するリビジョンを処理するためのコンポーネントおよびフローを示すブロックとフローの組み合わせの図である。 ブラウザによって報告されるリビジョンを処理するためのプロセスを示すフロー図である。 複数のユーザによって協調的に編集されるコンテンツに対するリビジョンをブラウザが処理できるようにするコンポーネントおよびデータフローを示すブロックとフローの組み合わせの図である。 ブラウザからリビジョンを受信して処理するためのサーバ側のコンポーネントおよびデータフローを示すブロックとフローの組み合わせの図である。 協調クライアントサービスを提供するためのサーバ側のコンポーネントを示すブロックとフローの組み合わせの図である。

以下の詳細な説明は、ウェブベースのマルチユーザコラボレーションのための技術を対象としている。本明細書で説明される主題は、コンピュータシステムにおけるオペレーティングシステムおよびアプリケーションプログラムの実行との関係で実行されるプログラムモジュールの一般的なコンテキストで提示されるが、当業者には、他のタイプのプログラムモジュールと組み合わせで他の実装も実施され得ることが認識されよう。一般に、プログラムモジュールは、ルーチン、プログラム、コンポーネント、データ構造、および特定のタスクを実行するか特定の抽象データ型を実装する他のタイプの構造を含む。さらに当業者には、本明細書で説明される主題は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなどを含め、他のコンピュータシステム構成で実施され得ることが理解されよう。

以下の詳細な説明において、特定の実施形態または実施例の一部を形成し、その特定の実施形態または実施例を図によって示している添付図面を参照する。いくつかの図面を通して同様の番号が同様の要素を表している図面を参照して、構造化されたデータ要素にアクセスして更新するマルチクライアントコラボレーションのためのツールおよび技術の態様を説明する。

図１は、全体的に符号１００で示されている、ウェブベースのマルチユーザコラボレーションを提供するためのシステムまたはオペレーティング環境を図示している。システム１００は、以下でさらに詳細に説明されるように、任意の数のフロントエンドサーバおよび／またはバックエンドサーバを含む本説明の実装とともに、１つまたは複数のサーバシステム１０２を含むことができる。該サーバは、特定の実装に適切なものとして選択された特定のタイプまたはアーキテクチャを有する、１つまたは複数のプロセッサ１０４を含むことができる。プロセッサ１０４は、該プロセッサ１０４との互換性のために選択された１つまたは複数のバスシステム１０６に結合することができる。

サーバ１０２は、バスシステム１０６に結合されるコンピュータ読取可能記憶媒体１０８の１つまたは複数のインスタンス（instance）を含むこともできる。そのバスシステムにより、プロセッサ１０４は、コンピュータ読取可能記憶媒体１０８との間でコードおよび／またはデータの読み取りを行うことができる。媒体１０８は、これらには限られないが半導体、磁性材料、光学などを含め、任意の適切な技術を使用して実装されたストレージ要素を表すことができる。媒体１０８は、ＲＡＭ、ＲＯＭ、フラッシュ、または他のタイプとして分類されるか否かに関わらずメモリコンポーネントを含み、またハードディスクドライブを表すこともある。

記憶媒体１０８は、プロセッサ１０４にロードされて実行されると、サーバ１０２にウェブベースのマルチユーザコラボレーションを容易にするための様々な技術を実行させる、命令の１つまたは複数のモジュールを含むことができる。より具体的には、記憶媒体１０８は、複数のクライアントシステムに協調クライアントサービス（collaborative client service）１１０を提供する命令のモジュールを含むことができる。図１は、そのようなクライアントシステムの２つの例を、１１２ａと１１２ｎ（集合的に、クライアントシステム１１２）として提供している。しかしながら、この説明の実装は多くのクライアントシステムを含むこともできる。

記憶媒体１０８は、ドキュメントストア１１４の１つまたは複数のインスタンスを含むことができる。ドキュメントストアの詳細は以下で提供するが、概要としては、ドキュメントストアは、複数のクライアントシステムが協調して編集または作成したドキュメントを保管または含む。図１は、ドキュメントストア１１４と協調クライアントサービス１１０のソフトウェアが同じ記憶媒体１０８上に存在するシナリオについて図示しているが、この実施例は、単に説明を容易にするためだけに提供されるものであり、可能な実装を制限するものではない。一部のシナリオにおいて、ドキュメントストアおよび協調クライアントサービスが別個の媒体および／または別個のシステムもしくは物理的ボックスに存在することもあることに特に留意されたい。

協調クライアントサービス１１０をより詳細に参照すると、このサービスは、サーバ１０２とクライアントシステム１１２との間の協調フローを容易にすることができる。図１では、協調フローの２つの例、すなわち、サーバ１０２とクライアントシステム１１２ａとの間のデータおよび処理フローを表す協調フロー１１６ａと、サーバ１０２とクライアントシステム１１２ｎとの間のデータおよび処理フローを表す協調フロー１１６ｎが提供されている。

クライアントシステム１１２をより詳細に参照すると、これらのクライアントシステムは、個々のプロセッサ１１８ａおよび１１８ｎ（集合的に、プロセッサ１１８）を含むことができ、ここでプロセッサ１１８ａおよび１１８ｎは、プロセッサ１０４と同じタイプおよびアーキテクチャであっても、異なっていてもよい。図１に示されるように、バスシステム１２０ａおよび１２０ｎ（集合的に、システム１２０）はそれぞれ、プロセッサ１１８ａおよび１１８ｎに結合する。これらのバスシステム１２０は、対応するプロセッサ１１８のタイプおよびアーキテクチャと互換性があるものにすることができ、サーバ１０２上のバスシステム１０６と同じタイプおよび同じアーキテクチャであっても異なるものであってもよい。コンピュータ読取可能記憶媒体１２２ａおよび１２２ｎ（集合的に、記憶媒体１２２）のそれぞれのインスタンスは、ブラウザソフトウェア１２４ａおよび１２４ｎ（集合的に、ブラウザ１２４）を含むことができる。

本明細書で説明されるように、クライアントシステム１１２とサーバシステム１０２は協力して、個々のエンドユーザ１２６ａおよび１２６ｎ（集合的に、エンドユーザ１２６）がドキュメントストア１１４からのドキュメント（全体または一部）を協調して編集および／または作成できるようにすることができる。一部のシナリオでは、異なるエンドユーザ１２６が協調して所与のドキュメントの同じ部分を編集することができる。他のシナリオでは、異なるエンドユーザ１２６が、所与のドキュメントの異なる部分について説明する（elaborate）ことができる。

サーバシステム１０２と様々なクライアントシステム１１２は、一般的に１２８で表されている１つまたは複数の適切なネットワーク上で相互に通信することができる。このようなネットワーク１２８は、グローバルネットワーク、地域（regional）ネットワーク、ローカルネットワーク、パーソナルネットワーク、または他のタイプのネットワークとして特徴付けられるかどうかに関わらず、任意の適切な形式をとることができる。サーバシステムおよびクライアントシステムは、ネットワーク１２８とインタフェースをとるのに適切な任意のネットワークアダプタ、ハードウェア、ソフトウェア、プロトコル・スタックなどを含みことができるが、これらの特徴は明確性および簡潔性のために図１から省略されている。

以下でさらに詳細に説明されるように、協調クライアントサービス１１０は、ユーザ１２６が、ブラウザを使用してドキュメントの少なくとも一部分を協調して編集または作成することができるようにすることができる。ユーザ１２６はブラウザを使用することができるので、クライアントシステム１１２は、ユーザがこの協調的な経験において浪費することとなる追加のクライアントソフトをインストールすることを防止することができる。協調クライアントサービス１１０はユーザ１２６に、ユビキタスなブラウザ（ubiquitous browser）を通じてより良いクライアント経験を提供することができる。より具体的には、協調クライアントサービスは、ユーザが、これらには限られないが文書処理、データベース管理、表計算管理、データ共有、電子ノート機能などを含め、様々なタイプのエンドユーザの機能にアクセスできるようにすることができる。これらのユーザ経験を可能にするために、サーバ側の協調クライアントサービスは、上記の機能の全てを実行する機能豊富な（feature-rich）クライアントによって使用される任意のネイティブ（native）のフォーマットに変更すること／該任意のネイティブのフォーマットから変換することができる。

図１においてサーバおよびクライアントシステムを示すのに使用された図形的要素は、単に説明を容易にするためだけに選択されたものであり、本明細書の説明に関して可能な実装を制限するように選択されたものではない。特に、図１は、サーバシステム１０２が、２つ以上のクライアントシステムによって共有される可能性もある集中コンピュータシステムである例を示している。クライアントシステム１１２は、デスクトップシステム、ラップトップもしくはモバイルコンピューティングシステム、スマートフォン、ワイヤレスで使用可能な携帯情報端末（ＰＤＡ）、または他の適切なシステムを表すことができる。しかしながら、本明細書の説明は、これらには限定されないが図１に示される例を含め、他の形式のサーバおよび／またはクライアントシステムもイとされている。

図１に示されるシステムおよびオペレーティング環境について説明したので、次に、協調プロセスの開始に関連するコンポーネントおよびフローの説明に移る。この説明を図２を用いて行う。

図２は、全体的に２００で示されるように、図１に図示される協調プロセスを開始することに関連するコンポーネントおよびデータフローを図示している。限定ではなく説明の容易性のために、図２は、前の図面の一部の参照番号を引用して同様の項目を示している。例えば、図２は、協調クライアントサービス１１０、ドキュメントストア１１４、ネットワーク１２８、ブラウザ１２４、およびユーザ１２６の表示を図１から引用している。

ドキュメントストア１１４をさらに詳細に参照すると、ドキュメントストアは、クライアントシステムおよびエンドユーザによるコラボレーションに利用可能なドキュメントのモデルを実装することができる。より具体的には、これらモデルは、これらの協調作業に（collaboration effort）おける効率および最適化の改善を容易にすることができる。例えば、特定のドキュメントのモデルは、該ドキュメントの特定の意味的な部分（semantic piece）を、本明細書でセル（cell）と呼ばれる構成（construct）に割り当てることができる。さらに、本明細書で説明される別の構成はリビジョンであり、該リビジョンは、特定の時間にとられたセルのスナップショットであり、その後そのポイントにおける該セルの表示を提供する。例えば、所与のドキュメント内の個々のページを、特定のセルを使用して表すことができる。同様に、特定のリビジョンを、セルに対応するコンテンツの特定の部分または態様を表す１つまたは複数のオブジェクトにさらに分割することができる。例えば、オブジェクトは、所与のページ内に現れているパラグラフまたはイメージ、所与のリスト内に現れている箇条書の部分（bullet point）などを含むことができる。

図２は、諸実装では１つまたは複数のドキュメントを表すのに適切なように任意の数のセル構造を含むことができるという理解の下において、２０２でリビジョン構造の例を図示している。同様に、所与のリビジョン構造が１つまたは複数のオブジェクトを含み得ることを、図２では、オブジェクトの例を２０４ａおよび２０４ｎ（集合的にオブジェクト２０４）で図示している。特定のオブジェクトは対応するＩＤによって識別される。これらのオブジェクトは、同じセル内の他のオブジェクトを指す（point）ことができ、あるいは他のセル内のオブジェクトを指すことができる。

協調クライアントサービス１１０は、異なるエンドユーザ１２６によるコラボレーションのための所与の特定のドキュメントからの１つまたは複数のリビジョンを、ブラウザ１２４を介して送信することができる。例えば、協調クライアントサービス１１０は、所与のドキュメント内のどのリビジョンが、異なるエンドユーザにとって関心のあるものかを決定して、次いでブラウザにおける表示のためにそれらリビジョンを、そのエンドユーザに送信することができる。図２では、ユーザ１２６ａによる対話のためにブラウザ１２４ａに送信されたリビジョンの例を２０６ａで示しており、ユーザ１２６ｂによる対話のためにブラウザ１２４ｂに送信されたリビジョンの例を２０６ｂで示しており、ユーザ１２６ｎによる対話のためにブラウザ１２４ｎに送信されたリビジョンの例を２０６ｎで示している。

協調クライアントサービス１１０は、所与のドキュメントの特定のリビジョン２０６のうちのいずれのリビジョンが、様々なクライアントブラウザに配信されるべきかを決定することができる。例えば、協調クライアントサービスは、初めに、所与のドキュメント内の全てのページの名前を含むナビゲーションページを、最初のページのみのコンテンツとともにブラウザに送信することができる。そのブラウザにおいて、異なるユーザは、それらの個々のナビゲーションページをクリックして、どのページを見て編集したいか選択することができる。その後、協調クライアントサービスは、選択されたページのコンテンツを、その様々なブラウザにダウンロードすることができる。例えば、異なるユーザ１２６は、所与のドキュメント内の同一または異なるページにスクロールすることができる。この例においては、協調クライアントサービスは、異なるユーザが編集したいと望むページを一旦決定すると、該クライアントサービスは、ドキュメントストア１１４からそのページに対応するリビジョン２０８を取得することができる。同様に、協調クライアントサービスは、２０６ａ、２０６ｂ、および２０６ｎ（集合的に、配信されたリビジョン２０６）で表されるように、これらのリビジョンを適切なユーザに配信することができる。

異なるシナリオでは、協調クライアントサービスは、特定のユーザによって編集されている所与のページだけでなく、ドキュメント内のその所与のページの前および／または後にある、ある特定の数のページも配信することができる。特定の数の「先の（look-ahead）」ページまたは「後ろの（look-behind）」ページを提供することによって、協調クライアントサービスは追加のリビジョンを送信することなく、これらのユーザが、いくつかの連続するページをスクロールすることを可能にする。

以下でさらに詳細に説明されるように、セルモデルは、ドキュメントストアが、異なるエンドユーザ（例えば、１２６）間のより効果的なコラボレーションを容易にすることを可能にする。例えば、ドキュメントのリビジョン表示は、典型的に、ドキュメントを全体として表示するよりもはるかに小さい。

以下でさらに詳細に説明されるように、ドキュメントのセルモデルは、ドキュメントストアが、異なるエンドユーザ（例えば、１２６）間のより効果的なコラボレーションを容易にすることを可能にする。例えば、ドキュメントのリビジョン表示は、典型的に、ドキュメントを全体として表示するよりもはるかに小さい。したがって、協調クライアントサービスは、リビジョン表示を送信することによって、全体のドキュメントを異なる協調ユーザおよびクライアントシステムに送信することに比べてネットワークリソースの消費を低減し、ネットワークの帯域幅を抑えることができる。

協調クライアントサービスが特定のリビジョン２０６をブラウザに配信すると、これらサービスは、一般的に２１０で示される協調情報（collaboration information）を格納することができる。例えば、この協調情報は、どの特定のリビジョンがどの特定のユーザに配信されたかを示すことができる。協調クライアントサービスは、この情報を、異なるユーザ１２６の表示２１４ａおよび２１４ｍ（集合的に、ユーザ表示２１４）を含むサーバ側のリビジョンストア２１２に格納することができる。同様に、ユーザ表示２１４は、２１６ａおよび２１６ｍ（集合的に、リビジョン表示２１６）で示されるように、どのリビジョンが特定のユーザに配信されたかを示すことができる。以下でさらに詳細に説明されるように、サーバ側のリビジョンストア内のこれらのエントリにより、協調クライアントサービスは、特定のユーザによって作成されたどのリビジョンが他のユーザに関連し得るのかを判断することが可能になる。

図２の様々なクライアントシステムとユーザとの間のコラボレーションを開始することに関連するコンポーネントとフローについて説明したので、次に、特定のドキュメントに対する協調作業を開始するのに実行される処理フローの説明に移る。この説明は図３を用いて行う。

図３は、符号３００で全体的に示されるように、特定のドキュメントに対する協調作業（例えば、編集）を開始するための処理フローを図示している。限定ではなく説明の容易性のために、図３では、前の図面から一部の参照番号を引用して同様の項目を示している。例えば、図３は、前の図面から協調クライアントサービス１１０の表示を引用している。プロセスフロー３００を、これらの協調クライアントサービスとの関連で説明するが、この説明の範囲および趣旨から逸脱することなく、他の構成要素またはサービスによってプロセスフロー３００の実装を実施することもできることに留意されたい。

処理フロー３００をより詳細に参照すると、ブロック３０２は一般的に、所与のドキュメントのうち、１または複数の特定のユーザにとって関心の対象となるセルを識別することを表している。例えば、ブロック３０２は、所与のドキュメントのページの名前を、該ドキュメントの最初のページのコンテンツとともに協調ユーザに送信することを含むことができる。ユーザは、次いで、自身が見たいページの名前を選択することができる。ブロック３０２は、特定のユーザにとって関心の対象となる所与のセルに関して、「先の」および／または「後ろの」のいくつかのレベルを提供することを含むことができる。ドキュメントのセルモデルに関する上記説明を思い起こすと、特定のセルは、例えばこれらのドキュメント内のページを表すことができる。

ブロック３０４は一般的に、ブロック３０２で識別された関心のリビジョンを取得することを表している。例えば、ブロック３０４は、様々な異なるユーザが本明細書で説明されるツールおよび技術を使用して協調的に作業することができるコンテンツを含んでいるドキュメントストアから、関心のリビジョンを取得することを含むことができる。図２では、符号１１４でそのようなドキュメントストアの例を提供しており、セルの例を２０８で示している。

ブロック３０６は一般的に、取得された関心のリビジョンを特定のユーザに送信することを表している。例えば、図２に示されるように、３人の異なるユーザ（例えば、ユーザ１２６ａ、１２６ｂ、および１２６ｎ）が所与のドキュメントに対して協調的に作業することを想定すると、これらのユーザは、この所与のドキュメントの同じまたは異なる部分に興味を示すことがある。したがって、ブロック３０６は、所与のドキュメントの適切な部分のリビジョン表示（例えば、２０６ａ、２０６ｂ、および２０６ｎ）を、これらの異なるユーザに送信することを含むことができる。

ブロック３０８は一般的に、特定のユーザを、これらのユーザが操作しているセルに関連付けることを表している。例えば、ブロック３０８は、特定のユーザ（例えば、図２の２１４）の表示を、リビジョン（例えば、図２のリビジョン表示２１６）がそれらのユーザに提供されているセルに関連付けることを含むことができる。

ブロック３１０は一般的に、ブロック３０８で定義された関連付け（association）を格納することを表している。例えば、ブロック３１０は、サーバ側のリビジョンストア（例えば、２１２）を更新して、図２の２１４および２１６で示されるように、作業しているユーザと該ユーザが協調的に作業しているセルとの間の関連付けまたは関係（relationship）を格納することができる。

特定のドキュメントに対する協調作業を開始するための処理フロー３００を説明したので、次に、ブラウザ側でこのコラボレーションを開始させるコンポーネントおよびフローに関するより詳細な説明に移る。この説明を図４を用いて行う。

図４は、全体的に４００で示されるように、所与のクライアントシステムにおいてブラウザ側でコラボレーションを開始させるコンポーネントおよびフローを図示している。限定ではなく説明の容易性のために、図４は、前の図面から一部の参照番号を引用して同様の項目を示している。例えば、図４は、前の図面からネットワーク１２８、配信されたセル２０６、ブラウザ１２４、およびユーザ１２６を引用している。

図４をさらに詳細に参照すると、クライアント側の複製マネージャ（replication manager）４０２は、配信されたリビジョン２０６をサーバ１０２からネットワーク１２８を介して受信することができる。これらのリビジョン２０６は、最初にユーザ１２６に対して提示されたページを表すことがあり、あるいは他の協調ユーザによってこれらセルに対して作成されたリビジョンを表すことがある。図４を説明するために、セル２０６は、ブラウザ１２４を介して最初にユーザ１２６に提示されたページを表すと仮定する。

通常、複製マネージャ４０２は、ブラウザとサーバとの間でセルに対するリビジョンをアップロードすること、およびダウンロードすることができる。複製マネージャは、ネットワークとブラウザとの間においてプロトコルを適切なものに変換することもできる。２０６で示されるリビジョンは、ネットワーク送信に適したプロトコルにあることが想定されているが、図４では、４０４で示されるリビジョンは、ブラウザによる処理に適したものとなるように変換される。

複製マネージャ４０２は、リビジョン４０４をクライアント側のリビジョンストア４０６に転送することができる。通常、該リビジョンストアは、これらのリビジョンまたは変更が所与のブラウザ１２４でローカルに生じたものかどうか、あるいは他のブラウザでリモートに生じて所与のローカルブラウザ１２４へ報告されたものであるかどうかに関わらず、セル２０６を生じるリビジョン（または、それらのリビジョンに対する変更）を管理して格納することができる。リビジョン４０４に関連する所与の協調作業を開始するとき、リビジョンストア４０６は、将来に参照するために、これらのセル４０８の初期状態（initial state）またはリビジョンを格納することができる。

リビジョンストア４０６は、協調的に編集されているドキュメントの意味モデル（semantic model）を提供するセルの表示をグラフデータ構造（graph data structure）４１０に提供することができ、その意味モデルはドキュメントの階層構造（hierarchy）を提供する。データ／ビューモデルの実装を想定すると、グラフ構造４１０は、このモデルのデータ部を提供することができる。グラフ構造４１０は、異なるタイプのノード、プロパティセット、および受信（incoming）セル２０６を表す他の要素を含む有向非巡回グラフとすることができる。図４は、ノードの例を４１２ａおよび４１２ｎ（集合的に、グラフノード４１２）で示している。例えば、ある受信リビジョンが、協調的に編集されたドキュメントの１ページを表すと想定すると、グラフ構造４１０内の異なるノード４１２は、異なるパラグラフ、イメージ、ページ、セクション、または該ページ内の他の部分もしくはサブ要素を表すことができる。一部のオブジェクトは、グラフ（例えば、イメージ）内の１つのノードを用いて表されるが、表などの他のコンテンツは、グラフ内の多くのノードを用いて表されることがある。

限定ではないが例示的な実装において、クライアント側の複製マネージャ４０２、クライアント側のリビジョンストア４０６、初期セル状態４０８、およびグラフ構造４１０を、Ｓｃｒｉｐｔ＃で作成し、ＪａｖａＳｃｒｉｐｔで実装することができる。しかしながら、これらの例は、単にこの説明を容易にするために提供されるものであり、異なる実装では他のシナリオも可能である。

グラフ構造４１０は、受信リビジョン２０６によって表されるコンテンツのブラウザ独立型モデル（browser-independent model）を提供することができる。また、このグラフ構造内のノード４１２を、様々な異なる部分的に利用可能なブラウザのうちのいずれか１つでレンダリングすることができる。したがって、ビューモデルまたはビューコード４１４は、これらのノード４１２を、グラフ構造４１０からブラウザ依存型ビューイングモデル（browser-dependent viewing model）にレンダリングすること、またはマッピングすることができる。図４は、このようなビューイングモデルの例をドキュメントオブジェクトモデル（ＤＯＭ）４１６として提供している。ＤＯＭ４１６は、協調的に編集されたドキュメントの現在のビュー、パラグラフの表示、イメージ、リスト、あるいはドキュメントの１つまたは複数のページ内に現れている他の要素を格納することができる。

ビューコード４１４は、ＤＯＭ内のノード４１８ａおよび４１８ｎ（集合的に、ＤＯＭノード４１８）に対応するグラフ構造内のノード４１２ａおよび４１２ｎを用いて、グラフ構造４１０からＤＯＭを作成することができる。その後、ＤＯＭ４１６を、ユーザ１２６による参照のためにブラウザ１２４上にレンダリングすることができる。図４は、任意の所与の時間においてユーザによる参照が可能なようにレンダリングされたコンテンツの部分を、ブラウザビューポート４２０として示している。ユーザは、適切であるとわかると、ブラウザビューポート内に表されたいずれか要素に対して対話することができる。

図４では、特定のドキュメントに対する協調作業を開始するためのコンポーネントおよびフローを説明したので、次に、協調して作業をするユーザによってドキュメントに対して行われたリビジョンを処理するためのコンポーネントおよびフローを説明する。この説明を図５を用いて行う。

図５は、全体的に５００で示されるように、協調して作業するユーザによってドキュメントに対して行われたリビジョンを処理するためのコンポーネントおよびフローを図示している。限定ではなく説明の容易性のために、図５は、前の図面から一部の参照番号を引用して同様の項目を示す。例えば、図５は、前の図面からネットワーク１２８、ブラウザ１２４、ユーザ１２６、協調クライアントサービス１１０、サーバ側のリビジョンストア２１２、およびユーザ２１４とリビジョン２１６に関連する表示を引用している。

図５をさらに詳細に参照すると、図５では、ユーザ１２６ａおよび１２６ｂが所与のドキュメント内の同じセルに対して協調的に作業していると想定している。図５は、ユーザ１２６ａと１２６ｂの間の共有されるこのセルを、５０２ａおよび５０２ｂで示している。上述したように、サーバ側のリビジョンストア２１２は、このシナリオを示すように、ユーザ表示２１４およびリビジョン表示２１６を作成して記憶することができる。ユーザ１２６ａが、共有セル５０２ａに対するリビジョン５０４ａを作成する場合、ブラウザ１２４ａは、これらリビジョンを協調クライアントサービス１１０に送信することができる。リビジョン５０４ａの通知は、セル５０２ａが修正（revise）されたことを示すこともできる。

リビジョン５０４ａの通知を受信すると、協調クライアントサービス１１０は、これらリビジョン５０４ａが、他のユーザによって編集されているセルに関連するかどうかを判断することができる。この判断を行うために、協調クライアントサービス１１０は、サーバ側のリビジョンストア２１２に問い合わせて、任意の他のユーザがセル５０２ａを編集しているかどうかを判断することができる。この場合、このクエリは、ユーザ１２６ｂも、ちょうど修正されたセル５０２ａを編集していることを示す可能性がある。さらに、ブラウザ１２４ｂは、協調クライアントサービス１１０に、セル５０２に対する任意の新たな変更に関して問い合わせることができる。このように、協調クライアントサービスを実行するサーバは、２つのクライアントがセル５０２に対して協調的に作業していると暗黙的に判断することができる。したがって、一部のシナリオでは、協調クライアントサービス１１０は、これらリビジョンの通知を形成してブラウザ１２４ｂに送信することができる。他のシナリオでは、協調クライアントサービスは、ブラウザ１２４ｂから要求を受信することができ、そしてそのような要求に対して、セル５０２に対する適切なリビジョンを用いて応答することができる。図５は、これらおよび他のシナリオを全体的に５０４ｂで示している。同様に、ブラウザ１２４ｂは、リビジョン５０４ｂを組み込むように、該ブラウザの表示を更新することができる。

図５に示されるこのシナリオでは、ユーザ１２６ｎは、ユーザ１２６ａと１２６ｂによって共有されているセル５０２ａと５０２ｂ（集合的に、セル５０２）とは異なる、セル５０６を編集していると想定されている。これら異なるセル５０２と５０６は、同じドキュメント内にあるが、ユーザ１２６ｎは現在、セル５０２を編集していない。このシナリオでは、他のユーザによって作成された、このセル５０２に対するリビジョンは、ユーザ１２６ｎおよび／またはブラウザ１２４ｎに直接は関連していない。したがって、協調クライアントサービス１１０は、これらリビジョンについてブラウザ１２４ｎに直ぐには通知しないので、その結果、このような通知に関連付けられるネットワークの帯域幅を節約することができる。しかしながら、ユーザ１２６ｎは、適切なものとして協調クライアントサービス１１０に送信されているこれらのリビジョンを用いて、セル５０６に対するリビジョン５０８を作成することができる。同様に、協調クライアントサービスは、これらのリビジョンを、同じセル５０６を編集している任意の他のブラウザまたはユーザに伝送することができる。

上述したように、先行技術に比較して、図５に図示されたシナリオは、動作上の効率をもたらすことができる。例えば、協調クライアントサービスは、全体のドキュメント自体ではなく、ドキュメントの一部（例えば、リビジョン）を配信することができる。典型的に、これらリビジョンは、ドキュメント全体よりもはるかに小さい。したがって、ネットワークを介してこれらリビジョンを送信することは、ドキュメント全体を送信することに比べて、より少ないネットワーク帯域幅のみを消費する。さらに、ブラウザ１２４および協調クライアントサービス１１０は、ドキュメント全体を更新されたバージョンに交換するのではなく、ドキュメントの一部をリビジョンに交換することができる。したがって、ネットワークを介したこれらのリビジョンの伝達は、ドキュメント全体を更新されたバージョンに交換するに比べて、はるかに小さいデータの送信のみを必要とする。このモデルにおいて生じるネットワークトラフィックは、伝達される変更のサイズには比例するが、変更されるオブジェクトのサイズには比例しない。

様々なブラウザ１２４が、協調的に編集されているセルに対するリビジョンを報告するとき、協調クライアントサービスは、これらのリビジョンの指示を、同じセルを編集している他のブラウザのみに配信する。通常、所与のドキュメントが複数のセルを用いてモデル化され、複数ユーザがこのドキュメントに対して協調的に作業している場合に、これらセルは典型的に、その複数のユーザの間にランダムに配信される。したがって、最悪のシナリオでは、これらのユーザの全てが、同じセルに対して協調的に作業することとなるが、最良のシナリオでは、多くても１人のユーザが、所与のセルに対して操作する。典型的な操作状況はこれらの極端なシナリオのいずれかに収まり、協調クライアントサービスが、修正されたセルに対して操作をしているユーザおよびブラウザのみにリビジョンを報告することによって、ネットワーク帯域幅およびリソースをさらに節約することができる。

図５において、協調ユーザによってドキュメントに対して作成されたリビジョンを処理することに関連するコンポーネントおよびデータフローについて説明したので、次に、これらのリビジョンを処理するための処理フローに関して説明することにする。この説明は図６を用いて行う。

図６は、全体的に６００で示されているように、ブラウザによって報告されるリビジョンを処理するためのフローを図示している。限定ではなく説明を容易にするために、図６は、前の図面から一部の参照番号を引用して同様の項目を示している。例えば、図６は、前の図面から、協調クライアントサービス１１０の表示を引用している。処理フロー６００を協調クライアントサービスに関連して説明するが、この説明の範囲と趣旨から逸脱することなく、処理フロー６００の実装を他のコンポーネントまたはサービスによって実施することもできることに留意されたい。

図６をさらに詳細に参照すると、ブロック６０２は、１つまたは複数のブラウザ（例えば、前の図面の１２４）によって報告されるようなリビジョンの指示を受信することを表している。例えば、ブロック６０２は、協調クライアントサービス１１０が、図５の５０４ａおよび５０８で示されるようなリビジョンの指示を受信することを含む。

ブロック６０４は一般的に、ブロック６０２で報告されたリビジョンの対象となるセルを識別することを表している。例えば、報告されたリビジョンは、これらリビジョンによって修正されたセルを示す識別子を含むことができる。

ブロック６０６は一般的に、ブロック６０６で受信された、報告されたリビジョンを記憶することを表している。例えば、ブロック６０６は、これらのリビジョンを、サーバ側のリビジョンストア（例えば、２１２）に記憶することを含む。

決定ブロック６０８は、任意の他のブラウザが、修正された所与のセルを参照および／または編集することを要求しているかどうかを判断することを表している。所与の時間において他のいかなるブラウザも、その所与のセルを要求していない場合には、処理フロー６００は、Ｎｏで示される分岐６１０に進んでブロック６０２に戻り、ブラウザの１つからセルに対する次のリビジョンの通知を待つ。

決定ブロック６０８に戻ると、他のブラウザが修正されたセルを要求していた場合は、処理フロー６００は、Ｙｅｓで示される分岐６１２から、セルに対するリビジョンを、要求している任意のブラウザに送信することを表しているブロック６１４に進む。図５において上述したように、コラボレーションに利用可能なセルを、協調的に作業するユーザの間にランダムに配信することができる。このシナリオでは、ブロック６１４は、これらのアップデートの通知を、所与のドキュメントに対して協調的に作業するユーザのすべてではなく、所与のドキュメント内で協調的に作業するユーザのうち特定の小さなサブセットに送信することを含むことができる。

ブロック６１４を実行した後、処理フロー６００はブロック６０２に戻り、ブラウザからの次のリビジョンの通知を待つ。図６において様々な協調的に作業するブラウザによって報告されたリビジョンを処理するフローについて説明したので、次に、ブラウザ側でこれらのリビジョンを処理するためのコンポーネントおよびデータフローに関して説明することにする。この説明を図７を用いて行う。

図７は、全体的に７００で示されるように、ブラウザが、複数のユーザによって協調して編集されるコンテンツに対するリビジョンを処理できるようにするコンポーネントおよびデータフローを図示している。限定ではなく説明を容易にするために、図７は、前の図面から一部の参照番号を引用して同様の要素を示す。例えば、図７は、前の図面からネットワーク１２８、例示的ユーザ１２６、例示的ブラウザ１２４、例示的ＤＯＭ４１６、例示的ビューコードまたはビューモデル４０８、および例示的グラフ構造４１０を引用している。図７は、ユーザによる編集のためにブラウザ１２４内に表示されたセルの初期状態４０８を含む、クライアント側のリビジョンストア４０６も引用している。さらに、図７は、ネットワーク１２８を介してブラウザからリビジョン５０４を報告することができる複製マネージャ４０２も引用している。

図７をさらに詳細に参照すると、ユーザ１２６は、ブラウザ１２４内に提示されたコンテンツと対話するために、送信された様々なコマンドを発行することができ、そしてこれらのコマンドにより、このコンテンツに対する任意の数のリビジョンを作成することができる。ブラウザ内に提示されたコンテンツのタイプに応じて、および協調クライアントサービス（例えば、前の図面の１１０）により、どのような機能がそのブラウザに対して利用可能にされたかに応じて、これらのコマンド７０２は様々なタイプをとり得る。

ユーザによって発行されたコマンド７０２のタイプに応じて、ブラウザは、これらコマンドをＤＯＭまたはグラフ構造に対して実行することができる。典型的に、ほとんどのコマンドが、データ／ビューモデルのモデル部分を提供するグラフに対して実行され得る。このように、モデル部分は最新に保たれる。しかしながら、編集コマンドを、ＤＯＭに対して、および特定のポイントにおいて（例えば、単語またはパラグラフの終わりにおいて）実行することができ、ＤＯＭは、ユーザの編集の結果得られるリビジョンを用いてグラフ構造を更新することができる。このように、ＤＯＭおよびグラフ構造は、ユーザによってタイプされた各キーストロークを追跡して処理するパフォーマンスの不利益を生じさせず、代わりに、処理における効率を改善するためにキーストロークまたはコマンドを集約する。

コマンド７０２に応答して、グラフ構造内のノードを更新することができ、このとき、更新されるコマンドによって影響されるそれらノードのみを更新することができる。該影響されるノートが更新されると、ビューコード４０８は、これらノードをトラバースして、例えば適切なＨＴＭＬを用いてＤＯＭに追加（populate）することができる。同様に、ブラウザ１２４は、ＤＯＭをトラバースして、ユーザ１２６に対して表示するためにＨＴＭＬをレンダリングすることができる。このように、ブラウザ１２４は、ユーザ１２６が、該ユーザが入力した任意のコマンドの結果を視覚化することを可能にする。

一部の例においては、ブラウザ１２４はコマンドを、該ブラウザにおいてローカルで実行するのか、あるいはサーバにおいてリモートで実行するかを決定することができる。この決定はパフォーマンス上の考慮に基づいて行われ、典型的には、リソースを多く要する（resource-intensive）オペレーションが、サーバにオフロードされる。しかしながら、考慮すべき他の要因には、所与の時間においてサーバが高負荷であることが含まれる。

クライアント側のリビジョンストア４０６は、ブラウザ１２４を介してユーザによって行われたコマンドまたは他のアクションの結果得られた、リビジョンのセットを格納することができる。ブラウザ内に表示されたセルの初期状態の表示４０８から始まると、リビジョンストア４０６は、一連のリビジョンデルタ７０４を作成して格納することができる。これらのリビジョンデルタは、所与のブラウザ１２４でローカルにグラフに対して起こった、連続的で増分的な変更を表す。他の機能の中で、これらのリビジョンデルタは、ブラウザが「アンドゥ」機能をユーザに提供するための機構を提供することができ、この機能により、ユーザは前の状態に戻るためにリビジョンのセットを介して後に戻ることができる。

リビジョンストア４０６は、リビジョンおよびリビジョンデルタを、初めは発生順に配列される１つまたは複数のリンクリスト（link list）として格納することができる。しかしながら、時間の経過により、そのようなリンクリストは、トラバースするにはかなり長くなることがある。典型的に、（例えば、「アンドゥ」操作のために）ユーザにとって関心の対象となるほとんどのリビジョンが、このリンクされたリストの端部にあることがある。しかしながら、関心の対象のこれらのリビジョンにアクセスすることは、リンクリスト全体をトラバースすることを必要とし、相当なパフォーマンス上の不利益を伴う。この状況において、リビジョンストアは、リビジョンデルタのリンクリストを認識することができるので、該リビジョンデルタを、リストを通じてより前の初期状態へと「後方に」探す代わりに、将来の状態へと「前方に」に探すことができる。

リビジョンストア４０６は、ローカルブラウザにおいて生ずるリビジョンの大部分またはすべてを表すデルタを格納することができるが、リビジョンストア４０６は、ネットワーク１２８を介して、これらのリビジョンの全てをサーバに報告してもよく、あるいは全ては報告しなくてもよい。例えば、ブラウザを介してローカルに生ずるリビジョンデルタ７０４の完全なセットを与えると、リビジョンストア４０６は、（７０６で示される）これらのリビジョンデルタの何らかのサブセットを複製マネージャ４０２に報告することができる。同様に、複製マネージャは、５０４で示されるようにこれらのリビジョンを、サーバに転送することができる。より具体的には、ブラウザ内の複製マネージャは、ブラウザ内で起こるユーザ対話とはあまり連動しないように、これらのリビジョンをいつサーバに転送するかを決定することができる。最終的に、所与のブラウザにおける複製マネージャは、ユーザがブラウザにおいて行った集約的な変更または累積的な結果の変更をサーバに伝送することができる。ブラウザにおける複製マネージャは、ブラウザにおいて起こったリビジョンとリビジョンデルタを結合することにより、セルに対する集約的な変更または累積的な変更に似ている結果のリビジョンを定義することができ、それによりセルの現在の状態を確立することができる。同様に、複製マネージャは、セルの現在の状態をサーバに送信することができる。

図７においてリビジョンを処理するためのブラウザ側のコンポーネントおよびデータフローについて説明したので、次にこれらリビジョンを処理するためのサーバ側のコンポーネントおよびデータフローに関して説明することにする。この説明を図８を用いて行う。

図８は、全体的に８００で示されるように、ブラウザからリビジョンを受信して処理するためのサーバ側のコンポーネントおよびデータフローを図示している。限定ではなく説明を容易にするために、図８は、前の図面から一部の参照番号を引用して同様の項目を示している。

図８に示される例では、例示的ユーザ１２６ａおよび１２６ｎが、例示的ブラウザ１２４ａおよび１２４ｎと対話して、特定のセル８０２ａおよび８０２ｎに対するリビジョン５０４ａおよび５０４ｎを作成する。同様に、ブラウザ１２４ａおよび１２４ｎは、これらリビジョンを、ネットワーク１２８を介して協調クライアントサービス１１０に報告することができる。

ブラウザからこれらリビジョンを受信すると、協調クライアントサービス１１０は、全体的に８０４で示されるように、これらのリビジョンをサーバ側のリビジョンストア（例えば、２１２）に記憶することができる。図８は、この説明の目的ために、リビジョンを伝達する２つのブラウザのみを図示しているが、この説明の実装には、リビジョンを協調クライアントサービスに報告する多くのブラウザ１２４を含めることができる。

図２において上述したように、サーバ側のリビジョンストア２１２は、１つまたは複数のオブジェクト表現２０４を含み得る任意の数のセルのリビジョンを含むことができる。これらのオブジェクト表現２０４は、セルまたはオブジェクトに関するいずれかのリビジョン通知が到着する前のセルまたはオブジェクトの１つまたは複数の状態を示す、初期のリビジョン８０６に関連付けられる。

リビジョン５０４の通知が様々なブラウザから到着すると、これら通知は、それぞれ８０２ａおよび８０２ｎで示されるように、どのセルが修正されているかを示すことができる。協調クライアントサービス１１０はこれらの通知を受信すると、該サービスは、サーバ側でリビジョンデルタ８０８を作成して記憶することができる。機能的に、サーバ側のこれらリビジョンデルタ８０８は、ブラウザ側に関して説明されたリビジョンデルタと同様に動作することができる。しかしながら、サーバ側のリビジョンデルタは、ブラウザサイドリビジョンデルタと厳密に同じものとしてもよく、あるいは厳密には同じものとはしなくてもよい。

図８においてブラウザからリビジョンを受信して処理するためのサーバ側のコンポーネントおよびデータフローについて説明したので、次に、サーバ側のコンポーネントに関するより詳細な説明に進む。この説明を図９を用いて行う。

図９は、全体的に９００に示されるように、協調クライアントサービスに関連付けられたサーバ側のコンポーネントを図示している。限定ではなく説明を容易にするために、図９は、前の図面から一部の参照番号を引用して同様の項目を示す。例えば、図９は、協調クライアントサービス１１０の例とネットワーク１２８の例を引用している。

ウェブサービス９０２が、ブラウザからの通信を受信して該通信を協調クライアントサービス内の適切なコンポーネントに向けるインタフェースとして提供されている。これらの通信には、例えば、コンテンツの所与のインスタンスに対して協調的に作業する様々な異なるブラウザから受信されるようなリビジョンまたはリビジョンデルタの通知を含めることができる。これらの通知は、様々なブラウザから来るものとすることができ、および／または様々なブラウザに送るものとすることができる。ウェブサービスは、これらの通信を、ネットワーク１２８を介した転送に適したプロトコルから、協調クライアントサービス内での処理により適した内部のバイナリプロトコルに変換する、アダプタ９０４を提供することができる。

ウェブサービスは、リビジョンをブラウザに送信し、およびリビジョンをブラウザから受信ための方法（method：メソッド）、すなわちアプリケーションプログラミングインターフェイス（ＡＰＩ）をサポートすることができる。さらに、これらのＡＰＩは、サーバに、所与のブラウザが所与のページからブラウズしたことを示す方法を含むことができ、そのページの任意のセルに対する編集が完了したことを示すことができる。

ストレージレイヤ（storage layer）９０６は、ウェブサービスアダプタ９０４を通じてサーバ側のリビジョンストア２１２との間で通信することができ、サーバ側のリビジョンストア２１２との間の通信を抽出することができる。ストレージレイヤ９０６は、サーバ側のリビジョンストアに対するインタフェースを提供するストレージアダプタ９０８も提供することができる。リビジョンが様々なブラウザから到着すると、ストレージレイヤ９０６は、これらのリビジョンをリビジョンストアにキャッシュすることができる。

サーバ側のリビジョンストアは、異なる特徴を有する異なる記憶領域またはキャッシュを含むことができる。例えば、第１の記憶領域９１０は、より最近より頻繁にアクセスされて修正された、より小さなデータチャンクを記憶するように適合または構成されることがある。可能な実装を制限するのではなく参照を容易にするために、図９は、この第１の記憶領域を「ホット」記憶領域またはキャッシュとして示している。また、リビジョンストアは、あまり最近あまり頻繁にはアクセスおよび修正されていない、より大きなデータチャンクを記憶するように適合または構成される、第２の記憶領域またはキャッシュ９１２も含むことができる。可能な実装を制限するのではなく参照を容易にするために、図９は、この第２の記憶領域を「コールド」記憶領域またはキャッシュとして示している。

マージレイヤ（merge layer）９１４および関連するマージエンジン９１６は、ストレージレイヤがマージ機能を呼び出すことを可能にするそれらインタフェースおよび関連した方法を作成する。例えば、異なるブラウザが、協調クライアントサービスに所与のコンテンツに対するリビジョンを送信すると、ストレージレイヤは、対応するリビジョンおよび／またはリビジョンデルタをキャッシュ９１０および９１２内に記憶することができる。適切なとき、ストレージレイヤ９０６は、マージレイヤ９１４を呼び出してこれらの様々なリビジョンをマージまたは調整（reconcile）し、ブラウザが協調的に作業しているコンテンツを更新することができる。さらに、マージレイヤ９１４は、マージエンジン９１６をいつ呼び出して実行するかを、任意の所与の時間に協調クライアントサービスを提供しているサーバがどのくらい高負荷であるか、または使用されているかなどの要因に基づいて決定することができる。

上記の処理において、セーブオペレーション（save operation）は、オペレーションをマージするように非同期的になる。典型的に、ブラウザ側ではリビジョンデータはかなりシリアル化（serialize）されうるが、サーバ側では、リビジョンデータは再編成されて最適化されるのでシリアル化されない。したがって、サーバによって保持されるリビジョン履歴は、ブラウザにおいて変更が生じた順序を示す線形表現（liner representation）としてもよく、あるいは線形表現としなくてもよい。代わりに、リビジョン履歴は分岐または他の非線形特性を含んでもよい。

典型的に、ユーザおよびブラウザは、マージプロセスの詳細からシールドされているので、マージにおける遅延はユーザ経験全体にはあまり影響を与えない。言い換えると、ユーザは、マージが完了するのを待つことなく、あるいはマージがサーバ側で進行中であることを気付くことなく、ブラウザにおいてリビジョンを継続することができる。

協調クライアントサービス１１０は、図９に示されるアーキテクチャを使用して、いくつかの機能を実行することができる。これら機能には、様々なブラウザとの間で転送されるデータのペイロードを最適化すること、ブラウザから発行されたコマンドを実行するのに最良の環境を決定すること、サーバ上のコンテンツおよびセルの記憶を最適化すること、協調コンテンツのマルチユーザによる編集を可能にすることなどが含まれるが、これらには限定されない。この議論について次に、これら機能の各々に関するさらなる詳細を提供する。

データのペイロードの最適化
協調クライアントサービス下でコラボレーションのためのドキュメントまたはファイルを開くとき、ストレージレイヤ９０６は、このファイルまたはドキュメント内の１つまたは複数の適切なページに関するコンテンツを取り出すことができる。ストレージレイヤは、この１つまたは複数のページに対するデータをサーバ側のリビジョンストアからフェッチすることができる。このフェッチを、これらのページを最初にホットストア（例えば、９１０）内で探すのに最適化することができる。３つの要求ページがホットストア内にない場合には、フェッチはコールドストア（例えば、９１２）を徐々｛じょじょ｝に検索することができる。

適切なデータは、リビジョンストアからフェッチされ、サーバ上のフロントエンドキャッシュ内に記憶され、そして、適切なブラウザ（例えば、１２４）に送信される。受信したブラウザは、このデータをブラウザ側のリビジョンストア（例えば、３０６）に記憶して、このデータをグラフ構造（例えば、３１０）に再作成するか、戻すことができる。所与のユーザが所与のブラウザ内のコンテンツを修正するとき、または別のユーザが別のブラウザ内のコンテンツを変更する場合、協調クライアントサービスは、これらの変更を示すリビジョンおよびリビジョンデルタを生成して、該コンテンツに対して協調的に作成されたこれらのリビジョンを他のブラウザに送信することができる。

ブラウザ側では、ブラウザは、ブラウザ側のリビジョンストア内のリビジョンおよびリビジョンデルタを取り扱うことができ、ブラウザは、該リビジョンストアからグラフ構造のための適切な更新を作成することができる。サーバ側において、協調クライアントサービスは、これらリビジョンおよびリビジョンデルタをホットストア（例えば、９１０）に記憶することができる。その後、協調クライアントサービスは、異なるユーザから受信したリビジョンとリビジョンデルタとをマージすることができる。例えば、クライアントサービスは、他の操作とはあまり連動しないように（すなわち、「静かに」）、他の操作とは非同期的にマージ操作を実行することができる。

他のユーザまたはブラウザは、協調コンテンツに対して行われた任意の変更をサーバに求めることができる。これら場合において、サーバが、フロントエンドサーバによって保持されたキャッシュからこれら変更を取り出すことができ、あるいは、フロントエンドサーバが、これらの変更をバックエンドサーバから取り出すことができる。一般に、協調クライアントサービスは、フロントエンドサーバが、該フロントエンドが前にフェッチしたデータをローカルに記憶して、バックエンドサーバに行かなくとも、このデータを要求ブラウザに返すことを可能にすることによって、便宜的なホットストアキャッシングを提供することができる。協調クライアントサービスは、リダイレクションを提供してキャッシュすることもでき、この場合、別のフロンエンドサーバが、ブラウザが要求しているキャッシュされたデータを含むとき、あるフロントエンドサーバがブラウザからの要求を、該

適切な環境におけるコマンドの実行
協調クライアントサービスは、サーバとの対話またはサーバによる介入を必要とすることなく、ブラウザの複数のコマンドを実行することができる。ブラウザは、ＤＯＭ（例えば、４１６）を操作することの組合せによって、およびグラフ構造（例えば、４１０）に対する操作を実行することによって、これらコマンドを実行することができる。しかしながら、サーバがこれらのコマンドを起動する性能容量を提供し、そしてサーバ上でコマンドを実行することは、コード（および、秘密情報および／または機密情報）をリモートブラウザにダウンロードすることを必要としないので、一部のコマンドはサーバで実行することができる。

さらに、サーバ上で実行されるそれらコマンドは、サーバの「通常の（normal）」操作に連動することなく、そのように動作することができる。例えば、ストレージレイヤ９０６が新たな変更を受信するとき、それは、記憶するためにサーバ側のリビジョンストア２１２に渡される。ストレージレイヤは、この新たな変更についてマージレイヤ９１４に通知することもできる。しかしながら、この通知とは非同期的に、マージレイヤは、適切なときに、この新たなコンテンツをマージすることを試みることができる。この非同期的な操作は、サーバの高負荷のリスクを最小化し、その結果、他の要求を処理するのに不十分である。このように、マージレイヤは、フロントエンドサーバが、マージに充てるに十分に自由なサイクルを有する場合にのみ動作することができる。

ペーストなどのコマンドは、ブラウザおよびサーバの組み合わせで実行することができる。ブラウザは、十分なペースト操作を実行するのに必要とされる処理が、ブラウザでローカルに実行するには複雑すぎることを検出するロジックを含むことがあり、代わりに、この操作を実行するようにサーバに求めることができる。再びサーバ上で実行するコードは、サーバ上で実行される他の操作を過度に妨げないように、このペースト操作をスケジューリングして実行することができる。

サーバ記憶
協調コンテンツ（例えば、セル）が記憶されるべきであるとき、このコンテンツは、ブラウザからフロントエンドサーバまで移行し、最終的にストレージレイヤに移行し得る。ストレージレイヤが、サーバ側のリビジョンストアと通信して該セルを２つの異なる位置することができる。すなわち、より最近生じた比較的小さい変更は、より高速でより高価なホットストア（例えば、９１０）内に記憶することができ、これは、より低速で、より安価なコールドストア（例えば、９１２）からデータを取り出さなければならない代わりに、この小さなデータのセットを取り出して他のユーザに渡すのに最適化されている。リビジョンまたは変更が、メインファイル内に一旦統合またはマージされると、メインファイルは、コールドストアに記憶される。これは、典型的に比較的大きいメインファイルを、ホットストアより安いストアに記憶することによって、コストを最適化する。

ブラウザがファイル内の特定のセルを要求するときに、ストレージレイヤおよびファイルプロバイダは、要求されたリビジョンを、これらのストア（すなわち、ホットストアおよびコールドストア）の１つまたは両方から取り出して、リビジョンを統一されたデータとしてブラウザおよびサーバ側の残りコンポーネントに提示することができる。また、ストレージレイヤは、コンテンツ内の特定のノードを拡大し、ブラウザが使用しないコンテンツはダウンロードしないことで、サーバ側で記憶されたユーザコンテンツをブラウザによって消費可能なコンテンツに変換することができる。

マルチユーザ編集
協調クライアントサービスによって利用されるデータモデルは、上述したようにリビジョンを含むことができる。また、クライアントサービスは、ユーザ対話を表現することなく（すなわち、「ひそかに」）、これらリビジョンをロード／保存することができる。このアプローチは、ユーザコンテンツおよびリビジョンがどのように共有されるか（すなわち、ワイヤに対する負担を最小にすることによって）、およびそのコンテンツおよびリビジョンがいつ共有されるかの双方を最適化して、ユーザからの変更を自動的に伝播することができる。このように、協調クライントサービスは、複数のユーザが所与のコンテンツに対して協調的に作業していることを検知すると、所与ユーザから他のすべてのブラウザへの変更をより高速に同期させることができる。

協調クライアントサービスは、ブラウザとサーバがデータを効率的に処理することができるようにデータモデルを変換する。ブラウザは、その後、適切なコンテンツを表示して処理する。さらに、協調クライアントサービスは電子ノートブックアプリケーション（例えば、ワシントン州レッドモンドのマイクロソフト社から利用可能なＯｎｅＮｏｔｅ（商標登録）を含むが、これには限定されない）と統合することができる。例えば、ストレージレイヤは、電子ノートブックアプリケーションと互換性があるフォーマットで記憶されるようにリビジョンのフォーマットを変更することができる。このように、協調クライアントサービスは、より豊かなユーザ経験を提供する電子ノートブックアプリケーション（または、他のソフトウェアもしくはアプリケーション）を依拠しつつも、より豊かなクライアントシームレスに統合して、広く利用可能なブラウザを利用することができる。

本明細書に提示された主題を、コンピュータの構造的特徴、方法論的動作、およびコンピュータ読取可能媒体に特有の言語で説明してきたが、添付した特許請求の範囲で定義される本発明は、本明細書に記載された特定の特徴、動作、または媒体に必ずしも限定されないことを理解されたい。むしろ、特定の特徴、動作および媒体は特許請求の範囲を実装する例示的な形態として開示されている。

上述した発明は例示のためにのみ与えられており、限定として理解されるべきでない。図示され説明された例示的実施形態と適用に従うことなく、特許請求の範囲で説明される本発明の趣旨および範囲から逸脱することなく、本明細書に記載された主題に対して様々な修正および変更を行なうことができる。

Claims (11)

1. 複数のユーザがそれぞれのブラウザを用いて１つのドキュメントに対して協調的に作業しているとき、
   前記ドキュメントを複数のセルとしてモデル化するステップであって、前記複数のセルはそれぞれ、前記ドキュメントの一部であり、少なくとも１つのオブジェクトを含む、ステップと、
   前記複数のユーザのうち少なくとも１のユーザにとって関心対象となる、前記ドキュメントの少なくとも１つのセルを識別するステップと、
   前記少なくとも１つの関心対象のセルに対するリビジョンを取得するステップであって、前記リビジョンは、特定の時間における前記少なくとも１つの関心対象のセルの前記少なくとも１つのオブジェクトの内容を表す、ステップと、
   前記取得したリビジョンを、前記少なくとも１のユーザに関連付けられた前記ブラウザに送信すべきであると決定し、前記取得したリビジョンの表示を、前記少なくとも１のユーザに関連付けられた前記ブラウザに送信するステップと、
   前記少なくとも１つの関心対象のセルを、前記少なくとも１つの関心対象のセルに対する前記リビジョンが送信された前記少なくとも１のユーザに関連付けるステップと、
   前記少なくとも１つの関心対象のセルと、前記少なくとも１つの関心対象のセルに対する前記リビジョンが送信された前記少なくとも１のユーザとの間の関連付けを記憶するステップと
   を含む方法をコンピュータに実行させるコンピュータ実行可能命令を有することを特徴とするコンピュータ読取可能記録媒体。
2. 前記ブラウザから前記ドキュメントに対する少なくとも１つのリビジョンの表示を受信するための命令をさらに含み、当該少なくとも１つのリビジョンは、前記少なくとも１つの関心対象のセルの前記少なくとも１つのオブジェクトのさらなる状態を表す、請求項１に記載の記録媒体。
3. 前記複数のユーザのうち少なくともさらなる１のユーザが前記少なくとも１つの関心対象のセルに対して協調的に作業していると決定するための命令をさらに含み、前記取得したリビジョンの表示を前記複数のユーザのうち少なくとも前記さらなる１のユーザに送信するための命令をさらに含む請求項２に記載の記録媒体。
4. 前記複数のユーザのうち少なくとも１のさらなるユーザが前記少なくとも１つの関心対象のセルに対して協調的に作業していると決定するための命令をさらに含み、前記取得したリビジョンの表示を前記複数のユーザのうちの前記少なくともさらなる１のユーザにのみに送信するための命令をさらに含む請求項２に記載の記録媒体。
5. 前記少なくとも１つの関心対象のセルに対する少なくともさらなるリビジョンの表示を前記ブラウザから受信するための命令をさらに含む請求項２に記載の記録媒体。
6. 前記リビジョンと、前記少なくとも１つの関心対象のセルに対する前記少なくともさらなるリビジョンとをマージするための命令をさらに含む請求項５に記載の記録媒体。
7. 前記少なくとも１つの関心対象のセルをキャッシュするための命令をさらに含む請求項１に記載の記録媒体。
8. 前記少なくとも１つの関心対象のセルを前記キャッシュから取り出し、前記少なくとも１つの関心対象のセルの表示を、前記複数のユーザのうちの少なくともさらなる１のユーザに関連付けられた少なくともさらなるブラウザに送信するための命令をさらに含む請求項７に記載の記録媒体。
9. 前記少なくとも１つの関心対象のセルを求める要求を受信し、この要求を前記キャッシュにリダイレクトするための命令をさらに含む請求項７に記載の記録媒体。
10. 複数のユーザがそれぞれのブラウザを使用して１つのドキュメントに対して協調的に作業しているとき、
    前記ドキュメントの一部の表示を、前記複数のユーザのうちの少なくとも１のユーザに関連付けられたブラウザに送信するステップと、
    前記ブラウザから前記ドキュメントの前記一部に対する少なくとも１つのリビジョンを受信するステップと、
    指定の期間の間にアクセスおよび修正された前記ドキュメントに関連付けられたデータを記憶するように構成された第１の記憶領域に、前記ドキュメントの前記一部を記憶するステップと、
    前記指定の時間期間の間にアクセスおよび修正されていない前記ドキュメントに関連付けられたデータを記憶するように構成された第２の記憶領域に、前記ドキュメントの残りを記憶するステップと
    を含む方法をコンピュータに実行させるコンピュータ実行可能命令を有するコンピュータ読取可能記録媒体。
11. 前記ドキュメントの前記一部を、クライアントアプリケーションに関連付けられた少なくとも１つのフォーマットに変換し、または該少なくとも１つのフォーマットから変換するための命令をさらに含む請求項１０に記載の記録媒体。

Images