(57)【特許請求の範囲】
【請求項１】
移動無線において音声付きおよび音声なしでテキストデータおよび／または画像データを伝送する方法において、
データに対し１つまたは複数のデータセットに関する少なくとも１つの識別信号（ｅ）が割り当てられて、該識別信号（ｅ）がデータ受信側へ伝送され、
該識別信号（ｅ）は部分的に送信側により生成され、部分的に前記サービスプロバイダ（ＭＭＳリレー）により生成され、
移動メッセージサービス（Mobile Messaging Service, MMS）に適用され、伝送されるデータは移動メッセージ（Mobile Message, MM）として構成され、
前記送信側により生成された前記１つまたは複数の識別信号（ｅ）は、送信側（ＭＭＳユーザエージェントＡ）からサービスプロバイダ（ＭＭＳリレー）へマルチメディアメッセージが伝達されるときに送られることを特徴とする、
データ伝送方法。
【請求項２】
前記識別信号（ｅ）が該識別信号（ｅ）により特徴づけられたデータセットの伝送前に伝送され、光学的または音響的に表示される、請求項１記載の方法。
【請求項３】
前記識別信号（ｅ）の受信側は、該識別信号（ｅ）により特徴づけられたデータの伝送を完全に許可するのか部分的に許可するのかを選択可能である、請求項２記載の方法。
【請求項４】
識別信号にはデータセットの種類に関する情報たとえばデータセットのデータフォーマットに関する情報が含まれている、請求項１から３のいずれか１項記載の方法。
【請求項５】
識別信号にはデータセットの名称に関する情報が含まれている、請求項１から４のいずれか１項記載の方法。
【請求項６】
識別信号にはデータセットの内容に関する情報が含まれている、請求項１から５のいずれか１項記載の方法。
【請求項７】
識別信号にはデータセットのサイズに関する情報が含まれている、請求項１から６のいずれか１項記載の方法。
【請求項８】
識別信号には伝送されるデータ内のデータセットの個数に関する情報が含まれている、請求項１から７のいずれか１項記載の方法。
【請求項９】
識別信号には、送信されるデータ内の少なくとも１つのデータセットとのリンクに関する情報が含まれている、請求項１から８のいずれか１項記載の方法。
【請求項１０】
識別信号には、送信されるデータ外の少なくとも１つのデータセットとのリンクに関する情報が含まれている、請求項１から９のいずれか１項記載の方法。
【請求項１１】
前記識別信号には、伝送されるデータセットとリンクされているデータセットのサイズに関する情報が含まれている、請求項９または１０記載の方法。
【請求項１２】
識別信号にはデータセットの識別子に関する情報が含まれている、請求項１から１１のいずれか１項記載の方法。
【請求項１３】
伝送標準ＵＭＴＳ（Universal Mobile Telecommunication System）、ＧＳＭ（Global system for mobile communication）、ＧＰＲＳ（General packet radio service）および／またはＥＤＧＥ（Enhanced Data Rates for GSM einviroments）に適用される、請求項１から１２のいずれか１項記載の方法。
【請求項１４】
１つまたは複数の識別信号が伝送データの１つまたは複数のヘッダフィールドに割り当てられる、請求項１から１３のいずれか１項記載の方法。
【請求項１５】
識別信号は少なくとも１つの付加的なヘッダフィールドに格納される、請求項１から１４のいずれか１項記載の方法。
【請求項１６】
送信側はヘッダフィールド Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−ＩＤ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｎａｍｅ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｔｙｐｅ、Ｘ−ＭＭＳ−Ｅｘｔｅｒｎａｌ−Ｌｉｎｋ−Ｆｌａｇ、Ｘ−ＭＭＳ−Ｅｘｔｅｒｎａｌ−Ｌｉｎｋ−Ｓｉｚｅのうちの１つまたは複数を生成する、請求項１５記載の方法。
【請求項１７】
識別信号は少なくとも部分的に、サービスプロバイダ（ＭＭＳリレー）から受け取ったデータセットから自主的に求められる、請求項１から１６のいずれか１項記載の方法。
【請求項１８】
ＭＭＳリレーはヘッダフィールド Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−ＩＤ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｓｉｚｅ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｔｙｐｅのうちの１つまたは複数を生成または更新する、請求項１７記載の方法。
【請求項１９】
１つまたは複数の識別信号（ｅ）はそれぞれ受信側（ＭＭＳユーザエージェントＢ）への通知にあたり、サービスプロバイダのＭＭＳリレーによって、１つのマルチメディアメッセージの１つまたは複数の新しいデータセットの存在に関して伝送される、請求項１から１８のいずれか１項記載の方法。
【請求項２０】
受信側の通信機器に１つの選択装置が設けられており、該選択装置により受信側は前記識別信号（ｅ）の少なくとも部分的な閲覧に従いデータセットに対する受信準備完了状態の確認応答を送出し、選択装置のトリガ後にはじめて受信装置への伝送が可能になる、請求項１から１９のいずれか１項記載の方法。
【請求項２１】
受信準備完了はデータの一部にのみ関連づけられ、データセットにおける該部分のみの伝送が許可される、請求項２０記載の方法。
【請求項２２】
準備されているデータに関する通知（Ｍ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ）と本来のデータ送達に関する通知（Ｍ−Ｒｅｔｒｉｅｖｅ．ｃｏｎｆ）に付加的な識別信号が加えられる、請求項１から２０のいずれか１項記載の方法。
【請求項２３】
準備されているデータを少なくとも部分的に受信するための準備完了状態が、受信側からプロバイダに送信されるメッセージＷＳＰ ＧＥＴ．ｒｅｑに割り当てられている、請求項１から２２のいずれか１項記載の方法。
【請求項２４】
請求項１から２３のいずれか１項記載の方法を実施するための移動通信装置（５；６）において、
１つまたは複数の識別されたデータセット（７）に対し完全にまたは部分的に受信準備が完了していることの承認または拒否を選択する選択スイッチ（２５）が設けられていることを特徴とする移動通信装置。
【請求項２５】
１つまたは複数のデータセット（７）の識別信号を視覚的または聴覚的に指示するための指示手段（２４）が設けられている、請求項２４記載の移動通信装置。
【請求項２６】
前記選択スイッチ（２５）はソフトウェア側でインプリメントされており、入力手段を介して選択可能である、請求項２４または２５記載の移動通信装置。
【請求項２７】
少なくとも１つの識別信号をデータ送達のヘッダフィールド（１７；１８；１９；２０；２１；２２；２３）に割り当てるソフトウェアが設けられている移動通信装置（５；６）。
【請求項２８】
コンピュータ読み取り可能な記録媒体において、
該記憶媒体上にプログラムが格納されており、該プログラムがコンピュータのメモリにロードされると該プログラムによってコンピュータは、移動無線ネットワークにおけるデータ伝送において伝送すべきデータとともに、１つまたは複数のデータセット（７）に対し特徴づけられた情報をもつ識別信号を個々の受信側（４）へ伝送し、該識別信号は部分的に送信側により生成され、部分的にサービスプロバイダ（ＭＭＳ）により生成され、
伝送されるデータは移動メッセージ（Mobile Message, MM）として構成されており、
前記送信側により生成された前記１つまたは複数の識別信号（ｅ）は、送信側（ＭＭＳユーザエージェントＡ）からサービスプロバイダ（ＭＭＳリレー）へマルチメディアメッセージが伝達されるときに送られることを特徴とする、
コンピュータ読み取り可能な記録媒体。
【請求項２９】
移動無線ネットワークにおけるデータ送信時に請求項１から２５のいずれか１項記載の方法を実施する、請求項２８記載のコンピュータ読み取り可能な記録媒体。
【請求項３０】
請求項１から２３のいずれか１項の記載に従って少なくとも１つのコンポーネントが動作する無線通信システム。
はデータ送信側が担うことになっている。
【発明の詳細な説明】
【０００１】
本発明は、請求項１の上位概念に記載の移動無線ネットワークにおけるデータ伝送方法、請求項２４の上位概念に記載の移動通信装置、請求項２８記載のコンピュータプログラム製品ならびに請求項３０記載の無線通信システムに関する。たとえばＧＳＭ標準に従い動作するネットワークのようなこれまでの移動無線ネットワークによって、まだかなり制約されているがテキストデータを伝送する可能性が開かれている。つまりたとえば１６０個のキャラクタまでのショートメッセージを伝送することができる。このような機構はＳＭＳ（ショートメッセージサービス Short Message Service）と呼ばれる。そしてこの種のテキストメッセージの送信コストはデータ送信側が担うことになっている。
【０００２】
将来は、マルチメディアデータたとえば音声付きまたは音声なしの静止画や動画の伝送も可能になるはずである。このような伝送においてはデータ伝送量やデータ形式の著しい拡大が見込まれ、これには伝送時間やコストの増大が伴う。
【０００３】
本発明の課題は、移動無線ネットワークの加入者のためのデータ伝送コントロールを簡単にすることにある。
【０００４】
本発明によればこの課題は、請求項１の特徴を備えた方法、請求項２４の特徴を備えた移動通信装置、請求項２８の特徴を備えたコンピュータプログラム製品、ならびに請求項３０記載の無線通信システムによって解決される。有利な実施形態については請求項２から２３、請求項２５から２７ならびに請求項２９を参照されたい。本発明の方法によれば、情報は受信のために用意されるデータの特性に関してデータ受信側へ情報を伝達することができ、これにより受信側にとってコントロールが簡単になる。
【０００５】
伝送すべきデータの特性を表す識別信号をまえもって送信することで、本来のデータの受信前にすでにコントロールが可能となり、その際に殊に有利であるのは、このようにして得られた情報に基づき、供給されるデータをいま受信したいのかあとで受信したいのか、それともまったく受信したくないのかという選択の余地が与えられることである。また、マルチメディアメッセージ（ＭＭ）を一部分だけ受信するという選択の可能性も与えられているならば、受信側はたとえば自身にとって重要な短い情報だけをダウンロードすることができ、そのような情報であれば短い伝送時間しか必要とせず、さらに必要に応じて多くのメモリを要する付加的な画像コンポーネント等をあとからダウンロードしてもよいし、あるいはそれらはまったくダウンロードしないようにすることができる。
【０００６】
このために使用される識別信号に受信すべきデータセットのサイズに関する情報が含まれているならば受信側は、データの伝送および／または調査にどの程度の時間を見込む必要があるのか、ならびにその時間をいま費やすのかあとで費やすのか、あるいは費やす意志がないのかについて確定することができる。
【０００７】
識別信号にデータセットの名称に関する情報が含まれているならば受信側は、データがどの複合テーマからのものであるのかを調べることができる。さらに有利には受信側は、それらのデータセットをいま受信したいのかあとで受信したいのか、あるいはまったく受信する意志がないのかを選択することができる。
【０００８】
さらに識別信号にデータ形式に関する情報も与えることができると殊に有利であり、これにより受信側は、たとえば画像データであるのかテキストデータであるのか、および／または音楽データであるのかを知るようになる。このようにしてコントロールおよびトランスペアレンスが格段に改善される。
【０００９】
図面に新たに描かれた後述の本発明対象に関する実施例によって、本発明のさらに別の利点や特徴がわかる。
【００１０】
図面
図１は、送信側レベルとプロバイダレベルとの間およびプロバイダレベルと受信側レベルとの間においてＷＡＰ（wireless application protocoll）に従って行われるデータ伝送に対応する送信を描いた図である。
【００１１】
図２は、図１に示したＷＡＰ標準に従って送信されるメッセージＭ−Ｓｅｎｄ．ｒｅｑのヘッダフィールドを示す図であり、ここでは本発明に従い新たに挿入されたヘッダフィールドにグレイが付されている。
【００１２】
図３は、図２で示しグレイの付されたフィールド内に格納された情報の形式ならびに送信データの受け取りに関してステータスレポート中に付加的に設けられたフィールドの指定を示す図である。
【００１３】
図４は、図２のヘッダフィールドをバイナリコードに割り当てる様子を示す図であって、ここでは本発明に従い新たに挿入されたヘッダフィールドにグレイが付されている。
【００１４】
図５は、図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ（ＭＮＩ）を図２と同様のかたちで示した図である。
【００１５】
図６は、図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｒｅｔｒｉｅｖｅ．ｃｏｎｆ（ＭＲＣ）を図２と同様のかたちで示した図である。
【００１６】
図７は、図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ａｃｋｎｏｗｌｅｄｇｅ．ｉｎｄ（ＭＡＩ）を図２と同様のかたちで示した図である。
【００１７】
図８は、図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｄｅｌｉｖｅｒｙ．ｉｎｄ（ＭＤＩ）を図２と同様のかたちで示した図である。
【００１８】
図９〜図１７ならびに図２３〜図２５は、本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【００１９】
図１８は、単一ヘッダフィールドネームの符号化について示す図である。
【００２０】
図１９は、図９による単一ヘッダフィールド中の新しいパラメータネームおよびパラメータ値の符号化（コーディング）について示す図である。
【００２１】
図２０は、バイナリコードを図９による単一ヘッダフィールド中のパラメータに割り当てる様子を示す図である。
【００２２】
図２１Ａ，２１Ｂは、マルチメディアサービス（ＭＭＳ）の送信問い合    ０わせ（ＷＡＰメッセージではＭ−Ｓｅｎｄ．ｒｅｑ；）における単一ヘッダフィールドを示す図である。
【００２３】
図２２は、図２１Ａ，図２１Ｂによる送信問い合わせＭＳｒｅｑに割り当てられたＭＭＳ受信側メッセージ（Ｍ−Ｎｉｎｄ；ＷＡＰメッセージではＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ；）のヘッダフィールドを示す図である。
【００２４】
図１〜図３中、同じ動作や機能をもつ構成要素にはそれぞれ同じ参照符号が付されている。
【００２５】
この実施例では、ＷＡＰ標準のためのデータ伝送スキーマ１に本発明を適用した事例について説明されており、これはたとえばＵＭＴＳ標準（universal mobile telecommunication standard）において殊に画像データや書式付きテキストデータの伝送において利用される。なお、本発明を他の標準にも転用できることは自明である。
【００２６】
ＵＭＴＳ標準の場合、従来のＳＭＳに加えてメッセージ伝送用のいわゆるＭＭＳ（Multimedia Messaging Service）も設けられており、これはマルチメディアメッセージ（ＭＭ）とも呼ばれる。これによって書式付きテキストや画像も音声付きまたは音声なしで伝送することができる。ＳＭＳにおいて設定されている１６０キャラクタのメッセージ長までという制約がなくなる。音声メッセージやビデオメッセージの伝送が可能となる。
【００２７】
ＭＭＳはＷＡＰを利用することによって実現できる。この場合、データたとえばマルチメディアメッセージ（Multimedia Message MM）の無線伝送のために、図１に示されているプロトコルスキーマ（WAP WSP: Wireless Session Protocoll）が用いられる。これにはデータ送信側のレベル２（ＭＭＳユーザエージェントＡとも呼ばれる）、サービスを実行しＭＭＳリレーとも呼ばれるプロバイダのレベル３および受信側のレベル４が含まれている。データ送信側のレベル２は少なくとも１つの通信機器５を有しており、さらに受信側のレベル４も通信機器６を有している。この通信機器５，６をたとえば一般的な携帯電話として構成することができるし、あるいはたとえばラップトップなど他の入力機能または出力機能を備えた機器として構成することができる。
【００２８】
送信側の通信機器５において作成されたまたはこの機器を介して転送すべきマルチメディアメッセージ（略してＭＭ）にはたとえばいくつかの画像、フィルムシーケンス、テキストなど１つまたは複数のユニット（データセット７）を含めることができる。ＭＭはまずはじめに問い合わせ送達９（これはＷＡＰプロトコルではM-Send.reqという名称をもつ）をプロバイダ（レベル３）へ送信する。
【００２９】
到来した送達９はそこから返送１０（M-send.conf）によって送信側（レベル２）へ確認応答される。
【００３０】
時間的にこれに続いて、プロバイダ（レベル３）から情報１１（M-Notification.ind）が受信側（レベル４）へ送信され、これによって受信側に対し、ダウンロード用のメッセージがプロバイダに用意されていることが通知される。
【００３１】
これによってプロバイダ３はたとえば自動的に、確認応答返送メッセージ１２（M-NotifyResp.req）を受信側の通信機器６（レベル４）から自動的に受け取る。
【００３２】
送達１３（WSP GET.req）を用いた受信側の要求に応じてはじめて、プロバイダから送達１４（M-retrieve.com）によりＭＭが受信側へ転送される。
【００３３】
メッセージ１５（M-Acknowledge.ind）はＭＭの受信について確認応答する。続くメッセージ１６（M-Delivery.ind）によって受信確認応答が送信側２へ戻される。
【００３４】
送達９，１０，１１，１２，１５，１６を管理するためにいわゆるヘッダフィールドが用いられ、つまりこれは本来のＭＭの前に置かれたフィールドであり、これらのフィールドには発信元、送信時刻、ファイルサイズおよび他の詳細な点に関する情報を含めることができる。
【００３５】
本発明によればヘッダフィールドの個数が増やされ、その目的は、ＭＭの特徴パラメータに関する情報フィールドとして少なくとも１つの別のフィールド１７，１８，１９，２０，２１，２２，２３を通知できるようにするためであり、そこにおいて１つまたは複数の識別信号をそれらのパラメータのために受信側４へ送信できるようにするためである。
【００３６】
実施例ではこのために０ｘ８０〜０ｘ８６までの１６進数体系でアドレッシングされるフィールド１７，１８，１９，２０，２１，２２，２３が設けられており（図４参照）、その目的はあとで詳しく説明するパラメータに関する情報を収容するためである。付加的なヘッダフィールドの個数やアドレッシングをこれとは異なるようにしてもよい。
【００３７】
付加的ないわゆるヘッダフィールド１７，１８，１９，２０，２１，２２，２３は少なくとも、受信側に対しＭＭが用意されていることを通知するメッセージ１１内に収容されている。メッセージ９（M-Send.req）も、付加的なパラメータが送信側２から生成されるならば、付加的なヘッダフィールド１７，１８，１９，２０，２１，２２，２３を含んでおり（図２）、さらに本来のＭＭ送達１４（M-Retrieve.conf）（図５参照）あるいは別のメッセージ１０，１２，１３，１５，１６も含んでいる。
【００３８】
ＭＭのデータセット７とは以下ではＭＭの個別の構成部分のことであるとし、これは形式（たとえば静止画）とフォーマット（たとえばＪＰＥＧ）によって定義されていて、この場合、ＭＭＳ内ではＭＭＳリレー３によるフォーマット変換も行われ、これによりある形式の特定のフォーマットしかサポートしない受信側４の通信装置６であっても、そのフォーマットだけで操作できるようになる。たとえば通信機器６はＪＰＥＧフォーマットの静止画だけしか表示できず、これは本出願ではＭＭＳリレー３に通知される。ＭＭＳリレー３はこの受信側のために到来するすべての静止画をＪＰＥｇフォーマットに変換し、これによって一般にデータサイズが変化する。このアスペクトは本発明による新たなヘッダフィールドの後述の説明で重要となる。
【００３９】
識別信号としてたとえばデータセット７に関する以下の情報を含めることができる。なお、これとは異なる個数の情報たとえば言及するもののうちいくつかの選択した情報のみとしてもよい。これらの情報は、オプションで通知１１（M-Notification.ind）においてＷＡＰ標準（図１）を使用したときにＭＭの受信側が利用でき、つまりはマルチメディアメッセージにおける本来のデータの伝送前に利用することができる。
【００４０】
受信側に事前に通知されるたとえばＭＭなどの伝送すべきデータの考えられるパラメータは以下のとおりである：
１．ＭＭに含まれるデータセット７の個数（これはＭＭの個々の要素の記述によっても暗黙的に示される）
２．データセット７の個々のサイズ（オクテット単位）
３．データセットの個々の形式およびフォーマット
４．データセットの個々のコンテンツＩＤ（Content Identification）、これは場合によってはＭＭ全体のコンテンツＩＤ／メッセージＩＤにも係わる
５．データセットの個々の名称
６．ＭＭ全体のテーマ
７．ある要素とＭＭにおける１つまたは複数の別のデータセット７とのリンク
８．ＭＭ全体または１つまたは複数のデータセット７とＭＭ外の１つまたは複数のＵＲＩとのリンク、この種の外部リンクの場合にはオプションとして解決された外部リンクのロードすべきデータのサイズ。
【００４１】
新しいヘッダフィールド１７，１８，９，２０，２１，２２，２３を用いて、ＭＭＳ内の詳細通知 "detailed Notification" の方式を変換することができ、ユーザに対するＭＭの快適性を高めることができる。ＭＭのロード前にすでに、つまりはユーザに対するコストが発生してしまう前に事前に、そのユーザにＭＭの内容および構成に関して詳しく通知して、それ相応に取り扱うことができ、たとえばＭＭの個々のデータセット７だけをダウンロードしその他を拒否するように処理することができる。
【００４２】
ＭＭは基本的に、ヘッダおよびＭＭの形式に依存して付加的にデータパート（WAP: Body）から成る。ヘッダは一般にＭＭの情報を有しており、これは定義されたヘッダフィールドによって構成されている。メッセージのデータパートには任意の形式（たとえばテキスト、画像、音声など）の１つまたは複数の要素が含まれており、これは任意の順序でヘッダに続いている。データパート中にプレゼンテーション記述が含まれているならば、ＷＡＰメッセージにおいてデータパートの最初にいわゆるスタートパラメータがこのプレゼンテーション記述を参照するようにすべきである。各ヘッダフィールドはフィールド名から成り、これにフィールド値が続き、このフィールド値は少なくとも１つのオクテットから成る。１６進数とフィールド名との対応づけは図４に示されている。
【００４３】
受信側への通知１１に所望の情報を添付するため基本的に２つの可能性がある。すなわち情報をプロバイダ３によって作成するか、あるいは送信側２によって作成する。ミックスフォームも可能である。詳細にはこのために以下のプロセスが考えられる：
情報はＭＭＳリレー３にメッセージ９とともに到来するＭＭから取り出され、すなわち一部はヘッダフィールドからそのまま引き継がれ、一部はＭＭのデータパートから計算される（たとえば１つのデータセット７のサイズ情報）。この過程で有利であるのは、メッセージ１１と受信側４（ユーザエージェントＢ）の要求に応じてそこへ伝送される実際の内容１４（WAP: M-Retrieve.conf）との間で予期される一貫性である。送信側２における実現コストつまりは移動端末機器におけるｉ．ｄ．Ｒは低いままである。別の利点は、フォーマット変換が行われるときにサイズ情報の精度に関して得られる。ＭＭＳの場合、データ供給前に内容をサービスプロバイダ３により、受信側のＭＭＳユーザエージェント４の能力（たとえばサポートされるコーデック、端末機器のディスプレイサイズ等）または受信側の好み（最大サイズに合わせた自動制限）に整合させることができる。ＭＭＳリレー３はデータ整合後の中味のサイズを受信側４に通知することができる。これは送信側２が所有していない情報である。欠点は、ＭＭＳリレー３においてこの「詳細情報 "detailed Notification"」のための情報を生成するために付加的なコストがかかることであり、これはMMに対し必要とされる「構文解析」と対応する情報の抽出によって生じる。
【００４４】
このようにするのではなく送信側２によってすでに情報を生成し、ヘッダフィールド１７；１８；１９；２０；２１；２２；２３としてＭＭ送信のためのメッセージ９（WAPではM-Send.req）に明示的に統合してもよい。有利なことにＭＭＳリレー３におけるＭＭの処理はそのままであり、これによってＭＭの中味を分析する必要がない。新たなヘッダフィールド１７；１８；１９；２０；２１；２２；２３により開かれる端末機器５における可能性の実現はメーカによって決定できる。しかも、快適性に関して様々な特徴をもつ端末機器を提供することができる。さらにＭＭ送信側の加入者２は、ＭＭ要素の内部的および外部的な結合に関する知識をＭＭ受信側へ詳細情報として通報することができ、これはＭＭＳリレー３によってのみ転送される。データセット７の内部的および外部的な結合に関する知識を必要とするＭＭＳリレー３内でのヘッダフィールドの生成は、そこにおいて手間をかけてＭＭの構文解析をすることによってしか行えない。欠点はヘッダフィールドが部分的に冗長な情報によって拡張されることである。
【００４５】
したがって有利であるのは、一部は送信側のユーザエージェント２で一部はＭＭＳリレー３において情報を生成することであり、このためにはＭＭＳリレー３の側で送信側２により生成された既存のヘッダフィールドの更新も必要である。
【００４６】
付加的な情報の生成に関するこのようなミックスフォームのために、以下で説明する情報を次のように分けることができる：
送信側のユーザエージェント２における生成：
・X-Mms-Content-ID: 従来のＷＡＰ仕様では、データセット７に（たとえば個々の名称と形式とにより）固有の付加的なヘッダフィールドを割り当て、複数のデータセットを階層的に配置することができない。そのためＭＭをインターネットメール（MIME = Multipurpose Internet Mail Extensions による拡張を伴うRFC 822 に準拠したフォーマット）にトランスペアレントに変換するために、以下の前提を提案する：Ｅメールのいかなる拡張に対し場合によっては付加的にＥメールのデータパート中に符号化される情報（名称、形式等）はＭＭにもトランスペアレントに含まれる。各データセット７に一義的に対応づけられているＭＭのヘッダ中のコンテンツＩＤを参照指示として利用することができる。メッセージボディ（＝本来の通知情報を含むデータ構造セクション）をフィールドとして定義しておく必要があり、このフィールドはプレゼンテーション記述オブジェクトのコンテンツＩＤ（＝内容識別子）ＣＩを有しており、これによりそのオブジェクトへのアクセスが可能となる。このような取り決めによってＭＭＳリレーから任意の受信側へＭＭをトランスペアレントに伝送することができ、これはダイレクトに他のＭＭＳリレーを介して行ってもよいし、Ｅメールによりインターネットを介して行うこともできる。データセット７に対する一義的な対応づけは、送信側のユーザエージェント２からＭＭＳリレー３への最初の伝送のために絶対に必要である。
【００４７】
・X-Mms-Content-Type: これはデータセットの形式とフォーマットを表す。これらは送信時にすでにエントリすべきものである。なぜならばデータセット７はＥメールの場合に要に必ずしもファイル名を保持しておらず、そうなるとファイルの拡張（エクステンション、拡張子）によってあるフォーマットに対応づけることができない。ＭＭＳリレー３によるこのフィールドの更新は、フォーマットおよび／または形式を変換するときにのみ必要である。X-Mms-Content-Type は値または信号ＣＴＶによって表され定められる。
【００４８】
・X-Mms-Content-Size: データセット７のサイズ。これは値もしくは内容ＣＳＶによって表され定められる。
【００４９】
・X-Mms-Content-Name: データセット７の名称。この名称は送信側のユーザエージェント２にとってのみ既知であり、それゆえそのユーザエージェントによってセットする必要がある。それに対し内容ＣＮＶが割り当てられる。
【００５０】
・X-Mms-External-Link-Flag: データセット７はＭＭ外の内容へのリンクを有することを示す。この情報が送信側ユーザエージェント２によりセットされれば、ＭＭＳリレー３によるデータセット７の内容分析が不要となる。これには内容的に値またはキャラクタシーケンスＥＬＦが対応づけられている。
【００５１】
・X-Mms-External-Link-Size: これによってＭＭ外のリンクされた内容のサイズが表される。これは内容ＥＬＳにより示される。外部の内容のデータ量はリンク自体からは読み取れないので、この情報はユーザにとって重要である。この情報は、送信側のＭＭＳユーザエージェント２においてＭＭの生成時にすぐに生成することができる。択一的にＭＭＳリレー３によって生成することも可能であるが、そのためにはＭＭ全体の分析のほかにもサイズを求めるため参照指示されているオブジェクトへのアクセスも必要となる。
【００５２】
・X-Mms-Content-Related-URI: このフィールドの情報ＣＲＶは、データセット７が関連づけられている他の要素のロケーションを指示する。たとえばデータセット７には、オーディオコンテンツ、ビデオコンテンツまたは他のＭＭのコンテンツを伴う多の要素に関連するプレゼンテーション記述が含まれている。この情報の生成には、送信側のＭＭＳユーザエージェント２の側に存在するMMの要素の内部的な関連づけに関する情報が必要とされる一方、ＭＭＳリレー／サーバ３もしくは受信側４におけるＭＭ要素のポジションに関する情報も必要とされる。これらの情報は送信側ＭＭＳユーザエージェント２の側においてヘッダフィールド内でコーディングすることができ、ついでＭＭＳリレー３によって目下のポジションに基づき補正／更新することができ、その後、受信側ＭＭＳユーザエージェント４において評価することができる。
【００５３】
ＭＭＳリレー３における生成もしくは更新：
・X-Mms-Content-ID: ＭＭＳリレー３がデータセット７の形式および／またはフォーマットを変更する場合には、それ相応のコンテンツタイプ Content-Type の更新が行われる。
【００５４】
・X-Mms-Content-Size: これはデータセット７のサイズであり、オクテットで表される。ＭＭＳリレー３がデータセットの形式および／またはフォーマットを変更する場合にのみ、コンテンツサイズに係わる情報の更新が行われる。
【００５５】
ユーザ４がメッセージ１１（WAP: M-Notification.ind）により受け取った多種多様な情報にによって、たとえばソフトウェア側でメニューにインプリメントされ入力手段たとえばキーボードを介して操作されるセレクトスイッチ２５を介して、個々のデータセット７へのアクセスも可能となる。したがってダウンロード要求により、（たとえば同時に付随テキストがいっしょに伝送されない写真などの）そのつど所望のデータセット７のコンテンツＩＤを用い、ＷＡＰであれば命令１３WSP GET.reqによって部分的なダウンロードを指示することができる。
【００５６】
これを実現するためには、付加的なヘッダフィールドを部分的にＭＭ内で何度も使用しなければならないという基本的な問題を解消する必要がある（WAPであればたとえばＭＭの各データセット７のためのX-Mms-content-Name）。また、データセットの記述において該当するように複数のヘッダフィールドが内容的に関連しているならば、シンタックス上の対応づけも必要である。
【００５７】
基本的にＷＡＰ標準の場合にはヘッダフィールドの順序は問題にはならない。したがって情報の対応づけをヘッダ要素の順序に依存させてしまい、それが唯一通用するパスであるならば、複数のデータセット７の名称、サイズ、形式および／またはＵＲＩという情報の順序の変更によって、データセット７の記述の変化が引き起こされ、もしくは誤りが生じてしまうことになる。それというのもＷＡＰではヘッダ要素の階層構造は設けられていないからである。他方、ヘッダ要素の順序が重要ではないという命題は、複数のリストを含むＨＴＴＰヘッダをそれぞれただ１つの要素しかもたない複数のＷＳＰヘッダに変換すべきであり、その際にエントリの順序を維持すべきであるという命題と矛盾する。このような矛盾を開所する目的で、ヘッダ要素の順序の重要性を前提条件として必要とする体系を設計する。
【００５８】
個々のデータセット７の記述を制限するため、定義されたヘッダフィールドによってデータセット７の記述が始まるようにする必要があり、これはメッセージのヘッダの終わりに達するまで、あるいは定義されたタイプの次のヘッダフィールドにより別のデータセット７の記述開始がマークされるまで、後続のすべてのヘッダフィールドに対応づけられる。
【００５９】
データセット７の記述のために定義されたヘッダフィールドとしてフィールド１７：X-Mms-Content-IDが用いられる。その理由はこれには要素の一義的なアドレスが含まれているからである。データセット７の記述は基本的にこのフィールドにより導入され、それに応じて別のフィールドをオプションとして任意の順序で設けることができる。
【００６０】
ヘッダ中にメッセージ要素に対する一義的なマーク（コンテンツＩＤ Content-ID）と相応の参照指示をもつこの体系に対する代案として、ＭＭのデータパートにおける既述のデータセットまでオフセットの指示により動作する体系も考えられる。とはいえこの場合の欠点は、オフセットが適正には計算されないおそれがあること、もしくはＭＭＳリレー３においてフォーマット変換が可能であれば適正に整合できないおそれがあることであり、他方、メッセージ１１におけるデータセットの記述とＭＭの実際の送達１４におけるデータセットの記述との間の論理的な関係を確立できなくなることである。この場合、情報を通達されたマルチメディアメッセージにもう一度入れておかなければならない。
【００６１】
送信側（レベル２）は通信機器５においてハードウェア側であるいは殊にソフトウェア側でいずれにせよ設けられているキーボードを介して、扱うべき入力オプションを操作することができ、これによりヘッダフィールド１７，１８，１９，２０，２１，２２，２３中に付加的な情報またはその一部分（s.o.）を格納することができる。これらはＭＭの１つまたは複数のデータセット７のための識別信号の構成部分として、送達９（WAPではM-Send.req 図１）とともにプロバイダ（レベル３）に送られる。ＭＭＳリレー３による送達の確認応答（WAP ではメッセージ１０：M-Send.conf）はそのまま維持される。なぜならばオプションとしてＭＭＳリレー３から与えられるメッセージＩＤが唯一の重要な情報だからである。
【００６２】
ついで受信側４は、この受信側に対し１つまたは複数のデータセット７をもつＭＭがダウンロード用に用意されているというメッセージ１１（WAPではNotification.ind）を受け取る。このメッセージ１１にはやはり、メッセージ９のヘッダからデータセット７を記述するために送達（WAPではM-Send.req）に対し付加的なすべてのヘッダフィールド１７，１８，１９，２０，２１，２２，２３が含まれている。この情報を受信側にオプションとして視覚的に（表示手段２４たとえばディスプレイを介して）または聴覚的に通知することができる。
【００６３】
メッセージ Notification １１に対する受信側の確認応答１２はそのまま変わらない。ＭＭの受信側４に対しそれらの内容について詳細に通知された後、受信側ＭＭ（WAPでは命令１３：WSP Get.req）をダウンロードすることができる。これに対する代案として本発明によれば、ＭＭのあだ１つの要素へのアクセスも可能である。この目的でたとえばＵＲＩとしてＭＭのデータセット７のコンテンツＩＤ Content-ID がダウンロード命令に組み込まれる。受信側４の了解なしにはＭＭのダウンロード（受信側への送達４の伝送）は許可されない。また、受信側４はＭＭを以降の任意の時点ではじめて伝達を希望することも可能である。
【００６４】
本来のデータ送達１４は既述のヘッダフィールド１７，１８，１９，２０，２１，２２，２３を有することができる。しかし図７に示されているようにこれは必須ではない。
【００６５】
ついでＭＭＳリレー３は、送信側２が望むならばＭＭの送達ステータスに関する通知１６（WAPではればM-Delivery.ind）をそこへ送る。これまでにすでに知られている可能性 "Expired"（有効期限切れ）、"Retrieved"（送達）、"Rejected"（拒否）、"Deferred"（遅延）のほか、本発明によれば "Partly-retrieved"（部分的に送達）もステータスフィールドに設けることができる。これによりどのデータセット７が送達されたのかが表される。メッセージ１６のそれ相応のセクションを以下のものとすることができる：
>>>>>
7.2.22 Status field（ステータスフィールド）
Status-value=Expired｜Retrieved｜Rejected｜Deferred｜Partly-retrieved
Expired = <Octet 128>
Retrieved = <Octet 129>
Rejected = <Octet 130>
Deferred = <Octet 131>
Partly-retrieved = <Octet 132>
<<<<<
同様に新しいフィールド２２，２３ X-Mms-External-Link-Flag（オプション）およびX-Mms-External-Link-Size（オプション）を、ＭＭ送達用のメッセージ９（WAPではM-Send.req）と受信側４へのメッセージ１１（WAPではM-Notification.ind）とにおいて、ＭＭに含まれるＭＭ外のコンテンツへのリンクを表すことができる。ＭＭヘッダ内のポジションに従いフィールド２２：X-Mms-External-Link-Flagは、ＭＭ全体またはＭＭの特定のデータセット７内の外部のコンテンツへのリンクが表される。フィールド２３：X-Mms-External-Link-Sizeにより、オプションとしてオクテットでコンテンツサイズが記述される。これによりノーティフィケーションNotificationの受信側は、ＭＭ自体のデータボリュームに対してどの付加的なデータボリュームをさらにダウンロードすべきかをすでに見積もることができる。
【００６６】
これまで説明してきたやり方を、たとえばＵＭＴＳなど個々の通信標準用のオペレーティングソフトウェアに組み込むことができる。この場合、通信機器５，６にはそれ相応のソフトウェアが設けられる。
【００６７】
次に、ＷＡＰ標準に準拠した本発明によるＭＭ伝送（図１）の具体的な流れについて説明する。
【００６８】
ここではたとえば以下のシナリオを前提とする：送信側２（Markus Trauberg）は、複数のデータセット７をもつテキストすなわちＭＰ３音声、ＪＰＥＧ画像、ＭＰＥＧ−４ビデオおよびＳＭＩＬプレゼンテーション記述をもつテキストを伴うＭＭを２人の受信側４（Andreas Schmidt, Josef Laumen）へ送出する。これらの受信側４による快適かつ多種多様な利用のために、送信側はＭＭのデータセット７のパラメータ記述をそのヘッダに添付する。データはメッセージ９（M-Send.req）および１１（M-Notification.ind）として受信側へ伝送される。受信側４ Andreas Schmidt はＭＭ全体を自身の端末機器６にロードするのに対し、受信側４ Josef Laumen はテキストだけにしか関心がなく、それのみを自身の端末機器６にロードする。以下のＭＭが各ユニット間で伝送される：
ＭＭは２ｔの宛先に送られる。この場合、メッセージプロトコルを図９のように描くことができる。
【００６９】
ＭＭにおいて、ヘッダ内でＭＭ要素に関する付加的な情報ブロックがコーディングされる。そこにはＭＭの各データセット７間の関係も記述される：つまりその中の外部の要素 image/jpeg, audio/mp3, video/meg4 への presentation＿description 参照の記述が対応するコンテンツＩＤとして含まれている。テキストの記述には、外部のオブジェクトに対する参照が含まれそれは８２４５ｂｙｔｅのデータをもつという情報が含まれている。
【００７０】
送信側２の上述の送信問い合わせ９（M-Send.req）の確認応答は、ＭＭＳリレー３によりメッセージ１０（M-Send.conf）によって行われる。このメッセージ１０には付加的な新しいフィールドは含まれておらず、このことは図１０に示した以下のリストから明らかである。
【００７１】
ＭＭＳリレー３はメッセージ１０を用いることで、問い合わせ９が誤りなくＭＭＳリレー３に伝送されたことを確認応答する。この場合、トランザクションＩｄ Transaction-ID#1 が利用され、これによりメッセージ１０が送信側２においてそれに属する問い合わせ９（M-Send.req）に、ひいては送信されたＭＭに一義的に対応づけられる。フィールドX-Mms-Delivery-Report内のメッセージ９において送達レポートが要求されたので、ＭＭＳリレー３はＭＭにメッセージＩＤを割り当て、それをここでは送信側２へ伝達する。
【００７２】
さらにメッセージ１１は受信側４へ伝送される：
M-Notification.ind (MMS Relay → MMS User Agent B):
ＭＭＳにおいて、ＭＭの受信側に対しその受信側のために存在する新しいメッセージに関して通知されるように構成されている。メッセージ１１（M-Notification.ind）は、ダウンロードのために準備されているＭＭについて宛先に通知するために用いられる。したがってこの実施例の場合には、受信側 Andreas Schmidt と Josef Laumen 宛の２つの通知が存在する。各々には固有のと欄属ションＩＤが含まれている。ＭＭのメモリロケーションに関する情報は、双方においてフィールド X-Mms-Content-Location におかれている。
【００７３】
図１１には、M-Notification-ind の内容が例示されている。この場合、メッセージ１１冒頭の通常のフィールドのほか、メッセージ９のすべての記述要素をメッセージ１１に引き継ぐことができる。ミックスフォームに基づきすでに説明したようにそれらに加えてさらに、メッセージ９のボディの情報から X-Mms-Content-Type と X-Mms-Content-Size の情報がＭＭＳリレー３によって生成される。受信側４はメッセージ１１の受信後、（これまでのように）ＭＭのアドレスも知ることになるし、個々のデータセット７およびそれらのコンテンツＩＤから成るそれらの組成も知ることになる。したがってＭＭの個々のデータセット７に対し別個にアクセスすることもできる。
【００７４】
ついで通知の適正な受信がＭＭの受信側４によりメッセージ１２（M-NotifyResp.ind）により確認応答され、これはメッセージ１１の適正なトランザクションＩＤをステータスメッセージとともにＭＭＳリレー３へ送り戻すことによって行われる。
【００７５】
ＭＭのダウンロードは命令１３（WSP Get.req）により指示される。ＭＭはそれに基づきＭＭＳリレー３によりメッセージ１４（M-Retrieve.conf）として受信側４へ送信される。
【００７６】
個々の要素に関する情報はすでにメッセージ１１として伝送されたので、これまでのとおりＭＭ全体のダウンロードをメッセージ１４によって行うことができ、その際に付加的なフィールドをこのメッセージ１４のヘッダに挿入する必要なない。これに対し個々のデータセット７のヘッダ中の付加的な情報はメッセージ１４内にも含まれているようにすべきであり、その理由はそれらにはＭＭデータセット７に関する重要な情報が含まれているからである。
【００７７】
次に、受信側４の２つの可能なリアクションについて例示する：
受信側 Andreas Schmidt はＭＭ全体をロードする。
【００７８】
受信側 Josef Laumen はＭＭのうちテキストパートのみを自身の受信機器６にロードする。
【００７９】
最初に事例の場合、メッセージ１４は図１２に示されているようにコーディングされる：
受信側４ Andreas Schmidt は、ＭＭの受信成功に続いてメッセージ１５（M-Acknowledge.ind）で確認応答する。その中に含まれているトランザクションＩＤによって、送信されたＭＭに対する対応づけをＭＭＳリレーにおいて図１３の情報信号 M-Acknowledge.ind に応じて行うことができる。
【００８０】
ついでトランザクションの最後のステップとして、メッセージ１６（M-Delivery.ind）が図１４に従いＭＭＳリレー３から送信側２へ伝達される：
これに対し第２の受信側 Josef Laumen は、メッセージ１４のテキストパートのみをダウンロードするものと決める。このため第２の受信側はメッセージ１３（WSP GET.req）中にテキストパートのコンテンツＩＤ "000714.1412.1markus.trauberg" を挿入する。この受信側はこのテキストパートをメッセージ１４（M-Retrieve.conf）として受け取り、これは Andreas Schmidt におけるバージョンとは著しく異なっており、その内容を図１５に例示した。
【００８１】
メッセージ１４は Andreas Schmidt へ送られたもののようにその完全なバージョンに比べ、望まないデータセット７の分だけ低減されている。しかもフィールド nEntries が相応に整合されている。
【００８２】
図１６に示されているメッセージ１５（M-Acknowledge.ind）は Andreas Schmidt のバージョンとほぼ完全に一致しているけれども、固有のトランザクションＩＤを有している：
最後のステップとして送信側２に対し送達ステータスに関して再び通知が行われる。これには部分的な送達（"Partly-retrieved"）のステータスが含まれており、内容的には図１７に描かれているようなものである。
【００８３】
マルチメディアメッセージサービス Multimedia Messaging Service （ＭＭＳ）におけるマルチメディアメッセージ（ＭＭ）の受信側に対し詳しい通知を既述のようにして行うことができることのほか、既述の実施形態とは異なる利点をもつさらに別の好適なオプション構成が存在する。次に、この有利なオプションについて説明する。
【００８４】
この変形実施形態の核となる着想は、個々の受信側に対し新たに定義されたただ１つのヘッダフィールドだけしか利用せずに個々のＭＭの内容に関して詳細に通知するというアイデアを実現することであり、そのフィールドのために新たなパラメータが挿入される。この場合、新たなヘッダフィールドにすべてのパラメータすなわち既述すべきＭＭの要素に関する情報が含まれている。本出願においてＭＭの要素もしくはデータセットとはＭＭの個々の構成部分のことであり、これはたとえばその形式（たとえば静止画）およびそのフォーマット（たとえば JPEG = joint photographics expert group）によって定義されている。
【００８５】
以下のリストには、すでに前述の実施形態のために提案された情報が含まれており、ＭＭの受信側に対しオプションとしてＭＭＳ内の受信側メッセージ（M-Nind; ＷＡＰではM-Notification.ind）を使用することができる。これには以下のものが含まれる：
・ＭＭに含まれている要素の個数（ＭＭの個々の要素の記述により暗黙的であもある）
・１つの要素のサイズ（オクテット単位）
・１つの要素の形式およびフォーマット
・１つの要素のコンテンツＩＤ（Content IDentification）（＝個々の識別信号における個々のヘッダフィールドの名称もしくは指示子
・１つの要素における名称
・ＭＭにおける１つの要素と１つまたは複数の別の要素とのリンク
・ＭＭ全体または１つまたは複数の要素とＭＭ外の１つまたは複数のＵＲＬ／ＵＲＩ（uniform resource link/identifier）とのリンク、この種の外部のリンクであればオプションとして解決された外部のリンクにおいてロードすべきオブジェクトのサイズ
以下の実施例において、ＭＭＳ受信側メッセージ（M-Nind; ＷＡＰではM-Notification.ind）および場合によってはＭＭＳ送信問い合わせ（M-Sreq; ＷＡＰではM-Send.req）およびＭＭＳ送達メッセージ（M-Rconf; ＷＡＰではM-Retrieve.conf）の選択的な拡張に対する相応のヘッダフィールドの定義について説明する。
【００８６】
ＭＭは基本的に（既述の実施例で示したとおり）ヘッダから成り、さらにメッセージの形式により場合によっては付加的にデータパート（ＷＡＰではボディ body）から成る。ヘッダにはメッセージの一般的な情報が含まれており、これは１つまたは複数の定義されたヘッダフィールドによって構成されている。場合によっては存在するメッセージのデータパートには１つまたは複数の任意の形式の要素が含まれており、これは任意の順序でヘッダに続いている。データパート中にプレゼンテーション記述が含まれている場合、たとえばＷＡＰメッセージではデータパートの冒頭においていわゆるスタートパラメータによりこのプレゼンテーション記述が適切に指示されるようにする。
【００８７】
ここで図１のメッセージの流れ図には、送信側ユーザ２（ユーザエージェントＡ＝Ｍ−ＵＡ＿Ａ）からＭＭＳ接続ユニット３（ＭＭＳリレー＝Ｍ−ＳＲ）を介して受信側ユーザ４（ユーザエージェントＢ＝Ｍ−ＵＡ＿Ｂ）へ向かうメッセージ伝達の基本的な流れが示されている。
【００８８】
メッセージ形式に応じて可能なもしくは必要とされるＷＡＰにおけるヘッダフィールドが、ここで考察するメッセージ形式に関して図２１Ａ、図２１Ｂおよび図２２による表として示されている。これらは WAP-209-MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0 に示されているものである。WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding" によれば、各ヘッダフィールドはフィールド名およびそれに続くフィールド値から成り、フィールド値は少なくとも１オクテットによって構成されている。図２０による表には、ＷＡＰメッセージのフィールド名に対する１６進数値の割り当てが示されている。このような別のオプションは、１つのＭＭの１つの要素を一義的に識別するための前述の実施例で言及したヘッダフィールドの定義すなわちX-Mms-Content-IDに基づくものであり、これはＭＭのボディにおいてＭＭの要素の前にヘッダフィールドとしておかれており、要素を一義的に表すものである。
【００８９】
前述の提案とは異なりＭＭの要素の記述はここでは単一のヘッダフィールドX-Mms-Content-IDをベースとしており、これは受信側に通知するためＭＭのヘッダに統合され、（受信側への通知のためその受信側に対し用意されているＭＭのデータセットの個数、形式、サイズ、フォーマットなどに関する）所要情報が以下のリストのうち１つまたは複数のパラメータにより記述される。
【００９０】
・名称：ＭＭ要素の名称を表す。
【００９１】
・形式：ＭＭ要素の形式およびフォーマットを表す。
【００９２】
・サイズ：ＭＭ要素のサイズをｂｙｔｅで表す。
【００９３】
・外部リンク：要素がＭＭ外のコンテンツへのリンクを含むことを表す。
【００９４】
・外部リンクサイズ：外部参照解決のためどの程度のデータボリュームを付加的にダウンロードする必要があるかを表す。
【００９５】
・関連ＩＤ：ＭＭのどの要素がその要素と関係しているのか、およびそれをＭＭの部分的なダウンロード時にもダウンロードすべきか（多重利用が可能）を表す。
【００９６】
つまり一般的に表現するとこの場合には、単一の付加的なヘッダフィールド内における１つまたは複数の対応するデータセットのための識別信号が、たとえば第１の移動無線機器および／または付加的なサーバのような個々の送信側から、ＭＭＳ受信側通知として第２の移動無線機器のような受信側へ符号化されて伝送される。これにより、場合によっては複数のヘッダフィールドが利用されたときにそれら自体の間で、および／または対応づけられたデータセットの間で生じる可能性のある順序問題や対応づけ問題が最初から回避される。
【００９７】
前述の実施例についてすでに説明したものに加えてさらに以下の情報もパラメータとして符号化できるようにする：
１．オリジナル形式 Original-Type：ＭＭＳ接続ユニット（Ｍ−ＳＲ）により符号変換される前のＭＭ要素の形式を表す。
【００９８】
２．オリジナルサイズ Original-Size：ＭＭ接続ユニット（Ｍ−ＳＲ）により符号変換される前のＭＭ要素のサイズをｂｙｔｅで表す。
【００９９】
単一のヘッダフィールド内においてＭＭ要素に関連するすべての情報をまとめることにより、前述の実施例において前提条件としたヘッダ順序の遵守を行わなくてよくなる。
【０１００】
図１８には、ＷＡＰによるＭＭの受信側への詳細な通知の目的で新たに導入された単一のヘッダフィールドがフィールド名およびフィールド値のコーディングを含めて示されている。図２０に示した表には、１６進数値とフィールド名との対応づけが含まれている。図１９による表には、１６進数値とパラメータ名との対応づけおよびパラメータ値の符号化に使用すべき形式が含まれている。さらに表２１Ａ／２１Ｂおよび表２２には、相応のヘッダフィールドにより補われたＷＡＰメッセージがリストアップされている。従来技術に対する表中のすべての変更および補足が枠で囲まれている。
【０１０１】
実施例：
さて、ＷＡＰフォーラムによる既述のメッセージの定義をベースとする以下の実施例では、ＷＡＰメッセージにおいて利用されるヘッダフィールドについて詳細に立ち入ることにする。ここでは例として以下のシナリオを前提とする：Ｍ−ＵＡ＿Ａ（Markus Trauberg）はマルチメディアメッセージＭＭＡを受信側Ｍ−ＵＡ＿Ｂ（Andreas Schmidt）へ送信し、その際、このメッセージはテキスト、ＭＰ３オーディオ、ＪＰＥＧ画像、ＭＰＥＧ−４ビデオおよびＳＭＩＬ（synchronized multimedia integration language）プレゼンテーション記述から成る。受信側により快適かつ多種多様に利用するため、ＭＭの要素の記述が本発明に従いＭＭのヘッダに供給される。データはメッセージＭ−ＳｒｅｑおよびＭ−Ｎｉｎｄとして受信側へ伝送される。受信側である Andreas Schmidt はＭＭ全体を自身の端末機器にロードする。この場合、以下のメッセージがユニット間で伝送される。
【０１０２】
ＭＭＡが宛先に送られる。その内容は図２３に例示されている。
【０１０３】
このメッセージにおいて、ヘッダ中に付加的な情報ブロックが符号化され、つまり一般的に表現すればＭＭ要素に関する１つまたは複数のパラメータが符号化される。そこにはＭＭの各要素間の関係も記述される。つまりプレゼンテーション記述（*.smil）の記述には、そこで参照されている要素 image/jpeg, audio/mp3, video/mpeg4 への参照指示が相応のコンテンツＩＤの形式で含まれている。テキストの記述には、外部のオブジェクトへの参照指示が含まれ８２４５ｂｙｔｅのデータであるという情報が含まれている。
【０１０４】
従来技術によれば、ＭＭＳユーザエージェントＡの送信問い合わせ（ＷＡＰではＭ−Ｓｅｎｄ．ｒｅｑ）に対しＭ−ＳＲから１つのメッセージ（ＷＡＰではＭ−Ｓｅｎｄ．ｃｏｎｆ）によって確認応答される。このＥＭの枠内ではこのメッセージは修正されず、したがってここではそれについては触れない。
【０１０５】
Ｍ−Ｎｉｎｄ（Ｍ−ＳＲ → Ｍ−ＵＡ−Ｂ）：
3G TS 23.140 version 3.0.1, Release 1999; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2 および WAP-209-MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0 によるＭＭＳ（multimedia service）の場合、１つのMMの受信側に対しその受信側のために存在する新たなメッセージに関する情報を通知するように構成されている。メッセージＭ−Ｎｉｎｄ（ＷＡＰではＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ）は、ダウンロードのために準備されているＭＭＳに関して宛先に通知するために用いられる。図２４にはその内容が例示されている。したがってこの実施例では受信側 Andreas Schmidt 宛の受信側通知が生じる。ここでＭＭＡの記憶場所に関する情報はフィールド X-Mms-Content-Location 内に存在する。
【０１０６】
メッセージ冒頭の通常のフィールドのほか、メッセージＭ−Ｓｒｅｑにおいてこの変形実施形態に関して新しいすべての記述された要素をメッセージＭ−Ｎｉｎｄに引き継がせることができる。付加的にＭ−ＳＲにより形式 Type とサイズ Size の情報がメッセージＭ−Ｓｒｅｑのボディの情報から生成され、もしくは含まれている形式 image/jpeg の画像が形式 image/bmp へ変換される。その理由は端末機器はＪＰＥＧ画像を表示できないからである。もともとの形式（オリジナルタイプ Original-Type）ともともとのファイルサイズ（オリジナルサイズ Original-Size）に関する対応する情報は、相応のヘッダフィールド内で補われている。受信側は詳細通知 detailed Nofitication を受け取った後、（これまでのように）ＭＭのアドレスも個々の要素とそれらのコンテンツＩＤの組み合わせも知ることになる。したがってＭＭの個々の要素に別個にアクセスすることも可能である。
【０１０７】
ついで通知の適正な受け取りに対しＭＭＡの受信側はメッセージＭ−ＮＲｉｎｄで確認応答することができ、これはＭ−Ｎｉｎｄの対応するトランザクションＩＤをステータスメッセージとともにＭＭＳリレーに送り返すことにより行われる。この場合、ＭＭＡのダウンロードは命令Ｗ−Ｇｒｅｇにより指示される。それに応じてＭ−ＳＲからＭＭ−ＵＡ ＡへメッセージＭ−Ｒｃｏｎｆ内でＭＭが送信される。
【０１０８】
次に、メッセージが受信側 Andreas Schmidt により自身の端末機器に完全にダウンロードされる。メッセージＭ−Ｒｃｏｎｆはたとえば図２５のようにして符号化される。
【０１０９】
ついで受信側Ｍ−ＵＡ Ｂは、ＭＭＡの受信成功を従来技術に従いメッセージにより確認応答する。
【０１１０】
以上要約すると、マルチメディアメッセージサービス Multimedia-Messaging-Service （ＭＭＳ）においてマルチメディアメッセージおよびその中に含まれているＭＭ要素を詳細に記述する付加的な情報を伝送する方法が提供される。これらの情報はたとえば、それぞれ管轄のサーバたとえばＭ−ＳＲなどから受信側のユーザエージェントへ、個々のＭＭＳ受信側通知内の単一または複数の付加的なヘッダフィールドによって伝送される。必要とされる情報は有利には送信側のユーザエージェントにより生成され、ＭＭＳ送信問い合わせにおいてそれにより符号化されて管轄のサーバへ伝送される。付加的にまたはこれとは無関係に、必要とされる情報を管轄の交換／供給サーバにより個々に送信すべきＭＭのデータパートから抽出して、受信側のユーザエージェントへＭＭＳ受信側通知において符号化して伝送することもできる。有利には受信側のユーザエージェントへ、送達のためたとえば管轄サーバ内に用意されているメッセージの内容または内容の個々の要素に関して、以下の情報のうちの１つまたは複数を伝達することができる：
・ＭＭ内に含まれている要素の個数
・ＭＭの要素のサイズ（オクテット単位）
・ＭＭの要素の形式およびフォーマット
・要素の識別子（コンテンツＩＤもしくはＵＲＩ）
・要素名
・１つまたは複数の要素とＭＭ内の１つまたは複数の別の要素とのリンク（たとえばプレゼンテーション記述とプレゼンテーション要素）
・１つまたは複数の要素とＭＭ外の任意の特性の内容（たとえばＨＴＭＬ／ＷＭＬページ）
・ＭＭ自体に加えてロード可能なリンクされた外部の要素の個々のサイズ（オクテット単位）
・Ｍ−ＳＲによる符号変換前の要素の形式およびフォーマット
・Ｍ−ＳＲによる符号変換前の要素のサイズ（オクテット単位）
この場合、要素の識別子（コンテンツＩＤもしくはＵＲＩ）によって、単一のヘッダフィールド中の最初のエントリまたは複数のヘッダフィールドが用いられているならば要素もしくはデータセットごとの最初のヘッダフィールドの内容を表す。
【０１１１】
有利には１つのＭＭの１つの要素の記述をただ１つのフィールドによって行うことができ、これは一義的な識別番号もしくは名称ごとにマルチメディアメッセージのデータパート中の要素を指示し、これにはパラメータとして別個のヘッダフィールド内にではなく別の情報も含まれている。
【０１１２】
有利にはＭＭの受信側は詳細通知を受け取った後、要素ＭＭの個々の要素だけを自身の端末にロードすることができる。同様に本発明によればＭＭＳ受信側通知（Ｍ−Ｎｉｎｄ）の付加的な情報をＭＭＳ送達メッセージ（Ｍ−Ｒｃｏｎｆ）のヘッダ内で補うこともできる。
【０１１３】
有利には付加的なヘッダフィールドは、データセットごとにただ１つのヘッダフィールドしか使用しないならば、ＷＡＰにおいて以下のように符号化することができる。すなわち図２０の表に示されているように00x10〜0x7Fの値の範囲内で、たとえば0x19としてフィールド名X-Mms-Content-IDが符号化される。また、図９の表に示されているようにX-Mms-Content-IDのフィールド値が符号化される。
【０１１４】
この単一のヘッダフィールドにおけるパラメータとしての情報は、たとえば図１９の表に示されているようにして符号化することができる。
【０１１５】
ＷＡＰおよびＭＭＳならびに殊にそれらの規格に関連する文献に対する基本的な情報として、以下のものを挙げておく：
[1] 3G TS 23.140 version 3.0.1, Release 1999; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2
[2] WAP-209-MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0
[3] WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding"
[4] WAP-Forum: "WAP MMS Interworking with Internet E-mail; WAP-207-MmsInetInterworking"; Draft Version 01-Jun-2000
[5] 3G TS 22.140 v.4.0.1 (July 2000): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1 Multimedia Messaging Service
[6] RFC822："Standard for the Format of ARPA Internet Text Messages", Crocker D., August 1982. URL: ftp://ftp.isi.edu/in-notes/rgc822.txt
[7] RFC2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", Freed N., November 1996. URL: ftp://ftp.isi.edu/in-notes/rfc2045.txt
[8] RFC2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", Freed N., November 1996. URL: ftp://ftp.isi.edu/in-notes/rfc2046.txt
[9] RFC2047: "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", Moore K., November 1996. URL: ftp://ftp.isi.edu/in-notes/rfc2047.txt
本発明においては文脈中の記載を簡単にするため以下の慣用の頭字語を引用したが、わかりやすくするためそれらの完全な意味を以下に挙げておく：
GSM Global System for Mobile Communication
MM Multimedia Message
MMS Multimedia Messaging Service
SMS Short Message Service
UMTS Universal Mobile Telecommunication System
WAP Wireless Application Protocol
WSP Wireless Session Protocol
MMS 固有の略語：
M-UA ＭＭＳユーザアプリケーション
M-SR ＭＭＳ接続ユニット
M-Sreq ＭＭＳ送信問い合わせ
M-Sconf ＭＭＳ送信確認応答
M-Nind ＭＭＳ受信側通知
M-NRind ＭＭＳ受信側通知確認応答
W-Greq ＭＭＳ送達問い合わせ
M-Rconf ＭＭＳ送達メッセージ
M-Aind ＭＭＳ送達確認応答
M-Dind ＭＭＳ送達状態通知
【図面の簡単な説明】
【図１】  送信側レベルとプロバイダレベルとの間およびプロバイダレベルと受信側レベルとの間においてＷＡＰ（wireless application protocoll）に従って行われるデータ伝送に対応する送信を描いた図である。
【図２】  図１に示したＷＡＰ標準に従って送信されるメッセージＭ−Ｓｅｎｄ．ｒｅｑのヘッダフィールドを示す図である。
【図３】  図２で示しグレイの付されたフィールド内に格納された情報の形式ならびに送信データの受け取りに関してステータスレポート中に付加的に設けられたフィールドの指定を示す図である。
【図４】  図２のヘッダフィールドをバイナリコードに割り当てる様子を示す図である。
【図５】  図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ（ＭＮＩ）を図２と同様のかたちで示した図である
【図６】  図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｒｅｔｒｉｅｖｅ．ｃｏｎｆ（ＭＲＣ）を図２と同様のかたちで示した図である。
【図７】  図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ａｃｋｎｏｗｌｅｄｇｅ．ｉｎｄ（ＭＡＩ）を図２と同様のかたちで示した図である。
【図８】  図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｄｅｌｉｖｅｒｙ．ｉｎｄ（ＭＤＩ）を図２と同様のかたちで示した図である。
【図９】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１０】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１１】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１２】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１３】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１４】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１５】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１６】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１７】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１８】  単一ヘッダフィールドネームの符号化について示す図である。
【図１９】  図９による単一ヘッダフィールド中の新しいパラメータネームおよびパラメータ値の符号化（コーディング）について示す図である。
【図２０】  バイナリコードを図９による単一ヘッダフィールド中のパラメータに割り当てる様子を示す図である。
【図２１Ａ】  マルチメディアサービス（ＭＭＳ）の送信問い合わせ（ＷＡＰメッセージではＭ−Ｓｅｎｄ．ｒｅｑ；）における単一ヘッダフィールドを示す図である。
【図２１Ｂ】  マルチメディアサービス（ＭＭＳ）の送信問い合わせ（ＷＡＰメッセージではＭ−Ｓｅｎｄ．ｒｅｑ；）における単一ヘッダフィールドを示す図である。
【図２２】  図２１Ａ，図２１Ｂによる送信問い合わせＭＳｒｅｑに割り当てられたＭＭＳ受信側メッセージ（Ｍ−Ｎｉｎｄ；ＷＡＰメッセージではＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ；）のヘッダフィールドを示す図である。
【図２３】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図２４】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図２５】  本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。
【図１】
0004358511.tif 000002
【図２】
0004358511.tif 000003
【図３】
0004358511.tif 000004
【図４】
0004358511.tif 000005
【図５】
0004358511.tif 000006
【図６】
0004358511.tif 000007
【図７】
0004358511.tif 000008
【図８】
0004358511.tif 000009
【図９】
0004358511.tif 000010
【図１０】
0004358511.tif 000011
【図１１】
0004358511.tif 000012
【図１２】
0004358511.tif 000013
【図１３】
0004358511.tif 000014
【図１４】
0004358511.tif 000015
【図１５】
0004358511.tif 000016
【図１６】
0004358511.tif 000017
【図１７】
0004358511.tif 000018
【図１８】
0004358511.tif 000019
【図１９】
0004358511.tif 000020
【図２０】
0004358511.tif 000021
【図２１Ａ】
0004358511.tif 000022
【図２１Ｂ】
0004358511.tif 000023
【図２２】
0004358511.tif 000024
【図２３】
0004358511.tif 000025
【図２４】
0004358511.tif 000026
【図２５】
0004358511.tif 000027