JP2008508825A - 特定用途向け登録データまたは登録解除データの送信方法、そのための、システム、サーバ、通信端末 - Google Patents

Abstract

通信端末（４０４）とサーバとを含む通信サーバを開示する。上記通信端末は、特定用途向け登録・登録解除データ（４１２）を上記サーバに送信する。上記データは、上記通信端末に導入されている、または、導入されていないアプリケーションに特有であり、上記サーバは、送信された特定用途向け登録または登録解除データに応じて制御動作を行う。

Description

発明の詳細な説明

本発明は、通信システム、通信システムの制御方法、サーバ、サーバの動作方法、通信端末、および、通信端末の動作方法に関するものである。

ＧＳＭ（Global System for Mobile Communications）規格に基づいた移動無線通信システムにより、音声通信リンクだけでなく、ＳＭＳ（ショートメッセージサービス）を用いて、１６０文字までの長さのテキストメッセージを送受信することができる。

この簡単で一般的に支持されている通信サービスに続くものが、例えば、［１］および［２］に記載されたＭＭＳ（マルチメディアメッセージングサービス）である。

ＭＭＳは、マルチメディアコンテンツを有するメッセージを移動しながら送受信できる通信サービスである。ＭＭＳによって送信されるメッセージを、以下、マルチメディアメッセージ（ＭＭ）と記載する。

ＳＭＳとは対照的に、送信されるＭＭＳメッセージの内容のテキストの長さは、１６０文字に制限されていない。

マルチメディアメッセージは、複数のマルチメディア要素（つまり、マルチメディアファイル、異なるファイルタイプ（例えばオーディオファイルまたは静止画像ファイル）、異なるファイル形式（例えば静止画像ファイルの場合、ＧＩＦまたはＪＰＥＧ））を有していてもよい。

ＭＭＳはまた、固定された時間および／または空間的な順序を有するマルチメディアを使った比較的小さなプレゼンテーションを送信できる。

ＧＳＭ通信システム（つまり、ＧＳＭ規格に基づいた移動無線通信システム）のオペレータ（operators）の要求によって、ＭＭＳメッセージクラスは、例えば［３］に記載されているように、近い将来市場に導入されるＭＭＳのバージョン１．２用に規定されてきた。

マルチメディアメッセージが含んでいるデータの最大量は、特定のＭＭＳメッセージクラスにおけるマルチメディアメッセージ毎に固定されている。さらに、マルチメディア要素に用いられる、上記ファイルタイプおよびファイル形式は、マルチメディアメッセージがこれらのマルチメディア要素を含んでもよいように固定されている。

ファイル形式が、通常、［４］に記載されているＭＩＭＥ（Multi Purpose Intermail Extensions）内容種別によって指定される。

ＪＡＶＡ（登録商標）コミュニティ、特にＪＳＲ‐２０５Ｅｘｐｅｒｔ Ｇｒｏｕｐ（参照：例えば、http://www.jcp.org/en/home/index）の主導で、ＭＭＳに用いられる通信プロトコルを拡大するために、３ＧＰＰ（第３世代パートナーシッププロジェクト）において表題「アプリケーションアドレス指定スキーマ」を掲げて作業を行ってきた。これにより、ＭＭＳはアプリケーション（つまり、ソフトウェアアプリケーション）によって搬送媒体（transport medium）（キャリア）として用いられる。つまりアプリケーション内で送信されるファイルおよびデータを、ＭＭＳによって送信することができる。

これにより、推定では、データがＭＭＳによって送信されるアプリケーションを、移動無線ネットワークのネットワーク要素と移動体通信端末とに導入できるようになるだろう。

アプリケーション内でＭＭＳによってデータを送信できるように、アプリケーションのアドレス指定は、ＭＭＳの場合推定では可能になるだろう。つまり、アプリケーションとしてアドレス指定されたアプリケーションアドレスおよび／またはアプリケーションを識別するアプリケーション識別子、の命令によって、送信側から上記アドレス指定または識別されたアプリケーションに、マルチメディアメッセージを送信できる。

この場合にはすぐに、これまでＭＭＳによって送信できなかったファイルタイプまたはファイル形式を有するファイルが、ＭＭＳによって推定では送信されるだろう。なぜなら、推定では、移動体通信端末に導入される多数のアプリケーションが、特定用途向けＭＩＭＥ内容種別のデータを受信および／または送信するからである。

通信端末に導入されたアプリケーションによって用いられるが、「通常」、通信端末によってサポートされない（つまり、アプリケーションがこの通信端末に導入されていない場合は用いられない）ファイルタイプおよびファイル形式を有する多数のファイルが、結果的に、推定では、ＭＭＳによって送信されるだろう。

上記ＭＭＳ規格における従来のＭＭＳ継電器／サーバは、送信されるマルチメディアメッセージが、通信端末によって用いられる（つまり処理される、また例えば、通信端末の画面に表示される）ファイルタイプまたはファイル形式を有するファイルを含んだマルチメディアメッセージであるかどうかを、識別することができない。あるいは、上記ＭＭＳ継電器／サーバは、上記マルチメディアメッセージが輸送コンテナとして用いられるかどうか、および、具体的には通信端末に導入されたアプリケーションを対象とし、このアプリケーションを用いてのみ通信端末によって処理される、ファイルタイプおよび／またはファイル形式を有するファイルを含んでいるかどうかを、識別することができない。

特に、マルチメディアメッセージの内容が通信端末によって処理されないと仮定した場合、ＭＭＳ継電器／サーバは、上記ＭＭＳ継電器／サーバが通信端末について知っている情報に基づいたいわゆる内容適合処理中に、マルチメディアメッセージの内容を削除することができる。このことは、上記内容が、少なくとも１つのこの通信端末に導入されたアプリケーションによって処理される場合でもいえる。

通信端末が特定のファイルタイプのファイルを処理できないという情報は、上記通信端末のプロファイルであるいわゆるＵＡ Ｐｒｏｆ（ユーザエージェントプロファイル）において、ＭＭＳ継電器／サーバに知られており、マルチメディアメッセージの内容を通信端末の機能および特性に適合するという上記ＭＭＳ継電器／サーバの能力の一部として、上記ＭＭＳ継電器／サーバは、マルチメディアメッセージの中のこのファイルタイプのファイルを削除できるだろう。なぜなら、ＭＭＳ継電器／サーバは、これらの内容を処理できるアプリケーションがこの通信端末に導入されることを知らないからである。

これにより、著しい質の低下およびデータの損失を招いてしまう。

このＭＭＳ継電器／サーバの動作は、特に、通信端末のユーザがマルチメディアメッセージの送信にかかる費用を負担する場合に、不都合である。なぜなら、例えば、上記ユーザは、搬送媒体としてＭＭＳを用いる付加価値サービスプロバイダ（ＶＡＳＰ）への加入者だからである。

現在のところ、多数のＭＭＳプロバイダは、内容適合機能をまだ運用していない。しかしこのことは、近い将来、推定ではＭＭＳバージョン１．２を導入することにより、変化するだろう。

ＭＭＳ携帯電話とＭＭＳサーバとの相互作用のための最小限の要求事項およびガイドラインについては、文献［３］に詳述されている。

ＭＩＭＥ（多目的インターネットメール拡張）メッセージの構造を記載するために用いられる様々なヘッダについては、［４］に詳述されている。

ＵＡ‐Ｐｒｏｆ（ユーザエージェントプロファイル）については、［５］に詳述されている。通信端末（例えば、移動体通信端末）の特性に関する情報の信号を通信システムのサーバに送ることができるように、ＵＡ‐Ｐｒｏｆは、ＷＡＰ（無線アプリケーションプロトコル）フォーラムによって規格化されている。このようにして、確実に、移動無線システムにおける移動体通信端末（つまり、移動無線通信端末）の上記特性を、ネットワーク端末において知ることができる。元々インターネットのモバイルブラウザ用に開発されたＵＡ‐Ｐｒｏｆは、今やさらに、他の移動体通信サービス、つまり移動無線通信サービス（例えばＭＭＳ）に用いられる。

このＵＡ‐Ｐｒｏｆ規格は、今やさらに、ＯＭＡ（オープンモバイルアライアンス）によって開発されている。

さらに、ＵＡ‐Ｐｒｏｆを、通信システムにおける他の構成要素の他の特性の信号をサーバに送信するために用いることもできる（例えば、サーバと通信端末とを連結するＷＡＰゲートウェイ）。また、上記ゲートウェイは、サーバと通信端末との間で転送されるデータを操作し、このプロセスにおいて上記データを変えることができる。

このために、上記従来技術では、いわゆる結果として生じたプロファイル（resultant profile）がサーバに送信される。しかし、サーバは、結果として生じたプロファイルに含まれた情報が他の構成要素または通信端末の特性を指定しているのかどうかを知らないが、明らかに（clearly）、通信端末とサーバとの間の送信連鎖（transmission chain）の、指定された全ての特性が、通信端末の特性であると考えられ、これにより、上記送信された結果として生じたプロファイルは、通信端末のプロファイルとして解釈されるだろう。

文献［６］は、ＸＭＬ（拡張可能なマーク付け言語）について記載している。

［７］は、端末とネットワークユニットとの間のＭＭＳプロトコルデータユニット（ＰＤＵ）の交換について記載している。

文献［８］は、情報オブジェクトに用いられる言語を示すことが望ましい状況において用いるための言語タグについて記載している。

［９］は、３ＧＰＰに関する文献である。パケット交換ストリーミングサービス（ＰＳＳ）用に、プロトコルおよびコーデックが指定される。

文献［１０］は、インテリジェントトランスコーディング（intelligent transcoding）（つまり、２つのネットワーク要素間のマルチメディアデータの変換）のための方法および装置を開示している。トランスコーディング情報は、格納されるとともに、送信される。

［１１］は、通信リンクによって情報をクライアントに送信するための装置および方法を開示している。上記情報は、クライアントと通信リンクとの特性に基づいてフォーマットに変換され、このフォーマットを用いて送信される。

文献［１２］は、特定の内容を有するメッセージを端末に送信する方法を開示している。ここで、特定のアプリケーションサービスセンターが、ショートメッセージを用いて、メッセージの性質（nature）を端末に通知し、上記特定のアプリケーションサービスセンターは、続いてパスワードを用いたアクセスに対する、端末の反応に応じて、メッセージを端末または例えばウェブサイトに送信する。

［１３］は、コード化された静止画像の信号を端末に供給するための方法を開示している。通信システムのネットワーク要素が、上記信号を受信し、少なくとも部分的に変換し、端末に送信する。

文献［１４］は、通信システムについて記載している。クライアントユニットがそのデータ処理機能（例えば、クライアントユニット表示装置の特性、または、スピーカーまたは一般的には処理可能なデータフォーマットの他の可能な特性）をデータフォーマッティングユニット（data formatting unit）に転送する。マルチメディアデータは、クライアント特性に関して、上記フォーマッティングユニットによって、クライアント特定に変換され、次に、各クライアントユニットに送信される。

本発明の目的は、通信端末に導入されたアプリケーションの搬送媒体としてＭＭＳを使用できるようにすることである。

この目的を、独立特許請求項の特徴部分を有する、通信システムの制御方法、サーバ、サーバの動作方法、通信端末、および、通信端末の動作方法によって解決する。

通信端末とサーバとを備えた通信システムを提供する。上記通信端末は、上記通信端末に導入されたまたは導入されていないアプリケーションに特有の特定用途向け登録データまたは登録解除データを上記サーバに送信するように構成されている信号装置を備えている。上記サーバは、送信された上記特定用途向け登録データまたは登録解除データに応じて制御動作を実行するように構成されている制御装置を備えている。

さらに、上記通信システムに基づいて、通信システムの制御方法、サーバ、サーバの動作方法、通信端末、および、通信端末の動作方法を提供する。

本発明の基本的な一概念は、明らかに、通信端末が、上記通信端末に導入されているアプリケーションをサーバにおいて登録している、または、上記通信端末に導入されていないアプリケーションをサーバにおいて登録しない、ということである。

本明細書では、アプリケーションとは、通信端末に導入されたソフトウェアアプリケーション（例えば、複数のプレーヤーがゲームを楽しめるようにデータを送信するゲームアプリケーション、または例えば、命令を安全に実行できるバンキングアプリケーション）のことである。

本発明の好ましい複数の形態については、従属請求項に記載する。通信システムに関して記載した本発明の他の複数の形態は、同じ意味で、通信システムの制御方法、サーバ、サーバの動作方法、通信端末、および、通信端末の動作方法に適用できる。

上記サーバは、上記通信端末にメッセージを送信するように構成されている送信装置と、上記通信端末に送信されるメッセージを変換するように構成されている変換装置とを備えており、上記制御動作は、上記サーバの送信装置によって上記通信端末に送信されるメッセージの上記変換装置による変換を活動化または非活動化することが好ましい。

したがって、上記サーバは、明らかに、上記変換装置による変換の活動化または非活動化に影響を与えるように構成されている制御ユニットを備えていることが好ましい。したがって、「制御動作」という文言は、例えば、上記変換装置による、上記サーバの上記送信装置によって上記通信端末に送信されるメッセージの変換を活動化または非活動化することであると理解すべきである。

メッセージの変換とは、例えば、メッセージの内容適合（例えば、ＭＭＳの内容適合、メッセージに含まれたファイルのファイルタイプへの変更、または、メッセージに含まれたファイルのファイル形式への変更）である。

上記通信端末は、明らかに、上記通信端末に送信されるメッセージを変換する必要がないサーバに、信号を送信する。

上記制御動作は、上記制御動作は、さらに、上記サーバの送信装置によって上記通信端末に送信されるいずれのメッセージを上記変換装置によって（部分的にまたは全体的に）変換する必要があるかを決定することを含んでいることが好ましい。

上記通信端末は、どのメッセージ（例えば、１つの特定の送信側から送信された全てのメッセージ、特定のファイルタイプおよび／またはファイル形式のファイルを含んだ全てのメッセージ、または、特定の時間で、または、特定の時間窓内で送信される全てのメッセージ）を変換する必要があるかという信号を送信できる。

特に、アプリケーションの登録または登録解除が、上記通信端末に送信されるメッセージを変換する必要がない、または、上記メッセージを変換する必要があるという信号を送信すること、および／または、上記通信端末に送信されるどのメッセージを部分的にまたは全体的に変換する必要があるのかという信号を送信することを、含んでいてもよい。

上記変換装置は、マルチメディア送信プロトコルを用いて上記送信装置を介して上記通信端末に送信されるメッセージを変換するように構成されていることが好ましい。

上記信号装置は、マルチメディア送信プロトコルを用いて上記特定用途向け登録データまたは登録解除データを上記サーバに送信するように構成されていることが好ましい。

上記マルチメディア送信プロトコルは、ＭＭＳ送信プロトコルであることが好ましい。

本発明の基本的な他の概念は、ＭＭＳによって上記アプリケーションを登録および登録解除することである。

本発明をＭＭＳに用いる場合、ＭＭＳ継電器／サーバに、例えば、ＭＭＳを搬送媒体として用いるアプリケーションが通信端末に導入されていることを知らせることができる。これにより、特に、上記通信端末に送信されるメッセージの望ましくない内容適合（例えば、ＭＭＳ継電器／サーバにおける、送信されるメッセージに含まれたファイルの望ましくない削除、および／または、送信されるメッセージに含まれたファイルのファイルタイプおよび／またはファイル形式の望ましくない変換）を、上記ＭＭＳ継電器／サーバによって、一時的または永久的に回避できる。

この場合、上記サーバはＭＭＳ継電器／サーバであり、マルチメディアメッセージのメッセージヘッダ（特に、具体的にはアプリケーションがマルチメディアメッセージにおいてアドレス指定された場合に挿入されているメッセージヘッダフィールド）に基づいて、上記通信端末に導入されているアプリケーションを示すデータを含むマルチメディアメッセージを識別してもよいし、別々に操作してもよい。例えば、上記サーバは、上記したように、上記メッセージを変換しないことを決定することができる。

同様に、上記通信端末に導入されているＭＭＳユーザエージェント（上記ＭＭＳユーザエージェントは、マルチメディアメッセージのメッセージヘッダ（特に、具体的にはアプリケーションがマルチメディアメッセージにアドレス指定された場合に挿入されているメッセージヘッダフィールド）に基づいてＭＭＳを利用できる、上記通信端末に導入されたソフトウェアプログラムである）が、上記アプリケーションを識別でき、上記ユーザに（例えばグラフィックス表示によって）提供するのではなく、アプリケーションに直接送信することができる。

あるいは、または、それに加えて、上記ＭＭＳ継電器／サーバは、マルチメディアメッセージのメッセージヘッダにおいて、少なくとも１つの新しいメッセージヘッダフィールドによって、マルチメディアメッセージをユーザに（例えば図表で）提供するのではなく、上記アプリケーションに直接送信する必要があるということを、ＭＭＳユーザエージェントに示すことができる。

上記信号装置は、上記特定用途向け登録データまたは登録解除データを上記通信端末のプロファイルとして送信するように構成されていることが好ましい。

したがって、上記通信端末は、自らが特定のタイプのメッセージを処理できることを示すプロファイルを送信する。なぜなら、上記通信端末には、アプリケーションが導入されているからである。したがって、例えば、上記サーバは、これらのメッセージを変換する必要がない。なぜなら、変換後、上記メッセージをアプリケーションによって用いることができず、これによりデータが破損してしまうからである。

上記プロファイルは、［５］に記載したように、ＵＡ‐Ｐｒｏｆ規格に従うことが好ましい。

本発明に基づいた他の概念として、上記アプリケーションが導入されるユニットにおいて、通信端末、または、通信システムの他のユニット（例えば、ＭＭＳ継電器／サーバ）、に導入されたアプリケーションの登録が挙げられる。

以下に記載した一形態では、この登録プロセスは、アプリケーションが導入されたユニットに、アプリケーションのアプリケーション識別および／またはアプリケーションアドレスを通知すること、（または、アプリケーションが導入されたユニットと、上記アプリケーションとの交渉）、および、場合によっては、アプリケーションが導入されるユニットに、アプリケーションの他のパラメータの値で、他の情報を転送することを含んでいる。例えば、上記アプリケーションが、ＭＭＳを介して（ペイロード）データを送信することを望むか、または、ユニットがＭＭＳを介して受信された（ペイロード）データをアプリケーションに送信することを望むと、上記他の情報は、アプリケーションと、上記アプリケーションが導入されるユニットとの間の双方向のデータ交換を制御するために用いられる。

本発明の模式的な実施形態について、以下に詳述し、図面に示す。

図１は、本発明の模式的な一実施形態に関する通信システムを示す図である。

図２は、本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。

図３は、本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。

図４は、本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。

図１は、本発明の模式的な一実施形態に関する通信システム１００を示している。

通信システム１００は、３ＧＰＰ内で指定されたＭＭＳ通信ネットワークアーキテクチャに基づいて設計されている。

第１のＭＭＳユーザエージェント１０１は、第１のＭＭＳ継電器／サーバ１０２および第２のＭＭＳ継電器／サーバ１０３を介して、第２のＭＭＳユーザエージェント１０４に連結されている。

ＭＭＳユーザエージェント１０１、１０４は、例えば、移動無線加入者装置、上記移動無線加入者装置に接続されている装置（例えばラップトップ）、または、他のいくつかの通信端末に備えられた、ソフトウェアプログラムであり、ＭＭＳを供給する（つまり、ＭＭＳを使用できるようにする）。

上記第１のＭＭＳユーザエージェント１０１は、ＭＭ１と示した第１のインターフェース１０５を介して、第１のＭＭＳ継電器／サーバ１０２に連結されている。

上記第２のＭＭＳユーザエージェント１０４は、同様にＭＭ１と示した第２のインターフェース１０６を介して、第２のＭＭＳ継電器／サーバ１０３に連結されている。

上記第１のＭＭＳ継電器／サーバ１０２は、ＭＭ４で示した第３のインターフェース１０７を介して、第２のＭＭＳ継電器／サーバ１０３に連結されている。

上記第１のＭＭＳ継電器／サーバ１０２は、第１のＭＭＳサービスプロバイダ（ＭＭＳプロバイダ）の第１の責任領域（responsibility area）（マルチメディアメッセージングサービス環境、ＭＭＳＥ）１０８に位置しており、上記第２のＭＭＳ継電器／サーバ１０３は、第２のＭＭＳサービスプロバイダの第２の責任領域１０９に位置している。

ＭＭＳ継電器／サーバ１０２、１０４は、ＭＭＳサービスプロバイダの責任領域１０８、１０９において通信サービスＭＭＳを上記ＭＭＳユーザエージェントに供給するネットワーク要素である。上記ＭＭＳユーザエージェントは、責任領域１０８、１０９に位置している（つまり、上記責任領域に位置する通信端末に備えられている）。

上記第１のＭＭＳユーザエージェント１０１は、第１の責任領域１０８に位置しており、上記第２のＭＭＳユーザエージェント１０４は、第２の責任領域１０９に位置している。

ＭＭＳ継電器／サーバ１０２、１０４は、マルチメディアメッセージの内容を通信端末の機能および特性に適合できる。このことは、内容適合と呼ばれる。

例えば、上記第１のＭＭＳ継電器／サーバ１０２は、１つのファイルタイプまたは１つのファイル形式のファイルを削除することができる。それは、このファイルを含んだマルチメディアメッセージを送信する通信端末がこのファイルタイプまたはこのファイル形式のファイルを処理できないという情報を、上記第１のＭＭＳ継電器／サーバが有している場合である。

内容適合の他の選択肢では、ＭＭＳ継電器／サーバ１０２、１０４が、上記通信端末に備えられた通信端末またはユーザエージェントに送信されるマルチメディアメッセージのファイルを変換する。つまり、通信端末によって処理されるファイルタイプおよびファイル形式を有するようにファイルを変える。この変換プロセスは、トランスコーディングとも呼ばれる。

本実施形態では、第１のＭＭＳユーザエージェント１０１を備えた通信端末の機能および特性に関する情報、および、第２のＭＭＳユーザエージェント１０４を備えた第２の通信端末の機能および特性に関する情報を、それぞれ、以下に記載するＵＡ Ｐｒｏｆ（ユーザエージェントプロファイル）規格に基づいて設計された通信端末の通信端末プロファイルとして、第１のＭＭＳ継電器／サーバ１０２および第２のＭＭＳ継電器／サーバ１０３に用いることができる。

他のサーバ１１１は、ＭＭ３と呼ばれる第４のインターフェース１１０を介して、第１のＭＭＳ継電器／サーバ１０２に連結されている。上記他のサーバ１１１は、例えば、電子メール通信サービス、ファックス通信サービス、または、ＵＭＳ（ユニファイドメッセージング）通信サービスを提供する、外部サーバである。

上記第１のＭＭＳ継電器／サーバ１０２の観点からすれば、上記第２のＭＭＳ継電器／サーバ１０３は、外部ＭＭＳサービスプロバイダによって動作される。

したがって、上記第２のインターフェース１０７を、外部ＭＭＳサービスプロバイダをリンクするための手段とすることができる。

ＨＬＲ（Home Location Register）１１３は、ＭＭ５と呼ばれる第５のインターフェース１１２を介して、第１のＭＭＳ継電器／サーバ１０２に連結されている。

上記ＨＬＲ１１３は、第１のＭＭＳ継電器／サーバ１０２を第１のＭＭＳユーザエージェント１０１と通信させる移動無線通信システムの一部である。つまり、第１のインターフェース１０５が移動無線通信システムによって供給される。

上記第１のＭＭＳユーザエージェント１０１は、移動無線通信システムにおける加入者装置において実行される。ここで、上記移動無線通信システムは、ＨＬＲ１１３を備えている。

上記移動無線通信システムは、例えば、ＧＳＭ規格またはＵＭＴＳ（Universal Mobile Telecommunications System）規格に基づいて設計されている。

第１のＭＭＳユーザエージェント１０１を実行し、具体化する（embodied）、通信端末のユーザの個々の利用者データは、ＨＬＲ１１３に格納される。このＨＬＲ１１３は、通常、移動無線通信システムの責任領域に配置されており、上記責任領域は、第１の責任領域１０８または第２の責任領域１０９と同じである必要はない。

１つ（または複数の）ＭＭＳユーザデータベース（またはベース）１１５が、ＭＭ６と呼ばれる第６のインターフェース１１４を介して、第１のＭＭＳ継電器／サーバ１０２に連結されている。

付加価値サービスプロバイダ（ＶＡＳＰ）の付加価値サービス（ＶＡＳ）サーバ１１７は、ＭＭ７で示した第７のインターフェース１１６を介して、第１のＭＭＳ継電器／サーバ１０２に連結されている。

付加価値サービス（ＶＡＳ）が、付加価値サービスサーバ１１７を介して、第１のＭＭＳユーザエージェント１０１のユーザに、および、場合によっては、第１のＭＭＳ継電器／サーバ１０２によって備えられたＭＭＳの他のユーザに、供給される。付加価値サービスは、通信リンクの単なる通信リンクの提供（例えば、株価の送信または電話番号情報）を越える通信サービスである。

ＭＭＳに対して料金を請求するための関連情報全体を集めて評価するために用いられる料金請求システム１１９が、ＭＭ８と呼ばれる第８のインターフェース１１８を介して、上記第１のＭＭＳ継電器／サーバ１０２に連結されている。

第１のＭＭＳ継電器／サーバ１０２の継電器要素１２１と、第１のＭＭＳ継電器／サーバ１０２のサーバ要素１２２とを連結している、第９のインターフェース１２０を、ＭＭ２と呼ぶ。

上記通信システム１００は、他のインターフェースを有していてもよい。

記号がＭＭ９、ＭＭ１０であるインターフェースが、今や標準化委員会において議論されている。

図２は、本発明の模式的な一実施形態に関するメッセージのフローチャート２００を示している。

図２に示したメッセージの流れは、図１を参照しながら上記したように配置および設計された、第１のＭＭＳユーザエージェント２０１と、第１のＭＭＳ継電器／サーバ２０２と、第２のＭＭＳ継電器／サーバ２０３と、第２のＭＭＳユーザエージェント２０４との間で生じる。

図２に示した上記メッセージの流れは、図１を参照しながら記載したように配置および設計された、第１のインターフェース２０５と、第２のインターフェース２０６と、第３のインターフェース２０７とを介して行われる。

上記メッセージのフローチャート２００は、上記メッセージの流れ、および、マルチメディアメッセージ２０８を送信している間のＭＭＳユーザエージェント２０１、２０４とＭＭＳ継電器／サーバ２０２、２０４との間のデータ交換を示している。メッセージのフローチャート２００に示したメッセージの流れは、例えば［２］に記載されているように、３ＧＰＰトランザクションフローチャート（3GPP transaction flowchart）に基づいて構成されている。

特に、上記メッセージの流れにしたがって送信されたメッセージは、［２］に規定されているような３ＧＰＰアブストラクトメッセージ（3GPP abstract messages）に基づいて構成されている。

図示したメッセージの流れにしたがって送信されたメッセージは、それぞれ、少なくとも１つのメッセージヘッダフィールド（情報要素）を備えている。ステップ２０９では、マルチメディアメッセージ２０８の送信側である上記第１のＭＭＳユーザエージェント２０１は、第１のインターフェース２０５を使用する。上記インターフェースは、例えば、ＭＭ１＿ｓｕｂｍｉｔ．ＲＥＱメッセージによってマルチメディアメッセージ２０８を第１のＭＭＳ継電器／サーバ２０２に送信するための電波インターフェースである。

ステップ２１０では、上記第１のＭＭＳ継電器／サーバ２０２は、ＭＭ１＿ｓｕｂｍｉｔ．ＲＥＳメッセージを介して、第１のＭＭＳユーザエージェント２０１からマルチメディアメッセージ２０８を正しく受信しているかを確認する。

ステップ２０９と同様に、ステップ２１１では、上記第１のＭＭＳ継電器／サーバ２０２から、ＭＭ４＿ｆｏｒｗａｒｄ．ＲＥＱメッセージを介して第２のＭＭＳ継電器／サーバ２０３に、および、第２のインターフェース２０６に、上記マルチメディアメッセージ２０８を送信し、ステップ２１２では、マルチメディアメッセージ２０８の正しい受信を、ＭＭ４＿ｆｏｒｗａｒｄ．ＲＥＳメッセージを介して第２のＭＭＳ継電器／サーバ２０３と第２のインターフェース２０６とによって確認する。

ステップ２１３では、マルチメディアメッセージ２０８の受信者である上記第２のＭＭＳユーザエージェント２０４は、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージと第３のインターフェース２０７を介して、マルチメディアメッセージ２０８がダウンロードに用いられるという情報を与えられる。

上記ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージは、ＵＲＩ（Uniform Resource Identifier）の形式で、第２のＭＭＳ継電器／サーバ２０３が属する責任領域（ＭＭＳＥ）の中のマルチメディアメッセージ２０８の記憶場所へのリファレンスを含んでいる。

ステップ２１４では、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＳメッセージを介した第２のＭＭＳユーザエージェント２０３と、第３のインターフェース２０７とによって、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージが正しく受信されていることを確認する。

ステップ２１５では、上記第２のＭＭＳユーザエージェント２０３は、ＭＭ１＿ｒｅｔｒｉｅｖｅ．ＲＥＱメッセージおよび第３のインターフェース２０７を使用して、第２のＭＭＳ継電器／サーバ２０３に供給されたマルチメディアメッセージ２０８を初めにダウンロードする。

ステップ２１６では、上記マルチメディアメッセージ２０８を、第２のＭＭＳ継電器／サーバ２０３から、ＭＭ１＿ｒｅｔｒｉｅｖｅ．ＲＥＳメッセージおよび第３のインターフェース２０７を介して、第２のＭＭＳユーザエージェント２０４に送信する。

ステップ２１７では、上記第２のＭＭＳユーザエージェント２０４は、ＭＭ１＿ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ．ＲＥＱメッセージ、および、ステップ２１６において供給されたマルチメディアメッセージ２０８が出力された（つまり、マルチメディアメッセージ２０８をダウンロードするための出力部に関する）第３のインターフェース２０７を介して、第２のＭＭＳ継電器／サーバ２０３に情報を与える。

他のメッセージを、ＭＭＳ規格に基づいて交換してもよい。

図３は、本発明の模式的な一実施形態に関するメッセージのフローチャート３００を示している。

図３に示したメッセージの流れは、通信端末３０１と、ゲートウェイコンピュータ３０２と、サーバ３０３との間で生じる。

例えば、上記通信端末３０１は、図１を参照しながら記載したように第１のＭＭＳユーザエージェント１０１が実行される移動無線通信システム中の、加入者装置である。

上記サーバ３０３は、例えば、図１を参照して記載した第１のＭＭＳ継電器／サーバ１０２である。

上記ゲートウェイコンピュータ３０２は、例えば、通信端末３０１とサーバ３０３との間でデータを送信するゲートウェイコンピュータである。このゲートウェイコンピュータは、例えば、図１を参照して記載してきた（図２の第３のインターフェース２０７に相当する）第１のインターフェース１０５の一部である。

例えば、上記ゲートウェイコンピュータ３０２は、無線アプリケーションプロトコル（ＷＡＰ）ゲートウェイコンピュータである。

コンピュータ端末（例えば、通信端末３０１）同士の特性および機能は、通常、互いに異なっている。例えば、通信端末の表示装置の特性は、表示サイズ、色の範囲、および、表示装置の解像度、または、通信端末の機能に関して、異なっていてもよい。これにより、特定のファイルタイプおよび／またはファイル形式のファイルを表示および／または処理することができる。

図３に示したメッセージの流れは、通信端末３０１の機能および特性に関する情報をサーバ３０３に送信するために用いられる。

このことは、ＷＡＰ（無線アプリケーションプロトコル）フォーラムによって規格化されたＵＡ Ｐｒｏｆ（ユーザエージェントプロファイル）に基づいて構成された通信端末プロファイルを用いて行われる。

さらに、このメッセージの流れは、サーバ３０３にゲートウェイ３０２の機能に関する信号を送るためにも用いられる。上記ゲートウェイは、サーバ３０３と通信端末３０１との間で転送されるデータを操作し、上記データを変えることもできる。

以下では、図３において、通信端末３０１の現在の通信端末プロファイルの信号がどのようにサーバ３０３に送信されるかについて記載する。

ステップ３０４では、例えば、通信端末３０１をサーバ３０３によって登録している間または通信端末３０１とサーバ３０３との間の通信リンクを構成するとき、通信端末３０１の基本プロファイルＢＰまたは通信端末３０１の基本プロファイルＢＰへのリファレンスを、第１のメッセージ３１３を介してゲートウェイコンピュータ３０２に送信する。

基本プロファイルＢＰによって指定された通信端末３０１の特性および／または機能が、例えば他のハードウェアが接続されていることにより変更または拡張した場合、通信端末３０１のための第１の差プロファイル（difference profile）ＤＰ１または通信端末３０１の上記第１の差プロファイルＤＰ１へのリファレンスを、ステップ３０４における第１のメッセージ３１３を介してゲートウェイコンピュータ３０２に、さらに、基本プロファイルＢＰに送信することにより、第１のメッセージ３１３を更新する。

この例は、第１の差プロファイルＤＰ１を送信すると仮定している。

ステップ３０５では、基本プロファイルＢＰおよび第１の差プロファイルＤＰ１を、ゲートウェイコンピュータ３０２を介して一時的に格納および評価できる。上記ゲートウェイコンピュータ３０２は、ゲートウェイコンピュータ３０２自体によって生成された第２の差プロファイルＤＰ２を、基本プロファイルＢＰおよび第１の差プロファイルＤＰ１に加えることができる。このことは、例えば、ゲートウェイコンピュータ３０２が、基本プロファイルＢＰおよび第１の差プロファイルＤＰ１によって指定された通信端末３０１の特性および機能とは異なっている場合、または、上記特性および機能を補完する、特定の特性および／または機能を有している場合に行われる。

この例は、第２の差プロファイルＤＰ２を生成すると仮定している。

ステップ３０６では、基本プロファイルＢＰ、第１の差プロファイルＤＰ１、および、第２の差プロファイルＤＰ２を、第２のメッセージ３１４を介して、サーバ３０３に送信する。

ステップ３０７では、サーバ３０３は、基本プロファイルＢＰ、第１の差プロファイルＤＰ１、および、第２の差プロファイルＤＰ２を基礎として使用し、通信端末３０１の結果として生じたプロファイルを生成する。ステップ３０４またはステップ３０６において、プロファイ自体の代わりに（つまり、第１の基本プロファイルＢＰまたは第１の差プロファイルＤＰ１または第２の差プロファイルＤＰ２の代わりに）上記プロファイルへのリファレンスのみを送信した場合、ステップ３０５においてゲートウェイコンピュータ３０２によって処理する前、および／または、サーバ３０３によって処理する３０７前にデリファレンスすることが必要である場合もある。つまり、参照されたプロファイルを、上記プロファイルが格納されている他のサーバからダウンロードする必要がある場合もある。

本実施形態ではＷＡＰと互換性のある通信端末３０１の個々の特性と、場合によっては、ゲートウェイ３０２および／または他の全てのネットワーク要素の、補助機能とを指定する結果として生じたプロファイルは、現在の通信端末プロファイルを示し、サーバ３０３によって管理されている。

通信リンクまたは通信セッションが存在している間、データ要求メッセージを送信することによって、データのダウンロードを通信端末３０１を介して開始できる。ステップ３０８では、上記通信端末３０１は、このようなデータ要求メッセージ３１５をゲートウェイコンピュータ３０２に送信する。この例は、通信端末３０１の特性または機能がステップ３０４によって変化したと仮定している。したがって、上記データ要求メッセージ３１５は、更新された基本プロファイルＢＰおよび第３の差プロファイルＤＰ３をゲートウェイコンピュータ３０２に送信するために用いられる。続いて実行されるステップ３１０、３１１、３１２は、ステップ３０５、３０６、３０７と同様に実行される。

通信端末３０１の特性および機能がステップ３０４によって変化しなかった場合、ステップ３０８では、更新された基本プロファイルＢＰおよび第３の差プロファイルＤＰ３は送信されず、ステップ３０８に続くステップでは、ステップ３０４〜３０７において送信され、ゲートウェイコンピュータ３０２および／またはサーバ３０３に格納された通信端末３０１のプロファイル（例えば、すでに決定された結果として生じたプロファイル）が用いられる。ゲートウェイコンピュータ３０２に格納されたプロファイルがステップ３０４によって同様に変化しない場合、サーバ３０３は、ステップ３０４〜３０７において送信された通信端末のプロファイル３０１を使用する。

したがって、基本プロファイルおよび、所望の全ての数の差プロファイルを含んだ結果として生じたプロファイルは、図３を参照しながら説明した上記手順で生成される。この場合、通信端末３０１とゲートウェイコンピュータ３０２との間で、基本プロファイルおよび全ての差プロファイルへのリファレンスの形状で、データも送信できる。さらに、現在の通信端末プロファイルの電波インターフェースによって送信されるデータの量は低減される。これは、更新された基本プロファイルおよび／または差プロファイルが、通信端末３０１の特性および／または機能の変化後にのみ送信される必要があるからである。

［５］では、送信されたプロファイル（つまり、基本プロファイルおよび差プロファイル）は、メタ言語ＸＭＬ（拡張可能なマーク付け言語）に基づいて構成されている。これについては、例えば［６］に記載されている。

ＸＭＬに基づいたフォーマットは、プラットフォームおよびソフトウェアとは無関係な構造データの交換に非常に適している。このことは、製造者およびシステムが異なっている、プログラムとコンピュータとの間でのデータ転送に適している。

また、複数の構成要素を、１つの通信端末プロファイルによって指定できる。この場合、各構成要素は、値を有する複数の属性を有していてもよい。例えば、ハードウェア構成要素の属性は、例えば画面サイズ、色機能（color capability）、および、これらの値である。

図３に示したメッセージの流れに沿って送信された上記プロファイル（基本プロファイルＢＰ、および、差プロファイルＤＰ１、ＤＰ２、ＤＰ３）と、上記の結果として生じたプロファイルとは、例えば、［５］ではＵＡ‐Ｐｒｏｆ規格のＷＡＰフォーラムによって規定されているように、プロファイルの基本構造を示している表１のように、構成されている。

情報ブロックおよび個人情報項目は、プロファイル内で、いわゆるタグ（マーク）によって互いに示されている。

ＸＭＬに基づいた文書では、最も多くのタグが、開始命令および終了命令として対になって生じ、それらの間に囲まれたテキストの意味を示している。上記の囲まれたテキストは、それ自体、他のタグによって細分されていてもよい。これにより、例えば、１つの属性に対してパラメータのリストを形成することができる。ＸＭＬに基づいたファイルにおける属性に関する詳細は、常に、引用符（＜＞）で囲まれている。

このタイプの細分の利点は、構成要素および属性の全てを用い、自在に拡張できる点にある。さらに、これにより、ＵＡ‐Ｐｒｏｆ規格に基づいたプロファイルの構造を、所望のように拡張することができ、簡単なグラフィックス表示が実現される。

ステップ３０８において送信された上記データ要求メッセージ３１５は、例えば、図２を参照しながら記載したＭＭ１＿ｒｅｔｒｉｅｖｅ．ＲＥＱメッセージであり、ステップ２１５において送信される。

このメッセージは、トランスポートプロトコルレベルにおいて、例えば、ＭＭＳに用いられるトランスポートプロトコルＷＳＰ（ワイヤレスセッションプロトコル（wireless session protocol）におけるデータ要求命令「ＷＳＰ ＧＥＴ」、または、ＭＭＳに用いられるｈｔｔｐ（ハイパーテキスト転送プロトコル）トランスポートプロトコルのデータ要求命令「ｈｔｔｐ ＧＥＴ」によって、形成される。

本実施形態において、および、ステップ３０８に応じて、各データ要求命令は、基本プロファイルおよび１つまたは複数の差プロファイルを含んでいる。

図４は、本発明の模式的な一実施形態に関するメッセージのフローチャート４００を示している。

図４に示したメッセージの流れは、ＭＭＳ継電器／サーバ４０１と、ＭＭＳユーザエージェント４０２と、アプリケーション４０３との間で生じる。

上記ＭＭＳユーザエージェント４０２およびアプリケーション４０３は、通信端末４０４に導入されている。例えば、通信端末４０４は、移動無線通信システムにおける加入者装置である。

上記ＭＭＳ継電器／サーバは、例えば、図１を参照しながら記載した第１のＭＭＳ継電器／サーバ１０２と同様に、配置および構成されている。

上記ＭＭＳユーザエージェント４０２は、例えば、図１を参照しながら記載した第１のＭＭＳユーザエージェント１０１と同様に配置および構成されている。

上記メッセージの流れは、図１（または図２のそれぞれ）を参照しながら記載した第１のインターフェース１０５（または、第３のインターフェース２０７）、および、ＭＭＳユーザエージェント４０２とアプリケーション４０３との間のインターフェースを構成する第２のインターフェース４０６、と同様に構成された第１のインターフェース４０５を介して実行される。

ＭＭＳを搬送媒体として使用するために、通信端末または一般的にはＭＭＳユニットのアプリケーション（例えば、ＭＭＳ継電器／サーバ、または、ＶＡＳＰサーバ）を導入した後、ＭＭＳユニットは、上記アプリケーションのために、上記アプリケーションを識別するアプリケーション識別、および／または、上記アプリケーションをアドレス指定できるアプリケーションアドレスを割り当てる。あるいは、上記アプリケーションは、ＭＭＳユニットに、上記アプリケーションのアプリケーション識別、および／または、上記アプリケーションのアプリケーションアドレスの信号を送信する。

可能であれば、アプリケーションの参照に用いられる上記アプリケーション識別および／またはアプリケーションアドレス、特に、上記アプリケーションのアプリケーション識別および／または上記アプリケーションのアプリケーションアドレスを示すことによってマルチメディアメッセージを上記アプリケーションに送信するために用いられる、上記アプリケーション識別および／またはアプリケーションアドレスを、一意的に選択する。

一実施形態では、上記アプリケーションの一意のアプリケーション識別および／またはアプリケーションアドレスを、上記アプリケーションとＭＭＳユニットとの間で交渉する（negotiated）場合がある。

一実施形態では、上記アプリケーション識別および／またはアプリケーションアドレスは、階層的に細分されたＵＲＩ（Uniform Resource Identifier、記憶場所へのリファレンス）を含んでいる。これは、アドレス指定されたＭＭＳユニットによって、アプリケーション識別および／またはアプリケーションアドレスの自動解決に障害が生じてしまった場合に、例えば他のアプリケーションによって、第２の手動解決または自動解決を常に実現できるようにするためである。

他の実施形態では、上記アプリケーション識別および／またはアプリケーションアドレスは、階層的な細分において、少なくとも１つの特定の要素（element）（好ましくは、最後の１つまたは複数の要素）によって異なっている。これにより、例えば、同じアプリケーションの異なる実現値のアドレス指定を、上記特定の１つまたは複数の要素の解決によって実現できる。

本実施形態では、アプリケーション４０３は、ＭＭＳユニット（つまりこの場合はＭＭＳユーザエージェント４０２）に、上記アプリケーション４０３が知っている上記アプリケーション４０３のアプリケーション識別および／またはアプリケーションアドレスの信号を送信することが好ましい。なぜなら、このようにして、上記アプリケーション４０３にデータを送信するマルチメディアメッセージを通信端末４０４に送信する送信側が、アプリケーション４０３が知っているアプリケーション識別および／またはアプリケーションアドレスを使用することができ、ＭＭＳユニットによって上記アプリケーション４０３に割当てられた、または、ＭＭＳユニットおよびアプリケーション４０３によって交渉された、アプリケーション識別および／またはアプリケーションアドレスに関する情報を与える必要がないからである。

他の実施形態では、上記ＭＭＳユニットは、第１のインターフェース４０５におけるアプリケーションのアドレス指定に用いられる外部識別（つまり、第２のアプリケーション識別および／またはアプリケーションアドレス）を、第２のインターフェース４０６におけるアドレス指定に用いられる、内部で交渉されたアプリケーション識別および／またはアプリケーションアドレスに割当てることを、管理する。しかし、本実施形態は、上記の実施形態よりも複雑である。

ステップ４０７では、上記アプリケーション４０３がうまく通信端末４０４に導入されたと仮定する。

ステップ４０８では、上記アプリケーション４０３は、適切なメッセージによって、ＭＭＳユーザエージェント４０２に、上記メッセージに割当てられたアプリケーション識別、および／または、上記メッセージに割当てられたアプリケーションアドレスを通知する。

ステップ４０９、４１０は、任意に実行され、例えば、アプリケーション４０３および通信端末４０４に応じて、実行されたり、実行されなかったりする。

ステップ４０９では、上記ＭＭＳユーザエージェント４０２は、アプリケーション４０３に、他の情報を送信することを要求する。このアプリケーション４０３は、ステップ４１０では、ＭＭＳユーザエージェント４０２に送信される。

例えば、ステップ４１０では、（または、ステップ４０８でも）、上記アプリケーション４０３は、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージをＭＭＳユーザエージェント４０２によって受信した場合、ＭＭＳユーザエージェント４０２は、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージのメッセージヘッダフィールドの内容をアプリケーション４０３に送信する必要があるという情報か、または、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージの送信側アドレスと、ＭＭ１＿ｎｏｔｉｆｉｃａｔｉｏｎ．ＲＥＱメッセージの参照とを指定するか、または、上記ＭＭＳユーザエージェントがアプリケーション４０３内のＭＭ１＿ｓｕｂｍｉｔ．ＲＥＱメッセージを介してマルチメディアメッセージを送信する場合にＭＭＳユーザエージェント４０２がＭＭ１＿ｓｕｂｍｉｔ．ＲＥＱメッセージの送信通知（配達通知）を自動的に要求する情報を、ＭＭＳユーザエージェントに送信するという情報かを、ＭＭＳユーザエージェント４０２に送信できる。一般的には、上記アプリケーションが導入されているＭＭＳユニットの上記アプリケーションは、上記したようにステップ４１０において（または、ステップ４０８でも）他の情報の交換を用いて、（［２］に規定されているように、アプリケーションが、ＭＭＳユニットから３ＧＰＰアブストラクトメッセージの送信を開始した場合）上記アプリケーションがどのデータをどのフォーマットで送信することを意図しているか、または、（アプリケーションが、ＭＭＳユニットからの、［２］に規定されているように受信された３ＧＰＰアブストラクトメッセージのデータを受信した場合）上記アプリケーションがどのデータをどのフォーマットで受信することを意図しているかを、示すことができる。

上記アプリケーション４０３から上記ＭＭＳユーザエージェントに送信された他の情報は、アプリケーション４０３に関する情報を有するＵＡ Ｐｒｏｆ規格に基づいた差プロファイル（つまり、ステップ４１１においてＭＭＳ継電器／サーバ４０１に送信されるアプリケーション４０３の差プロファイル）をも含んでいてもよい。

アプリケーションの差プロファイルの送信は、ＭＭＳによってデータを送信する全てのアプリケーションが差プロファイルを形成する場合のみ、望ましくない内容適合の問題を克服する。したがって、送信された他の情報内のアプリケーションの差プロファイルを送信することは、好ましくない。

ステップ４１１、４１２は、上記実施形態に応じて、特にステップ４０９、４１０が実行されたかどうかに応じて、異なるように実行される。

一実施形態では、ＭＭＳユーザエージェント４０２は、ステップ４１２において形成されたメッセージを用いることにより、ステップ４１２において、ＭＭＳを搬送媒体として用いる新しいアプリケーション４０３が通信端末４０４に導入されているという情報をＭＭＳ継電器／サーバ４０１に与える。このことを、例えば、図３を参照しながら記載してきたように、アプリケーション４０３が通信端末４０４に導入された時間に応じて、基本プロファイルまたは差プロファイルによって行うことができる。

一実施形態では、ＭＭＳユーザエージェント４０２は、ステップ４１２における上記アプリケーション４０３のアプリケーション識別および／またはアプリケーションアドレスを、適切なメッセージによって、ＭＭＳ継電器／サーバ４０１に送信する。

一実施形態では、ＭＭＳユーザエージェント４０２は、［３］よりもアップグレードされた通信端末プロファイルを用いて、ＵＡ Ｐｒｏｆ規格に準拠する。上記規格は、ＭＭＳユーザエージェント４０２のプロファイルをＭＭＳ継電器／サーバ４０１に送信して、ＭＭＳ継電器／サーバ４０１において、ＭＭＳに基づいた内容適合の間に、特定のファイルタイプおよび／または特定のファイル形式のファイルを変換するスイッチを一時的にまたは永久的にＯＦＦ状態にすることを要求する。本発明の代替的な１つの実施形態では、この制御情報をアップグレードすることは、ＭＭＳユーザエージェントからＭＭＳ継電器／サーバへ特定の制約を送信することであるとする。

ステップ４０９、４１０が実行され、上記送信された他の情報がアプリケーション４０３の差プロファイルを含んでいる場合、この差プロファイルは、ステップ４１１において評価され、および／または、ステップ４１２においてＭＭＳユーザエージェント４０２からＭＭＳ継電器／サーバ４０１に送信される。

上記したように、この手順により、ＵＡ Ｐｒｏｆ規格に基づいた差プロファイルによって、全てのアプリケーションが情報の送信を確実にサポートする場合にのみ、望ましくない内容適合の問題を確実に解決することができる。

このことを実際には実現できないので、アプリケーション４０３からＭＭＳユーザエージェント４０２に差プロファイルを送信する必要がない以下の実施形態が好ましい。

ステップ４１１では、上記ＭＭＳユーザエージェント４０２は、第１の情報要素を通信端末プロファイル（例えば、ＵＡ Ｐｒｏｆ規格に基づいた差プロファイル、または、ＵＡ Ｐｒｏｆ規格に基づいた通信端末４０４の基本プロファイル）に挿入する。上記情報要素は、ＭＭＳ継電器／サーバ４０１に、特定のファイルタイプおよび／または特定のファイル形式の、ＭＭＳユーザエージェント４０２に送信されるファイルを全て変換する必要がないということを示す。本発明の代替的な１つの実施形態では、変換プロセスに影響を与えるために、ＭＭＳユーザエージェント４０２からＭＭＳ継電器／サーバ４０１に他の制約を（例えば、他の情報要素の形式で）送信することも、提供する。

情報要素が挿入されている、ＵＡ Ｐｒｏｆ規格に基づいた通信端末プロファイルの例について、表２〜４を参照しながら、以下に説明する。

上記第１の情報要素は、他の補助条件および／または制限を有していてもよい。上記条件および／または制限とは、例えば、第１の情報要素をＭＭＳ継電器／サーバ４０１に送信する時間から、一般的には、特定のファイルタイプおよび／または特定のファイル形式を有するＭＭＳユーザエージェント４０２に送信されたファイルの変換を抑制する必要がない情報か、または、ＭＭＳを用いている間にファイルをアプリケーション４０３の搬送媒体として用いる場合にのみ、ＭＭＳユーザエージェント４０２に送信される特定のファイルタイプおよび／または特定のファイル形式を有するファイルを変換する必要がない情報か、または、１つの特定の規定された送信側からＭＭＳユーザエージェント４０２にファイルを含んだマルチメディアメッセージを送信する場合にのみ、ＭＭＳユーザエージェント４０２に送信される特定のファイルタイプおよび／またはファイル形式を有するファイルを変換する必要がない情報、のことである。

例えばステップ４０７においてアプリケーション４０３が通信端末４０４からアンインストールされ、アプリケーション４０３がＭＭＳユーザエージェント４０２からログオフされた、他の模式的な実施形態では、ステップ４１１においてＵＡ Ｐｒｏｆ規格に基づいてＭＭＳユーザエージェント４０２が第２の情報要素を差プロファイルに挿入する。差プロファイルをＭＭＳ継電器／サーバ４０１に送信した後、差プロファイルは、ＭＭＳユーザエージェント４０２に送信される特定のファイルタイプおよび／またはファイル形式のファイルを第２の情報要素の送信時間からもう一度変換する必要があるということを、ＭＭＳ継電器／サーバ４０１に示す。

ステップ４１１において、適切な通信端末プロファイル（例えば、第１の情報要素の挿入による、または、ステップ４１０においてＭＭＳユーザエージェント４０２に送信された他の情報の使用による、ＵＡ Ｐｒｏｆ規格に基づいた差プロファイル）を形成した後、ステップ４１２では、通信端末からＭＭＳ継電器／サーバ４０１に通信端末プロファイルを送信する。

アプリケーション４０３を導入しない一実施形態では、第２の情報要素を差プロファイルに挿入および送信せず、上記した第１の情報要素を差プロファイルによってもう一度送信する。上記差プロファイルでは、メッセージヘッダフィールドに含まれた値の第１の情報要素が変更されている。この変更は、上記第１の情報要素を送信した後、ＭＭＳ継電器／サーバ４０１に、ＭＭＳユーザエージェント４０２に送信される特定のファイルタイプおよび／またはファイル形式を有するファイルを送信時間から（もう一度）変換する必要があることを示すように行われる。

したがって、ステップ４１２における通信端末プロファイルの送信の結果、特にＭＭＳがアプリケーションの搬送媒体として用いられる場合に、ＭＭＳ継電器／サーバ４０１が、通信端末４０４に送信されるマルチメディアメッセージをどのようにして操作する必要があるのかを知ることになる。

例えば、ステップ４１３では、ＭＭＳ継電器／サーバ４０１からＭＭＳユーザエージェント４０２にマルチメディアメッセージを送信する。

ステップ４０９、４１０を実行した場合、および、受信されたマルチメディアメッセージをＭＭＳユーザエージェント４０２が上記のように操作する必要があるということを指定するプロセスにおいて、他の情報をＭＭＳユーザエージェント４０２に供給した場合、ＭＭＳユーザエージェント４０２はこのことをステップ４１４において行う。

ステップ４１５では、ＭＭＳユーザエージェント４０２は、アプリケーション４０３の上記受信されたマルチメディアメッセージに含まれたデータをアプリケーション４０３に送信する。例えば、このことは、マルチメディアメッセージにおける個々のメッセージヘッダフィールドの内容であってもよいし、あるいは、全てのマルチメディアメッセージであってもよい。

一実施形態では、ステップ４１５において送信されたデータは、ステップ４０８および／またはステップ４１０において交換された他の情報に応じて決まる。

例えばステップ４１１において実行されたように情報要素が挿入されたＵＡ Ｐｒｏｆ規格に基づいた通信端末プロファイルの例について、表２、表３、表４、表５を参照しながら以下に説明する。

表２〜表５は、それぞれ、［７］よりも拡張された通信端末プロファイルの１つの可能な形態を示している。

表２の改良された通信端末プロファイルが、［７］よりも新しい、ＭＭＳＢｅａｒｅｒＦｏｒＡｐｐｌｉｃという表題のついた（entitled）ＸＭＬ属性を含んでいる。上記表題は、通信端末プロファイルを通信端末からＭＭＳ継電器／サーバに送信する場合、ＭＭＳを搬送媒体として用いる少なくとも１つのアプリケーションが上記通信端末に導入されたという情報の送信に用いられる。

他の実施形態では、ＸＭＬ属性は、ＭＭＳ継電器／サーバにおいて、内容適合をＯＮ状態およびＯＦＦ状態にするために用いられる。

他の実施形態では、表３に示したように構成された通信端末プロファイルを用いる。この通信端末プロファイルは、ＭｍｓＣｃｐｐＡｃｃｅｐｔＡｐｐｌｉｃという表題のついた（entitled）[７]よりも新しいＸＭＬ属性を有している。上記属性は、どのＭＩＭＥ内容種別が上記通信端末に導入されたアプリケーションによってサポートされるのかに関する情報を、通信端末からＭＭＳ継電器／サーバに送信するために用いられる。

他の実施形態では、通信端末からＭＭＳ継電器／サーバに送信される通信端末プロファイルは、表４に示したように改良される。この場合、上記通信端末プロファイルは、ＭＭＳＳｕｐｐｒｅｓｓＣｏｎｔｅｎｔＡｄａｐｔａｔｉｏｎＡｐｐｌｉｃという表題のついた［７］よりも新しいＸＭＬ属性を有している。ＭＭＳマルチメディアメッセージが上記通信端末に導入されるアプリケーションによってアプリケーションデータの送信に用いられる場合、上記属性を用いて、ＭＭＳ継電器／サーバにおいて内容適合を実行する必要のないという情報をＭＭＳ継電器／サーバに与えることができる。

他の実施形態では、通信端末からＭＭＳ継電器／サーバに送信される通信端末プロファイルは、表５に示したように改良される。この場合、上記通信端末プロファイルは、ＭＭＳＳｕｐｏｒｔｅｄＡｐｐｐｌｉｃｓという表題のついた［７］よりも新しいＸＭＬ属性を有している。上記属性を用いて、上記通信端末に導入されて（現在のところ）ＭＭＳを搬送媒体として使用する（または、基本的に、ＭＭＳを使用できる、つまり場合によってはＭＭＳを使用する予定である）アプリケーション（アプリケーション識別）のリストをＭＭＳ継電器／サーバに示すことができる。上記ＭＭＳ継電器／サーバが、アプリケーション識別および／またはアプリケーションアドレスが表５の端末によって信号送信されるアプリケーション識別と一致しているマルチメディアメッセージ（ＭＭ）を送信する予定である場合、この情報によって、ＭＭＳ継電器／サーバは、内容適合を抑制することができる。

表２〜表５は、ＵＡ Ｐｒｏｆ規格に基づいた属性のテキスト符号化（text coding）を示している。［５］では、全てのテキスト属性が２値のトークンに割当てられる２進表記法も、可能である。他の実施形態では、このようにして２進コード化された、ＵＡ Ｐｒｏｆ規格に従った通信端末プロファイルが用いられる。

以下の出版物を本明細書において例証している。
［１］ 3GPP TS 22.140 version 6.5.0, Release 6; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Messaging Service (MMS); Service Aspects (Stage 1)
［２］ 3GPP TS 23.140 version 6.5.0, Release 6; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description (Stage 2)
［３］ OMA-MMS-CONF-v1 2-20030929-C; Open Mobile Alliance; MMS Conformance Document 1.2; Candidate Version 16 September 2003
［４］ RFC2045; Multipurpose Internet Mail Extensions (MIME), Part One: "Format of Internet Message Bodies"; November 1996; (http://www.ietf.org/rfc/rfc2045.txt)
［５］ OMA-WAP-UAProf-v1 1-20021212-C; Open Mobile Alliance; User Agent Profile 1.1; Candidate Version 12-12-2002; (http://member.openmobilealliance.org)
［６］ Extensible Markup Language (XML) 1.1; W3C Recommendation, 4th February 2004, Francois Yergeau, John Cowan, Tim Bray, Jean Paoli, et.al.; (http://www.w3.org/XML)
［７］ OMA-MMS-CTR-v1 2-20030916-C; Open Mobile Alliance, MMS Client Transactions 1.2; Candidate Version 16 September 2003; (http://member.openmobilealliance.org)
［８］ RFC1766; Tags for the Identification of Languages; March 1995; (http://www.ietf.org/rfc/rfc1766.txt)
［９］ 3GPP TS 26.234 version 5.4.0, Release 5, Third Generation Partnership Project; Transparent end-to-end Packet Switched Streaming Service (PSS); Protocols and Codecs
［１０］ ＵＳ ２００１/００４７５１７ Ａ１
［１１］ ＵＳ ２００３/１７７２６９ Ａ１
［１２］ ＥＰ １ ０９１ ６０１ Ａ２
［１３］ ＥＰ １ ２６３ ２０５ Ａ１
［１４］ ＵＳ ２００３／０１７７２６９ Ａ１

本発明の模式的な一実施形態に関する通信システムを示す図である。 本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。 本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。 本発明の模式的な一実施形態に関するメッセージのフローチャートを示す図である。

〔符号の説明〕
１００ 通信システム
１０１ ＭＭＳユーザエージェント
１０２、１０３ ＭＭＳ継電器／サーバ
１０４ ＭＭＳユーザエージェント
１０５−１０７ インターフェース
１０８、１０９ 責任領域
１１０ インターフェース
１１１ サーバ
１１２ インターフェース
１１３ ＨＬＲ
１１４ インターフェース
１１５ ＭＭＳユーザデータベース
１１６ インターフェース
１１７ 付加価値サービスサーバ
１１８ インターフェース
１１９ 料金請求システム
１２０ インターフェース
１２１ 継電器要素
１２２ サーバ要素
２００ メッセージのフローチャート
２０１ ＭＭＳユーザエージェント
２０２、２０３ ＭＭＳ継電器／サーバ
２０４ ＭＭＳユーザエージェント
２０５−２０７ インターフェース
２０８ マルチメディアメッセージ
２０９−２１７ 処理ステップ
３００ メッセージのフローチャート
３０１ 通信端末
３０２ ゲートウェイコンピュータ
３０３ サーバ
３０４−３０８ 処理ステップ
３１０−３１２ 処理ステップ
３１３−３１５ メッセージ
４００ メッセージのフローチャート
４０１ ＭＭＳ継電器／サーバ
４０２ ＭＭＳユーザエージェント
４０３ アプリケーション
４０４ 通信端末
４０５、４０６ インターフェース
４０７−４１５ 処理ステップ

Claims (13)

1. 通信端末とサーバとを備えた通信システムであって、
   上記通信端末は、上記通信端末に導入されたまたは導入されていないアプリケーションに特有の特定用途向け登録データまたは登録解除データを上記サーバに送信するように構成されている信号装置を備え、
   上記サーバは、送信された上記特定用途向け登録データまたは登録解除データに応じて制御動作を実行するように構成されている制御装置を備えていることを特徴とする通信システム。
2. 上記サーバは、上記通信端末にメッセージを送信するように構成されている送信装置と、上記通信端末に送信されるメッセージを変換するように構成されている変換装置とを備えており、
   上記制御動作は、上記サーバの送信装置によって上記通信端末に送信されるメッセージの上記変換装置による変換を活動化または非活動化することであることを特徴とする請求項１に記載の通信システム。
3. 上記制御動作は、さらに、上記サーバの送信装置によって上記通信端末に送信されるいずれのメッセージを上記変換装置によって変換する必要があるかを決定することを含んでいることを特徴とする請求項２に記載の通信システム。
4. 上記変換装置は、マルチメディア送信プロトコルを用いて上記送信装置を介して上記通信端末に送信されるメッセージを変換するように構成されていることを特徴とする請求項２または３に記載の通信システム。
5. 上記信号装置は、マルチメディア送信プロトコルを用いて上記特定用途向け登録データまたは登録解除データを上記サーバに送信するように構成されていることを特徴とする請求項１〜４のいずれか１項に記載の通信システム。
6. 上記マルチメディア送信プロトコルは、ＭＭＳ送信プロトコルであることを特徴とする、請求項４または５に記載の通信システム。
7. 上記信号装置は、上記特定用途向け登録データまたは登録解除データを上記通信端末のプロファイルとして送信するように構成されていることを特徴とする請求項１〜６のいずれか１項に記載の通信システム。
8. 上記プロファイルは、ＵＡ‐Ｐｒｏｆ規格に従うことを特徴とする、請求項７に記載の通信システム。
9. 通信端末とサーバとを備えた通信システムの制御方法であって、
   上記通信端末は、上記通信端末に導入されたまたは導入されていないアプリケーションに特有の特定用途向け登録データまたは登録解除データを上記サーバに送信し、
   上記サーバは、送信された上記特定用途向け登録データまたは登録解除データに応じて制御動作を実行することを特徴とする通信システムの制御方法。
10. 通信端末を備えた通信システムのサーバであって、
    上記通信端末に導入されたまたは導入されていないアプリケーションに特有の、上記通信端末によって送信された特定用途向け登録データまたは登録解除データに応じて、制御動作を実行するように構成されている制御装置を備えたことを特徴とするサーバ。
11. 通信端末を備えた通信システムにおけるサーバの動作方法であって、
    上記サーバは、上記通信端末に導入されたまたは導入されていないアプリケーションに特有の、上記通信端末によって送信された特定用途向け登録データまたは登録解除データに応じて制御動作を実行することを特徴とするサーバの動作方法。
12. サーバを備えた通信システムの通信端末であって、
    上記通信端末に導入されたまたは導入されていないアプリケーションに特有の特定用途向け登録データまたは登録解除データを上記サーバに送信するように構成されている信号装置を備えていることを特徴とする通信端末。
13. サーバを備えた通信システムにおける通信端末の動作方法であって、
    上記通信端末は、上記通信端末に導入されたまたは導入されていないアプリケーションに特有の特定用途向け登録データまたは登録解除データをサーバに送信することを特徴とする通信端末の動作方法。

Images