JP2003198599A - ネットワーク・ユーセージの計量方法 - Google Patents

Abstract

(57)【要約】 【課題】ネットワーク顧客に課金するために使用可能な
インターネット・ユーセージの計量方法を提供する。 【解決手段】本発明は、課金データを容易に計算できる
ように、ネットワーク上の少なくとも２つのサイト間で
発生するサービス消費を定量化する情報を抽出するシス
テムおよび方法を対象とする。サービス消費の測定は、
ネットワークと通信する顧客によって消費されるサービ
スに関する。本発明の方法は、顧客によるインターネッ
ト・ユーセージを監視すること、監視されたインターネ
ット・ユーセージ中に発生するデータ処理リソースの消
費情報を記録すること、および、定義された期間内に記
録された顧客によるデータ処理リソース消費の量を求め
ることを含む。この情報を使用して、インターネット等
のネットワークの使用に対して顧客に課金するのに適し
た詳細情報が提供される。

Description

【発明の詳細な説明】 【０００１】 【発明の属する技術分野】本発明は、一般にネットワー
ク管理に関し、より詳細にはインターネット・ユーセー
ジを計量することに関する。 【０００２】関連出願 本出願は、同時係属であり同時に出願され、本願と同一
の譲受人に譲渡された米国特許出願第１０／０１２，７
１３号の「ENHANCED SYSTEM AND METHOD FOR NETWORK U
SAGE MONITORING」に関連する。本特許出願はまた、以
下に挙げる同時係属でありかつ本願と同一の譲受人に譲
渡された米国特許出願にも関連する。すなわち、米国特
許出願第０９／５５９，４３８号の「INTERNET USAGE D
ATA RECORDING SYSTEM AND METHOD EMPLOYING BATCH CO
RRELATION OF INDEPENDENT DATASOURCES」、同第０９／
５６０，５０９号の「INTERNET USAGE DATA RECORDING
SYSTEM AND METHOD WITH CONFIGURABLE DATA COLLECTOR
SYSTEM」、同第０９／５５９，６９３号の「INTERNET
USAGE DATA RECORDING SYSTEM AND METHOD EMPLOYING D
ISTRIBUTED DATA PROCESSING AND DATA STORAGE」、お
よび同第０９／５６０，０３２号の「INTERNET USAGE D
ATA RECORDING SYSTEM AND METHOD EMPLOYING A CONFIG
URABLE RULE ENGINE FOR THE PROCESSING AND CORRELAT
ION OF NETWORK DATA」であり、これらはすべて２００
０年４月２７日に出願されている。本出願は、さらに以
下の同時係属でありかつ本願と同一の譲受人に譲渡され
た米国特許出願第０９／５７８，８２６号の「INTERNET
USAGE DATA RECORDING SYSTEMAND METHOD EMPLOYING A
CONFIGURABLE RULE ENGINE WITH IP ADDRESS RANGE MA
TCHING FOR THE PROCESSING OF NETWORK DATA」に関連
する。 【０００３】 【従来の技術】インターネットによるサービスの使用が
増大し、サービスの種類が増大することにより、かかる
サービスの消費に対する計量（metering）および課金
（billing）を行う有効なメカニズムが必要となってい
る。同一または同様のインターネット接続メカニズムを
利用する様々な顧客によるデータ消費量は、テキスト、
オーディオファイル、ビデオファイルおよび写真といっ
た種々の特徴によって変動する。従って、個々の顧客に
よって消費されるサービスのレベルを追跡することが望
ましい。 【０００４】かかるユーセージ（usage：使用量）を追
跡するための１つのメカニズムは、インターネット・ユ
ーセージ・マネージャ（ＩＵＭ）である。ＩＵＭは、ル
ータ、ＡＴＭスイッチ、Ｗｅｂサーバ、メールサーバ、
ＶＯＩＰ（Voice over Internet Protocol）および無線
ゲートウェイ等のネットワーク機器からユーセージ情報
を収集し、顧客サイトのニーズに基づいてユーセージ情
報をフィルタリングし結合して、その情報をファイルベ
ースかまたはプログラミング的な（ＡＰＩ）手段によっ
て任意のアプリケーションが容易に利用可能できるもの
に加工する、ネットワーク・ユーセージ・メディエーシ
ョン（mediation）メカニズムである。ＩＵＭの上位に
構築可能なアプリケーションには、課金、容量計画、フ
ロード（不正）検出およびマーケティング分析が含まれ
る。 【０００５】ＳＮＭＰ（Simple Network Management Pr
otocol）は、マルチベンダ相互運用ネットワーク管理の
ために広く使用される規格のセットである。ＳＮＭＰプ
ロトコルは、ネットワーク・マネージャがエージェント
を管理しエージェントと情報を交換するために広く使用
されている。エージェントについてのネットワーク管理
情報は、オブジェクトのセットからなる管理情報ベース
（ＭＩＢ）と呼ばれるデータベースに格納される。管理
されたオブジェクトはすべて、階層構造またはツリー構
造で配置される。各オブジェクトは、一般に一意の識別
子と関連付けられ、例えば１．３．１．６．１．２．
１．１．３のような整数のシーケンスから構成される
（これは、ｉｓｏ．ｏｒｇ．ｄｏｄ．ｉｎｔｅｒｎｅ
ｔ．ｍｇｍｔ．ｍｉｂ２．ｓｙｓｔｅｍ．ｓｙｓｕｐｔ
ｉｍｅを表す）。この一意の識別を、オブジェクト識別
子（ＯＩＤ）と呼ぶ。ここで、「ｉｓｏ」は国際標準化
機構（International Organizations for Standards）
を表し、「ｏｒｇ」は「組織（organization）」を表
し、「ｄｏｄ」は「米国国防総省（Department of Defe
nse）」を表し、「ｍｇｍｔ」は管理（management）を
表し、「ｍｉｂ２」は管理情報ベース２（management i
nformation base 2）を表し、「ｓｙｓｕｐｔｉｍｅ」
はシステムが最後に初期化された時点から任意の所与の
瞬間までの経過時間である「システム稼動時間（system
up time）」を表す。 【０００６】情報は、一般に、ＳＮＭＰ−Ｇｅｔまたは
ＳＮＭＰ−Ｓｅｔ演算を指定するＳＮＭＰメッセージの
形式によりマネージャとエージェントとの間で交換され
る。ネットワーク・マネージャは、ＳＮＭＰ−Ｇｅｔま
たはＳＮＭＰ−ＧｅｔＮｅｘｔ演算を使用してエージェ
ントのＭＩＢにおけるいくつかのオブジェクトの値を検
索することによって、エージェントを監視することがで
き、それらの値をＳＮＭＰ−Ｓｅｔ演算によって変更す
ることによって、そのエージェントを制御することがで
きる。 【０００７】ＳＮＭＰ−Ｇｅｔ演算は、一般に、ＭＩＢ
テーブル内のオブジェクトまたは行エントリに関する情
報を検索するためのコマンドである。ＳＮＭＰ−Ｓｅｔ
演算は、一般に、ＭＩＢテーブル内のオブジェクトまた
は行エントリに値を割り当てるためのコマンドである。
ＳＮＭＰ−ＧｅｔＮｅｘｔ演算は、一般に、特定のＯＩ
Ｄによって識別される行の直後の、ＭＩＢテーブル内の
行に関する情報を検索するためのコマンドである。 【０００８】一般に、ＳＮＭＰ演算は、ＭＩＢ内のオブ
ジェクト・インスタンスへのアクセスを伴う。複数オブ
ジェクトの交換を容易にするために、ＳＮＭＰメッセー
ジは、一般に「変数バインディング」フィールドを含
む。このフィールドは、一般に、オブジェクト・インス
タンスの参照のシーケンスとそれらオブジェクトの値と
から成り立つ。ＭＩＢオブジェクトが複数の行を含むテ
ーブルである場合、通常はＳＮＭＰ−ＧｅｔＮｅｘｔ演
算を使用してテーブルがスキャンされ、先に参照された
参照のシーケンスに従ってテーブルに次に発生するオブ
ジェクト・インスタンスの値が発見される。 【０００９】「リモートモニタ（ＲＭＯＮ）」は、ＳＮ
ＭＰプロトコルの拡張形式である。ＲＭＯＮは、一般
に、リモートのローカル・エリア・ネットワーク（ＬＡ
Ｎ）を管理するためのアルゴリズムとデータベースを定
義する。一般に、ＲＭＯＮ仕様を実装するシステムまた
はネットワーク機器は、ＲＭＯＮプローブと呼ばれる。
ＲＭＯＮプローブは、一般に、そのローカルのＲＭＯＮ
ＭＩＢを読み書きし、ＳＮＭＰプロトコルを介してネ
ットワーク・マネージャと通信することにより、ネット
ワーク・トラフィック情報を取込むことができる。ＲＭ
ＯＮプローブは、一般に、７層ＯＳＩ（Open Systems I
nterconnect）ネットワーク・プロトコル・スタックの
物理層で情報を取込むことができる。 【００１０】ＲＭＯＮ２は、ＯＳＩネットワーク・プロ
トコル・スタックのアプリケーション層までの分析を提
供する、ＲＭＯＮのアップグレードである。さらに、Ｒ
ＭＯＮ２は、「タイムフィルタ」と呼ばれる新たなイン
デクシング・オブジェクトの使用を通じて、ＭＩＢテー
ブル内の行エントリの値が変化した行のみをＭＩＢテー
ブルから検索するための特別な「ＭＩＢトリック(tric
k)」を提供することによって、マネージャとプローブと
の間の通信の効率を向上させる。タイムフィルタ・メカ
ニズムを使用して、ＳＮＭＰ−ＧｅｔＮｅｘｔ演算にお
いてタイムフィルタ・コンポーネントを特定の時点に設
定することで、管理ステーションは、その特定の時点か
らエントリが変化した行のみを一般に検索する。 【００１１】 【発明が解決しようとする課題】ＲＭＯＮ２ ＭＩＢテ
ーブルの使用によりネットワーク・ユーセージ・アクテ
ィビティを記述する情報は集約されるが、データ消費情
報は、依然として、顧客のネットワーク接続の履歴にお
ける固定の時点から発生するすべてのデータ消費を累積
する方法で提供される。従って、検索されたデータをさ
らに処理しなければ、かかる情報を課金の目的のために
容易に使用できないことがある。 【００１２】従って、既存のインターネット・ユーセー
ジ監視では、データ消費を定量化するデータが長期間に
わたって取得されるいう問題がある。 【００１３】また、既存のインターネット・ユーセージ
監視によって引き出されるデータは、一般にネットワー
ク顧客への課金目的に使用するためには追加の処理が必
要であるという問題がある。 【００１４】従って、上記の問題を解決する必要性が当
技術分野に存在する。 【００１５】 【課題を解決するための手段】本発明は、ネットワーク
・ユーセージを計量するシステムおよび方法を目的とす
る。本発明のシステムおよび方法は、顧客によるインタ
ーネット・ユーセージを監視すること、監視されたイン
ターネット・ユーセージによるデータ処理リソース消費
を記録すること、および、定義された期間内に記録され
た顧客によるデータ処理リソース消費の量を求めること
を含む。本発明のシステムおよび方法によって、一度に
複数の顧客によるネットワーク・ユーセージを記録し表
で表す（tabulate）ことができることは理解されよう。 【００１６】 【発明の実施の形態】本発明は、課金データをすぐに計
算できるように、ネットワーク上の少なくとも２つのサ
イト間で発生するサービス消費を定量化する情報を抽出
するシステムおよび方法を対象とする。一般に、関連の
あるサービス消費測定は、ネットワークと通信する顧客
によって消費されるサービスに関する。 【００１７】従来技術は、総量の観点から、指示された
サービス消費にアプローチするが、本発明のアプローチ
では、好ましくは、定義された時間窓内で発生するデー
タ処理リソースの消費を識別する情報を分離する。好ま
しくは、この分離された情報を使用して、インターネッ
ト等のネットワークの使用に対し顧客に課金する際の使
用に適した詳細情報を提供する。 【００１８】本明細書において、「ネットワーク・ユー
セージ」、「インターネット・ユーセージ」「サービス
消費」および「データ処理リソース消費」という用語
は、一般に、インターネット等のネットワークによって
顧客に提供されるデータ取得等のサービスの量に対応す
る。サービス消費には、限定されないが、テキストデー
タ、イメージデータ、オーディオデータおよび／または
ビデオデータの形式のネットワークによるデータの取得
が含まれる。サービス消費は、予約帯域幅の量、１つま
たは複数の通信経路の直接性（directness）および／ま
たは速度、顧客のインターネット接続のサービスの品
質、送受信されたメッセージの数、ネットワーク上の特
定のユーザサイトから探索等の目的のためにリモートの
ノードのコンピュータによって消費される処理労力の
量、探索されるデータレコードの数、または上記したも
のの任意の組合せに対応しても良い。本明細書でより詳
細に説明するように、課金の目的のためには、特定のユ
ーザまたは顧客によるネットワークへのアクセスの定義
された時間窓内で発生するこのようなデータ処理リソー
ス消費の量を特定することが望ましい。 【００１９】本明細書において、「サイト」という用語
は、一般に個別のＩＰ（インターネット・プロトコル）
アドレスを有しネットワークと通信するノードに対応
し、「絶対時間」という用語は、一般に、実質上普遍的
な時間基準点を参照する時刻または他の時間測定値等の
量に対応する。 【００２０】好ましい実施形態では、本発明は、課金の
ために、連続するポーリングサイクル間のデータ消費、
または他のサービス消費の変動を計算する能力を提供す
る。ＲＭＯＮ２は、特定の時刻または時点から変化した
データテーブルエントリを返すことができるが、一般
に、提供される値は消費されたデータの絶対値であるた
め、エントリの変化量に関してはいかなる示唆も与えて
くれない。上述の内容は、ＲＭＯＮ２プローブが再始動
される時に初めて、テーブルエントリが埋められる(pop
ulate)ことから、正しい。 【００２１】しかし、ＲＭＯＮ２ ＭＩＢテーブル行イ
ンデックスの第２の要素、すなわちタイムフィルタ要素
は、好ましくは、特定の時刻からのデータ消費情報に関
連するタイムスタンプを提供するため、２つの異なる時
点における同一のＭＩＢテーブル行エントリの２つのイ
ンスタンス間の差を計算することによって、増分データ
消費情報を取得することができる。 【００２２】好ましい実施形態では、ＩＵＭ ＲＭＯＮ
２エンキャプスレータ(Encapsulator)は、ＭＩＢテーブ
ル行インデックスのタイムフィルタ・コンポーネントを
取り除き（strip out）、残りの行インデックスを内部
ハッシュテーブル・エントリに対するキーとして使用す
ることによって、これを達成する。好ましくは、データ
消費情報は、そのキーを使用して後にアクセスすること
ができるエントリに対する値として格納される。ＭＩＢ
テーブルから情報を検索する次のポーリングサイクルで
は、タイムフィルタ・コンポーネントが無いテーブル行
インデックスをハッシュテーブルに対するキーとして使
用することにより、以前の期間についてのデータ消費情
報を取得することができる。 【００２３】好ましい実施形態では、最後の期間の累積
データ消費情報はハッシュテーブルから取得される。好
ましくは、連続するポーリング演算において収集される
累積データ消費値間の差を計算して、この２つの連続す
るポーリング演算間で消費されたデータの量を計算す
る。次いで、現在のポーリングサイクルの累積データ消
費値を好ましくはハッシュテーブルに格納することで、
続くポーリングサイクルの完了時に増分データ消費情報
を計算できるようにする。 【００２４】好ましい実施形態では、顧客に課金できる
アクティビティには、限定されないが、ネットワークか
ら顧客に送信されるデータの量、顧客からネットワーク
に送信されるデータの量、インターネット・セッション
中にアクセスまたは探索されるデータの量、顧客により
アクセスされたネットワークに連結されたコンピューテ
ィングノードが顧客の要求に応答して引き受けるアクテ
ィビティの処理量、または上記の任意の組合せが含まれ
る。 【００２５】好ましい実施形態では、ＲＭＯＮ２は、Ｓ
ＮＭＰと共に動作する技術規格であり、ネットワーク・
アクティビティを監視するように動作する。ＩＵＭのコ
ンポーネントの１つ、すなわちＲＭＯＮ２エンキャプス
レータは、好ましくは、ポーリングサイクル（その期間
は事前に設定することができる）毎に１回ネットワーク
上のＲＭＯＮ２プローブと通信し、かかるＲＭＯＮ２プ
ローブの各々に関連するＭＩＢテーブルを取得する。Ｒ
ＭＯＮ２プローブは、好ましくはトラフィックを監視
し、かかる監視アクティビティの間に収集されたトラフ
ィック情報でＲＭＯＮ２ ＭＩＢテーブルを埋める（po
pulate）。これらＲＭＯＮ２ ＭＩＢテーブルは、一般
に、ＩＰアドレスと、プロトコルソースおよび定義と、
定義された時間窓にわたって記録された情報を検索する
ために使用できるタイムフィルタ情報とを含むオブジェ
クトを有する。 【００２６】好ましい実施形態では、ＲＭＯＮ２プロー
ブは、トラフィックを監視し、ＭＩＢテーブルエントリ
を完成させる。一般に、ＭＩＢテーブル内の各オブジェ
クトは、オブジェクト識別子（ＯＩＤ）に一意に関連付
けられる。好ましくは、ＲＭＯＮ２エンキャプスレータ
が設定される時、調べられているＯＩＤオブジェクトと
共に、プローブのＩＰアドレスが指定される。好ましく
は、オブジェクトに関する情報の検索時に、例えばユー
セージおよび課金情報を生成するために、この情報を望
み通りに使用することができる。このように、本発明
は、ＭＩＢテーブルの連続するインスタンス間のテーブ
ルエントリまたはオブジェクトにおける変化量をＲＭＯ
Ｎ２が求められるようにすることによって、従来技術と
区別される。 【００２７】従って、本発明の好ましい実施形態の利点
は、既知の継続時間の期間に関連し、絶対時間の測定値
で定義される開始点および終了点を有するネットワーク
・ユーセージ情報を収集することができる点にある。 【００２８】本発明の好ましい実施形態のさらなる利点
は、収集されたネットワークユーセージ情報を使用し
て、課金情報を容易に生成することができる点にある。 【００２９】本発明の好ましい実施形態のさらに別の利
点は、顧客によって消費されるデータ処理リソースを正
確に考慮する課金情報を生成することができる点にあ
る。 【００３０】図１は、本発明の好ましい実施形態の動作
を示す。顧客ＩＰ接続３００は、好ましくは、サービス
・プロバイダ・サイト１０３を介してインターネット１
００に接続される。ＩＵＭ（インターネット・ユーセー
ジ・マネージャ）２００は、好ましくは、顧客ＩＰ接続
３００（および任意に、顧客ＩＰ接続Ｎ ３００−Ｎ等
の他の同様の接続）とインターネット１００または他の
ネットワークとの間に発生するアクティビティを監視し
て、課金情報１０２を生成するために有益に用いること
ができるインターネット・ユーセージ計量情報１０１を
生成するように動作する。課金情報１０２に加えて、Ｉ
ＵＭ２００は、容量計画情報、フロード検出情報および
／またはマーケティング分析情報を有益に提供するため
に使用することもできる。 【００３１】図２を参照すると、ＩＵＭ２００が、限定
されないが、ＲＭＯＮ２／ＳＮＭＰプロトコル２０１お
よびＲＭＯＮ２エンキャプスレータ２０３という機能要
素を含むことが分かる。ＲＭＯＮ２、すなわち「リモー
トモニタ２」は、本発明の監視方式において、およびＲ
ＭＯＮ２プローブ２０２との通信中にエンキャプスレー
タ２０３のアクティビティに対して利用することができ
るただ１つのプロトコルであることが認められよう。本
発明とともに他のプロトコルを利用することもできるこ
とは認められよう。 【００３２】好ましい実施形態では、エンキャプスレー
タ２０３内には、図３とともにより詳細に説明するハッ
シュテーブル３０４が含まれ、エンキャプスレータ２０
３はＩＵＭ２００内に含まれる。ＩＵＭ２００は、図３
とともにより詳細に説明するネットワーク・マネージャ
３０１のアクティビティのサブセットを実行する。ＩＵ
Ｍ２００の演算に加えて、ネットワーク・マネージャ３
０１は、好ましくはＲＭＯＮ２プローブ２０２等のネッ
トワーク機器も設定する。 【００３３】好ましい実施形態では、ＩＵＭ２００は、
例えばＳＮＭＰ「ＧｅｔＮｅｘｔｔａｂｌｅ−ｗａｌ
ｋ」コマンド等の適当なコマンドを送信することによ
り、ユーセージ計量のためのデータを検索する。好まし
くは、検索を行うＩＵＭ２００エンティティは、ＲＭＯ
Ｎ２エンキャプスレータ２０３である。ＩＵＭ２００を
利用する時、ユーザは、好ましくは、ＲＭＯＮ２プロー
ブのＩＰアドレスと、いずれのＲＭＯＮ２ ＭＩＢオブ
ジェクトを問合せるか（オブジェクトのＯＩＤを指定す
ることによって）と、ＲＭＯＮ２プローブをポーリング
する頻度と、コミュニティおよびポート番号等の他のＳ
ＮＭＰ設定とを指定して、ＲＭＯＮ２エンキャプスレー
タ２０３を構成する。 【００３４】好ましい実施形態では、ポーリングが開始
すると、ＲＭＯＮ２エンキャプスレータ２０３は、ルー
プ内で一連のＳＮＭＰ−ＧｅｔＮｅｘｔ演算を、０にセ
ットされた「変数バインディング」の初期タイムフィル
タ・インデックス値と共に発行することによって、指定
されたＲＭＯＮ２プローブ２０２に対する問合せを実行
する。タイムフィルタは、通常、変数バインディング・
インデックスの第２のインデックス・コンポーネントで
ある。返された結果は、一般に、直前のポーリング・サ
イクルから値が変化したテーブルエントリを含む。これ
ら返された結果はその後、好ましくは内部ハッシュテー
ブルに保存される。好ましくは、ＲＭＯＮ２プローブの
現在のｓｙｓＵｐＴｉｍｅ値も、次のポーリング・サイ
クルのために保存される。一般に、ｓｙｓＵｐＴｉｍｅ
の最後に保存された値がタイムフィルタ値として使用さ
れ、後続の「ｔａｂｌｅ ｗａｌｋ」は、最後のポーリ
ング・サイクルから変化した行のみを返す。一般に、
「ｔａｂｌｅ ｗａｌｋ」は、ＭＩＢテーブル内のすべ
てのエントリを検索する連続的なＳＮＭＰ「ｇｅｔｎｅ
ｘｔ」演算である。 【００３５】本明細書では、「ｓｙｓＵｐＴｉｍｅ」値
は、一般に「システム稼動時間」値に対応し、現システ
ムが動作している時間の総量を意味する。この値は、
日、週、月または年で測定することができ、一般にいか
なる特定のインターネット・セッションの長さよりもは
るかに長い。 【００３６】次に図３を参照する。好ましい実施形態で
は、ＲＭＯＮ２プローブ２０２のＭＩＢテーブル３０３
のポーリングから返される行は、ハッシュテーブル３０
４に格納され、そこでは、行インデックスがこのテーブ
ルに対するキーの役割を果たす。ＲＭＯＮ２テーブル行
インデックスは、１つのポーリングサイクルから次のポ
ーリングサイクルまでに変化するタイムフィルタ・コン
ポーネント３０７を含むので、好ましくはこれらインデ
ックスをさらに操作してタイムフィルタ・コンポーネン
ト３０７を取り除くことで、異なるポーリングサイクル
からの同じ行をハッシュテーブル３０４内の同じ行に帰
属させる（attribute）ことができる。この手法は、１
つのポーリングサイクルから次のポーリングサイクルま
でのテーブルエントリの変化量を計算するために有益に
利用することができる。 【００３７】さらに図３を参照すると、顧客ＩＰ接続３
００とインターネット１００との間の通信は、好ましく
は、顧客ＩＰ接続３００のインターネット・ユーセージ
の計量を実行するために、ネットワーク・マネージャ３
０１によって監視される。好ましくは、ネットワーク・
マネージャ３０１とＭＩＢテーブル３０３との間の対話
のために、適当なネットワーク管理プロトコル３０２が
利用される。ネットワーク管理プロトコル３０２は、限
定されないがＳＮＭＰ、ＲＭＯＮまたはＲＭＯＮ２を含
む任意の適当なプロトコルであって良い。ＩＵＭ２００
（図２）の機能は、一般に、ネットワーク・マネージャ
３０１の演算のサブセットである。ネットワーク・マネ
ージャ３０１の機能は、好ましくは、サービス・プロバ
イダ・サイト１０３内で実現される。しかし、追加的に
または代替的に、顧客ＩＰ接続３００を含むサイトにお
いて、ユーセージ計量を実現することもできる。好まし
くは、ＭＩＢテーブル３０３は、図３に示すようにＲＭ
ＯＮ２プローブ２０２のコンポーネントである。 【００３８】種々の異なるネットワーク管理プロトコル
を任意に採用して、任意の顧客数および複数の異なるネ
ットワーク・マネージャを用いて、本発明を実施できる
ことが認められよう。さらに、複数の異なるネットワー
クが１つまたは複数の顧客と通信することもでき、この
ような変形はすべて本発明の範囲内に含まれる。 【００３９】好ましい実施形態では、ネットワーク・マ
ネージャ３０１は、そのローカルＭＩＢテーブル３０３
をネットワーク・マネージャ３０１によって消費される
ことが意図された情報で埋めるように、ＲＭＯＮ２プロ
ーブ２０２を構成する。ＭＩＢテーブル３０３のオブジ
ェクト３０５は、好ましくは、タイムフィルタ・コンポ
ーネント３０７によって指示される特定の時点につい
て、顧客ＩＰ接続３００を介して使用されたインターネ
ット・サービスの量を定量化するエントリを含む。一般
に、オブジェクト３０５に含まれるインターネット・ユ
ーセージの量は、顧客ＩＰ接続３００とインターネット
１００との間の対話の履歴におけるある時点から開始
し、ＭＩＢテーブル３０５のデータがポーリングされる
時点で終了するすべてのユーセージをカウントする、累
積された合計である。一般に、顧客ＩＰ接続３００とイ
ンターネット１００との間の対話の履歴における参照点
は、実質的に、ポーリングが発生する時点からは遠く離
れている。一般に、ＭＩＢテーブル３０３の連続するイ
ンスタンスは、一般的に値がリセットされないので、次
第に増大するインターネット１００のユーセージの累積
された合計を含んでいる。顧客３０９は、顧客ＩＰ接続
３００にアクセスしているように示されている。ＩＰ接
続３００を介して１人の顧客のみがインターネットに接
続している場合もあるが、複数の異なる顧客がそのよう
に接続することも可能であることが認められよう。同一
のＩＰ接続３００に複数の異なる顧客３０９が連続して
接続することも可能である。 【００４０】顧客がサービス・プロバイダに接続される
と、一般に顧客には一意のＩＰアドレスを有するＩＰ接
続が提供される。その後、一般にＲＭＯＮ２プローブが
オンとされた時点で開始する期間にわたってエントリが
累積される、ＭＩＢテーブルエントリが生成される。従
って、このようなエントリは、一般に１つのインターネ
ット・セッションまたは１人の顧客に関連付けられるア
クティビティを分離しない。 【００４１】最初の顧客が顧客ＩＰ接続３００等の特定
の顧客ＩＰ接続から切断すると、後に同一のＩＰ接続に
ログオンする異なる顧客によって、同じＩＰアドレスが
使用されるようにすることが可能である。しかし、後の
ユーザまたは顧客が別の顧客によって先に使用されたＩ
Ｐアドレスに接続する時、テーブルエントリ値は一般に
リセットされない。従って、テーブルエントリ値には、
一般にこのような後のユーザのユーセージを反映する量
が加えられる。従って、この後のユーザのインターネッ
ト・セッションが終了すると、テーブルエントリ値は、
一般に複数の異なるインターネット・セッションにわた
り累積した量を表すことになる。この理由により、単一
のインターネット・セッションに関連するインターネッ
ト・ユーセージを分離するために、累積ユーセージ測定
値の変化を反映するインターネット・ユーセージ・デー
タをテーブルエントリから抽出することが望ましい。 【００４２】好ましい実施形態では、ＭＩＢテーブル３
０３等のＭＩＢテーブルはＲＭＯＮ２プローブ２０２の
一部であり、ＩＵＭのＲＭＯＮ２エンキャプスレータ２
０３（図２）のための情報源である。好ましくは、ＲＭ
ＯＮ２プローブ２０２は、インターネット１００のユー
セージを監視し、そのローカルＭＩＢテーブルを埋める
（populate）。ＩＵＭのＲＭＯＮ２エンキャプスレータ
２０３は、好ましくは、ＳＮＭＰ「ｇｅｔ ｎｅｘｔ」
コマンドを介してＲＭＯＮ２プローブ２０２と通信し
て、ＲＭＯＮ２プローブのＭＩＢテーブルから情報を検
索する。そして、ＲＭＯＮ２エンキャプスレータ２０３
は、ＭＩＢテーブル行インデックスからタイムフィルタ
・コンポーネントを取り除き、取り除かれたインデック
スを自身の内部ハッシュテーブルへのキーとして格納す
る。次いで、ＲＭＯＮ２エンキャプスレータ２０３は、
好ましくは、ＭＩＢテーブル行インデックスをそのハッ
シュテーブルの値として格納し、ハッシュテーブルはさ
らなる処理のために保存される。タイムフィルタ・コン
ポーネントに加えて、ＭＩＢ行インデックスは、好まし
くは、ＲＭＯＮエンキャプスレータ２０３とＲＭＯＮ２
プローブ２０２との間の通信のために利用されるプロト
コルの他に、ソースおよび宛先ＩＰアドレス等の情報を
含む。 【００４３】好ましい実施形態では、定義された期間に
わたる顧客ＩＰ接続３００によるインターネット・ユー
セージ量の変化を計算するために、ＭＩＢテーブル３０
３の連続したインスタンスから情報を抽出することが望
ましい。連続するＭＩＢテーブル・インスタンスにおけ
るインターネット１００のユーセージの累積された合計
における変化量は、好ましくは、ポーリング・サイクル
間のタイムスパンにおける顧客ＩＰ接続３００によるイ
ンターネット・ユーセージの消費を表し、これによって
ＭＩＢテーブル３０３の連続するインスタンスが生成さ
れる。同様に、連続的に取得されたＭＩＢテーブル３０
３に見られるインターネット１００のユーセージ・アク
ティビティの累積された合計間の差を計算して、既知の
継続時間の期間内に発生し、かつ既知の開始時刻および
終了時刻を有するネットワーク・ユーセージを求めるこ
とができる。 【００４４】例えば、第１のＭＩＢテーブル３０３のイ
ンスタンスが次のようなエントリを含むとする。 【００４５】 【表１】 時刻 総消費データ 午後８時 101,000メガバイト 【００４６】また、第２のＭＩＢテーブル３０３のイン
スタンスが次のようなエントリを含むとする。 【００４７】 【表２】 時刻 総消費データ 午後９時 102,500メガバイト 【００４８】絶対時間値とバイト量の差を計算すると、
次のようになる。 【００４９】 【表３】 タイムスパン 消費データ ６０分 1,500メガバイト 【００５０】上記の例では、関係する期間は、午後８時
に開始し１時間続くものとして完全に定義されている。
２つのポーリング・サイクルおよび２つのＭＩＢテーブ
ルエントリ・インスタンスの間に消費されたデータは、
１，５００メガバイトであるように示されている。上記
最後のテーブルにおける情報は、好ましくは、課金情報
に容易に変換可能である。さらに、タイミング情報が利
用可能であるため、かかる課金情報は容易に項目別に分
けることができる。従って、上記最後のテーブルで示さ
れたサービスに対する請求書は、以下のようになる。 【００５１】 【表４】 費用 消費データ 開始時刻 終了時刻 日付 15.00ドル 1,500メガバイト 午後8時 午後9時 2001年3月1日 【００５２】好ましい実施形態では、変更されたインタ
ーネット・ユーセージ・データはハッシュテーブル３０
４に格納される。タイムフィルタ・コンポーネントは、
好ましくはオブジェクト３０５のテーブル行インデック
スから取り除かれ、内部ハッシュテーブル・エントリに
対するキーとして使用される。好ましくは、連続するポ
ーリング・サイクル間の時間差が計算され、ハッシュテ
ーブル３０４内の変更されたオブジェクト３０６内に含
まれる。変更されたオブジェクト３０６は、好ましく
は、定義された期間内のユーセージ・アクティビティを
表すデータを含む。オブジェクト３０６の「変更」と
は、一般にそこからタイムフィルタ・コンポーネントを
取り除くことを言う。 【００５３】図４は、本発明の好ましい実施形態による
インターネット・ユーセージ・アクティビティの第１の
ポーリング結果に対応する例示的なエントリのテーブル
である。本発明のメカニズムが１分のポーリング間隔を
使用してＭＩＢデータを検索および処理する実施例を考
慮する。 【００５４】本実施例は、２００１年１月１日の午前１
２時で開始する。現プローブの「システム稼動時間」
は、2,970,720,450ミリ秒である（図示せず）。ＳＮＭ
Ｐ「ｇｅｔｎｅｘｔ」演算であってよい問合せから４つ
の行が返され、それら行には図４において１〜４の番号
が与えられ、それぞれ参照番号４０３〜４０６を有して
いる。回復されたエントリは、好ましくは内部ハッシュ
テーブル４００に格納される。タイムフィルタ・コンポ
ーネントは、好ましくは行インデックスから取り除かれ
る。取り除かれたタイムフィルタ・テーブル行インデッ
クスは、好ましくはハッシュテーブル４００に対するキ
ーとして保存される。この行インデックスは、一般にそ
の内部に、ソースＩＰアドレス、宛先ＩＰアドレス、プ
ロトコルおよびポート番号等の符号化された追加の情報
を有している。 【００５５】好ましい実施形態では、値列４０２は、好
ましくは、同じ行に列記されたＩＰアドレスに対して伝
送されたバイトの量を含む。キー列４０１は、好ましく
は、インターネット等のネットワークと対話している特
定の顧客を顧客のＩＰアドレスによって識別するエント
リを含む。図５および図６において、キー列５０１およ
び６０１は、好ましくは特定の顧客を識別する情報も含
む。 【００５６】続いて図５のテーブル５００を参照する
と、このときの時刻は午前１２時１分である（図示せ
ず）。システム稼動時間、すなわちタイムフィルタ値
は、2,970,780,450ミリ秒であり（図示せず）、図４に
結果を示したポーリング演算から60,000ミリ秒後すなわ
ち１分後である。値エントリ５０２は、行１（５０
３）、行２（５０４）および行４（５０６）に対しての
み変化しており、行３（５０５）のエントリは変化して
いないことがわかる。図４のキー列４０１と同様に、列
５０１は、好ましくは、ネットワークと対話している特
定の顧客を識別するエントリを含む。 【００５７】実施例の説明を続けると、その後、午前１
２時２分、すなわち第２のポーリング演算の60,000ミリ
秒後に第３のポーリング演算が行われ、その結果が図６
に示されている。図６のテーブル６００を見ると、行１
（６０３）に対する値６０２のみ変化したことが分か
る。具体的には、値列６０２と行１（６０３）との交点
おけるエントリが6,608,000から6,609,000に変化してお
り、これは１０００の増加、すなわち行１（６０３）の
「キー」フィールド６０１に示されたＩＰアドレスを有
する顧客によって１０００バイトが消費されたことを表
している。行６０４〜６０６の値列６０２のエントリ
は、図５の行５０４〜５０６における列５０２のそれぞ
れのエントリから変化していない。図４、図５および図
６のそれぞれの値列４０２、５０２および６０２のエン
トリは、一般に、図３に関連して説明した変更されたオ
ブジェクト３０６に対応する。 【００５８】実施例の説明を続けると、図７のテーブル
７００は、本発明の好ましい実施形態により３つのポー
リング・サイクルで収集された情報に基づくユーセージ
・レコードを示す。図７のテーブルのデータは、「開始
時刻」列７０１、「終了時刻」列７０２、ソースＩＰア
ドレス７０３、宛先ＩＰアドレス７０４、およびバイト
で表されたユーセージ７０５に区分して示されている。
行７０６〜７０９の各々は、指定された継続時間を有し
絶対時間によって識別される指定された開始時刻および
終了時刻を有するある期間にわたって、ＩＰアドレスに
よって識別されるソース機器と宛先機器との間で発生し
たデータ・ユーセージまたは消費の量に関連付けられ
る。 【００５９】図７、特に行７０６を参照すると、２００
１年１月１日、午前１２時から１２時１分の間に、ソー
スＩＰアドレス１０．１０．１０．２０と宛先ＩＰアド
レス１０．１０．１０．２８との間で１００２バイトが
使用された、すなわち通信されたことが分かる。また、
行７０９を参照すると、同一の２つのロケーションの間
で午前１２時１分から１２時２分の間のデータ・ユーセ
ージが１０００バイトであったことも分かる。行７０７
および７０８内に含まれるデータに関しても同様に観察
できる。 【００６０】好ましい実施形態では、図７に含まれるデ
ータは、ネットワークによる通信セッションに対する者
を正確に識別し、特定の開始時刻７０１および終了時刻
７０２を識別し、かかる通信セッション中に消費された
データを明確に提示している（ユーセージ列７０５）こ
とから、課金の目的のために容易に使用することができ
る。 【００６１】好ましくは、本発明のメカニズムは、図４
ないし図６において提供されたデータから、図７に入力
されている有用なデータを抽出する。例えば、図７の行
７０６のデータは、図４の行４０３と図５の行５０３と
から抽出できることが分かる。図４および図５に関連す
るタイムフィルタ値は、それぞれ午前１２時と午前１２
時１分であることが先に識別されている。図４の行４０
３と図５の行５０３のアドレス情報を検討することで、
図７の行７０６に同じＩＰアドレスが関係していること
が分かる。最後に、図５の行５０３と図４の行４０３に
入力された「値」の差を計算すると、6,608,000−6,60
6,998＝1002となり、この値が行７０６の「ユーセー
ジ」７０５に入力される。 【００６２】図８は、本発明の好ましい実施形態と共に
使用するために適合可能なコンピュータシステム８００
である。中央処理装置（ＣＰＵ）８０１がシステムバス
８０２に連結されている。ＣＰＵ８０１は、ヒューレッ
ト・パッカード社のＰＡ−８２００等の任意の汎用ＣＰ
Ｕであって良い。しかし、本発明は、ＣＰＵ８０１が本
明細書で説明したような本発明の動作をサポートする限
り、ＣＰＵ８０１のアーキテクチャによって限定されな
い。バス８０２は、ＳＲＡＭ、ＤＲＡＭまたはＳＤＲＡ
Ｍなどであるランダム・アクセス・メモリ（ＲＡＭ）８
０３に接続される。バス８０２には、ＰＲＯＭ、ＥＰＲ
ＯＭまたはＥＥＰＲＯＭなどであるＲＯＭ８０４もまた
連結される。ＲＡＭ８０３およびＲＯＭ８０４は、本技
術分野において周知であるようにユーザやシステムのデ
ータおよびプログラムを保持する。 【００６３】バス８０２はまた、好ましくは、入出力
（Ｉ／Ｏ）アダプタ８０５、通信アダプタカード８１
１、ユーザ・インタフェース・アダプタ８０８およびデ
ィスプレイ・アダプタ８０９に接続される。Ｉ／Ｏアダ
プタ８０５は、ハードドライブ、ＣＤドライブ、フレキ
シブルディスク・ドライブ、テープドライブのうちの１
つまたは複数である記憶装置８０６を、コンピュータシ
ステムに接続する。通信アダプタ８１１は、コンピュー
タシステム８００を、ローカル・エリア・ネットワーク
（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、イーサネッ
ト（登録商標）またはインターネット・ネットワークの
うちの１つまたは複数であるネットワークまたはインタ
ーネット８１２に連結するように適合される。ユーザ・
インタフェース・アダプタ８０８は、キーボード８１３
およびポインティングデバイス８０７等のユーザ入力装
置をコンピュータシステム８００に接続する。ディスプ
レイ・アダプタ８０９は、ＣＰＵ８０１によって駆動さ
れ、ディスプレイ装置８１０上の表示を制御する。 【００６４】本発明には例として以下の実施形態が含ま
れる。 【００６５】（１）顧客によるインターネット（１０
０）のユーセージを監視するステップと、前記監視され
たインターネット（１００）のユーセージ中に発生する
データ処理リソース消費情報を記録するステップと、定
義された期間内に記録された前記顧客によるデータ処理
リソース消費の量を求めるステップと、を含むインター
ネット・ユーセージを計量する方法。 【００６６】（２）前記監視するステップは、前記顧客
と前記インターネット（１００）との間の接続（３０
０）をポーリングするステップと、前記顧客による処理
リソース消費の総量を反映するデータを取得するステッ
プと、前記取得されたデータ処理リソース消費データを
絶対時間の量に関連付けるステップと、を含む上記(１)
に記載の方法。 【００６７】（３）前記記録するステップは、前記取得
されたデータ処理リソース消費データと前記関連付けら
れた絶対時間とを第１のテーブルに格納するステップを
含む、上記(２)に記載の方法。 【００６８】（４）前記求めるステップは、連続するポ
ーリングステップ間のデータ処理リソース消費の差を計
算するステップと、前記連続するポーリングステップ間
の絶対時間の差を計算するステップと、を含む上記(３)
に記載の方法。 【００６９】（５）前記連続するポーリングステップ間
のデータ処理リソース消費および絶対時間の前記計算さ
れた差を第２のテーブルに格納するステップをさらに含
む、上記(４)に記載の方法。 【００７０】（６）前記第２のテーブルはハッシュテー
ブル（３０４）を含む、上記(５)に記載の方法。 【００７１】（７）前記データ処理リソース消費の量を
求めるステップは、前記顧客によって受信されたデータ
の量を求めるステップを含む、上記(１)に記載の方法。 【００７２】（８）前記データ処理リソース消費の量を
求めるステップは、前記顧客によって伝送されたデータ
の量を求めるステップを含む、上記(１)に記載の方法。 【００７３】（９）前記データ処理リソース消費の量を
求めるステップは、前記定義された期間内に探索された
レコードの数を求めるステップを含む、上記(１)に記載
の方法。 【００７４】（１０）前記データ処理リソース消費の量
を求めるステップは、前記定義された期間内に伝送され
たメッセージの数を求めるステップを含む、上記(１)に
記載の方法。

【図面の簡単な説明】 【図１】本発明の好ましい実施形態による課金目的のイ
ンターネット・ユーセージ計量情報の使用を説明するブ
ロック図である。 【図２】本発明の好ましい実施形態による、プローブと
通信するインターネット・ユーセージ・マネージャの動
作コンポーネントの選択を示す図である。 【図３】本発明の好ましい実施形態による、顧客のネッ
トワーク・ユーセージを測定するハッシュテーブルの生
成を示すブロック図である。 【図４】本発明の好ましい実施形態によるインターネッ
ト・ユーセージ・アクティビティの第１のポーリング結
果に対応する例示的なエントリのテーブルである。 【図５】本発明の好ましい実施形態によるインターネッ
ト・ユーセージ・アクティビティの第２のポーリング結
果に対応する例示的なエントリのテーブルである。 【図６】本発明の好ましい実施形態によるインターネッ
ト・ユーセージ・アクティビティの第３のポーリング結
果に対応する例示的なエントリのテーブルである。 【図７】本発明の好ましい実施形態による、求められた
インターネット・ユーセージ・アクティビティの記録の
例示的な表を示す図である。 【図８】本発明の好ましい実施形態と共に使用するよう
に適合可能なコンピュータ装置を示す図である。 【符号の説明】 １００ インターネット １０１ インターネット・ユーセージ計量情報 １０２ 課金情報 １０３ サービス・プロバイダ・サイト ２００ インターネット・ユーセージ・マネージャ ３００ 顧客ＩＰ接続

Claims (1)

1. 【特許請求の範囲】 【請求項１】顧客によるインターネット・ユーセージを
   監視するステップと、 前記監視されたインターネット・ユーセージ中に発生す
   るデータ処理リソース消費情報を記録するステップと、 定義された期間内に記録された前記顧客によるデータ処
   理リソース消費の量を求めるステップと、 を含む方法。