JP4943512B2 - 通知メッセージ処理方法および装置 - Google Patents

Description

関連出願の相互参照
本発明は、２００７年５月３０日に出願された中国特許出願第２００７１０１０８３９８．０号「セッション接続及びセッション開始同期方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｓｅｓｓｉｏｎ Ｃｏｎｎｅｃｔｉｏｎ ａｎｄ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ）」の優先権と、２００７年８月７日に出願された中国特許出願第２００７１０１３７５５５．０号「通知メッセージ処理方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ Ｐｒｏｃｅｓｓｉｎｇ）」の優先権とを主張するものであり、これら２件の出願の内容は、参照により、本明細書に組み込まれている。

本発明は、全体として通信分野に関し、特に、データ同期技術の分野における通知メッセージ処理の方法および装置に関する。

人々の仕事や暮らしにおいて、現代の通信技術の果たす役割がますます重要になるにつれて、データ伝送の品質に関して課される要求はますます高くなっている。データ同期（ＤＳ）は、データ伝送において非常に重要である。ＤＳ技術は、移動装置とネットワークサーバとの間のデータ同期に関する。同期されるデータとしては、電話帳、アドレス帳、スケジュール、ショートメッセージ、メールなどがある。

既存のＤＳメッセージでは、サーバが端末装置に通知メッセージを配信するための通知機構が与えられている。端末装置は、通知メッセージ内のセッションＩＤ（セッション識別子）やサーバＩＤ（サーバ識別子）のような情報に従って、サーバとのセッション接続を開始する。通知メッセージの配信は、ショートメッセージ、ＯＴＡ（Ｏｖｅｒ ｔｈｅ Ａｉｒ）技術のＰＵＳＨ（ＯＴＡ ＰＵＳＨ）などを用いて行われることが可能である。

現行のＤＳサーバとＤＳクライアントとの間のセッションの管理のフローチャートを、図１に示す。ステップ１１０で、ＤＳサーバは、ＤＳクライアントに通知(Notification)メッセージを配信して、セッション接続を要求する。次に、ステップ１２０で、ＤＳクライアントは、ＤＳサーバとのセッション接続を開始し、ＤＳクライアントの認証情報および装置情報を、ＤＳサーバへ送信する。認証情報および装置情報は、管理セッションのPackage＃１メッセージに含まれる。次に、ステップ１３０で、ＤＳサーバは、Package＃２メッセージをＤＳクライアントへ送信し、Package＃２メッセージではセッションアクションのための初期化パッケージが搬送される。その後、ステップ１４０で示されるように、Package＃３〜Package＃４のメッセージを用いて、後続のセッションアクションが実行される。

既存のＤＳ通知メッセージのフォーマットを、図２に示す。

通知メッセージのヘッダ内の各フィールドの説明は以下の通りである。
＜digest＞：：＝１２８＊ビット；ＭＤ５ダイジェスト（摘要）の値
＜version＞：：＝１０＊ビット；バージョン情報
＜ui-mode＞：：＝＜not-specified＞／＜background＞／＜informative＞／＜user-interaction＞；ユーザインタラクションモード
＜not-specified＞：：＝「００」；未指定
＜background＞：：＝「０１」；バックグラウンドモード
＜informative＞：：＝「１０」；情報提供モード
＜user-interaction＞：：＝「１１」；ユーザインタラクションモード
＜initiator＞：：＝＜client＞／＜server＞；セッションイニシエータ
＜client＞：：＝「０」；クライアントによって開始される
＜server＞：：＝「１」；サーバによって開始される
＜future-use＞：：＝２７＊ビット；拡張のために予約されている
＜sessionid＞：：＝１６＊ビット；セッション識別子
＜length-identifier＞：：＝８＊ビット；サーバ識別子の長さ
＜server-identifier＞：：＝＜length-identifier＞＊CHAR(文字)；サーバ識別子
＜vendor-specific＞：：＝ｎ＊ビット；拡張のために予約されている

ＤＳ通知メッセージの通知本体のフォーマットを、図３に示す。図３のnum-syncsフィールドは、同期アクションの数を示している。future-useフィールドは、将来の拡張のために予約されている。sync1からsyncNまでのフィールドは、いくつかの特定の同期アクションを示している。sync-typeフィールドは、同期のタイプを示している。content-typeフィールドは、同期されるべきデータベースのコンテンツのタイプを示している。server-URI-lengthフィールドは、server-URIフィールドの長さを示している。server-URIフィールドは、同期されるべきサーバデータベースの名前を記憶するために用いられる。上述のことからわかるように、ＤＳ通知メッセージは、同期のタイプ、同期されるべきデータベース、その他を示している。

しかしながら、本願発明者は、既存のセッション管理の機構に少なくとも１つの問題があることに気づいた。それは、ＯＴＡインタフェースのリソースの使用効率がよくないことである。たとえば、クライアントとサーバは既にトランスポート層で認証されており、クライアントが認証情報を再度報告する必要はない。クライアントが認証情報をもう一度報告した場合、ＯＴＡインタフェースのリソースが浪費される。あるいは、クライアントとサーバはトランスポート層では既に認証されていても、管理／同期セッションのセットアップの前に、クライアントが認証情報を報告すること及びアプリケーション層で認証が実行されることが、サーバにとっては必要である場合もある。この時点でクライアントが認証情報を報告しない場合、サーバは「クライアントの認証情報がありません」というエラーメッセージを返し、クライアントは、認証情報をもう一度報告しなければならない。したがって、サーバとのインタラクション（対話）がもう一度発生するため、ＯＴＡインタフェースのリソースが浪費される。あるいは、クライアントが完全な装置情報を報告することはサーバにとって必要ではないにも関わらず、クライアントが完全な装置情報をサーバに報告していることもあり、これは、ＯＴＡインタフェースのリソースの浪費になる。

さらに、従来技術では、通知メッセージの受信後にクライアントによって開始される同期のタイプは、クライアントからの一方向のデータ修正情報に従って選択され、低速同期、高速同期、リフレッシュ同期などの同期タイプは、非常に古い。あるインテリジェント（高度）な同期では、同期を要求する２者が、相手のデータ修正情報およびデータベース情報を解析することにより、データ情報およびデータフィンガープリント情報を選択的に送信することが可能である。たとえば、サーバによって指定された同期方向が双方向であれば、クライアントは一方向同期を開始しない。ただし、クライアントが適切な同期機構を選択できない場合には、セッションの効率が低下する可能性がある。

上述のことからわかるように、従来技術ではクライアントは、サーバがクライアントにどのようなアクションをどのように実行することを期待しているかを正確に知ることができないため、クライアントとサーバとの間で複数のインタラクションが行われる場合があり、これはＯＴＡインタフェースのリソースを浪費し、セッション効率を低下させる可能性がある。

本発明の諸実施形態は、ネットワークリソースを節約し、セッション効率を高めることが可能な、通知メッセージ処理方法および装置を提供する。

本発明の一実施形態は、通知メッセージ処理の方法を提供する。本方法は、セッション接続の確立をトリガする通知メッセージをデータ同期（ＤＳ）サーバから受信し、前記通知メッセージは少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送し、通知メッセージで搬送された命令情報に従って対応するアクションをＤＳクライアントが実行することと、を含む。

本発明の一実施形態は、データ同期（ＤＳ）クライアントを提供する。ＤＳクライアントは、セッション接続の確立をトリガする通知メッセージをデータ同期（ＤＳ）サーバから受信する構成された受信モジュールであって、前記通知メッセージは少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する、受信モジュールと、受信モジュールによって受信された通知メッセージを解析して命令情報を取得するよう構成された解析モジュールと、解析モジュールによって通知メッセージから解析された命令情報に従って対応するアクションを実行するよう構成された処理モジュールと、を含む。

本発明の一実施形態は、データ同期（ＤＳ）サーバを提供する。サーバは、セッション接続の確立をトリガする通知メッセージを生成するよう構成された生成モジュールであって、前記通知メッセージは少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する、生成モジュールと、生成モジュールによって生成された通知メッセージをＤＳクライアントへ送信するよう構成された送信モジュールと、を含む。

本発明の一実施形態では、ＤＳクライアントは、セッション接続の確立をトリガする通知メッセージを、データ同期（ＤＳ）サーバから受信する。通知メッセージは、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する。ＤＳクライアントは、通知メッセージで搬送された命令情報に従って、対応するアクションを実行する。ＤＳクライアントは、ＤＳサーバがＤＳクライアントにどのようなアクションを実行することを要求しているか、およびそのアクションの実行様式を、セッション接続の確立をトリガする通知メッセージによって知ることが可能であるため、アクションの様式がサーバの要求を満たさないことに起因して、ＤＳクライアントとＤＳサーバとの間で複数のインタラクションが行われることを防ぐことが可能であり、これによって、ネットワークリソースが節約され、セッション効率が高まる。

従来技術における、ＤＳサーバとＤＳクライアントとの間のセッション管理を示すフローチャートである。 従来技術におけるＤＳ通知メッセージのフォーマットを示す図である。 従来技術におけるＤＳ通知メッセージの通知本体のフォーマットを示す図である。 本発明の種々の実施形態における通知メッセージのフォーマットを示す図である。 本発明の第１の実施形態における通知メッセージの処理方法を示すフローチャートである。 本発明の第１の実施形態における通知メッセージのフォーマットを示す図である。 本発明の第２の実施形態における、２つの「アクション」フィールドを搬送する通知メッセージのフォーマットを示す図である。 本発明の第２の実施形態における、空セッションの開始のアクション命令を搬送する「アクション」フィールドを示す図である。 本発明の第２の実施形態における通知メッセージの処理方法を示すフローチャートである。 本発明の第２の実施形態における、認証情報報告のアクション命令を搬送する「アクション」フィールドを示す図である。 本発明の第２の実施形態における、装置情報報告のアクション命令を搬送する「アクション」フィールドを示す図である。 本発明の第３の実施形態における通知メッセージの処理方法を示すフローチャートである。 本発明の第５の実施形態における通知メッセージの処理システムの構成を示す図である。

以下では、本発明の目的、技術的解決方法、および優位性をより明らかにするために、図面を参照しながら、本発明をより詳細に説明していく。

本発明の種々の実施形態では、セッション接続の確立をトリガする通知メッセージを、図４に示されるようなフォーマットに拡張することにより、少なくとも１つのアクションを実行することをＤＳクライアントに命令する命令情報が、通知メッセージで搬送される。

具体的には、通知メッセージのメッセージ本体は、ＤＳクライアントが実行を命令されるアクションの数Ｎを搬送する４ビットのサイズのアクション数フィールド（num-actionsフィールド）と、拡張のために予約されている予備(future-use)フィールドと、各フィールドが対応するアクションの命令を搬送するＮ個のアクションフィールド（Actionフィールド）と、拡張のために予約されているベンダ固有(vendor-specific)フィールドとを含む。容易に気づかれるように、本発明の一実施形態における通知メッセージの構造は、（図３に示されたような）従来技術における通知メッセージの構造と非常によく似ており、num-actionsフィールドは、図３のnum-syncsフィールドに対応し、Actionフィールドは、図３のsyncフィールドに対応し、future-useフィールドおよびvendor-specificフィールドが同様に予約されている。従来技術における通知メッセージの構造の多くを変更する必要がないため、本発明の諸実施形態は従来技術との互換性を有することができる。

各「アクション」フィールドが、対応するアクションのアクション命令を搬送する方法は、以下のとおりである。

各「アクション」フィールドは、アクションタイプのフィールド（Action-typeフィールド）と、アクション固有情報フィールド（Action-specificフィールド）と、情報長さフィールド（information-lengthフィールド）と、情報フィールド（informationフィールド）とを含む。以下、各「アクション」フィールド内のフィールドについて説明する。
＜Action-type＞：：＝４＊ビット；アクションが属するアクションタイプを搬送する
＜Action-specific＞：：＝２８＊ビット；アクションに固有のパラメータ情報を搬送する
＜information-length＞：：＝８＊ビット；informationフィールドの長さを搬送する
＜information＞：：＝＜information-length＞＊CHAR(文字)；アクションが実行される際に必要な情報を保持する

ここで、アクションタイプとして可能なのは、同期、認証情報報告、装置情報報告、セッション情報表示、または空セッションの開始である。たとえば、「アクション」フィールド内のAction-typeフィールドの値が００００の場合は、認証情報を報告するアクション命令が「アクション」フィールドで搬送されていることが示されている。「アクション」フィールド内のAction-typeフィールドの値が０００１の場合は、装置情報を報告するアクション命令が「アクション」フィールドで搬送されていることが示されている。「アクション」フィールド内のAction-typeフィールドの値が００１０の場合は、セッション情報を表示するアクション命令が「アクション」フィールドで搬送されていることが示されている。「アクション」フィールド内のAction-typeフィールドの値が００１１の場合は、空セッションを開始するアクション命令が「アクション」フィールドで搬送されていることが示されている。「アクション」フィールド内のAction-typeフィールドの値が０１００の場合は、同期を実行するアクション命令が「アクション」フィールドで搬送されていることが示されている。

以下では、本発明の第１の実施形態を説明する。この実施形態は、通知メッセージ処理の方法に関連する。この実施形態に関しては、一例として、以下のケースについて説明を行う。すなわち、同期の実行をＤＳクライアントに命令する「アクション」フィールドが、通知メッセージのメッセージ本体で搬送され、ＤＳクライアントは、「アクション」フィールドに従って同期セッションを開始する。そのフローチャートを、図５に示す。

ステップ５１０で、ＤＳサーバは通知メッセージを生成し、通知メッセージは、同期アクションの実行をＤＳクライアントに命令する命令情報を搬送する。

具体的には、本発明において通知メッセージによってＤＳクライアントが実行を命令されるアクションは、同期のみであるため、メッセージ本体内の「アクション数」フィールドの値は１であり、同期のアクション命令を搬送する「アクション」フィールドのみが含まれる。「アクション」フィールド内の「Action-type（アクションタイプ）」フィールドの値は、（上述のケースの場合は）０１００であり、「Action-specific（アクション固有）」フィールドで搬送されるのは同期アクションに関連するパラメータ情報であり、「information（情報）」フィールドで搬送されるのは同期されるデータベースの識別子（たとえば、そのデータベースの統一資源識別子（Uniform Resource Identifier: URI））であり、「information-length（情報長さ）」フィールドで搬送されるのは、「情報」フィールドの長さ（たとえば、データベースＵＲＩの長さ）である。

ここで、「アクション固有」フィールドはさらに、図６に示されるような、「Direction（方向）」フィールド、「Behavior（挙動）」フィールド、「ID-Valid（ＩＤ有効）」フィールド、「Log-Valid（ログ有効）」フィールド、「Content-type（コンテンツタイプ）」フィールドを含んでいる。以下、これらのフィールドのそれぞれについて説明する。

「方向」フィールドは、同期の方向を示すために用いられ、長さは２＊ビットであり、具体的には以下のとおりである。
＜Direction＞：：＝＜No-Way＞／＜from-server＞／＜from-client＞／＜two-way＞；方向情報
＜No-way＞：：＝「００」；方向なし
＜from-server＞：＝「０１」；サーバから一方向
＜from-client＞：＝「１０」；クライアントから一方向
＜two-way＞：＝「１１」；双方向

「挙動」フィールドは、同期挙動（たとえば、サーバ／クライアント側のデータをリフレッシュするか、保存するか）を示すために用いられ、長さは１＊ビットであり、具体的には以下のとおりである。
＜Behavior＞：：＝＜Preserve＞／＜Refresh＞；同期挙動
＜Preserve＞：：＝「０」；保存
＜Refresh＞：：＝「１」；リフレッシュ（更新）

同期のタイプは、「挙動」フィールドと「方向」フィールドとの組み合わせによって決定されることができる。たとえば、＜方向＞＝０１かつ＜挙動＞＝１である場合、サーバからの一方向で開始されるＤＳセッションであり、同期後にクライアント側のデータがリフレッシュされることを意味する。

「ＩＤ有効」フィールドは、サーバ側でのデータエントリの識別子情報（ＩＤ）は有効かどうかを示すために用いられ、長さは１＊ビットであり、具体的には以下のとおりである。
＜ID-Valid＞：：＝＜valid＞／＜invalid＞；ＩＤの有効性
＜valid：：＝「１」；ＩＤは有効
＜invalid＞：：＝「０」；ＩＤは無効

ＤＳサーバは、２者間の識別子情報のマッピングテーブルを保持する必要があることに注意されたい。

データベースに損傷があると識別子情報が無効になる可能性があり、これは、２者間での機構の選択に影響を及ぼす。たとえば、サーバにある識別子情報が無効である場合は、クライアントがセッションを開始した後に、サーバはまずクライアントに対して、クライアントのフィンガープリントを送信するように要求することが可能であり、サーバはそのフィンガープリントに基づいて、どのデータが既にサーバ側に存在するか、どのデータがサーバ側に存在しないかを特定し、その後、サーバがクライアントに対して、送信が必要なデータを送信するように命令する。

「ログ有効」フィールドは、サーバ側の変更ログが有効かどうかを示すために用いられ、長さは１＊ビットであり、具体的には以下のとおりである。
＜log-Valid＞：：＝＜valid＞／＜invalid＞；変更ログの有効性
＜valid＞：：＝「１」；ログは有効
＜invalid＞：：＝「０」；ログは無効

ログは、ＤＳサーバ側のデータベースの変更およびデータエントリの変更を記録するために用いられる。ログが無効であれば、ＤＳサーバは、ＤＳクライアントのデータエントリのどれが変更されているかをＤＳクライアントに知らせることができない。これは、２者間での同期機構の選択に影響を及ぼす。

「コンテンツタイプ」フィールドは、データベースにあるデータタイプ（たとえば、ｖＣａｒｄの種類や電子メールの種類）を示すために用いられ、長さは２３＊ビットである。

別の実施形態では、「挙動」フィールドおよび「方向」フィールドは、「アクションタイプ」フィールド内にあるように設計されることが可能である。
＜action-type＞：：＝＜data-sync＞＜direction＞＜behavior＞；アクションタイプ情報、４＊ビット
＜data-sync＞：：＝「０」；データ同期、１＊ビット

＜data-sync＞フィールドが０であれば、アクションのタイプがデータ同期であることを意味し、０以外であれば、アクションのタイプが別のものであることを意味する。

「挙動」フィールドおよび「方向」フィールドは、既述のものと同じである。

次に、ステップ５２０でＤＳサーバは生成された通知メッセージをＤＳクライアントに配信する。具体的にはＤＳサーバは、図６に示されたように生成された通知メッセージを、ＯＴＡ ＰＵＳＨまたはセッション開始プロトコル（ＳＩＰ）ＰＵＳＨまたはショートメッセージによって、ＤＳクライアントに配信することができる。

次に、ステップ５３０でＤＳクライアントは受信した通知メッセージを解析し、同期機構を選択する。具体的にはＤＳクライアントは、受信した通知メッセージを解析することによって、メッセージ内の「アクション」フィールドで搬送された同期のアクション命令を取得し、このアクション命令に従って適切な同期機構を選択する。

同期機構の選択は、同期方向の選択、同期データの選択、および同期挙動の選択のうちのいずれか、またはこれらの任意の組み合わせを含む。

同期データの選択は、すべてのデータエントリを送信するか否か、修正されたデータエントリだけを送信するか否か、の選択を含む。

同期挙動の選択は、データフィンガープリント情報を送信するか否か、データエントリの比較を相手方に要求するか否かどうか、相手方において記憶されているデータエントリを受信されたデータエントリで上書きすることを相手方に要求するか否か、の選択を含む。

「アクション」フィールドで搬送されたアクション命令に従ったＤＳクライアントによる適切な同期機構の選択について、いくつかの例を用いて簡単に説明する。

たとえば、ＤＳサーバのＩＤマッピングテーブルが無効である場合、ＤＳクライアントがデータエントリ識別子を送信しても、ＤＳサーバはこれを識別することができない。したがってＤＳクライアントは、データフィンガープリント情報を送信するか、またはすべてのデータを送信することを選択しなければならない。あるいは、ＤＳサーバが多数のデータエントリを修正する場合には、ＤＳクライアントは双方向同期、またはＤＳサーバ一方向同期を選択しなければならず、２者間のデータエントリ修正の競合を防ぐために、データフィンガープリント情報が送信されなければならない。実際には、他にもここで１つ１つ示されない多くの事例がさらにある。

次に、ステップ５４０で、ＤＳクライアントは選択された同期機構を用いて、ＤＳサーバとの同期セッションを開始する。

容易に理解されるように本実施形態では、通知メッセージは同期を実行するアクション命令を搬送する。したがって、ＤＳクライアントは、この情報に従って対応する同期機構を選択することが可能になり、同期機構の選択に関するセッションインタラクションの数が少なくなり、セッションの効率が高くなる。

本発明の第２の実施形態は、通知メッセージ処理の方法を提供する。第２の実施形態は、第１の実施形態とほぼ同様であり、これらの間の違いは、次のとおりである。すなわち、第１の実施形態では、通知メッセージはＤＳクライアントが同期を実行しなければならないことを示すだけであるが、第２の実施形態では、通知メッセージはＤＳクライアントが同期を実行しなければならないことを示すだけでなく、ＤＳクライアントが他のアクションをも実行しなければならないことも示す。

たとえば、ＤＳサーバで生成された通知メッセージは、図７に示されるように、同期の実行をＤＳクライアントに命令する「アクション」フィールドだけでなく、セッション情報を表示するアクションの実行をＤＳクライアントに命令する「アクション」フィールドも搬送する。「アクション１」フィールドは同期アクションを実行するアクション命令を搬送し、これは第１の実施形態の「アクション１」フィールドとまったく同じなので、ここでは説明しない。以下、「アクション２」フィールドについて、具体的に説明する。

「アクション２」フィールド内の「アクションタイプ」フィールドの値（たとえば、００１０）は、「アクション」フィールドの搬送するものが、セッション情報を表示するアクション命令であること、「情報」フィールドの搬送するものが、セッション情報のコンテンツであること、ならびに、「情報長さ」フィールドの搬送するものが、セッション情報のコンテンツ長さであることを示している。

ＤＳクライアントが「アクション２」フィールドを、解析によって取得した後、「情報」フィールド内のセッション情報が、「新着の電子メールがあります」のような表示可能なテキストの形式でユーザに対して表示されることができる。同期セッションが開始され、サーバにある、その新着の電子メールが、ＤＳクライアントに同期される。セッション情報を表示するアクションがＤＳクライアントによって実行される場合には、「アクション２」フィールド内の「アクション固有」フィールドの情報は不要なので、ＤＳクライアントは、「アクション固有」フィールドの解析を無視してよい。

実際には、ＤＳクライアントが通知メッセージから「アクション１」フィールドを解析により取得した後に、「アクション１」フィールドで搬送された同期アクションのアクション命令に従って同期セッションを開始することも要求されるが、この処理については第１の実施形態の説明において説明されているので、ここでは説明を繰り返さない。

さらに、通知メッセージは、空セッションアクションの開始をＤＳクライアントに命令する「アクション」フィールドを搬送することもできる。ＤＳクライアントが「アクション」フィールドを解析により取得した後、ＤＳクライアントは、「アクション」フィールド内の「アクションタイプ」フィールドの値から、ＤＳクライアントが空セッションを開始することをＤＳサーバが期待していることを知ることができる。「アクションタイプ」フィールドの値が００１１であるとすると、これは「アクション」フィールドの搬送するものが空セッションを開始するアクション命令であることを示しており、この「アクション」フィールドを、図８に示す。

ＤＳサーバは、ＤＳクライアントによって開始された空セッションに基づいて、データ同期または装置機能に関して、ＤＳクライアントとネゴシエートすることができる。たとえば、空セッションがセットアップされた後、ＤＳサーバがＤＳクライアントの装置情報を必要とした場合は、以下の「獲得（Ｇｅｔ）」コマンドを送信することにより、装置情報が取得することができる。
＜Get＞
＜CmdID＞１＜／CmdID＞
＜Item＞
＜Target＞
＜LocURI＞．／DevInfo＜／LocURI＞
＜／Target＞
＜／Item＞
＜／Get＞

ＤＳクライアントが、空セッションを開始するアクションを実行する場合には、「アクション２」フィールド内の「アクション固有」フィールドの情報は不要なので、ＤＳクライアントは、「アクション固有」フィールドの解析を無視してよい。

容易に理解されるように、ＤＳクライアントに対するアクション命令は、実際には通知メッセージの「アクション」フィールドで搬送され、各「アクション」フィールドは互いに独立している。したがって、通知メッセージは、１つの「アクション」フィールドだけを搬送することも、複数の「アクション」フィールドを搬送したりすることもある。搬送される「アクション」フィールドは、同期アクションのアクション命令、空セッションを開始するアクション命令、または、セッション情報を表示するアクション命令であってよい。さらに、認証情報や装置情報を報告するアクション命令であってもよい。認証情報や装置情報を報告するアクション命令を「アクション」フィールドで搬送することについては、次の第３の実施形態の説明において説明する。

本発明の第３の実施形態は、通知メッセージ処理の方法を含む。本実施形態では、通知メッセージのメッセージ本体は、認証情報の報告をＤＳクライアントに命令する「アクション」フィールドと、装置情報の報告をＤＳクライアントに命令する「アクション」フィールドとを搬送する。ＤＳクライアントは、それら２つの「アクション」フィールドに従って、認証情報および装置情報を報告する。その具体的なフローチャートを、図９に示す。

ステップ９１０で、ＤＳサーバは、セッション接続の確立をトリガする通知メッセージを生成する。このメッセージは、認証情報および装置情報を報告するアクション命令を搬送する。

認証情報を報告するアクション命令を「アクション」フィールドが搬送する様式を、図１０に示す。「アクション」フィールド内の「アクションタイプ」フィールドの値（たとえば、００００）は、現在の「アクション」フィールドの搬送するものが認証情報を報告するアクション命令であること、「情報」フィールドの搬送するものが（クライアントが報告することを求められている）認証情報が属する認証機構（たとえば、基本認証（ａｕｔｈ−ｂａｓｉｃ）認証機構、ＭＤ５認証（ａｕｔｈ−ＭＤ５）認証機構、ＳＨＡ−２５６認証機構、ＳＨＡ−１認証機構、または未指定の機構の認証機構）であること、「情報長さ」フィールドの搬送するものが「情報」フィールド内の認証機構の長さであることを示している。以下、「情報長さ」フィールドおよび「情報」フィールドについて説明する。
＜information-length＞：：＝８＊ビット；認証機構の長さ
＜information＞：：＝＜auth-basic＞／＜auth-MD5＞／＜SHA-256＞／＜SHA-1＞／＜not specified＞；認証機構
＜auth-basic＞；基本認証機構
＜auth-MD5＞；ＭＤ５認証機構
＜SHA-256＞；ＳＨＡ−２５６認証機構
＜SHA-1＞；ＳＨＡ−１認証機構
＜not specified＞；未指定の認証機構

＜information＞：：＝＜not specified＞である場合、これは、ＤＳサーバが認証機構を指定せず、ＤＳクライアントはＤＳ標準におけるパラメータ構成「Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ」の認証タイプ「ＡＡｕｔｈＰｒｅｆ」の値で指定された認証方法、または最後に成功したセッションで使用された認証方法を用いて認証してよいことを意味することに注意されたい。

装置情報を報告するアクション命令を「アクション」フィールドが搬送する様式を、図１１に示す。「アクション」フィールド内の「アクションタイプ」フィールドの値（たとえば、０００１）は、「アクション」フィールドの搬送するものが装置情報を報告するアクション命令であること、「アクション固有」フィールドの搬送するものが装置情報の報告の様式（たとえば、完全な装置情報の報告、更新された装置情報の報告、空の装置情報の報告、または装置情報データベースの識別子の報告）であること、「情報」フィールドの搬送するものが、ＤＳクライアント内の装置情報が記憶されている位置に関する情報であること、「情報長さ」フィールドの搬送するものが「情報」フィールド内の位置情報の長さであることを示している。以下、「アクション固有」フィールド、「情報長さ」フィールド、および「情報フィールド」について説明する。
＜Action-specific＞：：＝＜completed＞／＜updated＞／＜null＞／ＵＲＩ；装置情報の報告の様式
＜completed＞：：＝「００」；完全な装置情報
＜updated＞：：＝「０１」；更新された装置情報
＜null＞：：＝「１０」；空の装置情報
＜ＵＲＩ＞：：＝「１１」；装置情報データベースの識別子
＜information-length＞：：＝８＊ビット；装置情報の位置リンクフィールドの長さ
＜information＞：：＝＜information-length＞＊CHAR（文字）；装置情報の位置リンク

＜Action-specific＞：：＝＜ＵＲＩ＞である場合、これは、ＤＳクライアントが、ＤＳクライアントの装置情報を記憶しているＵＲＩリンクを報告することを求められていることを示しており、ＤＳサーバは、このアドレスに従ってアクセスすることにより、ＤＳクライアントの装置情報を取り出す。このようにして、ＯＴＡインタフェースのリソースを節約することが可能である。

＜information＞フィールドは、ＤＳクライアント内の装置情報の記憶位置を示している。たとえば、ＤＳサーバがＤＳクライアントに対しすべての装置情報を報告することを求める場合は、＜Action-specific＞フィールドは＜completed＞であり、＜information＞フィールドは、．／．．．／devinfである。ＤＳサーバがＤＳクライアントに対し、更新された装置情報を報告することを求める場合は、＜Action-specific＞フィールドは＜updated＞であり、＜information＞フィールドは、．／．．．／devinf／datastore／CTCAPであり、これは、CTCAP要素下の更新情報を示している。装置情報の一部の詳細は、．／．．．／devinf／datastore／SyncCapのような階層型ＵＲＩで表されることが可能であり、これは、ＤＳクライアントが、SyncCap要素の下の装置情報を報告することを求められていることを意味する。ＤＳクライアント上に、同じ名前を有する複数の要素がある場合、これらは、ＵＲＩの一致条件を付けることで表されることができる。

たとえば、次のように、ＤＳクライアント上に複数のDataStore（データストア）要素があり、DataStoreの下に複数のCTCAP（ＣＴ機能）要素があるとする場合、以下のように表わせる
＜DataStore＞
＜DisplayName＞addressbook＜／DisplayName＞
＜SourceRef＞．．．＜／SourceRef＞
＜CTCap＞
＜CTType＞syncml：filtertype-cgi＜／CTType＞
．．．
＜／CTCap＞
＜CTCap＞
＜CTType＞text/x-vcard＜／CTType＞
．．．
＜／CTCap＞
．．．
＜／DataStore＞
＜DataStore＞
＜DisplayName＞Email＜／DisplayName＞
．．．
＜／DataStore＞

そして、ＤＳクライアントが、＜DisplayName＞がaddressbook（であるデータストアの情報を報告することを、ＤＳサーバから求められている場合、これは、次のＵＲＩで指定されることができる。
．／Devinf／DataStore［DisplayName＝“addressbook”］

さらに、ＤＳクライアントが、＜DisplayName＞がaddressbookであるデータストアの、＜CTCap＞がtext/x-vcardである情報を報告することを、ＤＳサーバから求められている場合、これは、次のＵＲＩで指定されることができる。
．／Devinf／DataStore［DisplayName＝“addressbook”］／CTCap［CTType＝“text/x-vcard

要素ではなく特性が比較される場合は、@Element方法が用いられる。たとえば、．／Devinf／DataStore［@DisplayName＝“addressbook”］。

ステップ９２０で、ＤＳサーバは、２つの「アクション」フィールドを含む、生成された通知メッセージを、ＤＳクライアントに配信する。具体的には、ＤＳサーバは、２つの「アクション」フィールドを含む、生成された通知メッセージを、ＯＴＡ ＰＵＳＨ（またはＳＩＰ ＰＵＳＨ）またはショートメッセージを用いてＤＳクライアントに配信して、セッション接続を要求することができる。

次に、ステップ９３０で、ＤＳクライアントは、受信した通知メッセージを解析して、セッション接続を開始する要求に応じるメッセージを生成する。この、セッション接続を開始するメッセージが、Package＃１メッセージである。

具体的には、ＤＳクライアントは、通知メッセージで搬送された「アクション」フィールドを解析し、後続のPackage＃１メッセージで認証情報および装置情報をどのように報告するかを、２つの「アクション」フィールドでそれぞれ搬送された、認証情報を報告するアクション命令、および装置情報を報告するアクション命令に従って決定する。

次に、ステップ９４０で、ＤＳクライアントは生成されたPackage＃１メッセージをＤＳサーバへ送信する。ステップ９５０および９６０はそれぞれステップ１３０および１４０と同じなので、ここでは説明を繰り返さない。

本実施形態では、ＤＳクライアントは、ＤＳサーバから求められている、認証情報および装置情報の報告の具体的な様式を、通知メッセージ（たとえば、報告された認証情報の機構や、装置情報の報告の様式）によって知ることが可能である。したがって、認証情報および装置情報の報告の様式と、ＤＳサーバの要求との間の矛盾によって、ＤＳクライアントとＤＳサーバとの間で複数のインタラクションが引き起こされるのを防ぐことができり、ネットワークリソースが節約できる。実際の応用では、通知メッセージにおいて、認証情報を報告するアクション命令、または装置情報を報告するアクション命令だけが搬送されることも可能である。

本発明の第４の実施形態は、通知メッセージ処理の方法を含む。本実施形態は第３の実施形態に基づいており、ＤＳサーバが認証機構を指定しない場合、すなわち、＜information＞：：＝＜not specified＞である場合には、ＤＳクライアントの特定のアクションをさらに含む。

その具体的なフローチャートを、図１２に示す。ステップ１２１０から１２５０は、それぞれ、ステップ９１０から９５０と同じなので、説明を繰り返さない。本実施形態では、ＤＳサーバは認証機構を指定しないため、ＤＳクライアントは、パラメータ構成「Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ」をローカルに検索して、認証タイプが「ＡＡｕｔｈＰｒｅｆ」であるノードを探す。このノードが存在していて、値を割り当てられている場合は、その値で示された認証方法で、認証情報が報告される。このノードが存在していない場合、あるいは存在しているが値を割り当てられていない場合は、デフォルトの認証方法で、安全な認証が実行される。たとえば、デフォルトの認証方法は、認証機構が「auth-basic（基本認証）」である認証情報をPackage＃１メッセージで報告することである場合、認証機構が「基本認証」である認証情報がＤＳクライアントによって生成されたPackage＃１メッセージで搬送される。本実施形態では、デフォルトの認証方法での認証は成功すると、認証の成功を示す状態コードが、ＤＳサーバからＤＳクライアントへ送信されるPackage＃２メッセージで搬送される。

次に、ステップ１２６０で、ＤＳクライアントが、受信したPackage＃２メッセージから認証の成功を知った後、このデフォルトの認証方法を後続の認証で用いるために、このデフォルトの認証方法を記録する。これにより、認証が成功する確率を高めることが可能である。具体的には、以下の２つの記録方法がある。

（１）認証方法を指定するための認証タイプがＡＡｕｔｈＰｒｅｆであるノードに、デフォルトの認証方法が記録される。前述の例の場合は、報告のための認証機構が「基本認証」である認証情報の認証方法が、ＡＡｕｔｈＰｒｅｆノードの値として使用され、ＡＡｕｔｈＰｒｅｆノードに記録される。

（２）デフォルトの認証方法がパラメータ構成「Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ」内のノードに記録され、このノードは、拡張され、認証に関連付けられる。前述の例の場合は、パラメータ構成「Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ」内で、認証に関連付けられたノードが拡張され、認証機構が「基本認証」である認証情報を報告する認証方法が、拡張されたノードに記録される。

次に、処理はステップ１２７０へ進む。ステップ１２７０はステップ９６０と同じなので、ここでは説明を繰り返さない。

さらに、ＤＳクライアントがＤＳサーバの通知メッセージを受信すると、ＤＳクライアントは、通知メッセージの受信に成功したことを示す確認情報によりＤＳサーバに応答することができ、その後、命令されたアクションが実行される。または、ある特殊なケースでは、ＤＳクライアントは確認メッセージを返すだけで、ＤＳサーバから命令されたアクションを実行しない。これは、たとえば、ＤＳサーバによって配信された通知メッセージの「Digest（ダイジェスト）」の、ＤＳクライアントによる認証が失敗した場合、ＤＳクライアントがビジーであるためにＤＳサーバから命令されたアクションを実行できない場合、または、ＤＳサーバから命令されたアクションを実行することをユーザが拒否した場合などである。これらの場合では、ＤＳクライアントは、受信状態情報により通知メッセージに応答することができる。

ＤＳクライアントから応答した情報において、次にＤＳサーバによって通知メッセージが配信される際に使用されるべき、新しい認証情報＜ＮｅｘｔＮｏｎｃｅ＞を、ＤＳサーバに向けて搬送することができる。ＤＳクライアントはさらに、状態（たとえば、認証が失敗した、クライアントがビジー、ユーザが拒否した、など）を伝えるために、表１に示されるような状態コード情報を、ＤＳサーバへ送信することが可能である。

たとえば、Package＃１メッセージでは、ＤＳクライアントは、通知メッセージに対して応答することが可能である。このメッセージの一例を以下に示す。
＜SyncML＞
＜SyncHdr＞
．．．
＜／SyncHdr＞
＜SyncBody＞
＜Status＞
＜CmdID＞１＜／CmdID＞
＜CmdRef＞０＜／CmdRef＞
＜MsgRef＞０＜／MsgRef＞ ；通知メッセージに対する応答を示す
＜Chal＞ ；新しい認証情報
＜Meta＞
＜Type xmlns＝'syncml：metinf'＞syncml：auth-md5＜／Type＞
＜Format xmlns＝'syncml：metinf'＞b64＜／Format＞
＜NextNonce xmlns＝'syncml：metinf'＞ZG9iZWhhdmUNCg＝＝＜／NextNonce＞
＜／Meta＞
＜／Chal＞
＜Data＞506＜／Data＞ ；ユーザがセッションを拒否したことを示す
＜／Status＞
．．．
＜／SyncBody＞
＜／SyncML＞

ＤＳサーバは、このメッセージに対して再度応答しなくてよい。

前述の実施形態では、ＤＳクライアントは実際には端末機器であることに注目されたい。ＤＳクライアントに通知メッセージの受信機能がない場合、ＤＳクライアントは、通知クライアントを介して通知メッセージを受信しなければならない。通知クライアントは、サービスの実装に応じて決まる。たとえば、通知メッセージがサービス実装上ＯＴＡ ＰＵＳＨを用いて送信される場合、通知クライアントはＯＴＡ ＰＵＳＨクライアントであり、通知メッセージがショートメッセージを用いて送信される場合、通知クライアントはショートメッセージクライアントである。同様に、ＤＳサーバに通知メッセージの送信機能がない場合、ＤＳサーバは通知メッセージを、通知サーバを介して送信しなければならない。

前述の実施形態では、「アクション数」フィールドの値は、ＤＳクライアントがＤＳサーバから実行を求められているアクションの数を示していることに注意されたい。たとえば、「アクション数」フィールドの値が１であることは、ＤＳクライアントが１つのアクションの実行を求められていることを示している。アクションのタイプと具体的なアクション命令は、１つの「アクション」フィールドで搬送される。「アクション数」フィールドの値が２であることは、ＤＳクライアントが２つのアクションの実行を求められていることを示している。この２つのアクションのタイプと具体的なアクション命令は、２つの「アクション」フィールドで、それぞれ搬送される。ただし、実際には、「アクション数」フィールドの値を０に設定することにより、ＤＳクライアントは、空セッションの開始のアクションを実行するように命令されることが可能である。その場合、通知メッセージは「アクション」フィールドを搬送しなくてよい。さらに、セッション情報の表示のアクションのような特定のアクションの場合は、「アクション」フィールド内の「アクション固有」フィールドは、実際には使用されないので実際の運用時には省略可能である。すなわち、「アクション」フィールド内に使用されないフィールドがある場合、それらのフィールドは省略可能である。

本発明の第５の実施形態は、図１３に示されるような、通知メッセージ処理のシステムを含み、このシステムは、ＤＳクライアント１３１およびＤＳサーバ１３２を含んでいる。

ＤＳサーバ１３２は、生成モジュール２１および送信モジュール２２を含んでおり、生成モジュール２１は、セッション接続の確立をトリガする通知メッセージを生成するように構成されており、通知メッセージは、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送し、送信モジュール２２は、生成モジュールによって生成された通知メッセージを、ＤＳクライアントへ送信するように適合されている。

ＤＳクライアント１３１は、受信モジュール１１と、解析モジュール１２と、処理モジュール１３とを含んでおり、受信モジュール１１は、セッション接続の確立をトリガする通知メッセージを、ＤＳサーバから受信するように構成されており、解析モジュール１２は、受信モジュール１１によって受信された通知メッセージを解析するように構成されており、処理モジュール１３は、解析モジュール１２によって通知メッセージから取得された命令情報に従って、対応するアクションを実行するように構成されている。クライアントが実行を命令されるアクションは、同期、認証情報の報告、装置情報の報告、セッション情報の表示、または空セッションの開始のうちの１つ、またはこれらの任意の組み合わせである。

ＤＳサーバがこれらのアクションに関するアクション命令を通知メッセージで搬送する様式は、図４に示されているので、ここでは説明を繰り返さない。対応するアクションのアクション命令を「アクション」フィールドがどのように搬送するかについても、既述の実施形態において詳細に説明されているため、ここでは説明を繰り返さない。

一般に、本発明の実施形態では、ＤＳクライアントは、ＤＳクライアントが実行することをＤＳサーバが期待しているアクションおよびアクションの具体的な実行様式を、通知メッセージを介して知ることが可能であるため、アクションの実行様式がサーバの要求を満たさないことに起因して、クライアントとサーバとの間で複数のインタラクションが行われることを防ぐことが可能であり、ネットワークリソースが節約され、セッション効率が高まる。

たとえば、通知メッセージは同期を実行するアクション命令を搬送し、ＤＳクライアントはその情報に従ってそれぞれの同期機構を選択するように構成されることが可能であり、したがって、同期機構を選択するセッションインタラクションの数が減り、セッション効率が高まる。

通知メッセージが、認証情報および／または装置情報を報告するアクション命令を搬送する場合、ＤＳクライアントは、ＤＳサーバが必要とする認証情報および／または装置情報を報告する具体的な様式（たとえば、認証情報を報告する機構や、装置情報の報告の様式）を、通知メッセージから知るように構成されることが可能である。認証情報および装置情報を報告する様式がＤＳサーバの要求を満たさないことに起因して、ＤＳクライアントとＤＳサーバとの間で複数のインタラクションが行われることを防ぐことが可能であり、したがって、ネットワークリソースが節約される。

さらに、本発明の一実施形態の通知メッセージの構造は、（図３に示されたような）従来技術における通知メッセージの構造と非常によく似ており、「アクション数」フィールドは、図３の「同期数」フィールドに対応し、「アクション」フィールドは、図３の「同期」フィールドに対応し、「予備」フィールドおよび「ベンダ固有」フィールドもそのままである。したがって、本発明の実施形態は、従来技術における通知メッセージの構造をあまり修正しなくても、従来技術と互換性があるように構成されることが可能である。

本発明の特定の好ましい実施形態を参照することにより、本発明を例示および説明してきたが、当業者であれば理解されるように、本発明の範囲および趣旨から逸脱することなく、それらの実施形態に様々な修正を施すことが可能である。

Claims (16)

1. セッション接続の確立をトリガする通知メッセージであって、セッション情報の表示及び空セッションの開始のうちの少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する前記通知メッセージを、データ同期（ＤＳ）サーバから受信し、
   前記通知メッセージで搬送された前記命令情報に従って、対応するアクションを実行すること、を含み、
   前記通知メッセージを受信後であって前記対応するアクションを実行する前に、前記通知メッセージで搬送された前記命令情報に従って、前記対応するアクションを実行するかどうかを、前記ＤＳクライアントの現在の状態に基づいて決定することをさらに含み、
   前記対応するアクションを実行することが求められている場合には、前記対応するアクションを実行し、
   前記対応するアクションを実行することが求められていない場合には、前記対応するアクションの実行を拒否することを示す確認メッセージを前記ＤＳサーバに応答し、前記確認メッセージが、前記ＤＳクライアントがビジーである、前記通知メッセージの認証に失敗した、又はユーザに拒否された、のいずれか一つを、実行を拒否する理由として搬送する、
   通知メッセージ処理方法。
2. 前記通知メッセージのメッセージ本体は、
   前記クライアントが実行を命令されるアクションの数を搬送するアクション数フィールドと、
   前記対応するアクションのアクション命令を搬送するアクションフィールドと、を備える請求項１に記載の通知メッセージ処理方法。
3. 前記アクションのフィールドは、
   前記アクションが属するアクションタイプを搬送するアクションタイプフィールドと、
   前記アクションに固有のパラメータ情報を搬送するアクション固有情報フィールドと、
   前記アクションを実行する際に必要な情報を搬送する情報フィールドと、
   前記情報フィールドの長さを搬送する情報長さフィールドと、
   を備える請求項２に記載の通知メッセージ処理方法。
4. 前記アクションタイプフィールドで搬送される前記アクションタイプは、同期アクションタイプであり、
   前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、同期されるべきデータベースの識別子であり、
   前記アクションに固有であって、前記アクション固有情報フィールドで搬送される前記パラメータ情報は、データ同期アクションの固有のパラメータ情報であり、
   前記命令情報で命令された前記アクションを実行することは、
   前記データ同期アクションに関連付けられた前記パラメータ情報に従って、同期機構を選択し、
   前記選択された同期機構を用いて、前記ＤＳサーバとのデータ同期セッションを開始すること、
   を含む請求項２に記載の通知メッセージ処理方法。
5. 前記パラメータ情報は、
   同期方向を示す情報と、
   同期挙動を示す情報と、
   前記サーバ側におけるデータエントリの識別子情報が有効かどうかを示す情報と、
   前記サーバ側における変更ログが有効かどうかを示す情報と、
   前記データベースにあるデータタイプを示す情報と、
   のうちの少なくとも１つを含み、
   前記同期挙動を示す情報が、
   データフィンガープリント情報を送信するか否か、
   相手方にデータエントリの比較を要求するか否か、及び
   相手方に記憶されているデータエントリを受信したデータエントリを使用して上書きするか否か、
   のいずれか１つを示す情報を含む、請求項４に記載の通知メッセージ処理方法。
6. 前記同期アクションに関連付けられた前記パラメータ情報に従って同期機構を選択することが、前記同期アクションに関連付けられた前記パラメータ情報に従って、同期方向を選択すること、同期データを送信することを選択すること、同期挙動を選択すること、のうちの少なくとも１つを含み、
   同期方向を選択することは、前記同期方向を、サーバからの一方向、クライアントからの一方向、双方向、または方向なし、となるように選択することを含み、
   同期データを送信することを選択することは、すべてのデータエントリを送信することを選択すること、または修正されたデータエントリだけを送信することを選択することを含み、
   同期挙動を選択することは、データフィンガープリント情報を送信するかどうかを選択すること、データエントリの比較を相手方に要求するかどうかを選択すること、または、前記相手方において記憶されているデータエントリを受信されたデータエントリを用いてリフレッシュすることを前記相手方に要求するかどうかを選択すること、を含む
   請求項４に記載の通知メッセージ処理方法。
7. 前記アクションタイプフィールドで搬送される前記アクションタイプは、認証情報を報告するアクションタイプであり、
   前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記クライアントが報告することを求められている前記認証情報の前記認証機構を含み、
   前記命令情報で命令された前記アクションを実行することは、前記認証機構に従って認証情報を報告することを含む、
   請求項３に記載の通知メッセージ処理方法。
8. 前記アクションタイプフィールドで搬送される前記アクションタイプは、装置情報を報告するアクションタイプであり、
   前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記装置情報が記憶されている、前記クライアント内の位置を示す位置情報を含み、
   前記アクション固有情報フィールドで搬送される前記アクション固有パラメータ情報は、前記装置情報の報告様式を含み、
   前記命令情報で命令された前記アクションを実行することは、
   前記位置情報に基づいて前記装置情報を取得し、
   前記報告様式に従って前記装置情報を報告することを含む、
   請求項３に記載の通知メッセージ処理方法。
9. 前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報はさらに、
   装置情報のうちの、条件を満たす部分を報告することを前記クライアントに命令する条件一致情報を含む、請求項８に記載の通知メッセージ処理方法。
10. 前記アクションタイプフィールドで搬送される前記アクションタイプは、セッション情報を表示するアクションのタイプであり、
    前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記セッション情報のコンテンツであり、
    前記命令情報で命令された前記アクションを実行することは、前記セッション情報のコンテンツを表示することを含む、
    請求項３に記載の通知メッセージ処理方法。
11. 前記アクションタイプフィールドで搬送される前記アクションタイプは、空セッションの開始のタイプであり、
    前記命令情報で命令された前記アクションを実行することは、空セッションを開始することを含む、
    請求項３に記載の通知メッセージ処理方法。
12. ＤＳクライアントが実行を命令される前記アクションは、空セッションの開始のアクションであり、
    前記通知メッセージのメッセージ本体は、前記アクション数フィールドを搬送し、前記アクション数フィールドの値は「０」である、
    請求項１に記載の通知メッセージ処理方法。
13. 前記通知メッセージを受信した後であって、前記対応するアクションを実行する前に、
    前記通知メッセージの受信に成功したことを示す確認メッセージを、前記ＤＳサーバに返すことをさらに含む、請求項１に記載の通知メッセージ処理方法。
14. 前記確認メッセージで新しい認証メッセージを報告することを含む請求項１または１３に記載の通知メッセージ処理方法。
15. 請求項１〜１４のいずれか一項に記載の通知メッセージ処理方法を実行する手段を備える、データ同期（ＤＳ）クライアント。
16. 請求項１〜１４のいずれか一項に記載の通知メッセージ処理方法を実行する手段を備えるデータ同期（ＤＳ）サーバ。

Images