JP2006501781A - ネットワークにおいて弾力的な課金を提供するシステム - Google Patents

Abstract

本発明は、パケット交換式ネットワークにおける課金処理に関する。パケットは、それがどのサービスフローに属するかに依存して、異なる課金がなされる。課金システムは、コントロールシステムと、パケット転送システムに設けられたサービスを行なう要素と、を備え、前記コントロールシステムは、少なくとも１ユーザの口座を管理するようになされた口座機能と、前記少なくとも１ユーザに対して許可されたサービスに対する課金方針を計算するようになされた課金方針決定ポイントと、を備える。さらに、前記サービスを行なう要素は、トークンバケットに関連して前記ユーザの口座機能から受信した予約を格納するようになされた１ユーザごとのトークンバケットと、前記計算された課金方針に従って前記トークンバケットから前記格納された予約を減少させることによって複数の前記許可されたサービスに対する課金を実行するようになされた課金方針実行ポイントと、を備える。

Description

本発明はパケット交換式通信システムに関し、より詳しくは、リアルタイムに課金を実行する処理に関する。

パケット交換式通信システムは、例えば音声、データ、多種多様なアプリケーションに由来するマルチメディアトラフィックなどの、多くの様々な種類の電気通信トラフィックを運ぶ。ネットワークの運用者は、様々な種類のトラフィックを使用し多様な課金方式を持つ、多様なサービスを提供することができる。

例えばストリーミングのようないくつかのサービスでは、時間ベースの課金を適用することがふさわしく、対照的に、例えばインターネットブラウジングのような他のサービスでは、従量制の課金が唯一可能な課金方法である。時間ベース、分量ベース、及びサービスベースの課金から選択することは、加入者が何に対して支払う意思があるかに関連してなされ、また、受け入れられる納得可能な課金方法を達成するためになされる。例えば、ビデオストリームのようなストリーミングアプリケーションでは、ユーザがビデオを見ることに費やした時間に対して支払うことがユーザにとって納得可能である。

１つの加入契約が複数のユーザを持つ場合もある。加入契約には前払い又は後払いのものがあり、前払いの場合は加入者は事前に、即ち、サービスが利用されるのに先立って、ある金額を支払い、後払いの場合は、例えばユーザが実際にある期間使用した時間やデータ量に対して支払う、ということを意味する。前払いの加入契約をサポートするために、課金方法は「リアルタイムの」性質を持たなければならない。このことは、前払いの加入者の預託金口座が空である時に特に重要であり、サービスの実行（この場合、パケット転送）が直ちに影響を受けなければならない。加入者の口座が空の場合、運用者は少なくとも課金対象であるすべてのサービスを停止することを望む。なぜなら、運用者は、消費されたサービスに対する不払いにより金銭を失うことを防止することに加えて、預託金をコントロールすることを望むからである。例えば口座への補給、緊急電話番号への発信、メンテナンスページ、場合によってはＳＭＳ／ＭＭＳメッセージの受信、などのいくつかの無料サービスは依然として開放されていてもよい。

それゆえ、サービスに基づくパケットレベルにより区別されるレート設定を実行できることが望ましい。しかしながら、パケットレベルにより区別されるレート設定を実行することは根本的な問題を生じる。なぜなら、レート設定は例えば料金プランや時間、分量の閾値、加入者のプロファイルなどの多数の入力パラメータを伴う複雑な処理であり、一方で、パケット転送は可能な限り最小限の待ち時間で実行されなければならないからである。それゆえ、パケット転送システム及びレート設定エンジンはそれぞれ、異なるシステム要件を有する。

ここで、従来技術における課金システムを「マルチプルトークンバケット(multiple token bucket)」システムと呼ぶ。そのようなシステムは図１に開示されるようなコントロールシステム及びパケット転送システムを備える。コントロールシステム１０１は、レート設定エンジン１０２及び預託金口座１０３を備える。パケット転送システム１０４は、サービスフロー(service flow)１０６及びユーザごとに１つのトークンバケット１０５を備え、その結果、複数のサービスが使用されるならば各々のログインしているユーザに対してマルチプル（複数の）トークンバケット１０５をもたらす。

ユーザが通信システムにログインすると、パケット転送システム１０４は各々のサービスについてコントロールシステム１０１に対しコントロール信号シーケンスを開始する。コントロールシステム１０１は加入者の預託金口座に事前に定められた金額の預託金を蓄え、この金額は「預託金(credit reservation)」と呼ばれる。コントロールシステム１０１はこのユーザが利用を許可されるサービスの組を決定する。これらの許可されたサービスについての識別子の組は、パケット転送システムに送信される。各々のサービス識別子について、パケット転送システム１０４はリソース予約信号シーケンスをコントロールシステムに対して開始する。それらの各々の信号シーケンスに対して、コントロールシステム１０１のレート設定エンジン１０２が料金プランを使用して、サービスがレート設定される。レート設定の値は、預託金の一部を「リソース予約(resource reservation)」（それは、典型的には、関係するデータ量）に変換するために使用され、それはパケット転送システム１０４に返送される。各々のリソース予約は特定のリソーストークンバケット１０５に入れられる。それゆえ、パケット転送システム１０４はマルチプル（複数の）トークンバケット１０５を備え、ユーザごとに各々の許可されたサービスに対して１つ割り当てられる。

トラフィックが通信システムを介して流れているとき、パケット転送システム１０４は、そのパケットがどのサービスフローに属するかを決定するために各々のパケットを分類する。そして、そのサービスに対するトークンバケット１０５がデクリメントされる。トークンバケット１０５が空になると、コントロールシステムに対してその処理の確認がなされ、新たなリソース予約がなされる。

それゆえ、パケット交換式通信システムにおけるパケット単位かつリアルタイムの課金を実行するマルチプルトークンバケット法は、そのパケットがどのサービスフローに属するかに依存して異なって課金され、許可されたサービスの組における各々のサービスフローに対して別々のリソース予約信号シーケンスを必要とする。このことは、コントロールシステムとパケット転送システムの間に多量の信号トラフィックを発生させる。加えて、このことはコントロールシステム及びパケット転送システムそれぞれに高い処理能力を要求し、かつ、前記システム間の高い転送能力を要求する。

さらに、マルチプルトークンバケット法は、不要な予約が実行されるので、他の欠点を有する。マルチプルトークンバケットの場合、事前に定められた量のリソースが各々のサービスに対して予約され、各々のトークンバケットの預託金は特定のサービスフローに専用なものとなる。このことは、利用されていないサービスに対してなされた預託金は、実際に利用されている他のサービスのためには使用され得ないということを意味する。それゆえ、このことは上述の不要な予約を招来する。さらに、その問題はサービスの数が増加すると、より悪化する。

他の可能な解決法としては、移動体通信ネットワークにおいて異なるコンシューマーサービスフローを区別するために、いくつかのＧＰＲＳのアクセスポイント識別番号(Access points Names, APN)を使用することがある。ＡＰＮは、携帯電話ネットワークにおける１つ以上のサービスフローに対するラベルである。しかし、この方法には、端末におけるＩＰアドレスの管理と同様、例えば端末とネットワークにおいて、ＡＰＮの設定管理に起因する欠点がある。それゆえ、この方法は設定及びコントロールする追加の管理を運用者に要求する。ネットワーク運用者はそれゆえ、１つのＡＰＮごとに複数のサービスを扱い、望ましくは１つのＡＰＮがすべてのサービスフローを扱う方法を好む。

上述のように、従来技術におけるマルチプルトークンバケット法は、コントロールシステムとパケット転送システムの間で多量の信号トラフィックを必要とする。加えて、マルチプルトークンバケット法は、多くの場合、上述の不要な予約をもたらしやすい。さらに、携帯電話ネットワークにおいて複数のサービスフローが１つのアクセス先識別番号（ＡＰＮ）に関連付けられる方法を達成することが望ましい。なぜなら、１つのＡＰＮごとに１つのサービスフローしか持たない方法は上述のような設定管理に関する欠点を有するからである。

それゆえ、本発明の第１の目的は、コントロールシステムとパケット転送システムの間の信号を減少させることによって、弾力的なリアルタイムの課金を提供する処理を達成することである。

本発明の第２の目的は、不必要な予約を防止することである。

本発明の第３の目的は、サービスフローがパケットレベルで区別され、適切な課金が弾力的な方法で適用される、課金システムを提供することである。すなわち、各々のパケットは、そのパケットがどのサービスに属するかに依存して異なって課金されることが可能である。

本発明の第４の目的は、ＡＰＮごとの複数のサービスを促進する方法を達成することである。

上述の目的は、請求項１に記載のシステム、請求項１２に記載のコントロールシステム、請求項１８に記載のサービスを行なう要素、請求項２９及び３０に記載のインタフェースによって達成される。

本発明における課金システムにより、コントロールシステムとパケット転送システムの間の信号を減少させることが可能となる。課金システムは、コントロールシステムと、パケット転送システムに設けられたサービスを行なう要素と、を備える。前記コントロールシステムは、少なくとも１ユーザの口座を管理するようになされた口座機能と、前記少なくとも１ユーザに対して許可されたサービスに対する課金方針を計算するようになされた課金方針決定ポイントと、を備える。前記サービスを行なう要素は、トークンバケットに関連して前記ユーザの前記口座機能から受信した予約を格納するようになされた１ユーザごとのトークンバケットと、前記計算された課金方針に従って前記トークンバケットの前記格納された予約を減少させることにより複数の前記許可されたサービスに対する課金を実行するようになされた課金方針実行ポイントと、を備える。

本発明の第１の実施例によれば、前記課金機能に対する不必要な予約をする危険性を減少させることは、１ユーザごとに複数のサービスフローによって共有される単一のトークンバケットを持つことにより、実現される。

本発明の他の利点は、レートの変更がある時間帯（ＴｏＤ）に実行されなければならない場合に、課金方針の中に、ユーザレート設定テーブルの一部であるＴｏＤ前後両方のレートを含むことにより、信号負荷が減少され得ることである。さらに、ユーザ預託金口座が空になる又は所定の閾値に到達したときに、課金方針のおかげでトラフィックに対するきめの細かい方針コントロールを適用することが可能である。

本発明の他の利点は、１加入者ごとに単一のトークンバケットを使用するという概念は、ネットワークにおけるトークン予約の分散を減少させ、その結果、多くの異なる予約に起因して前払い口座が空になる危険を減少させる。それはまた、サービスを行なう要素とゲートウェイ、ひいては前払いシステムの間のコントロール信号を減少させ、それゆえ、３つすべての機能のための物理的な箱の必要性を減少させる。

本発明の他の利点は、サービスクラスという概念により、運用者が、関連する複数のサービスを複数のグループに分類することが可能となる。すなわち、同一の料金を持つ複数のサービスは１つのグループに分類される。それゆえ、同一のサービスクラス中のサービス間の関係は、料金が同一でなければならない以外は任意である。なぜなら、レート設定はサービスクラスに基づくからである。さらに、各々のユーザが特定のサービスクラスに対して異なる料金を持ち得るが、特定のユーザに対して、サービスクラス中のすべてのサービスは同一のレート設定（ある特定の時間に）を持ち、それは、あるサービスクラスに属するすべてのパケットは、レート設定エンジンに対するコントロール信号を必要とせずにリアルタイムにそのサービスクラスに関係するレート設定の値に従ってレート設定されるということを意味する。サービスのグループ化にある利点は、１加入者ごとのデータ量が劇的に減少することである。一例として、サービスの数が数千の規模であっても、サービスクラスの数は百程度までであろう。サービスクラスの概念はまた、運用者側でのサービス認証の基礎となる。加えて、サービスクラスの概念は、ユーザにとっての複雑さを減少させ（異なるサービスに対する課金方式がより容易に理解できるようになる）、課金システムの処理をスピードアップさせる。なぜなら例えば、ユーザレート設定テーブルのサイズが減少するからである。

本発明の他の利点は、サービスの利用を開始する時（例えばＭＭＳメッセージを取得する時）の遅延が減少し、それにより、エンドユーザの満足度の向上とより高いデータのスループットにつながる。これは、加入者の接続における動的な事前レート設定によって達成され、このことは、有効条件を含むすべての適用可能なレート設定の値は、加入者が異なるサービスの使用を開始する前に計算されるということを意味する。それはまた、コントロール信号トラフィックを減少させ、それゆえ、レート設定エンジンの負荷を減少させる。トラフィックデータスループットの増大及びコントロール信号トラフィックの減少により、ネットワークにおいてより少ない物理的な箱ですむようになる。レート設定の値が明白な有効性を持ち、更新されても良いので、高い水準のレート設定の弾力性が維持される。

本発明の他の利点は、サービスフィルタ及びプロトコルインスペクションフィルタ（ＰＩＦ）の概念により、運用者は、サービスフィルタのルールを割り当てるだけで、トラフィックデータスループットを増加させることにつながる、サービスに対するフィルタルールを指定することが可能になるが、サービスを区別する必要があるときはより高度なフィルタルールを起動する可能性が依然としてあるということである。それゆえ、ＰＩＦは、サービスフィルタの手段によって、即ち、ＩＰアドレスの使用によって、サービスフロー間の区別が不可能な場合にのみ使用され、パケット転送システムにおけるより高いスループットという結果につながる。そのような概念は、他のサービスのために必要なときに新たなルールをさらに含めることを可能にする、一般的なものである。

本発明の他の利点は、課金システムが「一度の最初の課金」を取り扱うように構成されることである。トークンの最初の分量は、サービスの開始の前又はその間にトークンバケットからデクリメントされる。

本発明の実施例のさらなる利点及び目的は、添付の図面を参照した以下の詳細な説明を読めば、明らかになるであろう。

以下、本発明の好適な実施例が開示される添付図面を参照して、本発明をさらに詳細に説明する。しかしながら本発明は、多くの異なる形態で実施されてもよく、ここで説明する実施例に限定されるものとして解釈されてはならない。むしろ、これらの実施例はこの開示が詳細かつ完全なものとなるように提供されるものであり、本発明の範囲を当業者に十分に伝達するものである。図面において、同一の符号は同一の要素を示す。

本発明によれば、リアルタイムの課金システムは、インターネットのようなＩＰネットワークやＧＰＲＳ／ＵＭＴＳ／ｃｄｍａ２０００システムのようなパケット交換式移動体通信ネットワークにおいて実現される。本発明の実施例がＧＰＲＳ／ＵＭＴＳシステムに関連して開示されたとしても、本発明はそのようなシステムに限定されるものではない。

図２に示される本発明の実施例によって提案される課金システムの方法は、コントロールシステム２０１及びサービスを行なう要素２０６を備える。コントロールシステム２０１は、レート設定エンジンとも呼ばれる課金方針決定ポイント２０２、及び、リアルタイムの課金目的のためにユーザの預託金口座を管理する預託金口座機能２０３を備える。サービスを行なう要素２０６は、課金を実行するための、すなわち、トークンバケット２０８の減算を管理するための、課金方針実行部２０７を備える。サービスを行なう要素のトークンバケットは、ログインしている１ユーザごとに複数のサービスに対して使用される。望ましくは、単一のトークンバケットが、ログインしている１ユーザごとにすべてのサービスに対して使用される。加えて、サービスを行なう要素は、そのパケットがどのサービスに属するかに基づいてパケットを区別する手段を備える。サービスを行なう要素は、例えばスイッチ、ルータ、プロキシ、ＧＰＲＳ／ＵＭＴＳシステムにおけるＧＰＲＳゲートウェイサポートノード（ＧＧＳＮ）、ｃｄｍａ２０００システムにおけるＰＤＳＮノードやホームエージェントのような、パケット転送システムに設けることができる。

本発明のシステムは、複数のサービスのためのすべての預託金を、パケット転送システムにおいてサービスを行なう要素内の１ユーザごとに単一のトークンバケットに収集する手段を備える。預託金口座機能は、すべてのサービス、即ち、後で詳細に説明するユーザサービスベクトルの中に含まれるサービスそれぞれに対して予約されるべき預託金の金額の情報を、特定のユーザにサービスを行なう要素のトークンバケットに送信する。預託金の金額は、ネットワーク運用者によって実行された、事前に定められた設定に従って予約される。複数のサービスのためのすべての預託金の収集は、すべて、単一のトークンバケットの中で可能となることが望ましい。これはサービスに対する課金方針がコントロールシステムによって本発明に従って計算され、サービスを行なう要素に送信されるおかげである。課金方針の計算はここでは、動的な事前レート設定と呼ばれ、後で詳細に説明する。

本発明は前払い及び後払い両方の加入契約に対するリアルタイムの課金に適用可能である。後払いの場合、トークンバケットはマイナスの値をとり、一方先払いの場合、ユーザは予約した以上の預託金を使用することは許されないため、トークンバケットはマイナスの値をとることが許されない。さらに、本発明はまた、サービスを行なう要素の設定に依存して、分量ベース、時間ベース、そしてサービスベースの課金すべてに適用可能である。

＜例１＞
本発明における課金システムを備える通信システムにユーザがログオンすると、サービスを行なう要素は、その要素とコントロールシステムの間でコントロール信号シーケンスを開始する。コントロールシステムは、このユーザが利用を許可されるサービス識別子の組を決定する。コントロールシステムのレート設定エンジン３０１は、料金プラン３０３及び他の入力データに基づいて課金方針３０４を計算する。他の入力データとは例えば、時間帯(Time of Day, ToD)、ユーザのローミング状態、ユーザへの総転送データ量、その他のユーザ固有の使用履歴などである。ユーザが既にログオンしている場合、現在の使用状態もまた、ユーザレート設定テーブルの計算に活用される。その状態とは例えば、ユーザのトークンバケットが空になり、即ち、１つの有効条件が達成されておらず、サービスを行なう要素が新たなユーザレート設定テーブルをコントロールシステムから要求するような状態である。この計算は図３に示されており、動的な事前レート設定と呼ばれる。課金方針は、ユーザレート設定テーブル３０５、及び、有効条件３０６の組、を備える。ユーザレート設定テーブル３０５は、ユーザが利用を許可される各々のサービスクラスに対するレート設定の値を含み、有効条件の組は、ユーザレート設定テーブルが有効である条件を定義する。サービスクラスの概念は、課金方針のユーザレート設定テーブルのサイズを制限するために本発明において導入される。サービスクラスとは、厳密に同一の課金パターンすなわち同一の料金プランを持つ、共通の属性を持つサービスのグループである。計算された課金方針はパケット転送システム内のサービスを行なう要素に送信される。

次に、パケット転送システム内でサービスを行なう要素が、予約信号シーケンスを、コントロールシステムの預託金口座機能に対して開始する。預託金口座機能は、ユーザの預託金口座に対して事前に定められた設定に従った預託金の金額を予約する。その金額は、預託金と呼ばれる。預託金は、複数のサービス、望ましくはすべてのサービスに対してなされ、総合的な預託金は、サービスを行なう要素に送信され、ユーザ固有のトークンバケットに入れられる。

トラフィックがパケット転送システムを介して流れる時、パケット転送システム内でサービスを行なう要素は、各々のパケットをそれがどのサービスクラスに属するか決定するために分類する手段を備える。受信した計算された課金方針は、トークンバケットから減じられるべき預託金の金額を決定するために使用される。なお、減算量はまた、ボーナスサービス、すなわちユーザが特定のサービスを使用するとお金をもらえるサービスをサポートするために、マイナスの値をとることもできる。

パケット転送システム内のサービスを行なう要素は、課金方針の有効条件が依然として有効であるかを継続的に調べる。有効条件の例には、時間、トークンバケットの閾値、地理的地域などがある。有効条件がもはや有効ではなくなると、新たな更新された課金方針を取得するために、信号発信シーケンスが開始される。一日のある時間（ＴｏＤ）にレートの変更が行なわれる場合、課金方針すなわちユーザレート設定テーブル部分は、ＴｏＤの前後両方で使用されるレートの値を含む。その結果、膨大な数のユーザに対して短い限られた時間で多数の信号を発生させてしまうような、膨大な数のユーザに対する課金方針が同時に更新される必要が無く、更新は比較的長い時間に実行されることができ、信号発信の最大負荷を減少させる。

図４は、有効条件と相関のあるユーザレート設定テーブルを備える課金方針の一例を示す図である。

トークンバケットが空であったり所定の閾値に達している場合、利用がコントロールシステムに対して確認され、新たなリソース予約がなされる。確認信号において、異なるサービスの利用についての情報が、望ましくは明示的に付加される。

＜基本的な用語＞
以下では、本発明に従った弾力的な転送課金システムの基本的な用語を説明する。
・「ユーザ」とは、運用者が提供するサービスにアクセスする人である。
・１人以上のユーザが１つの「加入契約(subscription)」に接続できる。
・「加入者(subscriber)」とは、加入契約の所有者である。
・「リアルタイム」の課金とは、サービスが要求されている間又は要求された後に課金処理がなされることを意味する。なお、３ＧＰＰでは「オンライン課金(on-line charging)」の語を用いる。
・「トークン」とは、切符(ticket)のようなものである。サービスの利用には、例えばトラフィック量や利用時間に基づいて事前に定められた量の切符／トークンを必要とする。
・「トークンバケット」とは、１ユーザのためのすべてのトークンが集められる場所である。
・「サービス」とは、特定の宛先へ、或いは特定の宛先からのすべてのＩＰフローの集まりであり、ＩＰパケットのヘッダやペイロード(payloads)内の情報によって決定される。
・「サービス識別子(service identifier)」とは、サービスに固有の識別子である。
・サービスクラスは、例えば課金やサービス認証に関して運用者が同様に取り扱うことを望むサービスの任意のグループに対する識別子である。１つのサービスは、１ユーザごとに一度に１つのサービスクラスにのみ属することが、許可される。
・「料金プラン(tariff plan)」とは、サービスが有効なときにサービスに対する価格を規定するものである。
・「レート設定の値(rating value)」とは、特定のサービスに対してトークンバケットから減じられるべき分量のことである。
・本発明による「サービスクラス」は、同一の料金プランを持つすべてのサービスを含む。
・「サービスフィルタ」とは、特定のサービス識別子を持つサービスを扱う特定のフィルタ設定のことである。それゆえ、サービス識別子はサービスをそのサービスフィルタに位置付ける(map)ために使用される。この用語は、後にさらに詳細に説明する。各々のサービスフィルタには、宛先とソースとの内の少なくともいずれか（トラフィックの方向に依存する）のＩＰアドレス（及びマスク）、ＴＣＰ及びＵＤＰポート番号（範囲）、そしてプロトコル番号が設定され得る。より上位のプロトコル層のインスペクション（検査）を扱うために、サービスフィルタは「プロトコルインスペクションフィルタ(Protocol Inspection Filter, PIF)」へのポインタを含み、それはステートフルパケットインスペクション(stateful packet inspection)を実行する。パケットインスペクションは、静的なサービスフィルタとは対照的に、動的に実行される。このことは、ＰＩＦは例えば以前のイベントに基づいたパケットインスペクションを実行することを意味する。ＰＩＦは特定の構成データ（図８ｂ参照）を持ち、例えばＵＲＩを含む。動的フィルタは定義されたＰＩＦルールに合致するパケットに対して実際のフィルタリングを実行するように設定される。最後に、サービスフィルタとＰＩＦ設定方針は、着信パケットに合致するフィルタの結果を代表するサービスクラス識別子を含む。「サービスクラス識別子」はサービスクラスを識別し、それゆえ、パケットに適用されるレート設定を決定する。サービスフィルタ及びＰＩＦの設定は、望ましくは、アクセスポイント識別番号(Access Point Name, APN)ごとに基づいたパケット転送システムで実行される。

＜本発明の好適な実施例＞
本発明に係る課金システム及び方法を、以下、ＧＰＲＳ／ＵＭＴＳシステムに関連して説明する。上述のように、ＧＰＲＳやＵＭＴＳシステムのような移動体通信システムに実現される課金システムの一実施例は、次のものを備える。
・図８に示すように、ＧＧＳＮ８００においてサービスを行なう要素８０１。サービスを行なう要素については後にさらに説明する。
・本発明によるレート設定エンジン、すなわち課金決定ポイントを含むコントロールシステム。それによって運用者は、サービスと料金プランを決定でき、それはさらに、サービスを行なう要素にレート設定情報を課金方針の形態で動的に提供する。コントロールシステムはさらに、預託金口座機能を備える。
・弾力的なインタフェースオプションによる手段によって運用者の前払いシステムに相互作用(interworking)のための結合ポイントを提供するゲートウェイ。前払いシステムが例えばラディウス(Radius)インタフェースをサポートする場合、ＧＧＳＮはそれと直接接するように構成される。

なお、本発明の実施例に係るその課金システム及び方法が以下でＧＰＲＳ／ＵＭＴＳシステムに関連して説明されていたとしても、そのシステム及び方法はそのようなシステムに限定されるものではなく、他のパケット交換式通信システムにも利用可能である。

＜区別されたパケットレート設定＞
上述のように、パケットレベルの区別されたレート設定は、多くの入力パラメータ（料金プラン、時間及び分量の閾値、加入者プロファイル、など）を含む複雑な処理であるが、パケット転送は可能な限り最小の待ち時間で実行されなければならない。

本発明に係る課金システムは、２つの段階でレート設定処理を使用する。
・課金方針を提供し、本発明に係るレート設定エンジンによって実行される「動的な事前レート設定処理」。
・例えば提供された課金方針に従って、ＧＧＳＮにおいてサービスを行なう要素によって実行される「リアルタイムのパケットレート設定」。

動的な事前レート設定処理は、加入者が利用を許可される各々のサービスクラスに対するレート設定の値の組を含む、課金方針を計算する。課金方針は、ユーザレート設定テーブル及び有効条件の組を含む。この計算には、料金プラン及び、例えばローミング状態や時間帯などの現在の加入者の状態を活用する。レート設定の値は、有効条件の組による限られた存続期間を持ち、例えば料金の閾値に達したときに更新されなければならない。有効条件は、時間以外の他のパラメータにも関連する。それゆえ、ユーザが何らかのサービスを利用開始する前に動的な事前レート設定が実行され、課金方針はサービスを行なう要素に提供される。

リアルタイムのパケットレート設定は、あるサービスクラスに属するものとしてパケットを分類し、そのパケットに対する既に計算されたレート設定の値を使用することにより、実行される。これは、転送処理において極めて小さな遅延で実行可能である。なぜなら、各々のサービス開始に対して、コントロールシステムと転送システム中のサービスを行なう要素間の信号発信は回避されるからである。

例えば、サービスベースの課金を持つサービス（例えばＭＭＳ）に対する、分量に依存しない課金の実行の場合がある。そのようなサービスでは、動的な事前レート設定処理は、「０」のレート設定の値をとる。リアルタイムのパケットレート設定では、「０」の値を使用し、それゆえ、そのトラフィックに対して課金は発生しない。

＜レート設定エンジン＞
図３は、本発明の好適な実施例のレート設定エンジンがユーザレート設定テーブルを生成することにより動的な事前レート設定処理をどのように実行するかを示す図である。ユーザレート設定テーブルは、ユーザサービスクラスベクトル、料金プラン、追加情報（例えばローミング状態、レート設定エンジンのデータベース中に蓄えられた総量や総接続時間、時間帯、地理的位置など）を組み合わせることにより生成される。ユーザレート設定テーブルに加えて、課金方針を生成するために、対応する有効条件の組が、料金閾値を使用して生成される。ユーザレート設定テーブル及び有効条件を含む課金方針が、例えばＧＧＳＮに設けられたサービスを行なう要素に提供される。

即ち、レート設定エンジンは以下の処理を実行する手段を備える。
・ユーザレート設定テーブルの要求を受け取ること。ここで、要求の入力はユーザ識別子、例えばＭＳＩＳＤＮ、ＳＧＳＮ ＩＰアドレス、ＰＤＰコンテクストのＱｏＳなどがある。
・以下でさらに説明する、加入者のユーザサービスクラスベクトルを受信すること。
・その加入者のユーザサービスクラスベクトルにおいて各々のサービスクラスに対するサービス定義を受信すること。
・このユーザについての、例えば転送履歴などの総量と総接続時間（望ましくは、レート設定エンジンの内部データベースに格納されている）を受信すること。
・各々のサービスクラスに対するＳＧＳＮ ＩＰアドレスに基づくローミング状態を計算すること。
・料金プランを使用する関係するレート設定の値及び関係するレート設定の範囲(dimension)、例えばユーザのローミング状態、総量及び総接続時間、ＴｏＤ、地理的位置などの情報、を計算すること。
・ローミング状態、レート設定エンジンのデータベースに蓄えられる総量及び総接続時間、ＴｏＤ、地理的位置などのレート設定の範囲における料金閾値を使用する、これらのレート設定の値に対する有効条件を計算すること。
・上述の計算に基づいてユーザレート設定テーブルを構築すること。
・構築されたユーザレート設定テーブル及び計算された有効条件を、本発明における課金方針の形態で、パケット転送システム内でサービスを行なう要素の課金実行ポイントに対し、送信すること。

＜サービスを行なう要素＞
本発明によれば、サービスを行なう要素は、パケット転送システム８００に設けられており、課金実行ポイント８０２、サービスの分類を実行する手段８０５、及び１ユーザごとに複数のサービス（望ましくはすべての許可された利用可能なサービス）を扱う１つのトークンバケット８０３を備える。このように、上述の実施例では、サービスを行なう要素はＧＧＳＮ８００に含まれる。図８は、サービスを行っている要素の概要を示す機能ブロック図である。

サービスフィルタ及びＰＩＦの設定は、サービスを行なう要素内で設定される。ＧＰＲＳ／ＵＭＴＳネットワークでは、これは望ましくはコアネットワークの運用及びサポートシステムを使用して実行される。サービスを行なう要素は、サービスフィルタに従ってパケットインスペクションを実行するようになされる。いくつかの場合では、必要なら、それはより上位層のプロトコルを解析するためにプロトコルインスペクションフィルタ（ＰＩＦ）を起動する。

前払い及び後払いの加入者に対して、サービスを行なう要素は、上述のような動的な事前レート設定及び予約機構を活用する。サービスを行なう要素は、後払い及び前払いの加入者を、課金特性情報を使用して又は加入者識別子（例えば携帯電話ネットワークの場合ＩＭＳＩ）の解析により、区別する。サービスを行なう要素は、運用者側のサービス認証を実行するために前払い及び後払い両方の加入者に対してユーザサービスクラスベクトルを取得するように設定される。さらに、サービスを行なう要素は、後払い及び前払い両方の加入者に対して預託金コントロールを実行するようになされる。

サービスを行なう要素は、レート設定エンジンからユーザレート設定テーブルを要求する。これは、例えばＰＤＰコンテクストアクティベーションによる接続設定、又はユーザレート設定テーブルの有効条件がもはや有効でないことをトリガーとする。新たなユーザレート設定テーブルが要求されると、サービスを行なう要素は、レート設定エンジンに対し、「最初のレート値」の状態と共に、転送量及び接続時間を報告する。

サービスを行なう要素は、前払い及び後払いシステムに対してゲートウェイを介して予約を行なう手段８０４を備え、それによって、パケット転送システム（例えばＧＧＳＮ）のサービスを行なう要素に保持される各々のユーザのトークンバケットを充填する。予約量及び有効条件は、サービスを行っている要素で設定可能である。それは、ユーザレート設定テーブルに従って各々のユーザのトークンバケットから減算する。

＜サービス分類＞
サービス分類は、パケット転送システム内のサービスを行なう要素にある手段によって実行される。本発明の一実施例によればパケットを分類する手段はサービスフィルタとＰＩＦとの内の少なくともいずれかである。それゆえ、分類はＩＰヘッダ情報とより上位層のプロトコルとの内の少なくともいずれかに基づいて実行される。本発明の一実施例に係るシステムのアーキテクチャは一般的なステートフルインスペクション及びＵＲＩの識別をサポートするが、最初の照準は、ＷＡＰ１．ｘ及び２．ｘ上のＭＭＳトラフィックを検出することに置かれる。パケットがあるサービス及びサービスクラスに属すると分類されると、リアルタイムのパケットレート設定は、計算された課金方針に従ってレート設定の値を決定する。トークンバケットは、そこで、決定されたレート設定の値に従って調整される。

本発明におけるパケット転送システム（望ましくはＧＧＳＮ）内でサービスを行なう要素は、加入者の前払い口座が空になると、ある方針を実行するようにもなされる。ローミング状態に依存して、ＰＤＰコンテクストは、アクティベーションが無効化(de-activated)されたり、無料でないパケットは停止されたりするが、無料のトラフィックは、例えば補給ページ、即ち、預託金口座が空になったときにユーザが入るデフォルトのウェブページにアクセスを許可するために、通過させられる。例えば、そのような補給ページから口座に再補給することが可能である。

ネットワーク運用者にとってのこの上述の２段階アプローチの利点は、もしスループットや待ち時間が最も重要なら、Ｅメールやインスタントメッセージのようなサービス、企業のゲートウェイへのトラフィック、インターネットへのトラフィックは、サービスフィルタでＩＰヘッダインスペクションだけを使用すれば定義可能であり、ＰＩＦは必要でない。しかし、ＷＡＰ上のＭＭＳのような他のサービスでは、ＩＰヘッダインスペクション（すなわちサービスフィルタ）では十分でない。ペイロード、この場合ＵＲＬ／ＵＲＩ、のより詳細なインスペクションが必要である。それゆえ、このアプローチは、それが要求されない場合はステートフルパケットインスペクションのオーバヘッドを回避する。それゆえ、本発明の基本的な思想の一つは、サービスフィルタの使用を開始することであり、その後、必要な場合にのみＰＩＦを継続することである。

＜例２＞
図７ａ及び７ｂは、運用者のゲートウェイがサブネット100.10.0.0/16に配置されている例を示す図である。これらのＷＡＰゲートウェイもまた、ＨＴＴＰプロキシとして機能するようになされているものとする。サービスフィルタ１及び２は共に、このサブネットへの或いはそのサブネットからのパケットに合致する。フィルタ１は、送信プロトコルであるワイヤレスセッションプロトコル（ＷＳＰ）に合致するように設定され、図７ａのＰＩＦポインタに従ってＰＩＦナンバー１を起動する。一方、フィルタ２は転送プロトコルであるＨＴＴＰに合致し、ＰＩＦナンバー２を起動する。流入するパケットはＷＳＰへの合致をもたらすＷＡＰパケットであるものとする。ＰＩＦ１はＰＩＦ設定において、この場合ＵＲＬ／ＵＲＩである識別子データを使用する。本実施例では、それは運用者のＭＭＳセンターのドメインネームをチェックする。もしパケットのＷＳＰヘッダがこれらのドメインネームのいずれかを含んでいれば、その結果のサービスクラスは１４である。もしパケットが他の何らかのＵＲＬ（ワイルドカード「＊」）を含んでいれば、そのパケットはＭＭＳではないＷＡＰトラフィックであり、サービスクラス１５に分類される。

図７ａに戻って、サービス識別子３を持つサービスフィルタは、例えばパートナーのサービスプロバイダであるサブネット100.12.0.0に合致するように設定される。このサービスプロバイダへの或いはそのサービスプロバイダからのすべてのパケットは、サービスクラス２２に分類される。最後に、サービス識別子４を持つサービスフィルタであり、「他のトラフィック」を意味するワイルドカードルールに合致するパケットは、サービスクラス６０に分類される。

ユーザプロファイル及びユーザサービスクラスベクトル
図５に示すユーザプロファイルは、本発明におけるユーザサービスクラスベクトルと共に、加入者識別子ＭＳＩＳＤＮを含む。ユーザサービスクラスベクトルは、ユーザが利用を許可されるサービスのリストである。

特に、運用者が運用者側でのサービス認証を実行することを望む場合、ユーザサービスクラスベクトルは、加入者がどのサービスクラスにアクセスを許可されるかをコントロールすることに使用される。ユーザサービスクラスベクトルは、サービス認証及び加入者提供システムを介して提供される。これにより、補給ページの基礎も形成する、加入者のポータルサイトを介した自己供給が可能となる。なお、もし運用者がサービス認証の利用を望まない場合は、すべての利用可能なサービスクラスがユーザサービスクラスベクトルにリストアップされる。

図７ａ及び７ｂを併せて示される例を続けると、図５のユーザプロファイルにより、ユーザがサービスクラス１４（ＭＭＳトラフィック）、１５（他のＷＡＰトラフィック）、２２（パートナーのサービスプロバイダ）、６０（他の一般的なインターネットアクセストラフィック）にアクセスすることが許可される。ユーザプロファイルは、顧客関係管理システムによって管理され、共通ディレクトリに格納される。どこにユーザプロファイルが格納されているかとは無関係に、それらは本発明におけるレート設定エンジンに複製される。

再び前項の例に戻ると、図６は簡略化された料金プランを示す図であり、サービスクラス１４（ＭＭＳトラフィック）は加入者がローミングを行なっている時以外は無料であり、サービスクラス１５（他のＷＡＰトラフィック）は１バイトにつき−２トークンにレート設定がされている。パートナーのサービスプロバイダへの或いはそのサービスプロバイダからのトラフィック（サービスクラス２２）はローミングを行なっている時以外は無料である。これらのレート設定の範囲は、独立したものであり、例えば特定のレートが、「午後６時から午前６時、３メガバイト以上、ローミングをしている時」のように組み合わせられてもよい。図６の料金プランは本発明における前記レート設定エンジンに使用される方法を模式的に簡略化したものにすぎない。

ユーザサービスクラスベクトルにおける各々のサービスクラスに対して、動的な事前レート設定の計算が５つのレート設定の値を生成する。それは、「最初のレート値」、２つの「現在のレート値」、２つの「次のレート値」である。料金プランとユーザサービスクラスベクトルの間の相互作用に関するさらなる情報を、以下で説明する。最初のレート値は、サービスクラスが最初に利用された時、又は、そのサービスクラスがその加入者に対する設定の値に依存する最初に使用されたサービスクラスに対して用いられた時に、差し引かれるべきトークンの数と等しい。それゆえ、最初の費用はサービス又は加入者に基づく。

「最初に」の意味の異なる設定（例えば１日ごと又は１ヶ月ごと）を取り扱うために、次の動的な事前レート設定の計算に使用される「最初のレート値」の適用に関する情報が、レート設定エンジンに供給される。「現在のレート値」は、直ちに使用されるであろうサービスクラスに属するパケットに対して課金される、１バイトごとのトークンの数である。下の有効条件を参照されたい。２つの「現在のレート値」を持つ理由は、上り及び下りのトラフィックそれぞれに対して異なるレート設定の値を可能にするためである。「次のレート値」は、「現在のレート値」の期限切れの後に使用される。「次のレート値」の目的は、ある時点における一括更新を管理するためである。すなわち、極めて多数のユーザに対して短い限られた時間に多数の信号を発生させる原因となりうる、極めて多数のユーザに対する課金方針が同時に更新される必要が無く、更新は長い時間に実行することが可能であり、このことはその限られた時間の間の単位時間当たりの信号負荷を減少させる。

課金方針４００のこれらのすべてのレート設定の値は、図４に示すようにユーザレート設定テーブル４０１を形成するためにサービスクラスごとにリストアップされている。ユーザレート設定テーブルは、有効条件４０２の組で特定される限られた存続期間を持ち、それは次のような範囲の料金閾値を使用して計算される。それは例えば、ローミング状態（ホーム又はアウェイ）、地理的位置、月／年などを含む時間帯（ＴｏＤ）、転送履歴とも呼ばれる総分量、接続（すなわちＧＰＲＳやＵＭＴＳ接続のＰＤＰコンテクスト）のＱｏＳなどである。分量／時間／位置に関連する閾値に達したときに、更新されたユーザレート設定テーブルを要求することは、サービスを行なう要素の責務である。それゆえ、課金システムは過去と現在の内の少なくともいずれかのユーザ固有の使用データを利用する。

本発明のシステムは「一度の最初の課金(one-time initial charge)」と呼ばれるサービスベースの課金をサポートするようになされる。「一度の最初の課金」原則に従って課金されるサービスの一例は、新聞の購読である。例えば、購読している新聞を読めるようにするために１ヶ月ごとに固定の料金がかかる。固定の購読料に加えて、分量又は時間ベースの料金も適用可能である。「一度の最初の課金」は本発明のシステムによって２つの方法でサポートされる。

・１つ目は、サービスクラスによるものである。加入者のユーザサービスクラスベクトルにおける各々のサービスクラスに対して、そのサービスクラスに分類される最初のパケットの到達は、トークンバケットから最初のレート値が差し引かれることを意味する。サービスを行なう要素は、そこで、そのような特別なサービスクラスに対する最初のレート値に０を代入する。

・２つ目は、加入者によるものである。加入者のユーザサービスクラスベクトル中のすべてのサービスクラスは、同一の一度の最初の課金値を持つ。ユーザサービスクラスベクトルに含まれるサービスクラスのいずれかについてパケットが到達すると、トークンバケットはその値だけ減じられ、すべての値は「０」に設定される。最初のレート値は使用されたものとしてレート設定エンジンに報告され、そこで、加入者の要求に対して「０」の最初のレート値が与えられるようになされる。

位置依存のレート設定では、パケット転送システムはコントロールシステムに位置情報を送信する。一例として、ＧＧＳＮは、ＳＧＳＮ ＩＰアドレスの送信、及び、ロケーションイネーブルドサーバ(Location Enabled Server)へのインタフェースをサポートする。パケット転送システムはそれゆえ、地理的位置に関する有効条件をチェックし、その条件がもはや満たされなくなった場合は新たなユーザレート設定テーブルを要求するようになされる。

時間制のレート設定では、サービスを行なう要素は有効時間条件を管理し、所定の閾値が過ぎると新たなユーザレート設定テーブルを要求する。加えて、サービスを行なう要素は、最大契約時間、すなわち、２４時間の接続まで単一料金、ということをサポートする。これは、残り時間有効条件によって管理され、サービスを行なう要素は、この値を減算する手段を備え、「０」や所定の閾値に到達すると、新しいユーザレート設定テーブルが要求される。もしその値が「０」になる又は所定の閾値に到達する前に現在の接続の無効化(de-activation)、例えばＰＤＰ接続無効化が発生すると、その値がレート設定エンジンに送信され、レート設定エンジンはそのユーザに対する総時間を更新するようになされる。

従量制のレート設定では、サービスを行なう要素は有効分量条件を管理し、所定の閾値が過ぎると新たなユーザレート設定テーブルを要求する。サービスを行なう要素はこの値を通過したトラフィック量をもって減少させ、もし「０」又は所定の閾値に到達すると、新しいユーザレート設定テーブルが要求される。もしその値が「０」になる又は所定の閾値に到達する前に現在の接続の無効化(de-activation)、例えばＰＤＰ接続無効化が発生すると、その値がレート設定エンジンに送信され、レート設定エンジンはその加入者に対する総分量を更新するようになされる。

コントロールシステム及びサービスを行なう要素はそれぞれ、本発明の中心的なユニットである。コントロールシステムは課金方針を計算し、サービスを行なう要素の課金実行ポイントにその課金方針を提供する責務がある。コントロールシステムはさらに、１人以上の加入者の預託金口座を管理する責務がある。サービスを行なう要素は、コントロールシステムから受信した課金方針に基づいて課金を実行する責務のある課金実行ポイントを備える。さらに、サービスを行なう要素は、１ユーザごとに複数のサービスに対する預託金を格納するようになされるトークンバケットを備える。トークンバケットは、コントロールシステムの預託金口座機能と通信するように構成される。コントロールシステム及びサービスを行なう要素それぞれについていくつかの異なる実施が可能であることは、当業者にとって明らかである。当業者にとって、コントロールシステムとサービスを行なう要素それぞれ、及び、本発明の他の機能が、公知のハードウェア及びソフトウェア手段を用いてどのように実現されるかは、明らかである。コントロールシステム及びサービスを行なう要素は、本発明に従ってプログラム可能に実施される。プログラム可能なコントロールシステム及びパケット転送システムの最も容易な実現方法は、ソフトウェア手段によるものであろうが、プログラム可能なハードウェアによる実施もまた、ハードウェア及びソフトウェアの組み合わせによる実施と同様、可能である。

図面及び明細書において、本発明の典型的な好適な実施例を開示した。また、特定の語を使用したが、これらは一般的かつ説明的な意味で使用されたに過ぎず、添付した請求項で説明される発明の範囲を限定する目的ではない。

従来技術におけるマルチプルトークンバケット法を示す概略的なブロック図である。 本発明の一実施例における単一トークンバケット法を示す概略的なブロック図である。 本発明における「課金方針」を計算する処理を示す概略的なブロック図である。 本発明におけるユーザレート設定テーブル及び有効条件を含む、課金方針を概略的に示す図である。 ユーザプロファイルを概略的に示す図である。 料金プランを概略的に示す図である。 サービスフィルタのパラメータを示す図である。 プロトコルインスペクションフィルタ（ＰＩＦ）設定のパラメータを示す図である。 移動体通信システムのＧＧＳＮに実現される本発明の一実施例に従うサービスを行なう要素を示す図である。

Claims (30)

1. コントロールシステム（２０１）と、パケット転送システム（２１０）に設けられたサービスを行なう要素（２０６）とを備え、パケットがどのサービスフローに属するかに依存して前記パケットに異なる課金をするパケット交換式ネットワークにおける課金システムであって、
   前記コントロールシステム（２０１）は、
   少なくとも１ユーザの口座を管理するようになされた口座機能（２０３）と、
   前記少なくとも１ユーザに対して許可されたサービスに対する課金方針を計算するように構成された課金方針決定ポイント（２０２）とを備え、
   前記サービスを行なう要素（２０６）は、
   前記ユーザの前記口座機能（２０３）から受信した予約を格納するようになされた１ユーザごとのトークンバケット（２０８）と、
   前記計算された課金方針に従って前記トークンバケット（２０８）の前記格納された予約を減少させることによって前記許可された複数のサービスに対して課金を実行するように構成された課金実行ポイント（２０７）と、
   を備え、
   前記ユーザは前記トークンバケット（２０８）に関連することを特徴とする、課金システム。
2. 前記サービスを行なう要素は１ユーザごとに単一のトークンバケットを備えることを特徴とする、請求項１に記載の課金システム。
3. さらに、前記計算された課金方針は、
   少なくとも１つのユーザレート設定テーブルと、
   有効条件の組と、
   を備えることを特徴とする、請求項１又は２に記載の課金システム。
4. 前記課金方針は、過去と現在との内の少なくともいずれかのユーザ固有の使用データに基づいて計算されることを特徴とする、請求項３に記載の課金システム。
5. 前記有効条件の組は、前記少なくとも１つのユーザレート設定テーブルの存続期間を定義することを特徴とする、請求項３又は４に記載の課金システム。
6. 前記計算された課金方針は、異なる時間有効条件を有する少なくとも２つのユーザレート設定テーブルを備えることを特徴とする、請求項３乃至５のいずれか１項に記載の課金システム。
7. 前記サービスを行なう要素は、前記サービスの料金プランに基づいて前記複数のサービスを異なるサービスクラスに分類する手段を備えることを特徴とする、請求項１乃至６のいずれか１項に記載の課金システム。
8. 前記許可された加入者サービスクラスは、サービスクラスベクトルに格納されることを特徴とする、請求項７に記載の課金システム。
9. 前記複数のサービスを異なるサービスクラスに分類する手段は、前記異なるサービスフローを識別するようになされたサービスフィルタを備えることを特徴とする、請求項１乃至８のいずれか１項に記載の課金システム。
10. 前記複数のサービスを異なるサービスクラスに分類する手段はさらに、前記サービスフィルタが前記識別を行ない得ない場合に前記異なるサービスフローを識別するようになされたプロトコルインスペクションフィルタを備えることを特徴とする、請求項９に記載の課金システム。
11. 前記パケット転送システムは、移動体通信ネットワークにおけるゲートウェイＧＰＲＳサポートノードであることを特徴とする、請求項１乃至１０のいずれか１項に記載の課金システム。
12. 少なくとも１ユーザの口座を管理するようになされた口座機能（２０３）を備える、パケット交換式ネットワークにおける課金システムのコントロールシステム（２０１）であって、
    前記コントロールシステムは、
    前記少なくとも１ユーザに対して許可されたサービスに対する課金方針を計算するようになされた課金方針決定ポイントを備えることを特徴とする、コントロールシステム。
13. 前記計算された課金方針は、
    少なくとも１つのユーザレート設定テーブルと、
    有効条件の組と、
    を備えることを特徴とする、請求項１２に記載のコントロールシステム。
14. 前記課金方針は、過去と現在との内の少なくともいずれかのユーザ固有の使用データに基づいて計算されることを特徴とする、請求項１３に記載のコントロールシステム。
15. 前記有効条件の組は、前記少なくとも１つのユーザレート設定テーブルの存続期間を定義することを特徴とする、請求項１３又は１４に記載のコントロールシステム。
16. さらに、前記計算された課金方針は、異なる時間有効条件を有する少なくとも２つのユーザレート設定テーブルを備えることを特徴とする、請求項１３乃至１５のいずれか１項に記載のコントロールシステム。
17. 前記コントロールシステムは、移動体通信ネットワークに実現されることを特徴とする、請求項１２乃至１６のいずれか１項に記載のコントロールシステム。
18. パケット交換式ネットワーク（２１０）において、課金システムのパケット転送システムに設けられたサービスを行なう要素（２０６）であって、
    少なくとも１ユーザに対する予約を受信する手段と、
    前記ユーザの前記予約を格納するようになされた１ユーザごとのトークンバケット（２０８）と、
    許可されたサービスに対する課金方針を受信する手段と、
    前記受信した計算された課金方針に従って前記トークンバケット（２０８）の前記格納された予約を減少させることによって前記複数の許可されたサービスに対する課金を実行するようになされた課金方針実行ポイント（２０７）と、
    を備え、
    前記ユーザは前記トークンバケットに関連することを特徴とする、サービスを行なう要素。
19. 前記サービスを行なう要素は、１ユーザごとに単一のトークンバケットを備えることを特徴とする、請求項１８に記載のサービスを行なう要素。
20. 前記課金方針は、
    少なくとも１つのユーザレート設定テーブルと、
    有効条件の組と、
    を備えることを特徴とする、請求項１８又は１９に記載のサービスを行なう要素。
21. 前記課金方針は、過去と現在との内の少なくともいずれかのユーザ固有の使用データに基づいて計算されることを特徴とする、請求項２０に記載のサービスを行なう要素。
22. 前記有効条件の組は、前記少なくとも１つのユーザレート設定テーブルの存続期間を定義することを特徴とする、請求項２０又は２１に記載のサービスを行なう要素。
23. 前記課金方針は、異なる時間有効条件を有する少なくとも２つのユーザレート設定テーブルを備えることを特徴とする、請求項２０乃至２２のいずれか１項に記載のサービスを行なう要素。
24. 前記サービスを行なう要素は、前記サービスの料金プランに基づいて前記複数のサービスを異なるサービスクラスに分類する手段を備えることを特徴とする、請求項１８乃至２３のいずれか１項に記載のサービスを行なう要素。
25. 前記許可された加入者サービスクラスは、サービスクラスベクトルに格納されることを特徴とする、請求項２４に記載のサービスを行なう要素。
26. 前記複数のサービスを異なるサービスクラスに分類する手段は、前記異なるサービスフローを識別するようになされたサービスフィルタを備えることを特徴とする、請求項２４又は２５に記載のサービスを行なう要素。
27. 前記複数のサービスを異なるサービスクラスに分類する手段は、前記サービスフィルタが前記識別を行ない得ない場合に前記異なるサービスフローを識別するようになされたプロトコルインスペクションフィルタを備えることを特徴とする、請求項２６に記載のサービスを行なう要素。
28. 前記パケット転送システムは、移動体通信ネットワークにおけるゲートウェイＧＰＲＳサポートノードであることを特徴とする、請求項１８乃至２７のいずれか１項に記載のサービスを行なう要素。
29. 請求項１２乃至１７のいずれか１項に記載のコントロールシステム（２０１）の課金方針決定ポイント（２０２）と、課金方針を転送するようになされた請求項１８乃至２８のいずれか１項に記載のサービスを行なう要素（２０６）の課金方針実行ポイント（２０７）とに接続可能であることを特徴とするインタフェース（１）。
30. 請求項１２乃至１７のいずれか１項に記載のコントロールシステム（２０１）の口座機能（２０３）と、前記口座機能（２０３）から前記トークンバケット（２０８）へ予約を転送するようになされた請求項１８乃至２８のいずれか１項に記載のサービスを行なう要素（２０６）のトークンバケット（２０８）とに接続可能であることを特徴とするインタフェース（２）。

Images