(57)【要約】【課題】  ＷＡＰ／ＭＭＳ対応の移動端末においても、コンテンツ要求リクエスト処理する際に必要とする情報が不足しないようにする。【解決手段】  移動端末（ＵＥ）１がコンテンツを取得する際に当該移動端末１に関するユーザエージェントの情報、ユーザ情報（User-Profile）、セルフケア情報（Selfcare-Profile）、移動端末情報（UE-Profile）からなるプロファイル情報をＲ２Ｍ１１のプロファイル部３３において生成する。このプロファイル情報はプロファイル部３３からＪＳＰ１０ｂに供給される。ＪＳＰ１０ｂでは、移動端末１が送出したコンテンツ要求リクエスト（HTTP Req）にプロファイル情報に基づいて移動端末の性能や能力を示すパラメータの拡張ヘッダを添付する。拡張ヘッダが添付されたHTTP Reqがオリジン・サーバ２１に送出されて、移動端末１の性能や能力を十二分に生かせるコンテンツを取得できるようになる。【選択図】  図３
2005277526.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ではコンテンツを移動端末１に合った形式に変換・編集または制限して正しく表示させる処理を行っている。
【００２２】
ＪＳＰ１０ｂで行われる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処理されていることから移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。これにより、移動体通信事業者対応の移動端末でもＷＡＰ／ＭＭＳ対応の移動端末でも同様に、移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。
【００２４】
次に、前述したＨＴＴＰの拡張ヘッダを補完する動作イメージを示すシーケンスを図４に示す。
図４に示すように、移動端末１上で動作しているユーザエージェント（ＵＡ）がコンテンツを取得する際にはユーザエージェントから通信接続要求であるActivate PDP Reqが送出される。このActivate PDP Reqは、ＳＧＳＮ５で受信される。そして、ＩＭＳＩおよびＭＳＩＳＤＮの情報が添付されているCreate PDP Reqを生成してＧＧＳＮ６に送る。Create PDP Reqを受信したＧＧＳＮ６は、Activate PDP Reqを送出したユーザエージェントにＩＰアドレスを払い出し、このＩＰアドレスとＭＳＩＳＤＮあるいはＩＭＳＩが添付されたAccounting Reqを生成してＲＡＤＩＵＳサーバ１１ａに送出する。なお、Accounting Reqは表記は異なるが図２に示すRadius Accounting Req(Accounting-start)と同じリクエストである。
【００２５】
Accounting Reqを受信したＲＡＤＩＵＳサーバ１１ａは、リクエストに添付された情報をRADIUS情報としてRAD Master３０に保管すると共に、RADIUS Replicationを生成してＷＡＰ−ＧＷ１０ａにReplicationする。また、ＲＡＤＩＵＳサーバ１１ａは、移動端末１に関するプロファイル情報を保存させるSave Profile Reqを生成してProfile部３３に送る。Save Profile Reqを受信したProfile部３３は、ユーザ情報（User-Profile）を取得するacquisition User-ProfileによりＤＲＳ１３に照会要求し、ＤＲＳ１３からユーザ情報（User-Profile）を取得する。この際の照会要求のパラメータは、ＭＳＩＳＤＮあるいはＩＭＳＩとされる。さらに、Profile部３３はSave Profile Reqに添付されたＭＳＩＳＤＮあるいはＩＭＳＩに基づいて、Selfcare DB３１に照会要求してセルフケア情報（Selfcare-Profile）を取得すると共に、CC/PP Repository３２に照会要求して移動端末情報（UE-Profile）を取得する。この場合、照会要求されたエントリが存在しない場合は、Profile Repository４０へ問い合わせを行いCC/PP Repository３２に移動端末情報（UE-Profile）を保存する。また、Profile Repository４０へ問い合わせできない場合はＲ２Ｍ１１で設定したDefault値をProfile部３３へ返すようにする。Profile部３３はこれらの取得した情報と前記したユーザエージェント情報をプロファイル情報としてメモリにキャッシュする。
【００２６】
そして、移動端末１におけるユーザエージェントからコンテンツを取得するためのコンテンツ要求リクエストであるHTTP Reqが送出される。このHTTP Reqのヘッダには、ＧＧＳＮ６から払い出されたユーザエージェントのＩＰアドレス、コンテンツを取得する相手先であるオリジン・サーバ２１のＵＲＩ（Request-URI）、User-Agent（ユーザエージェント情報）あるいはUA-Prof情報が少なくとも添付されている。このHTTP Reqを受信したＷＡＰ−ＧＷ１０ａは、ヘッダにＭＳＩＳＤＮ、ＩＭＳＩが添付されたHTTP ReqをＪＳＰ１０ｂに渡す。また、受信したHTTP ReqのヘッダにUA-Prof情報が添付されていた場合はＷＡＰ−ＧＷ１０ａはUA-Prof情報をProfile部３３に渡し、HTTP Reqを送出した移動端末１に関するプロファイル情報を補完する。そして、Profile部３３とＪＳＰ１０ｂとの間においてHTTP Reqを送出した移動端末１にかかるプロファイル情報の取得と送出（acquisition & Complement Profile）が行われて、Profile部３３にキャッシュされていたプロファイル情報がＪＳＰ１０ｂに渡される。ＪＳＰ１０ｂは、HTTP Reqの拡張ヘッダにおいて必要とされる移動端末情報（UE-Profile）が不足している場合は、取得したプロファイル情報の移動端末情報（UE-Profile）に基づいて不足しているパラメータをHTTP Reqの拡張ヘッダに補完する。ＪＳＰ１０ｂは、この拡張ヘッダとRequest-URIが少なくとも添付されているHTTP Reqをオリジン・サーバ２１に送出して、オリジン・サーバ２１から要求されたコンテンツを取得する。
【００２７】
ここで、ＪＳＰ１０ｂにおいて行われる拡張ヘッダの補完処理のフローチャートを図５に示す。
拡張ヘッダの補完処理は、ヘッダにＭＳＩＳＤＮ、ＩＭＳＩが添付されたHTTP ReqがＷＡＰ−ＧＷ１０ａからＪＳＰ１０ｂに渡された際にスタートされ、ＪＳＰ１０ｂはステップＳ１０にてHTTP Reqを送出した移動端末１に関するユーザエージェントのプロファイル情報をProfile部３３から取得する。次いで、ステップＳ１１にてＷＡＰ−ＧＷ１０ａから渡されたHTTP Reqの拡張ヘッダにユーザＩＤ（ＵＩＤ）が添付されているか否かが判断される。この場合、移動端末１がＷＡＰ／ＭＭＳ対応の移動端末であった場合は拡張ヘッダが添付されておらずＮＯと判断されてステップＳ１４に分岐する。また、移動体通信事業者対応の移動端末であった場合は拡張ヘッダが添付されていることからＹＥＳと判断されてステップＳ１２に進む。ステップＳ１２ではHTTP Reqに添付されていたＵＩＤが、Profile部３３から取得したプロファイル情報におけるユーザ情報（User-Profile）のＵＩＤとが異なるか否かが判断される。ここで、両者のユーザＩＤが異なる場合はHTTP Reqを送出したユーザエージェントが、Profile部３３から取得したプロファイル情報のユーザエージェントと異なることになるため、ステップＳ１３に進んでユーザエージェント（ＵＡ）にエラーを返し、拡張ヘッダの補完処理を終了する。
【００２８】
また、添付されていたユーザＩＤがProfile部３３から取得したプロファイル情報におけるＵＩＤとが一致している場合は、HTTP Reqを送出したユーザエージェントと、Profile部３３から取得したプロファイル情報のユーザエージェントが一致し、拡張ヘッダの補完処理を進めるためステップＳ１４に分岐する。ステップＳ１４では、HTTP Reqに他の拡張ヘッダが添付されているか否かが判断される。ここで、HTTP Reqに他の拡張ヘッダが添付されていると判断された場合はステップＳ１５に進み、HTTP Reqに他の拡張ヘッダが添付されていないと判断された場合はステップＳ１８に分岐する。ステップＳ１８では、Profile部３３から取得したプロファイル情報におけるセルフケア情報（Selfcare-Profile）を参照してユーザがＵＩＤの送出に同意しているか否かが判断される。ここで、ユーザがＵＩＤの送出に同意している場合は、ステップＳ１９に進んでHTTP Reqの拡張ヘッダにＵＩＤを添付し送出する。また、ユーザがＵＩＤの送出に同意していない場合は、ステップＳ２０に分岐してHTTP Reqの拡張ヘッダからＵＩＤを削除する。
【００２９】
ステップＳ１９あるいはステップＳ２０の処理が終了すると、ステップＳ１５に進みHTTP Reqの拡張ヘッダにおいて不足している移動端末情報（UE-Profile）を添付する。この場合のHTTP Reqの拡張ヘッダに添付される対象とされるヘッダパラメータの一例の一覧表を図６に示す。図６に示す一覧表では、対象とされるヘッダパラメータ（Parameter）と、パラメータの説明（Explanation）と、プロファイルクラス（Profile class）と、取得場所（origin of acquisition）が示されている。図６に示す機種名を示すx-jphone-msname 、画面サイズ（幅＊高さ）を示すx-jphone-display 、色深度を示すx-jphone-color 、発音数を示すx-jphone-sound、SMAFFile対応の種類を示すx-jphone-smaf、ユーザＩＤを示すx-jphone-uid、ＭＳＩＳＤＮを示すx-jphone-msisdn、待ち受け地域を示すx-jphone-region、ＩＭＳＩを示すx-jphone-Imsiのパラメータが不足している場合に添付される対象のヘッダパラメータとされる。ただし、ＭＳＩＳＤＮを示すx-jphone-msisdnのパラメータは許可されたノードについてのみ添付することとしている。
【００３０】
そこで、ステップＳ１５の処理が終了するとステップＳ１６にてHTTP Reqの転送先であるオリジン・サーバ２１がＩＭＳＩあるいはＭＳＩＳＤＮを示すmsisdnパラメータの添付が許可されているか否かが判断される。msisdnパラメータの添付が許可されるノードは移動体通信事業者により決定されて外部設定ファイルに格納されている。ここで、外部設定ファイルを参照して転送先のオリジン・サーバ２１がmsisdnパラメータの添付が許可されるノードであった場合は、ステップＳ１７に進んでＵＤＢから取得したプロファイル情報のユーザ情報（User-Profile）におけるＩＭＳＩあるいはＭＳＩＳＤＮを拡張ヘッダに添付し、拡張ヘッダの補完処理を終了する。また、転送先のオリジン・サーバ２１がmsisdnパラメータの添付が許可されないノードであった場合は、そのまま拡張ヘッダの補完処理を終了する。
【００３１】
ところで、移動端末１のユーザエージェントとオリジン・サーバ２１との間において暗号通信機能と認証機能をもつ暗号化プロトコルであるＳＳＬ（Secure Socket Layer ）通信を行っていると、トンネリングされているためＷＡＰ−ＧＷ及びＪＳＰ１０においては転送される双方向のデータに対してアクセスすることができずHTTP Reqにユーザ情報や移動端末情報の補完をすることができない。すなわち、ＷＡＰ−ＧＷ及びＪＳＰ１０は、HTTP ReqをEND to ENDで送出してしまうため、オリジン・サーバ２１においてリクエスト処理する際に必要とする情報が不足する不具合が生じるおそれがある。そこで、ＨＴＴＰ拡張ヘッダ補完等のアプリケーション処理をすることを目的として、ユーザエージェントからのＳＳＬ通信をＷＡＰ−ＧＷ及びＪＳＰ１０において一旦終端し、ＷＡＰ−ＧＷ及びＪＳＰ１０においてＨＴＴＰ拡張ヘッダ補完処理等のアプリケーション処理をした後、再度、オリジン・サーバ２１に対してＳＳＬ通信を開始するようにしてもよい。さらに、オリジン・サーバ２１からのＳＳＬ通信をＷＡＰ−ＧＷ及びＪＳＰ１０において一旦終端し、ＷＡＰ−ＧＷ及びＪＳＰ１０においてTrans-coding処理等のアプリケーション処理をした後、再度、ユーザエージェントに対してＳＳＬ通信を開始するようにしてもよい。
【００３２】
以上説明したように、移動体通信事業者対応の移動端末ではコンテンツ要求リクエストに移動端末の性能や能力を示すパラメータの拡張ヘッダが添付されている。このように拡張ヘッダがコンテンツ要求リクエストに添付されていると、このリクエストに応じてコンテンツを提供するオリジンサーバは、拡張ヘッダとして添付されているパラメータを参照して、移動端末の性能や能力を十二分に生かせるコンテンツを提供することができる。また、オリジンサーバが移動端末の性能や能力を十二分に生かせるコンテンツを提供するサービスを行っていない場合は、移動体通信システム側においてＲ２Ｍ１１より取得したプロファイル情報の移動端末情報（UE-Profile）に基づいて移動端末の性能や能力を十二分に生かせるようにコンテンツを変換することができる。
【００３３】
本発明にかかる移動体通信システムにおいては、移動端末がコンテンツを取得する際に当該移動端末に関するユーザエージェントの情報、ユーザ情報（User-Profile）、セルフケア情報（Selfcare-Profile）、移動端末情報（UE-Profile）からなるプロファイル情報をＲ２Ｍ１１において生成する。このプロファイル情報はＲ２Ｍ１１からＪＳＰ１０ｂに供給される。このため、ＷＡＰ／ＭＭＳ対応の移動端末が送出したコンテンツ要求リクエストにＪＳＰ１０ｂにおいてプロファイル情報に基づいて移動端末の性能や能力を示すパラメータの拡張ヘッダを添付することができる。また、ＪＳＰ１０ｂにおいてＲ２Ｍ１１より取得したプロファイル情報の移動端末情報（UE-Profile）を参照することにより移動端末の性能や能力を十二分に生かせるように取得したコンテンツを変換することができる。これにより、ＷＡＰ／ＭＭＳ対応の移動端末であっても移動体通信事業者が提供している独自プロトコルに基づく独自のサービスを受けることができ、移動端末の有する性能や能力を十二分に生かしてコンテンツを取得することができるようになる。さらに、プロファイル情報はＲ２Ｍ１１において一元管理されることから、拡張ヘッダが添付されていない場合にプロファイル情報を構成しているいずれかの情報を必要とするサーバの負担を軽減することができる。
【産業上の利用可能性】
【００３４】
以上の説明では、移動体通信システムにおける移動端末がインターネット上からコンテンツを取得するものとしたが、これに限るものではなくあるネットワークにおける通信端末が他のネットワークからコンテンツを取得する際にも適用することができる。
【図面の簡単な説明】
【００３５】
【図１】本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
【図２】本発明にかかる移動体通信システムにおいて実行されるＷＡＰプロトコルの基本シーケンスを示す図である。
【図３】本発明の移動体通信システムにおいて特徴的な構成であるＷＡＰ−ＧＷ及びＪＳＰとＲ２Ｍの詳細構成を移動体通信システムの概要と共に示す図である。
【図４】本発明にかかる移動体通信システムにおいてＨＴＴＰの拡張ヘッダを補完する動作イメージを示すシーケンス図である。
【図５】本発明にかかる移動体通信システムにおけるＪＳＰにおいて行われる拡張ヘッダの補完処理のフローチャートである。
【図６】本発明にかかる移動体通信システムにおいてHTTP Reqの拡張ヘッダに添付される対象とされるヘッダパラメータの一例の一覧表を示す図である。
【符号の説明】
【００３６】
１  移動端末（ＵＥ）
２  無線基地局（ＢＴＳ）
３  無線基地局制御装置（ＲＮＣ）
４  移動通信交換局（ＭＳＣ）
５  ゲートウエイ（ＳＧＳＮ）
６  ゲートウエイ（ＧＧＳＮ）
１０  ノードおよびアプリケーションゲートウエイ（ＷＡＰ−ＧＷ及びＪＳＰ）
１０ａ  ＷＡＰ−ＧＷ
１０ｂ  ＪＳＰ
１１  情報管理サーバ（Ｒ２Ｍ）
１１ａ  ＲＡＤＩＵＳサーバ
１２  ディレクトリサーバ（ＤＩＲ）
１３  ディレクトリ・レプリカ・サーバ（ＤＲＳ）
１４  ウェブ・ゲートウエイ（ＷＧＷ）
２０  インターネット
２１  オリジン・サーバ
２２  サーバ（Portal）
３０  RAD Master
３１  Selfcare DB
３２  CC/PP Repository
３３  プロファイル部（Profile）
４０  Profile Repository
【図１】
2005277526.tif 000003
【図２】
2005277526.tif 000004
【図３】
2005277526.tif 000005
【図４】
2005277526.tif 000006
【図５】
2005277526.tif 000007
【図６】
2005277526.tif 000008