(57)【要約】  通知メッセージ処理の方法および装置が提供される。本方法は、セッション接続のセットアップを開始する通知メッセージをＤＳサーバから受信することを含み、通知メッセージは、動作の実行をＤＳクライアントに指示する指示情報を含む。ＤＳクライアントは通知メッセージに含まれた指示情報に従って、対応する動作を実行する。
2010509813.tif 000002
【特許請求の範囲】
【請求項１】
セッション接続の確立をトリガする通知メッセージであって、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する前記通知メッセージを、データ同期（ＤＳ）サーバから受信し、
前記通知メッセージで搬送された前記命令情報に従って、対応するアクションを実行すること、を含む通知メッセージ処理方法。
【請求項２】
前記ＤＳクライアントが実行を命令される前記アクションは、
同期と、
認証情報の報告と、
装置情報の報告と、
セッション情報の表示と、
空セッションの開始と、
のうちの少なくとも１つである請求項１に記載の通知メッセージ処理方法。
【請求項３】
前記通知メッセージのメッセージ本体は、
前記クライアントが実行を命令されるアクションの数を搬送するアクション数フィールドと、
前記対応するアクションのアクション命令を搬送するアクションフィールドと、を備える請求項１に記載の通知メッセージ処理方法。
【請求項４】
前記アクションタイプのフィールドは、
前記アクションが属するアクションタイプを搬送するアクションタイプフィールドと、
前記アクションに固有のパラメータ情報を搬送するアクション固有情報フィールドと、
前記アクションを実行する際に必要な情報を搬送する情報フィールドと、
前記情報フィールドの長さを搬送する情報長さフィールドと、
を備える請求項３に記載の通知メッセージ処理方法。
【請求項５】
前記アクションタイプフィールドで搬送される前記アクションタイプは、同期アクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、同期されるべきデータベースの識別子であり、
前記アクションに固有であって、前記アクション固有情報フィールドで搬送される前記パラメータ情報は、データ同期アクションの固有のパラメータ情報であり、
前記命令情報で命令された前記アクションを実行することは、
前記データ同期アクションに関連付けられた前記パラメータ情報に従って、同期機構を選択し、
前記選択された同期機構を用いて、前記ＤＳサーバとのデータ同期セッションを開始すること、
を含む請求項４に記載の通知メッセージ処理方法。
【請求項６】
前記パラメータ情報は、
同期方向を示す情報と、
同期挙動を示す情報と、
前記サーバ側におけるデータエントリの識別子情報が有効かどうかを示す情報と、
前記サーバ側における変更ログが有効かどうかを示す情報と、
前記データベースにあるデータタイプを示す情報と、
のうちの少なくとも１つを含む請求項５に記載の通知メッセージ処理方法。
【請求項７】
前記同期アクションに関連付けられた前記パラメータ情報に従って同期機構を選択することが、前記同期アクションに関連付けられた前記パラメータ情報に従って、同期方向を選択すること、同期データを送信することを選択すること、同期挙動を選択すること、のうちの少なくとも１つを含み、
同期方向を選択することは、前記同期方向を、サーバからの一方向、クライアントからの一方向、双方向、または方向なし、となるように選択することを含み、
同期データを送信することを選択することは、すべてのデータエントリを送信することを選択すること、または修正されたデータエントリだけを送信することを選択することを含み、
同期挙動を選択することは、データフィンガープリント情報を送信するかどうかを選択すること、データエントリの比較を相手方に要求するかどうかを選択すること、または、前記相手方において記憶されているデータエントリを受信されたデータエントリを用いてリフレッシュすることを前記相手方に要求するかどうかを選択すること、を含む
請求項５に記載の通知メッセージ処理方法。
【請求項８】
前記アクションタイプフィールドで搬送される前記アクションタイプは、認証情報を報告するアクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記クライアントが報告することを求められている前記認証情報の前記認証機構を含む、
請求項４に記載の通知メッセージ処理方法。
【請求項９】
前記アクションタイプフィールドで搬送される前記アクションタイプは、装置情報を報告するアクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記装置情報が記憶されている、前記クライアント内の位置を示す位置情報を含み、
前記アクション固有情報フィールドで搬送される前記アクション固有パラメータ情報は、前記装置情報の報告様式を含む、
請求項４に記載の通知メッセージ処理方法。
【請求項１０】
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報はさらに、
装置情報のうちの、条件を満たす部分を報告することを前記クライアントに命令する条件一致情報を含む、請求項９に記載の通知メッセージ処理方法。
【請求項１１】
前記アクションタイプフィールドで搬送される前記アクションタイプは、セッション情報を表示するアクションのタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記セッション情報のコンテンツである、
請求項４に記載の通知メッセージ処理方法。
【請求項１２】
前記アクションタイプフィールドで搬送される前記アクションタイプは、空セッションの開始のタイプである、請求項４に記載の通知メッセージ処理方法。
【請求項１３】
ＤＳクライアントが実行を命令される前記アクションは、空セッションの開始のアクションであり、
前記通知メッセージのメッセージ本体は、前記アクション数フィールドを搬送し、前記アクション数フィールドの値は「０」である、
請求項１に記載の通知メッセージ処理方法。
【請求項１４】
前記対応するアクションを実行する前に、
前記通知メッセージで搬送された前記命令情報に従って、前記対応するアクションを実行するかどうかを、現在の状態に基づいて決定することをさらに含み、
前記対応するアクションを実行することが求められている場合には、前記対応するアクションが実行され、
前記対応するアクションを実行することが求められていない場合には、前記対応するアクションの実行を拒否することを示す確認メッセージが前記ＤＳサーバに応答される、請求項１に記載の通知メッセージ処理方法。
【請求項１５】
前記確認メッセージは、前記アクションの実行を拒否する理由として、
前記クライアントがビジーである、
認証が失敗した、および
ユーザによって拒否された、
のうちのいずれかを搬送する、請求項１４に記載の通知メッセージ処理方法。
【請求項１６】
前記通知メッセージを受信した後であって、前記対応するアクションを実行する前に、
前記通知メッセージの受信に成功したことを示す確認メッセージを、前記ＤＳサーバに返すことをさらに含む、請求項１に記載の通知メッセージ処理方法。
【請求項１７】
前記確認メッセージで新しい認証メッセージを報告することを含む請求項１４または１６に記載の通知メッセージ処理方法。
【請求項１８】
セッション接続の確立をトリガする通知メッセージを、データ同期（ＤＳ）サーバから受信するように構成され、少なくとも１つのアクションの実行を前記ＤＳクライアントに命令する命令情報を搬送する前記通知メッセージを受信するように構成された前記受信モジュールと、
前記受信モジュールによって受信された前記通知メッセージを解析して前記命令情報を取得するように構成された解析モジュールと、
前記解析モジュールによる前記通知メッセージの解析によって取得された前記命令情報に従って、対応するアクションを実行するように構成された処理モジュールと、
を備えるデータ同期（ＤＳ）クライアント。
【請求項１９】
前記クライアントが実行を命令される前記アクションは、
同期と、
認証情報の報告と、
装置情報の報告と、
セッション情報の表示と、
空セッションの開始と、
のうちの少なくとも１つである、請求項１８に記載のＤＳクライアント。
【請求項２０】
セッション接続の確立をトリガする通知メッセージを生成するように構成され、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する前記通知メッセージを生成するように構成された前記生成モジュールと、
前記生成モジュールによって生成された前記通知メッセージを前記ＤＳクライアントへ送信するように構成された送信モジュールと、
を備えるデータ同期（ＤＳ）サーバ。
【請求項２１】
前記クライアントが実行を命令される前記アクションは、
同期と、
認証情報の報告と、
装置情報の報告と、
セッション情報の表示と、
空セッションの開始と、
のうちの少なくとも１つである、請求項２０に記載のＤＳサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本発明は、２００７年５月３０日に出願された中国特許出願第２００７１０１０８３９８．０号「セッション接続及びセッション開始同期方法及び装置（Ｍｅｔｈｏｄ  ａｎｄ  Ｄｅｖｉｃｅ  ｆｏｒ  Ｓｅｓｓｉｏｎ  Ｃｏｎｎｅｃｔｉｏｎ  ａｎｄ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ）」の優先権と、２００７年８月７日に出願された中国特許出願第２００７１０１３７５５５．０号「通知メッセージ処理方法及び装置（Ｍｅｔｈｏｄ  ａｎｄ  Ｄｅｖｉｃｅ  ｆｏｒ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｍｅｓｓａｇｅ  Ｐｒｏｃｅｓｓｉｎｇ）」の優先権とを主張するものであり、これら２件の出願の内容は、参照により、本明細書に組み込まれている。
【０００２】
本発明は、全体として通信分野に関し、特に、データ同期技術の分野における通知メッセージ処理の方法および装置に関する。
【背景技術】
【０００３】
人々の仕事や暮らしにおいて、現代の通信技術の果たす役割がますます重要になるにつれて、データ伝送の品質に関して課される要求はますます高くなっている。データ同期（ＤＳ）は、データ伝送において非常に重要である。ＤＳ技術は、移動装置とネットワークサーバとの間のデータ同期に関する。同期されるデータとしては、電話帳、アドレス帳、スケジュール、ショートメッセージ、メールなどがある。
【０００４】
既存のＤＳメッセージでは、サーバが端末装置に通知メッセージを配信するための通知機構が与えられている。端末装置は、通知メッセージ内のセッションＩＤ（セッション識別子）やサーバＩＤ（サーバ識別子）のような情報に従って、サーバとのセッション接続を開始する。通知メッセージの配信は、ショートメッセージ、ＯＴＡ（Ｏｖｅｒ  ｔｈｅ  Ａｉｒ）技術のＰＵＳＨ（ＯＴＡ  ＰＵＳＨ）などを用いて行われることが可能である。
【０００５】
現行のＤＳサーバとＤＳクライアントとの間のセッションの管理のフローチャートを、図１に示す。ステップ１１０で、ＤＳサーバは、ＤＳクライアントに通知(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（ダイジェスト）」の、ＤＳクライアントによる認証が失敗した場合、ＤＳクライアントがビジーであるためにＤＳサーバから命令されたアクションを実行できない場合、または、ＤＳサーバから命令されたアクションを実行することをユーザが拒否した場合などである。これらの場合では、ＤＳクライアントは、受信状態情報により通知メッセージに応答することができる。
【００８１】
ＤＳクライアントから応答した情報において、次にＤＳサーバによって通知メッセージが配信される際に使用されるべき、新しい認証情報＜ＮｅｘｔＮｏｎｃｅ＞を、ＤＳサーバに向けて搬送することができる。ＤＳクライアントはさらに、状態（たとえば、認証が失敗した、クライアントがビジー、ユーザが拒否した、など）を伝えるために、表１に示されるような状態コード情報を、ＤＳサーバへ送信することが可能である。
【表１】
2010509813.tif 000003
【００８２】
たとえば、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＞
【００８３】
ＤＳサーバは、このメッセージに対して再度応答しなくてよい。
【００８４】
前述の実施形態では、ＤＳクライアントは実際には端末機器であることに注目されたい。ＤＳクライアントに通知メッセージの受信機能がない場合、ＤＳクライアントは、通知クライアントを介して通知メッセージを受信しなければならない。通知クライアントは、サービスの実装に応じて決まる。たとえば、通知メッセージがサービス実装上ＯＴＡ  ＰＵＳＨを用いて送信される場合、通知クライアントはＯＴＡ  ＰＵＳＨクライアントであり、通知メッセージがショートメッセージを用いて送信される場合、通知クライアントはショートメッセージクライアントである。同様に、ＤＳサーバに通知メッセージの送信機能がない場合、ＤＳサーバは通知メッセージを、通知サーバを介して送信しなければならない。
【００８５】
前述の実施形態では、「アクション数」フィールドの値は、ＤＳクライアントがＤＳサーバから実行を求められているアクションの数を示していることに注意されたい。たとえば、「アクション数」フィールドの値が１であることは、ＤＳクライアントが１つのアクションの実行を求められていることを示している。アクションのタイプと具体的なアクション命令は、１つの「アクション」フィールドで搬送される。「アクション数」フィールドの値が２であることは、ＤＳクライアントが２つのアクションの実行を求められていることを示している。この２つのアクションのタイプと具体的なアクション命令は、２つの「アクション」フィールドで、それぞれ搬送される。ただし、実際には、「アクション数」フィールドの値を０に設定することにより、ＤＳクライアントは、空セッションの開始のアクションを実行するように命令されることが可能である。その場合、通知メッセージは「アクション」フィールドを搬送しなくてよい。さらに、セッション情報の表示のアクションのような特定のアクションの場合は、「アクション」フィールド内の「アクション固有」フィールドは、実際には使用されないので実際の運用時には省略可能である。すなわち、「アクション」フィールド内に使用されないフィールドがある場合、それらのフィールドは省略可能である。
【００８６】
本発明の第５の実施形態は、図１３に示されるような、通知メッセージ処理のシステムを含み、このシステムは、ＤＳクライアント１３１およびＤＳサーバ１３２を含んでいる。
【００８７】
ＤＳサーバ１３２は、生成モジュール２１および送信モジュール２２を含んでおり、生成モジュール２１は、セッション接続の確立をトリガする通知メッセージを生成するように構成されており、通知メッセージは、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送し、送信モジュール２２は、生成モジュールによって生成された通知メッセージを、ＤＳクライアントへ送信するように適合されている。
【００８８】
ＤＳクライアント１３１は、受信モジュール１１と、解析モジュール１２と、処理モジュール１３とを含んでおり、受信モジュール１１は、セッション接続の確立をトリガする通知メッセージを、ＤＳサーバから受信するように構成されており、解析モジュール１２は、受信モジュール１１によって受信された通知メッセージを解析するように構成されており、処理モジュール１３は、解析モジュール１２によって通知メッセージから取得された命令情報に従って、対応するアクションを実行するように構成されている。クライアントが実行を命令されるアクションは、同期、認証情報の報告、装置情報の報告、セッション情報の表示、または空セッションの開始のうちの１つ、またはこれらの任意の組み合わせである。
【００８９】
ＤＳサーバがこれらのアクションに関するアクション命令を通知メッセージで搬送する様式は、図４に示されているので、ここでは説明を繰り返さない。対応するアクションのアクション命令を「アクション」フィールドがどのように搬送するかについても、既述の実施形態において詳細に説明されているため、ここでは説明を繰り返さない。
【００９０】
一般に、本発明の実施形態では、ＤＳクライアントは、ＤＳクライアントが実行することをＤＳサーバが期待しているアクションおよびアクションの具体的な実行様式を、通知メッセージを介して知ることが可能であるため、アクションの実行様式がサーバの要求を満たさないことに起因して、クライアントとサーバとの間で複数のインタラクションが行われることを防ぐことが可能であり、ネットワークリソースが節約され、セッション効率が高まる。
【００９１】
たとえば、通知メッセージは同期を実行するアクション命令を搬送し、ＤＳクライアントはその情報に従ってそれぞれの同期機構を選択するように構成されることが可能であり、したがって、同期機構を選択するセッションインタラクションの数が減り、セッション効率が高まる。
【００９２】
通知メッセージが、認証情報および／または装置情報を報告するアクション命令を搬送する場合、ＤＳクライアントは、ＤＳサーバが必要とする認証情報および／または装置情報を報告する具体的な様式（たとえば、認証情報を報告する機構や、装置情報の報告の様式）を、通知メッセージから知るように構成されることが可能である。認証情報および装置情報を報告する様式がＤＳサーバの要求を満たさないことに起因して、ＤＳクライアントとＤＳサーバとの間で複数のインタラクションが行われることを防ぐことが可能であり、したがって、ネットワークリソースが節約される。
【００９３】
さらに、本発明の一実施形態の通知メッセージの構造は、（図３に示されたような）従来技術における通知メッセージの構造と非常によく似ており、「アクション数」フィールドは、図３の「同期数」フィールドに対応し、「アクション」フィールドは、図３の「同期」フィールドに対応し、「予備」フィールドおよび「ベンダ固有」フィールドもそのままである。したがって、本発明の実施形態は、従来技術における通知メッセージの構造をあまり修正しなくても、従来技術と互換性があるように構成されることが可能である。
【００９４】
本発明の特定の好ましい実施形態を参照することにより、本発明を例示および説明してきたが、当業者であれば理解されるように、本発明の範囲および趣旨から逸脱することなく、それらの実施形態に様々な修正を施すことが可能である。
【図１】
2010509813.tif 000004
【図２】
2010509813.tif 000005
【図３】
2010509813.tif 000006
【図４】
2010509813.tif 000007
【図５】
2010509813.tif 000008
【図６】
2010509813.tif 000009
【図７】
2010509813.tif 000010
【図８】
2010509813.tif 000011
【図９】
2010509813.tif 000012
【図１０】
2010509813.tif 000013
【図１１】
2010509813.tif 000014
【図１２】
2010509813.tif 000015
【図１３】
2010509813.tif 000016
【手続補正書】
【提出日】平成21年5月8日(2009.5.8)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
現行のＤＳサーバとＤＳクライアントとの間のセッションの管理のフローチャートを、図１に示す。ステップ１１０で、ＤＳサーバは、ＤＳクライアントに通知(Notification)メッセージを配信して、セッション接続を要求する。次に、ステップ１２０で、ＤＳクライアントは、ＤＳサーバとのセッション接続を開始し、ＤＳクライアントの認証情報および装置情報を、ＤＳサーバへ送信する。認証情報および装置情報は、管理セッションのPackage＃１メッセージに含まれる。次に、ステップ１３０で、ＤＳサーバは、Package＃２メッセージをＤＳクライアントへ送信し、Package＃２メッセージではセッションアクションのための初期化パッケージが搬送される。その後、ステップ１４０で示されるように、Package＃３〜Package＃４のメッセージを用いて、後続のセッションアクションが実行される。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
セッション接続の確立をトリガする通知メッセージであって、少なくとも１つのアクションの実行をＤＳクライアントに命令する命令情報を搬送する前記通知メッセージを、データ同期（ＤＳ）サーバから受信し、
前記通知メッセージで搬送された前記命令情報に従って、対応するアクションを実行すること、を含む通知メッセージ処理方法。
【請求項２】
前記ＤＳクライアントが実行を命令される前記アクションは、
同期と、
認証情報の報告と、
装置情報の報告と、
セッション情報の表示と、
空セッションの開始と、
のうちの少なくとも１つである請求項１に記載の通知メッセージ処理方法。
【請求項３】
前記通知メッセージのメッセージ本体は、
前記クライアントが実行を命令されるアクションの数を搬送するアクション数フィールドと、
前記対応するアクションのアクション命令を搬送するアクションフィールドと、を備える請求項１に記載の通知メッセージ処理方法。
【請求項４】
前記アクションタイプのフィールドは、
前記アクションが属するアクションタイプを搬送するアクションタイプフィールドと、
前記アクションに固有のパラメータ情報を搬送するアクション固有情報フィールドと、
前記アクションを実行する際に必要な情報を搬送する情報フィールドと、
前記情報フィールドの長さを搬送する情報長さフィールドと、
を備える請求項３に記載の通知メッセージ処理方法。
【請求項５】
前記アクションタイプフィールドで搬送される前記アクションタイプは、同期アクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、同期されるべきデータベースの識別子であり、
前記アクションに固有であって、前記アクション固有情報フィールドで搬送される前記パラメータ情報は、データ同期アクションの固有のパラメータ情報であり、
前記命令情報で命令された前記アクションを実行することは、
前記データ同期アクションに関連付けられた前記パラメータ情報に従って、同期機構を選択し、
前記選択された同期機構を用いて、前記ＤＳサーバとのデータ同期セッションを開始すること、
を含む請求項４に記載の通知メッセージ処理方法。
【請求項６】
前記パラメータ情報は、
同期方向を示す情報と、
同期挙動を示す情報と、
前記サーバ側におけるデータエントリの識別子情報が有効かどうかを示す情報と、
前記サーバ側における変更ログが有効かどうかを示す情報と、
前記データベースにあるデータタイプを示す情報と、
のうちの少なくとも１つを含む請求項５に記載の通知メッセージ処理方法。
【請求項７】
前記同期アクションに関連付けられた前記パラメータ情報に従って同期機構を選択することが、前記同期アクションに関連付けられた前記パラメータ情報に従って、同期方向を選択すること、同期データを送信することを選択すること、同期挙動を選択すること、のうちの少なくとも１つを含み、
同期方向を選択することは、前記同期方向を、サーバからの一方向、クライアントからの一方向、双方向、または方向なし、となるように選択することを含み、
同期データを送信することを選択することは、すべてのデータエントリを送信することを選択すること、または修正されたデータエントリだけを送信することを選択することを含み、
同期挙動を選択することは、データフィンガープリント情報を送信するかどうかを選択すること、データエントリの比較を相手方に要求するかどうかを選択すること、または、前記相手方において記憶されているデータエントリを受信されたデータエントリを用いてリフレッシュすることを前記相手方に要求するかどうかを選択すること、を含む
請求項５に記載の通知メッセージ処理方法。
【請求項８】
前記アクションタイプフィールドで搬送される前記アクションタイプは、認証情報を報告するアクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記クライアントが報告することを求められている前記認証情報の前記認証機構を含み、
前記命令情報で命令された前記アクションを実行することは、前記認証機構に従って認証情報を報告することを含む、
請求項４に記載の通知メッセージ処理方法。
【請求項９】
前記アクションタイプフィールドで搬送される前記アクションタイプは、装置情報を報告するアクションタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記装置情報が記憶されている、前記クライアント内の位置を示す位置情報を含み、
前記アクション固有情報フィールドで搬送される前記アクション固有パラメータ情報は、前記装置情報の報告様式を含み、
前記命令情報で命令された前記アクションを実行することは、
前記位置情報に基づいて前記装置情報を取得し、
前記報告様式に従って前記装置情報を報告することを含む、
請求項４に記載の通知メッセージ処理方法。
【請求項１０】
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報はさらに、
装置情報のうちの、条件を満たす部分を報告することを前記クライアントに命令する条件一致情報を含む、請求項９に記載の通知メッセージ処理方法。
【請求項１１】
前記アクションタイプフィールドで搬送される前記アクションタイプは、セッション情報を表示するアクションのタイプであり、
前記アクションを実行する際に必要とされ、前記情報フィールドで搬送される前記情報は、前記セッション情報のコンテンツであり、
前記命令情報で命令された前記アクションを実行することは、前記セッション情報のコンテンツを表示することを含む、
請求項４に記載の通知メッセージ処理方法。
【請求項１２】
前記アクションタイプフィールドで搬送される前記アクションタイプは、空セッションの開始のタイプであり、
前記命令情報で命令された前記アクションを実行することは、空セッションを開始することを含む、
請求項４に記載の通知メッセージ処理方法。
【請求項１３】
ＤＳクライアントが実行を命令される前記アクションは、空セッションの開始のアクションであり、
前記通知メッセージのメッセージ本体は、前記アクション数フィールドを搬送し、前記アクション数フィールドの値は「０」である、
請求項１に記載の通知メッセージ処理方法。
【請求項１４】
前記対応するアクションを実行する前に、
前記通知メッセージで搬送された前記命令情報に従って、前記対応するアクションを実行するかどうかを、現在の状態に基づいて決定することをさらに含み、
前記対応するアクションを実行することが求められている場合には、前記対応するアクションが実行され、
前記対応するアクションを実行することが求められていない場合には、前記対応するアクションの実行を拒否することを示す確認メッセージが前記ＤＳサーバに応答される、請求項１に記載の通知メッセージ処理方法。
【請求項１５】
前記通知メッセージを受信した後であって、前記対応するアクションを実行する前に、
前記通知メッセージの受信に成功したことを示す確認メッセージを、前記ＤＳサーバに返すことをさらに含む、請求項１に記載の通知メッセージ処理方法。
【請求項１６】
前記確認メッセージで新しい認証メッセージを報告することを含む請求項１４または１５に記載の通知メッセージ処理方法。
【請求項１７】
請求項１〜１６のいずれか一項に記載の通知メッセージ処理方法を実行する手段を備える、データ同期（ＤＳ）クライアント。
【請求項１８】
請求項１〜１６のいずれか一項に記載の通知メッセージ処理方法を実行する手段を備えるデータ同期（ＤＳ）サーバ。
【国際調査報告】
2010509813.tif 000017
2010509813.tif 000018
2010509813.tif 000019
2010509813.tif 000020