A{grave over ( )}s	4	A{grave over ( )}s	3
K{grave over ( )}s	4	K{grave over ( )}s	4
Q{grave over ( )}s	4	Q{grave over ( )}s	4
J{grave over ( )}s	4	J{grave over ( )}s	4
10{grave over ( )}s	4	10{grave over ( )}s	2
9{grave over ( )}s	4	9{grave over ( )}s	4
8{grave over ( )}s	4	8{grave over ( )}s	4
7{grave over ( )}s	4	7{grave over ( )}s	4
6{grave over ( )}s	4	6{grave over ( )}s	4
5{grave over ( )}s	4	5{grave over ( )}s	4
4{grave over ( )}s	4	4{grave over ( )}s	3
3{grave over ( )}s	4	3{grave over ( )}s	3
2{grave over ( )}s	4	2{grave over ( )}s	4
	52		47

(Bold cards reflect deck constituency change)

Thus, in this non-limiting example, at44 the processor depletes the deck data of thefirst data structure30 and displays the remaining constituency of the card data so the player knows which cards remain available for selection and display.

With reference to the example ofFIG. 3, at46 the player selects with the input means14 which cards of the initial holding to hold. For example, with reference toFIG. 1 the player may decide to hold the 10's. Thus thedisplay12 would display thecards18 in the following manner:

TABLE-US-00002

10,	3,	A,	4,	10,

Hold		Hold

In this example, upon the player prompting play, at48 theprocessor15 selects from the data stored in the first data structure the next data, e.g. N.sub.6 N.sub.8 and displays the same as replacements for the discarded cards3A4. For example, the hand, after replacements may result in a final holding outcome of:

TABLE-US-00003

10,	10,	J,	J,	10

Hold		Hold

This holding is a Full House.

In this example, in connection with the retrieval of the replacement card data, the processor at44 depletes the deck data of the data representing the replacement cards (cards 10.diamond., JJ) and displays at thedisplay12 at table34 the new constituency of the deck depleted by the replacement card data. Thus the table34 would be:

	TABLE-US-00004

	Table After Initial Deal		Table After Replacements

A's	3	A's	3
K's	4	K's	4
Q's	4	Q's	4
J's	4	J's	2
10's	2	10's	1
9's	4	9's	4
8's	4	8's	4
7's	4	7's	4
6's	4	6's	4
5's	4	5's	4
4's	3	4's	3
3's	3	3's	3
2's	4	2's	4
	47		44

(Bold cards reflect deck constituency change)

Thus the player has updated information as to the constituency of the remaining deck data.

In this example, at50 theprocessor15 compares the outcome to data stored in asecond data structure52 representing winning outcomes and the award for each (referred to herein as pay table data) to determine if the player is entitled to an award. If the player has obtained a winning outcome, at54 theprocessor15 issues the appropriate award. Typical pay table data for a five unit wager is as shown at the pay table28 ofFIG. 1. The pays may be linear based upon the tokens wagered or may include one or more higher pays to encourage a maximum coin wager.

In some embodiments, after the award or if no award was won, theprocessor15 determines at56 if the player has prompted re-shuffling of the deck data of thefirst data structure30. In some embodiments, the player may prompt reconfiguration and reconstitution of the deck data of the first data structure into data representing a shuffled, random, serially ordered full deck by touching shuffle button58 (FIG. 1). In some embodiments, theprocessor15 reconfigures and reconstitutes the deck data of thefirst data structure30 into data representing cards N.sub.1 N.sub.52. In some embodiments, thedisplay12 would also be controlled to show the constitution of the deck data at table34. In some embodiments, the player may command re-shuffling where the deck constitution, for the next hand of play, is not what the player desires, e.g. is completely depleted of Aces thus making a Royal Flush impossible for the next hand. It should be noted that where deck depletion makes certain outcomes impossible for the next hand, theprocessor15 would re-configure the pay table28 and remove that outcome in some embodiments. For example, if all Kings are depleted from the deck making a Royal Flush impossible, the Royal Flush pay would be removed from the pay table28.

In some embodiments, if the player does not command re-shuffling, re-shuffling may be commanded based upon the count of the card data which has been displayed.

According to some embodiments, where penetration into the deck data reaches a predetermine number, theprocessor15 commands reconfiguration and reconstitution of the deck data. For example, if the count exceeds 30 cards, e.g. (N.sub.1 N.sub.31), at60 the deck data is reshuffled before the play of the next hand in some embodiments.

In some embodiments, one or more triggers at62 may trigger re-shuffling and reconstitution of the deck. For example, where the game is a Joker's Wild version of Video Poker, the display of the Joker in the hand may trigger re-shuffling before the play of the next hand. Other triggers may be depletion of one of A's 10's from the deck (making a Royal Flush impossible) or depletion of all the 2's in a Deuces Wild format game.

In some embodiments where re-shuffling takes place, the table34 may reflect the re-constitution of the deck.

Table34 may also display the cards remaining for each suit as shown in the example ofFIG. 1.

In some embodiments, whether re-shuffling takes place or not, the player at36 inputs another wager to play the next hand having the information imparted by the table34 of the constitution of the deck data.

The example ofFIG. 2 illustrates thedisplay12 after completion of a hand which has depleted the deck data to have a remaining set of 32 cards. Since the next hand could require the selection and display of ten cards (initial holding of five cards where all are discarded and replaced) thereby exceeding a forty card deck penetration, re-shuffling of the deck data would occur prior to the play of the next hand in some examples.

	TABLE-US-00005

	Royal Flush (without Joker)	5000
	5 of a Kind	1000
	Royal Flush with Joker	500
	Straight Flush	250
	4 of a Kind	100
	Full House	35
	Flush	25
	Straight	15
	3 of aKind	10
	Twopair	5
	Pair of Queens orBetter	5

In some embodiments, theprocessor15 is programmed to order re-shuffling (reconfiguration and reconstitution) of the deck data upon the first of: (1) where the count the hands played as tracked by thecounter42 is four hands (2) after a hand is played including the Joker, or (3) player commanded re-shuffling.

Blackjack/Baccarat

Turning to the example ofFIG. 4, there is shown a diagram for the play of Blackjack or Baccarat according to the present invention. Like elements bear like reference numbers.

In some embodiments, at36 the player inputs their desired wager to play a hand of Baccarat or Blackjack and at38 prompts theprocessor15 for play. In some embodiments, theprocessor15 accesses thefirst data structure30 to get the next cards at40 in order from the random, serially arranged, deck data. In some embodiments for Blackjack, the processor would select and display two cards for a player hand and two cards for a dealer hand; however for the dealer hand, only one card is exposed. Thus, at44, the deck data is depleted by four cards displayed for the initial holding and the constituency of the remaining deck is displayed at table34 in some embodiments.

With continuing reference toFIG. 4, theprocessor15 also counts at42 the number of cards (and/or hands of play, if desired) represented by the current hand as well as accounts for the value, and if desired suit, of the cards remaining in the deck data inventory of thefirst data structure30 in this example. For Baccarat or Blackjack, suit is not important and hence may not be accounted for in some implementations.

In some embodiments, at64 the hands are completed by the player standing, splitting, doubling down, taking a hit according to the rules of Blackjack. The player's action may require the selection and display of additional cards for the player hand. In some embodiments, for additional cards requested by the player, at44 and as described above, the deck data is selected in order from the serially arranged, randomized deck data, cards are counted at42, at44 the deck data is depleted and the new deck constituency is displayed. In some embodiments, the dealer's hand at64 is also completed which may require selecting and displaying additional cards according to the well-known rules of the game. In some embodiments, for any additional cards for the dealer's hand, cards are counted at42, at44 the deck data is depleted and the new deck constituency is displayed. It should be recognized that this example is non-limiting and that other elements and/or methods may be used in other embodiments.

In some embodiments, when the player and dealer hands have been completed, at66 the hands are compared, according to the well known rules of the game to determine if the player has won the hand. If the player has won at54 the award is issued to the player and if not, the player's wager is lost and is retained.

In some embodiments, after the award or if no award was won, theprocessor15 determines at56 if the player has prompted re-shuffling of the deck data of thefirst data structure30. In some embodiments, the player may prompt reconfiguration and reconstitution of the deck data of thefirst data structure30 into data representing a shuffled, random, serially ordered full deck by touching shuffle button58 (FIG. 1). In some embodiments, theprocessor15 reconfigures and reconstitutes the deck data of thefirst data structure30 into data representing cards N.sub.1 N.sub.52 for the fifty-two card deck. In some embodiments, thedisplay12 would also be controlled to show the constitution of the deck data at table34. In some embodiments, the player may command re-shuffling where the deck constitution, for the next hand of play, is not what the player desires, e.g. is completely depleted of Aces thus making a Blackjack impossible for the next hand. It should be recognized that his example is non-limiting and other embodiments may include other elements or methods.

In some embodiments, ff the player does not command re-shuffling, re-shuffling may be commanded based upon the count of the card data which has been displayed or additionally or alternatively, the number of hands which have been played since re-shuffling of the deck. According to some embodiments, where penetration into the deck data or the number of hands of play reaches a predetermine number, theprocessor15 commands reconfiguration and reconstitution of the deck data. For example, if the count exceeds 30 cards, e.g. (N.sub.1 N.sub.31), at60 the deck data is reshuffled before the play of the next hand in some embodiments. Or, in some embodiments, if four hands have been played, re-shuffling may be triggered.

In some embodiments, one or more triggers at62 may trigger re-shuffling and reconstitution of the deck. For example, where all the Aces have been depleted from the deck (making a Blackjack impossible), re-shuffling may be triggered before the play of the next hand in some embodiments.

In some embodiments, Baccarat is played in the same manner as illustrated inFIG. 4 and described above. The difference is the exposure of all cards and the known draw rules for Baccarat to complete the Player and Banker hands therefore.

The device and method may also be applied to other casino card games such as modified Blackjack, Baccarat or Poker games. Further the method can also be employed in a table game using one or more decks of cards and a card reader to read cards as they are distributed to players.

In some embodiments, a player may not have an option to restore/reshuffle a deck. In such embodiments, at least one additional sequential game hand may be conducted using a finite set/deck data/inventory cumulatively excluding dealt game indicia until an automatic restoration event. Such an event may include, for example, a number of cards being dealt, a number of hands played, a particular state of a shoe, when a cut card is reached, and so on. In some implementations, a virtual card may be placed in a deck at a desired location and when the cut card is reached the deck may be reshuffled/restored. In some implementations, the reshuffle/restore may occur before the start of a next hand. In other implementations, the reshuffle/restore may occur at a time when the automatic event is triggered (e.g., even if it is in the middle of a hand). In some implementations, a cut card may be placed in a deck between a desired range of cards (e.g., in the middle third of a deck), at a random location in a deck, and/or in any other desired location and/or fashion.

Some embodiments may include saving a state of a finite set/deck data/an inventory. Such a state may be saved, for example after a first gaming session. Saving a state may include, for example, storing information describing a current circumstance of a deck, such information may be stored, for example, in a database, and/or on any computer readable medium. A gaming session, for example, may include any number of games played. A gaming session ay end, for example, when a player turns a device used to play the game off, leaves a gaming machine, turns a computer program used to play a device off, switches applications on a computer, visits a different website than the one used to play a game, and/or takes any other action to stop the play of a game.

Some embodiments may include restoring a state of a game at a start of a second gaming session. The start of a gaming session may include any time before play of a game begins (e.g., before cards are dealt, before a player is given an option to make a move in a game, etc.). Restoring a state may include receiving/retrieving stored information. Such information may be retrieved from a database and/or any computer readable medium. Be restoring the state, the player may begin play using a deck that has been depleted to the extent it was depleted in the prior session. Accordingly, a player may be unable to perform a manual restoration by turning a game off and back on, in some such implementations.

In some implementations, information about a state may be stored in a location that may withstand a reset of a gaming device, for example, a permanent storage device such as a hard disk drive. In some implementations, such information may be updated each time a card is dealt so that the information is up to date at all instances.

In some implementations, a first gaming session may take place on a first device and a second gaming device. Each gaming device may have access to the state information (e.g., through a communication network). The state information may be stored for example, on a networked drive or other network accessible storage medium. The state information may be stored on a card or other id that a player carries with her and may be used by the player to start a game (e.g., similar to the well known TITO system storage of money information). In some implementations, a player may end a computer program to end a session and begin a computer program at a same or different device to begin a second session. A computer program may include, for example a java script program, an AJAX program, a web browser, a web based application, a stand alone program, and/or any other program.

While certain embodiments of the present invention have been described, it should be understood that these embodiments are subject to many modifications and changes without departing from the spirit and scope of the appended claims.