"移動無線ネットワークにおけるマルチメディアメッセージ伝送のためのデータ伝送コストアカウント方法において、マルチメディアメッセージにおける伝送されるまたは伝送しようとするデータに、該データに関連づけられた少なくとも1つの応答の送信コストに関する少なくとも1つのコスト信号を割り当て、1つまたは複数の該コスト信号を1つまたは複数のデータ受信側へ伝送し、1つまたは複数の前記コスト信号に、データの出所送信側による少なくとも1つの応答に対するコストの負担に関する情報が含まれており、前記コスト信号に、少なくとも1つの応答と前記データとの対応づけを可能とするデータに関する識別情報が含まれており、1つまたは複数の前記コスト信号は、マルチメディアメッセージの伝送データにおける1つまたは複数のヘッダフィールドに含まれていることを特徴とする、データ伝送コストアカウント方法。前記コスト信号によって、伝送されたデータに対する応答を本来の受信側が無料でまかなえる期間を設定する、請求項1記載の方法。前記コスト信号によって、伝送されたデータに対し本来の受信側が無料でまかなえる応答の個数を設定する、請求項1または2記載の方法。データが複数の受信側に伝送されるときには前記データ送信側が個々のデータ送信に対しそれぞれ異なるコスト信号を割り当てる、請求項1または2記載の方法。1つまたは複数のコスト信号の相違を、応答に対するコスト負担の受け入れ用意および/または該受け入れ用意の期間および/または無料で行える応答の個数に関連づける、請求項4記載の方法。データを受信する前、受信した時または受信した後、視覚的または聴覚的にコスト信号情報を受信側に表示する、請求項1または2記載の方法。移動メッセージサービスMobileMessagingServiceMMSに適用する、請求項1または2記載の方法。伝送標準UMTSUniversalMobileTelecommunicationSystem、GSMGlobalsystemformobilecommunication、GPRSGeneralpacketradioserviceおよび/またはEDGEEnhancedDataRatesforGSMenvironmentsに適用する、請求項1または2記載の方法。1つまたは複数の応答に対するコスト負担受け入れ用意状態を1つのヘッダフィールドに格納し、該コスト負担受け入れ用意の期間を別のヘッダフィールドに格納する、請求項1または2記載の方法。1つまたは複数のコスト信号をヘッダフィールド0x1B~0x1Eに格納する、請求項9記載の方法。データセットマルチメディアメッセージを送信側MMSユーザエージェントAからサービスプロバイダのMMSリレーへ伝達するとき、伝達されたデータセットマルチメディアメッセージの受信をサービスプロバイダのMMSリレーが送信側MMSユーザエージェントAに対し確認応答するとき、新たなデータセットマルチメディアメッセージの存在に関してサービスプロバイダのMMSリレーにより受信側MMSユーザエージェントBに通知するとき、本来のデータの受信側MMSユーザエージェントBからサービスプロバイダのMMSリレーへ応答マルチメディアメッセージを伝達するとき、および本来の受信側MMSユーザエージェントBからの応答マルチメディアメッセージの存在に関して本来の送信側MMSユーザエージェントAに通知するとき、前記コスト信号を伝送する、請求項1または2記載の方法。付加的なヘッダフィールドを送付物MSendreqMSendconfMNotificationindMRetrieveconfにそれぞれ割り当てる、請求項1または2記載の方法。送信側が送信すべきデータに対する1つまたは複数の応答のために送信側が行おうとするコスト負担の可能性に関する付加的なヘッダフィールドと、コスト負担受け入れ用意期間を設定するための付加的なヘッダフィールドとを、送出された送付物MSendreqに割り当てる、請求項12記載の方法。プロバイダからデータ送信側に戻される送付物MSendconf内に、応答に対するコスト負担を是認または部分的に拒否する確認応答をもつヘッダフィールドと、データ送信側にとって予測されるコストに関する情報をもつヘッダフィールドを割り当てる、請求項13記載の方法。プロバイダから受信側へ送出される送付物MNotificationind内で、コストの負担を表し場合によっては応答期間および/または応答回数の制限を表す信号が、少なくとも1つのヘッダフィールドにおかれる、請求項12記載の方法。プロバイダから受信側へ送出される送付物MNotificationind内で、コストの負担を表し場合によっては応答期間および/または応答回数の制限を表す信号が、少なくとも1つのヘッダフィールドにおかれる、請求項13記載の方法。プロバイダから受信側へ送出される送付物MNotificationind内で、コストの負担を表し場合によっては応答期間および/または応答回数の制限を表す信号が、少なくとも1つのヘッダフィールドにおかれる、請求項14記載の方法。受信側からプロバイダに送信される応答には、送信されたデータに対する応答であることを表す指示子と、どのデータであるかを表す識別情報とが含まれている、請求項12から15のいずれか1項記載の方法。本来の送信側MMSユーザエージェントAに対する通知には、受信のために用意されている送信が応答であるという情報と、どのデータに係わるかかの識別情報が含まれている、請求項11記載の方法。本来の送信側MMSユーザエージェントAに対する通知には、受信のために用意されている送信が応答であるという情報と、どのデータに係わるかかの識別情報が含まれている、請求項18記載の方法。個々の識別信号に少なくとも1つのヘッダフィールドを付加的に追加し、該ヘッダフィールドに識別信号に対する応答期限をセットする、請求項1または2記載の方法。請求項1から21のいずれか1項記載の方法を実施するための移動通信装置5;6。1つまたは複数の応答に対するコスト負担受け入れを承認するための受け入れスイッチ16が設けられている、請求項22記載の移動通信装置5;6。1つまたは複数の応答に対するコストを負担することと該コスト負担の期間を視覚的または聴覚的に表示するための表示手段15が設けられている、請求項23記載の移動通信装置。前記受け入れスイッチ16はソフトウェアによって実装されており入力手段を介して選択される、請求項23または24記載の移動通信装置。1つまたは複数の応答のコストを負担するコスト信号をデータ送付物9,13のヘッダフィールド17;18;19;20;21に割り当てるためのソフトウェアが設けられている、請求項22記載の移動通信装置5;6。1つまたは複数の応答のコストを負担するコスト信号をデータ送付物9,13のヘッダフィールド17;18;19;20;21に割り当てるためのソフトウェアが設けられている、請求項23記載の移動通信装置5;6。1つまたは複数の応答のコストを負担するコスト信号をデータ送付物9,13のヘッダフィールド17;18;19;20;21に割り当てるためのソフトウェアが設けられている、請求項24記載の移動通信装置5;6。1つまたは複数の応答のコストを負担するコスト信号をデータ送付物9,13のヘッダフィールド17;18;19;20;21に割り当てるためのソフトウェアが設けられている、請求項25記載の移動通信装置5;6。移動無線ネットワークにおけるマルチメディアメッセージ伝送に対するデータ伝送コストアカウントのための移動通信装置5,6において、aマルチメディアメッセージの伝送データに関連づけられた少なくとも1つの応答の送信コストのために、マルチメディアメッセージにおける伝送されるまたは伝送しようとするデータに、少なくとも1つのコスト信号を割り当てる手段が設けられており、前記コスト信号には、データの出所送信側による少なくとも1つの応答に対するコスト負担に関する情報が含まれており、b前記コスト信号のために識別情報を対応づける手段が設けられており、前記識別信号によって、マルチメディアメッセージにおけるデータに少なくとも1つの応答が対応づけられ、cマルチメディアメッセージの伝送データにおける1つまたは複数のヘッダフィールドに、1つまたは複数の前記コスト信号を収容する手段と、d1つまたは複数の前記コスト信号を1つまたは複数のデータ受信側へ伝送する手段が設けられていることを特徴とする、データ伝送コストアカウントのための移動無線装置。本発明の課題は、移動無線ネットワークの加入者に対するコストのコントロールならびに制御を簡単にすることである。本発明によればこの課題は、マルチメディアメッセージにおける伝送されるまたは伝送しようとするデータに、該データに関連づけられた少なくとも1つの応答の送信コストに関する少なくとも1つのコスト信号を割り当て、1つまたは複数の該コスト信号を1つまたは複数のデータ受信側へ伝送し、1つまたは複数の前記コスト信号に、データの出所送信側による少なくとも1つの応答に対するコストの負担に関する情報が含まれており、前記コスト信号に、少なくとも1つの応答と前記データとの対応づけを可能とするデータに関する識別情報が含まれており、1つまたは複数の前記コスト信号は、マルチメディアメッセージの伝送データにおける1つまたは複数のヘッダフィールドに含まれていることにより解決される。本発明による方法を用いることで、データ受信側が受け取るデータに対し無料で応答することができるようになる。これによりデータ送信側にとってたとえばアンケート実施などの可能性が開かれる。このような場合、これまでは応答する側が応答メッセージのコストを負担することになってしまい、その結果、回答率が低くなっていた。本発明によれば受信側の応答にかかるコストを受信側にとって疑う余地なく無料にすることができるので、受信側にとってコスト管理が容易になる。コスト信号を送信側により設定可能であれば送信側は、1つのメッセージ場合によっては発生する可能性のある複数の応答メッセージのコストを送信側が負担するか否かを選択することができ、これを個々の事例ごとにあてはめて選択することもできる。本発明の実施形態によれば送信側に対しサービスプロバイダから、応答コスト負担に関して送信側がどのようなコストを見込めるのか、たとえば最低限のコストであるのか最大限のコストであるのかが通知される。この値はサービスプロバイダにおいて計算することができ、たとえばどれぐらいの数の受信側にデータが伝送されるのかに依存させることができる。殊に有利には、コストをいっしょに負担してもらうために応答を行わなければならない期間をデータ送信側によって決めることができる。これによりデータ送信側は発生する可能性のあるコストを所期のように制限することができ、その際、個々の受信側にとって個々の応答がコスト負担によってまかなわれているか否かについてはっきりしない事態が生じてしまうことがない。また、同じ目標設定によって個々の受信側の応答回数を制限することもできる。データ送信側は想定される受信側をグループ分けし、それらのグループごとに応答コスト負担に関する特定のパラメータを割り当てるようにすれば、コスト制御をきわめて効果的に行うことができるようになる。このようにすればたとえば、固定客を新規の取引先とは別のコスト負担条件にすることができ、たとえば固定客に対しては無料応答期間を長くすることができる。以上のことから本発明によれば送信側によって、受信側のリアクションに対し緻密にコントロール可能でありそれゆえたとえばTEDアンケートや電話によるマーケッティングを介した販売などのような大量伝送のためにも適したコスト負担を実現することができる。本発明のその他の利点や特徴は図面ならびに以下で説明する本発明の実施例に示されている。実施例では本発明をWAP標準のためのデータ伝送スキーマ1に適用するものとして説明する。これはたとえばUMTSUniversalmobiletelecommunicationstandardにおける特別な画像データおよびフォーマット化されたテキストデータの伝送において使用されるようなものである。当然ながら、本発明を他の標準にも適用することができる。UMTS標準においては従来のSMSShortMessageServiceに加えて、口で話されていないメッセージの伝送のためにいわゆるMMSMultimediaMessagingServiceも組み入れられるように計画されている。これによりフォーマット化されたテキストデータと画像も伝送することができる。SMSにおいて定められている160文字のメッセージ長までの制約がもはやなくなる。オーディオおよびビデオメッセージの伝送も可能である。MMSはWAPの利用を介して実現できる。それによればデータたとえばマルチメディアメッセージMultimediaMessage=MMsの無線伝送に対して、図1では一方の側のデータ伝送に関して図2では応答送付も加えて描かれているプロトコルスキーマWAPWSP:WirelessSessionProtocolが使用される。このプロトコルスキーマはデータ送信側のレベル2MMSユーザエージェントA、プロバイダのレベル3MMSリレーおよび受信側のレベル4MMSユーザエージェントBを有している。データ送信側のレベル2は少なくとも1つの通信装置5を有しており、同様に受信側のレベル4は通信装置6を有している。これらの通信装置5,6はたとえば通常の携帯電話としてまたはたとえばラップトップコンピュータのように別の入力機能や表示機能を備えた機器として構成することができる。送信側の通信装置5において作成されたまたはこの通信装置を経由して転送可能なデータセット7はまずはじめ、送付物9としてこれはWAPプロトコルではMSendreqと呼ばれ、その構成を本発明による拡張を加えないかたちで図3に示すプロバイダーレベル3へ送られる。到来した送付物に対し返送10によってこれはWAPプロトコルではMSendconfと呼ばれ従来の構成について図5に示すプロバイダからの確認応答が送信側レベル4に送られる。時間的にこれに続いてプロバイダ3から情報11MNotificationind、図7に示すが受信側レベル4に送信され、これによって受信側に対し自身宛にダウンロードすべくメッセージがプロバイダ3のところに用意されていることが通知される。これについてプロバイダ3はたとえば自動的に確認応答返送12MNotifyRespreqを受信側レベル4の通信装置6から受け取る。送付物13WSPGETreqによる受信側からの要求に対してはじめて、プロバイダ3から送付物14MRetrieveconf、図9参照を伴うデータセット7が受信側レベル4に転送される。送付物9,10,11,12,14を管理するためいわゆるヘッダフィールドが用いられ、つまり本来のデータセット7の前にフィールドが配置されており、このフィールド内に出所、送信時間、ファイルサイズおよび他の詳細な項目が含まれている。本発明によればヘッダフィールドの数が増やされている。その目的は少なくとも1つの別のフィールドを情報および制御フィールドとして利用できるようにし、その中に受信側4から出所データ送信側2へ戻される応答の返送図2参照のコストを負担する用意のあることを示すコスト信号を取り込めるようにするためである。実施例ではそのために参照符号17,18,19,20で表されたヘッダフィールド0x1B~0x1Eが割り当てられている図12。フィールド0x1C~0x1Eには、それぞれ受信側グループに整合された様々なコストの負担後述の説明を参照に関する情報が含まれている。また、フィールド0x1Bには応答に対する識別信号が含まれており、これにより応答を事前に取得したデータセット7に割り当てることができるようになる。参照符号22で示したフィールド0x1Aには予期されるコストに関する情報が含まれている後述の説明を参照。送信側レベル2は通信装置5のところで、ハードウェア側の処理またはたとえばソフトウェア側の処理でいずれにせよ設けられているキーボードを介して扱うことのできるスイッチまたは同様の入力手段16を操作して、1つまたは複数の応答に対するコストの負担を設定することができる。これに対する代案として、たとえばデータ発送前に更新可能なサービスプロバイダ3との取り決めによってもその設定を行うことができる。サービスプロバイダ3との特別な継続的取り決めを行わなくても、データ7の伝送を要求する問い合わせMSendreqにおいて、送信すべきデータの応答コストが負担されるという情報および場合によってはどの程度まで負担を請け負うかについての情報を、送信側2からサービスプロバイダ3へいっしょに伝送することができる。この目的でヘッダフィールド17,18,19,20が新たに問い合わせ9に収容されており図4、これによってヘッダフィールドの数が従来技術図3よりも増えている。フィールド17,18,19はたとえば0x1B、0x1C、0x1D10進数の29,29,30でアドレッシングされ、フィールド名XMmsRFFToAmoutXMmsRFFCcAmoutXMmsRFFBccAmoutが付けられているが、これらのフィールドにはそれぞれ整数の変数が格納されている図11。これによって受信側の3つのグループすなわちToグループ直接の受信側、Ccグループcarboncopy:その他の受信側について知らされるかたちでいっしょに読むおよびBccグループblindcarboncopy:他の受信側について知らされずにいっしょに読むのために、これらグループにおける各々の受信側4からのこの種の応答メッセージの個数が定義され、それらに対し出所送信側2はコストを負担する。これらの値を種々のグループについて互いに異ならせることができ、それによって上述の利点が得られることになる。なお、コストの負担された応答だけの設定も可能である。整数の変数がたとえばオクテットから成る場合、最大で256この任意の応答が可能である。ここで示したグループ設定の代わりに他の設定または任意の設定も可能である。さらにそれ自体既存のフィールド21XMmsExpiryを以下のように補うこともできる。すなわち、そこに与えられているプロバイダ3のサーバ内での最大記憶時間をここではコスト負担に対する最大期間デッドラインとして定義することもでき、つまりこの期間経過後に送信されるこの種の応答はもはや出所データ送信側2によっても支払う必要がなくなる。フィールド20により応答を再認識するための識別信号が与えられており、それによってこの応答を適正なデータセット7に割り当てることができ、このようにすることであとになって出所送信側2に到来するメッセージすべてをReplyforfreeという分類で受け取ることがなくなり、つまりその送信側にとってコスト負担の義務を伴って受け取られるようになる。なお、ここで示したフィールドのほかにも別のフィールドを設けることもでき、たとえば応答コストが出所データの送信側2によって完全には負担されないときにはコストの一部分を与えるようなフィールドも考えられる。また、フィールド21に格納されている期間が経過するまではコストを完全に負担し、その後は一部分だけをあるいは最高限度までを負担するように設定することもできる。さらにまた、コストを負担する応答のタイプを選択することも可能であり、たとえばテキストメッセージに対してのみ負担するが画像データやオーディオデータについては負担しないというようにすることができる。サービスプロバイダ3はその応答確認メッセージ10MSendconf:図5、本発明による拡張:図6において自身の準備態勢すなわち送信側2によるコストの負担を完全にまたは部分的に受け入れることができ、そのためにこのメッセージ10内に含まれているフィールド17,18,19も個々のグループについて、完全な受け入れであれば送信側2により提案された値にセットし、部分的な受け入れであればそれよりも小さい値にセットする。図示されていないがさらに応答確認メッセージ10はたとえば0x1A10進数の26によりアドレッシングされるフィールド22を有することができ、このフィールド中にはサービスプロバイダレベル3によって作成された予期されるコストの上昇に関する情報が格納されている。この情報は許可された応答の個数および設定された期間に依存する。また、応答中に許可されるべきデータ型との依存性も生じる可能性がある。サービスプロバイダ3は送信側2により要求されたコストの負担を了承したときには、受信側4に向けた送付物11MNotificationind:図8においてフィールド17,18,19を送信側2により設定された値のままにしておき、アドレッシングすべき受信側のグループに従って1つまたは複数の受信側4にこれを通知する。これにより受信側は、自身に対しダウンロードすべきデータセット7が用意されているというメッセージを受け取り、このメッセージに対し受信側は特定のやり方でまたは特定の期間内に所定数の応答を、コストを負担することなく出所送信側2へ返送することができる。この情報をたとえばディスプレイなどの表示手段15を介して視覚的にまたは聴覚的に受信側に通知することができる。0x1B10進数の27でアドレッシングされフィールド名XMmsReplyIDをもつフィールド20内の識別信号は1つの応答の中にしか含まれておらず、このようにすることで本来のデータセットに対する対応づけのために一義的な識別信号ID2を実現することができる。本来のメッセージ7はすでに従来技術によれば別のヘッダフィールドによりそのID1によって一義的に識別されているので、補助フィールド20は不要である。ダウンロードすべくデータセット7が用意されているという送付物11の通知後に受信側4は、データセット7をサービスプロバイダのレベル3から自身の受信レベル4へとつまり通信装置6の記憶装置へとダウンロードする意志があるか否かを決定することができる。受信側がそれに了解すると決定したならば、受信側はプロバイダにメッセージ13WSPGETreqを返送する。これによりサービスプロバイダ3において受信側4へのデータ伝送MRetrieveconfが始められる。了解すると決定しなければデータセット7のダウンロード受信側4への送付物14の伝送は開始されない。また、受信側4があとの時点ではじめてメッセージを伝達してもらいたいという状況もあり得る。この場合、送付物14をメッセージ11と同様に新たに挿入されたフィールド17,18,19内に収容することができる図10。このようにすることで、無料の応答に関するコスト情報は送付物が用意されているということが通知されるときだけでなくデータセット7の配送時にもいっしょに供給され、このようにすることでそれを記憶したりまたはたとえばプリントしたりすることができる。対応づけのためのフィールド20はやはり1つの応答の中にしか含まれていない。それというのもデータセット7はすでに一義的に識別されているからであるID1。本発明によればこのようにしてたとえば、注文を出そうとする顧客からそのためのコストの負担を取り除くことができる。また、たとえば親が子に対し、要求された応答に対し子供が支払わなくて済むようメッセージを伝送することもできる。このことが殊に重要になるのは、たとえば金額が減ってしまうカードにより通知をじかに支払わなければならないときである。このようにすれば残額が僅かなカードであってもReplyforfree方式でのデータ7の応答が依然として可能となる。上述のように応答メッセージ図2内に付加的にフィールド20が収容されており、このフィールドは0x1B10進数の27でアドレッシングされ、フィールド名XMmsReplyIDをもっている。この中に格納されている識別情報ID2を、それがコストの負担の取り除かれた応答であるならば、伝送されるデータ7の識別信号ID1と一致させることができ、その結果、伝送されるデータ7と返送される応答とが同一の識別信号をもつことになり、そのことからそれら相互間の適正な対応づけが明確になる。さらに同様にこの応答を、1つまたは複数の応答のためのコスト負担情報がメッセージ11Mnotifyind内および/またはメッセージ14Mretrieveconf内に含まれていたか否かとは無関係に表すことができる。上述の方法を、個々の通信標準を稼働させるソフトウェアたとえばUMTSに組み込むことができる。この場合、通信装置5,6にそれに相応するソフトウェアが設けられる。したがってアカウントモデルReplyForFreeを置き換えることができるようにする目的で、MMAリレー3は以下の処理ステップを実行することができる:a個々の受信側グループに対する無料の応答MMsの個数が符号化されているWAPメッセージ9MSendreqのヘッダフィールドから、WAPメッセージ11MNotificationindと14MRetrieveconfに対し種々の受信側グループのために必要とされるフィールド値を読み出し、サービスプロバイダ3の設定に応じて修正または操作する必要がある。b送られたデータ7の識別信号ID7と応答の識別信号ID2が互いに異なっている場合、MMSリレー3はそれを互いに一義的にマッピングしてフィールド20XMMSReplyIDをそれに応じて監視または修正できなければならない。c受信側4MMSユーザエージェントBからMMSリレー3へWAPメッセージ23MSendreqを用いて応答が送信された後、これを個々の識別信号に基づき、応答マルチメディアメッセージMMBが本当に伝送データ7MMAに対する応答であるか否か、およびセットされた期間が守られていたか否かを検査する必要がある。次に、WAPメッセージにおいて利用されるヘッダフィールドについて詳しく説明する。ここでは一例として以下のシナリオを採用することにする:MMSユーザエージェントA送信側2はテキストおよびJPEG画像を有するMMA7を3つの受信側4へ送信する1つのTo受信側および2つのCc受信側。To受信側グループにおいては送信側2は3つの応答MMsMultimediaメッセージのためのコストを負担するつもりであるのに対し、受信側グループCcにおいては2つの応答MMsのためのコストだけしか負担しないつもりである。しかしMMsサービスプロバイダ3は、Cc受信側のために1つの無料の応答MMだけしか許可しない。コスト負担のためにまず最初に1時間=3600秒が設定される。メッセージ9:MSendreqMMSユーザエージェントA→MMSリレー3:andreasschmidsalsiemensdeというアドレスをもつ送信側2MMSユーザエージェントAはjoseflaumensalsiemensdeというアドレスをもつ受信側4MMSユーザエージェントBへMMA7を送信し、これはテキストMIMEcontenttypeplaintextとJPEG画像MIMEcontenttypeimagejpegとによって構成されている。このMMA7のカーボンコピーcarboncopyCcはさらに別の受信側4のところへ向かい、これはgunnarschmidtsalsiemensdeというアドレスをもつユーザである。さらに2つの別のブラインドカーボンコピーが、さらに別の受信側4としてBccに記載されたMMSユーザに伝送されることになる。WAPメッセージ9MSendreqにはたとえばトランザクションID10が含まれている。送信側は、アドレスjoseflaumensalsiemensdeをもつユーザMMSユーザエージェントB、Toフィールドからの3つの応答MMsにかかるコストを負担する用意がある。さらに送信側は、ユーザgunnarschmidtsalsiemensdeCcフィールドからの2つの応答MMsと、他の2つの両方のBcc受信側からのそれぞれ1つの応答MMにかかるコストの負担も望んでいる。これらの情報はグレーでハイライト表示されたフィールド17XMmsRFFToAmount、18XMmsRFFCcAmountおよび19XMmsRFFBccAmountに含まれている。MMAのコストの保証された応答に対する期間3600秒はフィールド21XMmsExpiryに書き込まれている。これに応じて送信側2は以下のように変更されたメッセージ10MSendconfをMMSリレー3から受け取る:メッセージ10:MSendconfMMSリレー→MMSユーザエージェントA:MMSリレー3はこのメッセージ10によって、WAPメッセージ9がエラーなくMMSリレー3に伝送されたことを確認応答する。この場合、識別信号がトランザクションIDとして使用され、その目的は送信側2においてメッセージ10をそれに属するMSendreq9に、つまりは送信されたMMA7に一義的に対応づけることにある。この例ではMMSリレー3はMMA7に識別信号AAAA1111msrelaysiemensdeを対応づけている。これはフィールド20に書き込まれており、従来技術のID1に対応する。メッセージ10においてフィールド17XMmsRFFToAmount、18XMmsRFFCcAmountおよび19XMmsRFFBccAmountは上述のように、サービスプロバイダ3がこれらのサービスをサポートして送信側2の要求を受け入れるか否かの情報を有している。これは図示の例ではTo受信側の複数の応答MMsについてのみ該当する。Cc受信側の場合には出所送信側2によりコストの負担される2つの応答が要求されていたが、サービスプロバイダ3は1つだけしか許可せず、その理由はたとえば送信側2が十分に支払い能力のある顧客であるとみなされていないからである。2つのBcc受信側の場合にはコストの負担される1つの応答が要求されていたが、サービスプロバイダ3はまったく許可しない。この例ではフィールドXMmsChargingAmountによって、MMA7の送信側に対しその送付および返送される応答MMsにかかる可能性のあるコストが示されている。メッセージ11:MNotificationindMMSリレー3→MMSユーザエージェントB4:この例では4つの受信側4の各々に対し1つの通知が存在し、すなわちTo受信側への通知とそれぞれCc受信側と2つのBcc受信側への通知である。これらの各々には固有のトランザクションIDが含まれている。期間に関する情報はフィールド21XMmsExpiry内のすべてに存在し、MMA7のメモリロケーションに関する情報はフィールドXMmscontentLocation内のすべてに存在する。aメッセージ11:To受信側へのMNotificationind:To受信側4はフィールド17XMmsRFFToAmount内のエントリに従い、自身にとって3つの応答MMsは無料であることを知る。bメッセージ11:Cc受信側へのMNotificationind:Cc受信側はフィールド18XMmsRFFCcAmount内のエントリを介して、自身にとって応答MMが無料であることを知る。cメッセージ11:Bcc受信側2へのMNotificationind:Bcc受信側へのMNotificationindここではたとえばこのグループのうち第2の受信側4のためのものであるが、これは従来技術に対し変更されていない。それというのもサービスプロバイダ3は、Bcc受信側のそれぞれ1つの応答についてコストを負担するという送信側2の要求を拒否したからである。MMA7のダウンロードはWSPGET命令13により始められる。これに応じてデータ7がMMSリレー3からメッセージ14MRetrieveconfにおいて個々の受信側4へ送られる。以下ではTo受信側についてのみ考察する。メッセージ14:MRetrieveconfMMSリレー3→MMSユーザエージェントB4:たとえばこのデータ7の受取側4が第2のサービスプロバイダに属する場合、MMA7は別のメッセージIDをもつ可能性がある。これはこの例においては、値BBBB2222boschmmsdeがメッセージIDフィールドに書き込まれていることで考慮されている。やはりメッセージ11MnNotificationindのようにTo受信側はフィールドXMmsRFFToAmount内のエントリを介して、自身にとって3つの応答MMsが無料であることを知る。従来技術によれば、メッセージIDフィールドの存在はWAPメッセージ14内ではオプションである。しかしフィールド17XMmsRFFToAmount、18XMmsRFFCcAmountまたは19XMmsRFFBccAmountが存在していて占有されているときには、Replyforfreeの機能を実現するためにこのフィールドが設けられていなければならない。ついでMMA7のTo受信側4は応答MM,MMBを出所送信側2へ送り戻す。この目的で僅かに変更されたMSendreq23が用いられる図2。この例では3つの可能な/前払いされた応答前述の説明を参照のうち第1の応答が送信されることになる。メッセージ23:MSendreqMMSユーザエージェントB→MMSリレー:出所受信側4MMSユーザエージェントBは新しいフィールド20XMmsReplyIDの存在に関して、このMMBは別のMMに対する応答を表すことを通知する。この応答がどのMMに関連するかは、フィールド20XMmsReplyIDのフィールドエントリBBBB2222boschmmsdeにおいて規定される。このエントリはMMAのメッセージIDであり、MMSユーザエージェントBに対しMMA7のダウンロードのときにメッセージ14としてこれが通知される。MMSユーザエージェントBの送信問い合わせ23MSendreqに対しMMSリレー3からメッセージ24MSendconfにより確認応答が行われる。これは以下のように変更されている:メッセージ24:MSendconfMMSリレー→MMSユーザエージェントB:エントリXMmsRFFToAmountによりMMSリレー3はMMSユーザエージェントBに対し、同じMMA7のためにコストの保証されたさらに2つの応答を送信可能なことを通知することができる。ついでMMSリレー3はMMBの受信側すなわちMMA7の出所送信側2に対し、WAPメッセージ25MNotificationindを用いて通知を行う:メッセージ25:MNotificationindMMSリレー3→MMSユーザエージェントA2:このMNotificationind25を変更した目的は、目下のMMが応答MMを表しておりどのMMA7にその応答が関連するかをMMSユーザエージェントAに通知するためである。そのためこの応答においてMNotificationind25中にフィールド20XMmsReplyIDが挿入される。この場合、フィールドエントリはこの応答MMBに関連するMMA7のメッセージID1とすべきであって、ここではAAAA1111mmsrelaysiemensdeである。ここで重要となるのはやはり以下のことである。すなわちサービスプロバイダ3MMSリレーは、ID1とID2とが互いに異なっているときにID2をID1へマッピングできなければならず、その理由はMMSユーザAはID1しか知らないのに対しMMSユーザエージェントBはID2しか知らないからである。フィールド20XMMSReplyIDの内容は、2回とも同じMMBが識別されるにもかかわらず、送信23MSendreqと25MNotificationindとで異ならせてもよく、この例でもそうである。ついでこの通知の適正な受信が再びWAPメッセージMNotifyRespreqによって確認応答され、これはMNotificationindの対応するトランザクションIDがステータスメッセージとともにMMSリレー3に返送されることで行われる。やはりWSPGET命令により、MMSユーザエージェントAによるMMBのダウンロードが始められる。それに応じてMMBはMMSリレー3からMRetrieveconfメッセージ27においてMMSユーザエージェントAに送信される:メッセージ27:MRetrieveconfMMSリレー→MMSユーザエージェントA:Mretrieveconf27も変更されるがその目的はMMSユーザエージェントAに対し、目下のMMBが応答MMを成しどのMMにこの応答が関連するのかを通知するためである。そのためフィールド20XMmsReplyIDがMNotificationindに挿入される。フィールドエントリは、この応答MMBが関連するMMAのメッセージID1とすべきである。1つの実施形態によれば移動無線ネットワークにおけるデータ伝送コストのアカウント方法において、伝送コストのための少なくとも1つの識別信号がデータに割り当てられ、この識別信号がデータの受信側および/または送信側へ伝送される。この場合、たとえばメッセージの送信側および/または個々の受信側にまえもって与えられていたWAPWirelessApplicationProtocolメッセージなどのようなデータ識別信号に対する応答について送信側により規定された期限を伝達するために、このデータ識別信号中では新たなヘッダフィールドは利用されない。その代わりに本発明によれば、この種の期限たとえば受信側が自身をアドレス指定しているマルチメディアメッセージに対し応答できる期限を伝達するために、既存のヘッダフィールドXMMSExpiryを利用することができる。このヘッダフィールドはすでにWAP209MMSEncapsulationRelease2000WirelessApplicationProtocolWAPMultimediaMessagingServiceMessageEncapsulationMMSProposedSCD10に記載されている。送信側により設定可能な応答期限もしくはリアクション期限は本発明によれば、たとえばWAPメッセージMSendreqMNotificationindMRetrieveconfのところに挿入されている。したがってすでに実装済みのヘッダフィールド中にコーディングされているマルチメディアメッセージの有効期限が同時に、マルチメディアメッセージの受信側がそれに対し無料で応答可能な期限も意味する。個々のデータ識別信号に割り当てられている既存のヘッダフィールドをこのように利用するのは格別効率的であるし目的に適っている。とはいうものの既存のヘッダフィールドが別のデータセットにより事前に占有されているならば、送信側により設定された期限の伝達にあたり問題が生じる可能性がある。この問題は有利には、個々の識別信号に少なくとも1つのヘッダフィールドを付加的に追加し、そのヘッダフィールド中に識別信号に対する応答期限をセットすることにより解決される。このようにして、伝達されたデータ識別信号に対しそのつどセットされた応答期限を多くの実際の状況のもとで信頼性を伴って簡単に伝送できるようになる。つまり択一的に、個々のデータ識別信号において送信側により設定された期限を伝達するために少なくとも1つの新しいヘッダフィールドが挿入される。たとえばWAPメッセージMSendreqMNotificationindMRetrieveconfはそれぞれ少なくとも1つの別のヘッダフィールド分だけ補われる。これにはたとえばXMmsReplydeadlineという名前を付けることができる。好適にはそれらに対し16進数の符号0x1F10進数の127が割り当てられる。このヘッダフィールドのフィールド値は有利にはWAP209MMSEncapsulationRelease2000WirelessApplicationProtocolWAPMultimediaMessagingServiceMessageEncapsulationsMMSProposedSCD10およびWAP203WSPVersion452000WirelessApplicationProtocolWirelessSessionProtocolSpecificationChapter84HeaderEncodingに従い符号化される。このようにして期限に対し明示的な日付または特定の期間を与えることができる。有利にはこの種の付加的なヘッダフィールドは以下の区分を有する:さらに応答マルチメディアメッセージの送信側は事前に得られたマルチメディアメッセージに対する自身の応答を、選択されたアカウントモデルたとえばリプライチャージReplychargingとは無関係に応答として表すこともできる。この目的で、ヘッダフィールドXMMSReplyIDと同様の少なくとも別のヘッダフィールドを挿入するのも好適であり、応答の行われるオリジナルマルチメディアメッセージのメッセージIDをそのフィールドに書き込むことができる。"