This section provides general software standards for Class II gaming systems for the play of Class II games.
(a) Player interface displays.
(1)
If not otherwise provided to the player, the player interface shall display the following:
(i)
The purchase or wager amount;
(iii)
Any player credit balance.
(2)
Between plays of any game and until the start of the next play, or until the player selects a new game option such as purchase or wager amount or card selection, whichever is earlier, if not otherwise provided to the player, the player interface shall display:
(i)
The total purchase or wager amount and all prizes and total credits won for the last game played;
(ii)
The final results for the last game played, including entertaining displays of results, if any; and
(iii)
Any default purchase or wager amount for the next play.
(b) Game initiation and play.
(1)
Each game played on the Class II gaming system shall follow and not deviate from a constant set of rules for each game provided to players pursuant to § 547.16. Any change in rules constitutes a different game. There shall be no automatic or undisclosed changes of rules.
(2)
For bingo games and games similar to bingo, the Class II gaming system shall not alter or allow to be altered the card permutations or game rules used for play of a Class II game unless specifically chosen by the player prior to commitment to participate in the game. No duplicate cards shall be sold for any common draw.
(3)
No game play shall commence and, no financial instrument or credit shall be accepted on the affected player interface, in the presence of any fault condition that affects the outcome of the game, open door, or while in test, audit, or lock-up mode.
(4)
The player must choose to participate in the play of a game.
(c) Audit Mode.
(1)
If an audit mode is provided, the Class II gaming system shall provide, for those components actively involved in the audit:
(i)
All accounting functions required by § 547.9, by applicable provisions of any Commission regulations governing minimum internal control standards, and by any internal controls adopted by the tribe or tribal gaming regulatory authority;
(ii)
Display player interface identification; and
(iii)
Display software version or game identification;
(2)
Audit mode shall be accessible by a secure method such as an employee PIN and key or other auditable access control.
(3)
Accounting function data shall be accessible by an authorized person at any time, except during a payout, during a handpay, or during play.
(4)
The Class II gaming system shall disable financial instrument acceptance on the affected player interface while in audit mode, except during financial instrument acceptance testing.
(d) Last game recall.
The last game recall function shall:
(1)
Be retrievable at all times, other than when the recall component is involved in the play of a game, upon the operation of an external key-switch, entry of an audit card, or a similar method;
(2)
Display the results of recalled games as originally displayed or in text representation, including entertaining display results implemented in video, rather than electro-mechanical, form, if any, so as to enable the tribal gaming regulatory authority or operator to clearly identify the game sequences and results that occurred;
(3)
Allow the Class II gaming system component providing game recall, upon return to normal game play mode, to restore any affected display to the positions, forms and values displayed before access to the game recall information; and
(4)
Provide the following information for the current and previous four games played and shall display:
(i)
Game start time, end time, and date;
(ii)
The total number of credits at the start of play, less the purchase or wager amount;
(iii)
The purchase or wager amount;
(iv)
The total number of credits at the end of play; and
(v)
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.
(vi)
For bingo games and games similar to bingo only, also display:
(A)
The card(s) used by the player;
(B)
The identifier of the bingo game played;
(C)
The numbers or other designations drawn, in the order that they were drawn;
(D)
The numbers or other designations and prize patterns covered on each card;
(E)
All prizes won by the player, including winning patterns and entertaining displays implemented in video, rather than electro-mechanical form, if any; and
(F)
The unique identifier of the card on which prizes were won;
(vii)
For pull-tab games only, also display:
(A)
The result(s) of each pull-tab, displayed in the same pattern as on the tangible pull-tab;
(B)
All prizes won by the player;
(C)
The unique identifier of each pull tab; and
(D)
Any other information necessary to fully reconstruct the current and four previous plays.
(e) Voucher and credit transfer recall.
Notwithstanding the requirements of any other section in this part, a Class II gaming system shall have the capacity to:
(1)
Display the information specified in § 547.11(b)(5)(ii) through (vi) for the last five vouchers or coupons printed and the last five vouchers or coupons accepted; and
(2)
Display a complete transaction history for the last five cashless transactions made and the last five cashless transactions accepted.
(f) Software signature verification.
The manufacturer or developer of the Class II gaming system must provide to the testing laboratory and to the tribal gaming regulatory authority an industry-standard methodology, acceptable to the tribal gaming regulatory authority, for verifying the Class II gaming system game software. By way of illustration, for game software stored on rewritable media, such methodologies include signature algorithms and hashing formulas such as SHA-1.
(g) Test, diagnostic, and demonstration modes.
If test, diagnostic, and/or demonstration modes are provided, the Class II gaming system shall, for those components actively involved in the test, diagnostic, or demonstration mode:
(1)
Clearly indicate when that component is in the test, diagnostic, or demonstration mode;
(2)
Not alter financial data on that component other than temporary data;
(3)
Only be available after entering a specific mode;
(4)
Disable credit acceptance and payment unless credit acceptance or payment is being tested; and
(5)
Terminate all mode-specific functions upon exiting a mode.
(h) Multi-game.
If multiple games are offered for player selection at the player interface, the player interface shall:
(1)
Provide a display of available games;
(2)
Provide the means of selecting among them;
(3)
Display the full amount of the player's credit balance;
(4)
Identify the game selected or being played; and
(5)
Not force the play of a game after its selection.
(i) Program interruption and resumption.
The Class II gaming system software shall be designed so that upon resumption following any interruption, the system:
(1)
Is able to return to a known state;
(2)
Shall check for any fault condition upon resumption;
(3)
Shall verify the integrity of data stored in critical memory;
(4)
Shall return the purchase or wager amount to the player in accordance with the rules of the game; and
(5)
Shall detect any change or corruption in the Class II gaming system software.
(j) Class II gaming system components acting as progressive controllers.
This paragraph applies to progressive controllers and components acting as progressive controllers in Class II gaming systems.
(1)
Modification of progressive parameters shall be conducted in a secure manner approved by the tribal gaming regulatory authority. Such parameters may include:
(ii)
Secondary pool increment(s);
(iv)
Maximum value(s); and
(v)
Identity of participating player interfaces.
(2)
The Class II gaming system component or other progressive controller shall provide a means of creating a progressive balancing report for each progressive link it controls. At a minimum, that report shall provide balancing of the changes of the progressive amount, including progressive prizes won, for all participating player interfaces versus current progressive amount(s), plus progressive prizes. In addition, the report shall account for, and not be made inaccurate by, unusual events such as:
(i)
Class II gaming system critical memory clears;
(ii)
Modification, alteration, or deletion of progressive prizes;
(iii)
Offline equipment; or
(iv)
Multiple site progressive prizes.
(k) Critical memory.
(1)
Critical memory may be located anywhere within the Class II gaming system. Critical memory is any memory that maintains any of the following data:
(iii)
Configuration data;
(iv)
Last game recall information required by § 547.8(d) ;
(v)
Game recall information for the current game, if incomplete;
(vi)
Software state (the last normal state software was in before interruption);
(vii)
RNG seed(s), if necessary for maintaining integrity;
(viii)
Encryption keys, if necessary for maintaining integrity;
(ix)
Progressive prize parameters and current values;
(x)
The five most recent financial instruments accepted by type, excluding coins and tokens;
(xi)
The five most recent financial instruments dispensed by type, excluding coins and tokens; and
(xii)
The five most recent cashless transactions paid and the five most recent cashless transactions accepted.
(2)
Critical memory shall be maintained using a methodology that enables errors to be identified and acted upon. All accounting and recall functions shall be verified as necessary to ensure their ongoing integrity.
(3)
The validity of affected data stored in critical memory shall be checked after each of the following events:
(ii)
Each attendant paid win;
(iii)
Each attendant paid progressive win;
(iv)
Each sensored door closure; and
(v)
Every reconfiguration, download, or change of prize schedule or denomination requiring operator intervention or action.
(l) Secured access.
Class II gaming systems that use a logon or other means of secured access shall include a user account lockout after a predetermined number of consecutive failed attempts to access system.