JP6080145B1 - 遊技用テーブル及び管理システム - Google Patents

Abstract

遊技用テーブルは、ユーザの識別情報を読み取り、ユーザのクレジット額を管理するサーバに識別情報を送信する識別情報読み取り部と、所定の区画に存在するチップのチップ情報をベット額として読み取り、ベット額をサーバに送信するチップ読み取り部と、ベット額がサーバで管理されているクレジット額よりも多い場合、エラーを出力する制御部とを有する。かかる構成により、ユーザがチップを置くことでベットをした額がクレジット額より多い場合、エラーを出力することができる。

Description

本発明は、カジノその他の遊技場において用いられる遊技用テーブル及び管理システムに関する技術である。より詳細には、ゲームに参加する参加者（以下、ユーザという）がチップをベットする際に用いられる遊技用テーブル及び管理システムに関する技術である。

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

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

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

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

本発明の一実施形態に係る遊技用テーブルは、ユーザの識別情報を読み取り、ユーザのクレジット額を管理するサーバに前記識別情報を送信する識別情報読み取り部と、所定の区画に存在するチップのチップ情報をベット額として読み取り、前記ベット額を前記サーバに送信するチップ読み取り部と、ベット額が前記サーバで管理されている前記クレジット額よりも多い場合、エラーを出力する制御部とを有する。

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

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

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

＜用語の説明＞
本明細書では、以下のように用語を定義する。
「遊技用テーブル」：遊技場において各種のゲームが行われるテーブルのことをいう。一般に、一つのテーブルにつき、一人のディーラーが配置される。また、一つのテーブルにつき、複数人のユーザが同時にゲームに参加することができる。
「ディーラー」：ゲームで用いるカードを配るなど、ゲームの進行を仕切る遊技場側の人間のことをいう。
「ユーザ」：遊技場に来店してゲームに参加するゲストの人間のことをいう。
「バカラ」：伝統的なカードゲームであり、BANKER（胴元役）とPLAYER（客役）によるカードゲームの勝敗を、ユーザが予想して賭けるゲームをいう。ユーザは単にゲームの勝敗を予想するのみであり、その手軽さなどから世界各地のカジノで人気を博している。ディーラーは、あるルールに則してバンカー及びプレイヤのそれぞれに２枚ないし３枚のトランプカードを配り、配られた合計数の１桁目が「９」に近い方が勝ちとなる。
「ブラックジャック」：カードの合計点数が２１点を超えないように、ユーザがディーラーより高い点数を得ることを目指すゲームである。
「ルーレット」：回転する円盤に球を投げ入れ、球が落ちる場所を予想するゲームである。賭ける対象の項目は、赤か黒か、奇数か偶数かなどように複数の数を包含するように賭けるものから特定の数に賭けるものまで様々な種類が存在する。
「チップ」：ゲームに参加する際に用いられる、札やコイン型をした通貨の代用物である。ただし、実施形態においては通貨などと交換可能な経済的価値を持たないものである。
「ベット」：ユーザの予想を表明して賭けることをいう。例えばバカラにおいては、バンカーが勝つのか（ＢＡＮＫＥＲ）、プレイヤが勝つのか（ＰＬＡＹＥＲ）、または勝負が引き分けに終わるのか（タイ（ＴＩＥ））を予想して、この勝敗予想に対応して賭けることをいう。また、例えばブラックジャックにおいては、ユーザは自身の勝つ可能性などを予想し、その勝敗予想に対応して賭けることをいう。ルーレットにおいては、ユーザが回転盤の中で球が落ちる箇所を予想し、予想先に賭けることをいう。
「ベット額」：ベットの際に用いる額のことである。各ユーザは、所望の種類や枚数のチップをテーブルに置くことでベット額を任意に指定することができる。ユーザの予想が当たった場合には、ベット額に応じた配当が得られる。
「ベット領域」：ユーザがチップを置くことでベット額を表明する領域である。つまり、ユーザがチップを賭ける領域である。例えばバカラにおいては、バンカーが勝つのか（BANKER)、プレイヤが勝つのか（PLAYER）、または勝負が引き分けに終わるのか（タイ（TIE））に応じたベットをする領域がテーブル上に明示されている。ルーレットにおいては、回転盤に存在する数や、複数の数を包含する項目（例えば赤枠の数を包含する「ＲＥＤ」）などがテーブル上に明示されている。
「クレジット」：ユーザが保有している残高のことである。配当が得られた場合にはクレジットの額が増え、予想が外れた場合には、クレジットの額が減る。

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

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

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

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

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

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

既に述べたように、現在のカジノその他の遊技場において、チップはゲームに参加するための道具であり、かつ、チップ自体に代用通貨としての価値が存在する。これに対して、以下で説明する実施形態においては、チップはゲームに参加するための道具である点に変わりないが、チップ自体には何ら代用通貨としての価値を持たせないようにする。具体的には、ユーザのクレジットをチップとは別個に電子的に管理する。チップはベットに用いられるが、支払い（ペイアウト）には用いられない。つまり、ユーザの予想が的中した場合に、ディーラーから的中相当分のチップがユーザに支払われることはない。したがって、ディーラーからユーザに、不適切な額のチップが渡されることを防止できる。その一方で、チップを用いてベットをするという行為自体は引き続き行われるので、カジノその他の遊技場本来の醍醐味を維持することができる。

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

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

以下、チップをベットする区画がユーザごとに独立して設けられている遊技用テーブルの例としてバカラ用テーブルを実施形態１で説明し、チップをベットする区画が複数のユーザに共通に設けられている遊技用テーブルの例としてルーレット用テーブルを実施形態２で説明する。

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

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

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

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

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

＜遊技用テーブルの説明＞
図２は、遊技用テーブル２０の一例を示す図である。遊技用テーブルは、所定の区画ごとに分かれており（区画１〜６）、ゲームに参加するユーザは、それぞれの区画の席Ｃａ〜Ｃｆに座り、ゲームに参加することになる。図２に示す遊技用テーブルは、ゲームに参加するユーザの区画が６個である例を示している。もちろん、この例に限られるものではなく、またテーブルごとに異なる区画であってもよい。また、図２はバカラで用いられる遊技用テーブル２０の例を挙げて説明しているが、テーブルのデザイン、表記されている内容などは一例に過ぎず、様々な態様のテーブルを用いることができる。以下、遊技用テーブル２０に備えられる各構成について説明をする。

＜識別情報読み取り部の説明＞
遊技用テーブル２０の各区画には、ユーザの識別情報を読み取る識別情報読み取り部２１０ａ〜２１０ｆが備えられている。以下、識別情報読み取り部２１０ａ〜２１０ｆを総称して識別情報読み取り部２１０と呼ぶことがある。つまり、参照符号の末尾のアルファベットを省略する場合がある。他の構成についても同様である。本実施形態においては、ユーザは識別カードを保有している。識別カードとしては、例えば磁気カード、ＩＣチップが埋め込まれたカード、ＲＦＩＤが埋め込まれたカードなど、様々な種別のカードを用いることができる。識別情報読み取り部２１０ａ〜２１０ｆは、カードの種別に応じた読み取り部として構成することができる。なお、識別情報は、カードのような記録媒体から得られるデータである必要はなく、例えば顔認証のような画像データを用いても、指紋認証などに代表されるような生体認証時に得られたデータを用いることもできる。また、ユーザの所有するまたは体に埋め込まれた発信器から短距離無線によって送信されるデータを用いることもできる。あるいは、これらを組み合わせてより強固な個人の識別情報を用いる形態を採用してもよい。

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

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

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

また、表示部２２０は、ユーザが後述するチップ読み取り部２４０にチップを置くことでベットをした場合、ベット額を表示するように構成してもよい。表示部２２０が表示するベット額は、サーバ１０から送信されたデータに基づいてもよいし、チップ読み取り部２４０から読み取られたデータであってもよい。

なお、本実施形態においては、各区画に表示部が設けられている構成を例に挙げて説明するが、これに限られるものではない。例えば、遊技用テーブル２０において１つの表示部が備えられており、ゲームに参加しているユーザのクレジットの額やベット額の一覧がその表示部に表示されてもよい。また、このような各ユーザのクレジット額が表示される表示部は、各ユーザ側に見えるようにテーブル上に配置されてもよいし、テーブルの頭上の空間などに配置されてもよい。あるいは、各ユーザのクレジット額が表示される表示部は、ディーラー側の手元部分に配置される形態でもよい。

また、表示部２２０は、例えばタッチパネルディスプレイで構成されており、ユーザからの入力を受け付け可能に構成されていてもよい。表示部２２０は、ベット額を表示する場合、ユーザにベット額が正しいかを入力させるインターフェースをさらに表示してもよい。例えば、表示部２２０は、ＯＫボタンを表示する。ユーザは、表示部２２０に表示されたベット額を確認し、ベットした額は、自身がベットすることを意図した額と同じであるかを判断する。ベットした額が意図した額と同じであるとユーザが判断すると、ユーザはＯＫボタンをタッチする。ＯＫボタンがタッチされると、ベット額を承認する旨の指示が、後述する通知部２６０に通知される。なお、ベット額を承認する旨の指示がサーバ１０に送信されてもよい。かかる構成により、ユーザが誤った額をベットした場合に、そのままゲームが進行されてしまうことを防止することができる。

なお、ゲームの進行の速度を優先的に扱う遊技場では、ベット額を承認する旨の指示が入力されるインターフェースを表示部２２０に表示しなくてもよい。また、ベット額を承認する旨の指示が入力されるインターフェースを表示するモードであるか、表示しないモードであるかを切り替える切り替え部（不図示）が遊技用テーブル２０に設けられてもよい。なお、上記例においては、表示部２２０にベット額を承認する旨の指示が入力されるインタフェース（ＯＫボタン）が表示される例を説明したが、これに限られない。表示部２２０とは別個に設けられた物理的な入力ボタン（不図示）が各区画に設けられてもよい。

表示部２２０は、ユーザがベットした額が、サーバ１０において管理されているクレジット額よりも大きい場合、サーバ１０からエラー（当該ベットが不可能であることを意味する情報）を受信してもよい。そして、表示部２２０は、受信したエラーを表示（当該ベットが不可能であることをユーザに告知するための文字や画像表示。音響や振動等を含む。）してもよい。表示するエラーは、サーバ１０から受信したエラーのデータそのものを表示してもよいし、サーバ１０からはエラー種別のみが受信され、表示部２２０はエラー種別に応じたエラーメッセージを表示してもよい。つまり、表示部２２０は、サーバ１０からエラーを受信した場合、エラーに応じた出力制御を行ってもよい。ここでは表示部２２０がエラーに応じた出力制御を行うものとして説明したが、遊技用テーブル２０に設けられている不図示のコンピュータ（第一の制御部）が、サーバ１０から受信したエラーに応じた出力制御を行ってもよい。ユーザがベットした額が、サーバ１０において管理されているクレジット額よりも大きい場合、そのユーザが本来ベットできる額を超えた額をベットしていることになるので、エラーを表示する。

＜チップ読み取り部の説明＞
次に、各区画に設けられるチップ読み取り部２４０ａ〜２４０ｆについて説明する。チップ読み取り部２４０ａ〜２４０ｆは、例えばチップに含まれているＲＦＩＤからそのチップの情報を読み取り、読み取ったチップの情報をサーバ１０に送信する。サーバ１０は、どの遊技用テーブルのどの区画に存在するチップの情報であるかを、前述の識別情報で説明した形態と同様の形態で特定できるように構成されている。

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

チップ読み取り部２４０は、読み取ったチップの情報を、サーバに加えて表示部２２０にも送信する構成としてもよい。

図２では、説明の便宜上、区画２を例に挙げてチップ読み取り部についての説明することとするが、他の区画についても同様である。チップ読み取り部２４０ｂは、チップに埋め込まれているＲＦＩＤを読み取るアンテナを含む。なお、本実施形態においてはチップにＲＦＩＤが埋め込まれている場合を例に挙げて説明するが、これに限られるものではなく、所定の区画に存在するチップの情報がサーバ側で把握することができるような構成であれば、いずれの構成を採用してもよい。

なお、図２に示すチップ読み取り部２４０は、あくまで図２のような表記がなされている遊技用テーブルにおけるチップ読み取り部２４０の一例に過ぎない。図２の遊技用テーブルはバカラを想定したテーブルであるが、バカラ一つを例に挙げてもその遊技用テーブルには様々な種類のテーブルがあり、また、テーブル上の表記についても多様のものである。よって、チップ読み取り部は、使用される遊技用テーブルに応じた位置に設けることができる。

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

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

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

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

＜チップ収納部の説明＞
チップ収納部２５０ａ〜２５０ｆは、ベットに用いられるチップを収納する。チップ収納部２５０ａ〜２５０ｆは、便宜上、それぞれの区画に設けられた例を示しているが、これに限られない。また、テーブル全体で共用のチップ収納部が設けられてもよい。チップ自体はベットで用いられる道具に過ぎず、チップ自体には何ら代替通貨の役割はないからである。

チップ読み取り部２４０が読み取り可能な領域に置かれたチップ、すなわち、ベットに用いられたチップは、ベット額が確定した後、あるいは、ゲームが終了した後に、それぞれのユーザに対してディーラーから戻される。ディーラーから戻されるのではなく、ユーザ自身が取り戻してもよい。戻されたチップは、ユーザが例えば再度チップ収納部に収納する。あるいは、ベットで用いられたチップは全てディーラーで回収されてもよい。チップ収納部のチップが少なくなった場合には、ディーラーまたは遊技場の係員から適宜補充用のチップがユーザに渡されてもよい。

＜通知部の説明＞
通知部２６０は、ディーラー側に設けられた表示部の一種である。通知部２６０は、ユーザがベットをし、ベットした額を承認する旨の指示が入力されたことを表示することができる。また、通知部２６０は、ユーザによってベットされた額が、サーバ１０において管理されているそのユーザのクレジット額よりも大きい場合、サーバ１０からエラーが通知されてよい。通知部２６０は、そのエラーを表示してもよい。なお、通知部２６０は、表示をすることで通知をする形態を説明したが、音声を出力することで通知をする形態でもよい。

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

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

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

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

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

識別情報受信部３１０は、各遊技用テーブルの識別情報読み取り部２１０から送信された識別情報を受信する。制御部３７０は、識別情報受信部３１０において受信した識別情報をキーとして記憶部３５０に記憶されているクレジット管理ＤＢを検索する。そして、制御部３７０は、その識別情報に対応付けて記憶部３５０に記憶されているクレジット額を、送信部３３０を用いて識別情報の送信元の遊技用テーブルに送信することができる。なお、ここでは識別情報を受信した場合、クレジット額を送信元の遊技用テーブルに送信する例を説明したが、クレジット額を送信しない形態でもよい。

送信部３３０は、送信元の遊技用テーブルや、他の装置に各種の情報を送信する。例えば、送信部３３０は、送信元の遊技用テーブルにクレジット額を送信してもよいし、ベット額を送信してもよい。また、送信部３３０は、ベット額がクレジット額よりも大きい場合、送信元の遊技用テーブルや他の装置に、エラーを送信してもよい。

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

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

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

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

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

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

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

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

ステップＳ６２１において、クレジット額を受信した表示部は、そのクレジットを表示する。単にクレジットを表示するだけではなく、登録されているユーザ名を併せて表示してもよい。

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

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

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

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

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

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

ステップＳ７１２においてサーバ１０の制御部３７０は、ベットチップのエラー判定処理を行う。エラー判定処理を説明する。制御部３７０は、進行管理ＤＢを参照して、ステップＳ７１１で特定した区画に関連付けられているユーザの識別情報を特定する。そして、制御部３７０は、クレジット管理ＤＢを参照して、当該識別情報に関連付けられているクレジット額を参照する。制御部３７０は、このようにして参照したクレジット額とベット額とを比較する。比較した結果、ベット額がクレジット額より大きい場合、制御部３７０は、エラーであると判定する。つまり、そのユーザは、ユーザ自身が保有するクレジット額よりも多くの額をベットしていることになるので、そのようなベットは受け付けられないと制御部３７０は判定する。

ステップＳ７１３において制御部３７０は、送信部３３０を用いて判定結果に応じた情報を遊技用テーブル２０に送信する。制御部３７０は、ステップＳ７１１で特定した区画に対応する表示部２２０に判定結果に応じた情報を送信してよい。判定結果がエラーであった場合には、制御部３７０は、送信部３３０を用いてエラーを送信してよい。判定結果がエラーでない場合には、制御部３７０は、チップ情報が示す額をベット額であると判定する。制御部３７０は、ベット額を、送信部３３０を用いて表示部２２０に送信してよい。

ステップＳ７２１において表示部２２０は、サーバ１０から送信された情報に基づく表示を行う。例えば、エラーが送信された場合には、表示部２２０はエラーを表示する。エラーとしては、例えばベットした額がクレジット額をオーバーしている、といったメッセージを表示してよい。

なお、ステップＳ７１２のエラー判定処理の結果、エラーであると判定した場合、制御部（第二の制御部）３７０は、遊技用テーブル２０の表示部２２０にエラーを出力する以外の処理を行ってもよい。例えば、遊技用テーブル２０の各区画において警告灯が備えられており、その警告灯を点灯、点滅させるような信号を制御部３７０が出力するように制御する態様でもよい。あるいは、遊技用テーブルに備えられたスピーカーなどから音声による警告が出力されるように制御部３７０が制御信号を出力するように制御する形態でもよい。また、ディーラーの通知部２６０にエラーを通知してもよいし、遊技場運営者の携帯端末などにエラーが生じたことを通知する形態でもよい。

ステップＳ７１４においてサーバ１０の制御部３７０は、進行管理ＤＢの更新処理を行う。なお、ステップＳ７１２のエラー判定処理の結果がエラーである場合、不適切なベットがされていることになるので、制御部３７０は、進行管理ＤＢの更新は行わない。進行管理ＤＢの更新処理の詳細は後述する。

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

なお、クレジットＤＢの更新の方法としては、（１）ゲームの結果が判明した時点でクレジット額の加算または減算を行う方法と、（２）ベットしたチップの額をゲームの結果が判明する前に減額する方法、つまり、ベットがされた時点でクレジット額を一旦減額する方法とが考えられるが、いずれの手法を採用してもよい。例えば、２０ドル分のチップをベットし、予想が的中して４０ドル分の払い戻しがある場合を想定する。つまり、ベット前と比べてクレジットが２０ドル分増える場合を想定する。（１）の方法を採用する場合、図７のステップＳ７１４の処理によって、２０ドル分のチップがクレジットに対して加算されるべき額であると算出されていることになる。（２）の方法を採用する場合、４０ドル分のチップがクレジットに対して加算されるべき額であると算出されていることになる。いずれの態様を採用してもよいが、本実施形態では、上記（１）のように、ゲームの結果が判明した時点でクレジットの加算または減算を行う方法を例に挙げて説明するものとする。

以上説明した図７においては、遊技用テーブル２０の表示部２２０に表示されるベット額の情報は、サーバ１０から送信される形態を説明した。図８は、別の形態を示す図である。

図８に示す処理は、遊技用テーブル２０の表示部２２０で表示されるベット額は、サーバ１０から送信された情報に基づくのではなく、チップ読み取り部２４０で読み取られた情報に基づく。すなわち、ステップＳ８０２でチップ読み取り部２４０は、読み取ったチップ情報を、表示部２２０とサーバ１０との両方に送信する。ステップＳ８２１で表示部２２０は、送信されたチップ情報に基づいてベット額を表示する。

サーバ１０において行われるステップＳ８１１及びＳ８１２の処理は、ステップ７１１及びＳ７１２と同じである。図８の処理においては、ステップＳ８１３において、サーバの制御部３７０は、ステップＳ８１２のベットチップのエラー判定処理の結果がエラーであるかを判定し、エラーである場合、ステップＳ８１４において制御部３７０は、エラーを遊技用テーブル２０に送信する。エラーの送信先は、図７と同様に、遊技用テーブルの表示部２５０でもよいし、通知部２６０でもよいし、他の装置等であってもよい。エラーが通知されると、ステップＳ８２２で表示部２２０はエラーを表示する。

サーバの制御部３７０は、ベットチップのエラー判定処理の結果がエラーでない場合、ステップＳ８１４のエラーの送信処理を行わずに、ステップＳ８１５に進む。ステップＳ８１５、Ｓ８１６、及びＳ８２３の処理は、図７のＳ７１４、Ｓ７１５、及びＳ７２２の処理と同じである。

このように、表示部２２０で表示されるベット額は、チップ読み取り部２４０が読み取った情報に基づくものであってもよいし、サーバ１０から送信される情報に基づくものであってもよい。

以上のような処理を行うことで、ゲームの結果に応じて適宜クレジットの更新処理が行われることになる。このように、本実施形態では、チップはベットに用いられるものの、ユーザの予想が的中した場合には、サーバ１０で管理されているクレジットが更新されることになる。つまり、ディーラーＤからは、ペイアウトとしてのチップがユーザに渡されることはない。

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

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

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

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

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

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

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

なお、先に説明したように、本実施形態においてチップはベットのために用いられるものであり、ペイアウトには用いられない。したがって、ゲームの勝敗に応じた額相当分のチップがディーラーから支払われることはない。なお、ユーザが使用するチップの在庫が少なくなった場合にディーラーからチップが補充される場合はある。このように補充としてディーラーからチップを渡されることがあったとしても、もはやチップ自体には代用通貨の役割がないので、過剰なチップがディーラーからユーザに渡されたとしても支障がない。

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

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

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

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

＜実施形態２＞
実施形態１においては、カードゲームに用いられる遊技用テーブルを例に挙げて説明した。実施形態２においては、ルーレットのような、ベットをする箇所がゲームに参加するユーザで共通の領域となるような遊技用テーブルを例に挙げて説明する。なお、実施形態１と同様に、チップはベットに用いられるものの、チップ自体からは金銭的な価値は排除されている。

図１０は、実施形態２に係る遊技用テーブル１０００の一例を示す図である。図１０には、ルーレットにおけるベット先のレイアウトが表記されており、ベット先のレイアウトに存在するチップを読み取るチップ読み取り部１０１０が設けられている。遊技用テーブル１０００は、ルーレットで用いられる回転盤１０４０も有する。

遊技用テーブル１０００には、ユーザの識別情報を読み取る識別情報読み取り部１０２０ａ〜１０２０ｃが設けられている。本実施形態における識別情報読み取り部１０２０は、実施形態１で説明した構成に加えて、チップを識別するチップ識別子をユーザの識別情報と共にサーバ１０に送信する構成とすることができる。遊技用テーブル１０００においては、ベットをする箇所がゲームに参加するユーザで共通の領域となる。したがって、チップをユーザ毎に識別できることが好ましい。つまり、誰が置いたチップであるのかを識別できることが好ましい。実施形態１では、ベットをする区画がゲームに参加するユーザに固有の区画となっていたので、チップが置かれた位置に基づいてそのチップを置いたユーザ、つまりベットをしたユーザを特定することが可能な構成である。本実施形態では、ベットをする区画が共通となるので、チップ自体にユーザを識別するための情報を含める。例えば、チップを識別するチップ識別子をチップ情報としてチップ自体に含める。その上で、ゲームに参加するユーザが識別情報読み取り部１０２０で識別情報を読み取る際に、そのユーザがどのチップを用いるかを示す情報（本例では、チップ識別子）を、そのユーザの識別情報とともにサーバ１０に送信する。これにより、サーバ１０では、チップ識別子と対応付けて、ゲームに参加するユーザを特定することができる。

図１０の例では、遊技用テーブル１０００に３人のユーザがゲームに参加する例を示している。各ユーザが用いるチップ群１０３０ａ〜１０３０ｃは、例えば色で外観が識別可能なチップとなっている。チップ群１０３０ａは赤、チップ群１０３０ｂは青、チップ群１０３０ｃは黄色といった具合である。色ではなく、模様でもよいし、色と模様とを組み合わせてもよい。形状が異なっていてもよい。そして、各チップ群に含まれるチップには共通のチップ識別子がチップ情報に含まれる。例えば、チップ群１０３０ａに含まれる全てのチップには、チップ識別子Ｃ１が含まれる。チップ情報には、チップ識別子のほかに、実施形態１で説明したようなチップの額を示す情報が含まれてよい。このように同じチップ識別子が含まれるチップの外観をユーザが識別可能に構成しておくことで、ゲームに参加するユーザは、自身のチップを容易に視認することができる。

識別情報読み取り部１０２０ａ〜１０２０ｃは、例えばチップ群を収納するチップケース１０６０ａ〜１０６０ｃと一体となって設けられていてよい。かかる構成によれば、ペアとなっている識別情報読み取り部とチップ群とをユーザが容易に理解できる。つまり、識別情報読み取り部で識別カードを読み取らせたユーザは、どのチップ群が自分の使用するチップ群であるかを直ちに認識することができる。識別情報読み取り部１０２０が識別情報を読み取ると、対応するチップ識別子と読み取った識別情報とをサーバ１０に送信する。

図１１は、サーバ１０で管理する進行管理ＤＢの一例を示す図である。サーバ１０は、識別情報読み取り部１０２０から識別情報とチップ識別子とを受信すると、受信した識別情報を、受信したチップ識別子に対応する項目に追加する。かかる処理により、チップ識別子と識別情報との関連付けをサーバ１０で行うことが可能となる。

ユーザが、それぞれベットを開始すると、チップ読み取り部１０１０はチップ情報を読み取りサーバ１０に送信する。実施形態１で説明したように、チップ読み取り部１０１０は、チップを読み取り可能な領域を細分化し、どの領域に置かれたチップであるかがサーバ１０側で特定できるとよい。チップ情報には、先に説明したようにチップ識別子が含まれる。

なお、ルーレットの場合には、バカラと比べてユーザがベットする区画が小さい。また、特定の数にベットするのではなく、複数のベット単位の境界部分（例えば「８」と「１１」の境界部分、「８」、「１１」、「９」、及び「１２」の交差部分）にベットがされる場合もある。さらには、複数の数を包含した項目（例えば「１ｓｔ１２」、「ＲＥＤ」）にベットがされる場合もある。したがって、遊技用テーブル１０００は、例えばテーブルを俯瞰した画像を撮影する撮像装置をさらに備えてもよく、撮像した画像をサーバ１０に送信する画像送信部をさらに有してもよい。サーバ１０は、送信された画像を用いてベットがされた領域を補正し、進行情報を更新してもよい。図１１の進行管理ＤＢでは、このようにして、ベット先やベット額などが更新される。

また、回転盤１０４０にセンサを設けたり、回転盤１０４０を撮影したりすることで、球が入った箇所が特定されてよく、特定された箇所が不図示のコンピュータなどを用いてサーバ１０に送信されてもよい。サーバ１０は、特定された箇所に基づいて図１１の進行管理ＤＢを更新することができる。

実施形態２においても実施形態１と同様に、ベットした額がクレジットの額より大きい場合には、表示部１０５０にエラーを表示してもよい。本実施形態では、テーブルに共通の表示部１０５０を設ける例を説明したが、実施形態１と同様に、ユーザ毎に表示部を設けてもよい。また、実施形態１と同様に、遊技用テーブルにおいてエラー出力する制御部を有してもよいし、サーバ側でエラーを出力する制御部を有してもよい。実施形態２では、一般的にユーザは１回のゲームにおいて、複数の箇所にベットをすることが多い。ユーザが複数の箇所にベットをする場合には、そのユーザがベットした総額（複数の箇所におけるベット額の合計）と、そのユーザのクレジットとを比較してもよい。あるいは、例えばユーザが５か所にベットをし、２か所のベット額を合計した時点で既にクレジットを超える場合には、残りの３か所のベット額は合計に含めずにエラーを出力してもよい。つまり、ベット額を累積する過程においてエラーであると判定できた時点でエラーを出力してもよい。

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

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

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

また、ユーザがＢＥＴした額がその遊技用テーブルで定められているリミット額を超えた場合にもエラーを出力しても良い。

また、上記説明した実施形態においては、ゲームの進行情報をサーバ１０が取得し、サーバ１０がユーザのクレジットを更新する形態を説明した。また、ユーザのベット額がサーバ１０で管理されているクレジットを超えている場合にエラーが出力される形態を説明した。しかしながら、かかる形態に限定されるものではない。遊技用テーブルの不図示のコンピュータがサーバ１０と同様の機能を実施してもよい。例えば、遊技用テーブルの不図示のコンピュータは、サーバ１０で管理しているユーザのクレジットを参照可能に構成してよい。ユーザのベット額がサーバ１０で管理しているクレジットを超える場合、遊技用テーブルの不図示のコンピュータは、上記説明した実施形態と同様にエラーを出力する制御をしてよい。また、遊技用テーブルの不図示のコンピュータは、進行情報を取得し、進行情報に基づくクレジットの増減をサーバ１０に通知してもよく、サーバ１０はこの通知に応じてクレジットを更新してよい。

あるいは、遊技用テーブルの不図示のコンピュータは、ユーザのクレジットを一時的にサーバ１０から取得し、ゲームが行われる期間中、ユーザのクレジットを一時的に管理してもよい。遊技用テーブルの不図示のコンピュータは、ユーザのベット額が、一時的に管理しているユーザのクレジットを超える場合、上記説明した実施形態と同様にエラーを出力する制御をしてよい。また、遊技用テーブルの不図示のコンピュータは、進行情報を取得し、一時的に管理しているユーザのクレジットを更新してよい。遊技用テーブルの不図示のコンピュータは、所定のタイミング、例えばゲームが終了したタイミングで、一時的に管理しているクレジットをサーバ１０に送信し、サーバ１０は、送信されたデータに従ってサーバ１０で管理しているクレジットを更新してよい。

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

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

１０ サーバ
２０ 遊技用テーブル
３１ キャッシャー装置
２１０ａ〜２１０ｆ 識別情報読み取り部
２２０ａ〜２１０ｆ 表示部
２３０ カードシュー
２３１ カード読み取り部
２４０ａ〜２４０ｆ チップ読み取り部
２５０ａ〜２５０ｆ チップ収納部
２６０ 通知部
３１０ 識別情報受信部
３２０ チップ情報受信部
３３０ 送信部
３４０ 進行情報取得部
３５０ 記憶部
３６０ 更新部
３７０ 制御部
３８０ クレジット更新要求受信部
９００ 遊技用テーブル
９１０ チップ読み取り部
９２０ａ〜９２０ｃ 識別情報読み取り部
９３０ａ〜９３０ｃ チップ群
９４０ 回転盤
９５０ 表示部
９６０ａ〜９６０ｃ チップ収納部

Claims (7)

1. ユーザの識別情報を読み取り、ユーザのクレジット額を管理するサーバに前記識別情報を送信する識別情報読み取り部と、
   所定の区画に存在するチップのチップ情報をベット額として読み取り、前記ベット額を前記サーバに送信するチップ読み取り部と、
   ベット額が前記サーバで管理されている前記クレジット額よりも多い場合、エラーを出力する制御部と
   を有する、遊技用テーブル。
2. 前記チップ読み取り部が前記ベット額を前記サーバに送信したことに応じて前記サーバから受信した額をベット額として表示する表示部をさらに有する、請求項１に記載の遊技用テーブル。
3. 前記チップ読み取り部が読み取った前記ベット額を表示する表示部をさらに有する、請求項１に記載の遊技用テーブル。
4. 前記表示部で表示された前記ベット額を承認する旨の指示を入力する入力部をさらに有する、請求項２または３に記載の遊技用テーブル。
5. ユーザの識別情報を読み取り、ユーザのクレジット額を管理するサーバに前記識別情報を送信する識別情報読み取り部と、
   所定の区画に存在するチップのチップ情報をベット額として読み取り、前記ベット額を前記サーバに送信するチップ読み取り部と
   を有する、遊技用テーブルと、
   ユーザのクレジットを固有の識別情報と対応付けて記憶する記憶部と、
   前記ベット額が前記クレジット額よりも多い場合、エラーを出力する制御を行う制御部と
   を有する前記サーバと
   を備える、管理システム。
6. 所定の区画に存在するチップを読み取り、前記読み取ったチップからチップを識別する識別子を含むチップ情報を読み取り、前記チップ情報をユーザのクレジット額を管理するサーバに送信するチップ読み取り部と、
   ユーザの識別情報を読み取り、前記識別子と対応付けて前記サーバに前記識別情報を送信する識別情報読み取り部と、
   同じ識別子を含むチップ情報が示すベット額が当該識別子と対応付けられた前記識別情報によって特定されるユーザのクレジット額を超える場合、エラーを出力する制御部と
   有する遊技用テーブル。
7. 同じ識別子をチップ情報として含むチップは、少なくとも一部の外観が共通である、請求項６に記載の遊技用テーブル。

Images