以下、本発明に係る決済システムの一形態を説明する。まず、図1を参照して、決済システムの全体構成を説明する。本形態の決済システム1は、複数の店舗2のそれぞれに設置された複数の課金対象機器3A、3B、…、3N(以下、参照符号3で代表することがある。)にて発生する課金に対応して、ユーザから課金内容に応じた量の仮想通貨を消費させるために設けられている。仮想通貨は、現金と引き換えにユーザが取得可能な金銭的価値の一例である。課金対象機器3の少なくとも一部は業務用の遊戯機(典型的にはゲーム機)であり、各店舗2はアミューズメント施設に相当する。ただし、各店舗2において、全ての課金対象機器3が遊戯機である必要はない。各店舗2には、少なくとも一台の遊戯機に加えて、料金の支払いと引き換えにユーザに所定のサービスを提供する各種の機器が課金対象機器3として設けられてよい。例えば、店舗2にジュース等の商品を販売する自動販売機等が設置されている場合には、それらの機器も本形態の決済システム1における課金対象機器3に含まれてよい。課金対象機器3は、本実施形態の決済システムと所定のプロトコルに従って通信可能な限りにおいて、種々の仕様に準拠して構成されてよい。課金対象機器3の製造者、提供者も互いに異なっていてもよい。課金対象機器3は、決済システム1を用いた決済方式の他に、現金等を用いた他の決済方式が併用可能とされてもよい。
決済システム1は、店舗2毎に構築される店舗システム10と、各店舗システム10に対して共通に設けられるサーバシステム20とを含んでいる。なお、図1では、一の店舗システム10のみ詳細を示している。店舗システム10は、各課金対象機器3にて発生した課金内容に対応してユーザに消費させるべき仮想通貨の量を判別するとともに、ユーザが所持するカード4から決済参照情報としてカード毎にユニークなカードIDを読み取り、そのカードID及び仮想通貨の消費量を指定してサーバシステム20に決済を要求する。カード4は、ユーザを識別するためにユーザに付与される媒体であって、そこにはカード4毎にユニークなカードIDが媒体識別情報として記録されている。ただし、ユーザが所持する媒体は、媒体識別番号を保持できる限り、カード4に限らず、携帯電話に付属するICチップその他が媒体として利用されてもよい。媒体識別情報は、ユーザ毎にユニークに設定された識別情報であってもよい。要するに、媒体識別情報は、媒体毎にユニーク性が保証されていれば足りる。
サーバシステム20は、ユーザが保持する仮想通貨の量をユーザのカードIDと対応付けて管理し、店舗システム10からの要求に応じて、カードIDに対応する口座に保持されている仮想通貨を消費させ、その処理結果を店舗システム10に通知する。つまり、本形態の決済システム1は、ユーザが予め現金等と引き換えに仮想通貨を取得し、その残高の範囲内でユーザが仮想通貨を消費することにより課金対象機器3の料金を支払うプリペイド方式の決済システムである。また、ユーザが保持する仮想通貨の残高がサーバシステム20側に保持され、その残高の減少(引き落とし)をサーバシステム20側で実行するシンクライアント方式(サーバ処理方式)の決済システムである。
店舗システム10は、課金対象機器3のそれぞれに1対1で対応付けて取り付けられる情報読取端末装置としてのリーダ11と、管理PC(パーソナルコンピュータの略、以下同様。)12と、設定端末PC13と、業者用端末PC14と、ルータ15とを含んでいる。各リーダ11、管理PC12、設定端末PC13及び業者用端末PC14は、店舗2内に構築された店舗内LAN16により相互に通信可能に接続される。また、各リーダ11は、課金対象機器3とは物理的に異なる装置として構成され、対応する課金対象機器3の制御ユニット(不図示)と所定のプロトコルに従って双方向に通信可能な状態で課金対象機器3に取り付けられる。ルータ15はインターネット5に接続されている。それにより、店舗内LAN16に接続されるリーダ11、管理PC12、設定端末PC13のそれぞれは、インターネット5を介してサーバシステム20と接続可能であり、サーバシステム20に対するクライアントとして機能するコンピュータ装置である。
リーダ11は、課金対象機器3から課金情報を受け取り、かつ決済処理の結果を課金対象機器3に提供する情報入出力手段、及びユーザが所持するカード4からカードIDを読み取る情報読取手段として機能する。管理PC12は、リーダ11から提供される情報を参照しつつ、課金対象機器3にて発生した課金の内容に応じてユーザに所定の仮想通貨を消費させる決済処理をサーバシステム20と協働して実行する。設定端末PC13は、店舗2の管理PC12が保持する情報を店舗2の運営者が管理する手段として機能する。これらの機能は後に詳しく説明する。
業者用端末PC14は、サーバシステム20から提供される決済履歴等の情報を店舗2の運営者が閲覧する端末として機能する。なお、図1の例において、リーダ11及び設定端末PC13は、無線LANアクセスポイント17を介して管理PC12と接続されているが、これらは有線接続されてもよい。業者用端末PC14は必ずしも店舗2内に設けられなくともよい。例えば、店舗2の営業主体である法人の本社又は営業所等に業者用端末PC14が設置されてもよい。なお、店舗2の営業主体は、単一店舗2のみを営業する者であってもよいし、複数の店舗2を営業する者であってもよい。
サーバシステム20は、複数のコンピュータ装置としてのサーバユニット21A、21B…(以下、これらを参照符号21で代表することがある。)と、それらのサーバユニット21をインターネット5に接続するルータ22とを備えている。ただし、サーバシステム20は単一のサーバユニットを用いるものでもよい。あるいは、クラウドコンピューティングを利用して論理的にサーバシステム20が構築されてもよい。
サーバシステム20には、さらにユーザ端末装置6もインターネット5を介して接続可能とされる。ユーザ端末装置6は、ネットワーク接続が可能でかつユーザの個人用途に供されるコンピュータ装置である。例えば、据置型又はブック型のPC6A、あるいは携帯電話(スマートフォンを含む。)のようなモバイル端末装置6Bがユーザ端末装置6として利用される。その他にも、据置型の家庭用ゲーム機、携帯型ゲーム機、携帯型タブレット端末装置といった、ネットワーク接続が可能でかつユーザの個人用途に供される各種のコンピュータ装置がユーザ端末装置6として利用されてよい。ユーザ端末装置6は、例えばユーザがサーバシステム20にアクセスして自己の決済履歴を閲覧し、あるいはユーザが仮想通貨を購入して自己の口座に預けるチャージ操作を行なうために利用される。なお、決済システム1には、さらなる端末装置が設けられてもよい。例えば、店舗2において、ユーザが現金やクレジットカードを用いて仮想通貨を購入するためのチャージ機がさらに設けられてルータ15と接続されてもよい。
次に、図2及び図3を参照して決済システム1の制御系の構成を説明する。まず、サーバシステム20の制御系を先に説明する。図2に示すように、サーバシステム20には、そのサブシステムとして、仮想通貨に関する取引全般を管理する取引管理システム31と、仮想通貨を管理する通貨管理システム32と、仮想通貨の取引に伴って発生する店舗2の運営者への支払い等を管理する経理システム33とが設けられている。取引管理システム31には、コンピュータハードウエアとソフトウエアとの組み合わせによって実現される論理的装置として、取引制御部34が設けられている。取引制御部34は、店舗システム10から送られる決済要求に従って、仮想通貨の消費等に必要な各種の処理を実行する。
決済要求には、ユーザがどの店舗2のどの課金対象機器3にて仮想通貨をどのように消費しようとしているかを特定するために必要な取引情報として、例えば、ユーザのカード4から読み取られたカードID、仮想通貨の消費量、及び店舗2を特定する店舗コード等が含まれているとする。取引制御部34は、カードIDとユーザの仮想通貨の口座に付された口座特定情報(例えばユーザIDとする。)との対応関係を記録したユーザ情報D1にアクセスして、カードIDに対応するユーザIDを判別する。また、取引制御部34は、通貨管理システム32の残高情報のデータD2にアクセスし、そのデータD2にて、ユーザIDと対応付けて記録されている仮想通貨の口座の残高から消費量を減少させることにより、仮想通貨の消費を実行する。さらに、取引制御部34は、取引情報を通貨管理システム32の取引情報データD3にユーザIDと対応付けて記録する。取引情報データD3には、取引日時、店舗コード、仮想通貨の消費量といった取引内容を特定する情報がユーザIDと対応付けて記録される。通貨管理システム32にユーザ端末装置6からユーザがアクセスすることにより、ユーザは自己のユーザ端末装置6から自己の口座残高を確認し、所定のチャージ操作をすることにより、その口座の残高を増加させることができる。
取引制御部34は、通貨管理システム32にて仮想通貨を消費させる処理を行なわせると、その処理結果、つまり消費に成功したか否かを店舗システム10に通知する。また、一回の取引、すなわち店舗システム10からの決済要求に対応した仮想通貨の消費処理が終わると、取引制御部34は今回の決済処理の内容を消費情報のデータD4に記録する。消費情報のデータD4には、取引日時、店舗コード、仮想通貨の消費量、ユーザID(又はカードID)といった取引内容を特定する情報が記録される。それにより、消費情報のデータD4は仮想通貨の決済処理の履歴を記録した履歴情報として機能する。消費情報のデータD4は適当な集計期間(一例として一月)毎に集計されて集計情報のデータD5に記録される。経理システム33は集計情報のデータD5に基づいて、店舗2毎、あるいは店舗2の営業主体毎といった所定の集計単位で消費情報を集計し、その集計結果に従って、店舗2の営業主体に対する支払額を演算し、演算結果を支払情報のデータD6に記録する。仮想通貨の購入代金はサーバシステム20の営業主体の売上げとなり、課金対象機器3の料金が仮想通貨で支払われた場合には店舗2の営業主体には代金が入らないため、サーバシステム20の営業主体には、仮想通貨の消費量に対応する売上げ代金を按分して店舗2の営業主体に支払う必要が生じる。そのために、支払額の演算等の処理が必要となる。経理システム33は、支払情報のデータD7に基づいて、店舗2の営業主体に対する支払通知書PDを作成し、これを業者用端末PC14に送信する。なお、業者用端末PC14では、集計情報のデータD5にも適宜アクセスして消費履歴等を確認することが可能とされている。さらに、取引制御部34は、店舗システム10から管理PC12の設定情報(管理PC情報)が送られた場合、その設定情報を管理PC情報のデータD7に店舗コードと対応付けて保存する。
次に、図3を参照して店舗システム10の制御系を説明する。図3は、課金対象機器3としての遊戯機の一例としてのゲーム機と店舗システム10のリーダ11、管理PC12及び設定端末PC13との関係を示している。以下では、課金対象機器3に代えて、ゲーム機3の表記を用いることがある。まず、店舗システム10においては、各課金対象機器3に課金管理部41が設けられている。課金管理部41は、課金対象機器3にて発生する課金の内容に応じた課金情報を生成し、その課金情報をリーダ11に出力する。課金対象機器としてのゲーム機3はコンピュータ装置の一種であり、そこにはコンピュータハードウエアとソフトウエアとの組み合わせによる論理的装置として、所定の手順に従ってゲームを進行させるゲーム制御部7が設けられている。課金管理部41もゲーム制御部7と同様の論理的装置であり、ゲーム制御部7を実現するためのプログラムに対して適宜のプログラムモジュールを追加することによって課金管理部41を実現することができる。
ゲーム制御部7によって提供されるゲームにおいては、一般に、ゲームの開始又は継続、ゲームのモード、アイテムの購入、使用といった事項がユーザの選択肢として用意される。また、業務用のゲーム機3において、ユーザが希望するモード等を選択してこれをプレイするためには、選択内容に応じた料金がユーザに課金される。つまり、ゲーム機3では、ユーザの選択肢のそれぞれが課金対象の品目(課金品目)として用意され、それらの課金品目に応じて料金が設定されている。ゲーム制御部7は、ユーザの指示に従ってゲームの選択肢のいずれが選択されたかを判別し、課金管理部41はその選択結果、つまりどの課金品目が選択されたかをゲーム制御部7から取得する。数量が選択可能な課金品目(例えば購入数量を選択可能なアイテム等)であれば、ユーザが選択した数量も課金管理部41が取得する。課金管理部41にてユーザの選択結果を取得することにより決済システム1による決済処理が開始される。そして、課金管理部41から決済完了が通知されると、ゲーム制御部7はユーザが選択した課金品目に対応したサービスをユーザに提供する。例えば、ゲーム制御部7は、ユーザが選択したゲームモードによるゲームのプレイを開始させ、あるいはユーザが選択したアイテムをユーザに付与する。なお、アイテムの購入には、対価を消費して、ゲーム中でアイテムを使用するための許諾を獲得すること等を含む。
課金管理部41は、ゲーム制御部7から提供される課金内容、つまり、ユーザが選択した課金品目、あるいはユーザが選択した課金品目及び数量に従って課金情報を生成する。ここでは、課金品目の単価と数量とを乗算してユーザに課金すべき料金を演算し、その料金を指定する情報を課金情報として生成するものとする。数量が選択不可能な課金品目については数量を1として料金が演算される。課金管理部41は、生成した課金情報(つまり、プレイ料金やアイテム等の購入料金)を所定のプロトコルに従ってリーダ11に送信する。
リーダ11には、情報管理部42とID読取部43とが設けられている。情報管理部42はリーダ11のコンピュータハードウエアとソフトウエアとの組み合わせによって実現される論理的装置である。ID読取部43は、カード4に記録されたカードIDを読み取る周辺機器として設けられている。例えば、カード4のICチップにカードIDが記録されている場合には、そのICチップから情報を読み取るようにID読取部43が構成されている。ただし、カードIDはICチップに限らず、磁気記憶層や光学的記憶層に記録されてもよいし、バーコードのように光学的に読み取り可能な態様で記録されてもよい。カード4に対するカードIDの記録方式に応じてID読取部43は適宜に構成することができる。なお、リーダ11には、仮想通貨の消費量等を表示するためのディスプレイを備えるが、図3では図示が省略されている。
情報管理部42には、課金対象機器3を識別するための機器識別情報として、機器IDが設定されている。機器IDは、一例としてリーダ11をネットワーク上で一意に特定するために付されるMACアドレスのように、リーダ11に固有の識別情報でもよいし、課金対象機器3を区別するために店舗2の運営者等が設定したゲーム機番号等でもよい。機器IDは、一例としてリーダ11の記憶部(例えばEEPROM)に保持されている。情報管理部42は、ゲーム機3の課金管理部41から課金情報を受け取ると、ID読取部43を起動させてカードIDの読み取りを開始させる。その読み取りが完了すると、情報管理部42は、取得したカードIDと、自己の機器IDとを指定して、課金管理部41から受け取った課金情報を管理PC12に送信する。
管理PC12には、論的装置として、取引制御部44が設けられている。取引制御部44は、リーダ11から受け取った課金情報及び機器IDに基づいて、ユーザに消費させるべき仮想通貨の量を判別し、判別した仮想通貨の消費量と、リーダ11から受け取ったカードIDと、店舗2毎にユニークに設定された店舗コードとを含む取引情報をサーバシステム20に提供して決済を要求する。店舗コードは、一例として管理PC12の記憶部45に保持されている。記憶部45には、さらにゲーム機3毎の設定情報のデータD10が記録されている。データD10は、ゲーム機3の課金管理部41から通知される料金に対する仮想通貨の消費量を記述したデータである。設定情報のデータD10は、どのゲーム機3に対応する設定情報かを判別できるように、機器IDと対応付けて記録されている。取引制御部44は、機器IDを利用して、課金が発生したゲーム機3の設定情報のデータD10を特定し、そのデータD10に従って、課金管理部41から通知される料金に対応してユーザが消費すべき仮想通貨の消費量を判別することができる。
上記の決済システム1では、設定情報のデータD10における消費量の設定値を操作することにより、ゲーム機3で課金されるべき料金をユーザが仮想通貨にて支払う際にユーザが消費すべき金銭的価値の量を適宜に変更することができる。例えば、通常は100円の現金で100ポイントの仮想通貨を購入できるとした場合、ゲーム機3の課金管理部41から出力される課金情報にて100円の料金が指定されている場合、80ポイントの消費量が設定情報のデータD10に記述されていれば、20円相当の割引が実現されることになる。管理PC12には、設定情報のデータD10の設定内容を店舗2の運営者に適宜に設定させるための論理的装置として、設定管理部46が設けられている。設定管理部46は、設定端末PC13に対して設定情報のデータD10の内容を閲覧し、あるいは設定情報のデータD10の内容を変更するためのWebページとしての管理ページを提示する。したがって、店舗2の運営者は、設定端末PC13のWebブラウズ機能を利用して管理PC12が提供する管理ページにアクセスし、設定情報のデータD10を確認し、料金と仮想通貨の消費量との対応関係を適宜に変更することができる。この機能を利用すれば、特定のゲーム機3のみ割引を実施し、あるいは特定の期間のみ割引を実施するといった柔軟な料金設定が可能となる。
次に、図4及び図5を参照して、決済システム1にて実行される処理を説明する。図4はゲーム機3にて発生した課金に対応してユーザに仮想通貨を消費させる際の処理の手順を示している。ゲーム機3において、ユーザが課金品目としてのモード、アイテム等を選択すると、ゲーム機3の課金管理部41は課金が発生したものとして図4の処理を開始し、まず、ゲーム制御部7からの情報に基づいて課金品目等(数量が含まれることもある。)を判別する(ステップS11)。次に、課金管理部41は、ステップS1の判別結果に従って課金すべき料金(課金額)を算出し、その料金を指定する課金情報をリーダ11に通知する(ステップS12)。リーダ11の情報管理部42は、ゲーム機3から課金情報を受け取ると図3の処理を開始し、まず管理PC12に対して、機器IDと課金情報としての料金を通知する(ステップS21)。
管理PC12の取引制御部44は、リーダ11から機器IDと課金情報とを受け取ると、機器IDに対応する設定情報のデータD10を特定し、そのデータD10に基づいて、課金情報で指定された料金に対応してユーザに消費させるべき仮想通貨の消費量を判別する(ステップS31)。次いで、取引制御部44はリーダ11の情報管理部42に仮想通貨の消費量を通知する(ステップS32)。この通知を受けて、リーダ11の情報管理部42は仮想通貨の消費量をユーザに提示する(ステップS22)。次いで、リーダ11の情報管理部42は、ID読取部43を起動させてカードIDの読み取りに備え、これに応じてユーザがカードIDを読み取らせる操作(一例としてカード4をリーダ11にタッチする操作)を行なうと、カード4のカードIDを読み取る(ステップS23)。次いで、情報管理部42は、読み取ったカードIDを管理PC12に通知する(ステップS24)。
管理PC12の取引制御部44は、リーダ11からカードIDを受け取ると、記憶部45に保持されている店舗コードと、リーダ11から受け取ったカードIDと、ステップS31で判別した仮想通貨の消費量とを指定する取引情報を添えてサーバシステム20に決済を要求する(ステップS33)。なお、カードIDの読取りに先行して仮想通貨の消費量をユーザに提示する必要がないときは、ステップS21、S22及びS32の処理を省略し、ステップS12の通知に対応してステップS23及びステップS24の処理を順次実行して管理PC12にカードID、機器ID、及び課金情報を一括して通知し、その後、管理PC12にてステップS31及びS33の処理を順次実行すればよい。
管理PC12からの決済要求を受けて、サーバシステム20の取引制御部34はカードIDに対応するユーザIDをユーザ情報のデータD1から取得し、そのユーザIDに対応付けて残高情報のデータD2に記録されている仮想通貨の口座の残高から、取引情報で指定された消費量を減算することにより、課金品目に対応した量の仮想通貨をユーザに消費させる(ステップS41)。ただし、残高が消費量に満たないときは消費が中止される。その後、取引制御部34は決済結果を管理PC12に通知する(ステップS42)。決済結果は、消費量の減算に成功した場合には決済完了、残高不足等により消費ができなかった場合には決済失敗として通知される。なお、決済に際して、サーバシステム20は、取引情報のデータD3や消費情報のデータD4への記録等も併せて実行するが、それらの処理は説明を省略する。
管理PC12の取引制御部44は、サーバシステム20から通知される結果を、課金が発生したゲーム機3のリーダ11に通知し(ステップS34)、リーダ11の情報管理部42はその結果をさらにゲーム機3の課金管理部41に通知する(ステップS25)。なお、管理PC12とサーバシステム20との間で決済処理が行なわれる際、どのゲーム機3で発生した課金に対応する処理かを特定可能とするため、例えばステップS33の決済要求毎に取引ID等を利用して決済要求が互いに区別される。ただし、決済要求の区別にはカードIDを利用することもできる。すなわち、取引IDに代えてカードIDを処理の判別に利用し、さらにカードIDが処理中の間は同一のカードIDによる決済処理を禁止することにより、カードIDを用いて決済要求が区別されるようにしてもよい。
ゲーム機3の課金管理部41は、リーダ11から決済結果を受け取ると、その結果をゲーム制御部7に通知する(ステップS13)。ゲーム制御部7は決済完了であれば、ユーザの選択に従ってサービスを提供する。例えば、ゲーム制御部7は、ユーザが選択したモードでゲームを開始させ、あるいはユーザがプレイしているゲームを継続させ、あるいはユーザが購入したアイテムをユーザに付与する。決済失敗の場合、ゲーム制御部7は例えば所定のエラー処理を実行する。
図5は、店舗2の運営者が設定端末PC13を用いて設定情報のデータD10を操作する際の処理の手順を示している。運営者が設定端末PC13のWebブラウザを起動して管理PC12の管理ページのURLを指定すると、設定端末PC13から管理PC12に対して管理ページのアクセスが要求される(ステップS51)。これを受けて、管理PC12の設定管理部46は管理ページのデータを設定端末PC13に送信する(ステップS61)。運営者が設定端末PC13にて設定情報のデータD10の設定値を更新すると、その更新情報が設定端末PC13から管理PC12に提供される(ステップS52)。これを受けて、管理PC12の設定管理部46は、更新情報に従って設定情報のデータD10を更新する(ステップS62)。次に、設定管理部46は、更新された設定情報を店舗コードとともにサーバシステム20に送信する(ステップS63)。これを受けて、サーバシステム20の取引制御部34は管理PC情報のデータD7に店舗コードと対応付けて保存されている設定情報を、管理PC12から提供された新たな設定情報で更新する(ステップS71)。
本発明は上述した形態に限定されず、適宜の変更が可能である。以下、変形例を順次説明する。上記の形態では、ゲーム機3の課金管理部41から課金情報として料金をリーダ11に通知し、管理PC12にて料金に対応した消費量を判別したが、これに代えて、図6に示したように、ステップS12でゲーム機3の課金管理部41から課金品目と数量とを課金情報として出力させ、ステップS31で管理PC12の取引制御部44が課金品目及び数量に従って仮想通貨の消費量を算出するものとしてもよい。この場合、記憶部45の設定情報には、課金品目と、1品あたりの仮想通貨の消費量(単位消費量)との対応関係を記述すればよい。なお、ゲーム機3から課金品目を取得する場合には、管理PC12やサーバシステム20にて仮想通貨の消費量を品目毎に管理できる利点がある。これにより、一つのゲーム機3においても特定の品目のみ割引設定するといったように、仮想通貨の消費量をさらに柔軟に調整することができる。また、課金品目毎に仮想通貨の消費量を把握することにより、売上げ分析等を細かく行なうことができる。課金品目を基準として仮想通貨の消費量等の管理を行う場合、ゲームの種類に応じてユニークな品目を設定し、その品目ごとに消費量との対応関係を設定すれば、同一店舗に同一種類のゲームを提供する複数台のゲーム機が設置されていても、それらのゲーム機に関する設定を共用し、一台分の設定で済ませることが可能である。
設定情報のデータD10を各リーダ11に配信してリーダ11の記憶部に記憶させることにより、仮想通貨の消費量をリーダ11に判別させることも可能である。例えば、図7に示したように、リーダ11の情報管理部42がゲーム機3の課金管理部41から課金情報(料金、あるいは課金品目と数量の組み合わせ)を受け取った場合、リーダ11の情報管理部42にて、リーダ11に対応付けられたゲーム機3についての設定情報のデータD10を参照して消費量を判別し(ステップS21a)、その後、ステップS24aでリーダ11からサーバシステム20に取引情報を通知して直接的に決済を要求してもよい。この場合、各リーダ11に店舗コードを記録しておけばよい。あるいは、図7の変形例として、リーダ11から管理PC12を経由してサーバシステム20に決済を要求するものとし、その際に管理PC12にて店舗コードを取引情報に付加してもよい。
仮想通貨の消費量はサーバシステム20にて判別することも可能である。この場合、管理PC12の設定情報のデータD10が管理PC情報のデータD7に店舗コードと対応付けて記録されているので、店舗システム10側から機器ID、課金情報及び店舗コードを指定する取引情報を添えてサーバシステム20に決済を要求すればよい。サーバシステム20にて仮想通貨の消費量を判別する手順の一例を図8に示す。この例では、管理PC12の取引制御部44がリーダ11から課金情報(料金又は課金品目と数量の組み合わせ)を受け取った場合、それらの機器ID及び課金情報と店舗コードとをサーバシステム20の取引制御部34に提供し(ステップS31a)、これを受けて取引制御部34が管理PC情報のデータD7にアクセスして店舗コードに対応する管理PC12の設定情報のデータD10を特定し、そのデータD10に従って取引制御部34が課金情報に対応する仮想通貨の消費量を判別する(ステップS31b)。続いて、取引制御部34が店舗2の管理PC12に対して消費量を通知し(ステップS32a)、その消費量を管理PC12がリーダ11に通知する(ステップS32b)。さらに、管理PC12はリーダ11からカードIDを受け取ると、そのカードIDとステップS32bで取得した消費量と店舗コードとを指定してサーバシステム20に対して決済を要求する(ステップS33a)。以降は図4と同様に処理すればよい。
仮想通貨の消費量を判別する際には、媒体識別情報(一例としてカードID)や営業識別情報(一例として店舗コード)をさらに参照することも可能である。例えば、図9に示すように、課金管理部41からの課金情報の出力に対応してリーダ11の情報管理部42にてカードIDの読み取りを実行し(ステップS23)、そのカードID、機器ID及び課金情報を管理PC12に通知する(ステップS24b)。管理PC12の取引制御部44は、サーバシステム20の取引制御部34にカードID及び店舗コードを提供して、それらのカードID及び店舗コードに対応する消費情報のデータD4の提供を要求し、サーバシステム20の取引制御部34からカードID及び店舗コード該当する消費情報のデータD4を管理PC12に提供する(ステップS31c、S31d)。
続いて、管理PC12の取引制御部44は課金情報に対応する仮想通貨の消費量を判別する(ステップS32c)。この場合、取引制御部44は、機器IDに対応する設定情報のデータD10に従って、課金情報に対応する仮想通貨の消費量をまず仮の消費量として判別する。続いて、サーバシステム20から取得した消費情報のデータD4を参照して、自己の店舗2におけるユーザの仮想通貨の消費状況が所定の割引条件を満たすか否かを判別する。そして、割引条件を満たす場合、取引制御部44は、設定情報から判別された仮の消費量を所定の割引率、あるいは割引量に従って減少させ、その減少後の量を、ユーザに消費させるべき仮想通貨の量として判別する。割引条件は、カードID及び店舗コードと対応付けて設定することができる。例えば、自店舗2におけるユーザの消費量の積算値が所定値を超えている場合に割引条件が満たされるように割引条件を設定することができる。この場合は、サーバシステム20から取得した消費情報のデータD4を利用してユーザのカードIDに対応する消費量の合計値を求め、得られた合計値を所定値と比較すればよい。あるいは、消費量の合計値に代えて、又は加えて、消費の回数を割引条件に加えることもできる。さらに、消費情報のデータD4に含まれている取引日時を参照することにより、ユーザが適当な期間(例えば一日、一週間、あるいは一月)内で初めて自店舗2でゲームをプレイする場合に割引条件が満たされるものとしてもよい。あるいは、ユーザが自店舗2で一定回数以上連続してゲームをプレイしている場合等に割引条件が満たされるものとしてもよい。消費状況としては、消費量の合計値、消費の回数、初回の消費か否か、連続プレイ回数の他にも、ユーザが仮想通貨を消費する頻度、所定の単位期間内におけるユーザの消費量の平均値等を求めて判別してもよい。
上記の例では、ユーザのカードID及び自店舗2の店舗コード、すなわち媒体識別情報と営業識別情報の両者と対応付けられている消費情報のデータD4を管理PC12が取得するものとしたが、いずれか一方の識別情報に対応する消費情報のデータD4、又は全ての消費情報のデータD4を管理PC12が取得し、いずれか一方の識別情報を手掛かりとして消費状況を判別してもよい。例えば、店舗2の異同を問わず、同一ユーザの消費状況が所定の割引条件を満たす場合に割引を実施してもよい。この場合は、全ての消費情報のデータD4を管理PC12にて取得し、ユーザのカードIDに対応付けられた消費情報を抽出してユーザの消費状況を判別するか、あるいは、ユーザのカードIDと対応付けられた消費情報に絞り込んで管理PC12がデータD4を取得し、その取り込んだ消費情報からユーザの消費状況を判別すればよい。あるいは、ユーザの異同を問わず、自店舗2における消費状況が所定の割引条件を満たす場合に割引を実施してもよい。例えば、自店舗2における全ユーザの一定期間内の仮想通貨の消費量の合計値が所定の設定値を超えたか否かを消費情報に基づいて判別し、その合計値が設定値を超えたときに一定期間に限ってユーザに関わりなく割引を実施してもよい。この場合は、全ての消費情報のデータD4を管理PC12にて取得し、自店舗2の店舗コードに対応付けられた消費情報を抽出して自店舗2における消費状況を判別するか、あるいは、自店舗2の店舗コードと対応付けられた消費情報に絞り込んで管理PC12がデータD4を取得し、その取り込んだ消費情報から自店舗2における消費状況を判別すればよい。
なお、上記の例では管理PC12がサーバシステム20から履歴情報としての消費情報のデータD4を取得し、カードIDや店舗コードを手掛かりとした消費状況の判別を管理PC12にて行なうものとしたが、図8に示したように、サーバシステム20側で消費量を判別する場合には、サーバシステム20の取引制御部34がカードID及び店舗コードを店舗システム10から取得し、消費量判別の際に割引条件が満たされるか否かを判別し、その判別結果に応じて消費量を調整するものとしてもよい。あるいは、サーバシステム20による消費情報のデータD4の管理とは別に、管理PC12にて自店舗2における履歴情報を蓄積し、カードIDを参照して消費量を判別するといった変形も可能である。管理PC12は店舗2内の各リーダ11に対して店舗内サーバとして実質的に機能するものであるが、その管理PC12に実装される機能をサーバシステム20に搭載すれば、店舗2に管理PC12を設けることなく、店舗単位での管理を実現することができる。
上記の形態では、リーダ11がゲーム機3等の課金対象機器に直接取り付けられているが、課金対象機器の制御部と双方向に通信可能に接続されることにより、課金情報の受信と決済処理の結果の通知とが可能である限り、リーダ11は課金対象機器に対して物理的に離されて設置されてもよい。リーダ11は課金対象機器3の製造時点で課金対象機器3と一体化されるように取り付けられてもよいし、課金対象機器3の製造後にいわゆる後付けの機器として取り付けられてもよい。本形態の決済システム1では、課金対象機器3において、課金管理部41を構成するためのプログラムを実装する必要があり、リーダ11を後付けする場合には課金対象機器3の改修が必要である。しかし、ゲーム制御部7のように課金対象機器3の本来的な動作制御に必要な制御部から課金情報、すなわち課金されるべき料金、あるいは課金品目や数量を取り出してリーダ11に提供し、リーダ11から決済処理の結果を受け取って課金対象機器3の制御部に通知する機能を課金対象機器3に付加すれば足り、その改修の負担は比較的小さくて足りる。
上記の形態では、プリペイド方式でかつシンクライアント方式の決済システムを例に挙げたが、本発明の決済システムはこれに限定されず、ポストペイド方式の決済システムにも適用可能である。本発明の決済システムは、カード等の媒体に金銭的価値の残高を記録し、その残高情報を用いて決済を行なう方式の決済システムでも適用可能である。また、カード等の媒体に残高情報が記録されている場合でも、情報読取端末装置の側で残高情報を読み出して店舗内の管理PCやサーバシステム側で残高からの金銭的価値の消費を実行し、消費後の残高情報をカード等の媒体に書き戻す方式の決済システムにも本発明は適用可能である。この場合は、媒体から取得する決済参照情報がカードIDのような媒体識別情報のみならず、残高情報等も決済参照情報としてユーザの媒体から取得する。一方、残高情報を媒体に記録せず、サーバ側にて保持する方式の決済システムでは、サーバ上の残高情報を特定するために必要な情報(上記の形態ではカードID)を媒体から決済参照情報として取得すれば足りる。決済処理の内容も決済システムの方式に応じて当然に適宜に変更されるものである。
本発明において、アミューズメント施設は、有償でユーザの遊戯に供される少なくとも一台の遊戯機が課金対象機器として設置されていればその範囲に含まれる。また、少なくとも一台の遊戯機が存在している限り、遊戯機以外の機器、例えば自動販売機等が本発明の決済システムにおける課金対象機器に含まれてもよい。遊戯機は、ユーザに対する入出力機能と遊戯の制御に必要な各種の演算処理機能とが単一の物理的装置としてのコンピュータ装置に集約された構成に限らない。例えば、ゲームの進行に必要な演算制御をサーバ側で実行し、そのサーバに対するクライアントとしてのコンピュータ装置が入出力機能を担うべき遠隔操作端末装置として利用されることにより、複数のコンピュータ装置が協働して論理的な遊戯機として機能する構成であっても本発明の課金対象機器に含めることができる。また、遊戯機には、パチンコ機やパチスロ機(スロットマシン含む。)といった遊技機を含む。したがって、アミューズメント施設には、パチンコ機やパチスロ機等が設置された遊技場も含まれる。
上述した実施の形態及び変形例のそれぞれから導き出される本発明の各種の態様を以下に記載する。なお、以下の説明では、本発明の各態様の理解を容易にするために添付図面の参照符号を括弧書にて付記するが、それにより本発明が図示の形態に限定されるものではない。
本発明の一態様に係る決済システム(1)は、アミューズメント施設(2)に設置された少なくとも一台の遊戯機を含む課金対象機器(3A、3B…3N)にて発生したユーザへの課金に対応して該ユーザに金銭的価値を消費させる決済処理を実行し、前記決済処理の結果を前記課金対象機器に通知するアミューズメント施設向けの決済システムであって、前記課金対象機器に設けられ、前記課金に対応して、課金内容を判別するための課金情報(一例として、料金、課金品目、あるいは課金品目とその数量とを判別するための情報)を生成し、出力する課金管理手段(41、S12)と、前記課金対象機器に対応付けて設けられ 、前記課金管理手段からの前記課金情報の出力に対応して、前記ユーザが所持する媒体(4)に保持された情報であって、かつ前記決済処理にて参照されるべき決済参照情報(一例として、カードID)を前記媒体から読み取る情報読取手段(42、43、S23)と、前記課金情報に基づいて判別される課金内容と前記ユーザに消費させるべき金銭的価値の量との対応関係の設定情報(D10)に従って、前記課金管理手段から出力された課金情報に対応して前記ユーザに消費させるべき金銭的価値の量を判別する消費量判別手段(44、S31;42,S21a;34、S31b;44、S32c)と、判別された量の金銭的価値をユーザが消費するように、前記決済参照情報を参照して前記決済処理を実行し、該決済処理の結果を前記課金対象機器に通知する決済実行手段(44、34、42、S24、S33、S41、S42、S34、S25)と、を備えている。
また、本発明の一態様に係る決済制御方法は、アミューズメント施設(2)に設置された少なくとも一台の遊戯機を含む課金対象機器(3A、3B…3N)にて発生したユーザへの課金に対応して該ユーザに金銭的価値を消費させる決済処理を実行し、前記決済処理の結果を前記課金対象機器に通知するアミューズメント施設向けの決済制御方法であって、
前記課金の発生に対応して、課金内容を判別するための課金情報(一例として、料金、課金品目、あるいは課金品目とその数量とを判別するための情報)を前記課金対象機器に生成させ、出力させる手順(S12)と、前記課金対象機器からの前記課金情報の出力に対応して、前記課金対象機器に対応付けて設けられた情報読取手段(42、43)により、前記ユーザが所持する媒体(4)に保持された情報であって、かつ前記決済処理にて参照されるべき決済参照情報(一例として、カードID)を前記媒体から読み取る手順(S23)と、前記課金情報に基づいて判別される課金内容と前記ユーザに消費させるべき金銭的価値の量との対応関係の設定情報(D10)に従って、前記課金対象機器から出力された課金情報に対応して前記ユーザに消費させるべき金銭的価値の量を判別する手順(S31;S21a;S31b;S32c)と、判別された量の金銭的価値をユーザが消費するように、前記決済参照情報を参照して前記決済処理を実行し、該決済処理の結果を前記課金対象機器に通知する手順(S24、S33、S41、S42、S34、S25)と、
を備えたものである。
本発明の上記各態様によれば、課金対象機器に設けられた課金管理手段にて課金情報が生成され、その課金情報に対応してユーザの媒体から決済参照情報が読み取られるとともに、課金情報と金銭的価値の消費量との対応関係を記述した設定情報に基づいて課金内容に応じた金銭的価値の消費量が判別され、その判別された消費量に相当する量の金銭的価値をユーザに消費させるように決済処理が行なわれる。したがって、課金対象機器にてユーザがどのような課金品目をどの程度購入しようとしているかといった課金内容に応じて課金情報を生成することができ、課金対象機器側の状況を踏まえてユーザに消費させるべき金銭的価値の量を定めることができる。これにより、決済の柔軟性が高まる。しかも、課金内容と金銭的価値の消費量との関係を設定情報に記述し、その設定情報に従って金銭的価値の消費量を判別するため、課金対象機器側が割引といった課金額の変更に対応していない場合でも、設定情報を参照して消費量を定める際に消費量判別手段で様々な要素を考慮して、消費量を調整することもできる。これにより、アミューズメント施設の運営者の都合等に応じた柔軟な決済を実現することができる。
本発明の一態様においては、前記課金内容と前記ユーザに消費させるべき金銭的価値の量との対応関係が変化するように前記設定情報を変更する消費量設定手段(46、S62)をさらに備えてもよい。これによれば、設定情報の変更により、課金内容に対して実際に消費させるべき金銭的価値の量を適宜に調整することができる。
前記課金対象機器は、複数種類の課金品目をユーザの選択に従って提供するように構成され、前記課金管理手段は、前記ユーザが選択した課金品目に応じて前記課金情報を生成するものとしてもよい。単一の課金対象機器にて複数種類の課金品目が設けられていても、課金品目の選択結果に応じて課金情報を生成するものとすれば、課金品目毎の料金の相違等を金銭的価値の消費量に反映させ、それにより、課金対象機器における課金内容に応じた柔軟な決済を実現することができる。
前記情報読取手段は、前記課金対象機器とは物理的に異なる装置として構成され、かつ前記課金対象機器と通信可能な状態で当該課金対象機器に取り付けられた情報読取端末装置(11)に設けられてもよい。これによれば、課金対象機器に対して情報読取手段を別個の装置として構成し、課金対象機器の製造時のみならず、既に運営されている既設の課金対象機器に対しても情報読取端末装置を取り付けることができる。さらに、既設の課金対象機器に対して課金内容を検出して課金情報を生成する機能を付加すれば、その課金対象機器から取り出した課金情報と情報読取手段にて読み取った決済参照情報を利用しつつ、本発明に従って決済処理を実行することが可能である。
本発明の一態様に係る決済システムにおいては、サーバ(20)と、前記サーバに対し、所定のネットワーク(5)を介して通信可能なクライアントとして前記アミューズメント施設に設置された少なくとも一台のコンピュータ装置(11、12)とを具備し、前記クライアントとしてのコンピュータ装置(11)が前記情報読取手段として機能し、前記サーバ又は前記クライアントとしてのコンピュータ装置のいずれか一方(12(図4、図6、図9);11(図7);20(図8))が前記消費量判別手段として機能し、前記サーバ及び前記クライアントとしてのコンピュータ装置が協働して前記決済実行手段として機能するものとしてもよい。これによれば、サーバ・クライアント方式でかつクラインアントとしてのコンピュータ装置を決済参照情報の取得に必要な情報読取手段として機能させる決済システムに対して、課金対象機器に課金管理手段を設け、かつサーバ又はクライアントとしてのコンピュータ装置を消費量判別手段として機能するように構成すれば、本発明の上述した一態様に係る決済システムを実現することができる。サーバを利用して決済処理を実行する決済システムでは、クライアント側の設備投資の負担が相対的に小さい利点があり、その利点を活かして柔軟性の高い決済システムを実現することが可能である。
さらに、前記情報読取手段は、前記決済参照情報の少なくとも一部として、前記媒体毎にユニークな媒体識別情報(一例としてカードID)を前記ユーザが所持する媒体(4)から読み取り可能とされ、前記サーバは、ユーザが所持する金銭的価値の量を前記媒体識別情報との対応関係が判別できる状態で保持し、前記決済実行手段は、前記情報読取手段が読み取った媒体識別情報に対応付けて保持されている金銭的価値の量を、前記消費量判別手段が判別した量に従って減少させることにより、前記決済処理を実行するものとしてもよい。これによれば、ユーザの所持に係る金銭的価値の量をサーバ上に保持し、その残量(残高)から、決済に必要な量の金銭的価値を消費させるので、アミューズメント施設側における設備投資の負担がさらに小さくて足り、本発明の一態様に係る決済システムをより少ないコストで導入することができる。
前記情報読取手段は、前記決済参照情報の少なくとも一部として、前記媒体毎にユニークな媒体識別情報(一例としてカードID)を前記ユーザが所持する媒体(4)から読み取り可能とされ、前記決済実行手段には、前記決済処理の内容を前記媒体識別情報と対応付けて履歴情報(D4)に記録する履歴記録手段(34)が設けられ、前記消費量判別手段(44、S32c)は、前記媒体識別情報及び前記履歴情報をさらに参照して前記ユーザに消費させるべき金銭的価値の量を判別可能とされてもよい。これによれば、媒体識別情報を手掛かりとして履歴情報を検索することにより、ユーザによる金銭的価値の消費状況を判別し、その消費状況に応じて金銭的価値の消費量を調整することが可能となる。例えば、消費量が相対的に多いユーザに対して割引を実施するといった操作が可能である。
さらに、前記アミューズメント施設には、該アミューズメント施設又は該施設の営業主体を判別するための営業識別情報(一例として店舗コード)を出力する営業情報識別手段(44)が設けられ、前記履歴記録手段は、前記決済処理の内容を前記営業識別情報とさらに対応付けて履歴情報(D4)に記録し、前記消費量判別手段(44、S32c)は、前記媒体識別情報及び前記履歴情報に加えて、前記営業識別情報をさらに参照して前記ユーザに消費させるべき金銭的価値の量を判別可能とされてもよい。これによれば、媒体識別情報に加えて営業識別情報を手掛かりとして履歴情報を検索することにより、アミューズメント施設、あるいはその営業主体を単位とした各ユーザの消費状況を判別し、その消費状況に応じて金銭的価値の消費量を調整することが可能となる。例えば、ユーザが同一施設、あるいは同一の営業主体に係る施設で一定量以上の金銭的価値を消費した場合等に割引を実施するといった操作が可能である。
前記アミューズメント施設には、該アミューズメント施設又は該施設の営業主体を判別するための営業識別情報を出力する営業情報識別手段(一例として店舗コード)が設けられ、前記決済実行手段には、前記決済処理の内容を前記営業識別情報と対応付けて履歴情報(D4)に記録する履歴記録手段(44、S32c)が設けられ、前記消費量判別手段は、前記営業識別情報及び前記履歴情報をさらに参照して前記ユーザに消費させるべき金銭的価値の量を判別可能とされてもよい。これによれば、営業識別情報を手掛かりとして履歴情報を検索することにより、アミューズメント施設又はその営業主体を単位とした金銭的価値の消費状況を判別し、その消費状況に応じてユーザに消費させるべき金銭的価値の量を調整することが可能となる。例えば、同一施設やその営業主体を単位とした消費量が一定レベルを超えたときに割引を実施するといった操作が可能である。