JP2009213735A - 課金システム、サーバシステム及びローカルサーバ - Google Patents

Abstract

【課題】ゲーム端末が店舗等の施設に設置されるネットワークゲームシステムにおける、適切な収益配分を可能とする仕組みの提供。
【解決手段】ゲームシステム１では、課金サーバ８０によって各店舗への課金が行われる。具体的には、（１）店舗に設置されたゲーム端末２０におけるゲームプレイの回数、（２）店舗に設置された店舗端末３０における現金のチャージ額それぞれに対して、所定の課金レートで算出された課金額が徴収される。また、（３）店舗端末３０におけるアイテムの購入個数（或いは、購入金額）に応じた報酬額が店舗に支給される。
【選択図】図１

Description

本発明は、課金システム等に関する。

ゲームサーバに通信ネットワークを介してゲーム端末が接続されて構成されるネットワークゲームシステムが知られている。このようなネットワークゲームシステムにおける課金方式として、プレーヤ毎に、アイテムの購入料金を含めたゲーム利用代金及びゲームサーバにアクセスするための通信料金を課金し、電子マネーで決済する仕組みがある（例えば、特許文献１参照）。
特開２００１−３４０６５６号公報

ネットワークゲームシステムの一形態として、ゲーム端末を業務用のゲーム装置としてゲームセンタ等の施設に設置する形態がある。通常、ゲームサーバは施設とは別の場所に設置され、メーカ側で運営管理される。一方、施設はゲームサーバの運営管理会社とは別会社によって運営管理される。しかし、ネットワークゲームシステムは、メーカ側がプレーヤやゲームプレイデータ等を一元管理することで、プレーヤは、どの施設を利用しても自身の最新のデータを利用してゲームプレイを楽しむことができるという特殊なシステム構成をなす。すなわち、プレーヤは、ある施設のあるゲーム端末（ゲーム装置）を利用するために、その施設に一定額のプレイ料金を支払うのが一般的である。
この場合、そのプレイ料金はその施設に入金されることになる。

ところが、ネットワークゲームシステムは施設だけで構築されているわけではなく、ゲームサーバの運営管理会社（メーカ側）にも適切な収益配分がなされて然るべきである。また、施設側の営業努力によって売り上げを上げている場合もあり、その営業努力に見合った適切な収益配分も要求されて然るべきである。このような収益配分にかかる問題は、ネットワークゲームシステム特有の問題である。本発明は、上記事情に鑑みてなされたものであり、ゲーム端末が店舗等の施設に設置されるネットワークゲームシステムにおける適切な収益配分を実現する仕組みの提供を目的としている。

上記課題を解決するための第１の発明は、
ＩＣ機能を有するゲームカード（例えば、図１のゲームカード１０）から記憶内容を読み取ってゲームプレイを実行するゲーム端末（例えば、図１のゲーム端末２０）と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバ（例えば、図１の店舗端末３０）と、前記ローカルサーバと通信接続されたサーバシステム（例えば、図１のサーバシステム４０）とを具備して構成された課金システム（例えば、図１のゲームシステム１）であって、
前記ローカルサーバは、
現金投入手段（例えば、図６の現金投入部３１６）と、
カード読み書き手段（例えば、図６のカードリーダ／ライタ３１２）と、
前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨（例えば、実施形態の「仮想マネー」）のチャージ処理を行うチャージ手段（例えば、図６のチャージ管理部３２１）と、
前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報（例えば、図６の設置店舗ＩＤ３３３）とともに前記サーバシステムに通知するチャージ用入金額通知手段（例えば、図６のチャージ管理部３２１）と、
を備え、
前記サーバシステムは、
前記ローカルサーバから通知される前記チャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段（例えば、図１６の集計部８２３）と、
前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段（例えば、図１６の集計部８２３）と、
を備えた、
課金システムである。

また、他の発明として、
ＩＣ機能を有するゲームカードから記憶内容を読み取ってゲームプレイを実行するゲーム端末と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバであって、現金投入手段と、カード読み書き手段と、前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理を行うチャージ手段と、前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報とともに前記サーバシステムに通知するチャージ用入金額通知手段とを備えたローカルサーバと通信接続されるサーバシステムであって、
前記ローカルサーバから通知される前記チャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段と、
前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段と、
を備えたサーバシステムを構成しても良い。

また、他の発明として、
ＩＣ機能を有するゲームカードから記憶内容を読み取ってゲームプレイを実行するゲーム端末と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバから通知されるチャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段と、前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段とを備えたサーバシステムと通信接続されるローカルサーバであって、
現金投入手段と、
カード読み書き手段と、
前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理を行うチャージ手段と、
前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報とともに前記サーバシステムに通知するチャージ用入金額通知手段と、
を備えたローカルサーバを構成しても良い。

この第１の発明等によれば、ローカルサーバでは、投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理が行われ、このチャージ用入金額が、自ローカルサーバが設置された施設の施設識別情報とともにサーバシステムに通知される。そして、サーバシステムでは、ローカルサーバから通知されるチャージ用入金額をローカルサーバの設置施設別に集計して各施設それぞれの入金総額が算出され、算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額が算出される。つまり、施設では、ローカルサーバにおいてチャージ用に投入された現金が収益となるとともに、このチャージ用の入金額に応じた課金額が徴収される。これにより、サーバシステム側が、施設側に対して、例えばチャージ用入金額の一部を後日徴収するといった、施設に対する適切な課金の仕組みを実現できる。

第２の発明は、第１の発明の課金システムであって、
前記課金額算出手段は、前記入金総額に対する課金額の算出に用いる課金レートを、入金総額が高い施設ほど低くするように調整する手段（例えば、図２３の店舗課金レートテーブル８６１）を有する課金システムである。

この第２の発明によれば、入金総額に対する課金額の算出に用いる課金レートが、入金総額が高い施設ほど低くするように調整される。つまり、施設にとってみれば、当該施設に設置されたローカルサーバでのチャージ用の入金総額が高いほど、課金レートが低くなる。これにより、施設側が、自施設に設置されているローカルサーバでのチャージを促す動機付けとなる。一方、サーバシステム側にとってみれば、ローカルサーバにおける入金額が多くなることで、課金レートが低くなっても、結果的には店舗から徴収する課金総額が多くなる。従って、施設側及びサーバシステム側のどちらにとっても、有益な課金の仕組みとなる。

第３の発明は、第１又は第２の発明の課金システムであって、
前記ゲームカードは、ＩＤ（例えば、図５のカードＩＤ１２ａ或いはプレーヤＩＤ１２ｂ）を記憶しており、
前記サーバシステムは、前記ＩＤごとに仮想通貨の保有額を記憶し（例えば、図８の仮想マネー残高６４２ｉ）、所与の増額要求信号又は減額要求信号（例えば、実施形態の「チャージ要求」）に応じて保有額を変更して管理する保有額管理手段（例えば、図１１のチャージ履歴データ６４６）を備え、
前記チャージ手段は、チャージ時に前記カード読み書き手段に前記ＩＤを読み取らせて、読み取ったＩＤに対応付けて前記保有額管理手段で管理されている保有額を前記チャージ用入金額に応じた仮想通貨分増額させる前記増額要求信号を前記サーバシステムに送信することで前記チャージ処理を行う、
課金システムである。

この第３の発明によれば、サーバシステムでは、ゲームカードが記憶しているＩＤごとに仮想通貨の保有額が記憶されるとともに、ローカルサーバにおける現金のチャージ用入金額に応じた仮想通貨分だけ保有額が増額される。つまり、どの施設のどのゲーム端末においてもチャージが可能である。

第４の発明は、第３の発明の課金システムであって、
前記サーバシステムは、
前記ＩＤごとに仮想通貨の保有額の変更履歴を管理する保有額履歴管理手段（例えば、図７の処理部６２０）と、
前記増額要求信号に応じて増額した前記ＩＤごとの所定期間の間又は通算の総額に基づいて、当該ＩＤに対応付けて前記保有額管理手段で管理されている保有額に所定のボーナス額（例えば、実施形態の「チャージ額に対するボーナスチャージ」）を付与する第１のボーナス処理手段（例えば、図７の処理部６２０）と、
を備えた課金システムである。

この第４の発明によれば、サーバシステムでは、ゲームカードのＩＤごとに仮想通貨の保有額の変更履歴が管理され、所定期間の間又は通算の仮想通貨の増額の総額に基づいて、仮想通貨の保有額に所定のボーナス額が付与される。すなわち、より多くの現金をチャージするほど、より多くのボーナス額が付与される。これにより、プレーヤに対してより多くのチャージを促すことができる。

第５の発明は、第３又は第４の発明の課金システムであって、
前記ゲーム端末は、ゲームプレイの際に前記ゲームカードから前記ＩＤを読み取って前記サーバシステムにプレイ実績通知信号（例えば、実施形態の「プレイ通知」）として通知するプレイ実績通知手段（例えば、図４のゲーム演算部２２１）を備えており、
前記サーバシステムは、
前記プレイ実績通信信号に基づいて前記ＩＤごとにプレイ実績を管理するプレイ実績管理手段（例えば、図９のプレイ履歴データ６４４）と、
前記プレイ実績管理手段で管理されている前記ＩＤごとの所定期間の間又は通算のプレイ実績に基づいて、当該ＩＤに対応付けて前記保有額管理手段で管理されている保有額に所定のボーナス額（例えば、実施形態の「プレイ回数に対するボーナスチャージ」）を付与する第２のボーナス処理手段（例えば、図７の処理部６２０）と、
を備えた、
課金システムである。

この第５の発明によれば、ゲーム端末では、ゲームカードのＩＤがプレイ実績通知信号としてサーバシステムに通知される。そして、サーバシステムでは、ゲームカードのＩＤごとにプレイ実績が管理され、所定期間の間又は通算のプレイ実績に基づいて、当該ＩＤに対応する仮想通貨の保有額に所定のボーナス額が付与される。つまり、ゲーム端末におけるゲームプレイに応じて、仮想通貨の保有額にボーナス額が付与される。これにより、プレーヤに対してゲーム端末でのゲームプレイを促すことができ、その結果、ゲーム端末が設置された施設でのゲームプレイによる収益を増加させるができる。

第６の発明は、第５の発明の課金システムであって、
前記プレイ実績通知手段は、前記ゲーム端末が設置された施設の施設識別情報（例えば、図４の設置店舗ＩＤ２３３）を前記プレイ実績通知信号に含めて前記サーバシステムに通知し、
前記サーバシステムは、前記プレイ実績通知信号に基づいて、前記ゲーム端末でのゲームプレイに対する課金額を各施設ごとに算出するゲーム課金額算出手段（例えば、図１６の集計部８２３）を備えた、
課金システムである。

この第６の発明によれば、ゲーム端末では、当該ゲーム端末が設置された施設の施設識別情報をプレイ実績通知信号に含めてサーバシステムに通知され、サーバシステムでは、プレイ実績通知信号に基づいて、ゲーム端末でのゲームプレイに対する課金額が各施設ごとに算出される。つまり、サーバシステム側から、各施設に対して、当該施設におけるゲーム端末でのゲームプレイに対する課金が行われる。

第７の発明は、第１から第６の何れかの発明の課金システムであって、
前記ローカルサーバは、
前記カード読み書き手段を制御して、前記ゲーム端末で実行されるゲームで利用可能な所定コンテンツ（例えば、実施形態の「アイテム」）を前記仮想通貨で販売処理するコンテンツ販売手段（例えば、図６のアイテム売買管理部３２２）と、
前記コンテンツ販売手段によって販売されたコンテンツの数及び／又は前記仮想通貨による販売額を販売情報（例えば、実施形態の「アイテム売買通知」）として、自ローカルサーバが設置された施設の施設識別情報とともに前記サーバシステムに通知するコンテンツ販売通知手段（例えば、図６のアイテム売買管理部３２２）と、
を備え、
前記サーバシステムは、
前記ローカルサーバから通知される販売情報を、前記ローカルサーバの設置施設別に集計して各施設それぞれの総販売情報として算出する販売情報集計手段（例えば、図１６の集計部８２３）と、
前記販売情報集計手段により算出された各施設それぞれの総販売情報に基づいて、各施設へ支給する報酬金額を算出する第１の報酬金額算出手段（例えば、図１６の集計部８２３）と、
を備えた、
課金システムである。

この第７の発明によれば、ローカルサーバでは、ゲーム端末で実行されるゲームで利用可能な所定コンテンツが仮想通貨で販売され、販売されたコンテンツの数及び／又は販売額を販売情報として、自ローカルサーバが設置された施設の施設識別情報とともにサーバシステムに通知される。そして、サーバシステムでは、ローカルサーバから通知される販売情報を設置施設別に集計して各施設それぞれの総販売情報として算出し、算出した各施設それぞれの総販売情報に基づいて、各施設へ支給する報酬金額が算出される。つまり、施設側にとってみれば、ローカルサーバにおける所定コンテンツの販売数／販売額に応じて報酬が支給されるため、プレーヤに対して自施設に設置されたローカルサーバの使用（コンテンツの販売）を促す動機付けとなる。更に、コンテンツの販売には仮想通貨が用いられるため、チャージをも促すことができ、収益の増加も見込める。

第８の発明は、第７の発明の課金システムであって、
前記第１の報酬金額算出手段は、総販売情報に対する報酬金額の算出に用いる報酬レートを、総販売情報の実績が高い施設ほど高くするように調整する手段（例えば、図２３の店舗課金レートテーブル８６１）を有する課金システムである。

この第８の発明によれば、総販売情報に対する報酬金額の算出に用いる報酬レートが、総販売情報の実績が高い施設ほど高くするように調整される。施設にとってみれば、自施設に設置されているローカルサーバでのコンテンツの販売数／販売額が多くなるほど、報酬レートが高くなり、支給される報酬金額が高くなる。このため、プレーヤに対して、当該施設におけるローカルサーバの使用（コンテンツの販売）を促す動機付けとなる。一方、サーバシステム側にとってみれば、各施設のローカルサーバにおけるコンテンツの販売が促され、より多くのコンテンツが販売されることで、各施設に対する報酬レートが高くなっても、結果的には収益の増加を見込める。

第９の発明は、第１〜第８の何れかの発明の課金システムであって、
前記ローカルサーバは、
前記カード読み書き手段を制御して、前記ゲーム端末で実行されるゲームで利用可能な所定コンテンツのプレーヤ間での前記仮想通貨を用いた取引処理を行う取引処理手段（例えば、図６のアイテム売買管理部３２２）と、
前記取引処理手段によって取り引きされた取引金額を、自ローカルサーバが設置された施設の施設識別情報とともに前記サーバシステムに通知する取引金額通知手段（例えば、図６のアイテム売買管理部３２２）と、
を備え、
前記サーバシステムは、
前記ローカルサーバから通知される前記取引金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの取引総額を算出する取引金額集計手段（例えば、図１６の集計部８２３）と、
前記取引金額集計手段により算出された各施設それぞれの取引総額に基づいて、各施設へ支給する報酬金額を算出する第２の報酬金額算出手段（例えば、図１６の集計部８２３）と、
を備えた、
課金システムである。

この第９の発明によれば、ローカルサーバでは、プレーヤ間での仮想通貨を用いた所定コンテンツの取引が行われ、取引された取引金額が、自ローカルサーバが設置された施設の施設識別情報とともにサーバシステムに通知される。そして、サーバシステムでは、ローカルサーバから通知される取引金額を、ローカルサーバの設置施設別に集計して各施設それぞれの取引総額が算出され、算出された各施設それぞれの取引総額に基づいて、各施設へ支給する報酬金額が算出される。つまり、ローカルサーバでの取引に応じて、当該ローカルサーバが設置された施設に報酬金額が支給される。施設側にとってみれば、当該施設に設置されたローカルサーバでプレーヤ間の所定コンテンツの取引が行われることで報酬が支給されるため、当該ローカルサーバでの当該取引を促す動機付けとなる。更に、この取引に仮想通貨が用いられるため、チャージをも促すことができ、収益の増加を見込める。一方、サーバシステム側にとってみれば、ローカルサーバでのチャージを促すことができ、その結果、より多くのチャージ用入金額に対する課金額を施設から徴収できる。

第１０の発明は、第９の発明の課金システムであって、
前記第２の報酬金額算出手段は、取引総額に対する報酬金額の算出に用いる報酬レートを、取引総額が高い施設ほど高くするように調整する手段（例えば、図２３の店舗課金レートテーブル８６１）を有する課金システムである。

この第１０の発明によれば、取引総額に対する報酬金額の算出に用いる報酬レートが、取引総額が高い施設ほど高くするように調整される。つまり、施設側にとってみれば、自施設に設置したローカルサーバでの取引総額が高いほど、報酬レートが高くなり、その結果、支給される報酬金額が高くなる。このため、施設に対して、ローカルサーバにおけるプレーヤ間のコンテンツの取引を促す動機付けとなる。一方、サーバシステム側にとっては、各施設でのローカルサーバでの取引総額が高くなるほど、報酬レートは高くなり施設に支給する報酬金額が高くなるけれども、この取引に仮想通貨が用いられることからチャージ用入金額が増加し、施設から徴収する課金額の増加が見込める。

本発明によれば、ローカルサーバでは、投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理が行われ、このチャージ用入金額が、自ローカルサーバが設置された施設の施設識別情報とともにサーバシステムに通知される。そして、サーバシステムでは、ローカルサーバから通知されるチャージ用入金額をローカルサーバの設置施設別に集計して各施設それぞれの入金総額が算出され、算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額が算出される。つまり、施設では、ローカルサーバにおいてチャージ用に投入された現金が収益となるとともに、このチャージ用の入金額に応じた課金額が徴収される。これにより、サーバシステム側が、施設側に対して、例えばチャージ用入金額の一部を後日徴収するといった、施設に対する適切な課金の仕組みを実現できる。

以下、図面を参照して本発明の好適な実施形態を説明する。なお、以下では、本発明をネットワークゲームシステムに適用した場合を説明するが、本発明の適用可能な実施形態がこれに限定されるものではない。

［システム構成］
図１は、本実施形態におけるゲームシステム１の構成図である。同図によれば、ゲームシステム１は、ゲーム端末２０と、店舗端末３０と、サーバシステム４０と、プレーヤ端末９０とを備えて構成されるネットワークゲームシステムである。ゲーム端末２０と店舗端末３０とサーバシステム４０とは、通信回線Ｎ１を介して通信可能に接続されている。また、サーバシステム４０とプレーヤ端末９０とは、通信回線Ｎ２を介して通信可能に接続されている。ここで、通信回線Ｎ１，Ｎ２とは、データ授受が可能な通信路を意味する。即ち、通信回線Ｎとは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮの他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。また、通信回線Ｎ１，Ｎ２は、それぞれ異なる通信網であっても同一の通信網であっても構わない。

ゲーム端末２０は、施設であるゲームセンタ等の店舗に設置されてプレーヤがゲームプレイを行うための端末装置であり、例えば業務用のゲーム装置で実現される。本実施形態では、ゲーム端末２０では、格闘対戦ゲームが行われる。この格闘対戦ゲームでは、他のプレーヤと対戦する対人戦や、ＣＰＵ制御されたキャラクタ（ＣＰＵキャラクタ）と対戦するＣＰＵ戦を楽しむことができる。

また、本実施形態のゲームシステム１では、ゲームカード１０を所有しゲームシステム１に登録することで、プレーヤキャラクタや保有するアイテム等のプレイデータを保持しておくことができ、どの店舗のどのゲーム端末２０においても、自分のオリジナルなプレーヤキャラクタを用いてゲームプレイを楽しむことができる。勿論、ゲームカード１０を用いなくともゲームプレイを行うことができる。ここで、ゲームカード１０は、販売等によって事前にプレーヤに提供されるものであり、例えば固有のカードＩＤが記憶されたＩＣチップを内蔵するＩＣカードにより実現される。

店舗端末３０は、ゲーム端末２０とともに店舗に設置され、プレーヤに、ゲーム端末２０におけるゲームプレイに関連するサービスを提供するための端末装置（ローカルサーバ）である。具体的には、ゲームシステム１に登録されているプレーヤを対象として、（１）アイテムの売買、（２）仮想マネー（仮想通貨）のチャージ、を行う。

「アイテムの売買」では、ゲーム端末２０でのゲームにおいて使用するアイテムの購入や、不要なアイテムの売却を行う。アイテムの売買には、（１）ゲーム運営会社によって運営される仮想店舗でのアイテム購入、（２）他のプレーヤとのアイテム売買（取引）、の２種類がある。ここで、「アイテム」とは、ゲーム端末２０におけるゲームで利用可能なコンテンツであり、例えば、プレーヤキャラクタが装備する武器や防具、装飾のためのアクセサリといった装備品、体力回復のための薬草といった道具等である。また、アイテム売買は、仮想マネーを用いて行われる。すなわち、不要なアイテムを仮想マネーに換金したり（販売）、他のプレーヤや仮想店舗から、所定量の仮想マネーと引き換えに所望のアイテムを獲得（購入）したりする。

「仮想マネーのチャージ」では、現金を、上述のアイテム売買において用いられる仮想マネーに変換（換金）する。具体的には、プレーヤが店舗端末３０において現金（例えば、１００［円］）を投入（入金）すると、この現金が所定の換金レート（例えば、２［Ｇ／円］）で仮想マネー（例えば、２００［Ｇ］）に変換され、当該プレーヤの保有する仮想マネーに追加される。プレーヤの保有する仮想マネーは、当該プレーヤが所有するゲームカード１０と対応付けてサーバシステム４０にて管理される。このため、プレーヤは、どの店舗のどの店舗端末３０においても、保有する仮想マネーを使用することができる。

サーバシステム４０は、ゲームシステム１の運営会社側に設置・管理され、公知のサーバコンピュータにより実現される。また、サーバシステム４０は、ゲームサーバ５０と、プレーヤ管理サーバ６０と、アイテム売買サーバ７０と、課金サーバ８０とから構成される。なお、これらのサーバは、それぞれが独立したサーバシステムとして構成されても良いし、或いは、いくつかが同一のサーバシステムとして構成されていても良い。

ゲームサーバ５０は、ゲーム端末２０におけるゲームプレイのためのデータのロード処理やセーブ処理といったネットワークゲームに必要な種々の処理を行う。また、対人戦では、対戦するプレーヤ同士を組み合わせるマッチング処理を行い、マッチングさせたゲーム端末２０同士を接続させて格闘対戦を行わせる。

プレーヤ管理サーバ６０は、ゲームシステム１の登録プレーヤを管理する。すなわち、登録プレーヤそれぞれについて、ゲーム端末２０におけるゲームプレイの履歴や保有しているアイテム、仮想マネー等を、所有するゲームカード１０に対応付けて管理する。

アイテム売買サーバ７０は、店舗端末３０におけるアイテムの売買を管理する。アイテム売買の方法には、「プレーヤ間でのアイテム売買」及び「仮想店舗でのアイテム購入」の２種類がある。「プレーヤ間のアイテム売買」では、例えばオークション形式で、二人のプレーヤ間でのアイテム売買を仲介する。「仮想店舗でのアイテム購入」では、ゲーム運営会社側が仮想店舗を運営し、プレーヤにアイテムを販売する。

課金サーバ８０は、ゲームシステム１の利用料として店舗に対する課金を行う。課金は、（１）ゲーム端末２０でのゲームプレイ、（２）店舗端末３０でのチャージ、（３）店舗端末３０でのアイテム売買、に対して行う。具体的には、ゲーム端末２０でのゲームプレイに対しては、当該店舗においてプレイ対価として投入された総額に対して、所定の課金レートで課金・徴収する。店舗端末３０でのチャージに対しては、当該店舗におけるチャージ総額に対して、所定の課金レートで課金・徴収する。アイテム売買については、販売プレーヤに対する販売手数料の徴収、及び、アイテム購入が行われた店舗への報酬の支払いを行う。

図２は、アイテム売買に対する課金を説明する図である。同図（ａ）は、「プレーヤ間のアイテム売買」に対する課金を示している。同図（ａ）では、「店舗Ａ」の店舗端末３０において、プレーヤＡ（購入者）が、「店舗Ｂ」の店舗端末３０におけるプレーヤＢ（販売者）から、「アイテム」を購入している。この場合、課金として、販売者である「プレーヤＡ」に対して「販売手数料」が徴収され、購入プレーヤ（購入者）である「プレーヤＢ」がアイテムの購入を行った「店舗Ｂ」に対して「報酬」が支払われる。

また、同図（ｂ）は、「仮想店舗でのアイテム購入」に対する課金を示している。同図（ｂ）では、「店舗Ｃ」の店舗端末３０において、プレーヤＣ（購入者）が、仮想店舗（販売者）からアイテムを購入している。この場合、課金として、購入者である「プレーヤＣ」がアイテム購入を行った「店舗Ｃ」に対して、「報酬」が支払われる。なお、販売者である「仮想店舗」は課金を行うゲーム運営会社により運営されているので、「販売手数料」の徴収は行われない。

図３は、サーバシステム４０を構成する各サーバ間のデータの流れを説明する図である。同図に示すように、ゲーム端末２０では、ゲームサーバ５０との通信を行うことでゲームプレイを実現する。このとき、ゲームサーバ５０は、プレーヤ管理サーバ６０にて管理されているプレーヤデータを取得し、取得したプレーヤデータ（主に、プレーヤキャラクタやアイテムのデータ）をもとにゲーム制御を行う。そして、ゲーム端末２０におけるゲームプレイが終了すると、プレイ通知が、ゲームサーバ５０から課金サーバ８０に送信される。

また、店舗端末３０では、アイテム売買サーバ７０と通信することでアイテム売買を実現する。このとき、アイテム売買サーバ７０では、プレーヤ管理サーバ６０にて管理されているプレーヤデータを取得し、取得したプレーヤデータ（主に、仮想マネーやアイテムのデータ）をもとにアイテム売買を制御する。そして、店舗端末３０におけるアイテム売買が終了すると、アイテム売買通知が、アイテム売買サーバ７０から課金サーバ８０に送信される。

また、店舗端末３０では、プレーヤ管理サーバ６０と通信することで、仮想マネーのチャージを実現する。このとき、プレーヤ管理サーバ６０では、管理しているプレーヤデータ（主に、仮想マネーのデータ）をもとに仮想マネーのチャージの制御を行う。そして、チャージが終了すると、チャージ通知が、プレーヤ管理サーバ６０から課金サーバ８０に送信される。

そして、課金サーバ８０では、受信したプレイ通知やアイテム売買通知、チャージ通知をもとに、店舗への課金を行う。

図１に戻り、プレーヤ端末９０は、プレーヤがサーバシステム４０から提供されるサービスを受けるための端末装置であり、例えばプレーヤが所有する携帯電話機やＰＣ等である。具体的には、プレーヤ端末９０は、ブラウザプログラムを起動してゲーム運営会社により開設されているホームページにアクセスすることで、プレーヤ管理サーバ６０にて管理されている当該プレーヤのプレーヤデータを閲覧することができる。

［ゲーム端末］
図４は、ゲーム端末２０の機能構成を示すブロック図である。同図によれば、ゲーム端末２０は、機能的には、操作入力部２１１と、カードリーダ／ライタ２１２と、処理部２２０と、画像表示部２１３と、音出力部２１４と、通信部２１５と、コイン検知部２１６と、記憶部２３０とを備えて構成される。

操作入力部２１１は、プレーヤの操作指示を受け付け、操作に応じた操作信号を処理部２２０に出力する。この機能は、例えばボタンスイッチやレバー、マウス、キーボード、タッチパネル、各種センサによって実現される。

カードリーダ／ライタ２１２は、挿入されたゲームカード１０に記録されているカードデータを読み出し、読み出したデータを処理部２２０に出力するとともに、処理部２２０からの書き込み指示に従って、ゲームカード１０のカードデータを更新する。

図５に、ゲームカード１０に記録されるカードデータ１２のデータ構成の一例を示す。同図によれば、カードデータ１２には、当該ゲームカード１０のカードＩＤ１２ａと、所有しているプレーヤのプレーヤＩＤ１２ｂ及びプレーヤ名１２ｃと、プレーヤキャラデータ１２ｄとが含まれる。プレーヤキャラデータ１２ｄは、プレーヤキャラクタのキャラクタＩＤやキャラクタ名、レベル、経験値、保有アイテム、カスタマイズされた外見や性格等のデータを含む。

処理部２２０は、記憶部２３０から読み出したプログラムやデータ、操作入力部２１１から入力された操作信号、カードリーダ／ライタ２１２で読み出されたデータ等に基づいて、ゲーム端末２０の全体制御やゲーム進行、画像生成等の各種演算処理を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）の演算装置やその制御プログラムで実現される。また、処理部２２０は、主にゲームの実行に係る演算処理を行うゲーム演算部２２１と、ゲーム演算部２２１の処理によって求められた各種のデータに基づきゲーム画像を生成する画像生成部２２３と、効果音やＢＧＭ等のゲーム音を生成する音生成部２２４とを含んでいる。

ゲーム演算部２２１は、ゲームプログラム２３１に従ったゲーム処理を行って、格闘対戦ゲームを実行する。このゲーム処理では、処理部２２０は、挿入されたゲームカード１０に記録されているカードデータ１２を読み出し、読み出したカードデータ１２に含まれるカードＩＤやプレーヤＩＤとともに、ゲームサーバ５０にプレーヤデータを要求する。そして、ゲームサーバ５０から受信したプレーヤデータをもとに、プレーヤキャラクタと敵キャラクタ（他のプレーヤのプレーヤキャラクタやＣＰＵキャラクタ）とが対戦する対戦処理を実行する。対戦が終了すると、対戦結果を画像表示部２１３に表示させるとともに、ゲームカード１０のカードデータ１２を更新し排出させる。

画像表示部２１３は、画像生成部２２３からの画像信号に基づいて、例えば１／６０秒毎に１フレームの画像を再描画しながらゲーム画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。音出力部２１４は、音生成部２２４からの音信号に基づいてＢＧＭや効果音等のゲーム音声を出力する。この機能は、例えばスピーカによって実現される。

通信部２１５は、処理部２２０からの制御信号に従って通信回線Ｎ１に接続し、外部装置（主に、他のゲーム端末２０やゲームサーバ５０）とのデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。コイン検知部２１６は、ゲーム対価として投入される硬貨（コイン）の種類や数を検知し、検知信号を処理部２２０に出力する。

記憶部２３０は、処理部２２０にゲーム端末２０を統合的に制御させるための諸機能を実現するためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部２２０の作業領域として用いられ、処理部２２０が各種プログラムに従って実行した演算結果や操作入力部２１１からの入力データ等を一時的に記憶する。この機能は、例えば各種ＩＣメモリやハードディスク、ＭＯ、ＲＯＭ、ＲＡＭ等によって実現される。本実施形態では、記憶部２３０には、ゲームプログラム２３１が記憶されるとともに、当該ゲーム端末２０の端末ＩＤ２３２と、設置店舗の店舗ＩＤ２３３とが記憶されている。

［店舗端末］
図６は、店舗端末３０の機能構成を示すブロック図である。同図によれば、店舗端末３０は、機能的には、操作入力部３１１と、カードリーダ／ライタ３１２と、処理部３２０と、画像表示部３１３と、音出力部３１４と、通信部３１５と、現金投入部３１６と、記憶部３３０とを備えて構成される。

操作入力部３１１は、プレーヤの操作指示を受け付け、操作に応じた操作信号を処理部３２０に出力する。この機能は、例えばボタンスイッチやレバー、マウス、キーボード、タッチパネル、各種センサによって実現される。

カードリーダ／ライタ３１２は、挿入されたゲームカード１０に記録されているカードデータを読み出し、読み出したデータを処理部３２０に出力するとともに、処理部３２０からの書き込み指示に従って、ゲームカード１０のカードデータ１２を更新する。

処理部３２０は、記憶部３３０に記憶されているプログラムやデータ、操作入力部３１１から入力された操作信号、通信部３１５を介して外部装置（主に、プレーヤ管理サーバ６０やアイテム売買サーバ７０）から受信したデータ等に基づいて、店舗端末３０の全体制御を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムによって実現される。また、本実施形態では、処理部３２０は、チャージ管理部３２１と、アイテム売買管理部３２２とを含み、店舗プログラム３３１に従った店舗処理を行う。

チャージ管理部３２１は、プレーヤ管理サーバ６０と通信を行って仮想マネーのチャージを制御する。具体的には、挿入されたゲームカード１０から読み出されたカードデータ１２に含まれるカードＩＤやプレーヤＩＤとともに、プレーヤ管理サーバ６０にプレーヤデータを要求し、受信したプレーヤデータをもとに、プレーヤの仮想マネー残高を表示させる。そして、現金が投入されると、投入金額（チャージ用入金額）をチャージ要求とともにプレーヤ管理サーバ６０に送信し、プレーヤ管理サーバ６０からチャージ結果を受信すると、受信したチャージ結果をもとにプレーヤの仮想マネー残高を更新表示する。

アイテム売買管理部３２２は、アイテム売買サーバ７０と通信を行ってアイテム売買を制御する。具体的には、操作入力部３１１から入力されるプレーヤの選択指示に従って、アイテム売買の種別（「プレーヤ間のアイテム売買」或いは「仮想店舗でのアイテム購入」）を選択する。

「プレーヤ間のアイテム売買」が選択され、アイテム購入ならば、他のプレーヤによって販売を希望するとされているアイテムをその希望販売価格を一覧表示し、プレーヤによって選択されたアイテムとその希望購入価格を含む購入希望通知をアイテム売買サーバ７０に送信する。そして、アイテム売買サーバ７０から受信した購入結果を表示する。また、アイテム販売ならば、プレーヤの保有アイテムのうち、販売したいアイテム及びその販売希望価格を含む販売希望通知をアイテム売買サーバ７０に送信する。そして、アイテム売買サーバ７０から受信した販売結果を表示する。

また、「仮想店舗でのアイテム購入」が選択されたならば、仮想店舗によって提供されているアイテムをその価格とともに一覧表示する。そして、プレーヤによって選択されたアイテムを含む購入通知をアイテム売買サーバ７０に送信し、アイテム売買サーバ７０から受信した購入結果を表示する。

図６に戻り、画像表示部３１３は、処理部３２０からの画像信号に基づく表示画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。音出力部３１４は、処理部３２０からの音信号に基づく音声を出力する。この機能は、例えばスピーカによって実現される。

通信部３１５は、処理部３２０からの制御信号に従って通信回線Ｎ１に接続し、外部装置（主に、プレーヤ管理サーバ６０やアイテム売買サーバ７０）とのデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。現金投入部３１６は、チャージ用として投入された紙幣及び硬貨の種類及び数を検知し、検知結果を処理部３２０に出力する。

記憶部３３０は、処理部３２０に店舗端末３０を統合的に制御させるための諸機能を実現するためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部３２０の作業領域として用いられ、処理部３２０が各種プログラムに従って実行した演算結果や操作入力部３１１からの入力データ等を一時的に記憶する。この機能は、例えば各種ＩＣメモリやハードディスク、ＭＯ、ＲＯＭ、ＲＡＭ等によって実現される。本実施形態では、記憶部３３０には、店舗プログラム３３１が記憶されるとともに、当該店舗端末３０の端末ＩＤ３３２と、設置店舗の店舗ＩＤ３３３とが記憶されている。

図７は、プレーヤ管理サーバ６０の機能構成を示すブロック図である。同図によれば、プレーヤ管理サーバ６０は、機能的には、操作部６１１と、処理部６２０と、表示部６１３と、通信部６１２と、記憶部６３０とを備えて構成される。

操作部６１１は、プレーヤ管理サーバ６０の管理者による操作指示を受け付け、操作指示に応じた操作信号を処理部６２０に出力する。この機能は、例えばボタンスイッチやレバー、キーボード、マウス、タッチパネル、各種センサ等によって実現される。

処理部６２０は、記憶部６３０に記憶されているプログラムやデータ、操作部６１１から入力された操作信号、通信部６１２を介して外部装置（主に、店舗端末３０やゲームサーバ５０）から受信したデータ等に基づいて、プレーヤ管理サーバ６０の全体制御を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）の演算装置やその制御プログラムによって実現される。

本実施形態では、処理部６２０は、プレーヤＤＢ６４１によって、ゲームシステム１に登録されているプレーヤを管理する。

図８は、プレーヤＤＢ６４１のデータ構成の一例を示す図である。同図によれば、プレーヤＤＢ６４１は、登録されているプレーヤそれぞれについてのプレーヤデータ６４２から構成される。プレーヤデータ６４２は、該当するプレーヤのプレーヤＩＤ６４２ａ及びプレーヤ名６４２ｂと、所有するゲームカード１０のカードＩＤ６４２ｃと、プレーヤキャラデータ６４２ｄと、仮想マネー残高６４２ｉと、保有アイテムデータ６４３と、プレイ履歴データ６４４と、プレイ履歴集計データ６４５と、チャージ履歴データ６４６と、チャージ履歴集計データ６４７と、アイテム売買履歴データ６４８と、ボーナスチャージチェックデータ６４９とを格納している。

プレーヤキャラデータ６４２ｄは、プレーヤキャラクタのキャラクタＩＤ６４２ｅと、キャラクタ名６４２ｆと、レベル６４２ｇと、経験値６４２ｈとを格納している。

プレイ履歴データ６４４は、当該プレーヤのゲームプレイの履歴である。図９に、プレイ履歴データ６４４のデータ構成の一例を示す。同図によれば、プレイ履歴データ６４４は、行ったゲームプレイそれぞれについて、ゲームプレイを行った日時６４４ａと、店舗６４４ｂと、プレイ結果６４４ｃとを対応付けて格納している。プレイ結果６４４ｃは、例えば対戦相手や勝敗である。

プレイ履歴集計データ６４５は、当該プレーヤの対象期間（例えば、今月）におけるプレイ履歴を集計したデータである。図１０に、プレイ履歴集計データ６４５のデータ構成の一例を示す。同図によれば、プレイ履歴集計データ６４５は、店舗６４５ａそれぞれについて、対象期間におけるプレイ回数６４５ｂを対応付けて格納している。

チャージ履歴データ６４６は、当該プレーヤの仮想マネーのチャージの履歴である。図１１に、チャージ履歴データ６４６のデータ構成の一例を示す。同図によれば、チャージ履歴データ６４６は、行ったチャージそれぞれについて、チャージを行った日時６４６ａと、店舗６４６ｂと、チャージ額６４６ｃとを対応付けて格納している。

チャージ履歴集計データ６４７は、当該プレーヤの対象期間（例えば、今月）に行ったチャージ履歴を集計したデータである。図１２に、チャージ履歴集計データ６４７のデータ構成の一例を示す。同図によれば、チャージ履歴集計データ６４７は、店舗６４７ａそれぞれについて、対象期間におけるチャージ額６４７ｂを対応付けて格納している。

アイテム売買履歴データ６４８は、当該プレーヤのアイテム売買の履歴である。図１３に、アイテム売買履歴データ６４８のデータ構成の一例を示す。同図によれば、アイテム売買履歴データ６４８は、行ったアイテム売買それぞれについて、アイテム売買を行った日時６４８ａと、店舗６４８ｂと、売買の種別６４８ｃと、売買したアイテム６４８ｄと、金額６４８ｅと、売買相手６４８ｆとを対応付けて格納している。売買種別６４８ｃは、「プレーヤ間のアイテム売買」であるか「仮想店舗からの購入」であるかの種別である。売買相手６４８ｆは、「プレーヤ間のアイテム売買」ならばその相手プレーヤであり、「仮想店舗からの購入」ならばその仮想店舗である。

ボーナスチャージチェックデータ６４９は、当該プレーヤにボーナスチャージを付与したか否かのチェックデータである。

処理部６２０は、ゲームサーバ５０から受信したプレイ通知に基づいて、該当するプレーヤのプレーヤデータ６４２を更新する。すなわち、プレイ通知には、ゲームプレイが行われた店舗やプレーヤ、プレイ日時等のデータが含まれており、該当するプレーヤのプレーヤキャラクタのデータやプレイ履歴を更新する。

また、アイテム売買サーバ７０から受信したアイテム売買通知に基づいて、該当するプレーヤのプレーヤデータ６４２を更新する。すなわち、アイテム売買通知には、販売者及び購入者、売買されたアイテムとその代金、アイテム売買が行われた店舗や日時のデータが含まれており、該当するプレーヤ（販売プレーヤ及び購入プレーヤ）それぞれの仮想マネー残高や保有アイテム、アイテム売買履歴を更新する。詳細には、「プレーヤ間のアイテム売買」の場合には、購入プレーヤの保有アイテムに購入したアイテムを追加するとともに、仮想マネー残高から購入したアイテムの代金を減算する。また、販売プレーヤの保有アイテムから販売されたアイテムを削除するとともに、仮想マネー残高に、販売したアイテムの代金から販売手数料を差し引いた額を加算する。また、「仮想店舗での購入」の場合には、購入プレーヤの保有アイテムに購入したアイテムを追加するとともに、仮想マネー残高から購入したアイテムの代金を減算する。なお、「販売手数料」は課金サーバ８０から通知される。

また、処理部６２０は、店舗端末３０から受信したチャージ通知に基づいて、該当するプレーヤのプレーヤデータ６４２を更新する。すなわち、チャージ通知には、チャージが行われた店舗やプレーヤ、チャージ額が含まれており、該当するプレーヤの仮想マネー残高にチャージ額を加算するとともに、チャージ履歴を更新する。

更に、処理部６２０は、プレーヤに対して、対象期間（例えば、今月）における（ａ）プレイ回数、（ｂ）チャージ額に応じたボーナスチャージを付与する。すなわち、プレイ履歴集計データ６４５を参照して、対象期間（例えば、今月）における各店舗でのプレイ回数が、所定のプレイ回数条件を満たしているかを判断し、満たしているならば、満たしたプレイ回数条件に応じたボーナスチャージを付与する。また、チャージ額に対しても同様に、チャージ履歴集計データ６４７を参照して、対象期間（例えば、今月）における各店舗でのチャージ額が、所定のチャージ額条件を満たしているかを判断し、満たしているならば、満たしたチャージ額条件に応じたボーナスチャージを付与する。

ここで、付与条件であるプレイ回数条件やチャージ額条件、付与されるボーナスチャージは、ボーナスチャージテーブル６５１で定められている。図１４は、ボーナスチャージテーブル６５１のデータ構成の一例を示す図である、同図によれば、ボーナスチャージテーブル６５１には、プレイ回数に対するテーブル６５１−１と、チャージ額に対するテーブル６５１−２とが含まれている。テーブル６５１−１は、段階６５１ａそれぞれについて、プレイ回数条件６５１ｂと、ボーナスチャージ６５１ｃとを対応付けて格納している。テーブル６５１−２は、段階６５１ｄそれぞれについて、チャージ額条件６５１ｅと、ボーナスチャージ６５１ｆとを対応付けて格納している。同図に示すように、付与条件は段階的に定められており、段階が上がるほど、条件とするプレイ回数やチャージ額が増えるとともに、付与されるボーナスチャージが多くなるように定められている。

なお、ボーナスチャージは、対象期間（例えば、今月）において、各段階の付与条件を満たした時点で１回だけ付与される。そして、各プレーヤにボーナスチャージを付与済みであるかは、ボーナスチャージチェックデータ６４９にてチェックされる。

図１５は、ボーナスチャージチェックデータ６４９のデータ構成の一例を示す図である。同図によれば、ボーナスチャージチェックデータ６４９には、プレイ回数についてのチェックデータ６４９−１と、チャージ額についてのチェックデータ６４９−２とが含まれている。チェックデータ６４９−１は、店舗６４９ａそれぞれについて、各段階６４９ｂでのボーナスチャージを付与したか否かを示す値を格納している。例えば、付与済みであることを示す「○」、或いは未付与であることを示す「×」が格納される。チェックデータ６４９−２でも同様に、店舗６４９ｃそれぞれについて、各段階６４９ｄでのボーナスチャージを付与したか否かを示す値を格納している。例えば、付与済みであることを示す「○」、或いは未付与であることを示す「×」が格納される。

図７に戻り、表示部６１３は、処理部６２０からの表示信号に基づく表示画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。通信部６１２は、処理部６２０からの制御信号に従って通信回線Ｎ１，Ｎ２に接続し、外部装置（例えば、店舗端末３０やゲームサーバ５０）とのデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。

記憶部６３０は、処理部６２０にプレーヤ管理サーバ６０を統合的に制御させるためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部６２０の作業領域として用いられ、処理部６２０が各種プログラムに従って実行した演算結果や操作部６１１からの入力データ等を一時的に記憶する。この機能は、例えばＩＣメモリやハードディスク、ＭＯ、ＲＡＭ、ＶＲＡＭ、ＣＤ−ＲＯＭ等によって実現される。本実施形態では、記憶部６３０には、プログラムとしてプレーヤ管理プログラム６３１が記憶されるとともに、データとして、プレーヤＤＢ６４１と、ボーナスチャージテーブル６５１とが記憶される。

図１６は、課金サーバ８０の機能構成を示すブロック図である。同図によれば、課金サーバ８０は、機能的には、操作部８１１と、処理部８２０と、表示部８１２と、通信部８１３と、記憶部８３０とを備えて構成される。

操作部８１１は、課金サーバ８０の管理者による操作指示を受け付け、操作に応じた操作信号を処理部８２０に出力する。この機能は、例えばボタンスイッチやレバー、マウス、キーボード、タッチパネル、各種センサ等によって実現される。

処理部８２０は、記憶部８３０に記憶されているプログラムやデータ、操作部８１１から入力された操作信号、通信部８１３を介して外部装置（主に、プレーヤ管理サーバ６０やゲームサーバ５０、アイテム売買サーバ７０）から受信したデータ等に基づいて、課金サーバ８０の全体制御を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムによって実現される。本実施形態では、処理部８２０は、店舗に対する課金を行う店舗課金部８２１と、プレーヤに対する課金を行うプレーヤ課金部８２５とを有する。

店舗課金部８２１は、店舗課金ＤＢ８４１によって各店舗への課金を管理する。図１７は、店舗課金ＤＢ８４１のデータ構成の一例を示す図である。同図によれば、店舗課金ＤＢ８４１は、各店舗についての店舗課金データ８４２から構成される。店舗課金データ８４２は、該当する店舗の識別情報である店舗ＩＤ８４２ａ及び店舗名８４２ｂと、プレイ実績データ８４３と、チャージ実績データ８４４と、アイテム売買実績データ８４５と、月締め集計データ８４６と、請求データ８４７とを格納している。

プレイ実績データ８４３は、当該店舗におけるゲームプレイの実績である。図１８に、プレイ実績データ８４３のデータ構成の一例を示す。同図によれば、プレイ実績データ８４３は、行われたゲームプレイそれぞれについて、ゲームプレイが行われた日時８４３ａと、プレーヤ８４３ｂとを対応付けて格納している。

チャージ実績データ８４４は、当該店舗における仮想マネーのチャージの実績である。図１９に、チャージ実績データ８４４のデータ構成の一例を示す。同図によれば、チャージ実績データ８４４は、行われたチャージそれぞれについて、チャージが行われた日時８４４ａと、プレーヤ８４４ｂと、チャージ額８４４ｃとを対応付けて格納している。

アイテム売買実績データ８４５は、当該店舗におけるアイテム売買の実績である。図２０に、アイテム売買実績データ８４５のデータ構成の一例を示す。同図によれば、アイテム売買実績データ８４５は、行われたアイテム売買それぞれについて、アイテム売買が行われた日時８４５ａと、売買種別８４５ｂと、売買されたアイテム８４５ｃと、売買金額８４５ｄと、購入者８４５ｅと、販売者８４５ｆとを対応付けて格納している。売買種別８４５ｂは、「プレーヤ間のアイテム売買」或いは「仮想店舗でのアイテム購入」である。購入者８４５ｅは、購入プレーヤである。販売者８４５ｆは、「プレーヤ間のアイテム売買」ならば販売プレーヤであり、「仮想店舗でのアイテム売買」ならば仮想店舗である。

月締め集計データ８４６は、当該店舗におけるプレイ実績、チャージ実績及びアイテム売買実績を、対象期間（例えば、１ヶ月）毎に集計したデータである。図２１に、月締め集計データ８４６のデータ構成の一例を示す。同図によれば、月締め集計データ８４６は、対象期間８４６ａ毎に、プレイ回数８４６ｂと、チャージ額８４６ｃと、アイテム売買８４６ｄにおけるアイテム購入の成立数、アイテム販売の成立数及び売買金額とを対応付けて格納している。アイテムの売買金額は、購入金額と販売金額との和である。

請求データ８４７は、当該店舗に対する課金請求のデータである。図２２に、請求データ８４７のデータ構成の一例を示す。同図によれば、請求データ８４７は、対象期間８４７ａ毎に、徴収額８４７ｂと、報酬額８４７ｃと、請求額８４７ｄとを対応付けて格納している。請求額８４７ｄは、徴収額８４７ｂから報酬額８４７ｃを差し引いた額である。

また、店舗課金部８２１は、実績更新部８２２と、集計部８２３とを含む。

実績更新部８２２は、各店舗におけるプレイ実績、チャージ実績及びアイテム売買実績を管理する。具体的には、ゲームサーバ５０から受信したプレイ通知をもとに、該当する店舗のプレイ実績を更新する。すなわち、プレイ通知には、ゲームプレイが行われた店舗や日時、プレーヤ等のデータが含まれ、該当する店舗の店舗課金データ８４２において、プレイ実績データ８４３に新たなプレイ実績を追加する。

また、プレーヤ管理サーバ６０から受信したチャージ通知をもとに、該当する店舗のチャージ実績を更新する。すなわち、チャージ実績には、仮想マネーのチャージが行われた店舗や日時、プレーヤ、チャージ額等のデータが含まれ、該当する店舗の店舗課金データ８４２において、チャージ実績データ８４４に新たなチャージ実績を追加する。

また、アイテム売買サーバ７０から受信したアイテム売買通知をもとに、該当する店舗のアイテム売買実績を更新する。すなわち、アイテム売買通知には、種別、販売者及び購入者やアイテム売買が行われた店舗、日時、売買されたアイテムやその代金等のデータが含まれる。そして、アイテム売買の種別が「プレーヤ間のアイテム売買」の場合には、アイテムの販売及び購入が行われた店舗それぞれの店舗課金データ８４２において、アイテム売買実績データ８４５に新たなアイテム売買実績を追加する。更に、販売プレーヤのプレーヤ課金データ８５２において、アイテム販売実績データ８５３に新たなアイテム販売実績を追加する。また、アイテム売買の種別が「仮想店舗でのアイテム購入」の場合には、アイテム販売が行われた店舗の店舗課金データ８４２において、アイテム売買実績データ８４５に新たなアイテム売買実績を追加する。

集計部８２３は、所定タイミング（例えば、月末）において、店舗課金ＤＢ８４１をもとに、各店舗それぞれについて、今月のプレイ実績、チャージ実績及びアイテム売買実績を集計し、月締め集計データ８４６を更新する。

次いで、店舗課金レートテーブル８６１を参照して課金レートを決定する。図２３は、店舗課金レートテーブル８６１のデータ構成の一例を示す図である。同図によれば、店舗課金レートテーブル８６１には、プレイ対価に対する課金レートを定めたテーブル８６１−１と、チャージ額に対する課金レートを定めたテーブル８６１−２と、アイテム購入に対する報酬単価を定めたテーブル８６１−３とが含まれている。テーブル８６１−１は、過去１ヶ月におけるプレイ回数８６１ａと、プレイ対価に対する課金レート８６１ｂとを対応付けて格納している。同図では、プレイ回数が多くなるほど、プレイ対価に対する課金レートが低くなるように定められている。テーブル８６１−２は、過去一ヶ月におけるチャージ額８６１ｃと、チャージ額に対する課金レート８６１ｄとを対応付けて格納している。同図では、チャージ額が多くなるほど、チャージ額に対する課金レートが低くなるように定められている。テーブル８６１−３は、過去一ヶ月におけるアイテム購入の成立数８６１ｅと、アイテム購入に対する報酬単価８６１ｆとを対応付けて格納している。報酬単価８６１ｆは、アイテム１個あたりの報酬額であり、同図では、アイテム購入の成立数が多くなるほど、報酬単価が高くなるように定められている。

すなわち、処理部８２０は、店舗課金レートテーブル８６１−１を参照し、当該店舗の対象期間（例えば、今月）のプレイ回数に対応する課金レートを判断する。次いで、プレイ対価にプレイ回数を乗じてゲームプレイでの収益額を算出し、この収益額に判断した課金レートを乗じて、ゲームプレイに対する徴収額を算出する。また、店舗課金レートテーブル８６１−２を参照し、対象期間（例えば、今月）におけるチャージ額に対応する課金レートを判断する。次いで、このチャージ額に判断した課金レートを乗じて、チャージに対する徴収額を算出する。そして、ゲームプレイに対する徴収額と、チャージに対する徴収額との和を、当該店舗に対する徴収額とする。

また、店舗課金レートテーブル８６１−３を参照し、対象期間（例えば、今月）のアイテムの購入成立数に対応する販売手数料を判断する。次いで、判断した販売手数料にアイテムの購入成立数を乗じて、アイテム売買に対する支払い額を算出する。そして、徴収額から支払い額を引いた額を請求額とする。

プレーヤ課金部８２５は、プレーヤ課金ＤＢ８５１によってプレーヤへの課金を管理する。図２４は、プレーヤ課金ＤＢ８５１のデータ構成の一例を示す図である。同図によれば、プレーヤ課金ＤＢ８５１は、登録されているプレーヤそれぞれについての複数のプレーヤ課金データ８５２から構成される。プレーヤ課金データ８５２は、当該プレーヤのプレーヤＩＤ８５２ａ及びプレーヤ名８５２ｂと、アイテム販売実績データ８５３とを格納している。

アイテム販売実績データ８５３は、「プレーヤ間でのアイテム売買」において他のプレーヤにアイテムを販売した実績である。図２５に、アイテム販売実績データ８５３のデータ構成の一例を示す。同図によれば、アイテム販売実績データ８５３は、当該プレーヤが行ったアイテムの販売それぞれについて、日時８５３ａと、店舗８５３ｂと、アイテム８５３ｃと、販売額８５３ｄと、購入者８５３ｅとを対応付けて格納している。

プレーヤ課金部８２５は、「プレーヤ間でのアイテム売買」において、販売プレーヤに対する課金を行う。具体的には、プレーヤ管理サーバ６０から課金要求を受信すると、該当する販売プレーヤから徴収する販売手数料を算出する。すなわち、販売プレーヤのプレーヤ課金データ８５２を参照して、当該プレーヤの過去一ヶ月における販売アイテムの個数を算出する。次いで、プレーヤ課金レートテーブル８６２を参照して、算出した販売アイテムの個数に応じた販売手数料を判断する。そして、判断した販売手数料をアイテム売買サーバ７０に通知する。

図２６は、プレーヤ課金レートテーブル８６２のデータ構成の一例を示す図である、同図によれば、プレーヤ課金レートテーブル８６２は、過去一ヶ月におけるアイテムの販売個数８６２ａと、販売したアイテム１個当たりの販売手数料８６２ｂとを対応付けて格納している。同図では、アイテムの販売個数が多いほど、販売手数料が低くなるように定められている。

［処理の流れ］
（Ａ）ゲーム処理
図２７は、ゲーム端末２０とゲームサーバ５０との間で実行されるゲーム処理を説明するフローチャートである。同図において、左側にゲーム端末２０における処理を示し、右側にゲームサーバ５０における処理を示している。

同図によれば、ゲーム端末２０では、ゲームカード１０が挿入され（ステップＡ１）、且つ、所定のゲーム対価が投入されると（ステップＡ３）、挿入されたゲームカード１０に記録されているカードデータを読み出す。そして、ゲームサーバ５０に対して、読み出したカードデータに含まれるカードＩＤやプレーヤＩＤ、当該ゲーム端末２０の端末ＩＤとともに、プレーヤデータを要求する（ステップＡ５）。

すると、ゲームサーバ５０では、この要求に応答して、プレーヤ管理サーバ６０に該当するプレーヤデータを要求し（ステップＢ１）、この要求に応答してプレーヤ管理サーバ６０から送信されてくるプレーヤデータを受信する（ステップＢ３）。そして、受信したプレーヤデータを該当するゲーム端末２０に送信する（ステップＢ５）。

その後、ゲーム端末２０とゲームサーバ５０との間で通信を行うことで、対戦処理が実行される（ステップＡ７，Ｂ７）。対戦処理が終了すると、ゲーム端末２０では、対戦結果を表示するとともに（ステップＡ９）、ゲームカード１０に記録されているカードデータを更新し（ステップＡ１１）、ゲームカード１０を排出する（ステップＡ１３）。また、ゲームサーバ５０では、プレーヤ管理サーバ６０にプレイ通知を送信するとともに（ステップＢ９）、課金サーバ８０にもプレイ通知を送信する（ステップＢ１１）。ゲーム処理は、このように行われる。

（Ｂ）店舗処理
図２８は、店舗端末３０における店舗処理を説明するフローチャートである。同図によれば、店舗端末３０では、ゲームカード１０が挿入されると（ステップＣ１）、挿入されたゲームカード１０に記録されているカードデータを読み出し、読み出したカードデータに含まれるカードＩＤやプレーヤＩＤ、当該店舗端末３０の端末ＩＤとともに、プレーヤデータをプレーヤ管理サーバ６０に要求する（ステップＣ３）。次いで、この要求に応答してプレーヤ管理サーバ６０から送信されてくるプレーヤデータを受信する（ステップＣ５）。

そして、「仮想マネーのチャージ」を行うのならば（ステップＣ７：ＹＥＳ）、受信したプレーヤデータをもとに、プレーヤの仮想マネー残高を表示する（ステップＣ９）。現金が投入されると（ステップＣ１１）、投入金額とともに、チャージ要求をプレーヤ管理サーバ６０に送信する（ステップＣ１３）。そして、この要求に応答して、プレーヤ管理サーバ６０からチャージ結果を受信すると（ステップＣ１５）、受信したチャージ結果をもとに、仮想マネー残高を更新表示する（ステップＣ１７）。

また、「アイテム売買」を行うのならば（ステップＣ１９：ＹＥＳ）、アイテム売買サーバ７０と通信を行って、所定のアイテム売買処理を行う（ステップＣ２１）。

続いて、ゲームカード１０のカードデータを更新し（ステップＣ２３）、ゲームカード１０を排出する（ステップＣ２５）。その後、ステップＣ１に戻り、同様の処理を繰り返す。

（Ｃ）プレーヤ管理処理
図２９は、プレーヤ管理サーバ６０におけるプレーヤ管理処理を説明するフローチャートである。同図によれば、ゲームサーバ５０からプレーヤデータを要求されると（ステップＤ１：ＹＥＳ）、該当するプレーヤのプレーヤデータ６４２を、ゲームサーバ５０に送信する（ステップＤ３）。また、ゲームサーバ５０からプレイ通知を受信すると（ステップＤ５：ＹＥＳ）、受信したプレイ通知をもとに、該当するプレーヤのプレーヤデータ６４２を更新する（ステップＤ７）。

また、店舗端末３０からプレーヤデータを要求されると（ステップＤ９：ＹＥＳ）、該当するプレーヤのプレーヤデータ６４２を、当該店舗端末３０に送信する（ステップＤ１１）。

また、店舗端末３０からチャージ要求を受信すると（ステップＤ１３：ＹＥＳ）、該当プレーヤの仮想マネー残高にチャージ額を加算して更新する（ステップＤ１５）。次いで、ボーナスチャージを算出し（ステップＤ１７）、ボーナスチャージが有るならば（ステップＤ１９：ＹＥＳ）、当該プレーヤの仮想マネー残高に、算出したボーナスチャージを加算して更新する（ステップＤ２１）。その後、当該店舗端末３０にチャージ結果を送信するとともに（ステップＤ２３）、課金サーバ８０にもチャージ通知を送信する（ステップＤ２５）。

また、アイテム売買サーバ７０からアイテム売買通知を受信すると（ステップＤ２７：ＹＥＳ）、受信したアイテム売買通知をもとに、購入プレーヤの仮想マネー残高からアイテムの購入代金を減算して更新する（ステップＤ２９）。次いで、販売者がプレーヤならば（ステップＤ３１：ＹＥＳ）、課金サーバ８０に、販売プレーヤの販売手数料を要求する課金要求を送信し（ステップＤ３３）、この要求に応答して課金サーバ８０から送信されてくる課金通知を受信する（ステップＤ３５）。そして、販売プレーヤの仮想マネー残高に、アイテムの販売代金から受信した課金通知に含まれる販売手数料を引いた額を加算して更新する（ステップＤ３７）。以上の処理を行うと、ステップＤ１に戻り、同様の処理を繰り返す。

（Ｄ）課金処理
図３０は、課金サーバ８０における課金処理を説明するフローチャートである。同図によれば、ゲームサーバ５０からプレイ通知を受信すると（ステップＥ１：ＹＥＳ）、実績更新部８２２が、受信したプレイ通知をもとに、該当する店舗のプレイ実績を更新する（ステップＥ３）。

また、実績更新部８２２は、プレーヤ管理サーバ６０からチャージ通知を受信すると（ステップＥ５：ＹＥＳ）、受信したチャージ通知をもとに、該当する店舗のチャージ実績を更新する（ステップＥ７）。

また、プレーヤ課金サーバ８０から課金要求を受信すると（ステップＥ９：ＹＥＳ）、販売プレーヤに対する販売手数料を算出する（ステップＥ１１）。すなわち、販売プレーヤに該当するプレーヤ課金データ８５２を参照して、販売プレーヤの対象期間（例えば、過去１ヶ月）におけるアイテムの販売個数を算出する。次いで、プレーヤ課金レートテーブル８６２を参照して、販売個数に応じた販売手数料を判断する。そして、この販売手数料を、課金通知としてプレーヤ管理サーバ６０に送信する（ステップＥ１３）。

また、アイテム売買サーバ７０からアイテム売買通知を受信すると（ステップＥ１５：ＹＥＳ）、受信したアイテム売買通知をもとに、該当する店舗のアイテム売買実績を更新する（ステップＥ１７）。

そして、集計タイミング（例えば、月末）となると（ステップＥ１９：ＹＥＳ）、集計部８２３が、店舗課金ＤＢ８４１を参照し、店舗毎に実績を集計する集計処理を行う（ステップＥ２１）。すなわち、店舗それぞれについて、対象期間（例えば、今月）のプレイ実績、チャージ実績及びアイテム売買実績を集計し、月締め集計データ８４６を更新する。

次いで、集計結果をもとに、店舗それぞれについて当該店舗宛ての請求書／支払い通知書を作成・発行する請求書発行処理を行う（ステップＥ２３）。すなわち、当該店舗の対象期間（例えば、今月）におけるゲームプレイのプレイ回数に応じた課金レートを決定し、プレイ対価に対する徴収額する。また、当該店舗の対象期間（例えば、今月）における仮想マネーのチャージ総額に応じた課金レートを決定し、チャージ総額に対する徴収額を算出する。更に、当該店舗の対象期間（例えば、今月）におけるアイテム購入成立数に応じた報酬単価を算出し、アイテム購入に対する報酬額を算出する。そして、徴収額から報酬額を減算して、当該店舗に対する今月の請求額を算出する。また、徴収額より報酬額のほうが高い場合には、支払い額として算出する。その後、発行した請求書／支払い通知書に対する決済処理を行う（ステップＥ２５）。この決済処理は、外部の金融システムとの間で行う公知の処理である。以上の処理を行うと、ステップＥ１に戻り、同様の処理を繰り返す。

［変形例］
なお、本発明の適用可能な実施形態は、上述の実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能なのは勿論である。

（Ａ）プレイ対価
例えば、ゲーム端末２０におけるプレイ対価を仮想マネーで支払うことにしても良い。この場合、課金サーバ８０はプレイ対価に対する課金は行わない。更にこの場合、仮想マネーの使用目的として、（１）アイテム売買と、（２）ゲームプレイとに分けて使用額を集計し、使用目的によって課金レートを異ならせることにしても良い。

（Ｂ）店舗に支給する報酬額
また、上述の実施形態では、プレーヤのアイテム購入に対して店舗に支給する報酬単価を、対象期間（例えば、１ヶ月）のアイテム購入の成立数としたが（図２３の店舗課金レートテーブル８６１参照）、これを、対象期間（例えば、１ヶ月）の購入総額に応じて決定することにしても良い。例えば、購入総額が高いほど、この報酬単価を高くする。また、アイテム１個当たりいくらといった報酬単価とするのではなく、対象期間（例えば、１ヶ月）の購入成立数或いは購入総額に対する報酬レートを定めることにしても良い。例えば、購入成立数が多いほど、或いは購入総額が高いほど、この報酬レートを高くする。

（Ｃ）プレーヤから徴収する販売手数料
また、上述の実施形態では、プレーヤからアイテム販売に対して徴収する販売手数料を、対象期間（例えば、１ヶ月）のアイテムの販売個数に応じて決定することにしたが（図２６のプレーヤ課金レートテーブル８６２参照）、これを、対象期間（例えば、１ヶ月）のアイテムの購入個数に応じて決定するとしても良いし、或いは、販売総額や購入総額に応じて決定することにしても良い。例えば、アイテムの購入個数が多いほど、或いは販売総額や購入総額が高いほど、この販売手数料を安くする。

また、この販売手数料をアイテム１個当たりいくらと定額とするのではなく、販売額に対する課金レートを定めることにしても良い。この場合、課金レートは、対象期間（例えば、１ヶ月）のアイテムの販売個数や購入個数、販売総額、購入総額に応じて変更することにしても良い。例えば、アイテムの販売個数や購入個数が多いほど、或いは販売総額や購入総額が多いほど、課金レートを低くする。

（Ｄ）コンテンツ
また、上述の実施形態では、ゲーム端末２０で実行されるゲームで利用可能なコンテンツを「アイテム」としたが、これ以外であっても良い。例えば、ゲーム中にプレーヤキャラが取るべき行動のヒントといったゲーム進行に役立つ情報のほか、ゲームに関連するキャラクタ等の画像やゲーム中の音楽、キャラクタの発生音といったデータでも良い。

（Ｅ）ゲームの種類
また、上述の実施形態では、格闘対戦ゲームに適用した場合を説明したが、例えばカーレースゲームやクイズゲームといった他の何れのゲームにも適用可能である。

ゲームシステムの構成図。 アイテム売買に対する課金の説明図。 サーバシステムの各サーバ間のデータの流れの説明図。 ゲーム端末の機能構成図。 カードデータのデータ構成例。 店舗端末の機能構成図。 プレーヤ管理サーバの機能構成図。 プレーヤＤＢのデータ構成例。 プレイ履歴データのデータ構成例。 プレイ履歴集計データのデータ構成例。 チャージ履歴データのデータ構成例。 チャージ履歴集計データのデータ構成例。 アイテム売買履歴データのデータ構成例。 ボーナスチャージテーブルのデータ構成例。 ボーナスチャージチェックデータのデータ構成例。 課金サーバの機能構成図。 店舗課金ＤＢのデータ構成例。 プレイ実績データのデータ構成例。 チャージ実績データのデータ構成例。 アイテム売買実績データのデータ構成例。 月締め集計データのデータ構成例。 請求データのデータ構成例。 店舗課金レートテーブルのデータ構成例。 プレーヤ課金ＤＢのデータ構成例。 アイテム販売実績データのデータ構成例。 プレーヤ課金レートテーブルのデータ構成例。 ゲーム処理のフローチャート。 プレーヤ管理処理のフローチャート。 店舗処理のフローチャート。 課金処理のフローチャート。

符号の説明

１ ゲームシステム
１０ ゲームカード、１２ カードデータ
２０ ゲーム端末
３０ 店舗端末
４０ サーバシステム
５０ ゲームサーバ、６０ プレーヤ管理サーバ
７０ アイテム売買サーバ、８０ 課金サーバ
９０ プレーヤ端末
Ｎ１．Ｎ２ 通信回線

Claims (12)

1. ＩＣ機能を有するゲームカードから記憶内容を読み取ってゲームプレイを実行するゲーム端末と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバと、前記ローカルサーバと通信接続されたサーバシステムとを具備して構成された課金システムであって、
   前記ローカルサーバは、
   現金投入手段と、
   カード読み書き手段と、
   前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理を行うチャージ手段と、
   前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報とともに前記サーバシステムに通知するチャージ用入金額通知手段と、
   を備え、
   前記サーバシステムは、
   前記ローカルサーバから通知される前記チャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段と、
   前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段と、
   を備えた、
   課金システム。
2. 前記課金額算出手段は、前記入金総額に対する課金額の算出に用いる課金レートを、入金総額が高い施設ほど低くするように調整する手段を有する請求項１に記載の課金システム。
3. 前記ゲームカードは、ＩＤを記憶しており、
   前記サーバシステムは、前記ＩＤごとに仮想通貨の保有額を記憶し、所与の増額要求信号又は減額要求信号に応じて保有額を変更して管理する保有額管理手段を備え、
   前記チャージ手段は、チャージ時に前記カード読み書き手段に前記ＩＤを読み取らせて、読み取ったＩＤに対応付けて前記保有額管理手段で管理されている保有額を前記チャージ用入金額に応じた仮想通貨分増額させる前記増額要求信号を前記サーバシステムに送信することで前記チャージ処理を行う、
   請求項１又は２に記載の課金システム。
4. 前記サーバシステムは、
   前記ＩＤごとに仮想通貨の保有額の変更履歴を管理する保有額履歴管理手段と、
   前記増額要求信号に応じて増額した前記ＩＤごとの所定期間の間又は通算の総額に基づいて、当該ＩＤに対応付けて前記保有額管理手段で管理されている保有額に所定のボーナス額を付与する第１のボーナス処理手段と、
   を備えた請求項３に記載の課金システム。
5. 前記ゲーム端末は、ゲームプレイの際に前記ゲームカードから前記ＩＤを読み取って前記サーバシステムにプレイ実績通知信号として通知するプレイ実績通知手段を備えており、
   前記サーバシステムは、
   前記プレイ実績通信信号に基づいて前記ＩＤごとにプレイ実績を管理するプレイ実績管理手段と、
   前記プレイ実績管理手段で管理されている前記ＩＤごとの所定期間の間又は通算のプレイ実績に基づいて、当該ＩＤに対応付けて前記保有額管理手段で管理されている保有額に所定のボーナス額を付与する第２のボーナス処理手段と、
   を備えた、
   請求項３又は４に記載の課金システム。
6. 前記プレイ実績通知手段は、前記ゲーム端末が設置された施設の施設識別情報を前記プレイ実績通知信号に含めて前記サーバシステムに通知し、
   前記サーバシステムは、前記プレイ実績通知信号に基づいて、前記ゲーム端末でのゲームプレイに対する課金額を各施設ごとに算出するゲーム課金額算出手段を備えた、
   請求項５に記載の課金システム。
7. 前記ローカルサーバは、
   前記カード読み書き手段を制御して、前記ゲーム端末で実行されるゲームで利用可能な所定コンテンツを前記仮想通貨で販売処理するコンテンツ販売手段と、
   前記コンテンツ販売手段によって販売されたコンテンツの数及び／又は前記仮想通貨による販売額を販売情報として、自ローカルサーバが設置された施設の施設識別情報とともに前記サーバシステムに通知するコンテンツ販売通知手段と、
   を備え、
   前記サーバシステムは、
   前記ローカルサーバから通知される販売情報を、前記ローカルサーバの設置施設別に集計して各施設それぞれの総販売情報として算出する販売情報集計手段と、
   前記販売情報集計手段により算出された各施設それぞれの総販売情報に基づいて、各施設へ支給する報酬金額を算出する第１の報酬金額算出手段と、
   を備えた、
   請求項１〜６の何れか一項に記載の課金システム。
8. 前記第１の報酬金額算出手段は、総販売情報に対する報酬金額の算出に用いる報酬レートを、総販売情報の実績が高い施設ほど高くするように調整する手段を有する請求項７に記載の課金システム。
9. 前記ローカルサーバは、
   前記カード読み書き手段を制御して、前記ゲーム端末で実行されるゲームで利用可能な所定コンテンツのプレーヤ間での前記仮想通貨を用いた取引処理を行う取引処理手段と、
   前記取引処理手段によって取り引きされた取引金額を、自ローカルサーバが設置された施設の施設識別情報とともに前記サーバシステムに通知する取引金額通知手段と、
   を備え、
   前記サーバシステムは、
   前記ローカルサーバから通知される前記取引金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの取引総額を算出する取引金額集計手段と、
   前記取引金額集計手段により算出された各施設それぞれの取引総額に基づいて、各施設へ支給する報酬金額を算出する第２の報酬金額算出手段と、
   を備えた、
   請求項１〜８の何れか一項に記載の課金システム。
10. 前記第２の報酬金額算出手段は、取引総額に対する報酬金額の算出に用いる報酬レートを、取引総額が高い施設ほど高くするように調整する手段を有する請求項９に記載の課金システム。
11. ＩＣ機能を有するゲームカードから記憶内容を読み取ってゲームプレイを実行するゲーム端末と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバであって、現金投入手段と、カード読み書き手段と、前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理を行うチャージ手段と、前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報とともに前記サーバシステムに通知するチャージ用入金額通知手段とを備えたローカルサーバと通信接続されるサーバシステムであって、
    前記ローカルサーバから通知される前記チャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段と、
    前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段と、
    を備えたサーバシステム。
12. ＩＣ機能を有するゲームカードから記憶内容を読み取ってゲームプレイを実行するゲーム端末と同一施設又は別施設に設置されてプレーヤの使用に供するローカルサーバから通知されるチャージ用入金額を、前記ローカルサーバの設置施設別に集計して各施設それぞれの入金総額を算出する入金額集計手段と、前記入金額集計手段により算出された各施設それぞれの入金総額に基づいて、各施設から徴収する課金額を算出する課金額算出手段とを備えたサーバシステムと通信接続されるローカルサーバであって、
    現金投入手段と、
    カード読み書き手段と、
    前記カード読み書き手段を制御して、前記現金投入手段に投入された現金のチャージ用入金額に応じた仮想通貨のチャージ処理を行うチャージ手段と、
    前記チャージ用入金額を、自ローカルサーバが設置された施設の識別情報である施設識別情報とともに前記サーバシステムに通知するチャージ用入金額通知手段と、
    を備えたローカルサーバ。

Images