(57)【要約】【課題】  クライアント・サーバの処理量を増加させることなくクライアント・サーバが必要とする移動端末に関するプロファイル情報を参照できるようにする。【解決手段】  各移動端末に関して管理コンソール２４から事業者独自の端末情報からなる差分プロファイル情報をCC/PP Repository３３ｂに登録する。各移動端末の製造業者が構築しているデータベース（Profile Repository２３）から各移動端末に関するオリジナルプロファイル情報を取得してCC/PP Repository３３ｂに格納する。CC/PP Repository３３ｂでは、クライアント・サーバ２５から移動端末に関するプロファイル情報が要求された際に、当該移動端末に関する前記差分プロファイル情報と前記オリジナルプロファイル情報とをマージしたプロファイル情報を返送する。【選択図】  図４
2006067324.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）、２は無線アクセスネットワークとコアネットワーク（パケット網）とのゲートウエイ（ＳＧＳＮ：Serving GPRS Support Node）、３はコアネットワーク（パケット網）とインターネットなどのＩＰネットワークとのゲートウエイ（ＧＧＳＮ：Gateway GPRS Support Node）、４はサービスごとのユーザのアクセス権限のチェックを行う移動通信システムの加入者認証機構（ＪＳＲ：J-SKY RADIUS）、５は移動端末１との間でショートメッセージの送受信を行なうＳＭＳＣ（Short Message Service Center）、６はＧＧＳＮ３とＪＳＲ４、ＪＳＰ７、Ｒ２Ｍ８、及び、ＰＰＧ１０との間の線路を通るパケットを分岐器により捕えて、そのパケット量を基に課金情報の記述レコード（ＣＤＲ：Charging Data Record）を出力するパケット課金記録情報収集装置（ＰＣＮ：Packet Charging Node）である。
【００１０】
また、７はＷＡＰとＨＴＴＰ（HyperText Transfer Protocol ）とを変換すると共に、受け付けたリクエストを適切な形式に変換して後段に送出するなどしてＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うプロキシサーバであるアプリケーションゲートウエイ（ＪＳＰ：J-Phone Scheme Proxy）である。なお、ＨＴＴＰは、ウェブブラウザとウェブサーバ間において、ＨＴＭＬ（Hyper Text Markup Language ）ファイルなどの文書を転送するために用いられるアプリケーションレベルのプロトコルである。８はＲＡＤＩＵＳセッション管理を行うＲＡＤＩＵＳサーバを備え、ＷＡＰ／ＭＭＳサービス加入者がウェブ（Web）やメール（Mail）等のサービスを利用する際に必要なユーザ情報や移動端末の能力に関する端末情報（UE-Profile）等のプロファイル情報を一元管理し、クライアント・サーバからの要求に応じて要求されたプロファイル情報を提供する本発明にかかる情報管理サーバ装置（Ｒ２Ｍ：RADIUS & Repository Manager）、９はディレクトリ・レプリカ・サーバ（ＤＲＳ：Directory Replica Server）であり、一定間隔（例えば、１分間隔）でディレクトリ・サーバ（ＤＩＲ：Directory Server）から加入者情報をローカルにコピーして維持することにより、照会要求に対して加入者情報を提供する。これにより、ＤＩＲの障害時においても、サービス（オーダー・エントリーを除く）を継続して提供することができる。
【００１１】
さらに、１０はWAP PushやMail通知の配信などのプッシュサービスを実行するノード（ＰＰＧ：Push Proxy Gateway）、１１はポータル・サーバ（ＰＴＬ：Portal Server）であり、外部サーバからの各種統計情報の収集と、統計情報に基づいてメニューソートを行ったり、移動体通信事業者オフィシャルメニューの作成を行う。 また、移動端末からのリクエストに対して、オフィシャルメニューを提供する。１２はＪＳＰ７に接続され、移動通信システムのコアネットワークとインターネット１９とを接続するウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）である。図示するようにインターネット１９には、移動端末１等に提供されるリソースが存在するかあるいは生成されるサーバであるコンテンツ・プロバイダ（ＣＰ）２１，２２が接続されている。１３はＤＢシンクロナイザ（DB-Synchronizer）であって、ＵＰＡ（User Profile Aggregator）、ＵＰＳ（User Profile Synchronizer）、ＳＰＭ（Service Provider Manager）からなり、ユーザ世代移行時のデータ同期や、ＣＰ２１，２２が提供するサービスに関する情報などを管理する。１４はＣＰ２１，２２から受信するコンテンツのサイズチェックや、文字コード変換などを行うノード（Ｗｔｒａｎｓ：Web Transcoder）、１５はＪａｖａアプリケーションの管理を行うノード（ＭＡＣＳ：MIDlet Access Control Server）である。
【００１２】
さらにまた、１６はディジタル著作権管理を行うサーバ（ＤＲＭ：Digital Rights Management）であり、ＯＭＡ（Open Mobile Alliance）の規格に準拠した電子著作権保護の考えを取り入れ、Forward LockやSeparate Deliveryなどのダウンロード方式を採用している。１７はＭＭＳ（Multimedia Messaging Service）を提供するためのメールサーバ（ＭＭＳ−Ｒ：Multimedia Messaging Service-Relay）であり、各種Reference Pointを持ち、ＭＭ（Multimedia Message）を中継する。１８はネットワークの設定など、移動端末のセットアップに必要な情報を、ＯＴＡ（Over The Air）を介して提供するノード（ＣＯＰ：Client OTA Provisioning）、１９はインターネットでありＣＰ２１，２２等が接続されている。ＲｅｐｏＤＢ（Repository Database）２０は、移動端末の製造業者などが構築している移動端末データベースであり、移動端末の性能情報などが保存されている。後述するプロファイル格納部に相当する。コンテンツ・プロバイダ（ＣＰ）２１，２２はインターネット１９に接続され、移動端末１等に提供されるリソースが存在するか、あるいは生成されるサーバであり、オリジン・サーバ（Origin Server）とも云われる。
【００１３】
なお、Ｒ２Ｍ８はＧＧＳＮ３とのRADIUS Accountingプロトコルの終端であるＲＡＤＩＵＳサーバを備えている。このＲＡＤＩＵＳサーバには、ユーザ毎のセッション管理およびセッションログの生成などの機能も実装されている。ユーザ毎のセッション管理情報はアクセス毎のクライアント特定のために必要不可欠な情報であり、セッション管理にはＪＳＰ７へのReplication機能や他ノードからの問い合わせに応答する機能が実装される。
また、図１においては、ＪＳＰ７とＰＰＧ１０は、いずれも、１個しか図示していないが、これらは処理を分散することができるように、それぞれ複数個設けるようにすると共にロードバランサーを設けて処理を振り分けるようにしてもよい。また、ＪＳＰ７では該当ユーザのセッション管理情報がＲＡＤＩＵＳサーバから複製（Replication）され、複製を保持している間のみ移動端末１におけるユーザエージェントからのリクエストが有効となるように制御している。
【００１４】
次に、図１に示す移動通信システムにおいて移動端末（ＵＥ）上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が無料のＷＥＢコンテンツを取得する際のシーケンスを図２に示す。このシーケンスでは、移動端末（ＵＥ）１がインターネット１９に接続されているＣＰ２１（２２）からコンテンツを取得するシーケンスとされている。
移動端末１がＣＰ２１（２２）からコンテンツを取得する際には、まず、プロキシ・サーバとして機能するＪＳＰ７との間のＴＣＰセッションを確立し、次いで、コンテンツの取得要求（ＨＴＴＰリクエスト）をＪＳＰ７に送り、ＪＳＰ７がコンテンツの取得要求を中継することにより、インターネット１９上のＣＰ２１（２２）から要求されたコンテンツを取得する。そして、このコンテンツを取得要求を行った移動端末１に提供し、ＴＣＰセッションを開放する。これにより、移動端末１が所望のコンテンツを取得できるようにしている。
【００１５】
具体的に図２を参照して説明すると、移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）がＷＥＢコンテンツを取得する際に、ＴＣＰ（Transmission Control Protocol）セッションを確立するための接続要求［1) Activate PDP Context Request］をＳＧＳＮ２に送出する。ＳＧＳＮ２は、接続要求［1) Activate PDP Context Request］を受信すると、移動端末（ＵＥ）１の加入者に割り当てられた国際識別番号（ＩＭＳＩ：International Mobile Subscriber Identity）及び移動端末（ＵＥ）１の電話番号（ＭＳＩＳＤＮ：Mobile Station ISDN number）が添付された接続要求［2) Create PDP Context Req］を生成して、ＧＧＳＮ３に送出する。この場合、移動端末１がＷＡＰ／ＭＭＳ規格の移動端末であって接続要求［Activate PDP-Context Req］に移動端末（ＵＥ）１の加入者に割り当てられたＩＭＳＩしか添付されていない場合は、ＳＧＳＮ２はこのＩＭＳＩにより、図示しないホームロケーションレジスタ（ＨＬＲ）から移動端末（ＵＥ）１の電話番号（ＭＳＩＳＤＮ）を取得する。
【００１６】
ＧＧＳＮ３は、接続要求［2) Create PDP Context Req］を受信すると、移動端末（ＵＥ）１のアクセス権限のチェックを行うためにＪＳＲ４に対して認証要求［3) RADIUS Access Req］を送出し、ＪＳＲ４から認証成功［4) RADIUS Access Accept］が返送されると、移動端末（ＵＥ）１にＩＰアドレスを払い出して、Ｒ２Ｍ８に対してRADIUSアカウンティングリクエスト［5) RADIUS  Accounting-start Req］を送出する。このRADIUSアカウンティングリクエスト［5) RADIUS  Accounting-start Req］には、移動端末（ＵＥ）１のＭＳＩＳＤＮあるいはＩＭＳＩ、払い出されたＩＰアドレスなどが添付されている。Ｒ２Ｍ８は、RADIUSアカウンティングリクエスト［5) RADIUS Accounting-start Req］を受信すると、ユーザごとのセッション管理情報（RADIUS Accounting-Profile）やプロファイル情報を作成して、ＩＰアドレスをキーに一括して内部メモリにキャッシュする。このキャッシュされた情報は該当するセッションが開放されるまでの間保持される。
【００１７】
また、Ｒ２Ｍ８は、ＪＳＰ７にこのセッション管理情報をリプリケーションさせるために、リプリケーション情報［6) Replication RADIUS Accounting Profile］を送出する。ＪＳＰ７は、リプリケーション情報［6) Replication RADIUS Accounting Profile］を受信すると、内部にこのセッション管理情報の複製（レプリカ）を保持する。ここで、保持するセッション管理情報には、移動端末（ＵＥ）１のＩＰアドレス、ＭＳＩＳＤＮ、ＩＭＳＩが含まれている。ＪＳＰ７は、このセッション管理情報の複製（レプリカ）を保持すると、セッション情報がリプリケーションされたことの通知［7) Replication RADIUS Accounting Profile Res］をＲ２Ｍ８に送出する。
【００１８】
Ｒ２Ｍ８は、通知［7) Replication RADIUS Accounting Profile Res］を受信すると、ＧＧＳＮ３にＴＣＰセッションの接続準備が整ったことの通知［8) RADIUS Accounting-start Res］を送出する。ＧＧＳＮ３は、移動端末（ＵＥ）１に対して払い出されたＩＰアドレスが添付された接続準備通知［9) Create PDP Context Res］をＳＧＳＮ２に送出する。次いでＳＧＳＮ２は、移動端末（ＵＥ）１に対して接続準備通知［10) Activate PDP Context Res ］を送出する。これによって、移動端末（ＵＥ）１とＪＳＰ７との間でＴＣＰハンドシェイクが行われてＴＣＰセッションが確立される。
【００１９】
移動端末（ＵＥ）１とＪＳＰ７との間でＴＣＰセッションが確立すると、移動端末（ＵＥ）１は、ＣＰ（オリジン・サーバ）２１（２２）からコンテンツを取得するためにＨＴＴＰリクエスト［11) HTTP Req］をＪＳＰ７に送出する。ＪＳＰ７は、ＨＴＴＰリクエスト［11) HTTP Req］を受信すると、内部に保持しているセッション管理情報の複製（レプリカ）を参照して、対応するセッション管理情報が存在するとともに、加入者情報が一致する場合にのみ、そのＨＴＴＰリクエスト［11) HTTP Req］を受け付ける。このＨＴＴＰリクエスト［11) HTTP Req］のヘッダには、ＧＧＳＮ３から払い出された移動端末（ＵＥ）１のＩＰアドレス、コンテンツを取得する相手先であるＣＰ（オリジン・サーバ）２１（２２）のＵＲＩ（Request-URI）、ユーザエージェント情報（UA）、ユーザエージェントのプロファイル情報（UA-Profile）が含まれている。
【００２０】
ＪＳＰ７は、ＨＴＴＰリクエスト［11) HTTP Req］を受信すると、この移動端末（ＵＥ）１がコンテンツの取得に必要なプロファイル情報をＲ２Ｍ８から取得するためにプロファイル取得リクエスト［12) Profile get Req］を送出する。Ｒ２Ｍ８は、プロファイル取得リクエスト［12) Profile get Req」に添付されているＩＰアドレス、ユーザエージェント情報（UA）、ユーザエージェントのプロファイル情報（UA-Profile）に基づいて、内部にキャッシュされている移動端末（ＵＥ）１のプロファイル情報を取得して、取得したプロファイル情報の返送通知［13) Profile get Response］をＪＳＰ７に送出する。この際の、移動端末１における端末情報（UE-Profile）を問い合わせるキー（問い合わせキー）として、ＩＰアドレスとユーザエージェント情報（UA）あるいは移動端末の製造業者が構築しているプロファイル格納部（Profile Repository）を示すＵＲＬ（UA-Prof）とをＲ２Ｍ８に送る。Ｒ２Ｍ８は問い合わせキーに該当する移動端末１に関する端末情報（UE-Profile）を取得してＪＳＰ７に返送する。なお、各移動端末に関する端末情報（UE-Profile）は、プロファイル格納部（Profile Repository）から取得したオリジナルプロファイル情報と移動体通信事業者が登録した差分プロファイル情報とからなりＲ２Ｍ８に一元管理されている。
【００２１】
ＪＳＰ７は、Ｒ２Ｍ８から通知された移動端末（ＵＥ）１のプロファイル情報に含まれている端末情報（UE-Profile）に基づいて不足しているパラメータを、移動端末（ＵＥ）から受信したＨＴＴＰリクエスト［11) HTTP Req］の拡張ヘッダに補完して、ＷＧＷ１２を介して当該ヘッダにおけるRequest-URIで特定されるＣＰ（オリジン・サーバ）２１（２２）にＨＴＴＰリクエスト［14) HTTP Req］を送出する。ところで、ＷＡＰ／ＭＭＳ対応の移動端末（ＵＥ）１では、端末情報（UE-Profile）のパラメータを添付するための拡張ヘッダを持つＨＴＴＰリクエスト［11) HTTP Req］の送出が困難である。しかし、上記したようにＪＳＰ７がＨＴＴＰリクエスト［11) HTTP Req］の拡張ヘッダに端末情報（UE-Profile）のパラメータを補完することができる。これにより、ＣＰ（オリジン・サーバ）２１（２２）では、移動端末（ＵＥ）１がＷＡＰ／ＭＭＳ対応の移動端末かどうかによらず、ＨＴＴＰリクエスト［14) HTTP Req］の拡張ヘッダに添付されている端末情報（UE-Profile）のパラメータを参照することにより、移動端末（ＵＥ）１の性能や能力を知ることができる。そして、ＣＰ（オリジン・サーバ）２１（２２）は、移動端末（ＵＥ）の性能や能力に適合するコンテンツを選択あるいは生成して、そのコンテンツをＨＴＴＰレスポンス［15) HTTP Res］によってＪＳＰ７に返送する。
【００２２】
ＪＳＰ７は、ＨＴＴＰレスポンス［15) HTTP Res］によってＣＰ（オリジン・サーバ）２１（２２）から取得したコンテンツをＨＴＴＰレスポンス［16) HTTP Res］として移動端末（ＵＥ）１に返送する。ここで、ＣＰ（オリジン・サーバ）２１（２２）によっては、ＨＴＴＰリクエスト［14) HTTP Req］の拡張ヘッダを参照することなくコンテンツを返送するサーバがある。この場合、ＪＳＰ７が取得したコンテンツは、必ずしも移動端末（ＵＥ）１の性能や能力に適合したものではない。そのような場合には、ＪＳＰ７は、移動端末（ＵＥ）１の端末情報（UE-Profile）に基づいて、その移動端末（ＵＥ）１の性能や能力に適合するように、コンテンツの文字変換やファイル形式変換などを行って、移動端末（ＵＥ）１に返送する。これにより、移動端末（ＵＥ）１の性能を十二分に発揮できるようになる。
【００２３】
移動端末（ＵＥ）１は、ＨＴＴＰレスポンス［16) HTTP Res］によってコンテンツを取得すると、ＪＳＰ７との通信を終了させるために、ＴＣＰセッションの開放要求［17) Deactivate PDP Context Request］をＳＧＳＮ２に送出する。ＳＧＳＮ２は、ＧＧＳＮ３に通信開放要求［18) Delete PDP Context Request］を送出し、これを受けたＧＧＳＮ３は、RADIUSアカウンティングストップリクエスト［19) RADIUS Accounting-stop Request］をＲ２Ｍ８に送出する。これを受信したＲ２Ｍ８は、内部に保持していた該当セッション管理情報を破棄して、RADIUSアカウンティングストップレスポンス［「20) RADIUS Accounting-stop Response］をＧＧＳＮ３に送出する。ＧＧＳＮ３は、通信開放準備通知［21) Delete PDP Context Response］をＳＧＳＮ２に送出し、次いでＳＧＳＮ２は、通信開放準備通知［22) Delete PDP Context Response］を移動端末（ＵＥ）１に送出する。こうして移動端末（ＵＥ）１とＪＳＰ７との間のＴＣＰセッションが開放され通信が終了する。
【００２４】
次に、本発明の情報管理サーバ装置における端末情報（UE-Profile）の管理、および、他ノードへの端末情報（UE-Profile）を提供する詳細構成を図３に示す。
図３において、Ｒ２Ｍシステム８は図１におけるＲ２Ｍ８であり、Ｒ２Ｍシステム８はＲＡＤＩＵＳサーバ（ＲＡＤ−Ｄ）３１と、各移動端末に関するプロファイル情報をキャッシュしているＲ２Ｍ部３２と、各移動端末に関するプロファイル情報を保管しているＰＤＢ３３とを備えている。Ｒ２Ｍシステム８におけるＲＡＤＩＵＳサーバ（ＲＡＤ−Ｄ）３１には管理している各移動端末毎のセッション情報であるセッション管理情報を保持しており、ＧＧＳＮ３からのRADIUSアカウンティングリクエスト［RADIUS Accouting-start Req］を受けた際に、保持している該当する移動端末１のセッション管理情報をＪＳＰ７にリプリケートしている。
【００２５】
ＰＤＢ３３は、移動端末１の加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤ（ＵＩＤ：User ID）等の通知にユーザが同意したか否か、また規制対象とするＵＲＬ（Uniform Resource Locators）をユーザが持つか否かなどのユーザの設定に関する固有情報からなるセルフケアプロファイルを保持するセルフケアデータベース（Selfcare DB）３３ａと、移動端末１の機種名および性能や能力を表すパラメータを機種毎に保持しているデータベースである端末情報格納部（CC/PP Repository）３３ｂとを備えている。さらに、Ｒ２Ｍ部３２は、セッション中のユーザにかかるセッション管理情報（Acct-Profile）、ユーザ情報（User-Profile）、セルフケア情報（Selfcare-Profile）、端末情報（UE-Profile）からなるプロファイル情報を作成してセッションが継続している間はメモリ３２ａ上にキャッシュしている。なお、ＤＲＳ９は一定間隔（例えば、１分間隔）でディレクトリ・サーバ（ＤＩＲ：Directory Server）から加入者情報をローカルにコピーして維持することにより、照会要求に対して加入者情報を提供するディレクトリ・レプリカ・サーバである。また、プロファイル格納部（Profile Repository）２３は機種情報や性能を示す情報からなる端末情報（UE-Profile）が格納されている移動端末製造業者が構築しているデータベースであり、図１に示す移動端末データベース（Repo DB）２０に相当している。
【００２６】
図３に示す構成において、前述したように移動端末１がＣＰ２１／２２からコンテンツを取得する際に、移動端末１のユーザエージェントからの通信接続要求に応じてＧＧＳＮ３からRADIUSアカウンティングリクエスト［RADIUS Accounting-start Req］が送出される。このリクエストを受信したＲＡＤＩＵＳサーバ３１は、リクエストの属性（Attribute）情報をセッション管理情報として保管する。そして、ＧＧＳＮ３が移動端末１に払い出したＩＰアドレス、移動端末１のＭＳＩＳＤＮ（Mobile Station ISDN number：電話番号）および携帯電話の加入者に与えられた国際識別番号であるＩＭＳＩ（International Mobile Subscriber Identity）等からなるセッション管理情報をＪＳＰ７にリプリケーションする。同時にＲ２Ｍ部３２は、RADIUSアカウンティングリクエスト［RADIUS Accounting-start Req］を送出した移動端末１に関するプロファイル情報の作成を開始する。すなわち、Ｒ２Ｍ部３２はセルフケアデータベース（Selfcare DB）３３ａにアクセスして当該移動端末１を使用しているユーザが設定した固有情報からなるセルフケア情報（Selfcare-Profile）を取得する。また、Ｒ２Ｍ部３２は端末情報格納部（CC/PP Repository）３３ｂにアクセスして当該移動端末１の機種名および性能や能力を表すパラメータからなる端末情報（UE-Profile）を取得する。この場合、該当するエントリが端末情報格納部（CC/PP Repository）３３ｂに存在しない場合は、プロファイル格納部（Profile Repository）２３へ問い合わせを行い端末情報格納部（CC/PP Repository）３３ｂに端末情報（UE-Profile）を保存するようにする。また、プロファイル格納部（Profile Repository）２３へ問い合わせできない場合は予め設定されている端末情報（UE-Profile）のデフォルト値をＲ２Ｍ部３２へ返すようにする。このデフォルト値は、いずれの機種でも最低限サポートしている共通の端末情報（UE-Profile）とされる。
【００２７】
さらに、Ｒ２Ｍ部３２はＤＲＳ９にアクセスして当該移動端末１を使用しているユーザのユーザ情報（User-Profile）を取得する。このユーザ情報は、ＩＭＳＩ、ＭＳＩＳＤＮおよび加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤから構成されている。そして、収集された当該移動端末１に関するセルフケア情報（Selfcare-Profile）、端末情報（UE-Profile）、ユーザ情報（User-Profile）とを一つにまとめて該当する移動端末１に関するプロファイル情報を作成してメモリ３２ａにキャッシュする。
【００２８】
そして、移動端末１上のユーザエージェントとＪＳＰ７との間でＴＣＰセッションが確立されると、上述したようにユーザエージェントからＨＴＴＰリクエストが送出される。このＨＴＴＰリクエストがＪＳＰ７で受信され、ＨＴＴＰリクエストにおけるＭＳＩＳＤＮあるいはＩＭＳＩに該当するプロファイル情報をＲ２Ｍ部３２にアクセスして取得する（Get Profile Including UE-Profile）。そして、ＨＴＴＰリクエストの拡張ヘッダにおいて必要とされる端末情報（UE-Profile）が不足している場合は、ＪＳＰ７は取得したプロファイル情報の端末情報（UE-Profile）に基づいて不足しているパラメータをＨＴＴＰリクエストの拡張ヘッダに補完する。この場合、ＷＡＰ／ＭＭＳ対応の移動端末のユーザエージェントにおいては端末情報（UE-Profile）のパラメータの拡張ヘッダが添付されたＨＴＴＰリクエストの送出が困難であることから、ＷＡＰ／ＭＭＳ対応の移動端末のユーザエージェントから送出されたＨＴＴＰリクエストには端末情報（UE-Profile）のパラメータが添付された拡張ヘッダが補完されるようになる。これにより、ＨＴＴＰリクエストを送出した移動端末の種類にかかわらず、移動通信システムからは今までと同様の内容の拡張ヘッダが添付されたＨＴＴＰリクエストをインターネットへ向けて送出することができるようになる。従って、コンテンツを要求されたＣＰ２１／２２は、ＷＡＰ／ＭＭＳ対応の移動端末であっても従来の移動端末と同様にして要求されたコンテンツを返送することが可能となる。
【００２９】
このようにして拡張ヘッダが必要に応じて補完されたＨＴＴＰリクエストはＪＳＰ７から送出され、そのRequest URIで特定される相手先のＣＰ２１／２２は、拡張ヘッダを参照して端末情報（UE-Profile）のパラメータに適合するコンテンツを選択あるいは生成して、そのコンテンツを返送するＨＴＴＰレスポンスをＪＳＰ７に向けて送出する。ただし、ＣＰ２１／２２によっては拡張ヘッダを参照することなくコンテンツを返送するサーバも存在し、ＪＳＰ７が取得したコンテンツは必ずしもコンテンツを要求した移動端末１の性能や能力に適合するものとはされていない。そこで、ＨＴＴＰレスポンスを受信したＪＳＰ７はコンテンツを要求した移動端末１に関するプロファイル情報の端末情報（UE-Profile）を参照して、移動端末１の性能や能力に適合するように変換処理している。この変換処理は、コンテンツを移動端末１で正しく表示させるために行われ、コンテンツを移動端末１に合った形式に変換・編集または制限して正しく表示させる変換処理を行っている。
【００３０】
移動端末１に合った形式になるよう変換処理が行われたコンテンツは、ＪＳＰ７から移動端末１に向けてＨＴＴＰレスポンスによりコンテンツが送出される。これにより、移動端末１でコンテンツが取得され、例えばユーザエージェントであるウェブブラウザに取得されたコンテンツが表示される。この場合、コンテンツが変換処理されていることから移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。これにより、移動体通信事業者対応の移動端末でもＷＡＰ／ＭＭＳ対応の移動端末でも同様に、移動端末１の有する性能や能力を十二分に生かしてコンテンツを表示することができるようになる。
【００３１】
次に、ＰＤＢ３３における端末情報格納部（CC/PP Repository）３３ｂの内部構造である端末情報管理イメージを図４に示す。
ＰＤＢ３３では移動端末の性能をサーバ側で把握するため、各移動端末の製造業者が構築しているデータベースであるプロファイル格納部（Profile Repository）２３から取得した標準化団体の提示する仕様に準拠したオリジナルプロファイル情報と、移動体通信事業者独自に定義する差分プロファイル情報とが各移動端末の機種毎に別個に管理されている。差分プロファイル情報は、管理コンソール２４から各移動端末の機種毎に登録することができ、例えば携帯電話向けの音楽データフォーマットであるＳＭＡＦ（Synthetic music Mobile Application Format ）や、音声やベクターグラフィックスのアニメーションを組み合わせて作成されたフラッシュコンテンツ（Flash）、ディジタル著作権管理（ＤＲＭ)などに対応しているかの端末情報とされる。このオリジナルプロファイル情報と差分プロファイル情報とが端末情報（UE-Profile）としてＰＤＢ３３で管理される。
【００３２】
ここで、端末情報（UE-Profile）のデータ構造の一例を図５に示す。
図５に示すように、端末情報（UE-Profile）は、キー情報とオリジナルプロファイル情報（UE-Profile オリジナル）と差分プロファイル情報（UE-Profile 差分）とからなっている。キー情報は、例えば「VF/4.2/V601N/」とされているユーザエージェント（User-Agent）引当キー、および、例えば「http://w3dev.de/uaprof_repository/ABC_21i.rdf」とされている移動端末の製造業者が構築しているプロファイル格納部（Profile Repository）を示すＵＲＬ（UA-Prof）とされている。このキー情報は、端末情報（UE-Profile）を要求する際の問い合わせキーになると共に、要求された際の検索キーになる。キー情報のうちのユーザエージェント（User-Agent）引当キーは、機種を一意に示す英数文字の組み合わせで構成され、例えば「VF/4.2/V601N/」とされる。また、ＵＲＬ（UA-Prof）は移動端末の製造業者が構築しているプロファイル格納部（Profile Repository）２３を示すＵＲＬである。オリジナルプロファイル情報と差分プロファイル情報とは、ハードウェアの仕様（Hardware Platform）とソフトウェアの仕様（Software Platform）等に分かれており、図示するようにオリジナルプロファイル情報と差分プロファイル情報とがマージされて端末情報（UE-Profile）とされている。この端末情報（UE-Profile）のデータは、移動端末のスクリーンサイズ、ピクセル上の縦横比、サポートしているコンテンツタイプやキャラクタセット等の情報とされる。
【００３３】
図４に戻り、ＪＳＰ７，ＰＰＧ１０，ＭＭＳ−Ｒ１７等のサーバが端末情報（UE-Profile）を要求するクライアント・サーバ２５である。これらのクライアント・サーバ２５から端末情報（UE-Profile）がＰＤＢ３３に要求された場合は、図示するように該当する移動端末のオリジナルプロファイル情報と差分プロファイル情報とをマージしたマージファイルを端末情報（UE-Profile）として返すようにする。この時の該当する端末情報（UE-Profile）の問い合わせキーとしてユーザエージェント（User-Agent）引当キーまたはＵＲＬ（UA-Prof）を使用することができる。この問い合わせキーに基づいてＰＤＢ３３は検索する際に、問い合わせキーがユーザエージェント（User-Agent）引当キーの場合は前方最長一致検索とされ、問い合わせキーがＵＲＬ（UA-Prof）の場合は、完全一致検索とされる。そして、問い合わせキーに該当する端末情報（UE-Profile）が存在しない場合、予め用意されているいずれの機種でも最低限サポートしているデフォルトの共通の端末情報（UE-Profile）を提供する。
【００３４】
ここで、クライアント・サーバ２５がＰＤＢ３３から端末情報（UE-Profile）を取得する際のシーケンス図を図６に、この場合にＰＤＢ３３が行う処理のフローチャートを図７に示す。
これらの図に示すように、クライアント・サーバ２５が端末情報（UE-Profile）の取得要求のＨＴＴＰリクエストをＰＤＢ３３に送出すると、このＨＴＴＰリクエストを受けたＰＤＢ３３はクライアント・サーバ２５が端末情報（UE-Profile）の取得要求を受けたと判断して（ステップＳ１０）、ＨＴＴＰリクエストにおけるユーザエージェント（User-Agent）ヘッダパラメータから取得したユーザエージェント（User-Agent）引当キーを問い合わせキーとして端末情報格納部（CC/PP Repository）３３ｂから該当する移動端末の端末情報（UE-Profile）を検索する（ステップＳ１１）。ここで、端末情報格納部（CC/PP Repository）３３ｂに問い合わせキーに合致する端末情報（UE-Profile）が存在しているか否かが判断され（ステップＳ１２）、存在すると判断された場合はオリジナルプロファイル情報（UE-Profile オリジナル）と差分プロファイル情報（UE-Profile 差分）とをマージし（ステップＳ１３）、ＰＢＤ３３はクライアント・サーバ２５にマージした端末情報（UE-Profile）を送出する（ステップＳ１４）。
【００３５】
また、問い合わせキーに合致する端末情報（UE-Profile）が存在しないと判断された場合は、プロファイル格納部（Profile Repository）２３に移動端末の端末情報（UE-Profile）を要求するＨＴＴＰリクエストを送り、プロファイル格納部（Profile Repository）２３から移動端末の端末情報（UE-Profile）を取得する（ステップＳ１５）。そして、プロファイル格納部（Profile Repository）２３から移動端末の端末情報（UE-Profile）を取得できたと判断された場合（ステップＳ１６）は、取得した端末情報（UE-Profile）をオリジナルプロファイル情報（UE-Profile オリジナル）として端末情報格納部（CC/PP Repository）３３ｂに登録する（ステップＳ１７）。次いで、上記と同様にオリジナルプロファイル情報（UE-Profile オリジナル）と差分プロファイル情報（UE-Profile 差分）とをマージし（ステップＳ１３）、ＰＢＤ３３はマージした端末情報（UE-Profile）をクライアント・サーバ２５に送出する（ステップＳ１４）。また、プロファイル格納部（Profile Repository）２３がダウン等して移動端末の端末情報（UE-Profile）を取得できないと判断された場合（ステップＳ１６）は、ＰＤＢ３３に予め用意されているデフォルトの共通の端末情報（UE-Profile）をクライアント・サーバ２５に送出する（ステップＳ１８）。
【００３６】
各移動端末の端末情報（UE-Profile）のユーザエージェント（User-Agent）の引当キー情報および移動体通信事業者が独自に定義する差分プロファイル情報とは、管理コンソール２４から端末情報格納部（CC/PP Repository）３３ｂに登録される。また、デフォルトの共通の端末情報（UE-Profile）は予めデフォルト端末情報（UE-Profile）のファイルが作成されて、端末情報格納部（CC/PP Repository）３３ｂに登録される。なお、移動端末ごとのユーザエージェント（User-Agent）の引当キー情報および移動体通信事業者が独自に定義する差分プロファイル情報などは新機種発売時や、移動機情報に変更が発生した場合などに、予め端末情報格納部（CC/PP Repository）３３ｂに登録しておく必要がある。
なお、クライアント・サーバ２５から端末情報（UE-Profile）が要求された際に、クライアント・サーバ毎に、プロファイル情報（UE-Profile）に含まれる項目を当該クライアント・サーバが必要とする項目だけとして提供するようにしてもよい。また、プロファイル情報の２種類の問い合わせキーに応じて提供するプロファイル情報を変更するようにしてもよい。
【００３７】
上記説明したように、本発明の情報管理サーバ装置を構成するＰＤＢ３３は、各移動端末に関して管理コンソール２４から登録された事業者独自の端末情報からなる差分プロファイル情報と、各移動端末の製造業者が構築しているプロファイル格納部（Profile Repository）２３から取得した各移動端末に関する端末情報からなるオリジナルプロファイル情報とが格納されている端末情報格納部（CC/PP Repository）３３ｂを有し、クライアント・サーバ２５から移動端末に関するプロファイル情報が要求された際に、当該移動端末に関する差分プロファイル情報とオリジナルプロファイル情報とをマージしたプロファイル情報を提供するようにしている。このように、差分プロファイル情報とオリジナルプロファイル情報とを分けて一元管理しているので、それぞれのプロファイル情報を独立して変更することができ、将来に仕様が拡張された際には該当するプロファイル情報を個別に変更することができることから、その対応を容易とすることができる。また、プロファイル情報を提供するクライアント・サーバ２５毎に、プロファイル情報に含まれる項目を当該クライアント・サーバが必要とする項目だけとして提供することができる。さらに、プロファイル情報の問い合わせキーに応じて提供するプロファイル情報を柔軟に変更することができるようになる。
【産業上の利用可能性】
【００３８】
以上説明したように、移動通信システムにおける移動端末がインターネット上からコンテンツを取得する際の情報管理サーバ装置に限るものではなく、ネットワーク上の通信端末が他のネットワークからコンテンツを取得する際や、マルチメディアメッセージを送受信する際の情報管理サーバ装置にも適用することができる。
【図面の簡単な説明】
【００３９】
【図１】本発明の実施例の情報管理サーバ装置を備える移動通信システムの概略構成のブロック図である。
【図２】図１に示す移動通信システムにおいて移動端末（ＵＥ）上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が無料のＷＥＢコンテンツを取得する際のシーケンスを示す図である。
【図３】本発明の移動通信システムにおける端末情報（UE-Profile）の管理、および、他ノードへの端末情報（UE-Profile）を提供する詳細構成を示す図である。
【図４】本発明にかかる情報管理サーバ装置を構成するＰＤＢの端末情報格納部（CC/PP Repository）の内部構造である端末情報管理イメージを示す図である。
【図５】本発明にかかる情報管理サーバ装置が管理する端末情報（UE-Profile）のデータ構造の一例を示す図表である。
【図６】本発明にかかる情報管理サーバ装置においてクライアント・サーバがＰＤＢから端末情報（UE-Profile）を取得する際のシーケンス図を示す図である。
【図７】本発明にかかる情報管理サーバ装置においてクライアント・サーバがＰＤＢから端末情報（UE-Profile）を取得する際のＰＤＢが行う処理のフローチャートである。
【符号の説明】
【００４０】
１  移動端末、２  ＳＧＳＮ、３  ＧＧＳＮ、４  加入者認証機構（ＪＳＲ）、５  ＳＭＳＣ、６  パケット課金記録情報収集装置（ＰＣＮ）、７  アプリケーションゲートウエイ（ＪＳＰ）、８  情報管理サーバ装置（Ｒ２Ｍ）、９  ディレクトリ・レプリカ・サーバ（ＤＲＳ）、１０  ＰＰＧ、１１  ポータル・サーバ（ＰＴＬ）、１２  ウェブ・ゲートウエイ（ＷＧＷ）、１３  ＤＢシンクロナイザ、１４  Ｗｔｒａｎｃｅ、１５  ＭＡＣＳ、１６  ＤＲＭ、１７  メールサーバ（ＭＭＳ−Ｒ）、１８  ＣＯＰ、１９  インターネット、２０  データベース（Repo DB）、２１，２２  コンテンツ・プロバイダ（ＣＰ）、２３  プロファイル格納部（Profile Repository）、２４  管理コンソール、２５  クライアント・サーバ、３１  ＲＡＤ−Ｄ、３２  Ｒ２Ｍ部、３３  ＰＤＢ、３３ａ  セルフケアデータベース（Selfcare DB）、３３ｂ  端末情報格納部（CC/PP Repository）
【図１】
2006067324.tif 000003
【図２】
2006067324.tif 000004
【図３】
2006067324.tif 000005
【図４】
2006067324.tif 000006
【図５】
2006067324.tif 000007
【図６】
2006067324.tif 000008
【図７】
2006067324.tif 000009