10.07.2015 Views

Class II Electronic Bingo Systems - Gaming Laboratories International

Class II Electronic Bingo Systems - Gaming Laboratories International

Class II Electronic Bingo Systems - Gaming Laboratories International

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.4 Bill Acceptors .....................................................................................................................................385.5 Credit Redemption..............................................................................................................................425.6 Hoppers as the Payment Method........................................................................................................435.7 Printers as the Payment Method.........................................................................................................435.8 Program Storage Device Requirements .............................................................................................455.9 Critical RAM Requirements................................................................................................................485.10 Rules of Play.......................................................................................................................................485.11 Metering .............................................................................................................................................505.12 Error Conditions ................................................................................................................................525.13 Program Interruption & Resumption .................................................................................................535.14 Door Open/Close................................................................................................................................545.15 Taxation Reporting Limits ..................................................................................................................555.16 Test/Diagnostic Mode.........................................................................................................................555.17 Last Game Recall................................................................................................................................56Table of Contents Page 3 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>CHAPTER 11.0 OVERVIEW - STANDARDS FOR CLASS <strong>II</strong>ELECTRONIC BINGO SYSTEMS1.1 Introduction1.1.1 General Statement.THE CONTENTS OF THIS SECTION IS FOR GENERAL EXPLANATION ONLY.PLEASE REFER TO THE GENERAL STATEMENT CONTAINED IN ‘ABOUT THISSTANDARD,’ ABOVE.The Indian <strong>Gaming</strong> Regulatory Act, enacted in 1988 as Public Law 100-497 and nowcodified at 25 U.S.C. §2701, establishes the jurisdictional framework that presentlygoverns Indian <strong>Gaming</strong>. The Act establishes three classes of games with a differentregulatory scheme for each. <strong>Class</strong> <strong>II</strong> <strong>Bingo</strong> is defined as the game of chance commonlyknown as <strong>Bingo</strong> (whether or not electronic, computer, or other technological aids areused in connection therewith) and if played in the same location as the <strong>Bingo</strong>, pull tabs,punch board, tip jars, instant <strong>Bingo</strong>, and other games similar to <strong>Bingo</strong>. The Actspecifically excludes slot machines or electronic facsimiles of any game of chance fromthe definition of <strong>Class</strong> <strong>II</strong> games. Tribes retain their authority to conduct, license, andregulate <strong>Class</strong> <strong>II</strong> <strong>Bingo</strong>, as long as the state in which the Tribe is located, permits such<strong>Bingo</strong> for any purpose and the Tribal government adopts an ordinance approved by theCommission. Tribal governments are responsible for regulating <strong>Class</strong> <strong>II</strong> <strong>Bingo</strong> withCommission oversight.1.1.2 <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Defined. An <strong>Electronic</strong> <strong>Bingo</strong> System may becomprised of the following:a) Game Server;Chapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 4 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) On-Line Monitoring System;c) Player Terminals, which may include currency or voucher acceptors;d) Cashier booths and/or Redemption Terminals;e) and all associated equipment needed for communications (i.e., Data CollectionUnits, Modems, Wireless Equipment, etc.)1.1.3 Phases of Certification. The approval of an <strong>Electronic</strong> <strong>Bingo</strong> System may becertified in two phases:a) Initial laboratory testing, where the laboratory will test the integrity of the systemin a laboratory setting with the equipment assembled; andb) On-site certification where the entire system is set up and tested on the <strong>Bingo</strong>floor prior to implementation.1.2 Acknowledgment of Other Standards Reviewed1.2.1 General Statement.RESERVED1.3 Purpose of Standard1.3.1 General Statement. The purpose of this technical standard is as follows:a) To eliminate subjective criteria in analyzing and certifying <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong><strong>Bingo</strong> <strong>Systems</strong>.b) To only test those criteria that impacts the credibility and integrity of <strong>Bingo</strong> fromthe Revenue Collection, security, and game play point of view.c) To create a standard that will insure that <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> arefair, secure, and able to be audited and operated correctly.Chapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 5 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>d) To recognize that non-game testing (such as Electrical Testing) should not beincorporated into this standard, but left to appropriate test laboratories thatspecialize in that type of testing. Except where specifically identified in thestandard, testing is not directed at health or safety matters. These matters are theresponsibility of the manufacturer, purchaser, and operator of the equipment.e) To construct a standard that can be easily changed or modified to allow for newtechnology.f) To construct a standard that does not specify any particular technology, method oralgorithm. The intent is to allow a wide range of methods to be used to conformto the standards, while at the same time to encourage new methods to bedeveloped.1.3.2 No Limitation of Technology. One should be cautioned that this documentshould not be read in such a way that limits the use of future technology. The documentshould not be interpreted that if the technology is not mentioned, then it is not allowed.As new technology is developed, this standard will be revised and will incorporate newminimum standards for the new technology.1.3.3 Scope of Standard. This standard will only cover those systems that play thegame of <strong>Bingo</strong> as defined by the National Indian <strong>Gaming</strong> Commission (NIGC). Thisstandard will only govern <strong>Electronic</strong> <strong>Bingo</strong> System requirements necessary to achievecertification for the purpose of:a)b)c)d)e)Randomness of selection of balls or numbers;properly displaying selected balls or numbers;properly verifying and awarding player winnings;properly accounting for and reporting all financial and game history data asneeded to properly audit the system; andReasonable security of the Player Terminal(s).Chapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 6 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>1.4 Other Documents That May Apply1.4.1 General Statement. This standard covers the minimal requirements of <strong>Class</strong> <strong>II</strong><strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> and all associated components. The following other standardsmay apply:a) GLI-11<strong>Gaming</strong> Devices in Casinosb) GLI-12 Progressive <strong>Gaming</strong> Devices in Casinosc) GLI-13 On-Line Monitoring and Control <strong>Systems</strong> (MCS) and Validation<strong>Systems</strong> in Casinosd) GLI-16 Cashless <strong>Systems</strong> in Casinose) GLI-17 Bonusing <strong>Systems</strong> in Casinosf) GLI-18 Promotional <strong>Systems</strong> in Casinosg) GLI-20 Redemption Terminals1.5 Definitions1.5.1 General Statement. The following are commonly used terms used throughout thisdocument:“<strong>Bingo</strong>” is defined within section 1.1.2 of this document.“Cashier Booth” means the location where a cashier is stationed where the patron mayredeem their winnings for cash.“Cashless” means player-account driven gaming where the wagers and wins areelectronically transferred from the system to the Player Terminal and vice versa.“Control Program” is the software that operates the Player Terminal’s functions.“Critical Files” means any file that would affect the integrity of the game including, butnot limited to, executables, data, and operating system files and other files, which mayaffect the game outcome or operation, which reside on the Program Storage Device.Chapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 7 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>“Critical Memory” is used to store all data that is considered vital to the continuedoperation of the Player Terminal. This includes, but is not limited to:a) All electronic meters required within the Metering section of this standard,including last bill data and power-up and door open metering;b) Current credits;c) Player Terminal /game configuration data;d) Information pertaining to the last five (5) plays with the respective ball draws(including the current game, if incomplete); ande) Software states (the last normal state the Player Terminal software was in beforeinterruption).“Game Server” means the portion of the <strong>Bingo</strong> System containing the Random NumberGenerator that communicates the randomly generated numbers to the Player Terminals. Itmay be local to an operation or remotely tied via a communications network to the localoperation.“Jackpot” means the portion of a jackpot paid by the <strong>Bingo</strong> game personnel. The amountis usually determined as the difference between the total posted jackpot amount and theamount paid out by the machine. It may also be the total amount of the jackpot.“Kiosk” (or Redemption Terminal) means the location where the patron may redeem hisor her winnings for cash using an automated cashier. Also refer to GLI-20 RedemptionTerminals.“Message Digest” means the mathematical results/signature of the hashing algorithm.“On-Line Monitoring System” means the system that is primarily tasked to providelogging, searching, and reporting of significant events and collection of financial data.The On-Line Management System may be a part of the Game Server or may be separate.Also refer to GLI-13 On-Line Monitoring and Control <strong>Systems</strong> (MCS) and Validation<strong>Systems</strong> in Casinos.“Payment Voucher” is the voucher printed by a Player Terminal as a method of payment.The Voucher is to be redeemed for cash or inserted into another Player Terminal, ifChapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 8 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>optioned in this way and must be validated and cancelled upon redemption by thevoucher Validation System.“Perm” means the total cards electronically available for play.“Personal Identification Number” (or PIN) is a unique identification number provided tothe patron for the purpose of accessing personal information.“Player Terminal” means a device or player station that is connected to a <strong>Bingo</strong> Systemthat allows the player to participate in the game of <strong>Bingo</strong>. The Player Terminal displaysthe game rules, <strong>Bingo</strong> cards, the <strong>Bingo</strong> balls called by the Game Server, credits wagered,and credits awarded and may have currency or voucher validation acceptors.“Program Code” is the computer language used to create the Control Program.“Program Storage Device” or (PSD) means the media used to store the Control Program.“Random Number Generator” (or RNG) means a process of selecting random numbersduring a <strong>Bingo</strong> game in which each number has an equal chance or probability of beingselected.“Redemption Terminal” (or Kiosk) means the location where the patron may redeemtheir winnings for cash using an automated cashier. Also refer to GLI-20 RedemptionTerminals.“Ticket Validation System” means a database that stores pending Payment Voucherinformation for the purpose of verifying the validity of the Voucher, presented forpayment. Also refer to GLI-13 On-Line Monitoring and Control <strong>Systems</strong> (MCS) andValidation <strong>Systems</strong> in Casinos.“Token” means a coin-like-money substitute, in various denominations, used fortransactions.“Tokenization” is when the Player Terminal is configured to issue credits, based on thegame denomination, which not one-to-one and is devisable of the coin inserted. (i.e., 5¢game denomination, 25¢ quarter in the coin acceptor will issue 5 credits for each coin-in)“Validation Number” is the unique number given to a Payment Voucher.Chapter One – Overview – <strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong> Page 9 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>CHAPTER 22.0 SUBMISSION REQUIREMENTS2.1 Introduction2.1.1 General Statement. This chapter shall govern the types of information that are ormay be required to be submitted by the submitting party in order to have equipmenttested to this Standard. Where the information has not been submitted or is not otherwisein the possession of the test laboratory, the submitting party shall be asked to supplyadditional information. Failure to supply the information can result in denial in whole orin part of the submission and/or lead to testing delays.2.1.2 Previous Submission. Where the testing laboratory has been previously suppliedwith the information on a previous submission, duplicate documentation is not requiredprovided that the previous information is referred to by the submitting party and thosedocuments are easily located at the testing laboratory. Every effort shall be made toreduce the redundancy of submission information.2.2 Prototype (Full Submission) Submissions2.2.1 General Statement. A Prototype (full submission) submission is a first timesubmission of a particular piece of hardware or software that has not previously beenreviewed by the test laboratory. For Modifications of previous submissions, includingrequired changes to previously submitted Prototype (full submission) certification,whether certified or pending certification, see ‘Submissions of Modifications (partialsubmissions) to a Previously Certified Item,’ Section 2.7.Chapter Two – Submission Requirements Page 10 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>NOTE: Due to abnormal component complexity and/or excessive cost it is sometimesnecessary for on-site testing of a system at the manufacturer’s facility. Regular upgradesnormally preclude testing at the manufacturer’s facility except in the case of prototypesubmissions.2.2.2 Submission Letter Requirements. Each submission shall include a requestletter on company letterhead dated within one (1) week of the date the submission isreceived by the test laboratory. The letter should include the following:a) The jurisdiction(s) for which you are requesting certification;b) The items requested for certification. In the case of software, the submitting partyshall include ID numbers and revision levels, if applicable. In the case ofproprietary hardware, the submitting party shall indicate the manufacturer, model,and part and revision numbers of the associated components of hardware; andc) A contact person who will serve as the main point of contact for engineeringquestions raised during evaluation of the submission. This may be either theperson who signed the letter or another specified contact; andd) If a wireless network solution is desired, then the design and scope of the wirelesssolution needs to be reviewed for security considerations. Upon installation at thecasino location, an independent network security auditing company should reviewthe installation and security procedures.2.3 System Hardware Submission Requirements – Prototype(Full Submission) Certification2.3.1 Presentation of Equipment to the Test Laboratory; Identical Equipment. Eachitem of <strong>Bingo</strong> equipment supplied by a manufacturer to the field shall be functionallyidentical to the specimen tested and certified. For example, an interface element suppliedas a certified device shall not have different internal wiring, components, firmware,circuit boards, circuit board track cuts or circuit board patch wires from the certifiedChapter Two – Submission Requirements Page 11 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>specimen, unless that change is also certified, see ‘Submissions of Modifications (partialsubmissions) to a Previously Certified Item,’ Section 2.7.2.3.2 Inventory of Equipment to the Test Laboratory. Each submission of hardwareshall contain the following:a) Server, Database, Front-End Controller, and Ancillary Stations to include but notlimited to: Cashier Booth functionality; Callers Desk/Ball Draw functionality;System Configuration Parameters functionality; and Accounting/ReportingFunctionality;b) Monitors, keyboards, mouse, printers, etc., to support the items listed above;c) Un-interruptible Power Supply (UPS) for critical components.d) Daubers and/or Player Terminals;e) Network cabling, hubs, switches, and any wireless components that may beinstalled at a casino property; andf) Minimum of two of each type of magnetic cards (or equivalent if an alternativemedia is used) used in the system, if applicable.NOTE: In an effort to reduce system submission size, monitor and data switches maybe used. Additionally, separate software may be housed in the same unit, as long as thefunctionality is not impaired and the software is identical to the field version.2.3.3 Accompanying Documentation. All accompanying technical documents,manuals, and schematics shall be submitted. In addition, the following items shall beprovided:a) If applicable, all UL, CSA, EC, AS3100, etc. or equivalent certification. Thiscertification information may be supplied at a later date;b) Any other proprietary equipment that may be used in the field in conjunction withthe Submission, if necessary to test the requirements set forth;Chapter Two – Submission Requirements Page 12 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>c) Accompanying software, see also, ‘System Software Submission Requirements –Prototype (Full Submission) Certification,’ Section 2.4; andd) If the submitting party has specialized equipment and/or software which is neededby the test laboratory to test submitted system, such as load/game simulators ortest data files, then the specialized equipment and/or software and all appropriateoperation and user manuals for the equipment and/or software shall be includedwith the submission.NOTE: Commercially available products are not required for submission unlessomission will impact testing and proper operation of the system.2.4 System Software Submission Requirements – Prototype(Full Submission) Certification2.4.1 General Statement. Each submission of software shall contain the following:a) Two sets of all EPROMs, CD-ROMs, or other storage media which containidentical contents. This includes all program executables, system componentfirmware, bin files, etc., unless other arrangements are made in advance of thesubmission. Where the test laboratory already has tested a software component,resubmission may not be necessary;b) Source Code, a Link Map and Symbol Table for all primary software executables.In addition, if requested, explanation of all non-volatile RAM on any systemdevice with the non-volatile RAM locations described;c) All user manuals in both hard and soft copy format to include a general overviewof the system from a component level, software and hardware setup andintegration, and system block diagrams and flow charts for the communicationprogram, if required;d) If not included in the user manuals, a connectivity manual for all associatedperipheral devices or remote sales or monitoring units;Chapter Two – Submission Requirements Page 13 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>e) If not included in the user manuals, provide example reports for each standardreport capable of being generated on the system with a formula summary detailingall reporting calculations including data types involved, mathematical operationsperformed, and field limit (length of field);f) If not included in the user manuals, a list of all supported communicationprotocols specifying version, if applicable; andg) If utilizing a software verification algorithm provide a description of thealgorithm, theoretical basis of the algorithm, results of any analyses or tests todemonstrate that the algorithm is suitable or the intended application, rules forselection of algorithm coefficients or "seeds", and means of setting the algorithmcoefficients or "seeds."2.5 Software Programming Requirements and Compilation2.5.1 General Statement. The following items shall be contained within all submittedsource code or related modules:a) Module Name;b) Brief description of module function; andc) Edit History including who modified it when and why.2.5.2 Source Code Commented. All source code submitted shall be commented in aninformative and useful manner.2.5.3 Source Code Completeness. All source code submitted shall be correct, completeand able to be compiled.2.6 Program IdentificationChapter Two – Submission Requirements Page 14 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>2.6.1 Software Requirements. On the primary system software components submittedand subsequently placed in the field, each program shall be uniquely identified and shalleither display version information at all times or utilize a user accessible function.2.6.2 Firmware Requirements. On all system firmware submitted and subsequentlyplaced in the field each program shall be uniquely identified displaying:a) Program ID;b) Manufacturer;c) Version number;d) Type and size of medium (requirement can be met by manufacturer stamp);ande) Location of installation in interface element device, if potentially confusing.NOTE: For EPROM based firmware, the identification label shall be placed over theUV window to avoid erasing or alteration of the program.2.7 Submissions of Modifications (Partial Submissions) to aPreviously Certified Item2.7.1 General Statement. For any update submission (e.g., a revision to an existinghardware or software that is currently under review, certified or has been reviewed andnot certified), the following information shall be required to process the submission inaddition to the requirements set forth in ‘Submission Letter Requirements,’ Section 2.2.2.All modifications require re-testing, examination, and re-certification by the testlaboratory.2.7.2 Modification of Hardware. Each hardware submission shall:a) Identify the individual items being submitted (including part number);Chapter Two – Submission Requirements Page 15 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) Supply a complete set of schematics, diagrams, data sheets, etc. describing themodification along with the reason for the change(s) for any manufacturerdesigned and built component; andc) Provide the updated or new hardware, a description, and the method of connectionto the original system or hardware components.2.7.3 Modification of System Software Functions or to Correct Software Error. Thesubmitter should use the same requirements as in the ‘System Software SubmissionRequirements – Prototype (Full Submission) Certification’ Section 2.4, listed above,except where the documentation has not changed. In this case, a resubmission ofidentical documents is not required. However, the submission must include:a) If new, a complete description of the function, including amendment manual anduser documents, and new source code if applicable; andb) If modifying, the submission must include a description of the software change(s),the modules affected and a new source code, if applicable.2.8 System Security Submission Requirements2.8.1 General Statement. Where a system requires the use of defined user roles withassociated passwords or PINs, a default list of all users and passwords or PINs must besubmitted, including a method to access the card and/or the player account database(s).This will allow testing of the permissible access and to ensure no unauthorized accesswould be allowed for specific areas.2.9 Joint Venture Submissions2.9.1 General Statement. A system is considered a joint venture when two or morecompanies are involved in the manufacturing of one system. Due to the increasingamount of joint venture submissions (more than one supplier involved in a productChapter Two – Submission Requirements Page 16 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>submission) and to alleviate any confusion to the suppliers, the following procedureshave been set forth.a) One company will prepare and submit the entire submission, even if they areusing parts from other suppliers, and must identify all part numbers of allcomponents. This will be the primary contact for the submission;b) The company submitting an approval request should do so on their letterhead.GLI will delegate an internal file number in this company’s name and will billthis company for all costs incurred throughout the approval process;c) The primary contact will be called when questions arise. However, testingengineers will work with all parties involved to complete the review;d) All suppliers who are part of the submission “group” may need to be licensedin the jurisdiction(s) where the submission is being approved. As a courtesyto the supplier, GLI may inquire as to whom does not need to be licensed fromthe regulator client. It should be noted that licensing questions should behandled directly with the jurisdiction; ande) Upon completion, it is the primary contact company that will receive theapproval letter, provided the submission meets the jurisdictional requirements.The primary contact company may then release copies of the approval letter tothe associated manufacturer(s).2.10 Random Number Generator Requirements2.10.1 General Statement. In some cases, where the system utilizes an electronicRandom Number Generator (RNG), the electronic RNG shall be submitted with thePrototype (full submission) Requests. RNGs shall be submitted for certification where:a) The RNG code has changed or the implementation of the random number haschanged; orChapter Two – Submission Requirements Page 17 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) Where a previously certified RNG is being implemented on a new hardwareplatform (i.e. change of microprocessor); orc) Where a previously certified RNG is generating numbers that are outside therange of numbers previously tested; ord) The RNG has never been certified before under these standards. In this case, theRNG will be certified as a part of the overall submission.2.11 Hardware Requirements for RNG Testing2.11.1 General Statement. The manufacturer shall submit the equipment needed fortesting.2.11.2 Cable Requirements. The manufacturer shall submit a cable to connect from thePlayer Terminal to the Game Server and/or on-line monitoring system, if necessary. Thiscable will utilize serial-type communications and easily attach to a standard PC. If anyspecial attachments or converters are necessary, the submitting party shall supply theequipment.2.11.3 GLI Standard Communications Specifications for RNG Testing. The testlaboratory has developed a relatively simple program to collect the data through a serialcommunications port. Adherence to the specifications below allows the submitting partyto use the test laboratory’s PC-based RNG gathering program. Use of this protocol isNOT required; however, in that case, the submitting party shall supply the softwarecollection interface software for the test lab’s use, which will be reviewed prior toimplementation. The following describes the implementation of the remote protocol:a) The test laboratory’s PC-based RNG gathering program uses the followingcommunications protocol. The lab can configure a standard COM1 or COM2port to the Game Server;Chapter Two – Submission Requirements Page 18 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) The manufacturer shall supply the test laboratory with a system or other mediumtest program running on the actual system or other medium that will do thefollowing:i. Look for the ASC<strong>II</strong> letter “R” for Ready to be sent from the test laboratorycollecting computer to the Game Server;ii. Upon the system receiving the “R”, the system shall call the RNG for thenumbers of the next game. The system shall return to the collecting computerthe amount of numbers called for each game.c) The system shall then send the randomly generated numbers to the collectingcomputer in the following format:i. The numbers SHALL be in ASC<strong>II</strong> format;ii. The numbers SHALL be separated by a space;iii. Leading zeros SHALL be inserted (e.g., if the game is returning twenty (20)balls for a keno system being used for this example) with the range ofnumbers being between 1 and 80, the output to the collecting computer willlook like the following: 23 25 01 00 10 09 43 51 03 04);iv. The system should NOT send a space, line feed, or carriage return after thelast number (the test laboratory will do that); andv. After sending the numbers, the system shall look for another “R” and repeatthe process.2.11.4 Additional Requirements.a) The test program RNG shall be identical to the RNG contained in the systemsoftware except for the following changes, which may be implemented to speedup the requirements of the test. The test laboratory may not allow any of thefollowing changes where it determines such change might affect the data receivedfrom the RNG. It should be noted that production software may have a test modeChapter Two – Submission Requirements Page 19 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>that contains this imbedded RNG test mode, provided that the machine indicatesclearly that it is in said test mode;b) The RNG test program should NOT require credits in order to play;c) The RNG test program should NOT award credits;d) The RNG test program does not have to show the game play. The program canjust display a message that states RNG test in progress;e) The manufacturer shall supply the test laboratory with detailed instructions onhow to set-up the system for test; andf) The manufacturer shall supply the test laboratory with a detailed description ofthe RNG algorithm that includes a detailed description on the RNGimplementation in their device, including how the initial SEED is generated. Inaddition, it shall provide the algorithm for reseeding or changing of the seedduring game play, if applicable.Chapter Two – Submission Requirements Page 20 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>CHAPTER 33.0 NIGC <strong>Bingo</strong> Game Definitions3.1 Introduction3.1.1 General Statement. This section covers the basic game elements common to theplay of <strong>Bingo</strong>. Due to the specific legal nature of <strong>Class</strong> <strong>II</strong> <strong>Bingo</strong> this document includesseveral NIGC Opinions and Guidance Bulletins to help clarify the game elements thatmay be required by the NIGC for a game to qualify as <strong>Bingo</strong>. The device manufacturershould be aware that specific items mentioned in the opinions, while not law, may or maynot be applied to the device by the NIGC and may be used as a factor in determiningoverall suitability of submitted items.This information is included here, again, as background information. It does notrepresent GLI’s belief of the law, the Tribe’s belief of the law or the NIGC’s belief of thelaw, in this area. It is not the intention of this document to offer legal advice, legalopinions or instruct the reader on what constitutes a <strong>Class</strong> <strong>II</strong> device, but rather thisinformation is being provided so that readers may gain a general understanding of thetype of equipment that this standard covers.It is highly recommended that any supplier interested in <strong>Class</strong> <strong>II</strong> equipment should hiretheir own legal counsel experienced in these matters. All questions as to classificationcriteria should be referred to individual Tribes, the supplier’s legal counsel or theNational Indian <strong>Gaming</strong> Commission.Original copies of the Advisory Bulletin and the two opinions cited below are availableon the NIGC web site at www.nigc.gov.Chapter Three – NIGC <strong>Bingo</strong> Game Definitions Page 21 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>3.2 NIGC Requirements for an <strong>Electronic</strong> <strong>Bingo</strong> Game3.2.1 General Statement. The following are the specific elements defined by NIGCrulings that may be required for an <strong>Electronic</strong> <strong>Bingo</strong> game:a)b)c)d)e)f)g)h)i)j)k)l)m)n)<strong>Electronic</strong> player stations must link players into a common game.The <strong>Bingo</strong> System must allow for and encourage multiple players and require aminimum of two players.The winning pattern or arrangement must be known before the game begins.Players must obtain a card before numbers are drawn.<strong>Electronic</strong> Cards are permissible but must be readily visible on the screen,prominently sized and displayed, using a readable font and contrasting colors.The numbers are randomly drawn or determined electronically.Numbers drawn are used in real time and not stored for later use.Selected numbers are used in the sequence in which they are drawn.The game-winning pattern cannot be achieved in a single ball release, thusrequiring that players participate in the contest to be the first to cover the winningpattern.All players must have the same opportunity to cover or daub to reflect theirparticipation in a common game.Prizes must be determined by play of the <strong>Bingo</strong> game, not by any other additionalelement of chance.The game must be won by the player(s) who first obtains a pre-designatedwinning pattern and who “covers” or “daubs” the numbers yielding that pattern.Players who fail to daub ‘sleep’ their winning <strong>Bingo</strong> pattern – and the gamecontinues; andConsolation, secondary, or interim prizes and progressive prizes are permissible ifthe award of these prizes comports with the IGRA requirements for <strong>Bingo</strong>,including the requirement for obtaining and daubing a predetermined pattern.Chapter Three – NIGC <strong>Bingo</strong> Game Definitions Page 22 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>We direct the reader to www.nigc.gov to obtain copies of game classification opinionsfor <strong>Class</strong> <strong>II</strong> and <strong>Class</strong> <strong>II</strong>I games. In addition, we direct the reader to specifically read theopinion letters on Reel Time <strong>Bingo</strong> (Multimedia Games) and Mystery <strong>Bingo</strong> (SierraDesign Group).Further we direct the reader to www.nigc.gov to obtain a copy of theNIGC Bulletin, 03-3, dated 9/23/03 entitled “Guidance on <strong>Class</strong>ifyingGames with Pre-Drawn Numbers.”Chapter Three – NIGC <strong>Bingo</strong> Game Definitions Page 23 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>CHAPTER 44.0 GAME SERVER REQUIREMENTS4.1 Introduction4.1.1 General Statement. This section covers the elements common to the “back-ofthe-house”operations of a <strong>Bingo</strong> System, hereinafter, ‘Game Server.’ The Game Serverrequirements outlined within this section may reside on an independent system orimbedded within the On-Line Monitoring and/or Ticket Validation and/or Cashless orother system, if and where applicable. The requirements for other system types (nongameserver) are defined within Section 1.4.1.4.2 General Operation & Server Security4.2.1 General Statement. The Game Server shall generate and transmit to the PlayerTerminals a set of random numbers, colors and/or symbols (hereinafter, ‘balls’),depending on the rules of the <strong>Bingo</strong> game. The game results are determined at the PlayerTerminal and any rewards are then available to be transmitted to the On-Line MonitoringSystem.4.2.2 Security. The Game Servers shall be housed in a Game Server room or in asecurely locked cabinet outside of the Player Terminals.4.2.3 Configuration Access Requirements. The Game Server interface elementsetup/configuration menu(s) must not be available unless using an authorized accessmethod that is secure.Chapter Four – Game Server Requirements Page 24 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>4.2.4 Card Database Security. An <strong>Electronic</strong> <strong>Bingo</strong> System shall possess a database ofall cards in the perm. Modification or changes to card faces shall not be permitted.Password authorization or another secure method shall control access to the database.4.3 Wireless Ethernet Communication4.3.1 General Statement. Should a wireless Ethernet communication solution beadopted, then additional security precautions must be taken. The current wirelessEthernet technology (Wi-Fi) is vulnerable and should not be considered secure. Thewired LAN (Local Area Network) must be isolated from the wireless (WLAN) networkthrough the layering of additional network security methods. The followingrecommendations are to be considered minimum recommendations and not restrictions:a)b)c)d)The wireless access point must be physically positioned in the building so that itis not easily accessible by unauthorized individuals.The access point must not be placed directly onto the casino network unless astand-alone stateful packet inspection firewall is employed.Wireless network traffic must be secured with additional encryption tocompensate for the weaknesses in Wi-Fi.The keys used to encrypt the communication through the wireless network mustbe stored in a secure location.4.4 Ball Drawing4.4.1 General Statement. The following are the <strong>Bingo</strong> System Game Serverrequirements for ball drawing:a) The balls shall be drawn one at a time via an approved electronic RandomNumber Generator certified for use in the game of <strong>Bingo</strong>;b) The operator shall have no discretion over which ball is drawn; andChapter Four – Game Server Requirements Page 25 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>c) The Game Server shall transmit the drawn balls to the individual PlayerTerminals.4.5 <strong>Electronic</strong> Random Number Generator Requirements4.5.1 General Statement. The use of an RNG results in the selection of game symbolsor production of Game Server outcomes. The selection shall:a) Be statistically independent;b) Conform to the desired random distribution;c) Pass various recognized statistical tests; andd) Be unpredictable.4.5.2 Applied Tests. The test laboratory may employ the use of various recognizedtests to determine whether or not the random values produced by the random numbergenerator pass the desired confidence level of 95%. These tests may include, but are notlimited to:a) Chi-square test;b) Equi-distribution (frequency) test;c) Gap test;d) Overlaps test;e) Coupon collector’s test;f) Permutation test;g) Kolmogorov-Smirnov test;h) Adjacency criterion test;i) Order statistic test;j) Runs test (patterns of occurrences should not be recurrent);k) Interplay correlation test;Chapter Four – Game Server Requirements Page 26 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>l) Serial correlation test potency and degree of serial correlation (outcomes shouldbe independent of the previous game); andm) Tests on subsequences.4.5.3 Background RNG Activity Requirement. The RNG shall be cycled continuouslyin the background between ball draws and during game play at a speed that cannot betimed by the player. The test laboratory recognizes that some time during the game, theRNG may not be cycled when interrupts may be suspended. The test laboratoryrecognizes this, but shall find that this exception should be kept to a minimum.4.5.4 RNG Seeding. The first seed shall be randomly determined by an uncontrolledevent. After every ball draw, there shall be a random change in the RNG process (newseed, random timer, delay, etc.). This will verify the RNG doesn’t start at the same value,every time. It is permissible not to use a random seed; however, the manufacturer mustensure that games will not synchronize.4.5.5 Ball Drawing Games. The consequences for games depicting balls being drawnfrom a barrel are as follows:a) At the start of each game, only balls applicable to the game are to be depicted;b) The barrel shall not be re-mixed except as provided by the rules of the gamedepicted;c) As balls are drawn from the barrel, they shall be immediately used as directed bythe Rules of the Game; andd) There can not be any possibility of the game ball/number being drawn more thanonce during the same game.4.5.6 Scaling Algorithms.a) If a random number with a range shorter than that provided by the RNG isrequired for some purpose within the Player Terminal, the method of re-scaling,Chapter Four – Game Server Requirements Page 27 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>(i.e., converting the number to the lower range), is to be designed in such a waythat all numbers within the lower range are equally probable.b) If a particular random number selected is outside the range of equal distribution ofre-scaling values, it is permissible to discard that random number and select thenext in sequence, for the purpose of re-scaling.4.6 Mechanical Random Number Generator Requirements4.6.1 General Statement. Mechanical based RNG games are games that use the lawsof physics to generate the outcome of the game. This includes ball blowers, rotarymixers, drums, or other physical mixing devices.4.6.2 Use of Mechanical RNG Devices. Current NIGC and Court Documents do notaddress the use of mechanical RNG based games. Should future rulings address this issuethis standard will be updated accordingly.4.7 Accounting/Event Reporting4.7.1 General Statement. The on-line monitoring and/or Game Server shall be capableof maintaining the following accounting and event data and shall be capable of producingreports on demand, as required by the specific local regulatory authority:a) Data required to be maintained for each <strong>Bingo</strong> Game includes:i. Date and time of the game start and game end;ii. RESERVED;iii. Cards-in-play count by location;iv. Identification number of winning card(s);v. Ordered list of balls or numbers drawn;vi. Prize amounts awarded for each game, for each location/Player Terminal;vii. RESERVED;Chapter Four – Game Server Requirements Page 28 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>viii. All information for special games that would be required to validate a <strong>Bingo</strong>(i.e., Color, special patterns, special cards, free strips, odd/even numbers,etc.); andix. RESERVED.b)Sales information for each <strong>Bingo</strong> game shall include:i. The name of the organization or hall;ii. Price of card faces;iii. Daily sales totals, by location;iv. Game-by-game sales and prizes by location;v. Packet Sales. There shall be an easy means to determine the specific cardssold for play, for each game. Daily reports based on the calendar date mustprovide this information;vi. Daily network summary, by game, by location (applies to multiple sites usinga single server);vii. Cash due and cash received reconciliation; andviii. Hard/Soft Count Reconciliation which is a log of all accounting changes (i.e.,meter adjustments and sales data corrections) including the employeename/ID authorized to make the changes, the date of the change, the time ofthe change, and the detailed items adjusted shall be kept on the system.4.8 Software Verification4.8.1 General Statement. The <strong>Systems</strong>, components of the systems (including Kiosks),Player Terminals and associated equipment that would affect the integrity of the gameand/or system, shall have the ability to allow for an independent integrity check of thesoftware from an outside source. This applies to any program that has an affect of theintegrity of the game/system. The verification of the software must be accomplished bybeing authenticated by a third-party device, which may be embedded within the systemsoftware (see *NOTE, below) or having an interface port for a third-party device toChapter Four – Game Server Requirements Page 29 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>authenticate the media. This integrity check will provide a means for field testing thesoftware to identify and validate the program. The test laboratory, prior to deviceapproval, shall approve the integrity check method.*NOTE: If the authentication program is contained within the game software, themanufacturer must receive written approval from the test laboratory prior to submission.NOTE: The ability of the system performing the authentication is subject to review basedon jurisdictional regulations and may or may not be required of the system. Therefore, itmay be necessary to provide for an independent check of each components software.Chapter Four – Game Server Requirements Page 30 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>CHAPTER 55.0 PLAYER TERMINAL REQUIREMENTS5.1 Introduction5.1.1 General Statement. This terminal is used by the player to place wagers, play thegame of bingo, and win prizes (when applicable). The Player Terminal receives the balldraw information from the Game Server and displays the information to the player. APlayer Terminal at a minimum will contain some form of activation to enroll in the <strong>Bingo</strong>Session and individual <strong>Bingo</strong> game and contain a methodology for delivery of thedetermined outcome. The device may be separated in parts, where some may be withinor outside the Player Terminal (e.g., Player Terminals that function with a system).5.2 Cabinet Requirements5.2.1 Physical Security. A Player Terminal shall be robust enough to withstand forcedillegal entry which would leave behind evidence of the attempted entry, unless such entrycauses an error code or is cleared at the commencement of a new play, and which doesnot affect the subsequent play or any other play, prize or aspect of the game.5.2.2 Machine and Player Safety. Electrical and mechanical parts and designprincipals of the Player Terminal may not subject a player to any physical hazards. Thetest laboratory shall NOT make any finding with regard to Safety and EMC testing, asthat is the responsibility of the manufacturer of the goods or those that purchase thegoods. Such Safety and EMC testing may be required under separate statute, regulation,law, or Act and should be researched accordingly, by those parties who manufacture orpurchase said devices. The test laboratory shall not test for, be liable for, nor make afinding relating to these matters.Chapter Five - Player Terminal Requirements Page 31 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.2.3 Environmental Effects on Game Integrity. The laboratory will perform certaintests to determine whether or not outside influences affect game fairness to the player orcreate cheating opportunities. A Player Terminal shall be able to withstand the followingtests, resuming game play without operator intervention:a) Electro-Magnetic Interference. Player Terminals shall not create electronic noisethat affect the integrity or fairness of neighboring machines or associatedequipment;b) Electro-Static Interference. Protection against static discharges requires that themachine’s conductive cabinets be earthed in such a way that static dischargeenergy shall not damage or inhibit the normal operation of the electronics or othercomponents within the Player Terminal. Player Terminals may exhibit temporarydisruption when subjected to a significant Electro-static discharge greater thanhuman body discharge, but they shall exhibit a capacity to recover and completeany interrupted play without loss or corruption of any control or data informationassociated with the Player Terminal. The tests will be conducted with a severitylevel of a minimum of 27KV air discharge;c) Radio Frequency Interference (RFI). Player Terminals shall not divert fromnormal operation by the application of RFI at a frequency range from twentyseven(27) to one thousand (1000) MHz with a field strength of three (3) volts permeter;d) Magnetic Interference. Player Terminals shall not be adversely affected bymagnetic interference. The manufacturer should supply any documentation if thedevice has had magnetic interference testing against any recognized standard; ande) Liquid Spills. Liquid spills applied to the outside of a Player Terminal, shall notaffect the normal operation of the machine, the integrity of the material orinformation stored inside the cabinet, or the safety of the players operating theequipment. If liquids are spilled into a coin acceptor or bill acceptor, the onlyChapter Five - Player Terminal Requirements Page 32 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>degradation permitted is for the acceptor to reject all inputs or generate an errorcondition, see also ‘Error Conditions,’ Section 5.12, of this standard.5.2.4 Temperature and Humidity. Player Terminals can be expected to operate in avariety of extreme environments. In the event that the designed operational parameters ofa Player Terminal are exceeded, the machine, if incapable of continued proper operation,shall perform an orderly shutdown without loss of game status, accounting, and securityevent data. The manufacturer should supply any documentation if the device has hadtemperature and humidity testing against any recognized standard.5.2.5 Surges. The machine shall not be adversely affected, other than resets, by surgesor dips of ± 20% of the supply voltage.NOTE: It is acceptable for the equipment to reset provided no damage to the equipmentor loss or corruption of data is experienced in the field.5.2.6 On/Off Switch. An on/off switch that controls the electrical current shall belocated in a place which is readily accessible within the interior of the machine so thatpower cannot be disconnected from outside of the machine using the on/off switch. Theon/off positions of the switch shall be labeled.5.2.7 Cabinet Wiring. The Player Terminal shall be designed so that power and datacables into and out of the Player Terminal can be routed so that they are not accessible tothe general public. This is for game integrity reasons only, not for health and safety.Security-related wires and cables that are routed into a logic area shall not be able to beeasily removed.5.2.8 Machine Identificaion. A Player Terminal shall have a not easily removable,without leaving evidence of tampering, identification badge, permanently affixed to theChapter Five - Player Terminal Requirements Page 33 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>exterior of the cabinet by the manufacturer, and this badge shall include the followinginformation:a) The manufacturer;b) A unique Validation Number;c) The Player Terminal model number; andd) The date of manufacture.5.2.9 Diverter. For games that accept coins or tokens, the software shall ensure that thediverter directs coins to the hopper or to the drop box when the hopper is full. Thehopper full detector shall be monitored to determine whether a change in diverter status isrequired. If the state of the detector changes, the diverter shall operate as soon aspossible, or within ten (10) games after the state change without causing a disruption ofcoin flow or creating a coin jam. Hopper-less Player Terminals shall always divert coinsto the drop box.5.2.10 Drop Box. If the game is equipped to accept coins or tokens, then the followingrules shall be met:a) Each Player Terminal equipped to accept coins or tokens shall contain a separatedrop bucket or drop box to collect and retain all such coins or tokens that arediverted into the drop box;b) A drop bucket shall be housed in a locked compartment separate from any othercompartment of the Player Terminal; andc) There shall be a method to electronically monitor the drop box area i.e., DoorOpen switches, even if manufactured by a different company.5.2.11 External Doors/Compartment Requirements.a) The interior of the device shall not be accessible when all doors are closed andlocked;Chapter Five - Player Terminal Requirements Page 34 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) Doors shall be manufactured of materials that are suitable for allowing onlylegitimate access to the inside of the cabinet (i.e., doors and their associatedhinges shall be capable of withstanding determined illegal efforts to gain access tothe inside of the Player Terminal and shall leave evidence of tampering if anillegal entry is made);c) The seal between the cabinet and the door of a locked area shall be designed toresist the entry of objects;d) There shall be a light on the top of the device that is clearly visible thatautomatically illuminates when the door to the Player Terminal, or doors to anydevices connected to the Player Terminals which may affect the operation of thePlayer Terminals, are opened. This requirement may be substituted for an audiblealarm or a common candle for machines such as the ‘bar-top’ style;e) Bar-top Game Exception. All bar-top Player Terminals shall have a light alarm,or an audio door alarm installed. The alarm shall be designed to activate when theinside of the machine is accessed with power on;f) All external doors shall be locked and monitored by door-access sensors, whichshall detect and report all external door openings, both to the machine by the wayof an error and to an on-line system.NOTE: The drop box door open does not have to cease game play; however, itmust still illuminate the tower light or alarm and notify the on-line system;g) It shall not be possible to insert a device into the Player Terminal that will disablea door open sensor when the machine’s door is shut without leaving evidence oftampering; andh) The sensor system shall register a door as being open when the door is movedfrom its fully closed and locked position.5.2.12 Logic Door and Logic Area. The logic area is a locked cabinet area (with its ownindependent locked door), which houses electronic components that have the potential tosignificantly influence the operation of the Player Terminal. There may be more than one(1) such logic area in a Player Terminal.Chapter Five - Player Terminal Requirements Page 35 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.2.13 <strong>Electronic</strong> Components. <strong>Electronic</strong> component items that are required to behoused in one (1) or more logic areas are:a) CPUs and other electronic components involved in the operation and evaluationof game play (e.g., game controller electronics and components housing the gameor system firmware program storage device);b) RESERVED;c) The Control Program, electronics involved in the calculation of game display andcomponents housing display program storage medium (passive display equipmentexempted);d) Communication controller electronics and components housing thecommunication program storage media or the communication board for the onlinesystem may reside outside the Player Terminal; ande) All flash memory devices that affect the game play function of the PlayerTerminal.5.2.14 Non-Volatile RAM Requirements. The following are the requirements for RAM:a) Battery Back-up. A battery back-up, or an equivalent, shall be installed on thegame for the electronic meters and shall be capable of maintaining the accuracy ofall information required for thirty (30) days after the power is discontinued fromthe machine. The back-up device shall be kept within the locked Logic Area;b) If the battery back-up is used as an ‘off chip’ battery source, it shall re-chargeitself to its full potential in a maximum of twenty-four (24) hours. The shelf lifeshall be at least five (5) years;c) Random access memory that uses an off-chip back-up power source to retain itscontents when the main’s power is switched off shall have a detection systemwhich will provide a method for software to interpret and act upon a low batterycondition; andChapter Five - Player Terminal Requirements Page 36 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>d) Clearing non-volatile memory shall only be able to be undertaken by accessingthe logic area in which it is housed.5.2.15 Printed Circuit Board (PCB) Identification Requirements. Requirements forPCB identification:a) Each printed circuit board (PCB) shall be identifiable by some sort of name (ornumber) and revision level;b) The top assembly revision level of the PCB shall be identifiable (if track cutsand/or patch wires are added to the PCB, then a new revision number or levelshall be assigned to the assembly); andc) Manufacturers shall ensure that circuit board assemblies, used in their PlayerTerminals, conform functionally to the documentation and the certified versionsof those PCBs that were evaluated and certified by the test laboratory.5.2.16 Patch Wires & Track Cuts. All patch wires and track cuts shall be documented,in an appropriate manner, in the relevant service manual and/or service bulletin and shallbe submitted to the test laboratory. This does not prohibit required repairs in the field.5.2.17 Power and Communication Lines. The termination points of power andcommunication lines shall not be accessible to players or unauthorized personnel.5.3 Coin or Token Acceptors5.3.1 General Statement. If the Player Terminal uses a coin acceptor, the acceptorshall accept or reject a coin on the basis of metal composition, mass, composite makeup,or equivalent security. In addition, it shall meet the following rules:a) Coin Acceptor Security Features/Error Conditions. The coin acceptor shall bedesigned to prevent the use of cheating methods such as slugging (counterfeitChapter Five - Player Terminal Requirements Page 37 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>coins), stringing (coin pullback), the insertion of foreign objects and othermanipulation;b) Rapidly Fed Coins. The Player Terminal shall be capable of handling rapidly fedcoins or piggy backed coins so that occurrences of cheating are eliminated;c) Direction Detectors. The Player Terminal shall have suitable detectors fordetermining the direction and the speed of coin travel in the receiver. If a cointraveling at too slow of a speed or improper direction it is detected. The PlayerTerminal shall enter an error condition and display an error condition, untilcleared by an attendant;d) Invalid Coins. Coins deemed invalid by the acceptor shall be rejected to the cointray and shall not be counted as credits;e) Coin Acceptance Conditions. Acceptance of coins for crediting to the creditmeter shall only be possible when the Player Terminal is enabled for play. Otherstates, such as error conditions, including door opens, audit mode and game play,shall cause the disabling of the coin acceptor system; andf) Credit Meter Update on Coin Insertion. Each coin inserted shall register theactual monetary value or a number of credits on the player’s credit meter for thenext game or bet meter. If registered directly as credits, the conversion rate shallbe clearly stated or be easily ascertainable from the Player Terminal.NOTE: The error conditions within this section shall also comply with the rulesoutlined within ‘Error Conditions,’ Section 5.12, unless otherwise noted.5.3.2 Coin Compartments. The coin compartment shall be locked separately from themain cabinet area, except that a separate cash compartment shall not be required for coinsnecessary to pay prizes in a Player Terminal that pays prizes through a drop hopper.5.4 Bill AcceptorsChapter Five - Player Terminal Requirements Page 38 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.4.1 General Statement. All acceptance devices shall be able to detect the entry ofvalid bills, coupons, paper tokens, or other approved notes, if applicable, and provide amethod to enable the Player Terminal software to discriminate, interpret and actappropriately upon a valid or invalid input. The acceptance device(s) shall beelectronically based and be configured to ensure that when accepting currency, they onlyaccept valid bills of legal tender. Bill acceptors may also accept coupons, paper tokens,or other approved notes and reject all others in a highly accurate manner. The bill-inputsystem shall be constructed in a manner that protects against vandalism, abuse, orfraudulent activity. In addition, bill acceptance device(s) shall meet the following rulesfor all acceptable types of medium:a) Credits. Credits shall only be registered when:i. The bill or other note has passed the point where it is accepted and stacked;andii. The acceptor has sent the “irrevocably stacked” message to the machine.5.4.2 Bill Acceptor Communications. All bill acceptors shall communicate to thePlayer Terminal using a bi-directional protocol.5.4.3 Factory Set Bill Acceptors. If bill acceptors are designed to be factory set only, itshall not be possible to access or conduct maintenance or adjustments to those billacceptors in the field, other than:a) The selection of bills, coupons, paper tokens, or other approved notes and theirlimits;b) Changing of certified EPROMs or downloading of certified software;c) Adjustment of the tolerance level for accepting bills or notes of varying qualityshould not be allowed externally to the machine. Adjustments of the tolerancelevel should only be allowed with adequate levels of security in place. This canChapter Five - Player Terminal Requirements Page 39 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>be accomplished through lock and key, physical switch settings, or other acceptedmethods approved on a case-by-case basis;d) Maintenance, adjustment, and repair per approved factory procedures; ore) Options that set the direction or orientation of acceptance.5.4.4 Tokenization. For games that allow tokenization, the game shall receive from thebill acceptor and post to the player the entire amount inserted.5.4.5 Metering of Bill Acceptor Events. A Player Terminal, which contains a billacceptor device, shall maintain sufficient electronic metering to be able to report thefollowing:a) Total monetary value of all items accepted;b) Total number of all items accepted; andc) A break down of the bills accepted:i. For bills, the game shall report the number of bills accepted for each billdenomination;ii. For all other notes, the game shall have a separate meter that reports thenumber of notes accepted, not including bills.5.4.6 Bill Recall. A Player Terminal that uses a bill acceptor shall retain in its memoryand display the denomination of the last five-(5) bills inserted, and the date and time ofthe insertion.5.4.7 Error Conditions. Each Player Terminal and/or bill acceptor shall have thecapability of detecting and displaying (for bill acceptors, it is acceptable to disable orflash a light or lights) the following bill acceptor error conditions:Chapter Five - Player Terminal Requirements Page 40 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>a) Stacker Full – the bill acceptor should disable itself to no longer accept bills. Thegame should not generate an error message when the stacker is full. This is anexception to having to display the message;b) Bill Jams – it is acceptable for the bill acceptor to indicate there is a bill jam bydisabling itself to accept no more bills or by some other method;c) Bill Acceptor Door Open – where a bill acceptor door is the belly glass door, adoor open signal is sufficient; andd) Stacker Door Open or Stacker Removed.NOTE: the Bill Acceptor Error Conditions listed above shall also apply to thegeneral ‘Error Conditions,’ of this standard.5.4.8 Power Failure during Bill Acceptance/Validation. If a power failure occursduring acceptance, the bill acceptor shall give proper credits for the bill or return the billto the player, notwithstanding that there may be a small window of time where powermay fail and credit may not be given. In this case, the window shall be less than one (1)second.5.4.9 Self Test. The bill acceptor device shall perform a self-test at each power up. Inthe event of a self-test failure, the bill acceptor shall automatically disable itself (i.e.,enter bill reject state) until the error state has been cleared.5.4.10 Influence Requirements. Environmental effects, as outlined within Section 5.2.3shall not adversely affect a bill acceptor. In addition, the manufacturer should supply anydocumentation if the bill acceptor has had any of these tests performed by a recognizedstandard.5.4.11 Stacker Requirements. Each bill acceptor shall have a secure stacker and allaccepted bills shall be deposited into the secure stacker. The secure stacker is to beChapter Five - Player Terminal Requirements Page 41 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>attached to the Player Terminal in such a manner so that it cannot be easily removed byphysical force and shall meet the following rules:a) The bill acceptor device shall have a ‘stacker full’ sensor;b) The stacker shall be independently locked, requiring a separate key to remove thestacker from the main cabinet area that is fitted with sensors that indicate dooropen/close or stacker removed. In addition, a separate key shall be required toremove the contents from the stacker; andc) A tower light or alarm shall be activated whenever there is access to the bill dooror the stacker has been removed.5.5 Credit Redemption5.5.1 General Statement. Available credits may be collected from the Player Terminalby the player pressing the “COLLECT” button at any time other than during:a) A game being played;b) Audit mode;c) Any door open;d) Test mode;e) A Credit Meter or Win Meter incrementation, unless the entire amount is placedon the meters when the collect button is pressed; orf) An error condition.5.5.2 Cancel Credit. If credits are collected, and the total credit value is greater than orequal to a specific limit (e.g., Hopper Limit for hopper games or Printer Limit for printergames), the game shall lock up until the credits have been paid, and the handpay iscleared by an attendant.Chapter Five - Player Terminal Requirements Page 42 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.6 Hoppers as the Payment Method5.6.1 Error Conditions. There shall be under no circumstances, an abnormal payoutfrom the hopper (if one exists) when the hopper is exposed to higher levels of electrostaticdischarge or if power is lost at any time during a payout. The hopper shall beinterfaced in such a way as to allow the Player Terminal Control Program to monitor thehopper mechanism, in all game states, to identify at least the following events and shallmeet the rules in ‘Error Conditions,’ Section 5.12:a) Extra coin paid; andb) Hopper jam or empty.NOTE: The hopper shall be resistant to manipulation by the insertion of a light source orany foreign object.5.7 Printers as the Payment Method5.7.1 General Statement. Payment by voucher printer as a method of creditredemption is only permissible when:a) The Player Terminal is linked to a computerized system, which allows validationof the printed voucher. Validation approval or information shall come from thecentral system in order to validate vouchers. Vouchers may be validated at anylocation, as long as it meets the standards in this section. Provisions must bemade if communication is lost and validation information cannot be sent to thecentral system, thereby requiring the manufacturer to have an alternate method ofpayment. The validation system must be able to identify duplicate vouchers toprevent fraud by reprinting and redeeming a voucher that was previously issuedby the Player Terminal; orChapter Five - Player Terminal Requirements Page 43 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) By use of an approved alternative method that includes the ability to identifyduplicate vouchers to prevent fraud by reprinting and redeeming a voucher thatwas previously issued by the Player Terminal.5.7.2 Payment by Voucher Printer. The printer shall print on a voucher and providethe data to an on-line data system that records the following information regarding eachpayout voucher printed. The information listed below can be obtained from the PlayerTerminal, interface board, the on-line data management system, or another means:a) Value of credits in local monetary units in numerical form;b) Time of day the voucher was printed in twenty-four (24) hour format showinghours and minutes – printing of this information is not required, provided thatstorage of this information is in the database;c) Date, in any recognized format, indicating the day, month, and year;d) Player Terminal number or machine number; ande) Unique Validation Number, or barcode.NOTE: To meet this standard, the Player Terminal shall either keep a duplicate copy orprint only one (1) copy to the player but have the ability to retain the last thirty-five (35)vouchers printed information to resolve player disputes. In addition, an approved systemshall be used to validate the payout voucher, and the voucher information on the centralsystem shall be retained at least as long as the voucher is valid at that location.5.7.3 Taxation Limit. If the taxation limit is reached on any single play when using avoucher printer, then the voucher must not be able to be redeemed at any place other thanthrough human interaction (not on another machine or at a self-serve Kiosk).5.7.4 Printer Location. If a Player Terminal is equipped with a printer, it shall belocated in a locked area of the Player Terminal (e.g., require opening of the main door toaccess), but not in the logic area or the drop box. This requirement ensures that changingthe paper does not require access to the drop (cash) or logic areas.Chapter Five - Player Terminal Requirements Page 44 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.7.5 Error Conditions. A printer shall have mechanisms to allow software to interpretand act upon the following conditions:a) Out of paper/paper low;b) Printer jam/failure; andc) Printer disconnected, it is permissible to detect a disconnection when the softwaretries to print or at any other time.NOTE: These conditions shall trigger an error condition to indicate the error hasoccurred see also ‘Error Conditions,’ Section 5.12, of this standard.5.8 Program Storage Device Requirements5.8.1 Requirements for Program Storage Devices. All Program Storage Devices,including EPROMs, DVD, CD-ROM, Compact Flash and any other type of ProgramStorage Devices shall:a) be clearly marked with sufficient information to identify the software and revisionlevel of the information stored in the devices and shall only be accessible withaccess to the locked logic compartment.b) Perform an integrity check (authentication) of the Critical Files or Program Codethat operate the Player Terminal during:i. Any power-up; andii. The first time the files or program code are loaded for use (even if onlypartially loaded).NOTE: RAM and PSD space that is not critical to machine security (e.g., videoor sound ROM) are not required to be validated. Although GLI recommends amethod be in place for the files to be tested for corruption. If any of the video orsound files contain payout amounts or other information needed by the player theChapter Five - Player Terminal Requirements Page 45 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>files or program storage must have a secure method of verification, also seeSoftware Verification.c) The program residing in the Player Terminal shall be contained in a storagemedium, which cannot be altered through use of the circuitry or programming ofthe Player Terminal itself.d) Is housed within a locked logic compartment; ande) Meets the Software Verification requirements in Section 4.8 of this document.5.8.2 Write Once (Non-Writable) Program Storage. For Program Storage Devices thatis written to once (i.e., EPROM, CD), the following rules shall be met:a) CD-ROM specific based Program Storage shall:i. Not be a re-writeable disk; andii. The “Session” shall be closed to prevent any further writing.b) Non-EPROM specific (including CD-ROM) Program Storage shall meet thefollowing rules:i. The Control Program shall authenticate all Critical Files by employing ahashing algorithm which produces a ‘Message Digest’ output of at least 128bits at minimum, as certified by the test laboratory and agreed upon by thejurisdiction. The Message Digest(s) shall be stored on a memory device(ROM-based or other medium) within the Player Terminal. Message Digestswhich reside on any other medium shall be encrypted, using a public/privatekey algorithm with a minimum of a 512 bit key. However, a 768 bit key isrecommended, or an equivalent encryption algorithm with similar securitycertified by the test laboratory and agreed upon by the jurisdiction.NOTE: For international jurisdictions, the minimum values outlined withinthis section may be substituted for the minimum values that would beapplicable for that location.Chapter Five - Player Terminal Requirements Page 46 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>ii. The Player Terminal shall authenticate all Critical Files against the storedMessage Digest(s), as required in (i), above. In the event of a failedauthentication, after the game has been powered up, the Player Terminalshould immediately enter an error condition with the appropriate tower lightsignal and record the details including time and date of the error in a log.This error shall require operator intervention to clear. The game shall displayspecific error information and shall not clear until either the file authenticatesproperly, following the operator intervention, or the medium is replaced orcorrected, and the device’s memory is cleared, the game is restarted, and allfiles authenticate correctly.NOTE: the values in (i) and (ii), above will constantly be re-evaluated based ontechnology advancements and new security methods available.5.8.3 Writable Program Storage. The program residing in the Player Terminal that iscapable of being erased and re-programmed without being removed from the PlayerTerminal, bill changer or other equipment or related device shall meet the belowrequirements:a) Re-programmable Program Storage shall only write to alterable storage mediacontaining data, files, and programs that are not critical to the basic operation ofthe game, such as marketing information. Notwithstanding the foregoing, suchdevice may write to media containing critical data, files, and programs providedthat the gaming equipment:i. It is recommended that a log of all information that is added, deleted, andmodified be stored on the media;ii. Verifies the validity of all data, files, and programs which reside on the mediausing the methods listed in Section 5.8.2(b), above.iii. Contains appropriate security to prevent unauthorized modifications; andChapter Five - Player Terminal Requirements Page 47 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>iv. Does not allow game play while the media containing the critical data, files,and programs is in a modifiable state.NOTE: If the program storage does not comply with any of the aboverequirements and is a Hard Disk, the media is permissible provided a writeprotecteddrive is used. SCSI Devices are preferred, as they provide a writeprotect jumper which can be sealed in place by the regulating body. Any othertype of drive will have the write line cut and verified in the field and any othermeans of write protection will be examined on a case-by-case basis.5.9 Critical RAM Requirements5.9.1 Comprehensive Memory Checks. Comprehensive checks of Critical Memoryshall be made during each Player Terminal restart (e.g., power-up cycle). The PlayerTerminal Control Program shall test for possible corruption of Critical Memory. Testmethodology shall detect 99.99 percent of all possible failures.5.9.2 Unrecoverable Critical Memory. An uncorrectable corruption of RAM shallresult in a RAM error. The RAM should not be cleared automatically, but shall require afull RAM clear (RAM Reset) performed by an authorized person.5.9.3 Function of RAM Reset. Following the initiation of a RAM reset procedure(utilizing a certified RAM Clear method), each bit in RAM must be set to the defaultstate. For games that allow for partial RAM clears, the methodology in doing so must beaccurate and the game must validate the un-cleared portions of RAM.5.10 Rules of PlayChapter Five - Player Terminal Requirements Page 48 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.10.1 General Statement. Payglasses or video displays (help screens) shall be clearlyidentified and shall accurately state the rules of the game and the award that will be paidto the player when the player obtains a specific win and include the following:a) Designation of Awards. The payglasses or video displays shall clearly indicatewhether awards are designated in denominational units, currency, or some otherunit.b) Display of Game Play. Unless otherwise denoted on the payglass, where thePlayer Terminal displays the game outcome in a form other than the standard<strong>Bingo</strong> card format all winning symbol patterns and their correlation to winningcard patters must be clearly displayed.c) Change in Award Value. The Player Terminal shall reflect any change in awardvalue, which may occur in the course of play. This may be accomplished with adigital display in a conspicuous location to the Player Terminal, and the gamemust clearly indicate such.d) Access to Paytable Information. All paytable information should be able to beaccessed by a player, prior to them committing to a bet. Payglasses or videodisplays shall not be certified if the information is inaccurate or may causeconfusion. The “reasonable player” standard shall be used for evaluation;e) Upcoming wins. The game shall not advertise ‘upcoming wins,’ unless thisadvertisement has been approved by the NIGC (i.e., three (3) times pay comingsoon.)f) Information to be Displayed. A Player Terminal shall display, or shall havedisplayed on the glass, the following information to the player at all times themachine is available for player input:i. The player’s current credit balance;ii. The current bet amount. This is only during the base game or if the player canadd to the bet during the game;Chapter Five - Player Terminal Requirements Page 49 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>iii. All possible winning outcomes or be available as a menu item or on the helpmenu;iv. Win amounts for each possible winning outcome or be available as a menu orhelp screen item;v. The amount won for the last completed game (until the next game starts orbetting options are modified); andvi. The player options selected (e.g., bet amount, lines played) for the lastcompleted game (until the next game starts or a new selection is made).5.11 Metering5.11.1 Credit Meter Units and Display. The credit meter shall be maintained in creditsor cash value (i.e. applicable local currency).5.11.2 Credit Meter – Incrementing. The value of every prize (at end of game) shall beadded to the player’s credit meter, except all handpays or merchandise.5.11.3 Progressives. Progressives may be added to the credit meter if either:a) The credit meter is maintained in the local currency amount; orb) The progressive meter is incremented to whole credit amounts; orc) The prize in the local currency amount is converted to credits on transfer to theplayer’s credit meter in a manner that does not mislead the player (i.e., makeunqualified statement “wins meter amount” and then rounds down on conversion)or cause accounting imbalances; andd) If the prize does not exceed the local taxation limit.5.11.4 Collect Meter. There shall be the facility for a collect meter which will show thenumber of credits or cash collected by the player (the number of credits or cash collectedshall be subtracted from the player’s credit meter and added to the collect meter).Chapter Five - Player Terminal Requirements Page 50 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.11.5 Software Meter Information Access. The software meter information shall beaccessible by an authorized person.5.11.6 <strong>Electronic</strong> Accounting and Occurrence Meters. Each Player Terminal shall haveelectronic accounting meters that are at least eight (8) digits in length. If the meter isbeing used in dollars and cents, at least eight (8) digits must be used for the dollaramount. The meter must roll over to zero upon the next occurrence, any time the meter iseight (8) digits or higher and after 99,999,999 has been reached or any other value that islogical. Occurrence meters shall be at least three (3) digits in length and roll over to zeroupon the next occurrence, any time the meter is higher that the maximum number ofdigits for that meter. The required electronic meters are as follows (accounting meters aredesignated with an asterisk ‘*’):a) The amounts-in* (OR cash-in) meter shall cumulatively count the total amountswagered during game play.b) The amounts-out* (OR credit-out) meter shall cumulatively count all amountsdirectly paid by the Player Terminal (not paid by an attendant) as a result ofwinning wagers, whether the payout is made from the hopper, ticket printer, to acredit meter or by any other means. This meter must not increment for billsinserted and cashed out (used as a change machine).c) The drop* meter shall maintain a cumulative count of the number of coins thathave been diverted into a drop bucket and credit value of all bills andvouchers/coupons inserted into the bill acceptor for play.NOTE: It is acceptable to have separate ‘drop’ meters for coins, bills, vouchersand coupons.d) The jackpots* meter shall reflect the cumulative amounts paid by an attendant forprogressive and non-progressive handpays.e) The games-played meter shall display the cumulative number of games playedsince the last RAM clear.Chapter Five - Player Terminal Requirements Page 51 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>f) A cabinet door meter shall display the number of times the front cabinet door wasopened since the last RAM clear.g) The drop door meter shall display the number of times the drop door or the billacceptor door was opened since the last RAM clear.h) The cancelled credit* meter shall reflect the cumulative amounts paid by anattendant that are in excess of the credit limit and residual credits that arecollected.NOTE: printer games do not require a cancelled credit meter unless, a ‘printerlimit’ option exists on the game.i) The progressive occurrence meter shall count the number of times eachprogressive meter is activated.5.12 Error Conditions5.12.1 General Statement. Each Player Terminal shall be capable of detecting anddisplaying the following error conditions and illuminate the tower light for each or soundan audible alarm. In addition, the game play on that terminal shall cease. These errorconditions shall be cleared by an attendant, unless otherwise noted, and be communicatedto an on-line monitoring and control system, if applicable:a) Coin-in jam;b) Coin-out jam;c) Hopper empty or timed out;d) Hopper runaway or extra Coin paid out, see also ‘Hoppers as a Payment Method,’Section 5.6;e) RAM error;f) Low RAM battery, for batteries external to the RAM itself or low power source;g) Currency-in jam;h) Program error or authentication mismatch;i) Door open (including bill acceptor);Chapter Five - Player Terminal Requirements Page 52 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>j) Reverse coin-in (coin traveling wrong way through acceptor);k) Microprocessor controlled mechanical device errors (i.e., Reels or Wheels orother top box/bonus feature or game display unit). This includes a mis-indexcondition that would affect the outcome of the game, and:i. The specific reel number shall be identified in the error code, if applicable;ii. In the final positioning of the mechanical device, if the position error exceedsone-half of the width of the smallest symbol excluding blanks on the reelstrip; andiii. Be monitored to detect malfunctions such as a reel that is jammed, or is notspinning freely, loss of communications with the game, or any attempt tomanipulate their final resting position.l) Power reset – This error condition does not require an attendant to clear.NOTE: This rule also applies to the ‘Bill Acceptor Error Conditions’ and the ‘PrinterError Conditions’ of this standard.5.12.2 Error Condition Explanation. For games that use error codes, an explanation oftheir meanings shall be affixed inside the Player Terminal. This does not apply to videobasedgames; however, video based games shall display meaningful text describing theerror condition(s).5.13 Program Interruption & Resumption5.13.1 Interruption. After a program interruption (e.g., power down), the software shallbe able to recover to the state it was in immediately prior to the interruption occurring,provided there is no advantage or disadvantage to the player(s).Chapter Five - Player Terminal Requirements Page 53 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.13.2 Restoring Power. If a Player Terminal is powered down while in an errorcondition, then upon restoring power, the error message shall be displayed and the PlayerTerminal shall remain locked-up. That is unless power-down is used as part of the errorreset procedure, or if on power-up or door closure, the Player Terminal checks for theerror condition and detects that the error is no longer in existence.5.13.3 Simultaneous Inputs. The program shall not be adversely affected by thesimultaneous or sequential activation of the various inputs and outputs, such as 'playbuttons', which might, whether intentionally or not, cause malfunctions or invalid results.5.13.4 Resumption. On program resumption, the following procedures shall beperformed as a minimum requirement:a) Any communications to an external device shall not begin until the programresumption routine, including self-tests, is completed successfully;b) Player Terminal control programs shall test themselves for possible corruptiondue to failure of the program storage media. The authentication may use thechecksum; however, it is preferred that the Cyclic Redundancy Check (CRC)calculations are used as a minimum (at least 16 bit). Other test methodologiesshall be of a certified type;c) The integrity of all critical memory shall be checked;d) Shall meet the rules outlined in Interruption, above.5.14 Door Open/Close5.14.1 Door Metering. The software shall be able to detect and meter access to thefollowing doors or secure areas:a) All external doors;Chapter Five - Player Terminal Requirements Page 54 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>b) Drop box door;c) Bill acceptor door; andd) Logic board compartment, if applicable.5.14.2 Door Open Procedures. When the Player Terminal’s main door is opened, thegame shall cease play, enter an error condition, display an appropriate error message,disable coin acceptance and bill acceptance, and either sound an alarm or illuminate thetower light or both.5.14.3 Door Close Procedures. When the Player Terminal’s main door is closed, thegame shall return to its original state* and display an appropriate error message, until thenext game has ended.*NOTE: The game shall return to its original state provided there is no advantage ordisadvantage to the player(s).5.15 Taxation Reporting Limits5.15.1 General Statement. If the game results in a single win amount that is equal to orgreater than the Taxation Limit, the game shall lock-up and no further play be permitteduntil manually reset by an attendant.5.16 Test/Diagnostic Mode5.16.1 General Statement. If in a test mode, any test that incorporates credits entering orleaving the Player Terminal (e.g., a hopper test) shall be completed on resumption ofnormal operation. In addition, there shall not be any test mode that increments any of theelectronic meters. Any credits on the Player Terminal that were accrued during the testmode shall be cleared before the test mode is exited. Test meters are permissible providedthe meter indicates as such.Chapter Five - Player Terminal Requirements Page 55 of 56


GLI Standard #22 June 22, 2004<strong>Class</strong> <strong>II</strong> <strong>Electronic</strong> <strong>Bingo</strong> <strong>Systems</strong>5.16.2 Entry to Test/Diagnostics Mode. The main cabinet door of the Player Terminalmay automatically place the Player Terminal in a service or test-mode. Test/diagnosticsmodemay also be entered via an appropriate instruction from an attendant during anaudit mode access.5.16.3 Exiting From Test/Diagnostic Mode. When exiting from test mode, the gameshall return to the original state* it was in when the test mode was entered.*NOTE: The game shall return to its original state provided there is no advantage ordisadvantage to the player(s).5.16.4 Test Games. If the Player Terminal is in a game test mode, the Terminal shallclearly indicate that it is in a test mode, not normal play. In addition, the system shall notsee the device as a participating Player Terminal.5.17 Last Game Recall5.17.1 Number Of Last Plays Required. Information on at least the last five (5) gamesis to be always retrievable on the operation of a suitable external key-switch or anothersecure method that is not available to the player.5.17.2 Last Play Information Required. Last play information shall provide allinformation required to fully reconstruct the last five (5) games. All values shall bedisplayed, including the initial credits, credits bet, credits won, and credits paid. If aprogressive was awarded, it is sufficient to indicate the progressive was awarded and notdisplay the value. This information should include the final game outcome.Chapter Five - Player Terminal Requirements Page 56 of 56

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!