JP4098763B2 - サーバ装置 - Google Patents

Description

本発明は、携帯電話などの移動端末からインターネット接続やマルチメディアメッセージの送受信を行うことができる移動通信システムにおけるサーバ装置に関する。

従来より、携帯電話などの移動端末からインターネット接続やマルチメディアメッセージの送受信を行うことができる移動通信システムが運用されている。しかしながら、従来の移動通信システムにおいては、各移動体通信事業者ごとにそれぞれ独自のプロトコルが用いられていた。
近年、いわゆる第３世代と呼ばれる携帯電話サービスが導入されつつあるが、この第３世代の移動通信システムにおいては同一の移動端末を世界中で共通に使用することができるように標準化が進められており、ＷＡＰ（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）であり、移動体通信網１０１は無線アクセスネットワークとコアネットワーク（パケット網）との間に設けられた移動体通信網であり、ＪＳＰ１０２はＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うプロキシサーバであるアプリケーションゲートウエイ（ＪＳＰ：J-Phone Scheme Proxy）であり、ＷＧＷ１０３はＪＳＰ１０２に接続され、コアネットワークとインターネット１０４とを接続するウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）であり、ＣＰ１０５はインターネット１０４に接続され、移動端末１００等に提供されるリソースが存在するか、あるいは生成されるサーバである。

このような移動通信システムにおいて移動端末１００がＣＰ１０５から有料のコンテンツを取得する際のシーケンスの一例を図８に示す。
ＣＰ１０５からコンテンツ一覧を取得した移動端末１００が所望のコンテンツを選択して、そのコンテンツの購入同意のＨＴＴＰリクエストを送出すると、このＨＴＴＰリクエストはＪＳＰ１０２、ＷＧＷ１０３を経由してＣＰ１０５において受け取られる。そして、ＣＰ１０５はダウンロード記述子（ＤＤ：Download Descriptor）を作成し、ＷＧＷ１０３、ＪＳＰ１０２を経由して移動端末１００へ送出する。移動端末１００は、取得したダウンロード記述子に含まれているコンテンツが存在しているＵＲＬに対し、そのコンテンツ要求（Object URI）を送出する。このコンテンツ要求（Object URI）は、ＪＳＰ１０２、ＷＧＷ１０３を経由して該コンテンツが存在しているＣＰ１０５に送信され、ＣＰ１０５からそのページに含まれているコンテンツが移動端末１００に送信される。移動端末１００は、全てのコンテンツを受信したときにInstall NotifyのリクエストをＪＳＰ１０２に送信し、ＪＳＰ１０２は、ＷＧＷ１０に対し課金するためにCharging Notifyを送信する。これにより、そのコンテンツに対する課金処理が行われることになる。

この場合、図７に示すような既存の移動通信システムではダウンロード記述子（ＤＤ）に含まれている対象ＵＲＬが公開されない仕様とされており、この仕様により一定以上のセキュリティを保つことができるよいうになっている。しかし、ＷＡＰ／ＭＭＳ対応の移動端末においては前記対象ＵＲＬがユーザに見えないという前提とされておらず、サービスとしてはＵＲＬが移動端末の表示部に表示されても良いものとされている。すなわち、サービスを提供する過程において前記対象ＵＲＬが移動端末の表示部に表示されてユーザに見えることが前提とされる。すると、有料コンテンツを取得する対象ＵＲＬが移動端末の表示部に表示されることになることから、このＵＲＬ情報を元にした不正なアクセスが想定されるという問題点が生じるようになる。

そこで、本発明は、サービスを提供する過程において表示されたＵＲＬ情報を元にした不正なアクセスを防止することができるサーバ装置を提供することを目的としている。

本発明は、有料コンテンツの取得要求に先立つ移動端末の前記有料コンテンツの購入同意のリクエストに対するレスポンスに、設定機能がチェックフラグをセットし、当該移動端末から有料コンテンツの取得要求があった際に、判定機能が、当該取得要求におけるチェックフラグがセットされていると判定したことを条件に、有料コンテンツの取得要求をコンテンツ・プロバイダに送出するようしたことを最も主要な特徴としている。

本発明のサーバ装置は、有料コンテンツの取得要求に先立つ移動端末の前記有料コンテンツの購入同意のリクエストに対するレスポンスに、設定機能がチェックフラグをセットし、当該移動端末から有料コンテンツの取得要求があった際に、判定機能が、当該取得要求におけるチェックフラグがセットされていると判定したことを条件に、有料コンテンツの取得要求をコンテンツ・プロバイダに送出するようにしている。そして、サービスを提供する過程において表示部に表示される対象ＵＲＬ情報を元にした不正なアクセスでは購入同意の過程を経ることなく有料コンテンツの取得要求がされることになるので、不正アクセスではチェックフラグがセットされていないようになり、当該アクセスを排除することができるようになる。これにより、サービスを提供する過程においてＵＲＬ情報が表示されても、その不正アクセスを防止することができるようになる。

本発明の実施例のサーバ装置を備える移動通信システムの構成を示すブロック図を図１に示す。
図１において、ＵＥ１は携帯電話機等の移動端末（ＵＥ：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）２０は、移動端末の製造業者などが構築している移動端末データベース（Repo DB）であり、移動端末の性能情報などが保存されている。後述するプロファイル格納部に相当する。コンテンツ・プロバイダ（ＣＰ）２１，２２はインターネット１９に接続され、移動端末１等に提供されるリソースが存在するか、あるいは生成されるサーバであり、オリジン・サーバ（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）に基づいて不足しているパラメータを、移動端末（ＵＥ）から受信したＨＴＴＰリクエスト［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］を移動端末（ＵＥ）１に送出する。こうして移動端末（ＵＥ）１とＪＳＰ７との間のＴＣＰセッションが開放され通信が終了する。

次に、本発明の実施例のサーバ装置は上述したＪＳＰ７であり、有料のＷＥＢコンテンツを取得する際に特徴的な処理を行っている。そこで、移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が有料のＷＥＢコンテンツを取得する際に、本発明の実施例のサーバ装置が実行する処理の概要を示すフローチャートを図３に示す。
図３のフローチャートにおいて、ＵＥ１から有料コンテンツをダウンロードするＨＴＴＰリクエストをＪＳＰ７が受信した際に、ＨＴＴＰリクエストにセキュリティを向上するためのスクランブルが施されていた場合は、ステップＳ１０にてスクランブルが解除される。次いで、ステップＳ１１にてユーザチェックフラグがオンされているか否かが判断される。このユーザチェックフラグは後述するが、有料コンテンツの購入同意をしたユーザであることを示すフラグである。ここで、ユーザチェックフラグがオンの場合、ステップＳ１２においてＨＴＴＰリクエストから取得したjskycmi（コンテンツ管理情報）生成時刻の有効期限のチェックを行う。このjskycmi（コンテンツ管理情報）はＪＳＰ７で設定され、その生成時刻は、当該有料コンテンツの購入同意のＨＴＴＰリクエストを受信した受信時刻とされている。生成時刻の有効期限切れの場合はエラー応答（HTTP Status Code 404 Not Found）をＪＳＰ７から移動端末（ＵＥ）１に返す。

また、有効期限に問題無い場合は、ステップＳ１３に進みＵＩＤのチェックを行う。このＵＩＤは、加入者に一意に割り当てられる移動体通信事業者独自のユーザＩＤ（ＵＩＤ：User ID）である。ＵＩＤのチェックでは、jskycmi（コンテンツ管理情報）に埋め込まれているＵＩＤと、有料コンテンツをダウンロードするＨＴＴＰリクエストから取得したユーザ情報（User-Profile）におけるＵＩＤとが一致するかどうかをチェックする。ここで、ＵＩＤが不正で一致しない場合はエラー応答（HTTP Status Code 404 Not Found）をＪＳＰ７から移動端末（ＵＥ）１に返す。また、両者のＵＩＤが一致する場合は有料コンテンツの取得要求のＨＴＴＰリクエストを有料コンテンツが存在するＣＰ（オリジン・サーバ）に送信し、有料コンテンツのダウンロードを開始する。なお、ユーザチェックフラグが付与されていない場合は、ＵＩＤおよびjskycmi（コンテンツ管理情報）生成時刻の有効期限切れの判定は行わない。ところで、ユーザチェックフラグは有料コンテンツの購入同意に対するレスポンス（後述するダウンロード記述子）を中継するＪＳＰ７がレスポンスに埋め込んでおり、この際にjskycmi（コンテンツ管理情報）生成時刻およびＵＩＤもレスポンスに埋め込んでいる。これにより、このレスポンスを元にした有料コンテンツをダウンロードするＨＴＴＰリクエストには、ユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤが埋め込まれるようになる。

なお、ステップＳ１２においてチェックするjskycmi生成時刻の有効期限において、有効期限の設定はあらかじめＪＳＰ７が有する外部設定ファイルに期限を設定することにより、有効期限が設定されている。また、チェックではＪＳＰ７がコンテンツダウンロード情報であるダウンロード記述子（ＤＤ：Download Descriptor）を要求した時刻（jskycmi生成時刻）から、有料コンテンツをダウンロードするＨＴＴＰリクエストを移動端末（ＵＥ）１から受信した時刻までの経過時間を算出し、算出した経過時間がＪＳＰ７の外部設定ファイルに設定された有効期限を超過しているかのチェックを行っている。

次に、本発明の実施例のサーバ装置を備える移動通信システムにおいて、移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が有料のＷＥＢコンテンツを取得する際のシーケンスを図４に示す。
図４に示すシーケンス図においては、有料のＷＥＢコンテンツの取得に先立つＴＣＰセッションを確立するシーケンスおよび有料のＷＥＢコンテンツの取得後のＴＣＰセッションを開放するシーケンスは省略して示している。これらの図示しないシーケンスは図２に示す接続要求［1) Activate PDP Context Request］から接続準備通知［10) Activate PDP Context Res ］までのシーケンス、および、開放要求［17) Deactivate PDP Context Request］から通信開放準備通知［22) Delete PDP Context Response］までのシーケンスと同様とされている。

図４において、図示しないシーケンスによりＴＣＰセッションが確立すると、移動端末（ＵＥ）１はコンテンツ一覧を取得するＨＴＴＰリクエストを送出する。このＨＴＴＰリクエストのＵＲＬは、例えばhttp://cp.com/kskycmi/xxx.........xxx/image.gifとされており、このＨＴＴＰリクエストはＪＳＰ７およびＷＧＷ１２で中継されてＵＲＬで示されるＣＰで受信される。これにより、ＣＰからコンテンツ一覧がＨＴＴＰレスポンスとして移動端末（ＵＥ）１へ送出され、ＷＧＷ１２およびＪＳＰ７で中継されて移動端末（ＵＥ）１が受信する。ＣＰからコンテンツ一覧を取得した移動端末（ＵＥ）１はコンテンツ一覧を参照して所望のコンテンツを選択した際に、コンテンツ選択のＨＴＴＰリクエストを送出する。このＨＴＴＰリクエストはＪＳＰ７で中継されてＷＧＷ１２が受信し、そのＨＴＴＰレスポンスとして購入価格等の情報と購入同意を示す「ＯＫ」ボタンと購入不同意を示す「ＮＧ」ボタンからなる購入同意画面がＷＧＷ１２から送出される。

そして、この購入同意画面は移動端末（ＵＥ）１にダウンロードされる。購入同意画面がダウンロードされた移動端末（ＵＥ）１には、ユーザエージェントであるブラウザに購入価格と「ＯＫ」ボタンと「ＮＧ」ボタンとが少なくとも表示され、ここで、購入同意画面上の「ＯＫ」ボタンを押すと購入同意（ＯＫ）のＨＴＴＰリクエストが購入同意したコンテンツが存在しているＣＰへ送出される。この購入同意のＨＴＴＰリクエストは、ＪＳＰ７およびＷＧＷ１２で中継されて目的とするＣＰが受信する。購入同意のＨＴＴＰリクエストを受信したＣＰはコンテンツをダウンロードするためのダウンロード記述子（ＤＤ：Download Descriptor）を作成し、ＨＴＴＰレスポンスとしてダウンロード記述子（ＤＤ）を移動端末（ＵＥ）１へ向けて送出する。図４に、ダウンロード記述子（ＤＤ）の一例が示されており、コンテンツのありかを示すＵＲＬ（Object URI）と、移動端末（ＵＥ）１がコンテンツを受け取ったことを通知するＵＲＬ（Install Notify URI）とが含まれている。このダウンロード記述子（ＤＤ）は、ＷＧＷ１２で中継されてＪＳＰ７が受信した際に、オンとされているユーザチェックフラグと、ＤＤ要求（移動端末１からの購入同意）をＪＳＰ７が受信した時刻であるjskycmi（コンテンツ管理情報）生成時刻と、移動端末（ＵＥ）１のＵＩＤがダウンロード記述子（ＤＤ）に埋め込まれる。このダウンロード記述子（ＤＤ）がＪＳＰ７から送出されて購入同意をした移動端末（ＵＥ）１が受信する。

ダウンロード記述子（ＤＤ）を受信したことにより、移動端末（ＵＥ）１のユーザエージェントには「このファイルをダウンロードするにはＯＫボタンを押して下さい」というメッセージが表示され、ここで、ＯＫボタンを押すと移動端末（ＵＥ）から取得したダウンロード記述子（ＤＤ）から取得したコンテンツのありかを示すＵＲＬ（Object URI）に対し、そのコンテンツ要求のＨＴＴＰリクエストが送出される。このコンテンツ要求は、ＪＳＰ７で受信されてそのObject URIに埋め込まれているユーザチェックフラグがオンとなっているか否かが判定される。ここで、ユーザチェックフラグがオンとなっていると判定された場合は、そのObject URIに埋め込まれているjskycmi（コンテンツ管理情報）生成時刻が有効期限内であるか、および、Object URIに埋め込まれているＵＩＤがＨＴＴＰリクエストのヘッダから取得したＵＩＤと一致するか判定される。

ここで、ユーザチェックフラグがオンと判定され、jskycmi（コンテンツ管理情報）生成時刻が有効期限内とされると共にＵＩＤが一致すると判定された場合は、ＪＳＰ７は埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤをObject URIから削除したＵＲＬ（Object URI）にコンテンツ要求のＨＴＴＰリクエストをＷＧＷ１２を経由して送出する。このコンテンツ要求を受け取ったＣＰは、コンテンツ要求に対するＨＴＴＰレスポンスとしてコンテンツを移動端末（ＵＥ）１に向けて送出する。このコンテンツのＨＴＴＰレスポンスは、ＷＧＷ１２およびＪＳＰ７で中継されて移動端末（ＵＥ）１で受信される。コンテンツがダウンロードされた移動端末（ＵＥ）１は、全てのコンテンツを受信したときにInstall NotifyのＨＴＴＰリクエストをダウンロード記述子（ＤＤ）から取得したＵＲＬ（Install Notify URI）に送出する。

このInstall NotifyのＨＴＴＰリクエストを受信したＪＳＰ７は、Install Notify URIに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤのチェックを前述と同様にして行う。この判定が全てＯＫとされた際に、ＪＳＰ７はInstall Notify URIに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤを削除すると共に、有料コンテンツに対する課金処理するためのCharging NotifyのＨＴＴＰリクエストをＷＧＷ１２に送信する。これにより、そのコンテンツに対する課金処理がＷＧＷ１２において行われ、ＷＧＷ１２はユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤが削除されたInstall NotifyのＨＴＴＰリクエストをＵＲＬ（Install Notify URI）に送出する。このInstall Notifyを受け取ったＣＰは、Install NotifyのＨＴＴＰリクエストに対するＨＴＴＰレスポンスであるInstall NotifyのAckをＷＧＷ１２およびＪＳＰ７を経由して移動端末（ＵＥ）１に送出する。このInstall NotifyのAckを移動端末（ＵＥ）１が受信することにより、有料コンテンツを取得するセッションを終了するようになる。
なお、ＪＳＰ７においてユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤのチェックを行った際に、全てＯＫと判定されなかった場合はエラー応答（HTTP Status Code 404 Not Found）をＪＳＰ７から移動端末（ＵＥ）１に返し、有料コンテンツを取得するセッションを終了させる。

次に、移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が著作権管理されている有料のＷＥＢコンテンツを取得する際のシーケンスを図５に示す。図５に示すシーケンス図においても、有料のＷＥＢコンテンツの取得に先立つＴＣＰセッションを確立するシーケンスおよび有料のＷＥＢコンテンツの取得後のＴＣＰセッションを開放するシーケンスは省略して示している。
図５に示すシーケンスにおいて、移動端末（ＵＥ）１はコンテンツ一覧を取得して、選択したコンテンツの購入同意画面がダウンロードされるまでのシーケンスは図４に示すシーケンスと同様とされており、その説明は省略する。

購入同意画面がダウンロードされた移動端末（ＵＥ）１には、ユーザエージェントであるブラウザに購入価格と「ＯＫ」ボタンと「ＮＧ」ボタンとが少なくとも表示される。ここで、購入同意画面上の「ＯＫ」ボタンを押すと、移動端末（ＵＥ）１が購入同意したコンテンツが著作権管理されているコンテンツとされている場合は、購入同意（ＯＫ）のＨＴＴＰリクエストが購入同意したコンテンツの著作権管理をしているＤＲＭ１６へ送出される。この購入同意のＨＴＴＰリクエストを受信したＤＲＭ１６はコンテンツをダウンロードするためのダウンロード記述子（ＤＤ：Download Descriptor）を作成し、ＨＴＴＰレスポンスとしてダウンロード記述子（ＤＤ）を移動端末（ＵＥ）１へ向けて送出する。図５に、ダウンロード記述子（ＤＤ）の一例が示されており、コンテンツのありかを示すＵＲＬ（Object URI）と、移動端末（ＵＥ）１がコンテンツを受け取ったことを通知するＵＲＬ（Install Notify URI）とが含まれている。このダウンロード記述子（ＤＤ）は、ＷＧＷ１２で中継されてＪＳＰ７が受信した際に、オンとされているユーザチェックフラグと、ＤＤ要求（移動端末１からの購入同意）をＪＳＰ７が受信した時刻であるjskycmi（コンテンツ管理情報）生成時刻と、移動端末（ＵＥ）１のＵＩＤがダウンロード記述子（ＤＤ）に埋め込まれる。このダウンロード記述子（ＤＤ）がＪＳＰ７から送出されて、購入同意をした移動端末（ＵＥ）１が受信する。

ダウンロード記述子（ＤＤ）を受信したことにより、移動端末（ＵＥ）１のユーザエージェントには「このファイルをダウンロードするにはＯＫボタンを押して下さい」等のメッセージが表示され、ここで、ＯＫボタンを押すと移動端末（ＵＥ）から取得したダウンロード記述子（ＤＤ）から取得したコンテンツが存在しているＵＲＬ（Object URI）に対し、そのコンテンツ要求のＨＴＴＰリクエストが送出される。このコンテンツ要求は、ＪＳＰ７で受信されてObject URIに埋め込まれているユーザチェックフラグがオンとなっているか否かが判定される。ここで、ユーザチェックフラグがオンとなっていると判定された場合は、そのObject URIに埋め込まれているjskycmi（コンテンツ管理情報）生成時刻が有効期限内であるか、および、コンテンツ要求（Object URI）に埋め込まれているＵＩＤがＨＴＴＰリクエストのヘッダから取得したＵＩＤと一致するか判定される。

ここで、ユーザチェックフラグがオンと判定され、jskycmi（コンテンツ管理情報）生成時刻が有効期限内とされると共にＵＩＤが一致すると判定された場合は、ＪＳＰ７は埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤをObject URIから削除したＵＲＬ（Object URI）にコンテンツ要求のＨＴＴＰリクエストをＷＧＷ１２を経由して送出する。このコンテンツ要求を受け取ったＣＰは、コンテンツ要求に対するＨＴＴＰレスポンスとしてコンテンツ（ＭＯ：Media Object）を移動端末（ＵＥ）１に向けて送出する。このコンテンツ（ＭＯ）は、ＷＧＷ１２およびＪＳＰ７で中継されて移動端末（ＵＥ）１で受信される。コンテンツ（ＭＯ）がダウンロードされた移動端末（ＵＥ）１は、全てのコンテンツ（ＭＯ）を受信したときにInstall NotifyのＨＴＴＰリクエストをダウンロード記述子（ＤＤ）から取得したＵＲＬ（Install Notify URI）に送出する。

このInstall NotifyのＨＴＴＰリクエストを受信したＪＳＰ７は、Install Notify URIに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤのチェックを前述と同様にして行う。この判定が全てＯＫとされた際に、ＪＳＰ７はInstall Notify URIに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤを削除すると共に、有料コンテンツに対する課金処理するためのCharging NotifyのＨＴＴＰリクエストをＤＲＭ１６に送信する。このCharging Notifyリクエストを受信したＤＲＭ１６は、上記コンテンツの著作権オブジェクト（ＲＯ：Rights Object）をＰＰＧ１０およびＳＭＳＣ５を経由してプッシュ転送する。上記コンテンツの著作権オブジェクト（ＲＯ）を移動端末（ＵＥ）１が受信することにより、取得してあったコンテンツ（ＭＯ）を開くことができるようになる。そして、移動端末（ＵＥ）１は上記コンテンツの著作権オブジェクト（ＲＯ）を受信した通知（Delivery Receipt）をＤＲＭ１６に送信する。そして、通知（Delivery Receipt）を受信したＤＲＭ１６はCharging NotifyリクエストをＷＧＷ１２に送り、これにより、著作権管理されているコンテンツに対する課金処理がＷＧＷ１２において行われ、ＷＧＷ１２はCharging NotifyのAckをＤＲＭ１６に送出する。このCharging NotifyのAckをＤＲＭ１６が受信することにより有料コンテンツを取得するセッションを終了させる。

なお、図５に示すシーケンスはコンテンツ（ＭＯ）と著作権オブジェクト（ＲＯ）とを分離して配信するSeparate Deliveryのシーケンスとされている。また、ＪＳＰ７においてユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤのチェックを行った際に、全てＯＫと判定されなかった場合はエラー応答（HTTP Status Code 404 Not Found）をＪＳＰ７から移動端末（ＵＥ）１に返し、有料コンテンツを取得するセッションを終了させる。

次に、移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が有料のＪａｖａ（ＴＭ）アプリケーションを取得する際のシーケンスを図６に示す。図６に示すシーケンス図においても、有料のＪａｖａ（ＴＭ）アプリケーションの取得に先立つＴＣＰセッションを確立するシーケンスおよび有料のＪａｖａ（ＴＭ）アプリケーションの取得後のＴＣＰセッションを開放するシーケンスは省略して示している。
図６に示すシーケンスにおいて、移動端末（ＵＥ）１はコンテンツ一覧を取得して、選択したコンテンツの購入同意画面がダウンロードされるまでのシーケンスは図４に示すシーケンスと同様とされており、その説明は省略する。

購入同意画面がダウンロードされた移動端末（ＵＥ）１には、ユーザエージェントであるブラウザに購入価格と「ＯＫ」ボタンと「ＮＧ」ボタンとが少なくとも表示される。ここで、購入同意画面上の「ＯＫ」ボタンを押すと、移動端末（ＵＥ）１が購入同意したコンテンツがＪａｖａ（ＴＭ）アプリケーションとされている場合は、購入同意（ＯＫ）のＨＴＴＰリクエストが購入同意したコンテンツであるＪａｖａ（ＴＭ）アプリケーションの管理をしているＭＡＣＳ１５へ送出される。ここで、Ｊａｖａ(TM)アプリケーションは、ＪＡＲ（Java Archive）ファイルとそれに対応するＪＡＤ（Java Application Descriptor）ファイル（記述子ファイル）で構成されている。ＪＡＲファイルは、Ｊａｖａ(TM)アプリケーションの実行に使用される圧縮／非圧縮のバイナリファイルであり、ＪＡＤファイルは、対応するＪＡＲファイルの説明（属性）が記述されたテキストファイルであり、アプリケーション名、アプリケーションのバージョン、ベンダ名、ＪＡＲファイルの存在する位置、ＪＡＲファイルのサイズなどの各種情報が記述されている。

購入同意のＨＴＴＰリクエストを受信したＭＡＣＳ１５は、対応するＪａｖａ（ＴＭ）アプリケーションのＪＡＤファイルを移動端末（ＵＥ）１へ向けて送出する。図６に、ＪＡＤファイルの一例が示されており、Ｊａｖａ（ＴＭ）アプリケーションのＪＡＲファイルのありかを示すＵＲＬ（MIDlet-Jar-URL）と、移動端末（ＵＥ）１がＪａｖａ（ＴＭ）アプリケーションを受け取ったことを通知するＵＲＬ（MIDlet-install-Notify）とが含まれている。このＪＡＤファイルは、ＷＧＷ１２で中継されてＪＳＰ７が受信した際に、オンとされているユーザチェックフラグと、ＪＡＤ要求（移動端末１からの購入同意）をＪＳＰ７が受信した時刻であるjskycmi（コンテンツ管理情報）生成時刻と、移動端末（ＵＥ）１のＵＩＤがＪＡＤファイルに埋め込まれる。このＪＡＤファイルがＪＳＰ７から送出されて購入同意をした移動端末（ＵＥ）１が受信する。

ＪＡＤファイルを受信したことにより、移動端末（ＵＥ）１のユーザエージェントには「このファイルをダウンロードするにはＯＫボタンを押して下さい」等のメッセージが表示され、ここで、ＯＫボタンを押すと移動端末（ＵＥ）から取得したＪＡＤファイルから取得したＪａｖａ（ＴＭ）アプリケーションが存在しているＵＲＬ（MIDlet-Jar-URL）に対し、該当するＪＡＲファイルをダウンロードするコンテンツ要求のＨＴＴＰリクエストが送出される。このコンテンツ要求は、ＪＳＰ７で受信されてそのMIDlet-Jar-URLに埋め込まれているユーザチェックフラグがオンとなっているか否かが判定される。ここで、ユーザチェックフラグがオンとなっていると判定された場合は、そのObject URIに埋め込まれているjskycmi（コンテンツ管理情報）生成時刻が有効期限内であるか、および、MIDlet-Jar-URLに埋め込まれているＵＩＤがＨＴＴＰリクエストのヘッダから取得したＵＩＤと一致するか判定される。

ここで、ユーザチェックフラグがオンと判定され、jskycmi（コンテンツ管理情報）生成時刻が有効期限内とされると共にＵＩＤが一致すると判定された場合は、ＪＳＰ７は埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤをMIDlet-Jar-URLから削除したＵＲＬ（MIDlet-Jar-URL）にＪＡＲファイルをダウンロードするコンテンツ要求のＨＴＴＰリクエストをＷＧＷ１２を経由して送出する。このコンテンツ要求を受け取ったＣＰは、コンテンツ要求に対するＨＴＴＰレスポンスとしてＪＡＲファイルを移動端末（ＵＥ）１に向けて送出する。このＪＡＲファイルのレスポンスは、ＷＧＷ１２およびＪＳＰ７で中継されて移動端末（ＵＥ）１で受信される。ＪＡＲファイルを移動端末（ＵＥ）１がダウンロードすることにより、移動端末（ＵＥ）１においてＪａｖａ（ＴＭ）アプリケーションを実行することができるようになる。そして、移動端末（ＵＥ）１は、ＪＡＲファイルを受信したときにＪａｖａ（ＴＭ）アプリケーションをダウンロードしたことを通知するＨＴＴＰリクエストをＵＲＬ（MIDlet-install-Notify）に送出する。

このＨＴＴＰリクエストを受信したＪＳＰ７は、MIDlet-install-Notifyに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤのチェックを前述と同様にして行う。この判定が全てＯＫとされた際に、ＪＳＰ７はMIDlet-install-Notifyに埋め込まれているユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤを削除すると共に、有料のＪａｖａ（ＴＭ）アプリケーションに対する課金処理をするためのMIDlet-Charging-NotifyのＨＴＴＰリクエストをＷＧＷ１２に送信する。これにより、そのＪａｖａ（ＴＭ）アプリケーションに対する課金処理がＷＧＷ１２において行われ、ＷＧＷ１２はユーザチェックフラグ、jskycmi（コンテンツ管理情報）生成時刻およびＵＩＤが削除されたMIDlet-install-NotifyのＨＴＴＰリクエストをＣＰに送信する。そして、ＣＰはMIDlet-install-NotifyのＨＴＴＰリクエストに対するＨＴＴＰレスポンスであるMIDlet-install-NotifyのAckをＷＧＷ１２およびＪＳＰ７を経由して移動端末（ＵＥ）１に送出する。このMIDlet-install-NotifyのAckを移動端末（ＵＥ）１が受信することにより有料のＪａｖａ（ＴＭ）アプリケーションを取得するセッションが終了するようになる。

上記の説明では、ユーザチェックフラグがオンと判定され、jskycmi（コンテンツ管理情報）生成時刻が有効期限内とされると共にＵＩＤが一致すると判定された場合に、コンテンツ取得要求を該当するＵＲＬに送出するようにしていたが、ユーザチェックフラグがオンと判定されたことだけを条件に、コンテンツ取得要求を該当するＵＲＬに送出するようにしてもよい。
本発明のサーバ装置はＪＳＰ７に限るものではなく、移動端末とコンテンツ・プロバイダとの間に位置するサーバ装置に適用することができる。

本発明の実施例のサーバ装置を備える移動通信システムの構成を示すブロック図である。 図１に示す移動通信システムにおいて、移動端末（ＵＥ）上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が無料のＷＥＢコンテンツを取得する際のシーケンス図を示す図である。 本発明の実施例のサーバ装置が実行する処理の概要を示すフローチャートである。 本発明の実施例のサーバ装置を備える移動通信システムにおいて、移動端末（ＵＥ）上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が有料のＷＥＢコンテンツを取得する際のシーケンスを示す図である。 移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が著作権管理されている有料のＷＥＢコンテンツを取得する際のシーケンスを示す図である。 移動端末（ＵＥ）１上で動作しているＷＥＢブラウザなどのユーザエージェント（ＵＡ）が有料のＪａｖａ（ＴＭ）アプリケーションを取得する際のシーケンスを示す図である。 既存の移動通信システムの概略構成である。 既存の移動通信システムにおいて移動端末がＣＰから有料のコンテンツを取得する際のシーケンスの一例を示す図である。

符号の説明

１ 移動端末、２ ＳＧＳＮ、３ ＧＧＳＮ、４ 加入者認証機構（ＪＳＲ）、５ ＳＭＳＣ、６ パケット課金記録情報収集装置（ＰＣＮ）、７ アプリケーションゲートウエイ（ＪＳＰ）、８ 情報管理サーバ（Ｒ２Ｍ）、９ ディレクトリ・レプリカ・サーバ（ＤＲＳ）、１０ ＰＰＧ、１１ ポータル・サーバ（ＰＴＬ）、１２ ウェブ・ゲートウエイ（ＷＧＷ）、１３ ＤＢシンクロナイザ、１４ Ｗｔｒａｎｃｅ、１５ ＭＡＣＳ、１６ ＤＲＭ、１７ メールサーバ（ＭＭＳ−Ｒ）、１８ ＣＯＰ、１９ インターネット、２０ データベース（Repo DB）、２１，２２ コンテンツ・プロバイダ（ＣＰ）、１００ 移動端末、１０１ 移動体通信網、１０２ ＪＳＰ、１０３ ＷＧＷ、１０４ インターネット、１０５ ＣＰ

Claims (6)

1. 移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウェイ装置と前記移動体通信網とに接続されたサーバ装置であって、
   前記移動体通信網に接続された移動端末が前記ＩＰネットワークに接続されたコンテンツ・プロバイダ上の有料コンテンツの購入同意をした際に購入同意のリクエストを送出し、該購入同意のリクエストに対するレスポンスにチェックフラグをセットする設定機能と、
   前記移動端末から前記有料コンテンツの取得要求があった際に、取得要求における前記チェックフラグの状態を検出して、前記有料コンテンツの取得要求をコンテンツ・プロバイダに送出するか否かを判定する判定機能とを有し、
   前記有料コンテンツの取得要求に先立つ前記移動端末からの前記有料コンテンツの購入同意のリクエストに対するレスポンスに、前記設定機能がチェックフラグをセットし、当該移動端末から前記有料コンテンツの取得要求があった際に、前記判定機能が、当該取得要求におけるチェックフラグがセットされていると判定したことを条件に、前記有料コンテンツの取得要求を前記コンテンツ・プロバイダに送出するようにしたことを特徴とするサーバ装置。
2. 前記移動端末から有料コンテンツの購入同意のリクエストに対するレスポンスとされるコンテンツダウンロード情報に、前記設定機能がチェックフラグをセットし、
   当該移動端末から前記コンテンツダウンロード情報に基づく前記有料コンテンツの取得要求があった際に、前記判定機能が、当該取得要求におけるチェックフラグがセットされていると判定したことを条件に、前記有料コンテンツの取得要求を前記コンテンツ・プロバイダに送出するようにしたことを特徴とする請求項１記載のサーバ装置。
3. 前記移動端末から有料コンテンツの購入同意のリクエストに対するレスポンスとされるコンテンツダウンロード情報に、前記設定機能が、チェックフラグおよび前記購入同意のリクエストの受信時刻と当該移動端末に関するユーザ識別情報とを設定し、
   前記移動体通信網に接続された移動端末から前記有料コンテンツを購入する要求があった場合に、前記判定機能が、当該取得要求におけるチェックフラグがセットされていると判定し、さらに、前記購入同意のリクエストの受信時刻からの経過時刻が許容範囲内の時刻とされていると共に、当該取得要求における当該移動端末に関するユーザ識別情報と、保存されているユーザ識別情報とが一致すると判定したことを条件として、前記有料コンテンツの取得要求を前記コンテンツ・プロバイダに送出するようにしたことを特徴とする請求項１記載のサーバ装置。
4. 前記コンテンツダウンロード情報が前記コンテンツ・プロバイダにおいて準備されて、有料コンテンツの購入同意のリクエストに対するレスポンスとして当該移動端末に通知されることを特徴とする請求項２あるいは３記載のサーバ装置。
5. 前記有料コンテンツが著作権管理サーバにより管理されている場合は、前記コンテンツダウンロード情報が前記著作権管理サーバにおいて準備されて、有料コンテンツの購入同意のリクエストに対するレスポンスとして当該移動端末に通知されることを特徴とする請求項２あるいは３記載のサーバ装置。
6. 前記有料コンテンツがＪａｖａアプリケーション管理サーバにより管理されている場合は、前記コンテンツダウンロード情報が前記Ｊａｖａアプリケーション管理サーバにおいて準備されて、有料コンテンツの購入同意のリクエストに対するレスポンスとして当該移動端末に通知されることを特徴とする請求項２あるいは３記載のサーバ装置。

Images