JP4405812B2 - 第１データ記憶部と第２データ記憶部との間で同期を取るための方法および装置 - Google Patents

Description

本発明は、卓上カレンダーおよび電子メール等の１つまたは２つ以上のアプリケーションのデータ項目を記憶している異なるデータ記憶部（データ記憶装置）の間で同期を取るための方法に関し、特に本発明は、このようなデータ記憶部のデータ構造間の同期を取るための方法に関する。

今日、ビジネスマンが、携帯電話または手の平サイズ（ハンドヘルド型）のコンピュータ（または他の移動端末）上で（予約を記録しておくための）電子メールアプリケーションやカレンダーアプリケーションを利用し、ビジネスマンの代わりに補助装置が送受信した電子メールや予約を記録するためにデスクトップコンピュータ上で上記の電子メールアプリケーションやカレンダーアプリケーションを補助装置に使用させることによって、ビジネスマンのために予約を記録しておくことが可能になっている。このような構成ではよくあることであるが、電子メールアプリケーションのデータ項目（ここでは、データユニットとも呼ばれる）やカレンダーのデータ項目が、携帯電話やデスクトップ型の他のデータ記憶部に保存されることがある。それゆえに、それぞれ電子メールおよびカレンダーの双方のアプリケーションのデータ項目を含むデータ記憶部のうち、いずれかのデータ記憶部に対して変更が加えられた場合、これらのデータ記憶部間の同期を取る必要が生じる。異なる機器で動作する２個のアプリケーションによってそれぞれ使用されるデータ記憶部間の同期を取る際（すなわち、２台のデータ記憶部のデータ項目およびデータ構造の双方の同期を取る際）に、最後の同期以後の変更が伝達されるプロトコルに基づいて２台のデータ記憶部の内容がお互いに対応するように設定され、（ある方針に従って）各々の機器に対してなされた変更間の衝突は解消され、２台のデータ記憶部の一方または双方のデータ項目または上記構成のいずれかまたはその双方に対して変更が加えられる。

このようなデータ記憶部間の同期を取るための機能が、いわゆるＳｙｎｃＭＬ Ｉｎｉｔｉａｔｉｖｅ（ＳｙｎｃＭＬイニシアティブ）にて開発されているような、いわゆるＳｙｎｃＭＬ（Ｓｙｎｃマークアップ言語）に基づいて開発されつつある（ＳｙｎｃＭＬの基準および仕様を含むＳｎｃＭＬの情報を含むＳｙｎｃＭＬの情報、および、ＳｙｎｃＭＬ Ｉｎｉｔｉａｔｉｖｅ（ＳｙｎｃＭＬイニシアティブ）の情報、特にＳｙｎｃＭＬ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳｙｎｃＭＬ表現プロトコル）およびＳｙｎｃＭＬ Ｓｙｎｃ Ｐｒｏｔｏｃｏｌ（ＳｙｎｃＭＬ同期プロトコル）の情報については、ｈｔｔｐ：／／ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ／を参照のこと）。ＳｙｎｃＭＬは、遠隔データ（例えば、異なる機器および異なるデータ記憶部に記憶されているデータ項目）および多数のネットワーク、プラットフォームおよび装置間の個人的情報の全般的な同期のための共通言語の公開された工業基準である。ＳｙｎｃＭＬにより、例えば全体としてまたは一部で無線通信または有線通信を行うことができるようなＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ユニバーサル・モービル・テレコミュニケーションズ・システム）（ＵＭＴＳ）、Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ラジオ・アクセス・ネットワーク）（ＵＴＲＡＮ）およびＩｎｔｅｒｎｅｔ（インターネット）を含む１つまたは２つ以上の相互接続用のネットワークを介して接続された異なる装置上で、データ項目（まだデータ構造ではない）の同期を取ることができる。このように、例えば固定ネットワーク（無線ネットワークを含む）、赤外線、ケーブルまたはＢｌｕｅｔｏｏｔｈ（ブルートゥース）を介して異なる装置間で通信を行うことが可能である。

ＳｙｎｃＭＬ（すなわち言語）は、データ記憶部間の同期を取る目的の他に、装置管理のために使用される。特に、クライアントと当該クライアントの管理サーバとの間の管理動作を転送するために使用される。仕様書すなわちＳｙｎｃＭＬ装置管理プロトコルを探すには、ｈｔｔｐ：／／ ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ／を参照していただきたい。ＳｙｎｃＭＬは、管理対象上で管理命令を実行させ、ＳｙｎｃＭＬ同期プロトコルおよびＳｙｎｃＭＬ表現プロトコルと同様のパッケージフォーマットを利用する。管理対象は、装置用の一揃いの構成パラメータを反映することがある。この管理対象に対する動作には、読み取りパラメータおよび設定パラメータが含まれることがある。他の管理対象として、装置上のソフトウェアアプリケーションの実行時環境であることもある。この種の管理対象に対して行われる動作としては、ソフトウェア要素のインストール、ソフトウェア要素の更新、またはソフトウェア要素のアンインストールが含まれる。その動作は、ＳｙｎｃＭＬ表現プロトコルの装置管理使用方法にて記述されているＳｙｎｃＭＬ管理プロトコルにより表される。ここで使用されるコマンドおよびメッセージ構造は、ＳｙｎｃＭＬ同期プロトコルのものにまさしく対応する。（このように、管理プロトコルのいわゆる文書型の定義は、ＳｙｎｃＭＬ同期プロトコルからの文書型の定義である。）

今まで、移動データの同期の進歩は、いくつかの制約によって多くのことが決定されてきた。データ記憶部の同期は、一揃いの異なる所有権付きのプロトコルに基づいてなされており、このプロトコルはそれぞれ、ごく限られた数の装置、システムおよびデータ型に対してのみ機能する。このような相互運用性のない技術のために、ユーザ、製造業者、サービスプロバイダおよび開発者の業務が複雑になってきた。さらに、所有権を有する異なるデータ記憶部の同期のプロトコルが増加すると、携帯装置の使用の拡大に障害となり、データアクセスやデータの配信が制限されると共に、ユーザの移動性が制限されてきた。

モバイル計算機や移動通信機器の人気が高まるにつれ、ユーザは、手に入る機器は何でも利用し、どこにいても、更新された情報やアプリケーションに対するアクセスを行うことを望んでおり、ＳｙｎｃＭＬ等の公開基準の必要性が高まる。

ＳｙｎｃＭＬは、Ｗｏｒｌｄ Ｗｉｄｅ Ｃｏｎｓｏｒｔｉｕｍ（ワールドワイドコンソーシアム）（Ｗ３Ｃ）のＸＭＬ Ａｃｔｉｖｉｔｙ（ＸＭＬアクティビィティ）（ウェブサイトｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ．）の製品であるＥｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ言語（拡張マークアップ言語：ＸＭＬ）１．０に示された、いわゆる拡張マークアップ言語（ＸＭＬ）のシンタックスを使用している。ＸＭＬの情報については、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ．ＸＭＬを参照していただきたい。

ここで使用されているように、データ項目またはデータユニットという専門用語は、いわゆるディレクトリ構造やデータ構造を順次形成するようないわゆるフォルダに構成されたデータの単位のことをいう。図４を参照すると、それぞれ１つまたは２つ以上のデータユニットを含むことが可能な種々のフォルダを含むディレクトリ構造が示されている。

ディレクトリ構造またはデータ構造という用語およびフォルダという用語は、広い意味に解釈されるものとする。まず、フォルダは、データユニットの任意のコンテナという意味に解釈されなければならない。このように、例えば、種々のオペレーティングシステム（マイクロソフトから入手可能なウィンドウズ（Ｗｉｎｄｏｗｓ）等）においてフォルダと呼ぶものは、ここで使用されるフォルダという用語の意味に理解されるものとするが、リレーショナルデータベースのテーブルにおけるレコードはデータユニットであるフィールドを含むために、リレーショナルデータベースのテーブルにおけるレコードにおいてもそのようにする。フィールドはデータユニットとみなすことのできる文字、数字およびその他の要素を含むため、このようなフィールドでさえもフォルダとみなされる。したがって、フィールドの各々がフォルダである。

ディレクトリ構造またはデータ構造という用語は、例えばデータユニットがファイルされる場合のオペレーティングシステムによって維持されるディレクトリの中のフォルダの木構造（tree structure）のような、データ記憶部におけるフォルダの構成を表す。しかしながら、ディレクトリ構造またはデータ構造という用語は、アプリケーションによって内部にて維持されるディレクトリ構造、すなわちオペレーティングシステムによって維持されないが、オペレーティングシステムによって動作するアプリケーションによって維持されるディレクトリ構造をも包含するものとして理解されるべきである。１つの例は、通常少なくとも２つのフォルダ、すなわち受信メールフォルダ（受信箱）と送信メールフォルダ（送信済み）とを含むほとんどすべての電子メールによって維持されるディレクトリ構造の例である。さらに、ディレクトリ構造またはデータ構造という専門用語は、（ディレクトリ構造が一個のアプリケーションの内部にのみ存在するものではなく、数個のアプリケーションであって、通常はインタフェースが良好でいずれもディレクトリ構造に対して変更を加えるようなアプリーションに内在するように）異なるアプリケーションにより共有される内部データ構造を含むように理解されなければならない。さらに、ディレクトリ構造すなわちデータ構造という用語は、システムディレクトリ構造および内部ディレクトリ構造の意味としても理解されなければならない。電子メールアプリケーションにより維持される内部ディレクトリの場合には、データユニットとは、内部ファイルの一種である電子メールである。いずれの型のディレクトリ構造においても、一般的に、フォルダは、異なるアプリケーションに属するデータユニットを含み、上記のアプリケーションは、データユニットに関連して保持される属性、または自分自身に属するデータユニットのすべての専用テーブルを保持するアプリケーションのいずれかに基づいて、当該データユニットがどこに配置されていても自分自身または他のアプリケーションに属するデータユニットを認識している。また一方で、既に説明したように、フォルダは例えば、データベースのテーブル内のレコードまたはそのようなレコード内のフィールドさえも表すことができるので、ディレクトリ構造すなわちデータ構造という専門用語は、データベース構造（フォルダがレコードの場合）やレコード構造（フォルダがフィールドの場合）さえも包含するものと理解されるべきである。フォルダという用語は、データユニットのすべてのコンテナを表すために、上記のように拡大して使用されていると解釈されることが重要であり、ディレクトリ構造またはデータユニットという専門用語はこれに対応して拡大された意味を有している。

アプリケーションのユーザは、データ項目の保存方法の変更（例えば、新規フォルダの追加、および、いくつかのデータユニットを既存のフォルダから新規フォルダへ移動すること）のみならず、当該アプリケーションに属する双方のデータユニットに変更を加えることが可能であり（例えば、新規データの追加、または、ユーザがデータユニットの内容を変更するためにアプリケーションを使用したことによって当該データユニットを更新したバージョンに置き換えること等）、すなわち、フォルダのみならずデータユニットに対しても変更を加えることができる（すなわち、ディレクトリ構造全体）。しかしながら、ＳｙｎｃＭＬに関する従来の技術によれば、ユーザが装置上のフォルダに変更を加えた場合、当該装置上のデータ記憶部と他の装置上で維持されるような対応するデータ記憶部との同期を取るために、ＳｙｎｃＭＬを利用することができなかった。ＳｙｎｃＭＬに関する従来の技術では、データユニットに変更を加えることに関してのみ同期を取ることができる。

ＳｙｎｃＭＬメッセージはネスト構造（nested structure）であり、１つまたは２つ以上のＳｙｎｃＭＬメッセージは、いわゆるＳｙｎｃＭＬパッケージに関連付けることができる。ＳｙｎｃＭＬメッセージは、それぞれ１つまたは２つ以上の要素型の１つまたは２つ以上の要素からなる個別のＸＭＬ文書である。この文書は、ＳｙｎｃＨｄｒ（Ｓｙｎｃヘッダ）の要素型により指定されるヘッダ、およびＳｙｎｃＢｏｄｙ（Ｓｙｎｃボディ）の要素型により指定される本体から構成される。ＳｙｎｃＭＬのヘッダは、ＳｙｎｃＭＬメッセージのルーティング（routing ）およびバージョニング（versioning）に関する情報を指定する。ＳｙｎｃＭＬ本体は、１つまたは２つ以上のＳｙｎｃＭＬコマンドのコンテナである。ＳｙｎｃＭＬコマンドは、個々の要素タイプにより指定される。ＳｙｎｃＭＬコマンドは、すべてのデータまたはメタ情報を含め、ＳｙｎｃＭＬコマンドの仕様を記述した他の要素タイプのコンテナとして作用する。

ＳｙｎｃＭＬでは、要求コマンドおよび応答コマンドを規定している。要求コマンドには以下のものが含まれる。例えば、ａｄｄ（発信側に対し、受信側にアクセスすることが可能なデータに１つまたは２つ以上のデータユニットの追加を要求させるコマンド）、ａｌｅｒｔ（発信側が受信側に対し、状態を通知させるコマンド）、ｃｏｐｙ（発信側に対し、受信側にアクセスすることが可能な１つまたは２つ以上のデータユニットのコピーを要求させるコマンド）、ｄｅｌｅｔｅ（発信側に対し、受信側にアクセスすることが可能な１つまたは２つ以上のデータユニットの削除または保存を要求させるコマンド）、ｇｅｔ（発信側に対し、受信側からの１つまたは２つ以上のデータユニットを要求させるコマンド）、およびｓｅａｒｃｈ（受信側にアクセスすることが可能な１つまたは２つ以上のデータユニットに対し、供給されたクエリー（query ）を実行させることを発信側に要求させるコマンド）が含まれる。現在、応答コマンドは以下のものだけである。すなわち、ｓｔａｔｕｓ（動作の完了状況を示すコマンド、または以前の要求を処理している最中にエラーが発生したことを示すコマンド）およびｒｅｓｕｌｔｓ（ＳｙｎｃＭＬのＧｅｔコマンドまたはＳｅａｒｃｈコマンドのいずれか一方のデータ結果を返送するために使用されるコマンド）である。

データユニットまたはフォルダを識別するために、ＳｙｎｃＭＬは識別子を使用する。この識別子は、いわゆるソースおよびターゲットの要素型に含まれ、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ（ユニフォーム・リソース・アイデンティファイア：ＵＲＩ）、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｎａｍｅｓ（ユニフォーム・リソース・ネーム：ＵＲＮ）の組み合わせであり得る。（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｎｄｅｎｔｉｆｉｅｒ（インターナショナル・モービル・イクィップメント・アイデンティファイア：ＩＭＥＩ）を表すために、ＳｙｎｃＭＬはＩＭＥＩ ＵＲＮの要素型を使用する。このＩＭＥＩ ＵＲＮは、有効１５桁のＩＭＥＩを指定する。その上、ＳｙｎｃＭＬは、ＳｙｎｃＭＬ指定名スペースおよび一意名（unique name ）を識別するために、ＳｙｎｃＭＬ ＵＲＮの要素型を使用する。また一方で、他のＵＲＮの要素型は、ＬｏｃＵＲＩの要素型において使用することができる。）

既に述べたように、ＳｙｎｃＭＬ表現プロトコル（すなわちＳｙｎｃＭＬメッセージ）は、ＸＭＬ要素型からなる文書マークである。要素型は、その目的または用途、親要素、コンテントまたは使用に対するすべての規制、およびコンテントモデルにより規定される。要素型には、いわゆる共用要素、メッセージコンテナ要素、データ記述要素、プロトコル管理要素およびプロトコルコマンド要素が含まれる。

共用要素型は、他のＳｙｎｃＭＬで使用される要素型で、例えば、ｄｅｌｅｔｅコマンドで指定されるデータがｄｅｌｅｔｅコマンドの受信側によって削除ではなく保存されるべきであることを示すアーカイブ（archive ）を含む。このように、ｄｅｌｅｔｅコマンドはアーカイブ共用要素を使用することが可能であり、この関係でアーカイブ共用要素型の親要素であるといわれる。他の要素型として、Ｃｍｄの要素型があり、これはＳｔａｔｕｓの要素型により参照されるＳｙｎｃＭＬコマンドを規定するために使用される（よって、この関係でＳｔａｔｕｓの要素型は親要素である）。他の要素型として、ＣｍｄＩｄの要素型があり、これはＳｙｎｃＭＬメッセージ一意コマンド識別子を指定するために使用され、Ａｄｄ、Ａｌｅｒｔ、Ａｔｏｍｉｃ、Ｃｏｐｙ，Ｄｅｌｅｔｅ、Ｅｘｅｃ、Ｇｅｔ、Ｍａｐ、Ｐｕｔ、Ｒｅｐｌａｃｅ、Ｒｅｓｕｌｔｓ、Ｓｅａｒｃｈ、Ｓｅｑｕｅｎｃｅ、ＳｔａｔｕｓおよびＳｙｎｃを含む種々の親要素を持つことが可能である。

本発明に関して特に注目すべき点は、共通要素型ＬｏｃＮａｍｅ、ＬｏｃＵＲＩ、ＳｏｕｒｃｅおよびＴａｒｇｅｔである。ＬｏｃＮａｍｅは、ターゲットまたはソースアドレスの表示名を指定するために用いられ、ＴａｒｇｅｔまたはＳｏｕｒｃｅの親要素として持つことが可能である。ＬｏｃＵＲＩは、ターゲットまたはソース指定アドレスを指定し、同様にＴａｒｇｅｔまたはＳｏｕｒｃｅの親要素として持つことが可能である。共通要素型Ｓｏｕｒｃｅは、ソースのルーティング情報またはマッピング情報を指定するために用いられ、その親要素はＩｔｅｍ、Ｍａｐ、ＭａｐＩｔｅｍ、Ｓｅａｒｃｈ、ＳｙｎｃおよびＳｙｎｃＨｄｒを含む。Ｔａｒｇｅｔは、ターゲットのルーティング情報またはマッピング情報を指定するために使用され、その親要素はＩｔｅｍ、Ｍａｐ、ＭａｐＩｔｅｍ、Ｓｅａｒｃｈ、ＳｙｎｃおよびＳｙｎｃＨｄを含む。

メッセージコンテナの要素型は、ＳｙｎｃＭＬメッセージのための基本的なコンテナサポートを提供する。このようなメッセージコンテナの要素型としては、以下の３つの要素型がある。第１の要素型はＳｙｎｃＭＬであり、これはＳｙｎｃＭＬメッセージのコンテナを指定し、いわゆるルート要素または文書要素であるために親を持たない。第２の要素型はＳｙｎｃＨｄｒであり、これはＳｙｎｃＭＬメッセージ中における修正情報またはルーティング情報（あるいは両者）のためのコンテナを指定し、ＳｙｎｃＭＬ要素を親要素として持つ。第２の要素型はＳｙｎｃＢｏｄｙであり、これはＳｙｎｃＭＬメッセージの本体またはコンテンツのためのコンテナを指定し、これもまたＳｙｎｃＭＬ要素を親要素として持つ。

データ記述要素は、ＳｙｎｃＭＬメッセージにおいて交換されたデータのコンテナ要素として使用され、このデータ記述要素は以下の要素型を含む。第１の要素型は、Ｄａｔａであり、これは離散型ＳｙｎｃＭＬデータを指定し、（親要素）Ａｌｅｒｔ、Ｃｒｅｄ、Ｉｔｅｍ、Ｓｔａｔｕｓ、およびＳｅａｒｃｈの要素型により使用される。第２の要素型は、Ｉｔｅｍであり、これは項目データのコンテナを指定するために使用され、（親要素）Ａｄｄ、Ａｌｅｒｔ、Ｃｏｐｙ、Ｄｅｌｅｔｅ、Ｅｘｅｃ、Ｇｅｔ、Ｐｕｔ、Ｒｅｐｌａｃｅ、ＲｅｓｕｌｔｓおよびＳｔａｔｕｓにより使用される。第３の要素型は、Ｍｅｔａであり、これは親要素型に関するメタ情報を指定するために使用され、（親要素）Ａｄｄ、Ａｔｏｍｉｃ、Ｃｈａｌ、Ｃｏｐｙ、Ｃｒｅｄ、Ｄｅｌｅｔｅ、Ｇｅｔ、Ｉｔｅｍ、Ｍａｐ、Ｐｕｔ、Ｒｅｐｌａｃｅ、Ｒｅｓｕｌｔｓ、Ｓｅａｒｃｈ、ＳｅｑｕｅｎｃｅおよびＳｙｎｃにより使用される。

現在、プロトコル管理要素は、表示されたＳｙｎｃコマンドのための要求ステータスコードを指定するＳｔａｔｕｓの要素型のみを含み、（親要素）ＳｙｎｃＢｏｄｙにより使用される。

最後にプロトコルコマンド要素を説明する。これらのプロトコルコマンド要素には、既に述べたコマンド要素が含まれる。すなわち、当該コマンド要素には、例えば、Ａｄｄが含まれており、これはデータがデータ集合に付加されることを指定し、（親要素）Ａｔｏｍｉｃ、Ｓｅｑｕｅｎｃｅ、ＳｙｎｃおよびＳｙｎｃＢｏｄｙにより使用される。その他のコマンド要素には、ＤｅｌｅｔｅおよびＲｅｐｌａｃｅ等が含まれる。

上記の要素型はすべて、基準であるＳｙｎｃＭＬ表現プロトコルに記載されており、インターネット（ｈｔｔｐ：／／ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ／ｄｏｃｓ／ｓｙｎｃｍｌ＿ｒｅｐｒｅｓｅｎｔ＿ｖ１１＿２００２０２１５．ｐｄｆ．）上で入手可能である。

同一のアプリケーションが同期プロトコルに従ってデータの取り扱いおよび通信の取り扱いを処理する場合には、ディレクトリ構造における通信の変更は問題にはならない。しかしながら、各々の装置において、数個のアプリケーションがディレクトリ構造として構成された一台のデータ記憶部を共有し、当該アプリケーションのそれぞれのデータユニットを一個以上のディレクトリ構造のフォルダに保存するといったような、より一般的な問題の場合には、データユニットだけでなくフォルダをどのように配置したら最良であるかということ、すなわち、そのためには同期プロトコルをどのように構成したら最良であるかということが明らかになっていない。公開基準、すなわちＳｙｎｃ Ｉｎｉｔｉａｔｉｖｅ（Ｓｙｎｃイニシアティブ）の製品であるＳｙｎｃＭＬ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳｙｎｃＭＬ同期プロトコル）によれば、（あらゆる点において）同期される各々のデータ記憶部を有する２台の遠隔装置の各装置は、同期（Ｓｙｎｃ）エージェント（装置１台につき１個、使用される多くの異なるアプリケーションについても同様）および１つまたは２つ以上のアプリケーション実体を含み、以下の同期プロトコル（すなわち、公開基準中に記載された同期プロトコルに従って通信を行うこと）は、アプリケーションではなく、同期エージェントに責任がある。（アプリケーションではなく、同期エージェントのみがＳｙｎｃＭＬを解釈する。）しかしながら、アプリケーションだけが、データユニットが直近に実行された同期以後に変更されたかどうかを認識している。同期エージェント中で符号化されたもののように、ＳｙｎｃＭＬ同期プロトコル中にＳｙｎｃＭＬの知識を要求するＳｙｎｃＭＬ同期プロトコルをどのように展開するかといったようないくつかの選択肢と、同期エージェントに対して、異なるアプリケーションが行っている方法により、データユニットの解釈を要求するいくつかの選択肢がある。

ＳｙｎｃＭＬ（または、同様の同期言語）が、同期エージェントおよびアプリケーション上の要求を最小化し、これによって、符号情報およびフォルダ情報の複製の必要性を回避するような方法で、ディレクトリ構造中のフォルダ等のデータ構造の状況を参照することが必要である。

上記問題点を解決するために、本発明の第１の態様において、第１データ記憶部に関連して動作する第１同期エージェントおよび第２データ記憶部に関連して動作する第２同期エージェントにより使用するための方法であって、第１データ記憶部は第２データ記憶部に同期されており、第１データ記憶部および第２データ記憶部の各々は、第１同期エージェントおよび第２同期エージェントとはそれぞれ異なる第１アプリケーションおよび第２アプリケーションによりデータをデータユニットとしてフォルダに記憶するために使用され、このフォルダは互いに組み合わされてデータ構造を定義する方法が提供される。この方法は、第１同期エージェントおよび第２同期エージェントが、上記第１同期エージェントおよび第２同期エージェント間の通信を可能にするトランスポート接続を確立するステップと、第２同期エージェントが、トランスポート接続を介してメッセージを第１同期エージェントに送信するステップとを有しており、当該メッセージはマークアップ言語を用いて表現され、少なくとも１つのデータ識別要素を有する（ここで使用される「データ識別要素」という用語は、ＳｙｎｃＭＬの中でＴａｒｇｅｔ（ターゲット）の要素と呼ばれるもの、またはＳｙｎｃＭＬの中でＳｏｕｒｃｅ（ソース）の要素と呼ばれるもののいずれか一方を示すために使用されているが、ＳｙｎｃＭＬと同様のすべてのマークアップ言語における同様の要素を包含するものと理解されるべきであって、データ識別要素という用語はデータ要素との対比の中にあり、当該データ識別要素という用語は、ＳｙｎｃＭＬまたはデータユニットを含む同様の言語における要素に言及する）。上記の方法において、第１データ記憶部または第２データ記憶部のデータ構造の変更に関する情報は、上記メッセージにおいて送信され、さらに、上記の第１データ記憶部または第２データ記憶部のデータ構造の変更に関する情報は、少なくとも１つのデータ識別要素にて設定される。

本発明の第１の態様において、少なくとも１つのデータ識別要素はデータ要素（すなわち、ＳｙｎｃＭＬマークアップ言語のデータ記述要素の特定の型またはＳｙｎｃＭＬマークアップ言語と同様の言語における同様の要素）の外部に備えること（すなわち、当該データ要素に含まれないこと）が可能である。さらに、本発明の第１の態様において、第１データ記憶部および第２データ記憶部のデータ構造の変更に関する情報は、フォルダの識別子を含んでいてもよい。さらにまた、少なくとも１つのデータ識別要素は、ターゲット要素またはソース要素であってよい。さらにまた、データ識別要素は、プロトコルコマンド要素に含まれていてよく、このプロトコルコマンド要素は、データ識別要素と組み合わされて、第１データ記憶部または第２データ記憶部のデータ構造の変更に関する情報を表示してよい。さらにまた、データ識別要素は、第２同期エージェントにより割り当てられた（マークアップ言語ＳｙｎｃＭＬにおける）いわゆるＬｏｃＵＲＩの要素（または同様のマークアップ言語における同様の要素）を含んでいてよく、第１データ記憶部または第２データ記憶部のデータ構造の変更に関する情報は、ＬｏｃＵＲＩ内で提供されるものであってよい。

さらに、本発明の第１の態様において、第１装置は、第１データ記憶部のみならず第１同期エージェントおよび第１アプリケーションのホストであってよく、および第２装置は、第２同期エージェント、第２データ記憶部および第２アプリケーションのホストであってよい。さらに、第１装置は、クライアント／サーバプロトコルにおいて、クライアントとして機能することが可能であり、第２装置は、クライアント／サーバプロトコルにおいて、サーバとして機能することが可能であり、メッセージが、クライアントからサーバへ提供され得る。さらにまた、第１装置は、クライアント／サーバプロトコルにおいて、サーバとして機能することが可能であり、第２装置は、クライアント／サーバプロトコルにおいて、クライアントして機能することが可能であり、メッセージが、サーバからクライアントへ提供され得る。メッセージを伝達するステップは、クライントメッセージに応答してよく、（さらに）サーバがホストであるデータ記憶部に関するクライアントメッセージが引き起こす任意の衝突に対する解決策を含んでいてもよい。

さらに、本発明の第１の態様において、第１アプリケーションはメッセージに含まれる任意のデータ要素に応答してよく、第１同期エージェントはデータ識別要素に応答してよく、また一方で、メッセージに含まれる任意のデータ要素により伝達される情報に基づいて、第１アプリケーションがデータ記憶部のデータユニットに何らかの変更を加える前に、第１同期エージェントは、データ識別要素により伝達される情報に基づいて、第１データ記憶部のデータ構造に変更を加えてよい。また一方で、第２同期エージェントは、データ識別要素において、第１データ記憶部または第２データ記憶部のデータ構造の変更に関する情報を提供することが可能であり、第２アプリケーションは、データ要素において、第１データ記憶部または第２データ記憶部のデータユニットの変更に関する情報を提供することが可能である。さらにまた、第１同期エージェントは、メッセージに応答して、データ構造の変更に関する情報をデータ識別要素から抽出してよく、当該情報を同期エンジンまたはアプリケーション実体に提供してよい。

本発明の第２の態様において、第１装置の動作および第２装置の動作に関連して、本発明の第１の態様に応じて動作する装置が提供される。本発明の第２の態様によれば、当該装置は無線通信端末であってよい。また一方で、当該装置は、無線通信端末ではなく、有線通信端末であってよい。さらにまた、当該装置は、クライアント／サーバモデルにおいてサーバとして機能することが可能であり、メッセージによって引き起こされる衝突を解消するための同期エンジンを含んでいてよい。

本発明の第３の態様において、本発明の第２の態様による第１装置を備え、当該第１装置は、クライアント／サーバモデルにおいてサーバとして機能し、メッセージによって引き起こされる衝突を解消するための同期エンジンを含んでいることを特徴とするシステムであって、さらに、本発明の第２の態様による第２装置を備え、当該第２装置は、クライアント／サーバモデルにおいてクライアントとして機能することを特徴とするシステムが提供される。

本発明の第４の態様において、電気通信装置（１１、１２）が第１装置および第２装置に関連して本発明の第１の態様に応じて動作するように、電気通信装置（１１、１２）のための動作命令を示すコンピュータプログラムが提供される。

本発明の第５の態様において、同期エージェントが第１同期エージェントおよび第２同期エージェントに関連して本発明の第１の態様に応じて動作するように、同期エージェントに対して動作命令を示すコンピュータプログラムが提供される。

このように、本発明は、フォルダ変更のためのデータ記憶部や、ユーザデータまたは装置管理のいずれか一方に関するアプリケーションにより使用され得るデータ記憶部の間で同期を取る方法を提供するために、ＳｙｎｃＭＬを拡張する。ここで、１台のデータ記憶部におけるフォルダの変更およびデータユニットの変更は、双方とも他のデータ記憶部に反映させることができる。

本発明は、ＳｙｎｃＭＬを解釈するために装置における各アプリケーションを符号化する必要性を無くすのではなく、単にサーバ上の装置の同期エージェントおよび同期エンジンを連動させるという利点を有する。その上、本発明では、各々の装置の同期エージェントにおいて、他の装置の対応するデータ記憶部に同期させるためのデータ記憶部を共有する種々のアプリケーションのデータユニットを解釈する方法に関するいかなる知識をも含んでいる必要性が回避される。

本発明の上記の目的および他の目的、特徴および効果は、添付図面（図１〜図４）に関連して提供されるような以下の詳細な説明を検討することにより明らかになるであろう。
図１は、本発明による、それぞれのデータ記憶部の間の同期を取るためにＳｙｎｃＭＬメッセージを交換するクライアントおよびサーバのブロック図およびフロー図である。
ここで図１を参照すると、クライアントデータ記憶部１１ｃとサーバ１２中の対応するサーバデータ記憶部１２ｃとの間の同期を取るクライアント１１が示されている（データ記憶部は、装置管理またはユーザデータ（例えば電子メール）の保持のために利用することができる）。一般的に、データ記憶部は、図４に図示されるような任意のディレクトリ構造により、データ記憶部は１つの（またはそれ以上）のシステムディレクトリ構造を含むことが可能であり、さらに、おそらくは、１つまたは２つ以上の内部ディレクトリ構造（すなわち、オペレーティングシステムに対向する１つ以上のアプリケーションによって維持される内部ディレクトリ構造）を保持することができるであろう。この結果、ディレクトリ構造はフォルダの木構造となり、各フォルダは、１つまたは２つ以上のデータユニット（ファイル、すなわちシステムディレクトリ構造において維持されるデータのユニット、または電子メールアプリケーションにより維持される電子メール等の内部ディレクトリにおけるアプリケーションによって維持されるデータのユニット）、および木構造の１つまたは２つ以上の他のフォルダを含むことができる。

同様の構造を有する言語または類似の言語によるメッセージも使用することができるけれども、同期はＳｙｎｃＭＬメッセージの交換を介して発生する。交換されたＳｙｎｃＭＬメッセージの中には、データユニットに関してデータ記憶部１１ｃ、１２ｃ間の同期を取るものもあり、データ構成に関して同期を取るものもある。換言すれば、結果として、双方のデータ記憶部はフォルダに関して等価構造を有し、少なくともアプリケーションが関係するものの範囲に関する限り、同期は実行されている。クライアント１１は、クライアント／サーバモデルにおいて、ＳｙｎｃＭＬプロトコルに従ってクライアントとしての役割を果たす任意の種類の装置であって、クライアント（通常、ラップトップ型または携帯電話またはその他の携帯端末）は、クライアント／サーバモデルにおいてサーバとしての役割を持つ装置（通常は、例えば、デスクトップコンピュータ）であるサーバ１２に対し、当該データ記憶部１１ｃ中のデータのすべての変更を送出する。（通常、装置自体のそれぞれのデータ記憶部の同期を取る２台の装置のうち、より高い演算能力を有する装置がサーバの役割を果たす。）

クライアント１１およびサーバ１２は、１つまたは２つ以上のそれぞれのアプリケーション実体を含み、さらに、（一般的な、すなわち、特定のアプリケーションに対して特殊化されない）それぞれの同期エージェント１１ｂ、１２ｂを含む。サーバアプリケーション実体１２ａは、上記のサーバ同期エージェントばかりでなくサーバ同期エンジン１２ｆに対してもインタフェースを可能にするという点で、クライアントアプリケーション実体１１ａとは異なっており、クライアント１１には上記のサーバアプリケーション実体に相当するものがない。同様に、サーバ同期エージェント１２ｃは、サーバ同期エンジン１２ｆに対してもインタフェースを行うという点で、クライアント同期エージェント１１ｃとは異なっている。クライアント／サーバアプリケーション実体１１ａ、１２ａは、例えば、ビジネスマンが予約を記録しておくために利用するカレンダーアプリケーションである。予約がクライアント装置上で処理されると、予約情報がクライアント記憶部１１ｃに新規ファイルとして記憶される。後に、クライアント１１からの要求またはサーバ１２からの指示があったときに、データ記憶部１２ｃは、新規データ（すなわち新規ファイル）に関して、クライアントデータ記憶部１１ｃと同期する。さらに、クライアントデータ記憶部１１ｃのディレクトリ構造に変更が加えられた場合、ここでは、ディレクトリ構造に関して、その後再び、クライアントデータ記憶部１１ｃおよびサーバデータ記憶部１２ｃ間の同期を取る必要がある（この場合、ディレクトリ構造に関して、すなわち、アプリケーションのデータを保持するためにどのフォルダを使用するかに関して）。また一方で、サーバデータ記憶部１２ｃに対して、アプリケーション１１ａ、１２ａのフォルダまたはデータユニットのいずれか一方に対する変更を含むような任意の変更を加えるときは、ＳｙｎｃＭＬメッセージの交換により、クライアントデータ記憶部１１ｃおよびサーバデータ記憶部１２ｃ間の同期を取る必要がある。

さらに図１を参照すると、ＳｙｎｃＭＬメッセージは、例えばｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（ハイパーテキスト・トランスポート・プロトコル：ＨＴＴＰ）、ｗｉｒｅｌｉｎｅ ｓｅｓｓｉｏｎ ｐｒｏｔｏｃｏｌ（ワイヤライン・セッション・プロトコル：ＷＳＰ）およびｏｂｊｅｃｔ ｅｘｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ（オブジェクト・エクスチェンジ・プロトコル：ＯＢＥＸ）を含む種々のトランスポート接続１４に従って通信することができる。（トランスポート接続は、無線接続または有線接続のいずれかを含むような任意の物理層接続を用いて提供してよい。）図に示すように、サーバ１２がＳｙｎｃＭＬメッセージをクライアント１１（あるいはその逆）に伝達するとき、サーバ同期エージェント１２ｂは、トランスポート接続１４を介してＳｙｎｃＭＬメッセージを順次クライアント１１に送出するサーバ同期アダプタ１２ｅに対してメッセージを送出するために、同期インタフェース（Ｉ／Ｆ）を使用する。クライアント同期アダプタ１１ｅは、受信端においてＳｙｎｃＭＬメッセージを受信し、このメッセージを順次クライアント同期エージェント１１ｂに送出するクライアント同期Ｉ／Ｆに対して、当該メッセージを送出する。

ここでは、（同一データユニットが各々の装置の同一または相当するフォルダに存在するようにし、かつ、対応する各々のデータユニットの内容も同一となるように）データユニットだけでなくフォルダの変更に関してデータ記憶部１１ｃ、１２ｃ間の同期を取ることとする。このために、本発明は、データユニットの変更に使用されるものと同一のコマンドであって、フォルダに変更を加えるコマンドを使用するＳｙｎｃＭＬを有している。これによって、演算要素（プロトコル命令要素）を搬送するメッセージを発行することによりフォルダに変更を加える。この演算要素としては、影響を受けるフォルダがここでいうデータ識別要素内で参照されるＳｙｎｃ、Ａｄｄ、ＲｅｐｌａｃｅおよびＤｅｌｅｔｅが挙げられ、上記データ識別要素は、データ要素の外部にあるターゲット要素またはソース要素のいずれかを意味する。データユニットに変更を加えるためには、従来技術によるＳｙｎｃＭＬでは、演算要素におけるデータ要素内のデータユニットを参照するメッセージを必要とする。本発明が、影響を受けるフォルダを参照するための他の考えられる構成より有利な点は、データ要素（すなわち、データ記述要素）の外部の影響を受けるフォルダの参照を利用するという点にある（すなわち、ＳｙｎｃＭＬが各アプリケーションによって解析することを可能にする符号を複製する必要がなく、それぞれ異なるアプリケーションのデータユニットを解釈するための符号を、各同期エージェント内に含む必要がない点）。

ここで、図２を参照すると、本発明によれば、データ記憶部１１ｃ、１２ｃを同期させる過程で影響を受けるフォルダ（および当該フォルダによるディレクトリに関するデータ構成）は、データ要素２８、２９（すなわちデータ記述要素の特定の型）の外部の（すなわち、データ要素２８、２９に含まれない）プロトコルコマンド要素２５（Ｒｅｐｌａｃｅ等）のソース要素２６およびターゲット要素２７のＬｏｃＵＲＩ中で識別されて表示される。ターゲットおよびソース要素は両者とも、ここでいう識別要素であって、データユニットを含むデータ要素２８、２９と対比される。一般的に、本発明によるデータ識別要素は、プロトコルコマンド要素２４に順次埋め込まれた非データ要素コンテナ（項目要素等）に埋め込まれる。プロトコルコマンド要素２４は、ＳｙｎｃＨｄｒコンテナ要素２２とともにＳｙｎｃＢｏｄｙコンテナ要素２３の一部として搬送され、両者はＳｙｎｃＭＬコンテナ要素すなわちＳｙｎｃＭＬメッセージ２１に含まれる。

データユニットおよびフォルダの双方に変更が加えられた場合は、まずフォルダの同期を取り、最初にフォルダに変更を加えた後にデータユニットに変更を加えるようにメッセージを定式化しなければならない。（データユニットまたはフォルダに対する）変更はそれぞれ、演算要素を介して実行される。フォルダに対する変更が、データユニットに対するいかなる変更よりも先になされるように構成しなければならない。

このように、本発明によれば、メッセージ中のフォルダの変更を送出したとき、例えばクライアントに新規フォルダを付加したときは、演算要素“ａｄｄ”のデータ要素（すなわち、データ記述要素の特定の型）は空白（empty ）の状態にされるか、または、このような演算要素（“ａｄｄ”）はメッセージ中に表示されず、フォルダ情報（フォルダＩＤまたはフルパス（full path ）名）は、すべてのデータ要素の外部にあるデータ識別要素（ソース要素またはターゲット要素）のＬｏｃＵＲＩ内で搬送される。

以下の〔表１〕のＳｙｃｎＭＬメッセージフラグメントは、Ｒｅｐｌａｃｅコマンド中で、識別子７を有するフォルダであって識別子１を有するフォルダ内に配置されたフォルダのアドレス指定を行う方法を示す。

（フォルダ自体とは異なる）フォルダ内のデータユニットのアドレス指定を行うと、フォルダの識別子およびディレクトリ構造のルートに関するフォルダのパス（木構造の場合）は、演算要素すなわちプロトコルコマンド要素（ＲｅｐｌａｃｅまたはＤｅｌｅｔｅ等）のターゲットおよびソース共通要素型のＬｏｃＵＲＩ内に転送される。下記の〔表２〕の例は、フォルダ７が識別子１を有するフォルダ内に配置されたとき、識別子７を有するフォルダにおける１２３の局所固有識別子（ｌｏｃａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ：ＬＵＩＤ）を有する項目のアドレス指定を行う方法を示す。

下記の〔表３〕は、本発明によるＳｙｎｃＭＬメッセージの一例を示し、このメッセージは、（クライアントまたはサーバのいずれかである）受信側端フォルダ情報を作成するために用いられる演算要素（コマンド）を含む。この例の中ではクリアテキスト（ｃｌｅａｒ ｔｅｘｔ：ＸＭＬ）が使用されている。無線環境においては、クリアテキストＸＭＬは使用されず、代わりにＷＢＸＭＬ（無線バイナリＸＭＬ）が使用されるであろう。

上記のＳｙｎｃＭＬメッセージのフラグメントは、「マイフォルダ（Ｍｙ ｆｏｌｄｅｒ）」という名称を得るために、．／１００／のＬｏｃＵＲＩを有するフォルダの名称を新たに付与する。

同期
本発明によれば、（双方向）同期は、例えば以下のように増補した仕様であるＳｙｎｃＭＬ同期プロトコルのバージョン１．１に記述されているように行うことができる。

前述の同期後にクライアントのフォルダへの修正が存在する場合は、同期要素内の演算要素（例えば、Ｒｅｐｌａｃｅ、ＡｄｄおよびＤｅｌｅｔｅ）に関する下記の要求事項を満たさなければならない。

第１に、フォルダ情報の送出は、メッセージオブジェクトの送出前に行わなければならない。換言すれば、フォルダ情報の送出は、メッセージオブジェクトに対する任意の修正を規定したコマンドを指定する前に、Ｒｅｐｌａｃｅコマンドを修正パッケージの中で指定しなければならない。

データ要素は、Ｉｔｅｍ（項目）の要素に対して指定してはならない。

動作が削除でない場合、Ｉｔｅｍの要素のメタ（ｍｅｔａ）要素内のＭａｒｋ（マーク）の要素は、フォルダに関する情報（例えば、フォルダの型）を伝達するために使用されなければならない。

動作が削除でない場合、Ｉｔｅｍの要素のソース（ｓｏｕｒｃｅ）要素内のＬｏｃＮａｍｅの要素は、表示可能なフォルダ名を指定しなければならない。

Ｉｔｅｍの要素のソース要素内のＬｏｃＮａｍｅの要素は、フォルダ識別子およびフォルダのパス全体を指定しなければならない。すなわち、すべての可能なサブフォルダ識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。フォルダ識別子はスラッシュ文字（‘／’）で区切らなければならない。

前述の同期後のクライアント中のメッセージオブジェクトに修正がある場合には、同期要素内の演算要素に関する下記の要求事項を満たさなければならない。

動作が削除でない場合、Ｉｔｅｍの要素のソース要素内のＬｏｃＮａｍｅの要素は、表示可能なメッセージ名を指定しなければならない。

動作が削除でない場合、Ｉｔｅｍの要素のメタ要素内のＭａｒｋの要素は、メッセージ（例えば、読み取り／非読み取り情報）の状況に関する情報を伝達するために使用されなければならない。

Ｉｔｅｍの要素のソース内のＬｏｃＵＲＩは、パス全体を含む項目の識別子を指定しなければならない。すなわち、すべての可能なフォルダおよびサブフォルダの識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。項目識別子（すなわち、ＬＵＩＤ）は常に、ＬｏｃＵＲＩの要素内の最終値として提示されなければならない。フォルダ識別子はスラッシュ（‘／’）で区切らなければならない。

下記の〔表４〕および〔表５〕に示すものは、修正をサーバに送出するクライアントの例である。

前述の同期後のサーバのフォルダ構造に修正がある場合には、同期要素内の演算要素に関する下記の要求事項を満たさなければならない。

フォルダ情報の送出は、全てのメッセージオブジェクトの送出前に行わなければならない。換言すれば、フォルダ情報の送出は、メッセージオブジェクトに対する修正を規定したコマンドを指定する前に、Ｒｅｐｌａｃｅコマンドを修正パッケージの中で指定しなければならない。

データ要素は、項目要素に対して指定してはならない。

動作が削除でない場合、Ｉｔｅｍの要素のメタ要素内のＭａｒｋの要素は、フォルダに関する情報（例えば、フォルダの型）を伝達するために使用されなければならない。

動作が削除でない場合、Ｉｔｅｍの要素のＴａｒｇｅｔ（ターゲット）内のＬｏｃＮａｍｅの要素は、表示可能なフォルダ名を指定しなければならない。

動作が追加である場合、ソース要素のＬｏｃＮａｍｅの要素は、表示可能なフォルダ名を指定しなければならない。

Ｉｔｅｍの要素のターゲット内のＬｏｃＵＲＩは、クライアント側フォルダ識別子およびフォルダのパス全体を指定しなければならない。すなわち、すべての可能なサブフォルダの識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。フォルダ識別子はスラッシュ文字（‘／’）で区切らなければならない。

動作が追加である場合、ソース要素のＬｏｃＵＲＩはサーバ側フォルダ識別子およびパスを指定しなければならない。ターゲット要素のＬｏｃＵＲＩはクライアントのフォルダパスを指定しなければならない。フォルダ識別子はターゲットＬｏｃＵＲＩ内で指定されてはならない。前述の同期後のサーバのメッセージオブジェクトに何らかの修正がある場合には、同期要素内の演算要素に関する以下の要求事項を満たさなければならない。

動作が追加である場合、Ｉｔｅｍの要素のソース要素内のＬｏｃＮａｍｅの要素は、表示可能なメッセージ名を指定しなければならない。Ｉｔｅｍの要素のソース要素内のＬｏｃＮａｍｅの要素は、パス全体を含む項目の識別子を指定しなければならない。すなわち、すべての可能なフォルダおよびサブフォルダの識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。項目識別子（すなわち、ＬＵＩＤ）は常に、ＬｏｃＵＲＩの要素内の最終値として提示されなければならない。フォルダ識別子はスラッシュ（‘／’）で区切らなければならない。ターゲット要素のＬｏｃＵＲＩはクライアントのフォルダパスを指定しなければならないが、項目識別子はＴａｒｇｅｔのＬｏｃＵＲＩ内で指定されてはならない。

動作が修正である場合、Ｉｔｅｍの要素のターゲット要素内のＬｏｃＮａｍｅの要素は、表示可能なメッセージ名を指定しなければならない。Ｉｔｅｍの要素のターゲット要素内のＬｏｃＮａｍｅの要素は、パス全体を含む項目識別子を指定しなければならない。すなわち、すべての可能なフォルダおよびサブフォルダの識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。項目識別子（すなわち、ＬＵＩＤ）は常に、ＬｏｃＵＲＩの要素内の最終値として提示されなければならない。フォルダ識別子はスラッシュ（‘／’）で区切らなければならない。

動作が削除である場合、Ｉｔｅｍの要素のソース要素内のＬｏｃＵＲＩは、クライアントのパス全体を含むクライアント側項目識別子を指定しなければならない。すなわち、すべての可能なフォルダおよびサブフォルダの識別子もまた、ＬｏｃＵＲＩの要素内で指定されなければならない。フォルダ識別子はスラッシュ（‘／’）で区切らなければならない。

動作が削除でない場合、Ｉｔｅｍの要素のメタ要素内のＭａｒｋの要素は、メッセージ（例えば、読み取り／非読み取り情報）の状況に関する情報を伝達するために使用されなければならない。

下記の〔表６〕および〔表７〕に示すものは、修正をクライアントに送出するサーバの例である。

コマンド識別子（ＩＤ）５を有する上記コマンドにおいて、サーバは、「マイオウンメッセージ（Ｍｙ Ｏｗｎ Ｍｅｓｓａｇｅｓ）」という名称のフォルダに関する．／４０４４／２２３／のｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（グローバリ・ユニーク・アイデンティファイア：ＧＵＩＤ）を使用する。ＳｙｎｃＭＬ同期プロトコル（基準）のバージョン１．１の５．３項の説明のように、クライアント同期エージェントは、フォルダに対しＬＵＩＤを割り当て、その後、（クライアントの）ＬＵＩＤが（サーバの）ＧＵＩＤとどのような関係を有しているかについて示すマップを、サーバに返送する（５．３．１項の例を参照のこと）。

いくつかのフォルダ処理
既に説明したように、フォルダは、同期セッションにおける単なる他のオブジェクトにすぎない。ユーザがクライアント装置（例えば、ラップトップまたは携帯電話）において新規フォルダを作成した場合を例にとると、結果として、クライアントは、次の同期セッションにおいて新規フォルダに関する情報を含むＲｅｐｌａｃｅコマンドを送出しなければならない。本発明によれば、このＲｅｐｌａｃｅコマンドの送出は、以下の〔表８〕のＳｙｎｃＭＬメッセージで行われる。

受信側がデータ要素を含まない動作（すなわち、ＲｅｐｌａｃｅまたはＡｄｄ）を受信した場合、この受信側は、上記動作はフォルダ処理の動作であると推定しなければならない。

フォルダの作成
フォルダの作成は、ＲｅｐｌａｃｅまたはＡｄｄコマンドを指定することにより行われる。以下の〔表９〕の例は、（識別子１０１１を有するクライアント側受信箱フォルダを有する）クライアントの受信箱における、フォルダ識別子７を有する新規フォルダを作成する方法である。

クライアントはサーバに対して、サーバがサーバフォルダの識別子をクライアントサーバの識別子に関連付ける方法を示すマッピング情報を返送しなければならない。さらに、サーバは、クライアントのフォルダ識別子を使用してフォルダを識別しなければならない。これによって、サーバから送られた演算要素のＩｔｅｍ内のターゲット要素は、常にクライアント側フォルダパスを含んでいなければならない。

サーバ上で新規フォルダが作成されてメッセージがフォルダに追加された場合、サーバは、サーバ修正パッケージ中の第１メッセージ中のフォルダ演算（すなわち、フォルダ情報を含むＡｄｄコマンド）を送出しなければならない。ただし、最終フラグは、メッセージ中で指定されてはならない。クライアントはサーバに対し、フォルダ識別子マッピング情報を返送することができなければならない。この結果、サーバは、実際のメッセージを含むＡｄｄ演算のＴａｒｇｅｔ内のクライアントフォルダ識別子を指定することができる。

フォルダ名の再付与
フォルダの表示名はＬｏｃＮａｍｅの要素内で転送されるため、フォルダ名の再付与のための特別な動作はない。したがって、表示可能なフォルダ名が変更されたときは、Ｒｅｐｌａｃｅコマンドを送出しなければならない。さらに、ＬｏｃＮａｍｅの要素はフォルダの新しい表示可能な名称を含んでいなければならない。

フォルダの移動
フォルダのパス全体はＬｏｃＵＲＩの要素内で転送されるため、フォルダ移動のための特別な動作はない。したがって、フォルダが他のフォルダに移動したときは、Ｒｅｐｌａｃｅコマンドを送出しなければならない。さらに、新規フォルダパスはＬｏｃＵＲＩに含まれなければならない。新規フォルダがサーバ上で作成されて既存のフォルダが新規フォルダ内に移動した場合、まず、サーバはクライアントに新規フォルダを追加し、フォルダ識別子のマッピング情報を受信した後、さらに、既存のフォルダを移動させなければならない。すなわち、サーバは、新規クライアント側フォルダパスを含むＲｅｐｌａｃｅコマンドを送出しなければならない。

アプリケーション要素、同期エレメントおよび同期エンジン間の協働関係
図１および図３に、データ構成（ディレクトリ構造）の変更に対応するためにクライアントおよびサーバアプリケーション１１ａ、１１ｂ、同期要素１１ｂ、１２ｂおよびサーバ同期エンジン１２が協働する可能な１つの方式を示すが、これらの方式は本発明の主題ではない。理解すべき重要なことは、本発明が、クライアント同期要素およびサーバ同期要素１１ｂ、１２ｂがデータ構成において変更せずに済むような情報を抽出するために、ＳｙｎｃＭＬメッセージをデータ要素レベルにまで解析する必要はないということを規定し、かつ、サーバおよびクライアントアプリケーション１１ａ、１１ｂが、データを追加したり交換したり削除したりすることができるようなそれぞれのデータ記憶部１１ｃ、１２ｃにアクセスするために、ディレクトリ構造について何も理解する必要はないということを規定していることである。

しかしながら、図１および図３を再度参照すると、２台のデータ記憶部１１ｃ、１２ｃの同期を取るための１つの構成では、第１のステップ３１ａにおいて、サーバ同期エージェント１２ｂは、クライアント同期エージェント１１ｂとのトランスポート接続を確立する（クライアント同期エージェントが行う逆の動作については、図３では触れていない）。次のステップ３１ｂにおいて、クライアントアプリケーション１１ａは、クライアントデータ記憶部１１ｃにおける最後の同期以後のクライアントデータ記憶部１１ｃの変更を決定し（同一のデータ記憶部を共有するアプリケーションは１個以上あり得るが、１個のアプリケーションしかないと仮定する）、クライアント同期エージェントはデータ記憶部１１ｃにおいて、同様の処理を実行する。さらに、次のステップ３１ｃにおいて、同期エージェントは、上記に説明したように、データエレメントの外部のデータ識別要素により、影響を受けるフォルダを引用するために、データ識別要素を用いて、コマンド（プロトコルコマンド要素）にフォルダの変更を設定する。次に、ステップ３１ｄにおいて、アプリケーションは、データ記述要素（データ、項目またはメタ要素）を用いて、コマンドにデータユニット変更を設定する。次に、ステップ３１ｅにおいて、同期エージェントはサーバ１２に対し、データ記述要素およびデータ識別要素（すべてのデータ要素の外部にある）によりメッセージ包含コマンドを送出する。

次に、サーバ１２で、次のステップ３１ｆにおいて、同期エージェント１２ｂは、すべてのデータ要素の外部にあるクライアントデータ識別要素により、任意のコマンドからフォルダ変更を抽出し、どのコマンドがクライアントデータ識別子を含んでいるかに基づいて、同期エンジン１２ｆに対し、最後の同期後にどのような変更がクライアントデータ記憶部に対してなされたかを表示する。次のステップ３１ｇにおいて、同期エンジンはフォルダの衝突を解消し、サーバ同期エージェント１２ｂに対してネットフォルダ変更を提供し、サーバ同期エージェント１２ｂは、サーバデータ記憶部１２ｃに対して対応するフォルダ変更を提供し、その後、サーバ同期エージェントは（サーバ）同期エンジンに対して（クライアントによる任意のデータユニット変更を伝達する）メッセージの残りの部分を提供する。

次のステップ３１ｈにおいて、同期エンジン１２ｆは、クライアントデータ記憶部１１ｃに対する変更がすべてサーバデータ記憶部１２ｃに対して加えられた場合に発生するような、サーバデータ記憶部によるいかなるデータユニットの衝突をも解消し、サーバアプリケーション１２ａに対して、ネットデータユニット変更を提供する。次のステップ３１ｉにおいて、サーバアプリケーションはサーバデータ記憶部１２ｃに対し、表示されたデータユニット変更を加え、適切なコマンドにおいて、クライアントデータ記憶部１１ｃに対してネットデータ変更を設定する。その後、次のステップ３１ｊにおいて、サーバ同期エージェントは、クライアントデータ記憶部１１ｃにおいてフォルダに加えられるべきネット変更を収集し、データ識別要素がメッセージ内のデータ要素の外部に設定された状態で、影響を受けるフォルダを表示するデータ識別要素を含むような対応するコマンドを付加する（その後、メッセージはクライアントに送出される）。

クライアント１１がサーバメッセージを受信すると、次のステップ３１ｋにおいて、クライアント同期エージェント１１ｂは、コマンドを解析することにより、コマンドに含まれるいかなるデータ要素をも含まずに、すべてのフォルダ変更を抽出する。これによって、クライアント同期エージェント１１ｂはクライントデータ記憶部１１ｃを変更し、アプリケーション１１ａに対してデータユニット変更のためのすべてのコマンドを提供する。最後にステップ３１ｍにおいて、アプリケーション１１ａは、クライアント同期エージェント１１ｂにより提供されたコマンドに従って、クライアントデータ記憶部１１ｃを変更する。

発明の範囲
これまで述べた構成は本発明の原理の実施例にすぎないことを理解されたい。本発明の範囲から逸脱することなく、非常に多くの変形および代替的な構成を当業者により考え出すことが可能である。また一方で、特許請求の範囲の従属形式の請求項は、このような変形および代替的な構成の範囲を含むように意図されたものである。

本発明による、それぞれのデータ記憶部の間の同期を取るためにＳｙｎｃＭＬメッセージを交換するクライアント（携帯電話等）およびサーバ（ネットワークサーバまたはパーソナルコンピュータ等）のブロック図およびフロー図である。 本発明によるＳｙｎｃＭＬメッセージの概略図である。 本発明に従って構成されたメッセージを使用して同期を取る際のクライアントおよびサーバの複数の構成要素間の協働関係の構成を示すフローチャートである。 （従来技術による）ディレクトリ構造の概略図である。

Claims (27)

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. 前記データ記憶部の前記データは、前記装置にホストされるアプリケーションにより装置管理のために使用される、請求項２２に記載の装置。

Images