US20100048305A1

US20100048305A1 - System and method for storing and analyzing data relating to card games

Info

Publication number: US20100048305A1
Application number: US12/309,755
Authority: US
Inventors: Kevin S. Koplin
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-01-30
Filing date: 2008-01-16
Publication date: 2010-02-25
Also published as: WO2008094409A1

Abstract

The present invention generally relates to a system and method for tracking data relating to various types of card games, including, for example, poker, and more particularly, includes a hand-held device for the storage of card game results and a remote system for the storage and further analysis of card game results. Users can use the device to formulate better card game strategies for future play, and learn to recognize patterns of cards which are likely (or not likely) to result in winning hands.

Description

FIELD OF THE INVENTION

The present invention generally relates to a system and method for tracking data relating to various types of card games, including, for example, poker, and more particularly, includes a hand-held device for the storage of card game results and a remote system for the storage and analysis of card game results.

BACKGROUND OF THE INVENTION

There are known systems and methods which collect, store and analyze information pertaining to card games, including, for example, that described in U.S. Patent Publication No. 2006/0001211.
These systems and methods do not include a hand-held device which enables a user to enter, track and store information about each game played, retrieve that information and perform statistical analyses of the same. Likewise, none of these systems work in conjunction with a remote software platform which includes further analytical tools for formulating and implementing strategies for future card game play.
Thus, there has been a long felt need for a device for entering and storing data, and a remote software system to which data can be uploaded from the handheld device for further analysis.

SUMMARY OF THE INVENTION

While the prior art methods and software are of interest, they have several limitations which the device and software of the present invention seek to avoid.
Specifically, it is an object of the present invention to provide a portable device for entering and storing data relating to card game play.
It is another object of the present invention to provide a graphical user interface that dynamically adapts in real time to reflect real life card game situations.
It is another object of the present invention to provide software rules which govern the manner and type of card game data that may be entered into the hand held device.
It is another object of the present invention to provide a system to which data from the handheld device can be uploaded for further analysis.
It is another object to solve the shortcomings of the prior art.
Other objects will become apparent from the following description of the present invention.

DESCRIPTION

It has now been found that the above related objects are obtained in the form of a rule-based system for entering and storing data pertaining to card games comprising: a memory for storing card game data entered by a user of the device; a processor in communication with the memory; an adaptable graphical user interface for entering data relating to card game play; and rules executed by the processor for dynamically configuring and adapting the graphical user interface to include functional keys for entering data pertinent to at least one of a plurality of card games specified in the memory. Moreover, at least one of the functional keys is capable of a generating a summary of card game data stored in the memory. The functional keys are preferably touch sensitive soft keys.
Another embodiment of the present invention is directed to a computer readable medium having computer executable instructions for performing a method for entering and storing card game data in a memory, the method comprising the steps of: generating an adaptable graphical user interface for entering data relating to card game play; dynamically configuring and adapting the graphical user interface to include functional keys for entering data pertinent to at least one of a plurality of card games specified in the memory; receiving card game data entered via the graphical user interface; storing the card game data in the memory; and displaying a summary of card game data stored in the database.
The system and computer readable medium further comprise rules for governing and controlling the type of card game data that may be entered for at least one of the plurality of card games. The type of card game data governed by the rules comprises one or more of the following: type of game played by a user; betting stakes; cards seen by the user; the user's betting position; last card seen by the user; results of a card game hand; and how the hand was won. More particularly, the betting stakes comprise one or more of the following: a betting limit, pot limit and no limit. Likewise, the position comprises one or more of the following: small blind, big blind, under the gun, bring in, and button. The results comprise one or more of the following: winning a hand in showdown, losing a hand in a showdown, winning a hand with no show down, folding a hand, winning with the highest hand and winning with the lowest hand.
The system and computer readable medium further comprise rules for governing and controlling the manner in which card game data that may be entered for at least one of the plurality of card games. In one embodiment, these rules comprise instructions for making the functional keys available and/or unavailable based upon actual poker situations.
The processor used in the system and computer readable medium also calculates statistics based on the data entered by a user, including at least one or more of the following: number of hands played, number of hands won, cards seen for each position and cards seen as a percentage of a number of hands played.
In one embodiment, the plurality of games utilized in the method comprises two or more of the following: Texas Hold'em, Omaha High, Omaha High-Low, Seven Card Stud High, Seven Card Stud Low, and Seven Card Stud High-Low. Additionally, the graphical user interface is capable of displaying a graphical representation of cards entered by the user and the position at which each card entered by the user was dealt in a particular hand.
In yet another embodiment, a system for analyzing card game data is provided. This system comprises: a graphical user interface comprising buttons for entering search criteria relating to the card game (e.g., poker) data; wherein at least one of the buttons is capable of generating a customized report that comprises data meeting the search criteria; a memory for storing card game data and the customized report; and a processor in communication with the memory and the graphical user interface.
In another embodiment, a computer readable medium having computer executable instructions for searching for and analyzing card game data stored in a memory is provided, the method comprises the steps of: providing a graphical user interface comprising buttons for entering search criteria relating to the card game data, wherein at least one of the buttons is capable of generating a customized report that comprises data meeting the search criteria; receiving a search criteria for card game data; generating a customized report that meets the search criteria; and storing the customized report in a memory.
The system and computer readable medium comprise rules for governing and controlling the manner in which a search for the can be performed. These rules only permit searches for card game outcomes that are possible, and do not permit searches for card game outcomes that are not possible.
In one embodiment, the card games for which searches can be performed comprise one or more of the following: Texas Hold'em, Omaha High, Omaha High-Low, Seven Card Stud High, Seven Card Stud Low, and Seven Card Stud High-Low.
The search buttons comprise one or more of the following: type of card game data buttons for searching for a specific game type; betting stakes buttons for searching for betting stakes for a particular game type; betting position buttons for searching for a user's betting position for a particular game type; card position buttons for search for the position of cards from which stored card hands were won; results buttons for searching for the user's results for a particular game type; and hand results buttons for searching for a specific poker hand result. More particularly, the betting stakes comprise one or more of the following: a betting limit, pot limit and no limit. Likewise, the position comprises one or more of the following: small blind, big blind, under the gun, bring in, and button. The results comprise one or more of the following: winning a hand in showdown; losing a hand in a showdown; winning a hand with no show down; folding a hand; winning with the highest hand; and winning with the lowest hand. The hand results comprise one or more of the following: straight flush, four of a kind, full house, flush, straight, three of a kind, two pair, one pair, and no pair.
The graphical user interface also provides buttons for searching for potential flushes for poker hand data stored in memory. Rules are provided for governing and controlling search criteria that may be used to search for potential flushes. These rules automatically make at least one of the buttons for searching for potential flushes unavailable based upon potential flush search criteria entered by a user. Additionally, these rules automatically select at least one of the buttons for searching for potential flushes based upon potential flush search criteria entered by a user.
In one embodiment, the buttons for searching for potential flushes comprise one or more of the following: buttons for searching for cards having matching suits; buttons for searching for cards not having matching suits; buttons for searching for cards having suits that make is possible for there to be a flush; buttons for searching for cards having suits that make it unlikely for there to be a flush; buttons for searching for cards having suits that make it possible for a user's opponent to make a flush; and buttons for searching for cards that have no affect on an ability to obtain a flush. Furthermore, the buttons for searching for potential flushes are configured for Texas Hold'em, and the buttons for searching for matching suits and non-matching suits are used to search for cards dealt in a pre-flop position. Additionally, buttons are provided for specifying a search for a specific number of cards for which there is a potential for flush.
Where a search for a potential flush is received, the following steps are performed: receiving a search for cards having matching suits; receiving a search for cards not having matching suits; receiving a search for cards having suits that make is possible for the user to make a flush; receiving a search for cards having suits that make it unlikely for the user to make a flush; receiving a search for cards having suits that make it possible for a user's opponent to make a flush; and receiving a search for cards that have no affect on an ability to obtain a flush.
Another embodiment of the present invention is directed to a hand-held device entering and storing card game data comprising: keys for entering and storing card game data; memory for storing the data; and a processor for directing received card data to the memory. The keys provide for the entry of one or more of the following types of card game data regarding a user's card game play: type of game played by a user, betting stakes, the user's starting cards, suit of the starting cards, the user's position when cards were received, cards seen by the user, result of hand, and how the hand was won. Moreover, the processor executes instructions for calculating statistics relating to the card game data. These statistics comprise at least one or more of the following: number of hands played, number of hands won, cards seen for each position and cards seen as a percentage of a number of hands played.
In one embodiment, the card games for which data may be entered into the hand-held device comprise one or more of the following: Texas Hold'em, Omaha High, Omaha High-Low, Seven Card Stud High, Seven Card Stud Low, and Seven Card Stud High-Low. Additionally, the betting stakes comprise one or more of the following: a betting limit, pot limit and no limit. Likewise, the position comprises one or more of the following: small blind, big blind, under the gun, bring in, and button. The results comprise one or more of the following: winning a hand in showdown; losing a hand in a showdown; winning a hand with no show down; folding a hand; winning with the highest hand; and winning with the lowest hand.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and related objects, features and advantages of the present invention will be more fully understood with reference to the following detailed description of the preferred, albeit illustrative, embodiments of the present invention when considered in conjunction with the accompanying figures, wherein:

FIG. 1 is a screen shot of the graphical user interface for the Texas Hold'em form of poker implemented in the hand-held device of the present invention;

FIG. 2 is a screen shot of the graphical user interface for the Seven Card Stud High-Low form of poker implemented in the hand-held device;

FIG. 3 is a screen shot of the graphical user interface for the Seven Card Stud High form of poker implemented in the hand-held device;

FIG. 4 is a screen shot of the graphical user interface for the Seven Card Stud Low form of poker implemented in the hand-held device;

FIG. 5 is a screen shot of the graphical user interface for the Omaha High form of poker implemented in the hand-held device;

FIG. 6 is a screen shot of the graphical user interface for the Omaha High-Low form of poker implemented in the hand-held device;

FIG. 7 is a second screen shot of the graphical user interface for the Texas Hold'em form of poker implemented in the hand-held device, and includes examples of how software rules are enforced during data entry;

FIG. 8 is a screen shot that includes an example of the statistics calculated and displayed by the hand-held device;

FIG. 9 is a screen shot of the graphical user interface used in connection with the server side software of the present invention;

FIG. 10 is a screen shot of the graphical user interface of FIG. 9, and includes an example of a search that may be performed by a user;

FIG. 11 is a screen shot of the graphical user interface of FIG. 9, and includes another example of a search that may be performed by a user;

FIG. 12 is a screen shot of the graphical user interface of FIG. 9, and includes a first example of a search for poker hands where there was potential for a flush;

FIG. 13 is a screen shot of the graphical user interface of FIG. 9, and includes a second example of a search for poker hands where there was potential for a flush;

FIG. 14 is a screen shot of the graphical user interface of FIG. 9, and includes another example of a search that may be performed by the user;

FIG. 15 is a screen shot of a table containing all hand records transferred to the server side software from a user's hand-held device; and

FIG. 16 is a screen shot of the results of the search performed in FIG. 14.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to a system and method for enabling a player of a card game (e.g., poker) to enter and store various types of information relating to his card game play, analyze the stored information, calculate statistics based on that information and formulate strategies for future play. In one embodiment, a hand-held device is used to enter card game data and calculate related statistics. This information may be transferred to a remote computer server having software which enables future review and analysis. Each of these aspects of the present invention is described below.
Referring to the embodiment shown in FIG. 1, the hand-held device is configured to permit the entry and storage of data pertaining to various known poker games and to calculate various statistics relating to the user's poker play. As discussed below, the hand-held device includes a graphical user interface (“GUI”) 10 which permits a poker player to enter the betting stakes for each hand, the cards dealt in each hand, the order in which the cards were dealt, the position from which the cards were seen, the betting position of each hand and the results of each hand. Rule-based software governs the manner in which this information can be entered into the device, and the manner in which the graphical user interface is displayed to the user. Based on the information entered by the user about each card game played, the device in real time calculates, stores and displays various statistics about the user's poker play.
Turning first to the handheld device with reference to FIG. 1, a conventional touch sensitive screen is provided which allows a user to enter and store information about a card game he or she has played, which in this example, is the Texas Hold'em form of poker. Touch sensitive screens are well known in the art. More particularly, the GUI 10 includes a series of touch-sensitive soft keys (e.g., alphanumeric and/or graphical buttons) which are grouped according to their various functions. In the example shown in FIG. 1, the group of soft keys include a type of card game keys 9 (e.g., Texas Hold'em), card value keys 11 (e.g., ace of clubs), game result keys 13 (e.g., Win Show), betting position keys 15 (e.g., small blind), betting stakes keys 17 and cards seen keys 18. Additionally, the following functional soft keys may also be included in the GUI 10: a “clear” key for clearing erroneously entered data; an “enter” key for storing data in the device's memory; and a “stats” key for calculating and displaying statistics relating to the user's card game play. The operation and functionality of these various keys are controlled by software running on a microprocessor (not shown) in the hand-held device.
In the example shown in FIG. 1, the following game type keys 9 are provided for various well known poker games: an “H” key for Texas Hold'em; an “O↑” key for Omaha High; an “
” key for Omaha High-Low; a “7↑” key for Seven Card Stud High; a “7↓” for Seven Card Stud Low (Razz); an a “
” key for Seven Card Stud High-Low. To enter data relating to one of these types of games, the user selects the appropriate key.
Additionally, an “L” key is provided as part of game type keys 9 group which, when selected, locks in a particular game type selected by the user. As a result, the user is prevented from changing the selected game during use by accidentally touching one of the other game type keys 9. Additionally, by locking in a particular game, the user will not need to re-enter the game type for each new hand of that game. The device can also be set to a default position which automatically locks in a selected game type. To unlock a particular game type, the user simply deselects the “L” button.
The card value keys 11 are for entering the value (e.g., 2-10 keys, a “J” key for Jack, a “Q” key for Queen, a “K” key for King, and an “A” key for Ace) and suit (e.g., a “
” key for Club, a “
” key Spade, a “♦” key Diamond, a “♡|” key for Heart) of each card seen for a particular hand. As each card is entered with these keys, a graphical representation of that card is displayed in the position that it was dealt. The user may specify the position that each card was seen by simply touching one of the card position spaces 21, 23, 25, 27, 29, 31, 33 displayed on the GUI 10. Thus, in the example shown in FIG. 1, the user has entered: (1) Ace of Clubs as the first card by touching space 21 and selecting the “A” and “
” keys; (2) King of Diamonds as the second card by touching the space 23 and selecting the “K” and “♦” keys; and (3) Queen of Hearts as the first of three “Flop” cards by selecting the space 25 and selecting the “Q” and “♡|” keys. Likewise, graphical representations of these cards have been automatically generated and displayed in spaces 21, 23, 25. Here, the user has not entered any other cards for this hand. However, depending upon the cards seen, the user can enter cards for the second and third Flop positions, Turn Position and River position by touching spaces 27, 29, 31 and 33, respectively, and entering a card value for each of these positions.
Alternatively, rules can be configured to guide the user through the entry of cards seen in the order that they are dealt. In this way, the user would not need to touch spaces 21-33 to specify the position of each card. Rather, the rules would automatically require the user to enter cards in the order dealt. However, the rules do not necessarily require the user to enter every card dealt, and may optionally allow the user to skip over card positions when entering data.
If the user has not entered all of the cards seen in a particular hand, the user can enter the position of the last card seen by selecting the relevant card seen key 18 that represents the last card seen. In the Texas Hold'em example of FIG. 1, the last card seen keys 18 include a “1st Card” key, a “2nd Card” key, three “Flop” keys, a “Turn” key and a “River” key. In FIG. 1, the user has only entered the actual cards seen in the First and Second positions and the first Flop position, even though he was actually dealt all seven cards. The user has indicated that the last card seen was in the River position by touching the “River” key, even though he has not specified the value of this card. As a result, the “River” key and the corresponding “River” card space 33 are highlighted to indicate that this is the position of the last card seen. Optionally, the user can enter the value of the card seen in the River position.
The betting position keys 15 allow the user to enter a betting position for each hand, and in one embodiment, include the following keys: a “SB” key for the Small Blind position; a “BB” key for Big Blind position; a “Gun/Bring In” for the under the gun/bring in position; and a “BTTN” key for the Button Position. Additionally, an “OTH” key is provided for indicating that the user was in a position other than the Small Blind, Big Blind, Under the Gun/Bring In and Button Positions. Optionally, a separate pop-up screen (not shown) may be provided in which the user can enter other information about his or her betting position, including, for example the betting positions of competing card players.
The betting stakes keys 17 enable the user to enter information about the betting stakes for each hand, and in one embodiment, include the following keys: an “L” key for indicating when there is a maximum bet limit; a “PL” key for indicating where there is a pot limit; and an “NL” key for indicating where there is no pot limit. The betting stakes keys 17 also include a “Lock” key which, when selected, locks in a particular betting stake entered by the user. To unlock a particular betting stake, the user simply deselects the “Lock” key.
Finally, the results keys 13 are for indicating the results of each poker hand (e.g., whether and how the user has won or lost). In the example shown in FIG. 1, the following results keys are provided: a “Win Show” key for indicating where the user wins a hand in a showdown; a “Lose Show” key for indicating where the user loses the hand in a showdown; a “Win-No Show” key for indicating where the user wins the hand and there is no showdown; a “Fold” key for indicating where the user has folded his hand; a “Win Hi” key for indicating where the user has the highest cards (and therefore winning hand) for a “High-Low” split game; and a “Win Low” key for indicating where the user had the lowest cards (and therefore winning hand) for a “High-Low” split game.
Each poker hand input by the user is stored in a database in the device's memory in a hand record by selecting the “Enter” key. Optionally, the time and date that the hand was entered is automatically assigned to and associated with that hand in the hand record. Additionally, both erroneously entered data and data that the user does not wish to store is cleared from the device by selecting the “Clear” key.
Preferably, the hand-held device is powered by a conventional battery source (e.g., a rechargeable battery), but can also be plugged into an electrical wall socket using AC/DC power adapter. It should also be noted that the software can be loaded onto conventional computer readable mediums, including, for example, handheld devices such as personal digital assistants, laptop computers, global positioning systems, MP3 players, cell phones, pocket PCs and the like. Alternatively, a comparable hand-held device can be made to accommodate the software.
Turning now to the intelligent functionality of the hand-held device, rules and logic are embedded in software on the device which automatically update the GUI 10 for each game in a manner which graphically represents real life card game situations. In this regard, the rules and logic will graphically update the GUI 10 to indicate to the user the keys that have already been selected, the keys that are still available for selection and keys which are no longer available for selection for each of the key groups 9, 11, 13, 15, 17 and 18. Since the rules and logic allow for the entry of data in a manner that corresponds to real life card game situations, they are event driven. As such, the rules are enforced differently according to both the game type selected and the circumstances that arise in a particular hand. In this regard, based upon the selection of the game type, the GUI 10 and soft keys are automatically configured with text and graphics appropriate for the selected game, with the GUI 10 having a different appearance for each game type. Moreover, the available keys for selection and the data that may be entered will vary according to the hand dealt, betting stakes, the user's betting position and the results of a hand.
For example, if, as shown in FIG. 1, the user selects Texas Hold'Em (i.e., the “H” key) from the game type keys 9, a software rule is enforced which causes the GUI 10 to be configured such that the user can enter up to seven cards for a Texas Hold'em hand. The software rules also configure the GUI 10 such that the user can enter the last card seen for only the Flop, Turn and River positions.
If, on the other hand, Seven Card Stud High-Low (i.e., the 7
key), Seven Card Stud High (i.e., the ↑ key) or Seven Card Stud Low (i.e., the ↓ key) is selected from the game type keys 9, then, as shown in FIGS. 2-4, respectively, the software enforces rules which reconfigure the GUI such that the cards dealt in the following positions can be entered by the user: a “1st Card” key; a “2nd Card” key; a “3rd Card” key; a “4th Street”; “5th Street” key; “6th Street” key; and “7th Street” key. Additionally, rules are enforced which permit the user to enter the first three cards in a hand, and the last card seen by the user may be only one of the Fourth Street-Seventh Street positions, as is permitted in these particular games.
Referring to FIGS. 5 and 6, respectively, if the user selects Omaha High (i.e., the O↑ key) or Omaha High-Low (i.e., the O
key), then the software enforces rules which reconfigure the GUI 10 such that cards dealt in the following positions can be entered by the user: a “1st Card” key; a “2nd Card” key; a “3rd Card” key; a “4th Card” key; and “Flop”, “Turn” and “River” keys.
Thus, as can be seen from these examples, the GUI 10 is automatically configured to graphically represent real life situations for each selected card game. Additionally, the rules and logic in the software may be used to automatically conform the GUI to real life situations for other types of card games, including, for example, blackjack, war, rummy, gin-rummy and the like.
Additionally, since the software on the device is configured to intelligently and dynamically reconfigure the GUI to correspond to real life poker situations, rules and logic are used to make only certain keys available for selection, while others will be made unavailable. In this regard, the rules and logic are event driven and, depending upon the circumstances that arise during a hand for a selected card game, the user will only be permitted to enter those card values, betting stakes, betting positions, the last card seen and hand results that are possible for that particular hand. As such, the available keys are always representative of real life poker situations.
For example, when a user selects one of the results keys 13, the software typically prevents the user from selecting any other keys within this group of keys. Indeed, subject to several exceptions, in a real life poker situation, only one outcome is possible. Thus, if the user selects the “Win Show” key, then the software updates the GUI to preclude the user from selecting the Lose Show, Win-No Show, Fold, Win Hi and Win Low keys. Additionally, the software automatically causes the selection of “River” key to indicate that this was the last card, as would necessarily be the case in a showdown. Thus, as shown in FIG. 1, the River Card key and space 33 are highlighted to indicate that this was the position of the last card seen. It should be noted that unlike the example in FIG. 1, since it is possible to have both the winning high and low hands in a high-low poker game, if one of the Win Hi and Win Low keys is selected for such games, then the unselected one of these keys remains available for selection.
Similarly, the software automatically limits the number of cards which may be entered for a particular game type, and depending upon the game selected, makes available for selection only individual card value keys 11 which have not been previously entered in that hand. It should be noted however, that the entry of both the card value and suit may be made in any order.
Turning to another example of how the rules and logic may be enforced, after entering information about each card, including the last card seen, the user enters his betting position using position keys 15. In the example shown in FIG. 1, the user has selected the Small Blind position (i.e., the SB key). Since it is not possible under the rules of Texas Hold'em for the user to also be in the Big Blind, Button or Other positions, a rule is invoked which prevents the user from selecting the BB, SB and Oth keys. By contrast, since the user can be both under the Gun/Bring in position and in the Small Blind position at the same time, the “Gun/Bring In” key remains available for selection. Additionally, the “Win Hi” and “Win Low” keys are made unavailable since these are not possible outcomes in Texas Hold'em.
Referring to FIGS. 2-4, if the user changes the game type to Seven Card Stud High-Low, Seven Card Stud High or Seven Card Stud Low (i.e., by selecting the
, 7↑ or 7↓ keys, respectively), then a rule is enforced which automatically renders the SB key, BB key and Bttn Key unavailable for selection, as these are not possible betting positions in these games. Similarly, the Win Hi and Win Low keys are automatically made unavailable in Seven Card Stud High and Seven Card Stud Low, as these are not possible outcomes in these games. By contrast, when Seven Card Stud High-Low is selected, the Win Show key is made unavailable since this is not a possible outcome for this game, and the “Win Hi” and “Win Low” keys are made available.
Additionally, if the user selects, for example, the Win Low Key for Seven Card Stud High-Low, as shown in FIG. 7, then rules are enforced which automatically make the Win Show, Lose Show, Win-No Show and Fold keys unavailable, since these are no longer possible outcomes for this game. However, as discussed above, the Win Hi key remains available since winning with the highest cards remains a possible outcome. Moreover, in order to win the low hand, the pot is necessarily split with the winner of the high hand. Thus, a rule is enforced with automatically highlights the 7th Street key in group 18 and corresponding “7th Street” space 33 since the user must have seen all seven cards under this scenario.
Further, if, as shown in FIG. 5, the user selects Omaha High (i.e., the O↑ key), a rule is enforced which automatically renders the Win Hi and Win Low keys unavailable since these are not possible outcomes. If the user selects Omaha High-Low (i.e., the
key), then another rule automatically renders the Win Show key unavailable since this is not a possible event, and the Win Hi and Win Low are made available as both are possible outcomes in this game.
Additionally, graphical indicators can be used to indicate to the user those keys that have been selected, keys that are still available for selection and keys that are no longer available for selection. Here again, the rules and logic automatically update the keys with the graphical indicators based upon the events that occur during a card game. For example, the keys that have been selected are highlighted with a first color (e.g., yellow). Selected keys can also be recessed upon their selection. Additionally, keys that are still available for selection are highlighted in a second color (e.g., blue). Likewise, keys that are made unavailable for selection are highlighted in a third color (e.g., gray).
These are but a few and the many possible examples in which the rules and logic of the present invention provide for the entry of card game data in a manner that reflects real life game situations, and are not intended to be limiting.
In another embodiment, the hand-held device can include hard wired (e.g., QWERTY) keys, including those used in devices such as computers, personal digital assistants and the like. In such a case, each button will have an alphanumeric and/or graphical identifier printed thereon which corresponds to the soft keys described herein, and which may optionally be back lit by an LED to indicate keys that have been pressed. Optionally, the hand-held device can include a flip top that shields others (e.g., adjacent poker players) from seeing what keys have been pressed. The flip top may be made of any suitable material and is hingedly connected to the device.
Upon entering card game data into the device, the user can save and store this data in hand record in a database stored in memory of the device by selecting the “Enter” key.
At any time during use of the device, the user can press the “Stats” key to display, in real time, statistics relating to the user's card play in the manner shown in FIG. 8. These statistics are automatically updated after each hand is stored in memory. In a preferred embodiment, the following statistics are displayed: the number of hands played as a whole number; the number of hands won, both as a whole number and as a percentage of hands played; how the hands were won; the position and number of cards that were seen, as a whole number for each position and a percentage of hands played; and the user's betting position for each hand, as whole numbers.
After the user completes his or her poker session, the data stored in the memory on the hand-held device may be transferred to a remote computer for review of all hands, and for further processing and statistical analysis. This may be done via a USB transfer, wirelessly, through the use of a memory card or any other known transfer means.
During the transfer of data from the hand-held device to a computer, which in one embodiment is sent via the Internet to a web-server containing proprietary software, the on-line server may upload advertisements to the user's hand-held device. The advertisements are stored on the user's handheld device. Thus, advertisements may be displayed to the user during data transfer to the server, as well as at later times (e.g., during later use of the device). These advertisements can be tailored to the user's interests or geographic location, and can be used to generate revenue for the operator of the server side software (e.g., website). In this connection, users may be required to enter a profile to register on the website, and this information can be used to select appropriate advertisements to be loaded on the user's device.
After the server acquires data (e.g., hands records) from the hand-held device, the user may upload this data to a personal computer. Simple review and analysis of the hand records may be performed using proprietary software loaded on the computer from a CD-ROM or website operating on the server. For example, searches and selection of hands that meet many criteria, such as particular combinations of cards, outcomes, positions, and stakes may be performed, and results are then rapidly presented to the user.
Additionally, more complex analyses may be performed on the data using a software application residing on the server (e.g., a web application). In a preferred embodiment, this software operates through a website, and allows for adaptive selections and analyses of data across selected card positions. Just as in the graphical user interface in the handheld device, the server side software includes a GUI having buttons which are made available based upon “real-life” card game situations. In this regard, the system configures itself so as to minimize the entry of trivial or invalid criteria.
The server side software enables a user to search for and select hands that meet many criteria, such as particular combinations of cards, outcomes, positions, and stakes of hands of a card game. However, as discussed below, this software allows for more complex analyses of data transferred from the user's handheld device.
Referring to FIG. 9, the server side software includes a GUI 101 having various groups of buttons that generally correspond to the groups of keys on the hand-held device. These buttons may be actuated by touch (where a touch sensitive screen is used) or by clicking them with a mouse pointer. In one embodiment, the GUI 101 includes a group of game type buttons 103 (e.g., “H”, “O↑”, “O↓”, “7↑”, “7↓” and “
”), a group of results buttons 105 (e.g., “Win Show”, “Lose Show”, Win-No-Show”, “Fold”, “Blank”, “Win Hi”, “Win Hi/Lo” and “Win Low”), a group of card position buttons 107 (e.g., “SB”, “BB”, “Gun/Bring In”, “Bttn” and “Oth”), a group of card value buttons 109 (e.g., “A”, “K”, “Q”, “J” and 2-10), a group of cards seen buttons 106 (e.g., “Pre-Flop”, “Flop”, “Turn” and “River”), and a group of stakes buttons 111 (e.g., “L”, “PL” and “NL”). With the exception of the following buttons, the symbols on these buttons are the same as those included in key groups 9, 11, 13, 15, 17 and 19 of the handheld device, and represent the same types of information described above with respect to those keys.
Specifically, the results buttons 105 further include: a “Blank” button that allows the user to search for hands where no outcome was identified by the user; and a “Win Hi/Low” button which allows for searches where the user has won hands with both the highest cards and the lowest cards. Additionally, the betting position buttons 107 further include: an “All” button for searching for all available positions for a selected game; a “Blank” button for searching for hand records where the user did not enter any position; a “SB-Gun/Bring In” button for searching for hands where the user was in the Small Blind and under the Gun positions; a “BB-bttn” button for searching for hands where the user was in the Big Blind and Button positions; and a “Gun/Bring In Bttn” for searching for hands where the user was in the Under the Gun and the Button positions.
Optionally, an “Or” button can be provided with the various button groups to serve as a Boolean operator to allow for multiple search criteria.
The GUI 101 also includes Cards Seen buttons 106 which allow a user to search for hands stored in memory according to how many cards in a hand they saw. In the Texas Hold'em example of FIGS. 9-14, the Cards Seen buttons 106 include “Pre-Flop”, “Flop”, “Turn” and “River” buttons. However, rules are provided for automatically changing the indicia on these buttons when another game is selected to allow for relevant searches. For example, for games that involve seven cards seen by all players, the indicia on the cards seen buttons 106 will change (not shown) to “Starting Cards” (for the first three cards seen) and “4th Street, “5th Street,” “6th Street,” and “7th Street”, for the last four cards seen, just as is done in the hand-held device. Additionally, rules automatically render the cards seen buttons 106 that are located beyond the position of the selected card seen buttons 106 unavailable.
In the Texas Hold'em example of FIGS. 9-14, by selecting the Flop button, the software will only search for hands that went no further than the Flop position. Moreover, the rules will automatically render the Turn and River buttons unavailable. By contrast, the River (or 7th Street) button and all preceding positional buttons will be automatically selected if the User selects the Win Show, Lose Show, Win Hi, Win Low, or Win Hi/Low buttons, since these buttons mandate that the hand went to the seventh card (e.g., the River or 7th Street).
As shown in FIGS. 9-14, a “View DB” key is provided, which, upon selection, allows the user to view all hand records stored in memory.
Additionally, a “Best Starting Cards” button is provided for searching for how all possible starting cards for a game fared in relation to each other. For example, Texas Hold'em has 169 possible starting two card combinations with a universally recognized mathematically-based hierarchy. A pair of Aces (AA) is known to be the best starting two card combination, and a starting hand consisting of a 7 and a 2 of different suits (72o (offsuit)) is known to be the worst. Thus, if a user searches for his best starting cards in all Texas Hold'em hands with no other search criteria selected, the software would retrieve and display all 169 of the two card combinations in the hierarchy of best to worst starting card combinations, along with a percentage of hands won for each such combination. In one embodiment, for hands that were never dealt to the player, the software marks such combinations with a dash (e.g., a “-”). If desired, the user can sort this data from best to worst starting cards, or vice versa.
Software rules and logic automatically update the GUI 101 on the server-side software to include information pertinent to the selected game type and to reflect real life card game results. In this regard, as discussed below, depending upon the selected game and search criteria, certain search buttons are automatically made unavailable for events that are not possible, while others are automatically selected for events that necessarily occurred.
For example, as in FIG. 9, if the user selects the “Win Show” button (i.e., winning at the showdown), the “River” button is automatically highlighted since this is necessarily the position of the last card seen in a showdown. The automatic highlighting of the River button indicates to the user that he could further modify his search to include any number of events that would necessarily occur before receiving the River card. Upon selection of the Search button, the software searches the database on the server for all Texas Hold'em hands entered by the user that were won at the showdown. The user may further narrow searches by selecting other available buttons (e.g., the betting position buttons 107, stakes buttons 111, etc.). The more the search criteria are defined, the narrower the search results will be.
In the example in FIG. 10, the user has selected the SB button for Texas Hold'em. This will search for all hands where the user was only in the Small Blind position. However, it should be noted that the remaining Position buttons 107 remain available for selection since, in this embodiment, the software is configured to allow for Boolean searching among all of the Position buttons 107.
Referring to FIG. 11, the user has narrowed the search in FIG. 10 by selecting a specific stakes button; here, the PL (i.e., pot limit) button. This search will yield all Texas Hold'em hands where the user was in the Small Blind position and there was a pot limit. It should be noted that the user could have selected up to all three betting Stakes buttons 111 to yield broader search results. Indeed, in this example, the L and NL buttons remain available for selection.
Another feature provided on the server side software enables the user to perform searches that assist in identifying and evaluating poker hands where either the user or his opponent were dealt cards which had the potential to result in a flush (i.e., a hand with five cards having the same suit). In this regard, the user is able to search for and evaluate poker hands where (a) it appeared that there was a potential to get a flush, (b) the user's opponents had the potential to get a flush, (c) neither the user nor any of his opponents had the potential for a flush and/or (d) the user actually had a flush. By analyzing this data, the user will, in future poker play, be more prepared to recognize and understand those situations where there is a potential to be dealt a flush in a hand (for both the user and the opponent). As a result, the user will be a better position to intelligently implement an overall strategy when playing card games.
The method for searching for potential flushes is described with respect to the Texas Hold'em form of poker. However, this method could be modified to apply to other forms of poker, including, for example, Omaha High and Omaha High-Low. Referring to FIG. 9, to perform a search for hands having potential for a flush, the user first identifies starting cards of interest as follows: selecting the “Match” button in the Pre-Flop position when searching for starting cards having two cards of the same suit; or selecting the “No Match” button when searching for two starting cards having different suits. Because suits in poker do not have any hierarchy, the suits are fungible for purposes of searching for flush potential. Indeed, a spade flush is no better than a heart flush; the better hand turns on what the highest card in the flush if there is no straight flush. If both hands have the same high card, then the second-highest ranking card is compared, etc.
Upon selecting one of the Match or No Match buttons in the Pre-Flop position, the software enables the user to search for “Good” or “Bad” cards for obtaining a flush with respect to one of the three cards dealt in the Flop position for all stored hands. Without limitation, Good cards have a suit that matches the suit of at least one of the user's two starting cards in the Pre-Flop position, and thus, allow for the possibility of obtaining a flush. In this regard, the suit of at least one of the cards in the Flop position must match the suit of both of the user's starting cards if the suits of the user's starting cards match. Alternatively, at least two of the cards in the Flop position must match at least one of the user's starting cards if the suits of the user's starting cards do not match for a particular hand for there to even be the possibility of a Flush. However, in order for a flush to be even possible for the user, there must, in actuality, be at least three cards among the five cards that comprise the cards in the Pre-Flop and Flop positions that have matching suits.
Without limitation, Bad cards exist where the suits of at least 2 of the cards in the flop position match each other, but do not match any of the user's starting cards in the Pre-Flop position. Bad cards may also exist where the suit of at least one of the cards in the Flop position matches the suit of the card in the Turn position, and are not Good cards. Thus, if the user identifies two Bad cards among the five cards that comprise the Flop and Turn, then, with a Bad card in the River position, the user's opponent could, potentially, with two cards in their hand that matches the Bad cards identified in this search, have a flush.
Referring to FIG. 9-14, the user can search for Good and Bad cards in the Flop position. In this connection, “0”, “1”, “2” and “3” buttons are provided for searching for a specific number of Good cards in the Flop position. Each of these buttons corresponds to the actual number of Good cards being searched for in the Flop position. Thus, for example, if the user wishes to search for three Good cards in the Flop position, he would select the “3” button. Similarly, “0”, “1”, “2”, “3” and “2+1” buttons are provided for searching for a specific number of Bad cards in the Flop position. As above, each of the 0, 1, 2 and 3 buttons correspond to the actual number of Bad cards being searched for in the Flop position. The 2+1 button is used to search for Bad cards where the suit of two cards in the Flop position match each other and also match the suit of the card in the Turn position, but do not match the Good cards. Thus, a search with the 2+1 button will yield hand results where the user did not have a flush, but his opponent(s) had the potential to obtain a flush (depending upon whether the River card was beneficial to the opponent(s)). Moreover, it should be noted that the 2+1 button is only available for those hand records for which data was entered by the user beyond the Flop position.
It should also be noted that since three cards are dealt in the Flop position, the maximum sum of Good and Bad cards that can be searched for in the Flop position cannot exceed three. However, the user can certainly search for fewer than three Good and Bad cards in the Flop position (e.g., a search for 1 Good card and 1 Bad card), if desired.
Additionally, the user may search for Good cards, Bad cards and cards that have no affect on the user's or his opponent(s)'s ability to obtain a flush in the Turn and River positions. In one embodiment, a “Good” button is provided in the Turn and River positions, which are used to search for cards in those positions that have suits matching the suit of at least one card in the Pre-flop position, and therefore, provide potential for a flush. Similarly, a “Bad” button is provided in the Turn and River positions, which are used to search for cards in those positions that have suits matching the suit of at least one card in the Flop position, and are not Good cards. “Neutral” buttons are provided in the Turn and River positions to search for cards that do not help the user or his opponent obtain a flush. A “Good/Neutral” button is also provided for searching for cards that may be considered to be good or neutral, but in reality, do not have any impact on the user's potential to make a flush. For example, where the user selects the Match button and the “3” Good Cards button in the Flop position as shown in FIG. 12, the software would search for hands where the user actually had a Flush since the search criteria requires five cards of the same suit. Thus, the only available options for the Turn and River Positions are receiving Good or Neutral cards. If the user has no preference, then he can simply select the Good/Neutral buttons to search for both possibilities.
In one embodiment, to search for Good, Bad, Good/Neutral or Neutral cards in the Turn and River positions, the user would need to first select one of the “Good” card buttons (i.e., 0, 1, 2, or 3) and “Bad” card buttons (i.e., 0, 1, 2, 3 or 2+1) in the Flop Position.
Referring to FIG. 12, if the user selects the “Match” button in the Pre-Flop position and the “3” Good Cards button in the Flop position, a rule is enforced which automatically selects the “0” Bad Cards button so that no bad cards can be searched for in the Flop position. Under this search, because there can be no Bad cards (e.g., this search would yield only those hands that actually resulted in a flush), the “Bad” button in the Turn position is made unavailable as there can only be Good or Neutral cards in the Turn position. Optionally, the Good, Bad, Neutral and Good/Neutral buttons can be made unavailable (as is the case in FIG. 12) in the River position until such buttons are selected in the Turn position.
As shown in FIG. 13, the user has selected the “Match” button in the Pre-Flop position and “1” Bad Card button and the “1” Good Card button in the Flop position. Since there can only be a total of three good and bad cards in the Flop position, a rule is enforced which renders the “3” Good Cards, “3” Bad Cards and “2+1” buttons unavailable. Similarly, a rule is enforced which automatically selects the “Bad” button in the Turn Position. Indeed, according to this search, there can only be one bad card in the Flop position, and thus, the card in the Turn position is necessarily bad (i.e., its suit matches the suit of a bad card in the Flop position, but not any Good cards). Moreover, in this search, there would only be three good cards—that is, the matching cards in the Pre-Flop position and the one good card in the Flop position. Thus, even if the suit of the card in the River position matches the suit of these three good cards, it is mathematically impossible for a flush to have occurred according to this search. Accordingly, a rule is enforced which makes the “Good” and “Neutral” buttons in the River position unavailable, and only permits the user to select a “Good/Neutral” button” or “Bad” button in the River position.
By contrast, since there are two bad cards in the search of FIG. 13, depending on the suit of the card in the River position and the suit of the user's opponents' cards in the Pre-Flop position, the opponents could potentially have a flush. Thus, the opponents flush potential will ultimately be determined by the suit of the card in the River position.
Referring to FIG. 14, another analytical tool is provided which provides for the ability to search for specific types of poker hand results. In this regard, a “Hand Outcome” button is provided which, when selected, provides a pop-up window with the following button (not shown): “Straight Flush”, “Four of a Kind”, “Full House”, “Flush”, “Straight”, “Three of a Kind”, “Two Pair”, “One Pair” and “No Pair.” By selecting one or more of these buttons, the software will yield search results in which the selected hand outcomes actually occurred. Moreover, for games where the best lowest cards are needed to win (e.g., Seven Card Stud Low), the Hand Outcome buttons may include buttons geared toward identifying the cards that made up the best five low cards in a hand (from the combination of the seven cards that the user was dealt). Additionally, an “Or” button may be optionally provided as a Boolean operator to search for more than one Hand Outcome.
Referring again to FIG. 14, the user can also identify specific cards to search for in each position (e.g., the Pre-Flop, Flop, Turn and River positions). In this connection, 2-10 buttons and A, K, Q and J buttons are provided for each position. By selecting these buttons during a search for potential flushes, the user can further narrow his search. More than one card can be searched for in each position. Likewise, an “All” button is provided which allows a search for all cards received at the specified position. In one embodiment, the software is set to a default position whereby all cards are searched from when searching for potential flushes. The software is also configured such that the order in which the cards are dealt in the Pre-Flop and Flop positions, respectively, is immaterial to the search.
FIG. 15 is an example of a screen shot of a table containing all of the hands entered by the user into the handheld device and uploaded to the server. In this example, the user has entered ten hands of Texas Hold'em. Accordingly, upon performing the search entered in FIG. 14, the results shown in FIG. 16 would be provided to the user. Only the results meeting the user's search criteria are displayed.
In the example of FIG. 16, the search results include the following information: the “GameName” column specifies the “Game Type” (here, Texas Hold'em); the column headings “Card 1” and “Card 2” correspond to the cards dealt in the Pre-Flop positions; the column headings “Card 3,” “Card 4” and “Card 5” correspond to the cards dealt in the Flop Position; the column heading “Column 6” corresponds to the card dealt in the Turn Position; the column heading “Card 7” corresponds to the card dealt in the River Position; the “Stake” heading corresponds to the betting stake for each hand (here, “PL”); the “Pos 0” and “Pos 1” headings correspond to up to two betting positions for each hand; the “Seen” heading corresponds to the last card seen in each hand; the “Result” heading corresponds to the result of each hand; and the “Date” and “Time” headings correspond to the date and time that each hand was entered in the hand-held device.
From the search results, the user can ascertain how many times, according to the search criteria used, that he actually made a flush, that he had the potential to make a flush and identify situations where his opponent had the potential to make a flush, how well he plays from certain positions, in this case the Small Blind, etc. Based on this information, the user will be better prepared to recognize situations that arise in future poker play where there is potential for a flush, and devise a strategy which enables him to achieve improved results in future play. For example, this information would assist the user with betting strategies, including, knowing when to bluff, recognizing bluffs by opposing players, when to raise the ante, when to fold, etc.
It is to be understood that the presently claimed invention may be embodied in other specified forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, and all changes which come within the meaning and range or equivalency of the claims are therefore intended to be embraced therein.

Claims

1. A rule-based system for entering and storing data pertaining to card games comprising:

a memory for storing card game data entered by a user of said device;

a processor in communication with said memory;

an adaptable graphical user interface for entering data relating to card game play; and

rules executed by said processor for dynamically configuring and adapting the graphical user interface to include functional keys for entering data pertinent to at least one of a plurality of card games specified in said memory,

wherein at least one of said functional keys is capable of a generating a summary of card game data stored in said memory.

2-13. (canceled)

14. A computer readable medium having computer executable instructions for performing a method for entering and storing card game data in a memory, the method comprising the steps of:

generating an adaptable graphical user interface for entering data relating to card game play;

dynamically configuring and adapting the graphical user interface to include functional keys for entering data pertinent to at least one of a plurality of card games specified in said memory;

receiving card game data entered via said graphical user interface;

storing said card game data in said memory; and

displaying a summary of card game data stored in said database.

15. The computer readable medium of claim 14, wherein the method further comprises the step of controlling the manner in which the graphical user interface is configured and adapted.

16. The computer readable medium of claim 14, wherein the method further comprises the step of controlling the type of card game data that may be entered for at least one of said plurality of card games.

17. The computer readable medium of claim 14, wherein the method further comprises the step of controlling the manner in which card game data may be entered for at least one of said plurality of card games.

18. The computer readable medium of claim 14, wherein the method further comprises the step of calculating statistics based on said data.

19. The computer readable medium of claim 18, wherein said statistics comprise at least one or more of the following: number of hands played, number of hands won, cards seen for each position and cards seen as a percentage of a number of hands played.

20. The computer readable medium of claim 14, wherein said plurality of games comprises two or more of the following: Texas Hold'em, Omaha High, Omaha High-Low, Seven Card Stud High, Seven Card Stud Low, Seven Card Stud and High-Low.

21. The computer readable medium of claim 15, wherein said type of card game data comprises one or more of the following: type of game played by a user; betting stakes; cards seen by the user; the user's betting position; last card seen by the user; results of a card game hand; and how said hand was won.

22. The computer readable medium of claim 21, wherein

said betting stakes comprise one or more of the following: a betting limit key, pot limit and no limit;

said position comprises one or more of the following: small blind, big blind, under the gun, bring in, and button; and

said results comprise one or more of the following: winning a hand in showdown; a hand in a showdown; winning a hand with no show down; folding a hand; winning with the highest hand; and winning with the lowest hand.

23. The computer readable medium of claim 14, wherein the method further comprises the step of displaying a graphical representation of cards entered by the user on said graphical user interface.

24. The computer readable medium of claim 23, wherein said graphical representation indicates to the user the position at which each card entered by the user was dealt in a particular hand.

25. A system for analyzing card game data comprising:

a graphical user interface comprising buttons for entering search criteria relating to said card game data, wherein at least one of said buttons is capable of generating a customized report that comprises data meeting said search criteria;

a memory for storing card game data and said customized report; and

a processor in communication with said memory and said graphical user interface.

26. The system of claim 25, further comprising rules for governing the manner in which a search for said can be performed.

27. The system of claim 26, wherein said rules for governing do not permit searches for card game outcomes that are not possible.

28. The system of claim 26, wherein said rules for governing only permit searches for card game outcomes that are possible.

29. The system of claim 25, wherein said card game is poker.

30. The system of claim 29, wherein said poker game comprises one or more of the following: Texas Hold'em, Omaha High, Omaha High-Low, Seven Card Stud High, Seven Card Stud Low, and Seven Card Stud High-Low.

31-39. (canceled)

40. A computer readable medium having computer executable instructions for searching for analyzing card game data stored in a memory, the method comprising the steps of:

providing a graphical user interface comprising buttons for entering search criteria relating to said card game data, wherein at least one of said buttons is capable of generating a customized report that comprises data meeting said search criteria;

receiving a search criteria for card game data;

generating a customized report that meets said search criteria; and

storing said customized report in a memory.

41-52. (canceled)

53. A hand-held device entering and storing card game data comprising:

keys for entering and storing card game data;

memory for storing said data; and

a processor for directing received card data to said memory.

54-58. (canceled)