(57)【要約】  本発明は、課金情報を生成するために、インターネットプロトコルマルチメディアシステム呼の複数のネットワーク要素から呼データ記録を集めて調整するための装置および方法に関する。事前請求書作成機は、統合された課金記録を格納して、課金データ記録を完了するために課金情報を取得するために、評価エンジンにアクセスする。有利なことに、複数のネットワーク要素からの情報は、結合された課金データ記録に統合される。
2010532105.tif 000002
【特許請求の範囲】
【請求項１】
電気通信ネットワークにおいて、オンラインおよびオフラインで請求される電気通信呼の処理を実行する装置であって、
複数のネットワーク要素を含む電気通信呼セッションの受信に応答して、呼コストデータが欠如している複数の課金データ記録を生成するための手段と、
前記欠如している呼コストデータを提供するための課金ゲートウェイ機能に、前記課金データ記録を送信するための手段と、
事前請求書作成モジュール、課金データ記録ルーティングおよびフィルタリングモジュール、ならびに課金データ記録相関機能を備える前記課金ゲートウェイ機能と、
１つの呼に属するすべての課金データ記録を単一の課金データ記録に集めるための前記課金データ記録相関機能と、
評価情報が必要かどうかを決定して、前記事前請求書作成モジュールに前記評価情報を要求するように要求するための前記ルーティングおよびフィルタリングモジュールと、
評価エンジンに評価情報を要求して、前記評価情報の受信に応答して前記課金データ記録を完了するための前記事前請求書作成モジュールと、
完了した課金データ記録を、請求システムの適切なファイルにルーティングするための前記ルーティングおよびフィルタリングモジュールとを備える、装置。
【請求項２】
即時料金を集めるためのアプリケーションサーバに、課金データをルーティングするための手段をさらに備える、請求項１に記載の装置。
【請求項３】
前記評価エンジンが前記請求システム内にある、請求項１に記載の装置。
【請求項４】
前払いおよび後払い課金記録をリアルタイムで生成するためのオンライン課金システムをさらに備える、請求項１に記載の装置。
【請求項５】
前記評価エンジンが前記オンライン課金システム内にある、請求項４に記載の装置。
【請求項６】
前記評価エンジンが独立型ユニットである、請求項１に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のための、課金機能を実行するための方法および装置に関する。
【背景技術】
【０００２】
本明細書では、例として第３世代電気通信システムを使用して、課金収集機能を向上させるための方法および装置を説明する。
【０００３】
ＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）として知られている、第３世代パートナーシッププロジェクト（３ＧＰＰ）および第３世代パートナーシッププロジェクト２（３ＧＰＰ２）の調和努力の導入により、ＩＰベースの信号プロトコルおよびベアラ接続に基づく新しい統合ネットワーク要素が導入された。電気通信のための、調和がとれた無線および有線のＩＰベース制御ネットワークを作成することが目的である。ＩＭＳネットワーク要素には、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービスＣＳＣＦ（Ｓ−ＣＳＣＦ）、メディアゲートウェイ制御機能（ＭＧＣＦ）、ブレークアウトゲートウェイ制御機能（ＢＧＣＦ）、メディアリソース機能コントローラ（ＭＲＦＣ）、およびアプリケーションサーバ（ＡＳ）がある。統合されたＩＭＳネットワーク内で課金機能を実行するために、それぞれのネットワーク要素は、課金収集機能（ＣＣＦ）と呼ばれる新しい要素への、定義されたインタフェースを有する。３ＧＰＰ（リリース５）および３ＧＰＰ２規格文書で定義されたＣＣＦは、ＩＭＳネットワーク内のオフライン課金ネットワーク要素である。ＣＣＦは、セッション課金情報をＩＭＳ要素から収集して、課金データ記録（ＣＤＲ）を構築およびフォーマットする。ＣＣＦは中間データ記憶バッファリングを提供して、課金情報をオペレータの請求システム（ＢＳ）に転送するためのメカニズムを提供する。
【０００４】
ＣＣＦは、ＩＭＳのために、ＩＭＳ要素からオペレータが選択した請求システムに課金情報を転送するためのメカニズムを提供する。ＣＣＦはＩＭＳ要素からのセッション課金情報の収集を担う。ＣＣＦは中間データ記憶装置としても働くことができるので、使用プロファイルがあれば、ＣＤＲの記憶を特定期間サポートする必要がある。さらに、３ＧＰＰ規格におけるＣＣＦは、ＡＳＮ．１（抽象構文記法１）ベースの課金詳細記録を作成しなければならない。これらのＣＤＲは、通常ＦＴＰ（ファイル転送プロトコル）を使用して、ＢＳ／ＢＭＤ（請求仲介装置）に転送されるが、他のプロトコルおよび転送方法も可能である。ＣＣＦは、ほぼリアルタイムモードで、ＩＭＳ要素からデータを受信できる。ＣＣＦは、収集した課金データをＢＳにファイルモードで転送することを可能にするために、十分な記憶領域を有するべきである。ＣＣＦは、ＢＳへのいくつかの転送プロトコルをサポートできる。ＣＣＦの目的の１つは、ＢＳと、課金データを送信するＩＭＳ要素との間の異なるインタフェースの数を減らすことである。
【０００５】
ＩＭＳシステムでは、オンライン課金サーバ（ＯＣＳ）によってオンライン課金が行われる。ＩＭＳ要素は、課金情報についてＯＣＳにリアルタイムで問い合わせる。ＯＣＳは、組み込まれている評価エンジンで呼を評価して、セッションについてのクレジット制御を提供する。ＯＣＳは、呼が終了すると、ＣＤＲも生成する。ＯＣＳは、前払いおよび後払いモードの両方をサポートできる。
【０００６】
３ＧＰＰおよび３ＧＰＰ２は、回線交換およびパケット交換ネットワークを含む第３世代ネットワーク全体に、前述のＩＭＳ課金アーキテクチャを生成している。
【０００７】
しかし、ＣＣＦにおける課金および評価の概念をサポートする規格がない（３ＧＰＰにも３ＧＰＰ２にも）ので、ＣＤＲにおける呼のコストを提供できない。すべての評価および請求情報は、バックオフィス請求システムで処理されなければならない。これにより、ＩＭＳ／ＣＣＦの機能が後払いおよびオフライン請求のみに限定されてしまう。
【０００８】
２００６年３月７日に発行された米国特許第７０１０１０４号明細書は、ＣＣＦ内に存在する事前請求書作成機の予備概念に関する。ＣＣＦは、課金データ記録（ＣＤＲ）から課金情報を収集でき、呼を評価するために、どの評価エンジンにもＤｉａｍｅｔｅｒ  Ｒｏクレジット制御要求（ＣＣＲ）メッセージを構築できる。事前請求書作成機は、受信した呼のコストを、請求システムによってプル配信されうるＣＤＲ内の新しいパラメータとして挿入することになる。しかし、この特許は、いつおよびどのように事前請求書作成機能が動作および実行されうるか、ならびにどのＣＤＲが事前請求書作成機を介して評価されうるかに関する情報を提供しない。
【０００９】
ＩＭＳオフライン課金アーキテクチャは、３ＧＰＰリリース６およびリリース７規格で変更される。ＣＣＦ機能は課金データ機能（ＣＤＦ）および課金ゲートウェイ機能（ＣＧＦ）にアップグレードされる。ＣＤＦは、ネットワーク要素とインタフェースして、Ｄｉａｍｅｔｅｒ  Ｒｆメッセージを介して課金情報を受信し、ネットワーク要素ごとにセッション（呼）ごとの課金データ記録（ＣＤＲ）を作成するので、セッションごとに複数のＣＤＲをもたらす。多くのネットワーク要素がセッションに関与でき、すべてのネットワークが課金情報をＣＤＦに送信する。ＣＧＦは、ＣＤＲを再処理して格納するための、ＣＤＦとＢＳ／ＢＭＤとの間のゲートウェイである。
【００１０】
従来技術の問題点は、ネットワーク要素は課金情報をＩＭＳネットワーク内の複数のＣＣＦに送信する場合があるので、ＣＣＦベースの事前請求書作成機は１つのセッション内の複数のＣＤＲを相互に関連付けることができないという点である。ＣＣＦベースの事前請求書作成機は、呼を評価するためにＯＣＳへの正確なＣＣＲメッセージを構築するために、１つのＣＤＲから十分な課金情報を有しない場合がある。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】米国特許第７０１０１０４号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１２】
出願人は、従来技術を慎重に検討し、より緊密に統合されたシステムが商業上望ましいだろうという結論を下した。ＣＧＦが、任意選択で、１つのセッション（呼）内の複数のＣＤＲを、事前請求書作成機が呼を評価するための完全な課金情報を含む単一のＣＤＲと相互に関連付けることができる場合、ＣＧＦは事前請求書作成機能を実装するための自然な場所になるべきである。また、ポリシー管理規則に基づいて、どのＣＤＲ（相互に関連しない、または相互に関連する）が呼コストに挿入されるべきかを、ＣＧＦ  ＣＤＲファイルフィルタリング機能が決定する。
【課題を解決するための手段】
【００１３】
したがって、出願人は、ＩＭＳ電気通信セッションに含まれる個々のネットワーク要素によって生成された様々な課金データ記録をまとめるために、課金ゲートウェイ機能（ＣＧＦ）を使用して、ＩＭＳのために課金処理を統合するための、および、呼を評価するためにこれらの課金データ記録を事前請求書作成機からオンライン課金システムまたは請求システムに送信するための、方法および装置を発明した。有利なことに、この構成が１つのセッションについてのすべての課金データをまとめ、統合処理において呼の評価および請求をする。
【００１４】
出願人の発明の１つの好ましい実施形態によれば、課金データ記録相関機能は、呼セッションのすべての課金データ記録を集め、課金データ記録フィルタリングおよびルーティング機能の制御下で、これらの記録を事前請求書作成機に送信するか、評価の必要がない場合は請求システムに直接送信する。事前請求書作成機は、評価要求を、オンライン課金システム内の評価エンジン、請求システム内の評価エンジン、または独立型評価エンジンに送信する。評価エンジンは呼を評価して、評価結果（呼コスト）を事前請求書作成機に返信する。事前請求書作成機は呼コストをＣＤＲに挿入する。課金データ記録フィルタリングおよびルーティング機能の制御下で、評価されたＣＤＲは選択された適切なファイル管理システムにルーティングされ、請求システムまたは他の仲介装置にプル／プッシュ配信されることになる。
【００１５】
従来技術のＣＣＲはクレジット制御要求（事前請求書作成機からＯＣＳへのＤｉａｍｅｔｅｒ  Ｒｏメッセージ）である。従来技術では、ＣＣＦ内の事前請求書作成機が、ＣＤＲからの課金情報を使用してＣＣＲメッセージを構築する。本発明では、ＣＧＦ内の事前請求書作成機能が、相互に関連するＣＤＲからの課金情報を使用してＣＣＲメッセージを構築する。ＣＣＲ自体に変更はないが、ＣＣＲメッセージ内に含まれる課金情報はより複雑である。
【図面の簡単な説明】
【００１６】
【図１】出願人の発明の動作を示すブロック図である。
【図２】呼についての課金記録の処理を示す流れ図である。
【発明を実施するための形態】
【００１７】
図１は、出願人の発明の動作を示すブロック図である。１つまたは複数のネットワーク要素１０１で、呼セッションが開始される。ネットワーク要素には、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービスＣＳＣＦ（Ｓ−ＣＳＣＦ）、メディアゲートウェイ制御機能（ＭＧＣＦ）、ブレークアウトゲートウェイ制御機能（ＢＧＣＦ）、メディアリソース機能コントローラ（ＭＲＦＣ）、およびアプリケーションサーバ（ＡＳ）がある。
【００１８】
それぞれのネットワーク要素は、Ｒｆインタフェース１０５を介して課金データ機能（ＣＤＦ）１０９に報告を行う。課金データ機能は、１つのセッション（呼）内の課金ゲートウェイ機能（ＣＧＦ）１２０に渡されるそれぞれのネットワーク要素について、課金データ記録１１４を生成する。ＣＧＦは、１つまたは複数のＣＤＦから複数のＣＤＲを受信できる。
【００１９】
課金ゲートウェイ機能には、セッション（呼）に関連するすべての課金データ記録を集めるための課金データ記録相関機能があり、ＣＤＦは１つのセッションにつき複数のＣＤＲを生成できるが、これにはＣＧＦが複数のＣＤＲを単一のＣＤＲと相互に関連付けることが必要である。課金ゲートウェイ機能は、このようなそれぞれの単一のＣＤＲを適切に取り扱うための、課金データルーティングおよびフィルタリング機能１２２も含む。呼コストの決定を必要とするそれらの課金データ記録は、フィルタリングおよびルーティング機能モジュールによって見つけられ、評価エンジン応答を取得するために必要なタイミングの表示とともに事前請求書作成機１２４に送信される。事前請求書作成機はＤｉａｍｅｔｅｒ  Ｒｏインタフェース１２６を介して、請求システム内に位置されうる評価エンジン１２８、またはＯＣＳ内の評価エンジン１２９、あるいは独立型評価エンジン１２７と通信する。
【００２０】
事前請求書作成機の機能は、呼コスト情報を提供すること、および適切な時間に、呼コスト情報を含む課金データ記録を、請求明細書のために適切なサブディレクトリおよび／または適切な周辺装置に渡すことである。
【００２１】
ネットワーク要素は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービスＣＳＣＦ（Ｓ−ＣＳＣＦ）、メディアゲートウェイ制御機能（ＭＧＣＦ）、ブレークアウトゲートウェイ制御機能（ＢＧＣＦ）、メディアリソース機能コントローラ（ＭＲＦＣ）、およびアプリケーションサーバ（ＡＳ）などの、物理的、またはプログラム制御された機能（非物理的）エンティティである。Ｒｆインタフェースは、オフライン課金のためのＤｉａｍｅｔｅｒ基準点である。課金データ機能は、ＩＭＳ課金システム内に物理的に実装されたソフトウェアモジュールである。課金ゲートウェイ機能は、ＩＭＳ課金システム内に実装されたソフトウェアモジュールである。課金ゲートウェイ機能は、課金データ記録相関機能、呼データ記録ルーティングおよびフィルタリングモジュール、ならびに事前請求書作成機も実装する。Ｄｉａｍｅｔｅｒ  Ｒｏインタフェースは、オンライン課金のための基準点である。評価エンジンは、特定の呼セッションについての料金を計算するための情報を提供するために便利な処理システム内に実装されたソフトウェアモジュールであり、その情報は基本料金、超過料金、およびビデオなどの特別なメディアサービスについての特別料金などの項目を含む。評価エンジンは、その呼セッションの当事者の個人情報および位置に基づいて、このような情報を提供できる。
【００２２】
オンライン課金システムは、前払いおよび後払い記録をリアルタイムで生成するための処理システムである。この実施形態では、オンライン課金システムは、呼のＣＤＲをオフライン課金するために、ＣＧＦの事前請求書作成機からＣＤＲを評価するための評価エンジン１２８も提供する。
【００２３】
オンライン課金システムは、１つまたは複数のアプリケーションサーバ１３２にも接続されうる。これらのアプリケーションサーバのうちの１つは、ほぼ即時の情報をホテル／モーテル課金システムに供給するために使用されうる。
【００２４】
図２は、関連するソフトウェアモジュールを含む、出願人の発明の動作を示す流れ図である。呼セッションが開始し、その呼セッションに関連するすべてのネットワーク要素が、Ｒｆメッセージを介して課金データ機能に課金情報を送信する（アクションブロック２０１）。課金データ機能は、１つまたは複数の課金データ記録を作成するが（アクションブロック２０３）、一般的に、その呼に含まれるそれぞれのネットワーク要素からの入力について１つの記録である。次いで、課金データ機能は、Ｇａインタフェースを介して課金データ記録を課金ゲートウェイ機能に送信する（アクションブロック２０５）。
【００２５】
課金ゲートウェイ機能内の課金データ記録相関機能は、呼に関連付けられるすべての課金データ記録を識別して、集める（アクションブロック２０７）。
【００２６】
課金ゲートウェイ機能フィルタリングおよびルーティングモジュールが、評価された呼データ記録が必要かどうかを決定する。ＣＤＲが評価されるべきかどうかをフィルター機能によって決定するための基本ルールには、以下のものがある：
１．呼のタイプ（たとえば、無料の呼（米国では８００呼）は評価される必要がない）、
２．サービスのタイプ（たとえば、より高い月額料金の代わりに無制限のローカルサービスを受信する局からのローカル呼）、
３．コンテンツのタイプ（たとえば、音声、ＳＭＳ／ＭＭＳ、ビデオ）、
４．アプリケーションサーバ情報（たとえば、テレホンカード、仮想プライベートネットワーク（ＶＰＮ）呼）、
５．メディア情報（たとえば、無線またはビデオ呼は通常評価される）、
６．呼び出す、および呼び出される当事者の数（たとえば、仮想プライベート回線サービスの呼は、通常評価される必要がない）、
７．即時請求呼（たとえば、ホテル／モーテルの呼は即時評価する必要がある）、
８．監視されている回線のための呼は評価されなければならない場合がある、
９．仮想移動体通信事業者（ＭＶＮＯ）の呼については、バックオフィス動作がＣＤＲをＣＧＦから直接プル配信し、そのＣＤＲを評価することができる。
【００２７】
評価が必要な場合、フィルタリングおよびルーティングモジュールは、その課金データ記録を事前請求書作成機に転送する（アクションブロック２０９）。
【００２８】
次いで、事前請求書作成機は、課金データ記録からＤｉａｍｅｔｅｒ  Ｒｏクレジット制御要求（ＣＣＲ）メッセージを構築して、これらのメッセージを返答のための時間制限の表示とともにオンライン課金システムに送信する（アクションブロック２１１）。評価情報は、基本料金、１分当たりの料金、およびセッションの特定のメディアについての特別料金などの情報を含む。オンライン課金システムは、ＣＣＲメッセージを処理し、評価エンジンに呼を評価するように要求する。オンライン課金システムは、時間制限内の評価を要求する（アクションブロック２１３）。次いで、オンライン課金システムは、Ｒｏクレジット制御応答メッセージ内で評価エンジンによって決定された結果コードおよび呼コストパラメータを事前請求書作成機に返す（アクションブロック２１５）。事前請求書作成機は、クレジット制御応答メッセージ内で検出される呼コストを、新しいフィールドとして課金データ記録に入れる（アクションブロック２１７）。事前請求書作成機は、評価された課金データ記録をフィルタリングおよびルーティングモジュールに転送する（アクションブロック２１９）。フィルタリングおよびルーティングモジュールは、課金データ記録がどのサブディレクトリにファイルされるべきかを決定して、課金データ記録をそのファイルに向かってルーティングする（アクションブロック２２１）。次いで、課金データ記録ファイルは、所与の時間間隔内に請求ドメインまたは請求システムによってプッシュ／プル配信されることになる（アクションブロック２２３）。次いで、請求ドメインまたは請求システムは、非リアルタイムモードで、特定の顧客に関連付けられる呼データ記録の呼コストに基づいて請求書を生成する。場合によっては、課金データ記録ファイルは、請求明細書を生成するためにＣＤＲを処理するアプリケーションサーバに送信されることになり、たとえばホテル／モーテル請求アプリケーションサーバは、請求明細書を生成するためにＣＤＲをほぼリアルタイムモードで処理する。
【００２９】
場合によっては、フィルタリング機能が複数のディレクトリ内にＣＤＲをファイルすることがある。たとえば、呼が有線および無線接続を含む場合、両方のサブファイルでエントリが必要とされることがある。
【００３０】
上記の説明は、出願人の発明の１つの好ましい実施形態の説明である。
【図１】
2010532105.tif 000003
【図２】
2010532105.tif 000004
【国際調査報告】
2010532105.tif 000005
2010532105.tif 000006