SYSTEM AND METHOD FOR STORING AND ANALYZING DATA RELATING TO CARD GAMES
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.
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 INVENTIONThere 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 INVENTIONWhile 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.
DESCRIPTIONIt 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.
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:
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
Turning first to the handheld device with reference to
In the example shown in
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
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
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
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
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
Referring to
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
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
Referring to
Additionally, if the user selects, for example, the Win Low Key for Seven Card Stud High-Low, as shown in
Further, if, as shown in
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
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
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
In the Texas Hold'em example of
As shown in
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
In the example in
Referring to
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
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
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
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
As shown in
By contrast, since there are two bad cards in the search of
Referring to
Referring again to
In the example of
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)
Type: Application
Filed: Jan 16, 2008
Publication Date: Feb 25, 2010
Inventor: Kevin S. Koplin (New York, NY)
Application Number: 12/309,755
International Classification: A63F 9/24 (20060101);