JP2009105931A - 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置 - Google Patents

移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置 Download PDF

Info

Publication number
JP2009105931A
JP2009105931A JP2008319719A JP2008319719A JP2009105931A JP 2009105931 A JP2009105931 A JP 2009105931A JP 2008319719 A JP2008319719 A JP 2008319719A JP 2008319719 A JP2008319719 A JP 2008319719A JP 2009105931 A JP2009105931 A JP 2009105931A
Authority
JP
Japan
Prior art keywords
data
mms
identification signal
message
data set
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008319719A
Other languages
English (en)
Other versions
JP5006864B2 (ja
Inventor
Andreas Schmidt
シュミット アンドレアス
Markus Trauberg
トラウベルク マルクス
Josef Laumen
ラウメン ヨーゼフ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of JP2009105931A publication Critical patent/JP2009105931A/ja
Application granted granted Critical
Publication of JP5006864B2 publication Critical patent/JP5006864B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Abstract

【課題】移動無線ネットワークにおけるデータ伝送にあたり、移動無線ネットワークの加入者のためのデータ伝送コントロールを簡単にする。
【解決手段】移動無線ネットワークにおいてデータを伝送する際たとえばマルチメディアメッセージ（ＭＭ）内で音声付きまたは音声なしでテキストおよび／または画像データを伝送する際、データに対し１つまたは複数のデータセットに関する少なくとも１つの識別信号が割り当てられ、その識別信号がデータの受信側に伝送される。
【選択図】図１

Description

本発明は、請求項１の上位概念に記載の移動無線ネットワークにおけるデータ伝送方法、請求項２６の上位概念に記載の移動通信装置、請求項３０記載のコンピュータプログラム製品ならびに請求項３２記載の無線通信システムに関する。
たとえばＧＳＭ標準に従い動作するネットワークのようなこれまでの移動無線ネットワークによって、まだかなり制約されているがテキストデータを伝送する可能性が開かれている。つまりたとえば１６０個のキャラクタまでのショートメッセージを伝送することができる。このような機構はＳＭＳ（ショートメッセージサービス Short Message Service）と呼ばれる。そしてこの種のテキストメッセージの送信コストはデータ送信側が担うことになっている。
将来は、マルチメディアデータたとえば音声付きまたは音声なしの静止画や動画の伝送も可能になるはずである。このような伝送においてはデータ伝送量やデータ形式の著しい拡大が見込まれ、これには伝送時間やコストの増大が伴う。
本発明の課題は、移動無線ネットワークの加入者のためのデータ伝送コントロールを簡単にすることにある。
本発明によればこの課題は、請求項１の特徴を備えた方法、請求項２６の特徴を備えた移動通信装置、請求項３０の特徴を備えたコンピュータプログラム製品、ならびに請求項３２記載の無線通信システムによって解決される。有利な実施形態については請求項２から２５、請求項２７から２９ならびに請求項３１を参照されたい。本発明の方法によれば、情報は受信のために用意されるデータの特性に関してデータ受信側へ情報を伝達することができ、これにより受信側にとってコントロールが簡単になる。
伝送すべきデータの特性を表す識別信号をまえもって送信することで、本来のデータの受信前にすでにコントロールが可能となり、その際に殊に有利であるのは、このようにして得られた情報に基づき、供給されるデータをいま受信したいのかあとで受信したいのか、それともまったく受信したくないのかという選択の余地が与えられることである。また、マルチメディアメッセージ（ＭＭ）を一部分だけ受信するという選択の可能性も与えられているならば、受信側はたとえば自身にとって重要な短い情報だけをダウンロードすることができ、そのような情報であれば短い伝送時間しか必要とせず、さらに必要に応じて多くのメモリを要する付加的な画像コンポーネント等をあとからダウンロードしてもよいし、あるいはそれらはまったくダウンロードしないようにすることができる。
このために使用される識別信号に受信すべきデータセットのサイズに関する情報が含まれているならば受信側は、データの伝送および／または調査にどの程度の時間を見込む必要があるのか、ならびにその時間をいま費やすのかあとで費やすのか、あるいは費やす意志がないのかについて確定することができる。
識別信号にデータセットの名称に関する情報が含まれているならば受信側は、データがどの複合テーマからのものであるのかを調べることができる。さらに有利には受信側は、それらのデータセットをいま受信したいのかあとで受信したいのか、あるいはまったく受信する意志がないのかを選択することができる。
さらに識別信号にデータ形式に関する情報も与えることができると殊に有利であり、これにより受信側は、たとえば画像データであるのかテキストデータであるのか、および／または音楽データであるのかを知るようになる。このようにしてコントロールおよびトランスペアレンスが格段に改善される。
図面に新たに描かれた後述の本発明対象に関する実施例によって、本発明のさらに別の利点や特徴がわかる。図１〜図３中、同じ動作や機能をもつ構成要素にはそれぞれ同じ参照符号が付されている。
この実施例では、ＷＡＰ標準のためのデータ伝送スキーマ１に本発明を適用した事例について説明されており、これはたとえばＵＭＴＳ標準（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）に従って行われるデータ伝送に対応する送信を描いた図である。 図１に示したＷＡＰ標準に従って送信されるメッセージＭ−Ｓｅｎｄ．ｒｅｑのヘッダフィールドを示す図である。 図２で示しグレイの付されたフィールド内に格納された情報の形式ならびに送信データの受け取りに関してステータスレポート中に付加的に設けられたフィールドの指定を示す図である。 図２のヘッダフィールドをバイナリコードに割り当てる様子を示す図である。 図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ（ＭＮＩ）を図２と同様のかたちで示した図である 図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｒｅｔｒｉｅｖｅ．ｃｏｎｆ（ＭＲＣ）を図２と同様のかたちで示した図である。 図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ａｃｋｎｏｗｌｅｄｇｅ．ｉｎｄ（ＭＡＩ）を図２と同様のかたちで示した図である。 図１に示したＷＡＰ標準に従い送信されるメッセージＭ−Ｄｅｌｉｖｅｒｙ．ｉｎｄ（ＭＤＩ）を図２と同様のかたちで示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 単一ヘッダフィールドネームの符号化について示す図である。 図９による単一ヘッダフィールド中の新しいパラメータネームおよびパラメータ値の符号化（コーディング）について示す図である。 バイナリコードを図９による単一ヘッダフィールド中のパラメータに割り当てる様子を示す図である。 マルチメディアサービス（ＭＭＳ）の送信問い合わせ（ＷＡＰメッセージではＭ−Ｓｅｎｄ．ｒｅｑ；）における単一ヘッダフィールドを示す図である。 マルチメディアサービス（ＭＭＳ）の送信問い合わせ（ＷＡＰメッセージではＭ−Ｓｅｎｄ．ｒｅｑ；）における単一ヘッダフィールドを示す図である。 図２１Ａ，図２１Ｂによる送信問い合わせＭＳｒｅｑに割り当てられたＭＭＳ受信側メッセージ（Ｍ−Ｎｉｎｄ；ＷＡＰメッセージではＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ；）のヘッダフィールドを示す図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。 本発明による方法に従い無線通信システムの複数のコンポーネント間でマルチメディアメッセージを伝送するための様々な情報信号の内容を例示した図である。

Claims (32)

  1. 移動無線におけるデータ伝送方法たとえば音声付きおよび音声なしでテキストデータおよび／または画像データを伝送する方法において、
    データに対し１つまたは複数のデータセットに関する少なくとも１つの識別信号が割り当てられて、該識別信号がデータ受信側へ伝送されることを特徴とする、データ伝送方法。
  2. 前記識別信号が該識別信号により特徴づけられたデータセットの伝送前に伝送され、光学的または音響的に表示される、請求項１記載の方法。
  3. 識別信号の受信側は、該識別信号により特徴づけられたデータの伝送を完全に許可するのか部分的に許可するのかを選択可能である、請求項２記載の方法。
  4. 識別信号にはデータセットの種類に関する情報たとえばデータセットのデータフォーマットに関する情報が含まれている、請求項１から３のいずれか１項記載の方法。
  5. 識別信号にはデータセットの名称に関する情報が含まれている、請求項１から４のいずれか１項記載の方法。
  6. 識別信号にはデータセットの内容に関する情報が含まれている、請求項１から５のいずれか１項記載の方法。
  7. 識別信号にはデータセットのサイズに関する情報が含まれている、請求項１から６のいずれか１項記載の方法。
  8. 識別信号には伝送されるデータ内のデータセットの個数に関する情報が含まれている、請求項１から７のいずれか１項記載の方法。
  9. 識別信号には、送信されるデータ内の少なくとも１つのデータセットとのリンクに関する情報が含まれている、請求項１から８のいずれか１項記載の方法。
  10. 識別信号には、送信されるデータ外の少なくとも１つのデータセットとのリンクに関する情報が含まれている、請求項１から９のいずれか１項記載の方法。
  11. 前記識別信号には、伝送されるデータセットとリンクされているデータセットのサイズに関する情報が含まれている、請求項９または１０記載の方法。
  12. 識別信号にはデータセットの識別子に関する情報が含まれている、請求項１から１１のいずれか１項記載の方法。
  13. 移動メッセージサービス Mobile Messaging Service (MMS) に適用され、伝送されるデータは移動メッセージ Mobile Message (MM) として構成される、請求項１から１２のいずれか１項記載の方法。
  14. 伝送標準ＵＭＴＳ（Universal Mobile Telecommunication System）、ＧＳＭ（Global system for mobile communication）、ＧＰＲＳ（General packet radio service）および／またはＥＤＧＥ（Enhanced Data Rates for GSM einviroments）に適用される、請求項１から１３のいずれか１項記載の方法。
  15. １つまたは複数の識別信号が伝送データの１つまたは複数のヘッダフィールドに割り当てられる、請求項１から１４のいずれか１項記載の方法。
  16. 識別信号は少なくとも１つの付加的なヘッダフィールドに格納される、請求項１から１５のいずれか１項記載の方法。
  17. １つまたは複数の識別信号は少なくとも部分的に送信側により生成され、送信側（ＭＭＳユーザエージェントＡ）からサービスプロバイダ（ＭＭＳリレー）へマルチメディアメッセージが伝達されるときに送られる、請求項１から１６のいずれか１項記載の方法。
  18. 送信側はヘッダフィールド Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−ＩＤ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｎａｍｅ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｔｙｐｅ、Ｘ−ＭＭＳ−Ｅｘｔｅｒｎａｌ−Ｌｉｎｋ−Ｆｌａｇ、Ｘ−ＭＭＳ−Ｅｘｔｅｒｎａｌ−Ｌｉｎｋ−Ｓｉｚｅのうちの１つまたは複数を生成する、請求項１７記載の方法。
  19. 識別信号は少なくとも部分的に、サービスプロバイダ（ＭＭＳリレー）から受け取ったデータセットから自主的に求められる、請求項１から１８のいずれか１項記載の方法。
  20. ＭＭＳリレーはヘッダフィールド Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−ＩＤ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｓｉｚｅ、Ｘ−ＭＭＳ−Ｃｏｎｔｅｎｔ−Ｔｙｐｅのうちの１つまたは複数を生成または更新する、請求項１９記載の方法。
  21. １つまたは複数の識別信号はそれぞれ受信側（ＭＭＳユーザエージェントＢ）への通知にあたり、サービスプロバイダのＭＭＳリレーによって、１つのマルチメディアメッセージの１つまたは複数の新しいデータセットの存在に関して伝送される、請求項１から２０のいずれか１項記載の方法。
  22. 受信側の通信機器に１つの選択装置が設けられており、該選択装置により受信側は前記識別信号の少なくとも部分的な閲覧に従いデータセットに対する受信準備完了状態の確認応答を送出し、選択装置のトリガ後にはじめて受信装置への伝送が可能になる、請求項１から２１のいずれか１項記載の方法。
  23. 受信準備完了はデータの一部にのみ関連づけられ、データセットにおける該部分のみの伝送が許可される、請求項２２記載の方法。
  24. 準備されているデータに関する通知（Ｍ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ）と本来のデータ送達に関する通知（Ｍ−Ｒｅｔｒｉｅｖｅ．ｃｏｎｆ）に付加的な識別信号が加えられる、請求項１から２３のいずれか１項記載の方法。
  25. 準備されているデータを少なくとも部分的に受信するための準備完了状態が、受信側からプロバイダに送信されるメッセージＷＳＰ ＧＥＴ．ｒｅｑに割り当てられている、請求項１から２４のいずれか１項記載の方法。
  26. 請求項１から２５のいずれか１項記載の方法を実施するための移動通信装置（５；６）において、
    １つまたは複数の識別されたデータセット（７）に対し完全にまたは部分的に受信準備が完了していることの承認または拒否を選択する選択スイッチ（２５）が設けられていることを特徴とする移動通信装置。
  27. １つまたは複数のデータセット（７）の識別信号を視覚的または聴覚的に指示するための指示手段（２４）が設けられている、請求項２６記載の移動通信装置。
  28. 前記選択スイッチ（２５）はソフトウェア側でインプリメントされており、入力手段を介して選択可能である、請求項２６または２７記載の移動通信装置。
  29. 少なくとも１つの識別信号をデータ送達のヘッダフィールド（１７；１８；１９；２０；２１；２２；２３）に割り当てるソフトウェアが設けられている移動通信装置（５；６）。
  30. コンピュータで呼び出し可能な記憶媒体を有しており、該記憶媒体上にプログラムが格納されており、該プログラムがコンピュータのメモリにロードされると該プログラムによってコンピュータは、移動無線ネットワークにおけるデータ伝送において伝送すべきデータとともに、１つまたは複数のデータセット（７）に対し特徴づけられた情報をもつ識別信号を個々の受信側（４）へ伝送することを特徴とするコンピュータプログラム製品。
  31. 移動無線ネットワークにおけるデータ送信時に請求項１から２５のいずれか１項記載の方法を実施する、請求項３０記載のコンピュータプログラム製品。
  32. 請求項１から２５のいずれか１項の記載に従って少なくとも１つのコンポーネントが動作する無線通信システム。
JP2008319719A 2001-01-18 2008-12-16 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置 Expired - Lifetime JP5006864B2 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
EP01101057 2001-01-18
EP01101057.6 2001-01-18
EP01102229 2001-01-31
EP01102229.0 2001-01-31
EP01107278 2001-03-23
EP01107278.2 2001-03-23

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2002558717A Division JP4358511B2 (ja) 2001-01-18 2001-12-12 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置

Publications (2)

Publication Number Publication Date
JP2009105931A true JP2009105931A (ja) 2009-05-14
JP5006864B2 JP5006864B2 (ja) 2012-08-22

Family

ID=27224113

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2002558717A Expired - Fee Related JP4358511B2 (ja) 2001-01-18 2001-12-12 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置
JP2008319719A Expired - Lifetime JP5006864B2 (ja) 2001-01-18 2008-12-16 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2002558717A Expired - Fee Related JP4358511B2 (ja) 2001-01-18 2001-12-12 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置

Country Status (3)

Country Link
US (1) US8099081B2 (ja)
JP (2) JP4358511B2 (ja)
WO (1) WO2002058359A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10149721A1 (de) 2001-10-09 2003-04-10 Siemens Ag Verfahren zur Übertragung von Daten
DE10225425A1 (de) 2002-06-07 2003-12-18 Siemens Ag Verfahren zur Übertragung von Daten
DE10230897A1 (de) * 2002-07-09 2004-01-29 Siemens Ag Nachrichtenübertragungsverfahren und -system
DE10235470B4 (de) * 2002-08-02 2005-10-06 Siemens Ag Verfahren, Teilnehmergerät sowie Funkkommunikationssystem zum Übertragen von Nutzdatennachrichten
EP1387539A1 (de) * 2002-08-02 2004-02-04 Siemens Aktiengesellschaft Verfahren und System zum Blockieren von unerwünschten Nachrichten
EP1424860A3 (en) * 2002-11-05 2006-01-25 Siemens Aktiengesellschaft Method for controlling a multimedia messaging service between a telecommunication device and a telecommunication network, respective smart card and telecommunication device
FR2847406B1 (fr) * 2002-11-20 2005-01-14 Cegetel Procede et dispositif modulaire de tracage d'un message multimedia a travers un reseau de telecommunications
US20040176114A1 (en) * 2003-03-06 2004-09-09 Northcutt John W. Multimedia and text messaging with speech-to-text assistance
KR100517988B1 (ko) * 2003-04-16 2005-09-30 엘지전자 주식회사 Ｇｓｍ 단말기의 문자메시지 수신 방법
DE10325889A1 (de) 2003-06-06 2004-12-23 Siemens Ag Verfahren zum Übertragen von Nachrichten
DE10353117B3 (de) * 2003-11-12 2005-07-14 Vodafone Holding Gmbh Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen
US7865181B1 (en) 2004-03-19 2011-01-04 Single Touch Interactive, Inc. Searching for mobile content
US20060031369A1 (en) * 2004-07-01 2006-02-09 Marc Caron Method, system, and edge multimedia messaging service (MMS) relay/server for multi-staged MMS
KR101048432B1 (ko) * 2004-10-05 2011-07-11 엘지전자 주식회사 이동통신 단말기의 파일을 이용한 메시지 전송 방법
AU2004324519B2 (en) * 2004-11-02 2010-06-10 Core Wireless Licensing S.A.R.L. Informing recipient device of message content properties
KR101155335B1 (ko) * 2005-01-07 2012-06-11 엘지전자 주식회사 이동통신 단말기의 멀티미디어 메시지 동작방법
KR100764787B1 (ko) * 2005-09-14 2007-10-11 엘지전자 주식회사 액티브 콘텐츠를 송수신하기 위한 방법 및 단말기
US8050660B2 (en) * 2006-03-07 2011-11-01 Motorola Mobility, Inc. Apparatus and method for handling messaging service message adaptation
WO2009116053A2 (en) * 2008-03-18 2009-09-24 Nowpos Online Services Pvt. Ltd. An invention for dispatch of opacity-controlled 'always-on-top' formats on telecommunication devices
EP2175378A1 (en) * 2008-10-13 2010-04-14 Vodafone Holding GmbH Provision of data stored in a memory card to a user device
US20120149339A1 (en) * 2010-12-10 2012-06-14 MobileIron, Inc. Archiving Text Messages
CN102164353B (zh) 2011-04-13 2013-08-28 青岛海信移动通信技术股份有限公司 一种解析mms信息的方法和设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066746A2 (en) * 1998-06-15 1999-12-23 Nokia Networks Oy A method for delivering messages in a wireless communications system using the same protocol for all types of messages
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages
WO2001033782A1 (en) * 1999-11-05 2001-05-10 Nokia Corporation Multimedia messaging service

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07175710A (ja) * 1993-12-20 1995-07-14 Canon Inc データ管理方法及び装置
GB2314729B (en) * 1995-12-19 2001-01-17 Motorola Inc Method and apparatus for rate governing communications
US5724412A (en) * 1996-10-07 1998-03-03 U S West, Inc. Method and system for displaying internet identification on customer premises equipment
US5850511A (en) * 1996-10-28 1998-12-15 Hewlett-Packard Company Computer implemented methods and apparatus for testing a telecommunications management network (TMN) agent
US5987100A (en) * 1997-04-23 1999-11-16 Northern Telecom Limited Universal mailbox
US20010012286A1 (en) * 1999-01-29 2001-08-09 Emmanuel L. Huna Method and apparatus for computer alert of device independent messages
US6647409B1 (en) * 1999-07-13 2003-11-11 Microsoft Corporation Maintaining a sliding view of server based data on a handheld personal computer
US6865609B1 (en) * 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
FI111780B (fi) * 1999-12-23 2003-09-15 Nokia Corp Sanomanvälityspalvelu
US7039678B1 (en) * 2000-09-07 2006-05-02 Axis Mobile, Ltd. E-mail proxy
US7031968B2 (en) * 2000-12-07 2006-04-18 Prev-U Israel Ltd. Method and apparatus for providing web site preview information

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999066746A2 (en) * 1998-06-15 1999-12-23 Nokia Networks Oy A method for delivering messages in a wireless communications system using the same protocol for all types of messages
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages
WO2001033782A1 (en) * 1999-11-05 2001-05-10 Nokia Corporation Multimedia messaging service

Also Published As

Publication number Publication date
US8099081B2 (en) 2012-01-17
US20040097248A1 (en) 2004-05-20
WO2002058359A1 (de) 2002-07-25
JP5006864B2 (ja) 2012-08-22
JP4358511B2 (ja) 2009-11-04
JP2004517587A (ja) 2004-06-10

Similar Documents

Publication Publication Date Title
JP5006864B2 (ja) 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置
EP1599979B1 (en) Message management
US8243890B2 (en) All-HTTP multimedia messaging
US9419926B2 (en) System, method and computer program product for the delivery of media content
AU2002253481B2 (en) Multimedia messaging method and system
US6629130B2 (en) Method and apparatus for processing electronic mail
US20020087549A1 (en) Data transmission
JP5743422B2 (ja) ファイルタイプおよび／またはファイルフォーマットの変換を伴うｍｍｓメッセージの伝送方法、加入者端末装置
EP2249590B1 (en) Method and system for interworking converged messaging service
US20030086438A1 (en) Method for accessing messages, and associated apparatuses and software programs
US20080261591A1 (en) Method for Transmitting Application-Specific Registration or De-Registration Data and System, Server and Communication Terminal Therefor
EP1760974B1 (en) A method, system and terminal for implementing information transfer services
WO2005117469A1 (en) System and method of interworking messages between mobile communication terminals
JP2004509572A (ja) 移動無線ネットワークにおけるデータ伝送コストアカウント方法
US20030081555A1 (en) Method, apparatus and software program for extending the flow of information when transmitting a message
CN100546300C (zh) 多媒体消息接发服务中媒体内容的流式传输
JP2004532567A (ja) マルチメディアメッセージサービス（ｍｍｓ）におけるメッセージング
CN101047668B (zh) 扩展信息发送方法
KR20080034072A (ko) Ｓｉｐ기반의 전송 메시지를 이용한 이종 메시지의 전송방법 및 이를 위한 사용자 장치
WO2008044829A1 (en) Method for transmitting different type messages using a sip-based transport message and user equipment therefor
US20030096598A1 (en) Method for transmitting data
CN100556002C (zh) 用于数据传输的方法和装置

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20101227

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20101228

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110629

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110727

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111012

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120426

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120525

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150601

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5006864

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term