JP4685869B2 - 状態ベースの同期 - Google Patents

Description

コンピュータ・プログラム・リスト
次の表に、参照として本明細書に組み込まれる、読み取り専用形式によるコンパクト・ディスクにリストされているコンピュータ・プログラム・リストとして提供される２２のソース・コード・ファイルを示す。

同期は、データ・セット間に一貫性を提供し、または維持する機能である。例えば、デスクトップ・コンピュータは、個人情報管理（「ＰＩＭ」）に関するデスクトップ・データ・セットを有する。そのデスクトップ・コンピュータのユーザは、自分がそのデスクトップ・コンピュータを離れた際にもＰＩＭデータを使用することを希望することがある。したがって、そのユーザは、ラップトップ・コンピュータ、または電話機や小型デバイスなどの他のデバイスのような携帯情報端末（「ＰＤＡ」）を使用中に、ＰＩＭデータにアクセスすることを希望する場合がある。そのような希望に対応するために、そのユーザのラップトップ・コンピュータやＰＤＡは、デスクトップ・コンピュータのＰＩＭデータ・セットに対応するＰＩＭデータ・セットをそれぞれ保持する。この同期機能の役割は、ユーザに自分のデータをそれぞれのデバイスで閲覧させることである。この役割は、一般に、複数のデバイスが同期する際に、同期イベントにより達成される。

デバイスを同期させる一般的な技術は、その時点でのデータのスナップショットを使用して、現行データとスナップショットとを比較し、何が変更されたかを特定することによりなされる。説明のために、図１を参照すると、デスクトップ・コンピュータ１００と携帯コンピュータ１１０の２つのデバイスのモデルが示されている。デスクトップ・コンピュータは、デスクトップ・コンピュータ１００で編集または追加された、ＰＩＭデータ・セットに対する現行情報を保持するＰＩＭデータベース１０１を有する。デスクトップ・コンピュータ１００は、ある時点で、典型的には以前の同期時点（恐らくは、最近の同期）でとられた、ＰＩＭデータ・セットのスナップショットである、デスクトップ・スナップショット・データベースも有する。同様に、携帯コンピュータ１１０は、現行ＰＩＭデータに対する携帯データベース１１１を有する。これらの構造を適所に配置して、デスクトップ１００と携帯１１０との同期を試みることができる。典型的な同期は、携帯データベース１１１とデスクトップ・データベース１０１との両方をスナップショット・データベース１０２と比較することにより行われる。次いで比較動作中に、データベース１０２と比較して、アクティブなデータベース１０１と１１１にある新しい、または変更されたデータ・アイテムのリストを組み立てる。最後に、この同期を終了するために、すべての３つのデータベース１０１、１０２、１１１を更新するように、新しい、変更されたデータのリストを使用する。

対応するデータがデスクトップと携帯との両方で変更された場合に、上記の同期プロセスで問題が発生する。例えば、同期以前のある時点でＪａｎｅ Ｄｏｅの電話番号がデスクトップでは８７７−５５５−５５５５に、携帯では８００−５５５−５５５５に変更されたと仮定する。比較動作中（または別の時点で）、同期システムはこの不一致に気づき、齟齬を識別する。現行技術では、一般的に、確実にこの齟齬を解決するエレガントな方法はない。いくつかの解決策は、ユーザにインターフェースを提示し、そのユーザに２つの選択肢から選択するよう要求する。残念ながら、そのユーザでさえもどのデータが正確かを思い出すことはできない。他の解決策は、各データベースに単純に複製項目を作成する（可能なデータ・アイテムのそれぞれに１つ）。

対応するデータ・セットを保持するデバイスが複数ある場合、この問題はさらに悪化する。例えば図１を参照して、形態１１０との同期の後で、デスクトップ１００がＰＤＡ１２０との同期を試みると仮定する。同期中、ＰＤＡ１２０がＪａｎｅ Ｄｏｅの電話番号を８８８−５５５−５５５と保持していることが分かる。残念ながら、従来技術では、ここでも確実に正確な結果を特定するエレガントな解決策がない。さらに、ここで正確な結果を特定することができたとしても（例えば、記憶しているユーザによって）、次に携帯１１０が同期された際に、システムに同じ問題が再度発生することを阻止できないであろう。

最後に、３つ以上のピアを有するピア・ツー・ピア・システムに対して問題が発生する。この問題の発生は、ピアが同時に２つが互いにそれぞれと同期し、齟齬が発生すると、いくつかのピアの１つがさらなる最新データを保持するかどうかを決して知ることができないというものである。タイム・スタンプは確実にその齟齬を解決することができないことは、注目に値する。これは、実際に人間が使用するものとして、２つの対応するデータ・アイテムが過去数日または数ヶ月間に変更された場合、それは第２の変更が正確であることを必ずしも意味するものではない。これは、第２の変更が別のピアとの同期の結果として発生した場合には、特に言えることである（このような「別のピア」は、遥か以前にそのデータ変更を受け取っている場合がある）。したがって、ピア・ツー・ピアの状況では、検出された齟齬が、一方では本当の齟齬であるか、他方ではデータの履歴を理解するなら検証可能な形で解決することのできる見かけの齟齬であるか、判定することはできない。

同期に関する他の関連の従来技術は、参照のため本明細書に組み込んだ、コンピュータ・システム間で情報を同期し、アーカイブに保管するための方法という、米国特許、５，７１０，９２２で見ることができる。さらに、２００４年５月２４日出願の、整理番号＿＿＿＿の、Ｔｏｂｙ ＰａｔｅｒｓｏｎおよびＪｅｒｏｍｅ Ｌｅｂｅｌによる「３つ以上のデバイス間で同期する方法（Ａ Ｍｅｔｈｏｄ ｏｆ Ｓｙｎｃｈｒｏｎｉｓｉｎｇ Ｂｅｔｗｅｅｎ Ｔｈｒｅｅ ｏｒ Ｍｏｒｅ Ｄｅｖｉｃｅｓ）」という名称の係属中の出願と、２００４年５月２４日出願の、整理番号＿＿＿＿の、Ｔｏｂｙ ＰａｔｔｅｒｓｏｎおよびＪｅｒｏｍｅ Ｌｅｂｅｌによる「同期方法（Ａ Ｍｅｔｈｏｄ ｏｆ Ｓｙｎｃｈｒｏｎｉｓｉｎｇ）」という名称の係属中の出願とが、参照により本明細書に組み込まれる。

本明細書における検討ならびに従来技術にある他の問題点に鑑みて、本発明のある実施態様は、（ｉ）すべての非齟齬データを適切に同期すること、（ii）本当の齟齬を検出し、その齟齬が本物ならば、それを解決するためにユーザにインターフェースを与えるだけですむこと、（iii）同じデータに対する同じ齟齬を解決するようユーザに２度要求することを回避することの３つの目標を同期システムに提案する。

これらの目標を従来技術に適用して、既存の同期システムが、一般に非齟齬データを正確に同期することができるという点で、第１の目標を達成することが確認された。しかし、第２と第３の目標を満足させるには、例えば上記でタイム・スタンプを参照したように、いくつかのタイプのメタデータを保持する必要がある。いくつかの従来技術によるシステムは、これらの目標を達成するためにメタデータを使用することを試みるが、どれも完全には成功しない。

本明細書に記載の実施態様は、同期システムおよび方法に役立つための履歴情報を使用することに関する。非常に簡単な実施態様では、履歴情報は、データ・ベースごとに保持される世代カウント情報ほどに小さい情報である（このコンテキストでは、データはデータ・アイテムまたはデータ・アイテムの集合体に関する）。データが同期される場合に、世代カウント情報が同期される。次いで齟齬するデータの優先権に関するより良い理解を得るために、同期中に世代カウントが使用される。

本発明の他の実施態様は、データ・アイテムに関する履歴情報のより豊富な形式を使用する。いくつかの実施態様では、デバイスに記憶されている各データ・アイテムは状態に関連付けられる。データ・アイテムが変更されるたびに、状態は変更される（例えば、増分される）。履歴情報は、状態をデータに対する変更に関連付けることにより、維持される。いくつかの実施態様では、履歴に関する単一ステートメントが履歴の同じ増分を経験した多くのデータ・アイテムと関連付けることができるように、履歴情報は本質的に包括的である。例えば、ユーザが１０個のデータ・アイテムを作成した場合、いくつかの実施態様は、この履歴を記録するために状態を１つだけ使用する（例えば、ユーザはデバイスＸでデータを作成した）。したがって、１０個の作成されたデータ・アイテムのそれぞれを同じ状態と関連付けることができる。１０個のデータ・アイテムの１つが変更される場合、その状態は変更され、残り９個のアイテムは古い状態を維持する。次いで変更されたデータ・アイテムは、その変更に関する別の履歴ステートメントと関連付けられた状態を有する（例えば、ユーザがデバイスＸでデータを編集した）。さらに、第１の作成された状態は、第２の作成されたデータの祖先のまま残る。この方法で、比較的少ない状態（および関連付けられた包括的な履歴ステートメント）を、非常に多くの個体数を有するデータ・アイテムでの変更を追跡するために使用することができる。

複数のデバイスが、対応するデータ・セットに対する例示の履歴の維持を活用すると仮定すると、各デバイスがすべてのデバイス（少なくとも同期の時刻による時間的意味で）のデータ・アイテムに関する状態情報を理解するように、それらデバイスは履歴情報を同期する。履歴情報が一度同期されると、データ・アイテムの祖先は履歴情報を参照することにより特定することができるので、データ・アイテムの同期の基礎として機能させることができる。例えば、データ・アイテムが同期中に齟齬する場合、その齟齬は、あるデータ・アイテムが他のデータ・アイテムの祖先か子孫かを判定するために、履歴情報を検査することにより解決することができる。

Ｉ．語彙および非限定
本開示を通して、本発明者らは、同期技術と例示を検討するために、ある種の語彙を使用する。検討する説明の大部分は、同じＰＩＭデータと同期に関するものである。しかし、本発明の多くの実施形態は、事実上いかなる種類のデータにも適用されることを明白に目的としている。本明細書で教示する技術を使用して同期することのできるいくつかのデータ例には、テキスト・ファイル、ワード・プロセッシング・ファイル、ファイル・システムからのファイル、ｊｐｅｇ、ｍｐ３、ｍｐｅｇ２、ｍｐｅｇ４、またはｗａｖファイルなどのメディア・ファイル、データベースからの記録、または特定用途に関連するか否かに関わらない、いかなる他のデータ・ファイル・タイプがある。

ここで、本発明者らの説明を目的とした実施形態の大部分の表現に戻ると、本発明者らは、原則としてＰＩＭデータに関して本発明を検討する。一般に、本発明者らは、ＰＩＭデータにアクセスするために使用されるコンピュータ、ＰＤＡ、電話機または他のインテリジェント・デバイスなどのデバイスについて検討する。それぞれのデバイスは、一般に、通常はデバイスに常駐の１つまたは複数のプロセスである同期クライアントと関連付けられている。場合により、第１のデバイスは、別のデバイスに常駐している同期クライアントを有する（これをプロキシと呼ぶ）。これは、第１のデバイスが、同期クライアントをホストするには十分に装備されていないためである。あるいは、マルチピア・システムでは、同期システムは、多くのピアが存在しない場合でも、すべてのピアを同期させるために相互のピアに対してローカル・プロキシを使用する（プロキシは、存在しないデバイスの代役を務める）。

ＰＩＭデータ自体は、一般に、個人的な連絡、カレンダ項目、ノート、日記の項目などとして生じる。本発明者らが記録について検討する場合は、一般に、相互関連した一組のデータ・アイテムに関して検討する。例えば、Ｊｏｈｎ Ｄｏｅの個人連絡カードを、電話番号、住所、ポケットベル番号、様々なその他のデータ・アイテムがＪｏｈｎ Ｄｏｅとの共通の関連付けにより相互関連している記録として見ることができる。単一のデバイスにあるＰＩＭデータの各アイテムは、１つまたは複数の他のデバイスにある１つまたは複数の対応するデータ・アイテムを有する場合がある。例えば、Ｊｏｈｎ Ｄｏｅの住所は、Ｊａｎｅ Ｄｏｅのデスクトップ・コンピュータ、携帯型コンピュータ、ＰＤＡ、電話機のそれぞれの対応するデータ・アイテムを有している。同様に、ここでのデータがデジタル写真の場合、デスクトップ・コンピュータにあるＪｏｈｎ Ｄｏｅの写真は、ＰＤＡ、携帯型コンピュータ、その他の場所にあるＪｏｈｎの対応する写真を有する。多くのデバイスすべてで、対応データの共通する表示（可能な限り）を提供することが、同期機能の役割である。

II．サンプルのハードウェア構造とソフトウェア構造
本明細書に記載の技術は、事実上いかなる構造上の状況においても実施することができるが、ここでは、説明のためにいくつかの例示の構造上の実施形態について述べる。図２を参照すると、ＰＤＡまたは電話機などのサンプルの携帯型デバイスが示されている。上記のように、クライアント・デバイスは、ユーザに対してデータにアクセスし、またはデータを編集するのに役立つ十分な知能のある、いなかるアイテムでも実施することができる。したがって、図２のデバイスは、限定はしないが、あらゆるそのようなデバイスのサンプルをも説明することを目的としている。デバイス２００の正面図２０１は、データを参照し、またはデータにアクセスするため、データを入力するために使用することのできる画面２０４を示す（タッチセンシティブな、または入力装備された画面例）。英数字などによるデータ入力のためにキーパッド２０５を使用することもでき、または電力および／またはデータ転送のために有線接続２０６を使用することもできる。無線ポート２０３は、赤外線、Ｂｌｕｅｔｏｏｔｈ、８０２．１１、またはデバイス２００内外のデータを移動させるためのいかなる他の無線伝送であってもよい。次にデバイス２００の内部２０２を検討すると、タスク処理を実行するためにプロセッサ２０９が存在すること分かる。本発明の実施形態は、プロセッサ２０９が、いかなるタイプのマイクロプロセッサまたはコントローラ、または１つまたは複数のデバイス機能を実施するための実行中のソフトウェア機能を実行する構成要素の集合体でもよいように、いかなるタイプのデバイスでも組み込むことができる。デバイス２００は、メモリ２０７、２０８として示される、データとプログラムを記憶するための複数タイプのメモリを有している。これらのメモリは、磁気メモリ、光メモリなど、いかなるタイプであっても、またはＳＲＡＭやＤＲＡＭなどのシリコンベース・メモリの数あるタイプのうちのどれであってもよい。最後に、デバイス２００は、場合によっては有線接続２０６と無線接続２０３とで実施されるようなＩ／Ｏ機能をサポートするための構成要素２１０を有することができる。

次に図３を参照すると、コンピュータ３００は、開示した技術の多くと共にユーザが併用できるデバイスの別の図面である。コンピュータ３００は、パーソナル・コンピュータなどの通常のコンピュータだが、それに限定されるものではない。コンピュータ３００は、１つまたは複数のマイクロプロセッサ３１５を有しており、システムの中心部にはチップセット（図示せず）が付属している。チップセットは、ネットワーク・ユニット３１０、音声ユニット３１１、Ｉ／Ｏユニット３１４として実装できる多くのＩ／Ｏ機能などのアイテムを含む。当然ながら、これらの機能またはサブ機能のいずれも、チップセットの内外で個別にまたは集合的に実装されることができる。コンピュータ３００は、適合し、電力を供給するための電源３１３も有する。コンピュータ３００はまた、いかなる種類の光ドライブおよび磁気ドライブと、ＩＤＥ、ＡＴＡまたはＳＣＳＩコントローラなどのドライブを使用するための適切なコントローラとを有する。ユーザがアクセスし易いように、コンピュータ３００は、モニタ３１８、スピーカ３１９、キーボード３２１、マウス３２０、オプショナルのタブレット／タッチ・スクリーンを有する。最後に、コンピュータ３００は、様々なポート（ネットワーク３０１、無線３０２、ＵＳＢ３０３、パラレル３０６、シリアル３０７、１３９４ ３０８またはモデム３０９）を介して他のアイテムのあらゆる方法（対応するデータ・アイテムを保持する他のデバイスなど）で接続することができる。

サンプルのハードウェアから移って、次に、一般的なソフトウェアの背景について検討する。具体的には、図４を参照すると、本発明のいくつかの実施形態が常駐するソフトウェア・アーキテクチャを説明することを目的としたソフトウェア・スタックが示されている。本発明者らのハードウェアの例と同様に、この構造は、いかなる方法でも排他的ではなく、説明を目的とするものである。これは、ソフトウェア開発業者が何らかの異なる方法で説明する傾向のある、層形式による図面では特に言えることである。この場合、Ｏ／Ｓカーネルから始まる層を表し、それよりも低レベルのソフトウェアとファームウェアとは省略した。ここでの表記法は、一般に、層で示されたソフトウェア要素が下の層からの資源を使用し、上の層にサービスを提供することを暗示することを目的としている。しかし実際には、特定のソフトウェア要素のすべての構成要素が、完全にそのような方法で振舞うわけではない。

これら但し書きに関して、図４では、２つの層４２４と４２３がオペレーティング・システム・カーネルとコア・サービスにそれぞれの専用であることが分かる。一般に、コア・サービス層４２３の上には、アプリケーション層４２０にあるアプリケーションに高位レベルの資源と複数のサービスとを提供するためのソフトウェア層（４２２、４２１）がある。層の図表を状況に加えると、一般に、アプリケーション層４２０でＰＩＭタイプのソフトウェアが見つかるものと期待することができる。例えば、アプリケーション層に常駐するｉＣａｌアプリケーション４２０とＡｄｄｒｅｓｓ Ｂｏｏｋアプリケーション４０３とがある。ｉＣａｌ４０２とＡｄｄｒｅｓｓ Ｂｏｏｋ４０３とは、ＰＩＭデータを管理し、ユーザに対してそのデータにアクセスし、編集し、または操作することを可能にするユーザ・インターフェースを与える、アプリケーション・プログラムである。これらのアプリケーション層サービスは、同期機能が、指定されたクライアント間でデータの共通表示（可能な限り）を維持することによりそれらのクライアントにサービスを提供するという点で、一種の同期クライアントである。エリア４１００は、一般に、同期機能を実装しているプロセスが多くの実施形態で配置される可能性のある場所を示す。より具体的には、同期機能を実装しているプロセスは、そのアプリケーション・クライアントに対するピアであってもよく、または可能ならばそれ自体をさらにそのアプリケーションに対してマスキングして（それ自体が同期クライアントであることを知らない同期クライアントを参照して）、下の層に常駐してもよい。同期機能は、複数層にある構成要素を有することもできる。しかし多くの実施形態では、アプリケーション・レベルの同期クライアントは、同期機能を構成し、活用するためにユーザ・インターフェースを提供する。したがって、同期プロセスは、クライアント・ソフトウェアでは１つの統合機能として表示される。さらに同期プロセスは、通常、いかなる特定のアプリケーションからも独立した構成と制御とのために、それら独自のユーザ・インターフェースを提供する。最後に、上記で検討したように、同期クライアントは外部デバイスのプロキシとして存在してもよい。そのようなプロキシ・プロセスは、ユーザ・インターフェースに対する需要が低く、一般に（しかし必須ではない）、ソフトウェア・スタックの上位層に存在する。

III．データ履歴を示すメタデータの保存
ａ．世代カウンティング
従来技術の問題点の多くは、各データ・セットまたはデータ・アイテムのためのデータ履歴情報を維持することにより解決策を見つけることができる。いくつかの実施形態で実現される１つの単純な形態では、世代カウントを維持することができる。具体的には、データが変更されるたびに、その変更を示すように世代カウントを増分することができる。さらに具体的には、世代カウントは、いかなるレベルのデータ・セットに対しても、すなわちＰＩＭデータベースごと、データ・クラス・データベースごと、記録ごと、またはデータ・アイテムごとに維持することができる。世代カウントは、メタデータとして概念的に説明することができ、したがっていかなる周知の技術によりデータと関連付けることができる。例えば多くの実施形態では、世代カウントは、各データ・アイテムごとに維持され、データと共に記憶される。上記のように、他の実施形態は、データ・アイテムまたはデータ・アイテムのいくつかの集合体に関連付けられたデータ構造などの他の技術を使用することができる。

履歴を示す情報がデータと同期されていると、履歴を示す情報を使用する技術（世代カウントなど）をさらに強化することができる。いくつかの実施形態では、同期プロセス中に世代カウントを同期させることができ、それにより複数のクライアント・ピアを通してデータ履歴のシン・バージョンを維持することができる。一例として、各データ・アイテムに関連付けられた世代カウントを使用する３つのピア・システムを同期すると仮定する。図５を参照すると、同期中のクライアントＡ、クライアントＢ、クライアントＣの態様を説明する表が示されている。具体的には、「ステップ」と名付けられた第１欄は、混乱なく一連のアクションを参照することができるように説明の参照用であり、「アクション」と名付けられた第２欄は、データ・アイテムの変更の原因となるアクションを示し、「データ」と名付けられた第３欄は、全知の観点から対象となるデータ値を示し、第４、第５および第６の欄は、クライアントＡ、Ｂ、Ｃそれぞれの観点からそれぞれの列挙されたアクション後のデータのステータスと世代カウントとを示す。

次に図５のステップ０を参照すると、デバイスＡ、Ｂ、Ｃに対応するデータ・アイテムが空であり、そのデータ・アイテムに関するアクションがなかったことが分かる。事実、このステータスは、空のデータ・アイテムまたは一時的に存在しないデータ・アイテムを表す。ステップ１を参照すると、ユーザは、デバイスＢでデータを作成するが、そのデータは「青」である。世代カウントは１である（Ｂステータス欄に示されており、デバイスＡとＣはこの変更を知らないままである）。ステップ２では、ユーザは、「青」から「青緑」にデータを編集し（明らかにデバイスＢで）、世代カウントは２に増加し、デバイスＡとＣは同様にそれを知らないままである。ステップ３では、デバイスＢはデバイスＣと同期し、データのステータスは「青緑」のままであり、デバイスＢとＣとはどちらも正確なデータと正確な世代カウント（２）とを知っており、デバイスＡはそれらを知らないままである。次にステップ４で、ユーザは、状態が赤に増分され、正確なデータが「青緑」から「赤」に変更されるように、デバイスＣでデータを編集する。デバイスＡはすべての事象を知らないままであり、デバイスＢは古いデータと古くからある状態（２）とを保存する。次にステップ５で、デバイスＡとＣとは同期してデバイスＡで正確なデータと世代カウントとを発見する（デバイスＢは両方で古くからある状態で残存する）。ステップ６で、ユーザは、デバイスＡで編集し、「赤」を「オレンジ」に変更し、新たな最上状態（４）に到達する。最後にステップ７で、デバイスＡ、Ｂ、Ｃのすべてが、共に同期を試みる。この結果は世代４となり、オレンジとなる。しかし、世代カウントを保持せずに、この３種類の同期が不要な齟齬を発生させたことは注目に値することである。

ｂ．さらに豊富なデータ履歴の表示の維持
実際、単純な世代カウントより豊富な履歴の表示を維持するための重要な使用方法がある。例えば、本発明の多くの実施形態では、詳細な履歴データが維持される。図６を参照すると、より詳細な完全なデータ・アイテム履歴を使用するクライアントＡ、クライアントＢ、クライアントＣを同期する態様を説明する表が示されている。具体的には、「ステップ」と名付けられた第１の欄は、混乱なく一連のアクションを参照することができるように説明の参照用であり、「アクション」と名付けられた第２の欄は、データ・アイテムの変更の原因となるアクションを示し、「データ」と名付けられた第３の欄は、全知の観点から対象となるデータ値を示し、第４、第５、第６の欄は、クライアントＡ、Ｂ、Ｃそれぞれの観点からそれぞれの列挙されたアクション後のデータのステータスと履歴情報とを示す。

次に図６のステップ０を参照すると、デバイスＡ、Ｂ、Ｃに対応するデータ・アイテムが空であり、そのデータ・アイテムに関するアクションがなかったことが分かる。事実、このステータスは、空のデータ・アイテムまたは一時的に存在しないデータ・アイテムを表している。ステップ１を参照すると、ユーザは、デバイスＢでデータを作成するが、そのデータは「青」である。ステップ１のトランザクションに関する事実はデバイスＢで維持される。次にステップ２で、ユーザは、指摘のようにデバイスＢでデータを編集する。その履歴はデバイスＢに記録される。ステップ３で、デバイスＢとデバイスＣとは同期され、その結果、そのデータ（青緑）とそのデータ・アイテムに対する履歴事実とが同期される。次のステップ（４）で、ユーザは、デバイスＣでデータ・アイテムを編集して、データを「赤」に変更する。次にステップ５でデバイスＡとＣとが同期すると、そのデータ・アイテムの全履歴がデバイスＡに伝えられる。この例から、各デバイスがデータ・アイテムの履歴のすべてまたは一部を保持していることが分かる。

したがって、その履歴は、そのデータに関する知的な決定を行うために活用される。そのような決定の一例は、明らかな齟齬の状態において、デバイスはデータ・アイテムの１つのバージョンが別のデータ・アイテムの子孫であるか否かを判定することができる。これは、切り捨てられたデータなど、多くの場合に非常に有用である。切り捨てられたデータは、デスクトップ・コンピュータなどのファットなデバイスが電話機などのシン・デバイスと同期する場合に発生することがある。電話機がデータ・アイテムのすべて（または記録などのセットのすべて）を保持するのに十分でない場合、デスクトップ・コンピュータからのデータは、電話機のデータベースに含めるために切り捨てられる。後で、電話機は、ＰＤＡなど別のデバイスと同期して、その切り捨てられたデータを伝える。ＰＤＡとデスクトップとは、その後に同期を試みると、特定の履歴データしか解決することのできない齟齬に遭遇する。

ｃ．履歴ベースの同期の用サンプル・プラットフォーム
以上、同期技術を改善し、強化するための、履歴ベースのメタデータの使用法について一般的に検討した。説明のために、構造の文脈にそれらの技術をおき、本発明の実施形態の一部のサンプルを検討することにする。これらの発明の実施形態の１つの利点は、以前の同期後にデータ・スナップショットの独立した維持を必ずしも必要としないということである。より具体的には、上記で説明したように、多くの既存の同期システムは、各同期の後にデータのスナップショットを保持する。このスナップショットは、どのデータが追加、変更、または削除されたかを特定するために、次の同期中に使用されるので、ユーザの編集とは独立して維持する必要がある。対照的に、本発明の多くの実施形態は、そのようなスナップショットの永続的な維持を必要とはしない。具体的には、システムが、履歴情報とデータ・アイテムの対応するメタデータとの両方を劇的に更新すると、別のスナップショットは必要なくなる。履歴データが、どのデータが本当に新しいかを判定する代替の、より包括的な方法を提供するので、これが可能となる。あるいは、本発明のいくつかの実施形態は、同期直前のスナップショットを単純に生成し、同期完了後にそのスナップショットを配置することにより、永続的なスナップショットを維持することを回避することができる。

次に図７Ｃを参照すると、同期クライアント・デバイス７９０が示されている。デバイス７９０内には、本発明の一実施形態を実施するために使用することのできる潜在的なデータ構造の概念的な説明が示されている。このデータ構造は、クライアント・デバイスにアクセス可能ないかなる適切な場所にも記憶できる。上記のように、一部の例は、ＳＲＡＭ、ＤＲＡＭ、磁気メモリまたは光メモリである。データ構造を、同じメモリ・タイプに、または同じ場所に記憶する必要はない。次にデバイス７９０を参照すると、データ・ストア７９１は、ユーザ・インターフェースと連携する使用法のための生データベースを表示することを目的としている。現行技術の構造などを実装するには多くの方法がある。そのような実施形態は、単一ファイルまたは多くのファイルにあってよい。ファイルは、フラット・テーブル、スープ・タイプのファイル、または組合せまたは適切な他のタイプのファイルであってよい。例えば、ＰＩＭデータの文脈では、関連付けられたＰＩＭプログラムにより管理される各データ・クラスに対する独立したスープ・ファイルまたは平らなファイルがしばしばある。それらのイベントのどれにおいても、データ・ストア７９１は、実際のデータといくつかのメタデータとを維持する。メタデータデータは、ＩＤコードほどに小さくても、データの完全な履歴ほどに大きくてもよい。メタデータという用語を使用することで、このデータをユーザのアクセスまたは操作のために使用することが除外されるものではない。いくつかの実施形態では、データ・ストア７９１のデータ・アイテムに付随するメタデータは、状態識別であり、任意にはデータ・アイテムＩＤである。

履歴ストア７９２は、データ・ストア７９１のデータ・セットまたはデータ・アイテムに関する履歴情報を維持するためのデータ構造を表すことを目的とする。この履歴情報は、本明細書の記載と一致したいかなる形式であってもよい。さらに「履歴情報」という名称は、関連履歴でない情報の使用を除外することを目的とするものではない。履歴情報は、開示した技術の下で有用ないかなるメタデータをも含むことができる。さらに、履歴情報は、ＩＤコード、仮想または物理位置または、表またはデータベースなど別個に記憶された関連デバイスなどのいかなる適切な技術を使用して、データ・アイテムに関連付けることができる。いくつかの実施形態では、履歴ストアの情報は、状態識別および／またはデータ・アイテムＩＤを使用してデータ・セットまたはデータ・アイテムに関連付けられる。さらに具体的には、いくつかの実施形態では、複数のデータ・アイテムが１つの状態に関連付けられる（例えば、データ・ストア７９１にメタとして保存される）。これらの実施形態では、多くのデータ・アイテムが同じ状態を有することができる。履歴情報は、履歴ストア７９２の対応する状態ＩＤを使用することにより、状態０に関連付けられる。例えばいくつかの実施形態では、デバイスＡのユーザは、通常ならば空のデータ・ストアに１０（または１０，０００もの）のデータ・アイテムを作成することができる。追加されたデータ・アイテムは、単一状態のみ、すなわちユーザがデバイスＡでデータを編集した履歴情報が付随する状態に対するＩＤのみを表すことができる。この例をさらに深く検討すると、デバイスＡのユーザが１０個の作成されたデータ・アイテムのうちの３個を編集しようとする場合、それら３個のデータ・アイテムの履歴を反映させるために第２の状態が履歴ストア７９２に反映される（これらは例えば、未編集の７個のアイテムが状態１の状態にある）。

次にスナップショット７９３に移ると、データ・ストアのすべてまたは一部の一時的なスナップショットのために使用することのできるデータ構造が示されている。上記のように、ある実施形態は、同期中または同期以前に独立したスナップショットを活用することができる。データ・ストア７９１に関して上記で示したように、履歴ストア７９２とスナップショット７９３とはどちらも、データ構造と物理メモリとに関する実施形態については柔軟である。さらに、データ・ストア７９１、履歴ストア７９２、スナップショット７９３は、同じデータ構造、または３個の別個のデータ構造、または１つまたは複数のデータ構造、または上記のいかなる組合せでも実施することができる。

IV．状態ベースの同期
上記のように、本発明の多くの実施形態は、状態ベースの同期技術を活用する。それにより、状態識別は各データ・アイテムまたはデータ・セットと関連付けられる。これらの実施形態では、データ・ストアで表示された状態は履歴ストアでも表示される。履歴ストア内で、状態は、限定はしないが、データ・アイテムの履歴に関する事実を含めてデータ・アイテムに関する事実と関連付けられる。マルチピア・システムでは、各クライアント・デバイスは、データ・ストアおよび／または履歴ストアを維持する。データ・アイテムが特定のデバイスに追加されるか、特定のデバイスで編集される場合（削除を含めて）、そのデータ・アイテムは新しい状態に割り当てられ、そのアイテムの状態変更を反映させるために、場合によっては１つの項目が履歴スペースに作られる。履歴スペースのその項目が「場合によって」だけである理由は、追加または編集されたデータ・アイテムの新しい状態が、別のデータ・アイテムの状態変更に対応して作成されたステートメントにより既に履歴ストアに反映されている可能性があるからである。したがって、履歴ストアの状態とそれらに付随するメタデータを、いくつかのデータ・アイテムに同時に適用できることは明らかである。さらに多くの実施形態では、履歴ストアの情報量を最低限に抑えることが望ましい。

ａ．一般的な同期例
上記のようにピア同期クライアントが動作すると仮定すると、最終的にそのような同期クライアントのどれか２つを同期させることが望ましい場合がある。いくつかの実施形態では、同期は非対称な形式で実行される。具体的には、第１のデバイスがそのデータ・ストアを第２のデバイスと同期し、次いで第２のデバイスがそのデータ・ストアを第１のデバイスと別個に同期する。多くの実施形態の場合、同期の実際のプロセスは、図７Ａに示す２つの非常に一般的なステップを含む。第１のステップ７０１は、履歴ストアの情報（例えば、データ・アイテムの状態変更を述べるメタデータ）を同期させることである。第２のステップ７０２は、データ・ストアのデータ・アイテムを同期させることである。履歴情報が最初に同期されるので、データ・ストアの同期に役立てるために履歴ストアにある新しい履歴情報を使用することができる。

一般に、履歴情報はいくつかの異なる方法で同期することができる。図７Ｂを参照すると、デバイス７０４からデバイス７０３に対してある同期の方法を実行している一対のデバイスが示されている。履歴アイテムを同期する恐らく最も簡単な方法は、デバイス７０４からデバイス７０３に履歴アイテムのすべてを転送することである。それらアイテムのうちのどれが履歴ストア７０５で表示されることを必要とするかを特定するために、転送された履歴アイテムをデバイス７０３で評価する。履歴情報を同期するための別の方法は、デバイス７０４と７０３が、無線リンク７０８などのどれか適切な通信機構を介してダイアログを入力することである。ダイアログの１つの方法では、デバイス７０３は、デバイス７０４の履歴情報の内容または履歴情報に関する事実についてのクエリ・デバイス７０４であってよい。それらのクエリに対する応答により、次いでデバイス７０３は、ストア７０５の必須の履歴情報を作成するか、またはデバイス７０４に必須の情報を要求してそれをストア７０５に置くことができる。ダイアログの別の方法では、デバイス７０４は、ストア７０５の履歴情報についてのクエリ・デバイス７０３であってよい。次いでデバイス７０３によって履歴情報が要求された場合はデバイス７０４はそれを特定し、それがどのような履歴情報であっても、それを送信することができる。

履歴情報を同期する第３の技術は、履歴情報に対して状態ベースの同期技術を再帰的に活用することである。図８を参照すると、デバイス８０２からデバイス８０１への１方向的な同期を実行している一対のデバイスが示されている。図８に示すように、状態ベースの同期の再帰的な使用は、複数の履歴ストアを必要とする場合がある。デバイス８０１は、第１の履歴ストア８０５と、第２の履歴ストア８０４と、第３の履歴ストア８０３とを有する。デバイス８０２は、第１の履歴ストア８０９と、第２の履歴ストア８０８と、第３の履歴ストア８０７とを有する。他のデータ構造に関して検討したように、各デバイスの履歴ストアは、いかなるタイプのメモリにも存在することができ、また様々なタイプの１つまたは複数のデータ構造として実装することができる。再帰的状態ベースの同期を実行するために、第１履歴ストア８０５または８０９の各要素（例えば、事実ステートメントまたは一群の事実ステートメント）はある状態に割り当てられ、そのような状態は第１履歴ストア８０５と８０９の要素に発生する状態変更に関する情報にも関連付けられる（第２の履歴ストア８０４または８０８）。これは、第１メタデータを維持するための第２のメタデータである。当然ながら、能率が指示する回数だけ、この技術を再帰的にネストすることができる。例えば、第３の履歴ストア８０３と８０７とは、履歴ストア８０４と８０８との第２のメタデータの同期に役立てるために、第３のメタデータを保持することができる。ネストされた履歴ストアを有する実施形態を同期する場合、同期の順番は履歴ストアの階層と反対であってよい。例えば、図８のすべての履歴ストアが活用された場合、第３の対８０３から８０７を最初に同期することができる。この同期の結果は、次いで第２の履歴ストア８０４と８０８との同期に役立てるために使用することができ、第２の履歴ストア８０４と８０８は反対に第１の履歴ストア８０５と８０９との同期に役立つ。

履歴情報が一度同期されると、遠隔データに対するすべてのメタデータ状態がローカルに認知される。次にデータ・ストア同期は、新しい履歴情報を役立てる可能性を持って始めることができる。図８、９を参照すると、一般的なプロセスは次の通りである。すなわち、ステップ９０１で、いくつかの実施形態は、ローカル・デバイス８０１と遠隔デバイス８０２とからの対応するデータ・アイテムを比較することができる。これらの実施形態では、決定９０２がそれらデータ・アイテムを同一であると判定した場合、次いでステップ９０３は、ローカル・データに対して必須のアクションはないことを宣言し、これで次のデータに対して準備ができたことになる。ステップ９０２でデータが同一でない場合、次いで状態を比較するために制御はステップ９０４に移る。多くの実施形態がステップ９０１と９０２とを省略し、したがって検討中のデータについてローカル状態と遠隔状態とを比較することにより、ここで説明したプロセスをステップ９０４で開始することは注目すべきことである。決定９０５がそれら状態を同一であると判定した場合、次いでこのデータ・アイテムに関してさらなるアクションは要求されず、制御は次のデータのためにステップ９０６に移る。決定９０５が、それらの状態を別の状態であると判定した場合、次いでローカル状態が遠隔状態の祖先であるか否かを判定するために、制御は決定９０７に移る。決定９０７が「はい」の場合、これはローカル・データが古くからあるものであることを示しており、ローカル・データを、遠隔データの値を反映させるために更新する必要がある。決定９０７の判定が「いいえ」の場合、次いで遠隔状態がローカル状態の祖先か否かを判定するために、制御は決定９０９にシフトする。ステップ９０９の決定が「はい」の場合、次いでローカル状態が最新であることが確定され、制御は次のデータ・アイテムのためにステップ９１１に移る。決定９０９が「いいえ」の場合、次いで制御はステップ９１０に移り、齟齬が発生する。齟齬を解決するために、多くの可能性を持った機構がある。いくつかの実施形態では、ユーザが齟齬したデータ・アイテム間で選択することができるように、ユーザ・インターフェースが提示される。様々な実施形態は、この点でユーザに役立つためにいくつかのメタデータを表示することができる。いくつかの場合によっては有用なメタデータは、そのデータ操作に関わる利用可能な範囲、時刻、デバイス、ユーザを含めて、各データ・アイテムの履歴であってよい。このメタデータは、履歴ストア、データ・ストアまたは他のどこかに保持することができる。しかし、アイテム特有メタデータが履歴ストアに保持される場合、それは多数の履歴ステートメントを生じさせる傾向にある。

当業者は注意せずとも理解することはできるものの、図９について説明されたプロセスは同期した世代カウントに適用できるが、齟齬が発生する機会が増える可能性があることに留意されたい。

ｂ．履歴ステートメントのための拡張性セマンティック言語
以上、履歴と履歴ステートメントの使用法について詳細に検討した。次に、履歴情報として使用するための、情報のタイプの例について検討する。履歴ステートメントの意味論を形成する際、多くの実施形態は、マシンの使用に向いたシンタックスを必要とする。したがって、これらの実施形態は、コンピュータに読み取りおよび／またはコンパイルを提供するためにソース・コード・タイプのフォーマットを使用することができる。いくつかの実施形態は、次の一般的なシンタックスを使用する。

新しい状態、関数／コマンド、クライアント、１つまたは複数の古い状態

「新しい状態」は、ローカル・デバイスに割り当てられた状態識別である。「古い状態」は、ローカル状態の用語で示された、データの前の状態を反映する。所与の履歴ステートメントの場合、上記のように同期中に必須な場合、古い状態と新しい状態とのどちらも祖先を追跡するために有用な場合がある。状態識別は、増分の順番で割り当てる必要はない。これら識別は、それらを活用する環境に一意であればよい。例えば、多くの実施形態では、状態識別はクライアント・デバイスごとに一意であってよい。これは、そのデバイスには単一の履歴ストアしかないからである。しかし、ある種のクラスのデータに対するそのデータとメタの範囲は別に維持することができ、次いで状態識別はデータ・クラス／同期クライアントの組合せに対して一意であればよい。さらに、いくつかの実施形態では、状態は一度だけ作成されるという点で不変である。当然ながら、次いで不要な新しい状態の作成を回避し、恒久的に不要であると判定された状態を除去することは、それらの実施形態にとってより重要な場合がある。

ここでの一般的なシンタックスでは、「クライアント」は、履歴ステートメントによって反映された変更に含まれた同期クライアントの識別である。いくつかの実施形態では、クライアント識別は、正確に祖先を追跡し、本物に対する齟齬を制限するために不可欠である。

ここでの一般的なシンタックスでは、「関数／コマンド」は、状態変更の本質を示す単なる語（通常は、動詞）である。このような適用の際、本発明者らは、様々な実施形態で使用するためのいくつかの関数を想定した。それらを以下に示す。

コマンド「ｅｘｔｅｒｎａｌ」は、ローカル・クライアントと遠隔クライアントとの間で通信を確立するために使用される。例えば、ステートメント｛１２、ｅｘｔｅｒｎａｌ、ｈｏｍｅｍａｃｈｉｎｅ、３４｝は、「ホームマシン」同期クライアントの状態３４に対応するローカル・マシンの状態１２を示す。記載された比較オペレーション中に、遠隔にあるデータ・アイテムが状態３４であり、ローカル状態が１２である場合、これらの状態は同じであることが分かっているので、これは同期中には有用である。

コマンド「ｕｓｅｒ＿ｅｄｉｔｅｄ」は、そのデータがユーザによって変更されたことを示すために使用される。例えば、｛１７，ｕｓｅｒ＿ｅｄｉｔｅｄ，“ＣｌｉｅｎｔＢ”，１４｝は、クライアントＢのユーザが状態１４でデータを編集し、ローカル・デバイスでは編集されたデータの状態が状態１７であることを示す。当然ながら、クライアントＢはローカル・クライアントであってよく、その場合、ステートメントはローカル・データの変更を反映する。

コマンド「ｃｏｎｆｌｉｃｔ＿Ｒｅｓｏｌｖｅｄ」は、齟齬解決の結果を示すために使用される。例えば、｛１０１，ｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄ，ｈｏｍｅｍａｃｈｉｎｅ，３７，３８｝は、状態３７に関連付けられたデータが状態３８に関連付けられたものと齟齬していると分かったこと、その齟齬がホームマシンで解決されたこと、その解決はローカル状態１０１で示されることを示している。齟齬する状態の順番は、勝ち状態と負け状態とのようにより多くの情報（例えば、勝ち状態、負け状態）を示すために使用される。上記実施例によれば、好ましい実施形態は、勝ち状態と負け状態とをその順番で列挙する。上記のように、ユーザの決定を受け取るためのユーザ・インターフェースを提示するなど、齟齬を解決するためには多くの技術がある。

コマンド「Ｋｎｏｗｎ＿ｅｑｕａｌ」は、２つの対応するデータ・アイテムが等しいことが分かったことを示すために使用される。明らかにするために、ここでは、データのメタではなく、例えば状態識別など、データとして扱われるものは何であれ言及することにする。この種の発見は、上記の比較オペレーション中に起こる場合がある。例えば、｛１００，ｋｎｏｗｎ＿ｅｕｑａｌ，ｈｏｅｍａｃｈｉｎｅ，３７，３８｝は、状態３７と３８のデータ・アイテムが同期クライアント・ホームマシン上で等しいことが分かり、新しいローカル状態１００はその発見を反映させるために作成されたことを示している。ここで再度、例えば「ローカル状態、遠隔状態」を指定するこの関数にシンタックスを提供することにより、より多くの情報を伝えるために古い状態の順番（必須ではないが）を使用する。

コマンド「ｔｒｕｎｃａｔｅｄ」は、データ・アイテムが（上記のように）何らかの理由で切り捨てられたことを示すために使用される。例えば、｛６９，ｔｒｕｎｃａｔｅｄ，ｏｆｉｃｅｍａｃｈｉｎｅ，６８｝は、状態６８の遠隔データ・アイテムが状態６８のオフィスマシンで切り捨てられ、ローカル・デバイスの状態６９に関連付けられていることを示している。

コマンド「ｄｅｌｅｔｅｄ」は、データ・アイテムが削除されたことを示す。例えば、｛２７，ｄｅｌｅｔｅｄ，ＰＤＡ，２６｝は、状態２６のデータ・アイテムが同期クライアントＰＤＡで削除され、その事実を反映させるために状態２７がローカルに作成されたことを示している。

コマンド「ｓｏｆｔ＿ｄｅｌｅｔｅｄ」は、デバイスの最大容量など、ユーザ削除以外の何らかの理由で削除されたデータ・アイテムを示すために使用される。例えば、｛１７，ｓｏｆｔ＿ｄｅｌｅｔｅｄ，ＰｈｏｎｅＡ，１６｝は、状態１６の下のデータ・アイテムが同期クライアントの電話Ａでソフトに削除され、ローカル状態１７がその事実を反映させるために使用されていることを示している。

「ｅｑｕivａｌｅｎｔ＿ｓｔａｔｅｓ」コマンドは、２つの状態が複製であるという事実を記録するために使用される。ほとんどの実施形態は複製状態を許可しないように設計されるべきだが、これら複製は、不良設計のシステムで発生したり、破損または他の予想外の問題の結果として発生したりする場合がある。それでも尚それらが見つかった場合には、それらを記録する。例えば、｛３８，ｅｑｕivａｌｅｎｔ＿ｓｔａｔｅｓ，ｈｏｍｅｍａｃｈｉｎｅ，１０１，２２｝は、ローカル状態１０１と２２が等しいこと、その事実が同期クライアント・ホームマシンで見つかったことを示している。状態３８は、その事実を記録するために使用され、可能ならば後でそれを除去するのに役立つ。

コマンド「ｉｎ＿ｕｓｅ」は、その状態がデバイスのデータ・ストアで使用中であることを示す。例えば、｛０，ｉｎ＿ｕｓｅ，ｈｏｍｅ＿ｍａｃｈｉｎｅ，３，５，１１，２５、２６｝は、同期クライアント・ホームマシンのデータ・ストアに存在するデータ・アイテムはすべて状態３、５、１１、２５または２６の１つに対応することを示している。多くの実施形態では、「０」はｉｎ＿ｕｓｅコマンド・ステートメントのためのサブジェクト・コマンドとして使用される。これらの実施形態では、「０」は他の履歴ステートメントを有するシンタックスを維持するためにのみ使用される。関数の問題として、使用中の現行状態を記録するために必須の新しい状態はない。さらに、いくつかの実施形態では、ｉｎ＿ｕｓｅコマンドは、主として後述する不要部分の整理と呼ばれるプロセスのために活用することができる。最後に、いくつかの実施形態では、ｉｎ＿ｕｓｅコマンドは、その製造時期を示す世代カウントを保持する。１つまたは複数の実施形態では、世代カウントは、次のようにクライアント名の隣の括弧内に入れられる。｛０，ｉｎ＿ｕｓｅ，ｈｏｍｅ＿ｍａｃｈｉｎｅ［１］，３，５，１１，２５ ２６｝

本明細書に記載のコマンドは、それらの名称または関数により排他的であることを目的とするものではない。例えば、「ｋｎｏｗ＿ｅｑｕａｌ」の代わりに、「ｓａｍｅ＿ｄａｔａ」またはプログラマーが希望する他の名称で呼ばれるコマンドによって同じ関数を実装することができる。さらに、本明細書で提供したサンプル・コマンドは、有用なコマンド・タイプを説明することを目的としている。様々な実施形態は、それらのコマンドの部分集合または上位集合さえも活用する。具体的には、多くの実施形態はシステムに伸張性を提供する。具体的には、システムは一度構築されると、レガシー・データまたはレガシー・履歴情報を崩壊させずに他のコマンドを含めるように、（他の場合はソフトウェアで）アップグレードすることができる。例えば、新しいコマンドと関数とを追加するために、実行可能性またはライブラリまたはそれら両方を置き換えることができる。新しいライブラリまたは実行可能性は、新しいコマンドだけでなく古いコマンドも解釈することが可能である。これにより、コンピュータ・メーカは、データの崩壊なしに、またはすべてのデータまたは履歴情報を再処理することを必要とせずに機能セットを強化または増加することが可能になる。

ｃ．サンプル
図１０は、本発明のいくつかの実施形態を実証し、テストするように書かれたプログラムから作成されたサンプルの集合体である。このプログラムは開発途上にあるが、これらの例は上記のシンタックス言語を使用して履歴ステートメントを作成することを説明している。参照のため、またより具体的な開示のために、実証プログラムのソース・コードを、本明細書の添付書類として添える。

図１０Ａを参照すると、１つまたは複数のデータ・アイテム（オブジェクトは、形状または内部文字を変更することによりその値を変更する１つのデータ・アイテムとして、または形状と内部文字により事実上実証される２つのデータ・アイテムを実施する１つのデータ・セットとして、というように２つの方法で見ることができる。）を実施するオブジェクト１００１が示されている。オブジェクト１００１に反映される番号「１」は、そのデータの状態を表す。作成されたオブジェクト、例えばオブジェクト１００１には状態（「１」）が割り当てられる。このデータおよび状態識別（「１」）は、データ・ストアに記憶され、履歴ステートメント１００２は履歴ストアで作成される。この場合、履歴ステートメント１００２は、ユーザの編集による状態０から状態１へのデータ・アイテム１００１の移行を示している。明らかに、いくつかの実施形態は、周知の情報がないことを示すために状態０を使用している。

次に図１０Ｂを参照すると、図１０Ａの続きの表現が示されている。このコンテキストは、４つのオブジェクトが追加された点で変更されている（１００３から１００６）。５つのオブジェクトすべてが単一ステートメントで記述されているので（ユーザは、状態０から状態１に移行するように編集した）、新しい履歴ステートメントは必須でないことに留意されたい。

次に図１０Ｃを参照すると、図１０Ｂの続きの表現が示されている。このコンテキストは、オブジェクト１００１が卵型から長方形に変更されたという点で変更されている。このデータ・アイテムの変更は、状態１から状態２への移行がユーザの編集により生じたことを示す、線１００７の履歴ストアに反映されている。すべての他のオブジェクトは状態１のままである。

次に図１０Ｄを参照すると、図１０Ｃの続きの表現が示されている。このコンテキストは、オブジェクト１００５が形状を変更し、状態２に移ったという点で変更されている。これは、線１００７により履歴ストアに反映される。線１００７は、次に、２つのオブジェクト１００１と１００５に対する同じ移行を反映していることに留意されたい。同様に、２つの列挙した状態がすべての存在するオブジェクトに対する状態０から状態２への移行を記述するので、残存する３つのオブジェクトを編集することができ、新しい状態は作成されない。

次に図１１Ａを参照すると、上記の実証プログラムからのグラフィカル・ユーザ・インターフェースが示されている。このＵＩは、クライアント・デバイス「Ｕｎｔｉｔｌｅｄ１」と「Ｕｎｔｉｔｌｅｄ２」がプログラムによりシミュレートされていることを示す、２つのウィンドウ１１０１と１１０２（デバイスの名称は各ウィンドウの上部にある）とを有する。図１１Ａは、デバイス「Ｕｎｔｉｔｌｅｄ」１１０１がそのデータ・ストアに単一オブジェクト１１０３を有し、その履歴ストアに単一の対応する履歴ステートメント１１１０を有することを示している。

次に図１１Ｂを参照すると、図１１Ａの続きの表現が示されている。このコンテキストは、デバイス１１０２がデバイス１１０１からの１方向同期を実行したという点で変更されている。この同期は、デバイス１１０２に、その履歴ストアに同一オブジェクトを入れたことが分かる。さらに、履歴ステートメント１１２０から１１２２は、上記関数を反映している。具体的には、ｉｎ＿ｕｓｅコマンド１１２０から、状態１がデバイス１１０２のデータ・ストアで使用中の唯一の状態であることが分かる。外部コマンド１１２１は、ローカル状態１が、（ローカルには状態１と表示される）遠隔状態１に対応することを反映する。ユーザが編集したコマンド１１２２は、そのオブジェクト１１３０がデバイス「Ｕｎｔｉｔｌｅｄ」１１０１で状態０から編集されたことを反映する。

次に図１１Ｃを参照すると、図１１Ｂの続きの表現が示されている。このコンテキストは、デバイス１１０１にはデバイス１１０２からの１方向同期が実行されたという点で変更されている。オブジェクト１１０３と１１３０は同じものを残し、それぞれのデバイスのオブジェクトだけを残すという点でデータ・ストアは変更されていないことが分かる。しかし履歴ストアの同期の際、（同期の受け取り側の）デバイス１１０１の履歴ストアに３つのステートメントが追加されたことが分かる。具体的には、線１１１１から１１１３は、新しく、上記の定義により実施されたものである。線１１１１から１１１３で使用されたｉｎ＿ｕｓｅコマンドは、各デバイスのデータ・ストアで使用中の状態を反映する。外部コマンド１１１２は、ローカル状態１がデバイス「Ｕｎｔｉｔｌｅｄ２」１１０２の状態１に等しいことを反映する。

ｄ．履歴情報の同期のより詳細な例
以上、同期履歴ステートメントを一般的に検討したが、次に、既に紹介された履歴ステートメントの例を使用して同期技術の例を提供する。同期履歴ステートメントでは、多くの実施形態が一度に１方向に同期する。したがって図７Ｂを参照すると、デバイス７０４とデバイス７０３との間で履歴情報の２方向の同期の実行を試みる場合、まず（ｉ）デバイス７０４の情報をデバイス７０３に組み込み、次に（ii）デバイス７０３の情報をデバイス７０４に組み込む。当然ながら、逆の順番も同様に機能する。それでもやはりそれらの実施形態は、１方向同期技術の適用を増大させることにより２方向同期を実行するので、ここでは１方向同期を検討することにする。

図１２を参照すると、説明のために「Ａｌｐｈａ」と「Ｂｅｔａ」という名称の２つのデバイスで履歴情報を同期しているものと仮定する。この例では、デバイスＡｌｐｈａはローカル・ターゲット・クライアントであり、デバイスＢｅｔａは遠隔ソース・クライアントである。この例の効果は、Ｂｅｔａの履歴ステートメントをＡｌｐｈａに組み込むことである（すなわち、このプロセス中はＢｅｔａの履歴ストアは読み取り専用である）。概念上は、この同期は、単に、Ｂｅｔａのすべての状態がＡｌｐｈａの対応する状態を有することを保証するプロセスである。これは、現在は対応する状態のないＢｅｔａのいかなる状態にも対応するように、Ａｌｐｈａで新しい状態を作成することにより達成される。実際は、Ｂｅｔａ状態がＡｌｐｈａへの組み込みに関して特定される場合、関連付けられた（Ｂｅｔａでの）履歴ステートメントはローカルで使用するために翻訳され、Ａｌｐｈａの履歴ストアに追加される。この一般的なプロセスは、図１２Ｂのフロー・チャートに関して概念的に説明することができる。

図１２Ｂを参照すると、第１のステップ１２０１は、Ｂｅｔａの履歴ストアに表示される履歴ステートメントを考慮することである。次に決定ステップ１２０２で、調査された履歴ステートメントが既にＡｌｐｈａの履歴ストアに反映されているか否かを判定する必要がある。一般に、この判定は、等しい履歴ステートメントがあるか、同じ情報が他の何らかの方法でＡｌｐｈａ履歴ストアに存在するかに関するものである。判定１２０２が「はい」の場合、次いでプロセスはこの状態／履歴ステートメントに関して終了している。対応する状態がＡｌｐｈａで見つからない場合、次いでプロセスはステム１２０４に移動し、そこで検討中のＢｅｔａステートメントがＡｌｐｈａでローカルに使用するために翻訳される。ステップ１２０５では、ローカライズされたステートメントが、一時的保持のためにＡｌｐｈａ履歴ストアかマッピング・テーブルに挿入される。

ｅ．履歴の５ステップ同期
遠隔履歴ストアの履歴ステートメントをローカル履歴ストアに同期するための同期プロセスは、次の３ステップだけで簡単に述べることができる。（ｉ）すべての遠隔状態に対応するように新しいローカル状態を作成する（外部または同等の状態タイプ・コマンドを使用して）、（ii）すべての遠隔履歴ステートメントをローカル履歴ステートメントに翻訳し、それをローカル・ストアに置き（ステップ（ｉ）は、すべての必要な状態があることを保証する）、すべての遠隔履歴ステートメントを変換する、そして（iii）ローカル・ストアの複製を消去するよう試みる。しかしいくつかの実施形態では、履歴ステートメントの僅かにより複雑な５ステップ同期と比較した場合、この３ステップ・プロセスは比較的非効率的である。この５ステップについて、ターゲット（例えば、Ｂｅｔａ履歴ストア）までに５つの段階を通過するものとして述べる。各段階は、履歴ステートメントの異なるタイプまたは異なる状況に対処するように設計されている。したがって各段階は、Ａｌｐｈａの履歴ストアに組み込むように新しい履歴ステートメントを作成することができる。しかし実質的な作業を開始する前に、動作環境に記号論理を提供する必要がある。例えば一般的なコンピュータ処理環境では、メモリを割り当てることができ、マッピング・テーブルまたは類似のデータ構造を作成することができる。このような「マッピング・テーブル」は、そのようなステートメントのリストが５段階を通して増加するかまたは変更されるので、新しいＡｌｐｈａの新しい履歴ステートメントを維持するために使用される。さらに、テーブルなどの構造は、データ、他のメタデータまたはＢｅｔａ起源履歴ステートメントなど、Ａｌｐｈａの新しい履歴ステートメントに対応する情報を維持するために使用される。

第１の段階では、ソース（Ｂｅｔａ）履歴ストアにあるすべての「ｅｘｔｅｒｎａｌ」コマンドベースの履歴ステートメントを検査し翻訳する。したがって、いくつかの実施形態では、Ｂｅｔａ履歴ストアにある１つ１つの「ｅｘｔｅｒｎａｌ」ベースの履歴ステートメント（または同じスナップショット）の場合、Ａｌｐｈａに対応する状態の関連付けがあることを保証する。例えば、図１２の線１を参照すると、Ｂｅｔａ、Ｂ１からＢ５に５つの「ｅｘｔｅｒｎａｌ」ベースの状態が反映されている場合、次いでＢ１からＢ５までの５つの状態それぞれに対してＡｌｐｈａに等価の状態を確立する「Ｅｘｔｅｒｎａｌ」コマンドがＡｌｐｈａに確実にあることを確認する。上記のコマンド目録を使用してＡｌｐｈａ履歴ストアにＢ１からＢ３しか見つからなかった場合、それらのステートメントは次のように表示される場合がある。
Ａ１、外部、ベータ、Ｂ１
Ａ２、外部、ベータ、Ｂ２
Ａ３、外部、ベータ、Ｂ３。

本例では、Ｂ４とＢ５に対する「外部」対応が見つからなかったので、それらの状態に対してステートメントを作成し、それらを本例のテーブルに入れることができる。図１２を参照すると、サンプルの新しいステートメントが線１、「デバイスＡｌｐｈａ」欄に表示されている。図１２から明らかなように、ここではＡｌｐｈａの状態へのＢｅｔａの状態の外部マッピングを作成している。第１段階中、多くの実施形態は、（ｉ）コマンドｉｎ＿ｕｓｅと（ii）ターゲット・クライアント（Ａｌｐｈａ）との両方を有するソース（Ｂｅｔａ）にある履歴ステートメントを無視する。例えばそれらの実施形態では、ＡｎｙＳｔａｔｅ，ｉｎ＿ｕｓｅ，Ａｌｐｈａ，ＡｎｙＳｔａｔｅという形式のステートメントを無視する。それらの実施形態では、不要部分の整理が実行される場合、プロセスの最後でＡｌｐｈａに対する新しい状態「ｉｎ＿ｕｓｅ」が作成される。

第２の段階では、ターゲット（Ａｌｐｈａ）の既存の状態で表現することのできるソース（Ｂｅｔａ）内のすべての履歴ステートメントを処理する。語彙の問題として、ソース（Ｂｅｔａ）履歴ステートメントが現行で既存のターゲット状態を使用して表現できる場合、次いでそのような履歴ステートメントを「ローカライズする」ことができると表現する。ローカライズすることのできるいかなるソース（Ｂｅｔａ）履歴ステートメントに対しても、ローカライゼーション（既存のローカル状態を使用してステートメントを表現する）を実行し、新しいローカライズされた履歴ステートメントをターゲット（Ａｌｐｈａ）のマッピング・テーブル（または他の実施形態では履歴ストア）に追加することができる。当然ながら、ローカライズされた履歴ステートメントが既にＡｌｐｈａのストアにある場合、次いでそれをマッピング・テーブルに追加する必要はない。さらに、使用される正確なアルゴリズムに応じて、ローカライズされたバージョンが既に履歴ストアにあることを認識する前にステートメントを完全に「ローカライズする」ことは不要な場合がある。その場合、そのようなことが認識された時はいつでも、ローカライゼーション・プロセスを中止することができる。次の例で、このプロセスを説明する。この例のために、Ａｌｐｈａが既存の状態Ａ１からＡ１５を有し、Ｂｅｔａは既存の状態Ｂ１からＢ１８を有し、異なるピア・デバイスＫａｐｐａは既存の状態Ｋ１から１３を有すると仮定する。さらに、Ａｌｐｈａ、ＢｅｔａおよびＫａｐｐａの状態は数字に対応し（すなわち、Ａ１、Ａ２、Ａ３はＢ１、Ｂ２、Ｂ３に対応し、Ｋ１、Ｋ２、Ｋ３にそれぞれに対応する）、Ａｌｐｈａ、Ｂｅｔａ、Ｋａｐｐａそれぞれがすべての既存の対応を確立する「ｅｘｔｅｒｎａｌ」コマンド・ステートメントを有すると仮定する。次に図１２、線２を参照すると、「条件」欄に、第２段階の本例に対する２つの履歴ステートメントがある。本例のためには、どちらのステートメントもＢｅｔａのデータ・ストアに存在する。第１ステートメントはｕｓｅｒ＿ｅｄｉｔｅｄコマンドであるが、これはＢ５がＢｅｔａデバイスの状態Ｂ４オブジェクトをユーザが編集したことを反映する状態であることを示している。マッピング・テーブル欄の線２から分かるように、このステートメントはＡｌｐｈａ状態の相当語句を容易に翻訳する。これは、Ｂｅｔａ状態Ｂ４、Ｂ５、Ｂ１０がデバイスＡｌｐｈａで確立された対応を既に有しているからである（上記のように、対応は「ｅｘｔｅｒｎａｌ」コマンドベースの履歴ステートメントにより確立することができる）。同様に、図１２、線２は、ｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄコマンドを有する履歴ステートメントの一例を示す。

いくつかの実施形態では、第２段階は、上記のように単純にローカライズされないソース（Ｂｅｔａ）履歴ステートメントを変換するよう試みることもできる。したがってＢｅｔａ履歴ステートメントをローカライズすることができない場合、次いでそのステートメントはこのプロセスの候補になる。このプロセスは、ソース（Ｂｅｔａ）の履歴ステートメントとターゲット（Ａｌｐｈａ）の履歴ステートメントとの間の関係を（確実に）推論するものである。当然ながら、そのような推論を行う技術は、履歴ステートメントの中心部にあるコマンドにより様々である。例えば図１２の線３を参照すると、（ｉ）ソース（Ｂｅｔａ）のｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄステートメント（例えば、｛Ｂ１６，ｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄ，Ｋａｐｐａ，Ｂ３，Ｂ５｝）があり、（ii）ターゲットのｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄステートメント（例えば、｛Ａ９，ｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄ，Ｋａｐｐａ，Ａ３，Ａ５｝）があり、（iii）ここで、勝ち状態（Ａ３＆Ｂ３）と負け状態（Ａ５とＢ５と）との間に一致する対応がある場合、（iv）サブジェクト状態Ｂ１６とＢ９とが同じであると推論することができる。そのような推論をしたので、最終的にマッピング・ステートメントをマッピング・テーブル（または、他の実施形態では、ターゲット（Ａｌｐｈａ）履歴ストア）に追加することができる。具体的には、「ｅｘｔｅｒｎａｌ」コマンド・ステートメントと「ｅｑｕivａｌｅｎｔ＿ｓｔａｔｅｓ」コマンド・ステートメントという２つのタイプのマッピング履歴ステートメントについて検討した。この場合、第１段階の結果として、対応が既にマッピング・テーブル（マッピング・テーブルは新しい履歴ステートメントの一時保管場所であることを想起されたい）にある場合は、「ｅｘｔｅｒｎａｌ」コマンドを使用する。対応がまだマッピング・テーブルにない場合は、「ｅｑｕivａｌｅｎｔ＿ｓｔａｔｅｓ」コマンドを使用する。

第２段階を完了する前に、推論された関係によって生じた新しいマッピングがある場合、それら新しいマッピングがより多くのソース（Ｂｅｔａ）履歴ステートメントをローカライズするための情報を提供するか否かを判定するために第２段階が反復される。

第３段階では、サブジェクトを除いて既存のターゲット（Ａｌｐｈａ）履歴ストアにある履歴ステートメントと一致するソース（Ｂｅｔａ）履歴ストアにある履歴ステートメントを処理する。あるいは、サブジェクト状態を推測することのできるＢｅｔａ履歴ストアの履歴ステートメントを処理する。これらの履歴ステートメントはＡｌｐｈａストアにある相当語句を既に有しているが、それらの相当語句はまだ容易には識別されない。それは、「ｅｘｔｅｒｎａｌ」またはサブジェクト状態間の対応を作成する他のステートメントがないからである。例えば図１２、線４を参照すると、異なるサブジェクト（結果状態Ａ１３とＢ１６）を有するが、そうでない場合は等価のステートメントを有する２つのｋｎｏｗｎ＿ｅｑｕivａｌｅｎｔコマンドがある。勝ち状態（Ｂ３，Ａ３）が同じであり、負け状態（Ｂ５，Ａ５）が同じなので、サブジェクト状態Ａ１３とＢ１６とも等価に違いないということが分かる。したがって線４のマッピング・テーブル欄に示すような対応する「ｅｘｔｅｒｎａｌ」コマンド（マッピング・テーブルに対応が見つからないことをいくつかの実施形態に示す外部コマンドが使用される）を追加することができる。第３段階が完了する前に、第３段階の推論された関係によって生じた新しいマッピングがある場合、次いでそれらの新しいマッピングがより多くのソース（Ｂｅｔａ）履歴ステートメントをローカライズするための情報を提供するか否かを判定するために第２段階が反復される。

第４段階では、サブジェクトを除いて、すなわちサブジェクトを除くＢｅｔａ履歴ステートメントのすべての状態をＡｌｐｈａの現行の状態で表現することができる場合に、ローカライズすることのできるすべてのＢｅｔａの履歴ステートメントを取り扱う。この点で、そのようなＢｅｔａ履歴ステートメントの場合、（ｉ）そのサブジェクトをローカライズすることはできないこと（それは第２段階で発生したから）、および（ii）Ｂｅｔａ履歴ステートメントは既存のＡｌｐｈａ履歴ステートメントと一致しないこと（推測や推論を含めて、いかなる観点からも）が分かる。新しいＡｌｐｈａ状態を作成し、それをＢｅｔａ履歴ステートメントのローカライズされたバージョンにサブジェクトとして添えることにより、これらのステートメントを取り扱う。一例として、図１２の線５を参照すると、通常ならば一致するｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄ履歴ステートメントに新しい状態「ＡＮＥＷ」が添えられている。さらに、まだローカライズされてない新たに作成された状態（ＡＮＥＷ）とＢｅｔａサブジェクト状態との間に対応を確立する新しいマッピング・ステートメントを作成する（図１２の線４の例を参照のこと）。「ｅｘｔｅｒｎａｌ」または「ｅｑｕivａｌｅｎｔ＿ｓｔａｔｅｓ」コマンドを使用するという仕様は、既に指摘した通りに保たれる（関連付けがマッピング・テーブルにまだない場合は、外部を使用する）。さらに、以前のように新しいマッピングを段階４で作成した場合、段階２を再試行する。それは、その新しいマッピングにより、新しいＢｅｔａ履歴ステートメントをローカライズすることができるようになる場合があるからである。

最後の段階の第５段階では、残存するソース（Ｂｅｔａ）履歴ステートメントのそれぞれを次のように処理する。（ｉ）０か、またはマッピング・テーブルに既にマッピングされているサブジェクトを有する残存するステートメントを無視する、（ii）残存する「ｅｘｔｅｒｎａｌ」コマンドを無視する（必須でない処理時間または空間学習状態を浪費したくないという理由から）、（iii）まだマッピングされていないソース（Ｂｅｔａ）履歴にある各状態に対して新しいターゲット（Ａｌｐｈａ）状態を作成する、（iv）Ｂｅｔａステートメントに類似しているが、新たに作成されたＡｌｐｈａ状態を使用するターゲット（Ａｌｐｈａ）履歴ステートメントを作成する。例えば、図１２の線６を参照すると、Ｂｅｔａ履歴ステートメント上に段階５の変換｛Ｂ１８，ｃｏｎｆｌｉｃｔ＿ｒｅｓｏｌｖｅｄ，Ｋａｐｐａ，Ｂ１７，Ｂ１６｝（ＡｌｐｈａはＢ１６、Ｂ１７またはＢ１８に対する対応状態を持たないと仮定する）がある。線５に示すように、新しいＡｌｐｈａ状態ＡＮＥＷ１、ＡＮＥＷ２およびＡＮＥＷ３は、Ｂ１６からＢ１８のそれぞれに対して作成される。さらに、Ｂｅｔａ齟齬解決ステートメントは、新たに作成されたＡｌｐｈａ状態を使用して翻訳される。

他の場合として、段階５が新しいマッピングを作成した場合、段階２を再試行する。これは、新しいマッピングにより、新しいＢｅｔａ履歴ステートメントをローカライズすることができるようになる場合があるからである。

段階５の終わりでは、対象となるすべてのＢｅｔａ履歴ステートメントは既に処理済みであるべきである。

ｆ．不要部分の整理
上記のように、システム資源を消費する履歴ステートメント数を最低限に抑え、パフォーマンスを高めることが望ましい場合がある。したがって、いくつかの実施形態は、不要な履歴ステートメントを消去するために、不要部分の整理プロセスを使用する。不要部分の整理とは、削除できるものはあるか否か（それらがシステムの機能に不要なので）を判定するために履歴ストア内の履歴ステートメントを評価するプロセスである。一般に、不要部分の整理を有効にするには、それぞれのクライアントがすべての他のクライアントで使用中の状態と、すべての既知のクライアントで不要であるとされる不要部分の整理の状態だけとを追跡する。さらに具体的には、サンプル・プロセスを次に示す。

（ｉ）使用中の状態を追跡する
最初に、各クライアントは、それ自体とそれぞれの既知のピア同期クライアントとで使用中のすべての状態を追跡する。換言すれば、ある状態がデータ・ストアのオブジェクトを表すために使用されている場合、その状態は使用中である。例えば、図１３Ａを参照すると、データ・ストアに単一オブジェクト（Ｄｏｇ）１３０２がある。図の１３０１で示されるように、オブジェクトＤｏｇは状態５にある。これは、履歴ストア１３０３に示すように、このオブジェクトが作成され（第１の履歴ステートメントを生じて）、次いでユーザが４回編集したからである（各編集で新しい履歴ステートメントが生じる）。しかし、不要部分の整理のために、データ・ストア１３０５では状態５だけが使用中である。オブジェクトＤｏｇ１３０２を、現在のところこの拡張システムの唯一のオブジェクトであると仮定すると（すべてのデータ、すべての同期クライアント）、次いで履歴ステートメント１３１０から１３１３が不要であることは直感的に分かる（他のクライアントにそれらの編集について伝えていない場合、オブジェクトＤｏｇを何回編集したかは問題ではない）。したがって、図１３Ｂを参照すると、仮定したように、システムにおける１３Ａの同期クライアントの不要部分の整理の結果が示されている。図１３Ｂを見ると分かるように、履歴ステートメント１３１０から１３１３は、ステートメント１３１４だけを残して削除されている（データ・ストアで使用される唯一のサブジェクト状態であるサブジェクト５と共に）。さらに、履歴ステートメント１３１５は、クライアント「Ｕｎｔｉｔｌｅｄ」１３２０では状態５が使用中であり、Ｕｎｔｉｔｌｅｄに対する「ｕｓｅｒ＿ｅｄｉｔｅｄ」コマンドがその第１世代にあること（「１」）を記録するために追加される。

図１３Ｃを参照すると、使用中の状態を説明する別の例が示されている。具体的には、図１３Ｃは、データ・ストアの２つのオブジェクト１３５１と１３５２を示している。この場合、第１のオブジェクト１３５１が作成され、次いで７回編集される（したがって、それは状態８である）。次いでオブジェクト１３５２が作成され、２回編集される（したがって、それは状態３である）。したがって、状態８と３とは、クライアント「Ｕｎｔｉｔｌｅｄ」１３５０で使用中である。

最後に、使用中の状態の追跡について、そのような情報がどのようにして、または恐らくは何時、追跡されるかに関する問題がある。クライアントは、データ・ストアに変更があるたびに情報を再計算することにより、使用中のそのような状態を動的に追跡することができる。あるいは、クライアントは、不要部分の整理を実行する際、または同期を行う際に、使用中のその状態を計算することができる。

（ii）必須の履歴ステートメント
使用中の状態の追跡に加えて、指定された一組の使用中の状態があると仮定すると、どのクライアントに対してどの履歴ステートメントが必要かを理解するための機構である必要がある。所与のクライアントでデータ変更があるたびに、既知のクライアント１つ１つに対してどの履歴ステートメントが必須かを計算することができる。履歴ステートメントが既知のクライアントに対して必須の場合、次いでそれを保存する必要がある。例えば図１４Ａを参照すると、３つのクライアント１４１０、１４３０、１４５０を有する同期システムが示されている。図１４Ａと、図１５のチャートの行１と２を参照すると、クライアント１４１０には作成された単一オブジェクトがあり、すべてのクライアント間で同期が行われている。次に図１４Ｂと、図１５の行３を参照すると、クライアント１４１０はデータ１４１１を編集し、その編集はデータ・ストアと履歴ストアとの両方に反映される（１４１０の状態２）。図１５の（行３）コメントから分かるように、（状態２への）このデータ編集を維持する必要があるので、すべてのクライアントはそれについて知る必要がある。しかしクライアント１４１０は、もはや状態１履歴ステートメントは必要としないが、同じものを維持する必要がある。これは、クライアント１４１０は、クライアント１４３０と１４５０との存在については知っていても、それらがその変更を必要としていることは知らないからである。図１４Ｃと、図１５の行４を参照すると、データ・オブジェクト１４１１を再度編集し、それを状態３に移動し、対応する履歴ステートメントを作成する。次いで図１５の行４のコメントを参照すると、すべてのクライアント１４１０、１４３０、１４５０はこの変更（状態３）を維持するために、この変更を要求する。しかし、クライアント１４１０は実際には、もはや、状態２は必要とせず（Ａ’への変更）、関連する履歴ステートメントを維持する必要がある。これは、クライアント１４３０と１４５０とがそれを必要としているからである。次に図１４Ｄと、図１５の行５を参照すると、同期したクライアント１４１０と１４３０とがある。行５のコメントを参照すると、１４１０と１４３０とのどちらも、もはや、状態２または状態１を必要とはしていないが、１４３０が存在し、その状態を必要とする可能性があるという認識から、それを保存する。最後に、図１４Ｅと図１５の行６に移動し、次に３つすべてのクライアントを同期し、不要部分を整理する。次に状態１と２とが不要になったことは確かなので、サブジェクト状態１または２を有する履歴ステートメントを消去することができる。したがって、クライアントは、すべての他の既知のクライアントがその解放された状態を必要としないことを確信すると即座に、状態を解放することができることが分かる（その状態をサブジェクトとして有するいかなる履歴ステートメントでも）。

（iii）使用中情報の共有／同期
最後に、この情報を他のクライアントと共有するための機構（特定のクライアントがどのようにして、お互いクライアントが何を必要とする可能性があるかを知る）を有することができる。図１４Ａから１４Ｅを見ると分かるように、この機構は、「ｉｎ＿ｕｓｅ」コマンドを使用する履歴ステートメントである。上記のように、ｉｎ＿ｕｓｅ履歴ステートメントは、次の情報のすべてを保持することができる。すなわち、サブジェクト状態インジケータ（常に「０」である）、ｉｎ＿ｕｓｅコマンド、最近のｉｎ＿ｕｓｅコマンドだけが所与の同期クライアントと関連しているので、世代カウント（例では括弧内に示される）、そして最後に、使用中の状態リストである。それらの使用中のステートメントを維持し同期することにより、各クライアントは、他の既知のデバイスで使用中の状態は何か、最後に彼らが接続したのは何時か（恐らく、２方向に同期され、不要部分が整理される）を知ることができる。これは、デバイス１４３０と１４５０とのどちらもそれらの状態を必要としないことが検証されるまで、（上記の例では）クライアント１４１０がどのようにすれば状態１も２も破棄しないと知ることができるかということである。したがって、いくつかの実施形態では、それら他の同期クライアントが別のクライアントで必須の状態を処分しないように、ｉｎ＿ｕｓｅ履歴ステートメントをそれら他の同期クライアントに同期する必要がある。

したがって、一般的に述べるように、Ｎ個の他のクライアントに（恐らくは、過渡的に）接続した（すなわち、それについて知っている）所与のクライアントには、使用中ステートメントに反映されたＮ組の使用中状態がある。これらの使用中状態とそれらの子孫とは（祖先と反対の）、そのＮ個のクライアントのグループに対して関連する場合がある状態である。すべての他の状態を破棄することができる。通常、別のクライアントと接続した場合、複数群の祖先は相互に無関係か否か（図１５の線６のように）を判定することができる。そこには、不要部分を整理する機会がある。

上記の実施形態は、明示しない限り限定はしないが説明を目的としている。当業者は、これらの実施形態と説明とを様々な方法で構成することができる。このような構成は、本明細書の検討の一部として予想され、意図されるものである。

同期することのできるデバイスを示す図である。 ハードウェアの一例を示す図である。 ハードウェアの一例を示す図である。 ソフトウェア・スタックの一例を示す図である。 世代カウントの一例を示す一覧表である。 履歴データの一例を示す一覧表である。 例示の同期プロセスを示す図である。 例示のデバイス同期を示す図である。 データ構造配置の説明図である。 状態ベース同期を再帰的に適用するための例示のシステムを示す図である。 同期のための例示のプロセスを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 例示のデータと、対応する履歴ステートメントとを示す図である。 同期履歴のための一実施形態を示す一覧表である。 履歴同期の説明図である。 履歴ステートメントのサンプル使用例を示す図である。 履歴ステートメントのサンプル使用例を示す図である。 履歴ステートメントのサンプル使用例を示す図である。 履歴ステートメントの不要部分の整理を説明するサンプルである。 履歴ステートメントの不要部分の整理を説明するサンプルである。 履歴ステートメントの不要部分の整理を説明するサンプルである。 履歴ステートメントの不要部分の整理を説明するサンプルである。 履歴ステートメントの不要部分の整理を説明するサンプルである。 履歴使用例を示す図である。

Claims (71)

1. デバイスが、同期のためにデータと履歴データとの間の関連を維持する方法において、
   前記デバイスの第１の作成手段が、第１のデータを作成するステップと、
   前記デバイスの第２の作成手段が、前記第１のデータの前記作成に応答して、前記デバイスでデータが作成されたことを示す履歴データを作成するステップと、
   前記デバイスの関連付け手段が、前記履歴データを前記第１のデータと関連付けるステップと、
   前記デバイスの前記第１の作成手段が、前記第１のデータと同じ種類のデータであるが前記第１のデータとは異なる第２のデータを作成するステップと、そして
   前記デバイスの前記関連付け手段が、前記履歴データを前記第２のデータと関連付けるステップと
   を含む方法。
2. 前記第１のデータが記録などのデータ・セットである請求項１に記載の方法。
3. 前記第１のデータがデータ・アイテムである請求項１に記載の方法。
4. 前記第１のデータが写真を表す請求項１に記載の方法。
5. 前記第１のデータが音声を表す請求項１に記載の方法。
6. 前記履歴データが、データを作成するデバイスの識別および性質に関する情報を含む請求項１に記載の方法。
7. 前記デバイスの編集手段が、前記デバイス上で前記第１のデータを編集するステップと、
   前記第２の作成手段が、前記第１のデータを編集したデバイスと、前記編集前の前記第１のデータについての情報とを含む、新しい履歴データを生成するステップと、
   前記関連付け手段が、前記編集された第１のデータを前記新しい履歴データと関連付けるステップと
   をさらに含む請求項１に記載の方法。
8. データの同期を維持するためのデバイスにおいて、
   第１のデータと、前記第１のデータと同じ種類の第２のデータとを作成するためのユーザ入力インタフェースと、
   データが前記デバイスで作成されたことを示す第１の履歴ステートメントを作成し、また前記第１のデータ、前記第２のデータ、及び前記第１の履歴ステートメントを第１の状態に関連付けるためのプログラムされた命令を備えるプロセッサと、
   前記第１のデータと前記第１の状態との間の前記関連付けと、前記第２のデータと前記第１の状態との間の前記関連付けとの両方を維持するための第１のデータ構造を記憶する第１のメモリと、
   前記第１の履歴ステートメントと前記第１の状態との間の前記関連付けを維持するための第２のデータ構造を記憶する第２のメモリと
   を含むデバイス。
9. 前記第１のデータがデータ・アイテムである請求項８に記載のデバイス。
10. 前記第１のデータが音声を表す請求項８に記載のデバイス。
11. 前記第１のデータが写真を表す請求項８に記載のデバイス。
12. 前記第１の履歴ステートメントが、前記デバイスの識別と、データを作成した性質とに関する情報を含む請求項８に記載のデバイス。
13. 前記第１のメモリが磁気メモリである請求項８に記載のデバイス。
14. 前記第１のメモリが動的メモリである請求項８に記載のデバイス。
15. 前記第１のメモリがスタティック・メモリである請求項８に記載のデバイス。
16. 前記第１のメモリと前記第２のメモリとは同じである請求項８に記載のデバイス。
17. 前記第１のデータ構造と前記第２のデータ構造が、単一スープ・データ構造に組み込まれる請求項８に記載のデバイス。
18. 前記第１のデータ構造と前記第２のデータ構造が、単一フラット・データ構造に組み込まれる請求項８に記載のデバイス。
19. 前記第１のデータ構造と前記第２のデータ構造が別個のオブジェクトである請求項８に記載のデバイス。
20. デバイスがデータベースを同期させる方法において、
    前記デバイスの第１の関連付け手段が、第１のデータ構造において、第１の状態を複数の同じ種類のデータと関連付けるステップと、
    前記デバイスの第２の関連付け手段が、第２のデータ構造において、前記第１の状態を、データの変更を行ったデバイスと前記変更前のデータの状態とについての情報を含む、データの変更履歴を示す情報に関連付けるステップと、
    前記デバイスの変更手段が、前記複数のデータのうちの第１のデータを変更するステップと、
    前記デバイスの前記第１の関連付け手段が、前記第１のデータ構造において、第２の状態を前記第１のデータに関連付けるステップと、
    前記デバイスの前記第２の関連付け手段が、前記第１のデータの前記変更に関する変更履歴を示す前記情報が前記第２のデータ構造において前記第２の状態にまだ関連付けられていない場合、前記第２のデータ構造において、前記第２の状態を当該情報と関連付けるステップとを含む方法。
21. 前記第１のデータ構造がスープ・データベースである請求項２０に記載の方法。
22. 前記第１のデータ構造がフラット・ファイルである請求項２０に記載の方法。
23. 前記第１のデータ構造が複数のサブ・データ構造を含む請求項２０に記載の方法。
24. 前記第２のデータ構造がスープ・データベースである請求項２０に記載の方法。
25. 前記第２のデータ構造がフラット・ファイルである請求項２０に記載の方法。
26. 前記第２のデータ構造が複数のサブ・データ構造を含む請求項２０に記載の方法。
27. 第３のデータ構造が、前記第１と第２のデータ構造の両方を含む請求項２０に記載の方法。
28. 前記データが記録である請求項２０に記載の方法。
29. 前記データがデータ・アイテムである請求項２０に記載の方法。
30. 前記変更が編集である請求項２０に記載の方法。
31. 前記変更が削除である請求項２０に記載の方法。
32. 情報を同期させるためのデバイスにおいて、
    第１の状態を複数の同じ種類のデータと関連付けるための第１のデータ構造を記憶する第１のメモリと、
    前記第１の状態を、データの変更を行ったデバイスと前記変更前のデータの状態とについての情報を含む、データの変更履歴を示す情報と関連付けるための第２のデータ構造を記憶するための第２のメモリと、
    前記複数のデータの第１のデータを変更するためのユーザ入力インタフェースと、
    前記第１のデータ構造において、第２の状態を前記第１のデータに関連付け、
    前記第１のデータの前記変更に関する変更履歴を示す前記情報が前記第２のデータ構造において前記第２の状態にまだ関連付けられていない場合、前記第２のデータ構造において、前記第２の状態を前記第１のデータの前記変更に関する変更履歴を示す前記情報と関連付けるためのプログラムされた命令を備えるプロセッサと
    を含むデバイス。
33. 前記第１のメモリと前記第２のメモリが同じである請求項３２に記載のデバイス。
34. 前記第１のデータ構造がスープ・データベースである請求項３２に記載のデバイス。
35. 前記第１のデータ構造がフラット・ファイルである請求項３２に記載のデバイス。
36. 前記第１のデータ構造が複数のサブ・データ構造を含む請求項３２に記載のデバイス。
37. 前記データが記録である請求項３２に記載のデバイス。
38. 前記データがデータ・アイテムである請求項３２に記載のデバイス。
39. 前記データが音声を表す請求項３８に記載のデバイス。
40. 前記データが写真を表す請求項３８に記載のデバイス。
41. 前記変更が編集である請求項３８に記載のデバイス。
42. デバイスが、第１のデータ構造で維持された第１のデータを、第２のデータ構造で維持された、前記第１のデータと同じ種類の第２のデータと同期させる方法において、
    デバイスの第１の関連付け手段が、前記第１のデータ構造において、第１のデータの各データ・アイテムを第１の状態と関連付けるステップと、
    デバイスの第２の関連付け手段が、第３のデータ構造において、前記第１の状態を、データの変更を行ったデバイスと前記変更前のデータの状態とについての情報を含む、データの変更履歴を示す履歴ステートメントと関連付けるステップと、
    デバイスの第３の関連付け手段が、前記第２のデータ構造において、第２のデータの各データ・アイテムを前記第２のデータ構造の第２の状態と関連付けるステップと、
    デバイスの第４の関連付け手段が、第４のデータ構造において、前記第２の状態を、データの変更を行ったデバイスと前記変更前のデータの状態とについての情報を含む、データの変更履歴を示す履歴ステートメントに関連付けるステップと、
    デバイスの第１の同期手段が、同期された第４のデータ構造を作成するために、前記第３のデータ構造からの履歴ステートメントを前記第４のデータ構造に同期するステップと、
    デバイスの第２の同期手段が、前記同期した第４のデータ構造からの情報を使用して、前記第１のデータ構造からのデータを前記第２のデータ構造に同期するステップと
    を含む方法。
43. 前記第１と第３のデータ構造が同じである請求項４２に記載の方法。
44. 前記第１と第３のデータ構造が１つのデバイスに常駐し、前記第２と第４のデータ構造が別のデバイスに常駐する請求項４２に記載の方法。
45. 前記第３と第４のデータ構造のそれぞれにある前記履歴ステートメントの１つまたは複数の履歴ステートメントが、第１の状態と第２の状態の間の相関を含む請求項４２に記載の方法。
46. 前記第１のデータがＮ個のデータ・アイテムを含み、そのようなＮ個のデータ・アイテムがＭ個の状態に関連付けられており、Ｍ＜Ｎである請求項４２に記載の方法。
47. 遠隔デバイスと同期するためのローカル・デバイスにおいて、
    ローカル・データと、関連付けられたローカル・データ状態とを記憶するための第１のローカル・データ・ストアであって、複数の前記ローカル・データが前記遠隔デバイスに記憶された遠隔データと相関し、前記遠隔データが遠隔状態に関連付けられた、第１のローカル・データ・ストアと、
    履歴ステートメントを記憶するための第２のローカル・データ・ストアであって、前記履歴ステートメントが
    ローカル・データ状態を遠隔データ状態に関連付けるステートメントと、
    データの変更を行ったデバイスと前記変更前のデータの状態とについての情報を含む、種類が同じである複数のローカル・データおよび１つまたは複数の遠隔データの編集に関するステートメントと
    を含む、第２のローカル・データ・ストアとを含むデバイス。
48. 前記編集は作成することである請求項４７に記載のデバイス。
49. 前記編集は削除することである請求項４７に記載のデバイス。
50. 前記編集は切り捨てることである請求項４７に記載のデバイス。
51. Ｎ個のローカル・データがあり、そのようなＮ個のローカル・データがＭ個のローカル状態に関連付けられており、Ｍ＜Ｎである請求項４７に記載のデバイス。
52. デバイスが、複数のデータへの変更を追跡する方法において、
    前記デバイスの第１の関連付け手段が、種類が同じである第１の複数のデータを第１の状態と関連付けるステップであって、前記第１の複数のデータのすべてが第１の履歴を有し、前記第１の履歴は前記第１の複数のデータのすべてに対して同一であり、前記第１の履歴にはデータの変更を行ったデバイスと前記変更前のデータの状態とについての情報が含まれる、ステップと、
    前記デバイスの第２の関連付け手段が、前記第１の状態を前記第１の履歴を記述する第１の履歴ステートメントに関連付けるステップと
    を含む方法。
53. 前記第１の履歴が前記データの作成である請求項５２に記載の方法。
54. 前記第１の履歴ステートメントが、データが作成されたこと、およびどのようにデータが作成されたかを示す請求項５３に記載の方法。
55. 前記第１の履歴ステートメントが、データが作成されたこと、およびデータを作成するためにどのデバイスが使用されたかを示す請求項５３に記載の方法。
56. 前記第１の履歴ステートメントが、データが作成されたこと、および前記データ作成に関連付けられた同期クライアントを示す請求項５３に記載の方法。
57. 前記第１の履歴がデータの編集であり、前記編集がある同期クライアントに関連付けられた請求項５２に記載の方法。
58. 前記第１の複数のアイテムがアドレスと電話番号とを含む請求項５２に記載の方法。
59. 前記第１の複数のアイテムが２つのアドレスを含む請求項５２に記載の方法。
60. 前記デバイスの変更手段が、前記第１の複数のデータのうちの１つまたは複数のデータを含む、データの第１の部分集合に第１の変更を行うステップと、
    前記デバイスの前記第１の関連付け手段が、第２の状態をデータの前記第１の部分集合と関連付けるステップと、
    前記デバイスの前記第２の関連付け手段が、第２の履歴ステートメントを前記第２の状態に関連付けるステップと
    をさらに含む請求項５２に記載の方法。
61. 第２の履歴ステートメントを前記第２の状態に関連付ける前記ステップが、前記第２の履歴ステートメントを作成することを含む請求項６０に記載の方法。
62. 前記第１の変更がデータの前記第１の部分集合を削除することである請求項６０に記載の方法。
63. 前記第１の変更が、データの前記第１の部分集合の前記データのそれぞれを独立して編集することである請求項６０に記載の方法。
64. 前記複数のデータおよびすべての関連付けられた履歴ステートメントが第１の共通データ構造で維持される請求項６０に記載の方法。
65. 第２の共通データ構造から前記第１の共通データ構造に履歴ステートメントを同期させるステップをさらに含む請求項６４に記載の方法。
66. 前記第１の共通データ構造が第１のデバイスに常駐しており、前記第２の共通データ構造が第２のデバイスに常駐している請求項６５に記載の方法。
67. 同期した第１の共通データ構造からの不要な履歴ステートメントを低減させるステップをさらに含む請求項６４に記載の方法。
68. 低減させる前記ステップが、使用中状態の子孫であるサブジェクト状態を履歴ステートメントが有するよう維持することを含む請求項６７に記載の方法。
69. 前記同期した第１の共通データ構造からの不要な履歴ステートメントを低減するステップをさらに含む請求項６６に記載の方法。
70. 低減する前記ステップが、前記第１のデバイスまたは前記第２のデバイスの使用中状態の子孫であるサブジェクト状態を履歴ステートメントが有するよう維持することを含む請求項６９に記載の方法。
71. コンピュータに、請求項１、２０、４２、又は５２のどれか１つに記載の各ステップを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images