JP6006755B2 - 決済システム、決済制御方法、決済制御用のコンピュータプログラム及び決済装置 - Google Patents

Description

本発明は、ユーザへの課金に対応して決済処理を行う決済システム等に関する。

ユーザへの課金に対応した決済を実現するシステムとして、現実の通貨を利用することなく、電子的な情報として記録された金銭的価値を消費させることにより決済処理を行う決済システムが広く普及している。例えば、ゲーム機の分野でも、ゲームのプレイ料金等をサーバ側に保持された仮想通貨の口座からの残高引き落としによって支払うようにしたシステムが知られている（例えば特許文献１参照）。

特開２０１０−２６２３８９号公報

ゲーム機では、二人又はそれ以上のユーザが共同してゲームをプレイするといったように、ゲーム機にて提供される無形の商品としてのプログラムやデータを複数のユーザが一緒に利用することを希望する場合がある。この場合、複数のユーザへのそれぞれの課金を単位として仮想通貨による決済処理を行うと、一部の課金に対応する決済処理に成功しても、他の課金に対応する決済処理が残高不足、通信エラーといった理由で失敗するといったように、決済処理間で相反する結果が生じるおそれがある。その場合、決済処理が成功した部分に限ってプログラムやデータを利用させるといったイレギュラーな制御が必要となり、ユーザが意図しない結果がもたらされる不都合が生じ得る。この種の問題はゲーム機に限ったものではなく、決済処理の結果が同一に定まるべき複数の課金が発生しても、課金毎に決済処理がなされる場合には例外なく発生し得る問題である。

そこで、本発明は決済処理の結果が同一に定まるべき複数の課金が発生した場合、それらの課金に対応する決済処理間にて処理結果が相反するおそれがなく、一部の決済が失敗した場合に生じる不都合を未然に防止することができる決済システム等を提供することを目的とする。

本発明の一態様に係る決済システムは、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えた決済システムにおいて、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられたものである。

本発明の一態様に係る決済制御方法は、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えたコンピュータシステムに適用される決済制御方法において、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手順と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手順とを実行させ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手順と、前記決済試行手順により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手順で試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手順とを実行させるものである。

本発明の一態様に係る決済制御用のコンピュータプログラムは、所定のコンピュータシステムに含まれた少なくとも一のコンピュータ装置を、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段、及び、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段として機能させる決済制御用のコンピュータプログラムであって、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられるように構成されたものである。

本発明の一態様に係る決済装置は、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えた決済システムにおいて、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられたものである。

本発明の一形態に係る決済システムが適用されたゲームシステムの全体構成を示す図。 図１のゲームシステムに適用された決済システムにおける特徴的な処理の概要を示す図。 決済システムの制御系の構成を示すブロック図。 ゲーム機の課金管理部が課金の発生に対応して実行する端末課金処理の手順の一例を示すフローチャート。 図４の処理に対応して決済サーバが実行する消費管理処理の手順を示すフローチャート。 ゲーム機の課金管理部が課金の発生に対応して実行する端末課金処理の手順の他の例を示すフローチャート。

図１は、本発明の一形態に係る決済システムが適用されたゲームシステムを説明する。まず、図１を参照して、ゲームシステムの全体構成を説明する。ゲームシステム１は、サーバ装置としてのセンターサーバ２と、センターサーバ２に所定のネットワーク５を介して接続可能なクライアント装置としてのゲーム機３及びユーザ端末装置４とを含む。センターサーバ２は、複数のコンピュータ装置としてのサーバユニット２Ａ、２Ｂ…が組み合わされることにより一台の論理的なサーバ装置として構成されている。ただし、単一のサーバユニットによりセンターサーバ２が構成されてもよい。あるいは、クラウドコンピューティングを利用して論理的にセンターサーバ２が構成されてもよい。

ゲーム機３は、所定のプレイ料金の支払いと引き換えに、そのプレイ料金に対応した範囲でユーザにゲームをプレイさせる商業用（業務用）のゲーム機として構成されている。この種のゲーム機３は、アーケードゲーム機と呼ばれることがある。ゲーム機３は、多数のユーザにゲームを繰り返しプレイさせて収益を上げることを主たる目的として店舗６等の所定の施設に設置されるコンピュータ装置である。なお、店舗６には一以上の適宜数のゲーム機３が設置される。図１では、ゲーム機３を区別せずに描いているが、そのハードウエア構成やゲームの内容は適宜に選択されてよい。ゲーム機３は、特定のゲームに適合する物理的構成（例えば操作部等）を備えた専用機として構成されてもよいし、ソフトウエアの書き換えにより種々のゲームに対応可能な汎用機として構成されてもよい。

一方、ユーザ端末装置４は、ネットワーク接続が可能でかつユーザの個人用途に供されるコンピュータ装置である。例えば、据置型又はブック型のパーソナルコンピュータ（以下、ＰＣと表記する。）４ａ、あるいは携帯電話（スマートフォンを含む。）のようなモバイル端末装置４ｂがユーザ端末装置４として利用される。その他にも、据置型の家庭用ゲーム機、携帯型ゲーム機、携帯型タブレット端末装置といった、ネットワーク接続が可能でかつユーザの個人用途に供される各種のコンピュータ装置がユーザ端末装置４として利用されてよい。ユーザ端末装置４は、各種のコンピュータソフトウエアを実装することにより、センターサーバ２が提供する種々のサービスをユーザに享受させることが可能である。

ネットワーク５は、センターサーバ２に対してゲーム機３及びユーザ端末装置４をそれぞれ接続させることができる限り、適宜に構成されてよい。一例として、ネットワーク５は、ＴＣＰ／ＩＰプロトコルを利用してネットワーク通信を実現するように構成される。典型的には、ＷＡＮとしてのインターネット５Ａと、センターサーバ２及びゲーム機３のそれぞれとインターネット５Ａとを接続するＬＡＮ５Ｂ、５Ｃとがルータ５Ｄを介して接続されることにより構築される。ユーザ端末装置４も適宜の構成によりインターネット５Ａに接続される。なお、ゲーム機３と店舗６のルータ５Ｄとの間にローカルサーバが設置され、そのローカルサーバを介してゲーム機３がセンターサーバ２と通信可能に接続されてもよい。センターサーバ２のサーバユニット２Ａ、２Ｂ…はＬＡＮ５Ｃに代えて、又は加えてＷＡＮ５Ａにより、相互に接続される場合もある。

次に、図２を参照してゲームシステム１に適用された決済システムの特徴を説明する。決済システム１０は、決済サーバ１１と、ゲーム機３をクライアントとするサーバクライアントシステムとして構成されている。決済サーバ１１は、センターサーバ２の一部として単一又は複数のサーバユニット２Ａ、２Ｂ…により実現される。決済サーバ１１は、ゲーム機３からの決済要求に従って、ユーザが保有する仮想通貨の残高をユーザの識別情報（一例としてユーザＩＤ）と対応付けて記録した口座データＡＤａ、ＡＤｂ…（図ではユーザＡ、Ｂの口座データのみを示す。以下、参照符号ＡＤで代表することがある。）にアクセスし、ゲーム機３から指定された課金対象ユーザの口座データＡＤから仮想通貨を消費させる決済処理を試行し、その処理結果をゲーム機３に通知する。ゲーム機３は決済処理の成功が通知されるとゲームのプレイを許可し、決済処理の失敗が通知されるとゲームのプレイを許可しない。なお、仮想通貨の用語は、現実の通貨と引き換えにユーザが取得可能でかつ電子的な情報として取引される金銭的価値の一例の意味で用いる。決済システム１０において、仮想通貨は現実の通貨と同様に金銭的価値として通用する。

ゲーム機３においては、複数のユーザがプレイに必要な料金を分担して支払いたい場合がある。例えば、単一のゲーム機３で二人のユーザがゲームをプレイするモード（いわゆる２Ｐモード）が選択された場合、そのモードのプレイに必要な料金を二人のユーザが分担して支払う場合等が該当する。この場合、決済サーバ１１による決済処理が各ユーザに対する課金のそれぞれを単位として行われ、ゲーム機３にも決済処理の結果が課金毎に個別に通知されることにより、一方のユーザの決済が成功しても、他方のユーザの決済が残高不足等によって失敗し、決済処理が成功したユーザのみでゲームが開始されてしまう可能性がある。そこで、決済システム１０においては、ゲーム機３にて、決済処理の結果が同一に定まるべき複数の課金が発生した場合、ゲーム機３がそれらの課金を一群の課金として一括処理の対象に設定して決済サーバ１１に決済処理を要求し、決済サーバ１１はこれを受けて一群の課金のそれぞれに対応する決済処理を試行する。そして、全ての決済処理が成功した場合には一群の課金に対応する決済処理が成功したことをゲーム機３に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、全ての決済処理を失敗したものとして処理して一群の課金に対応する決済処理が失敗したことをゲーム機３に通知する。

上記の処理を具体的な例により説明する。二人のユーザＡ、Ｂが共同してゲームをプレイするモードを選択した場合において、ユーザＡ、Ｂにプレイ料金がそれぞれ課金され、ユーザＡに対する課金額がＣａ、ユーザＢに対する課金額がＣｂであったとする。課金額Ｃａ、Ｃｂは互いに等しくてもよいし、異なっていてもよい。この場合、ゲーム機３は、ユーザＡ、Ｂのそれぞれに対する課金を一群の課金とみなし、ユーザＡ、Ｂの口座データＡＤａ、ＡＤｂを特定するための識別情報、一例として、ユーザＡ、Ｂがそれぞれ所有するカード８に記録されたカード毎にユニークなカードＩＤをユーザＡ、Ｂから取得する。次に、ゲーム機３は、ユーザＡのカードＩＤ及び課金額Ｃａを含む課金情報、及びユーザＢのカードＢのカードＩＤ及び課金額Ｃｂを含む課金情報をそれぞれ生成し、それらの課金情報に従った決済処理を一括処理の対象に設定して、決済サーバ１１にそれらの決済処理を要求する。決済サーバ１１は、ゲーム機３から一括処理の対象に設定された決済処理の要求を受け取ると、ユーザＡのカードＩＤに基づいてユーザＡの口座データＡＤａにアクセスし、口座残高から課金額Ｃａに相当する仮想通貨の消費を試み、その結果（成功又は失敗）を判別し、かつ、ユーザＢのカードＩＤに基づいてユーザＢの口座データＡＤｂにアクセスし、口座残高から課金額Ｃｂに相当する仮想通貨の消費を試み、その結果（成功又は失敗）を判別する。そして、決済サーバ１１は、各決済処理の結果がいずれも成功であれば、一括処理の対象の全ての決済処理が成功したことをゲーム機３に通知する。一方、決済サーバ１１は、一つでも決済処理に失敗した場合には一括処理の対象の全ての決済処理が失敗したことをゲーム機３に通知する。この場合、決済サーバ１１は一部の決済処理（先に試行した決済処理）が成功していれば、その決済処理を取り消す。

以上のように、決済システム１０によれば、ゲーム機３にて決済処理の結果が同一に定まるべき一群の課金が発生した場合、ゲーム機３がそれぞれの課金に対応する決済処理を一括処理の対象に設定してそれらの決済処理を決済サーバ１１に要求し、決済サーバ１１は、全ての決済処理が成功した場合に限って決済処理の成功が通知され、一つでも決済処理が失敗すれば全ての決済が失敗したものと処理してゲーム機３に全ての決済処理が失敗したことが通知される。したがって、料金を分担すべきユーザ間で決済処理の結果が相反することがない。そのため、決済に成功したユーザに限ってゲームのプレイを開始させるといった、ユーザが意図しない制御を行う必要がなく、一部の決済が失敗した場合に生じ得る不都合を未然に防止することができる。

次に、図３を参照して、決済システム１０における制御系の要部の構成を説明する。まず、ゲーム機３には、制御部２０と、記憶部２１と、リーダ部２２とが設けられている。制御部２０は、ＣＰＵ及びその動作に必要な周辺装置を含み、記憶部２１に記録されたゲーム機用プログラムＰｇに従ってゲームをプレイさせるために必要な各種の処理を実行する。記憶部２１は磁気記憶媒体、ＥＥＰＲＯＭといった不揮発性の記憶媒体を有し、制御部２０に対する外部記憶装置として機能する。リーダ部２２は制御部２０からの指示に従ってユーザのカード８に記録されたカードＩＤを読み取り、制御部２０に通知する。

制御部２０には、そのハードウエアとソフトウエアとしてのゲーム機用プログラムＰｇとが協働して実現される論理的装置として、ゲーム制御部２３及び課金管理部２４が設けられる。ゲーム制御部２３は、ユーザの操作に応じてゲームの進行を制御するために必要な各種の演算処理等を実行することによりゲームそれ自体の制御主体となる装置である。課金管理部２４はゲーム機３におけるユーザへの課金を管理する装置である。課金管理部２４は、ゲーム制御部２３からの通知によりユーザへの課金の発生を検出し、課金内容に対応した決済処理を決済サーバ１１に要求し、その決済処理の結果を決済サーバ１１から受け取ってゲーム制御部２３に結果を通知する。課金管理部２４は、上述した一群の課金が発生したか否かを判別する処理と、一群の課金のそれぞれに対応する決済処理を一括処理の対象に設定する処理とを担当する。

一方、決済サーバ１１には、制御部３０と、記憶部３１とが設けられている。制御部３０は、ＣＰＵ及びその動作に必要な周辺装置を含み、記憶部２１に記録されたサーバ用プログラムＰｓに従って仮想通貨を用いた決済に必要な各種の処理を実行する。記憶部３１は磁気記憶媒体、ＥＥＰＲＯＭといった不揮発性の記憶媒体を有し、制御部３０に対する外部記憶装置として機能する。

制御部３０には、そのハードウエアとソフトウエアとしてのサーバ用プログラムＰｓとが協働して実現される論理的装置として、取引管理部３２及び消費管理部３３が設けられる。取引管理部３２は、ゲーム機３からの決済処理の要求を受け取り、その要求に添えられた課金情報に応じて仮想通貨の消費を消費管理部３３に指示し、消費管理部３３の処理結果に基づいて、決済処理の結果をゲーム機３に通知するといった仮想通貨の取引に関する制御を実行する。消費管理部３３は、仮想通貨の消費を制御する。

決済サーバ１１の取引管理部３２は、ユーザ情報のデータＤ１０及び取引履歴のデータＤ１１に、消費管理部３３は仮想通貨残高のデータＤ１２にそれぞれアクセス可能とされている。ユーザ情報のデータＤ１０は、ユーザのカードＩＤと、ユーザ毎にユニークなユーザ識別情報としてのユーザＩＤとの対応関係を記述したデータである。取引管理部３２は、ユーザ情報のデータＤ１０にアクセスすることにより、ゲーム機３から受け取った課金情報のカードＩＤに対応するユーザＩＤを取得し、そのユーザＩＤと課金額に相当する仮想通貨の消費量とを消費管理部３３に通知する。また、取引管理部３２は、決済処理の結果を課金情報とともに取引履歴のデータＤ１１に記録する。

消費管理部３３は、取引管理部３２からユーザＩＤ及び消費量を指定して仮想通貨の消費を指示されると、仮想通貨残高のデータＤ１２にアクセスして、ユーザＩＤに対応する口座を特定し、その口座に保持された残高を課金情報で指定された消費量に相当する量減少させる決済処理を試み、その結果を取引管理部３２に通知する。取引管理部３２は、消費管理部３３から通知される処理結果に基づいてゲーム機３に処理結果を通知するが、この際、一括処理が設定された決済処理に関しては、それぞれの処理結果を一致させるために必要な処理を行う。つまり、取引管理部３２は、ゲーム機３から一括処理の対象として設定された決済処理が要求された場合、その一括処理の対象となる決済処理間で同一の処理結果を得るための処理を担当する。なお、決済サーバ１１には、決済処理に伴って発生する各種の関連処理を行うための論理的装置及びデータも設けられるが、それらの図示及び説明は省略する。口座データＡＤに記録される残高は、ユーザ端末装置４からのユーザの購入操作等に従って増加させることができるが、その処理に必要な構成の図示及び説明は省略する。

次に、図４及び図５を参照して決済システム１０の処理手順の一例を説明する。図４は、ゲーム機３の課金管理部２４が課金の発生に対応して実行する端末課金処理の手順の一例を示している。この例は、ユーザが購入しようとする商品に応じて課金対象者の人数が予め定められ、課金対象者の人数が２以上に設定された商品が購入される場合に一群の課金が発生したと判別する例である。ここでいう商品はゲーム機３においてユーザが購入可能な無形の商品を意味する。例えば、ゲームのモード、コンテンツ（アイテム等）等が商品に相当する。つまり、ゲーム機３にて利用されるべきプログラム又はデータが無形の商品としてユーザの購入対象となる。また、商品には課金対象者（つまり、料金を支払うべきユーザ）の人数が予め設定されており、課金対象者の人数は商品に応じて１又は２以上の複数に設定されている。例えば、二人のユーザでプレイするいわゆる２Ｐモードの場合、課金対象者の人数として２設定される。なお、購入の用語は、その所有権をユーザが取得する譲渡に限定されず、一定期間又は無期限の使用の権利をユーザが獲得する場合も購入の概念に含まれる。

ゲーム機３にてユーザが何らかの商品を購入する操作を行うと、ゲーム機３の課金管理部２４は図４の処理を開始し、まずゲーム制御部２３からユーザが購入する商品の情報を取得してその内容を確認する（ステップＳ１１）。ここでは、特に、商品に対して予め設定されている料金及び課金対象者の人数を確認する。例えば、ゲーム機３にてユーザに提供される商品毎にユニークな商品コードを設定し、その商品コードと料金及び課金対象者の人数を指定する情報とを対応付けたテーブルを予めゲーム機３に記録しておくことにより、料金及び課金対象者を確認することができる。

次に、課金管理部２４は、課金対象者の人数が複数か否かを判別する（ステップＳ１２）。複数であった場合、課金管理部２４は決済処理が同一に定まるべき一群の課金が発生したものと判断してステップＳ１３に進み、単数、つまり課金対象者が一人であった場合にはステップ１８に進む。ステップＳ１３に進んだ場合、課金管理部２４は課金対象者の人数をユーザに提示してその人数分のカードＩＤの読み取りを要求し、その要求に対応する全てのユーザのカードＩＤを取得することにより、課金対象の全てのユーザを識別する。次に、課金管理部２４は、課金対象の各ユーザに対する課金額を確定する（ステップＳ１４）。例えば、商品に対して料金（つまり課金額の総額）以外にも、課金対象者の人数に応じて各ユーザへの課金額が予め設定されている場合には、その額をユーザ毎の課金額として確定すればよい。商品に対して料金のみが設定されている場合には、その料金を課金対象のユーザが互いに等しく分担するように課金額が確定されてもよい。つまり、商品の料金をユーザ数で割った額が各ユーザに対する課金額として確定されてもよい。あるいは、各ユーザに対する課金額をユーザに指定させ、指定された額が課金額として確定されてもよい。なお、商品に対して予め課金対象の人数が設定されている場合、商品の料金は課金対象者の人数で等しく割ることができる値に設定されることが望ましい。料金をユーザ数で除したときに余り（端数）が生じる場合には、ユーザからの指示に従って、あるいはユーザの指示を経ることなく、所定の条件に従って自動的に、余りの額を負担するユーザが決定されてもよい。課金額を確定する際に、その単位は仮想通貨にて決済可能な最小単位以上であれば適宜に設定してよい。例えば、１円単位での決済が可能な場合、課金額を１円単位で設定してもよいし、１００円単位で設定してもよい。

各ユーザへの課金額が確定すると、課金管理部２４は各ユーザに対する課金情報を生成する（ステップＳ１５）。課金情報は課金対象のユーザのカードＩＤ、課金額を含む。さらに課金情報には、商品を識別する情報（例えば商品コード）といった取引履歴のデータＤ１１に記録されるべき各種の情報が含まれてもよい。次に、課金管理部２４は、課金対象の全てのユーザに対応する決済処理を一括処理の対象に設定する（ステップＳ１６）。例えば、一括処理がなされるべき課金情報を一つの処理単位としてひとまとめに統合することにより、一括処理の対象の決済処理を設定することができる。他にも、一括処理の対象は適宜の手法で設定できる。例えば、課金情報を相互に関連付ける情報を各ユーザに対する課金情報に記録することにより、決済サーバ１１にて一括処理の対象となる決済処理が判別できるようにしてもよい。次に、課金管理部２４は、生成された課金情報を決済サーバ１１に送信して決済処理を要求する（ステップＳ２１）。この場合、課金対象の全てのユーザに関する決済処理が、一括処理の対象として、ひとまとめにして決済サーバ１１に要求される。

一方、ステップＳ１２で課金対象者の人数が一人であった場合、課金管理部２４は課金対象のユーザのカードＩＤを取得することによりそのユーザを識別し（ステップＳ１８）、続いてユーザへの課金額を確定する（ステップＳ１９）。この場合の課金額は商品の料金そのものである。さらに、課金管理部２４は単一のユーザに関する課金情報を生成し（ステップＳ２０）、その後、ステップＳ２１へと進んで決済処理を要求する。このときの要求では一括処理であることの通知がなされない。

決済処理を要求した後、課金管理部２４は決済処理の結果を決済サーバ１１から取得するまで処理を保留し（ステップＳ２２）、処理結果を取得したら決済処理が成功したか否かを判別する（ステップＳ２３）。そして、決済処理が成功していればゲーム制御部２３に対して商品の購入を許可することを通知し（ステップＳ２４）、決済処理が失敗であればゲーム制御部２３に対して商品の購入を許可しないことを通知する（ステップＳ２５）。これを受けてゲーム制御部２３は、ユーザが購入を希望した商品をユーザに提供してよいか否かを制御する。例えば、ユーザが所定のモードを商品として購入しようとした場合、ゲーム制御部２３は購入許可であればそのモードをプレイさせるための処理に進み、購入が許可されていなければそのモードでのプレイを禁止する。

なお、上記の処理では、ステップＳ１２で課金対象者が複数であった場合、ステップＳ１３にてまず全ユーザのカードＩＤを取得し、その後、ステップＳ１４で課金額を確定し、ステップＳ１５で全ユーザの課金情報を生成しているが、これらの手順を入れ替えてもよい。例えば、課金対象者の人数が複数であった場合、一人目のユーザに関してまずカードＩＤの取得、課金額の確定及び課金情報の生成を順次実行し、次に二人目のユーザについて同様の処理を行い、以下、課金対象者の全ユーザに対して処理が完了するまでループを繰り返し、全ての課金情報が生成された時点でステップＳ１６に進んでもよい。さらに、一人目のユーザに関して課金情報が生成された時点でこれを一括処理の対象に設定して決済サーバ１１に決済処理を要求し、以下全てのユーザの処理が終わるまで同様の処理を繰り返してもよい。この場合、決済サーバ１１では一人目のユーザの課金情報を得た時点で先行して決済処理の試行を開始することができ、かつ、一括処理の対象の決済処理が全て要求されるまで、決済処理の結果の確定とゲーム機３への通知を保留することにより、一括処理の対象となる決済処理の結果を相互に一致させることができる。また、上記の処理では、課金対象者が一人の場合、ステップＳ１８〜２０に分岐したが、これを分岐することなくステップＳ１３〜Ｓ２１の処理を順次実行してもよい。

図５は、図４の処理に対応して決済サーバ１１が実行する消費管理処理の手順を示している。決済サーバ１１は、ゲーム機３から決済処理が要求されると図５の処理を開始する。図５の処理においては、まず取引管理部３２がゲーム機３から決済処理の要求に伴って提供される課金情報を確認し（ステップＳ３１）、次に取引管理部３２は、ゲーム機３から要求された決済処理が一括処理の対象として設定されているか否かを判別する（ステップＳ３２）。一括処理の対象であった場合、取引管理部３２は処理数を判別するための変数Ｎに初期値１をセットし（ステップＳ３３）、その後、Ｎ人目のユーザに関する決済処理を消費管理部３３に試行させる（ステップＳ３４）。この場合、取引管理部３２は処理対象のユーザに関する課金情報からカードＩＤを取得し、そのカードＩＤに対応するユーザＩＤをユーザ情報のデータＤ１０から取得し、そのユーザＩＤと課金情報に含まれた課金額とを消費管理部３３に通知する。その通知に応答して、消費管理部３３はステップＳ３４の処理を実行する。すなわち、消費管理部３３は、仮想通貨残高のデータＤ１２にアクセスして、取引管理部３２から通知されたユーザＩＤに対応する口座データＡＤを特定し、その口座データＡＤの残高が課金額に相当する量（消費量）以上か否かを判別する。そして、残高が消費量以上であれば、残高を消費量だけ減少させて取引管理部３２に決済成功を通知する。一方、仮想通貨の残高が消費量未満であった場合、消費管理部３３は残高を減少させることなく、決済失敗を取引管理部３２に通知する。ただし、残高が足りていても、例えば口座データＡＤからの仮想通貨の消費が禁止されているといった理由により、仮想通貨を消費することができない場合も決済失敗としてよい。

ステップＳ３４にて消費管理部３３が決済処理を試行すると、次に取引管理部３２は消費管理部３３から通知される決済処理の結果が成功か否かを判別する（ステップＳ３５）。成功であった場合、取引管理部３２は一括処理の対象とされた全ての決済処理が終了したか否かを判別する（ステップＳ３６）。この場合、変数Ｎが一括処理の対象となっている決済処理の数、言い換えれば、課金対象者の人数と一致するか否かを判別すればよい。未処理の決済処理があれば取引管理部３２は変数Ｎに１を加算し（ステップＳ３７）、その後、ステップＳ３４の処理に戻る。一方、ステップＳ３６にて全ての決済処理が終わったと判断した場合、取引管理部３２はステップＳ３８に進み、全ての決済処理が成功したことを処理結果としてゲーム機３に通知する。

ステップＳ３５にて、消費管理部３３から通知される決済処理の結果が失敗であった場合、取引管理部３２はステップＳ３９に進み、既に成功している決済処理、この場合は一人目からＮ−１人目までの決済処理の取り消しを消費管理部３３に指示し、これを受けて消費管理部３３は該当する決済処理を取り消す（ステップＳ３９）。つまり、消費管理部３３はステップＳ３４で残高から引かれた消費量を口座データＡＤの残高に加算することにより、決済処理を取り消す。その後、取引管理部３２は、一括処理の対象の全ての決済処理が失敗したことをゲーム機３に通知する（ステップＳ４０）。

なお、ステップＳ３２で一括処理の対象として設定されていないと判断された場合、取引管理部３２は課金情報のカードＩＤに対応するユーザＩＤを取得して課金額とともに消費管理部３３に通知することにより決済処理を要求し、これに対応して消費管理部３３が指定されたユーザＩＤに対応する口座データＡＤを特定して決済処理を試みる（ステップＳ４１）。その後、取引管理部３２は消費管理部３３から決済成功が通知されたか否かを判別し（ステップＳ４２）、成功であれば決済成功をゲーム機３に通知し（ステップＳ４３）、失敗であれば決済失敗をゲーム機３に通知する（ステップＳ４４）。ステップＳ３８、Ｓ４０、Ｓ４３又はＳ４４のいずれかによりゲーム機３に決済処理の結果を通知した後、決済サーバ１１は図５の処理を終える。その通知は図４のステップＳ２２にてゲーム機３の課金管理部２４に取得される。

以上の処理によれば、一群の課金が発生すると、それらの課金に対応する決済処理が一括処理の対象に設定された状態で決済サーバ１１に決済処理が要求され、その場合、決済サーバ１１からは全ての決済処理に成功した場合に限って決済成功がゲーム機３に通知され、それ以外の場合、つまり一つでも決済処理が失敗した場合には一括処理の対象の全ての決済処理が失敗したものとしてゲーム機３に決済処理の結果が通知される。したがって、商品の料金を複数のユーザが分担して支払うべき場合において、ユーザ間で決済処理の結果が相反することがない。そのため、決済に成功したユーザに限ってゲームのプレイを開始させるといった、ユーザが意図しない制御を行う必要がなく、一部の決済が失敗した場合に生じ得る不都合を未然に防止することができる。なお、図５の処理でも、ステップＳ３２の分岐を省略し、課金対象のユーザが一人であってもステップＳ３３以下の処理に進むようにしてもよい。

次に、図６を参照してゲーム機３における端末課金処理の他の形態を説明する。なお、図６の端末課金処理は、商品を購入しようとする際に、課金対象者の人数をユーザに決定させ、課金対象者の人数が２以上の場合に一群の課金が発生したと判別する例である。図６の処理は図４の処理の一部を変更したものであり、図４と共通する処理は同一の参照符号を付して説明を省略する。

ゲーム機３にてユーザが何らかの商品を購入する操作を行うと、ゲーム機３の課金管理部２４は図６の処理を開始し、まずゲーム制御部２３からユーザが購入する商品の情報を取得してその内容を確認する（ステップＳ５１）。ここでは、特に、商品に対して予め設定されている料金（課金額）を確認すればよい。次に、課金管理部２４はユーザにカード８の読み取りを指示し、その指示に対応するユーザのカードＩＤを取得することにより、課金対象のユーザを識別する（ステップＳ５２）。次に、課金管理部２４は、所定の基準時、例えばステップＳ５２の処理開始時点から所定の待ち時間が経過したか否かを判別し（ステップＳ５３）、経過していなければステップＳ５２に戻る。待ち時間は、ステップＳ５２、Ｓ５３の間で処理がループしている間、二人以上のユーザからカード８のカードＩＤを取得することが十分に可能な長さに設定される。

ステップＳ５３にて待ち時間が経過したと判断されると、課金管理部２４はステップＳ５４に進み、複数のユーザのカードＩＤを取得したか否かを判別する。複数と判断された場合、課金管理部２４はステップＳ５５に進み、各ユーザへの課金額を確定する。この処理は図４のステップＳ１４と同様に、商品の料金と課金対象者の人数とに基づいて各ユーザに対する課金額を確定する処理であるが、図６の場合はステップＳ５３の処理が肯定判断されるまでは課金対象のユーザ数が確定しておらず、商品の料金に対して各ユーザに対する課金額を予め定めておくことができない。したがって、ステップＳ５５では、各ユーザに対する課金額をユーザに指定させ、指定された額を課金額として確定するか、あるいは、ユーザの指示を経ることなく課金管理部２４が自動的に課金額を確定するようにしてもよい。例えば、商品の料金を課金対象のユーザ数で除した値を各ユーザへの課金額として確定させることが考えられる。この場合、課金額に余り（端数）が生じる場合には、ユーザからの指示に従って、あるいはユーザの指示を経ることなく、所定の条件に従って自動的に、余りの額を負担するユーザが決定されてもよい。

ステップＳ５５にて課金額が確定された後、課金管理部２４はステップＳ１５以下の処理に進む。一方、ステップＳ５４にて課金対象のユーザ数が単数であると判断された場合、課金管理部２４はステップＳ１９、Ｓ２０を経てステップＳ２１に進む。これらの処理は図４と同じでよい。

図６の処理によれば、商品に対して予め課金対象者の人数を決めておく必要がなく、商品の料金を何人のユーザで分担して支払うかをユーザが決められるので、決済の自由度が高まる。例えば、所定人数のユーザがプレイすることを前提としたモードであっても、その料金を所定人数より多いユーザで分担して支払い、あるいは、所定人数未満のユーザで支払うといった決済処理を実現することができる。

本発明は以上の形態に限定されることなく、適宜の変更又は変形を施した形態にて実施されてよい。例えば、上記の形態では、一括処理が設定された決済処理が要求された場合、決済サーバ１１の消費管理部３３にてユーザの口座データＡＤから仮想通貨を順次消費させることにより決済処理を試行しているが、この段階では各ユーザの課金額以上の残高が存在するか否かのみを確認し、全ユーザの残高が課金額以上の場合に、仮想通貨の消費を実行するものとしてもよい。この場合、残高不足のユーザが一人でも存在すれば、一括処理の対象の決済処理が全て失敗したものとする処理結果を取引管理部３２が生成し、ゲーム機３に通知する処理を行えばよく、消費管理部３３により決済処理を取り消す必要はない。上記の形態では、各ユーザに対する課金額をゲーム機３の課金管理部２４にて決定しているが、これに代えて、決済サーバ１１側で各ユーザへの課金額が決定されてもよい。

一括処理の対象となる決済処理が、一部ユーザの残高不足を原因として失敗に終わった場合、決済可能な代替の課金プランを決済システムがユーザに提案する機能が追加されてもよい。例えば、残高に余裕があるユーザの課金額を増加させることにより、商品の料金を分担して決済することが可能な場合には、修正後の各ユーザへの課金額をユーザに代替プランとして提示し、ユーザの許可を得て決済処理を試行するものとしてもよい。料金が５００円に設定されたモードを二人のユーザが２５０円ずつ支払ってプレイすることを希望し、一人のユーザの残高が１００円しかなかった場合、そのユーザの課金額を１００円、他のユーザの課金額を４００円として提示するといった例が想定される。

複数のユーザが商品の料金を分担して支払う場合を例に挙げたが、そのような態様に限らず、一人のユーザが複数の決済手段を併用して料金を支払おうとする場合でも本発明の決済システムは適用可能である。例えば、ユーザが所定のサービスを利用した際に、特典としてポイントを付与するシステムにおいては、ユーザが商品の料金の一部をポイントで支払い、残りを仮想通貨で支払うことを希望することがある。この場合、ポイントの利用に関する課金と仮想通貨の利用に関する課金とを一群の課金と見なすことにより、本発明を適用することができる。

本発明の各態様はゲームシステムに適用される例に限らず、各種の決済システムに適用されてよい。例えば、店舗内における決済端末装置を課金管理手段とし、店舗内におけるサーバを決済手段としてそれぞれ機能させる決済システムでも本発明は適用可能である。商品は無形の商品に限らず、有形の商品であってもよい。例えば、決済成功の場合に有形の商品を払い出し、あるいは発送するシステムにおける決済に本発明の各態様が適用されてもよい。

上記の形態では、決済システムが、サーバクライアントシステムとして構成され、ユーザが所有する金銭的価値の一例としての仮想通貨がサーバ側でユーザの識別情報と対応付けて記録され、その残高を課金額に相当する量だけ消費させるいわゆるプリペイド型システムとして構成され、かつ、クライアント側には金銭的価値の残高を保持せず、ユーザの口座を特定する情報をクライアント側で取得してサーバに通知する、いわゆるシンクライアント型のシステムとして構成されている。しかしながら、本発明の一態様に係る決済システムは、これらの例に限らない。例えば、ポストペイ型の決済システムでも、通信エラー、あるいは利用制限などによって一部のユーザの決済処理のみが失敗する可能性があり、こうした場合に一群の課金に対応する決済処理を一括処理の対象に設定して本発明を適用すれば、決済処理間で結果が相反する不都合を回避することができる。また、ユーザが所有するカード、携帯電話等に実装されたＩＣチップ等の記録媒体に仮想通貨の残高が記録され、その残高を店舗等に設置されたコンピュータ装置の付属機器としてのリーダライターで読み取って課金額を消費させるスタンドアローン型の決済システム（あるいは決済装置）であっても、一群の課金のそれぞれで利用されるべき複数の記憶媒体から残高をそれぞれ取得し、全ての記憶媒体の残高が各媒体に対する課金額以上であれば決済処理が成功と見なしてリーダライターに残高消費を指示し、一つでも残高が不足する記憶媒体が存在すれば決済失敗として処理することにより本発明を適用することができる。この場合はコンピュータ装置が課金管理手段及び決済手段として兼用されることになる。

上述した実施の形態及び変形例のそれぞれから導き出される本発明の各種の態様を以下に記載する。なお、以下の説明では、本発明の各態様の理解を容易にするために添付図面の参照符号を括弧書にて付記するが、それにより本発明が図示の形態に限定されるものではない。

本発明の一態様に係る決済システムは、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段（２４）と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段（１１）とを備えた決済システム（１０）において、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段（２４、Ｓ１１、Ｓ１２；Ｓ５１〜５４）と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段（２４、Ｓ１６、Ｓ２１）と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段（３３、Ｓ３４）と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段（３２、Ｓ３５、Ｓ３８〜Ｓ４０）と、が設けられているものである。

本発明の一態様に係る決済制御方法は、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段（２４）と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段（１１）とを備えたコンピュータシステム（１）に適用される決済制御方法において、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手順（Ｓ１１、Ｓ１２；Ｓ５１〜５４）と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手順（Ｓ１６、Ｓ２１）とを実行させ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手順（Ｓ３４）と、前記決済試行手順により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手順で試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手順（Ｓ３５、Ｓ３８〜Ｓ４０）とを実行させるものである。

本発明の一態様に係る決済制御用のコンピュータプログラムは、所定のコンピュータシステムに含まれた少なくとも一のコンピュータ装置（３、１１）を、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段（２４）、及び、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段（１１）として機能させる決済制御用のコンピュータプログラム（Ｐｇ、Ｐｓ）であって、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段（２４、Ｓ１１、Ｓ１２；Ｓ５１〜５４）と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段（２４、Ｓ１６、Ｓ２１）と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段（３３、Ｓ３４）と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段（３２、Ｓ３５、Ｓ３８〜Ｓ４０）と、が設けられように構成されたものである。

本発明の一態様に係る決済装置は、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段（２４）と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段（１１）とを備えた決済システム（１０）において、前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段（２４、Ｓ１１、Ｓ１２；Ｓ５１〜５４）と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段（２４、Ｓ１６、Ｓ２１）と、が設けられ、前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段（３３、Ｓ３４）と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段（３２、Ｓ３５、Ｓ３８〜Ｓ４０）と、が設けられているものである。

本発明の各態様によれば、一群の課金が発生した場合、それらの課金に対応する決済処理が一括処理の対象に設定されて決済処理が要求され、これに対応して決済試行手段により各決済処理が成功するか否かが試行され、全ての決済処理が成功する場合には一群の課金のそれぞれに対応する決済処理が全て成功したことが課金管理手段に通知され、一つでも決済処理が失敗すれば、全ての決済処理が失敗したものとして処理されて課金管理手段には一群の課金のそれぞれに対応する決済処理の全てが失敗したことが通知される。したがって、一群の課金のそれぞれに対応する決済処理間で決済処理の結果が相反するおそれがなく、一部の決済が失敗した場合に生じ得る不都合を未然に防止することができる。

なお、本発明の一態様に係るコンピュータプログラムは、記憶媒体に記憶された状態で提供されてもよい。この記憶媒体を用いれば、例えばコンピュータに本発明に係るコンピュータプログラムをインストールして実行することにより、そのコンピュータを利用して本発明のゲームシステムを実現することができる。コンピュータプログラムを記憶した記憶媒体は、ＣＤＲＯＭ等の非一過性の記憶媒体であってもよい。

本発明の一態様において、前記判別手段は、複数のユーザが料金を分担して支払うことにより商品を購入する場合に、各ユーザに対してなされるべき課金の集合が前記一群の課金に相当するものとして前記一群の課金が発生したと判別してもよい。この場合は、複数のユーザが料金を分担して支払うことにより商品を購入する場合、ユーザ間で決済処理の結果が相反するおそれを排除することができる。

上記の態様において、前記判別手段は、商品に応じて予め定められた課金対象者の人数を判別可能であり、前記課金対象者の人数が２以上の場合に前記一群の課金が発生したと判別してもよい。この場合には、商品に対して課金対象者の人数を予め設定しておくことにより、一群の課金が発生したか否かを容易に判別することができる。

あるいは、前記判別手段は、前記商品が購入される際に、課金対象者の人数をユーザの操作に基づいて判別し、前記課金対象者の人数が２以上と判別された場合に前記一群の課金が発生したものと判別してもよい。この場合には、ユーザの操作によって課金対象者の人数を判別するので、商品の料金を何人のユーザで分担して支払うかをユーザが決めることができ、決済の自由度が高まる。

上記形態において、前記決済試行手段は、前記複数のユーザのそれぞれが分担すべき料金の額に相当する金銭的価値を各ユーザに消費させる処理をユーザ毎の決済処理として試行するものとしてもよい。これによれば、ユーザに金銭的価値を消費させることにより決済処理が行われる。

さらに、前記一群の課金が発生した場合、商品の料金と課金対象者としてのユーザの人数とに基づいて前記複数のユーザがそれぞれ分担すべき料金の額を決定する課金額決定手段（２４、Ｓ１４；Ｓ５４）をさらに具備し、前記決済試行手段は、前記料金決定手段が決定した課金額に相当する金銭的価値を各ユーザに消費させてもよい。これによれば、課金額決定手段により各ユーザの課金額が決定されるので、各ユーザが料金の分担額を計算して指示するといった手間を省くことができる。

あるいは、前記ユーザが保有する金銭的価値がユーザの識別情報と対応付けて所定の残高データ（Ｄ１２）に記録され、前記決済試行手段は、各ユーザが消費すべき金銭的価値を、前記残高データに記録された各ユーザの金銭的価値から減少させることにより前記決済処理を試行するものとしてもよい。これによれば、残高データにユーザの識別情報と対応付けて記録された金銭的価値を減少させるため、いわゆるプリペイド型のシステムにおいて、一部の決済処理が失敗した場合の問題を解決することができる。

本発明の一態様において、前記取引管理手段は、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記一群の課金に対応して前記決済試行手段が試行した決済処理のうち、成功した決済処理を取り消すものとしてもよい（Ｓ３９）。これによれば、一部の決済処理が失敗した場合、先行して成功した決済処理が取り消されるため、一括処理の対象として設定された決済処理の一部が成功した状態で残されるおそれがない。

本発明の一態様においては、前記商品が、所定のコンピュータ装置（３）上で前記ユーザの利用に供される無形の商品であってもよい。これによれば、コンピュータ装置にて利用される商品の購入に際して複数の課金が発生した場合、それらの課金に対応する決済処理間で処理結果が相反することによる不都合の発生を防止することができる。

本発明の一態様においては、前記コンピュータ装置としてゲーム機（３）が設けられ、前記商品が前記ゲーム機にて利用されるべきプログラム又はデータであってもよい。これによれば、ゲーム機にて利用されるプログラム又はデータの購入に際して複数の課金が発生した場合、それらの課金に対応する決済処理間で処理結果が相反することによる不都合の発生を防止することができる。

さらに、前記ゲーム機にて複数のユーザが共同してプレイする場合における前記複数のユーザのそれぞれへの課金の集合が前記一群の課金に相当するものとされてもよい。これによれば、ゲーム機にてゲームをプレイ使用とする複数のユーザのそれぞれに課金が発生した場合、それらの課金に対応する決済処理間で処理結果が相反することによる不都合の発生を防止することができる。

本発明の一態様においては、決済システムがサーバクライアント型のシステムとして構成され、前記課金管理手段が前記クライアント（３）側に、前記決済手段が前記サーバ（１１）側にそれぞれ設けられてもよい。これによれば、クライアント側から一括処理の対象を設定して決済処理を要求することにより、サーバ側では決済処理間の処理結果の相反を防ぐように適切な処理を行うことができる。

１ ゲームシステム
２ センターサーバ
３ ゲーム機（クライアント、コンピュータ装置）
１０ 決済システム（コンピュータシステム）
１１ 決済サーバ（サーバ、決済手段、コンピュータ装置）
２４ 課金管理部（課金管理手段、判別手段、決済要求手段）
３２ 取引管理部（取引管理手段）
３３ 消費管理部（決済試行手段）
Ｄ１２ 仮想通貨残高データ

Claims (15)

1. 課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えた決済システムにおいて、
   前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、
   前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられている、決済システム。
2. 前記判別手段は、複数のユーザが料金を分担して支払うことにより商品を購入する場合に、各ユーザに対してなされるべき課金の集合が前記一群の課金に相当するものとして前記一群の課金が発生したと判別する請求項１に記載の決済システム。
3. 前記判別手段は、商品に応じて予め定められた課金対象者の人数を判別可能であり、前記課金対象者の人数が２以上の場合に前記一群の課金が発生したと判別する請求項２に記載の決済システム。
4. 前記判別手段は、前記商品が購入される際に、課金対象者の人数をユーザの操作に基づいて判別し、前記課金対象者の人数が２以上と判別された場合に前記一群の課金が発生したものと判別する請求項２に記載の決済システム。
5. 前記決済試行手段は、前記複数のユーザのそれぞれが分担すべき料金の額に相当する金銭的価値を各ユーザに消費させる処理をユーザ毎の決済処理として試行する請求項２〜４のいずれか一項に記載の決済システム。
6. 前記一群の課金が発生した場合、商品の料金と課金対象者としてのユーザの人数とに基づいて前記複数のユーザがそれぞれ分担すべき料金の額を決定する課金額決定手段をさらに具備し、前記決済試行手段は、前記課金額決定手段が決定した料金の額に相当する金銭的価値を各ユーザに消費させる請求項５に記載の決済システム。
7. 前記ユーザが保有する金銭的価値がユーザの識別情報と対応付けて残高データに記録され、
   前記決済試行手段は、各ユーザが消費すべき金銭的価値を、前記残高データに記録された各ユーザの金銭的価値から減少させることにより前記決済処理を試行する請求項５又は６に記載の決済システム。
8. 前記取引管理手段は、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記一群の課金に対応して前記決済試行手段が試行した決済処理のうち、成功した決済処理を取り消す請求項１〜７のいずれか一項に記載の決済システム。
9. 前記商品が、所定のコンピュータ装置上で前記ユーザの利用に供される無形の商品である請求項２〜７のいずれか一項に記載の決済システム。
10. 前記コンピュータ装置としてゲーム機が設けられ、前記商品が前記ゲーム機にて利用されるべきプログラム又はデータである請求項９に記載の決済システム。
11. 前記ゲーム機にて複数のユーザが共同してプレイする場合における前記複数のユーザのそれぞれへの課金の集合が前記一群の課金に相当する請求項１０に記載の決済システム。
12. サーバと該サーバに対して所定のネットワークを介して接続可能なクライアントとを含むサーバクライアント型のシステムとして構成され、前記課金管理手段が前記クライアント側に、前記決済手段が前記サーバ側にそれぞれ設けられている請求項１〜１１のいずれか一項に記載の決済システム。
13. 課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えたコンピュータシステムに適用される決済制御方法において、
    前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手順と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手順とを実行させ、
    前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手順と、前記決済試行手順により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手順で試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手順とを実行させる決済制御方法。
14. 所定のコンピュータシステムに含まれた少なくとも一のコンピュータ装置を、課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段、及び、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段として機能させる決済制御用のコンピュータプログラムであって、
    前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、
    前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられるように、構成された決済制御用のコンピュータプログラム。
15. 課金の発生に対応して課金内容に応じた決済処理を要求する課金管理手段と、前記決済処理の要求に従って前記課金内容に応じた決済処理を試行し、前記決済処理の結果を前記課金管理手段に通知する決済手段とを備えた決済システムにおいて、
    前記課金管理手段には、前記決済処理の結果が同一に定まるべき一群の課金が発生したか否かを判別する判別手段と、前記一群の課金が発生したと判別された場合、該一群の課金に対応する決済処理を一括処理の対象に設定して、該一群の課金に対応する決済処理を前記決済手段に要求する決済要求手段と、が設けられ、
    前記決済手段には、前記一括処理の対象として設定された決済処理が要求された場合、前記一群の課金のそれぞれに対応する決済処理を試行する決済試行手段と、前記決済試行手段により全ての決済処理が成功した場合には前記一群の課金に対応する決済処理が成功したことを前記決済処理の結果として前記課金管理手段に通知し、少なくとも一つの課金に対応する決済処理が失敗した場合には、前記決済試行手段が試行した全ての決済処理を失敗したものとして処理して前記一群の課金に対応する決済処理が失敗したことを前記決済処理の結果として前記課金管理手段に通知する取引管理手段と、が設けられている、決済装置。

Images