JP2011511368A - マルチマスター同期環境のための知識ベースフレームワークにおける質的オブジェクト変更の表現 - Google Patents

Abstract

本開示は、オブジェクト品質の概念を含むように知識ベース同期フレームワークを拡張する、マルチマスター同期環境においてネットワークノード間で同期を取るステップに関する。一実施形態では、オブジェクトの与えられたバージョンについての知識ベクトルに、オブジェクトについての品質情報を表す追加的な次元（複数可）が置かれ、オブジェクトの品質のどのタイプが同期プロセスの一部としてノードに伝えられるべきかをノードが決定することを可能にするために、その次元が同期プロセス中に考慮される。他の実施形態は、マルチマスター同期環境において他のノードによって維持される同じオブジェクトに関する将来の同期を回避するために、オブジェクトを無効化するステップを含む。
【選択図】図１

Description

本開示は、マルチマスター同期環境（ｍｕｌｔｉ−ｍａｓｔｅｒ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ）のための知識ベース同期フレームワーク（ｋｎｏｗｌｅｄｇｅ ｂａｓｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｆｒａｍｅｗｏｒｋ）における、同期が取られたオブジェクト（複数可）に対する変更についての知識を記述するための拡張メタデータに関し、拡張メタデータは、変更についての質的情報（ｑｕａｌｉｔａｔｉｖｅ ｉｎｆｏｒｍａｔｉｏｎ）を含む。

モバイルコンピューティングおよび通信デバイスの人気が、いつでもユーザーが望むときに情報を送受信できるようにしたいという対応する願望を生み出した。簡単に言えば、ユーザーは、いつどこにいても、またデバイス個々の能力がどうであれ、情報およびアプリケーションへの様々なデバイスからのユビキタスアクセスを望んでおり、加えて、ユーザーは、そのような情報に直に（ｏｎ ｔｈｅ ｆｌｙ）アクセスし、更新できることを望んでおり、データが可能な限り正確で最新であることの保証を望んでいる。

デバイスおよびオブジェクトに互いにデータのレプリカを共有させることを試みる様々な分散データシステムが存在する。例えば、音楽共有システムは、ＰＣ、セルフォン、ゲーム機、およびＭＰ３プレーヤーの間で音楽の同期を取ることができる。電子メールデータは、ワークサーバー、クライアントＰＣ、およびポータブル電子メールデバイスの間で同期を取ることができる。しかし、今日、そのようなデバイスが互いに１組の共通情報の同期を取る限りにおいて、同期は一般に、静的設定に従ってデバイス間で取られる。しかし、これらのデバイスが頻繁にまたは断続的に切断される場合、すなわち、相手との通信から切断され得るようにデバイスが疎結合されている場合、例えば、セルフォンがトンネル内に入った場合、または同期が取られるデバイスの数が動的である場合、デバイスが、互いに再接続するとき、またはネットワークに参加するときに、他の各デバイスがどのような変更を必要とするかを決定するための、トポロジー独立な方法を有することが望ましくなる。

図１に示されるように、今日では、電子メールサーバーが電子メールクライアントと同期を取る場合など、マスターノード１００がクライアントノード１１０と専用方式で同期を取る様々な例が存在する。２つのデバイス間の専用同期であるため、２つのデバイス間で同期を取るために必要とされる情報１０２は、マスターノード１００によって追跡することができる。そのような情報１０２は、任意選択的に、クライアントノード１１０によっても同様に追跡することができるが、マスターノード１００とクライアントノード１１０の間の接続が時々切断される場合、または同期デバイスの数が突然増加もしくは減少し得る場合、それらのデバイスのすべてにおいて各デバイスが必要とする共通な情報の必要な情報を追跡することは、難しい問題となる。

現在の解決策は、しばしば、同期セマンティクス（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｅｍａｎｔｉｃｓ）を、任意のノードではなく、もっぱら特定のノード（例えば、電子メールサーバー）のクロックまたは論理透かし（ｌｏｇｉｃａｌ ｗａｔｅｒｍａｒｋ）に基づかせる。これらのシステムは、単一の接続ノードまたはマスターの場合には良好に機能し得る。しかし、ノード接続のトポロジーまたはパターンが予測不能に変化し得る場合、それらのシステムは、問題に打ち当たる。

他のシステムは、問題に対処するために、特定の種類のデータオブジェクトのための独自仕様の同期モデルを構築し、すべてのデバイスにおいて、データフォーマットに固有な膨大な量のプリミティブメタデータを追跡する。例えば、特定のＷｏｒｄプロセッシング文書フォーマットのオブジェクトの同期を取るために、文書およびその基本プリミティブを表現することに、それらが時間とともに変化するにつれて、多くのオーバーヘッドおよび複雑さがもたらされ、共通の１組のＷｏｒｄプロセッシング文書に従って同期を取ることを望む他のデバイスに対してその情報を効率的に表現することにも、多くのオーバーヘッドおよび複雑さがもたらされる。そのようなシステムは、構築が複雑になって多くのコストがかかり、それが基づいているカスタムデータフォーマットのせいで拡張可能性がない（ｎｏｎ−ｅｘｔｅｎｄｉｂｌｅ）のに加えて、生成し、分析し、追跡しなければならない大量のメタデータのせいで本質的に拡張可能性がない（ｕｎｓｃａｌａｂｌｅ）。

加えて、そのような解決策は、１つの特定の領域、例えばＷｏｒｄプロセッシング文書にのみ適用される。例えば、ピクチャ、ビデオ、電子メール、文書、データベースストアなど、すべての種類の同期オブジェクトが考慮される場合、マルチマスター環境内のすべてのデバイスにおいてそのようなオブジェクトの進化を追跡するために、各オブジェクトタイプに基づいたカスタム同期解決策を実施することは、現在のところ機能し得ないことが分かる。したがって、そのような解決策は、同期セマンティクスをデータセマンティクス（ｄａｔａ ｓｅｍａｎｔｉｃｓ）と密接に結び付ける。

したがって、トポロジー内のコンピューターが互いに接続する方法を変更した場合、またはコンピューターの数が増加するにつれて、ノード独立の同期知識が必要とされている。例えば、メディアプレーヤーの場合、多数のコンピューター間および多数のウェブサイト間で同期を取るのが望ましいことがある。たいていの場合、ほとんどのアプリケーションは、少数のよく知られたエンドポイント（ホームＰＣおよびメディアプレーヤー）の間でデータの同期を取ることができるにすぎない。しかし、メディアプレーヤーアプリケーションのユーザーにとって、デバイスコミュニティー（ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｔｙ）は時間とともに進化するので、デバイスによって利用される音楽ライブラリーのためのデータ同期の柔軟性がますます必要となり、それによって、より堅牢なシステムの必要性が生み出される。

その必要性は、起こり得る変更のタイプの観点から多くのコンピューティングオブジェクトが一枚岩的でないことを考えた場合、より一層複雑になる。今日の複雑なコンピューティング環境では、オブジェクト変更は、単なる「オブジェクトへのデータの追加」または「オブジェクトからのデータの除去」を越えた多様な変更を含む。オブジェクトのデータのいくつかに対する変更は、変更されるデータの除去と、変更を反映したデータの追加と考えることもできる。したがって、一枚岩的な見方の下では、オブジェクトの進化の観点からオブジェクトに何が起こり得るかについて、限られた見方が、すなわち、オブジェクトによって表されるデータは、いくつかの新しいデータを用いて拡大でき、オブジェクトによって表されるデータの一部は、残りを同じに留めたまま変更でき、および／またはオブジェクトによって表されるデータの一部は、削除できる、という見方があるにすぎない。

これに関連して、オブジェクトに関する多数の属性のすべても変更することができる。例えば、オブジェクトの名前、オブジェクトが最後に閲覧されたとき、オブジェクトのフィールドの許容可能な長さ、オブジェクトのスキーマ（例えば、連絡先スキーマ）、オブジェクトの忠実度（例えば、オーディオ）、オブジェクトに適用される圧縮方式、オブジェクトの解像度（例えば、画像もしくはビデオ）、オブジェクトのファイルフォーマット、またはオブジェクトに対して定義できる他の任意の機能はすべて、オブジェクトのデータの追加または除去という単純な表現によっては適切に反映されない、オブジェクトの変更可能な属性の例である。

これに関連して、異なるデバイスは、同じオブジェクトの表現に関して、異なる要件または制限を有する。例えば、ＰＣ上でのオブジェクトの表現は一般に、メモリーが限定されたモバイル電話上でのオブジェクトの表現とは異なる要件に関連する。一例として、画像オブジェクトが与えられた場合、ＰＣ上では１０Ｍｂの原画像を表現する方がより適しており、一方、ディスプレイおよびメモリーがより小さなモバイル電話に対しては、同じ与えられた画像オブジェクトを３００Ｋｂの画像として表現する方がより適している。

いくつかの従来のシステムは、第１の品質から第２の品質への品質変化をこうむるオブジェクトを別個のオブジェクトとして扱い、すなわち、第１の品質に留まる第１のオブジェクトを維持するのに加えて、オブジェクトがこうむった変更を第２の品質に反映したまったく新しい第２のオブジェクトを生成する。結果として、両方のオブジェクトは、同期が取られて進行する。異なるオブジェクトの数、デバイスの数、および／または異なる品質のバージョンの数が少なからぬものになった場合、そのようなシステムが、禁止せざるを得ない、非常に無駄の多いものになることが分かる。

したがって、オブジェクトは複雑な方法で変更でき、特に、異なる能力の異なるデバイスにわたって同期が取られるので、同期メタデータ内においてそのような変更を効率的に表し、同時に、上で説明されたような疎結合されたマルチマスター同期環境において同期を扱うための方法が、現在望まれている。簡潔に言えば、オブジェクトが品質の変更をこうむった場合に、可能であるならば、デバイスの複雑なマルチマスターネットワークトポロジーにおける知識交換（ｋｎｏｗｌｅｄｇｅ ｅｘｃｈａｎｇｅ）において、オブジェクトの品質の減少または増加を表す能力が、無数の同期シナリオのために望まれる。

今日の同期モデルの上で説明された難点は、従来のシステムの問題のいくつかについての概要を提供することを意図したものにすぎず、網羅的であることは意図していない。従来のシステムが抱える他の問題、および本明細書で説明される様々な非限定的な実施形態の対応する利点は、以下の説明を検討することでより明らかとなるであろう。

本明細書では、より詳細な説明および添付の図面における以下の例示的で非限定的な実施形態の様々な態様の基本的または概略的な理解を可能にする助けとなるように、簡略化された要約が提供される。しかし、この要約は、広範なまたは網羅的な概要として意図されていない。代わりに、この要約の唯一の目的は、以下の様々な実施形態のより詳細な説明に対する前置きとして、いくつかの例示的で非限定的な実施形態に関連するいくつかの概念を簡略化された形式で提示することである。

本明細書では、オブジェクト品質の概念を含むように知識ベース同期フレームワークを拡張する、マルチマスター同期環境における複数のネットワークノード間の同期を提供する様々な実施形態が説明される。有利には、同期フレームワークによれば、エンドポイントは、知識交換の目的で、同期データの１つまたは複数のオブジェクトの品質の定義を可能にする方法で、データの同期を取ることができる。

一実施形態では、オブジェクトの与えられたバージョンについての知識ベクトル（ｋｎｏｗｌｅｄｇｅ ｖｅｃｔｏｒ）に、オブジェクトのそのバージョンについての増分品質情報を表す追加的な次元（複数可）が置かれ、オブジェクトの品質のどのタイプが同期プロセスの一部としてノードに伝えられるべきかをノードが決定することを可能にするために、その次元が同期プロセス中に考慮される。例えば、ノードにとって望ましくない品質を有するオブジェクトは、マルチマスター同期環境において他のノードによって維持されるそのようなオブジェクトに関する将来の同期を回避するために無効化（ｔｏｍｂｓｔｏｎｅ）することができ、他の実施形態では、オブジェクトに対する変更が非破壊的（ｎｏｎ−ｄｅｓｔｒｕｃｔｉｖｅ）である（とノードによって決定された）場合、オブジェクトの現在のバージョンは、現在のバージョンの別のバージョン、すなわち、変更されたオブジェクトの品質レベルを表すバージョンを反映するように拡張される。変更が破壊的（ｄｅｓｔｒｕｃｔｉｖｅ）と見なされた場合、同期メタデータによって、新しいバージョンが反映される。

上記および他の実施形態が、以下でより詳細に説明される。

様々な非限定的な実施形態が、添付の図面を参照してさらに説明される。

システムの２つの適切に定義されたエンドポイントの間で同期を提供する専用同期システムの図である。 同期オブジェクトについての品質情報を含む同期メタデータを含むマルチマスター同期のためのインフラストラクチャーの高水準ブロック図である。 ネットワークに接続するノードおよびネットワークから切断するノードの存在下で、品質同期メタデータに基づいて同期を取るための例示的で非限定的なプロセスを示すフロー図である。 品質同期メタデータに基づいて同期を取るための例示的で非限定的なプロセスを示す別のフロー図である。 ノードが疎結合されたネットワークのうちの４つのノードの間の例示的で非限定的な知識交換を示す図である。 デバイスのいくつかが互いに切断された場合の、ノードが疎結合されたネットワークのうちの４つのノードの間の例示的で非限定的な知識交換を示す図である。 ネットワークのノード間で多数のオブジェクトが共有される状況における例示的な知識交換を示す図である。 ネットワークのノード間で多数のオブジェクトが共有される状況における例示的な知識交換を示す図である。 ネットワークのノード間で多数のオブジェクトが共有される状況における例示的な知識交換を示す図である。 ネットワークのノード間で多数のオブジェクトが共有される状況における知識交換のためのプロセスを示す例示的で非限定的なフロー図である。 知識に基づいて変更を要求し、伝えるためのフレームワークを示す全体的なアーキテクチャーの図である。 質的情報を同期メタデータに含めるための第１の実施形態を示す全体的なフロー図である。 無効化する実施形態が例示的な方式で示された第１の非限定的なシナリオを示す図である。 質的情報を同期メタデータに含めるための代替的な実施形態を示す全体的なフロー図である。 バージョンをバージョン管理する実施形態が例示的な方式で示された第２の非限定的なシナリオの図である。 同期メタデータの一部として品質情報を伝達できる共通の１組のＡＰＩを介して別のノードとの知識交換を実行するためのデバイスの例示的で非限定的な実施のブロック図である。 本明細書で説明される様々な実施形態が実施できる例示的で非限定的なネットワーク環境を表すブロック図である。 本明細書で説明される様々な実施形態の１つまたは複数の態様が実施できる例示的で非限定的なコンピューティングシステムまたは動作環境を表すブロック図である。

概要
背景技術において説明されたように、とりわけ、従来のシステムは、オブジェクトに生じたあらゆる変更毎にオブジェクトの異なるバージョンを生成するが、そのようなシステムは、無損失変換、トランスコーディング、トランスクリプション、または忠実度の変更など、オブジェクトに対する変更についての質的情報を獲得しない。例えば、デバイスが、望む質的バージョンのオブジェクトとのみ同期を取ることができ、オブジェクトによって拒否される質的バージョンを有するオブジェクトとは同期を取らないように、オブジェクトまたはオブジェクトの特定のバージョンの品質の変更についての情報を、同期言語（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｌａｎｇｕａｇｅ）自体の一部として獲得することが望ましい。

したがって、様々な非限定的な実施形態では、マルチマスター同期環境内の異なるノードが、知識を比較でき、どのオブジェクトの同期を取り、どのオブジェクトは同期を取るのが望ましくないかを決定できるように、異なる忠実度、変換、符号化の、すなわち、異なる質的バージョンのオブジェクトは、マルチマスター同期環境において、オブジェクトの品質についての情報を獲得する方法で同期が取られる。

以降のロードマップについて一言すると、まず、本明細書で説明されるいくつかの実施形態の概要が提示される。その後、マルチマスターデータ同期システムにおいて知識を効率的に表現するための一般的な機構についてのいくつかの補足的なコンテキストが与えられる。次に、補足的なコンテキストについての例示的で非限定的な実施形態および特徴がより詳細に説明され、オブジェクトに対する変更についての質的情報を表現するためのマルチマスターデータ同期システムの代替実施形態が理解され、続いて、そのような実施形態を実施できる代表的なネットワークおよびコンピューティング環境が説明される。

これに関連して、様々な実施形態は、本明細書で知識と呼ばれる概念に基づいた同期のためのモデルを定義する、マルチマスター同期環境のノードのためのデータ同期フレームワークに関する。簡潔に言えば、知識は、同期が取られるオブジェクトから論理的に分離されて維持されるメタデータであり、デバイスが、最初に知識を交換し、次にオブジェクトに対するどの変更を互いに受け渡すべきかを効率的に列挙できるように、レプリカの状態ベース同期についての効率的な要約を定義する。有利には、各ノードは、オブジェクトのどの品質は同期を取るのが望ましく、オブジェクトのどの品質は同期を取るのが望ましくないかに関する独自のルールを定義することができる。例えば、デバイスは、どのバージョンが望ましいかを決定するためのテストを指定することができ、または異なる品質を好ましさの順序にランク付けして並べることができる。

これに関連して、多くの場合、マルチマスター同期トポロジーの各デバイスが、同期が取られるオブジェクトの品質レベルについて何を知っているか（例えば、低解像度か、それとも高解像度か）、またはより一般的に、各デバイスが、デバイスによって維持されるオブジェクトに適用される任意の１つもしくは複数の変換について何を知っているかを効率的に表現する方法で、データの同期を取ることが有益である。この点において、個々のエンドポイントが、より低い品質のオブジェクト（またはオブジェクトの第１の変換）と同期を取るべきか、それともより高い品質のオブジェクト（またはオブジェクトの第２のより適切な変換）を有するデバイスを探し出すべきかを決定できるように、デバイスは、そのような情報を知識交換の一部として効率的に伝達することができる。

一実施形態では、エンドポイントは、許容できない変換、符号化、忠実度などのバージョンを受信した場合は常に、その許容できないオブジェクトバージョンを無効化し、実質的にそのアイテムを同期プロセスから削除することができるが、将来の同期がその許容できないバージョンを再び受け入れることを回避するように、エンドポイントは、許容できないバージョンについてのメタデータを維持する。しかし、時間とともに、そのような無効化メタデータが、許容し得ないほど増加することがあり得る。要するに、デバイスは、特に機能が限定されており、おそらくは多くを拒否するデバイスの場合は、本当のところ、それまでに対話したが好まなかったものすべての記録を維持する必要はない。

このタイプの知識の効率的な表現を利用する他の実施形態では、ノード間での質的情報の共有の達成は、データのバージョンをバージョン管理することによって達成される。そのような実施形態は、２層の場合はバージョンのバージョンをバージョン管理し、３層の場合はバージョンのバージョンのバージョンをバージョン管理し、以降も同様にすることによって、オブジェクトに適用される変換または品質レベルを任意の数のレベルまたは層にまで拡張することもできる。個々のエンドポイントは、オブジェクトに対する特定の変更が、バージョンのバージョン管理を必要としない一般的な変更（ティックカウント（ｔｉｃｋｃｏｕｎｔ）の通常の増加、または新しいバージョンの適用）を表すか、それとも代わりに、現在のティックカウントによって表されるバージョンをバージョン管理することによって表される、忠実度または変換の変更を表すかを決定することが可能である。

どのオブジェクトが変化したかについての情報をバージョンを介して効率的に獲得し、表現する能力と、それに加えて、それらのオブジェクトがどのように変化したかについての情報を獲得し、表現する能力は、実質的に、エンドポイントに、オブジェクトの特定のバージョンがエンドポイントにとってどれだけ有益かを告げる。したがって、知識表現にバージョン情報のバージョン管理を含めることによって知識を拡張することは、オブジェクトに対する変換についての質的情報を伝える目的を達成するための別の方法である。

言及されたように、無効化する実施形態は、オブジェクトが望まないアイテムを受信した（例えば、デバイスのメモリーに対して解像度が高すぎる）ときに、デバイスが、そのアイテムを再び受信しないようにそのアイテムを無効化することができるが、アイテムについて知らされたが、そのアイテムを削除したという知識を伝えることができるように実施することもできる。したがって、様々な実施形態は、オブジェクトの異なる品質についての情報が同期知識の一部として定義されるように、オブジェクトの変換またはトランスコーディングの品質の概念を同期自体の言語に組み込む。

図２は、マルチマスター同期環境において同期を取るオブジェクトの概念を全体として図説するブロック図であり、オブジェクトは、オブジェクトのために定義された同期メタデータに従って異なる品質にある。示されるように、デバイス２００およびデバイス２１０は、ネットワーク２２０（複数可）と、それぞれ同期コンポーネント２０２、２１２とを介して互いに接続し、同期を取るものとして示されている。各同期コンポーネント２０２、２１２は、ストレージ２０４、２１４内にオブジェクトを保存するばかりでなく、以下でより詳細に説明されるように、それぞれそれらのオブジェクトの同期知識２０６、２１６も維持する。これに関連して、データタイプおよびネットワークトポロジーとは独立に同期を取るために使用される同期知識２０６、２１６は、オブジェクトの品質を説明するメタデータを含むように拡大することができる。

オブジェクトの品質を説明するメタデータの場合、これは、オブジェクトの同期のために、オブジェクトの異なる変換についての質的情報を獲得できることを意味する。例えば、図示されるように、同じオブジェクトＸは、デバイス２００およびデバイス２１０上で表現することができ、それぞれオブジェクト２３０および２３０’として表現される。オブジェクト２３０は、品質Ｑ１を有し、オブジェクト２３０’は、品質Ｑ１と異なる品質Ｑ２を有する。したがって、様々な実施形態に関連して説明される知識に基づいたマルチマスター同期プロトコルによれば、同期知識２０６、２１６は、オブジェクトに対する変更のバージョン管理に加えて、オブジェクトの同じバージョンの異なる品質を説明する情報を含む。

例えば、オブジェクトＸ２３０は、ＷＭＡフォーマットの歌とすることができ、一方、オブジェクトＸ２３０’は、同じ歌とすることができるが、ＡＡＣフォーマットとして符号化される。２つのオブジェクトをその歌の異なるバージョンとして表現する代わりに、本明細書の様々な実施形態は、それが同じバージョンであるが、そのバージョンに関連付けられた異なる品質が存在することを示す、知識表現を可能にする。したがって、ノードは同期メタデータ内に含まれる品質情報に基づいて、与えられた品質バージョンの同期を取るべきかどうかを決定することができる。

歌が例として使用されたが、オブジェクトのタイプは関係がない。オブジェクトのバージョンが異なる質的特性を有すると考え得ることを宣言するのが有益である場合はいつでも、同じ技法を適用することができる。例えば、ＰＣ上のＯｕｔｌｏｏｋ内の連絡先アイテムは、モバイル電話上の連絡先アイテムよりも多くのフィールドを含むことができる。前者は、後者よりも品質が高い連絡先のバージョンであると、ノードによって見なされ得る。そのような場合、本質的に、それは、連絡先アイテムによって表されるデータの量についての忠実度または解像度の変化である。したがって、実質的に、任意のアイテムは、例えば、異なる符号化または同じプログラムの異なるプログラミング言語トランスコーディングなど、同じオブジェクトの変換に関連する変化に分類することができる。したがって、本明細書の実施形態のいくつかは、概念の簡素化のため、オーディオまたはビデオの文脈において説明されるが、任意のタイプのオブジェクトが、品質変換をこうむると見なすことができ、各エンドポイントは、その目標のため、同期の観点からそれが何を意味するかを定義することができる。

図３は、マルチマスター同期環境において様々なノード間で同期を取ることを目的とした、オブジェクトのための「品質」情報の使用を説明する、全体的なフロー図である。３００において、いくつかのポイントにおいて、異なる品質を有するオブジェクトのバージョンに対して、同期メタデータが定義される。３１０において、ノードが、マルチマスター同期環境において、任意のネットワークトポロジーに従って構成された１つまたは複数のネットワークを介して、別のノードに接続する。３２０において、ノードは、同期メタデータを学習すること、すなわち、別のノードから受信すること、もしくは別のノードに要求し、受信することができ、またはノードは、同期メタデータを別のノードに送信することができ、メタデータは、同期が取られる１組のオブジェクトのためのバージョン管理情報を説明し、オブジェクトに適用される変換の質的特性についての品質情報を含む。

３３０において、オブジェクトについての品質情報の集合的知識を決定するために、品質情報を含む２つのノードの同期メタデータが比較される。３４０において、１組のオブジェクトについての品質情報の集合的知識に基づいて、ノードは、どのオブジェクトの同期を取るべきかを選択することができる。３５０において、比較の後、任意選択的に、ノードは、ノードのために定義された品質基準を満たさない、１組のオブジェクトのうちのオブジェクトにアクションを取る（例えば、削除する）ことができるが、他のノードとの将来の効率的な知識交換のために、取られたアクションについて説明する同期メタデータを維持することもできる。

例えば、ノードは、オブジェクトの最高品質のバージョンのみを保持することを選択することができる。画像の場合、例えば、オブジェクトが５Ｍｂバージョンを有する場合、３００Ｋｂバージョンは、ノード上での両バージョンのサポートを仮定したより低い解像度であるので、削除することができる。別のノードの場合、３００Ｋｂは、そのノードによってサポートされる最高の解像度であることがあり、そのため、ノードは、３００Ｋｂよりも高いオブジェクトの品質バージョンを拒否するように定義することができる。同様に、同じデータの異なる符号化は、互換性の観点から、異なるノードでは異なるように適用することができ、したがって、有利には、同期メタデータへの品質メタデータの包含は、取得できる異なる種類のオブジェクトについての各ノードがもち得る視力（ｖｉｓｉｏｎ）を改善し、同時に、どの品質バージョンが望ましくないかをノードが表現する仕組みを可能にする。

３６０において、任意選択的に、ステップ３５０に従って削除されたいくつかのオブジェクトは、同期メタデータ内で無効化することができ、それは、ローカルデバイス上でオブジェクトが削除され、ノードは過去にその品質を有するアイテムについて知らされたことがあるが、ノードは将来再びそのアイテムについて知らされたくないことを示す。一実施形態では、ノードは、拒否された品質を有するアイテムについての情報を維持することによって、アイテムを有することについて実質的に嘘をつくが、そのアイテムが将来望まれないことも通知する。例えば、そのようなオブジェクトについては、将来の知識交換の最中に同期知識を比較する目的で、オブジェクトがかつて学習されて拒否されたことを示すようにブールフラグ（Ｂｏｏｌｅａｎ ｆｌａｇ）を設定することができる。

図４は、マルチマスター環境において同期を取るための知識交換フレームワークにおける、同期メタデータ内の品質情報の代表的な実施を示すフローチャート図である。示されるように、デバイス３００とデバイス４１０は接続され、同期を取ることを望む。例を簡潔にするため、図４は、デバイス４００とデバイス４１０の間で同期が取られる１つのオブジェクト４０２および４１２をそれぞれ示しているが、当該技法は、任意の１組のオブジェクトのために拡張することができる。言及されたように、本明細書で説明される実施形態によれば、同期知識４０４および４１４が、オブジェクト４０２および４１２のために、デバイス４００および４１０によってそれぞれ維持される。これに関連して、同期知識４０４は、品質Ｑ１がオブジェクト４０２に適用されることを表し、同期知識４１４は、品質Ｑ２がオブジェクト４１２に適用されることを表す。

４５０に示されるように、ノードが、マルチマスター同期環境において、任意のネットワークトポロジーに従って構成された１つまたは複数のネットワークを介して、他のノードに接続した後、デバイス４１０は、デバイス４１０から同期知識４１４を受信することができる。４５２において、デバイス４００は、以下でより詳細に説明される知識交換原理に従って、知識４０４を知識４１４と比較する。

これに関連して、４５４において、デバイス４００は、同期知識４１４内で表されるバージョンＱ２が望ましいかどうかを決定することができる。望ましい場合、４５６において、ローカル知識４０４は、知識４１４の品質情報Ｑ２を用いて更新される。次に４５８において、デバイス４００は、デバイス４００が関心のあるオブジェクトの更新を要求し、更新された知識４０４が、デバイス４１０に送信される。今度は、４６０において、デバイス４１０が、更新された知識４０４を知識４１４と比較し、４６２において、品質Ｑ１を有するデバイス４００のバージョンが望ましいかどうかを決定する。４６４において、知識４１４は、更新された知識４１４を含むように更新され、知識交換を完了させる。４６６において、更新された知識４０４が、Ｑ２がデバイス４００にとって望ましいことを示している場合、４６８において、デバイス４００は、そのような更新を受信し、４７０において、それがデバイス４００によって保存される。同様に、デバイス４１０は、望む変更をデバイス４００から受信する。このようにして、同期知識交換は、デバイスが、同期中に受信したバージョンの品質について選り好みすることを可能にする。
効率的な知識表現および交換
様々な非限定的な実施形態による、マルチマスター同期環境における、知識として表現された同期メタデータを介するオブジェクトの品質の表現を説明する前置きとして、このセクションでは、データ同期フレームワークにおける、知識を効率的に表現するための全体的な機構の概要が提示される。

全体的な同期機構は、（１）第１のノードによって必要とされる最低限のデータのみを送信するように第２のノードに要求することによる、接続デバイス間での知識の効率的な交換、（２）第１のノードと第２のノードの間でのデータの状態の不一致すなわち競合を効率的かつ正確に認識する能力、（３）任意の数のノードを同期させる能力、および（４）任意のノードを任意の他のノードを介して同期させる能力、すなわち、ピアツーピアのマルチマスター同期環境において動作する能力を含む。

全体的な機構を用いて、２つのデバイス間で共有されるいくつかの情報に対して、任意の数の変更を行うことができる。２つのデバイスは接続されるといつでも、互いに知識を交換することによって、デバイス間での変更を容易にするための、互いが何を知っており、何を知らないかを再構成するために必要とされる少なくとも最低限の量の情報を知るようになる。３つ以上のデバイスが含まれる場合、共有される情報のより大きなベース（ｂａｓｅ）についての知識に関して、知識は不完全になり得るが、多数のデバイス間でより多くの知識が共有されるので、時間とともにデバイスが他のデバイスに接続するにつれ、集合的な知識がデバイスによって蓄積され続けることに留意されたい。

有利には、様々な非限定的な実施形態では、同期は、１組のデバイスまたは１組のデバイスの一部に対して実行され、そのすべてが１組のオブジェクトの最新バージョンを維持することに関心があるが、同期は、そのようなデバイスが、コンピューティングエコシステム（ｃｏｍｐｕｔｉｎｇ ｅｃｏｓｙｓｔｅｍ）においてデバイスが同期を取ることができる異なるオブジェクトについて質的結論を下すことも可能にする。デバイスが１つまたは複数のネットワークを介して１組のデバイスのうちの他のデバイス（複数可）と再び接続する場合はいつも、そのデバイスは、他のデバイス（複数可）がそれらの集合的知識を用いて表すのと同じくらい最新の集合的知識を再獲得する。このようにして、疎接続されたデバイスであっても、１組のデバイスと接触し、接触を断つことができ、その後、最新の１組の集合的知識を所有する任意の１組のデバイスと接触することによって、獲得し損ねたすべての知識を再学習することができる。

図５は、知識交換が、任意の数のデバイスに一般化または拡張可能であることを示している。示されるように、非限定的な数のデバイスとして、４つのデバイス５００、５１０、５２０、５３０が、デバイス間で共有される１組の共通情報について各デバイスが何を知っており、何を知らないかをそれぞれ示す知識表現５０２、５１２、５２２、５３２とともに示されている。

有利には、図６に示されるように、ネットワーク内の接続が切断された場合でさえも、それにも関わらず、他のデバイスへの少なくとも１つの接続が直接的または間接的に存在する限り、デバイス５００、５１０、５２０、５３０のすべてによって、完全な１組の知識が獲得できる。例えば、示されるように、デバイス５３０の知識５３２は、デバイス５２０との知識交換、次にデバイス５２０とデバイス５１０の間の知識交換、最後にデバイス５１０とデバイス５００の間の知識交換を介して、依然として、デバイス５００に到達する。

より多くのデバイスが、共有される共通情報についての知識を共有する場合、様々な非限定的な実施形態による知識交換（複数可）は、集合的知識がどのデバイスから来るかについて関知しないので、デバイスのすべてが利益を得る。デバイスの各々は、それが接続された他のデバイスのいずれかから、デバイス間で共有される情報についての多くの知識を獲得しようと試みて独立に動作する。

例示的で非限定的な詳細では、２つのノードが会話に関わり、会話の最後に、関心のあるデータセットについて同等の知識を有するための方法が、さらに詳細に説明される。この方法は、ピアツーピアネットワーク／マルチマスター環境に入って来た新しい各デバイスに対して知識交換能力を授けることによって、２つのノードを超えて拡張可能である。

したがって、図７に示されるように、任意の数のノードを有するピアツーピアネットワークのノード７００は、ノード７１０とデータを交換することを望む。ノードＡは、ノード７１０に変更を要求することによって開始し、それを行うために、ノード７００は、示されるように、（Ｋ_Ｎ７００として表された）その知識をノード７１０に送信する。

デバイスまたはノードの知識は、デバイス間で共有される各オブジェクトを文字識別子を用いてラベル付けすることによって表され、次に、後に付けられた数字が、このオブジェクトの最新バージョンを表す。例えば、図７に示されるようにＫ_Ｎ７００は、オブジェクトＡ、Ｂ、Ｃ、Ｄを含み、その各々は、ノード７００とノード７１０の間で同期が取られ、各オブジェクトの後に付けられた数字は、デバイスにおいて知られているオブジェクトの最新バージョンを表す。例えば、時間ｔ＝１における知識Ｋ_Ｎ７００は、図７においてＡ４、Ｂ３、Ｃ６、Ｄ０と表記される、Ａの第５バージョン、Ｂの第４バージョン、Ｃの第７バージョン、Ｄの第１バージョンを含む。対照的に、時間ｔ＝１におけるノード７１０の知識Ｋ_Ｎ７１０は、図７においてＡ３、Ｂ６、Ｃ６、Ｄ２と表記される、Ａの第４バージョン、Ｂの第７バージョン、Ｃの第７バージョン、Ｄの第３バージョンを含むことができる。

図８に示されるように、時間Ｔ＝２において、ノード７１０は、ノード７００から受信した知識Ｋ_Ｎ７００を自らの知識Ｋ_Ｎ７１０と比較し、何がノード７００に送信される必要があるかを決定する。この例では、ノード７００の知識のＢ３、Ｄ０は、ノード７１０の知識のＢ６、Ｄ２よりも遅れているので、結果として、ノード７１０は、ＢおよびＤに関する変更をノード７００に送信する。ノード７１０は、Ｂ６とＢ３の間の変更およびＤ２とＤ０の間の変更をノード７００に送信する場合、（ノード７１０上で最新の変更が行われたときがいつであろうとそれを反映した）ノード７１０が有する知識Ｋ_Ｎ７１０の最新バージョンとともに送信する。

時間ｔ＝３を表す図９に示されるように、ノード７００への知識Ｋ_Ｎ７１０の送信は、同じバージョンであったにも関わらず、ノード７００とノード７１０の両方がオブジェクトに対する変更を行ったことが後で判明した場合、ノード７００が、競合を検出する（例えば、後の解決のためにそれらを保存する）ことを可能にする。これは、自律的な更新、効率的な列挙を可能にするが、ノードが変更に出会い、それを交換した場合に、正しい競合検出も可能にする。例えば、例において、Ｃ６が知識Ｋ_Ｎ７１０と知識Ｋ_Ｎ７１０の双方で同じオブジェクトではない場合、例えば、双方がＣ５からＣ６に独立に進化した場合、どちらのＣ６が正しいＣ６であるかは、例えば、同期シナリオおよび含まれるデバイスに適した事前に定められた方針による解決に従った競合解決に委ねるために保留にすることができる。

上で説明された全体的な機構を使用する、分散マルチマスター同期環境の任意の２つのノード間の例示的な知識交換プロセスが、図１０のフロー図に示されている。１０００において、ノードＡは、ノードＢとの同期を要求し、それによって、ノードＡが知らない変更をノードＢに求める。ノードＢに授けるため、１０１０において、ノードＡは、その知識をノードＢに送信する。１０２０において、ノードＢは、ノードＡから受信した知識を自らの知識と比較して、ノードＢが知っているどの変更をノードＡに送信すべきかを決定する。１０３０において、ノードＢは、そのような変更をノードＡに送信し、加えて、ノードＢは、ノードＡが１０４０において同様の知識比較を実行できるように、その知識をノードＡに送信する。本明細書で説明される実施形態と一貫性を保って、デバイスにとって望ましくないメタデータによる質的特性を有するオブジェクトは、デバイスの制限のせいで、またはそのような質的特性はデバイスが目標を促進する助けとならないので、同期が取られない。

１０５０において、ノードＡは、ノードＡおよびノードＢ上でバージョンの独立した進化が発生している場合、ノードＢの知識に反映された最新バージョンとノードＡの知識に反映された最新バージョンの間の潜在的な競合を検出する。任意選択的に、競合の場合にどちらのノードが他方のノードに優先されるかを決定するために、いずれかの競合解決方針を適用することができる。１０６０において、ノードＢによって所有されない最新の変更が、ノードＡからノードＢに送信される。競合解決方針が、ノード間で共通情報を維持するために、変更がノードＢからノードＡに送信されるか、それともノードＡからノードＢに送信されるかを追加的に指図する。独立したバージョン管理がＯＫまたは望ましい場合、競合解決は別の選択肢にならない。本明細書で説明される実施形態と一貫性を保って、デバイスにとって望ましくないメタデータによる質的特性を有するオブジェクトは、デバイスの制限のせいで、またはそのような質的特性はデバイスが目標を促進する助けとならないので、同期が取られない。

図１１は、フィルタリングされた知識が可能である場合に、すなわち、ノードの知識の一部が１つまたは複数の他のノードと同期が取られる場合に、知識を交換するための一般化された機構を示している。示されるように、各レプリカＡおよびＢは、同期プロバイダＰＡおよびプロバイダＰＢをそれぞれ有する。これに関連して、各レプリカＡおよびＢは、知識Ｋ_ＡおよびＫ_Ｂをそれぞれ維持し、潜在的には、フィルタリングされた知識Ｆ_ＡおよびＦ_Ｂも維持する。部分化（ｓｕｂｓｅｔｔｉｎｇ）のない場合と同様に、レプリカのいずれかが、別のレプリカの変更１１００を要求することができ、変更を伝える他のレプリカに応答して、変更１１１０を受信することができる。図示されるように、レプリカＡは、１１００において、所定の範囲の１組のオブジェクトについての変更を要求することができ、組内のオブジェクトの品質についての情報を含むその知識を送信する。同様に、１１１０において、知識Ｋ_ＡおよびＫ_Ｂの分析に基づいて、１１１０において、レプリカＢは知っているが、レプリカＡは知らない変更が、品質の範囲内にあるオブジェクトについて、レプリカＡに送信される。フィルタリングされた知識Ｆ_Ａとフィルタリングされた知識Ｆ_Ｂが同じ範囲（ｓｃｏｐｅ）内にある場合、一般化された知識交換に関して、
Ｋ_Ａ＝Ｋ_Ａ∪Ｋ_Ｂ
となる。

フィルタリングされた知識Ｆ_Ａとフィルタリングされた知識Ｆ_Ｂが同じ範囲内にない場合、
代わりに、知識は、以下のように、それぞれのフィルターＦ_ＡとＦ_Ｂの共通部分に射影された他のレプリカの知識を既存の知識に加える関数である。

Ｋ_Ａ＝Ｋ_Ａ∪（Ｋ_Ｂ→（Ｆ_Ａ∩Ｆ_Ｂ））
アプリケーションの中でもとりわけ、これらのタイプのフィルターのための例示的で非限定的なアプリケーションは、カラム（ｃｏｌｕｍｎ）、または同期フレームワークの任意の変更ユニット（ｃｈａｎｇｅ ｕｎｉｔ）をフィルタリングするためのものである。システムにおいてカラム変更は移動操作の影響を受ける可能性が低いので、これは特に適用可能である。フィルター表現（ｆｉｌｔｅｒ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）および知識統合（ｋｎｏｗｌｅｄｇｅ ｃｏｎｓｏｌｉｄａｔｉｏｎ）という、留意するに値する２つの検討対象が、このシナリオに関して存在する。

フィルター表現に関して、移動のないフィルターの場合のフィルター表現は、以下のようになる。各フィルターは、フィルター内に含まれる変更ユニットのリストとして表現される。この表現は、表現の便利な手段を提供するばかりでなく、必要な場合にフィルターを組み合わせる能力も提供する。フィルターを組み合わせる能力は、知識を統合するために有益である。

知識統合に関して、知識を最も簡潔な形式に保つため、知識を統合する能力が維持されなければならない。これに関連して、知識を最もコンパクトな形式に維持できるように、フィルタリングされた知識の断片（ｆｒａｇｍｅｎｔ）を統合することができる。

フィルターを組み合わせる能力について検討すると、フィルターは１組の変更ユニットとして表現できるので、両方のフィルターに存在する変更ユニットの組を分離することによって、フィルター内の重複を照合調整することができる。

また、フィルターのためのベクトルは、フィルター内の個々の変更ユニットの各々に適用されるので、フィルターの組み合わせは、両方のフィルター内の各変更ユニットについて、変更ユニットのための合成ベクトルを見つけることによって、実行することができる。その後、ベクトルのすべてが知られると、共通のベクトルを有する変更ユニットが、新しいフィルター内に再度組み合わされる。

フィルターは、デバイス間でどの情報の同期を取るかを制御するための１つの方法であるが、フィルターは一般に、以下でより詳細に説明される実施において提供されるように、アイテムの品質の特性を同期メタデータの一部として扱わない。

したがって、知識の概念は、マルチマスター同期ネットワークの多数のノード間での知識交換のため、データを効率的に表現するために使用することができ、ネットワークのいずれのノードも、ノード間で同期が取られる共通情報または共通情報の一部を独立して進化させることができる。上で説明された知識ベースフレームワークは、マルチマスター同期環境のために実施することができ、以下でより詳細に説明されるように、フレームワークは、効率的な同期メタデータを介したオブジェクトのバージョンの品質についての概念を含むように拡張可能である。
オブジェクトの品質の知識ベース表現
様々な実施形態では、マルチマスター同期トポロジーにおけるデバイスによるデータの効率的な同期が提供され、デバイスは、同期が取られるオブジェクトの品質レベル（例えば、第１のオーディオフォーマットか、それとも第２のオーディオフォーマットか、第１の解像度か、それとも第２の解像度か、もしくは第１のスキーマに準拠するのか、それとも第２のスキーマに準拠するのか）について知っており、またはより一般的に、各デバイスは、オブジェクトのバージョンに適用されるいずれか１つもしくは複数の変換について知っている。個々のエンドポイントが、第１の品質のオブジェクトのバージョン（もしくはオブジェクトのバージョンの第１の変換）と同期を取るべきかどうかを決定でき、または異なる品質を有するオブジェクトのバージョン（もしくはオブジェクトのバージョンの第２のより適切な変換）を有するデバイスを探し出せるように、デバイスは、知識交換の一部としてそのような情報を効率的に伝達することができる。

どのオブジェクトが変化したかについての情報をバージョンを介して効率的に獲得および表現する能力と、それらのオブジェクトが質的にどのように変換されたかについての情報を獲得および表現する能力は、実質的に、オブジェクトの特定のバージョンがエンドポイントにとってどれだけ有益であるかをエンドポイントに告げ、オブジェクトが「変化した」または「異なる」という単なる事実よりも多くの情報が利用可能である。

例えば、ｉＰｏｄは、すべての種類のオーディオファイルを消費することはできず、オーディオファイルの独自仕様フォーマットを再生するのに最もよく適している。対照的に、他のほとんどのＭＰ３プレーヤーは、オーディオファイルのｉＰｏｄ独自仕様フォーマットを再生することができない。したがって、同期言語自体の一部として、異なるオーディオファイル符号化など、同じオブジェクトの異なる品質バージョンについて、知識交換の一部として同期を取ることが望ましいかを、デバイスに決定させることが望ましい。

実施形態の第１の組では、無効化が実施され、それによって、オブジェクトが望まないアイテム（例えば、デバイスのメモリーに対して高すぎる解像度、またはデバイスによってサポートされない異なるスキーマに準拠するオブジェクトのバージョン、またはデバイスが符号化を復号できないなど）を受信した場合、デバイスは、デバイスがそのアイテムを再び受信することを望まないことを同期メタデータが反映するように、そのアイテムを無効化することができる。エンドポイントは、許容できない変換、符号化、忠実度などのバージョンを受信した場合、許容できないオブジェクトバージョンを無効化することができ、実質的に、そのデバイスとの同期プロセスからそのアイテムを削除する。

アイテムは望まれていないので、デバイスによって削除することができ、または他の適切なアクションをオブジェクトに対して取ることができる。別の適切なアクションの例は、オブジェクトのバージョンがデバイスにとって不適切な符号化であるのに、デバイスがそのオブジェクトの復号器を有さない場合に、それにも関わらず、デバイスが、不適切な符号化をデバイスにとって理解可能な符号化にトランスコードするトランスコーダーを有することがある場合とすることができる。そのような場合、オブジェクトを削除する代わりに、デバイスは、オブジェクトを別の符号化に変換し、同期メタデータ内でその変換または新しい品質レベルを表すことができる。

これに関連して、エンドポイントは、将来の同期が許容できないバージョンを再び受け入れることを回避するように、許容できないバージョンについてのメタデータを維持し続ける。しかし、時間とともに、そのような無効化メタデータが、許容し得ないほど増加することがあり得る。要するに、デバイスがそれまでに対話したが好まなかったものすべての記録を維持することは、特に機能が限定されており、多くのオブジェクトを拒否するデバイスの場合、またはめったに遭遇しない品質のオブジェクトの場合、効率的ではない。

しかし、あるコンピューティング同期エコシステムの場合、そのような１組の実施形態は、例えば、デバイスが一般に互換性をもち、類似のアプリケーションならびに類似のメモリーおよび処理能力を有し、デバイスの各々が他のデバイスが知っているすべてを知りたがる可能性が高いため、少数の拒否しかもたらされない可能性が高い同期環境において、きわめて良好に機能することがある。デバイスがハードウェアおよび／またはソフトウェア特徴においてより一層異質になるにつれて、デバイスが他のデバイスが知っているすべてを知りたがらない可能性がより高くなる。その状況は、異なる言語を話す人々と類似している。互いに異なる言語を話す人々の間では、人が他人が理解できる言語を話し始めるまで、多くのコミュニケーションの拒否が発生する。

この点において、オブジェクトのバージョンの品質の概念を、オブジェクト自体のソースであるデバイスに拡張することができる。例えば、時間とともに、デバイスは、特定のノードからの通信のほとんどまたはすべてが低いまたは非互換の品質にあり、したがって、多くが拒否されることを学習することができる。そのような場合、デバイスは、時間とともに、低い品質の別のデバイスと同期を取らず、そのデバイスにとってより関係のある知識を有する、より高い品質のデバイスを待つことを選択することができる。例えば、ＭＰ３プレーヤーは、ｉＰｏｄがｉＰｏｄ独自仕様フォーマットの歌のみを有することを学習した後は、ｉＰｏｄと同期を取らないことを選択することができ、デバイスが将来、ｉＰｏｄとの知識交換および比較を実行しなくて済むようにする。

言及されたように、オブジェクトのバージョンについての品質情報を表現する１つの方法は、デバイスに適さないオブジェクトのバージョンにデバイスが気づき、それを拒否した場合に、オブジェクトを無効化することである。多くの拒否が発生した場合、オブジェクトの数が劇的に増加するにつれて、各デバイスが将来何を受信したくないかについてのデバイス当たりに保存される情報の量が、問題を提示し得る。

無効化する実施形態が、全体として、図１２のフロー図によって示されている。１２００において、様々なノードが、多様なマルチマスター同期環境において、任意のトポロジカルフレームワークに従って、互いに接続することができる。１２１０において、２つ以上のノードが、知識交換を介して同期を開始する。２２０において、他のノードから受信したオブジェクトの各バージョンについて、各ノードは、オブジェクトのバージョンによって表される品質がノードにとって望ましいかどうかを決定する。１２３０において、望ましいかどうかに関わらず、遭遇したバージョンの知識を含むように、同期メタデータが更新される。１２４０において、バージョンが望ましい場合、そのバージョンは同期を取り続け、すなわち、オブジェクトのそのバージョンに関する同期は、将来の知識交換において変わることなく取られ続ける。１２５０において、オブジェクトが望ましくないとノードが決定した場合、バージョンの知識は（将来の知識交換においてノードに対してそのオブジェクトの同期を取らないようにするために）維持されるが、１２６０において、オブジェクトの望ましくないバージョンは削除することができ、またはオブジェクトのそのバージョンに対して、変換などの他のアクションを取ることができる。

無効化する実施形態の動作が、全体として、図１３に示されている。示されるように、最初、１３０２において、ノードＡ１３００とノードＣ１３２０は、同期を取っており、両方のノードがサポートする高精細度オブジェクトＯ１を同期させている。しかし、１３０４において、ノードＡ１００とノードＢ１３１０が同期を取るとき、１３１４において、ノードＢ１３１０は、オブジェクトの高精細度バージョンを保存できないと決定し、そのため、オブジェクトが削除またはより低い精細度バージョンに変換される。例では、簡略にするため、オブジェクトがノードＢ１３１０によって削除される。１３１２において、ノードＢは、ノードＢ１３１０がオブジェクトのそのバージョンと再び同期を取ることを望まないことを反映するように、同期知識を拡大する。

有利には、その後、１３２２において、ノードＣ１３２０がノードＢ１３１０と同期を取るとき、高精細度オブジェクトＯ１は、ノードＢ１３１０がそのバージョンの非所望を反映する知識を有するので、同期が取られない。しかし、１３３２において、後でノードＤ１３３０がノードＢ１３１０と同期を取るとき、低精細度バージョンには除外が存在しないので、ノードＤ１３３０は、オブジェクトＯ１の低精細度バージョンをノードＢ１３１０に同期させる。このようにして、各ノードは、時間とともに、異なる品質のデータの様々なバージョンに対する嫌忌を反映することができ、サポートされないアイテムに対する努力を繰り返して、不必要な同期トラフィックを生じさせることなく、より知的に同期を取ることができる。

代替的な１組の実施形態では、新しい独立したバージョンに値する破壊的変更とは対照的に、品質は、データのバージョンが品質変換をこうむったことが決定されるデータのバージョンのバージョン管理によって、同期メタデータ内で表される。オブジェクトのバージョンに適用される変換または品質レベルの１つの層を表すためのバージョンのバージョン管理に加えて、そのような実施形態は、任意の数のレベルまたは層に、例えば、２層の場合のバージョンのバージョンのバージョン管理、３層の場合のバージョンのバージョンのバージョンのバージョン管理などに拡張することもできる。

有利には、個々のエンドポイントは、オブジェクトに対する特定の変更が、新しいバージョンが生成される、例えば、ティックカウントが増加されるなど、バージョンのバージョン管理をトリガーしない一般的な変更を表すか、それとも代わりに、例えば、現在のティックカウントによって表されるオブジェクトのバージョンをバージョン管理するなど、オブジェクトの現在のバージョンをバージョン管理することによって表されるタイプの、忠実度または変換変更を表すかを決定することが可能である。したがって、バージョン情報のバージョン管理を知識表現に含めることによる知識の拡張は、オブジェクトに対する変換についての質的情報を伝える目的を達成する別の方法である。

バージョン情報をバージョン管理するための例示的な実施形態が、図１４のフロー図に示されている。１４００において、１組のオブジェクトの一部として同期が取られるオブジェクトのバージョンの質的特性が変更される。１４１０において、同期メタデータは、例えば質的変更のためにバージョンがバージョン管理される、オブジェクトのバージョンに対する質的変更を反映した品質情報を含むように拡大される。品質情報が２層である場合、バージョンのバージョンがバージョン管理され、さらに層が増えた場合も同様である。１４２０において、ノードが、マルチマスター同期環境内の別のノードに接続する。

１４３０において、ノードは、同期が取られる１組のオブジェクトのうちのオブジェクトのバージョンについての品質バージョン情報の交換を含む知識交換を介して同期を取る。１４４０において、各ノードは、知識交換に従って更新を列挙し、受信する。その後、オブジェクトの各バージョンについて、各ノードは、品質情報と、ノードが異なる質的特性を有するバージョンの様々なバージョンを望むかどうかを検討する。

同じオブジェクトの異なる質的バージョンに対応するオブジェクトのバージョンの異なるバージョンを表す効率性が、図１５のブロック図にさらに示されている。図１５では、最初に、ノードＡ１５００は、オブジェクトＯの同じバージョンの異なる質的バージョンを有する。示されるように、Ｏ１Ｑ１は、オブジェクトＯの第１のバージョンを表すメタデータを示す表記であり、Ｑ１は、オブジェクトＯ１のバージョンの第１の品質バージョンであることを示す。したがって、ノードＡ１５００は、オブジェクトＯ１の３つの異なる質的バージョンＱ１、Ｑ２、Ｑ３を含む。その後、Ｔ１において、Ｔ１におけるノードＡ１５００とノードＢ１５１０の間の知識交換の後、ノードＢ１５１０は、バージョンＱ１およびＱ２のみを望むことを指定し、その後、それらの同期が取られる。その後、Ｔ２およびＴ３におけるさらなる同期において、オブジェクトＣ１５２０は、品質Ｑ１を有するバージョンのみを望み、一方、オブジェクトＤ１５３０は、品質Ｑ２を有するバージョンのみを望む。したがって、異なる品質の表現は、オブジェクトの多くの不必要で無駄な同期を回避するために、マルチマスター同期環境においてどのバージョンの同期を取るべきかを決定する機会を各デバイスに与える。

図１６は、１組のＡＰＩを介して完全または部分知識交換を実行するためのデバイス１６００の例示的で非限定的な実施のブロック図である。示されるように、デバイス１６００は、非限定的な実施形態による、別のデバイスと１組のオブジェクト１６３０の同期を取るための知識交換技法を実行する同期モジュール１６２０を含む。１組のオブジェクト１６３０は、効率的な動作のためにキャッシュ（図示されず）内に保存することもでき、その場合、１組のオブジェクト１６３０は、オフラインアプリケーションによって後で更新することができる。同期モジュール１６２０は、本明細書で説明されたように、一般に知識交換技法に従ってデータを他のノードに送信し、他のノードから受信するための同期通信モジュール１６２２を含むことができる。

同期通信モジュール１６２２は、例えばオプションの承認モジュール１６４０を介して承認された場合に、第２のデバイスとの同期を開始し、第２のデバイスに接続することができる同期開始モジュール１６２４を含むこともできる。同期モジュール１６２２は、同期の開始に応答して、例えば、知識を取得もしくは送信するため、または変更を取得もしくは送信するために、１組のオブジェクト１６３０についての完全および／または部分知識１６０２をＡＰＩを介して第２のデバイスに送信するＩ／Ｏモジュール１６２６を含むこともできる。同様に、Ｉ／Ｏモジュール１６２６は、第２のデバイスの要求した知識または変更１６１２、および第２のデバイスが起源の１組のオブジェクト１６３０に施された変更を受信することができる。次に、同期分析モジュール１６２８は、１組のオブジェクト１６３０に対して行われた任意の変更を適用するように、またローカルに行われた変更を決定するために、第２のデバイスから受信した知識１６１２を第１のデバイスの知識１６０２と比較するように、またはデバイス間の同期を完了するために第２のデバイスに送信するように動作する。

本明細書の実施形態によれば、図５から図１１に関連して説明されたようなバージョン管理知識１６０３などの、１組のオブジェクト１６３０についてのノードによって所有される知識１６０２は、知識ベースフレームワーク内のオブジェクトに適用される変換についての質的情報を定義する品質知識１６０４を含むように拡大される。

言及されたように、その概要が上で提供された知識フレームワーク内に含まれるメタデータを拡大することによる、オブジェクトのバージョンの知識ベース品質の様々な実施形態が、本明細書で提供された。疑念を避けるために言えば、本明細書で使用される「品質」という用語は、広い意味をもち、データに関する質的特性に影響を与える１つまたは複数の変換または機能に従ってデータを変換できる任意の方法を指す。したがって、品質という用語は、しばしば、文脈固有またはアプリケーション固有である。この点について、上で説明されたように、知識交換の一部として交換される同期メタデータ内にオブジェクトの異なる質的バージョンの概念を含めることによって、各エンドポイントは、コンピューティングシステム内で同期を取ることになった場合に、異なるバージョンにどう対処するかを決定することができる。

同様に、「変換」という用語および「トランスコーディング」という用語は、データを変更するための任意の機能を指す。加えて、「解像度」または「忠実度」の変更という用語は、広く、細部をより多くまたは少なく含むように任意のオブジェクトを変更することを指す。マルチマスター同期環境において複数のネットワークノード間の同期を提供する様々な実施形態が本明細書で説明され、それらは、同期オブジェクト（複数可）の質的変換の概念を含むように知識ベース同期フレームワークを拡張する。

したがって、様々な実施形態の拡張メタデータ表現は、エンドポイントが、オブジェクトの同じバージョンの異なる質的バージョンについてノードと他のノードの間で同期を取ることが望ましいかどうかをノードが決定できるように、オブジェクトに適用される変更がオブジェクトを質的に変換するかどうかを含むオブジェクトに関する知識を効率的に学習し、伝えることを可能にする。その場合、知識交換は、関与するノードにとってオブジェクトのバージョンのどの品質が最も望ましいかについての分析を含むことができ、オブジェクトの望ましくない品質バージョンを、オブジェクトのそれらの品質バージョンを受信することを望まない他のノードに送信する不必要な反復を防止することができる。
例示的なネットワークおよび分散環境
本明細書で説明された同期インフラストラクチャーの様々な実施形態は、コンピューターネットワークの一部としてまたは分散コンピューティング環境内に展開でき、任意の種類のデータストアに接続できる、任意のコンピューターまたは他のクライアントもしくはサーバーデバイスとの関連で実施できることを当業者であれば理解できよう。これに関連して、本明細書で説明された様々な実施形態は、任意の数のメモリーまたはストレージユニット、ならびに任意の数のストレージユニットにわたって発生する任意の数のアプリケーションおよびプロセスを有する、任意のコンピューターシステムまたは環境において実施することができる。これは、リモートまたはローカルストレージを有する、ネットワーク環境または分散コンピューティング環境内に展開されるサーバーコンピューターおよびクライアントコンピューターを有する環境を含むが、それに限定されない。

分散コンピューティングは、コンピューティングデバイスおよびシステム間の通信交換によって、コンピューターリソースおよびサービスの共用を提供する。これらのリソースおよびサービスは、情報の交換、ファイルなどのオブジェクトのキャッシュストレージおよびディスクストレージを含む。これらのリソースおよびサービスは、負荷バランシング、リソースの拡張、および処理の専門化などのための、多数の処理ユニットにわたる処理能力の共用も含む。分散コンピューティングは、ネットワーク接続性を利用し、クライアントが、それらの集団的能力を利用して、企業全体を益することを可能にする。これに関連して、様々なデバイスは、本開示の様々な実施形態のために説明されたような同期インフラストラクチャーを使用できる、アプリケーション、オブジェクト、またはリソースを有することができる。

図１７は、例示的なネットワークまたは分散コンピューティング環境の概略図を提供している。分散コンピューティング環境は、アプリケーション１７３０、１７３２、１７３４、１７３６、１７３８によって表されるような、プログラム、メソッド、データストア、プログラマブルロジックなどを含むことができる、コンピューティングオブジェクト１７１０、１７１２など、およびコンピューティングオブジェクトまたはデバイス１７２０、１７２２、１７２４、１７２６、１７２８などを含む。オブジェクト１７１０、１７１２など、およびコンピューティングオブジェクトまたはデバイス１７２０、１７２２、１７２４、１７２６、１７２８などが、ＰＤＡ、オーディオ／ビデオデバイス、モバイル電話、ＭＰ３プレーヤー、パーソナルコンピューター、ラップトップなど、異なるデバイスを含み得ることは理解できよう。

各オブジェクト１７１０、１７１２など、およびコンピューティングオブジェクトまたはデバイス１７２０、１７２２、１７２４、１７２６、１７２８などは、通信ネットワーク１７４０によって直接的または間接的に、１つまたは複数の他のオブジェクト１７１０、１７１２など、およびコンピューティングオブジェクトまたはデバイス１７２０、１７２２、１７２４、１７２６、１７２８などと通信することができる。図１７では単一の要素として示されているが、ネットワーク１７４０は、図１７のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティングデバイスを含むことができ、ならびに／または図示されていない多数の相互接続ネットワークを表すことができる。各オブジェクト１７１０、１７１２など、または１７２０、１７２２、１７２４、１７２６、１７２８などは、本開示の様々な実施形態に従って提供される同期インフラストラクチャーとの通信または同期インフラストラクチャーの実施に適した、ＡＰＩ、または他のオブジェクト、ソフトウェア、ファームウェア、および／もしくはハードウェアを利用できる、アプリケーション１７３０、１７３２、１７３４、１７３６、１７３８などのアプリケーションも含むことができる。

分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワーク構成が存在する。例えば、コンピューティングシステムは、有線または無線システムによって、ローカルネットワークまたは広域分散ネットワークによって、互いに接続することができる。現在、多くのネットワークが、広域分散コンピューティングのためのインフラストラクチャーを提供し、多くの異なるネットワークを包含する、インターネットに結合されるが、任意のネットワークインフラストラクチャーが、様々な実施形態で説明されたような同期インフラストラクチャーに付随する例示的な通信のために使用できる。

したがって、クライアント／サーバー、ピアツーピア、またはハイブリッドアーキテクチャーなど、多数のネットワークトポロジーおよびネットワークインフラストラクチャーが利用できる。「クライアント」は、それが関係しない別のクラスまたはグループのサービスを使用する、クラスまたはグループのメンバーである。クライアントは、別のプログラムまたはプロセスによって提供されるサービスを要求するプロセス、すなわち、大雑把に言って１組の命令またはタスクとすることができる。クライアントプロセスは、他のプログラムまたはサービス自体についてのいかなる作業詳細も「知る」必要なしに、要求したサービスを利用する。

クライアント／サーバーアーキテクチャー、特にネットワークシステムでは、クライアントは通常、別のコンピューター、例えばサーバーによって提供される共用ネットワークリソースにアクセスするコンピューターである。図１７の図では、非限定的な例として、コンピューター１７２０、１７２２、１７２４、１７２６、１７２８などが、クライアントと考えることができ、コンピューター１７１０、１７１２などが、サーバーと考えることができ、サーバー１７１０、１７１２などは、クライアントコンピューター１７２０、１７２２、１７２４、１７２６、１７２８などからのデータの受信、データの保存、データの処理、クライアントコンピューター１７２０、１７２２、１７２４、１７２６、１７２８などへのデータの送信などの、データサービスを提供するが、状況に応じて、任意のコンピューターをクライアント、サーバー、またはその両方と見なすことができる。これらのコンピューティングデバイスのいずれかは、１つまたは複数の実施形態のために本明細書で説明されたような同期インフラストラクチャーに関連し得る、処理データ、同期または要求サービスまたはタスクとすることができる。

サーバーは一般に、インターネットまたはワイヤレスネットワークインフラストラクチャーなどのリモートまたはローカルネットワークを介してアクセス可能なリモートコンピューターシステムである。クライアントプロセスは、第１のコンピューターシステムにおいてアクティブとすることができ、サーバープロセスは、第２のコンピューターシステムにおいてアクティブとすることができ、それらは通信媒体を介して互いに通信し、したがって、分散機能を提供し、多数のクライアントがサーバーの情報収集能力を利用することを可能にする。同期インフラストラクチャーに従って利用される任意のソフトウェアオブジェクトは、スタンドアロンで提供することができ、または多数のコンピューティングデバイスもしくはオブジェクトにわたって分散することができる。

通信ネットワーク／バス１７４０がインターネットであるネットワーク環境では、例えば、サーバー１７１０、１７１２などは、ハイパーテキスト伝送プロトコル（ＨＴＴＰ）など、多くの知られたプロトコルのいずれかを介して、クライアント１７２０、１７２２、１７２４、１７２６、１７２８などが通信するウェブサーバーとすることができる。サーバー１７１０、１７１２などは、分散コンピューティング環境に特徴的なように、クライアント１７２０、１７２２、１７２４、１７２６、１７２８などとして機能することもできる。
例示的なコンピューティングデバイス
言及されたように、有利には、本明細書で説明された技法は、コンピューティングシステムにおいて他のオブジェクトと同期を取るのが望ましい任意のデバイスに適用することができる。したがって、ハンドヘルド、ポータブル、および他のコンピューティングデバイス、ならびにすべての種類のコンピューティングオブジェクトが、様々な実施形態と関連して、すなわち、デバイスが同期を取ることができるどこででも、使用されることが企図されていることを理解されたい。したがって、以下図１８で説明される以下の汎用リモートコンピューターは、コンピューティングデバイスの単なる一例にすぎない。

必ずしも必要ではないが、実施形態は、デバイスもしくはオブジェクト用のサービスのデベロッパーによって使用するために、オペレーティングシステムを介して部分的に実施することができ、および／または本明細書で説明された様々な実施形態の１つもしくは複数の機能態様を実行するように動作するアプリケーションソフトウェア内に含まれることができる。ソフトウェアは、クライアントワークステーション、サーバー、または他のデバイスなど、１つまたは複数のコンピューターによって実行される、プログラムモジュールなどのコンピューター実行可能命令という一般的な文脈において説明することができる。コンピューターシステムが、データを伝達するために使用できる様々な構成およびプロトコルを有し、したがって、特定の構成またはプロトコルを限定的なものと見なすべきではないことを当業者であれば理解されよう。

したがって、図１８は、本明細書で説明された実施形態の１つまたは複数の態様を実施できる適切なコンピューティングシステム環境１８００の一例を示しているが、上で明確にしたように、コンピューティングシステム環境１８００は、適切なコンピューティング環境の一例にすぎず、使用または機能の範囲に関していかなる限定も暗示しようとは意図していない。コンピューティング環境１８００は、例示的な動作環境１８００内に示されたコンポーネントのいずれか１つまたは組み合わせに関して、何らかの依存性または必要性を有すると解釈されるべきではない。

図１８を参照すると、１つまたは複数の実施形態を実施するための例示的なリモートデバイスは、コンピューター１８１０の形態をとる汎用コンピューティングデバイスを含む。コンピューター１８１０のコンポーネントは、限定することなく、処理ユニット１８２０、システムメモリー１８３０、およびシステムメモリーを含む様々なシステムコンポーネントを処理ユニット１８２０に結合するシステムバス１８２２を含むことができる。

コンピューター１８１０は一般に、コンピューター１８１０によってアクセスできる任意の利用可能媒体とすることができる様々なコンピューター可読媒体を含む。システムメモリー１８３０は、リードオンリーメモリー（ＲＯＭ）および／またはランダムアクセスメモリー（ＲＡＭ）などの揮発性および／または不揮発性メモリーの形態をとるコンピューター記憶媒体を含むことができる。限定することなく例を挙げると、メモリー１８３０は、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータも含むことができる。

ユーザーは、入力デバイス１８４０を介してコンピューター１８１０にコマンドおよび情報を入力することができる。モニターまたは他のタイプの表示デバイスも、出力インタフェース１８５０などのインタフェースを介してシステムバス１８２２に接続される。モニターに加えて、コンピューターは、出力インタフェース１８５０を介して接続できる、スピーカーおよびプリンターなどの他の周辺出力デバイスも含むことができる。

コンピューター１８１０は、リモートコンピューター１８７０などの１つまたは複数の他のリモートコンピューターへの論理接続を使用して、ネットワークまたは分散環境において動作することができる。リモートコンピューター１８７０は、パーソナルコンピューター、サーバー、ルーター、ネットワークＰＣ、ピアデバイスもしくは他の共通ネットワークノード、または他の任意のリモート媒体消費もしくは伝送デバイスとすることができ、コンピューター１８１０に関して上で説明された要素のいずれかまたはすべてを含むことができる。図１８に示される論理接続は、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）などのネットワーク１８７２を含むが、他のネットワーク／バスを含むこともできる。そのようなネットワーク環境は、家庭、オフィス、企業規模のコンピューターネットワーク、イントラネット、およびインターネットにおいて一般的である。

上で言及されたように、例示的な実施形態が様々なコンピューティングデバイスおよびネットワークアーキテクチャーに関連して説明されたが、基礎をなす概念は、任意のネットワークシステム、および同期を取ることが望ましい任意のコンピューティングデバイスまたはシステムに適用することができる。

また、アプリケーションおよびサービスが同期インフラストラクチャーを使用することを可能にする、例えば、適切なＡＰＩ、ツールキット、ドライバーコード、オペレーティングシステム、コントロール、スタンドアロンまたはダウンロード可能ソフトウェアオブジェクトなど、同一または類似の機能を実施するための多数の方法が存在する。したがって、本明細書の実施形態は、ＡＰＩ（または他のソフトウェアオブジェクト）の観点からばかりでなく、同期機能を提供するソフトウェアまたはハードウェアオブジェクトからも企図される。したがって、本明細書で説明された様々な実施形態は、全部がハードウェアである態様、部分的にハードウェアで、部分的にソフトウェアである態様、およびソフトウェアの態様を有することができる。

「例示的（ｅｘｅｍｐｌａｒｙ）」という語は、本明細書では、例、例証、または実例として役立つことを意味するために使用される。疑念を避けるために言えば、本明細書で開示される主題は、そのような例によって限定されない。加えて、「例示的」として本明細書で説明された任意の態様または設計は、他の態様または設計よりも好ましいまたは有利であると解釈される必要はなく、当業者に知られる等価の例示的な構造および技法を排除することを意味するものでもない。さらに、「含む（ｉｎｃｌｕｄｅｓ）」、「有する（ｈａｓ）」、「含む（ｃｏｎｔａｉｎｓ）」という用語、および他の類似の語が詳細な説明または特許請求の範囲において使用される限り、疑念を避けるために言えば、そのような用語は、任意の追加要素または他の要素を排除しない開かれた移行語としての「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語と類似の仕方で包含的であることを意図している。

「限定された品質」という用語は、オブジェクトの存在の開始および／または終了が制限されるような、同期システムにおけるオブジェクトの存在に対する制限を指す。

言及されたように、本明細書で説明された様々な技法は、ハードウェアもしくはソフトウェアに関連して、または適切な場合には両方の組み合わせに関連して実施することができる。本明細書で使用される「コンポーネント」および「システム」などの用語も同様に、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中ソフトウェアといったコンピューター関連エンティティーを指すことを意図している。例えば、コンポーネントは、限定することなく、プロセッサー上で実行中のプロセス、プロセッサー、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピューターとすることができる。例えば、コンピューター上で実行中のアプリケーションおよびコンピューターは、コンポーネントとすることができる。１つまたは複数のコンポーネントが、プロセスおよび／または実行スレッド内に存在することができ、コンポーネントは、１つのコンピューター上に局在すること、および／または２つ以上のコンピューター間に分散することができる。

上述のシステムは、いくつかのコンポーネント間の対話に関して説明された。そのようなシステムおよびコンポーネントが、それらのコンポーネントもしくは特定のサブコンポーネント、特定のコンポーネントもしくはサブコンポーネントのいくつか、および／または追加のコンポーネントを、それらの様々な順列および組み合わせに従って含むことができることが理解できよう。サブコンポーネントは、親コンポーネント内に含まれる（階層的である）代わりに、他のコンポーネントに通信可能に結合されたコンポーネントとして実施することもできる。加えて、１つまたは複数のコンポーネントは、集約機能を提供する単一のコンポーネントに組み合わせること、またはいくつかの別個のサブコンポーネントに分割することができ、統合機能を提供するために、そのようなサブコンポーネントに通信可能に結合する、管理層などの任意の１つまたは複数の中間層を提供できることに留意されたい。本明細書で説明されたコンポーネントはいずれも、本明細書で特に説明されないが、当業者に一般に知られている、１つまたは複数の他のコンポーネントと対話することもできる。

上で説明された例示的なシステムに鑑みて、説明された主題に従って実施できる方法は、様々な図のフローチャートを参照することでより良く理解されよう。説明を簡素にする目的で、方法は一連のブロックとして示され、説明されたが、いくつかのブロックは本明細書で叙述および説明されたのとは異なる順序ならびに／または他のブロックと同時に生じることができるので、特許請求される主題はブロックの順序によって限定されないことを理解および認識されたい。非順次的または分岐するフローがフローチャートを介して示された場合、同一または類似の結果を達成する他の様々な分岐、フロー経路、およびブロックの順序が実施できることが理解できよう。さらに、これ以降で説明される方法を実施するために、図示されたブロックのすべてが必ずしも必要とされるわけではない。

本明細書で説明された様々な実施形態に加えて、対応する実施形態から逸脱することなく、それらと同一または等価の機能を実行するために、他の類似の実施形態が使用でき、または説明された実施形態に変更および追加を施し得ることを理解されたい。またさらに、多数の処理チップまたは多数のデバイスは、本明細書で説明された１つまたは複数の機能の実行を分担することができ、同様に、ストレージは、複数のデバイスにわたって達成することができる。したがって、本発明は、任意の単一の実施形態または１組の実施形態に限定されず、むしろ添付の特許請求の範囲に従った広さ、主旨、および範囲において解釈されるべきである。

Claims (21)

1. マルチマスター同期環境において１つまたは複数のネットワークを介して通信可能に結合される複数のノードのうちの第１のノードと第２のノードの間で１組のオブジェクトの同期を取るための方法であって、
   与えられたデータ範囲について、前記第１のノードと前記第２のノードの間で、両ノード上で表現される１組のオブジェクトについての同期知識を交換するステップ（３２０）であって、前記第１のノードおよび前記第２のノードの同期知識が、それぞれ、前記第１のノードおよび前記第２のノード上で表現される前記１組のオブジェクトのうちのオブジェクトの対応するバージョンを表す同期メタデータを含み、前記同期知識の表現が、データタイプから独立である、ステップと、
   前記同期知識交換に基づいて、どちらが他方のノードに対して受信ノードになってもよい前記第１のノードまたは前記第２のノードによって、前記受信ノード上で表現されるオブジェクトに適用された第２の変換とは異なる、対応するオブジェクトに適用された第１の変換を有する、前記１組のオブジェクトのうちのオブジェクトを受信し、前記第１の変換が前記第２の変換とは異なる品質であることを認識するステップ（３４０）と、
   前記第１の変換が適用された前記オブジェクトのバージョンについての前記受信ノードによる知識と、前記第２の変換が適用された前記オブジェクトのバージョンについての知識とを表す変換メタデータを含むように、前記受信ノードの前記同期メタデータを更新するステップ（３６０）と
   を含む方法。
2. 少なくとも１つの事前定義された基準に基づいて、前記第１の変換が適用された前記オブジェクトが、前記受信ノードにとって望ましいかどうかを決定するステップ（３４０）であって、決定する前記ステップが、第１の変換機能を第２の変換機能と比較するステップを含む、ステップ
   をさらに含む請求項１に記載の方法。
3. 前記第１の変換が適用された前記オブジェクトが前記受信ノードにとって望ましくない場合、前記受信ノードによって前記オブジェクトを削除するステップ（３５０）
   をさらに含む請求項２に記載の方法。
4. 前記第１の変換が適用された前記オブジェクトが前記受信ノードにとって望ましくない場合、前記受信ノードが前記第１の変換が適用された前記オブジェクトの前記バージョンについて知らされたが、前記マルチマスター同期環境における他のノードとの将来の知識交換の一部として、前記バージョンを受信することを望んでいないことを反映するように、前記受信ノードの前記同期メタデータを更新することによって、前記オブジェクトを無効化するステップ（３６０）
   をさらに含む請求項３に記載の方法。
5. 前記同期メタデータを更新する前記ステップ（３６０）が、同じ前記オブジェクトに対して異なる前記第１の変換および前記第２の変換についての知識を表す変換メタデータを用いて前記同期メタデータを拡大するステップをさらに含む、
   請求項１に記載の方法。
6. 前記同期メタデータを更新する前記ステップ（３６０）が、異なる第１の変換および第２の変換が適用された前記オブジェクトについての知識を表し、前記受信ノードが前記第１の変換が適用可能な前記オブジェクトを削除したか、それとも前記第２の変換が適用可能な前記オブジェクトを削除したかを表す変換メタデータを用いて前記同期メタデータを拡大するステップをさらに含む、
   請求項１に記載の方法。
7. 変換メタデータを含むように前記受信ノードの前記同期メタデータを更新する前記ステップ（３６０）が、将来の知識交換によって、前記受信ノードが同じまたは他のノードから前記削除されたオブジェクトを再び受信する結果がもたらされないよう防止する、請求項６に記載の方法。
8. 前記同期メタデータを拡大する前記ステップ（１２５０）が、前記受信ノードが前記第１の変換が適用可能な前記オブジェクトを削除したか、それとも前記第２の変換が適用可能な前記オブジェクトを削除したかを表すブール値を用いて、前記オブジェクトについての前記同期メタデータを拡大するステップを含む、
   請求項６に記載の方法。
9. 交換する前記ステップ（３２０）が、前記データ範囲内で、それぞれ、ローカル同期知識または外部同期知識の一部として前記第１のノードまたは前記第２のノードによって学習されたが、前記第１のノードまたは前記第２のノード上で削除された任意のオブジェクトに対する考慮を含みながら、前記第１のノード上で表現される前記１組のオブジェクトに関する前記第１のノードのローカル同期知識を前記第２のノードの外部同期知識と比較するステップ（３３０）を含む、請求項１に記載の方法。
10. 比較する前記ステップに基づいて、前記第２のノード上で表現される前記１組のオブジェクトについての前記外部知識に対する変更と、前記第２のノード上で表現される前記１組のオブジェクトに対する対応する変更とを決定するステップ（１０６０）と、
    前記外部知識に対する前記変更と、前記１組のオブジェクトに対する前記対応する変更とを前記第２のノードに送信するステップ（１０６０）と
    をさらに含む請求項９に記載の方法。
11. マルチマスター同期環境において複数のノードのうちのノードと別のノードの間で１組のオブジェクトの同期を取る、１つまたは複数のネットワークを介して接続可能な前記複数のノードのうちのノードであって、
    前記複数のノードのうちの前記ノードと前記他のノードの間で前記１組のオブジェクトの同期を取るための同期コンポーネント１６２０であって、
    データタイプとは独立に、前記他のノードと前記ノードの間の知識交換のためのメタデータ構造を定義する同期プロトコルを介して、前記他のノードとの同期を開始し、前記同期プロトコルに基づいて、前記１組のオブジェクトの同期を取るための要求を前記他のノードに送信し、それに応答して、前記他のノード上で表現される前記１組のオブジェクトに対応する他のノードオブジェクトの第１のバージョン管理情報と、前記他のノードオブジェクトの第１のバージョン管理情報に対応する他のノードオブジェクトの第２のバージョン管理情報とを含む前記１組のオブジェクトについての外部知識を前記他のノードから受信する、同期通信コンポーネント１６２２であって、前記他のノードオブジェクトの第２のバージョン管理情報が、前記他のノードオブジェクトの第１のバージョン管理情報をバージョン管理し、前記他のノードオブジェクトの第１のバージョン管理情報によって表される前記１組のオブジェクトのバージョンについての異なる忠実度レベルを表す、同期通信コンポーネント１６２２と、
    前記１組のオブジェクトについての前記外部知識、対応する他のノードオブジェクトの第１のバージョン管理情報、および他のノードオブジェクトの第２のバージョン管理情報を、前記１組のオブジェクトについての前記ローカル知識、対応するノードオブジェクトの第１のバージョン管理情報、および前記ノードオブジェクトの第１のバージョン管理情報のバージョンをバージョン管理した対応するノードオブジェクトの第２のバージョン管理情報と比較して、前記１組のオブジェクトの更新されるローカル知識、対応するノードオブジェクトの第１のバージョン管理情報、および対応するノードオブジェクトの第２のバージョン管理情報によってどの変更が反映されるべきかを決定することによって、前記ノード上で表現される前記１組のオブジェクトについてのローカル知識と、対応するノードオブジェクトバージョン管理情報を更新する、同期分析コンポーネント１６２８と
    を含む同期コンポーネント１６２０
    を含むノード。
12. 対応するノードオブジェクトの第１のバージョン管理情報および対応するノードオブジェクトの第２のバージョン管理情報を有する前記更新されるローカル知識によって表される前記１組のオブジェクトのうちの各オブジェクトについて、前記同期分析コンポーネント１６２８が、前記ノードおよび前記他のノード上で表される第２のバージョン管理情報を、前記第１のバージョン管理情報によって表される前記オブジェクトの与えられた第１のバージョンと比較して、前記第２のバージョン管理情報によって表される前記与えられた第１のバージョンの与えられた第２のバージョンが、前記ノードまたは前記他のノードにとって同期を取るのが望ましいかどうかを決定する、請求項１１に記載のノード。
13. 前記同期プロトコルが、前記ノードと前記他のノードの間で同期が取られる実際のデータのいかなるスキーマも規定しない、請求項１１に記載のノード。
14. マルチマスター同期環境において１つまたは複数のネットワークを介して通信可能に結合される複数のノードのうちの第１のノードと第２のノードの間で１組のオブジェクトの同期を取るための方法であって、
    前記第１のノードによって前記１組のオブジェクトのうちの少なくとも１つのオブジェクトの質的特性を変更するステップ（１４００）と、
    前記質的特性に対する前記変更を表す品質メタデータを含むように、前記少なくとも１つのオブジェクトに関する前記第１のノードの同期知識メタデータを更新するステップ（１４１０）であって、前記同期知識メタデータの表現が、データタイプから独立である、ステップと、
    前記第１のノードによって前記第２のノードに前記第１のノードの前記更新された同期知識メタデータを送信するステップを含む、前記第１のノードによって前記第２のノードと同期を取るステップ（１４３０）であって、送信する前記ステップが、前記第１のノード上で表現される前記１組のオブジェクトのバージョンに対応する前記１組のオブジェクトのうちのオブジェクトのバージョンメタデータと、前記１組のオブジェクトの前記バージョンに関連する任意の対応する品質メタデータとを送信するステップを含む、ステップと
    を含む方法。
15. 更新する前記ステップ（１４１０）が、前記少なくとも１つのオブジェクトの前記質的特質の前記変更に応答して変更するステップを含む、
    請求項１４に記載の方法。
16. 変更する前記ステップが、前記第１のノードによって定義された少なくとも１つの基準に基づいて、前記少なくとも１つのオブジェクトの前記質的特質を変更することを決定するステップ（１４４０）
    をさらに含む、請求項１４に記載の方法。
17. 決定する前記ステップ（１４４０）が、変更する前記ステップが、前記少なくとも１つのオブジェクトによって表されるデータを、実質的に前記データを破壊することなく変換することを決定するステップを含む、請求項１６に記載の方法。
18. 決定する前記ステップ（１４４０）が、変更する前記ステップが、前記少なくとも１つのオブジェクトによって表されるデータを、実質的に前記データの忠実度を変更することなくトランスコードすることを決定するステップを含む、請求項１６に記載の方法。
19. 決定する前記ステップ（１４４０）が、変更する前記ステップが、前記少なくとも１つのオブジェクトによって表されるデータを、前記データの忠実度を低下させて変換することを決定するステップを含む、請求項１６に記載の方法。
20. 決定する前記ステップ（１４４０）が、変更する前記ステップが、前記少なくとも１つのオブジェクトによって表されるデータを、前記データの忠実度を向上させて変換することを決定するステップを含む、請求項１６に記載の方法。
21. 前記質的特性に対する前記変更を表すように、前記第１のノードの前記同期知識メタデータを更新する前記ステップ（１４１０）が、前記少なくとも１つのオブジェクトの現在のバージョンメタデータを変更せずにおくステップと、前記現在のバージョンメタデータとともに、前記少なくとも１つのオブジェクトの同じバージョンの異なる品質を区別する追加的な品質バージョンメタデータを保存するステップとを含む、請求項１６に記載の方法。

Images