JP2017211971A - 管理システム及びゲーム用テーブル - Google Patents

Abstract

【課題】ユーザに不適切な額のチップが渡されてしまうことを防止すること。
【解決手段】サーバは、ユーザのクレジットを固有の識別情報と対応付けてユーザ毎にそれぞれ記憶する。そして、所定の区画に存在するチップのチップ情報が示す額と、識別情報に対応付けて記憶されているクレジットに対して加算または減算されるべき額と、が一致しない場合、エラーを出力する制御を行う。
【選択図】図１

Description

本発明は、カジノその他の遊技場において用いられる管理システムに関する技術である。より詳細には、ゲームに参加する参加者（以下、ユーザという）に対してチップの支払いがディーラーによって行われるような場面における、チップの役割を変更するための管理システムに関する技術である。

従来、カジノその他の遊技場においては、例えばバカラやブラックジャックなどに代表されるようなカードゲームが広く行われている。これらのカードゲームにおいては、ユーザはチップをベットしてゲームに参加する。そして、一般に、ユーザがゲームに勝つと、その結果に応じたチップがディーラーからユーザに支払われる。つまり、ディーラーとユーザとの間で、実際にチップの受け渡しが行われる。そして、そのチップは、キャッシャーなどと呼ばれる窓口において景品と交換したり、換金したりすることが可能となっている。このように、チップは遊技場内で用いられる一種の代用通貨の役割を果たしている。

特許文献１では、チップの中にＲＦＩＤを埋め込み、ＲＦＩＤを用いてチップを管理する技術が開示されている。このような手法によれば、チップの真贋を判定することができるので、ユーザが偽チップを持ち込んで不正を働くことを防止することは可能である。

特表２０１５−５２５３９１号公報

しかしながら、特許文献１に記載の技術では、チップの真贋は判定することができるが、ディーラーのミスや恣意的な操作により、ユーザに不適切な額のチップが渡されてしまうことを防止することができない。

本発明の一実施形態に係る管理システムは、ユーザのクレジットを管理するサーバと、ユーザの識別情報を読み取り前記サーバに送信する識別情報読み取り部と、所定の区画内に存在するチップのチップ情報を読み取り前記サーバに送信するチップ読み取り部と、を備え、前記サーバは、ユーザのクレジットを固有の識別情報と対応付けて記憶する記憶部と、前記チップ情報が示す額と、前記識別情報に対応付けて記憶されているクレジットに対して加算または減算されるべき額と、が一致しない場合、エラーを出力する制御を行う制御部と、を有する。

本発明によれば、ディーラーとユーザとの間で行われるチップの受け渡しという、カジノその他の遊技場本来の醍醐味であるユーザ体験を維持しつつ、かつ、ディーラーのミスや恣意的な操作によりユーザに不適切な額のチップが渡されてしまうことを防止することができる。

実施形態に係る管理システムの構成の一例を示す図である。 実施形態に係るゲーム用テーブルの一例を示す模式図である。 実施形態に係るサーバの構成の一例を示す図である。 実施形態に係るサーバで記憶されるクレジット管理ＤＢの一例を示す図である。 実施形態に係るサーバで記憶される進行管理ＤＢの一例を示す図である。 実施形態に係る、ユーザがゲームに参加する場合の処理シーケンスの一例を示す図である。 実施形態に係る、ディーラーによってチップが配布される際の処理シーケンスの一例を示す図である。 実施形態に係る、ユーザがゲームに参加しようとベットをする場合の処理シーケンスの一例を示す図である。 実施形態に係る、ディーラーによってチップが配布される際の処理シーケンスの別の一例を示す図である。 実施形態に係る進行管理ＤＢの更新処理の一例を示すフローチャートである。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下の実施形態において説明する構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜用語の説明＞
本明細書では、以下のように用語を定義する。
「ゲーム用テーブル」：遊技場において各種のゲームが行われるテーブルのことをいう。一般に、一つのテーブルにつき、一人のディーラーが配置される。また、一つのテーブルにつき、複数人のユーザが同時にゲームに参加することができる。
「ディーラー」：カードを配ったり、配当に応じたチップをユーザに配ったりする遊技場側の人間のことをいう。
「ユーザ」：遊技場に来店してゲームに参加するゲストの人間のことをいう。
「バカラ」：伝統的なカードゲームであり、BANKER（胴元役）とPLAYER（客役）によるカードゲームの勝敗を、ユーザが予想して賭けるゲームをいう。ユーザは単にゲームの勝敗を予想するのみであり、その手軽さなどから世界各地のカジノで人気を博している。ディーラーは、あるルールに則してバンカー及びプレイヤのそれぞれに２枚ないし３枚のトランプカードを配り、配られた合計数の１桁目が「９」に近い方が勝ちとなる。
「ブラックジャック」：カードの合計点数が２１点を超えないように、ユーザがディーラーより高い点数を得ることを目指すゲームである。
「チップ」：ゲームにおいて用いられる代用通貨である。
「ベット」：ユーザの予想を表明して賭けることをいう。例えばバカラにおいては、バンカーが勝つのか（BANKER)、プレイヤが勝つのか（PLAYER）、または勝負が引き分けに終わるのか（タイ（TIE））を予想して、この勝敗予想に対応して賭けることをいう。また、例えばブラックジャックにおいては、ユーザは自身の勝つ可能性などを予想し、その勝敗予想に対応して賭けることをいう。
「ベット額」：ベットの際に用いる額のことである。各ユーザはベット額を任意に指定することができる。ユーザの予想が当たった場合には、ベット額に応じた配当が得られる。
「ベット領域」：ユーザがチップを置くことでベット額を表明する領域である。つまり、ユーザがチップを賭ける領域である。例えばバカラにおいては、バンカーが勝つのか（BANKER)、プレイヤが勝つのか（PLAYER）、または勝負が引き分けに終わるのか（タイ（TIE））に応じたベットをする領域がテーブル上に明示されている。
「クレジット」：ユーザが保有している残高のことである。配当が得られた場合にはクレジットが増え、予想が外れた場合には、クレジットは減る。

＜チップの不適切な額の受け渡し防止方法＞
前述したとおり、一般に遊技場で用いられるチップは、キャッシャーにおいて景品と交換したり、場合によっては現金と交換したりすることができる。したがって、ディーラーによるミスにより、あるいは、恣意的な操作により、不適切な額のチップがユーザに支払われてしまうことを防止することが求められている。

防止方法の一例としては、監視カメラを設けることである。監視カメラによってディーラーの挙動を監視しておくことである程度の抑止力にはなる。しかしながら、実際にチップの額が想定額よりも減っていた場合には、遊技場の運営者が監視カメラの映像を後追いで逐一確認する必要があり、過度な労力を要することになる。

また、防止方法の一例として、チップ制度自体を廃止してしまうことが考えられる。つまり、ディーラーとユーザとの間のチップのやり取り自体を廃止して、クレジットを電子的に管理するやり方が考えられる。例えば、遊技場のスロットマシーンなどでは、チップではなくバーコードが表記された用紙を用いて電子的にクレジットを管理する方式が採用されているケースが多い。バーコードを読み取らせることでクレジットをマシンに登録したユーザは、ベット額などを入力する入力部（タッチパネルなど）を介して所望のベットをする。そして、予想の結果に応じて電子的に管理されているクレジットが増減される。このように、スロットマシーンなどで実施されている形態のようにチップ制度自体を廃止してしまえば、ディーラーからユーザにチップが受け渡される際に、不適切な額のチップが渡されてしまうという問題は生じなくなる。しかしながら、チップ制度を廃止してしまうと、カジノその他の遊技場の醍醐味が失われてしまう。

＜カジノその他の遊技場の醍醐味＞
カジノその他の遊技場の醍醐味について説明をする。近年では、生身の人間と対面してゲームを行うのではなく、例えばオンラインカジノなどのように画面中のディーラーと対面してゲームを行う方式が増えている。

しかしながら、カジノその他の遊技場の醍醐味というものは、生身の人間（ディーラー）と対面してゲームを行い、チップのやり取りを実際に行うことによって生じるものである。例えばディーラーとユーザとの間で醸成される空気感、間、コミュニケーション、あるいは周囲のユーザも含めたテーブル全体おいて共有される現実の空間そのものが斬新なユーザ体験である。このように、現実の空間において実際に生身の人間（ディーラー）との間でゲームを行うことで得られるユーザ体験こそがカジノその他の遊技場で得られる醍醐味と言える。だからこそ、カジノその他の遊技場の中でもディーラーとユーザとの間で実際にチップのやり取りが行われるカードゲームが人気を博しているのである。

そこで、以下で説明する実施形態においては、カジノその他の遊技場本来の醍醐味を失うことなく、ディーラーからユーザにチップが受け渡される場合に不適切なチップの額が受け渡されることを防止することを実現したシステムを説明する。

既に述べたように、現在のカジノその他の遊技場において、チップはゲームに参加するための道具であり、かつ、チップ自体に代用通貨としての価値が存在する。これに対して、以下で説明する実施形態においては、チップはゲームに参加するための道具である点に変わりないが、チップ自体には何ら代用通貨としての価値を持たせないようにする。具体的には、ユーザのクレジットをチップとは別個に電子的に管理する。さらに、ディーラーからユーザに支払われる際のチップを読み取り、電子的に管理されているクレジットと比較する。そして比較の結果、不適切なチップが支払われてしまっている場合には、エラーが出力される仕組みを採用する。したがって、ユーザが保有するチップの額と、電子的に管理されているクレジットとは一致することになる。

なお、ユーザが景品に交換したり換金しようとしたりする場合には、物理的にそのユーザが保有しているチップではなく電子的に管理されているクレジットを用いて景品交換や換金が行われる。このように、チップ自体には代用通貨としての価値を持たせないようにしている。

このような技術思想によれば、電子的に管理されているクレジットに代用通貨としての役割が移行されるので、チップ自体には代用通貨としての価値がなくなる。したがって、仮にディーラーが不正の意図で不適切な額のチップをユーザに渡そうとしても、そのような行為は全く無意味な行為となる。その一方で、チップがゲームに参加するための道具であるという役割自体はそのまま存続させる。したがって、ゲームに参加するユーザは、あくまでチップをベットに用いることになり、かつ、予想が的中した場合には、ディーラーからチップが支払われることになる。したがって、ユーザにとっては従前と同様のやり方でゲームに参加をすることができるのでカジノ本来の醍醐味を引き続き味わうことができるのである。

＜＜実施形態１＞＞
＜システム構成＞
遊技場には、様々な種類のゲームが存在するが、本実施形態では、ディーラーとユーザとの間でチップの受け渡しが行われるゲームを例に挙げて説明する。このようなゲームは、一般にゲーム用テーブルを介してディーラーとユーザとが対面して行われる。

図１は、実施形態１に係る、カジノその他の遊技場において用いられる管理システムの構成の一例を示すブロック図である。図１に示す管理システムは、サーバ１０と、複数のゲーム用テーブル２０、２１、２２・・・と、遊技場の窓口に設置されたキャッシャー装置３１とを含む。なお、ここではゲーム用テーブルは複数ある例を説明するが、１つのゲーム用テーブルのみを有する構成であってもよい。また、以下ではゲーム用テーブル２０を例に挙げてゲーム用テーブルの構成等を説明するが、他のゲーム用テーブルについても同様の説明が適用できる。

サーバ１０とゲーム用テーブル２０とキャッシャー装置３１との間は、無線または有線で接続されており、情報のやり取りが可能となっている。なお、図示していないが、サーバ１０とゲーム用テーブル２０とキャッシャー装置３１との間には、ルータなどの中継装置が設けられていてもよい。また、サーバ１０は遊技場内に設けられていてもよいし、外部に設けられていてもよい。また、ゲーム用テーブル２０、サーバ１０１、およびキャッシャー装置３１は、インターネット回線を通じて接続される構成でもよい。

＜サーバの構成＞
サーバは、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスク１４、通信Ｉ／Ｆ１５を有する。ＣＰＵ１１は、ＲＯＭ１２やハードディスク１４に格納された各種の制御プログラムに従ってサーバ１０の制御を行う。ＲＯＭ１２は制御用のプログラムが格納される。ＲＡＭ１３は、各種のデータやプログラムを一時的に格納するために用いられる。ハードディスク１４は、各種のデータやプログラムを格納する。また、ハードディスク１４は、後述する各種の情報を対応付けたデータテーブルを記憶する。例えば、ハードディスク１４は、ユーザのクレジットを、固有の識別情報と対応付けたクレジット管理データベース（ＤＢ）を記憶する。識別情報とは、例えばユーザが保有する識別カードに含まれる情報である。したがって、識別情報はユーザを識別する情報であるとも言える。クレジット管理ＤＢの詳細については後述する。

＜窓口の説明＞
窓口にはキャッシャー装置３１が設けられている。窓口とは、遊技場の窓口であり、実際の通貨と遊技場内で用いられる代用通貨とを交換する場所である。本実施形態においては、遊技場に来店したユーザはそれぞれ識別カードを保有する。この識別カードは、例えばユーザが遊技場に入店した際に作成したり、事前に申請などして作成されたりするものである。ユーザは窓口で入金を行うことでその識別カードに含まれる識別情報に対応付けてクレジットを追加することができる。また、窓口に払い出しに来たユーザに対しては、窓口の係員は、そのユーザが保有する識別カードを窓口に設置されているカードリーダで読み込ませて、キャッシャー装置３１に識別情報を取得させる。そして、キャッシャー装置３１は、取得した識別情報を用いてサーバ１０にクレジットの問い合わせをすることで、払い出しに来たユーザの払い出し額を決定する。

＜ゲーム用テーブルの説明＞
図２は、ゲーム用テーブル２０の一例を示す図である。ゲーム用テーブルは、所定の区画ごとに分かれており（区画１〜６）、ゲームに参加するユーザは、それぞれの区画の席Ｃａ〜Ｃｆに座り、ゲームに参加することになる。図２に示すゲーム用テーブルは、ゲームに参加するユーザの区画が６個である例を示している。もちろん、この例に限られるものではなく、またテーブルごとに異なる区画であってもよい。また、図２はバカラで用いられるゲーム用テーブル２０の例を挙げて説明しているが、テーブルのデザイン、表記されている内容などは一例に過ぎず、様々な態様のテーブルを用いることができる。以下、ゲーム用テーブル２０に備えられる各構成について説明をする。
＜識別情報読み取り部の説明＞
ゲーム用テーブル２０の各区画には、ユーザの識別情報を読み取る識別情報読み取り部２１０ａ〜２１０ｆが備えられている。本実施形態においては、ユーザは識別カードを保有している。識別カードとしては、例えば磁気カード、ＩＣチップが埋め込まれたカード、ＲＦＩＤが埋め込まれたカードなど、様々な種別のカードを用いることができる。識別情報読み取り部２１０ａ〜２１０ｆは、カードの種別に応じた読み取り部として構成することができる。なお、識別情報は、カードのような記録媒体から得られるデータである必要はなく、例えば顔認証のような画像データを用いても、指紋認証などに代表されるような生体認証時に得られたデータを用いることもできる。また、ユーザの所有するまたは体に埋め込まれた発信器から短距離無線によって送信されるデータを用いることもできる。あるいは、これらを組み合わせてより強固な個人の識別情報を用いる形態を採用してもよい。

識別情報読み取り部２１０ａ〜２１０ｆは、読み取った識別情報をサーバ１０に送信する。なお、ゲーム用テーブル２０からサーバ１０に識別情報が送信されればよく、個々の識別情報読み取り部２１０ａ〜２１０ｆで読み取った識別情報を、個々の識別情報読み取り部２１０ａ〜２１０ｆがサーバ１０に個別にそれぞれ送信する形態でなくてもよい。たとえば、ゲーム用テーブル内の情報を管理する不図示のコンピュータなどを用いてサーバ１０に識別情報が送信されるような形態でもよい。以下の実施形態では、識別情報読み取り部２１０がサーバ１０に識別情報を送信するとして説明をする。

なお、ゲーム用テーブル２０側からサーバ１０に識別情報が送信される際には、サーバ１０においてゲーム用テーブルを特定するためのゲーム用テーブルＩＤや、識別情報を読み取った識別情報読み取り部２１０を特定するための、すなわち、対応する区画を特定するための区画ＩＤとが併せて送信されるように構成されていてもよい。そして、サーバ１０は、これらのＩＤを用いて、送信された識別情報がどのゲーム用テーブルのどの区画において読み取られた識別情報であるかを特定する処理を行うことができる。なお、例えば送信元のＩＰアドレスやＭＡＣアドレスなどからゲーム用テーブルとその区画とをサーバ１０で特定することができるような構成であれば、前述したようなＩＤ等はゲーム用テーブル２０側からサーバ１０に対して送信されなくてもよい。

＜表示部の説明＞
ゲーム用テーブル２０の各区画には、ユーザのクレジットを表示する表示部２２０ａ〜２２０ｆがそれぞれ設けられている。ユーザがたとえば区画１に座り、識別情報読み取り部２１０ａに識別カードを読み取らせる動作を行うと、識別情報読み取り部２１０ａは、読み取った識別情報をサーバ１０に送信する。サーバ１０は、識別情報に対応付けてクレジットを記憶しているので、サーバ１０は、送信された識別情報に対応付けられたクレジットのデータを、その送信元と同じ区画の表示部に送信する。ゲーム用テーブルの表示部では、このようにしてサーバ１０から送信されたクレジットを表示する。

なお、本実施形態においては、各区画に表示部が設けられている構成を例に挙げて説明するが、これに限られるものではない。例えば、ゲーム用テーブルにおいて１つの表示部が備えられており、ゲームに参加しているユーザのクレジットの一覧がその表示部に表示されてもよい。また、このような各ユーザのクレジットが表示される表示部は、各ユーザ側に見えるようにテーブル上に配置されてもよいし、テーブルの頭上の空間などに配置されてもよい。あるいは、各ユーザのクレジットが表示される表示部は、ディーラー側の手元部分に配置される形態でもよい。
＜チップ読み取り部の説明＞
次に、各区画に設けられるチップ読み取り部２４０について説明する。チップ読み取り部２４０は、例えばチップに含まれているＲＦＩＤからそのチップの情報を読み取り、読み取ったチップの情報をサーバ１０に送信する。サーバ１０は、どのゲーム用テーブルのどの区画に存在するチップの情報であるかを、前述の識別情報で説明した形態と同様の形態で特定できるように構成されている。

例えば、ディーラーＤまたはユーザによってある区画に置かれるチップが、１０ドルのチップ３枚と１ドルのチップ５枚であっとする。このような場合、チップ読み取り部は、その区画に存在するチップは、１０ドルのチップが３枚、１ドルのチップが５枚である、というチップの情報を読み取る。そして、読み取った個々のチップの情報をサーバ１０に送信し、サーバ１０では、これらを計算して４５ドルの額のチップがその区画に存在すると判定することになる。なお、個々のチップの情報を送信せずに、チップ読み取り部２４０において読み取ったチップの合計額を算出し、その算出した額をサーバに送信する形態でもよい。

図２では、説明の便宜上、区画２を例に挙げてチップ読み取り部についての説明することとするが、他の区画についても同様である。区画２においては、チップからチップ情報を読み取るチップ読み取り部が２か所に設けられている。具体的には、ベットがされたチップを読み取るベットチップ読み取り部（第一のチップ読み取り部）２４０ａとディーラーから払い出された（ペイアウトされた）チップを読み取るペイアウトチップ読み取り部（第二のチップ読み取り部）２４０ｂとが設けられている。ベットチップ読み取り部２４０ａもペイアウトチップ読み取り部２４０ｂも、チップに埋め込まれているＲＦＩＤを読み取るアンテナが埋め込まれている。なお、ここではベットチップ読み取り部２４０ａとペイアウトチップ読み取り部２４０ｂとに分ける構成を例に挙げて説明したが、これらを区別せずに一つのチップ読み取り部が１つの区画に備わっている構成としてもよい。また、本実施形態においてはチップにＲＦＩＤが埋め込まれている場合を例に挙げて説明したが、これに限られるものではなく、所定の区画に存在するチップの額面がサーバ側で把握することができるような構成であれば、いずれの構成を採用してもよい。

なお、図２に示すチップ読み取り部は、あくまで図２のような表記がなされているゲーム用テーブルにおけるチップ読み取り部の一例に過ぎない。図２のゲーム用テーブルはバカラを想定したテーブルであるが、バカラ一つを例に挙げてもそのゲーム用テーブルには様々な種類のテーブルがあり、また、テーブル上の表記についても多様のものである。よって、ベットチップ読み取り部やペイアウトチップ読み取り部は、使用されるゲーム用テーブルに応じた位置に設けることができる。
＜カードシューの説明＞
ゲーム用テーブルには、カードシュー２３０も配置される。カードシューとは、ゲームに用いるトランプカードを格納するケースである。ディーラーは、カードシューから順次ゲームに用いるトランプカードを取り出してテーブル上の所定の領域に配る。本実施形態においては、カードシュー２３０にカード読み取り部２３１が設けられている。例えばカード読み取り部２３１は、ラインスキャナによってカードに表記されているパターン認識を行い、その認識結果に基づいて所定の領域に配られるカードの種別（「スペードの２」などのように、カードのスートや数）を特定することができる。あるいは、カード読み取り部２３１は、トランプカードに埋め込まれたＲＦＩＤを読み取るように構成することができる。カード読み取り部２３１は、読み取ったＲＦＩＤに含まれるデータに基づいて、所定の領域に配られるカードの種別を特定してもよい。また、カード読み取り部２３１は、トランプカードを撮像する撮像部を有する構成でもよい。そして、カード読み取り部２３１は。撮像部によって撮像された画像データを解析することで所定の領域に配られるカードの種別を特定するように構成されていてもよい。その他、カード読み取り部２３１は、カードに表記された特定のコードを読み取ることでカードの種別を特定する構成であってもよく、その他いずれの形態を採用してもよい。特定されたカードの種別を示すカード情報は、カード読み取り部２３１からサーバ１０に送信される。

このように、カード読み取り部２３１がテーブル上の所定の領域に配られるカードを読み取ることによって、例えばバカラにおいてはＢＡＮＫＥＲとＰＬＡＹＥＲとに対してどのカードが配られたかをサーバ１０において判定することができる。バカラの場合には、ＢＡＮＫＥＲまたはＰＬＡＹＥＲに対してディーラーＤがカードを配るか否かが全てルールによって明確に定義が定められており、ディーラーやユーザの意思が介入する余地がない。したがって、サーバ１０は、順番に取り出されるカードを順次読み取るカード読み取り部２３１から送信されたカード情報に基づいてゲームの結果を判定することができる。なお、上記の説明においてはサーバ１０においてゲームの結果を判定するとして説明したが、ゲーム用テーブルに設けられる不図示のコンピュータによってゲームの結果の判定が行われ、その結果がサーバ１０に送信される形態でもよい。

このように、サーバ１０は、カード情報に基づいて、例えばＢＡＮＫＥＲまたはＰＬＡＹＥＲのどちらが勝ったか、あるいは、引き分け（タイ）か、などのようなゲームの進行を示す情報（以下、進行情報と呼ぶ）を取得可能に構成されている。

なお、カード読み取り部２３１から得られるカード情報を例に挙げて説明したが、進行情報がサーバ１０で取得される構成はこれに限られるものではない。例えば、監視カメラなどによってゲーム用テーブルの様子を撮影し、撮影した映像に基づくゲームの進行情報がサーバ１０で取得されるような構成でもよい。あるいは、ディーラーやカジノ側のスタッフなどが適宜、結果をデータ入力するなどして、進行情報がサーバ１０で取得される構成でもよい。また、これらの組み合わせであってもよい。また、進行情報には、ゲームの結果のほかに、ゲーム実施中であるか、ベット期間中であるか、ペイアウト期間中であるかなどの現在のゲーム用テーブルの状態を示す情報が含まれていてもよい。

＜サーバの構成＞
次に、サーバの具体的な構成を説明する。図３は、サーバ１０の具体的な構成の一例を示すブロック図である。サーバ１０は、識別情報受信部３１０、チップ情報受信部３２０、クレジット送信部３３０、進行情報取得部３４０、記憶部３５０、更新部３６０、制御部３７０、クレジット更新要求受信部３８０を有する。図３に示す各部は、ＣＰＵ１１がＲＯＭ１２またはハードディスク１４に格納されたソフトウェアプログラムをＲＡＭ１３に一時的に展開し、展開したプログラムに従った処理を行うことで、ＣＰＵ１１が図３に示す各部として機能する。また、識別情報受信部３１０、チップ情報受信部３２０、クレジット送信部３３０、進行情報取得部３４０、およびクレジット更新要求受信部３８０は、ＣＰＵ１１と通信Ｉ／Ｆ１５とが協働してこれらの機能部として動作する。また、記憶部３５０と更新部３６０は、ＣＰＵ１１とハードディスク１４とが協働してこれらの機能部として動作する。なお、本実施形態においては、ソフトウェアによる処理によってサーバの構成を説明することとするが、同様の処理を専用に行うハードウェアによって、あるいは、このようなハードウェアとソフトウェアとの組み合わせによって、処理を実現するように構成されていてもよい。

記憶部３５０は、クレジット管理ＤＢを記憶する。クレジット管理ＤＢとは、前述のとおり、ユーザのクレジットを、固有の識別情報と対応付けて記憶するデータベースのことである。図４は、記憶部に記憶されているクレジット管理ＤＢの一例を示す図である。

例えばユーザが識別カードを窓口などにおいて提示してクレジットを追加しようとする場合、次のような処理が行われることになる。窓口においてユーザが提示した識別カードから識別情報が読み取られる。そして、窓口のキャッシャー装置３１は、読み取った識別情報と、追加されるクレジットの額とを含むクレジットの更新要求をサーバ１０に送信する。サーバ１０のクレジット更新要求受信部３０８においてクレジットの更新要求を受信すると、制御部３７０は更新部３６０を制御して、記憶部３５０に記憶されているクレジット管理ＤＢを更新する。すなわち、更新要求に含まれるクレジットを、更新対象の識別情報に対応するクレジットに加算する。このようにして、クレジットにチャージがなされ、記憶部３５０に記憶されるクレジットが更新されることになる。

なお、ここでは窓口のキャッシャー装置３１においてクレジットにチャージされた場合を例に挙げて説明したが、窓口においてユーザが識別カードを提示して払い出しをする場合も、「クレジットの追加」が「クレジットの削減」に変更される点を除けば、同様の処理となる。

また、記憶部３５０は、進行管理ＤＢを記憶する。図５は、進行管理ＤＢの一例を示す図である。進行管理ＤＢは、ゲーム用テーブルを特定するテーブルＩＤの項目と、そのゲーム用テーブル内での区画を示す項目と、ゲームに参加するユーザの識別情報を示す項目と、ベットした額を記憶する項目と、ベット先を示す項目と、更新すべき額を示す項目とが含まれている。進行管理ＤＢを用いた処理は後述する。

識別情報受信部３１０は、各ゲーム用テーブルの識別情報読み取り部２１０から送信された識別情報を受信する。制御部３７０は、識別情報受信部３１０において受信した識別情報をキーとして記憶部３５０に記憶されているクレジット管理ＤＢを検索する。そして、制御部３７０は、その識別情報に対応付けて記憶部３５０に記憶されているクレジットをクレジット送信部３３０を用いて識別情報の送信元のゲーム用テーブルに送信する。

進行情報取得部３４０は進行情報を取得する。例えば、進行情報には、前述のようにテーブルで行われているゲームの結果や、ゲームの状態（たとえば、ゲーム実施中、ベット期間中、ペイアウト期間中など）などの情報が含まれる。

更新部３６０は、制御部３７０の制御によって、記憶部３５０に記憶されているテーブルを更新する。例えば、更新部３６０は、クレジット更新要求受信部３８０で受信したクレジット更新要求（入金要求）に基づいて図４に示すクレジット管理ＤＢに管理されているクレジットを更新する。また、更新部３６０は、識別情報受信部３１０、チップ情報受信部３２０、進行情報取得部３４０で得られる各情報に基づいて図５に示す進行管理ＤＢを更新したり図４に示すクレジット管理ＤＢを更新したりする。詳細は後述する。

＜ゲームに参加するシーケンス＞
以下では、ユーザがテーブルに着席してゲームに参加する場面を想定し、各場面において行われる各処理を具体的に説明する。なお、識別カードに対応付けたクレジットはすでにクレジット管理ＤＢに登録済みであるものとして説明する。

図６は、ユーザがゲームに参加しようとゲーム用テーブルの所定の区画に着席して、識別カードを識別情報読み取り部２１０に読み取らせた場合の処理シーケンスの一例を示す図である。つまり、ユーザがゲームに参加する場合の初期処理の一例を説明する。ここではユーザが図２の区画２に着席した場合の例を説明する。

ステップＳ６０１において識別情報読み取り部２１０ｂは、識別カードを読み取って識別情報を得る。そして、ステップＳ６０２において識別情報読み取り部２１０ｂは、識別情報をサーバ１０に送信する。

サーバ１０の識別情報受信部３１０において識別情報を受信すると、ステップＳ６１１において制御部３７０は、送信元のＩＰアドレスなどから、識別情報の送信元のゲーム用テーブルと区画とを特定する。

そして、ステップＳ６１２において制御部３７０は更新部３６０を制御して、図５に示すような進行管理ＤＢを更新させる。すなわち、更新部３６０は、ステップＳ６１１において特定されたゲーム用テーブルと区画とに対応する、進行管理ＤＢ内の識別情報項目に、識別情報受信部３１０で受信した識別情報を追加する。例えば、テーブルＩＤがＴ１１で特定される区画２に、識別情報がＵ１０３２である識別カードを所持するユーザが着席する。そして、識別情報読み取り部２１０によって識別情報が読み取られると、上述した処理にしたがって更新部３６０が当該識別情報を進行管理ＤＢの対応する位置に書き込む。これにより、制御部３７０は、Ｕ１０３２で識別されるユーザが、テーブルＩＤがＴ１１の区画２に着席してゲームに参加しようとしている状態であることを特定することができる。

次に、図６の処理シーケンスに戻って説明を続ける。ステップＳ６１３において制御部３７０は、記憶部３５０に記憶されている図４に示すクレジット管理ＤＢを、受信した識別情報をキーとして検索する。そして、制御部３７０は、検索の結果が合致した識別情報に関連付けられているクレジットを、クレジット送信部３３０を用いてゲーム用テーブルに送信する。具体的には、クレジット送信部３３０は、ステップＳ６１１で特定されたゲーム用テーブルの区画に対応する表示部に、クレジットを送信する。

ステップＳ６２１において、クレジットを受信した表示部は、そのクレジットを表示する。

以上のような処理により、ゲームに参加しようとするユーザが、ゲーム用テーブルの所定の区画における識別情報読み取り部に識別情報を読み取らせると、対応するクレジット（すなわち、自身の保有するクレジット）が表示部に表示される。

＜ディーラーによるチップの配布時の処理シーケンス＞
次に、ディーラーによってチップが配布される場合における処理シーケンスについて説明する。なお、ディーラーによってチップが配布される場合の例としては、（１）ユーザが最初にテーブルに着席してゲームに参加しようとする場合、（２）ユーザがゲームを終了しようとディーラーにチップの両替（たとえば、少額単位のチップをより単位の大きい額のチップに交換するなど）を依頼し、この依頼に応じてディーラーからチップが配布される場合、（３）ユーザがゲームに勝つなどのように、ゲームの結果に基づいてディーラーからチップが配布される場合、などがある。このうち、（３）のケースについては別の項で説明することにし、ここでは（１）と（２）の場合についての説明をする。

ユーザが最初にテーブルに着席してゲームに参加しようとする場合、ディーラーからチップを配布される。つまり、図６で示した処理に引き続き、ディーラーからチップが配布されることになる。この場合、ディーラーは、表示部に表示されているクレジットに相当するチップをユーザに配布する。なお、他のテーブルなどですでにゲームを行いチップを保有しているユーザに対しては、このような配布が行われなくてもよい。

ディーラーからユーザに対してチップが配布される場合には、人の手を介してチップが配布されることになるので、先に説明したようなチップの誤配が生じやすい。そこで本実施形態においては、制御部３７０は、ディーラーによってチップが配布される際に、配布されたチップのチップ総額と、サーバ１０で記憶しているクレジットとが一致するかを判定する。そして、一致しないと判定された場合に、エラーを出力するように制御をする。

図７は、ディーラーによってチップが配布される際の処理シーケンスの一例を示す図である。ゲームに参加しようとテーブルに着席して識別カードを識別情報読み取り部２１０ｂに読み取らせたユーザに対して、ディーラーは表示部２２０ｂに表示されたクレジットを配布する。すなわち、ディーラーが、当該ユーザの着席している区画２のペイアウトチップ読み取り部２４０ｂの読み取り可能な領域に、表示部２２０ｂに表示されたクレジットに相当するチップを置く。すると、ステップＳ７０１においてペイアウトチップ読み取り部２４０ｂは、読み取り対象の領域に存在するチップを読み取ることでチップ情報を得る。そして、ステップＳ７０２においてペイアウトチップ読み取り部２４０ｂは、チップ情報をサーバ１０に送信する。

ステップＳ７１１においてサーバ１０の制御部３７０は、図６のステップＳ６１１で説明したような手法と同様な手法によって、送信元のゲーム用テーブルと区画とを特定する。ゲーム用テーブルと区画とを特定すると、制御部３７０は、図５で示した進行管理ＤＢを参照することで、その区画においてゲームに参加しているユーザの識別情報を特定する。そして、制御部３７０は、図４で示したクレジット管理ＤＢを参照して、その特定した識別情報に対応付けられているクレジットを抽出する。

ステップＳ７１２においてサーバの制御部３７０は、このようにして抽出されたクレジットと、送信されたチップ情報とを比較して、両者の額が一致するかを判定する。例えば、サーバ１０の記憶部３５０で記憶されているクレジットの額が１００ドルである場合に、ディーラーが配布したチップが１５０ドルである場合には、制御部３７０は、ペイアウトチップ読み取り部２４０ｂによって読み取られたチップ情報が示す額と一致しないと判定する。

ステップＳ７１２において両者が一致しないと制御部３７０が判定した場合、ステップＳ７１３において制御部３７０は、エラーを出力する制御をする。ステップＳ７１２において両者が一致すると制御部３７０が判定した場合、ステップＳ７１３の処理はスルーされる。

ステップＳ７１２で制御部３７０において行われるエラーの出力の制御の一例としては、ゲーム用テーブルの対応する区画２の表示部２２０ｂにエラーを示す画面を表示することが挙げられる。しかしながら、エラーを出力する制御を行う態様はこれに限られるものではなく、様々な態様が可能である。例えば、ゲーム用テーブルの各区画において警告灯が備えられており、その警告灯を点灯、点滅させるような信号を制御部３７０が出力するように制御する態様でもよい。あるいは、ゲーム用テーブルに備えられたスピーカーなどから音声による警告が出力されるように制御部３７０が制御信号を出力するように制御する形態でもよい。また、遊技場運営者の携帯端末などにエラーが生じたことを通知する形態でもよい。

図７の例では、ユーザが最初にテーブルに着席してゲームに参加しようとする場合を例に挙げて説明したが、ユーザがディーラーにチップの両替を依頼するような場合も同様である。また、ディーラーから配布されたチップのみならず、ユーザが自身で保有するチップを置くようなケースでも適用できる。例えば、ユーザがゲームを途中で終了してゲーム用テーブルから退席しようとするに場合に、自身の保有しているチップをペイアウトゾーンに全て置く。すると、ペイアウトチップ読み取り部２４０ｂは、読み取り対象の領域に存在するチップのチップ情報を読み取り、その後は上述した処理と同様の処理が行われる。

＜ユーザがベットする場合の処理シーケンス＞
次に、ユーザがゲームに参加してベットをする場合の処理シーケンスの一例を説明する。図８は、ユーザがゲームに参加しようとベットをする場合の処理シーケンスの一例を示す図である。

ユーザは、バカラゲームに参加しようとする場合、ゲームの結果を予想する。そして、図２に示すように、自身が座っている区画における、予想した項目に対応する領域（図２の例では、ＰＬＡＹＥＲ、ＢＡＮＫＥＲ，ＴＩＥ）に、チップを置く。このように予想した項目に対応する領域にユーザがチップを置くことを、ベットするという。このとき置かれたチップの種類と枚数とによって示される総額が、ユーザのベットした額となる。

ステップＳ８０１においてベットチップ読み取り部２４０ａは、読み取り対象領域に存在するチップを読み取ることでチップ情報を得る。例えば、１０ドルのチップが２枚、５ドルのチップが１枚存在する場合には、存在するチップの額は２５ドルであるというチップ情報を得る。そして、ステップＳ８０２においてベットチップ読み取り部２４０ａは、ステップＳ８０１で得たチップ情報をサーバに送信する。なお、ここではベットチップ読み取り部２４０ａは、チップの総額を示すチップ情報をサーバ１０に送信する形態を例に挙げて説明したが、これに限られるものではない。例えば、ベットチップ読み取り部２４０ａは、読み取ったチップの種別と枚数とを示すチップ情報をサーバに送信し、サーバ側でチップの総額を算出するような形態であってもよい。

また、チップ情報には、そのチップが置かれた予想項目（図２の例では、ＰＬＡＹＥＲ、ＢＡＮＫＥＲ，ＴＩＥ）を特定する情報をさらに含んでいてもよい。例えば、ベットチップ読み取り部２４０ａは、読み取り可能な領域を分割したサブ領域のチップを読み取ることが可能に構成されており、そのサブ領域を特定する情報をチップ情報に含めて送信することができる。なお、説明した形態は一例に過ぎず、ユーザがどの予想項目に対していくらベットしたかをサーバ１０側で特定できればいずれの形態を採用してもよい。

サーバの制御部３７０は、ステップＳ８１１においては、図６や図７で説明した処理と同様に、送信元のゲーム用テーブルと区画とを特定する。また制御部３７０は、上述したように、ベットされた予想項目をさらに特定する。

ステップＳ８１２において、サーバの制御部３７０は更新部３６０を制御して、記憶部３５０に記憶されている進行管理ＤＢを更新する処理を行う。ステップＳ８１２の処理の詳細は後述する。

ステップＳ８１３においてサーバは、ペイアウトチップ読み取り部からチップ情報が送信された場合にはエラー判定処理を行う。この処理は、オプションで行われる処理であり、ペイアウトチップ読み取り部からチップ情報が送信されない場合には、サーバはエラー判定処理は行わなくてよい。例えば、ユーザの予想が外れた場合には、ベットしたチップはディーラーによって回収されてしまい、ディーラーからチップが払い戻されることはないからである。また、後述するように、ユーザの予想が当たったとしても、引き続きユーザが払い戻されたチップを、そのままベット用のチップとして用いる場合もある。したがって、ユーザの予想が的中して、ディーラーから支払われたチップを一旦ユーザが保有するような場合にステップＳ８１３の処理が行われる。

図９は、ステップＳ８１３の詳細を説明する図である。図９の処理は、基本的に図７で説明した処理と同様の処理であり、ステップＳ９１２の処理が図７で説明した処理と異なる処理となる。すなわち、ステップＳ９０１、Ｓ９０２、Ｓ９１１、Ｓ９１３、Ｓ９１４の処理は、それぞれステップＳ７０１、Ｓ７０２、Ｓ７１１、Ｓ７１３、Ｓ７１４の処理と同様の処理とすることができる。

ステップＳ９１２において制御部３７０は、ペイアウトチップ読み取り部から送信されたチップ情報が示す額が、クレジットに対して加算または減算されるべき額と一致するかを判定する。例えば、ベットしたチップが２０ドルであり、ユーザの予想が的中して４０ドルのチップが支払われる場合を考える。ここで、（１）ゲームの結果が判明した時点でクレジットの加算または減算を行う方法と、（２）ベットしたチップの額をゲームの結果が判明する前に減額する方法、つまり、ベットがされた時点でクレジットを一旦減額する方法とが考えられるが、いずれの手法を採用してもよい。（１）の方法を採用する場合、図８のステップＳ８１２の処理によって、２０ドル分のチップがクレジットに対して加算されるべき額であると算出されている。（２）の方法を採用する場合、４０ドル分のチップがクレジットに対して加算されるべき額であると算出されている。以下の説明では、上記（１）のように、ゲームの結果が判明した時点でクレジットの加算または減算を行う方法を例に挙げて説明するものとする。

ステップＳ９１２における判定の結果、ペイアウトチップ読み取り部から送信されたチップ情報が示す額が２０ドルと一致しない場合には、制御部３７０は、ステップＳ９１３に進み、エラーを出力する制御を行う。

次に、図８の処理の説明を続ける。
ステップＳ８１４において制御部３７０は、ステップＳ８１２の進行管理ＤＢの更新処理において算出されている、クレジットに対して加算または減算されるべき額をクレジットに反映して、クレジット管理ＤＢに管理されているクレジットを更新する。そして、更新後のクレジットを表示部２２０ｂに送信する。これを受けて表示部２２０ｂは、ステップＳ８２１において更新後のクレジットを表示する処理を行う。

以上のような処理を行うことで、ゲームの結果に応じて適宜クレジットの更新処理が行われることになる。

なお、ここではディーラーからチップが払い戻されるたびにエラー判定処理を行う例を説明したが、この限りでない。例えば、ユーザが席に着席してから退席するまでの間、つまり、連続してゲームを実施している場合にはエラー判定処理を省略し、ユーザがゲームを終了して退席する場合のみ、つまり、図７で示すような場合にのみ、エラー判定処理を行う形態でもよい。なお、ユーザが退席する場合には、ユーザまたはディーラーがゲーム用テーブルに設けられている不図示の退席ボタンを押すことでサーバにそのユーザが退席することを通知されてもよい。あるいは、識別カードを抜きだすことで識別情報読み取り部がユーザが退席することをサーバに通知する構成でもよい。

＜進行情報に応じた進行管理ＤＢの更新処理＞
次に、サーバによって行われる、ステップＳ８１２の進行管理ＤＢの更新処理を、図１０をもとに説明する。進行情報とは、先に説明したように、ゲームの結果などのゲームの進行状態を示す情報である。

図１０は、サーバ１０によって実行される、進行管理ＤＢの更新処理の一例を示すフローチャートである。

ステップＳ１００１において制御部３７０は、例えば図５に示す進行管理ＤＢのベット額およびベット先を更新する。制御部３７０は、例えば図８のステップＳ８１１の特定処理によって特定された項目に対して進行管理ＤＢのベット額およびベット先を更新する。

ステップＳ１００２において進行情報取得部３４０は、ディーラーによって配られるトランプカードのカード情報を取得する。例えば、スペードの１などのトランプカードの種別を特定するカード情報を取得する。

ステップＳ１００３において制御部３７０は、ステップＳ１００２で取得したトランプカードのカード情報に基づいてゲームの結果を判定する。この判定の結果、勝敗がついたと判定できた場合にはステップＳ１００４からステップＳ１００５に処理を進める。勝敗がついたと判定できない場合には、ステップＳ１００２に戻り、場に配られる次のトランプカードのカード情報の取得を行う。

先に説明したように、バカラはゲームの状況に応じてＢＡＮＫＥＲやＰＬＡＹＥＲに対して次のカードがディーラーから配布されるか否かが明確にルール化されているので、ゲームに参加するディーラーやユーザの意思が配られるトランプカードに影響を及ぼすことがない。したがって、カードシューから順番に取り出されるカードをカード読み取り部が順次読み取ることなどによって、配られたトランプカードの種別を特定し続けることで、制御部３７０は、ゲームの結果を判定することができる。

ステップＳ１００５において、制御部３７０は、ゲームの結果に基づいて、クレジットに対して加算または減算されるべき金額を算出する。例えば図５の進行管理ＤＢ（ここで「更新すべき額」は未更新であるとする）の状態において、ＰＬＡＹＥＲが勝利したと仮定する。図５の進行管理ＤＢの「更新すべき額」の項目においては、ＰＬＡＹＥＲが勝利した場合に加算されるべき額が制御部３７０によって算出され、更新部３６０によって更新されることになる。すなわち、ＰＬＡＹＥＲに予想したユーザに対しては、ベットした額と同額が更新すべき額として算出され、ＢＡＮＫＥＲに予想したユーザに対しては更新すべき額がベット額分を減算した額として算出され、ＴＩＥを予想したユーザには、更新すべき額が０と算出される。

したがって、例えば、区画２のユーザに対しては、ディーラーから２０ドル分のチップが払われることになる。このとき、図９で説明したように、この支払われる２０ドル分のチップに相当するチップ情報が示す額と、図５の進行管理ＤＢで記録されている更新すべき額とが一致するかの判定が行われることになる。

その後、図８のステップＳ８１４で説明したように、更新部３６０は、進行管理ＤＢに含まれる「更新すべき額」に記憶されている値を、クレジット管理ＤＢに記憶されているクレジットに反映することで、クレジット管理ＤＢに記憶されている、区画２のユーザの識別情報に対応するクレジットを更新する。そして、前述の図８のステップＳ８１４で説明したように、更新後のクレジットが表示部に送信され、表示されることになる。

なお、遊技場における実際の利用形態として、ユーザがディーラーから配布されたチップをそっくりそのまま用いて再度ベットをするような形態も考えられる。つまり、払い戻されたチップをペイアウトチップ読み取り部２４０ｂに置くことなく、ユーザがそのままベットチップ読み取り部２４０ａに置く形態も考えられる。このような形態であっても、これまで説明した処理と同様の処理が行われる。

＜実施形態の効果＞
以上説明したように、本実施形態では、チップからは金銭的な価値を取り除き、金銭的な価値はサーバの記憶部３５０で記憶する形態を採用している。その一方で、従前と同様にディーラーとユーザとの間でチップのやり取りが行われることになる。したがって、ユーザにとっては従前と同様のやり方でゲームに参加をすることができるのでカジノ本来の醍醐味を引き続き味わうことができる。また、ユーザのクレジットはサーバで管理されているので、ディーラーがミスや恣意的な行為によりチップを多く渡すような場合には、エラーが出力されるので、その場でミスに気が付き、修正がなされることになる。

また、本実施形態では、ゲームに参加する際に識別カードを用いる例を説明した。このように、ゲームに参加する際に識別カードなどを用いることによってカジノに来店するユーザを管理することができる。例えば、来店頻度、ゲームの嗜好、クレジットなどをその識別カードを作成する際に入力される各種の個人情報などと組み合わせて来店するユーザの情報管理を行うことが可能となる。このようにユーザの個別管理を行うことで、例えばユーザがゲームにのめり込んでしまうことを防止するといった効果も得られる。

＜その他の実施形態＞
なお、以上説明した実施形態においては、ベットチップ読み取り部とペイアウトチップ読み取り部とを別々に構成する例を説明したが、ゲームの進行状態に応じてベット期間中であるか払い戻し期間（ペイアウト期間）中であるかはサーバ側で把握することができる。したがって、チップ情報受信部３２０が受信したチップ情報と、進行情報取得部３４０で取得した進行情報とに基づいて、送信されたチップ情報はベットされたチップに関するチップ情報であるのか、ペイアウトされたチップに関するチップ情報であるかを制御部３７０が適宜判定するような形態を採用してもよい。

また、以上説明した実施形態においては、バカラを例に挙げて説明したが、これに限られるものではない。例えば、カジノにおいて行われる代表的なカードゲームとしては、ブラックジャックが挙げられる。ブラックジャックの場合には、バカラと異なり、ユーザの意思によってゲームの結果が変わってくる。例えば、ユーザがさらなるトランプカードを追加を要求するか（ヒット）、それともトランプカードを追加しないか（ステイ、またはスタンド）をユーザ自身の意思によって決定することができる。したがって、ブラックジャックの場合には、カードシューから場に配られるトランプカードを読み取るだけではなく、例えばテーブル上のカードの画像からゲームの結果を判定したり、あるいは、カード自体にＲＦＩＤなどを埋め込み、どのカードが誰に配布されたか、などを確認できるように構成することとよい。

また、一般にカジノにおいては、ご祝儀としてチップ（祝儀）がユーザから渡される場合がある。以下、ゲームで用いるチップと区別するために、ご祝儀の意味で用いるチップのことを「チップ（祝儀）」と記載する。例えば、各テーブルを回ってドリンクを配るドリンクガールからドリンクの提供を受ける場合にはドリンクガールに対してチップ（祝儀）を渡したり、ゲームに大勝した場合にはディーラーに対してチップ（祝儀）を渡す慣習がある。このようなチップ（報酬）を渡すような慣習もまた、チップを用いるカジノの醍醐味と言える。上述した実施形態によれば、サーバの記憶部３５０で記憶されているクレジットとユーザがゲームのために保有するチップとが一致しない場合にエラーを出力する形態を採用している。したがって、チップ（祝儀）をドリンクガールやディーラーに渡してしまうと額が一致しなくなりエラーを出力してしまう。

そこで、例えばチップ（祝儀）用のチップを読み取る読み取り部を設け、その読み取り部においてチップを読み取った場合には、その額をクレジットから差し引く処理を行う。このような処理を行えば、ユーザは、ドリンクガールやディーラーにチップ（祝儀）を渡す前にチップ（祝儀）用の読み取り部に一旦チップを置いてから祝儀としてチップを渡せば、サーバの記憶部３５０で記憶している額との不一致が生じないので、エラーが出力されてしまうことを防止することができる。

また、上記説明した実施形態においては、ゲーム用テーブルにおけるカードゲームを例に挙げて説明したが、これに限られるものではない。例えばルーレットのようなテーブルゲームにおいても本発明を適用することが可能である。ルーレットの場合には、ベットする箇所がゲームに参加するユーザで共通の領域となる。したがって、ベットに用いるチップをユーザ毎に識別可能なように、参加するユーザを識別する情報をチップ情報にさらに含めておけばよい。

また、上記説明した実施形態においては、識別カードには識別情報が記載されており、サーバでこの識別情報と関連付けてクレジットが記憶され、更新される形態を例に挙げて説明したが、この例に限られることはない。例えば、識別カード自体にクレジットを記憶させておき、また、ゲーム用テーブルに設けられる識別情報読み取り部は、識別カードに情報を書き込む書き込み部としても用いることで、識別カード自体にクレジットを記憶するような形態を採用してもよい。このような形態であっても、ディーラーによるチップの誤配を防止することができる。また、ユーザの個別管理も同様にサーバにおいて行うことができる。

また、上記説明した実施形態においては、クレジット管理ＤＢや進行管理ＤＢのようなデータテーブル形式で情報が管理されている形態を例に挙げて説明したが、これに限られるものではなく、どのような形式で情報が記憶されていてもよい。

また、スロットマシーンなどの従来から電子的にクレジットを管理している装置においても共通の識別カードを用いることができる。すなわち、ユーザが識別カードをスロットマシーンに読み取らせると、サーバ１０で管理されているクレジットがそのスロットマシーンに利用可能なクレジットの額として登録されてもよい。

また、本実施形態で説明したサーバ１０は、図３で示す各部の処理を複数の装置によって分散して処理を行うような形態を採用してもよい。また、上述した実施形態の機能を実現するためのプログラムコードを、１つのコンピュータ（ＣＰＵ、ＭＰＵ）で実行してもよい。あるいは、複数のコンピュータが協働することによって実行してもよい。また、プログラムコードをコンピュータが実行する形態でもよい。あるいは、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。また、プログラムコードの一部をハードウェアで実現し、残りの部分をコンピュータが実行してもよい。

また、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを適宜読み出して実行することで本発明が実現されてもよい。

１０ サーバ
２０ 遊戯テーブル
３１ キャッシャー装置
２１０ａ〜２１０ｆ 識別情報読み取り部
２２０ａ〜２１０ｆ 表示部
２３０ カードシュー
２３１ カード読み取り部
２４０ａ ベットチップ読み取り部
２４０ｂ ペイアウトチップ読み取り部
３１０ 識別情報受信部
３２０ チップ情報受信部
３３０ クレジット送信部
３４０ 進行情報取得部
３５０ 記憶部
３６０ 更新部
３７０ 制御部
３８０ クレジット更新要求受信部

Claims (11)

1. ユーザのクレジットを管理するサーバと、
   ユーザの識別情報を読み取り前記サーバに送信する識別情報読み取り部と、
   所定の区画内に存在するチップのチップ情報を読み取り前記サーバに送信するチップ読み取り部と、
   を備え、
   前記サーバは、
   ユーザのクレジットを固有の識別情報と対応付けて記憶する記憶部と、
   前記チップ情報が示す額と、前記識別情報に対応付けて記憶されているクレジットに対して加算または減算されるべき額と、が一致しない場合、エラーを出力する制御を行う制御部と、
   を有する、管理システム。
2. 前記サーバは、
   実施されるゲームの結果を含む進行情報を取得する取得部と、
   前記チップ情報と取得した前記進行情報とに基づいて、前記クレジットに対して加算または減算されるべき額を算出する算出部と
   をさらに有する、請求項１に記載の管理システム。
3. 前記チップ読み取り部は、
   前記所定の区画の第一の領域に存在するチップのチップ情報を前記サーバに送信する第一のチップ読み取り部と、
   前記所定の区画の前記第一の領域とは異なる第二の領域に存在するチップのチップ情報を前記サーバに送信する第二のチップ読み取り部とを少なくとも含み、
   前記算出部は、
   前記第一のチップ読み取り部から送信されたチップ情報が示す額をベットした額として用いて、前記ゲームの結果に応じて前記加算または減算されるべき額を算出し、
   前記制御部は、
   前記第二のチップ読み取り部から送信されたチップ情報が示す額と、算出された額とが一致しない場合、前記制御を行う、
   請求項２に記載の管理システム。
4. 取得した前記進行情報がベット期間中であることを示す場合、
   前記算出部は、前記チップ情報が示す額をベットした額として用いて、前記ゲームの結果に応じて前記加算または減算されるべき額を算出する、請求項２に記載の管理システム。
5. 前記取得部で取得した進行情報がペイアウトの期間中であることを示す場合、
   前記制御部は、
   前記チップ情報が示す額と、更新された額と一致しない場合、前記制御を行う、請求項４に記載の管理システム。
6. 前記進行情報がユーザの退席を示す場合において、前記制御部は、前記加算または減算されるべき額を前記クレジットに反映した額が、前記チップ情報が示す額と一致しない場合、前記制御を行う、請求項２に記載の管理システム。
7. 算出された前記額を前記クレジットに対して反映することで前記クレジットを更新する更新部をさらに有する、請求項２から６のいずれか一項に記載の管理システム。
8. 前記ゲームで用いられるトランプカードのカード情報を読み取り前記サーバに送信するカード情報読み取り部をさらに有し、
   前記サーバは、前記送信されたカード情報に基づいて前記進行情報を決定する、請求項２から７のいずれか一項に記載の管理システム。
9. 前記クレジットを表示する表示部をさらに有する、請求項１から８のいずれか一項に記載の管理システム。
10. ユーザのクレジットを管理するサーバと通信するように構成されたゲーム用テーブルであって、
    ユーザの識別情報を読み取り前記サーバに送信する識別情報読み取り部と、
    所定の区画内に存在するチップのチップ情報を読み取り前記サーバに送信するチップ読み取り部と
    前記チップ情報が示す額と、前記識別情報読み取り部から送信された識別情報に対応付けて前記サーバで記憶されているクレジットに対して加算または減算されるべき額と、が一致しない場合、エラーを出力する出力部と
    を有する、ゲーム用テーブル。
11. ユーザのクレジットを管理するサーバと、
    ユーザの識別情報を読み取り前記サーバに送信する識別情報読み取り部と、
    所定の区画内に存在するチップのチップ情報を読み取り前記サーバに送信するチップ読み取り部と、
    を備え、
    前記サーバは、
    ユーザのクレジットを固有の識別情報と対応付けて記憶する記憶部と、
    実施されるゲームの結果を含む進行情報を取得する取得部と、
    前記チップ情報と取得した前記進行情報とに基づいて前記識別情報に対応付けて記憶されているクレジットを更新する更新部と、
    前記進行情報が前記ユーザの退席を示す場合において、前記チップ情報が示す額と、更新された前記クレジットと、が一致しない場合、エラーを出力する制御を行う制御部と、
    を有する、管理システム。

Images