JP5249405B2 - メッセージを処理する方法、システム、サーバ、および端末 - Google Patents

Description

本発明は、通信技術に関し、特に、メッセージを処理する方法、システム、サーバ、および端末に関する。

装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）（ＤＭ）技術は、サーバが端末に対して、パラメータ構成、ファームウェア更新、ソフトウェアのダウンロード、インストール、および削除、故障の診断および修復、端末監視などの管理操作を、ＯＴＡ（Ｏｖｅｒ
Ｔｈｅ Ａｉｒ）方式で行うことを意味する。データ同期（Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）（ＤＳ）技術は、移動装置とネットワークサーバとの間でデータが同期されることを意味し、同期されるデータは、電話帳、アドレス帳、カレンダ、ショートメッセージ、メールなどを含む。

先行のＤＭ技術またはＤＳ技術では、サーバが端末装置に通知メッセージを配信する際に用いる通知メカニズムが提供され、端末装置は、通知内のセッション識別子（ＩＤ）、サーバＩＤ、および他の情報に従って、サーバとのセッション接続を開始する。通知メッセージは、ショートメッセージまたはプッシュ方式で配信される。ＤＭ仕様は、ＤＭサーバが端末装置を管理するメカニズムを提供し、図１に示されるように、セッション管理フローは、以下のステップを含む。

ステップ１０１で、ＤＳまたはＤＭサーバが、セッション接続を要求する通知メッセージを配信する。

ステップ１０２で、端末が通知メッセージを受信した後、セッションを接続するかどうかを、ユーザが直接確認し、確認結果が、セッションを接続することであれば、処理はステップ１０３へ進み、そうでない場合、端末は何の処理も行わない。

ステップ１０３で、端末は、セッション接続を開始し、セッションフローを実行するための初期化パッケージをサーバへ送信する。

ステップ１０４で、サーバは、端末から送信された、セッション接続を開始するための初期化パッケージを受信した後、セッション操作を実行するための初期化パッケージを端末へ送信する。

ステップ１０５で、端末およびサーバは、後続のセッションフローを実行する。

前述の先行技術に基づいて、本願発明者は、前述の発明の方法の、実際の操作プロセスにおいていくつかの問題が発生しうることを見出した。すなわち、端末は、サーバから通知メッセージを受信しても、応答するメカニズムを持たない。したがって、サーバは、端末からのフィードバックを取得できず、通知メッセージを繰り返し送信し続ける。その結果、サーバの処理作業負荷が増大し、占有されるネットワークリソースが増大する。

そこで、本発明の実施形態では、ＤＳまたはＤＭ通知メッセージを拡張することにより、より多くのセッション管理情報を、ＤＳまたはＤＭ通知メッセージで搬送することが可能であり、ＤＳまたはＤＭ端末は、通知メッセージを解析および判断し、解析および判断結果に従って、ＤＳまたはＤＭサーバへ応答メッセージを送信する。それによって、ＤＳまたはＤＭサーバは更に、ＤＳまたはＤＭ端末から返された情報に従って処理を行う。

本発明の実施形態は、以下のステップを含む方法を提供する。

セッションの確立を要求する、サーバからセッション要求側から送信された通知メッセージが端末によって受信され、この通知メッセージは、セッションに関連付けられたセッション管理情報を搬送する。

通知メッセージ内の、セッションに関連するセッション管理情報が取得され、このセッション管理情報に従って、サーバとのセッション接続が端末によって開始される。または、セッション管理情報に従って通知メッセージが端末によって確認され、確認結果に従って応答メッセージが端末によって生成され、この応答メッセージは、サーバへ送信される。前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、前記セッションの前記指示情報は、重要度情報を含む。

本発明の実施形態は更に、ＤＳまたはＤＭ端末を提供し、ＤＳまたはＤＭ端末は、
サーバから送信された、セッション管理情報を搬送する通知メッセージを受信するように適合された通知メッセージ受信モジュールと、
セッション管理情報を取得し、セッション管理情報に従って通知メッセージを確認するように適合されたセッション判断モジュールと、
セッション判断モジュールの確認結果に従って応答メッセージを生成するように適合され、前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、前記セッションの前記指示情報は、重要度情報を含む応答メッセージ生成モジュールと、
セッション判断モジュールの判断結果に従って、応答メッセージ生成モジュールによって生成された応答メッセージを、通知メッセージ送信側へ、通知メッセージのベアラフォームで送信するように適合された応答メッセージ送信モジュールと、
応答メッセージ生成モジュールによって生成された応答メッセージをセッション要求送信側へ送信するように適合されているか、又はセッション判断モジュールの確認結果に従ってサーバとのセッション接続を開始するように適合されたメッセージ送受信モジュールと、を含む。

本発明の実施形態は更に、ＤＳまたはＤＭサーバを提供し、ＤＳまたはＤＭサーバは、
セッションの確立を要求する通知メッセージをＤＳまたはＤＭ端末へ送信するように適合されたセッション通知メッセージ開始モジュールと、
ＤＳまたはＤＭ端末から返された応答メッセージを受信するように適合され、前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、前記セッションの前記指示情報は、重要度情報を含む応答メッセージ受信モジュールと、
応答メッセージで搬送されたコンテンツに従って、対応する処理を実行するように適合された処理モジュールと、を含む。

前述の技術的な解決からわかるように、本方法では、ＤＳまたはＤＭサーバから配信された、セッション接続を要求する通知メッセージが受信された後、メッセージのフォームおよびコンテンツの解析、判断、および認証の結果に従って、応答メッセージがＤＳまたはＤＭサーバへ送信され、これによって、サーバは、さらなる処理を行うために、ＤＳまたはＤＭ端末から返された情報に従って、送信された通知の問題を判断することが可能である。したがって、ＤＳまたはＤＭサーバが、セッション接続がＤＳまたはＤＭ端末によって確立されたことを通知されない場合に、通知メッセージをやみくもに繰り返し送信することを回避することが可能である。更に、端末は、セッションを実行するかどうかを決定するために、かつ、セッションが拒否された場合に応答メッセージでサーバに通知するために、セッションの重要度および目的をあらかじめ認識しており、これによって、サーバが通知メッセージを繰り返し送信することが回避される。

図１は、ＤＳまたはＤＭ端末が、通知サーバから送信された通知メッセージを受信して処理する、先行技術におけるセッション管理のフローチャートである。 図２は、本発明の一実施形態において提供されるメッセージ処理システムの概略構成図である。 図３は、本発明の一実施形態において提供される、図２のシステムに基づいて実施されるメッセージ処理方法のフローチャートである。 図４は、本発明の一実施形態において提供される、ＤＳまたはＤＭ端末内の通知クライアントが応答メッセージを通知サーバへ送信することのシグナリングフローチャートである。 図５は、本発明の一実施形態において提供される、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントが応答メッセージをＤＳまたはＤＭサーバへ送信することのシグナリングフローチャートである。 図６は、本発明の一実施形態において提供される、セッション開始プロトコル（ＳＩＰ）プッシュメッセージによって、ＤＳまたはＤＭサーバへ応答メッセージが送信されることのシグナリングフローチャートである。

本発明の実施形態は、ＤＳまたはＤＭセッションに適用可能なメッセージ処理方法を提供する。この方法では、ＤＳまたはＤＭサーバから配信された、セッション接続を要求する通知メッセージが受信された後、このメッセージのフォームおよびコンテンツを解析、判断、および認証した結果に従って、ＤＳまたはＤＭサーバへ応答メッセージが送信され、これにより、サーバは、ＤＳまたはＤＭ端末から返された情報に従って、さらなる処理を行うために、送信された通知における問題を判断することが可能であり、これによって、ＤＳまたはＤＭサーバが、ＤＳまたはＤＭ端末によってセッション接続が確立されたことを通知されない場合に通知メッセージをやみくもに繰り返し送信することが回避される。更に、端末は、セッションを実行するかどうかを決定するために、かつ、セッションが拒否された場合に応答メッセージでサーバに通知するために、セッションの重要度および目的をあらかじめ認識しており、これによって、サーバが通知メッセージを繰り返し送信することが回避される。

この方法を実現するために、本発明の実施形態は、メッセージ処理システムを提供する。図２は、本発明に従ったシステムの概略構成図であり、これには、端末１００とサーバ側とが含まれている。端末は、主として、ＤＳまたはＤＭクライアント１０１（これは、ＤＭクライアントであっても、ＤＳクライアントであってもよく、ＤＭクライアントおよびＤＳクライアントであってもよく、以降では説明は同じである）と、通知クライアント１０２とを含んでいる。サーバ側は、主として、ＤＳまたはＤＭサーバ２００および通知サーバ３００を含んでいる。

本発明の実施形態では、ＤＳまたはＤＭクライアント１０１は、ＤＳまたはＤＭプロトコルでＤＳまたはＤＭサーバ２００と対話し、ＤＳまたはＤＭクライアント１０１は、メッセージ送受信モジュール１０１１、セッション判断モジュール１０１２、および応答メッセージ生成モジュール１０１３を含んでいる。

メッセージ送受信モジュール１０１１は、ＤＳまたはＤＭサーバから送信されたＤＳまたはＤＭセッションメッセージを受信し、応答メッセージ生成モジュール１０１３によって生成されたＤＳまたはＤＭセッションメッセージをＤＳまたはＤＭサーバ２００へ送信するように適合されている。

セッション判断モジュール１０１２は、通知メッセージで搬送されるセッション管理情報を抽出するように適合されており、セッション管理情報は、メッセージのバージョン情報、メッセージ送信者のＩＤ情報、セッションの目的情報、セッションの指示情報などであり、この中の、セッションの指示情報は、これらに限定されないが、セッションの目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報などを含む。セッション判断モジュール１０１２は、抽出された情報の処理、たとえば、セッションが重要かどうか、ならびにメッセージのバージョン情報が正しいかどうかを、セッションの目的に従って判断すること、送信者のＩＤ情報に従ってダイジェスト認証を実行すること、および他の処理を行うように、更に適合されており、処理結果に従ってメッセージの応答を判断するように適合されている。

セッション判断モジュール１０１２は更に、メッセージのフォーム情報（たとえば、メッセージのフォーマット）を取得し、メッセージのフォーマットを解析し、解析結果に従ってメッセージの応答を判断するように適合されている。

セッション判断モジュール１０１２は更に、サーバ側から送信された通知メッセージのベアラフォーム情報と、通知メッセージから取得された情報とに従って、応答メッセージのフォームおよびコンテンツを判断するように適合されている。

応答メッセージ生成モジュール１０１３は、セッション判断モジュール１０１２の指示に従って、応答メッセージを生成するように適合されている。なお、応答メッセージがＤＳまたはＤＭセッションに基づく場合、応答メッセージ生成モジュール１０１３は、ＤＳまたはＤＭセッションメッセージを生成し、ＤＳまたはＤＭセッションメッセージを、メッセージ送受信モジュール１０１１を介してＤＳまたはＤＭサーバ２００へ送信するように適合されている。一方、応答メッセージが非セッションに基づく場合、言い換えると、応答メッセージが、通知サーバから送信された通知メッセージのベアラフォーム、たとえば、ＳＩＰメッセージ、ＳＭＳ（ショートメッセージサービス）、ＷＡＰ（無線アプリケーションプロトコル）プッシュ、ＳＩＰプッシュなど）に基づいて生成される場合、応答メッセージ生成モジュール１０１３は、応答メッセージの、対応するフォーマット（たとえば、後述される本発明の実施形態において説明される応答メッセージのフォーマット）に従って、かつ、サーバ側の通知サーバから送信された通知メッセージのベアラフォームに従って、対応するフォーマットで応答メッセージを生成し、以下で説明される応答メッセージ送信モジュール１０２２を介して、対応するフォーマットの応答メッセージを通知サーバ３００へ送信するように適合されている。

他の場合には、ＤＳまたはＤＭクライアント１０１は、ポリシー設定モジュール１０１４を更に含んでよく、ポリシー設定モジュール１０１４は、メッセージを応答するかどうかを判断するポリシーを記憶するように適合されており、ポリシーの詳細内容については、以下に示される、本方法の実施形態のポリシーに関連する詳細な紹介を参照されたい。

セッション判断モジュール１０１２は更に、ポリシー設定モジュール１０１４において設定されているポリシーに従って、サーバ側に対してメッセージの応答を行うかどうかを判断するように適合されている。

本発明の実施形態では、端末１００は更に、通知クライアント１０２を含んでおり、通知クライアント１０２は、通知メッセージ受信モジュール１０２１および応答メッセージ送信モジュール１０２２を含んでいる。通知メッセージ受信モジュール１０２１は、通知サーバから送信された通知メッセージを受信するように適合されている。応答メッセージ送信モジュール１０２２は、応答メッセージ生成モジュール１０１２によって生成された応答メッセージを通知サーバへ送信するように適合されている。通知メッセージは、これに限定されないが、ショートメッセージ、ＯＴＡプッシュメッセージ、ＳＩＰプッシュメッセージなどを含む。

本発明のシステムの実施形態では、サーバ側は、ＤＳまたはＤＭサーバ２００および通知サーバ３００を含んでいる。なお、これら２つのサーバの区別は論理的な区別であり、実際の応用では、これら２つのサーバは、１つのＤＳまたはＤＭサーバに統合されてもよい。

ＤＳまたはＤＭサーバ２００は、セッション通知メッセージ開始モジュール２０１、応答メッセージ受信モジュール２０２、および処理モジュール２０３を含んでよい。セッション通知メッセージ開始モジュール２０１は、通知サーバ３００の通知メッセージ送信モジュール３０１に対し、セッション通知メッセージをＤＳまたはＤＭ端末１００へ送信することを要求するように適合されている。応答メッセージ受信モジュール２０２は、通知クライアント１０２から返され、通知サーバ３００の応答メッセージ解決モジュール３０３によって送信された、非セッションに基づく解決済み応答メッセージを受信し、または、ＤＳまたはＤＭクライアント１０１から返された、セッションに基づく応答メッセージを受信するように適合されている。処理モジュール２０３は、受信された応答メッセージで搬送されたコンテンツに従って、さらなる処理を行うように適合されている。たとえば、応答メッセージで搬送されたコンテンツが、ダイジェスト認証が失敗したこと、サーバＩＤが正しくないこと、メッセージのフォーマットが正しくないこと、およびバージョン情報が正しくないことのうちのいずれかを示す情報を含んでいる場合、処理モジュール２０３は、対応するエラーを訂正する。応答メッセージで搬送されたコンテンツが、セッションが拒否されたこと、および通知メッセージが正常に受信されたことのうちのいずれかを示す情報を含んでいる場合、処理モジュール２０３は、通知メッセージを送信しない。なお、通知サーバ３００の応答メッセージ解決モジュール３０３は、ＤＳまたはＤＭサーバ２００内に設けられてもよく、これによって、ＤＳまたはＤＭサーバ２００は、対応する応答メッセージを解決する。

通知サーバ３００は、通知メッセージ送信モジュール３０１、応答メッセージ受信モジュール３０２、および応答メッセージ解決モジュール３０３を含んでよい。通知メッセージ送信モジュール３０１は、通知メッセージを通知クライアント１０２へ送信するように適合されており、応答メッセージ受信モジュール３０２は、通知クライアント１０２から返された応答メッセージを受信し、応答メッセージを応答メッセージ解決モジュール３０３へ送信するように適合されており、応答メッセージ解決モジュール３０３は、応答メッセージ受信モジュール３０２によって通知クライアント１０２から受信された通知メッセージを解決し、解決結果をＤＳまたはＤＭサーバへ送信するように適合されている。

前述のシステムに基づき、本発明の実施形態は更に、ＤＳまたはＤＭセッションに適用可能なメッセージ処理方法を提供する。図３は、本方法の実施形態のフローチャートを示し、これには以下のステップが含まれる。

ステップ３０１で、通知メッセージが受信される。

ＤＳまたはＤＭ端末は、ＤＳまたはＤＭサーバの要求に従って、通知サーバから送信された、ＤＳまたはＤＭセッションの通知メッセージを受信する。通知メッセージは、セッション管理情報を搬送する。セッション管理情報は、これに限定されないが、たとえば、セッション要求側のＩＤ情報、認証情報、セッションの指示情報などを含む。指示情報は、これらに限定されないが、セッションの目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報などを含む。本発明の実施形態では、ＤＳまたはＤＭ通知メッセージを拡張することにより、セッション管理情報は、通知メッセージに含められ、ＤＳ通知およびＤＭ通知のメッセージボディ部分のフォーマットが異なるため、以下ではそれぞれについて説明が行われる。

以下では、ＤＳ通知メッセージを拡張する方法を説明し、拡張されたＤＳ通知のフォーマットを、次の表１に示す。

拡張されたフィールドは、以下のように説明される。
<response-mode> ::= <not-specified> / <response> / <no-response> / <user-decide>; このフィールドは「応答モード」を表す。
<not-specified> ::= "00" ; このフィールドは「未指定」を表す。
<response> ::= "01" ; このフィールドは「応答」を表す。
<no- response > ::= "10"; このフィールドは「応答せず」を表す。
<user-decide> ::= "11"; このフィールドは「ユーザが決定」を表す。
<importance> ::= <not-specified>/<low>/<normal>/<high>; このフィールドは「重要度」を表す。
< not-specified> ::= "00"; このフィールドは「未指定」を表す。
<low> ::= "01"; このフィールドは「低」を表す。
<normal> ::= "10"; このフィールドは「通常」を表す。
<high> ::= "11"; このフィールドは「高」を表す。
<time-out> ::= 5*BIT ; このフィールドは「日単位でのタイムアウト時間」を表す。
<future-use> ::= 18*BIT; このフィールドは「拡張用として予約済み」を表す。
<length-info> ::= 8*BIT; このフィールドは「セッション情報の長さ」を表す。
<info> ::= <length-info>*CHAR; このフィールドは「セッション情報」を表す。
<Op-Code> ::=3*BIT; このフィールドは「操作コード」を表す。

<response-mode>に従って、サーバは、応答メッセージの送信が必要かどうかを端末に
指示する。応答モードが「応答」である場合、これは、端末が、通知メッセージを正常に受信したかどうかを返すことが必要であることを表す。応答モードが「未指定」である場合、端末は、ポリシーに従って、応答メッセージを送信するかどうかを判断することが可能である。応答モードが「応答せず」である場合、端末は、応答メッセージをサーバへ送信する必要がない。応答モードが「ユーザが決定」である場合、端末はユーザに入力を要求し、ユーザは、応答メッセージを応答するかどうかを判断する。

実際の応用において、通知メッセージのトランスポート層が成功または失敗の情報を自動的に応答することをサポートしている場合、サーバは、応答モードを「応答せず」または「未指定」に設定する。通知メッセージのトランスポート層が応答メッセージを自動的に応答することをサポートしていない場合、サーバは、応答モードを「応答」に設定し、アプリケーション層が、応答メッセージで応答する。細かな組み合わせは、状況に応じて決定されることが可能であり、本発明は、それらの様式に限定されない。

<importance>は、セッションの重要度を示すように適合されており、端末は、サーバとのセッション接続を確立することが必要かどうかを、セッションの重要度に従って判断する。なお、重要度は、サーバによって決定され、端末の参照用として適合されているに過ぎない。これは、サーバにとって重要なセッションが、端末にとっては重要でない場合があるためである。端末は、セッションが重要かどうかを、端末の状態、たとえば、端末がビジーである場合や、セッションが端末にとって重要ではない場合に応じて、判断することが可能である。

<time-out>は、通知メッセージのタイムアウト時間を指定するように適合されている。通知メッセージは、セッションＩＤ情報を含んでおり、端末は、セッションＩＤ情報に従って、サーバとのセッション接続を開始する。サーバは、端末のセッション接続を確実に認識するために、この情報を保存することが必要である。指定のタイムアウト時間内に端末がサーバとのセッション接続を開始しない場合、サーバは、リソースを節約するために、この通知の関連情報を保存しない。タイムアウト時間は、日単位であり、０の場合は、時間制限が存在しないことを示している。

<length-info>は、<info>の長さをバイト単位で指定するように適合されている。これ
は、０の場合には、<info>の長さが０であること、すなわち、フィールドが存在しないことを示している。

<info>は、通知の目的、たとえば、「ファームウェアのアップグレードが必要ですか？」を示すように適合されている。端末またはユーザは、この情報に従って、サーバとのセッション接続を開始するかどうかを判断する。

<Op-Code>は、サーバから端末に指示される操作コードである。たとえば、サーバは端
末に、空セッションを開始することを要求したり、あるいは、装置情報を報告することを要求したりする。端末は、セッションを受け入れる場合には、＜操作コード＞の指示に従って、対応するセッションを開始する。

<Op-Code>の値は、次の表２に示されるとおりである。

値が０００の場合、サーバはクライアントに、空セッションを開始することを要求する。セッションが確立された後、サーバは、＜Ｇｅｔ＞コマンドを用いて端末の装置情報を取得したり、あるいは、同期操作を開始したりすることが可能である。

値が００１の場合、サーバはクライアントに、すべての装置情報を報告することを要求する。最初の同期において、クライアントは、すべての装置情報をサーバに報告することが必要である。その後の同期においては、クライアントは、トラヒックを節約するために、更新された装置情報を報告することだけが必要である。

値が０１０の場合、サーバはクライアントに、更新された装置情報を報告することを要求する。クライアントは、＜Ｐｕｔ＞コマンドを用いて、更新された装置情報をサーバに報告することが可能であり、クライアントは、装置情報の更新記録を保存しなければならない。

値が０１１の場合、サーバはクライアントに、装置情報を報告しないことを要求する。サーバがクライアントの装置情報を必要としていない場合、または、サーバがクライアントの装置情報を無用と見なしている場合は、トラヒックを節約するために、サーバはクライアントに、装置情報を報告しないことを要求することが可能である。

次に、ＤＭ通知メッセージを拡張する方法を説明し、拡張されたＤＭ通知のフォーマットを次の表３に示す。

拡張されたフィールドは、以下のように説明される。
<num-MOs>::= 4*BIT;このフィールドは「ＭＯの数」を表す。
<future-use>::= 4*BIT;このフィールドは「拡張用として予約済み」を表す。
<MO1>::= <MOI-length><MOI>;このフィールドは「最初のＭＯＩの情報」を表す。
<MOI-length>::= 8*BIT;このフィールドは「ＭＯＩの長さ」を表す。
<MOI>::= <MOI-length>*CHAR;このフィールドは「ＭＯのＩＤ情報」を表す。
<num-MOs>は、このセッションに関与するＭＯの数を示すように適合されている。後続
のＭＯ１〜ＭＯＮは、ＭＯの詳細情報を示すように適合されている。
<MOI-length>は、ＭＯＩの長さを示すように適合されている。
<MOI>は、ＭＯのＩＤ情報を示すように適合されている。

端末は、特定のポリシーを設定して、<MOI>、<Importance>、または他の情報に従って、サーバとのセッション接続を開始するかどうかを自動的に決定することが可能である。たとえば、重要度レベルが高い場合、端末は、セッションを自動的に許可する。重要度レベルが低い場合、端末は、セッションを自動的に拒否する。たとえば、ＭＯＩが「ｕｒｎ：ｏｍａ：ｍｏ：ｆｕｍｏ：１．０」である場合も、端末は、セッションを自動的に許可する。

ステップ３０２で、通知メッセージのコンテンツが抽出される。

ＤＳまたはＤＭ端末は、通知メッセージで搬送されたコンテンツを抽出する。なお、１つの通知メッセージは、コンテンツの一部、たとえば、セッションの指示情報を搬送することが可能であり、セッションの指示情報は、セッションの重要度値および／または目的情報、操作情報、セッションのタイムアウト情報（応答時間）、ＤＳまたはＤＭサーバによって配信される、ＤＳまたはＤＭ端末の応答ポリシーなどを含む。一方、すべての情報が１つの通知メッセージで搬送されることは必須ではない。明らかに、すべての情報が同時に搬送されてよい。

ステップ３０３で、ＤＳまたはＤＭ端末は、通知メッセージのフォームおよびコンテンツを確認する。

ＤＳまたはＤＭ端末が通知メッセージのフォームおよびコンテンツを確認することには、これに限定されないが、以下の処理が含まれる。ＤＳまたはＤＭ端末は、通知メッセージのフォーマットが正しいかどうかを判断し、メッセージのバージョンが一致しているかどうかを判断し、サーバＩＤが不正かどうか、またはサーバＩＤが存在するかどうかを判断し、ダイジェストが合格したかどうかを、認証情報に従って認証し、セッションの重要度を、取得された、セッションの重要度値に従って決定すること、または、セッションの重要度を、取得された、セッションの目的および端末の現在の状態、たとえば、端末がビジーかどうか、同じセッションが実行されているかどうか、などに従って決定すること、または、取得された、セッションの目的情報をユーザに対して表示し、ユーザがセッションを拒否するか受け入れるかに従って、セッションの重要度を決定することを行う。ＤＳまたはＤＭ端末は更に、ＤＳまたはＤＭサーバからＤＳまたはＤＭ端末に配信された、ＤＳまたはＤＭ端末の応答ポリシーを採用するかどうかを判断する。

ステップ３０４で、応答方法が、ポリシーに従って判断される。ＤＳまたはＤＭセッションを開始する場合、端末は、ＤＳまたはＤＭセッションを開始する、あるいは、何も処理を行わない。ＤＳまたはＤＭセッションを開始しない場合、処理はステップ３０６へ進む。

ポリシーは、ＤＳまたはＤＭ端末にあらかじめ記憶されている応答ポリシーであってよく、ＤＳまたはＤＭサーバからＤＳまたはＤＭ端末に配信された応答ポリシーであってもよい。ＤＳまたはＤＭ端末のポリシーは、これに限定されないが、以下のような、いくつかの状況を含む。１．通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、サーバＩＤは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、かつ、セッションが、セッション管理情報内の指示情報および／または端末の現在の状態に従って、比較的重要と見なされ、受信されることが可能である場合は、メッセージを応答することが必要である。２．通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、ＤＳまたはＤＭサーバＩＤは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、かつ、セッションは、比較的重要と見なされている場合は、メッセージを応答しないことが必要である。３．通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、サーバＩＤは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、しかし、かつ、セッションが、セッション管理情報内の指示情報および／または端末の現在の状態に従って、重要ではないと見なされ、セッションが拒否された場合は、メッセージを応答することが必要である。４．受信されたメッセージが、通知メッセージのバージョンが正しくないこと、フォーマットが正しくないこと、ＤＳまたはＤＭサーバＩＤが正しくないこと、およびダイジェスト妥当性検査に合格していないことのうちのいずれかの状況を有する場合、しかし、セッションが、セッション管理情報内の指示情報および／または端末の現在の状態に従って、比較的重要と見なされ、受信されることが可能である場合は、メッセージを応答することが必要である。５．受信されたメッセージが、バージョンが正しくないこと、フォーマットが正しくないこと、ＤＳまたはＤＭサーバＩＤが正しくないこと、およびダイジェスト妥当性検査に合格していないことのうちのいずれかの状況を有する場合、しかし、セッションが、セッション管理情報内の指示情報および／または端末の現在の状態に従って、重要ではないと見なされ、セッションが拒否された場合は、メッセージを応答することが必要である。実際の応用では、ＤＳまたはＤＭ端末は、ユーザに入力を要求し、ユーザは、応答するかどうかを決定する。ステップ３０３で、端末が、ＤＳまたはＤＭサーバからＤＳまたはＤＭ端末に配信された、ＤＳまたはＤＭ端末の応答ポリシーを採用することを決定した場合、端末は、サーバから配信された応答ポリシーを採用することによって、対応する応答を行う。実際の応用では、メッセージを応答することが必要であることがすぐにデフォルトとして決定され、このステップは省略可能である。

ステップ３０５で、応答メッセージのフォームおよびコンテンツが決定され、応答メッセージが生成される。

ステップ３０４に従って、メッセージを応答することが必要であると判断された場合、ステップ３０３における、メッセージに対する様々な解析および認証結果、ならびに、通知メッセージの様々なベアラフォームに応じて、応答メッセージのフォームおよびコンテンツは、以下で述べられるルールに従って決定される。

応答メッセージの様々なフォームおよびコンテンツは、応答を必要とする４つの状況に応じて、それぞれ決定される。

第１の状況（前述の１）では、ＤＳまたはＤＭ端末内の通知クライアントが、通知メッセージのベアラフォームに従ってメッセージを応答することが可能な場合、通知クライアントは、サーバ側の通知メッセージが正常に受信されたという内容のメッセージで、通知サーバに応答する。応答メッセージのコンテンツは、応答メッセージで搬送されるステータスコードで表され、詳細については、以下に示される本方法の実施形態を参照されたい。そうでない場合、ＤＳまたはＤＭ端末内の通知クライアントは、通知メッセージのベアラフォームに従ってメッセージを応答することができない、あるいは、通知クライアントが通知メッセージのベアラフォームに従ってメッセージを応答することが可能であっても、通知サーバの応答メッセージのＩＤが存在しないため、メッセージを応答することができない。この場合、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントは、サーバ側の通知メッセージが正常に受信されたという内容のメッセージで、応答する。たとえば、通知クライアントは、ＳＭＳ方式で通知サーバから送信された通知メッセージを受信するが、通知サーバの応答番号が存在しないため、メッセージを応答することができない。この応答メカニズムでは、通知メッセージは、メッセージを応答するためのＤＳまたはＤＭセッションを開始することなく、便利に応答される。明らかに、通知クライアントがメッセージを応答できるかどうかは問題ではないと見なされることが可能であり、ＤＳまたはＤＭクライアントがメッセージにより応答することが直接決定される。

第２の状況（前述の３）では、第１の状況と同様に、ＤＳまたはＤＭ端末内の通知クライアントがメッセージを応答することが可能な場合には、通知クライアントは、メッセージで応答する。そうでない場合、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントは、セッションが拒否されたという内容のメッセージにより、応答する。同様に、通知クライアントがメッセージにより応答することが可能かどうかを考慮することなく、ＤＳまたはＤＭクライアントが、セッションが拒否されたという内容のメッセージにより応答することを直接決定することが可能である。

第３の状況（前述の４）では、受信されたメッセージが、ＤＳまたはＤＭサーバＩＤが正しくない状況、およびダイジェスト妥当性検査に合格していない状況のうちの１つを有する場合、ＤＳまたはＤＭクライアントは、ＤＳまたはＤＭサーバＩＤが正しくないか、ダイジェスト妥当性検査に合格していないために、メッセージを応答することができず、通知クライアントは、ＤＳまたはＤＭサーバＩＤが正しくないか、ダイジェスト妥当性検査に失敗したという内容のメッセージにより、応答する。受信されたメッセージが、バージョンが正しくないか、あるいはフォーマットが正しくない状況を有する場合は、第２の状況と同様に、通知クライアントまたはＤＳまたはＤＭクライアントは、通知メッセージが正しくないという内容、具体的には、メッセージのバージョンが正しくないか、メッセージのフォーマットが正しくないというエラータイプのメッセージを応答するために選択される。

第４の状況（前述の５）では、受信されたメッセージが、ＤＳまたはＤＭサーバＩＤが正しくない状況、およびダイジェスト妥当性検査に合格していない状況のうちの１つを有する場合、ＤＳまたはＤＭクライアントは、ＤＳまたはＤＭサーバＩＤが正しくないか、ダイジェスト妥当性検査に合格していないために、メッセージを応答することができず、通知クライアントは、セッションが拒否されたという内容のメッセージにより、応答する。受信されたメッセージのバージョンが正しくないか、あるいはフォーマットが正しくない場合は、第２の状況と同様に、通知クライアントまたはＤＳまたはＤＭクライアントは、セッションが拒否されたという内容のメッセージを応答するために選択される。応答メッセージは、応答メッセージのコンテンツおよびフォームに従って生成される。

ステップ３０６で、ＤＳまたはＤＭ端末は、メッセージで応答する。

ＤＳまたはＤＭ端末内の通知クライアントがメッセージにより応答する場合、通知クライアントは、応答メッセージを、サーバによる認識が可能な、指定のフォーマットにパッケージし、パッケージされたメッセージを通知サーバへ送信する。フォーマットの詳細については、本発明による方法の実施形態の、関連するステップの詳細説明を参照されたい。

ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントがメッセージにより応答する場合、ＤＳまたはＤＭクライアントは、サーバセッション通知メッセージの応答としてＤＳまたはＤＭサーバへ送信されたセッションメッセージの中の対応するコンテンツを搬送する。搬送方法の詳細については、本発明による方法の実施形態の、関連するステップの詳細説明を参照されたい。

ＤＳまたはＤＭセッションを開始することは、応答メッセージの１つとして用いられることが可能である。

以下では、２つの実施形態を説明する。第１の実施形態では、通知クライアントを経由して、メッセージにより応答する方法を説明する。第２の実施形態では、ＤＳまたはＤＭクライアントを経由して、メッセージを応答する方法を説明する。

図４は、本発明による方法の第１の実施形態のシグナリングフローチャートを示しており、これには以下のステップが含まれる。

ステップ４０１では、ＤＳまたはＤＭサーバが、セッション管理関連情報を提供し、通知メッセージをＤＳまたはＤＭ端末に配信することを通知サーバに要求する。通知サーバは、ショートメッセージサーバ、ＯＴＡ ＰＵＳＨサーバ、またはＳＩＰ ＰＵＳＨサーバなどとして実装されることが可能である。

関連する管理情報の内容については前述されているので、ここでは繰り返さない。

ステップ４０２で、通知サーバが、ＤＳまたはＤＭ端末に通知メッセージを配信し、セッション接続を要求する。通知メッセージは、セッション管理目的、重要度、および他の情報を含み、配信方式は、ショートメッセージやＯＴＡ ＰＵＳＨなどであってよい。

ステップ４０３で、端末内の通知クライアントが、通知メッセージをＤＳまたはＤＭクライアントへ転送する。

ステップ４０４で、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントは、メッセージのコンテンツ、たとえば、ＤＳまたはＤＭサーバＩＤを抽出し、通知メッセージ内のダイジェストを認証し、メッセージのフォーマットを解析し、セッションの重要度を判断する。

ＤＳまたはＤＭ端末は、メッセージを応答することが必要かどうかを、ＤＳまたはＤＭ端末内であらかじめ設定および保存されている前述のポリシーに従って判断する。たとえば、ＤＳまたはＤＭサーバＩＤが正しくない場合、ダイジェスト認証が失敗した場合、または通知のフォーマットが正しくない場合、端末は、通知メッセージの応答として、対応するエラー情報により、サーバに応答する。

ＤＳまたはＤＭサーバＩＤが正しい場合、ダイジェスト認証が成功した場合、または通知のフォーマットが正しい場合、端末は、通知メッセージの応答として、対応する情報、たとえば、端末がメッセージを正常に受信したことを示す情報により、サーバに応答することが可能である。

ステップ４０５で、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントは、通知メッセージが正常に受信されたかどうかを示すために、ステータスコードおよび応答メッセージを生成する。

メッセージを正常に受信した場合、端末は、２００（成功）情報により応答する。ＤＳまたはＤＭサーバＩＤが正しくない場合、ダイジェスト認証が失敗した場合、または通知のフォーマットが正しくない場合、端末は、対応するエラーコードにより、通知サーバに応答する。ステータスコードの詳細な対応テーブルを、表５に示す。

ステップ４０６で、ＤＳまたはＤＭクライアントは、応答メッセージを通知クライアントへ転送する。

なお、ＤＳまたはＤＭクライアントが、応答メッセージを通知クライアントへ転送することを決定する前に、通知メッセージにより応答することを、通知メッセージのベアラフォームおよび通知サーバの応答番号に従って決定することが必要である。

ステップ４０７で、通知クライアントは、応答メッセージを、後述の表４に示されるような指定のフォーマットにパッケージする。

ステップ４０８で、通知クライアントは、パッケージされた応答メッセージを通知サーバへ転送する。

ステップ４０９で、通知サーバは、応答メッセージに従って、後続の処理を行う。

端末から返されたステータスコードが、メッセージが正常に受信されたことを示している場合、通知サーバは、通知メッセージを再送信しない。端末から返されたステータスコードがエラーコードである場合、サーバは、発生した障害の状況に応じて通知メッセージを再生成し、この通知メッセージを端末へ再送信する。たとえば、フォーマットが正しくない場合、サーバは、メッセージのフォーマットをチェックする。ダイジェストが正しくない場合は、ダイジェストを生成するために、認証情報が再取得される。

ステップ４１０で、通知サーバは、処理結果をＤＳまたはＤＭサーバへ送信する。

上述の実施形態からわかるように、通知メッセージのフォームおよびコンテンツを解析、判断、および認証することによって、メッセージにおける問題、たとえば、フォーマットの問題、ＤＳまたはＤＭサーバＩＤの問題、認証が成功していないという問題、バージョンが正しくないという問題など、が判断されることが可能である。あるいは、サーバによって開始されたセッションが重要でないことが判断されることが可能である。これらの問題は、サーバに送信される応答メッセージで搬送され、これによって、サーバは、通知メッセージが正常に受信されたかどうかを認識し、通知メッセージを送信しないようにする。あるいは、サーバは、フォーマット、バージョン、およびサーバＩＤの問題がメッセージに存在することを認識すると、関連する情報を訂正して、更新された通知メッセージを時間どおりに送信して、セッションを実行する。あるいは、サーバは、端末がセッションを拒否したという情報を認識した後は、セッションメッセージをやみくもに再送信しない。

なお、ステップ５０５で、ＤＳまたはＤＭ端末は、応答メッセージを運ぶために、通知の配信時に、ベアラフォームに従ってベアラフォームを選択する。更に、サーバが応答メッセージをよりよく認識することを可能にするために、本発明では、応答メッセージのフォーマットは、次の表４に示されるように設計されている。

<version>や<sessionid>など、いくつかのフィールドは、通知メッセージの場合と同じ意味を有している。他のフィールドは、以下のように説明される。
<status-code>::= 4*BIT;このフィールドは「ステータスコード」を表す。
<length-authname>::= 8*BIT;このフィールドは「認証名の長さ」を表す。
<authname>::= <length-authname>*CHAR;このフィールドは「認証名」を表す。

<status-code>は、ＤＳまたはＤＭ端末を認証するＤＳまたはＤＭサーバに使用される
。<status-code>は、端末によって受信された通知メッセージのステータスコード、たと
えば、成功または失敗を示すように適合されている。可能なステータスコードは、次の表５に示されるとおりである。

なお、フォーマットの設定、または表は、一例として示されており、本発明では、他の同様な設定は除外されないため、示された例に限定されない。

更に、端末から送信されたメッセージが通知の応答メッセージであることを、サーバが具合よく認識することを可能にするために、応答メッセージのコンテンツタイプを次のように定義することが可能である。
Application/vnd.syncml.DM.response application/vnd.syncml.ds.response

サーバは、受信されたステータスコード情報に従って、端末がメッセージを受信した状況を認識することが可能である。

ＤＳまたはＤＭ端末が、ベアラフォームまたは他の理由、たとえば、通知サーバの応答番号を取得することができない、あるいは、通知サーバがＷＡＰ ＰＵＳＨによって通知メッセージを配信した、などにより、通知メッセージにより応答することができない場合、端末は、通知メッセージをＷＡＰ ＰＵＳＨ方式で応答することができない。ここで、端末は、サーバに対して、ＤＳまたはＤＭセッション方式でメッセージを応答することが可能である。たとえば、端末は、通知サーバの対応するエラー情報、またはセッションが拒否されたことを示す情報を応答することが可能である。なお、ＤＳまたはＤＭ端末が通知メッセージのダイジェストに認証に失敗した場合、またはＤＳまたはＤＭサーバＩＤ情報が正しくないことがわかった場合、端末は、そのサーバを信頼することができないので、対応するエラー情報を報告するためのＤＳまたはＤＭセッションを開始しない。通知のフォーマットが正しくなく、バージョンが一致せず、他のエラーも存在する場合、端末は、エラー情報を、ＤＳまたはＤＭセッション方式で報告することが可能である。サーバに対して、ＤＳまたはＤＭセッション方式でメッセージが応答される場合、指定された情報を報告するために、プロトコル内にアラートタイプ（Ａｌｅｒｔ Ｔｙｐｅ）を定義する必要がある（たとえば、ｏｒｇ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ＤＭ．ｎｏｔｉｆｉｃａｔｉｏｎ−ｅｒｒｏｒは、＜データ＞内の関連するエラーコードを示す）。

状況の詳細については、図５を参照されたい。図５は、本発明による方法の第２の実施形態に従って、ＤＳまたはＤＭクライアントを介して、メッセージにより応答することのシグナリングフローチャートであり、以下にプロセスの詳細を示す。

以下、各ステップを示す。

ステップ５０１では、ＤＳまたはＤＭサーバが、セッション管理関連情報を提供し、通知メッセージをＤＳまたはＤＭ端末に配信することを通知サーバに要求する。通知サーバは、ショートメッセージサーバ、ＯＴＡ ＰＵＳＨサーバ、またはＳＩＰ ＰＵＳＨサーバなどとして実装されることが可能である。

関連する管理情報の内容については前述されているので、ここでは繰り返さない。

ステップ５０２で、通知サーバが、ＤＳまたはＤＭ端末に通知メッセージを配信し、セッション接続を要求する。通知メッセージは、セッション管理目的、重要度、および他の情報を含み、配信方式は、ショートメッセージやＯＴＡ ＰＵＳＨなどであってよい。

ステップ５０３で、端末内の通知クライアントが、通知メッセージをＤＳまたはＤＭクライアントへ転送する。

ステップ５０４で、ＤＳまたはＤＭ端末内のＤＳまたはＤＭクライアントは、メッセージのコンテンツ、たとえば、ＤＳまたはＤＭサーバＩＤ、を抽出し、通知メッセージのダイジェストを認証し、メッセージのフォーマットを解析し、セッションの重要度を判断することなどを行う。

ＤＳまたはＤＭ端末は、メッセージを応答することが必要かどうかを、ＤＳまたはＤＭ端末内であらかじめ設定および保存されている前述のポリシーに従って判断する。たとえば、通知のフォーマットが正しくなく、バージョン情報が正しくない場合、端末は、対応するエラー情報で、ＤＳまたはＤＭサーバに応答する。

ＤＳまたはＤＭサーバＩＤが正しく、ダイジェスト認証が成功し、通知のフォーマットが正しく、バージョンが正しい場合、端末は、通知メッセージの応答として、対応する情報、たとえば、端末がメッセージを正常に受信したことを示す情報で、ＤＳまたはＤＭサーバに応答することが可能である。

セッションの重要度は、設定されているポリシーを満たしていない、と、端末が見なした場合、端末は、セッションを拒否する応答メッセージを、ＤＳまたはＤＭサーバへ送信する。

ステップ５０６で、ＤＳまたはＤＭクライアントが、通知メッセージのベアラフォーム、通知サーバの応答番号、および他の情報を確認することにより、対応するポリシーに従って、メッセージを応答することが必要であると判断した場合、ＤＳまたはＤＭクライアントは、通知の形式では応答しないことを決定するか、ＤＳまたはＤＭセッション方式のメッセージにより応答することを直接選択する。応答メッセージの内容は、メッセージのフォーマットが正しくないこと、メッセージのバージョンが正しくないこと、通知メッセージが正常に受信されたこと、またはセッションが拒否されたことを含む。

オプションで、ＤＳまたはＤＭクライアントは、通知メッセージ内の関連情報をユーザに対して表示することが可能であり、セッションを拒否するかどうかを、ＵＩ（ユーザインタフェース）インタフェースで確認することをユーザに要求する。

ステップ５０７で、ユーザは、セッションを拒否することを、入力インタフェースで決定する。

ステップ５０８で、ＤＳまたはＤＭ端末は、ＤＳまたはＤＭサーバとのセッション接続を開始し、セッションを拒否する応答メッセージを送信する。

オプションで、端末がセッションを受け入れた場合、端末は、通知メッセージ内の指示に従って、対応するセッション操作を開始する。たとえば、端末は、空セッションを開始するか、装置情報を報告する。

ステップ５０８で、ＤＳまたはＤＭ端末は、端末がセッションを拒否したことをサーバに通知するために、特別セッションを開始することが必要である。メッセージの使用方法をサーバに通知するために、アラートタイプを定義する必要があり、アラートタイプは、ｏｒｇ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ＤＭ．ｒｅｆｕｓｅｓｅｓｓｉｏｎのように定義されることが可能である。

以下に、メッセージの例を示す。
<Alert>;このフィールドは「アラートコマンド」を表す。
<CmdID>1</CmdID>;このフィールドは「コマンドのシーケンス番号ＩＤ」を表す。
<Data>1226</Data>;このフィールドは「アラートタイプ（１２２６は汎用アラートを表す）」を表す。
<Item>;このフィールドは「データアイテム」を表す。
<Meta>;このフィールドは「データアイテムの説明情報」を表す。
<Type xmlns="syncml:metinf">;このフィールドは「アイテムタイプ」を表す。
org.openmobilealliance.dm.refuse-session;このフィールドは「セッションが拒否
された」を表す。
</Type>
<Format xmlns="syncml:metinf">b64</Format>;<Data>のデータフォーマット。
</Meta>
<Data>abc... </Data>;このフィールドは「データコンテンツ」を表す。
</Item>
</Alert>

あるいは、アラートタイプは個別に拡張されている。たとえば、アラート１２２０は、セッションが拒否されたことを示す情報をサーバに報告するように適合されている。

以下に、メッセージの例を示す。
<Alert>;このフィールドは「通知コマンド」を表す。
<CmdID>1</CmdID>
<Data>1220</Data>;このフィールドは「端末がセッションを拒否したことを表す通知タイプ」を表す。
<Item> ... </Item>
</Alert>

更に、メッセージのフォーマットが正しくなく、メッセージのバージョンが正しくなく、通知メッセージが正常に受信されたことを示す情報を、メッセージ内のアラート要素で搬送することが可能である。

トラヒックを節約するために、ＤＳまたはＤＭサーバは、セッションを拒否する応答メッセージを受信した場合には、メッセージで応答しなくてよい。

前述の本実施形態の説明からわかるように、ＤＳまたはＤＭ端末は、ＤＳまたはＤＭサーバによって開始されたセッションが重要かどうかを、あらかじめ通知メッセージによって認識する。たとえ、サーバから配信された通知メッセージが、セッションが重要であることを示している場合でも、端末は、そのセッションが重要かどうかを、端末の状態に応じて判断する。端末は、セッションが重要ではないと決定した場合には、セッションを拒否する応答情報をすぐにサーバへ送信し、これによって、ＤＳまたはＤＭサーバが、端末がセッションを開始したことを通知されるまで通知メッセージを繰り返し送信することを防ぎ、サーバ処理およびネットワークリソースが浪費されるのを防ぐ。したがって、端末は、セッションの目的および重要度をあらかじめ認識するため、実行中のセッションの重要度が要件を満たさないことが検出された場合にそのセッションが拒否されるという状況が回避され、これによって、端末の処理リソースならびにネットワークの伝送リソースの浪費を防ぐことができる。

たとえば、通知サーバとして動作するＳＩＰプッシュエージェントが通知メッセージを送信する、第３の実施形態において、本発明による、ＤＳまたはＤＭセッションに適用可能なメッセージ処理方法を更に説明する。これにより、当業者であれば、本発明のソリューションをより明確に理解されるであろう。この実施形態では、ＳＩＰプッシュ送信側エージェントが通知サーバであり、ＳＩＰプッシュ受信側エージェントが通知クライアントである。プッシュコンテンツは、通知メッセージを含む。プロセスの詳細については、図６を参照されたい。図６は、以下のステップを含む。

ステップ６０１で、ＤＳまたはＤＭサーバが、通知要求をＳＩＰプッシュ送信側エージェントに転送し、通知メッセージの送信を要求する。

ステップ６０２で、ＳＩＰプッシュ送信側エージェントサーバは、通知のコンテンツをＤＳまたはＤＭ端末に配信する。

ＳＩＰプッシュ送信側エージェントサーバは、ＳＩＰプッシュプロトコルを用いて、ＤＳまたはＤＭ端末内のＳＩＰプッシュ受信側エージェント（すなわち、通知クライアント）に通知メッセージを配信する。

この実施形態における、通知のダイジェストおよびメッセージヘッダの内容を、次の表６に示す。

通知のメッセージボディ部のコンテンツを、次の表７に示す。

この通知のコンテンツは、ＳＩＰのＭＥＳＳＡＧＥメソッドを用いて配信される。このＳＩＰメッセージの例を以下に示す。
MESSAGE sip:user@domain.com SIP/2.0
Via:SIP/2.0/TCP serverpc.domain.com;branch=z9hG4bk776sgdkse;
Max-Forwards: 70
From: sip:server@domain.com;tag=49583
To: sip:user@domain.com
Call-ID: asd88asd77@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: application/vnd.syncml.dm.notification
Content-Length: (…)
［−−通知メッセージがここに入る！−−］

ステップ６０３で、ＳＩＰプッシュ受信側エージェントが、ＤＳまたはＤＭクライアントへ通知メッセージを送信する。

ＤＳまたはＤＭ端末は、ＳＩＰを用いて、プッシュコンテンツに応答する。このメッセージの例を以下に示す。
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bk123dsghds;
Via:SIP/2.0/TCP senderpc.domain.com;branch=z9hG4bk776sgdkse;
From: sip:server@domain.com;tag=49394
To: sip:user@domain.com
Call-ID: asd88asd77@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: application/vnd.syncml.dm.response
Content-Length: (…)
［−−通知応答メッセージがここに入る！−−］

通知の応答メッセージのコンテンツおよびフォーマットを、次の表８に示す。

ステップ６０４で、ＤＳまたはＤＭクライアントが、通知メッセージのコンテンツに従って、認証、解析、および判断を行う。細かなプロセスは本方法の実施形態と同じであり、ＤＳまたはＤＭクライアントは、認証、解析、および判断の結果、ならびに、対応するポリシーに従って、応答メッセージのフォームおよびコンテンツを決定する。

たとえば、上述のプロセスに従って、ＳＩＰプッシュ受信側エージェントによりメッセージを用いて応答することが決定された場合、処理はステップ６０５へ進む。ＤＳまたはＤＭ端末が、設定されているポリシーに従って、セッションの重要度が低いことを知り、セッションがＭＯＩからの診断であって、必須のセッションタイプではないことを認識した場合、ＤＳまたはＤＭ端末は、妨害されて自動的にセッションを拒否することを求めず、処理はステップ６０７へ進む。

ステップ６０５で、ＳＩＰプッシュ受信側エージェントは、応答メッセージを、ＳＩＰプッシュ送信側エージェントサーバ内のＳＩＰプッシュ送信側エージェントへ、ＳＩＰフォームで送信する。

ステップ６０６で、ＳＩＰプッシュ送信側エージェントサーバが、ＤＳまたはＤＭサーバへ応答メッセージを送信する。

ステップ６０７で、ＤＳまたはＤＭクライアントは、ＤＳまたはＤＭサーバとのＤＳまたはＤＭセッションを開始し、セッションを拒否する応答メッセージを送信する。

セッションを拒否するメッセージのコンテンツの例を以下に示す。
<Alert>;このフィールドは「アラートコマンド」を表す。
<CmdID>1</CmdID>;このフィールドは「コマンドのシーケンス番号ＩＤ」を表す。
<Data>1226</Data>;このフィールドは「アラートタイプ（１２２６は汎用アラートを表す）」を表す。
<Item>;このフィールドは「データアイテム」を表す。
<Meta>;このフィールドは「データアイテムの説明情報」を表す。
<Type xmlns="syncml:metinf">;このフィールドは「アイテムタイプ」を表す。
org.openmobilealliance.dm.refuse-session;このフィールドは「端末がセッ
ションを拒否した」を表す。
</Type>
<Format xmlns="syncml:metinf">b64</Format> ;このフィールドは「＜データ＞のフォーマット」を表す。
</Meta>
<Data>abc... </Data>;このフィールドは「データコンテンツ」を表す。
</Item>
</Alert>

上述の実施形態からわかるように、通知メッセージのフォームおよびコンテンツを解析、判断、および認証することによって、メッセージにおけるエラー、たとえば、フォーマットのエラー、ＤＳまたはＤＭサーバＩＤのエラー、認証が成功していないというエラー、バージョンが正しくないというエラーなどが判断されることが可能である。あるいは、サーバによって開始されたセッションが重要でないことが判断されることが可能である。これらの問題は、サーバに送信される応答メッセージで搬送され、これによって、サーバは、通知メッセージが正常に受信されたかどうかを認識し、通知メッセージを送信しないようにする。あるいは、サーバは、フォーマットエラー、バージョン、およびサーバＩＤがメッセージに存在することを認識すると、関連する情報を訂正して、更新された通知メッセージを時間どおりに送信して、セッションを実行する。あるいは、サーバは、端末がセッションを拒否したという情報を認識した後は、セッションメッセージをやみくもに再送信しない。更に、ＤＳまたはＤＭ端末は、ＤＳまたはＤＭサーバによって開始されたセッションが重要かどうかを、あらかじめ通知メッセージによって認識する。たとえ、サーバから配信された通知メッセージが、セッションが重要であることを示している場合でも、端末は、そのセッションが重要かどうかを、端末の状態に応じて判断する。端末は、セッションが重要ではないと判断した場合には、セッションを拒否する応答情報をすぐにサーバへ送信し、これによって、ＤＳまたはＤＭサーバが、端末からセッションの初期化を通知されるまで通知メッセージを繰り返し送信することを防ぎ、サーバ処理およびネットワークリソースが浪費されるのを防ぐ。あるいは、端末は、セッションの目的および重要度をあらかじめ認識するため、実行中のセッションの重要度が要件を満たさないことが検出された場合にそのセッションが拒否されるという状況が回避され、これによって、端末の処理リソースならびにネットワークの伝送リソースの浪費を防ぐことができる。

当業者であれば、前述の実装方式の説明によって明確に理解されるように、本発明は、ソフトウェアおよび必要な汎用ハードウェアプラットフォームを用いて実現可能であり、明らかにハードウェアによっても実現可能であるが、ほとんどの状況下では、前者がより一層好ましい。この理解に基づいて、本発明の技術的ソリューションは、ソフトウェア製品の形態でほぼ実現され、あるいは、先行技術の一因となる部分は、ソフトウェア製品の形態で実現されることが可能である。このコンピュータソフトウェア製品は、コンピュータのフロッピー（登録商標）ディスク、ハードディスク、または光ディスクのような可読記憶媒体に保存され、コンピュータ装置（パーソナルコンピュータ、サーバ、またはネットワーク装置）が本発明の各実施形態による方法を実行することを可能にする、いくつかの命令を含む。

当業者であれば明らかなように、本発明の範囲または趣旨から逸脱することなく、本発明の構造に様々な修正および変形を施すことが可能である。先述の内容に鑑み、本発明の修正および変形は、添付の特許請求項およびその均等物の範囲に収まる限り、本発明に包含されるものとする。

Claims (10)

1. データ同期（ＤＳ）または装置管理（ＤＭ）のセッションに適用可能なメッセージ処理方法であって、
   端末によって、セッションの確立を要求する、サーバから送信された通知メッセージであって、前記セッションに関連するセッション管理情報を搬送する前記通知メッセージを受信することと、
   前記端末によって、前記セッション管理情報に従って前記通知メッセージを確認し、確認結果に従って、前記通知メッセージのエラー情報を搬送する応答メッセージを生成し、前記サーバが、前記エラー情報のエラータイプに従って対応して前記通知メッセージを修正し、修正された通知メッセージを再送信するよう、前記応答メッセージを、ＤＳまたはＤＭセッションメッセージの形で前記サーバへ送信することと、を含む方法。
2. 前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、
   前記セッションの前記指示情報は、前記セッションの、目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報、を含む請求項１に記載の方法。
3. 前記重要度情報は、前記セッションの重要度を示すように適合されている請求項２に記載の方法。
4. 前記通知メッセージの前記エラー情報は、
   前記通知メッセージ内の、前記サーバの前記ＩＤ情報が正しくないか、存在しないことを示す情報、
   前記通知メッセージのフォーマットが正しくないことを示す情報、
   前記通知メッセージ内の、前記通知メッセージの前記認証情報に対する認証が失敗したことを示す情報、及び
   前記通知メッセージが有効期間を超えたことを示す情報、のうちの１つを含む、請求項１〜３のいずれか１項に記載の方法。
5. データ同期（ＤＳ）または装置管理（ＤＭ）端末であって、
   サーバから送信された、セッション管理情報を搬送する通知メッセージを受信するように適合された通知メッセージ受信モジュールと、
   前記セッション管理情報に従って前記通知メッセージを確認するように適合されたセッション判断モジュールと、
   前記セッション判断モジュールの確認結果に従って、前記通知メッセージのエラー情報を搬送する応答メッセージを生成するように適合された応答メッセージ生成モジュールと、
   前記サーバが、前記エラー情報のエラータイプに従って対応して前記通知メッセージを修正し、修正された通知メッセージを再送信するよう、前記応答メッセージ生成モジュールによって生成された前記応答メッセージを、ＤＳまたはＤＭセッションメッセージの形でサーバへ送信するように適合されたメッセージ送受信モジュールと、
   を含むＤＳまたはＤＭ端末。
6. 前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、
   前記セッションの前記指示情報は、前記セッションの、目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報、を含む請求項５に記載のＤＳまたはＤＭ端末。
7. 前記重要度情報は、前記セッションの重要度を示すように適合されている請求項６に記載のＤＳまたはＤＭ端末。
8. データ同期（ＤＳ）または装置管理（ＤＭ）サーバであって、
   セッションの確立を要求する通知メッセージをＤＳまたはＤＭ端末へ送信するように適合されたセッション通知メッセージ開始モジュールと、
   前記ＤＳまたはＤＭ端末からＤＳまたはＤＭセッションメッセージの形で返された、前記通知メッセージのエラー情報を搬送する応答メッセージを受信するように適合された応答メッセージ受信モジュールと、
   前記エラー情報のエラータイプに従って対応して前記通知メッセージを修正し、修正された通知メッセージを再送信するように適合された処理モジュールと、を備えるＤＳまたはＤＭサーバ。
9. 前記セッション管理情報は、前記サーバの識別子（ＩＤ）情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクト（ＭＯ）のＩＤ情報の少なくも１つを含み、
   前記セッションの前記指示情報は、前記セッションの、目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報、を含む請求項８に記載のＤＳまたはＤＭサーバ。
10. 前記重要度情報は、前記セッションの重要度を示すように適合されている請求項９に記載のＤＳまたはＤＭサーバ。

Images