JP5294867B2 - データ同期を実行する方法、システム、クライアントおよびサーバ - Google Patents

Description

本発明は、オープン・モバイル・アライアンス（Open Mobile Alliance、ＯＭＡ）によって規定された同期マークアップ言語（Synchronization Markup Language、ＳｙｎｃＭＬ）のデータ同期（data sync）の規格の分野に関し、特に、ＳｙｎｃＭＬプロトコルに基づいてデータ同期を実行する方法、システム、クライアントおよびサーバに関する。

複数のプラットホームおよびネットワーク間で個人の情報および企業のデータをデータ同期する標準規格を制定するために、ＯＭＡはＳｙｎｃＭＬデータ同期規格を提案している。ＳｙｎｃＭＬ開発の目的は、任意の端末装置を使用してどこでもいつでも任意のネットワークのデータにアクセスできるようにするために、端末ユーザ、装置開発事業者、基本コンポーネント開発事業者、データ提供事業者間の共同作業を可能にすることにある。代表的なシナリオは、移動装置／アプリケーションサーバとネットワークサーバとの間のデータ同期である。これに加えて、ＳｙｎｃＭＬは、２つのパソコン（ＰＣ）間のデータ同期など、ピア・ツー・ピアのデータ同期に使用することもできる。

図１は、ＳｙｎｃＭＬ規格に基づくデータ同期を示す概略図である。データ同期の開始フェーズにおいてパラメータを取り決め（negotiate）た後、クライアントおよびサーバは、両者間でデータが同期していることを保証するために、変更のあったデータを相互に送信し合う。

データ同期クライアント（Data Synchronization Client、ＤＳクライアント）とは、一般に、ＰＣソフトウェア、移動電話機または携帯情報端末（Personal Digital Assistant、ＰＤＡ）など、インテリジェントな端末のことである。住所録、カレンダー、メモ帳、ショートメッセージ、電子メールなど、ユーザデータを格納するために、装置中にクライアントデータベースが構成される。これら全てのデータの形式は標準規格で規定されており、ＤＳクライアントは、データを標準形式に変換し、変換されたデータを、データを処理してデータベース中に格納するＤＳサーバに送信することができる。

ＤＳサーバは同期コマンドを含む同期メッセージをＤＳクライアントから受信してもよく、また同期メッセージをＤＳクライアントに返信してもよい。ＤＳサーバはネットワークサーバまたはＰＣであってもよい。ＤＳサーバのデータを格納するために、ＤＳサーバ中にサーバデータベースが構成される。

データ識別子がＤＳクライアントおよびＤＳサーバの両方に格納される。ＤＳクライアントはローカルな一意性識別子（Local Unique Identifier、ＬＵＩＤ）をデータ識別子として使用し、一方、ＤＳサーバはグローバルな一意性識別子（Global Unique Identifier、ＧＵＩＤ）をデータ識別子として使用する。

図２は、ＤＳクライアントおよびＤＳサーバのデータ蓄積装置を示す概略図である。図２に示すように、ＤＳクライアントにおいては種々のＬＵＩＤとデータとの間の対応関係のみを保持すればよいが、ＤＳサーバにおいては、種々のＧＵＩＤとデータとの間の対応関係のみならず、種々のＧＵＩＤとＬＵＩＤとの間の対応関係をも保持する必要がある。表１に示すように、複数のデータ同期のタイプが存在する。

さらに、ＳｙｎｃＭＬ規格に規定されたデータ同期手順は、通常、３つのフェーズを含む。
１．同期開始フェーズであり、このフェーズでは、認証、同期対象である同期データベースの折衝、同期ケーパビリティ（どのデータ形式および同期タイプをクライアントおよび／またはサーバがサポートするかを含む）の折衝が主であり、またそのような折衝の手順が複数回実行されねばならない場合もある。
２．同期フェーズであり、主に、ＤＳクライアントおよびＤＳサーバのうちの一方が他の一方へ、データ状態の変更に従う操作コマンドを介して変更のあったデータを送信すること、および他の一方が、そのデータを用いてデータ同期の目的を果たすべくそれ自身のデータを更新するために、操作コマンド（例えば、更新、削除、または追加の操作コマンド）を実行することを含む。
３．同期完成フェーズであり、主に、ＤＳクライアントおよびＤＳサーバが、同期の完成を相互に確認することを含む。

従来技術では、フォルダおよびファイルの蓄積のやり方はデータについて定義されており、それはＰＣにおけるフォルダおよびファイルに基づく木構造をシミュレートする。論理的または物理的に階層関係を有するデータについては、そのデータは少なくとも１つのノードを含む木構造で表現することができ、その各ノードはフォルダノード（フォルダ項目とも言う）または項目ノード（データ項目とも言う）であってよい。しかし、従来技術では、内容またはサブ木（sub-tree）を有する特定ノードを要求に従って同期化することはできない。さらに、グループ別の住所録を同期化する方法はｖＣａｒｄ中のグループフィールドを基にフィルタ技術を使用して実行されるが、その欠点は、同期プロトコルが、全データ形式に一般的でない特定のデータ形式と緊密に結びついていることであり、そのため内容または木構造中のサブ木を有する特定ノードは要求通りに同期化されない場合がある。

しかしながら、今日では、論理的または物理的に階層関係を有する実際の木構造として蓄積された、同期を必要とする大量のデータが存在する。例えば、住所録、カテゴリ分けされたショートメッセージおよびメールボックスで構成された電子メールなど、フォルダによって木構造状に構成され、ユーザの携帯電話機中に論理的または物理的に存在するデータもある。さらに、カレンダーまたは添付ファイル付き電子メールも、階層的なやり方で構成されると考えられよう。従来技術に従えば、ユーザは、データベースの一部ではなく、データベース全体を同期化できるのみである。ショートメッセージを例にとると、ユーザはショートメッセージのデータベース全体を同期化できるのみであり、ショートメッセージの“bless”という名の１カテゴリだけを同期して、“joke”という名の別カテゴリを今回は同期しないでおくことはできない。カレンダー／電子メールの外部に格納される添付文書については、それら添付文書を同期化することはできず、添付文書とカレンダーまたは電子メールとの階層関係は従来技術では記述できない。それと同時に、１つのデータ項目が２つのカテゴリ中に存在することを実現することはできない。例えば、Zhang Sanは、住所録において同時に、「大学グループ」および「友人グループ」のグループに属するのにである。

まとめると、既存のデータ同期技術は現実の要求を満足させることができず、特に、１つのデータ項目を階層的に考えることまたは階層構造中の任意のノードレベルのデータ同期をサポートすることができない。

本発明の一実施形態は、複数の装置を同期化する方法を開示し、本方法は、第２装置の複数の情報ノードからなる情報ノードの拡張アドレスを第１装置によって取得するステップと、情報ノードの同期を可能にするべく、木構造中の情報ノードを見つけるために拡張アドレスを使用するステップと、を有し、複数の情報ノードは、階層的木構造状に配置され、拡張アドレスは、情報ノードの階層的位置を含むことを特徴とする。

また、本発明の一実施形態は、複数の装置を同期化するシステムを開示し、本システムは、第２装置との通信を行う機能を有した第１装置を具備し、第２装置は、階層的木構造中に複数の情報ノードを格納し、第１装置は、第２装置の複数のノードからなるノードの拡張アドレスを取得し、拡張アドレスは、情報ノードの階層的位置を用いて拡張され、拡張アドレスは、前記情報ノードの同期を可能とするべく、木構造中で特定の情報ノードを見つけるために使用することができることを特徴とする。

本発明の一実施形態は、複数の装置を同期化する別の方法を開示し、本方法は、第２装置によって第１装置から同期コマンドを受信するステップと、第２装置によって第２装置における階層的木構造中に格納された情報ノードを同期化するステップと、を有し、情報ノードを同期化するステップは、同期コマンドに応答して実行され、要求は、階層的木構造中の情報ノードの位置を表す拡張アドレスを含むことを特徴とする。

以上により、本発明の実施形態は、データ同期を効率的に実行すること、およびシステムリソースを節約すること、さらには実際のユーザの要求を満たすことができるよう、データ同期中にクライアントおよびサーバ間でデータベース全体のデータを送信することなく、あるレベルについてのデータ同期を柔軟に実行するために採用される。

添付の図面および特定の実施形態を参照して、以下に本発明を詳細に説明する。

本発明の実施形態はデータ同期を実行する方法を開示するが、その方法では、クライアントおよびサーバのうちの一方が他の一方に第１同期コマンドを送信する。第１同期コマンドを送信する前に、クライアントおよびサーバは同期対象ノードのアドレスを決定する。第１同期コマンドの受信後、第１同期コマンドの受信側は、受信した第１同期コマンドに従って、決定した同期対象ノードのデータ同期を実行する。同期対象ノードは階層木構造中の任意のノード、例えば、データベース全体、論理的または物理的フォルダ、またはデータ項目、であってよい。

ＳｙｎｃＭＬプロトコルによれば、データ同期は３つのフェーズに分けることができ、同期開始フェーズ、同期フェーズおよび同期完成フェーズを含む。本発明の実施形態における同期完成フェーズのプロセスは従来技術におけるものと同じであり、したがって、同期開始フェーズおよび同期フェーズのみをこれから説明する。

同期開始フェーズでは、第２同期コマンドの送信によるクライアントとサーバとの折衝により、同期対象ノードのアドレスが指定されることになっており、それはデータベースアドレス、論理的または物理的フォルダ識別子、またはデータ項目識別子であってよい。クライアントおよびサーバのうちの一方が同期対象ノードのアドレスを伝える第２同期コマンドを他の一方へ送信すると、それは第２同期コマンドで伝えられる同期対象ノードのアドレスに従ってその時の同期対象であるノードを決定する。同期対象ノードは１つ以上のノードを含んでもよい。同期対象ノードが２つ以上のノードを含む場合、クライアントおよびサーバのうちの一方が、全てのノードに関する第２同期コマンド、これは全てのノードのアドレスを伝える、を他の一方へ送信すると、他の一方は第２同期コマンドで伝えられる全てのノードのアドレスに従って、その時同期対象となるノードに含まれる全てのノードを決定する。クライアントおよびサーバのうちの一方が、各々のノードに関して１つの第２同期コマンド、これはそのノードのアドレスを伝える、を他の一方へ送信すると、他の一方は各々の第２同期コマンドで伝えられる各々のノードアドレスに従って、その時の同期対象となるノードに含まれる全てのノードを１つずつ決定する。あるいは、同期開始フェーズにおいて第２同期コマンドを介して同期対象ノードを取り決める必要がないよう、同期対象ノードのアドレスがクライアントおよびサーバ中に事前に構成されてもよい。本発明の実施形態で述べられる同期対象ノードは、データベース、フォルダ、データ項目、または少なくとも１つのフォルダおよび少なくとも１つの項目からなる組合せを含んでもよい。本発明の実施形態の原理を明らかにするため、少なくとも１つのフォルダを含む同期対象ノードに関する本発明の実施形態の実行についてこれから説明する。同期対象ノードのその他の考え得る組み合わせについては明記しないが、しかし、それでもそれは本発明の保護範囲に含まれる。

以下に示すように、具体的には、同期対象ノードのアドレスを第２同期コマンドで伝えるステップを実現する２種類のやり方がある（少なくとも１つのフォルダを含む同期対象ノードの場合、同期対象ノードのアドレスは同期対象フォルダのアドレスである）。

やり方１：既存プロトコルにおいてターゲット（target）データベースを指示する要素（同期対象データのアドレスを伝える要素とも呼ばれる）が、同期対象フォルダ（実際には、木構造中の任意のノードを指示できる）を指示できるように拡張される。元来はデータベースレベルのアドレスを指示する要素であるものが、任意のレベルのノードアドレスを指示できる要素に拡張される。詳細な実行プロセスは、統一資源識別子（ＵＲＩ、Uniform Resource Identifier）の形式を事前に定義するステップ、すなわち、データベースレベルのアドレスを識別するレベルのＵＲＩおよびノードレベルのアドレスを識別するレベルのＵＲＩを事前に指定するステップ、および事前に定義されたＵＲＩによって同期対象ノードを指示するステップ、を含んでもよい。例えば、“/files”というＵＲＩはデータベースレベルのアドレスであり、“/files/folder1 ID”というＵＲＩはデータベース中のfolder1という名前のフォルダのアドレスであって、ここで、“files”はデータベースの名前であり、そして“folder1 ID”はフォルダ識別子である、と指定するステップである。データベースまたはフォルダまたはデータ項目の一意性識別子（Unique Identifier、ＵＩＤ）は、同期対象ノードのアドレスをより正確に指定するために、ＵＲＩ中で使用することができる。例えば、“/4980”は同期対象データベースのアドレスであると指定され、“/4980/4560”は、ＵＩＤ4980によって識別される第4980データベース中の、ＵＩＤ4560で識別されるサブフォルダのアドレスであると指定される。データベース中にさらに多くのレベルが存在する場合、“/4560/4980/556”など、多重レベル構造を有するＵＲＩが採用される。“/files/4980”など、ＵＤＩ番号をフォルダ名と混成したものを使用するＵＲＩ指示法が採用されてもよい。複数の同期対象フォルダが存在する場合、これらのフォルダを指示するために複数のＵＲＩが与えられてよいことは勿論である。さらに、階層構造では、１つのフォルダノードは少なくとも１つのサブフォルダおよび／または少なくとも１つのデータ項目ノードを有してもよく、それゆえ、同期対象ノードのアドレスはフォルダ識別子およびデータ項目識別子を含んでもよい。例えば、ノードアドレス“/Macy/03/05”では、“03”はデータベース“Macy”に属するデータ項目の識別子であり、“05”は親ノードであるデータ項目“03”のサブ項目（例えば、添付文書）の識別子である。

やり方２：既存プロトコルにおいてフィルタ条件を指示する要素が同期対象フォルダ（実際には、木構造中の任意のノードを指示できる）を指示するように拡張される。具体的な実装は、既存のフィルタ条件（例えば、フィルタコマンド）を、同期対象フィルタを指示するように拡張することを含む。同期対象フォルダが１つ以上存在する場合、これらのフォルダを同時にフィルタ条件に指示できるのは勿論である。

同期対象フォルダを指示するためのこれらの２つのやり方をこれから詳細に説明する。

Ｉ．やり方１は、既存プロトコルにおけるターゲットデータベースを指示する要素の拡張により、同期対象フォルダの取り決めを行う方式であって、ターゲットデータベースを指示する要素で伝えられる同期対象フォルダのアドレスは、通常、ＵＲＩと呼ばれる。

本発明の実施形態では、第２同期コマンドを送信することによって同期対象フォルダを取り決める一方、クライアントおよびサーバは同期タイプ折衝パラメータ（sync type negotiation parameter）をさらに取り決めてもよい。クライアントおよびサーバが第２同期コマンドの送信によって同期対象フォルダを取り決める時、同期タイプ折衝パラメータを第２同期コマンドでさらに伝えることができ、それに従ってその時の同期タイプを決定できる。第２同期コマンドは、同期マークアップ言語（ＳｙｎｃＭＬ）プロトコルにおけるAlert（警告）要素を使用して実行することができ、ここで、同期対象フォルダのアドレスを伝える要素はAlert要素のサブ要素（例えば、Item（項目）要素）であってもよく、そして同期タイプ折衝パラメータを伝える要素がAlert要素のサブ要素（例えば、Item要素）であってもよい。Alert要素を使用して実行される第２同期コマンドは、Sync Alert（同期警告）コマンドと呼ぶこともできる。第２同期コマンドとして機能するAlert要素中のその他のサブ要素、Code（コード）要素など、は、同期タイプ折衝パラメータおよび同期対象フォルダのアドレスを伝えるためにも使用でき、そしてAlert要素の属性もまた同期タイプ折衝パラメータおよび同期対象フォルダのアドレスを伝えるために使用できる。これらのケースにおけるコマンド構造を本明細書に逐一示すことはしないが、それらは本発明の保護範囲に含まれるものとする。そして、将来の仕様においては、これらの要素、サブ要素または属性の名前および構造は変化する場合もあろうが、これらの変化が本発明を限定するものとはみなすことはできない。

Alertコマンドを１つ以上の同期対象フォルダの指定に使用できるようさらに拡張して、複数フォルダの同期を実行するようにしてもよい。その機能を実装する方式を以下に示す。

同期開始フェーズでは、同期対象フォルダの折衝はクライアントによりサーバに対して開始されるものとして、折衝のプロセスは以下のようになる。

クライアントは同期対象フォルダのアドレスを伝えるAlertコマンドをサーバに送信するが、そのアドレスは同期対象フォルダのＵＲＩであってもよい。次いで、サーバはクライアントに応答を返してもよい。Alertコマンドの例をこれから示す。例えば、クライアントが指定する同期対象フォルダはfolder1と名付けられている。クライアントは、同期タイプおよび同期対象フォルダのアドレス（例えば、ＵＲＩ）を伝えるAlertコマンドをサーバに送信する。クライアントのフォルダ構造がサーバのものと同じである場合（同期対象ノードが少なくとも１つのフォルダを含むだけで、フォルダ構造がデータ階層構造に言及する場合）、クライアントは、それのローカルフォルダ構造に従って、同期対象フォルダのローカルアドレスがサーバにおける同期対象フォルダのアドレスであると直ちに決定する。クライアントのフォルダ構造がサーバのものと異なる場合、クライアントはサーバにおける同期対象フォルダのアドレスを決定する必要がある場合もあり、この場合、以下のように幾つかの決定方法が存在する。すなわち、１．クライアントはまずサーバからサーバのフォルダ構造を取得し、そして取得したフォルダ構造に従ってサーバ中の同期対象フォルダのアドレスを決定する。２．サーバが同期対象フォルダのアドレス（例えば、ＵＩＤまたはＵＲＩ）をクライアントに送信する。３．クライアントが同期対象フォルダのアドレスを直接に指定し、指定されたアドレスがサーバにおいて存在しない場合、サーバはクライアントが指定したアドレスに同期対象フォルダを作成する。４．クライアントは、ユーザが入力した情報に従って同期対象フォルダのアドレスを決定する。すなわち、ユーザが同期対象フォルダのアドレスを決定する。５．クライアントおよびサーバが同期対象フォルダのアドレスを前もって設定する。たとえクライアントのフォルダ構造がサーバのフォルダ構造と同一である場合でもまた、クライアントは、上記の方法を使用して同期対象フォルダ決定する。例えば、クライアントおよびサーバの両者は、バックアップ（backup）同期の実行が予定される場合、サーバのデータベース中に“backup”という名前のフォルダを準備するものとする。上記のフォルダ構造は作成後にサーバ中に格納されてもよく、またはサーバ中に格納されず、クライアントが要求した場合にサーバが指定したデータベースに実時間で作成される。同期手順を開始するためにサーバがAlertコマンドを送信する場合、同期対象フォルダのアドレスは、クライアント中の同期対象フォルダのアドレス（すなわち、送信元アドレス）およびサーバ中のそれ（すなわち、宛先アドレス）を含んでもよい。２つのアドレスは同じでもよく異なってもよい。同期発信元のクライアントについては、同期対象フォルダのローカルアドレス（すなわち、送信元アドレス）は、例えば、送信元アドレスを予め構成する、またはユーザが送信元アドレスを指定する、または送信元アドレスをユーザがクライアントに送信するなど、複数の手段で取得できる。しかしながら、サーバ中の同期対象フォルダのアドレス（すなわち、宛先アドレス）は、同期手順の開始時にクライアントがサーバに指示しなければならない。ここで説明するのは、同期発信元として機能するクライアントがサーバに宛先アドレスを指示する方法であり、クライアントが送信元アドレスを決定する方法はここでは論じない。

クライアントによるサーバのフォルダ構造の取得は、独立した同期セッションによって実行することができ、その場合は、同期タイプ折衝パラメータを伝えるAlertコマンドにおいて新しいサブ要素または属性が拡張または定義されるものとし、そしてデータベースのフォルダ構造を取得するためのみの、データベースの同期は目的としない、新しい同期タイプも定義されるものとする。データベースのフォルダ構造および同期データを取得するための別の同期タイプが定義されてもよい。フォルダ構造を取得するための実行方式をこれから示す。

１．クライアントは同期セッションを引き起こすコマンドをサーバへ送信する。同期対象フォルダのアドレスを決定するAlertコマンドを送信する前に、クライアントはターゲットデータベースのフォルダ構造を取得するための同期コマンドをサーバに送信する。ターゲットデータベースのフォルダ構造を取得するこの同期コマンドを上述の２つの同期コマンドと区別するため、その同期コマンドを第３同期コマンドと呼ぶものとする。第３同期コマンドは、例えば、以下の例で示されるGetコマンドの例のようなGet（取得)要素を使用して実行できる。既存のGetコマンドは、装置性能情報を取得するために使用されるのみであり、そのため、データベースのフォルダ構造の取得を要求するために、既存のGetコマンドの定義を拡張するものとし、データベースのフォルダ構造の取得の要求を指示する識別子が定義に追加される。
<Get>

......

<Target><LocURI>/contacts?List=struct</LocURI></Target>......

</Get>

上記のGetコマンドの例に示されるTarget要素では、“/contacts”はターゲットデータベースのＵＲＩを指し、“?List=struct”はデータベースのフォルダ構造を取得する要求を指示する識別子を指す。そしてGetコマンドの受信後、サーバはターゲットデータベースのＵＲＩに対応するデータベースを見つける。

２．サーバは、Getコマンドへの応答、例えば、Results（結果）コマンド、によりターゲットデータベースのフォルダ構造をクライアントへ返す。サーバのデータベースのフォルダ構造は次のようであるとする。すなわち、“/contacts”のルートフォルダ（すなわち、第１レベルのフォルダノード）の配下に、４つのサブノードＡ、Ｂ、ＣおよびＤが存在し、それらは第２レベルのフォルダと呼ばれる。そして、Ａ１およびＡ２というサブノードが第２レベルのフォルダノードＡの配下にあり、その２つのサブノードは第３レベルのフォルダノードと呼ばれる。ここで、返されたResultsコマンドは以下の幾つかのやり方で構成できる。

（１）１つのItem要素が、フォルダ構造中の１つのノードのＵＲＩを指示するために使用される。Resultsコマンドの受信後、クライアントは、各Item要素で指示されるＵＲＩに従ってサーバのフォルダ構造を構築する。Resultsコマンドの形式は以下のとおりである。
<Results> ......

<Item> ......

<Source><LocURI>/A</LocURI></Source>.....

</Item>

<Item>.....

<Source><LocURI>/A/A1</LocURI></Source>......

</Item>

</Results>

（２）全てのフォルダ構造データは、１つの要素にカプセル化される。例えば、フォルダ構造データは、Item要素中のData要素中にカプセル化することができ、そのItem要素はResults要素のサブ要素であり、Data要素中にカプセル化されたフォルダ構造データはファイルとして存在してもよい。この場合、Resultsコマンドの形式は以下のようになる。
<Results> ......

<Item> ......

<Data>フォルダ構造データ</Data>

</Item>

</Results>

別のサブ要素または属性もまた、フォルダ構造を取得する要求を指示するために、第３同期コマンドとして機能するGet要素中で使用されてよい。これらのケースでのGet要素およびResults要素のコマンド構造を逐一示すことはしないが、どの種類のGet要素およびResults要素が一緒に使用されるかに関係なく、それらもまた本発明の保護の範囲に含まれるものとする。同様に、Add（追加）コマンドまたはReplace（置換）コマンドもまた、階層構造データを伝えるように拡張されてよく、その拡張のやり方はResultsコマンドのそれと同じであり、そしてこれも本発明の保護範囲に含まれるものとする。

あるいは、クライアントは、サーバが主導権をもってクライアントへ同期対象フォルダのアドレスを送信することにより、同期対象フォルダのアドレスを決定してもよい。サーバによる同期対象フォルダのアドレスの送信は、クライアントへの通知（notification）の送信により実行されてもよい。通知の形式はデータ同期プロトコルにおける通知形式であってもよく、またはその通知はサーバによって別のエンジン、例えば、ショートメッセージサービス（Short Messaging Service、ＳＭＳ）、ワイヤレス・アプリケーション・プロトコル・プッシュ（Wireless Application Protocol Push、ＷＡＰ Ｐｕｓｈ）サービス、セッション開始プロトコル（Session Initiating Protocol、ＳＩＰ）メッセージ、マルチメディアメッセージサービス（Multimedia Message Service、ＭＭＳ）など、を介して送信してもよい。クライアントは任意の種類の同期対象階層構造のＵＲＩを取得してよい。

同期対象フォルダのアドレスを決定すると、クライアントは、決定した送信元および同期対象のターゲットアドレスを伝えるAlertコマンドをさらに送信してもよく、同期対象フォルダのアドレスおよび同期タイプ折衝パラメータはItem要素中で伝えることもでき、Alertコマンドの形式は以下のようになる。すなわち、
<Alert>

<Sync type>Two-way sync</Sync type>

<Item>

<Target><LocURI>/files/folder1(サーバ中のfolder1という名前の同期対象フォルダのＵＲＩ)</LocURI></Target>

<Source><LocURI>/files/folder1(クライアント中のfolder1という名前の同期対象フォルダのＵＲＩ)</LocURI></Source> ......

</Item> ......

</Alert>

複数の同期対象フォルダが存在する場合、１つの同期タイプおよび複数のItem要素をAlertコマンドで伝えることができ、そして各Item要素は１つのフォルダのアドレスを伝えるために使用され、ここで、複数の同期対象フォルダの同期タイプは同一である。

クライアントが送信したAlertコマンドの受信後、サーバはクライアントへ同期対象フォルダの折衝結果を伝える応答を返し、そこで、クライアントは、サーバに同期データを送信することにより続行するかまたは取り決めをし直すかを決定してよい。応答は、既存プロトコルにおける状態コードを返送する同期コマンド、例えば、Statusコマンド、であってもよい。

複数の同期対象フォルダが存在する場合、サーバがクライアントへ応答を返すやり方は次のものを含む。すなわち、全ての同期対象フォルダについて、サーバは全てのフォルダについての折衝結果を伝える１つの応答を返す、またはサーバは各フォルダについてそのフォルダの折衝結果を伝える１つの応答を返し、ここで、これらのフォルダの折衝結果を返すために複数のStatusコマンドを複数のフォルダそれぞれについて使用でしてよい（折衝の結果は状態コードと呼ばれる場合もある）。

異なるフォルダについて異なる同期タイプを採るためには、以下の方式を使用できる。

１．複数の同期対象フォルダについて、クライアントはサーバへ全てのフォルダのアドレスおよび各フォルダに対応する同期タイプ折衝パラメータを伝えるAlertコマンドを送信する。サーバは、Alertコマンドで伝えられる全てのフォルダのアドレスに従って全ての同期対象フォルダを決定し、そしてフォルダそれぞれに対応する同期タイプを決定する。ここで、Alertコマンドは、元来は同期対象の宛先データベースのアドレスを伝えるために使用され、ノードレベルアドレスおよび同期タイプを指示できるように拡張された、複数の要素（例えば、Item要素）を伝え、そして１つの同期対象フォルダ（実際には、木構造中の任意のノードを指示できる）のアドレスおよび１つのフォルダの同期タイプを担うために使用される。

２．各同期対象フォルダについて、クライアントは１つのフォルダのアドレスおよびその１つのフォルダの同期タイプ折衝パラメータを伝えるAlertコマンドをサーバに送信する。サーバは、各々のAlertコマンド中のフォルダのフォルダアドレスおよび同期タイプ折衝パラメータに従って、各々の同期対象フォルダおよび同期タイプを決定する。ここで、Alertコマンドは、元来は同期対象宛先データベースのアドレスを伝えるために使用される１つの要素、およびノードレベルアドレスを指示できるよう拡張された、元来は同期タイプを伝えるために使用される、１つの要素を伝え、そして同期対象フォルダ（実際には、木構造中の任意のノードを指示できる）のアドレスを担うために使用される。元来は同期タイプを伝えるために使用されるその１つの要素は同期タイプ折衝パラメータを担うために使用される。

しかしながら、複数の同期対象フォルダが存在してその複数のフォルダの同期タイプが同じである場合、全ての同期対象フォルダについて、クライアントはサーバへ全てのフォルダのアドレスおよびこれらのフォルダの同期タイプ折衝パラメータを伝える１つのAlertコマンドを送信する。サーバはAlertコマンド中の全てのフォルダのアドレスおよび折衝パラメータに従って、全ての同期対象フォルダの同期タイプを決定する。ここで、そのAlertコマンドは、元来は同期対象宛先データベースのアドレスを伝えるために使用される複数の要素（例えば、Item要素）および元来は同期タイプを伝えるために使用される１つの要素（例えば、Data要素）を伝え、ここで、元来は同期対象宛先データベースのアドレスを伝えるために使用される各要素はノードレベルアドレスを指示することができる１つの要素に拡張され、同期対象フォルダのアドレスを担うために使用される。元来は同期タイプを伝えるために使用されるその要素は、１つの同期タイプ折衝パラメータを担う。第２同期コマンドとして動作するAlert要素はまた、同期タイプ折衝パラメータ、同期対象フォルダのアドレスなどを伝えるために別のサブ要素または属性を使用してもよい。これらの場合におけるコマンド構造を逐一示すことはしないが、それらは本発明の保護範囲に含まれるものとする。

II．やり方２は、同期対象フォルダのアドレスをフィルタリングメカニズムを使用して決定するやり方である。

既存のフィルタリングメカニズムは、ファイルレベルおよび項目レベルのフィルタリングのみを実行でき、これは同期対象データの形式に主に依存する。そして、本発明の一実施形態では、既存のフィルタリングメカニズムはノードレベル（ここで、ノードレベルはフォルダレベルを指す）へ拡張され、それは同期対象データの形式によって制限されず、全ての種類のデータ形式に使用できる。例えば、フォルダレベルのフィルタリング条件を伝えるサブ要素をＳｙｎｃＭＬプロトコルにおける既存のFilter要素に挿入することにより、その要素はFolderLebelと名付けることができ、ここで、同期対象フォルダを指示するためにＣＧＩ（Common Gateway Interface）構文を使用できる。Filter要素の属性または新たに追加されたサブ要素はまた、フォルダレベルのフィルタリング条件を伝えるために使用してもよく、この場合のコマンド構造をこの後示すことはしないが、これは本発明の保護範囲に含まれるものとする。

Filterコマンドの形式は以下のように与えられ、それぞれ１１２および１１３と番号を付された２つの同期対象フォルダを伝える。
<Filter> ......

<NodeLevel>

<Item>

<Meta><Type>syncml:filtertype-cgi</Type></Meta>

<Data>&LUID &EQ; 112 &AND; &LUID &EQ; 113 (１１２および１１３を含む同期対象フォルダの番号を指示するために、Filter要素のＣＧＩ構文を使用) </Data>

</Item>

</NodeLevel> ......

</Filter>

同期フェーズでは、どのやり方に基づく同期の操作タイプも、第１同期コマンドの送信によって指示され、それは同期対象フォルダのアドレスをさらに指示してもよく、またはデータ内容をさらに伝えてもよい。

同期対象フォルダのアドレスを第１同期コマンドで伝える場合、同期対象データのアドレスを既存のSync（同期化）コマンドで伝えるために使用される要素を、同期の粒度（granularity）をデータベースレベルから任意のノードのレベルへ拡張するよう、拡張することができる（例えば、Target要素）。例えば、ノードレベルのアドレスを指示できるTarget要素をSyncコマンドで伝えることができる。既存のSyncコマンドは、同期対象データベースのアドレスを指示できるのみのTarget要素を伝えるのみである。しかしながら、本発明の実施形態によるSyncコマンドは、任意のノードレベルのアドレスを指示することができ、データベース全体の全てのデータではなく、指示されたアドレスの範囲に属するデータを伝えることができる。

上記の解決法では、１つのSyncコマンドは１つの同期対象フォルダのアドレスを伝えることができ、複数の同期対象フォルダが存在する場合、それら複数のフォルダのアドレスは、複数のSyncコマンドでそれぞれ、又は１つのSyncコマンドでも伝えることができる。例えば、２つの同期対象フォルダ、それぞれfolder1およびfolder2と名付けられる、のアドレスは２つのSyncコマンドでそれぞれ伝えることができる。第１同期コマンドとして動作する上記のSync要素では、別のサブ要素または属性が同期対象フォルダのアドレスを伝えるために使用されてもよく、またこれらの場合のコマンド構造を逐一示すことはしないが、しかしそれらは本発明の保護範囲に含まれるものとする。

第１同期コマンド（例えば、Syncコマンド）が操作タイプを伝える時、操作タイプを伝える具体的なやり方は従来技術のものと同じであり、操作タイプを伝えるためにAdd(追加)、Replace（置換）、Delete(削除)、Move（移動）などの要素を使用することになる。例えば、サブ要素をSync（同期化）コマンドで伝えることができ、そのサブ要素は追加操作を指示するAdd要素、または置換操作を指示するReplace要素、または削除操作を指示するDelete要素、または移動操作を指示するMove要素などであってもよい。このようにして、第１同期コマンドを受信する受信側は、第１同期コマンドが伝える操作タイプに従って、操作タイプによって指定された同期操作を同期対象フォルダについて実行できる。その結果、実際の状況に従って、Add要素、Replace要素、Delete要素、またはMove要素を選択でき、そしてその選択された要素を種々の操作タイプを指定するSyncコマンドで伝えることができる。

本発明の実施形態である、以上に述べた第１、第２および第３同期コマンドの全てで伝えられる、例えば、同期対象ノードのデータ、ノードレベルのアドレス、フィルタリング条件、同期タイプ、階層構造データなど、種々の情報は、以上に示されたサブ要素または属性で伝えることができるだけでなく、別の要素または属性でも伝えることができる。これらのコマンドについては非常に多くの実行ケースが存在することに鑑み、これらのコマンドの形式をここで逐一示すことはしないが、しかしそれらは本発明の保護範囲に含まれるものとする。

幾つかの具体的な実施形態について、同期フェーズをこれから説明する。クライアントによって開始された同期手順はサーバによって開始された同期手順と同様であるので、これからは、クライアントが同期フェーズを開始し、サーバがデータ同期操作を実行する例を取り上げて、同期フェーズについて説明する。以下の実施形態では、第１同期コマンドはＳｙｎｃＭＬプロトコルのSync要素を使用して実行され、そのSync要素は、追加、置換、削除または移動などの操作タイプを伝えてもよい。

ユーザが物理的または論理的フォルダを作成でき、再帰的および非再帰的に同期化する任意のフォルダを指定できるよう、クライアントおよびサーバ中にそれぞれ３つのテーブルが構成される。

１．データ項目テーブル（Data Item table） データ項目のＵＩＤと内容（Data）の対応関係を含む、全てのデータ項目の情報を格納するために使用され、ここで、データ項目のＵＩＤはクライアントおよびサーバにおいてそれぞれItem LUIDおよびItem GUIDで示される。

２．フォルダテーブル（Folder Table） 全てのフォルダの情報を格納するために使用され、各フォルダの情報は、フォルダの番号、フォルダの名前（Name）、そのフォルダが属する親フォルダ（Parent Source）、フォルダの状態（Folder Status）およびそれらの対応関係を含み、ここで、フォルダの状態は主に、Existing（現存、Ｅで示される）、Adding（追加、Ａで示される）、Deleting（削除、Ｄで示される）、Moving（移動、Ｍで示される）およびCopying（コピー、Ｃで示される）を含む。状態Deletingは２つの状態、Permanent Deletion（永久削除、Ｐ−Ｄで示され、Hard Deletionとも呼ばれる）およびNon-permanent Deletion（非永久削除、Ｐ−ＮＤで示され、Soft Deletionとも呼ばれる）、をさらに含んでもよく、フォルダのＵＩＤはクライアントおよびサーバにおいてそれぞれFolder LUIDおよびFolder GUIDで示される。従来は、LUIDは、GUIDとは異なる。しかしながら、これらは同一であるとみなすことができる。LUID-GUIDの仕組みの発展は、この発明の範囲に影響しない。

３．「データ項目−フォルダ」の索引テーブル（Index Table） データ項目の所属を格納するために使用され、データ項目のＵＩＤ、親項目（Parent Source）、データ項目の状態（Data Status）、およびそれらの対応関係を含み、ここで、データ項目のＵＩＤはクライアントおよびサーバにおいてそれぞれItem LUIDおよびItem GUIDで示される。

さらに、クライアントにおけるデータのＵＩＤとサーバにおけるそれとの間の対応関係のテーブルがサーバ中に格納されるものとする、すなわち、ＧＵＩＤとＬＵＩＤとの間の対応関係である。

本発明の第１に、ユーザは新しいフォルダ“bless”をショートメッセージ用のルートフォルダ（例えば、/sms）の配下に追加し、“Spring Festival”および“Mid-autumn Festival”２つのサブフォルダをフォルダ“bless”の配下に追加して、それぞれのフォルダの配下にデータ、すなわち、データＮ１をフォルダ“bless”の配下に追加し、データＮ２をフォルダ“Spring Festival”の配下に追加し、そしてデータＮ３をフォルダ“Mid-autumn Festival”の配下に追加する。

図３ａおよび図３ｂに示されるように、図３ａは本発明の第１実施形態においてユーザが定義するデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータ項目を示し、実線はExisting（現存）の状態を示し、そして点線はNew（新規）の状態を示す。図３ｂは、本発明の第１実施形態におけるクライアントのデータ蓄積装置を示す概略図である。クライアントにおいては、データ項目テーブル、フォルダテーブルおよび「データ項目−フォルダ」の索引テーブルが格納される。各テーブル中に付加されたデータ状態は図３ｂ中に対応して示される。

ユーザがフォルダ“bless”を同期化するよう要求すると、クライアントは以下の同期コマンドを整然と作成する。

第１に、ユーザからのフォルダ“bless”を同期化するコマンドに従って同期対象データがフォルダであることを決定した後、クライアントはフォルダテーブルに従って、フォルダ“bless”の状態がＮ（新規）であると決定する。その後、クライアントは、フォルダの追加を指示する同期コマンドを構築する。例えば、Addサブ要素がSyncコマンドに追加され、Syncコマンドのサブコマンドと呼ばれる場合もあるAdd同期コマンドが構築される。構築されるAddコマンドでは、データタイプがフォルダであることを示すためにMetaフィールドが使用される。データタイプはフォルダテーブルに従って決定されるが、そこでは、同期対象データのＵＩＤが1006であることを示すためにＬＵＩＤフィールドが使用され、データ内容が“bless”であることを示すためにDataフィールドが使用され、そして親フォルダがルートフォルダであることを示すためにSourceParentフィールドが使用される。

第２に、クライアントはフォルダ“bless”配下のデータ項目の状態を決定し、そして索引テーブル中のデータ項目2001に対応する状態がＮであるので、Add同期コマンドが構築される。データ項目テーブルに基づいてデータ項目2001に対応するデータ内容はＮ１であると決定した後、構築されるAdd同期コマンドでは、データタイプがｖＣａｒｄ（一種のData Itemとして知られる）であることを示すためにMetaフィールドが使用され、同期対象データのＵＩＤが2001であることを示すためにＬＵＩＤフィールドが使用され、データ内容がＮ１であることを示すためにDataフィールドが使用され、そして親フォルダが1006であることを示すためにSourceParentフィールドが使用される。

クライアントが、フォルダ“bless”の配下には新たに追加されるデータ項目は存在しないと決定した場合、それは次いでフォルダ“bless”配下のサブフォルダの状態をチェックするが、それの実行はフォルダ“bless”の決定についてのそれと同じである。２つのAdd同期コマンドが構築され、一方のAddコマンドには、データタイプがFolderであることを示すMetaフィールド、同期対象データのＵＩＤが1007であることを示すＬＵＩＤフィールド、データ内容が“Spring Festival”であることを示すDataフィールド、および親フォルダが1006であることを示すSourceParentフィールドが存在し、そして他方のAddコマンドには、データタイプがFolderであることを示すMetaフィールド、同期対象データのＵＩＤが1008であることを示すＬＵＩＤフィールド、データ内容が“Mid-autumn Festival”であることを示すDataフィールド、および親フォルダが1006であることを示すSourceParentフィールドが存在する。

フォルダ“bless”の配下には新たに追加されるデータ項目は存在しないと決定した後、クライアントはフォルダ“Spring Festival”およびフォルダ“Mid-autumn Festival”の配下のデータ項目の状態をチェックするが、それの実行はＮ１の決定についてのそれと同じである。すなわち、クライアントは２つのAdd同期コマンドをそれぞれ構築する。

このようにして、再帰的同期は、新たに追加される各データ項目についてAdd同期コマンドを送信することにより実行される。非再帰的同期は、次のケースのようになる。１．１つのフォルダを同期化するだけであり、そのフォルダ配下のデータ項目は同期化しない、例えば、フォルダ名の変更、２．１つのフォルダおよびその配下のデータ項目を同期化するだけであり、サブフォルダは同期化しない。

最後に、構築されたAdd同期コマンドの全てがサーバに送信される。１つのAddコマンド内のデータ量が比較的小さい場合、複数のAddコマンドを１つのメッセージ中に含めて、１回の交換によりサーバへ送信することができる。また、１つのAddコマンド内のデータ量が比較的大きい場合、複数のAddコマンドを伝えるために１つ以上のメッセージが必要となり、全てのAddコマンドは複数の交換によりサーバに送信することができる。実際上は、複数のフォルダおよびデータ項目を含むAdd同期コマンドは１つのみを送信することができ、その１つのAdd同期コマンドを複数の論理的なAddコマンドとみなすものとする。

サーバが上記のAddコマンドを受信した後の同期操作を実行するプロセスをこれから説明する。このプロセスに関係するテーブルは図３ｂに示すテーブルと同様である。

フォルダ“bless”を追加する同期コマンドの受信後、サーバは、受信した同期コマンドに含まれるMetaフィールドに従って同期対象データのタイプがFolderであり、ＬＵＩＤフィールドに従って同期対象データのＵＩＤが1006であり、Dataフィールドに従って同期対象フォルダの名前が“bless”であり、そしてSourceParentフィールドに従って親フォルダがルートフォルダであると決定する。その後、同期対象データに、サーバのローカルＵＩＤ（Folder GUID）が、例えば、100006と、割り当てられる。次いで、対応する項目がローカルに構築されたフォルダテーブルに追加される。例えば、100006、bless、ルートフォルダ、データ項目の状態およびそれらの対応関係を含む項目が追加される。これに加えて、クライアントにおける同期対象データのＵＩＤ（すなわち、ＬＵＩＤ）、サーバにおける同期対象データのＵＩＤ（すなわち、ＧＵＩＤ）およびそれらの対応関係が、ＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルに格納される。すなわち、1006、100006およびそれらの対応関係が格納される。

サーバがデータ項目Ｎ１を追加する同期コマンド受信した場合、それは、受信した同期コマンドに含まれるMetaフィールドに従って同期対象データのタイプはData Itemであり、ＬＵＩＤフィールドに従ってクライアント中のデータのＵＩＤは2001であり、Dataフィールドに従ってデータ内容はＮ１であり、そしてSourceParentフィールドに従って親フォルダは1006であると決定する。その後、データ項目Ｎ１はローカルデータベースに格納され、次いで、200001など、サーバのローカルＵＩＤ（Folder GUID）が同期対象データに割り当てられ、200001、Ｎ１およびそれらの対応関係など、対応する項目がローカルに構成されたデータ項目テーブルに追加され、200001、100006、データ項目Ｎ１の状態およびそれらの対応関係など、対応する項目が索引テーブルに追加され、そしてクライアント中の同期対象データのＵＩＤ、サーバ中の同期対象データのＵＩＤおよびそれらの対応関係、すなわち、2001、200001およびそれらの対応関係、がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルに格納される。

サーバにおいてフォルダ“Spring Festival”および“Mid-autumn Festival”を追加するやり方は、フォルダ“bless”を追加するものと同じであり、そしてデータ項目Ｎ２およびＮ３を追加するやり方はデータ項目Ｎ１を追加するものと同じである。

さらに、注目すべきは、同期操作を実行するためにサーバが同期コマンドをクライアントへ送信する場合、サーバ中の同期対象データのＵＩＤはその同期コマンド中に含まれ、同期操作の実行後、クライアントはサーバへ、クライアント中の同期対象データのＵＩＤとサーバ中のそれとの間の対応関係、すなわち、ＬＵＩＤとＧＵＩＤとの間の対応関係、を返し、サーバは受信した対応関係をＬＵＩＤとＧＵＩＤとの間の対応関係についてローカルに構成されたテーブルに格納する。

こうして、データを追加する同期操作を実行することができ、ここで、そのデータはユーザの要望に従って作成した特定のデータ項目またはフォルダであってよく、それはシステムの物理的なデータ構造によって限定されない。本発明の実施形態の利点は、データ構造中の複数のノードに属するかもしれないデータについて、複数のノードのデータ同期化においてそのデータの１つのコピーのみが転送され、またそのデータの１つのコピーのみが同期操作を実行する側によって格納され、それによりネットワークおよび装置のリソースが大幅に節減されることにあることがわかる。例えば、Ｎ１がフォルダ“bless”、“Spring Festival”および“Mid-autumn Festival”に属するものとすると、サーバでの同期操作中に、２つの対応するエントリ、すなわち、項目１「200001、100007、データＮ１の状態およびそれらの対応関係」および項目２「200001、100008、データＮ１の状態およびそれらの対応関係」、を索引テーブルに追加するものとする。

第２実施形態では、ユーザは、ショートメッセージ用のルートフォルダ（/sms）配下のフォルダ“bless”の属性、フォルダ“bless”中のデータ項目Ｕ１、およびフォルダ“Spring Festival”中のデータ項目Ｕ２、を更新する。この実施形態では、Ｕ２はフォルダ“Spring Festival”および“Mid-autumn Festival”に属する。

図４ａおよび図４ｂに示すように、図４ａは、本発明の第２実施形態においてユーザが定義したデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータItemを示し、実線はその状態がExisting（現存）であることを示し、そして点線はその状態がUpdate（更新）であることを示す。図４ｂは、本発明の第２実施形態におけるクライアントのデータ蓄積装置を示す概略図である。データ項目テーブル、フォルダテーブルおよび索引テーブルはクライアント中に格納されている。各テーブル中のデータ状態は図４ｂ中に対応して示される。

ユーザがフォルダ“bless”の同期を要求した場合、クライアントは以下の同期コマンドを整然と作成する。

まず、ユーザから受信したフォルダ“bless”の同期のためのコマンドに従って、同期対象データがフォルダであると決定すると、クライアントは、フォルダテーブルのフォルダ“bless”の状態はＵ（更新）であると決定し、更新を指示する同期コマンド、例えば、Syncコマンドのサブコマンドとも呼べる、Replace同期コマンドを構築する。そして、構築したReplaceコマンドにおいて、データタイプがFolderである−これはフォルダテーブルに従って決定される−ことを示すためにMetaフィールドが使用され、同期対象データのＵＩＤが1006であることを指示するためにＬＵＩＤフィールドが使用され、具体的なデータが“bless”であることを指示するためにDataフィールドが使用され、そして親フォルダがルートフォルダであることを指示するためにSourceParentフィールドが使用される。

その後、クライアントは、フォルダ“bless”中のデータ項目の状態を索引テーブルに従って決定し、番号1006に対応するデータ項目は状態がＵである2001であると決定して、Replace同期コマンドが構築される。データ項目2001に対応する具体的なデータ内容がデータ項目テーブルからＮ１であると決定された後、構築されるReplace同期コマンドでは、データタイプがｖＣａｒｄ（一種のData Itemとして知られる）であることを指示するためにMetaフィールドが使用され、同期対象データのＵＩＤが2001であることを指示するためにＬＵＩＤフィールドが使用され、具体的なデータがＵ１であることを指示するためにDataフィールドが使用され、そしてデータ項目が属する親フォルダが1006であることを指示するためにSourceParentフィールドが使用される。

次いで、フォルダ“bless”中には置換対象データ項目は存在しないと決定した後、クライアントはフォルダ“bless”の１つ以上のサブフォルダの状態をチェックするが、その実行はフォルダ“bless”を決定するためのそれと同じである。そして、この実施形態では、フォルダ“bless”のサブフォルダの状態には変更はなく、そのためサブフォルダは処理する必要がない。

最後に、フォルダ“bless”の配下に同期対象サブフォルダが存在しないと決定した時、クライアントはサブフォルダ“Spring Festival”中のデータ項目の状態をチェックするが、これの実行はデータ項目Ｕ１を決定するのと同じである。すなわち、クライアントはReplace同期コマンドを構築し、そして、番号2002に対応する具体的なデータ内容がデータ項目テーブルからＵ２であると決定した後、構築されるReplace同期コマンドにおいて、データタイプがｖＣａｒｄ（一種のData Itemとして知られる）であることを指示するためにMetaフィールドが使用され、同期対象データのＵＩＤが2002であることを指示するためにＬＵＩＤフィールドが使用され、具体的なデータがＵ２であることを指示するためにDataフィールドが使用され、そしてデータ項目が属する親フォルダが1007であることを指示するためにSourceParentフィールドが使用される。

このようにして、再帰的同期は、置換される各データ項目についてReplace同期コマンドを送信することにより実行される。勿論、非再帰的同期も実行可能であるが、その実行の原理は再帰的同期のものと同様であり、それについてはここではこれ以上説明しない。再帰的同期を実行するかどうかは、同期開始フェーズでの同期対象フォルダの取り決めにおいて決定することができ、ここで、再帰的同期識別子が本発明の実施形態による第２同期コマンドでさらに伝えられる。値“true（真）”を有する再帰的同期識別子は、同期対象フォルダに対して再帰的同期が実行されるべきことを示し、その結果、同期対象フォルダのルートノードおよび全てのサブノードに対してデータ同期が実行されることになる。値“false（偽）”を有する再帰的同期識別子が第２同期コマンドで伝えられる場合、それは、同期対象フォルダに対して非再帰的同期が実行されるべきことを示し、その結果、同期対象フォルダのルートノードに対してのみ、データ同期が実行されることになる。値“true（真）”を有する再帰的同期識別子が示されてない場合、常に再帰的同期とみなすことができる。同期開始フェーズにおいて、再帰的同期が同期対象フォルダに対して実行されるものと決定された場合、同期フェーズでクライアントまたはサーバによって送信される第１同期コマンドで伝えられるデータ内容は、同期対象フォルダのルートフォルダおよび各サブフォルダのデータ内容を含み、そして第１同期コマンドの受信側は、第１同期コマンドで伝えられたデータ内容に従って、同期対象フォルダのルートフォルダおよび各サブフォルダのデータ内容を順々に同期化する。そして、同期開始フェーズにおいて、非再帰的同期が同期対象フォルダに対して実行されるものと決定された場合、同期フェーズでクライアントまたはサーバによって送信される第１同期コマンドで伝えられるデータ内容は、同期対象フォルダのルートフォルダのデータ内容を含み、そして第１同期コマンドの受信側は、同期対象フォルダのルートフォルダのデータ内容のみを同期化する。ここで、本発明の実施形態において述べられるデータ内容は、同期対象フォルダのフォルダおよびデータ項目の内容、例えば、フォルダ名（Name）およびデータ項目のデータ（Data）、を示す。

その後、全ての構築されたReplace同期コマンドはサーバへ送信されるが、その詳細な転送方法はAdd同期コマンドの転送についてのものと同じであり、ここではそれ以上説明しないものとする。

サーバが上記のReplaceコマンドを受信した後、同期操作を実行するプロセスについてこれから説明する。このプロセスに関係するテーブルは図４ｂに示されたテーブルと同様であり、ここでは示さない。

フォルダ“bless”を置換する同期コマンドの受信後、サーバは、受信した同期コマンドのMetaフィールドに従って同期対象データのタイプがFolderであり、ＬＵＩＤフィールドに従って同期対象データのＵＩＤが1006であり、Dataフィールドに従って同期対象フォルダの名前が“bless”であり、そしてSourceParentフィールドに従って同期対象データの親フォルダがルートフォルダであると決定する。その後、ローカルサーバにおける同期対象データ−それが置換される−の番号、例えば、100006、がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得される。次いで、構成されたフォルダテーブルにおいて対応する項目が置換される、すなわち、項目中の“bless”の属性情報が置換され、ここで、その項目は、100006、bless、ルートフォルダ、データ項目“bless”の状態およびそれらの対応関係を含む。

データ項目Ｕ１を置換する同期コマンドの受信後、サーバは、受信した同期コマンドのMetaフィールドに従って同期対象データのタイプがData itemであり、ＬＵＩＤフィールドに従ってクライアント中のデータのＵＩＤが2001であり、Dataフィールドに従って具体的なデータ内容がＵ１であり、そしてSourceParentフィールドに従って親フォルダが1006であると決定する。その後、ローカルサーバ（例えば、200001）における同期対象データ−それが置換される−のＵＩＤが、ＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、そして同期対象データのローカルＵＩＤに対応する項目がローカルに構成されたデータ項目テーブル中で置換される。すなわち、項目200001中のＵ１の情報、Ｕ１およびそれらの対応関係が置換される。

サーバにおいてＵ２を置換する方法はＵ１を置換する方法と同じであり、ここでこれ以上述べることはしない。

注目すべきは、この実施形態では、Ｕ２はフォルダ“Spring Festival”および“Mid-autumn Festival”の両方に属するが、Ｕ２を置換するためにはReplaceコマンドは１度だけ送ればよく、サーバにおいてＵ２は１度だけ置換すればよく、それで２つのフォルダの両方の中のＵ２を置換することができる。サーバにおいては実際にはデータのコピーが１つだけ格納されており、データの帰属が索引テーブルに示されているからである。本発明の実施形態の方法を使用することにより冗長データが最大限に削減され、リソースを節減できることがわかる。

第３実施形態では、ユーザはデータ項目“Ｍ１”をフォルダ“music”からフォルダ“favorite”へ移動し、そしてフォルダ “mp3” 全体を“favorite”へ移動する。

図５ａおよび図５ｂに示すように、図５ａは、本発明の第３実施形態においてユーザが定義したデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータItemを示し、実線はその状態がExisting（現存）であることを示し、そして点線はその状態がMove（移動）であることを示す。図５ｂは、本発明の第３実施形態におけるクライアントのデータ蓄積装置を示す概略図である。データ項目テーブル、フォルダテーブルおよび索引テーブルはクライアント中に格納されている。各テーブル中のデータ状態は図５ｂ中に対応して示される。

ユーザがルートフォルダの同期を要求した場合、クライアントは以下の同期コマンドを整然と作成する。

まず、クライアントは、ユーザから受信したルートフォルダを同期化するコマンドに従って、ルートフォルダの全てのサブフォルダの状態をチェックする。この実施形態では、ルートフォルダの全てのサブフォルダの状態に変更がなく、処理される必要はない。次いで、クライアントはルートフォルダ配下のデータ項目の状態が変更されているかどうかをチェックする。この実施形態では、ルートフォルダ配下のデータ項目の状態は変更がなく、処理の必要はない。

その後、クライアントは各サブフォルダの状態が変更されているかどうかを順々にチェックする。この実施形態では、クライアントはmusicフォルダ配下の“mp3”サブフォルダの状態がＭ（移動）であると決定し、次いでMove同期コマンドを構築する。Move同期コマンドはSyncコマンドのサブコマンドと呼ばれてもよく、これは、懸案の移動データを伝えるために使用される。構築されるMoveコマンドでは、データタイプがFolderであることを示すためにMetaフィールドが使用され、データタイプはフォルダテーブルに従って決定され、同期対象データの番号が1006であることを示すためにＬＵＩＤフィールドが使用され、そしてフォルダの移動後の親フォルダが1004であることを示すためにSourceParentフィールドが使用される。

次いで、クライアントは、musicフォルダ配下のデータ項目の状態を、1006に対応するデータ項目は索引テーブルで2001であってその状態はＭ（移動）と決定し、Move同期コマンドが構築され、そしてその構築されたコマンドにおいて、データタイプがItemであることを指示するためにMetaフィールドが使用され、同期対象データの番号が2001であることを指示するためにＬＵＩＤフィールドが使用され、そしてフォルダの移動後の親フォルダが1004であることを指示するためにSourceParentフィールドが使用される。

このようにして、本実施形態では他に移動されるデータは存在せず、それ以上の処理はない。

その後、全ての構築されたMove同期コマンドはサーバへ送信される。詳細な転送のやり方はAdd同期コマンドの転送のものと同じであり、ここではこれ以上説明しない。

サーバが上記のMoveコマンドを受信した後の同期操作を実行するプロセスについてこれから説明する。このプロセスに関係するテーブルは、図５ｂに示されるテーブルと同様であり、ここではテーブルは示さない。

mp3フォルダの移動を指示するMove同期コマンドの受信後、サーバは、受信したMove同期コマンドのMetaフィールドに従って同期対象のデータタイプがFolderであると決定し、そしてＬＵＩＤフィールドに従ってクライアントにおける同期対象データの番号が1006であると決定し、さらにSourceParentフィールドに従ってmp3フォルダが移動した後の親フォルダが1004であると決定する。その後、サーバにおける懸案の移動データの番号（例えば、100006）が、ＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、そしてローカルに構成されたフォルダテーブルの同期対象ローカルデータの番号に対応する項目において、親フォルダが、受信Move同期コマンドで伝えられた親フォルダに変更される、すなわち、テーブル中の100006に対応する親フォルダが1005から1004に変更される。

Ｍ１データ項目の移動を指示するMove同期コマンドの受信後、サーバは、受信したMove同期コマンドのMetaフィールドに従って同期対象のデータタイプがItemであることを決定し、そしてＬＵＩＤフィールドに従ってクライアントにおける同期対象データの番号が2001であることを決定し、さらにSourceParentフィールドに従ってＭ１データ項目の移動後の親フォルダが1004であると決定し、その後、ローカルサーバにおける同期対象データの置換された番号、例えば、200001、がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、ローカルに構成された索引テーブルにおけるローカルな同期対象データの番号に対応する項目において、親フォルダが受信同期コマンドで伝えられた親フォルダに変更される、すなわち、テーブル中の200001に対応する親フォルダが1005から1004へ変更される。

本発明の実施形態による方法は、移動同期操作を実行するとき、対応するデータテーブルの対応関係の変更を必要とするだけであり、実際のデータの移動を必要とせず、その結果、限られたリソースが最大限に節約されることがわかる。

注目すべきは、フォルダのみならずそのサブフォルダおよびデータ項目が移動する時、例えば、mp3フォルダが移動する時、mp3フォルダに関係する１つのMoveコマンドのみが送信されればよく、mp3フォルダ配下のサブフォルダおよびデータ項目に関係するその他のMoveコマンドは、そのサブフォルダおよびそれらデータ項目が属する親フォルダが変化しないので、送信の必要がないことである。

第１同期コマンドで伝えられる操作タイプが削除であって、同期対象フォルダ配下のデータ項目を同期化するステップが、同期対象フォルダのデータ項目のデータ内容が同期対象フォルダの配下のみに格納されているかどうか、もしそうである場合、第１同期コマンドで値“true”を有する永久削除識別子をさらに伝えるか、もしそうでない場合、第１同期コマンドで値“false”を有する永久削除識別子をさらに伝えるか、を決定するステップを含む時、第１同期コマンドによって同期対象フォルダに対して実行されるデータ同期操作は、値“true”を有する永久削除識別子が第１同期コマンドで伝えられたかどうかを決定するステップを含み、もしそうである場合は同期対象フォルダ配下のデータ項目のデータ内容を削除するステップを、もしそうでない場合はデータ項目と同期対象フォルダとの間の対応関係を廃棄するステップを、含む。値“true（真）”を有する永久削除識別子が示されてない場合、常に永久削除とみなすことができる。

第４実施形態では、ユーザは“bless”フォルダ配下の“Ｄ１”データ項目を削除し、そして“Spring Festival”フォルダ配下のデータ“Ｕ２”について永久削除を選択し、そして“Spring Festival”フォルダ配下のデータ“Ｄ３”について非永久削除を選択する。この実施形態では、データ項目の削除についてのみ説明する。

図６ａおよび図６ｂに示すように、図６ａは、本発明の第４実施形態を使用してユーザが定義したデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータItemを示し、実線はその状態がExisting（現存）であることを示し、そして点線はその状態がDelete（削除）であることを示す。図６ｂは、本発明の第４実施形態を使用するクライアントのデータ蓄積装置を示す概略図である。データ項目テーブル、フォルダテーブルおよび索引テーブルはクライアント中に格納されている。各テーブル中のデータ状態は図６ｂ中に対応して反映されている。

ユーザが“bless”フォルダの同期を要求した場合、クライアントは以下の同期コマンドを整然と作成する。

クライアントはblessフォルダ配下のデータ項目の状態を決定する。データ項目2001の状態はＰ−Ｄであるので、Delete同期コマンドが構築される。Delete同期コマンドは、あるデータの削除を伝えるために使用されるSyncコマンドのサブコマンドと呼ばれる場合もあり、構築されるDelete同期コマンドでは、データタイプがItemであることを示すためにMetaフィールドが使用され、同期対象データの番号が2001であることを指示するためにＬＵＩＤフィールドが使用され、そして永久削除を指示する識別子もまたDelete同期コマンドに含められる必要がある。

blessフォルダ配下に削除データ項目が存在しないと決定した後、クライアントはblessフォルダ配下のサブフォルダの状態をチェックする。この実施形態では、blessフォルダ配下のサブフォルダ状態には変更がなく、処理の必要がない。

blessフォルダ配下に削除サブフォルダは存在しないと決定した後、クライアントは“Spring Festival”サブフォルダ配下のデータ項目の状態を決定する。その方法の詳細はＤ１を決定するものと同じである。すなわち、最終結果は２つのDelete同期コマンドを構築することであり、一方のDelete同期コマンドでは、データタイプがｖＣａｒｄ（一種のData Itemとして知られる）であることを示すためにMetaフィールドが使用され、同期対象データの番号が2002であることを指示するためにＬＵＩＤフィールドが使用され、そして永久削除を指示する識別子、例えば、Ｐ−Ｄ、もまたそのコマンドに含められる必要がある。そして、もう一方のDeleteコマンドでは、データタイプがｖＣａｒｄ（一種のData Itemとして知られる）であることを示すためにMetaフィールドが使用され、同期対象データの番号が2003であることを指示するためにＬＵＩＤフィールドが使用され、そして非永久削除を指示する識別子、例えば、ＮＰ−Ｄ、もまたそのコマンドに含められる必要がある。

構築されたDelete同期コマンドは懸案の削除データを含まなくてよく、懸案の削除データのタイプおよびＵＩＤを、永久削除か非永久削除かのシナリオで指示しさえすればよい。以上は、Deleteコマンドの１つの実行のやり方であり、すなわち、そのコマンドは、タイプ、ＵＩＤおよび永久削除か非永久削除かを伝えるために使用される識別子の３種類の情報を含むが、勿論、別の実行のやり方も存在し、例えば、Deleteコマンドを２つのコマンド、一方をP-Deleteコマンド、他方をNP-Deleteコマンド、に分割すれば、各々の削除コマンドは、タイプおよび懸案削除データの番号を含みさえすればよい。

最後に、削除を伝えるために使用される全ての構築された同期コマンドはサーバへ送信される。

サーバが上記Deleteコマンドを受信した後の同期操作で実行されるプロセスをこれから説明する。

Ｄ１データ項目の削除を指示する同期コマンドの受信後、サーバは、受信した同期コマンドのMetaフィールドに従って同期対象データのタイプがItemであると決定し、ＬＵＩＤフィールドに従ってクライアントにおける同期対象データの番号は2001であると決定し、削除が永久削除であると決定し、その後、ローカルサーバにおける懸案の削除データ番号−例えば、200001−がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、データ項目テーブルおよび索引テーブル中で、同期対象データのローカル番号に対応する項目がそれぞれ削除される、すなわち、200001と番号を付された全項目が削除される。同時に、ローカルデータベースにおいてデータＤ１が削除される。

Ｄ２データ項目の削除を伝えるために使用されるDelete同期コマンドの受信後、サーバは対応するデータテーブルの全項目を削除するが、Ｄ２を削除する方法はＤ１を削除するものと同じであり、ここでそれ以上説明しない。

Ｄ３データ項目の削除を伝えるために使用されるDelete同期コマンドの受信後、サーバは、受信したDelete同期コマンドのMetaフィールドに従って同期対象データのタイプがItemであると決定し、ＬＵＩＤフィールドに従ってクライアントにおける同期対象データの番号が2003であると決定し、削除が非永久削除であると決定し、その後、ローカルサーバにおける懸案の削除データ番号−例えば、200003−がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、索引テーブルにおいて、同期対象データのローカルデータの番号に対応する項目のみが削除される、すなわち、200003と番号を付された全項目が削除され、Ｄ３データはローカルデータベースでは削除されない。

本発明の実施形態による本方法は、削除の同期操作を実行する時に、クライアントとサーバとの間で識別子を送信しさえすればよく、また詳細なデータ内容を送信する必要はなく、その結果、限りあるリソースが最大限に節約されることがわかる。

第５実施形態では、ユーザは“bless”フォルダ全体を削除する。それは“bless”フォルダの全てのサブフォルダおよびデータ項目を削除することに等しい。この実施形態では、Ｄ１とＤ２のみがblessフォルダの配下にあって、Ｄ３はblessフォルダおよびjokeフォルダの配下にある。また、この実施形態ではフォルダを削除する説明のみとする。

図７ａおよび図７ｂに示すように、図７ａは、本発明の第５実施形態を使用してユーザが定義したデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータItemを示し、実線はその状態がExisting（現存）であることを示し、そして点線はその状態がDelete（削除）であることを示す。図７ｂは、本発明の第５実施形態を使用するクライアントのデータ蓄積装置を示す概略図である。データ項目テーブル、フォルダテーブルおよび索引テーブルはクライアント中に格納されている。各テーブル中のデータ状態は、図７ｂ中に対応して反映されている。

ユーザがルートフォルダの同期を要求した場合、クライアントは以下の同期コマンドを整然と作成する。

まず、クライアントは、ユーザから受信したルートフォルダの同期のコマンドに従って、ルートフォルダ配下の全てのサブフォルダの状態をチェックする。この実施形態では、blessの状態はフォルダテーブルからＤと決定され、クライアントは以下のステップをさらに実行する。すなわち、懸案の削除フォルダのデータ項目およびそのフォルダのサブフォルダのデータ項目が懸案の削除フォルダの配下のみに存在するかを決定するステップ、もしそうである場合、Delete同期コマンドを構築して永久削除を指示する情報をDelete同期コマンドに含ませるステップ、もしそうでない場合、各々のデータ項目およびフォルダに関するDelete同期コマンドをそれぞれ構築して、永久削除を指示する情報を懸案の削除フォルダ配下のみに存在するデータ項目またはフォルダに対応するDelete同期コマンドに含ませ、そして非永久削除を指示する情報を懸案の削除フォルダ配下のみには存在しないデータ項目またはフォルダに対応するDelete同期コマンドに含ませるステップである。すなわち、そのデータ項目またはフォルダが別のフォルダの配下にも存在する場合は（ここでは、他のフォルダはblessサブフォルダを含ないとする）、非永久削除情報がそのようなデータに対応するDelete同期コマンドに含まれ、そして、そのようなデータでない場合は、永久削除情報がそれに対応するDelete同期コマンドに含まれる。その後、全ての構築されたDelete同期コマンドはサーバに送信される。ここで、削除コマンドはそれぞれ各データ項目およびフォルダに関連して構築され、それは実際に再帰的な同期である。

サーバが上記のDelete同期コマンドを受信した後の同期操作の実行のプロセスについてこれから説明する。

サーバが受信したコマンドがデータ項目と関連するDelete同期コマンドの場合、処理のやり方は第４実施形態のものと同じであり、ここではそれ以上説明しない。

サーバが受信したコマンドがフォルダに関連するDelete同期コマンドの場合、ローカルサーバにおける懸案の削除データの番号がＬＵＩＤとＧＵＩＤとの間の対応関係について構成されたテーブルから取得され、次いで、同期対象ローカルデータの番号に対応する項目が、ローカルに構成されたフォルダテーブルから永久削除か非永久削除かに関わらず削除る。

またフォルダ削除操作に関連して注目すべきは、クライアントが同期を主導してフォルダを削除−例えば、blessフォルダを削除−するとき、それは、そのフォルダに関連する１つのDelete同期コマンドを構築できるのみであり、それが実行するその他の操作、例えば、「懸案の削除フォルダのデータ項目およびそのフォルダのサブフォルダのデータ項目が懸案の削除フォルダの配下のみに存在するかの決定」等は、クライアントの操作を簡易化するために、全てサーバによって実行されることである。勿論、逆もまた同様である。

実際の適用では、第４実施形態は、通常、第５実施形態と併せて使用される。

さらに、削除操作については、サーバの同期操作の終了後、クライアントはそれ自身の対応するデータテーブルを削除する。

第６実施形態では、ユーザはデータ項目“Ｍ１”を“music”フォルダから“favorite”フォルダへコピーし、そして“mp3”フォルダを“favorite”フォルダへコピーする。

図８ａおよび図８ｂに示すように、図８ａは、本発明の第６実施形態を使用してユーザが定義したデータ構造を示す概略図であり、ここで、四角のフレームはFolderを示し、円はデータItemを示し、実線はその状態がExisting（現存）であることを示し、そして太線はその状態がCopy（コピー）であることを示す。図８ｂは、本発明の第６実施形態を使用するクライアントのデータ蓄積装置を示す概略図である。データ項目テーブル、フォルダテーブルおよび索引テーブルはクライアント中に格納されている。各テーブルに付加されたデータの状態は図３ｂ中に対応して反映されている。

注目すべきは、上記の実施形態において、クライアントにおける番号とサーバにおける番号との間の対応関係のテーブル、例えば、ＬＵＩＤとＧＵＩＤとの間の対応関係のテーブル−すなわち、ＬＵＩＤ−ＧＵＩＤメカニズム−を有する目的は、長いＵＩＤをサポートできない限られた容量の装置が存在する事実を考慮していることである。全ての装置が長いＵＩＤをサポートできる場合、ＬＵＩＤ−ＧＵＩＤメカニズムは、クライアントおよびサーバがクライアントかサーバかによって生成された同じＵＩＤを使用するように進化し、その場合、プロセスは同じＵＩＤを使用して直接に実行することができ、そして、ＬＵＩＤ−ＧＵＩＤの対応付けはもはや不要となる。従ってその場合は、本発明のこの実施形態の実装に限定されない。

ユーザがルートフォルダの同期を必要とするとき、クライアントおよびサーバの操作は第１実施形態のものと同じである。それらの違いは、第１実施形態では、クライアントは各データ項目およびフォルダに関連して１つのAdd同期コマンドを送信し、一方、この実施形態では、クライアントがフォルダに関連してCopy同期コマンド（そのCopy同期コマンドもまたSyncコマンドのサブコマンドであり、懸案のコピーデータを伝えるために使用される）を送信する場合、そのフォルダ配下のサブフォルダおよびデータ項目に関連してはCopy同期コマンド送信する必要がなく、そのためデータの転送量はさらに低減してネットワークリソースが節約される。この実施形態におけるサーバのプロセスは第１実施形態のものと同じであり、各フォルダおよびデータ項目に関連して逐一実行される。

さらに付け加えると、Copy同期が実行されるとき、ユーザは、実際のデータのコピーが作成される必要があるかどうか、もしそうである場合、同期操作を実行する側のデータ同期操作が、ローカルデータベースにおけるデータのコピーおよびローカルに構成されたデータフォルダテーブル中の対応する項目の追加、をさらに含むか、を要求に従って決定する。

クライアントの変更操作、例えば、移動したフォルダ中でのエントリの追加、置換または削除、がサーバのそれと矛盾する場合、本発明の実施形態は、既存の矛盾解決メカニズムを拡張することによりクライアントおよびサーバ間の完全なデータ同期を保証することができる。詳細な実装は、クライアントおよびサーバからのデータ内容をマージするための、ある構成に基づく「ウィン−ウィン（win-win）」という名前の新しい解決法を追加するよう既存の矛盾解決メカニズムを拡張し、そして現在の「クライアント−ウィン（Client-Win）」または「サーバ−ウィン（Server-Win）」解決法に加えて、ウィン−ウィンのやり方によりクライアントおよびサーバ間で完全に同じデータを確保する。クライアントのデータ操作がサーバのそれと矛盾するとき、サーバが矛盾を検出して「ウィン−ウィン」解決法を実行する。次いで、サーバは、矛盾解決結果に従って同期操作を返信し、クライアントはサーバのデータ操作に従って同期操作を実行するが、そのデータ操作は、追加操作、置換操作、移動操作、削除操作、コピー操作またはそれらの任意の組合せを含む。例えば、ユーザがクライアントにおいてＡフォルダを移動してそれをＢフォルダのサブフォルダとし、そしてサーバ中のＡフォルダに項目を追加する、すると、クライアントおよびサーバ間の完全な同一データを保証するために、サーバはＡフォルダを移動してそれをＢフォルダのサブフォルダとし、そしてクライアントもまたＡフォルダに項目を追加する。

本発明の実施形態は、上記の方法に基づくデータ同期のためのシステムをさらに開示し、そのシステムはクライアントおよびサーバを含み、それらは同期コマンドの交換により相互に通信し合う。クライアントおよびサーバは、同期対象フォルダの決定および同期対象フォルダの同期の実行にさらに使用される。

図９は、本発明の実施形態によるデータ同期のためのシステムアーキテクチャを示す概略図である。図９に示すように、クライアントは、ノードアドレスを処理する第１モジュールおよびデータ同期のための第１モジュールを含み、そしてサーバはノードアドレスを処理する第２モジュールおよびデータ同期のための第２モジュールを含む。

クライアントにおいては、ノードアドレスを処理する第１モジュールが、同期対象ノードのアドレスを決定してデータ同期のための第１モジュールへ送信し、同期対象ノードのアドレスをデータ同期のための第１モジュールから受信し、受信したアドレスに従って同期対象ノードを決定し、かつ同期対象ノード配下のデータについてクライアントおよびサーバ間の同期を提供するために使用され、また、データ同期のための第１モジュールが、同期対象ノードのアドレスをノードアドレスを処理する第１モジュールから受信し、同期対象ノードのアドレスを伝える同期コマンドを構築し、その同期コマンドをサーバへ送信し、同期コマンドをサーバから受信し、同期対象ノードのアドレスをその同期コマンドから取得し、かつその取得したアドレスをノードアドレスを処理する第１モジュールへ送信するために使用される。ノードアドレスを処理する第１モジュールは、ユーザがクライアント用に同期対象ノードのアドレスを設定できるよう、構築されたコマンドによってユーザから入力された同期対象ノードのアドレスを受信するためにさらに使用されてもよい。

サーバにおいては、ノードアドレスを処理する第２モジュールが、同期対象ノードのアドレスを決定してデータ同期のための第２モジュールへ送信し、同期対象ノードのアドレスをデータ同期のための第２モジュールから受信し、受信アドレスに従ってその時の同期対象ノードを決定し、かつ同期対象ノードの配下のデータについてクライアントおよびサーバ間の同期を提供するために使用され、また、データ同期のための第２モジュールが、同期対象ノードのアドレスをノードアドレスを処理する第２モジュールから受信し、同期対象ノードのアドレスを伝える同期コマンドを構築し、同期コマンドをサーバに送信し、同期コマンドをサーバから受信して同期対象ノードのアドレスを分析によって同期コマンドから取得し、かつ取得したアドレスをノードアドレスを処理する第２モジュールに送信するために使用される。

データ同期のための上記のシステムから、本発明の実施形態は、データ同期のためのクライアントおよびデータ同期のためのサーバをさらに開示することがわかる。クライアントおよびサーバを実装する原理は、上記のシステムにおけるクライアントおよびサーバについてのものと同じであり、したがって、それの動作原理および内部構造をここでさらに説明することはしないが、本発明の保護の範囲に含まれるものとする。

以上は、本発明の好ましい実施形態に過ぎず、本発明を限定するために使用されるものではない。本発明の精神および原理の下になされたいかなる変更、等価な置換または改良も、本発明の保護の範囲に含まれるものとする。

データ同期の実行の概略図である。 クライアントおよびサーバのデータ蓄積装置を示す概略図である。 本発明の第１実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第１実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の第２実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第２実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の第３実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第３実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の第４実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第４実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の第５実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第５実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の第６実施形態による、ユーザによって定義されるデータ構造を示す概略図である。 本発明の第６実施形態による、クライアントのデータ蓄積装置を示す概略図である。 本発明の実施形態による、データ同期のためのシステムアーキテクチャを示す概略図である。

Claims (14)

1. 複数の装置の同期を実行する方法であって、
   同期セッションの同期開始フェーズで、第１装置により、第２装置から該第２装置の階層的木構造の記述が受信され、前記記述に基づいて、前記階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスが決定される段階と、
   前記同期開始フェーズで、前記第１装置により、前記同期対象情報ノードを指定するための同期コマンドが前記第２装置に送信される段階と、
   前記同期セッションの同期フェーズで、前記第１装置により、前記アドレスが用いられ、指定された情報ノードが前記第２装置に同期される段階と
   を有し、
   前記記述は、階層的木構造中の全情報ノードの階層的位置を記述するために使用され、
   前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
   前記情報ノードは、データベース中のデータ項目またはフォルダであり、
   前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
   前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
   前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
   前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とする方法。
2. 複数の装置の同期を実行する方法であって、
   同期セッションの同期開始フェーズで、第１装置により、第２装置の階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスとして、アドレスの指定が行われ、当該アドレスが前記第２装置に存在しない場合、前記第２装置により、当該アドレスにノードが生成される段階と、
   前記同期開始フェーズで、前記第１装置により、前記同期対象情報ノードを指定するための同期コマンドが前記第２装置に送信される段階と、
   前記同期セッションの同期フェーズで、前記第１装置により、前記アドレスが用いられ、指定された情報ノードが前記第２装置に同期される段階と
   を有し、
   前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
   前記情報ノードは、データベース中のデータ項目またはフォルダであり、
   前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
   前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
   前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
   前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とする方法。
3. 複数の装置の同期を実行する方法であって、
   同期セッションの同期開始フェーズで、第１装置により、第２装置の階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスが取得される段階と、
   前記同期開始フェーズで、前記第１装置により、前記同期対象情報ノードを指定するための同期コマンドが前記第２装置に送信される段階と、
   前記同期セッションの同期フェーズで、前記第１装置により、前記アドレスが用いられ、指定された情報ノードが前記第２装置に同期される段階と
   を有し、
   前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
   前記情報ノードは、データベース中のデータ項目またはフォルダであり、
   前記アドレスは、フィルタリング条件として構成され、
   前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
   前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
   前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
   前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とする方法。
4. 前記第１装置により、前記同期対象情報ノードを指定するための同期コマンドが前記第２装置に送信される段階が、
   前記第１装置により、決定した送信元および同期対象のターゲットアドレスを伝えるＡｌｅｒｔコマンドと、同期タイプ折衝パラメータとが前記第２装置に送信される段階を含むことを特徴とする請求項１に記載の方法。
5. 前記第１装置により、前記第２装置から該第２装置の階層的木構造の記述が受信され、前記記述に基づいて、前記階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスが決定される段階が、
   前記第１装置により、前記第２装置の階層的木構造の記述を取得するための同期コマンドが前記第２装置に送信される段階と、
   前記第２装置により、自身の階層的木構造の記述が応答として前記第１装置に返される段階と
   を含むことを特徴とする請求項１に記載の方法。
6. 前記記述を取得するための前記同期コマンドが、装置性能情報を取得するために使用される拡張同期コマンドであり、
   前記拡張同期コマンドには、装置の階層的木構造の記述を取得する要求を指示するための識別子が追加され、
   前記第２装置の階層的木構造の記述が、第２拡張コマンドによって第１装置に返され、
   前記第２拡張コマンドには複数のＩｔｅｍ要素が含まれ、階層的木構造中の個々のノードの記述を示すために各Ｉｔｅｍ要素が使用されるか、または、前記第２拡張コマンドには１つのＩｔｅｍ要素が含まれ、階層的木構造中の全ノードの記述が１つのＩｔｅｍ要素にカプセル化されることを特徴とする請求項５に記載の方法。
7. 前記第１装置により、前記第２装置から該第２装置の階層的木構造の記述が受信され、前記記述に基づいて、前記階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスが決定される段階が、
   前記第２装置により、自身の階層的木構造の記述が通知として前記第１装置に自発的に送信される段階を含み、
   前記通知は、修正されたＳｙｎｃＭＬプロトコルに従う通知形式であるか、または、ショートメッセージサービス（ＳＭＳ）、ワイヤレス・アプリケーション・プロトコル・プッシュ（ＷＡＰ Ｐｕｓｈ）サービス、セッション開始プロトコル（ＳＩＰ）メッセージ、およびマルチメディアメッセージサービス（ＭＭＳ）のうちのいずれかを介して前記第２装置により送信されることを特徴とする請求項１に記載の方法。
8. 前記フィルタリング条件が、ノードレベルのフィルタリングであり、
   前記同期コマンドが、ノードレベルのフィルタリング条件を伝えるための新たに追加されたサブ要素または属性を含んだＦｉｌｔｅｒ要素を含み、
   前記同期対象情報ノードを指示するために、ＣＧＩ構文が使用されることを特徴とする請求項３に記載の方法。
9. 前記第１装置と前記第２装置との双方で３つのテーブルが構築される段階をさらに有し、
   前記３つのテーブルは、前記同期フェーズで前記同期対象情報ノードの同期を実行するために、前記第１装置および前記第２装置によって使用され、
   前記３つのテーブルは、
   前記階層的木構造中の全データ項目の情報を格納するために使用される第１テーブルと、
   前記階層的木構造中の全フォルダの情報を格納するために使用される第２テーブルと、
   前記階層的木構造中の全データ項目の所属情報を格納するために使用される第３テーブルと
   からなり、
   各データ項目の前記情報は、データ項目のＵＩＤとデータ項目の内容との対応関係を含み、
   各フォルダの前記情報は、フォルダの番号、フォルダの名前、当該フォルダが属する親フォルダ、フォルダの状態、およびそれらの対応関係を含み、
   フォルダの状態は、現存、追加、更新、削除、移動、およびコピーからなり、
   各データ項目の前記所属情報は、データ項目のＵＩＤ、当該データ項目が属する親フォルダ、データ項目の状態、およびそれらの対応関係を含むことを特徴とする請求項１に記載の方法。
10. 前記同期フェーズで、
    前記階層的木構造中のフォルダの同期を実行する際、前記第１装置により、前記第２テーブル中の前記フォルダの状態によって定まる操作タイプを含む同期コマンドが前記第２装置に送信されるとともに、前記第３テーブルに照らして、前記フォルダ下にデータ項目が存在するとの判断がなされた場合に、前記第１装置により、前記第１テーブルに照らして、前記フォルダ下の前記データ項目の内容がさらに決定され、前記データ項目の内容と前記第３テーブル中の前記フォルダ下の前記データ項目の状態によって定まる操作タイプとを含む第２同期コマンドが前記第２装置に送信される段階と、
    前記階層的木構造中のデータ項目の同期を実行する際、前記第１装置により、前記第１テーブルに照らして、前記データ項目の内容が決定され、前記データ項目の内容と前記第３テーブル中の前記データ項目の状態によって定まる操作タイプとを含む同期コマンドが前記第２装置に送信される段階と
    をさらに有し、
    前記第２同期コマンドは、前記データ項目の親フォルダとして前記フォルダを指定することを特徴とする請求項９に記載の方法。
11. 同期の実行のための装置であって、
    同期セッションの同期開始フェーズで、第２装置から該第２装置の階層的木構造の記述を受信し、前記記述に基づいて、前記階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスを決定するように構成された第１モジュールと、
    前記同期開始フェーズで、前記同期対象情報ノードを指定するための同期コマンドを前記第２装置に送信し、前記同期セッションの同期フェーズで、前記第１モジュールから取得したアドレスを用いて、指定された情報ノードを前記第２装置に同期させるように構成された第２モジュールと
    を具備し、
    前記記述は、階層的木構造中の全情報ノードの階層的位置を記述するために使用され、
    前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
    前記情報ノードは、データベース中のデータ項目またはフォルダであり、
    前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
    前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
    前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第２モジュールは、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
    前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第２モジュールは、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とする装置。
12. 複数の装置の同期を実行するシステムであって、
    第１装置と、
    第２装置と
    を具備し、
    同期セッションの同期開始フェーズで、前記第１装置が、前記第２装置から該第２装置の階層的木構造の記述を受信し、前記記述に基づいて、前記階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスを決定し、
    前記同期開始フェーズで、前記第１装置が、前記同期対象情報ノードを指定するための同期コマンドを前記第２装置に送信し、
    前記同期セッションの同期フェーズで、前記第１装置が、前記アドレスを用いて、指定された情報ノードを前記第２装置に同期させ、
    前記記述は、階層的木構造中の全情報ノードの階層的位置を記述するために使用され、
    前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
    前記情報ノードは、データベース中のデータ項目またはフォルダであり、
    前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
    前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
    前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
    前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とするシステム。
13. 複数の装置の同期を実行するシステムであって、
    第１装置と、
    第２装置と
    を具備し、
    同期セッションの同期開始フェーズで、前記第１装置が、前記第２装置の階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスとして、アドレスの指定を行い、指定したアドレスが前記第２装置に存在しない場合、前記第２装置が、当該アドレスにノードを生成し、
    前記同期開始フェーズで、前記第１装置が、前記同期対象情報ノードを指定するための同期コマンドを前記第２装置に送信し、
    前記同期セッションの同期フェーズで、前記第１装置が、前記アドレスを用いて、指定された情報ノードを前記第２装置に同期させ、
    前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
    前記情報ノードは、データベース中のデータ項目またはフォルダであり、
    前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
    前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
    前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
    前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とするシステム。
14. 複数の装置の同期を実行するシステムであって、
    第１装置と、
    第２装置と
    を具備し、
    同期セッションの同期開始フェーズで、前記第１装置が、前記第２装置の階層的木構造状に配置された複数の情報ノードのうちの同期対象情報ノードのアドレスを取得し、
    前記同期開始フェーズで、前記第１装置が、前記同期対象情報ノードを指定するための同期コマンドを前記第２装置に送信し、
    前記同期セッションの同期フェーズで、前記第１装置が、前記アドレスを用いて、指定された情報ノードを前記第２装置に同期させ、
    前記アドレスは、階層的木構造中で情報ノードの位置を特定するために使用される階層的位置情報を含み、
    前記情報ノードは、データベース中のデータ項目またはフォルダであり、
    前記アドレスは、フィルタリング条件として構成され、
    前記同期コマンドは、前記同期対象情報ノードの前記アドレスを含み、
    前記同期コマンドは、再帰的同期を実行するか否かを指示するための再帰的同期識別子をさらに含み、
    前記同期開始フェーズで、前記再帰的同期識別子が再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードを階層的木構造中のサブ木のルートノードとして扱って、前記サブ木の全情報ノードの同期を実行し、
    前記同期開始フェーズで、前記再帰的同期識別子が非再帰的同期の実行を示すとの判断がなされた場合、前記同期フェーズで、前記第１装置は、指定された情報ノードの前記アドレスを用いて、指定された情報ノードだけの同期を実行することを特徴とするシステム。