データ同期DSまたは装置管理DMのセッションに適用可能なメッセージ処理方法であって、端末によって、セッションの確立を要求する、サーバから送信された通知メッセージであって、前記セッションに関連するセッション管理情報を搬送する前記通知メッセージを受信することと、前記端末によって、前記通知メッセージにおいて、前記セッションに関連する前記セッション管理情報を取得することと、前記端末によって、前記セッション管理情報に従って、前記サーバとのセッション接続を開始するか、または、前記端末によって、前記セッション管理情報に従って前記通知メッセージを確認し、確認結果に従って応答メッセージを生成し、前記応答メッセージを前記サーバへ送信することと、を含み、前記セッション管理情報は、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報は、重要度情報を含む方法。前記重要度情報は、前記セッションの重要度を示すように適合されている請求項1に記載の方法。前記確認結果に従って前記応答メッセージを前記生成することの前に、前記端末によって、前記通知メッセージで応答することが必要かどうかを判断し、前記通知メッセージを応答する必要がある場合には、前記確認結果に従って前記応答メッセージを生成することを更に含む請求項2に記載の方法。前記確認結果に従って前記応答メッセージを前記生成することの前に、前記端末によって、前記応答メッセージのフォームを決定することを更に含み、前記応答メッセージの前記フォームは、前記通知メッセージのベアラフォームを前記応答メッセージのベアラフォームとして使用すること、および/または、DSまたはDMセッションメッセージのフォームで、前記通知メッセージにより応答することを含む請求項1から請求項3のいずれか一項に記載の方法。前記応答メッセージは、前記通知メッセージが正常に受信されたことを示す情報、前記通知メッセージのエラー情報、前記セッションが拒否されたことを示す情報、および前記セッションが受け入れられたことを示す情報のうちの1つを搬送する請求項4に記載の方法。前記通知メッセージの前記エラー情報は、前記通知メッセージ内の、前記サーバの前記ID情報が正しくないか、存在しないことを示す情報、前記通知メッセージのフォーマットが正しくないことを示す情報、前記通知メッセージ内の、前記通知メッセージの前記認証情報に対する認証が失敗したことを示す情報、及び前記通知メッセージが有効期間を超えたことを示す情報、のうちの1つを含む請求項5に記載の方法。前記受信された応答メッセージで搬送されたコンテンツに従って、前記サーバが、対応する処理を実行することを更に含み、前記対応する処理を前記実行することは、前記エラー情報のエラータイプに従って対応して前記通知メッセージを修正し、修正された通知メッセージを再送信すること、または前記通知メッセージが端末によって正常に受信されたという情報、または、前記セッションが前記端末によって拒否されたという情報に従って、前記通知メッセージを再送信しないことを含む請求項5に記載の方法。データ同期DSまたは装置管理DM端末であって、サーバから送信された、セッション管理情報を搬送する通知メッセージを受信するように適合された通知メッセージ受信モジュールと、前記セッション管理情報を取得し、前記セッション管理情報に従って前記通知メッセージを確認するように適合され、前記セッション管理情報が、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報が、重要度情報を含むセッション判断モジュールと、前記セッション判断モジュールの確認結果に従って応答メッセージを生成するように適合された応答メッセージ生成モジュールと、前記応答メッセージ生成モジュールによって生成された前記応答メッセージをサーバへ送信するように適合されているか、又は前記セッション判断モジュールの前記確認結果に従って前記サーバとのセッション接続を開始するように適合されたメッセージ送受信モジュールと、を含むDSまたはDM端末。前記セッション判断モジュールは、前記サーバから送信された前記通知メッセージのベアラフォームに従って、前記応答メッセージのフォームを判断するように更に適合されており、前記メッセージ送受信モジュールは、前記セッション判断モジュールの前記確認結果に従って、前記応答メッセージを前記サーバへ、DSまたはDMセッションメッセージフォームで送信するように更に適合されており、前記セッション判断モジュールの前記確認結果に従って、前記応答メッセージを前記サーバへ、前記通知メッセージの前記ベアラフォームで送信するように適合された応答メッセージ送信モジュールを更に備える請求項8に記載のDSまたはDM端末。前記セッション判断モジュールは、前記サーバの識別子ID情報が正しいかどうかを、前記セッション管理情報内の、前記サーバの前記ID情報に従って確認し、前記通知メッセージ内の認証情報を、前記サーバの前記正しいID情報に従って認証し、前記セッションの重要度を、前記セッション管理情報内の、前記セッションの指示情報に従って判断するように更に適合されている請求項8または9に記載のDSまたはDM端末。前記応答メッセージ生成モジュールは、前記サーバの前記IDエラー情報および/または前記セッション判断モジュールによって確認された認証失敗情報を、前記生成された応答メッセージで搬送するか、又は前記セッションの前記指示情報に従って、前記セッション判断モジュールによって確認された、前記セッションの拒否情報を、前記生成された応答メッセージで搬送するように更に適合されている請求項10に記載のDSまたはDM端末。前記重要度情報は、前記セッションの重要度を示すように適合されている請求項8に記載のDSまたはDM端末。データ同期DSまたは装置管理DMサーバであって、セッションの確立を要求する通知メッセージをDSまたはDM端末へ送信するように適合され、前記通知メッセージが、前記セッションに関連するセッション管理情報を搬送し、前記セッション管理情報が、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報が、重要度情報を含むセッション通知メッセージ開始モジュールと、前記DSまたはDM端末から返された応答メッセージを受信するように適合された応答メッセージ受信モジュールと、前記応答メッセージで搬送されたコンテンツに従って、対応する処理を実行するように適合された処理モジュールと、を備えるDSまたはDMサーバ。前記応答メッセージ受信モジュールによって受信された前記応答メッセージは、通知メッセージエラー情報、前記端末が前記通知メッセージを正常に受信したことを示す情報、および前記端末が前記セッションを拒否したことを示す情報のうちの1つを搬送し、前記処理モジュールは、前記通知メッセージエラー情報内のエラータイプに従って対応して前記通知メッセージを修正し、前記修正された通知メッセージを再送信するか、または前記端末が前記通知メッセージを正常に受信したこと、もしくは前記セッションを拒否したことを示す情報に従って、前記通知メッセージを再送信しないように更に適合されている請求項13に記載のDSまたはDMサーバ。前記重要度情報は、前記セッションの重要度を示すように適合されている請求項13に記載のDSまたはDMサーバ。前述の先行技術に基づいて、本願発明者は、前述の発明の方法の、実際の操作プロセスにおいていくつかの問題が発生しうることを見出した。すなわち、端末は、サーバから通知メッセージを受信しても、応答するメカニズムを持たない。したがって、サーバは、端末からのフィードバックを取得できず、通知メッセージを繰り返し送信し続ける。その結果、サーバの処理作業負荷が増大し、占有されるネットワークリソースが増大する。そこで、本発明の実施形態では、DSまたはDM通知メッセージを拡張することにより、より多くのセッション管理情報を、DSまたはDM通知メッセージで搬送することが可能であり、DSまたはDM端末は、通知メッセージを解析および判断し、解析および判断結果に従って、DSまたはDMサーバへ応答メッセージを送信する。それによって、DSまたはDMサーバは更に、DSまたはDM端末から返された情報に従って処理を行う。本発明の実施形態は、以下のステップを含む方法を提供する。セッションの確立を要求する、サーバからセッション要求側から送信された通知メッセージが端末によって受信され、この通知メッセージは、セッションに関連付けられたセッション管理情報を搬送する。通知メッセージ内の、セッションに関連するセッション管理情報が取得され、このセッション管理情報に従って、サーバとのセッション接続が端末によって開始される。または、セッション管理情報に従って通知メッセージが端末によって確認され、確認結果に従って応答メッセージが端末によって生成され、この応答メッセージは、サーバへ送信される。前記セッション管理情報は、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報は、重要度情報を含む。本発明の実施形態は更に、DSまたはDM端末を提供し、DSまたはDM端末は、サーバから送信された、セッション管理情報を搬送する通知メッセージを受信するように適合された通知メッセージ受信モジュールと、セッション管理情報を取得し、セッション管理情報に従って通知メッセージを確認するように適合されたセッション判断モジュールと、セッション判断モジュールの確認結果に従って応答メッセージを生成するように適合され、前記セッション管理情報は、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報は、重要度情報を含む応答メッセージ生成モジュールと、セッション判断モジュールの判断結果に従って、応答メッセージ生成モジュールによって生成された応答メッセージを、通知メッセージ送信側へ、通知メッセージのベアラフォームで送信するように適合された応答メッセージ送信モジュールと、応答メッセージ生成モジュールによって生成された応答メッセージをセッション要求送信側へ送信するように適合されているか、又はセッション判断モジュールの確認結果に従ってサーバとのセッション接続を開始するように適合されたメッセージ送受信モジュールと、を含む。本発明の実施形態は更に、DSまたはDMサーバを提供し、DSまたはDMサーバは、セッションの確立を要求する通知メッセージをDSまたはDM端末へ送信するように適合されたセッション通知メッセージ開始モジュールと、DSまたはDM端末から返された応答メッセージを受信するように適合され、前記セッション管理情報は、前記サーバの識別子ID情報、認証情報、並びに前記セッションの指示情報及び管理オブジェクトMOのID情報の少なくも1つを含み、前記セッションの前記指示情報は、重要度情報を含む応答メッセージ受信モジュールと、応答メッセージで搬送されたコンテンツに従って、対応する処理を実行するように適合された処理モジュールと、を含む。前述の技術的な解決からわかるように、本方法では、DSまたはDMサーバから配信された、セッション接続を要求する通知メッセージが受信された後、メッセージのフォームおよびコンテンツの解析、判断、および認証の結果に従って、応答メッセージがDSまたはDMサーバへ送信され、これによって、サーバは、さらなる処理を行うために、DSまたはDM端末から返された情報に従って、送信された通知の問題を判断することが可能である。したがって、DSまたはDMサーバが、セッション接続がDSまたはDM端末によって確立されたことを通知されない場合に、通知メッセージをやみくもに繰り返し送信することを回避することが可能である。更に、端末は、セッションを実行するかどうかを決定するために、かつ、セッションが拒否された場合に応答メッセージでサーバに通知するために、セッションの重要度および目的をあらかじめ認識しており、これによって、サーバが通知メッセージを繰り返し送信することが回避される。本発明の実施形態は、DSまたはDMセッションに適用可能なメッセージ処理方法を提供する。この方法では、DSまたはDMサーバから配信された、セッション接続を要求する通知メッセージが受信された後、このメッセージのフォームおよびコンテンツを解析、判断、および認証した結果に従って、DSまたはDMサーバへ応答メッセージが送信され、これにより、サーバは、DSまたはDM端末から返された情報に従って、さらなる処理を行うために、送信された通知における問題を判断することが可能であり、これによって、DSまたはDMサーバが、DSまたはDM端末によってセッション接続が確立されたことを通知されない場合に通知メッセージをやみくもに繰り返し送信することが回避される。更に、端末は、セッションを実行するかどうかを決定するために、かつ、セッションが拒否された場合に応答メッセージでサーバに通知するために、セッションの重要度および目的をあらかじめ認識しており、これによって、サーバが通知メッセージを繰り返し送信することが回避される。この方法を実現するために、本発明の実施形態は、メッセージ処理システムを提供する。図2は、本発明に従ったシステムの概略構成図であり、これには、端末100とサーバ側とが含まれている。端末は、主として、DSまたはDMクライアント101これは、DMクライアントであっても、DSクライアントであってもよく、DMクライアントおよびDSクライアントであってもよく、以降では説明は同じであると、通知クライアント102とを含んでいる。サーバ側は、主として、DSまたはDMサーバ200および通知サーバ300を含んでいる。本発明の実施形態では、DSまたはDMクライアント101は、DSまたはDMプロトコルでDSまたはDMサーバ200と対話し、DSまたはDMクライアント101は、メッセージ送受信モジュール1011、セッション判断モジュール1012、および応答メッセージ生成モジュール1013を含んでいる。メッセージ送受信モジュール1011は、DSまたはDMサーバから送信されたDSまたはDMセッションメッセージを受信し、応答メッセージ生成モジュール1013によって生成されたDSまたはDMセッションメッセージをDSまたはDMサーバ200へ送信するように適合されている。セッション判断モジュール1012は、通知メッセージで搬送されるセッション管理情報を抽出するように適合されており、セッション管理情報は、メッセージのバージョン情報、メッセージ送信者のID情報、セッションの目的情報、セッションの指示情報などであり、この中の、セッションの指示情報は、これらに限定されないが、セッションの目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報などを含む。セッション判断モジュール1012は、抽出された情報の処理、たとえば、セッションが重要かどうか、ならびにメッセージのバージョン情報が正しいかどうかを、セッションの目的に従って判断すること、送信者のID情報に従ってダイジェスト認証を実行すること、および他の処理を行うように、更に適合されており、処理結果に従ってメッセージの応答を判断するように適合されている。セッション判断モジュール1012は更に、メッセージのフォーム情報たとえば、メッセージのフォーマットを取得し、メッセージのフォーマットを解析し、解析結果に従ってメッセージの応答を判断するように適合されている。セッション判断モジュール1012は更に、サーバ側から送信された通知メッセージのベアラフォーム情報と、通知メッセージから取得された情報とに従って、応答メッセージのフォームおよびコンテンツを判断するように適合されている。応答メッセージ生成モジュール1013は、セッション判断モジュール1012の指示に従って、応答メッセージを生成するように適合されている。なお、応答メッセージがDSまたはDMセッションに基づく場合、応答メッセージ生成モジュール1013は、DSまたはDMセッションメッセージを生成し、DSまたはDMセッションメッセージを、メッセージ送受信モジュール1011を介してDSまたはDMサーバ200へ送信するように適合されている。一方、応答メッセージが非セッションに基づく場合、言い換えると、応答メッセージが、通知サーバから送信された通知メッセージのベアラフォーム、たとえば、SIPメッセージ、SMSショートメッセージサービス、WAP無線アプリケーションプロトコルプッシュ、SIPプッシュなどに基づいて生成される場合、応答メッセージ生成モジュール1013は、応答メッセージの、対応するフォーマットたとえば、後述される本発明の実施形態において説明される応答メッセージのフォーマットに従って、かつ、サーバ側の通知サーバから送信された通知メッセージのベアラフォームに従って、対応するフォーマットで応答メッセージを生成し、以下で説明される応答メッセージ送信モジュール1022を介して、対応するフォーマットの応答メッセージを通知サーバ300へ送信するように適合されている。他の場合には、DSまたはDMクライアント101は、ポリシー設定モジュール1014を更に含んでよく、ポリシー設定モジュール1014は、メッセージを応答するかどうかを判断するポリシーを記憶するように適合されており、ポリシーの詳細内容については、以下に示される、本方法の実施形態のポリシーに関連する詳細な紹介を参照されたい。セッション判断モジュール1012は更に、ポリシー設定モジュール1014において設定されているポリシーに従って、サーバ側に対してメッセージの応答を行うかどうかを判断するように適合されている。本発明の実施形態では、端末100は更に、通知クライアント102を含んでおり、通知クライアント102は、通知メッセージ受信モジュール1021および応答メッセージ送信モジュール1022を含んでいる。通知メッセージ受信モジュール1021は、通知サーバから送信された通知メッセージを受信するように適合されている。応答メッセージ送信モジュール1022は、応答メッセージ生成モジュール1012によって生成された応答メッセージを通知サーバへ送信するように適合されている。通知メッセージは、これに限定されないが、ショートメッセージ、OTAプッシュメッセージ、SIPプッシュメッセージなどを含む。本発明のシステムの実施形態では、サーバ側は、DSまたはDMサーバ200および通知サーバ300を含んでいる。なお、これら2つのサーバの区別は論理的な区別であり、実際の応用では、これら2つのサーバは、1つのDSまたはDMサーバに統合されてもよい。DSまたはDMサーバ200は、セッション通知メッセージ開始モジュール201、応答メッセージ受信モジュール202、および処理モジュール203を含んでよい。セッション通知メッセージ開始モジュール201は、通知サーバ300の通知メッセージ送信モジュール301に対し、セッション通知メッセージをDSまたはDM端末100へ送信することを要求するように適合されている。応答メッセージ受信モジュール202は、通知クライアント102から返され、通知サーバ300の応答メッセージ解決モジュール303によって送信された、非セッションに基づく解決済み応答メッセージを受信し、または、DSまたはDMクライアント101から返された、セッションに基づく応答メッセージを受信するように適合されている。処理モジュール203は、受信された応答メッセージで搬送されたコンテンツに従って、さらなる処理を行うように適合されている。たとえば、応答メッセージで搬送されたコンテンツが、ダイジェスト認証が失敗したこと、サーバIDが正しくないこと、メッセージのフォーマットが正しくないこと、およびバージョン情報が正しくないことのうちのいずれかを示す情報を含んでいる場合、処理モジュール203は、対応するエラーを訂正する。応答メッセージで搬送されたコンテンツが、セッションが拒否されたこと、および通知メッセージが正常に受信されたことのうちのいずれかを示す情報を含んでいる場合、処理モジュール203は、通知メッセージを送信しない。なお、通知サーバ300の応答メッセージ解決モジュール303は、DSまたはDMサーバ200内に設けられてもよく、これによって、DSまたはDMサーバ200は、対応する応答メッセージを解決する。通知サーバ300は、通知メッセージ送信モジュール301、応答メッセージ受信モジュール302、および応答メッセージ解決モジュール303を含んでよい。通知メッセージ送信モジュール301は、通知メッセージを通知クライアント102へ送信するように適合されており、応答メッセージ受信モジュール302は、通知クライアント102から返された応答メッセージを受信し、応答メッセージを応答メッセージ解決モジュール303へ送信するように適合されており、応答メッセージ解決モジュール303は、応答メッセージ受信モジュール302によって通知クライアント102から受信された通知メッセージを解決し、解決結果をDSまたはDMサーバへ送信するように適合されている。前述のシステムに基づき、本発明の実施形態は更に、DSまたはDMセッションに適用可能なメッセージ処理方法を提供する。図3は、本方法の実施形態のフローチャートを示し、これには以下のステップが含まれる。ステップ301で、通知メッセージが受信される。DSまたはDM端末は、DSまたはDMサーバの要求に従って、通知サーバから送信された、DSまたはDMセッションの通知メッセージを受信する。通知メッセージは、セッション管理情報を搬送する。セッション管理情報は、これに限定されないが、たとえば、セッション要求側のID情報、認証情報、セッションの指示情報などを含む。指示情報は、これらに限定されないが、セッションの目的情報、重要度情報、タイムアウト情報、操作情報、応答ポリシー情報などを含む。本発明の実施形態では、DSまたはDM通知メッセージを拡張することにより、セッション管理情報は、通知メッセージに含められ、DS通知およびDM通知のメッセージボディ部分のフォーマットが異なるため、以下ではそれぞれについて説明が行われる。以下では、DS通知メッセージを拡張する方法を説明し、拡張されたDS通知のフォーマットを、次の表1に示す。拡張されたフィールドは、以下のように説明される。このフィールドは応答モードを表す。00このフィールドは未指定を表す。01このフィールドは応答を表す。10このフィールドは応答せずを表す。11このフィールドはユーザが決定を表す。このフィールドは重要度を表す。00このフィールドは未指定を表す。01このフィールドは低を表す。10このフィールドは通常を表す。11このフィールドは高を表す。5BITこのフィールドは日単位でのタイムアウト時間を表す。18BITこのフィールドは拡張用として予約済みを表す。8BITこのフィールドはセッション情報の長さを表す。CHARこのフィールドはセッション情報を表す。3BITこのフィールドは操作コードを表す。に従って、サーバは、応答メッセージの送信が必要かどうかを端末に指示する。応答モードが応答である場合、これは、端末が、通知メッセージを正常に受信したかどうかを返すことが必要であることを表す。応答モードが未指定である場合、端末は、ポリシーに従って、応答メッセージを送信するかどうかを判断することが可能である。応答モードが応答せずである場合、端末は、応答メッセージをサーバへ送信する必要がない。応答モードがユーザが決定である場合、端末はユーザに入力を要求し、ユーザは、応答メッセージを応答するかどうかを判断する。実際の応用において、通知メッセージのトランスポート層が成功または失敗の情報を自動的に応答することをサポートしている場合、サーバは、応答モードを応答せずまたは未指定に設定する。通知メッセージのトランスポート層が応答メッセージを自動的に応答することをサポートしていない場合、サーバは、応答モードを応答に設定し、アプリケーション層が、応答メッセージで応答する。細かな組み合わせは、状況に応じて決定されることが可能であり、本発明は、それらの様式に限定されない。は、セッションの重要度を示すように適合されており、端末は、サーバとのセッション接続を確立することが必要かどうかを、セッションの重要度に従って判断する。なお、重要度は、サーバによって決定され、端末の参照用として適合されているに過ぎない。これは、サーバにとって重要なセッションが、端末にとっては重要でない場合があるためである。端末は、セッションが重要かどうかを、端末の状態、たとえば、端末がビジーである場合や、セッションが端末にとって重要ではない場合に応じて、判断することが可能である。は、通知メッセージのタイムアウト時間を指定するように適合されている。通知メッセージは、セッションID情報を含んでおり、端末は、セッションID情報に従って、サーバとのセッション接続を開始する。サーバは、端末のセッション接続を確実に認識するために、この情報を保存することが必要である。指定のタイムアウト時間内に端末がサーバとのセッション接続を開始しない場合、サーバは、リソースを節約するために、この通知の関連情報を保存しない。タイムアウト時間は、日単位であり、0の場合は、時間制限が存在しないことを示している。は、の長さをバイト単位で指定するように適合されている。これは、0の場合には、の長さが0であること、すなわち、フィールドが存在しないことを示している。は、通知の目的、たとえば、ファームウェアのアップグレードが必要ですかを示すように適合されている。端末またはユーザは、この情報に従って、サーバとのセッション接続を開始するかどうかを判断する。は、サーバから端末に指示される操作コードである。たとえば、サーバは端末に、空セッションを開始することを要求したり、あるいは、装置情報を報告することを要求したりする。端末は、セッションを受け入れる場合には、<操作コード>の指示に従って、対応するセッションを開始する。の値は、次の表2に示されるとおりである。値が000の場合、サーバはクライアントに、空セッションを開始することを要求する。セッションが確立された後、サーバは、<Get>コマンドを用いて端末の装置情報を取得したり、あるいは、同期操作を開始したりすることが可能である。値が001の場合、サーバはクライアントに、すべての装置情報を報告することを要求する。最初の同期において、クライアントは、すべての装置情報をサーバに報告することが必要である。その後の同期においては、クライアントは、トラヒックを節約するために、更新された装置情報を報告することだけが必要である。値が010の場合、サーバはクライアントに、更新された装置情報を報告することを要求する。クライアントは、<Put>コマンドを用いて、更新された装置情報をサーバに報告することが可能であり、クライアントは、装置情報の更新記録を保存しなければならない。値が011の場合、サーバはクライアントに、装置情報を報告しないことを要求する。サーバがクライアントの装置情報を必要としていない場合、または、サーバがクライアントの装置情報を無用と見なしている場合は、トラヒックを節約するために、サーバはクライアントに、装置情報を報告しないことを要求することが可能である。次に、DM通知メッセージを拡張する方法を説明し、拡張されたDM通知のフォーマットを次の表3に示す。拡張されたフィールドは、以下のように説明される。4BITこのフィールドはMOの数を表す。4BITこのフィールドは拡張用として予約済みを表す。このフィールドは最初のMOIの情報を表す。8BITこのフィールドはMOIの長さを表す。CHARこのフィールドはMOのID情報を表す。は、このセッションに関与するMOの数を示すように適合されている。後続のMO1~MONは、MOの詳細情報を示すように適合されている。は、MOIの長さを示すように適合されている。は、MOのID情報を示すように適合されている。端末は、特定のポリシーを設定して、、、または他の情報に従って、サーバとのセッション接続を開始するかどうかを自動的に決定することが可能である。たとえば、重要度レベルが高い場合、端末は、セッションを自動的に許可する。重要度レベルが低い場合、端末は、セッションを自動的に拒否する。たとえば、MOIがurn:oma:mo:fumo:1.0である場合も、端末は、セッションを自動的に許可する。ステップ302で、通知メッセージのコンテンツが抽出される。DSまたはDM端末は、通知メッセージで搬送されたコンテンツを抽出する。なお、1つの通知メッセージは、コンテンツの一部、たとえば、セッションの指示情報を搬送することが可能であり、セッションの指示情報は、セッションの重要度値および/または目的情報、操作情報、セッションのタイムアウト情報応答時間、DSまたはDMサーバによって配信される、DSまたはDM端末の応答ポリシーなどを含む。一方、すべての情報が1つの通知メッセージで搬送されることは必須ではない。明らかに、すべての情報が同時に搬送されてよい。ステップ303で、DSまたはDM端末は、通知メッセージのフォームおよびコンテンツを確認する。DSまたはDM端末が通知メッセージのフォームおよびコンテンツを確認することには、これに限定されないが、以下の処理が含まれる。DSまたはDM端末は、通知メッセージのフォーマットが正しいかどうかを判断し、メッセージのバージョンが一致しているかどうかを判断し、サーバIDが不正かどうか、またはサーバIDが存在するかどうかを判断し、ダイジェストが合格したかどうかを、認証情報に従って認証し、セッションの重要度を、取得された、セッションの重要度値に従って決定すること、または、セッションの重要度を、取得された、セッションの目的および端末の現在の状態、たとえば、端末がビジーかどうか、同じセッションが実行されているかどうか、などに従って決定すること、または、取得された、セッションの目的情報をユーザに対して表示し、ユーザがセッションを拒否するか受け入れるかに従って、セッションの重要度を決定することを行う。DSまたはDM端末は更に、DSまたはDMサーバからDSまたはDM端末に配信された、DSまたはDM端末の応答ポリシーを採用するかどうかを判断する。ステップ304で、応答方法が、ポリシーに従って判断される。DSまたはDMセッションを開始する場合、端末は、DSまたはDMセッションを開始する、あるいは、何も処理を行わない。DSまたはDMセッションを開始しない場合、処理はステップ306へ進む。ポリシーは、DSまたはDM端末にあらかじめ記憶されている応答ポリシーであってよく、DSまたはDMサーバからDSまたはDM端末に配信された応答ポリシーであってもよい。DSまたはDM端末のポリシーは、これに限定されないが、以下のような、いくつかの状況を含む。1.通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、サーバIDは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、かつ、セッションが、セッション管理情報内の指示情報および/または端末の現在の状態に従って、比較的重要と見なされ、受信されることが可能である場合は、メッセージを応答することが必要である。2.通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、DSまたはDMサーバIDは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、かつ、セッションは、比較的重要と見なされている場合は、メッセージを応答しないことが必要である。3.通知メッセージが正常に受信された場合、言い換えると、通知メッセージが、通知メッセージのバージョンは正しいこと、フォーマットは正しいこと、サーバIDは正しいこと、およびダイジェスト妥当性検査に合格したことを示している場合、しかし、かつ、セッションが、セッション管理情報内の指示情報および/または端末の現在の状態に従って、重要ではないと見なされ、セッションが拒否された場合は、メッセージを応答することが必要である。4.受信されたメッセージが、通知メッセージのバージョンが正しくないこと、フォーマットが正しくないこと、DSまたはDMサーバIDが正しくないこと、およびダイジェスト妥当性検査に合格していないことのうちのいずれかの状況を有する場合、しかし、セッションが、セッション管理情報内の指示情報および/または端末の現在の状態に従って、比較的重要と見なされ、受信されることが可能である場合は、メッセージを応答することが必要である。5.受信されたメッセージが、バージョンが正しくないこと、フォーマットが正しくないこと、DSまたはDMサーバIDが正しくないこと、およびダイジェスト妥当性検査に合格していないことのうちのいずれかの状況を有する場合、しかし、セッションが、セッション管理情報内の指示情報および/または端末の現在の状態に従って、重要ではないと見なされ、セッションが拒否された場合は、メッセージを応答することが必要である。実際の応用では、DSまたはDM端末は、ユーザに入力を要求し、ユーザは、応答するかどうかを決定する。ステップ303で、端末が、DSまたはDMサーバからDSまたはDM端末に配信された、DSまたはDM端末の応答ポリシーを採用することを決定した場合、端末は、サーバから配信された応答ポリシーを採用することによって、対応する応答を行う。実際の応用では、メッセージを応答することが必要であることがすぐにデフォルトとして決定され、このステップは省略可能である。ステップ305で、応答メッセージのフォームおよびコンテンツが決定され、応答メッセージが生成される。ステップ304に従って、メッセージを応答することが必要であると判断された場合、ステップ303における、メッセージに対する様々な解析および認証結果、ならびに、通知メッセージの様々なベアラフォームに応じて、応答メッセージのフォームおよびコンテンツは、以下で述べられるルールに従って決定される。応答メッセージの様々なフォームおよびコンテンツは、応答を必要とする4つの状況に応じて、それぞれ決定される。第1の状況前述の1では、DSまたはDM端末内の通知クライアントが、通知メッセージのベアラフォームに従ってメッセージを応答することが可能な場合、通知クライアントは、サーバ側の通知メッセージが正常に受信されたという内容のメッセージで、通知サーバに応答する。応答メッセージのコンテンツは、応答メッセージで搬送されるステータスコードで表され、詳細については、以下に示される本方法の実施形態を参照されたい。そうでない場合、DSまたはDM端末内の通知クライアントは、通知メッセージのベアラフォームに従ってメッセージを応答することができない、あるいは、通知クライアントが通知メッセージのベアラフォームに従ってメッセージを応答することが可能であっても、通知サーバの応答メッセージのIDが存在しないため、メッセージを応答することができない。この場合、DSまたはDM端末内のDSまたはDMクライアントは、サーバ側の通知メッセージが正常に受信されたという内容のメッセージで、応答する。たとえば、通知クライアントは、SMS方式で通知サーバから送信された通知メッセージを受信するが、通知サーバの応答番号が存在しないため、メッセージを応答することができない。この応答メカニズムでは、通知メッセージは、メッセージを応答するためのDSまたはDMセッションを開始することなく、便利に応答される。明らかに、通知クライアントがメッセージを応答できるかどうかは問題ではないと見なされることが可能であり、DSまたはDMクライアントがメッセージにより応答することが直接決定される。第2の状況前述の3では、第1の状況と同様に、DSまたはDM端末内の通知クライアントがメッセージを応答することが可能な場合には、通知クライアントは、メッセージで応答する。そうでない場合、DSまたはDM端末内のDSまたはDMクライアントは、セッションが拒否されたという内容のメッセージにより、応答する。同様に、通知クライアントがメッセージにより応答することが可能かどうかを考慮することなく、DSまたはDMクライアントが、セッションが拒否されたという内容のメッセージにより応答することを直接決定することが可能である。第3の状況前述の4では、受信されたメッセージが、DSまたはDMサーバIDが正しくない状況、およびダイジェスト妥当性検査に合格していない状況のうちの1つを有する場合、DSまたはDMクライアントは、DSまたはDMサーバIDが正しくないか、ダイジェスト妥当性検査に合格していないために、メッセージを応答することができず、通知クライアントは、DSまたはDMサーバIDが正しくないか、ダイジェスト妥当性検査に失敗したという内容のメッセージにより、応答する。受信されたメッセージが、バージョンが正しくないか、あるいはフォーマットが正しくない状況を有する場合は、第2の状況と同様に、通知クライアントまたはDSまたはDMクライアントは、通知メッセージが正しくないという内容、具体的には、メッセージのバージョンが正しくないか、メッセージのフォーマットが正しくないというエラータイプのメッセージを応答するために選択される。第4の状況前述の5では、受信されたメッセージが、DSまたはDMサーバIDが正しくない状況、およびダイジェスト妥当性検査に合格していない状況のうちの1つを有する場合、DSまたはDMクライアントは、DSまたはDMサーバIDが正しくないか、ダイジェスト妥当性検査に合格していないために、メッセージを応答することができず、通知クライアントは、セッションが拒否されたという内容のメッセージにより、応答する。受信されたメッセージのバージョンが正しくないか、あるいはフォーマットが正しくない場合は、第2の状況と同様に、通知クライアントまたはDSまたはDMクライアントは、セッションが拒否されたという内容のメッセージを応答するために選択される。応答メッセージは、応答メッセージのコンテンツおよびフォームに従って生成される。ステップ306で、DSまたはDM端末は、メッセージで応答する。DSまたはDM端末内の通知クライアントがメッセージにより応答する場合、通知クライアントは、応答メッセージを、サーバによる認識が可能な、指定のフォーマットにパッケージし、パッケージされたメッセージを通知サーバへ送信する。フォーマットの詳細については、本発明による方法の実施形態の、関連するステップの詳細説明を参照されたい。DSまたはDM端末内のDSまたはDMクライアントがメッセージにより応答する場合、DSまたはDMクライアントは、サーバセッション通知メッセージの応答としてDSまたはDMサーバへ送信されたセッションメッセージの中の対応するコンテンツを搬送する。搬送方法の詳細については、本発明による方法の実施形態の、関連するステップの詳細説明を参照されたい。DSまたはDMセッションを開始することは、応答メッセージの1つとして用いられることが可能である。以下では、2つの実施形態を説明する。第1の実施形態では、通知クライアントを経由して、メッセージにより応答する方法を説明する。第2の実施形態では、DSまたはDMクライアントを経由して、メッセージを応答する方法を説明する。図4は、本発明による方法の第1の実施形態のシグナリングフローチャートを示しており、これには以下のステップが含まれる。ステップ401では、DSまたはDMサーバが、セッション管理関連情報を提供し、通知メッセージをDSまたはDM端末に配信することを通知サーバに要求する。通知サーバは、ショートメッセージサーバ、OTAPUSHサーバ、またはSIPPUSHサーバなどとして実装されることが可能である。関連する管理情報の内容については前述されているので、ここでは繰り返さない。ステップ402で、通知サーバが、DSまたはDM端末に通知メッセージを配信し、セッション接続を要求する。通知メッセージは、セッション管理目的、重要度、および他の情報を含み、配信方式は、ショートメッセージやOTAPUSHなどであってよい。ステップ403で、端末内の通知クライアントが、通知メッセージをDSまたはDMクライアントへ転送する。ステップ404で、DSまたはDM端末内のDSまたはDMクライアントは、メッセージのコンテンツ、たとえば、DSまたはDMサーバIDを抽出し、通知メッセージ内のダイジェストを認証し、メッセージのフォーマットを解析し、セッションの重要度を判断する。DSまたはDM端末は、メッセージを応答することが必要かどうかを、DSまたはDM端末内であらかじめ設定および保存されている前述のポリシーに従って判断する。たとえば、DSまたはDMサーバIDが正しくない場合、ダイジェスト認証が失敗した場合、または通知のフォーマットが正しくない場合、端末は、通知メッセージの応答として、対応するエラー情報により、サーバに応答する。DSまたはDMサーバIDが正しい場合、ダイジェスト認証が成功した場合、または通知のフォーマットが正しい場合、端末は、通知メッセージの応答として、対応する情報、たとえば、端末がメッセージを正常に受信したことを示す情報により、サーバに応答することが可能である。ステップ405で、DSまたはDM端末内のDSまたはDMクライアントは、通知メッセージが正常に受信されたかどうかを示すために、ステータスコードおよび応答メッセージを生成する。メッセージを正常に受信した場合、端末は、200成功情報により応答する。DSまたはDMサーバIDが正しくない場合、ダイジェスト認証が失敗した場合、または通知のフォーマットが正しくない場合、端末は、対応するエラーコードにより、通知サーバに応答する。ステータスコードの詳細な対応テーブルを、表5に示す。ステップ406で、DSまたはDMクライアントは、応答メッセージを通知クライアントへ転送する。なお、DSまたはDMクライアントが、応答メッセージを通知クライアントへ転送することを決定する前に、通知メッセージにより応答することを、通知メッセージのベアラフォームおよび通知サーバの応答番号に従って決定することが必要である。ステップ407で、通知クライアントは、応答メッセージを、後述の表4に示されるような指定のフォーマットにパッケージする。ステップ408で、通知クライアントは、パッケージされた応答メッセージを通知サーバへ転送する。ステップ409で、通知サーバは、応答メッセージに従って、後続の処理を行う。端末から返されたステータスコードが、メッセージが正常に受信されたことを示している場合、通知サーバは、通知メッセージを再送信しない。端末から返されたステータスコードがエラーコードである場合、サーバは、発生した障害の状況に応じて通知メッセージを再生成し、この通知メッセージを端末へ再送信する。たとえば、フォーマットが正しくない場合、サーバは、メッセージのフォーマットをチェックする。ダイジェストが正しくない場合は、ダイジェストを生成するために、認証情報が再取得される。ステップ410で、通知サーバは、処理結果をDSまたはDMサーバへ送信する。上述の実施形態からわかるように、通知メッセージのフォームおよびコンテンツを解析、判断、および認証することによって、メッセージにおける問題、たとえば、フォーマットの問題、DSまたはDMサーバIDの問題、認証が成功していないという問題、バージョンが正しくないという問題など、が判断されることが可能である。あるいは、サーバによって開始されたセッションが重要でないことが判断されることが可能である。これらの問題は、サーバに送信される応答メッセージで搬送され、これによって、サーバは、通知メッセージが正常に受信されたかどうかを認識し、通知メッセージを送信しないようにする。あるいは、サーバは、フォーマット、バージョン、およびサーバIDの問題がメッセージに存在することを認識すると、関連する情報を訂正して、更新された通知メッセージを時間どおりに送信して、セッションを実行する。あるいは、サーバは、端末がセッションを拒否したという情報を認識した後は、セッションメッセージをやみくもに再送信しない。なお、ステップ505で、DSまたはDM端末は、応答メッセージを運ぶために、通知の配信時に、ベアラフォームに従ってベアラフォームを選択する。更に、サーバが応答メッセージをよりよく認識することを可能にするために、本発明では、応答メッセージのフォーマットは、次の表4に示されるように設計されている。やなど、いくつかのフィールドは、通知メッセージの場合と同じ意味を有している。他のフィールドは、以下のように説明される。4BITこのフィールドはステータスコードを表す。8BITこのフィールドは認証名の長さを表す。CHARこのフィールドは認証名を表す。は、DSまたはDM端末を認証するDSまたはDMサーバに使用される。は、端末によって受信された通知メッセージのステータスコード、たとえば、成功または失敗を示すように適合されている。可能なステータスコードは、次の表5に示されるとおりである。なお、フォーマットの設定、または表は、一例として示されており、本発明では、他の同様な設定は除外されないため、示された例に限定されない。更に、端末から送信されたメッセージが通知の応答メッセージであることを、サーバが具合よく認識することを可能にするために、応答メッセージのコンテンツタイプを次のように定義することが可能である。ApplicationvndsyncmlDMresponseapplicationvndsyncmldsresponseサーバは、受信されたステータスコード情報に従って、端末がメッセージを受信した状況を認識することが可能である。DSまたはDM端末が、ベアラフォームまたは他の理由、たとえば、通知サーバの応答番号を取得することができない、あるいは、通知サーバがWAPPUSHによって通知メッセージを配信した、などにより、通知メッセージにより応答することができない場合、端末は、通知メッセージをWAPPUSH方式で応答することができない。ここで、端末は、サーバに対して、DSまたはDMセッション方式でメッセージを応答することが可能である。たとえば、端末は、通知サーバの対応するエラー情報、またはセッションが拒否されたことを示す情報を応答することが可能である。なお、DSまたはDM端末が通知メッセージのダイジェストに認証に失敗した場合、またはDSまたはDMサーバID情報が正しくないことがわかった場合、端末は、そのサーバを信頼することができないので、対応するエラー情報を報告するためのDSまたはDMセッションを開始しない。通知のフォーマットが正しくなく、バージョンが一致せず、他のエラーも存在する場合、端末は、エラー情報を、DSまたはDMセッション方式で報告することが可能である。サーバに対して、DSまたはDMセッション方式でメッセージが応答される場合、指定された情報を報告するために、プロトコル内にアラートタイプAlertTypeを定義する必要があるたとえば、org.openmobilealliance.DM.notification-errorは、<データ>内の関連するエラーコードを示す。状況の詳細については、図5を参照されたい。図5は、本発明による方法の第2の実施形態に従って、DSまたはDMクライアントを介して、メッセージにより応答することのシグナリングフローチャートであり、以下にプロセスの詳細を示す。以下、各ステップを示す。ステップ501では、DSまたはDMサーバが、セッション管理関連情報を提供し、通知メッセージをDSまたはDM端末に配信することを通知サーバに要求する。通知サーバは、ショートメッセージサーバ、OTAPUSHサーバ、またはSIPPUSHサーバなどとして実装されることが可能である。関連する管理情報の内容については前述されているので、ここでは繰り返さない。ステップ502で、通知サーバが、DSまたはDM端末に通知メッセージを配信し、セッション接続を要求する。通知メッセージは、セッション管理目的、重要度、および他の情報を含み、配信方式は、ショートメッセージやOTAPUSHなどであってよい。ステップ503で、端末内の通知クライアントが、通知メッセージをDSまたはDMクライアントへ転送する。ステップ504で、DSまたはDM端末内のDSまたはDMクライアントは、メッセージのコンテンツ、たとえば、DSまたはDMサーバID、を抽出し、通知メッセージのダイジェストを認証し、メッセージのフォーマットを解析し、セッションの重要度を判断することなどを行う。DSまたはDM端末は、メッセージを応答することが必要かどうかを、DSまたはDM端末内であらかじめ設定および保存されている前述のポリシーに従って判断する。たとえば、通知のフォーマットが正しくなく、バージョン情報が正しくない場合、端末は、対応するエラー情報で、DSまたはDMサーバに応答する。DSまたはDMサーバIDが正しく、ダイジェスト認証が成功し、通知のフォーマットが正しく、バージョンが正しい場合、端末は、通知メッセージの応答として、対応する情報、たとえば、端末がメッセージを正常に受信したことを示す情報で、DSまたはDMサーバに応答することが可能である。セッションの重要度は、設定されているポリシーを満たしていない、と、端末が見なした場合、端末は、セッションを拒否する応答メッセージを、DSまたはDMサーバへ送信する。ステップ506で、DSまたはDMクライアントが、通知メッセージのベアラフォーム、通知サーバの応答番号、および他の情報を確認することにより、対応するポリシーに従って、メッセージを応答することが必要であると判断した場合、DSまたはDMクライアントは、通知の形式では応答しないことを決定するか、DSまたはDMセッション方式のメッセージにより応答することを直接選択する。応答メッセージの内容は、メッセージのフォーマットが正しくないこと、メッセージのバージョンが正しくないこと、通知メッセージが正常に受信されたこと、またはセッションが拒否されたことを含む。オプションで、DSまたはDMクライアントは、通知メッセージ内の関連情報をユーザに対して表示することが可能であり、セッションを拒否するかどうかを、UIユーザインタフェースインタフェースで確認することをユーザに要求する。ステップ507で、ユーザは、セッションを拒否することを、入力インタフェースで決定する。ステップ508で、DSまたはDM端末は、DSまたはDMサーバとのセッション接続を開始し、セッションを拒否する応答メッセージを送信する。オプションで、端末がセッションを受け入れた場合、端末は、通知メッセージ内の指示に従って、対応するセッション操作を開始する。たとえば、端末は、空セッションを開始するか、装置情報を報告する。ステップ508で、DSまたはDM端末は、端末がセッションを拒否したことをサーバに通知するために、特別セッションを開始することが必要である。メッセージの使用方法をサーバに通知するために、アラートタイプを定義する必要があり、アラートタイプは、org.openmobilealliance.DM.refusesessionのように定義されることが可能である。以下に、メッセージの例を示す。このフィールドはアラートコマンドを表す。1このフィールドはコマンドのシーケンス番号IDを表す。1226このフィールドはアラートタイプ1226は汎用アラートを表すを表す。このフィールドはデータアイテムを表す。このフィールドはデータアイテムの説明情報を表す。このフィールドはアイテムタイプを表す。orgopenmobilealliancedmrefusesessionこのフィールドはセッションが拒否されたを表す。b64のデータフォーマット。abcこのフィールドはデータコンテンツを表す。あるいは、アラートタイプは個別に拡張されている。たとえば、アラート1220は、セッションが拒否されたことを示す情報をサーバに報告するように適合されている。以下に、メッセージの例を示す。このフィールドは通知コマンドを表す。11220このフィールドは端末がセッションを拒否したことを表す通知タイプを表す。更に、メッセージのフォーマットが正しくなく、メッセージのバージョンが正しくなく、通知メッセージが正常に受信されたことを示す情報を、メッセージ内のアラート要素で搬送することが可能である。トラヒックを節約するために、DSまたはDMサーバは、セッションを拒否する応答メッセージを受信した場合には、メッセージで応答しなくてよい。前述の本実施形態の説明からわかるように、DSまたはDM端末は、DSまたはDMサーバによって開始されたセッションが重要かどうかを、あらかじめ通知メッセージによって認識する。たとえ、サーバから配信された通知メッセージが、セッションが重要であることを示している場合でも、端末は、そのセッションが重要かどうかを、端末の状態に応じて判断する。端末は、セッションが重要ではないと決定した場合には、セッションを拒否する応答情報をすぐにサーバへ送信し、これによって、DSまたはDMサーバが、端末がセッションを開始したことを通知されるまで通知メッセージを繰り返し送信することを防ぎ、サーバ処理およびネットワークリソースが浪費されるのを防ぐ。したがって、端末は、セッションの目的および重要度をあらかじめ認識するため、実行中のセッションの重要度が要件を満たさないことが検出された場合にそのセッションが拒否されるという状況が回避され、これによって、端末の処理リソースならびにネットワークの伝送リソースの浪費を防ぐことができる。たとえば、通知サーバとして動作するSIPプッシュエージェントが通知メッセージを送信する、第3の実施形態において、本発明による、DSまたはDMセッションに適用可能なメッセージ処理方法を更に説明する。これにより、当業者であれば、本発明のソリューションをより明確に理解されるであろう。この実施形態では、SIPプッシュ送信側エージェントが通知サーバであり、SIPプッシュ受信側エージェントが通知クライアントである。プッシュコンテンツは、通知メッセージを含む。プロセスの詳細については、図6を参照されたい。図6は、以下のステップを含む。ステップ601で、DSまたはDMサーバが、通知要求をSIPプッシュ送信側エージェントに転送し、通知メッセージの送信を要求する。ステップ602で、SIPプッシュ送信側エージェントサーバは、通知のコンテンツをDSまたはDM端末に配信する。SIPプッシュ送信側エージェントサーバは、SIPプッシュプロトコルを用いて、DSまたはDM端末内のSIPプッシュ受信側エージェントすなわち、通知クライアントに通知メッセージを配信する。この実施形態における、通知のダイジェストおよびメッセージヘッダの内容を、次の表6に示す。通知のメッセージボディ部のコンテンツを、次の表7に示す。この通知のコンテンツは、SIPのMESSAGEメソッドを用いて配信される。このSIPメッセージの例を以下に示す。MESSAGEsipuserdomaincomSIP20ViaSIP20TCPserverpcdomaincombranchz9hG4bk776sgdkseMaxForwards70Fromsipserverdomaincomtag49583TosipuserdomaincomCallIDasd88asd771234CSeq1MESSAGEContentTypeapplicationvndsyncmldmnotificationContentLength[--通知メッセージがここに入る--]ステップ603で、SIPプッシュ受信側エージェントが、DSまたはDMクライアントへ通知メッセージを送信する。DSまたはDM端末は、SIPを用いて、プッシュコンテンツに応答する。このメッセージの例を以下に示す。SIP20200OKViaSIP20TCPproxydomaincombranchz9hG4bk123dsghdsViaSIP20TCPsenderpcdomaincombranchz9hG4bk776sgdkseFromsipserverdomaincomtag49394TosipuserdomaincomCallIDasd88asd771234CSeq1MESSAGEContentTypeapplicationvndsyncmldmresponseContentLength[--通知応答メッセージがここに入る--]通知の応答メッセージのコンテンツおよびフォーマットを、次の表8に示す。ステップ604で、DSまたはDMクライアントが、通知メッセージのコンテンツに従って、認証、解析、および判断を行う。細かなプロセスは本方法の実施形態と同じであり、DSまたはDMクライアントは、認証、解析、および判断の結果、ならびに、対応するポリシーに従って、応答メッセージのフォームおよびコンテンツを決定する。たとえば、上述のプロセスに従って、SIPプッシュ受信側エージェントによりメッセージを用いて応答することが決定された場合、処理はステップ605へ進む。DSまたはDM端末が、設定されているポリシーに従って、セッションの重要度が低いことを知り、セッションがMOIからの診断であって、必須のセッションタイプではないことを認識した場合、DSまたはDM端末は、妨害されて自動的にセッションを拒否することを求めず、処理はステップ607へ進む。ステップ605で、SIPプッシュ受信側エージェントは、応答メッセージを、SIPプッシュ送信側エージェントサーバ内のSIPプッシュ送信側エージェントへ、SIPフォームで送信する。ステップ606で、SIPプッシュ送信側エージェントサーバが、DSまたはDMサーバへ応答メッセージを送信する。ステップ607で、DSまたはDMクライアントは、DSまたはDMサーバとのDSまたはDMセッションを開始し、セッションを拒否する応答メッセージを送信する。セッションを拒否するメッセージのコンテンツの例を以下に示す。このフィールドはアラートコマンドを表す。1このフィールドはコマンドのシーケンス番号IDを表す。1226このフィールドはアラートタイプ1226は汎用アラートを表すを表す。このフィールドはデータアイテムを表す。このフィールドはデータアイテムの説明情報を表す。このフィールドはアイテムタイプを表す。orgopenmobilealliancedmrefusesessionこのフィールドは端末がセッションを拒否したを表す。b64このフィールドは<データ>のフォーマットを表す。abcこのフィールドはデータコンテンツを表す。上述の実施形態からわかるように、通知メッセージのフォームおよびコンテンツを解析、判断、および認証することによって、メッセージにおけるエラー、たとえば、フォーマットのエラー、DSまたはDMサーバIDのエラー、認証が成功していないというエラー、バージョンが正しくないというエラーなどが判断されることが可能である。あるいは、サーバによって開始されたセッションが重要でないことが判断されることが可能である。これらの問題は、サーバに送信される応答メッセージで搬送され、これによって、サーバは、通知メッセージが正常に受信されたかどうかを認識し、通知メッセージを送信しないようにする。あるいは、サーバは、フォーマットエラー、バージョン、およびサーバIDがメッセージに存在することを認識すると、関連する情報を訂正して、更新された通知メッセージを時間どおりに送信して、セッションを実行する。あるいは、サーバは、端末がセッションを拒否したという情報を認識した後は、セッションメッセージをやみくもに再送信しない。更に、DSまたはDM端末は、DSまたはDMサーバによって開始されたセッションが重要かどうかを、あらかじめ通知メッセージによって認識する。たとえ、サーバから配信された通知メッセージが、セッションが重要であることを示している場合でも、端末は、そのセッションが重要かどうかを、端末の状態に応じて判断する。端末は、セッションが重要ではないと判断した場合には、セッションを拒否する応答情報をすぐにサーバへ送信し、これによって、DSまたはDMサーバが、端末からセッションの初期化を通知されるまで通知メッセージを繰り返し送信することを防ぎ、サーバ処理およびネットワークリソースが浪費されるのを防ぐ。あるいは、端末は、セッションの目的および重要度をあらかじめ認識するため、実行中のセッションの重要度が要件を満たさないことが検出された場合にそのセッションが拒否されるという状況が回避され、これによって、端末の処理リソースならびにネットワークの伝送リソースの浪費を防ぐことができる。当業者であれば、前述の実装方式の説明によって明確に理解されるように、本発明は、ソフトウェアおよび必要な汎用ハードウェアプラットフォームを用いて実現可能であり、明らかにハードウェアによっても実現可能であるが、ほとんどの状況下では、前者がより一層好ましい。この理解に基づいて、本発明の技術的ソリューションは、ソフトウェア製品の形態でほぼ実現され、あるいは、先行技術の一因となる部分は、ソフトウェア製品の形態で実現されることが可能である。このコンピュータソフトウェア製品は、コンピュータのフロッピー登録商標ディスク、ハードディスク、または光ディスクのような可読記憶媒体に保存され、コンピュータ装置パーソナルコンピュータ、サーバ、またはネットワーク装置が本発明の各実施形態による方法を実行することを可能にする、いくつかの命令を含む。当業者であれば明らかなように、本発明の範囲または趣旨から逸脱することなく、本発明の構造に様々な修正および変形を施すことが可能である。先述の内容に鑑み、本発明の修正および変形は、添付の特許請求項およびその均等物の範囲に収まる限り、本発明に包含されるものとする。