(57)【要約】  電気通信ネットワークで使用するための収益管理システムおよび方法を開示する。収益管理システムは、インターネットプロトコルマルチメディアサブシステム（internet protocol multimedia subsystem）（ＩＭＳ）と統合され得る。収益管理システムおよび方法は、ハードウェアおよび／もしくはソフトウェア収益発生モジュールもしくはアーキテクチャ、収益捕捉モジュールもしくはアーキテクチャ、収益収集モジュールもしくはアーキテクチャ、収益分析モジュールもしくはアーキテクチャ、またはそれらの組合せを有し得る。
2008547361.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの前払いおよび／または後払いおよび／または即払いアカウントに対する電気通信サービス用のリアルタイムの課金のための、収益を管理するよう構成されたコンピュータシステムであって、ゲートウェイ層と、収益捕捉層と、データベース層と、記憶層とを備える、システム。
【請求項２】
インメモリオブジェクト記憶装置をさらに備え、前記オブジェクト記憶装置はＲＡＭメモリを含む、請求項１に記載のシステム。
【請求項３】
前記収益捕捉層は前記インメモリオブジェクト記憶装置を含む、請求項２に記載のシステム。
【請求項４】
前記システムは、プロセッサに関してスケーラブルである、請求項１に記載のシステム。
【請求項５】
前記システムは、メモリに関してスケーラブルである、請求項１に記載のシステム。
【請求項６】
前記システムは、ＩＭＳアカウントと接続するよう構成されている、請求項１に記載のシステム。
【請求項７】
前払い、後払いおよび即払いの電気通信ネットワークユーザアカウントに対する収束的なリアルタイムの課金を行なうよう構成されている、収益管理システム。
【請求項８】
前記システムは、ＩＭＳアカウントと接続するよう構成されている、請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願との相互参照
この出願は、２００５年６月２８日に出願された仮出願番号第６０／６９４，７４３号および２００５年７月２８日に出願された仮出願番号第６０／６９４，７４３号の利益を主張し、これらは引用によって全文が本明細書に援用される。
【背景技術】
【０００２】
発明の背景
電気通信ネットワークオペレータおよびサービスプロバイダは、現在、インターネットプロトコルマルチメディアサブシステム（internet protocol multimedia subsystem）（ＩＭＳ）を実装している。ＩＭＳとは、回路交換網、パケット交換網および公衆交換電話網（public switched telephone network）（ＰＳＴＮ）を含むいずれのネットワークタイプ上でもマルチメディアおよび電話サービスをセッションベースで制御するための１組のインターネットプロトコル（Internet Protocol）（ＩＰ）基準である。ＩＭＳは、インターネットプロトコル上で通信、コラボレーションおよびエンターテイメント媒体を管理する。ＩＭＳによって、ユーザは、自然で直観的な方法でコンテンツにも他のユーザにもアクセスできる。
【０００３】
ＩＭＳは、固定されたネットワークまたはモバイルネットワークに依存しない機能をユーザに提供し、セッション開始プロトコル（session initiation protocol）（ＳＩＰ）を含む既存のプロトコルも保持する。ＳＩＰはＩＭＳの中核をなす。ＳＩＰは元々はボイスオーバーインターネットプロトコル（voice over Internet Protocol）（ＶｏＩＰ）のために開発され、ＳＩＰによって、複数のユーザは進行中の通信セッション（すなわち、携帯電話機、コンテンツサーバまたはパーソナルコンピュータなどの２つ以上の通信端末間の接続）に意のままに出入りすることができる。その上、ＳＩＰによって、ユーザはセッション中に動的に媒体（音声、ビデオ、コンテンツなど）を追加または除去でき、複数のセッションを並行して実行できる。
【０００４】
ＩＭＳで可能なサービスには、プッシュ・トゥ・トーク（push-to-talk）、クリック・トゥ・ダイヤル（click-to-dial）、マルチプレイヤゲーム、ビデオ電話、ＳＭＳ、ファイル共有を含む動的なプッシュコンテンツ、ならびにビデオ会議、ならびに他の通信、コラボレーションおよびエンターテイメントサービス間の位置ベースの商取引の組合せが含まれる。
【０００５】
これらのサービスは、以前は、独立したサイロ（silo）の状態で存在していた。すなわち、ユーザは、新しいサービスにアクセスできる（すなわち、セッションを開始する）前に、１つのサービスを出なければならない（すなわち、セッションを終了させなければならない）。ＩＭＳのルーティング、ネットワーク位置、アドレス指定およびセッション管理は、サイロの壁を無くして、複数の並行するセッションを維持しながらユーザにネットワークとサービスとの間を自由に移動させるいわゆる融合した機能性をもたらす。このように、ＩＭＳは、別個の通信事象のシーケンスを単一の共有された通信環境に変容させる。
【０００６】
たとえば、ユーザは、状況に最も適した通信モード（音声、ビデオ付き音声、テキスト・トゥ・スピーチのｅメールなど）を選択できるようになる一方で、たとえば音声通話の途中でビデオストリームを追加することによって、その選択を動的に変更する自由を保持することになる。ユーザは、任意の装置上で、固定されたネットワークまたはモバイルネ
ットワークの任意のネットワークタイプを介して、馴染みのあるサービスにアクセスすることも可能である。ユーザは、より幅広い支払の選択肢、クレジットコントロールプレゼンス管理およびグループへの便利な接続性などの新しい機能性とともにこれらの自由を享受することになる。
【０００７】
ＩＭＳは、オペレータおよびサービスプロバイダに、コスト削減および増収の機会も提供する。ＩＭＳで可能なサービスは、今日のサイロ状態のサービス（siloed service）とは異なって、たとえば課金、ルーティング、プロビジョニングおよび加入者管理のすべての機能を複製する必要がないため、オペレータおよびサービスプロバイダはコスト削減を期待できる。それどころか、ＩＭＳサービスはすべてのサービスにわたって同じ機能を再使用でき、それによって、オペレータにとっては資本および操業上の支出の大幅な節約になる。サービス向上を可能にすることを通じた増収はＩＭＳの他の利点である。このように、ＩＭＳは、商品化の脅威に直面している通信およびメディア企業にとっての次の解決策である。
【０００８】
電気通信ネットワークオペレータおよびサービスプロバイダは、ＩＭＳの価値を実感するために収束的な課金システムを必要とする。このようなシステムは、サービスが複数の第三者プロバイダに端を発するときでさえ、抱き合わせ販売および他の営業販売促進活動時の相互サービス割引ならびに顧客毎の単一の総合請求書を適用するために、統合された顧客のビュー表示とともに必要である。
【０００９】
課金が、近年、バッチ処理からリアルタイム処理へ、バックオフィス支援機能からフロントオフィス基幹機能へ、最小限に抑えられるべきコストから収益を最大化するための戦略的機会へと重大な変容を経るにつれて、旧来の請求書作成アプリケーションは、ＩＭＳで可能なサービスに対する課金の需要に益々不十分になってきた。
【００１０】
さらに、顧客には選択肢があることをオペレータは知っている。この環境では、ＣＳＰは、少なくとも９９．９９９％のアップタイム、いわゆる「ファイブ・ナイン（five-nines）」の可用性を維持できなければ競争力を保つことは困難である。１年当たりかろうじて５分のダウンタイムになるファイブ・ナインは、従来の請求書作成では前例がない。
【００１１】
バッチ処理システムのように、従来の請求書作成ベンダは高可用性のソリューションを提供する必要がなかった。バッチ工程中に請求書作成システムが故障した場合、一旦システムが使用可能になれば単純にジョブを再開させることができた。この理由から、ＣＳＰは、前払いならびに後払いの加入者およびサービスを処理するために別個のシステムを維持することを余儀なくされていた。前払いの音声サービスは、サービス制御ポイント（service control point）（ＳＣＰ）またはサービスノードの形態で前払いソリューションを従来から提供していたネットワーク機器ベンダによって概して管理されていた。ネットワーク、特に前払いの音声を考慮に入れて構築されていたこれらのシステムは、層−１のサービスプロバイダの高可用性および低い待ち時間要件を達成するように設計されていた。しかしながら、非常に単純な評価性能のみを支援するとともに、この設計に焦点を当てることによって、これらのシステムが後払いのシステムよりもはるかに制限的になるという結果になった。
【００１２】
すべての収益管理機能に対する支援を提供する単一のシステムはなかったので、ＣＳＰは多くの場合何十もの別個のシステムを配備してそれらの機能を支援しなければならなかった。異なる「ストーブパイプ（stovepipe）」システムが前払いおよび後払いのサービスを管理する一方で、さらに他のシステムが音声、データ、コンテンツおよびメッセージングなどのサービスを管理していた。このような種々の環境によって、操作コストはより高くなり、益々積極的になる市場の要求を満たすＣＳＰの能力は阻害されてきた。
【００１３】
ＣＳＰはもはや複数のシステムを維持する操作上の超過分を持つだけの余裕がない。その代わりに、ＣＳＰは、高性能および高可用性ならびに柔軟性およびスケーラビリティを与える単純で、収束的な、モジュール方式の収益管理ソリューションを必要としている。また、収益管理システムは、消費者マーケティング、すなわち、抱き合わせ販売、条件付きのマルチサービス割引、高度に細分化された販売促進活動、ならびにコンテンツプロバイダ、サービスプロバイダおよびネットワークオペレータの複数パートナーのバリューチェーンにわたる収益分配を益々必然的に伴う複雑な機能の需要を満たさなければならない。
【００１４】
トランスポート（回路交換網では呼およびパケット交換網ではパケット）をリアルタイムでルーティングしなければならない電気通信ネットワークとは異なって、電気通信プロバイダ用の旧来の請求書作成システムは、慣例に従って、バックオフィス機能、通話詳細記録およびＩＰ詳細記録などのバッチ処理記録を遂行してきた。特定のバッチを処理する予定になっているときに請求書作成システムが使用可能でなければ、技術者は問題を修正し、次いで予定から数時間遅れてプロセスを実行することができた。最悪の場合のシナリオでは、顧客の請求書は通常よりも１日または２日後にメールボックスに届いたものだった。しかしながら、現在では、通信サービスユーザの新たな期待によって、請求書作成ゲームの規則は変化しつつある。
【００１５】
今日のユーザは、さまざまな個人的ニーズ、ビジネスニーズおよび家族のニーズに従って多様な支払の選択肢を要求する。
【００１６】
インボイスを介した後払いの従来の態様でオペレータと勘定を清算する長年にわたる関係を引続き好むユーザがいるのに対して、現在では、前払いする自由を要求するユーザがますます多くなっている。これは、ある期間にわたる、おそらく複数のＣＳＰからのサービスへのクレジットとして、食料品店でプリペイドカードを購入することによって、おそらく行なわれる。さらに、各々の取引が始まるときにデビットカードまたはクレジットカード番号を提供することによって、製品およびサービスを消費するときにそれらの支払を行なう、いわゆる即払いを望むユーザもいる。
【００１７】
収束的なリアルタイムのソリューションがない時には、ＣＳＰは、複数の、統合されていない請求書作成および顧客ケアシステムを維持することによって、前払い、後払いおよび即払いの顧客の強いニーズに対処しなければならなかった。実際、ＣＳＰには選択肢がなかった。なぜなら、旧来の請求書作成システムは、前払いおよび即払いサービスのリアルタイムのトランザクション要件に対応するようには設計されていなかったためである。そして、ＣＳＰは間違いなく、電気通信ネットワークへの直接的な接続を介してリアルタイムで１日当たり数億ものトランザクションを処理するために収益管理システムが必要とする必須の低い待ち時間およびファイブ・ナインの可用性を伴って構築されていなかった。
【００１８】
前払いの高性能／低い待ち時間および高可用性要件を満たし得る請求書作成システムがないことによって、ＣＳＰに対して大幅なコストが課されてきた。なぜなら、ＣＳＰは前払い／後払いの環境およびサービスのために複数の別個のシステムを維持することを余儀なくされていたためである。
【発明の開示】
【発明が解決しようとする課題】
【００１９】
発明の簡単な概要
収益管理システムおよび収益管理のための方法を開示する。収益管理システムは、コン
ピュータのネットワーク、単一のコンピュータ、コンピュータ可読媒体上のプログラム、ソフトウェアおよび／もしくはハードウェアアーキテクチャ、またはそれらの組合せであり得る。収益管理システムは、たとえば電気通信ネットワークオペレータおよびサービスプロバイダが使用でき、電気通信ネットワークの使用および電気通信ネットワークによって発生する収益を管理する。電気通信ネットワークは有線である可能性もあれば、および／または無線である可能性もある。
【課題を解決するための手段】
【００２０】
収益管理システムは、前払い、後払いおよび即払いの電気通信ネットワークユーザアカウントに対する収束的なリアルタイムの課金を行なうことができる。収益管理システムは、サービスサイクル全体を通じて、すなわち収益発生から収益捕捉、収益収集、収益分析まで、収益を管理できる。収益管理システムは、ハードウェアおよび／もしくはソフトウェア収益発生モジュールもしくはアーキテクチャ、収益捕捉モジュールもしくはアーキテクチャ、収益収集モジュールもしくはアーキテクチャ、収益分析モジュールもしくはアーキテクチャ、またはそれらの組合せを有し得る。（本明細書において、モジュール、アーキテクチャ、層またはプラットホームとして示されるかまたは記載される要素または特徴はいずれも、他のモジュール、アーキテクチャ、層またはプラットホームのいずれかであり得る。）
収益発生モジュールまたはアーキテクチャは、電気通信ネットワーク上での新しいサービスの配備の遅れを最小限に抑えることができる。収益発生モジュールまたはアーキテクチャは、迅速なプロビジョニング、価格設定、割引、ならびに個人用販売促進活動および収益分配などの顧客およびパートナー関係のすべての局面の管理のためのＧＵＩベースのアプリケーションを有し得る。
【００２１】
収益捕捉モジュールまたはアーキテクチャは、詐欺またはシステムダウンタイムが原因の漏れがゼロの状態ですべてのトランザクションを収益に変換する高性能および高可用性のプラットホームを強化し得る。高可用性のプラットホームはさらに、顧客離れを最小限に抑える。
【００２２】
収益収集モジュールまたはアーキテクチャは、すべての前払いおよび即払いの収益をリアルタイムで収集しながら、後払いアカウントの正確な請求書を保証できる。収益収集モジュールは、パートナー（たとえば、ビジネスパートナー）の明細を生成でき、たとえばマーケティング戦略の変更を提案するために財政状態のリアルタイムのビュー表示を提供できる。
【００２３】
収益分析モジュールまたはアーキテクチャは、収益管理システムを通過するトランザクションを処理でき、予め定められた数学的関数にデータを提供できる（すなわち、データ分析）。収益分析モジュールは、ＩＭＳで可能なサービスとともに使用され得る。
【００２４】
収益管理システムは、ＩＭＳで可能なサービスを迅速に起動および管理し、エンドツーエンドの収益管理を行うためのキャリアグレード（carrier-grade）性能、高可用性、無制限のスケーラビリティ、柔軟性、およびそれらの組合せを提供できる。
【００２５】
収益管理システムは、サービスプロバイダが顧客タイプ、ネットワーク、サービス、支払方法および地理にわたってリアルタイムで収益を管理するための単一の収束的なプラットホームであり得る。収益管理システムは、収束的な収益管理システムの機能性および柔軟性とともに、たとえばフロントエンドキャリアグレードネットワーク要素のものと等しい高性能、高可用性およびスケーラビリティを有し得る。
【００２６】
収益管理システムは、任意の顧客タイプ（家庭用またはビジネス用）、ネットワークタ
イプ（パケット交換または回路交換）、サービスタイプ（音声、データ、コマースなど）、支払方法（前払い、後払いおよび即払い）、および地理（複数の通貨および税制度）にわたってリアルタイムで収益を管理する統一システムであり得る。ＣＳＰの請求書作成および顧客ケアプラットホームにおける不十分な性能および可用性の意味合いを調査した後である。収益管理システムは、高性能／低い待ち時間のために収益捕捉プラットホームおよびインメモリオブジェクト記憶装置（たとえば、ＴＩＭＯＳまたは他の技術）を有することができ、高可用性のためにアクティブ／アクティブ段階的アーキテクチャを有することができる。
【００２７】
収益管理システムは、新しいサービスを迅速に起動および管理するためのキャリアグレード性能、無制限のスケーラビリティ、ファイブ・ナインの可用性、柔軟性、およびそれらの組合せを与えることができる。
【００２８】
収益管理システムは、統一された加入者のビュー表示（たとえば、さまざまなネットワークにわたるユーザのためのデータベース情報の迅速かつ組織立ったビュー表示）をオペレータに与えることができる。収益管理システムは、市場細分化のためにデータベースデータを分析し、割引（たとえば、マルチサービス割引）を作り出し、すべてのサービスを単一の請求書に集約するなどの機能性を促進し、与えるように構成され得る。
【００２９】
収益管理システムは、たとえばネットワークがさまざまな音声およびマルチメディアサービスを提供でき、それらの請求書を作成できるようにエンドカスタマーとの複数の収益接触点を正確に管理できる。
【００３０】
収束的な収益管理システムは、重複を排除でき、範囲の経済性を活用できるため、複数の統合されていないシステムよりも操作コストが低くなり得る。このような効率は、資源、技能、訓練、ハードウェアなどの実質的な節約に繋がる可能性がある。収束的な収益管理システムは、複数のスタンドアロンのシステムよりも大きな柔軟性およびスケーラビリティを有し得る。このシステムは、サービスが複数のプロバイダに端を発するときでさえ、相互サービス割引を抱き合わせ販売に適用する能力および顧客ごとに単一の請求書を生成する容量などの重要な機能性の利点を、統合された顧客のビュー表示に提供できる。
【発明を実施するための最良の形態】
【００３１】
詳細な説明
図１は、収益管理システムがＩＭＳフレームワークと統合され得る（すなわち、ＩＭＳフレームワークとデータ通信し得る）ことを示す。ユーザは、任意の装置を介して、および標準アクセスポイント、ＣＳＣＦ（call session control function）（呼セッション制御機能）またはＳＩＰサーバを通る任意のアクセスネットワークを介して、ＩＰベースのサービスにアクセスできる。ＣＳＣＦは、セッションをセットアップおよび管理し、他のユーザからまたはコンテンツおよびアプリケーションサーバからメッセージおよびコンテンツを送る。ＣＳＣＦは、加入者のデータおよび好みを管理するＨＳＳ（home subscriber service）（ホーム加入者サービス）と共同で機能し、ユーザは互いに探し出すことができ、加入したサービスにアクセスできるようになる。ＣＧＦ（charging gateway function）（課金ゲートウェイ機能）は、他のオペレータのネットワークへのアクセスを仲介でき、課金、プロビジョニングおよび顧客サービスのためのアプリケーションを支援できる。
【００３２】
図２は、収益管理システムのアーキテクチャがゲートウェイ層（たとえば、ＡＡＡゲートウェイ）、収益捕捉層、ならびにデータベースおよび記憶層を有し得ることを示す。ゲートウェイ層は、（カリフォルニア州パロアルト（Palo Alto）のヒューレット・パッカード・インコーポレイテッド（Hewlett Packard, Inc.）からの）ＨＰ  OpenCallなどの
サービスプラットホームを介して外部のネットワークに接続でき、次にネットワークスイッチに接続できる。
【００３３】
ゲートウェイ層は、ネットワーク層とのインターフェイスであり得る。ネットワーク層への接続は、１つ、２つまたはそれより多くのＡＡＡ（authentication, authorization,
accounting）（認証、許可、アカウンティング）ゲートウェイマネージャを介して維持されることができる。ＡＡＡゲートウェイマネージャは、１つの第１のマネージャおよび１つ以上のアイドル状態であるが実行するバックアップを含むことができ、ＴＣＰ／ＩＰを介してネットワークＳＣＰに接続し、いくつかのタスクを管理する。これらのタスクは、プロトコル翻訳、非同期インターフェイス、負荷バランシング、サービス水準合意（service-level agreement）（ＳＬＡ）の待ち時間の実施、故障の検出、故障の処理、故障の回復、およびそれらの組合せを含み得る。
【００３４】
プロトコル翻訳は、ネットワークＳＣＰが使用するプロトコルから通信プロトコル（たとえば、ポータル通信プロトコル（Portal Communications Protocol）（ＰＣＰ））への高速の翻訳を提供できる。ＡＡＡゲートウェイは、ＨＰ  OpenCallのメッセージベースのインターフェイス（Message Based Interface）（ＭＢＩ）プロトコル、ダイアメータ課金（Diameter Charging）およびＰＣＰを支援できる。ＡＡＡゲートウェイは、追加のプロトコルを支援するために拡張機能を提供できる。
【００３５】
ＳＣＰへの非同期接続では、要求がＳＣＰから受取られ、承認され得る。要求されたオペレーションが完了した後、ＡＡＡゲートウェイの非同期インターフェイスはＳＣＰへの応答を最終結果とともに送信できる。
【００３６】
負荷バランシング要素は、ラウンドロビンアルゴリズムを使用して、使用可能な接続マネージャ全体にわたって均一に要求を分散させることができる。
【００３７】
ＳＬＡの実施は、サービス水準合意の待ち時間要件との適合性をモニタリングおよび保証し得る。
【００３８】
故障検出要素は、ＡＡＡゲートウェイと収益捕捉プラットホームにおける接続マネージャとの間の壊れたリンクなどの故障を検出できる。
【００３９】
故障処理要素は、バックエンドの故障および待ち状態の回復、およびバックエンドが使用可能でない場合または指定された待ち時間レベルの範囲内でバックエンドが全く応答していない場合の低下した動作モード中に処理される要求のための暫定的な要求記憶機構を提供できる。
【００４０】
故障回復要素は、故障後に、収益捕捉プラットホームへ要求を再実行できる。
呼（または他の接続）がネットワークに達すると、ＳＣＰは、サービスを承諾する（すなわち、呼を許可する）ためにＡＡＡゲートウェイに照会し得る。通話中、ＳＣＰは、通話開始および通話終了要求を通すことによって、および以前に許可された量が使い尽くされる寸前である場合には要求を再許可することによって、収益管理システムは、通話状態を評価される状態に保つ。
【００４１】
ＡＡＡゲートウェイは、ＳＣＰ要求を事象データ記録（event data record）（ＥＤＲ）に変換できる。ＡＡＡゲートウェイは、次いで、サービスおよび要求タイプに応じて、たとえば認証、許可またはアカウンティングの専門の処理パイプラインにＥＤＲを送ることができる。処理パイプラインは、収益捕捉プラットホームにおいてＣＭのＡＰＩを呼出すことができるモジュールを含み得る。これは、応答を受取るまで処理を阻止する同期呼
である。応答は次いでＥＤＲへの翻訳を経ることができ、ＥＤＲはネットワーク出力モジュールに進むことができ、ネットワーク出力モジュールは応答をＳＣＰに戻すことができる。
【００４２】
このプロセスは、ＡＡＡゲートウェイにおけるタイムアウトモニタリング機構によって待ち時間についてモニタリングされ得る。タイムアウト機構は、受入れることのできない待ち時間を検出すると、ＥＤＲをタイムアウトパイプラインに渡すことができる。次いで、タイムアウトパイプラインはビジネスロジックを実行することができ、必要な待ち時間レベルを有する応答を保証するために低下したモードで要求を処理する。低下したモードによって、タイムアウトパイプラインは、構成可能な規則の組に基づいて、いかに進むべきかについて決定することができる。たとえば、要求が市内通話を許可するためのものである場合、規則はこのような要求のタイムアウト後にデフォルトによって承認を示し得る。対照的に、国際通話を許可するための、タイムアウトになった要求は、デフォルトの拒否を受取り得る。
【００４３】
２つの他のパイプライン、すなわち例外パイプラインおよび再実行パイプラインは、いかなる収益漏れも防ぐために、タイムアウトになった要求をリーンアップし（lean up）、記憶し、再実行することができる。タイムアウトが収益捕捉プラットホームにおける故障によって引起されていた場合には、再実行パイプラインは、収益捕捉プラットホームが接続状態に戻り、ログ記録された要求をそれに送信した後に再実行ログを読取ることができる。タイムアウトが他の理由で生じていた場合には、再実行はすぐに開始できる。
【００４４】
収益捕捉層は、前払いおよび即払いのトランザクションに必要な認証および許可を実行できる。収益捕捉層は、すべてのトランザクションを評価および記録する事象のアカウンティングタスクを処理することができる。図３は、収益捕捉層が、１つ、２つまたはそれより多くの接続マネージャ、データベースデータマネージャ、およびＴＩＭＯＳ（transactional in-memory object store）（トランザクションインメモリオブジェクト記憶装置）データマネージャ、すなわちデータベースと同期し得る高性能のインメモリ記憶装置を有し得ることを示す。収益捕捉層の要素は、収益捕捉プラットホームによって包含され得る。
【００４５】
各ＡＡＡゲートウェイマネージャは、ＴＣＰ／ＩＰを介して、１つ、２つまたはそれより多くの別個の接続マネージャに接続できる。第１の／バックアップモデルとは対照的に、これらの２つの接続は、通常の処理中は常に使用される。ＣＡＩへの開始要求は、単純なラウンドロビンアルゴリズムによって均一に分散される。接続の相互機械分散によって、ハードウェアレベルでの故障許容が提供され得る（接続マネージャの数は、オペレータの可用性およびスケーラビリティ要件によって決定され得るであろう）。
【００４６】
接続マネージャは、適切なＴＩＭＯＳデータマネージャまたはバックエンドデータベースマネージャに要求をルーティングできる。収益管理システムの設計は、高速のインメモリＴＩＭＯＳキャッシュからのデータだけにアクセスすることによって、実行されるべき認証および許可などの、時間に影響されやすい要求を与えることができる。より高い待ち時間を許容できるアカウンティング要求は、ＴＩＭＯＳキャッシュにもバックエンドデータベースにもアクセスできる。
【００４７】
このシステムは、非リアルタイム要求がＴＩＭＯＳデータをバイパスするように構成され得る。非リアルタイム要求は、たとえばバッチ評価または請求書作成ジョブ、または顧客サービス担当によるアカウントクエリーなどの、ミリ秒レベルの応答時間を必要としないリアルタイム要求を含み得る。
【００４８】
図４は、示される例示的な負荷分散を有する収益管理システムの変形例を示す。このシステムのアーキテクチャは、１つ、２つまたはそれより多くのＴＩＭＯＳインスタンスおよびそれらのバックアップインスタンスを有し得る。各ＴＩＭＯＳインスタンスは３つのコンポーネント、すなわち参照オブジェクトキャッシュ、移動性データおよび非常駐オブジェクト記憶装置を有し得る。
【００４９】
参照オブジェクトキャッシュは、リアルタイムの認証および許可プロセス中に読取専用の参照に必要な、顧客のアカウントの記録などのデータベースオブジェクトのためのキャッシュエリアであり得る。
【００５０】
移動性データは、データベースから参照オブジェクトキャッシュを埋めるためのサブシステムであり得る。
【００５１】
非常駐オブジェクト記憶装置は、アクティブセッションオブジェクトおよびリソース予約オブジェクトなどの、ＴＩＭＯＳのみが使用する一時的なオブジェクトを記憶するために使用されるエリアであり得る。
【００５２】
ＴＩＭＯＳインスタンスは、加入者ベースの別個の組を満たし得る。たとえば、最小限の２つのインスタンスの構成についてインスタンス当たり約５０％の加入者を図４に示す。各々の第１のＴＩＭＯＳインスタンスは独立したサーバ上で実行可能であり、その同じサーバが別の第１のＴＩＭＯＳインスタンスのバックアップインスタンスを実行させる。
【００５３】
その一方で、接続マネージャは、正しいインスタンスに要求をルーティングするためにディレクトリサーバを調査し得る。ディレクトリサーバは、別個のプロセスとして構成可能である可能性もあれば、任意のＴＩＭＯＳインスタンスの一部として構成可能である可能性もある。
【００５４】
ＴＩＭＯＳデータマネージャは次に少なくとも２つのデータベースデータマネージャに接続でき、この２つのデータベースデータマネージャは両方アクティブであり、故障の場合には他方のワークロードを引継ぐことができる。データベースデータマネージャは、バックエンドリレーショナルデータベースと接続する。
【００５５】
データベースおよび記憶層は、１つ以上のサーバクラスタ、クラスタソフトウェア、１つ以上の記憶エリアネットワーク、およびそれらの組合せを有し得る。サーバクラスタは少なくとも２つのデータベースサーバの構成である可能性があり、この２つのデータベースサーバは単一のデータベースについてのデータを処理する。クラスタソフトウェアは、（たとえば、オラクルＲＡＣ（Real Application Cluster）（リアルアプリケーションクラスタ）クラスタソフトウェア、またはそれを用いて実行するための）前払いの支払アカウントを管理できる。記憶エリアネットワークは、高速および高可用性のディスク記憶装置を支援できる。
【００５６】
収益管理システムは、高速の記憶エリアネットワークを介して、オラクルＲＡＣなどの高性能のリレーショナルデータベースにアクセスできる。このシステムはマルチスレッドおよびＴＩＭＯＳデータ管理を利用可能である。ＴＩＭＯＳは、システムメモリ（すなわち、ＲＡＭ）にアクセスできる。ＲＡＭにおけるデータ要求は、ディスクベースのデータベースにおけるデータ要求よりもはるかに早く処理できる。ＴＩＭＯＳデータ管理とＲＤＢＭＳとの間の以下の差異のために、リレーショナルデータベースと比較して、スループットおよび待ち時間を低減できる。
【００５７】
ＴＩＭＯＳは、インメモリデータを記憶でき、データベースアクセスの時間遅延および
関係のある表現とデータベースの物理的なフォーマットとの間の翻訳を回避できる。
【００５８】
収益管理システムは、インメモリデータのために最適化された内部検索および記憶アルゴリズムを利用し、待ち時間をさらに低減する。
【００５９】
ＴＩＭＯＳによって管理されるデータの読取専用の要求は、バックエンドデータベースおよびそれに続くディスク記憶装置への往復を回避でき、それによって、複数のネットワークホップおよび関連付けられる待ち時間を回避する。非常駐オブジェクトの作成および更新は、ＴＩＭＯＳによって専らメモリにおいて行なわれることができ、ディスクアクセスオペレーションを必要としない。
【００６０】
このシステムは、段階的可用性アーキテクチャ、常用／常用冗長構成および制御可能なシステム再生を介して、オペレーションを分散させ得る。
【００６１】
収益管理システムは、収益捕捉プラットホーム内のより低い層のコンポーネントにおいて故障が発生した場合に、必要であれば低下したモードで、可用性が非常に高い、より高い層がシステムオペレーションを維持できる段階的可用性アーキテクチャを有し得る。たとえば、第１のＡＡＡゲートウェイが収益捕捉層における接続マネージャへの接続性を失ったとしても、ゲートウェイ層はサービス許可の可用性を維持できる。低下したモードで動作するときでさえ、このシステムは、確実にすべての事象を再実行ログに取込み、ディスクに残して、耐久性を持たせることによって、収益漏れを防ぐことができる。再実行ログを使用することによって、システムが回復するとすぐに各事象が確実に課金を受けることができるようになる。
【００６２】
【表１】
2008547361.tif 000003
【００６３】
表１は、収益管理システムの層の各々についての例示的なパーセンテージを示す。ＡＡＡゲートウェイが、サービスの許可のために９９．９９９％の可用性を提供するように設計されており、低下したモードで実行可能であるので、サービス可用性は、最も使用可能でないコンポーネントの可用性よりも大幅に高い。フロントオフィス（たとえば、ＲＡＭ）のリアルタイム処理によって、高可用性が可能になる。
【００６４】
このシステムは、常用／常用冗長または常用／受動冗長を有し得る。常用／常用冗長は、実質的にすぐにコンポーネントにおける故障を検出でき、故障したコンポーネントの負荷を対応するものに自動的に切換えることができる。対応するものは、故障したコンポーネントの追加の負荷を引受けることができる。なぜなら、このシステムは、ノードが通常のオペレーション下で容量を十分に下回って実行するように構成される（たとえば、適切に大きさを決められる）ことができ、したがって、フェイルオーバー中に追加の負荷を吸収できるためである。
【００６５】
ＡＡＡゲートウェイは、２つのアクティブな接続マネージャ間でトラフィック５０／５
０を分割できる。各接続マネージャは、適切なＴＩＭＯＳデータマネージャまたはデータベースデータマネージャに要求をルーティングできる。各クラスタノードは、通常のオペレーション中は４０％の容量で実行し得る。ＴＩＭＯＳデータマネージャのうちの１つが接続マネージャに応答できない場合には、このシステムは、他のクラスタノード上で実行するＴＩＭＯＳデータマネージャのバックアップインスタンスに自動的にフェイルオーバーできる。
【００６６】
フェイルオーバー時に、移動性データは、予めロードされていなかった任意の参照データでバックアップＴＩＭＯＳキャッシュをロードし始めることができる。バックアップシステム上での処理は、フェイルオーバーの直後に再開し得る（たとえば、システムはデータ移動の完了を待つ必要がない）。必要なデータがまだＴＩＭＯＳキャッシュにロードされていないバックアップＴＩＭＯＳ  ＤＭに要求が入ると、要求は適切なデータベースＤＭに渡されることができる。タイムアウトモニタは、埋まったキャッシュへの要求よりも待ち時間が高いとしても必要な待ち時間制限内に確実に応答がなされるようにできる。さらに、要求されたオブジェクトは、キャッシュに入れられていないオブジェクトへの要求のために副作用としてキャッシュに入れられることができ、たとえば同じデータに対するその後の要求をはるかに早くする。
【００６７】
このシステムは他のタイプのフェイルオーバーを支援できる。たとえば、ＡＡＡゲートウェイと接続マネージャとの間の接続が失敗すると、接続が依然として操作可能である接続マネージャは全負荷を引受けることができる。その一方で、ＡＡＡゲートウェイは、指定された待ち時間内に接続マネージャから応答を受取らなければ特注のビジネスロジックを自動的に実行し得る。たとえば、接続マネージャがデータベース更新要求に応答できなかった場合、ビジネスロジックは、システムが一旦回復するとＡＡＡゲートウェイが確実に後続の処理の要求を保存できるようにする。特注のビジネスロジックは、顧客の残高情報へのアクセスを拒む深刻な故障状態下で、たとえ低下したモードであっても、オペレーションを維持できる。
【００６８】
記憶エリアネットワーク、クラスタサーバおよびオラクルのＲＡＣソフトウェアの組合せによって、データベースおよび記憶層における高可用性を支援できる。図４は、異なるデータベーススキーマに位置する、たとえば別個の顧客セグメントを満たす、少なくとも２つの独立したサーバ（たとえば、ＲＡＣサーバ）を有し得るデータベース構成を示す。各ＲＡＣサーバは１つのデータベーススキーマ専用であり得る。通常のオペレーション中は、システムの両半分についてのトラフィックは、異なる経路を辿ることができ、互いに干渉し得ない。故障状況では、オラクルはトラフィックを残りのＲＡＣサーバにリダイレクトすることができる。オラクルＲＡＣによって、トラフィックを確実に残りのノードに円滑に移行させることができる。
【００６９】
記憶アレイおよびディスクミラーリングなどの他のオプションのアプローチは、データベースおよび記憶層における追加の障害許容力を提供し得る。
【００７０】
収益管理システムは、たとえば高可用性をさらに補うために、制御可能なシステム再生モジュールを有し得る。制御可能なシステム再生は、指定された間隔でプロセスが自動的に再開するように設定された状態で、ＣＳＰにすべてのシステムプロセスの寿命を制限させるように構成され得る。制御可能なシステム再生（すなわち、予定されているフェイルオーバーと類似している）は、そうでなければシステムの安定性を危うくする可能性がある累積エラーがいずれも決定的なものになり得ないことを非難できる。比較的良好な状態でこのようなエラーを検出することによって、制御可能なシステム再生には、技術者がエラー蓄積の源を修正する時間の余裕がある。さらに重要なことには、制御可能なシステム再生モジュールは、予定されていないフェイルオーバーが発生したときに確実に適切に実
行できるようにする。
【００７１】
コンテンツマネージャモジュールは、オペレータを付加価値サービスプロバイダとリンクするために、安全な請求書作成インターフェイスを提供できる。収益管理モジュールは、ビジネスパートナーが自分達のシステムをすべて購入および支援する必要なく、（たとえば、インターネットまたは他のＧＵＩインターフェイスを介して）ビジネスパートナーが収益マネージャモジュールのリアルタイムの機能性にアクセスできるようにし得る。
【００７２】
このシステムは、価格設定管理、顧客管理、パートナー管理、およびサービスの使用可能性のための柔軟性のあるＧＵＩアプリケーションを有し得る。たとえば、このシステムは価格設定センター／管理モジュールを有し得る。価格設定センター／管理モジュールは、価格設定および割引のための関連付けられる規則とともに製品およびサービスのカタログを迅速に規定するためのツールなどの価格設定管理機能性を有し得る。
【００７３】
価格設定管理モジュールは、いずれの支払方法のためにも統一した価格設定インターフェイス（たとえば、１つのツール／１つのプロセス）を用いて価格設定、販売促進活動およびサービスバンドルを規定できる。価格設定管理モジュールは、評価スキームの一部として評価記録内から任意の属性を使用できる。価格設定管理モジュールは、１回限りの、繰返し発生しない事象（たとえば、登録／取消料金、ｍコマース、コンテンツおよびさまざまなサービスの使用）を支援でき、かつ、さまざまな期間の繰返し発生する事象（たとえば、週に一度、月に一度、数ヶ月に一度、および年に一度の事象）に対する前払いのサポートを支援できる。価格設定管理モジュールは、層状になった、大量の、マルチサービス割引オプションおよびユーザ定義の割引を管理できる。価格設定管理モジュールは、日／週の時間および特別な日を追跡できる。価格設定管理モジュールは、閉じたユーザグループおよび友人および家族などの価格設定オプションをグループ分けできる。価格設定管理モジュールは、ゾーンおよび位置ベースの価格設定に対する支援を提供できる。価格設定管理モジュールは、無制限の数の価格設定メトリック、すなわちトランスポートベースのメトリック（分当たり、キロバイト当たりなど）、価値ベースのメトリック（呼出し音当たり、ゲーム当たり、メッセージ当たりなど）、混成のメトリック、またはＣＳＰが将来規定したいと思う可能性のある任意のメトリックを管理できる。価格設定管理モジュールは、１つ以上の残高の影響を任意の数の割当てられた金銭的または非金銭的な残高に割当てることができる。価格設定管理モジュールは比例配分規則を規定できる。価格設定管理モジュールは、総勘定元帳（general ledger）（Ｇ／Ｌ）における項目との、製品とサービスとの間の関連を規定できる。
【００７４】
このシステムは顧客管理インターフェイスモジュールを有し得る。顧客管理インターフェイスは、リアルタイムまたはバッチＣＲＭ／ＰＲＭ統合を介して、旧来のアプリケーションとの統合またはそれらの組合せを介して、たとえば収益管理システム内で固有に顧客およびパートナーのアカウントを作成および管理することを支援できる。
【００７５】
収益管理システムは、サービス上で装置関連情報を活性化、不活性化、プロビジョニングおよび維持するために他のモジュールを有し得る。たとえば、リアルタイムでプロビジョニングできるサービス（たとえば、ＧＳＭ電話）もあれば、段階的なプロビジョニングを有し得るサービス（たとえば、高速のインターネットアクセス）もある。このシステムは、ＧＰＲＳ、ＧＳＭ、ＷＡＰ、ＬＤＡＰ、およびＳＩＭなどのサービスならびに基準の工業要件に基づいて特定のサービス管理性能を提供するために１つ以上のサービスマネージャモジュールを有し得る。
【００７６】
収益管理システムは、ソフトウェアの修正がほとんどないかまたは全くなく、性能の損失がない状態で、無制限の、線形に近いスケーラビリティを支援できる。加入者またはト
ランザクション量が増加すると、オペレータは垂直的なスケーリング（たとえば、既存のサーバへのＣＰＵの追加）または水平的なスケーリング（たとえば、追加のサーバの配備）のいずれかによっていつでも容量を追加できる。この追加の容量によって、システムの高性能および高可用性は減少しないままであることが可能である。
【００７７】
たとえばトランザクション量の増加が既存のＴＩＭＯＳインスタンスの容量に近づくと、オペレータは別のＴＩＭＯＳインスタンスの対を支援するために必要なハードウェアを追加できる。このシステムは、たとえばＴＩＭＯＳがシステムの容量における制限要因でなければ、オラクルＲＡＣクラスタなどの複数のデータベースを追加することによって容易にスケーラブルである。図３の最小限の構成の拡張である図５は、複数のＤＢのスケーラビリティの変形例を示す。
【００７８】
収益管理システムは、さまざまな顧客中心の方法でクレジットを管理できる。たとえば、家族は（たとえば、家族の各メンバーが異なる支払スキームを望む場合に）同じファミリープランで別個の前払いおよび／または後払いおよび／または即払いのサブアカウントを有することができる。企業は、企業の通信装置について個人的な使用とビジネスでの使用との間でアカウントを分けることができる（たとえば、従業員は、個人的な通話およびビジネスでの通話を行なうことができ、別個のアカウントに請求されることが可能である）。
【００７９】
インボイスを準備し、印刷し、顧客に郵送する月に一度のバッチプロセスを介した請求書作成に慣れているサービスプロバイダにとっては、ＩＭＳ時代の顧客中心の請求書作成は例のごとくビジネスの終わりを意味する。その代わりに、サービスプロバイダは、顧客の条件通りに顧客のクレジットおよび料金を管理でき、前払いおよび即払いのオプションならびに従来の後払いのインボイス送付を提供する、より柔軟性のあるリアルタイムのシステムを実現しなければならない。
【００８０】
図６は、収益管理システム用のベンチマークテストについての構成を示す。このテストは、カリフォルニア州キューパーティーノ（Cupertino）のヒューレット・パッカードの研究所において行なわれた。このテストは、７２個の１−ＧＨｚのＣＰＵが複数のドメインにパーティション化された状態の単一のＨＰスーパードームコンピュータで行なわれた。８個のＣＰＵのパーティションで実行するテストドライバソフトウェアが、収益管理システムを通る真のトラフィック負荷（１５０万人の前払いの加入者）をシミュレートした。接続マネージャおよびデータベースデータマネージャも各々８個のＣＰＵのパーティションで実行したが、トランザクションインメモリオブジェクト記憶装置（ＴＩＭＯＳ）データマネージャの単一のインスタンスは１６個のＣＰＵのパーティションで実行した。オラクルＲＤＢＭＳは別の１６個のＣＰＵのパーティションで実行した。
【００８１】
【表２】
2008547361.tif 000004
【００８２】
表２は、ベンチマークテストの結果を示す。セッションとは、最初から最後までのネットワークへのユーザのアクセスを表わす。たとえば、前払いの音声通話の場合、発呼者の支払の許可に続いて被発呼者が呼出に応えるとセッションが開始する。このセッションは
、発呼者が電話を切ると終了する。たとえば前払いのＳＭＳメッセージの場合には、支払許可の直後に、恐らくはるかに短いセッションが開始し、一旦メッセージがネットワークを渡して伝送されると終了する。
【００８３】
各セッションは複数のオペレーションを含んでいてもよい。たとえば、前払いの音声通話は典型的には、サービス許可オペレーション、および承諾されるとアカウンティング開始オペレーション、およびアカウンティング停止オペレーションの３つのオペレーションを含む。前払いの通話は、たとえば通話時間が長い場合にネットワーク上でより多くの時間を再許可および予約するためにシステム内でオペレーションを引起し得る。ＳＭＳメッセージに概して必要なのは、メッセージ当たり２つのオペレーション、すなわち許可およびアカウンティング停止だけである。
【００８４】
被テストシステムは、秒当たり１７９もの並行するセッションを支援した。これは、ＣＰＵ当たり毎秒９．０のセッションに匹敵し、秒当たり４９４のオペレーションに匹敵する。その上、システムが線形にスケーラブルであるため、追加のＴＩＭＯＳインスタンスを確立し、より多くのＣＰＵを含めることによって、ファイブ・ナインのサービス可用性で考えられるいずれの負荷需要も満たすために、比例した性能の増大が提供され得る。
【００８５】
ベンチマークテストシステムのスケールアップしたバージョンは、数千万人の加入者を支援できる。ベンチマークテスト結果における平均的な許可待ち時間は３４ミリ秒である（すなわち、実質的に瞬時の応答である）。
【００８６】
この発明の精神および範囲から逸脱することなくさまざまな変更および修正がこの開示および利用される等価物に対してなされ得ることが当業者に明らかである。任意の実施例とともに示される要素は、具体的な実施例についての例示であり、この開示の範囲内で他の実施例で使用することができる。
【図面の簡単な説明】
【００８７】
【図１】ＩＭＳフレームワークに統合される収益管理システムの変形例を示す。
【図２】ネットワーク層を有する収益管理システムの変形例を示す。
【図３】収益管理システムの変形例を示す。
【図４】例示的な負荷分散を有する収益管理システムの変形例を示す。
【図５】複数のデータベースサブシステムを有する収益管理システムの変形例を示す。
【図６】収益管理システムのベンチマークテストのためのセットアップを示す。
【図２】
2008547361.tif 000005
【図３】
2008547361.tif 000006
【図４】
2008547361.tif 000007
【図５】
2008547361.tif 000008
【図６】
2008547361.tif 000009
【図１】
2008547361.tif 000010
【手続補正書】
【提出日】平成20年2月29日(2008.2.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つの前払い、少なくとも１つの後払いおよび少なくとも１つの即払いアカウントに対する電気通信サービス用のリアルタイムの課金のための、収益を管理するよう構成されたコンピュータシステムであって、
通信ネットワークと通信するように結合されたゲートウェイ層を備え、前記ゲートウェイ層は、前記通信ネットワークを介してユーザからサービス要求を受取り、前記ユーザの認証および要求された前記サービスの許可を要求するように適合されており、前記システムはさらに、
前記ゲートウェイ層と通信するように結合された収益捕捉層を備え、前記収益捕捉層は、前記ユーザの認証および要求された前記サービスの許可の要求を前記ゲートウェイ層から受取り、前記ユーザの認証および要求された前記サービスの許可を実行し、要求された前記サービスに対して課金するように適合されており、前記システムはさらに、
前記収益捕捉層と通信するように結合されたデータベース層を備え、前記データベース層は、前記収益捕捉層に顧客情報を提供するように適合されており、前記システムはさらに、
前記データベース層と通信するように結合された記憶層を備え、前記記憶層は、顧客アカウント情報を維持するように適合されている、システム。
【請求項２】
インメモリオブジェクト記憶装置をさらに備え、前記オブジェクト記憶装置はＲＡＭメモリを含む、請求項１に記載のシステム。
【請求項３】
前記収益捕捉層は前記インメモリオブジェクト記憶装置を含む、請求項２に記載のシステム。
【請求項４】
前記システムは、プロセッサに関してスケーラブルである、請求項１に記載のシステム。
【請求項５】
前記システムは、メモリに関してスケーラブルである、請求項１に記載のシステム。
【請求項６】
要求された前記サービスは、ＩＭＳで可能なサービスを含む、請求項１に記載のシステム。
【請求項７】
前払い、後払いおよび即払いの電気通信ネットワークユーザアカウントに対する収束的なリアルタイムの課金を行なうよう構成された収益管理システムであって、
通信ネットワークと、
前記通信ネットワークと通信するように結合されたゲートウェイ層を備え、前記ゲートウェイ層は、前記通信ネットワークを介してユーザからサービス要求を受取り、前記ユーザの認証および要求された前記サービスの許可を要求するように適合されており、前記システムはさらに、
前記ゲートウェイ層と通信するように結合された収益捕捉層を備え、前記収益捕捉層は、前記ユーザの認証および要求された前記サービスの許可の要求を前記ゲートウェイ層から受取り、前記ユーザの認証および要求された前記サービスの許可を実行し、要求された前記サービスに対して課金するように適合されている、システム。
【請求項８】
要求された前記サービスは、ＩＭＳで可能なサービスを含む、請求項７に記載のシステム。
【請求項９】
前記通信ネットワークは、ＩＭＳフレームワークを含む、請求項７に記載のシステム。
【請求項１０】
前記サービス要求は、呼セッション制御機能を含む、請求項７に記載のシステム。
【請求項１１】
前記ゲートウェイ層は、前記サービス要求を事象データ記録に変換し、前記事象データ記録を前記収益捕捉層に送るように適合されている、請求項７に記載のシステム。
【請求項１２】
前記ゲートウェイ層は、複数のパイプラインのうちの１つを介して前記事象データ記録を前記収益捕捉層に送り、前記複数のパイプラインのうちの１つは、要求された前記サービスおよび要求タイプに基づいて、前記複数のパイプラインから選択される、請求項１１に記載のシステム。
【請求項１３】
前記複数のパイプラインの各々は、前記収益捕捉層のアプリケーションプログラムインターフェイスを呼出すように適合されたモジュールを含む、請求項１２に記載のシステム。
【請求項１４】
前記収益捕捉層は、さらに事象を評価するように適合されている、請求項７に記載のシステム。
【請求項１５】
前記収益捕捉層は、さらにトランザクションを記録するように適合されている、請求項７に記載のシステム。
【請求項１６】
前記収益捕捉層は、前記ゲートウェイ層と通信するように結合されて、かつ、アプリケーションプログラムインターフェイス（Application Program Interface）（ＡＰＩ）を与える接続マネージャをさらに含む、請求項７に記載のシステム。
【請求項１７】
前記収益捕捉層は、前記ＡＰＩを介して、前記ユーザの認証および要求された前記サービスの許可の要求を前記ゲートウェイ層から受取る、請求項１６に記載のシステム。
【請求項１８】
前記接続マネージャは、要求のタイプに基づいて要求をルーティングするように適合されている、請求項１６に記載のシステム。
【請求項１９】
前記要求のタイプは非リアルタイム要求を含み、前記要求をルーティングすることは、前記要求をバックエンドデータベースにルーティングすることを含む、請求項１８に記載のシステム。
【請求項２０】
前記要求のタイプはリアルタイム要求を含み、前記要求をルーティングすることは、前記要求を高速のインメモリキャッシュにルーティングすることを含む、請求項１８に記載のシステム。