JP4100870B2 - テレコミュニケーションネットワークのサービス制御 - Google Patents

Description

【０００１】
【技術分野】
本発明は、一般に、テレコミュニケーションシステムにおけるサービス制御の実施に係る。この点について、「サービス」とは、テレコミュニケーションネットワークを経て１人以上の顧客（即ちネットワークを経て利用できるサービスの１人以上のユーザ）へ供給することのできるいかなる情報サービスも指す。この供給は、単一又は一度だけの事象でもよいし、或いは長期間にわたって延長されてもよい。サービスの典型的な例は、以下で説明する。
【０００２】
【背景技術】
顧客に提供されるサービスが単一又は一度だけの事象と考えられる場合には、単一のトランザクションによりそれに対して支払をするのが自然である。このトランザクションは、電子マネーや、電子財布や又はネットワーク支払を行うためにクレジットカード会社により指定された機密電子トランザクション（ＳＥＴ）プロトコルのような色々な既知の機構の１つを用いて行うことができる。
一方、サービスが連続的な場合には、小さな増分で、例えば、１分ごとに次の１分のサービスに対して支払をするのが顧客にとって効果的である。この増分的支払では、供給が中断された場合に顧客の損失が低く保たれ、損失は前払いされた額に限定される。このような中断は、意図的又は偶発的である。例えば、映画の送信中に、顧客が視聴の終了を決定したり、又はネットワークに混雑状態が生じてサービスの供給が中断したりすることがある。
【０００３】
一連の支払受け取りに基づいて連続的サービスの供給を制御するためには次の２つの問題を解決しなければならない。（１）詐欺的行為及び支払の捏造をいかに防止するか、及び（２）サービスプロバイダーがサービスを終了する判断を行えるようにする制御機構をいかに実施するか。
第１の問題は、顧客ターミナルがシーケンス番号を伴う支払いメッセージを発生しそして各支払メッセージにデジタル符牒を追加するようにして対処することができる。符牒及びシーケンス番号をチェックすることにより、サービスプロバイダーは、送信中に変更又は複写された支払メッセージを容易に検出することができ、これらメッセージは破棄される。デジタル符牒は、顧客を保護するだけでなく、サービスプロバイダーも保護し、顧客は、サービスプロバイダーに不変のまま到達した支払を後で否定することができない。デジタル符牒を利用した課金システムが、例えば、同じ出願人によって出願された初期のＰＣＴ特許出願ＰＣＴ／ＦＩ９７／００６８５号に開示されている。
【０００４】
第２の問題に対する解決策は、例えば、ネットワーク遅延の変化やメッセージの損失のために支払の規則的な到着に依存し得ないようなインターネットワーク環境（インターネットのような）で機能できる制御機構である。従って、顧客に関する制御機構の性能に対するネットワークの影響を最小にすることができる。今日の主流である顧客中心の雰囲気において、顧客と、顧客以外のサービスプロバイダーは、個々の顧客が当該サービスプロバイダーを有するという関係に基づいて個々に処理することができる。従って、この機構は、サービスプロバイダーが個人的な顧客サービスを提供できるものでなければならない。又、この機構は、種々のアプリケーション及び環境に対して調整できるように柔軟でなければならない。
【０００５】
【発明の開示】
本発明の目的は、上記要件を満足する制御機構を形成することにより上記第２の問題に対する解決策を提供することである。
この目的は、独立請求項に記載した解決策により達成することができる。
本発明の考え方は、少なくとも現在のサービスセッション中有効であるサービス価格に依存し且つ顧客が現時点までの支払をした仕方も示す少なくとも１つの制御パラメータを維持することである。制御パラメータの値が計算され、そして少なくとも１つのスレッシュホールドと比較されて、サービスを継続することが許されるか、又は他の何らかの手段をとらねばならないか、例えば、顧客に現在の状況を通知しなければならないか決定される。スレッシュホールドの値は、多数の変数に依存し、例えば、現在セッション中及び／又は１つ以上の以前のセッション中の顧客の振る舞い（即ち、１つ以上の制御パラメータ）に依存する。
【０００６】
本発明による制御システムは、色々な種類の技術及びビジネス環境に適応させることができ、そして顧客は、たとえ顧客によりなされたある支払が失われたり又はネットワークにおいて遅延されたりしても、公平に取り扱うことができる。
本発明の好ましい実施形態によれば、制御パラメータは、顧客によりこうむる負債、又は顧客がサービスプロバイダーに対して負債を負っている時間長さを表すことができる。このように、制御機構は、顧客のアクティブティを測定し、そして制御処置が必要であるか又は顧客に通知を送信しなければならないかどうか判断することができる。
本発明の更に別の効果は、多数の独立した情報流より成る複合サービス、及び１つの情報流が多数の顧客に送信されるマルチキャストサービスに適していることである。
本発明の方法は、容量及び地理的カバレージについて拡張可能である。
【０００７】
【発明を実施するための最良の形態】
以下、添付図面の図１ないし図１２を参照して、本発明及びその好ましい実施形態を詳細に説明する。
図１は、本発明の動作環境を一般的レベルで示す。課金セッションには３つの当事者が含まれ、それらは、情報サービスのユーザ即ち顧客と、サービスプロバイダーと、サービスに対して顧客がいかに支払をするか監視する制御プロセスユニットとである。顧客はターミナルＣＴを有し、これは、サービスプロバイダーからサービスを受け、そしてその受けたサービスに対して１つ以上の支払メッセージを制御プロセスユニットＣＵへ順次に送信する。制御プロセスユニットは、これら支払メッセージをオンラインで監視し、そして受信した情報に応答して、サービスプロバイダーのサーバーＳＰへ制御メッセージを送信することにより、サービスの供給を制御する。又、制御プロセスユニットは、提供されるサービスの現在価格も得、そしてそれらを使用して、サービスセッション中に顧客の振る舞いを評価する。
【０００８】
各支払メッセージは、実際の電子マネー、又は顧客が支払に対して委ねた厳密な金額に関する情報を含む。更に、個々の支払メッセージは、全サービスに対する支払、又はサービスの一部分のみに対する支払を含む。しかしながら、この点において、サービスは、ある時間周期、通常、数分から数時間持続する連続サービスであると仮定する。このようなサービスの一例は、サービスプロバイダーのサーバーから顧客へ送信されるオーディオ−ビジュアル流（映画のような）である。又、顧客は、サービスに対して小さな増分で支払を行い、従って、個々の支払メッセージは、サービスが持続する全時間よりも相当に短い時間周期である例えば１分といった短い時間に対する支払を含むものと仮定する。連続サービスの別の例は、顧客が自分自身のターミナルでプレイすることのできる（ネットワーク）ゲームである。
【０００９】
サービスの供給は、顧客及びサービスプロバイダーがサービスの価格について合意した後にスタートする。サービスの供給中、顧客は、支払メッセージを制御プロセスに送信し、そして合意した項目に従って支払が送られる限り、制御プロセスは、サービスの供給を中断しない。
制御プロセス及びサービスプロバイダーは、同じ情報サーバーに並置されてもよいし、又は個別のホスト共に存在しそして個別の組織に所属してもよい。従って、サービスプロバイダーのサーバーと制御プロセスとの間にはネットワークが存在してもよい。
課金セッションの第１段階は、通常、価格の交渉であり、即ち顧客はあるサービスを要求し、そしてサービスの価格と支払方式とについて合意がなされる。
【００１０】
次の段階では、サービスが顧客に供給される。顧客は、通常、サービスの供給と同時に制御プロセスユニットに支払メッセージを送信する。サービスの供給は、顧客が合意した支払方式を固守する限り、或いは顧客又はサービスプロバイダーがサービスを終了すると決定するまで、続けられる。顧客が、合意した方式に基づいて制御プロセスユニットへ支払を送金しなかった場合には、制御プロセスがサービスを停止するようにサービスプロバイダーに通知する。
上述したように、顧客ターミナルは、連続サービスに対し小さな増分で支払をするように支払の流れを発生するのが好ましい。例えば、接続欠陥によりサービスの供給が停止した場合には、顧客の損失が小さく保たれる。ここでは、顧客（又は顧客ターミナル）が、支払をいつ送金すべか及び各支払における総額を判断することにより自分自身のリスクを制限できると仮定する。支払は、ユーザターミナルから不規則な間隔で送金することができ、そして変化する総額を含むことができる。
【００１１】
金銭に関連した詳細（金額、通貨等）に加えて、各支払には２つの識別子がなければならず、即ちそれは、支払流の識別子（ある課金セッションに属する全ての支払に対して同じである）と、支払が２回以上受け入れられないよう確保するための独特の識別子、例えば、シーケンス番号とである。上述したように、支払の情報は、例えば、支払メッセージにデジタル符牒を付けることにより、捏造、不正行為、又は転送における意図しない変更に対しても保護されねばならない。
又、交渉段階において、公称時間間隔Ｉを定義し、これに基づいて顧客が支払を送金するようにすることもできる。この間隔は、制御プロセスが更なる支払いについて問合せする場合に顧客がその支払を送るための時間をもてるように、ネットワークを横切る平均往復時間よりも最低限１桁大きくセットされねばならない。又、支払と支払との間の時間の下限は、支払の殺到による過負荷から制御プロセスを保護するように定義することもできる。この過負荷保護は、例えば、支払受け入れポイントにおける既知の漏れバケツ(leaky bucket)メカニズムにより実行することができる。
【００１２】
ネットワークサービスに課金するための一般的な環境は、上記ＰＣＴ特許出願ＰＣＴ／FI９７／００６８５号、及び同じ出願人により出願された別の以前のＰＣＴ特許出願ＰＣＴ／ＦＩ９８／００５９０号（本発明の出願時には機密）に開示されている。これら文書には、より多くの背景情報を見ることができる。
提供されるサービスの価格は、均一料金と、供給時間又は供給データ量Ｖに基づく料金との組合せである。時間ｔにおける固定価格成分の数はＭ(ｔ)であり、そして固定価格成分の和はｅ(ｔ)＝ｅ１＋ｅ２＋・・＋ｅＭ(ｔ)である。サービスの供給は時間ｔ＝０にスタートし、そして時間ｔにおける合計サービス料金は次のようになる。
Ｃ(ｔ)＝ｅ(ｔ)＋ｓｔ＋ｒＶ(ｔ) （１）
但し、ｓは単位時間当たりの価格、そしてｒは単位量当たりの価格である。
【００１３】
一般に、サービスの価格は、時間及びデータ量の関数であり、即ちＣ＝Ｃ(ｔ、Ｖ)である。簡単化のために、以下の説明では、時間をベースとする料金及び均一料金を中心に述べる。従って、ｒはゼロであると仮定する。しかしながら、本発明による方法は、顧客がトラフィック量Ｖの測定を偽造できないとすれば、量をベースとする料金にも適用できることに注目するのが重要である。この要件は、顧客のターミナルが汎用コンピュータである場合には、実施することが困難である。しかしながら、ターミナルが移動電話のような埋め込み型装置である場合には、この要件を満足することができる。量をベースとする料金をシステムにいかに追加できるかの一例は、上記のＰＣＴ出願ＰＣＴ／ＦＩ９８／００５９０号に開示されている。
【００１４】
上述したように、単位時間当たりのサービスの価格は、一定でなくてもよい。価格が時間ｔｉにおいて変化し、従って、ｓ(ｔ)＝ｓｉ、ｔｉ≦ｔ＜ｔｉ＋１であると仮定する。時間ｔまでに、価格ｓがＫ(ｔ)回変化し、最初の変化はｔ＝０において生じ、即ちＫ(０)＝１である。ｓｉ＞０のときに、サービスに対して顧客に料金が課せられる。ｓｉ＝０及びｓｉ＜０のケースも関連があり、例えば、広告の間に、価格はゼロ又は負となる。負の価格は、上述したネットワークゲームにおいても使用でき、即ち顧客は、ゲームにおいてボーナスを勝ち取ることができる。
時間ｔにおける累積料金の一般的な方程式は、次の通りである。
【数１】

【００１５】
簡単化のために、サービスの単位時間当たりの価格は、時間ドメインにおいて変化し、断片的には一定のままであると仮定する。図２ａは、単位時間当たりの価格が−２と＋４の単位通貨間で変化するようなこの種の一例を示す。単位時間当たり一定の断片的価格のケースでは、上記式を次のように書き直すことができる。
【数２】

図２ｂは、価格が図２ａのように変化するときの累積料金Ｃ(ｔ)を示す。図から明らかなように、単位時間当たりの価格ｓ(ｔ)は、曲線Ｃ(ｔ)の傾斜を決定する。サービス価格が変化するときの時間ｔｉは、明確に通知することができる。
【００１６】
上述したように、顧客（又は顧客ターミナル）は、各支払メッセージに対する支払額を決定することができる。ｉ番目の支払の金額をｐｉで表しそして時間ｔにおける支払受け取りの回数をＮ(ｔ)で表すと、顧客が支払った又は支払を委託した総額は、次のように表される。
【数３】

全ての支払が同じ金額を含む必要はないが、サービスプロバイダーは、支払を送金すべき公称間隔Ｉを定義することができる。顧客がこの公称間隔に固執しそして価格ｓが一定である場合には、支払における金額がｐｉ＝ｓＩとなる。
【００１７】
図２ｃは、不規則な間隔で送金される支払から形成されそして変化する総額を含む累積総額Ｐ(ｔ)の一例を示す。
ここで、累積費用Ｃ(ｔ)と受け取り支払の総額Ｐ(ｔ)との間の差として時間ｔにおける顧客の負債Ｄ(ｔ)、即ちＤ(ｔ)＝Ｃ(ｔ)−Ｐ(ｔ)を定義する。これは、上記式（２）及び（３）を考慮すると、次のように表される。
【数４】

Ｄ(ｔ)の値は、顧客の支払がサービスの費用より少ないときにはゼロより大きく、そして過剰に支払ったときには、Ｄ(ｔ)＜０である。Ｄ(ｔ)＞０のときには顧客はサービスプロバイダーに借金した状態であり、それ故、Ｄ(ｔ)を負債と称する。
【００１８】
図２ｄは、料金が図２ｂに示すように累積しそして顧客が図２ｃに示すように支払するときの負債を時間の関数として示している。
負債Ｄ(ｔ)の値は、サービスが前払いサービスとして供給されるか又は信用で供給されるかを特徴付けるのに使用できる。全供給時間中Ｄ(ｔ)＜０である場合には、サービスが前払いである。
顧客が公称時間間隔で一定金額を含む支払を送金するように契約を結んだ場合には、サービスに対して前払いするために２つの選択肢がある。
− 顧客は、メディアストリームのようなサービスの単位時間ごとに、前もって支払する。又、顧客は、サービスプロバイダーにある金額を予納することもできる。
− 顧客は、多額の金額をサービスプロバイダーに予納し、そして支払が後で回収される。
【００１９】
負債が、ある供給時間中にゼロより大きくなる場合には、サービスは、少なくとも部分的に信用で供給される。
本発明によれば、負債に関連した制御パラメータＣＰが制御プロセスに対して決定される。以下に述べるように、制御パラメータの値は、費用Ｃ(ｔ)に影響する全ての価格に基づくと共に、サービスに対して現時点までに顧客がどのように支払ったかにも基づく。
更に、制御パラメータ値に対する１つ以上の限界であってそれに基づいて顧客が支払を送金すべき限界も、制御プロセスに対して定義される。次いで、制御プロセスは、サービスセッション中に制御パラメータの現在値を計算し、そしてその計算された値を上記限界と比較して、どんな処置をとるべきか決定する。実施の仕方及び制御パラメータの値に基づいて、サービスの終了が差し迫っていることを顧客に通知することもできるし、サービスを直ちに終了することもできる。
【００２０】
本発明の最も簡単な実施形態では、顧客によりこうむる負債が上記制御パラメータとして使用され、即ちＣＰ＝Ｄ(ｔ)である。以下の説明では、このようなケースを仮定する。
上述したように、Ｄ(ｔ)の値は、顧客がサービスプロバイダーに対してどれほど多くの借金をしているかの直接的な尺度である。サービスプロバイダーのリスクを最小にするために、最大負債値に対してスレッシュホールドをもつことが望ましい。更に、顧客の負債がサービス終了限界に近づきつつあることを顧客に通知するために１つ以上の低通知スレッシュホールドをもつことも望ましい。このようにして、失われた支払が自動的にサービスの終了となることはない。従って、本発明の好ましい実施形態によれば、少なくとも２つのスレッシュホールド値が制御パラメータとして使用され、即ちそれらは、サービスの終了が差し迫っていることをいつ顧客に通知すべきかを決定するのに使用される低い値と、サービスをいつ終了すべきかを決定するのに使用される高い値である。以下の説明において、前者は、通知スレッシュホールドと称され、そして後者は、終了スレッシュホールドと称される。
【００２１】
Ｄ(ｔ)の値が所定の通知スレッシュホールドを越えたときには、顧客が新たな支払を送金するように求められる。負債が更に増加して終了スレッシュホールドに到達した場合には、サービスの供給が終了される。
図３は、上記スレッシュホールドの作用を示す（負債が制御パラメータとして使用されるとき）。この図において、顧客が未払いのまま受けることのできるサービスの最大額を定義する終了スレッシュホールドがＴＴで示され、一方、通知スレッシュホールドがＮＴで示される。支払が規則的な間隔で受け取られる限り、負債の上限は、ｓＩ＝４である。支払が失われたときには、Ｄ(ｔ)がこの値より増加し、通知スレッシュホールド値ＮＴ＝７に到達する。制御プロセスユニット（又はサービスプロバイダー）から通知を受け取った後に、顧客ターミナルは、失われた支払を再送金し、これにより、Ｄ(ｔ)は、終了スレッシュホールドＴＴ＝９に到達しない。再送金した支払が受け取られた後に、負債は、Ｄ(ｔ)≦４となる。
【００２２】
終了スレッシュホールドに到達する前に通知に対して顧客が反応できるようにするために、課金セッション中の最高サービス価格又はその推定値をＳとし、そしてサービスプロバイダーと顧客ターミナルとの間の平均往復時間をΔとすれば、差ＴＴ−ＮＴは、明らかにＳΔより大きくなければならない。
ここで、支払の到達時間をａｉで表し、そして更に、支払ｐｉが受け取られる直前及び直後の時間を各々ｔ＝ａ_ｉ ⁻及びａ_ｉ ^＋とする。ある状態では、支払が受け取られた直後の負債の値が、制御を遂行するのに非常に有用である。以下の説明では、この値をＤ(ａ_ｉ ^＋)で表す。
【００２３】
従って、本発明の１つの好ましい実施形態によれば、支払の直後の負債値についても、個別のスレッシュホールドＡＤＴが設けられる。Ｄ(ａ_ｉ ^＋)＞ＡＤＴの場合には、顧客にそれが通知される。このスレッシュホールドの値は、ＡＤＴ＜ＮＴ＜ＴＴである。又、顧客が終了スレッシュホールド付近にＤ(ｔ)の値を維持するのを防止するために、Ｄ(ａ_ｉ ^＋)に対しても終了スレッシュホールドを定義することができる。
顧客のクロックが制御プロセスの基準クロックより低速である場合には、Ｄ(ａ_ｉ ^＋)の値が徐々に増加する。通知に伴い、顧客は、例えば、その通知を受けた後に特別支払を送金することにより、それを考慮に入れることができる。この種の状態が図４に示されており、この図は、顧客のクロックが基準クロックよりも１０％低速である例示的なケースを示す。ｔ＝Ｔ１において、支払後の負債が、それに対応するスレッシュホールドに到達する。時間ｔ＝Ｔ２において、顧客は僅かな特別支払を送金する。支払が欠落したときには、支払後の負債Ｄ(ａ_ｉ ^＋)がスレッシュホールドＡＤＴを越えることもある点に注意されたい。Ｄ(ａ_ｉ ^＋)の増加が必ずしもクロックのずれによるものでないケースにおいて顧客への通知を取り除きたい場合には、支払が欠落することを考慮したある特別なロジックを制御プロセスユニットに導入しなければならない。
【００２４】
本発明の更に別の好ましい実施形態によれば、顧客が負債状態にある累積時間長さが制御パラメータとして使用される。換言すれば、制御プロセスは、Ｄ(ｔ)＞０である時間長さを制限する。ｘ(ｔ)を次のように定義した場合には、
【数５】

Ｄ(ｔ)＞０である周期（０、ｔ）内の時間長さは、次のようになる。
【数６】

但し、ｃ(ｔ)は、非減少関数で、その値はせいぜいｔである。顧客は、Ｃ(ｔ)を減少するすべがなく、その増加を防ぐことしかできない。
ここでも、ｃ(ｔ)の値に対して終了スレッシュホールドＴＴがセットされる。終了スレッシュホールドがＴＴ＝０の場合には、負債時間制限のサービス供給が前払いされることに注意されたい。ゼロとＴＴとの間の通知スレッシュホールドを定義することもできる。たとえ同じ参照マーク（ＴＴ及びＮＴ）が異なる制御パラメータのスレッシュホールドに対して使用されても、スレッシュホールドの値及び単位は、当該制御パラメータに基づいて変化することに注意されたい。
【００２５】
以下、制御プロセスの実施について詳細に説明する。簡略化のために、Ｎ(ｔ)の有効性確認と、シーケンス番号の追跡については、以下の説明から省略する。支払の欠落や複写を検出するために、制御プロセスは、最後に受け取った支払の番号Ｎ(ｔ)を覚えておきそしてシーケンス１、２、・・Ｎ(ｔ)におけるギャップを追跡しなければならない。更に、固定費用及び支払の処理は、固定費用ｅＭ(ｔ)がＤ(ｔ)に加算されそして支払がＤ(ｔ)から減算されることを除いて同じであるから、固定費用ｅｉも、以下の説明では省略する。
上記制御プロセスは、少なくとも３つの異なる仕方で実施することができる。第１の実施形態では、制御パラメータがスレッシュホールドを越える瞬間が推定される。この例では、２つのタイマーが使用され、即ち制御パラメータの値が通知スレッシュホールドに到達したと推定されるときに時間切れする通知タイマーと、制御パラメータの値が終了スレッシュホールドに到達したと推定されるときに時間切れする終了タイマーである。第２の実施形態によれば、制御パラメータの値が周期的に計算される。この第２の実施形態では、制御パラメータは、２つの連続するチェックポイント間のどこかでスレッシュホールドを越え、値が次にチェックされるときにそれが通知される。第３の実施形態では、値が周期的に計算されると共に、支払が受け取られたとき又はサービスの価格が変化するときにも計算される。
【００２６】
図５ａは、制御パラメータがスレッシュホールドを越える瞬間を推定する第１の実施形態に基づいて機能する制御プロセスを示すフローチャートである。最初に、制御プロセスは、制御プロセスに使用されるべき制御パラメータＣＰと、その制御パラメータに関連したスレッシュホールドＮＴ及びＴＴの値とを決定する（段階５１１）。その後、プロセスは、変数Ｔ（時間）、Ｄ（負債）、ＣＰ及びｓをそれらの初期値に初期化する（段階５１２）。この段階において、変数Ｔは現在時刻の値を得、そして他の変数は、それらの初期値を得る。初期値は、固定値でもよいし、顧客特有の値でもよく、同じ顧客の以前のサービスセッションに基づいてセットすることができる。
【００２７】
初期化の後、実際の制御プロセス（課金セッション）は、制御プロセスユニットが待機状態に入り（段階５１３）、ある信号の到着を待機するときにスタートする。この待機状態の間には、５つの異なる信号形式を受信し得る。即ち第１の信号は、サービス価格（即ちｓの値）の変化を指示し、第２の信号は、顧客から支払が受け取られたことを指示し、第３の信号は、通知タイマーが時間切れしたことを指示し、第４の信号は、終了タイマーが時間切れしたことを指示し、そして第５の信号は、終了要求が受け取られたことを指示する。終了要求は、顧客又はサービスプロバイダーが、制御プロセスとは独立して、サービスの停止を決定する場合に受け取られる。（単位時間当たりの価格を指すときには、「価格」という短い表現を使用することに注意されたい。）
【００２８】
５つの信号のいずれかが受信された後に、パラメータＣＰ、Ｄ及びＴがそれらの新たな値に更新される（段階５１５、・・５１９）。上記の第１、第３、第４及び第５信号の後に、負債の新たな値は、Ｄ：＝Ｄ＋ｓ(ｔ−Ｔ)であり、即ちｓ(ｔ−Ｔ)の値に以前の値が加えられたものとなる。第２の信号が受信された場合には、負債がＤ：＝Ｄ＋ｓ(ｔ−Ｔ)−ｐＮ(ｔ)の値に更新され、即ち受け取られた支払が考慮に入れられる。更に、第１の信号を受信した後に、サービス価格ｓは、その新たな値（即ちｓ：＝ｓＫ(ｔ)）に更新される。制御パラメータを更新する一例について、以下に述べる。
受信された信号が、終了タイマーが時間切れしたという指示、又は終了要求であった場合には、更新された値が将来の使用のために記憶され、そしてサービスが停止される（段階５２６及び５２７）。
【００２９】
一方、受信された信号が、第１、第２又は第３の信号である場合には、制御パラメータの更新された値が終了スレッシュホールドＴＴと比較される（段階５２０）。この比較が、制御パラメータの値が終了スレッシュホールドの値以上であることを示す場合には、変数が記憶され、そしてサービスが停止される（段階５２６及び５２７）。
しかしながら、そうでない場合、即ち制御パラメータＣＰの値が終了スレッシュホールドより小さい場合には、制御パラメータの新たな値が通知スレッシュホールドＮＴの値と比較される（段階５２１）。制御パラメータの値が通知スレッシュホールドＮＴ以上であることが分かった場合には、顧客ターミナルに送信される上記通知メッセージにより顧客に通知がなされ（段階５２３）、そして終了タイマーがセットされる（段階５２５）。負債が制御パラメータとして使用され、現在時刻がｔでありそしてｓ＞０である場合には、終了の時刻がｔ＋(ＴＴ−Ｄ(ｔ))／ｓとなる。
【００３０】
制御パラメータの値が通知スレッシュホールドＮＴの値にまだ到達しない場合には、ｓの値が変化しないと通知スレッシュホールドに到達し得ない状態であるかどうかチェックされる（段階５２２）。もしそうであれば、通知タイマーがセットされる（段階５２４）。負債が制御パラメータとして使用される場合には、通知の時刻がｔ＋(ＮＴ−Ｄ(ｔ))／ｓとなる。
段階５２２において、タイマーをセットするような使い方であるかどうかチェックがなされる。例えば、ｓ≦０である場合には、Ｄ(ｔ)が増加しないので、タイマーをセットするポイントはない。
その後、プロセスは待機状態（段階５１３）に戻り、新たな信号を待機する。
サービスが停止されようとしているときにも（即ち、段階５２６及び５２７に関連して）顧客及び／又はサービスプロバイダーに通知を送信できることが明らかである。
【００３１】
図５ｂは、図５ａのプロセスにおいて制御パラメータがいかに更新されるか、即ち段階５１５ないし５１９において制御パラメータの更新がいかに実行されるかを示すフローチャートである。この例では、負債状態にある時間が制御パラメータとして使用され、即ちＣＰ＝ｃ(ｔ)であると仮定される。先ず、段階５５１において、一時的な変数Ｂに値Ｄ＋ｓ(ｔ−Ｔ)が与えられ、即ちＢは、負債の新たな値を表す。次いで、負債の以前の値及び新たな値に基づいて、３つの別々の方法の１つにおいて制御パラメータの新たな値を計算しなければならない。以前の値が正であり、そして新たな値がゼロ以上である場合には、段階５５３において、制御パラメータが値ｃ＋(ｔ−Ｔ)に更新される。以前の値が正であることが分かりそして新たな値が負である場合には、段階５５５において、制御パラメータが値ｃ−Ｄ／ｓに更新される。以前の値がせいぜいゼロであることが分かり、そして新たな値がゼロより大きい場合には、段階５５７において、制御パラメータが値ｃ＋Ｂ／ｓに更新される。
【００３２】
図５ｃは、ｃ(ｔ)が制御パラメータとして使用される場合に終了タイマーをいかにセットするかを示す。このケースでは、制御パラメータが終了スレッシュホールドに到達する場合に、時間ＴＴ−ｃの後、又は時間ＴＴ−ｃ−Ｄ／ｓの後にそれを行うことが明らかである。但し、ｃ、Ｄ及びｓは、段階５１５及び５１６において上記変数の最後の更新で得られた値に対応する。又、第１のケースは、［(ｓ≧０∧Ｄ≧０)∧¬(ｓ＝０∧Ｄ＝０)］∨［ｓ＜０∧Ｄ≧(ｃ−ＴＴ)ｓ］のときに適用できることが明らかである。但し、∧は、論理アンド演算であり、∨は、論理オア演算であり、そして¬は、論理ノット演算である。これは、図の段階５６０においてテストされる条件１である。第２のケースは、ｓ＞０及びＤ＜０のときに適用できる。これは、段階５６２においてテストされる。
【００３３】
上記第２の実施形態において、制御パラメータの値は、チェックを行わねばならないときに時間切れするタイマーを使用することにより周期的にチェックされる。制御パラメータ値のこの周期的な計算は、支払又は価格変化を指示する記録された事象をベースとし、即ち支払が到着するか又は価格が変化するたびに、それに対応する事象がテーブルに記録される。事象Ｅｉの記録は、トリプレット（形式、値、時間）を含み、但し、形式は、「支払」又は「価格の変化」である。チェックとチェックとの間に、制御プロセスは、これらの記録をテーブルに記憶する（即ち、上記事象が発生するときに事象記録が記憶される）。次いで、テーブルの情報が制御パラメータの次のチェックポイントで使用される。
【００３４】
テーブルＥが図６に示されている。テーブルの長さは、ｌで示される。従って、テーブルは、ｌ個の記録のアレーである。時間単位Ｈごとに、例えば、２０秒ごとに、制御プロセスは、制御パラメータ及び負債の新たな値を計算し、そしてテーブルを作成する。テーブルの最初と最後の記録は、形式「価格の変化」である。第１の記録Ｅ０は、制御パラメータの各計算の終わりに（「価格の変化」、ｓＫ(ｎＨ)、ｎＨ）に初期化される。最後の記録Ｅｌ−１は、（「価格の変化」、ｓＫ(ｎＨ)、(ｎ＋１)Ｈ）であり、制御プロセスは、制御パラメータの新たな計算をスタートする前に、その記録をテーブルの終わりに追加する。従って、周期（ｎＨ、(ｎ＋１)Ｈ）において外部事象がない場合には、その周期の終わりにｔ＝(ｎ＋１)Ｈであるときに、テーブルＥは、２つの記録を含むことになる。
課金セッションの始めに、制御プロセスは、Ｅ０を（「価格変化」、ｓ１、０）にそしてｌを１に初期化し、更に、第１の時間切れ信号をｔ＝Ｈに到着するようにスケジュールする。
【００３５】
図７は、制御パラメータの値の周期的な計算を示すフローチャートである。最初の２つの段階（７１１及び７１２）は、このケースでは、図５ａの実施形態と同じであるが、段階７１２では、テーブルも上述したように初期化される。
この実施形態では、制御プロセスは、待機状態において４つの異なる形式の信号を受信することができ（段階７１３）、第１の信号は、サービスの価格（即ちｓの値）の変化を指示し、第２の信号は、顧客から支払を受け取ったことを指示し、第３の信号は、時間切れタイマーが時間切れしたことを指示し、そして第４の信号は、終了要求を指示する。時間切れタイマーは、上記のチェックポイントにおいて時間切れとなる。
【００３６】
４つの信号のいずれかが受信された後に、事象記録をテーブルに追加することによりテーブルＥが上述したように（段階７１５、・・７１８）更新される。更に、上記第３又は第４の信号が受信される場合には、パラメータＣＰ及びＤも、それらの新たな値へ更新される。上述したように、第３及び第４の信号に関しては、追加される記録が「価格の変化」である。
第１及び第２信号に関連したテーブル更新の後に（即ち段階７１５及び７１６の後に）、プロセスは待機状態（段階７１３）へ進んで、新たな信号を待機する一方、第４の信号に関連したテーブル更新の後には、変数が記憶されそしてサービスが停止される（終了要求が受信される）。
【００３７】
上記第３信号の後にのみ、制御パラメータの新たな値を終了スレッシュホールドと比較することによりプロセスが継続する（段階７１９）。ここで、制御パラメータの値が終了スレッシュホールドの値以上であることが分かった場合には、変数が記憶され、そしてサービスが停止される（段階７２４及び７２５）。
もしそうでなければ、即ち制御パラメータの値ＣＰが終了スレッシュホールドより小さい場合には、制御パラメータの新たな値が通知スレッシュホールドＮＴの値と比較される（段階７２０）。制御パラメータの値が通知スレッシュホールドＮＴ以上であると分かった場合には、顧客に通知がなされ（段階７２１）、そしてテーブルが処理され（段階７２２）、上記の最後の記録だけがテーブルに残されるようにする。制御パラメータの値が通知スレッシュホールドより小さい場合には、通知段階がスキップされ、制御プロセスは、段階７２２へ直接ジャンプして、テーブルを処理する。テーブルが処理された後に、時間切れタイマーがセットされる（段階７２３）。その後、制御プロセスは、待機状態に戻って、新たな信号を待機する。
【００３８】
図８は、図７のプロセスにおいて制御パラメータをいかに更新するか、即ち段階７１７及び７１８において制御パラメータの更新をいかに遂行するかを示すフローチャートである。この例でも、負債状態にある時間が制御パラメータとして使用され、即ちＣＰ＝ｃ(ｔ)であると仮定する。図中、参照記号「Ｅ_ｉ.ｔｙｐｅ」は、テーブル内のｉ番目の記録の形式フィールドの値を指す。先ず、プロセスは、テーブルインデックスｊに値１を与え、そして価格ｓの値を、テーブルの第１記録の値フィールドの値に等しくセットする（段階８１１）。その後、プロセスは、現在記録がテーブルの最後の記録であるかどうかテストする（段階８１２）。もしそうであれば、プロセスは停止される。さもなくば、プロセスは、段階８１３へジャンプし、新たな負債値を表す一次的変数Ｂに、値Ｄ＋ｓ(Ｅ_ｊ.ｔｉｍｅ−Ｅ_ｊ−１.ｔｉｍｅ)が与えられ、即ち以前の記録の時間フィールドの値が現在記録の値から差し引かれ、その差に価格ｓを乗算し、そしてその結果を負債の以前の値に加算する。その後、図５Ｂについて上述したのと同様に、段階８１４ないし８１９において制御パラメータの値が更新され、即ち計算ルールは、負債の以前の値及び現在の値が正であるか負であるかに依存する。
【００３９】
制御パラメータの新たな値が計算された後に、プロセスは、現在記録の形式フィールドが「支払」であるかどうかテストする。もしそうであれば、即ち受信したメッセージが支払を含んでいれば、支払の額が負債の現在値に考慮される（段階８２１）。その後、現在記録の形式フィールドが「支払」でない場合には、プロセスは、現在記録の形式フィールドが「価格変化」であるかどうかテストする（段階８２２）。もしそうであれば、負債に変数Ｂの現在値が与えられ、そして価格がその新たな値に更新される（段階８２３）。その後、現在記録の形式フィールドが「価格変化」でなかった場合には、プロセスがテーブルインデックスｊの値を１だけ増加し、そして段階８１２へジャンプして戻り、テーブルの終わりに到達したかどうかテストする。
上記の第３実施形態において、制御プロセスは、Ｈ時間単位の周期が経過したときだけでなく、外部信号（支払又は価格変化のいずれかを指示する）を受信したときにも、制御パラメータを計算する。この方法を使用するときには、評価と評価との間の事象が記録されてはならない。この方法について次に説明する。
【００４０】
図９は、スレッシュホールドを越えたかどうかプロセスが周期的にチェックするようなこの種の実施形態を示すフローチャートである。この場合に、プロセスは、図７の実施形態の場合と同じ４つの形式の信号を待機状態において受信することができる（段階９１３）。更新段階（９１５ないし９１８）は、テーブルを必要としないという意味で図５ａの実施形態と同様である。待機状態において時間切れ信号が受信された場合には、制御パラメータの更新された値が終了スレッシュホールドと比較される。その値がスレッシュホールドより小さい場合には、時間切れタイマーが再びセットされる（段階９２０）。その後、並びに第１及び第２信号に関連した更新段階（９１５及び９１６）の後に、制御パラメータの新たな値が終了及び通知スレッシュホールドと比較され（段階９２１及び９２２）、そしてサービスの終了、通知の送信及び待機状態へのジャンプが、上述したように実行される。
【００４１】
制御パラメータを上記のように周期的に計算すると、顧客が累積し得る最大未払い使用額は、ＴＴ＋ＳＨとなり、ここで、Ｓは、課金セッション中の最大価格である。
顧客からメッセージが受け取られない場合でもサービスを停止させるために、段階５１２、７１２及び９１２においてタイマーを初期化することができる。別のやり方として、支払又は価格変化を示す信号がサービスセッションの始め（ｔ＝０）に常に送信される。支払は、ゼロ支払であってもよい。
上述したように、上記全ての実施形態においては、ＣＴ≧ＡＤＴの場合には、制御プロセスが支払後に通知を送信することもできる。簡単化のために、これはフローチャートには示さない。
【００４２】
周期的な計算又は制御パラメータを使用する実施形態は、予想型のもの（即ち図５ａに基づくもの）よりも精度が低く、即ちＣＰ＞ＴＴを通知するのに制御プロセスにＨ個の時間単位を必要とする。しかしながら、周期的な計算は、価値の高い技術であり、ＣＰの値を周期的に計算するときには、経過時間に基づくだけでなく、各周期内に受信するデータ量にも基づいて、顧客に課金することができる。
予想型戦略の正確さは、信号が到着した直後に制御プロセスを実行するようスケジュールするという仮定をベースとする。しかしながら、ほとんどのオペレーティングシステムでは、特に多数の制御プロセスが同じハードウェアを共用する場合に、この仮定は現実的でない。制御プロセスを実行するマシンが、ＣＰＵ負荷に関してタイマーをセット及びリセットするのに経費がかかるものである場合には、第２及び第３の実施形態の方が、第１の実施形態より好ましい。というのは、外部トラフィックに影響されないタイマーを使用しているからである。第２実施形態の別の効果は、制御パラメータに関連した全ての計算が所定の時間に行われ、従って、制御パラメータの計算により生じる最大負荷を予想できることである。
【００４３】
以上のことから明らかなように、制御パラメータＣＴは、サービス供給中の顧客の振る舞いを特徴付ける。一般的に述べると、制御パラメータは、（１）サービス価格の値、及びサービス価格が変化する時刻、そして（２）なされた支払、及びその支払がなされた時刻、に依存する。換言すれば、一連の値を｛｝で表すと、ＣＴ＝ｆ（{ｓｉ}、{ｔｉ}、{ｐｊ}、{ａｊ}）となる。制御パラメータは、Ｄ(ｔ)の関数、ｃ(ｔ)の関数、又はその両方の関数である。異なる種類の制御パラメータを使用すると、サービスに最も適した制御ポリシーを開発することができる。以下、Ｄ(ｔ)及びｃ(ｔ)の両方が制御パラメータとして使用される幾つかの考えられるポリシーを例示する。
顧客の負債Ｄ(ｔ)の値にスレッシュホールドを設定するのに加えて、サービス時間を連続するタイムスロットに分割することができる。１つのタイムスロットの長さは、ｎＩ：[０、ｎｌ]、[ｎＩ、２ｎＩ]、・・である。第１の例では、ポリシーは、各タイムスロット内においてＤ(ｔ)＞０である時間長さがスレッシュホールドＵより短いことを必要とする。このように、負債の最大値に加えて、顧客が自分の負債を増加し得る割合を制限することができる。
【００４４】
考えられるポリシーの別の例として、Ｄ(ｔ)＜Ａ（Ａ＞０）である限り、サービスを信用で供給することができる。時間ｔ＝τにおいて負債が限界に達した場合には（即ちＤ(τ)＝Ａ）、そのときからサービスの供給をほぼ前払いとしなければならないことが顧客に通知され、即ちｃ(ｔ)−ｃ(τ)≧Ｕの場合にはサービスの供給が停止される。従って、負債限界に達した場合には、料金の一部分が前もって支払われた場合だけサービスを継続することが許される。この制御戦略では、顧客が累積し得る最大未払い使用量は、単位時間当たりの最大価格をＳとすれば、Ａ＋ＵＳである。
又、ｃ(ｔ)＜Ｕである限り、（関連負債）終了スレッシュホールドをＴＴとして、サービスを信用で供給してもよい。時間ｔ＝τにおいて負債状態にある時間のスレッシュホールドに到達しそしてｃ(τ)＝Ｕである場合には、（負債関連）スレッシュホールドがＴＴ’＜ＴＴに下げられる。従って、顧客が前もって充分な支払をしない場合には、許容最大負債が下げられる。
【００４５】
あるケースでは、サービス供給時間のある部分、例えば、サービス供給時間の最大限半分の間だけ、顧客が負債状態にあることを必要とするのが適当である。時間（０、ｔ）内においてＤ(ｔ)＞０である時間の割合ｑ(ｔ)を次のように定義する。
ｑ(ｔ)＝ｃ(ｔ)／ｔ
顧客が負債を有している時間巾と、負債を有していない時間巾との比は、次の通りである。
ｃ(ｔ)／(ｔ−ｃ(ｔ))＝ｑ(ｔ)／(１−ｑ(ｔ))
量ｑ(ｔ)／(１−ｑ(ｔ))は、サービスセッション中に制御パラメータとして使用することもできる。
２つ以上の制御パラメータをプロセスに導入することは簡単である。全ての制御パラメータを同じ段階で計算し、そして各制御パラメータを、それに対応するスレッシュホールドと比較することができる。
【００４６】
又、制御プロセスは、ｃ(ｔ)の定義においてＤ(ｔ)に対して非ゼロのスレッシュホールドを使用するように変更することもできる。これを行うために、上記式（５）を次のように再定義する。
【数７】

但し、Ａは、通貨単位を有する。時間（０、ｔ）内においてＤ(ｔ)＞Ａである時間長さをｃＡ(ｔ)で表すと、次のようになる。
【数８】

Ａ＞０の場合には、ｃＡ(ｔ)＜ＴＴにより制御されるサービスが信用で供給される。又、Ａ＜Ｂの場合には、ｃＡ(ｔ)≧ｃＢ(ｔ)であり、そして差ｃＡ(ｔ)−ｃＢ(ｔ)は、時間（０、ｔ）内においてＡ＜Ｄ(ｔ)＜Ｂである時間長さである。
更に一般化するために、スレッシュホールドＡは、時間の断片的直線関数であるとする。従って、式（５）にＤ(ｔ)に代わってＤ(ｔ)−Ａ(ｔ)を入れると、ｃＡ(ｔ)の計算がｃ(ｔ)の計算となる。
【００４７】
又、セッションごとにスレッシュホールドを変更することもできる。スレッシュホールドは、例えば、サービスの価格、以前のサービスセッション中の顧客の振る舞い、及び現在セッションの長さに依存し得る。制御システムは、顧客の振る舞いに関するデータを収集し、そしてその収集したデータに基づいて、条件を変更し、例えば、スレッシュホールド又はサービスの価格を変更することができる。顧客が適時に支払を満足する場合には、信用できることが証明され、より多くの特典を与えることができる。一方、顧客が適時に支払を満足しないことがシステムに分かると、その顧客に対して更に厳しい条件が採用される。例えば、負債状態にある時間がスレッシュホールドレベルを越えた場合には、価格を上げることができる。以上のことから明らかなように、サービスプロバイダーは、サービスの条件を指令したり、又はこのタスクを第３者の制御エンティティに委ねたりすることができる。
【００４８】
図１０ａは、顧客ターミナルＣＴの構造を例示する機能的ブロック図である。本発明に関する限り、顧客ターミナルの重要な部分は、支払メッセージを発生する支払ジェネレータＰＧである。この支払ジェネレータに接続されているのは、セキュリティライブラリーＳＬＩであり、そのメモリは、顧客のプライベートな暗号キーを含み、そして支払メッセージの符号化を実行する。この支払ジェネレータは、支払メッセージを形成して、それをセキュリティライブラリーに送信し、そこで、顧客のプライベートな暗号キーを用いてメッセージが符号化される。セキュリティライブラリーは、符号化されたメッセージをジェネレータに返送し、該ジェネレータは、それを制御プロセスユニットに転送する。
その暗号化されたメッセージをターミナルと課金サーバーとの間で交換しなければならない用途又は環境の場合には、セキュリティライブラリーは、暗号化、符号化及び符号の照合を実行する。
【００４９】
セキュリティライブラリーは、ハードウェアベースのものでもソフトウェアベースのものでもよい。しかしながら、ハードウェアベースの解決策の方が優れたセキュリティを与える。従って、セキュリティライブラリー又はその一部分は、例えば、顧客のプライベートな暗号キーを含むスマートカードを使用して、上述したように構成することができる。
更に、ターミナルは、サービスを受けるための要素を含む。これら要素は、例えば、サービスプレーヤーＶＰを含み、これは、ネットワークから受信した映像信号を再生しそして支払メッセージを発生するための支払ジェネレータコマンドも与えることのできるビデオプレーヤーである。サービスブラウザＳＢ、サービスプレーヤーＶＰ及び支払ジェネレータは、ターミナルのコミュニケーションライブラリーＣＬを経てネットワークに接続される。ＣＬは、ターミナルが動作するときの基礎であるプロトコルスタックを構成する。このプロトコルスタックは、例えば、既知のＴＣＰ／ＩＰスタックで構成される。
【００５０】
更に、ターミナルは、例えば、受信した情報流のサービスクオリティ（ＱｏＳ）を監視するための種々の要素を含むことができる。例えば、ビデオプレーヤーは、サービスクオリティがあるレベルより下がったときに情報の送信を停止するためのコマンドをソースに与えることができる。
図１０ｂは、支払ジェネレータＰＧを詳細に示す機能的ブロック図である。契約ロジックユニットＣＬＵ１は、コンフィギュレーションデータベースＣＤＢに記憶された情報に基づいて支払メッセージの発生を処理する。これは、受信した契約情報をグラフィックユーザインターフェイスＧＵＩへ転送し、そして上述した課金記録の形式を発生するロジックを含む。このロジックは、２つの連続する支払間に経過する時間を定めるタイミング成分ＴＭを含む。契約ロジックユニットＣＬＵ１は、外部制御インターフェイスＥＣＩを経て通信ライブラリー及びネットワークに接続されると共に、内部制御インターフェイスＩＣＩを経てサービスプレーヤーに接続される。外部制御インターフェイスは、内部と外部の支払メッセージフォーマットの間で変換を行う。ターミナル制御インターフェイスは、サービスプレーヤーと契約ロジックユニットとの間のメッセージ転送を取り扱い、そしてサービスプレーヤーにより使用されるメッセージフォーマットと装置の内部メッセージフォーマットとの間で必要な変換を遂行する。内部制御インターフェイスとサービスプレーヤーとの間の接続（インターフェイスＡ３）は、例えば、通信ライブラリー（ＴＣＰソケット）を用いて実現することができる。コンフィギュレーションデータベースＣＤＢは、ユーザによりなされた設定（ユーザの好み）を記憶するのに使用されると共に、受信したサービス識別に応答して顧客に表示される種々のサービス（映画のような）に関する情報を記憶するのにも使用され得る。このデータベースは、例えば、マイクロソフトアクセス又はボーランドパラドックスで形成することができる。コンフィギュレーションデータベースは、マネージメントユニットＭＭを経て制御される。マネージメントユニット、コンフィギュレーションデータベース及び契約ロジックユニットは、全て、装置のグラフィックユーザインターフェイス（ＧＵＩ）に接続され、これは、例えば、ジャバ・アプレット又はマイクロソフト・ビジュアル・ベーシック・プログラミング・ツールを用いて実施することができる。コンフィギュレーションデータベースの一部分は、ネットワーク内に配置することができる。
【００５１】
サービスプレーヤーを例えばオーディオ・ビジュアル流に対して設計する場合には、例えば、このようなサービスに対して設計されたプログラム及びパーソナルコンピュータを用いて実施することができる。
図１１は、制御プロセスユニットＣＵの構造を例示する一般的なブロック図である。本発明に関する限り、装置の主要部分は、上記のフローチャートで述べた機能を遂行する課金ロジックＣＨＬである。このため、課金ロジックは、上記のパラメータ及び変数が記憶されるメモリＭを使用する。又、課金ロジックは、おそらく制御プロセスに使用される異なるタイマー（ＴＥＴ、ＮＯＴ、ＴＩＴ）もセットする。
【００５２】
到来する及び出て行くメッセージは、メッセージ処理ユニットＭＰＵによって処理され、該ユニットは、又、支払メッセージ及び価格変化を課金データベースＣＭに記憶する。メッセージ処理ユニットは、設定されるべき接続を定めるプロトコルスタックを形成する通信ライブラリーＣＬを経てネットワークに接続される。制御ロジックＣＬＵ２は、ネットワークから受信したメッセージに応答して課金ユニットを制御し、そして課金ロジックからの信号に応答してサービスプロバイダーに制御メッセージをそして顧客に通知メッセージを送信することにより、サービスセッションを制御する。又、制御ロジックは、サービスデータベースＳＥＤ及び加入者データベースＳＵＤにアクセスする。加入者データベースは、制御プロセスユニットを管理するオペレータのための顧客データ（各顧客の公開キーを含む）を含む。サービスデータベースは、次いで、サービスプロバイダーによって提供されるサービス及び価格のような課金パラメータに関する情報を含む。サービスデータベースは、任意である。というのは、サービスプロバイダーから受信されるメッセージが、課金目的のために必要な情報を含み得るからである。暗号化ブロックＣＭは、支払符牒を照合するためにメッセージ処理ユニットに関連される。このブロックは、ターミナルのＳＬブロックに対応する。
【００５３】
上述した制御方法は、多数の要素より成るサービスを包含するように拡張することもできる。これら要素が単一のサービスプロバイダーから発生される場合には、上記の制御方法を使用するのは簡単であり、即ち価格ｓが要素の価格の和になるだけである。これら要素が個別のサービスプロバイダーから発生される場合には、各サービスプロバイダーの利益を個別に管理しなければならない。これについて、以下に説明する。
複合サービスの要素は、個別に価格付けを行い、そして個別のサービスプロバイダーから発生することもできる。複合サービスの２つの例は、ネットワークからの多数のリソース割り当てを必要とするデータの送信と、多数の内容プロバイダーが所有する要素を伴うマルチメディアプレゼンテーションの供給である。
【００５４】
サービスが異なる価格の要素で構成されそしてそれら要素の数ｌが供給時間中に変化すると仮定する。従って、ｓ(ｔ)、Ｐ(ｔ)、Ｃ(ｔ)及びＤ(ｔ)は、ｌ次元ベクトルであり、各ベクトル要素は、サービス要素に対応する。例えば、太い活字でベクトルを表すとすれば、次のようになる。

【００５５】
従って、このように定義した演算及びブールのオペレーションと共に、上記の制御方法を適用することができる。サービス要素の制御パラメータとそれに対応するスレッシュホールドとの比較は簡単であるが、スレッシュホールドを越えたときに何を行うかを決定しなければならない。全てのサービス要素の供給を停止するか、又はスレッシュホールドを越えた要素のみを停止することができる。従って、複合サービスにおける要素の１つに対して顧客がいかに支払うかが、全サービスの供給に影響し得る。
負債状態にある時間を制御パラメータとして使用する場合にも同じことが言える。上記式（５）を次のように定義し直すことができる。
【数９】

【００５６】
一方、負債状態にある時間は、サービス要素ごとに別々に定義することもでき、そして各要素は、ｃ(ｔ)に対して異なるスレッシュホールドを有してもよく、この場合、負債状態にある時間及びスレッシュホールドは、ベクトルｃ(ｔ)及びＴＴとなる。サービス終了条件は、ｃ(ｔ)＞ＴＴと定義することができ、即ち負債時間の少なくとも１つがそれに対応する限界を越えた場合にサービスが停止される。又、スレッシュホールドを越えた要素のみを遮断することもできる。
全サービスに対するより一般的な終了条件は、関数Ｆ(ｘ)が実数を生み出すとすれば、Ｆ(ｃ(ｔ))＞Ｆ(ＴＴ)である。例えば、Ｆ(ｘ)は、ベクトル成分ｘｉの直線的組合せである。関数Ｆの重要なクラスは、最小{ｘｉ}≦Ｆ(ｘ)≦最大{ｘｉ}、１≦ｉ≦ｌを満足するものである。演算、幾何学及び調和手段は、このような関数の例である。
【００５７】
上記説明では、サービスが１つの受信機だけに供給されるポイント−ポイント接続のみについて述べた。本発明による方法は、サービスが顧客のグループに供給されるマルチキャストシステムにも使用できる。
通常ソースと称される単一の送信機があるか、又はマルチキャストグループの全メンバーがメッセージを送信できる１対ｎ及びｎ対ｎのマルチキャスト構成が存在する。この点については、サービスプロバイダーが唯一の送信機である１対多数のマルチキャストのみを説明する。図１２に示すように、マルチキャストツリーは、ノードｖｉと、ノード間の指向リンク（ｖｉ、ｖｊ）とで構成され、そしてマルチキャストグループのメンバーがノードに接続される。ノードは、実際には、ルーターであり、そしてメンバーは、個々のホストである。ノードｖｉを根とするサブツリーは、ローカルメンバー（ルーター後のサブネットワークにおけるホスト）と、ｖｊベースのサブツリーとで構成され、ここで、ｖｊは、ノードｖｉに直接リンクされる。マルチキャストツリーは、多数の基準に対して拡張することができ、例えば、ツリーは、考えられる最短経路を使用する単一方向性の１対ｎツリーであり、そして個別のツリーは、メッセージを送信できるマルチキャストグループの各メンバーに対して拡張され、或いは全ての送信者に対して使用される１つの両方向ツリーがあってもよい。簡単化のために、ここでは、ソースをベースとする１対ｎのマルチキャストツリーのみを考える。
【００５８】
マルチキャストサービスに対する課金は、２つの複雑な問題を含む。即ち、グループのメンバーに料金をいかに割り当てるかと、各メンバーが自分の負担分を支払うようにいかに制御するかである。内容を形成する費用に加えて、ネットワークに使用されるリソースからも費用が発生する。リンクの費用を割り当てそして費用割り当て機構を実施する方法は色々なものがある。
費用が割り当てられ、そして価格付けポリシーを使用して各メンバーのサービス料金が決定されると、当然、メンバーが充分な支払をするよう制御するための反復的な方法が使用され、即ち各ノードｖｉは、そのサブツリーを制御し、そしてソースは、全マルチキャストツリーを制御する。ノードｖｉにおける制御プロセスを実施するために、複合サービスに対する上記方法を適用することができ、即ち多数のサービス要素に対して単一顧客が支払をするのではなく、多数の顧客が同じサービスに対して支払する。各ベクトル成分は、ｖｉにリンクされたノード又はｖｉのローカルメンバーを表す。これらメンバーは、他のメンバーと同時に支払い記録を送信する必要がなく、各メンバーは、独自に支払を送信することができる。あるノードは、例えば、ある量の支払を収集したときに、上流の次のノードに支払を更に送信することができる。
【００５９】
マルチキャストグループにおいて、ローカルメンバー又はその下流のメンバーの若干のみが充分な支払をしない場合に、ノードｖｉを使用してマルチキャストを受信する全てのメンバーを切り離しすることは賢明ではない。それ故、制御パラメータがそのスレッシュホールドを越えたときには、ＣＰｉ＞ＴＴｉであるような要素ｉに対応するノード又はメンバーだけを遮断しなければならない。ノードを遮断するためのスレッシュホールドは、ローカルメンバーを遮断するスレッシュホールドより大きくなければならない。このように、各ノードは、支払しないローカルメンバーを、マルチキャストグループから全サブツリーを切り離す前に除去することができる。
【００６０】
以上のことから明らかなように、本発明による制御方法は、マルチキャストサービスにも適しており、ツリーの異なるハイアラーキーレベルに適用される。サービスの供給中にメンバーがグループに加わったり去ったりし得る動的なマルチキャストグループでは、割り当てられる費用及びサービス価格が一定でない。複合及びマルチキャストサービスに対する制御方法は、変動性サービスにも適用できる。
上述した制御方法は、ストリーミング媒体、インターネットへのアクセス及び上述した複合及びマルチキャストサービスのような種々のサービスを課金するときに使用することができる。
【００６１】
顧客が余分な支払をするときは、オンライン及びオフラインの２つの方法で取り扱うことができる。制御プロセスは、顧客が過剰な支払をしていることを顧客にオンラインで通知することができ、そして更に支払を送信するときに、それを考慮に入れねばならない。課金セッションの後に、顧客は、サービスプロバイダーに許可した額より少なく請求されてもよいし、或いは特に電子マネーの場合にはその余分な額を顧客に返金することもできる。
以上、添付図面を参照して本発明を詳細に説明したが、本発明は、これらの例に限定されるものではなく、特許請求の範囲内で種々の変更がなされ得ることが明らかであろう。考えられる変更を以下に簡単に述べる。
【００６２】
例えば、ターミナルは、実際の支払を送信する必要がなく、他の何らかの（支払関連）メッセージを課金サーバーに送信し、受信エンティティがそれを使用して、支払メッセージそれ自体を発生することも考えられる。例えば、ターミナルは、サービスの時間中にいわゆる「生きた状態に保つ(keep-alive)」メッセージを送信し、そして制御プロセスが支払メッセージを発生してもよい。同様に、特に、ターミナルの移動をサポートするシステムでは、他の何らかのネットワーク要素又はエンティティが、支払メッセージのジェネレータとしてターミナルの役割を果たすことも考えられる。このような要素又はエンティティは、ユーザの完全な機密を保有しなければならない。ターミナルの役割を果たすことは、例えば、ターミナルがあるまとまった額を上記要素又はエンティティに支払い、この要素又はエンティティが、受け取った支払いに基づいてサービス接続を維持し、そしておそらく顧客ターミナルからの追加支払いを要求することにより、実行することができる。又、あるユーザが、別のユーザへのサービスの供給に対してリアルタイムで支払をしてもよい。
【図面の簡単な説明】
【図１】 本発明による方法が一般的レベルで使用されるネットワーク環境を示す図である。
【図２ａ】 単位時間当たりのサービス価格を時間の関数として示す図である。
【図２ｂ】 サービス価格が図２ａに示すように変化するときにサービスに関連した累積料金を示す図である。
【図２ｃ】 顧客から受け取る累積支払の一例を示す図である。
【図２ｄ】 累積料金及び支払が図２ｂ及び２ｃに示すように変化するときに未払サービスの額、即ち顧客によりこうむる負債を時間の関数として示す図である。
【図３】 支払がネットワークのどこかで失われたときの負債スレッシュホールドの作用を示す図である。
【図４】 顧客ターミナルのクロックが制御プロセスのクロックより低速であるときの負債スレッシュホールドの作用を示す図である。
【図５ａ】 制御プロセスの第１実施形態を示すフローチャートである。
【図５ｂ】 図５ａの実施形態における制御パラメータの更新を示すフローチャートである。
【図５ｃ】 終了タイマーがいかにセットされるかを示すフローチャートである。
【図６】 制御プロセスの第２実施形態に使用されるテーブルである。
【図７】 制御プロセスの第２実施形態を示すフローチャートである。
【図８】 図７の実施形態における制御パラメータの更新を示すフローチャートである。
【図９】 制御プロセスの第３実施形態を示すフローチャートである。
【図１０ａ】 顧客ターミナルの構造を機能的ブロック図の形態で示す図である。
【図１０ｂ】 顧客ターミナルの支払ジェネレータの構造を詳細に示す図である。
【図１１】 制御プロセスユニットの構造を機能的ブロック図の形態で示す図である。
【図１２】 マルチキャストサービスの供給を示す図である。

Claims (22)

1. サービスを受けるために顧客により使用される顧客ターミナル（CT）と、顧客にサービスを提供するための少なくとも１つのサーバー（SP）と、顧客へのサービスの提供を制御するための制御手段（CU）とを備えたテレコミュニケーションネットワークにおいてサービスの提供を制御する方法において、
   上記サーバーが、上記顧客ターミナルへ情報を送信することにより連続的なサービスを提供するとともに、該サービスの現在価格を上記制御手段に通知するステップ、
   上記制御手段が、上記サービスに対する支払額を上記顧客ターミナルから受け取るステップ、
   上記制御手段が、上記サービスの累積料金と上記支払額の累積額を求め、これらの累積料金と累積額に値が依存する負債に関連する少なくとも１つの制御パラメータを維持するステップ、
   上記制御手段において、上記制御パラメータの値と上記制御手段に記憶された第１スレッシュホールド（TT）やこの第１スレッシュホールド（ TT ）よりも小さな第２スレッシュホールド（NT）とを比較するステップであって、上記第１スレッシュホールドはサービスをいつ終了すべきかを決定するのに使用され、上記第２スレッシュホールドはサービスの終了が差し迫っていることをいつ顧客に通知すべきかを決定するのに使用される、上記比較するステップ、
   上記制御パラメータの値が上記第２スレッシュホールド以上であるが上記第１スレッシュホールドよりも小さいときに、上記制御手段から上記顧客ターミナル（CT）に通知を送信するステップ、及び
   上記制御手段が、上記制御パラメータの値が上記第１スレッシュホールド以上であるときに上記サービスの提供を停止するステップ、
   を含むことを特徴とする方法。
2. 上記制御手段が、少なくとも２つの制御パラメータを維持し、
   上記制御手段が、制御パラメータごとに少なくとも１つのスレッシュホールドを決定し、そして
   上記制御手段が、ある制御パラメータの値がその制御パラメータに対応するある第１スレッシュホールドを越えたときにサービスを停止する請求項１に記載の方法。
3. 一方の制御パラメータは、その値が上記制御手段によるサービスの停止に使用される制御パラメータである請求項１または２に記載の方法。
4. 顧客によりこうむる負債を表す制御パラメータを使用する請求項１又は２に記載の方法。
5. 上記制御手段が、各支払の直後に制御パラメータの値を計算し、その制御パラメータを上記第２スレッシュホールドよりも小さな第３スレッシュホールド(ADT)と比較し、そして制御パラメータの値がその第３スレッシュホールドを超えたときに顧客ターミナルに通知を送信する請求項３に記載の方法。
6. 顧客がサービスプロバイダーに対して負債を負っている時間長さを表す制御パラメータを使用する請求項１に記載の方法。
7. 顧客がサービスプロバイダーに対して負債を負っている期間と、顧客がサービスプロバイダーに対して負債を負っていない期間との比を表す制御パラメータを使用する請求項１に記載の方法。
8. 第１及び第２の制御パラメータを上記制御手段において維持し、
   上記制御手段が、パラメータ特有の値の１つが停止値を表すように両制御パラメータに対して少なくとも１つのスレッシュホールド値を決定し、そして
   上記制御手段が、いずれかの制御パラメータの値がそれに対応する停止値以上のときにサービスを停止する請求項１に記載の方法。
9. 第１制御パラメータは、顧客によりこうむる負債を表し、そして第２制御パラメータは、顧客がサービスプロバイダーに対して負債を負っている時間長さを表す請求項８に記載の方法。
10. 上記制御手段が、第１及び第２の制御パラメータを維持し、
    上記制御手段が、第１制御パラメータに対する第１スレッシュホールド及び第２制御パラメータに対する第２スレッシュホールドを決定し、
    上記制御手段が、第２制御パラメータの値が第２スレッシュホールド値を越えたときに第１スレッシュホールド値を変更し、そして
    上記制御手段が、第１制御パラメータの値が第１スレッシュホールド値以上のときにサービスを停止する請求項１に記載の方法。
11. 上記制御手段が、制御パラメータの値に基づいてサービスの価格を変更する請求項１又は２に記載の方法。
12. 上記制御手段が、サービスを停止するのに使用される制御パラメータの値に基づいてサービスの価格を変更する請求項１１に記載の方法。
13. 上記制御手段が、現在サービスセッションのみに基づいて制御パラメータの値を決定する請求項１に記載の方法。
14. 上記制御手段が、顧客のサービスセッションに関するデータを記憶し、そして現在サービスセッション中に制御パラメータの値を決定するときに現在顧客の少なくとも１つの以前のサービスセッションに関するデータを上記制御手段において使用する請求項１に記載の方法。
15. 上記制御手段が、制御パラメータの値がスレッシュホールド値以上のときを指示するためにタイマーを使用する請求項１又は３に記載の方法。
16. 上記制御手段が、制御パラメータの値を所定の時間に周期的に計算し、
    上記制御手段が、２つの連続する時間の間に発生するサービス価格の変化と、各変化に対応する時間とを記憶し、そして
    上記制御手段が、制御パラメータの値を計算するときにその記憶された情報を使用する請求項１に記載の方法。
17. 上記制御手段が、制御パラメータの値を周期的に計算し、そしてサービスの価格が変化するとき及び上記顧客から支払を受けたときにも計算する請求項１に記載の方法。
18. 多数の情報流が顧客へ送信されるネットワークにおいて、
    上記制御手段が、制御パラメータと、各情報流に対するスレッシュホールドとを維持し、そして
    上記制御手段が、少なくとも１つの情報流の制御パラメータ値がそれに対応するスレッシュホールド以上の場合に上記情報流を停止する請求項１に記載の方法。
19. 多数の情報流が顧客へ送信されるネットワークにおいて、
    上記制御手段が、制御パラメータと、各情報流に対するスレッシュホールドとを維持し、そして
    上記制御手段が、上記流れの制御パラメータ値がそれに対応するスレッシュホールド以上のときに１つの情報流のみを停止する請求項１に記載の方法。
20. １つの情報流が多数の顧客へ送信されるネットワークにおいて、
    上記制御手段が、顧客特有のスレッシュホールドを維持し、
    上記制御手段が、顧客グループ特有のスレッシュホールドを維持し、そして
    上記制御手段が、全顧客グループへの情報流が停止される前に顧客への情報流を停止できるように上記スレッシュホールドの値を選択する請求項１に記載の方法。
21. １つの情報流が多数の顧客へ送信されるネットワークにおいて、上記制御手段が、顧客グループのサービスセッションに関するデータを記憶し、そして現在サービスセッション中に制御パラメータの値を決定するときに現在顧客グループの少なくとも１つの以前のサービスセッションに関するデータを上記制御手段において使用する請求項１に記載の方法。
22. サービスを受けるために顧客により使用される顧客ターミナル（CT）と、顧客にサービスを提供するための少なくとも１つのサーバー（SP）と、顧客へのサービスの提供を制御するための制御手段（CU）とを備えたテレコミュニケーションネットワークにおいてサービスの提供を制御するシステムにおいて、
    上記顧客ターミナルへ情報を送信することにより連続的なサービスを提供するための手段（SP）と、
    上記サービスの現在価格を上記制御手段に通知するための手段（SP）を備え、そして
    上記制御手段は、
    上記サービスに対する支払額を上記顧客ターミナルから受け取る手段と、
    上記サービスの累積料金と上記支払額の累積額を求めて、これらの累積料金と累積額に値が依存する負債に関連する少なくとも１つの制御パラメータを維持するための第１制御手段(CHL)と、
    上記制御パラメータの値をメモリ装置（ M ）に記憶された第１の所定のスレッシュホールド値（TT）やこの第１の所定のスレッシュホールド値（ TT ）よりも小さな第２のスレッシュホールド値と比較するための比較手段（CHL）であって、上記第１の所定のスレッシュホールド値はサービスをいつ終了すべきかを決定するのに使用され、上記第２のスレッシュホールド値はサービスの終了が差し迫っていることをいつ顧客に通知すべきかを決定するのに使用される、上記比較手段（ CHL ）と、
    上記制御パラメータの値が上記第２スレッシュホールド以上であるが上記第１スレッシュホールドよりも小さいときに上記顧客ターミナル（CT）に通知を送信し、上記制御パラメータの値が上記第１スレッシュホールド以上であるときにサービスの提供を停止するための第２制御手段（CHL,CLU2）と、
    を含むことを特徴とするシステム。

Images