JP7239740B2 - 課金方法、装置、およびシステム - Google Patents

Description

本出願は、通信技術の分野に関し、詳細には、課金方法、装置、およびシステムに関する。

本出願は、２０１９年８月２日に中国国家知識産権局に出願され、「ＣＨＡＲＧＩＮＧ ＭＥＴＨＯＤ、ＡＰＰＡＲＡＴＵＳ、ＡＮＤ ＳＹＳＴＥＭ」と題する中国特許出願第２０１９１０７１３７５６．３号明細書に対する優先権を主張するものであり、その全体が参照により本明細書に組み込まれる。

現在、４Ｇ通信システムでは、オンライン課金サービスおよびオフライン課金サービスは、異なる課金システムを用いることにより課金される。図１で示されるように、システム１００における課金トリガー機能（ｃｈａｒｇｉｎｇ ｔｒｉｇｇｅｒ ｆｕｎｃｔｉｏｎ）装置１０１は、Ｒｏインターフェースを介してオンライン課金システム１０２と通信し、またＲｆインターフェースを介してオフライン課金システム１０３と通信する。オンライン課金システム１０２は、オンライン課金サービスに対する課金を実施するように構成され、またオフライン課金システム１０３は、オフライン課金サービスに対する課金を実施するように構成される。オンライン課金またはオフライン課金を決定した後、ＣＴＦ装置は、オンライン課金システム１０２またはオフライン課金システム１０３に対して、ダイアメータ課金要求を開始する。オンライン課金システム１０２またはオフライン課金システム１０３は、ダイアメータ課金要求における課金コマンドおよび要求タイプに基づいて対応する課金処理を実施し得る。

５Ｇ通信システムでは、サービスベースのオンライン／オフライン収束課金メッセージが使用され、リソース予約および使用情報報告が、格付けグループに基づいて実装される。使用情報が報告されると、担持される使用割当て管理表示は、その使用情報が割当てを有する使用情報かどうかを示して、割当てを有する使用情報の報告、または割当てのない使用情報の報告を実装する。割当ては、先行して、課金システムによりＣＴＦに認可された割当てである。言い換えると、使用割当て管理表示は、割当てが、先行して課金システムから適用されており、その適用に基づいて課金システムにより認可されているかどうかを示す。

既存の５Ｇ通信システムで使用されるオンライン／オフライン収束課金メッセージは、セッションベースのトラフィック、持続期間リソース予約、および使用報告をサポートする。しかし、現在の収束課金システムは、イベント課金を正確に、かつ効率的に実装することができない。

本出願の実施形態は、イベント課金サービスに対する課金を実装するための課金方法、装置、およびシステムを提供する。

第１の態様によれば、本出願の実施形態は、課金方法を提供する。本方法は、以下のことを含む、すなわち、ＣＨＦ装置は、課金トリガー機能ＣＴＦ装置により送られた第１の課金要求を受け取り、ここで、第１の課金要求は、イベント課金情報を担持する。次いで、ＣＨＦ装置は、イベント課金情報に基づいて、第１のイベント課金処理モードを決定し、第１の課金要求を第１のイベント課金処理モードに従って処理する。本方法によれば、ＣＨＦ装置は、第１の課金要求に基づいて第１のイベント課金処理モードを決定し、イベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。

可能な実装では、イベント課金情報は、イベント課金を示す表示情報を含み、第１のイベント課金処理モードを決定する前に、ＣＨＦ装置は、イベント課金表示情報に基づいて、第１の課金要求が、イベントサービスに対する課金要求であると決定する。したがって、ＣＨＦ装置は、イベント課金サービスに対する要求を正確に決定し、次いで、その後の処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。

可能な実装では、第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、またイベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。ＣＨＦ装置は、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求は、ワンタイムイベント課金要求であると決定し、第１の課金要求に基づいて、第１のイベント課金リソースを作成し、かつ第１のイベント課金リソースは、第３の課金要求を有しないと決定する。代替として、ＣＨＦは、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求は、非ワンタイムイベント課金要求であると決定し、第１の課金要求に基づいて、第１のイベント課金リソースを作成し、かつ第１のイベント課金リソースは、第３の課金要求を有すると決定する。ＣＨＦ装置は、後続する処理を実施するための後続する第３の課金要求があるかどうかを決定する。例えば、後続する課金要求がない場合、第１のイベント課金リソースは、課金処理が完了した後、リリースされる。代替として、後続する課金要求がある場合、第１のイベント課金リソースは保持される。

可能な実装では、イベント課金情報は、第１のイベント課金処理モードをさらに含み、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。ＣＨＦ装置は、処理効率を高めるために、イベント課金処理モードを第１の課金要求から直接取得し得る。

可能な実装では、第１の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含む。ＣＨＦ装置が、イベント課金情報に基づいて、第１のイベント課金処理モードを決定することは、以下のことを含む、すなわち、ＣＨＦ装置は、ユーザ識別子に基づいてユーザ情報を取得し、かつイベント課金を示す表示情報、ユーザ情報、およびサービスタイプを示すパラメータに基づいて、第１のイベント課金処理モードを決定し、ここで、第１のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。ＣＨＦ装置は、処理効率を高めるために、第１の課金要求から、イベント課金処理モードを直接取得し得る。

可能な実装では、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求が、非ワンタイムイベント課金要求であると決定した後、ＣＨＦ装置が、イベント課金情報に基づいてイベント課金処理モードを決定することは、第１のイベント課金処理モードが、イベント割当ての適用であると決定することを含む。

可能な実装では、第１のイベント課金処理モードは、直接控除であり、またＣＨＦ装置が、第１のイベント課金処理モードに従って第１の課金要求を処理することは、第１の課金要求に基づいて格付けを実施し、かつ格付け結果に基づいて、ユーザの勘定残高からの控除を実施することを含む。

可能な実装では、第１のイベント課金処理モードは、オフラインイベント報告であり、またＣＨＦ装置が、第１のイベント課金処理モードに従って第１の課金要求を処理することは、第１の課金要求に基づいて、イベント課金データ記録を生成することを含む。

可能な実装では、第１のイベント課金処理モードは、イベント割当ての適用であり、ＣＨＦ装置が、第１のイベント課金処理モードに従って第１の課金要求を処理することは、イベント課金情報に基づいて格付けを実施し、かつ格付けに基づいてイベント割当てを認可することを含む。

可能な実装では、ＣＨＦ装置は、第１の課金要求に対する第１の課金応答をＣＴＦ装置にさらに返し、第１の課金応答は、決定された第１のイベント課金処理モードを担持する。

可能な実装では、イベント課金処理モードは、直接控除であり、第１の課金要求を処理した後、ＣＨＦ装置は、イベント課金サービスに対する第２の課金要求を受け取り、ここで、第２の課金要求は、第２のイベント課金処理モード、および第１のイベント課金リソースの識別子を含み、第２のイベント課金処理モードは返済であり、第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、また第１のイベント課金リソースの識別子は、第１の課金要求に対する課金応答から取得される。加えて、ＣＨＦ装置は、第１のイベント課金リソースの識別子に基づいて、第１の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が返済される。

可能な実装では、第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、第２の課金要求は、ワンタイムイベント課金の表示パラメータを担持する。ＣＨＦ装置は、第２の課金要求に基づいて、第２のイベント課金リソースをさらに作成する。

可能な実装では、第２の課金要求は、第１のイベント課金リソースに対する更新要求であり、またＣＨＦ装置は、第２の課金要求に基づいて、第１のイベント課金リソースをさらにリリースする。

可能な実装では、第２の課金要求は、第１のイベント課金リソースに対するリリース要求であり、またＣＨＦ装置は、第２の課金要求に基づいて、第１のイベント課金リソースをさらにリリースする。

可能な実装では、第１の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第１の課金要求が、第１のイベント課金リソースに対する再送信された作成要求ではないと決定した後、ＣＨＦ装置は、第１のイベント課金リソースをさらに作成する。本方法によれば、ＣＨＦは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。

可能な実装では、第２の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータに基づいて、第２の課金要求が、第２のイベント課金リソースに対する再送信された作成要求ではないと決定した後、ＣＨＦ装置は、第２のイベント課金リソースをさらに作成する。この方法によれば、ＣＨＦは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。

可能な実装では、第１の課金要求は、イベント識別子および／またはイベント量をさらに担持し、第１の課金要求を処理することは、イベント識別子および／またはイベント量に基づいて課金要求を処理することを含む。この方法によれば、複数の課金サービスが生じるごとに課金処理を行うことを回避するために、１つまたは複数のイベントの生成が、１つの課金要求において表され得る。このように、課金処理が簡単化される。

第２の態様によれば、本出願の実施形態は、課金方法を提供する。方法は以下のことを含む、すなわち、ＣＴＦ装置は、イベント課金サービスの課金サービスが生じたと決定し、第１の課金要求を課金機能ＣＨＦ装置に送り、ここで、第１の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用される。ＣＴＦ装置は、第１の課金要求のものであって、ＣＨＦ装置により送られた第１の課金応答を受け取り、ここで、第１の課金応答は、決定されたイベント課金処理モードに従って、第１の課金要求を処理した結果を含む。この方法によれば、ＣＴＦ装置は、第１の課金要求におけるイベント課金情報を担持し、したがって、ＣＨＦ装置は、第１の課金要求に基づいて第１のイベント課金処理モードを決定し、かつイベント課金処理を実施し得る。したがって、イベント課金サービスに対する課金は、正確に、かつ効率的に実施されることができる。

可能な実装では、第１の課金応答は、ＣＨＦにより決定されたイベント課金処理モードをさらに含む。

可能な実装では、第１のイベント課金処理モードは、直接控除であり、第１の課金応答は、第１の課金要求に基づいて作成された第１のイベント課金リソースの識別子を含み、またＣＴＦ装置は、ＣＨＦ装置により送られた第１の課金応答を受け取る。次いで、ＣＴＦ装置は、イベント課金サービスが実施されるのに失敗したとさらに決定し、イベント課金サービスに対する第２の課金要求を送り、ここで、第２の課金要求は、第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第１のイベント課金リソースの識別子と、を含み、また第１のイベント課金リソースの識別子は、第１の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。本方法によれば、イベント課金サービスにおいて、課金の正確さおよびユーザ体験を向上させるために、イベント課金サービスが実施されるのに失敗したための手数料が返済される。

可能な実装では、第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、また第２の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持する、または第２の課金要求は、第１のイベント課金リソースに対する更新要求である、もしくは第１のイベント課金リソースに対するリリース要求である。

可能な実装では、第１の課金要求または第２の課金要求は、再送信決定パラメータをさらに含み、また再送信決定パラメータは、第１の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される、かつ／または
第２の課金要求は、再送信決定パラメータをさらに含み、再送信決定パラメータは、第２の課金要求が、イベント課金リソースに対する再送信された作成要求ではないと決定するために使用される。この方法によれば、ＣＨＦは、正確な課金処理を実施するために、リソース作成要求が再送信要求であるかどうかをさらに決定し得る。

可能な実装では、ＣＴＦ装置は、サービスイベントが生じた回数の数量を決定し、また課金要求は、イベント識別子およびイベント量をさらに担持する。この方法によれば、複数のイベント課金サービスが生じるごとに課金処理を行うことを回避するために、１つまたは複数のイベントの生成が、１つの課金要求において表され得る。このように、課金処理が簡単化される。

第３の態様によれば、ＣＨＦ装置が提供される。装置は、第１の態様および第２の態様におけるＣＨＦ装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する１つまたは複数のモジュールを含む。

第４の態様によれば、ＣＴＦ装置が提供される。装置は、第１の態様および第２の態様におけるＣＴＦ装置を実装する機能を有する。機能は、ハードウェアにより実装され得る、または対応するソフトウェアを実行するハードウェアにより実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する１つまたは複数のモジュールを含む。

第５の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金トリガー機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第１の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。

第６の態様によれば、本出願の実施形態は、互いに結合される不揮発性メモリおよびプロセッサを含む課金機能装置を提供する。プロセッサは、メモリに記憶されたプログラムコードを呼び出して、第２の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。

第７の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第１の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。

第８の態様によれば、本出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、プログラムコードを記憶し、またプログラムコードは、第２の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施するために使用される命令を含む。

第９の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第１の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。

第１０の態様によれば、本出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第２の態様におけるいずれかの方法のいくつか、またはすべてのステップを実施する。

第１１の態様によれば、本出願の実施形態は、第３の態様における課金機能装置、および第４の態様における課金トリガー機能装置を含む課金システムを提供する。

本出願の第２から第１１の態様における技術的な解決策は、第１の態様のものと一致していることを理解されたい。これらの態様、および対応する実行可能な実装により達成される有益な効果は同様であり、詳細を再度述べないものとする。

本出願の実施形態において、または背景において、技術的解決策をより明確に述べるために、以下は、本出願の実施形態または背景を説明するための添付図面を述べる。

現在の技術における課金システムの概略的なブロック図である。 本出願の実施形態によるネットワークアーキテクチャの概略的なブロック図である。 本出願の実施形態による課金システムの概略的なブロック図である。 本出願の実施形態による課金フレームワークの概略的なブロック図である。 本出願の実施形態による課金方法の流れ図である。 本出願の実施形態による課金方法の流れ図である。 本出願の実施形態による課金方法の流れ図である。 本出願の実施形態による課金機能装置の概略的なブロック図である。 本出願の実施形態による課金トリガー機能装置の概略的なブロック図である。 本出願の実施形態による課金デバイスの概略的なブロック図である。

以下は、本出願の実施形態における添付図面を参照して本出願の実施形態を述べる。

図２は、本出願の実施形態が適用できる可能なネットワークアーキテクチャの概略図である。ネットワークアーキテクチャ２００は、第５世代移動体通信技術（ｔｈｅ ５ｔｈ Ｇｅｎｅｒａｔｉｏｎ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ、５Ｇ）ネットワークアーキテクチャである。５Ｇアーキテクチャは、１個のユーザ機器２０１、無線アクセスネットワーク（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、ＲＡＮ）２０２、アクセスおよびモビリティ管理機能（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ、ＡＭＦ）装置２０６、セッション管理機能（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ、ＳＭＦ）装置２０５、ユーザプレーン機能（ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ、ＵＰＦ）装置２０３、ネットワーク露出機能（Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ、ＮＥＦ）装置２０８、ショートメッセージサービス機能（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ、ＳＭＳＦ）装置２０９、データネットワーク（ｄａｔａ ｎｅｔｗｏｒｋ、ＤＮ）２０４、および課金機能（ｃｈａｒｇｉｎｇ ｆｕｎｃｔｉｏｎ、ＣＨＦ）装置２０７を含み得る。さらに、図２で示されたネットワーク要素に加えて、本出願のこの実施形態におけるアーキテクチャは、例えば、モノのインターネットメッセージゲートウェイなど、イベント課金を使用する別のネットワーク要素または機能をさらに含み得る。図２の機能モジュール間の通信は、次世代（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ、ＮＧ）インターフェース、またはサービスベースのインターフェース（ｓｅｒｖｉｃｅ ｂａｓｅｄ ｉｎｔｅｒｆａｃｅ、ＳＢＩ）を介する接続を確立することにより実装され得る。例えば、ＲＡＮデバイスは、ＮＧインターフェース２（略してＮ２）を介するＡＭＦへの制御プレーンシグナリング接続を確立し得る、またＮＥＦデバイスは、ＳＢＩインターフェースＮｎｅｆを介して外部サービスを提供し得る。

ユーザ機器は、無線送受信機機能を有するデバイスである。ユーザ機器は、屋内デバイス、屋外デバイス、手持ち式デバイス、もしくは車両搭載デバイスを含む陸上で展開され得る、または水面上で（例えば、船上で）展開され得る、または空中で（例えば、航空機、気球、もしくは衛星で）展開され得る。

以下は、本出願の実施形態における添付図面を参照して、本出願の実施形態における技術的解決策を述べる。本出願の記述において、その他の形で指定されない限り、「複数の」は、２つ以上を意味する。さらに、本出願の実施形態における技術的解決策の明確な記述を容易にするために、本出願の実施形態では、「第１」および「第２」などの用語は、同じ対象物の間、または機能および目的が基本的に同じである同様の対象物の間を区別するために使用される。当業者であれば、「第１」および「第２」などの用語は、量、または実行順序を限定するように意図されたものではなく、また「第１」および「第２」などの用語は、明確な差を示すものでもないことを理解するはずである。本発明における「Ａおよび／またはＢ」は、ＡまたはＢのいずれか一方、またはＡおよびＢを含むものと説明され得る。

図３は、本出願の実施形態による課金アーキテクチャ３００の概略図である。課金アーキテクチャ３００は、課金トリガー機能（ｃｈａｒｇｉｎｇ ｔｒｉｇｇｅｒ ｆｕｎｃｔｉｏｎ、ＣＴＦ）装置３１および課金システム３２を含む。課金トリガー機能装置３１および課金システム３２は、サービスベースのインターフェースを介して、互いに通信し得る。サービスベースのインターフェースは、ＲＥＳＴｆｕｌおよび遠隔手続き呼び出し（ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ、ＲＰＣ）など、リソースベースの機能露出インターフェースを指す。図２のネットワークアーキテクチャを参照すると、ＣＴＦ装置１０１は、ＳＭＦ装置２０５に配置され得る。言い換えると、ＳＭＦ装置２０５は、ＣＴＦ装置３１の機能を統合する。課金システム３２は、課金機能（ｃｈａｒｇｉｎｇ ｆｕｎｃｔｉｏｎ、ＣＨＦ）装置２０７を含む。ＣＨＦ装置２０７は、オンライン（ｏｎｌｉｎｅ）課金、およびオフライン（ｏｆｆｌｉｎｅ）課金を実施し得る。すなわち、課金システム３２は、収束課金システムであり得る。課金システム３２は、課金が実施されるときに必要な勘定残高管理機能（ａｃｃｏｕｎｔ ｂａｌａｎｃｅ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ、ＡＢＭＦ）装置、および格付け機能（ｒａｔｉｎｇ ｆｕｎｃｔｉｏｎ、ＲＦ）装置をさらに含む。ＡＢＭＦ装置は、ユーザの預金口座を記憶し、かつ管理するように構成され、またＲＦ装置は、サービスの使用情報に対する格付けを実施するように構成される。図３で示された課金トリガー機能装置３１および課金システム３２に加えて、本出願のこの実施形態における課金アーキテクチャは、請求（ｂｉｌｌｉｎｇ）装置をさらに含み得る。請求装置および課金システム３２は、課金ゲートウェイ機能（ｃｈａｒｇｉｎｇ ｇａｔｅｗａｙ ｆｕｎｃｔｉｏｎ、ＣＧＦ）装置を用いることにより、互いに通信し得る。ＣＧＦ装置は、課金システムの一部として課金システムに統合され得る、または請求装置の一部として請求装置に統合され得る、または独立したネットワーク要素として存在し得る。以下の内容が、さらに詳細に述べられる。

課金トリガー機能装置１０１は、課金開始要求を生成し、課金システム３２が、課金開始要求を処理する。本出願のこの実施形態では、課金トリガー機能装置３１はまた、クライアントと見なされ、また課金システム３２は、サーバと見なされ得る。課金トリガー機能装置３１および課金システム３２は、１つまたは複数のプロセッサ、および１つまたは複数のプロセッサに結合されたメモリを含み得る。メモリは、これだけに限らないが、本明細書で述べられるように、コンピュータにアクセスできる命令またはデータ構造の形式の望ましいプログラムコードを記憶するために使用されることのできるＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または任意の他の媒体を含み得る。

図４は、図３における課金アーキテクチャの特定の実装である。ＣＨＦ装置２０７は、サービスベースのインターフェースＲｅｓｔｆｕｌを介して外部サービスを提供し得る。インターフェースの名前は、Ｎｃｈｆであり、ＣＴＦ装置１０１は、インターフェースＮｃｈｆを介して、ＣＨＦ装置２０７にアクセスし得る。課金システムは、ＣＨＦ装置２０７、ＡＢＭＦ装置２１０、ＲＦ装置２１２、およびＣＧＦ装置２１１を含む。

図５は、本出願による課金方法５００の概略的な流れ図である。方法５００は、図２におけるネットワークアーキテクチャに、かつ図３および図４で示される課金アーキテクチャに適用され得る。実際には、方法５００はまた、別の通信シナリオにも適用され得る。これは、本出願の実施形態に限定されない。図５で示されるように、方法５００は、以下の内容を含む。

ステップ５０１：現在のサービスをイベント課金サービスとして構成し、かつＣＴＦ装置１０１におけるサービスの課金ルールを構成する。

ステップ５０１で、ＣＴＦ装置１０１が、ＳＭＦ装置２０５に配置された場合、イベント課金サービスおよび課金ルールは、ポリシを送達することにより、ＣＴＦ装置１０１におけるＰＣＦにより動的に構成され得る、またはＣＴＦ装置１０１において事前に構成され得る。任意選択で、ＣＴＦ装置１０１が、別のネットワーク機能装置に位置する場合、イベント課金サービスの課金ルールは、ＣＴＦ装置１０１において事前に構成される。操作者は、サービスがイベント課金サービスであることを示すために、ＣＴＦ装置１０１においてサービス課金ルールを構成し得る。サービス課金ルールは、報告条件、および／またはイベント課金サービスの課金処理モードをさらに含む。課金処理モードは、（１）直接控除、（２）予約ベースのイベント課金（割当ての適用、および割当ての使用報告を含む）、（３）オフラインイベント報告、（４）返済、および同様のものなどを含む。

直接控除は、ＣＨＦ装置２０７が、ＣＴＦ装置１０１により報告された課金要求に基づいて格付けを実施し、格付け結果に基づき、ユーザの勘定残高からの控除を実施することを意味する。オフラインイベント報告は、ＣＨＦ装置２０７が、ＣＴＦ装置１０１により報告された課金要求に基づいてイベント課金データ記録（Ｃｈａｒｇｉｎｇ Ｄａｔａ Ｒｅｃｏｒｄ、ＣＤＲ）を生成することを意味し、ＣＤＲはまたイベント課金請求書とも呼ばれる。イベント割当ての適用は、ＣＨＦ装置２０７が、ＣＴＦ装置１０１により報告された課金要求に基づいて格付けを実施し、勘定残高におけるリソースを予約する（すなわち、ユーザへの割当てを認可する）ことを意味する。割当て使用報告は、サービスが課金報告を満たすとき、認可された割当てを有する使用情報が報告されることを意味する。返済は、直接控除が実施されるイベント課金サービスに対して、イベント課金サービスが実施されるのに失敗した場合、直接控除における控除量が返済されることを意味する。

課金処理モードにおいて、リソースを求める第１の課金要求に対するイベント課金処理モードは、第１のイベント課金処理モードと呼ばれる。第１のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告を含む。第２の課金要求に対するイベント課金処理モードは、第２のイベント課金処理モードと呼ばれる。第２のイベント課金処理モードは、返済を含む。

課金処理モードにおいて、第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、また課金システムに第１のイベント課金リソースを作成するように要求するために使用される。第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、課金システムに第２のイベント課金リソースを作成するように要求するために使用される、または第２の課金要求は、第１のイベント課金リソースに対する更新要求であり、課金システムに第１のイベント課金リソースを更新するように要求するために使用される、または第２の課金要求は、第１のイベント課金リソースに対するリリース要求であり、第１のイベント課金リソースに対応する課金データが更新された後、第１のイベント課金リソースをリリースするように課金システムに要求するために使用される。

例えば、課金要求は、イベント送信側および受信側、イベント発生時間、ならびに／またはイベントコンテンツサイズを担持する。

ステップ５０２：ＣＴＦ装置１０１は、第１の課金要求をＣＨＦ装置２０７に送り、ここで、第１の課金要求は、イベント課金情報を担持する。

ＣＴＦ装置１０１は、イベント課金サービスの使用をモニタし、イベント課金サービスの課金イベントが生じたと決定する。課金イベントは、課金される必要のあるイベントであり、課金報告をトリガーする課金イベントである。ＣＨＦ装置２０７は、構成されたサービス課金ルールに従って、第１の課金要求を生成する。第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、ＣＨＦ装置２０７に送られる。ＣＴＦ装置１０１が、ＳＭＦ装置２０５に位置している場合、課金イベントが生ずることは、新しいＰＤＵセッションが確立されることであり得る。ＣＴＦ装置１０１が、システムの別の機能装置に位置する場合、課金イベントが生ずることは、ＣＴＦ装置１０１が、ネットワーク機能ＡＰＩの起動メッセージを受け取ること、またはネットワーク機能ＡＰＩに対する起動応答を返すことであり得る。

イベント課金情報は、イベント課金を示す表示情報を含み、また第１の課金要求が、イベントサービスに対する課金要求であると決定するために使用される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータであり得る（例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モードなど）。

イベント課金情報は、ワンタイムイベント課金の表示パラメータ、または非ワンタイムイベント課金の表示パラメータをさらに含む。ワンタイムイベント課金の表示パラメータは、第１のイベント課金リソースが、第１の課金要求に基づいて作成された後、第１のイベント課金リソースは、後続する課金要求を有しないことを示す。

リソースイベント課金リソース作成は、第１のイベント課金処理モードをさらに担持し得る。第１のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。加えて、リソースイベント課金リソース作成は、イベント識別子、イベント量、再送信決定パラメータ、イベントの詳細などのうちの１つまたは複数のものをさらに担持し得る。イベント量は、イベントの生じた回数の数量を示す。イベント識別子は、サービスイベントを示し、例えば、サービスイベントが、ＡＰＩ起動、またはＳＭＳ送信であることを示す。

ステップ５０３：ＣＨＦ装置２０７は、第１の課金要求に基づいて、イベント課金サービスに対する課金処理を実施する。

例えば、第１の課金要求が、第１のイベント課金リソースに対する作成要求であるとき、ＣＨＦ装置２０７は、第１の課金要求に対する第１のイベント課金リソースを作成し、かつリソース識別子を第１のイベント課金リソースに割り振る。

特に、ＣＨＦ装置２０７は、第１の課金要求がワンタイムイベント課金であるかどうかを決定する必要がさらにあり、ＣＨＦ装置２０７が、第１の課金要求はワンタイムイベント課金要求であると決定した場合、ＣＨＦ装置２０７は、第１のイベント課金リソースは、後続する課金要求を有しないと決定する。したがって、第１の課金要求に基づいて、課金リソースを作成し、かつ課金処理を実施した後、ＣＨＦ装置２０７は、もはや第１のイベント課金リソースのコンテキストを保持しない、例えば、第１のイベント課金リソースをリリースする、または第１のイベント課金リソースをデータベースに記憶する。代替として、ＣＨＦ装置２０７が、第１の課金要求は、非ワンタイムイベント課金要求であると決定した場合、ＣＨＦ装置２０７は、第１の課金要求に基づいて第１のイベント課金リソースを作成し、第１のイベント課金リソースは、第１のイベント課金リソースをリリースするための後続する課金要求を有すると決定し、かつ第１のイベント課金リソースのコンテキストを保持し、後続する課金要求を処理できるようにする。第１の課金要求が、ワンタイムイベント課金であるかどうかを、ＣＨＦ装置２０７により決定するための特定の方法は、以下のことを含む、すなわち、イベント課金情報が、ワンタイムイベント課金の表示パラメータをさらに含む場合、ＣＨＦ装置２０７は、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求は、ワンタイムイベント課金要求である、または非ワンタイム課金要求であると決定する。第１の課金要求が、ワンタイムイベント課金のパラメータを担持しないが、課金処理モードを決定するための情報を担持する場合、ＣＨＦ装置２０７は、決定された課金処理モードに従って、第１の課金要求がワンタイムイベント課金要求であるかどうかをさらに決定する。例えば、決定されたイベント課金処理モードが、直接控除またはオフラインイベント報告である場合、ＣＨＦ装置２０７は、第１の課金要求がワンタイムイベント課金要求であると決定する。決定されたイベント課金処理モードが、リソース予約である場合、ＣＨＦ装置２０７は、第１の課金要求は、非ワンタイムイベント課金要求であると決定する。イベント課金情報が、イベント課金処理モードをさらに含む場合、イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。ＣＨＦ装置２０７は、リソースイベント課金リソース作成において担持されたイベント課金処理モードに従って、直接控除、オフラインイベント報告、またはサービスに対するイベント割当ての適用を実施し得る。

イベント課金情報が、第１のイベント課金処理モードを含まない場合、ＣＨＦ装置２０７は、第１の課金要求に基づいて、第１のイベント課金処理モードを決定し、決定された第１のイベント課金処理モードに従って、第１の課金要求を処理し得る。決定された第１のイベント課金処理モードは、直接控除、イベント割当ての適用、またはオフラインイベント報告であり得る。例えば、ＣＨＦ装置２０７は、第１の課金要求において担持されたユーザ識別子に基づいて、ユーザ情報を取得し、かつ取得されたユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、ＣＨＦ装置２０７は、例えば、ＡＰＩ起動のサービスタイプなど、第１の課金要求におけるサービスタイプのパラメータに基づいてイベント課金処理モードを決定してもよい。代替として、ＣＨＦ装置２０７は、第１の課金要求におけるサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。ＣＨＦ装置２０７は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照してイベント課金処理モードを決定し得る。

イベント課金情報が、イベント課金処理モードを含まない場合、ＣＨＦ装置２０７は、イベント課金表示情報に基づいて、第１の課金要求は、イベント課金サービスに対する課金要求であると決定し、第１の課金要求におけるユーザ識別子に基づいて、ユーザ情報を取得し、ユーザ情報に基づいてイベント課金処理モードを決定し得る。代替として、ＣＨＦ装置２０７は、イベント課金情報に含まれるサービスタイプのパラメータ、またはサービス状況のパラメータに基づいて、イベント課金処理モードを決定してもよい。ＣＨＦ装置２０７は、代替として、例えば、ユーザ情報およびサービスタイプを参照するなど、前述のいくつかの情報を参照して、イベント課金処理モードを決定してもよい。

イベント課金情報が、イベント課金処理モードを含まない場合、ＣＨＦ装置２０７は、イベント課金情報に含まれる非ワンタイムイベント課金の表示パラメータに基づいて、イベント課金処理モードをさらに決定し得る。特に、イベント課金情報が、非ワンタイムイベント課金の表示パラメータを含む場合、ＣＨＦ装置２０７は、第１のイベント課金処理モードは、イベント割当ての適用であると決定する。

イベント課金情報は、再送信決定パラメータをさらに含む。第１の課金要求に対して、第１のイベント課金リソースを作成する前に、ＣＨＦ装置２０７は、再送信決定パラメータに基づいて、第１の課金要求が、第１のイベント課金リソースに対する再送信された作成要求ではないと決定した後、第１のイベント課金リソースを作成する。再送信決定パラメータは、大域的に一意の専用の識別子であり得る、またはユーザ識別子とサービス特有の識別子の組合せであり得る。サービス特有の識別子は、ユーザドメインにおいてのみ一意である。

ステップ５０４：ＣＨＦ装置２０７は、第１の課金要求に対する第１の課金応答をＣＴＦ装置１０１に送り、ここで、第１の課金応答は、第１のイベント課金リソースの識別子を担持する。

任意選択で、第１の課金要求が、第１のイベント課金処理モードを担持していない場合、第１の課金応答は、例えば、直接控除、イベント割当ての適用、またはオフラインイベント報告など、ＣＨＦ装置２０７により決定された第１のイベント課金処理モードをさらに担持する。

ステップ５０５：ＣＴＦ装置１０１は、第１の課金要求の控除量を返済するように要求するために、第２の課金要求をＣＨＦ装置２０７に送る。

第２の課金要求は、第２のイベント課金リソースに対する作成要求、または第１のイベント課金リソースに対する更新要求、または第１のイベント課金リソースに対する削除要求であり得る。

第１のイベント処理モードが直接控除であるとき、ＣＴＦ装置１０１は、イベント課金サービスが実施されるのに失敗したと決定し、またＣＴＦ装置１０１は、イベント課金サービスに対する第２の課金要求を送る。第２の課金要求は、第２のイベント課金リソースに対する作成要求、または、第１のイベント課金リソースに対する更新要求、または第１のイベント課金リソースに対する削除要求であり得る。好ましくは、第２の課金要求は、第２のイベント課金リソースに対する作成要求である。第２の課金要求は、第２のイベント課金処理モード、および第１のイベント課金リソースの識別子を含み、また第２のイベント処理モードは、返済である。第２のイベント課金処理モードは、第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される。第１のイベント課金リソースの識別子は、第１の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。

例えば、イベント課金サービスが、実施されるのに失敗し、かつ第１のイベント課金処理モードが直接控除である場合、第２の課金要求は、以下のようになり得る、
課金作成要求
｛
ｏｎｅＥｖｅｎｔＣｈａｒｇｉｎｇ：真
ｅｖｅｎｔＣＨＭｅｔｈｏｄ：返済
｝

ここにおいて、「課金作成要求」は、第２の課金要求が、リソース作成要求であることを示す。第２の課金要求は、ワンタイムイベント課金のパラメータ「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」を担持しており、またワンタイムイベント課金のパラメータは、後続するイベント課金要求があるかどうかを示すために使用される。ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇの値は真であり、後続するリソース更新課金要求、またはリソース削除課金要求がないことを示している。リソース更新課金要求は、第２のイベント課金処理モード「ｅｖｅｎｔＣＨＭｅｔｈｏｄ」をさらに担持する。第２のイベント課金処理モードの値は、返済であり、イベント課金処理モードは返済であることを示している。

ステップ５０６：ＣＨＦ装置２０７は、第２の課金要求に基づいて課金処理を実施し、第２の課金要求に対する第２の課金応答をＣＴＦ装置１０１に返す。

第２の課金要求は、第１のイベント課金リソースに対する更新要求、または削除要求であり得、第２のイベント課金処理モードを含む。第２のイベント課金処理モードは返済である。第２のイベント処理モードは、第１の課金要求を用いることにより実施された直接控除における控除量を返済するようにＣＨＦ装置２０７に示す。ＣＨＦ装置２０７は、第１の課金要求を用いることにより実施された直接控除における控除量を決定し、かつユーザの勘定残高に控除量を返済する。加えて、ＣＨＦ装置２０７は、第２の課金要求に基づいて、第１のイベント課金リソースをさらにリリースする。第２の課金要求に対する応答は、返済動作の結果である。

別の実装では、第２の課金要求は、第２のイベント課金リソースに対する作成要求であり得るが、第２の課金要求は、第２のイベント課金処理モード、および第１のイベント課金リソースの識別子を担持し、また第２のイベント課金処理モードは返済であり、第１の課金要求を用いることにより実施された直接控除における控除量を返済するようにＣＨＦ装置２０７に示すために使用される。第２の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持し得る。ＣＨＦ装置２０７は、第２の課金要求に基づいて第２のイベント課金リソースを作成し、第１のイベント課金リソースの識別子に基づいて、第１の課金要求を用いることにより実施された直接控除における控除量を決定し、かつ控除量をユーザの勘定残高に戻す。

任意選択で、第２の課金要求は、再送信決定パラメータをさらに含む。再送信決定パラメータに基づいて、第２の課金要求が、第２のイベント課金リソースに対する再送信された作成要求ではないと決定した後、ＣＨＦ装置２０７は第２のイベント課金リソースを作成する。

ステップ５０７：ＣＴＦ装置１０１は、第３の課金要求をＣＨＦ装置２０７に送る。

第１の課金要求が、リソース作成要求であり、かつ第１の課金処理モードが、イベント割当ての適用であるとき、ＣＴＦ装置は、イベント課金サービスの実行を完了した後、第３の課金要求をＣＨＦにさらに送る。第３の課金要求は、第３の課金処理モード、すなわち、オフラインイベント報告を担持する。

第３の課金要求は、リソース更新要求、またはリソース削除要求であり得る。第３の課金要求は、第１のイベント課金リソースの識別子をさらに含み得る。

ステップ５０８：ＣＨＦ装置２０７は、第２の課金要求に基づいて課金処理を実施し、かつ第３の課金要求に対する第３の課金応答をＣＴＦ装置１０１に返す。

第３の課金要求を受け取った後、ＣＨＦ装置２０７は、第３の課金処理モードに従って、ＣＤＲを生成する。ＣＨＦ装置２０７は、第３の課金応答をＣＴＦ装置に返す。

前述の方法によれば、ＣＨＦ装置２０７は、収束課金システムを用いることにより、イベント課金を実装し得、したがって、ＣＴＦによりイベント課金を処理するための方法は、課金システムによりイベント課金を処理するための方法と一致して、課金システムにより実施される処理と、サービスに対してＣＴＦにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。

図６は、本出願の実施形態による、ＣＴＦ装置１０１により送られた課金要求をＣＨＦ装置２０７が受け取った後でＣＨＦ装置２０７によって実施される対応する処理の詳細な流れ図である。この実施形態では、ＣＴＦ装置１０１により送られた第１の課金要求は、イベント課金処理モードを担持せず、ＣＨＦ装置２０７は、ユーザ情報および／またはサービス情報に基づいてイベント課金処理モードを決定する。図６に対応する手順は、以下のステップを含む。

ステップ６０１：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第１の課金要求を受け取る。第１の課金要求については、ステップ５０２の説明を参照されたい。

一例では、第１の課金要求は、以下のように第１のイベント課金リソースに対する作成要求であることがある。
Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ
｛
ｏｎｅＥｖｅｎｔＣｈａｒｇｉｎｇ： ｔｒｕｅ
｝

本明細書では、「課金作成要求」は、そのメッセージが第１の課金要求であることを示す。第１の課金要求は、ワンタイム課金のパラメータ「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」を担持し、ワンタイム課金のパラメータは、後続の第３の課金要求があるかどうかを示すために使用される。「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」の値が真である場合には、それは、後続の第３の課金要求がないことを示す。第３の課金要求は、リソース更新課金要求またはリソース削除課金要求である。

任意選択で、第１の課金要求は、イベント識別子および／またはイベント量をさらに担持することがある。ＣＴＦ装置１０１は、各サービスの各タイプの課金イベントにイベント識別子を割り振る。すなわち、イベント識別子は、イベントのタイプを示す。例えば、ユーザ状態を問い合わせるネットワーク能力ＡＰＩに割り振られるイベント識別子は、ＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓである。イベント量は、イベントの発生回数の数量を示す。例えば、イベント量が３であるときには、それは、ユーザ状態のネットワーク能力が３回問い合わせられたことを示す。課金要求がイベントデータを担持しない場合には、それは、イベントの発生回数の数量が１であることを示す。イベント識別子およびイベント量を担持するリソースイベント課金リソース作成の例は、以下のとおりである。
Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ
｛
Ｍｕｌｔｉｐｌｅ Ｕｎｉｔ Ｕｓａｇｅ
Ｒｅｑｕｅｓｔｅｄ Ｕｎｉｔ
ＥｖｅｎｔＩＤ：ＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓ
ＥｖｅｎｔＮｕｍ：１
｝

本明細書では、「ＥｖｅｎｔＩＤ：ＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓ」は、イベント識別子がＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓであることを示す。本明細書では、「ＥｖｅｎｔＮｕｍ：１」は、イベントが使用された回数の数量が１であることを示す。

ステップ６０２：ＣＨＦ装置２０７が、第１の課金要求がイベントサービスに対する課金要求であると決定する。

第１の課金要求は、イベント課金を示す表示情報を担持し、ＣＨＦ装置２０７は、イベント課金を示す表示情報に基づいて、第１の課金要求がイベント課金サービスに対する課金要求であると決定する。したがって、ＣＨＦ装置２０７が第１の課金要求についての第１のイベント課金処理モードを決定する必要があると決定される。イベント課金を示す表示情報は、専用の識別子であり得る、または任意のイベント課金パラメータ（例えば、イベントサービス識別子、ワンタイムイベント課金の表示パラメータ、非ワンタイムイベント課金の表示パラメータ、およびイベント課金処理モード）であり得る。

一例では、ＣＨＦ装置２０７は、ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ（すなわちワンタイム課金要求パラメータ）に基づいて、第１の課金要求がイベント課金サービスに対する課金要求であると決定することがある。代替として、第１の課金要求は、イベントサービス識別子（例えばイベントＩＤ）を担持し、ＣＨＦ装置２０７は、イベント課金サービス識別子に基づいて、第１の課金要求がイベント課金サービスに対する課金要求であると決定する。

ステップ６０３：ＣＨＦ装置２０７が、第１の課金要求に基づいて、第１のイベント課金処理モードを決定する。

ＣＨＦ装置２０７は、第１の課金要求内のユーザ識別子、サービスタイプのパラメータまたはサービス状態のパラメータに基づいて、第１の課金要求の第１のイベント課金処理モードを決定することがある。例えば、第１の課金要求は、サービス状態を示すサービス状態パラメータを担持する。サービス状態が、サービスが発生する前である場合には、ＣＨＦ装置２０７によって実施される課金処理は、直接控除である。サービス状態が、サービスが発生した後である場合には、ＣＨＦ装置２０７によって実施される課金処理は、ＣＤＲを生成することである。一例では、サービス状態のパラメータは、サービス要求、またはサービス応答であり得る。ＣＨＦ装置２０７は、サービス要求について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生する前であると決定することがある。ＣＨＦ装置２０７は、サービス応答について、サービス状態のパラメータに基づいて、イベント課金サービス状態がサービスが発生した後であると決定することがある。

任意選択で、ＣＨＦ装置２０７は、さらに、第１の課金要求内のユーザ識別子に基づいてユーザ情報を取得し、課金要求のユーザが前払いのユーザであると決定し、第１のイベント課金処理モードが直接控除であると決定し、課金要求に対して直接控除を実施することがある。代替として、ＣＨＦ装置２０７は、課金要求のユーザが後払いのユーザであると決定し、第１のイベント課金処理モードがオフラインイベント報告であると決定し、課金要求に基づいてＣＤＲを生成することがある。

任意選択で、ＣＨＦ装置２０７は、さらに、イベント課金情報に含まれるワンタイムイベント課金の表示パラメータに基づいてイベント課金処理モードを決定することがある。具体的には、イベント課金情報がワンタイムイベント課金の表示パラメータを含む場合には、それは、第１の課金要求が後続の第３の課金要求を有することを示し、ＣＨＦ装置は、第１のイベント課金処理モードがイベント割当ての適用であると決定する。

ステップ６０４：ＣＨＦ装置２０７が、第１の課金要求がワンタイム課金要求であるかどうかを決定する。第１の課金要求がワンタイム課金要求である場合には、ステップ６０５が実施される。第１の課金要求がワンタイム課金要求でない場合には、ステップ６０９が実施される。

第１の課金要求は、ワンタイムイベント課金のパラメータ（例えばｏｎｅＥｖｅｎｔＣｈａｒｇｉｎｇ）を担持する。ワンタイムイベント課金のパラメータの値が真である場合には、ＣＨＦ装置２０７は、第１の課金要求がワンタイム課金要求である、すなわちイベント課金サービスが後続の第３の課金要求を有していないと決定する。ワンタイムイベント課金のパラメータの値が偽である場合には、ＣＨＦ装置２０７は、第１の課金要求が非ワンタイム課金要求である、すなわちイベント課金サービスが後続の第３の課金要求を有すると決定する。

第１の課金要求がワンタイムイベント課金のパラメータを担持し、第１の課金要求が非ワンタイム課金要求であると示すことは、以下の例であることがある。
Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ
｛ Ｍｕｌｔｉｐｌｅ Ｕｎｉｔ Ｕｓａｇｅ
Ｒｅｑｕｅｓｔｅｄ Ｕｎｉｔ
ＥｖｅｎｔＩＤ：ＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓ
ＥｖｅｎｔＮｕｍ：１
ｏｎｅＥｖｅｎｔＣｈａｒｇｉｎｇ：ｆａｌｓｅ
｝

本明細書では、課金作成要求は、メッセージがイベント課金リソースに対する作成要求であることを示す。本明細書では、「Ｍｕｌｔｉｐｌｅ Ｕｎｉｔ Ｕｓａｇｅ」は、サービスユニットの利用を示す。例えば、イベントＩＤは、イベント識別子を示し、ＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓは、イベント識別子がＮＥＦ＿ＧｅｔＵｓｅｒＳｔａｔｕｓであることを示す。ＥｖｅｎｔＮｕｍは、イベント課金サービスについて、イベントの発生回数の数量が１であることを示す。本明細書では、リソースイベント課金リソース作成に担持されるワンタイム課金のパラメータ「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」は、後続の課金要求があるかどうかを示すために使用される。「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」の値が偽である場合には、それは、後続のリソース更新課金要求またはリソース削除課金要求がある、すなわち第１の課金要求が非ワンタイム課金要求であることを示す。

ステップ６０５：ＣＨＦ装置２０７が、決定された第１のイベント課金処理モードに従って、課金処理を実施する。

第１のイベント課金処理モードが直接控除である場合には、ＣＨＦ装置２０７は、第１の課金要求に基づいて格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施する。格付けは、ユーザの預金残高が十分である場合には、ＣＨＦが価格を表す通貨単位の量を計算し、要求された単位または内部単位の量に基づいてユーザの勘定残高から計算された量を控除することを意味する。

第１のイベント課金処理モードがオフラインイベント報告である場合には、第１の課金要求に基づいて、イベント課金データ記録が生成される。

第１のイベント課金処理モードがイベント割当ての適用である場合には、イベント課金情報に基づいて格付けが実施され、格付けに基づいてイベント割当てが認可される。

第１の課金要求がワンタイム課金要求であるので、第１の課金要求に対して課金処理を実施した後で、ＣＨＦ装置２０７は、さらに第１のイベント課金リソースをリリースする必要がある。

ステップ６０６：ＣＨＦ装置２０７が、第１の課金要求に対する第１の課金応答をＣＴＦ装置に返す。

第１の課金応答は、ＣＨＦ装置によって決定された第１のイベント課金処理モードを担持する。ＣＨＦ装置２０７によって決定された第１のイベント課金処理モードは、直接控除またはＣＤＲ生成である。

第１の課金応答は、ＣＨＦ装置２０７によって作成されたイベントリソース識別子をさらに担持する。第１のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。

リソース作成課金応答は、以下であることがある。
Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｓｐｏｎｓｅ
｛
ＥｖｅｎｔＣｈａｒｇｉｎｇＨａｎｄｌｉｎｇ： ｛Ｄｅｂｉｔ ｏｒ Ｒｅｃｏｒｄ｝

本明細書では、「Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｓｐｏｎｓｅ」は、リソースについて課金応答を作成することを示す。本明細書では、「ＥｖｅｎｔＣｈａｒｇｉｎｇＨａｎｄｌｉｎｇ」パラメータは、ＣＨＦ装置２０７によって決定された第１のイベント課金処理モードを担持し、ここで、「Ｄｅｂｉｔ」は、ＣＨＦ装置２０７によって決定された課金処理モードが直接控除であることを示す。本明細書では、「Ｒｅｃｏｒｄ」は、ＣＨＦによって決定された課金処理モードがＣＤＲを生成することであることを示し、この課金処理モードは、オフラインイベント報告に対応する。

ステップ６０７：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第２の課金要求を受け取る。

第１のイベント課金処理モードが直接控除であるときには、第１の課金応答を受け取った後で、ＣＴＦ装置１０１は、イベント課金サービスが実施されるのに失敗したと決定し、ＣＴＦ装置１０１は、イベント課金サービスについて第２の課金要求を送る。第２の課金要求は、第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第１のイベント課金リソースの識別子とを含み、第１のイベント課金リソースの識別子は、第１の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。

第２の課金要求の詳細な説明については、ステップ５０５の説明を参照されたい。本出願のこの実施形態では、詳細を改めて説明しない。

ステップ６０８：ＣＨＦ装置２０７が、第２の課金要求に対する第２の課金応答をＣＴＦ装置に返す。ここで、この課金応答は、ＣＨＦ装置２０７によって決定された課金処理モードを担持する。ＣＨＦ装置２０７によって決定された課金処理モードは、直接控除またはイベント割当ての適用である。

ステップ６０８の説明については、ステップ５０６を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。

ステップ６０９：ＣＨＦ装置２０７が、第１の課金要求内に担持される第１のイベント課金処理モードに従って課金処理を実施する。

第１のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第１のイベント課金リソース割当てが認可され、格付けに基づいて第１のイベント課金リソースの識別子が割り振られる。

ステップ６１０：ＣＨＦ装置２０７が、第１の課金要求に対する第１の課金応答をＣＴＦ装置に返す。

第１の課金応答は、ＣＨＦ装置によって決定された第１のイベント課金処理モードを担持する。ＣＨＦ装置によって決定された第１のイベント課金処理モードは、割当ての認可である。第１の課金応答は、さらに、ＣＨＦ装置２０７によって作成された第１のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。

ステップ６１１：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第３の課金要求を受け取る。

イベント課金サービスの実行を完了した後で、ＣＴＦ装置は、第３の課金要求をＣＨＦ装置２０７に送る。第２の課金要求は、第１のイベント課金リソースに対する更新要求または削除要求であることがある。第３の課金要求は、第１のイベントリソース識別子を担持する。

さらに、第２の課金要求は、第２のイベント処理モードをさらに担持することがあり、第２のイベント処理モードは、割当て使用報告である。ＣＨＦ装置２０７は、第２のイベント処理モードに従って、イベント課金データ記録を生成する。

ステップ６１２：ＣＨＦ装置２０７が、第３の課金要求に対する第３の課金応答をＣＴＦ装置に返す。

任意選択で、ステップ６０１または６０７の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第１のイベント課金リソースまたは第２のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、ＣＨＦ装置２０７は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をＣＴＦ装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、ＣＨＦ装置２０７は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、ＣＨＦ装置２０７は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。

この方法によれば、ＣＨＦ装置２０７は、第１の課金要求に基づいて第１のイベント課金処理モードを決定して、サービスに対して課金システムにより実施される処理と、ＣＴＦにより実施される処理との間の不一致を回避することがあり、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止することがある。

図７は、本出願の実施形態による、ＣＨＦ装置２０７がＣＴＦ装置１０１により送られた課金要求を受け取った後でＣＨＦ装置２０７によって実施される対応する処理の詳細な流れ図である。この実施形態では、ＣＴＦ装置１０１により送られる第１の課金要求は、第１のイベント課金処理モードを担持し、ＣＨＦ装置２０７は、第１の課金要求内に担持される第１のイベント課金処理モードに従って第１のイベント課金処理モードを決定する。図７に対応する手順は、以下のステップを含む。

ステップ７０１：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第１の課金要求を受け取る。第１の課金要求については、ステップ５０２の説明を参照されたい。

一例では、第１の課金要求は、以下のように第１のイベント課金リソースに対する作成要求であることがある。
Ｃｈａｒｇｉｎｇ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ
｛
ｏｎｅＥｖｅｎｔＣｈａｒｇｉｎｇ：ｔｒｕｅ
ｅｖｅｎｔＣＨＭｅｔｈｏｄ：ｄｅｂｉｔ
｝

本明細書では、「課金作成要求」は、第１の課金要求が課金リソース作成要求であることを示す。第１の課金要求は、ワンタイム課金のパラメータ「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」を担持し、ワンタイム課金のパラメータは、後続の第３の課金要求があるかどうかを示すために使用される。「ｏｎｅＥｖｅｎｔｃｈａｒｇｉｎｇ」の値が真である場合には、それは、後続の第３の課金要求がないことを示す。第３の課金要求は、リソース更新課金要求またはリソース削除課金要求である。本明細書では、「ｅｖｅｎｔＣＨＭｅｔｈｏｄ」は、第１のイベント課金処理モードであり、第１のイベント課金処理モードの値は、直接控除（ｄｅｂｉｔ）、オフラインイベント報告（記録）、またはイベント割当ての適用（予約）である可能性がある。

任意選択で、第１の課金要求は、イベント識別子および／またはイベント量をさらに担持することがある。例については、ステップ６０１の説明を参照されたい。

ステップ７０２：ＣＨＦ装置２０７が、第１の課金要求がイベントサービスに対する課金要求であると決定する。ステップ７０２の詳細な説明については、ステップ６０２の説明を参照されたい。本発明のこの実施形態では、本明細書で詳細を改めて説明しない。

ステップ７０３：ＣＨＦ装置２０７が、第１の課金要求に基づいて、第１のイベント課金処理モードを決定する。

第１の課金要求は、第１のイベント課金処理モードを担持し、ＣＨＦ装置２０７は、第１の課金要求に基づいて第１のイベント課金処理モードを決定する。

ステップ７０４：ＣＨＦ装置２０７が、第１の課金要求がワンタイム課金要求であるかどうかを決定する。第１の課金要求がワンタイム課金要求である場合には、ステップ７０５が実施される。第１の課金要求がワンタイム課金要求でない場合には、ステップ７０９が実施される。

ステップ７０４の詳細な説明については、ステップ６０４を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。

ステップ７０５：ＣＨＦ装置が、決定された第１のイベント課金処理モードに従って、課金処理を実施する。ステップ７０５の詳細な説明については、ステップ６０５を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。

ステップ７０６：ＣＨＦ装置２０７が、第１の課金要求に対する第１の課金応答をＣＴＦ装置に返す。

第１の課金応答は、ＣＨＦ装置２０７によって作成されたイベントリソース識別子を担持する。第１のイベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。

ステップ７０７：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第２の課金要求を受け取る。ステップ７０７の詳細な説明については、ステップ６０７を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。

ステップ７０８：ＣＨＦ装置２０７が、第２の課金要求に対する第２の課金応答をＣＴＦ装置に返す。

ステップ７０８の説明については、ステップ５０６を参照されたい。本発明のこの実施形態では、本明細書で詳細を説明しない。

ステップ７０９：ＣＨＦ装置２０７が、第１の課金要求内に担持される第１のイベント課金処理モードに従って課金処理を実施する。

第１のイベント課金処理モードは、イベント割当ての適用である。具体的には、イベント課金情報に基づいて格付けが実施され、格付けに基づいて第１のイベント課金リソース割当てが認可され、格付けに基づいて第１のイベント課金リソースの識別子が割り振られる。

ステップ７１０：ＣＨＦ装置２０７が、第１の課金要求に対する第１の課金応答をＣＴＦ装置に返す。

第１の課金応答は、ＣＨＦ装置２０７によって作成された第１のイベントリソース識別子を担持する。イベントリソース識別子は、リソース作成課金応答のメッセージヘッダ内に担持される。

ステップ７１１：ＣＨＦ装置２０７が、ＣＴＦ装置１０１により送られた第３の課金要求を受け取る。ステップ７１１の詳細な説明については、ステップ６１１を参照されたい。本出願のこの実施形態では、本明細書で詳細を改めて説明しない。

ステップ７１２：ＣＨＦ装置２０７が、第３の課金要求に対する第３の課金応答をＣＴＦ装置に返す。

任意選択で、ステップ７０１または７０７の課金要求は、再送信決定パラメータをさらに担持することがある。再送信決定パラメータに基づいて、リソースイベント課金リソースが再送信されたリソース作成要求ではないと決定された後で、課金要求に基づいて、第１のイベント課金リソースまたは第２のイベント課金リソースが作成される。再送信決定パラメータは、再送信識別子、イベント識別子、または以前の課金要求のメッセージ識別子などであることがある。再送信決定パラメータを担持する課金要求を受け取った後で、ＣＨＦ装置２０７は、再送信決定パラメータに基づいて、以前の課金要求についての処理結果をＣＴＦ装置に返す。さらに、以前の課金要求がうまく処理されたと決定した後で、ＣＨＦ装置２０７は、以前の課金要求についての処理結果を返す。または、以前の課金要求が処理されるのに失敗したと決定した後で、ＣＨＦ装置２０７は、再送信決定パラメータを担持する課金要求を処理し、処理結果を返す。

この方法によれば、ＣＨＦ装置２０７は、収束課金システムを用いることによってイベント課金サービスの課金を実装することがある。第１の課金要求は、第１のイベント課金処理モードを担持し、ＣＨＦ装置２０７は、第１のイベント課金処理モードに従って、処理を直接実施することがある。これにより、サービスに対して課金システムにより実施される処理と、ＣＴＦにより実施される処理との間の不一致を回避し、かつ操作者の損失、またはユーザのサービス体験に対する影響をさらに阻止する。

以上では、ネットワーク要素間の相互作用の観点から、本出願の実施形態で提供される解決策について主に説明した。前述の機能を実装するためには、課金機能装置および課金トリガー機能装置などのデバイスは、それらの機能を実施するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解され得る。当業者なら、本明細書に開示される実施形態に記載される例のモジュールおよびアルゴリズムステップと組み合わせて、本出願が、ハードウェア、またはハードウェアとコンピュータソフトウェアの組合せによって実装され得ることに容易に気づくであろう。機能がハードウェアによって実施されるか、コンピュータソフトウェアによって駆動されるハードウェアによって実施されるかは、これらの技術的解決策の特定の応用分野および設計上の制約によって決まる。当業者なら、異なる方法を使用して、説明された機能を特定の各応用分野のために実装することがあり得るが、その実装が本出願の範囲を超えると考えられるべきではない。

本出願の実施形態では、前述の方法例に基づいて、ＣＴＦ装置１０１およびＣＨＦ装置２０７などのデバイスに対して機能モジュールの分割が実施されることがある。例えば、各機能モジュールはそれぞれの機能に対応する分割によって得られることがあるし、または、２つ以上の機能が１つの処理モジュールに統合されることがある。統合されたモジュールは、ハードウェアの形態で実装され得る、またはソフトウェア機能モジュールの形態で実装され得る。本出願の実施形態では、モジュールの分割は一例であり、単に論理機能分割であることに留意されたい。実際の実装では、別の分割方法が用いられることがある。

例えば、機能モジュールが統合的な分割によって得られるときには、図８は、装置８００の構造の概略図である。装置８００は、前述の実施形態における課金機能装置２０７であり得る、または課金機能装置２０７内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図８に示すように、この装置は、受信モジュール８０１と、決定モジュール８０２と、処理モジュール８０３と、送信モジュール８０４とを含む。

受信モジュール８０１は、課金トリガー機能ＣＴＦ装置により送られた第１の課金要求を受け取るように構成され、第１の課金要求は、イベント課金情報を担持する。決定モジュール８０２は、イベント課金情報に基づいて第１のイベント課金処理モードを決定するように構成される。処理モジュール８０３は、第１のイベント課金処理モードに従って第１の課金要求を処理するように構成される。

任意選択で、イベント課金情報は、イベント課金を示す表示情報を含み、決定モジュール８０２は、イベント課金表示情報に基づいて、第１の課金要求がイベントサービスに対する課金要求であると決定するようにさらに構成される。

任意選択で、第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、イベント課金情報は、ワンタイムイベント課金の表示パラメータをさらに含む。

決定モジュール８０２は、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求がワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール８０３は、第１の課金要求に基づいて第１のイベント課金リソースを作成するようにさらに構成され、決定モジュール８０２は、第１のイベント課金リソースが第２の課金要求を有していないと決定するようにさらに構成される。

代替として、決定モジュール８０２は、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求が非ワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュール８０３は、第１の課金要求に基づいて第１のイベント課金リソースを作成するようにさらに構成され、決定モジュール８０２は、第１のイベント課金リソースが第２の課金要求を有すると決定するようにさらに構成される。

任意選択で、第１の課金要求は、ユーザ識別子を担持し、イベント課金情報は、サービスタイプを示すパラメータをさらに含み、決定モジュール８０２がイベント課金情報に基づいて第１のイベント課金処理モードを決定することは、ユーザ識別子に基づいてユーザ情報を取得することと、イベント課金を示す表示情報、ユーザ情報、および／またはサービスタイプを示すパラメータに基づいて第１のイベント課金処理モードを決定することとを含み、ここで、第１のイベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である。

任意選択で、決定モジュール８０２が、ワンタイムイベント課金の表示パラメータに基づいて、第１の課金要求が非ワンタイムイベント課金要求であると決定した後において、決定モジュール８０２がイベント課金情報に基づいてイベント課金処理モードを決定することは、第１のイベント課金処理モードがイベント割当ての適用であると決定することを含む。

任意選択で、第１のイベント課金処理モードは、直接控除であり、処理モジュール８０３が第１のイベント課金処理モードに従って第１の課金要求を処理することは、第１の課金要求に基づいて格付けを実施し、格付け結果に基づいてユーザの勘定残高からの控除を実施することを含む。

任意選択で、第１のイベント課金処理モードは、オフラインイベント報告であり、処理モジュール８０３が第１のイベント課金処理モードに従って第１の課金要求を処理することは、第１の課金要求に基づいてイベント課金データ記録を生成することを含む。

任意選択で、第１のイベント課金処理モードは、イベント割当ての適用であり、処理モジュール８０３が第１のイベント課金処理モードに従って第１の課金要求を処理することは、イベント課金情報に基づいて格付けを実施すること、および格付けに基づいてイベント割当てを認可することを含む。

任意選択で、ＣＨＦ装置２０７は、第１の課金要求に対する課金応答をＣＴＦ装置１０１に返すように構成された送信モジュール８０４をさらに含み、ここで、課金応答は、決定された第１のイベント課金処理モードを担持する。

任意選択で、イベント課金処理モードは、直接控除であり、第１の課金要求を処理した後で、
受信モジュール８０１は、イベント課金サービスに対する第２の課金要求をさらに受け取り、ここで、第２の課金要求は、第２のイベント課金処理モードおよび第１のイベント課金リソースの識別子を含み、第２のイベント課金処理モードは、返済であり、かつ第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報であり、第１のイベント課金リソースの識別子は、第１の課金要求に対する課金応答から取得される。

決定モジュール８０２は、第１のイベント課金リソースの識別子に基づいて、第１の課金要求を用いることにより実施された直接控除における控除量を決定するようにさらに構成される。

処理モジュール８０３は、控除量をユーザの勘定残高に返済するようにさらに構成される。

任意選択で、第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、第２の課金要求は、ワンタイムイベント課金の表示パラメータを担持し、処理モジュール８０３は、第２の課金要求に基づいて第２のイベント課金リソースを作成するようにさらに構成される。

任意選択で、第２の課金要求は、第１のイベント課金リソースに対する更新要求であり、処理モジュール８０３は、第２の課金要求に基づいて第１のイベント課金リソースをリリースするようにさらに構成される。

任意選択で、第２の課金要求は、第１のイベント課金リソースに対するリリース要求であり、処理モジュール８０３は、第２の課金要求に基づいて第１のイベント課金リソースをリリースするようにさらに構成される。

任意選択で、第１の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール８０２は、再送信決定パラメータに基づいて、第１の課金要求が第１のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール８０３は、第１のイベント課金リソースを作成するようにさらに構成される。

任意選択で、第２の課金要求は、再送信決定パラメータをさらに含み、ここで、決定モジュール８０２は、再送信決定パラメータに基づいて、第２の課金要求が第２のイベント課金リソースに対する再送信された作成要求ではないと決定するようにさらに構成される。処理モジュール８０３は、第２のイベント課金リソースを作成するようにさらに構成される。

任意選択で、課金要求は、イベント識別子および／またはイベント量をさらに担持し、処理モジュール８０３が第１の課金要求を処理することは、イベント識別子および／またはイベント量に基づいて第１の課金要求を処理することを含む。

図９は、ＣＴＦ装置９００の概略構造図である。ＣＴＦ装置９００は、前述の実施形態の課金トリガー機能装置１０１であり得る、または課金トリガー機能装置１０１内のチップであり得る。これは、本出願の実施形態では、特に限定されない。図９に示すように、ＣＴＦ装置は、受信モジュール９０１、決定モジュール９０２、および送信モジュール９０３を含む。

決定モジュール９０２は、イベント課金サービスの課金イベントが発生したと決定するように構成され、送信モジュール９０３は、第１の課金要求を課金機能ＣＨＦ装置２０７に送るように構成され、ここで、第１の課金要求は、イベント課金情報を担持し、イベント課金情報は、イベント課金処理モードを決定するために使用され、受信モジュール９０１は、第１の課金要求のものであり、かつＣＨＦ装置により送られる、第１の課金応答を受け取るように構成され、ここで、第１の課金応答は、決定されたイベント課金処理モードに従って第１の課金要求を処理した結果を含む。

任意選択で、第１のイベント課金処理モードは、直接控除であり、第１の課金応答は、第１の課金要求に基づいて作成された第１のイベント課金リソースの識別子を含み、受信モジュール９０１がＣＨＦ装置２０７により送られた第１の課金応答を受け取った後で、決定モジュール９０２は、イベント課金サービスが実施されるのに失敗したと決定するようにさらに構成される。

送信モジュール９０３は、イベント課金サービスに対する第２の課金要求を送るようにさらに構成され、ここで、第２の課金要求は、第１の課金要求を用いることにより実施された直接控除における控除量を返済するように示すために使用される表示情報と、第１のイベント課金リソースの識別子とを含み、第１のイベント課金リソースの識別子は、第１の課金要求を用いることにより実施された直接控除における控除量を決定するために使用される。

図１０は、本出願の実施形態による課金トリガー機能装置または課金機能装置（本明細書では、短縮して課金デバイス１０００と呼ばれることがある）の実装の概略ブロック図である。課金デバイス１０００は、プロセッサ１０１０、メモリ１０３０、およびバスシステム１０５０を含み得る。プロセッサとメモリは、バスシステムによって接続される。メモリは、命令を記憶するように構成される。プロセッサは、メモリに記憶された命令を実行するように構成される。課金トリガー機能装置または課金機能装置のメモリは、プログラムコードを記憶し、プロセッサは、メモリに記憶されたプログラムコードを呼び出して、本出願に記載される様々な課金処理方法、例えば図５から図７の実施形態に記載される処理ステップを実施し得る。反復を避けるために、本明細書では詳細は説明しない。

本出願のこの実施形態では、プロセッサ１０１０は、中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、略称「ＣＰＵ」）であることがあるし、あるいはプロセッサ１０１０は、別の汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）もしくは別のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェア構成要素などであることがある。汎用プロセッサは、マイクロプロセッサであることがあるし、またはプロセッサは、任意の従来のプロセッサなどであることがある。

メモリ１０３０は、読取り専用メモリ（ＲＯＭ）デバイスまたはランダムアクセスメモリ（ＲＡＭ）デバイスを含むことがある。代替として、適当なタイプの任意のその他の記憶デバイスが、メモリ１０３０として使用されることがある。メモリ１０３０は、バス１０５０を介してプロセッサ１０１０によってアクセスされるコードおよびデータ１０３１を含むことがある。メモリ１０３０は、オペレーティングシステム１０３３およびアプリケーションプログラム１０３５をさらに含むことがある。アプリケーションプログラム１０３５は、プロセッサ１０１０が本出願に記載される課金方法を実施することを可能にする少なくとも１つのプログラムを含む。例えば、アプリケーションプログラム１０３５は、アプリケーション１からＮを含むことがあり、さらに、本出願に記載される課金方法を実施する課金アプリケーション（略称、課金アプリケーション）を含むことがある。

バスシステム１０５０は、データバスに加えて、電力バス、制御バス、および状態信号バスなどをさらに含むことがある。ただし、説明が分かりやすくなるように、図中の様々なタイプのバスは、バスシステム１０５０として示されている。

任意選択で、課金デバイス１０００は、トランシーバ１０７０などの１つまたは複数の入出力デバイスをさらに含むことがある。トランシーバ１０７０は、別のネットワーク機能装置と通信するように構成される。

当業者なら、本明細書に開示および記載される様々な例示的な論理ブロック、モジュール、およびアルゴリズムステップを参照して記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せによって実装されることが可能であることを理解することができる。実施形態がソフトウェアによって実装される場合には、例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体に記憶され、あるいはコンピュータ可読媒体を介して送信され、ハードウェア型の処理モジュールによって実行されることがある。コンピュータ可読媒体は、データ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体、または（例えば通信プロトコルに従う）１つの場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含むことがある。このように、コンピュータ可読媒体は、一般に、（１）非一時的な有形のコンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応することがある。データ記憶媒体は、本出願に記載される技術を実装するための命令、コード、および／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされることが可能な任意の使用可能な媒体であり得る。コンピュータプログラム製品が、コンピュータ可読媒体を含み得る。

限定されるわけではないが、一例では、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、または別のコンパクトディスク記憶装置、磁気ディスク記憶装置、または別の磁気記憶装置、フラッシュメモリ、あるいは所望のプログラムコードを命令またはデータ構造の形態で記憶するために使用されることが可能であり、かつコンピュータによってアクセス可能である、その他の任意の媒体を含み得る。さらに、任意の接続は、コンピュータ可読媒体と称されるのが適当である。例えば、命令が、ウェブサイト、サーバ、または別の遠隔ソースから、同軸ケーブル、光ファイバ、撚り対線、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を介して送信される場合には、同軸ケーブル、光ファイバ、撚り対線、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、またはその他の一時的媒体を含まず、実際には非一時的な有形の記憶媒体を意味することを理解されたい。本明細書で使用されるディスクは、コンパクトディスク（ＣＤ）、レーザディスク、光ディスク、デジタル汎用ディスク（ＤＶＤ）、およびＢｌｕ－ｒａｙディスクを含む。磁気ディスクは、通常は磁気的にデータを再現し、光学ディスクは、レーザを用いて光学的にデータを再現する。上述の品目の組合せもまた、コンピュータ可読媒体の範囲に含まれるものとする。

命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいはその他の等価な集積またはディスクリート論理回路などの、１つまたは複数のプロセッサによって実行されることがある。したがって、本明細書で使用される「プロセッサ」という用語は、本明細書に記載される技術を実装するのに適した前述の構造またはその他の任意の構造のうちのいずれか１つであることがある。さらに、いくつかの態様では、本明細書に記載される例示的な論理ブロック、モジュール、およびステップを参照して記載される機能は、符号化および復号を行うように構成された専用のハードウェアおよび／またはソフトウェアモジュール内に設けられることがあるし、あるいは結合されたコーデック内に組み込まれることがある。さらに、これらの技術は、１つまたは複数の回路または論理要素内で完全に実装されることがある。

本出願の技術は、集積回路（ＩＣ）またはＩＣのグループ（例えばチップセット）を含む、様々な装置またはデバイスで実装され得る。本出願では、様々な構成要素、モジュール、またはモジュールについて、開示される技術を実施するように構成された装置の機能態様を強調するように説明されているが、これらは、必ずしも異なるハードウェアモジュールによって実装されるわけではない。実際には、上述のように、様々なモジュールが、適当なソフトウェアおよび／またはファームウェアと組み合わせてコーデックハードウェアモジュールに結合され得る、あるいは相互運用可能なハードウェアモジュール（上述の１つまたは複数のプロセッサを含む）によって提供され得る。

以上の説明は、単に本出願の具体的な実装であり、本出願の保護範囲を限定することを意図しているわけではない。本出願に開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

Claims (25)

1. 課金方法であって、
   課金トリガー機能装置により送られた第１の課金要求を、課金機能装置によって受け取るステップ（５０２、６０１、７０１）であって、前記第１の課金要求は、イベント課金情報を担持し、前記イベント課金情報は、ワンタイムイベント課金の表示パラメータおよびイベント課金処理モードを含み、前記イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である、ステップと、
   前記イベント課金情報に基づいて、前記課金機能装置によって第１のイベント課金処理モードを決定するステップ（６０３、７０３）と、
   前記課金機能装置によって、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理するステップ（５０３、６０５、６０９、７０５、７０９）と
   を含む方法。
2. 前記イベント課金情報は、イベント課金を示す表示情報を含み、前記方法は、
   前記イベント課金表示情報に基づき、前記第１の課金要求はイベント課金サービスに対する課金要求であると決定するステップ（６０２、７０２）
   をさらに含む請求項１に記載の方法。
3. 前記第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、前記方法は、
   ワンタイムイベント課金の前記表示パラメータに基づき、前記第１の課金要求は、ワンタイムイベント課金要求であると決定し、前記第１の課金要求に基づいて前記第１のイベント課金リソースを作成し、かつ前記第１のイベント課金リソースは第３の課金要求を有しないと決定するステップ（６０４、７０４）、または
   ワンタイムイベント課金の前記表示パラメータに基づき、前記第１の課金要求は、非ワンタイムイベント課金要求であると決定し、前記第１の課金要求に基づいて前記第１のイベント課金リソースを作成し、かつ前記第１のイベント課金リソースは第３の課金要求を有すると決定するステップ（６０４、７０４）
   をさらに含む請求項１または２に記載の方法。
4. 前記第１のイベント課金処理モードは、前記直接控除であり、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理する前記ステップは、前記第１の課金要求に基づいて格付けを実施し、かつ格付け結果に基づいてユーザの勘定残高からの控除を実施するステップを含む、または
   前記第１のイベント課金処理モードは、前記オフラインイベント報告であり、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理する前記ステップは、前記第１の課金要求に基づいてイベント課金データ記録を生成するステップを含む、または
   前記第１のイベント課金処理モードは、前記イベント割当ての適用であり、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理する前記ステップは、前記イベント課金情報に基づいて格付けを実施し、かつ前記格付けに基づいてイベント割当てを認可するステップを含む請求項１に記載の方法。
5. 前記イベント課金処理モードは、前記直接控除であり、前記第１の課金要求を処理する前記ステップの後、前記方法は、
   前記イベント課金サービスに対する第２の課金要求を受け取るステップであって、前記第２の課金要求は、第２のイベント課金処理モードおよび前記第１のイベント課金リソースの識別子を含み、前記第２のイベント課金処理モードは、返済であり、かつ前記第１の課金要求を用いることにより実施された前記直接控除における控除量を返済するように示すために使用される表示情報であり、前記第１のイベント課金リソースの前記識別子は、前記第１の課金要求に対する課金応答から取得される、ステップと、
   前記第１のイベント課金リソースの前記識別子に基づいて、前記第１の課金要求を用いることにより実施された前記直接控除における前記控除量を決定するステップと、
   前記控除量を、前記ユーザの前記勘定残高に返済するステップと
   をさらに含む請求項４に記載の方法。
6. 前記第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、前記第２の課金要求は、ワンタイムイベント課金の表示パラメータを担持し、前記方法は、前記第２の課金要求に基づいて、前記第２のイベント課金リソースを作成するステップをさらに含む、または
   前記第２の課金要求は、前記第１のイベント課金リソースに対する更新要求であり、前記方法は、前記第２の課金要求に基づいて、前記第１のイベント課金リソースをリリースするステップをさらに含む、または
   前記第２の課金要求は、前記第１のイベント課金リソースに対するリリース要求であり、前記方法は、前記第２の課金要求に基づいて、前記第１のイベント課金リソースをリリースするステップをさらに含む請求項５に記載の方法。
7. 前記第１の課金要求は、再送信決定パラメータをさらに含み、前記方法は、前記再送信決定パラメータに基づいて、前記第１の課金要求は、前記第１のイベント課金リソースに対する再送信された作成要求ではないと決定した後、前記第１のイベント課金リソースを作成するステップをさらに含む請求項１乃至６のいずれか一項に記載の方法。
8. 課金方法であって、
   課金トリガー機能装置によって、イベント課金サービスの課金イベントが生じたと決定するステップ（５０２）と、
   前記課金トリガー機能装置によって、第１の課金要求を課金機能装置に送るステップ（５０２、６０１、７０１）であって、前記第１の課金要求は、イベント課金情報を担持し、前記イベント課金情報は、イベント課金処理モードを決定するために使用され、前記イベント課金情報は、ワンタイムイベント課金の表示パラメータおよびイベント課金処理モードを含み、前記イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用であるステップと、
   前記第１の課金要求のものであり、かつ前記課金機能装置によって送られる第１の課金応答を、前記課金トリガー機能装置によって受け取るステップ（５０４、６０６、６１０、７０６、７１０）であって、前記第１の課金応答は、前記決定されたイベント課金処理モードに従って前記第１の課金要求を処理した結果を含む、ステップと
   を含む方法。
9. 前記第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、ワンタイムイベント課金の前記表示パラメータは、前記第１のイベント課金リソースが前記第１の課金要求に基づいて作成された後、前記第１のイベント課金リソースが後続する課金要求を有しないことを示し、またはワンタイムイベント課金の前記表示パラメータは、前記第１のイベント課金リソースが前記第１の課金要求に基づいて作成された後、前記第１のイベント課金リソースが後続する課金要求を有することを示す、請求項８に記載の方法。
10. 前記第１のイベント課金処理モードは、前記直接控除であり、前記第１の課金応答は、前記第１の課金要求に基づいて作成された前記第１のイベント課金リソースの識別子を含み、前記課金機能装置により送られた第１の課金応答を受け取る前記ステップの後、前記方法は、
    前記イベント課金サービスは実施されるのが失敗したと決定するステップと、
    前記イベント課金サービスに対する第２の課金要求を送るステップであって、前記第２の課金要求は、前記第１の課金要求を用いることにより実施された前記直接控除における控除量を返済するように示すために使用される表示情報と、前記第１のイベント課金リソースの前記識別子と、を含み、前記第１のイベント課金リソースの前記識別子は、前記第１の課金要求を用いることにより実施された前記直接控除における前記控除量を決定するために使用される、ステップと
    をさらに含む請求項８または９に記載の方法。
11. 前記第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、前記第２の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持する、または前記第２の課金要求メッセージは、前記第１のイベント課金リソースに対する更新要求である、もしくは前記第１のイベント課金リソースに対するリリース要求である請求項１０に記載の方法。
12. 課金機能装置であって、
    課金トリガー機能ＣＴＦ装置により送られた第１の課金要求を受け取るように構成された受信モジュールであって、前記第１の課金要求は、イベント課金情報を担持し、前記イベント課金情報は、ワンタイムイベント課金の表示パラメータおよびイベント課金処理モードを含み、前記イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である、受信モジュールと、
    前記イベント課金情報に基づいて、第１のイベント課金処理モードを決定するように構成された決定モジュールと、
    前記第１のイベント課金処理モードに従って、前記第１の課金要求を処理するように構成された処理モジュールと
    を備える装置。
13. 前記イベント課金情報は、イベントの課金を示す表示情報を含み、前記決定することは、前記イベント課金表示情報に基づいて、前記第１の課金要求がイベントサービスに対する課金要求であると決定するようにさらに構成される請求項１２に記載の装置。
14. 前記第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、
    決定モジュールは、ワンタイムイベント課金の前記表示パラメータに基づいて、前記第１の課金要求が、ワンタイムイベント課金要求であると決定するようにさらに構成され、処理モジュールは、前記第１の課金要求に基づいて、前記第１のイベント課金リソースを作成するようにさらに構成され、前記決定モジュールは、前記第１のイベント課金リソースが第３の課金要求を有しないと決定するようにさらに構成される、または
    前記決定モジュールは、ワンタイムイベント課金の前記表示パラメータに基づき、前記第１の課金要求が、非ワンタイムイベント課金要求であると決定するようにさらに構成され、前記処理モジュールは、前記第１の課金要求に基づいて、前記第１のイベント課金リソースを作成するようにさらに構成され、前記決定モジュールは、前記第１のイベント課金リソースが、第３の課金要求を有すると決定するようにさらに構成される請求項１２または１３に記載の装置。
15. 前記第１のイベント課金処理モードは、前記直接控除であり、前記処理モジュールが、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理することは、前記第１の課金要求に対する格付けを実施し、かつ格付け結果に基づいてユーザの勘定残高からの控除を実施することを含む、または
    前記第１のイベント課金処理モードは、前記オフラインイベント報告であり、前記処理モジュールが、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理することは、前記第１の課金要求に基づいてイベント課金データ記録を生成することを含む、または
    前記第１のイベント課金処理モードは、前記イベント割当ての適用であり、前記処理モジュールが、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理することは、前記イベント課金情報に基づいて格付けを実施し、前記格付けに基づいてイベント割当てを認可することを含む請求項１４に記載の装置。
16. 前記イベント課金処理モードは、前記直接控除であり、前記第１の課金要求を処理した後に、
    受信モジュールは、前記イベント課金サービスに対する第２の課金要求をさらに受け取り、ここで、前記第２の課金要求は、第２のイベント課金処理モードおよび前記第１のイベント課金リソースの識別子を含み、前記第２のイベント課金処理モードは、返済であり、かつ前記第１の課金要求を用いることにより実施された前記直接控除における控除量を返済するように示すために使用される表示情報であり、前記第１のイベント課金リソースの前記識別子は、前記第１の課金要求に対する課金応答から取得される、
    前記決定モジュールは、前記第１のイベント課金リソースの前記識別子に基づいて、前記第１の課金要求を用いることにより実施された前記直接控除における前記控除量を決定するようにさらに構成され、かつ
    前記処理モジュールは、前記ユーザの前記勘定残高に前記控除量を返済するようにさらに構成される請求項１５に記載の装置。
17. 前記第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、前記第２の課金要求は、ワンタイムイベント課金の表示パラメータを担持し、前記処理モジュールは、前記第２の課金要求に基づいて、前記第２のイベント課金リソースを作成するようにさらに構成される、または
    前記第２の課金要求は、前記第１のイベント課金リソースに対する更新要求であり、前記処理モジュールは、前記第２の課金要求に基づいて、前記第１のイベント課金リソースをリリースするようにさらに構成される、または
    前記第２の課金要求は、前記第１のイベント課金リソースに対するリリース要求であり、前記第１のイベント課金リソースは、前記第２の課金要求に基づいている請求項１６に記載の装置。
18. 課金トリガー機能装置であって、
    イベント課金サービスの課金イベントが生じたと決定するように構成された決定モジュールと、
    第１の課金要求を、課金機能装置に送るように構成された送信モジュールであって、前記第１の課金要求は、イベント課金情報を担持し、前記イベント課金情報は、イベント課金処理モードを決定するために使用され、前記イベント課金情報は、ワンタイムイベント課金の表示パラメータおよびイベント課金処理モードを含み、前記イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用である送信モジュールと
    前記第１の課金要求のものであり、かつ前記課金機能装置によって送られた第１の課金応答を受け取るように構成された受信モジュールであって、前記第１の課金応答は、前記決定されたイベント課金処理モードに従って、前記第１の課金要求を処理した結果を含む、受信モジュールと
    を備える装置。
19. 前記第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、ワンタイムイベント課金の前記表示パラメータが、前記第１のイベント課金リソースが前記第１の課金要求に基づいて作成された後、前記第１のイベント課金リソースが後続する課金要求を有さないことを示し、または
    前記第１の課金要求は、第１のイベント課金リソースに対する作成要求であり、ワンタイムイベント課金の前記表示パラメータが、前記第１のイベント課金リソースが前記第１の課金要求に基づいて作成された後、前記第１のイベント課金リソースが後続する課金要求を有することを示す、請求項１８に記載の装置。
20. 前記第１のイベント課金処理モードは、前記直接控除であり、前記第１の課金応答は、前記第１の課金要求に基づいて作成された前記第１のイベント課金リソースの識別子を含み、前記受信モジュールが、前記課金機能装置により送られた前記第１の課金応答を受け取った後、前記決定モジュールは、前記イベント課金サービスが実施されるのに失敗したと決定するようにされに構成され、
    前記送信モジュールは、前記イベント課金サービスに対する第２の課金要求を送るようにさらに構成され、前記第２の課金要求は、前記第１の課金要求、および前記第１のイベント課金リソースの前記識別子を用いることにより実施される前記直接控除における控除量を返済することを示すために使用される表示情報を含み、前記第１のイベント課金リソースの前記識別子は、前記第１の課金要求を用いることにより実施される前記直接控除における前記控除量を決定するために使用される請求項１８に記載の装置。
21. 前記第２の課金要求は、第２のイベント課金リソースに対する作成要求であり、前記第２の課金要求は、ワンタイムイベント課金の表示パラメータをさらに担持する、または前記第２の課金要求は、前記第１のイベント課金リソースに対する更新要求、もしくは前記第１のイベント課金リソースに対するリリース要求である請求項２０に記載の装置。
22. 課金方法であって、
    前記課金トリガー機能装置によって、第１の課金要求を課金機能装置に送るステップ（５０２、６０１、７０１）であって、前記第１の課金要求は、イベント課金情報を担持し、前記イベント課金情報は、イベント課金処理モードを決定するために使用され、前記イベント課金情報は、ワンタイムイベント課金の表示パラメータおよびイベント課金処理モードを含み、前記イベント課金処理モードは、直接控除、オフラインイベント報告、またはイベント割当ての適用であるステップと、
    前記イベント課金情報に基づいて、前記課金機能装置によって第１のイベント課金処理モードを決定するステップ（６０３、７０３）と、
    前記課金機能装置によって、前記第１のイベント課金処理モードに従って前記第１の課金要求を処理するステップ（５０３、６０５、６０９、７０５、７０９）と
    を含む方法。
23. 課金トリガー機能装置によって、イベント課金サービスの課金イベントが生じたと決定するステップ（５０２）をさらに含む請求項２２に記載の方法。
24. 前記第１の課金要求のものであり、かつ前記課金機能装置によって送られる第１の課金応答を、前記課金トリガー機能装置によって受け取るステップ（５０４、６０６、６１０、７０６、７１０）であって、前記第１の課金応答は、前記決定されたイベント課金処理モードに従って前記第１の課金要求を処理した結果を含む、ステップをさらに含む請求項２２または２３に記載の方法。
25. ワンタイムイベント課金の前記表示パラメータに基づき、前記第１の課金要求は、ワンタイムイベント課金要求であると決定し、前記第１の課金要求に基づいて前記第１のイベント課金リソースを作成し、かつ前記第１のイベント課金リソースは第３の課金要求を有しないと決定するステップ（６０４、７０４）、または
    ワンタイムイベント課金の前記表示パラメータに基づき、前記第１の課金要求は、非ワンタイムイベント課金要求であると決定し、前記第１の課金要求に基づいて前記第１のイベント課金リソースを作成し、かつ前記第１のイベント課金リソースは第３の課金要求を有すると決定するステップ（６０４、７０４）
    をさらに含む請求項２２乃至２４のいずれか一項に記載の方法。

Images