JP2010539605A

JP2010539605A - データ主導型の同期

Info

Publication number: JP2010539605A
Application number: JP2010525039A
Authority: JP
Inventors: アール．デイビスダレン; シー．トーマスマイロン; アール．クラークマイケル
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2007-09-14
Filing date: 2008-09-12
Publication date: 2010-12-16
Also published as: CN101802815A; WO2009036345A2; CN101802815B; US20090077138A1; US8185494B2; EP2201479A2; EP2201479A4; WO2009036345A3

Abstract

同期が、特定のアプリケーションおよび／またはエンドポイントではなく、データおよび場合によっては１組の同期動作に制約される。その結果として、エンドポイント間で同期するには、カスタマイズした同期ソリューションを作成する必要がなく、ベンダおよび／またはアプリケーション固有の機構に依存する必要もない。１つの事例では、エンドポイントにわたる同期を動的に構成するために、標準的なデータおよび／または同期スキーマに参加するかそれらを利用することができる。

Description

今日では、２つの一般的なモデル、即ち、データ・リポジトリをある場所から別の場所へ複製すること、またはホスト・ストアとクライアント・ストアとの間でデータを転送すること、のうち一方を利用して２つのエンドポイント間でデータを同期するアプリケーションが数多く存在している。第１の場合の古典的な例は、データベースをデータベース・クラスタにわたって、またはウェブ・ベースのホストとクライアント・ベースのアプリケーションとの間で複製するものである。このモデルの要点は、参加者の間で明確にされているパターンで、データが転送されていることである。これらの参加者は、一般的にはソフトウェア開発の視点からデータ管理システムによって完全に制御される。第２の場合は、この文脈ではストア間同期と称するが、かなり脆弱である。なぜなら、この場合、一般的には、データセット内の項目に対して同一レベルのサポートを行わないエンドポイント間でデータが転送されるからである。デスクトップ・コンピュータと、携帯電話またはポータブル・メディア・プレイヤのようなポータブル装置との間の同期が古典的な例である。

ストア間同期の課題に対処するために、従来のソリューションでは、ホスト装置およびクライアント装置を接続するカスタムプロトコルの上にアプリケーション・スタックを生成する。一般的には、同期スタックのベンダがまた、ホスト装置およびクライアント装置の両方に対して１つまたは複数の同期プロバイダを記述して、このルート（conduit）が電子メール・プログラムのようなアプリケーションからデータを運搬できるようにする。例えば、これらのプロバイダがデスクトップ・コンピュータおよびポータブル装置の両方にインストールされると、コンジットを通した同期が可能となる。勿論、このソリューションが及ぶ範囲は、スタックのベンダがどれくらい作業を実施する意思があるかに依存する。例えば、スタックのベンダがホスト上の特定のデータソースをサポートしない場合は、そのデータソースからのコンテンツをクライアントに同期することはできない。

スタックのベンダが、システムをサードパーティに対して利用可能にし、そのサードパーティもパイプの両端で動作するプロバイダを作成し、それにより広範囲の同期エコシステムを促進できるようにすることがある。それでも、ルート（conduit）の全ての態様がスタックのベンダによって記述されるので、ソリューションは特定のベンダに固定され、ベンダがスタックを利用可能とする場所に限定されてしまう。

最終的には、自身のアプリケーションを任意のポータブル装置と同期するためのソリューションを出荷したい大多数のベンダ、またはアプリケーションの同期をサポートしたいポータブル装置の製造者は、サードパーティのソリューションを購入するか、独自のソリューションを開発するか、または単にこのような機能を提供しない、と決定することになる。

以下で、開示した主題の幾つかの態様の基本的な理解を与えるために簡略化した概要を提示する。本発明の概要は広範囲な概要ではない。本発明の概要は、クレーム主題の主要または重要な要素を特定しようとするものではなく、クレーム主題の範囲を区別しようとするものでもない。その唯一の目的は、後述のより詳細な説明に対する前置きとして幾つかの概念を簡略化した形で提示することである。

簡潔に述べると、本開示はデータ主導型の同期に関する。アプリケーションおよび／またはエンドポイントに制約されない広範囲な同期システムおよびその関連する方法を提供する。一のベンダからの専用のコードが同期パイプの両側で要求されるアプリケーション・スタックまたはサイロ・ベースのアプローチではなく、データセットおよび／またはデータセットのソースにわたって同期を実現するために情報をどのように交換するかを定義するモデル・ベースのアプローチを提示する。このようにして、任意のソースを任意の相手先（destination）と同期することができる。

本開示の一態様によれば、エンドポイントが参加する同期モデルの関数として、同期化を実施することができる。同期モデルは、データ、およびそのデータを同期のために特定のプロトコルを用いてどのように交換できるかを定義する。エンドポイントは、データ同期に関する通信および／または対話を可能とする、具体的な同期モデルを確立するために交渉を行う。続いて、同期コンポーネントを、同期およびデータ交換に関する指定された動作（behavior）を実装するように構成することができる。

前述の目的および関連する目的を達成するために、本明細書では、クレーム主題の幾つかの例示的な態様を以下の説明および付属の図面に関連して説明する。これらの態様は、主題を実践できる様々な方法を示すものであり、その全てはクレーム主題の範囲内にあることを意図している。他の利点および新規な特徴は、図面と関連して考慮すると、以下の発明を実施するための形態から明らかになろう。

開示した主題の態様に従うデータ主導型同期システムのブロック図である。データ同期を可能とする代表的な同期コンポーネントのブロック図である。代表的なデータ・スキーマ・コンポーネントまたはその出力のブロック図である。代表的な同期モデルコンポーネントもしくは同期スキーマ・コンポーネントまたはそれらの出力のブロック図である。開示した主題の態様に従って２つのエンドポイント間でデータを同期するためのシステムのブロック図である。開示した主題の態様に従う同期モデルのブロック図である。開示した主題の態様に従うデータ同期方法のフローチャート図である。開示した主題の態様に従う同期方法のフローチャート図である。開示した主題の態様に従う、データスキーマを利用した同期方法のフローチャート図である。本開示の態様に従う、データおよび同期スキーマを利用した同期方法のフローチャート図である。本開示の態様に適した動作環境を示す略ブロック図である。例示的なコンピューティング環境の略ブロック図である。

以下に、ソースおよびデスティネーションに対する非依存性を実現するデータ同期システムおよびデータ同期方法を示す。その結果として、アプリケーションおよびエンドポイントは、アプリケーションおよび／またはエンドポイントに固有なソリューションに制約されることなく同期機能を行うことができる。寧ろ、同期はデータおよび１組の同期動作に制約される。より具体的には、同期を、データスキーマの関数として実施し、同期モデルを用いて最適化することができる。リッチだが基礎的な通信プロトコルの上に追加の層を構築し、この追加の層を使用してデータおよび同期のためにどのようにそのデータを交換するかを定義する。さらに、異なるストアおよび／または異なるエンドポイントにわたって最適な同期を動的に構成するために、データスキーマおよび同期モデルを任意のソースと任意のデスティネーションとの間で交渉することができる。

ここで、本開示の様々な態様を付属の図面を参照して説明する。図面全体を通して、同じ番号は同じ要素または対応する要素を指す。しかし、当然のことながら、図面およびそれに関連する詳細な説明は、クレーム主題を開示した特定の形に限定しようとするものではない。寧ろ、クレーム主題の精神および範囲の中にある全ての修正物、等価物および変形物を網羅しようとするものである。

最初に図１を参照して、クレーム主題の態様に従うデータ主導型の同期システム１００を提供する。システム１００は、（Ｎを１より大きい整数として、１からＮの）幾つかのデータセット１１２の間の通信を可能とするコンジット・コンポーネント１１０を含む。例として、コンジット・コンポーネント１１０は、情報をデータセット１１２から取り出すことができるデータ転送機構またはデータ転送プロトコル（例えば、ＭＴＰ（ＭｅｄｉａＴｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ））に対応し、それらを含み、且つ／または実装することができる。データセット１１２を、とりわけモバイル装置、デスクトップ・コンピュータ、サーバのような複数の関連するエンドポイントまたは装置内に埋め込むことができる。コンジット・コンポーネント１１０は、同期コンポーネント１２０と通信可能に結合されており、同期コンポーネント１２０へデータを提供するように動作可能である。同期コンポーネント１２０は、コンジット・コンポーネント１１０を使用して、複数のデータセット１１２の同期を容易にする。以下にさらに説明するように、ホストおよびクライアントとして特定したエンドポイントの間で同期を実施することができる。この場合、ホストが１つまたは複数のクライアントにわたって同期を実行することができる。

クレーム主題の一態様によれば、システム１００は、関連するアプリケーションおよび／またはエンドポイントに制約されずにデータセット１１２を同期することができる。換言すれば、データ同期は、関連するアプリケーションまたは装置のベンダによって提供される機能に限定されない。そうではなく、同期はデータ主導であるか、またはデータによって、場合によっては一連の同期動作によって、制約される。

ストアがデータセット内の項目に対して同じレベルのサポートを含まない（例えば、忠実度が失われる）ストア間同期のシナリオにおいて一般的に使用される、従来のサイロ式同期システム（ｓｉｌｏｓｙｎｃｈｒｏｎｉｚａｔｉｏｎｓｙｓｔｅｍ）を考える。このシステムでは、プロバイダは、サイロの上および底に挿入して全ての必要な同期機能がそれらの間で必ず行われるようにできるコードを提供する。コードは両側（例えば、ソースおよび相手先）で実行されているので、全ての忠実度の問題が必ず正確に処理されるようにすることはプロバイダの責任である。

従来のシステムには幾つかの問題がある。第１に、汎用的なアプリケーションは、データを係るアプリケーションにわたって同期する目的で同期サイロの作成者に振り回される。さらに、またはあるいは、エンドポイントは所与の同期サイロによって同様に制約される。それに応じて、カスタム同期ソリューションを開発することができるか、または同期を提供しないとすることができる。ここで、システム１００は、ソースのアプリケーションおよびデスティネーション（destination）に対する非依存性を実現する、データ同期機構を提供する。その結果として、アプリケーションおよび／またはポータブル装置のベンダは、自身の独自のソリューションを作成したりまたは制限付きのソリューションにライセンスを与えるのではなく、所望の機能をより低コストで提供する機会が得られる。

以下のさらなる説明に照らして理解されるように、リッチなレベルのアプリケーションの独立性および／またはエンドポイントの独立性を実現し幾つかの異なるベンダからの強力なサポートを促すために、共通の明確な標準化ソリューションを使用することができる。さらに、様々なアプリケーションおよび／またはエンドポイントを扱うために、伝統的に構築されたサイロ式同期スタックをモデルとして検討することは一般に不適切である。あるいは、同期されているアプリケーションおよび／またはエンドポイント（例えば、サイロの上および底）に着目するのではなく、リッチな同期エクスペリエンスを可能とするための、エンドポイントが通信する方法（例えば、サイロの中央）に着目して同期を行うことができる。一実装形態では、標準化された通信機構を提供して、リッチな同期オプションを提供するようにサイロの上および底での発展を促すことができる。

図２に注目すると、クレーム主題の態様に従う代表的な同期コンポーネント１２０が示されている。この同期コンポーネントはデータ分析コンポーネント２１０および更新コンポーネント２２０を含む。これらの２つのコンポーネント２１０および２２０は基本的な同期機能の責務を負う。より具体的には、データ分析コンポーネント２１０は複数のデータセットを分析して、これらのデータセットを同期するために、変更が必要ならば、これらのデータセットをどのように変更する必要があるかを判定する。更新コンポーネント２２０は、データ分析コンポーネント２１０によって提供される分析結果の関数としての１つまたは複数のデータセットの変更を、容易にする。

さらに、同期コンポーネント１２０は、データ分析コンポーネント２１０に影響を及ぼすデータ・スキーマ・コンポーネント２３０および同期モデル／同期スキーマ・コンポーネント２４０を含む。データ・スキーマ・コンポーネント２３０は、交換すべきデータを定義する。同期モデルコンポーネント２４０（本明細書では、同期スキーマ・コンポーネントとも称する）は、同期のためにデータをどのように交換すべきかを規定する。換言すれば、データスキーマおよび同期スキーマをデータ分析コンポーネント２１０に提供してその動作をカスタマイズすることができる。特に、このようなスキーマは、どのデータを交換するか、および複数のデータセットを同期するためにそのデータをどのように交換するか、を制御することができる。

１つの事例では、データ・スキーマ・コンポーネント２３０および同期モデルコンポーネント２４０は、データ分析コンポーネント２１０に提供するためのスキーマを、例えばウェブサイトまたは他のネットワーク・ロケーションから取得することができる。あるいは、コンポーネント２３０および２４０はスキーマ自体に対応することができる。何れの場合でも、スキーマを、複数の異なる方法で記述することができる。この方法には、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）またはコンパイル時に生成したバイナリ構造が含まれるがこれらに限らない。

図３は、クレーム主題の態様に従う代表的なデータ・スキーマ・コンポーネント２３０またはその出力を示す。データセットは、同期に関して、同じ忠実度情報または同じレベルの忠実度を常に含むとは限らない。例えば、ＰＩＭ（ｐｅｒｓｏｎａｌｉｎｆｏｒｍａｔｉｏｎｍａｎａｇｅｒ）アプリケーションに関連付けられたモバイル装置のストアは、一般的に、特にアプリケーションが異なる製造者によって作成された場合には、デスクトップのストアと同じデータを含まない。この問題を解決するために、コンテンツ・コンポーネント３１０が、同期されるデータを記述することができる。これにより、同期のホストおよびクライアントは同じデータ交換の言葉を話すこと（speak）ができる。

例として、連絡先オブジェクトに関して話す同期ホストは、カレンダ・オブジェクトを話すクライアントと同期できるはずがない。しかし、ホストおよびクライアントの両方が連絡先オブジェクトのような同じコンテンツタイプを話す場合は、ホストとクライアントは同期関係に参加できるはずである。コンテンツタイプとはデータに関する特定の形式を含意すると想定されていることに留意されたい。換言すれば、２つのエンドポイントが両方とも「連絡先」を話すと表明する場合は、それらが同じ連絡先の形式（例えば、姓、名、番地、都市、州、および郵便番号）を参照していると想定されている。これは、厳密に要求されるものではなく、同期を容易にするものである。必要な場合は、異なる形式を特定の標準化された形式および／または公開された形式へマッピングするための変換を実施することができる。

データ・スキーマ・コンポーネント２３０はまた、コンテンツ・コンポーネント３１０によって記述されたデータに関連付けられた、変更単位を特定するための変更コンポーネント３２０を含む。同期のホストおよびクライアントの両方が同じコンテンツタイプを話すのでデータ同期を実施できる、と単に述べるだけで十分である。それにも関わらず、同期の性能を最大化するためには、変化した最小量のデータのみをあるエンドポイントから別のエンドポイントへ転送すべきである。幾つかの場合、データセット内の特定の項目を変更単位として分離することは意味がある。なぜなら、それらの項目は頻繁に変化する傾向にあり、他の項目はグループ化されればより効率的に管理できるからである。例えば、電子メール・アドレスは頻繁に変化することがあり、そういうものとして別々の変更単位として指定することができる。一方で、番地、都市、州、および郵便番号を含む物理的なアドレスは、単一の変更単位としてグループ化することができる。

図４は、クレーム主題の態様に従う代表的な同期モデル／同期スキーマ・コンポーネント２４０またはその出力を示す。前述のように、同期モデルコンポーネント２４０は、同期を実現するためにデータをどのように交換するかを特定する。代表的なコンポーネント２４０は、状態コンポーネント４１０および変更検出コンポーネント４２０を含む。

状態コンポーネント４１０は、同期の現在状態をコンテンツタイプと独立して記述するためのモデルである。以下の動作を示した順序で実施する汎用的な同期動作を考える。
１．最後に第２のエンドポイントと同期動作をしてから第１のエンドポイントで何が変更されたかを判定する。
２．第２のエンドポイント上のオブジェクトを調べることにより、第１のエンドポイントに存在する変更を第２のエンドポイントが既にもっているかどうかを判定する。
（ｉ）データが同じならば、変更を無視する。
（ｉｉ）データが同じでなく、一方のみが変更された場合、直近の変更を一方から他方に同期する。
（ｉｉｉ）データが同じでなく、変更単位が両方で変更されている場合、２つの変更の間の衝突を解決するための何らかの形のビューワを使用する。
３．変更を第１のエンドポイントから第２のエンドポイントへコピーする。
エンドポイント上の同期状態に関するリッチな情報がなければ、一般的には、動作２を実施するための唯一の方法は、（動作１からの）変更セット内の各項目を列挙し、変更されたものを発見し、対応する項目を第２のエンドポイント上で見つけ（これは、共通の同期ＩＤが共有されていない場合は、列挙して一致を探すように性能が低下する）、変更単位内のプロパティの各々を調べてそれらが異なっているかどうかを見ることである。単純なプロパティまたはデータセットの場合は、この比較は性能上の問題とはならないであろうが、大規模なプロパティまたはデータセットの場合は、この比較は非常にコストのかかるものになる。同期の現在状態を導入することによって、図２のデータ分析コンポーネント２１０は、変更を行う必要があるかどうかを直接判定するために、オブジェクトではなく状態ストアに問い合わせることができる。

変更検出コンポーネント４２０は、変更を一方または他方で特定する方法を記述する。変更の特定には多数の可能性が存在する。例えば、どちらのエンドポイントが同期動作を駆動していても、総列挙モデルを利用して別のストアに十分問い合わせることができる。アンカーベースのアプローチでは、ストアは変更または差分を管理するかまたは実際に提供しなければならないが、これらの差分は同期動作を行うのに最適な形態または言語ではないことがある。あるいは、アンカーベースのモデルと同様に、とりわけ同期メタデータを管理する方法に関して最適または実質的に最適である方法で差分を提供することができる。さらに、サービスモデルでは、全てのものを一まとめにして、全ての作業を行って結果を返すサービス（例えば、ウェブサービス）に、送信することができる。

同期モデルコンポーネント２４０はまた、同期をさらに容易にする識別子コンポーネント４３０およびバージョンコンポーネント４４０を含む。識別子コンポーネント４３０は、オブジェクトのようなデータのコレクションに対するコンテキスト固有の識別子を提供する。識別子を用いずにオブジェクトを見つけるコストは非常に高い可能性がある。識別子を追加することで、追加のデータを比較する必要なしに、参照されているオブジェクトが同じであるとより容易に認識することができる。当然のことながら、係る同期識別子またはＩＤは、既存のスキーマ内の特定の列であることができるか、または提供されたデータに基づいてＩＤを決定するためのマッピング関数を必要とする。

バージョンコンポーネント４４０は、オブジェクトのような各データ構造体に関連付けられた各変更単位のバージョンに関する情報を交換するための、コンテンツタイプに依存しない共通の形式を記述する。バージョンを導入すると、データの比較ではなくバージョンの比較を通じて、同期動作の両側において変更が加えられたかどうかを判定するプロセスが大幅に簡略化される。バージョンをもつことは、少なくとも２つの概念を含意する。第１に、バージョン情報に対する共通の形式が存在する。第２に、この形式を、オブジェクトベースごとに変更単位の粒度（granularity）で、同期クライアントのエンドポイントに記憶しそのエンドポイントから取り出すことができる。

図５は、クレーム主題の態様に従って２つのエンドポイント間でデータを同期するためのシステム５００を示す。システム５００はエンドポイント５１０および５２０を含む。とりわけ、エンドポイント５１０および５２０は、２つのモバイル装置か、モバイル装置とデスクトップ・コンピュータまたはサーバ、に対応することができる。各エンドポイントは、同期コンポーネント１２０を利用して同期できるローカルのデータストア５１２からなる。

各同期コンポーネント１２０は、同期プロトコルについて交渉し、且つ／または同期関係を確立するための交渉コンポーネント５３２を含む。とりわけ、ＣＯＭベースのオブジェクト交換インタフェースまたはＭＴＰ（ＭｅｄｉａＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）のようなデータ転送プロトコルが、エンドポイント通信に対する基礎としての役割を果たすことができる。交渉コンポーネント５３２は、同期に関する具体的な規則または手続きの識別を容易にする。従って、同期モデルを、所望の同期のリッチさをサポートする他の通信プロトコルの上に構築することができる。

同期プロトコルの交渉は本質的に動的である。固定または硬直した通信方式および１組のインタフェースを同期のために利用するのではなく、従来と同様に、エンドポイントがプロトコルまたは関係を交渉することができる。エンドポイントが対話に現れると、同期に関してエンドポイントが通信する方法を、とりわけ能力および／または優先度の関数としてその時点で決定することができる。

同期プロトコルが交渉コンポーネント５３２を介して確立されると、同期コンポーネント１２０を、特定の方法で対話するように構成コンポーネント５３４で構成することができる。従って、同期コンポーネント１２０は、具体的な事前にプログラムされた同期動作に依存するのではなく、モデルに従って同期を実装するように適応可能または構成可能な汎用機能を備えることができる。

交渉および以後の構成は、エンドポイント５１０および５２０が参加する１つまたは複数のスキーマ５４０に依存することができる。一の態様によれば、スキーマ（複数可）５４０は、例えばＸＭＬ文書のように、公開されたものであることができ、または公開したものとすることができる。スキーマ（複数可）５４０は、データスキーマ５４２のサブコンポーネントおよび同期スキーマ５４４のサブコンポーネントを含むことができる。データ・スキーマ・コンポーネント５４２は、コンテンツタイプおよび関連する変更単位を含む、同期プロセスにおいて交換すべきデータを記述する。同期スキーマ・コンポーネント５４４は、データセットを同期するためにデータをどのように交換するかを記述する。例えば、同期スキーマは、とりわけ、現在の同期状態および変更検出を記述する１つまたは複数のモデルを含むことができる。

エンドポイント５１０および５２０は、交渉および以後の同期の間に異なるタイプの情報を交換することができる。示したように、データのコンテンツタイプまたはデータが従うスキーマの識別に関する情報を交換することができる。エンドポイントがサポートする変更検出モードおよび現在の状態モデルに関する情報も送信される。この情報を利用して、エンドポイント間の同期を構成することができる。オブジェクトまたは他のデータ構造体を、必要ならばエンドポイント５１０と５２０との間で交換することができる。さらに、装置上での実行を容易にするための、命令または動作を渡すことができる。

同期の効率は、少なくとも部分的には、各エンドポイントが同期動作に参加できるレベルに依存することができる。エンドポイントは、同期動作に参加するためにコンテンツタイプおよび変更情報の粒度を定義するデータスキーマを特定するだけでよい。エンドポイントがこの情報を提供するだけであった場合、他のエンドポイントがそれ自体のために限られたエンドポイント内の項目を列挙し、変更を発見し、変更を適用することができる同期ソリューションを生成することが可能である。反対に、例えば、２つのエンドポイントが状態情報に基づいて独立に変更を特定しどの変更を転送すべきかを判定できる場合は、その２つのエンドポイントは変更のみを交換することができる。ここで、その同期は高速且つ効率的であるはずである。なぜなら、転送される余分なデータの量は同期動作ではなく変更単位の定義によって制約されるからである。これらの２つの場合の間には、幾つかの混成型のモデルが存在する。各エンドポイントが同期関係に参加できるためには、各エンドポイントは、それが別のエンドポイントに要求するものに対して独自の能力を定義して、可能な限り効率的に動作する同期パートナーシップを生成できるようにすべきである。

開示した主題の一態様によれば、スキーマ（複数可）５４０を標準化することができる。データまたはオブジェクト形式および関連する同期機構を標準化することによって、任意のソースから任意のデスティネーションへの標準化を有効にすることができる。開発者、製造者、ベンダ等は幾つかのデータおよび／または同期スキーマに合意して、より広範囲な同期実施方法を可能とすることができる。例えば、標準的な連絡先オブジェクトは、姓、名、番地、州、都市、および郵便番号に関するフィールドを含むことができる。全てまたは多くのベンダ等がこの形式を連絡先オブジェクトに対して利用すれば、種々のアプリケーションおよび／またはアーキテクチャにわたって係るオブジェクトを同期できるはずである。

同期関係に参加するために追加のスキーマ項目を表現することができる。標準化されたソリューションを開発する際の最も大きな課題の１つは、交換すべき項目の領域に関して合意することになりつつある。同期関係に参加したい全ての者の定義を満足するデータスキーマを定義できると考えるのではなく、スキーマが、例えばカスタム同期モデルをサポートするために新しい項目を追加できるようにする拡張性をサポートすることができる。例えば、ビジネス連絡先マネージャはインスタントメッセージングアドレスの概念をもつことはできない。なぜなら、インスタントメッセージングは一般的にはビジネス通信では使用されないからである。しかし、消費者に着目した連絡先マネージャは一般的に係るフィールドを含む。連絡先に関する元のデータスキーマが係るフィールドなしに定義されていた場合は、消費者指向のバージョンが、標準的なスキーマおよびインスタントメッセージングフィールドの追加をそれがサポートすることを示すことができることにより、インスタントメッセージングフィールドを理解する他のアプリケーションがインスタントメッセージングフィールドと同期することができる。さらに、幾つかのクライアントを、インスタントメッセージングフィールドのような追加の同期要素を実際にそのフィールドを理解することなく運搬できる、データ・タクシー（ｄａｔａｔａｘｉｓ）として構成することができる。

さらに当然のことながら、データ転送機構、または同期プロトコルの１つもしくは複数の態様を、標準化プロセスを介してより強く定義できる。例えば、デスクトップコンピュータプラットフォームは、異なる同期コンポーネントを、その両方が同じスキーマ（複数可）５４０をサポートすることを示すためにどのように登録できるかに関する特定のモデルを定義することができる。このモデルにおいては、変更検出および状態管理の概念を、最適な交換パターンを可能とするように強く定義することができる。しかし、個々のオブジェクトに対してデフォルトのデータ転送機構を定義することによって基本レベルの相互運用性を強制できる一方で、このシステム内の２つのエンドポイントが、追加のスキーマ項目の共通知識またはよりリッチなデータ転送モデルに基づいてよりリッチなデータ交換パターンを交渉することも依然として可能であるはずである。

このモデルにはまた、プロキシエージェントを導入できるという利点がある。図１に戻ると、コンジット・コンポーネント１１０が多数のデータセット１１２に結合できることを述べた。交換パターンがデスクトップに対して固定されているシステムにおいては、説明したデスクトップシステム内で同期するために、複数のデータセット１１２からデータを引き出すことができるデータ非依存のプロキシコンポーネント５１４を導入することができる。複数のデータセット１１２は、潜在的に、異なる１組のスキーマ（複数可）５４０を代表するものである。示したように、データストア５１２は、直接的にまたはプロキシコンポーネント５１４を介して、同期コンポーネント１２０と選択的に結合することができる。

図６は、クレーム主題の態様に従うプログラム的な同期モデル６００を示す。モデル６００は、１つまたは複数のコンポーネントを介して実装された場合に、関連付けられたアプリケーションおよび／またはアーキテクチャによって制約されない、複数のエンドポイントに記憶されたデータの同期を可能とする機能のグループを広範囲に定義する。底から始めて上へと、モデル６００はデータ転送層６１０、同期スキーマ層６２０およびデータスキーマ層６３０を含む。

データ転送層６１０はエンドポイント間の通信を可能とする。限定ではなく例として、オブジェクトならびに様々な他の装置およびコンテンツ情報の交換を可能とする、ＣＯＭインタフェースまたはＭＴＰのようなリッチな通信プロトコルを利用することができる。このように、層６１０はエンドポイントまたはエンドポイントの装置にわたるデータ交換に関する基礎または基盤を提供する。

次の層は、同期の実現に関してデータ交換を定義する同期スキーマ層または同期モデル層６２０である。即ち、層６２０は、原始的なデータ転送層６１０上で交換されるデータに関する、追加の有向な同期制約を提供する。様々なデータ交換モデルおよびデータ交換機構を同期スキーマ層によって定義および／またはサポートすることができる。例えば、同期層６２０は現在の状態を記述するためのコンテンツタイプ独立のモデル、データ構造体に対するコンテンツ固有の識別子、変更単位ごとにバージョン情報を交換するためのコンテンツタイプ独立の形式、同期関係に参加するための追加のスキーマ項目を表現するための方法、オブジェクトスキーマ内の特定の項目を維持できる忠実度を示すための方法および／または各エンドポイントが同期動作に参加できるレベルを示す方法、を提供することができる。

最後に、データスキーマ層６３０は同期動作において交換すべきデータを記述する。これには、コンテンツタイプまたはオブジェクトスキーマおよび変更単位の粒度を含む、２つの態様がありうる。換言すれば、データの形式およびデータに関連付けられた変更単位である。

モデルの利用に関してさらに明快とすることを支援するため、連絡先データが携帯電話からデスクトップ・コンピュータに同期される同期シナリオを考える。各装置は同期をサポートできるかまたはサポートできない連絡先ストアを含む。装置は、オブジェクト交換プロトコルにわたるオブジェクトスキーマに従って定義されたオブジェクトを交換することができる。オブジェクトの交換の方法は、モバイル装置によって実装される同期スキーマに依存することができる。装置が変更検出モデルおよび／または他の同期機能を実装する場合は、装置は係る機能に従って変更を検出しデスクトップコンポーネントに返すことができる。あるいは、例えば、装置のベンダが係る技術に投資する意思がない場合は、モバイル装置はどのような同期スキーマも実装せず、デスクトップ装置にそれらの同期スキーマを十分に列挙させることはできない。

前述のシステム、アーキテクチャ等を幾つかのコンポーネント間の対話に関して説明した。当然のことながら、係るシステムおよびコンポーネントは、その中で規定されたコンポーネントまたはサブコンポーネント、規定されたコンポーネントまたはサブコンポーネントの一部、および／または追加のコンポーネントを含むことができる。サブコンポーネントを、親コンポーネント内に含まれるのではなく他のコンポーネントに通信可能に結合されたコンポーネントとして実装することもできる。さらに、１つもしくは複数のコンポーネントおよび／またはサブコンポーネントを単一のコンポーネントに結合して集約機能を提供することができる。システム、コンポーネントおよび／またはサブコンポーネントの間の通信をプッシュ・モデルおよび／またはプル・モデルに従って達成することができる。コンポーネントは、本明細書では簡潔さのために具体的に説明していないが、当業者によって知られている１つまたは複数の他のコンポーネントと対話してもよい。

さらに、理解されるように、上で開示したシステムおよび以下で開示する方法の様々な部分は、人口知能、機械学習、または知識ベースもしくはルール・ベースのコンポーネント、サブコンポーネント、プロセス、手段、方法、または機構（例えば、サポート・ベクタ・マシン、ニューラル・ネットワーク、エキスパート・システム、ベイジアン・ビリーフ・ネットワーク、ファジー・ロジック、データ・フュージョン・エンジン、分類器・・・）を含むことができ、またはそれらから成ることができる。係るコンポーネントは、とりわけ、システムおよび方法の一部をより適応的ならびに効率的および知的にするための、ある特定の機構またはそれによって実施される処理を自動化することができる。限定ではなく例として、係る機構を同期プロトコルの交渉および／または同期コンポーネントの構成に関して使用することができる。例えば、エンドポイントの能力および／または優先度を、暗黙的または明示的に収集した装置タイプまたは他のコンテキスト情報およびそれらに従って構成した同期の関数として、推論することができる。

上述した例示的なシステムを考慮すると、開示した主題に従って実装できる方法が図７から図１０のフローチャートを参照してより良く理解されよう。説明の簡潔さのため、本方法は一連のブロックとして図示および説明されるが、当然のことながら、一部のブロックを本明細書で図示および説明したものと異なる順序で行うことができ、且つ／または一部のブロックを本明細書で図示および説明したもの以外のブロックと並行に行うことができるので、クレーム主題はブロックの順序によって限定されない。さらに、図示した全てのブロックが、以降で説明する方法を実装する必要はないこともある。

図７を参照すると、クレーム主題の態様に従うデータ同期方法７００が示されている。参照番号７１０で、データを複数のソースから獲得する。７２０で、関連するアプリケーション、エンドポイント、アーキテクチャ、等に制約されずに、ソースを引き続いて同期する。同期されているアプリケーションまたはエンドポイントではなく、同期すべきデータに着目している。換言すれば、同期はデータ主導である。

従来、および前述のように、同期はカスタムなアプリケーション同期ソリューションに限定され、その範囲は限られている。係るソリューションがデータセット内の特定のデータソースまたは要素をサポートしない場合、そのデータを同期することはできない。同期ベンダが自身のシステムをサードパーティに利用可能として、サードパーティが、より広い同期エコシステムを促すためにパイプの端で動作するプロバイダを作成できるようにすることがある。しかし、こうすると同期が特定のベンダに固定され、係る同期の及ぶ範囲が制限される。従って、装置ベンダは同期機能を差し控えるか、または独自のカスタム・ソリューションを生成するコストを負担しなければならない。

方法７００は、或る意味でこれらの要因から独立した、同期に対するかなり広いアプローチを提供する。一実装形態では、データセットにわたる同期を実現するために情報がどのように交換されるかを定義する、プロトコルベースのアプローチが使用される。結果として、参入する上での唯一の障壁は、例えば、サードパーティからライセンスを受けたソフトウェアではなく、単純にプロトコルおよび１組の標準を実装することである。別の言い方をすれば、同期は、特定のアプリケーションまたはアーキテクチャではなく、データおよび１組の同期の動作に制約される。

図８は、クレーム主題の態様に従う同期方法８００のフローチャート図である。参照番号８１０で、例えばＭＴＰ等のような基本通信プロトコルを利用して、データソースを通信可能に接続する。次に番号８２０で、同期プロトコルを交渉する。１つの事例では、これは、幾つかの標準的なまたは事前設定されたスキーマ、モデルおよび／または機構のうちどれが会話において各エンドポイントによって実装されるかを特定すること、およびそれに基づいてデータを効率的に同期するための全体的なモデルを決定することに対応できる。モデルを、エンドポイントのデータソースによってサポートされる最高レベルまたは最もリッチな同期モデルを選択すること、および／またはエンドポイントの優先度およびコンテキスト（例えば、負荷、処理能力・・・）のような追加の情報を利用すること、にのみ基づいて選択することができる。番号８３０で、データを、交渉された通信プロトコルに従って交換し、複数のソースにわたって同期することができる。

図９は、クレーム主題の態様に従う、データスキーマを利用した同期方法９００を示す。番号９１０で、所定のまたは交渉された通信プロトコルを用いて、同期の目的で、データを獲得するか、またはデータにアクセスする。参照番号９２０で、データのコンテンツタイプを決定する。この情報を、データおよび／または外部スキーマに関連付けられたエンドポイントから直接に獲得することができる。一態様によれば、とりわけアプリケーションおよび／またはアーキテクチャから独立したデータ交換を容易にするために、コンテンツタイプを標準化する。例えば、コンテンツタイプは、同期すべき情報の態様を定義する関連するスキーマ文書を伴った、コンテンツオブジェクトまたはメディアファイルであることができる。参照番号９３０で、例えばコンテンツタイプ自体と同じまたは同様な方法で、コンテンツタイプに関連付けられた変更単位を決定する。例として、住所は、番地、都市、州、および郵便番号が常にグループで交換されるように単一の変更単位を備えることができるが、一方で電子メール・アドレスは別々の変更単位であることができる。参照番号９４０で、データスキーマを利用してデータを同期する。例えば、同期するエンドポイントはデータを列挙し、変更を特定し、そのデータに関するそれらの変更を達成することができる。

図１０は、クレーム主題の態様に従う、データおよび同期スキーマを利用したデータ同期方法１０００のフローチャート図である。番号１０１０で、データを獲得するか、またはデータにアクセスする。参照番号１０２０で、例えば、コンテンツタイプおよび変更単位粒度の識別を含むデータスキーマを決定する。番号１０３０で、現在の同期状態を記述するコンテンツタイプ非依存のモデルを決定する。これにより、変更セット内の各項目を分析して変更を発見することを要求するのではなく、状態を比較することによって、同期プロセスを支援することができる。参照番号１０４０で、データのバージョンを変更単位レベルで特定するためのコンテンツタイプ非依存のバージョン形式を決定する。１０５０で、データを比較することなく、オブジェクトのような同じデータ構造体の発見を促進するコンテキスト識別子形式を特定する。番号１０６０で、とりわけ総列挙またはアンカーベースのような、変更識別方法を特定する。とりわけ、動作１０３０から１０６０で決定される全ての情報を、データに関連付けられたエンドポイントから他のエンドポイントに直接的に、または外部スキーマの識別を介して間接的に、通信することができる。さらに、この情報は、複数の標準的なまたは公開されたスキーマ、モデル、タイプ等のうち１つの識別に対応することができる。参照番号１０７０で、データを、データスキーマおよび収集した同期情報に従って同期することができる。例えば、データスキーマに従って定義したデータを、変更検出方法ならびに状態情報、バージョン情報および／または識別子情報に従って変更を決定するために精査し、データが同期されることを保証するために交換することができる。

本明細書で使用するとき、用語「コンポーネント」、「システム」等はコンピュータ関連の実体、即ち、ハードウェア、ハードウェアおよびソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアの何れかを指すよう意図している。例えば、コンポーネントは、プロセッサ上で稼動しているプロセス、プロセッサ、オブジェクト、インスタンス、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであることができるがこれらに限らない。例として、コンピュータ上で稼動しているアプリケーションおよびそのコンピュータはともにコンポーネントであることができる。１つまたは複数のコンポーネントがプロセスおよび／または実行スレッド内部に常住することができ、コンポーネントを１つのコンピュータ上に配置する、および／または複数のコンピュータ間に分散させてもよい。

「例示的」という単語またはその様々な形態は、本明細書では、例、事例、または実例を意味するように使用される。「例示的」として本明細書で説明する任意の態様または設計は必ずしも他の態様または設計に対して好適または有利であると解釈すべきではない。さらに、種々の例は明快さおよび理解の目的で提供されるにすぎず、クレーム主題または本開示の関連部分を限定または制限することは決して意味しない。当然のことながら、範囲が異なる無数の追加の例または代替的な例を提示することもできたが、簡潔さのために省略した。

本明細書で使用する際、用語「推論」または「推論する」は一般にシステム、環境、および／またはユーザの状態を事象および／またはデータを介して得た１組の観測結果から推測または推論するプロセスを指す。推論を使用して、例えば具体的な文脈もしくは動作を特定するか、状態の確率分布を生成することができる。推論は確率的であることができる。即ち、着目する状態の確率分布はデータおよび事象の考察に基づいて計算される。推論はまた、高レベルな事象を１組の事象および／またはデータから構成するために使用される技法を指すことができる。係る推論の結果、事象が時間的に緊密に相関していようとなかろうと、且つ事象およびデータが１つまたは数個の事象およびデータソースから来ようと来まいと、新たな事象または動作は１組の観測した事象および／または記憶した事象データから構築されることになる。様々な分類方式および／またはシステム（例えば、サポート・ベクタ・マシン、ニューラル・ネットワーク、エキスパート・システム、ベイジアン・ビリーフ・ネットワーク、ファジー・ロジック、データ・フュージョン・エンジン・・・）を、本発明と関連して自動的な動作および／または推論した動作の実施に関連して使用することができる。

さらに、本発明の全てまたは一部を、コンピュータを制御して本発明を実装するソフトウェア、ファームウェア、ハードウェア、またはその任意の組合せを製造するための、標準的なプログラミング技術および／またはエンジニアリング技術を用いる方法、装置、または製品として実装してもよい。本明細書で使用する「製品」という用語は、任意のコンピュータ可読装置または媒体からアクセス可能なコンピュータ・プログラムを含むよう意図している。例えば、コンピュータ可読媒体は、磁気記憶装置（例えば、ハード・ディスク、フロッピー・ディスク、磁気ストリップ・・・）、光ディスク（例えば、ＣＤ（ｃｏｍｐａｃｔｄｉｓｋ）、ＤＶＤ（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋ）・・・）、スマート・カード、およびフラッシュ・メモリ装置（例えば、カード、スティック、キー・ドライブ・・・）を含むことができるがこれらに限らない。さらに、当然のことながら、搬送波を、電子メールの送受信またはインターネットもしくはＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ）のようなネットワークへのアクセスに使用されるもののようなコンピュータ可読電子データを運搬するために使用できる。勿論、クレーム主題の範囲または精神を逸脱しない多数の修正をこの構成に加えうることが当業者には認識されよう。

開示した主題の様々な態様に文脈を与えるために、図１１および図１２ならびに以下の議論では、開示した主題の様々な態様の実装に適した環境の簡潔で一般的な説明を与えることとする。上では主題を、１つまたは複数のコンピュータ上で稼動するプログラムのコンピュータ実行可能命令の一般的な文脈で説明したが、本発明を他のプログラム・モジュールと組み合わせて実装してもよいことは当業者には認識されよう。一般に、プログラム・モジュールには、特定のタスクを実施し、且つ／または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造、等が含まれる。さらに、システムまたは方法を、単一のプロセッサ、マルチプロセッサまたはマルチ・コア・プロセッサのコンピュータ・システム、ミニ・コンピューティング装置、メインフレーム・コンピュータだけでなく、パーソナル・コンピュータ、ハンドヘルド・コンピューティング装置（例えば、ＰＤＡ（ｐｅｒｓｏｎａｌｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ）、電話、時計・・・）、マイクロプロセッサ・ベースまたはプログラム可能な家庭用電化製品または工業電子装置、等を含む他のコンピュータ・システム構成で実践してもよいことは当業者には理解されよう。例示した態様を、通信ネットワークを通して接続されたリモート処理装置によりタスクが実施される分散コンピューティング環境で実践してもよい。しかし、クレーム主題の全てではないにしても一部の態様をスタンド・アロン・コンピュータで実践することができる。分散コンピューティング環境では、プログラム・モジュールをローカル・メモリ記憶装置およびリモート・メモリ記憶装置の両方に配置することができる。

図１１を参照すると、本明細書で開示した様々な態様を実装するための例示的な環境１１１０はコンピュータ１１１２（例えば、デスクトップ、ラップトップ、サーバ、ハンド・ヘルド、プログラム可能家庭用電化製品または工業電子装置・・・）を含む。コンピュータ１１１２は処理ユニット１１１４、システム・メモリ１１１６およびシステム・バス１１１８を含む。システム・バス１１１８はシステム・コンポーネントを処理ユニット１１１４に結合させる。当該システム・コンポーネントにはシステム・メモリ１１１６が含まれるがこれに限らない。処理ユニット１１１４は様々な使用可能なプロセッサの何れかであることができる。当然のことながら、デュアル・マイクロプロセッサ、マルチ・コアおよび他のマルチプロセッサ・アーキテクチャを処理ユニット１１１４として使用できる。

システム・メモリ１１１６は揮発性メモリおよび不揮発性メモリを含む。ＢＩＯＳ（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ）は、例えば起動中にコンピュータ１１１２内部の要素間で情報を転送するための基本ルーチンを含み、不揮発性メモリに記憶される。限定ではなく例として、不揮発性メモリはＲＯＭ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ）を含むことができる。揮発性メモリはＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）を含み、処理を容易にするための外部キャッシュ・メモリとして動作することができる。

コンピュータ１１１２はまた、取外し可能／取外し不能、揮発性／不揮発性のコンピュータ記憶媒体を含む。図１１は、例えば、大容量記憶装置１１２４を示す。大容量記憶装置１１２４には、磁気ディスク・ドライブもしくは光ディスク・ドライブ、フロッピー・ディスク・ドライブ、フラッシュ・メモリ、またはメモリ・スティックのような装置が含まれるがこれらに限らない。さらに、大容量記憶装置１１２４は記憶媒体を、別々に含むか、または他の記憶媒体と組み合わせて含むことができる。

図１１は、ユーザおよび／または他のコンピュータと、適切な動作環境１１１０で説明した基本的なコンピュータ・リソースとの間の中間体として動作するソフトウェア・アプリケーション（複数可）１１２８を提供する。係るソフトウェア・アプリケーション（複数可）１１２８は、システム・ソフトウェアおよびアプリケーション・ソフトウェアのうち一方またはその両方を含む。システム・ソフトウェアは、大容量記憶措置１１２４に記憶することができるオペレーティング・システムを含むことができ、オペレーティング・システムはコンピュータ・システム１１１２のリソースを制御し割り当てるように動作する。アプリケーション・ソフトウェアは、システム・メモリ１１１６および大容量記憶装置１１２４の何れかまたは両方に記憶したプログラム・モジュールおよびデータを通して、システム・ソフトウェアによるリソース管理を利用する。

コンピュータ１１１２はまた、バス１１１８に通信可能に結合されコンピュータ１１１２との対話を促進する、１つまたは複数のインタフェース・コンポーネント１１２６を含む。例として、インタフェース・コンポーネント１１２６はポート（例えば、シリアル、パラレル、ＰＣＭＣＩＡ、ＵＳＢ、ＦｉｒｅＷｉｒｅ・・・）またはインタフェース・カード（例えば、サウンド、ビデオ、ネットワーク・・・）等であることができる。インタフェース・コンポーネント１１２６は（有線または無線で）入力を受信し、出力を提供することができる。例えば、入力を、マウスのようなポインティング・デバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲーム・パッド、パラボラ・アンテナ、スキャナ、カメラ、他のコンピュータ等を含む装置から受け取ることができるが、これらに限らない。出力をコンピュータ１１１２によってインタフェース・コンポーネント１１２６を介して出力装置（複数可）に提供することもできる。出力装置は、とりわけディスプレイ（例えば、ＣＲＴ、ＬＣＤ、プラズマ・・・）、スピーカ、プリンタおよび他のコンピュータを含むことができる。

図１２は、本発明が対話できる例示的なコンピューティング環境１２００の略ブロック図である。システム１２００は１つまたは複数のクライアント（複数可）１２１０を含む。クライアント（複数可）１２１０はハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）であることができる。システム１２００はまた、１つまたは複数のサーバ（複数可）１２３０を含む。従って、システム１２００は、他のモデルの中でもとりわけ、２層のクライアント・サーバ・モデルまたは多層のモデル（例えば、クライアント、中間層サーバ、データ・サーバ）に対応することができる。サーバ（複数可）１２３０はまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）であることができる。サーバ１２３０は、例えば、本発明の態様を使用することで変換を実施するためのスレッドを収容することができる。クライアント１２１０とサーバ１２３０との間の１つの可能な通信は、複数のコンピュータ・プロセス間で送信されるデータ・パケットの形の通信であろう。

システム１２００は、クライアント（複数可）１２１０とサーバ（複数可）１２３０の間の通信を容易にするために使用できる通信フレームワーク１２５０を含む。クライアント（複数可）１２１０は、クライアント（複数可）１２１０にローカルな情報を記憶するために使用できる１つまたは複数のクライアント・データストア（複数可）１２６０に、動作可能に接続される。同様に、サーバ（複数可）１２３０は、サーバ１２３０にローカルな情報を記憶するために使用できる１つまたは複数のサーバ・データストア（複数可）１２４０に、動作可能に接続される。

クライアント／サーバ間の対話を、本明細書で説明した同期に関して利用することができる。例として、データストア１２６０を含むモバイル装置（例えば、電話、携帯情報端末、ラップトップ、メディア・プレイヤ・・・）のようなクライアント１２１０は、通信フレームワーク１２５０を利用して、サーバ１２３０および関連するデータストア１２４０と同期しようとすることができる。例えば、個人のラップトップ・コンピュータ上のデータに加えられた変更を、企業サーバ上の対応するデータと同期することができる。さらに、クライアント１２１０は、同期エンジンまたは同期コンポーネントの構成を容易にするための、１つまたは複数のサーバ・データストア１２４０上の標準的なスキーマ、モデル、プロトコル等を公開、および／またはそれらにアクセスすることができる。

クレーム主題の態様の種々の例を以上で説明した。勿論、クレーム主題を説明する目的でコンポーネントまたは方法の全ての考えうる組合せを説明することは不可能であるが、開示した主題の多数のさらなる組合せおよび順列が可能であることは当業者には認識されよう。従って、開示した主題は添付の特許請求の範囲の精神および範囲内にある全ての係る代替物、修正物、および変形物を含むことを意図している。さらに、発明を実施するための形態または特許請求の範囲において用語「含む」、「包含する」、「有する」、「有している」またはその変形を使用する限りでは、係る用語は用語「備える」を請求項において移行語として使用する場合に解釈される用語「備える」と同様に、包括的であると意図している。

Claims

複数のデータセット（１１２）との対話を可能とするコンジット・コンポーネント（１１０）と、
関連するアプリケーションおよび／またはエンドポイントによって制約されない、前記データセット（１１２）のデータ主導型同期を容易にする同期コンポーネント（１２０）と
を備えることを特徴とするデータ同期システム（１００）。
同期のために前記データセットのデータ構造を定義するデータスキーマ・コンポーネント（２３０）をさらに備えることを特徴とする請求項１に記載のシステム。
前記データスキーマ・コンポーネント（２３０）は変更単位を特定することを特徴とする請求項２に記載のシステム。
前記データスキーマ・コンポーネント（２３０）はコンテンツタイプを規定することを特徴とする請求項３に記載のシステム。
同期のためにデータがどのように交換されるかを定義する同期モデルコンポーネント（２４０）をさらに備えることを特徴とする請求項２に記載のシステム。
前記同期モデルコンポーネント（２４０）は変更検出方法を規定することを特徴とする請求項５に記載のシステム。
前記同期モデルコンポーネント（２４０）は前記データの現在の状態を規定することを特徴とする請求項５に記載のシステム。
前記データセットを比較し、差分を特定するコンポーネント（２１０）をさらに備えることを特徴とする請求項５に記載のシステム。
前記差分を解決するために１つまたは複数の前記データセットを更新し、それによって前記セットを同期するコンポーネント（２２０）をさらに備えることを特徴とする請求項８に記載のシステム。
前記データセットまたはその一部は、拡張可能なコンテンツタイプのスキーマに従うことを特徴とする請求項１に記載のシステム。
データセットに対してコンテンツタイプおよび変更単位を決定するステップと、
前記データセットを、前記コンテンツタイプおよび前記変更単位の関数として複数のデータストアにわたって同期するステップと
を含むことを特徴とするストア間同期方法。
関連するエンドポイントの能力および／または優先度に基づいて変更検出方法を決定するステップをさらに含むことを特徴とする請求項１１に記載の方法。
複数の所定の識別方法から選択することを特徴とする請求項１２に記載の方法。
同期状態情報を利用して前記データセットを同期するステップをさらに含むことを特徴とする請求項１１に記載の方法。
同じデータ構造体を特定するコンテキスト固有の識別子を利用して前記データセットを同期するステップをさらに含むことを特徴とする請求項１１に記載の方法。
前記変更単位に関連付けられたコンテンツ非依存のバージョニング情報を利用して前記データを同期するステップをさらに含むことを特徴とする請求項１１に記載の方法。
前記コンテンツタイプおよび前記変更単位を公開のスキーマから獲得するステップをさらに含むことを特徴とする請求項１１に記載の方法。
サポートされない同期データを運搬するステップをさらに含むことを特徴とする請求項１１に記載の方法。
データがどのように交換されるかを定義する同期モデルおよび交換すべき前記データを記述するデータスキーマの関数として、複数のエンドポイント間で同期プロトコルを交渉するための手段（５３２）と、
前記交渉された同期プロトコルに従って同期を構成するための手段（５３４）と
を備えることを特徴とする同期を容易にするシステム（５００）。
前記交渉されたプロトコルに従って複数の装置にわたって前記データを同期するための手段（１２０）をさらに備えることを特徴とする請求項１９に記載のシステム。