本出願は、通信技術の分野に関し、詳細には、課金方法、装置、およびシステムに関する。
本出願は、2019年8月2日に中国特許庁に出願され、「CHARGING METHOD、APPARATUS、AND SYSTEM」と題する中国特許出願第201910713756.3号明細書に対する優先権を主張するものであり、その全体が参照により本明細書に組み込まれる。
現在、4G通信システムでは、オンライン課金サービスおよびオフライン課金サービスは、異なる課金システムを用いることにより課金される。図1で示されるように、システム100における課金トリガー機能(charging trigger function)装置101は、Roインターフェースを介してオンライン課金システム102と通信し、またRfインターフェースを介してオフライン課金システム103と通信する。オンライン課金システム102は、オンライン課金サービスに対する課金を実施するように構成され、またオフライン課金システム103は、オフライン課金サービスに対する課金を実施するように構成される。オンライン課金またはオフライン課金を決定した後、CTF装置は、オンライン課金システム102またはオフライン課金システム103に対して、ダイアメータ課金要求を開始する。オンライン課金システム102またはオフライン課金システム103は、ダイアメータ課金要求における課金コマンドおよび要求タイプに基づいて対応する課金処理を実施し得る。
5G通信システムでは、サービスベースのオンライン/オフライン収束課金メッセージが使用され、リソース予約および使用情報報告が、格付けグループに基づいて実装される。使用情報が報告されると、担持される使用割当て管理表示は、その使用情報が割当てを有する使用情報かどうかを示して、割当てを有する使用情報の報告、および割当てのない使用情報の報告を実装する。割当ては、先行して、課金システムによりCTFに認可された割当てである。言い換えると、使用割当て管理表示は、割当てが、先行して課金システムから適用されており、その適用に基づいて課金システムにより認可されているかどうかを示す。
既存の5G通信システムで使用されるオンライン/オフライン収束課金メッセージは、セッションベースのトラフィック、持続期間リソース予約、および使用報告をサポートする。しかし、現在の収束課金システムは、イベント課金を正確に、かつ効率的に実装することができない。
本出願の実施形態は、イベント課金サービスに対する課金を実装するための課金方法、装置、およびシステムを提供する。
第1の態様によれば、本出願の実施形態は、課金方法を提供する。本方法は、以下のことを含む、すなわち、CHF装置は、課金トリガー機能CTF装置により送られた第1の課金要求を受け取り、ここで、第1の課金要求は、イベント課金情報を担持する。次いで、CHF装置は、イベント課金情報に基づいて、第1のイベント課金処理モードを決定し、第1の課金要求を第1のイベント課金処理モードに従って処理する。本方法によれば、CHF装置は、第1の課金要求に基づいて第1のイベント課金処理モードを決定し、イベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、イベント課金情報は、イベント課金を示す表示情報を含み、第1のイベント課金処理モードを決定する前に、CHF装置は、イベント課金表示情報に基づいて、第1の課金要求が、イベントサービスに対する課金要求であると決定する。したがって、CHF装置は、イベント課金サービスに対する要求を正確に決定し、次いで、その後の処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、またイベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。CHF装置は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、ワンタイムイベント課金要求であると決定し、第1の課金要求に基づいて、第1のイベント課金リソースを作成し、かつ第1のイベント課金リソースは、第2の課金要求を有しないと決定する。代替として、CHFは、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、非ワンタイムイベント課金要求であると決定し、第1の課金要求に基づいて、第1のイベント課金リソースを作成し、かつ第1のイベント課金リソースは、第2の課金要求を有すると決定する。CHF装置は、後続する処理を実施するための後続する第3の課金要求があるかどうかを決定する。例えば、後続する課金要求がない場合、第1のイベント課金リソースは、課金処理が完了した後、リリースされる。代替として、後続する課金要求がある場合、第1のイベント課金リソースは保持される。
可能な実装では、イベント課金情報は、第1のイベント課金処理モードをさらに含み、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置は、処理効率を高めるために、イベント課金処理モードを第1の課金要求から直接取得し得る。
可能な実装では、第1の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含む。CHF装置が、イベント課金情報に基づいて、第1のイベント課金処理モードを決定することは、以下のことを含む、すなわち、CHF装置は、ユーザ識別子に基づいてユーザ情報を取得し、かつイベント課金を示す表示情報、ユーザ情報、およびサービスタイプを示すパラメータに基づいて、第1のイベント課金処理モードを決定し、ここで、第1のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置は、処理効率を高めるために、第1の課金要求から、イベント課金処理モードを直接取得し得る。
可能な実装では、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が、非ワンタイムイベント課金要求であると決定した後、CHF装置が、イベント課金情報に基づいてイベント課金処理モードを決定することは、第1のイベント課金処理モードが、イベント割当ての適用であると決定することを含む。
可能な実装では、第1のイベント課金処理モードは、直接控除であり、またCHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいて格付けを実施し、かつ格付け結果に基づいて、ユーザの勘定残高からの控除を実施することを含む。
可能な実装では、第1のイベント課金処理モードは、オフラインイベント報告であり、またCHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいて、イベント課金データ記録を生成することを含む。
可能な実装では、第1のイベント課金処理モードは、イベント割当ての適用であり、CHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、イベント課金情報に基づいて格付けを実施し、かつ格付けに基づいてイベント割当てを認可することを含む。
可能な実装では、CHF装置は、第1の課金要求に対する第1の課金応答をCTF装置にさらに返し、第1の課金応答は、決定された第1のイベント課金処理モードを担持する。
可能な実装では、イベント課金処理モードは、直接控除であり、第1の課金要求を処理した後、CHF装置は、イベント課金サービスに対する第2の課金要求を受け取り、ここで、第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を含み、第2のイベント課金処理モードは返済であり、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、また第1のイベント課金リソースの識別子は、第1の課金要求に対する課金応答から取得される。加えて、CHF装置は、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が控除される。
可能な実装では、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、第2の課金要求は、ワンタイムイベント課金の表示パラメータを担持する。CHF装置は、第2の課金要求に基づいて、第2のイベント課金リソースをさらに作成する。
可能な実装では、第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、またCHF装置は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。
可能な実装では、第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、またCHF装置は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。
可能な実装では、第1の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第1の課金要求が、第1のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置は、第1のイベント課金リソースをさらに作成する。本方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、第2の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第2の課金要求が、第2のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置は、第2のイベント課金リソースをさらに作成する。この方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持し、第1の課金要求を処理することは、イベント識別子および/またはイベント量に基づいて課金要求を処理することを含む。この方法によれば、複数の課金サービスが生じるごとに課金処理を行うことを回避するために、1つまたは複数のイベントの生成が、1つの課金要求において表され得る。このように、課金処理が簡単化される。
第2の態様によれば、本出願の実施形態は、課金方法を提供する。方法は以下のことを含む、すなわち、CTF装置は、イベント課金サービスの課金サービスが生じたと決定し、第1の課金要求を課金機能CHF装置に送り、ここで、第1の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用される。CTF装置は、第1の課金要求のものであって、CHF装置により送られた第1の課金応答を受け取り、ここで、第1の課金応答は、決定されたイベント課金処理モードに従って、第1の課金要求を処理した結果を含む。この方法によれば、CTF装置は、第1の課金要求におけるイベント課金情報を担持し、したがって、CHF装置は、第1の課金要求に基づいて第1のイベント課金処理モードを決定し、かつイベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、第1の課金応答は、CHFにより決定されたイベント課金処理モードをさらに含む。
可能な実装では、第1のイベント課金処理モードは、直接控除であり、第1の課金応答は、第1の課金要求に基づいて作成された第1のイベント課金リソースの識別子を含み、またCTF装置は、CHF装置により送られた第1の課金応答を受け取る。次いで、CTF装置は、イベント課金サービスが実施されるのに失敗したとさらに決定し、イベント課金サービスに対する第2の課金要求を送り、ここで、第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子と、を含み、また第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が控除される。
可能な実装では、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、また第2の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持する、または第2の課金要求メッセージは、第1のイベント課金リソースに対する更新要求である、もしくは第1のイベント課金リソースに対するリリース要求である。
可能な実装では、第1の課金要求または第2の課金要求は、再送信決定パラメータをさらに含み、また再送信決定パラメータは、第1の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される、かつ/または
第2の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータは、第2の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される。この方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、CTF装置は、サービスイベントが生じた回数の数量を決定し、また課金要求は、イベント識別子およびイベント量をさらに担持する。この方法によれば、複数のイベント課金サービスが生じるごとに課金処理を行うことを回避するために、1つまたは複数のイベントの生成が、1つの課金要求において表され得る。このように、課金処理が簡単化される。
第3の態様によれば、CHF装置が提供される。装置は、第1の態様および第2の態様におけるCHF装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。
第4の態様によれば、CTF装置が提供される。装置は、第1の態様および第2の態様におけるCTF装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。
第5の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金トリガー機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第6の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第2の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第7の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。
第8の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第2の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。
第9の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第10の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第11の態様によれば、本出願の実施形態は、第3の態様における課金機能装置、および第4の態様における課金トリガー機能装置を含む課金システムを提供する。
本出願の第2から第11の態様における技術的な解決策は、第1の態様のものと一致していることを理解されたい。これらの態様、および対応する実行可能な実装により達成される有益な効果は同様であり、詳細を再度述べないものとする。
本出願の実施形態において、または背景において、技術的解決策をより明確に述べるために、以下は、本出願の実施形態または背景を説明するための添付図面を述べる。
現在の技術における課金システムの概略的なブロック図である。
本出願の実施形態によるネットワークアーキテクチャの概略的なブロック図である。
本出願の実施形態による課金システムの概略的なブロック図である。
本出願の実施形態による課金フレームワークの概略的なブロック図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金機能装置の概略的なブロック図である。
本出願の実施形態による課金トリガー機能装置の概略的なブロック図である。
本出願の実施形態による課金デバイスの概略的なブロック図である。
以下は、本出願の実施形態における添付図面を参照して本出願の実施形態を述べる。
図2は、本出願の実施形態が適用できる可能なネットワークアーキテクチャの概略図である。ネットワークアーキテクチャ200は、第5世代移動体通信技術(the 5th Generation mobile communication technology、5G)ネットワークアーキテクチャである。5Gアーキテクチャは、1個のユーザ機器201、無線アクセスネットワーク(radio access network、RAN)202、アクセスモビリティ管理機能(access and mobility management function、AMF)装置206、セッション管理機能(session management function、SMF)装置205、ユーザプレーン機能(user plane function、UPF)装置203、ネットワーク露出機能(Network Exposure Function、NEF)装置208、ショートメッセージサービス機能(Short Message Service Function、SMSF)装置209、データネットワーク(data network、DN)204、および課金機能(charging function、CHF)装置207を含み得る。さらに、図2で示されたネットワーク要素に加えて、本出願のこの実施形態におけるアーキテクチャは、例えば、モノのインターネットメッセージゲートウェイなど、イベント課金を使用する別のネットワーク要素または機能をさらに含み得る。図2の機能モジュール間の通信は、次世代(next generation、NG)インターフェース、またはサービスベースのインターフェース(service based interface、SBI)を介する接続を確立することにより実装され得る。例えば、RANデバイスは、NGインターフェース2(略してN2)を介するAMFへの制御プレーンシグナリング接続を確立し得る、またNEFデバイスは、SBIインターフェースNnefを介して外部サービスを提供し得る。
ユーザ機器は、無線送受信機機能を有するデバイスである。ユーザ機器は、屋内デバイス、屋外デバイス、手持ち式デバイス、もしくは車両搭載デバイスを含む陸上で展開され得る、または水面上で(例えば、船上で)展開され得る、または空中で(例えば、航空機、気球、もしくは衛星で)展開され得る。
以下は、本出願の実施形態における添付図面を参照して、本出願の実施形態における技術的解決策を述べる。本出願の記述において、その他の形で指定されない限り、「複数の」は、2つ以上を意味する。さらに、本出願の実施形態における技術的解決策の明確な記述を容易にするために、本出願の実施形態では、「第1」および「第2」などの用語は、同じ対象物の間、または機能および目的が基本的に同じである同様の対象物の間を区別するために使用される。当業者であれば、「第1」および「第2」などの用語は、量、または実行順序を限定するように意図されたものではなく、また「第1」および「第2」などの用語は、明確な差を示すものでもないことを理解するはずである。本発明における「Aおよび/またはB」は、AまたはBのいずれか一方、またはAおよびBを含むものと説明され得る。
図3は、本出願の実施形態による課金アーキテクチャ300の概略図である。課金アーキテクチャ300は、課金トリガー機能(charging trigger function、CTF)装置101および課金システム31を含む。課金トリガー機能装置101および課金システム31は、サービスベースのインターフェースを介して、互いに通信し得る。サービスベースのインターフェースは、RESTfulおよび遠隔手続き呼び出し(remote procedure call、RPC)など、リソースベースの機能露出インターフェースを指す。図2のネットワークアーキテクチャを参照すると、CTF装置101は、SMF装置205に配置され得る。言い換えると、SMF装置205は、CTF装置101の機能を統合する。課金システム31は、課金機能(charging function、CHF)装置207を含む。CHF装置207は、オンライン(online)課金、およびオフライン(offline)課金を実施し得る。すなわち、課金システム31は、収束課金システムであり得る。課金システム31は、課金が実施されるときに必要な勘定残高管理機能(account balance management function、ABMF)装置、および格付け機能(rating function、RF)装置をさらに含む。ABMF装置は、ユーザの預金口座を記憶し、かつ管理するように構成され、またRF装置は、サービスの使用情報に対する格付けを実施するように構成される。図3で示された課金トリガー機能装置101および課金システム31に加えて、本出願のこの実施形態における課金アーキテクチャは、請求(billing)装置をさらに含み得る。請求装置および課金システム31は、課金ゲートウェイ機能(charging gateway function、CGF)装置を用いることにより、互いに通信し得る。CGF装置は、課金システムの一部として課金システムに統合され得る、または請求装置の一部として請求装置に統合され得る、または独立したネットワーク要素として存在し得る。以下の内容が、さらに詳細に述べられる。
課金トリガー機能装置101は、課金開始要求を生成し、課金システム31が、課金開始要求を処理する。本出願のこの実施形態では、課金トリガー機能装置101はまた、クライアントと見なされ、また課金システム31は、サーバと見なされ得る。課金トリガー機能装置101および課金システム31は、1つまたは複数のプロセッサ、および1つまたは複数のプロセッサに結合されたメモリを含み得る。メモリは、これだけに限らないが、本明細書で述べられるように、コンピュータにアクセスできる命令またはデータ構造の形式の望ましいプログラムコードを記憶するために使用されることのできるRAM、ROM、EEPROM、フラッシュメモリ、または任意の他の媒体を含み得る。
図4は、図3における課金アーキテクチャの特定の実装である。CHF装置207は、サービスベースのインターフェースRestfulを介して外部サービスを提供し得る。インターフェースの名前は、Nchfであり、CTF装置101は、インターフェースNchfを介して、CHF装置207にアクセスし得る。課金システムは、CHF装置207、ABMF装置210、RF装置212、およびCGF装置211を含む。
図5は、本出願による課金方法500の概略的な流れ図である。方法500は、図2におけるネットワークアーキテクチャに、かつ図3および図4で示される課金アーキテクチャに適用され得る。実際には、方法500はまた、別の通信シナリオにも適用され得る。これは、本出願の実施形態に限定されない。図5で示されるように、方法500は、以下の内容を含む。
ステップ501:現在のサービスをイベント課金サービスとして構成し、かつCTF装置101におけるサービスの課金ルールを構成する。
ステップ501で、CTF装置101が、SMF装置205に配置された場合、イベント課金サービスおよび課金ルールは、ポリシを送達することにより、CTF装置101におけるPCFにより動的に構成され得る、またはCTF装置101において事前に構成され得る。任意選択で、CTF装置101が、別のネットワーク機能装置に位置する場合、イベント課金サービスの課金ルールは、CTF装置101において事前に構成される。操作者は、サービスがイベント課金サービスであることを示すために、CTF装置101においてサービス課金ルールを構成し得る。サービス課金ルールは、報告条件、および/またはイベント課金サービスの課金処理モードをさらに含む。課金処理モードは、(1)直接控除、(2)予約ベースのイベント課金(割当ての適用、および割当ての使用報告を含む)、(3)オフラインイベント報告、(4)返済、および同様のものなどを含む。
直接控除は、CHF装置207が、CTF装置101により報告された課金要求に基づいて格付けを実施し、格付け結果に基づき、ユーザの勘定残高からの控除を実施することを意味する。オフラインイベント報告は、CHF装置207が、CTF装置101により報告された課金要求に基づいてイベント課金データ記録(Charging Data Record、CDR)を生成することを意味し、CDRはまたイベント課金請求書とも呼ばれる。イベント割当ての適用は、CHF装置207が、CTF装置101により報告された課金要求に基づいて格付けを実施し、勘定残高におけるリソースを予約する(すなわち、ユーザへの割当てを認可する)ことを意味する。割当て使用報告は、サービスが課金報告を満たすとき、認可された割当てを有する使用情報が報告されることを意味する。返済は、直接控除が実施されるイベント課金サービスに対して、イベント課金サービスが実施されるのに失敗した場合、直接控除における控除量が返済されることを意味する。
課金処理モードにおいて、リソースを求める第1の課金要求に対するイベント課金処理モードは、第1のイベント課金処理モードと呼ばれる。第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告を含む。第2の課金要求に対するイベント課金処理モードは、第2のイベント課金処理モードと呼ばれる。第2のイベント課金処理モードは、返済を含む。
課金処理モードにおいて、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、また課金システムに第1のイベント課金リソースを作成するように要求するために使用される。第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、課金システムに第2のイベント課金リソースを作成するように要求するために使用される、または第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、課金システムに第1のイベント課金リソースを更新するように要求するために使用される、または第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、第1のイベント課金リソースに対応する課金データが更新された後、第1のイベント課金リソースをリリースするように課金システムに要求するために使用される。
例えば、課金要求は、イベント送信側および受信側、イベント発生時間、ならびに/またはイベントコンテンツサイズを担持する。
ステップ502:CTF装置101は、第1の課金要求をCHF装置207に送り、ここで、第1の課金要求は、イベント課金情報を担持する。
CTF装置101は、イベント課金サービスの使用をモニタし、イベント課金サービスの課金イベントが生じたと決定する。課金イベントは、課金される必要のあるイベントであり、課金報告をトリガーする課金イベントである。CHF装置207は、構成されたサービス課金ルールに従って、第1の課金要求を生成する。第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、CHF装置207に送られる。CTF装置101が、SMF装置205に位置している場合、課金イベントが生ずることは、新しいPDUセッションが確立されることであり得る。CTF装置101が、システムの別の機能装置に位置する場合、課金イベントが生ずることは、CTF装置101が、ネットワーク機能APIの起動メッセージを受け取ること、またはネットワーク機能APIに対する起動応答を返すことであり得る。
イベント課金情報は、イベント課金を示す表示情報を含み、また第1の課金要求が、イベントサービスに対する課金要求であると決定するために使用される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータであり得る(例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モードなど)。
イベント課金情報は、ワンタイムイベント課金の表示パラメータ、または非ワンタイムイベント課金の表示パラメータをさらに含む。ワンタイムイベント課金の表示パラメータは、第1のイベント課金リソースが、第1の課金要求に基づいて作成された後、第1のイベント課金リソースは、後続する課金要求を有しないことを示す。
リソースイベント課金リソース作成は、第1のイベント課金処理モードをさらに担持し得る。第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。加えて、リソースイベント課金リソース作成は、イベント識別子、イベント量、再送信決定パラメータ、イベントの詳細などのうちの1つまたは複数のものをさらに担持し得る。イベント量は、イベントの生じた回数の数量を示す。イベント識別子は、サービスイベントを示し、例えば、サービスイベントが、API起動、またはSMS送信であることを示す。
ステップ503:CHF装置207は、第1の課金要求に基づいて、イベント課金サービスに対する課金処理を実施する。
例えば、第1の課金要求が、第1のイベント課金リソースに対する作成要求であるとき、CHF装置207は、第1の課金要求に対する第1のイベント課金リソースを作成し、かつリソース識別子を第1のイベント課金リソースに割り振る。
特に、CHF装置207は、第1の課金要求がワンタイムイベント課金であるかどうかを決定する必要がさらにあり、CHF装置207が、第1の課金要求はワンタイムイベント課金要求であると決定した場合、CHF装置207は、第1のイベント課金リソースは、後続する課金要求を有しないと決定する。したがって、第1の課金要求に基づいて、課金リソースを作成し、かつ課金処理を実施した後、CHF装置207は、もはや第1のイベント課金リソースのコンテキストを保持しない、例えば、第1のイベント課金リソースをリリースする、または第1のイベント課金リソースをデータベースに記憶する。代替として、CHF装置207が、第1の課金要求は、非ワンタイムイベント課金要求であると決定した場合、CHF装置207は、第1の課金要求に基づいて第1のイベント課金リソースを作成し、第1のイベント課金リソースは、第1のイベント課金リソースをリリースするための後続する課金要求を有すると決定し、かつ第1のイベント課金リソースのコンテキストを保持し、後続する課金要求を処理できるようにする。第1の課金要求が、ワンタイムイベント課金であるかどうかを、CHF装置207により決定するための特定の方法は、以下のことを含む、すなわち、イベント課金情報が、ワンタイムイベント課金の表示パラメータをさらに含む場合、CHF装置207は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、ワンタイムイベント課金要求である、または非ワンタイム課金要求であると決定する。第1の課金要求が、ワンタイムイベント課金のパラメータを担持しないが、課金処理モードを決定するための情報を担持する場合、CHF装置207は、決定された課金処理モードに従って、第1の課金要求がワンタイムイベント課金要求であるかどうかをさらに決定する。例えば、決定されたイベント課金処理モードが、直接控除またはオフラインイベント報告である場合、CHF装置207は、第1の課金要求がワンタイムイベント課金要求であると決定する。決定されたイベント課金処理モードが、リソース予約である場合、CHF装置207は、第1の課金要求は、非ワンタイムイベント課金要求であると決定する。イベント課金情報が、イベント課金処理モードをさらに含む場合、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置207は、リソースイベント課金リソース作成において担持されたイベント課金処理モードに従って、直接控除、オフラインイベント報告、またはサービスに対するイベント割当ての適用を実施し得る。
イベント課金情報が、第1のイベント課金処理モードを含まない場合、CHF装置207は、第1の課金要求に基づいて、第1のイベント課金処理モードを決定し、決定された第1のイベント課金処理モードに従って、第1の課金要求を処理し得る。決定された第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。例えば、CHF装置207は、第1の課金要求において担持されたユーザ識別子に基づいて、ユーザ情報を取得し、かつ取得されたユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、CHF装置207は、例えば、API起動のサービスタイプなど、第1の課金要求におけるサービスタイプのパラメータに基づいてイベント課金処理モードを決定してもよい。代替として、CHF装置207は、第1の課金要求におけるサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。CHF装置207は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照してイベント課金処理モードを決定し得る。
イベント課金情報が、イベント課金処理モードを含まない場合、CHF装置207は、イベント課金表示情報に基づいて、第1の課金要求は、イベントサービスに対する課金要求であると決定し、第1の課金要求におけるユーザ識別子に基づいて、ユーザ情報を取得し、ユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、CHF装置207は、イベント課金情報に含まれるサービスタイプのパラメータ、またはサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。CHF装置207は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照して、イベント課金処理モードを決定してもよい。
イベント課金情報が、イベント課金処理モードを含まない場合、CHF装置207は、イベント課金情報に含まれる非ワンタイムイベント課金の表示パラメータに基づいて、イベント課金処理モードをさらに決定し得る。特に、イベント課金情報が、非ワンタイムイベント課金の表示パラメータを含む場合、CHF装置207は、第1のイベント課金処理モードは、イベント割当ての適用であると決定する。
イベント課金情報は、再送信決定パラメータをさらに含む。第1の課金要求に対して、第1のイベント課金リソースを作成する前に、CHF装置207は、再送信決定パラメータに基づいて、第1の課金要求が、第1のイベント課金リソースに対する再送信された作成要求ではないと決定した後、第1のイベント課金リソースを作成する。再送信決定パラメータは、大域的に一意の専用の識別子であり得る、またはユーザ識別子とサービス特有の識別子の組合せであり得る。サービス特有の識別子は、ユーザドメインにおいてのみ一意である。
ステップ504:CHF装置207は、第1の課金要求に対する第1の課金応答をCTF装置101に送り、ここで、第1の課金応答は、第1のイベント課金リソースの識別子を担持する。
任意選択で、第1の課金要求が、第1のイベント課金処理モードを担持していない場合、第1の課金応答は、例えば、直接控除、イベント割当ての適用、またはオフラインイベント報告など、CHF装置207により決定された第1のイベント課金処理モードをさらに担持する。
ステップ505:CTF装置101は、第1の課金要求の控除量を返済するように要求するために、第2の課金要求をCHF装置207に送る。
第2の課金要求は、第2のイベント課金リソースに対する作成要求、または第1のイベント課金リソースに対する更新要求、または第1のイベント課金リソースに対する削除要求であり得る。
第1のイベント処理モードが直接控除であるとき、CTF装置101は、イベント課金サービスが実施されるのに失敗したと決定し、またCTF装置101は、イベント課金サービスに対する第2の課金要求を送る。第2の課金要求は、第2のイベント課金リソースに対する作成要求、または、第1のイベント課金リソースに対する更新要求、または第1のイベント課金リソースに対する削除要求であり得る。好ましくは、第2の課金要求は、第2のイベント課金リソースに対する作成要求である。第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を含み、また第2のイベント処理モードは、返済である。第2のイベント課金処理モードは、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される。第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
例えば、イベント課金サービスが、実施されるのに失敗し、かつ第1のイベント課金処理モードが直接控除である場合、第2の課金要求は、以下のようになり得る、
課金作成要求
{
oneEventCharging:真
eventCHMethod:返済
}
ここにおいて、「課金作成要求」は、第2の課金要求が、リソース作成要求であることを示す。第2の課金要求は、ワンタイムイベント課金のパラメータ「oneEventcharging」を担持しており、またワンタイムイベント課金のパラメータは、後続するイベント課金要求があるかどうかを示すために使用される。oneEventchargingの値は真であり、後続するリソース更新課金要求、またはリソース削除課金要求がないことを示している。リソース更新課金要求は、第2のイベント課金処理モード「eventCHMethod」をさらに担持する。第2のイベント課金処理モードの値は、返済であり、イベント課金処理モードは返済であることを示している。
ステップ506:CHF装置207は、第2の課金要求に基づいて課金処理を実施し、第2の課金要求に対する第2の課金応答をCTF装置101に返す。
第2の課金要求は、第1のイベント課金リソースに対する更新要求、または削除要求であり得、第2のイベント課金処理モードを含む。第2のイベント課金処理モードは返済である。第2のイベント処理モードは、第1の課金要求を用いることにより実施された直接控除における控除量を返済するようにCHF装置207に示す。CHF装置207は、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。加えて、CHF装置207は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。第2の課金要求に対する応答は、返済動作の結果である。
別の実装では、第2の課金は、第2のイベント課金リソースに対する作成要求であり得るが、第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を担持し、また第2のイベント課金処理モードは返済であり、第1の課金要求を用いることにより実施された直接控除における控除量を返済するようにCHF装置207に示すために使用される。第2の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持し得る。CHF装置207は、第2の課金要求に基づいて第2のイベント課金リソースを作成し、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつ控除量をユーザの勘定残高に戻す。
任意選択で、第2の課金要求は、再送信決定パラメータをさらに含む。再送信決定パラメータに基づいて、第2の課金要求が、第2のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置207は第2のイベント課金リソースを作成する。
ステップ507:CTF装置101は、第3の課金要求をCHF装置207に送る。
第1の課金要求が、リソース作成要求であり、かつ第1の課金処理モードが、イベント割当ての適用であるとき、CTF装置は、イベント課金サービスの実行を完了した後、第3の課金要求をCHFにさらに送る。第3の課金要求は、第3の課金処理モード、すなわち、オフラインイベント報告を担持する。
第3の課金要求は、リソース更新要求、またはリソース削除要求であり得る。第3の課金要求は、第1のイベント課金リソースの識別子をさらに含み得る。
ステップ508:CHF装置207は、第2の課金要求に基づいて課金処理を実施し、かつ第3の課金要求に対する第3の課金応答をCTF装置101に返す。
第3の課金要求を受け取った後、CHF装置207は、第3の課金処理モードに従って、CDRを生成する。CHF装置207は、第3の課金応答をCTF装置に返す。
前述の方法によれば、CHF装置207は、収束課金システムを用いることにより、イベント課金を実装し得、したがって、CTFによりイベント課金を処理するための方法は、課金システムによりイベント課金を処理するための方法と一致して、課金システムにより実施される処理と、サービスに対してCTFにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。
図6は、本出願の実施形態による、CTF装置101により送られた課金要求をCHF装置207が受け取った後でCHF装置207によって実施される対応する処理の詳細な流れ図である。この実施形態では、CTF装置101により送られた第1の課金要求は、イベント課金処理モードを担持せず、CHF装置207は、ユーザ情報および/またはサービス情報に基づいてイベント課金処理モードを決定する。図6に対応する手順は、以下のステップを含む。
ステップ601:CHF装置207が、CTF装置101により送られた第1の課金要求を受け取る。第1の課金要求については、ステップ502の説明を参照されたい。
一例では、第1の課金要求は、以下のように第1のイベント課金リソースに対する作成要求であることがある。
Charging Create Request
{
oneEventCharging: true
}
本明細書では、「課金作成要求」は、そのメッセージが第1の課金要求であることを示す。第1の課金要求は、ワンタイム課金のパラメータ「oneEventcharging」を担持し、ワンタイム課金のパラメータは、後続の第3の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が真である場合には、それは、後続の第3の課金要求がないことを示す。第3の課金要求は、リソース更新課金要求またはリソース削除課金要求である。
任意選択で、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持することがある。CTF装置101は、各サービスの各タイプの課金イベントにイベント識別子を割り振る。すなわち、イベント識別子は、イベントのタイプを示す。例えば、ユーザ状態を問い合わせるネットワーク能力APIに割り振られるイベント識別子は、NEF_GetUserStatusである。イベント量は、イベントの発生回数の数量を示す。例えば、イベント量が3であるときには、それは、ユーザ状態のネットワーク能力が3回問い合わせられたことを示す。課金要求がイベントデータを担持しない場合には、それは、イベントの発生回数の数量が1であることを示す。イベント識別子およびイベント量を担持するリソースイベント課金リソース作成の例は、以下のとおりである。
Charging Create Request
{
Multiple Unit Usage
Requested Unit
EventID:NEF_GetUserStatus
EventNum:1
}
本明細書では、「EentID:NEF_GetUserStatus」は、イベント識別子がNEF_GetUserStatusであることを示す。本明細書では、「EventNum:1」は、イベントが使用された回数の数量が1であることを示す。
ステップ602:CHF装置207が、第1の課金要求がイベントサービスに対する課金要求であると決定する。
第1の課金要求は、イベント課金を示す表示情報を担持し、CHF装置207は、イベント課金を示す表示情報に基づいて、第1の課金要求がイベントサービスに対する課金要求であると決定する。したがって、CHF装置207が第1の課金要求についての第1のイベント課金処理モードを決定する必要があると決定される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータ(例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モード)であり得る。
一例では、CHF装置207は、oneEventcharging(すなわちワンタイム課金要求パラメータ)に基づいて、第1の課金要求がイベントサービスに対する課金要求であると決定することがある。代替として、第1の課金要求は、イベントサービス識別子(例えばイベントID)を担持し、CHF装置207は、イベントサービス識別子に基づいて、第1の課金要求がイベントサービスに対する課金要求であると決定する。
ステップ603:CHF装置207が、第1の課金要求に基づいて、第1のイベント課金処理モードを決定する。
CHF装置207は、第1の課金要求内のユーザ識別子、サービスタイプのパラメータまたはサービス状態のパラメータに基づいて、第1の課金要求の第1のイベント課金処理モードを決定することがある。例えば、第1の課金要求は、サービス状態を示すサービス状態パラメータを担持する。サービス状態が、サービスが発生する前である場合には、CHF装置207によって実施される課金処理は、直接控除である。サービス状態が、サービスが発生した後である場合には、CHF装置207によって実施される課金処理は、CDRを生成することである。一例では、サービス状態のパラメータは、サービス要求、またはサービス応答であり得る。CHF装置207は、サービス要求について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生する前であると決定することがある。CHF装置207は、サービス応答について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生した後であると決定することがある。
任意選択で、CHF装置207は、さらに、第1の課金要求内のユーザ識別子に基づいてユーザ情報を取得し、課金要求のユーザが前払いのユーザであると決定し、第1のイベント課金処理モードが直接控除であると決定し、課金要求に対して直接控除を実施することがある。代替として、CHF装置207は、課金要求のユーザが後払いのユーザであると決定し、第1のイベント課金処理モードがオフラインイベント報告であると決定し、課金要求に基づいてCDRを生成することがある。
任意選択で、CHF装置207は、さらに、イベント課金情報に含まれるワンタイムイベント課金の表示パラメータに基づいてイベント課金処理モードを決定することがある。具体的には、イベント課金情報がワンタイムイベント課金の表示パラメータを含む場合には、それは、第1の課金要求が後続の第3の課金要求を有することを示し、CHF装置は、第1のイベント課金処理モードがイベント割当ての適用であると決定する。
ステップ604:CHF装置207が、第1の課金要求がワンタイム課金要求であるかどうかを決定する。第1の課金要求がワンタイム課金要求である場合には、ステップ605が実施される。第1の課金要求がワンタイム課金要求でない場合には、ステップ609が実施される。
第1の課金要求は、ワンタイムイベント課金のパラメータ(例えばoneEventCharging)を担持する。ワンタイムイベント課金のパラメータの値が真である場合には、CHF装置207は、第1の課金要求がワンタイム課金要求である、すなわちイベント課金サービスが後続の第3の課金要求を有していないと決定する。ワンタイムイベント課金のパラメータの値が偽である場合には、CHF装置207は、第1の課金要求が非ワンタイム課金要求である、すなわちイベント課金サービスが後続の第3の課金要求を有すると決定する。
第1の課金要求がワンタイムイベント要求のパラメータを担持し、第1の課金要求が非ワンタイム課金要求であると示すことは、以下の例であることがある。
Charging Create Request
{ Multiple Unit Usage
Requested Unit
EventID:NEF_GetUserStatus
EventNum:1
oneEventCharging:false
}
本明細書では、課金作成要求は、メッセージがイベント課金リソースに対する作成要求であることを示す。本明細書では、「Multiple Unit Usage」は、サービスユニットの利用を示す。例えば、イベントIDは、イベント識別子を示し、NEF_GetUserStatusは、イベント識別子がNEF_GetUserStatusであることを示す。EventNumは、イベント課金サービスについて、イベントの発生回数の数量が1であることを示す。本明細書では、リソースイベント課金リソース作成に担持されるワンタイム課金のパラメータ「oneEventcharging」は、後続の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が偽である場合には、それは、後続のリソース更新課金要求またはリソース削除課金要求がある、すなわち第1の課金要求が非ワンタイム課金要求であることを示す。
ステップ605:CHF装置207が、決定された第1のイベント課金処理モードに従って、課金処理を実施する。
第1のイベント課金処理モードが直接控除である場合には、CHF装置207は、第1の課金要求に基づいて格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施する。格付けは、ユーザの預金残高が十分である場合には、CHFが価格を表す通貨単位の量を計算し、要求された単位または内部単位の量に基づいてユーザの勘定残高から計算された量を控除することを意味する。
第1のイベント課金処理モードがオフラインイベント報告である場合には、第1の課金要求に基づいて、イベント課金データ記録が生成される。
第1のイベント課金処理モードがイベント割当ての適用である場合には、イベント課金情報に基づいて格付けが実施され、格付けに基づいてイベント割当てが認可される。
第1の課金要求がワンタイム課金要求であるので、第1の課金要求に対して課金処理を実施した後で、CHF装置207は、さらに第1のイベント課金リソースをリリースする必要がある。
ステップ606:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置によって決定された第1のイベント課金処理モードを担持する。CHF装置207によって決定された第1のイベント課金処理モードは、直接控除またはCDR生成である。
第1の課金応答は、CHF装置207によって作成されたイベントリソース識別子をさらに担持する。第1のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
リソース作成課金応答は、以下であることがある。
Charging Create Response
{
EventChargingHandling: {Debit or Record}
本明細書では、「Charging Create Response」は、リソースについて課金応答を作成することを示す。本明細書では、「EventChargingHandling」パラメータは、CHF装置207によって決定された第1のイベント課金処理モードを担持し、ここで、「Debit」は、CHF装置207によって決定された課金処理モードが直接控除であることを示す。本明細書では、「Record」は、CHFによって決定された課金処理モードがCDRを生成することであることを示し、この課金処理モードは、オフラインイベント報告に対応する。
ステップ607:CHF装置207が、CTF装置101により送られた第2の課金要求を受け取る。
第1のイベント課金処理モードが直接控除であるときには、第1の課金応答を受け取った後で、CTF装置101は、イベント課金サービスが実施されるのに失敗したと決定し、CTF装置101は、イベント課金サービスについて第2の課金要求を送る。第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子とを含み、第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
第2の課金要求の詳細な説明については、ステップ505の説明を参照されたい。本出願のこの実施形態では、詳細を改めて説明しない。
ステップ608:CHF装置207が、第2の課金要求に対する第2の課金応答をCTF装置に返す。ここで、この課金応答は、CHF装置207によって決定された課金処理モードを担持する。CHF装置207によって決定された課金処理モードは、直接控除またはイベント割当ての適用である。
ステップ608の説明については、ステップ506を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。
ステップ609:CHF装置207が、第1の課金要求内に担持される第1のイベント課金処理モードに従って課金処理を実施する。
第1のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第1のイベント課金リソース割当てが認可され、格付けに基づいて第1のイベント課金リソースの識別子が割り振られる。
ステップ610:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置によって決定された第1のイベント課金処理モードを担持する。CHF装置によって決定された第1のイベント課金処理モードは、割当ての認可である。第1の課金応答は、さらに、CHF装置207によって作成された第1のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ611:CHF装置207が、CTF装置101により送られた第3の課金要求を受け取る。
イベント課金サービスの実行を完了した後で、CTF装置は、第3の課金要求をCHF装置207に送る。第2の課金要求は、第1のイベント課金リソースに対する更新要求または削除要求であることがある。第3の課金要求は、第1のイベントリソース識別子を担持する。
さらに、第2の課金要求は、第2のイベント処理モードをさらに担持することがあり、第2のイベント処理モードは、割当て使用報告である。CHF装置207は、第2のイベント処理モードに従って、イベント課金データ記録を生成する。
ステップ612:CHF装置207が、第3の課金要求に対する第3の課金応答をCTF装置に返す。
任意選択で、ステップ601または607の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第1のイベント課金リソースまたは第2のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、CHF装置207は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をCTF装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、CHF装置207は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、CHF装置207は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。
この方法によれば、CHF装置207は、第1の課金要求に基づいて第1のイベント課金処理モードを決定して、サービスに対して課金システムにより実施される処理と、CTFにより実施される処理との間の不一致を回避することがあり、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止することがある。
図7は、本出願の実施形態による、CHF装置207がCTF装置101により送られた課金要求を受け取った後でCHF装置207によって実施される対応する処理の詳細な流れ図である。この実施形態では、CTF装置101により送られる第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1の課金要求内に担持される第1のイベント課金処理モードに従って第1のイベント課金処理モードを決定する。図7に対応する手順は、以下のステップを含む。
ステップ601:CHF装置207が、CTF装置101により送られた第1の課金要求を受け取る。第1の課金要求については、ステップ502の説明を参照されたい。
一例では、第1の課金要求は、以下のように第1のイベント課金リソースに対する作成要求であることがある。
Charging Create Request
{
oneEventCharging:true
eventCHMethod:debit
}
本明細書では、「課金作成要求」は、第1の課金要求が課金リソース作成要求であることを示す。第1の課金要求は、ワンタイム課金のパラメータ「oneEventcharging」を担持し、ワンタイム課金のパラメータは、後続の第3の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が真である場合には、それは、後続の第3の課金要求がないことを示す。第3の課金要求は、リソース更新課金要求またはリソース削除課金要求である。本明細書では、「eventCHMethod」は、第1のイベント課金処理モードであり、第1のイベント課金処理モードの値は、直接控除(debit)、オフラインイベント報告(記録)、またはイベント割当ての適用(予約)である可能性がある。
任意選択で、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持することがある。例については、ステップ601の説明を参照されたい。
ステップ702:CHF装置207が、第1の課金要求がイベントサービスに対する課金要求であると決定する。ステップ702の詳細な説明については、ステップ602の説明を参照されたい。本発明のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ703:CHF装置207が、第1の課金要求に基づいて、第1のイベント課金処理モードを決定する。
第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1の課金要求に基づいて第1のイベント課金処理モードを決定する。
ステップ704:CHF装置207が、第1の課金要求がワンタイム課金要求であるかどうかを決定する。第1の課金要求がワンタイム課金要求である場合には、ステップ705が実施される。第1の課金要求がワンタイム課金要求でない場合には、ステップ709が実施される。
ステップ704の詳細な説明については、ステップ604を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ705:CHF装置が、決定された第1のイベント課金処理モードに従って、課金処理を実施する。ステップ705の詳細な説明については、ステップ605を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ706:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置207によって作成されたイベントリソース識別子を担持する。第1のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ707:CHF装置207が、CTF装置101により送られた第2の課金要求を受け取る。ステップ707の詳細な説明については、ステップ607を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ708:CHF装置207が、第2の課金要求に対する第2の課金応答をCTF装置に返す。
ステップ708の説明については、ステップ506を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。
ステップ709:CHF装置207が、第1の課金要求内に担持される第1のイベント課金処理モードに従って課金処理を実施する。
第1のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第1のイベント課金リソース割当てが認可され、格付けに基づいて第1のイベント課金リソースの識別子が割り振られる。
ステップ710:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置207によって作成された第1のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ711:CHF装置207が、CTF装置101により送られた第3の課金要求を受け取る。ステップ711の詳細な説明については、ステップ611を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ712:CHF装置207が、第3の課金要求に対する第3の課金応答をCTF装置に返す。
任意選択で、ステップ601または607の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第1のイベント課金リソースまたは第2のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、CHF装置207は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をCTF装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、CHF装置207は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、CHF装置207は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。
この方法によれば、CHF装置207は、収束課金システムを用いることによってイベント課金サービスの課金を実装することがある。第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1のイベント課金処理モードに従って、処理を直接実施することがある。これにより、サービスに対して課金システムにより実施される処理と、CTFにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。
以上では、ネットワーク要素間の相互作用の観点から、本出願の実施形態で提供される解決策について主に説明した。前述の機能を実装するためには、課金機能装置および課金トリガー機能装置などのデバイスは、それらの機能を実施するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解され得る。当業者なら、本明細書に開示される実施形態に記載される例のモジュールおよびアルゴリズムステップと組み合わせて、本出願が、ハードウェア、またはハードウェアとコンピュータソフトウェアの組合せによって実装され得ることに容易に気づくであろう。機能がハードウェアによって実施されるか、コンピュータソフトウェアによって駆動されるハードウェアによって実施されるかは、これらの技術的解決策の特定の応用分野および設計上の制約によって決まる。当業者なら、異なる方法を使用して、説明された機能を特定の各応用分野のために実装することがあり得るが、その実装が本出願の範囲を超えると考えられるべきではない。
本出願の実施形態では、前述の方法例に基づいて、CTF装置101およびCHF装置207などのデバイスに対して機能モジュールの分割が実施されることがある。例えば、各機能モジュールはそれぞれの機能に対応する分割によって得られることがあるし、または、2つ以上の機能が1つの処理モジュールに統合されることがある。統合されたモジュールは、ハードウェアの形態で実装され得る、またはソフトウェア機能モジュールの形態で実装され得る。本出願の実施形態では、モジュールの分割は一例であり、単に論理機能分割であることに留意されたい。実際の実装では、別の分割方法が用いられることがある。
例えば、機能モジュールが統合的な分割によって得られるときには、図8は、装置800の構造の概略図である。装置800は、前述の実施形態における課金機能装置207であり得る、または課金機能装置207内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図8に示すように、この装置は、受信モジュール801と、決定モジュール802と、処理モジュール803と、送信モジュール804とを含む。
受信ユニット801は、課金トリガー機能CTF装置により送られた第1の課金要求を受け取るように構成され、第1の課金要求は、イベント課金情報を担持する。決定ユニット802は、イベント課金情報に基づいて第1のイベント課金処理モードを決定するように構成される。処理ユニット803は、第1のイベント課金処理モードに従って第1の課金要求を処理するように構成される。
任意選択で、イベント課金情報は、イベント課金を示す表示情報を含み、決定ユニット802は、イベント課金表示情報に基づいて、第1の課金要求がイベントサービスに対する課金要求であると決定するようにさらに構成される。
任意選択で、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、イベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。
決定モジュール802は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求がワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール803は、第1の課金要求に基づいて第1のイベント課金リソースを作成するようにさらに構成され、決定モジュールは、第1のイベント課金リソースが第2の課金要求を有していないと決定するようにさらに構成される。
代替として、決定モジュール802は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が非ワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール803は、第1の課金要求に基づいて第1のイベント課金リソースを作成するようにさらに構成され、決定モジュール802は、第1のイベント課金リソースが第2の課金要求を有すると決定するようにさらに構成される。
任意選択で、第1の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含み、決定モジュール802がイベント課金情報に基づいて第1のイベント課金処理モードを決定することは、ユーザ識別子に基づいてユーザ情報を取得することと、イベント課金を示す表示情報、ユーザ情報、および/またはサービスタイプを示すパラメータに基づいて第1のイベント課金処理モードを決定することとを含み、ここで、第1のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。
任意選択で、決定モジュール802が、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が非ワンタイムイベント課金要求であると決定した後において、決定モジュール802がイベント課金情報に基づいてイベント課金処理モードを決定することは、第1のイベント課金処理モードがイベント割当ての適用であると決定することを含む。
任意選択で、第1のイベント課金処理モードは、直接控除であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に対して格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施することを含む。
任意選択で、第1のイベント課金処理モードは、オフラインイベント報告であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいてイベント課金データ記録を生成することを含む。
任意選択で、第1のイベント課金処理モードは、イベント割当ての適用であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、イベント課金情報に基づいて格付けを実施すること、および格付けに基づいてイベント割当てを認可することを含む。
任意選択で、CHF装置207は、第1の課金要求に対する課金応答をCTF装置101に返すように構成された送信モジュールをさらに含み、ここで、課金応答は、決定された第1のイベント課金処理モードを担持する。
任意選択で、イベント課金処理モードは、直接控除であり、第1の課金要求を処理した後で、
受信モジュール801は、イベント課金サービスに対する第2の課金要求をさらに受け取り、ここで、第2の課金要求は、第2のイベント課金処理モードおよび第1のイベント課金リソースの識別子を含み、第2のイベント課金処理モードは、返済であり、かつ第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、第1のイベント課金リソースの識別子は、第1の課金要求に対する課金応答から取得される。
決定モジュール802は、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定するようにさらに構成される。
処理モジュール803は、控除量をユーザの勘定残高に返済するようにさらに構成される。
任意選択で、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、第2の課金要求は、ワンタイムイベント課金の表示パラメータを担持し、処理モジュール803は、第2の課金要求に基づいて第2のイベント課金リソースを作成するようにさらに構成される。
任意選択で、第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、処理モジュール803は、第2の課金要求に基づいて第1のイベント課金リソースをリリースするようにさらに構成される。
任意選択で、第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、処理モジュール803は、第2の課金要求に基づいて第1のイベント課金リソースをリリースするようにさらに構成される。
任意選択で、第1の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール802は、再送信決定パラメータに基づいて、第1の課金要求が第1のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール803は、第1のイベント課金リソースを作成するようにさらに構成される。
任意選択で、第2の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール802は、再送信決定パラメータに基づいて、第2の課金要求が第2のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール803は、第2のイベント課金リソースを作成するようにさらに構成される。
任意選択で、課金要求は、イベント識別子および/またはイベント量をさらに担持し、処理モジュール803が第1の課金要求を処理することは、イベント識別子および/またはイベント量に基づいて第1の課金要求を処理することを含む。
図9は、CTF装置900の概略構造図である。CTF装置900は、前述の実施形態の課金トリガー機能装置101であり得る、または課金トリガー機能装置101内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図9に示すように、CTF装置は、受信モジュール901、決定モジュール902、および送信モジュール903を含む。
決定モジュール902は、イベント課金サービスの課金イベントが発生したと決定するように構成され、送信モジュール903は、第1の課金要求を課金機能CHF装置207に送るように構成され、ここで、第1の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用され、受信モジュール901は、第1の課金要求のものであり、かつCHF装置により送られる、第1の課金応答を受け取るように構成され、ここで、第1の課金応答は、決定されたイベント課金処理モードに従って第1の課金要求を処理した結果を含む。
任意選択で、第1のイベント課金処理モードは、直接控除であり、第1の課金応答は、第1の課金要求に基づいて作成された第1のイベント課金リソースの識別子を含み、受信モジュール901がCHF装置207により送られた第1の課金応答を受け取った後で、決定モジュール902は、イベント課金サービスが実施されるのに失敗したと決定するようにさらに構成される。
送信モジュール903は、イベント課金サービスに対する第2の課金要求を送るようにさらに構成され、ここで、第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子とを含み、第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
図10は、本出願の実施形態による課金トリガー機能装置または課金機能装置(本明細書では、短縮して課金デバイス1000と呼ばれることがある)の実装の概略ブロック図である。課金デバイス1000は、プロセッサ1010、メモリ1030、およびバスシステム1050を含み得る。プロセッサとメモリは、バスシステムによって接続される。メモリは、命令を記憶するように構成される。プロセッサは、メモリに記憶された命令を実行するように構成される。符号化デバイスのメモリは、プログラムコードを記憶し、プロセッサは、メモリに記憶されたプログラムコードを呼び出して、本出願に記載される様々な課金処理方法、例えば図5から図7の実施形態に記載される処理ステップを実施し得る。反復を避けるために、本明細書では詳細は説明しない。
本出願のこの実施形態では、プロセッサ1010は、中央処理装置(Central Processing Unit、略称「CPU」)であることがあるし、あるいはプロセッサ1010は、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは別のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェア構成要素などであることがある。汎用プロセッサは、マイクロプロセッサであることがあるし、またはプロセッサは、任意の従来のプロセッサなどであることがある。
メモリ1030は、読取り専用メモリ(ROM)デバイスまたはランダムアクセスメモリ(RAM)デバイスを含むことがある。代替として、適当なタイプの任意のその他の記憶デバイスが、メモリ1030として使用されることがある。メモリ830は、バス1050を介してプロセッサ1010によってアクセスされるコードおよびデータ1031を含むことがある。メモリ1030は、オペレーティングシステム1033およびアプリケーションプログラム1035をさらに含むことがある。アプリケーションプログラム1035は、プロセッサ1010が本出願に記載される課金方法を実施することを可能にする少なくとも1つのプログラムを含む。例えば、アプリケーションプログラム1035は、アプリケーション1からNを含むことがあり、さらに、本出願に記載される課金方法を実施する課金アプリケーション(略称、課金アプリケーション)を含むことがある。
バスシステム1050は、データバスに加えて、電力バス、制御バス、および状態信号バスなどをさらに含むことがある。ただし、説明が分かりやすくなるように、図中の様々なタイプのバスは、バスシステム1050として示されている。
任意選択で、課金デバイス1000は、トランシーバ1070などの1つまたは複数の入出力デバイスをさらに含むことがある。トランシーバ1070は、別のネットワーク機能装置と通信するように構成される。
当業者なら、本明細書に開示および記載される様々な例示的な論理ブロック、モジュール、およびアルゴリズムステップを参照して記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せによって実装されることが可能であることを理解することができる。実施形態がソフトウェアによって実装される場合には、例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体に記憶され、あるいはコンピュータ可読媒体を介して送信され、ハードウェア型の処理ユニットによって実行されることがある。コンピュータ可読媒体は、データ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体、または(例えば通信プロトコルに従う)1つの場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含むことがある。このように、コンピュータ可読媒体は、一般に、(1)非一時的な有形のコンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応することがある。データ記憶媒体は、本出願に記載される技術を実装するための命令、コード、および/またはデータ構造を取り出すために1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされることが可能な任意の使用可能な媒体であり得る。コンピュータプログラム製品が、コンピュータ可読媒体を含み得る。
限定されるわけではないが、一例では、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROM、または別のコンパクトディスク記憶装置、磁気ディスク記憶装置、または別の磁気記憶装置、フラッシュメモリ、あるいは所望のプログラムコードを命令またはデータ構造の形態で記憶するために使用されることが可能であり、かつコンピュータによってアクセス可能である、その他の任意の媒体を含み得る。さらに、任意の接続は、コンピュータ可読媒体と称されるのが適当である。例えば、命令が、ウェブサイト、サーバ、または別の遠隔ソースから、同軸ケーブル、光ファイバ、撚り対線、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を介して送信される場合には、同軸ケーブル、光ファイバ、撚り対線、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、またはその他の一時的媒体を含まず、実際には非一時的な有形の記憶媒体を意味することを理解されたい。本明細書で使用されるディスクおよびディスクは、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル汎用ディスク(DVD)、およびBlu-rayディスクを含む。磁気ディスクは、通常は磁気的にデータを再現し、光学ディスクは、レーザを用いて光学的にデータを再現する。上述の品目の組合せもまた、コンピュータ可読媒体の範囲に含まれるものとする。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、あるいはその他の等価な集積またはディスクリート論理回路などの、1つまたは複数のプロセッサによって実行されることがある。したがって、本明細書で使用される「プロセッサ」という用語は、本明細書に記載される技術を実装するのに適した前述の構造またはその他の任意の構造のうちのいずれか1つであることがある。さらに、いくつかの態様では、本明細書に記載される例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、符号化および復号を行うように構成された専用のハードウェアおよび/またはソフトウェアモジュール内に設けられることがあるし、あるいは結合されたコーデック内に組み込まれることがある。さらに、これらの技術は、1つまたは複数の回路または論理要素内で完全に実装されることがある。
本出願の技術は、集積回路(IC)またはICのグループ(例えばチップセット)を含む、様々な装置またはデバイスで実装され得る。本出願では、様々な構成要素、モジュール、またはユニットについて、開示される技術を実施するように構成された装置の機能態様を強調するように説明されているが、これらは、必ずしも異なるハードウェアユニットによって実装されるわけではない。実際には、上述のように、様々なユニットが、適当なソフトウェアおよび/またはファームウェアと組み合わせてコーデックハードウェアユニットに結合され得る、あるいは相互運用可能なハードウェアユニット(上述の1つまたは複数のプロセッサを含む)によって提供され得る。
以上の説明は、単に本出願の具体的な実装であり、本出願の保護範囲を限定することを意図しているわけではない。本出願に開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
本出願は、通信技術の分野に関し、詳細には、課金方法、装置、およびシステムに関する。
本出願は、2019年8月2日に中国国家知識産権局に出願され、「CHARGING METHOD、APPARATUS、AND SYSTEM」と題する中国特許出願第201910713756.3号明細書に対する優先権を主張するものであり、その全体が参照により本明細書に組み込まれる。
現在、4G通信システムでは、オンライン課金サービスおよびオフライン課金サービスは、異なる課金システムを用いることにより課金される。図1で示されるように、システム100における課金トリガー機能(charging trigger function)装置101は、Roインターフェースを介してオンライン課金システム102と通信し、またRfインターフェースを介してオフライン課金システム103と通信する。オンライン課金システム102は、オンライン課金サービスに対する課金を実施するように構成され、またオフライン課金システム103は、オフライン課金サービスに対する課金を実施するように構成される。オンライン課金またはオフライン課金を決定した後、CTF装置は、オンライン課金システム102またはオフライン課金システム103に対して、ダイアメータ課金要求を開始する。オンライン課金システム102またはオフライン課金システム103は、ダイアメータ課金要求における課金コマンドおよび要求タイプに基づいて対応する課金処理を実施し得る。
5G通信システムでは、サービスベースのオンライン/オフライン収束課金メッセージが使用され、リソース予約および使用情報報告が、格付けグループに基づいて実装される。使用情報が報告されると、担持される使用割当て管理表示は、その使用情報が割当てを有する使用情報かどうかを示して、割当てを有する使用情報の報告、または割当てのない使用情報の報告を実装する。割当ては、先行して、課金システムによりCTFに認可された割当てである。言い換えると、使用割当て管理表示は、割当てが、先行して課金システムから適用されており、その適用に基づいて課金システムにより認可されているかどうかを示す。
既存の5G通信システムで使用されるオンライン/オフライン収束課金メッセージは、セッションベースのトラフィック、持続期間リソース予約、および使用報告をサポートする。しかし、現在の収束課金システムは、イベント課金を正確に、かつ効率的に実装することができない。
本出願の実施形態は、イベント課金サービスに対する課金を実装するための課金方法、装置、およびシステムを提供する。
第1の態様によれば、本出願の実施形態は、課金方法を提供する。本方法は、以下のことを含む、すなわち、CHF装置は、課金トリガー機能CTF装置により送られた第1の課金要求を受け取り、ここで、第1の課金要求は、イベント課金情報を担持する。次いで、CHF装置は、イベント課金情報に基づいて、第1のイベント課金処理モードを決定し、第1の課金要求を第1のイベント課金処理モードに従って処理する。本方法によれば、CHF装置は、第1の課金要求に基づいて第1のイベント課金処理モードを決定し、イベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、イベント課金情報は、イベント課金を示す表示情報を含み、第1のイベント課金処理モードを決定する前に、CHF装置は、イベント課金表示情報に基づいて、第1の課金要求が、イベントサービスに対する課金要求であると決定する。したがって、CHF装置は、イベント課金サービスに対する要求を正確に決定し、次いで、その後の処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、またイベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。CHF装置は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、ワンタイムイベント課金要求であると決定し、第1の課金要求に基づいて、第1のイベント課金リソースを作成し、かつ第1のイベント課金リソースは、第3の課金要求を有しないと決定する。代替として、CHFは、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、非ワンタイムイベント課金要求であると決定し、第1の課金要求に基づいて、第1のイベント課金リソースを作成し、かつ第1のイベント課金リソースは、第3の課金要求を有すると決定する。CHF装置は、後続する処理を実施するための後続する第3の課金要求があるかどうかを決定する。例えば、後続する課金要求がない場合、第1のイベント課金リソースは、課金処理が完了した後、リリースされる。代替として、後続する課金要求がある場合、第1のイベント課金リソースは保持される。
可能な実装では、イベント課金情報は、第1のイベント課金処理モードをさらに含み、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置は、処理効率を高めるために、イベント課金処理モードを第1の課金要求から直接取得し得る。
可能な実装では、第1の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含む。CHF装置が、イベント課金情報に基づいて、第1のイベント課金処理モードを決定することは、以下のことを含む、すなわち、CHF装置は、ユーザ識別子に基づいてユーザ情報を取得し、かつイベント課金を示す表示情報、ユーザ情報、およびサービスタイプを示すパラメータに基づいて、第1のイベント課金処理モードを決定し、ここで、第1のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置は、処理効率を高めるために、第1の課金要求から、イベント課金処理モードを直接取得し得る。
可能な実装では、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が、非ワンタイムイベント課金要求であると決定した後、CHF装置が、イベント課金情報に基づいてイベント課金処理モードを決定することは、第1のイベント課金処理モードが、イベント割当ての適用であると決定することを含む。
可能な実装では、第1のイベント課金処理モードは、直接控除であり、またCHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいて格付けを実施し、かつ格付け結果に基づいて、ユーザの勘定残高からの控除を実施することを含む。
可能な実装では、第1のイベント課金処理モードは、オフラインイベント報告であり、またCHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいて、イベント課金データ記録を生成することを含む。
可能な実装では、第1のイベント課金処理モードは、イベント割当ての適用であり、CHF装置が、第1のイベント課金処理モードに従って第1の課金要求を処理することは、イベント課金情報に基づいて格付けを実施し、かつ格付けに基づいてイベント割当てを認可することを含む。
可能な実装では、CHF装置は、第1の課金要求に対する第1の課金応答をCTF装置にさらに返し、第1の課金応答は、決定された第1のイベント課金処理モードを担持する。
可能な実装では、イベント課金処理モードは、直接控除であり、第1の課金要求を処理した後、CHF装置は、イベント課金サービスに対する第2の課金要求を受け取り、ここで、第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を含み、第2のイベント課金処理モードは返済であり、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、また第1のイベント課金リソースの識別子は、第1の課金要求に対する課金応答から取得される。加えて、CHF装置は、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が返済される。
可能な実装では、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、第2の課金要求は、ワンタイムイベント課金の表示パラメータを担持する。CHF装置は、第2の課金要求に基づいて、第2のイベント課金リソースをさらに作成する。
可能な実装では、第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、またCHF装置は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。
可能な実装では、第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、またCHF装置は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。
可能な実装では、第1の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第1の課金要求が、第1のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置は、第1のイベント課金リソースをさらに作成する。本方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、第2の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第2の課金要求が、第2のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置は、第2のイベント課金リソースをさらに作成する。この方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持し、第1の課金要求を処理することは、イベント識別子および/またはイベント量に基づいて課金要求を処理することを含む。この方法によれば、複数の課金サービスが生じるごとに課金処理を行うことを回避するために、1つまたは複数のイベントの生成が、1つの課金要求において表され得る。このように、課金処理が簡単化される。
第2の態様によれば、本出願の実施形態は、課金方法を提供する。方法は以下のことを含む、すなわち、CTF装置は、イベント課金サービスの課金サービスが生じたと決定し、第1の課金要求を課金機能CHF装置に送り、ここで、第1の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用される。CTF装置は、第1の課金要求のものであって、CHF装置により送られた第1の課金応答を受け取り、ここで、第1の課金応答は、決定されたイベント課金処理モードに従って、第1の課金要求を処理した結果を含む。この方法によれば、CTF装置は、第1の課金要求におけるイベント課金情報を担持し、したがって、CHF装置は、第1の課金要求に基づいて第1のイベント課金処理モードを決定し、かつイベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。
可能な実装では、第1の課金応答は、CHFにより決定されたイベント課金処理モードをさらに含む。
可能な実装では、第1のイベント課金処理モードは、直接控除であり、第1の課金応答は、第1の課金要求に基づいて作成された第1のイベント課金リソースの識別子を含み、またCTF装置は、CHF装置により送られた第1の課金応答を受け取る。次いで、CTF装置は、イベント課金サービスが実施されるのに失敗したとさらに決定し、イベント課金サービスに対する第2の課金要求を送り、ここで、第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子と、を含み、また第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が返済される。
可能な実装では、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、また第2の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持する、または第2の課金要求は、第1のイベント課金リソースに対する更新要求である、もしくは第1のイベント課金リソースに対するリリース要求である。
可能な実装では、第1の課金要求または第2の課金要求は、再送信決定パラメータをさらに含み、また再送信決定パラメータは、第1の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される、かつ/または
第2の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータは、第2の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される。この方法によれば、CHFは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。
可能な実装では、CTF装置は、サービスイベントが生じた回数の数量を決定し、また課金要求は、イベント識別子およびイベント量をさらに担持する。この方法によれば、複数のイベント課金サービスが生じるごとに課金処理を行うことを回避するために、1つまたは複数のイベントの生成が、1つの課金要求において表され得る。このように、課金処理が簡単化される。
第3の態様によれば、CHF装置が提供される。装置は、第1の態様および第2の態様におけるCHF装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。
第4の態様によれば、CTF装置が提供される。装置は、第1の態様および第2の態様におけるCTF装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。
第5の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金トリガー機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第6の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第2の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第7の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。
第8の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第2の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。
第9の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第1の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第10の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第2の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。
第11の態様によれば、本出願の実施形態は、第3の態様における課金機能装置、および第4の態様における課金トリガー機能装置を含む課金システムを提供する。
本出願の第2から第11の態様における技術的な解決策は、第1の態様のものと一致していることを理解されたい。これらの態様、および対応する実行可能な実装により達成される有益な効果は同様であり、詳細を再度述べないものとする。
本出願の実施形態において、または背景において、技術的解決策をより明確に述べるために、以下は、本出願の実施形態または背景を説明するための添付図面を述べる。
現在の技術における課金システムの概略的なブロック図である。
本出願の実施形態によるネットワークアーキテクチャの概略的なブロック図である。
本出願の実施形態による課金システムの概略的なブロック図である。
本出願の実施形態による課金フレームワークの概略的なブロック図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金方法の流れ図である。
本出願の実施形態による課金機能装置の概略的なブロック図である。
本出願の実施形態による課金トリガー機能装置の概略的なブロック図である。
本出願の実施形態による課金デバイスの概略的なブロック図である。
以下は、本出願の実施形態における添付図面を参照して本出願の実施形態を述べる。
図2は、本出願の実施形態が適用できる可能なネットワークアーキテクチャの概略図である。ネットワークアーキテクチャ200は、第5世代移動体通信技術(the 5th Generation mobile communication technology、5G)ネットワークアーキテクチャである。5Gアーキテクチャは、1個のユーザ機器201、無線アクセスネットワーク(radio access network、RAN)202、アクセスおよびモビリティ管理機能(access and mobility management function、AMF)装置206、セッション管理機能(session management function、SMF)装置205、ユーザプレーン機能(user plane function、UPF)装置203、ネットワーク露出機能(Network Exposure Function、NEF)装置208、ショートメッセージサービス機能(Short Message Service Function、SMSF)装置209、データネットワーク(data network、DN)204、および課金機能(charging function、CHF)装置207を含み得る。さらに、図2で示されたネットワーク要素に加えて、本出願のこの実施形態におけるアーキテクチャは、例えば、モノのインターネットメッセージゲートウェイなど、イベント課金を使用する別のネットワーク要素または機能をさらに含み得る。図2の機能モジュール間の通信は、次世代(next generation、NG)インターフェース、またはサービスベースのインターフェース(service based interface、SBI)を介する接続を確立することにより実装され得る。例えば、RANデバイスは、NGインターフェース2(略してN2)を介するAMFへの制御プレーンシグナリング接続を確立し得る、またNEFデバイスは、SBIインターフェースNnefを介して外部サービスを提供し得る。
ユーザ機器は、無線送受信機機能を有するデバイスである。ユーザ機器は、屋内デバイス、屋外デバイス、手持ち式デバイス、もしくは車両搭載デバイスを含む陸上で展開され得る、または水面上で(例えば、船上で)展開され得る、または空中で(例えば、航空機、気球、もしくは衛星で)展開され得る。
以下は、本出願の実施形態における添付図面を参照して、本出願の実施形態における技術的解決策を述べる。本出願の記述において、その他の形で指定されない限り、「複数の」は、2つ以上を意味する。さらに、本出願の実施形態における技術的解決策の明確な記述を容易にするために、本出願の実施形態では、「第1」および「第2」などの用語は、同じ対象物の間、または機能および目的が基本的に同じである同様の対象物の間を区別するために使用される。当業者であれば、「第1」および「第2」などの用語は、量、または実行順序を限定するように意図されたものではなく、また「第1」および「第2」などの用語は、明確な差を示すものでもないことを理解するはずである。本発明における「Aおよび/またはB」は、AまたはBのいずれか一方、またはAおよびBを含むものと説明され得る。
図3は、本出願の実施形態による課金アーキテクチャ300の概略図である。課金アーキテクチャ300は、課金トリガー機能(charging trigger function、CTF)装置31および課金システム32を含む。課金トリガー機能装置31および課金システム32は、サービスベースのインターフェースを介して、互いに通信し得る。サービスベースのインターフェースは、RESTfulおよび遠隔手続き呼び出し(remote procedure call、RPC)など、リソースベースの機能露出インターフェースを指す。図2のネットワークアーキテクチャを参照すると、CTF装置101は、SMF装置205に配置され得る。言い換えると、SMF装置205は、CTF装置31の機能を統合する。課金システム32は、課金機能(charging function、CHF)装置207を含む。CHF装置207は、オンライン(online)課金、およびオフライン(offline)課金を実施し得る。すなわち、課金システム32は、収束課金システムであり得る。課金システム32は、課金が実施されるときに必要な勘定残高管理機能(account balance management function、ABMF)装置、および格付け機能(rating function、RF)装置をさらに含む。ABMF装置は、ユーザの預金口座を記憶し、かつ管理するように構成され、またRF装置は、サービスの使用情報に対する格付けを実施するように構成される。図3で示された課金トリガー機能装置31および課金システム32に加えて、本出願のこの実施形態における課金アーキテクチャは、請求(billing)装置をさらに含み得る。請求装置および課金システム32は、課金ゲートウェイ機能(charging gateway function、CGF)装置を用いることにより、互いに通信し得る。CGF装置は、課金システムの一部として課金システムに統合され得る、または請求装置の一部として請求装置に統合され得る、または独立したネットワーク要素として存在し得る。以下の内容が、さらに詳細に述べられる。
課金トリガー機能装置101は、課金開始要求を生成し、課金システム32が、課金開始要求を処理する。本出願のこの実施形態では、課金トリガー機能装置31はまた、クライアントと見なされ、また課金システム32は、サーバと見なされ得る。課金トリガー機能装置31および課金システム32は、1つまたは複数のプロセッサ、および1つまたは複数のプロセッサに結合されたメモリを含み得る。メモリは、これだけに限らないが、本明細書で述べられるように、コンピュータにアクセスできる命令またはデータ構造の形式の望ましいプログラムコードを記憶するために使用されることのできるRAM、ROM、EEPROM、フラッシュメモリ、または任意の他の媒体を含み得る。
図4は、図3における課金アーキテクチャの特定の実装である。CHF装置207は、サービスベースのインターフェースRestfulを介して外部サービスを提供し得る。インターフェースの名前は、Nchfであり、CTF装置101は、インターフェースNchfを介して、CHF装置207にアクセスし得る。課金システムは、CHF装置207、ABMF装置210、RF装置212、およびCGF装置211を含む。
図5は、本出願による課金方法500の概略的な流れ図である。方法500は、図2におけるネットワークアーキテクチャに、かつ図3および図4で示される課金アーキテクチャに適用され得る。実際には、方法500はまた、別の通信シナリオにも適用され得る。これは、本出願の実施形態に限定されない。図5で示されるように、方法500は、以下の内容を含む。
ステップ501:現在のサービスをイベント課金サービスとして構成し、かつCTF装置101におけるサービスの課金ルールを構成する。
ステップ501で、CTF装置101が、SMF装置205に配置された場合、イベント課金サービスおよび課金ルールは、ポリシを送達することにより、CTF装置101におけるPCFにより動的に構成され得る、またはCTF装置101において事前に構成され得る。任意選択で、CTF装置101が、別のネットワーク機能装置に位置する場合、イベント課金サービスの課金ルールは、CTF装置101において事前に構成される。操作者は、サービスがイベント課金サービスであることを示すために、CTF装置101においてサービス課金ルールを構成し得る。サービス課金ルールは、報告条件、および/またはイベント課金サービスの課金処理モードをさらに含む。課金処理モードは、(1)直接控除、(2)予約ベースのイベント課金(割当ての適用、および割当ての使用報告を含む)、(3)オフラインイベント報告、(4)返済、および同様のものなどを含む。
直接控除は、CHF装置207が、CTF装置101により報告された課金要求に基づいて格付けを実施し、格付け結果に基づき、ユーザの勘定残高からの控除を実施することを意味する。オフラインイベント報告は、CHF装置207が、CTF装置101により報告された課金要求に基づいてイベント課金データ記録(Charging Data Record、CDR)を生成することを意味し、CDRはまたイベント課金請求書とも呼ばれる。イベント割当ての適用は、CHF装置207が、CTF装置101により報告された課金要求に基づいて格付けを実施し、勘定残高におけるリソースを予約する(すなわち、ユーザへの割当てを認可する)ことを意味する。割当て使用報告は、サービスが課金報告を満たすとき、認可された割当てを有する使用情報が報告されることを意味する。返済は、直接控除が実施されるイベント課金サービスに対して、イベント課金サービスが実施されるのに失敗した場合、直接控除における控除量が返済されることを意味する。
課金処理モードにおいて、リソースを求める第1の課金要求に対するイベント課金処理モードは、第1のイベント課金処理モードと呼ばれる。第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告を含む。第2の課金要求に対するイベント課金処理モードは、第2のイベント課金処理モードと呼ばれる。第2のイベント課金処理モードは、返済を含む。
課金処理モードにおいて、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、また課金システムに第1のイベント課金リソースを作成するように要求するために使用される。第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、課金システムに第2のイベント課金リソースを作成するように要求するために使用される、または第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、課金システムに第1のイベント課金リソースを更新するように要求するために使用される、または第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、第1のイベント課金リソースに対応する課金データが更新された後、第1のイベント課金リソースをリリースするように課金システムに要求するために使用される。
例えば、課金要求は、イベント送信側および受信側、イベント発生時間、ならびに/またはイベントコンテンツサイズを担持する。
ステップ502:CTF装置101は、第1の課金要求をCHF装置207に送り、ここで、第1の課金要求は、イベント課金情報を担持する。
CTF装置101は、イベント課金サービスの使用をモニタし、イベント課金サービスの課金イベントが生じたと決定する。課金イベントは、課金される必要のあるイベントであり、課金報告をトリガーする課金イベントである。CHF装置207は、構成されたサービス課金ルールに従って、第1の課金要求を生成する。第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、CHF装置207に送られる。CTF装置101が、SMF装置205に位置している場合、課金イベントが生ずることは、新しいPDUセッションが確立されることであり得る。CTF装置101が、システムの別の機能装置に位置する場合、課金イベントが生ずることは、CTF装置101が、ネットワーク機能APIの起動メッセージを受け取ること、またはネットワーク機能APIに対する起動応答を返すことであり得る。
イベント課金情報は、イベント課金を示す表示情報を含み、また第1の課金要求が、イベントサービスに対する課金要求であると決定するために使用される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータであり得る(例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モードなど)。
イベント課金情報は、ワンタイムイベント課金の表示パラメータ、または非ワンタイムイベント課金の表示パラメータをさらに含む。ワンタイムイベント課金の表示パラメータは、第1のイベント課金リソースが、第1の課金要求に基づいて作成された後、第1のイベント課金リソースは、後続する課金要求を有しないことを示す。
リソースイベント課金リソース作成は、第1のイベント課金処理モードをさらに担持し得る。第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。加えて、リソースイベント課金リソース作成は、イベント識別子、イベント量、再送信決定パラメータ、イベントの詳細などのうちの1つまたは複数のものをさらに担持し得る。イベント量は、イベントの生じた回数の数量を示す。イベント識別子は、サービスイベントを示し、例えば、サービスイベントが、API起動、またはSMS送信であることを示す。
ステップ503:CHF装置207は、第1の課金要求に基づいて、イベント課金サービスに対する課金処理を実施する。
例えば、第1の課金要求が、第1のイベント課金リソースに対する作成要求であるとき、CHF装置207は、第1の課金要求に対する第1のイベント課金リソースを作成し、かつリソース識別子を第1のイベント課金リソースに割り振る。
特に、CHF装置207は、第1の課金要求がワンタイムイベント課金であるかどうかを決定する必要がさらにあり、CHF装置207が、第1の課金要求はワンタイムイベント課金要求であると決定した場合、CHF装置207は、第1のイベント課金リソースは、後続する課金要求を有しないと決定する。したがって、第1の課金要求に基づいて、課金リソースを作成し、かつ課金処理を実施した後、CHF装置207は、もはや第1のイベント課金リソースのコンテキストを保持しない、例えば、第1のイベント課金リソースをリリースする、または第1のイベント課金リソースをデータベースに記憶する。代替として、CHF装置207が、第1の課金要求は、非ワンタイムイベント課金要求であると決定した場合、CHF装置207は、第1の課金要求に基づいて第1のイベント課金リソースを作成し、第1のイベント課金リソースは、第1のイベント課金リソースをリリースするための後続する課金要求を有すると決定し、かつ第1のイベント課金リソースのコンテキストを保持し、後続する課金要求を処理できるようにする。第1の課金要求が、ワンタイムイベント課金であるかどうかを、CHF装置207により決定するための特定の方法は、以下のことを含む、すなわち、イベント課金情報が、ワンタイムイベント課金の表示パラメータをさらに含む場合、CHF装置207は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求は、ワンタイムイベント課金要求である、または非ワンタイム課金要求であると決定する。第1の課金要求が、ワンタイムイベント課金のパラメータを担持しないが、課金処理モードを決定するための情報を担持する場合、CHF装置207は、決定された課金処理モードに従って、第1の課金要求がワンタイムイベント課金要求であるかどうかをさらに決定する。例えば、決定されたイベント課金処理モードが、直接控除またはオフラインイベント報告である場合、CHF装置207は、第1の課金要求がワンタイムイベント課金要求であると決定する。決定されたイベント課金処理モードが、リソース予約である場合、CHF装置207は、第1の課金要求は、非ワンタイムイベント課金要求であると決定する。イベント課金情報が、イベント課金処理モードをさらに含む場合、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。CHF装置207は、リソースイベント課金リソース作成において担持されたイベント課金処理モードに従って、直接控除、オフラインイベント報告、またはサービスに対するイベント割当ての適用を実施し得る。
イベント課金情報が、第1のイベント課金処理モードを含まない場合、CHF装置207は、第1の課金要求に基づいて、第1のイベント課金処理モードを決定し、決定された第1のイベント課金処理モードに従って、第1の課金要求を処理し得る。決定された第1のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。例えば、CHF装置207は、第1の課金要求において担持されたユーザ識別子に基づいて、ユーザ情報を取得し、かつ取得されたユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、CHF装置207は、例えば、API起動のサービスタイプなど、第1の課金要求におけるサービスタイプのパラメータに基づいてイベント課金処理モードを決定してもよい。代替として、CHF装置207は、第1の課金要求におけるサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。CHF装置207は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照してイベント課金処理モードを決定し得る。
イベント課金情報が、イベント課金処理モードを含まない場合、CHF装置207は、イベント課金表示情報に基づいて、第1の課金要求は、イベント課金サービスに対する課金要求であると決定し、第1の課金要求におけるユーザ識別子に基づいて、ユーザ情報を取得し、ユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、CHF装置207は、イベント課金情報に含まれるサービスタイプのパラメータ、またはサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。CHF装置207は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照して、イベント課金処理モードを決定してもよい。
イベント課金情報が、イベント課金処理モードを含まない場合、CHF装置207は、イベント課金情報に含まれる非ワンタイムイベント課金の表示パラメータに基づいて、イベント課金処理モードをさらに決定し得る。特に、イベント課金情報が、非ワンタイムイベント課金の表示パラメータを含む場合、CHF装置207は、第1のイベント課金処理モードは、イベント割当ての適用であると決定する。
イベント課金情報は、再送信決定パラメータをさらに含む。第1の課金要求に対して、第1のイベント課金リソースを作成する前に、CHF装置207は、再送信決定パラメータに基づいて、第1の課金要求が、第1のイベント課金リソースに対する再送信された作成要求ではないと決定した後、第1のイベント課金リソースを作成する。再送信決定パラメータは、大域的に一意の専用の識別子であり得る、またはユーザ識別子とサービス特有の識別子の組合せであり得る。サービス特有の識別子は、ユーザドメインにおいてのみ一意である。
ステップ504:CHF装置207は、第1の課金要求に対する第1の課金応答をCTF装置101に送り、ここで、第1の課金応答は、第1のイベント課金リソースの識別子を担持する。
任意選択で、第1の課金要求が、第1のイベント課金処理モードを担持していない場合、第1の課金応答は、例えば、直接控除、イベント割当ての適用、またはオフラインイベント報告など、CHF装置207により決定された第1のイベント課金処理モードをさらに担持する。
ステップ505:CTF装置101は、第1の課金要求の控除量を返済するように要求するために、第2の課金要求をCHF装置207に送る。
第2の課金要求は、第2のイベント課金リソースに対する作成要求、または第1のイベント課金リソースに対する更新要求、または第1のイベント課金リソースに対する削除要求であり得る。
第1のイベント処理モードが直接控除であるとき、CTF装置101は、イベント課金サービスが実施されるのに失敗したと決定し、またCTF装置101は、イベント課金サービスに対する第2の課金要求を送る。第2の課金要求は、第2のイベント課金リソースに対する作成要求、または、第1のイベント課金リソースに対する更新要求、または第1のイベント課金リソースに対する削除要求であり得る。好ましくは、第2の課金要求は、第2のイベント課金リソースに対する作成要求である。第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を含み、また第2のイベント処理モードは、返済である。第2のイベント課金処理モードは、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される。第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
例えば、イベント課金サービスが、実施されるのに失敗し、かつ第1のイベント課金処理モードが直接控除である場合、第2の課金要求は、以下のようになり得る、
課金作成要求
{
oneEventCharging:真
eventCHMethod:返済
}
ここにおいて、「課金作成要求」は、第2の課金要求が、リソース作成要求であることを示す。第2の課金要求は、ワンタイムイベント課金のパラメータ「oneEventcharging」を担持しており、またワンタイムイベント課金のパラメータは、後続するイベント課金要求があるかどうかを示すために使用される。oneEventchargingの値は真であり、後続するリソース更新課金要求、またはリソース削除課金要求がないことを示している。リソース更新課金要求は、第2のイベント課金処理モード「eventCHMethod」をさらに担持する。第2のイベント課金処理モードの値は、返済であり、イベント課金処理モードは返済であることを示している。
ステップ506:CHF装置207は、第2の課金要求に基づいて課金処理を実施し、第2の課金要求に対する第2の課金応答をCTF装置101に返す。
第2の課金要求は、第1のイベント課金リソースに対する更新要求、または削除要求であり得、第2のイベント課金処理モードを含む。第2のイベント課金処理モードは返済である。第2のイベント処理モードは、第1の課金要求を用いることにより実施された直接控除における控除量を返済するようにCHF装置207に示す。CHF装置207は、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。加えて、CHF装置207は、第2の課金要求に基づいて、第1のイベント課金リソースをさらにリリースする。第2の課金要求に対する応答は、返済動作の結果である。
別の実装では、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり得るが、第2の課金要求は、第2のイベント課金処理モード、および第1のイベント課金リソースの識別子を担持し、また第2のイベント課金処理モードは返済であり、第1の課金要求を用いることにより実施された直接控除における控除量を返済するようにCHF装置207に示すために使用される。第2の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持し得る。CHF装置207は、第2の課金要求に基づいて第2のイベント課金リソースを作成し、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定し、かつ控除量をユーザの勘定残高に戻す。
任意選択で、第2の課金要求は、再送信決定パラメータをさらに含む。再送信決定パラメータに基づいて、第2の課金要求が、第2のイベント課金リソースに対する再送信された作成要求ではないと決定した後、CHF装置207は第2のイベント課金リソースを作成する。
ステップ507:CTF装置101は、第3の課金要求をCHF装置207に送る。
第1の課金要求が、リソース作成要求であり、かつ第1の課金処理モードが、イベント割当ての適用であるとき、CTF装置は、イベント課金サービスの実行を完了した後、第3の課金要求をCHFにさらに送る。第3の課金要求は、第3の課金処理モード、すなわち、オフラインイベント報告を担持する。
第3の課金要求は、リソース更新要求、またはリソース削除要求であり得る。第3の課金要求は、第1のイベント課金リソースの識別子をさらに含み得る。
ステップ508:CHF装置207は、第2の課金要求に基づいて課金処理を実施し、かつ第3の課金要求に対する第3の課金応答をCTF装置101に返す。
第3の課金要求を受け取った後、CHF装置207は、第3の課金処理モードに従って、CDRを生成する。CHF装置207は、第3の課金応答をCTF装置に返す。
前述の方法によれば、CHF装置207は、収束課金システムを用いることにより、イベント課金を実装し得、したがって、CTFによりイベント課金を処理するための方法は、課金システムによりイベント課金を処理するための方法と一致して、課金システムにより実施される処理と、サービスに対してCTFにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。
図6は、本出願の実施形態による、CTF装置101により送られた課金要求をCHF装置207が受け取った後でCHF装置207によって実施される対応する処理の詳細な流れ図である。この実施形態では、CTF装置101により送られた第1の課金要求は、イベント課金処理モードを担持せず、CHF装置207は、ユーザ情報および/またはサービス情報に基づいてイベント課金処理モードを決定する。図6に対応する手順は、以下のステップを含む。
ステップ601:CHF装置207が、CTF装置101により送られた第1の課金要求を受け取る。第1の課金要求については、ステップ502の説明を参照されたい。
一例では、第1の課金要求は、以下のように第1のイベント課金リソースに対する作成要求であることがある。
Charging Create Request
{
oneEventCharging: true
}
本明細書では、「課金作成要求」は、そのメッセージが第1の課金要求であることを示す。第1の課金要求は、ワンタイム課金のパラメータ「oneEventcharging」を担持し、ワンタイム課金のパラメータは、後続の第3の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が真である場合には、それは、後続の第3の課金要求がないことを示す。第3の課金要求は、リソース更新課金要求またはリソース削除課金要求である。
任意選択で、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持することがある。CTF装置101は、各サービスの各タイプの課金イベントにイベント識別子を割り振る。すなわち、イベント識別子は、イベントのタイプを示す。例えば、ユーザ状態を問い合わせるネットワーク能力APIに割り振られるイベント識別子は、NEF_GetUserStatusである。イベント量は、イベントの発生回数の数量を示す。例えば、イベント量が3であるときには、それは、ユーザ状態のネットワーク能力が3回問い合わせられたことを示す。課金要求がイベントデータを担持しない場合には、それは、イベントの発生回数の数量が1であることを示す。イベント識別子およびイベント量を担持するリソースイベント課金リソース作成の例は、以下のとおりである。
Charging Create Request
{
Multiple Unit Usage
Requested Unit
EventID:NEF_GetUserStatus
EventNum:1
}
本明細書では、「EventID:NEF_GetUserStatus」は、イベント識別子がNEF_GetUserStatusであることを示す。本明細書では、「EventNum:1」は、イベントが使用された回数の数量が1であることを示す。
ステップ602:CHF装置207が、第1の課金要求がイベントサービスに対する課金要求であると決定する。
第1の課金要求は、イベント課金を示す表示情報を担持し、CHF装置207は、イベント課金を示す表示情報に基づいて、第1の課金要求がイベント課金サービスに対する課金要求であると決定する。したがって、CHF装置207が第1の課金要求についての第1のイベント課金処理モードを決定する必要があると決定される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータ(例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モード)であり得る。
一例では、CHF装置207は、oneEventcharging(すなわちワンタイム課金要求パラメータ)に基づいて、第1の課金要求がイベント課金サービスに対する課金要求であると決定することがある。代替として、第1の課金要求は、イベントサービス識別子(例えばイベントID)を担持し、CHF装置207は、イベント課金サービス識別子に基づいて、第1の課金要求がイベント課金サービスに対する課金要求であると決定する。
ステップ603:CHF装置207が、第1の課金要求に基づいて、第1のイベント課金処理モードを決定する。
CHF装置207は、第1の課金要求内のユーザ識別子、サービスタイプのパラメータまたはサービス状態のパラメータに基づいて、第1の課金要求の第1のイベント課金処理モードを決定することがある。例えば、第1の課金要求は、サービス状態を示すサービス状態パラメータを担持する。サービス状態が、サービスが発生する前である場合には、CHF装置207によって実施される課金処理は、直接控除である。サービス状態が、サービスが発生した後である場合には、CHF装置207によって実施される課金処理は、CDRを生成することである。一例では、サービス状態のパラメータは、サービス要求、またはサービス応答であり得る。CHF装置207は、サービス要求について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生する前であると決定することがある。CHF装置207は、サービス応答について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生した後であると決定することがある。
任意選択で、CHF装置207は、さらに、第1の課金要求内のユーザ識別子に基づいてユーザ情報を取得し、課金要求のユーザが前払いのユーザであると決定し、第1のイベント課金処理モードが直接控除であると決定し、課金要求に対して直接控除を実施することがある。代替として、CHF装置207は、課金要求のユーザが後払いのユーザであると決定し、第1のイベント課金処理モードがオフラインイベント報告であると決定し、課金要求に基づいてCDRを生成することがある。
任意選択で、CHF装置207は、さらに、イベント課金情報に含まれるワンタイムイベント課金の表示パラメータに基づいてイベント課金処理モードを決定することがある。具体的には、イベント課金情報がワンタイムイベント課金の表示パラメータを含む場合には、それは、第1の課金要求が後続の第3の課金要求を有することを示し、CHF装置は、第1のイベント課金処理モードがイベント割当ての適用であると決定する。
ステップ604:CHF装置207が、第1の課金要求がワンタイム課金要求であるかどうかを決定する。第1の課金要求がワンタイム課金要求である場合には、ステップ605が実施される。第1の課金要求がワンタイム課金要求でない場合には、ステップ609が実施される。
第1の課金要求は、ワンタイムイベント課金のパラメータ(例えばoneEventCharging)を担持する。ワンタイムイベント課金のパラメータの値が真である場合には、CHF装置207は、第1の課金要求がワンタイム課金要求である、すなわちイベント課金サービスが後続の第3の課金要求を有していないと決定する。ワンタイムイベント課金のパラメータの値が偽である場合には、CHF装置207は、第1の課金要求が非ワンタイム課金要求である、すなわちイベント課金サービスが後続の第3の課金要求を有すると決定する。
第1の課金要求がワンタイムイベント課金のパラメータを担持し、第1の課金要求が非ワンタイム課金要求であると示すことは、以下の例であることがある。
Charging Create Request
{ Multiple Unit Usage
Requested Unit
EventID:NEF_GetUserStatus
EventNum:1
oneEventCharging:false
}
本明細書では、課金作成要求は、メッセージがイベント課金リソースに対する作成要求であることを示す。本明細書では、「Multiple Unit Usage」は、サービスユニットの利用を示す。例えば、イベントIDは、イベント識別子を示し、NEF_GetUserStatusは、イベント識別子がNEF_GetUserStatusであることを示す。EventNumは、イベント課金サービスについて、イベントの発生回数の数量が1であることを示す。本明細書では、リソースイベント課金リソース作成に担持されるワンタイム課金のパラメータ「oneEventcharging」は、後続の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が偽である場合には、それは、後続のリソース更新課金要求またはリソース削除課金要求がある、すなわち第1の課金要求が非ワンタイム課金要求であることを示す。
ステップ605:CHF装置207が、決定された第1のイベント課金処理モードに従って、課金処理を実施する。
第1のイベント課金処理モードが直接控除である場合には、CHF装置207は、第1の課金要求に基づいて格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施する。格付けは、ユーザの預金残高が十分である場合には、CHFが価格を表す通貨単位の量を計算し、要求された単位または内部単位の量に基づいてユーザの勘定残高から計算された量を控除することを意味する。
第1のイベント課金処理モードがオフラインイベント報告である場合には、第1の課金要求に基づいて、イベント課金データ記録が生成される。
第1のイベント課金処理モードがイベント割当ての適用である場合には、イベント課金情報に基づいて格付けが実施され、格付けに基づいてイベント割当てが認可される。
第1の課金要求がワンタイム課金要求であるので、第1の課金要求に対して課金処理を実施した後で、CHF装置207は、さらに第1のイベント課金リソースをリリースする必要がある。
ステップ606:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置によって決定された第1のイベント課金処理モードを担持する。CHF装置207によって決定された第1のイベント課金処理モードは、直接控除またはCDR生成である。
第1の課金応答は、CHF装置207によって作成されたイベントリソース識別子をさらに担持する。第1のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
リソース作成課金応答は、以下であることがある。
Charging Create Response
{
EventChargingHandling: {Debit or Record}
本明細書では、「Charging Create Response」は、リソースについて課金応答を作成することを示す。本明細書では、「EventChargingHandling」パラメータは、CHF装置207によって決定された第1のイベント課金処理モードを担持し、ここで、「Debit」は、CHF装置207によって決定された課金処理モードが直接控除であることを示す。本明細書では、「Record」は、CHFによって決定された課金処理モードがCDRを生成することであることを示し、この課金処理モードは、オフラインイベント報告に対応する。
ステップ607:CHF装置207が、CTF装置101により送られた第2の課金要求を受け取る。
第1のイベント課金処理モードが直接控除であるときには、第1の課金応答を受け取った後で、CTF装置101は、イベント課金サービスが実施されるのに失敗したと決定し、CTF装置101は、イベント課金サービスについて第2の課金要求を送る。第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子とを含み、第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
第2の課金要求の詳細な説明については、ステップ505の説明を参照されたい。本出願のこの実施形態では、詳細を改めて説明しない。
ステップ608:CHF装置207が、第2の課金要求に対する第2の課金応答をCTF装置に返す。ここで、この課金応答は、CHF装置207によって決定された課金処理モードを担持する。CHF装置207によって決定された課金処理モードは、直接控除またはイベント割当ての適用である。
ステップ608の説明については、ステップ506を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。
ステップ609:CHF装置207が、第1の課金要求内に担持される第1のイベント課金処理モードに従って課金処理を実施する。
第1のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第1のイベント課金リソース割当てが認可され、格付けに基づいて第1のイベント課金リソースの識別子が割り振られる。
ステップ610:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置によって決定された第1のイベント課金処理モードを担持する。CHF装置によって決定された第1のイベント課金処理モードは、割当ての認可である。第1の課金応答は、さらに、CHF装置207によって作成された第1のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ611:CHF装置207が、CTF装置101により送られた第3の課金要求を受け取る。
イベント課金サービスの実行を完了した後で、CTF装置は、第3の課金要求をCHF装置207に送る。第2の課金要求は、第1のイベント課金リソースに対する更新要求または削除要求であることがある。第3の課金要求は、第1のイベントリソース識別子を担持する。
さらに、第2の課金要求は、第2のイベント処理モードをさらに担持することがあり、第2のイベント処理モードは、割当て使用報告である。CHF装置207は、第2のイベント処理モードに従って、イベント課金データ記録を生成する。
ステップ612:CHF装置207が、第3の課金要求に対する第3の課金応答をCTF装置に返す。
任意選択で、ステップ601または607の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第1のイベント課金リソースまたは第2のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、CHF装置207は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をCTF装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、CHF装置207は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、CHF装置207は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。
この方法によれば、CHF装置207は、第1の課金要求に基づいて第1のイベント課金処理モードを決定して、サービスに対して課金システムにより実施される処理と、CTFにより実施される処理との間の不一致を回避することがあり、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止することがある。
図7は、本出願の実施形態による、CHF装置207がCTF装置101により送られた課金要求を受け取った後でCHF装置207によって実施される対応する処理の詳細な流れ図である。この実施形態では、CTF装置101により送られる第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1の課金要求内に担持される第1のイベント課金処理モードに従って第1のイベント課金処理モードを決定する。図7に対応する手順は、以下のステップを含む。
ステップ701:CHF装置207が、CTF装置101により送られた第1の課金要求を受け取る。第1の課金要求については、ステップ502の説明を参照されたい。
一例では、第1の課金要求は、以下のように第1のイベント課金リソースに対する作成要求であることがある。
Charging Create Request
{
oneEventCharging:true
eventCHMethod:debit
}
本明細書では、「課金作成要求」は、第1の課金要求が課金リソース作成要求であることを示す。第1の課金要求は、ワンタイム課金のパラメータ「oneEventcharging」を担持し、ワンタイム課金のパラメータは、後続の第3の課金要求があるかどうかを示すために使用される。「oneEventcharging」の値が真である場合には、それは、後続の第3の課金要求がないことを示す。第3の課金要求は、リソース更新課金要求またはリソース削除課金要求である。本明細書では、「eventCHMethod」は、第1のイベント課金処理モードであり、第1のイベント課金処理モードの値は、直接控除(debit)、オフラインイベント報告(記録)、またはイベント割当ての適用(予約)である可能性がある。
任意選択で、第1の課金要求は、イベント識別子および/またはイベント量をさらに担持することがある。例については、ステップ601の説明を参照されたい。
ステップ702:CHF装置207が、第1の課金要求がイベントサービスに対する課金要求であると決定する。ステップ702の詳細な説明については、ステップ602の説明を参照されたい。本発明のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ703:CHF装置207が、第1の課金要求に基づいて、第1のイベント課金処理モードを決定する。
第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1の課金要求に基づいて第1のイベント課金処理モードを決定する。
ステップ704:CHF装置207が、第1の課金要求がワンタイム課金要求であるかどうかを決定する。第1の課金要求がワンタイム課金要求である場合には、ステップ705が実施される。第1の課金要求がワンタイム課金要求でない場合には、ステップ709が実施される。
ステップ704の詳細な説明については、ステップ604を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ705:CHF装置が、決定された第1のイベント課金処理モードに従って、課金処理を実施する。ステップ705の詳細な説明については、ステップ605を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ706:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置207によって作成されたイベントリソース識別子を担持する。第1のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ707:CHF装置207が、CTF装置101により送られた第2の課金要求を受け取る。ステップ707の詳細な説明については、ステップ607を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ708:CHF装置207が、第2の課金要求に対する第2の課金応答をCTF装置に返す。
ステップ708の説明については、ステップ506を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。
ステップ709:CHF装置207が、第1の課金要求内に担持される第1のイベント課金処理モードに従って課金処理を実施する。
第1のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第1のイベント課金リソース割当てが認可され、格付けに基づいて第1のイベント課金リソースの識別子が割り振られる。
ステップ710:CHF装置207が、第1の課金要求に対する第1の課金応答をCTF装置に返す。
第1の課金応答は、CHF装置207によって作成された第1のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。
ステップ711:CHF装置207が、CTF装置101により送られた第3の課金要求を受け取る。ステップ711の詳細な説明については、ステップ611を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。
ステップ712:CHF装置207が、第3の課金要求に対する第3の課金応答をCTF装置に返す。
任意選択で、ステップ701または707の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第1のイベント課金リソースまたは第2のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、CHF装置207は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をCTF装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、CHF装置207は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、CHF装置207は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。
この方法によれば、CHF装置207は、収束課金システムを用いることによってイベント課金サービスの課金を実装することがある。第1の課金要求は、第1のイベント課金処理モードを担持し、CHF装置207は、第1のイベント課金処理モードに従って、処理を直接実施することがある。これにより、サービスに対して課金システムにより実施される処理と、CTFにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。
以上では、ネットワーク要素間の相互作用の観点から、本出願の実施形態で提供される解決策について主に説明した。前述の機能を実装するためには、課金機能装置および課金トリガー機能装置などのデバイスは、それらの機能を実施するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解され得る。当業者なら、本明細書に開示される実施形態に記載される例のモジュールおよびアルゴリズムステップと組み合わせて、本出願が、ハードウェア、またはハードウェアとコンピュータソフトウェアの組合せによって実装され得ることに容易に気づくであろう。機能がハードウェアによって実施されるか、コンピュータソフトウェアによって駆動されるハードウェアによって実施されるかは、これらの技術的解決策の特定の応用分野および設計上の制約によって決まる。当業者なら、異なる方法を使用して、説明された機能を特定の各応用分野のために実装することがあり得るが、その実装が本出願の範囲を超えると考えられるべきではない。
本出願の実施形態では、前述の方法例に基づいて、CTF装置101およびCHF装置207などのデバイスに対して機能モジュールの分割が実施されることがある。例えば、各機能モジュールはそれぞれの機能に対応する分割によって得られることがあるし、または、2つ以上の機能が1つの処理モジュールに統合されることがある。統合されたモジュールは、ハードウェアの形態で実装され得る、またはソフトウェア機能モジュールの形態で実装され得る。本出願の実施形態では、モジュールの分割は一例であり、単に論理機能分割であることに留意されたい。実際の実装では、別の分割方法が用いられることがある。
例えば、機能モジュールが統合的な分割によって得られるときには、図8は、装置800の構造の概略図である。装置800は、前述の実施形態における課金機能装置207であり得る、または課金機能装置207内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図8に示すように、この装置は、受信モジュール801と、決定モジュール802と、処理モジュール803と、送信モジュール804とを含む。
受信モジュール801は、課金トリガー機能CTF装置により送られた第1の課金要求を受け取るように構成され、第1の課金要求は、イベント課金情報を担持する。決定モジュール802は、イベント課金情報に基づいて第1のイベント課金処理モードを決定するように構成される。処理モジュール803は、第1のイベント課金処理モードに従って第1の課金要求を処理するように構成される。
任意選択で、イベント課金情報は、イベント課金を示す表示情報を含み、決定モジュール802は、イベント課金表示情報に基づいて、第1の課金要求がイベントサービスに対する課金要求であると決定するようにさらに構成される。
任意選択で、第1の課金要求は、第1のイベント課金リソースに対する作成要求であり、イベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。
決定モジュール802は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求がワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール803は、第1の課金要求に基づいて第1のイベント課金リソースを作成するようにさらに構成され、決定モジュール802は、第1のイベント課金リソースが第2の課金要求を有していないと決定するようにさらに構成される。
代替として、決定モジュール802は、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が非ワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール803は、第1の課金要求に基づいて第1のイベント課金リソースを作成するようにさらに構成され、決定モジュール802は、第1のイベント課金リソースが第2の課金要求を有すると決定するようにさらに構成される。
任意選択で、第1の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含み、決定モジュール802がイベント課金情報に基づいて第1のイベント課金処理モードを決定することは、ユーザ識別子に基づいてユーザ情報を取得することと、イベント課金を示す表示情報、ユーザ情報、および/またはサービスタイプを示すパラメータに基づいて第1のイベント課金処理モードを決定することとを含み、ここで、第1のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。
任意選択で、決定モジュール802が、ワンタイムイベント課金の表示パラメータに基づいて、第1の課金要求が非ワンタイムイベント課金要求であると決定した後において、決定モジュール802がイベント課金情報に基づいてイベント課金処理モードを決定することは、第1のイベント課金処理モードがイベント割当ての適用であると決定することを含む。
任意選択で、第1のイベント課金処理モードは、直接控除であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいて格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施することを含む。
任意選択で、第1のイベント課金処理モードは、オフラインイベント報告であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、第1の課金要求に基づいてイベント課金データ記録を生成することを含む。
任意選択で、第1のイベント課金処理モードは、イベント割当ての適用であり、処理モジュール803が第1のイベント課金処理モードに従って第1の課金要求を処理することは、イベント課金情報に基づいて格付けを実施すること、および格付けに基づいてイベント割当てを認可することを含む。
任意選択で、CHF装置207は、第1の課金要求に対する課金応答をCTF装置101に返すように構成された送信モジュール804をさらに含み、ここで、課金応答は、決定された第1のイベント課金処理モードを担持する。
任意選択で、イベント課金処理モードは、直接控除であり、第1の課金要求を処理した後で、
受信モジュール801は、イベント課金サービスに対する第2の課金要求をさらに受け取り、ここで、第2の課金要求は、第2のイベント課金処理モードおよび第1のイベント課金リソースの識別子を含み、第2のイベント課金処理モードは、返済であり、かつ第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、第1のイベント課金リソースの識別子は、第1の課金要求に対する課金応答から取得される。
決定モジュール802は、第1のイベント課金リソースの識別子に基づいて、第1の課金要求を用いることにより実施された直接控除における控除量を決定するようにさらに構成される。
処理モジュール803は、控除量をユーザの勘定残高に返済するようにさらに構成される。
任意選択で、第2の課金要求は、第2のイベント課金リソースに対する作成要求であり、第2の課金要求は、ワンタイムイベント課金の表示パラメータを担持し、処理モジュール803は、第2の課金要求に基づいて第2のイベント課金リソースを作成するようにさらに構成される。
任意選択で、第2の課金要求は、第1のイベント課金リソースに対する更新要求であり、処理モジュール803は、第2の課金要求に基づいて第1のイベント課金リソースをリリースするようにさらに構成される。
任意選択で、第2の課金要求は、第1のイベント課金リソースに対するリリース要求であり、処理モジュール803は、第2の課金要求に基づいて第1のイベント課金リソースをリリースするようにさらに構成される。
任意選択で、第1の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール802は、再送信決定パラメータに基づいて、第1の課金要求が第1のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール803は、第1のイベント課金リソースを作成するようにさらに構成される。
任意選択で、第2の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール802は、再送信決定パラメータに基づいて、第2の課金要求が第2のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール803は、第2のイベント課金リソースを作成するようにさらに構成される。
任意選択で、課金要求は、イベント識別子および/またはイベント量をさらに担持し、処理モジュール803が第1の課金要求を処理することは、イベント識別子および/またはイベント量に基づいて第1の課金要求を処理することを含む。
図9は、CTF装置900の概略構造図である。CTF装置900は、前述の実施形態の課金トリガー機能装置101であり得る、または課金トリガー機能装置101内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図9に示すように、CTF装置は、受信モジュール901、決定モジュール902、および送信モジュール903を含む。
決定モジュール902は、イベント課金サービスの課金イベントが発生したと決定するように構成され、送信モジュール903は、第1の課金要求を課金機能CHF装置207に送るように構成され、ここで、第1の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用され、受信モジュール901は、第1の課金要求のものであり、かつCHF装置により送られる、第1の課金応答を受け取るように構成され、ここで、第1の課金応答は、決定されたイベント課金処理モードに従って第1の課金要求を処理した結果を含む。
任意選択で、第1のイベント課金処理モードは、直接控除であり、第1の課金応答は、第1の課金要求に基づいて作成された第1のイベント課金リソースの識別子を含み、受信モジュール901がCHF装置207により送られた第1の課金応答を受け取った後で、決定モジュール902は、イベント課金サービスが実施されるのに失敗したと決定するようにさらに構成される。
送信モジュール903は、イベント課金サービスに対する第2の課金要求を送るようにさらに構成され、ここで、第2の課金要求は、第1の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第1のイベント課金リソースの識別子とを含み、第1のイベント課金リソースの識別子は、第1の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。
図10は、本出願の実施形態による課金トリガー機能装置または課金機能装置(本明細書では、短縮して課金デバイス1000と呼ばれることがある)の実装の概略ブロック図である。課金デバイス1000は、プロセッサ1010、メモリ1030、およびバスシステム1050を含み得る。プロセッサとメモリは、バスシステムによって接続される。メモリは、命令を記憶するように構成される。プロセッサは、メモリに記憶された命令を実行するように構成される。課金トリガー機能装置または課金機能装置のメモリは、プログラムコードを記憶し、プロセッサは、メモリに記憶されたプログラムコードを呼び出して、本出願に記載される様々な課金処理方法、例えば図5から図7の実施形態に記載される処理ステップを実施し得る。反復を避けるために、本明細書では詳細は説明しない。
本出願のこの実施形態では、プロセッサ1010は、中央処理装置(Central Processing Unit、略称「CPU」)であることがあるし、あるいはプロセッサ1010は、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは別のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェア構成要素などであることがある。汎用プロセッサは、マイクロプロセッサであることがあるし、またはプロセッサは、任意の従来のプロセッサなどであることがある。
メモリ1030は、読取り専用メモリ(ROM)デバイスまたはランダムアクセスメモリ(RAM)デバイスを含むことがある。代替として、適当なタイプの任意のその他の記憶デバイスが、メモリ1030として使用されることがある。メモリ1030は、バス1050を介してプロセッサ1010によってアクセスされるコードおよびデータ1031を含むことがある。メモリ1030は、オペレーティングシステム1033およびアプリケーションプログラム1035をさらに含むことがある。アプリケーションプログラム1035は、プロセッサ1010が本出願に記載される課金方法を実施することを可能にする少なくとも1つのプログラムを含む。例えば、アプリケーションプログラム1035は、アプリケーション1からNを含むことがあり、さらに、本出願に記載される課金方法を実施する課金アプリケーション(略称、課金アプリケーション)を含むことがある。
バスシステム1050は、データバスに加えて、電力バス、制御バス、および状態信号バスなどをさらに含むことがある。ただし、説明が分かりやすくなるように、図中の様々なタイプのバスは、バスシステム1050として示されている。
任意選択で、課金デバイス1000は、トランシーバ1070などの1つまたは複数の入出力デバイスをさらに含むことがある。トランシーバ1070は、別のネットワーク機能装置と通信するように構成される。
当業者なら、本明細書に開示および記載される様々な例示的な論理ブロック、モジュール、およびアルゴリズムステップを参照して記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せによって実装されることが可能であることを理解することができる。実施形態がソフトウェアによって実装される場合には、例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体に記憶され、あるいはコンピュータ可読媒体を介して送信され、ハードウェア型の処理モジュールによって実行されることがある。コンピュータ可読媒体は、データ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体、または(例えば通信プロトコルに従う)1つの場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含むことがある。このように、コンピュータ可読媒体は、一般に、(1)非一時的な有形のコンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応することがある。データ記憶媒体は、本出願に記載される技術を実装するための命令、コード、および/またはデータ構造を取り出すために1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされることが可能な任意の使用可能な媒体であり得る。コンピュータプログラム製品が、コンピュータ可読媒体を含み得る。
限定されるわけではないが、一例では、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROM、または別のコンパクトディスク記憶装置、磁気ディスク記憶装置、または別の磁気記憶装置、フラッシュメモリ、あるいは所望のプログラムコードを命令またはデータ構造の形態で記憶するために使用されることが可能であり、かつコンピュータによってアクセス可能である、その他の任意の媒体を含み得る。さらに、任意の接続は、コンピュータ可読媒体と称されるのが適当である。例えば、命令が、ウェブサイト、サーバ、または別の遠隔ソースから、同軸ケーブル、光ファイバ、撚り対線、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を介して送信される場合には、同軸ケーブル、光ファイバ、撚り対線、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、またはその他の一時的媒体を含まず、実際には非一時的な有形の記憶媒体を意味することを理解されたい。本明細書で使用されるディスクは、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル汎用ディスク(DVD)、およびBlu-rayディスクを含む。磁気ディスクは、通常は磁気的にデータを再現し、光学ディスクは、レーザを用いて光学的にデータを再現する。上述の品目の組合せもまた、コンピュータ可読媒体の範囲に含まれるものとする。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、あるいはその他の等価な集積またはディスクリート論理回路などの、1つまたは複数のプロセッサによって実行されることがある。したがって、本明細書で使用される「プロセッサ」という用語は、本明細書に記載される技術を実装するのに適した前述の構造またはその他の任意の構造のうちのいずれか1つであることがある。さらに、いくつかの態様では、本明細書に記載される例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、符号化および復号を行うように構成された専用のハードウェアおよび/またはソフトウェアモジュール内に設けられることがあるし、あるいは結合されたコーデック内に組み込まれることがある。さらに、これらの技術は、1つまたは複数の回路または論理要素内で完全に実装されることがある。
本出願の技術は、集積回路(IC)またはICのグループ(例えばチップセット)を含む、様々な装置またはデバイスで実装され得る。本出願では、様々な構成要素、モジュール、またはモジュールについて、開示される技術を実施するように構成された装置の機能態様を強調するように説明されているが、これらは、必ずしも異なるハードウェアモジュールによって実装されるわけではない。実際には、上述のように、様々なモジュールが、適当なソフトウェアおよび/またはファームウェアと組み合わせてコーデックハードウェアモジュールに結合され得る、あるいは相互運用可能なハードウェアモジュール(上述の1つまたは複数のプロセッサを含む)によって提供され得る。
以上の説明は、単に本出願の具体的な実装であり、本出願の保護範囲を限定することを意図しているわけではない。本出願に開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。