JP2016511883A - コンテンツキュレーションのためのアプリケーションプログラミングインタフェース - Google Patents

Abstract

位置識別子を通して特定される文書のコンテンツブロックのアドレスを作成するためのアプリケーションプログラミングインタフェース（ＡＰＩ）ならびに、作成されたアドレスからコンテンツを取得する、および作成されたアドレスにコンテンツを戻して入れる、または統合するためのＡＰＩによって、コンテンツキュレーションを容易にすることができる。変換および統合サービスを含むアクセスサービスを使用して、様々なクライアントに適したフォーマットでコンテンツブロックを提供することができる。コンテンツブロックが少なくとも２つのユニフォームリソースロケータ（ＵＲＬ）を使用して取り込まれる場合でも、複数のコンテンツブロックが単一の文書として取得されるように文書ビューが描かれる。

Description

[0001]共同作業およびファイル共有は共同作業用ソフトウェアの進歩につれて容易になってきた。しかし、すべてのデバイスで共同執筆および共同作業のサポートが可能なわけではない。デバイスには共同作業に対応しないもの、または対象のデジタルコンテンツをアクセスおよび修正するすべてのシステムが同じプログラムを実行することを要求するものがある。ある人があるデジタルコンテンツをアクセス、共有、および共同執筆する能力は、そのデジタルコンテンツを閲覧、修正し、その修正を伝播させて、別の人（または別のプラットフォーム上の同一人物）によってアクセスされたときにその修正がデジタルコンテンツの一部として反映されるようにするために、そのデジタルコンテンツのフォーマットを認識する適切なソフトウェアプログラムおよび、そのプログラムを実行することのできるデバイスをもっているかどうかに、ある程度依存する。

[0002]異なるプラットフォームを使用するデバイスの急増に伴い、独自のフォーマットのみのアクセスおよび表示が可能な、または、あるフィーチャの以前のバージョンのコンテンツのみの編集が可能なプログラムを実行するデバイスで、ある１つのフォーマットのコンテンツを共有、アクセスおよび編集することは難題となる可能性がある。それに加え、あるアプリケーションの新バージョンに新しいフィーチャが追加されると、新バージョンは下位互換性をもたなければならず、かつ／または将来のバージョンに対応するための拡張編集機能を組み込まなければならない。さらに、複数のファイルからのコンテンツの組み合わせが望まれることがあり、そのいくつかが異なるファイルフォーマットまたはバージョンであることがある。

[0003]アプリケーションプログラミングインタフェースおよびアクセスサービスが提供され、これらのサービスでは１つまたは複数のリソースからのコンテンツをユーザに対して単一の文書として提示することが可能である。この文書、またはビューは、アプリケーション（例えば、ビューア、エディタなど）によって定義されるコンテンツブロック（ｂｌｏｃｋｓ ｏｆ ｃｏｎｔｅｎｔ）、またはユーザによって定義されるコンテンツブロックを含むことができ、これらのブロックはアクセスサービスを通して個別にアドレス指定およびアクセスすることができる。アドレス指定可能なコンテンツブロックを大きな文書の枠から作成すること、およびアドレス指定可能なコンテンツブロックのコンテンツを取り出すことを可能にするアプリケーションプログラミングインタフェース（ＡＰＩ）によって、コンテンツキュレーションを促進することができる。

[0004]一実施形態によれば、変換および統合サービスを行うシステムによってクライアントにサービスされる文書は、１組の体験およびその中のコンテンツである。文書または文書の中から選択されたコンテンツブロックは、システムからの取り出しが可能な場所にマスター文書として第１のファイルフォーマットで保管することができ、クライアントから要求されると、文書を適切なファイルフォーマットに変換してクライアントにサービスすることができる。また、サービスされる文書は、そのクライアントでサポートされるフィーチャバージョンを考慮に入れることができる。

[0005]サービスされた文書をクライアントデバイスに表示することができる。このサービスは文書の適用範囲を広げ（プラットフォームの異なる複数のデバイスにまで）、その文書のために、そのクライアントデバイスに適した体験を作成する。文書は、どのクライアントでも全く同一に見える必要はない。むしろ、文書をユーザの体験に合わせてカスタマイズし、デバイスに適合させることができる。文書がクライアントデバイスに表示された後は、ユーザはローカルで文書を修正することができる。修正は、コンテンツに対する修正ならびに文書に関連するデータの修正を含むことができる。例えば、注釈、コメント、テキスト編集、画像編集、およびその他の修正が加えられてもよい。次に、ユーザは修正をサーバに戻して保存することができる。ユーザが修正した文書の部分が異なるファイルフォーマットであるか、または異なるバージョンのフィーチャを含んでいる場合でも、サーバは修正を統合することができる。

[0006]修正をマスター文書に統合することに加えて、クライアントデバイスに表示されている文書の全部または一部を別のマスター文書として保存し、アドレスサービスによってアドレスを指定することができる。

[0007]一実施形態によれば、第１の文書の第１のビューを表示することができる。第１の文書を、第１のアドレスから取り出し、必要に応じて適切なフォーマットまたはフィーチャバージョンに変換することによってクライアントにサービスすることができる。クライアントに表示された文書ビューで作業しているユーザは、編集またはその他のさらなる処置のためにコンテンツのサブセットを選択することができる。選択される部分は、特定されたコンテンツであり得る。特定されたコンテンツは、段落識別子、行識別子、文字識別子、範囲、部分識別子、またはそれらの組み合わせなどの位置識別子を使用して特定することができる。特定されたコンテンツ用に第２のアドレスを取得するために、アドレスサービスを起動することができる。次に、そのコンテンツのサブセットを第２のアドレスを通じてアクセスし、単独に修正することができる。

[0008]別の実装によれば、文書ビューを、少なくとも２つのリソースからのコンテンツを含めてクライアントに提供することができる。例えば、アクセスサービスを呼び出すとき、少なくとも、第１のアドレスからの第１のコンテンツブロックおよび第２のアドレスからの第２のコンテンツブロックへの要求を伴うことができる。第１のコンテンツブロックと第２のコンテンツブロックを組み合わせることができる。組み合わされたコンテンツブロックは位置識別子を含み、これを使用して新しいアドレスを作成することができる。

[0009]文書ビューを、少なくとも２つのユニフォームリソースロケータ（ＵＲＬ）を使用して取り込んだコンテンツを有する複数のコンテンツブロックと位置識別子とを含むように提供（またはサービス）することができる。１つまたは複数のコンテンツブロック（コンテンツブロックのサブセットでもよい）を、新しいＵＲＬを割り当てるために選択可能であり、この新しいＵＲＬを通じて単独にアクセスすることができる。

[0010]この概要は、いくつかの概念を選んで簡略化した形で紹介するためのものであり、これらの概念は、下記の、発明を実施するための形態において詳細に説明される。この概要は、請求項に記載された主題の重要なフィーチャまたは不可欠なフィーチャを特定することを意図せず、請求項に記載された主題の範囲を制限するために使用されることも意図しない。

[0011]ある実施形態が行われてもよい動作環境を示す図である。 [0012]本発明の一実施形態によるエンドポイントの動作環境を示す図である。 [0013]本発明の一実施形態によるコンピューティング環境を示す図である。 [0014]本発明の一実施形態による変換および統合サービスの処理フロー例を示す図である。 [0015]変換および統合サービスのシナリオ例を示す図である。 変換および統合サービスのシナリオ例を示す図である。 変換および統合サービスのシナリオ例を示す図である。 変換および統合サービスのシナリオ例を示す図である。 [0016]本発明の一実施形態による、エディタによって行われる処理を示す図である。 [0017]本発明の一実施形態による、複数のエディタを使用して文書を共同作業するための方法の処理フローを示す図である。 [0018]いくつかの実施形態で使用されるコンピューティングデバイスの構成要素を示すブロック線図である。 [0019]本発明の一実施形態による、アドレス指定可能な複数のコンテンツブロックを有する文書ビューを示す図である。 [0020]本発明の一実施形態によるコンテンツキュレーションのためのシステムを示す図である。 [0021]文書のコンテンツのサブセットに新しいアドレスを作成するシナリオ例を示す図である。 [0022]文書から作成されたコンテンツのサブセットを使用する、共同作業のための方法の処理フローを示す図である。 [0023]例示的一実施形態を説明する動作環境を示す図である。 [0024]キュレーションされたコンテンツにアクセスするための方法の処理フローを示す図である。

[0025]アプリケーションプログラミングインタフェースおよびアクセスサービスが提供され、これらのサービスでは１つまたは複数のリソースからのコンテンツをユーザに対して単一の文書として提示することが可能である。この文書、またはビューは、アプリケーション（例えば、ビューア、エディタなど）によって定義されるコンテンツブロック（ｂｌｏｃｋｓ ｏｆ ｃｏｎｔｅｎｔ）、またはユーザによって定義されるコンテンツブロックを含むことができ、これらのブロックはアクセスサービスを通して個別にアドレス指定およびアクセスすることができる。文書の特定可能な領域に関するアドレス作成すること、および作成されたアドレスからコンテンツを取り出すことを可能にするアプリケーションプログラミングインタフェース（ＡＰＩ）によって、コンテンツキュレーション（および配布）を促進することができる。

[0026]コンテンツキュレーションとは、様々なソースからのコンテンツを編成および提示（または共有）することである。
[0027]コンテンツのいくつかの断片が互いに別々の場所にあり、互いに異なるフォーマットで保管されている場合でも、これらのコンテンツの断片を１つの文書として組み合わせることができ、読者、エディタ、またはその他のクライアントが、これを１つのまとまった断片として閲覧することができる。

[0028]このことは、画定された各コンテンツブロックにアドレスを与えることによって達成できる。アクセスサービスは１つまたは複数のコンテンツブロックアドレスを含む要求を受け取り、その１つまたは複数のコンテンツブロックアドレスから様々なコンテンツブロックを取り出し、コンテンツを組み合わせてクライアントに提供する。文書ビュー内で、ブロックの境界は、ブロックの組み合わせまたは分解がクライアントに許可される範囲までは動的であることができる。例えば、元は１つのブロックで形成されている文書（その文書を構成する複数の要素に１つのアドレスでアクセスできる）のビューを提示してもよい。

[0029]文書の閲覧中、あるユーザが別の文書またはアプリケーションで使用するために、コンテンツの少なくとも一部をキャプチャしようとすることもある。このシナリオでは、ユーザは文書の中の特定された部分のアドレスを要求してもよい。この部分は、位置識別子を使用してコンテンツブロックとして特定することができる。新しいアドレスが作成されれば、別のクライアント（またはサーバ）が、特定された位置を使用して作成されたアドレスの位置からコンテンツを取得することによって、そのアドレスを有するブロックにアクセスしてもよい。あるケースでは、それらの複数の異なるブロックから文書が作成されてもよい。またあるケースでは、ブロックが改訂されると文書が改訂される。１つのアドレスが、複数のストレージデバイスおよび分散コンピューティング環境を含むリソースを指してもよいことを理解されたい。

[0030]電子文書は、一般に紙製文書のデジタル等価物と理解されており、そのコンテンツの作成、注釈付け、修正が文書エディタによって容易になり、最近ではコンテンツの共有および共同作業も容易になっている。

[0031]修正には、コンテンツの修正ならびに文書に関するデータの修正を含むことができる。例えば、コメント、テキスト編集、画像編集、およびその他の修正が行われてもよい。ファイルの修正には、追加、削除、追加コンテンツおよびリッチなコンテンツを提供する作業、コメントを追加する作業、ならびに、画像エディタ内で画像を修正する作業を含むことができる。

[0032]本発明の一定の実施形態は文書（サービスとしての文書）に新しいフィーチャを加え、文書の中に体験のセットおよびコンテンツが提供される。体験のセットは、変換および統合サービスのコンテンツアクセスサービスを含む、サービスのセットに対応する。変換サービスでは、文書が閲覧される各クライアントに対して文書のコンテンツのカスタマイズが可能になり、統合サービスでは、文書への修正をマスター文書に再統合することが可能になる。マスター文書はコンテンツ、メタデータ、および文書に加えられた修正（コンテンツの修正およびメタデータの修正を含む）の集合体であってもよい。いくつかのケースでは、マスター文書は最も忠実度の高い文書として表示されることができる。

[0033]よって、忠実度の低いエディタの中で行われた修正または、あるフィーチャの以前のバージョンを使用した修正がマスター文書に再統合されたときは、統合サービスが忠実度の補正（ｆｉｄｅｌｉｔｙ ｒｅｈｙｄｒａｔｉｏｎ）をすることができる。

[0034]忠実度の補正とは、あるフィーチャの以前のバージョン、または低機能なエディタのファイル形式によって修正されたコンテンツを、全機能を備え、最新バージョンのフィーチャをもつコンテンツとして返すことである。例えば、あるグラフフィーチャに２つのバージョンがあり、第１のバージョンはリッチなチャート（３Ｄチャートなど）をもち、第２のバージョンはチャートを静止画像としてしか解釈できないとする。第２のバージョンに対応するエディタでコンテンツが編集された後から、第１のバージョンに対応するエディタでの閲覧／編集のために、静止画像に忠実度の補正を行って３Ｄチャートに戻すことができる。第１のバージョンはフィーチャの将来または後のバージョンでもよく、第２のバージョンはそのフィーチャの以前または早期のバージョンでもよい。他のケースでは、両方のバージョンは、同時期にリリースされながらも利用可能な機能が意図的に異なるバージョンであってもよい。

[0035]マスター文書は文書と称されるが、マスター文書の保管は、コンテンツおよび最新の編集フィーチャの追跡に適した任意のフォーマットで行うことができる。
[0036]これらのサービスを通して、消費者デバイスは様々なプラットフォームにわたって、クライアント側ソフトウェアまたは消費デバイスを複雑化することなくコンテンツにアクセスすることおよび修正することが可能である。

[0037]文書閲覧の柔軟性を高めるために、文書のブロック（ユーザまたはアプリケーションによって画定された部分）は、別々にアクセス、閲覧、および修正して、個別に使用またはマスター文書に戻して統合することができる。

[0038]（文書またはその他のコンテンツおよび関連情報の）ファイルフォーマットとは、ファイルの内容（および、場合によっては関連情報）に関する情報が符号化され、コンピュータ可読媒体に保管される様式である。ファイルタイプはファイルフォーマットと同義に使用されることがあるが、一般にはファイルフォーマットの分類を指す。例えば、ファイルタイプには文書ファイルタイプが含まれてもよく、これにはハイパーテキストマークアップ言語（ＨＴＭＬ）、Ａｄｏｂｅポータブルドキュメントフォーマット（ＰＤＦ）、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ文書（ＤＯＣ）、Ｏｆｆｉｃｅ オープン拡張可能マークアップ言語（ＯＯＸＭＬ）フォーマット（ＤＯＣＸ）などが含まれる。Ｍｉｃｒｏｓｏｆｔ ＷｏｒｄはＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．の登録商標であり、Ａｄｏｂｅ ＰＤＦはＡｄｏｂｅ Ｓｙｓｔｅｍｓ， Ｉｎｃ．の登録商標である。

[0039]本明細書で使用するときは「消費フォーマット」は、特定のデバイスまたはソフトウェアプログラムでサポートされるファイルフォーマット（例えば、「サポート対象ファイルフォーマット」）を指す。サポート対象のファイルフォーマットであることに加え、消費フォーマットは、デバイス（またはプログラム）が多様なユーザ体験をどのようにサポートできるかに関する、ファイルサイズ、機能などに関するフィーチャを含むことができる。

[0040]サービスとしての文書という枠組みに戻ると、変換および統合サービスを含むコンテンツアクセスサービスを、クラウドサービス体験の一部として提供することができる。この様式では、コンテンツは１つのフォーマットで作成されてもよく、あらゆるプラットフォームにわたって、コンテンツの消費者にシームレスな体験を提供し得る様式でのアクセスおよび編集が可能になり得る。

[0041]図１は、ある実施形態が行われてもよい動作環境を示す。
[0042]図１を参照すると、動作環境には１つまたは複数のクラウドまたはウェブサービスを含むことができる。本明細書に記載するコンテンツアクセスサービス１００はクラウドサービスまたはウェブサービスでもよい。

[0043]クラウドサービスとは一般に、拡張可能な処理能力およびストレージ能力を提供する、ホスティングされたサービスを指す。クラウドコンピューティングは、多くの場合、仮想化されたリソースを含むことがある。クラウドコンピューティングによって提示されるリソース自体はサービスとして提供され、クラウドコンピューティングの顧客は、物理インフラストラクチャを所有する第３者プロバイダからリソースを賃借して使用する。

[0044]クラウドサービス（例えば、大規模分散コンピューティング環境）によって、ウェブサービスの提供および／またはホスティングが可能である。ウェブサービスとは、ネットワーク上での相互運用的なマシン対マシンの対話をサポートし、ソフトウェアが他のソフトウェアアプリケーションに接続できるようにするソフトウェアシステムである。

[0045]ウェブサービスは、技術標準およびプロトコルの集合を提供する。例えば、あるウェブサービスは、メッセージを送受信するソフトウェアエージェントまたはハードウェアエージェント（例えば、ある特定のサービスを要求および提供するコンピューティングプラットフォーム）によって実装され得る機能を提供する。アプリケーションは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、拡張マークアップ言語（ＸＭＬ）、ウェブサービス記述言語（ＷＳＤＬ）、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクトノーテーション（ＪＳＯＮ）、ＳＯＡＰ（元は”ｓｉｍｐｌｅ ｏｂｊｅｃｔ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ”の略語）などの普遍的なウェブプロトコルおよびデータフォーマットを通じてウェブサービスにアクセスすることができる。

[0046]リプリゼンテーショナルステートトランスファ（ＲＥＳＴ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）プロトコルは名前付きのリソースにアクセスするときに有用であり、本発明の一定の実施形態で使用されてもよい。本発明の他の実施形態では、ＳＯＡＰが利用されてもよい。いくつかのケースでは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．のＦＳＳＨＴＴＰ（Ｆｉｌｅ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｅｒｖｉｃｅ ｖｉａ ＳＯＡＰ ｏｖｅｒ ＨＴＴＰ）が使用されてもよい。

[0047]コンテンツアクセスサービス１００は、１つまたは複数の物理サーバおよび／または仮想サーバを使用してネットワーク上に実装されてもよい。ネットワークには、セルラーネットワーク（例えば無線電話）、ポイントツーポイントのダイアルアップ接続、衛星ネットワーク、インターネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、ＷｉＦｉネットワーク、アドホックネットワーク、またはそれらの組み合わせを含むことができるが、それらに限定されない。そのようなネットワークは、ハブ、ブリッジ、ルータ、スイッチ、サーバ、およびゲートウェイなどの様々なタイプのネットワーク要素を接続するために広く使用されている。ネットワークは、インターネットなどの公共ネットワークおよび／または安全なエンタープライズプライベートネットワークなどのプライベートネットワークを含む、接続された１つまたは複数のネットワーク（例えばマルチネットワーク環境）を含んでもよい。当業者には理解されるように、ネットワークへのアクセスは、１つまたは複数の有線または無線アクセスネットワークを介して提供されてもよい。

[0048]コンテンツアクセスサービス１００は、インポート／変換部１０２および、レンダリング／変換部１０４を含んでもよい。様々なソース１０６からの文書をコンテンツアクセスサービス１００にインポートすることができる。インポート／変換部１０２は、コンテンツを読者から要求される特定のフォーマットにするという制限を抑える、または撤廃することによって、個人出版を促進することができる。例えば、特定のファイルフォーマットでの作業を制作者に要求せずに、書店または他の販売所もしくは商店への個人出版が可能になる。制作者が作品を簡単に出版できるようになれば、リーダーのユーザは多くのコンテンツにアクセスできるようになる。

[0049]「リーダー」とは、主に電子書籍（ｅｂｏｏｋｓ）および／またはその他の電子コンテンツを読むことを目的として設計されたソフトウェアアプリケーションおよび／または電子デバイスを指す。リーダーには、多くの場合、注釈、強調、ブックマーク、および書込みなどの、少なくとも何らかの編集機能が含まれる。

[0050]ソフトウェア電子書籍リーダーの例には、Ｇｏｏｇｌｅ ＩｎｃのＧＯＯＧＬＥ ＲＥＡＤＥＲアプリケーション、Ａｐｐｌｅ Ｉｎｃ．のＡＰＰＬＥ ＩＢＯＯＫＳアプリケーション、Ａｄｏｂｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．のＡＤＯＢＥ ＡＣＲＯＢＡＴ ＥＢＯＯＫ ＲＥＡＤＥＲアプリケーション、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．のＭＩＣＲＯＳＯＦＴ ＲＥＡＤＥＲアプリケーションがある。ハードウェア電子書籍リーダーの例には、Ａｍａｚｏｎ．ｃｏｍ Ｉｎｃ．のＡＭＡＺＯＮ ＫＩＮＤＬＥブランドの電子書籍リーダー、Ｂａｒｎｅｓ ＆ Ｎｏｂｌｅ Ｉｎｃ．から入手可能なＢＡＲＮＥＳ ＡＮＤ ＮＯＢＬＥ ＮＯＯＫブランドの電子書籍リーダータブレットがある。電子書籍とは、電子書籍リーダーで読むことができるデジタル形式のテキストおよび／または画像ベースの出版物である。コンテンツを作成および出版するために使用される、電子書籍およびその他のデジタルコンテンツには、電子出版（ｅＰｕｂ）、ＨＴＭＬ、ＰＤＦ、プリンタコマンド言語（ＰＣＬ）、拡張マークアップ言語（ＸＭＬ）などの様々なフォーマットがある。

[0051]いくつかのケースでは、インポートされた文書（例えば、インポート／変換部１０２を通じて）が、クラウド（１０８）の一部として保管されるか、または（アドレスまたはＵＲＩ（ユニフォームリソース識別子）を保管することによって）保管されているように見えてもよい。コンテンツアクセスサービス１００は、ストレージ１０８上での動作を決定してもよいし、または別のストレージ（このストレージはストレージ１０８を直接または間接的にアクセスしてもよい）に動作を委託してもよい。

[0052]文書ファイルはコンテンツアクセスサービス１００からエクスポートされてもよい。インポートされた文書の１つなどの文書は、エクスポートされる前に、リーダー１１０、プリンタ１１２、第３者サイト１１４、および２次変換サービス１１６などのエンドポイントでの消費（例えば表示のためのレンダリング、対話、修正、または、印刷およびさらなる変換を含む追加処置など）のために変換されることができる。

[0053]エンドポイントとは、顧客がサービスにアクセスする手段、すなわち対話の入り口を指す。様々な実施形態によれば、エンドポイントのカスタム化が提供され、それによって適用範囲が拡大され、コンテンツの消費方法がデバイスに基づいて変更される。

[0054]エンドポイントは１つまたは複数の消費者デバイスであることができる。
[0055]消費者デバイスとは、サービスまたはソースから取り込みまたは購買されたデータまたは文書を消費（すなわち、表示／読書、編集、または注釈付けに使用する）ために使用されるコンピューティングデバイスを指す。消費者デバイスは、主として電子書籍を読むために使用される単一目的のコンピューティングデバイス（多くの場合、リーダーと呼ばれる）でもよいし、または電子書籍またはその他の電子／デジタルコンテンツを読むためのリーダーまたはビューアソフトウェアを備える複数目的のコンピューティングデバイスでもよい。

[0056]「ビューア」とは、特定のプログラムに関連するフォーマットまたはファイルタイプで文書またはデータを表示する、または表示するように見えるソフトウェアアプリケーションまたはハードウェアアプリケーションを指す。特定のファイルフォーマット用のビューアは、その特定のファイルフォーマットを理解し、そのファイルの視覚表現を提示することができる。通常、あるファイルフォーマットの「ビューア」は、著者の元の意図を維持しながら、そのファイルフォーマットを高い忠実度で視覚的に提示できると仮定される。「リーダー」は、ページめくりのアニメーションの提供、最後に読んでいた位置の記憶、単語を調べる辞書の提供など「読む」体験に主に関連する機能を含むビューアのタイプである。

[0057]サービスは文書の適用範囲を（様々なプラットフォームにわたるデバイスにまで）広げ、文書のためにクライアントデバイスに適した体験を作成する。文書は各クライアントで全く同じに見える必要はなく、ユーザの体験に合わせて、またデバイスに適合するように文書をカスタマイズすることができる。

[0058]第３者が文書を使用して、追加のユーザ体験を作成することができる。
[0059]システムはデバイスを知ることによって、カスタム化されたファイルフォーマットを（例えばサービス１００を通して）提供することができる。シナリオ例として、ＮＯＯＫリーダーまたはＫＩＮＤＬＥリーダーのユーザが、そのデバイスを使用して、読書に利用可能なコンテンツを検索してもよい。サービス１００は、どのデバイスが使用されているかを判断し、コンテンツの提示をデバイスに合わせて適切に調節する。例えば、ＮＯＯＫリーダーにはｅＰｕｂ２またはｅＰｕｂ３のフォーマットが送られ、ＫＩＮＤＬＥリーダーにはＡＺＷフォーマットが送られてもよい。

[0060]カスタム化されたファイルがデバイスに送られた後に、（サービス１００を通して）ファイルをサーバに戻して保存することができる。例えば、クライアントにサービスされたファイルに特定の処置（ＮＯＯＫリーダー、ＫＩＮＤＬＥリーダー、またはエディタアプリケーションを実行するタブレット内での、注釈付けまたは編集などの修正処置）を行い、これらの修正をそのファイルのマスター文書に統合することができる。

[0061]本発明の一定の実施形態では、変更されたブロックを個別にアクセスするために、マスター文書に統合せず、別々のアドレスに割り当てることができる。
[0062]さらなる実施形態では、（例えば、ユーザがデバイスからアカウントにログインしたときなどに識別子を受信することによって）ユーザについても知ることによって、システムは（例えばサービス１００を通して）ユーザが自分のデバイスで処理できるファイルフォーマットを気にすることなく、ネットワーク内の多くのデバイス上の自分のファイルにアクセスできるようにすることができる。システムはユーザを知ることによって、ユーザが自分のファイルにアクセスできるようにすることに加えて、そのユーザに関連する仕事に関する文書内の特定のコンテンツを提示するようにファイルをカスタマイズすることができる。例えば、ユーザがある段落を読む仕事を課せられている場合、その文書にアクセスできるすべてのユーザではなく、その特定されたユーザにその段落が提供されてもよい。一実施形態では、このことは、その特定のユーザにその段落ブロックへのリンクまたはアドレスを提供することによって達成可能である。

[0063]エンドポイントとサービス１００との通信は、２種類に大別される。１つは双方向のリッチな体験で、もう１つは制限付きの体験である。どちらの場合でも、本発明の実施形態を使用すれば、エンドポイントにはファイルフォーマット変換の処理、すべてのファイルフォーマットをレンダリングする能力、または、コンテンツの共同執筆のためのレイヤを含むことは必要ない。

[0064]多様なリッチさのエンドポイントが本発明の様々な実施形態によってサポートされる。本明細書で使用するとき、「リッチさ」とは、あるアプリケーションで利用可能な体験の範囲および、そのアプリケーションが特定のコンテンツおよび機能をユーザに提示する能力を指す。例えば、最もリッチな消費体験は、コンテンツの編集および操作が利用可能なフル機能のアプリケーションをサポートするデバイス（例えば、エンドポイントエディタ１１８）を通して利用可能であり得る。制限付きの体験には、コンテンツの編集および操作のいくつかの機能を残したバイトサイズのオーサリングツール（例えば、制限付きエンドポイントエディタ１２０）が含まれる。制限付きの体験（または「軽い編集」）とフル機能エディタ（または「重い編集」）との違いは、軽い編集では注釈およびコメントのみがサポートされる場合があることである。

[0065]コンテンツを表示できるリーダー（例えば、消費者デバイス１２２）は、ある範囲のリッチさをサポートすることができる。すべてのエディタタイプおよびフィーチャバージョンのサポートが可能である。

[0066]アクセスサービス１００によって提供される変換および統合サービスは、クライアントデバイスまたは別のサーバ（例えば、リーダー１１０もしくは消費デバイス１２２、エンドポイントエディタ１１８、または消費および制限付きエンドポイントエディタ１２０）によって直接要求されてもよい。いくつかの実施形態では、サーバ（図２に関して説明されるように）または第３者サイト（例えば１１４）または２次変換サービス（例えば１１６）が、クライアントデバイスに代わってサービス１００にアクセスしてもよい。プリンタ１１２もまた、直接または別のクライアントデバイスを通して、変換および統合サービス１００からコンテンツを受け取ってもよい。

[0067]エンドポイントエディタ１１８がウェブサービス（例えばサービス１００）と通信してもよい１つのフレームワークは、クライアントアプリケーションが、文書に対する変更とサーバ上で実行するＭＩＣＲＯＳＯＦＴ ＳＨＡＲＥＰＯＩＮＴウェブアプリケーションなどのファイル管理および共同作業のプログラムとを、ＦＳＳＨＴＴＰアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して効率的に同期させることが可能になるフレームワークを介することである。ＦＳＳＨＴＴＰプロトコルのクライアント側はパススルーである。例えば、アプリケーション層などの上位層のプロトコルが行った呼び出しは、直接トランスポート層に引き渡され、トランスポート層から返される結果は上位層のプロトコルまたはアプリケーションに直接戻される。

[0068]ＡＰＩは一般に、２つ以上のアプリケーションが互いに通信できるようにするためのプログラミング命令および標準のセットであり、通例、ＨＴＴＰ要求メッセージのセットおよび応答メッセージに指定されるフォーマットまたは構造として実装される。メッセージは、情報リソースを含むことができる。リソースとは、ユニフォームリソース識別子（ＵＲＩ）によって特定できる情報であり、ファイル、動的に生成されるクエリ結果、共通ゲートウェイインタフェース（ＣＧＩ）スクリプト、いくつかの言語で利用可能な文書などであってもよい。

[0069]いくつかの実施形態によれば、あるリソースにアクセスするアドレスを作成するためのＡＰＩが提供される。そのリソースにアクセスする目的で、その作成されたアドレスに存在するコンテンツを要求するためのＡＰＩをさらに提供することができる。コンテンツの要求に、コンテンツに特定のフォーマットを求める要求を含めることができる。そのアドレスにコンテンツを戻す（または「プッシュする」）ためのＡＰＩをさらに提供することができる。プッシュには、統合または上書きが含まれてもよい。

[0070]変換および統合サービス１００は、さらに広範なクラウドサービス１３０ならびにウェブアプリケーションコンポーネント（ＷＡＣ）１３２に関連してもよい。ＷＡＣは、ユーザがブラウザ内で文書を閲覧および編集できるようにするコンポーネントである。ＷＡＣは、コンテンツを消費および編集することによってエンドポイントとしても、いくつかの統合および変換サービス機能を提供することによってサービスとしても機能することができる。そのような実施形態では、ユーザは、インフラストラクチャおよびプラットフォームを管理するクラウド上のアプリケーションソフトウェアおよびデータベースにアクセスすることができる。エンドユーザは、ブラウザまたはアプリ（スマートフォンおよびタブレットなどのモバイルデバイスのために設計されたアプリケーション）を通して、クラウドでホストされているソフトウェアアプリケーションにアクセスする。一例を図２に関して説明する。

[0071]図２は、本発明の一実施形態によるエンドポイントの動作環境を示す。図２を参照すると、クライアント２１０およびサーバ２２０がネットワーク２３０を介して通信している。

[0072]ネットワーク２３０は、相互接続ネットワーク（ｉｎｔｅｒｎｅｔ）、イントラネット、またはエクストラネットでもよく、任意の適切な通信ネットワークであることができ、通信ネットワークは、セルラー（例えば無線電話）ネットワーク、インターネット（Ｉｎｔｅｒｎｅｔ）、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、ＷｉＦｉネットワーク、アドホックネットワークまたはそれらの組み合わせを含むが、これらに限定されない。

[0073]前述したように、そのようなネットワークには、ハブ、ブリッジ、ルータ、スイッチ、サーバ、およびゲートウェイなどのネットワーク要素の接続を含んでもよい。ネットワーク２３０は、インターネットなどの公共ネットワークおよび／または安全なエンタープライズプライベートネットワークなどのプライベートネットワークを含む、接続された１つまたは複数のネットワーク（例えばマルチネットワーク環境）を含んでもよい。当業者には理解されるように、ネットワーク２３０へのアクセスは、１つまたは複数の有線または無線アクセスネットワーク（図示せず）を介して提供されてもよい。

[0074]クライアント２１０およびサーバ２２０は、１つまたは複数の処理ユニット（ＣＰＵ）、メモリ、大容量ストレージ、およびＩ／Ｏデバイス（例えば、ネットワークインタフェース、ユーザ入力デバイス）で構成されるコンピューティングシステムを含むことができる。コンピューティングシステムの要素は、バスを介して互いに通信することができる。コンピューティングシステムのハードウェアプラットフォームは多くの形に組み込まれることができ、それらの形には、パーソナルコンピュータ、サーバコンピュータ、手持ち式またはラップトップのデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な家電製品、および、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境（例えば、クラウドベースのコンピューティングシステム）（および、アプリケーション機能、メモリ、データストレージならびに、読み取りおよび様々な処理機能が、インターネットまたはイントラネットなどの分散コンピューティングネットワーク上で相互から遠隔で運用されてもよい環境）が含まれるが、それらに限定されない。

[0075]一定の実施形態では、クライアント２１０はコンピューティングデバイスとして具体化されることができ、コンピュータデバイスには、パーソナルコンピュータ、タブレット、リーダー、モバイルデバイス、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ（またはノートブックまたはネットブック）コンピュータ、ゲームデバイスまたはコンソール、デスクトップコンピュータ、もしくはスマートテレビジョンが含まれるが、これらに限定されない。

[0076]一定の実施形態では、サーバ２２０はコンピューティングデバイスとして具体化されることができ、コンピューティングデバイスには、サーバコンピュータ、エンタープライズコンピュータ、パーソナルコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、およびそれらの組み合わせが含まれるが、これらに限定されない。クライアントコンピューティングデバイスおよびサーバコンピューティングデバイスのリストは制限を目的とせず、クライアントおよびサーバは同じ形または異なる形に具体化されてもよいことを理解されたい。

[0077]クライアントコンピューティングデバイス２１０は、オペレーティングシステム２１１および１つまたは複数のアプリケーションプログラムを実行するように構成され、アプリケーションプログラムは、図示される実施形態では、ワードプロセッサまたはエディタアプリケーション２１２、ウェブブラウザアプリケーション２１３、および／または１つまたは複数のその他のアプリケーションなどである。

[0078]オペレーティングシステム２１１は、クライアントコンピューティングデバイス２１０の動作を制御するためのコンピュータプログラムである。アプリケーションプログラムは、オペレーティングシステム２１１の上で動作し、本明細書に記載されるような様々な機能を提供するように構成された実行可能なプログラムである。ワードプロセッサアプリケーションは一般に、タイプ入力、編集、書式設定、保存、印刷、およびコメント付けを容易にするように構成されたアプリケーションである。エディタアプリケーションは、編集および注釈のツールを提供する任意のアプリケーションでもよく、ワードプロセッサアプリケーションまたは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．のＭＩＣＲＯＳＯＦＴ ＯＦＦＩＣＥ、Ｇｏｏｇｌｅ Ｉｎｃ．のＧＯＯＧＬＥ ＤＯＣＳ 、Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ ＦｏｕｎｄａｔｉｏｎのＡＰＡＣＨＥ ＯＰＥＮＯＦＦＩＣＥまたは、Ｚｏｈｏ ＣｏｒｐｏｒａｔｉｏｎのＺＯＨＯ ＯＦＦＩＣＥなどの他の生産性アプリケーションであってもよい。

[0079]生産性アプリケーションには、ワードプロセッサプログラム、共同作業プログラム、プレゼンテーションプログラム、スプレッドシートプログラム、および朗読／ノート記録プログラムなどが含まれるが、これらに限定されない。

[0080]ウェブブラウザアプリケーション２１３は、ワールドワイドウェブ（「ウェブ」）上の情報リソース、ならびにプライベートネットワーク内のウェブサーバによってネットワーク２３０を介して提供される情報リソースを取り込み、または検討して、その情報リソースをユーザに提示する（例えば、表示用にレンダリングする）ためのアプリケーションプラグラムである。さらに、ウェブブラウザアプリケーション２１３によって、サーバによって提供される情報および様々な機能へのユーザのアクセスが可能になる。

[0081]図示されるサーバコンピュータ２２０は、サーバのオペレーティングシステム２２１、サーバのワードプロセッサまたはエディタアプリケーション２２２などの１つまたは複数のアプリケーションプログラム、および／または１つまたは複数のその他のアプリケーションを実行するように構成される。サーバ２２０は、また、サービスをホスティングしてもよい（さらに、図１に示されるようにＷＡＣ１３２を組み込んでもよい）。

[0082]サーバのオペレーティングシステム２２１は、サーバコンピュータの動作を制御するためのコンピュータプログラムであり、アプリケーションプログラムは、サーバのオペレーティングシステム２２１の上で実行して、本明細書に記載される様々な機能を提供するように構成された実行可能なプログラムである。サーバのワードプロセッサまたはエディタアプリケーション２２２は、いくつかの実施形態では、上記のワードプロセッサまたはエディタアプリケーション２１２と類似して構成されるウェブベースのアプリケーションプログラムである。サーバのワードプロセッサまたはエディタアプリケーション２２２は、ワードプロセッサまたはエディタアプリケーション２１２と同一の機能を提供してもよい。

[0083]いくつかの実施形態では、サーバコンピュータ２２０はサーバのワードプロセッサまたはエディタアプリケーション２２２を実行するように構成され、クライアントコンピューティングデバイス２１０は、クライアント／サーバ構成内でサーバのワードプロセッサまたはエディタアプリケーション２２２と対話するためにサーバコンピュータ２２０をアクセスするように構成される。

[0084]クライアント−サーバ関係におけるコンピューティングデバイス相互の通信は、特定のリソースまたは実施予定の特定作業へのアクセスを求める要求を送信するクライアントによって開始されてもよい。続いてサーバが要求された処置を行い、クライアントに応答を返してもよい。

[0085]一実施形態では、ウェブベースのワードプロセッサまたはエディタアプリケーション１２２にアクセスするために、クライアントのウェブブラウザアプリケーション２１３を使用してサーバ、例えばサーバ２２０への接続が行われてもよい。

[0086]クライアント２１０およびサーバ２２０は、ネットワーク２３０を介して変換および統合サービス２４０にアクセスすることができる。クライアント２１０およびサーバ２２０上で実行するアプリケーションは、ＨＴＴＰ、ＸＭＬ、ＪＳＯＮおよびＳＯＡＰなどの普遍的なウェブプロトコルおよびデータフォーマットを介して、またはＦＳＳＨＴＴＰプロトコルを介してサービス２４０にアクセスすることができる。

[0087]図３は、本発明の一実施形態によるコンピューティング環境を示す。図３に示されるように、ユーザ３００のコンピューティング環境は、複数のクライアント３１０（デスクトップ３１１、ラップトップ３１２、スマートフォン３１３、タブレット３１４、リーダー（図示せず）、ゲームコンソール（図示せず）など）、およびネットワーク３３０を通して接続されたサーバ３２０を含むことができる。

[0088]図２のネットワーク２３０に関して説明したように、ネットワーク３３０は、相互接続ネットワーク（ｉｎｔｅｒｎｅｔ）、イントラネット、またはエクストラネットでもよく、任意の適切な通信ネットワークであることができ、通信ネットワークは、セルラー（例えば無線電話）ネットワーク、インターネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、ＷｉＦｉネットワーク、アドホックネットワークまたはそれらの組み合わせを含むが、これらに限定されない。

[0089]クライアント３１０およびサーバ３２０は、クライアント２２０およびサーバ２３０に関して説明したように構成されるコンピューティングシステムを伴うことができる。

[0090]各クライアント３１０は、サーバ３２０によってコンテンツアクセスサービスを通して提供される文書（およびそのコンテンツ）３４０を閲覧および編集（および／または注釈付け）するためのソフトウェアアプリケーションを含むことができる。

[0091]ユーザ３００は、複数のクライアント３１０（例えば、事務所内のデスクトップコンピュータ、家庭内のラップトップ３１２、および携帯電話／スマートフォン３１３）を有することができ、それらのクライアント３１０上で実行するソフトウェア電子書籍リーダーもしくは文書ビューアまたはエディタを使用して、サーバ３２０から取り込んだ電子書籍またはその他のデジタルコンテンツを読んでもよいし、ならびにそのコンテンツを編集および／または注釈付けしてもよい。

[0092]サーバ３２０は、変換サービスおよび統合サービスを（コンテンツアクセスサービスの一部として）提供するように構成されたハードウェアデバイスおよび／またはソフトウェアプログラムである。変換サービスによって、ユーザがコンテンツにアクセスするために使用する特定のクライアント３１０によって直接にはサポートされていないファイルフォーマットのコンテンツ（そのユーザが所有するコンテンツであっても）にユーザがアクセスできるようになる。統合サービスは、ユーザ３００が加えた変更を、データベース３５０に保管されているマスター文書に再統合する。

[0093]サーバ３２０によって提供されるサービス（または機能）のうち１つまたは複数を、クラウドコンピューティング環境内で実行することができる。さらに、サーバ３２０は、ＡＰＩを通して開示されるアプリケーションを含むことができる（かつ／またはＡＰＩを通して開示されるサービスをホスティングすることができる）。

[0094]一定の実施形態によれば、サーバ３２０を包含するシステムは、クライアント３１０またはデータベース（データベース３５０など）から文書をインポートできるように提供されてもよい。インポートされた文書はマスター文書３４５と考えられてもよいし、インポートされた文書からマスター文書３４５が作成されて、例えば、サーバ３２０に関連するデータベース３５０に保管されてもよい。

[0095]一実施形態では、文書を「インポート」するときは、その文書にユニフォームリソースロケータ（ＵＲＬ）を作成してもよい。次に、クライアント（または消費者デバイス）が（作成されたアドレスにある）文書を要求したときに、その文書を取り込んで消費者デバイスに提供することができる。一定の実施形態によれば、アドレスの作成は、文書の全体または一部に対して行うことができる。さらなる実施形態では、アドレスの作成は、ＡＰＩを通して開示されてもよい。

[0096]サーバ３２０は、文書３４５を消費者デバイス（例えば、デスクトップ３１１、ラップトップ３１２、スマートフォン３１２、タブレット３１４、リーダー（図示せず）、ゲームコンソール（図示せず）など）に適したフォーマットに変換することができる。

[0097]ユーザ３００は、各デバイス（例えば、３１１、３１２、３１３、３１４）のすべてにわたって、マスター文書３４５の適切なバージョン（例えば、文書３４０の形）にアクセスすることができる。例えば、どのデバイスまたはプラットフォームでも文書３４０を表示することができる。例えば、ラップトップ３１２上で、１つのプログラム内で文書３４０の作業をしているユーザ３００は、変更内容と共に文書を保存することができる。文書を保存することによって、統合サービスを呼び出すことができる。例えば、図５Ｂ〜５Ｄに示されるように、文書全体（図５Ｂ）、変更部分（デルタΔ）（図５Ｃ）、または特定の修正部分（図５Ｄ）をサーバに戻して、マスター文書と統合することができる。

[0098]実際の物理ファイルは、クラウドに（データベース３５０などのクラウドの一部として）保管されてもよいし、またはクラウドに保管されなくてもよい。ファイルは、サーバもしくはコンピュータ、またはネットワークを通してサービスからアクセスできる任意のストレージに保管されてもよい。マスター文書（またはその他のインポートされたファイル）は、アドレス指定可能なファイルの集合としてサーバ３２０に保管することができ、要求されたときにインポートおよび変換してもよい。図１１に関して説明されるように、文書内のコンテンツのサブセットに対してアドレスを作成してもよく、それぞれのアドレスを使用して新しい「マスター文書」を取得し、要求されたときにそれらの新しいマスター文書を組み合わせてもよいし、または別々にインポートおよび／または変換してもよい（図９も参照）。

[0099]クライアントデバイス（ラップトップ３１６）上の別のユーザ３６０、または、タブレット３１４などの第２のデバイス上の第１のユーザ３００は文書３４０を開くことができ、彼らの体験は、文書３４０が、デバイス３１６（または第１のユーザ３００が文書にアクセスしている第２のデバイス）内で作業可能な文書であるということである。次に、デバイス３１６を使用する第２のユーザ３６０（または第２のデバイス上の第１のユーザ３００）は、編集後に文書を保存することができ、サービスによって変更が統合される。

[0100]複数の実施形態によれば、各クライアント３１０には、そのクライアントに適したフォーマットでファイルが保管されているように見える。ファイルを開いてデータにアクセスするために、クライアントでファイルを変更する必要はない。例えば、クライアントが適切なファイル形式を受け取るかどうかについてはサーバが対処するので、アプリケーションは予定したとおりに文書を開くことができる。クライアント３１０で、ユーザ（３００、３６０）は、予定したとおりの工程に従って文書を保存する。サーバは、エンドポイントの制限を理解して、デバイスに適した書式を提供する。

[0101]サーバ３２０と消費者／クライアントデバイス３１０との通信は、クライアント３１０で利用可能なデバイスまたはソフトウェアのタイプをサーバが知り、それに従ってユーザの体験を適合させるように行われる。

[0102]サーバ３２０は、エンドポイントでのユーザエージェント／クライアントの特性を特定できるように構成されることができる。特定は、エンドポイント（例えば、クライアント３１０）からサーバ３２０に送られる能動的または暗示的な通知に基づいてもよい。サーバ３２０は、クライアントの体験ならびに存続する体験（例えば、保管されている、マスター文書のコピー）を適合させるようにさらに構成されることができる。

[0103]一定の実施形態によれば、サービスされる文書３４０は、小さい（大きい）ディスプレイサイズに合わせてリフローされるだけでなく、追加の調整も可能である。
[0104]リフローとは、限られたディスプレイまたはウィンドウに合わせてコンテンツの表示を調整することを指し、ここで、テキストは読みやすさのために元のサイズのままで残り、画像は縮小されて、両方を一目で見られるようになってもよい。

[0105]追加の調整の例として、高解像度のデバイスは高解像度のコンテンツのサービスを受けることができ（フォームファクタが高いほど多くのオブジェクトを受け取ることができる）、電話は（例えば、文書内の１２メガピクセル版の画像の代わりに）低解像度の画像を受け取ってもよい。さらに、タッチ入力可能なデバイスには、文書にタッチ反応性のフィーチャが追加されてもよい。さらに適合されたエンドポイントサービスも提供されてよく（例えば、ＡＰＩを通して開示される）、これには、文書へのコメント付けおよび、ワークフロー要素（するべき仕事の項目など）の追加を可能にするサービスを含むが、これらに限定されない。セキュリティ設定および権利管理がクライアントに適合されてもよい。例えば、古いバージョンまたは一定のファイルフォーマットがクライアントにサービスされたとき、低い忠実度での保存による害を最小限に抑えるために、読み取り専用として機能するように文書が提供されるが、マスターとは別のコピーとして文書が保存されるようにすることができる。

[0106]いくつかの実施形態では、クライアントは、アドレス作成ＡＰＩを使用してアドレスを要求することによって、低い忠実度（または、異なるフォーマットまたは将来のバージョン）を保存することができる。

[0107]サービスされる文書３４０が特定の消費者デバイスによってレンダリングされるために適した（カスタマイズされることもある）フォーマットであるだけでなく、文書３４０の修正内容がマスター文書３４５に再統合されることもできる。サーバ３２０は、どのタイプのデバイスおよび／またはソフトウェアがクライアントで利用可能かを知ることによって修正内容を再統合することができる。例えば、クライアントデバイスが異なるプラットフォーム（およびファイルフォーマット）を使用している場合は、サーバ３２０は、変換時に失われることのある忠実度を知り、変更があればサーバ上で復元することができる。

[0108]同様に、クライアントデバイスが異なるバージョンのフィーチャを使用している場合は、サーバ３４０は使用されているバージョンを知り、それに合わせて調節を行うことができる。フィーチャには、テキスト、チャート、数式、テキスト効果およびグラフィックス（ＭＩＣＲＯＳＯＦＴ ＳＭＡＲＴＡＲＴグラフィックスを含む）、デジタルコンテンツ（動画を含む）、目録スタイル、スレッド化されたコメント機能、スペルチェック、辞書、言語の操作および編集のユーティリティ、ならびにグラフィックスの操作および編集のユーティリティが含まれるが、これらに限定されない。

[0109]サービスは下位および上位の互換性を提供することができる。
[0110]例えば、最新バージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤを、以前のバージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤを実行しているクライアントにサービスすることができ、クライアントは以前のバージョンへの変換を行う必要はない。さらに、読み取り専用バージョンがサービスされる（忠実度の低いバージョンで保存して戻される問題を避けるため）のではなく、以前のバージョンを実行しているクライアントがその文書を編集してもよい。その理由は、以前のバージョンがフル忠実度のバージョンにどのように害を及ぼすか（および、忠実度の高いコンテンツに置き換わった画像がどのように見えるか）をサーバが知っているので、サーバ上でデータを復元することができる（すなわち、忠実度の補正を行う）からである。

[0111]忠実度の補正をサーバで行うことができる理由は、コンテンツがどんな形で提供されたか、ならびに、ファイルが特定のファイルフォーマットである間にファイルに関して行われ得る特定の制約および処置をサーバが知っているからである。

[0112]図４は、本発明の一実施形態による変換および統合サービスの処理フローの例である。図４を参照すると、操作（４０２）で、サーバが統合要求を受け取るとき、要求および文書が提供されてもよい。サーバは、文書が新規文書であるのかまたはシステムに既に存在するのかを判断することができる（４０４）。文書が新規文書（または新規コピー）である場合は、システムは、その文書からマスターを作成することができる（４０６）。マスターはその文書であることもできるし（同じファイルフォーマットおよびフィーチャバージョンを使用する）、またはその文書を特定のファイルフォーマットおよびフィーチャバージョンに変換することによってマスター文書を作成することもできる。

[0113]マスター文書を作成することによって、一定の実施形態では、サービスとしての文書の体験をユーザのために作成することができる。具体的には、マスター文書は、そのマスター文書を構成するコンテンツと共に、制作者および他の人がその文書に関して行ってもよい処置のセットを含む。カスタム化された体験を顧客に提供することができ、コンテンツを編集する能力をサービスの一部として開示することができる。

[0114]一実装では、マスター文書の作成には、アドレスの作成が伴う（これには、グローバル一意識別子（ＧＵＩＤ）の作成を伴ってもよい）。このサービスによるアドレスの作成は、他のサービスまたはアプリケーションが、このサービスにアドレスを作成させるように拡張可能であることができる。

[0115]操作（４０４）に戻ると、文書が新しい文書ではないと判断された場合（例えば、既にシステム上にマスター文書が存在するから）は、サーバは、文書のファイルフォーマットがマスター文書と同じか異なるかを判断することができる（４０８）。ファイルフォーマットが異なると判断された場合は、それに応答して、サーバは文書のファイルフォーマットを、マスター文書のファイルフォーマットまたは、システムに理解される他の何らかのフォーマットに変換してから（４１０）、その文書とマスター文書との間の差異を自動的に判断し（４１２）、差異（デルタ）を統合してマスターを改訂することができる（４１４）。デルタをマスター文書に統合することによって、あるデバイス上のユーザがある文書に何かを行い、その文書に次にアクセスする人（または第２のデバイス上の同一人物）が、それらの変更が反映されている文書を受け取ることができるように、その文書に関連する変更を行うことが可能になる。

[0116]操作（４０８）に戻ると、ファイルフォーマットが同じである場合は、その文書でサポートされているフィーチャバージョンがマスターでサポートされているフィーチャバージョンと同じか判断を行うことができる（４１６）。フィーチャバージョンが異なると判断された場合は、それに応答して、サーバはその文書とマスターとの間の、フィーチャに関連しない差異（デルタ）を判断し（４１８）、判断されたデルタを使用して、忠実度を失うことなくマスターを改訂することができる（４２０）。

[0117]ある文書を別の文書に変換するため、またはコンテンツをあるバージョンから別のバージョンに変換するために、ファイルフォーマットおよび／またはフィーチャバージョンを判断することによって、ファイル全体およびファイル内のコンテンツを分析することができる。その文書とマスターとの間に、ファイルフォーマットおよびフィーチャバージョンの違いがない場合は、マスターで差異を自動的に改訂する（４２２）か、または、マスターをその文書に置き換えることができる。

[0118]図５Ａ〜図５Ｄは、変換および統合サービスのシナリオ例を示す。図５Ａを参照すると、変換サービス５０５がデータベース５１０からの文書にアクセスし、その文書を、サポート対象のファイルフォーマットで、例えば文書５２０として表示されるようにクライアントにサービスする。表示される文書５２０の実際のファイルフォーマット（データベース５１０に保存されている形）には、ＰＤＦ、ＤＯＣ、ＤＯＣＸ、およびｅＰｕｂが含まれるが、これらに限定されない。しかし、変換サービス５０５は、クライアントによってサポートされるフォーマット、さらにはそのエンドポイントのためにカスタマイズされたフォーマットでコンテンツを提供することができる。

[0119]データベースからの文書にアクセスするために、サービスは文書のリソース識別子を受け取り、そのアドレス位置にある文書を取り出すか、または要求する。
[0120]複数の実施形態で提供するシステムでは、文書が、実際には特定のクライアントに必要なフォーマットまたはバージョンで存在していない場合でも、ユーザがその文書を閲覧（または編集）するために選択する時点まで、そのフォーマットであるかのようにユーザに提示される。サーバに保存されているすべてのファイルがファイルフォーマットのすべてのタイプにあらかじめ変換されているのではなく、ユーザから要求があったときに、文書の特定のフォーマットが送られる。

[0121]複数の実施形態では、コンテンツが消費され得る範囲を拡張し、そのコンテンツが提供されるデバイス（またはクライアント）に適した体験をそのコンテンツのために作成することができる。サービスは、デバイスおよび能力を解釈して、その特定のデバイス上でそのコンテンツを閲覧するための望ましい、または適切な方法は何かを判断することができる。サービスが考慮することのできるフィーチャには、ディスプレイの寸法、デバイスのユーザ入力能力、ネットワーク接続の速度および／または帯域幅、ならびに、オペレーティングシステムおよびアプリケーションの制約が含まれるが、これらに限定されない。

[0122]例えば、ある文書はラップトップで表示すると素晴らしいが、電話またはタブレットなどの小さい画面ではあまり便利ではないことがある。クライアントが何であるかを判断することによって（そのクライアントに適する消費フォーマットを判断するなど）、サービスはデバイス（またはソフトウェア）に基づく消費体験を修正する。

[0123]クライアントで、サービス５１０によって提供された文書５２０が編集されてもよい。現在の例では、編集された文書５２５がマスター文書に戻して統合され、異なるエディタおよびフィーチャバージョンにわたる共同作業が容易になり得る。統合サービスを提供するために、共同作業および統合のサービスのための総合的なＡＰＩまたは複数のＡＰＩを使用することができる。ＡＰＩによって、複数のプラットフォームにわたって、クライアントが変更内容を統合することが可能になる。さらに、例えば、所有権付きのフォーマットまたは新しいフォーマットが配備された場合など、認識可能なファイルフォーマットへの中間変換が行われることのある状況で、サービスは第３者のアダプタに拡張可能であることができる。

[0124]図５Ｂ〜図５Ｄは、編集された文書５２５をマスター文書に戻して統合する、様々なシナリオを示す。
[0125]図５Ｂは、修正のある文書５３０全体が統合サービス５４０に提供されるケースを示す。図５Ｂを参照すると、総合ＡＰＩを使用することができる。一実施形態では、クライアントが文書全体を変更と共に（文書５３０として）サーバ（例えば、サービス５４０）に送ることができる。サービス５３０は文書５３０を解釈して、差異を判断してから、自動的に統合する。統合は、編集された文書がマスター文書とは異なるフォーマットであっても行われる。文書５３０を、統合を容易にするためにサービス５４０によって特定のフォーマットに変換することができる。

[0126]図５Ｃは、文書５２０と編集された文書５２５との間の差異（デルタΔ５５０）が（総合ＡＰＩを介して）統合サービス５６０に提供されるケースを示す。サービス５６０はデルタ５５０を解釈して、自動的に統合を行う。統合は、編集された文書がマスター文書とは異なるフォーマットであっても行われる。

[0127]図５Ｄは、複数のＡＰＩが使用されるケースを示す。ＡＰＩを、コンテンツ統合の軽量な選択肢の一部としてバンドルすることができる。ＡＰＩは個別の修正機能であることができ、強調表示ＡＰＩ、フォントＡＰＩ、段落ＡＰＩ、スタイルＡＰＩ、翻訳ＡＰＩ、数式ＡＰＩ、表の作成／修正のＡＰＩ、画面の挿入／作成／編集のＡＰＩ、色のＡＰＩ、またはコメントＡＰＩなどを含んでもよいが、これらに限定されない。ＡＰＩのうち１つまたは複数が特定のクライアントに対して利用可能であってよい。

[0128]例えば、クライアントが強調表示ＡＰＩを呼び出して段落識別子またはテキストを引き渡し、サービスが強調表示を行うことができる。クライアントがコメントＡＰＩを呼び出して、コメントを挿入する文、段落、または単語と共にコメントとして挿入するテキストを引き渡すことができる。デバイスは、文書のファイルフォーマットを理解している必要はない。例えば、文書がＤＯＣＸファイルとして保存されていても、クライアントがその文書をＰＤＦファイルまたはｅＰＵＢファイルとして閲覧（および編集）していてもよい。

[0129]別の実施形態によれば、クライアントがコメントＡＰＩを呼び出し、そのＡＰＩがコメントサービスを提供してもよい。コメントサービス（例えばコメントＡＰＩを介する）では、制限のあるエンドポイントが、文書の一部上のコメントを完全な文書に統合させるためにサービスに送ることが可能になる。コメントサービスは、コメントおよびそのコメントが文書のどの部分に関連するかの指示を受け取ってから、完全な文書がそのコメントを含むように修正することができる。

[0130]さらなる一実施形態では、例えば、購読のシナリオ（クライアントまたはサーバが、誰かが投稿したか、メッセージを送ったか、または他の文書にコメントしたとの通知および／またはコメントを受け取るか、または取得する）で、コメント自体にアドレスが割り当てられてから、他のクライアントによって使用されることができる。

[0131]図５Ｄに示される例では、編集された文書は、第１段落の強調表示、第３段落のテキスト訂正、および文書に関連するメタデータへの署名の追加を含む。強調表示ＡＰＩについては、クライアントは強調表示ＡＰＩを呼び出して、段落識別子５７０を強調表示サービス５７５に引き渡すことができる。タイプミスを訂正するために、クライアントは位置識別子（例えば、第３段落の第１文）および置換テキスト５８０をテキスト編集サービス５８５に引き渡すことができる。署名を追加するために、クライアントは、位置識別子（例えば、メタデータ）および署名５９０を署名サービス５９５に引き渡すことができる。

[0132]位置識別子には、文書内の段落を特定する位置識別子、文書内の行を特定する行識別子、文書内の文字を特定する文字識別子、および文書内の部分を特定する部分識別子が含まれるが、これらに限定されない。部分識別子は、文書コンテンツ、コメントコンテンツ、スタイルコンテンツなどの部分を区別する、位置の識別を提供することができる。部分識別子によって特定される文書の部分は、構造的に区切られた文書内のコンテンツであってもよい。一実施形態では、部分識別子は、関連するメタデータをもつ構造的なマークアップを通して修正された文書の部分を特定する。構造的に区切られたコンテンツの例を以下に示す。

[0133] これは段落です。
＜ｆｉｌｌ−ｉｎ ｒｅｇｉｏｎ＞ここのコンテンツをユーザが編集して、
統合するためにサーバに送り返してもよい＜／ｆｉｌｌ−ｉｎ ｒｅｇｉｏｎ＞
次の段落。

[0134]上記の例にはコンテンツコントロールがあり、ユーザによって修正可能なコンテンツは、特定される”ｆｉｌｌ−ｉｎ ｒｅｇｉｏｎ”マークアップの間の段落内にある。いくつかの実施形態では、修正が行われる文書の部分は、例えば、”ｆｉｌｌ−ｉｎ ｒｅｇｉｏｎ”などの、文書内の構造的マークアップを通して特定することができる。

[0135]いくつかの実施形態では、プレーンテキストのファイルフォーマットをサポートしているクライアントは、テキストを受け取って指定された書式を追加することのできるＡＰＩを、テキストを引き渡して呼び出すことによって、サービスを通してリッチなコンテンツをファイルに追加することができる。同様に、コンテンツをメタデータに追加するサービスを呼び出すことによってメタデータにコンテンツを追加することができる。

[0136]図６は、本発明の一実施形態による、エディタによって行われる処理を示す図である。エディタとは、テキスト、画像、または音声を編集するためのツールを含むクライアント（ハードウェアまたはソフトウェア）を指す。エディタは、ワードプロセッサアプリケーションを含む、生産性アプリケーションでもよい。

[0137]図６を参照すると、操作（６０２）で、エディタは文書を要求することができる。要求は、クラウドデータベース６０４に置かれたファイルを開く要求であってもよい。文書はそのエディタによってサポートされるものと同じファイルフォーマットではないことがあるので、文書への要求が、変換サービスを提供するアクセスサービス６０８を呼び出すことができる。アクセスサービス６０８は、データベース６０４から文書を取り出し、文書をそのエディタに適したファイルフォーマットに変換することができる。操作（６０８）で、エディタはアクセスサービス６０６から変換された文書を受け取り、受け取った文書を表示のためにレンダリングすることができる。

[0138]データベース６０４から取り込まれる文書はマスター文書でもよい。エディタの使用過程で、受信された文書をユーザが修正してもよい。受信された文書に修正が加えられると（６１０）、統合サービスを呼び出すことによって修正内容がマスター文書に統合されてもよい（６１２）。

[0139]統合サービスを呼び出すと（６１２）、アクセスサービス（６１４）の統合サービスが呼び出される。統合サービスの呼び出しは、ユーザから保存コマンドを受け取ったことへの応答として発生してもよい。別の実施形態では、統合サービスの呼び出しは、ワークフローの一部として発生してもよい。例えば、システムからの自動保存などの一定のイベントによって、統合サービスの呼び出しがトリガされてもよい。

[0140]ユーザの識別に基づいた文書および／またはアクセスサービスへのアクセスを提供するために、随意に、確認処理（６１６、６１８）が含まれてもよい。例えば、サインインしたユーザをアクセスサービス（６０６、６１４）について確認するために、ＯＡＴＨトークンが使用されてもよい。ユーザが認証されるように、エディタによってトークンがクラウドデータベースおよび／またはアクセスサービスに送られてもよい。

[0141]複数のさらなる実施形態ではアイデンティティマネージャを利用して、サービスが、ユーザは何者か、およびユーザが関心をもつ文書は何かを容易に知ることができるようにしてもよい。ユーザのアイデンティティを知ることによって、サービスはユーザに代わって、複数のデバイス（例えば、ユーザのコンピュータ、ラップトップ、タブレット、スマートフォン、電子書籍リーダーなど）およびサービス（例えば、Ｄｒｏｐｂｏｘ Ｉｎｃ．のＤＲＯＰＢＯＸサービスおよびＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．のＭＩＣＲＯＳＯＦＴ ＳＫＹＤＲＩＶＥサービスなどのファイルホスティングサービス）にわたるユーザのコンテンツ（例えば、文書）を取り出すことができる。

[0142]さらに、文書の提供先のクライアントを知ることによって、システムはあるフォーマットの文書を取り上げ、その文書を、そのユーザに使用されるクライアントのためにカスタム化されたフォーマットに変換することができる。例えば、あるユーザがＭＩＣＲＯＳＯＦＴ ＷＯＲＤの文書で作業しており、自分の電子書籍リーダーの中の文書にアクセスしたいと考える。このようなケースでは、サービスは、ユーザが電子書籍リーダーから利用可能なファイルを調べたときにその文書を提示することができる（例えば、ユーザが電子書籍リーダーでその文書を読めるように）。このことによって、現在ユーザが行っている、（文書を適切なフォーマットに変換するために）文書を電子書籍リーダーに送るというステップをなくすことができる。

[0143]ファイルは、リーダーデバイスのアプリを開いたときに利用可能になってもよい。アプリには、そのリーダーで実行可能な文書のハブが関連付けられていてもよい。別の実施形態では、リーダーによって、Ａｍａｚｏｎ．ｃｏｍがＫｉｎｄｌｅリーダーに提供するサービスなどのサービスが提供され、リーダーは、リーダーのユーザが本発明の一定の実施形態のアクセスサービスから文書にアクセスするために、拡張編集レイヤを介してユーザの体験を統合することができる。

[0144]一実施形態によれば、ユーザは単純に文書の作業を行い、文書（または文書のアドレス）を保存し、ファイルを閉じることができる。アイデンティティマネージャが、ユーザが何者かを知り、それからどのプラットフォームに対して文書を利用可能にするのかを知ることによって、文書は、同一または異なるクライアントによって再びアクセスされたときに、適切なフォーマットでユーザに提示される。

[0145]図７は、本発明の実施形態による、複数のエディタを使用して文書を共同作業するための方法の処理フローを示す。共同作業の方法は、アクセスサービスによって管理されるマスター文書７００に基づくことができる。第１のエディタ（エディタ１）は、操作（７１０）で、アクセスサービスに文書７００を要求することができる。マスター文書７００は、アクセスサービスに関連するデータベースに保管されていてもよいし、またはアクセスサービスが知っている位置から取り込まれてもよい。この例では、第１のエディタは、ｅＰｕｂフォーマットをサポートするリーダーで、マスター文書がＤＯＣＸフォーマットでもよい。アクセスサービスは第１のエディタに適したフォーマットを決定し（７１５）、文書を第１のエディタに提供することができる（７２０）。第１のエディタは、ｅＰｕｂフォーマットをサポートし、マスター文書のＤＯＣＸフォーマットをサポートしないので、サービスは第１のエディタに文書をｅＰｕｂフォーマットで提供することができる。

[0146]第１のエディタはｅＰｕｂフォーマットの文書を受け取り（７２５）、その文書を表示することができる（７３０）。第１のエディタのユーザは、例えばコメントを挿入するなどして、そのｅＰｕｂ文書を修正してもよい（７３０）。保存コマンド（または他の指定された条件）が発生すると、第１のエディタは、アクセスサービスに統合を要求することができる（７４０）。要求は、修正付きのｅＰｕｂ文書全体（例えば、文書およびコメント）または、修正の位置識別子および修正内容（例えば、コメントの位置およびコメントとして追加するテキスト）を含んでもよい。

[0147]アクセスサービスは統合要求を受け取って（７４５）、修正内容をマスター文書に統合する操作を行うことができる（７５０）。マスター文書は、元のフォーマットおよびバージョンを維持することができる。

[0148]第２のエディタはアクセスサービスに文書を要求することができる（７５５）。この例では、第２のエディタはＤＯＣＸ拡張をサポートするが、マスター文書とは異なるフィーチャバージョンのコンピューティングデバイスでもよい。説明例のように、マスター文書がバージョン５で、第２のエディタがバージョン１でもよい。操作（７６０）で、アクセスサービスは第２のエディタに適したフォーマットを判断し、第２のエディタに文書を提供することができる（７６５）。第２のエディタはＤＯＣＸ （フィーチャバージョン１）フォーマットの文書を受け取り（７７０）、文書を表示することができる（７７５）。第２のエディタのユーザが文書を修正してもよい（７８０）。保存コマンド（または他の指定された条件）が発生すると、第１のエディタはアクセスサービスに統合を要求することができる（７８５）。

[0149]アクセスサービスは統合要求を受け取って（７９０）、修正内容をマスター文書に統合する操作を行うことができる（７９５）。修正は、両方のバージョンでサポートされるフィーチャを使用したコンテンツの一部でもよい。第２のエディタは、新バージョンではなく旧バージョンのＤＯＣＸをサポートしているので、サービスを使用して新バージョンへの忠実度補正を行うことができ、新しいフィーチャを使用したコンテンツが統合によって破壊されることはない。

[0150]修正が両方のバージョンではサポートされないフィーチャを使用したコンテンツの一部である場合は、ユーザに代わって行われる変更および、ユーザの決定に応答して行われる変更を含め、任意の適切な方法で矛盾を解決してもよい。例えば、いくつかのケースでは、サービスによる決定は、修正を組み込むかどうか、どこにどのように組み込むかに関して行われてもよい。決定することができない（または決定に着手できない）と判断された場合には、サービスは１つまたは複数のデバイスに、すべての矛盾および可能性を見るかどうか選択させてもよい。次にユーザは、矛盾を解決するための選択肢を選ぶことができる。

[0151]アクセスサービスは、複数のエディタが同一のファイルの閲覧および編集を行えるようにする。それに加えて、第２のエディタおよび第１のエディタは、両方がマスター文書にアクセスしている間、その文書を異なるプラットフォームにわたってアクセスしている。

[0152]複数の実施形態によれば、ファイルは、ユーザにはコンテンツとして見え、個別にアドレス指定可能な部分（本明細書では「ブロック」と呼ぶ）を含む「文書」であることができる。これらの個別にアドレス指定可能なブロックは、テキスト、段落、段落の集合、表、オブジェクト、図、表、音声、画像、ならびにその他の様々な単位および集合を含むことができる。一定の実施形態によれば、各ブロックおよび／またはブロックの集合は、個別にアドレス指定可能であることができる。さらに、個別にアドレス指定可能な文書のブロックはそれぞれ、変換および統合サービスを使用して変換および統合することができる。いくつかのケースでは、このことは、文書が保管される方法と異なるフォーマットで文書の一部を編集するときに役立つことができる。

[0153]１つまたは複数のテキストブロック（書式設定付き、または書式設定なし）および／または画像が組み合わされ、文書ビューでユーザに提示されてもよい。
[0154]図９は、本発明の一実施形態による、アドレス指定可能な複数のコンテンツブロックを有する文書ビューを示す。図９に示されるように、あるユーザに、複数のコンテンツブロック（Ｂｌ ９０１、Ｂ２ ９０２、Ｂ３ ９０３など）で形成される単一の文書「文書」９００が見える。複数のコンテンツブロックは、凝集された１つの文書として見えるように組み合わされてもよく、その構成要素のうち少なくとも２つが異なるサービスまたはリソース位置から取得されたものであってもよい。

[0155]図９に示される例で、文書ビュー９００は、テキスト９１０、画像９２０、および表９３０を含むことができる。文書ビュー９００内のコンテンツのいくつかは、個別にアドレス指定可能でもよい（また、その文書を提供するアクセスサービスまたは他のサービスによって、異なるサービスまたはリソース位置から取得されたものであってもよい）。例えば、文書ビュー９００内の文または段落はアドレス指定可能なコンテンツブロックＢ１ ９０１からのコンテンツを含んでもよく、表９３０は、コンテンツブロックＢ２ ９０２およびＢ３ ９０３からのコンテンツを含む、個別にアドレス指定可能な１つまたは複数のセルを含んでもよい。

[0156]一定の実装では、文書ビューは共有ブロックビューを含むことができ、共有ブロックビューでは文書ビューを形成するサブブロックが文書ビュー内で視覚化される。視覚化は、強調表示、フォントの色、コメントによって示されてもよいし、またはその他の、文書ビューのその部分が共有ブロックまたは異なるアドレスから取得されたことをユーザが判断できる区別によって示されてもよい。

[0157]図１０は、本発明の一実施形態によるコンテンツキュレーションのためのシステムを示す。図１０を参照すると、あるユーザが、コンテンツアクセスサービスによって複数のリソースおよび／またはサービス（１００１、１００２、１００３）から取り込まれたコンテンツを、凝集された単一の文書１０００として閲覧することができる。一実施形態によれば、ユーザは、文書１０００をそのユーザのデバイスに適したフォーマットで利用可能な単一の文書として提示するアクセスサービスを使用して文書１０００にアクセスしてもよい。文書１０００を提示するとき、アクセスサービスは、書庫１０１０から複数の構成要素を取り込んでもよい。

[0158]例えば、クライアントは、複数のリソースから取り込まれるコンテンツを含む文書を要求してもよい。そのようなケースでは、コンテンツの断片を取り込むために、異なるリソース（またはサービス）に対応するＡＰＩ呼び出しを作成することができる。ユーザには第１のコンテンツブロックＣＩ １０２１、第２のコンテンツブロック １０２２、および第３のコンテンツブロック １０２３が単一の文書１０００に見えるが、クラウド（または書庫）には、ＡＰＩ１ １０３１、ＡＰＩ２ １０３２、およびＡＰＩ３ １０３３を通してそれぞれのリソースまたはサービス１００１、１００２、および１００３から取得された３つのサブ構成要素が見える。

[0159]アクセスサービスは、書庫１０１０から適切なサブ構成要素ＣＩ １０２１、Ｃ２ １０２２、および Ｃ３ １０２３を取得し、クライアントでの閲覧に適したフォーマットに整理することによって、文書要求の受け取りに応答してもよい。

[0160]文書の部分は、個別にアドレス指定可能であることができる。文書の一部分のみを別の人にレビューまたはコメント付けしてもらうときに、文書をＥメールで送るか、またはその人に文書全体を提供する代わりに、ユーザは、その文書のレビューまたはコメント付けの対象である特定の部分へのリンクをその人に送ることができる。文書の特定部分のアドレス（およびＵＲＬ）は、サービスを使用して要求することができる。ユーザは、アドレスを受け取った後、別の人にアドレスを送信することができる。文書のビュー内で作業しているとき、ユーザはある部分を選択して、アドレスの作成を要求することができる。

[0161]一実施形態では、アドレスが取得された後は、このアドレスはデータを取り戻すために、例えばＵＲＬの形で、人々およびシステムの間で渡し回されることができる。
[0162]いくつかの実施形態では、アドレスは、リンクまたはブロックのＵＲＬを表す他の形としてクライアントに戻されることができる。様々な実施形態によれば、アドレスサービスは１つまたは複数のサーバに組み込まれ、１つまたは複数のデータベースおよび／またはデータウェアハウスをアクセスすることができる。アドレスサービスは、ＳＯＡＰ ＡＰＩと共にＸＭＬ Ｗｅｖサービスとして実装されてもよい。

[0163]一定の実施形態によれば、サービスによって作成されたアドレスに存在するコンテンツにアクセスできるようにするために、ＵＲＬを作成することができる。コンテンツブロックを返すＵＲＬは、そのブロックのＧＵＩＤを含んでもよい。いくつかの実施形態では、ブロックが保管されているフォーマットを示すために、出力ファイルタイプを含むことができる。

[0164]例えば、ＧＥＴ ＨＴＴＰ要求を介して、ＵＲＬにアクセスすることによって、そのアドレスに存在するデータが取得されてもよい。ＵＲＬは、第３者サービスによって、あるコンテンツを購読者に提供するために使用されてもよい。

[0165]アドレスが作成された後は、そのアドレスを使用してデータを取得することができる。データは、ネイティブＸＭＬ、カノニカルＨＴＭＬ、またはテキスト形式であることができる。「カノニカル」なリンクとは、リソースの好ましいバージョンを指す。カノニカルなリンクリレーションは、関係する国際化リソース識別子（ＩＲＩ）のコンテンツを重複した形で返すリソースのセットの中から、好ましいＩＲＩ（すなわち、重複するコンテンツを有する複数のリソースのうち、好ましいＩＲＩ）を指定する。

[0166]図１１は、文書のコンテンツのサブセットに新しいアドレスを作成するシナリオ例を示す。図１１を参照すると、例えば位置識別子によって特定される文書ビュー１１１０のコンテンツブロックにアドレス（例えば、ＧＵＩＤ）を作成するために、アドレス作成ＡＰＩ１１００を呼び出すことができる。位置識別子には、文書内の段落を特定する位置識別子、文書内の行を特定する行識別子、文書内の文字を特定する文字識別子、および文書内の部分を特定する部分識別子が含まれるが、これらに限定されない。部分識別子は、文書コンテンツ、コメントコンテンツ、スタイルコンテンツなどの部分を区別する位置の識別を提供することができる。部分識別子によって特定される文書の部分は、構造的に区切られた文書内のコンテンツであってもよい。

[0167]アドレス作成サービスがＧＵＩＤを作成した後は、そのＧＵＩＤをコンテンツブロックに関連するメタデータとしてクライアントに返すことができる。
[0168]ＧＵＩＤを引き渡すＵＲＬを使用して、このコンテンツブロックにアクセスすることができる。いくつかのケースでは、文書のコンテンツブロックを表示するときに、文書ビューはこの新しいコンテンツブロックアドレスを使用することができる。

[0169]あるユーザによってコンテンツブロックが改訂されたときに、このブロックを使って形成されている、別のユーザが閲覧中の文書が改訂されることができる。いくつかのシナリオでは改訂は同時に現れてもよく、あるクライアントでコンテンツブロックが改訂されると、そのアドレス指定可能なコンテンツブロックを含む文書を閲覧中の別のクライアントには、その改訂がローカルで行われているかのように見えてもよい。他のいくつかのシナリオでは、改訂されたブロックがいつ共有されるか（および、そのアドレス指定可能なコンテンツにアクセスする他の人に利用可能になるか）をユーザが制御してもよい。このことは、例えば、ＵＲＬにあるバージョンを保管して、その文書の特定のバージョンへのポインタを送ることによって実現することができる。例えば、あるユーザはレビューのためにドラフトバージョンを送り、最新バージョンでの作業を続けることができる。ドラフトバージョンを受け取った人々には、改訂されたポインタの送信によって最新バージョンが共有されるまでは、変更内容は見えない。

[0170]１つの例では、クライアントがアドレス作成ＡＰＩ１１００を呼び出して、段落識別子１１１２または範囲（および、いくつかのケースではテキストまたは画像）を引き渡すことができ、サービスが、その段落または範囲に対してＧＵＩＤ−１ １１１４を生成（および保管）する。いくつかのケースでは、テキストまたは画像が提供されると、サービスは段落識別子または範囲が提出されたかのようにアドレスを生成することができる。

[0171]別の実施形態として、クライアントがアドレス作成ＡＰＩ１１００を呼び出して、表１１２２の１つまたは複数のセルを引き渡し、その表の１つまたは複数のセルのアドレス（例えばＧＵＩＤ−２ １１２４）をサーバに生成（および保管）させることができる。あるシナリオでは、そのようなコンテンツブロックを、計算に使用するために、スプレッドシートクライアントによってアクセスすることができる。別のシナリオでは、グラフまたは算術関数の総計を有するセルコンテンツブロック（スプレッドシートアプリケーションで作成されたものなど）に特定なアドレスを使用して、このコンテンツをブログで、またはワードプロセッサもしくはプレゼンテーション用の文書の一部として使用してもよい。

[0172]さらに別の例として、クライアントがアドレス作成ＡＰＩ１１００を呼び出して、メタデータ１１３２を引き渡し、そのメタデータに対して特定なアドレス（例えば、ＧＵＩＤ−３ １１３４）を取得することができる。当然ながら、メタデータは、他の位置特定されたコンテンツの１つまたは複数のブロックに含まれていてもよい。個別のアドレスを通じてアクセスされたときにメタデータが役立つことのある１つのシナリオは、バージョン情報または署名情報のメタデータの場合である。このメタデータは、後になって、文書の共同作業履歴を提示するためにアクセスされてもよい。いくつかの実装では、後にアクセスされたときに、履歴データはＵＲＬによって特定されるブロックのバージョンおよび特定のバージョンに関するコンテンツのリストを含むことができる。

[0173]権利の管理もまた、アドレスブロックのために実装されてもよい。例えば、クライアントがアドレス作成ＡＰＩを呼び出すときに、そのアドレスに存在するコンテンツがアクセスされた場合に確認するために、アクセス、編集、閲覧、および共有が誰に許可されるかに関する情報を要求と共に引き渡すことができ、そのような情報は、そのアドレスにあるコンテンツがアクセスされた場合に確認するために、例えばメタデータとしてサーバによって保管されることができる。このことを使用して、ある範囲または文書の他の特定可能な部分に対するアクセスまたは許可を管理することができる。あるシナリオでは、ブロックは、特定のユーザまたは役割（権利管理システムによって割り当てられるものなど）によるアクセスの管理を含むことができる。別のシナリオでは、ブロックは、ある部分が読み取り専用かどうかなどの許可を含むことができる。さらに別のシナリオでは、様々な役割を有するユーザがそれらに対応する許可を得られるように、アクセスと許可の両方を含むことができる。

[0174]図１２は、文書から作成されたコンテンツのサブセットを使用する、共同作業のための方法の処理フロー図を示す。図１２を参照すると、アクセスサービスによってマスター文書１２００を管理することができる。操作（１２１０）で、第１のクライアント（ユーザ１）はアクセスサービスに文書１２００を要求することができる。マスター文書１２００は、アクセスサービスに関連するデータベースに保管されていてもよいし、またはアクセスサービスが知っている位置から取り込まれてもよい。第１のクライアントからの要求に応答して、アクセスサービスは文書を適切なフォーマットで第１のクライアントに提供できる（１２１５）。

[0175]第１のクライアントは文書を受け取って表示することができる（１２２０）。第１のクライアントのユーザは、例えば、テキスト行内のタイプミスの変更、コメントの追加、またはその他の何らかの編集機能を行うことによって、随意に文書を修正してもよい（１２２５）。文書の閲覧中に、ユーザは１つまたは複数のコンテンツブロックを選択し（１２３０）、その選択内容のアドレスをアクセスサービスに要求することができる（１２３５）。要求は、位置識別子および／またはユーザが選択したコンテンツを含むことができる。

[0176]アクセスサービスはアドレス要求を受け取って、その選択範囲のアドレスを作成することができる（１２４０）。選択されたブロック（複数可）（またはその位置）がアクセスサービスによってデータストアに保管され、そのブロック（複数可）のアドレスがクライアントに提供されてもよい。クライアントはアドレスを受け取り（１２４５）、そのブロックのアドレスを文書のメタデータに含ませることができる。新しく割り当てられたアドレスを有する部分を含む文書に修正が行われてもよく（１２５０）、そのブロック内のデータが（修正があれば、修正と共に）サーバにプッシュバックされて、アクセスサービスによってアドレスＢ１に保存されてもよい（１２５５）。図示されていないが、元の文書（および／またはその文書への修正）もまた、マスター文書の元のフォーマットおよびバージョンを保ったまま、マスター文書１２００に戻して統合されてもよい。

[0177]第２のクライアント（ユーザ２）（作成されたコンテンツブロックＢ１についての情報をあらかじめ与えられていてもよい人）が、アドレスＢ１にあるコンテンツを要求することができる（１２６０）。アクセスサービスへの要求は、そのコンテンツのアドレスと所望のフォーマットの両方を含んでもよい。いくつかのケースでは、アクセスサービスは他の方法でコンテンツのフォーマットを判断することができる。アクセスサービスは、コンテンツブロックＢ１を適切なフォーマットで第２のクライアントに提供することができる（１２６５）。第２のクライアントはＢ１コンテンツを受け取って、文書ビューに表示することができる（１２７０）。第２のクライアントは、そのコンテンツブロックを単独で表示してもよいし、これもアクセスサービスによってアクセスされる別の文書の一部として表示してもよいし、または、第２のクライアントによって生成または作成された別の大きな文書の一部として表示してもよい。第２のクライアントのユーザは、コンテンツブロックＢ１を含め、その文書を修正してもよい（１２７５）。保存コマンド（または他の指定された条件）が発生すると、第２のクライアントは、アクセスサービスに統合を要求することができる（１２８０）。

[0178]アクセスサービスは統合要求を受け取って（１２８５）、修正内容をアドレスＢ１にあるコンテンツに統合する操作を行うことができる（１２９０）。
[0179]図１３は、例示的一実施形態を説明する動作環境の図を示す。コンテンツアクセスサービス１３００がクラウド上に拡張編集機能レイヤを提供し、このレイヤを第３者（または当事者）である（第２のサービスの）プロバイダがユーザの体験に統合してもよい。

[0180]例えば、第２のサービス１３０５が特定のファイル部分を求める要求１３１２と共に、コンテンツアクセスサービス１３００を呼び出すことができる。そのファイル部分は、コンテンツアクセスサービス１３００によってアクセス可能か、またはクラウド上にホスティングされているデータストア１３２０から取り込まれてもよい。要求１３１２を受け取ったことに応答して、コンテンツアクセスサービス１３００は、文書のデータブロックを第２のサービス１３０５に適したフォーマットで第２のサービス１３０５に返してもよい。データのフォーマットは、アクセスサービス１３００によって変換されてもよいし、または変更せずに第２のサービス１３０５に提供されてもよい。第２のサービス１３０５は、コンテンツをクライアント１３１０に提供してもよい。いくつかの実施形態では、要求は複数の要求および／またはリソースを含むことができる。データが第２のサービス１３０５によって受け取られた後で、データが組み合わされ、任意の適切な方法でユーザ１３１０に提供されてもよい。

[0181]例えば、第２のサービス１３０５は、あるユーザが、そのユーザまたは他の人がキュレーションしたコンテンツを含むコンテンツを購読しているか、または何らかの別の様式で受け取っている先のコンテンツアクセスサービスでもよい。

[0182]図１４は、キュレーションされたコンテンツにアクセスするための方法の処理フロー図である。アクセスサービスがコンテンツブロック１４００を管理することができる。コンテンツブロック１４００は、アクセスサービスに関連するデータベースに保管されていてもよいし、またはアクセスサービスが知っている位置から取り込まれてもよい。操作（１４１０）で、クライアント（ユーザ３）は第２のサービスに出版物／文書を要求してもよく、第２のサービスは購読サービスでもよい。この出版物／文書は、キュレーションされたコンテンツを含むことができる。第２のサービスは購読要求を受け取ってから（１４１５）、操作（１４２０）で、コンテンツブロック１４００をアクセスサービスに要求することができる。アクセスサービスは文書を適切なフォーマットで第２のサービスに提供することができる（１４２５）。第２のサービスがコンテンツブロックを受け取った（１４３０）後で、コンテンツブロックＢ１を、第２のサービスによって要求または生成されてもよい他のデータと組み合わせることができる（１４３５）。出版物／文書は、クライアントによって受け取られることができる（１４４０）。

[0183]通知サービスを利用してコンテンツの改訂を購読者に伝えることができる。あるいは、コンテンツは定期的に更新されるか、または改訂が行われたことの通知を受け取ったときに更新されることができる。

[0184]コンテンツブロックのアドレスを（例えば、アドレス指定可能なエンティティまたはオブジェクトを作成することによって）作成することによって、サーバから名前付きオブジェクト（複数可）を取得し、その名前付きオブジェクトのカスタム化されたビューを閲覧／編集してから、統合および変換の問題を扱うサービスを利用することができる。

[0185]下記のシナリオ例は、本発明の一定の実施形態および本発明の多数の利点がより良く理解されるように提示される。下記のシナリオ例は、本発明の実施形態のいくつかの適用例および変形例を説明することのみを目的とする。当然ながら、これらのシナリオ例は、本発明を限定するものとは決して考えられない。

[0186]シナリオ例Ａ：
[0187]ＫＩＮＤＬＥリーダーまたはＮリーダーのユーザが文書を読んでおり、コメント、タイプミスの訂正、強調表示、またはその他のなんらかの修正もしくは注釈によって文書に寄与しようとしている。これらのリーダーは、そのリーダーが主としてエディタでない場合でも、何らかの編集能力を有する。したがって、本発明の一定の実施形態では、ユーザがそのリーダーの能力、例えば注釈および編集の能力の利点を利用してから、それらの修正を文書に戻して統合することができる。各デバイスまたはアプリケーションが共著能力を含む代わりに、「サービスとしての文書」統合サービスは、複数の異種のプラットフォームからでも、編集内容／コンテンツを文書に戻して統合することができる。

[0188]一実施形態では、リーダーが同期操作を行うときに統合を行うことができる（ユーザが、達成可能な最も遠い位置からデジタルコンテンツを収集しながら複数のデバイスにわたってデジタルコンテンツを読むことができるようにする操作など）。そのような１つのケースでは、同期サービスに位置更新を求める呼び出しのときに、本発明の一実施形態の変換および統合サービスに、文書に加えた修正を送ることができる。

[0189]別の実施形態では、例えば、ユーザが文書を保存することを選択したときなどのユーザによる能動的なステップに際して、リーダーは変換および統合サービスを呼び出すことができる。

[0190]クライアントはそのクライアントが理解できるレイヤを含んで共著を行う必要がないので、デバイスは「ダンパー」であること、すなわちデバイスリソースを他のアプリケーションおよび機能に集中させることができる。

[0191]シナリオ例Ｂ：
[0192]最近のバージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤ文書および、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．から入手可能なワードプロセッサソフトウェアでは、文書はＤＯＣＸフォーマットで作成されることがあるが、著者は、ｅＰｕｂフォーマットを使用するＮＯＯＫリーダーまたは、所有権付きのＡＺＷおよびＫＦ８フォーマットを使用するＡＭＡＺＯＮ ＫＩＮＤＬＥリーダーなどのリーダーで文書の閲覧、またコメント付けまたは編集を行おうとすることがある。その人は、このサービスを使用することによって、ＮＯＯＫリーダーまたはＫＩＮＤＬＥリーダーに適したフォーマットで文書にアクセスして、例えば、コメントを追加することなどによって文書を変更することができる。コメントはマスターファイルに戻して保管することができ、この場合、このファイルはＤＯＣＸファイルフォーマットである。

[0193]シナリオ例Ｃ：
[0194]現在、文書の作成に使用されたバージョンと異なるバージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤ文書を開くと、文書のフィーチャがすべては表示されないことがある。例えば、あるフォントまたは書式が変わったり、例えば、脚注機能および一部のマクロなどの複雑なフィーチャが消えたりすることがある。ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ９７（ＤＯＣ拡張ファイルフォーマットを使用）およびＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ２０１０（ＤＯＣＸ拡張ファイルフォーマットを使用）の場合のように、いくつかのケースでは、バージョンの変更はファイルフォーマットの変更でもある。ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ２００７およびＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ２０１０の場合のように、別のケースでは、バージョンの変更は追加の機能および／またはフィーチャを提供する。

[0195]古いバージョンで文書を作成してから新しいバージョンで開いたときに起こる問題は少なくなってはいるが、あるフィーチャが新しいバージョンで廃止されている場合または完全にはサポートされていない場合にはエラーが起こることがある。文書を開くために使用されるバージョンと異なるバージョンで作成された文書を表示することに関する問題に加え、新しいバージョンで作成された文書を古いバージョンで開いてから保存すると、文書を古いバージョンで再び開いたとしても、古いバージョンのフィーチャが失われることがある。例えば、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ２０１０ワードプロセッサアプリケーションは、グラフィックスの作成および操作のフィーチャを含む。ＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ２０１０で凝ったグラフィックスを含む文書を作成しても、文書の最初のページのテキスト内のタイプミスを訂正するためにＭＩＣＲＯＳＯＦＴ ＷＯＲＤ ９７で開いてから保存すると、保存された文書は古いバージョン（ＤＯＣ拡張ファイルフォーマット）に逆戻りして、凝ったグラフィックスが失われる。１つの単語を変更しただけでも、文書全体が古いバージョンのグラフィック画像に逆戻りしてしまう。

[0196]一定の実施形態によれば、古いバージョンへのユーザの意図的な変更が認識され、新しいフィーチャを保持したままで、新しいバージョンでサポートされる文書に統合することができる。

[0197]シナリオ例Ｄ：
[0198]コンテンツアクセスサービスを使用することによって、コンテンツを既存製品の古いバージョンに合わせて調節することができる。例えば、ユーザ（最新プログラムを実行している、およびその逆）が受け取るファイルはエンドポイントに基づいて調節されている可能性があるので、ユーザは最新バージョンのソフトウェアアプリケーションへのアップグレードを遅らせることもできるし、または古い／新しい拡張ファイルフォーマットを読むために、次のバージョンに下位互換性を要求することもできる。

[0199]例えば、ＭＩＣＲＯＳＯＦＴ ＯＦＦＩＣＥ ２０１３を実行しているクライアントは利用可能なすべてのフィーチャを含むフルビューを受け取ってもよいが、同じ文書がＭＩＣＲＯＳＯＦＴ ＯＦＦＩＣＥ ２００７を実行しているクライアントによって開かれたときは、サービスは、消費ビュー用でありながらＭＩＣＲＯＳＯＦＴ ＯＦＦＩＣＥ ２００７のために最適化されたコンテンツをパッケージングする。最適化には、一定のフィーチャを適切な忠実度のフィーチャに置き換えることを含むことができる。一例として、あるバージョンで提供される数式エディタには下位互換性がないことがある。したがって、サービスは文書パッケージ内の数式を数式の画像または、文書の提供先のバージョン内の数式エディタで編集可能な形に置き換えてもよい。

[0200]ワードプロセッサアプリケーションを含む、他の生産性アプリケーションのために類似の体験を提供することができる。例えば、ＭＩＣＲＯＳＯＦＴ ＯＦＦＩＣＥ ２０１３を実行しているクライアントは利用可能なすべてのフィーチャを含むフルビューを受信してもよいが、Ｇｏｏｇｌｅ Ｉｎｃ．から入手可能なＧＯＯＧＬＥ ＤＯＣＳ、Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎから入手可能なＡＰＡＣＨＥ ＯＰＥＮＯＦＦＩＣＥ、またはＺｏｈｏ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＺＯＨＯ ＯＦＦＩＣＥなどの別の生産性アプリケーションを実行しているクライアントから同じ文書が開かれたときは、サービスは、消費ビュー用でありながらＧＯＯＧＬＥ ＤＯＣＳ、ＯＰＥＮＯＦＦＩＣＥ、またはＺＯＨＯ ＯＦＦＩＣＥのために最適化されたコンテンツをパッケージングする。

[0201]シナリオ例Ｅ：
[0202]マスターファイルは最も高い忠実度のフォーマットで保管されてもよい。例えば、マスター文書が最新バージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤで保存されてもよい。古いバージョンのＭＩＣＲＯＳＯＦＴ ＷＯＲＤを実行しているクライアントは、ＤＯＣＸフォーマットではなくＤＯＣフォーマットでファイルのサービスを受けることができる。ユーザがＤＯＣ文書に変更を加え、その文書を保存すると（自動保存の一部として、または能動的ステップによって）、ＤＯＣ文書への変更はマスターファイルに戻してＤＯＣＸフォーマットで保存される。一実施形態では、ＤＯＣ文書全体がサーバでＤＯＣＸフォーマットに補正される。別の実施形態では、ユーザが修正した部分のみが（単に、クライアントにＤＯＣファイルがサービスされたときにコンテンツに加えられた差異の一部ではなく）保存時にサーバに返される。この部分は次いで完全な忠実度の文書と再関連付けされ得る。

[0203]シナリオ例Ｆ：
[0204]複数の実施例では、同じ製品の異なるバージョン間で上位および下位の互換性を促進することができる。現在、ＭＩＣＲＯＳＯＦＴ ＷＯＲＤプログラムで保存されたファイルは、複数のターゲット向けに保存される。例えば、あるファイルで数式の最新バージョンのフィーチャを使用してファイルを保存すると、ネイティブの数式データが保存され（編集のために適切な忠実度で読み戻せるように）、古いバージョンのワードプロセッサでその数式エディタがサポートされていなくても数式がどのように見えるかを表示できるように、数式の画像が保存される。古いバージョンには新しいバージョンが完全な忠実度を取り戻すための方法についての情報が含まれてもよい
[0205]ワードプロセッサの各バージョンは、あるフィーチャバージョンが完全な忠実度を取り戻せるように、一定のフィーチャをラウンドトリップさせる方法に関する情報を含む。ラウンドトリップとは、文書があるバージョンから別のバージョンに変わり、次に元のバージョンに戻ることを指す。例えば、フィーチャＡがバージョンＸにあるが、バージョンＹではフィーチャＡはフィーチャＡプライムとして表現されることがある。フィーチャＡプライムがバージョンＸから閲覧またはアクセスされると、そのフィーチャはＡに戻る。この仕組みでは、古いバージョンがそのフィーチャをどのようにラウンドトリップできるか、および追加データを保存するよう要求する可能性に基づいて、フィーチャバージョンが下位互換性をもつことが強要される。

[0206]本発明の実施形態では、あるバージョンが様々なフィーチャをラウンドトリップさせる方法を知るよう強要しないか、または強要の程度を軽減するとともに、複数のバージョンをサポートするために保存するデータの量を減少させる。複数の実施形態では、ある製品の古いバージョンが、その製品の新しいバージョンからのコンテンツを読んで保持できるようになる。

[0207]シナリオ例Ｇ：
[0208]リッチテキストフォーマット（ＲＴＦ）は、様々な文書、テキストおよびグラフィックスの書式設定属性を、多くのワードプロセッサアプリケーション用のプラットフォーム間の文書交換に使用するために符号化するファイルフォーマットである。そのファイルに想定されるクライアント／消費者をサポートするために、現在、ＲＴＦファイルには１つのファイル内に複数の別バージョンの画像が保存される。例えば、あるファイルが現在のバージョンの画像を提供し、第２の（またはより多くの）ファイルが１つまたは複数の古いバージョンの画像を提供し、別のファイルがＷＯＲＤ ２．０バージョン、さらに別のファイルがＷＯＲＤＰＡＤバージョンを提供する。変換および統合サービスを提供することによって、ワードプロセッサアプリケ−ションが多くのファイルフォーマットをサポートする必要、または同じ内容の複数のファイルをもつ必要がなくなる。

[0209]シナリオ例Ｈ：
[0210]統合サービスを適用して、Ｅメールで送られた文書内の変更を自動的に統合することができる。そのようなケースでは、Ｅメールサービスまたはサーバが統合サービスと通信できる。統合サービスは、Ｅメールサービス（またはＥメールサーバ）がエディタであるかのように統合を行うことができる。

[0211]例えば、あるグループの人々がある文書で共同作業してもよい。グループの１人がオフラインで行った変更を、他の人にＥメールの添付として送信してもよい。サービスおよびシステムはその文書の識別子を知っているので、統合サービスと通信するよう構成されたＥメールサービスまたはＥメールサービスをもつ受信者へのＥメール送信動作によって、ユーザに代わってマスター文書に変更を統合することができる。

[0212]別の例では、グループの１人が、第１のＥメールサービスに関連するアカウントを使用する他の人にＥメールを送信し、その文書を添付してもよい。何人かの受信者は、第１のＥメールサービスに繋がっていない第２のＥメールサービスを使用していてもよい。例えば、第１のＥメールサービスがＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．のＨＯＴＭＡＩＬサービスで、第２のＥメールサービスがＧｏｏｇｌｅ ＩｎｃのＧＭＡＩＬサービスであってもよい。

[0213]第１のＥメールサービスと繋がっていない第２のＥメールサービスのユーザの１人が文書を編集して、編集した文書を添付して返信したときに、第１のＥメールサービスが変更内容（オフラインで加えられた変更）をマスター文書に戻して統合することができる。第１のＥメールサービスは添付ファイルを受信し、文書（および文書の系統）を特定して、統合サービスとの通信を開始することができる。統合サービスは、第１のＥメールサービスがエディタであるかのように統合のサービスを行うことができる。

[0214]シナリオ例Ｉ：
[0215]あるユーザが、制限されたコンピューティング能力および制限された帯域幅（たとえば遅延に起因する）を有するデバイス（例えば電話）を使用してレビューするために文書を受信してもよい。現在、そのユーザがこの環境で文書にコメント付けしようとすると、ただ１つのコメントまたは変更でも、文書全体がサーバに返送される。一実施形態によれば、アクセスサービスはユーザのデバイスの制限への適応策を提供して、変更の確認を行うためのコメントチェックボックス（「はい」または「いいえ」）を組み込むことができる。すると、チェックボックス応答の結果だけがサーバに返送されることができる。この様式では、デバイスは必要なデータをサービスから取得してから、サービスを呼び戻してコメントを更新して承認させることができる。サービスは確認結果を受け取り、忠実度の高いコメントの修正および／または挿入を行うことができる。能力の限られたデバイスのユーザには、そのデバイスに共著のソフトウェア／技術を導入する費用をかけなくても、すべての共著体験を有しているように感じられる。

[0216]シナリオ例Ｊ：
[0217]消費者デバイスへのコンテンツの適応の一例として、消費者デバイスがタッチ対応デバイスであるが文書がタッチに対応していないケースがある。サービスは、例えば、ズーム機能または拡大されたフィーチャなどを提供することによって文書を拡張して、文書をタッチ対応にすることができる。図示される例のように、大画面のデバイスで最初に作成されたが小画面のデバイスでレンダリングするために提供される文書内の表には、表を（閲覧のために）ズームインできるようにタッチ用の外観を追加することができる。

[0218]あるいは、または、さらにサービスは、小さいデバイスの寸法を考慮することによって３列の表のうち１列分のスペースしかないと判断し、小さい画面に適した形で表を提示することができる。これには、ズームフィーチャを追加することまたは、一度に１列のみを表示することが含まれてもよい。

[0219]シナリオ例Ｋ：
[0220]ユーザがアドレス作成ＡＰＩを使用して、アドレス指定可能領域を指定することができる。あるシナリオ例では、スプレッドシートアプリケーションで表がアクセス、閲覧、および修正されてもよい。この表は、その表が作成されてアドレス指定可能領域に入っているワードプロセッサアプリケーションから取得されてもよい。スプレッドシートアプリケーションで変更が行われた後に、表がワードプロセッサの文書に返送され（必要なら変換されて）、統合されてもよい。この表は複数の文書に入れることができる。すなわち、オブジェクトが画定された（かつ、アドレスを与えられた）後は、そのオブジェクトへの変更がサーバに戻されると、その変更はそのオブジェクト（およびアドレス）を全体の一部として使用するすべての「文書」で見えるようになる。

[0221]ユーザが、あるバージョンに個別のアドレスを作成することによってコンテンツのそのバージョンを「凍結」してもよい。いくつかのケースでは、凍結されたバージョンへのアクセスに追加の許可を関連付けてもよい。

[0222]ユーザがコンテンツブロックの編集中に一時的バージョンを提供し、ユーザが選択したときにブロックへの変更が更新されるようにしてもよい。一実装では、これは、ユーザがクライアントで、そのユーザがブロックへの変更を一時的に保存していることを明らかにする、独立したプッシュ機能をもつことによって達成できる。そのようなケースの１つでは、サービスは、直前のバージョンまたは一時的変更のどちらかをポインタと関連付けることができる。

[0223]シナリオ例Ｌ：
[0224]１つのシナリオ例では、エディタがＨＴＭＬで文書を要求することができる。ＨＴＭＬで提供された文書を閲覧および／または編集しながら、サービスを呼び出してアドレス指定可能なサブ領域を作成することができる。すなわち、アドレスサービスがコンテンツブロック（関連するメタデータを含んでもまたは含まなくてもよい）のためにアドレスを作成することができる。例えば、閲覧中のページおよび、その閲覧中のページ内に表示されているデータのためのアドレスを要求することができる。例えば、要求は領域を閲覧中のページとして定めることができ、その新しく作成されたアドレスに、その閲覧中のページ内のデータを保管する（または関連付けする）ことができる。複数の実施形態によれば、閲覧中のページをさらに分割して、特定の領域にアドレスを作成することができる。どちらのケースでも、表示中のページの一部をキャプチャするよう要求するクライアントには、閲覧中の文書に加えられた修正に起因するデータサイズの変化を処理する能力は必要ない。その代わりに、クライアントはアドレス作成ＡＰＩを呼び出すことができ、このＡＰＩが統合および変換の問題を処理する。

[0225]例えば、エディタ／ビューアが受け取った文書のバージョンが、２００文字の文字列の文字５５から文字７５までの範囲のコンテンツを提示することがある。しかし、（その範囲内または範囲外で）文書に修正が加えられると、閲覧のために取り込まれる範囲がユーザの所望する部分をカバーしていないことがある。

[0226]その範囲内のテキストに対してアドレスを作成することによって、同じアドレスに関連するテキストへの変更に起因して範囲が変化しても、範囲の変化は問題にならない。その理由は、その変化を、すべてのコンテンツの取り出しに使用できる１つのアドレスに関連付けることができるからである。いくつかのケースでは、ある特定の範囲の中のテキストをクライアントに与えることを求める要求が作成されるときにはアドレスが要求されるという、アドレス作成ＡＰＩによる暗黙の了解があり得る。

[0227]範囲とは、ＨＴＭＬ文書のコンテンツの一部を指し、どの位置でも開始および終了することができる。一般に、範囲オブジェクトは、範囲の開始点および終了点を含み、その範囲内のコンテンツ（テキストまたはＨＴＭＬ要素など）のコピー、削除、置換を可能にする。モニカーとは、１つまたは複数のオブジェクトを特定してその位置を知るために使用できるニックネームまたは名前を指す。ＨＴＭＬは、アンカーおよび名前付き領域を含むこともでき、それらはアドレスサービスを通してアドレス指定可能にすることができる。

[0228]シナリオ例Ｍ：
[0229]第３者（または当事者）であるプロバイダ（第２のサービスのプロバイダ、またはウェブプレゼンスを有するプロバイダ）は、アドレス作成サービスを使用して、独自のアプリケーションを提供することができる、例えば、住宅ローン会社（またはその他のベンダー）がアドレス作成サービスを使用して、ウェブアプリケーションのユーザがローンを組む際に異なるオプションを試せるように、その会社のウェブアプリケーションを提供することができる。ユーザによって調節可能なローンオプションの変数には、期間（例えば、３０年、１５年、７年）、細目、総額、月払い額などが含まれてもよい。このタイプの論理は、スプレッドシートアプリケーションを使用して実装することができる。単に住宅ローン会社が顧客にスプレッドシートを提供するだけでは、そのようなプログラムを実装したスプレッドシートアプリケーションはすぐに管理できなくなることがある。そのようなプログラムを実装するために使用できる別の選択肢は、住宅ローン会社（またはベンダー）が独自のウェブアプリケーションおよび計算エンジンを作成することである。

[0230]スプレッドシートを提供したり、新しいウェブアプリケーションを提供したりする代わりに、本明細書に記載されるサービスのうち１つまたは複数を活用して、償却または他の融資シナリオのオプションを提供することができる。例示的一実装によれば、スプレッドシートアプリケーションのワークシートを住宅ローン会社が作成して、あるユーザのためにカスタム化したビューの一部として顧客が利用できるようすることができる。例えば、ウェブアプリケーション（またはウェブページ）がスプレッドシート文書にアクセスして、住宅ローン会社がアドレス指定可能した部分に基づいて、ユーザにビューを提示することができる。一実装では、住宅ローン会社は、顧客から情報を収集し、スプレッドシートを作成し、顧客から収集した情報をスプレッドシートに記入するＷｅｂアプリケーションを作成することができる。「スプレッドシート」が、スプレッドシートＡＰＩを通して呼び出され、そのＡＰＩがワークシートを作成し、スプレッドシートに範囲を追加し、そのワークシート（または、セルもしくは範囲）に対する更新を可能にしてもよい（例えば、範囲追加ＡＰＩまたは範囲修正／更新ＡＰＩ）。

[0231]スプレッドシートが作成された後は、住宅ローン会社のアプリケーションは、ユーザがデータを閲覧および操作できるようにしてスプレッドシートを開くか、または専用に作成されたユーザインタフェース内に情報（例えば、個別にアドレス可能な総額セルからの情報）を提示することができる。スプレッドシートのビューまたは専用に作成されたユーザインタフェースのビューはユーザからの入力を受け取とってから、サービスを呼び出して、結果の計算および／または更新を行わせることができる（例えば、計算ＡＰＩ、または統合後のセルからデータを取得するための呼び出しを通して）。

[0232]さらなる一実装では、データ入力および計算出力の一定部分に関連するスプレッドシートのセルを個別にアドレス指定可能にしてもよく（アドレス作成サービスの使用を通して）、ワードプロセッサまたはその他のアプリケーションからアクセスして、例えばローンアプリケーションの一部として使用できる文書ビューを作成してもよい。

[0233]図８は、いくつかの実施形態で使用されるコンピューティングデバイスの構成要素を示すブロック線図である。例えば、システム８００を使用して、クライアントデバイス、エディタ、またはリーダーをデスクトップコンピュータ、ノートコンピュータ、タブレット、スマートフォンなどの、１つまたは複数のアプリケーションを実行することのできるものの形で実装することができる。いくつかの実施形態では、システム８００は、統合されたＰＤＡおよび無線電話などの統合コンピュータデバイスである。本明細書に記載されるシステムの複数の態様は、モバイルおよび従来のデスクトップの両方のコンピュータ、ならびにサーバコンピュータおよびその他のコンピュータシステムに適用可能であることを理解されたい。例えば、タッチスクリーンまたはタッチ入力可能デバイス（タッチ入力可能なトラックパッドまたはマウスを含むが、これらに限定されない）が、モバイルおよびデスクトップの両方のデバイスに適用可能であることができる。

[0234]システム８００はプロセッサ８０５を含み、このプロセッサは１つまたは複数のアプリケーションプログラム８１０および／またはオペレーティングシステム８２０の命令に従ってデータを処理する。プロセッサ８０５はシステムオンチップ（ＳｏＣ）に、センサ（例えば、磁気探知機、環境光センサ、近接センサ、加速度計、ジャイロスコープ、全地球測位システムセンサ、温度センサ、衝撃センサ）、およびネットワーク接続性のための構成要素（無線／ネットワークインタフェース８３５を含む）などの１つまたは複数の他の構成要素と共に含まれてよい、または含まれる。

[0235]１つまたは複数のアプリケーションプログラム８１０がメモリ８１５にロードされ、オペレーティングシステム８２０上で、またはオペレーティングシステム８２０と関連して実行してもよい。アプリケーションプログラムの例には、電話ダイヤルプログラム、Ｅメールプログラム、ＰＩＭプログラム、ワードプロセッサプログラム、スプレッドシートプログラム、インターネットブラウザプログラム、メッセージングプログラム、ゲームプログラムなどが含まれる。その他のアプリケーションプログラムがメモリ８１５にロードされてデバイス上で実行してもよく、これには様々なクライアントアプリケーションおよびサーバアプリケーションが含まれる。

[0236]メモリ８１５は、組み込みおよび取り外し可能なメモリコンポーネントを含む１つまたは複数のメモリコンポーネントを包含してもよく、その１つまたは複数のメモリコンポーネントがオペレーティングシステムを保存できることが理解される。様々な実施形態によれば、オペレーティングシステムには、Ｓｙｍｂｉａｎ Ｌｔｄ．のＳＹＭＢＩＡＮ ＯＳ、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ（登録商標） ＭＯＢＩＬＥ ＯＳ、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ（登録商標） ＰＨＯＮＥ ＯＳ、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ ＣｏｍｐａｎｙのＰＡＬＭ ＷＥＢＯＳ、Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ ＬｉｍｉｔｅｄのＢＬＡＣＫＢＥＲＲＹ ＯＳ、Ａｐｐｌｅ Ｉｎｃ．のＡＰＰＬＥ ＩＯＳ、および、Ｇｏｏｇｌｅ Ｉｎｃ．のＧＯＯＧＬＥ ＡＮＤＲＯＩＤ（登録商標） ＯＳが含まれるが、これらに限定されない。その他のオペレーティングシステムも意図されている。

[0237]システム８００はメモリ８１５内に不揮発性ストレージ８２５も含む。不揮発性ストレージ８２５は、システム８００の電源が切られたときに失われてはならない永続的情報を保存するために使用されてもよい。アプリケーションプログラム８１０は不揮発性ストレージ８２５を使用して、生産性アプリケーションでコンテンツの作成または修正が行われている間に実行されたコマンドの記録などの情報を保存してもよい。また、ホストコンピュータシステム（サーバなど）上の対応する同期アプリケーションと対話するために同期アプリケーションが含まれ、アプリケーションプログラム８１０の一部として存在して、不揮発性ストレージ８２５に保存された情報とホストコンピュータシステムに保存された対応する情報との同期を維持してもよい。

[0238]システム８００は電源８３０を有し、この電源は１つまたは複数のバッテリーおよび／または環境発電装置（環境放射線、光起電力、圧電、熱電、静電など）として実装されてもよい。電源８３０は、ＡＣアダプタまたは給電ドッキングクレードルなどの、バッテリーへの給電または充電を行う外部電源をさらに含んでもよい。

[0239]システム８００は、無線周波通信の送受信の機能を行う無線／ネットワークインタフェース８３５も含んでもよい。無線／ネットワークインタフェース８３５は通信事業者またはサービスプロバイダを介して、システム８００と「外界」との間の無線接続性を促進する。無線／ネットワークインタフェース８３５との間の伝送はオペレーティングシステム８２０の制御下で行われ、オペレーティングシステム８２０は無線／ネットワークインタフェース８３５が受信した通信をアプリケーションプログラム８１０に伝え、また、その逆を行う。

[0240]システム８００は無線／ネットワークインタフェース８３５によって、サーバコンピューティングデバイスおよびその他のクライアントデバイスを含む他のコンピューティングデバイスとネットワークを介して通信することができる。

[0241]オーディオインタフェース８４０を使用して、聴覚信号をユーザに提供し、かつ、ユーザから受け取ることができる。例えば、電話の会話を容易にするなどのために、オーディオインタフェース８４０をスピーカに接続して聴覚出力を提供し、かつマイクロフォンに接続して聴覚入力を受け取ることができる。また、ユーザが音声コマンドを通じてコンピューティングデバイスと対話できるように、スピーカが組み込まれてもよい。

[0242]システム８００は、ビデオインタフェース８４５をさらに含んでもよく、このインタフェースは静止画像、ビデオストリームなどを記録するための任意選択のカメラ（図示せず）の操作を可能にする。また、コンピューティングデバイスとの対話に使用されるジェスチャをキャプチャするためにカメラが使用されてもよい。

[0243]ディスプレイ８５５を通して視覚出力を提供することができる。ディスプレイ８５５はタッチスクリーンディスプレイでもよい。いくつかのケースでは、ディスプレイはタッチスクリーンでなくてもよく、ディスプレイ８５５のグラフィカルユーザインタフェースの部分として表示される選択項目を選択するためにボタン、キー、ローラーホイールなどのユーザ入力要素が使用される。

[0244]ユーザ入力のためにキーパッド８６０を含むことができる。キーパッド８６０は物理キーボードでもよいし、またはタッチスクリーンディスプレイ８５５上に生成されるソフトキーパッドでもよい。いくつかの実施形態では、ディスプレイおよびキーパッドが組み合わされている。いくつかの実施形態では、オーディオインタフェース８４０およびビデオインタフェース８４５を含む２つ以上の入出力（Ｉ／Ｏ）コンポーネントが組み合わされてもよい。それぞれの入出力コンポーネントに個別のプロセッサが含まれてもよいし、または処理機能がプロセッサ８０５に組み込まれてもよい。

[0245]ディスプレイ８５５は、グラフィカルユーザインタフェース（ＧＵＩ）要素、コンテキスト予測ツールバーユーザインタフェース、テキスト、画像、動画、通知、仮想ボタン、仮想キーボード、メッセージングデータ、インターネットコンテンツ、デバイス状態、時刻、日付、カレンダデータ、お気に入り、地図情報、位置情報、およびその他の、視覚形式で提示可能な任意の情報を提示してもよい。いくつかの実施形態では、ディスプレイ８５５は、任意のアクティブマトリクスまたはパッシブマトリクス技術、および任意のバックライト技術（使用する場合）を利用する液晶ディスプレイ（ＬＣＤ）である。いくつかの実施形態では、ディスプレイ８５５は有機発光ダイオード（ＯＬＥＤ）ディスプレイである。当然ながら、その他のディスプレイタイプも意図されている。

[0246]タッチスクリーン（ディスプレイに関連付けられてもよい）は、タッチの存在および位置を検出するように構成された入力デバイスである。タッチスクリーンは抵抗膜タッチスクリーン、表面弾性波タッチスクリーン、赤外線タッチスクリーン、光イメージングタッチスクリーン、分散信号タッチスクリーン、音響パルス認識タッチスクリーンであってもよく、または、その他の任意のタッチスクリーン技術を利用してもよい。いくつかの実施形態では、タッチスクリーンはディスプレイの上部に透明な層として組み込まれ、ユーザが１回または複数回のタッチを使用して、ディスプレイ上に提示されたオブジェクトまたはその他の情報と対話できるようにする。

[0247]他の実施形態では、コンピューティングデバイスのディスプレイのない表面にタッチパッドが組み込まれていてもよい。例えば、コンピューティングデバイスがディスプレイの上部にタッチスクリーンを有し、ディスプレイの反対側の表面にタッチパッドを有してもよい。

[028]いくつかの実施形態では、タッチスクリーンはシングルタッチスクリーンである。他の実施形態では、タッチスクリーンはマルチタッチスクリーンである。いくつかの実施形態は、タッチスクリーンが個別のタッチ、単一タッチジェスチャ、および／またはマルチタッチジェスチャを検出するように構成されている。便宜上、それらは本明細書では集合的にジェスチャと称される。下記に、いくつかのジェスチャについて説明する。これらのジェスチャは例示を目的とし、添付の特許請求の範囲を制限することを意図しないことを理解されたい。さらに、説明されるジェスチャ、追加のジェスチャ、および／または代替のジェスチャが、タッチスクリーンと共に使用するためのソフトウェアに実装されてもよい。そのように、開発者は特定のアプリケーションプログラムに特有のジェスチャを作成してもよい。

[0249]いくつかの実施形態では、タッチスクリーンはタップジェスチャをサポートする。このジェスチャでは、ユーザがディスプレイ上に提示された項目を１回タップする。タップジェスチャは様々な理由で使用されてもよく、これにはユーザがタップするものを開くか、または起動することが含まれるが、これに限定されない。いくつかの実施形態では、タッチスクリーンはダブルタップジェスチャをサポートする。このジェスチャでは、ユーザがディスプレイ上に提示された項目を２回タップする。ダブルタップジェスチャは様々な理由で使用されてもよく、これには段階的なズームインまたはズームアウト、テキスト内の単語の選択が含まれるが、これらに限定されない。いくつかの実施形態では、タッチスクリーンは長押しジェスチャをサポートする。このジェスチャでは、ユーザがタッチスクリーンをタップし、所定の時間以上接触したままにする。長押しジェスチャは様々な理由で使用されてもよく、これにはコンテキスト固有のメニューを開くことが含まれるが、これに限定されない。

[0250]いくつかの実施形態では、タッチスクリーンはパンジェスチャをサポートする。このジェスチャでは、ユーザがタッチスクリーンに指を置き、タッチスクリーンに接触したまま指をタッチスクリーン上で動かす。パンジェスチャは様々な理由で使用されてもよく、これには複数のスクリーン、画像またはメニューを通って抑制された速度で移動することが含まれるが、これに限定されない。マルチフィンガーパンジェスチャもまた、意図されている。いくつかの実施形態では、タッチスクリーンはフリックジェスチャをサポートする。このジェスチャでは、ユーザがスクリーンを動かしたい方向に指を滑らせる。フリックジェスチャは様々な理由で使用されてもよく、これにはメニューまたはページを水平または垂直にスクロールすることが含まれるが、これに限定されない。いくつかの実施形態では、タッチスクリーンはピンチおよびストレッチジェスチャをサポートする。このジェスチャでは、ユーザがタッチスクリーン上で２本の指（例えば、親指および人差し指）でつまむ動作または２本の指の間を開く動作をする。ピンチおよびストレッチジェスチャは様々な理由で使用されてもよく、これにはウェブサイト、地図、または図の無段階のズームインおよびズームアウトが含まれるが、これに限定されない。

[0251]上記のジェスチャは、ジェスチャを行うために１本または複数の指を使用する場合について説明したが、つま先、鼻、あごなどのその他の体の部分、またはスタイラスペンなどの物を使用してタッチスクリーンと対話してもよい。そのように、上記のジェスチャは例示を目的とし、決して限定的と判断されてはならないことを理解されたい。

[0252]システム８００を実装する、どのモバイルコンピュータデバイスまたはデスクトップコンピュータデバイスでも、記載されたものより多くの、または少ないフィーチャまたは機能性を有してもよく、本明細書に記載される構成に限定されないことを理解されたい。

[0253]例えば、いくつかの実施形態では、ユーザインタフェースおよび各種の情報を壁面に投影して、その壁面上で表示および対話が行われてもよい。
[0254]様々な実装では、システム８００を介して保存されるデータ／情報には、デバイスでローカルに保存されるデータキャッシュを含んでもよいし、または無線／ネットワークインタフェース８３５を介して、または、デバイスとそのデバイスに関連する別体のコンピューティングデバイスとの間の有線接続を介して、デバイスによってアクセスされてもよい任意の数のストレージ媒体にデータが保存されてもよい。デバイスに関連するコンピューティングデバイスは、例えば、インターネットなどの分散コンピューティングネットワーク内のサーバコンピュータなどである。そのようなデータ／情報は、無線インタフェース８３５または分散コンピューティングネットワークを介してデバイスによってアクセスされてもよいことが理解されよう。同様に、そのようなデータ／情報は、電子メールおよび共同作業に関するデータ／情報共有システムを含む、よく知られたデータ／情報の伝送および保存手段に従って、容易にコンピューティングデバイス間で伝送され、保存および使用されることがある。

[0255]本明細書で説明する一定の技法は、１つまたは複数のコンピューティングデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能な命令の一般的な文脈で記載されている。一般に、プログラムモジュールはルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含み、これらは特定の仕事を行うか、または特定の抽象データ型を実装する。

[0256]複数の実施形態はコンピュータプロセスとして、コンピューティングシステムとして、または、コンピュータプログラム製品またはコンピュータ可読媒体などの製造者製品として実装されてもよい。本明細書に記載される一定の方法およびプロセスは、コードおよび／またはデータとして具体化され、１つまたは複数のコンピュータ可読媒体に保存されてもよい。本発明の一定の実施形態では、実行されると前述した方法論の１つまたは複数をシステムに行わせる１組の命令を内部に有するコンピュータシステムの形の機械を使用することが意図される。一定のコンピュータプログラム製品は、コンピュータシステムによって読み取られる１つまたは複数のコンピュータ可読記憶媒体であって、コンピュータプロセスを実行するための命令から成るコンピュータプログラムが符号化されている。

[0257]コンピュータ可読媒体は、入手可能な任意のコンピュータ可読記憶媒体または、コンピュータシステムからアクセス可能な通信媒体であることができる。
[0258]通信媒体には、例えば、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータなどを含む通信信号を、１つのシステムから別のシステムに伝送する媒体が含まれる。通信媒体は、ケーブルおよびワイヤ（例えば、光ファイバ、同軸ケーブルなど）などの誘導された伝送媒体および、音波、電磁気、ＲＦ、マイクロ波および赤外線などのエネルギー波を伝播させることのできる無線（誘導なしの伝送）媒体を含むことができる。コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータは、例えば、搬送波または、スペクトル拡散技法の一部として使用される類似の機構などの無線媒体に変調データ信号として具体化することができる。「変調データ信号」という用語は、その信号の特性のうち１つまたは複数が、信号内の情報の符号化に関する１つの様式で変更または設定されている信号を指す。変調は、アナログ、デジタルまたは混合変調技法であってもよい。通信媒体、特にコンピュータシステムによって使用可能なデータを含むことのある搬送波および他の伝播信号は、コンピュータ可読記憶媒体には含まれない。

[0259]制限ではなく例として、コンピュータ可読記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータなどの情報の保存のための任意の方法または技術に実装された、揮発性および不揮発性の、取り外し可能および取り外し不可能な媒体が含まれ得る。例えば、コンピュータ可読記憶媒体には、ランダムアクセスメモリ（ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ）などの揮発性メモリおよびフラッシュメモリなどの不揮発性メモリ、様々な読出し専用メモリ（ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ）、磁気および強磁性／強誘電性メモリ（ＭＲＡＭ、ＦｅＲＡＭ）、ならびに、磁気および光記憶デバイス（ハードドライブ、磁気テープ、ＣＤ、ＤＶＤ）またはその他の、コンピュータシステムによる使用のためにコンピュータ可読情報／データを保存することのできる、現在知られている、または将来開発される媒体が含まれるが、これらに限定されない。

[0260]さらに、本明細書に記載される方法およびプロセスはハードウェアモジュールに実装することができる。例えば、ハードウェアモジュールには、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、およびその他の、現在知られている、または将来開発されるプログラム可能論理デバイスが含まれるが、これらに限定されない。ハードウェアモジュールが起動されると、そのハードウェアモジュールは、そのハードウェアモジュール内に含まれている方法およびプロセスを行う。

[0261]本仕様で「一実施形態」、「ある実施形態」、「例示的実施形態」などは、その実施形態に関連して記載される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。本仕様内の様々な場所に記載されているそのような局面は、必ずしもすべて同じ実施形態に関するものではない。さらに、本明細書に開示されるどの発明または実施形態のどの要素または制限も、他の要素または制限のいずれかまたはおよび／もしくはすべてと（個別または任意の組み合わせで）、または本明細書に開示される他のどの発明もしくは実施形態とも組み合わせることができ、それらの組み合わせのすべてが、本発明の範囲に関して無制限に意図されている。

[0262]本明細書に記載される例および実施形態は、単に例示することが目的であり、それに照らした様々な修正または変更が当業者に提示されることが理解され、本願の趣旨および範囲に含まれることが理解される。

Claims (10)

1. 第１の文書の第１のビューを表示するステップであって、前記第１の文書が第１のアドレスを通してアクセス可能である、ステップと、
   前記第１の文書の特定されたコンテンツの第２のアドレスを要求するためにアドレスサービスを呼び出すステップと
   を含む方法。
2. 前記第２のアドレスのユニフォームリソースロケータ（ＵＲＬ）を受信するステップをさらに含み、前記ＵＲＬが前記特定されたコンテンツのマスター文書にアクセスする、請求項１に記載の方法。
3. 前記特定されたコンテンツが、段落識別子、行識別子、文字識別子、範囲、および部分識別子のうち少なくとも１つなどの位置識別子を使用して特定される、請求項１に記載の方法。
4. 前記第１の文書の前記特定されたコンテンツへの修正をマスター文書に統合するよう要求するために統合サービスを呼び出すステップをさらに含み、前記マスター文書が随意に前記第２のアドレスに位置する、請求項１に記載の方法。
5. 文書を閲覧するための方法であって、
   少なくとも第１のコンテンツブロックの第１のアドレスおよび第２のコンテンツブロックの第２のアドレスを含む要求と共にアクセスサービスを呼び出すステップと、
   少なくとも前記第１のアドレスおよび前記第２のアドレスからの前記第１のコンテンツブロックおよび前記第２のコンテンツブロックが組み合わされたコンテンツを含む文書ビューを受け取るステップと
   を含み、
   前記組み合わされたコンテンツの各ブロックが段落識別子、行識別子、文字識別子、範囲、および部分識別子のうち少なくとも１つなどの位置識別子を含んでおり、前記位置識別子が前記アクセスサービスによる個別の取り出しのためにアドレスを割り当てられることが可能である、方法。
6. 前記第１のアドレスまたは前記第２のアドレスに保管されているコンテンツへの修正が前記文書ビューに反映される、請求項５に記載の方法。
7. 前記第１のコンテンツブロックが前記第１のアドレスを含む第１のユニフォームリソースロケータ（ＵＲＬ）を通してアクセス可能であり、前記第２のコンテンツブロックが前記第２のアドレスを含む第２のＵＲＬを通してアクセス可能である、請求項５に記載の方法。
8. 前記組み合わされたコンテンツの前記コンテンツブロックのうち少なくとも１つと関連し、任意でバージョン情報を含む履歴データを受け取るステップをさらに含む、請求項５に記載の方法。
9. 複数のコンテンツブロックを含む文書ビューであって、
   前記コンテンツブロックが、
   段落識別子、行識別子、文字識別子、範囲、および部分識別子のうち少なくとも１つなどの位置識別子と、
   少なくとも２つのユニフォームリソースロケータ（ＵＲＬを使用して取り込まれたコンテンツとを含み、
   新しいＵＲＬを割り当てて、その新しいＵＲＬを通して個別にアクセス可能であるために、随意に、少なくとも２つのＵＲＬを使用して取り込まれた複数のコンテンツブロックのうち１つまたは複数のコンテンツブロックが選択可能である、
   文書ビュー。
10. 少なくとも２つのＵＲＬを通してアクセスされるリソースに保管されているコンテンツへの修正が文書ビューに反映される、請求項９に記載の文書ビュー。