(57)【特許請求の範囲】
【請求項１】
メッセージを、移動無線網を介して伝送する際に情報流を拡張する方法であって、
当該伝送は送信アプリケーション（１，１ａ）から送信側ネットワークユニット（５，５ａ）と受信側ネットワークユニット（６，６ａ）を介して受信アプリケーション（２，２ａ）に行われ、
前記送信側ネットワークユニット（５，５ａ）と受信側ネットワークユニット（６，６ａ）とは同じもの、または相互の異なるものであり、かつ１つまたは２つのサービスプロバイダ（３，４）の管轄領域内にあり、
前記メッセージによって、少なくとも１つのサービスプロバイダの管轄領域で特別の機能、すなわちメッセージの応答課金またはコールバックが要求され、
前記メッセージは、応答課金がサポートされる場合、送信者が受信者による応答メッセージのコストを引き受ける用意があるかについての情報を含んでいる形式の方法において、
送信側および受信側ネットワークユニット（５，５ａ；６，６ａ）が、それぞれ要求された機能をサポートするか否かについての情報を前記受信アプリケーション（２，２ａ）に通知する、ことを特徴とする方法。
【請求項２】
送信側ネットワークユニット（５，５ａ）と受信側ネットワークユニット（６，６ａ）が相互に異なる場合、
それぞれ要求された機能が送信側ネットワークユニット（５，５ａ）によりサポートされているという情報が受信側ネットワークユニット（６，６ａ）に送信されるか、または受信側ネットワークユニット（６，６ａ）により受信され、評価される請求項１記載の方法。
【請求項３】
送信側ネットワークユニット（５，５ａ）と受信側ネットワークユニット（６，６ａ）が相互に異なる場合において、それぞれ要求された機能が送信側のネットワークユニット（５，５ａ）と受信側のネットワークユニット（６，６ａ）によりサポートされる場合、それぞれ要求された機能が送信側ネットワークユニット（５，５ａ）によりサポートされるという情報が受信側ネットワークユニット（６，６ａ）により消去され、受信アプリケーション（２，２ａ）には通知されない、請求項１または２記載の方法。
【請求項４】
それぞれ要求された機能をサポートするか否かという情報をメッセージMM1＿submit.RES（Ｎ２）またはM-Send.conf（Ｎ２ａ）において、送信側ネットワークユニット（５，５ａ）から相応の送信アプリケーション（１，１ａ）に通知する、請求項１から３までのいずれか一項記載の方法。
【請求項５】
ＷＡＰメッセージM-Send.conf（Ｎ２ａ）において、フィールド名が１６進符号化された新たなヘッドフィールドを使用し、
該フィールド名のフィールド値は、それぞれ要求された機能をサポートする場合にはオクテット＜Octet 128＞を含み、サポートしない場合にはオクテット＜Octet 129＞を含む、請求項４記載の方法。
【請求項６】
それぞれ要求された機能をサポートするか否かという情報をメッセージMM1＿notification.REQ（３）ないしはM-notification.ind（３ａ）および／またはMM1＿retrieve.RES（Ｎ６）ないしはM-Retrieve.conf（Ｎ６ａ）において、受信側ネットワークエレメント（６，６ａ）から受信アプリケーション（２，２ａ）に通知する、請求項１から５までのいずれか一項記載の方法。
【請求項７】
ＷＡＰメッセージM-Notification.ind（Ｎ３ａ）および／またはM-Retrieve.conf（Ｎ６ａ）において、フィールド名が１６進符号化された新たなヘッドフィールドを使用し、
該ヘッドフィールドのフィールド値は、それぞれ要求された機能をサポートする場合にはオクテット＜Octet 128＞を含み、サポートしない場合にはオクテット＜Octet 12９＞を含む、請求項６記載の方法。
【請求項８】
受信アプリケーション（２，２ａ）は、それぞれ要求された機能が送信側および／または受信側ネットワークユニット（５，５ａ；６，６ａ）によりサポートされているか否かという情報の存在または非存在を評価し、
当該サポートされているか否かという情報をユーザに対して出力する、請求項１から７までのいずれか一項記載の方法。
【請求項９】
送信側のネットワークユニット（５，５ａ）と受信側のネットワークユニット（６，６ａ）が相互に異なり、要求された機能が応答課金である場合、
次の情報の少なくとも１つが送信側ネットワークユニット（５，５ａ）から受信側ネットワークユニット（６，６ａ）へ通知される：
・送信者が受信者による応答メッセージに対するコストを引き受ける用意があるという情報；
・応答メッセージを無料で送信できる期日についての情報；
・応答メッセージの最大サイズについての情報；
・応答メッセージを通知する際のオリジナルメッセージのメッセージ識別番号についての情報；
請求項１から８までのいずれか一項記載の方法。
【請求項１０】
送信側ネットワークユニット（５，５ａ）から受信側ネットワークユニット（６，６ａ）へ通知される前記情報の少なくとも１つをメッセージMM4＿forward.REQ（Ｎ８）において通知する、請求項９記載の方法。
【請求項１１】
送信アプリケーション（１，１ａ）、送信側ネットワークユニット（５，５ａ）、受信側ネットワークユニット（６，６ａ）および／または受信アプリケーション（２，２ａ）は、応答メッセージの許容最大サイズについての情報を通知ないし受信する、請求項１記載の方法。
【請求項１２】
最大許容サイズについての情報をメッセージMM1＿submit.REQ（Ｎ１）ないしM-Send.req（Ｎ１ａ）において、送信アプリケーション（１，１ａ）から送信側ネットワークユニット（５，５ａ）に通知する、請求項１１記載の方法。
【請求項１３】
最大許容サイズについての情報をメッセージMM1＿notfication.REQ（Ｎ３）ないしM-Notification.ind（Ｎ３ａ）および／またはMM1＿retrieve.RES（Ｎ６）ないしM-Retrieve.conf（Ｎ６ａ）において、受信側ネットワークユニット（６，６ａ）から受信アプリケーション（２，２ａ）に通知する、請求項１１または１２記載の方法。
【請求項１４】
ＷＡＰメッセージM-Send.req（Ｎ１ａ）、M-Notification.ind（Ｎ３ａ）および／またはM-Retrieve.conf（Ｎ６ａ）において、フィールド名が１６進符号化された新たなヘッドフィールドを使用し、
当該ヘッドフィールドのフィールド値は、複数の段階付けられた最大値の１つ、または送信者により選択された具体値を、応答メッセージの許容サイズにために含む、請求項１２または１３記載の方法。
【請求項１５】
１つのサービスプロバイダ（３，４）の管轄領域にあるネットワークユニットであって、
該ネットワークユニットは送信アプリケーション（１，１ａ）および／または受信アプリケーション（２，２ａ）に配属されており、
当該ネットワークユニット（５，５ａ；６，６ａ）を介してメッセージが送信アプリケーション（１，１ａ）から受信アプリケーション（２，２ａ）に通知され、
該メッセージは、送信者が受信者による応答メッセージのコストを引き受ける用意があるか否かについての情報、またはメッセージのコールバック機能についての情報を含んでいる形式のネットワークユニットにおいて、
前記ネットワークユニット（５，５ａ；６，６ａ）は、それぞれ要求された機能をこれがサポートするか否かについての情報を受信アプリケーション（２，２ａ）に通知するように構成されている、ことを特徴とするネットワークユニット。
【請求項１６】
移動無線網で通信を行うための移動無線加入者端末機器であって、 メッセージを、サービスプロバイダ（３，４）の管轄領域にあるネットワークユニット（５，５ａ；６，６ａ）から受信するための少なくとも１つの受信アプリケーション（２，２ａ）を有し、
前記メッセージは送信者から発するものであり、サービスプロバイダの管轄領域における特別の機能、すなわち応答課金またはメッセージのコールバックの要求を含んでいる形式の移動無線加入者端末機器において、
前記移動無線加入者端末機器は、それぞれ要求された機能が、関与するネットワークユニットによりサポートされているか否かについての情報を受信および評価するように構成されていることを特徴とする移動無線加入者端末機器。
【請求項１７】
移動無線加入者端末機器は、次の情報の少なくとも１つを通知ないし受信するように構成されている：
・送信側と受信側ネットワークユニット（５，５ａ；６，６ａ）とが異なる場合に対して、送信者が受信者による応答メッセージに対するコストを引き受ける用意があることについての情報の受信および評価；
・応答メッセージの許容最大サイズについての情報の通知および／または受信；
・応答課金機能が、送信側ネットワークユニット（５，５ａ）によりサポートされているか否かについての情報の受信および評価；
・応答課金機能が、受信側ネットワークユニット（６，６ａ）によりサポートされているか否かについての情報の受信および評価；
請求項１６記載の移動無線加入者端末機器。
【請求項１８】
メッセージとしてマルチメディアメッセージを使用する、請求項１から１４までのいずれか一項記載の方法。
【請求項１９】
移動無線網としてＵＭＴＳネットワークを使用する、請求項１から１４までのいずれか一項または請求項１８記載の方法。
【請求項２０】
ネットワークユニット（５，５ａ；６，６ａ）はＵＭＴＳネットワークのネットワークユニットである、請求項１５記載のネットワークユニット。
【請求項２１】
メッセージとしてマルチメディアメッセージを通知する、請求項１５または２０記載のネットワークユニット。
【請求項２２】
移動無線加入者端末機器はＵＭＴＳネットワークで通信するように構成されている、請求項１６または１７記載の移動無線加入者端末機器。
【請求項２３】
受信アプリケーション（２，２ａ）は、マルチメディアメッセージを受信するように構成されている、請求項１６，１７または２２のいずれか一項記載の移動無線加入者端末機器。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、メッセージを、移動無線網を介して伝送する際に情報流を拡張する方法であって、当該伝送は送信アプリケーションから送信側ネットワークユニットと受信側ネットワークユニットを介して受信アプリケーションに行われ、前記送信側ネットワークユニットと受信側ネットワークユニットとは同じもの、または相互の異なるものであり、かつ１つまたは２つのサービスプロバイダの管轄領域内にあり、前記メッセージによって、少なくとも１つのサービスプロバイダの管轄領域で特別の機能、すなわちメッセージの応答課金またはコールバックが要求され、前記メッセージは、応答課金がサポートされる場合、送信者が受信者による応答メッセージのコストを引き受ける用意があるかについての情報を含んでいる形式の方法に関する。
さらに本発明は上記方法を実施するためのネットワークユニットおよび移動無線加入者端末機器に関する。
【０００２】
【従来の技術】
移動無線システムＧＳＭ（GSM - Global System for Mobile Communications）は音声電話の他に、１６０文字長までの短いテキストメッセージを送受信する手段を提供する。このサービスはＳＭＳ（SMS - Short Message Service）と称される。より詳細には、ＧＳＭ03.40、バージョン7.4.0,リリース１９９８；Digital Cellular Telecommunications System; Technical realization of the Short Message Service (SMS) 参照。
【０００３】
次世代ＵＭＴＳ（UMTS - Universal Mobile Telecommunications System）の移動無線システムに対しては現在のところ、移動メッセージサービスのマルチメディア機能バリエーションが標準化されている。これはいわゆるＭＭＳ（MMS - Multimedia Messaging Service）である。3GPP TS 22.140 バージョン4.1.0,リリース 4; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS), 並びに 3GPP TS 23.140 バージョン4.3.0, リリース 4; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2 参照。
【０００４】
マルチメディア内容を有するメッセージは以下、ＳＭＳのテキストメッセージから区別するために単に短くＭＭＳと称する（MM - Multimedia Message;末尾のＳは複数）。ＳＭＳとは異なり、純粋なテキスト内容への制限はない。ＭＭＳでは、テキストを個別の好みに合わせてフォーマットしたり、オーディオおよびビデオ内容をメッセージに埋め込むことができる。
【０００５】
図１には、現在の技術水準による３ＧＰＰ（第３世代パートナーシップ）の観点からのＭＭＳネットワークアーキテクチャが示されている。ＭＭＳユーザエージェント（省略：ＵＡ；複数ＵＡｓ）とは例えば、移動無線電話または移動無線電話に接続された機器（例えばラップトップ等）上での、ＭＭＳを実現するアプリケーションと理解されたい。メッセージを送信するアプリケーションを以下、送信アプリケーション、特別のＭＭＳではユーザエージェントＡ（省略はＵＡＡ）と称し、受信されたアプリケーションを受信アプリケーション、特別のＭＭＳではユーザエージェントＢ（省略はＵＡＢ）と称する。図１によれば、送信アプリケーションＵＡＡから無線ネットワーク７を介して、ＭＭ１により示されたエアインタフェースを使用し、ＭＭがＭＭＳリレー/サーバＡ（ここでの省略はＲＳＡ；ＭＭＳリレー/サーバはＲＳ、複数はＲＳｓ）により示されたネットワークユニット５に送信される。ネットワークユニットは、ＭＭＳサービスプロバイダ３の管轄領域、すなわちいわゆるＭＭＳＥ（MMSE - Multimedia Messaging Service Environment）にあり、ＭＭＳ機能を使用する。インタフェースＭＭ４を介して、次にメッセージがＭＭＳリレー/サーバＢ（省略ＲＳＢ）により示されたネットワークユニット６にさらに伝送される。このネットワークユニット６は受信側ＭＭＳサービスプロバイダ４（ＭＭＳサービスプロバイダＢ）の管轄領域にある。この受信側ＭＭＳサービスプロバイダ４はさらに無線ネットワーク８を介し、インタフェースＭＭ１を使用してメッセージを受信アプリケーションＵＡＢ２に伝送する。
【０００６】
図１には、送信側ネットワークユニットＲＳＡ１と受信側ネットワークユニットＲＳＢ２とが同じではない一般的場合が示されている。しかし１つのＭＭＳＥだけが関与する特別の場合も従来技術で公知であり、インタフェースＭＭ１は必ずしもエアインタフェースとして構成する必要のないことも事実である。
【０００７】
上記仕様３ＧＰＰ  ＴＳ 23.140 バージョン4.3.0, リリース４に記載された、送信側および受信側ＲＳｓを前記特別の場合に識別するためのＭＭＳのフィーチャは、いわゆる応答課金である。これはリプレー課金と称され、これに従って送信者はＭＭの送信の際に自分の準備性を表明することができる。すなわち応答メッセージに対するコスト、とりわけマルチメディア応答（応答ＭＭ）に対するコストを受信者から引き受けることを表明することができる。ここでは付加的に送信者からの期日も通知することができる。相応の応答課金識別子を備えるＭＭが受信者に対するネットワークエレメントＲＳ上でダウンロードのために準備されると、このことがまず通知され、これに基づいてＭＭを自分の端末機器へダウンロードすることができる。ここで受信者には、通知の際にもＭＭのダウンロードの際にも、このいわゆるオリジナルＭＭへの応答メッセージは無料であることが通知される。受信者がこれを使用したければ、単に自分の端末機器に整列されたＭＭを応答ＭＭとして前に受信したオリジナルＭＭに指示し、送信すればよい。応答課金機能はこれまでＭＭＳＥ内で定義されていた。詳細な説明は、３ＧＰＰ  ＴＳ  23.140 バージョン４．３．０、リリース４の補遺Ｅにある。
【０００８】
ＭＭの転送に必要な情報はすべて、応答課金機能に対して補充された情報と同様に情報エレメントとして、３ＧＰＰ  ＴＳ  23.140 バージョン 4.3.0,リリース４に定義されたアブストラクトメッセージに書き込まれる。データ交換に関与する機器（アプリケーションＵＡまたはネットワークエレメントＲＳ）が情報エレメントを識別しなければ、これは変更されずに通過する。この特性は応答課金機能に対しては問題となり得る。なぜなら上記の応答課金機能は従来技術によれば、データ交換に関与するすべて機器（すなわちＵＡｓとＲＳの両方）が応答課金機能をサポートする場合にだけ機能するからである。例えば送信アプリケーションＵＡＡと受信アプリケーションＵＡＢだけが応答課金機能をサポートし、関与するネットワークエレメントＲＳはサポートしない場合（なぜならこれが古いＭＭＳバージョンをサポートするため）、応答ＭＭがネットワークエレメントＲＳにより識別されず、場合によっては拒絶されないこともある。すなわち応答ＭＭの送信者（＝オリジナルＭＭの受信者）は間違って、送信者から送信された応答ＭＭのコストが受信者（＝オリジナルＭＭの送信者）に課金されることを信じてしまう。
【０００９】
３ＧＰＰとＷＡＰフォーラム標準化審議会では、上記の互換性問題（ネットワークエレメントＲＳが応答課金機能をサポートしない）に対する解決手段も、応答課金機能を複数のＭＭＳＥへ拡張することに対する解決手段も知られていない。
【００１０】
前記の問題は、送信者が特別の機能をサービスプロバイダに要求するが、送信者および／または受信者が、１つまたは複数のサービスプロバイダの管轄領域において相応に関与するネットワークユニットが要求された機能をサポートするか否かを知らないという類似の他の場合にも存在する。将来は別の新たな機能、例えば「ＭＭＳからのバックコール」をＭＭＳに導入することも考えられる。すなわちこの新たな機能は送信ユニットおよび受信ユニットによりサポートされるが、場合により関与するネットワークユニットによってはサポートされない。
【００１１】
従来技術での他の問題は、オリジナルメッセージの送信者が応答課金指示により次のことから保護できないことである。すなわち受信者が非常に長い、従って非常に高価な応答メッセージを自分にリターン送信することから保護できないことである。
【００１２】
【発明が解決しようとする課題】
本発明の課題は、応答課金がサポートされている場合とサポートされていない場合が混在する条件の下で、応答メッセージの送信者（＝オリジナルメッセージの受信者）が間違って、送信者から送信された応答メッセージのコストが受信者（＝オリジナルメッセージの送信者）に課金されることを信じてしまわないように構成することである。
【００１３】
【課題を解決するための手段】
この課題は本発明により、冒頭に述べた形式の方法において、送信側および受信側ネットワークユニットが、それぞれ要求された機能をサポートするか否かについての情報を前記受信アプリケーションに通知することによって解決される。
【００１４】
従来技術で発生した互換性問題は本発明により次のようにして解決される。すなわち本発明の第１側面によれば、送信側および／または受信側ネットワークユニットの要求された応答課金機能をサポートするための情報を、データ交換に関与する機器間で伝送するのである。ここで第１の場合、送信側および受信側ネットワークユニット、とりわけ該当するネットワークエレメントＲＳはＭＭＳサービスプロバイダの管轄領域において同じである。該当するネットワークユニットからのフィードバックに関する情報は、本発明ではとりわけ受信アプリケーションに通知される。同様に相応する確認が送信アプリケーションに通知されることも本発明の一部である。この情報を送信および／または受信アプリケーションの側で受信することも同様に本発明の構成部である。
【００１５】
【発明の実施の形態】
さらに本発明により、要求された機能の拡張、例えば応答課金機能の拡張、または送信者によるコールバック要求の際の、送信および受信アプリケーションへのメッセージコールバック機能が可能である。この送信および受信アプリケーションは、種々のＭＭＳサービスプロバイダのＭＭＳを要求する（すなわち２つのＭＭＳＥ間で）。付加的データとして、ネットワークエレメントＲＳが供給された機能をサポートするかという情報を通知することにより、送信側ネットワークエレメントＲＳ（送信者のＭＭＳリレー／サーバ）から受信側ネットワークエレメントＲＳ（受信者のＭＭＳリレー／サーバ）への部分区間、ないし受信側ネットワークエレメントＲＳから受信アプリケーションＵＡＢへの部分区間の両方でＭＭを転送する際に、要求された機能が種々異なるＭＭＳＥ間でも可能となり、上に述べた互換性問題は解消する。
【００１６】
ネットワークエレメントＲＳが要求された機能を、ネットワークエレメントＲＳから受信アプリケーションＵＡＢへの部分区間でのＭＭの送信に対する直接的反応としてサポートするか否かという情報を通知することにより、該当する機能の快適性が格段に上昇する。
【００１７】
本発明の第２側面によれば、送信側ネットワークユニットと受信側ネットワークユニットとが相互に異なる場合、付加的情報が送信側ネットワークユニットから受信側ネットワークユニットへ伝送される。この付加的情報とは、受信者に対する応答課金の可能性、応答課金のための識別番号（これは有利にはオリジナルメッセージの識別番号に相応する）、オリジナルメッセージに回答する期日、および／または応答メッセージに対する最大許容サイズについての指示である。
【００１８】
本発明の第３側面によれば、送信者は一般的に、応答課金の際に応答メッセージのサイズに対する上限を指示する手段を得る。これは例えば複数の上限によって実現され、これらの上限の１つをオリジナルメッセージの送信者が選択する。択一的に、送信者は応答メッセージの最大サイズを自動的に選択することができる。これにより送信者は確実に応答メッセージが、送信者が自分で選択したコストを上回ることになるないようにすることができる。
【００１９】
本発明の相応の装置では、ネットワークユニットに相応の制御ユニットが設けられており、移動無線加入者機器に相応の受信および／送信アプリケーションが装備されている。ここでは上に述べたように、このアプリケーションが移動無線電話に直接インストールされているか、またはラップトップ、ノートブック等にインストールされているかは関係ない。概念「移動無線加入者機器」は、この実施形態も含む。とりわけ相応のソフトウエアプログラムも本発明の一部である。
【００２０】
【実施例】
本発明を図面に基づき詳細に説明する。
【００２１】
以下、例として特別機能；「応答課金」ないし「リプレー課金」に基づき、インタフェースＭＭ１上での付加的情報の交換によって、上記の互換性問題がどのようにＭＭＳＥ内で処理されるかを説明する（事例１）。続いて前記方法の一般的事例への拡張が紹介される。この一般的事例では、ＭＭｓが異なるＭＭＳサービスプロバイダの２つの異なるＭＭＳＥ間で交換される（事例２）。ここでの変更には、インタフェースＭＭ１の他にインタフェースＭＭ４も該当する。最後に、一般的事例２で説明される方法（ＭＭｓを２つのＭＭＳＥ間で交換する）の可能な実現を、ＷＡＰ（WAP - Wireless Application Protocol）でのエアインタフェースとして構成されたＭＭ１に対して紹介する。
【００２２】
Ｉ．事例１：ただ１つのＭＭＳＥ内での応答課金
まず図２に基づいて、送信アプリケーションＵＡＡ１（ＭＭＳユーザエージェントＡ）も、受信アプリケーションＵＡＢ２（ＭＭＳユーザエージェントＢ）も、同じＭＭＳサービスプロバイダからのＭＭＳを要求する場合を考察する。すなわちＭＭは１つのＭＭＳＥ内でだけ転送される。図２は、所属のいわゆるトランザクションフローチャートを示す。これは３ＧＰＰ  ＴＳ 23.140 バージョン4.3.0,リリース４に定義されたアブストラクトメッセージが示された３ＧＰＰによるものである。ユーザＡがＭＭを作成し、このＭＭを「リプレー課金」と標識付け、これをアブストラクトメッセージＮ１（MM1＿subnit.REQ）によってインタフェースＭＭ１を介して、そのＭＭＳサービスプロバイダのＭＭＳＥにあるネットワークエレメントＲＳに送信する。このＲＳは同時に送信側および受信側のネットワークエレメントであり、従って２つの参照符号５と６が付されている（図１参照）。ネットワークエレメントＵＡＡ１は、ＭＭを送信アプリケーションＵＡＡ１から正しく受信したことをアブストラクトメッセージＮ２（MM1＿submit.RES）により確認し、受信者Ｂにダウンロードの準備のできたＭＭについてアブストラクトメッセージＮ３（MM1＿notification.REQ）により通知する。アブストラクトメッセージＮ４（MM1＿notification.RES）は単に、メッセージが受信アプリケーションＵＡＢ２により正しく受信できたことに対する確認として用いられる。アブストラクトメッセージＮ５（MM1＿retrieve.REQ）により、ユーザＢはネットワークエレメントＲＳ５，６で準備されたＭＭのダウンロードを開始することができる。ＭＭのネットワークエレメントＲＳ５，６から受信アプリケーションＵＡＢ２への配信は、アブストラクトメッセージＮ６（MM1＿retrieve.RES）によって行われる。これに対する確認は、続いてアブストラクトメッセージＮ７（MM1＿acknowledgement.REQ）によって行われる。
【００２３】
本発明によれば、ネットワークエレメントＲＳから２つのアブストラクトメッセージＮ３（MM1＿notification.REQ=ＭＭについての通知）および／またはＮ６（MM1＿retrieve.RES=ＭＭの配信）が、ネットワークエレメントＲＳが要求された応答課金機能をサポートする場合、別の情報エレメントだけ補充される。新たな情報エレメントは例えば「リプレー課金サポート(Reply-Charging-Support)」と称することができる。ネットワークエレメントＲＳ（または一般的に：ＭＭＳサービスプロバイダ）が応答課金機能をサポートするか否かについての情報が存在する。テーブル１と２は本発明の補遺を示す。すなわちアブストラクトメッセージＮ３（MM1＿notification.REQ）とＮ６（MM1＿retrieve.RES）にある新たな情報エレメント「リプレー課金サポート」を示す。このアブストラクトメッセージは両方の場合とも有利には公知の情報エレメント「リプレー課金(Reply-Charging)」の後方に挿入される。
【００２４】
【表１】
0003857629.tif 000002
【００２５】
表１：事例１による、アブストラクトメッセージＮ３（MM1＿notification.REQ）とＮ６（MM1＿retrive.RES）にある付加的情報エレメント。
【００２６】
要求された応答課金機能をサポートしないネットワークエレメントＲＳは有利には、このネットワークエレメントに対して未知の情報エレメントを変化せずにさらに通過させ、このとき情報エレメント「リプレー課金サポート」を補充しない。受信者の受信アプリケーションＵＡＢはこのようにして、応答課金機能が自分のＭＭＳサービスプロバイダのＭＭＳＥでサポートされているか否かを識別し、相応に対処することができる。言い替えると：ネットワークエレメントＲＳによりセットされた情報エレメント「リプレー課金サポート」がアブストラクトメッセージＮ３（MM1＿notification.REQ）および／またはＮ６（MM1＿retrieve.RES）に存在する場合だけ、オリジナルＭＭの受信者は相応に標識付けられた応答ＭＭの送信の際に、応答課金機能がＭＭＳサービスプロバイダによりサポートされることを確信できる。
【００２７】
応答課金機能の快適性を高めるために、上に新たに定義された情報エレメント「リプレー課金サポート(Reply-Charging-Support)」を有利にはアブストラクトメッセージＮ２（MM1＿submit.RES）にも挿入する。このアブストラクトメッセージＮ２により、ＭＭの正しい受信がネットワークエレメントＲＳの送信後に確認される（図２参照）。このようにして送信アプリケーションＵＡＡ１には、応答課金識別子を備えるオリジナＭＭの送信後に、相応の識別子を備える応答ＭＭの送信後の受信アプリケーションＵＡＢ２と同じように、ＭＭＳサービスプロバイダが要求された応答課金機能をサポートするか否かについての情報が与えられる。表２は、アブストラクトメッセージＮ２（MM1＿submit.RES）に対する付加的情報エレメント「リプレー課金サポート」を示す。この情報エレメントは有利には公知の情報エレメント「メッセージＩＤ」の後方に挿入される。
【００２８】
【表２】
0003857629.tif 000003
【００２９】
表２：事例１による、アブストラクトメッセージＮ２（MM1＿submit.RES）内の付加的情報エレメント。
【００３０】
ＩＩ．事例２：２つの異なるＭＭＳＥ間での応答課金
次に送信アプリケーションＵＡＡと受信アプリケーションＵＡＢとが異なるＭＭＳサービスプロバイダのＭＭＳを要求する場合を考察する。すなわち応答課金識別子を備えるＭＭが２つのＭＭＳＥ間で転送される。応答課金はこの場合、次の場合にだけ申し分なく機能する。すなわち送信および受信アプリケーションの他に、送信者のネットワークエレメントＲＳＡと受信者のネットワークエレメントＲＳＢとが応答課金機能をサポートする場合だけ申し分なく機能する。異なるＭＭＳＥ間での応答課金の互換性問題はここでは本発明により次のようにして解消される。すなわち付加的情報をＭＭの転送の際に共に伝送するのである。この付加的情報は、応答課金機能を相応のネットワークエレメント（ＲＳＡ，ＲＳＢ）サポートするか否かについての情報を与える。
【００３１】
図３は、図２のトランザクションフローチャートの相応の拡張を示す。そこに示したアブストラクトメッセージに加えて、ここではインタフェースＭＭ４（図１参照）に対するアブストラクトメッセージが示されている。
【００３２】
図３によれば、ユーザＡがＭＭを作成し、これを「リプレー課金」により標識付け、インタフェースＭＭ１を介して自分のＭＭＳサービスプロバイダＡのＭＭＳＥにあるネットワークエレメントＲＳＡ５に送信する。このサービスプロバイダが要求された応答課金機能をサポートしていれば、本発明によりネットワークエレメントＲＳＡ５はアブストラクトメッセージＮ８でＭＭと共に、次の情報を受信者のＭＭＳＥにあるネットワークエレメントＲＳＢ６にさらに伝送する：（図３のメッセージＮ９（MM4＿forward.RES）について今のところ立ち入る必要はない。）
１．送信者が、応答ＭＭに対するコストを受信者から引き受けることの用意（情報エレメント「リプレー課金(Reply-Charging)」）、
２．無料で応答ＭＭを送信するまでの期日（情報エレメント「リプレー課金デッドライン(Reply-Charging-Deadline)」）、
３．応答ＭＭに対する最大サイズ（情報エレメント「リプレー課金サイズ(Reply-Charging-Size)」）、
４．送信者のＭＭＳサービスプロバイダが要求された応答課金機能をサポートしているか否かの情報（例えば名称「オリジナルＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMSE)」）、または（伝送されるＭＭが応答ＭＭである場合；この場合は応答ＭＭが新たなオリジナルＭＭとして有効である）：
５．（元の）オリジナルＭＭのメッセージＩＤ（情報エレメント「リプレー課金ＩＤ(Reply-Charging-ID)」）。
【００３３】
表３は、アブストラクトメッセージＮ８（MM4＿forward.REQ）にある本発明の付加的情報エレメントを示す。ここで新たな情報エレメント「リプレー課金ＩＤ」は有利には公知の情報エレメント「メッセージＩＤ」の後方に、他の４つの新たな情報エレメントは公知の情報エレメント「コンテンツ」の後方に挿入される。
【００３４】
【表３】
0003857629.tif 000004
【００３５】
表３：事例２による、アブストラクトメッセージＮ８（MM4＿forward.REQ）にある付加的情報エレメント。
【００３６】
表３にリストアップされていない情報エレメント「リプレー課金」、「リプレー課金デッドライン」および「リプレー課金ＩＤ」はここで新たに定義する必要はない。これらは公知のようにすでにインタフェースＭＭ１で使用され、ここでは本発明により新たなインタフェースＭＭ４に伝送される。情報エレメント「オリジナルＭＭＳＥでリプレー課金サポート」について以下詳細に説明する。
【００３７】
上記事例１で定義された、ＭＭＳサービスプロバイダが要求された応答課金機能をサポートするか否かという情報を通知する情報エレメント「リプレー課金サポート」は、ここで説明する場合に対して十分ではない。なぜならネットワークエレメントＲＳＢ６は、これが応答課金機能をサポートしない場合には、ネットワークエレメントＲＳＡ５によりセットされた情報エレメント「リプレー課金サポート」を変化せずにＭＭの通信ないし配信の際に受信アプリケーションＵＳＢ２にさらに引き渡すこととなるからである。この特性は受信アプリケーションＵＡＢ２により間違って解釈されることがある。受信アプリケーションは、ＭＭの伝送に関与する両方のネットワークエレメント５，６（ＲＳＡ、ＲＳＢ）が要求された応答課金機能をサポートするか否かの情報を必要とする。この理由から本発明では、ネットワークエレメントＲＳＡ５とネットワークエレメントＲＳＢ６との間のインタフェースＭＭ４上に他の情報エレメントが、ネットワークエレメントＲＳＢ６と受信アプリケーションＵＡＢ２と間のインタフェースＭＭ１上として定義される。２つの新たな情報エレメントは「オリジナルＭＭＳＥでリプレー課金サポート」（応答課金が送信側ＭＭＳＥの側でサポートされる）と「受信ＭＭＳＥでリプレー課金サポート」（応答課金が受信側ＭＭＳＥの側でサポートされる）とすることができる。これらは表３，５，６に示されている。アブストラクトメッセージＮ３（表５）とＮ６（表６）では、情報エレメント「受信ＭＭＳＥでリプレー課金サポート」が有利には情報エレメント「リプレー課金」の後方に挿入されている。
【００３８】
ネットワークエレメントＲＳＢが応答課金機能をサポートする場合には、ネットワークエレメントＲＳＢは、受信者が通信する前、ないしＭＭを配信する前に、アブストラクトメッセージＮ８（MM4＿forward.REQ）に相応の情報エレメント「オリジナルＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMSE)」が含まれているか否かを検査しなければならない。含まれていれば、ネットワークエレメントＲＳＢは自分の側で相応の情報エレメント「受信ＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Recipient-MMSE)」をアブストラクトメッセージＮ３（MM1＿notification.REQ=ダウンロードの準備されたＭＭを介する通信）ないしはアブストラクトメッセージＮ６（MM1＿retrieve.RES=ＭＭの配信）に挿入しなければならない。オプションとしてネットワークエレメントＲＳＢは、ネットワークエレメントＲＳＡによりセットされた情報エレメント「オリジナルＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMSE)」を、行われた検査の後で、コストのかかるエアインタフェースを軽減するために再び消去することができる。ただしこれは、ネットワークエレメントＲＳＢがこれを識別できる場合である。受信者の受信アプリケーションＵＡＢこの方法により、情報エレメント「受信ＭＭＳＥでリプレー課金サポート」の存在または非存在を評価することによって簡単に、オリジナルＭＭへの応答ＭＭの送信が２つの関与するＭＭＳサービスプロバイダによって処理できるか否かを識別できる。
【００３９】
情報エレメント「リプレー課金サイズ(Reply-Charging-Size)」は応答ＭＭの許容サイズを表す。この情報エレメントも本出願の対象である。有利にはアブストラクトメッセージＮ１（MM1＿submit.REQ）、Ｎ８（MM4＿forward.REQ），Ｎ３（MM1＿notification.REQ）およびＮ６（MM1＿retrieve.RES）に補充される。これは応答課金機能の快適性を高めるためである。この新たな情報エレメントによりオリジナルＭＭの送信者は、応答ＭＭに対する時間的期日の他にその最大サイズを設定することができる。択一的にまたはこれに補充して、これをＭＭの伝送に関与するＭＭＳサービスプロバイダの１つによっても使用することができ、応答ＭＭのサイズを制限できる。表３から６には、相応のアブストラクトメッセージに新たに定義された情報エレメント「リプレー課金サイズ」が示されている。ここでこの情報エレメントは、アブストラクトメッセージＮ１，Ｎ３およびＮ６に、それぞれ公知の情報エレメント「リプレー課金デッドライン」の後方に挿入されている。
【００４０】
【表４】
0003857629.tif 000005
【００４１】
表４：アブストラクトメッセージＮ１（MM1＿submit.REQ）における付加的情報エレメント。
【００４２】
【表５】
0003857629.tif 000006
【００４３】
表５：事例２による、アブストラクトメッセージＮ３（MM1＿notification.REQ）における付加的情報エレメント。
【００４４】
【表６】
0003857629.tif 000007
【００４５】
表６：事例２による、アブストラクトメッセージＮ６（MM1＿retrieve.RES）における付加的情報エレメント。
【００４６】
事例１で説明した手段と同様に、ここで導入された情報エレメント「オリジナルＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMSE)」の有利にはアブストラクトメッセージＮ２（MM1＿submit.RES）に挿入される。このアブストラクトメッセージＮ２により、ＭＭの正しい受信がネットワークエレメントＲＳにより確認される。このことは応答課金機能の快適性を格段に向上させる。なぜならこのようにして、送信アプリケーションＵＡＡは応答課金識別子を備えるオリジナルＭＭの送信後に、受信アプリケーションＵＡＢも相応に標識付けられた応答ＭＭの送信後に（この場合はオリジナルの応答ＭＭの受信アプリケーションＵＡＢ）、それぞれのＭＭＳサービスプロバイダが要求された応答課金機能をサポートするか否かの情報を得るからである。表７は、アブストラクトメッセージＮ２（MM1＿submit.RES）における付加的情報エレメント「オリジナルＭＭＳＥでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMSE)」を示す。これは有利には情報エレメント「メッセージＩＤ」の後方に挿入される。
【００４７】
【表７】
0003857629.tif 000008
【００４８】
表７：事例２による、アブストラクトメッセージＮ２における付加的情報エレメント。
【００４９】
ＩＩＩ．本発明のＷＡＰへの転換
これまでの従来技術によれば、ＭＭＳの実現は単にＷＡＰ（WAP - Wireless Application Protocol）を介してだけ可能である。ＭＭＳに適した端末機器とＷＡＰゲートウエイとの間のエアインタフェース（３ＧＰＰ：ＭＭ１）をつなぐために、３ＧＰＰ  ＴＳ 22.140 バージョン４．１．０、リリース４とＷＡＰ−209.102MMSEncapsulation, 8,Feb.2001（ワイヤレスアプリケーションプロトコル；ＷＡＰマルチメディアメッセージングサービス；メッセージカプセル化；ＭＭＳドラフトＳＣＤ）によれば、ＷＡＰ  ＷＳＰ伝送プロトコルの使用が規定されている。従って次に、応答課金のために新たに定義された上記の、３ＧＰＰアブストラクトメッセージの情報エレメントをＷＡＰ実現のＷＡＰメッセージに転換するかを説明する。ここでは例として事例２による実施例（２つのＭＭＳＥ間での応答課金）を転換する。なぜならこの事例は一般的な場合を表しており、この事例には３ＧＰＰとＷＡＰの転換に対して大きなチャンスが認められるべきだからである。
【００５０】
図４は、ＷＡＰ−209.102-MMSEncapsulationによる現在の技術でのＷＡＰにおけるトランザクションフローチャートを示す。このフローチャートでは、ＷＡＰメッセージの交換がＭＭの伝送の場合において、関与する４つの具体例間で行われる。これら具体例は、送信アプリケーション１ａ（ＭＭＳクライアントＡ、省略ＣＡ）、送信側ネットワークエレメント５ａ（ＭＭＳプロキシーリレーＡ、省略ＰＲＡ）、受信側ネットワークエレメント６ａ（ＭＭＳプロキシーリレーＢ、省略ＰＲＢ）、そして受信アプリケーション２ａ（ＭＭＳクライアントＢ、省略ＣＢ）である。本願に該当するＷＡＰメッセージＮ１ａ（M-Send.req）、Ｎ２ａ（M-Send.conf）、Ｎ３ａ（M-Notification.ind）およびＮ１６ａ（M-Retrieve.conf）はここでは太く示されている。ここでＷＡＰメッセージＮ１ａは上記メッセージＮ１に相当し、ＷＡＰメッセージＮ２ａは上記メッセージＮ２に相当する等々。付加的に公知のメッセージＮ１０ａ（M-Delivery.ind）が示されている。３ＧＰＰに定義された概念ＭＭＳユーザエージェント、ＭＭＳリレー／サーバおよびＭＭＳＥはＷＡＰに存在しないことに注意されたい。従ってこの節ではもっぱら概念：ＭＭＳクライアントとＭＭＳプロキシーリレーないしそれらの省略に付いて説明するが、省略は同じ具体例を意味する。３ＧＰＰ概念ＭＭＳＥに対してＷＡＰには類似の表現は存在しない。
【００５１】
ＷＡＰ−209.102-MMSEncapsulationに従いＷＡＰメッセージのヘッドフィールドは、フィールド名およびそれに続くフィールド値からなる。フィールド値は少なくとも１つのオクテット（８ビットワード）からなる。１６進値をフィールド名に割り当てることが表８に示されている。現在は２４のフィールド名が存在する。本願で新たに定義されたフィールド名は従って有利には番号２５（１６進：０×１９）から始まる。これらは表９に示されている。
【００５２】
【表８】
0003857629.tif 000009
【００５３】
表８：フィールド名の割り当て（従来技術）。
【００５４】
【表９】
0003857629.tif 000010
【００５５】
表９：本発明により新たに定義されたフィールド名。
【００５６】
ＷＡＰ−209.102-MMSEncapslationによる、ＷＡＰのヘッドフィールドは常にフィールド名とフィールド値からなるから、ここで新たに定義されるヘッドフィールドの各々に対して少なくとも１つのフィールド値を定義しなければならない。これについて以下に説明する。
【００５７】
１つのヘッドフィールドのフィールド値を符号化するのに全体で４つの可能性がある。ここで第１のオクテットは符号化の形式の長さを介して区別する（表１０参照）。
【００５８】
【表１０】
0003857629.tif 000011
【００５９】
表１０：フィールド値を符号化するための４つの可能性（従来技術）。
【００６０】
エアインタフェースで伝送すべきデータ量を小さく維持するため、新たに定義された２つのヘッドフィールド「オリジナルＭＭＳプロキシーリレーでリプレー課金サポート」と「受信ＭＭＳプロキシーリレーでリプレー課金サポート」とは有利にはもっぱら第４の値領域（１２８から２５５）からなる。新たなヘッドフィールド「オリジナルＭＭＳプロキシーリレーでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMS-Proxy-Relay)」と「受信ＭＭＳプロキシーリレーでリプレー課金サポート(Replay-Charging-Support-At-Recipient-MMS-Proxy-Relay)」の可能な定義は次のとおりである：
【００６１】
【外１】
0003857629.tif 000012
【００６２】
新たに定義されたヘッドフィールド「リプレー課金サイズ(Reply-Charging-Size)」に対するフィールド値はステップ毎に（応答ＭＭはＸ、ＹまたはＺｋバイトの大きさになることができる）または具体的に（応答ＭＭはＸｋバイトの大きさにだけなることが）指示することができる。新たなヘッドフィールド「リプレー課金サイズ(Reply-Charging-Size)」の可能な定義は、応答メッセージの可能な大きさを段階付けた場合に次のようになる：
【００６３】
【外２】
0003857629.tif 000013
【００６４】
応答メッセージの可能な大きさを具体的に指示した場合の新たなヘッドフィールド「リプレー課金サイズ(Reply-Charging-Size)」の可能な定義は次のとおりである（値領域１）：
【００６５】
【外３】
0003857629.tif 000014
【００６６】
別の符号化手段についてはここでは詳細に立ち入らない。しかし本発明の枠内で種々の符号化手段が存在することは明かである。
【００６７】
本発明によりＷＡＰメッセージに補充されたＮ１ａ（M-Send.reg）、Ｎ２ａ（M-Send.conf）、Ｎ３ａ（M-Notification.ind）およびＮ６ａ（M-Retieve.conf）が表１１から１４に示されている。ＭＭＳＥ内で応答課金機能を実現するために必要な他の応答課金機能はそこには示されていない。なぜなら３ＧＰＰに定義された情報エレメントのＷＡＰフォーマットへの正確な転換は現在、まだ終了していないからである。ＷＡＰメッセージＮ１ａ（M-Send.req）にはヘッドフィールド「リプレー課金サイズ」が有利にはヘッドフィールド「内容タイプ(Content-Type)」の後方に補充された。このヘッドフィールドにより、応答課金機能を使用しようとするアプリケーションＣＡ１ａは、ＭＭの送信の際に期日に指示に加えて応答ＭＭのサイズを制限することができる。
【００６８】
【表１１】
0003857629.tif 000015
【００６９】
表１１：ＷＡＰメッセージＮ１ａ（M-Send.req）における新たに定義されたヘッドフィールド。
【００７０】
ＷＡＰメッセージＮ２ａ（M-Send.conf）には、ヘッドフィールド「オリジナルＭＭＳプロキシーリレーでリプレー課金サポート(Reply-Charging-Support-At-Originator-MMS-Proxy-Relay)」が有利にはヘッドフィールド「メッセージＩＤ(Message-ID)」の後方に補充された。このヘッドフィールドによりＭＭを送信した送信アプリケーションＣＡ１ａは、相応のネットワークエレメントＰＲＡが応答ＭＭに対するコストを送信者が引き受けることを理解し受け入れたか、または前に受信され、相応に標識付けられたオリジナルＭＭへの応答ＭＭを理解し受け入れたかについて通知される。
【００７１】
【表１２】
0003857629.tif 000016
【００７２】
表１２：ＷＡＰメッセージＮ２ａ（M-Send.conf）において新たに定義されたヘッドフィールド。
【００７３】
ＷＡＰメッセージＮ３ａ（M-Notfication.ind）とＮ６ａ（N-Retrive.conf）は（場合により存在する、送信者のネットワークエレメントＰＲ５ａが応答課金機能をサポートするという情報の他に）、受信者のネットワークエレメントＰＲ６ａによりセットされたヘッドフィールド「受信ＭＭＳプロキシーリレーでリプレー課金サポート(Replay-Charging-Support-At-Recipient-MMS-Proxy-Relay)」を含む。しかし受信者の受信アプリケーションＣＢ２ａに対しては、ヘッドフィールド「受信ＭＭＳプロキシーリレーでリプレー課金サポート(Replay-Charging-Support-At-Recipient-MMS-Proxy-Relay)」だけが重要である。これは有利には次の場合にだけセットされる。すなわち送信側ネットワークエレメントＰＲＡ５ａと受信側ネットワークエレメントＰＲＢ６ａの両方が応答課金機能をサポートする場合にだけセットされる。これが存在すれば、受信アプリケーションＣＢ２ａは、前に受信されたオリジナルＭＭへの応答ＭＭが関与する両方のＭＭＳサービスプロバイダにより理解されることを確信できる。ヘッドフィールド「受信ＭＭＳプロキシーリレーでＸ−Ｍｍｓリプレー課金サポート(X-Mms-Reply-Charging-Support-At-Recipient-MMS-Proxy-Relay)」はＷＡＰメッセージＮ３ａにおいて有利には公知のヘッドフィールド「Ｍ−Ｍｍｓコンテンツロケーション(M-Mms-Content-Location)」の後方に、ＷＡＰメッセージＮ６ａでは有利には公知のヘッドフィールド「コンテンツタイプ(Content Type)」の後方に挿入されている。ヘッドフィールド「Ｘ−Ｍｍｓリプレー課金サイズ(X-Mms-Reply-Charging-Size)」は、ＷＡＰメッセージＮ３ａにおいて有利には公知のヘッドフィールド「Ｘ−Ｍｍｓ満了(X-Mms-Expiry)」の後方に、ＷＡＰメッセージＮ６ａにおいては有利には公知のヘッドフィールド「Ｘ−Ｍｍｓ読み出しリプレー(X-Mms-Read-Reply)」の後方に挿入されている。
【００７４】
【表１３】
0003857629.tif 000017
【００７５】
表１３：ＷＡＰメッセージＮ３ａ（M-Notification.ind）における新たに定義されたヘッドフィールド。
【００７６】
【表１４】
0003857629.tif 000018
【００７７】
表１４：ＷＡＰメッセージＮ６ａ（M-Retieve.conf）において新たに定義されたヘッドフィールド。
【００７８】
本発明を応答課金機能に基づいて詳細に説明した。しかし移動無線加入者により要求される他の機能に対しても使用することができる。
【００７９】
さらに本発明は、マルチメディアメッセージに対してだけ使用されるのではなく、相応にしてＳＭＳメッセージの送信ないし受信にも使用できる。
【図面の簡単な説明】
【図１】図１は、３ＧＰＰの仕様によるＭＭＳネットワークアーキテクチャを示す。
【図２】図２は、送信アプリケーション（ＵＡＡ）から受信アプリケーション（ＵＡＢ）へＭＭが、ただ１つのネットワークエレメントＲＳを関与して送信される場合のトランザクションフローチャートである。
【図３】図３は、送信アプリケーション（ＵＡＡ）から受信アプリケーション（ＵＡＢ）へＭＭが、２つのネットワークエレメント（ＲＳｓ）を関与して送信される場合のトランザクションフローチャートである。
【図４】図４は、送信アプリケーション（ＣＡ）から受信アプリケーション（ＣＢ）へ２つのネットワークエレメント（ＰＲｓ）を関与して送信される場合に対する、ＷＡＰでのトランザクションフローチャートである。
【符号の簡単な説明】
１  送信アプリケーション（ＭＭＳユーザエージェントＡ＝ＵＡＡ）
１ａ  送信アプリケーション（ＭＭＳクライアントＡ＝ＣＡ）
２  受信アプリケーション（ＭＭＳユーザエージェントＢ＝ＵＡＢ）
２ａ  受信アプリケーション（ＭＭＳクライアントＢ＝ＣＢ）
３  ＭＭＳ  サービスプロバイダ（ＭＭＳサービスプロバイダＡ）
４  ＭＭＳサービスプロバイダ（ＭＭＳサービスプロバイダＢ）
５  送信側ネットワークユニット（ＭＭＳリレーサーバＡ＝ＲＳＡ）
５ａ  送信側ネットワークユニット（ＭＭＳプロキシーリレーＡ＝ＲＰＡ）
６  受信側ネットワークユニット（ＭＭＳリレーサーバＢ＝ＲＳＢ）
６ａ  受信側ネットワークユニット（ＭＭＳプロキシリレーＢ＝ＰＲＢ）
７  無線ネットワーク
８  無線ネットワーク
ＭＭ１  インタフェース
ＭＭ４  インタフェース
Ｎ１  メッセージ  MM1＿submit.REQ
Ｎ１ａ  ＷＡＰメッセージ  M-Send.req
Ｎ２  メッセージ  MM1＿submit.RES
Ｎ２ａ  ＷＡＰメッセージ  M-Send.conf
Ｎ３  メッセージ  MM1＿notification.REQ
Ｎ３ａ  ＷＡＰメッセージ  M-Notification.ind
Ｎ４  メッセージ  MM1＿notification.RES
Ｎ４ａ  ＷＡＰメッセージ  M-NotifyResp.req
Ｎ５  メッセージ  MM1＿retrieve.REQ
Ｎ５ａ  ＷＡＰメッセージ  WSP GET
Ｎ６  メッセージ  M＿retrieve.conf
Ｎ６ａ  ＷＡＰメッセージ  M-Retrieve.conf
Ｎ７  メッセージ  MM1＿acknowledgement.REQ
Ｎ７ａ  ＷＡＰメッセージ  M-Acknowledge.ind
Ｎ８  メッセージ  MM4＿forward.REQ
Ｎ９  メッセージ  MM4＿forward.RES
Ｎ１０ａ  ＷＡＰメッセージ  M-Delivery.ind
【図１】
0003857629.tif 000019
【図２】
0003857629.tif 000020
【図３】
0003857629.tif 000021
【図４】
0003857629.tif 000022