(57)【要約】【課題】  ＷＡＰ／ＭＭＳ対応の移動端末においても、移動端末毎に存在する性能差を十二分に生かしたサービスを提供する。【解決手段】  移動端末（ＵＥ）１がコンテンツを取得する際に当該移動端末１に関するユーザエージェントの情報、ユーザ情報（User-Profile）、セルフケア情報（Selfcare-Profile）、移動端末情報（UE-Profile）からなるプロファイル情報をＲ２Ｍ１１のプロファイル部３３において生成する。このプロファイル情報はプロファイル部３３からＪＳＰ１０ｂに供給される。ＪＳＰ１０ｂでは、移動端末１が送出したコンテンツ要求リクエスト（HTTP Req）に応じてオリジン・サーバ２１から取得したコンテンツを、プロファイル情報における移動端末１の性能や能力を示すパラメータを参照することにより移動端末１の性能や能力を十二分に生かせるように変換する。【選択図】  図３
2005275534.tif 000002
【特許請求の範囲】
【請求項１】
移動端末からのコンテンツ要求に応じて、要求されたコンテンツをオリジン・サーバから取得して前記移動端末に提供する調整サーバと、
ユーザ関連情報および移動端末情報を一元管理する情報管理サーバとを少なくとも備え、
前記調整サーバは、前記移動端末からのコンテンツ要求リクエスト受信時に、前記移動端末の性能を示す移動端末情報を前記情報管理サーバから取得して、前記移動端末からのコンテンツ要求リクエストに応じて前記オリジン・サーバから取得したコンテンツを、前記情報管理サーバから取得した移動端末情報に適合するように変換して前記移動端末に提供するようにしたことを特徴とする移動体通信システム。
【請求項２】
前記情報管理サーバは、前記コンテンツ要求リクエストに先立つ前記移動端末からの接続開始リクエストを受信したことを契機に、ユーザが設定したユーザ固有情報とユーザを識別可能なユーザ情報からなる前記ユーザ関連情報および前記移動端末情報を含む当該移動端末に関するプロファイル情報を生成し、前記調整サーバからの要求時に前記プロファイル情報を渡すようにしたことを特徴とする請求項１記載の移動体通信システム。
【請求項３】
移動端末からのコンテンツ要求に応じて、要求されたコンテンツをオリジン・サーバから取得して前記移動端末に提供するサーバ装置であって、
前記移動端末からのコンテンツ要求リクエスト受信時に、ユーザ関連情報および移動端末情報を一元管理する情報管理サーバから前記移動端末の性能を示す移動端末情報を取得して、前記移動端末からのコンテンツ要求リクエストに応じて前記オリジン・サーバから取得したコンテンツを前記移動端末情報に適合するように変換して前記移動端末に提供するようにしたことを特徴とするサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話などの移動端末からインターネットに接続することができる移動体通信システム及びサーバ装置に関する。
【背景技術】
【０００２】
従来より、携帯電話などの移動端末からインターネットに接続することのできる移動体通信システムが運用されている。しかしながら、従来の移動体通信システムにおいては、各移動体通信事業者ごとにそれぞれ独自のプロトコルが用いられていた。
近年、いわゆる第３世代と呼ばれる携帯電話サービスが導入されつつあるが、この第３世代の移動体通信システムにおいては同一の移動端末を世界中で共通に使用することができるように標準化が進められており、ＷＡＰ（Wireless Application Protocol）及びＭＭＳ（Multimedia Messaging Service）の規格が共通仕様として採用されている（非特許文献１）。
【０００３】
上述のように、第３世代のサービスが開始されると、従来より提供されていた各移動体通信事業者独自のプロトコルに対応した移動端末と、上記ＷＡＰ／ＭＭＳ対応の移動端末とが存在することとなる。
各移動体通信事業者はそれぞれの独自プロトコルに基づいて、独自のサービスを提供していたが、これからは、ＷＡＰ／ＭＭＳ規格に対応した移動端末の加入者が増加していくことになる。このことから、各移動体通信事業者独自のプロトコルに対応した移動端末に限らず、これらＷＡＰ／ＭＭＳ対応の移動端末についても、従来より各移動体通信事業者独自の規格に対応した移動端末に対して提供しているものと同様のサービスを提供することが求められることになる。
【０００４】
例えば、従来の移動体通信システムでは、移動端末の個々の能力を判別することなく、システムワイドでの変換ルールを適用して取得したコンテンツの変換や圧縮を行っていた。この場合、従来の移動体通信システムでは移動端末の性能や能力を示す移動端末情報はインターネットに接続してコンテンツを取得する際に移動端末から送出されるコンテンツ要求リクエストに添付されているものの、従来の移動体通信システムではコンテンツの変換は移動端末の能力を加味することなく一律で行うこととしていたため、最も性能の低い移動端末に合わせて変換の規定をするより他無く、従来の移動体通信システムでは移動端末毎の性能を引き出すコンテンツの変換や圧縮の処理を移動端末毎の性能や能力に応じて行うことができなかった。このため、性能の良い移動端末はそのメリットを十分に享受することができないことになる。このように、従来の移動体通信システムでは移動端末毎に存在する性能差を十二分に生かしたサービスの提供ができないという問題点があった。
【非特許文献１】The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [online], (2002.01.18)，［平成１５年１１月１５日検索］，インターネット<URL:http://www.wapforum.org/what/WAPWhite#Paper1.pdf>
【発明の開示】
【発明が解決しようとする課題】
【０００５】
そこで、本発明は、ＷＡＰ／ＭＭＳ対応の移動端末においても、移動端末毎に存在する性能差を十二分に生かしたサービスを提供することができる移動体通信システムを提供することを目的としている。
【課題を解決するための手段】
【０００６】
本発明は、ユーザ関連情報および移動端末情報を一元管理する情報管理サーバから取得した移動端末情報に適合するようにオリジン・サーバから取得したコンテンツを変換するようにしたことを最も主要な特徴としている。
【発明の効果】
【０００７】
本発明の移動体通信システム及びサーバ装置は、ユーザ関連情報および移動端末情報を一元管理する情報管理サーバから取得した移動端末情報に適合するようコンテンツを変換するようにしたので、移動端末毎の性能の能力に合わせた変換を行って移動端末にコンテンツを渡せるようになるため、ＷＡＰ／ＭＭＳ対応の移動端末においても、各移動端末の特性を十二分に発揮することが可能となる。
【発明を実施するための最良の形態】
【０００８】
図１は、本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
この図において、１は携帯電話機等の移動端末（ＵＥ：User Equipment）、２は該移動端末１が接続されている無線基地局（ＢＴＳ：Base Transceiver Station）、３は複数の無線基地局２を管理する無線基地局制御装置（ＲＮＣ：Radio Network Controller）、４は前記無線基地局制御装置３に接続され、移動端末１の呼接続制御やサービス制御等を行う移動通信交換局（ＭＳＣ：Mobile service Switching Center）である。
また、５は前記無線基地局制御装置（ＲＮＣ）３とコアネットワーク（パケット網）とのゲートウエイ（ＳＧＳＮ：Serving GPRS Support Node）、６はコアネットワーク（パケット網）とインターネットなどのＩＰネットワークとのゲートウエイ（ＧＧＳＮ：Gateway GPRS Support Node）である。
【０００９】
１０はＷＡＰとＨＴＴＰ（HyperText Transfer Protocol ）とを変換するノード（ＷＡＰ−ＧＷ：WAP-Gateway）、及び、受け付けたリクエストを適切な形式に変換して後段に送出するなどしてＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うアプリケーションゲートウエイ（ＪＳＰ：J-Phone Scheme Proxy）とを有する調整サーバ（ＷＡＰ−ＧＷ及びＪＳＰ）である。なお、ＨＴＴＰは、ウェブブラウザとウェブサーバ間において、ＨＴＭＬ（Hyper Text Markup Language ）ファイルなどの文書を転送するために用いられるアプリケーションレベルのプロトコルである。１１はRADIUSセッション管理を行うＲＡＤＩＵＳサーバ１１ａを備え、ＷＡＰ／ＭＭＳサービス加入者がウェブ（Web）やメール（Mail）等のサービスを利用する際に必要なユーザ情報や移動端末の能力に関する情報（UE-Profile）等を一元管理し、クライアントからの要求に応じて提供する情報管理サーバ（Ｒ２Ｍ：RADIUS & Repository Manager）である。
【００１０】
なお、Ｒ２Ｍ１１はＧＧＳＮ６とのRADIUS Accountingプロトコルの終端であるＲＡＤＩＵＳサーバ１１ａを備えている。このＲＡＤＩＵＳサーバ１１ａには、ユーザ毎のセッション管理およびセッションログの生成などの機能も実装されている。ユーザ毎のセッション管理情報はアクセス毎のクライアント特定のために必要不可欠な情報であり、セッション管理にはＷＡＰ−ＧＷ及びＪＳＰ１０へのReplication機能や他ノードからの問い合わせに応答する機能が実装される。
【００１１】
図１に戻り、１２は全加入者情報を一元管理するディレクトリ・サーバ（ＤＩＲ：Directory Server）である。この加入者情報は、全世代、全地域間で共用されるものであり、ＤＩＲ１２はＤＲＳ（Directory Replica Server）１３の情報元になっている。１３はディレクトリ・レプリカ・サーバ（ＤＲＳ：Directory Replica Server）であり、一定間隔（例えば、１分間隔）でＤＩＲ１２から加入者情報をローカルにコピーして維持することにより、照会要求に対して加入者情報を提供する。これにより、ＤＩＲ１２の障害時においても、サービス（オーダー・エントリーを除く）を継続して提供することができる。
【００１２】
１４は前記ＷＡＰ―ＧＷ及びＪＳＰ１０に接続され、移動体通信システムのコアネットワークとインターネット２０とを接続するウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）である。図示するようにインターネット２０にはオリジン・サーバ（Origin Server：指定されるリソースが存在するか、あるいは生成されるサーバ）２１が接続されている。２２は移動端末１に表示されるメニューやメニューを生成する機能を有するサーバ（Portal）である。
なお、図１においては、前記ＷＡＰ−ＧＷ及びＪＳＰ１０は、１個しか図示していないが、これらは処理を分散することができるように、それぞれ複数個設けるようにすると共にロードバランサーを設けて処理を振り分けるようにしてもよい。また、ＷＡＰ−ＧＷ及びＪＳＰ１０は該当ユーザのRADIUS情報がRADIUSサーバ１１ａから複製（Replication）され、保持している間のみ移動端末１におけるユーザエージェントからの要求が有効となるように制御する。
【００１３】
次に、図１に示す本発明にかかる移動体通信システムにおいて実行されるＷＡＰプロトコルの基本シーケンスを図２に示す。この基本シーケンスは、移動端末１がインターネット２０に接続されているオリジン・サーバ２１からコンテンツを取得する際のシーケンスである。
図２に示すように、移動端末１上で動作しているユーザエージェントがコンテンツを取得する際にはユーザエージェントから通信接続要求が送出され、この通信接続要求に応じてＧＧＳＮ６からRadius Accounting Req(Accounting-start)が送出される。このリクエストを受信したＲＡＤＩＵＳサーバ１１ａは、リクエストのヘッダに添付されているユーザ毎のセッション情報をメモリ上に保管（Add/Modify Record）する。次いで、ＲＡＤＩＵＳサーバ１１ａは、セッション情報と同様のRADIUS情報をリプリケーションするためにRadius Accounting ReplicationをＷＡＰ−ＧＷ及びＪＳＰ１０に送り、これを受信したＷＡＰ−ＧＷ及びＪＳＰ１０はReplicateされたRADIUS情報をサーバ内に保管する。そして、ＷＡＰ−ＧＷ及びＪＳＰ１０はRADIUS情報がリプリケーションされたことを通知するRadius Accounting Replication ResをＲＡＤＩＵＳサーバ１１ａに返信する。これを受信したＲＡＤＩＵＳサーバ１１ａは接続する準備ができたことを通知するRadius Accounting ResをＧＧＳＮ６に送出する。これにより、ユーザエージェントとＷＡＰ−ＧＷ及びＪＳＰ１０との間でＴＣＰ（Transmission Control Protocol）セッションを確立するためのTCP Handshakeが行われてＴＣＰセッションが確立（Session Connected）される。なお、RADIUS情報およびユーザ毎のセッション情報はRadius Accounting Req(Accounting-start)に添付された加入者情報等からなるAttribute情報とされている。
【００１４】
ＴＣＰセッションが確立すると、ユーザエージェントはオリジン・サーバ２１からコンテンツを取得するコンテンツ要求リクエストであるHTTP Reqを送出する。このHTTP Reqを受信したＷＡＰ−ＧＷ及びＪＳＰ１０は保管したRADIUS 情報を参照して、RADIUS情報が存在すると共に加入者情報が一致するときのみHTTP Reqを受け付ける。ＷＡＰ−ＧＷ及びＪＳＰ１０は、コンテンツを要求した移動端末１の性能を表す移動端末情報をＲ２Ｍ１１から取得し、受け付けたHTTP Reqの拡張ヘッダに不足している移動端末情報を補完する。次いで、ＷＡＰ−ＧＷ及びＪＳＰ１０とコンテンツを取得するオリジン・サーバ２１間においてＴＣＰセッションを確立するためのTCP Handshakeが行われてＴＣＰセッションが確立（Session Connected）される。ＴＣＰセッションが確立されるとＷＡＰ−ＧＷ及びＪＳＰ１０はHTTP Reqをオリジン・サーバ２１に送り、オリジン・サーバ２１は要求されたコンテンツを返送するHTTP Resを送出する。
【００１５】
この際に、オリジン・サーバ２１はHTTP Resに添付された拡張ヘッダを参照することにより移動端末１の性能を知ることができ、移動端末１の性能を十二分に発揮できるように性能に応じたコンテンツを返送することができる。オリジン・サーバ２１は、要求された全てのコンテンツを送出するとＴＣＰセッションを閉じるためのTCP FinをＷＡＰ−ＧＷ及びＪＳＰ１０に送出し、これを受信したＷＡＰ−ＧＷ及びＪＳＰ１０は、HTTP ResおよびTCP Finを受信したことを通知するAckとＴＣＰセッションを閉じるためのTCP Finをオリジン・サーバ２１に送出する。オリジン・サーバ２１はこれを受けたことを通知するTCP Ackを返送してＴＣＰセッションを閉じ、ＷＡＰ−ＧＷ及びＪＳＰ１０はTCP Ackを受信してＴＣＰセッションを閉じることによりＷＡＰ−ＧＷ及びＪＳＰ１０とオリジン・サーバ２１間におけるＴＣＰセッションが終了（Session Disconnected）する。
【００１６】
移動端末１から要求されたコンテンツを取得したＷＡＰ−ＧＷ及びＪＳＰ１０は、コンテンツを要求した移動端末１の性能を表す移動端末情報を参照し、この移動端末情報に基づいて移動端末１の性能を十二分に発揮できるようにコンテンツの変換処理を行う。次いで、ＷＡＰ−ＧＷ及びＪＳＰ１０は変換後のコンテンツを返送するHTTP Resをユーザエージェントに送出する。HTTP Resを受信したユーザエージェントは、取得したコンテンツを表示すると共に受信したことを通知するAckとＴＣＰセッションを閉じるためのTCP FinをＷＡＰ−ＧＷ及びＪＳＰ１０に送出する。これを受信したＷＡＰ−ＧＷ及びＪＳＰ１０は、TCP Finを受信したことを通知するTCP Ackを返送し、ユーザエージェントとＷＡＰ−ＧＷ及びＪＳＰ１０間におけるＴＣＰセッションが終了（Session Disconnected）する。次いで、ユーザエージェントからの通信を終了させるための通信終了要求に応じてＧＧＳＮ６からRadius Accounting Req(Accounting-stop)が送出される。このリクエストを受信したＲＡＤＩＵＳサーバ１１ａは該当するRADIUS情報を破棄しRadius Accounting ResをＧＧＳＮ６に送出する。これにより、ユーザエージェントとＷＡＰ−ＧＷ及びＪＳＰ１０との間の通信が終了する。
【００１７】
次に、本発明の移動体通信システムにおいて特徴的な構成であるＷＡＰ−ＧＷ及びＪＳＰ１０とＲ２Ｍ１１の詳細構成を移動体通信システムの概要と共に図３に示す。
図３において、Ｒ２Ｍ１１はＲＡＤＩＵＳサーバ１１ａを備えているが明示していない。Ｒ２Ｍ１１は、ＲＡＤＩＵＳサーバ１１ａで管理されるユーザ毎のセッション情報であるRADIUS情報を保持するデータベースであるRAD Master３０と、加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤ（ＵＩＤ：User ID）等の通知にユーザが同意したか否か、また規制対象とするＵＲＬ（Uniform Resource Locators）をユーザが持つか否かなどのユーザの設定に関する固有情報からなるSelfcare Profile情報を保持するデータベースであるSelfcare DB３１と、移動端末１の機種名および性能や能力を表すパラメータを機種毎に保持しているデータベースであるCC/PP Repository３２を備えている。さらに、Ｒ２Ｍ１１はセッション中のユーザにかかるセッション情報（Acct-Profile）、ユーザエージェントのプロファイル情報（UA-Profile）、移動端末情報（UE-Profile）、セルフケア情報（Selfcare-Profile）、ユーザ情報（User-Profile）からなるプロファイル情報を作成してセッションが継続している間はメモリ上にキャッシュしているプロファイル部（Profile）３３を備えている。また、ＷＡＰ−ＧＷ及びＪＳＰ１０はＷＡＰ−ＧＷ１０ａとＪＳＰ１０ｂとから構成されている。なお、Portalサーバ２２により生成したメニューを移動端末１に表示して、そのメニューから設定／編集したSelfcare Profile情報をSelfcare DB３１に格納／更新することができる。また、Profile Repository４０は機種情報や性能を示す情報からなる移動端末情報（UE-Profile）が格納されている移動端末製造業者が構築しているデータベースである。
【００１８】
図３に示す構成において、前述したように移動端末１がオリジン・サーバ２１からコンテンツを取得する際に、移動端末１のユーザエージェントからの通信接続要求に応じてＧＧＳＮ６からAccounting Req(Accounting-start)が送出される。このリクエストを受信したＲ２Ｍ１１は、リクエストのAttribute情報をRADIUS情報としてRAD Master３０に保管する。そして、ＧＧＳＮ６が移動端末１に払い出したＩＰアドレス、移動端末１のＭＳＩＳＤＮ（Mobile Station ISDN number：電話番号）および携帯電話の加入者に与えられた国際識別番号であるＩＭＳＩ（International Mobile Subscriber Identity）等からなるRADIUS情報がＷＡＰ−ＧＷ１０ａにReplicationされると共に、Profile部３３に供給される。Profile部３３はこれを契機にAccounting Req(Accounting-start)を送出した移動端末１に関するプロファイル情報の作成を開始する。すなわち、Profile部３３はSelfcare DB３１にアクセスして当該移動端末１を使用しているユーザが設定した固有情報からなるセルフケア情報（Selfcare-Profile）を取得する。また、Profile部３３はCC/PP Repository３２にアクセスして当該移動端末１の機種名および性能や能力を表すパラメータからなる移動端末情報（UE-Profile）を取得する。この場合、該当するエントリがCC/PP Repository３２に存在しない場合は、Profile Repository４０へ問い合わせを行いCC/PP Repository３２に移動端末情報（UE-Profile）を保存するようにする。また、Profile Repository４０へ問い合わせできない場合はＲ２Ｍ１１で設定したDefault値をProfile部３３へ返すようにする。さらに、Profile部３３はＤＲＳ１３にアクセスして当該移動端末１を使用しているユーザのユーザ情報（User-Profile）を取得する。このユーザ情報は、ＩＭＳＩ、ＭＳＩＳＤＮおよび加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤから構成されている。そして、収集された当該移動端末１に関するセルフケア情報（Selfcare-Profile）、移動端末情報（UE-Profile）、ユーザ情報（User-Profile）とRADIUS情報を一つにまとめて該当する移動端末１に関するプロファイル情報を作成してメモリにキャッシュする。
【００１９】
そして、移動端末１上のユーザエージェントとＷＡＰ−ＧＷ１０ａとの間でＴＣＰセッションが確立されると、上述したようにユーザエージェントからHTTP Reqが送出される。このHTTP ReqがＷＡＰ−ＧＷ１０ａで受信されると、HTTP Reqにおける要求するリソースを指し示すRequest URI（ＵＲＩ：Uniform Resource Identifier）、ＭＳＩＳＤＮ、ＩＭＳＩをＷＡＰ−ＧＷ１０ａはＪＳＰ１０ｂに渡す。ＪＳＰ１０ｂは渡されたＭＳＩＳＤＮあるいはＩＭＳＩに該当するプロファイル情報をProfile部３３にアクセスして取得する。そして、HTTP Reqの拡張ヘッダにおいて必要とされる移動端末情報（UE-Profile）が不足している場合は、ＪＳＰ１０ｂは取得したプロファイル情報の移動端末情報（UE-Profile）に基づいて不足しているパラメータをHTTP Reqの拡張ヘッダに補完する。この場合、ＷＡＰ／ＭＭＳ対応の移動端末のユーザエージェントにおいては移動端末情報（UE-Profile）のパラメータの拡張ヘッダが添付されたHTTP Reqの送出が困難であることから、ＷＡＰ／ＭＭＳ対応の移動端末のユーザエージェントから送出されたHTTP Reqには移動端末情報（UE-Profile）のパラメータが添付された拡張ヘッダが補完されるようになる。これにより、HTTP Reqを送出した移動端末の種類にかかわらず、移動体通信システムからは今までと同様の内容の拡張ヘッダが添付されたHTTP Reqをインターネットへ向けて送出することができるようになる。従って、コンテンツを要求されたオリジン・サーバ２１は、今までと同様にして要求されたコンテンツを返送することが可能となる。
【００２０】
このようにして拡張ヘッダが必要に応じて補完されたHTTP ReqはＪＳＰ１０ｂから送出され、そのRequest URIで特定されるオリジン・サーバ２１は、拡張ヘッダを参照して移動端末情報（UE-Profile）のパラメータに適合するコンテンツを選択あるいは生成して、そのコンテンツを返送するHTTP ResをＪＳＰ１０ｂに向けて送出する。ただし、オリジン・サーバ２１によっては拡張ヘッダを参照することなくコンテンツを返送するサーバも存在し、ＪＳＰ１０ｂが取得したコンテンツは必ずしもコンテンツを要求した移動端末１の性能や能力に適合するものとはされていない。そこで、HTTP Resを受信したＪＳＰ１０ｂはコンテンツを要求した移動端末１に関するプロファイル情報の移動端末情報（UE-Profile）を参照して、移動端末１の性能や能力に適合するようにTrans-codingしている。Trans-codingはコンテンツを移動端末１で正しく表示させるために行われ、コンテンツを移動端末１に合った形式に変換・編集または制限して正しく表示させる処理を行っている。
【００２１】
ＪＳＰ１０ｂで行われるTrans-codingではマークアップ言語（ＭＬ）変換、文字セット変換、オブジェクト変換が行われる。ＭＬ変換では移動端末１がサポートするContent Typeが特定され、特定された移動端末１がサポートするContent Typeに従ってマークアップ言語の変換が行われる。マークアップ言語の種類には、ＳＧＭＬ、ＨＴＭＬ、ＸＴＭＬ等がある。また、文字セット変換ではマークアップ言語の種類等にかかわらず、コンテンツのテキストについて移動端末１の能力に応じて文字コードおよび絵文字の変換を行う。文字コード変換では、移動端末１が取得されたコンテンツの文字コードをサポートしていない場合に行われ、例えばShift-JIS、EUC-JP、ISO-2022-JP、UTF-8、ISO-10646-UCS-2 の文字コードを、Shift-JISあるいはUTF-8 UEの文字コードに変換している。絵文字変換では、変換元Pictogram形式と変換後Pictogram形式を定義して、規則に合わせたPictogram形式の変換を行うようにする。文字コードおよび絵文字の変換機能は、それぞれ単独に動作するようにしてそれぞれの機能をそれぞれオン／オフできるようにしても良い。オブジェクト変換では、移動端末１がサポートするファイル形式が特定され、移動端末１がサポートすると特定されたファイル形式に従ってオブジェクト（コンテンツ）のファイル形式の変換が行われる。ファイル形式には、ＪＰＥＧ，ＧＩＦ、ＰＮＧ等がある。また、オブジェクト変換では移動端末１の画面の大きさや表示部の性能に応じてピクセル数変換や色深度変換が行われる。なお、移動端末１の性能や能力はＪＳＰ１０ｂが取得したプロファイル情報の移動端末情報（UE-Profile）を参照すればよい。
【００２２】
このようにして、移動端末１に合った形式に変換・編集または制限して正しく表示させるTrans-coding処理の行われたコンテンツがＪＳＰ１０ｂからＷＡＰ−ＧＷ１０ａに渡されて、ＷＡＰ−ＧＷ１０ａから移動端末１に向けてTrans-coding処理後のコンテンツを送るHTTP Resが送出される。移動端末１では、HTTP Resを受信することによりコンテンツが取得され表示される。この場合、コンテンツがそれぞれの移動端末に適した形式にTrans-coding処理されていることから移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。これにより、移動体通信事業者対応の移動端末でもＷＡＰ／ＭＭＳ対応の移動端末でも同様に、移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。
【００２３】
以上説明したように、移動体通信事業者対応の移動端末ではコンテンツ要求リクエストに移動端末の性能や能力を示すパラメータの拡張ヘッダが添付されている。このように拡張ヘッダがコンテンツ要求リクエストに添付されていると、このリクエストに応じてコンテンツを提供するオリジンサーバは、拡張ヘッダとして添付されているパラメータを参照して、移動端末の性能や能力を十二分に生かせるコンテンツを提供することができる。また、オリジンサーバが移動端末の性能や能力を十二分に生かせるコンテンツを提供するサービスを行っていない場合は、移動体通信システム側において拡張ヘッダとして添付されているパラメータを参照することにより移動端末の性能や能力を十二分に生かせるようにコンテンツを変換することができる。
【００２４】
本発明にかかる移動体通信システムにおいては、移動端末がコンテンツを取得する際に当該移動端末に関するユーザエージェントの情報、ユーザ情報（User-Profile）、セルフケア情報（Selfcare-Profile）、移動端末情報（UE-Profile）からなるプロファイル情報をＲ２Ｍ１１において生成する。このプロファイル情報はＲ２Ｍ１１からＪＳＰ１０ｂに供給される。このため、ＷＡＰ／ＭＭＳ対応の移動端末が送出したコンテンツ要求リクエストにＪＳＰ１０ｂにおいてプロファイル情報に基づいて移動端末の性能や能力を示すパラメータの拡張ヘッダを添付することができる。また、ＪＳＰ１０ｂにおいてプロファイル情報の移動端末の性能や能力を示すパラメータを参照することにより移動端末の性能や能力を十二分に生かせるように取得したコンテンツを変換することができる。これにより、ＷＡＰ／ＭＭＳ対応の移動端末であっても移動体通信事業者が提供している独自プロトコルに基づく独自のサービスを受けることができ、移動端末の有する性能や能力を十二分に生かしてコンテンツを取得することができるようになる。さらに、プロファイル情報はＲ２Ｍ１１において一元管理されることから、拡張ヘッダが添付されていない場合にプロファイル情報を構成しているいずれかの情報を必要とするサーバの負担を軽減することができる。
【産業上の利用可能性】
【００２５】
以上の説明では、移動体通信システムにおける移動端末がインターネット上からコンテンツを取得するものとしたが、これに限るものではなくあるネットワークにおける通信端末が他のネットワークからコンテンツを取得する際にも適用することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
【図２】本発明にかかる移動体通信システムにおいて実行されるＷＡＰプロトコルの基本シーケンスを示す図である。
【図３】本発明の移動体通信システムにおいて特徴的な構成であるＷＡＰ−ＧＷ及びＪＳＰとＲ２Ｍの詳細構成を移動体通信システムの概要と共に示す図である。
【符号の説明】
【００２７】
１  移動端末（ＵＥ）
２  無線基地局（ＢＴＳ）
３  無線基地局制御装置（ＲＮＣ）
４  移動通信交換局（ＭＳＣ）
５  ゲートウエイ（ＳＧＳＮ）
６  ゲートウエイ（ＧＧＳＮ）
１０  ノードおよびアプリケーションゲートウエイ（ＷＡＰ−ＧＷ及びＪＳＰ）
１０ａ  ＷＡＰ−ＧＷ
１０ｂ  ＪＳＰ
１１  情報管理サーバ（Ｒ２Ｍ）
１１ａ  ＲＡＤＩＵＳサーバ
１２  ディレクトリサーバ（ＤＩＲ）
１３  ディレクトリ・レプリカ・サーバ（ＤＲＳ）
１４  ウェブ・ゲートウエイ（ＷＧＷ）
２０  インターネット
２１  オリジン・サーバ
２２  サーバ（Portal）
３０  RAD Master
３１  Selfcare DB
３２  CC/PP Repository
３３  プロファイル部（Profile）
４０  Profile Repository
【図１】
2005275534.tif 000003
【図２】
2005275534.tif 000004
【図３】
2005275534.tif 000005