U.S. patent application number 12/309755 was filed with the patent office on 2010-02-25 for system and method for storing and analyzing data relating to card games.
Invention is credited to Kevin S. Koplin.
Application Number | 20100048305 12/309755 |
Document ID | / |
Family ID | 39674376 |
Filed Date | 2010-02-25 |
United States Patent
Application |
20100048305 |
Kind Code |
A1 |
Koplin; Kevin S. |
February 25, 2010 |
SYSTEM AND METHOD FOR STORING AND ANALYZING DATA RELATING TO CARD
GAMES
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.
Inventors: |
Koplin; Kevin S.; (New York,
NY) |
Correspondence
Address: |
AMSTER, ROTHSTEIN & EBENSTEIN LLP
90 PARK AVENUE
NEW YORK
NY
10016
US
|
Family ID: |
39674376 |
Appl. No.: |
12/309755 |
Filed: |
January 16, 2008 |
PCT Filed: |
January 16, 2008 |
PCT NO: |
PCT/US08/00593 |
371 Date: |
October 15, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60898182 |
Jan 30, 2007 |
|
|
|
Current U.S.
Class: |
463/43 ;
463/37 |
Current CPC
Class: |
G07F 17/3288 20130101;
A63F 1/18 20130101; A63F 9/24 20130101; G07F 17/3218 20130101; G07F
17/3293 20130101; G07F 17/32 20130101 |
Class at
Publication: |
463/43 ;
463/37 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
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)
Description
FIELD OF THE INVENTION
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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
[0005] 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.
[0006] Specifically, it is an object of the present invention to
provide a portable device for entering and storing data relating to
card game play.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] It is another object to solve the shortcomings of the prior
art.
[0011] Other objects will become apparent from the following
description of the present invention.
DESCRIPTION
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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
[0028] 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:
[0029] 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;
[0030] 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;
[0031] 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;
[0032] 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;
[0033] FIG. 5 is a screen shot of the graphical user interface for
the Omaha High form of poker implemented in the hand-held
device;
[0034] 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;
[0035] 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;
[0036] FIG. 8 is a screen shot that includes an example of the
statistics calculated and displayed by the hand-held device;
[0037] FIG. 9 is a screen shot of the graphical user interface used
in connection with the server side software of the present
invention;
[0038] 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;
[0039] 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;
[0040] 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;
[0041] 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;
[0042] 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;
[0043] 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
[0044] FIG. 16 is a screen shot of the results of the search
performed in FIG. 14.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.uparw." key for Omaha High; an "" key for
Omaha High-Low; a "7.uparw." key for Seven Card Stud High; a
"7.dwnarw." 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.
[0049] 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.
[0050] 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 ".diamond-solid." 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
".diamond-solid." 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] If, on the other hand, Seven Card Stud High-Low (i.e., the 7
key), Seven Card Stud High (i.e., the .uparw. key) or Seven Card
Stud Low (i.e., the .dwnarw. 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.
[0061] Referring to FIGS. 5 and 6, respectively, if the user
selects Omaha High (i.e., the O.uparw. 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.uparw. or 7.dwnarw. 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.
[0068] 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.
[0069] Further, if, as shown in FIG. 5, the user selects Omaha High
(i.e., the O.uparw. 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.
[0070] 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).
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.uparw.",
"O.dwnarw.", "7.uparw.", "7.dwnarw." 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.
[0081] 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.
[0082] Optionally, an "Or" button can be provided with the various
button groups to serve as a Boolean operator to allow for multiple
search criteria.
[0083] 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.
[0084] 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).
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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.
* * * * *