JP2014505438A - 移動通信システムの課金制御装置及び方法 - Google Patents

Abstract

本発明は、移動通信システムの課金制御方法及び装置に関し、本発明の移動通信システムにおいて課金制御方法は、端末から伝送されるスポンササービス要請受信時に、サービス提供者がスポンサクーポンを生成して前記端末に伝送する段階と、前記端末が前記スポンサクーポンを受信してオペレータに伝送する段階と、前記オペレータが前記スポンサクーポンを利用してスポンサトラフィックに対するフィルタ及び課金規則を設定し、端末に通知する段階と、前記端末が前記サービス提供者に前記スポンササービスを再要請し、前記サービス提供者からスポンサトラフィックサービスを提供される段階と、前記オペレータが前記サービス提供者に前記スポンサトリピックに対して課金する段階とを含むことを特徴とする。

Description

本発明は、移動通信システムの課金制御装置及び方法に関し、特にスポンサトラフィックの課金制御装置及び方法に関する。

現在、通信網の発展に伴い、多様な形態の電子購買方式が使用されている。このような電子購買方法は、ユーザが通信網に接続してサービス提供者に接続した後、サービス提供者の商品を見ながら所望の商品を購買する方法が一般的である。このような場合、ユーザが、通信網に接続するとき、課金を発生させることができる。例えば、移動通信網を通じてサービス提供者サーバに接続した後、電子ショッピングを行えば、ユーザは、移動通信網事業者に通信網接続による使用料を支払わなければならない。特に映画、電子ブック、音楽などの大容量データを有する商品を購買する場合、通信網接続時間が長くなり、そのため、多い金額の課金を発生させることができる。

本発明は、サービス提供者、網事業者及び端末よりなる通信網において端末が網事業者を介してサービス提供者と接続する場合、端末のトラフィックに関連した通信費用をサービス提供者に課金する方法を提案する。

本発明の実施例による移動通信システムにおいて課金制御方法は、端末から伝送されるスポンササービス要請受信時に、サービス提供者がスポンサクーポンを生成し、前記端末に伝送する段階と、前記端末が前記スポンサクーポンを受信し、オペレータに伝送する段階と、前記オペレータが前記スポンサクーポンを利用してスポンサトラフィックに対するフィルタ及び課金規則を設定し、端末に通知する段階と、前記端末が前記サービス提供者に前記スポンササービスを再要請し、前記サービス提供者からスポンサトラフィックサービスを提供される段階と、前記オペレータが前記サービス提供者に前記スポンサトラフィックに対して課金する段階とを含むことを特徴とする。

また、本発明の移動通信システムにおいて課金を制御する装置は、スポンササービス利用のためのスポンササービス要請をサービス提供者に伝送し、前記サービス提供者からスポンサクーポン受信時に、スポンササービス再要請をオペレータに伝送する端末と、前記端末からスポンササービス要請受信時にスポンサクーポンを生成し、前記端末に伝送し、前記端末からスポンササービス再要請受信時に前記端末にスポンサトラフィックサービスを提供するサービス提供者と、前記端末から前記スポンサクーポン受信時に、前記受信したスポンサクーポンを利用してスポンサトラフィックに対するフィルタ及び課金規則を設定し、前記端末に通知し、前記スポンサトラフィックに対して前記サービス提供者に課金するオペレータとを含むことを特徴とする。

本発明の実施例による移動通信システムにおいて端末がスポンサトラフィック要請時にサービス提供者が発行したクーポンを利用して網事業者が検証、フィルタインストール及び課金規則を設定し、その後、端末がサービス提供者に接続し、スポンサトラフィックをサービスされるとき、網事業者は、これをサービス提供者に課金する。したがって、本発明の実施例によるスポンサトラフィック処理方法は、第３者サーバ（３ｒｄ ｐａｒｔｙ ｓｅｒｖｅｒ）情報の動的設定支援と第３者サーバとオペレータ網内のサーバとのオンライン取り引きを最小化することができるという利点がある。

移動通信網でスポンサトラフィックの概念を説明するための図である。 移動通信網でスポンサトラフィックの例を説明する図である。 現在３ＧＰＰで論議中のＰｏｌｉｃｙ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ拡張ソリューション構造を示す図である。 現在３ＧＰＰで論議中のＰｏｌｉｃｙ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ拡張ソリューション構造での動作を説明するための図である。 本発明の第１実施例による移動通信網においてｃｏｕｐｏｎ ｂａｓｅｄスポンサ課金シナリオを示す図である。 本発明の実施例によるスポンサクーポンサービス加入情報ｐｌａｎｎｉｎｇ例を示す図である。 本発明の実施例による移動通信網の構造を示す図である。 図７でＳＮＥサーバの内部構成を示す図である。 本発明の実施例においてクーポン発行及び伝送手続を示す図である。 本発明の実施例においてスポンサトラフィックに対するパケットフィルタをインストールし、課金率を設定する手続を示す図である。 本発明の実施例においてスポンサトラフィックを行う手続を示す図である。 本発明の実施例においてクーポンがデータ量及び／または時間である場合のスポンサトラフィック終了手続を示す図である。 本発明の実施例においてクーポンがサービス提供者によって終了する場合のスポンサトラフィック終了手続を示す図である。 本発明の実施例によってスポンサ課金を終了する手続を示す図である。 本発明の実施例によって網事業者とサービス提供者との間に課金を行う手続を示す図である。 本発明の第２実施例による移動通信網においてｃｏｕｐｏｎ ｂａｓｅｄスポンサ課金シナリオを示す図である。

以下、本発明の好ましい実施例の詳細な説明を添付の図面を参照して詳しく説明する。図面において、同一の構成は、できるだけどの所でも同一の符号を示していることを留意しなければならない。

また、下記説明では、サービス提供者、クーポンなどのように具体的な特定事項が示されているが、これは、本発明のさらに全般的な理解を助けるために提供されたものに過ぎず、このような特定事項なしに本発明が実施されることができることは、この技術分野における通常の知識を有する者に自明であると言える。そして、本発明を説明するにあたって、関連された公知機能あるいは構成に対する具体的な説明が本発明の要旨を不明にすることができると判断される場合、詳細な説明を省略する。

以下の説明において、“端末”という用語は、サービス提供者にサービスを要請するユーザ端末であって、ＵＥなどと混用されて使用され、“網事業者”という用語は、オペレータと混用されて使用され、“サービス提供者”という用語は、サービス提供者、ｓｐｏｎｓｏｒ、３ｒｄ ｐａｒｔｙ ｓｅｒｖｉｃｅｓなどと混用されて使用される。また、“スポンサトラフィック”という用語は、サービス提供者とのトラフィックを意味し、スポンサ課金（“ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｅ”）という用語は、端末が通信網に接続して発生した課金をサービス提供者が支払うことを意味する。

本発明の実施例は、移動通信網においてスポンサトラフィックに対する課金を端末に賦課せずに、サービス提供者に賦課する方案を提案する。このための通信網は、端末、網事業者及びサービス提供者で構成されることができる。このために、本発明の実施例においては、まず、スポンサとオペレータ契約によってスポンサクーポンを発行し、そのクーポンを端末または網事業者に伝送する。この際、前者の場合、端末は、これをバイパス（ｂｙｐａｓｓ）し、オペレータサーバに伝送する方法を提案する。また、本発明の実施例においては、網事業者が、伝送されたクーポン内のコンテンツ／サービスサーバ情報を利用してスポンサ課金に対するフィルタと規則を設置する方法を提案する。そして、本発明の実施例においては、クーポンに明示されたスポンサ使用量からスポンサ満了が把握し、スポンサトラフィックフィルタと規則を設置解除し、すぐスポンササービスが満了するということ及び既に満了したことをユーザに通知する方法を提案する。

上記のような本発明を実施するために、本発明の第１実施例は、端末がスポンサトラフィックを利用するサービスを要請すれば、サービス提供者は、スポンサトラフィック要請であることを認識し、移動通信網で使用することができるスポンサクーポンを生成し、端末に伝送する。それでは、端末は、受信したクーポンを網事業者に伝送し、クーポンを受信した網事業者は、クーポン内の情報を利用してスポンサトラフィックに対するフィルタと課金規則を設定し、その結果を端末に通知する。その後、端末は、網事業者を通じてサービス提供者に接続し、スポンサトラフィックをサービスされ、網事業者は、端末のトラフィックに関連した料金をサービス提供者に課金する。

また、上記のような本発明を実施するために、本発明の第２実施例は、端末がスポンサトラフィックを利用するサービスを要請すれば、サービス提供者は、スポンサトラフィック要請であることを認識し、移動通信網で使用することができるスポンサクーポンを生成し、網事業者に伝送する。それでは、クーポンを受信した網事業者は、クーポン内の情報を利用してスポンサトラフィックに対するフィルタと課金規則を設定した後、その結果を前記サービス提供者に通知する。それでは、サービス提供者は、前記クーポンに含まれたサーバのアドレスを端末に伝送する。その後、ユーザは、網事業者を通じてサービス提供者に接続してスポンサトラフィックをサービスされ、網事業者は、端末のトラフィックに関連した料金をサービス提供者に課金する。

上記のような本発明の実施例による動作を詳しく説明する。

現在３ＧＰＰでは特別なトラフィックに対して当該トラフィックを使用する端末に課金せず、第３者に課金するスポンサトラフィック支援に対するソリューションが論議中にある。図１はスポンサトラフィックの概念を説明するための図である。図１に示されたように、スポンサトラフィックという端末が第３者にサービス使用料を支払うトラフィックを行うとき、第３者が端末が第３者に接続して発生する通信料を支払うトラフィックを意味する。

例えば、端末が第３者であるオンラインブックストアに接続し、ｅｂｏｏｋを検索及び／または購買によって電子ブックをダウンロードするトラフィックに対して、端末の通信料を第３者に課金するようになる。この際、課金方式は、多様な形態で具現されることができる。すなわち、端末がオンラインブックストアに接続して電子ブックを購買する場合、端末が電子ブックを検索及び購買によって電子ブックをダウンロードするのに発生するすべての費用をｏｎｌｉｎｅ ｂｏｏｋｓｔｏｒｅに課金することができる。また、図２に示されたように、端末が電子ブックを検索するのに発生する費用は、端末に課金し（図２の参照番号２１０のような場合）、端末がｅｂｏｏｋの購入ボタンを押した後、当該ｅｂｏｏｋをダウンするトラフィックに対しては、端末に課金をせず、スポンサであるオンラインブックストアで課金することができる（図２の参照番号２２０のような場合）。

図３は、現在３ＧＰＰで論議中のポリシー課金制御（Ｐｏｌｉｃｙ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ）拡張ソリューション構造を示す図である。

図３を参照すれば、第３者サーバであるＮｏｎ−ＳＩＰ ＡＳＰ ３１０（図２の場合、ブックストアサーバになることができる）でスポンサトラフィックを処理するオペレータネットワーク内のサーバ（図３でＡＦになることができる）にｂｏｏｋ ｄｏｗｎｌｏａｄに関連したトラフィックに対する情報を信号として伝送する。そして、これを受信したオペレータネットワークのサーバ（ＡＦ）でポリシーを制御するポリシー課金規則機能（ＰＣＲＦ）エンティティーにスポンサトラフィックに対する情報を伝達する。それでは、ＰＣＲＦは、実際課金レコードを生成するパケットデータネットワークゲートウェイ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ、ＰＧＷ）にスポンサトラフィックに対してスポンサのＩＤで課金レコードが生成されるようにメッセージを伝達する。それでは、ＰＧＷでは、スポンサトラフィックに対してｕｓｅｒ ＩＤではないｓｐｏｎｓｏｒｅｄ ＩＤで課金レコードを生成する。すなわち、ＰＧＷは、スポンサトラフィックに対してＵＥ １００ではない３ｒｄ ｐａｒｔｙに課金をする。

上記のような図３のようなポリシー課金制御構造を拡張するソリューションは、次のようなイシューを引き起こすことができる。

まず、第３者サーバは、スポンサするトラフィックに対する情報とスポンサトラフィックの開始と終了を通知するための信号を課金データを作るＰＧＷに伝達しなければならない。そのため、第３者サーバは、オペレータネットワーク内のＰＧＷと連結されたサーバとコネクション（ｃｏｎｎｅｃｔｉｏｎｎ）を有しなければならない。第３者がグローバルサービス（ｇｌｏｂａｌ ｓｅｒｖｉｃｅ）をする場合、図４に示されたように、オペレータのサーバとすべてコネクションを連結しなければならないし、スポンサトラフィックが発生する度に、関連した信号をオペレータのサーバに伝送しなければならない。また、図３のＮｏｎ−ＳＩＰ ＡＳＰとＡＦとの間は、現在３ＧＰＰ標準でｏｕｔ ｏｆ ｓｃｏｐｅなので、オペレータサーバが支援する他のｐｒｅｐａｒａｔｏｒｙ ｐｒｏｔｏｃｏｌを第３者がすべて支援しなければならないので、第３者に負担が発生することができる。（Ｎ：Ｍ ｃｏｎｎｅｃｔｉｏｎ）。

第二に、第３者サーバにスポンサするトラフィックを伝送したセッション（ｓｅｓｓｉｏｎ）を固定しなければならない。当該トラフィックを伝送するサーバのアドレスとポートなどを固定し、この固定（ｓｔａｔｉｃ）情報をＰＧＷにｓｔａｔｉｃに設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）し、当該トラフィックが発生すれば、そのトラフィックに対してｓｐｏｎｓｏｒｅｄ ＩＤで課金するようにしなければならない。ところが、このために、当該トラフィックを伝送するサーバのアドレスとポートなどが固定されなければならない。しかし、このような場合、第３者が巨大事業者ではなければ、Ｃｅｎｔｒａｌ Ｄａｔａ Ｃｅｎｔｅｒ（ＣＤＦ）やＩｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ（ＩＤＣ）などを利用するようになるので、サーバのアドレスとポートなどが固定されにくい。

したがって、上記のようなイシュー、すなわち第３者サーバ情報の動的設定支援と第３者サーバとオペレータ網内のサーバとのオンライン取り引きを最小化するための方案が考慮されなければならない。

図５は、本発明の第１実施例によって第３者サーバ情報の動的設定支援と第３者サーバとオペレータ網内のサーバとのオンライン取り引きの最小化を考慮してスポンサトラフィックを処理する動作を示す図である。

図３を参照すれば、まず、第３者サービスを開始しようとするサービス提供者のために、オペレータは、スポンサクーポンサービスを提供し、第３者提供者は、オペレータが提供するスポンサクーポンサービスに加入しなければならない。

図６は、本発明の実施例によるスポンサクーポンサービス加入情報ｐｌａｎｎｉｎｇの例を示す図である。

図６に示されたように、前記クーポンには、データモデルを規定（ｓｐｅｃｉｆｙ ｔｈｅ ｄａｔａ ｍｏｄｅｌ）しなければならないし、ここには、データのサイズ（ｖｏｌｕｍｅ（ｔｏｔａｌ））及び有効期間（ｖａｌｉｄｉｔｙ ｗｉｎｄｏｗ）が表示されなければならない。例えば、毎月−〜１Ｇ：４０＄、〜２Ｇ：７０＄、〜３Ｇ：１００＄になることができる。

前記スポンサトラフィックを処理するために、端末１００にクーポンを発行する前に、サービス提供者３００とオペレータ２００は、発行されるクーポンを検証するための情報をあらかじめ交換しなければならない。このために、サービス提供者３００は、５１１段階で、スポンサクーポン加入情報と以後発行クーポンのサイン（ｓｉｇｎ）の有効性を証明するときに使用する公開キーをオペレータに伝達する。それでは、前記オペレータ２００は、５１３段階で、オペレータＩＤをサービス提供者３００に伝送し、追加的に保安キーを共有することもできる。前記５１１段階及び５１３段階を行うと、サービス提供者３００とオペレータ２００との間には、スポンサトラフィックを処理するための準備を完了するようになる。

その後、端末１００が５２１段階でスポンサトラフィックを利用するサービスを要請（サービス要請（ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ））（ｅｘ：ｅｂｏｏｋ費用を支払った後、ｄｏｗｎｌｏａｄ ｂｕｔｔｏｎ ｃｌｉｃｋ）する。この際、前記５１１段階で、サービスを要請するとき、前記端末１００は、現在使用するオペレータｉｄを一緒に伝送する。前記端末１００からサービス要請を受信すれば、前記サービス提供者３００は、５２３段階で、スポンサトラフィック要請であることを認識し、当該オペレータで使用することができるスポンサクーポンを生成した後、当該オペレータに通知した公開キーとカップルである個人キー（ｐｒｉｖａｔｅ ｋｅｙ）で前記生成されたスポンサクーポンをサイン（ｓｉｇｎ）する。追加的に共有された保安キーを利用してサインと同時に暗号化も可能である。前記クーポンを個人キーでサインする理由は、端末１００が前記クーポンを変更して他の用途で使用することを防止するためである。すなわち、前記クーポンをサービス提供者３００の個人キーでサインすれば、端末１００は、前記クーポン内の情報を変更することができず、したがって、端末１００が要請したサービス用途にのみ使用することができるようになる。その後、前記サービス提供者３００は、５２５段階で、前記端末１００のサービス要請（ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ）対して再試行命令（ｒｅ−ｔｒｙ ｃｏｍｍａｎｄ）及び生成したクーポンを端末１００に一緒に伝送する。この際、再試行のために接続するサーバアドレスは、クーポン内に入っているサーバアドレスと同一である。

この際、前記サービス提供者３００が前記端末１００に伝送するクーポンは、下記表１のような構造を有することができる。

前記表１のようなクーポンは、サービス提供者のＩＤ、端末が連結するオペレータのＩＤ、クーポンＩＤ、使用モデル（ｕｓａｇｅ ｍｏｄｅｌ）、サービス提供者の連結アドレス、クーポンの使用開始時間（ｔｉｍｅ ｓｔａｍｐ）などを含み、上記のようなクーポンのすべてのパラメータは、サービス提供者の個人キー（ｐｒｉｖａｔｅ ｋｅｙ）によってサインされる。

上記のようなクーポンを受信する端末１００は、５２７段階で受信されたクーポンをオペレータ２００に伝送（ｂｙｐａｓｓ）する。前記端末１００から前記表１のようなクーポンを受信するオペレータ２００は、５２９段階で、契約当時（図５の５１１段階）に受けたサービス提供者３００の公開キーでクーポンに対する有効性を検証する。その後、前記クーポンの有効性検証に成功すれば、前記オペレータ２００は、５２９段階で、クーポン内のサーバ情報を利用してスポンサトラフィックに対するフィルタを構成し、前記フィルタに対するトラフィックは、ｓｐｏｎｓｏｒ ｉｄでｃｈａｒｇｉｎｇするように課金規則を設定する。この際、必要に応じて、前記オペレータ２００は、新しいベアラーを生成した後、新たに生成されたベアラーにフィルタと課金規則を設定することもできる。

上記のように、５２９段階で、クーポンの有効性検証、フィルタ構成及び課金規則を設定した後、オペレータは、５３１段階で、フィルタの設置とクーポン有効性検証結果を端末に伝達（ｎｏｔｉｆｙ ｃｏｕｐｏｎ ｖａｌｉｄａｔｉｏｎ）する。それでは、前記端末１００は、５３３段階で、第３者提供者３００に受けた再試行（ｒｅ−ｔｒｙ）アドレスにさらにサービス要請（ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ）する。この際、前記５３３段階で、端末１００のサービス要請によって発生するトラフィックは、スポンサトラフィックになり、前記スポンサトラフィックに対するｃｈａｒｇｉｎｇは、オペレータ２００によってｓｐｏｎｓｏｒｅｄ ＩＤの加入情報関連ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄに記録される。すなわち、前記オペレータ２００は、前記スポンサトラフィックに対しては、端末１００に課金せずに、第３者提供者３００に課金する。

図７は、本発明の実施例によってスポンサトラフィックを処理する移動通信システムの構造を示す図である。

図７を参照すれば、端末１００は、ｕｓｅｒ １１０、コンテンツアプリケーション１２０及びモバイルＯＳ １３０などで構成されることができ、オペレータ２００は、ＳＮＥサーバ（ＳＥＮＳ）２１０、ＵＤＲ ２２０、ＰＣＲＦ ２３０、ＰＧＷ（ＧＧＳＮ） ２４０及びＯＦＣＳ ２５０で構成されることができる。ここで、ユーザ１１０は、クーポンをダウンロードし、スポンサトラフィック処理に関連した情報などを処理及び表示する動作を行う。コンテンツアプリケーション１２０は、端末でスポンサトラフィックを処理するアプリケーションであり、モバイルＯＳ１３０は、オペレータ２００と無線通信機能を行う。

オペレータ２００のＳＮＥサーバ２１０は、スポンサトラフィック処理時に端末１００から受信されるクーポンを検証し、クーポン内のサーバ情報を利用してスポンサトラフィックに対するフィルタを構成し、前記フィルタに対するトラフィックは、ｓｐｏｎｓｏｒ ｉｄでｃｈａｒｇｉｎｇするように課金規則を設定する。ＵＤＲ（Ｕｓｅｒ Ｄａｔａ Ｒｅｐｏｓｉｔｏｒｙ）２２０は、課金規則を格納し、それでは、ＰＣＲＦ ２３０は、実際課金レコードを生成するスポンサトラフィックに対してスポンサのＩＤで課金レコードが生成されるようにメッセージを生成し、ＰＧＷ ２３０では、ＰＣＲＦ ２３０で伝送されるメッセージによってスポンサトラフィックに対してｕｓｅｒ ＩＤではないｓｐｏｎｓｏｒｅｄ ＩＤで課金レコードを生成し、ＯＦＣＳ ２５０は、これによる勘定書を発生する。

図８は、前記図７で端末のＳＮＥ通信クライアントモジュールとオペレータ２００のＳＮＥサーバ２１０の構成を示す図である。

図８を参照すれば、スポンサトラフィックを処理するための端末のモバイルプラットホームは、ＳＮＥ通信クライアントモジュールを含み、そのモジュールは、次の機能を行う。まず、ＳＮＥ通信クライアントモジュールは、第３者アプリケーションからクーポンを受けてオペレータネットワークにあるＳＮＥサーバ２１０に設置を要請し、また、設置結果を確認する。そして、前記ＳＮＥサーバ２１０でクーポン満了などに対する通知を伝送すば、これを受信し、第３者アプリケーションに伝達する。また、ＳＮＥ通信クライアントモジュールは、上記のような以外のオペレータ網のＳＮＥサーバ２１０とのすべての通信機能を行う。

また、前記ＳＮＥサーバ２１０は、４種の機能モジュールと２種のＲｅｐｏｓｉｔｏｒｙを含み、それぞれの機能は、次の通りである。

ＳＮＥクライアント通信機能８２０は、端末のモバイルプラットホームにあるＳＮＥ通信クライアントモジュールとの通信機能を行う。前記ＳＮＥクライアント通信機能８２０は、端末で伝送した第３者アプリケーションのクーポンを受けてクーポン有効性機能８３０に伝送し、有効性確認を行う。そして、クーポン内容を基盤でスポンサ課金規則がスポンサトラフィックポリシーコントローラによって設置されれば、前記ＳＮＥクライアント通信機能８２０は、その結果を端末のＳＮＥ通信クライアントモジュールに通知する結果を行い、その他、端末のモバイルプラットホームにあるＳＮＥ通信クライアントモジュールとのすべての通信機能を行う。

スポンサ通信機能８４０は、第３者がオペレータとスポンサ契約を締結するときに接続するサーバ機能を行い、スポンサが入力した情報をスポンサの公開キーを含む認証書（ｃｅｒｔｉｆｉｃａｔｅ）とともにスポンサ認証格納所８５０に格納し、オペレータ網に設置され、使用されたクーポンに対する情報と実際オペレータ網の使用情報をスポンサクーポン格納所８６０に格納する機能を行う。そして、前記スポンサ通信機能８４０は、その他、第３者がオペレータ網の情報を見てアップデートするなど第３者とオペレータ間のすべての通信機能を行う。

クーポン有効性機能８３０は、第３者が発行したクーポンをスポンサ認証格納所８５０に格納された第３者公開キーと共有された保安キーなどの追加情報を利用して有効性を確認し、その結果を通知する機能を行う。

スポンサトラフィックポリシーコントローラ８１０は、クーポン有効性機能８３０によって有効性が確認されたクーポンの情報を利用してオペレータ網に設置されたＴＦＴと課金規則を生成し、ＰＣＲＦ ２３０と連動して生成されたＴＦＴと課金規則を設置する機能を行う。そして、前記スポンサトラフィックポリシーコントローラ８１０は、この機能以外のオペレータ網の他のエンティティーと連動するすべての機能を行う。

スポンサクーポン格納所８６０は、第３者がオペレータとスポンサ契約を締結するとき、スポンサが入力したスポンサの公開キーを含む認証書とその他のすべての情報を格納する格納する。スポンサ認証格納所８５０は、端末のモバイルプラットホームにあるＳＮＥ通信クライアントモジュールで伝送されたクーポンを格納し、前記クーポン使用によって端末で使用したスポンサトラフィック情報をも格納する。

以下、本発明の実施例によってスポンサトラフィック処理動作をクーポンを活性化する過程（Ａｃｔｉｖａｔｅ Ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ Ｃｏｕｐｏｎ）、パケットフィルタインストール及び課金ルール設定過程（Ｉｎｓｔａｌｌｉｎｇ ｔｈｅ ｐａｃｋｅｔ ｆｉｌｔｅｒｓ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｏｒ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）、スポンサトラフィック処理過程（Ｅｘｐｉｒａｔｉｏｎ Ａｌｅｒｔｉｎｇ）、スポンサトラフィック処理終了過程（Ｄｅａｃｔｉｖａｔｅ Ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ）及び課金処理過程（Ｃａｓｈ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）の順に説明する。

まず、クーポン処理過程（Ｃｏｕｐｏｎ Ｉｓｓｕｅ ａｎｄ ｄｅｌｉｖｅｒｙ）を説明する。図９は、本発明の実施例によってクーポンを活性化する過程（Ａｃｔｉｖａｔｅ Ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ Ｃｏｕｐｏｎ）を示す図である。

図９を参照すれば、９１１段階は、前記サービス提供者３００とオペレータ２００との間にスポンサトラフィック処理のための契約過程である。すなわち、９１１段階で、オペレータ２００は、スポンサクーポンサービスを提供し、コンテンツ提供者３００は、オペレータ２００が提供するスポンサクーポンサービスに加入する動作を行う。前記スポンサトラフィックを処理するために、サービス提供者３００とオペレータ２００は、発行されるクーポンを検証するための情報をあらかじめ交換する。この際、コンテンツ提供者（ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒ）３００は、前記表１のようなスポンサクーポン加入情報と以後発行クーポンのｓｉｇｎに対する有効性を証明（ｖｅｒｉｆｉｃａｔｉｏｎ）するときに使用する公開キーをオペレータ２００に伝達し、オペレータ２００は、オペレータＩＤをコンテンツ提供者３００に伝送し、保安キー（保安キー）を共有することもできる（Ｃｏｎｔｒａｃｔｕａｌ ａｇｒｅｅｍｅｎｔ ｂｅｔｗｅｅｎ ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒ ａｎｄ ｔｈｅ ｏｐｅｒａｔｏｒ ｏｎ ｔｈｅ ａｍｏｕｎｔ ｏｆ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ ａｎｄ ｉｔｓ ｃｈａｒｇｉｎｇ ｒａｔｅ．Ｔｈｅ ｏｐｅｒａｔｏｒ ｈａｓ ｔｈｅ ｃｅｒｔｉｆｉｃａｔｅ ｉｎｃｌｕｄｉｎｇ ｔｈｅ ｐｕｂｌｉｃ ｋｅｙ ｏｆ ｔｈｅ ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒｓ．）。

その後、ユーザ端末１００が９１３段階でスポンサトラフィックを利用するｓｅｒｖｉｃｅをコンテンツ提供者３００に要請し（ｒｅｑｕｅｓｔ ｔｈｅ ｓｅｒｖｉｃｅ ｗｈｉｃｈ ｕｓｅｓ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）、現在使用するオペレータ ｉｄを一緒に伝送する。前記端末１００からサービス要請を受信すれば、前記コンテンツ提供者３００は、９１５段階で、スポンサトラフィック要請であることを認識し、当該オペレータで使用することができる前記表１のようなスポンサクーポンを生成した後、生成されたスポンサクーポンを個人キー（ｐｒｉｖａｔｅ ｋｅｙ）でｓｉｇｎする（Ｔｈｅ ｃｏｎｔｅｎｔｓｐｒｏｖｉｄｅｒ ｉｓｓｕｅｓ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｃｏｕｐｏｎ ｓｉｇｎｅｄ ｂｙ ｉｔｓ ｐｒｉｖａｔｅ ｋｅｙ）。前記クーポンを個人キー（ｐｒｉｖａｔｅ ｋｅｙ）でｓｉｇｎする理由は、前述したように、端末１００が前記クーポンを変更して他の用途に使用することを防止するためである。追加的に、共有された保安キーを利用してｓｉｎｇと暗号化（ｅｎｃｒｙｐｔｉｏｎ）を行うこともできる。その後、前記コンテンツ提供者３００は、９１７段階で、前記端末１００のサービス要請（ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ）対して専用命令（ｒｅ−ｄｉｒｅｃｔ ｃｏｍｍａｎｄ）及び生成したクポンをｎｂｏｕｎｄ ｓｉｇｎａｌで一緒に伝送する（ｓｅｎｄ ｔｈｅ ｒｅ−ｔｒｉａｌ ｃｏｍｍａｎｄ ｔｏ ｔｈｅ ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ ｗｉｔｈ ｉｓｓｕｅｄ ｃｏｕｐｏｎ）。この際、再試行（ｒｅ−ｔｒｙ）のために接続するサーバアドレスは、クーポン内に入っているサーバアドレスと同一である。現在使用するオペレータｉｄを一緒に伝送する。

図１０は、本発明の実施例によってオペレータ２００でパケットフィルタをインストールし、課金規則を設定（ｉｎｓｔａｌｌｉｎｇ ｔｈｅ ｐａｃｋｅｔ ｆｉｌｔｅｒｓ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｏｒ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）する手続を示す図面である。

図１０を参照すれば、端末１００のユーザ１１０は、１０１１段階で、前記コンテンツ提供者３００からクーポン及び再試行命令（ｒｅｔｒｙ ｃｏｍｍａｎｄ）を受信し（ｒｅｃｅｉｖｅ ｔｈｅ ｃｏｕｐｏｎ＋ｒｅｔｒｙ ｃｏｍｍａｎｄ ｗｉｔｈ ｃｏｎｔｅｎｔ ｓｅｒｖｅｒ ａｄｄｒ）、これを端末のコンテンツアプリケーション１２０に伝達する。それでは、コンテンツアプリケーション１２０は、１０１３段階で、前記受信されたクーポンをパラメータで端末１００で提供するスポンサ課金メソドを呼び出し、モバイルＯＳ １３０に伝達して（ａｐｐ ｃａｌｌ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｍｅｔｈｏｄ ｗｉｔｈ ｉｔｅｍ ｏｂｊｅｃｔ ｉｎｃｌｕｄｅｓ ｔｈｅ ｃｏｕｐｏｎ）、前記モバイルＯＳ１３０は、１０１５段階で、Ａｐｐｌｉｃａｔｉｏｎ ｉｄ、ｕｓｅｒ ｉｄ、スポンサクーポンを含むサービス要求メッセージ（ａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｑｕｅｓｔ）をオペレータネットワーク内のサーバのＳＮＥＳ ２１０に伝送する（ａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｑｕｅｓｔ（ａｐｐｌｉｃａｔｉｏｎ ＩＤ、ｕｓｅｒ ＩＤ、ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｃｏｕｐｏｎ））。

それでは、前記スポンサ課金活性化要請（Ａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｑｕｅｓｔ）を受信したＳＮＥＳ ２１０は、１０１７段階で、コンテンツ提供者が登録した公開キーでクーポンのサインの有効性証明を行う（ｖａｌｉｄａｔｅ ｔｈｅ ｃｏｕｐｏｎ ｗｉｔｈ ｔｈｅ ｃｅｒｔｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒ）。追加的に、保安キーを利用してｓｉｇｎとｅｎｃｒｙｐｔｉｏｎになっていたら、共有されている保安キーを利用して有効性証明と復号（ｄｅｃｒｙｐｔｉｏｎ）を行う。そして、前記有効性証明が正常に行われれば、前記ＳＮＥＳ ２１０は、１０１９段階で、当該ａｐｐｌｉｃａｔｉｏｎ ｉｄ、ｓｐｏｎｓｏｒｅｄ ｉｄで確認（ｉｄｅｎｔｉｆｙ）されるスポンサトラフィックに対する課金規則がｕｓｅｒ ｉｄで確認されるユーザの課金規則に既に設置されているかを確認し、まだ設置されていなければ、課金規則をＵＤＲに格納する（ｃｈｅｃｋ ＵＤＲ ｉｆ ｔｈｅｒｅ ｉｓ ａｎ ｅｘｉｓｔｉｎｇ ｒｅｃｏｒｄ ｆｏｒ ｕｓｅｒ ＩＤ ａｎｄ ｃｏｕｐｏｎ（ｓｐｏｎｓｏｒ ＩＤ、ｃｏｎｔｅｎｔ ＩＤ）。Ｉｆ ｔｈｅｒｅ ｉｓ ｎｏ ｅｘｉｓｔｉｎｇ ｒｅｃｏｒｄ、ＳＮＥＳ ａｄｄｓ（ｉｎｓｔａｌｌ）ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｃｏｕｐｏｎ）。

この際、格納した規則をｆｏｒｃｅするためには、ＰＧＷに設置必要である。このために、前記ＳＥＮＳ ２１０は、１０２１段階で、ＰＣＲＦ ２３０を通じてＰＧＷ２４０にこれを通知し（ｓｅｎｄ ａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｍｅｓｓａｇｅ ｔｏ ｔｈｅ ＰＣＲＦ ｗｉｔｈ ＰＣＲＦ ｗｉｔｈ ｓｕｂｓｃｒｉｐｔｉｏｎＩＤ、ＴＦＴ、ｓｐｏｎｓｏｒＩＤ、ｓｐｏｎｓｏｒ ｍｏｄｅｌ ａｎｄ ｉｔｓ ｐａｒａｍｅｔｅｒｓ）、ＰＧＷ ２４０は、１０２３段階で、スポンサ課金ｍｏｄｅｌをインストールする（ＰＧＷ（ＰＣＥＦ）ｉｎｓｔａｌｌｓ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｍｏｄｅｌ）。

上記のような動作を具体的に説明すれば、前記ＳＮＥＳ ２１０は、前記ＰＣＲＦ ２３０にユーザの加入情報ｉｄ、スポンサの加入情報ＩＤ、スポンサトラフィックに対するパケットフィルタで構成されるＴＦＴ、使用モデル（ｕｓａｇｅ ｍｏｄｅｌ）をパラメータとしてスポンサ課金活性化を要請する。この際、既存ベアラー（ｂｅａｒｅｒ）を利用する場合、フィルタと課金規則だけをＰＧＷ ２４０に設置し、新しいベアラーを利用する場合、ＩＰ−ＣＡＮ Ｓｅｓｓｉｏｎ Ｍｏｄｉｆｉｃａｔｉｏｎ過程を通じてＰＧＷ ２４０に当該フィルタと課金規則を利用するベアラーを生成するようにする。そして、前記ＰＧＷ ２４０は、ＰＣＲＦ ２３０を通じて前記ＳＮＥＳ ２１０にスポンサ課金モデルのインストール結果を報告する。

前記Ａｃｔｉｖａｔｅスポンサ課金要請に対する結果をＰＧＷ ２４０に受信するＳＮＥＳ ２１０は、１０２５段階で、端末１００のモバイルＯＳ １３０にスポンサクーポン設置結果（ａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｓｐｏｎｓｅ（ｒｅｓｕｌｔ＝ｓｕｃｃｅｓｓ）を通知し（ａｃｔｉｖａｔｅスポンサ課金ｒｅｓｐｏｎｓｅ（ｒｅｓｕｌｔ＝ｓｕｃｃｅｓｓ））、モバイルＯＳ １３０は、１０２７段階で、これをコンテンツアプリケーション１２０に伝達する（ｒｅｔｕｒｎ ｆｒｏｍ ＡＰＩ ｍｅｔｈｏｄ ｃａｌｌ）。したがって、コンテンツアプリケーション１２０が呼び出したスポンサ課金メソド実行結果がコンテンツアプリケーション１２０に返還（ｒｅｔｕｒｎ）される。それでは、前記コンテンツアプリケーション１２０は、１０２９段階で、再試行命令（ｒｅｔｒｙ−ｃｏｍｍａｎｄ）として受けたスポンサクーポンに含まれたサーバアドレスと一致するコンテンツサーバにサービスを要請し（ｒｅｑｕｅｓｔ ｔｈｅ ｓｅｒｖｉｃｅ ｗｈｉｃｈ ｕｓｅｓ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）、当該トラフィックに対してＰＧＷ ２４０は、前記端末１００のスポンサトラフィックに対してｓｐｏｎｓｏｒｅｄ ｉｄで課金レコード（ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄ）を作成する。

ここで、前記設置（ｉｎｓｔａｌｌ）過程で、コンテンツ提供者３００の再試行命令（ｒｅｔｒｙ−ｃｏｍｍａｎｄ）に要求されたコンテンツサーバアドレスとクーポン内のコンテンツサーバアドレスがＵＲＩである場合、ＳＮＥＳ ２１０は、当該ＵＲＩに対するＤＮＳクイーリー（ＤＮＳ ｑｕｅｒｙ）を行い、その結果アドレスにスポンサトラフィックに対するパケットフィルタを構成して設置し、その結果アドレスを端末１００に伝送し、端末１００は、サーバが伝送したそのアドレスをコンテンツサーバアドレスとしてサービス利用のための接続を行う。

また、前記検証過程で、コンテンツ提供者３００が前払い（ｐｒｅ−ｐａｉｄ）方式でスポンサ加入情報に加入した場合、スポンサ加入情報ＩＤのｃｒｅｄｉｔがすべて満了（ｅｘｐｉｒｅ）すれば、前記ＳＮＥＳ ２１０は、そのコンテンツ提供者３００に対するスポンサクーポンに対する有効性証明をすべて失敗（ｆａｉｌ）として処理する。

一方、図１０では、ユーザ１１０がオペレータのＳＮＥＳサーバ２１０にスポンサ課金活性化メッセージを直接伝送するフローについて記述したが、必ずこれに限定されるものではない。

具体的に、端末は、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｎｔｕｍ）プロトコルを利用して前記スポンサ課金活性化メッセージをＳＮＥＳ ２１０に伝送することもできる。このために、端末は、スポンサ課金を活性化させるためのＮＡＳメッセージにＰＣＯ（Ｐｒｏｔｏｃｏｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｐｔｉｏｎ）を設定すれば、前記スポンサ課金活性化メッセージをＰ−ＧＷ ２４０に直接伝達することができる。ここで伝達されるスポンサ課金活性化メッセージ（ＮＡＳメッセージ）は、１０１５段階で記述されたメッセージと同一のパラメータを含むことができる。それでは、前記メッセージを受信したＰ−ＧＷ ２４０がこれをＰＣＲＦ ２３０に伝達し、ＰＣＲＦ ２３０が前記メッセージをＳＮＥＳ ２１０にさらに伝達することもできる。ＰＣＲＦ ２３０からスポンサ課金活性化メッセージを受信したＳＮＥＳ ２１０は、さらに１０１７以下の段階を行うことができる。

図１１は、スポンサトラフィックを処理する途中にクーポンの使用モデル（ｕｓａｇｅ ｍｏｄｅｌ）によってスポンサトラフィックを終了していることを警報する手続（Ｅｘｐｉｒａｔｉｏｎ Ａｌｅｒｔｉｎｇ）を示す図である。

図１１を参照すれば、端末のダウンロードアプリケーション（ｄｏｗｎｌｏａｄ ａｐｐｌｉｃａｔｉｏｎ）１２０は、１１１１段階で、コンテンツ提供者３００からコンテンツデータをダウンロードする（ａｐｐ ｄｏｗｎｌｏａｄｓ ｔｈｅ ｃｏｎｔｅｎｔｓ ｏｒ ｓｔｒｅａｍｉｎｇ ｔｈｅ ｃｏｎｔｅｎｔ（ｅｘ：ｖｉｄｅｏ ｄａｔａ））。ここで、前記コンテンツデータは、電子ブック、映画、音楽などのデータになることができる。上記のように、端末のダウンロードアプリケーション１２０がコンテンツデータをダウンロードするとき、ＰＧＷ ２４０は、１１１３段階で、ＰＧＷに設置されたクーポンの使用データレコード（ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）が臨界値に到逹するか（ｅｘｐｉｒｅ）検査し、臨界値に到逹した場合、これをＰＣＲＦに通知する（Ｗｈｅｎ ｔｈｅ ｉｎｓｔａｌｌ ｕｓａｇｅｄａｔａ ｒｅｃｏｒｄ ｒｅａｃｈｅｓ ｔｈｅ ｔｈｒｅｓｈｏｌｄ、ｉｔｓ ｅｎｄ ｓｎｏｔｉｆｉｃａｔｉｏｎ ｔｏ ｔｈｅ ＰＣＲＦ）。それでは、前記ＰＣＲＦ ２３０は、１１１５段階で、前記ＰＧＷ ２４０からスポンサ課金レコードに対する臨界値に到達したことを通知されるようになり、これには、ｓｐｏｎｓｏｒｅｄ ＩＤ、加入情報ＩＤ、課金ＩＤ、使用データレコードなどが含まれることができる（Ｔｈｒｅｓｈｏｌｄ ｒｅａｃｈ ｎｏｔｉｆｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄｓ（ｓｐｏｎｓｏｒｅｄ ＩＤ、ｓｕｂｓｃｒｉｐｔｉｏｎ ＩＤ（ｏｒ ｃｈａｒｇｉｎｇ ＩＤ）、ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）。それでは、前記ＰＣＲＦ２３０は、１１１７段階で、前記ＳＮＥＳ ２１０にイベント通知（ｅｖｅｎｔ ｎｏｔｉｆｉｃａｔｉｏｎ（ｓｐｏｎｓｏｒｅｄ ＩＤ、加入情報ＩＤ、使用データレコード）をする。前記イベント通知を受信すれば、前記ＳＮＥＳ ２１０は、１１１９段階で、前記ＰＣＲＦ ２３０にＡｃｋメッセージを伝送し、前記ＰＣＲＦ ２３０は、１１２１段階で、前記ＰＧＷ ２４０にＡｃｋメッセージを伝送する。

その後、前記ＳＮＥＳ ２１０は、前記端末のモバイルＯＳ １３０に警報メッセージ、残っている使用量情報などを含む終了警報メッセージを伝送する（Ｅｘｐｉｒａｔｉｏｎ Ａｌｅｒｔ（Ａｌｅｒｔ ｍｅｓｓａｇｅ、Ｒｅｍａｉｎｉｎｇ ｓｐｏｎｓｏｒｅｄ ｄａｔａ ｕｓａｇｅ））。それでは、端末のモバイルＯＳ １３０は、１１２５段階で、ＳＮＥＳ ２１０にＡｃｋを伝送する。また、前記モバイルＯＳは、１１２７段階で、コンテンツアプリケーション１２０に受信された警報（ａｌｅｒｔ）を伝達し、コンテンツアプリケーション１２０は、これを処理し（Ｃａｌｌ ｔｈｅ ｌｉｓｔｅｎｅｒ ＡＰＩ ｉｆ ｉｔ ｗａｓ ｒｅｇｉｓｔｅｒｅｄ（ｆｏｒ ｅｘａｍｐｌｅ Ａｌｅｒｔ ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ ｇｏｉｎｇ ｔｏ ｅｘｐｉｒｅ）、ｕｓｅｒ １１０は、１１２９段階で、警報（ａｌｅｒｔ）を表示する（ｄｉｓｐｌａｙ ｔｈｅ ａｌｅｒｔ ｍｅｓｓａｇｅ ｔｏ ｔｈｅ ｕｓｅｒ）。

前述したように、端末がコンテンツアプリケーション１２０がスポンサトラフィックを利用するサービスを行っている状態で、スポンサトラフィックがクーポンの使用量が設定された値に到逹すれば、オペレータ２００は、これを端末１００に警報し、端末１００は、これを表示する。この際、前記クーポンに表示される使用量は、スポンサトラフィックのサイズ（ｔｏｔａｌ ａｍｏｕｎｔ）、時間（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）及びｕｎｔｉｌ ｅｎｄ ｓｉｇｎａｌｓに表示されることができる。

図１２は、前記クーポン使用量が全体サイズ（ｔｏｔａｌ ａｍｏｕｎｔ）、全体時間（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）になった場合の動作手続を示す図であり、図１３は、前記クーポン使用量が‘終了信号まで’（ｕｎｔｉｌ ｅｎｄ ｓｉｇｎａｌｓ）になった場合の動作手続を示す図である。

図１２を参照すれば、前記クーポン使用量が全体サイズ、全体時間になった場合の動作は、前記図１１と類似の手続に進行される。すなわち、コンテンツアプリケーション１２０が、１２１１段階で、スポンサトラフィックを利用するサービスを利用する中であり、ＰＧＷ ２４０は、１２１３段階で、ＰＧＷに設置されたクーポンの使用量が臨界値に到逹するかを確認し、臨界値に到逹した場合、これをＰＣＲＦに通知する。ここで、前記クーポンの使用量は、全体サイズまたは全体時間になることができ、時間またはサイズがあらかじめ定められた量の９０％程度に到逹すれば、クーポンの使用量が満了（ｅｘｐｉｒｅ）していることを通知する動作を行う（Ｗｈｅｎ ｔｈｅ ｉｎｓｔａｌｌ ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ ｒｅａｃｈｅｓ ｔｈｅ ｔｈｒｅｓｈｏｌｄ（ｔｏｔａｌ ａｍｏｕｎｔ、ｔｏｔａｌ ｄｕｒａｔｉｏｎ）、ｉｔｓ ｅｎｄｓ ｎｏｔｉｆｉｃａｔｉｏｎ ｔｏ ｔｈｅ ＰＣＲＦ）。

それでは、１２１５段階−１２２１段階を行いながら、前記ＰＧＷ ２４０は、ＰＣＲＦに限界到達通知（ｔｈｒｅｈｏｌｄ ｒｅａｃｈ ｎｏｔｉｆｉｃａｔｉｏｎ）を行い（Ｔｈｒｅｓｈｏｌｄ ｒｅａｃｈ ｎｏｔｉｆｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ ｒｅｃｏｒｄｓ（ｓｐｏｎｓｏｒｅｄ ＩＤ、ｓｕｂｓｃｒｉｐｔｉｏｎ ＩＤ（ｏｒ ｃｈａｒｇｉｎｇ ＩＤ）、ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）、前記ＰＣＲＦ ２３０は、前記ＳＮＥＳ ２１０にイベント通知（ｅｖｅｎｔ ｎｏｔｉｆｉｃａｔｉｏｎ（ｓｐｏｎｓｏｒｅｄ ＩＤ、ｓｕｂｓｃｒｉｐｔｉｏｎ ＩＤ、ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）をする。前記イベント通知を受信すれば、前記ＳＮＥＳ ２１０は、前記ＰＣＲＦ ２３０にＡｃｋメッセージを伝送し、前記ＰＣＲＦ ２３０は、前記ＰＧＷ ２４０にＡｃｋメッセージを伝送する。

その後、前記ＳＮＥＳ ２１０は、１２２３段階で、端末１００に終了警報メッセージを送って、（Ｅｘｐｉｒａｔｉｏｎ Ａｌｅｒｔ（Ａｌｅｒｔ ｍｅｓｓａｇｅ、Ｒｅｍａｉｎｉｎｇ ｓｐｏｎｓｏｒｅｄ ｄａｔａ ｕｓａｇｅ））を伝送する。それでは、端末１００は、１１２５段階で、ＳＮＥＳ ２１０にＡｃｋを伝送する。そして、前記端末は、１２２７段階及び１１２９段階で、コンテンツアプリケーションをａｌｅｒｔ伝達し（Ｃａｌｌ ｔｈｅ ｌｉｓｔｅｎｅｒ ＡＰＩ ｉｆ ｉｔ ｗａｓ ｒｅｇｉｓｔｅｒｅｄ（ｆｏｒ ｅｘａｍｐｌｅ Ａｌｅｒｔ ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ ｇｏｉｎｇ ｔｏ ｅｘｐｉｒｅ）、警報を表示する（ｄｉｓｐｌａｙ ｔｈｅ ａｌｅｒｔ ｍｅｓｓａｇｅ ｔｏ ｔｈｅｕｓｅｒ）。

一方、図１１及び図１２では、使用してから残ったスポンサトラフィックの全体サイズが一定のサイズである場合、または一定時間が経過した場合、警報を通知する実施例について記述したが、必ずこれに限定されるものではない。例えば、スポンサトラフィックの一定量消耗時ごとに、または一定時間経過時ごとに警報を発生することもできる。例えば、スポンサトラフィックが５Ｍｂｙｔｅずつ消耗する度に警報を発生することができる。または、サービス提供者がオペレータと契約したスホントトラフィックの全体時間が１時間である場合、５分消尽時ごとに警報を発生することもできる

一方、本発明の他の実施例によれば、オペレータがユーザに警報を通知する実施例だけについて記述したが、必ずこれに限定されるものではない。例えば、オペレータは、ユーザ及びサービス提供者に同時に警報を通知することができる。警報を受けたサービス提供者は、追加的にオペレータとスポンサクーポンに対する契約を締結し、ユーザがスポンササービスを提供されるにあたって不便を経験しないようにすることができる。

また、前記図１３を参照すれば、コンテンツアプリケーション１２０が１２１１段階でスポンサトラフィックを利用するサービスを利用する中に、このような状態でクーポン使用量がｕｎｔｉｌ ｅｎｄ ｓｉｇｎａｌである場合、コンテンツ提供者３００のコンテンツサーバからスポンサトラフィックの終了を示すメッセージを受信することができる。すなわち、前記コンテンツアプリケーション１２０は、１３１３段階で、コンテンツ提供者３００のサーバからバイパス要請メッセージ（ｒｅｑｕｅｓｔ ｂｙ−ｐａｓｓ ｍｅｓｓａｇｅ）（スポンサトラフィックｅｎｄ）を受信するようになる。すなわち、前記コンテンツサーバは、終了時点になれば、１３１３段階で、スポンサトラフィック終了に対するネットワークバイパス要請メッセージ（ｎｅｔｗｏｒｋ ｂｙ−ｐａｓｓ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）（ｂｙ−ｐａｓｓされるメッセージは、ｅｎｃｒｙｐｔｅｄされる）をコンテンツアプリケーションに伝達する。それでは、１３１５段階で、コンテンツアプリケーション１２０は、ユーザ１１０に警報を表示する（ｄｉｓｐｌａｙ ｔｈｅ ａｌｅｒｔ ｍｅｓｓａｇｅ ｔｏ ｔｈｅ ｕｓｅｒ（ｅｘ：ｎｏｗ ｄａｔａ ｔｒａｆｆｉｃｉｓ ｃｈａｒｇｅｄ ｔｏ ｙｏｕ！！！））。そして、前記コンテンツアプリケーション１２０は、１３１７段階で、暗号化されたバイパスメッセージをＳＮＥＳ ２１０に伝達する（ｐａｓｓ ｔｈｅ ｍｅｓｓａｇｅ（ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ ｅｎｄ！）。

図１２で、クーポン使用量の全体使用量または全体期間が完全に満了するか、または図１３で１３１７段階を行った後、オペレータ２００は、スポンサ課金を終了（ｄｅａｃｔｉｖａｔｅスポンサ課金）する手続を行う。

図１４は、スポンサ課金を終了（ｄｅａｃｔｉｖａｔｅスポンサ課金）する手続を示す図である。

図１４を参照すれば、端末のダウンロードアプリケーション１２０は、１４１１段階で、スポンサトラフィックのサービスを利用することができる状態であり、これは、コンテンツ提供者３００からコンテンツデータをダウンロードすることができる状態になることができる。上記のような状態で、ＳＮＥＳ ２１０が図１１〜図１３で説明されたクーポン使用量によるスポンサ満了（ｓｐｏｎｓｏｒｉｎｇ ｅｘｐｉｒａｔｉｏｎ）を感知すれば、１４１３段階で、ＰＣＲＦ ２３０にスポンサ課金の終了を通知し（ｄｅａｃｔｉｖａｔｅ ｔｈｅ ｓｐｏｎｓｏｒｉｎｇ ｃｈａｒｇｉｎｇ）、ＰＣＲＦ ２３０は、これをＰＧＷに通知する。それでは、前記ＰＧＷ ２４０は、１４１５段階で、当該トラフィックフィルタと課金規則を設置解除（ｄｅ−ｉｎｓｔａｌｌする（Ｗｈｅｎ ｔｈｅ ｉｎｓｔａｌｌｅｄ ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ ｒｅａｃｈｅｓ ｔｈｅ ｉｔｓ ｄａｔｅ ｕｓａｇｅ ｏｒ ｒｅｃｅｉｖｅ ｔｈｅ ｄｅａｃｔｉｖａｔｅ ｒｅｑｕｅｓｔ ｆｒｏｍ ＳＮＥＳ、ｉｔ ｄｅ−ｉｎｓｔａｌｌ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｄａｔａ ｒｅｃｏｒｄｓ、ａｎｄ ｓｅｎｄｓ ｎｏｔｉｆｉｃａｔｉｏｎ ｔｏ ｔｈｅ ＰＣＲＦ）。

そして、ＰＧＷ ２４０は、１４１７段階で、ＰＣＲＦ ２３０にスポンサ課金の終了を通知し（ｄｅａｃｔｉｖａｔｅ ｓｐｏｎｓｏｒｅｄ ｃｈａｒｇｉｎｇ（ｓｐｏｎｓｏｒｅｄ ＩＤ、ｓｕｂｓｃｒｉｐｔｉｏｎ ＩＤ（ｏｒ ｃｈａｒｇｉｎｇ ＩＤ）、ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）、前記ＰＣＲＦ ２３０は、１４１９段階で、前記ＳＮＥＳ ２１０にイベント通知（ｅｖｅｎｔ ｎｏｔｉｆｉｃａｔｉｏｎ（ｓｐｏｎｓｏｒｅｄ ＩＤ、加入情報ＩＤ、ｕｓａｇｅ ｄａｔａ ｒｅｃｏｒｄ）をする。前記イベント通知を受信すれば、前記ＳＮＥＳ ２１０は、１４２１段階で、前記ＰＣＲＦ ２３０にＡｃｋメッセージを伝送し、前記ＰＣＲＦ ２３０は、１４２３段階で、前記ＰＧＷ２４０にＡｃｋメッセージを伝送する。

その後、前記ＳＮＥＳ ２１０は、１４２５段階で、前記端末のモバイルＯＳ １３０にスポンサ課金終了を通知する（ｄｅａｃｔｉｖａｔｉｏｎ ｎｏｔｉｆｉｃａｔｉｏｎ（ｄｅａｃｔｉｖａｔｉｏｎ ｍｅｓｓａｇｅ、ｃｏｎｓｕｍｅｄ ｓｐｏｎｓｏｒｅｄ ｄａｔａ ｕｓａｇｅ））を伝送する。それでは、端末のモバイルＯＳ １３０は、１４２７段階で、ＳＮＥＳ ２１０にＡｃｋを伝送する。また、前記モバイルＯＳは、１４２９段階で、コンテンツアプリケーション１２０に受信された警報を伝達し、コンテンツアプリケーション１２０は、これを処理し（Ｃａｌｌ ｔｈｅ ｌｉｓｔｅｎｅｒ ＡＰＩ ｉｆ ｉｔ ｗａｓ ｒｅｇｉｓｔｅｒｅｄ（ｆｏｒ ｅｘａｍｐｌｅ ｄｅａｃｔｉｖａｔｅｄ ｓｐｏｎｓｏｒｅｄ Ｃｈａｒｇｉｎｇ）、ｕｓｅｒ １１０は、１１２９段階で、警報を表示する（ｄｉｓｐｌａｙ ｔｈｅ ａｌｅｒｔ ｍｅｓｓａｇｅ ｔｏ ｔｈｅ ｕｓｅｒ）。上記のように、スポンサ課金を終了した後、オペレータ２００は、スポンサトラフィックに対する課金を行う。図１５は、スポンサ課金を終了した後、スポンサトラフィックに対する課金（ｃａｓｈ ｔｈｅ ｓｐｏｎｓｏｒｅｄ ｔｒａｆｆｉｃ）を行う手続を示す図である。

図１５を参照すれば、スポンサ課金終了時に、オペレータ２００は、１５１１段階で、費用請求とともにコンテンツ提供者３００が発行したクーポン資料を前記コンテンツ提供者に伝達する（ｐｒｅｓｅｎｔ ｔｈｅ ｂｉｌｌ ｔｈｅ ｃｏｕｐｏｎｓ ｉｓｓｕｅｄ ｂｙ ｔｈｅ ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒ）。それでは、前記コンテンツ提供者３００は、１５１３段階で、クーポン検証を行い（ｃｈｅｃｋ ｔｈｅ ｖａｌｉｄｉｔｙ ｔｈｅ ｃｏｕｐｏｎｓ ａｎｄ ｔｏｔａｌ ｕｓａｇｅ）、検証が完了すれば、１５１５段階で、前記オペレータ２００に端末のスポンサトラフィックによる費用を支払う。

図１６は、本発明の第２実施例によるスポンサトラフィックの処理手続を示す図である。

図１６を参照すれば、まず、３ｒｄ ｐａｒｔｙ ｐｒｏｖｉｄｅｒ（サービス提供者、コンテンツ提供者）３００とオペレータ２００との間にスポンサクーポンを処理するために前処理動作を行う。すなわち、第３者サービスを開始しようとするサービス提供者３００のために、オペレータ２００は、スポンササービスを提供する。そして、第３者提供者３００は、オペレータ２００が提供するスポンササービスに加入する。そして、サービス提供者３００は、１６１１段階で、以後オペレータ２００に伝送するメッセージとオペレータが有効性を証明するときに使用する公開キー（スポンサクーポン加入情報＋公開キー）をオペレータに伝達する。そして、前記オペレータ２００は、第３者が接続するオペレータ２００のサーバのアドレス（オペレータオペレータサーバアドレス）とサーバで使用されるプロトコルセットを伝達する。上記のような過程を行いながら、前記サービス提供者３００とオペレータ２００との間にスポンサトラフィックを処理する事前準備を行う。

上記のような状態で、ユーザ端末１００が１６２１段階でスポンサトラフィックを利用するサービスを要請する（例えば、ｅｂｏｏｋ費用支払い後、ｄｏｗｎｌｏａｄ ｂｕｔｔｏｎ ｃｌｉｃｋ）ことができる。この際、前記スポンサトラフィックを要請するとき、現在使用するオペレータｉｄを一緒に伝送する。それでは、前記サービス提供者３００は、スポンサトラフィック要請であることを認識し、１６２３段階で、クーポンを生成する。前記クーポンは、下記表２のような構造を有することができ、前記クーポン内には、スポンサを受ける端末を事業者が認識することができるＩＤ（例えば、電話番号など）とスポンサを受けたｔｒａｆｆｉｃの端末側のアドレス（ＩＰ ａｄｄｒｅｓｓ ＆ Ｐｏｒｔ）などが含まれる。その後、前記サービス提供者３００は、前記生成されたクーポンを前記１６１３段階で前記オペレータ２００から受信したサーバアドレスに前記１６１３段階で受信したｐｒｏｔｏｃｏｌ ｓｅｔを利用して伝送する。

前記クーポンを受信するオペレータ２００は、１６２７段階で、前記１６１１段階で受信したサービス提供者３００の公開キーでクーポンに対する有効性を証明する。そして、前記オペレータ２００は、前記１６２７段階で、前記クーポン内のサーバ情報を利用してスポンサトラフィックに対するフィルタを構成し、前記フィルタに対するトラフィックは、ｓｐｏｎｓｏｒ ｉｄでｃｈａｒｇｉｎｇするように課金規則を設定する。この際、必要に応じて、新しいベアラーを生成後、新たに生成されたベアラーにフィルタと課金規則を設定する。前記オペレータ２００が前記１６２７段階でクーポン有効性、フィルタ設置及び課金規則を設定する動作は、前記図１０のような手続で行われることができる。

前記１６２７段階を行った後、前記オペレータ２００は、１６２９段階で、前記フィルタの設置とクーポン有効性結果をサービス提供者３００に通知する（ｎｏｔｉｆｙ ｃｏｕｐｏｎ ｖａｌｉｄａｔｉｏｎ）。それでは、前記サービス提供者３００は、１６３１段階で、サービス購買を要請した端末に応答し、１６２３段階で生成した前記表２のようなクーポンに入れたサーバアドレスを端末に通知する（ｄｏｗｎｌｏａｄ ｓｅｒｖｅｒ ｉｎｆｏ）。それでは、端末１００は、１６３３段階で、前記１６３１段階で受信されたサーバアドレスにサービスを要請し、スポンサトラフィックサービスを受けることができる。この際、前記スポンサトラフィックに対する課金は、ｓｐｏｎｓｏｒｅｄ ＩＤの加入情報関連課金レコードに記録され、端末に賦課されない。

上記のように、端末が移動通信網を通じてサービス提供者３００のサーバに接続し、所望のデータをダウンロードする状態で、端末は、クーポンの使用モデルによって前記図１１〜図１３のうちいずれか１つの方法で満了警報情報を受信することができる。また、スポンサトラフィックのサービスが終了すれば、図１４のような手続でスポンサ課金不活性化動作を行うようになり、スポンサトラフィックに対する課金（ｃａｓｈ ｔｈｅスポンサトラフィック）は、図１５のような手続で行われる。

すなわち、本発明の第２実施例によるスポンサトラフィック処理手続は、前記図１６のように行われ、前記本発明の第１実施例において端末１００のモバイルプラットホームのＳＮＥ通信クライアントモジュールが第３者にあるＳＮＥクライアントプログラムに存在するということ以外のすべての要素は同一である。

本明細書と図面に開示された本発明の実施例は、本発明の技術内容を容易に説明し、本発明の理解を助けるために特定例を提示したものに過ぎず、本発明の範囲を限定しようとするものではない。ここに開示された実施例以外にも、本発明の技術的思想に基づく他の変形例が実施可能であるということは、本発明の属する技術分野における通常の知識を有する者に自明である。

１００… 端末
１１０… ユーザ
１２０… コンテンツアプリケーション
１３０… モバイルＯＳ
２００… オペレータ
２１０… ＳＮＥサーバ
２２０… Ｕｓｅｒ Ｄａｔａ Ｒｅｐｏｓｉｔｏｒｙ
２３０… ＰＣＲＦ
２４０… Ｐ−ＧＷ（ＧＧＳＮ）
２５０… ＯＦＣＳ
３００… コンテンツ提供者
８１０… スポンサトラフィックポリシーコントローラ
８２０… ＳＮＥクライアント通信機能
８３０… クーポン有効性機能
８４０… スポンサ通信機能
８５０… スポンサクーポン格納所
８６０… スポンサ認証格納所

Claims (11)

1. 移動通信システムで課金制御方法において、
   端末から伝送されるスポンササービス要請受信時に、サービス提供者がスポンサクーポンを生成し、前記端末に伝送する段階と；
   前記端末が前記スポンサクーポンを受信し、オペレータに伝送する段階と；
   前記オペレータが前記スポンサクーポンを利用してスポンサトラフィックに対するフィルタ及び課金規則を設定し、端末に通知する段階と；
   前記端末が前記サービス提供者に前記スポンササービスを再要請し、前記サービス提供者からスポンサトラフィックサービスを提供される段階と；
   前記オペレータが前記サービス提供者に前記スポンサトラフィックに対して課金する段階と；
   を含むことを特徴とする課金制御方法。
2. 前記スポンササービス要請受信段階の前に、
   前記サービス提供者が前記オペレータが提供するスポンサクーポンサービスに加入する段階をさらに含むことを特徴とする請求項１に記載の課金制御方法。
3. 前記加入する段階は、
   前記サービス提供者と前記オペレータが、前記スポンサクーポンに対する有効性を検証するための情報を送受信する段階をさらに含むことを特徴とする請求項２に記載の課金制御方法。
4. 前記スポンサクーポンは、
   前記サービス提供者の識別子、前記オペレータの識別子、前記スポンサクーポン識別子、使用モデル、前記サービス提供者の連結アドレス、または前記スポンサクーポンの使用開始時間のうち少なくとも１つを含むことを特徴とする請求項１に記載の課金制御方法。
5. 前記再要請段階は，
   前記端末がスポンサ課金活性化要請メッセージを前記オペレータに伝送する段階と；
   前記オペレータが、前記スポンサトラフィックに対する課金が前記サービス提供者に課金されるように、課金規則を設定する段階と；
   前記課金規則をポリシー課金規則機能（Ｐｏｌｉｃｙ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）を経由してＰＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）に伝達する段階と；
   前記ＰＧＷが前記課金規則を設置し、応答メッセージを前記オペレータに伝送する段階と；
   をさらに含むことを特徴とする請求項１に記載の課金制御方法。
6. 移動通信システムで課金を制御する装置において、
   スポンササービス利用のためのスポンササービス要請をサービス提供者に伝送し、前記サービス提供者からスポンサクーポン受信時にスポンササービス再要請をオペレータに伝送する端末と；
   前記端末からスポンササービス要請受信時にスポンサクーポンを生成して前記端末に伝送し、前記端末からスポンササービス再要請受信時に前記端末にスポンサトラフィックサービスを提供するサービス提供者と；
   前記端末から前記スポンサクーポン受信時に、前記受信したスポンサクーポンを利用してスポンサトラフィックに対するフィルタ及び課金規則を設定して前記端末に通知し、前記スポンサトラフィックに対して前記サービス提供者に課金するオペレータと；
   を含むことを特徴とする課金制御装置。
7. 前記サービス提供者が、前記オペレータが提供するスポンサクーポンサービスに加入することを特徴とする請求項６に記載の課金制御装置。
8. 前記加入時に、
   前記サービス提供者と前記オペレータが、スポンサクーポンに対する有効性を検証するための情報を送受信することを特徴とする請求項７に記載の課金制御装置。
9. 前記スポンサクーポンは、
   前記サービス提供者の識別子、前記オペレータの識別子、前記スポンサクーポン識別子、使用モデル、前記サービス提供者の連結アドレス、または前記スポンサクーポンの使用開始時間のうち少なくとも１つを含むことを特徴とする請求項６に記載の課金制御装置。
10. 前記オペレータは，
    前記端末からスポンサ課金活性化要請メッセージを受信すれば、前記スポンサトラフィックに対する課金が前記サービス提供者に課金されるように課金規則を設定することを特徴とする請求項６に記載の課金制御装置。
11. 前記オペレータは、
    ポリシー課金規則機能（Ｐｏｌｉｃｙ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）を経由してＰＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）に伝達することを特徴とする請求項１０に記載の課金制御装置。