(57)【特許請求の範囲】
【請求項１】
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
少なくとも１つのＭＭＳユーザエージェントにおいて個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求める、ただしその際、マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含めることを特徴とする、
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法。
【請求項２】
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
少なくとも１つのＭＭＳユーザエージェントにおいて個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求め、ただしその際、マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含め、
まえもって設定可能な有効データ容量上限（ＳＧｘ）を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを提供することを特徴とする、
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法。
【請求項３】
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法において、
少なくとも１つのＭＭＳユーザエージェントにおいて個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求め、ただしその際、マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含め、
まえもって設定可能な価格上限および／または有効データ容量上限（ＳＰｘ、ＳＧｘ）を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを提供することを特徴とする、
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための方法。
【請求項４】
付加的に、場合によっては個々のマルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられている少なくとも１つまたは複数のヘッダフィールドのサイズを、該マルチメディアメッセージの有効データ容量（ＶＯＬ）の計算に含める、請求項１から３のいずれか１項記載の方法。
【請求項５】
マルチメディアメッセージの宛先指定のためのヘッダフィールド"Ｃｃ"および"Ｂｃｃ"のサイズを有効データ容量（ＶＯＬ）の計算に含める、請求項４記載の方法。
【請求項６】
付加的に、個々のマルチメディアメッセージ（ＭＭ）に含まれているプレゼンテーション記述を部分的にまたは全体的に有効データ容量（ＶＯＬ）の計算に含める、請求項１から５のいずれか１項記載の方法。
【請求項７】
そのつど選択された有効データ容量上限（ＳＧｘ）と対比して個々のマルチメディアメッセージ（ＭＭ）の未使用有効データ容量（ＦＶＯＬ）を求める、請求項１から３のいずれか１項記載の方法。
【請求項８】
未使用の有効データ容量（ＦＶＯＬ）を部分的にまたは全体的に、少なくとも１つの付加的なマルチメディアメッセージ要素、マルチメディアメッセージ部分要素、または他の付加的な情報の形態の有効データによって充填する、請求項７記載の方法。
【請求項９】
もともと生じている占有されている有効データ容量（ＶＯＬ）を、有効データ容量を段階づけた料金体系（ＧＴＭ）の１つの価格クラス（Ｐｘ）に割り当てる、請求項３記載の方法。
【請求項１０】
個々のマルチメディアメッセージ（ＭＭ）の未使用有効データ容量（ＦＶＯＬ）を、該マルチメディアメッセージ（ＭＭ）に現在割り当てられている価格クラス（Ｐｘ）について求める、請求項９記載の方法。
【請求項１１】
選択されている有効データ容量上限（ＳＧｘ）を超えた場合、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）において生じている有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを個々のマルチメディアメッセージ（ＭＭ）に適用する、請求項２記載の方法。
【請求項１２】
選択されている価格上限（ＳＰｘ）または選択されている有効データ容量上限（ＳＧｘ）を超えた場合、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）において生じている有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを個々のマルチメディアメッセージ（ＭＭ）に適用する、請求項３記載の方法。
【請求項１３】
まえもって定義されている有効データ容量上限（ＳＧｘ）を超過した場合にはそのことを注意喚起する、請求項２または１１記載の方法。
【請求項１４】
まえもって定義されている価格上限および／または有効データ容量上限（ＳＰｘ，ＳＧｘ）を超過した場合にはそのことを注意喚起する、請求項３または１２記載の方法。
【請求項１５】
有効データ容量上限（ＳＧｘ）を、個々のユーザおよび／またはＭＭＳ（マルチメディアメッセージサービス）サービスプロバイダ（Ｐａ，ＰＢ）により定義する、請求項２，１１または１３記載の方法。
【請求項１６】
価格上限および／または有効データ容量上限（ＳＰｘ、ＳＧｘ）を、個々のユーザおよび／またはＭＭＳ（マルチメディアメッセージサービス）サービスプロバイダ（Ｐａ，ＰＢ）により定義する、請求項３，１２，１４のうちいずれか１項記載の方法。
【請求項１７】
ａ）そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）において現在生じている有効データ容量（ＶＯＬ）を求め、
ｂ）求められた有効データ容量（ＶＯＬ）を１つの価格クラス（Ｐ１〜Ｐ５）に割り当て、
ｃ）求められた有効データ容量（ＶＯＬ）に対応する価格クラス（Ｐｘ）について未使用有効データ容量（ＦＶＯＬ）を求め、
ｄ）定義された価格上限および／または有効データ容量上限（ＳＰｘ、ＳＧｘ）が場合によっては超えたことを検出して、そのことを注意喚起し、
ｅ）ステップａ）による算出結果、および／またはステップｂ）による割り当て、および／またはステップＣ）による計算、および／またはステップｄ）による場合によっては生じる超過を、音響的、触覚的またはグラフィック形態でユーザに示し、
ｆ）マルチメディアメッセージ（ＭＭ）をもともと割り当てられていた価格クラスよりも低い価格クラス（Ｐｘ）に属させることを優先的な目標として、現在の有効データ容量を低減する少なくとも１つの提案をユーザに呈示し、
ｇ）もともと占有していた有効データ容量の低減を実行して、準備処理しているマルチメディアメッセージ（ＭＭ）をもともと割り当てられていた価格クラスよりも低い価格クラスに属させる、
請求項３記載の方法。
【請求項１８】
前記のステップまたはそれらのうちの一部分を、ＭＭＳユーザエージェントとは独立した少なくとも１つの固有の機能ユニットにおいて実行する、請求項１記載の方法。
【請求項１９】
前記のステップまたはそれらのうちの一部分を、ＭＭＳユーザエージェントとは独立した少なくとも１つの固有の機能ユニットにおいて実行する、請求項２，４〜８，１１，１３，１５のいずれか１項記載の方法。
【請求項２０】
前記のステップまたはそれらのうちの一部分を、ＭＭＳユーザエージェントとは独立した少なくとも１つの固有の機能ユニットにおいて実行する、請求項３，９，１０，１２，１４，１６，１７のいずれか１項記載の方法。
【請求項２１】
前記固有の機能ユニットに対しＭＭＳユーザエージェントから、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）において該ＭＭＳユーザエージェントにより求められた有効データ容量（ＶＯＬ）あるいは全体的または部分的に編集済みのマルチメディアメッセージ自体を供給する、請求項１９または２０記載の方法。
【請求項２２】
個々のＭＭＳユーザエージェントおよび／または少なくとも１つの固有の機能ユニットから、超過した場合にそのことを指示するために個々のユーザまたはＭＭＳサービスプロバイダにより設定された有効データ容量上限（ＳＧｘ）へのアクセスを行う、請求項１９記載の方法。
【請求項２３】
個々のＭＭＳユーザエージェントおよび／または少なくとも１つの固有の機能ユニットから、個々のマルチメディアメッセージ（ＭＭ）において求められた有効データ容量（ＶＯＬ）を１つの価格クラス（Ｐｘ）に割り当てるための情報たとえばテーブル形式のデータへのアクセス、および／または超過した場合にそのことを指示するために個々のユーザまたはＭＭＳサービスプロバイダにより設定された価格上限および／または有効データ容量上限（ＳＰｘ、ＳＧｘ）へのアクセスを行う、請求項２０記載の方法。
【請求項２４】
前記情報を端末機器たとえば無線通信装置における１つまたは複数の内部記憶領域に格納する、請求項２２記載の方法。
【請求項２５】
前記情報を端末機器たとえば無線通信装置における１つまたは複数の内部記憶領域に格納する、請求項２３記載の方法。
【請求項２６】
前記情報を、個々の端末機器とケーブルおよび／または無線を介して接続可能な１つまたは複数の外部記憶ユニットに格納する、請求項２２または２３記載の方法。
【請求項２７】
外部記憶ユニットとして、移動端末装置に差し込み可能なＳＩＭカードまたは（Ｕ）ＳＩＭを備えたＵＩＣＣを使用する、請求項２６記載の方法。
【請求項２８】
個々の記憶ユニットにおいてもっぱらネットワーク業者により書き込み可能または更新可能な記憶領域を、固有のＭＭＳ料金情報の記憶および後からのＯＴＡ更新に使用する、請求項２４記載の方法。
【請求項２９】
個々の記憶ユニットにおいてもっぱらネットワーク業者により書き込み可能または更新可能な記憶領域を、固有のＭＭＳ料金情報の記憶および後からのＯＴＡ更新に使用する、請求項２５記載の方法。
【請求項３０】
個々のネットワーク業者のＭＭＳ料金情報を有効データ容量上限（ＳＧｘ）のために利用する、請求項２８記載の方法。
【請求項３１】
個々のネットワーク業者のＭＭＳ料金情報を価格上限および／または有効データ容量上限（ＳＰｘ，ＳＧｘ）のために利用する、請求項２９記載の方法。
【請求項３２】
個々の記憶ユニットにおいて個々のユーザにも書き込み権限および読み出し権限のある記憶領域を、ユーザ定義された有効データ容量上限（ＳＧｘ）を記憶するために利用する、請求項２４記載の方法。
【請求項３３】
個々の記憶ユニットにおいて個々のユーザにも書き込み権限および読み出し権限のある記憶領域を、ユーザ定義された価格上限および／または有効データ容量上限（ＳＰｘ，ＳＧｘ）を記憶するために利用する、請求項２５記載の方法。
【請求項３４】
前記の複数のステップまたはそれらのステップのうちの一部分を、ＳＩＭカード上の低減アプリケーション（ＳＡＴアプリケーション）または（Ｕ）ＳＩＭを備えたＵＩＣＣ上の低減アプリケーション（ＣＡＴもしくは（Ｕ）ＳＡＴアプリケーション）により実行する、請求項１９または２０記載の方法。
【請求項３５】
有効データ容量上限（ＳＧＸ）が超過した場合にはそのことを示す出力メッセージを、少なくとも１つのマンマシンインタフェース（ＨＭＩ human machine interface）ユニットを介して音響的、触覚的に、および／またはグラフィック形態でユーザに通知する、請求項２記載の方法。
【請求項３６】
有効データ容量上限（ＳＧＸ）および／または価格クラス上限（ＳＰｘ）が超過した場合にはそのことを示す出力メッセージを、少なくとも１つのマンマシンインタフェース（ＨＭＩ human machine interface）ユニットを介して音響的、触覚的に、および／またはグラフィック形態でユーザに通知する、請求項３記載の方法。
【請求項３７】
視覚的な出力のために棒グラフ（ＢＫ）を使用する、請求項３５記載の方法。
【請求項３８】
視覚的な出力のために棒グラフ（ＢＫ）を使用する、請求項３６記載の方法。
【請求項３９】
割り当てるべき価格クラス（Ｐ１〜Ｐ５）に関連づけて、個々のマルチメディアメッセージ（ＭＭ）において現在生じている有効データ容量（ＶＯＬ）を、棒グラフ（ＢＫ）を用いて表示する、請求項３８記載の方法。
【請求項４０】
個々のマルチメディアメッセージ（ＭＭ）の１つのマルチメディアメッセージ要素において現在生じている有効データ容量を低減するためにファイルタイプ変換、ファイルフォーマット変換、圧縮技術（＝ファイルフォーマット変換のサブセット）、および／または静止画における色の深さおよび／またはサイズの低減を適用する、請求項２または３記載の方法。
【請求項４１】
マルチメディアメッセージ要素の有効データ容量を低減するための少なくとも２つの可能性を互いに組み合わせて、たとえばそれらを相前後させて実施する、請求項４０記載の方法。
【請求項４２】
請求項１から４１のいずれか１項記載の方法を実施するために構成されている無線装置たとえば移動無線装置。
【請求項４３】
マルチメディアメッセージを伝送効率化準備処理する移動無線装置において、
前記移動無線装置は、
個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求めるＭＭＳユーザエージェントを有しており、
マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含めることを特徴とする、
マルチメディアメッセージを伝送効率化準備処理する移動無線装置。
【請求項４４】
マルチメディアメッセージを伝送効率化準備処理する移動無線装置において、
前記移動無線装置は、
個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求めるＭＭＳユーザエージェントを有しており、
マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含め、
まえもって設定可能な有効データ容量上限（ＳＧｘ）を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを提供することを特徴とする、
マルチメディアメッセージを伝送効率化準備処理する移動無線装置。
【請求項４５】
マルチメディアメッセージを伝送効率化準備処理する移動無線装置において、
前記移動無線装置は、
個々のマルチメディアメッセージ（ＭＭ）の編集前、編集後および／または編集中、該マルチメディアメッセージ（ＭＭ）の個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージ（ＭＭ）において生じている占有有効データ容量（ＶＯＬ）を求めるＭＭＳユーザエージェントを有しており、
マルチメディアメッセージのテーマに関する「件名」ヘッダフィールドのサイズのような、各マルチメディアメッセージ（ＭＭ）のヘッダ部分に設けられているヘッダフィールドのサイズを占有有効データ容量（ＶＯＬ）の計算に含め、
まえもって設定可能な価格上限および／または有効データ容量上限（ＳＰｘ、ＳＧｘ）を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージ（ＭＭ）においてもともと生じていた占有有効データ容量（ＶＯＬ）を低減するための少なくとも１つの低減アプリケーションを提供することを特徴とする、
マルチメディアメッセージを伝送効率化準備処理する移動無線装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はマルチメディアメッセージの伝送効率化準備処理のための方法および無線通信装置に関するものである。
【背景技術】
【０００２】
特許文献１から、遠隔の通信ユニットと通信サーバとの間の通信データに関して単に全体量についてのみ監視してコントロールすることのできる方法および装置が知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】ＵＳ  ２００２／００１３８５４  Ａ１
【非特許文献】
【０００４】
【非特許文献１】3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS).
【非特許文献２】3GPP TS 22.140 version 4.1.0, Release 4; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS).
【非特許文献３】3GPP TS 23.140 version 5.1.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2.
【非特許文献４】W3C Recommendation 15-June-1998: "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification" - http://www.w3.org/TR/REC-smil/.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の課題は、伝送すべきマルチメディアメッセージの送信側または受信側に対するコスト透明性を改善することにある。
【課題を解決するための手段】
【０００６】
この課題は、マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための以下に示す本発明による方法によって解決される：
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための第１の方法において、個々のマルチメディアメッセージの編集前、編集後および／または編集中、該マルチメディアメッセージの個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージにおいて生じている占有有効データ容量を求める。
【０００７】
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための第２の方法において、個々のマルチメディアメッセージの編集前、編集後および／または編集中、該マルチメディアメッセージの個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージにおいて生じている占有有効データ容量を求め、まえもって設定可能な有効データ容量上限を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージにおいてもともと生じていた占有有効データ容量を低減するための少なくとも１つの低減アプリケーションを提供する。
【０００８】
マルチメディアメッセージをその送信前または受信前に伝送効率化準備処理するための請求項３による第３の方法では、個々のマルチメディアメッセージの編集前、編集後および／または編集中、該マルチメディアメッセージの個々のマルチメディアメッセージ要素のデータ容量をすべて総和することにより該マルチメディアメッセージにおいて生じている占有有効データ容量を求め、まえもって設定可能な価格上限および／または有効データ容量上限を超過した場合には、そのつど送信または受信すべきマルチメディアメッセージにおいてもともと生じていた占有有効データ容量を低減するための少なくとも１つの低減アプリケーションを提供する。
【発明の効果】
【０００９】
上記の各方法により、個々のマルチメディアメッセージを実際に送信側から送ったりもしくは受信側が受け取ったりする前に、簡単かつ高い信頼性でマルチメディアメッセージの個々の送信側または受信側に対し改善されたコスト透明性が提供される。
【００１０】
第２の方法では、まえもって定められた有効データ容量上限を超えたときに送信または受信すべきマルチメディアメッセージにおいて本来生じている有効データ容量を低減するために、少なくとも１つの低減アプリケーションが提供される。
【００１１】
さらに、第３の方法では、まえもって定められた料金上限および／または有効データ容量上限を超えたときに送信または受信すべきマルチメディアメッセージにおいて本来生じている有効データ容量を低減するために、少なくとも１つの低減アプリケーションが提供される。
【００１２】
送信または受信すべき個々のマルチメディアメッセージに対しこれらの低減アプリケーションをたとえば送信側がそれ相応の選択により適用すると、生じている占有有効データ容量を低減することができ、その結果、送信時または受信時の伝送コストを節約できるようになる。
【００１３】
さらに本発明は、本発明による方法を実施するよう構成された請求項４４による無線通信装置たとえば移動無線装置に関する。
【００１４】
従属請求項にはその他の実施形態が示されている。
【００１５】
次に、図面を参照しながら本発明ならびにその実施形態について詳しく説明する。
【図面の簡単な説明】
【００１６】
【図１】図１は、送信側と受信側との間の３ＧＰＰに従ったＭＭＳ（マルチメディアメッセージサービス Multimedia Messaging Service）ネットワークアーキテクチャの概略図である。
【図２】図２は、直線的な料金設定モデルと段階づけられた料金設定モデルとを対比して示す図であり、この場合、個々のマルチメディアメッセージ送信時の料金は、マルチメディアメッセージのデータ容量が大きくなるにつれて高くなる。
【図３】図３は、本発明による方法の１つの有利な実施例に関する時間的な流れをテキストで記述されたステップを用いて描いた図である。
【図４】図４は、本発明による方法に関する様々な変形実施形態を実行する際の移動無線通信装置のためのＨＭＩユニット（ＨＭＩ：マンマシンインタフェース "human machine interface"）の形態を例示した図である。
【図５】図５は、本発明による方法に関する様々な変形実施形態を実行する際の移動無線通信装置のためのＨＭＩユニット（ＨＭＩ：マンマシンインタフェース "human machine interface"）の形態を例示した図である。
【図６】図６は、本発明による方法に関する様々な変形実施形態を実行する際の移動無線通信装置のためのＨＭＩユニット（ＨＭＩ：マンマシンインタフェース "human machine interface"）の形態を例示した図である。
【実施例】
【００１７】
図１〜図６中、同じ機能および同じ作用をもつ要素にはそれぞれ同じ参照符号が付されている。
【００１８】
移動無線システムＧＳＭ（GSM : Global System for Mobile Communications）によれば音声電話機能のほか、１６０キャラクタ長までの短いテキストメッセージを送信したり受信したりすることもできるようになる。このサービスはＧＳＭ移動無線システムでは殊にＳＭＳ（SMS : Short Message Service）と呼ばれる（これについてはたとえば明細書末尾に挙げた参考文献［１］を参照されたい）。
【００１９】
次世代の移動無線システム（２．５Ｇおよび３Ｇ）たとえばＵＭＴＳ（UMTS : Universal Mobile Telecommunications System）のために現在、移動体メッセージサービスのマルチメディア対応バリエーションが標準化されており、これはいわゆるＭＭＳ（Multimedia Messaging Service 明細書末尾に挙げた参考文献［２］および［３］を参照されたい）である。以下ではＳＭＳのテキストメッセージと区別しやすくするため、マルチメディアコンテンツをもつメッセージのことを略して単にＭＭ（MM : Multimedia Message）と称する。ＳＭＳとは異なり、純粋なテキストコンテンツという制約がなくなる。ＭＭＳ（Multimedia Messaging Service）の場合、ユーザは自身のテキストの書式を固有に設定することができ、および／またはオーディオデータおよび／またはビデオデータならびにその他の通信要素を１つのメッセージに埋め込むことができる。したがって１つのマルチメディアメッセージは、様々なファイルタイプ（たとえばオーディオまたは静止画）および／または様々なファイルフォーマット（たとえば静止画であればGIFやJPEG）をもつ複数のマルチメディアメッセージエレメントから合成されている可能性がある。
【００２０】
図１には、現在の技術水準によるＭＭＳネットワークアーキテクチャが３ＧＰＰの視点から描かれている。ここではたとえばマルチメディアメッセージＭＭが第１のいわゆるＭＭＳユーザエージェントＡから第２のＭＭＳユーザエージェントＢへ、それぞれ送信側もしくは受信側に割り当てられたＭＭＳリレー／サーバのＲＡもしくはＲＢが関与しながら伝送される。詳しくは、マルチメディアメッセージＭＭの伝送方向で見るとリレー／サーバＲＡはユーザエージェントＡの後方でネットワーク側に配置されている。そしてリレー／サーバＲＢは第２の受信側のユーザエージェントの前方でネットワーク側に配置されている。図１では、ユーザエージェントＡと送信側に配置されているＭＭＳリレー／サーバＲＡとの間の個々のインタフェース接続をＭＭ１と称し、ユーザエージェントＢと受信側に配置されているＭＭＳリレー／サーバＲＢをＭＭ１＊と称する。リレー／サーバＲＡとリレー／サーバＲＢ双方の間のインタフェースＭＭ４におけるプロトコルとして、ＳＭＴＰ（simple mail transfer protocol）が採用される。個々のＭＭＳユーザエージェントＡもしくはＢとは有利には、ＭＭＳを実現するアプリケーションもしくはシーケンスプロシージャのことである。このアプリケーションは殊にソフトウェアプログラムとして、送信側で関与する個々の無線通信装置、送信側でそれに割り当てられたＭＭＳリレー／サーバ、受信側で関与する個々の無線通信装置、および／または受信側でそれに割り当てられたＭＭＳリレー／サーバにインプリメントされている。この場合、個々の無線通信装置を有利には移動無線装置として構成することができる。択一的に個々のＭＭＳユーザエージェントを、移動無線装置に接続された機器（たとえばラップトップコンピュータ等）にインプリメントしておくことができる。ＭＭＳリレー／サーバは、ここではたとえばＰＡ，ＰＢなどのような個々のＭＭＳプロバイダの管轄領域（MMSE - Multimedia Messaging Service Environment）においてＭＭＳユーザエージェントＡ，ＢにＭＭＳ機能を提供するネットワーク要素である。
【００２１】
ＭＭＳプロバイダもしくはサービスプロバイダは、新たなサービス提供ＭＭＳのための料金設定モデルとして、マルチメディアメッセージの送付を送信側の勘定につける（原則："sending party pays" すなわちそれぞれ送信する側が支払う）ようにすることができる。他方、必要に応じて、マルチメディアメッセージの受信側に対し、この受信側宛のマルチメディアメッセージが受信側に割り当てられたＭＭＳリレー／サーバに存在するという通知を受信することについて、および／またはこのマルチメディアメッセージにおける１つまたは複数のメッセージ要素を受信側ＭＭＳリレー／サーバからダウンロードすることについて、課金することもでき、すなわち受信側の勘定につけることもできる。
【００２２】
ＧＳＭＡ（Global System for Mobile Communications Association ＧＳＭ移動無線ネットワーク業者による世界規模の利益協同体）の将来のＭＭＳプロバイダにとって殊に関心があるのは、以下で「ＭＭ容量クラス」"MM volume Class" と称する方式に基づく料金設定モデルである。この方式の基礎となる着想は、伝送すべきまたは受信すべき個々のマルチメディアメッセージを、コスト決算における透明性向上の目的でマルチメディアメッセージの占有する有効データ容量もしくはそのサイズに基づき、事前に定義された複数の有効データ容量クラスいわゆるＭＭ容量クラスに割り当てることであり、このクラスは特定の価格カテゴリーもしくは価格クラスに属している（図２の右側の図ＧＴＭを参照）。ここで個々のマルチメディアメッセージの有効データ容量もしくはサイズとは本発明においては、個々のマルチメディアメッセージにおける複数のコンポーネントもしくは複数のメッセージ要素のバイトまたはビットの総計のことである。実践において、ＭＭＳにおける有効データ容量ディメンションの区分をたとえば３〜４とすることができ、したがって総括的に見えることのできるＭＭＳ容量クラスが有利である。図２の右側には、このように段階づけられた料金システムに関するダイアグラムＧＴＭが描かれている。横軸に沿って、ｍａｘ＝４とする複数の閾値Ｇ１〜Ｇｍａｘが書き込まれている。このダイアグラムの縦軸に沿って、これらの有効データ容量閾値に対しｘ＝１〜５とする価格もしくはコスト値が対応づけられている。たとえばＧ１，Ｇ２などのようにそれぞれ対応づけられた２つの価格の間では、たとえばＰ３などのようにそれぞれ対応づけられた価格クラスもしくはコストクラスは一定である。したがって全体としてみると、有効データ容量クラスが高くなるにつれて価格クラスが段階的に上昇する料金システムが形成されている。つまりたとえばＧ１のような個々のデータ容量閾値を超えると、価格Ｐｘはまえもって設定可能な所定の価格の金額だけ上昇する。たとえば有効データ容量が閾値Ｇ２を超えると、価格はＰ３からＰ４＞Ｐ３に上昇する。したがって全体として、１つ上の有効データ容量閾値Ｇ１〜Ｇ４に順次上昇していく階段状カーブもしくはバー状のカーブが対応する価格Ｐｘについて生じることになり、つまりはたとえば０〜Ｇ１，Ｇ１〜Ｇ２，Ｇ２〜Ｇ３．．．という具合に続く有効データ容量範囲に依存する価格の階段状化が生じる。この場合、それぞれ伝送すべきまたは受信すべきマルチメディアメッセージのデータ容量もしくはサイズが閾値を超えるたびに、マルチメディアメッセージはその伝送コストに関してそれまでの価格段階Ｐｘから１つ上の価格段階Ｐｘ＋１へと移行する。閾値超過ごとに殊にそれぞれ１つの一定の価格上昇額を選択するならば、階段状カーブは一次近似において直線的に上昇する。
【００２３】
このようなアプローチにおける欠点は、有効データが有効データ容量ディメンションＶＯＬにおける閾値Ｇｘ（ｘ＝１〜ｍａｘ、ｍａｘは定義された閾値の最大数を表す）を超えるたびに、個々のマルチメディアメッセージがいっそう高い価格カテゴリーＰｘ（ｘ＝１〜ｍａｘ；図２ではたとえばｍａｘ＝５）に高められることである。この場合、あるマルチメディアメッセージが低い方の価格カテゴリーＰｘに属するのか高い方の価格カテゴリーＰｘに属するのかに関して、ただ１つの付加的なビットまたはバイトが決定的な意味をもつ可能性がある。一般に次のことがあてはまる。すなわち、有効データ容量ディメンションＶＯＬにおける閾値Ｇｘの個数が少なくなればなるほど、マルチメディアメッセージの送信側または受信側がマルチメディアメッセージの現在の価格カテゴリーにより設定された個々の段階の最大有効データ容量ＶＯＬを最適には利用しきれず、すなわち不完全にしか利用できずもしくは占有せず（図２の右側のダイアグラムを参照）、したがっていっしょに支払う伝送容量を無駄にする確率が高くなる。有効データ容量ディメンションの閾値Ｇｘと対応づけられた価格カテゴリーの個数を増やしていくならば、図２左側のダイアグラムＬＴＭに描かれているように、対応づけられた価格Ｐの直線的な経過に近づけることができる。この左側のダイアグラムによれば、それぞれ伝送すべきマルチメディアメッセージの有効データ容量に伴い価格Ｐは連続的にしかも直線的に上昇する。この場合、最大有効データ容量Ｇｍａｘに最大価格Ｐｍａｘが割り当てられている。したがって図２右側のダイアグラムＧＴＭの両方の軸において有効データ容量閾値範囲Ｇｘ−Ｇ（ｘ−１）および対応する価格カテゴリーＰｘの増加分を十分に小さくすれば、有効データ容量ＶＯＬとそれらに割り当てられた価格Ｐとの間の図２のダイアグラムＬＴＭの直線的な経過特性Ｌ１が近似的に達成される。とはいえこのような料金体系は、将来のＭＭＳプロバイダの経済利益とは相容れないものである。しかも決算のための価格と有効データ容量とのこのような連続的な対応づけは個々のプロバイダ側からすれば煩雑すぎるし、個々のユーザにとっても見通しが悪すぎる。
【００２４】
つまり図２の左側のダイアグラムＬＴＭには理想の直線的な料金設定モデルが描かれているのに対し、図２の右側には実際の階段状の料金設定モデルが描かれている。これら両方の事例ともに、そのつど送信または受信すべきマルチメディアメッセージにおいて生じている占有データ容量ＶＯＬが大きくなればなるほど、マルチメディアメッセージ送付時の価格が高くなる。
【００２５】
以下では一例として１つのマルチメディアメッセージを送付する事例を挙げながら、マルチメディアメッセージをできるかぎりデータ容量効率を高めひいては好適なコストで送信できるようにする目的で、ＭＭＳ対応の通信端末機器有利には無線通信装置のユーザに対しいわゆるＨＭＩユニット（HMI - Human Machine Interface）を介して種々の判定補助をどのようにして提示できるのかについて、様々な有利な可能性を述べることにする。さらにここでは、送信すべきマルチメディアメッセージにおいてもともと生じていた有効データ容量を上述のＭＭ容量クラス方式による料金モデルにおいて送信前に最適化する有利な方法についても立ち入ることにする。送信時例に関するステップはそれ相応のやり方で受信事例にも転用可能であり、その場合、無線通信装置は自身のＭＭＳユーザエージェントを介して、受信側のＭＭＳリレー／サーバ上に到来している１つのマルチメディアメッセージあるいはそのうちの１つまたは複数の要素を受け取る準備ができているという通知を受信する。そのつど関与する無線通信装置として、たとえば移動局もしくは移動無線装置が利用される。
【００２６】
最終的に採用した料金設定モデル（直線的または階段状）とは無関係に、ＭＭなどのようなマルチメディアメッセージの送信側にとって常に好適であるのは、このマルチメディアメッセージの編集前、編集中および／または編集後に自身の端末機器において、その送信にどれくらいのコストがかかるかを見積もれるようにすることである。このことはＭＭ容量クラスをベースとした料金設定モデルについて殊にあてはまる。なぜならばその場合には、ＭＭなどのような個々のマルチメディアメッセージの送信側が現在のすなわちもともと割り当てられている価格カテゴリーＰｘの有効データ容量ＶＯＬを最適には利用し尽くしていないこと、すなわち計算される価格カテゴリーと結びつけられたもしくはそれに対応するデータ容量ＶＯＬにおいて空いたまま残された部分を無駄に支払うことがクリティカルになる可能性があるからである。いっしょに支払われることになるこのような空き容量は、そのつど伝送すべきマルチメディアメッセージの実際に目下存在しているデータ容量と、存在しているそのデータ容量に対応して計算される価格カテゴリーＰｘと１つ上の価格カテゴリーＰｘ＋１との境界を成すデータ容量閾値の差によって形成される。
【００２７】
本発明による方法の１つの有利な実施形態によれば、個々のマルチメディアメッセージの編集中もしくは編集後、時間的に相前後する以下の個別ステップを含むステップシーケンスを実施するのが好適である（図３参照）。
ａ）ＭＭのようなそのつど生じる送信すべきマルチメディアメッセージにおいてもともと存在する占有有効データ容量ＶＯＬを求める。
ｂ）ＭＭのような送信すべきマルチメディアメッセージの求められた有効データ容量ＶＯＬを適切な価格クラスつまり価格カテゴリーＰｘに対応づける。
ｃ）そのつど設定されている料金体系に基づき送信すべきマルチメディアメッセージにおいてもともと生じていた占有有効データ容量に割り当てられた目下の価格クラスＰｘについてまだ空いている有効データ容量ＦＶＯＬを計算する。この目的で、所定の料金体系において１つ上の価格クラスＰｘ＋１に割り当てられる有効データ容量Ｇｘ＋１と現在生じているマルチメディアメッセージの有効データ容量ＶＯＬとの差を計算する。
ｄ）ユーザ定義の価格上限および／または有効データ容量上限を場合によっては超えていないかを検出し、必要に応じてそのことをユーザに注意喚起する。
ｅ）ステップａ）による検出の結果、および／またはステップｂ）による割り当て、および／またはステップｃ）による計算、および／または場合によって生じる可能性のあるステップｄ）による超過を、音響的、触覚的および／またはグラフィック形態で表示する。
ｆ）送信すべきマルチメディアメッセージにおいてもともと存在している有効データ容量を削減もしくは低減する１つまたは複数の提案をユーザに提示し、ここで優先的に目標としているのは、このマルチメディアメッセージを所定の料金体系においてもっと低いカテゴリーに所属させることである。
ｇ）送信すべきマルチメディアメッセージの有効データ容量の低減を実行し、これが目標としているのはやはり、このマルチメディアメッセージを所定の料金体系にもっと低い価格カテゴリーに所属させることである。
【００２８】
有利であるのは１つの変形実施形態において、すべてのステップａ）〜ｇ）をそのつど送信側のＭＭＳユーザエージェントにおいてじかに実行することである。しかしながらこれに対する代案として好適であるのは１つの変形実施形態において、ステップａ）〜ｇ）を少なくとも１つの固有の、すなわちＭＭＳユーザエージェントとは無関係な少なくとも１つの固有の機能ユニットにより実行することである。場合によっては両方の事例において有利となる可能性があるのは、ステップａ）〜ｇ）の一部分だけを実行することである。たとえば送信すべきマルチメディアメッセージの占有有効データ容量に属する現在の価格クラスを求め、求められた現在の価格カテゴリーに対してまだ空いている有効データ容量を計算し、これらの情報すべてを表示し、さらにユーザ定義された価格上限および／または有効データ容量上限の超過が場合によっては発生したことに関する通報が、基本ステップとして有利である。
【００２９】
固有の機能ユニットにより実行されるステップにおいて、この機能ユニットに対し好適にはＭＭＳユーザエージェントから（対応する機能ユニットの機能もしくは役割に従い）特定の情報が供給され、たとえばＭＭＳユーザエージェントから求められたそのつど送信すべきマルチメディアメッセージの占有有効データ容量が供給され、あるいは送信のために全体的または部分的に編集済みのマルチメディアメッセージ自体が供給される。
【００３０】
両方の事例において（すべてのステップが送信側通信ユニットのＭＭＳユーザエージェント（図１のＡ参照）において実行されるか、あるいはいくつかのステップまたはすべてのステップが少なくとも１つの固有の機能ユニットにより実行される）、好適にはＭＭＳユーザエージェントまたは少なくとも１つの固有の機能ユニットは、そのつど送信すべきマルチメディアメッセージの求められた有効データ容量を１つの価格クラスに割り当てる目的で、所定の料金体系における特定の情報にアクセスし、たとえば図２のＧＴＭのような料金／有効データテーブルにアクセスし、および／または場合によっては超過を指示できるようにする目的で、ユーザがセットした価格上限および／または有効データ容量上限にアクセスする。
【００３１】
このような情報は、個々の通信端末機器の内部記憶領域に格納しておくことができ、あるいはケーブル、電気接点または無線を介して端末機器と接続可能な外部記憶ユニットに格納しておくことができる。
【００３２】
外部記憶ユニットにデータを格納するための格別有利な実施形態によれば、外部記憶ユニットは集積メモリカード（いわゆるスマートカード Smartcard）であり、たとえばＳＩＭ（subscriber identy module）カードまたは（Ｕ）ＳＩＭをもつＵＩＣＣカードであり、これは移動端末機器に差し込まれる。つまりこのようなカード上に、もっぱらネットワーク業者だけによって書き込み可能なもしくは更新可能な記憶領域と、ユーザが書き込み権限と読み出し権限をもつ記憶領域とが存在している。前者の記憶領域は、たとえばＭＭ容量クラスの方式に基づく個々のＭＭＳプロバイダの固有のＭＭＳ料金情報を記憶しあとからＯＴＡ更新（OTA = "over the air"）するのに殊に良好に適している。後者の記憶領域は、ユーザ定義の価格上限および／またはユーザデータ容量上限の記憶に適している。ネットワーク業者の料金情報がＳＩＭカードもしくは（Ｕ）ＳＩＭをもつＵＩＣＣカードに格納されているこの実施形態は、ＯＴＡ更新が可能なことから常に最新の料金を上述の計算や比較に利用できる点で有利である。
【００３３】
個々のＭＭＳユーザエージェントとは無関係な機能ユニットにおいて上述のステップのいくつかまたは複数を実施するための１つの有利な実施形態によれば、個々のマルチメディアメッセージのデータ容量を低減するアプリケーションもＳＩＭカード（ＳＡＴアプリケーション）または（Ｕ）ＳＩＭをもつＵＩＣＣ（ＣＡＴもしくは（Ｕ）ＳＡＴアプリケーション）上で実施される。
【００３４】
さらに個々の端末機器または外部記憶ユニット（たとえばＳＩＭカードまたは（Ｕ）ＳＩＭをもつＵＩＣＣ）に格納されている料金情報の更新を、無線ネットワーク内の端末機器とサーバとの間の一般的なデータコネクションを利用しエアインタフェースを介して行うこともできる。このアクションを選択的に個々の端末機器における無線ユニットにより導入することもできるし（"PULL"）またはネットワークにおけるサーバによって導入することもできる（"Push"サービス）。
【００３５】
すでに手短に説明した個々のステップａ）〜ｇ）について、次に図３を参照しながら詳しく説明する。
【００３６】
はじめにたとえばＭＭのようなマルチメディアメッセージが、送信側の無線通信装置のＭＭＳユーザエージェントたとえば図１のＡにおいて送信用に編集される。その際、この種のマルチメディアメッセージは基本的に、主としてマルチメディアメッセージの伝送もしくは管理用の情報が含まれているヘッダ（"header"）といわゆるボディ（"body part"）とによって構成されており、ボディには複数のマルチメディアメッセージ要素（すなわち固有の有効データ）を含めることができ、ここでは冒頭で説明したような様々なファイルタイプおよびファイルフォーマットを利用することができる。
【００３７】
たとえばＭＭのようなマルチメディアメッセージの有効データ容量ＶＯＬが求められ（図３のステップＳ１）、これはたとえば個々のＭＭ要素のすべてのデータ容量ならびにマルチメディアメッセージのテーマを表す名称「件名」をもつヘッダフィールドのサイズを総計することによって計算される。好適には、マルチメディアメッセージの宛先指定のためのヘッダフィールド（たとえば"Cc"および"Bcc"）の長さもしくはサイズ、ならびに場合によってはマルチメディアメッセージ中に含まれるプレゼンテーション記述（たとえばＳＭＩＬプレゼンテーション（SMIL - Synchronized Multimedia Integration Language 文献［４］を参照）を、送信すべきマルチメディアメッセージの有効データ容量の計算にいっしょに含めるようにしてもよい。
【００３８】
送信すべきマルチメディアメッセージＭＭにおいて現在生じている有効データ容量ＶＯＬが図３のステップＳ１に従い求められ、したがってそれが既知になると、簡単なやり方でたとえば図２のＧＴＭのような格納されている料金テーブルなどに基づき、それに属する価格カテゴリーを求めることができる（図３のステップＳ２を参照）。同様に、まだ空いているすなわち未使用の有効データ容量ＦＶＯＬを、料金テーブルに基づきもともと存在している有効データ容量に対応づけられている価格クラスについて計算することもできる。この場合、空きの有効データ容量ＦＶＯＬは、マルチメディアメッセージＭＭが１つ高い価格カテゴリーに属するまで最大で補うことのできるバイト数に相応する（図３のステップＳ３を参照）。その後、有利には求められた有効データ容量ＶＯＬおよび／または対応づけられた価格クラスＰｘが、まえもって定義されたすなわち設定可能な有効データ容量上限および／または価格上限ＳＧｘ，ＳＰｘと比較される（図３のステップＳ４を参照）。設定されたこれらの上限のうち一方を超えると、有効データの低減が可能であるかおよびどのようにして可能であるかについて、マルチメディアメッセージＭＭが有利には自動的に調べられる。理想的にはこの目的で、各マルチメディアメッセージ要素が個別に考察される。その際、事前に定義される有効データ容量上限および／または価格上限を、
ａ）個々のユーザにより、および／または
ｂ）個々のＭＭＳプロバイダにより
規定しておくことができる。
【００３９】
以下の例では、１つのファイルのデータ容量を低減するための様々な有利な可能性について説明する：
ａ）ファイルタイプ変換（たとえばタイプ「ムービー」をタイプ「静止画」の複数のファイルに変換して、画像シーケンスから複数のいわゆる「スナップショット」を作成）；
ｂ）ファイルフォーマット変換（たとえばタイプ「静止画」であればＢＭＰからＪＰＧへの変換、タイプ「音声」であればＷＡＶからＭＰ３）への変換）、静止画であればたとえば色の深さおよび／またはサイズを低減することも可能：
ｃ）ここで明示的に挙げた可能性のほか、さらに別のデータ圧縮法も存在する。さらに複数の変換技術を相互に組み合わせることもできる（たとえば最初に画像サイズを変更し、次にファイルフォーマット変換を実施する）。
【００４０】
ここで触れた圧縮技術はファイルフォーマット変換のサブセットを成しており、ファイルサイズの低減という目標を優先的にもつものである。これらの技術のうち多くのものによれば、たとえば圧縮比１０：１が達成され、一部ではそれよりもさらに高い圧縮比が達成される。
【００４１】
ついで（場合によっては個々の送信側における再問い合わせ後および場合によっては送信側による確認後）好適にはそれぞれ調べられたマルチメディアメッセージたとえばＭＭの有効データ容量ＶＯＬが低減され（図３のステップＳ５参照）、その際、少なくとも１つのマルチメディアメッセージ要素のサイズが（たとえば変換／圧縮により）低減され、少なくとも１つの変形されたマルチメディアメッセージ要素から成る少なくとも１つのいっそう小さい新たなマルチメディアメッセージが作成される（図３のステップＳ６参照）。その後、有効データ容量に関して低減された１つまたは複数のメッセージ要素をもつこのようにして変形されたマルチメディアメッセージが、有利には送信に対し択一的に送信側に提示される（図３のステップＳ７参照）。
【００４２】
時間的に相前後して行われるこれらのステップＳ１〜Ｓ７の個々のステップが終わるたびにオプションとして、マンマシンインタフェースＨＭＩを介してユーザへ出力メッセージを出すことができる。ＭＭのようなそのつど送信すべきマルチメディアメッセージに関して求められた有効データ容量ＶＯＬ、この有効データ容量に対応づけられた価格カテゴリーＰｘ、現在の価格カテゴリーではこれまで使われていなかった（つまりまだ空いている）有効データ容量ＦＶＯＬ、および／またはユーザ定義の価格上限および／または有効データ容量上限ＳＧｘ，ＳＰｘを、そのつど関与している無線通信装置のマンマシンインタフェースＨＭＩ（HMI - Human Machine Interface）によって出力するために、有利には棒グラフの形式で表示するのが適している。この種の棒グラフはそれぞれ図４〜図６の実施例に描かれており、参照符号ＢＫが付されている。
【００４３】
以下の２つの実施例では、送信側はマルチメディアメッセージＭＭを送信したいと望んでおり、このマルチメディアメッセージはたとえばテキスト要素と静止画というような２つのマルチメディアメッセージ要素を有している。
【００４４】
実施例１
想定：
−お金を節約するため、ユーザは最大限の状態で価格カテゴリーＰ２のマルチメディアメッセージを送信したい。
−ユーザ定義の価格上限ＳＰｘ＝Ｐ３をマルチメディアメッセージＭＭ編集時に超えてしまう。
−ユーザは、自身のマルチメディアメッセージＭＭの目下の有効データ容量ＶＯＬを低減するための提案を呈示させることができる。
【００４５】
ユーザは、２つのマルチメディアメッセージ要素（略してＭＭ要素）から成るマルチメディアメッセージＭＭを、プロシージャ「ＭＭコンポーザ」"MM composer" を用いてユーザ自身の固有の考えに従い編集する。最初のＭＭ要素はタイプ「テキスト」である。第２のＭＭ要素はＢＭＰフォーマットの静止画である。ついで送信側は、自身のマルチメディアメッセージＭＭのユーザデータ容量およびそれに属する価格カテゴリーを計算させる（図４の左側を参照）。その結果示されたのは、マルチメディアメッセージＭＭはユーザ定義の閾値ＳＰｘ＝Ｐ３を超えていることである。つまり図４にはマンマシンインタフェースＨＩＭの１形態（パート１）が例示されており、これによれば左側の図面に、伝達すべきマルチメディアメッセージの（有効）データ容量ＶＯＬを求めるときのメッセージが示されており、図４の右側の図面には、まえもって設定されている価格テーブルに基づき割り当てられた価格カテゴリーＰｘの送出された様子が示されている。つまりたとえば図２のＧＴＭに相応するようなプロバイダの所定の料金体系に基づき、マルチメディアメッセージの現在の有効データ容量がどの価格クラスに対応するのかが求められる。
【００４６】
送信側は自身の（通信装置の）マンマシンインタフェースＨＭＩを介してこのことについて知らされ、現在送信すべきマルチメディアメッセージＭＭに対する代案となる提案を呈示させたいのか質問される（図５の左側の図面）。テキストと非圧縮静止画とから成るここで考察しているマルチメディアメッセージＭＭに関して代案となる提案を作成するために、第２のＭＭ要素の圧縮が呈示される（たとえばＢＭＰからＪＰＧ）。図５の右側の図面には、これについて考えられる端末機器のＨＭＩの表示が描かれている。送信側はたとえば棒グラフＢＫに基づき、代案となるマルチメディアメッセージＭＭが所望の価格クラスＰ２内に収まっていることをただちに把握する。セットされたもしくは選択された閾値ＳＰｘ＝Ｐ３はもう超えていない。ここで送信側は、ＭＭＳユーザエージェントＡから本発明に従って変形されたマルチメディアメッセージＭＭを、情報内容を変えず自身が当初編集したときよりいっそう好適な条件で送信できるようになる。つまり図５に例示されているマンマシンインタフェースＨＭＩの１形態（パート２）によれば、その左側にＭＭがユーザ定義閾値を超えていることが示されており、右側には（有効）データ容量の低減されたＭＭの価格クラスの表示が示されている。
【００４７】
実施例２
想定：
−お金を節約するために、ユーザは最大限の状態で価格カテゴリーＰ２のマルチメディアメッセージを送信したい。
−個々のマルチメディアメッセージＭＭは価格カテゴリーＰ２に収まっているが、ユーザ定義の価格上限ＳＰｘ＝Ｐ２を著しく下回っている。
−ユーザは現在の価格カテゴリーＰ２内でこれまでは未使用であった有効データ容量ＦＯＬについて指摘される。
【００４８】
ユーザはＭＭのようなマルチメディアメッセージを編集し、その際、第１のＭＭ要素をタイプ「テキスト」のファイルによって構成しようとしている。送信側は、テキストが自身のマルチメディアメッセージをどの程度占めているのかについて（換言すればメッセージが定義された閾値Ｐ３よりも下にあるのかについて）不確かであるので、送信側ははじめに自身のマルチメディアメッセージの現在の有効データ容量ＶＯＬおよびそれに属する価格カテゴリーを求めさせ、つまり計算させる。計算結果がたとえば棒グラフＢＫによりユーザに示される。ここで送信側は、チェックされたマルチメディアメッセージが所望の価格クラス内にまだ収まっていることをただちに把握する（図６の左側）。さらに送信側は未使用の有効データ容量ＦＯＬについて通知され、安心してさらに第２のＭＭ要素（たとえばここでは３０ｋＢｙｔｅサイズの静止画）をマルチメディアメッセージに組み入れることができる。つまり図６に例示されているマンマシンインタフェースＨＭＩの１形態（パート３）によれば、左側には求められた価格カテゴリーの表示が描かれており、右側には、現在割り当てられている価格カテゴリーの有効データ容量がまだ完全には利用されていないことが示されている。
【００４９】
以上のことをまとめて考察してみると、そのつど伝送すべきマルチメディアメッセージの最適な準備処理は有利には以下の形式で達成される：
最初の改善のために十分であるのは、個々のマルチメディアメッセージの送信前、個々のマルチメディアメッセージの編集後および／または編集中、個々のマルチメディアメッセージの有効データ容量ＶＯＬを求めることである。ＳＧｘのような所定の有効データ容量上限を、またはＳＰｘのような所定の価格上限を場合によっては超えたときには、マルチメディアメッセージの有効データ容量の少なくとも１つの低減アプリケーションが提供される。その際、個々の上限を超えたことが個々のユーザに適切なかたちで注意喚起される。好適にはユーザに対し、そのつど送信すべきマルチメディアメッセージの有効データ容量を低減するための種々の可能性も、自身の通信装置のマンマシンインタフェースＨＭＩを介して選択および実施するために呈示される。
【００５０】
これらに加えてまたはこれとは無関係に、マルチメディアメッセージを受信すべきときにも同様の処理を行うことができる。
【００５１】
このように既述の方法は（最終的に選択されたＭＭＳ用料金モデルに依存することなく）有利である。それというのも、マルチメディアメッセージの個々の送信側または受信側に対し、個々の通信端末機器上で編集されているマルチメディアメッセージがどの程度のサイズであるのかについて、つまりそれが現在どの程度の有効データ容量を有しているかについて、高い信頼性を伴って通知することができるからである。これはたとえば、個々のマルチメディアメッセージのコンポーネントのバイトまたはビットの総計を表示することによって表すことができる。
【００５２】
ＭＭＳサービスに対しＭＭ容量クラスの非線形の方式による料金設定モデル（図２右側のダイアグラムを参照）を導入すれば、さらに別の利点が加わる。すなわちマルチメディアメッセージの送信側または受信側に対し、送信または受信すべきマルチメディアメッセージが本来の有効データ容量に関してどの割り当て価格カテゴリーに入っているかについて、およびこのマルチメディアメッセージの現在の価格カテゴリーが最適に利用されているのかについて、高い信頼性を伴って通知される。つまり現在の有効データ容量に対し所定の料金体系に基づき割り当てられた価格クラス内で、それまで占有されていない理由でどの程度の有効データＦＶＯＬを、マルチメディアメッセージが料金体系において１つ上の高い価格カテゴリーに属するまでにさらに補うことができるかが求められる。しかもマルチメディアメッセージの送信側に対し、自身によりまたはＭＭＳサービスプロバイダによってセットされた閾値たとえば価格カテゴリー閾値ＳＰｘおよび／または有効データ容量閾値ＳＧｘを超えたときに、常に警告を出すことができる（図３参照）。
【００５３】
このようにして、送信または受信すべきマルチメディアメッセージの送信側または受信側に対し、そのマルチメディアメッセージの有効データ容量を見積もるために、そして暗黙的には発生コストに関して、数多くの支援を呈示する有利な方法が提供される。
【００５４】
たとえば図２の右側の方式に従いＭＭ容量クラスの方式に応じてＭＭＳの料金設定が計画されている場合、マルチメディアメッセージの有効データ容量の自動的な適応をユーザ定義された限界値に基づき所期のように実施することができ、これによればマルチメディアメッセージをいっそう低い価格カテゴリーに属させることができ、ひいてはマルチメディアメッセージの送信コストを節約することができる。
【００５５】
この場合、マルチメディアメッセージにおいて求められた有効データ容量ＶＯＬは、それぞれまえもって設定されている料金体系においてたとえば図２のＰ１〜Ｐ５のような１つの選択された価格クラスに割り当てられる。好適には、個々に選択された上限（たとえばＳＧｘ）および／または特定の有効データ容量と結びつけられている価格上限（たとえばＳＰｘ）と対比して、個々のマルチメディアメッセージにおいてＦＶＯＬのようなまだ空いている有効データ容量が求められる。マルチメディアメッセージの未使用有効データ容量ＦＶＯＬが求められ、これが料金体系に基づき、目下占有しているマルチメディアメッセージにおける有効データ容量の価格クラスに割り当てられることができると有利である。場合によっては有利なやり方で、このような未使用の有効データ容量ＦＶＯＬを部分的にまたは全体的に別の有効データまたは付加的な情報によって満たすことができる。たとえば、選択された価格クラスたとえばＰ２などに対応づけられた有効データ容量上限ＳＧｘを場合によっては超過したときには好適には、個々のマルチメディアメッセージの有効データ容量ＶＯＬを低減するための少なくとも１つの低減アプリケーションが提供される。殊に好適であるのは、ユーザ定義の価格上限および／または有効データ容量上限ＳＧｘ，ＳＰｘを超えた場合にはそのことが注意喚起されるようにすることである。
【００５６】
たとえば以下のステップシーケンスが有利である。すなわち、
ａ）そのつど送信または受信すべきマルチメディアメッセージの有効データ容量ＶＯＬを求め、
ｂ）求められた有効データ容量ＶＯＬを、まえもって定められている料金体系に基づきたとえばＰ１〜Ｐ５のような価格クラスに割り当て、
ｃ）現在の価格クラスたとえばＰ２に関してまだ使用されていない有効データ容量ＶＯＬを求め、
ｄ）ユーザ定義された上限（価格上限および／または有効データ容量上限）たとえばＳＰｘ，ＳＧｘを超えた場合にはそのことを注意喚起し、
ｅ）ステップａ）による算出結果、および／またはステップｂ）による割り当て、および／またはステップｃ）による計算、および／またはステップｄ）による場合によっては発生する超過を、ユーザに対し音響的、触覚的またはグラフィックで表示し、
ｆ）マルチメディアメッセージをもっと低い価格カテゴリーに属させることを優先的な目標として、有効データ容量を低減するための少なくとも１つの提案をユーザに呈示し、
ｇ）ユーザによる確認後または自動的に、準備処理されたマルチメディアメッセージがもっと低い価格カテゴリーに属するよう有効データ容量の低減を実行する。
【００５７】
有利には、本発明による方法の様々な実施形態が（少なくとも１つの）ＭＭＳユーザエージェントにおいてそのまま実行される。これに対する代案として、上述の種々のステップあるいはそれらのステップのうちの一部分を、ＭＭＳユーザエージェントとは独立した少なくとも１つの固有の機能ユニットによって実行することもできる。この目的で好適であるのは、固有の機能ユニットに対し個々のＭＭＳユーザから、それにより求められたそのつど伝送すべきまたは受信すべきマルチメディアメッセージにおける有効データ容量ＶＯＬあるいは完全にまたは部分的に編集されたマルチメディアメッセージの有効データボリームＶＯＬが供給されることである。場合によっては好適であるのは、個々のＭＭＳユーザエージェントおよび／または少なくとも１つの固有の機能ユニットが特定の情報に対しアクセス権をもつことであり、たとえば求められた有効データ容量ＶＯＬをＰ１〜Ｐ５のような価格クラスに割り当てることができるようにする目的でテーブル形式のデータにアクセスしたり、あるいはユーザによりセットされた価格上限および／または有効データ容量上限たとえばＳＰｘ、ＳＧｘにアクセスして、超過が発生した場合にそれを指示できるようにする。有利であるのは、この種の情報を端末機器たとえば無線装置の内部メモリ領域に格納できることである。これに加えて、あるいはこれに対する代案として、ケーブルを介してまたは無線で端末機器と接続可能な外部記憶ユニットにこの種の情報を格納することができる。有利であるのは、外部記憶ユニットとしてＳＩＭカードまたは（Ｕ）ＳＩＭをもつＵＩＣＣカードを使用することであり、これらのカードは移動端末装置に差し込み可能である。
【００５８】
好適には、もっぱらネットワーク業者側だけにより書き込み可能もしくは更新可能な記憶領域が、固有のＭＭＳ料金情報の記憶ならびに後からのＯＴＡ更新のために用いられる。また、個々のユーザも書き込み権限および読み出し権限をもつ記憶領域を、ユーザ定義の価格上限および／または有効データ容量上限の記憶のために利用できると有利である。
【００５９】
実施する機能ユニットとして、たとえばＳＩＭカード上の低減アプリケーション（ＳＡＴアプリケーション）または（Ｕ）ＳＩＭをもつＵＩＣＣ（ＣＡＴもしくは（Ｕ）ＳＡＴアプリケーション）を使用することができる。
【００６０】
有効データ容量上限ＳＧｘおよび／または価格クラス上限ＳＰｘが超過し場合にそのことを指示する出力メッセージが、少なくとも１つのマンマシンインタフェースＨＭＩ（"human machine interface"）を介して有利には音響的または触覚的に、あるいはグラフィックでユーザに通知される。結果もしくは比較を視覚的に出力するために棒グラフが殊に適している。
【００６１】
マルチメディアメッセージの有効データ容量を低減するために殊にファイルタイプ変換、ファイルフォーマット変換、圧縮技術（データフォーマット変換のサブセット）を、および／または静止画であれば色の深さおよび／またはサイズの低減を、そのつど送信または受信すべきマルチメディアメッセージにおける少なくとも１つのマルチメディアメッセージ要素に適用することができる。好適には、１つのマルチメディアメッセージ要素の有効データ容量を低減するための少なくとも２つの可能性が互いに組み合わせられ、たとえば相前後して実行される。
【００６２】
１つのマルチメディアメッセージの有効データ容量ＶＯＬを、有利にはマルチメディアメッセージにおける個々のマルチメディアメッセージ要素のすべてのデータ容量を総計することによって求めることができる。場合によってこれに加えて部分的にまたは全体として、マルチメディアメッセージのヘッダ部分に場合によっては設けられている少なくとも１つのヘッダフィールドを有効データ容量計算時に考慮することができ、たとえばマルチメディアメッセージのテーマに関する「件名」ならびにマルチメディアメッセージの宛先指定のための"Cc"および"Bcc"といったヘッダフィールドのサイズを、有効データ容量計算時に考慮することができる。場合によってはマルチメディアメッセージ中に含まれているプレゼンテーション記述も、部分的にまたは全体的に有効データ容量の計算にあたりいっしょに取り込むことができる。
【００６３】
これまでの説明においてたとえば以下の関連文献を参照した：
[1] 3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS).
[2] 3GPP TS 22.140 version 4.1.0, Release 4; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS).
[3] 3GPP TS 23.140 version 5.1.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2.
[4] W3C Recommendation 15-June-1998: "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification" - http://www.w3.org/TR/REC-smil/.
【図１】
0005162493.tif 000002
【図２】
0005162493.tif 000003
【図３】
0005162493.tif 000004
【図４】
0005162493.tif 000005
【図５】
0005162493.tif 000006
【図６】
0005162493.tif 000007