JP2018501685A

JP2018501685A - オフライン課金システムにおける削減された部分的ｃｄｒの取り扱い

Info

Publication number: JP2018501685A
Application number: JP2017523255A
Authority: JP
Inventors: シャルマ，ランジャン; カイ，イガン
Original assignee: アルカテル−ルーセント
Priority date: 2014-10-31
Filing date: 2015-10-27
Publication date: 2018-01-18
Anticipated expiration: 2035-10-27
Also published as: US9538016B2; KR101951621B1; CN107078916A; KR20170063910A; US20160127563A1; CN107078916B; JP6479978B2; EP3213542B1; EP3213542A1; WO2016069513A1

Abstract

本発明は、セッションについての部分的課金データ・レコード（ＣＤＲ）を取り扱うシステムおよび方法に関する。オフライン課金システムは、課金ゲートウェイ機能（ＣＧＦ）のクラスタを含んでいる。クラスタのうちの第１のＣＧＦは、セッションについての第１の完全に資格要件を満たした部分的ＣＤＲ（ＦＱＰＣ）を受信し、クラスタの中のＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールに、第１のＦＱＰＣに基づいて、ＦＱＰＣデータを記憶する。クラスタのうちの第２のＣＧＦは、第１のＣＧＦの失敗に応答して、セッションについての削減された部分的ＣＤＲ（ＲＰＣ）を受信し、中央集中されたストレージ・モジュールからＦＱＰＣデータを取り出し、ＲＰＣと、中央集中されたストレージ・モジュールから取り出されたＦＱＰＣデータとに基づいて、セッションについての第２のＦＱＰＣを生成する。

Description

本開示は、通信システムの分野に関し、詳細にはオフライン課金に関する。

サービス・プロバイダは、一般的に、エンド・ユーザ（加入者と称されることもある）に対して非常に多数の音声サービスと、データ・サービスとを提供する。音声サービスの例は、音声コール、コール転送、コール・ウェイティングなどである。データ・サービスの例は、ストリーミング・オーディオ、ストリーミング・ビデオ、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ：ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、オンライン・ゲーム、およびＩＰ−ＴＶである。データ・サービスは、パケット交換（ＰＳ：ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ）コア・ネットワークによって管理され、このＰＳコア・ネットワークは、インターネットなど、外部のパケット・データ・ネットワーク（ＰＤＮ：ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋｓ）とエンド・ユーザをインターフェースする。ＰＳ−コア・ネットワークのいくつかの例は、汎用パケット無線サービス（ＧＰＲＳ：ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）コア・ネットワーク、ロング・ターム・エボリューション（ＬＴＥ：ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）ネットワークの進化型パケット・コア（ＥＰＣ：ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）などである。セル電話、パーソナル・データ・アシスタント、スマートフォン、ノートブック・コンピュータなどのモバイル・デバイスは、１つまたは複数の基地局とのエア・インターフェースを通じて、ネットワークによって提供されるデータ・サービスにアクセスすることができる。

サービス・プロバイダは、オフライン課金機能およびオンライン課金機能を使用して、様々なサービスを使用するために各デバイスによって消費されるリソースの使用状況を追跡する。３ＧＰＰ／３ＧＰＰ２標準グループは、様々なネットワーク・ドメイン（例えば、回路交換ドメイン、パケット交換ドメイン、および／またはワイヤレス・ドメイン）におけるオンライン課金システムおよびオフライン課金システムと、ＩＰマルチメディア・サブシステム（ＩＭＳ：ＩＰｍｕｌｔｉｍｅｄｉａｓｕｂｓｙｓｔｅｍｓ）と、新たに出現している３Ｇ／ＯＭＡアプリケーション・サービスとを実装するために使用され得る仕様のセットを規定している。

３ＧＰＰＴＳ３２．２４０仕様によれば、オフライン課金は、ネットワーク・リソース使用についての課金情報がリソース使用と同時に収集されるプロセスである。課金情報は、課金機能のチェーンを通して渡され、この課金機能のチェーンは、加入者課金および／またはオペレータ間アカウンティングのためのネットワーク・オペレータの課金ドメインに対して転送される課金データ・レコード（ＣＤＲ：ＣｈａｒｇｉｎｇＤａｔａＲｅｃｏｒｄ）の生成をもたらす。オフライン課金を実装するために、課金トリガ機能（ＣＴＦ：ＣｈａｒｇｉｎｇＴｒｉｇｇｅｒＦｕｎｃｔｉｏｎ）が、サービスを提供するネットワーク要素の中に実装される。ＣＴＦは、課金可能イベントに関連する情報を収集し、この情報を一致する課金イベントへとアセンブルし、それらの課金イベントを課金データ機能（ＣＤＦ：ＣｈａｒｇｉｎｇＤａｔａＦｕｎｃｔｉｏｎ）に対して送信し、この課金データ機能（ＣＤＦ）は、ネットワーク要素の中に実装されることも、またはオフライン課金システム（ＯＦＣＳ：ＯｆｆｌｉｎｅＣｈａｒｇｉｎｇＳｙｓｔｅｍ）の中に実装されることもある。

ＣＤＦは、１つまたは複数のＣＴＦから課金イベントを受信し、また課金イベントの中に含まれる情報を使用してＣＤＲを構築する。ＣＤＲは、課金とアカウンティングとにおける使用のための、課金イベントについての情報（例えば、コール・セットアップの時間、コールの持続時間、転送されるデータの量など）のフォーマットされた集まりである。次いで、ＣＤＦは、ＯＦＣＳの課金ゲートウェイ機能（ＣＧＦ：ＣｈａｒｇｉｎｇＧａｔｅｗａｙＦｕｎｃｔｉｏｎ）に対してＣＤＲを送信する。ＣＧＦは、ネットワークと、課金ドメインとの間のゲートウェイとしての役割を果たす。それゆえに、ＣＧＦは、ＣＤＦ（および他のＣＤＦ）からＣＤＲを収集し、場合によってはＣＤＲを相互に関連づけ、ＣＤＲをＣＤＲファイルの中に書き込み、ＣＤＲファイルを課金ドメインに対して使用可能にする。

３ＧＰＰＴＳ３２．２４０仕様は、ＣＤＦと、ＣＧＦとの間の完全に資格要件を満たした部分的ＣＤＲ（ＦＱＰＣ：ＦｕｌｌｙＱｕａｌｉｆｉｅｄＰａｒｔｉａｌＣＤＲ）と、削減された部分的ＣＤＲ（ＲＰＣ：ＲｅｄｕｃｅｄＰａｒｔｉａｌＣＤＲ）とについてのサポートを提供する。ＦＱＰＣは、ＣＤＲタイプについて指定される完全な１組のフィールドを含んでいる部分的ＣＤＲである。これは、すべての強制的フィールド、および条件付きフィールド、ならびに、ＣＤＲの中に含まれるようにネットワーク・オペレータがプロビジョニングしてきているこれらのフィールドを含む。ＲＰＣは、強制的フィールドと、以前の部分的ＣＤＲに対するセッション・パラメータの変化に関する情報とだけを提供する部分的ＣＤＲである。一例として、ＣＤＦからＣＧＦへと送信される第１の部分的ＣＤＲは、すべての必要なフィールドを含むＦＱＰＣである。このＦＱＰＣは、同じセッションのためにＣＧＦによって後で受信されるＲＰＣ内で失われた情報を提供するための基礎としての役割を果たす。セッションについての情報が変化していない場合、そのときにはＣＧＦは、ＣＤＦからＲＰＣを受信することができる。ＲＰＣを受信するとすぐに、ＣＧＦは、それが同じセッションのために受信した先行ＦＱＰＣに基づいて、ＲＰＣから別のＦＱＰＣを構築することができる。

３ＧＰＰＴＳ３２．２４０仕様３ＧＰＰ規格ＡＶＰコード８４１

本明細書において説明される実施形態は、オフライン課金システムの内部でＲＰＣを取り扱うやり方を提供する。ＣＧＦが、セッションについてのＦＱＰＣを受信すると、ＣＧＦは、オフライン課金システムの内部のＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールにＦＱＰＣについてのデータ（例えば、コピー）を記憶する。中央集中されたストレージ・モジュールに記憶されるＦＱＰＣデータは、セッションについてのＦＱＰＣを最初に受信することなく、セッションについてのＲＰＣを受信する任意のＣＧＦについての参照データとしての役割を果たす。例えば、セッションについての部分的ＣＤＲを取り扱う一次的ＣＧＦの失敗がある場合、そのときには、ＲＰＣは、二次的ＣＧＦに対してルーティングされる可能性がある。しかしながら、二次的ＣＧＦは、このセッションについてＦＱＰＣを以前に受信してはいなかった。このようなシナリオが起こるときに、第２のＣＧＦは、中央集中されたストレージ・モジュールからＦＱＰＣデータをフェッチし、ＦＱＰＣデータとＲＰＣデータとを使用して、セッションについての別のＦＱＰＣを構築することができる。それゆえに、ＲＰＣは、中央集中されたストレージ・モジュールに記憶されたデータに基づいて、ＦＱＰＣへと再構築することができる。

一実施形態は、少なくとも１つのハードウェア・プラットフォーム上に実装された課金ゲートウェイ機能（ＣＧＦ：ＣｈａｒｇｉｎｇＧａｔｅｗａｙＦｕｃｔｉｏｎｓ）のクラスタを含むオフライン課金システムを備えている。クラスタのうちの第１のＣＧＦは、セッションについての第１のＦＱＰＣを受信し、第１のＦＱＰＣからのＦＱＰＣデータを、クラスタの中のＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールに記憶するように構成されている。クラスタのうちの第２のＣＧＦは、第１のＣＧＦの失敗に応答して、セッションについてのＲＰＣを受信し、中央集中されたストレージ・モジュールからＦＱＰＣデータを取り出し、ＲＰＣと、中央集中されたストレージ・モジュールから取り出されたＦＱＰＣデータとに基づいて、セッションについての第２のＦＱＰＣを生成するように構成されている。

別の実施形態においては、第１のＣＧＦは、ＦＱＰＣデータをオブジェクトとして、中央集中されたストレージ・モジュールに記憶し、セッションに割り当てられた課金ＩＤに基づいて、オブジェクトに対して名前を割り当てるように構成されている。

別の実施形態においては、第２のＣＧＦは、ＲＰＣからセッションについての課金ＩＤを抽出し、課金ＩＤに基づいて、ＦＱＰＣデータについてのオブジェクトの名前を導き出し、オブジェクトの名前に基づいて、中央集中されたストレージ・モジュールからＦＱＰＣデータについてのオブジェクトを取り出すように構成されている。

別の実施形態においては、第２のＣＧＦは、セッションについての第３のＦＱＰＣを受信し、第３のＦＱＰＣに基づいて、中央集中されたストレージ・モジュールの中のＦＱＰＣデータをアップデートするように構成されている。

別の実施形態においては、第２のＣＧＦは、セッションの終了を識別し、セッションの終了に応答して中央集中されたストレージ・モジュールからＦＱＰＣデータを削除するように構成されている。

別の実施形態においては、中央集中されたストレージ・モジュールは、クラウド・ストレージを備えている。

別の実施形態においては、オフライン課金システムは、ＣＧＦのクラスタと、課金データ機能（ＣＤＦ）のクラスタとの間に接続されたバック・エンド・ディストリビュータを含んでいる。バック・エンド・ディストリビュータは、ＣＤＦのクラスタからＣＧＦのクラスタへと部分的ＣＤＲを配信するように構成されている。

別の実施形態においては、第２のＣＧＦが、セッションについての先行ＦＱＰＣを受信した場合、そのときには第２のＣＧＦは、ローカル・メモリから先行ＦＱＰＣを取り出し、ＲＰＣと、ローカル・メモリから取り出された先行ＦＱＰＣとに基づいて、セッションについての第２のＦＱＰＣを生成するように構成されている。

別の実施形態は、ＣＧＦのクラスタを備えたオフライン課金システムを動作させる方法を含んでいる。本方法は、クラスタのうちの第１のＣＧＦにおいて、セッションについての第１のＦＱＰＣを受信するステップと、第１のＦＱＰＣからのＦＱＰＣデータを、クラスタの中のＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールに記憶するステップとを含む。本方法は、第１のＣＧＦの失敗に応答して、クラスタの第２のＣＧＦにおいて、セッションについてのＲＰＣを受信するステップと、中央集中されたストレージ・モジュールからＦＱＰＣデータを取り出すステップと、ＲＰＣと、中央集中されたストレージ・モジュールから取り出されたＦＱＰＣデータとに基づいて、第２のＣＧＦにおいてセッションについての第２のＦＱＰＣを生成するステップとをさらに含む。

別の実施形態は、ＣＧＦのクラスタを含むオフライン課金システムを備えている。クラスタのうちのＣＧＦは、セッションについての部分的ＣＤＲを受信し、部分的ＣＤＲがＦＱＰＣを含んでいるか、またはＲＰＣを含んでいるかを決定するように構成されている。部分的ＣＤＲがＦＱＰＣを含んでいるとき、ＣＧＦは、クラスタの中のＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールにＦＱＰＣからのＦＱＰＣデータを記憶するように構成されている。部分的ＣＤＲがＲＰＣを含んでいるとき、ＣＧＦは、先行ＦＱＰＣがＣＧＦにおいてセッションについて受信されたかどうかを決定し、先行ＦＱＰＣがＣＧＦにおいて受信されなかったという決定に応答して、中央集中されたストレージ・モジュールからＦＱＰＣデータを取り出し、ＲＰＣと、中央集中されたストレージ・モジュールから取り出されたＦＱＰＣデータとに基づいて、セッションについての第２のＦＱＰＣを生成するように構成されている。

別の実施形態においては、部分的ＣＤＲがＲＰＣを含んでいるときに、ＣＧＦは、先行ＦＱＰＣがＣＧＦにおいて受信されたという決定に応答して、ローカル・メモリからＦＱＰＣデータを取り出し、ＲＰＣと、ローカル・メモリから取り出されたＦＱＰＣデータとに基づいて、セッションについての第２のＦＱＰＣを生成するように構成されている。

上記の概要は、本明細書のいくつかの態様についての基本的理解を提供している。この概要は、本明細書の広範囲に及ぶ概説ではない。本明細書の重要な要素または不可欠な要素を識別することも、本明細書の特定の実施形態のどのような範囲、または特許請求の範囲のどのような範囲も示すことも、意図してはいない。その唯一の目的は、後で提示されるより詳細な説明に対する前置きとして、簡略化された形式で本明細書のいくつかの概念を提示することである。

本開示についてのいくつかの実施形態が、次に、例だけとして、添付の図面を参照して説明される。同じ参照番号は、すべての図面において、同じ要素または同じタイプの要素を表している。

例示の一実施形態におけるオフライン課金アーキテクチャを示す図である。例示の一実施形態における、ＣＧＦクラスタ内でＲＰＣを取り扱う方法を示すフロー・チャートである。例示の一実施形態におけるＲＰＣの取り扱いを示す流れ図である。

図面および以下の説明は、特定の例示の実施形態を示すものである。したがって、当業者なら、本明細書において明示的に説明されても、または示されてもいないが、実施形態の原理を実施し、また実施形態の範囲内に含まれる様々な構成を考案することができるようになることが、正しく理解されるであろう。さらに、本明細書において説明されるどのような例も、本実施形態についての原理を理解する際に、助けとなることを意図しており、またそのように具体的に列挙された例および状態だけに限定することのないように解釈されるべきである。結果として、本発明の概念は、以下で説明される特定の実施形態または例だけには限定されないが、特許請求の範囲とそれらの均等物とによって限定される。

それ以外の方法で示されていない限り、用語「第１の」、「第２の」などは、本明細書において単に標識として使用されており、またこれらの用語が言及している項目に対する順序の要件、位置の要件、または階層の要件を課すことを意図してはいない。

図１は、例示の一実施形態におけるオフライン課金アーキテクチャ１００を示すものである。アーキテクチャ１００は、その加入者（すなわち、エンド・ユーザおよび関連するユーザ機器（ＵＥ：ＵｓｅｒＥｑｕｉｐｍｅｎｔ））に対してサービスを提供して、加入者についてのオフライン課金を提供する回路交換ネットワークまたはパケット交換ネットワークの形で実装されることもある。いくつかの例示のネットワークは、ＩＰマルチメディア・サブシステム（ＩＭＳ：ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）ネットワーク、ロング・ターム・エボリューション（ＬＴＥ）ネットワーク、汎用パケット無線サービス（ＧＰＲＳ）などを含む。

アーキテクチャ１００は、フロント・エンド・ディストリビュータ１１０を通してオフライン課金システム（ＯＦＣＳ）１２０に接続するネットワーク要素１０２を含んでいる。ネットワーク要素１０２は、ネットワークによって提供されるサービスの提供において使用される装置または機器である。例えば、ネットワーク要素は、ＩＭＳネットワークのサービング・コール・セッション制御機能（Ｓ−ＣＳＣＦ：Ｓｅｒｖｉｎｇ−ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）またはアプリケーション・サーバ（ＡＳ：ａｐｐｌｉｃａｔｉｏｎｓｅｒｖｅｒ）、ＬＴＥネットワークのサービング・ゲートウェイ（ＳＧＷ：ＳｅｒｖｉｎｇＧａｔｅｗａｙ）またはパケット・データ・ネットワーク・ゲートウェイ（ＰＧＷ：ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ）などを備えることができる。ネットワーク要素１０２は、ネットワーク要素１０２によって提供されるサービスについての課金可能イベントを検出し、課金可能イベントについての情報を一致する課金イベントへとアセンブルし、それらの課金イベントを課金データ機能（ＣＤＦ）に対して送信する課金トリガ機能（ＣＴＦ）１０４を含んでいる。ネットワーク要素１０２の場合には、ＣＴＦ１０４は、ダイアメーターＲｆインターフェースを使用する。それゆえに、ＣＴＦ１０４は、課金情報をダイアメーターＲｆのアカウンティング要求（ＡＣＲ）などのアカウンティング要求へとアセンブルする。１つのＣＴＦ１０４が図１に示されるが、フロント・エンド・ディストリビュータ１１０に接触する複数のＣＴＦが存在する可能性がある。

ＯＦＣＳ１２０は、ネットワークによって提供されるセッションまたはサービスについてのオフライン課金を実装するように構成された装置、サーバ、デバイス、または機器である。オフライン課金は、２つのタイプ、すなわち、セッション・ベース、またはイベント・ベースのものとすることができる。イベント・ベースの課金においては、ＣＴＦは、提供される使用またはサービスを報告し、ここでは、サービスの提供は、加入者登録、再登録、登録解除などの１回のオペレーションの形で提供される。ＣＴＦは、ＡＣＲイベント（ＡＣＲＥＶＥＮＴ）の形で、使用を報告する。セッション・ベースの課金は、セッションについての使用レポートを報告するプロセスであり、また開始（ＳＴＡＲＴ）アカウンティング・データと、中間（ＩＮＴＥＲＩＭ）アカウンティング・データと、終了（ＳＴＯＰ）アカウンティング・データとを使用する。セッション中に、ＣＴＦ１０４は、セッションの手順に応じて複数のＡＣＲ中間を送信することができる。

この実施形態においては、ＯＦＣＳ１２０は、複数のＣＤＦ（ＣＤＦ１〜ＣＤＦｎ）１２２〜１２５を備えているＣＤＦクラスタ１２１を含んでいる。ＣＤＦは、ネットワーク要素の内部のＣＴＦから課金イベントを受信し、それらの課金イベントをＣＤＲへとフォーマットし、そのＣＤＲをＣＧＦに対して送信する、ＯＦＣＳ１２０の内部の要素またはモジュールを備えている。ＯＦＣＳ１２０はまた、複数のＣＧＦ（ＣＧＦ１〜ＣＧＦｎ）１３２〜１３５を備えているＣＧＦクラスタ１３１と、中央集中されたストレージ・モジュール１３８とを含む。ＣＧＦは、セッションについてのＣＤＲを相互に関連づけ、また相互に関連づけられたＣＤＲを有するＣＤＲファイルを課金ドメイン１４０に対して転送するＯＦＣＳ１２０の内部の要素またはモジュールを備えている。中央集中されたストレージ・モジュール１３８は、ＣＧＦクラスタ１３１の中の各ＣＧＦ１３２〜１３５によってアクセス可能である任意のストレージ・デバイスを備えている。例えば、中央集中されたストレージ・モジュール１３８は、一実施形態におけるＣＧＦクラスタ１３１と同じプラットフォーム上にストレージ・アレイを備えることができる。別の実施形態においては、中央集中されたストレージ・モジュール１３８は、ネットワーク（図示されず）を通してアクセス可能なクラウド・ストレージを備えていることができる。ストレージ・モジュール１３８は、それが、ＣＧＦクラスタ１３１の中の各ＣＧＦ１３２〜１３５によってアクセス可能であるので、「中央集中される」ものと考えられる。

ＯＦＣＳ１２０におけるＣＤＦは、ダイアメーターＧａインターフェースの上でＣＧＦと通信する。図１に示される場合には、ＧＴＰ’をＧａインターフェースで使用して、ＣＤＦからＣＧＦへとＣＤＲを移送する。図１には具体的に示されてはいないが、ＯＦＣＳ１２０は、ＣＤＦ１２２〜１２５と、ＣＧＦ１３２〜１３５とを実装する１つまたは複数のプロセッサ、または他のハードウェア・プラットフォームを含むことができる。

課金ドメイン１４０は、課金調停アプリケーションと、他の課金アプリケーション（例えば、統計的アプリケーション）とについてのＣＤＲファイルを受信および処理するオペレータ・ネットワークの一部分である。

フロント・エンド・ディストリビュータ１１０は、ＣＴＦ（例えば、ＣＴＦ１０４）と、ＯＦＣＳ１２０の中のＣＤＦ１２２〜１２５との間に実装される。フロント・エンド・ディストリビュータ１１０の目的は、ＣＴＦからＯＦＣＳ１２０の内部の複数のＣＤＦ１２２〜１２５へと、ダイアメーター要求、またはアカウンティング要求（例えば、ＡＣＲ）を配信することである。

バック・エンド・ディストリビュータ１１５は、ＯＦＣＳ１２０の中のＣＤＦ１２２〜１２５と、ＣＧＦ１３２〜１３５との間に実装される。バック・エンド・ディストリビュータ１１５の目的は、ＣＤＦ１２２〜１２５からＣＧＦ１３２〜１３５へとＣＤＲを配信することである。

ディストリビュータを使用することは、オペレータのプロビジョニング・タスクを容易にし、システムが範囲を超えるときには、プロビジョニング・アクティビティは、ディストリビュータにおける新しいシステム（またはサブシステム）の識別の包含に対して最適化される。したがって、自動スケーリング・シナリオにおいては、ＣＤＦがネットワーク・トポロジに追加されるときに、フロント・エンド・ディストリビュータ１１０は、その情報を用いてアップデートされる。同様に、ＣＧＦが追加されるときには、バック・エンド・ディストリビュータ１１５がアップデートされる。ディストリビュータは、オフライン課金処理チェーンにおいてあるレベルの分離を提供する。しかしながら、これは、ＣＤＦが、ＣＧＦフェイルオーバーを認識しないようにしており、これは、ＣＤＦが送信しようとしている部分的ＣＤＲが、完全に資格要件を満たした部分的ＣＤＲ（ＦＱＰＣ）であるべきか、または削減された部分的ＣＤＲ（ＲＰＣ）であるべきかを決定する際のステップである。

以下の実施形態は、ＯＦＣＳ１２０の内部で生成される部分的ＣＤＲを取り扱う新しいやり方を示すものである。概説として、ＦＱＰＣが、あるセッションについて生成され、またＣＧＦクラスタ１３１の中のＣＧＦにルーティングされるときに、ＣＧＦは、中央集中されたストレージ・モジュール１３８にＦＱＰＣのコピーを記憶する。このＦＱＰＣは、ＣＧＦクラスタ１３１の中の任意のＣＧＦ１３２〜１３５によってアクセス可能であり、その結果、ＣＧＦは、セッションについてのＣＤＲタイプのために指定される完全な１組のフィールドを識別することができる。ＣＧＦクラスタ１３１の中のＣＧＦが、セッションについて選択された別のＣＧＦの失敗があるときなど、ＦＱＰＣを最初に受信することなしに、セッションについてのＲＰＣをたまたま受信する場合には、ＲＰＣを受信するＣＧＦは、中央集中されたストレージ・モジュール１３８に問い合わせて、セッションについて記憶されているＦＱＰＣに関するデータを取り出すことができる。ＣＧＦは、ＲＰＣと一緒にセッションについてのＦＱＰＣを処理して、セッションについての別のＦＱＰＣを生成することができる。それゆえに、たとえＣＧＦが、セッションについてＦＱＰＣを最初に受信することなしにＲＰＣを受信するとしても、ＣＧＦは、中央集中されたストレージ・モジュール１３８からＦＱＰＣについて必要とされるフィールドを取り出すことができ、その結果、それは、セッションについてのＦＱＰＣを生成することもできる。セッション中にＣＧＦの失敗があるときに、フェイルオーバーのＣＧＦは、中央集中されたストレージ・モジュール１３８に問い合わせを行うことにより、セッションについてのＦＱＰＣを生成することができる。この新しい方法は、ＣＧＦのフェイルオーバーについて知り、またそのようなフェイルオーバーのすぐ後にＦＱＰＣがＲＰＣの代わりに送信されるべきかどうかを決定する必要性を緩和する。

オフライン課金を示すために、図１におけるＣＴＦ１０４は、ネットワーク要素１０２によって提供されるサービスについての課金可能イベントを検出し、またＣＴＦ１０４は、課金可能イベントについての情報をアカウンティング要求へとアセンブルする。アカウンティング要求は、セッション識別子（ＩＤ）によって参照されるセッションについてのものである。フロント・エンド・ディストリビュータ１１０は、セッションについてのＣＴＦ１０４からアカウンティング要求を受信し、また配信アルゴリズム、ルックアップ・テーブルなどに基づいて、アカウンティング要求についての宛先ＣＤＦ（例えば、ＣＤＦ１２２〜１２５のうちの１つ）を選択する。次いで、フロント・エンド・ディストリビュータ１１０は、選択されたＣＤＦ（例えば、ＣＤＦ１２２）に対してアカウンティング要求をルーティングする。

ＣＤＦ１２２は、アカウンティング要求を処理して、セッションについてのＣＤＲをオープンするかまたはアップデートする。例えば、アカウンティング要求が、セッションの開始のための「開始」メッセージである場合、そのときにはＣＤＦ１２２は、開始メッセージに基づいて、セッションについてのＣＤＲをオープンすることができる。アカウンティング要求が、セッション中の「中間」メッセージである場合、そのときにはＣＤＦ１２２は、中間メッセージに基づいて、セッションについてのＣＤＲ（既にオープンされた）をアップデートすることができる。

ＣＤＦ１２２がセッションの終了の前にＣＤＲを閉じる事例が存在する可能性があり、これは、部分的ＣＤＲと称される。例えば、ＣＤＦ１２２がＣＤＲを最初にオープンするときに、セッションの終了を示す「終了」メッセージが受信されなければ、ＣＤＦ１２２は、ＣＤＲを閉じるためにタイマーを設定することができる。ＣＤＦ１２２が、タイマーの期限切れの前に終了メッセージを受信する場合、そのときにはＣＤＦ１２２は、セッションが完全なＣＤＲを生成するように、ＣＤＲを閉じる。ＣＤＦ１２２が、タイマーの期限切れの前に終了メッセージを受信しない場合、そのときにはＣＤＦ１２２は、ＣＤＲを閉じて、セッションについての部分的ＣＤＲを生成する。またＣＤＦ１２２が、セッション、またはオフライン課金について規定される変更条件のどれかについてのサービスまたは媒体の変更を示すアカウンティング要求を受信する場合、そのときにはＣＤＦ１２２は、ＣＤＲを閉じて、セッションについての部分的ＣＤＲを生成することができる。部分的ＣＤＲは、セッションの一部分についての課金情報を提供するＣＤＲのタイプである。長い持続時間のセッションが、複数の部分的ＣＤＲによってカバーされることもある。部分的ＣＤＲについての２つのフォーマット、すなわち、必要なフィールドのすべてを含むＦＱＰＣと、削減されたフォーマットを有しているＲＰＣと、が存在している。ＣＤＦ１２２は、部分的ＣＤＲをバック・エンド・ディストリビュータ１１５に対して転送する。

１つまたは複数のＣＤＦ１２２〜１２５は、同じように動作して、セッション（または他のセッション）についての部分的ＣＤＲを生成することができる。ＣＤＦが部分的ＣＤＲを生成するたびに、それは、Ｇａ参照点の上などで、バック・エンド・ディストリビュータ１１５に対して部分的ＣＤＲを転送する。バック・エンド・ディストリビュータ１１５は、セッションについての部分的ＣＤＲを受信し、また配信アルゴリズム、ルックアップ・テーブルなどに基づいて、部分的ＣＤＲについての宛先ＣＧＦ（例えば、ＣＧＦ１３２〜１３５のうちの１つ）を選択する。次いで、バック・エンド・ディストリビュータ１１５は、選択されたＣＧＦ（例えば、ＣＧＦ１３２）に対して部分的ＣＤＲをルーティングする。以下の実施形態は、ＣＧＦクラスタ１３１の中のＣＧＦが、どのようにして部分的ＣＤＲを取り扱うかを説明している。

図２は、例示の一実施形態におけるＣＧＦクラスタ１３１においてＲＰＣを取り扱う方法２００を示すフロー・チャートである。方法２００のステップは、図１におけるＯＦＣＳ１２０を参照して説明されるが、当業者なら、方法２００が他のシステムにおいても実行され得ることを正しく理解するであろう。また、本明細書において説明されるフロー・チャートのステップは、必ずしもすべてを含んだものではなく、示されていない他のステップを含むことができ、またそれらのステップは、代替的な順序で実行されることもある。

ＣＧＦクラスタ１３１のうちのＣＧＦは、バック・エンド・ディストリビュータ１１５（ステップ２０２）からセッションについての部分的ＣＤＲを受信する。この実施形態について、ＣＧＦ１３２がバック・エンド・ディストリビュータ１１５から部分的ＣＤＲを受信することが仮定される。部分的ＣＤＲを受信するのに応答して、ＣＧＦ１３２は、部分的ＣＤＲが、ＦＱＰＣであるか、またはＲＰＣであるかを決定する（ステップ２０４）。部分的ＣＤＲがＦＱＰＣであるとき、ＣＧＦ１３２は、中央集中されたストレージ・モジュール１３８に、ＦＱＰＣについてのＦＱＰＣデータ（例えば、コピー）を記憶する（ステップ２０６）。ＣＧＦ１３２は、中央集中されたストレージ・モジュール１３８に、ＦＱＰＣの任意の望ましいパラメータを記憶することができる。望ましいパラメータは、ＣＤＲタイプについて指定される完全な１組のフィールドとすることができる。ＣＧＦ１３２は、ローカル・メモリにＦＱＰＣのコピーを記憶することもできる。中央集中されたストレージ・モジュール１３８にＦＱＰＣを記憶するとき、それは、ＦＱＰＣが中央集中されたストレージ・モジュール１３８に記憶された最初の事例であるか、または中央集中されたストレージ・モジュール１３８に既に記憶されたＦＱＰＣに対するアップデートである可能性がある。ＦＱＰＣが中央集中されたストレージ・モジュール１３８に最初に記憶されるときに、ＣＧＦは、ＦＱＰＣについて中央集中されたストレージ・モジュール１３８の中にオブジェクトを作成し、またＦＱＰＣまたはＦＱＰＣに関連するデータをオブジェクトに記憶する。ＣＧＦが、セッションについてのＦＱＰＣを受信するが、オブジェクトが、中央集中されたストレージ・モジュール１３８の中に既に作成されている場合、そのときにはＣＧＦは、ＦＱＰＣについての新しいデータでオブジェクトをアップデートする。

バック・エンド・ディストリビュータ１１５から受信される部分的ＣＤＲがＲＰＣであるときに、ＣＧＦ１３２は、先行ＦＱＰＣが、セッションについて受信されたかどうかを決定する（ステップ２０８）。ＣＧＦ１３２が、セッションについての先行ＦＱＰＣを受信した場合、そのときにはＣＧＦ１３２は、ローカル・メモリに記憶された先行ＦＱＰＣを有するであろう。しかし、ＣＧＦ１３２が、ＦＱＰＣを最初に受信することなしにＲＰＣを受信することができる事例が存在する可能性がある。例えば、別のＣＧＦ（例えば、ＣＧＦ１３３）が、セッションについて以前に選択されたが、セッションが終了する前にサービス停止（ＯＯＳ：ＯｕｔＯｆＳｅｒｖｉｃｅ）になった場合、そのときにはＣＧＦ１３２は、最初にＦＱＰＣを受信することなしに、ＲＰＣを受信することができる。バック・エンド・ディストリビュータ１１５は、ＣＤＦクラスタ１２１と、ＣＤＦクラスタ１３１との間に設置されるので、ＣＤＦ１２２〜１２５は、ＣＧＦ１３２〜１３５のステータスを知らない。それゆえに、ＣＤＦは、セッションについてのＦＱＰＣまたはＲＰＣを生成するときに、ＣＧＦ１３２〜１３５のステータスを考慮することはない。たとえＣＧＦクラスタ１３１の中のＣＧＦが、セッション中にＯＯＳになるとしても、ＣＤＦクラスタ１２１の中のＣＤＦは、ＲＰＣが完全な１組のフィールドを有していないにもかかわらず、バック・エンド・ディストリビュータ１１５に対してＲＰＣを依然として送信することができる。

ＣＧＦ１３２が、ＲＰＣの前に先行ＦＱＰＣを受信した場合、そのときにはＣＧＦ１３２は、ローカル・メモリにアクセスして、セッションについてのＦＱＰＣデータを取り出す（ステップ２１０）。次いで、ＣＧＦ１３２は、ＲＰＣとローカル・メモリから取り出されたＦＱＰＣデータとに基づいて、セッションについての別のＦＱＰＣを生成する（ステップ２１２）。ある時点において、ＣＤＦ１３２は、ＣＤＲ（ＦＱＰＣを含む）を相互に関連づけ、ＣＤＲをＣＤＲファイルの中に書き込み、またＣＤＲファイルを課金ドメイン１４０に対して使用可能にする。

ＣＧＦ１３２が、ＲＰＣの前に先行ＦＱＰＣを受信しなかった場合、そのときにはＣＧＦ１３２は、中央集中されたストレージ・モジュール１３８にアクセスして、セッションについてのＦＱＰＣデータを取り出す（ステップ２１４）。ＣＧＦ１３２は、セッションについての先行ＦＱＰＣを受信しなかったので、ＣＧＦ１３２は、中央集中されたストレージ・モジュール１３８から先行ＦＱＰＣのコピーをフェッチすることができる。中央集中されたストレージ・モジュール１３８は、クラスタ１３１の中の各ＣＧＦ１３２〜１３５によってアクセス可能であるセッションについてのＦＱＰＣについての中央集中されたリポジトリとしての役割を果たす。次いで、ＣＧＦ１３２は、ＲＰＣと中央集中されたストレージ・モジュール１３８から取り出されたＦＱＰＣデータとに基づいて、セッションについての別のＦＱＰＣを生成する（ステップ２１２）。

方法２００は、ＣＧＦクラスタ１３１の内部でＲＰＣを取り扱う、より堅牢な方法を提供する。セッションについて選択された一次的ＣＧＦがＯＯＳになり、またＲＰＣが、セッションについて以前にＦＱＰＣを受信しなかった二次的ＣＧＦに対してルーティングされる場合／ときに、二次的ＣＧＦは、中央集中されたストレージ・モジュール１３８にアクセスして、先行ＦＱＰＣを取り出すことができ、その結果、ＣＧＦは、ＲＰＣの中で提供されていないＣＤＲについての必要なフィールドを識別することができる。次いで、二次的ＣＧＦは、先行ＦＱＰＣからのデータと、ＲＰＣからのデータとに基づいて、ＦＱＰＣをアセンブルすることができる。それゆえに、セッションについての課金は、一次的ＣＧＦがＯＯＳになるにもかかわらず、有効なやり方で取り扱われる可能性がある。

例
以下は、図１において示されるような、オフライン課金アーキテクチャの内部でＲＰＣを取り扱う一例を提供している。図３は、例示の一実施形態におけるＲＰＣの取り扱いを示す流れ図である。初めに、進行中のセッションが存在していることが仮定される。セッションは、値「ＳＴＡＳ：１３５．２５１．８５．１９７−４ｂｂ３ｆ３２ｆ−０００００４ａｂ」を有する、ＩＭＳ課金識別子（ＩＣＩＤ（ＩＭＳＣｈａｒｇｉｎｇＩｄｅｎｔｉｆｉｅｒ）、３ＧＰＰ規格ＡＶＰコード８４１）などの課金ＩＤによって識別される。所与のセッションに関して、課金ＩＤは、規格が指定するように不変にとどまるであろう。このセッションでは、ＣＤＦ１２２は、セッションについての部分的ＣＤＲをトリガし、この部分的ＣＤＲは、セッションについての第１のＦＱＰＣ（ＦＱＰＣ１）である。次いで、ＣＤＦ１２２は、バック・エンド・ディストリビュータ１１５に対してＦＱＰＣを送信する。バック・エンド・ディストリビュータ１１５は、ＣＧＦ１３２を選択して、ＣＤＲ（これは、一次的ＣＧＦと称されることもある）を相互に関連づけ、またＣＧＦ１３２に対してＦＱＰＣを転送する。

セッションについてのＦＱＰＣ１を受信することに応答して、ＣＧＦ１３２は、ローカル・メモリにＦＱＰＣ１のコピーを記憶する。ＣＧＦ１３２の内部の内部ロジックはまた、ＣＧＦ１３２が、中央集中されたストレージ・モジュール１３８にＦＱＰＣ１のコピーを記憶することも制御する。この実施形態においては、中央集中されたストレージ・モジュール１３８は、ＯｐｅｎＳｔａｃｋ（商標）プラットフォーム上に実装されるクラウド・ストレージを備えることができる。それゆえに、この実施形態は、オブジェクトを記憶するためのＯｐｅｎＳｔａｃｋ（商標）スウィフトを考慮することになり、このオブジェクトは、セッションについてのＦＱＰＣになる。ＯｐｅｎＳｔａｃｋ（商標）スウィフト・オブジェクト・ストアＡＰＩは、「アカウント」（オブジェクト・ストアにアクセスすることが許可された認証されたユーザ、これは、この場合には、共通のアカウントを共有することになる複数のＣＧＦインスタンスになる）と、「コンテナ」（複数のファイルが記憶され得るディレクトリに類似する。これは、この場合には、ＣＧＦのトポロジを通しての単一のコンテナになる）と、「オブジェクト」（これは、この場合には、各個別ＦＱＰＣについてのファイルになる）とを規定する。

初期化フェーズ中に、コンテナが、ＦＱＰＣについて中央集中されたストレージ・モジュール１３８の中で作成されることもある。これは、ＯｐｅｎＳｔａｃｋ（商標）オブジェクト・ストアＡＰＩを経由して使用可能なコンテナ・コマンドを使用することにより、達成され、このＯｐｅｎＳｔａｃｋ（商標）オブジェクト・ストアＡＰＩは、４つの動詞、すなわち、
ＧＥＴ−特定のアカウントについてのすべてのコンテナを取り出す
ＨＥＡＤ−どれだけ多くのオブジェクトがコンテナの中にあるかと、コンテナに関連する任意のカスタム・メタデータとを取り出す
ＰＵＴ−オプションとしてのポリシーを有するアカウントにコンテナを作成する
ＤＥＬＥＴＥ−特定のコンテナを削除する
を公開している。

システム初期化の一部分として、コンテナは、ＰＵＴ動詞、すなわち、
ＰＵＴｖ１．０／｛ａｃｃｏｕｎｔ｝／｛ｃｏｎｔａｉｎｅｒ｝
を使用することを通じて、ＯｐｅｎＳｔａｃｋ（商標）スウィフトの中に作成されることもある。

「アカウント」パラメータは、共通ＣＧＦアカウント（例えば、「ＣＧＦ」）を表しており、また「コンテナ」パラメータは、コンテナに記憶されるデータのタイプ（例えば、「ＦＱＰＣ」）を示すことができる。

中央集中されたストレージ・モジュール１３８にＦＱＰＣ１のコピーを記憶するために、ＣＧＦ１３２は、ＦＱＰＣ１の代表的オブジェクトを中央集中されたストレージ・モジュール１３８へとアップロードする。ＣＧＦ１３２は、ＦＱＰＣ１についてのオブジェクト（すなわち、ファイル）を作成し、またオブジェクトに名前を割り当てる。オブジェクトの名前は、セッションに割り当てられた課金ＩＤ（例えば、ＩＣＩＤ）を含むことができ、またはセッションに割り当てられた課金ＩＤ（例えば、ＩＣＩＤ）に基づいたものとすることができる。例えば、課金ＩＤが、「ＳＴＡＳ：１３５．２５１．８５．１９７−４ｂｂ３ｆ３２ｆ−０００００４ａｂ」である場合、そのときにはオブジェクト名は、課金ＩＤを含むことができる。次いで、ＣＧＦ１３２は、以下のＰＵＴコマンド、
$ curl-X PUT -i＼
-H "X-Auth-Token: fa77bcd6-98a1-dab0-d4ba-aba90ab9ae"＼
-T STAS:135.251.85.197-4bb3f32f-000004ab＼
https://commonobjectstore.cloud.swiftdrive.com/v1/CF_xer7_343/FQPC/
STAS:135.251.85.197-4bb3f32f-000004ab
を使用するなどして、このオブジェクトをスウィフト・オブジェクト・ストアへとアップロードする。

ＣＧＦ１３２からのＰＵＴコマンドに応答して、中央集中されたストレージ・モジュール１３８は、「ＦＱＰＣ」についてのコンテナにオブジェクトを記憶する。ＦＱＰＣ１についてのオブジェクトは、他のＣＧＦがセッションについてのＲＰＣを受信する場合に使用するための参照である。

後の時点で、ＣＤＦ１２２は、セッションについての別の部分的ＣＤＲをトリガする。ＣＤＦ１２２が、セッションについてのＦＱＰＣを既に生成しているので、ＣＤＦ１２２は、このトリガリング・イベントのすぐ後に、セッションについての第１のＲＰＣ（ＲＰＣ１）を生成する。ＣＤＦ１２２は、バック・エンド・ディストリビュータ１１５に対してＲＰＣ１を送信する。バック・エンド・ディストリビュータ１１５は、この場合にもＣＧＦ１３２を選択して、ＣＤＲを相互に関連づけ、またＣＧＦ１３２に対してＲＰＣ１を送信する。ＣＧＦ１３２は、ローカル・メモリにＦＱＰＣ１のコピーを記憶するので、ＣＧＦ１３２は、ＲＰＣ１からのデータと、ＦＱＰＣ１からのデータとに基づいて、セッションについての別のＦＱＰＣ（ＦＱＰＣ２）を構築することができる。

ＣＤＦ１２２が、セッションについての別の部分的ＣＤＲをトリガするときに、この部分的ＣＤＲは、この場合にも、ＲＰＣ（ＲＰＣ２）とすることができる。ＣＤＦ１２２は、バック・エンド・ディストリビュータ１１５に対してＲＰＣ２を送信する。バック・エンド・ディストリビュータ１１５は、この場合にも、ＣＧＦ１３２を選択して、ＣＤＲを相互に関連づけるが、ＣＧＦ１３２はサービス停止（ＯＯＳ）になってしまっている。それゆえに、バック・エンド・ディストリビュータ１１５は、バックアップＣＧＦまたは二次的ＣＧＦを選択し、このバックアップＣＧＦまたは二次的ＣＧＦは、ＣＧＦ１３３である。次いで、バック・エンド・ディストリビュータ１１５は、ＣＧＦ１３３に対してセッションについてのＲＰＣ２を送信する。ＣＧＦ１３３がＲＰＣを受信すると、それは、ＲＰＣに基づいて、セッションについての別のＦＱＰＣを構築する必要がある。しかしながら、ＣＧＦ１３３は、それが使用して、ＲＰＣから別のＦＱＰＣを構築することができるセッションについてのＦＱＰＣを受信していない。したがって、ＣＧＦ１３３は、中央集中されたストレージ・モジュール１３８に問い合わせを行って、中央集中されたストレージ・モジュール１３８に記憶された（ＦＱＰＣ１についての）ＦＱＰＣデータを取り出す。

中央集中されたストレージ・モジュール１３８からＦＱＰＣデータをフェッチするために、ＣＧＦ１３３は、ＲＰＣから、ＳＴＡＳ：１３５．２５１．８５．１９７−４ｂｂ３ｆ３２ｆ−０００００４ａｂとなる、セッションに関連する課金ＩＤを抽出することができる。次いで、ＣＧＦ１３３は、課金ＩＤに基づいて、ＦＱＰＣデータについてのオブジェクトの名前を導き出すことができる。次いで、ＣＧＦ１３３は、以下のＧＥＴコマンド、すなわち、
$ curl-X GET＼
-H "X-Auth-Token: fa77bcd6-98a1-dab0-d4ba-aba90ab9ae"＼
https://commonobjectstore.cloud.swiftdrive.com/v1/CF_xer7_343/FQPC/
STAS:135.251.85.197-4bb3f32f-000004ab>
STAS:135.251.85.197-4bb3f32f-000004ab
をアセンブルすることにより、オブジェクトの名前に基づいて、ＦＱＰＣデータについてのオブジェクトを取り出すことができる。

ＣＧＦ１３３は、中央集中されたストレージ・モジュール１３８からＦＱＰＣを受信し、またＲＰＣ２からのデータと、中央集中されたストレージ・モジュール１３８から取り出されたＦＱＰＣ１からのデータとに基づいて、セッションについての別のＦＱＰＣ（ＦＱＰＣ３）を構築する。

ＣＧＦ１３３が、課金ＩＤ「ＳＴＡＳ：１３５．２５１．８５．１９７−４ｂｂ３ｆ３２ｆ−０００００４ａｂ」によって識別されるセッションが終了したことを示すＲＰＣ（ＲＰＣｎ）または別のメッセージを受信する場合、そのときにはＣＧＦ１３３は、ハウスキーピングの一部分として、中央集中されたストレージ・モジュール１３８からＦＱＰＣについてのこのオブジェクトをパージする必要がある。中央集中されたストレージ・モジュール１３８からＦＱＰＣをパージするために、ＣＧＦ１３３は、以下のＤＥＬＥＴＥコマンド、すなわち、
$ curl-X DELETE -i＼
-H "X-Auth-Token: fa77bcd6-98a1-dab0-d4ba-aba90ab9ae"＼
https://commonobjectstore.cloud.swiftdrive.com/v1/CF_xer7_343/FQPC/
STAS:135.251.85.197-4bb3f32f-000004ab
をアセンブルすることができる。

ＤＥＬＥＴＥコマンドに応答して、中央集中されたストレージ・モジュール１３８は、コンテナからこのＦＱＰＣについてのオブジェクトを削除する。

図面に示され、または本明細書において説明される様々な要素またはモジュールのうちのどれもが、ハードウェア、ソフトウェア、ファームウェア、またはこれらの何らかの組合せとして実装される可能性がある。例えば、ある要素は、専用のハードウェアとして実装されることもある。専用のハードウェア要素は、「プロセッサ」、「制御装置」、または何らかの類似した専門用語で称されることもある。プロセッサによって提供されるときに、それらの機能は、単一の専用プロセッサにより、単一の共用プロセッサにより、または複数の個別プロセッサによって提供されることもあり、これらの個別プロセッサのうちのうちのいくつかは、共用されることもある。さらに、「プロセッサ」または「制御装置」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを排他的に意味するように解釈されるべきではなく、また限定することなく、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ）のハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ）または他の回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ）、ソフトウェアを記憶するためのリード・オンリー・メモリ（ＲＯＭ：ｒｅａｄｏｎｌｙｍｅｍｏｒｙ）、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）、不揮発性ストレージ、ロジック、あるいは何らかの他の物理的なハードウェアのコンポーネントまたはモジュールを暗黙のうちに含むことができる。

また、ある要素は、プロセッサまたはコンピュータによって実行可能な命令として実装されて、その要素の機能を実行することができる。命令のいくつかの例は、ソフトウェアと、プログラム・コードと、ファームウェアとである。それらの命令は、プロセッサによって実行されるときに、要素の機能を実行するようにプロセッサに指示するように、動作可能である。それらの命令は、プロセッサによって読み取り可能であるストレージ・デバイスの上に記憶されることもある。ストレージ・デバイスのいくつかの例は、デジタル・メモリまたはソリッド・ステート・メモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、あるいは光学的に読み取り可能なデジタル・データ・ストレージ媒体である。

特定の実施形態が本明細書において説明されたが、本開示の範囲は、これらの特定の実施形態だけに限定されることはない。本開示の範囲は、添付の特許請求の範囲と、それらの任意の均等物とによって規定される。

Claims

少なくとも１つのハードウェア・プラットフォーム上に実装された課金ゲートウェイ機能（ＣＧＦ）のクラスタを備えたオフライン課金システムを備える装置であって、
前記クラスタのうちの第１のＣＧＦは、セッションについての第１の完全に資格要件を満たした部分的ＣＤＲ（ＦＱＰＣ）を受信し、前記第１のＦＱＰＣからのＦＱＰＣデータを、前記クラスタの中の前記ＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールに記憶するように構成されており、
前記クラスタのうちの第２のＣＧＦは、前記第１のＣＧＦの失敗に応答して、前記セッションについての削減された部分的ＣＤＲ（ＲＰＣ）を受信し、前記中央集中されたストレージ・モジュールから前記ＦＱＰＣデータを取り出し、前記ＲＰＣと、前記中央集中されたストレージ・モジュールから取り出された前記ＦＱＰＣデータとに基づいて、前記セッションについての第２のＦＱＰＣを生成するように構成されている、装置。
前記第１のＣＧＦは、前記ＦＱＰＣデータをオブジェクトとして前記中央集中されたストレージ・モジュールに記憶するように構成されており、
前記第１のＣＧＦは、前記セッションに割り当てられた課金識別子（ＩＤ）に基づいて、前記オブジェクトに対して名前を割り当てるように構成されている、請求項１に記載の装置。
前記第２のＣＧＦは、前記ＲＰＣから前記セッションについての前記課金ＩＤを抽出し、前記課金ＩＤに基づいて、前記ＦＱＰＣデータについての前記オブジェクトの前記名前を導き出し、前記オブジェクトの前記名前に基づいて、前記中央集中されたストレージ・モジュールから前記ＦＱＰＣデータについての前記オブジェクトを取り出すように構成されている、請求項２に記載の装置。
前記第２のＣＧＦは、前記セッションについての第３のＦＱＰＣを受信し、前記第３のＦＱＰＣに基づいて、前記中央集中されたストレージ・モジュールの中の前記ＦＱＰＣデータをアップデートするように構成されている、請求項１に記載の装置。
前記第２のＣＧＦは、前記セッションの終了を識別し、前記セッションの前記終了に応答して、前記中央集中されたストレージ・モジュールから前記ＦＱＰＣデータを削除するように構成されている、請求項１に記載の装置。
少なくとも１つのハードウェア・プラットフォーム上に実装された課金ゲートウェイ機能（ＣＧＦ）のクラスタを備えたオフライン課金システムを動作させる方法であって、
前記クラスタのうちの第１のＣＧＦにおいて、セッションについての第１の完全に資格要件を満たした部分的ＣＤＲ（ＦＱＰＣ）を受信するステップと、
前記第１のＣＧＦにより、前記第１のＦＱＰＣからのＦＱＰＣデータを、前記クラスタの中の前記ＣＧＦのそれぞれによってアクセス可能である中央集中されたストレージ・モジュールに記憶するステップと、
前記第１のＣＧＦの失敗に応答して、前記クラスタのうちの第２のＣＧＦにおいて、前記セッションについての削減された部分的ＣＤＲ（ＲＰＣ）を受信するステップと、
前記第２のＣＧＦにより、前記中央集中されたストレージ・モジュールから前記ＦＱＰＣデータを取り出すステップと、
前記第２のＣＧＦにより、前記ＲＰＣと、前記中央集中されたストレージ・モジュールから取り出された前記ＦＱＰＣデータとに基づいて、前記セッションについての第２のＦＱＰＣを生成するステップと、
を含む、方法。
中央集中されたストレージ・モジュールに前記ＦＱＰＣデータを記憶するステップは、前記ＦＱＰＣデータをオブジェクトとして前記中央集中されたストレージ・モジュールに記憶するステップを含み、前記方法は、
前記セッションに割り当てられた課金識別子（ＩＤ）に基づいて、前記オブジェクトに対して名前を割り当てるステップをさらに含む、請求項６に記載の方法。
前記第２のＣＧＦにより、前記ＲＰＣから前記セッションについての前記課金ＩＤを抽出するステップと、
前記課金ＩＤに基づいて、前記ＦＱＰＣデータについての前記オブジェクトの前記名前を導き出すステップと、
前記第２のＣＧＦにより、前記オブジェクトの前記名前に基づいて、前記中央集中されたストレージ・モジュールから前記ＦＱＰＣデータについての前記オブジェクトを取り出すステップと、
をさらに含む、請求項７に記載の方法。
前記第２のＣＧＦにより、前記セッションについての第３のＦＱＰＣを受信するステップと、
前記第３のＦＱＰＣに基づいて、前記中央集中されたストレージ・モジュールの中の前記ＦＱＰＣデータをアップデートするステップと、
をさらに含む、請求項６に記載の方法。
前記第２のＣＧＦにおいて前記セッションの終了を識別するステップと、
前記セッションの前記終了に応答して、前記中央集中されたストレージ・モジュールから前記セッションについての前記ＦＱＰＣデータを削除するステップと、
をさらに含む、請求項６に記載の方法。