(57)【特許請求の範囲】
【請求項１】
サーバおよびクライアント間においてオブジェクトを同期化する方法において、
前記サーバまたは前記クライアントのいずれか一方が他方へ、メッセージ部分を含み、同期要求アクティビティおよび同期応答アクティビティを１つメッセージの中にグループ化する同期化メッセージを送信するステップであって、前記同期要求アクティビティはデータを更新するコマンドを含むとともに前記同期応答アクティビティは前のデータ更新コマンドに対する応答を含み、前記メッセージ部分は、
（ａ）前記オブジェクトを同期化する前記同期化メッセージのプロトコルバージョンを表示している前記同期化メッセージのバージョン部分と、
（ｂ）前記サーバおよび前記クライアント間で前記オブジェクトを同期化するためにとられる同期化アクションを示している前記同期化メッセージのコマンド部分と、
（ｃ）同期化アクションエラーを示している前記同期化メッセージの応答部分と、を有すること
を備えることを特徴とするオブジェクトを同期化する方法。
【請求項２】
請求項１に記載の方法において、前記コマンド部分は同期されるオブジェクトを識別するフェッチ部分を含むことを特徴とするオブジェクトを同期化する方法。
【請求項３】
請求項２に記載の方法において、前記フェッチ部分は、前記オブジェクトが同期されるべきただ１つのオブジェクトであること示していることを特徴とするオブジェクトを同期化する方法。
【請求項４】
請求項１に記載の方法において、前記コマンド部分は、同期化するオブジェクトの最大数を示すウィンドウサイズ部分を含むことを特徴とするオブジェクトを同期化する方法。
【請求項５】
請求項１に記載の方法において、前記コマンド部分は、同期化することできるオブジェクトがほかにもあることを示す残余 (more available) 部分含むことを特徴とするオブジェクトを同期化する方法。
【請求項６】
請求項１に記載の方法において、送信する前記ステップに応答して、
前記同期化メッセージを受信した前記他方が、第２の同期化メッセージを送信するステップであって、前記第２の同期化メッセージは、前記クライアントおよび前記サーバ間で第２のコマンドセットを送信するように設定可能であること、
をさらに備えることを特徴とするオブジェクトを同期化する方法。
【請求項７】
請求項６に記載の方法において、前記第２の同期化メッセージは、前記クライアントおよび前記サーバ間でデータを送信するように設定可能であることを特徴とするオブジェクトを同期化する方法。
【請求項８】
請求項１に記載の方法において、前記同期化メッセージは、前記サーバに更新を前記クライアントへ送信させることを要求する変更取得 (get changes) 部分をさらに有することを特徴とするオブジェクトを同期化する方法。
【請求項９】
請求項１に記載の方法において、前記クライアントが前記サーバへ追加のオブジェクトを送るときは、前記同期化メッセージは、前記サーバが前記オブジェクトに関連付けたサーバＩＤを含む応答部分を、さらに有していることを特徴とするオブジェクトを同期化する方法。
【請求項１０】
請求項９に記載の方法において、前記応答部分は、前記クライアントが前記オブジェクトと伴に送信したクライアントＩＤを含むことを特徴とするオブジェクトを同期化する方法。
【請求項１１】
請求項１に記載の方法において、前記オブジェクトは、より多くの同期化されるオブジェクトと関連付けられていることを特徴とするオブジェクトを同期化する方法。
【請求項１２】
請求項１に記載の方法において、前記同期化メッセージは、Ｅメールと関連付けられていることを特徴とするオブジェクトを同期化する方法。
【請求項１３】
請求項１に記載の方法において、前記同期化メッセージは、ハイパテキスト転送プロトコル (HTTP) を使用して送信されることを特徴とするオブジェクトを同期化する方法。
【請求項１４】
請求項１に記載の方法において、前記コマンド部分は、オブジェクト更新データを収めているオブジェクトデータ部分を含むことを特徴とするオブジェクトを同期化する方法。
【請求項１５】
請求項１に記載の方法において、前記同期化メッセージは、前記同期化アクションの状態を示す状態部分をさらに含んでいることを特徴とするオブジェクトを同期化する方法。
【請求項１６】
請求項１に記載の方法において、前記同期化メッセージは、
（ｄ）前記サーバおよび前記クライアント間で第２のオブジェクトを同期化するためにとられる第２の同期化アクションを示す第２のコマンド部分と、
（ｅ）エラーが発生した場合に、前記第２の同期化アクションが正常に完了しなかったことを示す第２の応答部分と、
をさらに有することを特徴とするオブジェクトを同期化する方法。
【請求項１７】
請求項１６に記載の方法において、前記同期化メッセージは、
前記クライアントが前記サーバから情報を要求した場合に、前記要求された情報を収めている情報応答部分、
をさらに有することを特徴とするオブジェクトを同期化する方法。
【請求項１８】
請求項１に記載の方法において、前記同期化メッセージは、
前記クライアントが情報を要求した場合に、前記要求された情報を収めている情報応答部分をさらに含んでいることを特徴とするオブジェクトを同期化する方法。
【請求項１９】
オブジェクトを同期化するシステムにおいて、
モバイルデバイスから同期化メッセージを受信するように構成されたサーバであって、前記同期化メッセージは、同期要求アクティビティおよび同期応答アクティビティを１つの同期化メッセージの中にグループ化する部分を含み、前記同期要求アクティビティはデータを更新するコマンドを含むとともに前記同期応答アクティビティはデータを更新する前のコマンドに対する応答を含み、さらに前記部分は、
（ａ）前記オブジェクトを同期化する前記同期化メッセージのバージョンを表示している前記同期化メッセージのバージョン部分と、
（ｂ）前記オブジェクトを同期化するためにとられる同期化アクションを示している前記同期化メッセージのコマンド部分と、を有すること
を備えることを特徴とするシステム。
【請求項２０】
請求項１９に記載のシステムにおいて、前記サーバは、第２の同期化メッセージを送信するように構成されており、前記第２の同期化メッセージは、
（ｃ）前記オブジェクトを同期化する前記第２の同期化メッセージのバージョンを示している前記第２の同期化メッセージの第２のバージョン部分と、
（ｄ）前記同期化アクションに関連付けられたエラーが発生した場合に、前記エラーを示している応答部分と
を有することを特徴とするシステム。
【請求項２１】
請求項２０に記載のシステムにおいて、エラーが前記同期化アクションと関連付けられていない場合は、前記応答部分は、前記同期化メッセージから省かれていることを特徴とするシステム。
【請求項２２】
請求項２０に記載のシステムにおいて、前記第２の同期化メッセージは、前記モバイルデバイスが情報を要求した場合、前記要求された情報に対する情報応答部分をさらに有することを特徴とするシステム。
【請求項２３】
請求項２１に記載のシステムにおいて、前記第２の同期化メッセージは、前記サーバおよび前記モバイルデバイス間で、第２のオブジェクトを同期化するためにとられる第２の同期化アクションを示すコマンド部分を有することを特徴とするシステム。
【請求項２４】
請求項２２に記載のシステムにおいて、前記サーバは、第２のサーバ上のデータを、前記同期化メッセージを使用して更新するようにさらに構成されていることを特徴とするシステム。
【請求項２５】
請求項２４に記載のシステムにおいて、前記サーバはプロキシサーバであることを特徴とするシステム。
【請求項２６】
請求項２５に記載のシステムにおいて、前記プロキシサーバは、前記モバイルデバイス上のオブジェクトを、前記第２のサーバ上のオブジェクトと関連付けることを特徴とするシステム。
【請求項２７】
データストアおよびコンピュータ実行可能命令を備えたモバイルデバイスにおいて、前記コンピュータ実行可能命令は、
同期要求アクティビティおよび同期応答アクティビティを１つのメッセージの中にグループ化するメッセージ部分を含む同期化メッセージをフォーマットするステップであって、前記同期要求アクティビティはデータを更新するコマンドを含むとともに前記同期応答アクティビティはデータを更新する前のコマンドに対する応答を含み、前記メッセージ部分は、
同期化プロトコルのバージョンを示しているバージョンＩＤ部分と、
サーバ上にあるデータを前記データストア上のデータと同期化する変更を前記サーバに定義するコマンド部分とを有することと、
前記同期化メッセージを前記サーバへ送信するステップと
を実行することを特徴とするモバイルデバイス。
【請求項２８】
請求項２７に記載のモバイルデバイスにおいて、前記同期化メッセージは、エラーが発生した場合に、前記更新が正常に完了しなかったことを示す応答部分をさらに有することを特徴とするモバイルデバイス。
【請求項２９】
請求項２８に記載のモバイルデバイスにおいて、前記同期化メッセージは、前記モバイルデバイスが情報を要求した場合、前記要求された情報を収めている情報応答部分をさらに有することを特徴とするモバイルデバイス。
【請求項３０】
請求項２８に記載のモバイルデバイスにおいて、前記コマンド部分は、前記モバイルデバイスを更新する、前記サーバ上にあるオブジェクトを識別するフェッチ部分を有することを特徴とするモバイルデバイス。
【請求項３１】
請求項２８に記載のモバイルデバイスにおいて、前記コマンド部分は、前記サーバが同期化するオブジェクトの最大数を示すウィンドウサイズ部分を有することを特徴とするモバイルデバイス。
【請求項３２】
データストアおよびコンピュータ実行可能命令を備えたサーバにおいて、前記コンピュータ実行可能命令は、
メッセージ部分を含み、同期要求アクティビティおよび同期応答アクティビティを１つのメッセージの中にグループ化する更新同期化メッセージを受信するステップであって、前記同期要求アクティビティはデータを更新する第１のコマンドを含むとともに前記同期応答アクティビティはデータを更新する前のコマンドに対する応答を含み、前記メッセージ部分は、
同期化プロトコルのバージョンを示しているバージョンＩＤ部分と、
モバイルデバイス上にあるデータを前記データストア上のデータと同期化する変更を前記サーバに定義する第１のコマンド部分とを有することと、
メッセージ部分を含み、同期要求アクティビティおよび同期応答アクティビティを１つのメッセージの中にグループ化する応答同期化メッセージを送信するステップであって、前記同期要求アクティビティはデータを更新する第２のコマンドを含むとともに前記同期応答アクティビティはデータを更新する前記第１のコマンドに対する応答を含み、前記メッセージ部分は、
同期化プロトコルのバージョンを示している第２のバージョンＩＤ部分と、
前記モバイルデバイス上にあるデータを前記データストア上のデータと同期化する変更を前記モバイルデバイスに定義する第２のコマンド部分とを有することと、
前記更新同期化メッセージを処理している途中でエラーが発生した場合に、同期化が正常に完了しなかったことを示す応答部分と、を有することと
を実行することを特徴とするサーバ。
【請求項３３】
請求項３２に記載のサーバにおいて、
前記更新同期化メッセージを構文解析するパーサと、
前記応答同期化メッセージを生成するジェネレータと
をさらに備えることを特徴とするサーバ。
【請求項３４】
請求項３３に記載のサーバにおいて、前記更新同期化メッセージと前記応答同期化メッセージの各々は、マークアップ言語を含んでいることを特徴とするサーバ。
【請求項３５】
請求項３４に記載のサーバにおいて、前記マークアップ言語は拡張可能マークアップ言語 (XML) を含むことを特徴とするサーバ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的には、コンピュータ実行可能ソフトウェアに関し、さらに具体的にはエレクトロニクスデバイスを同期化することに関する。
【０００２】
【従来の技術】
パーソナルデジタルデータの同期化に対する関心は、モバイルデバイスが出現して以来増加している。ある初期方法では、パーソナルデータを同期化するためには、ユーザは、パーソナルコンピュータ (personal computer  PC) 上でデータを更新する必要があった。サーバとのデータの同期化は、PCが行っていた。オフィスから外出したときモバイルデバイスを更新するには、ユーザは、モバイルデバイス上で手作業によってデータを再入力する必要があった。
【０００３】
モバイルデバイスマーケットが熟成するのに伴い、データを同期化するために主従複製システム (master-slave replication system) が開発された。主従複製システムでは、マスタデバイスであるPCからデータを受け取り、それを複製してスレーブデバイスであるモバイルデバイスに送っていた。通常、この方法によると、データをPCに入力し、そのあと、データをモバイルデバイスに手作業で再入力する必要がなくなった。しかし、ユーザは、双方のデバイスからデータを再入力する必要が時々あった。例えば、ユーザがオフィスから外出し、モバイルデバイス上で情報を更新する必要が起こったとき、ユーザは、データをモバイルデバイスに手作業で入力することもあり得た。しかし、モバイルデバイス上で行った変更がオーバライト（重ね書き）されるのを防止するために、同じデータをPCに再入力してからPCとの同期をとる必要があった。
【０００４】
最後に、両方向同期化方法 (two-way synchronization technique) が開発された。この方法を使用すると、ユーザは、PCからでも、モバイルデバイスからでも情報を更新することが可能であった。そのあと、データを同期化するために、２つのデバイスが接続され、情報がやりとりされていた。この方法は、デバイスが、ワイヤレスネットワークやセルラネットワークなどの、高レイテンシ (high latency)、低バンド幅、および/または低信頼度のネットワークによって分離されるまでは、一般的に満足されていた。
【０００５】
ワイヤレスネットワークでは、コネクションが失われるリスクは、非ワイヤレスシステムよりも数倍に大である。いくつかの同期化方法では、起こり得る中断に対処するために、メッセージが受信される間に、いくつかの個所で肯定応答 (acknowledgement) を送信するようにしている。しかし、複数の肯定応答を送信すると、セルラネットワークでは別の問題が起こっている。代表例として、セルラネットワークは、レイテンシが高くなっている。各送信は、このレイテンシの影響を受けている。従って、肯定応答を使用すると、総同期化時間が増加し、例えば、低信頼度のネットワークでは、中断が起こり得る可能性が大になっている。
【０００６】
さらに、セルラネットワークは、バンド幅が比較的低であることが多い。セルラネットワーク上のPCとモバイルデバイス間で比較的少数のオブジェクトを同期化するには、数分かかることがある。多数のオブジェクトを同期化するには、数時間かかることがある。この問題は、概して、ローカルエリアネットワークに直接に接続されたデバイスやローカルエリアネットワーク経由で接続されたデバイスでは、見られない。
【０００７】
【発明が解決しようとする課題】
従って、この分野では、高レイテンシ、低バンド幅、および/または低信頼度のネットワークで接続されたデバイス上でデータを同期化する方法が要望されている。
【０００８】
【課題を解決するための手段】
本発明は、高レイテンシ、低バンド幅、および/または低信頼度のネットワークで接続されていても、それらのデバイスを同期化するためのシステムおよび方法を提供する。
【０００９】
本発明によれば、複数の同期化アクティビティに対する応答を単一のメッセージに入れることによって、複数の肯定応答のレイテンシを防止するプロトコルが提供される。要求とその前の要求に対する応答は１つにまとめて、１つのメッセージに入れることを可能にしている。すべてのオブジェクトを同期化しなくても、選択したオブジェクトだけを同期化することを可能にしている。ウィンドウサイズは、単一のトランザクション期間に同期化されるオブジェクトの数を制限するように設定することができる。このプロトコルは、サーバからでも、モバイルデバイスからでも、同期化を開始できる設計になっている。
【００１０】
本発明の一側面（態様）では、プロトコルは、オブジェクト更新要求に対する応答を１つのグループにまとめている。応答を１つのグループにまとめると、各更新要求に応答するときのレイテンシの若干が防止される。
【００１１】
本発明の別の側面では、プロトコルは、更新に対する応答を１つのグループにまとめ、１つのグループにまとめられたオブジェクト更新要求と一緒に送信することを可能にしている。従って、同期化期間に複数のメッセージを送信するのではなく、１つのメッセージでエラーを報告し、更新を送信し、要求し、応答することを可能にしている。このようにすると、同期化のレイテンシが低減し、必要とされるバンド幅が大幅に減少される。
【００１２】
本発明の別の側面では、このプロトコルにより、モバイルデバイスは、特定のオブジェクトまたはフォルダをサーバから取り出すことを、他のアイテムを同期化することなく要求できるようにしている。例えば、ユーザは、あるＥメールからサブジェクトライン（subject line：件名、タイトル）を得ると、そのＥメールの残り部分を取得したい場合がある。ユーザにすべてのオブジェクトの同期化を完了させなくても、このプロトコルによれば、モバイルデバイスは、Ｅメールの残り部分だけをサーバに要求し、Ｅメールに同期化済みのマークをサーバに付けさせることを要求することができる。
【００１３】
本発明のさらに別の側面では、プロトコルは、モバイルデバイスが変更をサーバに送信し、変更を送り返さないことを要求することを可能にしている。このようにすると、ユーザは、他のアイテムが同期化されている間ユーザを待たせることなく、Ｅメールを同期化し、送信することができる。
【００１４】
本発明の別の側面では、プロトコルは、サーバから送られてくる更新のウィンドウサイズを設定することを可能にしている。例えば、ユーザは、任意の特定トランザクションで更新のためにサーバから送られるオブジェクトの数に制限を設けたい場合がある。このプロトコルによると、モバイルデバイスは、更新されるオブジェクトの数に制限を設けて、その数のオブジェクトだけを送信することを要求することができる。このようにすると、ユーザまたはモバイルデバイスに置かれているアルゴリズムは、追加のオブジェクトをいつ更新すべきかを判断することができる。ウィンドウサイズの変更は、例えば、コネクション条件に適応させるためにも使用できる。比較的小さなウィンドウサイズは、コネクションの信頼度が低いとき、コネクションが壊れたとき再送信されるデータを少なくするために使用することができる。これとは逆に、比較的大きなウィンドウサイズは、コネクションの信頼度が高いとき、複数の伝送のオーバヘッドを減少して同期化を行うために使用することができる。
【００１５】
本発明の別の側面では、プロトコルは、更新できるオブジェクトがほかにもあることを、サーバが通知できるようにしている。例えば、モバイルデバイスによって設定されたウィンドウサイズ内で送信できる以上のオブジェクトがサーバに存在する場合がある。このプロトコルによれば、ウィンドウサイズ内で送信できるオブジェクトを送信したあと、サーバは、更新できるオブジェクトがほかにもあることを通知できるようにしている。
【００１６】
本発明の別の側面では、プロトコルは、失敗したオブジェクト同期化は報告するが、成功したオブジェクト同期化は報告しないことによって、伝送時に追加のバンド幅が使用されるのを回避している。
【００１７】
本発明の別の側面では、プロトコルは、同期化メッセージをバンド外 (out of band) で送信することを可能にしている。すなわち、サーバとモバイルデバイスは、プロトコルを使用しないで一部のオブジェクトを同期化することを可能にしている。例えば、サーバは、プロトコルの外で緊急メッセージをモバイルデバイスに送信することができる。つまり、プロトコルに頼らなくても、同期化メッセージが送信されるようにしている。
【００１８】
本発明は、セルラネットワーク、Ｅメール、ダイレクトコネクション、インターネット (the Internet)、http、ftp、または他の伝送プロトコルを使用してデバイスを同期化するために使用できる。本発明は伝送プロトコルの上に「上乗せ(ride)」できるので、本発明は、その上を走行するプロトコルのセキュリティを利用することが可能になっている。プロトコルは拡張可能であるので、デバイスは、相互に通信するとき使用されるデータまたは追加コマンドを埋め込むことを可能にしている。
【００１９】
【発明の実施の形態】
本発明は、エレクトロニックデバイスの同期化を容易化する構造と方法を提供する。本発明で、中でも特に開示されているのは、低信頼度、低バンド幅、および/または高レイテンシのネットワークを利用してデバイスを同期化することを目的としたプロトコルである。このプロトコルによれば、複数のコマンドと応答を１つのグループにまとめ、１つのメッセージに入れることを可能にしている。また、このプロトコルによると、同期化アクティビティ期間に他のオブジェクトを同期化することなく、単一のオブジェクトをフェッチ（fetch）することができる。プロトコルは拡張可能であるので、このプロトコルを使用するアプリケーションは、相互に通信するために追加のコマンドを埋め込む（はめ込む）ことができる。
【００２０】
以下では、最初に、上記特徴を備えた例示プロトコルについて説明し、そのあとで、このプロトコルを使用するシステムと方法について説明することにする。
【００２１】
例示プロトコル
本発明の一例示実施形態では、データを同期化するプロトコルは、同期化するデバイス間で送信されることを目的とした一連の拡張可能マークアップ言語 (extensible markup language  XML) ドキュメントとして実現されている。以下では、最初に、プロトコルを説明する際に使用される用語とシンタックスの説明が示され、そのあと、プロトコルの構造が説明されている。
【００２２】
以下に説明するシンタックスのフォーマットでは、下記の例に示すように、その後にコロンが置かれているタグペアと別のタグペアがリストされている。
【００２３】
<Add>...</Add> : <Commands>...</Commands>
タグペアが別のタグペアと一緒にリストされているときは、そのことは、第１タグペアが第２タグペアからの次のレベルにあるとき、その説明が適用されることを示している。そうでないときは、別段の断りがない限り、その説明はタグペアが現れた個所で適用されている。以下の説明では、次のレベルとは、そのタグが、上位レベルのタグの内側にネストされた１つまたは２つ以上のタグの１つとして含まれていることを意味している。例えば、次のXMLドキュメントでは、
0003987396.tif 000002
【００２４】
<Version>タグと<Collections>タグは、<Sync>タグからの次のレベルに置かれている。<Collection>タグは、<Collections>タグからの次のレベルに置かれているが、<Sync>タグと<Collections>タグのどちらに対しても次のレベルに置かれていない。なお、上に示す例示XMLドキュメントのインデント（字下げ）は、XMLドキュメントを正しく作るためには必須でない。上の例は次のように書いても、
<Sync><Version> 0 . 2< /Version><Collections ><Collection>...
</Collection></Collections></Sync>
依然として有効なXMLドキュメントである。
【００２５】
タグペアに続いて、そのタグペアが出現することが許される個数が指定されている。このことは、本発明のこの例示実施形態では、出現個数に関する情報が適用されることを意味している。他の実施形態では、設計上の考慮事項や他の要因に応じて、タグペアは他の個数にすることが許容されている。
【００２６】
許容される出現個数に続く説明では、タグペアの使い方の例が示されている。そこでの説明と例は網羅的なものではなく、説明の便宜上示されたものである。
【００２７】
説明に続いて、カレントタグからの次のレベルに現れることができるタグのリスト（または無タグのリスト）が示されている。このタグリストは、本発明のこの例示実施形態では、リストされたタグペアが次のレベルに現れることができることを意味している。他の実施形態では、他のタグペアを許すことが可能であり、リストされたタグペアの一部が除外されていても、本発明の精神と範囲から逸脱するものではない。
【００２８】
以上から理解されるように、多くのタグ名を別の名前で置き換えても、機能的に同等である。さらに、本発明の精神と範囲から逸脱しない限り、タグを並べ替えたり、レベルを追加または削除したりすることも可能である。以上の紹介と共に、以下には、タグと説明が記載されている。
【００２９】
<Sync>...</Sync>
許される個数：同期化XMLドキュメント当たり１個
説明：<Sync>タグは、sync XMLドキュメントの始まりを示している。言い換えれば、パーサ (parser) が<Sync>タグを見つけたとき、このことは、<Sync>タグと</Sync>タグの間に置かれているものはすべて、パーサにsyncメッセージとして扱わせることを意味している。<Sync>...</Sync>タグは、Ｅメール、ftpデータ、あるコンピュータから別のコンピュータに渡されるファイル、httpデータなどを含む、どのタイプのドキュメントにも埋め込むことが可能である。同期化を行うシステムは、受信した各コミュニケーションをスキャンして、<Sync>...</Sync>タグペアが現れたかどうかを判断することができる。<Sync>...</Sync>タグペアが現れたときは、システムは、<Sync>...</Sync>タグペアで定義されたXMLドキュメントを抽出し、それを同期化エンジンに渡すことができる。
次のXMLレベルにネスト（nest：入れ子にする）できるタグ：
<Version>...</Version>
<Status>...</Status>
<Collections>...</Collections>
【００３０】
<Version>...</Version>
許される個数：１個
説明：このタグを使用すると、プロトコルを使用する２つのアプリケーションは、各アプリケーションが使用しているプロトコルのバージョンを相互に送信することができる。プロトコルは、バージョンが同じであることを要求していない。むしろ、バージョンが不一致の場合、いつ進めるか、進めるかどうか、およびどのように進めるかの判断は、各アプリケーションに任せている。バージョンが不一致のとき、アプリケーションは、他のアプリケーションと通信するとき、例えば、旧バージョンのプロトコルを使用するかどうかを判断することができる。  次のXMLレベルにネストできるタグ：なし。
【００３１】
<Collection>...</Collection>
許される個数：１個
説明：<Collections>タグは、１つまたは２つ以上の<Collections>...</Collections>タグペアがあとに続くことを示している。ある意味では、<Collections>...</Collections>タグペアは、一連のコレクション情報を「ラップアラウンド(wrap around)」する。
次のXMLレベルにネストできるタグ：
<Collection>...</Collection>
【００３２】
<Collection>...</Collection>
許される個数：１個−無制限
説明：<Collection>...</Collection>タグペアは、コマンド、応答、および関連情報のコレクションをラップアラウンドする。代表例として、<Collection>...</Collection>タグペアは、受信側に送信される作業および/または応答のバッチを含んでいる。<Collection>...</Collection>タグペアは、カレンダ、連絡先などの、あるオブジェクトタイプに関係する更新の集まりを、１つの要求にバッチするために使用される。このプロトコルでは、１つの要求で送信できる<Collection>...</Collection>タグペアの個数は無制限になっている。
次のXMLレベルにネストできるタグ：
<Class>. . .</Class>
<SyncKey>. . .</SyncKey>
<CollectionId>. . .</CollectionId>
<Options>. . .</Options>
<Commands>. . .</Commands>
<Responses> . . . </Responses>
<Status>. . . </Status>
<GetChanges/>
<WindowSize>. . . </WindowSize>
<MoreAvailable/>
【００３３】
<Class>...</Class>
許される個数：コレクションごとに１個
説明：<Class>...</Class>タグペアは、同期化が必要であるオブジェクトクラスのタイプを記述しているデータを収めている。異種オブジェクトは異なる特性をもつことができる。例えば、カレンダにおけるアポイントメントは、開始時間と終了時間を属性としてもっているのに対し、アドレスブックにおける連絡先は、電話番号を属性としてもっている。このクラスタグを使用すると、プロトコルは、なにを同期化するのかに関して処理アプリケーションに通知するために使用できる。
次のXMLレベルにネストできるタグ：なし
【００３４】
<SyncKey>...</SyncKey>
許される個数：コレクションごとに１個
説明：<SyncKey>...</SyncKey>タグペアの間に置かれる同期化キーは、ウォータマーク (watermark) と呼ばれることがある。この同期化キーに基づいて、アプリケーションは、例えば、再送信するのは応答であるか、要求であるかを判断することができる。例えば、クライアントは、同期化データおよびコマンドと一緒に、１の同期化キーを送信する場合がある。サーバはこの同期化キーを受信し、コマンドとデータを処理し、成功したことを示す応答をクライアントに送信する。この応答は、例えば、コネクションが失われると、クライアントに到着しないことがある。ある時間期間待ってから、クライアントはデータを再送信し、１の同期化キーを再使用する場合がある。同期化キーは１であるので、サーバは、クライアントがデータを再送信しようとしていると判断することができ、オリジナルメッセージで処理されたアイテムがあるかをチェックすることができる。他方、クライアントが成功したことを示す応答を受信した場合は、２の同期化キーを使用して新メッセージを送信する場合がある。同期化キーは異なっているので、サーバは、そのメッセージの中の情報は新しいものであると判断することができる。
次のXMLレベルにネストできるタグ：なし
【００３５】
<CollectionId>...</CollectionId>
許される個数：コレクションごとに１個
説明：<CollectionId>...</CollectionId>タグペアの間に置かれるコレクションIDは、コレクション、フォルダ、または個別オブジェクトを特定するために使用することができる。例えば、コレクションIDは、ユーザのメールシステムのアウトボックス（送信箱）を特定することができるが、アウトボックスに入っているシングルメッセージを特定することもできる。コレクションIDの指定がないときは、同期化されるデータおよびプロトコルを使用するシステムに応じて、「デフォルトフォルダ」が使用されることがある。
次のXMLレベルにネストできるタグ：なし
【００３６】
<Options>...</Options>
許される個数：コレクションごとに１個
<Options>...</Options>タグペアは、プロトコルによって無視され、サーバ側またはクライアント側のアプリケーションに送られるデータおよび/またはコマンドを取り囲むために使用することができる。プロトコルは、開始<Options>タグと終了</Options>タグの間にどのようなものでも置ける設計になっている。例えば、アプリケーションは、ピクチャを別のアプリケーションに送信したい場合がある。ピクチャをJPEGフォーマットで表しているバイナリデータは、それを<Options>...</Options>タグペアで囲むと送信することが可能になる。別の方法として、追加のタグペアとデータを<Options>...</Options>タグペアの間に置くことにより、アプリケーション固有の方法でプロトコルを「擬似拡張(pseudo-expanded)」することも可能である。例えば、アプリケーションは、syncオペレーション期間にサーバからクライアントに送られるEメールにフィルタを入れて、ある種のサブジェクトラインをもつEメールだけが送信されるように要求することができる。別の方法として、アプリケーションは、各Eメールの最初の1000文字だけが、syncオペレーション期間にサーバからクライアントに送信されるように、Eメールに一定の切り捨て制限 (truncation limit) を設けることを要求することも可能である。サーバとクライアントに固有のまったく新しいプロトコルを<Options>...</Options>タグペアの間に置いても、同期化プロトコルに障害が起こることはない。
次のXMLレベルにネストできるタグ：任意。しかし、個別的には、プロトコルによって認識されないものがある。
【００３７】
<Commands>...</Commands>
許される個数：コレクションごとに無制限
<Commands>...</Commands>タグペアは、サーバ側またはクライアント側のアプリケーションに送信されるコマンドを取り囲むために使用される。<Commands>タグは、その後に続くものが、作用の対象となる要求であることを示している。例えば、追加 (add)、削除 (delete)、または変更 (change) コマンドは、関連データと一緒に、<Commands>...</Commands>タグペアの間に置くことができる。プロトコルは、<Commands>...</Commands>タグペアがコミュニケーションの中に存在することを要求していない。例えば、クライアントは、サーバがどの更新も送信しないことを要求することができ（<GetChanges/>タグを送信しないことにより）、その場合、サーバは、<Commands>...</Commands>タグペアの間に置かれている、どのコマンドの送信も無視することができる。しかし、<Commands>...</Commands>タグペアが存在するときは、少なくとも１つのコマンドがその間に置かれている必要がある。
次のXMLレベルにネストできるタグ：
<Add>...</Add>
<Delete>...</Delete>
<Change>...</Change>
<Fetch>...</Fetch>
なお、上記タグペアは、少なくとも１つが次のXMLレベルにネストされている必要がある。
【００３８】
<Responses>...</Responses>
許される個数：コレクションごとに無制限
<Responses>...</Responses>タグペアは、前のメッセージで送信されたコマンドに対する応答を取り囲むために使用される。プロトコルは、前のメッセージのコマンドを処理している途中で障害が発生したとき、あるいはFetchコマンドのように、応答を要求する要求が行われたとき、応答を送信する設計になっている。コマンドに対する応答が送信されないときは、成功したものとみなされる。応答は、要求IDとステータスパラメータを含んでいるのが一般である。例えば、コマンドは、特定のIDで特定されたオブジェクトをサーバに削除させることを要求することができる。例えば、無効なIDが指定されたときのように、サーバが特定されたオブジェクトを見つけることができないときは、サーバはその応答として、オブジェクトが見つからなかったとの情報を<Responses>...</Responses>タグペアで囲んで送信することができる。
【００３９】
プロトコルは、<Responses>...</Responses>タグペアがコミュニケーションに存在することを要求していない。例えば、サーバは、クライアントが要求するすべてのコマンドを、エラーなしで正しく実行することができ、その場合、サーバは、<Responses>...</Responses>タグペアの間に置かれている応答の送信を無視することができる。しかし、<Responses>...</Responses>タグペアが存在するときは、前の要求に対する応答が少なくとも１つ含まれている必要がある。
次のXMLレベルにネストできるタグ：
<Add>...</Add>
<Delete>...</Delete>
<Change>...</Change>
<Fetch>...</Fetch>
なお、上記タグペアは、少なくとも１つが次のXMLレベルにネスとされている必要がある。
【００４０】
<GetChanges/>
許される個数：コレクションごとに１個
説明：<GetChanges/>タグは、変更が要求側に送り返されることを示す空タグ(empty tag) である。一般的には、クライアントは、更新したいデータをサーバに送信し、更新されたデータがクライアントに送り返されることを要求する。更新されたデータをサーバに要求するには、クライアントは<GetChanges/>タグを使用することができる。このタグを使用しないときは、サーバは、クライアントから送られてきた更新に応答するとき、更新されたデータを送り返さないはずである。
【００４１】
プロトコルは、サーバではなく、クライアントが更新を要求する<GetChanges/>タグを送信する設計になっている。このようにすると、クライアント側のユーザは、サーバからの変更がいつクライアントに送信されるかを指示することができる。例えば、ワイヤレスネットワークを利用してサーバに送られるデータを同期化するモバイルデバイスを使用するユーザは、モバイルデバイスがすべてのデータ更新をサーバに送ることを要求する機能を、サーバに持たせないことを望む場合がある。むしろ、ユーザは、データ更新をいつサーバに送るかの制御権をユーザがもち、ユーザの都合のよいときにやり取りを行うことを望んでいるのが代表的である。
【００４２】
さらに、プロトコルは、クライアントがあるセッションで複数の要求をサブミットするとき、最後の要求の中に<GetChanges/>タグを組み入れる設計になっている。このようにすると、サーバはすべての要求を処理してから更新を送り返すことが可能になる。
次のXMLレベルにネストできるタグ：なし
【００４３】
<WindowSize>...</WindowSize>
許される個数：コレクションごとに１個
<WindowSize>...</WindowSize>タグペアは、サーバからクライアントに送られる更新の数を制限するために使用できる値を収めている。例えば、サーバは、最後の同期化以後、ユーザに対する新Eメールをいくつか受信していることがある。すべての新Eメールがサーバによって送信されるときは、ユーザは、サーバが更新をユーザのモバイルデバイスに送信する間、比較的長時間待たされることがある。このプロトコルを使用すると、ユーザ（またはユーザのモバイルデバイス）は、各コレクションの同期化ごとにサーバからの更新をいくつ送信させるかを、各コレクションに見合うウィンドウサイズを選択することによって指定することができる。サーバは、指定された数の更新をユーザのモバイルデバイスに送信し、コレクションには更新がまだ残っていることを、<MoreAvailable/>タグを送ることによって指示することができる。これについては、以下で詳しく説明する。
【００４４】
さらに、信号損失が間欠的にデバイスに起こっているときは、そのデバイスは、ウィンドウサイズをダイナミックに縮小することができる。そのようにすると、伝送の途中で信号が損失したとき、再送の必要があるデータ量は比較的少量で済むことになる。
次のXMLレベルにネストできるタグ：なし
【００４５】
<MoreAvailable/>
許される個数：コレクションごとに１個
<MoreAvailable/>タグは、同期化のための更新がまだ残っていることを示している。<MoreAvailable/>タグは、同期化の対象となるコレクションで送信できる更新の数に<WindowSize>...</WindowSize>タグペアが制限を設けていたとき送信することができる。例えば、クライアントに対して更新の必要のある10個のEメールがサーバ側にあって、クライアントがウィンドウサイズを４に設定して同期化に関与していた場合、サーバは４つのEメールと<MoreAvailable/>タグを送信して、同期化の対象となるEメールがまだサーバ側に残っていることを指示することができる。
次のXMLレベルにネストできるタグ：なし
【００４６】
<Add>...</Add> : <Commands>...</Commands>
許される個数：無制限
<Commands>...</Commands>タグペアの間に置かれる<Add>...</Add>タグペアは、オブジェクトを追加するために使用される。<Add>...</Add>タグペアの間に置かれるadd情報は、オブジェクトとそのオブジェクトと関連付けようとするデータを示している。例えば、クライアントは、サーバの連絡先データ情報を更新するために情報を送信する場合がある。これを行うには、クライアントは、100のように、連絡先を特定する整数と、John Doeのように連絡先のファーストネームとラストネームを、<Add>...</Add>タグペアの間に置くことができる。同様に、サーバが新オブジェクトをクライアントに送信するときは、オブジェクトとそのオブジェクトに関連付けようとするデータを示す情報が送信される。<Add>...</Add>タグペアは、以下で説明するように、<Responses>...</Responses>タグペアの間に置くことも可能である。
次のXMLレベルにネストできるタグ：
<ClientId>...</ClientId>
<ServerId>...</ServerId>
<ApplicationData>...</ApplicationData>
【００４７】
<Delete>...</Delete> : <Commands>...</Commands>
許される個数：無制限
<Commands>...</Commands>タグペアの間に置かれる<Delete>...</Delete>タグペアは、オブジェクトを削除するために使用される。<Delete>...</Delete>タグペアの間に置かれるdelete情報は、削除しようとするオブジェクトを特定している。例えば、クライアントは、サーバの連絡先データ情報を更新するためにdelete情報を送信する場合がある。これを行うには、100のように、削除しようとする連絡先 (John Doe) を示す整数を、<Delete>...</Delete>タグペアの間に置くことができる。同様に、クライアントからオブジェクトを削除するには、サーバは、削除しようとするオブジェクトを示す情報を送信する。<Delete>...</Delete>タグペアは、以下で説明するように、<Responses>...</Responses>タグペアの間に置くことも可能である。
次のXMLレベルにネストできるタグ：
<ServerID>...</ServerID>
【００４８】
<Change>...</Change> : <Commands>...</Commands>
許される個数：無制限
<Commands>...</Commands>タグペアの間に置かれる<Change>...</Change>タグペアは、オブジェクトを追加するために使用される。<Change>...</Change>タグペアの間に置かれるChange情報は、オブジェクトとそのオブジェクト内で変更しようとするデータを示している。例えば、クライアントは、サーバの連絡先データ情報を更新するために情報を送信する場合がある。これを行うには、クライアントは、100のように、連絡先 (John Doe) を特定する整数と、Janeのように、ファーストネームの変更を、<Change>...</Change>タグペアの間に置くことができる。同様に、サーバがオブジェクトの更新をクライアントに送信するときは、そのオブジェクトと、そのオプジェクトに関連するどのデータを変更しようとするのかを示す情報が送信される。<Change>...</Change>タグペアは、以下で説明するように、<Responses>...</Responses>タグペアの間に置くことも可能である。
次のXMLレベルにネストできるタグ：
<ServerId>...</ServerId>
<ApplicationData>...</ApplicationData>
【００４９】
<Fetch>...</Fetch> : <Commands>...</Commands>
fetchタグは、特定のオブジェクトを取得する要求を示している。例えば、ユーザは、Ｅメールのサブジェクトラインだけを取り出すようにモバイルデバイスを構成することができる。同期化を行うとき、モバイルデバイスは、例えば、<Options><GetSubjectsOnly/></Options>シンタックスを通して、Ｅメールのサブジェクトだけをサーバに送信させることを要求することができる。（なお、このプロトコルでは、<Options>...</Options>タグペアの間に置かれているものは無視されるが、<Options>...</Options>タグペアの個所で前述したように、このペアの間に置かれているデータをアプリケーションに渡すことでプロトコルを「拡張」することができる。Ｅメールのサブジェクトラインを読んでいるユーザは、他のＥメールが同期化されるのを待つことなく、あるサブジェクトに関連するＥメール全体を取り出すことを望む場合がある。<Fetch>...</Fetch>タグペアの使用を通して該当のオブジェクトを要求し、<GetChanges/>タグを省くことにより、モバイルデバイスは、サーバから他のオブジェクトを送信させることなく、１つのオブジェクトを取り出させることができる。
次のXMLレベルにネストできるタグ：
<ServerId>...</ServerId>
【００５０】
<Add>...</Add> : <Responses>...</Responses>
<Responses>...</Responses>タグペアの間に置かれる<Add>...</Add>タグペアは、オブジェクトを追加したことを確認し、追加したオブジェクトのサーバIDについてクライアントを更新するために使用される。例えば、クライアントは、サーバの連絡先データ情報を更新するために情報を送信する場合がある。これを行うには、クライアントは、100のように、連絡先を特定する整数と、John Doeのように、連絡先のファーストネームとラストネームを、<Add>...</Add>タグペアの間に置くことができる。サーバが追加更新に応答するときは、例えば、100のようなクライアントID、新オブジェクトに割り当てられたサーバID、および更新のステータスを送信する。このようにすると、クライアントは、サーバによって割り当てられたIDを使用して、オブジェクトに対する別の更新を行うことができる。<Add>...</Add>タグペアは、上述したように、<Commands>...</Commands>タグペアの間に置くことも可能である。
次のXMLレベルにネストできるタグ：
<ClientId>...</ClientId>
<ServerId>...</ServerId>
<Status>...</Status>
【００５１】
<Delete>...</Delete> : <Responses>...</Responses>
許される個数：無制限
<Responses>...</Responses>タグペアの間に置かれる<Delete>...</Delete>タグペアは、オブジェクトを削除するステータスを報告するために使用することができる。<Delete>...</Delete>タグペアの間に置かれるdelete情報は、削除しようとするオブジェクトを特定している。例えば、クライアントは、サーバの連絡先データ情報を更新するためにdelete情報を送信する場合がある。これを行うには、クライアントは、100のように、削除しようとする連絡先 (John Doe) を特定する整数を、<Delete>...</Delete>タグペアの間に置くことができる。例えば、100で特定された連絡先オブジェクトがサーバ側に存在しないため、削除が失敗したときは、サーバは、<Delete>...</Delete>タグペアとその間に置かれた関連失敗情報を使用して、削除に応答することができる。
次のXMLレベルにネストできるタグ：
<ServerID>...</ServerID>
<Status>...</Status>
【００５２】
<Change>...</Change> : <Responses>...</Responses>
許される個数：無制限
<Responses>...</Responses>タグペアの間に置かれる<Change>...</Change>タグペアは、オブジェクトを追加したステータスを報告するために使用される。例えば、クライアントは、サーバの連絡先データ情報を更新するために情報を送信する場合がある。これを行うには、クライアントは、100のように、連絡先 (John Doe) を特定する整数と、Janeのように、ファーストネームの変更を<Change>...</Change>タグペアの間に置くことができる。データを変更している途中でエラーが起こった場合、例えば、IDに関連する連絡先が見つからない場合、サーバは、例えば、100のように、受信したIDと、IDが見つからなかったことを示すエラーコードを、クライアントに送信される<Change>...</Change>タグペアの間に置くことによって応答することができる。<Change>...</Change>タグペアは、上述したように、<Commands>...</Commands>タグペアの間に置くことも可能である。
次のXMLレベルにネストできるタグ：
<ServerID>...</ServerID>
<Status>...</Status>
【００５３】
<Fetch>...</Fetch> : <Responses>...</Responses>
許される個数：無制限
<Responses>...</Responses>タグペアの間に置かれる<Fetch>...</Fetch>タグペアは、<Commands>...</Commands>タグペアの間において出された<Fetch>コマンドで要求されたオブジェクトに関連するステータスとデータを送信するために使用される。例えば、Eメールのサブジェクトラインを読んでいるユーザは、他のEメールが同期化されるのを待つことなく、あるサブジェクトに関連するEメール全体を取り出したい場合がある。ユーザが使用しているクライアントは、<Fetch>...</Fetch>タグペアを、オブジェクトを特定している<Commands>...</Commands>タグペアの間に置いて送信することによって、Eメール全体をユーザに送信することをサーバに要求することができる。サーバは、例えば、要求されたオブジェクトが見つからなかった場合、エラーステータスコードを送信することによって応答することができる。別の方法として、サーバは、データを<Fetch>...</Fetch>タグペアの間に置いて送信することにより、要求情報を送信することも可能であり、この場合、データは要求されたオブジェクトとそのオブジェクトに関連するデータを示している。
次のXMLレベルにネストできるタグ：
<ServerID>...</ServerID>
<Status>...</Status>
<ApplicationData>...</ApplicationData>
【００５４】
<ClientId>...</ClientId>
許される個数：<Add>...</Add>タグペアごとに１個
<ClientId>...</ClientId>タグペアの間に置かれる情報は、クライアント側の特定オブジェクトを特定している。オブジェクトがサーバ側にストアされているときは、サーバは、そのオブジェクトに異なるオブジェクトIDを関連付けている場合がある。クライアント、サーバ、またはクライアントとサーバの間に置かれていて、これらの間でメッセージを中継するデバイスは、クライアント側オブジェクトIDとサーバ側オブジェクトIDとを対応付けているマップをストアしているのが代表的である。プロトコルは、オブジェクトをサーバに追加することをクライアントが最初に要求したとき、クライアントがクライアント側オブジェクトIDをサーバに送信させる設計になっている。オブジェクトとそのIDを受信すると、サーバはそのオブジェクトに対応するサーバ側IDを生成し、クライアント側ID、関連のサーバ側ID、および追加のステータスをクライアントに送信し、これを受けて、クライアントは、将来の更新に備えてオブジェクトにIDを関連付ける。オブジェクトに関する将来の更新は、クライアントとサーバのどちらも、サーバ側IDで参照することができる。例えば、ユーザは、ユーザのモバイルデバイスで新連絡先、例えば、John Doeを追加すると、モバイルデバイスをサーバと同期化する。モバイルデバイスは、例えば、100のように、クライアント側IDを新連絡先に割り当て、新連絡先をクライアント側IDと一緒にサーバに送信し、例えば、752のように、どのサーバ側IDがクライアント側IDと対応付けられたかを示す応答をサーバから受信する。このサーバ側IDは、ユーザが連絡先に関する情報を更新するとき使用される。
次のXMLレベルにネストできるタグ：なし
【００５５】
<ServerId>...</ServerId>
許される個数：<Add>...</Add>、<Delete>...</Delete>、<Change>...</Change>、または<Fetch>...</Fetch>タグペアごとに１個
<ServerId>...</ServerId>タグペアの間に置かれる情報は、サーバ側の特定オブジェクトを示している。オブジェクトに対してサーバによって割り当てられたIDは、オブジェクトに対してクライアントによって割り当てられたIDと同じで場合と、そうでない場合がある。サーバIDに関する詳細情報は、上述した<ClientId>...</ClientId>タグペアの個所に説明されている。クライアントIDとサーバIDとを対応付けたマップをクライアント側が維持しているシステムでは、ユーザがサーバ側の連絡先を変更したいとき、ユーザのクライアントは、その連絡先を更新するためにサーバIDを更新データと一緒にサーバに送信することができる。例えば、連絡先John Doeの名前をJane Doeに変更する場合は、ユーザのクライアントは、John Doeに関連するサーバID、例えば、752を名前変更情報と一緒にサーバに送信することになる。
次のXMLレベルにネストできるタグ：なし
【００５６】
<ApplicationData>...</ApplicationData>
許される個数：<Add>...</Add>または<Fetch>...</Fetch>タグペアごとに１個  <ApplicationData>...</ApplicationData>タグペアは、サーバ側またはクライアント側のアプリケーションに送信されるデータおよび/またはコマンドを取り囲むために使用できる。プロトコルは、開始<ApplicationData>タグと終了</ApplicationData>タグの間にどのようなものでも置くことができる設計になっている。この点では、前述した<Options>...</Options>タグペアに類似している。例えば、アプリケーションは、ピクチャを別のアプリケーションに送信する必要が起こる場合がある。ピクチャをJPEGフォーマットで表しているバイナリデータは、それを<ApplicationData>...</ApplicationData>タグペアの間に置くことによって送信することができる。別の方法として、アプリケーションは、連絡先情報を更新するために情報を送信する場合がある。このプロトコルによれば、アプリケーションは新連絡先オブジェクト全体を送信するのではなく、変更された情報だけを送信できるようにしている。例えば、連絡先John Doeのファーストネームを変更するアプリケーションは、変更しようとする連絡先の属性を示す情報、例えば、<c:FirstName>Jane</c:FirstName>を<ApplicationData>...</ApplicationData>タグペアの間に置くことができる。なお、<c:FirstName>Jane</c:FirstName>タグペアは、個別的にはこのプロトコルによって認識されないが、<ApplicationData>...</ApplicationData>タグペアの性質上、連絡先情報を更新する方法を必要とするアプリケーションに便宜を与えるために、プロトコルに組み入れることが可能になっている。
次のXMLレベルにネストできるタグ：任意。しかし、個別的にはこのプロトコルで認識されない。
【００５７】
<Status>...</Status>
<Status>...</Status>タグペアは、要求されたオペレーションが成功したか、失敗したかに関するデータを取り囲むために使用することができる。そのようなデータとしては、オペレーションのステータス、例えば、Syncサーバのエラーを記述する文字ストリング、エラーに対応する整数、例えば、4153699、文字と数字からなる英数字ストリング、または他の任意のデータフォーマットがある。ステータスの報告に整数が使用されるときは、いくつかのフィールドに分割することができる。例えば、最初の桁は使用されるプロトコルに対応付けることができる。例えば、4153は、AirSyncプロトコルの短縮語である"AS"のASCIIを表している。整数の別のフィールドは、エラータイプに対応付けることができる。次の表は、いくつかのエラータイプの例を示している。
【００５８】
【表１】
0003987396.tif 000003
【００５９】
上例の接頭部 (4153) と上表を使用すると、次の例に示すように、個々の整数が表すものを定義することができる。
成功 = 4153200
アクセス拒否 = 4153300
サーバタイムアウト = 4153301
バージョン不一致 = 4153500
SyncKey無効 = 4153501
AirSyncプロトコルエラー = 4153499
データサーバエラー = 4153699
変換エラー = 4153601
不一致 = 4153602
不明 = 4153999
アプリケーションがエラーを処理するか、プロトコルパーサがエラーを処理するかは、アプリケーション固有である。例えば、プロトコルパーサは、送信側にメッセージを再送信させることを要求することによって、AirSyncエラーに応答することができる。アプリケーションは、不一致のバージョンを受信したときなにをすべきかを判断することができる。アプリケーションは、例えば、受信したバージョンと互換性のあるバージョンをプロトコルパーサに使用させることができる。
次のXMLレベルにネストできるタグ：なし
【００６０】
プロトコルのシンタックスの説明は、以上のとおりである。このプロトコルを詳細に検討すると、上述してきた利点が得られることが分かるはずである。具体的には、このプロトコルを使用すると、複数の応答を１つにまとめることができる。さらに、このプロトコルを使用すると、データを更新する複数のコマンドを１つにまとめることができる。さらに、データを更新するコマンドグループとこれらのコマンドに対する応答グループも、１つにまとめて１つのXMLドキュメントにすることができる。このプロトコルによれば、<Fetch>...</Fetch>タグペアを使用し、</GetChanges>タグを省くと、クライアントは、完全な同期化を要求しなくても、１つのオブジェクトを送信することを要求することができる。</GetChanges>タグを省くと、クライアントは、サーバからの更新をクライアントに受信させなくても、更新をサーバに送信することができる。<WindowSize>...</WindowSize>タグペアを使用すると、クライアントは、一定数の更新だけを同期化期間に送信させることを要求することができる。<MoreAvailable/>タグを使用すると、サーバは、送信したオブジェクトのほかにも、オブジェクトが残っていることを通知することができる。このプロトコルによれば、オプションである<Responses>...</Responses>を使用すると、更新が成功した各オブジェクトについては応答を送信することなく、更新が失敗した各オブジェクトについて応答を送信できるので、送信の必要がある情報量が減少することになる。<Options>...</Options>タグペアと<ApplicationData>...</ApplicationData>タグペアを使用すると、アプリケーション固有の方法でプロトコルを拡張することができる。
【００６１】
図１から図３は、デバイスを同期化するプロトコルのシンタックスの一例を示す図である。このシンタックスはXMLスキーマ言語 (schema language) で提供され、そこでは、XMLは、このプロトコルで許される許容XMLドキュメントのグラマーを定義するために使用されている。なお、このスキーマは、プロトコルの完全なシンタックスを記述していない。スキーマに不備がある個所では、<!-- -->タグペアを使用して、そのスキーマにコメントが付けられている。XMLスキーマを使用してXMLドキュメントを指定する方法の詳しい説明については、現在http://www.w3.org に置かれているWorld Wide Webコンソーシアムのホームページを参照されたい。
【００６２】
図４と図５は、データの同期化のためにクライアントによって送信されるXMLドキュメントの例を示す図である。図６と図７は、図４と図５に示すXMLドキュメントに応答して送信されるXMLドキュメントの例を示す図である。図４、図５、図６、および図７は、本明細書に開示されているプロトコルを使用してクライアント側とサーバ側のデータを同期化するために使用されるXMLドキュメントの説明図である。
【００６３】
例示コンピューティングデバイス
図８を参照して説明すると、本発明を実現する例示システムは、コンピューティングデバイス４００のような、コンピューティングデバイスを含んでいる。非常に基本的な構成では、コンピューティングデバイス４００は、少なくとも１つの処理ユニット４０２とシステムメモリ４０４を装備しているのが代表的である。処理ユニット４０２の中には、既存の物理プロセッサ、設計中の物理プロセッサ、協働の多重プロセッサ、仮想プロセッサ、およびバイナリ実行可能命令を解釈する機能を備えた他のデバイスまたはソフトウェアプログラムが含まれている。コンピューティングデバイスの正確な構成とタイプに応じて、システムメモリ４０４としては、揮発性メモリ（RAMなど）、不揮発性メモリ（ROM、フラッシュメモリなど）またはこれらを任意に組み合わせたものがある。システムメモリ４０４には、オペレーティングシステム４０５、１つまたは２つ以上のプログラムモジュール４０６が置かれているのが代表的であるが、プログラムデータ４０７が置かれていることもある。この基本構成は、上記コンポーネントを破線４０８で囲んで図８に示されている。
【００６４】
コンピューティングデバイス４００は、追加の機構または機能を備えている場合もある。例えば、コンピューティングデバイス４００は、例えば、磁気ディスクや光ディスク、テープのような、追加のデータストレージデバイス（取り外し可能および/または取り外し不能）を装備することも可能である。このような追加ストレージは、取り外し可能ストレージ４０９および取り外し不能ストレージ４１０として図８に示されている。コンピュータ記憶媒体としては、揮発性と不揮発性の、取り外し可能と取り外し不能の媒体があり、これらは、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータなどの、情報を記憶するための方法またはテクノロジで実現されている。システムメモリ４０４、取り外し可能ストレージ４０９および取り外し不能ストレージ４１０は、いずれもコンピュータ記憶媒体の例である。コンピュータ記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリテクノロジ、CD-ROM、デジタルバーサタイルディスク (digital versatile disk  DVD)または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、そのほかに、必要とする情報をストアするために使用でき、コンピュータデバイス４００によってアクセス可能な他の媒体があるが、これらに限定されない。このようなコンピュータ記憶媒体は、いずれも、デバイス４００の一部にすることが可能である。コンピューティングデバイス４００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの、入力デバイス４１２を備えることも可能である。ディスプレイ、スピーカ、プリンタなどの出力デバイス４１４を備えることも可能である。これらのデバイスはすべて、この分野では公知であるので、ここで詳しく述べることは省略する。
【００６５】
コンピューティングデバイス４００は、ネットワークなどを利用してデバイスが他のコンピューティングデバイス４１８と通信することを可能にする通信コネクション４１６を装備することもできる。通信コネクション４１６は、通信媒体の一例である。通信媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータを、搬送波や他のトランスポートメカニズムなどの変調データ信号で具現化しているのが代表的であり、その中には、あらゆる情報配信媒体が含まれている。ここで「変調データ信号(modulated data signal)」という用語は、その特性の１つまたは２つ以上が、信号中の情報を符号化するような形で設定または変更されている信号を意味している。通信媒体の例としては、ワイヤド（有線）ネットワークや直接ワイヤドコネクションなどのワイヤド媒体、音響、RF、赤外線、その他のワイヤレス媒体などのワイヤレス媒体があるが、これらに限定されない。ここで使用されている「コンピュータ読取可能媒体(computer readable media)」という用語には、記憶媒体と通信媒体の両方が含まれている。
【００６６】
モバイルコンピューティングデバイス
図９は、モバイルコンピューティングデバイス５００の機能コンポーネントを示す機能ブロック図である。モバイルコンピューティングデバイス５００は、プロセッサ５６０、メモリ５６２、ディスプレイ５２８、およびキーパッド５３２を備えている。メモリ５６２には、揮発性メモリ（例えば、RAM）および不揮発性メモリ（例えば、ROM、フラッシュメモリなど）が含まれているのが一般である。モバイルコンピューティングデバイス５００は、Microsoft Corporation提供のWindows（登録商標） CEオペレーティングシステムや他のオペレーティングシステムなどのように、メモリ５６２に常駐して、プロセッサ５６０上で実行されるオペレーティングシステム５６４を備えている。キーパッド５３２としては、プッシュボタン数値ダイアリングパッド（通常の電話機上のもの）、マルチキーのキーボード（従来のキーボードなど）がある。ディスプレイ５２８としては、液晶ディスプレイやモバイルコンピューティングデバイスで共通に使用されている他のタイプのディスプレイなどがある。ディスプレイ５２８はタッチセンシティブ（接触感知）にすることもできるので、入力デバイスとしても使用されている。
【００６７】
１つまたは２つ以上のアプリケーションプログラム５６６はメモリ５６２にロードされ、オペレーティングシステム５６４上で実行される。アプリケーションプログラムの例としては、電話ダイヤラプログラム (phone dialer program)、Eメールプログラム、スケジューリングプログラム、PIM（personal information management：パーソナル情報管理）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどがある。モバイルコンピューティングデバイス５００は、メモリ５６２内に不揮発性ストレージ５６８も備えている。不揮発性ストレージ５６８は、モバイルコンピューティングデバイス５００をパワーダウンしたとき消失してはならない持続性情報をストアしておくために使用できる。アプリケーション５６６は、Eメールアプリケーションで使用されるEメールや他のメッセージ、PIMで使用される連絡先情報、スケジューリングプログラムで使用されるアポイントメント情報、ワードプロセッシングアプリケーションで使用されるドキュメントなどの情報を使用し、ストレージ５６８にストアしておくことができる。同期化アプリケーションもモバイルデバイスに置かれており、ホストコンピュータに置かれている対応する同期化アプリケーションとやりとりして、ストレージ５６８にストアされた情報がホストコンピュータ側にストアされている対応する情報と同期が保たれるようにプログラムされている。
【００６８】
モバイルコンピューティングデバイス５００は電源５７０を備えており、これは、１つまたは２つ以上のバッテリとして実装することが可能になっている。電源５７０としては、さらに、ACアダプタやパワードドッキングクレイドル (powered docking cradle) のように、バッテリを補足または充電するための外部電源がある。
【００６９】
モバイルコンピューティングデバイス５００は、図示のように、２種類の外部通知メカニズム、すなわち、LED ５４０とオーディオインタフェース５７４も備えている。これらのデバイスは電源５７０に直結できるので、これらがアクティブ状態にあるとき、バッテリ電源を節約するためにプロセッサ５６０または他のコンポーネントがシャットダウンされた場合でも、通知メカニズムによって指定された時間の間、オンのままになっている。LED ５４０は、ユーザがデバイスのパワーオンステータスを表示するアクションをとるまで、いつまでもオンにしておくようにプログラムすることができる。オーディオインタフェース５７４は、可聴信号をユーザとの間で送受するために使用される。例えば、オーディオインタフェース５７４をスピーカに結合すると、可聴出力を得ることができ、マイクロホンに結合すると、可聴入力を受信できるので、電話会話が容易化される。
【００７０】
モバイルコンピューティングデバイス５００は、無線周波数通信を送受信する機能を実行する無線インタフェースレイヤ５７２も備えている。無線インタフェースレイヤ５７２を使用すると、モバイルコンピューティングデバイス５００と外部世界とを、電話会社やサービスプロバイダを経由してワイヤレスで接続することが容易化される。無線インタフェースレイヤ５７２との間の送受信は、オペレーティングシステム５６４の制御下で行われる。言い換えれば、無線インタフェースレイヤ５７２によって受信されたコミュニケーションは、オペレーティングシステム５６４を通してアプリケーションプログラム５６６に伝えていくことができ、その逆も同じである。
【００７１】
例示同期化システム
図１０は、本発明の一実施形態に従い、クライアント側とサーバ側のデータを同期化するように構成されたシステムを示す機能ブロック図である。システムは、クライアント６０５、バックエンドサーバ６１０、およびプロキシサーバ６２０を含んでいる。プロキシサーバ６２０は、ハイパテキスト転送プロトコル (hypertext transport protocol  HTTP) インタフェース６１５、syncエンジン６２２、ドキュメントパーサ６２５、およびプロトコルエンジン６３０を備えている。プロトコルエンジン６３０はsyncパーサ６３５とビルダ６４０から構成されている。
【００７２】
クライアント６０５は、ネットワークに情報を送信し、ネットワークから情報を受信する機能を備えた任意のデバイスである。そのようなデバイスとしては、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとするまたはプログラマブルなコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどがある。クライアント６０５には、同期化を必要とする多種類のアプリケーションを置いておくことができる。
【００７３】
バックエンドサーバ６１０は、図８を参照して説明したコンピューティングシステムにすることができる。代表例として、バックエンドサーバ６１０はサービスを実行し、クライアント群のためにデータをストアしている。例えば、バックエンドサーバ６１０は、Eメールを送信し、受信し、ストアし、削除するメールサーバとして使用することができる。さらに、バックエンドサーバ６１０は、Eメールを処理するための種々のルールをもち、複数のユーザのためにEメールを処理することができる。
【００７４】
HTTPインタフェース６１５は、インターネット上をデータ送信するために使用される。HTTPインタフェース６１５は、伝送制御プロトコル/インターネットプロトコル (transmission control protocol/internet protocol  TCP/IP) などの、他のプロトコルの上に構築されている（または他のプロトコルを使用して送信される）のが代表的である。HTTPインタフェース６１５は、Webページの要求をブラウザから送信し、Webページからのデータをブラウザに送信するために使用されるのが代表的であるが、他の情報を送信するためにも使用できる。
【００７５】
プロキシサーバ６２０も、図８を参照して説明したコンピューティングシステムにすることができる。プロキシサーバ６２０は、クライアント６０５とバックエンドサーバ６１０との間のインタフェースの働きする。具体的には、プロキシサーバ６２０は、クライアント６０５からの要求を、バックエンドサーバ６１０が理解できる要求に変換する。また、バックエンドサーバ６１０から戻されたデータを、クライアント６０５に適した情報に変換する。プロキシサーバ６２０は、バックエンドサーバ６１０が備えていない、すべての必要同期化機能を備えている。例えば、バックエンドサーバ６１０には、簡易構造化照会言語 (structured query language  SQL) データベースが置かれていることがある。このデータベースは、SQLコマンドに応答してデータをストアし、データを取り出すことができる。しかし、SQLデータベースは、図６乃至図９を参照して説明したプロトコルのような、プロトコルには応答しないのが代表的である。例えば、<GetChanges/>は、SQLシンタックスの一部になっていない。従って、クライアント６０５のようなクライアントが変更要求を送信するときは、プロキシサーバ６２０がその要求をSQLシンタックスに変換し、該当する場合には、SQLデータベースにクエリ（照会）し、その応答としてXMLドキュメントを作成し、そのXMLドキュメントをクライアントに送信している。
【００７６】
図１０に示すシステムの利点の１つは、バックエンドサーバ６１０を、簡易または高度のメールサーバで置き換えても、クライアント６０５に影響しないことである。そのために、プロキシサーバ６２０は、バックエンドサーバ６１０と通信するようにプログラムされ、バックエンドサーバ６１０に欠けている同期化機能を実行できるようにしている。
【００７７】
Syncエンジン６２２はドキュメントサーバ６２５を使用して、クライアント６０５とバックエンドサーバ６１０から送られてきたコマンドおよび/またはデータを見つけるようにしている。例えば、クライアント６０５は、本明細書に開示されているプロトコルの一部でないコマンドを送信する場合がある。そのようなものとして、クライアント６０５がEメール全体を受信しなかったときのEメールに対する応答要求（スマート応答）、クライアント６０５がアタッチメントを受信しなかったときのEメールついて、そのアタッチメント付きでEメールを転送する要求（スマート転送）、あるいは進行中作業 (work-in-progress) フォルダのようなフォルダを、そのフォルダ内のすべてのオブジェクトを取り出すことなく、ある場所から別の場所へ移動する要求など、がある。
【００７８】
別の方法として、クライアント６０５は、<Sync>...</Sync>タグペアをドキュメントに埋め込むこともできる。この場合には、ドキュメントパーサ６２５は、<Sync>...</Sync>タグペアの間に置かれている同期化XMLドキュメントを抽出するために使用され、そのあと、syncエンジン６２２がそれをプロトコルエンジン６３０に送って、同期化ドキュメントを抽出するようにしている。
【００７９】
プロトコルエンジン６３０は、syncパーサ６３５を使用して同期化コマンド、応答、および/またはデータを抽出し、そのあとsyncエンジン６２２に送られる。例えば、syncエンジン６２２は、複数のコマンドと応答を収めているXMLドキュメントをプロトコルエンジン６３０に送信することができる。そのあと、syncエンジン６２２は、すべてのコマンドと応答が処理されるまで、次のコマンドまたは応答を関連データと一緒に戻すように繰り返しプロトコルエンジン６３０に要求することができる。プロトコルエンジン６３０は、XMLドキュメントをsyncパーサ６３５に渡し、要求に応じて、コマンドと応答が関連データと一緒にsyncパーサ６３５から戻される。
【００８０】
同様に、プロトコルエンジン６３０は、コマンド、応答、および/またはデータを収めているXMLドキュメントを、ビルダ６４０を使用して構築し、そのあとsyncエンジン６２２に送信される。例えば、syncエンジン６２２は、syncエンジン６２２からクライアント６０５に送られるXMLドキュメントの構築を開始するようにプロトコルエンジン６３０に要求することができる。そのあと、syncエンジン６２２は、XMLドキュメントに入れられるコマンドと応答をデータと一緒に繰り返しプロトコルエンジン６３０に送信することができる。プロトコルエンジン６３０は、コマンドと応答を含むXMLドキュメントをデータと一緒にビルダ６４０にアセンブルさせたあと、そのXMLドキュメントをsyncエンジン６２２に送信する。
【００８１】
本発明の別の実施形態では、プロキシサーバ６２０は不要になっている。その代わりに、クライアント６０５は、バックエンドサーバ６１０と直接に通信する。本発明のこの実施形態では、クライアント６０５とバックエンドサーバ６１０は、図６乃至図９を参照して説明したプロトコルを使用して要求を送信し、応答を受信できるようになっている。
【００８２】
図１１は、本発明の一実施形態に従って、クライアント側とサーバ側のデータを同期化するように構成されたシステムを示す機能ブロック図である。システムは、クライアント６０５、バックエンドサーバ６１０、プロキシサーバ６２０、およびメッセージ配信システム７１５を含んでいる。クライアント６０５、バックエンドサーバ６１０、およびプロキシサーバ６２０のオペレーションの一部は、図１０を参照して説明したとおりである。
【００８３】
メッセージ配信システム７１５は、データをバンド外でクライアント６０５に配信することができる。すなわち、メッセージ配信システム７１５は、クライアント６０５が更新データを要求するまで待たなくても、データをクライアント６０５に送付することができる。むしろ、メッセージ配信システム７１５は、ページャ (pager) とまったく同じように、メッセージをいつでもクライアント６０５に配信することができる。この種のメッセージは、バックエンドサーバ６１０などのサーバから出されるのが代表的であり、サーバIDとデータを含んでいる。バンド外メッセージの一例として、簡易メッセージングシステム (Simple Messaging System  SMS) などを使用して配信されるメッセージがある。
【００８４】
クライアント６０５には、サーバIDとクライアントIDとを対応付けているマッピングテーブル７２０が置かれている。マッピングテーブル７２０は、更新をバックエンドサーバ６１０との間で送受信するときに使用される。例えば、クライアント６０５は、クライアントID 1のようなクライアントIDを、サーバID 102のようなサーバIDに変換したあと、サーバID 102に関連するサーバ側オブジェクトを更新する要求を送信することができる。さらに、クライアント６０５がサーバ６１０またはメッセージ配信システム７１５から更新を受信したとき、クライアント６０５は、サーバIDを該当クライアントIDにマッピングし、クライアントIDに関連するクライアント側オブジェクトを更新することができる。例えば、メッセージ配信システム７１５がサーバID 100に関連する更新を配信したときは、クライアント６０５は、そのサーバIDをクライアントID 3にマッピングし、クライアントIDに関連するクライアント側オブジェクトを、それに見合うように更新する。
【００８５】
別の方法として、クライアント６０５は、マッピングテーブル７２０を一時的に作成しておき、必要でなくなっとき削除することができる。例えば、ユーザは、クライアント６０５側でオブジェクトを追加する場合がある。クライアントは、そのオブジェクトにクライアントIDを割り当て、それをオブジェクトテーブル７２５に入れておくことができる。そのあと、クライアント６０５は、マッピングテーブル７２０を作成し、割り当てたクライアントIDをそこに入れておくことができる。クライアント６０５がバックエンドサーバ６１０とデータを同期化するまで、サーバIDが新オブジェクトと関連付けられないことがある。クライアント６０５がバックエンドサーバ６１０とデータを同期化するとき、クライアント６０５は、各クライアントIDと関連付けられたサーバIDを示した応答を受け取ることがある。各サーバIDがクライアントIDと関連付けられるとき、クライアント６０５は、オブジェクトテーブル７２５に入っているオブジェクト関連のクライアントIDを、受信したサーバIDで置き換えることができる。そのあとは、マッピングテーブル７２０内の各新オブジェクトには、サーバIDが割り当てられているので、マッピングテーブル７２０を削除することができる。そのあと、クライアント６０５は、オブジェクトテーブル７２５内のIDを使用して、バックエンドサーバ６１０側のオブジェクトを参照することができる。
【００８６】
XML1ドキュメント７０５とXML2ドキュメント７１０は、同期化が行われるときクライアント６０５とプロキシサーバ６２０間で送信できる例示XMLドキュメントの一部である。
【００８７】
本発明の別の実施形態では、プロキシサーバ６２０には、クライアント側IDとサーバ側IDを対応付けているマッピングテーブル（図示せず）を置いておくことが可能になっている。プロキシサーバ６２０は、クライアント６０５とバックエンドサーバ６１０間のメッセージをモニタリングし、関係する情報を抽出することによってそのマッピングテーブルを維持管理している。例えば、クライアント６０５は、オブジェクトを追加する更新を、クライアント６０５がオブジェクトと関連付けたIDと一緒に送信することができる。その応答として、バックエンドサーバ６１０は、あるサーバ側IDをそのオブジェクトに割り当てたことを通知することができる。プロキシサーバ６２０は、クライアント側IDと割り当てられたサーバ側IDを使用すると、そのマッピングテーブルを更新することができる。
【００８８】
さらに、マッピング情報を定期的にプロキシサーバ６２０と共有させると、最新のマッピングを収めておくことが可能になる。例えば、クライアント６０５は、メッセージ配信システム７１５から新オブジェクトをバンド外で受信することがある。クライアント６０５は、オブジェクトと一緒に送られてきたサーバ側IDとは異なるクライアント側IDを割り当てることがある。そのあとで、クライアント６０５は、クライアント側IDと要求した変更を送信すると、オブジェクトの更新をバックエンドサーバ６１０に送ることもあり得る。オブジェクトの最初の追加はバンド外で行われたので、プロキシサーバ６２０は、送られてきたクライアントIDに関連するサーバIDを知らないことがある。プロキシサーバ６２０に知らせていないマッピングに対応する、取得した新オブジェクトのリストをとっておき、プロキシサーバ６２０に定期的にマッピング情報を知らせるようにすると、クライアント６０５はこの問題を避けることができる。
【００８９】
クライアントとサーバとを対応付けるマッピングを実現するには、本明細書に開示されているプロトコルに<Map>...</Map>タグペアを追加しておく必要がある。バンド外で送信されるオブジェクトについては、そのオブジェクトと一緒に送信されるサーバ側IDに関連するクライアント側IDを、このタグペアの間に入れておくことができる。
【００９０】
別の方法として、クライアント６０５へのバンド外配信を禁止することも可能である。そのようにすると、マッピング情報の定期的共有は不要になる。むしろ、プロキシサーバは、クライアント６０５とバックエンドサーバ６１０間のコミュニケーションを処理することによってマッピング情報を取得することが可能になる。
【００９１】
プロキシサーバ６２０がマッピング情報をもっているときは、クライアント６０５は、クライアント側IDをもつオブジェクトを参照することにより、プロキシサーバ６２０を通して更新をバックエンドサーバ６１０に送信することができる。そのあと、プロキシサーバ６２０は、マッピングテーブルを使用してクライアント側IDをサーバ側IDに変換することが可能になる。プロキシサーバ６２０が、オブジェクトに関してバックエンドサーバ６１０とのやりとりするとき、オブジェクトに関連するサーバ側IDを使用することになる。プロキシサーバ６２０がクライアント６０５とやりとりするときは、オブジェクトに関連するクライアント側IDを使用することになる。マッピングテーブルをプロキシ側にストアしておくと、類似のマッピングテーブルのためにクライアントデバイス側で必要になるストレージが不要になる。
【００９２】
図１２は、ここで開示しているプロトコルを使用して同期化を行うときのプロセスを示す論理フロー図である。図１１を参照して説明したシステムを参照しながら、図１２を説明することにする。プロセスは、データがクライアント６０５のようなクライアントと、バックエンドサーバ６１０のようなバックエンドサーバとの間で同期化される準備状態にあるとき、ブロック８０５から開始される。この時点では、マッピングテーブル７２０は空であり、クライアント側オブジェクトテーブルには、サーバ側ID 100と101に関連するオブジェクトが入っている。この例の説明の便宜上、クライアント６０５とバックエンドサーバ６１０は、以前にデータを同期化していないものと想定されている。
【００９３】
ブロック８１０では、クライアントは、前回の同期化以後に行われた変更を収めているXMLドキュメントを作成する。クライアントとバックエンドサーバは以前にデータを同期化していないので、このXMLドキュメントは、クライアント側で作成され、これから同期化されるオブジェクトを収めている。例えば、図１１を参照して説明すると、クライアント６０５は、XML1ドキュメント７０５に類似のXMLドキュメントを作成している。このドキュメントは、基本的には、クライアント側ID 1と2に関連するオブジェクトに対応するオブジェクトを、サーバに追加させることを記述している。そのあと、クライアント６０５は、XML1ドキュメント７０５をプロキシサーバ６２０に送信する。
【００９４】
ブロック８１５では、プロキシサーバは、送られてきたXMLドキュメントを使用してバックエンドサーバを更新し、ドキュメントの中で要求された情報がほかにもあれば、それを要求する。例えば、プロキシサーバ６２０は、XML1ドュメント７０５に入っている２オブジェクトに対応する２つの更新をバックエンドサーバ６１０に送信する。
【００９５】
ブロック８２０では、バックエンドサーバは、プロキシサーバから要求された更新を行う。例えば、バックエンドサーバ６１０は、２つのオブジェクト、例えば、AとBを追加し、その各々にサーバ側ID、例えば、102と103を割り当てる。
【００９６】
ブロック８２５では、プロキシサーバは、バックエンドサーバ側にある更新とコマンドを受信する。さらに、バックエンドサーバは、バックエンドサーバが追加した各新オブジェクトのサーバ側IDをプロキシサーバに送信するのが代表的である。プロキシサーバは、サーバが割り当てた各IDを、クライアントがオブジェクトと関連付けたIDと一緒にプロキシサーバに報告することができる。このようにすると、クライアントは、新たに追加されたオブジェクトに対する将来の更新を、サーバがオブジェクトと関連付けたIDを使用して送信できるように、そのマッピングテーブルを更新しておくことができる（または一時的マッピングテーブルを破棄し、割り当てられたサーバ側IDでクライアント側IDを置き換え、将来の参照に備えてサーバ側IDを使用することができる）。例えば、プロキシサーバ６２０は、２オブジェクトCとDを、そのオブジェクトに関連付けられたサーバ側ID、例えば、100と101と一緒にバックエンドサーバ６１０から受信する。また、プロキシサーバ６２０は、以前に追加したクライアント側オブジェクト、例えば、AとBのIDを得るために、バックエンドサーバ６１０にクエリし、サーバがサーバ側ID 102をオブジェクトAに、サーバ側ID 103をオブジェクトBに割り当てたことを知ることになる。
【００９７】
ブロック８３０では、プロキシサーバは、クライアントが以前に送信した更新に対する応答を、サーバからクライアントに送信されるコマンドおよび/または更新と一緒に収めているXMLドキュメントを、クライアントに送信するために作成する。例えば、図１１に示すように、プロキシサーバ６２０は、XML2ドキュメント７１０に入っている情報を含むXMLドキュメントを作成している。XML2ドキュメントは、プロキシサーバ６２０からクライアント６０５に送信されるのが代表的であるXMLドキュメントの一部にすぎない。XMLドキュメントには、特に、サーバ側IDが、最新の更新を送るときクライアントが追加したオブジェクトについてサーバ側IDが対応付けられているクライアント側IDと一緒に含まれているのが一般的である。XML2ドキュメントを作成したあと、プロキシサーバ６０２は、それをクライアント７０２に送信する。
【００９８】
ブロック８３５では、クライアントはXMLドキュメントを受信し、エラーがある場合その対処方法を判断し、該当する更新を行う。例えば、例えば、図１１に示すように、クライアント６０５はXML2ドキュメントを受信し、オブジェクトCとDをクライアント側オブジェクトテーブル７２５に追加している。クライアント６０５は、サーバ側ID 100-103が、そのIDと対応付けられているクライアント側IDと一緒に入っているマッピングテーブル７２０も更新する。
【００９９】
ブロック８４０で、処理は終了する。この時点で、クライアントとバックエンドサーバの間の同期化は完了している。さらに、クライアントは、サーバ側IDを使用してオブジェクトの変更が得られるように、そのマッピングテーブルを更新している。クライアントが再び同期化するときは、上述したステップを繰り返すことで行うことができる。
【０１００】
本発明の種々実施形態は、コンピューティングシステム上で実行されるコンピュータ実装ステップまたはプログラムモジュールのシーケンスとして、および/またはコンピューティングシステム内の相互接続ロジック回路または回路モジュールとして実現されている。どのように実現されるかは、本発明を実現するコンピューティングシステムに要求されるパフォーマンスに応じた選択の問題である。この分野の精通者ならば、上述してきた説明から理解されるように、本明細書に開示されている種々実施形態の機能とオペレーションは、請求の範囲に明確化されている本発明の精神と範囲から逸脱しない限り、ソフトウェアでも、ファームウェアでも、特殊目的デジタルロジックでも、あるいはこれらの任意の組み合わせでも、実現することが可能である。
【０１０１】
上述してきた仕様、例およびデータは、本発明を構成するものの製造と使用を詳細に説明したものである。本発明は、本発明の精神と範囲から逸脱しない限り、種々態様に実現することが可能であるので、本発明の本質は請求の範囲に記載されているとおりである。
【図面の簡単な説明】
【図１】デバイスを同期化するためのプロトコルのシンタックスの一例を示す図である。
【図２】デバイスを同期化するためのプロトコルのシンタックスの一例を示す図である。
【図３】デバイスを同期化するためのプロトコルのシンタックスの一例を示す図である。
【図４】データの同期化のためにクライアントから送信されるXMLドキュメントの例を示す図である。
【図５】データの同期化のためにクライアントから送信されるXMLドキュメントの例を示す図である。
【図６】図４と図５に示すXMLドキュメントに対する応答として送信されるXMLドキュメントの例を示す図である。
【図７】図４と図５に示すXMLドキュメントに対する応答として送信されるXMLドキュメントの例を示す図である。
【図８】本発明を実現するためのシステムの例を示す図である。
【図９】モバイルコンピューティングデバイスの機能コンポーネントを示す機能ブロック図である。
【図１０】クライアント側とサーバ側のデータを同期化するように構成されたシステムを示す機能ブロック図である。
【図１１】クライアント側とサーバ側のデータを同期化するように構成されたシステムの詳細を示す機能ブロック図である。
【図１２】本発明に従って開示されているプロトコルを使用して同期化を実行するためのプロセスを示す論理フロー図である。
【符号の説明】
４００  コンピューティングデバイスr
４０２  処理ユニット
４０４  システムメモリ
４０５  オペレーティングシステム
４０６  プログラムモジュール
４０７  プログラムデータ
４０９  取り外し可能ストレージ
４１０  取り外し不可能ストレージ
４１２  入力デバイス
４１４  出力デバイス
４１６  通信コネクション
４１８  他のコンピューティングデバイス
５００  モビールコンピューティングデバイス
５２８  ディスプレイ
５３２  キーパッド
５４０  LED
５６２  メモリ
５６４  OS
５６６  アプリケーション
５６８  ストレージ
５７０  電源
５７２  無線インタフェースレイヤ
５７４  オーディオインタフェース
６０５  クライアント
６１０  バックエンドサーバ
６１５  HTTP
６２０  プロキシサーバ
６２２  syncエンジン
６２５  パーサ
６３０  プロトコルエンジン
６３５  パーサ
６４０  ビルダ
７１５  メッセージ配信システム
７０５  XML1ドキュメント
７１０  XML2ドキュメント
７２０  マッピングテーブル
７２５  オブジェクトテーブル
【図１】
0003987396.tif 000004
【図２】
0003987396.tif 000005
【図３】
0003987396.tif 000006
【図４】
0003987396.tif 000007
【図５】
0003987396.tif 000008
【図６】
0003987396.tif 000009
【図７】
0003987396.tif 000010
【図８】
0003987396.tif 000011
【図９】
0003987396.tif 000012
【図１０】
0003987396.tif 000013
【図１１】
0003987396.tif 000014
【図１２】
0003987396.tif 000015