(57)【要約】オンライン文書サービスは、ユーザによって編集されるアプリケーションサーバによって提供される。文書は、アプリケーションサーバのローカルメモリ内のコンポーネントベースの構造に記憶されて、共同オーサリングおよび衝突解決の精度を提供する。コンポーネントレベルのロックを利用して、同時に起こるユーザ編集ベースの衝突を最小限にし、そして他のユーザの存在も示す。コンポーネントベースの構造修正は、コンポーネント編集をキャプチャするために記憶され、そして文書の保存アクションの後同期する。編集が１または複数のクライアントによってユーザに保存される時、その編集は、文書がクライアント上の現在の表現を生成するのに使用されたバージョンから変更されていても、サーバ文書の現在のバージョンに保存され得る。
2013541115.tif 000002
【特許請求の範囲】
【請求項１】
オンライン文書編集を同期するために少なくとも一部はコンピューティングデバイスによって実行される方法であって、前記方法は、
文書の第１のセクションと関連付けられる第１の共同オーサリングメタデータの指示を受信するステップであって、前記第１の共同オーサリングメタデータは、ブラウザベースのクライアントアプリケーションから受信される、受信するステップと、
前記文書の第２のセクションと関連付けられる第２の共同オーサリングメタデータの指示を受信するステップであって、前記第２の共同オーサリングメタデータは、第２のクライアントアプリケーションから受信され、前記第２のクライアントアプリケーションは、ブラウザで動作しない、受信するステップと、
前記ブラウザベースのクライアントアプリケーションに提供される変換表現に基づいて前記第１の共同オーサリングメタデータを解釈するステップと、
前記文書と関連する前記第１の共同オーサリングメタデータおよび前記第２の共同オーサリングメタデータを記憶するステップと
を備えたことを特徴とする方法。
【請求項２】
前記第１の共同オーサリングメタデータは、ユーザ名、ユーザの存在情報、および文書内ロックのセットのうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項３】
コンポーネントレベルの変更された文書において他の編集と衝突する１または複数の編集を認識するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項４】
前記衝突する編集が結びの句である場合、通知を用いずに、衝突する編集を同一コンポーネント内で統合することを試みるステップをさらに備えたことを特徴とする請求項３に記載の方法。
【請求項５】
前記文書にアクセスするクライアント間でパラグラフの番号を同期することを確認するための要求を前記クライアントアプリケーションから受信した後、前記文書の各パラグラフを再番号割り当てするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項６】
前記ユーザが前記文書の単一の共作成者であるかどうかを判定するための要求を、前記文書と関連付けられる共同オーサリングアプリケーションを実行するサーバに送るステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項７】
オンライン文書編集を同期するオンライン文書アプリケーションサーバであって、前記サーバは、
メモリと、
前記メモリに接続されたプロセッサであって、前記プロセッサは、前記メモリに記憶された命令と共にアプリケーションを実行し、前記アプリケーションは、
文書の要求をユーザから受信し、
前記文書に対する文書ロックを記憶サーバから要求し、
前記文書を前記記憶サーバから読み出し、
前記文書を、前記文書のコンテンツを含む複数のコンポーネント、ならびにユーザ名およびユーザの存在情報を含む第１の共同オーサリングメタデータに変換し、
少なくとも２人のユーザによる編集間の衝突を判定し、
前記複数のコンポーネントに対する複数のコンポーネントロックを、前記衝突する編集を評価することによって判定し、
前記文書ロックを解除することによって前記文書ロックを前記複数のコンポーネントロックに調整し、前記複数のコンポーネントロックを、適合するコンポーネントに適用し、
前記グラフを表示用のブラウザベースのクライアントアプリケーションに送信する
ように構成される、プロセッサと
を備えたことを特徴とするサーバ。
【請求項８】
前記衝突を判定した後、前記アプリケーションは、
少なくとも１つのユーザ選択に対し、少なくとも１つの衝突するユーザ編集および少なくとも１つの対応するコンポーネントを、前記ブラウザベースのクライアントアプリケーションに送信することであって、前記少なくとも１つの選択は、前記衝突を解消する前記少なくとも１つの対応するコンポーネントに記録される
ようにさらに構成されることを特徴とする請求項７に記載のアプリケーションサーバ。
【請求項９】
前記アプリケーションは、
前記複数のコンポーネントロックを、第２の共同オーサリングメタデータとして文書グラフに記憶する
ようにさらに構成されることを特徴とする請求項７に記載のアプリケーションサーバ。
【請求項１０】
オフラインブラウザベースのクライアントアプリケーションは、オンラインに戻った後、統合するための少なくとも１つのユーザ編集を、前記文書グラフに送信することを特徴とする請求項９に記載のアプリケーションサーバ。
【請求項１１】
前記アプリケーションは、
編集時間、ユーザの認証情報、およびユーザの役割のセットのうちの少なくとも１つを、前記ブラウザベースのクライアントアプリケーションに送信する
ようにさらに構成されることを特徴とする請求項７に記載のアプリケーション。
【請求項１２】
オンライン文書編集を同期するための命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、
文書の要求をユーザから受信するステップと、
前記文書に対する文書ロックを記憶サーバから要求するステップと、
前記文書を前記記憶サーバから読み出すステップと、
前記文書を、ユーザ名およびユーザの存在情報を含む第１の共同オーサリングメタデータを含む複数のコンポーネントに送信し、かつ前記複数のコンポーネントをグラフに記憶するステップと、
前記複数のコンポーネントに対する複数のコンポーネントロックを、少なくとも１つのユーザ編集を評価することによって判定するステップと、
前記文書ロックを解除することによって前記文書ロックを前記複数のコンポーネントロックに調整し、前記複数のコンポーネントロックを、前記グラフ内の適合するコンポーネントに適用し、および前記複数のコンポーネントロックを第２の共同オーサリングメタデータとして前記グラフに記憶するステップと、
前記グラフを表示用のブラウザベースのクライアントアプリケーションに送るステップと
を備えたことを特徴とするコンピュータ可読記憶媒体。
【請求項１３】
前記命令は、現在のユーザに、前記複数のコンポーネントロックを通知することをさらに備えたことを特徴とする請求項１２に記載のコンピュータ可読記憶媒体。
【請求項１４】
前記命令は、
コンポーネントレベル識別子を記憶するステップと、
前記文書の他の部分が変化しても、前記コンポーネントレベル識別子を使用して、ユーザの編集を、適したコンポーネント領域に移動するステップと
をさらに備えたことを特徴とする請求項１２に記載のコンピュータ可読記憶媒体。
【請求項１５】
前記命令は、
ユーザに、前記文書を編集する現在の作成者の名前および存在情報を通知するステップ
をさらに備えたことを特徴とする請求項１２に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン文書編集の同期化に関する。
【背景技術】
【０００２】
ウェブアプリケーションは、ネットワークを介して多様なサービスおよびデータをユーザに提供する。データは、集められ、処理され、そして異なる位置に記憶される。ウェブアプリケーションは、そのデータを読み出し、そのデータを提示するのにフォーマットし、そしてクライアントデバイス上でウェブページをレンダリングする閲覧アプリケーションにそのデータを提供する。一部のウェブページには、そのデータが双方向通信しない静的なものもある。他のウェブページは、リンクを介した付加的な情報またはウェブベースのモジュールの起動など、ある程度の双方向性を提供できる。しかしながら、一般に、ウェブページは、ウェブページの作成者によって決められたフォーマットおよび量のデータを提示する。
【０００３】
オンライン文書アプリケーションは、文書を編集してビューする能力をユーザに提供するが、その能力は、最近までシッククライアントアプリケーションの分野であった。計算の技術的進歩とネットワークおよびデータ記憶の拡大とによって、オンラインアプリケーションがシッククライアントアプリケーションの文書編集機能を提供することができるようになった。プラットフォームに依存しないさまざまな基本技術を通じてオンラインアプリケーションを使用できる利点により、多数のユーザが文書の生成および管理を共同で行うことができるようになった。しかしながら、複数のユーザによる文書へのアクセスは、非同期のユーザ編集につながる恐れがある。さまざまな技術を介して文書が複数のプラットフォームにアクセスする場合、文書の維持管理および文書の一貫性をさらに複雑にする恐れがある。
【発明の概要】
【０００４】
本概要は、以下の発明を実施するための形態でさらに説明される概念の選択を簡略化した形で紹介するために与えられる。本概要は、特許請求される主題の主要な特徴または不可欠な特徴のみを明らかにすることも、特許請求される主題の範囲を決めるのに役立つものとして用いられることも意図しない。
【０００５】
実施形態は、文書コンポーネントレベルで修正を制御することによってオンライン文書編集を同期することを対象とする。ある実施形態に従って、文書を文書コンポーネントのグラフに変換でき、および複数のユーザによって提出される変更を管理するためにロックをコンポーネント上でアサートできる。グラフコンポーネントの変更は、グラフの修正を維持管理することによって追跡できる。
【０００６】
これらと他の特徴および利点は、以下の詳細な説明を読み、且つ関連する図面を見直すことによって明らかになるであろう。前述の概説と以下の詳細な説明との両方は、説明するためのものであり、特許請求される態様を制限するものではないことを理解されたい。
【図面の簡単な説明】
【０００７】
【図１】オンライン文書編集サービスの例示的コンポーネントを示す図である。
【図２】編集を管理するロックアクションの例示的ステップを示す図である。
【図３】編集を管理する修正実装の例示的ステップを示す図である。
【図４Ａ】ある実施形態に係る例示的シナリオを示す図である。
【図４Ｂ】ある実施形態に係る例示的シナリオを示す図である。
【図４Ｃ】ある実施形態に係る例示的シナリオを示す図である。
【図５】実施形態に係るシステムを実装できるネットワーク化環境である。
【図６】実施形態を実装できる例示的コンピューティングオペレーティング環境のブロック図である。
【図７】実施形態に係る文書コンポーネントレベルで修正を制御することによってオンライン文書編集を同期するプロセスの論理流れ図である。
【発明を実施するための形態】
【０００８】
上記に簡潔に説明したように、ロックアクションを使用して文書コンポーネントレベルで修正を制御することによってオンライン文書編集を同期できる。文書を文書コンポーネントのグラフに変換できる。複数のユーザによって提出される変更を管理するためにロックをコンポーネント上でアサートできる。各共作成者が編集する文書をコンポーネントレベルで編集することを含めたグラフの修正を維持管理することによってグラフコンポーネントの変更を追跡できる。以下の詳細な説明において、その一部を成す添付図面についての説明が行われ、図解を目的とする実施形態または例によって示される。本開示の精神または範囲から逸脱しない範囲においてこのような態様を組み合わせてもよいし、他の態様を利用してもよいし、構造の変更を行ってもよい。従って、以下の詳細な説明は、限定された意味で解釈されるものではなく、本発明の範囲は、添付の特許請求の範囲およびその等価物によって定義される。
【０００９】
実施形態は、コンピューティングデバイスのオペレーティングシステム上で実行するアプリケーションプログラムと共に実行するプログラムモジュールの一般的な状況において説明されるが、態様は、他のプログラムモジュールと共に実装されてもよいことが当業者には認識されよう。
【００１０】
一般に、プログラムモジュールは、ルーチン、プログラム、コンポーネント、データ構造、および特定のタスクを実行するまたは特定の抽象データ型を実装する他のタイプの構造を含む。さらに、実施形態は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家電、ミニコンピュータ、メインフレームコンピュータ、および同等のコンピューティングデバイスを含む、他のコンピュータシステム構成で実施されてよいことが当業者には認識されよう。実施形態を、通信ネットワークにリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施できる。分散コンピューティング環境において、プログラムモジュールをローカルメモリ記憶デバイスとリモートメモリ記憶デバイスとの両方に配置することができる。
【００１１】
実施形態を、コンピュータ実装プロセス（方法）、コンピューティングシステムとして、あるいはコンピュータプログラム製品またはコンピュータ可読媒体などの、製造品として実装できる。コンピュータプログラム製品は、コンピュータシステムによって読み取り可能であり、且つコンピュータまたはコンピューティングシステムが例示的プロセス（複数）を実行するようにさせる命令を備えるコンピュータプログラムを符号化する、コンピュータ記憶媒体であってよい。コンピュータ可読記憶媒体を、例えば、揮発性コンピュータメモリ、不揮発性コンピュータメモリ、ハードドライブ、フラッシュドライブ、フロッピー（登録商標）ディスク、またはコンパクトディスク、および同等の記憶媒体のうちの１つまたは複数によって実装することができる。
【００１２】
この明細書全体を通じて、用語「プラットフォーム」は、実施形態を実装できるさまざまな文書タイプまたは同様の環境に共同オーサリングサービスを提供するソフトウェアコンポーネントとハードウェアコンポーネントとの組み合わせであってよい。プラットフォームの例は、複数のサーバ上で実行されるホストサービス、単一のサーバ上で実行されるアプリケーション、および同等のシステムを含むが、これらに限定されない。用語「サーバ」は、一般に、典型的にはネットワーク化環境において１または複数のソフトウェアプログラムを実行するコンピューティングデバイスを指す。しかしながら、サーバは、ネットワーク上のサーバと見なされる１または複数のコンピューティングデバイス上で実行される仮想サーバ（ソフトウェアプログラム）として実装されてもよい。このような技術および例示的動作について以下により詳細に説明する。
【００１３】
図１は、オンライン文書編集サービスの例示的コンポーネントを示す図である。１００において、サーバ１１０は、１または複数のオンライン文書編集アプリケーションを実行し、そしてネットワーク１４０経由で情報、特に文書コンテンツを送信できる。ネットワーク１４０は、ローカルネットワークであってよいし、またはインターネットベースのインフラストラクチャなどの、外部エンティティであってよい。そのネットワークは、有線または無線接続性を提供できる。ネットワークノードは、セキュアでないまたはセキュアな接続性を介して互いに接続できる。セキュアな接続性の例として、ネットワークノード間で暗号化された通信を使用して確立される仮想プライベートネットワーク（ＶＰＮ）がある。
【００１４】
サーバ１１０は、さまざまなプロトコルを介してクライアントと通信する文書編集アプリケーションを提供できる。その一例として、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）がある。文書編集アプリケーションは、文書編集サービスをシンクライアントおよびシッククライアントのエンドユーザに提供できる。シンクライアント（またはウェブクライアント）１３１、１３４は、サーバアプリケーションが提供する機能に依存できる。シッククライアント（またはリッチクライアント）１３７は、サーバアプリケーションが提供する機能とローカル機能とを組み合わせて、エンドユーザに付加的なユーティリティを与えることができる。リッチクライアント１３７は、同じアプリケーションサーバ１１０に接続する必要がない。最終的に、すべてのクライアントは、同じ文書を文書サーバ１２０上で編集する。いくつかの実装に従って、アプリケーションサーバ１１０は、ウェブ編集能力に適するサーバにすることができ、別のサーバは、リッチクライアント１３７に適していて且つそれによって使用されるサービスを提供できる。アプリケーションサービスの例は、ユーザ編集とユーザ存在情報およびユーザ名とを統合してクライアントデバイス上でユーザ変更を表示できる。さらに、サーバアプリケーションは、複数のユーザが異なるクライアントデバイス（１３０、１３３および１３６）を介してサービスにアクセスできるようにする場合がある。例示的シナリオにおいて、ユーザは、文書にアクセスして変更した結果、その同じ文書（１３２、１３５および１３８）を異なるバージョンにできる。
【００１５】
実施形態において、文書サーバ１２０は、文書記憶サービスであってよい。文書は、テキスト、描画、イメージ、ビデオ、およびオーディオを含む、文書のさまざまなタイプおよびフォーマットを記憶できるが、これらに限定されない。例示的システムにおいて、文書サーバは、アプリケーションサーバによって提供されるオンライン編集アプリケーションを介して複数のユーザによって編集されるテキスト文書を記憶できる。別の例示的システムにおいて、文書サーバは、アプリケーションサーバによって提供されるオンラインイメージ編集アプリケーションを介して複数のユーザによってアクセスおよび編集されるイメージ文書を記憶できる。しかし、他の例において、文書記憶サーバは、ハイブリッド文書タイプのオンラインアプリケーションサービスを介してアクセスおよび編集を同時に行う複数のファイルタイプおよびフォーマットを複数のユーザに提供できる。
【００１６】
例示的シナリオにおいて、ユーザは、アプリケーションサーバによって提供される文書アプリケーションを介して編集するために既存の文書にアクセスできる。ユーザ要求の後、アプリケーションサーバは、記憶サーバ内の文書を読み出してロックできる。アプリケーションサーバは、文書を、その文書のコンポーネントをカプセル化するグラフに変換できる。アプリケーションサーバは、そのグラフを修正番号に割り当てることができる。アプリケーションは、ユーザ変更を評価し、そして文書ロックを、変更されたコンポーネントを包含するグラフコンポーネントを隠すコンポーネントロック（複数）に変えることができる。アプリケーションサーバは、グラフコンポーネントの変更を書き込んで、グラフの修正番号を変更でき、そしてファイルサーバに書き込むことによってそのグラフ変更を同期できる。さらに、オフラインクライアントは、オンラインに戻った後に統合する編集をグラフに送信できる。
【００１７】
ユーザが文書を共同オーサリングできるようにさせるアプリケーションサーバは、クライアントからのある通信を予測することができる。その通信は、２種類の要求、即ち、記憶要求およびサーバアクセス要求の形で入ってくる。要求動作を、２つの層を使用して実装できる。第１に、サーバは、各要求に対してシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）インタフェースを示すことができる。要求は、その後、その要求にサービスするサーバのフロントエンドのコンポーネントに渡される。
【００１８】
別の例示的実施形態において、ウェブブラウザベースのクライアントアプリケーションは、ブラウザで実行するスクリプトベースのコードと、フロントエンドで実行するＣ＃コードなどの、実装に特化したコードとの２つの部分から構成され得る。フロントエンドは、要求を受信してサービスできる。その結果、アプリケーションは、ウェブブラウザベースのクライアントが要求できる方法を実装する際のオプションを有することができる。ブラウザで実行するコードは、１）サーバ上で示されたＳＯＡＰインタフェースに直接要求できるか、または２）サーバ上の単一のエントリーポイントに直接すべて要求して、ＳＯＡＰ要求を受信すると、フロントエンドが、そのフロントエンド内から直接要求にサービスできるコンポーネントを呼び出すようにさせることができる。
【００１９】
サーバ上の単一のエントリーポイントに直接すべて要求することは、事前処理、事後処理、管理容易性、移植性、および一貫性において有利になり得る。事前処理について、非同期Ｊａｖａ  Ｓｃｒｉｐｔ（登録商標）（ＡＪＡＸ）または同様の要求は、サーバによって要求される動作の詳細を包含できるバイナリストリームを包含できる。バイナリストリームの生成は、スクリプト言語では面倒になる恐れがある。さらに、サーバは、より単純な命令からバイナリ要求を生成できるユーティリティにすでにアクセスした可能性がある。
【００２０】
事後処理について、生応答をバイナリストリーム以外でブラウザがより解釈しやすいフォーマットに変換するのに望ましい処理もあり得る。その応答は、文書を参照できるデータを包含できる。管理容易性についして、単一のエントリーポイントを利用するので、システムは、フロントエンド上で真の負荷を考慮するためのスロットリングなどの動作を実装できる。アプリケーションは、関連する複数の要求が同時に到達する時、より良い再使用状態にすることもできる。移植性について、ブラウザがさまざまなエンドポイントに発呼するようにさせるので、システムは、他のインプリメンタに実装から実装までのエンドポイント名を保持するように強制することによって、そのインプリメンタに負荷を加えることができる。一貫性について、ブラウザベースの文書編集は、ほとんどの通信を同じエンドポイントに集めることができる。
【００２１】
別の実施形態において、記憶要求を使用して、データを記憶または読み出すことができる。このような記憶要求は、基本文書に結合された１または複数のパーティションされたデータセルに要求できる。ウェブブラウザなどのクライアントアプリケーションからサーバのフロントエンドに記憶要求を行うことは、異なる機構を通じて実現できる。しかしながら、文書を共同オーサリングするユーザは、新しい要求をシステムに課すことができる、共同オーサリングに関連するメタデータを記憶して読み出す付加的な要求を要求できる。
【００２２】
例において、ウェブブラウザは、ページのコンテンツを読み出す動作を実行できる。ウェブブラウザは、文書に対してウェブブラウザベースのサービスを発呼できる。ウェブブラウザは、どの文書およびどのセルをターゲットにして要求を発行したいかについての情報をインスタンス化し、そしてその応答オブジェクトに書き込むことができる。
【００２３】
サーバがこの要求を受信すると、サーバアプリケーションは、（スロットリング、バッチングの後で）タイプに基づいて変換し、そしてそのタイプに基づいて適切なハンドラにデスパッチできる。サーバアプリケーションは、実装技術に基づいてエンドポイントが受け入れ可能なフォーマットに入力を変換できる。プロトコルは、その要求の入力をバイナリストリームでのみ受け取ることもあるし、または任意の入力を（そのようなデータを記憶する効率を最大にするために）バイナリデータに変換することもある。機能は、ストリームを、アプリケーションが実行できる要求の詳細（どのパーティション、どのセルを入手または送出するか）を包含するパラメータになり得る入力と見なすことができる。
【００２４】
別の例示的実施形態において、アプリケーションプロバイダ（１１０）のコンポーネントは、引数からバイナリストリームを構築できるオブジェクトを包含できる。ラッパーを実装して、そのような技術の実装において相互運用することが賢明であろう。
【００２５】
ラッパーは、ネイティブ機能をラップし、そしてその機能を実装コードに示すことができる。ラッパー実装オブジェクトは、ブラウザベースのサービス（特定のセルのデータを読み出すなど）に出す各タイプの要求ごとに存在し得る。ラッパー実装オブジェクトを、ブラウザベースのサービス要求に使用できる同じ引数でインスタンス化できる。ラッパー実装オブジェクトは、要求を実行するネイティブ機能の実装メソッドを呼び出す方法を認識するＡｄｄＴｏＮａｔｉｖｅＲｅｑｕｅｓｔメソッドを実装できる。最後に、実行メソッドは、要求を実行し、そしてその結果（即ち、ストリーム）を戻すインタフェースで呼び出されることもある。その結果は、ラッパーコード内のオブジェクト指向構造に変換して戻される。セルデータを記憶するまたは読み出す要求は、文書コンテンツのラッパーを使用するブラウザベースのアプリケーションとしてサービスされてもよい。
【００２６】
アプリケーションは、共同オーサリング用のメタデータを記憶して読み出す際に使用されるラッパーインタラクションを適用できる。しかしながら、メタデータは、セルオブジェクトの観点から表すことができない。アプリケーションによって記憶されるメタデータは、拡張マークアップ言語（ＸＭＬ）文書などのデータのオパークブロブになり得る。メタデータをセルオブジェクトのグラフに入れ込むことで、セルの観点から記憶できる。読み出した後、データは、ストリームに再構成され得るセルオブジェクトのグラフとして再生できる。
【００２７】
アプリケーションサーバ上のアプリケーションコードは、データをストリームとして記憶または読み出すことによってメタデータ記憶要求に対処できる。ストリームを、適切なスキーマに従って操作用のＸＭＬ文書オブジェクトに供給できる。
【００２８】
さらに別の実施形態において、サーバアクセス要求は、共同オーサリングセッションに参加する／離脱するなどの、機能性を実行する要求のセットに限定されてもよい。機能性は、現在認証されているユーザに関する情報（ユーザ名、電子メールアドレス、および他のユーザ情報など）を求めることができる。そのような要求は、共同オーサリング要求と名付けられてもよい。サーバ要求は、記憶要求と同じパターンに従う。オブジェクトは、扱い易い引数を使用して共同オーサリング要求を生成する能力がある。サーバ要求のパラメータおよび出力をより単純にして、記憶要求が必要とするバイナリストリームを生成するコストの負荷よりもかなり少なくできる。
【００２９】
例示的実施形態を、本明細書では特定のプロトコル、コマンド、メッセージ、およびシステムを用いて説明する。しかしながら、それらは、実施形態に対する制限と見なされるべきではない。本開示の異なる態様は、本明細書で説明される発明の原理を用いた他のプログラミング言語、プロトコル、システム、およびコンポーネントで実装され得る。
【００３０】
図２は、文書へのアクセスを管理するロックアクションの例示的ステップを示す。図２００は、実施形態に従って編集を管理するロックアクションのいくつかの例示的ステップを示す。ウェブブラウザなどのクライアントアプリケーション２１０は、アプリケーションサーバ２３０から文書を要求する（２１２）ことができる。要求が受信されると、アプリケーションサーバは、要求された文書上で文書ロックを生成するために文書記憶サーバ２５０にロック要求を送信する（２３２）ことができる。文書ロックを生成すると、アプリケーションサーバは、記憶サーバから文書を読み出す（２３４）ことができる。
【００３１】
ある実施形態に従って、サーバは、最初に文書のロックを要求し、その後、その要求が共同オーサリングに適しているかを確認するために検査し（２１６）、そしてひとたびその判定が行われると、サーバは、そのロックを複数のクライアントが文書を開くことができる１つのロックに調整する（２３６）ことができる。ロックが適していないと判定される場合、サーバは、排他的ロックに戻ることができる。これによって、サーバが、文書が複雑なために共同オーサリングに適していない文書、ならびに文書コンテンツとの同期から外れたまたは同期が誤っている恐れのある文書のコンテンツに対する事前の情報を持たなくても、そのようなアクションに適した文書を保持できるようにさせる。
【００３２】
例示的実施形態をＸＭＬ文書ホスティングテキストにすることができる。アプリケーションサーバは、ＸＭＬ文書をそのスキーマおよびパラグラフコンポーネントにパースし、そしてグラフに修正番号を与える間にグラフのコンポーネントを記憶できる。記憶要求の応答は、ストリーム形式であってよい。ストリームをＸＭＬ文書か、あるいはＸＭＬの単純なＡＰＩにパースしてメモリの負荷を回避する必要があるかもしれない。プロパティを特定するＸＭＬ要素は、メンバ変数によって構成部分となり得る。サーバアクセス要求からの応答は、特化した構造になる場合もあり、ブラウザが扱い易い表現に直接変換され得る。
【００３３】
代替的実施形態において、より複雑な事後処理のステップは、サーバに仕事をさせる代償の結果、ウェブブラウザなどのシンクライアントアプリケーション上でかなりの性能利得が得られる。二次的メタデータは、ロックの記述、および各ロックに対してロックによって隠されたパラグラフのパラグラフ識別子のリストを包含できる。ブラウザは、グラフをトラバースして、各ロックを隠されたパラグラフに適用するために、識別子がロックによって特定されるパラグラフを探す必要があるかもしれない。
【００３４】
代替として、ロックの仕様は、対応するパラグラフ識別子の代わりに、パラグラフオブジェクトのオブジェクト識別子を包含できる。グラフ内のオブジェクトの識別子によってオブジェクトを求めるには、ランダムアクセスが効率的であり、アプリケーションは、全てトラバースすることを回避できる。
【００３５】
二次的メタデータの要求に応答するサーバのフロントエンドは、パラグラフ識別子の代わりに、隠れたパラグラフのオブジェクト識別子を特定するロックに応答するのに十分な情報を有することができる。二次的メタデータを読み出すと、サーバのフロントエンドは、ユーザがロックするのをパースし、その後、アプリケーションサーバ上の記憶装置からグラフの最新の修正を読み出すことができる。サーバのフロントエンドは続いて、グラフ内のすべてのパラグラフオブジェクトを見つけて、パラグラフ識別子からパラグラフオブジェクトのオブジェクト識別子までの逆マップを構築できる。サーバのフロントエンドは、パラグラフ識別子に代わりに、パラグラフオブジェクト識別子を包含する応答を構築できる。
【００３６】
ブラウザ側では、共同オーサリングメタデータを解釈してそれに基づいて動作する共通のアクタ／エディタ／マネージャのパターンと、メタデータを移動するレプリケータとを有する以下のオブジェクトを含むことができる。
【００３７】
１、エディタ表
о  エディタ表を定期的にダウンロードおよびアップロードする（セッション中２回）プロセス。
о  エディタ表のスキーマの情報をカプセル化するエディタ。
о  文書内の現在の共作成者を表すメモリ内構造を維持管理するマネージャ。マネージャは、エディタがデータを解釈する時にそのエディタによって呼び出される追加および削除メソッドを示すことができる。マネージャは、相手のＧＵＩＤ識別子によってユーザを見つける検索メソッドも示すことができる。
о  インスタントメッセージなどの他の機能性を提供することもできる任意のＵＩに対処するアクタ。
【００３８】
２、二次的メタデータ
о  二次的メタデータを定期的にダウンロードおよびアップロードするプロセス。
【００３９】
二次的メタデータは、いくつかの情報を包含でき、主に文書内ロックに関する情報を包含する。二次的メタデータの、文書内ロック以外の情報をレプリケータで管理できる。ロックについて、アクタ／エディタ／マネージャのパターンを再度展開できる。
【００４０】
１、ロックを追加および削除して、グラフのコンポーネントを提供するメソッドを有するアクタ。アクタは、ロックに対して「ここで入力できますか？」という問いに答えるメソッドも有することができる。
【００４１】
２、プレースホルダー、エフェメラル、自動削除などの、さまざまなリストに入れることができる現在周知のロックのセットを維持管理するマネージャ。すべてのエフェメラルロックを除去して、それらをプレースホルダーロックに変えるなどの、グローバルロック動作。プレースホルダー、エフェメラル、および自動削除ロックをパラグラフなどの文書コンポーネントと関連付けることができる。
【００４２】
３、設計は、ロック編集オブジェクトを必要としないかもしれない。ロックオブジェクトは、ひとたび生成されると、効率的に不変になり得るので、実行される実編集動作が必要ないかもしれない。
【００４３】
スキーマロックをパラグラフなどの文書コンポーネントと関連付けることもできる。代替として、ウェブブラウザベースのクライアントは、共同オーサリングを許可しない特徴の広範なセットを有することができる。ブラウザのクライアントがスキーマロックを用いてすでに開いている文書（即ち、別のクライアントがロックを用いた）を見つけることができたとしても、ブラウザのクライアントは、全文書をスキャンする必要があり、問題となる特徴が見つからなければ、ユーザに編集のみを許可することもある。これは、サーバアプリケーションがほとんどすべての文書コンテンツを読み取って、そのコンテンツをグラフに変換することができ、そしていつでも動作を停止できるので、ウェブブラウザベースのクライアントに対する付加的な負荷とはならない。
【００４４】
別の実施形態において、シード同期を、文書内の各パラグラフ識別子に再度番号を割り当てる要求として使用できる。要求は、要素を二次的メタデータまたは主メタデータ内の同じ名前に一致させることによって発行され得る。再番号割り当ては、文書識別子から開始される単一の増分カウントとして実行され、および事前定義された順序で文書内のパラグラフをウォークスルーすることによって実行され得る。二次的メタデータの後続するすべての要求および情報は、元の文書に記憶されたパラグラフ識別子ではなく、再番号割り当てから生じるパラグラフ識別子を参照できる。
【００４５】
シード同期化要求の実装は、再番号割り当てがヘッダ／フッタ、フットノートおよびエンドノート、テキストボックス内のテキストなどの、ブラウザでは（現在）見えない文書の部分に依存する場合があるので、ブラウザでは不可能かもしれない。シード同期化をサーバのフロントエンドに実装できる。
【００４６】
シード同期要求を実装する単純な手法は、文書のすべてのパラグラフのプロパティ（パラグラフ識別子が記憶されているプロパティ）を変更できる新しい修正を生成することである。第２の手法は、フロントエンド内の特定の要求メソッドを実装することである。そのメソッドは、古いパラグラフ識別子を新しいパラグラフ識別子にマップするディクショナリの戻り値を有する。ブラウザは、二次的メタデータのシード同期要素を受信する時に要求を発行して、結果として生じたマップを使用してメタデータのリマインダを解釈できる。
【００４７】
代替的実施形態において、サーバの負荷を最小に保つために、ユーザが文書の単一の共作成者であるかどうかを判定する負荷の軽い要求を実装できる。ウェブブラウザベースのクライアントもサーバの負荷を最小限にする「自分１人ですか？」という要求を実装できる。
【００４８】
例示的実施形態として全シーケンスを以下に示す。以下のステップにおいて、（Ｂ）は、「ブラウザ」であり、（Ｓ）は、（フロントエンドアプリケーションの）サーバである。
【００４９】
１、（Ｂ）ファイルのコンテンツを入手するウェブブラウザベースのサービス要求を行う。
【００５０】
２、（Ｓ）スキーマロックを用いてファイルをロックして、セッションに参加することを試みる。
ａ、（Ｓ）スキーマロックによってファイルが既にロックされていて、継続する場合、ユーザは、もう単独ではない。
ｂ、（Ｓ）ファイルがその他のロックによってロックされた場合、セッションに失敗する。
ｃ、（Ｓ）現在のユーザの認証情報およびサーバ時間を入手する要求を発行する。
【００５１】
３、（Ｓ）ストアからファイルを（ストリームとして）読み出す。
【００５２】
４、（Ｓ）ストリームを（ファイル内の各ｘｍｌ要素をウォークスルーする）グラフに変換する。
ａ、（Ｓ）共同オーサリングのセッションにおいて許可されていない要素と遭遇した場合に記憶する。
【００５３】
５、（Ｓ）ロックを調整する。
ａ、（Ｓ）すでにスキーマロックを用いてロックされた場合、
ｉ、  ステップ４ａから発行がない場合、継続する。あるいは、排他的ロックに切り替えるように試みる。
ｂ、（Ｓ）アプリケーションがスキーマロックか、または排他的ロックで終了したかどうかを記録する。さらに、ユーザが文書内ですでに単独ではない場合、２ａから記憶する。
【００５４】
６、（Ｓ）、このグラフを記憶装置に記憶し、そしてグラフをユーザ専用ルートに提供する。この方法において、複数のユーザは、すべての異なるグラフコンテンツを記憶装置の同じパーティション内に有して、互いに衝突しないようにすることができる。２人のユーザが同じ文書から開始するが、異なる変更を行う場合を例にする。グラフを記憶するために、グラフの変更は、保存動作を呼び出して、グラフの変更が１つずつコミットされるまで、別個のままにしなければならない。同じユーザが別のコンピュータまたは別のブラウザのインスタンスから（クラッシュの後でも）アプリケーションを起動する場合に、システムが、グラフのどの部分がそのユーザに属しているかを特定することができるように、このルートは、ユーザに固有である（しかし、ユーザのブラウザまたはコンピュータに固有ではない）。
【００５５】
７、（Ｓ）このグラフをブラウザに送る。
【００５６】
８、（Ｂ）コンテンツを非直列化して表示する。
【００５７】
９、（Ｂ）ステップ５ｃにおいて、アプリケーションがスキーマロックを有する場合、
ａ、（Ｂ）（ステップ２ａから）現時点で単独の場合、他の作成者が参加する時／参加するかどうかを判定するためにＡｍＩＡｌｏｎｅに頻繁に尋ねるプロセスを開始する。
ｂ、（Ｂ）ユーザが編集する時、（ユーザが単独または単独でないかに関わらず）ロックを生成する。
ｃ、（ステップ２ａから）単独でない場合または（上記の９ａから）単独でない場合、
ｉ、（Ｂ）このセッション（ステップ９ｂ）の間に生成されるロックの表示を開始する。
ｉｉ、（Ｂ）現在のユーザをエディタ表に付加する要求を発行する。
ｉｉｉ、（Ｂ）エディタ表および二次的メタデータに対する反復プロセスを開始する。
【００５８】
付加的な作成者またはロックに関する新しい情報を適切な情報としてグラフに適用できる。ひとたびユーザがエディタを離脱すると、アプリケーションは、エディタ表から現在のユーザを除去する要求および共同オーサリングセッションを離脱する要求を発行できる。
【００５９】
さらに別の実施形態において、実装は、「編集不可能な」領域をサポートできる。その完全な機能は、編集可能な領域と編集不可能な領域との両方、ならびにテキスト以外のオブジェクト、またはテキストと他のオブジェクトとの組み合わせを包含する範囲にわたる選択肢から成る。ユーザは、選択を行い、そして相手のコンテンツを編集不可能な領域に置いて、非ブラウザベースのクライアントに一貫した体験を提供することができる。
【００６０】
図３は、ある実施形態に従った例示的シナリオを示す。図３に示すように、アプリケーションサーバ３３０は、文書編集サービスを提供できる。文書は、テキスト、描画、イメージ、オーディオ、およびビデオを含むが、これらに限定されないさまざまフォーマットから構成されてよい。例示的実装は、複数のユーザの複数のクライアントアプリケーション３１０によって共同オーサリングされた文書を維持管理するアプリケーションサーバである。代替として、文書は、単一のフォーマットから構成されてよいし、またはテキスト、オーディオおよびビデオのコンテンツを組み合わせた文書などの、タイプの組み合わせを包含してもよい。
【００６１】
図３００に示すように、クライアントアプリケーションは、ユーザによって編集された文書を保存する要求を行う（３１２）ことができる。アプリケーションサーバは、文書記憶サーバ３５０に記憶された文書を読み出す（３３２）ことができる。ステップ３１４において、アプリケーションサーバは、ローカルに記憶された文書の基本グラフを読み出すまたは生成できる。ステップ３１６において、アプリケーションサーバは、ユーザ編集を包含するグラフの修正を読み出すことができる。その後、読み出された文書をローカルに記憶された基本修正に変換する（３１８）ことができる。基本修正と記憶された文書との間の変更は、アプリケーションサーバによって同期されることができる。ステップ３２０において、アプリケーションサーバは、最近再記憶された基本グラフの修正と、ユーザ編集を包含する任意の修正とを比較できる。基本グラフに入れられる編集は、ステップ３２２において文書に入力する準備ができている。これは、３２２において読み出す文書が、グラフ修正３１６を生成するのに使用された文書と同じ文書でなくても、起こり得ることに留意されたい。従って、共同オーサリングアプリケーションは、「元」文書のローカルコピーを保持する必要がなく、（アプリケーションは、サーバ上の最新のコピーに対して働くので）スケールアウトする能力が向上する。文書の変更は、記憶サーバに保存できる（３３４）。文書の変更を保存した後、アプリケーションサーバは、その変更を包含する修正を基本グラフに付加できる。ステップ３２６において、アプリケーショングラフは、変更されたグラフをローカルに記憶できる。ステップ３３６において、どのロックホールドもロックリフレッシュを用いて解除できる。
【００６２】
実施形態において、どの変更も、非ブラウザベースのクライアントとブラウザベースのクライアントとの両方における現在のセッション中に文書に付加できる。しかしながら、非ブラウザベースのクライアントなどのシッククライアントは、保存アクション中にサーバから文書の最新バージョンを入手できる。ユーザは、衝突する変更または編集を解消するように求められる場合がある。ユーザ選択は、衝突を解消するためにグラフ内の対応するコンポーネントに記録され得る。ブラウザベースのアプリケーションに送られる衝突解消情報は、編集時間、ユーザに認証情報、ユーザの存在情報、およびユーザの役割を含むことができる。結果として生じたコンテンツは、新しい最新のバージョンとしてサーバに戻って保存され得る。
【００６３】
別の実施形態において、保存中に統合するためのハイレベル実装は、以下を含むことができる。
【００６４】
１、他のユーザ（または作成者）によって行われた変更のセットを入手する。
【００６５】
２、ユーザによって行われた変更を他の作成者によって行われた変更と比較する。サーバは、「衝突」として双方によって操作されるすべてのオブジェクトを収集できる。
【００６６】
３、衝突すると見なされるすべてのオブジェクトに対して、サーバは、アプリケーションが、ユーザが介入せずに衝突を解消できるかどうかを判定できる。衝突の解消は、望ましい変更の統合セットを表す現在のユーザの修正を操作することによって実現され得る。オブジェクトが解消されないままである場合、サーバは、統合動作を停止して、ブラウザに信号を送って衝突を解消するＵＩをユーザに提示するようにさせる。
【００６７】
４、変更を文書に適用して、記憶サーバに保存できる。
【００６８】
５、アプリケーションサーバは、変更のセットを他の作成者からブラウザに送ることができる。さらに、衝突を解消するために、ユーザ自身の変更に対して変更を任意に行うことができ、その変更を送ることもできる。
【００６９】
他のユーザによって行われる変更のセットの入手は、なおも課題が存在し得る。他のユーザの変更を管理するための入力は、不完全に見えるかもしれない。文書の現在の状態は、利用できるであろうが、元の状態は、利用できない。しかしながら、アプリケーションサーバは、元グラフを通じて文書の元の状態について把握している。ユーザによって行われる変更は、一部グラフが元に変換されなかった文書において、他の作成者によって行われた変更と恐らく衝突しないであろう。サーバアプリケーションは、文書の現在の状態を変換し、そして結果として生じたグラフを元のグラフと比較できる。比較は、文書の他の共作成者によって行われた変更のセットにおいて生じ得る。変更のセットは、グラフの２つの状態の違いとなり得るので、修正として最も自然に表すことができる。従って、サーバアプリケーションは、衝突を検出するのに必要なすべての情報を入手し、そして統合動作の最終において他の共作成者の変更をブラウザに送ることができるようになる。
【００７０】
現在の文書の状態から生じるグラフと元グラフとの比較は、それ自体に課題が存在する。パラグラフおよび他のオブジェクトが付加または除去されたか、あるいは任意の方法で移動された恐れがあるので、グラフ内のノードを１つずつ比較することを単に用いることができない。ある種の固有の識別子がアタッチされる文書（パラグラフまたは表の行を例とする）の構成では、これらの識別子を使用して、すぐに対応しなければならない元グラフからノードを選び出し、そして変化があったかどうかを確かめるためにプロパティを比較することができる。例示的実施形態において、システムは、最初に元グラフ全体にわたって読み込み、そしてパラグラフの識別子によってそのオブジェクト（元状態）を表したグラフノードにマップすることを構築する。その後、文書の現在の状態に対応するグラフを構築する。この新しいグラフのパラグラフに対応するノードが構成されると、元ノードは、パラグラフの識別子を使用して検索される。そのようなパラグラフが、元グラフに基づいて構成されたマップ内で見つからない場合、そのパラグラフは、他の作成者によって新しく付加されたことになる。ノードがマップ内で見つかった場合、現在のノードのプロパティは、元ノードのプロパティと比較される。プロパティが任意に付加または除去された場合、またはプロパティの値が元ノードの同じプロパティの値とは異なる場合、そのプロパティは、変更されたことになる。
【００７１】
文書内に固有の識別子が適用される構成もあり得る。現在の構成と元の構成とを比較するために、固有の識別子が関連するそのような構成の近くまたは構成内に包含する他のオブジェクトに依存することができる。例えば、セル表は、それ自体の固有の識別子を有していない。しかしながら、この実施形態において、任意のセル表に包含する最終パラグラフと関連付けられる識別子は、その表（ならびに、そのパラグラフ自体）（セル表およびパラグラフノードのオブジェクトは、異なったタイプから成るので、両方の識別子として同じ値を使用する際の曖昧さがない）の識別子として使用される。これは、それらの識別子が変更しないように、そのオブジェクトを変更する時のある法則を守るために編集システムの他の部分が必要になる。セル表の例の場合、セルに対するどの編集も、最終パラグラフのパラグラフ識別子を変更できない。
【００７２】
代替として、衝突を自動的に解消できない場合、他の作成者によって行われた変更を包含する修正は、衝突するオブジェクトとマークされてブラウザに送られ得る。さらに、同じ変更をブラウザに送って、ユーザの文書を最新の状態にすることができる。最後に、ユーザに、衝突を解消するためにＵＩを提示できる。ユーザは、すべての衝突が解消されると、再度保存を試みることができる。
【００７３】
保存動作中に統合を実行する例示的シーケンスを詳述する。以下のステップにおいて、（Ｂ）は、「ブラウザ」であり、（Ｓ）は、（フロントエンドアプリケーションの）サーバである。
【００７４】
１、（Ｂ）文書を保存するウェブブラウザベースのサービス要求を送る。
【００７５】
２、（Ｓ）記憶サーバから文書の現在の状態を（ＩＳｔｒｅａｍとして）読み出す。
【００７６】
３、（Ｓ）記憶装置に記憶されていた元グラフをロード中に読み出す。
【００７７】
４、（Ｓ）ユーザが行った編集としてサーバに蓄積された修正を読み出す。
【００７８】
５、（Ｓ）ステップ３の元グラフを使用して、他のユーザによって行われた変更の修正を蓄積するベースラインとして文書を変換する。
【００７９】
６、（Ｓ）ステップ４の修正をステップ５の修正と比較する。
【００８０】
ａ、（Ｓ）両方のステップにおいてオブジェクトが見つかった場合、ステップ３または４による修正を変更することによって解消を試みる。
【００８１】
ｂ、どのオブジェクトも解消することができない場合、保存を停止し、ステップ５の修正に戻る。
【００８２】
７、（Ｓ）文書の保存およびステップによって変更された修正を実行する。
【００８３】
８、（Ｓ）結果として生じた文書を記憶サーバに戻して記憶する。
【００８４】
９、（Ｓ）ステップ５による修正を基本グラフに付加して、その結果を新しいベースとしてマークする。
【００８５】
１０、（Ｓ）ステップ６の（恐らく変更された）修正を記憶装置に付加する。
【００８６】
１１、（Ｓ）ファイルのロックをリフレッシュする。
【００８７】
１２、（Ｓ）ステップ５の修正と（変更された場合）ステップ６の修正との両方を戻す。
【００８８】
図４Ａから図４Ｃまでは、ある実施形態に従った例示的シナリオを示す。例示的実施形態において、表の構造的変更の統合は、変更が互いに直交する場合に複雑になり得る。図４１０において、ユーザは、２×２表の編集を開始できる。ユーザが中央の列を付加して、そして他のユーザが中央の行を付加する場合、予測される結果は、図４２０ようになる。予測される結果を達成するには、サーバアプリケーションは、付加される行（表が２つの行を有する場合に付加される）が、統合中にその表に付加される第３のセルを有する必要があるかを検出する必要があり得る。あるいは、他のユーザによって付加された列が、セルが欠けている図４３０の表につながる恐れがある。このタスクは、列が第１クラスのオブジェクトとして文書でもグラフ表記でも表されないという事実によって困難になる。この複雑な状況は、１人のユーザが列（その列の数が変更していないように見える）を検出して列の同じ番号を付加する時か、またはすべての共作成者のアクションの総数が全表を除去する数に達する時に生じ得る。
【００８９】
複雑な統合解決の代替的実施形態において、ブラウザベースのアプリケーションは、同じパラグラフを編集する２人の作成者に対処しなければならない場合がある。ブラウザベースのアプリケーションは、キャラクターレベルで変更を組み合わせるのに望ましくないので、ユーザ入力無しではこの衝突の解消を試みることができない。アプリケーションは、ワードの複雑さのために無意味なワードを生成する恐れがある。分類する次の論理的単位は、ワード処理の境界に置かれるであろう。ブラウザベースのアプリケーションは、２つの付加または削除が合理的に独立したものと理解されている表のパラグラフまたは行と違って、パラグラフからワードまたは文を付加または除去するには、コンテンツをかなり変更するため、ユーザ入力も要求できる。
【００９０】
複雑な統合解決の別の実施形態において、ブラウザベースのアプリケーションは、リストおよび再番号割り当てを用いて衝突を解消しなければならない場合がある。実装は、ワード処理アプリケーションなどのブラウザベースのアプリケーションが、リスト項目を記録し、そしてその項目に番号を割り当てることができる方法に関するコードの中で最高のレベルである。リスト項目の番号を計算し、そしてグラフ自体に（永続的でないプロパティとして）記憶できる。リスト項目として更新される番号を付加および削除するか、または上げるおよび下げることができる。さらに、ワード処理の場合、そのアプリケーションは、ブラウザのそのようなすべての項目メンバの値を再計算できない。しかしながら、サーバアプリケーションは、ロード動作中に値を計算して、ユーザ編集アクションの後、追加的にのみ変更できる。ユーザと他の共作成者との両方が衝突しない変更を行うことができる場合（しかし、結果として変更するリスト内の項目の番号割り当てが生じる）、サーバアプリケーションは、統合動作の部分として番号を更新する必要があるかもしれない。
【００９１】
上記のオンライン文書編集を同期するシステムおよび実装は、図解を目的とし、実施形態に対して制限するものではない。文書は、テキスト、描画、イメージ、オーディオ、およびビデオを含むが、これらに限定されないさまざまなタイプから構成されてよい。文書は、タイプの組み合わせによって構成され得る。ユーザ編集を、本明細書で説明される発明の原理を使用した他のモジュール、プロセス、および構成を用いて同期できる。
【００９２】
図５は、実施形態を実装できる例示的ネットワーク化環境である。ユーザ編集の同期化を管理するサーバアプリケーションを、ホストサーバなどの、１または複数のサーバ５１４または単一のサーバ（例えば、ウェブサーバ）５１６上で実行されるソフトウェア経由で実装できる。プラットフォームは、ネットワーク５１０を介してスマートフォン５１３、ラップトップコンピュータ５１２、またはデスクトップコンピュータ５１１（「クライアントデバイス」）などの、個々のコンピューティングデバイス上のクライアントアプリケーションと通信できる。
【００９３】
上記のように、文書アプリケーションサーバは、文書記憶サーバに記憶された文書のユーザ編集を同期するアルゴリズムを実行できる。ユーザが文書のコンポーネントを編集する場合、アプリケーションサーバは、ユーザ編集中にロックされたコンポーネントに関する情報を、クライアントデバイス５１１、５１２、５１３上で文書を編集する他の共作成者に送信できる。
【００９４】
クライアントデバイス５１１、５１２、５１３は、以前に説明したように、リモートサーバ（複数）（例えば、サーバ５１４のうちの１つ）上で実行されるアプリケーションにアクセスできるようにさせる。サーバ（複数）は、直接またはデータベースサーバ５１８を介して関連データをデータストア（複数）５１９から読み出すまたはそのデータストアに記憶できる。
【００９５】
ネットワーク（複数）５１０は、サーバ、クライアント、インターネットサービスプロバイダ、および通信媒体のうちの任意のトポロジーを備えることができる。実施形態に従ったシステムは、静的または動的トポロジーを有することができる。ネットワーク（複数）５１０は、企業ネットワークなどのセキュアなネットワーク、無線オープンネットワークなどのセキュアでないネットワーク、またはインターネットを含むことができる。ネットワーク（複数）５１０は、公衆交換電話網（ＰＳＴＮ）またはセルラーネットワークなどの、他のネットワークを介して通信を調整することもできる。さらに、ネットワーク（複数）５１０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）またはこれに順ずる、短距離無線ネットワークを含むことができる。ネットワーク（複数）５１０は、本明細書で説明されるノード間の通信を提供する。ネットワーク（複数）５１０は、例として、音響、ＲＦ、赤外線および他の無線媒体などの、無線媒体を含むが、これらに限定されない。
【００９６】
コンピューティングデバイス、アプリケーション、データソース、およびデータ分散システムによる他の多くの構成を用いて、オンライン文書編集を同期できる。さらに、図５において論じたネットワーク化環境は、単に図解を目的とするものである。実施形態は、例示的アプリケーション、モジュール、またはプロセスに限定されない。
【００９７】
図６および関連する論述は、実施形態を実装できることに適したコンピューティング環境の簡潔で一般的な説明を与えることを意図する。図６を参照し、実施形態に従って、コンピューティングデバイス６００などのアプリケーションの例示的コンピューティングオペレーティング環境を説明する。基本構成において、コンピューティングデバイス６００は、オンライン文書のユーザ編集を同期するオンラインアプリケーションサーバであり、少なくとも１つの処理ユニット６０２およびシステムメモリ６０４を含むことができる。コンピューティングデバイス６００は、プログラムを実行する際に協働する複数の処理ユニットも含むことができる。コンピューティングデバイスの正確な構成およびタイプに応じて、システムメモリ６０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）またはその２つのある組み合わせであってよい。システムメモリ６０４は、典型的には、ワシントン州レドモンドにあるマクロソフト社製ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムなどの、プラットフォームの動作を制御するのに適したオペレーティングシステム６０５を含む。システムメモリ６０４は、プログラムモジュール６０６、文書サービス６２２、および同期化モジュール６２４などの、１または複数のソフトウェアアプリケーションも含むことができる。
【００９８】
文書サービス６２２は、編集用のオンライン文書を提供するサービスの一部であってよい。同期化モジュール６２４は、ユーザ編集を記憶された文書に同期して、共同オーサリング編集によって生じる衝突を解消することができる。文書は、コンポーネントに細分化され、そしてコンポーネントは、コンポーネントレベルのロックをパラグラフなどの文書の部分的編集に実装するグラフに記憶され得る。この基本構成は、図６の破線６０８内のコンポーネントによって示される。
【００９９】
コンピューティングデバイス６００は、付加的な特徴または機能性を有することができる。例えば、磁気ディスク、光ディスクまたは磁気テープ、光テープなどの、付加的なデータ記憶デバイス（リムーバブルおよび／またはノンリムーバブル）を含むこともできる。そのような付加的記憶装置は、図６のリムーバブル記憶装置６０９およびノンリムーバブル記憶装置６１０によって示される。コンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの、情報を記憶する任意の方法または技術で実装される、揮発性および不揮発性、リムーバブルおよびノンリムーバブル媒体を含むことができる。システムメモリ６０４、リムーバブル記憶装置６０９およびノンリムーバブル記憶装置６１０は、すべてコンピュータ可読記憶媒体の例である。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用することができ、且つコンピューティングデバイス６００によってアクセスすることができるその他の媒体を含むが、これらに限定されない。このような任意のコンピュータ可読記憶媒体は、コンピューティングデバイス６００の一部であってよい。コンピューティングデバイス６００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、および同様の入力デバイスなどの、入力デバイス（複数）６１２を有することもできる。ディスプレイ、スピーカ、プリンタ、および他のタイプの出力デバイスなどの、出力デバイス（複数）６１４も含むことができる。このようなデバイスは当業者には周知であり、ここで詳細に論じる必要はない。
【０１００】
コンピューティングデバイス６００は、デバイスが、分散コンピューティング環境における無線ネットワーク、衛星リンク、セルラーリンク、および同様の機構などを介して、他のデバイス６１８との通信を行うようにさせる通信接続６１６を包含することもできる。他のデバイス６１８は、通信アプリケーション、記憶サーバ、および同様のデバイスを実行するコンピュータデバイス（複数）を含むことができる。通信接続（複数）６１６は、通信媒体の一例である。通信媒体は、その中にコンピュータ可読命令、データ構造、プログラムモジュール、または搬送波または他の移送機構などの、変調データ信号の他のデータを含むことができ、そして任意の情報配信媒体を含む。用語「変調データ信号」は、その特性セットのうちの１または複数を有するか、または信号の情報を符号化することに関してそのような方法で変更される信号を意味する。通信媒体は、例として、有線ネットワークまたは直接有線接続などの、有線媒体と、音響、ＲＦ、赤外線および他の無線媒体などの、無線媒体とを含むが、これらに限定されない。
【０１０１】
実施形態の例も方法を含む。その方法を、本明細書で説明される構造を含む、いくつかの方法で実装することができる。そのような１つの方法は、本明細書で説明されるタイプのデバイスをマシン動作によって行うことである。
【０１０２】
別の選択的方法は、一部を実行する１または複数の人間のオペレータと共に実行される方法の個々の動作のうちの１または複数に関する。この人間のオペレータは、互いに共同配置される必要はないが、それぞれは、唯一、プログラムの一部を実行するマシンと共に配置されなければならない。
【０１０３】
図７は、実施形態に従って、修正を文書コンポーネントレベルで制御することによってオンライン文書編集を同期するプロセスである、プロセス７００の論理流れ図を示す。プロセス７００を、オンライン文書サービスをクライアントに提供するアプリケーションサーバによって実装できる。
【０１０４】
プロセス７００は、動作７１０から開始し、そこでオンライン文書アプリケーションサーバ（例えば、ウェブサーバのフロントエンド）は、ユーザから文書の要求を受信する。文書は、さまざまなフォーマットから構成されてよい。ユーザ要求を受信すると、アプリケーションサーバは、動作７２０において文書が記憶サーバでロックされるようにする要求ができる。文書をロックした後、アプリケーションサーバは、動作７３０において記憶サーバから文書を読み出すことができる。記憶サーバは、文書をストリームとしてアプリケーションサーバに送信できる。アプリケーションサーバは、動作７４０において、ストリームを文書コンポーネントに変換し、そしてコンポーネントをグラフにロードできる。サーバは、読み出された文書を包含するグラフ修正を、ローカルに記憶された基本グラフと比較し、そしてコンポーネントの変更を任意に同期できる。
【０１０５】
動作７５０において、アプリケーションサーバは、どの文書コンポーネントがユーザによって変更されたかを判定できる。動作７６０において、保存動作は、ユーザが保存動作を呼び出した後で実行され得るし、アプリケーションサーバは、ユーザ変更に基づいてグラフのどのコンポーネントをロックするかを判定し、そして後続の動作７７０においてグラフの新しい修正を生成する間に、対応するコンポーネントの変更を記録できる。アプリケーションサーバは、動作７８０において、現在働いているコンポーネント上でユーザ編集が同時にならないように、文書ロックをローカルグラフ上のコンポーネントベースのロックに変更できる。クライアントアプリケーションは、文書のどのコンポーネントがユーザによってロックされかまたは動かされるかを示す通知を指示することができる。提供される情報は、ユーザ存在情報、およびコンポーネントの現在の作成者を示す作成者名も包含できる。さらに、文書レベルのロックもユーザに表示することができる。さらに、共作成者の存在情報は、共作成者が最後に編集したグラフのコンポーネントに記憶され得る。共作成者の存在情報は、編集されたコンポーネントを有するクライアントアプリケーションによって表示され得る。
【０１０６】
文書内の他の作成者の情報を示すメタデータを受信すると、現在のユーザは、ロックされたコンポーネントをさらに変更することができない。他の作成者が相手の変更をコミットするために保存する場合／時、それによって保持されたロックを任意に除去し、代わりに「リフレッシュ要求された」ロックに変えることができる。このロックは、異なる体裁を有するので、もはや他の作成者と関連しない。
【０１０７】
逆に、現在のユーザが編集アクションを実行しない場合、自分達の現在の作成者の存在情報は、（必要に応じて）文書内ロックの存在情報を記述するメタデータに付加するよことによって他の作成者に通信され得る。現在のユーザが自身の変更を保存する場合、現在のユーザによって保持されたロックを任意に除去する要求をサーバに送って、代わりに他の人に対する「リフレッシュ要求された」ロックに変えることができる。
【０１０８】
プロセス７００に含まれる動作は、図解を目的とするものである。実施形態に従ったオンライン文書編集の同期は、本明細書で説明される発明の原理を使用して、ステップを少なくしたまたは付加した同様のプロセス、ならびに動作の異なる順序によって実装されてよい。
【０１０９】
上記の明細書において、例およびデータは、製品の完全な説明および実施形態の構成の使用を提供する。発明の主題が構造的特徴および／または方法論的動作に固有の言語で説明されているが、添付の特許請求の範囲で定義される発明の主題は、必ずしも上記の固有の特徴または動作に限定されるものではないことを理解されたい。むしろ、上記の固有の言語および動作は、特許請求の範囲および実施形態を実装する例示的形態として開示される。
【図１】
2013541115.tif 000003
【図２】
2013541115.tif 000004
【図３】
2013541115.tif 000005
【図４Ａ】
2013541115.tif 000006
【図４Ｂ】
2013541115.tif 000007
【図４Ｃ】
2013541115.tif 000008
【図５】
2013541115.tif 000009
【図６】
2013541115.tif 000010
【図７】
2013541115.tif 000011
【国際調査報告】
2013541115.tif 000012
2013541115.tif 000013