National Indian Gaming Commission (NIGC or “Commission”).
The proposed rule would add a new part to the Commission's regulations establishing technical standards for Class II games—bingo, lotto, other games similar to bingo, pull tabs, or “instant bingo”—that are played primarily through “electronic, computer, or other technologic aids.” The proposed rule would also establish a process for assuring the integrity of such games and aids before their placement in a Class II tribal gaming operation. No such standards currently exist. The Commission proposes this action in order to assist tribal gaming regulatory authorities and operators in ensuring the integrity and security of Class II games and gaming revenue.
Submit comments on or before September 30, 2006.
Mail comments to “Comments on Technical Standards,” National Indian Gaming Commission, 1441 L Street, NW., Washington, DC 20005, Attn: Michael Gross, Senior Attorney. Comments may be transmitted by facsimile to 202-632-0045, but the original also must be mailed or submitted to the above address. Comments may be sent electronically, instead of by mail or fax, to email@example.com. Please indicate “Class II technical regulations” in the subject line.Start Further Info
FOR FURTHER INFORMATION CONTACT:
Michael Gross, Senior Attorney, Office of General Counsel, telephone: 202.632.7003. This is not a toll free call.End Further Info End Preamble Start Supplemental Information
The Indian Gaming Regulatory Act, 25 U.S.C. 2701-21 (“IGRA”), enacted by the Congress in 1988, establishes the National Indian Gaming Commission (“NIGC” or “Commission”) and sets out a comprehensive framework for the regulation of gaming on Indian lands. The Act establishes three classes of Indian gaming.
- “Class I gaming” means social games played solely for prizes of minimal value or traditional forms of Indian gaming played in connection with tribal ceremonies or celebrations. 25 U.S.C. 2703(6). Indian tribes regulate Class I gaming exclusively.
- “Class II gaming” means the game of chance commonly known as bingo, whether or not electronic, computer, or other technologic aids are used in connection therewith, including, if played in the same location, pull-tabs, lotto, punch boards, tip jars, instant bingo, and other games similar to bingo, as well as various non-house banked card games. 25 U.S.C. 2703(7)(A). Specifically excluded from Class II gaming are banking card games such as blackjack, electronic or electromechanical facsimiles of any game of chance, and slot machines of any kind. 25 U.S.C. 2703(7)(B). Indian tribes and the NIGC share regulatory authority over Class II gaming. Indian tribes can engage in Class II gaming without any state involvement.
- “Class III gaming” includes all forms of gaming that are not Class I gaming or Class II gaming. 25 U.S.C. 2703(8). Class III gaming thus includes all other games of chance, including lotteries and most forms of casino gaming, such as slot machines, roulette, and banking card games like blackjack. Class III gaming may be conducted lawfully only if the tribe and the state in which the tribe is located enter into a tribal-state compact for such gaming. Alternatively, a tribe may operate Class III gaming under gaming procedures issued by the Secretary of the Interior. Because of the compact requirement, states, Indian tribes, and the NIGC possess regulatory authority over Class III gaming. In addition, the United States Department of Justice and United States Attorneys possess exclusive criminal, and certain civil, jurisdiction over Class III gaming on Indian lands.
The Commission has determined that it is in the best interests of Indian gaming to adopt technical standards that govern the implementation of electronic, computer, and other technologic aids used in the play of Class II games because no such standards currently exist. The technical standards seek to provide a means for tribal gaming regulatory authorities and tribal operators to ensure that the integrity of Class II games played with the use of electronic, computer, or other technologic aids is maintained; that the games and aids are secure; and that the games and aids are fully auditable, i.e. that they provide a means for the gaming authority and gaming operation to account for all gaming revenue.
Development of the Proposed Rule Through Consultation With Indian Tribes
In recognition of tribal sovereignty and the fundamental importance of standards to the operation and regulation of gaming on Indian lands under IGRA, the Commission developed a policy and process for consultation with Indian tribes that would provide opportunity for early and meaningful tribal input regarding formulation of these proposed regulations.
In particular, while initially advising tribes of the Commission's intention to develop standards, the Commission also actively consulted with tribes regarding formulation of the Commission's first-ever official Government-to-Government Tribal Consultation Policy. After several months of consultation with tribes, the Commission's official Tribal Consultation Policy was adopted and published in the Federal Register on March 31, 2004 (69 FR 16973). The Commission purposely established this policy in order to have consultation policy guidelines in place for meaningful pre-rulemaking tribal consultation on these standards and other planned Commission rulemaking initiatives.
The Commission's official Tribal Consultation Policy expressly calls for the Commission, to the extent practicable and permitted by law, to engage in regular, timely, and meaningful government-to-government consultation with Indian Tribes when formulating proposed new or revised administrative regulations that may substantially affect the operation or regulation of gaming on Indian lands. To fulfill this policy commitment, the Commission devised a three-part plan to afford tribes a reasonable and practicable opportunity to consult with the Commission and to provide early input in formulation of regulations, before they were published as proposed new rules in the Federal Register and the actual rule-making process began.
First, the Commission endeavored to consult in person at least twice with each gaming tribe between May 2003 and March 2006 regarding development of these, and other, proposed regulations. During this time period, the Commission sent out over 500 separate invitations to individual tribes to consult with the Commission and provide input. Many tribes accepted and participated in separate government-to-government consultation meetings with the Commission regarding the proposed regulations and other matters. While some tribes declined the Commission's invitations, between May 2003 and Start Printed Page 46337March 2006 the Commission conducted over 300 separate government-to-government consultation meetings with individual tribes and their leaders or representatives.
Second, the Commission established a joint Federal-Tribal Advisory Committee on March 31, 2004, composed of both Commission and tribal representatives to assist the Commission in formulating these regulations. In January 2004, the Commission requested all gaming tribes across the country to nominate tribal representatives to serve on this Advisory Committee. From the tribal nominations received, the Commission selected the following seven tribal representatives on March 31, 2004: Norm Des Rosiers, Gaming Commissioner, Viejas Band of Kumeyaay Indians; Joseph Carlini, Gaming Commission Executive Director, Agua Caliente Band of Cahuilla Indians; Kenneth Ermatinger, Gaming Commission Executive Director, Sault Ste. Marie Tribe of Chippewa Indians of Michigan; Jamie Hummingbird, Gaming Commission Director, Cherokee Nation, Oklahoma; Mark Garrow, Gaming Commission Inspections Manager, St. Regis Mohawk Tribe; Melvin Daniels, General Manager, Muckleshoot Indian Bingo, Muckleshoot Indian Tribe; Charles Lombardo, Senior Vice-President for Gaming Operations, Seminole Tribe of Florida.
To date, the Advisory Committee has held six (6) meetings: May 13, 2004 in Washington, DC; August 2-3, 2004, Washington, DC; September 13-14, 2004, Cherokee, North Carolina; December 1-3, 2004, Oklahoma City, Oklahoma; January 12-13, 2005, Palm Springs, California; and March 11, 2005, Chicago, Illinois. During these committee meetings, all of which were open to the public, the committee discussed the various characteristics of Class II and Class III games of chance, their play, and related gaming technology and methods. In addition, the committee discussed, reviewed, critiqued and commented on 2 different, successive preliminary working drafts of the proposed Class II technical standards prepared by the Commission representatives on the Committee. The seven tribal committee representatives provided early tribal input and valuable insight, advice, and assistance to the Commission in developing each of the respective working drafts, as well as the current proposed regulations.
The Commission's establishment of the joint Federal-Tribal advisory committee was the subject of a legal challenge while the Commission was preparing the proposed rule for publication. On March 10, 2005, nearly one year after the Commission established the committee, the Confederated Salish and Kootenai Tribes of the Flathead Nation and the Santa Rosa Rancheria Indian Community filed suit against the Commission alleging, among other things, that several of the committee members were not eligible to participate on the committee. Following a hearing in Federal court, at which the request for temporary restraining order was denied, the Commission determined that it should proceed to publish the proposed rule for comment while the legal standing of the committee was further litigated. The Commission also sought clarification from those tribes nominating the committee members concerning the member's role as an official representative of the tribe. As a result of this clarification, and, out of an abundance of caution, the Commission regretfully requested that two members of the Committee step down.
The third component of the Commission's effort to consult with tribes during the pre-rulemaking formulation phase of these proposed regulations was to make the various preliminary working drafts of the proposed regulations available to all tribes and their leaders for review and comment, independent of the joint federal-tribal Advisory Committee. In particular, while these proposed regulations were being formulated, the first and second preliminary working drafts were mailed to each tribe and its leaders, inviting written comment. The drafts were also posted on the Commission's website for review and comment by all. Many tribes and members of the public submitted written comments on these respective working drafts. The tribal comments were shared with the members of the Advisory Committee for their review and carefully considered by the Commission in formulating these proposed regulations.
In addition, the Gaming Standards Association, a casino-industry group comprised of game manufacturers and operators, and the National Indian Gaming Association, the largest Indian gaming trade group, assembled a meeting on December 16, 2004, in Las Vegas, Nevada, so that interested members of both organizations could review the technical standards and provide suggestions to the Commission. The Commission was invited, and it sent a staff member to listen to the discussion and to answer questions, if necessary.
Beyond all of this, the Commission attended and addressed several different assemblies of tribal leaders and tribal gaming operators and regulators at meetings and conferences organized by state and regional tribal gaming associations, the National Indian Gaming Association, and the National Congress of American Indians between January 2003 and March 2005. At these meetings and conferences, the Commission advised tribal leaders of its intention and plan to develop these regulations and provided periodic updates regarding the progress and status of the regulations development. The Commission also made itself available at these meetings to answer any questions from tribal leaders regarding the proposed regulations or their formulation.
Through each of these various means, the Commission actively endeavored to provide all tribes with a reasonable and practical opportunity over the past 26 months to meet and consult with the Commission on a government-to-government basis and provide early and meaningful tribal input regarding the formulation and implementation of these proposed regulations.
Purpose and Scope
The proposed Part 547 applies to Class II games played primarily through electronic, computer, or other technologic aids, or modifications of such games and aids. It does not apply to live session bingo. Class II games played through such technologic aids are widely used in Indian gaming operations, yet no uniform standards exist to govern their implementation. The proposed rule seeks to remedy that absence and establish technical standards for such games and aids.
Again, the technical standards seek to provide a means for tribal gaming regulatory authorities and tribal operators to ensure that the integrity of Class II games played with the use of electronic, computer, or other technologic aids, is maintained; that the games and aids are secure; and that the games and aids are fully auditable. In so doing, the technical standards are modeled, when appropriate, on similar standards from experienced gaming jurisdictions not only in North America but around the world. The requirements for game accounting meters, for example, are modeled on Nevada's requirements.
There are, however, unique aspects of Class II gaming for which few models now exist, and none existed at the time the Commission began this project. Bingo, as IGRA defines it, is a multiple-player game in which players compete against one another to be the first to cover a predetermined pattern of Start Printed Page 46338numbers or other designations. In order to meet IGRA's statutory requirements, electronic bingo implementations must allow multiple players in different locations, whether in one facility or in more than one, to play a common game. Manufacturers, therefore, have implemented bingo on client-server architectures. A common arrangement, but by no means the only one possible, is to have client machines on the casino floor as electronic player stations. These display bingo cards, allow the players to cover numbers when drawn, and pay any prizes won. The server, usually located off the floor, draws random numbers and passes them, along data communications lines, to the client machines for game play. Such client-server arrangements are not common in other gaming jurisdictions, and they produce regulatory challenges with which most other gaming jurisdictions have not fully grappled.
Chief among these challenges is securing games from unauthorized changes or tampering. In a stand-alone Class III slot machine, for example, the game software is typically located within the game cabinet itself, and there are many, well-established technical means for securing the software. In client-server implementations, by contrast, game software may be downloaded from the server to clients, or game software may exist simultaneously on clients and servers, with the clients acting as terminals receiving game information transmitted across data communication lines from the server. In either case, the well-established means of securing Class III game software may not be adequate.
The proposed rule therefore implements minimum standards for mechanisms that can be used to verify the authenticity of game software, whether located on servers or clients or both, as well as minimum standards for when verification must occur and when, and by whom, games may be downloaded or changed. The proposed rule also provides general, minimum technical standards for servers, for clients, and standards common to both clients and servers, and it provides minimum standards for software storage media, money and credit handling, and data communications, all of which may require different treatment when using clients and servers rather than stand-alone games.
That said, the proposed rule provides only minimum standards. Tribes and tribal gaming regulatory authorities may add any additional requirements, or more stringent requirements, needed to suit their particular circumstances. In addition, the proposed rule makes no attempt to foreclose the implementation of new technologies.
In order to ensure compliance with the technical standards, the proposed rule borrows again from the established practices of tribal, state, and provincial gaming jurisdictions across North America. The proposed rule establishes, as a necessary prerequisite to a game and aid being offered to the public for play in a Class II gaming operation, a process of game submission by the manufacturer; review and analysis by a qualified, independent testing laboratory; and approval by the tribal gaming regulatory authority.
Under the proposed rule, a tribe's gaming regulatory authority will require all Class II games and aids, or modifications of such games and aids, to be submitted by the manufacturer to a testing laboratory for review and analysis. That submission includes a working prototype of the game and aid, all pertinent software, and the complete documentation and description of all functions and components. In turn, the laboratory will certify that the game or aids do or do not meet the requirements of the proposed rule, as well as any additional requirements adopted by the tribe's gaming regulatory authority. The laboratory will provide a written certification and report of its analysis and conclusions to the tribal gaming regulatory authority for its approval or disapproval of the game or aid. The tribal gaming regulatory authority will retain the certification and report as long as the game remains available to the public for play on the casino floor. This will allow the commission to perform its regulatory oversight role.
Finally, the Commission is cognizant of existing standards under the Minimum Internal Control Standards (MICS), 25 CFR part 542, some of which address equipment or technical issues. The proposed rule and the MICS therefore have small areas of overlap. The Commission does not intend by the proposed rule to alter or repeal part 542, and relevant parts of the proposed rule so state.
Regulatory Flexibility Act
This proposed rule will not have a significant economic effect on a substantial number of small entities as defined under the Regulatory Flexibility Act, 5 U.S.C. 601 et seq. Indian tribes are not considered to be small entities for the purposes of the Regulatory Flexibility Act.
Small Business Regulatory Enforcement Fairness Act
This proposed rule is not a major rule under 5 U.S.C. 804(2), the Small Business Regulatory Enforcement Fairness Act. This rule does not have an annual effect on the economy of $100 million or more. This rule will not cause a major increase in costs or prices for consumers, individual industries, Federal, state or local government agencies or geographic regions and does not have a significant adverse effect on competition, employment, investment, productivity, innovation, or the ability of U.S.-based enterprises to compete with foreign-based enterprises. The Commission believes that the requirement for examination and testing by an independent testing lab will add only limited additional expense to Indian casinos operating Class II games and aids. The Commission has been informed that operations already do this as a matter of course. Likewise, the Commission does not anticipate significant additional costs for redesign and repurchase of Class II games and aids. Many manufacturers who sell Class II games and equipment are already building to similar standards for the machines they sell in Class III and non-Indian casino markets. Moreover, feedback from manufacturers to date indicates industry support for these standards.
Unfunded Mandates Reform Act
For these reasons as well, the Commission has determined that this proposed rule does not impose an unfunded mandate on state, local, or tribal governments or on the private sector of more than $100 million per year. Thus, it is not a “significant regulatory action” under the Unfunded Mandates Reform Act, 2 U.S.C. 1501 et seq. The Commission has determined that this proposed rule may have a unique effect on tribal governments, as this rule applies to tribal governments, whenever they undertake the ownership, operation, regulation, or licensing of gaming facilities on Indian lands as defined by the Indian Gaming Regulatory Act. Thus, in accordance with section 203 of the Unfunded Mandates Reform Act, the Commission implemented a small government agency plan that provides tribal governments with adequate notice, opportunity for meaningful consultation, and information, advice, and education on compliance.
Again, the Commission's plan included the formation of a tribal advisory committee and request for input from tribal leaders through Start Printed Page 46339government-to-government consultations and through written comments to draft regulations that are provided to the tribes. Section 204(b) of the Unfunded Mandates Reform Act exempts from the Federal Advisory Committee Act (5 U.S.C. App.) meetings with tribal elected officials (or their designees) for the purpose of exchanging views, information, and advice concerning the implementation of intergovernmental responsibilities or administration. In selecting Committee members, consideration was placed on the applicant's experience in this area, as well as the size of the tribe the nominee represented, geographic location of the gaming operation, and the size and type of gaming conducted. The Commission attempted to assemble a committee that incorporated diversity and was representative of tribal gaming interests. The Commission will meet with the Advisory Committee to discuss the public comments that are received as a result of the publication of this proposed rule and make recommendations regarding the final rule. The Commission also plans to continue its policy of providing technical assistance, through its field offices, to tribes to assist in complying with issues raised by the proposed rule.
In accordance with Executive Order 12630, the Commission has determined that this proposed rule does not have significant takings implications. A takings implication assessment is not required.
Civil Justice Reform
In accordance with Executive Order 12988, the Office of General Counsel has determined that the proposed rule does not unduly burden the judicial system and meets the requirements of sections 3(a) and 3(b)(2) of the Order.
Paperwork Reduction Act
This proposed rule requires information collection under the Paperwork Reduction Act of 1995, 44 U.S.C. 3501, et seq., and is subject to review by the Office of Management and Budget. The title, description, and respondent categories are discussed below, together with an estimate of the annual information collection burden.
With respect to the following collection of information, the Commission invites comments on: (1) Whether the proposed collection of information is necessary for proper performance of its functions, including whether the information would have practical utility; (2) the accuracy of the Commission's estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including the use of automated collection techniques, when appropriate, and other forms of information technology.
Title: Process for Certification of Electronic, Computer, or other Technologic Aids used in the play of Class II games, proposed 25 CFR 547.4.
Summary of information and description of need: This provision in the proposed rule establishes a process for assuring that electronic, computer, or other technologic aids used with the play of Class II games have been reviewed and evaluated by a qualified, independent testing laboratory prior to their approval by a tribal gaming regulatory authority and their placement on the floor in a Class II tribal gaming operation. The process helps to ensure the proper functioning of the equipment and the integrity, fairness, and auditability of games played.
The process requires a tribe's gaming regulatory authority to require that all Class II games played primarily through electronic, computer, or other technologic aids, or modifications of such games and aids, be submitted by the manufacturer to a qualified, independent testing laboratory for review and analysis. That submission includes a working prototype of the game and aid, all pertinent software, and complete documentation and descriptions of all functions and components. In turn, the laboratory will certify that the game or aids do or do not meet the requirements of the proposed rule and any additional requirements adopted by the tribe's gaming regulatory authority. The laboratory will provide a written certification and report of its analysis and conclusions to the tribal gaming regulatory authority for its approval or disapproval of the game or aid.
This process is necessary to ensure the fairness and integrity of Class II gaming. Technical standards such as those in the proposed rule are a fundamental part of Class III gaming and of non-Indian casino gaming throughout North America. No uniform standards exist for Class II gaming, however. The implementation of such standards will assist tribal gaming regulators in ensuring that games are implemented fairly, that all technologic aids are secure and function properly, and that the games and aids allow the tribe and the operator to properly account for gaming revenue.
Respondents: The respondents are independent testing laboratories and developers and manufacturers of Class II games and technologic aids. The Commission estimates that there are 20 such manufacturers and 5 such laboratories. The frequency of responses to the information collection requirement will vary.
During the first 6 to 12 months after adoption of the proposed rule, all existing games or aids in Class II operations that fall within the rule must be submitted and reviewed if they are to continue in Class II operations. Following that period, the frequency of responses will be a function of the Class II market and the need or desire for new games and aids. Thus, the Commission estimates that the frequency of responses will range over an initial period of frequent submissions, settling down into infrequent and occasional submissions during periods when there are a few games, aids, or modifications brought to market, punctuated by fairly steady periods of submissions when new games and aids are introduced. The Commission estimates that submission will number approximately 150 during the first year after adoption and approximately 75 per year thereafter.
Information Collection Burden: The preparation and submission of documentation supporting submissions by developers and manufacturers (as opposed to the game or aid hardware and software per se) is an information collection burden under the Paperwork Reduction Act, as is the preparation of certifications and reports of analyses by the laboratories. The amount of documentation or size of a laboratory certification and report is a function of the complexity of the game, equipment, or software submitted for review. Minor modifications of software or hardware that a manufacturer has already submitted and that a laboratory has previously examined is a matter of little time both for manufacturer and laboratory, while the submission and review of an entirely new game platform is time consuming.
The practice of submission and review set out in the proposed rule, however, is not new. It is already part of the regulatory requirements in tribal, state, and provincial gaming jurisdictions throughout North America and the world. Manufacturers already have significant compliance personnel and infrastructure in place, and the very existence of private, independent laboratories is due to these requirements. Start Printed Page 46340
Accordingly, the Commission estimates that gathering and preparing documentation for a single submission requires, on average, eight hours of an employee's time for a manufacturer. The Commission also estimates that following examination and analysis, writing a report and certification requires, on average, 12.5 hours of an employee's time for a laboratory. The Commission estimates that the information collection requirements in the proposed rule will be a 1200-hour burden on manufacturers during the first year after adoption and a 600-hour burden thereafter. The Commission estimates that the information collection requirements in the proposed rule will be a 1875-hour burden on laboratories during the first year after adoption and a 940-hour burden thereafter. The following table summarizes:
|Provision||Respondents||Number of respondents||Collections, 1st year||Hours per collection||Total hours||Collections, year 2 forward||Hours per collection||Total|
|25 CFR 546.4||Laboratories||5||150||12.5||1875||75||12.5||937.5|
Comments: Pursuant to the Paperwork Reduction Act, 44 U.S.C. 3507(d), the Commission has submitted a copy of this proposed rule to OMB for its review and approval of this information collection. Interested persons are requested to send comment regarding the burden, estimates, or any other aspect of the information collection, including suggestions for reducing the burden (1) directly to the Office of Information and Regulatory Affairs, OMB, Attention: Desk Officer for National Indian Gaming Commission, 725 17th St. NW., Washington DC, 20503, and (2) to Michael Gross, Senior Attorney, National Indian Gaming Commission, 1441 L Street NW., Washington DC 20005.
National Environmental Policy Act
The Commission has determined that this proposed rule does not constitute a major Federal action significantly affecting the quality of the human environment and that no detailed statement is required pursuant to the National Environmental Policy Act of 1969 (42 U.S.C. 4321 et. seq).Start List of Subjects
List of Subjects in 25 CFR Part 547End List of Subjects
For the reasons set forth in the preamble, the Commission proposes to add new 25 CFR part 547 to read as follows:Start Part
PART 547—MINIMUM TECHNICAL STANDARDS FOR GAMING EQUIPMENT USED WITH THE PLAY OF CLASS II GAMES
- What is the purpose of this part?
- How do these regulations affect state jurisdiction?
- What are the definitions for this part?
- How do I comply with this part?
- What are the rules of interpretation and of general application for this part?
- What are the minimum technical standards applicable to servers?
- What are the minimum technical hardware standards applicable to client machines used as Electronic Player Stations?
- What are the minimum technical software standards applicable to client machines used as Electronic Player Stations?
- What are the technical standards applicable to critical memory?
- What are the minimum technical standards for meters?
- What are the minimum standards for Electronic Player Station events?
- What are the minimum technical standards for last game recall?
- What are the minimum technical standards for money and credit handling?
- What are the minimum technical standards applicable both to clients and servers or to client-server implementations generally?
- What are the minimum technical standards for the Formal Application Configuration document and verification tool?
- What are the minimum technical standards for downloading Class II game software, paytables, peripheral software or other Download Packages in client—server implementations?
- What are the minimum technical standards for changing available Class II game software or paytables in client—server implementations?
- What are the minimum technical standards for game program storage media?
- What are the minimum technical standards for random number generation?
- What are the minimum technical standards for data communications?
- What are the minimum technical standards for encryption?
- What are the minimum standards for game artwork, glass, and rules?
- What are the minimum standards for interfacing to a casino monitoring system?
- How does a gaming operation apply for a variance from these standards?
The Indian Gaming Regulatory Act, 25 U.S.C. 2703(7)(A)(i) permits the use of electronic, computer, or other technologic aids in connection with the play of Class II games. This part establishes the minimum technical standards governing the use of such aids.
Nothing in this part shall be construed to grant to a state jurisdiction in Class II gaming or to extend a state's jurisdiction in Class III gaming.
For the purposes of this part, the following definitions apply:
Application, A computer program, or group of programs, that operates on a computer system, including game programs that run on a server or client.
Attract Mode, The period of time on an electronic player station between one play finishing and the next play commencing, or another mode being entered, and displaying features of the game or games available for play.
Audit Mode, The mode where it is possible to view Electronic Player Station meters, statistics, etc. and perform non-player related functions.
Cancel Credit, An action at an Electronic Player Station where some or all of the monetary entitlements of the player are removed and paid to a player after overt action taken by an attendant.
Cashless Account, A file, record, or other database item maintained on a computer system that contains account identification information and a current amount held within the account.
Cashless Transaction, A moement of money to or from a cashless account—often to or from an Electronic Player Station.
Cashless Wagering System, A system that securely maintains records of cashless accounts and caters for a wide range of account transactions, including open, close, PIN registration / modification / resetting, account identification / verification, deposits, Start Printed Page 46341withdrawals, and transfers to and from Electronic Player Stations.
Cashout Request, The mode where the Electronic Player Station dispenses coins, tokens, bills, vouchers, or their equivalents after the patron has pressed collect to redeem credits under a certain value.
CD-ROM, A compact disk which contains fixed data or programs that can only be read by the equipment in which it is inserted.
Chairman, The Chairman of the National Indian Gaming Commission pursuant to the Indian Gaming Regulatory Act, 25 U.S.C. 2701 et seq.
Client, An computer, often an Electronic Player Station, that is controlled through local or wide area network by a master computer known as a server.
Coin Validator, Equipment used to validate coins or tokens placed in an electronic player station.
Commission, The National Indian Gaming Commission.
Communication Protocol, A means or methodology for passing data and other messages between two or more computer components. Typical protocols enable means for communications to continue without loss or corruption of data in the case of errors over the medium with which the data is sent.
Coupon, A voucher or ticket which enables transfer of promotional credits to an Electronic Player Station, whether cashable or playable only.
CPU, The central processing unit of a computer.
Critical Memory, Memory locations storing data specified in § 547.11(a) for an Electronic Player Station.
Critical Memory Clear, The process a service technician goes through to reset the memory of an Electronic Player Station, which configures the Electronic Player Station into the ‘as new' state.
Cycling, Calling the random number generator in order to advance its state rather than to obtain an output.
Data-link Layer, The lowest level of logical, as opposed to physical, communication between two or more computer devices.
Disable (Client), Action taken either by the client or via instruction from the server or other network computer system to disable play and acceptance and payment of coins, tokens, cash, vouchers, or credits, but still permitting maintenance or auditing functions.
Discretionary access controls, The ability to be able to restrict access to computing objects such as files, peripherals, programs on the basis of the privileges associated with a user account Disruption, Any form of mis-operation, component failure, or interference to the Class II gaming equipment.
Download Package, Approved data sent from a Download Server to a client or other component of the technologic aids used in the play of Class II games for such purposes as changing of the device software, loading or selecting a new paytable, changing configuration parameters such as tokenization, changing peripherals software or configuration, or requesting specific information from the device.
Download Server, A computer device that delivers Download Packages or causes Download Packages to be actuated in a secure manner to technologic aids used in the play of Class II games.
Electromagnetic Interference, The physical characteristic of an electronic device to emit electronic noise either into free air, onto the mains power lines, or communication cables.
Electrostatic Discharge, Electrostatic Discharge (see Electrostatic interference).
Electrostatic Interference, The physical property of being able to create electronic interference to a device by either discharging static electricity onto the surface of the unit or via a mains power or communication cable.
Enable (client), An action taken to place the client, generally an Electronic Player Station, in a state where it can conduct gaming and money movement transactions.
Entropy source, A hardware device or software algorithm designed to produce outputs derived from measures of “truly” random events, such as thermal noise.
EPROM, Electrically Programmable Read Only Memory—a storage area which may be filled with data and information, which once written is not modifiable, and which is retained even if there is no power applied to the machine.
Extensible Protocol, A communications protocol which contains a mechanism that can be used to negotiate extensions to the protocol—sometimes called options.
Fault, An event that when detected by an Electronic Player Station causes a discontinuance of game play or other machine functions.
Fault Mode, A mode where the Electronic Player Station has disabled itself, preventing game play or other functions, as a result of a fault condition occurring on the Electronic Player Station.
Flash Memory, A computer chip with a read-only memory that retains its data when the power is turned off and that can be electronically erased and reprogrammed without being removed from the circuit board.
Flash ROM, A flash memory device which contains fixed data or programs that can be read but not written to by the gaming equipment in which it is inserted.
Game Software, The operational program(s) which control the play, display and results of Class II games and played on gaming equipment.
Gaming Equipment, All electrical and mechanical physical components making up the equipment on which Class II games are played.
Hardware, See Gaming Equipment
Hopper, A device used to store and dispense coins.
Idle Mode, The period of time after the completion of the previous game, or before the very first game after a memory reset, until the player begins to select options for the next game.
Initial seeding, Initializing the RNG state
Logic Area, A locked area of gaming equipment that houses electronic components that have the potential to significantly influence the operation of the Electronic Player Station
MAC Filter, An access point that can be configured with filters that accept or reject data on the basis of the sender's Media Access Control (MAC) address. All devices that participate in 802.11a, 802.11b and 802.11g Wireless networks have a unique (MAC) address. The MAC address is present in every frame transmitted over the Wireless network.
Magnetic Interference, A magnetic field which has the potential to affect the operation of an electronic device.
Master Meter, A meter whose value is reset only when a memory reset is performed. This meter represents the total of all updates since the last memory reset.
Meter, A non-volatile variable storing Electronic Player Station audit, accounting, and game play information.
Modification, A new version of existing hardware or software, often consisting of relatively minor or discreet changes, used with the play of Class II games.
Non-cashable credit, Credits given by an operator to a patron as part of a promotion, placed on an electronic player station through a voucher or electronic transfer, and capable of activating play but not being cashed out.
Non-writable storage media, A storage device which contains fixed data or programs that can be read, but not written to, by the gaming equipment in which it is inserted.
Number of RNG states, The number of settings that the RNG state can take on Start Printed Page 46342before returning to the initial state. Also called RNG cycle.
Par Sheet, An information sheet supplied by the equipment or game manufacturer detailing the mathematics and probabilities of a game.
Paytable, The set of prizes available to players for achieving certain outcomes or patterns in the game on offer.
Play of a game, A sequence of actions in the Electronic Player Station initiated by a player through a wagering of credits and terminated when all credits wagered have been lost or all winnings have been transferred to the Electronic Player Station's total wins meter and the player's credit meter.
Printed Circuit Board, The piece of board used to connect together electronic components in a certain manner using tracks and holes to route the signals.
Programmable Logic Device, An electronically configurable integrated circuit, usually used for hardware control purposes.
Progressive Jackpot, An incremental prize that increases by a defined amount, each time a game is played on one of a group of interconnected electronic player stations.
RAM, Random Access Memory.
Random, Passing recognized statistical tests for randomness.
Random Number Generator (RNG), A software module, hardware device or combination of these designed to produce outputs that are random.
Removable/Rewritable storage media, Program or data storage devices that can be removed from the Class II gaming equipment and written to, or rewritten by the gaming equipment or by other equipment designed for that purpose.
Re-seeding, Modifying the state of an RNG using external inputs
Residual Credits, Credits remaining which are less than the value of one coin or token.
RNG algorithm, The coded instructions which step an RNG's state through its cycle and calculate the next output.
RNG cycle, The number of settings that the RNG state can take on before returning to the initial state.
RNG state, RNGs (other than entropy sources) produce outputs by an algorithm which modifies one or more variables through a long sequence. These variables constitute the RNG state.
ROM, Read Only Memory.
Scaling algorithm, The coded instructions which map an random number generator output onto a range desired by a caller.
Server, A master computer station which controls multiple clients via a local or wide area network.
Setup Mode, The initial stage of configuration mode where a technician can enter Electronic Player Station related data.
SSID, Service Set Identifier. An alphanumeric string maintained by the Wireless Access Point that identifies the name of the specific Wireless network. An end station uses the SSID to distinguish between multiple wireless networks and to determine what authentication method and credentials it should use to gain a connection.
System Account, A user account available on the server, usually secured by a username and password, that provides access to the operating system and resident software.
Test/Diagnostics Mode, A mode on an electronic player station that allows various tests to be performed on its hardware and software.
Testing Laboratory, An organization recognized by the Commission as suitable for evaluation of submitted gaming equipment and software for compliance with this part and part 546 of this chapter.
Touch Screen, A video monitor with a special surface that can activate the Electronic Player Station by the touching of the screen's surface.
Voucher Payment System, A system that securely maintains records of payment vouchers generated by Electronic Player Stations, validates and records successful or failed payments of vouchers by Electronic Player Stations, kiosks or cashier stations, and controls the purging of expired vouchers.
WEP, Wired Equivalent Privacy. An early security standard intended to protect wireless traffic from unauthorized access and modification. WEP has fundamental design flaws and will not protect a Wireless network. Automatic tools that compromise WEP security on a busy network within a few hours are available.
Wireless Access Point, A device that sends and receives wireless radio signals to and from wireless devices, rebroadcasting these signals to and from the Local Area Network to which the Wireless Access Point is connected.
Wireless communication network, A system of multiple computer devices which communicate with each other by broadcasting their messages through the air without using a physical medium such as a wire or cable.
WPA, Wi-Fi Protected Access. A security standard that overcomes some of the known problems with WEP. WPA uses stronger encryption and provides for user authentication. However, like WEP, WPA will not protect a wireless network. Other security standards (e.g. WPA2) are available and under development by various standards bodies.
(a) Effective date. In order that manufacturers and operators have time to bring games and aids into compliance, this part shall be effective 6 months following publication of the final rule in the Federal Register. Upon application by a tribal gaming regulatory authority, the Chairman may extend the effective date for one or more additional periods of 6 months for good cause shown.
(b) Submission, testing, and approval. Except as provided in paragraph (d) of this section, no tribe shall offer for play or use in a tribal gaming operation any gaming equipment, game software, or modification of gaming equipment or game software unless:
(1) The gaming equipment, game software, or modification has been submitted to a testing laboratory recognized by the Commission pursuant to § 546.9(f) of this chapter.
(2) The submission conforms to the requirements of paragraph (c) of this section.
(3) The testing laboratory tests the submission to the standards established by this part, and to any additional standards adopted by the tribal gaming regulatory authority, and provides a formal written report to the party making the submission, setting forth and certifying to its findings and conclusions. And
(4) Following receipt of the laboratory's report, the tribal gaming regulatory authority makes a finding that the gaming equipment, game software, or modification conforms to the standards established by this part, and to any additional standards adopted by the tribal gaming regulatory authority. The tribal gaming regulatory authority shall retain a copy of the laboratory's report so long as the gaming equipment, game software, or modification that is the subject of the report remains available to the public for play in its gaming operation.
(c) Submission requirements. Submissions to testing laboratories required by § 547.4(b) shall include the following:
(1) A complete, comprehensive, and technically accurate description and explanation in both technical and lay language of the manner in which equipment operates. Documentation of client—server implementations shall identify:
(i) The amount of time that the storage of the game records and significant event required to be kept by § 547.6(d) Start Printed Page 46343through (e) may be maintained without causing a degradation in performance;
(ii) The maximum number of enrollable client machines; and
(iii) The number of client machines constituting a high or maximum load and whose collective operation will produce a degradation in system performance.
(2) All source code:
(i) Complete and able to be compiled, with resultant object code identical to that submitted for evaluation;
(ii) If applicable, a resolution of differences in compiled software versions by the addition of ‘date’ and ‘time’ stamps or other such compiler variations;
(iii) If redundant sections of code exist, documentation of the areas of code that are redundant; and
(iv) If code is made redundant via a dynamically settable parameter, documentation of each such parameter, the means of setting or resetting it, and all default states.
(3) The necessary compilers and development environment to enable the software to be independently compiled and tested.
(4) A copy of all executable software, including data and graphic information, and a copy of all source code for programs submitted on electronically readable, unalterable media including, if requested, a method of:
(i) Examining the source code;
(ii) Conducting computer-aided searches within the source code;
(iii) Comparing two different versions of the source code and examining the differences between the two versions; and
(iv) Verifying that the executable software that is to be used for testing has been compiled from the source code versions submitted.
(5) Prototype equipment including all hardware and software components, and if the submitted equipment is a client-server configuration:
(i) A server fully loaded and configured (production mode) with the application to be used in production; and
(ii) At least two clients or Electronic Player Stations, fully loaded and configured (production mode) with the application to be used in production;
(iii) The communications equipment to link the server and clients; and
(iv) If the equipment is to link to external systems such as a casino monitoring system, the hardware and software that enable the interface.
(6) A Formal Application Configuration (FAC) document meeting the requirements of § 547.17(a) and an FAC verification tool meeting the requirements of § 547.17(b) through (g).
(7) A par sheet or mathematical analysis of each game for each paytable submitted.
(8) A copy of all graphical images displayed on the equipment or used in the game, including rules, instructions, and paytables. All artwork supplied shall be identified by a part number and the name or logo of the manufacturer. Successive versions of artwork shall be numbered sequentially.
(9) Any other information, documentation, software, or equipment deemed necessary by the testing laboratory.
(d) Emergency hardware and software changes. (1) Notwithstanding the requirements of paragraph (b) of this section, a tribal gaming regulatory authority may permit modified hardware or game software to be made available for play without prior laboratory review if, in its discretion, the modified hardware or game software is:
(i) Necessary to correct a problem affecting the fairness, security, or integrity of a game; or
(ii) Unrelated to game play.
(2) If a tribal gaming regulatory authority authorizes modified game software or hardware to be made available for play or use without prior laboratory review, the tribal gaming regulatory authority shall require the hardware or software manufacturer to:
(i) Immediately advise other users of the same hardware or software of the importance and availability of the update;
(ii) Immediately submit, pursuant to the requirements of paragraph (c) of this section, the new hardware or software to a test laboratory for testing and verification;
(iii) Provide the tribal gaming regulatory authority a temporary Formal Application Configuration meeting the requirements of § 547.17 for any new software.
(a) Minimum standards. A tribal gaming regulatory authority may establish and implement additional technical standards that are as stringent as, or more stringent than those set out in this part.
(b) Only applicable standards apply. Gaming equipment and software used with play of Class II games shall meet all applicable requirements of this part. For example, if an Electronic Player Station lacks a hopper or the ability to print or accept vouchers, then the standards that govern those things do not apply.
(c) Fairness. No gaming equipment or software used with the play of Class II games shall cheat, mislead, or disadvantage users.
(d) Approved equipment and software only. All gaming equipment and software used with the play of Class II games shall be identical in all respects to a prototype reviewed and tested by a recognized gaming laboratory and approved for use by the tribal gaming regulatory authority pursuant to § 547.4(b) or (d). Unapproved software shall not be loaded onto or stored on any program storage medium used with the play of Class II games.
(e) Proper functioning. All gaming equipment and software used with the play of Class II games shall perform according to the manufacturer's design and operating specifications.
This section provides standards applicable to all servers used with play of Class II games.
(a) General requirements. (1) Servers shall authenticate all communications as coming from an enrolled client machine.
(2) Servers shall only process gaming transactions from games approved by the tribal gaming regulatory authority.
(3) Servers shall be able to enroll and un-enroll client machines for gaming.
(4) Servers shall be able to enable and disable specific client machines for gaming.
(5) Servers shall ensure that only enrolled, enabled client machines participate in gaming.
(6) The default condition for new client machines shall be un-enrolled and disabled.
(b) Physical security. Servers shall be housed in a secure, dedicated room or in a secure locked cabinet. Access shall be restricted to persons authorized by the tribal gaming regulatory authority. Servers located on the casino floor shall also meet the applicable requirements of § 547.7.
(c) Logical/Software security. Nothing in this section shall be construed to alter, repeal or limit the applicability of § 542.16(a) of this chapter. Servers used in the play of Class II games shall also meet the following requirements:
(1) Servers shall use operating systems that have discretionary access controls and shall be configured so that access controls are used to prevent unauthorized access to the operating system, programs, data, and peripherals.
(2) Servers shall be configured so that audit trails are maintained for login/authentication successes and failures. The following information shall be recorded, if supported:
(i) Date and time of the login attempt; Start Printed Page 46344
(ii) Username supplied; and
(iii) Success or failure.
(3) Logins using system accounts (e.g. administrator, root, etc.) shall be restricted to the console. Notwithstanding this, logins using system accounts may be made away from the console for the purpose of remote support, provided that such remote access meets the requirements of paragraph (c)(9) of this section.
(4) Generic user accounts are prohibited.
(5) Accounts shall be restricted to authorized personnel, as specified by the tribal gaming regulatory authority.
(6) Account passwords shall only be transmitted in encrypted or hashed form meeting the requirements of § 547.23(b) through (c).
(7) Application passwords shall be stored in an encrypted or hashed form meeting the requirements of § 547.23(b) through (c).
(8) Only software essential to the operation of the server shall be loaded onto the server.
(9) Remote access to enable dynamic debugging may be permitted by the tribal gaming regulatory authority pursuant to § 542.16(e) of this chapter. To support this facility, servers shall:
(i) Provide a mechanism to enable and disable remote access, which shall be disabled by default; and
(ii) Log all successful and unsuccessful attempts at remote access. Nothing in this requirement shall be construed to alter, repeal, or limit the applicability of § 542.16(e)(1) of this chapter.
(d) Game record information. The server shall store the following records for each game played:
(1) Client ID;
(2) Game start time and date;
(3) Game identifier (version);
(4) Game end time;
(5) Total amount bet by all participants in game;
(6) Total amount won by all participants in game; and
(7) Final game result, including progressive prizes awarded and, for bingo, game number and numbers or designations drawn, in the order drawn.
(e) Significant events. The server shall store the following significant events:
(1) Server shutdown;
(2) Server startup;
(3) Gaming application startup;
(4) Gaming application shutdown;
(5) Client enrolled;
(6) Client un-enrolled;
(7) Client enabled;
(8) Client disabled;
(9) Client tamper detection;
(10) Client signature check and result;
(11) Client application restart;
(12) Client application download;
(13) Server parameter change;
(14) Client parameter change;
(15) Game created;
(16) Game enable;
(17) Game disable;
(18) Game deleted;
(19) Any instance of an aborted game.;
(20) Large (jackpot) win;
(21) Large win (jackpot) approved/rejected;
(22) Progressive parameter change;
(23) Progressive created;
(24) Progressive enabled;
(25) Progressive disabled;
(26) Progressive deleted;
(27) Progressive win;
(28) Progressive win approved/rejected;
(29) Client doors open;
(30) Client doors closed;
(31) Client hopper refill;
(32) Client hand-pay;
(33) Data-link level connection between client and server broken. This requirement does not refer to temporary perturbations of communications where “temporary” means a disruption of less than 10 seconds; and
(34) Data-link level connection between client and server is established.
(f) Storage requirements. Game records, significant events, and remote access logs shall be maintained for a period of one year from the date the games are played.
(g) Alternate storage requirements. Game records, significant events, and remote access logs may be kept in an archived manner, on the server or elsewhere, provided that the information reconciles across all forms of replicated storage and that the information can be produced within 24 hours upon request. In any event, game records and significant events for the previous 72 hours shall be immediately accessible.
(h) Servers acting as progressive controllers. This paragraph (h) applies to progressive controllers, or servers acting as progressive controllers, used with the play of Class II games.
(1) Modification of progressive jackpot parameters shall be secure. Such parameters include, at a minimum:
(i) Increment value;
(ii) Secondary pool increment(s);
(iii) Reset amount(s);
(iv) Maximum value(s); and
(v) Identity of participating Electronic Player Stations.
(2) No parameters shall be modified for an active progressive jackpot unless the jackpot has been won, or as otherwise authorized by the tribal gaming regulatory authority.
(3) If the tribal gaming regulatory authority authorizes modification before a progressive jackpot is won, the server or controller shall:
(i) Halt the operation of the progressive jackpot(s);
(ii) Allow the parameter modifications; and then
(iii) Restart the progressive jackpot(s).
(4) No progressive jackpot shall be returned to its reset amount before it is won except as authorized by the tribal gaming regulatory authority. In any event, no progressive jackpot shall be reset before it is won unless the accumulated jackpot amount is transferred to another active progressive jackpot.
(5) The server or other progressive controller shall provide a means of creating a progressive balancing report for each progressive it controls. At a minimum, that report shall provide balancing of the changes in coin-in meters for all participating Electronic Player Stations versus current progressive jackpot amount(s), plus progressive jackpots won. In addition, the report shall account for, and not be made inaccurate by, unusual events such as:
(i) Electronic Player Station critical memory clears;
(ii) Modification, alteration, or deletion of progressive jackpots.
(iii) Offline equipment; or
(iv) Multiple site jackpots.
This section provides minimum hardware standards for all client machines or servers located on the casino floor and used as Electronic Player Stations for the play of Class II games.
(a) FCC certification. Electronic Player Stations shall have obtained the relevant FCC certification(s), or the USA equivalent, required for equipment of its type prior to approval by the tribal gaming regulatory authority.
(b) UL certification. Electronic Player Stations shall have obtained the relevant UL certification(s), or the USA equivalent, required for equipment of its type prior to approval by the tribal gaming regulatory authority.
(c) Power interconnections. There shall be no mains ground interconnections via data cabling between devices powered from different wall outlets. RS-422, which is designed to operate with a floating ground, may be used provided that any shield or signal grounds are not connected to the mains ground.
(d) Power supplies. (1) Electronic Player Stations shall employ power Start Printed Page 46345supply filtering sufficient to permit continued operation at voltages ±10% of 110v.
(2) Electronic Player Stations shall employ power supply filter sufficient to ensure that none of the following damage or inhibit their operation or affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless trans
(i) Surges or dips of ±20% of 110v of the supply voltage;
(ii) Repeated switching on and off of the AC power supply; or
(iii) Jiggling the AC cord at the wall outlet.
(3) Electronic Player Stations may handle the power variations listed in paragraph (d)(2)(i) through (iii) of this section by intentionally shutting down or going into sleep mode.
(4) All ratings of fuses, if any, shall be clearly stated on or in close proximity to the fuse holder, and switches on the power supply shall show On/Off positions.
(e) Printed Circuit Boards. (1) Printed circuit boards that are specially manufactured or proprietary and not off-the-shelf shall display a unique identifier such as a serial number and revision number, which shall be updated to reflect new revisions or modifications of the board.
(2) Switches or jumpers on all circuit boards that have the potential to affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction shall be capable of being sealed.
(f) Labeling. External key-switches, locks (other than for doors), switches, and buttons shall be securely labeled, using stickers or otherwise, according to their function or the series of events they initiate.
(g) Electrostatic Discharge. (1) Electronic Player Stations shall be constructed so that static discharges of ±15-25 kV for air discharges and of ±7.5-10 kV for contact discharges may cause a temporary disruption but shall not otherwise damage or inhibit operation or affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction.
(2) Electronic Player Stations accessible to the public shall be constructed so that they exhibit total immunity to human body electrostatic discharges on all areas exposed to contact, i.e., static discharges of ±15 kV for air discharges and ±7.5 kV for contact discharges shall not damage or inhibit operation or affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction.
(h) Radio Frequency Interference. Electronic Player Stations shall be constructed so that commonly used electromagnetic emitting devices such as mobile phones or walkie talkies, even if such devices are placed upon, or immediately outside of, the cabinet, shall not damage or inhibit operation or affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction.
(i) Magnetic Interference. Electronic Player Stations shall be constructed so that the application of magnetic interference of up to 10 Gauss at a distance of 5 cm from any surface shall not damage or inhibit operation or affect the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction.
(j) Cabinet and housing construction and security, generally. (1) Cabinets and housings shall be of a robust construction designed to resist determined illegal entry and to protect internal components.
(2) Cabinets and housings shall be reasonably resistant to the extremes of the casino operating environment, such as liquid spills, smoke, and heat, such that these conditions are not capable of affecting the outcome or integrity of any game, progressive award, or voucher, coupon, or cashless transaction.
(3) All doors, hinges, locks, seals and holes, gaps, or slots in the cabinet or housing exterior shall be of a robust construction designed to resist determined illegal entry and to protect internal components.
(4) All protuberances and attachments such as buttons, identification plates, and labels shall be sufficiently robust to avoid unauthorized removal.
(k) Construction and security of locked areas within cabinets, logic areas. (1) All components other than those with which the player interacts directly, such as buttons and entry slots for bills, vouchers, and coins, shall be located within the cabinet, which shall be locked, or in a separate locked area within the cabinet. Bill and coin validators shall be located within the cabinet.
(2) Except for logic areas and locked areas that only provide access to lighting, locked areas within a cabinet shall be equipped with door access detection devices that meet the requirements of paragraph (m) of this section.
(3) Locked areas within a cabinet shall be of a robust construction designed to resist determined illegal entry and to protect internal components.
(l) Security of locked areas within cabinets. (1) The following components shall be housed in a separate, independently locked area within the cabinet:
(i) CPU's and any other electronic components involved in the operation, calculation, or determination of game play and game results, voucher or coupon issuance or redemption, progressive parameters, or cashless transactions;
(ii) All electronics involved in the calculation of game display and components housing display program storage media;
(iii) All program media involved in the operation, calculation, or determination of game play and game results, voucher or coupon issuance or redemption, progressive parameters, or cashless transactions;
(iv) Communication controller electronics and components housing the communication program storage media;
(v) Interfaces and drivers for metering systems; and
(vi) Interfaces to peripherals with money-handling or credit transfer capabilities.
(2) When there are multiple locked areas within a cabinet, access to one shall not be possible from another except by use of a key.
(m) Door access detection. All locked areas, including the main cabinet door but excluding logic areas, shall be equipped with a sensor or other means to detect an open door. In addition:
(1) The door open sensor, and its components or cables, shall be secure against attempts to disable them or interfere with their normal mode of operation.
(2) It shall not be possible to disable a door open sensor, or access components within, without first properly opening the door.
(3) A door open sensor that is disconnected, tampered with, or fails shall be interpreted as an open door.
(n) Touch screens. Shall be:
(1) Resistant to scratching;
(2) Accurate, and, once calibrated, shall maintain that accuracy for the manufacturer's recommended maintenance period;
(3) Capable of re-calibration without access to the machine cabinet other than through the main door.
(o) Tower lights. Electronic Player Stations shall have a light or lights mounted on the top of its cabinet that automatically illuminates when various conditions occur such as errors, alerts, hand-pay jackpots, and call attendant requests from players. Required tower light states are left to the discretion of the tribal gaming regulatory authority.
(p) Audible alarms. An audible alarm is not required if a tower light is available to signal errors, alerts, hand-pay jackpots etc. Start Printed Page 46346
(q) Bill validators. Nothing in this subsection is intended to alter, repeal, or limit the applicability of §§ 542.7(g)(1)(i), 542.21(e), 542.31(e), or 542.41(e) of this chapter.
(1) Bill validators shall be of a robust construction designed to resist determined illegal entry, vandalism, and fraud and to be reasonably resistant to the extremes of the casino operating environments, such as liquid spills, smoke, and heat. In any event, bill validators shall be constructed so that physical tampering with the validator leaves evidence of such tampering.
(2) Bill validators shall be able to detect the entry of valid bills, vouchers, coupons, or other equivalents and to provide a method to enable the client software to interpret and act upon valid or invalid input.
(3) In so doing, bill acceptors shall:
(i) Be electronically based and incorporate multiple, sophisticated detection methods to validate bills;
(ii) Accept only valid bills, vouchers, coupons or equivalents;
(iii) Reject and return all invalid bills, vouchers, and coupons or equivalents to the player; and
(iv) Register the proper number of credits on the credit meter.
(4) All accepted bills shall be deposited into a secure container or stacker that:
(i) Sits within its own locked area within the main cabinet; and
(ii) Is itself locked with a key that opens no other lock.
(5) Bill validators or clients have sensors to indicate stacker full, stacker door open/closed, stacker removed, or bill jam.
(6) Bill validators shall provide a means through which the client may detect potential cheating such as counterfeit bills or bill yo yos.
(7) Bill validators shall employ a reliable means of transmitting credit values to the client. Pulse stream interface or serial communication without error detection and correction are not reliable communication methods.
(8) Ball validators shall be disabled when the cable connecting it to the client machine is disabled.
(9) A bill validator's tolerance level for accepting bills of varying quality and the alteration of a bill validator's checking procedures shall not occur without access to the Electronic Player Station and under conditions specified by the tribal gaming regulatory authority. In any event, it shall not be possible to disable validation features.
(10) Access to bill validators shall only occur under conditions specified by the tribal gaming regulatory authority and shall cause the Electronic Player Station to enter disabled mode. In any event, access in the field shall be limited to:
(i) Access required to clear a bill jam, which shall not provide access to the bill stacker unless that is the location of the jam;
(ii) Selection of bill, coupons, vouchers, or their equivalents, and their limits;
(iii) Changing approved EPROMs or downloading approved software;
(iv) Maintenance, adjustment, and repair per approved factory procedures; or
(v) Options that set the direction or orientation of acceptance.
(11) Bill validators shall be designed to minimize the possibility of a loss of credits if a power outage occurs during acceptance. In no event shall there be during acceptance a window of time longer than one second in which a power outage causes a loss of credits.
(12) Bill validators shall have a means of self verification, which it shall perform at each power up.
(13) If a bill validator only accepts bills fed in a certain direction or orientation, this shall be clearly indicated by sufficient instruction such as a label with a graphical picture.
(14) Bill validators shall not accept bills, vouchers, or their equivalents if any part of the validator is missing, including the stacker.
(r) Coin slots, validators. (1) Coin slots and coin validators shall be of a robust construction designed to resist determined illegal entry, vandalism, and fraud and to be reasonably resistant to the extremes of the casino operating environment such as liquid spills, smoke, and heat. In any event, coin slots and coin validators shall be constructed so that physical tampering leaves evidence of such tampering.
(2) Coin validators shall be able to detect the insertion of valid coins and tokens and to provide a method to enable the client to interpret and act upon valid or invalid input.
(3) In so doing, coin acceptors shall be electronically based and incorporate sophisticated detection methods, accepting only valid coins and tokens and rejecting and returning all others to the player.
(4) Coin validators shall provide a means through which client may detect potential cheating such as counterfeits or coin yo yos.
(5) Access to coin validators that use flash memory or are otherwise reprogrammable in the field shall be permitted only under conditions specified by the tribal gaming regulatory authority.
(s) Coin diverter chutes. (1) Coin chutes and diverter mechanisms shall be constructed to ensure that coins inserted into the client machine are deposited into the hopper, the cash box or the coin tray without jams or spillage onto the internal floor of the machine. Coin chutes and diverters shall be constructed so that physical tampering leaves evidence of such tampering.
(2) Means shall be provided to enable the client to determine a coin's direction of travel so as to detect yo-yo-ing.
(3) There shall be sufficient closed loop control to enable client to determine:
(i) If a coin is traveling to a cash box or to a hopper;
(ii) If a coin diverter has failed; and
(iii) If an internal coin jam has occurred.
(t) Hoppers. (1) Coin hoppers shall be located behind the locked main door or within another locked area.
(2) Coin hoppers shall have or provide a means to enable the client to identify and act upon the following conditions:
(i) Hopper full;
(ii) Hopper empty;
(iii) Hopper jam;
(iv) Extra coin(s) paid/runaway hopper.
(u) Printers. (1) Printers shall be located within the main cabinet but not in the logic area or the cash box area.
(2) Printers shall have mechanisms to allow software to interpret and act upon the following conditions:
(i) Out of paper/paper low;
(ii) Printer jam/failure; and
(v) External mechanisms affecting play. There shall be no external mechanisms such as DIP switches or jumpers that can affect the outcome of a play unless capable of being sealed by the tribal gaming regulatory authority.
This section provides general software standards for clients used as Electronic Player Stations for the play of Class II games.
(a) Door monitoring. Electronic Player Station shall be able to detect access to the following:
(1) The main cabinet door;
(2) Belly door(s), if different than the main cabinet door;
(3) Drop box door(s);
(4) Bill acceptor doors; and
(5) Communication boards, if accessible without opening a door.
(b) Hopper monitoring. The Electronic Player Station software shall be able to identify the following events, at a minimum: Start Printed Page 46347
(1) Hopper full;
(2) Hopper empty;
(3) Hopper jam; and
(4) Extra coin(s) paid/runaway hopper.
(c) Information displays. (1) During the play of any game, the Electronic Player Station shall display all game results so that the player may see and comprehend them. This display shall also include:
(i) The amount wagered; and
(ii) The credit meter balance.
(2) Between plays of any game and the start of the next play, or the player selects a new game option such as wager amount or card selection, whichever is earlier, and when there are credits on the credit meter, the Electronic Player Station shall display:
(i) The total credits wagered and all prizes and total credits won for the last play;
(ii) The final results for the last game played, including alternate displays of results, if any; and
(iii) The default number of credits that will be wagered on the next play.
(3) Prior to the play of any game, when the player has selected or changed game options such as wager amount or bingo card, the Electronic Player Station shall remove the results of the previous game or otherwise distinguish them from the new selections.
(4) Following cash out payable from the hopper and until the start of the next play, the Electronic Player Station shall display the metered value of coins or tokens paid in dollars and cents or in credits, if the coin denomination is an exact multiple of the credit tokenization value.
(5) Following cash out payable as a cancel credit and until the start of the next play, the Electronic Player Station shall display the metered value of the credits cancelled in dollars and cents or in credits, if the amount of the cancel credit is an exact multiple of the credit tokenization value.
(6) Attract modes may be displayed if there are credits on the credit meter, provided that there is a means for the player to interrupt and return to the previous display.
(7) Help screens may be displayed during game play provided that there is a means for the player to interrupt and return to the previous display.
(d) Touch screen calibration and implementation. (1) The Electronic Player Station shall have software re-calibrating capability unless the touch screen is designed never to require re-calibrating.
(2) If opening the main Electronic Player Station door affects touch screen calibration, there shall be a means to determine the accuracy of calibration when the door is closed again.
(3) Touch screen button icons shall be sufficiently separated to reduce chances of selection errors due to calibration or parallax errors.
(4) There shall be no hidden or undocumented buttons or touch points anywhere on the screen except as provided for in the game rules.
(e) Game initiation and play. (1) Every game played on an Electronic Player Station shall follow and not deviate from a constant set of rules. Any change in rules constitutes a different game. Allowing variations in the size of a wager is not a change in rules.
(2) No game shall commence, and no money or credit shall be accepted, on an Electronic Player Station in the presence of any fault condition or open door, or while the Electronic Player Station is in test, audit, or lock-up mode.
(3) Credits wagered shall only come from the credit meter, which shall be decremented at the start of play.
(4) The player shall initiate play of a game on an Electronic Player Station by pressing a button or similar input device. No Electronic Player Station shall automatically initiate game play.
(5) The value of prizes awarded as a result of any game shall be paid in full and not truncated or rounded.
(f) Audit mode. (1) Each Electronic Player Station shall have an audit mode, which shall provide access to the following information, at a minimum:
(i) All meters required by § 547.12;
(ii) Last game recall information required by § 547.14;
(iii) Terminal identification;
(iv) Software version or game identification; and
(v) Any other game statistics maintained solely by the Electronic Player Station and not transferred to and maintained by the server or casino monitoring system.
(2) Audit mode shall be accessible by a secure method, such as a key-switch, entry of a card into a card reader and verification by PIN, or from within the interior of the Electronic Player Station cabinet.
(3) Meters shall be accessible by an authorized person at any time, except during a payout from a hopper, during a cancel credit, or during play (except where play is interrupted by a fault condition).
(4) The Electronic Player Station shall disable all credit acceptance while in audit mode, except during coin, bill, or other credit acceptance testing.
(g) Test or diagnostic mode. (1) Test mode on an Electronic Player Station may be entered via an appropriate instruction during Audit Mode or automatically upon opening the main cabinet door.
(2) The Electronic Player Station shall clearly indicate when it is in test mode.
(3) Test games run in test mode, if implemented, shall:
(i) Not increment any meters other than a temporary on-screen credit meter;
(ii) Only be available after entering a specific test game mode within door open mode; and
(iii) Be clearly indicated as such and not as normal game play.
(4) The Electronic Player Station shall disable all credit acceptance while in test mode, except during coin, bill, or other credit acceptance testing.
(5) Exiting test mode shall terminate all tests, unless further input is required, which shall be clearly indicated by Electronic Player Station software.
(h) Multi-game machines. Electronic Player Stations that offer multiple games for play shall:
(1) Present a game selection screen that displays:
(i) The available games;
(ii) The means of selecting among them; and
(iii) The full amount of the player's credit balance;
(2) Identify the game selected or being played;
(3) Not compel the play of a game after its selection; and
(4) Not start a new game before the current play is complete and all relevant meters have been updated.
(i) Separate storage, machine specific information. Electronic Player Station software shall be designed so that machine specific information such machine address or other configurable parameters is stored within in a separate device (EPROM, Flash or file for disk machines) as game and system software.
(j) Program interruption and resumption. (1) Electronic Player Station software shall be designed so that upon any loss of power it is able to return to the state it was in prior to the interruption.
(i) If in a test mode at interruption, the Electronic Player Station shall, on power up, complete any test that incorporates credits entering or leaving the machine (e.g. a hopper test) prior to resumption of normal operation.
(ii) If in a fault condition at interruption, the Electronic Player Station shall, on power up, display the applicable fault message and remain locked-up, unless:
(A) The power down is part of an error reset procedure; or
(B) The Electronic Player Station checks for the fault condition on power up and detects no fault. Start Printed Page 46348
(2) Electronic Player Station software shall be designed so that upon any loss of power, it shall, at a minimum:
(i) Turn off and brake the hopper;
(ii) Maintain the integrity of data stored in critical memory; and
(iii) Complete its power-down routine.
(3) Electronic Player Station software shall be designed so that upon program resumption after a loss of power, it:
(i) Successfully completes any program resumption routine, including self tests, before beginning any communications to an external device;
(ii) Tests itself for possible corruption due to failure of the program storage media using a minimum 16-bit Cyclic Redundancy Check (CRC) check;
(iii) Checks the integrity of critical memory;
(iv) Tests any power down routine for correct completion and displays an appropriate message if incorrect completion detected; and
(v) Detects any change in the software since loss of power. If a change has been detected, the Electronic Player Station shall lock-up and display an appropriate message until it is reset by an authorized person.
(4) Electronic Player Station software shall be designed so that when disabled in a non-fault condition during play, for example by the server, but without loss of power, it finishes the current play and allows the player to cash out.
(k) Simultaneous inputs. The simultaneous or sequential activation of various inputs (such as buttons on the button panel), whether or not intentional, shall not adversely affect the integrity of any game.
This section provides specific standards for the contents and maintenance of critical memory, which stores data essential for the play of Class II games.
(a) Critical memory, location and contents. Critical memory may be stored on a server or on a client used as an Electronic Player Station and shall maintain all of the following data:
(1) Auditing meters;
(2) Current credits;
(3) Electronic Player Station and game configuration data;
(4) Last game recall information required by § 547.14;
(5) Game recall information for the current game, if incomplete;
(6) Software state (the last normal state the Electronic Player Station software was in before interruption);
(7) RNG seed(s);
(8) Encryption keys;
(9) Progressive jackpot parameters and current values, if maintained within the client or server;
(10) The five most recent cashless transactions; and
(11) The five last ticket transactions (redeem or print).
(b) Maintenance. (1) Critical memory shall be implemented with a level of redundancy such that failure of a single component will not mean the loss of any data.
(2) In the event of a disruption during updates, there shall be a means of defining which of the multiple available copies of data in critical memory is correct.
(3) Software shall ensure that updates to meters in critical memory are successful and that any error(s) in one logical copy of the meters is not propagated through to other copies.
(4) Critical memory shall be maintained using a methodology that enables errors to be identified and acted upon.
(c) Validity checks, detection of corrupt memory. (1) The validity of critical memory in an Electronic Player Station shall be checked after:
(i) Every restart;
(ii) Each of the following transactions:
(A) Bill input;
(B) Jackpot win;
(C) Progressive jackpot win;
(D) Door closed; and
(E) Any reconfiguration, download, or change of game paytable or denomination requiring operator intervention or action;
(iii) Every cashless transfer;
(iv) Every voucher print/redeem; and
(v) Before and after a game play.
(2) Notwithstanding the requirements of paragraph (c)(1) of this section, critical memory may be partitioned, and each partition may be verified independently when relevant data is to be changed.
(3) Following any restart, the Electronic Player Station shall check the validity of critical memory and then perform a comparison check of all logical copies of critical memory.
(d) Recoverable critical memory failures. (1) If upon any validity check failure at least one logical copy of critical memory is good, the software may recover critical memory data and continue game play provided:
(i) All logical copies of critical memory are recreated using the good logical copy as a source; and
(ii) The Electronic Player Station software verifies that the recreation of critical memory was successful.
(2) If verification of recreated critical memory identifies a permanent physical memory failure, the error shall be handled as an unrecoverable critical memory failure pursuant to paragraph (e) of this section.
(e) Unrecoverable critical memory failures. (1) If upon any validity check all logical copies of critical memory are corrupt, or if any verification identifies a permanent physical memory failure, the software shall flag a critical memory storage error.
(2) Critical memory storage errors shall not be cleared automatically and shall require a full critical memory storage clear.
(3) If the Electronic Player Station is so designed that after an unrecoverable memory failure it is possible to view all logical copies of meters, including the customer's credit meter, the Electronic Player Station shall highlight which are expected to be valid and which corrupt.
(4) A processor installed from another Electronic Player Station, or a processor that has never been used, shall be considered an unrecoverable critical memory failure.
(f) Critical memory resets or clears. (1) All methods of clearing meters or other critical memory data shall:
(i) Require access to the logic area of the Electronic Player Station or other secure means authorized by the tribal gaming regulatory authority; and
(ii) Initialize all bits in critical memory to their default states.
(2) The default display after a critical memory reset, or upon entering game play mode, shall not be a winning pattern or game.
(3) Any configuration setting entered during setup mode immediately following a critical memory reset shall not be able to be changed after the machine leaves setup mode.
(g) Non-critical memory. Electronic Player Stations shall check non-critical memory upon power up.
This section provides standards for meters on Electronic Player Stations used in the play of Class II games. Nothing in this section requires the use of electromechanical meters. Nothing prohibits the use of electromechanical meters, provided that they meet the requirements of this section.
(a) Meter width. (1) Accounting meters shall be at least eight decimal digits or 32 bits wide.
(2) Count meters shall be at least six decimal digits or 24 bits wide.
(3) Credit meters shall have sufficient digits or bits to display the maximum prize attainable for the game, including cashless transfers or other external payments to the credit meter, but not hand-pay jackpots. Start Printed Page 46349
(b) Rollover. Meter rollover to zero shall not corrupt data.
(c) Meters displayed on the game screen. (1) Meters displayed on the game screen shall be displayed in a format which is clearly visible to the player and easily distinguished from the rest of the game.
(2) A display may alternate between dollars and cents and credits, provided that both values are clearly visible and easily distinguished from one another. Such a display shall not alternate during play or during the incrementation of the win meter or credit meter following a win.
(d) Credit meter display and function. (1) The credit meter shall be prominently displayed at all times in all modes except:
(i) Audit, configuration, and test modes; and
(ii) Temporarily, during alternate displays of game results.
(2) When wagered, credits shall be immediately deducted from the credit meter.
(3) Every prize won shall be added to the player's credit meter, except for hand-pays, cancel credits, progressives, or non-cash prizes. Progressives may be added to the credit meter if:
(i) The credit meter is maintained in dollars and cents, or
(ii) The progressive meter is incremented in number of credits, or
(iii) The prize in dollars and cents is converted to credits on transfer to the player's credit meter in a manner that does not mislead the player or cause accounting imbalances; and
(iv) The Electronic Player Station can accommodate payments that are not direct multiples of the game's denomination, pursuant to § 547.15(j); and
(v) The progressive prize is less than $1,200, or other amount specified by the tribal gaming regulatory authority.
(4) If the credit meter displays credits while maintaining a balance that includes odd cents, then the credit meter shall display the remaining odd cents when the balance drops below one credit.
(5) Meters displayed to the player may be incremented or decremented using visual effects, but the internal storage of these meters shall be immediately updated in full.
(e) Required meters. (1) The following meters shall be implemented in Electronic Player Stations, as applicable:
|(i) Coin In||The total value of all wagers, whether from the insertion of coin or tokens, currency, deduction from a credit meter or any other means||Accounting.|
|(ii) Coin Out||The total value of all amounts directly paid by the machine as a result of winning wagers, whether made from the hopper, to a credit meter, or any other means||Accounting.|
|(iii) Coins Dropped||The total value of coins or tokens diverted to the drop||Accounting.|
|(iv) Jackpot||The total value of jackpots paid by an attendant and not capable of being paid by the machine itself. This does not include progressive amounts. This meter is only to include awards resulting from a specifically identified amount listed in the manufacturer's par sheet||Accounting.|
|(v) Canceled Credits||The total value paid by an attendant resulting from a player initiated cash-out that exceeds the physical or configured capability of the machine to make the proper payout amount||Accounting.|
|(vi) Physical Coin In||The total value of coins or tokens inserted into the Electronic Player Station||Accounting.|
|(vii) Physical Coin Out||The total value of coins or tokens paid out by the hopper||Accounting.|
|(viii) Bill In||The total value of the currency accepted||Accounting.|
|(ix) Bill Out||The total value of currency dispensed, if the Electronic Player Station has a currency dispenser||Accounting.|
|(x) Bill in Count||The total number of each bill denomination accepted||Count/Accounting.|
|(xi) Voucher In||The total value of all wagering vouchers and payout receipts accepted by the machine||Accounting.|
|(xii) Voucher Out||The total value of all wagering vouchers and payout receipts issued by the machine||Accounting.|
|(xiii) Cashless In||The total value of cashable credits electronically transferred to the Electronic Player Station from a cashless wagering system||Accounting.|
|(xiv) Cashless Out||The total value of cashable credits electronically transferred from the Electronic Player Station to a cashless wagering system||Accounting.|
|(xv) Games Played||The cumulative number of games played since the last critical memory clear||Count.|
|(xvi) Cabinet Door Open||The number of times the front cabinet door has been opened||Count.|
|(xvii) Drop Door Open||The number of times the drop door or the bill acceptor door has been opened||Count.|
|(xviii) Attendant Paid Progressive Payout||The total value of credits paid by an attendant as a result of progressive awards that are not capable of being paid by the machine itself||Accounting.|
|(xix) Machine Paid Progressive Payout||The total value of credits paid as a result of progressive awards paid directly by the machine||Accounting.|
|(xx) Games Won||The cumulative number of all games won||Count.|
|(xxi) Games Lost||The cumulative number of all games lost||Count.|
(2) When an Electronic Player Station offers multiple paytables for play, the following meters shall be implemented, for each paytable, and the meter information shall be available both at the Electronic Player Station and the server:
|(i) Coin In||The total value of all wagers for this paytable||Accounting.|
|(ii) Machine Paid Paytable||The total value of all amounts for this paytable directly paid by the machine as a result of paytable winning wagers||Accounting.|
|(iii) Machine Paid Progressive||The total value of credits for this paytable paid directly to the machine as a result of progressive awards||Accounting.|
|(iv) Attendant Paid Paytable||The total value of all amounts for this paytable paid by an attendant as a result of paytable winning wagers||Accounting.|
|Start Printed Page 46350|
|(v) Attendant Paid Progressive||The total value of credits for this paytable paid by an attendant as a result of progressive awards||Accounting.|
|(vi) Games Won||The cumulative number of games won for this paytable||Count.|
|(vii) Games Lost||The cumulative number of games lost for this paytable||Count.|
(3) If an Electronic Player Station supports promotional coupons or non-cashable credits, the following meters shall be implemented:
|(i) Non-Cashable Promotion In||The total value of non-cashable credits placed on the Electronic Player Station by insertion of a promotional coupon or electronically transferred to the Electronic Player Station from a promotional account by means of an external connection between the machine and a cashless wagering system||Accounting.|
|(ii) Cashable Promotion In||The total value of cashable credits placed on the Electronic Player Station by insertion of a promotional coupon or electronically transferred to the electronic player station from a promotional account by means of an external connection between the machine and a cashless wagering system||Accounting.|
|(iii) Non-Cashable Promotion Out||The total value of non-cashable credits redeemed by an Electronic Player Station issuing a promotional coupon or electronically transferred from the electronic player station to a promotional account by means of an external connection between the machine and a cashless wagering system||Accounting.|
|(iv) Cashable Promotion Out||The total value of cashable credits redeemed by an Electronic Player Station issuing a promotional coupon or electronically transferred from the electronic player station to a promotional account by means of an external connection between the machine and a cashless wagering system||Accounting.|
(f) Meter updates. (1) Meters shall be updated upon the occurrence of the metered event.
(2) Updating multiple meters shall occur before display on the Electronic Player Station or response to a meters request from a casino monitoring system.
This section provides standards for events such as faults, deactivation, door open or other changes of states, and lockup on Electronic Player Stations used in the play of Class II games.
(a) Faults, generally.
(1) The following faults are to be treated as events:
|Fault||Definition and action to be taken|
|(i) Coin Yo-Yo||Inserted coin detected moving in the incorrect direction.|
|(A) A single coin yo-yo may be treated as an information only event.|
|(B) Consecutive coin yo-yos are to lead to an Electronic Player Station fault condition.|
|(ii) Coin-in Jam||Coin detected not moving—e.g. sensors are continually blocked.|
|(iii) Coin to Cashbox or Diverter Fault||Multiple coins detected going to the cashbox instead of the hopper, or vice-versa.|
|(iv) Hopper Empty||Coins not passing a hopper output sensor within a specified time.|
|(v) Hopper Jam||The hopper output sensor(s) are blocked.|
|(vi) Extra Coin Paid||Single coin passed hopper sensor after hopper payout completed.|
|(vii) Hopper Run-away||Multiple coins passing hopper sensor.|
|(viii) External Peripheral Controller Fault/Disconnect||Any peripheral controller fault or communications failure.|
|(ix) Printer Paper Low||The printer paper will soon be exhausted.|
|(A) Lock up the Electronic Player Station upon completion of a predetermined number of tickets calculated to ensure “Paper Out” is not possible. If a paper-out sensor is also provided then “Paper Low” results only in a message.|
|(B) Note that if an Electronic Player Station has a printer it shall have a Paper Low or Paper Out sensor, or both.|
|(x) Printer Paper Out||The printer paper has been exhausted. The Electronic Player Station shall lock-up until the paper out state is cleared.|
|(xi) Printer Jammed||The printer paper is not feeding correctly.|
|(xii) Low CMOS RAM Back-up Battery||Back-up RAM Battery has reached a voltage where back-up will become unreliable soon.|
|(A) A message stating that the repairer shall be called shall be displayed.|
|(B) The Electronic Player Station shall lock-up.|
|(xiii) Critical RAM Errors, Mismatch||Some critical RAM error has occurred: When a non-correctable RAM error has occurred, the data on the Electronic Player Station can no longer be considered reliable. Accordingly, any communication to external devices shall cease immediately, and an appropriate message shall be displayed.|
|(xiv) EEPROM Error||An EEPROM error has occurred.|
|—As for Critical RAM errors—|
|(xv) Program storage medium fault||The software has failed its own internal security check.|
|Any communication to external devices shall cease immediately.|
|An appropriate message shall be displayed, if possible.|
|Start Printed Page 46351|
|No modifications to critical meters in RAM shall be possible.|
|The Electronic Player Station shall lock-up until corrected.|
|(xvi) Progressive communications lost||Communications with the device or system that is controlling the progressive(s) has failed.|
|(xvii) Progressive levels mismatch||An Electronic Player Station or server has a different number of progressive levels configured than the device or systems that is controlling the progressive(s).|
|(xviii) Game meter/progressive meter mismatch||There is a difference in progressive amount between an in-machine game meter and the progressive controller.|
(2) Upon the occurrence of any fault identified in paragraph (a)(1) of this section, the Electronic Player Station shall, unless otherwise specified in paragraph (a)(1) of this section:
(i) Display a message that the event has occurred;
(ii) Disable all player inputs, including coin and bill input, except the service call button, if any;
(iii) Sound an identifiable alarm for at least 1.5 seconds or illuminate the tower light;
(iv) Save any incomplete game play in its current condition; and
(v) If in hopper payout, the turn off and brake the hopper.
(3) Upon clearing any fault identified in paragraph (a)(1) of this section, the Electronic Player Station shall:
(i) Remove the event message;
(ii) Enable all player inputs;
(iii) Turn off the alarm or tower light; and
(iv) Recommence game play from the beginning of the play, or from the point at which interruption occurred, using saved data, and conclude normally.
(b) Door open/close events. (1) The following door open or close conditions are to be treated as events:
|(i) Electronic Player Station Door Open||The main cabinet door is open.|
|(ii) Cash box Door Open||The cash box door is open.|
|(iii) Other Secure Area Accessed||Any other secure area has been accessed.|
|(iv) Electronic Player Station Door Closed||The main cabinet door has closed.|
|(v) Cash box Door Closed||The cash box door has closed.|
|(vi) Other Secure Area Secured||Previously accessed secure area has been secured.|
(2) The Electronic Player Station shall perform the following on any door open event:
(i) Save any software state prior to door opening;
(ii) Save any game play in its current incomplete condition;
(iii) Indicate that a door is open;
(iv) Disable all credit input, but credit input may be enabled for the duration of any credit input test or hopper test;
(v) Disable all game play;
(vi) Disable and brake hopper if the hopper is running, but the hopper may be enabled for the duration of a hopper test;
(vii) Disable all player inputs, but player inputs may be enabled in door open/test mode;
(viii) Disable cash out; and
(ix) Sound an identifiable alarm for at least 1.5 seconds or illuminate the tower light.
(3) The Electronic Player Station shall perform the following when all doors are closed:
(i) Return to the software state saved upon door open;
(ii) Indicate, for 10 seconds or until the next game play, that the doors are closed;
(iii) Enable player inputs;
(iv) Turn off alarm or tower light; and
(v) Recommence game play from the beginning of the play, or from the point at which interruption occurred, using saved data, and conclude normally.
(c) Bill validator events. (1) The following bill validator events shall be treated as faults:
(i) Bill door open open/closed
(ii) Bill container or stacker removed
(iv) Bill jam
(v) Bill Yo-Yo
(vi) Bill container or stacker full
(vii) Bill validator cable disconnected
(viii) Bill validator self-check failure
(2)(i) Upon the occurrence of any fault identified in paragraph (c)(1) of this section, the Electronic Player Station shall:
(A) Display a message or other indication that the event has occurred;
(B) Sound an identifiable alarm for at least 1.5 seconds or illuminate the tower light; and
(C) Disable bill input.
(ii) Game play may continue, except upon the occurrence of a bill jam or door open, container or stacker removed, or cable disconnected event, in which case the Electronic Player Station shall disable all player inputs and the ability to cash out.
(3) Bill validator faults may not be automatically cleared but shall require operator intervention.
(4) Upon clearing any fault identified in paragraph (a)(1) of this section, the Electronic Player Station shall, as appropriate:
(i) Remove the event message;
(ii) Turn off the alarm or tower light; and
(iii) Enable bill input, all player inputs, and cash out.
(d) Non-fault events. For the following non-fault events, the Electronic Player Station shall take the following actions:
|(1) Electronic Player Station Power Off During Play||(i) Game play shall be saved in its current incomplete condition (wins shall only be paid on subsequent power up).|
|(2) Power Off During Play||(ii) If in hopper payout, disable and brake hopper.|
|Start Printed Page 46352|
|(3) Electronic Player Station Power On||(i) Enable player inputs.|
|(ii) Recommence game play from the beginning of the play, or from the point at which interruption occurred, using saved data, and conclude normally.|
|(4) Linked Progressive Award||(i) Display appropriate message.|
|(ii) Unless the prize is transferred to the player's credit meter, lock-up until the award paid by attendant.|
|(5) Jackpot Win||For any prize equaling or exceeding an amount set by the tribal gaming regulatory authority, lock-up until the award paid by attendant.|
|(6) Maximum Hopper Pay out Exceeded||Lock up until cancel credit and full amount paid manually.|
This section provides standards for last game recall information on Electronic Player Stations used in the play of Class II games.
(a) Game recall, generally. (1) The Electronic Player Station shall make game recall information retrievable at all times upon the operation of an external key-switch, entry of an audit card, or other similar method.
(2) The Electronic Player Station shall be able to show the player the results of recalled games as the player originally saw them and enable the tribal gaming regulatory authority or operator to clearly identify the game sequences and results that occurred.
(3) The Electronic Player Station shall, upon return to normal game play mode, restore the display to the positions, forms and values displayed before access to the game recall information.
(b) Game recall information. Electronic Player Stations shall be able to display the following information for the last five games played and shall display all values, even if zero:
(1) The total number of credits at the start of play, less credits bet;
(2) The total number of credits bet;
(3) The total number of credits at the end of play;
(4) The total number of credits won as a result of the game recalled, and the value in dollars and cents for progressive prizes, if different;
(5) The total number of credits added, separated by coins or tokens, bills, vouchers and cashless transfer, since the end of the previous play and through to the end of the last play;
(6) The total number of credits redeemed, separated by coins or tokens, vouchers, and cashless transfer, since the end of the previous play and through to the end of the last play;
(7) The total value of cancelled credits, in dollars and cents, since the end of the previous play and through to the end of the last play;
(8) The value of all accounting meters as at the end of the last play;
(9) For bingo games and games similar to bingo only:
(i) The card(s) used by each player;
(ii) The number of the bingo game played;
(iii) The numbers drawn, in the order that they were drawn;
(iv) The numbers and prize patterns covered on each card;
(v) The patterns slept during the game;
(vi) All prizes won and winning patterns; and
(vii) The number of the card on which prizes were won;
(10) For pull-tabs games only:
(i) The result(s) of each pull-tab, displayed in the same pattern as on the tangible pull-tab; and
(ii) All prizes won.
(11) Any other information necessary to fully reconstruct the last five plays.
(c) Voucher and credit transfer recall. Notwithstanding the requirements of any other section in this part, an Electronic Player Station shall have the capacity to:
(1) Display the information specified in § 547.15(h)(3)(ii) through (vi) for the last five vouchers printed and the last five vouchers accepted; and
(2) Display a complete transaction history for the last five cashless transfers made and the last five cashless transfers accepted.
This section provides standards for money and credit handling by Electronic Player Stations used in the play of Class II games.
(a) Credit acceptance, generally. (1) The Electronic Player Station shall disable all credit acceptance in the presence of any fault or while in audit or test mode, except for coin, bill, or other credit acceptance testing.
(2) The Electronic Player Station shall register the correct number of credits on the credit meter upon any credit acceptance.
(b) Credit acceptance, coins and tokens. (1) The Electronic Player Station shall register the actual value or number of credits on the credit meter upon insertion of a valid coin or token.
(2) The Electronic Player Station shall accurately count each valid coin token at the highest speed in which the coins or tokens may be fed into the Electronic Player Station.
(3) The Electronic Player Station shall reject coins or tokens deemed invalid by the validator.
(4) If a hopper is present, the Electronic Player Station shall:
(i) Cause the diverter to direct coins to the cash box when the hopper is full; and
(ii) Continually monitor the hopper full detector to determine whether a change in diverter status is required. If the state of the detector changes, the diverter shall operate as soon as possible after the state change without causing a disruption of coin flow or creating a coin jam.
(c) Credit acceptance, bills. (1) The Electronic Player Station shall always register bills, coupons, vouchers, or their equivalents on the credit meter if they are input during game play.
(2) The Electronic Player Station shall not register credits on the credit meter until:
(i) The bill, coupon, voucher or other equivalent has passed the point where it is accepted and stacked; and
(ii) It has received a “stacked” message from the bill acceptor.
(3) The Electronic Player Station shall have a means of handling simultaneous insertion of bills (and vouchers and their equivalents) into the bill acceptor and coins (or tokens) into the coin slot, such that the proper number of credits is always registered. In complying with this requirement, the Electronic Player Station may reject and return either the bill or coin or both.
(d) Credit acceptance, vouchers. Nothing in this paragraph (d) is intended to alter, repeal, or limit the applicability of §§ 542.13(n), 542.21(f), 542.31(f), or 542.41(f) of this chapter.
(1) The Electronic Player Station shall be able to detect the entry of a valid voucher.
(i) If valid, the voucher serial number is transmitted to the voucher validation system. Start Printed Page 46353
(ii) If not valid, the voucher shall be rejected and returned to the player.
(2) The voucher payment system shall verify the authenticity of the voucher and ensure that payment is pending. If the voucher is valid:
(i) The voucher payment system will communicate a success message, including the amount to be paid, back to the Electronic Player Station.
(ii) The Electronic Player Station will determine if it can accept or handle the amount transferred.
(A) If it cannot, the Electronic Player Station shall send a reject message to the voucher payment system and return the ticket to the player.
(B) If it can accept or handle the amount transferred, the Electronic Player Station shall register credits on the credit meter, stack the voucher, and handle odd cents pursuant to paragraph (j) of this section.
(e) Credit redemption generally. Electronic Player Stations shall allow players to cash out or redeem credits at any time other than:
(1) During the play of a game;
(2) While the Electronic Player Station is in audit mode or any test mode;
(3) While any door open condition exists;
(4) While the credit meter or total wins meter is incrementing;
(5) While the Electronic Player Station is disabled; and
(6) While any fault condition exists, excluding:
(i) Ticket printer failure or printer paper error;
(ii) Progressive controller failure;
(iii) Bill acceptor full.
(f) Credit redemption, cancel credit / hand-pay jackpots. (1) A cancel credit / hand-pay shall occur:
(i) In the absence of a voucher printer and upon the occurrence of a jackpot larger than the maximum jackpot payable from the hopper, as determined by the tribal gaming regulatory authority;
(ii) In the absence of a voucher printer and upon the occurrence of a cash out request when the credits registered on the credit meter exceed the maximum amount payable from the hopper, as determined by the tribal gaming regulatory authority;
(iii) In the absence of a functioning voucher printer and hopper, upon the occurrence of any cash out request;
(iv) Upon a manual override to force a cancel credit or hand-pay when a voucher is not wanted; and
(v) When the amount on the credit meter is not a direct multiple of the coin value contained within the hopper—in this case, the Electronic Player Station may dispense all possible coins from the hopper and leave only the final odd cents or residual credit;
(vi) Upon the occurrence of a jackpot, or combination of prizes awarded in a single game, of $1,200 or more; or
(vii) Upon the any other circumstance required by the tribal gaming regulatory authority.
(2) Upon the occurrence of a cancel credit or hand-pay jackpot, the Electronic Player Station shall:
(i) Automatically lock-up and display a “call attendant” or other message describing the condition;
(ii) Remain in the lock-up state until the credits have been cancelled by manual intervention or the player exits from the cancel credit state and resumes play, except that the player shall not be able to exit upon the occurrence of a jackpot, or combination of prizes awarded in a single game, of $1,200 or more and requiring the issuance of a W-2G;
(iii) Display the cancel credit hand-pay amount in dollars and cents; and
(iv) When cancel credit or hand-pay has been completed, the credit meter shall be set to zero, the lock-up state exited, and the cancel credit meter incremented by the amount cancelled or paid.
(g) Credit redemption, coins or tokens from the hopper. (1) Once initiated, the player shall not be able to cancel, pause, or otherwise control payment from the hopper.
(2) Each coin paid from the hopper shall be registered on the physical coin out meter and be decremented from the player's credit meter.
(h) Credit redemption, vouchers. Nothing in this paragraph (h) shall alter, repeal, or limit the applicability of § 542.13(n) of this chapter. In addition, credit redemption by ticket voucher shall conform to the following:
(1) An Electronic Player Station may redeem credits by printed voucher when it communicates with a voucher payment system that validates the voucher.
(2) An Electronic Player Station that redeems credits with printed vouchers shall either:
(i) Maintain an electronic record of all information required by § 547.15(h)(3)(ii) through (vi); or
(ii) Generate two identical copies of each voucher printed, one to be provided to the player and the other to be retained within the machine for audit purposes.
(3) Valid vouchers shall contain the following:
(i) Gaming operation name, city and state, reservation, or territory;
(ii) Electronic player station number or printer station number, as applicable;
(iii) Date and time of issuance;
(iv) Alpha and numeric dollar amount;
(v) A sequence number;
(vi) A validation number, although
(A) No ticket validation number shall be repeated, even upon a total replacement of the electronic player station, and
(B) Ticket validation numbers shall have some form of checkcode or other form of information redundancy to prevent prediction of subsequent validation numbers without knowledge of the checkcode algorithm and parameters;
(vii) A second printing of validation number on the leading edge of the voucher or coupon; (viii) A bar code or other form of machine readable markings, which shall have enough redundancy and error checking to ensure that 99.9% of all misreads are flagged as errors;
(ix) Transaction type or other method of differentiating ticket types; and
(x) Expiration period or date when voucher or coupon will expire.
(i) Cashless credit transfers. (1) Transfers from a cashless account may not exceed the balance of that account.
(2) The Electronic Player Station software shall be designed to have a secure method of identifying a cashless account in order to redeem credits and transfer them to that account, even in the event a player's account card has been abnormally removed or there is a loss of power.
(j) Credit transfers not multiples of game denomination. For games not metered in dollars and cents, the Electronic Player Station shall handle credit transfers from voucher systems or cashless systems that are not multiples of the game denomination in one of the following ways:
(1) Reject the transfer and any voucher input.
(2) Redeem the odd cents by printing a voucher by cashless transfer back to the cashless system. The Electronic Player Station may redeem the odd cents immediately or after the player finishes playing, provided in the latter case that the odd cents are displayed to the player in accordance with § 547.12(d)(4).
(k) Cards used as account identifiers. Nothing in this paragraph (k) is intended to alter, repeal, or limit the applicability of § 542.13(o) of this chapter.
(1) Multiple-use Simple Magnetic Stripe Cards. If the card media is a simple magnetic stripe card designed for repeated, rather than single, use in the manner of a voucher, additional security protection to that of reading the Start Printed Page 46354magnetic stripe is required. At a minimum, the entry of a PIN, selectable by the patron, is required when an amount of money can be withdrawn from an account.
(2) Card Locking Mechanisms. Except if an amount debited from a card or account is placed directly on the credit meter and no further transactions are required from the card or account, the Electronic Player Station shall activate a locking mechanism to retain a card within the reading device, and lock a card into the unit once inserted, until one of the following conditions is met:
(i) The player has requested a collect of remaining credits and all updating of meters and account records has been successfully completed.
(ii) The player has a zero credit balance and updating of all meters and account records has been completed successfully.
(iii) An invalid card condition has been cleared by an approved method.
(iv) A power or communications failure of the Electronic Player Station. In this instance, the meter and accounting information shall be updated by the cashless system before logically releasing the card.
This section provides minimum software standards common both to servers and clients, wherever located, and used in the play of Class II games. It also provides minimum standards for client-server implementations used in the play of Class II games.
(a) Client enable / disable requirements. (1) Electronic Player Stations shall be in a disabled state following:
(i) An application start or restart;
(ii) A system start; and
(iii) A system start from a standby, sleep, or hibernating mode.
(2) Electronic Player Stations shall remain in the disabled state until they receive an “enable” command from the server.
(3) Electronic Player Stations shall not immediately enable on receipt of a server “enable” command if a door open or other disabled state is still present when the enable instruction is received from the server, but may enable itself after all alarms are cleared.
(b) Automatic operation of programs. Software used with play of Class II games shall automatically restart, without the need for operator intervention, when the computer on which they operate starts or restarts.
(c) Load requirements. (1) Under high or maximum loads:
(i) The server or client shall not provide misleading information to players.
(ii) Information stored in the client or server shall not become corrupted.
(iii) Random number generators shall continue to perform correctly.
(iv) Game outcome decisions shall not be affected except for speed degradation.
(2) The client-server system shall function correctly after it has recovered from an excessive load.
(3) Recovery from excessive load may involve a system restart.
(d) Memory requirements. (1) Servers and clients may implement memory in any form, including random access memory of any kind, writeable flash, memory sticks, PCMCIA memory, and writable disks.
(2) Memory data storage shall be capable of preserving its contents for at least 90 days with power removed.
(3) Memory backup power sources, which may be rechargeable or non-rechargeable, shall meet the following conditions:
(i) Shall have the ability to fully recharge within 24 hours, if rechargeable; and
(ii) Shall have a life span of at least five years.
(4) Random access memory that uses an off-chip battery backup shall provide a method for the Electronic Player Station software to:
(i) Check for battery low/battery fail conditions on every power up and, at a minimum, every 24 hours; and
(ii) Interpret and act upon a battery low/battery fail condition.
(e) Network requirements. (1) Network infrastructure shall ensure that only gaming-related equipment can make a data-link layer connection to server or clients. For the purposes of this subsection, “gaming-related equipment” means:
(i) Casino monitoring systems;
(ii) Cashless gaming systems;
(iii) Voucher payment systems;
(iv) Player tracking systems;
(v) Progressive jackpot systems or controllers; or
(vi) Any other gaming-related equipment approved by the tribal gaming regulatory authority.
(2) If servers or clients are also connected to non-gaming computers, data may only transfer from the servers and clients to the non-gaming equipment. This shall be implemented through:
(i) Internal controls approved by the tribal gaming regulatory authority; and
(ii) Configuration of firewall devices so that only the servers and clients can establish the connection to be used for the data transfer.
(3) The network infrastructure shall report an event each time a data-link level connection is established or broken to a client or server. These events may be raised at the server, casino monitoring system or network control terminal.
(f) Communications protocol requirements. The following requirements apply to the communications within the client-server domain:
(1) Extensible protocols are permitted provided that any recipient shall explicitly reject options, commands, and responses that it does not support.
(2) The communications protocol shall be designed to support delivery of all data, including after a restart of a system component. The protocol is not required to support delivery in the case of a total failure of a system before all data is sent.
(3) The protocol shall ensure the correct delivery of data to the application in the order that the data was sent and without loss or duplication.
(4) The communications protocol shall be designed and implemented so there is no noticeable degradation of data integrity at bit error rates of 1 in 106.
(g) Failure/recovery requirements. (1) Client-server domains used in the play of Class II games shall provide a level of redundancy and a means of recovery such that the occurrence of any of the following will not lead to the loss of, or prevent recovery of, data stored in critical memory, including credit balance:
(i) Catastrophic client failure or failure of primary client components such as hard disks or other primary storage devices;
(ii) Catastrophic server failure, including replacement of server hardware or primary components; and
(iii) Total power failure, unless duplicated uninterruptible power supplies (UPSs) of requisite capacity are part of the domain specifications.
This section provides minimum standards for the Formal Application Configuration (FAC) document and verification tool required for submission of equipment, software, or modifications of equipment or software used with the play of Class II games to a test laboratory and to a tribal gaming regulatory authority pursuant to § 547.4(b)(2)-(4); for verification of game software on clients and servers pursuant to Start Printed Page 46355§ 547.18(a)(6) and § 547.19(b)(3); and EPROM control standards pursuant to § 542.13(g) of this chapter.
(a) Contents of the FAC document. (1) The Formal Application Configuration (FAC) document shall include a detailed file and directory listing of all of the following software, as applicable:
(i) .EXE, .DLL, .JAR and other executable files and their necessary components;
(iii) Stored database procedures;
(iv) Fixed parameter files affecting any game outcome, game mathematics, game denomination, or available prizes (excluding parameters expected to periodically change);
(v) Batch files;
(vi) Fixed data and graphic information;
(vii) Reports used to verify the correct working of the game software;
(viii) Compressed files expanded to be any of these; and
(ix) Any other software required by the tribal gaming regulatory authority.
(2) For all software listed in paragraph (a)(1) of this section, the FAC document shall include a signature or hash value calculated using an algorithm that meets the requirements of § 547.23(c). If the algorithm uses signature seeds (algorithm coefficients), each FAC record shall contain the signature result for each seed maintained by the verifying tool. Alternatively, the FAC document may contain a list of controlled directories and a signature value for each such directory as calculated by the verification tool.
(3) The FAC document shall identify all files that, if discovered to be altered or missing by the verification tool, require a shutdown of the server or client.
(4) The FAC document shall be labeled with a unique identifier indicating the software with which it is associated.
(5) The FAC document shall describe in detail the verification tool associated with it.
(b) FAC verification tool, generally. No particular implementation is required, unless required by the tribal gaming regulatory authority. Verification tools may include third-party program storage (ROM) verification devices; commonly available third-party signature algorithms; hashing formulas such as SHA-1, provided that they use a seed of not less than four digits as a part of the calculation; or any other implementation that meets the requirements of this section and contains or is able to access the listing of game software files, directories, and signatures presented in the FAC document for the purposes of comparison and verification.
(c) FAC verification tool, general methodology. The FAC verification tool shall be capable of:
(1) Searching through the directory structure of the game program storage media;
(2) Performing and reporting signature checks on files individually or on entire directories in the game software using an algorithm that:
(i) Meets the hashing requirements specified § 547.23(c);
(ii) Processes individual software components, fixed data components, and entire software suites; and
(iii) Is capable of using a seeding methodology that will allow for a random or manually selected seed as part of the signature calculation—if the algorithm requires signature seeds, these shall be manually entered or selected from an external device or randomly selected from a pool of seeds and checksums;
(3) Comparing files and directories in the game software, or their signatures, with the files and directories, or their signatures, in the FAC listing provided in the FAC document.
(4) Reporting file names, time and date stamps, and size for all files and directories;
(5) Reporting the following error conditions, which shall be logged and reported to the tribal gaming regulatory authority:
(i) Mismatching or modified files and directories;
(ii) Files or directories present in the game software but not in the FAC listing; and
(iii) Files or directories present in the FAC listing but not the game software;
(6) And any other requirements specified by the tribal gaming regulatory authority.
(d) FAC verification tool, specific requirements. Notwithstanding the requirements of paragraphs (b) through (c) of this section, the implementation of the verification tool shall meet the following requirements:
(1) The verification tool shall not be spoofed by a program or thread operating on the hardware and software under test; and
(2) The FAC listing in, or available to, the verification tool shall be encrypted using a methodology that satisfies the requirements of § 547.23(b).
(e) FAC verification tool, external locations. (1) The verification tool may reside on a medium external to the Class II client-server implementation.
(f) FAC verification tool located on a server. The verification tool may reside on a server. In such a case:
(1) The server shall contain the FAC listings for each client.
(2) The server shall initiate verification of the client by passing the FAC without signatures to the client.
(3) The client shall pass the signature results to the server for verification.
(4) Errors and warnings identified during the test shall be logged on the server or an external monitoring system and reported to the screen of the server. Failure or error on critical software files does not require that the device be immediately disabled unless the check failure occurs immediately after the software download verification required by § 547.18(a)(6).
(g) FAC self-verification. A server or client may self verify, i.e. use a verification located on that server or client for the purpose of checking the software it contains, provided that:
(1) One or more base devices at the beginning of a chain of security verify peer devices, and the base device(s) are themselves verified by some external means. An example of such a technique is when the Boot ROM for a PC is modified to check running versions of software before enabling this software to run; the Boot ROM could be in a removable EPROM which could be verified by an external EPROM verifier.
(2) The verification tool is itself verified by the gaming laboratory and the tribal gaming regulatory authority as secure from tampering or compromise.
(3) Self-verification is implemented only in addition to, not in lieu of, other verification tool options allowed by paragraphs (e) and (f) of this section.
(h) Running the FAC verification tool. The FAC verification tool shall be run to verify the authenticity of Class II game software and paytables:
(1) Following the addition, removal, or change of game software or paytables pursuant to § 547.19;
(2) Following the download of game software or paytables pursuant to § 547.18;
(3) Pursuant to EPROM control standards adopted by the tribal gaming regulatory authority in accordance with § 542.13(g) of this chapter;
(4) After recovery from any power failure or upon power up; and
(5) At any other time required by the tribal gaming regulatory authority.
(i) Verification of non-interrogatable devices. Program devices that cannot be interrogated, such as Smart cards, may be used provided they are able to be verified by the following FAC methodology:
(1) A challenge is sent by the peer device, such as a hashing seed, to which Start Printed Page 46356the device must respond with a checksum of its entire program space using the challenge value.
(2) The challenge mechanism and means of loading the software into the device is verified by the independent testing laboratory and approved by the tribal gaming regulatory authority.
This section provides standards for the downloading of Class II games or paytables to clients or servers on the casino floor for patron play.
(a) Downloads. (1) Downloads of games, paytables, peripheral software or other download packages shall be conducted only as authorized by the tribal gaming regulatory authority.
(2) Downloads of download packages shall be conducted only from an approved Download Server. The Download Server may be the main game server or a separate computer device, in which case that device must meet the server standards of section § 547.6 and be separately approved by the tribal gaming regulatory authority.
(3) Downloads conducted during operational periods shall be performed in a manner which will not affect play on Electronic Player Stations that are not the subject of the download.
(4) Downloaded games shall not be played in more than one configuration on any given Electronic Player Station during any one gaming day, unless separate metering for each configuration can be maintained.
(5) Downloads shall use a secure protocol that will deliver the download data without alteration or modification, even if errors occur during communication.
(6) The software, paytables, peripheral software or other download packages shall be verified following download using a FAC verification tool and new Formal Application Configuration conforming to § 547.17.
(7) The integrity of the master meter set and critical memory shall be maintained after a download.
(8) Power loss or communications loss during a download shall result either in recommencement or continuation of download and not require operator intervention.
(9) The server shall log each download of any Download Package.
(10) Each log record shall contain as a minimum:
(i) The time and date of the initiation of the download;
(ii) The time and date of the completion of the download;
(iii) The client player station(s) to which software was downloaded;
(iv) The version(s) of download package and any embedded software downloaded. Logging of the unique FAC identifier will satisfy this requirement;
(v) The user who initiated the download;
(vi) The outcome of the FAC verification following the download (success or failure).
(11) Download logs shall be retained for a period of one year from the date of the download. These logs may be kept in an archived manner, on the server or elsewhere, provided that the information reconciles across replicated storage and that the information can be produced within 24 hours upon request. In any event, download logs for the previous 72 hours shall be immediately accessible.
(b) Interim Storage or actuation of Download Packages. If Download packages are loaded to interim storage and not to the Electronic Player Station or peripheral for immediate activation, then the interim storage shall be:
(1) A component within the logic area of the client device; or
(2) A separate device, such as a processor board, that resides within a logic area of the client device and meets the requirements of:
(i) Section 547.5;
(ii) Section 547.10(a), if residing in a separate cabinet;
(iii) Section 547.11;
(iv) Section 547.1(d);
(v) Section 547.16(g); and
(vi) Section 547.17.
(c) Actuation of Download Packages. (1) Actuation of Download Packages shall be conducted only as authorized by the tribal gaming regulatory authority.
(2) Actuation of Download Package shall not be permitted if an error or tilt condition exists on the destination device or Electronic Player Station.
(3) If the actuation process involves transfer of data from interim storage to the Electronic Player Station, the communications method must meet the requirements of paragraph (a)(5) of this section, and cryptographic protection is not necessary if the data transfer is contained within one logic area.
(4) The server shall permanently log each instance of package actuation as required by paragraphs (a)(9) and (10) of this section.
(d) Download of peripheral software. Peripherals, such as bill acceptors, may have their software, firmware or configuration updated by the client device provided:
(1) The Download Package containing the peripheral software has been previously approved by the tribal gaming regulatory authority.
(2) The process of transfer the peripheral software is secure and meets the specification of the communication protocol to the peripheral.
This section provides standards for adding, removing, or swapping to different Class II games and paytables on client-server implementations by a method other than the download of software. Downloadable software is the subject of § 547.18. The actions described in this section may be initiated by command at the client station, external command initiated by the server, or actuation of a Download Package previously downloaded that performs approved reconfiguration commands or other methods approved by the tribal gaming authority.
(a) Adding or changing games or paytables, authorization. Game software and paytables shall be added to, or changed on, a client-server implementation and made available to patrons for play only as authorized by the tribal gaming regulatory authority.
(b) Adding or changing games or paytables, process. (1) All Electronic Player Stations that are to have game software or paytables added or changed shall be disabled for play before the addition or change occurs.
(2) An updated Formal Application Configuration meeting the requirements of § 547.17 shall be installed or otherwise made available for use by the FAC verification tool to verify the changed game software or paytables.
(3) The added or changed game software or paytables shall be verified on the server or Electronic Player Station, as applicable, using a FAC verification tool and new Formal Application Configuration that conforms with § 547.17 prior to re-enabling the Electronic Player Stations or clients for play.
(c) Display following change. Immediately following reenabling, the Electronic Player Station shall;
(1) Reset the win meter to zero;
(2) Reset any player options selected (e.g. bet amount, lines played, etc.) to the minimum available value and apply this value or values to appropriate on-screen displays; and
(3) Change, if necessary, the display of the game screen to a non-winning result or combination.
(d) Deleting paytables, authorization. (1) Paytables shall only be deleted from a client—server implementation as Start Printed Page 46357authorized by the tribal gaming regulatory authority.
(2) The remaining game software and paytables shall be verified on the server, Electronic Player Stations, or clients, as applicable, using a FAC verification tool and new Formal Application Configuration that conforms with § 547.17.
(e) Deleting games, authorization and requirements. (1) Games shall be deleted from a client—server implementation only as authorized by the tribal gaming regulatory authority.
(2) In any event, games shall be deleted only if:
(i) There are no incomplete instances of the game outstanding; and
(ii) All Electronic Player Stations that are to have game software or paytables deleted shall be disabled for play before the deletion occurs.
(3) The remaining game software and paytables shall be verified on the server, Electronic Player Stations, or clients, as applicable, using a FAC verification tool and new Formal Application Configuration that conforms with § 547.17.
(f) Audit trail. An automatic audit trail of all game software and pay table changes shall be maintained and shall include, at a minimum:
(1) The identity of the person making the change(s), if the client-server implementation requires identification or log-in for the person(s) making changes;
(2) The time and date of the change(s);
(3) The type of change(s), (e.g. addition, change, or deletion of game / pay table); and
(4) Application parameters or variables.
This section provides minimum standards for removable, (re-)writable, and non-writable storage for programs used with the play of Class II game software.
(a) Removable program storage media. (1) All removable program storage media such as ROMs, EPROMs, Flash ROMs, CD-ROMs, DVDs etc. shall be clearly marked with sufficient information to identify the software and version or revision level contained.
(2) All removable program storage media shall maintain an internal checksum or signature of its contents. Verification of this checksum or signature is to be performed after every restart and, if the verification fails, the Electronic Player Station shall enter a fatal error state.
(b) Non-writeable program storage media. (1) All EPROMs and Programmable Logic Devices (PLDs) that have erasure windows shall be fitted with covers over their erasure windows.
(2) All unused areas of EPROMs shall be written with the inverse of the erased state, e.g., zero bits (00 hex) for most EPROMs, random data, or repeats of the program data.
(3) Flash memory storage devices intended to have the same logical function as ROM, i.e. not to be dynamically written, shall be write protected or otherwise protected from unauthorized modification.
(4) Re-writeable CD-ROMs shall not be used.
(5) The write cycle shall be closed or finished for all CD-ROMs such that it is not possible to write any further data to the CD.
(6) Write protected hard disks are permitted if the means of enabling the write protect is easily viewable and can be sealed in place.
(c) (Re-)Writeable program storage media. (1) (Re-)writable program storage, such as hard disks, Flash memory, writable CD-ROMs, and writable DVDs, may be used provided that the verification requirements of § 547.19(b) and § 547.18(a)(6) are met.
(2) Program storage is structured so there is an obvious separation of fixed data (e.g. program, fixed parameters, DLLs) and variable data.
(d) Identification of program storage media. All discrete program storage media (e.g. EPROM, CD-ROM) shall be uniquely identified, displaying:
(2) Game name;
(3) Game development number or variation;
(4) Version number;
(6) Type and size of media; and
(7) Location in Electronic Player Station, if critical (e.g. socket position 3 on PCB).
This section provides minimum standards for random number generators (RNGs) used with the play of Class II games and for cryptography.
(a) Properties. All RNGs shall produce output having the following cryptographic properties:
(1) Statistical randomness;
(2) Unpredictability; and
(b) Statistical Randomness. (1) Numbers produced by an RNG shall be statistically random individually and in the permutations and combination used in the application under the rules of the game. For example, if a Bingo game with 75 balls has a progressive winning pattern of the five numbers on the bottom of the card and the winning of this prize is defined to be the five numbers are matched in the first five balls drawn, the likelihood of each of the 75C5 combinations are to be verified to be statistically equal.
(2) Numbers produced by an RNG shall pass the statistical tests for randomness to a 99% confidence level, which may include:
(i) Chi-square test;
(ii) Equi-distribution (frequency) test;
(iii) Gap test;
(iv) Poker test;
(v) Coupon collector's test;
(vi) Permutation test;
(vii) Run test (patterns of occurrences shall not be recurrent); (viii) Spectral test;
(ix) Serial correlation test potency and degree of serial correlation (outcomes shall be independent from the previous game); and
(x) Test on subsequences.
(c) Unpredictability. (1) It shall not be feasible to predict future outputs of an RNG, even if the algorithm and the past sequence of outputs are known.
(2) Unpredictability shall be ensured by re-seeding or by continuously cycling the RNG, and by providing a sufficient number of RNG states for the applications supported.
(i) Re-seeding may be used where the re-seeding input is at least as statistically random as, and independent of, the output of the RNG being re-seeded.
(ii) The number of RNG states shall be larger than the number of possible outcomes in the application for which the RNG is used by at least a factor of 108.
(d) Non-repeatability. The RNG shall not reproduce the same output stream that it has produced before, nor shall any two instances of an RNG produce the same stream as each other. This property shall be ensured by initial seeding that comes from:
(1) A source of “true” randomness, such as a hardware random noise generator; or
(2) A combination of timestamps, parameters unique to a server or Electronic Player Station, previous RNG outputs, etc.
(e) General requirements. (1) Game software that calls an RNG to simulate an event of chance shall immediately use the output returned in accordance with the game rules.
(2) RNG outputs shall not be arbitrarily discarded or selected.
(3) Where a sequence of outputs is required, the whole of the sequence shall be used in accordance with the game rules. Start Printed Page 46358
(f) Scaling algorithms and scaled numbers. An RNG that provides output scaled to given ranges shall:
(1) Meet the requirements of paragraphs (a) through (d) of this section and be independent and uniform over the range;
(2) Provide numbers scaled to the ranges required by game rules, and notwithstanding the requirements of paragraph (e)(2) of this section, may discard numbers that do not map uniformly onto the required range but shall use the first number in sequence which does map correctly to the range;
(3) Be capable of producing every possible outcome of a game according to its rules; and
(4) Use an unbiased algorithm. A scaling algorithm is considered to unbiased if the measured bias is no greater than 1 in 100 million.
(g) RNGs used for cryptography. (1) RNGs used for cryptography shall:
(i) Be separate from RNGs used for other purposes;
(ii) Be accessible only by the components that implement the security functionality;
(iii) Not weaken security by providing a point of attack on the security protocols that it supports;
(iv) Have a number of states at least as great as the encryption strength—for example, an RNG using 128 bit encryption shall have at least 2128 states;
(v) Make use of an entropy source in its initial and ongoing seeding, unless a security protocol requires that a recipient's (pseudo) RNG supplied with correct key information reproduces the same sequence as the sender's RNG; and
(vi) Be re-seeded at a rate that makes cryptoanalytic attack impractical.
(2) RNG components used for cryptography shall notify callers in the event of a malfunction.
(3) Security system components reliant on RNG outputs shall cease to operate when a fault is detected in the operation of the RNG and security can no longer be assured.
This section provides minimum standards for data communications with gaming equipment, or components, used with the play of Class II games. This section also provides minimum standards for communications between the Class II gaming equipment and any equipment external to it.
(a) Electrical requirements. (1) Communication interfaces on Electronic Player Stations shall have at least 3 Kv of line isolation to achieve mains power static discharge immunity from lightning and other static discharges.
(2) When subjected to electrostatic discharges, Electronic Player Stations shall not interfere with the operation of any other attached equipment via local data communications cabling.
(3) When subject to disruption of the mains power, Electronic Player Stations shall not interfere with the operation of any other attached gaming device via local data communications cabling.
(4) Electronic Player Stations and successive devices in any communications chain shall be powered from different sources.
(5) There shall be no mains ground interconnections via data cabling between Electronic Player Stations powered from different supply circuits unless adequate line isolation is in place. Note that RS-232-C may be used only if the two communicating devices are powered from the same supply circuit and the cable length between the two devices is less than 15 feet.
(b) Functional requirements, generally. (1) Data communications shall be designed to allow transfer of game play financial information and event data to a casino operating system on a regulator schedule or on demand.
(2) After gaming equipment has been de-activated, activating the gaming equipment requires manual intervention by the gaming operator, except that:
(i) An Electronic Player Station may automatically re-activate upon restoration of communications following a communications failure, unless it determines that lock-up state should apply due to some other cause; and
(ii) If gaming equipment is automatically de-activated at the end of the venue's current session (e.g., an automatic deactivation date/time calendar exists), it is permissible for the casino monitoring system to automatically re-activate the gaming equipment when the next permitted session commences.
(3) When more than one Electronic Player Station or client communicates using the same transmission medium, the communications port shall operate at a communication speed within a 1% tolerance of the required communications speed, unless the specific communications protocol allows a greater tolerance.
(c) Protocol requirements. (1) All communications shall be made via a protocol-based communications scheme unless otherwise authorized by the tribal gaming regulatory authority.
(2) Communications protocols shall include:
(i) Error control;
(ii) Flow control; and
(iii) Link control (remote connection).
(3) For serial communication links, data communications shall make use of suitable error detection algorithms. At a minimum, Cyclic Redundancy Checks (CRCs) shall be used for this purpose. The use of only parity or simple checksum byte is not acceptable.
(4) Data communications shall be able to withstand varying error rates.
(d) Communications failures and recovery. (1) During any communications failure and recovery, no data shall be lost, duplicated, modified or re-ordered.
(2) Failures and re-establishment of communications shall be logged as events by the Electronic Player Station or server.
(3) On program resumption, e.g., after a power restart of the equipment, any communications to an external device shall not begin until the program resumption routine, including self-tests, is completed successfully.
(4) When a non-correctable critical storage error has occurred, the data on the Electronic Player Station can no longer be considered reliable. Accordingly, any communication to external devices shall cease immediately and an appropriate message shall be displayed.
(e) Wireless communications. Wireless communications may be used within and to Class II gaming equipment provided the following requirements are met:
(1) Wireless access points must be installed so the general public cannot physically access them.
(2) External switches that reset device configuration to a default state must be disabled unless that default state meets the requirements of this paragraph (e).
(3) Open or unencrypted Wi-Fi communications are prohibited.
(4) 802.11i in combination with 802.1X and Radius authentication servers is an acceptable method for securing wireless communications. The device/user authentication mechanism must employ digital certificates, two-factor methods or similarly strong techniques. Use of simple passwords is not acceptable.
(5) WPA and WEP are not acceptable methods for securing wireless communications.
(6) VPNs shall be used for end-to-end communication, and any wireless portion of the connection must meet the requirements of this paragraph (e).
(7) The portions of the network that contain wireless access points must be separated from the rest of the network by firewalls.
(8) Wireless access points must have MAC filtering capabilities. MAC filters on Wireless Access Points must be Start Printed Page 46359enabled (only devices using registered MAC addresses can connect).
(9) The SSID in 802.11 networks must be changed to be different to the default factory setting.
(10) The SSID in 802.11 networks must not be broadcast in response to broadcast probe requests.
(11) Peer-to-peer networking (a.k.a. ad-hoc mode) shall be disabled on all wireless devices, except for the purpose of communicating with peripheral devices in a small-radius personal area network.
(12) The Beacon Interval in 802.11 networks must be increased to the maximum value of 67 seconds.
(13) Access through SNMP must be restricted:
(i) SNMP must be disabled unless it is in active use through a network management system.
(ii) SNMP and SNMP v2 are not acceptable.
(iii) If SNMP v3 is proposed, the configuration must change read and write community strings away from default values (typically “public” and “private” respectively).
(14) DHCP must be disabled, which means statically configuring IP addresses into end devices.
(15) Username and passwords must be changed from factory default.
(16) Insecure usernames and passwords (e.g. anonymous/anonymous) must be deleted from any Wireless Access Point.
(17) Wireless communications may not be used to circumvent restrictions limiting gambling to the casino floor or other designated areas. Implementation, therefore, of wireless communications may require the tribal gaming regulatory authority to implement requirements for blocking capabilities in various locations.
This section provides minimum standards for encryption and hashing in client-server implementations used with the play of Class II games.
(a) Encryption generally. (1) Communications across public areas shall be encrypted.
(2) Communications across publicly accessible networks shall be encrypted. These include Ethernet networks or any networks that use routers, all wireless communications, communications across wide area networks.
(3) Proprietary or closed loop networks need not be encrypted but shall be physically secure such that intrusion is detectable.
(4) Notwithstanding paragraphs (a)(1) through (3) of this section, communications containing any of the following need not be encrypted but must be protected against illicit alteration, unless contained within a single logic area:
(i) Software uploads and downloads;
(ii) Game outcome information; and
(iii) Progressive jackpot meters, parameters, configuration, and win messages.
Note that message authentication codes based upon hashing algorithms that meet the requirements of paragraph (c) of this section are sufficient to meet this requirement.
(5) Notwithstanding paragraphs (a)(1) through (3) of this section, communications containing any of the following shall be protected from eavesdropping i.e. encrypted, and from illicit alteration unless the communication is contained within a single logic area:
(i) RNG seeds and outcomes;
(ii) Encryption keys, where the implementation chosen requires transmission of keys;
(v) Ticket voucher transactions;
(vi) Transfers of money to/from player accounts, pursuant to § 542.13(o)(3)(iii) of this chapter;
(vii) Transfer of money between gaming equipment, pursuant to § 542.13(o)(3)(iii) of this chapter;
(viii) Player tracking information;
(6) If key data files containing pull tabs game results are maintained on a disk on the server and/or clients, the files shall be encrypted.
(b) Encryption algorithm. Any encryption required by this part shall use an algorithm that meets the following requirements:
(1) Encryption algorithms are to be demonstrably secure against cryptanalytic attacks. Encryption algorithms that media reports have demonstrated to be broken are not demonstrably secure. The following algorithms are demonstrably secure:
(i) SSL/TLS (Using a Public Key algorithm);
(ii) IPSec—(Potentially a “Hardware” solution);
(iii) Triple DES (Symmetric algorithm using a 112 bit key);
(iv) IDEA (Symmetric algorithm using a 128 bit key);
(v) Blowfish (Symmetric algorithm using a 448 bit key);
(vi) Twofish (Symmetric algorithm using a 128-bit, 192-bit or 256-bit key); and
(vii) AES (Symmetric algorithm using a 128-bit, 192-bit or 256-bit key).
(2) The minimum width (size) for encryption keys is 112 bits for symmetric algorithms and 1024 bits for public key algorithms.
(3) If a symmetric algorithm is chosen, a key rotation methodology ensuring encryption keys are changed no less than every 30 days shall be adopted. The key rotation process shall be automated.
(4) There shall be a secure method implemented for changing the current encryption key set. An example of an acceptable method of exchanging keys is the use of public key encryption techniques to transfer new key sets.
(5) Other proprietary encryption and authentication methods, including the use of a Virtual Private Network (VPN), are permissible provided they provide protection against eavesdropping and illicit modification equivalent to the methods described paragraphs (a) and (b) of this section.
(c) Hashing algorithms. Any hashing required by this part shall use an algorithm having the following characteristics:
(1) The hashing algorithm shall combine the entire contents of the files or data being processed.
(2) The hashing algorithm shall combine the bits in a complicated and cross-interactive manner.
(3) The hashing algorithm shall detect at least 99.998% of all possible altered files or data.
(4) The hashing algorithm shall be cryptographically strong, i.e. by looking at the hash result there is no practical way, in a given period of time, to derive any part of the original data.
(5) If the hashing algorithm uses seeds (algorithm coefficients), the “seed” information shall influence the behavior of the algorithm in a non-trivial way.
This section provides standards for the display of game artwork, the displays on belly or top glass, and the display and disclosure of game rules, whether in physical or electronic form.
(a) Rules, instructions, and pay tables, generally. The Electronic Player Station shall at all times display, or make readily available to the player upon request, the following:
(1) Game name, rules, and options such as number of coins wagered stated clearly and unambiguously, without the capability to mislead. all prizes advertised shall be available to win;
(3) Instructions for play on, and use of, the Electronic Player Station, including the functions of all buttons;
(4) A paytable or other explanation, sufficient to allow a player to determine the correctness of all prizes awarded, including. Start Printed Page 46360
(i) The range and values obtainable for any variable prize;
(ii) Whether the value of a prize depends on credits wagered;
(iii) The means of division of any pari-mutuel prizes; and
(iv) The paytable or other explanation need not, however, that subsets of winning patterns are not awarded additional pays (e.g. five in a row does not also pay three in a row or four in a row) unless there are exceptions, which shall be clearly stated.
(b) Disclaimers. The Electronic Player Station shall at all times display:
(1) “Malfunctions void all pays and plays”
(2) “Actual Win Determined by Bingo [or other applicable Class II game] Play. Pay Table Lines and Reels for Entertainment Only.”
(c) Stickers. Stickers may be used on Electronic Player Stations provided that they:
(1) Do not shrink or peel with time or heat;
(2) Are not easily removed;
(3) Meet applicable part number requirements, which may be affixed to the sticker backing or surroundings when size limitations occur.
The section provides general standards for a client-server implementation used with the play of Class II games to interface with a casino monitoring or accounting system. This section also provides general standards for servers acting as monitoring or accounting systems.
(a) Monitoring or accounting system interface, generally. (1) Client-sever implementations used with the play of Class II games shall be interfaced to an on-line monitoring system that processes security, maintenance and financial data and provides accounting data to the operator. An on-line monitoring system is required in all cases where remote monitoring is allowed.
(2) Data communications with the casino monitoring system shall meet the requirements of § 547.22.
(3) An on-line monitoring system may be located locally within a facility or remotely outside of the facility.
(4) The on-line monitoring at the minimum shall provide a statistical analysis for verification of correct performance/return to player for each Electronic Player Station.
(b) Servers acting as monitoring or accounting systems. The components or functions of an on-line monitoring system may be embedded within the game server. If so, the following requirements apply:
(1) The server shall not permit the alteration of any information.
(2) The server shall have a backup and archive utility to allow the operator to save data in critical memory in the event of a system failure. In the event of a catastrophe that results in a failure whereby the servers cannot be restarted, it shall be possible to reload the system to a backup point and to fully recover the contents of that backup.
(a) Tribal gaming regulatory authority approval. (1) A tribal gaming regulatory authority may approve a variance from the requirements of this part for a gaming operation if it has determined that the variance will achieve a level of security and game integrity sufficient to accomplish the purpose of the standard it is to replace.
(2) For each enumerated standard for which the tribal gaming regulatory authority approves a variance, it shall submit to the Commission Chairman, within 30 days, a detailed report, which shall include the following:
(i) A detailed description of the variance;
(ii) An explanation of how the variance achieves a level of security sufficient to accomplish the purpose of the standard it is to replace and of any equipment or software to be implemented with the variance;
(iii) An evaluation of the variance from an independent testing laboratory recognized by the Commission pursuant to § 546.9(f) of this chapter; and
(iv) Evidence that the tribal gaming regulatory authority has approved the variance.
(3) In the event that the tribal gaming regulatory authority or the tribe chooses to submit a variance request directly to the Chairman, it may do so without the approval requirement set forth in paragraph (a)(2)(iv) of this section.
(b) Review by the Chairman. (1) Following receipt of the variance approval, the Chairman or his designee shall have 60 days to concur with or object to the approval of the variance.
(2) Any objection raised by the Chairman shall be in the form of a written explanation and be based upon the following criteria:
(i) There is no valid explanation of why the gaming operation should have received a variance approval from the tribal gaming regulatory authority on the enumerated standard; or
(ii) The variance as approved by the tribal gaming regulatory authority does not provide a level of security or game integrity sufficient to accomplish the purpose of the standard it is to replace.
(3) If the Chairman fails to object in writing within 60 days after the date of receipt of a complete submission, the variance shall be considered concurred with by the Chairman.
(4) The 60-day deadline may be extended, provided such extension is mutually agreed upon by the tribal gaming regulatory authority and the Chairman.
(c) Curing Chairman's objections. (1) Following an objection by the Chairman to the issuance of a variance, the tribal gaming regulatory authority shall have the opportunity to cure any objections noted by the Chairman.
(2) A tribal gaming regulatory authority may cure the objections raised by the Chairman by:
(i) Rescinding its initial approval of the variance; or
(ii) Rescinding its initial approval, revising the variance, approving it, and resubmitting it to the Chairman.
(3) Upon any re-submission of a variance approval, the Chairman shall have 30 days to concur with or object to the re-submitted variance.
(4) If the Commission fails to object in writing within 30 days after the date of receipt of the re-submitted variance, the re-submitted variance shall be considered concurred with by the Chairman.
(d) Appeals. (1) Upon receipt of objections to a re-submission of a variance, the tribal gaming regulatory authority shall be entitled to an appeal to the full Commission in accordance with the following process:
(i) Within 30 days of receiving an objection to a re-submission, the tribal gaming regulatory authority shall file its notice of appeal.
(ii) Failure to file an appeal within the time provided by this section shall result in a waiver of the opportunity for an appeal.
(iii) An appeal under this section shall specify the reasons why the tribal gaming regulatory authority believes the Chairman's objections should be reviewed, and shall include supporting documentation, if any.
(iv) The tribal gaming regulatory authority shall be provided with any comments offered by the Chairman to the Commission on the substance of the appeal, and the tribal gaming regulatory authority shall have the opportunity to respond to any such comments.
(v) Within 30 days after receipt of the appeal, the Commission shall render a decision based upon the criteria contained within paragraph (b)(2) of this section unless the tribal gaming regulatory authority elects to wave the Start Printed Page 4636130-day requirement and to provide the Commission with additional time, not to exceed an additional 30 days, to render a decision.
(vi) In the absence of a decision within the time provided, the tribal gaming regulatory authority's resubmission shall be considered concurred with and become effective.
(2) The tribal gaming regulatory authority may, without resubmitting the variance, appeal the Chairman's objection to the approval of a variance to the full Commission by filing a notice of appeal within 30 days of the Chairman's objection and complying with the procedures set out in paragraph (d)(1) of this section.
(e) Effective Date of variance. The gaming operation shall comply with standards that achieve a level of security or game integrity sufficient to accomplish the purpose of the standard it is to replace until such time as the Chairman objects to the Tribal gaming regulatory authority's approval of a variance as provided in paragraph (b) of this section.
(f) Discretion. Concurrence in a variance by the Chairman or by the Commission is discretionary and variances will not be granted routinely. The gaming operation shall comply with standards at least as stringent as those set forth in this part until such time as the Chairman or the Commission concurs with the tribal gaming regulatory authority's approval of the variance.
Dated: August 1, 2006.
Philip N. Hogen,
Cloyce V. Choney,
[FR Doc. 06-6787 Filed 8-10-06; 8:45 am]
BILLING CODE 7565-01-P