JP2004526352A

JP2004526352A - メッセージのアクセス方法および該方法に対応する方法ならびにソフトウェアプログラム

Info

Publication number: JP2004526352A
Application number: JP2002563667A
Authority: JP
Inventors: トラウベルクマルクス; アンドレアス　シュミット; ヨーゼフ　ラウメン; イェルビベルハッセン; ファンニーケルクザビーネ
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2001-02-02
Filing date: 2002-01-21
Publication date: 2004-08-26
Also published as: WO2002063839A2; US20030086438A1; DE10104713A1; WO2002063839A3; EP1356645A2

Abstract

本発明は、第１のメッセージたとえば移動無線システムおよび／またはインターネットを利用して送信された第１のメッセージたとえばＭＭＳタイプのマルチメディアメッセージを、時間的にこの第１のメッセージのあとに送信された第２のメッセージを使って操作できるようにした方法たとえば呼戻または置換ができるようにした方法に関する。これによってこの種のシステムのユーザにとっていっそうユーザフレンドリーなシステムが得られる。この場合、このような第１のメッセージを条件付きで操作するオプションが提供される。さらに本発明によれば、この方法に適した通信装置、ネットワークエレメントおよびソフトウェアプログラムが提供される。

Description

【技術分野】
【０００１】
本発明は、第１のメッセージへのアクセス方法、有利にはＭＭＳ形式のマルチメディアメッセージへのアクセス方法に関するものであり、ここで第１のメッセージは送信アプリケーションまたはＶＡＳアプリケーションによって受信アプリケーションに送信される。
【０００２】
さらに本発明は、相応する遠隔通信装置、ネットワークエレメント、並びにソフトウエアプログラムに関する。
【０００３】
移動無線システムＧＳＭ（ＧＳＭ−Global System for Mobile Communication ）は音声電話の他に、１６０文字長までのショートテキストメッセージを送信ないし受信できる。このサービスはＳＭＳ（ＳＭＳ−Short Message Service）と称される。ＧＳＭ０３．４０バージョン７．４．０、リリース１９９８年；デジタルセルラー通信システム；ショートメッセージサービス（ＳＭＳ）の技術的実現を参照のこと。
【０００４】
次世代のＵＭＴＳ移動無線システム（ＵＭＴＳ−Universal Mobile Telecommunication System）に対しては現在のところ、移動メッセージサービスのマルチメディア機能バリエーションが標準化されている。これはいわゆるＭＭＳ（ＭＭＳ−Multimedia Messaging Service）である。３ＧＴＳ２２．１４０バージョン４．０．１、リリース２０００年；第３世代パートナーシッププロジェクト；グループサービスおよびシステムアスペクト技術的仕様；サービスアスペクト；ステージ１；マルチメディアメッセージングサービス（ＭＭＳ）参照のこと。マルチメディアコンテンツを有するメッセージを以下、ＳＭＳのテキストメッセージから区別するために略してＭＭｓと称する（ＭＭ−Multimedia Message；複数：ＭＭｓ）。ＳＭＳとは異なり、純粋なテキスト内容に制限されることはない。ＭＭＳではテキストを個人の好みに応じてフォーマットし、オーディオおよびビデオコンテンツをメッセージに埋め込むことができる。さらなる新規性は、ＭＭｓの配信の際に、いわゆるプッシュモード（到来するＭＭを遅延なしで受信側に配信する）といわゆるプルモード（受信側にはまず新たに到来したＭＭについて通知され、これに基づいていつこのＭＭを自分の受信器にダウンロードするかを自分で決定できる）との区別することができることである。この公知の関係が図１に示されており、参照符号１２によりＭＭＳサーバとして示されたネットワークエレメントが、参照符号１１によりＵＭＴＳターミナルが示されている。
【０００５】
これまでの従来技術によれば、ＭＭＳはＷＡＰ（ＷＡＰ−Wireless Application Protocol）を介してのみ実現可能である。ＭＭＳに適した端末機とＷＡＰゲートウエイとの間のエアインタフェースをブリッジオーバするために、ＷＡＰの使用がＷＳＰに規定されている（ＷＳＰ−Wireless Session Protocol）。WAP-203-WSP、バージョン４−５月２０００年；ワイヤレスアプリケーションプロトコル、ワイヤレスセッションプロトコル仕様；チャプター８．４：“Header Encoding”参照。３ＧＴＳ２２．１４０バージョン４．０．１（ｓ．ｏ．）；３ＧＴＳ２３．１４０バージョン４．０．０、リリース４，第３世代パートナーシッププロジェクト、グループターミナル技術的仕様、マルチメディアメッセージングサービス（ＭＭＳ）、機能的ディスクリプション、ステージ２参照。
【０００６】
図２は、３ＧＴＳ２３．１４０バージョン４．０．０（上記参照）による現在の従来技術によるいわゆるトランザクションフローチャートを示す。ここには関与する３つの実体間でのＷＡＰメッセージ交換がＭＭの送信と受信の場合で示されている。３つの実体とは、送信アプリケーションＵＡＡ（ＵＡＡはＭＭＳユーザエージェントＡに対する省略）、ネットワークエレメントＲＳ（ＲＳはＭＭＳリレー／サーバの省略）、および受信アプリケーションＵＡＢ（ＵＡＢはＭＭＳユーザエージェントＢに対する省略）である。ＭＭＳユーザエージェントとは、移動無線機または移動無線機に接続された機器（例えばラップトップ等）上でＭＭＳを実現するアプリケーションである。ＭＭＳリレー／サーバは、該当領域ないしＭＭＳサービスプロバイダのＭＭＳ環境にあるネットワークエレメントであり、このサービスプロバイダはアプリケーション「ＭＭＳユーザエージェント」に対してＭＭＳ機能性を提供する。
【０００７】
以下、図２の公知のトランザクションフローチャート（送信アプリケーションＵＡＡがＭＭ_Ａを受信アプリケーションＵＡＢに送信する）に基づき、ＷＡＰメッセージの交換について説明する。ここではまず単純に、送信アプリケーションＵＡＡ１と受信アプリケーションＵＡＢ１２が同じＭＭＳサービスプロバイダのＭＭＳを供給することを前提にする。送信アプリケーションＵＡＡ１で形成されたＭＭ_ＡはＷＡＰメッセージM-Send.reqによりネットワークエレメントＲＳ２，１２に送信される（このネットワークエレメントは送信側でも受信側でも機能を引き受けるので、二重参照符号２，１２により示されている）。これに基づき受信アプリケーションＵＡＡ１はＷＡＰメッセージM-Send.confを受信する。このＷＡＰメッセージM-Send.confによりＭＭ_ＡがネットワークエレメントＲＳ２，１２により正しく受信されたことが確認される。このメッセージには、ネットワークエレメントＲＳ２，１２により設定された、送信されるＭＭ_Ａに対する個別の識別番号ＩＤ１を含むことができる。その後、ネットワークエレメントＲＳ２，１２は受信アプリケーションＵＡＢ１１に対して、ＷＡＰメッセージM-Notification.indにより新たに到来し、ダウンロードの準備のできたＭＭ_Ａのメモリスペース（ＵＲＩ−Uniform Resource Identifirer；以下ＵＲＩと略す）について情報通知する。これに基づきネットワークエレメントＲＳ２，１２は例えばＷＡＰメッセージM-NotifyResp.reqにより、該当するＭＭ_Ａについての通知（M-Notification.ind）が成功裏に送信されたことの確認を受け取る。この時点でネットワークエレメントＲＳ２，１２はまだダインロード準備のできたＭＭに対するメッセージＩＤで予約されていない。２つのＷＡＰメッセージM-Notification.indとM-NotifyResp.reqの交換の際には、このメッセージに対するただ１つの個別トランザクション識別番号（トランザクションＩＤ）が交換される。次に受信アプリケーションＵＡＢはＷＡＰメッセージＷＳＰＧＥＴ（これによりＵＲＩはネットワークエレメントＲＳ２，１２に送信される）を用いてＭＭ_Ａの配信を要求する。ＷＡＰメッセージM-Retrieve.confにより受信アプリケーションＵＡＢ１１はこれに基づいてネットワークエレメントＲＳ２，１２により所望されるメッセージＭＭ_Ａを配送する。ここでＭＭ_ＡはネットワークエレメントＲＳ２，１２により設定された個別の識別番号ＩＤ２により識別される。ＷＡＰメッセージM-Acknowledge.indによりＭＭ_Ａが受信アプリケーションＵＡＢ１１によって正しく受信されたことが受領確認される。送信側が自分の送信したＭＭ_Ａが成功裏に受信されたことを通知して欲しいと表明した場合に対しては、ネットワークエレメントＲＳ２，１２はこれに対して、ＷＡＰメッセージM-Delivery.indを受信アプリケーションＵＡＢ１１に送信することで応じることができる。
【０００８】
図３は、公知の可能なＭＭＳアーキテクチャを示す。ここではＭＭ交換に関与する送信アプリケーションＵＡＡ１と受信アプリケーションＵＡＢ１１が、種々異なるＭＭＳサービスプロバイダ（ＭＭＳサービスプロバイダＡとＭＭＳサービスプロバイダＢ）からのＭＭＳを要求する。この場合、関与するＭＭＳサービスプロバイダのＭＭＳＥｓ（ＭＭＳＥ−Multimedia Messaging Service Environment＝マルチメディアメッセージングサービス環境）間でＭＭをさらに転送する必要がある。参照符号４はＭＭＳサービスプロバイダＡのＭＭＳＥを表わし、参照符号１４はサービスプロバイダＢのＭＭＳＥを表わす。ＭＭを２つのＭＭＳＥｓ間でさらに転送すること、正確に言えば送信側ネットワークエレメントＲＳＡ２（ＲＳＡはＭＭＳリレー／サーバＡに対する省略）と受信側ネットワークエレメントＲＳＢ１２（ＲＳＢはＭＭＳリレー／サーバＢに対する省略）との間で転送することは例えばＳＭＴＰ（ＳＭＴＰ−Simple Mail Transfer Protocol,３ＧＴＳ２３．１４０バージョン４．０．０（ｓ．ｏ．）参照のこと）を介してインターネット（ＩＰ−インターネットプロトコル、参照符号２０）により行われる。プロトコルＳＭＰＴは図３に参照符号２２により示されている。移動無線網は図３には一般的にＰＬＭＮ（ＰＬＭＮ−Public Land Mobile Network）として示されており、参照番号６が付されている。各ＭＭには編集の際にＭＭが早くても受信側に、正確に言えば受信アプリケーションＵＡＢ１１に配送されるべき時点を割当てることができる。これが使用されるならば、ＭＭは送信側ＭＭＳＥ_Ａ４に−正確に言うならば参照符号３の付されたＭＭＳサーバＡのメモリに−この期限に達するまで中間記憶される。Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in Sophia Antipolis, France 10-12 October 2000; T-doc:T2M00092; Chapter 7; 3GPP TSG-T2 SWG3 参照のこと。その後で初めてＭＭは受信側ＭＭＳＥ_Ｂ１４に送信される。さらに各ＭＭの編集の際に、所望の有効期限を指示することができる。ＭＭは有効期限の満了まで、ないしは受信アプリケーションＵＡＢ１１による先行のＭＭのダウンロードまで受信側ＭＭＳＥ_Ｂ１４（正確に言えば参照符号１３の付されたＭＭＳサーバＢのメモリ）に記憶される。Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 参照のこと。
【０００９】
同様に図３の公知のＭＭＳ基準アーキテクチャから分るように、ＭＭｓはアプリケーションＵＡＡないしＵＡＢから発するだけでなく、ＭＭＳＶＡＳアプリケーション（ＶＡＳ＝Value Added Services＝付加価値サービス）からも発することがある。このＶＡＳアプリケーションは図３に参照符号７により示されている。ここでこれは付加サービスを提供するネットワーク側の装置である。この場合、ＭＭ７インタフェースはＭＭＳＶＡＳアプリケーションとネットワークエレメントＲＳとの間の通信インタフェースとして用いられる。現在までこのインタフェースに対して義務的ＭＭＳ固有メッセージは定義されていない。ここでの通信はＨＴＴＰ（Hypertext Transport Protocol）またはＳＭＴＰに基づいて行うことができる。とりわけ標準化の現在の状態によれば、ＭＭ１に類似するコーディングをこのインタフェースに対して使用することができる。
【００１０】
冒頭に述べた方法と装置では、メッセージは送信側ないし委託者により処理することができる。ただし前記メッセージが送信アプリケーションＵＡＡに存在する場合である。メッセージが送信された場合には、それ以上の介入ないしアクセスを行うことができない。この問題は、メッセージを、無線を介して送信する場合だけでなく電子メール（Ｅメール）をインターネットおよび他の通信システム介して送信する場合にも当てはまる。
【００１１】
本発明の課題は、冒頭に述べた方法および装置を改善して、送信側／受信側の必要性をより指向した、メッセージの処理ないし介入を可能にすることである。
【００１２】
この課題は冒頭に述べた形式の方法において、第１のメッセージを操作するための操作ジョブを備える第２のメッセージを作成し、送信し、受信し、さらに転送および／または処理し、これにより第１のメッセージへの操作アクセスを許容または通知することにより解決される。
【００１３】
さらにこの課題は相応の通信装置において、請求項３５の構成によって解決される。相応の通信装置とは、とりわけ移動無線電話並びにインターネットと接続されたコンピュータを含む通信ユニットであると理解されたい。第２のメッセージを作成、送信、受信および／または処理するための本発明の手段は、例えば制御ユニットおよびプロセッサユニットのようなハードウエアユニットの他にソフトウエア解決手段を有している。このソフトウエア解決手段は、変更されたおよび／または新たに定義されたヘッドフィールドを備えるＷＡＰメッセージの有利な変形であり、これを処理することができる。このソフトウエア解決手段については以降で説明する。
【００１４】
とりわけ前記課題は相応のネットワークエレメントにおいて、請求項４６の構成によって解決される。本発明ではこの種のネットワークエレメントは通信システムの一部であり、複数の送受信ユニット間、とりわけ複数の移動電話間および／またはインターネットに接続されたコンピュータ間の通信を可能にする。このような通信システムは、無線通信システムも含めて、通常はサービスプロバイダにより運営される。第２のメッセージを受信、処理および／または転送するための本発明の手段は、例えば制御ユニットおよびプロセッサユニットのようなハードウエア素子の他にソフトウエアを含んでいる。このソフトウエアは、相応に適合されたまたは新たに定義されたヘッドフィールドを備えるＷＡＰメッセージの有利な変形であり、後で詳細に説明する。
【００１５】
本発明のメッセージは従来のＳＭＳ、マルチメディアコンテンツを有するＭＭ、またはその他の電子的メッセージとすることができる。以下、本発明をＭＭに基づいて説明するが、これによりこのメッセージ形式の制限されるものではない。第１のメッセージに対しては省略としてＭＭ_Ａを、第２のメッセージに対してはＭＭ_Ｂを以下で使用する。
【００１６】
本発明の利点は、第１のメッセージを送信後に操作できることであり、とりわけ呼戻、および／またはこれに対して後から変更ないし更新を行うことができることである。このような操作は本発明により、メッセージを移動無線システムを介して送信する際に、移動無線システム間で、とりわけインターネットオペレータＩＰバックボーンを介して移動無線網と他の通信システム間で、とりわけインターネットＥメールの場合はインターネットを介して可能である。
【００１７】
とりわけ本発明により、委託者から送信ユニットの送信アプリケーションによって少なくとも１つのネットワークエレメントを介して受信ユニットの受信アプリケーションへ送信された第１のメッセージ、とりわけＭＭＳ形式のマルチメディアメッセージを操作することができる。このとき、第１メッセージの送信後に操作情報を備える第２メッセージを送信ユニットから少なくとも１つのネットワークエレメントへ伝達する。このネットワークエレメントは、第１メッセージへの操作アクセスを許容または仲介する。
【００１８】
第１メッセージと第２メッセージは、サービスプロバイダの少なくとも１つの送信側ネットワークエレメントとサービスプロバイダの少なくとも１つの受信側ネットワークエレメントとを介して受信アプリケーションに送信される。ここで少なくとも１つの送信側ネットワークエレメントと少なくとも１つの受信側ネットワークエレメントとはただ１つのサービスプロバイダの管轄エリアに属するか、または最も簡単な場合は同じにすることができる。
【００１９】
受信アプリケーションと送信アプリケーションとが同じであることも可能である。
【００２０】
特に有利には、第１のメッセージ、送信側ネットワークエレメント、受信側ネットワークエレメント、および／または受信アプリケーションへ操作アクセスを行う。
【００２１】
受信アプリケーションがまだ操作ジョブについて情報通知されていなければ、第１のメッセージは有利には送信側サービスプロバイダまたは受信側サービスプロバイダの管轄領域で操作され、その際、有利には受信アプリケーションは操作について報告されない。これに対して第１のメッセージについての通知がすでに受信側で行われており、しかしこの第１のメッセージがまだダウンロードされていなければ、有利には第１のメッセージは送信側サービスプロバイダの管轄領域で、受信アプリケーションの情報なしで操作されるか、または操作は受信側サービスプロバイダの管轄領域で行われる。このとき有利には受信アプリケーションは操作およびその操作時点について情報通知される。
【００２２】
本発明による操作は、呼戻と変更という２つのサービスフィーチャに限定されるものではない。後からの転送ジョブ、第２のメッセージを第１のメッセージに後から添付することなども本発明の操作の意味に理解すべきである。以下、呼戻ジョブと変更ジョブについて詳細に説明する。
【００２３】
本発明の実施形態によれば、ＭＭの呼戻（本開示内では「リコール」と称する）は、少なくとも受信側がＭＭを別の順序に移動するか、他の受信側にさらに転送するか、または開封するまで常に可能である。
【００２４】
ＭＭの後からの変更（本開示内では「リプレース」と称する）は本発明の実施形態では、受信側がこのＭＭをすでに処理した場合でも可能である。この場合、受信側には折り返し相応のＭＭの後からの変更について情報通知される。これは通知（ノティフィケーション）により受信側が更新されたＭＭのダウンロードを後から自分で開始するか（プルモード）、または更新されたＭＭを自動的に同時に配信することにより行われる（プッシュモード）。
【００２５】
本発明の改善形態では、ＭＭの送信側、すなわち送信アプリケーション（ＭＭＳユーザエージェント）またはＭＭＳＶＡＳアプリケーションが以前に送信したＭＭを所定の条件の指示の下で再び呼び戻すか、または後から変更ないし更新を行うことができる。この送信側により選択可能な条件は第２のメッセージの情報エレメントに含むことができる。この条件は例えば、ダウンロード準備のできたＭＭについて受信側がまだ情報通知されていない場合だけのＭＭの呼戻、またはＭＭがすでに受信側の端末機器に配信されているが、まだ開封されていない場合だけ実行する変更ジョブである。これらのサービスフィーチャを以下、「条件付き呼戻（条件付きリコールまたは条件付きキャンセル）ないしは「条件付き変更」（条件付きリプレース）と称する。概念「変更」ないし「リプレース」とは置換と理解すべきであるが、変更のその他の形式でも良い。本発明の情報エレメントは、相応に補足されるかまたは新たに定義された、ＷＡＰメッセージ内にあるヘッドフィールドである。
【００２６】
この本発明の利点は、以前に送信されたＭＭの呼戻および／または置換をスケーラブルに、かつフレキシブルに実現できることである。このサービスフィーチャはマルチメディアメッセージサービスの魅力を高める。
【００２７】
メッセージ（ＭＭ）の送信側は、無条件の操作ジョブであっても、条件付きの操作ジョブであっても、送信アプリケーション「ＭＭＳユーザエージェント」またはＭＭＳＶＡＳアプリケーションとすることができる。このような送信アプリケーションは例えば移動端末機上のアプリケーションであり、ＭＭＳＶＡＳアプリケーションは付加価値サービスを提供するネットワーク側のアプリケーションである。
【００２８】
さらに本発明の対象は、ＷＡＰにおいて本発明の方法を、既存のヘッドフィールドの変更により、または新たに定義されたヘッドフィールドを、ＷＡＰ−ＭＭＳエンキャプスレーション規格の該当するＷＡＰメッセージに追加することにより実現することである。ＷＡＰ−２０９−ＭＭＳエンキャプスレーション、リリース２０００；ワイヤレス・アプリケーション・プロトコル；ＷＡＰマルチメディアメッセージングサービス；メッセージ・エンキャプスレーション；ＭＭＳプロポーズドＳＣＤ１．０参照。
【００２９】
同様に相応の２進符号化も本発明の対象である。これについては下の実施例でさらに説明する。
【００３０】
以下、本発明を実施例に基づき詳細に説明する。
図１は、従来技術のＵＭＴＳによるプルモードとプッシュモードを比較する図である。
図２は、従来技術によるマルチメディアメッセージサービス（ＭＭＳ）に対するトランザクション線図である。
図３は、従来技術によるマルチメディアメッセージサービスアーキテクチャの概略図である。
図４は、本発明による第１のメッセージの操作可能性を有するマルチメディアメッセージサービスを示す図である。
図５は、新たに定義されたヘッドフィールドの符号化を示す図である。
図６は、公知のヘッドフィールドでのＸ−Ｍｍｓステータスの補足を示す図である。
図７は、新たに挿入されたヘッドフィールド、Ｘ−Ｍｍｓ−オリジナルメッセージ・ステータスを示す図である。
図８は、新たに挿入されたヘッドフィールド、Ｘ−Ｍｍｓ−オリジナルメッセージＩＤを示す図である。
図９は、別に新たに定義されたヘッドフィールドの符号化を示す図である。
図１０は、ヘッドフィールド、Ｘ−Ｍｍｓ−サポートフィーチャでの補足を示す図である。
【００３１】
図４の上部を参照して、第１のメッセージＭＭ_Ａを、第１および第２のＭＭＳサービスプロバイダ（サービスプロバイダＡとサービスプロバイダＢ）の交換によって送信および受信する公知の経過を説明する。第１のメッセージＭＭ_Ａの送信後、送信側の送信アプリケーションＵＡＡ１にはＷＡＰメッセージ、M-send.confにおいて前に送信されたＭＭ_Ａに対するメッセージＩＤが通知される（ＩＤ１）。この識別番号ＩＤ１はサービスプロバイダＡのネットワークエレメントＲＳＡ２によって形成され、ＭＭ_Ａを送信側インタフェース、送信アプリケーションＵＡＡ１／ネットワークエレメントＲＳＡ２内で一義的に表わす。ＭＭ_ＡがサービスプロバイダＢのネットワークエレメントＲＳＢ１２から受信側アプリケーションＵＡＢ１１にＷＡＰメッセージ、M-Retrieve.confにより受信側で配送される際にも、同様にメッセージＩＤ（図２のＩＤ２）が通知される。この識別番号ＩＤ２は場合によってはネットワークエレメントＲＳＢ１２により新たに形成され、ＭＭ_Ａを受信側インタフェース、ネットワークエレメントＲＳＢ１２／受信アプリケーションＵＡＢ１１内で一義的に表わすのに用いられる。
【００３２】
ＭＭ_Ａを送信側ネットワークエレメントＲＳＡ２と受信側ネットワークエレメントＲＳＢ１２との間で伝送するために、ＩＤ１を仮の識別番号（ＩＤ３）に変換することができる。この仮の識別番号（ＩＤ３）はＭＭ_Ａを種々異なるシステム間で識別する（図４では、米印でマークされた個所がインタフェース間でのメッセージＩＤの変換を意味する）。とりわけこのＩＤ３はグローバルに一義的であるべきである。例えばＩＤ３は、サービスプロバイダＡ、ＩＤ１、並びにＩＤ変換の時点についての情報を含む。このために送信側ネットワークエレメントＲＳＡ２はこの変換を復元できる情報ないし手段を有していなければならない。これは例えば引き渡し通知のためである。内部で明瞭なＩＤを使用するために、ＩＤ３を受信側ネットワークエレメントＲＳＢ１２で上記の内部ＩＤ２に変換することができる。このＩＤ２はＭＭAを受信アプリケーションＵＡＢ１１に対して同定する。そのためには受信側ネットワークエレメントＲＳＢ１２も、この変換を復元できる情報ないし手段を有していなければならない。これは例えば引き渡し通知のためである。ＭＭ_Ａは受信側でＩＤ２により識別される。
【００３３】
本発明によれば、送信アプリケーション、受信アプリケーションおよび／または送信アプリケーションと受信アプリケーションとの間で検出されたネットワークエレメントにより、以前に送信された第１のメッセージＭＭ_Ａへアクセスすることができる。このアクセスは、第２のメッセージＭＭ_Ｂを作成し、この第２のメッセージが第１のメッセージＭＭ_Ａへの操作アクセスを許容するかまたは通知することにより行われる。
【００３４】
ＭＭ_Ｂの識別手段を図４に基づいて説明する。ここではＭＭBが識別番号ＩＤ４を有する。ＭＭ_Ｂを異なるサービスプロバイダシステム間で通知するために、ＩＤ４は送信側ネットワークエレメントＲＳＡ２により内部ＩＤ（ＩＤ６）に変換される。この内部ＩＤはＭＭ_Ｂをシステム間で識別する。とりわけＩＤ６がグローバルに一義的でなければならない場合、例えばサービスプロバイダＡ、ＩＤ４および変換の時点についての情報が含まれる。このために送信側ネットワークエレメントＲＳＡ２は、この変換を復元することのできる情報ないし手段を有していなければならない。これは例えば引き渡し通知のためである。内部で明瞭なＩＤを使用するために、ＩＤ６は受信側ネットワークエレメントＲＳＢ１２により内部ＩＤ（ＩＤ５）に変換される。この内部ＩＤはＭＭ_Ｂを受信アプリケーションＵＡＢ１１に対して同定する。このために受信側ネットワークエレメントＲＳＢ１２は、この変換を復元することのできる情報ないし手段を有していなければならない。これは例えば引き渡し通知のためである。ＭＭ_Ｂは受信側でＩＤ５により識別される。
【００３５】
ＭＭ_ＡとＭＭ_Ｂとの必要な接続を実現するために、ＩＤ４はＩＤ１に付いての参照を、ＩＤ６はＩＤ３についての参照を、そしてＩＤ５はＩＤ２についての参照を有する。受信アプリケーションＵＡＢ１１の報告はＭＭ_ＡとＭＭ_Ｂを介して２つのメモリスペースＵＲＩ１ないしＵＲＩ２を指示する。
【００３６】
識別番号ＩＤ１とＩＤ３，ＩＤ３とＩＤ２，並びにＩＤ１とＩＤ３は同じであっても良い。同じようにＩＤ４とＩＤ６，ＩＤ６とＩＤ５、並びにＩＤ４、ＩＤ５、ＩＤ６は同じであっても良い。
【００３７】
関与する送信側ネットワークエレメントの少なくとも１つおよび関与する受信側ネットワークエレメントの少なくとも１つは有利には、ＩＤの一義的かつ可逆的な変換を行い、それについての情報を管理することができる。
【００３８】
以下、操作手段「呼戻」および「変更」を例として説明する。とりわけ後者の概念は本発明では、第１のメッセージＭＭ_Ａの更新であると理解されたい。これはとりわけ第１のメッセージを第２のメッセージにより置換することにより行われる。しかし一般的に、本発明により開示された、操作のすべての形式に対するオプションのすべての組合せも実現可能である。これらは例えば、受信側に第１のメッセージの操作について情報が通知されるか否か、およびどの情報が受信側に通知されるか、操作の形式について情報を通知すべきか否か、受信側に送信側の操作機能についての情報を通知すべきか否か、第２のメッセージをプルモードまたはプッシュモードで配達すべきか否か、送信側または受信側ネットワークエレメントでの変更、または受信アプリケーションＵＡＢでの変更を行うべきか否か、送信側および／または受信側に操作の実行について通知すべきか否か等である。
【００３９】
Ａ．サービスフィーチャ「呼戻」
本発明によれば、第１のマルチメディアメッセージＭＭ_Ａをすでに送信し、このすでに送信したＭＭ_Ａを再び呼び戻したいと望むＭＭＳのユーザは、新たな第２のメッセージＭＭ_Ｂを情報付きで送信することができ、以前に送信された第１のメッセージＭＭ_Ａは再び呼び戻される。
【００４０】
このことは本発明によれば有利には次のようにして実現される。すなわち送信側が新たなＭＭ_Ｂを作成し、この新たなＭＭ_Ｂは呼戻命令を含むが、有利には受信側に対する所定の内容（コンテンツ／メッセージボーイ）を含んでおらず、この新たなメッセージを以前に送信したＭＭ_Ａと同じ受信側に送信するのである。呼戻フラグとして有利には以前に送信したＭＭ_ＡのＩＤ１が使用される。呼戻情報を備えるＭＭ_Ｂはまず送信側のネットワークエレメントに到達する。ここで有利には、ＩＤ１を備えるＭＭ_ＡがまだサービスプロバイダＡ（ＭＭＳＥ_Ａ）の管轄領域にあるか否か、またはこれがすでにサービスプロバイダＢのＭＭＳＥ_Ｂに転送されているか否かを検査する。例えば前者は送信側により選択された自分のＭＭ_Ａの配達に対する所望の時点にまだ達していない場合であり、後者はＭＭ_Ａがまだその有効持続期間を越えていないか、または受信アプリケーションＵＡＢに配達されていない場合である。ＭＭ_Ａが、関与するＭＭＳサービスプロバイダのＭＭＳＥで発見されると直ちに、ＭＭ_ＡとＭＭ_Ｂの消去を管轄ネットワークエレメントＲＳにより開始することができる。
【００４１】
受信アプリケーションＵＡＢがすでにＭＭＳＥ_Ｂで準備されたＭＭAについてメッセージング（通知）により知らされており、ＭＭ_ＡがまだサービスプロバイダＢの管轄領域／メモリに存在する場合、受信アプリケーションＵＡＢは新たなメッセージング（通知）により、ＭＭ_ＡがサービスプロバイダＢにより消去され、従って送信側がこれを呼び戻したのでダウンロードできないことが知らされる。さらにＭＭＳサービスプロバイダＢは、受信アプリケーションＵＡＢに呼戻命令を実行した日付を通知することができる。
【００４２】
ＭＭ_Ａがすでに受信側に配送されている場合、受信側の受信アプリケーションＵＡＢには上記の新たなメッセージング（通知）により、送信側がＭＭ_Ａを呼び戻したがっていることが知らされる。ＭＭ_Ａの消去は直接、受信アプリケーションＵＡＢが呼戻サービスフィーチャをサポートする場合には受信アプリケーションＵＡＢで行われる。端末機器におけるこのサービスフィーチャの実現、ユーザの調整、ＭＭＳサービスプロバイダの調整および／またはネットワークプロバイダの調整に応じて、ＭＭ_Ａの端末機器での消去をＭＭAがすでに受信側により処理されているか（例えば開封、既読、転送等）否かに依存させることができる。しかし配送後にまだ受信側により処理されていないＭＭｓだけを消去するのが有利である。呼戻情報を備えるＭＭ_Ｂは受信アプリケーションＵＡＢに必ずしも配送されなければならないものではない。これはすでにＭＭＳＥ_Ｂで消去することができる。
【００４３】
呼戻情報を備えるＭＭ_Ｂが呼び戻すべきＭＭ_Ａの前にネットワークエレメントＲＳＢに達した等の理由で、ＭＭ_Ａの受信側（ＭＭＳユーザエージェントＢ）がＭＭAについてまだ通知を受けていなければ、やはり送信側により開始された呼戻アクションについて情報通知する必要はない。その代わりにネットワークエレメントＲＳＢは有利には、呼戻に参照されるＭＭ_Ａを受け取り、これを到達の際に消去するまで待機する。このときこれは受信側には通知されない（ネットワークエレメントＲＳＢが呼戻サービスフィーチャをサポートすることが前提である）。択一的にＭＭ_Ａの消去はネットワークエレメントＲＳＡで行うこともできる。
【００４４】
呼戻の委託者（ＭＭＳユーザエージェントＡ）は、自分により開始されたアクションの実行の結果および日付について、関与するＭＭＳサービスプロバイダが可能である場合、情報通知される。
【００４５】
ここで説明したサービスフィーチャ「呼戻」を置換できるようにするため、以下の情報の１つまたは複数を関与する実体（送信アプリケーションＵＡＡ、ネットワークエレメントＲＳＡ、ネットワークエレメントＲＳＢおよび受信アプリケーションＵＡＢ）との間で付加的に交換することが提案される。
【００４６】
送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（ＭＭの送信の際）：
・ＭＭ_Ｂが呼戻命令であるというフラグ。
・呼び戻すべきＭＭ_Ａの識別番号。
・送信側が、自分の開始した呼戻アクションの結果についてフィードバックを要求しているという情報。
【００４７】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（ＭＭ送信後の確認の際）：
・サービスプロバイダが呼戻サービスフィーチャをサポートしているか否かの通知。
【００４８】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（送信側と受信側が異なるＭＭＳＥに所属する場合にだけ必要）：
・ＭＭ_Ｂが呼戻命令であることのフラグ。
・呼び戻すべきＭＭ_Ａの識別番号。
・送信側が、自分の開始した呼戻アクションの結果についてフィードバックを供給しているという情報。
【００４９】
情報をネットワークエレメントＲＳＡとネットワークエレメントＲＳＢとの間で通知することは、この情報がＭＭ_Ｂの送信の際に存在していたか否かに依存する。
【００５０】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）（該当するＭＭについての報告の場合）、有利にはメッセージにおいて：
・いつ呼戻が実行されたかという情報。
・以前に通知により予告されたＭＭ_Ａがもはやダウンロードできないという情報。ＭＭＳＥBで消去されたＭＭ_Ａの同定はメッセージレファレンス（ＵＲＩ）に基づき行われる。
または：
・すでに配送されたＭＭ_Ａが送信側により呼び戻されているという情報。呼び戻されるＭＭ_Ａの同定は受信アプリケーションＵＡＢでメッセージＩＤに基づき行われる。
【００５１】
受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（通知後）：
・受信側が、以前に通知により予告されたＭＭ_Ａがもはやダウンロードできないことを理解したか否かの情報。
または：
・受信アプリケーションＵＡＢがＭＭAの呼戻を成功裏に実行できたか（すなわち消去）または指示したか否かについての情報。
・受信側にすでにダウンロードしたＭＭ_Ａが呼び戻されたため、受信アプリケーションにアクセスできる端末機器のメモリ（または接続された機器／メモリカード）には存在していないことが情報通知されたか（および／または呼戻に同意したか）否かについての情報。
【００５２】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー・サーバＡ）（送信側と受信側が異なるＭＭＳＥに所属し、送信側がフィードバックを要求する場合だけ必要である）：
・呼戻ジョブを成功裏に実行できたか否かの情報。
・いつ呼戻ジョブが実行されたかという情報。
・呼戻ジョブが自動的に実行されたか否かの情報。
・受信側が呼戻について情報通知されたか否か（および／または呼戻に同意したか否か）の情報。
・すでにダウンロードされたＭＭ_Ａが呼び戻され、従って受信アプリケーションＵＡＢにアクセスする端末機器のメモリ（または接続された機器／メモリカード）に存在しないという情報。
・呼び戻されたＭＭ_Ａの識別番号。
【００５３】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→受信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（通知時に）：
・呼戻ジョブが成功裏に実行できたか否かの情報。
・いつ呼戻ジョブが実行されたかという情報。
・呼戻ジョブが自動的に実行されたか否かの情報。
・受信側が呼戻について情報通知されたか否か（および／または呼戻に同意したか否か）の情報。
・すでにダウンロードされたＭＭ_Ａが呼び戻され、従って受信アプリケーションＵＡＢにアクセスする端末機器のメモリ（または接続された機器／メモリカード）に存在しないという情報。
・呼び戻されたＭＭ_Ａの識別番号。
【００５４】
付加的サービスフィーチャ：条件付き呼戻
この本発明の特別のアスペクトには、マルチメディアメッセージの条件付き呼戻（条件付きリコール／キャンセル）および条件付き変更ないし置換または更新（条件付き置換）の技術思想が基礎となる。本発明によれば、ＭＭの送信側から送信された呼戻ジョブまたは変更ジョブの実行が所定の条件と結び付けられる。例えば送信側は、受信側に到着について情報通知されていない場合だけ所定のＭＭを呼戻または更新することを望む場合がある。別の場合では、受信アプリケーションＵＡＢが通知を受け取っていても、またはＭＭが読まれていても、送信側が消去または変更を望むこともあり得る。さらにこのサービスフィーチャを実現するためのコンセプトは本発明の一部であり、ここでは３ＧＰＰＭＭＳ仕様（上記３ＧＴＳ23.140バージョン4.0.0参照）からのデータフィールドの導入ないし適合が必要である。ここではＷＡＰの新たなヘッドフィールドが定義され、他のフィールドが整合または補足される。
【００５５】
本発明のこの有利な実施形態によれば、第２のメッセージ（以下、ＭＭ_Ｂと称する）が、第１のメッセージ（ＭＭA）を所定の条件下では削除ないし呼び戻すべきであるという情報と共に送信される。新たなＭＭ_Ｂは、ＭＭ_Ａの呼戻過程を実行するための情報を含んでいる。本発明によれば、呼戻命令の送信側は自分の意志を実行するための条件をセットする。このとき送信ユーザエージェントまたはＶＡＳアプリケーションは、どの場合に以前送信したＭＭを消去ないし無効とするかを設定する。
【００５６】
サービスプロバイダは本発明により呼戻フィーチャの使用を他のサービスプロバイダの複数のドメインまたは所定のドメインに制限することができる。このことは、受信側のアドレスの識別、例えば受信側の呼び出し番号、メールアドレス等に基づいて行うことができる。さらなる手段は付加的識別子（フラグ）を呼び出し命令でセットすることである。
【００５７】
さらに条件付き呼戻は以前に送信されたメッセージ、とりわけＭＭの処理フェーズないし処理状態に基づく。送信側はこの場合、ＭＭのどの状態でこれを消去すべきかを決定する。送信側により設定可能な、呼戻のための条件は次のとおりである：
１．ＭＭの呼戻を、これがまだサーバに存在し、受信側がそのことについてまだ知らない場合だけ行う。従って呼戻はこの場合、通知が送信されていない場合だけ行う。
２．ＭＭの呼戻を、通知は送信されているが、ＭＭがまだダウンロードされていない場合だけ行う。
３．ＭＭの呼戻を、受信側がこれをまだ開封ないし既読にしていない場合だけ行う。この場合、呼戻はダウンロード後でも行うことができる。
４．ＭＭの呼戻を、受信側でのＭＭの処理に依存せずに行う。この場合呼戻は、受信側がこのＭＭを呼んだ場合でも試みられる。
【００５８】
このサービスフィーチャを実現する場合、有利には標準的条件「デフォルト値」が仮定される。例えば標準的条件が上記４つの場合の１つに相応することを取り決めることができる。この予備設定は例えば、呼戻命令を条件付きで実行するための表明がない限り、呼戻をＭＭの存在について通知する前にだけ実行するよう設定することができる。このシステムは、呼戻を消去すべきＭＭのダウンロード前にだけ、またはＭＭが開封ないし既読になった後でも実行するよう設定することもできる。
【００５９】
以下にＭＭステータス条件付き呼戻フィーチャを実現するためのトランザクションを説明する。従ってすでに送信されたＭＭ_Ａは送信側により後から再び呼び戻すことができる。この呼戻は、送信側が新たなＭＭ_Ｂを作成することにより行われるが、この新たなＭＭ_Ｂは条件付き呼戻命令を含んでおり、有利には受信側に対する特定の内容（コンテンツ／メッセージ本体）は含んでいない。この新たなメッセージは、前に送信したＭＭ_Ａと同じ受信側に送信される。呼戻識別として有利には前に送信したＭＭ_Ａの識別番号（ＩＤ１）が使用される。呼戻情報を伴うＭＭ_Ｂはまず送信側のネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）に到達する。ここではＩＤ１を備えるＭＭAがまだサービスプロバイダＡ（マルチメディアメッセージングサービス環境Ａ、ＭＭＳＥ_Ａ）の管轄領域にあるか否か、またはこれがすでにサービスプロバイダＢのＭＭＳＥ_Ｂに転送されているか否かが検査される。前者は、送信側により選択された自分のＭＭ_Ａの所望の配送に対する時点にまだ達していない場合であり、後者は、ＭＭ_Ａがまだその有効期限を過ぎておらず、かつ受信アプリケーションＵＡＢにまだ配送されていない場合である。
【００６０】
ＭＭAがＭＭＳＥで発見されると直ちに、ＭＭ_ＡとＭＭ_Ｂの消去を管轄のネットワークエレメントＲＳにより開始することができる。元の受信側が自分に宛てられたＭＭ_Ａを別のアドレスに転送している場合、有利には呼戻命令もネットワークエレメントＲＳＢから相応に転送される。これにより呼戻を目的側のネットワークエレメントＲＳで行うことができる。ネットワークエレメントＲＳＢが、ＭＭが転送されたという情報のみを有しており、目的地が分らなければ（例えば元の受信側が自分に宛てられたＭＭをＥメールアドレスに転送した場合）、呼戻命令の送信側は有利には転送による呼戻の失敗について情報通知される。秘密性の理由から、呼戻の失敗について通報し、その場合に理由にはコメントしないことも考えられる。
【００６１】
呼戻命令の実行に有利なのは、ＭＭがまだネットワークエレメントＲＳＡまたはＲＳＢの一方にあり、受信アプリケーションＵＡＢがまだこのメッセージについて通知されていない場合である。このような場合は、ＭＭが送信側の希望により所定の時点で配送されるべきであるが、まだ到着していない場合である。この場合、ＭＭはまだ送信側のネットワークエレメントＲＳＡにある。ＭＭをネットワークエレメントＲＳＢに記憶することもできる。これは例えば受信側の端末機器が遮断されており、ＭＭの有効期限をまだ越えていない場合である。この両方の場合で、ＭＭの消去は選択された壮挙条件に依存しないで行うことができる。上に述べた４つの呼戻条件すべてはこの状況を網羅する。
【００６２】
受信アプリケーションＵＡＢが、ＭＭＳＥ_Ｂにすでに存在するＭＭ_Ａについて通知（ノティフィケーション）によって情報を受けており、ＭＭAがまだサービスプロバイダＢの管轄領域／メモリに存在すべきである場合、本発明によれば呼戻は上記２，３，４により番号の付された場合にだけ行うことができる。条件付き呼戻のケース１に対しては、送信側が有利には説明を伴う通知を受け取る。この説明は、受信側がすでに前に送信されたＭＭについて情報を受けており、呼戻を実行できなかったという説明である。別の場合（２，３，４）に対して、受信アプリケーションＵＡＢは新たな通知（ノティフィケーション）により次の知識を得る。すなわちＭＭ_ＡがサービスプロバイダＢにより消去されており、従ってもはやダウンロードすることができない、なぜならこれが呼び戻されたからであるという知識を得る。さらなる手段では、受信側が、ＭＭがもはや存在していないか、またはこれが呼び戻されたことを自分に通知することを要求した場合に初めて受信側に呼戻について情報通知する。
【００６３】
ＭＭ_Ａがすでに受信側には移動されている場合、呼戻はケース４（処理程度に依存しない呼戻）および場合によりケース３（ＭＭがまだ開封されていない／未読である）に対してだけ実行することができる。受信アプリケーションＵＡＢはケース３と４に対してだけ、有利には新たな通知（ノティフィケーション）により送信側がＭＭ_Ａの呼戻を希望しているという知識を得る。この通知は有利には消去の条件を含む。
【００６４】
従ってＭＭ_Ａの消去は受信アプリケーションＵＡＢで直接行うことができる。ただしこれが呼戻フィーチャをサポートする場合である。ケース３であれば、ＭＭは端末機器がＭＭがまだ開封されていないか、または未読であることを検出した場合だけ消去される。ケース４に対して消去は、前記のことに依存しないで行われる。両方の場合で、ＭＭ_Ｂは受信アプリケーションＵＡＢに配達する必要はない。このＭＭはすでにＭＭＳＥ_Ｂで消去することができる。なぜなら通知（ノティフィケーション）が消去をトリガするからである。ケース１（通知前の呼戻）および２（ダウンロード前にだけ呼戻）に対しては呼戻を行うことができない。ここでは送信側は有利には、メッセージがすでに送信されている（ケース１）か、またはＭＭがすでにダウンロードされている（ケース２）ので、ＭＭの呼戻ができなかったという情報によるフィードバックを受け取る。
【００６５】
本発明による消去過程を実現するためのさらなる手段は、ＭＭ_Ｂの配達を呼戻情報と共に受信アプリケーションＵＡＢまで行うのである。消去はこの場合、受信側の端末機器でＭＭ_Ｂにより行われ、ＭＭ_Ｂから発生した通知（ノティフィケーション）によってはトリガされない。この場合については以下で詳細に述べない。
【００６６】
呼戻の委託者（送信アプリケーションＵＡＡまたはＶＡＳアプリケーション）は有利には前記すべての場合で、自分により開始されたアクションの結果ないし実行の日付について情報を受ける。これはとりわけ委託者がこれを要求し、関与するＭＭＳサービスプロバイダがこれを可能にする場合である。
【００６７】
ここで説明したサービスフィーチャ「条件付き呼戻」を変換することができるようにするため、本発明では以下の情報の１つまたは複数を関与する実体（送信アプリケーションＵＡＡ、ＭＭＳネットワークエレメントＲＳＡ、ＭＭＳネットワークエレメントＲＳＢおよび受信アプリケーションＵＡＢ）間で付加的に交換することが提案される。基礎として実際の３ＧＰＰ仕様３ＧＴＳ２２．１４０バージョン４．０．１（上記参照）、３ＧＴＳ２３．１４０バージョン４．０．０（上記参照）、ＷＡＰ仕様ＷＡＰ−２０９−ＭＭＳＥキャプスレーション、リリース２０００（上記参照）、ＷＡＰ−２０３−ＷＳＰ、バージョン４−Ｍａｙ−２０００（上記参照）並びに３ＧＰＴＳＧ−Ｔ２ＳＷＧ３ＭＭＳ Ad Hoc ミーティング＃５のリポート（上記参照）を使用する。以下詳細に無条件呼戻を参照して相違と補足を説明する。
【００６８】
曹品プリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（ＭＭの送信時に）：
・呼戻を実行するための条件：
−通知前だけ呼戻。
−通知の送信後であってもダウンロード前だけ呼戻。
−ＭＭが開封されていない／未読である場合だけ呼戻。
−ＭＭの処理程度に依存しないで（ＭＭ_Ａが読まれた後でも）呼戻。
【００６９】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（ＭＭ送信後の確認の際）
・サービスプロバイダが条件付き呼戻フィーチャをサポートしているか否かの通達。ここでシステムは、「呼戻」に対するサポートと「条件付き呼戻」に対するサポートとを区別することができる。
【００７０】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（送信側および受信側が異なるＭＭＳＥに所属する場合だけ必要）：
・呼戻実行のための条件：
−通知前だけ呼戻。
−通知の送信後であってもダウンロード前だけ呼戻。
−ＭＭが未読である場合だけ呼戻。
−ＭＭの処理程度に依存しないで（読まれた後でも）呼戻。
【００７１】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）（該当するＭＭ_Ｂについての通知の際）：
・呼戻実行のための条件：
−通知の送信後であってもダウンロード前だけ呼戻。この条件は、ＭＭがダウンロードされていない場合だけ通達される。
−ＭＭが未読である場合だけ呼戻。
−ＭＭの処理程度に依存しないで（読まれた後でも）呼戻。
【００７２】
受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（通知の後で）：
・条件付き呼戻ジョブが成功裏に実行できたか否かの情報。
・失敗した場合には、あり得る理由を伴う相応の通報。
【００７３】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（送信側および受信側が異なるＭＭＳＥに所属し、送信側がフィードバックを要求している場合だけ必要）：
・条件付き呼戻ジョブが成功裏に実行できたか否かの情報。
・失敗した場合には、あり得る理由を伴う相応の通報。
【００７４】
ＷＡＰメッセージの適合
以下、サービスフィーチャ「呼戻」に対するＷＡＰメッセージの可能な変形について詳細に説明する。予め、ＷＡＰ仕様ではＭＭＳユーザエージェントがＭＭＳクライアントに相応し、ＭＭＳリレー／サーバの代わりにＭＭＳプロクシー／リレーについて説明することを述べておく。ＡＰ−２０３−ＷＳＰ、バージョン４−Ｍａｙ―２０００（上記参照）。既存のＭＭＳユーザエージェントについて説明するときはこれによりＭＭＳクライアントも含むものである。同じことが概念：ＭＭＳリレー／サーバとＭＭＳプロクシー／リレーについても当てはまる。分かり易くするため以下では、概念：ＭＭＳユーザエージェントとＭＭＳリレー／サーバだけを使用する。
【００７５】
サービスフィーチャ「呼戻」をＭＭＳのＷＡＰ実現に追加するため、本発明ではＷＡＰメッセージの変形、M-Send.req,M-Send.conf,M-Notification.ind,M-NotifyResp.indおよびM-Delivery.indが提案される。これらでは本発明により種々異なるヘッドフィールドが補足ないし変形される。ＷＡＰ−２０３−ＷＡＰ（上記参照）によれば、各ヘッドフィールドは符号化されたフィールド名と符号化されたフィールド値からなる。ここではフィールド値を符号化するのに全体で４つの手段が存在し、フィールド値の第１のオクテットが符号化の形式および長さについて決定する（表１参照）。
【００７６】
Ａ．１．ＷＡＰメッセージ M-Send.req（送信アプリケーションＵＡＡからネットワークエレメントＲＳＡへ）
ＭＭ_Ａの送信側は、自分がこのＭＭ_Ａを再び呼び戻したいことを表明しなければならない。このことは別のＭＭ_Ｂを同じ受信側に送信することにより行われる。この目的のために、ＷＡＰメッセージM-Send.reqでこれと共にＭＭ_Ｂを送信することができ、ヘッドフィールドが補足される。このヘッドフィールドは、送信側が呼び戻したがっているＭＭの識別番号を有している（図２のＭＭ_ＡのＩＤ１）。このヘッドフィールドが名前X-Mms-Recall-IDと１６進コード0x7F（１０進：１２７）を有することが提案される。メッセージＩＤはエンキャプスレーション規格（ＷＡＰ−２０９−ＭＭＳＥエンキャプスレーション、リリース２０００；ワイヤレスアプリケーションプロトコル；ＷＡＰマルチメディアメッセージングサービス；メッセージエンキャプスレーション；ＭＭＳ提案ＳＣＤ１．０）と同じであり、有利にはいわゆるテキストストリングにより符号化される。さらにＭＭの送信側には呼戻ジョブにより有利にはフィードバックを要求することのできる手段が与えられる。このために適切な標識X-Mms-Request-Reportと１６進コード0x85（１０進：１３３）を伴うヘッドフィールドをＷＡＰメッセージM-Send.reqに導入することが提案される。このヘッドフィールドのフィールド値は有利にはエンキャプスレーション規格（上記参照）と同じであり、「フィードバックが希望される」に対しては〈オクテット１２８〉により、「フィードバックが希望されない」に対しては〈オクテット１２９〉により符号化される。
【００７７】
さらに条件付き呼戻の場合に対して付加的に新たなヘッドフィールドを挿入することが提案される。この新たなヘッドフィールドは呼戻命令の実行に対する条件を通知する。このために例えば標識X-Mms-Recall-Condを備えるヘッドフィールドが提案される。このヘッドフィールドは有利には１６進コード0x86（１０進：１３４）を有する。このヘッドフィールドは有利には、「通知前だけの呼戻」に対しては〈オクテット１２８〉により、「通知の送信後であってもダウンロード前だけ呼戻」に対しては〈オクテット１２９〉により、「ＭＭが未読の場合での呼戻」に対しては〈オクテット１３０〉により、そして「ＭＭの処理程度に依存しない（既読後であっても）呼戻」に対しては〈オクテット１３１〉により符号化される。さらなる条件を導入する場合、有利には相応のフィールド値が追加される。〈オクテット１３１〉の導入とは択一的に、ヘッドフィールドX-Mms-Recall-Condのない呼戻命令を「既読後であっても呼戻」に対するものと取り決めることもできる。
【００７８】
Ａ．２ＷＡＰメッセージ M-Send.conf （ネットワークエレメントＲＳＡから送信アプリケーションＵＡＡへ）
このＷＡＰメッセージにより送信アプリケーションＵＡＡには本発明では付加的に、サービスプロバイダＡが送信側（ＭＭＳユーザエージェントＡ）の呼戻ジョブを受け入れたか否かが通知される。このために有利には、名前 X-Mms-Supported-Feature と１６進コード0x83（１０進：１３１）を備える新たなヘッドフィールドをＷＡＰメッセージ M-Send.conf に挿入することが提案される。有利にはフィールド値としてエンキャプスレーション規格（上記参照）と同じものが使用され、〈オクテット１２８〉が委託確認を、〈オクテット１３０〉が負のフィードバックに使用される（図１０参照）。
【００７９】
さらに送信アプリケーションＵＡＡには本発明により付加的に、サービスプロバイダＡが条件付き呼戻をサポートしているか否かが通知される。このためにここでは、１６進コード0x83（１０進：１３１）を備えるX-Mma-Supported-Featureのフィールド値に例えば値〈オクテット１３１〉を補足することが提案される。この値はここでは条件付き呼戻のサポートに対するものである。ＭＭAがまだネットワークエレメントＲＳＡに記憶されており、受信アプリケーションＵＡＢにまだ通知されていない場合、ＭＭは有利には消去され、送信アプリケーションＵＡＡは有利にはこの実行について情報を受ける。このために本発明では、ヘッドフィールドX-Mms-StatusをＷＡＰメッセージM-Send.confに追加することが提案される。このとき有利には新たなフィールド値〈オクテット１３８〉が「通知前に呼戻が必要」に対するものであると定義される。さらにここでは新たなフィールド値〈オクテット１４２〉を「メッセージが送信されたので呼戻が失敗」に対して設定することが提案される。このコード値は、条件付き呼戻のケース１（通知前だけ呼戻）を実行しようとする送信アプリケーションＵＡＡに、メッセージがすでに送信された場合にＭＭ_Ａの消去ができなかったことの情報を与える。このような場合は、送信アプリケーションＵＡＡと受信アプリケーションＵＡＢが同じネットワークエレメントＲＳ、ここではネットワークエレメントＲＳＡに配属されているときに発生する。
【００８０】
Ａ．３ＷＡＰメッセージ M-Notification.ind （ネットワークエレメントＲＳＢから受信アプリケーションＵＡＢへ）
受信アプリケーションＵＡＢがすでに、ダウンロードの準備のできたＭＭ_Ａについて情報を受けた場合、本発明ではＷＡＰメッセージM-Notification.indで、適切な標識X-Mms-Recall-URIと１６進コード0x80（１０進：１２８）を備える新たに定義されたヘッドフィールドが使用される。この新たに定義されたヘッドフィールドによって受信アプリケーションＵＡＢには、前記のＵＲＩを備えるＭＭ_Ａがもはやダウンロード待機されていない、なぜなら送信側がこれを呼び戻したからであることが通報される。この新たに定義されたヘッドフィールドのフィールド値は有利にはエンキャプスレーション規格（上記参照）と同じであり、テキストストリングとして符号化される。
【００８１】
受信アプリケーションＵＡＢに消去の時点について情報を与えることができるようにするため、本発明では適切な標識X-Mms-Date-of-Executionと１６進コード0x84（１０進：１３２）を備える新たに定義されたヘッドフィールドを補足することができる。このヘッドフィールドに対するフィールド値は有利にはエンキャプスレーション規格（上記参照）に従い長整数として符号化される。
【００８２】
通知のＵＲＩでは本発明により、標準テキストメッセージの記憶場所が指示される（例えば：「このＭＭは送信側により再度消去されました」）。このテキストメッセージによりネットワークエレメントＲＳＢは受信アプリケーションＵＡＢに、実行された呼戻ジョブについて情報を与えることができる。これはネットワークエレメントが呼戻サービスフィーチャをサポートしておらず（すなわち新たなヘッドフィールドを識別しない）、ＭＭを通知で指示された記憶場所からダウンロードしようとする場合である。
【００８３】
呼び戻すべきＭＭAがすでに受信アプリケーションＵＡＢに配送されている場合、本発明ではＷＡＰメッセージM-Notification.indが章Ａ．１で定義された、名前X-Mms-Recall-IDを備えるヘッドフィールドを含むことができる。受信アプリケーションＵＡＢはこれに基づきメッセージＩＤ（図２からのＩＤ２）を用いてＭＭ_Ａの消去を開始することができる（有利には呼戻サービスフィーチャをサポートする）。
【００８４】
消去すべきＭＭ_Ａが受信アプリケーションＵＡＢによりダウンロードされた場合、条件付き呼戻の場合では、受信アプリケーションＵＡＢが有利にはＭＭAの消去のための条件について情報を受ける。このために有利には本発明で新たに定義された、１６進コード0x86（１０進：１３４）を備えるヘッドフィールドX-Mms-Recall-Condが使用される。この場合、コード値〈オクテット１３０〉がＭＭが未読の場合の呼戻（未読の呼戻）に対して、および〈オクテット１３１〉がＭＭの処理程度に依存しない呼戻（既読であっても呼戻）に対して必要なだけである。通知前だけの呼戻に対する〈オクテット１２８〉と、通知の送信後であってもダウンロード前だけの呼戻に対する〈オクテット１２９〉はここでは必要ない。なぜならこの例では両方の場合で、通知の送信前にＭＭ_Ａの消去を行うべきだからである。
【００８５】
Ａ．４ＷＡＰメッセージ M-NotifyResp.req（受信アプリケーションＵＡＢからネットワークエレメントＲＳＢへ）
本発明によれば有利には、ＷＡＰメッセージM-NotifyResp.reqでオプションとして新たなヘッドフィールドを追加することが提案される。この新たなヘッドフィールドによってネットワークエレメントＲＳＢに、受信アプリケーションＵＡＢが成功裏に実行された呼戻ジョブについての通報を理解した否かが通知される。この目的のために有利には、他のＷＡＰメッセージから既知のヘッドフィールドX-Mms-Statusが使用され、新たなフィールド値が定義される：〈オクテット１３６〉が「フィーチャ呼戻がサポートされている」を意味することが提案される。
【００８６】
呼び戻すべきＭＭAがすでに受信アプリケーションＵＡＢに配送されている場合、本発明の変形実施例では、ＷＡＰメッセージM-NotifyResp.reqに、エンキャプスレーション規格で定義されたヘッドフィールドヘッドフィールドX-Mms-Statusが挿入され、これによりネットワークエレメントＲＳには、送信側の呼戻ジョブが受信アプリケーションＵＡＢに成功裏に実行できたか否かを通知することができる。このためにここではこのヘッドフィールドの拡張も必要である：フィードバックは有利には２つの新たなフィールド値、すなわち「呼戻ジョブが成功裏に実行された」に対する〈オクテット１３２〉と、「呼戻ジョブは実行できなかった」に対する〈オクテット１３３〉により実現される。
【００８７】
条件付き呼戻の場合に対しては、「呼戻成功」に対する〈オクテット１３３〉および「呼戻失敗」に対する〈オクテット１３３〉、並びに上記で提案されたフィールド値、すなわち「通知前の呼戻成功」に対する〈オクテット１３８〉、および「呼戻失敗、なぜならメッセージが送信されたから」に対する〈オクテット１４２〉に、以下のフィールド値を追加することが提案される：
−〈オクテット１４０〉、「ＭＭが既読になる前の呼戻成功」に対して、
−〈オクテット１４１〉、「ＭＭが既読になったあとの呼戻成功」に対して、
−〈オクテット１４４〉、「読み戻し失敗、なぜならＭＭが既読であったから」に対して、
−〈オクテット１４５〉、「呼戻失敗、なぜならＭＭが消去されていたから」に対して、
これらの通報のおかげで、呼戻命令の送信側は自分のジョブ正確な結果について情報を受けることができる。
【００８８】
Ａ．５ＷＡＰメッセージ M-Delivery.ind （ネットワークエレメントＲＳＡから曹品プリケーションＵＡＡへ）
さらに有利には章Ａ．４で拡張されたヘッドフィールドX-Mms-Statusをここでも挿入する。これにより、新たなフィールド値〈オクテット１３２〉が「呼戻ジョブは成功裏に実行された」に対して、そして〈オクテット１３３〉が「呼戻ジョブを実行することができなかった〉に対して使用されていれば（図６参照）、送信側に呼戻ジョブを成功裏に実行できたか否かを通知することができる。さらに送信側は自分の呼戻ジョブの実行の日付について、章Ａ．３で定義したヘッドフィールド（有利には符号 X-Mms-Date-of-Excution を有する）を用い情報を受けることができる。
【００８９】
さらに有利には別の新たなフィールド値が定義される：
−〈オクテット１３９〉「ダウンロード前の呼戻成功」に対して
−〈オクテット１４３〉「呼戻失敗、なぜならＭＭがすでにダウンロードされていたから」に対して
これによりＷＡＰメッセージ M-Delivery.ind 内のヘッドフィールド X-Mms-Status の種々のフィールド値によって、送信側に自分の呼戻が実行されたか否か、またどのような条件で実行されたかを通知することができる。
【００９０】
条件付き呼戻の送信側にジョブの実行について情報通知する別の手段が新たなヘッドフィールドの定義により実現される。このヘッドフィールドは相応のＷＡＰメッセージで使用される。そのために例えば名前 X-Mms-Recall-Status を備えるヘッドフィールドが提案される。このヘッドフィールドは上に示した場合で拡張ヘッドフィールド X-Mms-Status に対する代替として使用することができる。後者はさらに、ＷＡＰ−２０９−ＭＭＳＥキャプスレーション、リリース２０００（上記参照）で定義された形態で使用することができる。新たなヘッドフィールド X-Mms-Recall-Status は有利には呼戻ジョブを実行するための情報だけを含む。X-Mms-Recall-Status に対しては１６進コード0x88（１０進：１３６）が提案される。種々異なる実施シナリオを網羅する可能なフィールド値は例えば：
−〈オクテット１２８〉「呼戻成功」に対して
−〈オクテット１２９〉「通知前に呼戻成功」に対して
−〈オクテット１３０〉「ダウンロード前に呼戻成功」に対して
−〈オクテット１３１〉「ＭＭが読まれる前に呼戻成功」に対して
−〈オクテット１３２〉「ＭＭが既読となった後に呼戻成功」に対して
−〈オクテット１３３〉「呼戻失敗」に対して
−〈オクテット１３４〉「呼戻失敗、なぜならメッセージが送信されたから」に対して
−〈オクテット１３５〉「呼戻失敗、なぜならＭＭがダウンロードされていたから」に対して
−〈オクテット１３６〉「呼戻失敗、なぜならＭＭが既読であったから」に対して
−〈オクテット１３７〉「呼戻失敗、なぜならメッセージが消去されたから」に対して
−〈オクテット１３８〉「呼戻失敗、メッセージを発見できなかったから」に対して
−〈オクテット１３９〉「呼戻失敗、メッセージがさらに転送されたから」に対して
さらなる理由または条件の場合に、フィールド値とコードを相応に補足することができる。
Ｂ．サービスフィーチャ「変更」
マルチメディアメッセージＭＭ_Ａを送信し、このすでに送信したＭＭを後から変更したいと望むＭＭＳのユーザは本発明により、新たなＭＭ_Ｂを情報と共に送信することができる。この情報は、このＭＭ_Ｂは前に送信したＭＭ_Ａを変更し、とりわけ置換するものであるという情報である。下に示す実施例ではこのことは一般的に第１のメッセージＭＭ_Ａの変更に対して当てはまる。また例えば前に送信したＭＭ_Ａに後からデータを追加することにも当てはまる。
【００９１】
ＭＭ_Ａの変更は次のようにして実現される。送信側は、変更命令を含む新たなＭＭ_Ｂを作成し、これを前に送信したＭＭ_Ａと同じ受信側に送信するのである。ＭＭ_Ａを同定するために有利には前に送信し、今や変更すべきＭＭAのＩＤ１を使用する。変更情報を備えるＭＭ_ＢはまずネットワークエレメントＲＳＡに到達する。ここでＩＤ１を有するＭＭ_ＡがまだサービスプロバイダＡの管轄領域（ＭＭＳＥ_Ａ）内にあるか、またはすでにサービスプロバイダＢのＭＭＳＥ_Ｂ内にあるかが検査される。ＭＭAの送信側により最も早い配送に対する時点または有効期限が指示されているか否かに応じて両方の場合が可能である。ＭＭ_Ａが関与するＭＭＳサービスプロバイダのＭＭＳＥにおいて発見されると直ちに、ＭＭ_ＢによるＭＭ_Ａの変更が管轄のネットワークエレメントＲＳにより開始される。実際にはこのアクションは、古いＭＭ_Ａを消去し、新たなＭＭ_Ｂを受信側に送信することにより行われる。ＭＭＳサービスプロバイダは本発明によれば受信アプリケーションＵＡＢに対して、場合により実行された変更過程および／または変更過程の実行された日付（このＭＭは何月何日に更新された）について知らせることができる。
【００９２】
ＭＭ_Ａの受信側（受信アプリケーションＵＡＢ）がまだＭＭ_Ａについての通知を受け取っていなければ（例えば変更ジョブを備えるＭＭ_Ｂが変更すべきＭＭ_Ａより前にネットワークエレメントＲＳＢに到達したという理由で）、受信側に必ずしも送信側により開始された変更アクションについて情報通知する必要はない。その代わりにネットワークエレメントＲＳＢは、変更すべきＭＭAを受け取るまで待機し、これを到着時にＭＭ_Ｂにより変更、とりわけ置換する（このことはＭＭＳネットワークエレメントＲＳＢが呼戻サービスフィーチャをサポートしていることが前提である）。ＭＭＳサービスプロバイダは本発明によれば、受信アプリケーションＵＡＢに対してＭＭ_Ｂの配送の際に、これが送信側により後から変更されたＭＭであり、この変更がいつ実行されたかを知らせることができる。
【００９３】
受信アプリケーションＵＡＢがすでに、ＭＭＳＥ_Ｂで準備されているＭＭ_Ａについて通知（ノティフィケーション）により情報を受けており、ＭＭ_ＡがまだサービスプロバイダＢの管轄領域に存在する場合、本発明によれば受信アプリケーションＵＡＢは新たな通知（ノティフィケーション）により送信側が自分のＭＭ_Ａを後から変更したこと、およびいつこの変更が実行されたかを知ることができる。
【００９４】
ＭＭ_Ａがすでに受信側に配送されている場合、受信アプリケーションＵＡＢはまず、サービスプロバイダＢから、ＭＭ_Ａを置換するためのＭＭ_Ｂが存在しているという通知を受け取るか、または変更ジョブを備えるＭＭ_Ｂを受信アプリケーションＵＡＢに直接配送することができる。ＭＭBがプッシュモードで配送されたか、またはプルモードで配送されたかに依存せずに、変更、とりわけＭＭ_ＡをＭＭ_Ｂにより受信アプリケーションＵＡＢで直接置換することができる。ただし変更サービスフィーチャがサポートされている場合である。端末機器、ユーザの構成、サービスプロバイダの構成および／またはネットワークプロバイダでのこのサービスフィーチャの実現に応じて、変更、とりわけＭＭ_Ａの置換（および引いてはプルモードの場合、ＭＭ_Ｂの付加的要求）は端末機器において、ＭＭ_Ａがすでに受信側により「処理された」か否かに依存せずに（例えば開封、既読、転送等）行うことができる。とりわけこのようなＭＭSをまだ受信側により処理されていなければ自動的に（すなわち受信側への問い合わせなしで）変更するのが有利である。受信側がＭＭ_Ａをすでに郵便到着箱から取り出し、転送または既読にしている場合には受信側に、少なくとも送信側がＭＭ_Ｂにより以前に送信したＭＭ_Ａを変更したがっていることを情報通知することができる。
【００９５】
送信側／ジョブ委託者（送信アプリケーションＵＡＡまたはＶＡＳアプリケーション）は、本発明の有利な実施例によれば、自分の開始した変更アクションの実行の結果および日付について、関与するＭＭＳサービスプロバイダがこれをサポートする場合には情報通知を受けることができる。
【００９６】
受信アプリケーションＵＡＢ上でのＭＭ_Ａの識別はとりわけメッセージ基準に基づいて行うことができる。このメッセージ基準は有利にはＵＲＩであり、そのメモリスペースの下に受信側サービスプロバイダＢの標準テキストメッセージが記憶されている。ＵＲＩは有利にはＭＭAの識別番号ＩＤ１、または受信側ネットワークエレメント（とりわけネットワークエレメントＲＳＢ）により設定される第２の識別番号（ＩＤ２）から形成される。
【００９７】
ここに説明したサービスフィーチャ変更、とりわけ置換を実行するために、本発明によれば、次の情報の１つまたは複数を関与する実体（送信アプリケーションＵＡＡ、ネットワークエレメントＲＳＡ、ネットワークエレメントＲＳＢおよび受信アプリケーションＵＡＢ）との間で付加的に直接交換することが提案される：
送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（ＭＭの送信時に）：
・ＭＭ_Ｂが変更命令であるというフラグ。
・変更すべきＭＭ_Ａの識別番号。
・送信側が自分の開始した変更アクションの結果についてのフィードバックを要求しているという情報。
【００９８】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（ＭＭ送信後の確認時に）：
・サービスプロバイダが変更サービスフィーチャをサポートしているか否かの通知。
【００９９】
ネットワークエレメントＲＳＡ（ＭＭＳリレー・サーバＡ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（送信側および受信側が異なるＭＭＳＥに所属する場合だけ必要）：
・ＭＭ_Ｂが変更命令であるというフラグ。
・変更すべきＭＭ_Ａの識別番号。
・送信側が自分の開始した変更アクションの結果についてフィードバックを要求しているという情報。
【０１００】
ネットワークエレメントＲＳＡとネットワークエレメントＲＳＢとの間での情報交換はこの方法がＭＭ_Ｂの送信時に存在していたか否かに依存する。
【０１０１】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）（到来するＭＭに関する通知時）、有利にはメッセージ内に：
・送信側がダウンロードのために備えているＭＭ_Ａを新たなＭＭ_Ｂによって変更したという情報。２つのＭＭの識別は該当するＭＭについてのメッセージ基準（ＵＲＩ）に基づき行われる。
・ダウンロードのために備えているＭＭ_Ａが新たなＭＭ_Ｂによって何時変更されたかという情報。または：
・送信側は既に前もって供給されたＭＭ_Ａを新たなＭＭ_Ｂによって変更、例えば置換したいという情報。更新されるＭＭ_Ａの識別は別個のメッセージＩＤに基づき行われ、ＭＭ_Ａを変更、例えば置換すべきＭＭ_Ｂの識別はメッセージ基準（ＵＲＩ）に基づき行われる。
【０１０２】
受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（通知後）：
・受信側に変更ジョブについて通知できたか否かという情報。
【０１０３】
ＰＵＬＬモードの場合、受信側に変更ジョブを有するＭＭ_Ｂが存在する事が通知されると、受信側はこのＭＭ_Ｂを公知のメカニズムを用いてネットワークエレメントＲＳＢから引き出すことができる。ＰＵＳＨモードではＭＭ_Ｂのダウンロードは受信側ではなくサービスプロバイダによって開始される。このＰＵＳＨモードでは先行の２つのステップ、通知及びこの通知の確認を省略することができる。
【０１０４】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）（ＭＭの配送時）：
・ＭＭ_Ｂは受信アプリケーションＵＡＢにおいて実施されるべき変更ジョブを包含しているというフラグ。
・既に供給されたＭＭ_Ａが変更、例えば置換されるべきという情報。ＭＭ_Ａの識別は別個のメッセージ識別番号（メッセージＩＤ）に基づき行われる。または、
・今まさに供給されたＭＭ_Ｂは後に変更するＭＭであるという情報。
・ＭＭ_Ｂが送信側によって何時変更されたかという情報。
【０１０５】
受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（ＭＭの配送後）：
・変更ジョブを実施することができたか否かという情報。
・変更ジョブは自動的に実施されたか否かという情報。
・受信側に変更過程が伝えられたか（及び／又は受信側は変更に同意したか）否かという情報。
【０１０６】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（送信側と受信側は異なるＭＭＳＥに属し且つ送信側がフィードバックを要求した場合にのみ必要）：
・変更ジョブを実施することができたか否かという情報。
・変更ジョブは何時実施されたかという情報。
・変更ジョブは自動的に実施されたか否かという情報。
・受信側に変更について伝えられたか（及び／又は受信側は変更に同意したか）否かという情報。
・既にダウンロードされていたＭＭ_Ａは変更、例えば置換されたか否か、または、しかしながらＭＭ_Ａは変更前にまだ供給されていなかったという情報。
・変更、例えば置換されたＭＭ_Ａの識別番号。
【０１０７】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（報告時）：
・変更ジョブを実施することができたか否かという情報。
・変更ジョブは何時実施されたかという情報。
・変更ジョブは自動的に実施されたか否かという情報。
・受信側は変更について伝えられたか（及び／又は受信側は変更に同意したか）否かという情報。
・既にダウンロードされていたＭＭ_Ａは変更、例えば置換されたか否か、または、しかしながらＭＭ_Ａは変更前にまだ供給されていなかったという情報。
・変更、例えば置換されたＭＭ_Ａの識別番号。
【０１０８】
付加的なサービスフィーチャ：条件付き変更
本発明の有利な実施形態によれば、変更命令の送信側は自身の要望を実施するための条件を指定することができる。ここで送信アプリケーションＵＡＡまたはＶＡＳアプリケーションが規定されており、ここでは事前に送信されたＭＭが変更される。条件付き変更を「Conditional Replace」と称することもできる。
【０１０９】
本発明によればサービスプロバイダはサービスフィーチャ「変更」の使用をサービスプロバイダの固有のまたは所定のドメインに制限することができる。このことは例えば受信側のアドレス（電話番号またはメールアドレスなど）の識別に基づき行うことができる。さらには、変更命令に付加的な識別子（フラグ）を使用することも考えられる。
【０１１０】
有利には条件付き更新は事前に送信されたメッセージ（ここではマルチメディアメッセージＭＭ）の処理段階を基礎とする。この場合送信側は、ＭＭのどの状態の時にこのＭＭが消去されるべきかを決定する。変更、例えば置換の考えられる条件は：
１．ＭＭがサーバに存在し且つ受信側がこれをまだ知らない場合のみＭＭを変更する。すなわち変更は通知（Notification）がまだ送信されていなかった場合にのみ行われる。
２．通知（Notification）は既に送信されていたが、ＭＭは未だダウンロードされていなかった場合にもＭＭは変更される。
３．受信側がＭＭを未開封ないし未読であった場合にＭＭを変更する。この場合、変更をダウンロード後にも行うことができる。
４．受信側におけるＭＭの処理段階に依存せずにＭＭを変更する。ここで変更は受信側がＭＭを既読である場合にも試みられる。
【０１１１】
このサービスフィーチャを実現するにあたり、有利には標準条件「デフォルト値」が使用される。例えば、標準条件を上述の４つの事例に対応するということを取り決めることができる。この事前の設定を、変更命令の条件付きの実施について詳細には示されていなかった場合には、変更は例えば通知前にのみ行われるべきであるように規定することができる。そのような変更は変更すべきＭＭをダウンロードする前にのみ、またはそれどころか開封後ないし既読後に行われるべきようにシステムを設計することもできる。
【０１１２】
以下ではＭＭステータス条件付きサービスフィーチャ「変更」を実現するためのトランザクションを検討する。すなわち既に送信されたＭＭ_Ａを送信側により、この送信側が条件付き変更命令及び受信側にとって所定の新たな内容（「Content/Message Body」）を包含する新たなＭＭ_Ｂを作成することによって後に再度呼び戻すことができる。この新たなメッセージは以前にＭＭ_Ａを送信した受信側と同一の受信側に送信される。変更識別子として以前に送信されたＭＭ_Ａの識別番号（ＩＤ１）が使用される（上記参照）。変更情報を有するＭＭ_Ｂは先ず送信側のネットワークエレメントＲＳＡに到達する。このネットワークエレメントＲＳＡではＩＤ１を有するＭＭ_ＡはサービスプロバイダＡの管轄領域（ＭＭＳＥ_Ａ）内にあるか否か、またはＭＭ_Ａは既にサービスプロバイダＢのＭＭＳＥ_Ｂに転送されたか否かが検査される。前者は例えば、送信側がＭＭ_Ａを所望に配送するために選択した時点にはまだ達していない場合であり、後者は例えば、ＭＭ_Ａは依然として有効時間を上回っておらず、受信アプリケーションＵＡＢに送信されていなかった場合である。
【０１１３】
ＭＭ_ＡがＭＭＳＥにおいて発見されるやいなや、権限のあるネットワークエレメントＲＳによるＭＭ_ＡのＭＭ_Ｂへの変更を開始することができる。本来の受信側がこの受信側へ配信されたＭＭを他のアドレスに転送した場合には、変更命令もネットワークエレメントＲＳによって相応に転送されるべきである。ネットワークエレメントＲＳＢが、目的地を知らずにＭＭは転送されたという情報のみを有する場合（例えば本来の受信側がこの受信側へ発信されたＭＭをあるＥメールアドレスに転送した場合）には、変更命令の送信側には転送に起因する呼戻の失敗を伝えることができる。信頼性の理由からオペレーションの失敗を伝えることも可能ではあるが、この場合には原因は説明されない。
【０１１４】
変更命令を実施するための殊に好適な事例は、ＭＭが依然ネットワークエレメントＲＳＡまたはＲＳＢに存在し、受信アプリケーションＵＡＢにこのメッセージに関する通知が未だなされていなかった場合である。そのような事例は例えばＭＭが送信側の要望に基づき、まだ訪れていない所定の時点以降に供給されるべき場合に生じる可能性がある。ここではＭＭが依然として送信側のネットワークエレメントＲＳＡに存在する。例えば受信側の端末機器がオフであり且つＭＭの有効時間が経過していなかった場合には、ＭＭをネットワークエレメントＲＳＢに記憶することもできる。これら２つの事例では、ＭＭの変更を選択れた消去条件に依存せずに行うことができる。すなわち上述した４つ全ての変更条件はこの状況をカバーする。
【０１１５】
受信アプリケーションＵＡＢには通知（Notification）を用いることによりＭＭＳＥ_ＢにあるＭＭ_Ａが既に伝えられており、このＭＭ_Ａは依然としてサービスプロバイダＢの管轄領域／メモリに存在する場合には、本発明によれば変更を上記において２、３及び４の番号を付した事例についてのみ行うことができる。条件付き変更の事例１では送信側は有利には、受信側には既に以前に送信されたＭＭが伝えられており、変更を行うことができなかったという通知を受け取る。他の事例（２、３及び４）では受信アプリケーションＵＡＢに新たな通知を用いて、ＭＭ_ＡはＭＭ_Ｂに変更されていて、したがってもはやダウンロードに備えないということを知らせることができる。この代わりに受信側は新たなＭＭ_Ｂを要求することができる。
【０１１６】
ＭＭ_Ａが既に受信側に供給されていた場合には、変更を事例４（処理段階に依存しない変更）、場合によっては事例３（ＭＭは未開封／未読であった場合のみ変更）についてのみ行うことができる。事例３及び４の場合のみ、受信アプリケーションＵＡＢには有利には新たな通知を用いて、送信側はＭＭ_Ａの変更を欲していることが知らされる。この通知は有利には変更の条件を包含する。したがってＭＭ_Ａの更新は、ＭＭＳユーザエージェントＡがサービスフィーチャ「変更」をサポートする限り、直接にこのＭＭＳユーザエージェントＡにおいて行うことができる。事例３の場合にＭＭは有利には、端末機器がＭＭは未開封ないし未読であったことを確認した場合にのみ変更される。事例４では変更はこれに依存せずにトリガされる。事例１（通知前の変更）及び事例２（ダウンロード前のみの変更）では、変更を行うことができない。送信側は有利には、通知が既に送信されていたため（事例１）、またはＭＭが既にダウンロードされていたため（事例２）、ＭＭを変更することができなかったという情報を有するフィードバックを受け取る。
【０１１７】
本発明によれば、変更過程を実現するための別の可能性は、変更情報を有するＭＭ_Ｂを受信アプリケーションＵＡＢに送信することである。この場合には変更は受信側の端末機器においてＭＭ_Ｂによってトリガされ、ＭＭ_Ｂから発生する通知によってはトリガされない。この事例についてはさらに詳細には検討しない。
【０１１８】
変更のジョブ委託側（送信アプリケーションＵＡＡまたはＶＡＳアプリケーション）には、有利には既述の全ての事例において、この委託側によって開始されるアクションの実行の結果及び必要に応じて日付が伝えられ、このことはジョブ委託側が要求し且つ関連するＭＭＳサービスプロバイダがこれを実現できる場合に行われる。
【０１１９】
条件付き変更は受信アプリケーションＵＡＢに到達すべきＭＭであるので、このサービスフィーチャ「変更」をサポートしないＭＭＳＥ（マルチメディア・メッセージング・サービス環境、Multimedia Messaging Service Environments）は有利には簡潔なＭＭとしての新たなＭＭ_Ｂを処理する。すなわちＭＭ_Ｂは、ＭＭ_Ａの置換なしに、受信アプリケーションＵＡＢに新たなＭＭとして到達する。有利にはこのことについても送信側には伝えられる。
【０１２０】
今ここで説明したサービスフィーチャ「条件付き変更」を実現できるようにするために、本発明によれば以下の情報のうちの１つまたは複数の情報が関与する実体（送信アプリケーションＵＡＡ、ネットワークエレメントＲＳＡ、ネットワークエレメントＲＳＢ及び受信アプリケーションＵＡＢ）の間で付加的に交換されることが提案される。基礎として現在の３ＧＰＰ規格3G TS140 version 4.0.1（上記参照）並びに3G TS 23.140 version 4.0.0（上記参照）及びＷＡＰ規格WAP-209-MMSEncapsulation;Release2000（上記参照）、WAP-203 WSP（上記参照）及びReport of the 3GPP TSG-T2 SWG3（上記参照）が使用される。以下では、無条件変更との比較における相違点及び補足点を詳細に検討する。
【０１２１】
送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（ＭＭを送信する場合）
・変更を実施するための条件：
−通知前にのみ変更。
−通知の送信後であっても、ダウンロード前にのみ変更。
−ＭＭが未開封／未読であった場合にのみ変更。
−（ＭＭ_Ａを既読であっても）ＭＭの処理段階に依存しない変更。
【０１２２】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（ＭＭの送信後の確認時）：
・サービスプロバイダが条件付き変更サービスフィーチャをサポートしているか否かという、このサービスプロバイダの通達。ここではシステムは「変更」のサポートと「条件付き変更」のサポートとを区別してもよい。
【０１２３】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（送信側と受信側は異なるＭＭＳＥに属している場合にのみ必要）：
・置換を実施するための条件：
−通知前にのみ変更。
−通知の送信後であっても、ダウンロード前にのみ変更。
−ＭＭが未読であった場合にのみ変更。
−（既読であっても）ＭＭの処理段階に依存しない変更。
【０１２４】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）（到来したＭＭ_Ｂに関する通知時）：
・変更を実施するための条件
−通知の送信後であっても、ダウンロード前にのみ変更。この条件はＭＭがダウンロードされていなかった場合にのみ伝えられる。
−ＭＭが未読であった場合にのみ変更。
−（既読であっても）ＭＭの処理段階に依存しない変更。
【０１２５】
受信アプリケーションＵＡＢ（ＭＭＳユーザエージェントＢ）→ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）（通知後）：
・条件付き変更ジョブを実施できたか否かの情報。
・失敗に終わった場合には考えられる理由の相応の通達。
【０１２６】
ネットワークエレメントＲＳＢ（ＭＭＳリレー／サーバＢ）→ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）（送信側と受信側は異なるＭＭＳＥに属し、送信側がフィードバックを要求した場合にのみ必要）：
・条件付き変更ジョブを実施できたか否かの情報。
・失敗に終わった場合には考えられる理由の相応の通達。
【０１２７】
ネットワークエレメントＲＳＡ（ＭＭＳリレー／サーバＡ）→送信アプリケーションＵＡＡ（ＭＭＳユーザエージェントＡ）（報告の際）：
・条件付き変更ジョブを実施できたか否かの情報。
・失敗に終わった場合には考えられる理由の相応の通達。
【０１２８】
ＷＡＰメッセージの適応
以下では変更サービスフィーチャのためのＷＡＰメッセージの可能な修正形態を詳細に説明する。適応及び割当は一例であり、勿論変形させることもできる。変更サービスフィーチャをＭＭＳのＷＡＰ実現に導入するために、本発明によればＷＡＰメッセージの修正形態、M-Send.req、M-Send.conf、M-Notification.ind、M-NotifyResp.req、M-Retrieve.conf、M-Acknowledge.ind及びM-Delivery.indが提案される。これらにおいて有利には、章Ａ（サービスフィーチャ呼戻）におけるプロセスと同様に種々のヘッダフィールドが補完ないし修正される。以下では再びＭＭＳユーザエージェントないしＭＭＳプロキシ／サーバについて述べるが、これはＭＭＳクライアントないしＭＭＳプロキシ／リレーも意味している。
【０１２９】
Ｂ．１ＷＡＰメッセージM-Send.req（送信アプリケーションＵＡＡからネットワークエレメントＲＳＡ）
ＭＭの送信側は、既に送信したＭＭ_Ａを後に新たなＭＭ_Ｂに変更、例えば置換したいということを表明できるものとする。有利にはこのために、新たなＭＭ_Ｂと共に送信されるＷＡＰメッセージM-Send.reqには、ＭＭ_Ｂによって変更、例えば置換されるべきＭＭの識別番号を持つ別のヘッダフィールドが補完される（すなわち図２のＭＭ_ＡのＩＤ１）。このヘッダフィールドにX-Mms-Replace-IDという名称と１６進数の符号化０ｘ８１（２進数：１２９）を持たせることが提案される。メッセージＩＤはカプセル化規格（上記参照）に従い有利にはテキスト列として符号化される。さらに変更ジョブを有するＭＭの送信側には有利にはフィードバックを要求する可能性が与えられる。このために、１６進数の符号化０ｘ８５（２進数：１３３）及び好適な名称X-Mms-Request-Reportを有する、章Ａ．１において規定されたヘッダフィールドがＷＡＰメッセージM-Send.reqに挿入される。このヘッダフィールドのフィールド値は有利にはカプセル化規格（上記参照）にしたがって、「フィードバックが所望される」用の＜Ｏｃｔｅｔ１２８＞及び「フィードバックは所望されていない」用の＜Ｏｃｔｅｔ１２９＞でもって符号化される。
【０１３０】
さらには付加的に、変更命令の実施の条件を伝送する新たなヘッダフィールドが付加される。このために例えば、有利には１６進数の符号化０ｘ８７（２進数：１３５）を備えた例示的な名称のX-Mms-Replace-Condを有するヘッダフィールドが提案される。このヘッダフィールドは有利には、通知前のみ置換（Replace only before Notification）用の＜Ｏｃｔｅｔ１２８＞、通知の送信後であってもダウンロード前のみの置換（Replace only before Downloading）用の＜Ｏｃｔｅｔ１２９＞、未読の場合における置換（Replace only before Reading）用の＜Ｏｃｔｅｔ１３０＞及び（既読であっても）ＭＭの処理段階に依存しない置換（Replace even after Reading）用の＜Ｏｃｔｅｔ１３１＞でもって符号化される。別の条件を導入する場合には有利には相応のフィールド値が付加される。
【０１３１】
Ｂ．２ＷＡＰメッセージM-Send.conf（ネットワークエレメントＲＳＡから送信アプリケーションＵＡＡ）
本発明によればこのＷＡＰメッセージを用いて、送信アプリケーションＵＡＡはサービスプロバイダＡが送信側（送信アプリケーションＵＡＡ）の変更ジョブに応じて処理を行ったか否か、ないし処理することができたか否かを伝える。このために、章Ａ．２において呼戻サービスフィーチャのために挿入された、好適な名称X-Mms-Supported-Featureを有するヘッダフィールドを有利にはここでも使用することが提案される。フィールド値として「変更フィーチャはサポートされている」用の＜Ｏｃｔｅｔ１２９＞か、「サポートされていない」用の＜Ｏｃｔｅｔ１３０＞が使用される。
【０１３２】
さらに、条件付き変更の場合には、１６進数の符号化０ｘ８３を有するX-Mms-Supported-Featureのフィールド値が値＜Ｏｃｔｅｔ１３２＞でもって補完されることが提案される。この値は条件付き変更ないし置換のサポートを表す。ＭＭ_Ａが依然としてネットワークエレメントＲＳＡに記憶されている場合、且つ受信アプリケーションＵＡＢに依然として通知されていなかった場合には、ＭＭは変更されて、送信アプリケーションＵＡＡには有利にはこの実施が伝えられる。このために本発明によれば、ヘッダフィールドX-Mms-StatusがＷＡＰメッセージM-Send.confに付加される事が提案される。ここで有利には、「通知前に変更は成功」用の新たなフィールド値＜Ｏｃｔｅｔ１４８＞が規定される。さらにここでは、フィールド値＜Ｏｃｔｅｔ１５２＞を「通知が送信されていたため変更は失敗」のために設定することが提案される。この符号化された値は、条件付き置換（通知前のみの変更）の事例１を実施しようとした送信アプリケーションＵＡＡに、通知が既に送信されていたのでＭＭ_Ａの更新を行うことができなかったということを伝える。この事例は、送信アプリケーションＵＡＡと受信アプリケーションＵＡＢが同一のネットワークエレメントＲＳ、すなわちネットワークエレメントＲＳＡに配属している場合に生じる可能性がある。さらに有利には別の新たなフィールド値が規定される：
「ダウンロード前、変更は成功」用の＜Ｏｃｔｅｔ１４９＞、及び
「ＭＭがダウンロードされていたので、変更は失敗」用の＜Ｏｃｔｅｔ１５３＞
後者の事例は、送信側が条件付き変更の事例２（ダウンロード前の変更）を要求した場合に生じる可能性がある。
【０１３３】
Ｂ．３ＷＡＰメッセージM-Notification.ind（ネットワークエレメントＲＳＢから受信アプリケーションＵＡＢ）
本発明によればＷＡＰメッセージM-Notification.indにおいて、有利には好適な名称X-Mms-Replaced-URI及び１６進数の符号化０ｘ８２（２進数：１３０）を有する新たなヘッダフィールドが補完される。このヘッダフィールドを用いて受信アプリケーションＵＡＢは、既に行われた通知の後に、ＭＭ_Ａを送信側が別のＵＲＩを有する新たなＭＭ_Ｂに置換したためこのＭＭ_Ａは示されているＵＲＩではもはやこれ以上ダウンロートに備えることができない、ということを伝える。この新たに規定されたヘッダフィールドのフィールド値は有利には、カプセル化規格（上記参照）にしたがいテキスト列として符号化される。受信アプリケーションＵＡＢに更新の時点を伝えるようにするために、本発明の有利な変形によれば章Ａ．３において新たに規定された、好適な名称X-Mms-Date-of-Executionを有するヘッダフィールドが補完される。
【０１３４】
変更すべき、例えば置換すべきＭＭ_Ａが既に受信アプリケーションＵＡＢに存在する場合には、有利にはＷＡＰメッセージM-Notification.ind内に章Ｂ．１において新たに規定された、好適な名称X-Mms-Replace-ID及び１６進数の符号化０ｘ８１（２進数：１２９）を有するヘッダフィールドが補完される。受信アプリケーションＵＡＢはダウンロードされるＭＭ_Ｂが相応のメッセージ識別番号を有するＭＭ_Ａについての変更命令を包含することを識別する。これに基づきＭＭ_Ｂのダウンロードをユーザの設定、ＭＭＳサービスプロバイダ及び／又はネットワークプロバイダの設定に応じて、ＰＵＳＨモードまたはＰＵＬＬモードにおいて開始することができる。
【０１３５】
言及したように、ＷＡＰメッセージM-Notification.indが受信アプリケーションＵＡＢに、ＭＭ_Ａを変更、例えば置換すべきメッセージＭＭ_Ｂの到来を伝える。条件付き変更のために受信アプリケーションＵＡＢには変更の条件が伝えられなければならない。このために有利には新たに規定された、１６進数の符号化０ｘ８７（２進数：１３５）を有するヘッダフィールドX-Mms-Replace-Condが使用される。この事例では符号化された値、ＭＭが未読であった場合にのみ変更用の＜Ｏｃｔｅｔ１３０＞及び（既読であっても）ＭＭの処理段階に依存しない変更用の＜Ｏｃｔｅｔ１３１＞だけが必要とされる。通知前のみの変更用の＜Ｏｃｔｅｔ１２８＞及び（通知の送信後でも）ダウンロード前のみの変更用の＜Ｏｃｔｅｔ１２９＞はここでは必要とされず、何故ならば両方の事例ではＭＭの変更は通知の送信前に行われるべきだったからである。ＭＭ_Ａを変更するための条件が充足されている場合には、ＭＭ_Ｂが受信アプリケーションＵＡＢに到来する前であってもこのＭＭを既に消去することができる。
【０１３６】
Ｂ．４ＷＡＰメッセージM-NotifyResp.ind（受信アプリケーションＵＡＢからネットワークエレメントＲＳＢ）
本発明によれば、ＷＡＰメッセージM-NotifyResp.ind内に、カプセル化規格（上記参照）において規定されたヘッダフィールドX-Mms-Statusが挿入されることが提案される。ネットワークエレメントＲＳには、送信側の変更ジョブがＰＵＳＨモードにおいて成功であったか否かについて伝えることができるので、ここでもまた（章Ａにおけるプロセス、サービスフィーチャ呼戻と同様に）このヘッダフィールドの拡張が必要である。フィードバックは本発明では有利には２つの新たなフィールド値、「変更ジョブの実施は成功した」用のフィールド値＜Ｏｃｔｅｔ１３４＞及び「変更ジョブを実施できなかった」用のフィールド値＜Ｏｃｔｅｔ１３５＞を用いて実現される。
【０１３７】
上記で提案したフィールド値＜Ｏｃｔｅｔ１３４＞及び＜Ｏｃｔｅｔ１３５＞並びに前述の「通知前の変更成功」用のフィールド値＜Ｏｃｔｅｔ１４８＞及び「通知が送信されていたため変更は失敗」用の＜Ｏｃｔｅｔ１５２＞に付加的に、以下のフィールド値が提案される：
−「ＭＭの既読以前の変更成功、」用の＜Ｏｃｔｅｔ１５０＞
−「ＭＭの既読以降の変更成功」用の＜Ｏｃｔｅｔ１５１＞
−「ＭＭが既読であったため変更失敗」用の＜Ｏｃｔｅｔ１５４＞
−「ＭＭが消去されていたため置換失敗」用の＜Ｏｃｔｅｔ１５５＞。
【０１３８】
これらを伝えることにより、変更命令の送信側に対してジョブの正確な結果に関して情報提供することができる。
【０１３９】
ＷＡＰメッセージM-Retrieve.conf（ネットワークエレメントＲＳＢから受信アプリケーションＵＡＢ）
変更すべきＭＭ_Ａを既にＭＭＳＥ_ＢにおいてＭＭ_Ｂに変更することができていた場合には、本発明によれば、ＭＭ_Ｂを受信アプリケーションＵＡＢに伝送するＷＡＰメッセージM-Retrieve.confに有利には、カプセル化規格（上記参照）において規定され拡張された、「変更成功」用のフィールド値＜Ｏｃｔｅｔ１３４＞を有するヘッダフィールドX-Mms-Status及び、章Ａ．３において新たに規定された好適な名称X-Mms-Date-of-Executionを有するヘッダフィールドが付加される。これによってネットワークエレメントＲＳＢは受信アプリケーションＵＡＢに、ＭＭ_Ｂは後に変更されたＭＭであり、送信側の変更ジョブがＭＭＳＥ_Ｂの管轄領域において何時実施されたかということを伝えることができる。
【０１４０】
変更すべきＭＭ_Ａが既に受信アプリケーションＵＡＢに存在する場合には、本発明によれば有利には、ＷＡＰメッセージM-Retrieve.conf内に同様に、章Ｂ．１において規定された名称X-Mms-Replace-IDを有するヘッダフィールドが補完される。受信アプリケーションＵＡＢが変更サービスフィーチャをサポートする場合には、このヘッダフィールドでもってＭＭ_Ａの変更を受信アプリケーションＵＡＢにおいてメッセージＩＤを用いることにより開始することができる（図２を参照されたい）。これによって他方では受信側に、送信側がＭＭ_Ａの新たなＭＭ_Ｂへの変更を欲したということのみが示される。
【０１４１】
条件付き変更の場合には、上記で新たに規定されたヘッダフィールドX-Mms-Replace-Condが有利にはこのメッセージに付加されることが提案される。「ＭＭが未読であった場合のみ置換」用のフィールド値＜Ｏｃｔｅｔ１３０＞及び既読であっても「ＭＭの処理段階に依存しない置換」用のフィールド値＜Ｏｃｔｅｔ１３１＞を使用することができる。したがって受信アプリケーションＵＡＢには、いかなる場合に古いＭＭが置換されるべきかが伝えられる。
【０１４２】
Ｂ．６ＷＡＰメッセージM-Acknowledge.ind（受信アプリケーションＵＡＢからネットワークエレメントＲＳＢ）
本発明によれば有利な構成では、ＷＡＰメッセージM-Acknowledge.ind内に、カプセル化規格（上記参照）において規定されたヘッダフィールドX-Mms-Statusが付加されることが提案される。ネットワークエレメントＲＳには、送信側の変更ジョブがＰＵＬＬモードにおいて成功することができたか否かを伝えることができるので、ここでもまた（章Ａにおけるプロセス、サービスフィーチャ呼戻と同様に）このヘッダフィールドの拡張が必要である。フィードバックは本発明によれば有利には、２つの新たなフィールド値「変更ジョブは成功した」用の＜Ｏｃｔｅｔ１３４＞及び「変更ジョブは実施できなかった」用の＜Ｏｃｔｅｔ１３５＞を用いて実現される。
【０１４３】
さらにフィールド値＜Ｏｃｔｅｔ１４９＞、＜Ｏｃｔｅｔ１５０＞、＜Ｏｃｔｅｔ１５１＞、＜Ｏｃｔｅｔ１５３＞、＜Ｏｃｔｅｔ１５４＞及び「＜Ｏｃｔｅｔ１５５＞を使用することができる（上記参照）。
【０１４４】
Ｂ．７ＷＡＰメッセージM-Delivery.ind（ネットワークエレメントＲＳＡから送信アプリケーションＵＡＡ）
さらに、章Ｂ．４ないしＢ．６において拡張されたヘッダフィールドX-Mms-Statusをここでもまた付加することが提案される。このヘッダフィールドを用いて送信側（送信アプリケーションＵＡＡ）には、ここで上述の新たなフィールド値が使用される場合であっても、変更ジョブを成功することができたか否かを伝えることができ、この場合には上述の値の一部または全てが生じる可能性がある。さらに送信側に対して、有利には変更ジョブの実施日時に関して、章Ａ．３において規定された好適な名称X-Mms-Date-of-Executionを有するヘッダフィールドを用いて伝えることができる。
【０１４５】
条件付き変更命令の送信側に変更ジョブの実施を伝える別の可能性は、本発明によれば相応のＷＡＰメッセージにおいて使用される新たなヘッダフィールドを規定することによって実現される。このために、例えば名称X-Mms-Replace-Statusを有するヘッダフィールドが提案される。このヘッダフィールドを上述の事例においては、拡張されたヘッダフィールドX-Mms-Statusの代替として使用することができる。後者をさらに、WAP-209-MMSEncapsulation,Release2000（上記参照）において規定された形式で使用することができる。新たなヘッダフィールドは有利には変更ジョブを実施するための情報のみを包含する。X-Mms-Replace-Statusに対しては１６進数の符号化０ｘ８９（２進数：１３７）が提案される。種々の実施シナリオをカバーする可能なフィールド値は例えば以下のものである：
−「変更成功」用の＜Ｏｃｔｅｔ１２８＞
−「通知前に変更成功」用の＜Ｏｃｔｅｔ１２９＞
−「ダウンロード前に変更成功」用の＜Ｏｃｔｅｔ１３０＞
−「ＭＭの既読以前の変更成功」用の＜Ｏｃｔｅｔ１３１＞
−「ＭＭの既読以降の変更成功」用の＜Ｏｃｔｅｔ１３２＞
−「変更失敗」用の＜Ｏｃｔｅｔ１３３＞
−「通知が送信されていたため変更失敗」用の＜Ｏｃｔｅｔ１３４＞
−「ＭＭがダウンロードされていたため変更失敗」用の＜Ｏｃｔｅｔ１３５＞
−「ＭＭは既読であったため変更失敗」用の＜Ｏｃｔｅｔ１３６＞
−「メッセージが消去されていたため変更失敗」用の＜Ｏｃｔｅｔ１３７＞
−「変更失敗、メッセージは発見されなかった」用の＜Ｏｃｔｅｔ１３８＞
−「変更失敗、メッセージは転送された」用の＜Ｏｃｔｅｔ１３９＞。
【０１４６】
別の理由または条件ではフィールド値及び符号化を相応に補完することができる。
【０１４７】
本発明によれば、上記のヘッダフィールドX-Mms-Replace-Statusと共にX-Mms-Replace-Statusについての別の択一形態は、変更命令及び呼戻命令を実施するためのフィードバックに使用することができる新たなヘッダフィールドである。このために、例示的な名称X-Mms-Operation-Statusを有するヘッダフィールドが提案される。このヘッダフィールドを１６進数の符号化０ｘ９０（２進数：１３８）を有することができ、以下のフィールド値も有する：
−「オペレーション成功」用の＜Ｏｃｔｅｔ１２８＞
−「通知前にオペレーション成功」用の＜Ｏｃｔｅｔ１２９＞
−「ダウンロード前にオペレーション成功」用の＜Ｏｃｔｅｔ１３０＞
−「ＭＭの既読以前のオペレーション成功」用の＜Ｏｃｔｅｔ１３１＞
−「ＭＭの既読以降のオペレーション成功」用の＜Ｏｃｔｅｔ１３２＞
−「オペレーション失敗」用の＜Ｏｃｔｅｔ１３３＞
−「通知が送信されていたためオペレーション失敗」用の＜Ｏｃｔｅｔ１３４＞
−「ＭＭがダウンロードされていたためオペレーション失敗」用の＜Ｏｃｔｅｔ１３５＞
−「ＭＭが既読であったためオペレーション失敗」用の＜Ｏｃｔｅｔ１３６＞
−「メッセージが消去されていたためオペレーション失敗」用の＜Ｏｃｔｅｔ１３７＞
−「オペレーション失敗、メッセージは発見されなかった」用の＜Ｏｃｔｅｔ１３８＞
−「オペレーション失敗、メッセージは転送された」用の＜Ｏｃｔｅｔ１３９＞。
【０１４８】
図５はもう一度、フィールド名及びフィールド値の符号化を包含する有利には新たに挿入される７つのヘッダフィールドを示す。図６には、新たなフィールド値によって拡張されたヘッダフィールドX-Mms-Statusが示されている。図７及び８には択一的な実現可能性のヘッダフィールド（実施例３及び４、上記参照）が示されている。相応のＷＡＰメッセージのヘッダフィールドにおける相応の補完は、説明の最後において表２から８にリスト化されている。個々の補完だけがこのヘッダフィールドにおいて行われることも勿論可能である。
【０１４９】
条件付き操作の事例に関して、図９は、フィールド名及びフィールド値の符号化を包含する新たに挿入されたヘッダフィールドX-Mms-Recall-Cond、X-Mms-Replace-Cond、X-Mms-Recall-Status、X-Mms-Replace-Status及びX-Mms-Operation-Statusを示す。図１０には、新たなフィールド値によって拡張されたヘッダフィールドX-Mms-Supported-Featureが示されている。図６に示したヘッダフィールドX-Mms-Statusは同様に、条件付き操作に関する新たなフィールド値を包含する。
【０１５０】
Ｃ．２進符号化
Ｃ．１呼戻ないし変更についての条件は無い場合
以下の実施例ではＷＡＰメッセージにおいて使用されるヘッダフィールドについて詳細に検討し、ここでは差し当たり最初のメッセージの呼戻ないし変更に対する条件は設けられていない。ここでは例示的に以下のシナリオが前提とされる：
送信アプリケーションＵＡＡはテキスト及びＪＰＥＧ画像から成るＭＭ_Ａを受信側に送信し、このＭＭ_Ａを後に呼び戻そうとする（例１）、ないし新たなＭＭ_Ｂと置換しようとする（例２）。
【０１５１】
M-Send.req（送信アプリケーションＵＡＡ→ネットワークエレメントＲＳＡ）：
【０１５２】
【数１】

【０１５３】
アドレスabc@siemens.deを持つユーザの送信アプリケーションＵＡＡは、テキスト（MIME content type"text/plain"）及びＪＰＥＧ画像（MIME content type"image/jpeg"）から成るＭＭ_Ａを、アドレスxyz@siemens.deを持つユーザの受信アプリケーションＵＡＢに送信する。このために使用されるＷＡＰメッセージM-Send.reqは例えばトランザクション識別番号ＩＤ１０を有する。ネットワークエレメントＲＳＡはこれに基づき、送信されたＭＭ_Ａに対して個別の識別番号を設定し、ＷＡＰメッセージM-Send.confを用いてＷＡＰメッセージM-Send.reqが誤りなくネットワークエレメントＲＳＡに伝送されたことを確認する。
【０１５４】
M-Send.conf（ネットワークエレメントＲＳＡ→送信アプリケーションＵＡＡ）：
【０１５５】
【数２】

【０１５６】
２つのＷＡＰメッセージM-Send.req及びM-Send.confにおいては同一のトランザクション識別番号（トランザクションＩＤ）が使用される。したがって、送信アプリケーションＵＡＡにおいてメッセージ識別番号を有するＷＡＰメッセージM-Send.confを一義的に所属のＷＡＰメッセージM-Send.reqに対応付けることができ、これによって別個の識別番号AAAA.1111@mms-relay01.siemens.deを送信されたＭＭ_Ａに対応付けることができる。ネットワークエレメントＲＳＡはＭＭ_Ａに対して、この例ではインタフェース送信アプリケーションＵＡＡ／ネットワークエレメントＲＳＡに対して別個の識別番号AAAA.1111@mms-relay01.siemens.deを設定している。この識別番号はヘッダフィールドMessage-IDにある。
【０１５７】
例１：呼戻（条件無し）
ＭＭ_Ａの送信側は、このＭＭ_Ａを（２時間後に）再び呼び戻そうとする。このことは、本発明によれば呼び戻されるべきＭＭ_Ａを送信した受信側と同一の受信側に送信される新たなＭＭ_Ｂを用いて行われる。この状況では、有利にはＷＡＰメッセージM-Send.reqにおいて、本発明により新たに規定された好適な名称X-Mms-Recall-IDを有するヘッダフィールドが使用され、このヘッダフィールドに呼び戻されるべきＭＭ_ＡのMessage-IDが登録される（図２におけるＩＤ１）。さらにＷＡＰメッセージM-Send.reqは有利には、本発明により新たに規定された好適な名称X-Mms-Request-Reportを有するヘッダフィールドを包含し、このヘッダフィールドを用いて、与えられた呼戻ジョブに関するフィードバックを要求することができる。ＷＡＰメッセージM-Send.reqには、呼戻ジョブの場合有利にはヘッダフィールドのみが包含されており、別のマルチメディア内容（"Message-Body"）は包含されていない。下記のように、新たに規定されたヘッダフィールドは縁で囲まれている。
【０１５８】
M-Send.req（送信アプリケーションＵＡＡ→ネットワークエレメントＲＳＡ）：
【０１５９】
【数３】

【０１６０】
ＭＭ_Ｂにおける呼戻命令を有するＷＡＰメッセージM-Send.reqの受信側に対しても、有利にはネットワークエレメントＲＳＡは即座にＷＡＰメッセージM-Send.confでもって応答する。このＷＡＰメッセージM-Send.confにはネットワークエレメントＲＳＡによって設定されたＭＭ_Ｂのためのメッセージ識別番号（ここではAAAA.2222@mms-relay01.siemens.de）が包含されている。さらにこのＷＡＰメッセージM-Send.confは有利には、本発明により新たに規定されたヘッダフィールドX-Mms-Supported-Featureを包含し、このヘッダフィールドを用いて送信アプリケーションＵＡＡに対してサービスプロバイダＡは呼戻サービスフィーチャをサポートしているか否かを示すことができる（ここでは示している）。
【０１６１】
M-Send.conf（ネットワークエレメントＲＳＡ→送信アプリケーションＵＡＡ）：
【０１６２】
【数４】

【０１６３】
受信側（ネットワークエレメントＲＳＢと受信アプリケーションＵＡＢとの間のインタフェース）においてＷＡＰメッセージを交換する場合には、受信アプリケーションＵＡＢは、
１．到来したＭＭについてまだ伝えられていなかったか、または
２．確かに伝えられてはいたが、ＭＭはまだ取り出されていないか、または
３．ＭＭを既に得ているか、
を区別する必要がある。
【０１６４】
第１及び第２の事例ではＭＭ_Ａ、また呼戻命令を包含するＭＭ_ＢもサービスプロバイダＢの管轄領域（ＭＭＳＥ_Ｂ）において消去することができる。第１の事例では受信側はこのことを一度も知る必要はない。これに対して第２の事例では受信アプリケーションＵＡＢに対してサービスプロバイダＢは有利には、送信側がＭＭ_Ａを後に呼び戻す場合には、このＭＭ_Ａはもはやこれ以上ダウンロードに備えていないということを伝えることが望ましい。このために本発明によればＷＡＰメッセージM-Notification.indを使用することができる。
【０１６５】
第２の事例：M-Notification.ind（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０１６６】
【数５】

【０１６７】
ＷＡＰメッセージM-Notification.indにおいては、呼び戻されるＭＭ_Ａを識別するためにＵＲＩだけを使用することができる。何故ならばネットワークエレメントＲＳはこの時点では呼び戻されるＭＭ_Ａに対して「Message-ID」をまだ設定していないからである（このことはダウンロードでもって初めて行われる）。ヘッダフィールドX-Mms-Recalled-URI及びX-Mms-Date-of-Executionはこの呼戻通知を「従来の」通知と区別する。ヘッダフィールドX-Mms-Content-Locationはこの場合ＵＲＩを示し、このＵＲＩの記憶スペースには有利にはサービスプロバイダＢの標準テキストメッセージ（例えば：「ＭＭは送信側によって再び消去された」）が存在する。したがって、呼戻サービスフィーチャの新たなヘッダフィールドを理解しない送信アプリケーション及び／又は受信アプリケーションに対しても、実施された呼戻ジョブを後に伝えることができる。
【０１６８】
ＷＡＰメッセージM-NotifyResp.reqでもって、ＷＡＰメッセージM-Notification.indは適切に受信されたことが確認される。ヘッダフィールドX-Mms-Statusはこの例では、本発明により新たに規定されたエントリのうちの１つ（すなわち「recall feature supported」）を持ち、このエントリでもってネットワークエレメントＲＳＢは受信アプリケーションＵＡＢが呼戻に関する情報を有する第２の通知を理解したことを知ることができる。
【０１６９】
（さらに）第２の事例：M-NotifyResp.req（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０１７０】
【数６】

【０１７１】
しかしながら消去されるべきＭＭ_Ａが既に受信アプリケーションＵＡＢに伝送されていた場合（第３の事例）には、有利にはＷＡＰメッセージM-Notification.indは好適に、既に行われた呼戻に関する通知ではなく呼戻命令自体を包含し、しかも呼び戻されるべきＭＭ_Ａの識別番号が登録される好適な名称X-Mms-Recall-IDを有するヘッダフィールドの形式で包含する。ここでは有利には識別番号が使用される（ＵＲＩは使用されない）。何故ならば識別番号は（ここでは既述の第３の事例において）事前に行われたダウンロード後にネットワークエレメントＲＳＢにも受信アプリケーションＵＡＢにも既知だからである。
【０１７２】
第３の事例：M-Notification.ind（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０１７３】
【数７】

【０１７４】
ヘッダフィールドX-Mms-Content-Locationはこの例ではＵＲＩを示し、このＵＲＩの記憶スペースにはサービスプロバイダＢの標準テキストメッセージ（例えば：「送信側はメッセージＩＤBBBB.3333@mms-relay02.siemens.deを有するＭＭの呼戻を欲している」）が設けられている。したがって、呼戻サービスフィーチャの新たなヘッダフィールドを理解しない送信アプリケーション及び／又は受信アプリケーションには、送信側によって送信された呼戻ジョブを後に伝えることができる。
【０１７５】
ＭＭ_Ａはこのインタフェースにおいて別の「メッセージＩＤ」を持てることを強調するために、この実施例では値BBBB.3333@mms-relay02.siemens.deが選択された（図２におけるＭＭ_ＡのＩＤ２に相応）。
【０１７６】
（さらに）第３の事例：M-NotifyResp.req（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）
【０１７７】
【数８】

【０１７８】
受信アプリケーションＵＡＢはこの実施例ではＷＡＰメッセージM-NotifyResp.reqを用いてフィードバックをネットワークエレメントＲＳＢに送り返す。このために有利には、カプセル化規格（上記参照）により本発明において拡張されたヘッダフィールドX-Mms-Statusが使用される。この実施例においてはＭＭ_Ａを受信アプリケーションＵＡＢにおいて消去することができ、このことはフィールド値「呼戻成功」でもって表される。ネットワークエレメントＲＳＢにおいてはＷＡＰメッセージの組トランザクションＩＤ（ここでは：２５）が、消去されたＭＭ_Ａのメッセージ識別番号（ここでは：BBBB.3333@mms-relay02.siemens.de）を推量することができる。これによって、フィードバックの作成が送信側によって所望され且つサービスプロバイダＢによってサポートされる場合には、フィードバックを作成することができる。
【０１７９】
M-Delivery.ind（ネットワークエレメントＲＳＡ→送信アプリケーションＵＡＡ）：
【０１８０】
【数９】

【０１８１】
送信側が自身によって開始した呼戻ジョブについてのフィードバックを所望した場合には、ＭＭＳリレー／サーバＡはＷＡＰメッセージM-Delivery.indを用いてフィードバックを送信アプリケーションＵＡＡに送り返すことができる。フィールド「Message-ID」には呼戻ジョブの識別番号がある。ここで呼戻のステータスには同様に有利には拡張されたヘッダフィールドX-Mms-Statusが使用され、このヘッダフィールドにおいて、ＭＭ_Ａの消去は成功したことがフィールド値「recall-successful」でもって確認される。送信アプリケーションＵＡＡには、呼戻ジョブのメッセージ識別番号と、呼び戻されるべきＭＭ_Ａのメッセージ識別番号との関係が既知であるので、（関与するＭＭＳサービスプロバイダがこれをサポートする場合には）送信側も呼戻ジョブを行うことができたか否かを伝えることができる。
【０１８２】
例２：変更（条件無し）
この例では送信側がＭＭ_Ａを（送信から１時間後に）更新しようとする。本来的に送信された２つのエレメントのうちＪＰＥＧ画像（MIME content type"image/jpeg"）のみが包含されたままであるとする。さらに件名「会議の議題」が変更されるものとする。
【０１８３】
本発明によれば新たなＭＭ_Ｂが、変更ないし置換されるべきＭＭ_Ａを以前に送信した受信側と同一の受信側に送信される。このために有利には、本発明により新たに規定された好適な名称X-Mms-Replace-IDを有するヘッダフィールドが使用され、このヘッダフィールドにＭＭ_Ａの「Message-ID」が記録される。さらに有利には、ＷＡＰメッセージM-Send.reqが、同様に本発明により新たに規定された好適な名称X-Mms-Request-Reportを有するヘッダフィールドを包含し、与えられた変更ジョブに関するフィードバックをこのヘッダフィールドを用いて（この例において示されているように）要求することができる。
【０１８４】
M-Send.req（送信アプリケーションＵＡＡ→ネットワークエレメントＲＳＡ）：
【０１８５】
【数１０】

【０１８６】
変更命令を有するＭＭ_Ｂを備えたこのＷＡＰメッセージM-Send.reqの受信側にも、有利にはネットワークエレメントＲＳＡは即座にＷＡＰメッセージM-Send.confでもって応答する。このＷＡＰメッセージには好適には、ネットワークエレメントＲＳＡによって設定されたＭＭ_Ｂのメッセージ識別番号（Message-ID）（ここでは：AAAA.5555@mms-relay01.siemens.de）及び同様に本発明により新たに規定されたヘッダフィールドX-Mms-Supported-Featureが包含されており、このヘッダフィールドを用いて送信アプリケーションＵＡＡにはサービスプロバイダＡが変更サービスフィーチャをサポートしているか否かを示すことができる。２つのＷＡＰメッセージはこの例ではトランザクション識別番号ＩＤＤ３２を有する。
【０１８７】
M-Send.conf（ネットワークエレメントＲＳＡ→送信アプリケーションＵＡＡ）：
【０１８８】
【数１１】

【０１８９】
受信側（ネットワークエレメントＲＳＢと受信アプリケーションＵＡＢとの間のインタフェース）においてＷＡＰメッセージを交換する際には、受信アプリケーションＵＡＢが、
１．到来したＭＭについてまだ伝えられていなかったか、または
２．確かに伝えられてはいたが、ＭＭをまだ取り出していないか、または
３．ＭＭを既に得ているか、
を区別する必要がある。
【０１９０】
第１及び第２の事例においては、ＭＭ_ＡをサービスプロバイダＢの管轄領域（ＭＭＳＥ_Ｂ）においてＭＭ_Ｂに変更、例えば置換することができる。本発明では、受信側は第１の事例において通知の際にもダウンロードの際にも、これが後に変更、例えば置換されたＭＭであり、変更ジョブが何時実施されたかを知ることができる。有利には第２の事例においては、サービスプロバイダＢが受信アプリケーションＵＡＢに対して、ＭＭＳＥ_Ｂにおける変更ジョブの実施直後に、送信側はＭＭ_Ａを新たなＭＭ_Ｂに更新したこと、またこの更新が何時行われたかについて伝えることができる。本発明によれば、この通知は有利にはＷＡＰメッセージM-Notification.indを用いて行われるべきであり、このＷＡＰメッセージにおいては変更、例えば置換されたＭＭ_Ａを識別するためにＵＲＩのみを使用することができる。何故ならばネットワークエレメントＲＳＢはこの時点ではＭＭ_Ａに対してメッセージ識別番号（"Message-ID"）をまだ設定していないからである（このことはＭＭ_Ａのダウンロードでもって初めて行われる）。ヘッダフィールドX-Mms-Replaced-URI及びX-Mms-Date-of-Executionはこの呼戻通知を「従来の」通知と区別する。ヘッダフィールドX-Mms-Content-Locationは、サーバにおいて目下の内容を有するＭＭ_Ｂを何処で発見できるかを表示する。
【０１９１】
第２の事例：M-Notification.ind（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０１９２】
【数１２】

【０１９３】
ＷＡＰメッセージM-NotifyResp.reqを用いて有利にはＷＡＰメッセージM-Notification.indを適切に受信したことが受信アプリケーションＵＡＢによって確認される、図２を参照されたい。ヘッダフィールドX-Mms-Statusはこの例では本発明により新たに規定されたエントリ（すなわち「replace feature supported」）を有し、このエントリでもってネットワークエレメントＲＳＢには、受信アプリケーションＵＡＢは変更ジョブが実施されたことに関する情報を有する第２のメッセージを理解したことが知らされる。
【０１９４】
（さらに）第２の事例：M-NotifyResp.req（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０１９５】
【数１３】

【０１９６】
しかしながら変更されるべきＭＭ_Ａが既に受信アプリケーションＵＡＢに伝送されていた場合（第３の事例）には、本発明によればＷＡＰメッセージM-Notification.indが有利には、既に行われた変更に関する通知ではなく変更命令自体を包含し、しかも変更、例えば置換すべきＭＭ_Ａの識別番号が登録される好適な名称X-Mms-Replace-IDを有するヘッダフィールドの形式で包含する。これに基づき受信アプリケーションＵＡＢによってＭＭ_ＢのダウンロードをＰＵＳＨモードまたはＰＵＬＬモードにおいてWSP GET命令を用いることにより開始することができる。ヘッダフィールドX-Mms-Content-Locationはこの例ではＵＲＩを示し、このＵＲＩのメモリスペースにはサービスプロバイダＢの標準テキストメッセージ（例えば：「送信側はメッセージＩＤ BBBB.3333@mms-relay02.siemens.deを有するＭＭ_Ａを後に変更しようとする」）が存在する。したがって、呼戻サービスフィーチャの新たなヘッダフィールドを理解しない受信アプリケーションにも、送信側によって送信された変更ジョブについて後に伝えることができる。
【０１９７】
第３の事例：M-Notification.ind（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０１９８】
【数１４】

【０１９９】
ＵＲＩをネットワークエレメントＲＳＢに送信するWSP GET命令についての応答として、受信アプリケーションＵＡＢは、ＷＡＰメッセージM-Retrieve.confにおいてＭＭ_Ａを変更ないし置換するための変更されたタイトル及び変更されたマルチメディア内容（ＪＰＥＧ画像）を有するＭＭ_Ｂを受け取る。ＷＡＰメッセージM-Retrieve.confにおいても有利には、好適な名称X-Mms-Replace-IDを有するヘッダフィールドが補完される。したがって、受信アプリケーションＵＡＢが変更サービスフィーチャをサポートする場合には、直接的に受信アプリケーションＵＡＢにおいてＭＭ_ＡをＭＭ_Ｂに変更、例えば置換することができる。選択された配送モードに依存して、ＷＡＰメッセージM-Retrieve.confにおいては、トランザクション識別番号がＷＡＰメッセージM-Notification.indから引き継がれるか（ＰＵＳＨモード）、新たなトランザクション識別番号が設定される（ＰＵＬＬモード）。
【０２００】
（さらに）第３の事例：M-Retrieve.conf（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０２０１】
【数１５】

【０２０２】
ＭＭ_Ａがこのインタフェースにおいて他のメッセージ識別番号（「Message-ID」）を有せることを強調するために、この実施例においては値としてBBBB.3333@mms-relay02.siemens.deが選択された（図２のＩＤ２に相応）。
【０２０３】
ＭＭ_ＢがＰＵＬＬモードで配送される場合：
第３の事例：M-Acknowledge.ind（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０２０４】
【数１６】

【０２０５】
ＭＭ_Ｂの配送がＰＵＬＬモードで行われると、受信アプリケーションＵＡＢは有利にはＷＡＰメッセージM-Acknowledge.indを用いてフィードバックをネットワークエレメントＲＳＢに送り返す。このために本発明により拡張されたヘッダフィールドX-Mms-Statusが使用される。この実施例においては、ＭＭ_Ａを受信アプリケーションＵＡＢにおいて新たなＭＭ_Ｂに置換することができており、このことはフィールド値「replace successful」でもって表される。ネットワークエレメントＲＳＢにおいては、ＷＡＰメッセージの組M-Retrieve.conf及びM-Acknowledge.indのトランザクションＩＤ（Transaction-ID）（ここでは：４８）から、置換されたＭＭ_ＡのメッセージＩＤ（ここでは：BBBB.3333@mms-relay02.siemens.de）を推測することができる。これによって、送信側によってフィードバックの作成が要求され且つサービスプロバイダＢによってサポートされる場合には、このフィードバックの作成が可能である。
【０２０６】
ＭＭ_ＢがＰＵＳＨモードで配送される場合：
第３の事例：M-NotifyResp.req（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０２０７】
【数１７】

【０２０８】
ＭＭ_Ｂの配送がＰＵＳＨモードで行われる場合には、受信アプリケーションＵＡＢはＭＭ_Ｂを適切に受信したことを、有利にはＷＡＰメッセージM-NotifyResp.reqを用いて確認する。このために有利には本発明において拡張されたヘッダフィールドX-Mms-Statusが使用される。この実施例においてはＭＭ_Ａを受信アプリケーションＵＡＢにおいて新たなＭＭ_Ｂに置換することができており、このことはフィールド値「replace successful」でもって表される。ネットワークエレメントＲＳＢにおいては、３つのＷＡＰメッセージM-Notification.ind、M-Retrieve.conf及びM-NotifyResp.reqのトランザクションＩＤ（ここでは：３８）から、置換されたＭＭ_ＡのメッセージＩＤ（ここでは：BBBB.3333@mms-relay02.siemens.de）を推測することができる。これによって、送信側によってフィードバックの作成が要求され且つサービスプロバイダＢによってサポートされる場合には、このフィードバックの作成が可能となる。
【０２０９】
M-Delivery.ind（ネットワークエレメントＲＳＡ→送信アプリケーションＵＡＡ）：
【０２１０】
【数１８】

【０２１１】
ネットワークエレメントＲＳＡはＷＡＰメッセージM-Delivery.indを用いてフィードバックを送信アプリケーションＵＡＡに送り返すことができる。このフィールドMessage-IDには変更ジョブのＩＤが存在する。ここでは有利には変更ジョブのステータスに関しては同様に、拡張されたヘッダフィールドX-Mms-Statusが使用され、このヘッダフィールドにおいてＭＭ_ＡのＭＭ_Ｂへの変更の成功がフィールド値「replace successful」でもって確認される。送信アプリケーションＵＡＡには変更ジョブのメッセージＩＤと呼び戻されるべきＭＭ_ＡのメッセージＩＤとの関係が既知であるので、（関与するサービスプロバイダがこれをサポートする場合には）送信側には変更ジョブを実施することができたか否かを伝えることができる。
【０２１２】
例３：ステータス情報を伝送するための択一形態（条件無し）
前述した２つの実施例においては、ＷＡＰメッセージM-NotifyResp.ind（ＰＵＳＨモード）またはM-Acknowledge.ind（ＰＵＬＬモード）を用いる受信アプリケーションＵＡＢから（サービスプロバイダＢにおける）ネットワークエレメントＲＳＢへ、与えられた呼戻ジョブないし変更ジョブの結果に関するフィードバックが伝送される、ないしＷＡＰメッセージM-Delivery.indを用いるネットワークエレメントＲＳＡから（サービスプロバイダＡにおける）送信アプリケーションＵＡＡへ、与えられた呼戻ジョブないし変更ジョブの結果に関するフィードバックが伝送される。このために新たなフィールド値がヘッダフィールドX-Mms-Statusに挿入された。このプロセスは確かに効果的であるが、ヘッダフィールドX-Mms-Statusを従来のように使用することには完全には応じていない。したがって以下では、フィードバックを伝送するための択一的な実施例を説明する。ここで呼戻ジョブないし変更ジョブの送信ないし実施は、例１及び例２において記述したように好適には変更されないままである。
【０２１３】
この択一形態でもって、（カプセル化規格（上記参照）において本来的に予定されているものと同様の）ヘッダフィールドX-Mms-Statusはさらには、送信側に最後に送信されたＭＭ（すなわち呼戻ジョブまたは変更ジョブに包含されているＭＭ）の状態を伝えることに専ら使用され、（実施例１及び２において説明したように）呼戻ジョブまたは変更ジョブの結果を伝えることには使用されない。したがってこの事例に関しては、送信側が呼戻ジョブまたは変更ジョブの結果に関して知ることができる別のヘッダフィールドが規定される。この新しいヘッダフィールドにX-Mms-Original-Message-Statusという名称を設け、１６進数の符号化０ｘ８６（２進数：１３４）を付すことが提案される。さらに、フィールド値として、例えば「ＭＭの呼戻は成功した」用の＜Ｏｃｔｅｔ１２８＞、「ＭＭの呼戻は失敗している」用の＜Ｏｃｔｅｔ１２９＞、「ＭＭの変更ないし置換は成功した」用の＜Ｏｃｔｅｔ１３０＞及び「ＭＭの変更ないし置換は失敗している」用の＜Ｏｃｔｅｔ１３１＞が使用される。図７はこの択一形態において表されるヘッダフィールドを示す。
【０２１４】
例４：フィードバックを伝送するための択一形態（条件無し）
例１及び例２においては、フィードバックに関連するＭＭ_Ａが呼戻ジョブないし変更ジョブの結果に関してＭＭ_ＢのメッセージＩＤ及びＷＡＰメッセージM-NotifyResp.indまたはM-Acknowledge.indにおけるトランザクションＩＤに基づいて識別された。
【０２１５】
呼び戻されたまたは変更、例えば置換されたＭＭ_ＡのメッセージＩＤを直接ＷＡＰメッセージM-NotifyResp.indまたはM-Acknowledgement.indを用いて（サービスプロバイダＢへ）、ないしM-Delivery.indを用いて（サービスプロバイダＡから）伝送することも考えられる。このために、例えば好適な名称X-Mms-Original-Message-IDを持つ新たなヘッダフィールドを挿入し、１６進数の符号化０ｘ８７（２進数：１３５）を付すことが提案される。この新たなヘッダフィールドのフィールド値は有利にはオリジナルＭＭ_ＡのメッセージＩＤを包含し、カプセル化規格（上記参照）によりテキスト列として符号化される。図８はこの択一形態において表されるヘッダフィールドである。
【０２１６】
Ｃ．２呼戻ないし変更について条件付きである場合
以下の実施例においては、最初のメッセージの条件付き呼戻ないし変更のためのＷＡＰメッセージにおいて使用されるヘッダフィールドを詳細に検討する。ここでは一例として以下のシナリオを想定する。すなわち、ＭＭＳＶＡＳアプリケーションＡはＭＭ_Ａを受信側に送信し、このＭＭ_Ａを後に呼び戻そうとする（例５）ないしＭＭ_Ｂに置換しようとする（例６）。
【０２１７】
ＷＡＰメッセージM-Send.conf内には送信されたＭＭ_Ａには別個の識別番号（AAAA.1111@mms-relay01.siemens.de）が割り当てられる。このメッセージＩＤ１（「Message-ID 1」）は、呼戻及び置換の際にＭＭ_Ａを識別するために使用される、上記参照、Report of the 3GPPP TSG-T2 SWG3 MMS。
【０２１８】
例５：条件付き呼戻
ＭＭ_Ａの送信側がこのＭＭ_Ａを（２時間後に）再び呼び戻そうとする。このことは呼び戻されるべきＭＭ_Ａを送信した受信側と同一の受信側に送信される新たなＭＭ_Ｂを用いて行われる。この時点では、ＷＡＰメッセージM-Send.reqには有利には、呼び戻されるべきＭＭ_Ａの相応のメッセージＩＤを有するヘッダフィールドX-Mms-Recall-IDが使用される、例１を参照されたい。それに加えここでは、与えられた呼戻ジョブに関するフィードバックがヘッダフィールドX-Mms-Request-Reportを用いて要求される。本発明により新たに規定された、名称X-Mms-Recall-Condを有するヘッダフィールドはＷＡＰメッセージM-Send.reqにおいて使用される。この例におけるフィールド値は＜Ｏｃｔｅｔ１３０＞とする。この値はメッセージが送信されたか否か、またはＭＭが既にダウンロードされたか否かには依存せずに、ＭＭ_Ａが未読であった場合にのみ呼戻を実現する送信側の希望に相応する。
【０２１９】
M-Send.req（ＭＭＳＶＡＳアプリケーションＡ→ネットワークエレメントＲＳＡ）：
【０２２０】
【数１９】

【０２２１】
この場合、ネットワークエレメントＲＳＡは、消去すべきＭＭが別のネットワークエレ
メントＲＳＢへ転送されたことを確認するものとする。ここではＭＭ_Ｂにおいて呼戻命令を含むＷＡＰメッセージM-Send.reqを受信したことが、ネットワークエレメントＲＳＡによりＷＡＰメッセージM-Send.confによって確認応答される（図２も参照）。これにはネットワークエレメントＲＳにより与えられたＭＭ_Ｂに対するメッセージＩＤ（ここではAAAA.2222@mms-relay01.siemens.de）が含まれている。さらにヘッダフィールドX-Mms-Supported-Featureには、本発明において新たに定義されたエントリ「条件付き呼戻フィーチャサポート」が含まれている。
【０２２２】
M-Send.conf（ネットワークエレメントＲＳＡ→ＭＭＳＶＡＳアプリケーションＡ）：
【０２２３】
【数２０】

【０２２４】
ここでは、受信アプリケーションＵＡＢに対し通知が行われこれによりＭＭが呼び出されたことをネットワークエレメントＲＳＢが確認したものとする。呼戻の条件をまだ満たすことができる状態にあるため（ＭＭはまだ未開封／未読）、呼戻ジョブの実行がさらに試される。その際、受信アプリケーションＵＡＢに対しＷＡＰメッセージM-Notification.indにより、メッセージＭＭ_Ａがまだ未読であったならば事前にダウンロードされたメッセージＭＭ_Ａが呼び戻されることが通知される。この条件はやはりヘッダフィールドX-Mms-Recall-condにより通知され、これは（未読時のみ呼び戻されることに対する）フィールド値＜Octet130＞をもつ。
【０２２５】
メッセージＭＭ_Ａの識別はここでも識別番号により行われる。しかしこの識別は他のネットワークエレメントＲＳへの転送ゆえにメッセージＩＤ１（AAAA.1111@mms-relay01.simenes.de）とは区別される（上述のWAP-209-MMSEncapsulation, Release 2000参照）。したがってこの実施例では別のメッセージＩＤ BBBB.3333@mms-relayu02.siemens.deが採用される。
【０２２６】
この例ではX-Mms-Content-Locationのヘッダフィールドは、サービスプロバイダＢの標準テキストメッセージ（たとえば「送信側はメッセージＩＤ BBBB.3333@mms-relay02.siemens.deをもつメッセージＭＭを呼び戻したい」）が格納されている記憶場所を表すＵＲＩを指している。したがって呼戻フィーチャのヘッダフィールドを理解できない受信アプリケーションに対しても、送信側から送られた呼戻ジョブについてあとから通知することができる。
【０２２７】
M-Notification.ind（ネットワークエレメントＲＳＢ→受信アプリケーションＵＡＢ）：
【０２２８】
【数２１】

【０２２９】
ＷＡＰメッセージM-NotifyResp.indによりＷＡＰメッセージM-Notification.indの適正な受信について確認応答される。メッセージＭＭ_Ａが未読であったならば、そのメッセージを条件付きの呼戻命令に従い消去することができる。さらにこの場合、受信アプリケーションＵＡＢに対し呼戻ジョブの結果について通知される。この目的でX-Mms-Statusヘッダフィールドが用いられる。この実施例ではこのヘッダフィールドには本発明により新たに定義されたエントリつまり「ＭＭ未読時のみ呼戻が成功する」ことに対する＜Octet140＞が収容されている。
【０２３０】
M-NotifyResp.ind（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０２３１】
【数２２】

【０２３２】
呼び戻すべきメッセージＭＭ_Ａがすでに開封されていたならば、もはやそれを消去しようとは試みられない。その代わりにＷＡＰメッセージM-NotifyResp.indには呼戻過程失敗についての情報が含まれる。なぜならばメッセージＭＭ_Ａは開封済みだったからである。このときヘッダフィールドX-Mms-Statusは、「メッセージＭＭは既読のため呼戻失敗」に対する値＜Octet144＞をもつことになる。
【０２３３】
M-NotifyResp.ind（受信アプリケーションＵＡＢ→ネットワークエレメントＲＳＢ）：
【０２３４】
【数２３】

【０２３５】
送信側が自身により指した呼戻ジョブに対する応答を望む場合、ネットワークエレメントＲＳＡはＷＡＰメッセージM-Delivery.indによって送信アプリケーションＵＡＡへ応答を送り戻すことができる。フィールド"Message-ID"には呼戻ジョブのＩＤ（AAAA.2222@mms-relay01.siemens.de）がおかれる。ここでも呼戻の状態に関して拡張されたヘッダフィールドX-Mms-Statusが使用され、そこではたとえばメッセージＭＭ_Ａの消去成功がフィールド値「ＭＭ未読時に呼戻成功」によって確認応答される。呼戻ジョブのメッセージＩＤと呼び戻すべきメッセージＭＭ_ＡのメッセージＩＤとの関係は送信アプリケーションＵＡＡにとって既知であるので、（関与しているＭＭＳサービスプロバイダがサポートしているかぎり）送信側に対しその送信側の呼戻ジョブの実行を成功させることができたか否かを通知することができる。
【０２３６】
M-Delivery.ind（ネットワークエレメント→送信アプリケーションＵＡＡ）：
【０２３７】
【数２４】

【０２３８】
例６：条件付きの変更もしくは置換
この実施例では、送信側は自身のメッセージＭＭ_Ａを（送信後１時間たってから）更新することを望んでいる。ここではもともと送られた２つのエレメントのうち、そのまま残しておくのはＪＰＥＧ画像（MIME content type "image/jpeg"）だけとする。さらに件名「会議の議題」の変更を行うものとする（例２を参照）。ここではＷＡＰメッセージM-Send.reqにおいて、置き換えるべきメッセージＭＭ_Ａの対応するＩＤをもつヘッダフィールドX-Mms-Replace-IDを使用するのがよい。さらにこの場合、X-Mms-Request-Reportのヘッダフィールドを用いて与えられた変更ジョブについての応答メッセージも要求される。本発明により新たに定義されたとえばX-Mms-Replace-Condという名称をもつヘッダフィールドが、ＷＡＰメッセージM-Send.reqにおいて使用される。この例におけるフィールド値は＜Octet128＞であるとする。この値は、メッセージＭＭ_Ａの受信側がこのメッセージについてまだ通知されていないときのみ呼戻を実現できる、という送信側の要求に対応している。
【０２３９】
M-Send.req（ＭＭＳＶＡＳアプリケーションＡ→ネットワークエレメントＲＳＡ）：
【０２４０】
【数２５】

【０２４１】
以下では２つのケースについて考察する：
ケース１：受信アプリケーションＵＡＢは通知（Notification）に基づきメッセージＭＭ_Ａをダウンロードした。
ケース２：メッセージＭＭ_ＡはまだネットワークエレメントＲＳＡ上にあり、受信アプリケーションＵＡＢへの通知は送信されていなかった。
【０２４２】
ケース１：
メッセージはすでに送信されたので、変更命令の実行に対する条件はもはや満たされない。したがって置換を行うことはもはやできない。この場合、変更命令をもつＷＡＰメッセージM-Send.reqの受信がＭＭＳリレー／サーバによりＷＡＰメッセージM-Send.confを用いて確認応答される。このメッセージにはＭＭＳリレー／サーバにより与えられたＭＭ_Ｂ用のメッセージＩＤ（ここではAAAA.2222@mms-relay01.siemens.de）が含まれている。さらにヘッダフィールドX-Mms-Supported-Featureには、本発明において新たに定義されたエントリ「条件変更フィーチャのサポート」が含まれている。変更ジョブは実行不可能であるため、ジョブ発行側に対しヘッダフィールドX-Mms-Response-Statusを用いてそのジョブの結果について通知される。この場合、フィールド値＜Octet152＞により、通知がすでに送信されていたため条件付きの置換を実行できなかったことが伝えられる：「通知が送信されていたため変更は失敗」。
【０２４３】
M-Send.conf（ネットワークエレメントＲＳＡ→ＭＭＳＶＡＳアプリケーションＡ）：
【０２４４】
【数２６】

【０２４５】
ネットワークエレメントＲＳＡが条件付きの置換をサポートしていない場合、そのネットワークエレメントはメッセージＭＭ_Ｂを通常のマルチメディアメッセージとして扱い、その結果、ＭＭ_Ａの置換が配慮されることなくそのメッセージは通常のように受信側へ伝送される。
【０２４６】
ケース２：
通知がまだ送信されていない場合、変更命令実行の条件が満たされている。したがって要求どおりに置換を行うことができる。ＭＭ_ＡをネットワークエレメントＲＳＡにおいて消去することができ、送信側に対しヘッダフィールドX-Mms-Response-Statusを用いてこの過程について通知される。フィールド値＜Octet152＞により、条件付きの置換が通知送達前に行われたことが伝えられる：「通知前に変更成功」。
【０２４７】
M-Send.conf（ネットワークエレメントＲＳＡ→ＭＭＳＶＡＳアプリケーションＡ）：
【０２４８】
【数２７】

【０２４９】
その後、新たなメッセージＭＭ_Ｂが受信アプリケーションＵＡＢに通常のマルチメディアメッセージとして届けられ、これは固有の通知として通告される。これにより受信側に対し、事前に送達されたメッセージＭＭ_Ａが送信側により新たなメッセージＭＭ_Ｂで置き換えられたことが伝えられる。
【０２５０】
既述の方法のほかに本発明の一部分としてこれに対応する装置も含まれ、たとえば通信端末機器およびここでは殊に移動無線機器ならびにそれに対応するネットワークエレメントも含まれる。同様にこれに対応するソフトウェアプログラムも本発明に含まれる。
【０２５１】
【表１】

表１：WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding" によるフィールド値符号化のオプション
【０２５２】
【表２】

表２：ＷＡＰメッセージM-Send.reqへの付加的な挿入
【０２５３】
【表３】

表３：ＷＡＰメッセージM-Send.confへの付加的な挿入
【０２５４】
【表４】

表４：ＷＡＰメッセージM-Notification.indへの付加的な挿入
【０２５５】
【表５】

表５：ＷＡＰメッセージM-NotifyResp.reqへの付加的な挿入
【０２５６】
【表６】

表６：ＷＡＰメッセージM-Retrive.confへの付加的な挿入
【０２５７】
【表７】

表７：ＷＡＰメッセージM-Acknowledge.indへの付加的な挿入
【０２５８】
【表８】

表８：ＷＡＰメッセージM-Delivery.indへの付加的な挿入
【図面の簡単な説明】
【０２５９】
【図１】従来技術のＵＭＴＳによるプルモードとプッシュモードを比較する図である。
【０２６０】
【図２】従来技術によるマルチメディアメッセージサービスに対するトランザクション線図である。
【０２６１】
【図３】従来技術によるマルチメディアメッセージサービスアーキテクチャの概略図である。
【０２６２】
【図４】本発明による第１のメッセージの操作可能性を有するマルチメディアメッセージサービスを示す図である。
【０２６３】
【図５】新たに定義されたヘッドフィールドの符号化を示す図である。
【０２６４】
【図６Ａ】公知のヘッドフィールドでのＸ−Ｍｍｓステータスの補足を示す図である。
【０２６５】
【図６Ｂ】公知のヘッドフィールドでのＸ−Ｍｍｓステータスの補足を示す図である。
【０２６６】
【図７】新たに挿入されたヘッドフィールド、Ｘ−Ｍｍｓ−オリジナルメッセージ・ステータスを示す図である。
【０２６７】
【図８】新たに挿入されたヘッドフィールド、Ｘ−Ｍｍｓ−オリジナルメッセージＩＤを示す図である。
【０２６８】
【図９Ａ】別に新たに定義されたヘッドフィールドの符号化を示す図である。
【０２６９】
【図９Ｂ】別に新たに定義されたヘッドフィールドの符号化を示す図である。
【０２７０】
【図９Ｃ】別に新たに定義されたヘッドフィールドの符号化を示す図である。
【０２７１】
【図９Ｄ】別に新たに定義されたヘッドフィールドの符号化を示す図である。
【０２７２】
【図１０】ヘッドフィールド、Ｘ−Ｍｍｓ−サポートフィーチャでの補足を示す図である。
【符号の説明】
【０２７３】
１送信アプリケーション（ＭＭＳユーザエージェントＡ＝ＵＡＡ）
２送信側のネットワークエレメント（ＭＭＳリレー／サーバＡ＝ＲＳＡ）
３ＭＭＳ記憶装置Ａ（ＭＭＳサーバＡ）
４ＭＭＳ環境（＝ＭＭＳＥ；ＭＭＳサービスプロバイダＡの環境）
６公衆移動ネットワーク（PLMN = Public Land Mobile Network）
７ＶＡＳアプリケーション（VAS = Value Added Service）
１１受信アプリケーション（ＭＭＳユーザエージェントＢ＝ＵＡＢ）
１２受信側のネットワークエレメント（ＭＭＳリレー／サーバＢ＝ＲＳＢ）
１３ＭＭＳ記憶装置Ｂ（ＭＭＳサーバＢ）
１４ＭＭＳＥ環境（＝ＭＭＳＥ；ＭＭＳサービスプロバイダＢの環境）
２０ＩＰインターネットプロトコル
２１レガシィメッセージシステム（Legacy Messaging System）
２２簡易メール転送プロトコル（SMTP = Simple Mail Transfer Protocol）

Claims

第１のメッセージ（ＭＭ_Ａ）たとえばＭＭＳタイプのマルチメディアメッセージ（ＭＭ）のアクセス方法において、
前記第１のメッセージ（ＭＭ_Ａ）は送信アプリケーション（１）またはネットワーク側のＶＡＳアプリケーション（７）により受信アプリケーション（１１）に送信され、
第１のメッセージ（ＭＭ_Ａ）を操作する操作ジョブにより第２のメッセージ（ＭＭ_Ｂ）が作成され、送信され、受信され、転送され、および／または処理されて、前記第１のメッセージ（ＭＭ_Ａ）への操作アクセスが指示され伝達されることを特徴とするアクセス方法。
前記の第１のメッセージ（ＭＭ_Ａ）と第２のメッセージ（ＭＭ_Ｂ）は無線により移動無線システムを用いて移動無線システムの間で、たとえばインターオペレータＩＰバックボーン（Inter-Operator-IP-backbone）を介して、移動無線ネットワークと他のメッセージネットワークの間で、たとえばインターネットＥメールによって、および／またはインターネットを介して送信される、請求項１記載の方法。
前記の第１のメッセージ（ＭＭ_Ａ）と第２のメッセージ（ＭＭ_Ｂ）は、サービスプロバイダ（サービスプロバイダＡ）の少なくとも１つの送信側のネットワークエレメント（２）とサービスプロバイダ（サービスプロバイダＢ）の少なくとも１つの受信側のネットワークエレメント（１２）を介して、受信側アプリケーション（１１）に送信される、請求項１または２記載の方法。
前記少なくとも１つの送信側のネットワークエレメント（２）と前記少なくとも１つの受信側のネットワークエレメント（１２）は、単一のサービスプロバイダ（サービスプロバイダＡ）の管轄エリア（４）に属しているかまたは同一である、請求項３記載の方法。
前記の送信アプリケーション（１）と受信アプリケーションは同一である、請求項１から４のいずれか１項記載の方法。
第１のメッセージ（ＭＭ_Ａ）に対する操作アクセスは、送信側のネットワークエレメント（２）、受信側のネットワークエレメント（１２）および／または受信側アプリケーション（１１）において行われる、請求項１から５のいずれか１項記載の方法。
前記操作ジョブには第１のメッセージ（ＭＭ_Ａ）の呼戻または消去が含まれる、請求項１から６のいずれか１項記載の方法。
前記操作ジョブには第１のメッセージ（ＭＭ_Ａ）の変更が含まれ、該変更はたとえば第１のメッセージ（ＭＭ_Ａ）を第２のメッセージ（ＭＭ_Ｂ）で置き換えることにより行われる、請求項１から６のいずれか１項記載の方法。
サービスプロバイダの関与するＭＭＳ環境（４，１４）の少なくとも１つの側で変更ジョブが未サポートであれば、第２のメッセージ（ＭＭ_Ｂ）は通常のメッセージとして受信アプリケーション（１１）に送達され、有利にはそのことが送り側に通知される、請求項８記載の方法。
前記第２のメッセージ（ＭＭ_Ｂ）は変更ジョブの場合にはプッシュモード（デリバーモード）またはプルモード（フェッチモード）でダウンロードされる、請求項８または９記載の方法。
前記第２のメッセージ（ＭＭ_Ｂ）は操作ジョブにより第１のメッセージ（ＭＭ_Ａ）の受信側に送信され、該第１のメッセージ（ＭＭ_Ａ）を識別または同定するために有利にはその識別番号（ＩＤ１）が用いられ、該識別番号（ＩＤ１）により第１のメッセージ（ＭＭ_Ａ）が送信アプリケーション（１）またはＶＡＳアプリケーションと送信側のネットワークエレメント（２）との間で一義的に表される、請求項１から１０のいずれか１項記載の方法。
メッセージ送信時に送信側のネットワークエレメント（２）に対し送信アプリケーション（１）またはＶＡＳアプリケーション（７）から、
メッセージ（ＭＭ_Ｂ）が操作ジョブであることを表すフラグ、
操作すべき第１のメッセージ（ＭＭ_Ａ）の識別番号、
送信側が該送信側により指示された操作の結果に関してフィードバックメッセージを要求していることを示す情報、
のうち１つまたは複数の情報が供給される、請求項１から１１のいずれか１項記載の方法。
送信アプリケーション（１）またはＶＡＳアプリケーション（７）に対し送信側のネットワークエレメント（２）から、該ネットワークエレメント（２）が請求項１から１２のいずれか１項記載の操作をサポートしているか否かについての情報、および／または操作ジョブが送信アプリケーション（１）またはＶＡＳアプリケーション（７）のサービスプロバイダ（サービスプロバイダＡ）によって受け入れられたか否かについての情報が供給される、請求項１から１２のいずれか１項記載の方法。
送信アプリケーション（１）もしくはＶＡＳアプリケーション（７）と受信アプリケーションが複数のサービスプロバイダのそれぞれ異なるＭＭＳ環境（ＭＭＳＥ_Ａ，ＭＭＳＥ_Ｂ）に属しているならば、受信側のネットワークエレメント（１１）に対し送信側のネットワークエレメント（１）から、
第２のメッセージ（ＭＭ_Ｂ）が操作ジョブであることを表すフラグ、
操作すべき第１のメッセージ（ＭＭ_Ａ）の識別番号、
送信側が該送信側により指示された操作の結果に関してフィードバックメッセージを要求していることを示す情報、
のうち１つまたは複数の情報が供給される、請求項１から１３のいずれか１項記載の方法。
それぞれ異なるサービスプロバイダ（サービスプロバイダＡ、サービスプロバイダＢ）のネットワークエレメント（２，１２）は、第１および／または第２のメッセージに関連する識別番号（ＩＤ１，ＩＤ３；ＩＤ４，ＩＤ６，ＩＤ５）の一義的で可逆的な変換を行い、対応する情報を有利には管理する、請求項１から１４のいずれか１項記載の方法。
たとえば消去命令を含む操作ジョブが与えられたとき、第１のメッセージ（ＭＭ_Ａ）に関して受信アプリケーション（１１）への通知がまだ行われていなければ、該第１のメッセージ（ＭＭ_Ａ）は送信側のサービスプロバイダ（サービスプロバイダＡ）のＭＭＳ環境（ＭＭＳＥ_Ａ）において、または受信側のサービスプロバイダ（サービスプロバイダＢ）の管轄エリア（ＭＭＳＥ_Ｂ）において操作されたとえば消去され、有利には該操作について受信アプリケーション（１１）には通知されない、請求項１から１５のいずれか１項記載の方法。
操作ジョブが与えられたとき、受信側に通知が行われたがまだ第１のメッセージ（ＭＭ_Ａ）がダウンロードされていなければ、該第１のメッセージ（ＭＭ_Ａ）は受信側のサービスプロバイダ（サービスプロバイダＢ）のＭＭＳ環境（ＭＭＳＥ_Ｂ）において操作され、受信アプリケーション（１１）に対し該操作およびその時点に関して有利には通知される、請求項１から１５のいずれか１項記載の方法。
操作ジョブが与えられたとき、受信側に通知が行われたがまだ第１のメッセージ（ＭＭ_Ａ）がダウンロードされていなければ、該第１のメッセージ（ＭＭ_Ａ）は送信側のサービスプロバイダ（サービスプロバイダＡ）のＭＭＳ環境（ＭＭＳＥ_Ａ）において操作され、受信アプリケーション（１１）に対し該操作に関して有利には通知されない、請求項１から１５のいずれか１項記載の方法。
受信アプリケーション（１１）に対し受信側のネットワークエレメント（１２）から、
通告されただけでまだ配送されていない第１のメッセージ（ＭＭ_Ａ）はもはやダウンロード可能な状態にないかまたは新たなメッセージ（ＭＭ_Ｂ）によって変更されていて、第１および／または第２のメッセージ（ＭＭ_Ａ，ＭＭ_Ｂ）は有利にはＵＲＩ（Uniform Resource Identifier = 格納場所）に基づき識別されることを示す情報、
すでに配送済みの第１のメッセージ（ＭＭ_Ａ）の操作を送信側が望んでおり、該第１のメッセージ（ＭＭ_Ａ）を受信アプリケーションにおいて有利にはメッセージ参照子に基づき行い、該メッセージ参照子は有利には受信側のサービスプロバイダ（サービスプロバイダＢ）の標準テキストメッセージが格納されているＵＲＩであり、該ＵＲＩは有利には第１のメッセージ（ＭＭ_Ａ）の識別番号（ＩＤ１）から、または受信側のネットワーク要素（１２）により決定された第２の識別番号（ＩＤ２）から合成されているという情報、
サービスプロバイダ（サービスプロバイダＡまたはＢ）の側における第１のメッセージ（ＭＭ_Ａ）の操作に関する通知、
操作オペレーションに関する通知および受信側が要求するならば操作されたメッセージが利用できないことに関する通知、
受信アプリケーション（１１）において実行すべき操作ジョブが第２のメッセージ（ＭＭ_Ｂ）に含まれることを表すフラグ、
すでに配送済みのいずれのメッセージ（ＭＭ_Ａ）を操作すべきであるのかを示す情報、
いつ操作が実行されたのかを示す情報、
配送された第２のメッセージ（ＭＭ_Ｂ）があとから変更されたメッセージであることを示す情報、
行うべき操作の種類を示す情報、
のうち１つまたは場合によっては複数の情報が有利には通知として供給される、請求項１から１８のいずれか１項記載の方法。
第２のメッセージ（ＭＭ_Ｂ）について通知が行われた後、受信アプリケーション（１１）から受信側のネットワークエレメント（１２）に対し、
事前に通告しただけの第１のメッセージ（ＭＭ_Ａ）の操作成功を受信アプリケーション（１１）が了解したことを示す情報、
すでにダウンロードされた第１のメッセージ（ＭＭ_Ａ）の操作を成功させることができたか否かを示す情報、
すでにダウンロードされたメッセージ（ＭＭ_Ａ）が操作されたことについて受信側に通知されているのかおよび／またはそのことについて受信側が同意しているのかを示す情報、
失敗であれば不成功の理由、
変更ジョブが与えられたならば、すでにダウンロードされた第１のメッセージ（ＭＭ_Ａ）が自動的に（プッシュモード）実行されたのかまたは受信側の指示に基づき（プルモード）実行されたのかを示す情報、
行われるべき操作がどのような種類であるのかを示す情報、
のうち少なくとも１つの情報が供給される、請求項１から１９のいずれか１項記載の方法。
送信アプリケーション（１）もしくはＶＡＳアプリケーション（７）と受信アプリケーション（１１）が複数のサービスプロバイダ（サービスプロバイダＡ、サービスプロバイダＢ）のそれぞれ異なるＭＭＳ環境（ＭＭＳＥ_Ａ，ＭＭＳＥ_Ｂ）に属しているならば、受信側のネットワークエレメント（１２）から送信側のネットワークエレメント（２）へ、
操作ジョブを成功させることができたのか否かを示す情報、
失敗であれば不成功の理由、
操作ジョブがいつ実行されたのかを示す情報、
操作ジョブが自動的に実行されたのか否かを示す情報、
受信側が操作について通知されたのか、および／または操作に同意したのか、および／または受信側により操作が指示されたのかを示す情報、
すでにダウンロードされた第１のメッセージ（ＭＭ_Ａ）が操作されたこと、あるいは第１のメッセージ（ＭＭ_Ａ）が変更前にはまだダウンロードされていなかったことを示す情報、
操作されたメッセージ（ＭＭ_Ａ）の暫定識別番号（ＩＤ３）、
どのような種類の操作が行われたのかを示す情報、
のうち１つまたは複数の情報が供給される、請求項１から２０のいずれか１項記載の方法。
送信アプリケーション（１）またはＶＡＳアプリケーション（７）に対し送信側のネットワークエレメント（２）から、
操作ジョブが成功したか否かを示す情報、
失敗であれば不成功の理由
第１のメッセージ（ＭＭ_Ａ）が未知のアドレスに転送されたことから操作を実行できなかったことを示す情報、
操作ジョブがいつ実行されたのかを示す情報、
操作ジョブが自動的に実行されたのか否かを示す情報、
操作について受信側に通知されたのか、および／または受信側が操作について同意したのか、および／または受信側が操作を指示したのかを示す情報、
すでにダウンロードされたメッセージ（ＭＭ_Ａ）が操作されたこと、あるいは第１のメッセージ（ＭＭ_Ａ）は変更前にはまだ配送されていなかったことを示す情報、
操作されたメッセージ（ＭＭ_Ａ）の識別番号（ＩＤ１）、
のうち１つまたは複数の情報が供給される、請求項１から２１のいずれか１項記載の方法。
前記第２のメッセージ（ＭＭ_Ｂ）には送信アプリケーション（１）またはＶＡＳアプリケーション（７）により付加された少なくとも１つの情報要素が含まれており、該情報要素は操作アクセス実行に対する少なくとも１つの条件を有する、請求項１から２２のいずれか１項記載の方法。
前記少なくとも１つの情報要素は第１のメッセージ（ＭＭ_Ａ）の処理状態に従った操作アクセスを表す、請求項２３記載の方法。
送信アプリケーション（１）またはＶＡＳアプリケーション（７）により前記少なくとも１つの情報要素を用いることで、
第１のメッセージ（ＭＭ_Ａ）の操作は、該第１のメッセージ（ＭＭ_Ａ）がまだサーバ上にあり受信側に該第１のメッセージ（ＭＭ_Ａ）についてまだ通知されていないときだけ行われる、
第１のメッセージ（ＭＭ_Ａ）の操作は、通知が送信されたが第１のメッセージ（ＭＭ_Ａ）はまだダウンロードされていないときも行われる、
第１のメッセージ（ＭＭ_Ａ）の操作は、受信側が第１のメッセージ（ＭＭ_Ａ）をまだ未開封もしくは未読のときに行われる、
第１のメッセージ（ＭＭ_Ａ）の操作は、処理状態に左右されることなく行われる、
という条件のうち少なくとも１つの条件が決定される、請求項２３または２４記載の方法。
前記情報要素にデフォルト値が割り当てられ、条件が詳しく指定されていないときには該デフォルト値に従い操作が行われる、請求項２３から２５のいずれか１項記載の方法。
第１および第２のメッセージ（ＭＭ_Ａ，ＭＭ_Ｂ）の伝送に関与するサービスプロバイダ（サービスプロバイダＡおよび／またはサービスプロバイダＢ）のうち少なくとも１つのサービスプロバイダは、操作ジョブを固有のデーモンまたは異なるサービスプロバイダの特定のデーモンに合わせて制限し、これは有利には受信側の識別子（呼出番号、メールアドレス．．．）に基づきまたは付加的なフラグを利用して行われる、請求項２３から２６のいずれか１項記載の方法。
操作ジョブを含み送信側アプリケーション（１）またはＶＡＳアプリケーション（７）から送信側のネットワークエレメント（２）へ送信される第２のメッセージ（ＭＭ_Ｂ）に対し、第１のメッセージ（ＭＭ_Ａ）の操作を実行するための条件として、
受信側へ通知される前のみ操作を行う、
通知送達後でもダウンロードされる前のみ操作を行う、
第１のメッセージ（ＭＭ_Ａ）がまだ未開封もしくは未読のときのみ操作を行う、
第１のメッセージ（ＭＭ_Ａ）の処理状態に左右されることなく操作を行う、
ことのうちの１つが付加される、請求項２３から２７のいずれか１項記載の方法。
送信側アプリケーション（１）またはＶＡＳアプリケーション（７）に対し送信側のネットワークエレメント（２）から第１または第２のメッセージ（ＭＭ_Ａ，ＭＭ_Ｂ）の送信後の確認応答時に、該ネットワークエレメント（２）が前記の条件付き操作をサポートしているのか、および／または条件付きの操作ジョブが送信側のサービスプロバイダ（サービスプロバイダＡ）により受け入れられたのか否かが通知される、請求項２３から２８のいずれか１項記載の方法。
送信アプリケーション（１）もしくはＶＡＳアプリケーション（７）と受信アプリケーション（１１）が複数のサービスプロバイダ（サービスプロバイダＡ、サービスプロバイダＢ）のそれぞれ異なるＭＭＳ環境（ＭＭＳＥ_Ａ，ＭＭＳＥ_Ｂ）に属しているならば、受信側のネットワークエレメント（１２）に対し送信側のネットワークエレメント（２）から第２のメッセージ（ＭＭ_Ｂ）による第１のメッセージ（ＭＭ_Ａ）の操作に関する条件として、
受信側に通知される前にのみ操作を行う、
通知が送達された後でもダウンロード前にのみ操作を行う、
第１のメッセージがまだ未開封もしくは未読のときのみ操作を行う、
第１のメッセージ（ＭＭ_Ａ）の処理状態に左右されずに操作を行う、
ことのうち１つまたは複数の条件が伝達される、請求項２３から２９のいずれか１項記載の方法。
受信アプリケーション（１１）に対し受信側のネットワークエレメント（１２）から第２のメッセージ（ＭＭ_Ｂ）による第１のメッセージ（ＭＭ_Ａ）の操作に関する条件として、有利には到来した第２のメッセージ（ＭＭ_Ｂ）に関する通知に際して、
受信側に通知される前にのみ操作を行う、
通知の送達後でもダウンロード前にのみ操作を行う、
第１のメッセージ（ＭＭ_Ａ）がまだ未開封もしくは未読のときのみ操作を行う、
第１のメッセージ（ＭＭ_Ａ）の処理状態に左右されずに操作を行う、
ことのうち１つまたは複数が伝達される、請求項２３から３０のいずれか１項記載の方法。
条件の付された操作を含めてメッセージ（ＭＭ）の送信、受信および操作はＷＡＰメッセージ（Wireless Application Protocol）により行われる、請求項１から３１のいずれか１項記載の方法。
操作ジョブは既存のヘッダフィールド（X-Mms-Status; M-Mms-Supported-Feature）の変更および／または付加的なヘッダフィールド（X-Mms-Recall-ID; X-Mms-Recalled-URI; X-Mms-Replace-ID; X-Mms-Replaced-URI; X-Mms-Supported-Feature; X-Mms-Date-Of-Execution; X-Mms-Request-Report; X-Mms-Original-Message-Status; X-Mms-Original-Message-ID; X-Mms-Recall-Cond; X-Mms-Replace-Cond; X-Mms-Recall-Status;
X-Mms-Replace-Status; X-Mms-Operation-Status）の追加により、適切なＷＡＰメッセージにインプリメントたとえばWAP-MMSEncapsulation標準に準拠するＷＡＰメッセージにインプリメントされ、たとえばＷＡＰメッセージであるM-Send.req, M-Send.conf, M-Notification.ind, M-NotifyResp.req, M-Retrieve.conf, M-Acknowledge.ind. M-Delivery.indのうちの少なくとも１つにインプリメントされる、請求項１から３２のいずれか１項記載の方法。
第１のメッセージ（ＭＭ_Ａ）は操作ジョブの結果に関するフィードバックメッセージのために、第２のメッセージ（ＭＭ_Ｂ）の識別番号（ＩＤ４）および対応するＷＡＰメッセージのトランザクションＩＤ番号または付加的なヘッダフィールドに基づき識別され、新たなヘッダフィールドのフィールド値には第１のメッセージ（ＭＭ_Ａ）の識別番号（ＩＤ１）が含まれる、請求項１から３３のいずれか１項記載の方法。
第１のメッセージ（ＭＭ_Ａ）たとえばMMSタイプのマルチメディアメッセージを作成し送信し受信および／または処理する手段が設けられている、請求項１から３４のいずれか１項記載の方法を実施するための通信装置において、
第２のメッセージ（ＭＭ_Ｂ）を作成し送信し受信および／または処理する手段が設けられており、
該第２のメッセージ（ＭＭ_Ｂ）には、事前に送信された第１のメッセージ（ＭＭ_Ａ）を操作するための条件なしまたは条件付きの操作ジョブが含まれていることを特徴とする通信装置。
送信アプリケーション（１）またはＶＡＳアプリケーションおよびこれらのアプリケーション（１，７）と結合されたまたは結合可能な送信ユニットが設けられている、請求項３５記載の通信装置。
受信アプリケーション（１１）および該受信アプリケーション（１１）と結合されたまたは結合可能な受信ユニットが設けられている、請求項３５または３６記載の通信装置。
条件なし操作ジョブおよび／または条件付き操作ジョブのサポート、操作ジョブのオペレーション成功またはオペレーション失敗および／または操作ジョブのオペレーション失敗の理由に関する送信側のネットワークエレメント（２）からの通知を評価するプロセッサユニットが設けられている、請求項３５から３７のいずれか１項記載の通信装置。
条件なしまたは条件付きの操作ジョブのオペレーションについての情報に関する受信側のネットワークエレメント（１２）からの通知を評価するプロセッサユニットが設けられている、請求項３５から３８のいずれか１項記載の通信装置。
操作ジョブのオペレーション成功またはオペレーション失敗および／または操作ジョブオペレーション失敗の理由に関する通知を受信側のネットワークエレメント（１２）へ送信する送信ユニットが設けられている、請求項３９記載の通信装置。
送信ユニットおよび受信ユニットを備えた移動電話機として構成されている、請求項３５から４０のいずれか１項記載の通信装置。
ＶＡＳアプリケーション（７）の設けられたネットワークエレメントとして構成されている、請求項３５から４０のいずれか１項記載の通信装置。
ＷＡＰメッセージを処理する手段が設けられており、該手段はたとえばWAP-MMSEncapsulation標準に準拠するＷＡＰメッセージを処理し、たとえばＷＡＰメッセージであるM-Send.req, M-Send.conf, M-Notification.ind, M-NotifyResp.req, M-Retrieve.conf, M-Acknowledge.ind, M-Delivery.indを処理し、該メッセージは操作ジョブに関連して交換すべき情報に応じて変更されたヘッダフィールドおよび／または付加的なフィールドを備えている、請求項３５から４２のいずれか１項記載の通信装置。
情報要素を生成する手段および該情報要素を送信アプリケーション（１）またはＶＡＳアプリケーション（７）により第２のメッセージ（ＭＭ_Ｂ）に割り当てる手段が設けられており、前記情報要素には操作アクセスのオペレーションに対する少なくとも１つの条件が含まれている、請求項３５から４３のいずれか１項記載の通信装置。
操作ジョブを実行する手段が設けられている、請求項４４記載の通信装置。
請求項３５から４５のいずれか１項記載の通信装置から送信された第１のメッセージ（ＭＭ_Ａ）たとえばＭＭＳタイプのマルチメディアメッセージを受信および転送する手段が設けられていて、たとえば請求項１から３４のいずれか１項記載の方法をネットワーク側で実施するためのネットワークエレメント（２；１２）たとえば無線通信システムのネットワークエレメントにおいて、
操作ジョブを伴う第２のメッセージ（ＭＭ_Ｂ）を受信、処理および／または転送する手段が設けられており、
前記操作ジョブは、受信されたおよび場合によってはすでに転送された第１のメッセージ（ＭＭ_Ａ）に係わるものであり、該第１のメッセージ（ＭＭ_Ａ）に対する操作アクセスを指示または仲介することを特徴とする、
ネットワークエレメント。
他のネットワークエレメント（１２；２）および／または送信側および／または受信側の受信アプリケーション（１；１１）への通知を受信、転送および／または生成ならびに送信する手段が設けられており、
該通知は、第２のメッセージ（ＭＭ_Ｂ）において指定された操作ジョブの実行に対し送信側により定められた条件、条件付きの操作ジョブオペレーションの成功または失敗および／または条件付きの操作ジョブのオペレーション失敗の理由に係わる、
請求項４６記載のネットワークエレメント。
操作ジョブを実行する手段が設けられている、請求項４６または４７記載のネットワークエレメント。
第１のメッセージ（ＭＭ_Ａ）は、受信ユニットのネットワークエレメント（２；１２）および／または受信アプリケーション（１１）において操作可能であり、たとえば消去可能および／または変更可能である、請求項４８記載のネットワークエレメント。
第２のメッセージ（ＭＭ_Ｂ）を受信、処理および／または転送する手段はＷＡＰメッセージたとえばWAP-MMSEncapsulation標準に準拠したＷＡＰメッセージを使用し、たとえばＷＡＰメッセージであるM-Send.req, M-Send.conf, M-Notification.ind, M-NotifyResp.req, M-Retrieve,conf, M-Acknowledge.ind, M-Delivery.indを使用し、該ＷＡＰメッセージは、操作ジョブに関連して交換すべき情報に従い変更されたヘッダフィールドおよび／または付加的なヘッダフィールドを備えている、請求項４６から４９のいずれか１項記載のネットワークエレメント。
プロセッサと、たとえば通信装置たとえば請求項３５から４５のいずれか１項記載の通信装置またはネットワークエレメントたとえば請求項４６から５０のいずれか１項記載のネットワークエレメントを備えた装置において実行可能なソフトウェアプログラムにおいて、
該ソフトウェアプログラムは前記装置とともに請求項１から３４のいずれか１項記載の方法を該装置の側で実施または指示することを特徴とするソフトウェアプログラム。
プロセッサと、たとえば通信装置たとえば請求項３５から４５のいずれか１項記載の通信装置またはネットワークエレメントたとえば請求項４６から５０のいずれか１項記載のネットワークエレメントを備えた装置にロード可能なソフトウェアプログラムにおいて、
該ソフトウェアプログラムによりプログラミングされた装置はプロセッサを含めて、請求項１から３４のいずれか１項記載の方法を実施可能または指示可能となり、または実施または指示に整合されることを特徴とするソフトウェアプログラム。