JP6761056B2 - リソース処理方法及び装置 - Google Patents

Description

本願は、２０１６年６月２２日に出願され「リソース処理方法及び装置」と題された中国特許出願第２０１６１０４６１０３３．５号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。

本願は、コンピュータ技術の分野に関し、特に、リソース処理方法及び装置に関する。

サービスプロバイダ（例えば、ウェブサイト）により提供されるサービスを利用する際、ユーザは、通常、サービスプロバイダのリソースを特定の量だけ消費する。サービスを円滑に利用するために、ユーザは、通常、対応する量のリソースコストをサービスプロバイダへフィードバックする。

現在、実際の状況において、サービスプロバイダはオンラインプリペイドリソース（例えば、電子バウチャや電子プリペイドカード（以下、簡略化して「プリペイドリソース」と称する））をユーザへ提供する。サービスプロバイダにより提供されるサービスをユーザが利用する際、プリペイドリソースは対応する量のリソースコストを相殺することが可能になる。

従来技術において、ユーザは、プリペイドリソースを１つずつサービスプロバイダから取得でき、それにより、ユーザは、サービスプロバイダによって提供されるサービスを利用する際、取得したプリペイドリソースを利用できる。サービスプロバイダのバックエンドサーバ（以下、簡略化して「サーバ」と称する）は、毎回、ユーザが取得するプリペイドリソースに対してリソースアカウントを作成し（つまり、各リソースアカウントは、毎回、ユーザが取得するプリペイドリソースに対応する）、各リソースアカウントとユーザとを関連付ける。ユーザがプリペイドリソースを利用する必要があるとき、サーバは、ユーザに関連付けられた各リソースアカウントを特定し、対応する量のプリペイドリソースを各リソースアカウントから差し引く。この差し引きは、差し引かれたプリペイドリソースの総量がサービスに必要なリソースの総量と一致するまで行われる。

例えば、ユーザが、サービスプロバイダにより提供される電子プリペイドカードを複数購入したとする。これに応じて、バックエンドサーバは、各電子プリペイドカードに対してプリペイメントアカウントを作成し、プリペイメントアカウントとユーザとを関連付ける。ユーザは、支払いを行う際、サービスプロバイダにユーザ情報（例えば、ユーザ名）を提供するだけでよい。そして、サーバは、ユーザ情報に基づいてユーザの複数のプリペイメントアカウントを特定し、対応する割当量を各プリペイメントアカウントから差し引き、支払いを完了させる。

しかし、先に述べた方法において、サーバは、対応する量のプリペイドリソースをリソースアカウントから１つずつ差し引く必要がある。この工程は、特に多数のユーザが各々のプリペイドリソースを利用する場合、多くの時間を要し、サーバの処理負荷を増大させる。これにより、プリペイドリソースを差し引く工程に、より多くの時間がかかり、ユーザによる効率的で円滑なサービスの取得に影響を及ぼす。

本願の実施は、サービスプロバイダのサーバによるユーザのプリペイドリソースの差し引きの効率が低いという従来技術における課題を解決するために、リソース処理方法を提供する。

本願の実施は、サービスプロバイダのサーバによるユーザのプリペイドリソースの差し引きの効率が低いという従来技術における課題を解決するために、リソース処理装置を提供する。

本願の実施では、以下の技術的解決策が用いられる。

本願の実施は、リソース処理方法を提供し、前記方法は：ユーザにより送信されるサービス要求を受信するステップと；前記サービス要求に対応するリソース消費量を特定するステップと；事前に作成された前記ユーザの総合リソースアカウントを特定するステップであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを含む、前記特定するステップと；前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するステップと；を含む。

本願の実施は、他のリソース処理方法を提供し、前記方法は：ユーザにより送信される支払い要求を受信するステップと；前記支払い要求に対応する支払い額を特定するステップと；事前に作成された前記ユーザの総合プリペイドカードアカウントを特定するステップであって、前記総合プリペイドカードアカウントは前記ユーザに属する全てのプリペイドカードファンドを含む、前記特定するステップと；前記総合プリペイドカードアカウントから、前記支払い額と一致するプリペイドカードファンドを差し引き、前記支払い要求を処理するステップと；を含む。

本願の実施は、リソース処理装置を提供し、前記装置は：ユーザにより送信されるサービス要求を受信するよう構成された受信モジュールと；前記サービス要求に対応するリソース消費量を特定するよう構成された特定モジュールと；事前に作成された前記ユーザの総合リソースアカウントを特定するよう構成された総合アカウントモジュールであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを含む、前記総合アカウントモジュールと；前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するよう構成された処理モジュールと；を含む。

本願の実施は、他のリソース処理装置を提供し、前記装置は：ユーザにより送信される支払い要求を受信するよう構成された受信モジュールと；前記支払い要求に対応する支払い額を特定するよう構成された特定モジュールと；事前に作成された前記ユーザの総合プリペイドカードアカウントを特定するよう構成された総合アカウントモジュールであって、前記総合プリペイドカードアカウントは前記ユーザに属する全てのプリペイドカードファンドを含む、前記総合アカウントモジュールと；前記総合プリペイドカードアカウントから前記支払い額と一致するプリペイドカードファンドを差し引き、前記支払い要求を処理するよう構成された処理モジュールと；を含む。

本願の実施で用いられる少なくとも１つの技術的解決策により、以下の有利な効果を奏することができる。

サービスプロバイダのサーバは、ユーザに対して作成された各リソースサブアカウントにおけるプリペイドリソースをカウントし、ユーザに対して総合リソースアカウントを作成し、カウントされたプリペイドリソースの総量を総合リソースアカウントに格納する。これにより、サーバは、ユーザのプリペイドリソースを取得する際、各リソースサブアカウントからプリペイドリソースを取得する代わりに、対応する量のプリペイドリソースを総合リソースアカウントから、直接、取得できる。この方法によれば、サーバがプリペイドリソースを取得する時間を効果的に短縮でき、サービス処理の効率を更に改善できる。

添付図面は、本願の更なる理解を提供するために用いられ、本願の一部を構成する。本願の例示的な実施及びその実施の説明は、本願を説明するために用いられており、本願に対する不適切な限定を構成するものではない。

図１ａは、本願の実施による、リソース処理アーキテクチャを示す概略図である。

図１ｂは、本願の実施による、リソース処理工程を示す概略図である。

図２ａは、本願の実施による、リソースアカウント作成を示す概略図１である。

図２ｂは、本願の実施による、リソースアカウント作成を示す概略図２である。

図２ｃは、本願の実施による、リソースアカウント作成を示す概略図３である。

図３は、本願の実施による、プリペイドリソースが用いられた後に得られるリソースアカウントを示す概略図である。

図４ａは、本願の実施による、変換係数が存在する場合のプリペイドリソースを示す概略図１である。

図４ｂは、本願の実施による、変換係数が存在する場合のプリペイドリソースを示す概略図２である。

図５ａは、本願の実施による、業者シナリオにおけるリソース処理アーキテクチャを示す概略図である。

図５ｂは、図５ａに示すアーキテクチャに基づくリソース処理手順を示す概略図である。

図６は、本願の実施による、サービス処理装置を示す概略構造図である。

図７は、本願の実施による、業者シナリオにおけるリソース処理装置を示す概略構造図である。

本願の目的、技術的解決策、及び利点をより明確にするために、以下は、本願の特定の実施及び対応する添付図面を参照して本願の技術的解決策を明確かつ包括的に説明する。明らかに、記載された実施は、本願の実施のすべてではなく一部である。創造的な努力なしに本願の実施に基づいて当業者によって得られる他のすべての実施は、本願の保護範囲内に入るものである。

上述のように、ユーザがプリペイドリソースを利用する際、サーバは、通常、ユーザに対応するプリペイメントアカウントから、対応するプリペイドリソースを１つずつ取得する。この工程には多くの時間がかかり、サービスプロバイダからユーザへのサービス提供の効率を下げる。

これに鑑み、ユーザがプリペイドリソースを利用する際には、迅速且つ便利にプリペイメントアカウントにおけるプリペイドリソースを取得する方法が求められる。本願の実施はリソース処理方法を提供し、この方法によれば、サーバはユーザのプリペイドリソースを迅速に取得でき、ユーザに対しサービスを提供する効率が改善される。

注記すると、本願の実施におけるサービスプロバイダは、ウェブサイトや電気通信事業者等の、オンラインサービスを提供できるサービスプロバイダであっても、店舗やレストラン等の、オフラインサービスを提供できるサービスプロバイダであってもよい（ただし、このシナリオにおいても、サービスプロバイダはオンラインのプリペイドリソースを提供する）。この場合、サービスプロバイダのサーバは、ウェブサイトのサーバ、電気通信事業者のサーバ、オンラインのプリペイドリソースを処理するように構成されたサーバ等であってよい。ただし、本願はそれらに限定されるものではない。

以下、添付図面を参照して、本願の実施によって提供される技術的解決策を詳細に説明する。

図１ａに示すように、図１ａは、本願の実施に係るリソース処理アーキテクチャを例示する概略図である。図１ａに示すアーキテクチャに基づき、図１ｂは本願の実施に係るリソース処理方法を示す。リソース処理方法は、具体的に、以下の各ステップを含む。

Ｓ１０１：ユーザにより送信されたサービス要求を受信する。

実際のアプリケーションシナリオにおいて、ユーザは、サービスプロバイダによって提供されるサービスを利用する必要がある場合、対応するサービス要求を送信できる。例えば、ユーザは、クラウドコンピューティングサービスを利用する場合には、クラウドコンピューティング要求を送信し、オンラインストレージサービスを利用する場合には、ストレージ要求を送信する。それに応じて、サービスプロバイダのサーバは、ユーザによって送信されたサービス要求を受信する。

当然ながら、本願のこの実施の或る任意の方法において、ユーザはエンドユーザデバイス（携帯電話、タブレット型コンピュータ、コンピュータ等であってよい）を用いてコードをスキャンする、対応するページ上のサービスコントロールをクリックする、などを行いサービス要求をサービスプロバイダへ送信できる。ただし、本願はそれに限定されるものではない。

Ｓ１０２：サービス要求に対応するリソース消費量を特定する。

上述のように、サービスプロバイダがユーザのサービス要求を処理する際、通常、特定の量のリソースが消費される。例えば、サービスプロバイダがユーザに対してクラウドコンピューティングサービスを提供する場合、対応する処理リソースが消費され、サービスプロバイダがネットワークストレージサービスを提供する場合、データベースにおけるストレージスペースが消費される。したがって、ユーザは、対応するリソースコストをサービスプロバイダに支払う必要がある。

この場合、サーバは、ユーザのサービス要求を受信した後、まず、サービス要求を処理するために必要なリソースの量（すなわち、サービス消費量）を特定し、続いてユーザが支払うべきリソースコストを特定する。

Ｓ１０３：事前に作成されたユーザの総合リソースアカウントを特定する。

総合リソースアカウントは、ユーザに属する全てのプリペイドリソースを含む。

本願のこの実施において、ユーザの総合リソースアカウントは、ユーザのリソースアカウントに基づき事前に作成される（総合リソースアカウントと区別するため、ユーザ機器がプリペイドリソースを取得する度に作成されるリソースアカウントを「リソースサブアカウント」と称する）。総合リソースアカウントに格納されたプリペイドリソースは、ユーザのリソースサブアカウントにおけるプリペイドリソースの合計であり、換言すれば、総合リソースアカウントにはユーザに属するプリペイドリソースの総量が含まれる。

例えば、ユーザがリソースアカウントＡ及びＢを有し、リソースサブアカウントＡにおけるプリペイドリソースの量が１００であり、リソースサブアカウントＢに含まれるプリペイドリソースの量が２００であると想定する。この場合、ユーザの総合リソースアカウントに含まれるプリペイドリソースの総量は３００である。

注記すると、本願のこの実施における総合リソースアカウントは、サーバによりユーザに対して作成される。本願のこの実施の方法において、サーバはユーザの識別子（例えば、ユーザがサーバに登録したユーザＩＤやサービスアカウント）を格納する。これにより、サーバは、ユーザの識別子に基づき、ユーザに対して総合リソースアカウントを作成できる。例えば、ユーザが「ｘｉａｏｍｉｎｇ」というアカウント名のサービスアカウントをサーバに登録した場合、サーバは、サービスアカウントのアカウント名に基づき、「ｘｉａｏｍｉｎｇ−総合リソースアカウント」という総合リソースアカウントをユーザに対して作成できる。サーバは、総合リソースアカウントを作成した後、ユーザの全てのプリペイドリソースを集め、これを総合リソースアカウントに格納する。

当然ながら、先の例は、総合リソースアカウントを作成する実践的な方法を説明しているに過ぎず、何ら本願に限定を課すものではない。

従来技術とは異なり、本願のこの実施においては、総合リソースアカウントはユーザに属する全てのプリペイドリソースを集めるためのアカウントであるため、各リソースサブアカウントからプリペイドリソースを差し引く必要はない。

Ｓ１０４：総合リソースアカウントから、リソース消費量に対応するプリペイドリソースを取得し、サービス要求を処理する。

サービス要求に対して消費されるリソースの量と、ユーザの総合リソースアカウントに含まれるプリペイドリソースの総量とが特定された後、対応する量のリソースを、ユーザの総合リソースアカウントから差し引くことができる。

なお、実際のアプリケーションシナリオにおいては様々なケースが発生し得る。

サービス要求に対して消費されるリソースの量が、総合リソースアカウントに含まれるプリペイドリソースの総量以下であるケースでは、サーバは、サービス要求に対して消費されるリソースの量を、総合リソースアカウントから差し引くことができる。例えば、サービス要求に対して消費されるリソースの量が８０であり、ユーザの総合リソースアカウントにおけるプリペイドリソースの総量が１００であると想定する。プリペイドリソースの量８０を、総合リソースアカウントから差し引くことができ、総合リソースアカウントにおけるプリペイドリソースの残量は２０となる。

サービス要求に対して消費されるリソースの量が、総合リソースアカウントに含まれるプリペイドリソースの総量よりも大きい、別のケースでは、それに応じて、サーバは、エンドユーザデバイスへ失敗通知をフィードバックし、ユーザに属するプリペイドリソースがサービス要求のリソース消費量を満たすのに不十分である旨をユーザに通知できる、又は、サーバは、総合リソースアカウントにおける全てのプリペイドリソースを差し引き、プリペイドリソースの不足分に対する差分補填通知をエンドユーザデバイスへフィードバックすることができる。後者の場合、ユーザは、別の方法でリソースの残量を支払うことができる。例えば、サービス要求に対して消費されるリソースの量が２００であり、ユーザの総合リソースアカウントにおけるプリペイドリソースの総量が１００であると想定する。先ず、ユーザの総合リソースアカウントにおけるプリペイドリソースの総量を差し引くことができる。この場合、サービス要求に対して消費することになるリソースの量は、１００が未払いのまま残る。したがって、ユーザは、残りのリソース消費量を補填するため、例えば、リソースを、直接、支払うことができる。ただし、本願はそれに限定されるものではない。

サービスプロバイダのサーバは、先の各ステップを用いてユーザの総合リソースアカウントを事前に作成する。総合リソースアカウントは、ユーザに属する全てのプリペイドリソースを集める。サーバは、ユーザのサービス要求を受信した後、サービス要求に対して消費されるリソースの量を特定する。これにより、サーバは、対応する量のプリペイドリソースを総合リソースアカウントから、直接、取得し、サービス要求に対して消費されるリソースを補填できる。従来技術では、プリペイドリソースはユーザの各リソースサブアカウントから差し引かれる。従来技術と比べると、本願のこの実施における方法では、対応する量のプリペイドリソースをユーザの総合リソースアカウントから、直接、取得でき、プリペイドリソースを取得する効率を効果的に改善できる。これにより、サーバが各リソースサブアカウントにおけるプリペイドリソースの量を計算することがなくなり、サーバの作業負荷が軽減される。

注記すると、前述の実施で提供される方法の各ステップを実行するのは同一デバイスであってよく、具体的には、サービスプロバイダのサーバであってよい。

総合リソースアカウントを作成する工程を詳細に以下説明する。

図２ａに示すように、図２ａは、本願の実施に係る、サーバが総合リソースアカウントを作成する工程を例示する概略図である。図２ａを参照すると、ユーザの総合リソースアカウントを事前に作成するステップは、事前に作成されたユーザの各リソースサブアカウントを特定するステップと、各リソースサブアカウントのプリペイドリソースの総リソース量をカウントするステップと、カウントされた総リソース量に基づき、ユーザに対して総合リソースアカウントを作成し、総リソース量に対応するプリペイドリソースを総合リソースアカウントに格納するステップとを含む。

各リソースサブアカウントは、ユーザにより毎回取得されるプリペイドリソースを格納する。

ユーザがサービスプロバイダからプリペイドリソースを取得した後（例えば、ユーザが購入した電子プリペイドカード及び電子バウチャ）、サーバは、ユーザに対して、対応するアカウントを作成し、取得されたプリペイドリソースを格納する。実際には、ユーザは、プリペイドリソースをサービスプロバイダから取得する際、ユーザの識別子を用いる（例えば、前述のユーザＩＤやサービスアカウント）。したがって、サーバは、ユーザがプリペイドリソースを取得する度にユーザの識別子を取得し、ユーザに属するリソースサブアカウントを作成できる。リソースサブアカウントを作成する工程は従来技術であり、本願のこの実施で詳細には説明はしない。

ユーザに属する各リソースサブアカウントは、ユーザが毎回取得するプリペイドリソースを格納する。したがって、リソースサブアカウントは、ユーザに属するプリペイドリソースの総量を特定するためにカウントされる。これに基づき、総合リソースアカウントがユーザに対して作成され、ユーザに属する全てのプリペイドリソースが総合リソースアカウントに集められて、格納される。

本願のこの実施の方法において、ユーザの総合リソースアカウントは、サーバがユーザに対して最初のリソースサブアカウントを作成する際に作成されることができる。図２ｂに示すように、サーバは、ユーザに対して作成された最初のリソースサブアカウント（図２ｂにおけるリソースサブアカウント１）を監視する。サーバは、リソースサブアカウントが作成されたことを検出した場合、リソースサブアカウントにおけるプリペイドリソースの量をカウントし、カウントしたプリペイドリソースの量を現在の総リソース量として用い、ユーザに対して総合リソースアカウントを作成し、プリペイドリソースの量に対応するプリペイドリソースを総合リソースアカウントに格納する。図２ｂからは、総合リソースアカウントにおけるリソースの総量が、リソースサブアカウント１に含まれるリソースの量であることが分かる。換言すれば、リソースの総量は１００である。

換言すれば、サーバは、ユーザに対して初めてリソースサブアカウントを作成する際に、ユーザに対して総合リソースアカウントを作成する。その後、ユーザが対応する量の新たなプリペイドリソースを取得した場合、サーバはユーザに対して新たなリソースサブアカウントを作成する。一方、総合リソースアカウントにおけるプリペイドリソースの量は変化する。具体的には、サーバは、リアルタイムに、新たなリソースサブアカウントにおけるプリペイドリソースを総合リソースアカウントに付加し、総合リソースアカウントにおける総リソース量は、対応する量のプリペイドリソース分だけ増加する。

例えば、図２ｃに示すように、ユーザは新たなプリペイドリソースを取得し（プリペイドリソースの量は５０であると想定する）、その上で、サーバはユーザに対して、新たなリソースサブアカウントである、リソースサブアカウント２を作成する（リソースサブアカウント２に格納されたプリペイドリソースの量は５０である）。この場合、サーバは、リソースサブアカウント２におけるプリペイドリソースの量を総合リソースアカウントに付加する。したがって、図２ｃにおいては、総合リソースアカウントにおける総リソース量が１５０に変わる。

総合リソースアカウントの作成により、ユーザによって取得された全てのプリペイドリソースが組み合わされる。サーバは、ユーザのプリペイドリソースを取得する際、各リソースサブアカウントからプリペイドリソースを取得するのではなく、総合リソースアカウントを用いてプリペイドリソースを、直接、取得できることが理解されよう。従来技術における方法と比べると、本願のこの実施における総合リソースアカウントを用いる方法は、サーバがユーザのプリペイドリソースを取得する時間を効果的に減らすことができる。

実際には、サービスプロバイダにより提供されるプリペイドリソースは異なる変換係数を持つことができる。具体的には、異なる変換係数を有する同一の量のプリペイドリソースは、異なる量のリソースコストを相殺できる。例えば、変換係数が１である場合、ユーザは１００のプリペイドリソースを用いて同一の量（すなわち、１００）のリソースコストを相殺できる。換言すれば、変換係数が１であり、ユーザにより送信されるサービス要求に対するリソース消費量が１００である場合、サーバは、ユーザに属する１００のプリペイドリソースを取得する。

一方、変換係数が２である場合、ユーザは１００のプリペイドリソースを用いて２００のリソースコストを相殺できる。換言すれば、変換係数が２で、ユーザにより送信されたサービス要求に対するリソース消費量が１００である場合、サーバはユーザに属する５０のプリペイドリソースを取得する。

この点に鑑み、サーバは、リソースサブアカウントにおけるリソースの総量をカウントする際、各リソースサブアカウントの変換係数に基づいてカウントをする必要がある。各リソースサブアカウントのプリペイドリソースの総リソース量をカウントするステップは、各リソースサブアカウントにおけるプリペイドリソースの変換係数を特定するステップと、各リソースサブアカウントの特定した変換係数に基づき各リソースサブアカウントのプリペイドリソースの総リソース量をカウントするステップとを含む。

本願のこの実施において、総合リソースアカウントにおけるプリペイドリソースの量は、各リソースサブアカウントにおけるプリペイドリソースの変換した量の合計である。

ユーザがサービス要求を送信した後、サーバは、サービス要求に対応するリソース消費量に基づき、同じ量のプリペイドリソースを総合リソースアカウントから取得できる。

注記すると、リソースサブアカウントにおけるプリペイドリソースの量は、総合リソースアカウントにおけるプリペイドリソースの総量とリアルタイムで対応する。換言すれば、リソースサブアカウントにおけるプリペイドリソースの量が変化すれば、それに応じて総合リソースアカウントにおけるプリペイドリソースの量も変化する。同様に、総合リソースアカウントにおけるプリペイドリソースの総量が変化すれば、それに応じて、サーバはリソースサブアカウントにおけるプリペイドリソースの量を調整する。したがって、サーバは、特定の量のプリペイドリソースを総合リソースアカウントから取得した後、同じ量のプリペイドリソースをリソースサブアカウントから差し引く。

本願のこの実施において、図１ａ及び図１ｂに示す方法は、ユーザの総合リソースアカウントから取得したプリペイドリソースの量に基づき、対応する量のプリペイドリソースを、ユーザに対応する各リソースサブアカウントから差し引くステップを更に含む。

本願のこの実施において、プリペイドリソースは、複数の方法を用いて各リソースサブアカウントから差し引くことができる。例えば、実際には、ユーザはプリペイドリソースを複数回取得でき、サーバは、ユーザがプリペイドリソースを取得する度にリソースサブアカウントを作成する。したがって、ユーザのリソースサブアカウント間には時系列的な順番があり、よって、プリペイドリソースは、リソースサブアカウントの作成時間の時系列に基づいて差し引くことができる。

例えば、図２ｃに示すケースでは、リソースサブアカウント１が、リソースサブアカウント２よりも早くに作成される。サーバがユーザの総合リソースアカウントから１２０のプリペイドリソースを取得する際、同量のプリペイドリソースを、リソースサブアカウント１及びリソースサブアカウント２から差し引く必要がある。リソースサブアカウント１の方が早い時間に作成されるので、サーバは、リソースサブアカウントの作成時間の時系列に基づき、先ずリソースサブアカウント１からプリペイドリソースを差し引く。図３に示すように、リソースサブアカウント１には現状ではプリペイドリソースがないが、２０のプリペイドリソースが更に差し引かれる必要がある。したがって、サーバは、リソースサブアカウント２から、２０のプリペイドリソースを差し引く。図３において、リソースサブアカウント２には３０のプリペイドリソースが残っている。

別の例では、異なるリソースサブアカウントが異なる変換係数を持つことができ、各リソースサブアカウントにおけるプリペイドリソースは、一連の変換係数に基づき差し引かれることができる。

図４ａに示すように、リソースサブアカウント１におけるプリペイドリソースの量が１００であり、変換係数が２であり；リソースサブアカウント２におけるプリペイドリソースの量が３０であり、変換係数が１である、と想定する。この場合、総合リソースアカウントにおけるリソースの総量は、１００*２＋３０＝２３０となる。図４ｂに示すように、ユーザが利用するサービスが１００のリソースを消費する必要がある場合、サーバは、総合リソースアカウントから１００のリソースを、直接、取得し（現状では、総合リソースアカウントに１３０のリソースが残る）、その上で、変換係数の優先度に基づき、リソースサブアカウント１から、５０のプリペイドリソースを差し引く。

したがって、前述の内容において、対応する量のプリペイドリソースを、ユーザに対応する各リソースサブアカウントから差し引くステップは、リソースサブアカウントとユーザとの間の関連付けを確立する時系列に基づき、対応する量のプリペイドリソースを各リソースサブアカウントから差し引くステップ；又は、各リソースサブアカウントにおけるプリペイドリソースの変換係数に基づきリソースサブアカウントの優先順位を特定し、リソースサブアカウントの特定された優先順位に基づき、対応する量のプリペイドリソースを、各リソースサブアカウントから差し引くステップを含む。

当然ながら、実際には、リソースサブアカウントにおけるプリペイドリソースは、代わりに、ユーザが設定したリソースサブアカウントの順序に基づいて差し引かれることができる。或いは、一部のリソースサブアカウントが有効期限を持つ場合、プリペイドリソースは有効期限に基づいて差し引かれることができる。ただし、本願はそれに限定されるものではない。

注記すると、本願のこの実施において、プリペイドリソースは、サービスプロバイダがサービスを提供した後に、リソースサブアカウントから差し引かれる。換言すれば、サービスプロバイダは、サーバが総合リソースアカウントからプリペイドリソースを取得した後で、対応するサービスをユーザに提供し、ユーザが適時にサービスを取得できることを保証する。これに基づき、その後、サーバはリソースサブアカウントからプリペイドリソースを差し引く。この方法を用いて、ユーザは適時にサービスを得ることができる。

本願における先の方法は、実際のアプリケーションシナリオにおいて、プリペイドカードのシナリオに適用できる。実際のアプリケーションシナリオにおけるアーキテクチャを図５ａに示す。実際のシナリオは、ユーザと、業者と、決済サービスプロバイダとを含む。ユーザは、対応するサービスを業者から得る（例えば、業者は、商品、飲食、宿泊等のサービスをユーザに提供できる）。業者は電子プリペイドカード（あるいは電子バウチャ等；以下、記載を簡略化して「プリペイドカード」と称する）をユーザに提供できる。決済サービスプロバイダは、業者により提供されたプリペイドカードに対するオンラインの支払いを技術的にサポートする。また、ユーザは、ユーザアカウントを、支払いサービスプロバイダに登録する。実際には、ユーザは、プリペイドカードを用いて対応する商品を業者から購入できる。ここでのプリペイドカードは、プリペイドリソースとみなしてよい。異なるプリペイドカードは異なる額及び異なる変換係数を有する。ユーザは複数のプリペイドカードを購入できる。このシナリオでは、図５ｂに示すように、本願の実施はリソース処理方法を提供する。

図５ｂにおける方法は以下の各ステップを含む。

Ｓ５０１：ユーザにより送信される支払い要求を受信する。

ユーザは、業者が提供する、商品、飲食、宿泊等のサービスを受けた後、対応する額を支払う必要がある。本願のこの実施の方法において、ユーザは、ユーザのエンドユーザデバイスを用いて支払い要求を送信できる。業者は、対応するＱＲコード（登録商標）をユーザに対して提供でき、ユーザは、エンドユーザデバイスを用いてコードをスキャンした後、支払い要求を送信する。本願のこの実施の別の方法では、支払い要求を業者が送信することもできる。業者は、業者の決済デバイス（例えば、ＰＯＳ装置やエンドユーザデバイス）を用いてサービス要求をサーバへ送信できる。

当然ながら、ユーザによって送信されるサービス要求も、業者によって送信されるサービス要求も、双方ともユーザの識別子（例えば、ユーザが支払いサービスプロバイダに登録したアカウント、電話番号、又はユーザＩＤ）と業者の識別子（例えば、業者名や業者ＩＤ）とを含む。

Ｓ５０２：支払い要求に対応する支払い額を特定する。

支払い要求は支払い額に関する対応情報を含んでいるので、サーバは、支払い額に関する情報に基づき、支払い要求に対して支払われる額を特定できる。

Ｓ５０３：事前に作成されたユーザの総合プリペイドカードアカウントを特定する。

総合プリペイドカードアカウントは、ユーザに属する全てのプリペイドカードファンドを含む。

注記すると、この実際のアプリケーションシナリオでは、業者がプリペイドカードを提供する。この点に鑑み、サーバは、業者の識別子とユーザの識別子とに基づき、ユーザに対してプリペイドカードアカウント（プリペイドカードサブアカウントと総合プリペイドカードアカウントとを含む）を作成する。

換言すれば、サーバは、サービス要求に含まれるユーザの識別子と業者の識別子とに基づき、業者に対応するプリペイドカードアカウントを特定し、ユーザの識別子に基づき、ユーザに属するプリペイドカードアカウントを特定する。

Ｓ５０４：総合プリペイドカードアカウントから支払い額と一致するプリペイドカードファンドを差し引き、支払い要求を処理する。

サーバは、ユーザの総合プリペイドカードアカウントから、対応するプリペイドカードファンドを差し引いた後、差し引きの成功を業者に通知し、業者はユーザの支払いトランザクションを完了する。また、サーバは、ユーザのプリペイドカードアカウントからのファンドの差し引きに成功した旨をユーザに通知し、対応する差し引きの詳細を提示する。ただし、当然ながら、本願はこれに限定されるものではない。

当然ながら、このシナリオにおけるリソース処理方法は、総合プリペイドカードアカウントを作成する工程と、各プリペイドカードサブアカウントにおけるプリペイドカードファンドに基づき、プリペイドカードファンドの総額をカウントする工程と、プリペイドカードリソースを差し引く工程とを更に含む。

このシナリオにおいて、ユーザの総合プリペイドカードアカウントを事前に作成するステップは、（ユーザにより毎回購入されるプリペイドカードファンドを格納する、）事前に作成されたユーザの各プリペイドカードサブアカウントを特定するステップと、各プリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントするステップと、カウントした総額に基づきユーザに対して総合プリペイドカードアカウントを作成し、総額と一致するプリペイドカードファンドを総合プリペイドカードアカウントに格納するステップとを含む。

上で述べたように、ユーザが業者のプリペイドカードを購入した後、サーバは、ユーザの識別子と業者の識別子とに基づき、ユーザに対してプリペイドカードサブアカウントを作成する。プリペイドカードサブアカウントは、プリペイドリソースが業者により提供されることを示すことができ、プリペイドカードサブアカウントはユーザに属する。

この工程において、プリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントするステップは、各プリペイドカードサブアカウントにおけるプリペイドカードファンドの変換係数を特定するステップと、各プリペイドカードサブアカウントの特定された変換係数に基づきプリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントするステップとを含む。

プリペイドカードファンドを差し引く工程において、この方法は、ユーザの総合プリペイドカードアカウントから差し引かれたプリペイドカードファンドに基づき、対応する量のプリペイドカードファンドを、ユーザに対応する各プリペイドカードサブアカウントから差し引くステップを更に含む。

注記すると、対応する量のプリペイドカードファンドをユーザに対応する各プリペイドカードサブアカウントから差し引くステップは、プリペイドカードサブアカウントとユーザとの間の関連付けを確立する時系列に基づき、対応する量のプリペイドカードファンドを各プリペイドカードサブアカウントから差し引くステップ；又は、各プリペイドカードサブアカウントにおけるプリペイドリソースの変換係数に基づきプリペイドカードサブアカウントの優先順位を特定し、プリペイドカードサブアカウントの特定された優先順位に基づき、対応する量のプリペイドカードファンドを各プリペイドカードサブアカウントから差し引くステップ；を含む。

先の内容は、図１ｂに示す方法で説明した内容に類似する。簡略化のため、ここでは詳細を省略する。

以上、本願の実施において提供されるリソース処理方法を説明した。同じ思想に基づき、本願の実施はリソース処理装置を更に提供する。

図６に示すように、この装置は、ユーザにより送信されたサービス要求を受信するよう構成された受信モジュール６０１と、サービス要求に対応するリソース消費量を特定するよう構成された特定モジュール６０２と、ユーザに属する全てのプリペイドリソースを含む、事前に作成されたユーザの総合リソースアカウントを特定するよう構成された総合アカウントモジュール６０３と、総合リソースアカウントから、リソース消費量に対応するプリペイドリソースを取得し、サービス要求を処理するよう構成された処理モジュール６０４とを含む。

総合アカウントモジュール６０３は、ユーザにより毎回取得されるプリペイドリソースを格納する、事前に作成されたユーザの各リソースサブアカウントを特定し、リソースサブアカウントのプリペイドリソースの総リソース量をカウントし、カウントされた総リソース量に基づきユーザに対して総合リソースアカウントを作成し、総リソース量に対応するプリペイドリソースを総合リソースアカウントに格納する。

また、総合アカウントモジュール６０３は、各リソースサブアカウントにおけるプリペイドリソースの変換係数を特定し、各リソースサブアカウントの特定された変換係数に基づきリソースサブアカウントのプリペイドリソースの総リソース量をカウントする。

この装置は、ユーザの総合リソースアカウントから取得されたプリペイドリソースの量に基づき、対応する量のプリペイドリソースを、ユーザに対応する各リソースサブアカウントから差し引くよう構成されたリソース決済モジュール６０５を更に含む。

リソース決済モジュール６０５は、リソースサブアカウントとユーザとの間の関連付けを確立する時系列に基づき、対応する量のプリペイドリソースを、各リソースサブアカウントから差し引く；又は、各リソースサブアカウントにおけるプリペイドリソースの変換係数に基づきリソースサブアカウントの優先順位を特定し、リソースサブアカウントの特定された優先順位に基づき、対応する量のプリペイドリソースを各リソースサブアカウントから差し引く。

ユーザがプリペイドカードを利用するシナリオにおいて、図６に示す装置に基づく装置を適用できる。具体的には、図７に示すように、本願の実施は、このシナリオにおけるリソース処理装置を提供する。この装置は、ユーザにより送信された支払い要求を受信するよう構成された受信モジュール７０１と、支払い要求に対応する支払い額を特定するよう構成された特定モジュール７０２と、ユーザに属する全てのプリペイドカードファンドを含む、事前に作成されたユーザの総合プリペイドカードアカウントを特定するよう構成された総合アカウントモジュール７０３と、総合プリペイドカードアカウントから支払い額と一致するプリペイドカードファンドを差し引き、支払い要求を処理するよう構成された処理モジュール７０４とを含む。

総合アカウントモジュール７０３は、ユーザにより毎回購入されるプリペイドカードファンドを格納する、事前に作成されたユーザの各プリペイドカードサブアカウントを特定し、プリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントし、カウントされた総額に基づきユーザに対して総合プリペイドカードアカウントを作成し、総額と一致するプリペイドカードファンドを総合プリペイドカードアカウントに格納する。

また、総合アカウントモジュール７０３は、各プリペイドカードサブアカウントにおけるプリペイドカードファンドの変換係数を特定し、各プリペイドカードサブアカウントの特定された変換係数に基づきプリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントする。

この装置は、ユーザの総合プリペイドカードアカウントから差し引かれたプリペイドカードファンドに基づき、対応する量のプリペイドカードファンドを、ユーザに対応する各プリペイドカードサブアカウントから差し引くよう構成されたリソース決済モジュール７０５を更に含む。

当業者は、本開示の実施が方法、システム、又はコンピュータプログラム製品として提供され得ることを理解するはずである。したがって、本開示は、ハードウェアのみの実施、ソフトウェアのみの実施、又はソフトウェアとハードウェアの組み合わせを用いた実施の形態をとることができる。更に、本開示は、コンピュータで使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能記憶媒体（磁気ディスク記憶装置、ＣＤ−ＲＯＭ、光メモリなどを含むがこれらに限定されない）に実装されるコンピュータプログラム製品の形態をとることができる。

本開示は、本開示の実施による方法、デバイス（システム）、及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。フローチャート及び／又はブロック図内の各プロセス及び／又は各ブロック、ならびにフローチャート及び／又はブロック図内のプロセス及び／又はブロックの組み合わせを実施するためにコンピュータプログラム命令を使用することができることに留意することは価値がある。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラム可能データ処理デバイスのプロセッサに提供されてマシンを生成することができ、その結果、コンピュータ又は他のプログラム可能データ処理デバイスのプロセッサによって実行される命令は、フローチャート中の１つ以上のプロセス及び／又はブロック図中の１つ以上のブロックにおける特定の機能を実施するための装置を生成する。

これらのコンピュータプログラム命令は、特定の方法で動作するようにコンピュータ又は別のプログラム可能データ処理デバイスに命令することができるコンピュータ可読メモリに格納することができ、その結果、コンピュータ可読メモリに格納された命令は命令装置を含むアーチファクトを生成する。命令装置は、フローチャート内の１つ又は複数のプロセス及び／又はブロック図内の１つ又は複数のブロックにおける特定の機能を実施する。

これらのコンピュータプログラム命令は、コンピュータ又は他のプログラム可能データ処理デバイスにロードすることができ、その結果、コンピュータ又は他のプログラム可能デバイス上で一連の動作及びステップが実行され、それによってコンピュータ実装処理が生成される。したがって、コンピュータ又は他のプログラム可能デバイス上で実行される命令は、フローチャート中の１つ以上のプロセス及び／又はブロック図中の１つ以上のブロックにおける特定の機能を実施するためのステップを提供する。

典型的な構成では、コンピューティングデバイスは、１つ又は複数のプロセッサ（ＣＰＵ）、入力／出力インタフェース、ネットワークインタフェース、及びメモリを含む。

メモリは、非永続的記憶装置、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ、及び／又は、例えば読み取り専用メモリ（ＲＯＭ）又はフラッシュメモリ（flush RAM）といった、コンピュータ可読媒体の他の形態を含むことができる。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法又は技術を用いることによって情報記憶を実施することができる持続的、非持続的、移動可能、及び移動不能の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータとすることができる。コンピュータ記憶媒体は、相変化ランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、又は他のメモリ技術、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、又は他の光学記憶装置、カセット、カセット磁気ディスク記憶装置、他の磁気記憶デバイス、又は他の任意の非伝送媒体を含むが、これらに限定されない。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスすることができる情報を記憶するように構成することができる。本明細書の定義に基づき、コンピュータ可読媒体は、コンピュータ可読一時的媒体、例えば変調データ信号及び搬送波を含まない。

用語「含む」「備える」又はそれらの他の任意の変形は、非排他的な包含を網羅することを意図しており、そのため、一連の要素を含むプロセス、方法、物品、又はデバイスはこれらの要素のみを含むだけでなく、明示的に列挙されていない他の要素も含む、又はそのようなプロセス、方法、物品、又はデバイスに固有の要素を更に含む、ということは注記に値する。「〜を含む」が付いた要素は、それ以上の制約がない限り、その要素を含むプロセス、方法、物品、又はデバイスにおける追加の同一の要素の存在を排除するものではない。

当業者は、本願の実施が方法、システム、又はコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、又はソフトウェアとハードウェアとの組み合わせを用いた実施の形態をとることができる。更に、本願は、コンピュータで使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能記憶媒体（磁気ディスク記憶装置、ＣＤ−ＲＯＭ、光メモリなどを含むがこれらに限定されない）上で実施されるコンピュータプログラム製品の形態をとることができる。

前述の説明は、本願の単なる実施であり、本願を限定することを意図するものではない。当業者にとって、本願は様々な修正及び変更を加えることができる。本願の精神及び原理内においてなされた任意の修正、均等物の置換、改良などは、本願の特許請求の範囲の範囲内に含まれるものである。
［第１の局面］
ユーザにより送信されるサービス要求を受信するステップと；
前記サービス要求に対応するリソース消費量を特定するステップと；
事前に作成された前記ユーザの総合リソースアカウントを特定するステップであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを備える、前記特定するステップと；
前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するステップと；を備える、
リソース処理方法。
［第２の局面］
前記ユーザの前記総合リソースアカウントを事前に作成するステップは：
事前に作成された前記ユーザの各リソースサブアカウントを特定するステップであって、前記各リソースサブアカウントは前記ユーザにより毎回取得されるプリペイドリソースを格納する、前記特定するステップと；
前記リソースサブアカウントのプリペイドリソースの総リソース量をカウントするステップと；
カウントされた前記総リソース量に基づき前記ユーザに対して前記総合リソースアカウントを作成し、前記総リソース量に対応する前記プリペイドリソースを前記総合リソースアカウントに格納するステップと；を備える、
第１の局面に記載のリソース処理方法。
［第３の局面］
前記リソースサブアカウントのプリペイドリソースの総リソース量をカウントする前記ステップは：
各リソースサブアカウントにおけるプリペイドリソースの変換係数を特定するステップと；
各リソースサブアカウントの特定された前記変換係数に基づき、前記リソースサブアカウントの前記プリペイドリソースの前記総リソース量をカウントするステップと；を備える、
第２の局面に記載のリソース処理方法。
［第４の局面］
前記ユーザの前記総合リソースアカウントから取得された前記プリペイドリソースの量に基づき、対応する量のプリペイドリソースを、前記ユーザに対応する各リソースサブアカウントから差し引くステップを更に備える、
第１の局面に記載のリソース処理方法。
［第５の局面］
対応する量のプリペイドリソースを、前記ユーザに対応する各リソースサブアカウントから差し引く前記ステップは：
前記リソースサブアカウントと前記ユーザとの間の関連付けを確立する時系列に基づき、対応する前記量の前記プリペイドリソースを、各リソースサブアカウントから差し引くステップ；又は、
各リソースサブアカウントにおける前記プリペイドリソースの前記変換係数に基づき、前記リソースサブアカウントの優先順位を特定し、前記リソースサブアカウントの特定された前記優先順位に基づき、対応する前記量の前記プリペイドリソースを、各リソースサブアカウントから差し引くステップ；を備える、
第４の局面に記載のリソース処理方法。
［第６の局面］
ユーザにより送信される支払い要求を受信するステップと；
前記支払い要求に対応する支払い額を特定するステップと；
事前に作成された前記ユーザの総合プリペイドカードアカウントを特定するステップであって、前記総合プリペイドカードアカウントは前記ユーザに属する全てのプリペイドカードファンドを備える、前記特定するステップと；
前記総合プリペイドカードアカウントから、前記支払い額と一致するプリペイドカードファンドを差し引き、前記支払い要求を処理するステップと；を備える、
リソース処理方法。
［第７の局面］
前記ユーザの前記総合プリペイドカードアカウントを事前に作成するステップは：
事前に作成された前記ユーザの各プリペイドカードサブアカウントを特定するステップであって、前記各プリペイドカードサブアカウントは前記ユーザにより毎回購入されるプリペイドカードファンドを格納する、前記特定するステップと；
前記プリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントするステップと；
カウントされた前記総額に基づき前記ユーザに対して前記総合プリペイドカードアカウントを作成し、前記総額と一致するプリペイドカードファンドを前記総合プリペイドカードアカウントに格納するステップと；を備える、
第６の局面に記載のリソース処理方法。
［第８の局面］
前記プリペイドカードサブアカウントのプリペイドカードファンドの総額をカウントする前記ステップは：
各プリペイドカードサブアカウントにおけるプリペイドカードファンドの変換係数を特定するステップと；
各プリペイドカードサブアカウントの特定された前記変換係数に基づき、前記プリペイドカードサブアカウントの前記プリペイドカードファンドの前記総額をカウントするステップと；を備える、
第７の局面に記載のリソース処理方法。
［第９の局面］
前記ユーザの前記総合プリペイドカードアカウントから差し引かれた前記プリペイドカードファンドに基づき、対応する量のプリペイドカードファンドを、前記ユーザに対応する各プリペイドカードサブアカウントから差し引くステップを更に備える、
第６の局面に記載のリソース処理方法。
［第１０の局面］
対応する量のプリペイドカードファンドを、前記ユーザに対応する各プリペイドカードサブアカウントから差し引く前記ステップは：
前記プリペイドカードサブアカウントと前記ユーザとの間の関連付けを確立する時系列に基づき、対応する前記量の前記プリペイドカードファンドを、各プリペイドカードサブアカウントから差し引くステップ；又は、
各プリペイドカードサブアカウントにおける前記プリペイドリソースの前記変換係数に基づき、前記プリペイドカードサブアカウントの優先順位を特定し、前記プリペイドカードサブアカウントの特定された前記優先順位に基づき、対応する前記量の前記プリペイドカードファンドを、各プリペイドカードサブアカウントから差し引くステップ；を備える、
第９の局面に記載のリソース処理方法。
［第１１の局面］
ユーザにより送信されるサービス要求を受信するよう構成された受信モジュールと；
前記サービス要求に対応するリソース消費量を特定するよう構成された特定モジュールと；
事前に作成された前記ユーザの総合リソースアカウントを特定するよう構成された総合アカウントモジュールであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを備える、前記総合アカウントモジュールと；
前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するよう構成された処理モジュールと；を備える、
リソース処理装置。
［第１２の局面］
ユーザにより送信される支払い要求を受信するよう構成された受信モジュールと；
前記支払い要求に対応する支払い額を特定するよう構成された特定モジュールと；
事前に作成された前記ユーザの総合プリペイドカードアカウントを特定するよう構成された総合アカウントモジュールであって、前記総合プリペイドカードアカウントは前記ユーザに属する全てのプリペイドカードファンドを備える、前記総合アカウントモジュールと；
前記総合プリペイドカードアカウントから、前記支払い額と一致するプリペイドカードファンドを差し引き、前記支払い要求を処理するよう構成された処理モジュールと；を備える、
リソース処理装置。

Claims (9)

1. サーバにより実行されるリソース処理方法であって、
   ユーザにより送信されるサービス要求を受信するステップ（Ｓ１０１）と；
   前記サービス要求に対応するリソース消費量を特定するステップ（Ｓ１０２）と；
   事前に作成された前記ユーザの総合リソースアカウントを特定するステップであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを備える、前記特定するステップ（Ｓ１０３）と；
   前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するステップ（Ｓ１０４）と；を備え、
   前記ユーザの前記総合リソースアカウントを事前に作成するステップは：
   事前に作成された前記ユーザの各リソースサブアカウントを特定するステップであって、前記各リソースサブアカウントは前記ユーザにより毎回取得されるプリペイドリソースを格納する、前記特定するステップと；
   前記リソースサブアカウントのプリペイドリソースの総リソース量をカウントするステップと；
   カウントされた前記総リソース量に基づき前記ユーザに対して前記総合リソースアカウントを作成し、前記総リソース量に対応する前記プリペイドリソースを前記総合リソースアカウントに格納するステップと；を備える、
   リソース処理方法。
2. 前記リソースサブアカウントのプリペイドリソースの総リソース量をカウントする前記ステップは：
   各リソースサブアカウントにおけるプリペイドリソースの変換係数を特定するステップと；
   各リソースサブアカウントの特定された前記変換係数に基づき、前記リソースサブアカウントの前記プリペイドリソースの前記総リソース量をカウントするステップと；を備える、
   請求項１に記載のリソース処理方法。
3. サーバにより実行されるリソース処理方法であって、
   ユーザにより送信されるサービス要求を受信するステップ（Ｓ１０１）と；
   前記サービス要求に対応するリソース消費量を特定するステップ（Ｓ１０２）と；
   事前に作成された前記ユーザの総合リソースアカウントを特定するステップであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを備える、前記特定するステップ（Ｓ１０３）と；
   前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するステップ（Ｓ１０４）と；を備え、
   前記ユーザの前記総合リソースアカウントから取得された前記プリペイドリソースの量に基づき、対応する量のプリペイドリソースを、前記ユーザに対応する各リソースサブアカウントから差し引くステップを更に備え、
   対応する量のプリペイドリソースを、前記ユーザに対応する各リソースサブアカウントから差し引く前記ステップは：
   前記リソースサブアカウントと前記ユーザとの間の関連付けを確立する時系列に基づき、対応する前記量の前記プリペイドリソースを、各リソースサブアカウントから差し引くステップ；又は、
   各リソースサブアカウントにおけるプリペイドリソースの変換係数に基づき、前記リソースサブアカウントの優先順位を特定し、前記リソースサブアカウントの特定された前記優先順位に基づき、対応する前記量の前記プリペイドリソースを、各リソースサブアカウントから差し引くステップ；を備える、
   リソース処理方法。
4. 事前に作成された前記ユーザの前記総合リソースアカウントに含まれる総合プリペイドカードアカウントから、支払い額と一致するプリペイドカードファンドを差し引き、支払い要求を処理するステップを更に備える、
   請求項１〜請求項３のいずれか１項に記載のリソース処理方法。
5. 前記サービス要求は、クラウドコンピューティング要求、又は、オンラインストレージ要求を備える、
   請求項１〜請求項４のいずれか１項に記載のリソース処理方法。
6. 前記リソース消費量は、消費された処理リソース、又は、データベースにおける使用されたストレージスペースを備える、
   請求項５に記載のリソース処理方法。
7. 事前に作成された前記ユーザの前記総合リソースアカウントは、前記ユーザのためにサーバにより作成される、
   請求項１〜請求項６のいずれか１項に記載のリソース処理方法。
8. 前記ユーザに属する前記プリペイドリソースは、前記サービス要求の前記リソース消費量を満たすのに不十分である旨を前記ユーザに通知するための、エンドユーザデバイスへの失敗通知を生成するステップを更に備える、
   請求項１〜請求項７のいずれか１項に記載のリソース処理方法。
9. リソース処理装置であって、
   ユーザにより送信されるサービス要求を受信するよう構成された受信モジュールと；
   前記サービス要求に対応するリソース消費量を特定するよう構成された特定モジュールと；
   事前に作成された前記ユーザの総合リソースアカウントを特定するよう構成された総合アカウントモジュールであって、前記総合リソースアカウントは前記ユーザに属する全てのプリペイドリソースを備える、前記総合アカウントモジュールと；
   前記総合リソースアカウントから、前記リソース消費量に対応するプリペイドリソースを取得し、前記サービス要求を処理するよう構成された処理モジュールと
   ；を備え、
   前記総合アカウントモジュールが：
   事前に作成された前記ユーザの各リソースサブアカウントを特定することであって、前記各リソースサブアカウントは前記ユーザにより毎回取得されるプリペイドリソースを格納する、前記各リソースサブアカウントを特定することと；
   前記リソースサブアカウントのプリペイドリソースの総リソース量をカウントすることと；
   カウントされた前記総リソース量に基づき前記ユーザに対して前記総合リソースアカウントを作成し、前記総リソース量に対応する前記プリペイドリソースを前記総合リソースアカウントに格納することと；を行うよう構成される、
   リソース処理装置。

Images