(57)【要約】【課題】  ＷＡＰ対応端末に対しても、従来のスキームで課金を行う。【解決手段】  移動端末１からオリジン・サーバ１２の有料コンテンツの購入要求があり、オリジン・サーバ１２から承認のＨＴＴＰ応答があったとき、ウェブ・ゲートウエイ（ＷＧＷ）１０は、該ＨＴＴＰ応答のステータス・コードを“402”に設定して、プロキシサーバ（ＷＡＰ−ＧＷ及びＪＳＰ）８に中継する。プロキシサーバ８は、該ＨＴＴＰ応答のステータスを“200”に設定して移動端末１に送出した後、要求のあったページの構成要素をＷＡＰプッシュまたはＯＭＡダウンロードにより、移動端末１にダウンロードさせる。そして、移動端末１から全コンテンツを取得したことを示す送達確認を受信すると、ＷＧＷ１０に対して課金通知を送信する。【選択図】  図１
2005267014.tif 000002
【特許請求の範囲】
【請求項１】
移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、
前記移動体通信網に接続された移動端末から前記ＩＰネットワークに接続されたオリジン・サーバ上の有料コンテンツを購入する要求があった場合に、
前記ゲートウエイで中継された前記オリジン・サーバからのＨＴＴＰレスポンスに含まれるステータスコードがその移動体通信事業者により設定された第１の値であるときに、その値を前記移動端末が認識することができる第２の値に設定して、該ＨＴＴＰレスポンスを前記移動端末に送信する機能と、
前記オリジン・サーバから前記移動端末から要求されたページの構成要素を全て受信した後に、該構成要素のデータを前記移動端末にプッシュにより送信する機能と、
前記移動端末から前記構成要素のデータを受信した旨の通知を受信したときに、前記ゲートウエイ装置に対して課金通知を送信する機能と
を有することを特徴とするサーバ装置。
【請求項２】
移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、
前記移動体通信網に接続された移動端末から前記ＩＰネットワークに接続されたオリジン・サーバの有料コンテンツの購入する要求があった場合に、
前記ゲートウエイで中継された前記オリジン・サーバからのＨＴＴＰレスポンスに含まれるステータスコードがその移動体通信事業者により設定された第１の値であるときに、その値を前記移動端末が認識することができる第２の値に設定して、該ＨＴＴＰレスポンスを前記移動端末に送信する機能と、
前記移動端末から要求されたコンテンツの各構成要素のＵＲＬを記述したダウンロードディスクリプタを作成する機能と、
該ダウンロードディスクリプタを前記移動端末に送信する機能と、
前記移動端末から前記構成要素を全て取得した旨の通知を受信したときに、前記ゲートウエイ装置に対して課金通知を送信する機能と
を有することを特徴とするサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話などの移動端末からインターネットに接続することができる移動体通信システムにおけるサーバ装置に関する。
【背景技術】
【０００２】
従来より、携帯電話などの移動端末からインターネットに接続することのできる移動体通信システムは運用されている。しかしながら、従来の移動体通信システムにおいては、各移動体通信事業者ごとにそれぞれ独自のプロトコルが用いられていた。
近年、いわゆる第３世代と呼ばれる携帯電話サービスが導入されつつあるが、この第３世代の移動体通信システムにおいては同一の移動端末を世界中で共通に使用することができるように標準化が進められており、ＷＡＰ（Wireless Application Protocol）及びＭＭＳ（Multimedia Messaging Service）の規格が共通仕様として採用されている（非特許文献１）。
【０００３】
このような第３世代のサービスが開始されると、従来より提供されていた各移動体通信事業者独自のプロトコルに対応した移動端末と、上記ＷＡＰ／ＭＭＳ対応の移動端末とが存在することとなる。
各移動体通信事業者はそれぞれの独自プロトコルに基づいて、独自のサービスを提供していたが、これからは、ＷＡＰ／ＭＭＳ規格に対応した移動端末の加入者が増加していくことになる。このことから、各移動体通信事業者独自のプロトコルに対応した移動端末に限らず、これらＷＡＰ／ＭＭＳ対応の移動端末についても、従来より各移動体通信事業者独自の規格に対応した移動端末に対して提供しているものと同様のサービスを提供することが求められることになる。
【０００４】
例えば、上述した従来の移動体通信システムにおいて、インターネットに接続されたコンテンツプロバイダから有料コンテンツをダウンロードするときには、移動体通信事業者独自のプロトコルが用いられていた。
図４の（ａ）は、従来のインターネットに接続することができる移動体通信システムの概要を示すブロック図であり、（ｂ）は、該システムにおいて有料コンテンツをコンテンツプロバイダからダウンロードするときのシーケンスを示す図である。
図４の（ａ）において、５１は移動端末（ＭＳ）、５２は移動体通信網、５３は移動体通信網５２とインターネット５４との間に設けられ、ウェブコンテンツを中継するゲートウエイ（ＷＧＷ：Web Gateway）、５４はインターネット、５５はコンテンツを配信するコンテンツプロバイダのサーバ（ＣＰ）である。この図に示すように、移動端末５１はその属する移動体通信網５２からＷＧＷ５３を介してインターネット５４と接続することができ、コンテンツプロバイダ５５から所望のコンテンツをダウンロードすることができる。
【０００５】
ここで、ＭＳ５１のユーザがコンテンツプロバイダ（ＣＰ）５５のウェブページをみて、そのコンテンツの購入を決定し、購入同意のＨＴＴＰ（Hypertext Transfer Protocol）リクエストを送信すると、該リクエストは、ゲートウエイ（ＷＧＷ）５３で中継され、コンテンツプロバイダ５５に送られる。
該購入同意のＨＴＴＰリクエストを受信したコンテンツプロバイダ５５は、必要に応じてユーザの認証をした後、購入承認を示すＨＴＴＰレスポンスをＷＧＷ５３に送信する。ＨＴＴＰレスポンスメッセージの第１行目は、httpのバージョン、ステータスコード（Status-Code）及びそれに関連したテキストフレーズ（Reason-Phrase：説明句）からなるステータス行が定義されている。ここで、ステータスコードは要求メッセージの状態をクライアントに通知するものであり、３桁の数字からなっている（ＲＦＣ２６１６を参照）。
ＷＧＷ５３では、前記ＣＰ５５からの購入承認を示すＨＴＴＰレスポンスを受信すると、そのステータスコードを“402”（課金指示）に設定して、該ＨＴＴＰレスポンスを移動端末５１に送信する。ここで、ステータスコード“402”は、「Payment Required」（支払いが必要）を意味する将来の使用のために予約されているコード（This code is reserved for future use. ）とされている。
ステータスコードが“402”に設定されたレスポンスを受信した移動端末５１は、該ＨＴＴＰレスポンス中で指定されたインラインオブジェクトの在りかを示すＵＲＩ（Uniform Resource Identifier）に対して、そのインラインオブジェクトを要求するＨＴＴＰリクエストを送信し、該要求を受け取ったＣＰ５５はそのコンテンツをＨＴＴＰレスポンスに載せてＭＳ５１に送信する。
ＭＳ５１は、全てのコンテンツを受け取ると、送達確認を前記ＷＧＷ５３に送信する。ＷＧＷ５３が送達確認を受け取ることにより、課金処理がなされる。また、ＭＳ５１は送達確認をＷＧＷ５３に送信した後に、受信したコンテンツを利用することができるようになされている。
【０００６】
このように、この移動体通信事業者は、ステータスコード“402”を用いる独自のプロトコルを採用しており、移動端末５１は、ステータスコードが“402”とされたＨＴＴＰレスポンスを受信したときに、上述した動作をするように構成されている。そして、このような構成とすることにより、移動端末５１において全てのコンテンツを受信したことを送達確認により確認した後に課金を行うようにしているため、圏外への移動や電波状態によりコンテンツを完全に受信できなかったときに課金されるといった不都合をなくし、合理的な課金を行うようにしていた。
【非特許文献１】The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [online], (2002.01.18)，［平成１５年１１月１５日検索］，インターネット<URL:http://www.wapforum.org/what/WAPWhite_Paper1.pdf>
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述のように、従来は移動体通事業者が独自仕様を採用することにより、合理的な課金処理が行われるようになされていた。しかしながら、ＷＡＰ／ＭＭＳ対応の移動端末（以下、単に、「ＷＡＰ対応端末」と呼ぶ。）には、基本的に移動体通信事業者の独自仕様を組み込むことができないため、前述した“402”というステータスコードを判別することができず、上述した従来より移動体通信事業者の課金システムで使用されてきたステータスコード“402”を使用するスキームを適用することができない。
そのためＷＡＰ対応端末に対しては、インターネット標準のステータスコード“200”（OK）を返信する必要があるが、そのステータスコードでは通常のレスポンスか、課金を伴う（端末側で送達確認を送出する必要のある）レスポンスであるのかの判別ができない。その結果、移動端末側で送達確認を送出することができず、そのままではサーバで課金ができないことになる。
【０００８】
そこで、本発明は、移動体通信事業者の独自仕様を組み込むことができないＷＡＰ対応端末においても、既存のノードと課金のスキームを利用して情報料の課金を行うことができるようにするサーバ装置を提供することを目的としている。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明のサーバ装置は、移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、前記移動体通信網に接続された移動端末から前記ＩＰネットワークに接続されたオリジン・サーバ上の有料コンテンツを購入する要求があった場合に、前記ゲートウエイで中継された前記オリジン・サーバからのＨＴＴＰレスポンスに含まれるステータスコードがその移動体通信事業者により設定された第１の値であるときに、その値を前記移動端末が認識することができる第２の値に設定して、該ＨＴＴＰレスポンスを前記移動端末に送信する機能と、前記オリジン・サーバから前記移動端末から要求されたページの構成要素を全て受信した後に、該構成要素のデータを前記移動端末にプッシュにより送信する機能と、前記移動端末から前記構成要素のデータを受信した旨の通知（Delivery Report）を受信したときに、前記ゲートウエイ装置に対して課金通知（Charging Notify）を送信する機能とを有するものである。
【００１０】
また、本発明の他のサーバ装置は、移動体通信網とインターネットなどのＩＰネットワークとの間に設けられるゲートウエイ装置と前記移動体通信網とに接続されたサーバ装置であって、前記移動体通信網に接続された移動端末から前記ＩＰネットワークに接続されたオリジン・サーバの有料コンテンツの購入する要求があった場合に、前記ゲートウエイで中継された前記オリジン・サーバからのＨＴＴＰレスポンスに含まれるステータスコードがその移動体通信事業者により設定された第１の値であるときに、その値を前記移動端末が認識することができる第２の値に設定して、該ＨＴＴＰレスポンスを前記移動端末に送信する機能と、前記移動端末から要求されたコンテンツの各構成要素のＵＲＬを記述したダウンロードディスクリプタを作成する機能と、該ダウンロードディスクリプタを前記移動端末に送信する機能と、前記移動端末から前記構成要素を全て取得した旨の通知（Install Notify）を受信したときに、前記ゲートウエイ装置に対して課金通知（Charging Notify）を送信する機能とを有するものである。
【発明の効果】
【００１１】
本発明のサーバ装置によれば、既存のノード（ウェブゲートウエイ装置）の機能を用いた従来の課金スキームを利用することができ、かつ、オリジン・サーバからのＨＴＴＰレスポンスをステータスコードを“200”に変換して送っても、移動端末側で送達確認を送出することが可能となった。
したがって、移動体通信事業者独自の仕様を埋め込むことができないＷＡＰ対応端末においても、従来通り送達確認を送出することができ、合理的な課金を行うことができる。
【発明を実施するための最良の形態】
【００１２】
図１は、本発明の移動体通信システムの実施例の全体構成を示すブロック図である。
この図において、１は携帯電話機等の移動端末（ＵＥ：User Equipment）、２は該移動端末１が接続されている無線基地局（ＢＴＳ：Base Transceiver Station）、３は複数の無線基地局２を管理する無線基地局制御装置（ＲＮＣ：Radio Network Controller）、４は前記無線基地局制御装置３に接続され、移動端末１の呼接続制御やサービス制御等を行う移動通信交換局（ＭＳＣ：Mobile service Switching Center）、５はＭＳＣ４に接続され、移動端末１に対してショートメッセージを配信するショートメッセージ・サービスセンター（ＳＭＳＣ：Short Message Service Center）、６は前記無線基地局制御装置（ＲＮＣ）３とコアネットワーク（パケット網）とのゲートウエイ（ＳＧＳＮ：Serving GPRS Support Node）、７はコアネットワーク（パケット網）とインターネットなどのＩＰネットワークとのゲートウエイ（ＧＧＳＮ：Gateway GPRS Support Node）である。
【００１３】
８は移動端末（ＵＥ）からのWAP2.0プロトコルを終端し、ＨＴＴＰ（HyperText Transfer Protocol ）を用いてオリジン・サーバ側へ転送するためのＷＡＰゲートウエイ（ＷＡＰ−ＧＷ：WAP-Gateway）、及び、受け付けたリクエストを適切な形式に変換して後段に送出するなどしてＷＡＰ標準機能と移動体通信事業者による拡張機能との調整を行うプロキシサーバ（ＪＳＰ：J-Phone Scheme Proxy）とを有するサーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）、９はＷＡＰプッシュやメール通知の配信などのプッシュサービスを実行するノード（ＰＰＧ：Push Proxy Gateway）、１０は前記サーバ装置８とインターネット１１との間に設けられたウェブ・ゲートウエイ（ＷＧＷ：Web Gateway）である。図示するようにインターネット１１にはオリジン・サーバ（Origin Server：指定されるリソースが存在するか、あるいは生成されるサーバ）１２が接続されている。
【００１４】
このように構成されたシステムにおいて、移動端末１のユーザが、コンテンツプロバイダであるオリジン・サーバ１２から有料コンテンツをダウンロードするときのシーケンスについて説明する。なお、以下の説明では、移動端末１はＷＡＰ対応端末であるとする。
図２は、本発明の第１の実施の形態において有料コンテンツをオリジン・サーバ１２からダウンロードするときのシーケンスを示す図である。この実施の形態は、ＷＡＰプッシュ（WAP Push）を利用するものである。なお、ＷＡＰプッシュ自体については、http://www.wapforum.org/what/technical.htmから文献をダウンロードすることができる。
【００１５】
図２において、ＷＡＰ対応端末である移動端末１がＷＡＰシーケンスにしたがってインターネットに接続しており、ユーザがオリジン・サーバ１２の有料コンテンツを購入することを決定したとする。これにより、移動端末１から購入同意を示すＨＴＴＰリクエストが送出されると、該ＨＴＴＰリクエストは、サーバ装置（ＷＡＰ−ＧＷ及びＪＳＰ）８及びＷＧＷ１０でそれぞれ中継されてオリジン・サーバ１２に送信される。
このＨＴＴＰリクエストを受信したオリジン・サーバ１２は、購入を承認するか否かを判定し、購入を承認するときには、購入の承認を示すＨＴＴＰレスポンスとそのページに含まれるコンテンツを前記ＷＧＷ１０に送信する。なお、１回のＨＴＴＰレスポンスでコンテンツの送信が完了しないときは、複数のＨＴＴＰレスポンスが発生される。
ＷＧＷ１０は、購入承認のＨＴＴＰレスポンス（通常、ステータスコードは“200”（OK）とされている。）を受信すると、そのステータスコードを“402”に設定して、前記サーバ装置８に送信する。
【００１６】
サーバ装置８は、該ステータスコードが“402”に設定されたＨＴＴＰレスポンスを受信すると、そのステータスコードを“200”に設定して移動端末（ＷＡＰ対応端末）１に送信するとともに、コンテンツが後から配信される旨を通知する。そして、前記オリジン・サーバ１２から送信されるコンテンツが全て受信されるのを待つ。
全コンテンツをオリジン・サーバ１２から受信したときは、該コンテンツをＷＡＰプッシュのメカニズムを用いて前記移動端末１に配信する。すなわち、前記ＰＰＧ９と前記ＳＭＳＣ５を経由して、各コンテンツを前記移動端末１に送信する。
前記サーバ装置８から前記ステータスコードが“200”に設定されたＨＴＴＰレスポンスを受信した移動端末１は、前記ＳＭＳＣ５を経由してＷＡＰプッシュでコンテンツを全て受信した後に、前記サーバ装置８に対して、 "Delivery Report"を送信する。
この"Delivery Report"を受信した前記サーバ装置８は、前記ＷＧＷ１０に対し、 “Charging Notify”を送信し、ＷＧＷ１０は、これを受けて前記移動端末１が購入したコンテンツに対する課金処理を行う。
このように、この実施の形態によれば、コンテンツ本体をＷＡＰプッシュのメカニズムを用いて配信することにより、ＷＡＰ対応端末に対しても従来のスキームを使用した合理的な課金を行うことが可能となる。
【００１７】
次に、本発明の第２の実施の形態について説明する。この実施の形態は、ＷＡＰプッシュではなく、ＯＭＡダウンロード（OMA(Open Mobile Alliance) Download）の技術を利用するものである。なお、ＯＭＡダウンロード自体については、http://www.openmobilealliance.org/documents.htmlから文献をダウンロードすることができる。
【００１８】
図３は、ＯＭＡダウンロードを利用する本発明の第２の実施の形態の動作を示すシーケンス図である。
前述した図２の場合と同様に、移動端末１からの購入同意のＨＴＴＰリクエストをサーバ装置８、ＷＧＷ１０経由で受け取ったオリジン・サーバ１２が購入承認のＨＴＴＰレスポンスを前記ＷＧＷ１０に返すと、ＷＧＷ１０は、そのＨＴＴＰレスポンスのステータスコードを“402”に設定して、サーバ装置８に中継する。
該ステータスコードが“402”のＨＴＴＰレスポンスを受け取ったサーバ装置８は、該ＨＴＴＰレスポンスを解析し、そのＨＴＴＰレスポンスのステータスコードを“200”に変換してＷＡＰ端末１に送出するとともに、ロケーションヘッダに含まれているＵＲＬを保存する。そして、該ＨＴＴＰレスポンスに含まれるインラインオブジェクトへのＵＲＬに基づいてダウンロード記述子（ＤＤ：Download Descriptor）を作成する。なお、このダウンロード記述子は、サーバ装置８に限らず、オブジェクトＵＲＬなどのコンテンツダウンロード時に必要な情報を把握する他サーバ（前記ＷＧＷ１０やオリジン・サーバ１２など）が作成してもよい。
移動端末１は、前記ＨＴＴＰレスポンスを受信すると、サーバ装置８に対してダウンロード記述子を要求し、取得したダウンロード記述子に含まれているＵＲＬに対し、そのコンテンツを要求する。
該コンテンツ要求は、前記サーバ装置８を介して、該コンテンツが記憶されているオリジン・サーバ１２に送信され、該オリジン・サーバ１２からそのページに含まれているコンテンツが前記移動端末１に送信される。
前記移動端末１は、全てのコンテンツを受信したときにInstall Notifyを前記サーバ装置８に送信し、サーバ装置８は、前記ステータスコードが“402”のＨＴＴＰレスポンスのロケーションヘッダに含まれていたＵＲＬ（ＷＧＷ１０）に対し、Charging Notifyを送信する。これにより、そのコンテンツに対する課金処理が行われることとなる。
このように、この実施の形態によれば、ＯＭＡダウンロードを利用することにより、ＷＡＰ対応端末に対しても従来のスキームを使用した合理的な課金を行うことができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の移動体通信システムの全体構成を示すブロック図である。
【図２】本発明の第１の実施の形態において有料コンテンツを購入するときのシーケンスを示す図である。
【図３】本発明の第２の実施の形態において有料コンテンツを購入するときのシーケンスを示す図である。
【図４】従来の移動体通信システムについて説明するための図であり、（ａ）は従来の移動体通信システムの概略構成を示すブロック図、（ｂ）は有料コンテンツを購入するときのシーケンスを示す図である。
【符号の説明】
【００２０】
１：移動端末（ＵＥ）、２：無線基地局（ＢＴＳ）、３：無線基地局制御装置（ＲＮＣ）、４：移動通信交換局（ＭＳＣ）、５：ショートメッセージ・サービスセンター（ＳＭＳＣ）、６：ゲートウエイ（ＳＧＳＮ）、７：ゲートウエイ（ＧＧＳＮ）、８：ＷＡＰゲートウエイ及びプロキシサーバ（ＷＡＰ−ＧＷ及びＪＳＰ）、９：ＷＡＰプッシュプロキシゲートウエイ（ＰＰＧ）、１０：ウェブ・ゲートウエイ（ＷＧＷ）、１１：インターネット、１２：オリジン・サーバ
【図１】
2005267014.tif 000003
【図２】
2005267014.tif 000004
【図３】
2005267014.tif 000005
【図４】
2005267014.tif 000006