JP4386582B2 - 通信ネットワーク - Google Patents

Description

【０００１】
発明の属する技術分野
本発明は、通信ネットワーク、とくに通信ネットワークにおける課金機構に関する。本発明は、１９９８年６月５日に出願された本発明の発明者の現在審査中のイギリス特許出願第9812161.9号に記載され、権利を主張された発明の態様を含み、前記第9812161.9号に先行する出願の内容は参考文献として本明細書に組込まれる。
【０００２】
従来の技術
従来の通信ネットワーク、例えば国内のＰＳＴＮ（公衆交換電話ネットワーク）において、相当な割合いのネットワーク資源はネットワーク使用の測定および請求書発行に専用である。調査ではこれらの資源は遠隔通信会社の歳入の６％ほどを消費すると推定している。対照的にインターネットは概して、個々の顧客に対しての測定および請求書発行機構を組入れていない。計測および請求書発行をサポートするのに要求されるネットワークのインフラストラクチャがないので、インターネットの操作コストは従来の電話ネットワークと比較して低くなり、インターネットの急速な拡大を促進した。しかしながら適切な請求書発行機能がないことは、インターネットによって保持されるトラヒックの特徴における重要な欠点であり：これはネットワーク資源の贅沢な使用を促進し、しかも新しい応用で、例えば保証されたサービス品質（ＱｏＳ）を必要とし、かつ加入に基いたインターネットアクセスサービスに通ずるものを支持するためのネットワークインフラストラクチャへの投資意欲を減退する。
【０００３】
発明が解決しようとする課題
本発明の第１の態様にしたがって、通信ネットワークを動作する方法であって：
（ａ）複数の顧客端末の各々においてネットワーク資源の各顧客端末による端末使用を測定する段階と；
（ｂ）次に、段階（ａ）によって生成された測定データからネットワーク使用課金を計算する段階とを含む方法を提供する。
【０００４】
本発明の発明者は、連合形の（federal:各素子は自治能力はあるが、全体でユニオンを形成する連邦形の）ネットワークにおいて使用するのに適した軽量の課金プロトコルを構成する主要な段階において、各顧客端末におけるネットワーク資源における自分自身の使用をモニタするようにすることによって、ネットワーク使用の計量を分散することを発見した。このやり方では、本質的にスケーラブルであり、ネットワーク内における相当なオーバーヘッドを避ける課金機構が用意される。
【０００５】
さらに本発明は好ましい構成において、マルチサービスネットワークの基礎をパケットネットワークに与え、各パケットを管理する（police）必要をなくした。したがってマルチサービスネットワークを構成するのが相当に簡単になり、すなわちこのマルチサービスネットワークでは、異なるパケットを既存の方式ではなく、適用されるサービスクラスにしたがって異なるパケットを差別的にスケジュールすることができる。
【０００６】
この方法は、段階（ａ）によって生成される測定データを記憶することを含むことが好ましい。測定データと共に、前記測定データに適用可能な料金を識別するデータが記憶されることが好ましい。料金を識別する前記データは、料金それ自体であってもよく、または料金の識別コードまたはポインタの形態をとってもよい。料金を記憶することによって、料金が時間で変化しても、顧客端末において口座データを測定値から生成することができる。
【０００７】
段階（ａ）によって生成されるデータをネットワークオペレータによって制御されるネットワーク口座オブジェクトへ通信することを含むことが好ましい。その代わりにデータを通常のやり方でネットワークオペレータから顧客へ通信してもよい。ネットワーク使用データ、およびネットワークオペレータによって計算されるネットワーク使用に対する課金は明示的に通信してもよい。またその代わりに、顧客端末によって計算される課金を示す口座データ内で、使用データを暗黙に（明示的でなく）通信してもよい。
【０００８】
この方法は、顧客端末とネットワークとの間で通信されるトラヒックの一部のみをネットワークオペレータがサンプリングする段階を含むことが好ましい。次にこのサンプル採りされたトラヒックは、顧客端末からネットワークプロバイダの口座オブジェクトへ報告されるネットワーク使用データと比較され、不一致が検出される。この比較はネットワーク使用に対して課金される全データに対して行われるか、または詳細な測定データに対して行ってもよい。全データに対する比較は効率上は標準的であり、この場合詳細な測定データに対する比較は、全データに対する比較が不一致を示したときのみ行われて、詐欺行為の証拠を記憶する。
【０００９】
本発明の発明者は、顧客が使用を測定し、使用データまたは価格設定された使用のデータを与える責務を負い、ネットワークオペレータがランダムに顧客トラヒックのサンプルのみを測定して、顧客によって供給されるデータの信頼性を確認すると、課金プロセスの効率をはるかに向上できることを発見した。
【００１０】
ネットワークオペレータ口座オブジェクトは、ネットワークオペレータによって制御される測定オブジェクトからか、または顧客端末の何れかからデータを受け取るように構成できることが好ましい。この方法は、ネットワーク口座オブジェクトにおいて受け取られた制御信号に応答して、１つの構成から他の構成へ課金することを含むことが好ましい。
【００１１】
この方法は、測定データを、顧客端末から遠隔しているシステムへ通信することを含む。例えばデータは、多数の顧客端末からコンポート（団体）口座システムへ通信してもよい。データを明示的に送るか、またはデータを使用して計算される使用課金を遠隔したシステムへ送るか、あるいはこの両者でもよい。データを遠隔したシステムへ報告するときは、データが生成されると直ぐに行なうか、または一定の期間において一連の測定からデータを収集（アグレゲート）した報告の形態で行ってもよい。
【００１２】
この方法は：
顧客端末と、この顧客端末に接続された第１のネットワークドメインとの間でトラヒックを通信することと；
第１のネットワークドメインと、該第１のネットワークドメインに接続された第２のネットワークドメインとの間で前記トラヒックをさらに通信することと；
顧客端末から第１のドメイン内の第１のネットワーク口座オブジェクトへネットワーク使用データを通信することと；
第１のネットワーク口座オブジェクトと、第２のドメイン内の第２のネットワーク口座オブジェクトとの間で口座データを通信することとを含むことが好ましい。
【００１３】
この態様は、連合形のデータネットワーク内のドメイン間で課金する効果的で効率的な方法を提供する。データは、第１の顧客端末から、中間のネットワークドメインを介して、第２の顧客端末へ流れるが、口座データ（すなわち、測定データ、またはそこから導き出されたデータ）が全て同じ方向に流れる必要はない。本発明は、例えば口座データが顧客から第１のドメインへ送られ、さらに第２のネットワークドメインから第１のネットワークドメインへ送られるシステムを含む。
【００１４】
この方法は、第１のネットワークドメイン内の現在のルート設定表から、第２のネットワークドメインを介して顧客端末とデータを通信する第２のドメインの識別子を判断し、顧客端末の口座データを現在のルート設定表によって識別される第２のドメインと通信することを含む。
【００１５】
本発明のさらに別の態様にしたがって、複数のネットワークドメインを含むネットワークを動作する方法であって、各顧客によるネットワーク資源の使用に対する課金を計算することと、第３の当事者への前記課金の清算の際の支払いをより明瞭にすることとを含む。この清算の支払いを使用して、所望の比率、例えば送信者が全て支払う、または送信者が６０％支払い、受信者が４０％支払うといった比率でエンドユーザ間で課金を配分することができる。
【００１６】
本発明のさらに別の態様にしたがって、複数の異なるサービスレベルを用意したパケットネットワークを動作する方法であって、前記パケットをパケットルータへ送ることと、パケットルータにおいて、パケットの分類を判断することと、パケットの分類に依存して差異があるようにパケットをスケジュールすることと、ルータから遠隔した位置においてパケットのサービスレベルを管理して、各サービスクラスに対するパケットの適格性を判断することとを含む方法を提供する。
【００１７】
本発明はさらに、本発明の方法によって動作するようにされた通信ネットワーク、顧客端末、およびネットワーク口座サーバ、およびこのようなネットワークで使用するルータを含む。
【００１８】
ここで本発明を実現するシステムをさらに詳しく添付の図面を参照して例示的に記載することにする。
【００１９】
発明の実施の形態
図１に示したように、通信ネットワーク１は多数のネットワークサブドメイン２Ａないし２Ｃを含む。ネットワークのサブドメインは、異なるオペレータの制御のもとに置かれる。ネットワークの動作において、異なるオペレータには相互信頼があるとは仮定しない。ネットワークのサブドメインはゲートウエイルータ３，４によって相互接続されている。本発明において通信ネットワークはインターネットであり、ユニキャストおよびマルチキャストインターネットプロトコル（ＩＰ）と関係するプロトコルの両方をサポートする。顧客端末５は、公衆交換電話ネットワーク（ＰＳＴＮ）６およびアクセスルータ７を介してサブドメイン２Ａへ接続されている。アクセスルータでは管理は必要ない。このアクセス点において単一のブロッキング試験がトラヒックに適用される。ゲートウエイルータ３、４およびアクセスルータ７はそれぞれCISCOシリーズ7500ルータおよびCISCOシリーズAS5800ユニバーサルアクセスサーバのような市販のデバイスであってもよい。他の顧客端末、例えばジャバイネーブルのモバイル端末８およびデータサーバ９がネットワークに接続されている。
【００２０】
顧客端末５はＬＡＮを介して口座サーバへ接続してもよい。口座サーバは、後述するように顧客端末から測定データを受取る口座オブジェクトを含んでもよい。
【００２１】
ネットワーク資源使用料金は、ネットワークを通って顧客端末へマルチキャスト（同報通信）される。これらの料金は異なる揮発性バンドに分割される。料金はネットワークオペレータの制御のもとで変更され、ネットワークの全体的なローディングを反映する。すなわち、ネットワークローディングが高くなると、料金はネットワーク資源の希少性を反映するように増加する。ネットワーク管理（マネージメント）プラットフォーム10は各サブドメインに接続される。各ネットワーク管理プラットフォームは、例えばＵＮＩＸ（Solaris）およびネットワーク管理アプリケーションを実行するＳＰＡＲＣワークステーションを構成しているコンピュータ処理システムを含んでもよい。ネットワーク管理プラットフォーム10は管理エンティティおよび料金エンティティをホストする。このネットワーク管理プラットフォーム10はさらに、後で記載するようにネットワーク口座オブジェクトをホストする口座サーバとして機能することもできる。ネットワーク管理プラットフォームは、例えばＳＮＭＰ（簡単なネットワーク管理プロトコル）を使用して各サブドメインへ接続される管理されているデバイスにおいてエージェント100と通信する。管理プラットフォームは、各サブドメイン内のネットワーク資源の全体的なローディングをモニタし、それにしたがってネットワーク使用料金を調整する。ネットワーク管理プラットフォーム（ＮＭＰ）はエージェントに命令して、デバイスをモニタし、集められた結果を規則的な間隔でＮＭＰへ報告し、その結果ＮＭＰは全ての報告の組合せをモニタすることができる。
【００２２】
この料金の中央制御に加えて、各顧客端末において料金アルゴリズムは、ネットワーク資源のローディングにおけるローカルに検出された変更に自動的に応答するようにされている。ローカルな料金変更の使用は、本発明の発明者の現在審査中の特許出願（発明の名称“Communications Network”、ＢＴ参照番号A25793）に記載され、権利を主張されており、本明細書ではこれを参考文献として取上げている。
【００２３】
サービスプロバイダは、異なるサービスレベル協定または異なる価格の揮発性、あるいはこの両者によって規定された異なる製品を提供することができる。例えば製品Ａは最善を尽くすサービスを固定価格（プライス）で提供し、一方で異なる製品Ｂは可変価格で最善を尽くすサービスを提供してもよい。サービスプロバイダは、次のパラメータ：すなわちサービスプロバイダが卸売りプロバイダに支払う価格；競争相手の価格；現在の資源利用；異なる製品に対する関連する需要に基いて製品の価格を調節してもよい。これらのパラメータにおける変化に応答して、料金調節を３つのやり方の１つにおいて実行することができる。第１に、プロバイダからの明らかな通信を必要とせずに、ネットワークローディングのローカルな観察に基いて料金を調節する。このアプローチは、後でさらに記載するが、最初に料金表（タリフ）に組込む必要があり、専らローカルな観察に依存している料金変動に制限される。第２に、プロバイダはパラメータの一部を調節することによって料金に適合することができる。顧客端末によって直接にできないパラメータ、例えばネットワーク資源の卸売価格の変化に依存するときに、このような調節が要求される。第３に、プロバイダは料金表を完全に置換してもよい。これは、既存の料金が要求される変化に適応できないときに要求される。
【００２４】
上述の第1の料金変更は必ず自動的に行われる。第２のタイプの課金は手操作で、またはサービスプロバイダシステムによって行われる観察に応答して自動的に調節を送るエージェントによって行うことができる。第３のタイプの変更は手操作で実行される可能性が高く、新しい料金に代わるものとして、一般的に人間による入力を要求する設計要素を要求する。しかしながら1組の特定の規則に基づいて製品の料金を自動的に交換するようにエージェントを採用することができる。
【００２５】
この段落では、上述で概略的に示した料金のサブシステムを説明するのに我々が構成したプロトタイプを記載した。この設計の特徴は次のもの、すなわち：
・料金および関係するユーザインターフェイス構成要素を表わすモバイルコードを使用することと；
・反復されるマルチキャストアナウンスメントプロトコルを使用して、料金および料金調節を効率的に通信することと；
・ダイナミックなクラスのローディングおよび反映を使用して、料金を受取って適合させることとを含む。
【００２６】
プロトタイプは、一般目的のジャバクラスのライブラリおよび２つの特定のアプリケーション、すなわち：
・プロバイダが多数の製品の料金（表）を導入、置換、および適合できるプロバイダシステムと；
・課金の追跡がユーザが使用している製品に加えられ続けることを可能にする顧客システムを含む。
【００２７】
プロバイダシステムは、マルチキャストイネーブルのネットワーク内の異なるホスト上で実行されている顧客システムの多数のインスタンス（例）をサービスする。マルチキャストアナウンスメントプロトコルを使用して、プロバイダシステムから顧客システムへ料金変更を通信する。
【００２８】
料金規定に対する柔軟性を最大にするために、我々はジャバクラスを使用して料金を表示することを選択した。この技術は、顧客へのユーザインターフェイス構成要素（コンポーネント）に供給して、料金の動きの視覚化をサポートするのにも使用される。
【００２９】
料金インターフェイスは、全ての料金に対する基本クラスとして働く。これは単一の操作get GUI()を規定して、顧客のＧＵＩ（グラフィカルユーザインターフェイス）へ組込むことができるジャバＳＷＩＮＧ構成要素として戻す。ＧＵＩ構成要素は、料金に適した技術を使用して、顧客が料金の動きを視覚化できるようにする。
【００３０】
料金インターフェイスのサブクラスは、各々が異なる組の測定および入力パラメータと関係する1組の料金タイプを設定する。これらのパラメータは、getCharge()方法のサイン内にパラメータを記載することによって識別される。例えばインターフェイスRSVPTariffは、RSVP TSPECを受取り、RSVP予約の特徴に基いて価格をコンピュータ処理する料金規定を許可するgetCharge()を規定する。他方でインターフェイスPacketCountTariffはパケットイン、パケットアウト、および現在の輻輳（一般的にパケットドロップ関数として測定される）の測定値を受取り、パケット数に依存し、輻輳を感知する料金の規定を許可するgetCharge()を規定する。他の料金は、使用測定の新しい形態が現れるときに加えることができる。料金インターフェイスと、サブクラスの料金インターフェイスRSVPTariffおよびPacketCountTariffとは、図１６に示されている。
【００３１】
料金は、上述の種々の料金インターフェイスの構成を用意することによって規定される。例えば、料金PacketCountLinearはPacketCountTariffがパケットカウントに比例して課金をコンピュータ処理するように構成する。別の料金CongestionSensitiveLinearは同様に働くが、顧客が輻輳中に特定の料金制限内に留まらないときに、科料の課金を加える。
【００３２】
料金インターフェイス構成に加えて、料金は他の‘ヘルパ’クラスを使用して、その動作を補助し、さらに、プロバイダが料金調整できるようにするために１以上のユーザインターフェイスを要求してもよい。プロバイダサイドユーザインターフェイスを要求して、プロバイダは料金調整することができる。
【００３３】
完全な料金表の記述は１組のジャバクラスから構成されており、その一部は顧客システム用に定められ、その残りはプロバイダシステムによって使用することが意図されている。顧客サイドクラスは、ジャバアーカイブ（ＪＡＲ）ファイルに纏められて、プロバイダシステムによる処理を容易にする。
【００３４】
新しい料金を展開するために、プロバイダシステムは最初に、実行環境へ要求する料金クラスをロードする。次にプロバイダシステムは、顧客サイドバンドルをロードし、それを直列化し、それを私設キーでサインし、アナウンスメントプロトコルを使用して、それを顧客システムに分配する。サインを使用すると、受取った料金が認証できることを顧客が確認できるようにする。
【００３５】
バンドル（束）を受取ると、各顧客システムは（プロバイダの私設キーを整合する公衆キーを使用して）サインを確認し、アナウンスメントプロトコルヘッダにおいて特定される作動時間は、例えば数時間または数日などのように相当に遅くなることもあるが、バンドルをアンパックし（パックを解いて）、特別の目的のために構成されたダイナミッククラスローダを使用してその実行環境へこれらのクラスをロードする。受取った料金表クラスのインスタンス（例）を生成して、先の料金の代わりにインストールする。料金が、（料金オブジェクトのgetGUI()方法を呼ぶことによって得られる）ユーザインターフェイス構成要素をもつとき、これは先の料金表のユーザインターフェイスを置換する。ユーザインターフェイスの変更は、料金が変更したことをユーザに知らせるようにサービスする。
【００３６】
料金調整は、現在実行中の料金に特定の動作の遠隔からの呼び出しを含む。したがって顧客システムは、料金を受取る前にこの動作のサインを知ることができない、すなわち動作が顧客システムに知られている料金（表）インターフェイスの何れにも記載されない。
【００３７】
この問題を克服するために、ジャバによってサポートされる“反映（reflection）”特徴を使用する。料金調整を送達するために、プロバイダはInvocationオブジェクトの例を生成し、呼ばれる動作名を、それに供給されるパラメータと一緒に記憶する。次にこのオブジェクトはアナウンスメントプロトコルを使用して直列化し、サインし、アナウンスする。顧客システムによって調整を受取り、確認するとき、Invocationオブジェクトは直列化を解除して、反映を使用して記載した動作を呼び出すことによって現在の料金に適用される。
【００３８】
アナウンスメントプロトコルを簡単にするために、べき等元および完全(idempotent and complete)であることを要求される。べき等元は、１回以上行うときに、不利に料金に影響を与えないことを保証する。完全性とは、調整が料金オブジェクトの全体的なパラメータの組を判断して、前もって加えた調整の影響を完全に取除くことを示唆する。
【００３９】
顧客システムは、毎秒料金によってサポートされるgetCharge()動作を繰り返し呼出し、戻された値に累積的な課金を加えることによって料金を適用することができる。getCharge()に供給されるパラメータは、現在実行中の料金に依存する。例えば料金がPacketCountTariffの構成であるとき、過ぎた時間におけるインバウンドパケット、アウトバンドパケット、および輻輳の測定が要求される。しかしながら料金がRsvpTariffの構成であるとき、現在の予約を記述しているTSPECのみが要求される。これは、顧客システムがハット製品(hat product)と関係する料金によるパラメータ要求を供給できるときのみ、顧客システムは製品に加入できることを示唆している。
【００４０】
getCharge()方法の各呼び出しは、さらに料金に特定のユーザインターフェイスの更新を行う。例えばCongestionSensitiveLinear料金において、getCharge()に供給される使用パラメータを使用して、トラヒックおよび輻輳のグラフィック表示を更新する。
【００４１】
アナウンスメントプロトコルを使用して、直列化された料金および調整をプロバイダシステムから、多数の顧客システムへ通信する。多数の顧客システムは大きいと仮定され、反復されるマルチキャストの解決案が適用される。
【００４２】
プロバイダによってサポートされる各製品は、アナウンスメントのためにマルチキャストチャンネルに割り当てられる。顧客システムは、それらが使用している製品に対応するチャンネルを聞く。現在の構成では、各顧客が関心をもっている製品の周知のマルチキャストアドレスの知識をもつと仮定される。
【００４３】
各製品のチャンネルにおいて、プロバイダは現在の料金および（もしあれば）各製品に対して最も最近行われた調整を繰り返しアナウンスする。各アナウンスメントはバージョン数を保持し、バージョン数はアナウンスメントが変更されるたびごとにインクリメントされる。顧客システムのみが、バージョン数の変化が検出されるたびに処理する。新しい顧客がチャンネルに加わると、顧客システムは調整アナウンスメントを処理する前に料金を受取るまで待機する。さらに、アナウンスメントバージョンが現在の料金のバージョンよりも大きいときのみ調整が加えられて、失われた料金アナウンスメントは、古い料金に対して次の調整を加えないことを保証する。
【００４４】
この例では、課金は“支払いおよび表示”プロセスを使用して実行される。この実施形態の課金アーキテクチャを構成するのに使用されるオブジェクトをここで説明する。オブジェクトは、課金アーキテクチャのソフトウエア構成で使用される構成要素のオブジェクトとより高いレベルのオブジェクトと含む。幾つかのオブジェクトはクライアント端末（例えば、クライアント端末５）上に存在することを意図され、他のオブジェクトは“エッジネットワーク(edge network)”内のどこか（例えば、アクセスルータ７上または対応するネットワークサブドメイン内−図１参照）に存在することを意図されている。顧客端末上のオブジェクトは、セッション制御オブジェクトＳ、顧客ビジネス規則オブジェクトＢ_ｃ、顧客価格設定オブジェクトＰｒ_ｃ、ＱｏＳマネージャＱ、顧客口座オブジェクトＡｃｔ_ｃ、および顧客測定オブジェクトＭ_ｃを含む。ビジネス規則オブジェクトＢ_ｃは、支払いに対する信頼性を含むセッションの観点において情報を受取り、価格設定オブジェクトＰｒ_ｃから現在の価格設定データを受取る。課金可能なサービスが利用される顧客方策制御のもとで、および課金可能なサービスがどのくらい使用されるかにおいて、顧客ビジネスオブジェクトは決定を行う。これらの決定はＱｏＳマネージャＱへ供給され、ＱｏＳマネージャＱでは何れの機構を使用して要求を達成するかを決定する。次にＱｏＳマネージャ（および口座オブジェクト）は顧客測定オブジェクトＭ_ｃを制御し、トラヒックおよびサービスの測定するアスペクト（観点）および無視するアスペクト（観点）を判断する。次に測定オブジェクトは、選択したトラヒックのアスペクト、例えば顧客端末によって送信され受取られるパケット数の計数と、これらのパケットのＱｏＳレベルとを記録する。これらのデータは、輻輳に対する割り増し料金を含む現在の料金と一緒に、顧客端末によって使用され、ネットワークオペレータに支払い可能な課金を判断する。測定オブジェクトＭ_ｃも、口座オブジェクトによって、顧客口座オブジェクトＡｃｔ_ｃへデータを送る頻度を判断する命令でプログラムされる。顧客口座オブジェクトＡｃｔ_ｃはネットワークプロバイダドメイン内の口座オブジェクトＡｃｔ_ｐへ（課金されていても、されていなくても）口座情報を送る。
ネットワークプロバイダのサイド、すなわち顧客端末が接続されているサブドメイン内では、顧客のトラヒックはＭの１つのバージョン、すなわちＭｐによって、管理機能(policing function)Ｐ_ｏによって判断されるサンプリングのみに基いて測定される。したがって、ネットワークオペレータは断続的にのみ顧客のトラヒックをサンプル採りする。Ｐ_ｏはネットワーク内で測定を行って、特定の顧客のトラヒックの全てを捕捉するところを制御する。バルク測定機能Ｍ _ｂ は、ルータの待ち行列長の変化する平均に反映されるように、総トラヒックレベルを価格設定オブジェクトＰｒ_ｐへ報告する責務を負う。バルク測定は一般的に、プロバイダのドメインから（確実とするために複製される）集中型価格設定機能へ集められることになる。Ｐｒ_ｐは、ネットワークプロバイダのビジネスオブジェクトＢ _ｐ からのビジネス規則、およびＭ _ｂ によって報告された現在のトラヒックレベルと隣り合うプロバイダからの価格を考慮した価格を設定する。管理機能Ｐ_ｏはＭ_ｐからのサンプル測定と、顧客自身の測定結果としてのＡｃｔ_ｐにおいて受取られた口座メッセージとを比較する。管理機能Ｐ_ｏは、口座が不十分であると確認すると、アクセス制御ゲートウエイＡｃｓにおけるサービスを制限するか、または他の科料（懲らしめ）を開始する。口座オブジェクト内にエンカプシュレートされると、別の管理オブジェクトは支払いのために契約時間内の支払に整合する口座を検査する。最後に、識別子マッピング機能Ｉは、顧客の識別子（口座、ディジタルサイン、など）と現在のネットワークアドレス（一般的に、ユニキャストまたはマルチキャストでＩＳＰによって割り当てられる）とをマッピングする。
【００４５】
測定（Ｍ）オブジェクトは口座（Ａｃｔ）オブジェクトに、最初に口座記録を生成し、次に報告および請求書発行を行うことを要求される情報を供給する。測定記録は、それ自体Ａｃｔオブジェクト内に記憶されず：測定データは可能な限り早く口座記録へ変換される。測定データの口座記録への変換は、クラスタイプの課金およびその収集を含む。加えて測定データを料金情報にリンクしてもよい。測定オブジェクトによって戻される測定データは、この例では、次の要素を含む：
通信に関係する２つのエンドポイントのＩＰアドレス。これはネットワークパケットから容易に使用することができる；
ポート番号：これらを使用して、ユーザによって一度に使用される異なるサービスを区別する。ポート番号はネットワークパケットからも得られる；
パケットタイプ：サービス識別子。これはサービスのタイプを、例えばＲＳＶＰ、異なるサービスタイプ、またはデータとして識別する。この情報は、異なる料金をパケットタイプに依存して適用できるようにする；
ネットワーク使用情報。これは測定データそれ自体であり、例えばパケット数の計数を含んでもよい；
時間情報。これは、要素であるときは、使用されたときに測定を行った時間長を示す；
時間参照。これは開始時間と終了時間を含み、例えば規定の“オフピーク”時間中にトラヒックに割引きを適用するのに使用できる。
【００４６】
現在の好ましい構成では、測定データは測定オブジェクトによってイベントドライブ方式に基いて、口座オブジェクトによって制御される時間間隔でＡｃｔオブジェクトへ戻される。別のアプローチでは、Ａｃｔオブジェクトによる測定オブジェクトのポーリング、すなわちイベントドライブ方式のポーリングを使用してもよく：データ通信は、ジャバ−ＲＭＩ（遠隔方法の呼出し、remote method invocation）およびジャバイベントモデルを使用して行ってもよく、またはソケットをＡｃｔとＭの間に生成して、測定オブジェクトを送ってもよい。さらに別の通信機構では、ＣＯＲＢＡまたはＳＮＭＰのようなメッセージ送信の使用を含む。この例では、ＦＬＥＸＩＮＥＴと呼ばれるＲＭＩ−ＣＯＲＢＡのような分散形イベントプログラミングインフラストラクチャを使用する。
【００４７】
測定オブジェクト（Ｍ）は、Ａｃｔオブジェクトに制御インターフェイスを与え、Ａｃｔオブジェクトは測定するもの、およびＭが測定情報を報告する時と場所を制御することができる。この制御インターフェイスは、次のパラメータへのアクセスを与える：
１．測定記録が（所定の顧客または１組の顧客に対して）要求される頻度。これは、例えば現金払いおよび従来の請求書発行を含む異なる口座のビジネスモデルに適合することができる。頻度は多数のミリ秒から成る期間として特定してもよい。
【００４８】
２．（所定の顧客または１組の顧客について）Ａｃｔへ報告されるもの。このパラメータは全てのパケット、または所定のＱｏＳ閾値などをもつパケットのみを特定することになる。
【００４９】
３．（所定の顧客または１組の顧客について）測定値を報告する場所。このパラメータはＡｃｔオブジェクト、または監査およびマーケティングのための別のビジネスに関係するオブジェクトに対する簡単な参照であってもよい。
【００５０】
４．測定オブジェクトの現在の計量に関する性質。
【００５１】
ネットワークプロバイダにおいてメータ（計器）Ｍは、異なる顧客に対する異なる測定要求を多重化し、測定および報告処理を最適化する。
【００５２】
顧客端末における口座オブジェクトは、小さい暗号化されたフラットファイルデータベースを使用して構成してもよい。ネットワークプロバイダサイドでは、例えば何万もの顧客口座を取扱うのにスケーラブルなより大きいデータベースを使用して、等価のオブジェクトを構成することができる。オブジェクト要求ブローカ（ＯＲＢ）は、顧客側のオブジェクトとネットワーク側のオブジェクトとの間の通信に使用され、Iona Technologies plc.のＯＲＢＩＸ（商標）のような市販のツールを使用して構成される。直列化を使用して、１つのデータベースからネットワークを介して別のネットワークへオブジェクトを送る。直列化のプロセスではオブジェクトの全ての属性をとり、特定の媒体における属性を、データの送信元のオブジェクトタイプを特定する情報と一緒に送る。直列化を解除するプロセスは、送信媒体からのデータをオブジェクトタイプ情報と一緒にとり、特定のタイプの新しいオブジェクトを生成して、それをデータで一杯とする。口座データベースは、１組の直列化された口座オブジェクトを保持する。ネットワークプロバイダによって要求されるより大きいデータベースは、オブジェクト指向のデータベースであってもよく、これはオブジェクトを受領して、それらをメモリスペースへ直列化する。その代わりにオブジェクト指向でないデータベースを使用してもよく、この場合は口座オブジェクトはデータベースタイプに変換される。例えば口座オブジェクトは、リレーショナルデータベースで使用するためのＳＱＬデータタイプに変換される。
【００５３】
上述で開示した直列化／直列化解除機構を使用して、さらにネットワークドメイン間の測定および口座インターフェイスをサポートすることができる。例えば顧客端末との間でパケットを通信するネットワークのエッジドメインでは多数の隣り合うドメインへパケットを次々と送る。口座データは顧客からネットワークエッジのドメインへ送られると、口座データもネットワークエッジのドメインの顧客オブジェクト71から隣り合うドメイン内の口座オブジェクト72へ送られ、ネットワークエッジのドメインのオペレータによって隣り合うドメインのオペレータへ支払いが行われる。このコンテキストでは、ネットワークエッジのドメインでは小売業者のドメインであり、隣り合うドメインは卸売業者のドメインである。図１１に示したように、小売業者のドメインと卸売業者のドメインとの間のインターフェイスのアーキテクチャは、小売業者のドメインと末端部の顧客との間のインターフェイスの反復バージョンである。しかしながら末端部の顧客へのインターフェイスの全ての測定およびＱｏＳの特徴は、小売業者のネットワークと卸売業者のネットワークとのインターフェイスでは必要とされない。この例のように、多数の卸売業者のプロバイダがある場合には、小売業者のネットワークにおける現在のルート設定またはアドレス割り当て、あるいはこの両者は、卸売業者のネットワーク間で口座を割り当てるためにインターロゲートされる。これは識別マッピングＩの別の形態であることが好都合である。マッピングは、各隣り合うプロバイダの識別子、ユニキャストアドレスの現在のグループ、アドレスのプリフィクス、マルチキャストアドレス、または自律系（ＡＳ）番号間で必要とされている。これは、末端部の顧客が一般的に１つのプロバイダのみをもつので、エッジアーキテクチャには概して必要とされない。顧客によって多数のプロバイダが使用されるとすると、口座を割り当てるマッピングがエッジでも使用される。以前のように、小売業者のドメインと卸売業者のドメインとの間のトラヒック測定をサンプル採りして、データ流の測定と並列して行うことができ−このときブロッキングは必要はない。実際にはネットワークプロバイダの各対は相互の顧客であってもよい。この場合に、小売業者／卸売業者のインターフェイスのアーキテクチャは鏡映（mirror）され、全ての機能を両方向で実行する。したがってネットワークドメイン間の支払いは、各口座流の結果と関係する価格とのバランスによって判断される。
【００５４】
多数のドメインを含むネットワークでは、図１２に示したように、“卸し売り業者”のドメイン82は多数の小売業者のネットワーク81、83から口座データを受け取ることができる。これらのデータは、ドメイン82内の口座オブジェクトによって収集され、別の隣り合うドメイン、例えばドメイン84との間で割り当てられる。口座データを割り当てるやり方は、ドメイン82内に維持されている平均化された境界のルート設定表によって判断される。図３ａおよび３ｂは、口座オブジェクト間で送られるデータを示す。この例では、口座データは：口座識別子；請求書発行記録識別子；サービスタイプ識別子；送信元アドレス；送信先アドレス；料金識別子；時刻；期間（すなわち、請求書発行記録によってカバーされる期間）；ユニット；コスト；および通貨（カレンシイ）を含む。加えて、支払いデータは総額および支払われた通貨を含む。
【００５５】
図４は、顧客端末上のプロトコルスタックおよびネットワークドメイン内の測定領域を示す。理想的にはこの領域内には２つの測定点があり、例えば図７において（ａ）で参照される２つの地点では、一方は顧客によって委託され、他方はネットワークによって委託される。構成を簡単にするために、両方の当事者によって委託される単一の測定点（ｂ）を使用することができる。これは、例えばクライアント端末上の暗号カードのような保安モジュール内に構成される。その代わりに、測定は異なる地点で行ってもよく、このときは測定が一致しない可能性がある。ネットワーク上では、実際の測定点は、各顧客において、ネットワーク層のヘッダ（ｃ）（この場合はＩＰ）を検査する第１のアクセスデバイスにある。そのアクセスネットワークおよびシステムが遅延および損失を導くので、ＩＳＰはネットワーク（ｄ）へ向かってより深部を測定しない。
【００５６】
（例えば、ダイヤルアップアクセスの際に）個々の顧客において、測定実行点は、ネットワーク層と一緒であるが、エンドシステムのスタック（ｅ）内である。理想的にはこれらの測定点は、各スタックのより低いところにあり、２つの当事者間のインターフェイスにより近く、スタック内の競合によって影響される可能性は低くなることが多い。しかしながらリンク層（ｆ−ｆ）における測定は、ネットワーク層に設定された課金可能なパラメータのみが常にリンク層フレーム；すなわちネットワークレベルマルチキャストにおいて反映されるので不適切であり、二点間の待ち時間要求などはリンク層において見えないことがある。さらにリンク層のヘッダは、異なるリンク方式が一緒に連結されるところで明らかな不一致するのを避けるために帯域幅の計算におけるパケットの大きさを測定するときに無視される必要がある。
【００５７】
（スタックの上の）受信方向では、この測定点選択は、より高い層の最も厳格なＱｏＳ要求に対処するように、より低い層が（バッファの大きさ、割込み妨害、およびスレッドスケジューリング優先順位を）測寸されていなければならないことを示唆されている。フレームが物理的媒体を取り去られるとき、この機械は、使用により課金するデータがネットワーク層を得る前に（例えば、中断コンテンションによって生じるバッファのオーバーフローによって）このデータが捨てられることなくスタック上にデータを送ることができなければならない。ネットワーク層では、ＩＳＰのサービスが測定され、ＱｏＳ要求が（エンドシステムにおいて）さらにスタック上へ送られるか、または（ルータ上を）送られるときにＱｏＳ要求が種々のフローの正しい差動処理を制御するのに最も便利なところである。
【００５８】
上述の測定オブジェクトは、一般的に市販されているネットワーク測定ソフトウエア、例えばNevil Brownlee’s NeTraMetシステムを適切に変更をして使用して実施することができる。これは、RFC 2063およびRFC 2064に記載されたアーキテクチャにしたがうＩＥＴＦインターネットに一致するソフトウエアメータである。このメータは、“パケットスニッフィング（packet sniffing）”を使用して、エンドポイントアドレスによって定められるトラヒックフローにおけるパケットおよびバイト計数値（カウント）を構築する。しかしながら一般的にアドレスはイーサネットアドレス、プロトコルアドレス（ＩＰ、DECNet、EtherTalk、ＩＰＸ、またはＣＬＮＳ）、またはトランスポート（移送）アドレス（ＩＰポート番号、など）、またはこれらの組み合わせであってもよいが、この構成ではＩＰアドレスのみが使用される。観察されるトラヒックフローは1組の規則によって特定され、‘マネージャ’プログラムによってNeTraMetへダウンロードされる。トラヒックフローデータは、‘コレクタ’プログラムからＳＮＭＰ（簡単なネットワーク管理プロトコル、Simple Network Management Protocol）を介して集められる。
【００５９】
図５ないし９は、上述の測定および口座オブジェクトの構成を示すクラスダイヤグラムである。クラスダイヤグラムは一連の図として示した。
【００６０】
制御図（図５）は、報告制御機能、測定に関係する制御機能、および一般的な制御機能を含む口座クラスを制御することに関係するクラス／インターフェイスを纏めたものである。図５は、イベント配布にも関係する。口座クラス上の制御は、制御タイプにしたがって分けられる。したがって４つのインターフェイスは使用可能となる。これらのインターフェイスの２つは口座オブジェクトの振舞いを直接に制御し、残りの２つは、報告情報および測定情報の両方を通信するのに使用されるジャバイベントモデルに関係している。ActControlインターフェイスは、一般に、口座の振舞いに関係している口座クラスを制御する。このActControlインターフェイスは、振舞いまたは特性を設定する方法と口座オブジェクトの現在の振舞いを見付ける方法の両方を用意している。例えば、このインターフェイスを使用して、口座オブジェクトの名前を設定するか、または既にＡｃｔオブジェクトに与えた名前を見付けるようにＡｃｔオブジェクトに照会する。ActReportインターフェイスは口座報告に関係する問題を制御する。制御呼は、口座オブジェクトの報告の振舞いに直接に関係している。例えば、addReportListener()と呼ばれる方法を使用して、情報報告における関心を登録する。登録が有効であると、他の制御方法への次の呼は報告頻度、即時の報告に対する要求、報告の保安特性、などのような振舞いを規定する。口座クラスが構成する２つの他のリスナインターフェイス（ReportListenerおよびMeasurementListener）を使用して、口座オブジェクトが口座報告および測定に関心をもっていることを示す。
【００６１】
口座報告の図（図６）は、口座オブジェクトにおける報告の振舞いおよび報告のプロセスに関係するクラス／インターフェイスを再びグループ化する。口座オブジェクトは口座報告を聴いて、このようなイベントをさらに生成する。口座オブジェクトは口座報告を生成し、（従来のジャバイベントモデルを使用して）このようなイベントへの関心を登録したオブジェクトにイベントを分配する。このような構成では、フレキシネット(flexinet)（ＣＯＲＢＡのような分散形プログラミングインフラストラクチャ）を使用して、口座オブジェクトから遠隔にあるオブジェクトから報告できるように、オブジェクト間の通信をサポートする。口座クラスはReportListenerインターフェイスを構成して、口座クラスがこのような口座報告も受取ることができるようにする。口座報告イベントはReportEventクラスについて行われる。このクラス内のイベントは、報告オブジェクトを含む従来のジャバイベントである。報告クラスにおける主要な属性は記録である。記録は口座記録の簡単なベクトルである。これらの記録は口座メモリの図（図７）に記載されている。ActRepoortCtrlインターフェイスは、口座オブジェクトの口座報告プロセスに関係する制御呼を規定する。呼を使用して、オブジェクトが口座報告における関心を登録し、関心の登録を解除し、報告プロセスを制御するようにできる。
【００６２】
口座メモリの図（図７）は、口座情報の持続性メモリに関係するクラスを示すためにクラス／インターフェイスを再びグループ化する。口座オブジェクトは、口座記録のデータベースをもつ。記録タイプは、価格設定されていない口座情報を保持している。価格設定された情報は、異なるクラスの主題である。データベースクラスは記録オブジェクトの簡単なベクトルであり、外部のメモリ媒体上のファイルに対して直列化することができる。データベースはさらに、報告されなければならない口座記録を戻す責務も負っている。
【００６３】
口座計測図（図８）は、口座クラスの計測の観点に関係するクラス／インターフェイスを示すためにクラス／インターフェイスを再びグループ化する。これは、口座オブジェクトにおける測定情報の受取りと、Meterの制御および簡単なMeterクラスの表示の両方に関係する。Meterクラスは、要求に応じてパルスイベントを生成する“パルサ(Pulsar)”オブジェクトを使用する。パルスの周波数はMeterオブジェクトによって設定される。パルスを受取ると、MeterはMeasurementEventオブジェクトを生成する。MeasurementListenerインターフェイスを構成し、かつ測定結果における関心を登録したオブジェクトは、measurementHandler方法を介してこれらのイベントを受け取る。既に記載したように、Meterオブジェクト、および測定イベントを受け取るオブジェクトの１つ以上は互いに離れていてもよい。測定イベントは通常のジャバイベントであり、MeasurementRecordの測定記録を含む。口座オブジェクトは、口座オブジェクトはMeterControlインターフェイスを介して制御を行ったMeterから測定情報を得る。一般的な制御例は測定報告の頻度であり、したがって口座オブジェクトは、計測オブジェクトがそれに報告する頻度を制御することができる。この制御インターフェイスも、測定結果における関心を登録するのに使用するインターフェイスである。
【００６４】
その他の口座の図（図９）は、図５ないし８では適合しない全ての他のクラス／インターフェイスを示すためにクラス／インターフェイスを再びグループ化している。これはJava（登録商標）Beanに関係するクラス、すなわちコードおよびグラフィカルユーザインターフェイス（ＧＵＩ）を実行するクラスを含む。AccountingBeanInfoクラスはJavaBeanに関係するクラスであり、このJavaBeanに関係するクラスは、その特性がBeanBoxおよび他の構成要素作成ツールにおいて図示されなければならないときにAccountingクラス上のいくつかの属性の記述を変更する。GoおよびMeterGoクラスのみが主要な方法を構成する。Goを使用して口座オブジェクトを開始し、MeterGoを使用してMeterオブジェクトを開始する。AccountingGUIクラスは、口座オブジェクトに関係するＧＵＩに対して責務を負う。Meterオブジェクトはそれに関係するＧＵＩをもっていない。図１０にはAccountingGUIを示した。ＧＵＩの最上部は口座オブジェクトからのデータを含み、最下部は口座オブジェクトにおいて使用できる制御に関係する。制御部は口座オブジェクトに使用できる制御インターフェイスに直接に関係する。口座クラスは、ＧＵＩから口座クラスへ参照するときにＧＵＩに気付かない。
【００６５】
上述の口座機構は、顧客、小売業者、および卸売業者のネットワークの間における支払いの確実性および支払うことを期待される人を設定する契約と組合せて使用することができる。次の段落では、支払いを行うための異なる清算モデルを記載する。この段落のシステムは、上述の特定の口座機構と関連して、または独立して使用することができる。
支払いの清算（ペイメントクリアランス）
“支払いに対する責任”および“支払うことを期待される人”に加えて、支払を受けるべき人に対する疑問もある。各エッジＩＳＰは送られたサービスと受け取ったサービスの両方について“半巡回（half-circuit）”ベースで支払うことができる。しかしながら他のビジネスモデルをサポートしてもよい。ビジネスモデルにおいて、ＩＳＰが全てのエッジプロバイダに向けて行われている送りと受けとのトラヒックの全てについての支払いを期待しない場合は、代わりに顧客が電話の場合のような両方（全て）の末端に代わってそれ自身のプロバイダへ支払ってもよい。別の口座フィールド−すなわち“受取人”フィールドが必要なことは明らかである。例えばこの代わりのビジネスモデルは、システムに入ったエッジの顧客からフロー毎に顧客によって何れの端末へ支払われるかに関する決定であってもよい。進むのにしたがって明らかになるので、我々はこのモデルを“プロバイダ清算”モデルと呼ぶ。これは図１３に示されている。ここでは、末端部の顧客91および92は、多数の中間のネットワーク93を介して通信する。このモデルにおけるプロバイダ間の金融の流れは、何れの末端部において支払いがフロー（またはパケット）ごとのベースでシステムに入るかに依存する。いくつかのフローでは、末端部間のコスト共有に比例していてもよい。したがってビジネスモデルの柔軟性のために、“ローカルな”または“遠隔した”末端部と単に述べるのではなく、“受取人”フィールドは、その代わりに“受取人の割合”フィールド−すなわち末端部において顧客によって支払われる合計コストの割合を考慮したフィールドであってもよい。したがって普通は、“ローカルのプロバイダに全て支払われる”か、または“遠隔のプロバイダへ全て支払われる”という典型的な場合は１００％または０％である。差額は遠隔した末端部が支払うことになる。しかしながらこのモデルについての知覚された目的は、ローカルな受取人が１００％を得るときのトランザクション効率であることに注意すべきである。しかし“プロバイダ清算”モデルには一定の欠点がある。
【００６６】
上述で既に指摘したように、“受取人の割合”フィールドではプロバイダ間の口座をドライブしなければならず、そうでないと末端部のＩＳＰおよびその上流のプロバイダの収入は完全にその制御外の要因に依存し−したがって顧客はその末端部へ支払うことを選択する。したがって“受取人の割合”フィールドは、上流のプロバイダによって委託（信頼）されなければならない。フィールドの改ざん防止を助けるために、このフィールドは遠隔のＩＳＰによってサインされることが必要である。サインされたフィールドをサインの完全性を失わずに収集するやり方がある。収集は、関係している全ての当事者によって委託された第３の当事者（ＴＴＰ）によってサインされたソフトウエアおよびＴＴＰによって再びサインされた記録によって行われなければならない。しかしながら収集ソフトウエアはＴＴＰによって委託されたホスト上でも実行しなければならない。さらに、全ての末端部のＩＳＰが遠隔のアドレスから遠隔のＩＳＰを識別するのは、階層的なルート設定ではできないこともあったが、このモデルを使用すると、この識別は必ずできることを意味する。それにも関らず、既に記載したように、遠隔ＩＳＰの支払いインターフェイスは末端部のステーション間のより高いレベルのプロトコルで送られるようにできる。この口座記録（会計記録）内にこれを含むことは、ステーションにとってほんのわずかに複雑になるだけである。しかしながら依然としてＩＳＰは、これが有効なＩＳＰであって、しかも遠隔のアドレスに整合しているかといった適切な検査を行なわなければならない。ＩＳＰがアドレスをもつと、複雑さはほんの僅かになるが、効率は悪くなり、ローカルなＩＳＰが上流のプロバイダを介して清算を行う長所を打ち消してしまうことが多い。将来の応用について、当事者間の支払いの分け前が固定されておらず、フローの特徴に依存するか、または他のパラメータがより高いレベル−すなわちプロバイダが正規に関心をもっているよりも高いレベルのみで理解したとすると、さらに相当に複雑になる。これは“期待される支払人”フィールドについての問題でもあるが、この場合は“プロバイダ清算”モデルにおける“受取人の割合”フィールドとは異なり、フィールドは情報提供に過ぎない。
【００６７】
最終的な支払い先である全てのエッジプロバイダの現在の価格を考慮にいれて、支払いを理想的に分割しなければならない。（電話用の国際口座レートシステム（ＩＡＲＳ）において使用される）唯一の代替案では、ＩＳＰにとって不一致の価格の平均をとったプロバイダ間の折衷価格に同意することになる。
【００６８】
通常インターネット上で見られるプロバイダの連鎖は相当に長いために、正確な位置に収入が到達する前に、潜在的に受理不能な遅延がもたらされることになる。支払いが確認されないままである間に、予備の委託機構を呼出さなければならないので、清算における遅延は支払いシステムのコストを相当に増加する。これらの委託機構は、プロバイダのみにではなく、エッジの顧客に適用されなければならず、したがってシステムの全コストを相当に増加する。
【００６９】
このような制限にも関らず、このようなモデルは支払いトランザクション数を低減することが明らかである。例えばインターネットの電話上での会話中の当事者の両者（全て）が発呼者によって支払われるとすると、発呼者が自分自身のＩＳＰへの全員の支払い金額を支払い、次にこのＩＳＰによって正しい総額を上流のプロバイダへバルクトランザクションの一部として送らせるとき、複雑さが緩和されると考えられる。他方で、（図１４に示した）“第３の当事者の清算”において、発呼者は関係する両者（全て）の当事者の両者（全て）のＩＳＰ間の支払いを分割しなければならない。
【００７０】
これが２つのモデルの名称間の区別が、誰が支払われるかにではなく、清算において行われる理由でなる。両方のモデルが、半巡回ごとに支払われる末端部のＩＳＰで終了する。支払時の支払人から受取人へのルートにはほとんど差がない。プロバイダと一緒に支払いの清算はデータ経路にしたがう。プロバイダはこの経路に沿って、一緒にされることになる２つの金銭上の分け前(money sharing)形式：すなわち卸し売り分け前半巡回共有（wholesale cut half-circuit sharing）でプロバイダの分け前を取る。
【００７１】
“第３の当事者の清算”システム（または２つの末端部間の清算システム（end to end clearing system）と呼ばれる）において、清算ハウス（clearing house；交換所、情報センタとして働く）の役割は（２つの末端部間の直接的な価格差を含む）半巡回シェアリングを取扱って、プロバイダ間の口座（勘定口）を卸し売り専用にすることである。第３の当事者の清算部は、管理プラットフォーム10の１つまたはネットワークドメインの１つに接続された追加のプラットフォーム上で構成することができる。プロバイダまたは顧客は清算ハウスの役割をもつと仮定できるが、口座情報モデルは第３の当事者の清算システムに基いていて、最も一般的な場合を許容する。支払いを行う顧客が専用の清算ハウスへ支払いを行なうか、遠隔の末端部においてＩＳＰに指示するか、または遠隔の顧客へ指示して顧客が自分自身のＩＳＰへ支払うことができるようにするものを明確にするために、全ての場合においてこの機能を達成する別のエンタープライズがないとしても、清算の役割は別々となっている。最後の場合は特別であり−清算の役割は無であるが、依然として情報モデルに現われる。半巡回共有がプロバイダの連鎖を介して達成されるとすると、これは卸し売りのために口座とは別々に維持されなければならない。そうでないとすると、インフラストラクチャ上に構成することができるモデルタイプは制限される。
【００７２】
清算の役割を別々にするとき、ここでこれは電話会社がそのビジネスにおける別の役割−すなわち“セッション小売業者”の役割も纏めたことを明らかに示している。したがって、末端部のtelco（電話会社）は固定価格で電話セッションを提供するが、各セッションを集めるのに必要なプロバイダによって課金される全ての２地点間の価格のみから構成されているとしたときに価格を変更するのに適用可能なやり方の数よりも、価格の範囲は小さい。ここでもまたこの役割はインターネットの世界における末端部の顧客（エッジカスタマ）によって仮定できるが、他の当事者にとってはＩＰサービス上で販売し、同時に、プロバイダの課金される卸し売り価格の変化を吸収することによって伝送に対する価格を提供することが可能である。この役割はtelcoおよびＩＳＰによっても取り続けられる。
【００７３】
口座メッセージの中で実際に何れの末端部に支払われるかを述べることは冗長である。現在他のプロバイダの口座はローカルプロバイダの口座で一括されるべきでないといった規則があるので、最終的に誰が支払いを受け取るかは、
暗示（暗黙）的である。口座は、最終的にローカルプロバイダによって行われる支払いに暗示的に関係していると推論される。口座中に誰に支払われるかを述べることは冗長である。これは支払い時間にのみ関係がある。そこで結果的に支払いが意図される人を述べることは、清算機構に与えられるとして、不可欠である。
【００７４】
図１５は、ネットワークにおいて末端部の価格設定を行うことを示す図である。パケットはＮ_ａからＮ_ｂへ、さらに他のネットワークへマルチキャストされることが示されている。マルチキャストはユニキャストを包括しているので、マルチキャストによって両者のトポロジをモデル化することができる。送信方向を逆にすることによってこのトポロジを集合体(aggregation)として取扱うこともできる。パケットという用語を使用しているが、矢印は一定の時間における類似のクラスのパケットの流れを表わしている。モデル化されているパケットまたはフローはデータまたはシグナリングであってもよい。異なる源からのパケットは常に別々のままであるので、多数の源のマルチキャストを別々にモデル化する必要はない。図１５では、ネットワークＮ_ａとＮ_ｂ との間における価格設定を強調している。Ｗ_ｂａｓとＷ_ｂａｒ は、それぞれＮ _ｂ にデータを送信するためおよびＮ _ｂ からデータを受信するためにＮ _ａ がＮ _ｂ に適用する課金に加えられる各方向の重み付けを示しており、一方でＷ _ａｂｓ とＷ _ａｂｒ は、それぞれＮ _ａ にデータを送信するためおよびＮ _ａ からデータを受信するためにＮ _ａ に課金するときにＮ _ｂ が加える重みである。問題となっている末端部とそのプロバイダの遠隔したエッジのみではなく、インターネットの遠隔した末端部との間の送信のために、価格はそれぞれ重み付けされている。それぞれのネットワーク間のインターフェイスには、このような４つの価格の重み付けがあるが、隣り合うものが同じ状態でない限り、重み付けは異なる値をとる。したがって各インターフェイスにおける一方向におけるトラヒックの支払いは、ネットワークの何れかの側によって提起された２つの重み付けされた価格間の差に依存する。言い換えると、誰がプロバイダであり、誰が顧客であるかに関して仮定は行われず；したがってこれは単に1度に行われる課金間の差のサインに依存する。明らかに、エッジの顧客（例えば、Ｎ_ｃ）はネットワーク接続された市場におけるプロバイダ状態が分からない。したがって、全てのｊにおいて、Ｗ_ｃｊｒ＝０である。したがって全ての受取りの重み付けをゼロに設定するか、または全ての送信の重み付けをゼロに設定することによって‘送信者のみの支払い’または‘受信者のみの支払い’のようなシナリオを解析することができる。例えば、ポリシー（policy）の安定性は、１つのネットワークが独立独行ポリシー(maverick policy)から得られるか否かを評価することによって判断することができる。
【００７５】
‘送信者のみの支払い’または‘受信者のみの支払い’は、主として受信者である顧客と主として送信者である顧客を異なるプロバイダへ移動することを促すことが多い。この状況は、支払いを行わない全顧客をもつプロバイダが相互接続ビジネス（interconnect business）から全ての収入を得るので維持することができる。1つのネットワークが独立独行（マベリック）となるとすると（例えば、他のネットワークが送信者のみを課金しているときに、受信者のみを課金すること）、支配的な送信者および受信者の両者がより廉価なプロバイダを選択するので、何れかのシナリオが安定を維持する。したがって独立独行のプロバイダが最初にパンクするのが確実になり、全システムへの収入が低減する−したがって独立独行は抑制するべきである！ しかしながら、これらの両方のポリシーではネットワークの使用は明らかに不十分とし、両方ともマルチキャスト（結果的に集合体）に関する限り不安定である。
【００７６】
対照的に、‘送信者および受信者の支払い’はユニキャストおよびマルチキャストの両方の場合に安定している。これは上述の場合とは異なり、ネットワークを十分に使用できる。これはさらに、受信価格を送信価格と異なって重み付けすることによって、支配的な送信者および受信者の異なるバランスを提供することもできる。例えば、少数の大きな支配的な送信者と、多数の小さい支配的な送信者とがあるとして、大きい支配的な顧客を管理する規模の経済がより低い送信者の重み付けとして反映されるようにできる。同様に、多数のユニキャストと比較して、小さい受信者のコミュニティへの非効率的なマルチキャストは、マルチキャストされる送信者の価格設定を僅かに重み付けすることによって阻止することができる。
【００７７】
上述ではインターネットのような連結されたパケットデータネットワークコンテキストにおける例を開示したが、本発明の多くの態様は回線交換ＰＳＴＮ（公衆交換電話ネットワーク）のような他のタイプのネットワークにも利用できる。図１７はこのコンテキストに応用される本発明の例を示す。このネットワークでは、顧客端末131、この例ではマイクロプロセッサとデータインターフェイスを組込んだ電話である、いわゆるインテリジェント電話は、ローカル交換132およびトランク交換133を介して電話ネットワークへ接続される。トランク交換133は、ＳＳ７（シグナリングシステム番号７）のシグナリングネットワーク２を介して、高度な呼制御機能を実行する責務を負うサービス制御ポイント135へ接続される。サービス制御ポイント135は、請求書発行オペレーションに対して責務を負い、さらにこの例では、ネットワークにおける料金設定を制御するオペレーショナルサポートサーバ136へも接続される。ＯＳＳサーバおよび顧客端末は、料金エンティティ（ＴＥ）を含む。固定ＰＳＴＮネットワークはさらに、ゲートウエイ137を介してセルラＧＳＭネットワーク138へ接続される。セルラネットワーク内の基地局ＢＳは、インテリジェント移動電話139へ信号を通信する。動作において、ネットワーク料金は、ＰＳＴＮネットワークおよびＧＳＭネットワークを介して顧客端末へ分配される。従来料金はここでも、顧客端末内のプロセッサ上で実行されるジャバ機能の形態を取ってもよい。ジャバ機能は、インターネットパケットとしてストリームにされる。１つの構成では、これらのインターネットパケットは、ＰＳＴＮネットワークおよびＧＳＭネットワーク、それら自体を介して分配することができる。例えば、パケットは、ＭＴＰ（メッセージトランスポートパート）のトランスポート層を使用してトランク交換へエンカプシュレートして、移送され、バンド外シグナリングを使用して顧客端末へさらに通信することができる。その代わりに、別々のデータ接続をＯＳＳサーバと顧客端末との間で公衆インターネットを介して設定することができる。上述の例では、ネットワークオペレータはネットワーク内の資源のローディングをモニタし、顧客端末内の料金エンティティに信号を送って、不足または他の関連する資源を反映するように料金を変更することができる。顧客端末、それら自体はネットワークローディングをモニタし、自動的に種々の料金を生成することができる。ネットワーク資源の使用度は、ネットワーク内で実行される従来の請求書発行の代わりに顧客端末によってローカルに測定することができる。ネットワークオペレータは、上述のように、サンプリングを実行することによって使用データの測定を管理することができる。
【図面の簡単な説明】
【図１】 本発明を実現するネットワークを示す模式図。
【図２】 本発明の例示的な実施形態を実施するために使用される口座オブジェクト間で送られるデータを示す図。
【図３】 本発明の例示的な実施形態を実施するために使用される口座オブジェクト間で送られるデータを示す図。
【図４】 顧客端末上およびネットワークドメイン内のプロトコルスタックを示す模式図。
【図５】 口座オブジェクトおよび測定オブジェクトを構成するソフトウエアのクラスダイアグラム。
【図６】 口座オブジェクトおよび測定オブジェクトを構成するソフトウエアのクラスダイアグラム。
【図７】 口座オブジェクトおよび測定オブジェクトを構成するソフトウエアのクラスダイアグラム。
【図８】 口座オブジェクトおよび測定オブジェクトを構成するソフトウエアのクラスダイアグラム。
【図９】 口座オブジェクトおよび測定オブジェクトを構成するソフトウエアのクラスダイアグラム。
【図１０】 図５ないし９のオブジェクトで使用するグラフィックユーザインターフェイス（ＧＵＩ）を示すダイヤグラム。
【図１１】 図１のネットワークの隣り合うドメイン間のインターフェイスを示すダイアグラム。
【図１２】 多数のネットワークドメインを通る口座データの分配を模式的に示すダイアグラム。
【図１３】 サービスプロバイダの清算を使用してネットワークを示すダイヤグラム。
【図１４】 第３の当事者の清算を使用してネットワークを示すダイヤグラム。
【図１５】 分割形エッジ価格設定を示す図。
【図１６】 料金インターフェイスを示す図。
【図１７】 別の実施形態を示す図。

Claims (28)

1. （ａ）複数の顧客端末の各々においてネットワーク資源の各顧客端末による使用を測定するステップと、
   （ｂ）次に、ステップ（ａ）によって生成された測定データからネットワーク使用料金を計算するステップと、
   （ｃ）少なくとも１の顧客端末によるネットワーク資源の使用を、該１又はそれぞれの顧客端末によるネットワーク資源の使用の一部のみを測定することによりサンプリングし、これを、該サンプリングされた使用に関して、ステップ（ａ）において該１又はそれぞれの顧客端末によって測定されたネットワーク資源の使用とステップ（ｂ）において計算されたネットワーク使用料金の１又は両方と比較するステップと、を備える通信ネットワークを動作する方法。
2. それぞれの顧客端末における一連の測定により生成された測定データを集計するステップをさらに含む請求項１に記載の方法。
3. 該測定データを記憶するステップをさらに含む請求項１または請求項２に記載の方法。
4. 該測定データと共に、前記測定データに適用可能なタリフを識別するデータを記憶するステップを含む請求項３に記載の方法。
5. ステップ（ａ）によって生成されたデータまたはステップ（ａ）によって生成されたデータから導き出されたデータを、ネットワークオペレータによって制御されるネットワーク口座オブジェクトへ通信するステップを含む請求項１ないし請求項４の何れか１項に記載の方法。
6. ネットワーク口座オブジェクトへ、該測定データから計算される使用料金を通信するステップを含む請求項５に記載の方法。
7. 測定データを顧客端末から遠隔のシステムへ通信するステップを含む請求項１ないし請求項６の何れか1項に記載の方法。
8. 前記サンプリングするステップは、ネットワークオペレータによって実行され、顧客端末とネットワークとの間で通信されるトラヒックの一部のみをサンプリングするステップを含み、このサンプリングされたトラヒックについて、このようにしてサンプリングされたネットワーク使用をそれぞれの顧客端末からネットワーク口座オブジェクトへ通信されるデータと比較して、それにより不一致を検出するステップをさらに含む請求項５または請求項６に記載の方法。
9. ネットワーク口座オブジェクトが、ネットワークオペレータによって制御される測定オブジェクトからまたは顧客端末からデータを受け取るように構成することができる請求項１ないし請求項８の何れか１項に記載の方法。
10. 顧客端末と関係する顧客口座オブジェクトが、データをネットワーク口座オブジェクトへ導くように構成することができる請求項９に記載の方法。
11. 前記測定オブジェクトからデータが受け取られる構成と、顧客端末からデータが受け取られる別の構成との間で、ネットワーク口座オブジェクトにおいて受け取られた制御信号に応答して、ネットワーク口座オブジェクトをスイッチングするステップを含む請求項９または請求項１０に記載の方法。
12. タリフを各顧客端末へ通信するステップと、各顧客端末においてタリフからおよび口座データからネットワーク使用料金を計算するステップとをさらに含む請求項１ないし請求項１１の何れか１項に記載の方法。
13. 該通信ネットワークが、複数のネットワークドメインを備える連合形のデータネットワークである請求項１ないし請求項１２の何れか1項に記載の方法。
14. 顧客端末と、この顧客端末に接続された第１のネットワークドメインとの間でトラヒッ
    クを通信するステップと、
    第１のネットワークドメインと、該第１のネットワークドメインに接続された第２のネ
    ットワークドメインとの間で前記トラヒックをさらに通信するステップと、
    顧客端末から第１のドメイン内の第１のネットワーク口座オブジェクトへネットワーク使用データを通信するステップと、
    第１のネットワーク口座オブジェクトと、第２のドメイン内の第２のネットワーク口座オブジェクトとの間で口座データを通信するステップとを含む請求項１３に記載の方法。
15. 第１のネットワークドメインにおける現在のルート設定テーブルから、第１のネットワークドメインを介して顧客端末とデータを通信する第２のドメインの識別子を判断し、顧客端末に関するネットワーク使用データを現在のルート設定テーブルによって識別される第２のドメインへ通信するステップを含む請求項１４に記載の方法。
16. 前記測定するステップが、顧客端末と通信ネットワークとの間で送られるパケットで通信されるデータ量を計数するステップを含む請求項１ないし請求項１５の何れか1項に記載の方法。
17. 顧客端末によって受け取られるパケットと顧客端末によって送られるパケットの両方を測定するステップを含む請求項１６に記載の方法。
18. ネットワークのローディングに依存してネットワーク使用に対するタリフを自動的に変更して、該タリフを測定データへ適用することによってネットワーク使用に対する料金を計算するステップを含む請求項１ないし請求項１７の何れか1項に記載の方法。
19. 複数の異なるサービスクラスをもつネットワーク上でパケットを送るステップを含む請求項１ないし請求項１８の何れか1項に記載の方法。
20. 前記パケットをパケットルータを通して送り、該パケットルータにおいてパケットに適用可能なサービスクラスを判断し、各サービスクラスに依存して異なってパケットをスケジューリングするステップを含む請求項１９に記載の方法。
21. パケットの分類を管理して、各サービスクラスに対するパケットの適格性を判断するステップが、ルータから遠隔の位置において実行される請求項２０に記載の方法。
22. 前記管理するステップが、顧客端末において実行される請求項２１に記載の方法。
23. ネットワークは少なくとも１のネットワークドメインを備え、該１又はそれぞれのネットワークドメインはそれぞれのネットワークオペレータにより動作される請求項１に記載の通信ネットワークを動作する方法において、該方法は、
    （１）ネットワークへ接続された送信元の顧客端末から、該ネットワークへ接続された少なくとも１つの送信先の顧客端末へデータフローを設定するステップと、
    （２）該または各ネットワークオペレータから決済エンティティへタリフデータを通信するステップと、
    （３）決済エンティティから、送信元および送信先顧客端末の少なくとも１つへ２地点間フローに関するタリフデータを通信するステップと、を備え、
    前記ステップ（ａ）は、
    （４）送信元の顧客端末からネットワーク内へ流れるデータ量と、ネットワークから該１の又はそれぞれの送信先の顧客端末へ流れるデータ量とをそれぞれの顧客端末で測定するステップを備え、
    該方法は、
    （５）ステップ（４）によって生成された測定データを該決済エンティティへ通信するステップと、
    （６）該決済エンティティで測定データおよびタリフから料金を計算するステップと、
    （７）該計算された料金にしたがって該決済エンティティから少なくとも１のネットワークオペレータの少なくとも１へ支払を行うステップと、
    （８）２地点間タリフにしたがう請求書を、該決済エンティティから、送信元顧客および送信先顧客の少なくとも１へ通信するステップと、をさらに備え、
    前記ステップ（ｃ）は、少なくとも１の顧客端末によるネットワーク資源の使用を、該１のまたはそれぞれの顧客端末による使用の一部のみを測定することによりサンプリングし、サンプリングした使用に関して、これをステップ（４）において該１またはそれぞれの顧客端末により測定されたネットワーク資源の使用とステップ（６）において計算されたネットワーク使用料金の１又は両方と比較するステップとを備える、請求項１に記載の方法。
24. 不一致が検出されたときに、顧客に科料を課すステップを含む、請求項８、または請求項８に従属するときの請求項９ないし請求項２３の何れか１項に記載の方法。
25. 請求項１ないし請求項２４の何れか１項に記載の通信ネットワークを動作する方法において、該ネットワークは複数のネットワークドメインを備え、該方法はネットワークを介して第1の顧客から第２の顧客へトラヒックを伝送するときのネットワーク資源の使用に対する料金を計算するステップをさらに含み、
    （Ａ）該伝送において使用されるネットワーク資源に依存してコストを判断するステップと、
    （Ｂ）第１および第２の顧客に対するコスト割り当てパラメータを判断するステップと、
    （Ｃ）該コストと割り当てパラメータとを組合せることによって第１と第２の顧客の一方または両方に対する料金を計算するステップ、とを含む方法。
26. 通信ネットワークと該ネットワークに接続された複数の顧客端末を備える通信システムにおいて、
    各顧客端末は、ネットワーク資源の端末による使用を測定する測定手段と、該測定されたネットワーク使用に依存してネットワーク使用料金を計算する計算手段の１又は両方を含み、
    該ネットワークは、顧客端末測定手段によって生成された測定データと、顧客端末計算手段によって生成された使用料金データの１又は両方を受信する受信手段を含み、
    該ネットワークは、少なくとも１の顧客端末によるネットワーク資源の使用を、該１のまたはそれぞれの顧客端末によるネットワーク資源の使用の一部のみを測定することによりサンプリングし、サンプリングした使用に関して、これをそれぞれの顧客端末から受信した測定データと使用料金データの１又は両方と比較するサンプリング手段をさらに含む、通信システム。
27. 顧客端末測定手段によって生成された測定データと、顧客端末計算手段によって生成された使用料金データの１又は両方を受信する受信手段と、
    顧客端末の少なくとも１によるネットワーク資源の使用を、該１またはそれぞれの顧客端末によるネットワーク資源の使用の一部のみを測定することによりサンプリングするサンプリング手段と、
    該サンプリング手段により測定された使用と、それぞれの顧客端末から受信した測定データと使用料金データの１又は両方とを比較する比較手段とを備える請求項２６に記載のシステムにおいて使用する通信ネットワーク。
28. 顧客端末によるネットワーク資源の使用を測定する測定手段と、測定された使用から導き出される使用または料金データを、該顧客端末が使用されていてネットワークに接続されているときに、ネットワーク内に配置された口座手段に送信する送信手段とを備える請求項２６に記載のシステムにおいて使用される顧客端末。

Images