JP5006864B2 - Method and mobile communication device for data transmission in a mobile radio network - Google Patents
Method and mobile communication device for data transmission in a mobile radio network Download PDFInfo
- Publication number
- JP5006864B2 JP5006864B2 JP2008319719A JP2008319719A JP5006864B2 JP 5006864 B2 JP5006864 B2 JP 5006864B2 JP 2008319719 A JP2008319719 A JP 2008319719A JP 2008319719 A JP2008319719 A JP 2008319719A JP 5006864 B2 JP5006864 B2 JP 5006864B2
- 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.)
- Expired - Lifetime
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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
本発明は、請求項1の上位概念に記載の移動無線ネットワークにおけるデータ伝送方法、請求項25の上位概念に記載の移動通信装置、請求項29記載のコンピュータ読み取り可能な媒体ならびに請求項31記載の無線通信システムに関する。
The present invention provides a data transmission method in a mobile radio network according to the superordinate concept of
たとえばGSM標準に従い動作するネットワークのようなこれまでの移動無線ネットワークによって、まだかなり制約されているがテキストデータを伝送する可能性が開かれている。つまりたとえば160個のキャラクタまでのショートメッセージを伝送することができる。このような機構はSMS(ショートメッセージサービス Short Message Service)と呼ばれる。そしてこの種のテキストメッセージの送信コストはデータ送信側が担うことになっている。 Previous mobile radio networks, such as networks operating according to the GSM standard, open the possibility of transmitting text data, albeit still quite limited. That is, for example, a short message of up to 160 characters can be transmitted. Such a mechanism is called SMS (Short Message Service). The transmission cost of this type of text message is to be borne by the data transmission side.
将来は、マルチメディアデータたとえば音声付きまたは音声なしの静止画や動画の伝送も可能になるはずである。このような伝送においてはデータ伝送量やデータ形式の著しい拡大が見込まれ、これには伝送時間やコストの増大が伴う。 In the future, it will be possible to transmit multimedia data such as still images and moving images with or without sound. In such transmission, the data transmission amount and the data format are expected to increase significantly, which is accompanied by an increase in transmission time and cost.
本発明の課題は、移動無線ネットワークの加入者のためのデータ伝送コントロールを簡単にすることにある。 It is an object of the present invention to simplify data transmission control for mobile radio network subscribers.
本発明によればこの課題は、請求項1の特徴を備えた方法、請求項25の特徴を備えた移動通信装置、請求項29の特徴を備えたコンピュータ読み取り可能な記憶媒体、ならびに請求項31記載の無線通信システムによって解決される。有利な実施形態については請求項2から24、請求項26から28ならびに請求項30を参照されたい。本発明の方法によれば、情報は受信のために用意されるデータの特性に関してデータ受信側へ情報を伝達することができ、これにより受信側にとってコントロールが簡単になる。
According to the invention, this object is achieved by a method with the features of
伝送すべきデータの特性を表す識別信号をまえもって送信することで、本来のデータの受信前にすでにコントロールが可能となり、その際に殊に有利であるのは、このようにして得られた情報に基づき、供給されるデータをいま受信したいのかあとで受信したいのか、それともまったく受信したくないのかという選択の余地が与えられることである。また、マルチメディアメッセージ(MM)を一部分だけ受信するという選択の可能性も与えられているならば、受信側はたとえば自身にとって重要な短い情報だけをダウンロードすることができ、そのような情報であれば短い伝送時間しか必要とせず、さらに必要に応じて多くのメモリを要する付加的な画像コンポーネント等をあとからダウンロードしてもよいし、あるいはそれらはまったくダウンロードしないようにすることができる。 By transmitting the identification signal indicating the characteristics of the data to be transmitted, it is possible to control the data before receiving the original data. In this case, the information obtained in this way is particularly advantageous. On the basis of this, there is a choice of whether to receive the supplied data now or later or not at all. Also, if the possibility of receiving only a portion of a multimedia message (MM) is given, the receiver can download only short information that is important to him, for example. For example, additional image components that require only a short transmission time and require a large amount of memory may be downloaded later, or they may not be downloaded at all.
このために使用される識別信号に受信すべきデータセットのサイズに関する情報が含まれているならば受信側は、データの伝送および/または調査にどの程度の時間を見込む必要があるのか、ならびにその時間をいま費やすのかあとで費やすのか、あるいは費やす意志がないのかについて確定することができる。 If the identification signal used for this contains information about the size of the data set to be received, the receiver must allow time for data transmission and / or investigation and You can decide whether you want to spend time now, later, or not willing to spend.
識別信号にデータセットの名称に関する情報が含まれているならば受信側は、データがどの複合テーマからのものであるのかを調べることができる。さらに有利には受信側は、それらのデータセットをいま受信したいのかあとで受信したいのか、あるいはまったく受信する意志がないのかを選択することができる。 If the identification signal contains information about the name of the data set, the receiving side can check which composite theme the data is from. More advantageously, the receiver can choose whether they want to receive these data sets now, later, or not at all.
さらに識別信号にデータ形式に関する情報も与えることができると殊に有利であり、これにより受信側は、たとえば画像データであるのかテキストデータであるのか、および/または音楽データであるのかを知るようになる。このようにしてコントロールおよびトランスペアレンスが格段に改善される。 Furthermore, it is particularly advantageous if the identification signal can also be given information on the data format, so that the receiver knows whether it is image data, text data and / or music data, for example. Become. In this way, control and transparency are greatly improved.
図面に新たに描かれた後述の本発明対象に関する実施例によって、本発明のさらに別の利点や特徴がわかる。図1〜図3中、同じ動作や機能をもつ構成要素にはそれぞれ同じ参照符号が付されている。 Further advantages and features of the present invention can be seen in the examples relating to the subject of the invention described later, which are newly drawn in the drawing. In FIG. 1 to FIG. 3, the same reference numerals are assigned to components having the same operations and functions.
この実施例では、WAP標準のためのデータ伝送スキーマ1に本発明を適用した事例について説明されており、これはたとえばUMTS標準(universal mobile telecommunication standard)において殊に画像データや書式付きテキストデータの伝送において利用される。なお、本発明を他の標準にも転用できることは自明である。
In this embodiment, an example in which the present invention is applied to the
UMTS標準の場合、従来のSMSに加えてメッセージ伝送用のいわゆるMMS(Multimedia Messaging Service)も設けられており、これはマルチメディアメッセージ(MM)とも呼ばれる。これによって書式付きテキストや画像も音声付きまたは音声なしで伝送することができる。SMSにおいて設定されている160キャラクタのメッセージ長までという制約がなくなる。音声メッセージやビデオメッセージの伝送が可能となる。 In the case of the UMTS standard, in addition to the conventional SMS, a so-called MMS (Multimedia Messaging Service) for message transmission is also provided, which is also called a multimedia message (MM). This allows formatted text and images to be transmitted with or without sound. There is no restriction on the message length of 160 characters set in SMS. Audio messages and video messages can be transmitted.
MMSはWAPを利用することによって実現できる。この場合、データたとえばマルチメディアメッセージ(Multimedia Message MM)の無線伝送のために、図1に示されているプロトコルスキーマ(WAP WSP: Wireless Session Protocoll)が用いられる。これにはデータ送信側のレベル2(MMSユーザエージェントAとも呼ばれる)、サービスを実行しMMSリレーとも呼ばれるプロバイダのレベル3および受信側のレベル4が含まれている。データ送信側のレベル2は少なくとも1つの通信機器5を有しており、さらに受信側のレベル4も通信機器6を有している。この通信機器5,6をたとえば一般的な携帯電話として構成することができるし、あるいはたとえばラップトップなど他の入力機能または出力機能を備えた機器として構成することができる。
MMS can be realized by using WAP. In this case, the protocol schema (WAP WSP: Wireless Session Protocol) shown in FIG. 1 is used for wireless transmission of data, for example, a multimedia message (MM). This includes level 2 (also called MMS user agent A) on the data sending side,
送信側の通信機器5において作成されたまたはこの機器を介して転送すべきマルチメディアメッセージ(略してMM)にはたとえばいくつかの画像、フィルムシーケンス、テキストなど1つまたは複数のユニット(データセット7)を含めることができる。MMはまずはじめに問い合わせ送達9(これはWAPプロトコルではM-Send.reqという名称をもつ)をプロバイダ(レベル3)へ送信する。
The multimedia message (abbreviated as MM) created in or transmitted through the
到来した送達9はそこから返送10(M-send.conf)によって送信側(レベル2)へ確認応答される。
The
時間的にこれに続いて、プロバイダ(レベル3)から情報11(M-Notification.ind)が受信側(レベル4)へ送信され、これによって受信側に対し、ダウンロード用のメッセージがプロバイダに用意されていることが通知される。 Subsequent to this, information 11 (M-Notification.ind) is transmitted from the provider (level 3) to the receiving side (level 4), and a message for download is prepared in the provider for the receiving side. Is notified.
これによってプロバイダ3はたとえば自動的に、確認応答返送メッセージ12(M-NotifyResp.req)を受信側の通信機器6(レベル4)から自動的に受け取る。
Accordingly, for example, the
送達13(WSP GET.req)を用いた受信側の要求に応じてはじめて、プロバイダから送達14(M-retrieve.com)によりMMが受信側へ転送される。 Only in response to a request on the receiving side using the delivery 13 (WSP GET.req), the MM is transferred from the provider to the receiving side by the delivery 14 (M-retrieve.com).
メッセージ15(M-Acknowledge.ind)はMMの受信について確認応答する。続くメッセージ16(M-Delivery.ind)によって受信確認応答が送信側2へ戻される。
Message 15 (M-Acknowledge.ind) acknowledges receipt of the MM. A subsequent message 16 (M-Delivery.ind) returns a reception confirmation response to the
送達9,10,11,12,15,16を管理するためにいわゆるヘッダフィールドが用いられ、つまりこれは本来のMMの前に置かれたフィールドであり、これらのフィールドには発信元、送信時刻、ファイルサイズおよび他の詳細な点に関する情報を含めることができる。
A so-called header field is used to manage the
本発明によればヘッダフィールドの個数が増やされ、その目的は、MMの特徴パラメータに関する情報フィールドとして少なくとも1つの別のフィールド17,18,19,20,21,22,23を通知できるようにするためであり、そこにおいて1つまたは複数の識別信号をそれらのパラメータのために受信側4へ送信できるようにするためである。
According to the present invention, the number of header fields is increased, the purpose of which is to enable notification of at least one
実施例ではこのために0x80〜0x86までの16進数体系でアドレッシングされるフィールド17,18,19,20,21,22,23が設けられており(図4参照)、その目的はあとで詳しく説明するパラメータに関する情報を収容するためである。付加的なヘッダフィールドの個数やアドレッシングをこれとは異なるようにしてもよい。
In the embodiment,
付加的ないわゆるヘッダフィールド17,18,19,20,21,22,23は少なくとも、受信側に対しMMが用意されていることを通知するメッセージ11内に収容されている。メッセージ9(M-Send.req)も、付加的なパラメータが送信側2から生成されるならば、付加的なヘッダフィールド17,18,19,20,21,22,23を含んでおり(図2)、さらに本来のMM送達14(M-Retrieve.conf)(図5参照)あるいは別のメッセージ10,12,13,15,16も含んでいる。
Additional so-called
MMのデータセット7とは以下ではMMの個別の構成部分のことであるとし、これは形式(たとえば静止画)とフォーマット(たとえばJPEG)によって定義されていて、この場合、MMS内ではMMSリレー3によるフォーマット変換も行われ、これによりある形式の特定のフォーマットしかサポートしない受信側4の通信装置6であっても、そのフォーマットだけで操作できるようになる。たとえば通信機器6はJPEGフォーマットの静止画だけしか表示できず、これは本出願ではMMSリレー3に通知される。MMSリレー3はこの受信側のために到来するすべての静止画をJPEgフォーマットに変換し、これによって一般にデータサイズが変化する。このアスペクトは本発明による新たなヘッダフィールドの後述の説明で重要となる。
The
識別信号としてたとえばデータセット7に関する以下の情報を含めることができる。なお、これとは異なる個数の情報たとえば言及するもののうちいくつかの選択した情報のみとしてもよい。これらの情報は、オプションで通知11(M-Notification.ind)においてWAP標準(図1)を使用したときにMMの受信側が利用でき、つまりはマルチメディアメッセージにおける本来のデータの伝送前に利用することができる。
For example, the following information regarding the
受信側に事前に通知されるたとえばMMなどの伝送すべきデータの考えられるパラメータは以下のとおりである:
1.MMに含まれるデータセット7の個数(これはMMの個々の要素の記述によっても暗黙的に示される)
2.データセット7の個々のサイズ(オクテット単位)
3.データセットの個々の形式およびフォーマット
4.データセットの個々のコンテンツID(Content Identification)、これは場合によってはMM全体のコンテンツID/メッセージIDにも係わる
5.データセットの個々の名称
6.MM全体のテーマ
7.ある要素とMMにおける1つまたは複数の別のデータセット7とのリンク
8.MM全体または1つまたは複数のデータセット7とMM外の1つまたは複数のURIとのリンク、この種の外部リンクの場合にはオプションとして解決された外部リンクのロードすべきデータのサイズ。
Possible parameters of data to be transmitted, such as MM, which are notified in advance to the receiving side are as follows:
1. The number of
2. Individual size of data set 7 (in octets)
3. 3. Individual format and format of the
新しいヘッダフィールド17,18,9,20,21,22,23を用いて、MMS内の詳細通知 "detailed Notification" の方式を変換することができ、ユーザに対するMMの快適性を高めることができる。MMのロード前にすでに、つまりはユーザに対するコストが発生してしまう前に事前に、そのユーザにMMの内容および構成に関して詳しく通知して、それ相応に取り扱うことができ、たとえばMMの個々のデータセット7だけをダウンロードしその他を拒否するように処理することができる。 The new header fields 17, 18, 9, 20, 21, 22, and 23 can be used to convert the detailed notification "detailed Notification" method in the MMS, and the comfort of the MM for the user can be improved. Already before the MM is loaded, that is, before the costs to the user are incurred, the user can be informed in detail regarding the contents and configuration of the MM and handled accordingly, eg individual data of the MM It can be processed to download only set 7 and reject others.
MMは基本的に、ヘッダおよびMMの形式に依存して付加的にデータパート(WAP: Body)から成る。ヘッダは一般にMMの情報を有しており、これは定義されたヘッダフィールドによって構成されている。メッセージのデータパートには任意の形式(たとえばテキスト、画像、音声など)の1つまたは複数の要素が含まれており、これは任意の順序でヘッダに続いている。データパート中にプレゼンテーション記述が含まれているならば、WAPメッセージにおいてデータパートの最初にいわゆるスタートパラメータがこのプレゼンテーション記述を参照するようにすべきである。各ヘッダフィールドはフィールド名から成り、これにフィールド値が続き、このフィールド値は少なくとも1つのオクテットから成る。16進数とフィールド名との対応づけは図4に示されている。 MM basically consists of a data part (WAP: Body) additionally depending on the format of the header and MM. The header generally has MM information, which is composed of defined header fields. The data part of the message includes one or more elements in any format (eg, text, image, audio, etc.) that follow the header in any order. If a presentation description is included in the data part, the so-called start parameter should refer to this presentation description at the beginning of the data part in the WAP message. Each header field consists of a field name, followed by a field value, which consists of at least one octet. The correspondence between hexadecimal numbers and field names is shown in FIG.
受信側への通知11に所望の情報を添付するため基本的に2つの可能性がある。すなわち情報をプロバイダ3によって作成するか、あるいは送信側2によって作成する。ミックスフォームも可能である。詳細にはこのために以下のプロセスが考えられる:
情報はMMSリレー3にメッセージ9とともに到来するMMから取り出され、すなわち一部はヘッダフィールドからそのまま引き継がれ、一部はMMのデータパートから計算される(たとえば1つのデータセット7のサイズ情報)。この過程で有利であるのは、メッセージ11と受信側4(ユーザエージェントB)の要求に応じてそこへ伝送される実際の内容14(WAP: M-Retrieve.conf)との間で予期される一貫性である。送信側2における実現コストつまりは移動端末機器におけるi.d.Rは低いままである。別の利点は、フォーマット変換が行われるときにサイズ情報の精度に関して得られる。MMSの場合、データ供給前に内容をサービスプロバイダ3により、受信側のMMSユーザエージェント4の能力(たとえばサポートされるコーデック、端末機器のディスプレイサイズ等)または受信側の好み(最大サイズに合わせた自動制限)に整合させることができる。MMSリレー3はデータ整合後の中味のサイズを受信側4に通知することができる。これは送信側2が所有していない情報である。欠点は、MMSリレー3においてこの「詳細情報 "detailed Notification"」のための情報を生成するために付加的なコストがかかることであり、これはMMに対し必要とされる「構文解析」と対応する情報の抽出によって生じる。
There are basically two possibilities for attaching desired information to the
The information is taken from the MM that arrives with the
このようにするのではなく送信側2によってすでに情報を生成し、ヘッダフィールド17;18;19;20;21;22;23としてMM送信のためのメッセージ9(WAPではM-Send.req)に明示的に統合してもよい。有利なことにMMSリレー3におけるMMの処理はそのままであり、これによってMMの中味を分析する必要がない。新たなヘッダフィールド17;18;19;20;21;22;23により開かれる端末機器5における可能性の実現はメーカによって決定できる。しかも、快適性に関して様々な特徴をもつ端末機器を提供することができる。さらにMM送信側の加入者2は、MM要素の内部的および外部的な結合に関する知識をMM受信側へ詳細情報として通報することができ、これはMMSリレー3によってのみ転送される。データセット7の内部的および外部的な結合に関する知識を必要とするMMSリレー3内でのヘッダフィールドの生成は、そこにおいて手間をかけてMMの構文解析をすることによってしか行えない。欠点はヘッダフィールドが部分的に冗長な情報によって拡張されることである。
Rather than doing this, information is already generated by the sending
したがって有利であるのは、一部は送信側のユーザエージェント2で一部はMMSリレー3において情報を生成することであり、このためにはMMSリレー3の側で送信側2により生成された既存のヘッダフィールドの更新も必要である。
Therefore, it is advantageous to generate information partly at the
付加的な情報の生成に関するこのようなミックスフォームのために、以下で説明する情報を次のように分けることができる:
送信側のユーザエージェント2における生成:
・X-Mms-Content-ID: 従来のWAP仕様では、データセット7に(たとえば個々の名称と形式とにより)固有の付加的なヘッダフィールドを割り当て、複数のデータセットを階層的に配置することができない。そのためMMをインターネットメール(MIME = Multipurpose Internet Mail Extensions による拡張を伴うRFC 822 に準拠したフォーマット)にトランスペアレントに変換するために、以下の前提を提案する:Eメールのいかなる拡張に対し場合によっては付加的にEメールのデータパート中に符号化される情報(名称、形式等)はMMにもトランスペアレントに含まれる。各データセット7に一義的に対応づけられているMMのヘッダ中のコンテンツIDを参照指示として利用することができる。メッセージボディ(=本来の通知情報を含むデータ構造セクション)をフィールドとして定義しておく必要があり、このフィールドはプレゼンテーション記述オブジェクトのコンテンツID(=内容識別子)CIを有しており、これによりそのオブジェクトへのアクセスが可能となる。このような取り決めによってMMSリレーから任意の受信側へMMをトランスペアレントに伝送することができ、これはダイレクトに他のMMSリレーを介して行ってもよいし、Eメールによりインターネットを介して行うこともできる。データセット7に対する一義的な対応づけは、送信側のユーザエージェント2からMMSリレー3への最初の伝送のために絶対に必要である。
・X-Mms-Content-Type: これはデータセットの形式とフォーマットを表す。これらは送信時にすでにエントリすべきものである。なぜならばデータセット7はEメールの場合に要に必ずしもファイル名を保持しておらず、そうなるとファイルの拡張(エクステンション、拡張子)によってあるフォーマットに対応づけることができない。MMSリレー3によるこのフィールドの更新は、フォーマットおよび/または形式を変換するときにのみ必要である。X-Mms-Content-Type は値または信号CTVによって表され定められる。
・X-Mms-Content-Size: データセット7のサイズ。これは値もしくは内容CSVによって表され定められる。
・X-Mms-Content-Name: データセット7の名称。この名称は送信側のユーザエージェント2にとってのみ既知であり、それゆえそのユーザエージェントによってセットする必要がある。それに対し内容CNVが割り当てられる。
・X-Mms-External-Link-Flag: データセット7はMM外の内容へのリンクを有することを示す。この情報が送信側ユーザエージェント2によりセットされれば、MMSリレー3によるデータセット7の内容分析が不要となる。これには内容的に値またはキャラクタシーケンスELFが対応づけられている。
・X-Mms-External-Link-Size: これによってMM外のリンクされた内容のサイズが表される。これは内容ELSにより示される。外部の内容のデータ量はリンク自体からは読み取れないので、この情報はユーザにとって重要である。この情報は、送信側のMMSユーザエージェント2においてMMの生成時にすぐに生成することができる。択一的にMMSリレー3によって生成することも可能であるが、そのためにはMM全体の分析のほかにもサイズを求めるため参照指示されているオブジェクトへのアクセスも必要となる。
・X-Mms-Content-Related-URI: このフィールドの情報CRVは、データセット7が関連づけられている他の要素のロケーションを指示する。たとえばデータセット7には、オーディオコンテンツ、ビデオコンテンツまたは他のMMのコンテンツを伴う多の要素に関連するプレゼンテーション記述が含まれている。この情報の生成には、送信側のMMSユーザエージェント2の側に存在するMMの要素の内部的な関連づけに関する情報が必要とされる一方、MMSリレー/サーバ3もしくは受信側4におけるMM要素のポジションに関する情報も必要とされる。これらの情報は送信側MMSユーザエージェント2の側においてヘッダフィールド内でコーディングすることができ、ついでMMSリレー3によって目下のポジションに基づき補正/更新することができ、その後、受信側MMSユーザエージェント4において評価することができる。
For such a mixed form of generating additional information, the information described below can be separated as follows:
Generation in
X-Mms-Content-ID: In the conventional WAP specification, a unique additional header field is assigned to data set 7 (for example, by individual name and format), and multiple data sets are arranged hierarchically. I can't. Therefore, to transparently convert MM to Internet mail (format compliant with RFC 822 with extension by MIME = Multipurpose Internet Mail Extensions), we propose the following assumptions: possibly additional to any extension of email Information (name, format, etc.) encoded in the e-mail data part is also transparently included in the MM. The content ID in the header of the MM uniquely associated with each
X-Mms-Content-Type: This represents the format and format of the data set. These should already be entered at the time of transmission. This is because the
-X-Mms-Content-Size: Size of
-X-Mms-Content-Name: Name of
X-Mms-External-Link-Flag: Indicates that
X-Mms-External-Link-Size: This represents the size of the linked content outside the MM. This is indicated by the content ELS. This information is important to the user because the amount of external content data cannot be read from the link itself. This information can be generated immediately when the MM is generated in the transmitting
X-Mms-Content-Related-URI: The information CRV in this field indicates the location of other elements with which the
MMSリレー3における生成もしくは更新:
・X-Mms-Content-ID: MMSリレー3がデータセット7の形式および/またはフォーマットを変更する場合には、それ相応のコンテンツタイプ Content-Type の更新が行われる。
・X-Mms-Content-Size: これはデータセット7のサイズであり、オクテットで表される。MMSリレー3がデータセットの形式および/またはフォーマットを変更する場合にのみ、コンテンツサイズに係わる情報の更新が行われる。
Generation or update in MMS relay 3:
X-Mms-Content-ID: When the
X-Mms-Content-Size: This is the size of
ユーザ4がメッセージ11(WAP: M-Notification.ind)により受け取った多種多様な情報によって、たとえばソフトウェア側でメニューにインプリメントされ入力手段たとえばキーボードを介して操作されるセレクトスイッチ25を介して、個々のデータセット7へのアクセスも可能となる。したがってダウンロード要求により、(たとえば同時に付随テキストがいっしょに伝送されない写真などの)そのつど所望のデータセット7のコンテンツIDを用い、WAPであれば命令13WSP GET.reqによって部分的なダウンロードを指示することができる。
According to various information received by the
これを実現するためには、付加的なヘッダフィールドを部分的にMM内で何度も使用しなければならないという基本的な問題を解消する必要がある(WAPであればたとえばMMの各データセット7のためのX-Mms-content-Name)。また、データセットの記述において該当するように複数のヘッダフィールドが内容的に関連しているならば、シンタックス上の対応づけも必要である。 In order to achieve this, it is necessary to eliminate the basic problem that an additional header field must be partially used several times in the MM (for example, each data set of the MM in the case of WAP). X-Mms-content-Name for 7). In addition, if a plurality of header fields are related in terms of contents as applicable in the description of the data set, it is also necessary to make a syntactic correspondence.
基本的にWAP標準の場合にはヘッダフィールドの順序は問題にはならない。したがって情報の対応づけをヘッダ要素の順序に依存させてしまい、それが唯一通用するパスであるならば、複数のデータセット7の名称、サイズ、形式および/またはURIという情報の順序の変更によって、データセット7の記述の変化が引き起こされ、もしくは誤りが生じてしまうことになる。それというのもWAPではヘッダ要素の階層構造は設けられていないからである。他方、ヘッダ要素の順序が重要ではないという命題は、複数のリストを含むHTTPヘッダをそれぞれただ1つの要素しかもたない複数のWSPヘッダに変換すべきであり、その際にエントリの順序を維持すべきであるという命題と矛盾する。このような矛盾を開所する目的で、ヘッダ要素の順序の重要性を前提条件として必要とする体系を設計する。
Basically, the order of header fields does not matter in the case of the WAP standard. Therefore, if the correspondence of information depends on the order of the header elements, and that is the only valid path, by changing the order of the information such as names, sizes, formats and / or URIs of the plurality of
個々のデータセット7の記述を制限するため、定義されたヘッダフィールドによってデータセット7の記述が始まるようにする必要があり、これはメッセージのヘッダの終わりに達するまで、あるいは定義されたタイプの次のヘッダフィールドにより別のデータセット7の記述開始がマークされるまで、後続のすべてのヘッダフィールドに対応づけられる。
In order to limit the description of an
データセット7の記述のために定義されたヘッダフィールドとしてフィールド17:X-Mms-Content-IDが用いられる。その理由はこれには要素の一義的なアドレスが含まれているからである。データセット7の記述は基本的にこのフィールドにより導入され、それに応じて別のフィールドをオプションとして任意の順序で設けることができる。
Field 17: X-Mms-Content-ID is used as a header field defined for the description of the
ヘッダ中にメッセージ要素に対する一義的なマーク(コンテンツID Content-ID)と相応の参照指示をもつこの体系に対する代案として、MMのデータパートにおける既述のデータセットまでオフセットの指示により動作する体系も考えられる。とはいえこの場合の欠点は、オフセットが適正には計算されないおそれがあること、もしくはMMSリレー3においてフォーマット変換が可能であれば適正に整合できないおそれがあることであり、他方、メッセージ11におけるデータセットの記述とMMの実際の送達14におけるデータセットの記述との間の論理的な関係を確立できなくなることである。この場合、情報を通達されたマルチメディアメッセージにもう一度入れておかなければならない。
As an alternative to this system that has a unique mark (content ID Content-ID) for the message element in the header and a corresponding reference instruction, a system that operates by specifying the offset to the previously described data set in the MM data part is also considered. It is done. However, the disadvantage in this case is that the offset may not be calculated properly, or if the format conversion is possible in the
送信側(レベル2)は通信機器5においてハードウェア側であるいは殊にソフトウェア側でいずれにせよ設けられているキーボードを介して、扱うべき入力オプションを操作することができ、これによりヘッダフィールド17,18,19,20,21,22,23中に付加的な情報またはその一部分(s.o.)を格納することができる。これらはMMの1つまたは複数のデータセット7のための識別信号の構成部分として、送達9(WAPではM-Send.req 図1)とともにプロバイダ(レベル3)に送られる。MMSリレー3による送達の確認応答(WAP ではメッセージ10:M-Send.conf)はそのまま維持される。なぜならばオプションとしてMMSリレー3から与えられるメッセージIDが唯一の重要な情報だからである。
The transmission side (level 2) can operate the input options to be handled via the keyboard provided on the
ついで受信側4は、この受信側に対し1つまたは複数のデータセット7をもつMMがダウンロード用に用意されているというメッセージ11(WAPではNotification.ind)を受け取る。このメッセージ11にはやはり、メッセージ9のヘッダからデータセット7を記述するために送達(WAPではM-Send.req)に対し付加的なすべてのヘッダフィールド17,18,19,20,21,22,23が含まれている。この情報を受信側にオプションとして視覚的に(表示手段24たとえばディスプレイを介して)または聴覚的に通知することができる。
Next, the receiving
メッセージ Notification 11に対する受信側の確認応答12はそのまま変わらない。MMの受信側4に対しそれらの内容について詳細に通知された後、受信側MM(WAPでは命令13:WSP Get.req)をダウンロードすることができる。これに対する代案として本発明によれば、MMのただ1つの要素へのアクセスも可能である。この目的でたとえばURIとしてMMのデータセット7のコンテンツID Content-ID がダウンロード命令に組み込まれる。受信側4の了解なしにはMMのダウンロード(受信側への送達4の伝送)は許可されない。また、受信側4はMMを以降の任意の時点ではじめて伝達を希望することも可能である。
The receiving
本来のデータ送達14は既述のヘッダフィールド17,18,19,20,21,22,23を有することができる。しかし図7に示されているようにこれは必須ではない。
The
ついでMMSリレー3は、送信側2が望むならばMMの送達ステータスに関する通知16(WAPであればM-Delivery.ind)をそこへ送る。これまでにすでに知られている可能性 "Expired"(有効期限切れ)、"Retrieved"(送達)、"Rejected"(拒否)、"Deferred"(遅延)のほか、本発明によれば "Partly-retrieved"(部分的に送達)もステータスフィールドに設けることができる。これによりどのデータセット7が送達されたのかが表される。メッセージ16のそれ相応のセクションを以下のものとすることができる:
>>>>>
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>
<<<<<
同様に新しいフィールド22,23 X-Mms-External-Link-Flag(オプション)およびX-Mms-External-Link-Size(オプション)を、MM送達用のメッセージ9(WAPではM-Send.req)と受信側4へのメッセージ11(WAPではM-Notification.ind)とにおいて、MMに含まれるMM外のコンテンツへのリンクを表すことができる。MMヘッダ内のポジションに従いフィールド22:X-Mms-External-Link-Flagは、MM全体またはMMの特定のデータセット7内の外部のコンテンツへのリンクが表される。フィールド23:X-Mms-External-Link-Sizeにより、オプションとしてオクテットでコンテンツサイズが記述される。これによりノーティフィケーションNotificationの受信側は、MM自体のデータボリュームに対してどの付加的なデータボリュームをさらにダウンロードすべきかをすでに見積もることができる。
The
>>>>>
7.2.22 Status field
Status-value = Expired | Retrieved | Rejected | Deferred | Partly-retrieved
Expired = <
Retrieved = <
Rejected = <
Deferred = <
Partly-retrieved = <
<<<<<
Similarly, the
これまで説明してきたやり方を、たとえばUMTSなど個々の通信標準用のオペレーティングソフトウェアに組み込むことができる。この場合、通信機器5,6にはそれ相応のソフトウェアが設けられる。
The methods described so far can be incorporated into operating software for individual communication standards, for example UMTS. In this case, the
次に、WAP標準に準拠した本発明によるMM伝送(図1)の具体的な流れについて説明する。 Next, a specific flow of the MM transmission (FIG. 1) according to the present invention compliant with the WAP standard will be described.
ここではたとえば以下のシナリオを前提とする:送信側2(Markus Trauberg)は、複数のデータセット7をもつテキストすなわちMP3音声、JPEG画像、MPEG−4ビデオおよびSMILプレゼンテーション記述をもつテキストを伴うMMを2人の受信側4(Andreas Schmidt, Josef Laumen)へ送出する。これらの受信側4による快適かつ多種多様な利用のために、送信側はMMのデータセット7のパラメータ記述をそのヘッダに添付する。データはメッセージ9(M-Send.req)および11(M-Notification.ind)として受信側へ伝送される。受信側4 Andreas Schmidt はMM全体を自身の端末機器6にロードするのに対し、受信側4 Josef Laumen はテキストだけにしか関心がなく、それのみを自身の端末機器6にロードする。以下のMMが各ユニット間で伝送される:
MMは2tの宛先に送られる。この場合、メッセージプロトコルを図9のように描くことができる。
Here, for example, assume the following scenario: The sender 2 (Markus Trauberg) has text with
The MM is sent to the 2t destination. In this case, the message protocol can be drawn as shown in FIG.
MMにおいて、ヘッダ内でMM要素に関する付加的な情報ブロックがコーディングされる。そこにはMMの各データセット7間の関係も記述される:つまりその中の外部の要素 image/jpeg, audio/mp3, video/meg4 への presentation_description 参照の記述が対応するコンテンツIDとして含まれている。テキストの記述には、外部のオブジェクトに対する参照が含まれそれは8245byteのデータをもつという情報が含まれている。 In the MM, additional information blocks for MM elements are coded in the header. It also describes the relationship between each data set 7 of the MM: that is, the description of the presentation_description reference to the external elements image / jpeg, audio / mp3, video / meg4 in it is included as the corresponding content ID Yes. The text description includes a reference to an external object and information that it has 8245 bytes of data.
送信側2の上述の送信問い合わせ9(M-Send.req)の確認応答は、MMSリレー3によりメッセージ10(M-Send.conf)によって行われる。このメッセージ10には付加的な新しいフィールドは含まれておらず、このことは図10に示した以下のリストから明らかである。
The confirmation response of the transmission inquiry 9 (M-Send.req) on the
MMSリレー3はメッセージ10を用いることで、問い合わせ9が誤りなくMMSリレー3に伝送されたことを確認応答する。この場合、トランザクションId Transaction-ID#1 が利用され、これによりメッセージ10が送信側2においてそれに属する問い合わせ9(M-Send.req)に、ひいては送信されたMMに一義的に対応づけられる。フィールドX-Mms-Delivery-Report内のメッセージ9において送達レポートが要求されたので、MMSリレー3はMMにメッセージIDを割り当て、それをここでは送信側2へ伝達する。
The
さらにメッセージ11は受信側4へ伝送される:
M-Notification.ind (MMS Relay → MMS User Agent B):
MMSにおいて、MMの受信側に対しその受信側のために存在する新しいメッセージに関して通知されるように構成されている。メッセージ11(M-Notification.ind)は、ダウンロードのために準備されているMMについて宛先に通知するために用いられる。したがってこの実施例の場合には、受信側 Andreas Schmidt と Josef Laumen 宛の2つの通知が存在する。各々には固有のトランザクションIDが含まれている。MMのメモリロケーションに関する情報は、双方においてフィールド X-Mms-Content-Location におかれている。
In addition, the
M-Notification.ind (MMS Relay → MMS User Agent B):
In the MMS, the MM receiver is configured to be notified about new messages that exist for that receiver. Message 11 (M-Notification.ind) is used to notify the destination about the MM that is prepared for download. Thus, in this embodiment, there are two notifications addressed to the recipients Andreas Schmidt and Josef Laumen. Each contains a unique transaction ID. Information about the memory location of the MM is in both fields X-Mms-Content-Location.
図11には、M-Notification-ind の内容が例示されている。この場合、メッセージ11冒頭の通常のフィールドのほか、メッセージ9のすべての記述要素をメッセージ11に引き継ぐことができる。ミックスフォームに基づきすでに説明したようにそれらに加えてさらに、メッセージ9のボディの情報から X-Mms-Content-Type と X-Mms-Content-Size の情報がMMSリレー3によって生成される。受信側4はメッセージ11の受信後、(これまでのように)MMのアドレスも知ることになるし、個々のデータセット7およびそれらのコンテンツIDから成るそれらの組成も知ることになる。したがってMMの個々のデータセット7に対し別個にアクセスすることもできる。
FIG. 11 illustrates the contents of M-Notification-ind. In this case, all the description elements of the
ついで通知の適正な受信がMMの受信側4によりメッセージ12(M-NotifyResp.ind)により確認応答され、これはメッセージ11の適正なトランザクションIDをステータスメッセージとともにMMSリレー3へ送り戻すことによって行われる。
The proper reception of the notification is then acknowledged by the
MMのダウンロードは命令13(WSP Get.req)により指示される。MMはそれに基づきMMSリレー3によりメッセージ14(M-Retrieve.conf)として受信側4へ送信される。
Download of MM is instructed by instruction 13 (WSP Get.req). Based on this, the MM is transmitted to the receiving
個々の要素に関する情報はすでにメッセージ11として伝送されたので、これまでのとおりMM全体のダウンロードをメッセージ14によって行うことができ、その際に付加的なフィールドをこのメッセージ14のヘッダに挿入する必要なない。これに対し個々のデータセット7のヘッダ中の付加的な情報はメッセージ14内にも含まれているようにすべきであり、その理由はそれらにはMMデータセット7に関する重要な情報が含まれているからである。
Since the information about the individual elements has already been transmitted as the
次に、受信側4の2つの可能なリアクションについて例示する:
受信側 Andreas Schmidt はMM全体をロードする。
受信側 Josef Laumen はMMのうちテキストパートのみを自身の受信機器6にロードする。
Next, two possible reactions on the receiving
Receiver Andreas Schmidt loads the entire MM.
The receiving side Josef Laumen loads only the text part of the MM into his
最初に事例の場合、メッセージ14は図12に示されているようにコーディングされる:
受信側4 Andreas Schmidt は、MMの受信成功に続いてメッセージ15(M-Acknowledge.ind)で確認応答する。その中に含まれているトランザクションIDによって、送信されたMMに対する対応づけをMMSリレーにおいて図13の情報信号 M-Acknowledge.ind に応じて行うことができる。
In the first case,
Receiving
ついでトランザクションの最後のステップとして、メッセージ16(M-Delivery.ind)が図14に従いMMSリレー3から送信側2へ伝達される:
これに対し第2の受信側 Josef Laumen は、メッセージ14のテキストパートのみをダウンロードするものと決める。このため第2の受信側はメッセージ13(WSP GET.req)中にテキストパートのコンテンツID "000714.1412.1markus.trauberg" を挿入する。この受信側はこのテキストパートをメッセージ14(M-Retrieve.conf)として受け取り、これは Andreas Schmidt におけるバージョンとは著しく異なっており、その内容を図15に例示した。
Then, as the last step of the transaction, a message 16 (M-Delivery.ind) is transmitted from the
In contrast, the second recipient Josef Laumen decides to download only the text part of the
メッセージ14は Andreas Schmidt へ送られたもののようにその完全なバージョンに比べ、望まないデータセット7の分だけ低減されている。しかもフィールド nEntries が相応に整合されている。
The
図16に示されているメッセージ15(M-Acknowledge.ind)は Andreas Schmidt のバージョンとほぼ完全に一致しているけれども、固有のトランザクションIDを有している:
最後のステップとして送信側2に対し送達ステータスに関して再び通知が行われる。これには部分的な送達("Partly-retrieved")のステータスが含まれており、内容的には図17に描かれているようなものである。
The message 15 (M-Acknowledge.ind) shown in FIG. 16 is almost perfectly consistent with Andreas Schmidt's version, but has a unique transaction ID:
As a final step, the
マルチメディアメッセージサービス Multimedia Messaging Service (MMS)におけるマルチメディアメッセージ(MM)の受信側に対し詳しい通知を既述のようにして行うことができることのほか、既述の実施形態とは異なる利点をもつさらに別の好適なオプション構成が存在する。次に、この有利なオプションについて説明する。 Multimedia message service In addition to being able to perform detailed notification to the multimedia message (MM) receiving side in the Multimedia Messaging Service (MMS) as described above, there is an advantage different from the above-described embodiment. There are other suitable optional configurations. This advantageous option will now be described.
この変形実施形態の核となる着想は、個々の受信側に対し新たに定義されたただ1つのヘッダフィールドだけしか利用せずに個々のMMの内容に関して詳細に通知するというアイデアを実現することであり、そのフィールドのために新たなパラメータが挿入される。この場合、新たなヘッダフィールドにすべてのパラメータすなわち既述すべきMMの要素に関する情報が含まれている。本出願においてMMの要素もしくはデータセットとはMMの個々の構成部分のことであり、これはたとえばその形式(たとえば静止画)およびそのフォーマット(たとえば JPEG = joint photographics expert group)によって定義されている。 The core idea of this variant is to realize the idea of notifying each receiver in detail about the contents of each MM without using only one newly defined header field. Yes, a new parameter is inserted for that field. In this case, the new header field contains information on all parameters, that is, the elements of the MM to be described. In this application, an MM element or data set is an individual component of the MM, which is defined, for example, by its format (eg still images) and its format (eg JPEG = joint photographics expert group).
以下のリストには、すでに前述の実施形態のために提案された情報が含まれており、MMの受信側に対しオプションとしてMMS内の受信側メッセージ(M-Nind; WAPではM-Notification.ind)を使用することができる。これには以下のものが含まれる:
・MMに含まれている要素の個数(MMの個々の要素の記述により暗黙的でもある)
・1つの要素のサイズ(オクテット単位)
・1つの要素の形式およびフォーマット
・1つの要素のコンテンツID(Content IDentification)(=個々の識別信号における個々のヘッダフィールドの名称もしくは指示子
・1つの要素における名称
・MMにおける1つの要素と1つまたは複数の別の要素とのリンク
・MM全体または1つまたは複数の要素とMM外の1つまたは複数のURL/URI(uniform resource link/identifier)とのリンク、この種の外部のリンクであればオプションとして解決された外部のリンクにおいてロードすべきオブジェクトのサイズ
以下の実施例において、MMS受信側メッセージ(M-Nind; WAPではM-Notification.ind)および場合によってはMMS送信問い合わせ(M-Sreq; WAPではM-Send.req)およびMMS送達メッセージ(M-Rconf; WAPではM-Retrieve.conf)の選択的な拡張に対する相応のヘッダフィールドの定義について説明する。
The following list contains information already proposed for the above embodiment, and optionally for the MM receiver, the receiver message (M-Nind; M-Notification.ind in WAP) in the MMS. ) Can be used. This includes the following:
-Number of elements included in MM (also implicit by description of individual elements of MM)
-Size of one element (in octets)
-Format and format of one element-Content IDentification of one element (= name or indicator of each header field in each identification signal-Name in one element-One element and one in MM Or a link with multiple other elements, or the entire MM or a link between one or more elements and one or more URL / URIs (Uniform Resource Link / Identifier) outside this MM, this kind of external link The size of an object to be loaded in an external link, which is optionally resolved. In the following example, in an MMS receiver message (M-Nind; M-Notification.ind for WAP) and possibly an MMS send query (M-Sreq Selective extension of M-Send.req) and MMS delivery messages (M-Rconf; M-Retrieve.conf for WAP) For the definition of the header fields of the corresponding description against.
MMは基本的に(既述の実施例で示したとおり)ヘッダから成り、さらにメッセージの形式により場合によっては付加的にデータパート(WAPではボディ body)から成る。ヘッダにはメッセージの一般的な情報が含まれており、これは1つまたは複数の定義されたヘッダフィールドによって構成されている。場合によっては存在するメッセージのデータパートには1つまたは複数の任意の形式の要素が含まれており、これは任意の順序でヘッダに続いている。データパート中にプレゼンテーション記述が含まれている場合、たとえばWAPメッセージではデータパートの冒頭においていわゆるスタートパラメータによりこのプレゼンテーション記述が適切に指示されるようにする。 The MM basically includes a header (as shown in the above-described embodiment), and further includes a data part (body body in WAP) depending on the message format. The header contains general information about the message, which consists of one or more defined header fields. In some cases, the data part of an existing message includes one or more arbitrary types of elements, which follow the header in any order. When a presentation description is included in the data part, for example, in a WAP message, this presentation description is appropriately indicated by a so-called start parameter at the beginning of the data part.
ここで図1のメッセージの流れ図には、送信側ユーザ2(ユーザエージェントA=M−UA_A)からMMS接続ユニット3(MMSリレー=M−SR)を介して受信側ユーザ4(ユーザエージェントB=M−UA_B)へ向かうメッセージ伝達の基本的な流れが示されている。 Here, the message flow diagram of FIG. 1 shows that the sending user 2 (user agent A = M-UA_A) to the receiving user 4 (user agent B = M) via the MMS connection unit 3 (MMS relay = M-SR). -The basic flow of message transmission towards UA_B) is shown.
メッセージ形式に応じて可能なもしくは必要とされるWAPにおけるヘッダフィールドが、ここで考察するメッセージ形式に関して図21A、図21Bおよび図22による表として示されている。これらは 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" によれば、各ヘッダフィールドはフィールド名およびそれに続くフィールド値から成り、フィールド値は少なくとも1オクテットによって構成されている。図20による表には、WAPメッセージのフィールド名に対する16進数値の割り当てが示されている。このような別のオプションは、1つのMMの1つの要素を一義的に識別するための前述の実施例で言及したヘッダフィールドの定義すなわちX-Mms-Content-IDに基づくものであり、これはMMのボディにおいてMMの要素の前にヘッダフィールドとしておかれており、要素を一義的に表すものである。 The header fields in WAP that are possible or required depending on the message format are shown as a table according to FIGS. 21A, 21B and 22 for the message format considered here. These are shown in 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: According to "Header Encoding", each header field consists of a field name followed by a field value. It is composed of at least one octet. The table according to FIG. 20 shows the assignment of hexadecimal values to the field names of the WAP message. Another such option is based on the header field definition, X-Mms-Content-ID, mentioned in the previous embodiment to uniquely identify one element of one MM, It is placed as a header field in front of the MM element in the MM body, and uniquely represents the element.
前述の提案とは異なりMMの要素の記述はここでは単一のヘッダフィールドX-Mms-Content-IDをベースとしており、これは受信側に通知するためMMのヘッダに統合され、(受信側への通知のためその受信側に対し用意されているMMのデータセットの個数、形式、サイズ、フォーマットなどに関する)所要情報が以下のリストのうち1つまたは複数のパラメータにより記述される。
・名称:MM要素の名称を表す。
・形式:MM要素の形式およびフォーマットを表す。
・サイズ:MM要素のサイズをbyteで表す。
・外部リンク:要素がMM外のコンテンツへのリンクを含むことを表す。
・外部リンクサイズ:外部参照解決のためどの程度のデータボリュームを付加的にダウンロードする必要があるかを表す。
・関連ID:MMのどの要素がその要素と関係しているのか、およびそれをMMの部分的なダウンロード時にもダウンロードすべきか(多重利用が可能)を表す。
Unlike the previous proposal, the description of the elements of the MM is here based on a single header field X-Mms-Content-ID, which is integrated into the header of the MM to inform the receiver (to the receiver) The required information (related to the number, format, size, format, etc.) of the MM data set prepared for the receiving side is described by one or more parameters in the following list.
Name: Represents the name of the MM element.
Format: Represents the format and format of the MM element.
Size: The size of the MM element is represented by bytes.
External link: Indicates that the element includes a link to content outside the MM.
External Link Size: Indicates whether the extent of the data volume for external reference resolution additionally need to be downloaded.
Association ID: Indicates which element of the MM is related to the element and whether it should be downloaded even when the MM is partially downloaded (multiple use is possible).
つまり一般的に表現するとこの場合には、単一の付加的なヘッダフィールド内における1つまたは複数の対応するデータセットのための識別信号が、たとえば第1の移動無線機器および/または付加的なサーバのような個々の送信側から、MMS受信側通知として第2の移動無線機器のような受信側へ符号化されて伝送される。これにより、場合によっては複数のヘッダフィールドが利用されたときにそれら自体の間で、および/または対応づけられたデータセットの間で生じる可能性のある順序問題や対応づけ問題が最初から回避される。 In other words, in general terms, in this case, the identification signal for one or more corresponding data sets in a single additional header field is, for example, the first mobile radio device and / or the additional An individual transmission side such as a server is encoded and transmitted as an MMS reception side notification to a reception side such as a second mobile radio device. This avoids ordering and mapping problems from the outset that can occur between themselves and / or between mapped data sets in some cases when multiple header fields are used. The
前述の実施例についてすでに説明したものに加えてさらに以下の情報もパラメータとして符号化できるようにする:
1.オリジナル形式 Original-Type:MMS接続ユニット(M−SR)により符号変換される前のMM要素の形式を表す。
2.オリジナルサイズ Original-Size:MM接続ユニット(M−SR)により符号変換される前のMM要素のサイズをbyteで表す。
In addition to what has already been described for the previous embodiment, the following information can also be encoded as parameters:
1. Original format Original-Type: Represents the format of the MM element before code conversion by the MMS connection unit (M-SR).
2. Original size Original-Size: The size of the MM element before code conversion by the MM connection unit (M-SR) is expressed in bytes.
単一のヘッダフィールド内においてMM要素に関連するすべての情報をまとめることにより、前述の実施例において前提条件としたヘッダ順序の遵守を行わなくてよくなる。 By collecting all the information related to the MM element in a single header field, it is not necessary to comply with the header order as a precondition in the above-described embodiment.
図18には、WAPによるMMの受信側への詳細な通知の目的で新たに導入された単一のヘッダフィールドがフィールド名およびフィールド値のコーディングを含めて示されている。図20に示した表には、16進数値とフィールド名との対応づけが含まれている。図19による表には、16進数値とパラメータ名との対応づけおよびパラメータ値の符号化に使用すべき形式が含まれている。さらに表21A/21Bおよび表22には、相応のヘッダフィールドにより補われたWAPメッセージがリストアップされている。従来技術に対する表中のすべての変更および補足が枠で囲まれている。 In FIG. 18, a single header field newly introduced for the purpose of detailed notification to the MM receiver by WAP is shown including the coding of field name and field value. The table shown in FIG. 20 includes a correspondence between hexadecimal values and field names. The table according to FIG. 19 includes a format to be used for associating hexadecimal values with parameter names and encoding parameter values. Further, Tables 21A / 21B and 22 list WAP messages supplemented by corresponding header fields. All changes and supplements in the table to the prior art are boxed.
実施例:
さて、WAPフォーラムによる既述のメッセージの定義をベースとする以下の実施例では、WAPメッセージにおいて利用されるヘッダフィールドについて詳細に立ち入ることにする。ここでは例として以下のシナリオを前提とする:M−UA_A(Markus Trauberg)はマルチメディアメッセージMMAを受信側M−UA_B(Andreas Schmidt)へ送信し、その際、このメッセージはテキスト、MP3オーディオ、JPEG画像、MPEG−4ビデオおよびSMIL(synchronized multimedia integration language)プレゼンテーション記述から成る。受信側により快適かつ多種多様に利用するため、MMの要素の記述が本発明に従いMMのヘッダに供給される。データはメッセージM−SreqおよびM−Nindとして受信側へ伝送される。受信側である Andreas Schmidt はMM全体を自身の端末機器にロードする。この場合、以下のメッセージがユニット間で伝送される。
Example:
Now, in the following embodiment based on the above-mentioned message definition by the WAP forum, the header fields used in the WAP message will be described in detail. Here, assume the following scenario as an example: send M-UA_A to (Markus Trauberg) recipient M-UA_B multimedia message MM A is (Andreas Schmidt), at that time, the message text, MP3 audio, It consists of JPEG images, MPEG-4 video and SMIL (synchronized multimedia integration language) presentation description. A description of the elements of the MM is supplied to the header of the MM in accordance with the present invention for more comfortable and more versatile reception. Data is transmitted to the receiving side as messages M-Sreq and M-Nind. Andreas Schmidt, the receiver, loads the entire MM into his terminal device. In this case, the following message is transmitted between units.
MMAが宛先に送られる。その内容は図23に例示されている。 MM A is sent to the destination. The contents are illustrated in FIG.
このメッセージにおいて、ヘッダ中に付加的な情報ブロックが符号化され、つまり一般的に表現すればMM要素に関する1つまたは複数のパラメータが符号化される。そこにはMMの各要素間の関係も記述される。つまりプレゼンテーション記述(*.smil)の記述には、そこで参照されている要素 image/jpeg, audio/mp3, video/mpeg4 への参照指示が相応のコンテンツIDの形式で含まれている。テキストの記述には、外部のオブジェクトへの参照指示が含まれ8245byteのデータであるという情報が含まれている。 In this message, an additional block of information is encoded in the header, that is, in general terms, one or more parameters relating to the MM element are encoded. The relationship between each element of MM is also described there. That is, the description of the presentation description (* .smil) includes a reference instruction for the elements image / jpeg, audio / mp3, and video / mpeg4 referenced there in the form of a corresponding content ID. The description of the text includes information indicating that the reference instruction to the external object is included and the data is 8245 bytes.
従来技術によれば、MMSユーザエージェントAの送信問い合わせ(WAPではM−Send.req)に対しM−SRから1つのメッセージ(WAPではM−Send.conf)によって確認応答される。このEMの枠内ではこのメッセージは修正されず、したがってここではそれについては触れない。
M−Nind(M−SR → M−UA−B):
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 によるMMS(multimedia service)の場合、1つのMMの受信側に対しその受信側のために存在する新たなメッセージに関する情報を通知するように構成されている。メッセージM−Nind(WAPではM−Notification.ind)は、ダウンロードのために準備されているMMSに関して宛先に通知するために用いられる。図24にはその内容が例示されている。したがってこの実施例では受信側 Andreas Schmidt 宛の受信側通知が生じる。ここでMMAの記憶場所に関する情報はフィールド X-Mms-Content-Location 内に存在する。
According to the prior art, an MMS user agent A's transmission inquiry (M-Send.req in WAP) is acknowledged by a single message (M-Send.conf in WAP) from the M-SR. This message is not modified within the framework of this EM, so it is not mentioned here.
M-Nind (M-SR → M-UA-B):
3G TS 23.140 version 3.0.1, Release 1999; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description;
メッセージ冒頭の通常のフィールドのほか、メッセージM−Sreqにおいてこの変形実施形態に関して新しいすべての記述された要素をメッセージM−Nindに引き継がせることができる。付加的にM−SRにより形式 Type とサイズ Size の情報がメッセージM−Sreqのボディの情報から生成され、もしくは含まれている形式 image/jpeg の画像が形式 image/bmp へ変換される。その理由は端末機器はJPEG画像を表示できないからである。もともとの形式(オリジナルタイプ Original-Type)ともともとのファイルサイズ(オリジナルサイズ Original-Size)に関する対応する情報は、相応のヘッダフィールド内で補われている。受信側は詳細通知 detailed Nofitication を受け取った後、(これまでのように)MMのアドレスも個々の要素とそれらのコンテンツIDの組み合わせも知ることになる。したがってMMの個々の要素に別個にアクセスすることも可能である。 In addition to the usual fields at the beginning of the message, all the described elements that are new with respect to this variant in the message M-Sreq can be carried over to the message M-Nind. In addition, information on the format Type and size Size is generated from the information on the body of the message M-Sreq by the M-SR, or the included image of image / jpeg is converted to the format image / bmp. This is because the terminal device cannot display a JPEG image. Corresponding information about the original format (original type) and the original file size (original size) is supplemented in a corresponding header field. After receiving the detailed notification detailed Nofitication, the receiver will know the MM address as well as the combination of the individual elements and their content IDs (as before). It is therefore possible to access individual elements of the MM separately.
ついで通知の適正な受け取りに対しMMAの受信側はメッセージM−NRindで確認応答することができ、これはM−Nindの対応するトランザクションIDをステータスメッセージとともにMMSリレーに送り返すことにより行われる。この場合、MMAのダウンロードは命令W−Gregにより指示される。それに応じてM−SRからMM−UA AへメッセージM−Rconf内でMMが送信される。 Then the receiving side of the MM A to proper receipt of the notification can be acknowledged in the message M-NRind, this is done by sending back to the MMS relay with the corresponding transaction ID status messages M-nind. In this case, downloading the MM A is indicated by the instruction W-Greg. In response, the MM is transmitted from the M-SR to the MM-UA A in the message M-Rconf.
次に、メッセージが受信側 Andreas Schmidt により自身の端末機器に完全にダウンロードされる。メッセージM−Rconfはたとえば図25のようにして符号化される。 The message is then completely downloaded to its terminal by the recipient Andreas Schmidt. The message M-Rconf is encoded as shown in FIG.
ついで受信側M−UA Bは、MMAの受信成功を従来技術に従いメッセージにより確認応答する。 Then the receiving side M-UA B is acknowledged by a message in accordance with the prior art the successful reception of the MM A.
以上要約すると、マルチメディアメッセージサービス Multimedia-Messaging-Service (MMS)においてマルチメディアメッセージおよびその中に含まれているMM要素を詳細に記述する付加的な情報を伝送する方法が提供される。これらの情報はたとえば、それぞれ管轄のサーバたとえばM−SRなどから受信側のユーザエージェントへ、個々のMMS受信側通知内の単一または複数の付加的なヘッダフィールドによって伝送される。必要とされる情報は有利には送信側のユーザエージェントにより生成され、MMS送信問い合わせにおいてそれにより符号化されて管轄のサーバへ伝送される。付加的にまたはこれとは無関係に、必要とされる情報を管轄の交換/供給サーバにより個々に送信すべきMMのデータパートから抽出して、受信側のユーザエージェントへMMS受信側通知において符号化して伝送することもできる。有利には受信側のユーザエージェントへ、送達のためたとえば管轄サーバ内に用意されているメッセージの内容または内容の個々の要素に関して、以下の情報のうちの1つまたは複数を伝達することができる:
・MM内に含まれている要素の個数
・MMの要素のサイズ(オクテット単位)
・MMの要素の形式およびフォーマット
・要素の識別子(コンテンツIDもしくはURI)
・要素名
・1つまたは複数の要素とMM内の1つまたは複数の別の要素とのリンク(たとえばプレゼンテーション記述とプレゼンテーション要素)
・1つまたは複数の要素とMM外の任意の特性の内容(たとえばHTML/WMLページ)
・MM自体に加えてロード可能なリンクされた外部の要素の個々のサイズ(オクテット単位)
・M−SRによる符号変換前の要素の形式およびフォーマット
・M−SRによる符号変換前の要素のサイズ(オクテット単位)
この場合、要素の識別子(コンテンツIDもしくはURI)によって、単一のヘッダフィールド中の最初のエントリまたは複数のヘッダフィールドが用いられているならば要素もしくはデータセットごとの最初のヘッダフィールドの内容を表す。
In summary, a method is provided for transmitting additional information describing in detail a multimedia message and the MM elements contained therein in a multimedia message service Multimedia-Messaging-Service (MMS). These information are transmitted, for example, from the respective responsible server, eg M-SR, etc. to the receiving user agent by means of single or multiple additional header fields in individual MMS receiver notifications. The required information is preferably generated by the sending user agent, encoded thereby in an MMS transmission query and transmitted to the responsible server. Additionally or independently, the required information is extracted from the data part of the MM to be individually transmitted by the responsible exchange / supply server and encoded in the MMS receiver notification to the receiving user agent. Can also be transmitted. Advantageously, one or more of the following information can be communicated to the receiving user agent regarding the content of the message or the individual elements of the content prepared for delivery, for example in the jurisdiction server:
-Number of elements contained in MM-Size of MM elements (in octets)
-MM element format and format-Element identifier (content ID or URI)
Element name Link between one or more elements and one or more other elements in the MM (eg presentation description and presentation element)
The content of one or more elements and any characteristics outside the MM (eg HTML / WML pages)
The individual size (in octets) of linked external elements that can be loaded in addition to the MM itself
-Element format and format before code conversion by M-SR-Size of element before code conversion by M-SR (in octets)
In this case, the element identifier (content ID or URI) represents the contents of the first header field for each element or data set if the first entry in a single header field or multiple header fields are used. .
有利には1つのMMの1つの要素の記述をただ1つのフィールドによって行うことができ、これは一義的な識別番号もしくは名称ごとにマルチメディアメッセージのデータパート中の要素を指示し、これにはパラメータとして別個のヘッダフィールド内にではなく別の情報も含まれている。 The description of one element of one MM can advantageously be done by a single field, which indicates the element in the data part of the multimedia message by a unique identification number or name, Other information is included as a parameter rather than in a separate header field.
有利にはMMの受信側は詳細通知を受け取った後、要素MMの個々の要素だけを自身の端末にロードすることができる。同様に本発明によればMMS受信側通知(M−Nind)の付加的な情報をMMS送達メッセージ(M−Rconf)のヘッダ内で補うこともできる。 Advantageously, after receiving the detailed notification, the recipient of the MM can load only the individual elements of the element MM into his terminal. Similarly, according to the present invention, additional information of the MMS receiver notification (M-Nind) can be supplemented in the header of the MMS delivery message (M-Rconf).
有利には付加的なヘッダフィールドは、データセットごとにただ1つのヘッダフィールドしか使用しないならば、WAPにおいて以下のように符号化することができる。すなわち図20の表に示されているように00x10〜0x7Fの値の範囲内で、たとえば0x19としてフィールド名X-Mms-Content-IDが符号化される。また、図9の表に示されているようにX-Mms-Content-IDのフィールド値が符号化される。 Advantageously, additional header fields can be encoded in WAP as follows if only one header field is used per data set: That is, as shown in the table of FIG. 20, a field name X-Mms-Content-ID is encoded as, for example, 0x19 within a range of values of 00x10 to 0x7F. Also, the field value of X-Mms-Content-ID is encoded as shown in the table of FIG.
この単一のヘッダフィールドにおけるパラメータとしての情報は、たとえば図19の表に示されているようにして符号化することができる。 Information as a parameter in this single header field can be encoded, for example, as shown in the table of FIG.
WAPおよびMMSならびに殊にそれらの規格に関連する文献に対する基本的な情報として、以下のものを挙げておく:
[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 MMSユーザアプリケーション
M-SR MMS接続ユニット
M-Sreq MMS送信問い合わせ
M-Sconf MMS送信確認応答
M-Nind MMS受信側通知
M-NRind MMS受信側通知確認応答
W-Greq MMS送達問い合わせ
M-Rconf MMS送達メッセージ
M-Aind MMS送達確認応答
M-Dind MMS送達状態通知
As basic information for WAP and MMS and in particular the literature relating to those standards, the following are mentioned:
[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;
[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;
[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
In the present invention, the following conventional acronyms have been cited for simplicity in context, but their full meanings are listed below for clarity:
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
Abbreviations specific to MMS:
M-UA MMS user application
M-SR MMS connection unit
M-Sreq MMS transmission inquiry
M-Sconf MMS transmission confirmation response
M-Nind MMS receiver notification
M-NRind MMS receiver notification confirmation response
W-Greq MMS delivery inquiry
M-Rconf MMS delivery message
M-Aind MMS delivery confirmation response
M-Dind MMS delivery status notification
Claims (31)
データに対し1つまたは複数のデータセットに関する少なくとも1つの識別信号が割り当てられて、該識別信号がデータ受信側へ伝送され、
該識別信号には、送信されるデータ内の少なくとも1つのデータセットとのリンクに関する情報が含まれていることを特徴とする、データ伝送方法。 In a data transmission method in a mobile radio network, for example in a method for transmitting text data and / or image data with and without voice,
At least one identification signal for one or more data sets is assigned to the data and the identification signal is transmitted to the data receiver;
The data transmission method, wherein the identification signal includes information related to a link with at least one data set in data to be transmitted.
1つまたは複数の識別されたデータセット(7)に対し完全にまたは部分的に受信準備が完了していることの承認または拒否を選択する選択スイッチ(25)が設けられていることを特徴とする移動通信装置。 Mobile communication device (5; 6) for carrying out the method according to any one of claims 1 to 24,
A selection switch (25) is provided for selecting acceptance or rejection of complete or partial readiness for one or more identified data sets (7). Mobile communication device.
該記憶媒体上にプログラムが格納されており、該プログラムがコンピュータのメモリにロードされると該プログラムによってコンピュータは、移動無線ネットワークにおけるデータ伝送において伝送すべきデータに対し、1つまたは複数のデータセット(7)に関する少なくとも1つの識別信号を割り当て、該識別信号をデータ受信側(4)へ伝送し、
該識別信号には、送信されるデータ内の少なくとも1つのデータセットとのリンクに関する情報が含まれていることを特徴とする、コンピュータ読み取り可能な記憶媒体。 In a computer readable storage medium,
Are stored programs onto the storage medium, when the program is loaded into the memory of the computer is a computer by the program for the data to be transmitted in the data transmission in a mobile radio network, one or more data sets allocating at least one identification signal directed to (7), and transmits the identification signal data receiving side to (4),
A computer-readable storage medium , wherein the identification signal includes information relating to a link with at least one data set in transmitted data .
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP01101057 | 2001-01-18 | ||
EP01101057.6 | 2001-01-18 | ||
EP01102229.0 | 2001-01-31 | ||
EP01102229 | 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 (en) | 2001-01-18 | 2001-12-12 | Method and mobile communication device for data transmission in a mobile radio network |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2009105931A JP2009105931A (en) | 2009-05-14 |
JP5006864B2 true JP5006864B2 (en) | 2012-08-22 |
Family
ID=27224113
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002558717A Expired - Fee Related JP4358511B2 (en) | 2001-01-18 | 2001-12-12 | Method and mobile communication device for data transmission in a mobile radio network |
JP2008319719A Expired - Lifetime JP5006864B2 (en) | 2001-01-18 | 2008-12-16 | Method and mobile communication device for data transmission in a mobile radio network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002558717A Expired - Fee Related JP4358511B2 (en) | 2001-01-18 | 2001-12-12 | Method and mobile communication device for data transmission in a mobile radio network |
Country Status (3)
Country | Link |
---|---|
US (1) | US8099081B2 (en) |
JP (2) | JP4358511B2 (en) |
WO (1) | WO2002058359A1 (en) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10149721A1 (en) | 2001-10-09 | 2003-04-10 | Siemens Ag | Data transmission involves transport protocol being used by external application and additional signaling in the transport protocol being used to connect to external user application |
DE10225425A1 (en) | 2002-06-07 | 2003-12-18 | Siemens Ag | Mobile phone network data transfer method, especially for transfer of multimedia messages, whereby message data is subject to data type and format conversion according to the receiver profile |
DE10230897A1 (en) * | 2002-07-09 | 2004-01-29 | Siemens Ag | Messaging method and system |
DE10235470B4 (en) * | 2002-08-02 | 2005-10-06 | Siemens Ag | Method, subscriber device and radio communication system for transmitting user data messages |
EP1387539A1 (en) * | 2002-08-02 | 2004-02-04 | Siemens Aktiengesellschaft | Method and system for blocking unsolicited messages |
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 (en) * | 2002-11-20 | 2005-01-14 | Cegetel | METHOD AND MODULAR DEVICE FOR TRACING A MULTIMEDIA MESSAGE THROUGH A TELECOMMUNICATIONS NETWORK |
US20040176114A1 (en) * | 2003-03-06 | 2004-09-09 | Northcutt John W. | Multimedia and text messaging with speech-to-text assistance |
KR100517988B1 (en) * | 2003-04-16 | 2005-09-30 | 엘지전자 주식회사 | Method for receiving sms of gsm |
DE10325889A1 (en) | 2003-06-06 | 2004-12-23 | Siemens Ag | Method of transmitting messages |
DE10353117B3 (en) * | 2003-11-12 | 2005-07-14 | Vodafone Holding Gmbh | Method for transmitting data to a mobile terminal in mobile networks |
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 (en) * | 2004-10-05 | 2011-07-11 | 엘지전자 주식회사 | Message transmission method using file of mobile communication terminal |
ATE437505T1 (en) * | 2004-11-02 | 2009-08-15 | Nokia Corp | INFORMING A RECIPIENT FACILITY OF MESSAGE CONTENT CHARACTERISTICS |
KR101155335B1 (en) * | 2005-01-07 | 2012-06-11 | 엘지전자 주식회사 | Multimedia message service operating method for mobile communication terminal |
KR100764787B1 (en) * | 2005-09-14 | 2007-10-11 | 엘지전자 주식회사 | A method and a mobile terminal for sending/receiving active contents |
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 (en) | 2011-04-13 | 2013-08-28 | 青岛海信移动通信技术股份有限公司 | Multimedia message service (MMS) information resolution method and equipment |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07175710A (en) * | 1993-12-20 | 1995-07-14 | Canon Inc | Data managing method and device therefor |
WO1997022936A1 (en) * | 1995-12-19 | 1997-06-26 | 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 |
FI108982B (en) | 1998-06-15 | 2002-04-30 | Nokia Corp | Message service in a wireless communication system |
US20010012286A1 (en) * | 1999-01-29 | 2001-08-09 | Emmanuel L. Huna | Method and apparatus for computer alert of device independent messages |
ATE302517T1 (en) | 1999-04-19 | 2005-09-15 | Nokia Corp | MESSAGE DELIVERY METHOD |
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 |
FI111314B (en) | 1999-11-05 | 2003-06-30 | Nokia Corp | Multimedia messaging service |
FI111780B (en) * | 1999-12-23 | 2003-09-15 | Nokia Corp | The messaging service |
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 |
-
2001
- 2001-12-12 JP JP2002558717A patent/JP4358511B2/en not_active Expired - Fee Related
- 2001-12-12 US US10/466,749 patent/US8099081B2/en not_active Expired - Fee Related
- 2001-12-12 WO PCT/EP2001/014617 patent/WO2002058359A1/en active Application Filing
-
2008
- 2008-12-16 JP JP2008319719A patent/JP5006864B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
US8099081B2 (en) | 2012-01-17 |
US20040097248A1 (en) | 2004-05-20 |
WO2002058359A1 (en) | 2002-07-25 |
JP4358511B2 (en) | 2009-11-04 |
JP2009105931A (en) | 2009-05-14 |
JP2004517587A (en) | 2004-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5006864B2 (en) | Method and mobile communication device for data transmission in a mobile radio network | |
EP1599979B1 (en) | Message management | |
US8243890B2 (en) | All-HTTP multimedia messaging | |
US8645470B2 (en) | System, method and computer program product for the delivery of media content | |
EP1075750B1 (en) | A method and apparatus for processing electronic mail | |
US20020087549A1 (en) | Data transmission | |
JP5743422B2 (en) | MMS message transmission method with conversion of file type and / or file format, and subscriber terminal device | |
US20030086438A1 (en) | Method for accessing messages, and associated apparatuses and software programs | |
CN103152243A (en) | Multimedia messaging method and system | |
US20090036094A1 (en) | Accounting of data transmission costs in a mobile radio network | |
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 | |
EP1751999A1 (en) | System and method of interworking messages between mobile communication terminals | |
US8300628B2 (en) | Method and system for transmitting supplementary data, and communication terminal | |
WO2004045233A1 (en) | A method for transmitting multimedia message between different multimedia message center | |
US20030081555A1 (en) | Method, apparatus and software program for extending the flow of information when transmitting a message | |
CN100546300C (en) | The stream transmission of media content in the Multimedia Message sending and receiving service | |
CN101047668B (en) | Extend information transmitting method | |
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 (en) | The method and apparatus that is used for transfer of data | |
JP5011208B2 (en) | Mail processing system and communication terminal device |
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 |