(57)【要約】【課題】  適切な決済を行うことのできる決済サーバ等を提供する。【解決手段】  残高管理ＤＢ４０３は、各電子マネーの残高情報を記憶する。決済制御部４０２は、収支が確定するまでにゲームサーバ１１にて発生した電子マネーの支払い分（参加料等）を供託するために、供託額を含んだ供託情報を生成して供託管理ＤＢ４０４に記憶させる。また、決済制御部４０２は、収支が確定するまでにゲームサーバ１１にて発生した払い戻し分（賞金等）を、当該供託情報の供託額と相殺する。そして、決済制御部４０２は、収支を確定する際に、供託管理ＤＢ４０４に記憶されている供託情報に基づいて、残高管理ＤＢ４０３の残高情報を更新する。【選択図】  図５
2005173827.tif 000002
【特許請求の範囲】
【請求項１】
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、
収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する供託情報記憶部と、
収支が確定するまでに発生した払い戻し分を、当該供託情報の供託額と相殺する供託情報更新部と、
収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する決済部とを備える、
ことを特徴とする決済サーバ。
【請求項２】
請求項１に記載の決済サーバであって、
収支が確定するまでの残高を、当該残高情報の残高から当該供託情報の供託額を控除した額として管理する残高管理部をさらに備える、
ことを特徴とするもの。
【請求項３】
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、
収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する供託情報記憶部と、
収支が確定するまでに発生した払い戻し分を債権額として管理する債権情報を記憶する債権情報記憶部と、
収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する決済額算出部と、
当該算出された決済額に基づいて、当該残高情報の残高を更新する決済部とを備える、
ことを特徴とする決済サーバ。
【請求項４】
請求項３に記載の決済サーバであって、
収支が確定するまでの残高を、当該残高情報の残高に当該債権額を加算して更に当該供託情報の供託額を控除した額として管理する残高管理部をさらに備える、
ことを特徴とするもの。
【請求項５】
請求項３に記載の決済サーバであって、
前記残高情報記憶部は、特定の用途で支払い可能となる特定用途残高を含む残高情報を記憶し、
前記供託情報記憶部は、特定の用途に向けた供託額を含む供託情報を記憶し、
前記債権情報記憶部は、特定の用途に向けた債権額を含む債権情報を記憶し、
前記決済額算出部は、当該特定の用途に向けた供託額と当該特定の用途に向けた債権額とを相殺し、特定用途の決済額を算出し、
前記決済部は、当該算出された特定用途の決済額に基づいて、当該特定用途残高を更新する、
ことを特徴とするもの。
【請求項６】
複数の端末と通信可能に接続されたゲームサーバと、当該ゲームサーバと通信可能に接続された決済サーバと、を備える決済管理システムであって、
前記ゲームサーバは、
接続された各端末との間で行われるゲームを制御するゲーム制御部と、
少なくともゲーム開始時に徴収される支払い金および、ゲーム終了時に払い戻される払い戻し金の処理を前記決済サーバに依頼する処理依頼部とを備え、
前記決済サーバは、
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、
収支が確定するまでに前記ゲームサーバにて発生した支払い金を供託額として管理する供託情報を記憶する供託情報記憶部と、
収支が確定するまでに前記ゲームサーバにて発生した払い戻し金を、当該供託情報の供託額と相殺する供託情報更新部と、
収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する決済部とを備える、
ことを特徴とする。
【請求項７】
複数の端末と通信可能に接続されたゲームサーバと、当該ゲームサーバと通信可能に接続された決済サーバと、を備える決済管理システムであって、
前記ゲームサーバは、
接続された各端末との間で行われるゲームを制御するゲーム制御部と、
少なくともゲーム開始時に徴収される支払い金および、ゲーム終了時に払い戻される払い戻し金の処理を前記決済サーバに依頼する処理依頼部とを備え、
前記決済サーバは、
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、
収支が確定するまでに前記ゲームサーバにて発生した支払い金を供託額として管理する供託情報を記憶する供託情報記憶部と、
収支が確定するまでに前記ゲームサーバにて発生した払い戻し金を債権額として管理する債権情報を記憶する債権情報記憶部と、
収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する決済額算出部と、
当該算出された決済額に基づいて、当該残高情報の残高を更新する決済部とを備える、
ことを特徴とする。
【請求項８】
残高情報記憶部と、供託情報記憶部とを用いる決済管理方法であって、残高情報記憶部は、支払い可能となる残高を管理する残高情報を記憶し、供託情報記憶部は、供託額を管理する供託情報を記憶し、
収支が確定するまでに発生した支払い分を供託額とした供託情報を供託情報記憶部に格納する供託情報格納ステップと、
収支が確定するまでに発生した払い戻し分を、当該供託情報の供託額と相殺する供託情報更新ステップと、
収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する決済ステップとを備える、
ことを特徴とする方法。
【請求項９】
残高情報記憶部と、供託情報記憶部と、債権情報記憶部とを用いる決済管理方法であって、残高情報記憶部は、支払い可能となる残高を管理する残高情報を記憶し、供託情報記憶部は、供託額を管理する供託情報を記憶し、債権情報記憶部は、債権額を管理する債権情報を記憶し、
収支が確定するまでに発生した支払い分を供託額とした供託情報を供託情報記憶部に格納する供託情報格納ステップと、
収支が確定するまでに発生した払い戻し分を債権額とした債権情報を債権情報記憶部に格納する債権情報格納ステップと、
収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する決済額算出ステップと、
当該算出された決済額に基づいて、当該残高情報の残高を更新する決済ステップとを備える、
ことを特徴とする方法。
【請求項１０】
コンピュータを、
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部、
収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する供託情報記憶部、
収支が確定するまでに発生した払い戻し分を、当該供託情報の供託額と相殺する供託情報更新部、
収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する決済部、
として機能させることを特徴とするプログラム。
【請求項１１】
コンピュータを、
支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部、
収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する供託情報記憶部、
収支が確定するまでに発生した払い戻し分を債権額として管理する債権情報を記憶する債権情報記憶部、
収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する決済額算出部、
当該算出された決済額に基づいて、当該残高情報の残高を更新する決済部、
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決済サーバ、決済管理システム、決済管理方法、および、プログラムに関する。
【背景技術】
【０００２】
近年、インターネット上にてゲームサーバ等を利用したネットワークゲーム（オンラインゲーム）が、普及してきている。また、インターネット上にて音楽や映像等のデジタルコンテンツの販売を行う販売サイトも広く知られている。
ユーザは、ゲーム装置やパーソナルコンピュータ等を操作して、これらのゲームサーバや販売サイトにアクセスし、ネットワークゲームをプレイしたり、デジタルコンテンツをダウンロードしたりする。その際、決済手段として、たとえば、プリペイド方式の電子マネーが用いられている。
【０００３】
この電子マネーは、ユーザによって事前に所定の金額分だけ購入（チャージ）され、インターネット上での決済に際して、貨幣と同等に使用（消費）される。また、使用により電子マネーの残高が少なくなった場合には、ユーザが追加購入（リチャージ）することにより、残高を増やすこともできる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のネットワークゲームでは、ゲームにおける勝敗等に拘わらず、単純に料金（参加料等）が電子マネーから差し引かれている。このため、ゲームに勝利しても料金面での優遇が得られず、達成感に物足りなさを感じるユーザも多かった。
また、ネットワークゲームを運営する企業等が、ゲームの勝者等に賞品（図書券等）や賞金を提供するといった企画を立てる場合もある。この場合、企業側は、勝者（ユーザ）の登録住所に賞品を送ったり、指定口座に賞金を振り込む必要があり、煩雑であるばかりでなく、別途経費も生じてしまう。そのため、企業側は、このような企画を立てることに消極的になりがちであった。
【０００５】
そこで、勝者の電子マネーに、賞品分や賞金分の額を払い戻す決済手法が、ユーザ側および企業側の双方を満足させるものとして、試みられようとしている。
【０００６】
しかしながら、このような決済手法を現実に行おうとした場合に、種々の不具合が生じることが懸念されている。
たとえば、決済時には、電子マネーの出金（引き落とし）処理に加えて、入金（払い戻し）処理が新たに発生し、その分だけ処理件数が増大することになる。
また、電子マネーを換金（現金化）するサービスを導入する場合では、従来であれば、残高が増えずに残っている電子マネーを換金することに何ら問題は生じない。これに対して、賞品分や賞金分の払い戻しが生じて、電子マネーの残高が購入時や追加購入時よりも増えてしまっていると、あたかもギャンブルのように、換金によりユーザが利益を得てしまうことになる。
さらに、賞品分を払い戻した場合でも、用途以外の名目で電子マネーが使用されてしまうと、賞品分として提供した意味がなくなってしまう。
【０００７】
そこで、これらの不具合を解消しつつ、ユーザ側および企業側の双方を満足させる決済手法の確立が求められていた。
【０００８】
本発明は、上記実状に鑑みてなされたもので、適切な決済を行うことのできる決済サーバ、決済管理システム、決済管理方法、および、プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の観点に係る決済サーバは、残高情報記憶部、供託情報記憶部、供託情報更新部、および、決済部を備え、以下のように構成する。
【００１０】
まず、残高情報記憶部は、たとえば、電子マネーの支払い可能となる残高を管理する残高情報を記憶する。また、供託情報記憶部は、収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する。
【００１１】
供託情報更新部は、収支が確定するまでに発生した払い戻し分を、当該供託情報の供託額と相殺する。たとえば、供託額と払い戻し分（払い戻し額）とが同額である場合に、供託情報更新部は、当該供託情報を供託情報記憶部から削除する。そして、決済部は、収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する。
【００１２】
このように、払い戻し分が供託額と相殺されるため、その分の決済を省くことができ、決済時における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００１３】
上記決済サーバは、収支が確定するまでの残高を、当該残高情報の残高から当該供託情報の供託額を控除した額として管理する残高管理部をさらに備えてもよい。この場合、残高管理部が、供託額等を考慮した残高を管理するため、決済時に残高不足となるような支払いの発生を未然に防止することができる。
【００１４】
本発明の第２の観点に係る決済サーバは、残高情報記憶部、供託情報記憶部、債権情報記憶部、決済額算出部、および、決済部を備え、以下のように構成する。
【００１５】
まず、残高情報記憶部は、たとえば、電子マネーの支払い可能となる残高を管理する残高情報を記憶する。また、供託情報記憶部は、収支が確定するまでに発生した支払い分を供託額として管理する供託情報を記憶する。そして、債権情報記憶部は、収支が確定するまでに発生した払い戻し分を債権額として管理する債権情報を記憶する。
【００１６】
決済額算出部は、収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する。そして、決済部は、当該算出された決済額に基づいて、当該残高情報の残高を更新する。
【００１７】
このように、収支が確定するまでに発生した供託額と債権額とを相殺してとりまとめることができ、決済時における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００１８】
上記決済サーバは、収支が確定するまでの残高を、当該残高情報の残高に当該債権額を加算して更に当該供託情報の供託額を控除した額として管理する残高管理部をさらに備えてもよい。この場合、残高管理部が、供託額および債権額を考慮した残高を管理するため、決済時に残高不足となるような支払いの発生を未然に防止することができる。
【００１９】
前記残高情報記憶部は、特定の用途で支払い可能となる特定用途残高を含む残高情報を記憶し、
前記供託情報記憶部は、特定の用途に向けた供託額を含む供託情報を記憶し、
前記債権情報記憶部は、特定の用途に向けた債権額を含む債権情報を記憶し、
前記決済額算出部は、当該特定の用途に向けた供託額と当該特定の用途に向けた債権額とを相殺し、特定用途の決済額を算出し、
前記決済部は、当該算出された特定用途の決済額に基づいて、当該特定用途残高を更新してもよい。この場合、特定の用途として規定された額を、適切に使用することができる。
【００２０】
本発明の第３の観点に係る決済管理システムは、複数の端末と通信可能に接続されたゲームサーバと、当該ゲームサーバと通信可能に接続された決済サーバと、を備える決済管理システムであって、以下のように構成する。
【００２１】
ゲームサーバは、ゲーム制御部、および、処理依頼部を備える。
まず、ゲーム制御部は、接続された各端末との間で行われるゲームを制御する。また、処理依頼部は、少なくともゲーム開始時に徴収される支払い金および、ゲーム終了時に払い戻される払い戻し金の処理を前記決済サーバに依頼する。
【００２２】
一方、決済サーバは、残高情報記憶部、供託情報記憶部、供託情報更新部、および、決済部を備える。
まず、残高情報記憶部は、たとえば、電子マネーの支払い可能となる残高を管理する残高情報を記憶する。供託情報記憶部は、収支が確定するまでにゲームサーバにて発生した支払い金を供託額として管理する供託情報を記憶する。また、供託情報更新部は、収支が確定するまでに前記ゲームサーバにて発生した払い戻し金を、当該供託情報の供託額と相殺する。たとえば、供託額と払い戻し分（払い戻し額）とが同額である場合に、供託情報更新部は、当該供託情報を供託情報記憶部から削除する。そして、決済部は、収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する。
【００２３】
このように、払い戻し分が供託額と相殺されるため、その分の決済を省くことができ、決済時の出納処理（入出金処理）の処理件数を適切に削減することができる。
【００２４】
本発明の第４の観点に係る決済管理システムは、複数の端末と通信可能に接続されたゲームサーバと、当該ゲームサーバと通信可能に接続された決済サーバと、を備える決済管理システムであって、以下のように構成する。
【００２５】
ゲームサーバは、ゲーム制御部、および、処理依頼部を備える。
まず、ゲーム制御部は、接続された各端末との間で行われるゲームを制御する。また、処理依頼部は、少なくともゲーム開始時に徴収される支払い金および、ゲーム終了時に払い戻される払い戻し金の処理を前記決済サーバに依頼する。
【００２６】
一方、決済サーバは、残高情報記憶部、供託情報記憶部、債権情報記憶部、決済額算出部、および、決済部を備える。
まず、残高情報記憶部は、たとえば、電子マネーの支払い可能となる残高を管理する残高情報を記憶する。供託情報記憶部は、収支が確定するまでにゲームサーバにて発生した支払い分を供託額として管理する供託情報を記憶する。債権情報記憶部は、収支が確定するまでにゲームサーバにて発生した払い戻し分を債権額として管理する債権情報を記憶する。また、決済額算出部は、収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する。そして、決済部は、当該算出された決済額に基づいて、当該残高情報の残高を更新する。
【００２７】
このように、収支が確定するまでに発生した供託額と債権額とを相殺してとりまとめることができ、決済時における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００２８】
本発明の第５の観点に係る決済管理方法は、支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、供託額を管理する供託情報を記憶する供託情報記憶部とを用いる決済管理方法であって、供託情報格納ステップ、供託情報更新ステップ、および、決済ステップを備え、以下のように構成する。
【００２９】
まず、供託情報格納ステップは、収支が確定するまでに発生した支払い分を供託額とした供託情報を供託情報記憶部に格納する。また、供託情報更新ステップは、収支が確定するまでに発生した払い戻し分を、当該供託情報の供託額と相殺する。たとえば、供託額と払い戻し分（払い戻し額）とが同額である場合に、供託情報更新ステップは、当該供託情報を供託情報記憶部から削除する。そして、決済ステップは、収支を確定する際に、相殺後の当該供託情報に基づいて、当該残高情報の残高を更新する。
【００３０】
このように、払い戻し分が供託額と相殺されるため、その分の決済を省くことができ、決済時における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００３１】
本発明の第６の観点に係る決済管理方法は、支払い可能となる残高を管理する残高情報を記憶する残高情報記憶部と、供託額を管理する供託情報を記憶する供託情報記憶部と、債権額を管理する債権情報を記憶する債権情報記憶部とを用いる決済管理方法であって、供託情報格納ステップ、債権情報格納ステップ、決済額算出ステップ、および、決済ステップを備え、以下のように構成する。
【００３２】
まず、供託情報格納ステップは、収支が確定するまでに発生した支払い分を供託額とした供託情報を供託情報記憶部に格納する。債権情報格納ステップは、収支が確定するまでに発生した払い戻し分を債権額とした債権情報を債権情報記憶部に格納する。また、決済額算出ステップは、収支を確定する際に、当該供託情報の供託額と当該債権情報の債権額とを相殺し、とりまとめた決済額を算出する。そして、決済ステップは、当該算出された決済額に基づいて、当該残高情報の残高を更新する。
【００３３】
このように、収支が確定するまでに発生した供託額と債権額とを相殺してとりまとめることができ、決済時における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００３４】
本発明の第７の観点に係るプログラムは、コンピュータ（電子機器を含む。）を、上記の決済サーバとして機能させるように構成する。
【００３５】
このプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記録媒体に記録することができる。
【００３６】
上記プログラムは、当該プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記録媒体は、当該コンピュータとは独立して配布・販売することができる。
【発明の効果】
【００３７】
本発明によれば、適切な決済を行うことができる。
【発明を実施するための最良の形態】
【００３８】
以下に本発明の実施形態を説明する。以下では、理解を容易にするため、ゲーム装置に本発明が適用される実施形態を説明するが、各種のコンピュータ、ＰＤＡ、携帯電話などの情報処理装置においても同様に本発明を適用することができる。すなわち、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素または全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【００３９】
（実施形態１）
図１は、本発明の第１の実施の形態に係る決済管理システムの概要構成の一例を示す模式図である。以下、本図を参照して説明する。
【００４０】
本決済管理システム１０は、一例として、ネットワークゲームにおける決済を管理するシステムであり、インターネット１４上にゲームの実行等を制御するゲームサーバ１１が配置されている。なお、ゲームサーバ１１には、電子マネーの残高を管理する決済サーバ１２が接続されている。そして、本決済管理システム１０における複数の端末１３は、インターネット１４を介してゲームサーバ１１と通信可能に接続されている。なお、端末１３同士の通信は、いわゆるピアツーピア通信技術によって行うことも可能である。理解を容易にするため、以下では、端末１３としてインターネットへの接続が可能なゲーム装置を一例にあげて、説明する。
【００４１】
図２は、本実施形態の端末１３として機能するゲーム装置の概要構成を示す模式図である。以下、本図を参照して説明する。
【００４２】
ゲーム装置１００は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、インターフェース１０４と、コントローラ１０５と、外部メモリ１０６と、ＤＶＤ（Digital Versatile Disk）−ＲＯＭドライブ１０７と、画像処理部１０８と、音声処理部１０９と、ＮＩＣ（Network Interface Card）１１０と、を備える。
【００４３】
なお、ゲーム用のプログラムおよびデータを記憶したＤＶＤ−ＲＯＭをＤＶＤ−ＲＯＭドライブ１０７に装着して、ゲーム装置１００の電源を投入することにより、当該プログラムが実行され、本実施形態の端末が実現される。
【００４４】
ＣＰＵ  １０１は、ゲーム装置１００全体の動作を制御し、各構成要素と接続され制御信号やデータをやりとりする。
【００４５】
ＲＯＭ  １０２には、電源投入直後に実行されるＩＰＬ（Initial Program Loader）が記録され、これが実行されることにより、ＤＶＤ−ＲＯＭに記録されたプログラムをＲＡＭ  １０３に読み出してＣＰＵ  １０１による実行が開始される。また、ＲＯＭ  １０２には、ゲーム装置１００全体の動作制御に必要なオペレーティングシステムのプログラムや各種のデータが記録される。
【００４６】
ＲＡＭ  １０３は、データやプログラムを一時的に記憶するためのもので、ＤＶＤ−ＲＯＭから読み出したプログラムやデータ、その他ゲームの進行やチャット通信に必要なデータが保持される。
【００４７】
インターフェース１０４を介して接続されたコントローラ１０５は、ユーザがゲーム実行の際に行う操作入力を受け付ける。たとえば、コントローラ１０５は、操作入力に従って、文字列（メッセージ）等の入力を受け付ける。
【００４８】
インターフェース１０４を介して着脱自在に接続された外部メモリ１０６には、ゲームの進行状態を示すデータ、チャット通信のログ（記録）のデータなどが書き換え可能に記憶される。ユーザは、コントローラ１０５を介して指示入力を行うことにより、これらのデータを適宜外部メモリ１０６に記録することができる。
【００４９】
ＤＶＤ−ＲＯＭドライブ１０７に装着されるＤＶＤ−ＲＯＭには、ゲームを実現するためのプログラムとゲームに付随する画像データや音声データが記録される。ＣＰＵ  １０１の制御によって、ＤＶＤ−ＲＯＭドライブ１０７は、これに装着されたＤＶＤ−ＲＯＭに対する読み出し処理を行って、必要なプログラムやデータを読み出し、これらはＲＡＭ  １０３等に一時的に記憶される。
【００５０】
画像処理部１０８は、ＤＶＤ−ＲＯＭから読み出されたデータをＣＰＵ  １０１や画像処理部１０８が備える画像演算プロセッサ（図示せず）によって加工処理した後、これを画像処理部１０８が備えるフレームメモリ（図示せず）に記録する。フレームメモリに記録された画像情報は、所定の同期タイミングでビデオ信号に変換され画像処理部１０８に接続されるモニタ（図示せず）へ出力される。これにより、各種の画像表示が可能となる。
【００５１】
なお、画像演算プロセッサは、２次元の画像の重ね合わせ演算やαブレンディング等の透過演算、各種の飽和演算を高速に実行できる。
また、仮想３次元空間に配置され、各種のテクスチャ情報が付加されたポリゴン情報を、Ｚバッファ法によりレンダリングして、所定の視点位置から仮想３次元空間に配置されたポリゴンを俯瞰したレンダリング画像を得る演算の高速実行も可能である。
【００５２】
さらに、ＣＰＵ  １０１と画像演算プロセッサが協調動作することにより、文字の形状を定義するフォント情報にしたがって、文字列を２次元画像としてフレームメモリへ描画したり、各ポリゴン表面へ描画することが可能である。フォント情報は、ＲＯＭ  １０２に記録されているが、ＤＶＤ−ＲＯＭに記録された専用のフォント情報を利用することも可能である。
【００５３】
音声処理部１０９は、ＤＶＤ−ＲＯＭから読み出した音声データをアナログ音声信号に変換し、これに接続されたスピーカ（図示せず）から出力させる。また、ＣＰＵ  １０１の制御の下、ゲームの進行の中で発生させるべき効果音や楽曲データを生成し、これに対応した音声をスピーカから出力させる。
【００５４】
ＮＩＣ  １１０は、ゲーム装置１００をインターネット等のコンピュータ通信網（図示せず）に接続するためのものであり、ＬＡＮ（Local Area Network）を構成する際に用いられる１０ＢＡＳＥ−Ｔ／１００ＢＡＳＥ−Ｔ規格にしたがうものや、電話回線を用いてインターネットに接続するためのアナログモデム、ＩＳＤＮ（Integrated Services Digital Network）モデム、ＡＤＳＬ（Asymmetric Digital Subscriber Line）モデム、ケーブルテレビジョン回線を用いてインターネットに接続するためのケーブルモデム等と、これらとＣＰＵ  １０１との仲立ちを行うインターフェース（図示せず）により構成される。
【００５５】
このほか、ゲーム装置１００は、ハードディスク等の大容量外部記憶装置を用いて、ＲＯＭ  １０２、ＲＡＭ  １０３、外部メモリ１０６、ＤＶＤ−ＲＯＭドライブ１０７に装着されるＤＶＤ−ＲＯＭ等と同じ機能を果たすように構成してもよい。
また、ユーザからの文字列の編集入力を受け付けるためのキーボードや、各種の位置の指定および選択入力を受け付けるためのマウスなどを接続する形態も採用することができる。
【００５６】
また、本実施形態のゲーム装置１００にかえて、一般的なコンピュータ（汎用のパーソナルコンピュータ等）を利用することもできる。たとえば、一般的なコンピュータは、上記ゲーム装置１００と同様に、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＤＶＤ−ＲＯＭドライブ、および、ＮＩＣを備え、ゲーム装置１００よりも簡易な機能を備えた画像処理部を備え、外部記憶装置としてハードディスクを有する他、フレキシブルディスク、光磁気ディスク、磁気テープ等が利用できるようになっている。また、コントローラではなく、キーボードやマウスなどを入力装置として利用する。
【００５７】
ネットワークゲームでは、ゲーム専用機だけでなく一般的なコンピュータを利用することも多々あることも考慮し、以下では、注記しない限り、端末について、図２に示したゲーム装置１００により説明を加える。これらは必要に応じて、適宜、一般的なコンピュータの要素に置換することができ、これらの実施形態も本発明の範囲に含まれる。
【００５８】
また、ゲームサーバ１１および、決済サーバ１２は、一般的なコンピュータ上に実現されるが、ゲーム装置１００の群の中の所定のゲーム装置１００をゲームサーバ１１および、決済サーバ１２として利用することも可能である。そして、ゲーム装置１００と一般的なコンピュータとは、その構成や機能に大きな相違はない。つまり、本発明のゲームサーバ１１および、決済サーバ１２をゲーム装置１００にて実現することも可能である。そこで、以下の説明では、一般的なコンピュータとゲーム装置１００とを同じように扱って説明する。
【００５９】
（ゲームサーバの構成および動作）
図３は、本実施形態に係るゲームサーバ１１の概要構成の一例を示す模式図である。図４は、当該ゲームサーバ１１にて実行されるゲーム制御処理の流れを示すフローチャートである。以下、これらの図を参照して説明する。
なお、一例として、ゲームサーバ１１が、複数のユーザ間（複数の端末１３）で行われる対戦ゲームを制御する場合について説明する。そして、ユーザが対戦ゲームをプレイする際に、所定額の参加料が必要となり、そして、ゲームの勝者には、その参加料が払い戻されるものとする。
【００６０】
図３に示すように、ゲームサーバ１１は、認証部２０１、ユーザ情報記憶部２０２、ゲーム制御部２０３、ゲーム情報記憶部２０４、および、課金管理部２０５を有する。
【００６１】
認証部２０１は、ユーザの認証前において、端末１３から送られるログイン情報を受信し、ユーザ情報記憶部２０２に記憶される情報を使用して、そのユーザを認証する。
たとえば、認証部２０１は、ユーザＩＤおよび、パスワードを含むログイン情報を受信すると、ユーザ情報記憶部２０２に記憶されるユーザ情報と照合し、一致した場合にだけユーザを認証できる。
【００６２】
ユーザ情報記憶部２０２は、各ユーザに関するユーザ情報をあらかじめ記憶する。
たとえば、ユーザ情報記憶部２０２は、ユーザを識別するためのユーザＩＤ、パスワード、ハンドルネーム、および、そのユーザが使用する電子マネーを識別するためのマネーＩＤ等を含むユーザ情報を記憶する。
【００６３】
ゲーム制御部２０３は、認証部２０１が認証したユーザ（端末１３）との間で、所定の情報をやりとりする。
たとえば、ゲーム制御部２０３は、ゲームをプレイするユーザ（プレイヤ）の各端末１３から送られる指示情報をそれぞれ受信し、受信した指示情報にしたがって対戦ゲームを制御する。そして、制御結果（ゲーム進行状況等）を示す情報を、各端末１３に逐次送信する。
【００６４】
ゲーム情報記憶部２０４は、各プレイヤに関する情報、および、各プレイヤの端末１３のネットワーク情報等を記憶する。
たとえば、ゲーム情報記憶部２０４は、各プレイヤのユーザＩＤおよび、ハンドルネーム等を記憶し、また、各端末１３のＩＰアドレスおよび、ＭＡＣアドレス等を記憶する。この他にも、ゲーム情報記憶部２０４には、対戦ゲームを制御する際に必要となる種々の情報も記憶される。
【００６５】
課金管理部２０５は、プレイヤの参加料の供託を決済サーバ１２に依頼する。また、ゲームが終了した際に、勝利したプレイヤへの参加料の払い戻し（供託のキャンセル）を、決済サーバ１２に依頼する。そして、決済処理の実行を決済サーバ１２に依頼する。
【００６６】
このような構成のゲームサーバ１１は、ユーザが操作する端末１３からの要求に応じて、図４に示すゲーム制御処理を実行する。以下、このゲーム制御処理について説明する。
【００６７】
まず、認証部２０１は、ユーザの認証前において、端末１３から送られ得るログイン情報を受信するまで待機する（ステップＳ３０１；Ｎｏ）。
たとえば、認証部２０１は、対戦ゲームをプレイしようとするユーザに操作された端末１３からアクセスされ、そして、ユーザＩＤおよび、パスワード等を含んだログイン情報が、端末１３から送られるまで待機する。
【００６８】
認証部２０１は、ログイン情報を受信すると（ステップＳ３０１；Ｙｅｓ）、ユーザ情報記憶部２０２に記憶されたユーザ情報を用いて、ユーザの認証を行う（ステップＳ３０２）。
そして、ユーザが認証されると、認証部２０１は、ユーザの端末１３のネットワーク情報（ＩＰアドレスおよびＭＡＣアドレス等）をゲーム制御部２０３に通知し、ゲーム制御部２０３とその端末１３との通信を許可する。また、ユーザ情報記憶部２０２に登録されているマネーＩＤが、そのユーザが使用する電子マネーとして特定される。
なお、パスワードが不正である等によりユーザが認証されなかった場合に、認証部２０１は、認証できない旨のメッセージを端末１３に送信し、再度ログイン情報の受信を待機する。
【００６９】
ユーザが認証された後、ゲーム制御部２０３は、課金管理部２０５を介して決済サーバ１２から残高情報を取得する（ステップＳ３０３）。
たとえば、課金管理部２０５は、マネーＩＤを含んだ残高参照依頼情報を決済サーバ１２に送信し、電子マネーの残高情報の返信を依頼する。これに応答して、決済サーバ１２は、後述する残高管理ＤＢ４０３から対象の残高情報を読み出し、課金管理部２０５に返送する。そして、課金管理部２０５は、残高情報を受信すると、ゲーム制御部２０３に供給する。
【００７０】
ゲーム制御部２０３は、残高情報に基づいて、電子マネーの残高が十分であるか否かを判別する（ステップＳ３０４）。つまり、残高情報の現在残高が、参加料以上であるか否かを判別する。
【００７１】
ゲーム制御部２０３は、電子マネーの残高が十分でないと判別すると（ステップＳ３０４；Ｎｏ）、そのユーザにゲームへの参加を認めずに、上述のステップＳ３０１に処理を戻す。
【００７２】
一方、電子マネーの残高が十分であると判別した場合に（ステップＳ３０４；Ｙｅｓ）、ゲーム制御部２０３は、プレイヤの登録を行い、課金管理部２０５を制御して参加料を供託する（ステップＳ３０５）。
たとえば、課金管理部２０５は、ゲーム番号、マネーＩＤ、発生日時、および、供託額（参加料）を含んだ供託依頼情報を生成して、決済サーバ１２に送信する。これに応答して、決済サーバ１２は、後述する供託管理ＤＢ４０４に供託情報を記憶させる。
なお、プレイヤの登録の際に、ゲーム情報記憶部２０４には、ユーザＩＤ、ハンドルネーム、および、端末１３のＩＰアドレス等が記憶される。
【００７３】
ゲーム制御部２０３は、対戦ゲームが開始可能であるか否かを判別する（ステップＳ３０６）。
たとえば、ゲーム制御部２０３は、プレイヤが必要人数分登録され、各プレイヤの端末１３との通信状態が良好である場合に、対戦ゲームが開始可能であると判別する。
ゲーム制御部２０３は、ゲームが開始可能でないと判別すると（ステップＳ３０６；Ｎｏ）、ステップＳ３０１に処理を戻し、上述のステップＳ３０１〜Ｓ３０６の処理を繰り返し実行する。
【００７４】
一方、ゲームが開始可能であると判別した場合に（ステップＳ３０６；Ｙｅｓ）、ゲーム制御部２０３は、対戦ゲームを開始し、各プレイヤの端末１３から送られる指示情報に従って、対戦ゲームを制御する（ステップ３０７）。
この際、ゲーム制御部２０３は、制御している対戦ゲームの進行状況等を示す情報を、各プレイヤの端末１３に向けてそれぞれ送信する。
【００７５】
ゲーム制御部２０３は、対戦ゲームが終了したか否かを判別する（ステップＳ３０８）。
たとえば、対戦ゲームのルールに基づいて、勝敗の決着がついたか否かを判別する。
ゲーム制御部２０３は、ゲームが終了していないと判別すると（ステップＳ３０８；Ｎｏ）、ステップＳ３０７にて対戦ゲームの制御を続ける。
【００７６】
一方、ゲームが終了したと判別した場合に（ステップＳ３０８；Ｙｅｓ）、ゲーム制御部２０３は、課金管理部２０５を介して、勝者の供託をキャンセルした後、決済を依頼する（ステップＳ３０９）。
たとえば、課金管理部２０５は、ゲーム番号、および、勝者のマネーＩＤを含むキャンセル依頼情報を生成して、決済サーバ１２に送信する。これに応答して、決済サーバ１２は、後述する供託管理ＤＢ４０４から対象の供託情報を削除する。
続けて、課金管理部２０５は、ゲーム番号を含む決済依頼情報を生成して、決済サーバ１２に送信する。これに応答して、決済サーバ１２は、後述する供託管理ＤＢ４０４に記憶された対象の供託情報を使用して、後述する残高管理ＤＢ４０３を更新する。
【００７７】
このようなゲーム制御処理により、ゲームサーバ１１は、ゲームが終了するまで、参加料を一時的に供託し、ゲームが終了して勝者に参加料の払い戻し（供託のキャンセル）を行った後に、決済を依頼する。
このため、相殺される分（勝者の参加料）の決済を省くことができ、決済サーバ１２における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００７８】
（決済サーバの構成および動作）
図５は、本実施形態に係る決済サーバ１２の概要構成の一例を示す模式図である。図６は、当該決済サーバ１２の残高管理ＤＢ（データベース）４０３に記憶される残高情報の一例を示す模式図である。図７は、当該決済サーバ１２の供託管理ＤＢ４０４に記憶される供託情報の一例を示す模式図である。
また、図８は、当該決済サーバ１２にて実行される決済管理処理の流れを示すフローチャートである。以下、これらの図を参照して説明する。
【００７９】
図５に示すように、決済サーバ１２は、依頼受付部４０１、決済制御部４０２、残高管理ＤＢ４０３、供託管理ＤＢ４０４、および、残高情報送信部４０５を有する。
【００８０】
依頼受付部４０１は、ゲームサーバ１１から送られる各種依頼情報を受け付ける。たとえば、依頼受付部４０１は、電子マネーの残高参照を依頼する残高参照依頼情報、参加料等の供託を依頼する供託依頼情報、供託のキャンセルを依頼するキャンセル情報、および、決済を依頼する決済依頼情報等を受け付ける。そして、受け付けた依頼情報を決済制御部４０２に供給する。
【００８１】
決済制御部４０２は、依頼受付部４０１を介してゲームサーバ１１から供給された依頼情報に応答して、所定の処理を実行する。
たとえば、決済制御部４０２は、残高参照が依頼された際に、残高管理ＤＢ４０３から対象の電子マネーの残高情報を読み出し、残高情報送信部４０５を介して、ゲームサーバ１１に送信する。
また、供託が依頼された際に、供託管理ＤＢ４０４に供託情報を追加して記憶する。なお、供託のキャンセルが依頼された際に、供託管理ＤＢ４０４から対象の供託情報を削除する。
さらに、決済が依頼された際に、供託管理ＤＢ４０４に記憶している供託情報に基づいて、残高管理ＤＢ４０３における対象となる電子マネーの残高情報を更新する。
【００８２】
残高管理ＤＢ４０３は、たとえば、図６に示すように、各電子マネーの残高等を管理するための残高情報を記憶する。
この残高情報は、電子マネーを識別するためのマネーＩＤ、電子マネーの現在の残高を示す現在残高、および、換金（現金化）する場合の上限を規定する購入時残高等からなる。
【００８３】
供託管理ＤＢ４０４は、図７に示すように、たとえば、供託内容を管理するための供託情報を記憶する。
この供託情報は、ゲーム毎に採番されるユニークなゲーム番号、電子マネーを識別するためのマネーＩＤ、供託の発生日時、および、発生した供託額（参加料等）等からなる。
【００８４】
図５に戻って、残高情報送信部４０５は、残高参照が依頼され、決済制御部４０２により残高管理ＤＢ４０３から対象の残高情報が読み出された際に、その残高情報をゲームサーバ１１に送信する。
【００８５】
このような構成の決済サーバ１２は、残高管理ＤＢ４０３にて購入時残高を記憶しており、電子マネーの現在残高を換金（現金化）する場合に、購入時残高より高い額を換金できないようにし、ギャンブルのような利益をユーザにもたらすのを防止する。なお、換金した後には、購入時残高がその分減算される。また、追加購入等がされるとその分だけ、購入時残高が増加する。
【００８６】
また、決済サーバ１２は、上述したゲーム制御処理を実行するゲームサーバ１１から送られる依頼情報に応答して、図８に示す決済管理処理を逐次実行する。以下、この決済管理処理について説明する。
【００８７】
まず、依頼受付部４０１は、ゲームサーバ１１から送られる依頼情報を受信する（ステップＳ５０１）。依頼受付部４０１は、受信した依頼情報を決済制御部４０２に供給する。
【００８８】
決済制御部４０２は、依頼情報が残高の参照を依頼する残高参照依頼情報であるか否かを判別する（ステップ５０２）。
決済制御部４０２は、残高参照依頼情報であると判別すると（ステップＳ５０２；Ｙｅｓ）、残高管理ＤＢ４０３から対象の残高情報を取得する（ステップＳ５０３）。
たとえば、決済制御部４０２は、残高参照依頼情報に含まれるマネーＩＤをキーにして残高管理ＤＢ４０３を検索し、対象となる電子マネーの残高情報を読み出す。
決済制御部４０２は、残高情報を取得すると、残高情報送信部４０５を介して、取得した残高情報をゲームサーバ１１に送信する（ステップ５０４）。
【００８９】
一方、残高参照依頼情報でないと判別した場合に（ステップＳ５０２；Ｎｏ）、決済制御部４０２は、供託を依頼する供託依頼情報であるか否かを判別する（ステップＳ５０５）。
決済制御部４０２は、供託依頼情報であると判別すると（ステップＳ５０５；Ｙｅｓ）、供託管理ＤＢ４０４に供託情報を追加して記憶する（ステップＳ５０６）。
たとえば、決済制御部４０２は、供託依頼情報に基づいて、ゲーム番号、マネーＩＤ、発生日時、および、供託額を含む供託情報を生成し、図７に示すような供託管理ＤＢ４０４に記憶させる。
【００９０】
一方、供託依頼情報でないと判別した場合に（ステップＳ５０５；Ｎｏ）、決済制御部４０２は、供託のキャンセルを依頼するキャンセル依頼情報であるか否かを判別する（ステップＳ５０７）。
決済制御部４０２は、キャンセル依頼情報であると判別すると（ステップＳ５０７；Ｙｅｓ）、供託管理ＤＢ４０４から対象の供託情報を削除する（ステップＳ５０８）。
たとえば、決済制御部４０２は、キャンセル依頼情報に含まれるゲーム番号および、マネーＩＤをキーにして、図７に示すような供託管理ＤＢ４０４を検索し、対象となる供託情報（勝者の供託情報）を削除する。
【００９１】
一方、キャンセル依頼情報でないと判別した場合に（ステップＳ５０７；Ｎｏ）、決済制御部４０２は、決済を依頼する決済依頼情報であるか否かを判別する（ステップＳ５０９）。
決済制御部４０２は、決済依頼情報であると判別すると（ステップＳ５０９；Ｙｅｓ）、供託管理ＤＢ４０４から対象の供託情報を取得する（ステップＳ５１０）。
たとえば、決済制御部４０２は、決済依頼情報に含まれるゲーム番号をキーにして、図７に示すような供託管理ＤＢ４０４を検索し、対象となる全ての供託情報を読み出す。
【００９２】
決済制御部４０２は、読み出した各供託情報にしたがって、残高管理ＤＢ４０３の残高情報を更新する（ステップＳ５１１）。
たとえば、供託制御部４０２は、供託情報のマネーＩＤをキーにして図６に示すような残高管理ＤＢ４０３から対象の残高情報を読み出す。そして、読み出した残高情報の現在残高から供託情報の供託額（参加料）分を減算することにより、現在残高（残高情報）を更新する。
【００９３】
なお、ステップＳ５０９にて決済依頼情報でないと判別した場合に（ステップＳ５０９；Ｎｏ）、決済制御部４０２は、想定された依頼情報でないため、何も処理せずにそのまま決済管理処理を終える。
【００９４】
このような決済管理処理により、決済サーバ１２は、ゲームサーバ１１から依頼された参加料を供託管理ＤＢ４０４において供託情報として管理する。そして、ゲームサーバ１１にてゲームが終了し、勝者への参加料の払い戻し（供託情報の削除）を行った後に、残った供託情報を使用して、決済を行う。
このため、相殺される分（勝者の参加料分の入出金）の決済を省くことができ、決済サーバ１２における出納処理（入出金処理）の処理件数を適切に削減することができる。
【００９５】
（実施形態２）
上記の第１の実施の形態では、ゲームの勝者に参加料をそのまま払い戻す（供託情報をキャンセルする）場合について説明したが、ゲームの勝者に所定額の賞金を払い戻すようにしてもよい。また、上記の第１の実施の形態では、１つのゲームが終了すると同時に決済を行ったが、所定数のゲームが終了する際に、まとめて決済を行うようにしてもよい。
以下、本発明の第２の実施の形態に係る決済管理システムについて説明する。
【００９６】
（ゲームサーバの動作）
本実施の形態では、ゲームサーバ１１は、図３に示す構成と同様である。それでも、ゲームサーバ１１は、図４と異なり、図９に示すゲーム制御処理を実行する。なお、図９のゲーム制御処理では、ユーザ認証の部分を省略しているが、図４と同様にユーザ認証が行われているものとする。以下、図９のゲーム制御処理について説明する。
【００９７】
まず、ゲーム制御部２０３は、ゲームに参加するユーザの端末１３から送られる参加情報を受信するまで待機する（ステップＳ６０１；Ｎｏ）。
ゲーム制御部２０３は、参加情報を受信すると（ステップＳ６０１；Ｙｅｓ）、課金管理部２０５を介して残高情報（供託情報等を考慮した残高情報）の返信を決済サーバ１２に依頼する（ステップＳ６０２）。つまり、マネーＩＤを含んだ残高参照依頼情報を決済サーバ１２に送信する。
【００９８】
これに応答して、決済サーバ１２は、対象の供託情報や債権情報（払い戻される賞金等の情報）を、供託管理ＤＢ４０４や後述する債権管理ＤＢ７０１から検索して、現時点における正確な現在残高を算出し、算出した現在残高を含んだ残高情報を課金管理部２０５に送信する。
【００９９】
ゲーム制御部２０３は、この残高情報に基づいて、電子マネーの残高が十分であるか否かを判別する（ステップＳ６０３）。ゲーム制御部２０３は、電子マネーの残高が十分でないと判別すると（ステップＳ６０３；Ｎｏ）、そのユーザにゲームへの参加を認めずに、上述のステップＳ６０１に処理を戻す。
【０１００】
一方、電子マネーの残高が十分であると判別した場合に（ステップＳ６０３；Ｙｅｓ）、ゲーム制御部２０３は、プレイヤの登録を行い、参加料の供託を決済サーバ１２に依頼する（ステップＳ６０４）。これに応答して、決済サーバ１２は、供託管理ＤＢ４０４に供託情報を追加して記憶する。
【０１０１】
ゲーム制御部２０３は、対戦ゲームが開始可能であるか否かを判別する（ステップ６０５）。ゲーム制御部２０３は、ゲームが開始可能でないと判別すると（ステップＳ６０５；Ｎｏ）、ステップＳ６０１に処理を戻し、上述のステップＳ６０１〜Ｓ６０５の処理を繰り返し実行する。
【０１０２】
一方、ゲームが開始可能であると判別した場合に（ステップＳ６０５；Ｙｅｓ）、ゲーム制御部２０３は、対戦ゲームを開始し、各プレイヤの端末１３から送られる指示情報に従って、対戦ゲームを制御する（ステップ６０６）。
【０１０３】
ゲーム制御部２０３は、対戦ゲームが終了したか否かを判別する（ステップＳ６０７）。ゲーム制御部２０３は、ゲームが終了していないと判別すると（ステップＳ６０７；Ｎｏ）、ステップＳ６０６にてゲームの制御を続ける。
【０１０４】
一方、ゲームが終了したと判別した場合に（ステップＳ６０７；Ｙｅｓ）、ゲーム制御部２０３は、賞金の払い戻しを決済サーバ１２に依頼する（ステップＳ６０８）。
たとえば、課金管理部２０５は、ゲーム番号、マネーＩＤ、発生日時、および、債権額（賞金額）を含んだ債権依頼情報を生成して、決済サーバ１２に送信する。これに応答して、決済サーバ１２は、後述する債権管理ＤＢ７０１に債権情報を追加して記憶する。
【０１０５】
ゲーム制御部２０３は、所定数分のゲームが終了したか否かを判別する（ステップＳ６０９）。
ゲーム制御部２０３は、所定数分のゲームが終了していないと判別すると（ステップＳ６０９；Ｎｏ）、ステップＳ６０１に処理を戻し、上述のステップＳ６０１〜Ｓ６０９の処理を繰り返し実行する。
【０１０６】
一方、所定数分のゲームが終了したと判別した場合に（ステップＳ６０９；Ｙｅｓ）、ゲーム制御部２０３は、決済サーバ１２に決済を依頼する（ステップＳ６１０）。
たとえば、課金管理部２０５は、一連のゲーム番号（所定数分のゲーム番号）を含む決済依頼情報を生成して、決済サーバ１２に送信する。これに応答して、決済サーバ１２は、供託管理ＤＢ４０４および債権管理ＤＢ７０１に記憶された対象の供託情報および債権情報を使用して、残高管理ＤＢ４０３を更新する。
【０１０７】
このようなゲーム制御処理により、ゲームサーバ１１は、決済サーバ１２に参加料を供託情報として管理させ、また、払い戻す賞金を債権情報として管理させる。そして、所定数分のゲームが終了すると、これらの供託情報および債権情報を使用した決済を、決済サーバ１２に依頼する。
【０１０８】
（決済サーバの構成および動作）
図１０は、本実施形態に係る決済サーバ１２の概要構成の一例を示す模式図である。つまり、本実施の形態では、決済サーバ１２は、図５に示す構成に加えて債権管理ＤＢ７０１をさらに備えている。図１１は、当該債権管理ＤＢ７０１に記憶される債権情報の一例を示す模式図である。
また、図１２は、当該決済サーバ１２にて実行される決済管理処理の流れを示すフローチャートである。以下、これらの図を参照して説明する。
【０１０９】
図１０に示すように、決済サーバ１２は、依頼受付部４０１〜残高情報送信部４０５に加え、債権管理ＤＢ７０１をさらに有する。
【０１１０】
債権管理ＤＢ７０１は、図１１に示すように、たとえば、債権内容を管理するための債権情報を記憶する。
この債権情報は、ゲーム毎に採番されるユニークなゲーム番号、電子マネーを識別するためのマネーＩＤ、債権の発生日時、および、発生した債権額等からなる。
【０１１１】
このような構成の決済サーバ１２は、上述した図９のゲーム制御処理を実行するゲームサーバ１１から送られる依頼情報に応答して、図１２に示す決済管理処理を逐次実行する。以下、図１２に示す決済管理処理について説明する。
【０１１２】
まず、依頼受付部４０１は、ゲームサーバ１１から送られる依頼情報を受信する（ステップＳ８０１）。なお、依頼受付部４０１は、賞金の払い戻しを依頼する払い戻し依頼情報も受信する。
【０１１３】
決済制御部４０２は、依頼情報が残高参照依頼情報であるか否かを判別する（ステップ８０２）。
決済制御部４０２は、残高参照依頼情報であると判別すると（ステップＳ８０２；Ｙｅｓ）、残高管理ＤＢ４０３から対象の残高情報を取得する（ステップＳ８０３）。
【０１１４】
続けて、決済制御部４０２は、供託管理ＤＢ４０４から供託情報を検索する（ステップＳ８０４）。
たとえば、決済制御部４０２は、残高参照依頼情報に含まれるマネーＩＤをキーにして供託管理ＤＢ４０４を検索し、検索された供託情報を読み出す。なお、複数の供託情報が検索された場合に、それぞれの供託情報を読み出す。
【０１１５】
さらに、決済制御部４０２は、債権管理ＤＢ７０１から債権情報を検索する（ステップＳ８０５）。
たとえば、決済制御部４０２は、同様にマネーＩＤをキーにして債権管理ＤＢ７０１を検索し、検索された債権情報を読み出す。なお、複数の債権情報が検索された場合に、それぞれの債権情報を読み出す。
【０１１６】
決済制御部４０２は、読み出した供託情報や債権情報に基づいて残高情報（現在残高）を修正し、残高情報送信部４０５を介して、修正後の残高情報をゲームサーバ１１に送信する（ステップ８０６）。なお、供託情報や債権情報が検索されなかった場合には、残高情報（現在残高）を修正することなく、ゲームサーバ１１に送信する。
【０１１７】
また、ステップＳ８０２にて、残高参照依頼情報でないと判別した場合に（ステップＳ８０２；Ｎｏ）、決済制御部４０２は、依頼情報が供託依頼情報であるか否かを判別する（ステップＳ８０７）。
決済制御部４０２は、供託依頼情報であると判別すると（ステップＳ８０７；Ｙｅｓ）、供託管理ＤＢ４０４に供託情報を追加して記憶する（ステップＳ８０８）。
【０１１８】
一方、供託依頼情報でないと判別した場合に（ステップＳ８０７；Ｎｏ）、決済制御部４０２は、賞金の払い戻しを依頼する払い戻し依頼情報であるか否かを判別する（ステップＳ８０９）。
決済制御部４０２は、払い戻し依頼情報であると判別すると（ステップＳ８０９；Ｙｅｓ）、債権管理ＤＢ７０１に債権情報を追加して記憶する（ステップＳ８１０）。
たとえば、決済制御部４０２は、払い戻し依頼情報にしたがって、ゲーム番号、マネーＩＤ、発生日時、および、債権額を含む債権情報を生成し、図１１に示すような債権管理ＤＢ７０１に記憶させる。
【０１１９】
一方、払い戻し依頼情報でないと判別した場合に（ステップＳ８０９；Ｎｏ）、決済制御部４０２は、依頼情報が決済依頼情報であるか否かを判別する（ステップＳ８１１）。
決済制御部４０２は、決済依頼情報であると判別すると（ステップＳ８１１；Ｙｅｓ）、供託管理ＤＢ４０４から複数の供託情報を取得する（ステップＳ８１２）。
たとえば、決済制御部４０２は、決済依頼情報に含まれる一連のゲーム番号をキーにして、供託管理ＤＢ４０４を検索し、対象となる全ての供託情報を読み出す。
【０１２０】
続いて、決済制御部４０２は、債権管理ＤＢ７０１から複数の債権情報を取得する（ステップＳ８１３）。
たとえば、決済制御部４０２は、同様に一連のゲーム番号をキーにして、債権管理ＤＢ７０１を検索し、対象となる全ての債権情報を読み出す。
【０１２１】
決済制御部４０２は、同一のマネーＩＤとなる供託情報（供託額）と債権情報（債権額）とを突き合わせて相殺し、各決済情報をそれぞれ生成する（ステップＳ８１４）。つまり、マネーＩＤ単位に供託額および債権額をそれぞれ集計し、集計した債権額から集計した供託額を減算することにより、各電子マネーの決済額を算出する。この場合、決済額がマイナスの場合に出金の決済情報となり、逆に、決済額がプラスの場合に入金の決済情報となる。なお、決済額が丁度ゼロとなった場合には、決済情報を生成しなくともよい。
【０１２２】
そして、決済制御部４０２は、生成された各決済情報に基づいて、残高管理ＤＢ４０３の残高情報を更新する（ステップＳ８１５）。つまり、該当する各残高情報の現在残高をそれぞれ更新する。
【０１２３】
なお、ステップＳ８１１にて、決済依頼情報でないと判別した場合に（ステップＳ８１１；Ｎｏ）、決済制御部４０２は、想定された依頼情報でないため、何も処理せずにそのまま決済管理処理を終える。
【０１２４】
このような決済管理処理により、決済サーバ１２は、参加料を供託管理ＤＢ４０４に供託情報として管理し、また、払い戻される賞金を債権管理ＤＢ７０１に債権情報として管理する。そして、ゲームサーバ１１にて所定数のゲームが終了した後に、これら供託情報および債権情報を突き合わせて相殺し、とりまとめた決済を行う。
このため、各電子マネーに対して、決済額を１つにまとめることができ、決済サーバ１２における出納処理（入出金処理）の処理件数を適切に削減することができる。
【０１２５】
（他の実施形態）
上記の第２の実施の形態では、ゲームサーバ１１にて所定数分のゲームが終了する度に、決済サーバ１２に決済を依頼する場合について説明したが、決済サーバ１２が自ら決済期限を管理し、期限経過のタイミングにて決済を行うようにしてもよい。
たとえば、決済サーバ１２は、月末時に、月中に生じた供託情報および債権情報を使用して、各電子マネーを一括して決済してもよい。
以下、本発明の他の実施の形態に係る決済サーバの決済動作について説明する。
【０１２６】
（決済サーバの決済動作）
本実施の形態では、決済サーバ１２は、図１０に示す構成と同様である。それでも、決済サーバ１２は、月末時に、図１３に示すような一括決済処理を実行する。以下、この一括決済処理について説明する。
【０１２７】
まず、決済制御部４０２は、残高管理ＤＢ４０３から所定の順番に従って、１つの残高情報を取得する（ステップＳ９０１）。
決済制御部４０２は、取得した残高情報に含まれるマネーＩＤをキーにして、供託管理ＤＢ４０４から供託情報を検索する（ステップＳ９０２）。
【０１２８】
決済制御部４０２は、供託情報が検索されたか否かを判別する（ステップＳ９０３）。決済制御部４０２は、供託情報が１つも検索されなかったと判別すると（ステップＳ９０４；Ｎｏ）、集計する供託額をゼロにする（ステップＳ９０４）。
一方、供託情報が検索されたと判別した場合に（ステップＳ９０３；Ｙｅｓ）、決済制御部４０２は、検索された各供託情報から供託額を集計する（ステップＳ９０５）。
【０１２９】
同様に決済制御部４０２は、マネーＩＤをキーにして、債権管理ＤＢ７０１から債権情報を検索する（ステップＳ９０６）。決済制御部４０２は、債権情報が検索されたか否かを判別する（ステップＳ９０７）。
【０１３０】
決済制御部４０２は、債権情報が１つも検索されなかったと判別すると（ステップＳ９０７；Ｎｏ）、集計する債権額をゼロにする（ステップＳ９０８）。
一方、債権情報が検索されたと判別すると（ステップＳ９０７；Ｙｅｓ）、決済制御部４０２は、検索された各債権情報から債権額を集計する（ステップＳ９０９）。
【０１３１】
決済制御部４０２は、決済額を算出し、残高情報を更新する（ステップＳ９１０）。
具体的に決済制御部４０２は、集計した債権額から供託額を減算して、月中の決済額をひとまとめにした決済額を算出する。
なお、決済額がマイナスの場合に、出金の決済情報となり、逆に、決済額がプラスの場合に、入金の決済情報となる。
そして、決済管理部４０２は、算出した決済額に基づいて、残高管理ＤＢ４０３の残高情報（現在残高）を更新する。なお、決済額がゼロの場合、決済を行わなくともよい。
【０１３２】
決済管理部４０２は、全ての決済を終えたか否かを判別する（ステップＳ９１１）。決済管理部４０２は、全ての決済を終えていないと判別すると（ステップＳ９１１；Ｎｏ）、ステップＳ９０１に処理を戻し、上述のステップＳ９０１〜Ｓ９１１の処理を繰り返し実行する。
一方、全ての決済を終えたと判別した場合に（ステップＳ９１１；Ｙｅｓ）、決済管理部４０２は、一括決済処理を終える。
【０１３３】
このような一括決済処理により、決済サーバ１２は、月中に生じた参加料および賞金を突き合わせて相殺し、電子マネー単位に決済額をひとまとめにする。そして、このようにまとめた決済額に基づいて決済を行うため、出納処理（入出金処理）の処理件数を適切に削減することができる。
【０１３４】
上記の実施の形態では、ゲームの勝者に賞金が払い戻される場合について説明したが、賞金の代わりに、賞品分の額（特定の用途に使用が限定される額）が払い戻される場合や、用途の限定される額が供託された（使用された）場合にも適宜適用可能である。
この場合、残高管理ＤＢ４０３にて管理される残高情報には、図１４（ａ）に示すように、用途の限定される残高（たとえば、用途Ａ残高や用途Ｂ残高等）が別途含まれている。
また、供託管理ＤＢ４０４にて管理される供託情報には、図１４（ｂ）に示すように、用途の限定される供託額（たとえば、用途Ａや用途Ｂ等）が別途含まれており、同様に、債権管理ＤＢ７０１にて管理される債権情報には、図１４（ｃ）に示すように、用途の限定される債権額（たとえば、用途Ａや用途Ｂ等）が別途含まれている。
【０１３５】
そして、決済サーバ１２は、上述した図１２の決済管理処理（決済時）や、上述した図１３の一括決済処理を実行する際に、これら用途の限定されるもの同士を突き合わせて決済を行う。たとえば、供託情報の用途Ａの供託額と債権情報の用途Ａの債権額とを突き合わせて相殺し、用途Ａ分がまとめられた決済額を算出する。同様に、用途Ｂの供託額と用途Ｂの債権額とを突き合わせて相殺し、用途Ｂ分がまとめられた決済額を算出する。そして、残高情報の用途の限定される残高を更新する。なお、用途の限定される残高が足りなくなった場合には、用途の限定されていない現在残高から補充されて決済される。
【０１３６】
以上説明したように、本発明によれば、適切な決済を行うことができる。
【図面の簡単な説明】
【０１３７】
【図１】本実施形態の決済管理システムの概要構成を示す模式図である。
【図２】ゲーム装置の概要構成の一例を示す模式図である。
【図３】第１の実施の形態に係るゲームサーバの概要構成の一例を示す模式図である。
【図４】当該ゲームサーバにて実行されるゲーム制御処理の流れを示すフローチャートである。
【図５】第１の実施の形態に係る決済サーバの概要構成の一例を示す模式図である。
【図６】当該決済サーバの残高管理ＤＢに記憶される残高情報の一例を示す模式図である。
【図７】当該決済サーバの供託管理ＤＢに記憶される供託情報の一例を示す模式図である。
【図８】当該決済サーバにて実行される決済管理処理の流れを示すフローチャートである。
【図９】第２の実施の形態に係るゲームサーバにて実行されるゲーム制御処理の流れを示すフローチャートである。
【図１０】第２の実施の形態に係る決済サーバの概要構成の一例を示す模式図である。
【図１１】当該決済サーバの債権管理ＤＢに記憶される債権情報の一例を示す模式図である。
【図１２】当該決済サーバにて実行される決済管理処理の流れを示すフローチャートである。
【図１３】当該決済サーバにて実行される一括決済処理の流れを示すフローチャートである。
【図１４】他の実施の形態に係る決済サーバのＤＢに記憶される情報の一例を示す模式図であって、（ａ）が残高管理ＤＢに記憶される残高情報であり、（ｂ）が供託管理ＤＢに記憶される供託情報であり、（ｃ）が債権管理ＤＢに記憶される債権情報である。
【符号の説明】
【０１３８】
１０    決済管理システム
１１    ゲームサーバ
１２    決済サーバ
１３    端末
１４    インターネット
１００  ゲーム装置
１０１  ＣＰＵ
１０２  ＲＯＭ
１０３  ＲＡＭ
１０４  インターフェース
１０５  コントローラ
１０６  外部メモリ
１０７  ＤＶＤ−ＲＯＭドライブ
１０８  画像処理部
１０９  音声処理部
１１０  ＮＩＣ
２０１  認証部
２０２  ユーザ情報記憶部
２０３  ゲーム制御部
２０４  ゲーム情報記憶部
２０５  課金管理部
４０１  依頼受付部
４０２  決済制御部
４０３  残高管理ＤＢ
４０４  供託管理ＤＢ
４０５  残高情報送信部
７０１  債権管理ＤＢ
【図１】
2005173827.tif 000003
【図２】
2005173827.tif 000004
【図３】
2005173827.tif 000005
【図４】
2005173827.tif 000006
【図５】
2005173827.tif 000007
【図６】
2005173827.tif 000008
【図７】
2005173827.tif 000009
【図８】
2005173827.tif 000010
【図９】
2005173827.tif 000011
【図１０】
2005173827.tif 000012
【図１１】
2005173827.tif 000013
【図１２】
2005173827.tif 000014
【図１３】
2005173827.tif 000015
【図１４】
2005173827.tif 000016