(57)【要約】ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するように構成される受信手段と、受信アカウントリクエストに基づいて、オンラインアカウント残高メッセージを更なる別個のサーバーに送信するように構成される送信手段とを備えるオンライン課金管理サーバー。【選択図】図２
2009500935.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するように構成される受信手段と、
前記受信アカウントリクエストに基づいて、オンラインアカウント残高メッセージを更なる別個のサーバーに送信するように構成される送信手段と、を備えるオンライン課金管理サーバー。
【請求項２】
前記オンラインアカウント残高メッセージは、オンラインアカウント残高リクエストメッセージである、請求項1に記載のサーバー。
【請求項３】
前記オンラインアカウント残高リクエストメッセージは、
・  予約を行う、
・  予約を確定して新しい予約を行う、
・  予約を確定する、
・  予約を解除する、
・  残高問い合わせ、
・  残高増額、および
・  残高減額、
のうちの少なくとも１つのためのリクエストを含む、請求項2に記載のサーバー。
【請求項４】
前記受信手段は、前記更なるサーバーからのオンラインアカウント残高メッセージを受信するようにさらに構成される、請求項1乃至3に記載のサーバー。
【請求項５】
前記更なるサーバーからの前記オンラインアカウント残高メッセージは、オンラインアカウント残高回答メッセージである、請求項4に記載のサーバー。
【請求項６】
前記オンラインアカウント残高回答メッセージは、前記オンラインアカウント残高リクエストメッセージに基づいた値を含む、請求項5に記載のサーバー。
【請求項７】
前記オンラインアカウント残高メッセージは、Diameterメッセージである、請求項1および4に記載のサーバー。
【請求項８】
前記オンラインアカウント残高メッセージは、Diameterクレジット制御メッセージ（Diameter credit control message）である、請求項7に記載のサーバー。
【請求項９】
前記サーバーは、評価サーバーである、請求項1乃至8に記載のサーバー。
【請求項１０】
オンライン課金アカウント管理サーバーであって、
少なくとも１つの更なる別個のサーバーからのオンラインアカウント残高メッセージを受信し、前記オンラインアカウント残高メッセージが、ネットワークサービスプロバイダから送信されて受信したアカウントリクエストメッセージに基づくものである、受信手段と、
前記受信したオンラインアカウント残高メッセージに基づいて、オンラインアカウント残高アクションを実行するように構成される処理手段と、
を備えるオンライン課金アカウント管理サーバー。
【請求項１１】
オンラインアカウント残高メッセージを前記更なるサーバーに送信するように構成される送信手段をさらに備える、請求項10に記載のサーバー。
【請求項１２】
前記オンラインアカウント残高メッセージは、オンラインアカウント残高リクエストメッセージである、請求項10および11に記載のサーバー。
【請求項１３】
前記オンラインアカウント残高リクエストメッセージは、
・  予約を行う、
・  予約を確定して新しい予約を行う、
・  予約を確定する、
・  予約を解除する、
・  残高問い合わせ、
・  残高増額、および
・  残高減額、
のうちの少なくとも１つのためのリクエストを含む、請求項12に記載のサーバー。
【請求項１４】
前記更なるサーバーに送信される前記オンラインアカウント残高メッセージは、オンラインアカウント残高回答メッセージである、請求項11に記載のサーバー。
【請求項１５】
前記オンラインアカウント残高回答メッセージは、前記実行されたアクションに基づいて、前記処理手段によって決定された値を含む、請求項14に記載のサーバー。
【請求項１６】
請求項1乃至9に記載のオンライン課金管理サーバーと、
請求項10乃至15に記載の別個のオンライン課金アカウント管理サーバーと、を備えるシステム。
【請求項１７】
オンライン課金管理サーバーと、別個のオンライン課金アカウント管理サーバーとを備えた通信ネットワーク内で、オンライン課金を実行するための方法であって、
前記オンライン課金管理サーバーにおいて、ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するステップと、
前記受信したアカウントリクエストメッセージに基づいて、前記オンライン課金管理サーバーから前記別個のオンライン課金アカウント管理サーバーへ、オンラインアカウント残高メッセージを送信するステップと、
を含む方法。
【請求項１８】
前記別個のオンライン課金アカウント管理サーバーにおいて、前記オンラインアカウント残高メッセージを受信するステップと、
前記別個のオンライン課金アカウント管理サーバーにおいて、前記受信したオンラインアカウント残高メッセージに基づいて、少なくとも１つのアカウント管理機能を実行するステップと、
をさらに含む請求項17に記載の方法。
【請求項１９】
前記少なくとも１つのアカウント管理機能を実行するステップに基づいて、前記別個のオンライン課金アカウント管理サーバーから前記オンライン課金管理サーバーへ、オンラインアカウント残高メッセージを送信するステップをさらに含む、請求項18に記載の方法。
【請求項２０】
オンライン課金管理サーバーと、別個のオンライン課金アカウント管理サーバーとを備えた通信ネットワーク内で、オンライン課金を実行するための方法を実行するように構成されるコンピュータプログラムであって、前記方法は、
前記オンライン課金管理サーバーにおいて、ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するステップと、
前記受信したアカウントリクエストメッセージに基づいて、前記オンライン課金管理から前記別個のオンライン課金アカウント管理サーバーへ、オンラインアカウント残高メッセージを送信するステップと、を含むコンピュータプログラム。
【請求項２１】
前記別個のオンライン課金アカウント管理サーバーにおいて、前記オンラインアカウント残高メッセージを受信するステップと、
前記別個のオンライン課金アカウント管理サーバーにおいて、前記受信したオンラインアカウント残高メッセージに基づいて、少なくとも１つのアカウント管理機能を実行するステップと、を実行するようにさらに構成される、請求項20に記載のコンピュータプログラム。
【請求項２２】
前記少なくとも１つのアカウント管理機能を実行するステップに基づいて、前記別個のオンライン課金アカウント管理サーバーから前記オンライン課金管理サーバーへ、オンラインアカウント残高メッセージを送信するステップを実行するようにさらに構成される、請求項21に記載のコンピュータプログラム。
【請求項２３】
オンライン課金アカウント管理サーバー及びオフライン課金アカウント管理サーバーを備える、オンライン課金及びオフライン課金のための複合機能サーバーであって、前記オンライン課金アカウント管理サーバーが、
少なくとも１つの更なる別個のサーバーからのオンラインアカウント残高メッセージを受信し、ここで前記オンラインアカウント残高メッセージは、ネットワークサービスプロバイダから送信されて受信したアカウントリクエストメッセージに基づくものである、受信手段と、
前記受信したオンラインアカウント残高メッセージに基づいて、オンラインアカウント残高アクションを実行するように構成される処理手段と、
を備える、複合機能サーバー。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン課金管理サーバーに関し、特に、これに限定されないが、無線携帯電話ネットワークのための前払い機能を提供するオンライン課金管理サーバーに関する。
【背景技術】
【０００２】
通信システムとは、ユーザー端末機器および/またはネットワークエンティティのような２つ以上のエンティティと、通信システムに関連する他のノードとの間の通信を可能にする設備である。通信には、例えば、音声、電子メール（Eメール）、テキストメッセージ、データ、マルチメディアなどの通信を含めることが可能である。
【０００３】
通信は、固定回線および/または無線通信インターフェースによって提供することが可能である。無線通信システムの機能は、システムがモビリティをそのユーザーに提供することである。無線通信を提供する通信システムの一例には、公衆陸上モバイルネットワーク（public land mobile network：PLMN）がある。固定回線システムの一例には、公衆交換電話網（public switched telephone network：PSTN）がある。
【０００４】
通信システムは、一般的に、システムの種々の要素が実行を許可されたもの、およびどのように達成すべきかを定めた規格または仕様に従って動作する。例えば、規格または仕様は、ユーザー、より詳しくはユーザー機器が、回路交換サーバーか、パケット交換サーバーか、またはその両方を備えている場合に規定することが可能である。接続に使用すべき通信プロトコルおよび/またはパラメータも、一般的に規定される。例えば、ユーザー機器と通信ネットワークの要素との間に、どのように通信を実装すべきかという様態は、一般的に、所定の通信プロトコルに基づいている。すなわち、通信がベースとすることができる特定の一連の"ルール"は、ユーザー機器が、通信システムを経て通信できるように規定する必要がある。
【０００５】
３G（Third Generation：第三世代）の導入によって、モバイルのユーザー機器（user equipment：UE）および他のタイプのUEを経て、インターネットのサービスにアクセスする可能性が著しく高められる。
【０００６】
コンピュータ（固定または携帯型）、携帯電話のような種々のユーザー機器（UE）、携帯情報端末、またはオーガナイザなどは、当業者には既知であり、これを使用してインターネットにアクセスしてサービスを得ることができる。移動局（mobile station：MS）と称されるモバイルユーザー機器は、無線インターフェースを経て、モバイル通信ネットワークの基地局、または他の局のような別のデバイスと通信することができる手段として定義することができる。
【０００７】
上述の、および以下に使用される"サービス"という用語は、ユーザーが望む、必要とする、または備えているあらゆるサービスまたは品物を広範囲にカバーするものと理解されるべきものである。この用語は、無料サービスの提供もカバーするものと理解されるべきものである。特に、これに限定されないが、"サービス"という用語は、インターネットプロトコルマルチメディアIMサービス、会議、電話、ゲーム、リッチコール、プレゼンス、eコマース、およびメッセージング（例、インスタントメッセージング）を含むものと理解されるべきものである。"サービス"は、２つ以上の要素を備えることが可能である。例えば、テレビ電話サービスは、声要素とビデオ要素とを含む。別様には、２つ以上のサービスを同時に提供することが可能であり、例えば、ゲームサービスとチャットルームサービスとを同時に提供することが可能である。
【０００８】
第三世代パートナーシッププロジェクト（3G Partnership Project：3GPP）では、ユーザー機器UEのユーザーにこれらのサービスへのアクセスを提供する汎用移動体通信システム（Universal Mobile Telecommunication System：UMTS）コアネットワークのための、基準アーキテクチャを規定している。このUMTSコアネットワークは、３つの主要ドメインに分割される。これらは、回路交換ドメイン、パケット交換ドメイン、およびインターネットプロトコルマルチメディア（IM）ドメインである。
【０００９】
これらのうちの後者、IMドメインは、マルチメディアサービスが十分に管理されるようにする。IMドメインは、インターネット技術特別調査委員会（Internet Engineering Task Force：IETF）によって開発されたように、セッション開始プロトコル（Session Initiation Protocol：SIP）に対応する。
【００１０】
IMSおよび非IMSシステムに関連する管理の一側面（例えば、マルチメディアメッセージングおよび位置推定サービスなどの、コアネットワーク以外のサービスノードを経て加入者に提供されるサービス）は、サービスの提供に対してユーザーに課金するものである。課金は、２つの課金モードに分けることができる。その第一は、ユーザーがサービスに対して事実上前払いする場合のオンライン課金であり、第二は、ユーザーがセッションの後にサービスに対して請求される場合のオフライン課金である。したがって、第一の課金方法は、都度払いシステムによって行われ、一方で、第二の方法は、ユーザーが行った通話に対してユーザーに定期的に請求する場合に行われる。
【００１１】
現在、オンライン課金の場合、クレジット制御リクエストメッセージを、オンライン課金システム（Online Charging System：OCS）として既知の技術であるネットワーク要素に渡すには、ユーザーに課金しようとするあらゆるネットワーク機能が必要である。OCSのアーキテクチャを標準化する試みは、第三世代パートナーシッププロジェクト（3GPP）の技術仕様（TR）32.815のような規格において規定されている。さらに、OCSによって操作されるアプリケーションおよびいくつかのインターフェースは、3GPP TS 32.296によってさらに標準化されている。
【００１２】
現在これらの規格に用いられているようなOCSのアーキテクチャには、統合された（すなわちオンラインおよびオフラインの）課金システムを操作しようとするあらゆるオペレータに対する問題を有する。上述の規格に規定されているように、OCSは、アカウント残高管理システムによって操作されるアカウントデータベースを含んでいる。アカウント残高管理システムおよびOCS内のアカウントデータベースは、オフラインアカウンティングシステムのオペレータによって保持された情報の事実上の部分的重複である。
【非特許文献１】3GPP TR32.815
【非特許文献２】3GPP TS 32.296
【発明のまとめ】
【００１３】
本発明およびその実施形態の目的の一つは、オンラインアカウンティングシステムを改良することであって、その改良によって、そのようなシステムを動作させる中央集中型のアカウンティングを作り上げる可能性を提供する。
にある。
【００１４】
本発明によれば、ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するように構成される受信手段と、前記受信アカウントリクエストに基づいて、オンラインアカウント残高メッセージを更なる別個のサーバーに送信するように構成される送信手段と、を備えるオンライン課金管理サーバーが提供される。
【００１５】
前記オンラインアカウント残高メッセージは、オンラインアカウント残高リクエストメッセージとすることが可能である。
【００１６】
前記オンラインアカウント残高リクエストメッセージは、予約を行う、予約を確定して新しい予約を行う、予約を確定する、予約を解除する、残高問い合わせ、残高増額、および残高減額、のうちの少なくとも１つのためのリクエストを含むことが可能である。
【００１７】
前記受信手段は、前記更なるサーバーからのオンラインアカウント残高メッセージを受信するようにさらに構成することが可能である。
【００１８】
前記更なるサーバーからの前記オンラインアカウント残高メッセージは、オンラインアカウント残高回答メッセージとすることが可能である。
【００１９】
前記オンラインアカウント残高回答メッセージは、前記オンラインアカウント残高リクエストメッセージに基づいた値を含むことが可能である。
【００２０】
前記オンラインアカウント残高メッセージは、Diameterメッセージとすることが可能である。
【００２１】
前記オンラインアカウント残高メッセージは、Diameterクレジット制御メッセージとすることが可能である。
【００２２】
前記サーバーは、評価サーバーとすることが可能である。
【００２３】
本発明の第二の側面によれば、少なくとも１つの更なる別個のサーバーからのオンラインアカウント残高メッセージを受信し、前記オンラインアカウント残高メッセージが、ネットワークサービスプロバイダから送信されて受信したアカウントリクエストメッセージに基づくものである、受信手段と、前記受信したオンラインアカウント残高メッセージに基づいて、オンラインアカウント残高アクションを実行するように構成される処理手段と、を備えるオンライン課金アカウント管理サーバーが提供される。
【００２４】
前記サーバーは、オンラインアカウント残高メッセージを前記更なるサーバーに送信するように構成される送信手段をさらに備えることが可能である。
【００２５】
前記オンラインアカウント残高メッセージは、オンラインアカウント残高リクエストメッセージとすることが可能である。
【００２６】
前記オンラインアカウント残高リクエストメッセージは、予約を行う、予約を確定して新しい予約を行う、予約を確定する、予約を解除する、残高問い合わせ、残高増額、および残高減額、のうちの少なくとも１つのためのリクエストを含むことが可能である。
【００２７】
前記更なるサーバーに送信された前記オンラインアカウント残高メッセージは、オンラインアカウント残高回答メッセージとすることが可能である。
【００２８】
前記オンラインアカウント残高回答メッセージは、前記実行されたアクションに基づいて、前記処理手段によって決定された値を含むことが可能である。
【００２９】
システムは、上述のオンライン課金管理サーバーと、上述の別個のオンライン課金アカウント管理サーバーと、を備えることが可能である。
【００３０】
本発明の第三の側面によれば、オンライン課金管理サーバーと、別個のオンライン課金アカウント管理サーバーとを備えた通信ネットワーク内で、オンライン課金を実行するための方法であって、前記オンライン課金管理サーバーにおいて、ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するステップと、前記受信したアカウントリクエストメッセージに基づいて、前記オンライン課金管理サーバーから前記別個のオンライン課金アカウント管理サーバーへ、オンラインアカウント残高メッセージを送信するステップと、を含む方法が提供される。
【００３１】
前記方法は、前記別個のオンライン課金アカウント管理サーバーにおいて、前記オンラインアカウント残高メッセージを受信するステップと、前記別個のオンライン課金アカウント管理サーバーにおいて、前記受信したオンラインアカウント残高メッセージに基づいて、少なくとも１つのアカウント管理機能を実行するステップと、をさらに含むことが可能である。
【００３２】
前記方法は、前記少なくとも１つのアカウント管理機能を実行するステップに基づいて、前記別個のオンライン課金アカウント管理サーバーから前記オンライン課金管理サーバーへ、オンラインアカウント残高メッセージを送信するステップをさらに含むことが可能である。
【００３３】
本発明の第四の側面によれば、オンライン課金管理サーバーと、別個のオンライン課金アカウント管理サーバーとを備えた通信ネットワーク内で、オンライン課金を実行するための方法を実行するように構成されるコンピュータプログラムであって、前記方法は、前記オンライン課金管理サーバーにおいて、ネットワークサービスプロバイダから送信された少なくとも１つのアカウントリクエストメッセージを受信するステップと、前記受信したアカウントリクエストメッセージに基づいて、前記オンライン課金管理から前記別個のオンライン課金アカウント管理サーバーへ、オンラインアカウント残高メッセージを送信するステップと、を含むコンピュータプログラムが提供される。
【００３４】
前記コンピュータプログラムは、前記別個のオンライン課金アカウント管理サーバーにおいて、前記オンラインアカウント残高メッセージを受信するステップと、前記別個のオンライン課金アカウント管理サーバーにおいて、前記受信したオンラインアカウント残高メッセージに基づいて、少なくとも１つのアカウント管理機能を実行するステップと、をさらに実行することが可能である。
【００３５】
前記コンピュータプログラムは、前記少なくとも１つのアカウント管理機能を実行するステップに基づいて、前記別個のオンライン課金アカウント管理サーバーから前記オンライン課金管理サーバーへ、オンラインアカウント残高メッセージを送信するステップをさらに実行することが可能である。
【００３６】
本発明の第五の側面によれば、オンライン課金アカウント管理サーバー及びオフライン課金アカウント管理サーバーを備える、オンライン課金及びオフライン課金のための複合機能サーバーであって、前記オンライン課金アカウント管理サーバーが、少なくとも１つの更なる別個のサーバーからのオンラインアカウント残高メッセージを受信し、ここで前記オンラインアカウント残高メッセージは、ネットワークサービスプロバイダから送信されて受信したアカウントリクエストメッセージに基づくものである、受信手段と、前記受信したオンラインアカウント残高メッセージに基づいて、オンラインアカウント残高アクションを実行するように構成される処理手段と、
を備える、複合機能サーバーが提供される。
【好適な実施形態の説明】
【００３７】
本発明を、添付図面を参照して一例として説明する。
【００３８】
本発明は、複数の実施形態を参照して本願明細書に一例として説明される。
【００３９】
図１を参照する。図１は、本発明の実施形態を実装することができるシステムを概略的に示す図である。システムは、ユーザー機器2を備える。ユーザー機器2は、あらゆる好適な形態とすることができ、例えば、携帯電話、携帯情報端末（personal digital assistant：PDA）、ポータブルコンピュータ、ラップトップコンピュータ、固定コンピュータ、または他の好適なデバイスのような、モバイルまたは固定エンティティとすることが可能である。ユーザー機器2は、無線接続を経て、無線アクセスネットワーク（radio access network：RAN）と通信するように構成される。この無線接続は、任意の好適な周波数（例、無線周波数）で動作することが可能である。
【００４０】
無線アクセスネットワーク8は、一般的に、基地局エンティティ（ノードBとも称される）から構成される。本文書では、基地局という用語を使用し、あらゆる好適なエンティティをカバーすることを意図する。無線アクセスネットワーク8は、制御要素も備える。規格に従って、制御要素は、UMTSシステムの場合には無線ネットワークコントローラ（radio network controller：RNC）と称し、GSMシステムの場合には基地局コントローラ（base station controller：BSC）と称することができる。コントローラという用語は、あらゆるこのような制御エンティティをカバーすることを意図するものである。いくつかの機構では、制御機能は、基地局機能から別々に提供され、単一の制御エンティティが複数の基地局を制御することが可能である。本発明の他の実施形態では、各基地局は、制御機能の一部を組み込むことが可能である。
【００４１】
無線アクセスネットワークは、コアネットワーク10と通信するように構成される。図１内に示されるコアネットワーク10は、パケット交換コアネットワークである。コアネットワークは、パケット交換トランザクションの変更に使用される少なくとも１つのサービングGPRS（general packet radio service：汎用パケット無線システム）サポートノードSGSNと、コアネットワーク10が外部パケット交換ネットワークに接続されるポイントでのスイッチである少なくとも１つのGPRSサポートノードGGSNとを備える。
【００４２】
コアネットワークは、IM（IPマルチメディア）サブシステム14に接続される。GGSNは、IMS 14内のP-CSCF 16（proxy call session control function：プロキシ呼セッション制御機能）に接続される。P-CSCFは、（S-CSCF（サービングCSCF）24に接続される。S−CSCFは、終端ネットワーク内でI（問い合わせ）−CSCF 22と交信する。I-CSCF 22は、着呼者であるエンドユーザーに対する適切な（S-CSCF（サービングCSCF）24を決定するように構成される。
【００４３】
図１は、発呼者を示す。着呼者は、異なるか、または同じIMSに接続することが可能である。同様に、着呼者は、同一の、または異なるOCSに接続することが可能である。着呼者が異なるIMSに接続されている場合、異なるコアネットワークおよびRANが提供される。IMSが同じである場合、異なるコアネットワークを必要とするか、または必要としない場合がある。同様に、RANは、着呼者に対して、発呼者と同じかまたは異なるRANとすることが可能である。
【００４４】
上述の実施例における本発明の説明を簡素化するためにIMS 14をOCS 6に接続して示してあるが、当業者は、OCS 6も他の非IMSネットワーク要素によって操作することができるものと理解されるべきものである。特に、3GPPは、OCS 6にメッセージを通信することができる、３つのタイプのプロトコルメッセージを規定している。図１に示される第一のタイプのメッセージは、3GPP仕様においてR0インターフェースで定義されるIMSオンライン課金の基準ポイントである。図１には示されないが、第二のタイプのメッセージは、マルチメディアメッセージサービス、WLAN、およびR0'インターフェースのような3GPP仕様に規定されたゲートウェイGPRSサービングノード（GGSN）のような、非IMSサービスに対するオンライン課金参照ポイントのためのものである。これも図１には示されないが3GPP仕様には規定されている、第三のタイプのメッセージは、モバイル交換局（Mobile Switching Centre：MSC）およびサービングGPRSサービングノード（SGSN）のようなネットワーク要素から送信することができる、モバイルネットワーク用拡張ロジックのためのカスタマイズアプリケーション（Customised Application for Mobile network Enhanced Logic：CAMEL）のアプリケーション部分（CAMEL Application Part：CAP）である。
【００４５】
図２を参照する。図２は改良されたOCS 106を示す図である。改良されたOCS 106は、少なくとも２つの物理的に独立したサーバーを備える。第一のサーバーはアカウント残高管理サーバー103であり、第二のサーバーは課金および評価サーバー101である。
【００４６】
アカウント管理サーバー（アカウント残高管理サーバーとしても知られている） 103は、課金および評価要素とメッセージをやりとりするように構成されるアカウント残高管理機能を備える。さらに、アカウント残高サーバー103は、アカウント残高管理機能がアクセスすることのできるアカウントデータ111を含む。
【００４７】
アカウント残高サーバーは、再課金サーバー3に接続されるようにさらに構成される。再課金サーバーは、アカウントデータ111によって格納されるアカウント値を再課金するように使用される。したがって、例えば、ユーザーアカウントがクレジットに関して低い場合（クレジットとは、例えば、通貨、帯域幅利用時間、またはデータ送信の有効性である）、リチャージサーバーは、メッセージをアカウント残高管理サーバー103に渡して、このようなアカウントを'補充する'ことができる。
【００４８】
課金および評価サーバー（オンライン課金管理サーバーとしても知られている）は、オンライン課金機能（online charging function：OCF） 151と、課金ゲートウェイ機能161と、および評価機能171とを備える。OCF自体は、当技術分野で既知のように、IMS呼セッション制御機能（CSCF）からのクレジット制御メッセージの受信に課金するIMSセッションの実行に使用されるセッションベースの課金機能153と、R0またはR0'インターフェースクレジット制御メッセージを使用したイベントベースの課金を実行するイベントベースの課金機能155とを備える。図２には示されていないが、OCF 151は、更なる実施形態では、ベアラベースの課金機能を備えることができる。ベアラベースの課金機能は、CAPプロトコルメッセージタイプを使用したベアラベースの課金を実行するように構成される。
【００４９】
OCF 151およびオペレータのポスト処理システム5に接続された課金ゲートウェイ機能161は、OCF 151によって使用されて、課金情報を収集し、オペレータポスト処理システム5に送信する。
【００５０】
評価機能171は、OCF 151に接続され、OCF 151によって使用されて、利用可能なサービスのタリフおよび評価を導出する。評価機能171の機能は、複数のセッション関連の非貨幣ユニット（サービスユニット、データ量、時間、およびイベント）のユニット決定、計算、および予約、価格決定（所与数の非貨幣ユニットに対する貨幣ユニットの計算）、タリフ決定（加入者契約条項およびリクエストされたサービスに基づいたタリフ情報の決定）、および評価に適用可能なゲット/セットカウンタのうちの１つとして、3GPP TR 32.815に明確に規定されている。
【００５１】
アカウント残高管理サーバー103および課金および評価サーバー101の相互作用に関して、一組のアカウント残高リクエスト（account balance request：ABR）およびアカウント残高回答（account balance answer：ABA）メッセージを以下に開示する。
【００５２】
ABRメッセージのテンプレートを以下に示す。
ABR：
＜セッションId＞
｛Diameterベースにあるような通常のルーチングベースの情報｝
｛アカウント残高アクション｝
｛アカウント残高リクエスト番号｝
｛ユーザー名／アカウントId｝
［リクエストされたサービスユニット］
［使用したサービスユニット］
【００５３】
フィールド＜セッションId＞は、OCF 151によって提供される一意のセッション番号であり、フィールド｛アカウント残高アクション｝は、アカウント残高管理サーバー103からリクエストされたアクションを表す。フィールド｛アカウント残高リクエスト番号｝は、課金および評価サーバー101からアカウント残高管理サーバー103への特定のリクエストを識別する番号である。フィールド｛ユーザー名／アカウントId｝は、アカウント残高管理サーバー103内に格納されたアカウントコードに対するサービスをリクエストするユーザーにリンクする識別子である。フィールド［リクエストされたサービスユニット］は、ユーザーがサービスをリクエストしたネットワーク要素を提供するサービスを識別する。フィールド［使用したサービスユニット］は、すでにユーザーにサービスを提供したネットワーク要素を提供するあらゆるサービスを識別する。
【００５４】
また、ABAメッセージのテンプレートを以下に示す。
ABA：
＜セッションId＞
｛Diameterベースにあるような通常のルーチングベースの情報｝
｛アカウント残高アクション｝
｛アカウント残高リクエスト番号｝
｛ユーザー名／アカウントId｝
［許可されたサービスユニット］
【００５５】
唯一追加されたフィールドは［許可されたサービスユニット］であり、これは、アカウント残高管理サーバーが実行したアクションに基づいて、アカウント残高管理サーバー103によって特定された値を識別する識別子である。
【００５６】
さらに、アカウント残高アクションAVPフィールドは、以下の値を有する。
1   予約を行う
2   予約を確定して新しい予約を行う
3   予約を確定する
4   予約を解除する
5   残高問い合わせ
6   残高増額
7   残高減額
【００５７】
オンライン課金管理サーバーを、上述のメッセージによって通信するオンライン課金管理と、オンライン課金アカウント残高管理サーバーとに分けることによって、オンライン課金アカウント残高管理サーバーの機能を複合オンラインおよびオフラインアカウント残高管理サーバーに組み込むことが可能であり、その結果、オンラインおよびオフラインのアカウントを有するユーザー間で、アカウントおよびデータが重複するという問題が解決される。
【００５８】
これらの値を受けたときのアカウントおよび残高管理サーバー103のオペレーションを、図３乃至9を参照して以下にさらに開示する。これらの図を参照して説明される実施例は、ユーザー機器2の簡略化したネットワークアーキテクチャと、ネットワーク要素51（図１による実施例では、IMS 14内に存在しうるが、同様に、先に説明したネットワーク要素のいずれかとすることが可能である）と、OCF 151と、アカウント残高管理サーバー111とを備える。
【００５９】
図３を参照する。図３には、これらのアカウント残高リクエスト（ABR）およびアカウント残高回答（ABA）メッセージの使用する第一の例を、標準のサービスオペレーションおよび終了に対して示す。最初のステップ201は、UE 2がサービス初期化リクエスト（initial service request）をネットワーク要素51に送信するときに生じる。
【００６０】
次のステップ203は、ネットワーク要素51がクレジット制御リクエスト初期化メッセージをOCF 151に送信するときに生じる。クレジット制御メッセージ初期化メッセージは、リクエストしたサービスおよびオンライン決済に対する十分なクレジットがユーザーにあるかどうかを判断するために送信される。
【００６１】
次のステップ205では、OCF 151は、ABR予約メッセージ（すなわち、アカウント残高アクションAVPフィールドを1に設定したABRメッセージ）を、アカウント残高管理サーバー（account balance management server：ABMS） 103に送信する。
【００６２】
ABMS 103は、このメッセージを受信すると、次のステップ207で、アカウント情報を調査して、アカウント内に十分なクレジットがある場合は、アカウントにおいてクレジット予約を行う。クレジット予約は、事実上、予約が除去されるまで、所定額のクレジットが使用されないように制限する。上述のように、このクレジットは、事実上の貨幣とするか、またはネットワーク依存の、例えば帯域幅、データ、関連するイベントカウントとすることができる。以下に説明する実施例では、クレジットは、事実上の貨幣である。
【００６３】
このクレジット予約を行った後に、ABMS 103は、ステップ209で、ABAメッセージをOCF 151に返して、予約が成功したことを確認する。
【００６４】
OCF 151は、次いで、（図３には示されない評価機能を使用して）ユーザーが予約した貨幣値を使用して得ることができるサービスに関連するユニット数を計算する。したがって、例えば、サービスが、受信したデータをkBで測定可能なオンデマンドのビデオであり、受信したkBにつきFユーロに評価され、予約された貨幣値が予約につきGユーロである場合、OCFは、予約を使い果たす前に、各予約が提供することができるビデオのG/F kBを計算する。
【００６５】
OCFは、次いで、ステップ213で、このサービスを提供するために、ユーザーが利用可能なユニット数の値を含んだクレジット制御回答メッセージをNE 51に送信する。NE 51がこのメッセージを受信すると、NEは、次いでUE 2へのサービスの供給を開始する。
【００６６】
UE 2を操作するユーザーが、割り当てられた全てのユニットを使い果たす前にサービスの終了を望む場合について、ステップ215乃至227に、残りのユニット値を計上するために、本発明で使用するプロセスを説明する。
【００６７】
ステップ215は、UE 2がサービス終了リクエストをNE 51に送信したときに生じる。NE 51は、終了リクエストを受信した後に残りのユニットを計算し、ステップ217で、CCR終了メッセージをOCF 151に送信する。このメッセージは残りのユニット値を含む。
【００６８】
OCF 151は、残りのユニット値を受信すると、ステップ219で、ステップ211のリバース計算を行って、残りのクレジット値（上述の実施例ではユーロ通貨の値）を決定する。
【００６９】
OCF 151は、次いで、ABRコミットメッセージ（すなわち、アカウント残高アクションAVPフィールドを3に設定したABRメッセージ）をABMS 103に送信する。このメッセージには、予約された額からの通貨の残高も渡される。
【００７０】
ABMS 103は、次いで、ステップ223で、クレジット予約を調査して、アクティブなアカウント値を残高に返し、事実上、部分的に使用されなかった予約された通貨を払い戻す。
【００７１】
次のステップ225で、ABMS 103は、ABAメッセージをOCF 1512に送信して、OCF 151にコミットプロシージャが成功したことを通知する。
【００７２】
更なるステップ227で、OCF 151は、更なるCCAメッセージをNEに送信して、NE 51において、コミット料金がクレジットされたことを確認する。
【００７３】
図４を参照する。図４は、OCF 151によって供給されたユニットが、サービスの終了前に使い果たされた場合を説明する、本発明の第2の実施例である。
【００７４】
第二の実施例の最初の6つのステップ201乃至213は、サービスの初期化を説明した上述の例の最初の6つのステップに説明したものと同じプロシージャに従う。
【００７５】
予約および変換されたユニットを使い果たしたが、サービスが継続されている場合は、ステップ301で、NE 51は、サービスのオペレーションの継続に新しいユニットが必要であるものと判断する。
【００７６】
次のステップ303では、NE 51は、CCR更新メッセージをOCF 151に送信する。
【００７７】
OCF 151は、CCR更新メッセージを受信すると、評価および変換オペレーションを実行して、使用したユニットを貨幣等価額に変換する。ステップ305は、第一の実施例のステップ219で実行したものに類似したオペレーションであり、唯一の相違点は、返された値が、元々予約されていた値に等しいことである。
【００７８】
OCF 151は、計算後のステップで、ABRコミットおよび予約メッセージ（すなわち、アカウント残高アクションAVPフィールドを2に設定したABRメッセージ）をABMS 103に送信する。
【００７９】
ABMS 103は、ABRコミットおよび予約メッセージを受信すると、ステップ309で、予約したアカウントから使用したクレジットを確定するアクションを実行し、更なる予約を作成する。
【００８０】
次のステップで、ABMS 103は、予約した額の値を含むABAメッセージをOCF 151に送信する。
【００８１】
以下の２つのステップ211aおよび213aでは、OCF 151は、ステップ211で実行したものに類似した、クレジットのユニットへの変換を実行し、続けてCCAメッセージをNE 51に送信する。NE 51において受信したCCAメッセージは、ステップ213で送信したステップに類似しており、このメッセージは、決定したユニット数を含んでいる。このプロシージャの終了時に、図３のステップ215の先に示され、第一の実施例に説明したように、ユーザーが終了させるまでサービスを継続することができるようになるか、または更なるユニットを使い果たし、NEが、ステップ303の先のステップを繰り返して更なる更新をリクエストする。
【００８２】
図５を参照する。図５では、ユーザーが最初にサービスをリクエストするが、NE 51に送信されたいかなるユニットも使用しない場合の、本発明の更なる実施例を示す。
【００８３】
第三の実施例の最初の6つのステップ201乃至213は、サービスの初期化を示す第一および第二の実施例の最初の6つのステップ201乃至213と同じである。
【００８４】
次のステップ215で、UE 2は、サービス終了リクエストをNE 51に送信する。ステップ401で、NE 51は、サービスが任意のユニットを使用しなかったことを判断する。上述のサービス終了シーケンスに関して、およびステップ217を参照して上述したように、NE 51は、CCR終了メッセージをOCF 151に送信する。
【００８５】
OCF 151は、CCR終了メッセージを受信すると、ステップ403で、使用した貨幣クレジットの額を計算する。本実施例では、使用ゼロのユニットが有るので、使用した貨幣クレジットの額もゼロであることを除いて、このステップは、上述の実施例のステップ219および305に類似する。
【００８６】
OCF 151は、使用したユニットがゼロであることを検出すると、ステップ405で、ABRリリースメッセージ（すなわち、アカウント残高アクションAVPフィールドを4に設定したABRメッセージ）をABMS 103に送信する。
【００８７】
ABMS 103は、ステップ409で、ABRリリースメッセージを受信した後に、予約を解除する。これは、実質的に、ステップ207で制限されているクレジットを、アクティブなアカウントに返す。
【００８８】
ABMS 103は、次いで、ステップ411で、ABAメッセージをOCF 151に送信して、予約のリリースが成功したことを確認する。
【００８９】
OCF 151は、次いで、ステップ413で、CCAメッセージをNE 51に送信し、アカウンティングプロセスの終了が成功したことをNEに通知する。
【００９０】
図６を参照する。図６は、UE 2を操作するユーザーが、ユーザーの現在のアカウントの残額を確認した場合を示す。
【００９１】
ステップ501で、UE 2は、残高問い合わせメッセージをNE 51に送信する。
【００９２】
ステップ503で、NE 51は、残高問い合わせリクエストを受信すると、CCRイベントメッセージをOCF 151に送信する。イベントメッセージは、ユーザーのアカウント残高が読み取るべき指標を含む。
【００９３】
ステップ505で、OCFは、ABR問い合わせメッセージ（すなわち、アカウント残高アクションAVPフィールドを5に設定したABRメッセージ）をABMS 103に送信する。
【００９４】
ステップ507で、ABMS 103は、ABR問い合わせメッセージを受信すると、示されたユーザーのアカウントを調査して、アカウントの残高を特定する。
【００９５】
ステップ509で、特定されたアカウントの残高は、ABAメッセージでABMS 103からOCF 151へ送信される。
【００９６】
ステップ511で、特定された残高は、CCAメッセージでOCF 151からNE 51へ送信される。
【００９７】
最後にステップ513で、特定された残高は、残高応答メッセージでNEからUE 2へ送信される。特定された応答は、次いでユーザーのUE上に表示することができる。
【００９８】
図７を参照する。図７には本発明の更なる実施例を示す。本実施例では、提供されるサービスの使用は、オペレータまたはサードパーティによって少なくとも部分的に補助されるので、ユーザーのアカウントへの払い戻しが支払い可能である。その一例には、オペレータが、例えば"10分のビデオを購入すれば、1ユーロをアカウントにクレジットする"といったロイヤルティボーナスアカウントをスポンサーする場合の状況となり得る、インセンティブスキームがある。
【００９９】
ステップ601で、UE 2は、サービスリクエストメッセージをNE 51に送信することによってサービスをリクエストする。
【０１００】
ステップ603で、NE 51は、サービスの使用がスポンサーされているので、リクエストされたサービスが払い戻しを受ける権利があることを判断する。
【０１０１】
ステップ605で、NE 51は、次いでCCRイベント/払い戻しメッセージをOCF 151に送信する。すなわち、CCRメッセージは、払い戻しがユーザーのアカウントに支払われることを示す旨が含まれる。
【０１０２】
ステップ607で、OCF 151は、ABR増額メッセージ（すなわち、アカウント残高アクションAVPフィールドを6に設定したABRメッセージ）をABMS 103に送信する。このメッセージは、ユーザーのアカウントに払い戻される額の詳細を含む。
【０１０３】
ステップ609で、ABMS 103がABR増額メッセージを受信すると、ABMS 103は、示されたクレジット値の分だけユーザーのアカウントの残高を増額する。
【０１０４】
ステップ611で、ABMS 103がユーザーのアカウントの増額に成功すると、ABMSは、次いで、ABAメッセージをOCF 151に送信して、このアクションが成功したことを確認する。
【０１０５】
ステップ613で、OCF 151は、ABAメッセージを受信すると、CCAメッセージをNE 51に送信して、アクションが成功したことをNE 51において確認する。
【０１０６】
本発明の更なる実施形態では、OCF 151は、CCRイベント/払い戻しメッセージを受信すると、更なる確認を行って、ユーザーのアカウントが払い戻しを受けたかどうかを判断することができる。更なる実施形態のステップ（図７には示さず）を、アカウントのリチャージの不正な受け取りに対する第二の確認として使用することができる。
【０１０７】
図８を参照する。図８は、本発明の実施形態の更なる実施例を示す。図８には、ユーザーがリクエストしたサービスが固定料金のサービスである場合の実施例を示す。その一例には、トランスポートのようなアイテムを、携帯電話の前払い機能を使用して購入することが可能なシステムがある。
【０１０８】
ステップ701で、UEは、サービスリクエストをNE 51に送信する。
【０１０９】
ステップ703で、NEは、リクエストを受信すると、そのリクエストに関連する課金額を計算する。
【０１１０】
ステップ705で、NE 51は、CCRイベント/自動引き落としメッセージをOCF 151に送信する。このメッセージは、算出した課金額を含む。
【０１１１】
ステップ707で、OCF 151は、使用したユニットの額を評価し、必要に応じて、以前に行われていなければ、課金されたユニットをクレジットに変更する（上述の例では、貨幣クレジットである）。
【０１１２】
ステップ709で、OCF 151は、ABR減額メッセージ（すなわち、アカウント残高アクションAVPフィールドを7に設定したABRメッセージ）をABMS 103に送信する。減額メッセージは、それによってユーザーのアカウントを減額する、評価されたクレジット値を含む。
【０１１３】
ステップ711で、ABMS 103は、ABR減額メッセージ内の値の分だけユーザーのアカウントを減額する。このアカウントを減額するオペレーションは、アカウントに予約が行われないので、上述の例のステップとは異なる。
【０１１４】
ステップ713で、ABMSは、次いで、ABAメッセージをOCF 713に送信して、リクエストの実行が成功したことを確認する。
【０１１５】
ステップ715で、ABMSは、次いで、CCAメッセージをNE 51に送信して、リクエストの実行が成功したことをNE 51において確認する。
【０１１６】
したがって、上述の実施例を参照することによって、アカウント残高管理サーバー103は、課金および評価サーバー（CRS） 101と組み合わせて、広範な課金管理オペレーションを実行できることが分かる。さらに、ABMS 103およびCRS 101が明確な範囲を有するので、オンライン課金アカウント管理システムを、オンラインおよびオフライン両方を処理することができる集中型アカウントの一部に組み込むことができ、したがって、アカウントの重複という問題が解決される。また、このようなシステムによって、オペレータは、ユーザーが使用して瞬間的な残高問い合わせを生成するという利点を有することができる単一の複合（オンラインおよびオフライン）アカウントを提供するような、さらに柔軟なアカウントオペレーションを用いることができる。
【０１１７】
本発明の更なる実施形態では、CRS 101とABMS 103との間で送信されるリクエストおよび回答メッセージ（上述の実施例の場合は、ABRおよびABAメッセージ）は、代わりに、既存のDiameterベースのメッセージに基づくものである。
【０１１８】
発明の他の実施形態では、リクエストおよび回答メッセージは、それぞれDiameterクレジット制御リクエスト、およびDiameterクレジット制御回答メッセージである。
【０１１９】
当業者は、説明された実施形態に対する種々の変形例があることを理解されるべきものである。本発明によって提供される保護の範囲は、添付の特許請求の範囲によって規定される。
【図面の簡単な説明】
【０１２０】
【図１】従来のオンライン課金システムを含む通信ネットワークの簡略図である。
【図２】本発明およびその実施形態が実装することが可能な、改良されたオンライン課金システムの簡略図である。
【図３】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図４】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図５】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図６】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図７】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図８】アカウンティングオペレーションの範囲に対する、改良されたオンライン課金システムのオペレーションを説明するフローチャートである。
【図１】
2009500935.tif 000003
【図２】
2009500935.tif 000004
【図３】
2009500935.tif 000005
【図４】
2009500935.tif 000006
【図５】
2009500935.tif 000007
【図６】
2009500935.tif 000008
【図７】
2009500935.tif 000009
【図８】
2009500935.tif 000010
【国際調査報告】
2009500935.tif 000011
2009500935.tif 000012