JP2015077290A - 遊技用システム - Google Patents
遊技用システム Download PDFInfo
- Publication number
- JP2015077290A JP2015077290A JP2013216588A JP2013216588A JP2015077290A JP 2015077290 A JP2015077290 A JP 2015077290A JP 2013216588 A JP2013216588 A JP 2013216588A JP 2013216588 A JP2013216588 A JP 2013216588A JP 2015077290 A JP2015077290 A JP 2015077290A
- Authority
- JP
- Japan
- Prior art keywords
- game
- card
- information
- balls
- ball
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Pinball Game Machines (AREA)
Abstract
【課題】特定処理を行なう相手を慎重に選択できるようにすることが可能な遊技用システムを提供する。
【解決手段】遊技用システムは、遊技場において遊技機に１対１に対応して設けられ会員のカード（記録媒体）を受付けるカードユニットと、遊技場の外に設置されカードの記録情報に対応付けて各会員の会員情報を管理する管理サーバとを含む。管理サーバは、一の会員が他の会員の中から選択した会員を、一の会員の「フレンド」として登録する。さらに、管理サーバは、一の会員が自らの「フレンド」の中から選択した会員を、一の会員の「仲良しフレンド」として登録する（図９７）。遊技用システムは、一の会員と「仲良しフレンド」との間でチャット、持玉共有、スタンプ送受信などの特定処理を実行する。
【選択図】図９７
【解決手段】遊技用システムは、遊技場において遊技機に１対１に対応して設けられ会員のカード（記録媒体）を受付けるカードユニットと、遊技場の外に設置されカードの記録情報に対応付けて各会員の会員情報を管理する管理サーバとを含む。管理サーバは、一の会員が他の会員の中から選択した会員を、一の会員の「フレンド」として登録する。さらに、管理サーバは、一の会員が自らの「フレンド」の中から選択した会員を、一の会員の「仲良しフレンド」として登録する（図９７）。遊技用システムは、一の会員と「仲良しフレンド」との間でチャット、持玉共有、スタンプ送受信などの特定処理を実行する。
【選択図】図９７
Description
本発明は、遊技用システムに関する。詳しくは、遊技場において遊技機に１対１に対応して設けられ受付けた記録媒体により特定される遊技者所有の遊技価値を用いて遊技機での遊技を可能にする遊技用装置と、前記遊技場の外に設置され前記記録媒体の記録情報に対応付けて会員登録された各会員遊技者の会員情報を管理する管理装置とを含む遊技用システムに関する。
従来、予め設定された一の遊技機群の遊技者同士で遊技を行なうための遊技媒体のデータを共有したり、メッセージを送受信したりすることができるように構成された遊技用システムがあった（たとえば、特許文献１参照）。
特許文献１のように複数の遊技者間でのデータ共有やメッセージ送受信を行なうことを可能にする場合、データ共有相手やメッセージ送受信相手を安易に選択できるようにすると、意図しない相手との間でデータが共有されたりメッセージが送受信されたりする事態が生じるおそれがある。しかしながら、特許文献１には、そのような問題およびその対策について言及されていない。
この発明はかかる事情に鑑み考え出されたものであり、その目的は、特定処理を行なう相手を慎重に選択できるようにすることが可能な遊技用システムを提供することである。
（１） 遊技場において遊技機（パチンコ機、スロットマシン、封入循環式パチンコ機（Ｐ台２）、メダル不要のスロットマシン（Ｓ台２Ｓ））に１対１に対応して設けられ受付けた記録媒体により特定される遊技者所有の遊技価値を用いて遊技機での遊技を可能にする遊技用装置（ＣＵ３、呼出しランプ装置など）と、前記遊技場の外に設置され前記記録媒体の記録情報に対応付けて会員登録された各会員遊技者の会員情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員、遊技履歴、遊技状況など）を管理する管理装置（たとえば、管理サーバ１４０）とを含む遊技用システムであって、
前記管理装置は、
会員登録された一の会員遊技者が会員登録された他の会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ１次関連会員遊技者として登録する１次登録手段（たとえば、図９１、図９５：一の会員遊技者が他の会員遊技者から選択してフレンド申請を行なった会員遊技者を、一の会員遊技者の「フレンド」として登録する）と、
前記一の会員遊技者が前記１次関連会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ２次関連会員遊技者として登録する２次登録手段（たとえば、図９７：一の会員遊技者が自らの「フレンド」の中から選択した会員遊技者を、一の会員遊技者の「仲良しフレンド」として登録する）とを有し、
前記一の会員遊技者と前記２次関連会員遊技者との間で特定処理を実行する特定処理手段（たとえば、図３８、図３９：仲良しフレンドとのチャットを行なう、図４０〜図４３：仲良しフレンドとの持玉（持点）共有を行なう、仲良しフレンドとのスタンプ送受信を行なうなど）をさらに含む。
前記管理装置は、
会員登録された一の会員遊技者が会員登録された他の会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ１次関連会員遊技者として登録する１次登録手段（たとえば、図９１、図９５：一の会員遊技者が他の会員遊技者から選択してフレンド申請を行なった会員遊技者を、一の会員遊技者の「フレンド」として登録する）と、
前記一の会員遊技者が前記１次関連会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ２次関連会員遊技者として登録する２次登録手段（たとえば、図９７：一の会員遊技者が自らの「フレンド」の中から選択した会員遊技者を、一の会員遊技者の「仲良しフレンド」として登録する）とを有し、
前記一の会員遊技者と前記２次関連会員遊技者との間で特定処理を実行する特定処理手段（たとえば、図３８、図３９：仲良しフレンドとのチャットを行なう、図４０〜図４３：仲良しフレンドとの持玉（持点）共有を行なう、仲良しフレンドとのスタンプ送受信を行なうなど）をさらに含む。
このような構成によれば、一の会員遊技者が特定処理を行なう相手を選択するには、単に１次関連会員遊技者を選択するだけでなく、さらに１次関連会員遊技者の中から２次関連会員遊技者を選択する必要がある。そのため、特定処理を行なう相手を慎重に選択できるようにすることが可能な遊技用システムを提供することができる。
（２） 上記（１）の遊技用システムにおいて、
前記１次登録手段は、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録することを前記他の会員遊技者が承認した場合に、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録する（たとえば、図９５のＳ４６２、Ｓ４６３：他の会員遊技者が一の会員遊技者からのフレンド申請を承認した場合に、他の会員遊技者を一の会員遊技者の「フレンド」として登録する）。
前記１次登録手段は、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録することを前記他の会員遊技者が承認した場合に、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録する（たとえば、図９５のＳ４６２、Ｓ４６３：他の会員遊技者が一の会員遊技者からのフレンド申請を承認した場合に、他の会員遊技者を一の会員遊技者の「フレンド」として登録する）。
このような構成によれば、本人の承諾なしに１次関連会員遊技者として登録されてしまうことを防止することができる。その結果、特定処理を行なう相手をより慎重に選択できるようにすることができる。
（３） 上記（１）または（２）の遊技用システムにおいて、
前記一の会員遊技者が第１操作を行なったことに応じて、前記他の会員遊技者の前記会員情報を表示する手段（たとえば、図１０１：一の会員遊技者が他の会員遊技者を絞り込むための検索条件を入力する操作を行なったことを少なくとも１つの条件として、他の会員遊技の遊技履歴を一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）と、
前記一の会員遊技者が前記第１操作よりも簡易な第２操作を行なったことに応じて、前記１次関連会員遊技者の前記会員情報を表示する手段（たとえば、図１００：一の会員遊技者がフレンドリストから閲覧対象者を選択する操作を行なったことを１つの条件として、フレンドの遊技履歴を一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）とをさらに含む。
前記一の会員遊技者が第１操作を行なったことに応じて、前記他の会員遊技者の前記会員情報を表示する手段（たとえば、図１０１：一の会員遊技者が他の会員遊技者を絞り込むための検索条件を入力する操作を行なったことを少なくとも１つの条件として、他の会員遊技の遊技履歴を一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）と、
前記一の会員遊技者が前記第１操作よりも簡易な第２操作を行なったことに応じて、前記１次関連会員遊技者の前記会員情報を表示する手段（たとえば、図１００：一の会員遊技者がフレンドリストから閲覧対象者を選択する操作を行なったことを１つの条件として、フレンドの遊技履歴を一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）とをさらに含む。
このような構成によれば、他の会員遊技者を予め１次関連会員遊技者として登録しておくことで、簡易な操作で当該１次関連会員遊技者の会員情報を閲覧することができる。その結果、遊技者の利便性を向上させることができる。
（４） 上記（３）の遊技用システムにおいて、
前記第１操作は、検索条件入力画面を表示させる操作（たとえば、図１０１のＳ５９０：会員検索要求操作）と、表示された前記検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作（たとえば、図１０１のＳ５９２：会員検索条件入力操作）と、入力された前記検索条件に従って抽出された前記他の会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１０１のＳ５９４：閲覧対象者選択操作）とを含み、
前記第２操作は、前記１次関連会員遊技者を一覧表示させる操作（たとえば、図１００のＳ５７０：フレンドリスト操作）と、一覧表示された前記１次関連会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１００のＳ５８０：閲覧対象者選択操作）とを含む。
前記第１操作は、検索条件入力画面を表示させる操作（たとえば、図１０１のＳ５９０：会員検索要求操作）と、表示された前記検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作（たとえば、図１０１のＳ５９２：会員検索条件入力操作）と、入力された前記検索条件に従って抽出された前記他の会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１０１のＳ５９４：閲覧対象者選択操作）とを含み、
前記第２操作は、前記１次関連会員遊技者を一覧表示させる操作（たとえば、図１００のＳ５７０：フレンドリスト操作）と、一覧表示された前記１次関連会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１００のＳ５８０：閲覧対象者選択操作）とを含む。
このような構成によれば、他の会員遊技者を予め１次関連会員遊技者として登録しておくことで、検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作を行なわなくても当該１次関連会員遊技者の会員情報を閲覧することができる。その結果、遊技者の利便性を向上させることができる。
（５） 上記（１）〜（４）のいずれかの遊技用システムにおいて、
前記特定処理手段は、前記特定処理として、前記一の会員遊技者による遊技中に、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者と当該一の会員遊技者との間でメッセージを送受信する処理（たとえば、図３８、図３９：同じ遊技場内で遊技している仲良しフレンドとのチャットを行なう処理）を行なう手段を含む。
前記特定処理手段は、前記特定処理として、前記一の会員遊技者による遊技中に、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者と当該一の会員遊技者との間でメッセージを送受信する処理（たとえば、図３８、図３９：同じ遊技場内で遊技している仲良しフレンドとのチャットを行なう処理）を行なう手段を含む。
このような構成によれば、同じ遊技場内で遊技している２次関連会員遊技者との間でメッセージ送受信によるコミュニケーションをとることができる。その結果、遊技の興趣を向上させることができる。
（６） 上記（１）〜（５）のいずれかの遊技用システムにおいて、
前記会員情報には、属性情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員など）が含まれ、
前記他の会員遊技者の中から前記属性情報が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から属性情報が似ている会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して、一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する。「フレンド」の中から属性情報が似ている会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
前記会員情報には、属性情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員など）が含まれ、
前記他の会員遊技者の中から前記属性情報が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から属性情報が似ている会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して、一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する。「フレンド」の中から属性情報が似ている会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
このような構成によれば、自らに嗜好などが似ている遊技者を１次関連会員遊技者あるいは２次関連会員遊技者として登録し易くなる。その結果、遊技者の利便性を向上させることができる。
（７） 上記（１）〜（５）のいずれかの遊技用システムにおいて、
前記会員情報には、遊技履歴が含まれ、
前記他の会員遊技者の中から前記遊技履歴が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から遊技履歴が似ている会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する。「フレンド」の中から遊技履歴が似ている会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
前記会員情報には、遊技履歴が含まれ、
前記他の会員遊技者の中から前記遊技履歴が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から遊技履歴が似ている会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して一の会員遊技者が所有する情報機器の表示部あるいは一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する。「フレンド」の中から遊技履歴が似ている会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
このような構成によれば、自らに遊技履歴が似ている遊技者を１次関連会員遊技者あるいは２次関連会員遊技者として登録し易くなる。その結果、遊技者の利便性を向上させることができる。
（８） 上記（１）〜（７）のいずれかの遊技用システムにおいて、
前記遊技用装置が受付けた一の会員遊技者と関連性を持つ前記２次関連会員遊技者のうち、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者を特定可能な情報を、当該２次関連会員遊技者の遊技状況とともに表示する手段をさらに含む（図３７：「仲良しフレンド」のアバターを、大当りなどの遊技状況とともに一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）。
前記遊技用装置が受付けた一の会員遊技者と関連性を持つ前記２次関連会員遊技者のうち、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者を特定可能な情報を、当該２次関連会員遊技者の遊技状況とともに表示する手段をさらに含む（図３７：「仲良しフレンド」のアバターを、大当りなどの遊技状況とともに一の会員遊技者が遊技する遊技機の表示器５４、３１２に表示する）。
このような構成によれば、同じ遊技場内で遊技している２次関連会員遊技者を特定可能な情報と、その２次関連会員遊技者の遊技状況とを同時に確認することができる。その結果、遊技者の利便性を向上させることができる。
（９） 上記（１）〜（８）のいずれかの遊技用システムにおいて、
前記遊技機での遊技に関する遊技関連情報（トップボタン、メニューボタン、離席ボタン、返却ボタン、玉貸しボタン、再プレイボタン、払出ボタン、入金の残額、持玉数（持点数）、貯玉数、遊技玉数（遊技点数）など）を表示する表示領域を有する表示手段（表示器５４、３１２）と、
前記遊技用装置に入力される入力を受け付ける受付手段（たとえば、ＣＵ３が入金操作、玉貸し操作、払出操作、再プレイ操作、ログイン操作、広告表示操作、返却操作、離席操作などを受け付ける）と、
前記受付手段が受け付けた入力の種類に基づいて、前記表示手段に表示される広告情報の表示態様を設定する設定手段（たとえば、ＣＵ３が広告情報を表示する広告表示領域を設定する、ＣＵ３が広告情報を表示する時間を設定する）と、
前記設定手段により設定された前記表示態様で前記広告情報を前記表示手段に表示させる表示制御手段（たとえば、図４４〜図４７：ＣＵ３が設定された表示領域に広告情報を表示する）とをさらに含む。
前記遊技機での遊技に関する遊技関連情報（トップボタン、メニューボタン、離席ボタン、返却ボタン、玉貸しボタン、再プレイボタン、払出ボタン、入金の残額、持玉数（持点数）、貯玉数、遊技玉数（遊技点数）など）を表示する表示領域を有する表示手段（表示器５４、３１２）と、
前記遊技用装置に入力される入力を受け付ける受付手段（たとえば、ＣＵ３が入金操作、玉貸し操作、払出操作、再プレイ操作、ログイン操作、広告表示操作、返却操作、離席操作などを受け付ける）と、
前記受付手段が受け付けた入力の種類に基づいて、前記表示手段に表示される広告情報の表示態様を設定する設定手段（たとえば、ＣＵ３が広告情報を表示する広告表示領域を設定する、ＣＵ３が広告情報を表示する時間を設定する）と、
前記設定手段により設定された前記表示態様で前記広告情報を前記表示手段に表示させる表示制御手段（たとえば、図４４〜図４７：ＣＵ３が設定された表示領域に広告情報を表示する）とをさらに含む。
このような構成によれば、遊技用装置が受け付けた入力の種類に応じた表示態様で広告情報が表示される。そのため、広告情報によって遊技者の遊技中の操作が妨げられることはなく、遊技者に対して不快感を与えることもない。また、入力の種類に応じた表示態様で広告情報が表示されるため、広告の宣伝効果を向上させることができる。
以下、図面を参照して本発明に係る実施の形態を以下に説明する。
＜パチンコ機の構成＞
まず、図１を参照して、本実施の形態に係るパチンコ機の構成を説明する。遊技場（ホール）内に複数配置されている各遊技島（図示略）には、遊技機の一例の封入循環式パチンコ機（以下、遊技機、パチンコ機またはＰ台と略称することもある）２が併設されている。なお、Ｐ台２の所定側の側方位置には、該Ｐ台２に対して遊技用装置の一例のカードユニット（以下ＣＵと略称することもある）３が１対１に対応設置されている。なお、本実施の形態に係る遊技用装置として、カードユニットを例に以下説明するが、これに限られず、単にＰ台２の大当りや異常を報知するだけでなく、Ｐ台２での入賞回数などの遊技情報を収集することができる呼出しランプ装置などであってもよい。
＜パチンコ機の構成＞
まず、図１を参照して、本実施の形態に係るパチンコ機の構成を説明する。遊技場（ホール）内に複数配置されている各遊技島（図示略）には、遊技機の一例の封入循環式パチンコ機（以下、遊技機、パチンコ機またはＰ台と略称することもある）２が併設されている。なお、Ｐ台２の所定側の側方位置には、該Ｐ台２に対して遊技用装置の一例のカードユニット（以下ＣＵと略称することもある）３が１対１に対応設置されている。なお、本実施の形態に係る遊技用装置として、カードユニットを例に以下説明するが、これに限られず、単にＰ台２の大当りや異常を報知するだけでなく、Ｐ台２での入賞回数などの遊技情報を収集することができる呼出しランプ装置などであってもよい。
Ｐ台２は、内部に遊技媒体の一例のパチンコ玉を封入しており、遊技者が打球操作ハンドル２５を操作することにより、発射モータ１８（図２参照）を駆動させて封入玉を１発ずつ遊技盤２６前面の遊技領域２７に打込んで遊技ができるように構成されている。具体的には、打球操作ハンドル２５の周囲にタッチセンサが設けられており、遊技者が打球操作ハンドル２５を操作している状態でその遊技者の手がタッチセンサに触れ、その遊技者の手の接触をタッチセンサで検知して発射モータ１８が駆動される。この状態で、遊技者による打球操作ハンドル２５の回動操作量に応じて打球発射勢いが調整されて玉が遊技領域２７内に発射される。
図１に示すＰ台２は、いわゆる第１種のパチンコ機であって、遊技領域２７の中央に可変表示装置（特別図柄とも言う）２７８が設けられている。また、遊技領域２７には、打込まれたパチンコ玉が入賞可能な複数種類の入賞口が設けられている。図１に示す遊技領域２７には、１つの大入賞口（可変入賞球装置）２７１と、３つの普通入賞口２７２，２７３，２７４と、３つの始動入賞口２７５，２７６，２７７とが示されている。特に、始動入賞口２７６は、遊技者にとって有利な第１の状態（たとえば開成状態）と遊技者にとって不利な第２の状態（たとえば閉成状態）とに変化可能な電動チューリップで構成されている。
可変表示装置２７８は、複数種類の識別情報（図柄）を可変表示可能な可変表示部を備えており、各始動入賞口２７５，２７６，２７７に入賞した始動入賞玉の検出信号に基づいてそれらの複数種類の識別情報の可変表示を開始させる。可変表示装置の表示結果が特定の識別情報の組合せ（たとえばぞろ目）になると、大当り状態となり、大入賞口２７１が開放する。
また、可変表示装置２７８の表示結果が大当り図柄の組合せ（ぞろ目）のうちの予め定められた特別の識別情報の組合せ（たとえば７７７等の確変図柄の組合せ）となることにより、確変大当り状態が発生し、それに伴う大当り状態の終了後大当りの発生確率が向上した確率変動状態（確変状態）が発生する。
遊技領域２７内に打込まれたパチンコ玉はいずれかの入賞口に入賞するかあるいは入賞することなくアウト口１５４に回収される。いずれかの入賞口に入賞したパチンコ玉およびアウト口１５４に回収されたパチンコ玉は再度Ｐ台２内の回収経路を通って打球発射位置にまで還元される。そして、遊技者が打球操作ハンドル２５を操作することにより再びその打球発射位置のパチンコ玉が遊技領域２７内に打込まれる。
Ｐ台２における遊技領域２７の下方位置には、表示器５４が設けられている。表示器５４は、液晶表示装置で構成されており、持点やカード残額、あるいは可変表示装置２７８の表示と連動した様々な演出画像を遊技者に表示する。なお、表示器５４は、図１に示すようにＣＵ３から独立してＰ台２に取付けられる構成でも、ＣＵ３と一体に形成され、Ｐ台２の前面に嵌合させる構成でもよい。
さらに、Ｐ台２における打球操作ハンドル２５の左方位置には、遊技玉から持玉への計数処理をするための計数ボタン２８が設けられている。本実施の形態では、計数ボタン２８を押下し続けた時間に応じて計数動作が繰返し実行される。なお、押下継続時間に関わらず、１度押下すると、所定数（たとえば１００玉）だけ遊技玉から持玉への計数が行なわれるようにしてもよく、あるいは、計数ボタン２８を１度押下した場合には、その押下時間にかかわらず（長押しか否かにかかわらず）、現在遊技者が所有している遊技玉のすべてが計数されるようにしてもよい。
このように、計数ボタン２８をＰ台２側に設けているため、計数ボタン２８をＣＵ３側に設ける場合に比較して、Ｐ台２に正対して座っている遊技者の操作性を向上できる。
計数ボタン２８の右上方には、遊技玉数を表示するための遊技玉数表示器２９が設けられている。遊技玉数表示器２９は、７セグメント式のディスプレイである。なお、遊技玉数表示器２９は、液晶表示器や有機ＥＬ表示器、その他の表示器で構成してもよい。
本実施の形態に係るＰ台２は、遊技盤２６とそれ以外の遊技枠（前枠）６とに分けることができる。特に、遊技盤２６は、各社が開発するパチンコ機の機種毎に異なるものである一方、遊技枠６は、機種に関わらず共通の共通枠とされている。このため、遊技店は新台入れ替えの際には遊技盤２６のみの交換で事足りる。
＜カードユニットの構成＞
次に、引続き図１を参照して、本実施の形態に係るＣＵ３の構成を説明する。このＣＵ３は、会員登録をしていない一般の遊技者に対して発行される遊技用記録媒体であるプリペイド機能を備えるビジターカード（一般カードとも言う）、該遊技場に会員登録した会員遊技者に対して発行され、会員登録した遊技場でのみ紐付けされた貯玉や残額等が使用可能とされる遊技用記録媒体である遊技場会員カード、および複数の遊技場で共通に利用することができるように会員登録した会員遊技者に対して発行される遊技用記録媒体である共通会員カードを受付ける。ビジターカード、遊技場会員カードおよび共通会員カードはＩＣカードで構成されている。
次に、引続き図１を参照して、本実施の形態に係るＣＵ３の構成を説明する。このＣＵ３は、会員登録をしていない一般の遊技者に対して発行される遊技用記録媒体であるプリペイド機能を備えるビジターカード（一般カードとも言う）、該遊技場に会員登録した会員遊技者に対して発行され、会員登録した遊技場でのみ紐付けされた貯玉や残額等が使用可能とされる遊技用記録媒体である遊技場会員カード、および複数の遊技場で共通に利用することができるように会員登録した会員遊技者に対して発行される遊技用記録媒体である共通会員カードを受付ける。ビジターカード、遊技場会員カードおよび共通会員カードはＩＣカードで構成されている。
それらのカードを受付けたＣＵ３は、カードの記録情報により特定される遊技者所有の遊技価値（たとえばカード残額、持玉数、あるいは貯玉数等）を“遊技玉のデータ”に変換する機能を有する。Ｐ台２では、遊技玉のデータによって特定される玉数相当の弾球遊技が可能とされる。つまり、“遊技玉のデータ”とは、発射可能な玉の発射残数を示すデータである。以下の説明では、“遊技玉のデータ”を貯玉や持玉と同様に、単に“遊技玉”と称する。
ＣＵ３の前面側には、紙幣を挿入するための紙幣挿入口３０２、装置前面より装置前方方向に突出形成された突出部３０５、共通会員カード、遊技場会員カードまたはビジターカードを挿入するためのカード挿入／排出口３０９などが設けられている。このカード挿入／排出口３０９に挿入された共通会員カード、遊技場会員カードまたはビジターカードがカードリーダライタ（図示省略）に受付けられ、そのカードに記録されている情報が読取られる。
前述の突出部３０５において、遊技者と対向する面には、表示器３１２が設けられている。
本実施の形態のＣＵ３には、機械的な再プレイボタンは設けられず、表示器５４または表示器３１２に、再プレイボタンが表示され（図１１（Ａ），図１２（Ａ），図１３（Ａ）参照）、表示器５４または表示器３１２のタッチパネルで、表示されている再プレイボタンへの操作が検知される。再プレイボタンは、共通会員カードや遊技場会員カードを受付けた場合において、該共通会員カードや該遊技場会員カードに記録された会員カードＩＤや遊技場会員ＩＤ（単に、カードＩＤ、Ｃ-ＩＤとも言う）ならびに会員カードＩＤや遊技場会員ＩＤにより特定される貯玉数を用いた再プレイ遊技を実施するためのボタンである。
表示器３１２は、挿入された遊技用記録媒体（カード）に記録されているプリペイド残額（カード残額または単に残額とも言う）を表示するものであるが、遊技玉数やその他の各種情報を表示可能であるとともに、表面が透明タッチパネルで構成されており、表示器３１２の表示部に表示された各種表示項目を指でタッチすることにより各種操作が入力可能となるように構成されている。
再プレイボタンを操作した場合に、挿入されたカードに遊技者が獲得した持玉数が記録されているときにはその持玉数の一部を引落として遊技玉に変換し、変換した遊技玉に基づいてＰ台２による遊技を行なうことが可能となる。一方、挿入されたカードが共通会員カードや遊技場会員カードであり持玉数が記録されておらずかつ貯玉がホール用管理コンピュータ等に記録されている場合には、その貯玉の一部が引落とされて遊技玉に変換され、Ｐ台２による遊技が可能となる。つまり、挿入されたカードに対応付けて貯玉と持玉との双方が記憶されている場合には、持玉が優先的に引落とされる。なお、再プレイボタンとは別に、持玉を引落とすための専用の持玉払出ボタンを設け、再プレイボタンは貯玉引落とし専用のボタンとしてもよい。
ここで、「貯玉」とは、前日以前に獲得した玉でホールに預けている玉であり、貯玉払出により遊技玉となる。また、貯玉は、遊技場に預入れられた遊技媒体であり、一般的に当該遊技場に設置されたホール用管理コンピュータやその他の管理コンピュータにより管理される。
「持玉」とは、当日獲得した玉であり、持玉払出により遊技玉となる。また、持玉数は、遊技者が遊技機により遊技を行なった結果遊技者の所有となった遊技玉数をカードに記録したものであって、未だに遊技場に預入れられていない玉数のことである。一般的には、遊技場において当日遊技者が獲得した玉数を「持玉」と言い、前日以前に遊技者が獲得した玉数であって遊技場に預入れられた玉数を「貯玉」と言う。
「遊技玉」とは、遊技機で発射可能な玉である。遊技玉数のデータは、既に説明したとおり、プリペイドカードの残額、持玉、あるいは貯玉を引落とすことと引き換えにして生成される。
なお、持玉数を遊技場に設定された持玉数管理用の管理装置で管理してもよい。要するに、「貯玉」と「持玉」との違いは、遊技場に預入れるための貯玉操作が行なわれて遊技場に預入れられた玉数であるか、あるいは、未だに遊技場に預入れられていない段階の玉数であるかの点である。
本実施形態では、貯玉データは共通会員カードや遊技場会員カードに直接記録させずホール用管理コンピュータ等の遊技場に設置されたサーバに共通会員カード番号や遊技場会員カード番号と対応付けて記憶させ、共通会員カード番号や遊技場会員カード番号に基づいて対応する貯玉を検索できるように構成されている。一方、持玉は、カードに直接記録している。しかし、それに限定されるものではなく、両者ともにホールサーバ８０１にカード番号と対応付けて記憶させてもよい。ビジターカードの場合も、持玉は、ビジターカードに直接記録している。しかし、それに限定されるものではなく、持玉をホールサーバ８０１にカード番号と対応させて記憶させてもよい。このホールサーバ８０１にカード番号と対応させて記憶させる際に、ホールサーバ８０１に記憶させた時刻を特定できるデータをカード（共通会員カード、遊技場会員カード、ビジターカード）に書込んで排出してもよい。また、プリペイド残額についてはカード（共通会員カード、遊技場会員カード、ビジターカード）に直接書込んで排出する。
なお、持玉を、カード（共通会員カード、遊技場会員カード、ビジターカード）、またはホールサーバに記憶させるタイミングは、たとえば、計数ボタン２８が操作されて計数処理が行なわれる度にリアルタイムに記憶させる、一定周期ごとに記憶させる、またはカードを返却するときに一括して記憶させるなどのタイミングとすることが考えられる。
また、遊技者が遊技を終えてＣＵ３からカードを返却したときには、ＣＵ３に記憶していた持玉が一旦貯玉としてホールサーバ８０１に記憶されるようにし、その遊技者がカードの返却を受けた日と同じ日に再び同じまたは別のＣＵ３にカードを挿入したときには、一旦貯玉として記憶された当日分の持玉のみが再びそのＣＵ３に記憶され、その持玉の範囲で遊技玉を加算し、遊技できるようにしてもよい。
紙幣挿入口３０２に挿入された紙幣は、貨幣識別器（図示省略）により取込まれてその真贋や紙幣種別の識別がなされる。
ＣＵ３の前面側には、さらに、ＩＲ（Infrared）感光ユニット（ＩＲ受光ユニットとも言う）３２０と、カメラ３９９とが設けられている。ＩＲ感光ユニット３２０は、遊技場の係員が所持するリモコン（図示略）から赤外線信号を受信して電子信号に変換して出力する。カメラ３９９は、遊技者の顔画像を撮影して、ＣＵ制御部３２３に出力する。
本実施の形態においては、上述の再プレイボタンと同様、機械的な玉貸（球貸）ボタンおよびカード返却ボタンは設けられず、表示器５４または表示器３１２に、玉貸ボタンおよびカード返却ボタンが表示され（図１１（Ａ），図１２（Ａ），図１３（Ａ）参照）、表示器５４または表示器３１２のタッチパネルで、表示されている玉貸ボタンおよびカード返却ボタンへの操作が検知される。玉貸ボタンは、挿入されたカードに記録されている残額を引落としてＰ台２による遊技に用いるための操作（遊技玉への変換操作）を行なうボタンである。カード返却ボタンは、遊技者が遊技を終了するときに操作され、挿入されているカードに遊技終了時の確定した遊技玉数（カード挿入時の持玉数−遊技玉への変換数＋計数操作によって計数された持玉数）を記憶させて排出するための操作ボタンである。
＜カードユニットとパチンコ機との構成＞
図２は、ＣＵ３とＰ台２との構成を示すブロック図である。図２を参照して、ＣＵ３とＰ台２との制御回路の概略を説明する。
図２は、ＣＵ３とＰ台２との構成を示すブロック図である。図２を参照して、ＣＵ３とＰ台２との制御回路の概略を説明する。
ＣＵ３には、マイクロコンピュータ等から構成されたＣＵ制御部３２３が設けられている。このＣＵ制御部３２３は、ＣＵ３の主制御機能部であり、制御中枢としてのＣＰＵ（Central Processing Unit）、ＣＰＵが動作するためのプログラムや制御データ等を記憶しているＲＯＭ（Read Only Memory）、ＣＰＵのワークエリアとして機能するＲＡＭ（Random Access Memory）、周辺機器との信号の整合性を保つための入出力インターフェイス等が設けられている。
ＣＵ制御部３２３には、ホール用管理コンピュータやセキュリティ上の管理を行なうホールサーバ８０１（図３参照）と通信を行なうための外部通信部（図示省略）が設けられている。ＣＵ制御部３２３には、Ｐ台２の払出制御基板１７とセキュリティを確保しながら通信を行なうためのセキュリティ基板（ＳＣ基板）３２５が接続される。セキュリティ基板３２５は、ＣＵ３のセキュリティ監視機能部である。なお、セキュリティ基板３２５上にＣＵ制御部３２３を設けてもよく、あるいは、セキュリティ基板３２５とは別の基板にＣＵ制御部３２３を設けてもよい。ＣＵ３にはＰ台２側への接続部（図示省略）が設けられており、Ｐ台２にはＣＵ３側への接続部（図示省略）が設けられている。これら接続部は、たとえばコネクタ等で構成されている。
ＣＵ３側のセキュリティ基板３２５とＰ台２側の払出制御基板１７とは、このコネクタと接続配線とを介して通信可能に接続される。セキュリティ基板３２５には、セキュリティ基板３２５と払出制御基板１７との通信を制御するための通信制御ＩＣ３２５ａと、Ｐ台２のセキュリティを監視するためのセキュリティチップ（ＳＣ）３２５ｂが設けられている。さらに、ＳＣ３２５ｂは、不正検知部１３２５を備え、不正検知部１３２５がＣＵ制御部３２３からＰ台２に通知される遊技玉の加算要求情報を監視することにより不正検知を行ない、不正検知時に鍵管理サーバ８００（図３参照）に通知する。また、不正検知用の設定値（定数）は鍵管理サーバ８００から基板制御情報として通知される。
ＣＵ制御部３２３には、前述した貨幣識別器により紙幣の真贋および種類が識別されて、その識別結果信号が入力される。また、ＣＵ制御部３２３には、遊技場の係員が所持しているリモコンから発せられた赤外線をＩＲ感光ユニット３２０が受光すれば、その受光信号が入力される。ＣＵ制御部３２３には、挿入されたカードの記録情報をカードリーダライタが読取って、その読取り情報が入力されるとともに、ＣＵ制御部３２３からカードリーダライタに対し、挿入されているカードに書込むデータが伝送されたときに、カードリーダライタはそのデータを挿入されているカードに書込む。カードの記録情報には、カードＩＤが含まれる。ＣＵ制御部３２３は、カードリーダライタが読み取ったカードＩＤを遊技終了まで記憶する。
ＣＵ制御部３２３は、遊技者が遊技している際、遊技者の持玉を管理・記憶する。ＣＵ制御部３２３から残額あるいは遊技玉数等のデータが表示制御部３５０に出力され、表示制御部３５０で表示用データに変換される。Ｐ台２に対し、表示制御部３５０で変換した表示用データが送信される。Ｐ台２に送信された表示用データは、中継基板１４を介して表示器３１２に入力される。表示器３１２には、その表示用データに応じた画像が表示される。また、表示器３１２の表面に設けられているタッチパネルを遊技者が操作すれば、その操作信号が表示制御部３５０を介してＣＵ制御部３２３に入力される。遊技者が玉貸ボタンを操作することにより、その操作信号がＣＵ制御部３２３に入力される。なお、玉貸ボタンは、ＣＵ３に設ける構成に限定されるものではなく、Ｐ台２に設けて操作信号をＣＵ制御部３２３に入力する構成であっても良い。遊技者が再プレイボタンを操作することによりその操作信号がＣＵ制御部３２３に入力される。遊技者がカード返却ボタン３２２を操作することによりその操作信号がＣＵ制御部３２３に入力される。
Ｐ台２には、Ｐ台２の遊技の進行制御を行なう主制御基板１６と、遊技玉を管理・記憶する払出制御基板１７と、払出制御基板１７の指令に基づいて発射モータ１８を駆動制御する発射制御基板３１と、可変表示装置２７８と、主制御基板１６から送信されてくるコマンドに基づいて可変表示装置２７８を表示制御する演出制御基板１５とが備えられている。
主制御基板１６および演出制御基板１５は、遊技盤２６に設けてある。主制御基板１６には主制御部１６１である遊技制御用マイクロコンピュータが搭載されている。主制御部１６１は、遊技機の主制御機能部である。遊技機制御用マイクロコンピュータは、制御中枢としてのＣＰＵ（Central Processing Unit）、ＣＰＵが動作するためのプログラムや制御データ等を記憶しているＲＯＭ（Read Only Memory）、ＣＰＵのワークエリアとして機能するＲＡＭ（Random Access Memory）、周辺機器との信号の整合性を保つための入出力インターフェイス等が設けられている。主制御部１６１は、遊技盤２６に設けられている入賞センサ１６２、および電波センサ１６３と接続してある。
主制御部１６１は、各始動入賞口２７５，２７６，２７７に玉が入賞すると、大当り（あるいはさらに小当りを含む）／外れを決定するための乱数を抽選し、その乱数を記憶する。これを保留記憶という。保留記憶数の最大値は、たとえば、４である。主制御部１６１は、可変表示装置２７８で新たな可変表示を開始できる状態になれば、保留記憶を１つ消化してその保留記憶に基づいた大当り判定を行なうとともに可変開始から表示結果の導出に至るまでの可変表示時間を複数種類の中から決定する。また、大当りを決定したときには、確率変動を生じさせるか否かも併せて決定する。主制御部１６１は、その大当り判定の結果（確変にするか否かを含む）、および可変表示時間に関する情報をコマンドとして演出制御基板１５に搭載された演出制御部１５１へ送信する。
主制御部１６１から演出制御部１５１へ送信される可変表示に関するコマンドには、可変表示の開始を示す可変開始コマンド、可変表示の結果を示す表示結果コマンド（大当り／外れ）、可変表示パターンを特定可能な可変表示時間コマンド、可変表示結果を導出表示させるタイミングを示す可変停止コマンドなどが含まれる。さらに、主制御部１６１から演出制御部１５１へ送信されるコマンドには、大当り中に大当りの進行状況を特定可能なコマンドや、新たな保留記憶の発生を示すコマンド、遊技状態のエラーの発生を示すコマンドなどがある。
演出制御部１５１は、主制御部１６１から送信されてくるこれらのコマンドに基づいて可変表示装置２７８の可変表示内容を決定する。たとえば、演出制御部１５１は、主制御部１６１から送信されてくるコマンドに基づいて可変表示結果および可変表示時間を特定し、停止図柄を決定するとともに可変表示パターン（リーチの有無、リーチの種類）を決定し、さらには大当りやリーチに関する予告演出の演出パターンを決定する。演出制御部１５１は、決定した可変表示内容に従って可変表示装置２７８を表示制御する。
演出制御基板１５は、遊技枠６側の中継基板１４を介して、表示器５４とも接続されている。演出制御部１５１は、可変表示装置２７８に対して可変表示等のための表示制御信号を送信するとともに、可変表示装置２７８の表示と連動する表示を行なうための表示制御信号を表示器５４へ送信可能である。なお、中継基板１４および表示器５４は、ＣＵ３側に設けるようにしてもよい。この場合、Ｐ台２側の演出制御基板１５は、ＣＵ３に設けた中継基板１４と接続される。
払出制御基板１７は、前枠（遊技枠）６に設けてある。払出制御基板１７には、払出制御部１７１である払出制御用マイクロコンピュータが搭載されている。払出制御部１７１は、遊技機の払出制御機能部である。払出制御用マイクロコンピュータは、制御中枢としてのＣＰＵ（Central Processing Unit）、ＣＰＵが動作するためのプログラムや制御データ等を記憶しているＲＯＭ（Read Only Memory）、ＣＰＵのワークエリアとして機能するＲＡＭ（Random Access Memory）、周辺機器との信号の整合性を保つための入出力インターフェイス等が設けられている。
また、払出制御基板１７に対し、発射玉検出スイッチ９０３、アウト玉検出スイッチ７０１、ファール玉検出スイッチ３３、計数ボタン２８、電波センサ１７３が電気的に接続された状態で設けられている。この電波センサ１７３は、電波を不正に発信して主に玉上げスイッチ（上）４１ａを常時オン状態にする不正行為を検知するためのものである。この電波センサ１７３の検出信号が払出制御基板１７の入力ポート（図示省略）を介して払出制御部１７１へ入力される。玉上げスイッチ（上）４１ａは、オンからオフに変化したことにより遊技玉の発射を検出し、その検知に基づいて、払出制御部１７１が、遊技玉数を「１」減算する。
したがって、不正電波によりこの玉上げスイッチ（上）４１ａが常時オン状態になると、いくら玉を発射しても遊技玉数が減算されない状態となる。このような電波による不正を電波センサ１７３により検知する。
主制御基板１６から払出制御基板１７に対し、主制御チップＩＤ、入賞口情報、ラウンド情報、接続確認信号、入賞検出信号、始動入賞口入賞情報、エラー情報、図柄確定回数、大当り情報、メーカ固有大当りの情報が送信される。
主制御チップＩＤ（メインチップＩＤとも言う）は、Ｐ台２の主制御基板１６に記録されているチップＩＤのことであり、Ｐ台２の電源投入時に払出制御基板１７に対して送信される情報である。入賞口情報は、入賞口の種類（始動入賞口、普通入賞口、大入賞口）と、賞球数（入賞口に遊技玉が入ったときの払出玉数）とを含む情報であり、Ｐ台２の電源投入時に払出制御基板１７に対して送信される。ラウンド情報は、大当りしたときのラウンド数の情報であり、Ｐ台２の電源投入時に払出制御基板１７に対して送信される。
接続確認信号は、主制御基板１６と払出制御基板１７とが接続されていることを確認するための信号であり、主制御基板１６から払出制御基板１７へ所定の電圧の信号が常時供給されており、払出制御基板１７がその所定電圧信号を受信していることを条件として払出制御基板１７が動作制御するように構成されている。入賞検出信号は、始動入賞口以外の入賞口に入賞したパチンコ玉の検出信号である。この検出信号を受けた払出制御基板１７は、その入賞玉１個に対して付与すべき玉数を、遊技玉数と加算玉数とに加算する制御を行なう。
始動入賞口入賞情報とは、始動入賞口のいずれかにパチンコ玉が入賞したことを示す情報である。エラー情報とは、主制御基板１６が遊技制御を行なっている最中にエラーが発生した場合にその旨を払出制御基板１７へ通知するための情報である。
図柄確定回数とは、各始動入賞口への入賞に対する可変表示装置の表示結果として確定した図柄の情報である。
大当り情報とは、大当りが発生したことを示す情報であり、その内訳は、各メーカ共通の大当りを示す共通大当り情報とメーカ固有の大当りを示すメーカ固有大当り情報とがある。共通大当り情報は、たとえば１５ラウンド大当り等のように、各遊技機メーカが共通に採用している大当りであり、その大当りに伴って確変が発生する場合には確変情報を含み、その大当りに伴って時短状態（可変表示装置の可変表示時間を短縮する制御状態）が発生する場合にはその時短情報を含んでいる。メーカ固有大当りとは、たとえば突然確変（突確）のような、或る遊技機メーカのみが採用している大当り状態のことである。
払出制御基板１７から主制御基板１６へ、ヘルスチェックコマンドと賞球個数受付コマンドとが送信される。ヘルスチェックコマンドとは、主制御基板１６が正常に動作しているか否かをチェックするためのコマンドである。賞球個数受付コマンドとは、加算玉数を受付けた旨を示すコマンドである。
アウト玉検出スイッチ７０１から払出制御基板１７へアウト玉検出信号が入力される。このアウト玉検出信号が入力された払出制御基板１７は、後述するように遊技中玉数（遊技領域２７に浮遊している浮遊玉の玉数）を減算更新する。ファール玉検出スイッチ３３からファール玉検出信号が入力された払出制御基板１７では、後述するように、加算玉数と遊技玉数とを加算更新するとともに、遊技中玉数を減算更新する。発射玉検出スイッチ９０３から払出制御基板１７へ発射玉検出信号が入力される。この発射玉検出信号が入力された払出制御基板１７は、遊技中玉数を減算更新する。
ＣＵ３のセキュリティ基板３２５とＰ台２の払出制御基板１７とが電気的に接続されており、セキュリティ基板３２５から払出制御基板１７へ、後述するように各種コマンドが送信される。逆に、払出制御基板１７からセキュリティ基板３２５へ、後述するように各種レスポンスが送信される。
遊技枠６には、払出制御基板１７の他、中継基板１４、発射制御基板３１、発射モータ１８、遊技玉数表示器２９が設けられている。なお、遊技玉数表示器２９は遊技枠６に直接取り付けてもよいが、玉が払い出される通常のパチンコ機の前面側に設けられた上皿や下皿のように、遊技枠６に対して回動可能な態様で設けるようにしてもよい。この点は、表示器５４についても同様である。払出制御基板１７の払出制御部１７１は遊技玉数表示器２９に遊技者が現在所有している遊技玉数を表示する。
払出制御基板１７から発射制御基板３１へ、発射制御信号と発射許可信号とが出力される。それを受けた発射制御基板３１は、発射モータ１８を励磁するための信号を出力する。これにより、パチンコ玉が遊技領域２７へ弾発発射される状態となる。発射制御基板３１は、遊技者が打球操作ハンドル２５に触れていることを検出するタッチリングの入力信号が入力されているときに発射モータ励磁出力を発し、発射モータ１８を駆動させる。
遊技枠６には、表示器５４が設けられている。表示器５４は、中継基板１４を介してＣＵ３の表示制御部３５０からの表示データ（表示制御信号）を受信する。さらに、表示器５４は、中継基板１４を介して演出制御基板１５からの表示データ（表示制御信号）を受信する。
中継基板１４には演出制御基板１５および表示制御部３５０のうち一方からの表示制御信号を表示器５４へ出力して表示器５４に演出制御基板１５または表示制御部３５０からの表示制御信号に基づく画像を表示するための切換回路１４１が搭載されている。
なお、本実施の形態では、Ｐ台２側の表示器５４がＣＵ側で制御されるように構成されているが、これに代えて、Ｐ台２側に表示器５４を表示制御するための表示制御用基板を設けてもよい。この場合、表示制御用基板は、払出制御部１７１の指令に基づいて表示器５４を表示制御する。
ＲＡＭクリアスイッチ２９３は、Ｐ台２のＲＡＭに記憶している遊技台情報や遊技情報を消去するためのスイッチであり、Ｐ台がエラー状態となった後当該スイッチを店員が操作することで初期状態に戻すことが可能となる。このＲＡＭクリアスイッチ２９３は、たとえばカードが排出された後に店員により操作される。
＜パチンコ玉の循環経路＞
ここでは、図１および図２を参照して、Ｐ台２におけるパチンコ玉の循環経路を概説する。
ここでは、図１および図２を参照して、Ｐ台２におけるパチンコ玉の循環経路を概説する。
遊技者が打球操作ハンドル２５を操作すると、発射モータ１８が駆動する。これにより、発射位置にまで供給されてきた１個のパチンコ玉が打球ハンマーにより弾発されてそのパチンコ玉が遊技領域２７に打込まれる。
遊技玉の発射検出は、玉上げスイッチ（上）４１ａがオンからオフに変化したことにより検出される。この検出は、払出制御部１７１が設けられている払出制御基板１７（図２参照）でのポート入力により検知され、その検知に基づいて、払出制御部１７１が、遊技玉数を「１」減算する。
遊技領域２７に打込まれた玉のうち、アウト口１５４（図１参照）に進入したアウト玉は、アウト玉流下経路を流下し、その途中に設けられたアウト玉検出スイッチ７０１によって検出される。ファール玉は、ファール玉戻り経路を通って流下し、その途中に設けられたファール玉検出スイッチ３３によって検出される。
入賞口や可変入賞球装置に入賞したすべての入賞玉は、遊技機背面で集められて回収玉通過経路に誘導される。同様に、アウト玉およびファール玉も回収玉通過経路に誘導される。回収玉通過経路には発射玉検出スイッチ９０３が設けられている。このため、入賞玉、アウト玉、およびファール玉のすべてが発射玉検出スイッチ９０３によって検出される。つまり、発射玉検出スイッチ９０３は、弾発されたパチンコ玉のすべてを検出するスイッチである。このスイッチの検出数と、発射モータ１８により弾発されたパチンコ玉の弾発数とが等しくなったときに、打込まれたパチンコ玉がすべて回収されたと判定できる。
そこで、本実施の形態では、発射玉検出スイッチ９０３の検出数と弾発数との差を演算しており、この差数が０でないときには、遊技領域２７に打込まれた玉の回収が済んでいないと判定している。この判定をすることによって、遊技領域２７を転動中であるか、遊技領域の釘等の間に引っ掛かって落下していないような浮遊玉が存在していないかどうかを判断できる。
＜表示器（タッチパネル）の表示制御＞
主制御基板１６に搭載されている主制御部１６１は、遊技制御に伴い変化する各種の遊技情報を払出制御基板１７の払出制御部１７１へ送信する。払出制御部１７１は、主制御部１６１から送信されてくる遊技情報に基づいて玉数情報等をＣＵ制御部３２３へ送信するとともに、遊技玉数表示器２９を表示制御する。その結果、遊技玉数表示器２９には、遊技者が現在所有している遊技玉数が表示され、玉の発射あるいは計数操作に基づいて遊技玉数の表示が減算更新され、入賞の発生あるいは貸玉操作等に基づいて遊技玉数の表示が加算更新される。
主制御基板１６に搭載されている主制御部１６１は、遊技制御に伴い変化する各種の遊技情報を払出制御基板１７の払出制御部１７１へ送信する。払出制御部１７１は、主制御部１６１から送信されてくる遊技情報に基づいて玉数情報等をＣＵ制御部３２３へ送信するとともに、遊技玉数表示器２９を表示制御する。その結果、遊技玉数表示器２９には、遊技者が現在所有している遊技玉数が表示され、玉の発射あるいは計数操作に基づいて遊技玉数の表示が減算更新され、入賞の発生あるいは貸玉操作等に基づいて遊技玉数の表示が加算更新される。
ＣＵ制御部３２３は、払出制御部１７１から送信されてくる玉数情報等に基づいて自ら記憶している遊技玉数等の遊技情報を更新する。また、ＣＵ制御部３２３はカード残額や遊技者の持玉を記憶しており、Ｐ台２側の表示器５４にそれら記憶している遊技情報に基づいた表示をするための情報を表示制御部３５０へ送信する。表示制御部３５０は、その情報に基づいた表示制御信号をＰ台２側の中継基板１４へ送信する。
一方、中継基板１４には、演出制御基板１５の演出制御部１５１からの表示制御信号も入力される。演出制御部１５１は、主制御部１６１から受信する各種の可変表示コマンドに基づいて可変表示装置２７８を表示制御するための表示制御信号を可変表示装置２７８へ送信するとともに、表示器５４を表示制御するための表示制御信号を中継基板１４へも送信する。
中継基板１４には、通常、ＣＵ３の表示制御部３５０側のみから表示制御信号が送信されており、演出制御部１５１からは表示制御信号は送信されない。その結果、通常は、表示器５４にはＣＵ３の表示制御部３５０からの表示制御信号に基づいた持点やカード残額などの情報が表示される。ところが、演出制御部１５１は、主制御部１６１から送信されてくるコマンドに基づいて遊技機の遊技状態の変化を検出すると、その遊技状態の変化に応じた表示制御信号を中継基板１４へ送信する。
切換回路１４１は、演出制御部１５１からの表示制御信号の入力があると、表示制御部３５０から入力される表示制御信号ではなく、演出制御部１５１から入力される表示制御信号を表示器５４へ送信するように回路を切換える。その結果、表示器５４には通常時はＣＵ３側の表示制御に基づいた持点等の表示がなされ、たとえば、可変表示装置２７８に大当り表示がなされるなどして遊技状態が変化すると、表示器５４の表示が大当り表示などの可変表示装置２７８の表示と連動するものに切換えられる。また、その後、演出制御部１５１から中継基板１４への表示制御信号の送信が停止すると、切換回路１４１は、信号の入力元を切換え元に戻す。その結果、表示器５４には、再び、ＣＵ３側の表示制御に基づいた情報が表示される。
つまり、上記の例は、切換回路１４１は、演出制御部１５１および表示制御部３５０のうち、演出制御部１５１から入力される表示制御信号を優先して表示器５４へ送信する構成である。通常時は表示制御部３５０のみから表示制御信号が切換回路１４１へと入力されるので、表示器５４にはＣＵ３側の表示制御に基づいた情報が表示され、大当り発生などの切換条件が成立して演出制御部１５１から表示制御信号が入力されると、その表示制御信号が優先されて表示器５４へ送信され、表示器５４の表示が切換えられる。
しかしながら、これに代えて、切換回路１４１は、演出制御部１５１および表示制御部３５０のうち、表示制御部３５０から入力される表示制御信号を優先して表示器５４へ送信する構成を採用してもよい。
すなわち、切換回路１４１は、通常時は演出制御部１５１から常時受信する表示制御信号に基づいて表示器５４に可変表示装置２７８の表示と連動する演出表示を行ない、遊技点や持点が残り少なくなどの所定の切換条件が成立してＣＵ３側からその旨を表示するための表示制御信号が入力されると、信号の入力元を演出制御部１５１から表示制御部３５９に切換えることにより、表示器５４が遊技演出画面から遊技点や持点が残り少ない旨等を報知する画面に変化するようにしてもよい。
本実施の形態では、遊技玉数を表示する遊技玉数表示器２９の表示制御はＣＵ３ではなく、遊技玉数の変動に直接的に関わるＰ台２によって行なわれるため、遊技玉数が遊技で使用されて減算され、あるいは遊技によって加算された場合に、その更新後の遊技玉数を即座に遊技玉数表示器２９に反映させることができる。
仮に、遊技玉数表示器２９の表示制御をＣＵ３が行なうものとした場合には、Ｐ台２からＣＵ３に対して送信する遊技玉数の情報に基づいてＣＵ３から遊技玉数表示器２９へと表示制御信号が送られるものとなる、しかし、その場合、ＣＵ３とＰ台２との通信状況等によって、実際には遊技玉数が変化しているものの、その変化が遊技玉数表示器２９にすぐに反映されないものとなるという不都合が生じるおそれがある。本実施の形態によれば、このような不都合が生じることを防止できる。
一方、表示器５４はＣＵ３側で表示制御するために、遊技玉数表示器２９を表示制御するＰ台２がさらに表示器５４をも表示制御する場合と比較して、Ｐ台２の表示制御負担を軽減できる。
ここで、表示器５４の表示を切り替える具体例を挙げる。たとえば、通常時は表示器（タッチパネル）５４にＣＵ３の表示制御部３５０の表示制御に基づいたカード残額等の表示をし、大当り発生等の遊技状態の変化に応じて表示器５４の表示を可変表示装置２７８の表示と連動したものに切換える例を挙げることができる。
あるいは、通常時は表示器（タッチパネル）５４に可変表示装置２７８の表示と連動した表示（演出制御部１５１の表示制御に基づく）をし、遊技点の減少に応じて表示器５４に遊技点が残り少ないことを報知する画像を表示する例を挙げることができる。
なお、演出制御部１５１から中継基板１４に送信される表示制御信号で表示器５４が表示動作する場合には、中継基板１４は単に演出制御部１５１から送信されてきた信号を中継してそのまま表示器５４に送信する機能を備えておけばよい。これに対して、表示器５４を表示動作させるための表示制御信号の信号形態と、演出制御部１５１から送信される表示制御信号との信号形態とが異なる場合も考えられ、この場合には、中継基板１４に切換回路１４１に加えて信号形態を変換する変換回路を設ければよい。
さらに、切換え条件成立時に演出制御部１５１から送信される表示制御信号によって表示器５４に表示される演出画像と、同じく演出制御部１５１から送信される表示制御信号によって可変表示装置２７８に表示される画像とが同じものであってもよく、異なるものであってもよい。異なるものとした場合には、演出制御部１５１には可変表示装置２７８用の画像データと表示器５４用の画像データとの２種類の画像データを記憶させておく必要がある。
また、遊技玉数表示器２９は、主制御部１６１が表示制御する構成としてもよく、あるいは、主制御部１６１から演出制御部１５１へ遊技玉数に関するコマンドを送信することによって演出制御部１５１が表示制御する構成としてもよい。
以上、説明した本実施の形態によれば、Ｐ台２の表示器５４には可変表示に関する演出情報を表示可能であるために、可変表示装置２７８と併せて演出効果の高い遊技を提供できる。しかも、表示器５４にＣＵ３側から送られてくる遊技情報を表示する条件が成立したときには、ＣＵ３によってその遊技情報を表示器５４に表示するための表示制御が実行されるため、その条件の成立の際には表示器５４を遊技演出ばかりでなくＣＵ３による遊技情報の表示にも活用でき、しかも遊技情報の表示に伴うＰ台２の表示制御負担も軽減できる。
＜カードユニットおよびパチンコ機に発生した異常の通知処理＞
図３は、相互認証の結果、異常を検知した場合の通知処理を説明するための説明図である。
図３は、相互認証の結果、異常を検知した場合の通知処理を説明するための説明図である。
図３を参照して、ＣＵ制御部３２３、セキュリティ基板３２５、払出制御部１７１、あるいは主制御基板１６において異常が発生した場合には、図３の矢印で示す方向に対して通知が行なわれる。ここで言う異常には、ＣＵ制御部３２３、セキュリティ基板３２５、払出制御部１７１、あるいは主制御基板１６を、不正に製造された他のものに差し替えるとか、あるいはノイズ等により誤作動したり故障したりした場合や、断線等によるオフライン状態などが含まれる。図３に示される鍵管理サーバ８００は、ＣＵ３内部の電子部品のシリアルＩＤ（ＳＩＤとも言う）毎に対応付けて、ＣＵ通信制御部のＳＩＤと認証鍵とを記憶している鍵の管理サーバである。また、鍵管理サーバ８００は、主制御基板１６と互いに通信可能なサーバである。
まず、ＣＵ３のセキュリティ基板３２５により異常が発生した場合には、前述したＣＵ制御部３２３とセキュリティ基板３２５との間で行なわれる相互認証の結果、ＣＵ制御部３２３が異常を検知する。この相互認証では、後述するシリアルＩＤ認証と機器認証の他に、セッション鍵による機器認証も含まれている。
シリアルＩＤは、セキュリティ基板３２５のシリアルＩＤ（基板シリアルＩＤ）であり、セキュリティ基板３２５のセキュリティチップ３２５ｂを製造する段階において、該セキュリティチップ３２５ｂのＲＯＭに記憶されている。また、ＣＵ３が遊技場に搬入された後、ホールサーバ８０１に接続されたときに、鍵管理センタの鍵管理サーバ８００からホールサーバ８０１経由で基板シリアルＩＤがダウンロードされてＣＵ制御部３２３に記憶される。
ＣＵ制御部３２３がセキュリティ基板３２５の異常を検知した場合、ＣＵ制御部３２３はホールサーバ８０１にその旨を通知するとともに、ＣＵ３の表示制御部３５０に異常報知コマンドを送信する。ＣＵ制御部３２３は、表示器３１２に異常発生した旨の表示を行なう制御を表示制御部３５０に行なわせるとともに、異常報知ランプ（図示せず）を点灯または点滅させて異常報知を行なう。さらに、ＣＵ制御部３２３は、外部通信部からホール用管理コンピュータへ異常が発生した旨の信号を送信する。
ＣＵ３のＣＵ制御部３２３により異常が発生した場合には、前述した相互認証によりセキュリティ基板３２５が異常発生を検知し、その旨を示す信号（異常通知信号）を払出制御部１７１に通知する。払出制御部１７１はそれを受けて異常発生した旨を主制御基板１６へ通知する。主制御基板１６は、前述と同様に、異常報知ランプを作動させる制御を行なうとともにホール用管理コンピュータへ異常が発生した旨の信号を送信する。
セキュリティ基板３２５が払出制御部１７１の異常を検知した場合には、その旨をＣＵ制御部３２３へ通知し、ＣＵ制御部３２３がその旨をホールサーバ８０１へ通知する。
このように、セキュリティ基板３２５は、ＣＵ制御部３２３の異常を検知したときにはその旨を払出制御部１７１へ通知する一方、払出制御部１７１の異常を検知したときには、その旨をＣＵ制御部３２３へ通知するものであり、セキュリティ基板３２５による異常発生の通知先がそれぞれ異なる。その理由は、異常が発生した制御部に対して異常が発生した旨を通知しても、何ら異常報知のための制御が行なわれず、異常防止対策にはならないためである。しかも、セキュリティ基板３２５は、通信制御の機能は有しているものの異常報知制御の機能は有していない。よって、自ら異常報知の制御が行なえず、そのために必ず異常が発生した制御部とは反対側の制御部の方向に異常発生した旨の通知を行なうのである。なお、セキュリティ基板３２５からの異常発生の通知を受けた払出制御部１７１は、その旨を主制御基板１６へ通知する。主制御基板１６はその通知を受けて、前述と同様の異常報知のための制御を行なう。
払出制御部１７１に異常が発生した場合には、その旨がセキュリティ基板３２５により検知され、異常が発生した旨がＣＵ制御部３２３へ通知され、ＣＵ制御部３２３は前述した異常報知制御を行なうとともにホールサーバ８０１へ異常が発生した旨を通知する。また、払出制御部１７１に異常が発生した場合には、主制御基板１６が異常発生した旨を検知し、その通知を受けて前述した異常発生報知用の制御を行なう。
払出制御基板１７は、前述したように、セキュリティ基板３２５に異常が発生した場合にはそれを検知して主制御基板１６へ通知する一方、主制御基板１６に異常が発生した場合にはそれを検知してセキュリティ基板３２５へ異常が発生した旨を通知する。この払出制御基板１７も、前述したセキュリティ基板３２５と同様に、異常が発生した旨を検知した場合にはその異常が発生した制御部に対して通知を行なっても異常報知用の制御が行なわれないために、異常が発生した制御部とは反対側の制御部あるいは制御基板に通知を行なう。なお、セキュリティ基板３２５と払出制御基板１７とは、異常報知ランプや異常報知用表示器等の異常報知手段が接続されておらず、異常を検知しても自ら異常報知制御する機能を有していない。なお、上記の説明では、セキュリティ基板３２５と払出制御基板１７とは、異常報知ランプや異常報知用表示器等の異常報知手段が接続されておらず、異常を検知しても自ら異常報知制御する機能を有していないこととして説明したが、セキュリティ基板３２５と払出制御基板１７とに異常報知の機能を設け、直接異常を発生した旨を通知させてもよい。
＜カードユニット側とパチンコ機側との送受信態様＞
次に、図４は、ＣＵ３側とＰ台２側とのそれぞれで記憶している各種データの内の主なものおよびその送受信態様を示す模式図である。図４を参照して、ＣＵ３側とＰ台２側とのそれぞれで記憶している各種データの内の主なものおよびその送受信態様を説明する。
次に、図４は、ＣＵ３側とＰ台２側とのそれぞれで記憶している各種データの内の主なものおよびその送受信態様を示す模式図である。図４を参照して、ＣＵ３側とＰ台２側とのそれぞれで記憶している各種データの内の主なものおよびその送受信態様を説明する。
本実施の形態においては、Ｐ台２側において遊技玉数の変動を算出して現在の最新の遊技玉数を記憶・管理している。ＣＵ３側においても現在の遊技玉数の算出・記憶を行なっているが、その遊技玉数はＰ台２側から送信されてきた情報に基づいたものである。一方、持玉（カード持玉数）や貯玉数、カード残額（残額）は、ＣＵ３側において管理・記憶している。
図４では、ＣＵ３側のＣＵ制御部３２３に設けられているＲＡＭの記憶データと、Ｐ台２側の払出制御基板１７に搭載されているＲＡＭの記憶データとを示している。まず、Ｐ台２とＣＵ３とが遊技場に設置されて初めて電気的に接続された状態で電源を立上げたときに、Ｐ台２側の払出制御基板１７は、主制御基板１６からメインチップＩＤ（主制御チップＩＤ）を送信してもらい、そのメインチップＩＤをＣＵ３側に送信するとともに、払出制御基板１７自体が記憶している払出チップＩＤ（払出制御チップＩＤ）をＣＵ３側へ送信する。
ＣＵ３側では、それら送信されてきたメインチップＩＤと払出チップＩＤとを記憶する。次に、接続時刻すなわちＣＵ３側とＰ台２側とが接続されて通信が開始された時刻のデータがＣＵ３側からＰ台２側へ送信され、Ｐ台２側ではその送信されてきた接続時刻を記憶する。
この状態で、メインチップＩＤ、払出チップＩＤおよびＣＵ３側で識別された接続時刻の３つの情報がＣＵ３側とＰ台２側とに記憶されることとなる。それ以降の電源投入時においては、Ｐ台２側からＣＵ３側へそれら３つの情報、すなわち、メインチップＩＤと払出チップＩＤと前回の接続時刻データとが送信される。
ＣＵ３側では、それら送信されてきたデータと既に記憶しているデータとを照合し、前回と同じＰ台２が接続されているか否かを判別する。なお、接続時刻のデータは、電源が立上げられる度にＣＵ３側とＰ台２側との通信が開始された新たな接続時刻データがＣＵ３側からＰ台２側へ送信されてその新たな接続時刻データをＰ台２側において記憶することとなる。
ＣＵおよびＰ台の双方は、電文に「通番」を付加して送信する。また、ＣＵおよびＰ台の双方は、相手から受信した「通番」を記憶する。「通番」には、「通常通番」、「加算通番」および「計数通番」の３種類がある。「通常通番」は、電文のシーケンス番号を示す。「通常通番」は、ＣＵ３側（一次局側）が初期値を「１」として送信時に受信した通番をカウントアップ（＋１）して送信する。ただし、再送時は、「通常通番」をカウントアップしない。Ｐ台２側（二次局側）は受信した通番をそのまま送信する。なお、通番の連続性が成立しない場合は無応答となる。「加算通番」はＣＵ３がＰ台２に対して遊技玉の加算を要求する際に用いられる通番である。「計数通番」は、Ｐ台２がＣＵ３に対して遊技玉の計数を要求する際に用いられる通番である。
通常通番の更新権はＣＵ３のみが有する。ＣＵ３は、送信した通常通番と同じ通常通番が返信されてきたときに、通常通番をバックアップ記憶した上で、更新した通常通番を送信する。加算通番の加算更新権はＣＵ３のみが有する。ＣＵ３は、加算要求をする場合には、それまで通信に用いていた加算通番に+１した加算通番をＰ台２へ送信する。Ｐ台２は、要求を承諾するときには、同じ加算通番を返信する。要求を拒否するときには、前回、受信した加算通番（今回受信した加算通番−１）を返信する。計数通番の加算更新権はＰ台２のみが有する。Ｐ台２は、計数要求をする場合には、それまで通信に用いていた計数通番に+１した計数通番をＣＵ３へ送信する。ＣＵ３は、要求を承諾するときには、同じ計数通番を返信する。要求を拒否するときには、受信した計数通番（今回受信した計数通番−１）を返信する。
以下では、「通常通番」について、ＣＵ３が送信時に受信した通番をカウントアップ（＋１）して送信する構成について説明する。しかし、本発明は当該構成に限定されるものではなく、Ｐ台２およびＣＵ３のそれぞれが、またはＰ台２が送信時に受信した通番をカウントアップ（＋１）して送信し、他方は受信した通番をそのまま送信する構成であってもよい。
また、「加算通番」および「計数通番」は、それぞれ、加算要求の処理および計数要求の処理においてカウントアップされる特別な通番である。以下では、この「加算通番」および「計数通番」がカウントアップされる際、「通常通番」もカウントアップする構成について説明する。しかし、本発明は当該構成に限定されるものではなく、「加算通番」および「計数通番」がカウントアップされる際に「通常通番」のカウントアップを停止する構成であってもよい。なお、以下では、「通常通番」を単に「通番」と称する。また、「加算通番」および「計数通番」を併せて「要求通番」とも称する。
Ｐ台２側からＣＵ３側へは、最新遊技台情報（カウント中の遊技台情報）が送信される。この最新遊技台情報は、Ｐ台２側の払出制御部１７１（図２参照）のＲＡＭの最新遊技台情報記憶領域に記憶されている。具体的には、加算玉数カウンタの情報と、減算玉数カウンタの情報と、計数玉数カウンタの情報とが含まれる。なお、遊技玉数は、最新遊技台情報に含まれず、後述するように遊技玉数カウンタのカウント値としてＰ台２側からＣＵ３側へ送信している。しかし、これに代えて、あるいは遊技玉数カウンタに加えて、遊技玉数も最新遊技台情報に含めてもよい。
これらのカウンタの情報が、まとめてレスポンスとしてＣＵ側へ送信される。加算玉数カウンタは、加算玉数をカウントするカウンタである。加算玉は、「賞球玉数×入賞個数」と「バック玉数」との和である。なお、バック玉とはファール玉のことである。つまり、加算玉とは、加算玉カウンタが遊技玉に加算すべき数を示す。減算玉数カウンタは、減算玉数をカウントするカウンタである。減算玉は、「発射玉数」である。つまり、玉上げスイッチ（上）４１ａのオンからオフへの出力変化により検出された玉数である。なお、「減算玉数」には、「計数玉数」は含まれない。計数玉数カウンタは、計数玉数をカウントするカウンタである。計数玉は、「計数操作によって遊技玉から持玉に変換された玉数」である。ここで、「賞球玉」は、入賞口へ玉が入賞することにより払出される玉であり、セーフ玉である。「発射玉」は、遊技機が発射した玉であり、バック玉がある場合はバック玉を減算した玉数が発射玉数となる。「バック玉」は、発射玉が盤面上に跳出せずに戻ってきた玉である。「アウト口通過玉」は、アウト口１５４を通過した玉であり、アウト玉とセーフ玉の合計玉数がアウト口通過玉数を意味する。
たとえば、遊技領域２７に打込まれたパチンコ玉が入賞して主制御基板１６から入賞情報が払出制御基板１７へ送信されてきたときに、その入賞情報に基づいて遊技玉を加算すべき加算玉数を加算玉数カウンタがカウントし、その加算玉数カウンタの値（加算玉数）をＰ台２側からＣＵ３側へ送信する。また、パチンコ玉が遊技領域２７内に発射されていることによる玉上げスイッチ（上）４１ａのオンからオフへの出力変化に基づいて減算玉数カウンタが発射玉数を減算玉数としてカウントし、その減算玉数カウンタの値（減算玉数）をＰ台２側からＣＵ３側へ送信する。
あるいは、払出制御部１７１は、計数ボタン２８の押下により、遊技玉数を計数玉数としてカウントし、その計数玉数カウンタの値（計数玉数）をＰ台２側からＣＵ３側へ送信する。
Ｐ台２側においては、加算玉数カウンタ、減算玉数カウンタ、および計数玉数カウンタの値をＣＵ３側へ送信する毎に、それらカウント値を前回遊技台情報記憶領域（払出制御部１７１のＲＡＭ等）にバックアップデータとして記憶（書換え）した後、最新遊技台情報としての加算玉数カウンタ、減算玉数カウンタ、および計数玉数カウンタの値を０クリアする（遊技玉数カウンタを除く）。なお、本実施の形態において「クリア」とは「初期化」と同じ意味である。
その結果、前回遊技台情報（直前に送信した遊技台情報）の記憶エリアに、直前にＣＵ３側に送信した遊技台情報である、加算玉数、減算玉数、および計数玉数のデータがバックアップデータとして記憶される。このバックアップデータは、Ｐ台２側からＣＵ３側へ最新遊技台情報が送信されなかった場合に、次の送信に際して今回の各カウンタの値ばかりでなくその送信されなかった前回の各カウンタの値をも送信できるようにするためのものである。この前回遊技台情報に、直前に送信した遊技玉数をさらに加えて記憶するようにしてもよい。
また、払出制御基板１７は、入賞の発生、玉の発射、バック玉の発生、および計数玉の発生（遊技玉から持玉への変換）に応じて、遊技玉数カウンタの値を更新し、その更新後の遊技玉数カウンタの値を遊技玉数としてＣＵ３側に送信する。
ＣＵ３側においては、ＲＡＭ内の累計データ記憶領域に、遊技玉数、カード持玉数（単に、持玉数とも言う）、貯玉数、残額、総加算玉数（加算玉数累計）、総減算玉数（減算玉数累計）、およびカード挿入時持玉数を記憶している。なお、カード持玉数は、カード挿入時持玉数から持玉払出数（カード持玉数から遊技玉数に変換した玉数）を減算し、計数玉数を加算した玉数である。つまり、カード持玉数は、現時点で遊技者が所有している持玉数である。
Ｐ台２側から送信されてきた加算玉数カウンタの値（加算玉数）に基づいて総加算玉数を加算して玉数を更新する。また、Ｐ台２側から送信されてきた減算玉数カウンタの値（減算玉数）に基づいて総減算玉数を減算して玉数を更新する。さらに、Ｐ台２から送信されてきた計数玉数カウンタの値に基づいてカード持玉数を加算して更新する。このように、ＣＵ３は、Ｐ台２より逐一送信されてくる最新遊技台情報によって総加算玉数、総減算玉数、カード持玉数を更新することで最新のそれらの情報を管理することが可能となる。
ＣＵ３は、図示のとおり、遊技玉を記憶する領域を備えているとともに、Ｐ台２側から遊技玉数カウンタのカウント値（遊技玉数または遊技玉トータル個数情報とも言う）も受信している。ＣＵ３は、遊技玉を記憶する領域を以下の手順で更新する。すなわち、ＣＵ３は、Ｐ台側から送信されてきた加算玉数カウンタの値（加算玉数）、減算玉数カウンタの値（減算玉数）、および計数玉数カウンタの値に基づいて、記憶している遊技玉数を更新するとともに、同じタイミングでＰ台側から送信されてきた遊技玉数カウンタのカウント値と、更新後の遊技玉数とが一致しているか否かを判定する。一致していれば、遊技の続行を許容するが、一致していなければ、エラー状態に移行する制御を行なう。
その結果、たとえば、異常報知ランプや表示器３１２によりエラー報知が行なわれ、あるいは、ホール用管理コンピュータやホールサーバ８０１にエラーが発生した旨のエラー通知信号が送信される（この場合、ホール用管理コンピュータやホールサーバ８０１によるエラー報知が行なわれるようにしてもよい）。その結果、係員による人為的な対応を促す所定の報知が行なわれる。
なお、エラー状態に移行して遊技を停止させることに代えて、ＣＵ３側で記憶している遊技玉数をＰ台２側から送信されてきた遊技玉数カウンタのカウント値に置き換えるようにしてもよい。または、それに代えて、ＣＵ３側で管理している遊技玉数と、Ｐ台２側で記憶している遊技玉数との平均値に補正してもよい。
このように、本実施の形態では、ＣＵ３側にも遊技玉数を記憶させているが、その遊技玉数がＰ台２側で管理記憶している遊技玉数と整合するか否かの判定を行なえるようにしている（ＣＵ３側機能）。そのため、仮に不正行為その他の事情で、Ｐ台２側で記憶している遊技玉数がＣＵ３側で記憶している遊技玉数と一致しない状況が発生しても、その旨をチェックできる。なお、ここでは、ＣＵ３側にその判定機能を設けたが、たとえば、ＣＵ３と接続されるホールサーバ８０１またはホール用管理コンピュータによって、ＣＵ３側で記憶している遊技玉数とＰ台２側で記憶している遊技玉数とを受信し、両者が整合しているか否かの判定を行なうものとしてもよい。
図４に示すように、ＣＵ３は、カード持玉数、貯玉数を記憶する記憶領域と、受付けた（挿入された）カードのカード残額を記憶する記憶領域と、総加算玉数（加算玉数累計）、総減算玉数（減算玉数累計）およびカード挿入時持玉を記憶する記憶領域をさらに有する。ＣＵ制御部３２３（図２参照）は、貯玉の使用を要求する入力（たとえば、再プレイボタンの入力（ただし、持玉無しのとき））に応じて貯玉を記憶する記憶領域から所定数の貯玉を減算する。
ＣＵ制御部３２３（図２参照）は、持玉の使用を要求する入力（たとえば、持玉有のときの再プレイボタンの入力（ただし、持玉有のとき））に応じて持玉を記憶する記憶領域から所定数の持玉を減算する。さらに、ＣＵ制御部３２３（図２参照）は、カード残額の使用を要求する入力（たとえば、玉貸ボタンの入力）に応じてカード残額を記憶する記憶領域から所定値を減算する。
遊技者所有の遊技用価値（たとえばプリペイド残額、持玉数、あるいは貯玉数）から価値を引落として遊技に使用する操作を遊技者が行なった場合に、その引落とし分の玉数を遊技玉数カウンタに加算するための加算玉数がＣＵ３側からＰ台２側へ送信される。Ｐ台２側では、それを受けて、遊技玉数カウンタを加算更新する。
本実施の形態に係る遊技システムでは、一方、遊技者所有の遊技用価値を引落としてドリンク等に交換するといういわゆるワゴンサービスのオーダ等を受付けることが可能である。ただし、遊技玉でワゴンサービスを受けることが制限されており、持玉でしかワゴンサービスを受けることができない。これは、各台計数機が配備された旧来の封入式のパチンコ機において、皿に残っている計数前の玉を手で掴み出してワゴンサービスに用いることを禁止するようなイメージである。
このため、本実施の形態では、ワゴンサービスを行なう操作が実行されたときに、持玉数がワゴンサービスの希望メニューに対応する玉数に満たない場合、遊技者に計数操作を促すように構成されている。その際に遊技者が計数操作を実行すると、その操作に基づく計数玉数がＰ台２側からＣＵ３側へ送信される。ＣＵ３側では、それを受けて、遊技玉数を減算し、カード持玉数を加算して更新する。
＜通信で用いられるフレーム構成＞
次に、本実施の形態に係るＣＵ３とＰ台２との間での通信について、さらに詳しく説明する。当該通信で用いられる電文は、所定のフォーマットからなるフレームで構成されている。送信データ（電文）は、必ず１フレーム単位で送信される。つまり、電文の分割送信は行なわない。また、連続で電文を送信する場合は、１ミリ秒以上の間隔をあける。
次に、本実施の形態に係るＣＵ３とＰ台２との間での通信について、さらに詳しく説明する。当該通信で用いられる電文は、所定のフォーマットからなるフレームで構成されている。送信データ（電文）は、必ず１フレーム単位で送信される。つまり、電文の分割送信は行なわない。また、連続で電文を送信する場合は、１ミリ秒以上の間隔をあける。
１フレームの送信データは、データ長、通常通番、加算通番、計数通番、コマンド、データ部を含む。「データ長」は、送信データのデータ長（通番〜データ部（業務電文範囲））を示す。「コマンド」は、電文のコマンドコードである。「データ部」は、電文のデータである。
＜ＣＵとＰ台との間で送受信するコマンドおよびレスポンス＞
次に図５を参照して、ＣＵ３とＰ台２との間で送受信されるコマンドおよびレスポンスの概略を説明する。
次に図５を参照して、ＣＵ３とＰ台２との間で送受信されるコマンドおよびレスポンスの概略を説明する。
図５には、送信方向および送信されるデータがコマンドかレスポンスかの別と送信情報の名称とその概略が示されている。
＜＜１．リカバリ要求、２．リカバリ応答＞＞
まず、ＣＵ３からＰ台２に対してリカバリ要求という名称のコマンドが送信される。このリカバリ要求のコマンドは、Ｐ台２に対してリカバリ情報を要求するものである。このリカバリ要求に対応して、Ｐ台２からＣＵ３に対してリカバリ応答という名称のレスポンスが送信される。このリカバリ応答のレスポンスは、ＣＵ３に対してリカバリ情報を通知するものである。
まず、ＣＵ３からＰ台２に対してリカバリ要求という名称のコマンドが送信される。このリカバリ要求のコマンドは、Ｐ台２に対してリカバリ情報を要求するものである。このリカバリ要求に対応して、Ｐ台２からＣＵ３に対してリカバリ応答という名称のレスポンスが送信される。このリカバリ応答のレスポンスは、ＣＵ３に対してリカバリ情報を通知するものである。
リカバリ要求のコマンドは、ＣＵ３が認証を完了した後にＣＵ３からＰ台２に対して送信される。リカバリ要求のコマンドは、ＣＵ３からＰ台２に対してリカバリ情報を要求し、ＣＵ３が認証完了後、最初に同コマンドを送信する。リカバリ要求は、「通番」、「コマンド」、「前回最終送信通番」、「前回最終送信計数通番」、「店舗コード」および「ＳＣ基板ＩＤ」が含まれている。「通番」は、シーケンス番号（１〜２５５）である。「コマンド」は、状態情報要求のコマンドコードであり、１６進表現のバイナリデータで示してある。
「前回最終送信通番」は、前回接続時にＰ台２に対して最後に送信した状態情報要求のコマンドの通番である。「前回最終送信通番」が“０”の場合、記憶している通番が無い状態を示している。なお、「前回最終送信通番」は、Ｐ台２において状態情報応答を送信時に、ＣＵ３において状態情報応答受信時に「通番」をＰ台２、ＣＵ３側ともに前回最終送信通番（通番）として記憶する通番である。
「前回最終送信計数通番」は、前回接続時にＰ台２に対して最後に送信した状態情報要求のレスポンスの計数通番である。「前回最終送信計数通番」は、“０”の場合、記憶している通番が無い状態を示している。なお、「前回最終送信計数通番」は、Ｐ台２において状態情報応答を送信時に、ＣＵ３に状態情報応答受信時に計数通番をＰ台２、ＣＵ３側ともに前回最終送信計数通番として記憶する通番である。
Ｐ台２のリカバリ処理（計数玉数）において、セキュリティ基板３２５から通知された「店舗コード」および「ＳＣ基板ＩＤ」と、Ｐ台２で保持している「店舗コード」および「ＳＣ基板ＩＤ」との一致判定を行ない、一致している場合には以下の処理を行なう。不一致の場合には、計数前の遊技球数に戻す。
Ｐ台２はＣＵ３より通知された「前回最終送信計数通番」を参照して、ＣＵ３が計数要求に対する計数処理を実施していなかった場合は計数要求がなかったものとする。この場合、Ｐ台２は自らＣＵ３に通知した計数要求に対応する遊技玉の減算処理を実行しない。一方、Ｐ台２はＣＵ３より通知された「前回最終送信計数通番」を参照して、ＣＵ３が計数処理を実施済と判定したときには計数前の遊技玉数から計数玉数を減算して遊技玉を確定する。なお、Ｐ台２が保持している店舗コードが全て“０”または“１”の場合は、店舗コードが一致していると判定する。
リカバリ応答のレスポンスは、ＣＵ３に対してＰ台２で保持しているリカバリ情報を応答するものである。リカバリ情報は、「通番」、「コマンド」、「前回最終送信通番」、「前回挿入中カードＩＤ」、「前回カード挿入時刻」、「前回最終送信加算通番」、「遊技情報格納有無」、「前回遊技台情報」および「前回遊技情報」を含んでいる。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
「前回最終送信通番」は、前回接続時にＣＵ３に対して最後に送信した状態情報応答のレスポンスに含まれる通番のデータであり、“０”のときは保持している通番がない場合である。「前回挿入中カードＩＤ」は、前回接続時に挿入中だったカードのカードＩＤのデータであり、“０”のときは挿入中のカードがない場合である。Ｐ台２の払出制御部１７１は、ＣＵ３から送信される情報に基づいて挿入中であったカードＩＤを記憶保持している。
「前回カード挿入時刻」は、前回接続時に挿入中だったカードの挿入時刻のデータであり、“０”のときは挿入中のカードがない場合である。このデータも、年情報を２桁ＹＹ、月情報を２桁ＭＭ、日情報を２桁ＤＤ、時間情報を２桁ｈｈ、分情報を２桁ｍｍ、秒情報を２桁ｓｓで表されるデータである。「前回最終送信加算通番」は、前回接続時にＣＵ３に対して最後に送信した状態情報応答のレスポンスに含まれる加算通番であり、“０”のときは当該加算通番がない場合である。「遊技情報格納有無」は、遊技情報を格納していない場合“０ｘ００”、遊技情報を格納している場合“０ｘ０１”である。
「前回遊技台情報」は、ＣＵ３に前回通知した遊技台情報であり、「遊技玉数」、「発射玉数」、「アウト口通過玉数」、「総賞球玉数」、「計数玉数」および「計数通番」の情報を含んでいる。「遊技玉数」は、ＣＵ３に前回通知した遊技玉数である。「発射玉数」は、ＣＵ３に前回通知した発射玉数である。「アウト口通過玉数」は、ＣＵ３に前回通知したアウト口通過玉数である。「総賞球玉数」は、ＣＵ３に前回通知した総賞球玉数である。「計数玉数」は、ＣＵ３に前回通知した計数玉数である。「計数通番」は、ＣＵ３に前回通知した計数通番である。
「前回遊技情報」は、ＣＵ３に前回通知した遊技情報であり、「遊技情報数」、「種別情報１」〜「種別情報ｎ」、「賞球情報１」〜「賞球情報ｎ」の情報を含んでいる。「遊技情報数」は、ＣＵ３に前回通知した遊技情報の個数（０〜ｎ）である。なお、ｎ＝０〜２２で可変長である。「種別情報１」は、ＣＵ３に前回通知した遊技種別情報１である。「種別情報ｎ」は、ＣＵ３に前回通知した遊技種別情報ｎである。「賞球情報１」は、ＣＵ３に前回通知した遊技賞球情報１である。「賞球情報ｎ」は、ＣＵ３に前回通知した遊技賞球情報ｎである。
なお、「前回最終送信加算通番」は、ＣＵ３において状態情報要求を送信時、Ｐ台２において状態情報要求受信時に、ＣＵ３側、Ｐ台２ともに前回最終送信加算通番として記憶する通番である。
Ｐ台２のリカバリ処理（遊技情報）において、セキュリティ基板３２５から通知された「店舗コード」および「ＳＣ基板ＩＤ」と、Ｐ台２で保持している「店舗コード」および「ＳＣ基板ＩＤ」との一致判定を行ない、「店舗コード」が不一致の場合には、リカバリデータを無しとして処理する。一致している場合には以下の処理を行なう。
遊技情報のリカバリデータがある時は「遊技情報格納無」を格納無：０ｘ００にし、「前回遊技台情報」および「前回遊技情報」にＰ台２が保持しているリカバリデータをセットする。遊技情報のリカバリデータがない時または前回最終送信通番が０の時は「遊技情報格納有無」を格納無“０ｘ００”にし、「前回遊技台情報」および「前回遊技情報」をＡＬＬ“０”をセットする。なお、Ｐ台２が保持している店舗コードが全て“０”または“１”の場合は、店舗コードが一致していると判定する。
なお、また、ＣＵ３は、Ｐ台２より通知された「前回最終送信通番」の処理を実施していなかった場合、前回遊技台情報を使用してリカバリ処理を行なう。なお、「前回最終送信通番」の処理を実施している場合は、ＣＵ３は、前回遊技台情報のみ使用してリカバリ処理を行なう。ただし、計数玉数のリカバリは実施しない。
また、通信相手の不一致等（たとえばＣＵ３またはＰ台２の交換等）でリカバリ処理が実施できない場合、Ｐ台２の表示情報を元にＰＯＳで手補正することが考えられる。たとえば、Ｐ台２の表示情報は、可変表示装置２７８の液晶表示画面を利用して表示することが考えられる。あるいは、Ｐ台２に対して、払出制御部１７１が制御する表示器をさらに設けておき、その表示器に対して手補正のための情報を表示することも考えられる。なお、ＰＯＳとは、景品管理システムのことであり、景品交換や景品の管理を行なうものである。また、ＰＯＳは、景品交換や景品の管理を行なうものに限定されず、店舗で商品を販売するごとに商品の販売情報を記録し、集計結果を在庫管理やマーケティング材料として用いる一般的な販売時点管理（Point Of Sales system）であってもよい。
＜＜３．リカバリ要求２、４．リカバリ応答２＞＞
ＣＵ３からＰ台２に対してリカバリ要求２という名称のコマンドが送信される。このリカバリ要求２のコマンドは、Ｐ台２に対して加算リカバリ情報を通知するものである。このリカバリ要求２に対応して、Ｐ台２からＣＵ３に対してリカバリ応答２という名称のレスポンスが送信される。このリカバリ応答２のレスポンスは、ＣＵ３に対して加算リカバリ情報の処理結果を通知するものである。
ＣＵ３からＰ台２に対してリカバリ要求２という名称のコマンドが送信される。このリカバリ要求２のコマンドは、Ｐ台２に対して加算リカバリ情報を通知するものである。このリカバリ要求２に対応して、Ｐ台２からＣＵ３に対してリカバリ応答２という名称のレスポンスが送信される。このリカバリ応答２のレスポンスは、ＣＵ３に対して加算リカバリ情報の処理結果を通知するものである。
リカバリ要求２のコマンドは、Ｐ台２に対して加算リカバリ情報を通知するものであり、「通番」、「コマンド」、「前回最終送信加算通番」および「加算玉数」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。リカバリ要求２は、Ｐ台２において加算玉リカバリ処理を実施する必要有とＣＵ３が判定したときに送信される。ＣＵ３は、Ｐ台２より受信したリカバリ応答に含まれる「前回最終送信加算通番」と自身で記憶している「前回最終送信加算通番」とを比較して一致している場合には加算玉リカバリ処理の必要無と判定し、不一致の場合には加算玉リカバリ処理の必要有と判定する。加算玉リカバリ処理の必要有と判定したときにはリカバリ要求２を送信する。
リカバリ要求２に含まれる「前回最終送信加算通番」は、前回接続時にＰ台２に対して最後に送信した状態情報要求のコマンドの加算通番のデータであり、「加算玉数」は、遊技玉の加算玉数のデータである。
次に、Ｐ台２のリカバリ処理について詳しく説明する。Ｐ台２のリカバリ処理は、Ｐ台２がリカバリ要求２に基づいて、ＣＵ３より通知された「前回最終送信通番」の処理を実施していなかった場合、加算玉数を参照して遊技玉に対して加算を行なう処理である。
リカバリ応答２のレスポンスは、ＣＵ３に対してＰ台２で加算リカバリ情報の処理結果を通知するもので、「通番」、「コマンド」および「リカバリ結果」を含んでいる。「リカバリ結果」は、“０ｘ００”の場合リカバリ結果ＯＫ、“０ｘ０１”の場合リカバリ結果ＮＧである。なお、Ｐ台２が加算玉数を受けられない状態の場合はリカバリ結果として処理ＮＧを応答する。
＜＜５．通信開始要求、６．通信開始応答＞＞
ＣＵ３からＰ台２に対して通信開始要求のコマンドが送信される。この通信開始要求のコマンドは、Ｐ台２に対して通信開始を要求するものである。この通信開始要求に対応して、Ｐ台２からＣＵ３に対して通信開始応答のレスポンスが送信される。この通信開始応答のレスポンスは、ＣＵ３に対して通信開始を応答するものである。
ＣＵ３からＰ台２に対して通信開始要求のコマンドが送信される。この通信開始要求のコマンドは、Ｐ台２に対して通信開始を要求するものである。この通信開始要求に対応して、Ｐ台２からＣＵ３に対して通信開始応答のレスポンスが送信される。この通信開始応答のレスポンスは、ＣＵ３に対して通信開始を応答するものである。
通信開始要求のコマンドは、Ｐ台２に対して正常に通信開始したことを通知するものである。通信開始要求を受信したＰ台２は、それまで記憶していたリカバリ情報をクリアする。通信開始要求のコマンドは、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。なお、ＣＵ３は、通信開始要求後、計数通番を“０”（初期値）に、Ｐ台２も通信開始要求受信後、計数通番を“０”（初期値）にする。
通信開始応答のレスポンスは、ＣＵ３に対して、正常に通信開始したことを通知するものであり、ＣＵ３が、リカバリ情報をクリアする。通信開始応答のレスポンスは、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
＜＜７．通信終了要求、８．通信終了応答＞＞
ＣＵ３からＰ台２に対して通信終了要求のコマンドが送信される。この通信終了要求のコマンドは、Ｐ台２に対して通信終了を要求するものである。この通信終了要求に対応して、Ｐ台２からＣＵ３に対して通信終了応答のレスポンスが送信される。この通信終了応答のレスポンスは、ＣＵ３に対して通信終了を応答するものである。
ＣＵ３からＰ台２に対して通信終了要求のコマンドが送信される。この通信終了要求のコマンドは、Ｐ台２に対して通信終了を要求するものである。この通信終了要求に対応して、Ｐ台２からＣＵ３に対して通信終了応答のレスポンスが送信される。この通信終了応答のレスポンスは、ＣＵ３に対して通信終了を応答するものである。
通信終了要求のコマンドは、Ｐ台２に対して正常に通信終了したことを通知するものであり、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
通信終了応答のレスポンスは、ＣＵ３に対して、正常に通信終了したことを通知するものであり、ＣＵ３およびＰ台２が、該通知以降、通信を停止し再起動待ちとする。通信終了応答のレスポンスは、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
＜＜９．状態情報要求＞＞
ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信される。この状態情報要求のコマンドは、Ｐ台２に対してＣＵ３の状態を要求するものである。ＣＵ３はこのコマンドを使用して、Ｐ台２の状態を定期的に確認する。また、状態情報要求のコマンドには、図４に示したＣＵ３側からＰ台２側へ向かう加算玉数が含まれている。
ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信される。この状態情報要求のコマンドは、Ｐ台２に対してＣＵ３の状態を要求するものである。ＣＵ３はこのコマンドを使用して、Ｐ台２の状態を定期的に確認する。また、状態情報要求のコマンドには、図４に示したＣＵ３側からＰ台２側へ向かう加算玉数が含まれている。
この状態情報要求の具体的データには、「通番」、「コマンド」、「ＣＵ状態」、「加算玉数」、「加算通番」および「計数通番」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
「ＣＵ状態」は、Ｐ台２に対して通知するＣＵ３の状態を表わし、Ｂｉｔ０が“１”のときにカード挿入中を、“０”のときカード未挿入をそれぞれ示している。つまり、Ｂｉｔ０は、ＣＵ３にカード（一般カード／遊技場会員カード／共通会員カード）が挿入されている状態を表わしている。また、ＣＵ３のカードストック部に予めストックされているストックカード（一般０円０玉カード）への入金により一般カード挿入中となる。
Ｂｉｔ１が“１”のときカードユニット開店中を、“０”のときカードユニット閉店中をそれぞれ示している。つまり、Ｂｉｔ１は、ＣＵ３の状態により、Ｐ台２に対してカードユニット開店状態を通知する。カードユニット開店中を通知するタイミングは、たとえば、開店完了時である。カードユニット閉店中を通知するタイミングは、たとえば、閉店時である。なお、Ｐ台２は同状態が開店中から閉店中に変化時、保持している遊技玉を全て計数玉数として状態情報応答にてＣＵ３に通知する。
Ｂｉｔ２が“１”のときカード返却準備中を、“０”のときカード返却準備中以外をそれぞれ示している。ＣＵ３は、カード返却、簡易離席、および食事休憩のそれぞれの操作時に、このビットを立てることによって、Ｐ台２に対して「カード返却準備中」を一定時間（１０秒）通知する。Ｐ台２は、計数ボタン２８の操作が検出されたときに、このカード返却準備中のビットがオンの状態情報要求を受信していれば、計数ボタンを１回操作したか複数回操作したかに関わらず、あるいは操作継続時間に関わらず、記憶している遊技玉を全て計数玉数として状態情報応答にてＣＵ３に通知する。
Ｂｉｔ３が“１”のとき遊技玉加算要求を、“０”のとき遊技玉加算要求無をそれぞれ示している。つまり、Ｂｉｔ３は、玉貸、持玉払出、および貯玉払出の操作時に遊技玉の加算（加算玉数）を要求する。
Ｂｉｔ４が“１”のとき計数玉受領完了を、“０”は計数玉未受領をそれぞれ示している。Ｂｉｔ４は、計数玉受領時に受領完了したことをＰ台２に通知する。つまり、状態情報応答のレスポンス「計数玉数」の送達を確認するために用いている。
Ｂｉｔ５が“１”のときカード抜き取り待ち中を、“０”はカード抜き取り完了をそれぞれ示している。Ｂｉｔ５は、ＣＵ３からカード抜き取り待ちとなっている状態をＰ台２に通知する。なお、Ｂｉｔ６〜Ｂｉｔ７は未使用である。
「加算玉数」は、遊技玉の加算玉数であり、ＣＵ状態のＢｉｔ３が“１”のときにのみ加算玉数のデータが有効となる。「加算通番」は、加算用シーケンス番号（０〜２５５）であり、遊技玉加算要求時にシーケンス番号を更新（＋１）して通知する。「計数通番」は、計数用シーケンス番号（０〜２５５）であり、計数要求時に受信した計数通番をそのまま通知する。ただし、計数通番の連続性が成立しない場合は計数受領を出さない。
＜＜１０．状態情報応答＞＞
状態情報要求に対応して、Ｐ台２からＣＵ３に対して状態情報応答のレスポンスが送信される。この状態情報応答のレスポンスは、ＣＵ３に対してＰ台２の情報・状態を通知するものである。状態情報応答のレスポンスには、図４に示した最新遊技台情報や遊技玉数が含まれている。
状態情報要求に対応して、Ｐ台２からＣＵ３に対して状態情報応答のレスポンスが送信される。この状態情報応答のレスポンスは、ＣＵ３に対してＰ台２の情報・状態を通知するものである。状態情報応答のレスポンスには、図４に示した最新遊技台情報や遊技玉数が含まれている。
この状態情報要求の具体的データには、「通番」、「コマンド」、「遊技玉数」、「発射玉数」、「アウトロ通過玉数」、「総賞球玉数」、「計数要求玉数」、「計数通番」、「発射強度」、「遊技台状態」、「不正検知情報」および「遊技情報」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
「遊技玉数」は、現在の遊技玉数（加算・減算を演算した結果の遊技玉数）である。「遊技玉数」は、ＣＵ３が後述する「総賞球玉数」「発射玉数」および「計数玉数」を使用してＣＵ３の保持している遊技玉数を計算する。その後、ＣＵ３は、計算したＣＵ３の遊技玉数と、Ｐ台２の遊技玉数とが一致するかをチェックする。
「発射玉数」は、発射個数（送信時に複数発射された玉がある場合は合算する）である。ただし、バック玉数がある場合はバック玉数分を減算する。つまり、「発射玉数」（減算）は、ＣＵ３が保持している遊技玉数から減算するデータである。カードを保持してない状態で該データを受信した場合、ＣＵ３は遊技玉数の減算を行なわない。また、ＣＵ３は、ＣＵ３自体の保持している遊技玉数が０玉の場合、減算を行なわない。
「アウト口通過玉数」は、アウト口１５４を通過した玉の個数（送信時に複数の通過玉がある場合は合算する）である。
「総賞球玉数」は、賞球情報１−ｎの賞球玉数の合計である。この賞球情報１−ｎとは、たとえば始動口、大入賞口、入賞口（普通入賞口）等の入賞口種別毎の賞球玉数のことである。なお、「総賞球玉数」（加算）は、ＣＵ３より送信する「加算要求玉数」は含まない。また、ＣＵ３は保持している遊技玉数に総賞球玉数のデータを加算する。カードを保持していない状態で総賞球玉数のデータを受信した場合、ＣＵ３は遊技玉数の加算は行なわない。
「計数要求玉数」は、計数要求した遊技玉の個数である。つまり「計数玉数」（減算）は、ＣＵ３が保持している遊技玉数から減算し、カード持玉数に加算するデータである。なお、Ｐ台２からＣＵ３に送信する減算玉数のデータに計数玉数は利用しない。また、カードを保持してない状態で該データを受信した場合、ＣＵ３は遊技玉数の減算を行なわない。また、ＣＵ３は、ＣＵ３自体の保持している遊技玉数が０玉の場合、減算を行なわない。
ただし、カードユニット開店状態が開店中から閉店中に変化した場合は、遊技機が保持している遊技玉を計数して計数玉数として設定する。カードユニット開店状態が開店中のときには計数ボタン２８の操作が行なわれたことにより遊技玉を計数して計数玉数として設定する。しかし、カードユニット開店状態が開店中から閉店中に変化した場合は、計数ボタン２８の操作を待つことなく自動的に遊技玉を計数して計数玉数として設定する。
「計数通番」は、計数用シーケンス番号（０〜２５５）であり、計数要求時にシーケンス番号を更新（＋１）して通知する。
「発射強度」は、遊技玉の発射するための強度である。
「遊技台状態」は、ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信された時点の、Ｐ台２の状態を示し、「遊技台状態１」、「遊技台状態２」、「遊技台状態３」、および「遊技台エラー状態」の情報を含んでいる。
「遊技台状態」は、ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信された時点の、Ｐ台２の状態を示し、「遊技台状態１」、「遊技台状態２」、「遊技台状態３」、および「遊技台エラー状態」の情報を含んでいる。
「遊技台状態１」のＢｉｔ０は、遊技を許可しているか、禁止しているかを示しており、“０”のときに遊技許可中であり、“１”のとき遊技禁止中である。Ｂｉｔ１は、ファン（遊技者）がプレイ中（玉を発射している）か否かを示しており、０”のとき待機中（ファンが球を発射してない状態）、“１”のとき遊技中（ファンが球を発射している状態）である。ただし、遊技玉が有り、発射ハンドル（打球操作ハンドル２５）をタッチした状態（タッチセンサに触れた状態）で遊技中となる。
Ｂｉｔ２は、遊技玉の有無（遊技玉無の検知）を示している。“０”のとき遊技玉数有、“１”のとき遊技玉数無である。Ｂｉｔ３は、玉の発射が停止している状態で、全ての発射した玉の行方が確定しているか否かを示している。つまり、遊技領域２７内の浮遊玉が全て回収されたか否か示している。ただし、発射停止スイッチ（単発打ちスイッチとも言う）による玉の発射停止は除く。“０”のとき遊技未完了（全ての玉の行方が未確定の状態）、“１”のとき遊技完了（全ての玉の行方が確定している状態）である。なお、Ｐ台２は、玉の発射を停止してから１５秒以上遊技の完了を確認できなかった場合、タイムアウトし、遊技完了とする。
Ｂｉｔ４は、遊技玉の計数要求の有無（計数ボタン押下の有無）を示しており、“０”のとき要求無、“１”のとき計数開始時の計数玉の払出要求がある場合である。Ｐ台は、計数操作が検出されたときに、この計数要求ＯＮの状態情報応答をＣＵ３へ送信し、計数要求が受領されたか否かを確認する。“１”のとき計数要求である。Ｂｉｔ５は、遊技玉加算の処理結果を示しており、“０”のとき加算ＯＫ、“１”のとき加算ＮＧである。Ｂｉｔ６〜Ｂｉｔ７は予備である。
「遊技台状態２」のＢｉｔ０は、大当り情報の大当り１（全ての大当り）を表わし、全ての大当り中“１”をセットする。Ｂｉｔ１は、大当り情報の大当り２（大当り＋小当り）を表わし、全ての大当り中および小当り中“１”をセットする。Ｂｉｔ２は、大当り情報の大当り３（出玉大の大当り）を表わし、出玉が大きい大当り中“１”をセットする。Ｂｉｔ３は、大当り情報の大当り４（出玉小の大当り）を表わし、出玉が小さい大当り中“１”をセットする。Ｂｉｔ４は、大当り情報の大当り５（出玉中の大当り）を表わし、出玉が中間の大当り中“１”をセットする。Ｂｉｔ５〜Ｂｉｔ７は予備である。
「遊技台状態３」のＢｉｔ０は、遊技状態情報の大当り中＋時短中を表わし、大当り中および時短中“１”をセットする。Ｂｉｔ１は、遊技状態情報の確変中を表わし、確変中“１”をセットする。Ｂｉｔ２は、遊技状態情報の時短中を表わし、時短中“１”をセットする。Ｂｉｔ３は、遊技状態情報の変動中を表わし、変動中“１”をセットする。Ｂｉｔ４〜Ｂｉｔ７は予備である。
「遊技台エラー状態」は、Ｐ台２で発生中のエラーコードを示し、Ｂｉｔ０〜Ｂｉｔ５を用いて各エラーコードを表現している。なお、Ｂｉｔ０〜Ｂｉｔ５が全て“０”のときにはエラー無である。Ｂｉｔ６は、エラーが発生している場所を特定する情報であり、“０”のとき払出制御、“１”のとき主制御をそれぞれ表わしている。Ｂｉｔ７は、エラーの出力方法を示し、“０”のとき発報のみ、“１”のとき発報＋ホールサーバ８０１への出力を表わしている。
「不正検知情報」は、ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信された時点の、Ｐ台２で検知した情報であり、「不正検知状態１」、「不正検知状態２」、「不正検知情報１」〜「不正検知情報４」および「加算通番」の情報を含んでいる。
「不正検知状態１」は、主制御基板１６の不正検知情報である。「不正検知状態１」のＢｉｔ０は、“１”のとき電波センサ検知の不正検知情報であることを表わしている。Ｂｉｔ１は、“１”のとき磁気センサ検知不の正検知情報であることを表わしている。Ｂｉｔ２は、“１”のとき不正入賞検知の不正検知情報であることを表わしている。Ｂｉｔ３〜Ｂｉｔ７は予備である。
「不正検知状態２」は、払出制御基板１７の不正検知情報である。「不正検知状態２」のＢｉｔ０は、“１”のときガラス板開放の不正検知情報であることを表わしている。Ｂｉｔ１は、“１”のとき枠本体開放の不正検知情報であることを表わしている。Ｂｉｔ２は、“１”のとき電波センサ検知の不正検知情報であることを表わしている。Ｂｉｔ３は、“１”のとき近接センサ異常の不正検知情報であることを表わしている。Ｂｉｔ４は、“１”のとき賞球ゴト検知の不正検知情報であることを表わしている。ここで、「ゴト」とは、パチンコやスロットマシンにおいて不正な方法で出玉を獲得する不正行為のことである。Ｂｉｔ５は、“１”のとき複合ゴト検知の不正検知情報であることを表わしている。Ｂｉｔ６は、“１”のとき不正加算検知の不正検知情報であることを表わしている。Ｂｉｔ７は、“１”のとき夜間枠開放・監視ＳＷ異常検知の不正検知情報であることを表わしている。
「不正検知情報１」は、賞球センサゴト検知（入賞不整合玉数）の情報を示すデータである。「不正検知情報１」は、「不正検知状態２」のＢｉｔ４が“１”のとき有効となる。「不正検知情報２」は、複合センサゴト検知（発射／ＯＵＴ不整合玉数）の情報を示すデータである。つまり、発射玉数とアウト玉数（アウト口通過玉数）との不整合を検知したときの情報を示すデータである。「不正検知情報２」は、「不正検知状態２」のＢｉｔ５が“１”のとき有効となる。「不正検知情報３」は、不正加算検知（不正加算玉数）の情報を示すデータである。「不正検知情報３」は、「不正検知状態２」のＢｉｔ６が“１”のとき有効となる。「不正検知情報４」は、夜間枠開放情報を示すデータである。「不正検知情報４」は、「不正検知状態２」のＢｉｔ７が“１”のとき有効となる。
「不正検知情報４」のＢｉｔ７は、夜間監視スイッチ異常４が発生しているかを示す情報で、“０”のとき正常、“１”のとき異常４発生を表わしている。Ｂｉｔ６は、夜間監視スイッチ異常３が発生しているかを示す情報で、“０”のとき正常、“１”のとき異常３発生を表わしている。Ｂｉｔ５は、夜間監視スイッチ異常２が発生しているかを示す情報で、“０”のとき正常、“１”のとき異常２発生を表わしている。Ｂｉｔ４は、夜間監視スイッチ異常１が発生しているかを示す情報で、“０”のとき正常、“１”のとき異常１発生を表わしている。Ｂｉｔ０〜３は、本体枠開放回数を示す情報で、“０”のとき開放なし、“１”〜“１５”は開放回数を表わしている。なお、開放回数は、１５回までカウントし、１６回以降のカウントは１５回でホールドされる。
「加算通番」は、加算用シーケンス番号であり、加算要求時に受信した加算通番をそのまま通知する。ただし、加算通番の連続性が成立しない場合は無応答となる。
「不正検知状態３」は、払出制御基板１７の不正検知情報である。「不正検知状態３」のＢｉｔ０は、“１”のとき他店舗遊技玉検知の不正検知情報であることを表わしている。Ｂｉｔ１〜Ｂｉｔ７は予備である。なお、他店舗遊技玉検知は、たとえばＰ台の回収玉通過経路にセンサが設けてあり、当該センサが遊技玉に設けてある識別情報（表面の刻印など）を読取り、自店舗の遊技玉の識別情報と一致するか否かを判定する。不一致の場合、遊技玉に他店舗の遊技玉が混入しているとして「不正検知状態３」のＢｉｔ０を“１”にして、ＣＵ３に通知する。
「遊技情報」は、ＣＵ３からＰ台２に対して状態情報要求のコマンドが送信された時点の、Ｐ台２の情報であり、「遊技情報数」、「種別情報１」〜「種別情報ｎ」、「賞球情報１」〜「賞球情報ｎ」を含んでいる。
「遊技情報数」は、種別情報・賞球情報の個数（ｎ）であり、ｎ＝０〜２２（可変長）である。種別情報は、Ｂｉｔ４からＢｉｔ７までがデータ種別の情報で、遊技情報のデータ種別を示しており、“０”のとき情報無、“１”のとき始動口、“２”のとき大入賞口、“３”のとき入賞口、“４”のとき図柄停止回数である。Ｂｉｔ０からＢｉｔ３までがデータ番号の情報で、遊技情報のデータ種別毎のデータ番号を示しており、“０”のとき情報無、“１”〜“１５”のときそれぞれのデータ番号を表わしている。
「種別情報１」〜「種別情報ｎ」は、遊技種別情報１〜遊技種別情報ｎをそれぞれ示し、「賞球情報１」〜「賞球情報ｎ」は、遊技賞球情報１〜遊技賞球情報ｎをそれぞれ示している。
ここで、賞球情報は、Ｂｉｔ０からＢｉｔ３までが賞球玉数の情報で、遊技情報のデータ種別毎に入賞時の賞球玉数を示しており、“０”のとき情報無、“１”〜“１５”のとき賞球玉数のデータをそれぞれ表わしている。Ｂｉｔ４からＢｉｔ７までが入賞個数の情報で、遊技情報のデータ種別毎に入賞個数（累計）を示しており、“０”のとき情報無、“１”〜“１５”のとき入賞個数のデータをそれぞれ表わしている。
＜＜１１．カード挿入通知、１２．カード挿入応答＞＞
ＣＵ３からＰ台２に対してカード挿入通知のコマンドが送信される。このカード挿入通知のコマンドは、Ｐ台２に対してカード挿入を通知するものである。このカード挿入通知に対応して、Ｐ台２からＣＵ３に対してカード挿入応答のレスポンスが送信される。このカード挿入応答のレスポンスは、ＣＵ３に対してカード挿入通知を受信した旨の応答である。
ＣＵ３からＰ台２に対してカード挿入通知のコマンドが送信される。このカード挿入通知のコマンドは、Ｐ台２に対してカード挿入を通知するものである。このカード挿入通知に対応して、Ｐ台２からＣＵ３に対してカード挿入応答のレスポンスが送信される。このカード挿入応答のレスポンスは、ＣＵ３に対してカード挿入通知を受信した旨の応答である。
カード挿入通知のコマンドは、カード挿入時に、Ｐ台２に対して挿入されたカードのカードＩＤと挿入時刻を通知し、「通番」、「コマンド」、「カードＩＤ」、「カード挿入時刻」、「店舗コード」および「ＳＣ基板ＩＤ」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
「カードＩＤ」は、ＣＵ３に挿入されたＩＣカードの識別ＩＤ情報であり、Ｐ台２が保持している遊技玉との紐付に使用する。「カード挿入時刻」は、ＣＵ３のカード挿入／排出口３０９（図１参照）にＩＣカードが挿入された時刻であり、年情報を２桁ＹＹ、月情報を２桁ＭＭ、日情報を２桁ＤＤ、時間情報を２桁ｈｈ、分情報を２桁ｍｍ、秒情報を２桁ｓｓで表されるデータである。カード挿入時刻は、Ｐ台２保持の遊技玉が当日玉か過去玉かの判断に使用する。
「店舗コード」は、ＣＵ３が設置されている店舗識別コードであり、Ｐ台２が保持している遊技玉との紐付に使用する。また、ＣＵ３が店舗移動されたか否かを判定するためにも使用する。ＣＵ３は、自らが設置されている店舗コードを記憶している。なお、店舗コードは、セキュリティ基板３２５より情報付加してＰ台に通知する。「ＳＣ基板ＩＤ」は、ＣＵ３を識別するためのＳＣ基板ＩＤであり、ＣＵ３が交換されたか否かを判定するために使用する。ＳＣ基板ＩＤは、セキュリティ基板３２５より情報付加してＰ台２に通知する。Ｐ台２の払出制御部１７１は、これらのカードＩＤ（Ｃ-ＩＤ）やカード挿入時刻等のカード挿入通知コマンドで通知される情報を記憶する。
カード挿入応答のレスポンスは、ＣＵ３に対して正常にカード挿入通知を受信したことを通知するもので、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
＜＜１３．カード返却通知、１４．カード返却応答＞＞
ＣＵ３からＰ台２に対してカード返却通知のコマンドが送信される。このカード返却通知のコマンドは、Ｐ台２に対してカード返却を通知するものである。このカード返却通知に対応して、Ｐ台２からＣＵ３に対してカード返却応答のレスポンスが送信される。このカード返却応答のレスポンスは、ＣＵ３に対してカード返却を応答するものである。
ＣＵ３からＰ台２に対してカード返却通知のコマンドが送信される。このカード返却通知のコマンドは、Ｐ台２に対してカード返却を通知するものである。このカード返却通知に対応して、Ｐ台２からＣＵ３に対してカード返却応答のレスポンスが送信される。このカード返却応答のレスポンスは、ＣＵ３に対してカード返却を応答するものである。
カード返却通知のコマンドは、Ｐ台２に対してカード返却を通知するもので、ＣＵ３が、「カード返却」ボタン押下時に同通知を送信する。カード返却通知には、「通番」、「コマンド」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。
カード返却応答のレスポンスは、ＣＵ３に対してカード返却通知の応答を送信するもので、「通番」、「コマンド」、「カードＩＤ」、「カード挿入時刻」のデータが含まれている。「通番」、「コマンド」、「カードＩＤ」および「カード挿入時刻」は、前述と同じであるので説明を繰返さない。なお、ＣＵ３は、カード返却応答の際、コマンドに含まれるカードＩＤと現在挿入中のカードのＩＤとが一致しない場合や、コマンドに含まれるカード挿入時刻に問題がある場合、カード返却を行なわない、持玉のカードへの書込みを禁止するなどの処理を行なう。
ここで、カード挿入通知時またはカード返却通知時のＰ台２の動作について説明する。カード挿入通知時に、ＣＵ３で遊技場会員カード／共通会員カード挿入、一般カード挿入、または一般０円０玉カードへの入金の操作を行なうと、Ｐ台２はカードＩＤおよびカード挿入時刻のバックアップを行なう。カード返却通知時に、ＣＵ３で「カード返却」ボタンの押下の操作を行なうと、Ｐ台２はカードＩＤおよびカード挿入時刻のクリアを行なう。
＜＜１５．通信テスト要求、１６．通信テスト応答＞＞
ＣＵ３からＰ台２に対して、通信テスト要求のコマンドが送信される。この通信テスト要求のコマンドは、Ｐ台２に対してテストデータを通知するものである。この通信テスト要求に対応して、Ｐ台２からＣＵ３に対して、通信テスト応答のレスポンスが送信される。このカード返却応答のレスポンスは、ＣＵ３に対してテストデータを応答するものである。
ＣＵ３からＰ台２に対して、通信テスト要求のコマンドが送信される。この通信テスト要求のコマンドは、Ｐ台２に対してテストデータを通知するものである。この通信テスト要求に対応して、Ｐ台２からＣＵ３に対して、通信テスト応答のレスポンスが送信される。このカード返却応答のレスポンスは、ＣＵ３に対してテストデータを応答するものである。
通信テスト要求のコマンドは、Ｐ台２に対してテストデータを通知するものである。なお、Ｐ台２に対して通知するテストデータは暗号化していない。通信テスト要求のコマンドは、「通番」、「コマンド」、および「テストデータ」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。「テストデータ」は、Ｐ台２に対して通知するテスト用のデータで任意のデータである。
通信テスト応答のレスポンスは、ＣＵ３に対してテストデータを通知するものである。なお、ＣＵ３に対して通知するテストデータも暗号化していない。通信テスト応答のレスポンスは、「通番」、「コマンド」、および「テストデータ」のデータが含まれている。「通番」および「コマンド」は、前述と同じであるので説明を繰返さない。「テストデータ」は、ＣＵ３に対して通知するテスト用のデータで任意のデータである。
＜ＣＵとＰ台との通信における主なシーケンス＞
＜＜コマンド、レスポンスの送信＞＞
まず、ＣＵ３とＰ台２との間でのコマンドおよびレスポンスの送信について説明する。ＣＵ３（１次局）からＰ台２（２次局）に対してコマンドが送信され、Ｐ台２はそのコマンドに応答してレスポンスをＣＵ３に返信する。つまり、業務電文の送信は、ＣＵ３を１次局、Ｐ台２を２次局としたコマンド／レスポンス方式である。
＜＜コマンド、レスポンスの送信＞＞
まず、ＣＵ３とＰ台２との間でのコマンドおよびレスポンスの送信について説明する。ＣＵ３（１次局）からＰ台２（２次局）に対してコマンドが送信され、Ｐ台２はそのコマンドに応答してレスポンスをＣＵ３に返信する。つまり、業務電文の送信は、ＣＵ３を１次局、Ｐ台２を２次局としたコマンド／レスポンス方式である。
ＣＵ３からＰ台２への最初のコマンドの送信から次のコマンドの送信までの期間が、２００ｍｓすなわち０．２秒に制御される。またＰ台２からＣＵ３へのレスポンスの送信を行なった後次のレスポンスの送信までの期間が２００ｍｓすなわち０．２秒に制御される。
このように、ＣＵ３とＰ台２との間で２００ｍｓの間隔でコマンドおよびレスポンスの双方が送信される。一方、Ｐ台２は、打球操作ハンドル２５を操作することによって、１分間に１００発のパチンコ玉が遊技領域２７内に打込まれるから、打球発射時間間隔は、０．６秒である。その結果、玉を１発発射する間に複数のコマンドおよびレスポンスが送受信されることになる。
それゆえ、Ｐ台２からＣＵ３へは、遊技玉数の変化量を通知するためのレスポンスが玉の発射時間間隔よりも短い間隔で次々と送信されることになる。その結果、Ｐ台２は、遊技玉数の変化量を細やかにＣＵ３に対して通知可能となる。
なお、ここでは、コマンドおよびレスポンスの送信間隔を２００ｍｓにしたが、送信間隔をこれよりも長い間隔としても、また、より短い間隔としてもよく、たとえば、その送信間隔をＰ台２の発射時間間隔と一致させることも考えられる。
＜＜ＣＵ側の通信回線断検知＞＞
次に、ＣＵ３側で通信断が検知された場合の処理について説明する。ＣＵ３がＰ台２に対してコマンドを送信してから２００ｍｓ間にレスポンスを受信できなかった場合、再度同じコマンドをＰ台２に送信する。さらにその２００ｍｓ後までの間にレスポンスを受信できなかった場合には、同じコマンドをＰ台２に送信するという２回目の再送を行なう。同じコマンドを最大１４回までＰ台２に再送する。１４回目の再送を行なってもＰ台２からレスポンスを受信できなかった場合、ＣＵ３は３秒後に通信異常と判断して「通信断」とする。この通信異常は、ＣＵ３のコネクタとＰ台２のコネクタとが離脱している場合あるいは接続配線の断線さらにはＰ台２の電源断などの原因が考えられる。ＣＵ３は、コマンドの再送時に通番のカウントアップを行なわない。
次に、ＣＵ３側で通信断が検知された場合の処理について説明する。ＣＵ３がＰ台２に対してコマンドを送信してから２００ｍｓ間にレスポンスを受信できなかった場合、再度同じコマンドをＰ台２に送信する。さらにその２００ｍｓ後までの間にレスポンスを受信できなかった場合には、同じコマンドをＰ台２に送信するという２回目の再送を行なう。同じコマンドを最大１４回までＰ台２に再送する。１４回目の再送を行なってもＰ台２からレスポンスを受信できなかった場合、ＣＵ３は３秒後に通信異常と判断して「通信断」とする。この通信異常は、ＣＵ３のコネクタとＰ台２のコネクタとが離脱している場合あるいは接続配線の断線さらにはＰ台２の電源断などの原因が考えられる。ＣＵ３は、コマンドの再送時に通番のカウントアップを行なわない。
＜＜Ｐ台側の通信回線断検知＞＞
Ｐ台２側で通信断を検知した場合の処理について説明する。ＣＵ３からＰ台２へコマンドが送信され、Ｐ台２ではそのコマンドに応答してレスポンスをＣＵ３に返信する。その後ＣＵ３からのコマンドがＰ台２に送信されてこない状態が３秒間継続した場合、Ｐ台２は通信断と判断し、発射モータ１８の駆動を停止させて遊技を停止する。この通信断の発生原因も、ＣＵ３のコネクタとＰ台２のコネクタとの離脱、接続配線の断線、あるいはＣＵ３の電源断などが考えられる。
Ｐ台２側で通信断を検知した場合の処理について説明する。ＣＵ３からＰ台２へコマンドが送信され、Ｐ台２ではそのコマンドに応答してレスポンスをＣＵ３に返信する。その後ＣＵ３からのコマンドがＰ台２に送信されてこない状態が３秒間継続した場合、Ｐ台２は通信断と判断し、発射モータ１８の駆動を停止させて遊技を停止する。この通信断の発生原因も、ＣＵ３のコネクタとＰ台２のコネクタとの離脱、接続配線の断線、あるいはＣＵ３の電源断などが考えられる。
なお、Ｐ台２側で通信断を検知するコマンド、レスポンスには、リカバリ要求／リカバリ応答、リカバリ要求２／リカバリ応答２、通信開始要求／通信開始応答、通知終了要求／通信終了応答、および通信テスト要求／通信テスト応答のコマンド、レスポンスを含まない。
＜＜電源投入＞＞
次に、電源投入時の接続シーケンスの処理について説明する。図６に示すシーケンス処理は、ＣＵ３とＰ台２との通信が正常に終了した後の通信再開時に実行される処理である。具体的には、カードが挿入されていない待機中において、ＣＵ３の電源をＯＦＦにした後の通信再開時に実行される。典型例は、遊技場において１日の営業が終了して電源を立下げ、翌日営業開始時に電源を立上げる場合である。
次に、電源投入時の接続シーケンスの処理について説明する。図６に示すシーケンス処理は、ＣＵ３とＰ台２との通信が正常に終了した後の通信再開時に実行される処理である。具体的には、カードが挿入されていない待機中において、ＣＵ３の電源をＯＦＦにした後の通信再開時に実行される。典型例は、遊技場において１日の営業が終了して電源を立下げ、翌日営業開始時に電源を立上げる場合である。
まず、電源を投入する。電源投入時においては、Ｐ台２では発射モータ１８を停止させて遊技を停止させてから通信を開始する。その後、認証シーケンスが開始され、Ｐ台２からＣＵ３に対して、メインチップＩＤと払出チップＩＤとが含まれる情報が送信される。ＣＵ３は、受信したメインチップＩＤと払出チップＩＤとを上位の管理サーバへ送信してメインチップＩＤと払出チップＩＤとが正規に登録されているか否か照会してもらいその結果を返信してもらう。正規に登録されていれば適正な認証結果となる。
認証シーケンス後、ＣＵ３は、前回最終送信通番および前回最終送信計数通番を含むリカバリ要求をＰ台２へ送信し、Ｐ台２に対してリカバリ情報を要求する。Ｐ台２は、ＣＵ３より通知された前回最終送信計数通番を参照して、計数リカバリ処理を実行する。具体的に、Ｐ台２は、前回最終送信計数通番を参照して、ＣＵ３が計数処理を実施していなかった場合、計数要求をなかったものとし、ＣＵ３が計数処理を実施済の場合、計数前の遊技玉数から計数玉数を減算して遊技玉を確定する。
計数リカバリ処理の実行後、Ｐ台２は、Ｐ台２内部（具体的には払出制御基板１７）でバックアップしている遊技情報リカバリデータをレスポンスとしてＣＵ３へ返信する（リカバリ応答）。リカバリ情報としては、前回最終送信通番、前回挿入中カードＩＤ、前回カード挿入時刻、前回最終送信加算通番および前回遊技台情報などが含まれている。
リカバリ応答を受けたＣＵ３では、リカバリ情報に含まれる前回最終送信加算通番の処理を実行していなかった場合、リカバリ情報に含まれる前回遊技台情報を使用してＣＵ３の加算リカバリ処理を実施する。ＣＵ３は、加算玉リカバリ処理を実施する場合、Ｐ台２に対して、リカバリ要求２をＰ台２へ送信し、Ｐ台２に対してリカバリデータを送信する。このリカバリデータには、前回最終送信通番、および加算玉数が含まれている。
それを受けたＰ台２では、受信したリカバリデータに基づいて加算リカバリ処理を実行し、その結果をレスポンスとしてＣＵ３へ返信する（リカバリ応答２）。なお、Ｐ台２が加算玉数を受けられない状態の場合はリカバリ結果としてリカバリ処理ＮＧを応答する。
このリカバリ処理は、ＣＵ３とＰ台２との間での互いのデータの整合性を回復するための処理であり、電源起動時に実行されるばかりでなく、トラブルが発生し復旧したときにも、実行される。
ＣＵ３は、リカバリ要求などのコマンドを送信する度に通番をカウントアップする。ただし、コマンドの再送時の際にはカウントアップしない。Ｐ台２は、前回受信した通番と同じ通番のコマンドを受信した場合には、通信不良が発生してＣＵ３がコマンドを再送したと判断する。ＣＵ３はコマンドの送信し、同じ通番のレスポンスがＰ台２から通知された時に通番をバックアップする。Ｐ台２は、受信したコマンドに対応するレスポンスを送信する際に、受信した通番をそのままＣＵ３に通知する。Ｐ台２はレスポンスの送信時に通番をバックアップする。
ＣＵ３は、認証シーケンスが終了した後、通番を“１”としてリカバリ要求のコマンドをＰ台２に送信する。Ｐ台２は、受信した通番“１”をそのままリカバリ応答のレスポンスとしてＣＵ３に返信する。さらに、ＣＵ３は、通番を“２”としてリカバリ要求２のコマンドをＰ台２に送信する。Ｐ台２は、受信した通番“２”をそのままリカバリ応答２のレスポンスをＣＵ３に返信する。
その後、ＣＵ３は、通番をカウントアップして“３”として、通信開始要求のコマンドをＰ台２へ送信する。なお、ＣＵ３は、リカバリ要求２を送信しなかった場合、通番は１カウントダウン（−１）した“２”となる。Ｐ台２では、それを受けて、リカバリデータをクリアする。そして、Ｐ台２は、受信した通番“３”のまま、通信開始応答のレスポンスをＣＵ３へ返信する。これ以降、ＣＵ３とＰ台２との間で、状態情報要求のコマンドと状態情報応答のレスポンスとの送受信が行なわれる。
ＣＵ３は、通番をカウントアップして“４”として、状態情報要求のコマンドをＰ台２へ送信する。Ｐ台２は、それを受けて、遊技台情報、遊技情報および前回最終送信通番を更新し、更新したデータを状態情報応答のレスポンスの送信毎にバックアップする。そして、Ｐ台２は、受信した通番“４”のまま、状態情報応答のレスポンスをＣＵ３に返信する。
ＣＵ３は、それを受けて、前回最終送信通番を更新し、更新したデータを状態情報応答のレスポンスの受信毎にバックアップする。
その後、ＣＵ３は、通番をカウントアップして“５”として、状態情報要求のコマンドをＰ台２へ送信し、Ｐ台２は、受信した通番“５”のまま、状態情報応答のレスポンスをＣＵ３に返信する。
＜＜カード挿入＞＞
カードが挿入されたときのＣＵ３およびＰ台２の処理について説明する。図７に示すＣＵ３は、カード挿入前、通番＝ｎ、カード返却準備状態＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。Ｐ台２では、それを受けて、通番＝ｎ、遊技禁止を含む状態情報応答のレスポンスをＣＵ３に返信する。
カードが挿入されたときのＣＵ３およびＰ台２の処理について説明する。図７に示すＣＵ３は、カード挿入前、通番＝ｎ、カード返却準備状態＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。Ｐ台２では、それを受けて、通番＝ｎ、遊技禁止を含む状態情報応答のレスポンスをＣＵ３に返信する。
その後、ＣＵ３では、カードが挿入されると、カードリーダライタにカードを取込む指令信号を出力するとともに、取込んだカードに記録されている情報（カードＩＤ等）をカードリーダライタが読取って、その読取り情報を受信する等の、カード挿入時処理が実行される。
ＣＵ３は、カードの挿入が行なわれた後の所定期間、カード情報問合せ中の状態になる。これは、挿入されたカードの適否や当該遊技場で登録されている遊技場会員カード／共通会員カードであるか否か、あるいは持玉、貯玉やカード残額等をたとえばホールサーバ８０１に問合せて認証している最中であることを表示器３１２に表示するとともにＰ台２側の表示器５４に表示させる処理を実行している最中であることを意味している。
ＣＵ３は、表示器３１２に挿入されたカードの問合せ中であることを表示している間、挿入されたカードを認証していないので、通番＝ｎ＋１、カード返却準備状態＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。Ｐ台２では、それを受けて、通番＝ｎ＋１、遊技禁止を含む状態情報応答のレスポンスをＣＵ３に返信する。なお、Ｐ台２側の表示器５４は、ＣＵ３の表示制御部３５０により表示制御が行なわれ、カードの問合せ中である旨の表示がなされる。
その後、ＣＵ３は、挿入されたカードが認証されると、そのカードのカードＩＤとカード挿入時刻とをＣＵ制御部３２３のＲＡＭに記憶させるとともに、通番＝ｎ＋２、カードＩＤ、カード挿入時刻、店舗コードおよびＳＣ基板ＩＤを含むカード挿入通知のコマンドをＰ台２へ送信する。なお、店舗コードおよびＳＣ基板ＩＤは、カード挿入通知のコマンドがセキュリティ基板３２５を通過するときに当該コマンドに付加される情報である。Ｐ台２では、それを受けて、受信したカードＩＤ、カード挿入時刻、店舗コードおよびＳＣ基板ＩＤのデータを払出制御部１７１のＲＡＭ等にバックアップするとともに、通番＝ｎ＋２を含むカード挿入応答のレスポンスをＣＵ３に返信する。なお、ＣＵ３においても、挿入されたカードのカードＩＤをＣＵ制御部３２３のＲＡＭ等に記憶する。
ＣＵ３は、それを受けて、通番＝ｎ＋３、カード返却準備状態＝ＯＮを含む状態情報要求のコマンドをＰ台２へ送信することで、カード挿入中である状態をＰ台２に対して通知する。Ｐ台２は、カード挿入中である状態の通知を受けて遊技を許可し、通番＝ｎ＋３、遊技許可を含む状態情報応答のレスポンスをＣＵ３に返信することで、遊技許可中である状態をＣＵ３に対して通知する。
カード挿入中、ＣＵ３は、通番＝ｎ＋４、カード返却準備状態＝ＯＮを含む状態情報要求のコマンドをＰ台２へ送信し、Ｐ台２は、通番＝ｎ＋４、遊技許可を含む状態情報応答のレスポンスをＣＵ３に返信する。
＜＜プリペイド貸出＞＞
次に、挿入されたカードのプリペイド残額から遊技玉を貸出すときの処理について説明する。図８に示すシーケンス処理では、挿入されたカードに記録されているプリペイド残額が５００円で、遊技玉数が５０玉である。まず、ＣＵ３は、通番＝ｎ、遊技玉加算要求＝ＯＦＦ、加算通番＝ｍを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝５０、加算通番＝ｍを含む状態情報応答のレスポンスをＣＵ３に返信する。このように、加算要求が発生していない間は、加算通番が更新されることはない。
次に、挿入されたカードのプリペイド残額から遊技玉を貸出すときの処理について説明する。図８に示すシーケンス処理では、挿入されたカードに記録されているプリペイド残額が５００円で、遊技玉数が５０玉である。まず、ＣＵ３は、通番＝ｎ、遊技玉加算要求＝ＯＦＦ、加算通番＝ｍを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝５０、加算通番＝ｍを含む状態情報応答のレスポンスをＣＵ３に返信する。このように、加算要求が発生していない間は、加算通番が更新されることはない。
その後、遊技者が１回「貸出」ボタンを押下する貸出操作（玉貸操作）を行なうことにより、ＣＵ３は、残額の５００円分すなわち１２５玉の貸出を行なう。ＣＵ３は、表示器５４または表示器３１２に表示された玉貸ボタン（貸出ボタン）が操作された場合（ステップＳ３０１）、後述するのめり込み判断処理を実行し（ステップＳ３０２）、のめり込み判断処理の結果、のめり込みフラグがオン状態とされたか否かを判断する（ステップＳ３０３）。のめり込みフラグは、遊技者が遊技にのめり込んでいる状態と判断できるか否かを示すフラグである。のめり込み判断処理については、後述する。
ＣＵ３は、のめり込みフラグがオン状態であると判断した場合（ステップＳ３０３でＹＥＳと判断した場合）、つまり、遊技者が遊技にのめり込んでいる状態と判断できる場合は、玉貸しをせずに、貸出ボタンの押下に対する処理を終了する。
一方、のめり込みフラグがオン状態でないと判断した場合（ステップＳ３０３０でＮＯと判断した場合）、つまり、遊技者が遊技にのめり込んでいないと判断できる場合は、５００円分のプリペイド消費を確定させるとともに、加算玉数＝１２５のデータをバックアップする。このように、残額消費は、貸出操作が行なわれた段階でＣＵ３側単独で確定する。その後、ＣＵ３は加算表示中となる。この加算表示中では、残額から１２５玉分引落して遊技玉に加算している最中であることを表示器５４に表示させる。
次に、ＣＵ３は、Ｐ台２に対して遊技玉の加算要求を行なう。そのため、ＣＵ３は、通番＝ｎ＋１、遊技玉加算要求＝ＯＮ、加算玉数＝１２５および加算通番＝ｍ＋１を含む状態情報要求のコマンドをＰ台２へ送信する。通番をカウントアップして“ｎ＋１”とするとともに、遊技玉の加算要求を行なうため、加算通番もカウントアップして“ｍ＋１”とする。ＣＵ３は、加算通番を“ｍ＋１”にカウントアップするとともに、前回最終送信加算通番を“ｍ＋１”に更新して、そのデータをバックアップする。それを受けて、Ｐ台２は、遊技玉数＝５０（現在の遊技玉数）＋１２５（加算玉数）＝１７５に遊技玉数を更新し、前回最終送信加算通番を“ｍ＋１”に更新して、そのデータをバックアップする。そして、Ｐ台２は、ＣＵ３に対して遊技玉数＝１７５および遊技玉加算結果＝ＯＫを通知するため、通番＝ｎ＋１、加算玉数＝１７５、遊技玉加算結果＝ＯＫおよび加算通番＝ｍ＋１を含む状態情報応答のレスポンスをＣＵ３に返信する。遊技玉の加算要求に対する応答であるため、加算通番をカウントアップせずに、そのまま“ｍ＋１”とする。
その後、ＣＵ３は、通番＝ｎ＋２、遊技玉加算要求＝ＯＦＦおよび加算通番＝ｍ＋１を含む状態情報要求のコマンドをＰ台２へ送信し、Ｐ台２は、通番＝ｎ＋５、加算玉数＝１７５および加算通番＝ｍ＋１を含む状態情報応答のレスポンスをＣＵ３に返信する。遊技玉の加算要求がＯＦＦの場合、状態情報要求および状態情報応答は、通番をカウントアップするが、加算通番はカウントアップしない。
＜＜のめり込み判断処理＞＞
前述の図８のステップＳ３０１で貸出ボタンが押下された場合、および、後述の図１６のステップＳ３０５でカード返却ボタンが押下されたと判断された場合、ＣＵ３によって、のめり込み判断処理が実行される。
前述の図８のステップＳ３０１で貸出ボタンが押下された場合、および、後述の図１６のステップＳ３０５でカード返却ボタンが押下されたと判断された場合、ＣＵ３によって、のめり込み判断処理が実行される。
図９は、ＣＵ３によって実行されるのめり込み判断処理の流れを示すフローチャートである。図９を参照して、まず、ＣＵ３のＣＵ制御部３２３は、のめり込みフラグがすでにオン状態であるか否かを判断する（ステップＳ３１１）。のめり込みフラグは、図８で前述したが、遊技者が遊技にのめり込んでいる状態と判断できるか否かを示すフラグである。
のめり込みフラグがオン状態でないと判断した場合（ステップＳ３１１でＮＯと判断した場合）、つまり、遊技者が遊技にのめり込んでいる状態でないと判断できる場合、ＣＵ制御部３２３は、のめり込み監視中フラグがオン状態であるか否かを判断する（ステップＳ３１２）。のめり込み監視中フラグは、遊技者ののめり込みの監視中であるか否かを示すフラグである。
のめり込み監視中フラグがオン状態でないと判断した場合（ステップＳ３１２でＮＯと判断した場合）、つまり、遊技者ののめり込みの監視中でないと判断した場合、ＣＵ制御部３２３は、のめり込み監視中フラグをオン状態にする（ステップＳ３１３）。
そして、ＣＵ制御部３２３は、カメラ３９９を制御して、遊技者の顔画像を撮影して、ＲＡＭに記憶させる（ステップＳ３１４）。また、カードが受付けられている場合は、ＣＵ制御部３２３は、そのカードＩＤを監視中ＩＤとしてＲＡＭに記憶させる（ステップＳ３１５）。
ホールサーバ８０１は、遊技者の顔画像に対応付けて、その遊技者が当日に遊技に使用した金額の累計である累計消費金額と、のめり込み防止のモードと、のめり込み防止の判断基準の設定額とを対応付けて記憶している。
図１０は、のめり込み防止に関する設定可能なパラメータを示す図である。図１０を参照して、のめり込み防止のモード設定としては、のめり込み防止の判断基準を満たすと遊技を禁止するモード「禁止」と、再び遊技を可能とするための手間が比較的多いモード「高」と、再び遊技を可能とするための手間が比較的少ないモード「低」とが含まれる。デフォルトでは、モード設定は、モード「高」に設定される。
のめり込みの判断基準の設定額は、１０，０００円から１００，０００円まで１０，０００円刻みで設定可能となっている。デフォルトでは、設定額は、３０，０００円とされる。
これらのモード設定および設定額の配信の設定は、一括してすべてのＣＵ３に送信する「一括」、または、個別にＣＵ３に送信する「個別」のいずれかである。デフォルトでは、「一括」に設定される。「一括」に設定された場合は、ホールサーバ８０１で設定された１組のモード設定および設定額が、ホールサーバ８０１で管理されているすべてのＣＵ３に送信される。「個別」に設定された場合は、ホールサーバ８０１で各ＣＵ３に対して個別に、モード設定および設定額が送信される。
図９に戻って、ＣＵ３では、ＣＵ制御部３２３は、ステップＳ３１４で撮影された顔画像に対応付けて、ホールサーバ８０１に記憶されている累計消費金額、モード設定および設定額を、ホールサーバ８０１から取得して、ＲＡＭに記憶させる（ステップＳ３１６）。なお、撮影された顔画像に対応付けてこれらのデータが記憶されていない場合は、ＣＵ制御部３２３は、撮影した顔画像に加えて、モード設定としてはデフォルトのモード「高」を記憶させ、累計消費金額としては「０円」を記憶させる。
のめり込み監視中フラグがオン状態であると判断した場合（ステップＳ３１２でＹＥＳと判断した場合）、つまり、遊技者ののめり込みの監視中であると判断した場合、および、ステップＳ３１６の後、つまり、のめり込みの監視中とされた後、ＣＵ制御部３２３は、表示器５４または表示器３１２に表示された玉貸ボタンが操作されたか否かを判断する（ステップＳ３２１）。
玉貸ボタンが操作されたと判断した場合（ステップＳ３２１でＹＥＳと判断した場合）、ＣＵ制御部３２３は、ＲＡＭの累計消費金額に単位玉貸額（ここでは、図８で示すように５００円）を加算する（ステップＳ３２２）。こののめり込み判断処理が、図８の玉貸の処理のサブルーチンとして実行されている場合は、ステップＳ３２１の判断は、必ず、ＹＥＳとなる。一方、こののめり込み判断処理が、図１６のカード返却の処理のサブルーチンとして実行されている場合は、ステップＳ３２１の判断は、ＮＯとなり、累計消費金額には何も加算されない。
玉貸ボタンが操作されていないと判断した場合（ステップＳ３２１でＮＯと判断した場合）、および、ステップＳ３２２の後、ＣＵ制御部３２３は、累計消費金額が、ＲＡＭに記憶している設定額を超えたか否かを判断する（ステップＳ３２３）。
累計消費金額が設定額を超えたと判断した場合（ステップＳ３２３でＹＥＳと判断した場合）、ＣＵ制御部３２３は、のめり込みフラグをオン状態にし、表示器５４または表示器３１２に表示されている玉貸ボタンに覆い被さるように、モードに応じた注意喚起表示を表示させ、玉貸しボタンを不能動化させる（ステップＳ３２４）。
累計消費金額が設定額を超えていないと判断した場合（ステップＳ３２３でＮＯと判断した場合）、および、ステップＳ３２４の後、ＣＵ制御部３２３は、実行する処理を呼出元の処理に戻す。
図１１は、モード「低」時ののめり込み防止のための画面の遷移を示す図である。図１２は、モード「高」時ののめり込み防止のための画面の遷移を示す図である。図１３は、モード「禁止」時ののめり込み防止のための画面の遷移を示す図である。
図１１から図１３を参照して、注意喚起表示を表示させていない通常時には、図１１（Ａ）、図１２（Ａ）および図１３（Ａ）で示すように、受付けられているプリペイド残額を示す「残額５０００円」といった表示と、受付けられたカードに対応付けて管理されている持玉の数を示す「持玉１０，０００玉」といった表示と、および、受付けられたカードに対応付けて管理されている貯玉の数を示す「貯玉２０，０００玉」といった表示とに加えて、カード返却ボタン、玉貸しボタンおよび再プレイボタンが表示される。
モード「低」時およびモード「高」時に、設定額を超過した場合には、図１１（Ｂ）および図１２（Ｂ）で示すそれぞれ同様の画面が表示される。具体的には、玉貸ボタンの一部に覆い被さるように、「のめり込まないように！」といった遊技者にのめり込みに対する注意喚起をするための表示と当該注意喚起表示を消去するための「確認」ボタンとを含む画像が、注意喚起表示として表示される。
モード「禁止」時に、設定額を超過した場合には、図１３（Ｂ）で示す画面が表示される。具体的には、玉貸ボタンの一部に覆い被さるように、「のめり込まないように！（店員をお呼びください）」といった遊技者にのめり込みに対する注意喚起をするための表示を含む画像が、注意喚起表示として表示される。
このように、モード「低」時およびモード「高」時とは異なり、モード「禁止」時には「確認」ボタンが表示されないため、遊技者は、注意喚起表示を消去することができない。
のめり込みフラグがオン状態であると判断した場合（ステップＳ３１１でＹＥＳと判断した場合）、つまり、遊技者が遊技にのめり込んでいる状態であると判断できる場合、ＣＵ制御部３２３は、カメラ３９９を制御して、遊技者の顔画像を撮影する。
そして、ＣＵ制御部３２３は、撮影した遊技者の顔画像が、ＲＡＭに記憶している遊技者の顔画像から変化したか否かを判断する（ステップＳ３３２）。顔画像が変化していないと判断した場合（ステップＳ３３２でＮＯと判断した場合）、受付けられているカードのカードＩＤが変化したか否かを判断する（ステップＳ３３３）。
顔画像またはカードＩＤの少なくともいずれか一方が変化したと判断した場合（ステップＳ３３２でＹＥＳと判断した場合、または、ステップＳ３３３でＹＥＳと判断した場合）、ＣＵ制御部３２３は、のめり込み監視中フラグをオフ状態とし、ＲＡＭに記憶している顔画像、累計消費金額、モード設定、および、設定額を消去する（ステップＳ３３４）。
顔画像およびカードＩＤの両方が変化していないと判断した場合（ステップＳ３３２およびステップＳ３３３でＮＯと判断した場合）、および、ステップＳ３３４の後、ＣＵ制御部３２３は、ＲＡＭに記憶されているモードがモード「低」であるか否かを判断する（ステップＳ３３５）。
モード「低」であると判断した場合（ステップＳ３３５でＹＥＳと判断した場合）、ＣＵ制御部３２３は、図１１（Ｂ）で示した確認ボタンが操作されたか否かを判断する（ステップＳ３３６）。確認ボタンが操作されていないと判断した場合（ステップＳ３３６でＮＯと判断した場合）、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
一方、モード「低」でないと判断した場合（ステップＳ３３５でＮＯと判断した場合）、ＣＵ制御部３２３は、ＲＡＭに記憶されているモードがモード「禁止」であるか否かを判断する（ステップＳ３３７）。
モード「禁止」であると判断した場合（ステップＳ３３７でＹＥＳと判断した場合）、ＣＵ制御部３２３は、店員によるＣＵ３のリセット操作があったか否かを判断する（ステップＳ３３８）。リセット操作がないと判断した場合（ステップＳ３３８でＮＯと判断した場合）、ＣＵ制御部３２３は、ステップＳ３３８の処理を繰返す。つまり、店員のリセット操作がない限り、先の処理には進められない。
モード「低」時で図１１（Ｂ）の画面表示時に確認ボタンが操作されたと判断した場合（ステップＳ３３６でＹＥＳと判断した場合）、および、モード「禁止」時で図１３（Ｂ）の画面表示時にリセット操作があったと判断した場合（ステップＳ３３８でＹＥＳと判断した場合）、ＣＵ制御部３２３は、のめり込みフラグをオフ状態にし、それぞれ、図１１（Ｃ）および図１３（Ｃ）で示すように注意喚起表示を消し、玉貸ボタンを能動化させる。その後、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
モード「禁止」でないと判断した場合（ステップＳ３３７でＮＯと判断した場合）、ＣＵ制御部３２３は、ＲＡＭに記憶されているモードがモード「高」であるか否かを判断する（ステップＳ３４１）。モード「高」でないと判断した場合（ステップＳ３４１でＮＯと判断した場合）、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
モード「高」であると判断した場合（ステップＳ３４１でＹＥＳと判断した場合）、ＣＵ制御部３２３は、図１２（Ｂ）で示した確認ボタンが操作されたか否かを判断する（ステップＳ３４２）。確認ボタンが操作されたと判断した場合（ステップＳ３４２でＹＥＳと判断した場合）、ＣＵ制御部３２３は、図１２（Ｃ）で示すように、玉貸ボタンの全部に覆い被さる「カード返却で操作可」といった表示を含む画像が表示されることで、玉貸ボタンは不能動化のまま、図１２（Ｂ）で示した注意喚起表示は消去される（ステップＳ３４３）。その後、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
一方、図１２（Ｂ）で示した確認ボタンが操作されていないと判断した場合（ステップＳ３４２でＮＯと判断した場合）、ＣＵ制御部３２３は、玉貸ボタン不能動化中であるか否か、つまり、図１２（Ｂ）または図１２（Ｃ）の画面が表示中であるか否かを判断する（ステップＳ３４４）。玉貸ボタン不能動化中でないと判断した場合（ステップＳ３４４でＮＯと判断した場合）、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
一方、玉貸ボタン不能動化中であると判断した場合（ステップＳ３４４でＹＥＳと判断した場合）、つまり、図１２（Ｂ）または図１２（Ｃ）の画面が表示中であると判断した場合、ＣＵ制御部３２３は、表示器５４または表示器３１２に表示されているカード返却ボタンが操作されたか否かを判断する（ステップＳ３４５）。
カード返却ボタンが操作されていないと判断した場合（ステップＳ３４５でＮＯと判断した場合）、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
一方、カード返却ボタンが操作されたと判断した場合（ステップＳ３４５でＹＥＳと判断した場合）、ＣＵ制御部３２３は、のめり込みフラグをオフ状態とし、図１２（Ｄ）で示すように玉貸ボタンに覆い被さる表示を消去することで、玉貸ボタンを能動化する（ステップＳ３４６）。その後、ＣＵ制御部３２３は、実行する処理をこの処理の呼出元の処理に戻す。
（１） このように、ＣＵ３によって、受付けた金額に応じてＰ台２でのパチンコ遊技を可能にするための図８で示すような玉貸の処理を実行させるための玉貸ボタンを示す画像が、表示器５４または表示器３１２に表示され、表示画面上での遊技者の操作の検知に基づいて、表示された玉貸ボタンの操作が受付けられたか否かが判断され、遊技の量を示す指標が所定基準に達したか否かが判断され、指標が所定基準に達したと判断されたことに応じて、玉貸ボタンを示す画像の一部に覆い被さる注意喚起表示が、表示され、注意喚起表示が表示されているときには、玉貸ボタンの操作の受付に応じた玉貸の処理が不能動化される。
このため、遊技の量がある基準に達すると、パチンコ遊技を可能にすることができなくなる。また玉貸ボタンを示す画像の一部に覆い被さる注意喚起表示がされるので、玉貸の処理ができず、パチンコ遊技を可能にすることができなくなったことを遊技者に分かり易く知らせることができる。その結果、遊技へののめり込みを効果的に防止することができる。
（２） 上述した実施の形態においては、ＣＵ３によって、パチンコ玉の払出しに用いられた金額が所定の設定額に達したか否かが判断されることで、指標が所定基準に達したか否かが判断されるようにした。
このため、パチンコ玉の払出しに用いられた金額が設定額に達すると、遊技を可能にすることができなくなる。その結果、遊技へののめり込みを効果的に防止することができる。なお、所定の設定額に達するまでの紙幣の投入回数に応じて、喚起表示の態様を異ならせるようにしてもよい。
（３） しかし、設定値に達したか否かが判断される金額は、当日のパチンコ玉の払出しに用いられた金額に限定されず、３日間など所定期間のパチンコ玉の払出しに用いられた金額であってもよい。
（４） また、これに限定されず、遊技が行なわれている時間（たとえば、当日の遊技時間であってもよいし、３日間など所定期間の遊技時間であってもよい）が所定時間に達したか否かが判断されることで、指標が所定基準に達したか否かが判断されるようにしてもよい。これによっても同様の効果を得ることができる。
（５） また、遊技が行なわれた回数（たとえば、当日の台移動回数であってもよいし、１週間など所定期間の他店を含めた来店回数であってもよい）が所定回数に達したか否かが判断されることで、指標が所定基準に達したか否かが判断されるようにしてもよい。これによっても同様の効果を得ることができる。
（６） 前述した実施の形態においては、所定基準は、遊技場内の管理装置であるホールサーバ８０１から設定可能であることとした。このため、管理装置が設置されている場所からまとめて所定基準を変更することができる。その結果、遊技へののめり込みを効果的に防止することができる。この場合に、遊技者ごと、ＣＵ３ごと、遊技機島ごと、機種ごと、遊技媒体貸出単価（たとえば、パチンコ玉１玉１円または４円、メダル１枚５円または２０円）ごと、大当り確率ごとに、所定基準が設定可能であることとしてもよい。
（７） しかし、これに限定されず、所定基準は、各ＣＵ３などの各遊技用装置で設定可能であることとしてもよい。これにより、各遊技用装置に所定基準を細やかに変更することができる。その結果、遊技へののめり込みを効果的に防止することができる。
（８） また、所定基準は、遊技場外の管理装置から設定可能であることとしてもよい。具体的には、遊技場外の管理装置で、所定基準が設定されて、設定された所定基準が、当該管理装置で管理される遊技場の遊技用装置に送信され、各遊技用装置で受信された所定基準が記憶されるようにする。これにより、遊技場外からまとめて所定基準を変更することができる。その結果、遊技へののめり込みを効果的に防止することができる。
（９） 前述した実施の形態においては、ＣＵ３によって、管理装置としてのホールサーバ８０１で遊技者を特定可能な情報（たとえば、カメラ３９９で撮影された顔画像、カードＩＤ）に対応付けて累積されて計数されている指標が、所定基準に達したか否かが判断されるようにした。
具体的には、上述したように、ホールサーバ８０１では、顔画像に対応付けられて累計消費金額などが記憶されている。のめり込みフラグおよびのめり込み監視中フラグがオフである場合、つまり、遊技者がのめり込み状態でないと判断され、未だ、のめり込みを監視していない場合は、まず、図９のステップＳ３１６で、ホールサーバ８０１から、遊技者の顔画像に対応する累計消費金額が取得され、のめり込みの監視が開始される。
そして、ステップＳ３２１，ステップＳ３２２で示されるように、玉貸ボタンが操作されるごとに、この累計消費金額に単位玉貸額が加算され、ステップＳ３２３，ステップＳ３２４で示されるように、累計消費金額が設定額を超えると、注意喚起表示が表示され、玉貸ボタンが不能動化される。
これにより、ある遊技者がＣＵ３のうちのいずれを用いたとしても、遊技の量がある基準に達すると、遊技を可能にすることができなくなる。その結果、遊技者ごとに遊技へののめり込みを効果的に防止することができる。
（１０） 前述した実施の形態においては、個人データ（たとえば、年収、ブラックリスト、遊技の量を示す指標の傾向）に関わらず、同じ所定基準に、指標が達したか否かを判断するようにした。
しかし、これに限定されず、管理装置で遊技者を特定可能な情報（たとえば、カメラ３９９で撮影された顔画像、カードＩＤ）に対応付けて管理されている当該遊技者の個人データに応じた所定基準に、指標が達したか否かを判断するようにしてもよい。
具体的には、複数の遊技場が共同で遊技の量の多い遊技者の顔画像を管理装置で管理し、その遊技者の遊技の量に応じた所定基準に、指標が達したか否かを判断するようにするようにしてもよい。
これにより、遊技者の個人データに応じた基準に達すると、遊技を可能にすることができなくなる。また、遊技者が遊技場会員カード／共通会員カードなどを使わない場合であっても遊技者を特定することができる。その結果、それぞれの遊技者に合わせてのめり込みを効果的に防止することができる。
（１１） 前述した実施の形態においては、１つの遊技場の管理装置で管理されているＣＵ３によって、管理装置で遊技者を特定可能な情報に対応付けて累積されて計数されている指標が、所定基準に達したか否かが判断されるようにした。
しかし、これに限定されず、管理装置で遊技用装置が管理されている複数の遊技場のうちのいずれの遊技場の遊技用装置によっても、管理装置で遊技者を特定可能な情報に対応付けて累積されて計数されている指標が、所定基準に達したか否かが判断されるようにしてもよい。
具体的には、複数の遊技場の遊技者の累計消費金額を管理する管理装置によって遊技者の顔画像に対応付けて複数の遊技場での累計消費金額を記憶し、遊技用装置によって、管理装置から取得された複数の遊技場での累計消費金額が、所定基準に達したか否かが判断されるようにしてもよい。
これにより、管理装置で遊技用装置が管理されているいずれの遊技場の遊技用装置を遊技者が用いたとしても、遊技の量がある基準に達すると、遊技を可能にすることができなくなる。その結果、遊技者が複数の遊技場のいずれを利用したとしても、遊技者ごとに遊技へののめり込みを効果的に防止することができる。
（１２） 前述した実施の形態においては、ＣＵ３によって、玉貸の処理の不能動化を解除する操作（たとえば、確認ボタンの操作、カードの返却ボタンの操作、店員のリセット操作）が受付けられたことを条件として、玉貸の処理の不能動化が解除される。
これにより、玉貸の処理の不能動化を解除するためには、不能動化を解除する操作が必要となるので、遊技を可能にするために手間が増える。その結果、より効果的にのめり込みを防止することができる。
（１３） なお、前述した実施の形態においては、図１１（Ｂ）、図１２（Ｂ）および図１３（Ｂ）で示したように、玉貸ボタンの一部に覆い被さるように注意喚起表示が表示されることとした。しかし、これに限定されず、玉貸ボタンの全部に覆い被さるように、注意喚起表示を表示させてもよい。
また、所定の指標が所定基準に達したときに、最初は、玉貸ボタンに覆い被さっていない状態で、注意喚起表示が表示されるようにし、次第に、注意喚起表示を大きくする、または、移動するなどして、所定時間、経過した時点で、玉貸ボタンの一部または全部に覆い被さるようにしてもよい。このように、次第に隠すようにすることで、覆い被さったことを遊技者に認識させることができる。
（１４） また、前述した実施の形態においては、玉貸ボタンが不能動化された。このように、玉貸ボタンの操作の受付を制限するようにした。しかし、これに限定されず、玉貸ボタンの操作は受付けるが玉貸の処理を制限、たとえば、玉貸の処理を実行しないするようにしてもよいし、操作をするための手間が掛かるようにするもの（たとえば、操作をするための手順が増えるもの、操作をするための場所が遠くなるもの）であってもよい。
また、遊技可能化処理の制限として、玉貸の処理を実行しないようにしてもよいし、入金を受付けないようにしてもよいし、遊技機の動作を停止させるようにしてもよい。
（１５） 前述した実施の形態においては、図１１（Ｂ）、図１２（Ｂ）および図１３（Ｂ）で示したように、玉貸ボタンに覆い被さるように注意喚起表示が表示されることとした。しかし、これに限定されず、玉貸ボタンに加えて、カード返却ボタンおよび再プレイボタンの少なくとも一方に覆い被さるように注意喚起表示が表示されるようにしてもよい。
（１６） 前述した実施の形態においては、注意喚起表示が表示されているときには、玉貸ボタンの操作の受付を制限するようにした。しかし、これに限定されず、注意喚起表示が表示されているときには、注意喚起表示が覆い被されている範囲に関わらず、玉貸しボタンに加えてカード返却ボタンおよび再プレイボタンの少なくとも一方の操作の受付を制限するようにしてもよい。また、注意喚起表示が表示されているときには、注意喚起表示が覆い被されている範囲に関わらず、玉貸しボタンに加えてカード返却ボタンおよび再プレイボタンの少なくとも一方の操作は受付けるが、それらのボタンに応じた処理を制限する（たとえば、実行しない）ようにしてもよい。
＜＜持玉払出・貯玉払出（再プレイ）＞＞
次に、持玉払出、貯玉払出をして再プレイする処理について説明する。この図１４では、当初の遊技玉数が５０玉の状態となっている。まず、ＣＵ３は、通番＝ｎ、遊技玉加算要求＝ＯＦＦおよび加算通番＝ｍを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝５０および加算通番＝ｍを含む状態情報応答のレスポンスをＣＵ３に返信する。このように、加算要求が発生していない間は、加算通番が更新されることはない。
次に、持玉払出、貯玉払出をして再プレイする処理について説明する。この図１４では、当初の遊技玉数が５０玉の状態となっている。まず、ＣＵ３は、通番＝ｎ、遊技玉加算要求＝ＯＦＦおよび加算通番＝ｍを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝５０および加算通番＝ｍを含む状態情報応答のレスポンスをＣＵ３に返信する。このように、加算要求が発生していない間は、加算通番が更新されることはない。
その後、持玉または貯玉が存在する状態で、遊技者が持玉払出ボタンまたは再プレイボタンを押下すると、ＣＵ３は、持玉または貯玉からの１２５玉分の消費を確定させる。このように、持玉または貯玉の消費は、持玉払出ボタンまたは再プレイボタンを押下する操作がなされた段階でＣＵ３側単独で確定する。なお、持玉と貯玉との双方が存在する場合には、持玉消費が優先される。
この持玉を優先して消費する制御に代えて、貯玉再プレイボタンと持玉再プレイボタンとを設け、遊技者が選択して操作することにより、貯玉消費または持玉消費のいずれかを選べるようにしてもよい。すなわち、再プレイボタンは、貯玉（貯メダル）から遊技玉（遊技点）を得るための貯玉（貯メダル）再プレイボタンと、持玉（持点）から遊技玉（遊技点）を得るための持玉（持点）再プレイボタンとの２つで構成してもよい。
ＣＵ３は、持玉または貯玉からの消費を確定させた後、加算玉数＝１２５の加算要求をＰ台２に通知する。具体的に、ＣＵ３は、遊技玉の加算処理中であることを表示するとともに、通番＝ｎ＋１、遊技玉加算要求＝ＯＮ、加算玉数＝１２５および加算通番＝ｍ＋１を含む状態情報要求のコマンドをＰ台２へ送信する。遊技玉の加算要求を行なうため、通番をカウントアップして“ｎ＋１”とするとともに、加算通番もカウントアップして“ｍ＋１”とする。さらに、ＣＵ３は、前回最終送信加算通番を“ｍ＋１”に更新して、そのデータをバックアップする。それを受けて、Ｐ台２は、遊技玉数＝５０（現在の遊技玉数）＋１２５（加算玉数）＝１７５に遊技玉数を更新し、前回最終送信加算通番を“ｍ＋１”に更新して、そのデータをバックアップする。そして、Ｐ台２は、通番＝ｎ＋１、加算玉数＝１７５、遊技玉加算結果＝ＯＫおよび加算通番＝ｍ＋１含む状態情報応答のレスポンスをＣＵ３に返信する。遊技玉の加算要求に対する応答であるため、加算通番をカウントアップせずに“ｍ＋１”のままとする。
その後、ＣＵ３は、通番＝ｎ＋２、遊技玉加算要求＝ＯＦＦおよび加算通番＝ｍ＋１を含む状態情報要求のコマンドをＰ台２へ送信し、Ｐ台２は、通番＝ｎ＋２、加算玉数＝１７５および加算通番＝ｍ＋１を含む状態情報応答のレスポンスをＣＵ３に返信する。
＜＜遊技玉計数（通常）＞＞
次に、遊技玉の一部を計数して減算する通常時の計数処理について説明する。この図１５では、カード返却の操作が検出されることなく計数ボタンが押下された場合を示している。それゆえ、ＣＵ３からＰ台２へ送信されるカード返却準備状態のビットは、いずれもＯＦＦ（＝０）となっている。このため、以下ではカード返却準備状態のビットの説明を省略する。
次に、遊技玉の一部を計数して減算する通常時の計数処理について説明する。この図１５では、カード返却の操作が検出されることなく計数ボタンが押下された場合を示している。それゆえ、ＣＵ３からＰ台２へ送信されるカード返却準備状態のビットは、いずれもＯＦＦ（＝０）となっている。このため、以下ではカード返却準備状態のビットの説明を省略する。
また、この図１５では、挿入された記録媒体（会員用カードまたはビジターカード）により特定される持玉数が「０」玉であり、当初の遊技玉数が「８００」玉の状態となっている。
なお、ここでは、計数ボタンの操作が検出されている間、１００点単位での計数が継続し、計数ボタンの操作が検出されなくなった段階で計数動作が終了する例を説明する。
まず、ＣＵ３は、通番＝ｎ、カード返却準備状態＝ＯＦＦ、計数通番＝ｍ、計数応答＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝８００、計数通番＝ｍ、計数玉数＝０、計数要求＝ＯＦＦを含む状態情報応答のレスポンスをＣＵ３に返信する。
ＣＵ３から送信された通番ｎに対して、Ｐ台２から通番ｎ＋１が返信されている。ＣＵ３から送信された計数通番ｍに対して、Ｐ台２からは同じ計数通番ｍが返信されている。これは、計数通番が、計数要求の発生を契機として更新され、計数の完了をもって更新が終了される特別な通番だからである。
その後、遊技者が、計数ボタン２８を押下する。この図１５では、計数ボタン２８を１回押下する操作がなされた直後に、通番＝ｎ＋１、カード返却準備状態＝ＯＦＦ、計数通番＝ｍ、計数応答＝ＯＦＦを含む状態情報要求のコマンドがＣＵ３からＰ台２へ送信されている。
Ｐ台２は、計数ボタン２８の操作を検出した場合、状態情報要求のコマンドに対する応答として、計数要求値を具体的に１００に設定した通番ｎ＋１の状態情報応答をＣＵ３へ送信する。ただし、この段階でＰ台２は計数要求分の計数を実行しない。このため、通番ｎ＋１の状態情報応答では、依然として遊技玉数＝８００とされている。また、この状態情報応答は、計数要求を示す電文であるため、計数通番が“ｍ＋１”にカウントアップされている。Ｐ台２は、このとき、前回最終送信計数通番を更新し、更新した前回最終送信計数通番と計数要求状態ＯＮとのデータをバックアップする。
通番ｎ＋１の状態情報応答を受信したＣＵ３は、要求されている計数玉数相当の持玉を加算するとともに、持玉の表示を１００に更新する。すなわち、ＣＵ制御部３２３は、表示制御部３５０に対して計数表示の指令を送信する。表示制御部３５０は、その指令を受けてＰ台２側の表示器５４を表示制御する。その結果、表示器５４には、遊技玉が計数されてその数が減少する一方で、持玉が増加する画像表示が行なわれる。
この場合、遊技玉が一発ずつ、各台計数器に案内されて計数されていくような演出表示を行なうことが考えられる。この演出表示の他の例としては、遊技玉数のデータが持玉数のデータに経時的に変換されていく表示であってもよい。たとえば、遊技玉数のデータと持玉数のデータとを棒グラフで示し、遊技玉数の棒グラフを減少させつつ持玉数の棒グラフを増加させたり、遊技玉数の棒グラフの一部を持玉数の棒グラフに移動させる表示を繰返したりしてもよい。さらに演出表示の他の例としては、現在の遊技玉数のデータと持玉数のデータをそのままデジタル表示し、遊技玉数を減少させつつ持玉数を増加させたり、遊技玉数の一部を持玉数に移動させる表示を繰返したり、種々の演出表示が考えられる。
さらに、ＣＵ３は、前回最終送信計数通番を“ｍ＋１”に更新して、そのデータをバックアップする。続いて、ＣＵ３は、Ｐ台２に対して、通番ｎ＋２、計数通番ｍ＋１、計数応答＝ＯＮの状態情報要求を送信し、要求された計数を終えたことを通知する。
この状態情報要求を受信したＰ台２は、ようやく、計数玉数＝１００に対応する数だけ遊技玉数を減算し、遊技玉数表示器２９の表示を８００から７００に更新する。この段階で、Ｐ台２は計数要求状態がＯＦＦとなるが、計数ボタンの押下が継続しているため、Ｐ台２は２度目の計数要求をＣＵ３へ送信する。すなわち、計数要求値を具体的に１００に設定した通番ｎ＋２の状態情報応答をＣＵ３へ送信する。ただし、この段階でもＰ台２は計数要求分の計数を実行しない。このため、通番ｎ＋２の状態情報応答では、遊技玉数＝７００とされている。また、この状態情報応答は、新たな計数要求として送信される電文であるため、計数通番を“ｍ＋２”にカウントアップして、前回最終送信計数通番を更新し、更新した前回最終送信計数通番と計数要求状態ＯＮとのデータをバックアップする。
通番ｎ＋２の状態情報応答を受信したＣＵ３は、要求されている計数玉数相当の持玉を加算するとともに、持玉の表示を２００に更新する。さらに、ＣＵ３は、前回最終送信計数通番を“ｍ＋２”に更新して、そのデータをバックアップする。続いて、ＣＵ３は、Ｐ台２に対して、通番ｎ＋３、計数通番ｍ＋２、計数応答＝ＯＮの状態情報要求を送信し、要求された計数を終えたことを通知する。
この状態情報要求を受信したＰ台２は、計数玉数＝１００に対応する数だけ遊技玉数を減算し、遊技玉数表示器２９の表示を７００から６００に更新する。ところが、この段階で、計数ボタンから遊技者の手が離れており、計数操作が終了している。このため、Ｐ台２は計数完了を通番ｎ＋３の状態情報応答でＣＵ３へ通知する。すなわち、現在の遊技玉数＝６００とともに、計数要求＝ＯＦＦ、計数玉数＝０の状態情報応答をＣＵ３へ送信する。また、計数要求に対応するすべての計数動作が済んでいるため、この状態情報応答に含まれる計数通番もｍ＋２のままで更新されていない。
この状態情報応答を受信したＣＵ３は、計数完了と判定する。図示を省略しているが、ＣＵ３は、通番ｎ＋４、計数通番ｍ＋２、カード返却準備状態＝ＯＦＦ、計数応答＝ＯＦＦの状態情報応答をＰ台２へ送信する。
このように、本実施の形態では、計数玉数を通知する情報状態応答をＰ台からＣＵへ送信する際に、Ｐ台側で早々と計数玉分の遊技玉の減算を行なっているのではなく、計数玉数を通知する情報状態応答を送信してからこれに対する受領確認をＣＵから受けた段階で、Ｐ台は遊技玉の減算を行なっている。
＜＜遊技玉計数（カード返却）＞＞
次に、カードを返却する際の遊技玉の計数処理について説明する。図１６は、遊技者がカード返却操作を行なった場合の計数処理を説明するためのシーケンス図である。図１６では、挿入された記録媒体（会員用カード等）により特定されるカード持玉数が０玉であり、当初の遊技玉数が８００玉の状態となっている。まず、ＣＵ３は、通番＝ｎ、ＣＵ開店状態＝ＯＮ、カード返却準備状態＝ＯＦＦ、計数通番＝ｍおよび計数応答＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝８００、計数通番＝ｍ、計数玉数＝０および計数要求＝ＯＦＦを含む状態情報応答のレスポンスをＣＵ３に返信する。
次に、カードを返却する際の遊技玉の計数処理について説明する。図１６は、遊技者がカード返却操作を行なった場合の計数処理を説明するためのシーケンス図である。図１６では、挿入された記録媒体（会員用カード等）により特定されるカード持玉数が０玉であり、当初の遊技玉数が８００玉の状態となっている。まず、ＣＵ３は、通番＝ｎ、ＣＵ開店状態＝ＯＮ、カード返却準備状態＝ＯＦＦ、計数通番＝ｍおよび計数応答＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ、遊技玉数＝８００、計数通番＝ｍ、計数玉数＝０および計数要求＝ＯＦＦを含む状態情報応答のレスポンスをＣＵ３に返信する。
その後、遊技者が、遊技を止める場合や別の遊技台に移動する場合に、表示器５４または表示器３１２に表示された「カード返却」ボタンを押下する（ステップＳ３０５）。「カード返却」ボタンが操作された場合、図９で前述したのめり込み判断処理を実行する（ステップＳ３０６）。
この場合、のめり込みフラグがオン状態であり、モード「高」であれば、カード返却ボタンの操作がされたか否かの判断（ステップＳ３４５）でＹＥＳと判断され、のめり込みフラグがオフ状態にされ、玉貸ボタンが能動化される。
その後、遊技者が「カード返却」ボタンを押下した時点では、Ｐ台２の遊技玉数が８００玉で、ＣＵ３はＰ台２の遊技玉数が０玉でないと判定する。また、ＣＵ３は、遊技者が「カード返却」ボタンを押下したのでカード返却準備状態＝ＯＮとして、通番＝ｎ＋１、ＣＵ開店状態＝ＯＮ、計数通番＝ｍおよび計数応答＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。なお、ＣＵ３は、カード返却準備状態＝ＯＮの通知を１０秒間、Ｐ台２に通知する。さらに、ＣＵ３は、Ｐ台２の遊技玉数が８００玉で、０玉でないため、カード返却待機として、表示器５４等に計数操作を促す表示を行なう。
計数操作を促す表示を受けて、遊技者が計数ボタン２８を押下して、遊技玉を持玉に変換する操作を行なう。Ｐ台２は、計数ボタン２８を押下する計数操作が、カード返却準備状態＝ＯＮでの計数操作であると判定し、たとえば１００玉単位での計数ではなく、一括して計数を処理する。
Ｐ台２は、遊技玉数８００玉の計数受付要求および遊技玉数８００玉を一括計数した計数玉数８００玉をＣＵ３に通知するために、通番＝ｎ＋１、遊技玉数＝８００、計数通番＝ｍ＋１、計数玉数＝８００および計数要求＝ＯＮを含む状態情報応答のレスポンスをＣＵ３に返信する。ただし、この段階でＰ台２は計数要求分の計数を実行しない。このため、通番ｎ＋１の状態情報応答では、依然として遊技玉数＝８００とされている。また、この状態情報応答は、計数要求の電文であるため、Ｐ台２は、計数通番を“ｍ＋１”にカウントアップして、前回最終送信計数通番を更新し、更新した前回最終送信計数通番と計数要求状態ＯＮとのデータをバックアップする。
これを受けて、ＣＵ３は、計数玉数８００玉を持玉数に加算して、計数玉数８００玉を遊技玉数８００玉から０玉に減算する。また、ＣＵ３は、更新した前回最終送信計数通番のデータをバックアップする。そして、ＣＵ３は、計数玉受取りを通知するため、通番＝ｎ＋２、ＣＵ開店状態＝ＯＮ、カード返却準備状態＝ＯＮ、計数通番＝ｍ＋１および計数応答＝ＯＮを含む状態情報要求のコマンドをＰ台２へ送信する。
Ｐ台２は、ＣＵ３からの応答を受けて、計数玉数８００玉を遊技玉数８００玉から減算して遊技玉数０玉を表示器５４等に表示する。さらに、Ｐ台２は、遊技玉数０玉、計数完了した旨をＣＵ３に通知するために、通番＝ｎ＋２、遊技玉数＝０、計数通番＝ｍ＋１、計数玉数＝０および計数要求＝ＯＦＦを含む状態情報応答のレスポンスをＣＵ３に返信する。なお、計数要求がＯＦＦとなるので、計数通番はｍ＋１のままカウントアップせずにＣＵ３に送信される。
ＣＵ３は、遊技者がカード返却ボタン３２２を押下してから１０秒経過する前、つまり、カード返却準備状態中に、計数ボタン２８を押下して遊技玉を持玉に一括計数して遊技玉数を０玉にしているので、カード返却処理を実行する。つまり、ＣＵ３は、通番＝ｎ＋３を含むカード返却通知のコマンドをＰ台２へ送信する。それを受けて、Ｐ台２は、通番＝ｎ＋３、払出制御基板１７に保持してあるカードＩＤおよびカード挿入時刻を含むカード返却応答のレスポンスをＣＵ３に返信する。カードＩＤおよびカード挿入時刻をＣＵ３に返信後、払出制御基板１７に保持してあるカードＩＤおよびカード挿入時刻のデータをクリアする。
それを受けて、ＣＵ３は、挿入しているカードに記憶しているカードＩＤと、Ｐ台２から受信したカードＩＤとの一致判別を行ない、一致した場合は挿入しているカードを返却し、不一致の場合エラー処理を行ないホールサーバ８０１などに報告する。ＣＵ３は、カードＩＤが一致した場合、カード挿入／排出口３０９に挿入してあったカード（挿入カード）に持玉数８００を記憶させてそのカードを遊技者に返却する。また、遊技者がカード挿入／排出口３０９にカードを挿入することなく入金操作により遊技を開始している場合には、ＣＵ３に設けられているカードストック部にストックされているカード（ストックカード）に持玉数８００を記憶させてそのカードを遊技者に返却する。挿入カードまたはストックカードの返却の際、ＣＵ３は当該カードのカードＩＤと持玉数のデータとをホールサーバ８０１へ送信し、ホールサーバ８０１が当該カードのカードＩＤに対応付けて持玉数のデータを記憶してもよい。
その後、ＣＵ３から返却されたカードは、カード挿入／排出口３０９から抜き取り可能となるため、カードの一部がカード挿入／排出口３０９から突き出た状態（カード抜き取り可能状態）で保持される。ＣＵ３は、カード抜き取り可能状態であるか否かを判定することが可能なセンサをカード挿入／排出口３０９の近傍に取り付けてあり、当該センサの信号がＯＮ状態の場合、カード抜き取り可能状態と判定し、ＯＦＦ状態の場合、カード抜き取り完了状態と判定する。
そして、ＣＵ３は、カード返却処理が実行され、カード抜き取り可能状態となった場合、カード返却準備状態ＯＦＦおよびカード抜き取り待ち中ＯＮの情報をＰ台２に通知する。そのため、ＣＵ３は、通番＝ｎ＋４、ＣＵ開店状態＝ＯＮ、カード返却準備状態＝ＯＦＦ、カード抜き取り待ち中＝ＯＮ、計数通番＝ｍ＋１および計数応答＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。これを受けて、Ｐ台２は、カード抜き取り忘れを防止するため、遊技者に対して「カード抜き取って下さい」との文言と使用した累計消費金額で買える物とを可変表示装置２７８に表示する。
このように、ＣＵ３によって、返却操作に基づいて受付けた金額のうち玉貸の処理に用いられていない残額を特定可能なカードを返却するための処理が実行され、カードを返却するための処理がされるときに、指標を示す情報が報知される。具体的には、使用した金額で買える物を表示する。しかしこれに限定されず、使用した金額自体を表示してもよい。
これにより、遊技者が使用した金額を間接的に示す遊技の量を示す指標が遊技者に示される。その結果、より効果的に遊技へののめり込みを防止することができる。
また、Ｐ台２は、カードの抜き取りを報知するため、ＬＥＤを点灯させたり、スピーカで「カード抜き取って下さい」と音声出力させたりしてもよい。さらに、Ｐ台２は、通番＝ｎ＋４、遊技玉数＝０、計数通番＝ｍ＋１、計数玉数＝０および計数応答＝ＯＦＦを含む状態情報応答のコマンドをＣＵ３へ送信する。
カード挿入／排出口３０９の近傍に取り付けたセンサがＯＮ状態であれば、ＣＵ３は、カード抜き取り待ち中＝ＯＮを含む状態情報要求のコマンドをＰ台２へ送信する。しかし、遊技者がカード挿入／排出口３０９からカードを抜き取った場合、カード挿入／排出口３０９の近傍に取り付けたセンサがＯＦＦ状態となるので、ＣＵ３は、通番＝ｎ＋５およびカード抜き取り待ち中＝ＯＦＦを含む状態情報要求のコマンドをＰ台２へ送信する。
これを受けて、Ｐ台２は、可変表示装置２７８に表示していた「カード抜き取って下さい」の表示を止め、カードの抜き取りの報知を終了する。なお、カードの抜き取りの報知は、カード抜き取り待ち中＝ＯＮを含む状態情報要求のコマンドを受取ってから、カード抜き取り待ち中＝ＯＦＦを含む状態情報要求のコマンドを受取るまで報知を継続する。さらに、Ｐ台２は、通番＝ｎ＋５を含む状態情報応答のコマンドをＣＵ３へ送信する。
なお、図１６で説明したカードを返却する際の遊技玉の計数処理のシーケンスは、カード返却時に限定されるものではなく、簡易離席・食事休憩時にも同様の処理を適用することができる。ここで、簡易離席とは、遊技者が小用を済ませるために５〜１０分程度の短い時間遊技を中断するものである。食事休憩とは、簡易離席よりも長いたとえば３０分間等遊技を中断して食事や休憩を行なうものである。
＜ホール用管理コンピュータを含むシステム＞
次に、複数の遊技機を設置した遊技場には、各遊技機の出玉などを管理するためにホールコン９００が、ホールサーバ８０１とは別に設けられている。図１７は、Ｐ台２およびＣＵ３と接続されるホールサーバ８０１およびホールコン９００の構成を説明するためのブロック図である。
次に、複数の遊技機を設置した遊技場には、各遊技機の出玉などを管理するためにホールコン９００が、ホールサーバ８０１とは別に設けられている。図１７は、Ｐ台２およびＣＵ３と接続されるホールサーバ８０１およびホールコン９００の構成を説明するためのブロック図である。
遊技機メーカによってＰ台２のデータ出力フォーマットが異なっている。そのため、ＣＵ３は、その種々のフォーマットの出力データを、所定のフォーマットに演算（変換）して台端末装置９０１経由でホールコン９００に出力する。その演算（変換）のための設定データがＣＵ制御部３２３に入力されて記憶されるように構成されている。
また、ホールコンメーカによってホールコン９００のデータ受信フォーマットが異なっている。そこで、図１７に示すホールコン９００は、台端末装置９０１を介してＣＵ３に接続してある。台端末装置９０１は、ＣＵ３からの出力データのフォーマットを、各種ホールコン９００にマッチするフォーマットに変換してホールコン９００に送信する。なお、ホールコン９００によるＰ台２の台番号管理は、台端末装置９０１に関連付けてホールコン９００に設定している。具体的には、ホールコン９００にはＣＰＵとＲＯＭとＲＡＭとＥＥＰＲＯＭとが内蔵されており、ＣＰＵは、定員等の操作に応じて、台番号管理データとしてＰ台２の台番号と台端末装置９０１の番号とを対応付けてＥＥＰＲＯＭに記憶させる。Ｐ台２とＣＵ３との間ではシリアル通信が行なわれ、ＣＵ３と台端末装置９０１との間ではＣＵ３の複数の出力ピンから出力されるパラレル通信が行なわれ、台端末装置９０１とホールコン９００との間ではシリアル通信が行なわれる。
ただし、各種ホールコン９００にマッチするフォーマットに変換する機能をＣＵ３またはホールコン９００内に持たせることで、台端末装置９０１を介在させなくてもよい。
次に、ホールコン９００がホールサーバ８０１に直接接続される構成について説明する。図１８は、Ｐ台２およびＣＵ３と接続されるホールサーバ８０１およびホールコン９００の別の構成を説明するためのブロック図である。
ＣＵ３が、ホールコンで管理する情報を、ホールサーバ８０１を経由してホールコン９００に送信できるように、ホールコン９００がホールサーバ８０１に直接接続されている。なお、ホールサーバ８０１には、複数のＣＵ３が接続されており、ホールサーバ８０１が複数のＣＵ３からの出力信号を取りまとめてホールコン９００に送信する。この場合、前述の各種ホールコン９００にマッチするフォーマットに変換してホールコン９００に送信する台端末装置９０１機能はホールサーバ８０１が担う。なお、所定のフォーマットに変換してホールコン９００に送信する台端末装置９０１機能を全てＣＵ３が担ってもよく、またホールサーバ８０１とＣＵ３とでどの情報を変換するか等の役割分担を行なうように制御してもよい。さらには、ホールサーバ８０１が複数のＣＵ３からの出力信号を取りまとめてホールコン９００に送信する際に、送信する情報の内容をまとめた情報として送信してもよい。たとえば、ホールサーバ８０１が、複数のＣＵ３から受信した信号を定期的に（たとえば１０秒毎に）ホールコン９００に送信する場合に、その１０秒間に受信したすべてのＣＵ３の情報を一括してホールコン９００に送信する。
ホールサーバ８０１は、持玉や貯玉を管理する関係上必ずＣＵ３と接続されている必要があり、図１８に示すように、複数のＣＵ３からの情報をホールサーバ８０１がまとめてホールコン９００へ送信する場合には、複数のＣＵ３からホールサーバ８０１までの配線は既存のものを有効利用でき、ホールサーバ８０１とホールコン９００とを結ぶ配線だけ新設すれば事足り、配線数の低減を図ることができる。また、各遊技機からの遊技情報をたとえば島端末装置がまとめてホールコン９００へ出力する場合には遊技機設置島毎にまとめる必要があるため、遊技機の設置レイアウトに制約があるという不都合が生じるが、図１８の場合には、遊技機設置島毎にまとめる必要がなく、遊技機の設置レイアウトに制約がなくなる。さらに、遊技機設置島のレイアウトの制約もなくなる。
図１７、図１８において、ＣＵ３を取付けて設置するための取付枠（ホルダ）に記憶されたＩＤであるホルダＩＤに対応付けてホールコン９００で台番号を管理してもよい。この取付枠（ホルダ）は、ＣＵ３を新たなものに交換しても取付枠（ホルダ）自体が交換されることはなく、引き続き従前のものが使用される。このホルダＩＤに対応付けてホールコン９００で台番号を管理する場合には、新たな台番号のＰ台２に交換されたときに、ＣＵ３がそのＰ台２の台番号と取付枠（ホルダ）のホルダＩＤとを読取ってホールコン９００へ送信する（図１８の場合にはホールサーバ８０１経由でホールコン９００へ送信する）。それを受けたホールコン９００のＣＰＵは、Ｐ台２の台番号とホルダＩＤとを対応付けてＥＥＰＲＯＭに設定記憶させる。なお、Ｐ台２の台番号とホルダＩＤとを係員が手動でホールコン９００に入力するようしてもよい。また、ホールサーバ８０１は、ＣＰＵ，ＲＯＭ，ＲＡＭ、入出力インターフェイスを有しており、ＣＵ３から送信されてきた情報を入出力インターフェイスで受信する。また、図１８の場合にはＣＰＵの制御によりその受信情報を入出力インターフェイスから出力してホールコン９００へ送信する。
また、他の管理方法として次のようにしてもよい。図１７で説明したように、Ｐ台２のメインチップＩＤや払出制御チップＩＤ等のＩＤデータがＣＵ３、ホールサーバ８０１を経由して鍵管理サーバ８００へ送信される。また、Ｐ台２の遊技盤２６を交換（盤交換）されて新たな主制御基板１６に代わったときもＰ台２のメインチップＩＤ等のＩＤデータがＣＵ３、ホールサーバ８０１を経由して鍵管理サーバ８００へ送信される。ゆえに、鍵管理サーバ８００へ送信される途中でホールサーバ８０１がメインチップＩＤを取得してホールコン９００へ送信することが可能である。
そこで、図１８に示すシステムでは、送信されてきたメインチップＩＤをホールサーバ８０１がホールコン９００に送信し、ホールコン９００においてそのメインチップＩＤデータにより遊技機台番号を管理する。台交換（盤交換）した場合に、たとえば、その台交換（盤交換）された後のメインチップＩＤ等のＩＤデータと台交換（盤交換）前のメインチップＩＤ等のＩＤデータとをＣＵ３がホールコン９００に送信し、ホールコン９００のＣＰＵが、ＥＥＰＲＯＭに遊技機台番号に対応付けて記憶されているＩＤデータを台交換（盤交換）された後のＩＤデータに更新する。また、図１７のシステムでも同様に、ＣＵ３が、Ｐ台２のメインチップＩＤ等のＩＤデータをホールコン９００にも送信して、ホールコン９００がＩＤデータを利用した台番号管理を行なうようにしてもよい。具体的には、図１７、図１８において、ホールコン９００のＣＰＵが、Ｐ台２から送られてきたメインチップＩＤやセキュリティ基板のＩＤデータを受信し、そのＩＤデータに対応付けてＰ台２の台番号をホールコン９００のＥＥＰＲＯＭに設定記憶して台番号管理を行なう。
さらに、図１７および図１８に示すシステムでは、ホールコン９００が、遊技機台番号に対応付けて当該遊技機の機種も記憶した遊技機台番号の管理データを格納し、その管理データに基づいて同じ機種の遊技機に対応するカードユニットを割出し、所定のフォーマットに演算（変換）するための設定データを一括ＣＵ３へダウンロードして一括設定するように制御してもよい。「所定のフォーマット」の具体例としては、たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔの出力ピンの割当てや信号の出力長さ、さらには、Ｂｉｔ１とＢｉｔ２とを１つの出力ピンにまとめてＢｉｔ１＋Ｂｉｔ２→１ピン出力のように変換するようなフォーマットでもよい。また、図５に示した遊技状態２のＢｉｔ５〜７の予備の大当りの各ビットに関し、Ｐ台の各々のメーカが開発した機種に特有の当り態様など、特徴的な仕様（ラウンド数や時短回数等）に応じて定義付けられた出力ピンの割当てや信号の出力長さなどを設定するフォーマットでもよい。さらには、どの信号を出力するかの選択も「所定のフォーマット」に含まれる。たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔのうち、Ｂｉｔ０〜４を出力してＢｉｔ５〜７は出力しないなどである。
また、図１８に示すシステムは、ＣＵ３とホールコン９００との間に台端末装置９０１が介在しないため、ＣＵ３からの出力データのフォーマットをホールサーバ８０１がホールコン９００にマッチするフォーマットに変換してホールコン９００に送信する。なお、ホールコンメーカによる規格が統一されれば、ホールサーバ８０１でのフォーマット変換は不要になる。
ホールコン９００によるＰ台２の台番号管理は、ＣＵ３のホルダに記憶されたホルダＩＤに対応付けてホールコン９００に設定したり、またＰ台２から送られてくるメインチップＩＤやセキュリティ基板のＩＤ等により台番号管理したりしてもよい。その台番号管理データに基づいて、同じ機種のＰ台２に対応したＣＵ３群に、ホールサーバ８０１経由で一括設定データをダウンロードして一括設定してもよい。
前述したように、Ｐ台２の遊技盤２６を交換（盤交換）した場合、新たな遊技盤２６に設けられた主制御基板１６のメインチップＩＤがＣＵ３、ホールサーバ８０１、鍵管理サーバ８００に送信される。そのため、メインチップＩＤに基づいて新台の台番号を管理することで、メインチップＩＤに基づいて新台の台番号の設定変更がなされているか否かをホールコン９００が確認し、設定のし忘れの場合に報知して設定のし忘れを防止することができる。
次に、ＣＵ３からホールコン９００にデータを送信する処理について説明する。図１９は、ＣＵ制御部３２３による加算玉数の送信処理を説明するためのフローチャートである。なお、当該フローチャートによる処理は、図１７および図１８のいずれのシステムについても適用することができる。
ＣＵ３からホールコン９００に送信するデータのうち、ＣＵ制御部３２３による加算玉数について説明する。まず、ＣＵ制御部３２３は、Ｐ台２から図３に示すように加算玉数の情報を受信する（ステップＳ３５１）。
ＣＵ制御部３２３は、受信した加算玉数を所定のフォーマットに変換（たとえば、加算玉数１０個を１パルスの信号に変換）し、送信する（ステップＳ３５２）。
なお、上記Ｓ３５１で受信する情報は、加算玉数に加えてまたはそれに代えて、発射玉数（図５参照）であってもよい。さらには、Ｓ３５１で受信する情報の他の例としては、以下のものでもよい。
ａ 可変表示装置２７８の可変停止時の図柄確定回数。
ｂ 各種入賞口への玉の入賞回数。
ｂ 各種入賞口への玉の入賞回数。
ｃ 前述の図５に示した遊技台情報２や３の各Ｂｉｔ情報。
また、受信した加算玉数を所定のフォーマットに変換して出力する方法としては、前述の１０個を１パルスの信号に変換するものに限定されるものではない。たとえば、どの種類の信号をどの出力ピンに割当てるか、信号の出力長さ、さらには、複数種類の信号を１つの出力ピンにまとめて出力のように変換するような出力方式でもよい。また、図５に示した遊技状態２のＢｉｔ５〜７の予備の大当りの各ビットに関し、Ｐ台の各々のメーカが開発した機種に特有の当り態様など、特徴的な仕様（ラウンド数や時短回数等）に応じて定義付けられた出力ピンの割当てや信号の出力長さなどを設定する出力方式でもよい。さらには、「所定のフォーマット」としては、どの信号を出力するかの選択も含まれる。たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔのうち、Ｂｉｔ０〜４を出力してＢｉｔ５〜７は出力しないなどである。
また、受信した加算玉数を所定のフォーマットに変換して出力する方法としては、前述の１０個を１パルスの信号に変換するものに限定されるものではない。たとえば、どの種類の信号をどの出力ピンに割当てるか、信号の出力長さ、さらには、複数種類の信号を１つの出力ピンにまとめて出力のように変換するような出力方式でもよい。また、図５に示した遊技状態２のＢｉｔ５〜７の予備の大当りの各ビットに関し、Ｐ台の各々のメーカが開発した機種に特有の当り態様など、特徴的な仕様（ラウンド数や時短回数等）に応じて定義付けられた出力ピンの割当てや信号の出力長さなどを設定する出力方式でもよい。さらには、「所定のフォーマット」としては、どの信号を出力するかの選択も含まれる。たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔのうち、Ｂｉｔ０〜４を出力してＢｉｔ５〜７は出力しないなどである。
さらに、前述のａの図柄確定回数の場合に、所定回数（たとえば１０回）図柄が確定すれば１パルス出力するように制御し、また、ｂの玉の入賞回数の情報の場合に、所定個数（たとえば１０個）の玉が入賞すれば１パルス出力するように制御してもよい。
以上のように、Ｓ３５２により所定のフォーマットに変換する情報は種々の情報が考えられる。それら情報が所定の数（たとえば１０）に達するまでＣＵ３ではＰ台２からの定期的に送られてくる情報を累積加算し、その加算値が所定の数（たとえば１０）に達したときに１パルスを出力するとともにそれまで累積加算値をクリアし、また次の情報の累積加算を開始する。この「累積加算値のクリア」は、累積加算値から所定の数（たとえば１０）を減算してもよい。なお、この「１パルス」の信号は、シリアル信号であるため送信情報（たとえば加算玉数）が所定の数（たとえば１０）であることを示す特定のＢｉｔを「１」にしたデータで出力する。
次に、ＣＵ制御部３２３による遊技情報の処理について説明する。図２０は、ＣＵ制御部３２３による遊技情報の処理を説明するためのフローチャートである。なお、当該フローチャートによる処理は、図１７および図１８のいずれのシステムについても適用することができる。
まず、ＣＵ制御部３２３は、ＣＵ３から出力する遊技情報の出力方式即ち遊技情報を所定のフォーマットに演算（変換）して出力するための設定データについて入力があるか否かを判断する（ステップＳ３６１）。ＣＵ制御部３２３は、リモコンなどの設定手段から出力方式について入力があったと判断した場合（ステップＳ３６１：ＹＥＳ）、入力した出力方式に基づいて、ＣＵ３から出力する遊技情報についてのビット位置、出力期間、出力有無、情報の変換などの出力方式を設定する（ステップＳ３６２）。一方、ＣＵ制御部３２３は、出力方式について入力がないと判断した場合（ステップＳ３６１：ＮＯ）、ステップＳ３６２の処理をスキップして、前回設定した出力方式を利用する。
上記ステップＳ３６２で設定される出力方式は、遊技機メーカによって異なるデータ出力フォーマットの遊技機情報を、ホールコンメーカによって異なるデータ受信ファーマットに変換して、ホールコン９００に出力するためのものである。たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔの出力ピンの割当てや信号の出力長さ、さらには、Ｂｉｔ１とＢｉｔ２とを１つの出力ピンにまとめてＢｉｔ１＋Ｂｉｔ２→１ピン出力のように変換するような出力方式でもよい。また、図５に示した遊技状態２のＢｉｔ５〜７の予備の大当りの各ビットに関し、Ｐ台の各々のメーカが開発した機種に特有の当り態様など、特徴的な仕様（ラウンド数や時短回数等）に応じて定義付けられた出力ピンの割当てや信号の出力長さなどを設定する出力方式でもよい。さらには、「データ受信ファーマットの変換」としては、どの信号を出力するかの選択も含まれる。たとえば、図５に示した遊技状態２や遊技状態３の各Ｂｉｔのうち、Ｂｉｔ０〜４を出力してＢｉｔ５〜７は出力しないなどである。また、上記「ビット位置」とは、遊技状態２や遊技状態３の各Ｂｉｔをどの出力ピンから出力するかの出力ピン位置の割当てのことである。
なお、前述したリモコンなどによる出力方式の入力の代わりに、ホールコン９００から出力方式のデータをダウンロードしてＣＵ制御部３２３に記憶させるようにしてもよい。さらには、ＣＵ３に接続されているＰ台２のメーカのサーバから出力方式のデータをダウンロードしてＣＵ制御部３２３に記憶させるようにしてもよい。その場合のダウンロードの経路としては、メーカのサーバからの出力方式のデータを鍵管理サーバ８００およびホールサーバ８０１を経由してＣＵ制御部３２３にダウンロードすることが考えられる。Ｐ台２のメーカのサーバから出力方式のデータをダウンロードする場合には、当該Ｐ台２を設計製造した者がホールコン９００へ出力しようと意図する遊技情報を意図どおりにＣＵ３に設定できるため、遊技場側で設定する必要がなくなるという利点がある。
ＣＵ制御部３２３は、Ｐ台２から遊技情報（たとえば、図５に示す遊技台状態２，３）を受信したか否かを判断する（ステップＳ３６３）。ＣＵ制御部３２３は、Ｐ台２から遊技情報を受信しないと判断した場合（ステップＳ３６３：ＮＯ）、処理を終了する。一方、ＣＵ制御部３２３は、Ｐ台２から遊技情報を受信したと判断した場合（ステップＳ３６３：ＹＥＳ）、受信した遊技情報を設定した出力方式に変換する（ステップＳ３６４）。ここで、ＣＵ制御部３２３は、設定した出力方式により、ホールコン９００にマッチしたフォーマットに遊技情報を変換するので、遊技機メーカによって異なるデータ出力フォーマットの遊技機情報を、ホールコンメーカによって異なるデータ受信ファーマットに変換して、ホールコン９００に出力することができる。
具体的には、図５に示した遊技状態２や遊技状態３の各Ｂｉｔの出力ピンの割当てや信号の出力長さ等をＳ３６２で設定して、その設定にしたがってＳ３６４で変換する。また、Ｓ３６２での設定内容としては、どのＢｉｔのデータを表示器５４で表示させるかを指定するように設定してもよく、その場合には、Ｓ３６２で指定されたＢｉｔのデータを後述するＳ３６６で判定して指定されたＢｉｔのデータを表示器５４で表示させるように制御する。さらなるＳ３６２での設定内容としては、たとえば、図５に示した遊技状態２や遊技状態３において、Ｂｉｔ１とＢｉｔ２とを１つの出力ピンにまとめてＢｉｔ１＋Ｂｉｔ２→１ピン出力のように変換してもよい。
遊技情報を変換後、ＣＵ制御部３２３は、変換した遊技情報をホールコン９００に送信するために出力する（ステップＳ３６５）。ＣＵ制御部３２３は、Ｐ台２から受信した遊技情報のうち、表示器３１２で表示させる情報が含まれているか否かを判断する（ステップＳ３６６）。この判断は、具体的には、上記Ｓ３６２での設定とは別に、図５に示した遊技状態２や遊技状態３の各ＢｉｔのうちどのＢｉｔの情報を表示させるかを予めリモコンやホールコン９００等によりＣＵ３に入力設定し、その設定されたＢｉｔの情報であるか否かにより判断する。また、他の方法として、前述したように、Ｓ３６２での設定と同時にどのＢｉｔの情報を表示させるかを入力設定した場合には、その設定にしたがって表示させる情報を判断する。
ＣＵ制御部３２３は、図１に示す表示器３１２で表示させる情報が含まれていると判断した場合（ステップＳ３６６：ＹＥＳ）、遊技情報を表示器３１２で表示する制御を行なう（ステップＳ３６７）。一方、ＣＵ制御部３２３は、表示器３１２で表示させる情報が含まれていないと判断した場合（ステップＳ３６６：ＮＯ）、処理を終了する。表示器３１２で表示させる情報とは、たとえば、遊技台情報２中の大当り３や大当り５、遊技台情報３中の確変中や時短中などが考えられる。
＜共通会員カード＞
本実施例の遊技用システムでは、図２１に示すように、共通会員用記録媒体であるＩＣカードから成る共通会員カード１Ａを所持する会員遊技者が、その１枚の共通会員カード１Ａを用いて複数の各遊技場Ａ〜Ｃにて会員登録を行なえるようになっている。なお、各遊技場Ａ〜Ｃのシステム構成は同一となっているので、遊技場Ａを例として本実施例のシステム構成を説明する。
本実施例の遊技場Ａでは、複数配置された遊技島に並設される遊技機としてのＰ台２に対して１対１に設置されるＣＵ３と、当該ＣＵ３にて使用される会員用記録媒体である共通会員カード１Ａ、並びにプリペイドカードであるビジターカードに記録されている遊技用価値であるプリペイド度数（以下、単に度数とする場合がある）の管理等を行なうシステムコントローラ１００と、共通会員カード１Ａを用いて会員登録を行なうための会員登録機１０と、会員遊技者の貯蓄玉数（会員情報に含まれる貯玉数）を管理する貯玉サーバ１１０と、セキュリティ上の管理を行なうホールサーバ８０１とが互いに通信ケーブル８を介して双方向にデータ通信可能に接続されている。ホールサーバ８０１は、さらに前述した鍵管理サーバ８００に接続されている。
本実施例のＣＵ３には、前面に設けられたカード挿入口に挿入された共通会員カード１Ａ、遊技場会員カードやビジターカードに記憶された（会員）カードＩＤやプリペイド度数等の記憶データを読み出すカードリーダライタ３’が内蔵されており、該カードリーダライタ３’により読み出されたプリペイド度数や、共通会員カード１Ａや遊技場会員カードに記憶されている持玉を使用して遊技玉を貸し出す玉貸処理や、共通会員カード１Ａや遊技場会員カードで特定される貯玉の少なくとも一部を遊技玉として払い出す再プレイ処理等が実施される。
なお、ＣＵ３からは、当該ＣＵ３に共通会員カード１Ａが挿入されたことを示す会員カードＩＤを含む会員カード受付け通知や、対応するＰ台２における遊技関連情報等の各種情報が送信され、システムコントローラ１００からは、各共通会員カード１Ａや各遊技場会員カード、各ビジターカードに残存するプリペイド度数等の情報が送信される。
また、貯玉サーバ１１０には、当該遊技場において会員登録した会員遊技者に関する会員情報（当該会員遊技者の遊技にて発生する会員遊技関連情報や、会員遊技者の氏名や住所等の個人情報である会員属性情報を含む）を収集、管理する会員管理コンピュータ１２０が通信ケーブル９を介して双方向にデータ通信可能に接続されている。更に、会員管理コンピュータ１２０は、専用通信回線１１を介して外部機関の貯玉補償センタに設置されている貯玉補償サーバ１３０に双方向にデータ通信可能に接続されている。この貯玉補償サーバ１３０は、会員管理コンピュータ１２０を介して遊技場Ａの貯玉サーバ１１０と通信可能になっている。また、会員管理コンピュータ１２０は、貯玉サーバ１１０を介して、各ＣＵ３や会員登録機１０やシステムコントローラ１００と通信可能になっている。
なお、本実施例では、会員管理コンピュータ１２０と貯玉サーバ１１０とを個別のコンピュータとした形態を例示しているが、本発明はこれに限定されるものではなく、これら会員管理コンピュータ１２０と貯玉サーバ１１０とを単一のコンピュータ（サーバコンピュータ）にて形成するようにしても良い。
また、本実施例では、会員登録を後述する受付カウンタにて実施できるようにするために、会員管理コンピュータ１２０とは個別に、共通会員カード１Ａに記憶されている会員カードＩＤや遊技場会員ＩＤを読み出すためのカードリーダライタ１０’を備える会員登録機１０を用いた形態を例示しているが、本発明はこれに限定されるものではなく、これら会員登録機１０と会員管理コンピュータ１２０とを単一のコンピュータにて形成するようにしても良い。
図２１に示すように、貯玉補償サーバ１３０は、後述するように、各遊技場の貯玉サーバ１１０が有する貯蓄玉（貯玉）数管理テーブル（図２３参照）と同一のテーブルを有し、各遊技場の貯玉サーバ１１０の貯蓄玉数管理テーブルが更新されるとともに、貯玉補償サーバ１３０の貯蓄玉数管理テーブルも構成されるようになっており、何らかの不具合等によって各遊技場における貯蓄玉数の管理データが損傷しても、これら貯蓄玉数の管理データを外部機関としての貯玉補償センタが保証できるようになっている。
更に、遊技場Ａの貯玉サーバ１１０は、専用通信回線１２を介して共通会員カード１Ａのカード管理会社に設置されている管理サーバ１４０に双方向にデータ通信可能に接続されている。この管理サーバ１４０は、貯玉サーバ１１０を介して遊技場Ａのシステムコントローラ１００、会員登録機１０、並びに会員管理コンピュータ１２０と通信可能になっている。なお、カード管理会社の管理サーバ１４０では、後述するように、各遊技場Ａ〜Ｃにて会員登録を行なった会員遊技者に関する情報を登録管理できるようになっている。
また、カード管理会社の管理サーバ１４０は、インターネットに接続された図示しない通信部を備えており、インターネットへの接続機能を有する会員遊技者が操作可能な情報端末であるノートパソコン１５Ａや携帯電話１６Ａから、該インターネットを介してアクセス可能とされるサイトサーバの機能を有する。
更に、前述したＣＵ３は、対応するＰ台２と直接接続されており、ＣＵ３と対応するＰ台２との間で各種信号の送受が可能とされているとともに、対応するＰ台２の遊技に使用される遊技玉数や該遊技玉数を計数した計数玉数などが送受信されている。
そして、これら入力された各信号に基づいて遊技関連情報が会員管理コンピュータ１２０に送信されることで、該会員管理コンピュータ１２０において、各Ｐ台２における遊技関連情報を把握できるとともに、対応するＣＵ３において共通会員カードの受付け中に生じた遊技関連情報を、当該会員遊技者の遊技にて発生した会員遊技関連情報である遊技履歴として管理するようになっている。
また、共通会員カード１Ａが備えるＩＣチップには、各共通会員カード１Ａを個々に識別可能とするための会員カードＩＤ（記録媒体識別情報）と、各会員遊技者を個々に識別可能とするために、各遊技場において各会員に固有に付与された遊技場会員ＩＤとが記憶されるようになっている。なお、共通会員カード１Ａには、当該遊技場Ａにおいて発行された遊技場会員ＩＤのみならず、他の遊技場Ｂ〜Ｃにおいて発行された遊技場会員ＩＤも記憶されるようになっており、会員遊技者は、１枚の共通会員カード１Ａによって、各遊技場Ａ〜Ｃにおいて会員登録を行なえるようになっている。ここで、遊技場会員カードが備えるＩＣチップには、各会員遊技者を個々に識別可能とするために、各遊技場において各会員に固有に付与された遊技場会員ＩＤが記憶されているが、会員カードＩＤ（記録媒体識別情報）は記憶されるようにはなっていない。
図２２に示すように、共通会員カード１Ａが備えるＩＣチップの記憶領域は、カード管理会社用の記憶領域や各遊技場Ａ〜Ｃの固有に割り当てられた記憶領域が設定されている。そして、後述するように、遊技場Ａは、共通会員カード１Ａにおける自店に対して割り当てられた記憶領域に、遊技場Ａが独自に発行する遊技場会員ＩＤを、会員登録機１０やＣＵ３に設けられたカードリーダライタを用いて書き込むことができるようになっている。なお、共通会員カード１ＡのＩＣチップにおける各遊技場Ａ〜Ｃに割り当てられた記憶領域には、各遊技場Ａ〜Ｃにおける独自の記憶データが記憶できるようになっているが、未使用の状態では、「０」などの空データを示すＮＵＬ値が初期値記憶データとして記憶されている。
貯玉サーバ１１０が備える記憶装置には、図２３に示す貯蓄玉数管理テーブルが記憶されている。なお、この貯蓄玉数管理テーブルには、図２３に示すように、会員遊技者の遊技場会員ＩＤに対応付けて、前記玉計数器４０にて計数されて再度の遊技に使用可能とされた貯蓄玉数が記憶されている。
会員管理コンピュータ１２０が備える記憶装置には、図２４に示すように、遊技場会員情報テーブル（図２４（ａ）参照）と、会員別遊技履歴テーブル（図２４（ｂ）参照）とが記憶されている。なお、遊技場会員情報テーブルには、図２４（ａ）に示すように、当該遊技場Ａにおいて会員登録した会員遊技者を識別可能な各遊技場会員ＩＤに対応付けて、本人確認に使用される暗証番号と、各会員遊技者の氏名（名字並びに名前）、性別、年齢、誕生日、職業、住所、電子メールアドレスからなる会員属性情報（会員情報）とが登録されている。
また、会員別遊技履歴テーブルには、図２４（ｂ）に示すように、各会員遊技者の遊技場会員ＩＤに対応付けて、来店ポイントと、来店回数と、会員遊技者がＣＵ３に共通会員カード１Ａを挿入してから遊技を終えて当該共通会員カード１Ａを取り出すまでに実施した遊技を１回の遊技として、最近１０回の遊技履歴（会員情報）が記憶されている。これら遊技履歴として具体的には、遊技場会員ＩＤ毎に、来店日、遊技を実施したＰ台２の台番号、遊技の開始時間（共通会員カード１Ａの挿入時間）、遊技の終了時間（共通会員カード１Ａの返却時間）、開始時間と終了時間との差である遊技時間、始動回数、大当回数、確変回数、会員遊技者が遊技に消費した金額である売上金額、会員遊技者が遊技にて獲得することで遊技場が該会員遊技者に対して提供する景品と等価な金額である支出金額（最小数は１００円単位）、これら売上金額から支出金額を差し引いた収支金額、遊技場の勝敗とが記憶されている。図２４（ｂ）に示す会員別遊技履歴テーブルは、会員管理コンピュータ１２０のみに記憶されるだけでもよいが、会員カードＩＤに対応付けて管理サーバ１４０に記憶してもよい。
また、本実施例の貯玉サーバ１１０は、ＣＵ３における再プレイ操作に基づいて該ＣＵ３から送信される貯玉使用要求の受信に基づいて、会員管理コンピュータ１２０に対して、当該貯玉使用要求に含まれる暗証番号が、当該貯玉使用要求に含まれる遊技場会員ＩＤに対応して前記遊技場会員情報テーブルに記憶されている暗証番号と一致するか否かを照会し、当該暗証番号が一致した場合において、前記貯蓄玉数管理テーブルに当該遊技場会員ＩＤに対応付けて記憶されている貯蓄玉数の遊技への再使用を許諾する貯蓄玉数使用許諾処理を実施し、該貯蓄玉数の遊技への再使用に供された貯蓄玉数の大きさを該貯蓄玉数の大きさから減算更新する。なお、この際、所定の手数料分の貯蓄玉数を減算更新するようにしても良い。
また、本実施例の貯玉サーバ１１０は、ＣＵ３から送信される計数玉数の受信に基づいて、当該計数玉数とともに送信される遊技場会員ＩＤに対応して貯蓄玉数管理テーブルに記憶されている貯蓄玉数の大きさに、当該受信した計数玉数の大きさを加算更新する貯蓄玉数更新処理を実施する。更に、貯蓄玉数管理テーブルの更新があった場合に、貯玉サーバ１１０は、更新後の新たな貯蓄玉数の大きさと遊技場会員ＩＤとを含む貯玉情報を貯玉補償センタの貯玉補償サーバ１３０に送信する貯玉情報送信処理を実施する。
また、本実施例の会員管理コンピュータ１２０は、ＣＵ３に新たに共通会員カード１Ａが受付けられたことに基づいて、当該ＣＵ３から送信される共通会員カード受付け通知の受信に基づき、当該共通会員カード受付け通知に含まれる新たに受付けた共通会員カード１Ａから読み出した遊技場会員ＩＤに対応する会員別遊技履歴テーブルの今回のデータを前回のデータに、前回のデータを２回前のデータというように、それぞれの遊技履歴の回数の更新を実施するともに、今回の遊技履歴への記憶（更新）を開始して、当該会員遊技者の遊技において発生する会員遊技関連情報の記憶し、ＣＵ３における返却操作に基づいて、ＣＵ３から送信される返却通知に記憶を開始した遊技場会員ＩＤが含まれる場合において、今回の遊技履歴への記憶（更新）を終了し、当該遊技単位における勝敗を判定して記憶する処理を実施する。
なお、今回の遊技履歴への記憶（更新）を開始に際しては、会員管理コンピュータ１２０からシステムコントローラ１００に対して当該更新する遊技履歴に対応する遊技場会員ＩＤを含む使用度数情報出力要求を送信することで、システムコントローラ１００から、当該送信した使用度数情報出力要求に含まれる遊技場会員ＩＤが記録された共通会員カード１Ａからプリペイド度数の使用があった場合に、該使用度数の情報が送信されてくることで、遊技履歴の売上金額への加算更新が実施されるようになっている。
また、本実施例の会員管理コンピュータ１２０は、後述するように、会員登録機１０において、新規の会員登録を実施するための所定操作がなされた場合に、会員登録画面を会員登録機１０の表示装置に表示して、新たに会員登録する会員遊技者に関する会員属性情報の入力を受付ける会員属性情報入力処理を実施し、遊技場会員情報テーブルに記憶された遊技場会員ＩＤのうち、未使用の遊技場会員ＩＤを当該新規会員遊技者に対して付与し、当該遊技場会員ＩＤに対応付けて、会員登録画面にて受付けた会員属性情報を遊技場会員情報テーブルに記憶する会員属性情報記憶処理を実施する。
図２５に示すように、カード管理会社の管理サーバ１４０が備える記憶装置には、共通会員情報テーブル（図２５（ａ）参照）と、登録済遊技場テーブル（図２５（ｂ）参照）と、遊技場情報テーブル（図２５（ｃ））と、１次関連会員情報テーブル（図２５（ｄ））と、２次関連会員情報テーブル（図２５（ｅ））とが記憶されている。なお、共通会員情報テーブルには、図２５（ａ）に示すように、各共通会員カード１Ａを個々に識別可能な会員カードＩＤ毎に対応付けて、本人確認に使用される暗証番号と、各会員遊技者の氏名（名字並びに名前）、性別、年齢、誕生日、職業、住所、電子メールアドレスからなる会員属性情報とが登録されている。なお、本実施例では、共通会員情報テーブルにおいて暗証番号も管理しているが、本発明はこれに限定されるものではなく、これら暗証番号は、個々の遊技場のみで個別に管理することで、個々の遊技場で異なる暗証番号となるようにしても良い。
また、本実施例の登録済遊技場テーブルには、図２５（ｂ）に示すように、各会員カードＩＤに対応付けて、当該会員カードＩＤから特定される会員遊技者が会員登録を行なった遊技場の遊技場ＩＤ（遊技場情報）が全て記憶されている。これら登録済遊技場テーブルへの遊技場ＩＤの登録は、後述するように、各遊技場に設置されている会員登録機１０または会員管理コンピュータ１２０から会員属性情報登録要求または会員属性情報送信要求とともに送信されてきた会員カードＩＤに対応付けて当該登録済遊技場テーブルに記憶されている遊技場ＩＤに、当該送信がなされた遊技場の遊技場ＩＤが含まれていない場合に、当該遊技場の遊技場ＩＤを当該会員遊技者が登録を行なった遊技場として登録済遊技場テーブルに登録される。
また、本実施例の遊技場情報テーブルには、図２５（ｃ）に示すように、各遊技場の遊技場識別子（遊技場Ａ、遊技場Ｂ、…）と遊技場ＩＤとに対応付けて、当該遊技場の遊技場名や、所在地が記憶されていることにより、遊技場ＩＤから当該遊技場の遊技場名や所在地等の情報を特定できるようになっている。
また、本実施例の１次関連会員情報テーブルには、図２５（ｄ）に示すように、各会員カードＩＤに対応付けて、当該会員カードＩＤから特定される会員遊技者と所定の関連性を持つ１次関連会員遊技者（以下「フレンド」ともいう）が全て記憶されている。本実施例において、「フレンド」は、当該会員カードＩＤから特定される会員遊技者が他の会員遊技者の中から選択したことに応じて登録される。
また、本実施例の２次関連会員情報テーブルには、図２５（ｅ）に示すように、各会員カードＩＤに対応付けて、当該会員カードＩＤから特定される会員遊技者と所定の関連性を持つ２次関連会員遊技者（以下「仲良しフレンド」ともいう）が全て記憶されている。本実施例において、「仲良しフレンド」は、当該会員カードＩＤから特定される会員遊技者が自らの「フレンド」の中から選択したことに応じて登録される。したがって、本実施例において、「仲良しフレンド」を登録するためには、まず他の会員遊技者の中から「フレンド」を選択して１次的に登録し、１次的に登録された「フレンド」の中から「仲良しフレンド」を２次的に登録する必要がある。なお、「フレンド」および「仲良しフレンド」の登録については後に詳述する。
次に、新規に共通会員カード１Ａを発行して会員登録を受付ける場合の会員登録機１０と会員管理コンピュータ１２０と管理サーバ１４０との処理状況について図２６を参照して説明する。
先ず、各遊技場Ａ〜Ｃのいずれの店舗でも会員登録を行なっていない遊技者が遊技場Ａに来場し、遊技場Ａの会員登録を行なうものとする（図２１参照）。この遊技者は未だ共通会員カード１Ａを所持（所有）しておらず、遊技場Ａに来場した際に、会員登録機１０が設置されている受付カウンタに出向く。そこで、会員登録の申込用紙に氏名や住所等の個人情報である会員属性情報を記入して店員に渡す。そして、遊技者から申込用紙を受け取った店員は、未使用（未発行）の共通会員カード１Ａを会員登録機１０のカードリーダライタ１０’にセットするとともに、会員登録機１０に会員属性情報を入力する。
なお、本実施例では、店員が会員登録機１０を操作して会員属性情報を入力するようになっているが、来場した遊技者が自由に操作できる入力端末を遊技場内に設置して、これらの端末を会員登録機１０に通信可能に接続し、遊技者が入力端末を用いて入力した会員属性情報を会員登録機１０に送信することで、会員登録機１０が会員属性情報を取得できる構成であってもよい。
また、会員登録機１０は、会員属性情報の入力を受付ける処理を行なうとともに、カードリーダライタ１０’に挿入された共通会員カード１ＡのＩＣチップにおいてカード管理会社用の記憶領域に記憶された会員カードＩＤの読み出し処理を行なう（図２２参照）。そして、会員登録機１０は、読み出した会員カードＩＤと当該遊技場Ａの遊技場ＩＤと入力された会員属性情報とを含む会員属性情報登録要求をカード管理会社の管理サーバ１４０に送信する処理を行なう。
ここで、カード管理会社の管理サーバ１４０は、遊技場Ａの会員登録機１０から受信した会員属性情報登録要求に含まれる会員カードＩＤを参照し、共通会員情報テーブルにおける当該会員カードＩＤに対応付けられた氏名や住所等の項目に、受信した会員属性情報登録要求に含まれる会員属性情報である会員遊技者の氏名や住所等を登録する処理を行なう。更に、管理サーバ１４０は、受信した会員属性情報登録要求に含まれる遊技場ＩＤを当該会員カードＩＤに対応付けて登録済遊技場テーブルに登録する処理を行なう。
さらに会員登録機１０は、会員属性情報を含む遊技場新規会員情報を会員管理コンピュータ１２０に送信する処理を行なう。ここで、会員管理コンピュータ１２０は、遊技場会員情報テーブルを参照し、未使用の遊技場会員ＩＤの中から所定の遊技場会員ＩＤを決定し、この決定した遊技場会員ＩＤに対応付けられた氏名や住所等の項目に、受信した遊技場新規会員情報に含まれる会員属性情報である会員遊技者の氏名や住所等を登録する処理を行なう。そして、決定した遊技場会員ＩＤを会員登録機１０に送信する処理を行なう。なお、会員管理コンピュータ１２０は、決定した遊技場会員ＩＤを貯玉サーバ１１０にも送信して、該貯玉サーバ１１０に決定した遊技場会員ＩＤを登録させるとともに、該遊技場会員ＩＤに対応する貯玉数に初期値である「０」を記憶させる。
そして会員登録機１０は、会員管理コンピュータ１２０から受信した遊技場会員ＩＤを、共通会員カード１ＡのＩＣチップにおける遊技場Ａ用の記憶領域（図２２参照）に書き込む処理を行なう。そして、店員は、会員登録機１０から共通会員カード１Ａを取り外し、この新規な共通会員カード１Ａを遊技者に手渡すようにし、遊技場Ａにおける会員登録を完了することで、該共通会員カード１Ａを当該遊技場Ａにて使用することが可能となる。
なお、これら共通会員カード１Ａを手渡す際、例えば、当該遊技者が所有している携帯電話機の電話番号やＩＤ（ＳＩＭコード）や免許証番号等を入力して登録しておくことで、当該遊技者が複数の共通会員カード１Ａの発行を受けようとしたときに、電話番号やＩＤ（ＳＩＭコード）や免許証番号が登録済みであるか否かを判定し、登録済みである場合には、発行を行なわないようにすることで、複数の共通会員カード１Ａが同一人物に発行されてしまうことを防止できるようにしても良い。
また、本実施例では、会員管理コンピュータ１２０が新たに当該遊技場の会員となる遊技者に付与する遊技場会員ＩＤを決定して、該決定した遊技場会員ＩＤを共通会員カードに書き込み記憶するようにしているが、本発明はこれに限定されるものではなく、例えば、予め共通会員カード１Ａに記憶されている会員カードＩＤを当該遊技場の遊技場会員ＩＤとして使用するようにしても良く、この場合において会員登録機１０は、会員カードＩＤを含む遊技場新規会員情報を会員管理コンピュータ１２０に送信し、会員管理コンピュータ１２０は、遊技場新規会員情報に含まれる会員カードＩＤと会員属性情報とを対応付けて遊技場会員情報テーブルに登録すれば良い。なお、このようにする場合にあっては、共通会員カード１Ａに個々の遊技場に割り当てられる記憶領域を設けなくても良い。
また、遊技場Ａ以外の遊技場Ｂ〜Ｃにおいて、共通会員カード１Ａを所持（所有）してない遊技者が会員登録を行なった場合も、上記した遊技場Ａの場合と同様な登録処理が行なわれ、遊技者は最初に会員登録を行なった遊技場Ｂ〜Ｃにて新規な共通会員カード１Ａを受け取るようになっている。
なお、本実施例では、カード管理会社の管理サーバ１４０の共通会員情報テーブルにおける会員カードＩＤに対応付けられた氏名や住所等の項目に、受信した会員属性情報登録要求に含まれる会員属性情報である会員遊技者の氏名や住所等を登録する処理と、遊技場Ａの会員管理コンピュータ１２０の遊技場会員情報テーブルにおける遊技場会員ＩＤに対応付けられた氏名や住所等の項目に、受信した遊技場新規会員情報に含まれる会員属性情報である会員遊技者の氏名や住所等を登録する処理と、を並行して処理できるようになっているが、その他の処理態様であってもよい。
例えば、カード管理会社の管理サーバ１４０の共通会員情報テーブルにて会員属性情報の登録処理が完了した時点で、その登録完了情報が遊技場Ａの会員管理コンピュータ１２０に送信され、会員管理コンピュータ１２０が登録完了情報を受信したことに基づいて、遊技場会員情報テーブルにて会員属性情報の登録処理を行なうようにしてもよい。また、先に、会員管理コンピュータ１２０の遊技場会員情報テーブルにて会員属性情報の登録処理を行なうようにし、その登録処理が完了した時点で、登録完了情報がカード管理会社の管理サーバ１４０に送信され、管理サーバ１４０が登録完了情報を受信したことに基づいて、共通会員情報テーブルにて会員属性情報の登録処理を行なうようにしてもよい。
次に、共通会員カード１Ａを所持している遊技者から会員登録を受付ける場合の会員登録機１０と会員管理コンピュータ１２０と管理サーバ１４０との処理状況について図２７を参照して説明する。
先ず、遊技場Ａ以外の遊技場Ｂ〜Ｃのいずれかの店舗で既に会員登録を完了している遊技者が遊技場Ａに来場し、遊技場Ａの会員登録を行なうものとする（図２１参照）。この遊技者は、既に最初に会員登録を行なった遊技場にて発行された共通会員カード１Ａを所持（所有）した状態で、会員登録機１０が設置されている受付カウンタに出向いて、会員登録したい旨を店員伝えるとともに、自身が所持している共通会員カード１Ａを店員に手渡す。店員は、受け取った共通会員カード１Ａを会員登録機１０のカードリーダライタ１０’に挿入する。
会員登録機１０は、カードリーダライタ１０’に挿入された共通会員カード１ＡのＩＣチップにおける遊技場Ａ用の記憶領域に記憶された記憶データとカード管理会社用の記憶領域に記憶された会員カードＩＤの読み出し処理を行なう（図２２参照）。ここで、遊技場Ａにおいて未だ会員登録がなされていない場合には、遊技場Ａ用の記憶領域に前述したＮＵＬ値が記憶データとして記憶されており、遊技場Ａにおいて既に会員登録がなされている場合には、当該遊技場Ａで独自に付与された遊技場会員ＩＤが記憶されていることとなる。
更に、会員登録機１０は、共通会員カード１Ａから読み出した記憶データを会員管理コンピュータ１２０に送信する処理を行なう。このカードの記憶データを受信した会員管理コンピュータ１２０は、遊技場会員情報テーブルを参照して共通会員カード１Ａの遊技場Ａ用の記憶領域から読み出したデータが遊技場会員ＩＤとして登録されているか否かを判定する処理を行なう。そして、会員管理コンピュータ１２０は、その判定結果（登録有り・登録無し）を会員登録機１０に返信する処理を行なう。
そして、会員管理コンピュータ１２０から判定結果を受信した会員登録機１０は、この判定結果により登録有りと判定された場合（記憶データが遊技場会員ＩＤである場合）に、登録済の旨を表示装置に表示する。この場合には、店員は、会員登録機１０から共通会員カード１Ａを取り外し、共通会員カード１Ａを遊技者に返却するとともに、既に遊技場Ａにおける会員登録が済んでいることを伝える。
また、会員管理コンピュータ１２０から判定結果を受信した会員登録機１０は、この判定結果により登録無しと判定された場合（記憶データがＮＵＬ値である場合等）に、読み出した会員カードＩＤと当該遊技場Ａの遊技場ＩＤとを含む会員属性情報送信要求をカード管理会社の管理サーバ１４０に送信する処理を行なう。
ここで、カード管理会社の管理サーバ１４０は、遊技場Ａの会員登録機１０から受信した会員属性情報送信要求に含まれる会員カードＩＤを照合し、該会員カードＩＤが登録されている場合には、共通会員情報テーブルにおける当該会員カードＩＤに対応付けられて登録されている氏名や住所等の会員属性情報を会員登録機１０に送信する処理を行なう。更に、管理サーバ１４０は、受信した会員属性情報送信要求に含まれる遊技場ＩＤを当該会員カードＩＤに対応付けて登録済遊技場テーブルに登録する処理を行なう。一方、該会員カードＩＤが共通会員情報テーブルに登録されていない場合には、会員属性情報の登録がない旨を示す会員属性情報未登録通知を返信して、会員登録機１０を、会員属性情報の受付け状態に移行させる。なお、これら会員属性情報が受付けられた場合の流れは、新規に共通会員カード１Ａを発行する場合の上述した流れと同じである。
また、カード管理会社の管理サーバ１４０から会員属性情報を受信した会員登録機１０は、受信した会員属性情報を含む遊技場新規会員情報を会員管理コンピュータ１２０に送信する処理を行なう。ここで、会員管理コンピュータ１２０は、遊技場会員情報テーブルを参照し、未使用の遊技場会員ＩＤの中から所定の遊技場会員ＩＤを決定し、この決定した遊技場会員ＩＤに対応付けられた氏名や住所等の項目に、受信した遊技場新規会員情報に含まれる会員属性情報である会員遊技者の氏名や住所等を登録する記録媒体利用登録処理を行なう。そして、決定した遊技場会員ＩＤを会員登録機１０に送信する処理を行なう。なお、会員管理コンピュータ１２０は、決定した遊技場会員ＩＤを貯玉サーバ１１０にも送信して、該貯玉サーバ１１０に決定した遊技場会員ＩＤを登録させるとともに、該遊技場会員ＩＤに対応する貯玉数に初期値である「０」を記憶させる。
更に、会員登録機１０は、カードリーダライタ１０’により、会員管理コンピュータ１２０から受信した遊技場会員ＩＤを共通会員カード１ＡのＩＣチップにおける遊技場Ａ用の記憶領域（図２２参照）に書き込む処理を行なう。そして、店員は、カードリーダライタ１０’から共通会員カード１Ａを取り外し、この共通会員カード１Ａを遊技者に手渡すようにし、遊技場Ａにおける会員登録を完了する。
このように、本実施例では、共通会員カード１Ａを所持している場合も、受付カウンタにおいて会員登録を実施するようにしているが、本発明はこれに限定されるものではなく、例えば、以下に示すように、ＣＵ３において共通会員カード１Ａを使用して会員登録を実施するようにしても良く、この場合のＣＵ３と会員管理コンピュータ１２０と管理サーバ１４０との処理状況について図２８を参照して説明する。
先ず、遊技場Ａ以外の遊技場Ｂ〜Ｃのいずれかの店舗で既に会員登録を完了している遊技者が遊技場Ａに来場したものとする（図２１参照）。この遊技者は、既に最初に会員登録を行なった遊技場にて発行された共通会員カード１ＡをＣＵ３に挿入する。
そして、ＣＵ３は、挿入された共通会員カード１ＡのＩＣチップにおける遊技場Ａ用の記憶領域に記憶された記憶データとカード管理会社用の記憶領域に記憶された会員カードＩＤをカードリーダライタ３’により読み出す読み出し処理を行なう（図２２参照）。ここで、遊技場Ａにおいて未だ会員登録がなされていない場合には、遊技場Ａ用の記憶領域に前述したＮＵＬ値が記憶データとして記憶されており、遊技場Ａにおいて既に会員登録がなされている場合には、当該遊技場Ａで独自に付与された遊技場会員ＩＤが記憶されていることとなる。
更に、ＣＵ３は、共通会員カード１Ａから読み出した記憶データを会員管理コンピュータ１２０に送信する処理を行なう。このカードの記憶データを受信した会員管理コンピュータ１２０は、遊技場会員情報テーブルを参照して共通会員カード１Ａの遊技場Ａ用の記憶領域から読み出したデータが遊技場会員ＩＤとして登録されているか否かを判定する処理を行なう。そして、会員管理コンピュータ１２０は、その判定結果（登録有り・登録無し）をＣＵ３に返信する処理を行なう。
そして、会員管理コンピュータ１２０から判定結果を受信したＣＵ３は、この判定結果により登録有りと判定された場合（記憶データが遊技場会員ＩＤである場合）に、前述した貯玉使用要求を貯玉サーバ１１０に送信し、当該ＣＵ３にて貯玉を使用できるようにする。
また、会員管理コンピュータ１２０から判定結果を受信したＣＵ３は、この判定結果により登録無しと判定された場合（記憶データがＮＵＬ値である場合等）に、該ＣＵ３が備える表示装置に「お客様は当店にて会員登録がなされておりません。当店にて会員登録を行ないますか？」等の表示を行ない、遊技者に対して当該遊技場Ａの会員登録を行なうか否かを問い合わせる処理を行なう。
ここで、遊技者が会員登録をしない旨の選択をした場合には、ＣＵ３から共通会員カード１Ａを排出するカード返却処理を行なう。また、遊技者が会員登録する旨の選択をした場合には、読み出した会員カードＩＤを含む会員登録要求を会員管理コンピュータ１２０に送信する処理を行なう。
なお、本実施例では、遊技者が会員登録をしない旨の選択をした場合には、共通会員カード１Ａを返却する形態を例示しているが、本発明はこれに限定されるものではなく、これら共通会員カード１Ａを会員カードではなくビジターカードとして受付けてビジターカードとして使用できるようにしても良く、この場合にあっては、共通会員カード１Ａの記憶領域に、ＣＵ３にて計数した持玉数を記憶するようにしても良い。
また、これら共通会員カード１Ａがビジターカードとして使用された場合において、該共通会員カード１Ａが挿入されてから返却されるまでの遊技履歴を、会員カードＩＤに対応付けて会員属性なしの遊技履歴として記憶しておき、後に当該共通会員カード１Ａを所持する遊技者が会員登録した場合には、該会員の遊技履歴として、当該共通会員カード１Ａの会員カードＩＤに対応付けて記憶されている会員属性なしの遊技履歴を引き継ぐようにしても良い。
そして、ＣＵ３から会員登録要求を受信した会員管理コンピュータ１２０は、受信した会員登録要求に含まれる会員カードＩＤと当該遊技場Ａの遊技場ＩＤとを含む会員属性情報送信要求をカード管理会社の管理サーバ１４０に送信する処理を行なう。
ここで、カード管理会社の管理サーバ１４０は、遊技場Ａの会員管理コンピュータ１２０から受信した会員属性情報送信要求に含まれる会員カードＩＤを照合し、該会員カードＩＤが登録されている場合には、共通会員情報テーブルにおける当該会員カードＩＤに対応付けられて登録されている氏名や住所等の会員属性情報を会員管理コンピュータ１２０に送信する処理を行なう。更に、管理サーバ１４０は、受信した会員属性情報送信要求に含まれる遊技場ＩＤを当該会員カードＩＤに対応付けて登録済遊技場テーブルに登録する処理を行なう。
一方、会員カードＩＤが共通会員情報テーブルに登録されていない場合には、会員属性情報の登録がない旨を示す会員属性情報未登録通知を会員管理コンピュータ１２０に返信することで、会員管理コンピュータ１２０は、ＣＵ３に対してエラー報知指示と返却指示とを送信して、エラーを報知させるとともに受付け中の共通会員カード１Ａを返却させる。なお、この場合、例えば、会員登録機１０の場合のように、ＣＵ３を会員属性情報の受付け状態に移行させて、会員属性情報の受付けを実施させるようにしても良い。このように、会員属性情報の受付けを実施させた場合の流れは、会員登録機１０において新規に共通会員カード１Ａを発行する場合の上述した流れと同じとすれば良い。
また、カード管理会社の管理サーバ１４０から会員属性情報を受信した会員管理コンピュータ１２０は、遊技場会員情報テーブルを参照し、未使用の遊技場会員ＩＤの中から所定の遊技場会員ＩＤを決定し、この決定した遊技場会員ＩＤに対応付けられた氏名や住所等の項目に、受信した会員属性情報である会員遊技者の氏名や住所等を登録する記録媒体利用登録処理を行なう。そして、決定した遊技場会員ＩＤをＣＵ３に送信する処理を行なう。なお、会員管理コンピュータ１２０は、決定した遊技場会員ＩＤを貯玉サーバ１１０にも送信して、該貯玉サーバ１１０に決定した遊技場会員ＩＤを登録させるとともに、該遊技場会員ＩＤに対応する貯玉数に初期値である「０」を記憶させる。
更に、ＣＵ３は、会員管理コンピュータ１２０から受信した遊技場会員ＩＤを、共通会員カード１ＡのＩＣチップにおける遊技場Ａ用の記憶領域（図２２参照）に書き込む処理を行ない、遊技場Ａにおける会員登録を完了する。
このように本実施例の遊技用システムでは、共通会員カード１Ａを所持している遊技者が会員となっていない遊技場Ａにおいて新たに会員になる際においては、カード管理会社の管理サーバ１４０において管理されている該遊技者の会員属性情報が、共通会員カード１Ａに記録されている会員カードＩＤに基づいて取得されて会員情報として登録されるため、これら会員属性情報を新たに会員になる毎に記入したり入力したりする等の当該遊技者の手間を著しく省くことができ、会員登録が非常に簡素化されるばかりか、複数の会員カードを携行する必要もないので、他の遊技場において既に会員登録している遊技者の他の遊技場における会員化を促進させることができる。
また、遊技者は、会員登録機１０が設置されているいずれか１の遊技場にて共通会員カード１Ａの新たな発行を受けて会員となることができるとともに、該会員の会員属性情報をカード管理会社の管理サーバ１４０において迅速に管理できる。
また、会員登録機１０またはＣＵ３において共通会員カード１Ａを受付けた際に、会員管理コンピュータ１２０が遊技場会員情報テーブルを参照してカードの記憶データが遊技場会員ＩＤとして登録されているか否かを判定する処理を行なうことで、遊技者が来場した遊技場Ａの会員であると判定されたときには、カード管理会社の管理サーバ１４０に対して会員カードＩＤが送信されて会員属性情報が無駄に取得されることがないので、会員管理コンピュータ１２０と管理サーバ１４０との間の通信負荷を低減できるとともに、管理サーバ１４０における処理負荷も低減できる。
次に、会員遊技者が、情報端末であるノートパソコン１５Ａや携帯電話１６Ａを用いて自分が会員登録を行なった各遊技場Ａ〜Ｃを把握する場合や、登録内容の確認・変更を行なう場合について図２９から図３１を用いて説明する。
先ず、会員遊技者は、情報端末であるノートパソコン１５Ａまたは携帯電話１６Ａからカード管理会社の管理サーバ１４０のサイト（会員サービスサイト）にアクセスすると、管理サーバ１４０は、図２９に示すように、ログインページを配信するようになっている。
このログインページには、共通会員カード１Ａの一面に印刷された会員カードＩＤを入力するための会員カードＩＤ入力部と、暗証番号を入力するための暗証番号入力部とが設けられており、会員遊技者は、これら各入力部に会員カードＩＤ並びに暗証番号を入力した後、当該ログインページの下方位置に設けられている「ログイン」の選択入力部を選択入力する。なお、会員カードＩＤは、共通会員カード１Ａの裏面にシリアルナンバーとして記載されており、会員遊技者は、このシリアルナンバーを会員カードＩＤとして入力するようになっている。
この「ログイン」の選択入力部の選択入力に基づいて、管理サーバ１４０は、当該ログインページにて受付けた会員カードＩＤに対応付けて前記共通会員情報テーブルに記憶されている暗証番号が特定されて、ログインページにて受付けた暗証番号との照合処理が実施され、該照合処理における照合が一致した場合において、前記登録済遊技場テーブルに該会員カードＩＤに対応して記憶されている遊技場ＩＤを全て抽出する処理を行なう。
更に、管理サーバ１４０は、遊技場情報テーブルを参照し、抽出した遊技場ＩＤに対応付けて登録されている遊技場名及び所在地を抽出し、遊技場表示ページを作成する処理を行なう。図３０に示すように、遊技場表示ページには、会員遊技者が会員登録を行なった遊技場が列挙され、この遊技場表示ページが会員遊技者の情報端末であるノートパソコン１５Ａや携帯電話１６Ａに配信される。このように会員遊技者は、自分が共通会員カード１Ａによって会員となっている遊技場Ａ〜Ｃを正確に把握することができる。
また、遊技場表示ページの下方には、「ログアウト」の選択入力部が設けられるとともに、会員遊技者が自分で登録した住所等の登録内容を確認するための登録内容確認ページを表示させるための「登録内容確認」の選択入力部が設けられる。そして、この「登録内容確認」の選択入力部の選択入力に基づいて、管理サーバ１４０は、前述のログインページにて受付けた会員カードＩＤに対応付けて前記共通会員情報テーブルに記憶されている会員遊技者の氏名や住所等の個人情報である会員属性情報を抽出し、登録内容確認ページを作成する処理を行なう。図３１に示すように、登録内容確認ページには、会員遊技者が登録した氏名や住所等の個人情報である会員属性情報が列挙され、この登録内容確認ページが会員遊技者の情報端末であるノートパソコン１５Ａや携帯電話１６Ａに配信される。登録内容確認ページに表示される会員属性情報には、「フレンド」として登録している会員の氏名も含まれている。また、「フレンド」の中で、誰が「仲良しフレンド」として登録されているかについても表示される。
例えば、会員カードＩＤが“ＫＫ−００００１”である「○○太郎」さんのフレンド欄には、図２５（ｄ）に示す１次関連会員情報テーブルから“ＫＫ−００００２”である「○○花子」さん、“ＫＫ−００１０１”である「△△三郎」さん、“ＫＫ−０００××”である「××次郎」さんが登録されていることが登録内容確認ページに表示される。また、３名のフレンドのうち、「○○花子」さんおよび「△△三郎」さんが「仲良しフレンド」に登録されている旨が各フレンド欄の氏名の下に表示される。なお、図３１に示す登録内容確認ページには、フレンドが氏名で表示されているが、氏名ではなくニックネームやアバター名などの別名で表示するようにしてもよい。
なお、登録内容確認ページの下方には、「ログアウト」の選択入力部が設けられるとともに、会員遊技者が自分で登録した住所等の会員属性情報の登録内容を変更するための登録内容変更ページ（図示略）を表示させるための「登録内容変更」の選択入力部や、会員遊技者が自分で登録した暗証番号を変更するための暗証番号変更ページ（図示略）を表示させるための「暗証番号変更」の選択入力部が設けられる。このように会員遊技者は、登録内容変更ページや暗証番号変更ページにて会員属性情報や暗証番号の変更を行なうことができ、多数の遊技場Ａ〜Ｃにおいて会員登録を行なっていても、一括して会員属性情報や暗証番号の変更を行なうことができる。つまり、これら変更があった場合には、変更したデータが、該ログイン中の会員遊技者が会員となっている各遊技場に送信されて、会員属性情報が更新されることで、一括して会員属性情報や暗証番号の変更を行なうことができる。
なお、具体的な構成はこれら実施例に限られるものではなく、本発明の要旨を逸脱しない範囲における変更や追加があっても本発明に含まれる。
例えば、前記実施例では、共通会員カード１Ａの発行を受ける会員登録を、各遊技場に設置された会員登録機１０において実施できるようにしているが、本発明はこれに限定されるものではなく、カード会社が、遊技者から会員属性情報が記載された会員登録の申込用紙の送付を受けて、カード管理会社の管理サーバ１４０においてこれらの会員登録の処理を実施するようにしても良い。なお、これらカード管理会社において会員登録を実施した場合においては、共通会員カード１Ａを郵送等により会員遊技者に発行すれば良い。このように、予め管理サーバ１４０にて会員登録を行なっておけば、各遊技場Ａ〜Ｃの会員登録を行なう場合に、会員属性情報を申込用紙に記入したり入力したりする等の当該遊技者の手間を著しく省くことができる。
また、前記実施例では、共通会員カード１Ａまたはビジターカードに遊技用価値であるプリペイド度数を記録し、これらのカードをＣＵ３にセットすることで使用できるが、この他にも、共通会員カード１Ａに電子マネー額が記憶された非接触ＩＣチップを内蔵するとともに、ＣＵ３に、この非接触ＩＣチップに記憶されているデータの読み出しや書き込みを含む非接触ＩＣチップとの近距離データ通信が可能な外部リーダライタを設けることで、共通会員カード１Ａに記憶された電子マネーを用いて遊技を行なえるようにしてもよい。この場合には、電子マネー額の利用機能、いわゆるお財布機能を有する携帯電話を共通会員カード１Ａの代りに用いるようにしてもよい。更に、この場合には、例えば、各遊技場Ａ〜Ｃの貯玉サーバ１１０に接続される管理サーバを電子マネーサービス会社に設置するとともに、この電子マネーサービス会社の管理サーバに金融機関ネットワークを介して接続された金融サーバを遊技者が電子マネー契約をしている口座等を有している金融機関に設置することで、電子マネーサービス会社の管理サーバは、遊技者が金融機関に開設した口座の残高を使用してチャージ額の決済を行なうことができ、チャージ額に対応する電子マネーを遊技者の共通会員カード１Ａや携帯電話にチャージすることができるようにしてもよい。なお、この場合にあっては、前記実施例にてカード管理会社の管理サーバ１４０が有する共通会員情報テーブルを、電子マネーサービス会社に設置される管理サーバにて管理するようにし、遊技場Ａ〜Ｃの会員登録機１０や会員管理コンピュータ１２０から会員属性情報送信要求があった際に、電子マネーサービス会社の管理サーバが自身で有する共通会員情報テーブルを参照して、対応する会員属性情報を遊技場Ａ〜Ｃの会員登録機１０や会員管理コンピュータ１２０に返信する処理を行なうようにしてもよい。
また、前記実施例では、管理サーバ１４０にて抽出した登録済みの遊技場に関する情報や会員属性情報を、アクセスしてきた会員遊技者の情報端末であるノートパソコン１５Ａや携帯電話１６Ａに配信するようにしているが、本発明はこれに限定されるものではなく、これらの情報を、ログインページにて受付けた会員カードＩＤから特定される当該会員遊技者の電子メールアドレスや、該会員遊技者から電子メールを受付けて、会員遊技者が指定した配信先となるこれらの電子メールアドレスに会員属性情報を含む電子メールを送信するようにしても良い。
また、前記実施例では、管理サーバ１４０にて抽出した登録済みの遊技場に関する情報や会員属性情報を、アクセスしてきた会員遊技者の情報端末であるノートパソコン１５Ａや携帯電話１６Ａに配信するようにしているが、本発明はこれに限定されるものではなく、遊技場Ａ〜Ｃに設置された会員登録機１０からカード管理会社の管理サーバ１４０のサイトにアクセスして、この会員登録機１０を用いて登録された住所等の会員属性情報の登録内容を変更できるようにしてもよい。
また、前記実施例では、管理サーバ１４０とサイトサーバとを１つのサーバにて構成しているが、本発明はこれに限定されるものではなく、セキュリティ性の向上の観点から管理サーバ１４０とサイトサーバとを個別に設ける構成にしてもよい。
＜管理サーバへのログイン＞
次に、各Ｐ台２で遊技する会員が管理サーバ１４０にログインして遊技を行なう場合について説明する。前述した管理サーバ１４０では、特に管理サーバ１４０にログインすることなく遊技を行なっているため、管理サーバ１４０に遊技履歴を記憶することなく、各遊技場に設けられた会員管理コンピュータ１２０で遊技履歴を記憶していた。以下に説明する遊技用システムでは、各Ｐ台２で遊技する会員が管理サーバ１４０にログインして遊技を行なうことで、管理サーバ１４０に遊技履歴を記憶するとともに、さまざまな機能を遊技者に提供することができる。まず、Ｐ台２で遊技を行なう際に、管理サーバ１４０にログインする必要がある。ここで、Ｐ台２に繋がったＣＵ３は、図２１に示すように貯玉サーバ１１０を介して管理サーバ１４０と通信可能に接続されており、共通会員カード１Ａの会員カードＩＤを用いて管理サーバ１４０にログイン可能である。
次に、各Ｐ台２で遊技する会員が管理サーバ１４０にログインして遊技を行なう場合について説明する。前述した管理サーバ１４０では、特に管理サーバ１４０にログインすることなく遊技を行なっているため、管理サーバ１４０に遊技履歴を記憶することなく、各遊技場に設けられた会員管理コンピュータ１２０で遊技履歴を記憶していた。以下に説明する遊技用システムでは、各Ｐ台２で遊技する会員が管理サーバ１４０にログインして遊技を行なうことで、管理サーバ１４０に遊技履歴を記憶するとともに、さまざまな機能を遊技者に提供することができる。まず、Ｐ台２で遊技を行なう際に、管理サーバ１４０にログインする必要がある。ここで、Ｐ台２に繋がったＣＵ３は、図２１に示すように貯玉サーバ１１０を介して管理サーバ１４０と通信可能に接続されており、共通会員カード１Ａの会員カードＩＤを用いて管理サーバ１４０にログイン可能である。
図１に示したＰ台２では、表示器５４に管理サーバ１４０へログインするための画面が表示される。図３２〜図３４は、管理サーバ１４０にログインするための操作を説明するための画面の一例を示す図である。なお、表示器５４には、タッチセンサが取り付けられてあり、当該画面に表示されたボタンの位置に触れると、当該ボタンの操作を行なうことが可能である。
図３２（ａ）は、Ｐ台２で遊技を始める前に、表示器５４に表示されているトップ画面上（表示器５４の手前側表示）にメニュー画面枠が表示されている一例である。メニュー画面枠内には、当該画面には管理サーバ１４０にログインせずに遊技を行なう「一般遊技」ボタン、電子マネーを利用するための「電子マネー」ボタン、管理サーバ１４０にログインする「ログイン」ボタン、ＣＵ３において会員登録を行なう場合の「会員登録」ボタン、表示器５４に広告を表示する場合の「ＣＭ表示」ボタンがそれぞれ表示されている。なお、図３２（ａ）に示すメニュー画面枠には、左側の縦方向に「一般遊技」ボタン、「一般遊技」ボタンの右側に上から順に「電子マネー」ボタン、「ログイン」ボタンおよび「会員登録」ボタンが並び、「会員登録」ボタンのさらに右側に「ＣＭ表示」ボタンがそれぞれ表示されている。
メニュー画面枠の下（表示器５４の後ろ側表示）のトップ画面には、前述のボタン以外に、画面左上にログインした会員遊技者のアバターを表示するアバター表示領域、当該アバター表示領域の右方向に「大当り」、「確変」、「スタート」および「確率」の順に遊技履歴が表示される。さらに、アバター表示領域の下方向には、トップ画面に戻るための「トップ」ボタン、メニュー画面枠を表示する「メニュー」ボタン、「離席」ボタン、ＣＵ３に挿入されたカードを返却するための「返却」ボタン、「球貸」ボタンが順に表示されている。また、図３２（ａ）に示す画面の最上段には、遊技機の台番号（たとえば、０３００番台）、および「呼出」ボタンが表示され、画面の最下段には画面左から順に「賞球数」、「残額」および「貸玉」の表示があり、当該表示に続き遊技の説明を表示するための「遊技ガイド」ボタン、および遊技機の操作を説明する「操作説明」ボタンが表示されている。メニュー画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。
遊技者が、管理サーバ１４０へログインして遊技を行なう場合、メニュー画面枠の「ログイン」ボタンを押下すると、ＣＵ３が共通会員カード１Ａの会員カードＩＤを読み出し、当該会員カードＩＤで管理サーバ１４０へログインする処理が行なわれる。その際、図２９に示したようなログイン画面を表示して暗証番号を入力する構成にしてもよい。
なお、ＣＵ３に挿入されているカードが共通会員カード１Ａではなく、遊技場会員向けに発行した会員カードやビジターカードである場合、携帯端末の非接触ＩＣチップに登録してある会員カードＩＤでもログインできるように、図３２（ｂ）に示す「会員認証します リーダーに携帯端末をかざしてください」のメッセージ画面枠（ポップアップ画面）がメニュー画面枠に変わってトップ画面上に表示される。遊技者は、自身の携帯端末の非接触ＩＣチップに会員カードＩＤを登録していれば、リーダー（図示せず）に携帯端末をかざして会員カードＩＤを読み出し、当該会員カードＩＤで管理サーバ１４０へログインする処理が行なわれる。もちろん、共通会員カード１Ａ自体をリーダーにかざして会員カードＩＤを読み出して、管理サーバ１４０へのログイン処理を行なってもよい。図３２（ｂ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。
管理サーバ１４０へのログイン処理が開始されると、図３２（ｂ）に示すメッセージ画面枠が消え、当該位置に図３３（ｃ）に示す「受付処理中です しばらくお待ちください」とのメッセージ画面枠が表示される。図３３（ｃ）に示すメッセージ画面枠の内容は、一例でありＣＵ３が管理サーバ１４０へのログイン処理を行なっている最中であることを示す内容であればいずれの内容であってもよい。なお、ＣＵ３が管理サーバ１４０へのログイン処理を行なっている最中の画面は、図３３（ｃ）に示す画面に限られず、たとえばメッセージ画面枠に遊技の説明画面や後述する広告画面を表示してもよい。図３３（ｃ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。ただし、「呼出」ボタン、「遊技ガイド」ボタンおよび「操作説明」ボタンの操作は有効にしてもよい。
次に、管理サーバ１４０へのログイン処理が終了すると、図３３（ｄ）に示すログイン中の画面が表示される。当該ログイン中の画面には、「ログイン中」ボタンの表示、アバター表示領域に、ログイン前に表示していた画像に変わり、ログインした遊技者が事前に登録したキャラクタ画像が表示される。なお、キャラクタ画像を表示したアバター表示領域の下に、ログインした遊技者の会員カードＩＤを表示してもよい。また、アバター表示領域に表示させるキャラクタ画像の情報は、少なくとも管理サーバ１４０の会員属性情報に関連付けて記憶してある。キャラクタ画像の登録は、管理サーバ１４０に会員属性情報を登録する際に、遊技者が自分にあったキャラクタ画像を選択して登録する。なお、管理サーバ１４０へのログインする度に、アバター表示領域に表示させるキャラクタ画像のデータを管理サーバ１４０から送信するのではなく、会員管理コンピュータ１２０の会員属性情報にも当該キャラクタ画像のデータを記憶させておき、会員管理コンピュータ１２０から当該データを送信するように構成してもよい。当該キャラクタ画像は、遊技者の遊技状況（たとえば、大当り、出玉○○○発、○○○ハマりなどの状況など）により表情や動作を変化させること（たとえば、大当りのときはうれしい表情をし、はずれのときは悲しい表情をするなど）ができるとともに、後述するフレンド機能のように他のＰ台２に設けた表示器５４に登場させることができる。さらに、ログイン中の画面には、本日持玉数、貯玉数、およびプレイ可能玉（遊技玉）数が表示される。また、表示器５４には、本日持玉数の表示の左側の位置に「払出」ボタン、貯玉数の表示の左側の位置に「再プレイ」ボタンがそれぞれ表示されている。「払出」ボタンは、本日持玉をプレイ可能玉（遊技玉）に変換するためのボタンであり、本日持玉数が存在するとき有効で、存在しないとき無効となる。また、「再プレイ」ボタンは、貯玉をプレイ可能玉（遊技玉）に変換するためのボタンであり、貯玉数が存在するとき有効で、存在しないとき無効となる。
管理サーバ１４０へのログイン処理が行なわれ、ログインに用いた会員カードＩＤが図２５（ａ）に示す共通会員情報テーブルに登録されていない場合、図３４（ｅ）に示す「この携帯ｏｒカードは会員登録されておりません 今すぐ会員登録しますか？」とのメッセージ画面枠が表示される。ここで、図３４（ｅ）に表示された「はい」ボタンを押下すると会員登録サイトへ遷移できるように図３４（ｅ）に示すメッセージ画面枠に変えて、図３４（ｆ）に示すメッセージ画面枠が表示される。図３４（ｆ）に示すメッセージ画面枠には、「[会員登録サイトへ遷移します]」のタイトル、および「リーダーに携帯端末をかざすか、表示されている二次元コードを読取ってください」とのメッセージが表示されるとともに二次元コードが表示される。遊技者は、携帯端末をリーダーにかざすか、二次元コードを読取って会員登録サイト（図示せず）へ遷移し、会員登録を行なう。一方、図３４（ｅ）に表示された「いいえ」ボタンを押下するとトップ画面が表示される。なお、「はい」ボタン、および「いいえ」ボタンのいずれも選択せずに１０秒間経過すると、トップ画面が表示されるようにしてもよい。図３４（ｅ）および図３４（ｆ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。ただし、「呼出」ボタン、「遊技ガイド」ボタンおよび「操作説明」ボタンの操作は有効にしてもよい。
＜管理サーバからのログアウト＞
次に、管理サーバ１４０からのログアウト処理について説明する。遊技者が遊技を終了する場合、以下のような操作を行ない管理サーバ１４０からログアウトする。図３５は、管理サーバ１４０からログアウトするための操作を説明するための画面の一例を示す図である。まず、図３５（ａ）に示す画面において表示されている「本日持玉」、「貯玉」、および「プレイ可能玉」がそれぞれ０玉になるように計数処理を行なう。次に、ＣＵ３に挿入されている共通会員カード１Ａを返却するために、「返却」ボタンを押下する。さらに、表示される「ログイン中」ボタンの押下することで、管理サーバ１４０からログアウトできる。なお、前述の操作は一例であり、例えば、「返却」ボタンを押下するだけで、前述の操作を自動で行ない管理サーバ１４０からログアウトするように構成してもよい。
次に、管理サーバ１４０からのログアウト処理について説明する。遊技者が遊技を終了する場合、以下のような操作を行ない管理サーバ１４０からログアウトする。図３５は、管理サーバ１４０からログアウトするための操作を説明するための画面の一例を示す図である。まず、図３５（ａ）に示す画面において表示されている「本日持玉」、「貯玉」、および「プレイ可能玉」がそれぞれ０玉になるように計数処理を行なう。次に、ＣＵ３に挿入されている共通会員カード１Ａを返却するために、「返却」ボタンを押下する。さらに、表示される「ログイン中」ボタンの押下することで、管理サーバ１４０からログアウトできる。なお、前述の操作は一例であり、例えば、「返却」ボタンを押下するだけで、前述の操作を自動で行ない管理サーバ１４０からログアウトするように構成してもよい。
管理サーバ１４０からのログアウト処理が開始されると、直ちにログアウトする構成であってもよいが、図３５（ｂ）のようにメッセージ画面枠を表示して完全にログアウトするまでに猶予時間を設定する構成であってもよい。図３５（ｂ）に示すメッセージ画面枠では、「認証解除カウントダウン開始 あと００秒でログアウトします」とのメッセージが表示される。つまり、ＣＵ３は、管理サーバ１４０との間の認証を解除せず、ログイン状態を設定された時間保持し、誤って「ログイン中」ボタンを押下して管理サーバ１４０からログアウトされてしまわないようにしてある。なお、猶予時間を待たずに直ちにログアウトできるように「ログアウト」ボタンが設けてある。逆に、継続して遊技を行ないたい場合のために「認証継続するには入金または「続ける」を押してください」とのメッセージが表示され、「続ける」ボタンを押下することで、図３３（ｄ）で示したログイン中画面に戻る。図３５（ｂ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。ただし、「呼出」ボタン、「遊技ガイド」ボタンおよび「操作説明」ボタンの操作は有効にしてもよい。
管理サーバ１４０からのログアウト処理が完了すると、図３５（ｃ）に示すような画面が表示される。具体的に、図３５（ｃ）に示すような画面には、「ログイン中」ボタンの表示が消え、アバター表示領域に遊技者が登録したキャラクタ画像に変わり、ログイン前のキャラクタ画像が表示される。また、アバター表示領域の下に、ログインした遊技者の会員カードＩＤが表示されていた場合、当該表示も消える。なお、「ログイン中」ボタンなどの表示が消えた部分に、後述する広告画像の表示を行なってもよい。
＜仲良しフレンド表示機能＞
管理サーバ１４０には、図２５（ｅ）に示すような２次関連会員情報テーブルが記憶してあり、各会員カードＩＤに対応付けて、当該会員カードＩＤから特定される会員遊技者の「仲良しフレンド」（２次関連会員遊技者）が全て記憶されている。そして、本実施形態に係る遊技用システムでは、当該２次関連会員情報テーブルを利用して仲良しフレンド表示機能を遊技者に提供することができる。ここで、仲良しフレンド表示機能とは、管理サーバ１４０にログインした会員カードＩＤに対応付けて２次関連会員情報テーブルに登録してある仲良しフレンドのうち、同じ遊技場で遊技している仲良しフレンドを検索して、ログインした会員の表示器５４に表示する機能である。図３６、図３７は、仲良しフレンド表示機能の操作を説明するための画面の一例を示す図である。
管理サーバ１４０には、図２５（ｅ）に示すような２次関連会員情報テーブルが記憶してあり、各会員カードＩＤに対応付けて、当該会員カードＩＤから特定される会員遊技者の「仲良しフレンド」（２次関連会員遊技者）が全て記憶されている。そして、本実施形態に係る遊技用システムでは、当該２次関連会員情報テーブルを利用して仲良しフレンド表示機能を遊技者に提供することができる。ここで、仲良しフレンド表示機能とは、管理サーバ１４０にログインした会員カードＩＤに対応付けて２次関連会員情報テーブルに登録してある仲良しフレンドのうち、同じ遊技場で遊技している仲良しフレンドを検索して、ログインした会員の表示器５４に表示する機能である。図３６、図３７は、仲良しフレンド表示機能の操作を説明するための画面の一例を示す図である。
具体的に、会員カードＩＤを有する会員が遊技場での遊技中に表示器５４に表示されたログイン画面から管理サーバ１４０にログインすると、当該遊技場の会員管理コンピュータ１２０はログインした会員の会員カードＩＤを特定可能な情報を管理サーバ１４０に送信する。管理サーバ１４０は、会員管理コンピュータ１２０からの情報に基づいて、ログインした会員の仲良しフレンドを検索し、検索結果を会員管理コンピュータ１２０に返信する。会員管理コンピュータ１２０は、管理サーバ１４０から受信した仲良しフレンドが現在ログインしているかどうかに基づいてログインした会員と同じ遊技場で遊技している仲良しフレンドがいるかどうかを検索し、検索結果をログインした会員の表示器５４に表示させる。なお、同じ遊技場内で遊技している仲良しフレンドを検索する処理を、各遊技場の会員管理コンピュータ１２０ではなく、管理サーバ１４０で行なうようにしてもよい。ここで、仲良しフレンド表示機能や後述するチャット機能を利用できる対象を同じ遊技場で遊技している仲良しフレンドに限定することで、他の遊技場での遊技状況と比較され、他の遊技場へ遊技者が流れるのを防止することができる。
なお、仲良しフレンドではなくてフレンドが同じ遊技場にいるか否かを検索して表示できるようにしてもよい。また、同じ遊技場ではなく異なる遊技場で遊技している（ログインしている）仲良しフレンドあるいはフレンドを特定するようにしてもよい。そして、特定された仲良しフレンドあるいはフレンドとの間で後述するチャット機能や持玉共有機能などの特定機能を利用できるようにしてもよい。
検索した結果、遊技場で遊技している仲良しフレンドが見つかった場合、図３６（ｂ）に示すように仲良しフレンドのアバター（仲良しフレンドを特定可能な情報）としてキャラクタ画像を「再プレイ」ボタンの下方に表示する。なお、表示する仲良しフレンドのキャラクタ画像は、仲良しフレンドの会員カードＩＤに基づいて、当該会員カードＩＤの会員属性情報に登録してあるキャラクタ画像を利用する。仲良しフレンドのキャラクタ画像を表示するだけでは、遊技者が各仲良しフレンドを識別することができない場合もあるので、キャラクタ画像とともに会員カードＩＤなどの識別番号（たとえば、「Ｎｏ．０００１」、「Ｎｏ．０００２」、「Ｎｏ．０００３」など）を表示してある。もちろん、キャラクタ画像とともに表示される識別表示は、会員カードＩＤに限定されず遊技場会員ＩＤ、会員カードＩＤに登録してある氏名やニックネーム等であってもよい。
図３６（ｂ）に示す画面では、３名の仲良しフレンドが表示されている。この仲良しフレンドの表示される順は、左からログイン時間の早い順としてある。もちろん、表示順は、これに限定されず、大当り回数が多い順や賞球数の多い順などでもよい。仲良しフレンドのアバターは、たとえば表示器５４の右端から歩いて登場して図３６（ｂ）に示すように所定の位置に並ぶように表示してもよい。また、登場する際に、仲良しフレンドの遊技状況を話し（ふきだし表示）しながら登場してもよい。さらに、図３６（ｂ）に表示された仲良しフレンドを押すことで、当該仲良しフレンドの遊技情報（たとえば遊技履歴など）に基づき当該仲良しフレンドの遊技状況（会員情報の一例、たとえば、大当り、出玉○○○発、○○○ハマりなどの状況など）を表示させることができる。たとえば、図３７（ｃ）に示すように、たとえば、識別番号「Ｎｏ．０００１」の仲良しフレンドのキャラクタ画像を押すと、現在の遊技状況として「大当り」と表示される。表示させる遊技状況には、遊技情報に含まれる大当り回数や確変回数などの遊技履歴や、会員属性情報に含まれる氏名などの情報がある。なお、フレンド機能では、ＣＵ３で受付けた会員カードＩＤに対応する遊技者に対応して、表示器５４にアバターを表示させる仲良しフレンドの会員属性情報を、当該仲良しフレンドの遊技情報とともに管理サーバ１４０または会員管理コンピュータ１２０から送信することになる。
検索した結果、遊技場で遊技している仲良しフレンドが見つからなかった場合、図３７（ｄ）に示すように「再プレイ」ボタンの下方にキャラクタ画像が表示されない。なお、前述の構成では、同じ遊技場内で遊技している仲良しフレンドを検索して表示しているが、これに限定されず、所定の範囲内であればよく、たとえば同じ系列店の遊技場内で遊技している仲良しフレンドを検索して表示しても、同じ地域内（たとえば同市内や同町内など）で遊技している仲良しフレンドを検索して表示してもよい。もちろん、管理サーバ１４０に登録されている仲良しフレンドであれば、どこで遊技しているのかに関わらず表示してもよい。
＜チャット機能・スタンプ送受信機能＞
本実施形態に係る遊技用システムでは、図３６、図３７で示したように、同じ遊技場で現在遊技している仲良しフレンドが仲良しフレンド表示機能により表示されるだけではなく、当該仲良しフレンドと通信を行なうこともできる。具体的には、仲良しフレンドとの間で定型文を用いたチャットやスタンプ送受信が可能である。図３８、図３９は、チャット機能の操作を説明するための画面の一例を示す図である。
本実施形態に係る遊技用システムでは、図３６、図３７で示したように、同じ遊技場で現在遊技している仲良しフレンドが仲良しフレンド表示機能により表示されるだけではなく、当該仲良しフレンドと通信を行なうこともできる。具体的には、仲良しフレンドとの間で定型文を用いたチャットやスタンプ送受信が可能である。図３８、図３９は、チャット機能の操作を説明するための画面の一例を示す図である。
まず、図３８（ａ）に示すように、仲良しフレンド表示機能の結果、表示器５４には、３名の仲良しフレンドが表示されている。この３名の仲良しフレンドの中から左端に位置する仲良しフレンドと通信を行なう場合、当該仲良しフレンドの画面位置を押して、通信相手を選択する。
表示されている仲良しフレンドを選択すると、図３８（ｂ）に示すように、選択メニュー画面枠がアバターなどを表示した画面上に表示され、チャット機能と後述する持玉共有機能とを選択することができる。チャット機能を利用して、選択した仲良しフレンドと通信を行なうためには、選択メニュー画面の「チャットをする」ボタンを押下する。図３８（ｂ）に示す選択メニュー画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。そのため、チャット機能を中止したい場合は、「トップ」ボタンなどを押下することで中止することができる。
「チャットをする」ボタンを押下すると、表示器５４には、図３８（ｂ）に示す選択メニュー画面枠に変わり、当該位置に図３９（ｃ）に示すような、送信する言葉（テキストメッセージ）を選ぶための一覧メニュー枠が表示される。一覧メニュー枠には、「送信する言葉を選んでね」とのメッセージとともに、「こんにちは」、「ハマッタ！」、「いいよ」、「激アツ」、「ハズれた！」、「ダメ」、「帰ろうかな」、「玉ちょうだい・・・」、「マジ？？？」、「まだ打つ？」および「移動します」などの送信する言葉が表示される。遊技者が一覧メニュー枠から「こんにちは」を選択して、通信相手の仲良しフレンドに送信する。なお、一覧メニュー枠に表示される送信する言葉は、ＣＵ３に予め登録されている言葉だけではなく、遊技者が事前に情報端末であるノートパソコン１５Ａや携帯電話１６Ａから管理サーバ１４０にアクセスして送信する言葉を追加・変更登録してもよい。また、送信する言葉を一覧メニュー枠から選ぶのではなく、キーボードなど入力画面を表示して直接入力するようにしてもよい。図３９（ｃ）に示す一覧メニュー枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。そのため、チャット機能を中止したい場合は、「トップ」ボタンなどを押下することで中止することができる。
本実施形態に係る遊技用システムは、遊技者が「こんにちは」と通信相手の仲良しフレンドに言葉を送信すると、図３９（ｄ）に示すように通信相手の仲良しフレンドから「がんばって！」との言葉を返信されてくることで、チャット機能を用いた通信を行なうことが可能となる。
このように、仲良しフレンドとの間で、チャット機能を用いて簡単に通信を行なうことができることで、複数の遊技者間でコミュニケーションを図りつつ遊技を行なうことが可能になり、単独で遊技を行なうときとは違った楽しみ方を遊技者に提供することができる。
さらに、本実施例では、仲良しフレンドとの間でチャット機能を利用してテキストメッセージを送受信する際に、「スタンプ」を添えることができるスタンプ送受信機能を利用可能に構成される。スタンプとは、テキストメッセージに挿入できるイラストのことであり、喜怒哀楽をはじめ、感動、落胆、放心、お礼、お詫び、応援などといった多種多様な感情や心境を表現したイラストが含まれる。スタンプを送受信することで、言葉では表現しにくい微妙な感情を、的確かつ簡潔に伝えることができる。
＜持玉共有機能＞
本実施形態に係る遊技用システムでは、図３６、図３７で示したように、同じ遊技場で現在遊技している仲良しフレンドが仲良しフレンド表示機能により表示されるだけではく、当該仲良しフレンドとの間で持玉を共有することができる。具体的には、仲良しフレンドとの間で持玉を送信したり、受信したりすることで持玉共有が可能である。図４０〜図４３は、持玉共有機能の操作を説明するための画面の一例を示す図である。
本実施形態に係る遊技用システムでは、図３６、図３７で示したように、同じ遊技場で現在遊技している仲良しフレンドが仲良しフレンド表示機能により表示されるだけではく、当該仲良しフレンドとの間で持玉を共有することができる。具体的には、仲良しフレンドとの間で持玉を送信したり、受信したりすることで持玉共有が可能である。図４０〜図４３は、持玉共有機能の操作を説明するための画面の一例を示す図である。
まず、図３８（ａ）に示すように、フレンド機能の結果、表示器５４には、３名の仲良しフレンドが表示されている。この３名の仲良しフレンドの中から左端に位置する仲良しフレンドとの間で持玉共有を行なう場合、当該仲良しフレンドの画面位置を押して、持玉共有相手を選択する。
表示されている仲良しフレンドを選択すると、図４０（ａ）に示すように、選択メニュー画面枠がアバターなどを表示した画面上に表示され、チャット機能と持玉共有機能とを選択することができる。持玉共有機能を利用して、選択した仲良しフレンドと持玉共有を行なうためには、選択メニュー画面の「持玉を贈る」ボタンを押下する。図４０（ａ）に示す選択メニュー画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。そのため、持玉共有機能を中止したい場合は、「トップ」ボタンなどを押下することで中止することができる。
「持玉を贈る」ボタンを押下すると、表示器５４には、図４０（ａ）に示す選択メニュー画面枠に変わり、当該位置に図４０（ｂ）に示すような、送る持玉数を選択する選択一覧画面枠が表示される。図４０（ｂ）に示す選択一覧画面枠には、「贈る玉数を選択してください！」とのメッセージが表示されるとともに、「５０００玉」、「３０００玉」、「１０００玉」および「５００玉」の贈る玉数が表示されている。なお、贈る玉数を選択一覧画面枠から選ぶのではなく、キーボードなど入力画面を表示して直接入力するようにしてもよい。図４０（ｂ）に示す選択一覧画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。そのため、持玉共有機能を中止したい場合は、「トップ」ボタンなどを押下することで中止することができる。
遊技者が「５０００玉」を選択すると、表示器５４には、図４０（ｂ）に示す選択一覧画面枠に変わり、当該位置に図４１（ｃ）に示すような確認画面枠が表示される。図４１（ｃ）に示す確認画面枠には、具体的に「Ｎｏ．０００１さんに持玉を贈ります」とのメッセージとともに、「現在の当日持玉」、「共有玉数」および「残りの当日持玉」が表示され、「決定」および「取消」ボタンが表示される。たとえば、「現在の当日持玉」が２３９４５玉で、「共有玉数」として５０００玉贈る場合、「残りの当日持玉」は、２３９４５玉−５０００玉で、１８９４５玉となる。遊技者は、当該画面で共有玉数を確認して、仲良しフレンドに持玉を贈る場合、「決定」ボタンを押下し、仲良しフレンドに持玉を贈ることを中止する場合、「取消」ボタンを押下する。ここで、図４１（ｃ）に示す画面が表示する前に、持玉を贈る相手の仲良しフレンドが管理サーバ１４０からログアウトしている場合であっても、図４１（ｃ）に示す画面を表示するとともに、贈る玉数の確認を行なう。図４１（ｃ）に示す選択メニュー画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっておらず、当該ボタンの操作は有効である。そのため、持玉共有機能を中止したい場合は、「トップ」ボタンなどを押下することで中止することができる。
「決定」ボタンを押下して、仲良しフレンドの持玉が送信された場合、図４１（ｄ）に示すように、「送信完了」のメッセージ画面枠がアバターなどを表示した画面上に表示される。図４１（ｄ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。一方、持玉を贈られた仲良しフレンド側の表示器５４（たとえば、０２３０番台のＰ台２に設けられた表示器５４）には、図４２（ｅ）に示すメッセージ画面枠がアバターなどを表示した画面上に表示され、「Ｎｏ．００８さんから贈り物が届いています」とのメッセージとともに、贈り物の「５０００玉」が表示される。図４２（ｅ）に示すメッセージ画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。贈られた持玉を受取った仲良しフレンドは、表示器５４に表示されている「確認」ボタンを押下することで、贈られた持玉を自分の持玉として利用することができるようになる。なお、表示器５４に図４２（ｅ）に示すメッセージ画面枠が表示されると、「確認」ボタンが押下されるまで遊技玉の発射以外の操作をすることができない。また、所定時間内に「確認」ボタンが押下されなければ、持玉共有機能をキャンセルするように構成しても、自動的に持玉共有するように構成してもよい。
図３８（ａ）で、持玉共有相手の仲良しフレンドを選択した後に、当該仲良しフレンドが管理サーバ１４０からログアウトしている場合や、当該仲良しフレンドとの通信ができなくなっている場合、表示器５４には、図４３（ｆ）に示すように「送信失敗」のメッセージ画面枠がアバターなどを表示した画面上に表示される。持玉の送信が失敗すると、贈った持玉を戻す処理が開始され、図４３（ｆ）に示すメッセージ画面枠に「持玉を戻します」と表示される。
贈った持玉を戻す処理が開始されると、表示器５４には、図４３（ｆ）に示すメッセージ画面枠に変わり、当該位置に図４３（ｇ）に示すメッセージ画面枠が表示される。図４３（ｇ）に示すメッセージ画面枠には、「共有玉を戻します」とのメッセージとともに、「現在の当日持玉」、「共有玉数」および「残りの当日持玉」が表示され、「確認」ボタンが表示される。たとえば、「現在の当日持玉」が１８９４５玉で、戻す「共有玉数」が５０００玉の場合、「残りの当日持玉」は、１８９４５玉＋５０００玉で、２３９４５玉となる。持玉が戻された遊技者は、表示器５４に表示されている「確認」ボタンを押下することで、戻された持玉を自分の持玉として利用することができるようになる。なお、図４３（ｇ）に示す選択メニュー画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっていないが、表示器５４に図４３（ｇ）に示すメッセージ画面枠が表示されると、「確認」ボタンが押下されるまで遊技玉の発射以外の操作をすることができない。また、所定時間内に「確認」ボタンが押下されなければ、自動的に持玉を戻してもよい。
＜広告表示機能＞
本実施形態に係る遊技用システムでは、遊技者などに対する広告宣伝機能を有する。具体的には、遊技者の遊技を妨げないような表示態様で広告を表示器５４に表示することが可能である。図４４〜図４７は、カードユニットの表示器に表示される広告の表示態様を説明するための画面の遷移を示す図である。
本実施形態に係る遊技用システムでは、遊技者などに対する広告宣伝機能を有する。具体的には、遊技者の遊技を妨げないような表示態様で広告を表示器５４に表示することが可能である。図４４〜図４７は、カードユニットの表示器に表示される広告の表示態様を説明するための画面の遷移を示す図である。
図４４（ａ）を参照して、ＣＵ３の表示器５４にはトップ画面が表示されている。トップ画面は、遊技者がカードをＣＵ３に挿入した後、初めに表示される初期画面である。図４４（ａ）からわかるように、表示器５４は、遊技機での遊技に関するさまざまな遊技関連情報を表示する表示領域を有している。具体的に、表示器５４には、トップ画面に遷移する操作を受け付ける「トップ」ボタンと、メニュー画面枠を表示する操作を受け付ける「メニュー」ボタンと、遊技者が遊技を中断するための離席操作を受け付ける「離席」ボタンと、カードの返却操作を受け付ける「返却」ボタンと、残額から遊技に用いる遊技点を貸出す操作を受け付ける「球貸」ボタン（図４４（ａ）の「２」（丸で囲まれた２を示す）の領域）と、遊技場に預け入れられている遊技者所有の貯玉から遊技点に引き落とす操作を受け付ける「再プレイ」ボタン（図４４（ａ）の「４」（丸で囲まれた４を示す）の領域）と、カードに記録された遊技者所有の持点から遊技点に払い出す操作を受け付ける「払出」ボタン（図４４（ａ）の「３」（丸で囲まれた３を示す）の領域）とが表示される。表示器５４には、さらに、入金の残額（残金）、賞球数、貸玉数、持玉数（持点数）、貯玉数、プレイ可能玉数である遊技玉数（遊技点数）などが表示される。
ここで、ＣＵ制御部３２３は、遊技者の遊技を妨げずに広告表示を行なうため、ＣＵ３が受け付けた入力の種類（たとえば、上述した各ボタンを遊技者が押下する操作）に基づいて、表示器５４に表示される広告の表示態様を設定する。ある局面では、ＣＵ制御部３２３は、表示態様として、表示領域に対する広告表示領域の割り当てを設定する。具体的には、ＣＵ制御部３２３は、遊技者から所定の操作を受け付けると、その所定の操作後に遊技者が行なうと想定される一連の操作を妨げないように広告表示領域を設定する。すなわち、ＣＵ制御部３２３は、遊技者が所定の操作を行なった後、次の操作のために遊技者が確認したい領域が適切に確認できるように広告表示領域を設定する。そして、表示制御部３５０は、設定された表示態様で広告を表示器５４に表示させる。別の局面では、ＣＵ制御部３２３は、表示態様のうち広告を表示させる表示時間を設定する。そして、表示制御部３５０は、当該設定された表示時間内において広告を表示させる。
以下、図４４（ａ）〜図４７（ｇ）を参照して、ＣＵ３が遊技者からどのような操作を受け付けると、表示器５４のどの領域に、どのくらいの時間、広告が表示されるのかを具体的に説明する。
図４４（ａ）および図４４（ｂ）を参照して、表示領域Ａに広告が表示される場合について説明する。まず、遊技者がＣＵ３に対して払出操作を行なった場合について考える。具体的には、払出操作とは、「払出」ボタンを選択する操作（表示対象操作「３」（丸で囲まれた３を示す）払出に相当）である。ＣＵ制御部３２３は、払出操作を受け付けると、持玉の残数を示す持玉数（持点情報）が表示されている領域を視認可能な態様で広告表示領域を設定する。たとえば、図４４（ｂ）に示すように、ＣＵ制御部３２３は、持玉数が表示されていない表示領域Ａを広告表示領域として設定し、表示制御部３５０は、設定された表示領域Ａに広告を表示する。すなわち、ＣＵ制御部３２３は、払出操作を受け付けると、持玉数に被らないように広告表示領域を設定する。なお、ＣＵ制御部３２３は、持玉数に加えて遊技玉数にも被らないように広告表示領域を設定してもよい。
また、ＣＵ制御部３２３は、図４４（ｂ）に示すように、広告を表示領域Ａに表示するときに、持玉数および遊技玉数を含むメッセージ画面枠（ポップアップ画面）を表示してもよい。当該メッセージ画面枠では、さらに払出玉数も表示されている。このとき、ＣＵ制御部３２３は、メッセージ画面枠が表示される比較的短い時間（たとえば、４秒）内で広告を表示するように設定してもよい。このようなメッセージ画面枠を表示させるのは、遊技者に対して持玉数および遊技玉数が変化したことの確認を促すためである。なお、持玉数が減少し遊技玉数が増加したことを強調する矢印を表示してもよい。これにより、ＣＵ３は、遊技者が払出操作後に持玉数の減少および遊技玉数の増加を確認するという流れを妨げることなく、広告を表示できる。
次に、遊技者がＣＵ３に対して入金操作を行なった場合について考える。入金操作とは、紙幣挿入口３０２に紙幣を挿入する操作（表示対象操作「１」（丸で囲まれた１を示す）入金に相当）、およびＣＵ３にスマートフォンなどの携帯端末と通信するための通信部を設けて、携帯端末を当該通信部にかざすことによって携帯端末内に記憶されている電子マネーをＣＵ３に認識させる操作（表示対象操作「５」（丸で囲まれた５を示す）電子マネーに相当）を含む。ＣＵ制御部３２３は、入金操作を受け付けると、入金の残額が表示されている領域、および「球貸」ボタンが表示されている領域を視認可能な態様で広告表示領域を設定する。たとえば、図４４（ｂ）に示すように、ＣＵ制御部３２３は、残額および「球貸」ボタンが表示されていない表示領域Ａに広告表示領域に設定し、表示制御部３５０は、設定された表示領域Ａに広告を表示する。すなわち、ＣＵ制御部３２３は、入金操作を受け付けると、残額および「球貸」ボタンに被らないように広告表示領域を設定する。
また、ＣＵ制御部３２３は、広告を表示領域Ａに表示するときに、上述した払出操作の場合と同じようなメッセージ画面枠を表示してもよい。この場合には、変化があった項目である残額および電子マネー残額を含むメッセージ画面枠が表示される。このとき、ＣＵ制御部３２３は、メッセージ画面枠が表示される比較的短い時間（たとえば、４秒）内で広告を表示するように設定してもよい。このようなメッセージ画面枠を表示させるのは、遊技者に対して残額または電子マネー残額が変化したことの確認を促すためである。
これにより、ＣＵ３は、遊技者が入金操作して残額または電子マネー残額が増加するのを確認した後、当該残額から遊技点を貸し出す球貸し操作を行なう（「球貸」ボタンを押下する）という一連の流れを妨げることなく、広告を表示できる。
次に、遊技者がＣＵ３に対して球貸し操作を行なった場合について考える。具体的には、球貸し操作とは、「球貸」ボタンを選択する操作（表示対象操作「２」（丸で囲まれた２を示す）球貸に相当）である。ＣＵ制御部３２３は、球貸し操作を受け付けると、入金の残額が表示されている領域、および遊技玉の残数を示す遊技玉数（遊技点情報）が表示されている領域を視認可能な態様で広告表示領域を設定する。たとえば、図４４（ｂ）に示すように、ＣＵ制御部３２３は、残額および遊技玉数が表示されていない表示領域Ａを広告表示領域として設定し、表示制御部３５０は、設定された表示領域Ａに広告を表示する。すなわち、ＣＵ制御部３２３は、球貸し操作を受け付けると、残額および遊技玉数に被らないように広告表示領域を設定する。
また、ＣＵ制御部３２３は、広告を表示領域Ａに表示するときに、上述した払出操作の場合と同じようなメッセージ画面枠を表示してもよい。この場合には、変化があった項目である残額および遊技玉数を含むメッセージ画面枠が表示される。このとき、ＣＵ制御部３２３は、メッセージ画面枠が表示される比較的短い時間（たとえば、４秒）内で広告を表示するように設定してもよい。このようなメッセージ画面枠を表示させるのは、遊技者に対して残額および遊技玉数が変化したことの確認を促すためである。なお、メッセージ画面枠において、残額が減少し遊技玉数が増加したことを強調する矢印を表示してもよい。これにより、ＣＵ３は、遊技者が球貸し操作後に残額の減少および遊技点数の増加を確認するという流れを妨げることなく、広告を表示できる。
次に、遊技者がＣＵ３に対して再プレイ操作を行なった場合について考える。具体的には、再プレイ操作とは、再プレイボタンを選択する操作（表示対象操作「４」（丸で囲まれた４を示す）再プレイに相当）である。ＣＵ制御部３２３は、再プレイ操作を受け付けると、貯玉の残数を示す貯玉数（貯玉情報）が表示されている領域を視認可能な態様で広告表示領域を設定する。たとえば、図４４（ｂ）に示すように、ＣＵ制御部３２３は、貯玉数が表示されていない表示領域Ａを広告表示領域として設定し、表示制御部３５０は、設定された表示領域Ａに広告を表示する。すなわち、ＣＵ制御部３２３は、再プレイ操作を受け付けると、貯玉数に被らないように広告表示領域を設定する。なお、ＣＵ制御部３２３は、貯玉数に加えて遊技玉数にも被らないように広告表示領域を設定してもよい。
また、ＣＵ制御部３２３は、図４４（ｂ）に示すように、広告を表示領域Ａに表示するときに、上述した払出操作の場合と同じようなメッセージ画面枠を表示してもよい。この場合には、変化があった項目である貯玉数および遊技玉数を含むメッセージ画面枠が表示される。このとき、ＣＵ制御部３２３は、メッセージ画面枠が表示される比較的短い時間（たとえば、４秒）内で広告を表示するように設定してもよい。メッセージ画面枠を表示させるのは、遊技者に対して貯玉数および遊技玉数が変化したことの確認を促すためである。なお、メッセージ画面枠において、貯玉数が減少し遊技玉数が増加したことを強調する矢印を表示してもよい。これにより、ＣＵ３は、遊技者が再プレイ操作後に貯玉数の減少を確認するという流れを妨げることなく、広告を表示できる。
次に、遊技者がメニュー画面枠を表示して管理サーバ１４０にログインするログイン操作を行なう場合について考える。具体的には、ログイン操作とは、遊技者が「メニュー」ボタンを選択ときに表示される図３２（ａ）に示すメニュー画面枠において、「ログイン」ボタンを選択する操作（表示対象操作「６」（丸で囲まれた６を示す）ログインに相当）である。ＣＵ制御部３２３は、「メニュー」ボタンを選択する操作を受け付けると、ログイン操作を受け付けるために必要なメニュー画面枠が表示される領域を視認可能な態様で広告表示領域を設定する。たとえば、図４４（ｂ）に示すように、ＣＵ制御部３２３は、メニュー画面枠が表示されていない表示領域Ａを広告表示領域として設定し、表示制御部３５０は、設定された表示領域Ａに広告を表示する。すなわち、ＣＵ制御部３２３は、「メニュー」ボタンを選択する操作を受け付けると、ログイン操作を受け付けるために必要な操作領域に被らないように広告表示領域を設定する。これにより、ＣＵ３は、遊技者がメニューボタンの選択操作後に表示されるメニュー画面枠においてログイン操作を行なうという流れを妨げることなく、広告を表示できる。
次に、図４５（ｃ）〜図４６（ｆ）を参照して、表示領域Ｂに広告が表示される場合について説明する。ここでは、遊技者が広告に関する操作である広告表示操作を行なう場合について考える。具体的には、広告表示操作とは、遊技者が「メニュー」ボタンを選択する操作と、「メニュー」ボタンを選択したときに表示される図３２（ａ）に示すメニュー画面枠において「ＣＭ表示」ボタンを選択する操作（表示対象操作「７」（丸で囲まれた７を示す）メニュー内のＣＭボタンタッチに相当）と、「ＣＭ表示」ボタンの選択操作後に表示されるＣＭ選択画面において複数の広告の中から表示させたい広告を選択する操作とを含む。ＣＵ制御部３２３は、「メニュー」ボタンを選択する操作を受け付けると、「ＣＭ表示」ボタンを含むメニュー画面枠を表示器５４に表示する。
続いて、ＣＵ制御部３２３は、図３２（ａ）に示すメニュー画面枠において「ＣＭ表示」ボタンを選択する操作を受け付けると、「メニュー」ボタンが表示される領域を視認可能な態様で広告表示領域を設定する。たとえば、図４５（ｄ）に示すように、ＣＵ制御部３２３は、「メニュー」ボタンが表示されていない表示領域Ｂを広告表示領域として設定する。また、表示制御部３５０は、図４６（ｅ）に示すように、広告表示領域として設定された表示領域Ｂに、複数のＣＭ（ＣＭ１〜ＣＭ６）から表示するＣＭを選択するためのＣＭ選択画面を表示させる。ＣＵ制御部３２３が遊技者からＣＭを選択する操作を受け付けると、遊技者により選択されたＣＭ（たとえば、ＣＭ１を選択）が比較的長い時間内（たとえば、１５秒間）において表示領域Ｂに表示される（図４６（ｆ））。このように、遊技者がＣＭを選択する操作を実行した場合には、遊技者が積極的にＣＭを視認したい場合であると考えられるため、ＣＵ制御部３２３は、広告を比較的大きい表示領域Ｂに比較的長い時間（１５秒間）内において表示するように設定し、表示制御部３５０は、当該設定に基づいて広告を表示させる。ただし、ＣＵ３は、表示領域Ｂ以外の領域の選択を受け付けたり、入金操作、カード挿入操作を受け付けたりした場合には、ＣＭを表示中であっても当該表示は解除される。
このように、ＣＵ制御部３２３は、「メニュー」ボタンに被らないように広告表示領域が設定することから、遊技者は常に「メニュー」ボタンを選択することが可能となる。そのため、一度「ＣＭ表示」ボタンを選択してＣＭ選択画面や選択されたＣＭが表示された場合であっても、「メニュー」ボタンを選択してメニュー画面枠を表示させることにより、容易にログイン操作などに移行することができる。
次に、図４７（ｇ）および図４８〜図５０を参照して、表示領域Ｃに広告が表示される場合について説明する。ここでは、遊技者がＣＵ３に対して返却操作または離席操作を行なった場合について考える。まず、カード返却操作の流れについて説明する。図４８、図４９は、カードユニットに対するカード返却操作の流れを説明するための画面遷移を示す図である。
図４８を参照して、ＣＵ３は、「返却」ボタンを選択する操作（表示対象操作「８」（丸で囲まれた８を示す）返却に相当）を受け付けると（図４８（ａ））、返却確認画面枠を表示する（図４８（ｂ））。返却確認画面枠には、「返却しますか？」とのメッセージ画面が表示される。図４８（ｂ）に示す返却確認画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。ただし、「呼出」ボタン、「遊技ガイド」ボタンおよび「操作説明」ボタンの操作は有効にしてもよい。ＣＵ３は、返却する指示（「はい」ボタンを選択する操作）を受け付けると、カードが返却され、カートの取り忘れを防止するための画面を表示する（図４９（ｃ））。つまり、返却操作が完了し、ＣＵ３は、返却操作を受け付けたと判断する。一方、ＣＵ３は、返却しない指示（「いいえ」ボタンを選択する操作）を受け付けると、図４８（ａ）の画面が表示されて遊技が継続される。
次に、離席操作の流れについて説明する。図５０は、離席操作の流れを説明するための画面遷移を示す図である。
図５０を参照して、ＣＵ３は、離席ボタンを選択する操作（表示対象操作「９」（丸で囲まれた９を示す）離席に相当）を受け付けると（図５０（ａ））、離席確認画面枠を表示する（図５０（ｂ））。離席確認画面枠には、「離席 ちょっとだけ席を離れるときに使ってね カードが返却されるから取り忘れに注意してね 離席返却されたカードは他の遊技台では使えないから必ず戻ってきてね」との注意喚起メッセージが表示される。図５０（ｂ）に示す離席確認画面枠の表示は、「トップ」ボタンや「球貸」ボタンなどと重なっており、当該ボタンの操作は無効である。ただし、「呼出」ボタン、「遊技ガイド」ボタンおよび「操作説明」ボタンの操作は有効にしてもよい。ＣＵ３は、離席する指示（「離席する」ボタンを選択する操作）を受け付けると、カードが返却され、カートの取り忘れを防止するための画面を表示する（図４９（ｃ））。つまり、離席操作が完了し、ＣＵ３は、離席操作を受け付けたと判断する。一方、ＣＵ３は、離席しない指示（「キャンセル」ボタンを選択する操作）を受け付けると、図５０（ａ）の画面が表示されて遊技が継続される。
ＣＵ制御部３２３は、上述した返却操作を受け付けた場合、および離席操作を受け付けた場合のいずれか一方の場合に、表示器５４の表示領域の全域を広告表示領域として設定する。具体的には、図４７（ｇ）に示すように、ＣＵ制御部３２３は、表示器５４の表示領域の全域である表示領域Ｃを広告表示領域として設定する。
また、ＣＵ制御部３２３は、比較的長い時間（たとえば、１５秒間）内において広告を表示するように設定する。表示制御部３５０は、設定された表示領域Ｃに広告を所定の時間内（たとえば、１５秒間）だけ表示する。このように、遊技者がカードを返却したり離席したりした場合のように、遊技機に遊技者が対峙しておらず遊技者の操作を妨げることがないような状況では、全域に比較的長い時間内において広告を表示する。
これにより、遊技者以外の他者に対する広告宣伝効果を高めることができる。ただし、ＣＵ制御部３２３が画面に対する選択操作を受け付けた場合、入金操作やカード挿入操作を受け付けた場合には、所定の時間内であってもＣＭ表示は解除される。
＜広告情報の管理＞
図５１は、本実施形態に係る広告情報の管理方式を説明するための概略図である。図５１に示すコンテンツ管理センタ８００Ｂのサーバ（以下「コンテンツ管理センタ８００Ｂ」という）は、ＣＵ３で再生された広告の再生実績を集計して広告情報として管理する。ここで、広告情報とは、広告としてＣＵ３で再生される音楽データ、画像データの実績を集計した情報である。コンテンツ管理センタ８００Ｂには、図示していないが制御中枢としてのＣＰＵ、ＣＰＵが動作するためのプログラムや制御データ等を記憶しているＲＯＭ、ＣＰＵのワークエリアとして機能するＲＡＭ、ＨＤＤなどの大容量記憶装置、周辺機器との信号の整合性を保つための入出力インターフェイス等が設けられている。以下、図５１に示す（１）〜（９）の符号に従い、広告情報の管理方式を具体的に説明する。なお、以下の説明では、説明の容易化のため、広告情報は、画像データの再生実績であり、当該画像データを「広告画像」という。
図５１は、本実施形態に係る広告情報の管理方式を説明するための概略図である。図５１に示すコンテンツ管理センタ８００Ｂのサーバ（以下「コンテンツ管理センタ８００Ｂ」という）は、ＣＵ３で再生された広告の再生実績を集計して広告情報として管理する。ここで、広告情報とは、広告としてＣＵ３で再生される音楽データ、画像データの実績を集計した情報である。コンテンツ管理センタ８００Ｂには、図示していないが制御中枢としてのＣＰＵ、ＣＰＵが動作するためのプログラムや制御データ等を記憶しているＲＯＭ、ＣＰＵのワークエリアとして機能するＲＡＭ、ＨＤＤなどの大容量記憶装置、周辺機器との信号の整合性を保つための入出力インターフェイス等が設けられている。以下、図５１に示す（１）〜（９）の符号に従い、広告情報の管理方式を具体的に説明する。なお、以下の説明では、説明の容易化のため、広告情報は、画像データの再生実績であり、当該画像データを「広告画像」という。
（１）Ｐ台２に対応するＣＵ３は、表示器５４において広告画像を再生する。以下、説明の容易化のため、「Ｐ台２に対応するＣＵ３の表示器５４で広告画像が再生される」ことを、単に「ＣＵ３で広告画像が再生される」と記載する。図５１の例では、Ｐ台２ａ（機種ＩＤ：機種Ａ）に対応するＣＵ３で広告画像Ａが再生中であり、Ｐ台２ｂ（機種ＩＤ：機種Ａ）に対応するＣＵ３で広告画像Ｂが再生中であり、Ｐ台２ｃ（機種ＩＤ：機種Ｂ）に対応するＣＵ３で広告画像Ｃが再生中であることを示している。
（２）各々のＰ台２に対応するＣＵ３は、広告画像が再生されたことを示す再生情報（たとえば、再生時「１」、非再生時「０」とする情報）、再生された広告画像の識別情報（たとえば、再生されている画像のコード）、その広告画像を再生したＣＵ３、およびＣＵ３に対応するＰ台２の特定情報（たとえば、機種ＩＤ）を関連付けて、記憶部Ａに記憶する。
広告画像の識別情報は、たとえば、画像名、画像コードである。また、Ｐ台２を特定するための特定情報は、たとえば、Ｐ台２の機種ＩＤ（機種名、機種コード）、メーカＩＤ（メーカ名、メーカコード）、主制御用セキュリティチップＩＤ、および払出制御用セキュリティチップＩＤの少なくともいずれかを含む。以下では、説明の容易化のため、広告画像の識別情報が画像コード、Ｐ台２の特定情報が機種ＩＤであるものとする。
ＣＵ３は、再生情報に基づいて、何らかの広告画像が再生されたことを検出し、画像コードに基づいて、その再生された広告画像がどの広告画像であるのかを識別することにより、再生された広告画像の再生実績を広告情報として収集する。ＣＵ３は、再生情報が検出された回数と画像コードとに基づいて、再生された広告画像の再生回数をカウントすることで当該再生実績を広告情報として収集する。つまり、ＣＵ３は、どの広告画像が、何回再生されたかという情報を含む再生実績を広告情報として収集する。ＣＵ３が収集する広告情報には、広告画像を再生した時刻などの情報を一緒に収集してもよい。広告情報に広告画像を再生した時刻の情報を収集することで、本来再生されるはずのない時刻（たとえば、営業時間外の時刻）に再生された情報を異常データとして広告情報から除外することができる。
さらに、ＣＵ３は、収集した広告画像の広告情報に、その広告画像を再生したＣＵ３に対応するＰ台２の機種ＩＤを関連付ける。ＣＵ３は、広告画像ごとに当該広告情報を内部ＲＡＭやハードディスクなどで構成される記憶部Ａに記憶する。このとき、記憶部Ａに記憶される広告情報は、どの広告画像が、どの機種において、何回再生されたかという情報を含む。記憶部Ａは、ＣＵ３に設けられる場合に限定されるものではなく、Ｐ台２およびＣＵ３の少なくともいずれか一方に設けられていればよい。遊技機に記憶部Ａを設ける場合、遊技盤２６の主制御基板１６の内部ＲＡＭや、遊技枠６の払出制御基板１７の内部ＲＡＭに記憶部Ａを設けてもよい。
なお、ＣＵ３が、広告情報を収集する際に、再生情報に基づいて再生回数をカウントする場合について説明したが、これに限られない。たとえば、ＣＵ３は、広告画像が再生されたことを示す再生情報を検出してから、当該再生の終了を示す終了信号を検出するまでの時間に基づいて再生時間を算出して、当該再生時間を広告情報として収集してもよい。
また、ＣＵ３は、広告画像の再生時における再生領域（広告表示領域）を示す領域情報を、記憶部Ａに記憶された当該広告画像の広告情報に関連付けてもよい。領域情報は、たとえば、図４４〜図４７で説明したような表示領域Ａ（小）、表示領域Ｂ（中）、表示領域Ｃ（大）を示す情報を含む。
また、ＣＵ３は、広告情報に広告画像が再生中に遊技をしていた遊技者の年齢および性別の情報を含めてもよい。たとえば、カメラ３９９は、遊技者の顔画像を撮影して、ＣＵ制御部３２３に出力する。そして、ＣＵ制御部３２３は、遊技者を撮像することで得られた撮像画像から当該遊技者の特徴量（たとえば、目、鼻、口および輪郭といった顔の各部分についての形や大きさ）を抽出する。ここで、特徴量には性別や年齢により傾向が見られるので、性別や年齢を判定できる。そのため、ＣＵ制御部３２３は、取得した特徴量と所定の基準値とを比較照合することにより、遊技者の年齢および性別を推定する。もちろん、管理サーバ１４０にログインしている場合、会員カードＩＤに対応付けて記憶してある会員属性情報から遊技者の年齢および性別の情報を読み出して使用してもよい。
上述したように、ＣＵ３は、広告情報を記憶部Ａに一旦記憶するので、ＣＵ３とユニット管理コンピュータ（ホールサーバ）８０１との間またはユニット管理コンピュータ８０１とコンテンツ管理センタ８００Ｂとの間で通信断が生じた場合でも、ＣＵ３で再生された広告画像の広告情報を記憶し続けることができ、通信復帰後にリカバリ処理を行なうことができる。つまり、ＣＵ３の記憶部Ａは、広告情報をユニット管理コンピュータ８０１やコンテンツ管理センタ８００Ｂへ送信するためのデータバッファとして機能させることができる。
（３）ＣＵ３は、記憶部Ａに記憶された広告情報をユニット管理コンピュータに送信する。具体的には、ＣＵ３は、定期的に（たとえば、１日に１回予め定められた時刻）、または広告情報の送信要求を外部（たとえば、ユニット管理コンピュータ８０１、コンテンツ管理センタ８００Ｂ）から受付けたときに、あるいはＣＵ３がオフライン状態からオンライン状態に復帰したときに広告情報をユニット管理コンピュータ８０１に送信する。
（４）ユニット管理コンピュータ８０１は、各々のＣＵ３から送信された広告情報を受信する。ユニット管理コンピュータ８０１は、受信した広告情報にＰ台２が設置された店舗情報を関連付ける。店舗情報は、たとえば、店舗の規模を示す情報（ホールの床面積、Ｐ台２の台数）を含む。
（５）各店舗のユニット管理コンピュータ８０１は、ＣＵ３から受信した広告情報に店舗情報を関連付けた広告情報をコンテンツ管理センタ８００Ｂに送信する。具体的には、ユニット管理コンピュータ８０１は、定期的に（たとえば、１日に１回予め定められた時刻）、または広告情報の送信要求を外部（たとえば、コンテンツ管理センタ８００Ｂ）から受付けたときに、あるいはユニット管理コンピュータ８０１がオフライン状態からオンライン状態に復帰したときに当該広告情報をコンテンツ管理センタ８００Ｂに送信する。
（６）コンテンツ管理センタ８００Ｂは、所定の条件で、各々のホールに設置されているユニット管理コンピュータ８０１から広告情報を受信してホールごとに集計する。具体的には、コンテンツ管理センタ８００Ｂは、定期的に（たとえば、１日に１回予め定められた時刻）、または広告情報の送信要求をユニット管理コンピュータ８０１に行なうことで、あるいはコンテンツ管理センタ８００Ｂがオフライン状態からオンライン状態に復帰したときに当該広告情報をユニット管理コンピュータ８０１から受信する。そして、コンテンツ管理センタ８００Ｂは、ホールごとに集計した広告情報を広告実績テーブルとして記憶部Ｂに記憶する。換言すると、コンテンツ管理センタ８００Ｂは、各ホールのユニット管理コンピュータ８０１から送信された広告情報を受信してホールごとの広告情報を集計し、記憶部Ｂに記憶された広告実績テーブルに蓄積して、広告情報を管理している。なお、コンテンツ管理センタ８００Ｂは、広告情報をホールごとに集計するという所定の条件で広告情報を集計しているが、これに限定されるものではなく、たとえば広告情報を遊技機メーカごとに集計することや、広告情報を機種ごとに集計することを所定の条件としてもよい。
図５２は、本実施形態に係る広告実績テーブルの概略図である。図５２に示す広告実績テーブルには、ホールごとに、当該ホールに設置されているＰ台２に対応するＣＵ３で再生された広告画像の広告情報が記憶されている。広告実績テーブルは、広告画像ごとに、機種、再生回数、再生時間、再生領域、および遊技者の性別を示す情報を含む。なお、図５２に示す広告実績テーブルには、図示していないが３０代や４０代などの遊技者の年齢の情報を追加してもよい。ここで、具体例として、店舗Ａの広告情報について説明する。店舗Ａでは、広告画像Ａは、機種Ａに対応するＣＵ３おいて、男性の遊技中に表示領域Ｂ（中）で１２回再生され、その再生時間が１８０秒であり、女性の遊技中に表示領域Ｃ（大）で８回再生され、その再生時間が１２０秒であったことを示している。また、広告画像Ａは、機種Ｂおよび機種Ｃに対応するＣＵ３では再生されていないことを示している。
広告画像Ｂは、機種Ｂに対応するＣＵ３において、女性の遊技中に表示領域Ａ（小）で２０回再生され、その再生時間が８０秒であったことを示している。広告画像Ｃは、機種Ｃに対応するＣＵ３において、男性の遊技中に表示領域Ｃ（大）で５回再生され、その再生時間が７５秒であり、女性の遊技中に表示領域Ｂ（中）で３回再生され、その再生時間が４５秒であったことを示している。広告画像Ｄは、機種Ａに対応するＣＵ３において、男性の遊技中に表示領域Ａ（小）で１０回再生され、その再生時間が４０秒であり、機種Ｂに対応するＣＵ３において、男性の遊技中に表示領域Ａ（小）で６回再生され、その再生時間が２４秒であり、機種Ｃに対応するＣＵ３において、女性の遊技中に表示領域Ｂ（中）で３回再生され、その再生時間が４５秒であったことを示している。
コンテンツ管理センタ８００Ｂは、このような様々な情報を含む広告実績テーブルを有しているため、広告を提供した広告料の様々な算定方式に対して、適切な情報を提供することができる。図５２の例では、コンテンツ管理センタ８００Ｂは、たとえば、再生回数、再生時間、再生領域、遊技店の規模に応じて広告料が算定される方式に対して、適切な情報を提供することができる。
（７）再び、図５１を参照して、コンテンツ管理センタ８００Ｂは、広告画像と、Ｐ台２に対応するＣＵ３での当該広告画像の再生が許可されている当該Ｐ台２の機種ＩＤとの対応関係を示す対応関係情報テーブルを記憶する記憶部Ｃをさらに含む。
図５３は、本実施形態に係る対応関係情報テーブルの概略図である。図５３の例では、広告画像Ａは、機種Ａに対応するＣＵ３でのみ再生が許可されており、広告画像Ｂは、機種Ｂに対応するＣＵ３でのみ再生が許可されており、広告画像Ｃは、機種Ｃに対応するＣＵ３でのみ再生が許可されており、広告画像Ｄは、機種Ａ、機種Ｂ、機種Ｃにそれぞれ対応するＣＵ３で再生が許可されていることを示している。たとえば、広告画像Ｄは、遊技機メーカと無関係な広告であり、機種に依存することなく再生される。しかし、広告画像Ａは、機種Ａを製造している遊技機メーカの広告であり、機種Ａが設置してあるＣＵ３でのみ再生される。
再び、図５１を参照して、コンテンツ管理センタ８００Ｂは、典型的には、遊技機メーカから入力された情報に基づいて、図５３に示したような対応関係情報テーブルを記憶部Ｃに記憶する。遊技機メーカは、コンテンツ管理センタ８００Ｂからの要求に応じて、出荷済みのＰ台２の機種ＩＤと、当該Ｐ台２で再生が許可されている広告画像との対応関係情報テーブルをコンテンツ管理センタ８００Ｂに送信する。あるいは、遊技機メーカは、Ｐ台２を出荷する際に、Ｐ台２の出荷履歴を管理している機歴管理センタ８００Ａ（図３参照）に出荷情報を入力するときに、当該出荷されたＰ台２の機種ＩＤと当該Ｐ台２で再生が許可されている広告画像との対応関係情報テーブルをコンテンツ管理センタ８００Ｂに送信する。コンテンツ管理センタ８００Ｂは、受信した対応関係情報テーブルを記憶部Ｃに記憶する。このように、コンテンツ管理センタ８００Ｂは、対応関係情報テーブルを遊技機メーカから容易に取得することができる。また、コンテンツ管理センタ８００Ｂは、遊技機メーカがＰ台２を出荷する際に対応関係情報テーブルが入力されるため、当該対応関係情報テーブルを確実に取得することができる。なお、コンテンツ管理センタ８００Ｂは、遊技機メーカから対応関係情報テーブルを直接取得する場合だけでなく、機歴管理センタ８００Ａを経由して対応関係情報テーブルを取得してもよい。
（８）コンテンツ管理センタ８００Ｂは、記憶部Ｂに記憶された広告実績テーブルと、記憶部Ｃに記憶された対応関係情報テーブルとに基づいて、Ｐ台２で許可されていない広告画像がＣＵ３で再生されたか否かを判定する。具体的には、コンテンツ管理センタ８００Ｂは、ある機種のＰ台２で本来再生される可能性のない広告画像についての広告情報が存在するか否かを判定する。図５２および図５３の例では、広告画像Ａ，Ｂ，Ｃ，Ｄは、すべて、再生が許可されている機種に対応するＣＵ３で再生されているため、コンテンツ管理センタ８００Ｂは、広告画像の管理に異常はないと判定する。これに対して、たとえば、広告画像Ａが機種Ｂに対応するＣＵ３で再生されていることを示す広告情報が存在する場合には、コンテンツ管理センタ８００Ｂは、機種Ｂにおいて許可されていない広告画像が再生されていると判定して、異常を報知する。具体的には、コンテンツ管理センタ８００Ｂは、管理者に異常な広告情報が存在することを連絡したり、異常な広告情報が存在する店舗に連絡したりすることで異常を報知する。なお、異常な広告情報と判定する条件は、前述の条件に限定されるものではなく、たとえば、広告情報としてあり得ない再生時間（１回の再生が１時間など）や、広告情報としてあり得ない再生回数（１分間に１０００回）などの条件でもよい。また、異常な広告情報と判定する条件として、登録されていない店舗から送信されてきた広告情報などがある。
また、コンテンツ管理センタ８００Ｂは、記憶部Ｃに格納された対応関係情報テーブルをユニット管理コンピュータ８０１、または店舗に設置されている各ＣＵ３に送信してもよい。そして、ＣＵ３は、接続されている遊技機の機種と、対応関係情報テーブルとを比較照合することで、当該機種で許可されていない広告画像は再生しないように制御してもよい。
（９）コンテンツ管理センタ８００Ｂは、記憶部Ｂに記憶された広告情報のうち異常がない広告情報について、必要がある場合に外部に出力する。具体的には、コンテンツ管理センタ８００Ｂは、広告情報に基づいて広告料を管理する管理団体に対して、広告情報の送信要求に応じて、その要求先に広告情報を送信する。また、コンテンツ管理センタ８００Ｂは、広告情報の送信要求に応じて、その要求先に広告情報を送信するのではなく、当該送信先に定期的に広告情報を送信してもよい。広告情報の送信先としては、たとえば、広告情報に基づいて広告画像を提供した広告料を配分する会社などが想定される。また、コンテンツ管理センタ８００Ｂは、図３に示すように鍵管理サーバ８００を介して機歴管理センタ８００Ａに接続されているので、外部に広告情報を出力する場合、機歴管理センタ８００Ａを経由して広告情報を外部に出力してもよい。
＜鍵管理サーバから通信制御ＩＣまでの間の通信に使用される暗号鍵＞
次に、鍵管理サーバから通信制御ＩＣまでの間の通信に使用される暗号鍵について説明する。図５４は、鍵管理サーバから通信制御ＩＣ３２５ａまでの間の通信に使用される暗号鍵を説明するための図である。まず、鍵管理サーバから通信制御ＩＣ３２５ａまでの間の通信に使用される暗号鍵には、主に基板出荷鍵、基板初期鍵、基板認証鍵、本認証鍵、仮認証鍵、有効鍵（商用）、通信鍵１（セッション鍵）および通信鍵２（セッション鍵）がある。基板出荷鍵は、ＣＵ制御部−ＳＣの間の通信に利用され、出荷以前での通信テスト電文の暗号にのみ使用される。基板初期鍵は、ＣＵ制御部−ＳＣの通信に利用され、ホールサーバとの最初の通信時にＣＵ制御部３２３が受信し、ＣＵ制御部３２３のＲＡＭに記憶される。ＳＣ３２５ｂは、製造時の埋め込み情報から基板初期鍵を生成してＲＡＭに記憶する。基板初期鍵を用いた認証用通信（基板初期鍵モード）は限られた期間のみ許容（時限的運用）される。ここで、基板初期鍵モードは、前述したように、ホールサーバと少なくとも１回は正常に通信して、基板初期鍵を取得する必要があるため、セキュリティ性は担保されている。
次に、鍵管理サーバから通信制御ＩＣまでの間の通信に使用される暗号鍵について説明する。図５４は、鍵管理サーバから通信制御ＩＣ３２５ａまでの間の通信に使用される暗号鍵を説明するための図である。まず、鍵管理サーバから通信制御ＩＣ３２５ａまでの間の通信に使用される暗号鍵には、主に基板出荷鍵、基板初期鍵、基板認証鍵、本認証鍵、仮認証鍵、有効鍵（商用）、通信鍵１（セッション鍵）および通信鍵２（セッション鍵）がある。基板出荷鍵は、ＣＵ制御部−ＳＣの間の通信に利用され、出荷以前での通信テスト電文の暗号にのみ使用される。基板初期鍵は、ＣＵ制御部−ＳＣの通信に利用され、ホールサーバとの最初の通信時にＣＵ制御部３２３が受信し、ＣＵ制御部３２３のＲＡＭに記憶される。ＳＣ３２５ｂは、製造時の埋め込み情報から基板初期鍵を生成してＲＡＭに記憶する。基板初期鍵を用いた認証用通信（基板初期鍵モード）は限られた期間のみ許容（時限的運用）される。ここで、基板初期鍵モードは、前述したように、ホールサーバと少なくとも１回は正常に通信して、基板初期鍵を取得する必要があるため、セキュリティ性は担保されている。
ここで、「限られた期間」とは、たとえば、２日間という限定的期間である。このように、時限的運用を可能にすることによって、ホールにシステムを導入した段階ですぐに鍵管理サーバとの鍵交換ができない場合であっても、システムの導入直後からホールは営業を開始することが可能となる。なお、限定的期間としては、たとえば、毎朝９時〜１７時までの間という具合に、１日の中での定めた期間を設定してもよい。
なお、前述の基板初期鍵モードは、基板初期鍵を用いた認証用通信を限られた期間可能にする制限を設けているが、本発明はこれに限定されるものではなく、使用できる金額（カード残額、あるいは現金）を制限してもよい。あるいは、可変表示装置における図柄の変動回数が一定回数に達した場合にゲームを強制終了させて遊技機を不能動化状態に制御してもよい。または、大当たりの累積回数が一定回数に達した場合にゲームを強制終了させて遊技機を不能動化状態に制御してもよい。その他、現金を投入することによる遊技のみを許容してカード残額を使用した遊技ができないようにしてもよく、持玉を使用した遊技のみに制限するようにしてもよい。
基板認証鍵は、ＣＵ制御部−ＳＣの間の通信に利用され、鍵管理サーバより基板セキュリティ情報の一部として受信する暗号鍵である。基板認証鍵を用いた認証用通信を行なうことで、基板初期鍵を用いた時限的運用から恒久的運用（通常運用）に通信モード（基板認証鍵モード）が切換わる。この基板認証鍵は、ＣＵ制御部のＲＡＭとＳＣのＲＡＭとに記憶される。
基板初期鍵を用いた時限的運用および基板認証鍵を用いた恒久的運用のいずれについても、ホールサーバに記憶された有効鍵をＣＵ制御部３２３が受信し、ＳＣ３２５ｂがその有効鍵を通信制御ＩＣ３２５ａに対して設定することによりＰ台とＣＵとの間の通信が可能となることで実現される。
本認証鍵は、ＳＣ−通信制御ＩＣの間の通信に利用され、鍵管理サーバから受信した更新情報から、ＳＣ３２５ｂにより生成されてＳＣ３２５ｂのＲＡＭに記憶されるとともに、通信制御ＩＣ３２５ａにおいてもＳＣ３２５ｂと同様に更新情報から生成されて通信制御ＩＣ３２５ａのＲＡＭに記憶される。なお、この本認証鍵は、鍵管理サーバなどから本認証鍵そのものを取得するようにしてもよい。また、鍵管理サーバなどから更新情報を受信することなくＣＵ制御部３２３と通信制御ＩＣ３２５ａとが自ら生成してもよい。さらに、鍵管理サーバなどから所定の第１データを取得するとともにＣＵ制御部３２３と通信制御ＩＣ３２５ａとが自ら所定の第２データを生成し、それら第１データと第２データとから本認証鍵を生成するようにしてもよい。
仮認証鍵は、ＳＣ−通信制御ＩＣの間の通信に利用され、本認証鍵が生成されるまでの間（又は設定された許容時間（たとえば２日）が経過するまでの間）、ＳＣ３２５ｂと通信制御ＩＣ３２５ａとの間での暗号通信に使用される。この仮認証鍵による暗号通信（仮認証鍵モード）は限られた期間（たとえば２日）のみ許容（時限的運用）される。ＳＣ３２５ｂおよび通信制御ＩＣ３２５ａは、製造段階から仮認証鍵をそれぞれのＲＯＭに記憶している。有効鍵（商用）は、ホールサーバとの最初の通信時にＣＵ制御部３２３経由でＳＣ３２５ｂが受信し、通信制御ＩＣ３２５ａに対して送信（設定）する鍵である。有効鍵が設定されることによってＰ台との通信が可能になる。なお、有効鍵は、通信制御ＩＣ３２５ａ活性化用のデータである。換言すると、有効鍵は、ＣＵとＰ台との間の通信を許可するための許可情報である。
通信鍵１（セッション鍵）は、ＣＵ制御部−ＳＣの間の通信に利用され、対遊技機用の業務電文通信に用いられ、ＳＣ３２５ｂが何らかの変数を用いて、毎営業日作成している。該変数として、たとえば、カウンタ値（乱数）や日時情報などを用いてもよい。通信鍵２（セッション鍵）は、ＳＣ−通信制御ＩＣの間の通信に利用され、対遊技機用の業務電文通信に用いられる。
なお、前述に説明した鍵は、鍵のデータがそれぞれの部分にそのまま埋込まれている構成であっても、鍵のデータを生成するための情報がそれぞれの部分に記憶されていて、該情報を利用いて鍵のデータを生成する構成であってもよい。
次に、暗号鍵の取得方法と、取得した暗号鍵を用いて暗号通信を行なう方法について説明する。まず、ＳＣ３２５ｂは、ホールサーバとの最初の通信時にＣＵ制御部３２３経由で有効鍵を取得する。ＳＣ３２５ｂは、取得した有効鍵を通信制御ＩＣ３２５ａに対して送信（設定）することで、Ｐ台との通信が可能になる。ＣＵ制御部３２３はホールサーバとの最初の通信時に基板初期鍵を受信し、ＣＵ制御部３２３のＲＡＭに記憶される。ＳＣ３２５ｂは、製造時の埋め込み情報から基板初期鍵を生成してＲＡＭに記憶する。ＳＣ３２５ｂは、取得した基板初期鍵を用いてＣＵ制御部３２３と暗号認証を行ない、該基板初期鍵を用いて時限的にＣＵ制御部３２３と暗号通信を行なう。また、電源投入時にＣＵ制御部３２３から送られてきた接続要求を受信したホールサーバは、当該ホールサーバが設置されている遊技場を識別するための統一店舗コードをＣＵ制御部３２３へ返信する。具体的には、ホールサーバのＣＰＵの制御にしたがってホールサーバの入出力インターフェイスからＣＵ制御部３２３へ統一店舗コードが送信される。
一方、ＣＵ制御部３２３とＳＣ３２５ｂとの間では、両者に初期情報として記憶されている基板メーカコードを用いた認証が行なわれる。基板メーカコードとは、セキュリティ基板３２５を製造したメーカを特定するコードのことである。基板メーカコードを用いた認証に成功したことを条件として、基板接続要求と基板接続応答とのやり取りが行なわれる（図５８参照）。ＣＵ制御部３２３からＳＣ３２５ｂへ送信される基板接続要求の中に上記統一店舗コードが含まれており、基板接続要求を受信することによりＳＣ３２５ｂが統一店舗コードを取得する。
次に、ＣＵ制御部３２３は、鍵管理サーバに対して基板セキュリティ情報を要求し、鍵管理サーバがホールサーバを介して送信してきた基板セキュリティ情報を受信することで、該基板セキュリティ情報に含まれる基板認証鍵を取得する。ＣＵ制御部は、取得した基板認証鍵を用いてＳＣと暗号認証を行ない、該基板認証鍵を用いてＳＣと暗号通信を行なう。なお、ＣＵ制御部３２３は、基板認証鍵を取得後すぐに基板初期鍵から基板認証鍵に鍵を変更するのではなく、後述するように遊技機が非稼動状態になっていることを条件にして鍵を変更する。
この基板認証鍵は、鍵管理サーバなどから取得する代わりに、ＣＵ制御部３２３が自ら生成してもよく、また、鍵管理サーバなどから所定の第１データを取得するとともにＣＵ制御部３２３が自ら所定の第２データを生成し、それら第１データと第２データとから基板認証鍵を生成するようにしてもよい。
次に、ＳＣ３２５ｂは、記憶してある仮認証鍵を用いて通信制御ＩＣ３２５ａと暗号通信を行なう。そして、ＳＣは、基板認証鍵を用いてＣＵ制御部と暗号通信を行なうことで鍵管理サーバから取得した更新情報を仮認証鍵で復号し、基板問合せ番号を照会する。ＳＣは、照会した基板問合せ番号が一致した場合、更新情報から本認証鍵を生成し、生成した本認証鍵を用いて通信制御ＩＣ３２５ａと暗号通信を行なう。なお、本認証鍵は、通信制御ＩＣ３２５ａにおいても出荷時から記憶されているものではなく、ＳＣ３２５ｂと同様に更新情報から生成される。
次に、ＳＣは、ＣＵ制御部に対して通信鍵１を通知し、以降のＣＵ制御部との間の通信を、通信鍵１を用いて行なうことで、遊技機との業務電文通信が可能となる。また、ＳＣは、通信制御ＩＣに対して有効鍵を設定することで、通信制御ＩＣから通信鍵２の通知を受け、以降の通信制御ＩＣとの間の通信を、通信鍵２を用いて行なうことで、遊技機との業務電文通信が可能となる。
＜ＣＵ制御部とＳＣとの通信における主なシーケンス＞
次に、図５５〜図６５に基づいて、ＣＵ制御部３２３におけるＣＰＵで実行される処理と、セキュリティチップ（ＳＣ）３２５ｂで実行される処理とを説明する。
次に、図５５〜図６５に基づいて、ＣＵ制御部３２３におけるＣＰＵで実行される処理と、セキュリティチップ（ＳＣ）３２５ｂで実行される処理とを説明する。
まず、図５５を参照して、ＣＵ制御部３２３の電源投入・ホール設置時の立上の処理を説明する。この図５５は、ＣＵ３が遊技場に設置されて最初に電源を立上げたときのシーケンスであり、特に、基板初期鍵を用いたホール設置時の立上シーケンスについて説明する。
まず、ＣＵ３の電源を投入すると、ＣＵ制御部３２３およびＳＣ３２５ｂが起動される。ＣＵ３が遊技場に設置されて最初に電源を立上げたときに、ＣＵ制御部３２３は、上位装置より（具体的にはホールサーバより）基板初期鍵Ａ、基板初期鍵ＡのＭＡＣ鍵、有効鍵（商用／Ｐ台出荷用）を取得する。ここで、基板初期鍵Ａは、遊技場に納入されてから最初に上位装置へ通信する時、ホールサーバからダウンロードしてＣＵ制御部３２３に記憶する暗号鍵であり、鍵管理センタに設置された鍵管理サーバに記憶されている基板情報（基板シリアルＩＤと基板認証鍵）が取得されるまで、ＣＵ制御部３２３とＳＣ３２５ｂとの通信に利用する暗号鍵である。なお、基板初期鍵Ａは、基板メーカコードを用いて復号され、一方、基板初期鍵ＡのＭＡＣ鍵も同様に、基板メーカコードを用いて復号される。これらの復号は、ＡＥＳ（Advanced Encryption Standard）の暗号方式に則った復号方式で行なわれる。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、基板メーカコード認証シーケンス、基板初期鍵認証シーケンス、セキュリティ基板情報問合せシーケンスを実行する。
基板メーカコード認証シーケンスは、チャレンジ／レスポンス方式を用いて、ＣＵ制御部３２３とＳＣ３２５ｂとの間で基板メーカコードを認証する。基板メーカコード認証シーケンスの処理後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵にホールサーバより取得した基板初期鍵を用い、基板初期鍵認証シーケンスを行ない、基板初期鍵認証が完了した場合に認証ＯＫとなる。なお、基板初期鍵認証シーケンスの詳細な処理については、後述する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵にホールサーバより取得した基板初期鍵を用い、セキュリティ基板情報問合せシーケンスを行ない、セキュリティ基板情報を取得することができた場合に取得ＯＫとなる。セキュリティ基板情報は、鍵管理センタの鍵管理サーバから取得し、基板シリアルＩＤや基板認証鍵などを含んでいる。なお、セキュリティ基板情報問合せシーケンスの詳細な処理については、後述する。基板認証鍵は、鍵管理センタに設置された鍵管理サーバからダウンロードしてＣＵ制御部３２３とＳＣ３２５ｂとの通信に利用する暗号鍵である。鍵管理サーバは、基板シリアル番号等に対応付けて基板認証鍵を記憶している。
セキュリティ基板情報問合せシーケンスでセキュリティ基板情報を取得することができた場合、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａとの間で認証を実行する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵にホールサーバより取得した基板初期鍵を用い、通信鍵交換シーケンスを行ない、業務電文通信用の通信鍵を交換する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に基板初期鍵を用い、通信鍵交換シーケンスを行ない、通信鍵を生成する。通信鍵交換シーケンスでは、基板情報取得シーケンスで基板情報を取得できた場合、基板認証鍵を暗号鍵に用いるが、基板情報を取得できなかった場合、基板初期鍵を時限的に暗号鍵に用いる。通信鍵の生成方法は、具体的には、乱数と現在時刻のデータとを用いて生成する。この通信鍵（セッション鍵）の生成方法は、乱数と現在時刻のデータとに限らず、暗号通信を行なう装置間での相互認証に用いた鍵以外の可変データであれば、いかなるものを用いてもよい。なお、通信鍵交換シーケンスは、遊技機による遊技を可能にするために遊技機との暗号通信に用いる鍵（通信化鍵）を交換するものであり、その詳細な処理については、後述する。
通信鍵交換シーケンスで通信鍵を生成できた場合、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａから遊技機チップ情報を取得する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に通信鍵交換シーケンスより取得した通信鍵を用い、遊技機チップ情報問合せシーケンスを行ない、遊技機チップ情報を問合せ／通知する。遊技機チップ情報には、主制御チップ番号や払出制御チップ番号などが含まれている。なお、遊技機チップ情報認証シーケンスの詳細な処理については、後述する。
以上の処理を行なうことで、ＣＵ制御部３２３およびＳＣ３２５ｂは、遊技機と業務電文通信が可能となる。この遊技機と業務電文通信を行なうことにより遊技機において遊技が可能となる。この遊技機との業務電文通信には、通信鍵（セッション鍵）を利用して運用される。このときの通信は、前述したように、時限的な通信であり、一定期間（たとえば、２日）のみ許容される。以上の処理を経て行なわれる通信モードが制限通信モード（基板初期鍵モード（基板初期鍵運用））である。この時限運用のまま一定期間（たとえば、２日）がオーバーした場合には仮運用が停止されるとともに、オーバーしたことがＳＣ３２５ｂからＣＵ制御部３２３、ホールサーバを経由して鍵管理サーバへ通知される。
その後、ＣＵ３は、Ｐ台２に対して、リカバリ要求を行ない、Ｐ台２は、前回最終送信通番、前回挿入中カードＩＤ、前回カード挿入時刻を含むリカバリ応答のレスポンス（リカバリ応答）をＣＵ３に返信する。
次に、図５６を参照して、ＣＵ制御部３２３の電源投入・通常立上の処理を説明する。この図５６は、ＣＵ３が遊技場に設置された後、通常に電源を立上げたときのシーケンスであり、特に、基板認証鍵を用いた立上シーケンスについて説明する。
まず、ＣＵ３の電源を投入すると、ＣＵ制御部３２３およびＳＣ３２５ｂが起動される。ＣＵ３が遊技場に設置されて最初に電源を立上げたときに、ＣＵ制御部３２３は、上位装置より（具体的には鍵管理サーバより、ホールサーバを経由して）基板シリアルＩＤ鍵、基板認証鍵バージョン、基板認証鍵Ａ、基板認証鍵ＡのＭＡＣ鍵を取得する。なお、基板シリアルＩＤ鍵は、基板初期鍵で復号され、基板初期鍵Ａは、基板シリアルＩＤを用いて復号され、さらに、基板初期鍵ＡのＭＡＣ鍵も同様に、基板シリアルＩＤを用いて復号される。これらの復号は、ＡＥＳの暗号方式に則った復号方式で行なわれる。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、基板メーカコード認証シーケンス、基板認証鍵認証シーケンス、セキュリティ基板情報問合せシーケンスを実行する。
基板メーカコード認証シーケンスは、チャレンジ／レスポンス方式を用いて、ＣＵ制御部３２３とＳＣ３２５ｂとの間で基板メーカコードを認証する。基板メーカコード認証シーケンスの処理後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に鍵管理サーバより取得した基板認証鍵を用い、基板認証鍵認証シーケンスを行なう。なお、基板認証鍵認証シーケンスの詳細な処理については、後述する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、鍵の更新が有る場合にのみ、暗号鍵に鍵管理サーバより取得した基板認証鍵を用い、セキュリティ基板情報問合せシーケンスを行なう。
基板認証鍵認証シーケンスで基板認証鍵を認証でき鍵更新が無かった場合や、鍵更新が有り、セキュリティ基板情報問合せシーケンスで認証ができると、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａとの間で認証を実行する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に基板認証鍵を用い、通信鍵交換シーケンスを行ない、通信鍵を生成する。通信鍵の生成方法は、具体的には、乱数と現在時刻のデータとを用いて生成する。この通信鍵（セッション鍵）の生成方法は、乱数と現在時刻のデータとに限らず、暗号通信を行なう装置間での相互認証に用いた鍵以外の可変データであれば、いかなるものを用いてもよい。なお、通信鍵交換シーケンスは、遊技機による遊技を可能にするために遊技機との暗号通信に用いる鍵（通信化鍵）を交換するものであり、その詳細な処理については、後述する。
通信鍵交換シーケンスで通信鍵を生成することができた場合、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａから遊技機チップ情報をさらに取得する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に通信鍵交換シーケンスより取得した通信鍵を用い、遊技機チップ情報問合せシーケンスを行ない、遊技機チップ情報を問合せ／通知する。遊技機チップ情報には、主制御チップ番号や払出制御チップ番号などが含まれている。なお、遊技機チップ情報認証シーケンスの詳細な処理については、後述する。
以上の処理を行なうことで、ＣＵ制御部３２３およびＳＣ３２５ｂは、遊技機と業務電文通信が可能となる。この遊技機と業務電文通信を行なうことにより遊技機において遊技が可能となる。この遊技機との業務電文通信には、通信鍵（セッション鍵）が利用される。このときの通信は、制限通信モードのような制限のない通常通信モード（基板認証鍵モード（基板認証鍵運用））である。
次に、図５７を参照して、ＣＵ制御部３２３の電源投入・工場出荷時立上の処理を説明する。この図５７は、ＣＵ３が遊技場に出荷される前の工場出荷時のシーケンスを示し、特に、基板出荷鍵を用いた工場出荷立上シーケンスについて説明する。当該シーケンスは、工場出荷時、上位装置に接続していない状態のＣＵ制御部３２３およびＳＣ３２５ｂにおける処理である。
まず、ＣＵ３の電源を投入すると、ＣＵ制御部３２３およびＳＣ３２５ｂが起動される。ＣＵ制御部３２３およびＳＣ３２５ｂは、基板メーカコード認証シーケンス、基板初期鍵認証シーケンスを実行する。
基板メーカコード認証シーケンスは、チャレンジ／レスポンス方式を用いて、ＣＵ制御部３２３とＳＣ３２５ｂとの間で基板メーカコードを認証する。基板メーカコード認証シーケンスの処理後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に基板初期鍵を用い、基板初期鍵認証シーケンスを行なう。しかし、工場出荷時の段階のため未だ遊技場にＣＵ３が設置されていないため、遊技場のホールサーバより基盤初期鍵をＣＵ制御部３２３が取得できておらず、その結果、基板初期鍵認証の結果がＮＧとなる。
その後、ＣＵ制御部３２３は、基板初期鍵認証シーケンスが認証ＮＧとなったため、ＣＵ制御部３２３は、ＳＣ３２５ｂにセキュリティ基板３２５のテストに用いる基板出荷鍵を要求する、基板出荷鍵要求のコマンドをＳＣ３２５ｂに送信する。ＳＣ３２５ｂは、ＣＵ制御部３２３から基板出荷鍵要求のコマンドを受信後、基板出荷鍵を含む基板出荷鍵応答のレスポンスをＣＵ制御部３２３に送信する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵にＳＣ３２５ｂより取得した基板出荷鍵を用い、基板出荷鍵認証シーケンスを行なう。なお、基板出荷鍵認証シーケンスの詳細な処理については、後述する。
基板出荷鍵認証シーケンスで基板出荷鍵を認証できた場合、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａとの間で認証を実行する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に基板出荷鍵を用い、通信鍵交換シーケンスを行ない、通信鍵を生成する。通信鍵の生成方法は、具体的には、乱数と現在時刻のデータとを用いて生成する。この通信鍵（セッション鍵）の生成方法は、乱数と現在時刻のデータとに限らず、暗号通信を行なう装置間での相互認証に用いた鍵以外の可変データであれば、いかなるものを用いてもよい。なお、通信鍵交換シーケンスは、遊技機による遊技を可能にするために遊技機との暗号通信に用いる鍵（通信化鍵）を交換するものであり、その詳細な処理については、後述する。
通信鍵交換シーケンスで通信鍵を生成できた場合、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａから遊技機チップ情報を取得する。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に通信鍵交換シーケンスより取得した通信鍵を用い、遊技機チップ情報問合せシーケンスを行ない、遊技機チップ情報を問合せ／通知する。遊技機チップ情報には、主制御チップ番号や払出制御チップ番号などが含まれている。なお、遊技機チップ情報認証シーケンスの詳細な処理については、後述する。
その後、ＣＵ３は、Ｐ台２に対して、通信テスト要求を行ない、Ｐ台２は通信テスト応答をＣＵ３に送信する。
以上の処理を行なうことで、ＣＵ制御部３２３およびＳＣ３２５ｂは、遊技機と通信テスト電文のみの通信が可能となる。この通信テスト電文の通信を行なうことにより工場出荷時の通信テストが行われる。この工場出荷時の通信テストに合格したＣＵ３が遊技場に納入されて最初の電源立上時のシーケンスが図５５で説明したホール設置立上シーケンスであり、その後基板認証鍵の取得後に実行されるシーケンスが図５６で説明した通常立上シーケンスである。
次に、図５８を参照して、基板メーカコードの認証シーケンスの処理を説明する。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板メーカコードの認証を要求する基板メーカコード認証要求１のコマンドを送信する。なお、基板メーカコード認証は、チャレンジ／レスポンス方式を用いて行なうため、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、チャレンジコードを要求する。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板メーカコードの認証を要求する基板メーカコード認証要求１のコマンドを送信する。なお、基板メーカコード認証は、チャレンジ／レスポンス方式を用いて行なうため、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、チャレンジコードを要求する。
基板メーカコード認証要求１のコマンドを受信したＳＣ３２５ｂは、基板メーカコードに基づくチャレンジコードを生成し、生成したチャレンジコードを基板メーカコード認証応答１のレスポンスでＣＵ制御部３２３に通知する。
基板メーカコード認証応答１のコマンドを受信したＣＵ制御部３２３は、チャレンジコードに基づくレスポンスコードを生成し、生成したレスポンスコードを基板メーカコード認証要求２のコマンドでＳＣ３２５ｂに通知する。具体的には、基板メーカコードを鍵として受信したチャレンジコードを暗号化してレスポンスコードを生成する。
基板メーカコード認証要求２のコマンドを受信したＳＣ３２５ｂは、レスポンスコードをチェックして（具体的には基板メーカコードを鍵としてレスポンスコードを復号してチャレンジコードを抽出して）チャレンジコードが一致すればチェック結果がＯＫであるとする。そして、当該チェック結果を基板メーカコード認証応答２のレスポンスでＣＵ制御部３２３に通知する。このとき、ＣＵ制御部３２３は、基板メーカコード認証結果などの認証ログ情報をＳＣ３２５ｂから取得する。
一方、チャレンジコードが一致しなければチェック結果がＮＧ（不適正）であるとする。その場合に、ｎ回際認証を繰り返し、ｎ回連続でＮＧの場合にＳＣ３２５ｂが無応答状態（ＨＡＬＴ）となり、基板認証鍵と本認証鍵とがクリアされる（図７１参照）。この無応答状態（ＨＡＬＴ）となった後には、ＳＣ３２５ｂが通信制御ＩＣ３２５ａと認証を行なうことはなく、工場で修理を行なうこととなる。
ＣＵ制御部３２３は、ＳＣ３２５ｂにＣＵ制御部固有情報（統一店舗コード、台番、現在時刻）を通知して、遊技機との接続を要求する基板接続要求のコマンドを送信する。
ＳＣ３２５ｂは、ＣＵ制御部３２３からの基板接続要求のコマンドを受信後、統一店舗コード、台晩、現在時刻の情報を保持し、前回の統一店舗コードが一致しているときは、ＣＵ制御部３２３に対して接続要求を受付けた（ＯＫ）ことを通知する基板接続応答のレスポンスを返信する。
一方、前回の統一店舗コードと不一致であるときは、ＣＵ制御部３２３に対して接続要求を受付けていない（ＮＧ）ことを通知する基板接続応答のレスポンスを返信し、ＲＡＭに記憶されている基板認証鍵をクリアするとともに、基板初期鍵を暗号鍵として処理を進めるモードである基板初期鍵モード（図５５参照）に遷移する。このとき、ＣＵ制御部３２３は、基板接続要求結果などの認証ログ情報をＳＣ３２５ｂから取得する。
次に、図５９を参照して、基板初期鍵または基板出荷鍵の認証シーケンスの処理を説明する。
まず、図５９に示すように、基板初期鍵を暗号鍵として処理を進めるモードである基板初期鍵モードの状態の場合には、図５９において基盤初期鍵を用いた認証が行われるが、基板出荷鍵を暗号鍵として処理を進めるモードである基板出荷鍵モードの状態の場合には、図５９において基盤出荷鍵を用いた認証が行われることになる。よって、図５９の「／」はいずれか一方を表す記号である。ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、認証情報を要求する基板初期鍵／基板出荷鍵認証要求１のコマンドを送信する。なお、基板初期鍵／基板出荷鍵認証要求１のコマンドは暗号化していないが、暗号鍵に基板初期鍵／基板出荷鍵を用いて、暗号化してもよい。
基板初期鍵／基板出荷鍵認証要求１のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して、基板初期鍵または基板出荷鍵で認証情報の乱数Ａを暗号化し、ＭＡＣ鍵でＨ−ＭＡＣを算出して、基板初期鍵／基板出荷鍵認証応答１のレスポンスで返信する。
基板初期鍵／基板出荷鍵認証応答１のコマンドを受信したＣＵ制御部３２３は、基板初期鍵または基板出荷鍵を検証するため、認証情報の乱数Ａを復号化し、ＭＡＣをチェックする。
その後、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板初期鍵または基板出荷鍵で認証情報の乱数Ｂを暗号化し、ＭＡＣ鍵でＨ−ＭＡＣを算出して、基板初期鍵／基板出荷鍵認証要求２のコマンドで送信する。なお、基板初期鍵／基板出荷鍵認証要求２のコマンドは、暗号鍵に基板初期鍵または基板出荷鍵を用いて、暗号化してある。
基板初期鍵／基板出荷鍵認証要求２のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して、基板初期鍵または基板出荷鍵を検証するため、認証情報の乱数Ｂを復号化し、ＭＡＣをチェックする。そして、ＳＣ３２５ｂは、ＣＵ制御部３２３に対して、認証結果を基板初期鍵／基板出荷鍵認証応答２のレスポンスで返信する。このとき、ＣＵ制御部３２３は、基板初期鍵認証結果、基板出荷鍵認証結果などの認証ログ情報をＳＣ３２５ｂから取得する。
次に、図６０を参照して、基板シリアルＩＤおよび基板認証鍵の認証シーケンスの処理を説明する。
まず、ＣＵ制御部３２３とＳＣ３２５ｂとの通信は、基板認証鍵を暗号鍵として処理を進めるモードである基板認証鍵モードの状態において、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板シリアルＩＤの認証を要求する基板シリアルＩＤ認証要求１のコマンドを送信する。なお、基板シリアルＩＤ認証は、チャレンジ／レスポンス方式を用いて行なうため、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、チャレンジコードを要求する。
基板シリアルＩＤ認証要求１のコマンドを受信したＳＣ３２５ｂは、基板シリアルＩＤに基づくチャレンジコードを生成し、生成したチャレンジコードを基板シリアルＩＤ認証応答１のレスポンスでＣＵ制御部３２３に通知する。
基板シリアルＩＤ認証応答１のコマンドを受信したＣＵ制御部３２３は、チャレンジコードに基づくレスポンスコードを生成し（具体的には基板メシリアルＩＤを鍵としてチャレンジコードを暗号化してレスポンスコードを生成し）、生成したレスポンスコードを基板シリアルＩＤ認証要求２のコマンドでＳＣ３２５ｂに通知する。
基板シリアルＩＤ認証要求２のコマンドを受信したＳＣ３２５ｂは、レスポンスコードをチェックして（具体的には基板メシリアルＩＤを鍵としてレスポンスコードを復号してチャレンジコードを抽出して）、チャレンジコードが一致すればチェック結果がＯＫであるとする。そして、当該チェック結果を基板シリアルＩＤ認証応答２のレスポンスでＣＵ制御部３２３に通知する。なお、チェック結果がＮＧの場合、ＳＣ３２５ｂは、ＣＵ制御部３２３に対してチェック結果を、基板認証結果通知および基板認証結果応答での認証結果に含め、ＮＧを通知する。このとき、ＣＵ制御部３２３は、基板シリアルＩＤ認証結果などの認証ログ情報をＳＣ３２５ｂから取得する。
その後、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板認証鍵のバージョン情報を通知するためにバージョン情報通知のコマンドを送信する。なお、バージョン情報通知のコマンドは、暗号鍵に基板認証鍵を用いて、暗号化してある。
バージョン情報通知のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して基板認証鍵のバージョン情報を受信したことを通知するために、バージョン情報応答のレスポンスを返信する。なお、バージョン情報応答のレスポンスは暗号化していないが、暗号鍵に基板認証鍵を用いて暗号化してもよい。
その後、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、認証情報を要求する基板認証鍵認証要求１のコマンドを送信する。なお、基板認証鍵認証要求１のコマンドは暗号化していないが、暗号鍵に基板認証鍵を用いて、暗号化してもよい。
基板認証鍵認証要求１のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して、基板認証鍵で認証情報の乱数Ａを暗号化し、ＭＡＣ鍵でＨ−ＭＡＣを算出して、基板認証鍵認証応答１のレスポンスで返信する。
基板認証鍵認証応答１のコマンドを受信したＣＵ制御部３２３は、基板認証鍵を検証するため、認証情報の乱数Ａを復号化し、ＭＡＣをチェックする。
その後、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板認証鍵で認証情報の乱数Ｂを暗号化し、ＭＡＣ鍵でＨ−ＭＡＣを算出して、基板認証鍵認証要求２のコマンドで送信する。なお、基板認証鍵認証要求２のコマンドは、暗号鍵に基板認証鍵を用いて、暗号化してある。
基板認証鍵認証要求２のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して、基板認証鍵を検証するため、認証情報の乱数Ｂを復号化し、ＭＡＣをチェックする。そして、ＳＣ３２５ｂは、ＣＵ制御部３２３に対して、認証結果を基板認証鍵認証応答２のレスポンスで返信する。
その後、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して、基板認証結果を通知するために、基板認証結果通知のコマンドを送信する。なお、基板認証結果通知のコマンドは、暗号鍵に基板認証鍵を用いて、暗号化してある。基板認証結果通知のコマンドは、基板シリアルＩＤ認証と基板認証鍵の認証結果をＳＣ３２５ｂに対して通知する。
基板認証結果通知のコマンドを受信したＳＣ３２５ｂは、ＣＵ制御部３２３に対して、基板シリアルＩＤ認証と基板認証鍵の認証結果を通知するために、基板認証結果応答のコマンドを送信する。なお、基板認証結果応答のコマンドは、暗号鍵に基板認証鍵を用いて、暗号化してある。このとき、ＣＵ制御部３２３は、基板認証結果などの認証ログ情報をＳＣ３２５ｂから取得する。
次に、図６１は、セキュリティ基板情報の問合せを行なう場合の処理を説明するための図である。図６１を参照して、まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して上位装置に問合せる情報を要求するために、セキュリティ基板問合せ指示通知のコマンドを送信する。なお、送信するセキュリティ基板問合せ指示通知のコマンドは、暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化してある。
セキュリティ基板問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に問合せる情報（基板シリアル番号および問合せ情報）をＣＵ制御部３２３に通知するために、セキュリティ基板問合せ結果のレスポンスをＣＵ制御部３２３に返信する。なお、返信するセキュリティ基板問合せ指示通知のレスポンスは、基板シリアル番号を暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化しているとともに、ＣＵ制御部３２３とホールサーバとが復号できない鍵（以下「秘匿用鍵」と言う）で問合せ情報を暗号化している。その結果、問合せ情報は鍵管理サーバのみが復号して解読できる。
セキュリティ基板問合せ結果のレスポンスを受信したＣＵ制御部３２３は、基板シリアル番号および問合せ情報に基づき、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）にセキュリティ基板３２５の情報（基板シリアル番号および問合せ情報）を問合せ、上位装置からの応答を待つ。セキュリティ基板情報を問合せ中、ＣＵ制御部３２３およびＳＣ３２５ｂは、上位装置からの応答を待たずに、次のステップの処理（たとえば、通信制御ＩＣの認証処理、遊技機チップ情報の認証処理、遊技機との業務電文処理等）を実行し、セキュリティ基板情報を受信したときに必要な処理を実施する。
その後、ＣＵ制御部３２３は、上位装置からセキュリティ基板情報の問合せ結果（基板シリアルＩＤおよび基板認証鍵）を受信すると、セキュリティ基板情報をＳＣ３２５ｂに通知する。具体的に、ＣＵ制御部３２３は、問合せ結果である基板シリアルＩＤおよび基板認証鍵を含むセキュリティ基板情報通知のコマンドをＳＣ３２５ｂに送信する。なお、送信するセキュリティ基板情報通知のコマンドは、暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化してある。
ＳＣ３２５ｂは、セキュリティ基板情報通知のコマンドを受信後、問合せ番号を確認して、セキュリティ基板情報通知のコマンドを正常に受信したことをＣＵ制御部３２３に通知するために、セキュリティ基板情報結果のレスポンスを返信する。なお、鍵更新情報は、次回リセット時に使用される。返信するセキュリティ基板情報結果のレスポンスは、暗号化しなくてもよいが、暗号化する場合、暗号鍵に基板初期鍵または基板認証鍵を用いる。
その後、ＣＵ制御部３２３は、受信結果がＯＫの場合には、基板シリアルＩＤ鍵および基板認証鍵Ａを保存して、次回リセット時に認証鍵情報として使用する。また、ＣＵ制御部３２３は、基板情報問合せおよび基板情報通知の認証ログ情報を取得する。
次に、図６２を参照して、遊技機チップ情報問合せシーケンスの処理を説明する。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して遊技機チップ情報を問合せる遊技機チップ問合せ指示通知のコマンドを送信する。なお、送信する遊技機チップ問合せ指示通知のコマンドは、暗号化しなくてもよいが、暗号化する場合、暗号鍵に通信鍵を用いる。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して遊技機チップ情報を問合せる遊技機チップ問合せ指示通知のコマンドを送信する。なお、送信する遊技機チップ問合せ指示通知のコマンドは、暗号化しなくてもよいが、暗号化する場合、暗号鍵に通信鍵を用いる。
一方、ＳＣ３２５ｂは、通信制御ＩＣから遊技機チップ情報を取得する。その後、遊技機チップ問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、遊技機チップ情報の取得を完了しているので、遊技機チップ問合せ結果＝ＯＫの情報を含む遊技機チップ問合せ結果のレスポンスをＣＵ制御部３２３に返信する。遊技機チップ情報には、主制御チップＩＤ、払出制御チップＩＤなどが含まれている。なお、返信する遊技機チップ問合せ結果のレスポンスは、主制御チップＩＤと払出制御チップＩＤとが秘匿用鍵で暗号化され、その他の情報は暗号鍵に通信鍵を用いて、暗号化してある。
その後、ＣＵ制御部３２３は、返信された遊技機チップ問合せ結果のレスポンスを受信した場合、上位装置（鍵管理サーバまたはホールサーバ：図５４参照）に、主制御チップ番号および払出制御チップ番号を含む遊技機チップ情報を問合せ、上位装置からの応答を待つ。遊技機チップ情報問合せ中、ＣＵ制御部３２３およびＳＣ３２５ｂは、上位装置からの応答を持たずに、次のステップの処理（遊技機との業務電文処理）を実行する。遊技機チップ情報の問合せには時間（たとえば２時間程度）がかかるため、その間遊技機の稼働を停止しておくわけにはいかないために、上位装置からの応答を持たずに次のステップの処理（遊技機との業務電文処理）を実行する。なお、遊技機チップ情報問合せ中は、リセット動作（たとえば、リセットボタン（図示省略）の操作や電源再投入など）が行なわれても、再度遊技機チップ問合せ指示通知の要求は出されない。
その後、ＣＵ制御部３２３は、上位装置から遊技機チップ情報の照合結果を受信すると、当該照合結果をＳＣ３２５ｂに通知する。具体的に、ＣＵ制御部３２３は、照合結果を含む遊技機チップ情報通知のコマンドをＳＣ３２５ｂに送信する。なお、送信する遊技機チップ照合結果通知のコマンドは、暗号鍵に通信鍵を用いて、暗号化してある。
ＳＣ３２５ｂは、遊技機チップ情報通知のコマンドを受信後、照合結果がＯＫのとき、遊技機メーカコードおよび型式コードをＣＵ制御部３２３に通知するため、遊技機チップ情報結果のレスポンスを返信する。なお、返信する遊技機チップ情報結果のレスポンスは、暗号鍵に通信鍵を用いて、暗号化してある。
同時に、ＣＵ制御部３２３は、ＳＣ３２５ｂからの遊技機チップ情報結果に含まれる遊技機チップ情報問合せ、遊技機チップ情報照合結果などの認証ログを取得する。
次に、図６３を参照して、基板認証鍵認証異常のシーケンスの処理を説明する。
まず、ＣＵ３の電源を投入すると、ＣＵ制御部３２３およびＳＣ３２５ｂが起動される。
まず、ＣＵ３の電源を投入すると、ＣＵ制御部３２３およびＳＣ３２５ｂが起動される。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、基板メーカコード認証シーケンス、基板認証鍵認証シーケンスを実行する。
基板メーカコード認証シーケンスは、チャレンジ／レスポンス方式を用いて、ＣＵ制御部３２３とＳＣ３２５ｂとの間で基板メーカコードを認証する。基板メーカコード認証シーケンスの処理後、ＣＵ制御部３２３およびＳＣ３２５ｂは、暗号鍵に鍵管理サーバより取得した基板認証鍵を用い、基板認証鍵認証シーケンスを行なう。ここで、基板認証鍵認証が認証ＮＧとなった場合には、ＳＣ３２５ｂは、認証異常として、基板認証鍵情報をクリアする。
その後、ＣＵ制御部３２３およびＳＣ３２５ｂは、基板初期鍵認証シーケンスを実行する。このとき、基板初期鍵認証シーケンスの通信は、暗号鍵として基板初期鍵を用いて、暗号化してある。
この基板初期鍵認証シーケンスの認証が認証ＯＫのときは、その後は図５５に示したホール設置時立上シーケンスの処理と同様に、セキュリティ基板情報問合せシーケンス、通信鍵交換シーケンス、遊技機チップ情報問合せシーケンスなどの処理が行われ、遊技機と業務電文通信が可能となる。以後の通信は、暗号鍵として、通信鍵を用いて、暗号化してある。
なお、ＳＣ３２５ｂは、基板認証鍵シーケンスの認証が認証ＮＧになったことを示す「基板認証鍵更新異常」のアラームを鍵管理サーバ８０１に通知する。
次に、図６４は、セキュリティ基板情報の問合せタイムアウトシーケンスの処理を説明する図である。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して上位装置に問合せる情報を要求するために、セキュリティ基板問合せ指示通知のコマンドを送信する。なお、送信するセキュリティ基板問合せ指示通知のコマンドは、暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化してある。
セキュリティ基板問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に問合せる情報（基板シリアル番号および問合せ情報）をＣＵ制御部３２３に通知するために、セキュリティ基板問合せ結果のレスポンスをＣＵ制御部３２３に返信する。なお、返信するセキュリティ基板問合せ指示通知のレスポンスは、基板シリアル番号を暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化しているとともに、秘匿用鍵で問合せ情報を暗号化している。その結果、問合せ情報は鍵管理サーバのみが復号して解読できる。
セキュリティ基板問合せ結果のレスポンスを受信したＣＵ制御部３２３は、基板シリアル番号および問合せ情報に基づき、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）にセキュリティ基板３２５の情報（基板シリアル番号および問合せ情報）を問合せ、上位装置からの応答を待つ。セキュリティ基板情報を問合せ中、ＣＵ制御部３２３およびＳＣ３２５ｂは、上位装置からの応答を待たずに、次のステップの処理（たとえば、通信制御ＩＣの認証処理、遊技機チップ情報の認証処理、遊技機との業務電文処理等）を実行する。
その後、ＣＵ制御部３２３は、上位装置からセキュリティ基板情報の問合せ結果（基板シリアルＩＤおよび基板認証鍵）を受信する前に、セキュリティ基板情報問合せの待ち時間がタイムアウトした場合には、ＣＵ３はＰ台２の状態に関する情報を要求する状態情報要求のコマンドを送信する。なお、この状態情報要求のコマンドは、暗号鍵に通信鍵を用い、暗号化してある。態情報要求のコマンドを受信したＳＣ３２５ｂは通信制御ＩＣ３２５ａ経由でＰ台２の遊技機チップ情報を取得する。
そしてＳＣ３２５ｂは、ＣＵ３に対して、状態情報応答のレスポンスを返信する。このとき、ＳＣ３２５ｂは、セキュリティ基板情報を鍵管理センタに問合せを要求する旨の「基板問合せ有」を含む状態情報応答を返信する。
上記のセキュリティ基板問合せに対して、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して上位装置に問合せる情報を要求するために、セキュリティ基板問合せ指示通知のコマンドを送信する。なお、送信するセキュリティ基板問合せ指示通知のコマンドは、暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化してある。
セキュリティ基板問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に問合せる情報（基板シリアル番号および問合せ情報）をＣＵ制御部３２３に通知するために、セキュリティ基板問合せ結果のレスポンスをＣＵ制御部３２３に再度返信する。なお、返信するセキュリティ基板問合せ指示通知のレスポンスは、基板シリアル番号を暗号鍵に基板初期鍵または基板認証鍵を用い、暗号化しているとともに、秘匿用鍵で問合せ情報を暗号化している。その結果、問合せ情報は鍵管理サーバのみが復号して解読できる。
セキュリティ基板問合せ結果のレスポンスを受信したＣＵ制御部３２３は、基板シリアル番号および問合せ情報に基づき、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）にセキュリティ基板３２５の情報（基板シリアル番号および問合せ情報）を問合せ、上位装置からの応答を待ち続ける。
次に、図６５は、遊技機チップ情報の問合せ（照合）タイムアウトシーケンスの処理を説明する図である。
まず、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して上位装置に問合せる情報（具体的には遊技機チップ情報）を要求するために、遊技機チップ問合せ指示通知のコマンドを送信する。なお、送信する遊技機チップ問合せ指示通知のコマンドは、暗号鍵に通信鍵を用い、暗号化してある。
一方、ＳＣ３２５ｂは、通信制御ＩＣから遊技機チップ情報を取得し、その後、遊技機チップ問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に問合せる情報（主制御チップ情報および払出制御チップ情報）をＣＵ制御部３２３に通知するために、遊技機チップ問合せ結果（認証ＯＫ）のレスポンスをＣＵ制御部３２３に返信する。なお、返信する遊技機チップ問合せ指示通知のレスポンスは、主制御チップＩＤと払出制御チップＩＤとが秘匿用鍵で暗号化され、その他の情報は暗号鍵に通信鍵を用い、暗号化してある。
遊技機チップ問合せ結果のレスポンスを受信したＣＵ制御部３２３は、主制御チップ情報および払出制御チップ情報に基づき、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に遊技機チップ情報（主制御チップ情報および払出制御チップ情報）を問合せ、上位装置からの応答を待つ。遊技機チップ情報を問合せ中、ＣＵ制御部３２３およびＳＣ３２５ｂは、上位装置からの応答を待たずに、次のステップの処理（たとえば、通信制御ＩＣの認証処理、セキュリティ基板情報の認証処理、遊技機との業務電文処理等）を実行し、遊技機チップ情報を受信したときに必要な処理を実施する。
しかしながら、その後、ＣＵ制御部３２３は、上位装置から遊技機チップ情報の問合せ結果（主制御チップ情報および払出制御チップ情報）を受信する前に、遊技機チップ情報問合せの待ち時間がタイムアウトした場合には、ＣＵ３はＰ台２の状態に関する情報を要求する状態情報要求のコマンドを送信する。なお、この状態情報要求のコマンドは、暗号鍵に通信鍵を用い、暗号化してある。状態情報要求のコマンドを受信したＳＣ３２５ｂは通信制御ＩＣ３２５ａ経由でＰ台２の遊技機チップ情報を取得する。
そしてＳＣ３２５ｂは、ＣＵ３に対して、状態情報応答のレスポンスを返信する。このとき、ＳＣ３２５ｂは、遊技機チップ情報の鍵管理センタへの問合せを要求する旨の「チップ情報問合せ有」を含む状態情報応答を返信する。
上記の遊技機チップ情報問合せに対して、ＣＵ制御部３２３は、ＳＣ３２５ｂに対して上位装置に問合せる情報を要求するために、遊技機チップ問合せ指示通知のコマンドを送信する。なお、送信する遊技機チップ問合せ指示通知のコマンドは、暗号鍵に通信鍵を用い、暗号化してある。
遊技機チップ問合せ指示通知のコマンドを受信したＳＣ３２５ｂは、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に問合せる情報（主制御チップ情報および払出制御チップ情報）をＣＵ制御部３２３に通知するために、遊技機チップ問合せ結果のレスポンスをＣＵ制御部３２３に再度返信する。なお、返信する遊技機チップ問合せ指示通知のレスポンスは、主制御チップＩＤと払出制御チップＩＤとが秘匿用鍵で暗号化され、その他の情報は暗号鍵に通信鍵を用い、暗号化してある。
遊技機チップ問合せ結果のレスポンスを受信したＣＵ制御部３２３は、主制御チップ情報および払出制御チップ情報に基づき、上位装置（具体的にはホールサーバ経由で鍵管理サーバ）に遊技機チップ情報（主制御チップ情報および払出制御チップ情報）を問合せ、上位装置からの応答を待ち続ける。
以上の図５５〜図６５に基づいて説明したＣＵ制御部３２３とＳＣ３２５ｂとの間でのシーケンスにおいて、特徴的な部分を以下にまとめて説明する。
ＣＵ３が遊技場に入荷されて設置された後に実行されるシーケンスとして、「基板初期鍵認証シーケンス」がある（図５５参照）。この「基板初期鍵認証シーケンス」は、遊技場に搬入されて設置された最初の電源投入時においては、上位装置（ホールサーバ）から基板初期鍵をダウンロード取得し、その基板初期鍵を用いて認証されるシーケンスである。この基板初期鍵認証シーケンスの認証結果がＯＫであることを条件として、この基板初期鍵を用いて「セキュリティ基板情報問合せシーケンス」が実行される（図５５参照）。このセキュリティ基板情報問合せシーケンスにより基板認証鍵が上位装置（鍵管理サーバ）からダウンロード記憶され、以降、この基板認証鍵を利用して各種認証シーケンスや通信鍵交換シーケンス等が実行されてその通信鍵を用いて遊技機と業務電文通信が実行される（図５６参照）。
一方、基板初期鍵を用いてのセキュリティ基板情報問合せシーケンス（図５５参照）を実行した結果、基板認証鍵を取得できない場合がある。この基板認証鍵は、ＣＵメーカがＣＵ３を遊技場に出荷するときにそのＣＵ３の基板認証鍵を鍵管理サーバへ送信して鍵管理サーバに記憶してもらい、遊技場に搬入されたＣＵがその事前に鍵管理サーバに記憶されている基板認証鍵をダウンロード記憶するのであるが、ＣＵメーカから鍵管理サーバへの基板認証鍵の送信が何らかの理由により遅れている場合がある。また、遊技場に搬入されて設置されたＣＵ３がセキュリティ基板情報問合せシーケンスを実行して基板認証鍵をダウンロードしようとしたときに鍵管理サーバとＣＵ３との間で不測の事態が発生して通信不能のオフライン状態となっている場合もある。このような場合には、基板認証鍵をダウンロードすることができない。
基板認証鍵をダウンロードできない場合に、それ以降の遊技機との業務電文通信等の実稼動の運用が一切できないとなれば、遊技場における稼動率の低下等の運用上の問題が生じる。そこで、このような不測の事態が発生した場合には、仮の認証鍵である基板初期鍵を利用して実稼動の仮運用ができるように制御される。具体的には、上位装置（具体的にはホールサーバ）より取得済の基板初期鍵を用いて、通信鍵交換シーケンスを実行し、乱数と時刻データとを用いて通信鍵（セッション鍵）を生成し、ＣＵ制御部３２３とＳＣ３２５ｂとの間でその通信鍵（セッション鍵）を共有し、その通信鍵（セッション鍵）を使用して業務電文通信を行なって実稼動制御が行なわれる。この基板初期鍵を利用して交換した通信鍵による実稼動制御は、あくまで基板初期鍵が仮の鍵であり基板認証鍵が取得できない不安定な状態であるために、一定の期間だけ許容される仮運用の制御がなされる。具体的には、２日間のみこの基板初期鍵を用いた実稼動制御を許容し、３日目の電源立上げ時においても基板認証鍵を取得できなかったときには、それ以降の制御を停止させ、異常が発生した旨を報知するとともにホールサーバやホール用管理コンピュータへ異常発生した旨の通知を行なうように制御する。なお、基板初期鍵での一定の期間（たとえば２日）だけ許容される仮運用の時限制御は、基板初期鍵がホールサーバに記憶されているものであるため、少なくともＣＵ制御部３２３がホールサーバに接続されていることが担保されている状態で許容される。
また、前述の「基板初期鍵／出荷鍵認証シーケンス」は、図５９に示した工場出荷時すなわち未だ遊技場に搬入されていない段階でも実行される。この段階で基板初期鍵認証シーケンスを実行した場合には、未だ基板初期鍵が取得されていないために、基板初期鍵を用いたこの基板初期鍵認証シーケンスの実行の結果ＮＧの認証結果が導出される。すると、図５９に示した基板出荷鍵要求、基板出荷鍵応答以降の各シーケンスが実行され、遊技機と通信テスト電文の通信が実行される状態となる。すなわち、「基板初期鍵／出荷鍵認証シーケンス」により、基板初期鍵が取得されている段階かあるいは取得されていない工場出荷時の段階かを判断しているのであり、本来相互認証を行なう機器認証シーケンスを、基板初期鍵が取得された段階かあるいは取得されていない工場出荷時の段階かの判別にも有効利用している。
＜通信制御ＩＣとセキュリティチップとの通信における主なシーケンス＞
次に、図６６は、ＳＣ３２５ｂと通信制御ＩＣ３２５ａとの間の業務電文シーケンスの処理を説明する図である。図６６を参照して、ＣＵ３の電源投入後のＳＣ３２５ｂおよび通信制御ＩＣ３２５ａの処理について説明する。
次に、図６６は、ＳＣ３２５ｂと通信制御ＩＣ３２５ａとの間の業務電文シーケンスの処理を説明する図である。図６６を参照して、ＣＵ３の電源投入後のＳＣ３２５ｂおよび通信制御ＩＣ３２５ａの処理について説明する。
まず、ＣＵ３の電源を投入すると、ＳＣ３２５ｂおよび通信制御ＩＣ３２５ａが起動される。ＳＣ３２５ｂは、起動するとＣＵ制御部３２３と認証が実施され、通信制御ＩＣ３２５ａは、起動すると遊技機と認証が実施される。
その後、ＳＣ３２５ｂおよび通信制御ＩＣ３２５ａは、暗号鍵に本認証鍵または仮認証鍵を用い、通信制御ＩＣ認証シーケンスを行なう。図５４に基づいて説明した「仮認証鍵モード」の場合には仮認証鍵を用い、本認証鍵が生成され後の本認証鍵モードの場合には本認証鍵を用いる。
その後、ＳＣ３２５ｂおよび通信制御ＩＣ３２５ａは、暗号鍵に本認証鍵または仮認証鍵を用い、セキュリティ情報更新シーケンスを行なう。さらに、ＳＣ３２５ｂおよび通信制御ＩＣ３２５ａは、暗号鍵に本認証鍵または仮認証鍵を用い、遊技機チップ情報認証シーケンスを行なう。
その後、ＳＣ３２５ｂは、通信制御ＩＣ３２５ａに対して通信鍵を要求する通信鍵要求のコマンドを送信する。通信鍵要求のコマンドは、暗号鍵に本認証鍵または仮認証鍵を用いて、暗号化してある。
通信鍵要求のコマンドを受信した通信制御ＩＣ３２５ａは、遊技機と業務電文を通信するための通信鍵（セッション鍵）を生成し、生成した通信鍵を通信鍵応答のレスポンスでＳＣ３２５ｂに通知する。なお、返信する通信鍵応答のレスポンスは、暗号鍵に本認証鍵または仮認証鍵を用いて、暗号化してある。通信鍵（セッション鍵）の生成方法は、具体的には、乱数と現在時刻のデータとを用いて生成する。この現在時刻のデータは、通信制御ＩＣ３２５ａ自ら生成してもよくまた他の装置からもらい受けてもよい。この通信鍵（セッション鍵）の生成方法は、乱数と現在時刻のデータとに限らず、前述の相互認証に用いた鍵以外の可変データであれば、いかなるものを用いてもよい。
なお、上記の処理終了以降、遊技機と業務電文通信が可能となる。
図６７は、「基板認証鍵による認証」の具体的制御を説明するためのフローである。図６７を参照して、以下説明する一連の処理は、ＣＵ制御部３２３とＳＣ３２５ｂとの間において行なわれる。
図６７は、「基板認証鍵による認証」の具体的制御を説明するためのフローである。図６７を参照して、以下説明する一連の処理は、ＣＵ制御部３２３とＳＣ３２５ｂとの間において行なわれる。
ステップＳ２０１において、チャレンジレスポンス方式を用い、基板シリアルＩＤを使用した認証処理(単体認証）が行なわれる（図６０の基板シリアルＩＤ認証要求／応答１，２参照）。
そして、ステップＳ２０１の単体認証が完了すると、次のステップＳ２０２において鍵バージョンのチェックが行なわれる（図６０のバージョン情報通知／応答参照）。
そして、ステップＳ２０２の鍵バージョンのチェックが完了すると、次のステップＳ２０３において、基板認証鍵を使用した機器認証が行なわれる（図６０の基板認証鍵認証要求／応答１，２参照）。
そして、ステップＳ２０３の機器認証処理が完了すると、次のステップＳ２０４において、ステップＳ２０１〜Ｓ２０３の認証結果を相互に通知を行ない、次のステップＳ２０５に処理が進む（図６０の基板認証結果通知／応答参照）。
ステップＳ２０５において、通知された認証結果について正常か否かが判断され、認証結果が正常である場合にはステップＳ２０６に処理が進み、認証結果が正常でない場合にはステップＳ２０７に処理が進む。
ステップＳ２０６において、ＣＵ制御部３２３がＳＣ３２５ｂから取得するセキュリティ基板情報を有しているか否かがさらに判断され、取得するセキュリティ基板情報を有している場合には、ステップＳ２０９に処理が進み、取得するセキュリティ基板情報を有していない場合には、ステップＳ２１０に処理が進む。
ステップＳ２０９においては、ＣＵ制御部３２３−ＳＣ３２５ｂ間の基板認証鍵の認証処理について、さらにセキュリティ基板情報の問合せ処理へ遷移し、処理が終了する。一方、ステップＳ２１０は、基板認証鍵モードの認証を正常に終了し、処理が終了する。なお、この場合には、ＣＵ制御部３２３−ＳＣ３２５ｂ間は遊技機チップ情報の照合の処理が行なわれる。
一方、ステップＳ２０５において、認証結果が正常でない場合には、ステップＳ２０６に処理が進み。このステップＳ２０６においてこのリトライ回数が３回目か否かが判断され、リトライ回数が３回目である場合には、ステップＳ２０８に処理が進み、リトライ回数が３回目でない（リトライ回数が１回目か２回目である）場合には、処理がステップＳ２０１に戻り、再度認証処理が行なわれる。
ステップＳ２０８において、ＳＣ３２５ｂ基板認証異常として、リセット動作（たとえば、リセットボタン（図示省略）の操作や電源再投入など）まで待機状態となる。リセット動作後において、再度基板初期鍵を暗号鍵として認証処理を行なうモード（基板初期鍵モード）で起動され、各認証処理が行なわれ、処理が終了する。この場合には、その日の営業は１日中この基板初期鍵モードで運用され、翌日の電源立上時に再度鍵管理サーバに対しセキュリティ基板情報取得要求を出し、セキュリティ基板情報の取得を試みる（図６４）。また、ステップＳ２０８ａに示したように、翌日の電源立上を待つことなくこの時点でセキュリティ基板情報の問合せ処理を再度実行してもよい。この場合には、基板初期鍵モードでの運用により遊技を進行させつつセキュリティ基板情報の問合せ処理も並行して進行させる。
図６８（ａ）は、ＣＵ制御部−ＳＣ間での通信モードの切替処理を説明するためのフローチャートの一例である。図６８（ａ）を参照して、ステップＳ２１１において、ＣＵ制御部３２３は鍵管理サーバに基板認証鍵の要求を行ない、次のステップＳ２１２に処理が進む。
そして、ステップＳ２１２において、ＣＵ制御部３２３は鍵管理サーバから送られてきたセキュリティ基板情報の中から基板認証鍵を取得するとともに、セキュリティ基板情報中の更新情報をＳＣ３２５ｂへ送信し、次のステップＳ２１３に処理が進む。
ステップＳ２１３において、ＣＵ制御部３２３は遊技機が非稼動状態か否かの判定を行なう。次のステップＳ２１４のモード切替処理を行なったときにはその切替処理の実行中遊技機との加減算玉数の通信処理ができなくなるため、ステップＳ２１４のモード切替処理を行なう前に遊技機が非稼動状態か否かの判定を行なうのである。遊技機が非稼動状態か否かは、ＣＵに遊技者のカードが挿入されていないか挿入されているかで判断する。カードが挿入されていない場合には遊技機が非稼働状態と判断する一方、カードが挿入されている場合には遊技機が稼働状態と判断する。ＣＵ制御部３２３に対応する遊技機が非稼動状態である場合には、ステップＳ２１４に処理が進み、ＣＵ制御部３２３に対応する遊技機が非稼動状態でない場合には、遊技機が非稼動状態になるまでステップＳ２１３の処理が行なわれる。
ステップＳ２１４において、ＣＵ制御部３２３は、ステップＳ２１２において取得した基板認証鍵に基づいて、基板初期鍵を暗号鍵として処理を進めるモード（基板初期鍵モード）から基板認証鍵を暗号鍵として処理を進めるモード（基板認証鍵モード）へ通信モードを切替て、処理が終了する。
図６８（ｂ）は、ＳＣ−通信制御ＩＣ間での通信モードの切替処理を説明するためのフローチャートの一例である。図６８（ｂ）を参照して、ステップＳ２１６において、ＳＣ３２５ｂがＣＵ制御部３２３からの更新情報を取得する。前述したようにＣＵ制御部３２３はステップＳ２１２により更新情報をＳＣ３２５ｂへ送信する。それを受けたＳＣ３２５ｂは、その更新情報を取得する。次に、ステップＳ２１７においてＳＣ３２５ｂは、取得した更新情報から本認証鍵を生成する。次に、前述のステップＳ２１３と同様に、ステップＳ２１８においてＳＣ３２５ｂは、遊技機が非稼動状態か否かの判定を行ない、非稼動状態であることを条件として、ステップＳ２１９の処理を実行する。ステップＳ２１９においてＳＣ３２５ｂは、生成した本認証鍵に基づいて、ＳＣ３２５ｂと通信制御ＩＣ３２５ａとの通信モードについて仮認証鍵を暗号鍵として処理を進めるモード（仮認証鍵モード）から本認証鍵を暗号鍵として処理を進めるモード（本認証鍵モード）へ切替える。
このような実施の形態によれば、ＣＵの正当性が鍵管理サーバに登録された基板認証鍵によって認証される前に通常の通信モードとなってカード残額等を用いたＰ台での遊技が可能となることを防止できる。さらに、鍵管理サーバに登録された基板認証鍵を受信できないときでも、制限通信モードとなり、Ｐ台での遊技が許容されるため、柔軟な運用が可能となる。しかも、その場合には通常通信モードに比べて所定の制限の下で遊技が許容されるものとなるため、鍵管理サーバに記憶された基板認証鍵での認証が必要とされることなく運用が続けられてしまうことを防止できる。
図６９（ａ）（ｂ）は、通信モードの切替処理を説明するためのフローチャートの他の例である。ＣＵ制御部−ＳＣ間での通信モードの切替処理を示す図６９（ａ）を参照して、ステップＳ２２１において、ＣＵ制御部３２３は鍵管理サーバにセキュリティ基板情報の要求を行ない、次のステップＳ２２２に処理が進む。
そして、ステップＳ２２２において、ＣＵ制御部３２３が鍵管理サーバに要求したセキュリティ基板情報をホールサーバが鍵管理サーバから取得し、そのセキュリティ基板情報の中から基板認証鍵をホールサーバが取得する。次に、ステップＳ２２３においてホールサーバは、前述のステップＳ２１３と同様の趣旨より、セキュリティ基板情報を要求したＣＵ制御部３２３に対応する遊技機が非稼動状態か否か判定する。遊技機が非稼動状態になったときにホールサーバはステップＳ２２４において、取得した基板認証鍵をＣＵ制御部３２３へ送信し、それを受けたＣＵ制御部３２３はセキュリティ基板情報中の更新情報をＳＣ３２５ｂへ送信する。次に、ステップＳ２２５においてＣＵ制御部３２３は、ステップＳ２２２４において取得した基板認証鍵に基づいて、基板初期鍵を暗号鍵として処理を進めるモード（基板初期鍵モード）から基板認証鍵を暗号鍵として処理を進めるモード（基板認証鍵モード）へ通信モードを切替て、処理が終了する。
次に、ＳＣ−通信制御ＩＣ間での通信モードの切替処理を示す図６９（ｂ）を参照して、ステップＳ２２６において、ＳＣ３２５ｂがＣＵ制御部３２３からの更新情報を取得する。前述したようにＣＵ制御部３２３はステップＳ２２４により更新情報をＳＣ３２５ｂへ送信する。それを受けたＳＣ３２５ｂは、その更新情報を取得する。次に、ステップＳ２２７においてＳＣ３２５ｂは、取得した更新情報から本認証鍵を生成する。次に、ステップＳ２２８においてＳＣ３２５ｂは、生成した本認証鍵に基づいて、ＳＣ３２５ｂと通信制御ＩＣ３２５ａとの通信モードについて仮認証鍵を暗号鍵として処理を進めるモード（仮認証鍵モード）から本認証鍵を暗号鍵として処理を進めるモード（本認証鍵モード）へ切替える。
このような実施の形態によれば、制限通信モードにおいてホールサーバが鍵管理サーバから基板認証鍵を受信したときでも、Ｐ台が稼動中のときには、即座にその基板認証鍵がＣＵに送信されて通常通信モードに切り換わるのではなく、遊技機が非稼働状態になったことを条件にして基板認証鍵がホールサーバからＣＵに送信されて通常通信モードに切り換わるため、制限通信モードにおいて提供されていた遊技に何らかの影響を与えてしまい、遊技者が不利益を被ることを防止できる。
＜ＳＣ３２５ｂとＣＵ制御部３２３との認証動作＞
次に、統一店舗コードのチェック、基板メーカコードの認証についてさらに詳しく説明する。
次に、統一店舗コードのチェック、基板メーカコードの認証についてさらに詳しく説明する。
まず、図７０を参照して、ＳＣ３２５ｂによる統一店舗コードのチェック処理を説明する。この処理は、ＳＣ３２５ｂが、基板接続要求時に通知される統一店舗コードと前回通知された統一店舗コードをチェックして、不一致の場合に設置された店舗が変わったと判断する認証動作である。ＳＣ３２５ｂは、記憶している前回の統一店舗コードがダミーコードであるか否かを判断する（ステップＳ１１０１）。なお、統一店舗コードのダミーコードは、たとえば、すべてのデータが“０ｘＦＦ”である。このダミーコードは、ＣＵ３が遊技場（店舗）に設置される前の出荷時の段階で通常の統一店舗コードの代わりに用いられるものであり、出荷時の段階でＳＣ３２５ｂに既に記憶されている。そして出荷時にダミーコードをＣＵ制御部３２３経由でＳＣ３２５ｂに入力して、ＳＣ３２５ｂがその入力されたダミーコードと記憶しているダミーコードとを一致判定して認証する。また、ダミーコードは、新装開店の遊技場(ホール)のため未だ統一店舗コードを取得していない場合に仮の店舗コードとして当該遊技場のホールサーバにデフォルトとして記憶されている。そして、新装開店の遊技場に設置されたＣＵ３にホールサーバからダミーコードをダウンロードさせてＳＣ３２５ｂがそのダウンロードされたダミーコードと記憶しているダミーコードとを一致判定して認証し、Ｐ台２による遊技を可能にする。
正規の統一店舗コードを取得したホールサーバはＣＵ制御部３２３へその統一店舗コードを送信する。それを受けたＣＵ制御部３２３は、次の電源投入時における基板接続要求時にその統一店舗コードをＳＣ３２５ｂへ送信する。それを受けたＳＣ３２５ｂは、記憶している前回の統一店舗コードがダミーコードであると判断した場合（ステップＳ１１０１：ＹＥＳ）、基板接続要求時にホールサーバから通知された統一店舗コードに記憶を更新するが、基板認証鍵、本認証鍵情報を初期化しないで、前回の各認証モードを引継いで動作する。その後、ＳＣ３２５ｂは、認証ログ情報を保存する（ステップＳ１１０６）。基板認証鍵、本認証鍵情報の初期化は、或る遊技場に設置されていたＣＵ３が他の遊技場に移設されたときに必要となる処理であるが、ＳＣ３２５ｂに記憶されているダミーコードを統一店舗コードに更新する場合には、前述した新装開店の遊技場が正規に統一店舗コードを取得してその統一店舗コードをＣＵ３にダウンロードした場合であり、店舗が代わったわけではなく、基板認証鍵、本認証鍵情報の初期化は不要である。逆にこのような場合に基板認証鍵、本認証鍵情報の初期化すると、再度基板認証鍵の取得要求が必要となり、1営業日での基板初期鍵運用（時限運用）が多くなり、時限運用猶予期間が少なくなる不都合が生じる。このような不都合を回避するために基板認証鍵、本認証鍵情報の初期化を行なわないように制御している。
一方、ＳＣ３２５ｂは、記憶している前回の統一店舗コードがダミーコードでないと判断した場合（ステップＳ１１０１：ＮＯ）、基板接続要求時にホールサーバから通知された統一店舗コードと、記憶している前回の統一店舗コードとが一致しているか否かを判断する（ステップＳ１１０２）。
ＳＣ３２５ｂは、基板接続要求時にホールサーバから通知された統一店舗コードと、記憶している前回の統一店舗コードとが一致していると判断した場合（ステップＳ１１０２：ＹＥＳ）、認証処理を基板初期鍵認証シーケンスへ遷移、あるいは、基板認証鍵認証シーケンスへ遷移する（ステップＳ１１０３）。なお、ＳＣ３２５ｂは、前回の認証モードが基板認証鍵モードである場合、基板認証鍵認証シーケンスへ遷移し、前回の認証モードがそれ以外の認証モードである場合、基板初期鍵認証シーケンスへ遷移する。
一方、ＳＣ３２５ｂは、基板接続要求時にホールサーバから通知された統一店舗コードと、記憶している前回の統一店舗コードとが一致していないと判断した場合（ステップＳ１１０２：ＮＯ）、基板認証鍵情報、および本認証鍵情報を初期化（クリア）する（ステップＳ１１０４）。このような統一店舗コードの不一致は、或る遊技場に設置されていたＣＵ３が他の遊技場に移設されたときに生じる。ＣＵ３が他の遊技場に移設されたため、前の遊技場で使用していた基板認証鍵情報および本認証鍵情報を初期化（クリア）してセキュリティを担保するのである。なお、ＳＣ３２５ｂは、ＣＵ制御部３２３から通知される統一店舗コードが変更になった場合、本認証鍵の初期化（クリア）を通信制御ＩＣ３２５ａに設定して、仮認証鍵による認証を開始する。なお、ＳＣ３２５ｂが本認証鍵情報を初期化（クリア）した場合に、通信制御ＩＣ３２５ａも本認証鍵情報を初期化（クリア）するように制御してもよく、また、特にそのような制御を行なうことなく次回の通信制御ＩＣ３２５ａとの認証のときにＳＣ３２５ｂが本認証鍵を有していないため仮認証鍵での認証に戻るようにしてもよい。
また、ＳＣ３２５ｂは、ステップＳ１１０４で基板認証鍵情報、および本認証鍵情報を初期化（クリア）した後、認証処理を基板初期鍵認証シーケンスおよび仮認証鍵シーケンスへ遷移する（ステップＳ１１０５）。
ＳＣ３２５ｂは、ステップＳ１１０３で認証処理を基板初期鍵認証シーケンスへ遷移、あるいは、基板認証鍵認証シーケンスへ遷移した後、ステップＳ１１０４で認証処理を基板初期鍵認証シーケンスへ遷移した後、認証ログ情報を保存する（ステップＳ１１０６）。
図７１は、基板メーカコードの認証動作を説明するためのフローチャートである。基板メーカコードの認証は、ＳＣ３２５ｂとＣＵ制御部３２３とが、それぞれ初期情報として記憶している基板メーカコードを使用した認証を行なう認証動作である。図７１を参照して、まず、ＳＣ３２５ｂとＣＵ制御部３２３とは、記憶している基板メーカコードを使用したチャレンジ／レスポンス方式による単体認証を行なう。（ステップＳ１２０１）。なお、単体認証時に生成するレスポンスコードは、たとえば、記憶している基板メーカコードを鍵にしてチャレンジコードをブロック暗号化した後にハッシュ関数でハッシュ化することで生成される。
ＳＣ３２５ｂは、生成したチャレンジコードに対してＣＵ制御部３２３が生成したレスポンスコードをチェックした認証結果が正常か否かの判断を行なう（ステップＳ１２０２）。ＳＣ３２５ｂは、認証結果が正常であると判断した場合（ステップＳ１２０２：ＹＥＳ）、既に基板認証鍵で認証済みであるか否かを判断する（ステップＳ１２０３）。一方、ＳＣ３２５ｂは、認証結果が正常でない（異常）と判断した場合（ステップＳ１２０２：ＮＯ）、ｎ回（たとえば３回）連続して異常であるか否かを判断する（ステップＳ１２０４）。
ＳＣ３２５ｂは、既に基板認証鍵で認証済みであると判断した場合（ステップＳ１２０３：ＹＥＳ）、基板認証鍵の認証処理へ遷移し、基板認証鍵認証シーケンスを維持する（ステップＳ１２０５）。一方、ＳＣ３２５ｂは、既に基板認証鍵で認証済みでないと判断した場合（ステップＳ１２０３：ＮＯ）、基板初期鍵の認証処理へ遷移する（ステップＳ１２０６）。
ＳＣ３２５ｂは、ｎ回連続して異常でないと判断した場合（ステップＳ１２０４：ＮＯ）、処理をステップＳ１２０１に戻す。一方、ＳＣ３２５ｂは、ｎ回連続して異常であると判断した場合（ステップＳ１２０４：ＹＥＳ）、セキュリティを担保するために基板認証鍵情報および本認証鍵情報を初期化（クリア）する（ステップＳ１２０７）。これにより、基板認証鍵情報および本認証鍵情報が盗用される不都合を防止できる。その後、ＳＣ３２５ｂは、基板初期鍵の認証処理へ遷移する（ステップＳ１２０８）。
ＳＣ３２５ｂは、ステップＳ１２０５で基板認証鍵認証シーケンスを維持、またはステップＳ１２０６、Ｓ１２０８で基板初期鍵の認証処理へ遷移した後、認証ログ情報を保存する（ステップＳ１２０９）。
＜遊技履歴表示機能＞
本実施の形態に係る遊技用システムは、複数の遊技場での遊技履歴を、ＣＵ３の表示器５４などの遊技場の表示装置ならびに遊技者の携帯電話１６Ａおよびノートパソコン（以下、単に「ＰＣ」ともいう）１５Ａなどの情報機器で表示する遊技履歴表示機能を有する。以下、図７２から図８３を参照して、遊技履歴表示機能について説明する。
本実施の形態に係る遊技用システムは、複数の遊技場での遊技履歴を、ＣＵ３の表示器５４などの遊技場の表示装置ならびに遊技者の携帯電話１６Ａおよびノートパソコン（以下、単に「ＰＣ」ともいう）１５Ａなどの情報機器で表示する遊技履歴表示機能を有する。以下、図７２から図８３を参照して、遊技履歴表示機能について説明する。
まず、遊技履歴表示機能の前提である管理サーバ１４０での遊技履歴の蓄積について説明する。ＣＵ３のＣＵ制御部３２３が、会員カードＩＤおよび当該会員カードＩＤに対応する当該遊技場の遊技場会員ＩＤを特定すると、逐次、それぞれ遊技場会員ＩＤおよび会員カードＩＤとともに遊技履歴と当該遊技機および設置遊技場を特定可能な遊技機ＩＤとを会員管理コンピュータ１２０および遊技場外の管理サーバ１４０に送信する。
会員管理コンピュータ１２０は、受信した遊技履歴を、遊技場会員ＩＤに対応付けて、記憶装置に記憶されている図２４（ｂ）で示される会員別遊技履歴テーブルに蓄積する。
また、管理サーバ１４０は、ＣＵ３に搭載されているカメラによって撮影された遊技者の顔データを取得し、当該顔データが記憶部に記憶されているか否かを判断する。
当該顔データが記憶されていれば、当該顔データに対応付けられた顔ＩＤを特定し、記憶されていなければ、新たに顔ＩＤを発行し、当該顔ＩＤと顔データとを対応付けて記憶部に記憶させる。管理サーバ１４０は、会員カードＩＤが特定されている場合は、顔ＩＤと会員カードＩＤとを対応付けて記憶部に記憶させる。管理サーバ１４０は、特定した顔ＩＤをＣＵ３に伝達する。そして、管理サーバ１４０は、受信した遊技履歴を、顔ＩＤおよび特定されている場合には会員カードＩＤならびに遊技機ＩＤに対応付けて、図２４（ｂ）の会員別遊技履歴テーブルで示されるような管理サーバ１４０の記憶部のテーブルに蓄積する。
これとともに、管理サーバ１４０は、遊技機ＩＤで特定される遊技場および遊技機ごとに、受信した遊技履歴を、顔ＩＤと対応付けて蓄積する。このように、共通会員カード受付中だけでなく、共通会員カードの受付中でない場合であっても、遊技機で遊技したすべての遊技について遊技履歴が送信されるので、遊技場および遊技機ごとの遊技履歴としては当該遊技機でのすべての遊技履歴が蓄積されることとなる。なお、遊技履歴を顔ＩＤに対応付けて蓄積しないようにしてもよい。この場合は、会員カードＩＤに対応付けられていない遊技履歴は、遊技機ＩＤごとに蓄積するようにする。
ＣＵ３は、所定のイベント発生ごとに、遊技履歴を、会員カードＩＤまたは顔ＩＤとともに管理サーバ１４０に送信する。所定のイベントとは、たとえば、ＣＵ３への入金、入金残額の消費による玉貸し、カードの排出、ログイン操作、ログアウト操作、大当り発生、計数操作、持玉の払出し、および、再プレイ操作などである。なお、遊技履歴は、所定のイベント発生ごとに送信されることに替えて、カード返却時または顔ＩＤ変化時に送信されるようにしてもよい。
ＣＵ３から管理サーバ１４０に送信され、管理サーバ１４０の記憶部のテーブルに蓄積される遊技履歴には、図２４（ｂ）で示す情報に加えて、後述する図８２で示すアウト玉数（遊技領域に打出された玉数）、セーフ玉数（遊技機から払出された賞球の数）、大当り回数および、スタート回数（図柄の変動表示が開始された回数）に加えて、日付、店舗ＩＤ、台番号、遊技開始時間、遊技終了時間、プリペイド入金金額、プリペイド消費金額、計数玉数、払出玉数、貯玉再プレイ玉数、発射玉数、入賞口入賞個数、大入賞口入賞個数、始動入賞口入賞個数、初当り回数（確変時短中でないときの大当り回数）、確変回数、時短回数、大当り中アウト玉数、大当り中セーフ玉数、大当り中スタート回数、大当り中始動入賞口入賞個数、大当り中大入賞口入賞個数、大当り中大入賞口賞球個数、確変時短中アウト玉数、確変時短中セーフ玉数、確変時短中スタート回数、確変時短中始動入賞口入賞個数、および、大当り継続回数（確変時短状態中に発生した大当りの連続した回数）などが含まれる。
次に、上述した管理サーバ１４０における遊技履歴の蓄積を前提とした遊技履歴表示機能について説明する。図７２および図７３は、それぞれ、遊技履歴表示機能での処理の流れの概略を示す第１および第２のフローチャートである。図７４から図８１および図８３は、それぞれ、遊技履歴表示機能での表示画面の例を示す第１から第９の図である。図８２は、遊技履歴表示機能で収集される遊技履歴の例を示す図である。
図７２を参照して、ＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、遊技情報サイトへのアクセス操作を受付けた（ステップＳ７０１でＹＥＳ）と判断した場合、管理サーバ１４０の遊技情報サイトへのアクセスを実行する。遊技情報サイトは、図２９から図３１で前述した会員サービスサイトと、同じ管理サーバ１４０で提供される異なるサイトである。
管理サーバ１４０のＣＰＵは、情報機器からのアクセスを受付けた（ステップＳ４０１でＹＥＳ）と判断した場合、ログイン前トップページのデータをアクセス元の情報機器に送信する（ステップＳ４０２）。
情報機器のＣＰＵは、管理サーバ１４０からログイン前トップページのデータを受信し、当該ログイン前トップページを表示部に表示させる（ステップＳ５０２）。
図７４を参照して、ログイン前トップページには、ログインＩＤおよびパスワードを入力するための入力窓、ログイン操作を入力するための「ログイン」ボタン、会員登録に進むための「会員登録」ボタン、掲示板を表示させるための「掲示板」ボタン、および、全国の優秀な遊技履歴を表示させるための複数のボタン（「Ａ店ＣＲ○○詳細」ボタン，「Ｂ店ＣＲ△△詳細」ボタン，「Ｃ店ＣＲ□□詳細」ボタン）などが表示される。なお、ログイン前トップページには、会員が特定されていない段階であるので、デフォルトのアバターの画像が表示される。
図７２に戻って、情報機器のＣＰＵは、ログイン前トップページで「会員登録」ボタンが操作された（ステップＳ５０３でＹＥＳ）と判断した場合、会員登録要求を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から会員登録要求を受信した（ステップＳ４０３でＹＥＳ）と判断した場合、会員登録受付処理を実行する（ステップＳ４０４）。情報機器のＣＰＵは、会員登録受付処理にしたがい、管理サーバ１４０との間で会員登録に必要な情報をやり取りする（ステップＳ５０４）。会員登録受付処理においては、たとえば、図２５（ａ）で示した情報が登録される。会員登録受付処理においては、特に、前述の共通会員カードの会員カードＩＤとログインＩＤとの対応付けが行なわれる。
具体的には、管理サーバ１４０のＣＰＵは、会員登録受付処理で表示されるページにおいて、既に発行されて会員遊技者が所持している共通会員カードに記載されている会員カードＩＤの入力を受付け、入力された会員カードＩＤが既に管理サーバ１４０の記憶部に記憶された正しいものであれば、新たに発行した遊技情報サイトのログインＩＤと遊技者に入力を求めたパスワードとを、当該会員カードＩＤに対応付けて管理サーバ１４０の記憶部に記憶させる。
なお、入力された会員カードＩＤが登録されている会員カードＩＤと異なる場合や、共通会員カードを所持していない場合に操作するボタンが操作された場合など、遊技者が未だ共通会員カードの発行を受けていない（会員登録していない）と考えられる場合は、共通会員カードの発行を受けることを促すためのページに誘導するようにしてもよい。
情報機器のＣＰＵは、ログイン前トップページの入力窓にログインＩＤおよびパスワードが入力された状態で「ログイン」ボタンが操作された（ステップＳ５０５でＹＥＳ）と判断した場合、入力されたログインＩＤおよびパスワードを管理サーバ１４０に送信する。本実施の形態においては、ログインＩＤは、図２５（ａ）で示した会員カードＩＤと同じであることとするが、これに限定されず、異なるものであってもよい。
管理サーバ１４０のＣＰＵは、情報機器からログインＩＤおよびパスワードを受信した（ステップＳ４０５でＹＥＳ）と判断した場合、ログインＩＤおよびパスワードが管理サーバ１４０の記憶部に記憶された正しいものであれば、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の情報に基づいて、当該ログインＩＤに対応する会員カードＩＤに応じたマイトップページを生成し、当該マイトップページのデータを、アクセス元の情報機器に送信する（ステップＳ４０６）。
本実施の形態においては、管理サーバ１４０の記憶部には、会員カードＩＤおよびログインＩＤに対応付けて、会員の情報として、図２４で示した情報と同様の遊技者の情報に加えて、アバター画像やポイント数やお気に入りの遊技場を示す情報などが記憶される。具体的には、管理サーバ１４０のＣＰＵは、会員の情報に基づいて、アバター画像やポイント数やお気に入りの遊技場を示す情報を特定し、お気に入りの遊技場のベスト３の遊技機を特定し、特定した遊技機での獲得玉数を特定し、これらの情報を含むマイトップページを生成する。
情報機器のＣＰＵは、管理サーバ１４０からマイトップページのデータを受信し、当該マイトップページを表示部に表示させる（ステップＳ５０６）。
図７５を参照して、マイトップページには、当該会員のアバターの画像、当該会員の名前、掲示板を表示させるための「掲示板」ボタン、お気に入りの遊技場の遊技履歴または全国の優秀な遊技履歴を表示させるための複数のボタン（「Ｘ店ＣＲ○○詳細」ボタン，「Ｘ店ＣＲ△△詳細」ボタン，「Ｘ店ＣＲ□□詳細」ボタン）、当該会員の遊技履歴を表示させるための複数のボタン（「２０１３年データ」ボタン，「生涯データ」ボタン，「詳細」ボタン）、および、当該会員の日付別のプレイデータを表示させるための「この日のプレイデータをみる」ボタンが表示される。
さらに、マイトップページには、図７５に示すように、フレンドリストページを表示させるための「フレンドリスト」ボタン、フレンド検索ページを表示させるための「フレンド検索」ボタン、フレンドリクエスト一覧ページを表示させるための「フレンドリクエスト」ボタンが表示される。
図７３を参照して、情報機器のＣＰＵは、マイトップページの「この日のプレイデータをみる」ボタンが操作されることでプレイデータ閲覧操作が行なわれた（ステップＳ５１１でＹＥＳ）と判断した場合、プレイデータ閲覧操作が行なわれた旨、ログインＩＤ、および、操作された「この日のプレイデータをみる」ボタンに対応する日付を、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、プレイデータ閲覧操作が行なわれた旨、ログインＩＤ、および、日付を受信した（ステップＳ４１１でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の遊技履歴に基づいて、当該日付に応じたログインＩＤに対応する会員カードＩＤの会員のプレイデータページを生成し、当該プレイデータページのデータを、アクセス元の情報機器に送信する（ステップＳ４１２）。
情報機器のＣＰＵは、管理サーバ１４０からプレイデータページのデータを受信し、当該プレイデータページを表示部に表示させる（ステップＳ５１２）。
図７６を参照して、プレイデータページには、当該プレイデータの遊技履歴の日付、当該日付の遊技情報サイトへのログイン回数、および、当該日付の合計の遊技履歴（当日に遊技したすべての遊技場のすべての遊技機の合計の大当り回数、総獲得玉数、遊技時間、総回転数、投資玉数）のデータが表示される。
なお、プレイデータページに、当日に遊技した遊技場や遊技した遊技機や遊技機の種別が特定可能に表示されてもよい。また、プレイデータページに、当日に遊技した遊技場ごとの遊技履歴や当日に遊技した遊技機の機種ごとの遊技履歴が特定可能に表示されてもよい。
図７３に戻って、情報機器のＣＰＵは、遊技履歴を検索するための遊技履歴検索操作が行なわれた（ステップＳ５１３でＹＥＳ）と判断した場合、遊技履歴検索操作が行なわれた旨、および、ログインＩＤを、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、遊技履歴検索操作が行なわれた旨、および、ログインＩＤを受信した（ステップＳ４１３でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の遊技履歴に基づいて、ログインＩＤに対応する会員カードＩＤの会員の遊技履歴を検索するための遊技者が遊技した店舗および機種の遊技履歴リストページを生成し、当該遊技履歴リストページのデータを、アクセス元の情報機器に送信する（ステップＳ４１４）。
情報機器のＣＰＵは、管理サーバ１４０から遊技履歴リストページのデータを受信し、当該遊技履歴リストページを表示部に表示させる（ステップＳ５１４）。
図７７を参照して、遊技履歴リストページには、当該会員が遊技した店舗のリストおよびその店舗を選択するためのボタン（「Ｘ店」ボタン，「Ａ店」ボタンなど）、ならびに、当該会員が遊技した機種のリストおよびその機種を選択するためのボタン（「ＣＲ○○」ボタン，「ＣＲ△△」ボタン，「ＣＲ◎◎」ボタンなど）が表示される。
会員が遊技した店舗および機種は、それぞれ、管理サーバ１４０の記憶部に記憶された当該遊技者の会員カードＩＤに対応付けられた遊技履歴から遊技場および遊技機ＩＤを抽出し、遊技機ＩＤから機種を特定することで特定される。
図７３に戻って、情報機器のＣＰＵは、遊技履歴リストページで店舗または機種を選択するためのボタンが操作された（ステップＳ５１５でＹＥＳ）と判断した場合、選択された店舗または機種の遊技履歴の店舗別リストまたは機種別リストの表示を要求する旨、選択された店舗または機種を特定するための情報（店舗ＩＤ，機種ＩＤ）およびログインＩＤを、管理サーバ１４０に送信する。
なお、管理サーバ１４０と情報機器との通信において、一度、ログインＩＤが正しく入力された後の所定期間（たとえば、当日中または所定時間）は、管理サーバ１４０は、情報機器を特定可能なＩＤを記憶しておき、当該ＩＤの情報機器からの要求があれば当該ＩＤからログインＩＤおよび会員カードＩＤを特定して、要求に応じた応答をするようにしてもよい。
管理サーバ１４０のＣＰＵは、店舗別リストまたは機種別リストの表示を要求する旨、店舗ＩＤまたは機種ＩＤ、および、ログインＩＤを受信した（ステップＳ４１５でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の遊技履歴に基づいて、当該店舗ＩＤまたは当該機種ＩＤで特定される店舗または機種の当該ログインＩＤに対応する会員カードＩＤの会員の店舗別／機種別遊技履歴リストページを生成し、当該店舗別／機種別遊技履歴リストページのデータをアクセス元の情報機器に送信する（ステップＳ４１６）。
情報機器のＣＰＵは、管理サーバ１４０から店舗別／機種別遊技履歴リストページのデータを受信し、当該店舗別／機種別遊技履歴リストページを表示部に表示させる（ステップＳ５１６）。
図７８を参照して、店舗別遊技履歴リストページには、店舗ＩＤで特定される店舗でのログインＩＤに対応する会員カードＩＤの会員の遊技履歴のリストとそれぞれの遊技履歴を選択するための複数の「詳細」ボタンが表示される。当該リストには、それぞれの遊技履歴に含まれる遊技機の機種、台番号、遊技場、および、遊技した日付が表示される。
図７９を参照して、機種別遊技履歴リストページには、機種ＩＤで特定される機種のログインＩＤに対応する会員カードＩＤの会員の遊技履歴のリストとそれぞれの遊技履歴を選択するための複数の「詳細」ボタンが表示される。当該リストには、それぞれの遊技履歴に含まれる遊技機の機種、台番号、遊技場、および、遊技した日付が表示される。
図７３に戻って、情報機器のＣＰＵは、店舗別／機種別遊技履歴リストページで「詳細」ボタンが操作された（ステップＳ５２１）と判断した場合、遊技履歴の詳細データの表示を要求する旨、選択された遊技履歴を特定する遊技履歴特定情報（遊技した日付、遊技場および台番号を特定可能な情報）およびログインＩＤを、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、遊技履歴の詳細データの表示を要求する旨、遊技履歴特定情報およびログインＩＤを受信した（ステップＳ４２１でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の遊技履歴に基づいて、当該遊技履歴特定情報で特定される遊技履歴の詳細データページを生成し、当該詳細データページのデータをアクセス元の情報機器に送信する（ステップＳ４２２）。
情報機器のＣＰＵは、管理サーバ１４０から詳細データページのデータを受信し、当該詳細データページを表示部に表示させる（ステップＳ５２２）。
図８０を参照して、詳細データページには、遊技履歴特定情報（遊技した日付、遊技場および台番号を特定可能な情報）で示される当該会員の遊技履歴（遊技機種名、遊技ホール名、遊技年月日、遊技機台番号、遊技時間、遊技開始時間、総回転数、通常回転数、大当り回数、大当り出現率（大当り回数を総回転数で割った値）、初当り回数、初当り出現率（初当り回数を総回転数で割った値）、回転率（総回転数をアウト玉数で割った値）、投資玉数、差玉数、ＭＡＸ出玉数（大当りが継続しているときの出玉数の最大値）、獲得玉数、大当り平均継続回数、大当り最大継続回数、最大ハマリ回転数（大当りが発生しなかった回転数の最大値）、スタートあふれ回数（保留記憶数が最大のときに始動入賞口に入賞した無効の始動入賞口入賞回数）、おまけ入賞口入賞回数（一般入賞口への入賞回数）、電サポ指数（高ベース中のセーフ玉数をアウト玉数で割った値）など）のデータ、当該遊技履歴の実戦データを表示させるための「実戦データへ」ボタン、および、当該遊技履歴のスランプグラフを表示させるための「スランプグラフへ」ボタンが表示される。なお、当該遊技履歴特定情報で示される日付、遊技場および台番号の当該会員以外および会員の遊技履歴を含む総遊技の遊技履歴を含めた遊技履歴（遊技履歴のスランプグラフ）を個別に表示させるようにしてもよい。また、遊技機の総遊技の遊技履歴と併せた遊技履歴やスランプグラフを個別に表示させるようにしてもよい。
図７３に戻って、情報機器のＣＰＵは、詳細データページで「実戦データへ」ボタンが操作された（ステップＳ５２３でＹＥＳ）と判断した場合、実戦データの表示を要求する旨、当該遊技履歴を特定する遊技履歴特定情報およびログインＩＤを、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、実戦データの表示を要求する旨、遊技履歴特定情報およびログインＩＤを受信した（ステップＳ４２３でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤで示される会員の遊技履歴に基づいて、当該遊技履歴特定情報で特定される遊技履歴の実戦データページを生成し、当該実戦データページのデータをアクセス元の情報機器に送信する（ステップＳ４２４）。
情報機器のＣＰＵは、管理サーバ１４０から実戦データページのデータを受信し、当該実戦データページを表示部に表示させる（ステップＳ５２４）。
図８１を参照して、実戦データページには、遊技履歴特定情報で示される遊技履歴の遊技経過を示す表、および、図８０で示した詳細データを表示させるための「詳細を見る」ボタンが表示される。遊技経過を示す表には、ログインした時間、大当りが発生した時間、大当り間の回転数、および、大当り出玉数を特定可能な情報が表示される。
図７３に戻って、情報機器のＣＰＵは、詳細データページで「スランプグラフへ」ボタンが操作された（ステップＳ５２５でＹＥＳ）と判断した場合、スランプグラフの表示を要求する旨、当該遊技履歴を特定する遊技履歴特定情報およびログインＩＤを、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、スランプグラフの表示を要求する旨、遊技履歴特定情報およびログインＩＤを受信した（ステップＳ４２５でＹＥＳ）と判断した場合、管理サーバ１４０の記憶部に記憶されている当該遊技履歴特定情報で特定される遊技機および日付の、当該ログインＩＤに対応する会員カードＩＤで示される会員およびその他の会員の遊技履歴に基づいて、当該遊技履歴特定情報で特定される遊技履歴のスランプグラフページを生成し、当該スランプグラフページのデータをアクセス元の情報機器に送信する（ステップＳ４２６）。
図８２を参照して、管理サーバ１４０の記憶されている遊技履歴には、遊技領域に打込まれた遊技球の玉数であるアウト玉のイベントごとの積算値、および、遊技機から払出された賞球の数であるセーフ玉のイベントごとの積算値などの、各台番号の遊技機および各会員ごと遊技に関する履歴の情報が含まれる。また、ＣＵ３から送信される情報に基づいて、遊技が開始されてから遊技が終了するまでの各会員ごとの遊技履歴が、一纏めの遊技履歴のデータとして管理サーバ１４０の記憶部に記憶される。
なお、遊技の開始および終了は、共通会員カードが受付けられる場合は、カード受付時のログインのイベント発生、および、カード排出時のログアウトのイベント発生によって判断され、共通会員カードが受付けられていない場合は、新たなイベントが発生したときの遊技履歴における顔ＩＤが変化したこと、および、当該顔ＩＤから別の顔ＩＤに変化したことによって判断される。
なお、前述したように、遊技履歴は、共通会員カードが受付けられている場合は会員カードＩＤとともに、ＣＵ３から管理サーバ１４０に所定のイベント発生ごとに送信され、当該会員カードＩＤに対応付けて会員の遊技履歴として管理サーバ１４０の記憶部に蓄積され、共通会員カードが受付けられていない場合は、ＣＵ３のカメラによって撮影された顔データから顔ＩＤを特定し、当該顔ＩＤに対応付けて管理サーバ１４０の記憶部に蓄積される。
スランプグラフの生成は、次のように行なわれる。まず、管理サーバのＣＰＵは、特定された日付、店舗ＩＤ、台番号の遊技履歴のうち、アウト玉およびセーフ玉を、記憶部から読出し、前述の所定のイベントごとのセーフ玉からアウト玉を引いた値を、所定のイベントごとの差玉の数として記憶部に記憶させ、記憶部に記憶されている所定のイベントの発生時間（不図示）に基づいて当該差玉の数を所定のイベントの発生時間順にプロットしてスランプグラフを生成する。遊技履歴に対応付けて顔ＩＤが記憶されているので、スランプグラフのうちのどの期間がどの顔ＩＤの遊技者であるかを示すことができる。
情報機器のＣＰＵは、管理サーバ１４０からスランプグラフページのデータを受信し、当該スランプグラフページを表示部に表示させる（ステップＳ５２６）。
図８３を参照して、スランプグラフページには、横軸を時間（営業開始時から営業終了時）、縦軸を差玉の数としたスランプグラフ、ならびに、当該スランプグラフの遊技年月日、遊技機種名、遊技ホール名、および、遊技機の台番号を示す情報、ならびに、当該会員の他の遊技者の同日および同台番号のスランプグラフも併せて表示させるための「併せて表示」ボタン、ならびに、当該会員のスランプグラフのみ表示させるための「あなただけのグラフのみ」ボタンが表示される。
本実施の形態におけるスランプグラフにおいては、当該会員が遊技した部分が太い実線、前述のフレンド機能で登録された関連会員が遊技した部分が太い波線、その他の遊技者が遊技した部分が細い実線で描かれている。この太い実線、太い波線、および、細い実線のすべての線を合わせたスランプグラフから特定されるのが、当該遊技機の当該日付における総遊技履歴（当該遊技機における一の期間における遊技機別遊技履歴）である。しかし、これに限定されず、それぞれの遊技者を区別可能にスランプグラフが描かれるようにすればよい。また、スランプグラフの横軸は、時間に限定されず、Ｐ台２の可変表示装置２７８で識別情報が変動表示した回転数またはスロットマシン２Ｓでのゲーム数であってもよい。
また、「あなただけのグラフのみ」ボタンが操作された場合、同日および同台番号のスランプグラフに当該会員のスランプグラフのみが反映され関連会員のスランプグラフは反映されない態様で、スランプグラフが表示されるようにしてもよいし、当該会員のスランプグラフのみが表示され、同日および同台番号の他の遊技者のスランプグラフは表示されない態様で、スランプグラフが表示されるようにしてもよい。
また、遊技機別遊技履歴と当該会員の遊技履歴とを区別可能に表示するのであれば、他の表示方法であってもよい。たとえば、図８３においては、当日の当該遊技機での当該会員のスランプグラフと当日の当該遊技機の当該会員以外の遊技者を含めたスランプグラフとを重ねて表示するようにしたが、並べて表示するようにしてもよい。また、遊技履歴をスランプグラフではなく、図８０で示したように数字で表示するようにして、当該会員の数字の遊技履歴と当日の当該遊技機の数字の遊技履歴を並べて表示させるようにしてもよい。
次に、前述した実施の形態により得られる主な効果を説明する。
（１） 遊技場に設置され遊技者により遊技が行なわれる遊技機（たとえば、パチンコ機、スロットマシン、封入循環式パチンコ機（Ｐ台２）、メダル不要のスロットマシン（Ｓ台２Ｓ））に対応して設けられ予め登録された遊技者である会員遊技者を個々に識別するための会員識別情報が記録された会員用記録媒体を受付ける遊技用装置と、遊技場に設置された前記遊技機における遊技履歴を前記遊技機ごとに管理し前記遊技場の外に設けられる管理装置とを含む遊技用システムであって、
各遊技機における遊技履歴を特定するための履歴特定情報を前記管理装置に送信する履歴特定情報送信手段（たとえば、ＣＵ３）と、
前記遊技用装置によって受付けられた前記会員用記録媒体に記録された前記会員識別情報を特定可能に前記管理装置に送信する会員識別情報送信手段（たとえば、ＣＵ３）とを備え、
前記管理装置は、
前記履歴特定情報送信手段によって送信される前記履歴特定情報に基づいて各遊技機における一の期間における遊技履歴である遊技機別遊技履歴（たとえば、当該遊技機の１日ごとの遊技時間、総回転数、総大当り回数など）を、各遊技機を特定可能な遊技機特定情報に対応付けて記憶する遊技機別遊技履歴記憶手段（たとえば、管理サーバ１４０の記憶部で記憶）と、
前記履歴特定情報送信手段によって送信される履歴特定情報と、前記会員識別情報送信手段によって送信される前記会員識別情報とに基づいて、一の会員遊技者の遊技履歴である会員遊技履歴（たとえば、当該遊技機での会員の遊技時間、総回転数、総大当り回数など）を、前記遊技機特定情報と前記会員識別情報とに対応付けて特定可能に記憶する会員遊技履歴記憶手段（たとえば、管理サーバ１４０の記憶部で記憶）とを備え、
会員遊技者を特定する会員特定手段（たとえば、図７２のステップＳ４０５、図７４参照。遊技者によって携帯電話１６Ａ，ノートパソコン１５Ａに手入力されたログインＩＤから会員カードＩＤを特定。共通会員カードからＣＵ３のカードリーダで読み取ることで会員カードＩＤを特定。携帯電話１６Ａ，ノートパソコン１５Ａで受付けることに限定されず、ＣＵ３，遊技情報を表示するための遊技情報表示端末で受付けるようにしてもよい。）と、
複数の前記遊技場に設置された前記遊技機のうちのいずれかの前記遊技機の選択を受付ける遊技機選択受付手段（たとえば、図７３のステップＳ４１３〜ステップＳ４２２、図７７〜図８０参照。携帯電話１６Ａ，ノートパソコン１５Ａで選択を受付けることに限定されず、ＣＵ３、遊技情報表示端末で選択を受付けるようにしてもよい。）と、
前記会員特定手段による会員遊技者の特定と前記遊技機選択受付手段により受付けた前記遊技機の選択とに基づいて、当該遊技機の前記遊技機別遊技履歴と当該遊技機での特定された会員遊技者の前記会員遊技履歴とを対応付けて表示する表示手段（たとえば、図７３のステップＳ４２６、図８３参照。個人データを強調したスランプグラフの態様で表示させる。携帯電話１６Ａ，ノートパソコン１５Ａで表示させることに限定されず、ＣＵ３，遊技情報データ表示端末に表示させるようにしてもよい。）とをさらに備える。
（１） 遊技場に設置され遊技者により遊技が行なわれる遊技機（たとえば、パチンコ機、スロットマシン、封入循環式パチンコ機（Ｐ台２）、メダル不要のスロットマシン（Ｓ台２Ｓ））に対応して設けられ予め登録された遊技者である会員遊技者を個々に識別するための会員識別情報が記録された会員用記録媒体を受付ける遊技用装置と、遊技場に設置された前記遊技機における遊技履歴を前記遊技機ごとに管理し前記遊技場の外に設けられる管理装置とを含む遊技用システムであって、
各遊技機における遊技履歴を特定するための履歴特定情報を前記管理装置に送信する履歴特定情報送信手段（たとえば、ＣＵ３）と、
前記遊技用装置によって受付けられた前記会員用記録媒体に記録された前記会員識別情報を特定可能に前記管理装置に送信する会員識別情報送信手段（たとえば、ＣＵ３）とを備え、
前記管理装置は、
前記履歴特定情報送信手段によって送信される前記履歴特定情報に基づいて各遊技機における一の期間における遊技履歴である遊技機別遊技履歴（たとえば、当該遊技機の１日ごとの遊技時間、総回転数、総大当り回数など）を、各遊技機を特定可能な遊技機特定情報に対応付けて記憶する遊技機別遊技履歴記憶手段（たとえば、管理サーバ１４０の記憶部で記憶）と、
前記履歴特定情報送信手段によって送信される履歴特定情報と、前記会員識別情報送信手段によって送信される前記会員識別情報とに基づいて、一の会員遊技者の遊技履歴である会員遊技履歴（たとえば、当該遊技機での会員の遊技時間、総回転数、総大当り回数など）を、前記遊技機特定情報と前記会員識別情報とに対応付けて特定可能に記憶する会員遊技履歴記憶手段（たとえば、管理サーバ１４０の記憶部で記憶）とを備え、
会員遊技者を特定する会員特定手段（たとえば、図７２のステップＳ４０５、図７４参照。遊技者によって携帯電話１６Ａ，ノートパソコン１５Ａに手入力されたログインＩＤから会員カードＩＤを特定。共通会員カードからＣＵ３のカードリーダで読み取ることで会員カードＩＤを特定。携帯電話１６Ａ，ノートパソコン１５Ａで受付けることに限定されず、ＣＵ３，遊技情報を表示するための遊技情報表示端末で受付けるようにしてもよい。）と、
複数の前記遊技場に設置された前記遊技機のうちのいずれかの前記遊技機の選択を受付ける遊技機選択受付手段（たとえば、図７３のステップＳ４１３〜ステップＳ４２２、図７７〜図８０参照。携帯電話１６Ａ，ノートパソコン１５Ａで選択を受付けることに限定されず、ＣＵ３、遊技情報表示端末で選択を受付けるようにしてもよい。）と、
前記会員特定手段による会員遊技者の特定と前記遊技機選択受付手段により受付けた前記遊技機の選択とに基づいて、当該遊技機の前記遊技機別遊技履歴と当該遊技機での特定された会員遊技者の前記会員遊技履歴とを対応付けて表示する表示手段（たとえば、図７３のステップＳ４２６、図８３参照。個人データを強調したスランプグラフの態様で表示させる。携帯電話１６Ａ，ノートパソコン１５Ａで表示させることに限定されず、ＣＵ３，遊技情報データ表示端末に表示させるようにしてもよい。）とをさらに備える。
このような構成によれば、表示手段によって複数の遊技場の遊技機の遊技機別遊技履歴と当該遊技機での会員遊技者の遊技履歴とが対応付けて表示される。このため、遊技者は複数の遊技場の遊技機の遊技履歴と当該遊技機での会員遊技者の遊技履歴とを対応付けて確認することができる。その結果、遊技者の利便性を向上させることが可能な遊技用システムを提供することができる。
（２） 上記（１）の遊技用システムにおいて、
前記遊技機選択受付手段は、前記会員特定手段によって特定された会員遊技者が遊技した前記遊技場のうちから前記遊技場の選択を受付け、選択された前記遊技場で当該会員遊技者が遊技した前記遊技機のうちから前記遊技機の選択を受付ける（たとえば、図７３のステップＳ４１４〜ステップＳ４２１、図７７，図７８，図８０参照）。
前記遊技機選択受付手段は、前記会員特定手段によって特定された会員遊技者が遊技した前記遊技場のうちから前記遊技場の選択を受付け、選択された前記遊技場で当該会員遊技者が遊技した前記遊技機のうちから前記遊技機の選択を受付ける（たとえば、図７３のステップＳ４１４〜ステップＳ４２１、図７７，図７８，図８０参照）。
このような構成によれば、会員遊技者が遊技した遊技機の選択を容易に行なうことができる。その結果、遊技者の利便性をさらに向上させることができる。
（３） 上記（１）の遊技用システムにおいて、
前記遊技機選択受付手段は、前記会員特定手段によって特定された会員遊技者が遊技した前記遊技機の機種のうちから前記機種の選択を受付け、選択された前記機種で当該会員遊技者が遊技した前記遊技機のうちから前記遊技機の選択を受付ける（たとえば、図７３のステップＳ４１４〜ステップＳ４２１、図７７，図７９，図８０参照）。
前記遊技機選択受付手段は、前記会員特定手段によって特定された会員遊技者が遊技した前記遊技機の機種のうちから前記機種の選択を受付け、選択された前記機種で当該会員遊技者が遊技した前記遊技機のうちから前記遊技機の選択を受付ける（たとえば、図７３のステップＳ４１４〜ステップＳ４２１、図７７，図７９，図８０参照）。
このような構成によれば、会員遊技者が遊技した遊技機の選択を容易に行なうことができる。その結果、遊技者の利便性をさらに向上させることができる。
（４） 上記（１）から（３）のいずれかの遊技用システムにおいて、
前記表示手段は、複数の前記遊技場における前記遊技機別遊技履歴と前記会員遊技履歴とを比較可能に表示する（たとえば、図８３のスランプグラフを複数の店舗分、表示させるようにしてもよい。）。
前記表示手段は、複数の前記遊技場における前記遊技機別遊技履歴と前記会員遊技履歴とを比較可能に表示する（たとえば、図８３のスランプグラフを複数の店舗分、表示させるようにしてもよい。）。
このような構成によれば、複数の遊技場における遊技機の遊技履歴と会員遊技者の遊技履歴とが比較可能に表示される。このため、遊技者は複数の遊技場における遊技履歴を容易に比較することができる。その結果、遊技者の利便性をさらに向上させることができる。
（５） 上記（１）から（４）のいずれかの遊技用システムにおいて、
前記表示手段は、前記遊技機選択受付手段によって受付けられた前記遊技機と、前記会員特定手段によって特定された会員遊技者と異なる他会員遊技者（たとえば、予め登録された関連会員遊技者、その他の会員遊技者）とに対応付けられて前記会員遊技履歴記憶手段に記憶された前記他会員遊技者の前記会員遊技履歴を、前記遊技機別遊技履歴と当該会員遊技者の前記会員遊技履歴とに対応付けて表示する（たとえば、図７３のステップＳ４２６において当該会員遊技者だけでなくフレンド機能で登録された関連会員遊技者の遊技履歴も反映させたスランプグラフを作成する。図８３参照。）。
前記表示手段は、前記遊技機選択受付手段によって受付けられた前記遊技機と、前記会員特定手段によって特定された会員遊技者と異なる他会員遊技者（たとえば、予め登録された関連会員遊技者、その他の会員遊技者）とに対応付けられて前記会員遊技履歴記憶手段に記憶された前記他会員遊技者の前記会員遊技履歴を、前記遊技機別遊技履歴と当該会員遊技者の前記会員遊技履歴とに対応付けて表示する（たとえば、図７３のステップＳ４２６において当該会員遊技者だけでなくフレンド機能で登録された関連会員遊技者の遊技履歴も反映させたスランプグラフを作成する。図８３参照。）。
このような構成によれば、他の会員遊技者の遊技履歴が当該遊技機の遊技履歴と会員遊技者の遊技履歴とに対応付けられて表示される。このため、遊技者は他の会員遊技者との比較を容易にすることができる。その結果、遊技者の利便性をさらに向上させることができる。
次に、前述した実施の形態の変形例について説明する。
（１） 前述した実施の形態においては、ＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器で遊技履歴表示機能を実行する場合について説明した。この場合、会員を特定するために図７４で示したページでログインＩＤを入力するようにし、ログインＩＤに対応付けられた会員カードＩＤを特定するようにした。しかし、これに限定されず、会員カードＩＤを直接入力するようにし、会員カードＩＤを特定するようにしてもよい。
（１） 前述した実施の形態においては、ＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器で遊技履歴表示機能を実行する場合について説明した。この場合、会員を特定するために図７４で示したページでログインＩＤを入力するようにし、ログインＩＤに対応付けられた会員カードＩＤを特定するようにした。しかし、これに限定されず、会員カードＩＤを直接入力するようにし、会員カードＩＤを特定するようにしてもよい。
また、Ｐ台２の表示器５４やＣＵ３の表示器３１２や店舗の遊技情報を表示するための遊技情報表示端末で、遊技履歴表示機能を実行するようにしてもよい。この場合、共通会員カードから会員カードＩＤを読込むことによって会員カードＩＤを特定するようにしてもよいし、情報機器の場合と同様、ログインＩＤを入力するようにし、ログインＩＤに対応付けられた会員カードＩＤを特定するようにしてもよい。また、共通会員カードを受付けているときのみログインＩＤを入力してログインができるようにしてもよい。この場合、読み取った会員カードＩＤと、ログインＩＤに対応付けて管理サーバ１４０が記憶している会員カードＩＤとの一致判定に基づいて、遊技履歴表示機能を実行するようにしてもよい。
（２） 前述した実施の形態においては、図８３で示したように、１台の遊技機の遊技履歴（たとえばスランプグラフ）に会員の遊技履歴（たとえばスランプグラフ）を反映させて表示するようにした。しかし、これに限定されず、店舗の同じ機種の同日または所定期間の平均遊技履歴、最高遊技履歴または最低遊技履歴（たとえばスランプグラフ）に、会員の遊技履歴（たとえばスランプグラフ）を反映させて表示するようにしてもよい。また、管理サーバ１４０で遊技履歴を管理している遊技機のうち同じ機種の同日または所定期間の平均遊技履歴、最高遊技履歴または最低遊技履歴（たとえばスランプグラフ）に、会員の遊技履歴（たとえばスランプグラフ）を反映させて表示するようにしてもよい。これにより、自分の遊技履歴と当該店舗または複数の店舗での同機種の遊技履歴とを比較することができ、遊技者の利便性をさらに向上させることができる。
（３） 前述した実施の形態のおいて、情報機器において、図７４で示した画面でログインＩＤとパスワードとを入力してログインした場合、一度、遊技履歴表示機能の実行を止めたとしても、所定期間（たとえば、当日中）は、再度、ログインＩＤとパスワードとを入力しなくても、遊技履歴表示機能を実行可能なように構成してもよい。これにより、遊技者の利便性をさらに向上させることができる。
なお、上述の（１）で説明したように、遊技状態表示端末で共通会員カードを受付けて遊技履歴表示機能を実行する場合は、共通会員カードが返却されるまで遊技履歴表示機能を実行可能なように構成する。
（４） 前述した実施の形態においては、図７７で示したように、階層的に遊技履歴を検索できるように構成した。しかし、これに限定されず、店舗および台番のリストなどから直接的に遊技履歴を選択できるように構成してもよい。
（５） また、同じ会員が同日に異なる店舗Ａ，Ｂで同じ機種で遊技した場合、同じ画面に店舗Ａ，Ｂでの当該会員の遊技履歴（たとえばスランプグラフ）を表示するようにしてもよい。この場合、店舗Ａ，Ｂの当該遊技機の当日の遊技履歴または同機種の遊技機での当日または所定期間の平均遊技履歴、最高遊技履歴または最低遊技履歴（たとえばスランプグラフ）を併せて表示するようにしてもよい。また、他の店舗の同機種で遊技している関連会員の遊技履歴（たとえばスランプグラフ）を併せて表示するようにしてもよい。これにより、遊技者の利便性をさらに向上させることができる。
（６） 前述した実施の形態における遊技履歴表示機能によれば、別の店舗に移った後に、元の店舗で遊技していた遊技機がその後どのような遊技履歴になっているかを確認することができる。
（７） 前述した実施の形態においては、図８３で示したように関連会員の遊技履歴を合わせて表示するようにした。しかし、関連会員に限定されず、他の遊技者、たとえば、同じ店舗または複数の店舗で、最も良い遊技履歴の遊技者または同じ程度の遊技履歴の遊技者などの遊技履歴を合わせて表示するようにしてもよい。
＜遊技履歴投稿配信機能＞
本実施の形態に係る遊技用システムは、遊技履歴を掲示板に投稿したり掲示板を遊技者の携帯電話１６Ａおよびノートパソコン（ＰＣ）１５Ａなどの情報機器に配信したりする遊技履歴投稿配信機能を有する。以下、図８４から図９０を参照して、遊技履歴投稿配信機能について説明する。
本実施の形態に係る遊技用システムは、遊技履歴を掲示板に投稿したり掲示板を遊技者の携帯電話１６Ａおよびノートパソコン（ＰＣ）１５Ａなどの情報機器に配信したりする遊技履歴投稿配信機能を有する。以下、図８４から図９０を参照して、遊技履歴投稿配信機能について説明する。
図８４および図８５は、それぞれ、遊技履歴投稿配信機能での処理の流れの概略を示す第１および第２のフローチャートである。図８６から図９０は、それぞれ、遊技履歴投稿配信機能での表示画面の例を示す第１から第５の図である。
図８４を参照して、ＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７４および図７５の「掲示板」ボタンが操作されることで、遊技情報サイトの掲示板のトップページを表示させるための操作を受付けた（ステップＳ５３１）と判断した場合、管理サーバ１４０に、当該掲示板のトップページの表示を要求する旨を送信する。
管理サーバ１４０のＣＰＵは、情報機器から掲示板のトップページの表示要求を受信した（ステップＳ４３１でＹＥＳ）と判断した場合、掲示板トップページのデータを、アクセス元の情報機器に送信する（ステップＳ４３２）。
情報機器のＣＰＵは、管理サーバ１４０から掲示板トップページのデータを受信し、当該掲示板トップページを表示部に表示させる（ステップＳ５３２）。
図８６を参照して、掲示板トップページには、検索する遊技機のカテゴリ（パチンコ、スロット）を選択入力するための入力窓、検索するキーワードを入力するための入力窓、検索対象を選択するためのラジオボタン（タイトル／機種名または本文／レス）、および、入力窓およびラジオボタンで設定された検索条件に基づいて検索を実行させるための「検索」ボタン、ならびに、機種掲示板を表示させるための「機種掲示板」ボタン、ならびに、カテゴリ別掲示板を表示させるための「カテゴリ別掲示板」ボタンが表示される。
図８４に戻って、情報機器のＣＰＵは、掲示板トップページで「機種掲示板」ボタンが操作された（ステップＳ５３３でＹＥＳ）と判断した場合、機種掲示板表示要求を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から機種掲示板表示要求を受信した（ステップＳ４３３でＹＥＳ）と判断した場合、機種掲示板トップページのデータを、アクセス元の情報機器に送信する（ステップＳ４３４）。
情報機器のＣＰＵは、管理サーバ１４０から機種掲示板トップページのデータを受信し、当該機種掲示板トップページを表示部に表示させる（ステップＳ５３４）。
図８７を参照して、機種掲示板トップページには、検索する遊技機のカテゴリ（パチンコ、スロット）を選択入力するための入力窓、検索するキーワードを入力するための入力窓、検索対象を選択するためのラジオボタン（タイトル／機種名または本文／レス）、および、入力窓およびラジオボタンで設定された検索条件に基づいて検索を実行させるための「検索」ボタン、ならびに、注目機種のスレッドのリストを表示させるためのいくつかのボタン（「ＣＲ◎◎」ボタン，「ＣＲ△△」ボタン，「ＣＲ□□」ボタン）などが表示される。
図８４に戻って、情報機器のＣＰＵは、掲示板トップページまたは機種掲示板トップページで、検索条件が入力された上で「検索」ボタンが操作された（ステップＳ５３５でＹＥＳ）と判断した場合、掲示板の検索を実行する旨および検索条件を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から掲示板の検索を実行する旨および検索条件を受信した（ステップＳ４３５でＹＥＳ）と判断した場合、検索条件に応じた掲示板のスレッド検索結果ページを、アクセス元の情報機器に送信する（ステップＳ４３６）。
情報機器のＣＰＵは、管理サーバ１４０からスレッド検索結果ページのデータを受信し、当該スレッド検索結果ページを表示部に表示させる（ステップＳ５３４）。
図８８を参照して、スレッド検索結果ページには、検索条件（ここでは、カテゴリがパチンコで、キーワードがＣＲ◎◎であること）、および、検索結果のスレッドのリストが表示される。検索結果のスレッドのリストには、スレッドのカテゴリ、スレッドを作成した投稿者、スレッドのタイトル、および、当該スレッドがお気に入りに登録された数が表示される。
また、図８４に戻って、情報機器のＣＰＵは、機種掲示板トップページで、いずれかの機種のスレッドのリストを表示させるためのボタンが操作された（ステップＳ５３７でＹＥＳ）と判断した場合、選択された機種のスレッドのリストの表示を要求する旨、および、選択された機種の機種ＩＤを管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から選択機種のスレッドのリストの表示要求および機種ＩＤを受信した（ステップＳ４３７でＹＥＳ）と判断した場合、当該機種ＩＤの機種のスレッド検索結果ページを、アクセス元の情報機器に送信する（ステップＳ４３８）。
情報機器のＣＰＵは、管理サーバ１４０からスレッド検索結果ページのデータを受信し、当該スレッド検索結果ページを表示部に表示させる（ステップＳ５３８）。当該スレッド検索結果ページは、図８８で説明したページと同様である。
図８５を参照して、情報機器のＣＰＵは、スレッド検索結果ページで、いずれかのスレッドが選択された（ステップＳ５４１でＹＥＳ）と判断した場合、選択されたスレッドの表示を要求する旨、および、選択されたスレッドを特定するためのスレッド特定情報（たとえば、スレッドが作られたときに割振られるスレッドＩＤ）を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から選択スレッドの表示（配信）要求およびスレッド特定情報を受信した（ステップＳ４４１でＹＥＳ)と判断した場合、当該スレッド特定情報で示されるスレッドページのデータを、アクセス元の情報機器に送信する（ステップＳ４４２）。
図８９を参照して、スレッドページには、スレッドの最初の投稿およびレスの内容、レスを新たに投稿するための「レスを書き込む」ボタン、および、当該スレッドをお気に入りに追加するための「お気に入りに追加」ボタンが表示される。スレッドの最初の投稿およびレスには、たとえば、Ｎｏ．２のレスで示されるように、遊技者自身の遊技履歴を貼り付ける（付加して投稿する）ことが可能とされている。
図８５に戻って、情報機器のＣＰＵは、スレッドページで、「レスを書き込む」ボタンまたは「この人にレスする」ボタンが操作された（ステップＳ５４３でＹＥＳ）と判断した場合、操作されたボタンに応じたレスを書き込む旨、および、当該スレッドのスレッド特定情報を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から操作されたボタンに応じたレスを書き込む旨およびスレッド特定情報を受信した（ステップＳ４４３でＹＥＳ）と判断した場合、当該スレッド特定情報で示されるスレッドに、操作されたボタンに応じたレスを書き込むためのレス書込みページのデータを、アクセス元の情報機器に送信する（ステップＳ４４４）。
情報機器のＣＰＵは、管理サーバ１４０からレス書込みページのデータを受信し、当該レス書込みページを表示部に表示させる（ステップＳ５４４）。
図９０を参照して、レス書込みページには、添付画像を入力するための入力窓、入力された添付画像をイメージを表示させる領域、最近の自分の遊技履歴をスレッドに掲載するための「最近のプレイデータ」ボタン、自分の遊技履歴のうち保護されているデータをスレッドに掲載するための「保護データリスト」ボタン、お気に入りの機種の自分の遊技履歴の累計データをスレッドに掲載するための「お気に入り機種累計データ」ボタン、選択された遊技履歴のイメージを表示させる領域、投稿する本文を入力するための入力窓、および、投稿内容の確認ページを表示させるための「投稿内容を確認する」ボタンが表示される。また、スレッドを新たに立ち上げるページにも、レス書込みページと同様のものが表示される。なお、お気に入りの機種は、事前に選択的に登録されている。また、レス書込みページに、過去の遊技履歴を機種別（メーカー別、タイプ別）、日別、期間別にスレッドに掲載するためのボタンが表示されるようにしてもよい。
図８５に戻って、情報機器のＣＰＵは、レス書込みページで、「最近のプレイデータ」ボタンおよび「お気に入り機種累計データ」ボタンのいずれかが操作されてプレイデータを選択する操作がされた（ステップＳ５４５でＹＥＳ）と判断した場合、選択されたプレイデータを表示するためのデータの送信要求、および、選択されたプレイデータを特定するためのプレイデータ特定情報（たとえば、遊技した日付、遊技した遊技場、遊技した遊技機の台番号を特定する情報）を、管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、選択したプレイデータを表示するためのデータの送信要求、および、プレイデータ特定情報を受信した（ステップＳ４４５でＹＥＳ）と判断した場合、選択されたプレイデータ（遊技履歴）を記憶部から読出し、当該プレイデータをレス書込みページに表示するためのデータを、アクセス元の情報機器に送信する（ステップＳ４４６）。
情報機器のＣＰＵは、管理サーバ１４０からプレイデータをレス書込みページに表示するためのデータを受信し、表示中のレス書込みページに、受信したデータで示されるプレイデータを表示させる（ステップＳ５４６）。表示されたプレイデータは、後述する投稿確認操作が行なわれると投稿内容に含められる。
このように、本実施の形態においては、図９０のレス書込みページ「最近のプレイデータ」ボタンが操作されることで、自分の遊技履歴のみを掲載することが可能とされる。ここでは、一の遊技場における一の遊技機の当該会員の遊技履歴が掲載される。また、一の遊技場や一の遊技機の遊技履歴を選択的に投稿できるようにしてもよい。
また、図９０のレス書込みページで「お気に入り機種累計データ」ボタンが操作されると、ステップＳ４４６の処理と同様、管理サーバ１４０で、事前に選択的に登録されている当該会員のお気に入り機種が特定され、特定された機種の当該会員のプレイデータ（遊技履歴の累計データ）が読出され、当該プレイデータをレス書込みページに表示するためのデータがアクセス元の情報機器に送信される。表示されたプレイデータは、後述する投稿確認操作が行なわれると投稿内容に含められる。これにより、複数の遊技場における一の機種の累計された自分の遊技履歴を掲載することが可能とされる。
また、図９０のレス書込みページで「保護データリスト」ボタンが操作されると、保護されることで削除されずに保存されている当該会員のプレイデータ（遊技履歴）のリストが表示される。このリストからプレイデータが選択されることで、表示中のレス書込みページに、当該プレイデータが表示される。これにより、遊技者が公開したいと考えているような保護されたプレイデータを容易に投稿することが可能とされる。
また、図示はされていないが遊技履歴の項目ごとに配信を許可するか否かを選択するボタンを設け、配信を許可するボタンが操作された項目については配信を許可し、配信を許可しないボタンが操作された項目については、配信を許可しないようにする。このように、配信を許可する遊技履歴の項目の設定を受付けることが可能とされる。
また、図示はされていないが当該会員が投稿した投稿情報（たとえば、図８９のスレッドのうちの一投稿情報）、当該会員が立てた掲示板のスレッド（たとえば、図８９のようなスレッド）および遊技履歴そのもの（たとえば、図７５，図７６，図８０，図８１，図８３で示したページなどで表示される当該会員の遊技履歴）など当該会員に関する情報を公開するか否かを選択するためのボタンを設け、公開するボタンが操作された場合はそれらの当該会員に関する情報を公開し、公開しないボタンが操作された場合はそれらの当該会員に関する情報を非公開とする。このように、当該会員に関する情報を公開するか否かの設定を受付けることが可能とされる。また、一部のみ公開することが可能としてもよい。たとえば、前述のフレンド機能のフレンド（関連会員）以外には公開しないように設定可能であってもよいし、特定の会員にしか公開しないように設定可能であってもよい。
なお、図８８で示した画面などで表示されるアバターやユーザのログインネームなどをクリックすると、当該ユーザの図７５で示したページが表示される。この場合に、当該ユーザの公開設定に応じて、当該ページおよびその他の遊技履歴のページが閲覧できたりできなかったりする。
図８５に戻って、情報機器のＣＰＵは、レス書込みページで「投稿内容を確認する」ボタンが操作されることで投稿確認操作が行なわれた（ステップＳ５５１でＹＥＳ）と判断した場合、投稿確認操作が行なわれた旨、投稿内容およびログインＩＤを管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から投稿確認操作が行なわれた旨、投稿内容およびログインＩＤを受信した（ステップＳ４５１でＹＥＳ）と判断した場合、当該投稿内容に本人以外の遊技履歴が含まれるか否かを判断する（ステップＳ４５２）。たとえば、投稿した人が投稿の本文に、他人の投稿からコピーした他人の遊技履歴を貼付けたり、偽造した遊技履歴を書込んだりした場合、投稿内容に本人以外の遊技履歴が含まれるようになる。
投稿内容に本人以外の遊技履歴が含まれるか否かは、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤの会員と異なる会員の遊技履歴の中に、投稿内容に含まれる遊技履歴が含まれているか否かで判断される。これにより、他人の遊技履歴が含まれるか否かだけでなく、偽造させた遊技履歴が含まれるか否かを判断することができる。
当該投稿内容に本人以外の遊技履歴が含まれる（ステップＳ４５２でＹＥＳ）と判断した場合、管理サーバ１４０のＣＰＵは、投稿の受付けを中止する（ステップＳ４５３）。なお、投稿の受付けの中止に加えて、投稿の受付けを中止した旨を報知するようにしてもよい。
一方、当該投稿内容に本人以外の遊技履歴が含まれない（ステップＳ４５２でＮＯ）と判断した場合、管理サーバ１４０のＣＰＵは、投稿内容を確認するための（図示しない）投稿確認ページのデータを、アクセス元の情報機器に送信する（ステップＳ４５４）。
情報機器のＣＰＵは、管理サーバ１４０から投稿確認ページのデータを受信し、当該投稿確認ページを表示部に表示させる（ステップＳ５５４）。投稿確認ページには、投稿内容および投稿内容を確定して投稿を完了させるための投稿確定ボタンが表示される。
情報機器のＣＰＵは、投稿確認ページで投稿確定ボタンが操作されることで投稿確定操作が行なわれた（ステップＳ５５５でＹＥＳ）と判断した場合、投稿確定操作が行なわれた旨、投稿内容およびログインＩＤを管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から投稿確定操作が行なわれた旨、投稿内容およびログインＩＤを受信した（ステップＳ４５５でＹＥＳ）と判断した場合、当該投稿内容を当該スレッドに追加して記憶部に記憶させる（ステップＳ４５６）。
なお、上述の図８５のステップＳ４４５〜ステップＳ４５６，ステップＳ５４５〜ステップＳ５５５の処理などで説明したレスを投稿するための処理と同様の処理は、スレッドを新たに立上げるページなどにおいて、スレッドを新たに立上げる処理にも実行される。
次に前述した実施の形態により得られる主な効果を説明する。
（１） 遊技に関する投稿情報を配信する配信装置（たとえば、管理サーバ１４０）を含む遊技用システムであって、
遊技者が遊技を行なった遊技機での遊技履歴情報を、前記遊技者を特定可能な遊技者特定情報（たとえば、カードＩＤ、携帯ＩＤ）に対応付けて記憶する個人遊技履歴記憶手段（たとえば、管理サーバ１４０であってもよいし、店舗ごとのサーバであってもよい）と、
前記遊技者特定情報を受付ける遊技者特定情報受付手段（たとえば、遊技者によって携帯電話１６Ａ、ノートパソコン１５Ａに手入力されたログインＩＤに対応する会員カードＩＤを受付ける。カードからＣＵ３のカードリーダで読み取られた会員カードＩＤを受付ける。）とを備え、
前記配信装置は、
前記遊技者特定情報受付手段によって受付けられた一の前記遊技者の前記遊技者特定情報に対応付けて前記個人遊技履歴記憶手段に記憶された前記遊技履歴情報を含む投稿情報を受付ける投稿受付手段（たとえば、図８５のステップＳ４５１〜ステップＳ４５５、図９０参照。携帯電話１６Ａ、ノートパソコン１５Ａから受付けることに限定されず、ＣＵ３から受付けるようにしてもよい。）と、
前記投稿情報の配信要求を受付ける配信要求受付手段（たとえば、図８５のステップＳ４４１、図８６〜図８８参照。携帯電話１６Ａ、ノートパソコン１５Ａから受付けることに限定されず、ＣＵ３から受付けるようにしてもよい。）と、
前記配信要求受付手段によって受付けられた前記配信要求で要求された前記投稿情報を配信する配信手段（たとえば、図８５のステップＳ４４２、図８９参照。携帯電話１６Ａ、ノートパソコン１５Ａに配信することに限定されず、ＣＵ３に配信するようにしてもよい。）と、
前記遊技者特定情報受付手段によって受付けられた前記一の遊技者とは異なる他の遊技者の前記遊技者特定情報に対応付けて前記個人遊技履歴記憶手段に記憶された前記遊技履歴情報を含む投稿情報の前記配信手段による配信を規制する配信規制手段（たとえば、図９０で示すように遊技履歴については、自分の遊技履歴のみを掲載することが可能とされる。また、図８５のステップＳ４５２で示すように、投稿確認時に他人の遊技履歴が含まれていないか確認し、含まれていない投稿のみを受付けるようにする。これに加えて、本文に遊技履歴と考えられる情報がある場合は、投稿受付手段によって受付けないようにしてもよいし、または、本文に遊技履歴と考えられる情報がある場合は、配信手段によって配信しないようにしてもよいし、配信しても黒塗りなどで視認できないようにしてもよい。）とを備える。
（１） 遊技に関する投稿情報を配信する配信装置（たとえば、管理サーバ１４０）を含む遊技用システムであって、
遊技者が遊技を行なった遊技機での遊技履歴情報を、前記遊技者を特定可能な遊技者特定情報（たとえば、カードＩＤ、携帯ＩＤ）に対応付けて記憶する個人遊技履歴記憶手段（たとえば、管理サーバ１４０であってもよいし、店舗ごとのサーバであってもよい）と、
前記遊技者特定情報を受付ける遊技者特定情報受付手段（たとえば、遊技者によって携帯電話１６Ａ、ノートパソコン１５Ａに手入力されたログインＩＤに対応する会員カードＩＤを受付ける。カードからＣＵ３のカードリーダで読み取られた会員カードＩＤを受付ける。）とを備え、
前記配信装置は、
前記遊技者特定情報受付手段によって受付けられた一の前記遊技者の前記遊技者特定情報に対応付けて前記個人遊技履歴記憶手段に記憶された前記遊技履歴情報を含む投稿情報を受付ける投稿受付手段（たとえば、図８５のステップＳ４５１〜ステップＳ４５５、図９０参照。携帯電話１６Ａ、ノートパソコン１５Ａから受付けることに限定されず、ＣＵ３から受付けるようにしてもよい。）と、
前記投稿情報の配信要求を受付ける配信要求受付手段（たとえば、図８５のステップＳ４４１、図８６〜図８８参照。携帯電話１６Ａ、ノートパソコン１５Ａから受付けることに限定されず、ＣＵ３から受付けるようにしてもよい。）と、
前記配信要求受付手段によって受付けられた前記配信要求で要求された前記投稿情報を配信する配信手段（たとえば、図８５のステップＳ４４２、図８９参照。携帯電話１６Ａ、ノートパソコン１５Ａに配信することに限定されず、ＣＵ３に配信するようにしてもよい。）と、
前記遊技者特定情報受付手段によって受付けられた前記一の遊技者とは異なる他の遊技者の前記遊技者特定情報に対応付けて前記個人遊技履歴記憶手段に記憶された前記遊技履歴情報を含む投稿情報の前記配信手段による配信を規制する配信規制手段（たとえば、図９０で示すように遊技履歴については、自分の遊技履歴のみを掲載することが可能とされる。また、図８５のステップＳ４５２で示すように、投稿確認時に他人の遊技履歴が含まれていないか確認し、含まれていない投稿のみを受付けるようにする。これに加えて、本文に遊技履歴と考えられる情報がある場合は、投稿受付手段によって受付けないようにしてもよいし、または、本文に遊技履歴と考えられる情報がある場合は、配信手段によって配信しないようにしてもよいし、配信しても黒塗りなどで視認できないようにしてもよい。）とを備える。
このような構成によれば、遊技者が遊技を行なった遊技機での遊技履歴情報が、遊技者を特定可能な遊技者特定情報に対応付けて記憶され、配信装置によって、一の遊技者の遊技者特定情報に対応付けて記憶された遊技履歴情報を含む投稿情報が受付けられ、投稿情報の配信要求が受付けられ、配信要求で要求された投稿情報が配信され、一の遊技者とは異なる他の遊技者の遊技者特定情報に対応付けて記憶された遊技履歴情報を含む投稿情報の配信が規制される。その結果、事実でない遊技履歴の配信を防止することで遊技者の遊技意欲を高めて遊技機の稼働を向上させることが可能な遊技用システムを提供することができる。
（２） 上記（１）の遊技用システムにおいて、
前記配信手段によって配信された前記投稿情報に含まれる他の遊技者の遊技履歴情報を含む前記投稿情報の前記投稿受付手段による受付けを規制する投稿規制手段（たとえば、図８５のステップＳ４５２で示すように、投稿確認時に他人の遊技履歴が含まれていないか確認し、含まれていない投稿のみを受付けるようにする。管理サーバ１４０で受付けを禁止することに限定されず、携帯電話１６Ａ，ノートパソコン１５Ａ側で受付けを禁止するようにしてもよい。）をさらに備える。
前記配信手段によって配信された前記投稿情報に含まれる他の遊技者の遊技履歴情報を含む前記投稿情報の前記投稿受付手段による受付けを規制する投稿規制手段（たとえば、図８５のステップＳ４５２で示すように、投稿確認時に他人の遊技履歴が含まれていないか確認し、含まれていない投稿のみを受付けるようにする。管理サーバ１４０で受付けを禁止することに限定されず、携帯電話１６Ａ，ノートパソコン１５Ａ側で受付けを禁止するようにしてもよい。）をさらに備える。
このような構成によれば、配信された投稿情報に含まれる他の遊技者の遊技履歴情報を含む投稿情報の受付けが規制される。その結果、事実でない遊技履歴の投稿を配信を防止することができる。
（３） 上記（１）または（２）の遊技用システムにおいて、
前記投稿情報に含まれる情報の項目のうち前記配信手段による配信を許可する項目の設定を受付ける配信許可設定受付手段（たとえば、遊技履歴の項目ごとに配信を許可するか否かを選択するボタンを設け、配信を許可するボタンが操作された項目については配信を許可し、配信を許可しないボタンが操作された項目については、配信を許可しないようにする。）をさらに備える。
前記投稿情報に含まれる情報の項目のうち前記配信手段による配信を許可する項目の設定を受付ける配信許可設定受付手段（たとえば、遊技履歴の項目ごとに配信を許可するか否かを選択するボタンを設け、配信を許可するボタンが操作された項目については配信を許可し、配信を許可しないボタンが操作された項目については、配信を許可しないようにする。）をさらに備える。
このような構成によれば、投稿情報に含まれる情報の項目のうち配信を許可する項目の設定が受付けられる。その結果、遊技者が公開したくない情報を公開しないようにすることができる。
（４） 上記（１）から（３）のいずれかの遊技用システムにおいて、
前記投稿情報を公開するか否かの設定を受付ける公開設定受付手段（たとえば、投稿情報を公開するか否かを選択するためのボタンを設け、投稿情報を公開するボタンが操作された場合は投稿を公開し、投稿情報を公開しないボタンが操作された場合は投稿を非公開とする。）をさらに備える。
前記投稿情報を公開するか否かの設定を受付ける公開設定受付手段（たとえば、投稿情報を公開するか否かを選択するためのボタンを設け、投稿情報を公開するボタンが操作された場合は投稿を公開し、投稿情報を公開しないボタンが操作された場合は投稿を非公開とする。）をさらに備える。
このような構成によれば、投稿情報を公開するか否かの設定が受付けられる。その結果、遊技者が投稿情報を公開したくない場合、公開しないようにすることができる。
（５） 上記（１）から（４）のいずれかの遊技用システムにおいて、
前記投稿受付手段は、複数の遊技場での前記遊技履歴情報を含む前記投稿情報を受付け可能である（たとえば、図９０の「お気に入り機種累計データ」ボタンの説明参照）。
前記投稿受付手段は、複数の遊技場での前記遊技履歴情報を含む前記投稿情報を受付け可能である（たとえば、図９０の「お気に入り機種累計データ」ボタンの説明参照）。
このような構成によれば、複数の遊技場での遊技履歴情報を含む投稿情報が受付けられる。このため、複数の遊技場での遊技履歴情報を別々に投稿しなくてもよくなる。その結果、遊技者の利便性を向上させることができる。
（６） 上記（１）から（５）のいずれかの遊技用システムにおいて、
前記投稿受付手段は、機種別の前記遊技履歴情報を含む前記投稿情報を受付け可能である（たとえば、図９０の「お気に入り機種累計データ」ボタンの説明参照）。
前記投稿受付手段は、機種別の前記遊技履歴情報を含む前記投稿情報を受付け可能である（たとえば、図９０の「お気に入り機種累計データ」ボタンの説明参照）。
このような構成によれば、機種別の遊技履歴情報を含む投稿情報が受付けられる。このため、遊技履歴情報を同じ機種の遊技機の遊技履歴情報を機種別にまとめて投稿することができる。その結果、遊技者の利便性を向上させることができる。
（７） 上記（１）から（６）のいずれかの遊技用システムにおいて、
前記個人遊技履歴記憶手段は、前記遊技が開始されてから当該遊技が終了するまでの前記遊技履歴情報を一の遊技履歴情報として記憶する（たとえば、図８２で示したように、ＣＵ３から送信される情報に基づいて、遊技が開始されてから遊技が終了するまでの遊技履歴が、一纏めの遊技履歴のデータとして管理サーバ１４０の記憶部に記憶される）。
前記個人遊技履歴記憶手段は、前記遊技が開始されてから当該遊技が終了するまでの前記遊技履歴情報を一の遊技履歴情報として記憶する（たとえば、図８２で示したように、ＣＵ３から送信される情報に基づいて、遊技が開始されてから遊技が終了するまでの遊技履歴が、一纏めの遊技履歴のデータとして管理サーバ１４０の記憶部に記憶される）。
このような構成によれば、遊技開始から終了までの遊技履歴情報が一の遊技履歴情報として記憶される。このため、データのやり取りをしやすくなる。その結果、データのやり取りが煩雑になることを防止することができる。
次に、前述した実施の形態の変形例について説明する。
（１） 本実施の形態においては、図９０で説明したように、自分の遊技履歴のみ投稿可能なように構成するようにした。また、図８５のステップＳ４５２およびステップＳ４５３で説明したように、本人以外の遊技履歴を含む場合、投稿の受付けを中止するようにした。
（１） 本実施の形態においては、図９０で説明したように、自分の遊技履歴のみ投稿可能なように構成するようにした。また、図８５のステップＳ４５２およびステップＳ４５３で説明したように、本人以外の遊技履歴を含む場合、投稿の受付けを中止するようにした。
しかし、他人の遊技履歴の配信を規制することに限定されず、自己の正しい遊技履歴以外の配信を規制するように構成してもよい。この場合、図８５のステップＳ４５２の処理において、投稿内容に含まれる遊技履歴が、管理サーバ１４０の記憶部に記憶されている当該ログインＩＤに対応する会員カードＩＤの会員の遊技履歴の中に含まれているか否かを判断する。そして、含まれていなければ、たとえば、投稿の受付けを中止することで配信を規制する一方、含まれていれば、投稿を受付けるための処理を実行するようにする。
（２） 図８９で示した遊技履歴が他人の遊技履歴であれば、コピーできないようにすることによって、他人の遊技履歴を自分の遊技履歴としての投稿または配信を規制するようにしてもよい。
（３） 図８５のステップＳ４５２で、図９０で示した投稿の本文中に、遊技履歴と考えられる数値（たとえば、遊技履歴に関連する用語（連チャン回数、大当り回数など）が付された数値など）が記載されている場合は、当該会員の管理サーバ１４０の記憶部に記憶された遊技履歴との一致度を算出し、一致度が所定値未満の場合、つまり、当該会員の遊技履歴ではないと考えられる場合は、投稿を受付けないようにしてもよい。
＜フレンド登録・仲良しフレンド登録＞
本実施の形態に係る遊技用システムにおいては、上述したように、一の会員遊技者（以下、単に「一の会員」ともいう）は、他の会員遊技者（以下、単に「他の会員」ともいう）を「フレンド」あるいは「仲良しフレンド」として予め登録しておくことができる。フレンドに登録しておくと、フレンドの遊技履歴を非フレンド（フレンドに登録されていない会員）の遊技履歴よりも簡易な操作で検索することができる。さらに、仲良しフレンドとして登録しておくと、既に述べたように、仲良しフレンドとの間で、仲良しフレンド表示、チャット、スタンプ送受信、持玉共有などの特定の処理を行なうことが可能になる。
本実施の形態に係る遊技用システムにおいては、上述したように、一の会員遊技者（以下、単に「一の会員」ともいう）は、他の会員遊技者（以下、単に「他の会員」ともいう）を「フレンド」あるいは「仲良しフレンド」として予め登録しておくことができる。フレンドに登録しておくと、フレンドの遊技履歴を非フレンド（フレンドに登録されていない会員）の遊技履歴よりも簡易な操作で検索することができる。さらに、仲良しフレンドとして登録しておくと、既に述べたように、仲良しフレンドとの間で、仲良しフレンド表示、チャット、スタンプ送受信、持玉共有などの特定の処理を行なうことが可能になる。
一の会員は、自らのＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器を操作することによって、他の会員を自らのフレンドとして登録することを他の会員に申請する「フレンド申請」を行なうことができる。
フレンド申請を受けた会員は、自らのＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器を操作することによって、そのフレンド申請を承認するか否かを選択することができる。フレンド申請を受けた会員がその申請を承認した場合、フレンド申請を受けた会員がフレンド申請を行なった会員のフレンドとして管理サーバ１４０の１次関連会員情報テーブル（図２５（ｄ）参照）に登録される。
また、既にフレンドを持つ会員は、自らのＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器を操作することによって、自らのフレンドの中から仲良しフレンドに設定する会員を選択する「仲良しフレンド設定」を行なうことができる。仲良しフレンド設定によって選択されたフレンドは、当該会員の「仲良しフレンド」として管理サーバ１４０の２次関連会員情報テーブル（図２５（ｅ）参照）に登録される。
以下、図９１〜図９９を参照して、フレンド登録・仲良しフレンド登録の処理の流れについて詳細に説明する。
＜＜フレンド申請処理＞＞
まず、一の会員がフレンド申請を行なう場合の処理について説明する。
まず、一の会員がフレンド申請を行なう場合の処理について説明する。
図９１は、フレンド申請処理の流れの概略を示すフローチャートである。この処理は、フレンド申請を行なう会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器と、管理サーバ１４０との間で行なわれる。
図９１を参照して、フレンド申請を行なう会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンド検索」ボタンの操作を受付けた場合、フレンド検索ページの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５５０）。管理サーバ１４０のＣＰＵは、情報機器からフレンド検索ページの表示要求を受信すると（ステップＳ４５０）、フレンド検索ページのデータを、アクセス元の情報機器に送信する（ステップＳ４５１）。情報機器のＣＰＵは、管理サーバ１４０からフレンド検索ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５５１）。
図９２は、フレンド検索ページの一例を示す図である。フレンド検索ページの上欄には、未だフレンドに登録されていない会員（非フレンド）の中からフレンドに登録したい会員を検索するための条件を入力する画面が表示される。この画面で、会員のニックネーム、性別、年齢、地域、称号などを入力することで、入力条件に合致する会員を検索することができる。また、キーワード検索欄にキーワードを入力したり、ＩＤ検索欄に会員カードＩＤを入力したりすることによって入力条件に合致する会員を検索することもできる。
なお、既に登録されているフレンドの中から特定のフレンドを検出する機能をさらに設けるようにしてもよい。
図９２に示すフレンド検索ページの下欄には、まだフレンドに登録されてない会員のうち、管理サーバ１４０がフレンド候補として抽出した会員が「おすすめユーザー」として表示される。
「おすすめユーザー」には、最近遊技した機種（遊技履歴の一例）が一致または近似する会員の中から４人がランダムに抽出されて表示される。非公開設定にしている会員、既にフレンドとして登録されている会員は「おすすめユーザー」の対象外となる。
なお、おすすめユーザーの抽出条件は上述した条件に限定されない。たとえば、属性情報（たとえばお気に入り機種、地域、年齢、会員カードＩＤの全部または一部）が一致または近似する会員を抽出するようにしてもよい。また、最近遊技した機種、お気に入り機種、地域、年齢、会員カードＩＤが若い順の優先順で条件が一致している会員上位１００人の中から４人をランダムに抽出するようにしてもよい。最近遊技した機種が一致する会員が１００人以上いる場合にはその中でお気に入り機種が一致している会員、地域が同じ会員、年齢が近い会員の優先順で１００人に絞り込こむようにすればよい。
「おすすめユーザー」の画面には、上記条件でランダムに表示された４人の会員のアバター画像、称号、ニックネーム、お気に入り機種、最終遊技日、獲得差玉、「遊技履歴を見る」ボタン、「フレンド申請を送る」ボタンがそれぞれ表示される。
図９１に戻って、情報機器のＣＰＵは、図９２のフレンド検索ページに入力された条件で検索された会員および図９２のおすすめユーザー欄に表示された会員の中からいずれかの会員を選択してプロフィールを表示させる操作（たとえば、おすすめユーザーの名前をタッチする操作など）を受付けた場合、当該選択された会員のプロフィールの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５５２）。管理サーバ１４０のＣＰＵは、情報機器から当該選択された会員のプロフィールの表示要求を受信すると（ステップＳ４５２）、当該選択された会員のプロフィールページのデータを、アクセス元の情報機器に送信する（ステップＳ４５３）。情報機器のＣＰＵは、管理サーバ１４０からプロフィールページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５５３）。
図９３は、プロフィールページの一例を示す図である。なお、図９３は、図９２に示すおすすめユーザーのうち、ニックネームが「パチンコ初心者」である会員のプロフィールページを例示している。プロフィールページには、選択された会員のアバター画像（コアラの画像）および称号ともに、選択された会員のプロフィール（ニックネーム、性別、生年月日、地域、自己紹介コメント）が表示される。さらに、称号の下には、「フレンド申請」ボタン、「お気に入りに追加」ボタンがそれぞれ表示される。
図９１に戻って、情報機器のＣＰＵは、図９２のフレンド検索ページに入力された条件で検索された会員の中から選択された会員あるいは図９２のおすすめユーザー欄から選択された会員の「フレンド申請を送る」ボタンの操作を受付けた場合、あるいは、図９３のプロフィールページの「フレンド申請」ボタンの操作を受付けた場合、当該会員に対するフレンド申請の作成を要求する旨を管理サーバ１４０に送信する（ステップＳ５５４）。管理サーバ１４０のＣＰＵは、情報機器から当該フレンド申請の作成要求を受信すると（ステップＳ４５４）、当該フレンド申請作成ページのデータを、アクセス元の情報機器に送信する（ステップＳ４５５）。情報機器のＣＰＵは、管理サーバ１４０からフレンド申請作成ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５５５）。
図９４は、フレンド申請作成ページの一例を示す図である。なお、図９４には、図９３のプロフィールページの「フレンド申請」ボタンが操作された場合に表示されるフレンド申請作成ページが例示されている。フレンド申請作成ページは、表示前のページ（図９４に示す例では図９３のプロフィールページ）の一部の領域にサブ画面として表示される。フレンド申請作成ページには、フレンド申請の宛先となる会員のアバター画像およびニックネームが表示され、その下には、本文入力欄と、「内容を確認する」ボタンとが表示される。
フレンド申請を行なう会員は、本文入力欄にたとえば「フレンドになってください！ よろしくお願いします。」などのメッセージを入力し、「内容を確認する」ボタンを操作すると、情報機器の表示部には内容確認ページ（図示せず）が表示される。この内容確認ページで入力内容を確認したことを示す操作を行なうことによって、フレンド申請の受付けを要求することができる。
図９１に戻って、情報機器のＣＰＵは、フレンド申請の受付けを要求する操作を受付けた場合、当該フレンド申請の受付けを要求する旨を管理サーバ１４０に送信する（ステップＳ５５６）。管理サーバ１４０のＣＰＵは、情報機器から当該フレンド申請の受付け要求を受信すると（ステップＳ４５６）、当該フレンド申請を受付けるとともに、フレンド申請受付完了ページのデータを、アクセス元の情報機器に送信する（ステップＳ４５７）。情報機器のＣＰＵは、管理サーバ１４０からフレンド申請受付完了ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５５７）。これにより、フレンド申請の受付けが完了し、後述するように、フレンド申請の宛先となる会員のフレンドリクエスト一覧ページに申請内容が表示されることになる。
＜＜フレンド登録（１次登録）処理＞＞
次に、フレンド登録処理について説明する。本実施例では、フレンド申請を受けた会員がその申請を承認した場合に、フレンド申請を受けた会員がフレンド申請を行なった会員の「フレンド」として登録される。
次に、フレンド登録処理について説明する。本実施例では、フレンド申請を受けた会員がその申請を承認した場合に、フレンド申請を受けた会員がフレンド申請を行なった会員の「フレンド」として登録される。
図９５は、フレンド登録処理の流れの概略を示すフローチャートである。この処理は、フレンド申請を受けた会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器と、管理サーバ１４０との間で行なわれる。
図９５を参照して、フレンド申請を受けた会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンドリクエスト」ボタンの操作を受付けた場合、フレンドリクエストの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５６０）。管理サーバ１４０のＣＰＵは、情報機器からフレンドリクエストの表示要求を受信すると（ステップＳ４６０）、フレンドリクエスト一覧ページのデータを、アクセス元の情報機器に送信する（ステップＳ４６１）。情報機器のＣＰＵは、管理サーバ１４０からフレンドリクエスト一覧ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５６１）。
図９６は、フレンドリクエスト一覧ページの一例を示す図である。フレンドリクエスト一覧ページには、「フレンドリクエスト」ボタンを操作した会員を宛先とするフレンド申請者の一覧が表示される。具体的には、フレンド申請を行なった会員のユーザー名（アバター画像、ニックネーム）、そのフレンド申請の受信日時、メッセージ内容、「承認」ボタン、「拒否」ボタンが、各会員ごとに表示される。なお、図９６に示す例では、全フレンド申請者２５人のうち、１〜５人が１ページ目に表示されている。ページ切り替えボタンを操作することで、他ページのフレンド申請者を表示させることができる。なお、フレンド申請者がいない場合には、その旨が表示される。フレンド申請を受けた会員は、各フレンド申請者のメッセージ内容などを確認して、その申請を承認するか否かを各フレンド申請者ごとに選択することができる。フレンド申請を受けた会員は、「承認」ボタンを操作することで当該フレンド申請を承認することができ、「拒否」ボタンを操作することで当該フレンド申請を拒否することができる。
図９５に戻って、情報機器のＣＰＵは、フレンド申請を承認する操作を受付けた場合、当該フレンド申請の承認を要求する旨を管理サーバ１４０に送信する（ステップＳ５６２）。管理サーバ１４０のＣＰＵは、情報機器から当該フレンド申請の承認要求を受信すると（ステップＳ４６２）、フレンド申請を受けた会員をフレンド申請を行なった会員の「フレンド」として図２５（ｄ）に示した１次関連会員情報テーブルに登録するとともに、フレンド登録完了ページのデータを、アクセス元の情報機器に送信する（ステップＳ４６３）。情報機器のＣＰＵは、管理サーバ１４０からフレンド登録完了ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５６３）。これにより、フレンド登録が完了する。
＜＜仲良しフレンド登録（２次登録）処理＞＞
次に、仲良しフレンド登録処理について説明する。本実施例では、既に１次登録されたフレンドを持つ会員が、自らのフレンドの中から仲良しフレンドに設定する会員を選択することで、当該選択されたフレンドを「仲良しフレンド」として２次登録することができる。
次に、仲良しフレンド登録処理について説明する。本実施例では、既に１次登録されたフレンドを持つ会員が、自らのフレンドの中から仲良しフレンドに設定する会員を選択することで、当該選択されたフレンドを「仲良しフレンド」として２次登録することができる。
図９７は、仲良しフレンド登録処理の流れの概略を示すフローチャートである。
図９７を参照して、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンドリスト」ボタンの操作を受付けた場合、フレンドリストの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５７０）。管理サーバ１４０のＣＰＵは、情報機器からフレンドリストの表示要求を受信すると（ステップＳ４７０）、フレンドリストページのデータを、アクセス元の情報機器に送信する（ステップＳ４７１）。情報機器のＣＰＵは、管理サーバ１４０からフレンドリストページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５７１）。
図９７を参照して、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンドリスト」ボタンの操作を受付けた場合、フレンドリストの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５７０）。管理サーバ１４０のＣＰＵは、情報機器からフレンドリストの表示要求を受信すると（ステップＳ４７０）、フレンドリストページのデータを、アクセス元の情報機器に送信する（ステップＳ４７１）。情報機器のＣＰＵは、管理サーバ１４０からフレンドリストページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５７１）。
図９８は、フレンドリストページの一例を示す図である。フレンドリストページには、自らのフレンドとして登録されている会員の情報が一覧表示される。具体的には、フレンドとして登録されている会員のアバター画像、称号、ニックネーム、お気に入り機種、最終遊技日、獲得差玉、「遊技履歴を見る」ボタン、「メッセージを送る」ボタン、「設定」ボタンが、各フレンド欄にそれぞれ表示される。なお、図９８には、全フレンド１２０人中、１〜２０人が１ページ目に表示される例が示されている。ページ切り替えボタンを操作することで、他ページのフレンドを表示させることができる。なお、フレンドが登録されていない場合には、その旨が表示される。会員は、フレンドリストページ中の「設定ボタン」を操作することによって、後述するフレンド設定ページを表示させることができる。
図９７に戻って、情報機器のＣＰＵは、フレンド設定ページを表示させる操作（図９８の「設定」ボタンの操作）を受付けた場合、フレンド設定ページの表示を要求する旨を管理サーバ１４０に送信する（ステップＳ５７３）。管理サーバ１４０のＣＰＵは、情報機器からフレンド設定ページの表示要求を受信すると（ステップＳ４７３）、フレンド設定ページのデータを、アクセス元の情報機器に送信する（ステップＳ４７４）。情報機器のＣＰＵは、管理サーバ１４０からフレンド設定ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５７４）。
図９９は、フレンド設定ページの一例を示す図である。フレンド設定ページは、図９８に示すフレンドリストページの一部の領域にサブ画面として表示される。フレンド設定ページには、選択されたフレンドのアバター画像およびニックネームが表示され、その右横には「仲良しに設定」ボタンと、「フレンド解除」ボタンとが表示される。「フレンド解除」ボタンを操作することで、そのフレンドの登録を解除することができる。「仲良しに設定」ボタンを操作することで、そのフレンドを仲良しフレンドとして登録することができる。
また、フレンド設定ページには、「『仲良し』になると、ホールでチャットやスタンプが送れるよ！」とのメッセージが表示される。このメッセージに表示されているように、本実施の形態においては、仲良しフレンドに登録すると、仲良しフレンドとの間で上述したチャット機能やスタンプ送受信機能が利用できるようになる。また、上述した仲良しフレンド表示機能、持玉共有機能も利用することができる。
また、フレンド設定ページには、「※最大１０人まで『仲良し』設定が可能」とのメッセージが表示される。このメッセージに表示されているように、本実施の形態においては、仲良しフレンドに登録可能な人数に上限数が設けられている。
図９７に戻って、情報機器のＣＰＵは、仲良しフレンドを設定する操作（図９９に示すフレンド設定ページの「仲良しに設定」ボタンの操作）を受付けた場合、仲良しフレンドの設定を要求する旨を管理サーバ１４０に送信する（ステップＳ５７５）。管理サーバ１４０のＣＰＵは、情報機器から仲良しフレンドの設定要求を受信すると（ステップＳ４７５）、要求されたフレンドを仲良しフレンドとして図２５（ｅ）に示した２次関連会員情報テーブルに登録するとともに、仲良しフレンド登録完了ページのデータを、アクセス元の情報機器に送信する（ステップＳ４７６）。情報機器のＣＰＵは、管理サーバ１４０から仲良しフレンド登録完了ページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５７６）。これにより、仲良しフレンド登録が完了する。
仲良しフレンド登録が完了すると、仲良しフレンドとの間で上述した仲良しフレンド表示機能、チャット機能、スタンプ送受信機能、持玉共有機能などの特定の機能を利用できるようになる。
＜会員情報表示処理＞
本実施の形態に係る遊技用システムは、管理サーバ１４０に管理されている自らの会員情報（属性情報や遊技履歴）だけでなく、他の会員の会員情報を検索して閲覧することができる。なお、会員管理コンピュータ１２０に管理されている他の会員の会員情報を検索して閲覧できるようにしてもよい。
本実施の形態に係る遊技用システムは、管理サーバ１４０に管理されている自らの会員情報（属性情報や遊技履歴）だけでなく、他の会員の会員情報を検索して閲覧することができる。なお、会員管理コンピュータ１２０に管理されている他の会員の会員情報を検索して閲覧できるようにしてもよい。
本実施の形態においては、フレンドの会員情報だけでなく、非フレンド（フレンドに登録されていない会員）の会員情報も検索することができるが、フレンドの会員情報は、非フレンドの会員情報よりも簡易な操作で検索することができる。
以下、図１００、図１０１を参照して、会員情報表示処理の流れについて説明する。
＜＜会員情報表示処理（フレンド）＞＞
図１００は、フレンドの会員情報を表示させる処理の流れの概略を示すフローチャートである。
＜＜会員情報表示処理（フレンド）＞＞
図１００は、フレンドの会員情報を表示させる処理の流れの概略を示すフローチャートである。
図１００を参照して、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンドリスト」ボタンの操作を受付けた場合、管理サーバ１４０との通信を行なって、図９８に示したフレンドリストページを表示部に表示させる（ステップＳ５７０，Ｓ５７１，Ｓ４７０，Ｓ４７１）。このフレンドリストページ上には、図９８に示したように、既に登録されている自らのフレンドが一覧表示される。なお、ステップＳ５７０，Ｓ５７１，Ｓ４７０，Ｓ４７１の処理の詳細については、前述の図９７で説明したものと同じであるのでここでの詳細な説明は繰り返さない。
情報機器のＣＰＵは、図９８に示したフレンドリストページ上に一覧表示されたフレンドの中から閲覧対象者を選択する操作を受付けた場合、閲覧対象者の会員情報を要求する旨を管理サーバ１４０に送信する（Ｓ５８０）。たとえば、情報機器のＣＰＵは、図９８に示したフレンドリストページ上で特定のフレンドのアバター画像を選択する操作を受付けた場合、当該選択されたアバター画像のフレンドの詳細な属性情報を要求する旨を管理サーバ１４０に送信する。また、情報機器のＣＰＵは、図９８に示したフレンドリストページ上で「遊技履歴を見る」ボタンの操作を受付けた場合、当該「遊技履歴を見る」ボタンが操作されたフレンドの遊技履歴を要求する旨を管理サーバ１４０に送信する。
管理サーバ１４０のＣＰＵは、情報機器から閲覧対象者の会員情報要求を受信すると（ステップＳ４８０）、要求された閲覧対象者の会員情報（属性情報、遊技履歴など）を表示するページのデータを、アクセス元の情報機器に送信する（ステップＳ４８１）。情報機器のＣＰＵは、管理サーバ１４０から閲覧対象者の会員情報を表示するページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５８１）。
このように、本実施の形態においては、閲覧対象者を絞り込む検索条件を入力する操作を行なうことなく、フレンドリストを表示させ、表示されたフレンドの中から閲覧対象者を選択するという簡易な操作で、フレンドの会員情報を検索することができる。
＜＜会員情報表示処理（非フレンド）＞＞
図１０１は、フレンドとして登録されていない会員（非フレンド）の会員情報を表示させる処理の流れの概略を示すフローチャートである。
図１０１は、フレンドとして登録されていない会員（非フレンド）の会員情報を表示させる処理の流れの概略を示すフローチャートである。
図１０１を参照して、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器のＣＰＵは、実行中のブラウザにおいて、図７５に示したマイトップページ上で「フレンド検索」ボタンの操作を受付けた場合、管理サーバ１４０との通信を行なって、図９２に示したフレンド検索ページを表示部に表示させる（ステップＳ５５０，Ｓ５５１，Ｓ４５０，Ｓ４５１）。このフレンド検索ページ上には、図９２に示したように、対象者のニックネーム、性別、年齢、地域、称号などを入力する欄や、キーワードを入力したり、会員カードＩＤを入力したりする欄が表示される。なお、ステップＳ５５０，Ｓ５５１，Ｓ４５０，Ｓ４５１の処理の詳細については、前述の図９１で説明したものと同じであるのでここでの詳細な説明は繰り返さない。
情報機器のＣＰＵは、フレンド検索ページ上で会員検索条件の入力を受付けた場合、入力された会員検索条件を示す情報を管理サーバ１４０に送信する（Ｓ５９２）。管理サーバ１４０のＣＰＵは、情報機器から会員検索条件を示す情報を受信すると（ステップＳ４９２）、受信した会員検索条件に合致する会員を自らが記憶している会員情報データから検索（抽出）し、検索結果を表示するページのデータをアクセス元の情報機器に送信する（ステップＳ４９３）。情報機器のＣＰＵは、管理サーバ１４０から検索結果を表示するページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５９３）。なお、検索結果を表示するページには、入力された会員検索条件に従って抽出された会員のアバター画像およびニックネームが表示される。
情報機器のＣＰＵは、検索結果を表示するページ上に表示された会員の中から閲覧対象者を選択する操作を受付けた場合、選択された閲覧対象者の会員情報を要求する旨を管理サーバ１４０に送信する（Ｓ５９４）。この際、閲覧対象者の属性情報を要求する操作を受付けた場合には閲覧対象者の属性情報を要求する旨を送信し、閲覧対象者の遊技履歴を要求する操作を受付けた場合には閲覧対象者の遊技履歴を要求する旨を送信するようにしてもよい。
管理サーバ１４０のＣＰＵは、情報機器から閲覧対象者の会員情報要求を受信すると（ステップＳ４９４）、要求された閲覧対象者の会員情報（属性情報、遊技履歴など）を表示するページのデータを、アクセス元の情報機器に送信する（ステップＳ４９５）。情報機器のＣＰＵは、管理サーバ１４０から閲覧対象者の会員情報を表示するページのデータを受信し、当該ページを表示部に表示させる（ステップＳ５９５）。
このように、本実施の形態においては、フレンドの会員情報だけでなく、非フレンドの会員情報も検索することができるが、多数の非フレンドの会員情報を検索する場合には、まず閲覧対象者を絞り込む検索条件を入力する操作を行なう手間が必要になる。
次に前述した実施の形態により得られる主な効果を説明する。
（１） 遊技場において遊技機（パチンコ機、スロットマシン、封入循環式パチンコ機（Ｐ台２）、メダル不要のスロットマシン（Ｓ台２Ｓ））に１対１に対応して設けられ受付けた記録媒体により特定される遊技者所有の遊技価値を用いて遊技機での遊技を可能にする遊技用装置（ＣＵ３、呼出しランプ装置など）と、前記遊技場の外に設置され前記記録媒体の記録情報に対応付けて会員登録された各会員遊技者の会員情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員、遊技履歴など）を管理する管理装置（たとえば、管理サーバ１４０）とを含む遊技用システムであって、
前記管理装置は、
会員登録された一の会員遊技者が会員登録された他の会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ１次関連会員遊技者として登録する１次登録手段（たとえば、図９１、図９５：一の会員遊技者が他の会員遊技者から選択してフレンド申請を行なった会員遊技者を、一の会員遊技者の「フレンド」として登録する）と、
前記一の会員遊技者が前記１次関連会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ２次関連会員遊技者として登録する２次登録手段（たとえば、図９７：一の会員遊技者が自らの「フレンド」の中から選択した会員遊技者を、一の会員遊技者の「仲良しフレンド」として登録する）とを有し、
前記一の会員遊技者と前記２次関連会員遊技者との間で特定処理を実行する特定処理手段（たとえば、図３８、図３９：仲良しフレンドとのチャットを行なう、図４０〜図４３：仲良しフレンドとの持玉（持点）共有を行なう、仲良しフレンドとのスタンプ送受信を行なうなど）をさらに含む。
（１） 遊技場において遊技機（パチンコ機、スロットマシン、封入循環式パチンコ機（Ｐ台２）、メダル不要のスロットマシン（Ｓ台２Ｓ））に１対１に対応して設けられ受付けた記録媒体により特定される遊技者所有の遊技価値を用いて遊技機での遊技を可能にする遊技用装置（ＣＵ３、呼出しランプ装置など）と、前記遊技場の外に設置され前記記録媒体の記録情報に対応付けて会員登録された各会員遊技者の会員情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員、遊技履歴など）を管理する管理装置（たとえば、管理サーバ１４０）とを含む遊技用システムであって、
前記管理装置は、
会員登録された一の会員遊技者が会員登録された他の会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ１次関連会員遊技者として登録する１次登録手段（たとえば、図９１、図９５：一の会員遊技者が他の会員遊技者から選択してフレンド申請を行なった会員遊技者を、一の会員遊技者の「フレンド」として登録する）と、
前記一の会員遊技者が前記１次関連会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ２次関連会員遊技者として登録する２次登録手段（たとえば、図９７：一の会員遊技者が自らの「フレンド」の中から選択した会員遊技者を、一の会員遊技者の「仲良しフレンド」として登録する）とを有し、
前記一の会員遊技者と前記２次関連会員遊技者との間で特定処理を実行する特定処理手段（たとえば、図３８、図３９：仲良しフレンドとのチャットを行なう、図４０〜図４３：仲良しフレンドとの持玉（持点）共有を行なう、仲良しフレンドとのスタンプ送受信を行なうなど）をさらに含む。
このような構成によれば、一の会員遊技者が特定処理を行なう相手を選択するには、単に１次関連会員遊技者を選択するだけでなく、さらに１次関連会員遊技者の中から２次関連会員遊技者を選択する必要がある。そのため、特定処理を行なう相手を慎重に選択できるようにすることができる。
（２） 上記（１）の遊技用システムにおいて、
前記１次登録手段は、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録することを前記他の会員遊技者が承認した場合に、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録する（たとえば、図９５のＳ４６２、Ｓ４６３：他の会員遊技者が一の会員遊技者からのフレンド申請を承認した場合に、他の会員遊技者を一の会員遊技者の「フレンド」として登録する）。
前記１次登録手段は、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録することを前記他の会員遊技者が承認した場合に、前記他の会員遊技者を前記一の会員遊技者の前記１次関連会員遊技者として登録する（たとえば、図９５のＳ４６２、Ｓ４６３：他の会員遊技者が一の会員遊技者からのフレンド申請を承認した場合に、他の会員遊技者を一の会員遊技者の「フレンド」として登録する）。
このような構成によれば、本人の承諾なしに１次関連会員遊技者として登録されてしまうことを防止することができる。その結果、特定処理を行なう相手をより慎重に選択できるようにすることができる。
（３） 上記（１）または（２）の遊技用システムにおいて、
前記一の会員遊技者が第１操作を行なったことに応じて、前記他の会員遊技者の前記会員情報を表示する手段（たとえば、図１０１：一の会員遊技者が他の会員遊技者を絞り込むための検索条件を入力する操作を行なったことを少なくとも１つの条件として、他の会員遊技の遊技履歴を表示する）と、
前記一の会員遊技者が前記第１操作よりも簡易な第２操作を行なったことに応じて、前記１次関連会員遊技者の前記会員情報を表示する手段（たとえば、図１００：フレンドリストから閲覧対象者を選択する操作を行なったことを１つの条件として、フレンドの遊技履歴を表示する）とをさらに含む。
前記一の会員遊技者が第１操作を行なったことに応じて、前記他の会員遊技者の前記会員情報を表示する手段（たとえば、図１０１：一の会員遊技者が他の会員遊技者を絞り込むための検索条件を入力する操作を行なったことを少なくとも１つの条件として、他の会員遊技の遊技履歴を表示する）と、
前記一の会員遊技者が前記第１操作よりも簡易な第２操作を行なったことに応じて、前記１次関連会員遊技者の前記会員情報を表示する手段（たとえば、図１００：フレンドリストから閲覧対象者を選択する操作を行なったことを１つの条件として、フレンドの遊技履歴を表示する）とをさらに含む。
このような構成によれば、他の会員遊技者を予め１次関連会員遊技者として登録しておくことで、簡易な操作で当該１次関連会員遊技者の会員情報を閲覧することができる。その結果、遊技者の利便性を向上させることができる。
（４） 上記（３）の遊技用システムにおいて、
前記第１操作は、検索条件入力画面を表示させる操作（たとえば、図１０１のＳ５９０：会員検索要求操作）と、表示された前記検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作（たとえば、図１０１のＳ５９２：会員検索条件入力操作）と、入力された前記検索条件に従って抽出された前記他の会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１０１のＳ５９４：閲覧対象者選択操作）とを含み、
前記第２操作は、前記１次関連会員遊技者を一覧表示させる操作（たとえば、図１００のＳ５７０：フレンドリスト操作）と、一覧表示された前記１次関連会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１００のＳ５８０：閲覧対象者選択操作）とを含む。
前記第１操作は、検索条件入力画面を表示させる操作（たとえば、図１０１のＳ５９０：会員検索要求操作）と、表示された前記検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作（たとえば、図１０１のＳ５９２：会員検索条件入力操作）と、入力された前記検索条件に従って抽出された前記他の会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１０１のＳ５９４：閲覧対象者選択操作）とを含み、
前記第２操作は、前記１次関連会員遊技者を一覧表示させる操作（たとえば、図１００のＳ５７０：フレンドリスト操作）と、一覧表示された前記１次関連会員遊技者の中から閲覧対象者を前記一の会員遊技者が選択する操作（たとえば、図１００のＳ５８０：閲覧対象者選択操作）とを含む。
このような構成によれば、他の会員遊技者を予め１次関連会員遊技者として登録しておくことで、検索条件入力画面に閲覧対象者を絞り込む検索条件を入力する操作を行なわなくても当該１次関連会員遊技者の会員情報を閲覧することができる。その結果、遊技者の利便性を向上させることができる。
（５） 上記（１）〜（４）のいずれかの遊技用システムにおいて、
前記特定処理手段は、前記特定処理として、前記一の会員遊技者による遊技中に、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者と当該一の会員遊技者との間でメッセージを送受信する処理（たとえば、図３８、図３９：同じ遊技場内で遊技している仲良しフレンドとのチャットを行なう処理）を行なう手段を含む。
前記特定処理手段は、前記特定処理として、前記一の会員遊技者による遊技中に、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者と当該一の会員遊技者との間でメッセージを送受信する処理（たとえば、図３８、図３９：同じ遊技場内で遊技している仲良しフレンドとのチャットを行なう処理）を行なう手段を含む。
このような構成によれば、同じ遊技場内で遊技している２次関連会員遊技者との間でメッセージ送受信によるコミュニケーションをとることができる。その結果、遊技の興趣を向上させることができる。
（６） 上記（１）〜（５）のいずれかの遊技用システムにおいて、
前記会員情報には、属性情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員など）が含まれ、
前記他の会員遊技者の中から前記属性情報が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から属性情報が一致または近似する会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して表示する。「フレンド」の中から属性情報が一致または近似する会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
前記会員情報には、属性情報（たとえば、氏名、性別、年齢、登録済遊技場、お気に入り機種、１次関連会員、２次関連会員など）が含まれ、
前記他の会員遊技者の中から前記属性情報が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から属性情報が一致または近似する会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して表示する。「フレンド」の中から属性情報が一致または近似する会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
このような構成によれば、自らに嗜好などが似ている遊技者を１次関連会員遊技者あるいは２次関連会員遊技者として登録し易くなる。その結果、遊技者の利便性を向上させることができる。
（７） 上記（１）〜（５）のいずれかの遊技用システムにおいて、
前記会員情報には、遊技履歴が含まれ、
前記他の会員遊技者の中から前記遊技履歴が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から遊技履歴が一致または近似する会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して表示する。「フレンド」の中から遊技履歴が一致または近似する会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
前記会員情報には、遊技履歴が含まれ、
前記他の会員遊技者の中から前記遊技履歴が前記一の会員遊技者と一致または近似する遊技者を抽出して表示する手段（たとえば、図９２：他の会員遊技者の中から遊技履歴が一致または近似する会員遊技者を「フレンド」の候補者（おすすめユーザー）として抽出して表示する。「フレンド」の中から遊技履歴が一致または近似する会員遊技者を「仲良しフレンド」の候補者として抽出して表示するようにしてもよい。）をさらに含む。
このような構成によれば、自らに遊技履歴が似ている遊技者を１次関連会員遊技者あるいは２次関連会員遊技者として登録し易くなる。その結果、遊技者の利便性を向上させることができる。
（８） 上記（１）〜（７）のいずれかの遊技用システムにおいて、
前記遊技用装置が受付けた一の会員遊技者と関連性を持つ前記２次関連会員遊技者のうち、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者を、当該２次関連会員遊技者の遊技状況とともに表示する手段をさらに含む（図３７：「仲良しフレンド」のアバターを、大当りなどの遊技状況とともに表示する）。
前記遊技用装置が受付けた一の会員遊技者と関連性を持つ前記２次関連会員遊技者のうち、当該一の会員遊技者と同じ遊技場内で遊技中の前記２次関連会員遊技者を、当該２次関連会員遊技者の遊技状況とともに表示する手段をさらに含む（図３７：「仲良しフレンド」のアバターを、大当りなどの遊技状況とともに表示する）。
このような構成によれば、同じ遊技場内で遊技している２次関連会員遊技者と、その２次関連会員遊技者の遊技状況とを同時に確認することができる。その結果、遊技者の利便性を向上させることができる。
（９） 上記（１）〜（８）のいずれかの遊技用システムにおいて、
前記遊技機での遊技に関する遊技関連情報（トップボタン、メニューボタン、離席ボタン、返却ボタン、玉貸しボタン、再プレイボタン、払出ボタン、入金の残額、持玉数（持点数）、貯玉数、遊技玉数（遊技点数）など）を表示する表示領域を有する表示手段（表示器５４、３１２）と、
前記遊技用装置に入力される入力を受け付ける受付手段（たとえば、ＣＵ３が入金操作、玉貸し操作、払出操作、再プレイ操作、ログイン操作、広告表示操作、返却操作、離席操作などを受け付ける）と、
前記受付手段が受け付けた入力の種類に基づいて、前記表示手段に表示される広告情報の表示態様を設定する設定手段（たとえば、ＣＵ３が広告情報を表示する広告表示領域を設定する、ＣＵ３が広告情報を表示する時間を設定する）と、
前記設定手段により設定された前記表示態様で前記広告情報を前記表示手段に表示させる表示制御手段（たとえば、図４４〜図４７：ＣＵ３が設定された表示領域に広告情報を表示する）とをさらに含む。
前記遊技機での遊技に関する遊技関連情報（トップボタン、メニューボタン、離席ボタン、返却ボタン、玉貸しボタン、再プレイボタン、払出ボタン、入金の残額、持玉数（持点数）、貯玉数、遊技玉数（遊技点数）など）を表示する表示領域を有する表示手段（表示器５４、３１２）と、
前記遊技用装置に入力される入力を受け付ける受付手段（たとえば、ＣＵ３が入金操作、玉貸し操作、払出操作、再プレイ操作、ログイン操作、広告表示操作、返却操作、離席操作などを受け付ける）と、
前記受付手段が受け付けた入力の種類に基づいて、前記表示手段に表示される広告情報の表示態様を設定する設定手段（たとえば、ＣＵ３が広告情報を表示する広告表示領域を設定する、ＣＵ３が広告情報を表示する時間を設定する）と、
前記設定手段により設定された前記表示態様で前記広告情報を前記表示手段に表示させる表示制御手段（たとえば、図４４〜図４７：ＣＵ３が設定された表示領域に広告情報を表示する）とをさらに含む。
このような構成によれば、遊技用装置が受け付けた入力の種類に応じた表示態様で広告情報が表示される。そのため、広告情報によって遊技者の遊技中の操作が妨げられることはなく、遊技者に対して不快感を与えることもない。また、入力の種類に応じた表示態様で広告情報が表示されるため、広告の宣伝効果を向上させることができる。
次に、前述した実施の形態の変形例について説明する。
（１） 本実施の形態においては、上述のフレンド申請処理（図９１）、フレンド登録処理（図９５）、仲良しフレンド登録処理（図９７）、会員情報表示処理（図１００、図１０１）を、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器から行なう場合を説明したが、これらの処理の全部または一部を各遊技場のＣＵ３から行なえるように構成してもよい。あるいは、これらの処理の全部または一部を各遊技場のＣＵ３からのみ行なえるようにし、会員のＰＣ１５Ａまたは携帯電話１６Ａからは行なえないようにしてもよい。
（１） 本実施の形態においては、上述のフレンド申請処理（図９１）、フレンド登録処理（図９５）、仲良しフレンド登録処理（図９７）、会員情報表示処理（図１００、図１０１）を、会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器から行なう場合を説明したが、これらの処理の全部または一部を各遊技場のＣＵ３から行なえるように構成してもよい。あるいは、これらの処理の全部または一部を各遊技場のＣＵ３からのみ行なえるようにし、会員のＰＣ１５Ａまたは携帯電話１６Ａからは行なえないようにしてもよい。
また、会員がフレンド申請処理（図９１）を各遊技場のＣＵ３から行なう場合には、同じ遊技場で遊技している会員の中からフレンドの候補者（おすすめユーザー）を抽出するようにしてもよい。
なお、同じ遊技場で遊技している会員を特定する手法は、仲良しフレンド表示機能で用いる手法と同じ手法を用いることができる。すなわち、会員がフレンド申請処理（図９１）を遊技場のＣＵ３から行なう場合には、当該遊技場の会員管理コンピュータ１２０あるいは当該遊技場の会員管理コンピュータ１２０から情報を受けた管理サーバ１４０で、同じ遊技場内で遊技している会員を特定するようにすればよい。
（２） 本実施の形態においては、非フレンドの会員情報（遊技履歴、属性情報）を表示するページを表示部に表示させることができる（図１０１のＳ５９５）が、このページからフレンド申請処理（図９１）を行なえるように構成してもよい。このようにすると、非フレンドの会員情報（遊技履歴、属性情報）を確認した上で、フレンド申請を行なうことができる。
（３） 本実施の形態においては、管理サーバ１４０がフレンドに登録されてない会員の中から遊技履歴あるいは属性情報が一致または近似する会員を抽出してフレンドの候補者（おすすめユーザー）として表示した（図９２）が、既にフレンドとして登録されている会員の中から遊技履歴あるいは属性情報が一致または近似する会員を抽出して仲良しフレンドの候補者（おすすめユーザー）として表示するようにしてもよい。
（４） 本実施の形態においては、フレンド登録を行なうには相手の承認を必要とした（図９５）が、相手の承認を得ることなくフレンド登録を行なえるようにしてもよい。
（５） 本実施の形態においては、仲良しフレンドとの間で持玉共有機能（図４０〜図４３）を利用できるが、持玉共有機能を利用できる機種を同一機種同士に限定したり、あるいは持玉共有機能を利用できる持玉を同一単価（たとえば、パチンコ玉１玉１円または４円、メダル１枚５円または２０円）同士に限定したりするようにしてもよい。
（６） 本実施の形態においては、仲良しフレンド表示機能、チャット機能、スタンプ送受信機能、持玉共有機能などの特定機能を、同じ遊技場で遊技している仲良しフレンドとの間に限定して利用可能としたが、これらの特定機能の全部または一部を、同じ遊技場だけでなく他の遊技場を含めた全国の遊技場で遊技している仲良しフレンドとの間で、あるいは自宅に居る仲良しフレンドとの間で利用できるようにしてもよい。
また、本実施の形態においては、上記の特定機能の利用を会員が遊技している遊技機に対応するＣＵ３から行なう場合について説明したが、上記の特定機能の全部または一部を遊技場で遊技している（ログインしている）あるいは自宅に居る会員のＰＣ１５Ａまたは携帯電話１６Ａなどの情報機器から行なえるようにしてもよい。
＜スロットマシン＞
次に、遊技機の他の例としてスロットマシンを説明する。図１０２は、スロットマシンの前面扉を開放した状態を示す斜視図である。これまでの説明において、パチンコ機を“Ｐ台”と略称したこととの関係上、スロットマシンを以下では、“Ｓ台”とも略称する。
次に、遊技機の他の例としてスロットマシンを説明する。図１０２は、スロットマシンの前面扉を開放した状態を示す斜視図である。これまでの説明において、パチンコ機を“Ｐ台”と略称したこととの関係上、スロットマシンを以下では、“Ｓ台”とも略称する。
遊技玉および持玉を用いた上記の遊技用システムは、Ｓ台にも同様に適用される。ただし、Ｓ台では、玉を使わずにゲームが行なわれる関係上、以下では、遊技玉を遊技点、持玉を持点と称する。
図１０２を参照して、スロットマシン（Ｓ台）２Ｓは、本体枠２ａＳに対して前面扉２ｂＳがその左側縁を揺動中心として開閉可能に設けられている。図１０２では図示を省略しているが、Ｓ台２Ｓの図面左隣には、Ｐ台と同様にＣＵが接続される。
Ｓ台２Ｓでは、遊技点を用いることによって賭数が設定され、入賞に応じてその遊技点が加算更新される。このため、Ｓ台２Ｓにおいて遊技をする際には、メダルの投入操作は不要である。ゆえに、Ｓ台２Ｓには、メダル投入口およびメダル払出口が設けられていない。
Ｓ台２Ｓの筐体内部には、外周に複数種の図柄が配列されたリール２Ｌ、２Ｃ、２Ｒ（以下、左リール、中リール、右リールともいう）が水平方向に並設されており、これらリール２Ｌ、２Ｃ、２Ｒに配列された図柄のうち連続する３つの図柄が前面扉２ｂＳに設けられた透視窓から見えるように配置されている。リール２Ｌ、２Ｃ、２Ｒの外周部には、複数種類の図柄が所定の順序で描かれている。
前面扉２ｂＳの各リール２Ｌ、２Ｃ、２Ｒを取り囲む部分には、タッチパネル式の表示器５１０が設けられている。この表示器５１０は、Ｐ台の表示器５４に相当する表示器であり、表示器５４と同種の各種情報（遊技点や持点など）が表示される他、ゲームにおいて設定された賭数などが表示される。表示器５１０は、図２の表示器５４と同様にＣＵの表示制御部３５０に接続されており、ＣＵ側で表示制御される。なお、この表示器５１０は、各リール２Ｌ、２Ｃ、２Ｒを取り囲む部分に設けるのではなく、Ｐ台と同様にさらに下方のパネル部分（図１０２に示されるスタートスイッチ７Ｓよりも下方の位置の、旧来のＳ台のメダル払出口が設けられたパネル部分）に設けてもよい。
また、前面扉２ｂＳには、メダル１枚分に相当する「遊技点＝１」を用いて賭数を設定する際に操作される１枚ＢＥＴスイッチ５Ｓ、遊技状態に応じて定められた最大の賭数（たとえば、ＢＢ発生前の通常遊技状態およびリプレイの当選確率が高確率となるＲＴ（Replay Time）においては「遊技点＝３」、ボーナスにおいては「遊技点＝２」）を設定する際に操作されるＭＡＸＢＥＴスイッチ６Ｓ、ゲームを開始する際に操作されるスタートスイッチ７Ｓ、リール２Ｌ、２Ｃ、２Ｒの回転を各々停止する際に操作されるストップスイッチ８Ｌ、８Ｃ、８Ｒがそれぞれ設けられている。
Ｓ台２Ｓにおいてゲームを行なう場合には、まず、Ｐ台と同様に、隣接されたＣＵを利用して遊技点を確保の上で、その遊技点を使用して賭数を設定する。遊技点は、ＣＵに挿入されたプリペイドカードの残額、持点、あるいは遊技場に預け入れている貯メダル（Ｐ台の貯玉に相当）を引落とすことによって得られる。遊技点を使用するには１枚ＢＥＴスイッチ５Ｓ、またはＭＡＸＢＥＴスイッチ６Ｓを操作すればよい。本実施の形態では、たとえば、賭数を１設定することによって遊技点が１減点され、表示器５１０の遊技点の表示も減算更新される。賭数が設定されると、賭数および遊技状態に応じて定められた入賞ラインが有効となり、スタートスイッチ７Ｓの操作が有効な状態、すなわち、ゲームが開始可能な状態となる。
ゲームが開始可能な状態でスタートスイッチ７Ｓを操作すると、各リール２Ｌ、２Ｃ、２Ｒが回転し、各リール２Ｌ、２Ｃ、２Ｒの図柄が連続的に変動する。この状態でいずれかのストップスイッチ８Ｌ、８Ｃ、８Ｒを操作すると、対応するリール２Ｌ、２Ｃ、２Ｒの回転が停止し、透視窓に表示結果が導出表示される。
そして全てのリール２Ｌ、２Ｃ、２Ｒが停止されることで１ゲームが終了し、有効化された入賞ライン上に予め定められた図柄の組合せ（以下、役とも呼ぶ）が各リール２Ｌ、２Ｃ、２Ｒの表示結果として停止した場合には入賞が発生し、その入賞に応じて定められた遊技点が遊技者に対して付与され、表示器５１０の遊技点の表示も加算更新される。
Ｓ台の場合にも、Ｐ台と同様に遊技点を計数することが可能である。図１に示すとおり、Ｓ台２Ｓには、遊技点を計数して持点に変換するための計数ボタン２８Ｓが設けられている。なお、玉貸ボタン、カード返却ボタン、および再プレイボタンは、ＣＵのディスプレイに表示される。遊技者は任意のタイミング、あるいは、Ｐ台と同様に計数操作を促す表示が表示器５１０に行なわれたことに基づいて、計数操作を実行する。すると、遊技点が計数されて遊技点が減少する一方で持点が増加する様子が表示器５１０に表示される。なお、玉貸ボタンは、ＣＵ側ではなくＰ台側およびＳ台側に設けてもよい。その場合に、玉貸ボタンの操作信号がＣＵ３へ直接入力されるようにしてもよく、あるいは、Ｐ台２やＳ台（スロットマシン）２Ｓを経由して状態情報応答としてＣＵ３へ送信されるようにしてもよい。
入賞となる役の種類は、遊技状態に応じて定められているが、大きく分けて、ビッグボーナス（ＢＢ）、レギュラーボーナス（ＲＢ）への移行を伴う特別役と、メダルの払い出しを伴う小役と、賭数の設定を必要とせずに次のゲームを開始可能となる再遊技役（リプレイ）とがある。
複数種類の入賞役のうちのいずれを当選させるか、あるいはいずれの入賞役も当選しない外れとするかは、たとえば、スタート操作が検出されたときに、Ｓ台２Ｓを制御する主制御部（Ｓ台の主制御部１６１に相当）によって決定される。この決定は、たとえば、所定の乱数発生器から発生され、あるいはソフトウエア上で生成される乱数を抽選することによって決定される。
その後、主制御部は、遊技者によるリールの停止操作を待ち、停止操作時を基準にして、所定のコマ数範囲に当選役に対応する図柄があればそれを引き込み、なければ、他の図柄を引込む制御を行ない、３つの図柄を停止させ、入賞の有無を判定する。主制御基部は、入賞と判定した場合には、入賞の種類に応じた遊技点を遊技者に付与する（遊技点を加算する）。
すなわち、Ｓ台により、遊技用価値を用いて１ゲームに対して所定数の賭数を設定することによりゲームが開始可能となるとともに、各々が識別可能な複数種類の識別情報を変動表示可能な可変表示装置に表示結果が導出されることにより１ゲームが終了し、該可変表示装置に導出された表示結果に応じて入賞が発生可能とされたスロットマシンであって、前記可変表示装置に表示結果が導出される前に、複数種類の入賞について発生を許容するか否かを決定する事前決定手段と、前記事前決定手段の決定結果に応じて、前記可変表示装置に表示結果を導出させる制御を行なう導出制御手段と、前記入賞が発生した場合に遊技価値を付与する付与手段とを含むスロットマシンが構成されている。
図１０３は、カードユニットおよびスロットマシンのそれぞれにおいて記憶している各種データおよびその送受信態様を説明するための説明図である。この図１０３は、Ｐ台の構成として説明した図４の用語をＳ台用に置き換えたものであり、その態様は、図４を用いて説明したものと同様であるので、ここでは、これ以上の説明を省略する。
＜変形例や特徴点など＞
次に、以上、説明した本実施の形態の変形例や特徴点などを列挙する。
次に、以上、説明した本実施の形態の変形例や特徴点などを列挙する。
（１） 本実施の形態では、加算通番と計数通番とはそれぞれ別のデータとして電文フォーマットに規定されているが、これらを要求通番として共通化してもよい。特に、遊技玉の加算と遊技玉の計数とは逆の処理であるため、両処理が同時に発生することは考えにくく、その観点からも両通番を共通化して電文データ量を削減することは可能である。
また、本実施の形態では、要求通番は、予め定めた上限値に達するまで、新たな要求が発生した場合には、先に更新済みの値を元にして通番更新が行なわれる。しかながら、このような制御に代えて、１つの要求に対応する処理がすべて終了した場合には、要求通番を予め定めた初期値に初期化するようにしてもよい。たとえば、図１５の例の場合には、計数完了を示す最後の状態情報応答に含める計数通番をｍ＋６ではなく、予め定めた初期値にすることが考えられる。
また、加算通番や計数通番といった要求通番、さらには通常の通番は、１ずつカウントアップされるのではなく、Ｐ台２およびＣＵ３の双方が記憶している所定の規則に従って更新（加算更新、減算更新、その他の演算式による更新）するものであってもよい。この場合、通番は、１，２，３といった“連続する番号”ではなく、Ａ、Ｂ、Ｃなどといった概念で更新されるデータとなる。
（２） 上記遊技用システムに遊技機の一例となるスロットマシン（Ｓ台）を適用した場合、たとえば、リールおよびリールに付属する各種センサ部分とリールを制御する主制御基板とがＰ台の遊技盤に対応し、それ以外の構成がＰ台の遊技枠に対応する。ただし、Ｓ台には、図２に示した遊技枠の各種検出スイッチ４１ａ、７０１、３３、発射制御基板３１、および発射モータ１８は、不要である。
旧来のＳ台にはクレジット機能が設けられており、これが有効になっているときには、賭数を設定するとクレジットが減算され、入賞が発生するとクレジットが加算される。ただし、クレジットには上限が定められており、クレジット数が上限値に達している状態で入賞が発生すると、ホッパーからメダルが払い出される。
一方、本実施の形態に係るＳ台では、賭数を設定すると遊技点が減算され、入賞が発生すると遊技点が加算される。また、遊技点が所定数に達すると、計数操作を促す表示がなされ、計数操作をすることによって、遊技点が持点に変換される。このため、旧来のＳ台のようにクレジットが上限に達してメダルを払い出す必要がない。その結果、本実施の形態に係るＳ台にはホッパーを設ける必要がない。
その結果、遊技場は、大量のメダルを確保する必要がなく、経済的負担が軽減される。また、遊技場は、メダルの補充・回収といった業務やメダル詰まりなどに対応するためのメンテナンス業務からも解放される。遊技客は、クレジットが満タンになった後で賭け操作毎にメダルを投入する煩わしさから解放され、遊技に集中しやすくなる。
他方、Ｓ台がメダルレスになった場合には、大量のメダルを獲得した遊技者が席の脇にメダルが入った箱を積み上げて自身の腕を誇示するような行為をすることができなくなるという不都合が生じる。しかしながら、本実施の形態では、上記のとおりドル箱表示する機能が設けられているため、このような不都合が生じることも防止できる。なお、Ｓ台の場合のドル箱表示は、多数の玉に代えて多数のメダルが積載されているようにするのが望ましい。
遊技機としてＳ台を適用した場合、「持点」および「遊技点」の２種類と、「クレジット」および「クレジット超過点」の２種類のデータとを用いて、以下のように各データが変換されるような遊技用システムを構成することも可能である。なお、Ｓ台の表示器５１０あるいは表示器２９Ｓには、これら４種類のデータを表示する。
まず、プリペイドカードの残額、貯メダル、または持点からの変換操作（貸出操作、貯メダル払出し操作、持点払出し操作）が検出された場合には、夫々が引き落とされて、遊技点に変換される。
遊技点は、旧来のスロットマシンにおけるメダルに対応するデータである。このため、たとえば、表示器５１０あるいは表示器２９Ｓには遊技点の点数を表示するとともに、遊技点相当の数のメダル画像を表示することが望ましい。たとえば、このメダル画像に遊技者が触れてスロットマシンに投入するような擬似投入メダル操作（たとえば、メダルを押し込むような操作）が検出されると、メダル画像が消え、遊技点が減算されて、代わりに賭数が１つ設定される。このような擬似メダル投入操作が３度行なわれることによって、賭数が最大値の３に設定される。
その後、さらに擬似メダル投入操作が検出されると、その検出に応じて、クレジットが加算される。クレジットには上限値（たとえば、５０）が設定されており、クレジットが上限値を超えたときには、クレジット超過点が加算される。
賭数設定は、遊技点を用いて上記のように行なうことが可能である他、クレジットを用いて行なうことも可能である。すなわち、１枚ＢＥＴスイッチ５Ｓの操作があれば、賭数設定値が１加算され、クレジットが１減算される。また、ＭＡＸＢＥＴスイッチ６Ｓの操作があれば、賭数が３に設定され、クレジットが賭数設定に応じて減算される。
ゲームの結果、入賞が発生すると、入賞に応じた数の得点がクレジットに加算される。なお、クレジットの上限値をオーバーする入賞が発生したときには、そのオーバー分の点数がクレジット超過点として記憶される。このクレジット超過点は、旧来のスロットマシンにおける、クレジットの上限を超えて入賞が発生したときに払い出されるメダルに相当する。このため、たとえば、表示器５１０あるいは表示器２９Ｓにはクレジット超過点を表示するとともに、クレジット超過点相当の数のメダル画像を表示することが望ましい。また、このメダル画像は、遊技点に対応するメダル画像と区別できるように色を変えるなどすることが望ましい。
また、クレジット超過点は、遊技者の操作によって遊技点に変換されるようにすることが望ましい。たとえば、クレジット超過点に対応するメダル画像に遊技者が触れて遊技点に変換するような擬似メダル変換操作（たとえば、メダルを押し込むような操作）が検出されると、メダル画像が消え、クレジット超過点が減算されて遊技点が加算されるものとする。
あるいは、クレジットが上限値未満になれば、自動的にクレジット超過点がクレジットに変換されるようにしてもよい。
遊技者が計数操作を実行すると、遊技点、クレジット、およびクレジット超過点の各々が計数されて持点に変換される。その結果、遊技者の持点は、「カード持玉数＋遊技点＋クレジット＋クレジット超過点」と掲載される。なお、“カード持玉数”とは、遊技点に変換していない変換前の持点（現時点で遊技者が所有している持玉数）である。
以上の説明において、持点、遊技点、クレジット、およびクレジット超過点の４種類のデータは、ＣＵとＳ台とでデータのやりとりをすることによって双方で記憶してもよく、あるいは、持点はＣＵ側のみで、それ以外はＳ台側のみで記憶してもよい。また、クレジット超過点をドル箱表示の対象としてもよい。
また、以上の説明では、クレジット超過点を用いる例を説明したが、クレジット超過点を用いなくてもよい。この場合、クレジットの上限を超えるような場合には、遊技点に加算するようにしてもよい。
（３） 本実施の形態では、カード度数を消費することによって、遊技点が加算される。あるいは、貯玉（貯メダル）を消費することによって、遊技点が加算される。つまり、カード度数あるいは貯玉から遊技点に変換される。一方、カード度数および貯玉から持点（計数玉、計数メダル）には変換されない。しかしながら、カード度数および貯玉から一旦、持点に変換されるようにしてもよい。
（４） 本実施の形態では、計数操作によって、遊技点が持点に変換される。この場合の変換率は１：１である。しかしながら、変換される場合の変換率を１：１以外としてもよい。たとえば、遊技点１００点を変換した場合、そのうちの３点を差し引いた９７点が持点に変換されるようにしてもよい。または、持点に対して１０割未満の所定割合を乗じて得られた数の遊技玉に変換されるようにしてもよい。
（５） 持点を特定可能に記録するための記録媒体は、スマートフォンなどの携帯端末を利用したものとしてもよい。この場合、ＣＵに携帯端末と通信するための通信部を設けて、携帯端末を通信部にかざすことによって、携帯端末内に記憶されているＩＤをＣＵが認識し、後は本実施の形態に記載したような手順で遊技を可能とする。一方、遊技終了時には、再度、携帯端末を通信部にかざすことによって、遊技終了時の持点がＩＤを通じて遊技者の持点に加算されるようにする。
（６） 遊技点を計数するための操作手段は、ＣＵ側に設けてもよい。その場合の操作手段は、タッチパネルに表示されるものとしてもよく、物理的なスイッチで構成してもよい。
（７） 本実施の形態では、カード返却操作をしたときに、未計数の遊技点が残っているときには、Ｐ台あるいはＣＵ側の表示器にて計数を促すメッセージを表示する。しかし、このような構成に代えて、カード返却操作をしたときに、未計数の遊技点が残っているときには、自動的に計数表示を開始するとともに、Ｐ台あるいはＣＵ側の表示器にて、未計数の遊技点が残っているために自動計数を開始したこと、あるいは、さらにそれに加えて、自動計数が完了した後にカードが返却されることを報知してもよい。
あるいは、カード返却操作をしたときに、未計数の遊技点が残っているときには、遊技者が一時的に離席する可能性があると判断し、表示器（ＣＵ側あるいはＰ台側）に、一時的な離席であるか否かを確認するメッセージを表示してもよい。さらに、表示器をタッチパネルで構成し、そのメッセージに対して遊技者が応答入力できるようにしてもよい。さらに、その応答入力が遊技終了であれば、計数操作を促すメッセージを表示する。一方、応答入力が一時離席であれば、ＣＵ側あるいはＰ台側または双方でカードのＩＤを記憶した状態のままで一旦、カードを排出するようにしてもよい。その後、同じＩＤのカードが挿入されたときには、元の状態から遊技を再開させる。
（８） 大当り中は、遊技玉数が満タンと判断するための判断基準値を上げてもよい。つまり、大当り中とそうでないときとで、満タン判断の判断基準値を異ならせてもよい。これによって、大当り中に遊技玉数が急激に多くなり、すぐに満タン判断がなされて発射停止してしまうことを防止できる。
（９） 大当りが発生したときの遊技玉数を記憶しておき、大当り中は、満タンの判断基準値を超えた場合であっても、大当りが発生してから増加した遊技玉数が許容値（たとえば、１０００玉）以内であれば、満タン判定しないものとしてもよい。
（１０） 遊技玉を計数するための計数操作手段としては、２回以上の所定回数操作したときに、計数機能を発揮するようなものを採用してもよい。これによって、誤操作を防止できる。また、この場合、１回操作では、計数機能とは異なる他の機能を発揮させるようにしてもよい。たとえば、１回操作をしてから所定時間（たとえば、１秒以内）、操作が無い場合には、店員を呼び出すためのランプを点灯させるような機能を発揮させ、１操作から１秒以内に２回目の操作が検出されたときには、計数機能を発揮させることも考えられる。
（１１） 「所定の記録媒体処理操作を検出したときに、前記遊技点を前記持点として、所定の処理が可能となるように処理する記録媒体処理手段」の「所定の処理」は、たとえば、ＣＵから排出されたカードを他の遊技機に接続された別のＣＵに挿入して使用する場合のＣＵの処理（カードで特定可能に記録された持玉を引き落として遊技玉に変換する処理や持玉共有処理、あるいはワゴンサービス処理等）を意味する。あるいはまた、「所定の処理」とは、景品交換用の景品交換機でカードを受付けて当該カードで特定される持点を消費して景品交換を可能とする処理であってもよい。
また、上述した「持点として所定の処理が可能となるように処理するための記録媒体処理操作」とは、たとえば、カードの返却操作である。また、「所定の処理」とは、カードの返却操作を検出したときに、ＣＵに挿入されているカードに持点を特定可能に記録し、当該カードを返却する処理である。ここで、「特定可能に記録」とは、カードに直接、持点を記録することの他、カードには持点を記録せずにカードのＩＤと持点とをＣＵに接続されたサーバに送信し、サーバ内でＩＤと持点とを対応付けて記憶するような方式を含む。
（１２） 玉の発射中に計数操作をすると、そのときの遊技玉数が基準値以下の場合には、計数操作が無効とされるようにしてもよい。また、玉の発射中に計数操作が検出されたときの遊技玉数が基準値を超える場合であっても、１回の計数操作で計数される玉数が所定数に定められている場合において、計数操作が検出されたときの遊技玉数からその所定数を差し引いた値が前記基準値に満たない場合には、計数操作を無効とするようにしてもよい。
また、遊技中であるか否かを玉の発射動作が検出されているか否かで判断してもよく、遊技中球数（遊技領域２７内で浮遊している浮遊玉）が０になっているか（遊技中でない）否か（遊技中）で、判断してもよい。さらに、可変表示装置が変動中であるか否か、大当り中であるか否か、アタッカーが開いているか否か、などで遊技中であるか否かを判定することも考えられる。
さらに、遊技機としてＳ台を適用して遊技中の計数操作を無効とする場合の「遊技中」とは、たとえば、リール２Ｌ、２Ｃ、２Ｒが回転開始してから停止するまでの期間である。あるいは、スタート操作が検出されてからリール２Ｌ、２Ｃ、２Ｒが停止するまでの期間である。
（１３） 図１５を参照して、Ｐ台は、計数された計数玉（持玉）を一時記憶する計数玉数カウンタを備えているものの、計数玉の累積値を記憶するカウンタを備えていない。しかしながら、Ｐ台側に、計数玉の累積値を記憶する計数玉累積記憶カウンタを備えてもよい。また、ＣＵ側には、カード持玉（計数玉）を記憶する領域が備えられているが、この領域には、挿入されたカード自体に持玉が記録されていた場合には、そのカード持玉も含めて現在の遊技者の持玉数が記憶される。このため、この領域のみでは、今回の遊技で遊技者が計数した計数玉の数を特定できない。そこで、今回の遊技で遊技者が計数した計数玉の数を記憶する領域をＣＵ側にさらに設けてもよい。ＣＵは、この場合、遊技が開始してからＰ台から送られてくる計数玉数の情報に基づいて当該領域に持玉を加算し、持玉が遊技玉に変換されると、当該領域から持玉を減算する。
（１４） 図１６の計数操作を促す表示としては、文章にて「遊技玉が残っているので計数して下さい」という表示であってもよく、あるいは画面上に計数ボタン２８を表示させて点滅するような表示であってもよい。また、カード返却準備状態ＯＮを受けたＰ台２は、遊技玉数表示器２９の遊技玉を点滅表示させるなどしてもよく、あるいは、遊技玉数表示器２９を画像表示装置で構成した場合には、上記実施の形態として説明したメッセージを遊技玉数表示器２９に表示して計数操作を促すようにしてもよい。
（１５） 計数ボタンを押し続ける時間に応じて、１回の操作で持点変換する遊技点数が異なるようにするために、たとえば、長押し（たとえば、１秒以上連続操作）のときには遊技点のすべてが計数される一方、短押し（たとえば、１秒未満の連続操作）のときには、２００玉だけが計数されるようにしてもよい。ただし、この場合には、遊技玉の残数が少ない場合、たとえば、２００玉未満の場合には、計数ボタンの操作ですべての遊技玉が計数されるようにするのが望ましい。
（１６） 遊技点の残数に応じて、計数ボタンの１回の短押下操作で計数される点数が異なるようにする場合、たとえば、次のようにすることが考えられる。たとえば、遊技点が２００点未満のときには、計数ボタンの１回の短押下操作ですべての遊技点が計数されるようにする。遊技点が２００以上１０００未満のときには、１回の短押下操作で２００点が計数されるようにする。遊技点が１０００以上５０００未満のときには、１回の短押下操作で１０００点が計数されるようにする。遊技点が５０００以上１００００未満のときには、１回の短押下操作で２０００点が計数されるようにする。遊技点が１００００以上のときには、１回の短押下操作で２５００点が計数されるようにする。なお、以上の数値は具体例であって、適宜、設定できる。
（１７） 遊技玉（遊技点）を計数して持点変換する際には、計数表示のみならず、計数音をスピーカから出力する制御をしてもよい。また、遊技点の計数の際には、玉が１つずつ、玉貯留皿から計数器へと落下していくような画像表示を行なうことが考えられる。
（１８） 計数操作に基づいて遊技点を持点に変換する変換表示（遊技玉を計数していき、持玉が増えていく様を示す表示）を行なうタイミングと、データ上で遊技点を減算し、持点を加算する演算を行なうタイミングとは様々なものとすることができる。変換表示が終わってから、前記演算を実行してもよい。また、そのために、変換表示が終わった後に遊技機からＣＵに対して計数データが送信されるようにしてもよい。なお、このような変形例は、持点を遊技点に変換する場合についても同様に適用可能である。
（１９） 本実施の形態では、ＣＵと遊技機との間の通信において、ＣＵを一次局、遊技機を二次局とするコマンド−レスポンス方式が採用されているが、一次局と二次局との関係を逆にしてもよい。あるいは、このような主従の関係がある通信方式を採用するのではなく、通信すべき要求が生じたときに双方が相手にデータを送信するような方式を採用してもよい。
（２０） 本実施の形態では、遊技機側およびＣＵ側の双方で遊技玉（遊技点）を記憶するようにしているが、遊技玉（遊技点）は遊技機側のみで記憶し、ＣＵ側では記憶しないようにしてもよい。一方、カード持玉（持点）は、ＣＵ側でのみ記憶しているが、遊技機側でも記憶するようにしてもよい。特に、遊技玉（遊技点）は遊技機側のみで記憶し、一方、カード持玉（持点）は、ＣＵ側でのみ記憶するようにして、データの記憶管理の役割分担を明確にしてもよい。
（２１） 表示器５４で行なう計数表示や各種の報知は、同様に表示器３１２で行なうようにしてもよい。
（２２） ＣＵ３において、Ｐ台側から送信されてきた加算玉数カウンタの値（加算玉数）および減算玉数カウンタの値（減算玉数）に基づいて、記憶している遊技玉数を更新し、Ｐ台側から送信されてきた計数玉数カウンタの値に基づいて記憶している遊技玉数を減算したときに、遊技玉数の値がマイナスになる場合には、エラー（異常）判定し、エラー処理を行なうようにしてもよい。エラー処理の具体例として、異常報知ランプ等によりエラー報知が行なわれたり、あるいは、ホール用管理コンピュータやホールサーバ８０１にエラーが発生した旨のエラー通知信号が送信されたりする（この場合、ホール用管理コンピュータやホールサーバ８０１によるエラー報知が行なわれるようにしてもよい）。
（２３） 貸出操作あるいは持点（持玉）から遊技点（遊技玉）への変換操作（貸出操作）が検出された場合、遊技点は、１点ずつカウントアップするようにしてもよいが、遊技者の待ち時間を短くするために、複数点（たとえば、１００円相当の２５点）ずつカウントアップするように表示してもよい。また、逆に、遊技点の計数操作が実行されたときにも、複数点ずつ持点がカウントアップするように表示してもよい。さらに、遊技点あるいは持点をカウントアップ表示するときの単位数を複数種類の中から設定できるようにしてもよい。その設定の際には、Ｐ台あるいはＳ台の表示器のタッチパネルを利用することが考えられる。
（２４） 打球操作ハンドルにタッチセンサを設けて、遊技者が打球操作ハンドルを握っていることがタッチセンサによって検出されている間は、計数操作を無効にしてもよい。計数操作を無効とは、計数操作を検出するが、その検出出力に基づいた計数動作を実行しないこと、あるいは、計数操作の検出自体をしないことの双方を意味する。または、遊技者が打球操作ハンドルに触れているだけでは計数操作を無効にせず、打球操作ハンドルを玉発射の駆動パルスが出力される程度にまで回している場合に、計数操作を無効にしてもよい。
これらの場合には、計数操作が検出されると、「ハンドルを放してください」というメッセージを遊技機あるいはＣＵの表示器に表示するようにしてもよい。あるいは、計数操作ボタンをタッチパネルの画面上のアイコンで表示するようにしたときには、計数操作ボタンをグレーアウトして、操作不能であることを遊技者に通知するようにしてもよい。
（２５） 玉貸ボタン、カード返却ボタン、再プレイボタン、および計数ボタンのうちの少なくとも１つ、あるいはすべては、遊技機側に設けてもよく、あるいはＣＵ側に設けてもよい。また、そのボタンは、タッチパネル式の表示器として説明した遊技機側あるいはＣＵ側の表示器に表示することが考えられる。
（２６） 本実施の形態に係る遊技用システムは、持点を使用した所定の持点使用処理を実行するための持点使用操作手段を含む。ここで、所定の持点使用処理とは、ワゴンサービスを実行するための処理や、あるいは、持点（持玉）を分割して共有する処理（持点を他人に分割譲渡する処理）を含む概念である。また、持点使用操作手段は、たとえば、タッチパネルである。あるいは、持点使用操作手段は、ＣＵ又は遊技機に対して持点使用処理の実行を指令するために遊技店の係員に与えられるリモコンであってもよい。
（２７） 図６〜図１６で示したシーケンス制御は、ＣＵ３、Ｐ台２、Ｓ台２Ｓ等の遊技機器単体内の制御装置間の送受信シーケンスに限定されるものではなく、たとえば、ＣＵ３、Ｐ台２、ジェットカウンタ、ＰＯＳ端末等の複数の遊技機器間の送受信シーケンスに適用してもよい。
たとえば、遊技玉の加算要求に関する処理を、ＣＵ制御部３２３とセキュリティチップ（ＳＣ）３２５ｂとの間に適用した場合には、遊技玉の加算要求電文をＣＵ制御部３２３が送信し、これに対する承諾または拒否電文をＳＣ３２５ｂがＰ台２側の応答に基づいて通信制御ＩＣ３２５ａ経由で返信する。
遊技玉の加算要求に関する処理を、セキュリティチップ（ＳＣ）３２５ｂと通信制御ＩＣ３２５ａとの間に適用した場合には、遊技玉の加算要求電文をＣＵ制御部３２３経由でセキュリティチップ（ＳＣ）３２５ｂが送信し、これに対する承諾または拒否電文を通信制御ＩＣ３２５ａがＰ台２側の応答に基づいて返信する。
計数要求に関する処理を、ＣＵ制御部３２３とセキュリティチップ（ＳＣ）３２５ｂとの間に適用した場合には、計数要求電文をＳＣ３２５ｂがＰ台２側の要求に基づいて通信制御ＩＣ３２５ａ経由でＣＵ制御部３２３に送信し、これに対する承諾または拒否電文をＣＵ制御部３２３が返信する。
計数要求に関する処理を、セキュリティチップ（ＳＣ）３２５ｂと通信制御ＩＣ３２５ａとの間に適用した場合には、計数要求電文を通信制御ＩＣ３２５ａがＰ台２側の要求に基づいて送信し、これに対する承諾または拒否電文をセキュリティチップ（ＳＣ）３２５ｂがＣＵ制御部３２３の指示に基づいて返信する。
（２８） 前述の実施の形態では、カードＩＤにより遊技者の同一性の判別を行なっているが、それに代えてまたはそれに加えて、遊技者の指紋や網膜等のバイオマスにより遊技者の同一性の判別を行なってもよい。
（２９） 前述の実施の形態では、カードＩＤと挿入時刻とが一致することを条件に遊技機から送信された得点をＣＵが現時点での得点として記憶しているが、遊技機とＣＵ３との通信が途絶えてから所定時間（たとえば２０分）が経過するまでに通信が開始されたことを更なる条件として、遊技機から送信された得点をＣＵが現時点での得点として記憶するように制御してもよい。具体的には、遊技機とＣＵ３との通信が途絶えてから所定時間（たとえば２０分）を計時するタイマをＣＵ制御部３２３に設け、遊技機とＣＵ３との通信の開始時（復旧時）に該タイマが未だ計時中（タイムアップしていない状態）であるか否か判定し、計時中との判定結果であることを更なる条件として、遊技機から送信された得点をＣＵが現時点での得点として記憶するように制御する。
また、挿入時刻の代わりに、ＣＵ３とＰ台２との間で用いられた最終通番等の一致を条件に遊技機から送信された得点をＣＵが現時点での得点として記憶するようにしてもよい。
（３０） 前述の実施の形態では、入賞の発生により直接遊技玉数や遊技点を加算するものを示したが、その代わりに、入賞の発生により持点を加算し、その加算された持点を引落して遊技玉数や遊技点を加算するように制御してもよい。
（３１） 前述の実施の形態では、遊技者所有の有価価値（プリペイド残額、持玉、貯玉）の範囲内で価値を引落して該引落し相当分の遊技点を加算するにおいて、引落した価値と同じ価値の遊技点を加算するものを示したが、その代わりに、たとえば、実際に引落した価値に対し消費税相当額分少ない遊技点を加算するように制御してもよい。
（３２） 本実施の形態では、遊技場から離れた鍵管理センタに鍵管理サーバを設置した。しかしながら、鍵管理サーバは遊技場内に設置してもよい。これにより、遊技場外に鍵管理サーバを設置する場合と比較すると、ＣＵと鍵管理サーバとの通信を高速化し易く、また、通信障害の発生率を低減できる。
（３３） ＣＵ制御部３２３は、ホールサーバ８０１を介して鍵管理サーバ８００から基板セキュリティ情報（基板認証鍵や更新情報を含む）を受信する。しかしながら、これに代えて、鍵管理サーバ８００とＣＵ制御部３２３との間にホールサーバ８０１を介することなく、鍵管理サーバ８００からＣＵ制御部３２３へ基板セキュリティ情報が送信される構成とてもよい。たとえば、鍵管理サーバ８００とＣＵとを直接、回線接続することや、鍵管理サーバ８００と各ＣＵとの間にホールサーバ８０１と異なる中継用の通信装置を設けることが考えられる。
（３４） 前述の実施の形態では、遊技の中断操作（簡易離席操作または食事休憩操作）に基づいて自動的に計数処理された計数玉数を一旦、持玉に加算してカードに書込み排出することで、中断処理を行ない、その後、遊技を中断した遊技者が戻ってきて、そのカードを再度元のＣＵ３に挿入し、持玉を遊技玉に変換する操作により、１２５玉ずつ遊技玉に変換されて遊技が可能になるものを示した。しかし、それに代えて、中断操作時に自動計数された計数玉を遊技玉や持玉とは別の預かり玉（Ｃ−ＩＤと挿入時刻も記憶）としてＣＵ３が記憶し、持玉加算せず、持玉を記録させることなくカードを排出することで中断処理を行ない。その排出カードが再挿入されると、預かり玉がすべて一括で自動的にＰ台の遊技玉に変換されて遊技可能となるように制御してもよい。あるいは、この場合の預かり玉は、中断操作に基づいてＰ台からＣＵへと送信され、ＣＵ側またはホールサーバ側で記憶しておき、カードが再度挿入されたときにＣＵまたはホールサーバから自動的にＰ台側へ預かり玉の情報が送信されて遊技玉としてＰ台側に記憶されるものとしてもよい。また、この場合に預かり玉の情報を送信する際には、遊技玉の加算指令としてＣＵからＰ台に送信してやればよい。
さらに、上記実施の形態では、中断操作に基づいて自動的に計数処理された計数玉数を一旦、持玉に加算してカードに書込んで排出したとき、そのカードに中断中フラグを記録しておくことによって、そのカードでは景品交換できないようにした。このように景品交換を禁止する手法としては、カードの中断中フラグを利用する以外の次のような手法を採用することも考えられる。
まず、中断操作が行なわれたときに、ＣＵからホールサーバにその情報（カードＩＤを含む）を送信し、ホールサーバ側で中断中の遊技者のカードを中断カードとして記憶する。景品交換時にはＰＯＳなどからホールサーバに問合せをし、景品交換に用いられているカードが中断カードであるか否かをホールサーバが判定する。あるいは、全中断カード情報を予めホールサーバからＰＯＳ側に送信しておいてもよい。その上で、景品交換に用いられているカードが中断カードであれば、当該カードを用いた景品交換を禁止する。
（３５） 上記実施の形態において、遊技機は、「全遊技点に対する変換処理が終了したことを条件に（遊技点＝０）、前記遊技点を前記持点として遊技用装置（ＣＵ）が所定の処理（景品交換機でカードを受付けて当該カードで特定される持点を消費して景品交換を可能とする処理、ＣＵから排出されたカードを他の遊技機に接続された別のＣＵに挿入して使用する場合のＣＵの処理）をするための記録媒体処理操作（カード返却操作（カード返却ボタン３２２の操作））を有効化する有効化手段」を含む。
（３６） 本実施の形態では、遊技情報の一例として、持玉、遊技玉、カードの残額、貯玉、その他、玉数情報や遊技台情報を挙げて説明した。しかしながら、遊技情報は、遊技機での遊技に関連したその他の情報をも含む。たとえば、遊技者が選択あるいはカスタマイズした遊技者の好みのキャラクタを可変表示装置２７８や表示器５４などの可変表示手段（可変表示装置）に表示可能にした場合には、そのキャラクタを特定可能な情報も遊技情報に含まれる。このような遊技者の嗜好に合うキャラクタを含む画面デザインの情報は、たとえば、遊技者のカードＩＤと対応付けて遊技の終了時にサーバに送信して記憶させ、新たに遊技を開始する際にはサーバからＣＵあるいはＰ台へダウンロードするようにしてもよい。
（３７） 遊技玉数表示器２９では、玉の発射または計数動作に連動して玉数が１つずつ減っていく表示がなされる。また、遊技玉数表示器２９では、玉貸操作等に応じて玉数が１つずつあるいは所定単位数ずつ増加する表示がなされる。遊技玉数表示器２９を液晶表示装置などの画像表示器で構成した場合には、単に遊技玉数をデジタル表示するのではなく、遊技玉数の変化が弾球によるものであるのか、計数によるものであるのか、入賞の発生によるものであるのか、貯玉の引き落としによるものであるのか、貸出操作によるものであるか、など、その種類に応じた画像を遊技玉数の表示更新と併せて表示するようにしてもよい。
また、計数操作が行われた場合、遊技玉数表示器２９では、計数動作に連動した計数表示が行われるが、遊技玉数表示器２９を液晶表示装置などの画像表示器で構成した場合には、表示器５４と同様に、遊技玉が計数されてその数が減少する一方で、持玉が増加する画像表示を行なうようにしてもよい。この場合、先の表示器５４の表示の変形例として説明したように、遊技玉数のデータが持玉数のデータに経時的に変換されていく表示（たとえば、棒グラフの表示）や、現在の遊技玉数のデータと持玉数のデータをそのままデジタル表示し、遊技玉数を減少させつつ持玉数を増加させたり、遊技玉数の一部を持玉数に移動させる表示を繰り返したりすることが考えられる。
（３８） 図１６に示したように、上記の実施の形態では、遊技玉が残っている状態で検出されたカード返却操作は、所定の待機期間で計数操作が検出されることによって、計数処理完了後に有効化されてカード返却処理に移行する。
一方、待機期間が経過しても計数操作が検出されない場合の処理としては、たとえば、先のカード返却操作を無効とすることが考えられる。この場合、ＣＵ３あるいはＰ台２側の表示器には待機期間が経過しても計数操作が検出されないため、カード返却操作が無効化された旨を表示してもよい。
あるいは、遊技玉が残っている状態で検出されたカード返却操作は、所定の待機期間で計数操作が検出されるか否かに関わらず、無効化してもよい。この場合には、カード返却操作が検出された後の計数操作に応じて全遊技玉を計数し終えた後、再度、カード返却操作を実行することによってカード返却処理を実行するものとしてもよい。あるいは、全遊技玉の計数を終えたとき、または、その前後で、カード返却操作を促す表示をＣＵ３あるいはＰ台２側の表示器で行なうようにしてもよい。
また、本実施の形態では、カード返却操作が検出されたときに遊技玉が１点でも残っていると、図１６に示した処理が実行される。しかしながら、カード返却操作が検出されたときに残っている遊技玉の数が２以上の予め定めた数であるときに、図１６に示した処理が実行されるようにしてもよい。
また、カード返却操作が検出された後の計数操作では遊技玉の計数表示速度を通常時よりも早くしてもよい。たとえば、通常の計数操作では遊技玉が１つずつ計数される表示をする一方、カード返却操作が検出された後の計数操作では、遊技玉が複数ずつまとめて計数される表示、あるいは、全遊技玉が一括して計数される表示をするようにすることが考えられる。
さらに、カード返却操作が検出された後の計数操作では全遊技玉が計数対象とされるのではなく、通常の計数操作のときよりも多い数の所定数の遊技玉が計数対象とされるものとしてもよい。たとえば、通常時には１回の計数操作で最大１００点の遊技玉が計数対象とされるが、カード返却操作が検出された後の計数操作では、それよりも多い２００点の遊技玉が計数対象とされるようにしてもよい。この場合でも、事前にカード返却操作があった場合にはカード返却操作がなかった場合に比べると、全遊技玉を計数するための計数操作回数が減り、早期に全遊技玉を計数完了させることができる。
また、遊技玉が残っている状態でカード返却操作が検出された場合には、計数操作の検出がなくても、全遊技玉の計数を開始させ、その後にカード返却処理に移行するようにしてもよい。この場合、全遊技玉の計数を開始させるときに、全遊技玉の計数を開始させる旨をＰ台２あるいはＣＵ３で表示してもよい。あるいは、全遊技玉の計数を開始させてもよいか否かを確認するメッセージを表示し、所定操作（たとえば、Ｐ台２あるいはＣＵ３のタッチパネルでの操作、再度のカード返却操作など）が検出されたことを条件として、全遊技玉の計数を開始させるようにしてもよい。
また、遊技中（玉の発射中）の場合に検出されたカード返却操作を無効にしてもよいが、カード返却操作を無効にするのではなく、Ｐ台側の方で遊技中の計数操作に基づいた計数の処理を無効にしてもよい。
さらに、上記実施の形態では、カード返却操作が検出されたときに遊技玉数が０であるか否かをＣＵ３が判定している。しかしながら、このような判定をＰ台２が行なうようにしてもよい。この場合、たとえば、カード返却操作が検出されたときに、カード返却操作有を示すデータをＣＵ３からＰ台２へ送信し、それを受けたＰ台２が自ら記憶している遊技玉数が０であるか否かを判定する。０であれば、遊技玉数が０であることまたはカード返却を許可するデータをＣＵ３へ送信する一方、０でなければ、遊技玉数が０でないことまたはカード返却の待機あるいはカード返却の禁止を示すデータをＣＵ３へ送信する。
また、上記実施の形態では、計数ボタンの操作が検出されたときに、その操作の検出前にカード返却操作が検出されているか否かをＰ台２が判定する。しかしながら、このような判定手段をＣＵ３が備えるようにしてもよい。この場合、たとえば、Ｐ台２は、計数ボタンの操作が検出されたときに、その旨を示すデータをＣＵ３へ送信する。それを受けたＣＵ３は、そのデータを受信する前の所定期間内にカード返却操作があったか否かを判定するようにすることが考えられる。
また、上記の実施の形態では、計数操作をＰ台２が検出する一方、カード返却操作をＣＵ３が検出するが、計数操作をＣＵ３が検出する一方、カード返却操作をＰ台２が検出する構成としてもよく、両操作共にＰ台２あるいはＣＵ３が検出する構成としてもよい。また、計数ボタンおよびカードカード返却ボタンの取り付け位置は、双方共にＣＵ３としてもＰ台２としてもよく、一方がＣＵ３またはＰ台２としてもよい。
（３９） 持玉または遊技玉の数の変化の有無をＣＵまたはＰ台でチェックし、所定期間、持玉または遊技玉の数が変化しない場合には、ＣＵまたはＰ台でその旨を報知するようにしてもよい。あるいは、報知のための信号を外部装置（ホールコンピュータ、Ｐ台上の呼び出しランプ）に出力してもよい。これにより、たとえば、残り僅かな玉が放置されたままで遊技放棄された台を店員が把握しやすくする。
（４０） あるいは、カードがＣＵに挿入されていないにも関わらず、遊技者の遊技玉が変化した場合には、ＣＵまたはＰ台でその旨を報知するようにしてもよい。あるいは、報知のための信号を外部装置（ホールコンピュータ、Ｐ台上の呼び出しランプ）に出力してもよい。これにより、たとえば、遊技を終えてカードを排出した後に、遊技盤に引っ掛かっていた玉が入賞して遊技玉が払い出されたまま放置されているような台を店員が把握しやすくする。
（４１） 本実施の形態において、ＣＵ３はＰ台２からの前回遊技台情報と最新遊技台情報とを自ら記憶しているデータと比較判定して、Ｐ台２側のデータに不正水増しのないことを確認してデータを補正する。仮に、ＣＵ３側でエラー判定されると、このような状況は、単にＣＵ３の交換が要因（交換後のＣＵ３には比較対象の正規のデータが記憶されていない）であって、不正行為に基づくものではない可能性もあるため、ホールの店員が確認の上で、リモコン等の携帯型端末装置でエラーを解除する。ただし、このように、ＣＵ３が新たなものに交換されていたときには、当該ＣＵ３は上記のエラー判定を一切しないようにしてもよい。また、あるいは、ＣＵ３には、交換されたものであるか否かに関わらず、上記のエラー判定機能を設けないようにしてもよい。
（４２） 本実施の形態において、遊技者所有の有価価値を特定可能な記録媒体であるカードを、遊技開始時にカード挿入／排出口３０９に挿入し、遊技終了後にカード挿入／排出口３０９から抜き取る構成について説明した。しかし、本発明はこれに限られず、カードを、遊技開始時にカード読み取り部に載置し、遊技終了後にカード読み取り部から外す構成であってもよい。つまり、遊技者所有の有価価値を特定可能な記録媒体を受付ける記録媒体受付手段に対して、遊技開始時に記録媒体受付手段に取り付け、遊技終了後に記録媒体受付手段から取り外す構成であればよい。
（４３） 本実施の形態において、ＣＵ３は、Ｐ台２に対してカード抜き取り待ち中の情報を通知し、当該情報の通知を受けたＰ台２が「カード抜き取って下さい」と可変表示装置２７８に表示するなど、カードの抜き取りの報知を行なう構成について説明した。しかし、本発明はこれに限られず、ＣＵ３は、Ｐ台２に対してカード抜き取り待ち中の情報を通知しつつ、表示器５４および／または表示器３１２に「カード抜き取って下さい」と表示するように制御してＣＵ側でカードの抜き取りの報知を行なう構成であってもよい。
（４４） 本実施の形態において、Ｐ台２は、カード抜き取り待ち中＝ＯＮを含む状態情報要求のコマンドを受取ってから、カード抜き取り待ち中＝ＯＦＦを含む状態情報要求のコマンドを受取るまでカードの抜き取りの報知を継続する構成について説明した。しかし、本発明はこれに限られず、Ｐ台２は、カード抜き取り待ち中＝ＯＮを含む状態情報要求のコマンドを受取ってから、一定期間カードの抜き取りの報知を行なっても、カード抜き取り待ち中＝ＯＮを含む状態情報要求のコマンドを受取ってから、カード抜き取り待ち中＝ＯＦＦを含む状態情報要求のコマンドを受取るまでの間、カードの抜き取りの報知を間欠的に行なってもよい。
（４５） 本実施の形態において、Ｐ台２は、カードを受付けたとき、および通信復旧したときに、ＣＵ３のセキュリティ基板３２５から通知された「店舗コード」および「ＳＣ基板ＩＤ」と、Ｐ台２で保持している「店舗コード」および「ＳＣ基板ＩＤ」との一致判定を行ない、一致している場合にはリカバリ処理を行ない、不一致の場合、遊技の継続を禁止する構成について説明した。しかし、本発明はこれに限られず、Ｐ台２は、ＣＵ３のセキュリティ基板３２５から通知された「店舗コード」と、Ｐ台２で保持している「店舗コード」との一致判定を行なう、またはＣＵ３のセキュリティ基板３２５から通知された「ＳＣ基板ＩＤ」と、Ｐ台２で保持している「ＳＣ基板ＩＤ」との一致判定を行ない、一致している場合にはリカバリ処理を行ない、不一致の場合、遊技の継続を禁止する構成であってもよい。
（４６） 本実施の形態の表示器５４において、現在遊技している関連会員遊技者のアバターが表示され、それぞれの関連会員遊技者の遊技状況（たとえば、大当り、出玉○○○発、○○○ハマりなどの状況など）を、管理サーバ１４０または会員管理コンピュータ１２０から遊技履歴などの遊技情報を定期的に受信して表示する構成（フレンド機能）について説明した。しかし、本発明はこれに限られず、管理サーバ１４０または会員管理コンピュータ１２０が、リアルタイムで収集している遊技履歴などの遊技情報を、遊技者のＣＵ３に逐次送信して関連会員遊技者の遊技状況を遊技者の表示器５４にリアルタイムで表示させてもよい。もちろん、管理サーバ１４０または会員管理コンピュータ１２０を経由せず、関連会員遊技者の遊技状況を遊技者のＣＵ３で直接収集して、リアルタイムに表示器５４に表示する構成でもよい。
（４７） 本実施の形態において、関連会員遊技者のアバターと通信するチャット機能は、予め登録してある言葉（定型文）などの文字のみを使用して通信を行なう構成について説明した。しかし、本発明はこれに限られず、関連会員遊技者のアバターと通信するチャット機能に、文字以外の絵などのスタンプを使用して通信を行なう構成であってもよい。また、通信は、遊技者と関連会員遊技者との二者間に限定されるものではなく、遊技者と三者以上の複数の関連会員遊技者間で行なってもよい。
（４８） 本実施の形態において説明したフレンド機能は、原則、所定の範囲で現在遊技しているすべての関連会員遊技者のアバターを表示器５４に表示する構成であると説明した。しかし、本発明はこれに限られず、他の遊技者に自身のアバターを表示させたくない場合に自身のアバターを非表示設定とすることが可能な構成であってもよい。また、自身のアバターを非表示設定する場合、他のすべての遊技者に対して非表示設定するのでなく、特定の他の遊技者に対してのみ非表示設定することもできる。
（４９） 本実施の形態において説明したフレンド機能は、管理サーバ１４０の会員属性情報に登録された関連会員のアバター（遊技者のフレンド）のみを表示器５４に表示する構成であると説明した。しかし、本発明はこれに限られず、管理サーバ１４０の会員属性情報に登録した関連会員が、それぞれ会員属性情報に登録している関連会員のアバター（遊技者のフフレンドのフレンド）までを表示器５４に表示してもよい。また、フレンド機能は、管理サーバ１４０の会員属性情報に登録された関連会員遊技者のアバターのみを表示するのではなく、管理サーバ１４０が自身の会員属性情報に関連する会員遊技者（たとえば、同年代の会員遊技者や、同郷の会員遊技者など）を検索して、当該会員遊技者のアバターを表示器５４に表示してもよい。前述のようにフレンド機能を追加することで、新たなフレンドを容易に見つけることができる。
（５０） 遊技者の一連の操作の流れを妨げないために、各種操作を受け付けるための各種ボタンに被らないように広告表示領域を設定する場合について説明したが、これに限られない。たとえば、広告を半透明で表示することで各種ボタンを視認可能にして遊技者の一連の操作を妨げないようにしてもよい。
（５１） カメラを用いて遊技者の年齢および性別を推定する場合について説明したが、これに限られない。たとえば、ＣＵ３は、遊技者を予め撮像して得られた遊技者の特徴量と、遊技者からの入力により得られた遊技者の年齢および性別とを関連付けてＲＯＭなどのメモリに記憶しておいてもよい。この場合には、ＣＵ３は、遊技者の特徴量と予めメモリに記憶された遊技者の特徴量とを比較することで、遊技者の年齢および性別を特定することができる。
（５２） 本実施の形態において説明したメッセージ画面枠では、所定の操作を行なった場合に、変化する項目を表示する場合（たとえば、「入金操作」を受け付けた場合であれば「残額」および「電子マネー残額」、球貸し操作を受け付けた場合であれば「残額」および「遊技玉数」を表示）について説明したが、これに限られない。具体的には、変化しない項目を含んでいてもよく、たとえば、変化の有無にかかわらず、残額、電子マネー残額、払出玉数、持玉数、遊技玉数、貯玉数などを全て表示する場合であってもよい。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
２ パチンコ機、２Ｓ スロットマシン、３ カードユニット、１６ 主制御基板、１７ 払出制御基板、２６ 遊技盤、５４，３１２ 表示器、３０９ カード挿入／排出口、３２０ ＩＲ受光ユニット、１６１ 主制御部、３２５ 表示制御部、１７１ 払出制御部、３２３ ＣＵ制御部。
Claims (1)
- 遊技場において遊技機に１対１に対応して設けられ受付けた記録媒体により特定される遊技者所有の遊技価値を用いて遊技機での遊技を可能にする遊技用装置と、前記遊技場の外に設置され前記記録媒体の記録情報に対応付けて会員登録された各会員遊技者の会員情報を管理する管理装置とを含む遊技用システムであって、
前記管理装置は、
会員登録された一の会員遊技者が会員登録された他の会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ１次関連会員遊技者として登録する１次登録手段と、
前記一の会員遊技者が前記１次関連会員遊技者の中から選択した会員遊技者を、前記一の会員遊技者と関連性を持つ２次関連会員遊技者として登録する２次登録手段とを有し、
前記一の会員遊技者と前記２次関連会員遊技者との間で特定処理を実行する特定処理手段をさらに含む、遊技用システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013216588A JP2015077290A (ja) | 2013-10-17 | 2013-10-17 | 遊技用システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013216588A JP2015077290A (ja) | 2013-10-17 | 2013-10-17 | 遊技用システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2015077290A true JP2015077290A (ja) | 2015-04-23 |
Family
ID=53009309
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013216588A Pending JP2015077290A (ja) | 2013-10-17 | 2013-10-17 | 遊技用システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2015077290A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105183276A (zh) * | 2015-08-19 | 2015-12-23 | 小米科技有限责任公司 | 在聊天界面实现游戏的方法、装置及终端设备 |
| JP2017086716A (ja) * | 2015-11-13 | 2017-05-25 | 株式会社ユニバーサルエンターテインメント | 遊技用装置及び遊技システム |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003320157A (ja) * | 2002-05-02 | 2003-11-11 | Sankyo Kk | 遊技用装置 |
| JP2005270203A (ja) * | 2004-03-23 | 2005-10-06 | Sankyo Kk | 情報提供システム |
| JP2006271455A (ja) * | 2005-03-28 | 2006-10-12 | Aruze Corp | 遊技システム、遊技関連装置及び遊技場管理装置 |
| JP2010051552A (ja) * | 2008-08-28 | 2010-03-11 | Sankyo Co Ltd | 遊技用装置 |
| JP2013138710A (ja) * | 2011-12-28 | 2013-07-18 | Sankyo Co Ltd | 遊技システム、遊技機及び管理装置 |
-
2013
- 2013-10-17 JP JP2013216588A patent/JP2015077290A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003320157A (ja) * | 2002-05-02 | 2003-11-11 | Sankyo Kk | 遊技用装置 |
| JP2005270203A (ja) * | 2004-03-23 | 2005-10-06 | Sankyo Kk | 情報提供システム |
| JP2006271455A (ja) * | 2005-03-28 | 2006-10-12 | Aruze Corp | 遊技システム、遊技関連装置及び遊技場管理装置 |
| JP2010051552A (ja) * | 2008-08-28 | 2010-03-11 | Sankyo Co Ltd | 遊技用装置 |
| JP2013138710A (ja) * | 2011-12-28 | 2013-07-18 | Sankyo Co Ltd | 遊技システム、遊技機及び管理装置 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105183276A (zh) * | 2015-08-19 | 2015-12-23 | 小米科技有限责任公司 | 在聊天界面实现游戏的方法、装置及终端设备 |
| US10099146B2 (en) | 2015-08-19 | 2018-10-16 | Xiaomi Inc. | Method, terminal device, and storage medium for playing game in chatting interface |
| JP2017086716A (ja) * | 2015-11-13 | 2017-05-25 | 株式会社ユニバーサルエンターテインメント | 遊技用装置及び遊技システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6345425B2 (ja) | 遊技機 | |
| JP2015213562A (ja) | 遊技用装置 | |
| JP6199138B2 (ja) | 遊技用システム | |
| JP6267469B2 (ja) | 遊技用システム | |
| JP6490954B2 (ja) | 遊技機 | |
| JP6302652B2 (ja) | 遊技用システムおよび遊技用装置 | |
| JP2015139458A (ja) | 遊技用システム及び管理装置 | |
| JP2015016108A (ja) | 遊技用システムおよび遊技用装置 | |
| JP6553835B2 (ja) | 遊技用装置 | |
| JP6358787B2 (ja) | 遊技機 | |
| JP6216572B2 (ja) | 遊技機 | |
| JP6489756B2 (ja) | 遊技機 | |
| JP2015077290A (ja) | 遊技用システム | |
| JP6377347B2 (ja) | 遊技用システム及び遊技用装置 | |
| JP6496488B2 (ja) | 遊技機 | |
| JP6541338B2 (ja) | 遊技盤 | |
| JP2017202352A (ja) | 遊技用システム | |
| JP6332976B2 (ja) | 遊技機 | |
| JP6411874B2 (ja) | 遊技盤 | |
| JP2019069364A (ja) | 遊技用システム | |
| JP6489755B2 (ja) | 遊技機 | |
| JP2014217580A (ja) | 遊技用システム、記録媒体処理装置、管理装置、および、携帯端末プログラム | |
| JP6406803B2 (ja) | 遊技機 | |
| JP6368494B2 (ja) | 遊技用システム | |
| JP6216645B2 (ja) | 遊技盤 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160901 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160920 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170623 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170704 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180130 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180724 |