Patent Publication Number: US-2007105608-A1

Title: System and method for managing a game

Description:
FIELD  
      The present application relates to systems and methods for managing a game, and more particularly to systems and methods for managing a game associated with a competitive elimination tournament event.  
     BACKGROUND  
      Interest and participation in games such as card games have increased greatly in recent years. The increased interest has led in turn to greater development and frequency of game tournaments. A leading card game having experienced particularly enthusiastic development is the game of poker, and especially the popular “Texas Hold &#39;em” variant of poker. An increasing number of public tournaments are being conducted, with many tournaments allowing entrance to any willing player upon payment of a buy-in fee. Several of these tournaments have participants numbering in the thousands of players, and have received international television coverage.  
      In a typical card game tournament, such as a poker tournament, participants are assigned to seat numbers at one of a plurality of game tables, and each participant begins playing with an initial quantity of game currency. During the course of the tournament, each participant attempts to win the game currency of the other participants assigned to the same gaming table. Participants losing all of their game currency are permanently eliminated from the tournament event.  
      The tournament may extend over several days and may be divided into several rounds of play, with participants being reassigned to other seats and other game tables as the total number of participants decreases. The process of elimination continues until only a final group of participants remains to play in an ultimate or final round, often at a single game table. Each participant in the final round may be assigned a seat number at the final round game table. In a typical poker tournament, the final round game table may include between two and ten participants, although any number greater than one is possible.  
      The tournament may award prizes to the participants based upon their duration of play, and particularly based upon their entrance into the final round. For example, each participant playing in the final group may receive a percentage of a total prize pool. The total prize pool may be created, for example, using the buy-in quantities collected from the participants, additional sums contributed by tournament sponsors, or both. Additionally, the percentage received may depend upon the sequence of elimination of the participants within the final round. For example, the first final round participant to be eliminated may receive a first percentage of the total prize pool, the second participant eliminated may receive a second percentage of the total prize pool, and so on. Typically the percentages are determined such that participants remaining longer or being eliminated later in the final round receive larger portions of the prize pool.  
      This prize-awarding mechanism, however, results in the awarding of prizes to a very small portion of the total number of participants that enter the tournament, for example to only the small number of participants remaining until the final round, as described above. Consequently, participants that are eliminated relatively early in the tournament do not have a stake in the final outcome of the tournament, and accordingly may lose interest in the event after their own elimination. This loss in interest may represent a corresponding loss in interest in activities associated with the tournament, such as the other events being managed by the entity sponsoring or managing the tournament. Additionally, because prizes are awarded only to participants in the tournament, spectators attending the event are not able to participate in the outcome of the tournament and may therefore similarly lose interest.  
      Therefore, a need exists for systems and methods for increasing participant and spectator interest in the game tournament by managing a game providing prizes that are associated with an outcome of the game tournament. Additionally, a need exists for systems and methods for managing such a game by fairly and efficiently creating, distributing, and redeeming game tickets.  
     SUMMARY  
      An aspect of the present application provides for a method for managing a game, comprising receiving information associated with an event, receiving a request for a ticket, generating a unique ticket number, selecting a number associated with a position of at least one participant in a round of the event, generating a ticket, the ticket including at least a portion of the information associated with the event, the unique ticket number, and the number associated with the position of at least one participant, and storing the unique ticket number and the number associated with the position of at least one participant.  
      A further aspect of the present application provides for a method for managing a game, comprising determining a winning position number of an event, receiving a ticket including event identification information, a unique ticket number, and a ticket winning position number, validating the received ticket, comparing the winning position number of the event and the ticket winning position number, awarding a prize when the winning position number of the event matches the ticket winning position number. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
      The present application can be more fully understood by reading the following detailed description of the presently preferred embodiments together with the accompanying drawings, in which like reference indicators are used to designate like elements, and in which:  
       FIG. 1  shows an exemplary game management system according to the exemplary embodiments of the present application;  
       FIG. 2  is a flow diagram illustrating an exemplary method for providing a ticket according to the exemplary embodiments of the present application;  
       FIG. 3  is a diagram illustrating an exemplary round game table according to the exemplary embodiments of the present application;  
       FIG. 4  is a flow diagram illustrating an exemplary method for receiving a ticket according to the exemplary embodiments of the present application;  
       FIG. 5  shows a graphical interface of a software application according to the exemplary embodiments of the present application;  
       FIG. 6  shows a graphical interface of a software application according to the exemplary embodiments of the present application;  
       FIG. 7  shows a graphical interface of a software application according to the exemplary embodiments of the present application;  
       FIG. 8  shows a graphical interface of a software application according to the exemplary embodiments of the present application; and  
       FIG. 9  shows a graphical interface of a software application according to the exemplary embodiments of the present application. 
    
    
     DETAILED DESCRIPTION  
      The exemplary embodiments of the present application relate to systems and methods for managing a game having winners selected based upon the outcome of a competitive tournament.  
      The present application relates to the management of a game that is associated with a competitive tournament event. The tournament event may include any competitive tournament wherein a plurality of participants compete and are eliminated over the course of the tournament until a final round of participants remain. In an exemplary embodiment, for example, the tournament may include a card game tournament such as a poker tournament. The tournament may alternatively include other competitive activities, such as athletic sports, automobile, horse, human, or other racing, games of chance, and board games such as chess, checkers, backgammon, and the like. The tournament may include participants gathering in a common physical location such as a casino or sport center, or may be played in a virtual setting, for example, through utilization of a software application accessed by the participants via a communication network such as the Internet.  
      When the tournament is a poker card game tournament, for instance, participants in the tournament may be eliminated through successive elimination rounds, and the tournament may include at least one final round having two or more final round participants. The final round participants may be assigned to seat and/or position numbers within the final round, and the seat and/or position numbers may relate to positions occupied at a final round table. The final round seat and/or position numbers may be determined by random drawing after commencement of the tournament but prior to initiation of the final round. The game of the present application may include generation and distribution of a plurality of tickets each bearing at least one final round seat and/or position number, and the seat and/or position numbers included on the tickets may be randomly and equally distributed amongst the plurality of generated tickets. The tickets may be distributed to individuals, and the distribution may be associated with a purchase or may be performed without an associated purchase. The individuals receiving tickets may choose to receive more than one ticket, and may additionally choose to swap received tickets with other individuals. For example, an individual receiving two tickets each including the same final round position number may elect to swap one of the received tickets with another individual possessing a ticket having a different final round position number. The swapping of received tickets may be performed by physical transfer of a printed ticket, or may be performed via a communication network, for example, when the game is played in a virtual setting through utilization of a software application accessed by the participants via a communication network such as the Internet. During live progression of the final round, participants may be eliminated from the final round until a final winning position is determined.  
      An exemplary game management system  100  is shown in  FIG. 1 . The game management system  100  may include an entity  102 , and the entity  102  may include at least one computer system  112 . In one embodiment, the entity may include a gaming organization such as a casino, a betting parlor, or the like. Alternatively, the entity  102  may include a racing organization, an athletic sport organization, a game of chance organization, or any other entity that may organize, sponsor, and/or manage a competitive tournament.  
      An exemplary game management system  100  of the present application may include software programs and/or routines stored and executed, for example, by the computer system  112 , and the software programs and/or routines may include software programs and/or routines for performing communication with other computer systems in conjunction with computer communication hardware and software. Communication between computer systems may be performed via a public communication network, for example the Internet, or via a private communication network separate from and independent of a public communication network. The communication may be performed by utilizing communication methods and protocols including TCP/IP, FTP, SSH, WIFI, and the like.  
      The terms “computer system” and “network” as used herein may include a variety of combinations of fixed and/or portable computer hardware, software, peripherals, and storage devices. The computer system  112  may include a plurality of individual components that are networked or otherwise linked to perform collaboratively, or may include a stand-alone component.  
      The computer system  112  of the entity  102  of the present application may further include a processing system  114 , at least one internal storage device  116 , at least one external storage device  118 , at least one printing device  120 , a reading device  122 , and an input/output device  124 . The storage devices  112 ,  114  may include devices for storing data electronically, such as hard drive devices, storage servers, storage-area networks, RAID configurations, optical media drives, holographic media drives, tape media drives, flash memory devices, and the like. The computer system  112  may also include computer system components including one or more random-access memory modules. The input/output device  124  may additionally include one or more peripherals such as keyboards, mice, and monitors for enabling input and output of information to and from the computer system  112 .  
      The software routines and/or programs may be embedded and/or stored in the internal storage device  116  or external storage device  118  and may be run by the processing system  114 . Alternatively, the software routines and/or programs may be run by another computer system independent of entity  102 , with output of the software routines and/or programs being accessed by processing system  114 . The processing system  114  may run software applications including operating systems such as UNIX, Linux, OS/2, VMS, and Microsoft applications, as well as database applications, web server applications, file server applications, FTP server applications, mail server applications, and the like.  
      Additionally, the computer system  112  may be capable of network communication, and the network may include wired or wireless communication lines and associated hardware devices used in transmitting, receiving, and routing data, such as routers, switches, hubs, network interfaces, and the like. The hardware and software components of the computer system  112  of the present application may include and may be included within fixed and portable devices including desktop, laptop, server, personal digital assistant, tablet, smart phone, television, radio, and audio and video recording devices.  
      The computer system  112  of the entity  102  may be capable of communication via a communication network  180 . The communication network  180  may include a private communication network and/or a public communication network such as the Internet. Alternatively, the computer system  112  may be capable of communication via a private communication network  182 , and the private communication network  182  may include a dedicated data line that is independent of and separate from a public communication network such as the Internet. Each of the communication networks may additionally be partially integrated and/or interfaced, or may be entirely independent of one another.  
      The game management system  100  may include at least one additional entity  140 , and the additional entity  140  may be incorporated within entity  102  or may be completely independent of entity  102 . Entity  140  may be a subsidiary entity or an entity affiliated with entity  102 . The additional entity  140  may include a computer system  142  and associated elements substantially similar in function and performance to those included in entity  102 , such as a processing system  144 , at least one internal storage device  146 , at least one external storage device  148 , at least one printing device  150 , a reading device  152 , and an input/output device  154 . The computer system  142  of the additional entity  140  may communicate with at least the computer system  112  of the entity  102  via the communication network  180  and/or the communication network  182 . Any number of additional entities may be included in game management system  100 .  
      The game management system  100  may additionally include a remote interface device  160 . The remote interface device  190  may include, for example, a stand-alone kiosk or interactive terminal operable for providing an interface to the computer system  112  of the entity  102 . The remote interface device  160  may include components and peripheral devices similar to those associated with the computer system  112  and additional entity computer system  142 , for example, a processing system  162 , at least one storage device  164 , at least one input/output device  166 , a printing device  168 , and a reading device  170 .  
      The independent interface device  160  may be located remotely from the entity  102 , and may operable by tournament administrators, participants, spectators, and other individuals to obtain tournament information and to manage tournament status, ticket requests, ticket redemptions, and the like, as described below. Any number of additional independent interface devices may be included in the game management system  100 .  
      The entity computer system  112  may also be configured to function as a web server for delivering information via an Internet interface using sockets. The information transmitted by the web server may include web page information identified by universal resource locators (“URLs”), and formatted in Hyper Text Markup Language (“HTML”) or a similar formatting language in response to requests received via the Internet. The web page information may also include information formatted using Dynamic HTML (“DHTML”), Extensible Markup Language (“XML”), Java, JavaScript, and the like. Alternatively, the web server may be configured to provide information utilizing Wireless Access Protocol (“WAP”) to a WAP-enabled device such as a cellular telephone, personal digital assistant (“PDA”), and the like.  
      Web server functions may be performed through utilization of web server applications such as Apache, Netscape, and Microsoft web server applications in conjunction with Common Gateway Interface (“CGI”) applications. The CGI applications may perform tasks related to receiving and sending data packets to other computer systems via communication networks, and may additionally perform communication with the database applications in accordance with information received from the communication networks. The CGI applications may include programs written, for example, using programming languages such as C, C++, Java, Perl, Python, and shell scripts. Additionally, the web server applications may incorporate or may be associated with data encryption applications including Secure Socket Layer (“SSL”) and/or Transport Layer Security (“TLS”) applications for providing endpoint authentication and communications privacy using cryptography, and secure shell (“SSH”) applications for encrypted communications, tunneling, forwarding ports, and transferring data files. The web server applications may additionally provide web services, and the web services may be provided via private communication networks and/or public communication networks such as the Internet.  
      The database applications may be utilized to build and manage databases, and the databases may be stored in internal storage devices  116 ,  146  and/or external storage devices  118 ,  148 . The database applications may include relational database management systems, such as applications developed by Oracle, IBM, and the like.  
      Additionally, the computer systems  112 ,  142  may run information processing software modules, including modules for individual account establishment and management, confidential information collection, request reception and processing, information formatting and transmission, security monitoring, and report generation. As will be appreciated by those skilled in the art, the modules may be programmed using, for example, the programming languages identified above, and may be programmed to interact with and utilize the computer system communication and data processing hardware elements identified above.  
      Referring to  FIG. 2 , a method for managing a game may begin with the starting of a game management software application at step  202 . The game management software application may be started and run, for example, by the computer system  112  of the entity  102 . Alternatively, the game management software application and/or a module of the game management software application may be run by the processing system  142  of additional entity  140  which may communicate with the computer system  112  of the entity  102 . Commands may be entered to the game management application by an event administrator, and the event administrator may be authenticated by entry of, for example, a username and password into an authentication module of the game management software application. Alternatively, authentication of the game administrator may be performed by entry of other identification information, such as biometric information including fingerprint information, voice pattern information, iris scan information, and the like.  
      At step  204 , event identification information may be entered by the event administrator and/or by another individual authorized to modify information processed by the game management software application. The event identification information may be received through manual entry into the game management software application, and the entry may be performed through via any of the input devices described above, for example through the input/output devices  124 ,  154 . The event identification information may include, for example, an event name, an event code, an event date and/or range of dates, an event reference number, and a workstation identification number corresponding to a device used to enter the information. The event identification information may additionally include identification information associated with an administrator of the event, identification information associated with a sponsor or promoter of the event, a maximum number of participants in the event, a maximum number of tickets for the event, a cost associated with each ticket, a percentage of a total prize pool redeemable by a winning ticket, a currency associated with the event, a legal and/or political jurisdiction associated with the event, and starting and ending times and/or starting and ending dates associated with the event. The administrator of the event and the sponsor of the event may be identical, separate, or affiliated entities.  
      Event identification information associated with several separate, independent events may be entered and managed simultaneously by the game management software application. The event identification information may be modified at any time by, for example, the event administrator. As will be understood by one skilled in the art, although the present application describes management of a single event, identification and other information associated with a plurality of events may be stored and managed independently. In an exemplary embodiment, a plurality of events may be managed simultaneously. Information associated with each independent event may be transmitted to the computer system  112 , and stored and/or correlated with information associated with other simultaneously-managed events or previously held events.  
      Information associated with a number of participant positions of one or more rounds of the event, for example, of a final round of the event may also be entered into the game management software application, at step  206 . In an exemplary embodiment, for example, the number of positions in a final round of a card game tournament event may include a number of seats at a game table of the final round of the event.  
      An exemplary round table for a card game competitive tournament is shown in  FIG. 3 . The round table may include a game table  302  having a predetermined position for a dealer  304 . A plurality of predetermined positions for round participants  306   a - 306   n  may be provided. In an exemplary embodiment the number of round participant positions, for example in a final round of the event, may be nine, however as will be understood by one skilled in the art, the number of positions may be any number greater than one.  
      In alternative exemplary embodiments, the information associated with one or more rounds of the event may include a number of participants in any intermediate round of the event, or of a single round in an event that does not include a plurality of rounds. For example, an event may be divided into a plurality of rounds, based upon a number of participants remaining, predetermined time periods, or other suitable criteria. The information associated with the one or more rounds may include a number of participants in any one or more than one of the rounds. Alternatively, the information associated with the one or more rounds may include information associated with more than one round conducted simultaneously.  
      In an exemplary embodiment, for example, the event may include a round of a number of participants, grouped by tables, teams, quantity, and the like. The participants remaining after conclusion of the round may progress to participate in another round having a reduced number of participants, and so on until the conclusion of the event. The information associated with the participant positions entered in  206  may be associated with any one or more than one of these rounds of the event.  
      In alternative embodiments, the information associated with the number of participants may include a number of players and/or teams participating in one or more rounds of a competitive sporting tournament, a number of participants in one or more rounds of a racing tournament, a number of participants in one or more rounds of a board game tournament, and the like. The information associated with the number of positions of one or more rounds of the event may be received at substantially the same time as the receipt of the event identification information, or the information associated with the number of positions may be received at a different time. The number of positions of the one or more rounds may include any number greater than one.  
      Referring again to  FIG. 2 , a request for generation of a ticket may be received at step  208 . The request may be received through manual entry of a command and/or key sequence by the event administrator or by an operator utilizing the input/output devices  124 ,  154  associated with computer systems  112 ,  142 . In alternative exemplary embodiments, the request for generation of a ticket may be received via the input/output device  154  associated with independent entity  140 , and/or via the input/output device  166  associated with the independent interface device  160  by an individual. An identity of the requesting individual may be entered in association with the request, or the request may be submitted without being associated with an identity.  
      In an alternative exemplary embodiment, the ticket request may be received via the communication network  180 , for example via a web interface to the game management software application, or via manual entry of a request transmitted by telephone, email, facsimile, and the like.  
      The ticket request may include and/or reference any or all of the event identification information, and the event identification information associated with the request may be entered via the respective input/output devices  124 ,  154 ,  166 . In an exemplary embodiment, the game management software application may allow entry of some or all of the event identification information through entry in text entry fields or by selection of the event identification information from a range of choices presented in the form of menus, drop-down lists, graphical icons, and the like.  
      In an alternative exemplary embodiment, a plurality of tickets may be requested simultaneously using a batch mode request. The plurality of tickets may be requested in batch mode via commands entered into the game management application by the event administrator utilizing the input/output devices  124 ,  154 ,  166 . The batch mode request may be used to generate a plurality of tickets from a single batch mode request, and the batch mode tickets generated may be in an active state or in an inactive state, as described in greater detail below.  
      The ticket request may be made by any individual, and the individual may be a spectator of the event, a participant in the event, a manager of the event, and the like. The request may be received and processed at any time prior to the commencement of a round of the event associated with the ticket. In the various exemplary embodiments of the present application, reference may be made to an individual performing and/or initiating the ticket request as a “requester,” and to an individual having possession and/or custody of the ticket after generation as the “ticket holder”. The requester and the ticket holder may be separate individuals or the same individual, as discussed below.  
      In an alternative exemplary embodiment, the ticket request may be associated with a percentage designation. The percentage designation may be associated with a percentage of a prize associated with the ticket winning position number. For instance, the percentage designation may be determined to be 50%, which may indicate that the ticket may be redeemable for 50% of the prize attributable to and redeemable using a ticket having a percentage designation of 100%. That is, a ticket including a 50% designation may be redeemable for 50% of a total prize redeemable by a ticket that does not include a percentage designation. The percentage designation may, for example, modify a value of the ticket by reducing a purchase price of the ticket, reduce an exchange value of the ticket, and the like. The percentage designation may be any value. The percentage designation may have a default value of 100%, meaning that a ticket may be redeemable for an entire attributable prize absent any indication of a percentage designation associated with the ticket.  
      Additionally, the percentage designation may be adjustable at a time after request and/or generation of the ticket, for instance, upon occurrence of a predetermined event or performance of a predetermined action, such as entry into an event, purchase of a good, passage of a period of time, and the like. For example, a ticket may initially include an adjustable percentage designation, whereby the percentage designation may be increasable upon entry of the requester and/or holder of the ticket to the event associated with the ticket. Alternatively, the adjustable percentage designation may modifiable based upon the ticket holder&#39;s and/or requester&#39;s purchase of a particular good or service, thereby acting as an incentive to the holder and/or requester.  
      In an alternative exemplary embodiment, the percentage designation may be adjustable to a value greater than 100%, for example to provide a winning value greater than that of a ticket that does not include a percentage designation. A percentage designation greater than 100% may further incentivize a ticket requester and/or ticket holder.  
      The status of the game may be checked at step  210 . The status of the game may include at least a closed status and an open status. The closed status may indicate that no more tickets may be generated, and the open status may indicate that additional requested tickets may be generated. The game status may be determined by, for example, comparing a number of tickets generated with a maximum number of tickets allowable for the event, and setting the status to closed when the number of tickets generated is at least equal to the maximum number of allowable tickets. The maximum number of allowable tickets associated with the event may be determined by manual entry into the game management software application, or may be determined based upon the event identification information entered at step  204 . Additionally, the game status may be set to a closed status upon commencement of one or more rounds of the event, and/or upon instruction entered by the event administrator at any time.  
      When the game status is determined to be closed, a notice of unavailability of ticket generation may be provided to the requesting individual at step  228 , and the process may proceed to terminate at step  230 . The notice may be printed, displayed on an electronic display device, or communicated verbally.  
      When the game status is determined to be open, the process may proceed to generation of a unique ticket number at step  212 . A unique ticket number may be generated for each requested ticket, and the unique ticket number may be generated based upon a plurality of elements. In an exemplary embodiment, for example, a universal time code associated with the time of receipt of the ticket request and/or the time of generation of the ticket may be determined and used to generate the unique ticket number. The universal time code may be associated with an international standard coordinated universal time, and may be utilized to provide a hardware true randomized value for generation of the unique ticket number such that the unique ticket number may be coded in an unalterable state. The universal time code may be provided, for example, by a software application that dynamically maintains a universal time code time value and that is run by the computer system  112 ,  142 , or may be retrieved via the communication network by querying network time servers and the like.  
      A 32-bit cyclic redundancy check (“CRC32”) value may be embedded in the universal ticket number to allow for subsequent validation, and the CRC32 value may be represented in hexadecimal format. In an exemplary embodiment, the universal ticket number may include a value of the universal time code interleaved with a corresponding CRC32 value and a check sum character. A 15-digit number may therefore be printed as a 21-character unique ticket number, with the additional characters being embedded CRC32 characters represented in hexadecimal format. Accordingly, should any digit of the unique ticket number change, or a majority of multi-digit changes or digit transpositions occur, the changes may be apparent and may allow a subsequent declaration of invalidity of the universal ticket number. Alternatively, a true random portion may be included and interleaved with the initial universal time code value to allow generation of, for example, a 33-digit unique ticket number. For instance, a 21-digit unique ticket number may allow for up to 100 universal ticket numbers to be generated per second, whereas utilization of a 33-digit unique ticket number may allow for generation of 16.7 million unique ticket numbers per second.  
      In an exemplary embodiment, for instance, a position distribution table may be checked for a number of positions remaining in a current segment, with each segment being equal to the number of seats on the final table. A randomization of the number remaining in the segment may be performed to yield a selection value that may ensure that each segment is fully allocated, and the randomized number may thereafter be translated back into the relevant seat position and recorded both against the ticket and in the distribution table. The randomization may be performed using a standard pseudo-random algorithm. Alternatively, the randomization may be performed using a hardware random device to yield a truly random value.  
      In an exemplary embodiment, instead of appending an identification value to each ticket reference of abstract data, an embedded information may be utilized, and the error detection value, such as a cyclic redundancy check (“CRC”) value for the identification value and the abstract data, may be calculated. For instance, the CRC value and the abstract data value may be combined, and a CRC value may be calculated using the two values, thereby calculating a first error detection value, the first error detection value relating to both the identification value and the associated data in a first buffer. The CRC value may then be transferred with the abstract data, and a recalculation may be performed whereby the recalculation may relate to recalculating the error detection value using the received abstract data and the identification value to generate a second error detection value. Upon recalculating the second error detection value, the second error detection value may be compared to the first error detection value received with the data, to determine validity of the data. The recalculation algorithm may include the predetermined cyclic redundancy check algorithm used to generate the first error detection value.  
      In an exemplary embodiment, the process of calculating the CRC may include first converting the abstract data to a stream of bits, whereby the stream of bits relate to a polynomial. A calculate operation may then be performed to multiply a set of bits including at least one of the bits by a constant to produce a remainder. The remainder may then be multiplied by a next set of bits, and so on. Since only the remainder is used in the next operation, the size of the resulting number may be maintained. For instance, the process may multiply two 32-bit words to create a single 64-bit number, but the process may only keep the lower 32 bits and discard the upper 32 bits, with the remaining lower 32 bits being multiplied by a next set of bits, i.e., the next 32-bit word in the sector of abstract data. Since all of the carry information is lost, the final result is a 32-bit value. The 32-bit value may therefore be a unique value based on the original data such that when the process is repeated, the same 32-bit value may be created. One 32-bit CRC value may be calculated for each data value, with each data value including one string of abstract data and an associated incrementing ticket reference. Upon calculating the CRC value across the abstract data, the CRC value may be stored within the abstract data producing, for instance, a printable barcode value. That is, the 32-bit CRC value may be stored with the original abstract data as non-abstract data.  
      In an exemplary embodiment, for example, re-computation of a new CRC value based upon the extracted abstract data information and the embedded CRC tag value delivered within the barcode value, and comparison of the transferred CRC value with the newly computed CRC value, may be used to provide an indication that the abstract data are valid. As will be appreciated by one skilled in the art, CRC is capable of detecting within a linear stream of two 10-bit errors, such that when two 10 bit chunks of information that are lost or incorrect in the data path, an error may be identified, allowing validation to a relatively high degree of confidence. In an exemplary embodiment, the CRC calculation may be performed utilizing a software application. Alternatively, the CRC calculation may be performed in hardware.  
      A ticket winning position number may be selected at step  214 . The selection of the ticket winning position number may be associated with the requested ticket and may correspond to, for example, a position and/or placement of one or more participants in one or more rounds of the event. In an exemplary embodiment, for example, the ticket winning position number may be associated with a final round of the event. The final round ticket winning position number may be associated with a seat number of a last remaining participant of an elimination card game tournament such as a poker tournament.  
      The ticket winning position number may include any value within a range of values corresponding to the number of positions available for participants in the one or more rounds of the event, as established at step  206 . The selection of the ticket winning position number may be performed such that, for a plurality of tickets, the ticket winning position numbers are equally and randomly distributed.  
      Selection of the ticket winning position number may be performed in accordance with information associated with a total number of tickets previously requested and/or generated, and information associated with ticket position information numbers selected during processing of the previously-generated tickets. For instance, a total number of tickets requested and/or generated may be used in combination with quantities of position numbers already selected to insure a substantially-equal distribution of ticket winning position numbers for the entire event.  
      In an exemplary embodiment, the ticket winning position number may be randomly selected from the set of values corresponding to the number of participant positions in the one or more rounds of the event. Additionally, the values selected for ticket winning position numbers for each requested ticket may be stored, and the stored values referenced to ensure that the ticket winning position numbers selected are substantially evenly-distributed across an entire quantity of tickets requested.  
      In an alternative exemplary embodiment, the selected ticket winning position number may be incorporated into and/or interleaved with the unique ticket number.  
      The ticket may be generated at step  216 . The generation of the ticket may include printing of the unique ticket number and the selected ticket winning position number on a ticket, using, for example, the printing devices  120 ,  150 ,  168 . In an exemplary embodiment, the ticket may include a paper receipt having the unique ticket number and ticket winning position number printed thereon. The ticket may additionally include a rubber, plastic, metal, or other printable element. The generation of the ticket may include presentation of the physical printed ticket to the requester.  
      A plurality of tickets may be generated simultaneously and/or in blocks. In an exemplary embodiment, for example, 500 tickets may be generated, and each of the plurality may include a prefix such as “Participant 1,” “Participant 2,” and the like.  
      In an alternative embodiment, the ticket may include an electronically-stored and transmitted document, and the electronic ticket may be encrypted utilizing any of the encryption protocols described above. The electronic-format ticket may include any or all of the information printed upon a physically-printed ticket. The electronic ticket document may additionally be associated with a password, and transmitted to the requester without a required associated password. The password may be transmitted to the requester via a separate communication and/or a separate communication line, and transmission of the password may be made contingent upon performance by the requester of an action, such as delivery of a payment, subscription to a service, physical entrance to a facility, and the like.  
      In an alternative exemplary embodiment, the generated ticket may include an electronically-readable file, and the file may contain part or all of the information described above with regard to a paper document ticket. The information contained in the electronic file may be presented in any format, and may be humanly-readable, machine-readable, and/or encoded using an encryption algorithm.  
      For instance, the electronic ticket may be transmitted in an encrypted and/or password-protected state to a requester via an electronic mail communication, along with instructions to the requester regarding actions that must be performed to obtain the password necessary to decrypt the ticket.  
      The unique ticket number and any other information printed on the ticket may be printed on at least one surface of the ticket, and may be printed in human-readable numerals, in machine-readable symbols, and/or may be represented utilizing a two-dimensional barcode, a three-dimensional barcode, a matrix barcode, or a similar machine-readable graphical representation. Additionally, a digital watermark or other suitable security code may be printed on the ticket, in human-readable and/or machine-readable form. The ticket may include an adhesive backing applied on a side, a pin, or some any other suitable attachment mechanism.  
      The tickets may be generated in an inactive state, and may require additional action be taken by the ticket requester and/or ticket holder to modify the state to active. In an exemplary embodiment, for example, the ticket may be printed and be distributed to potential ticket holders via postal mail, as solicitations, and the like. The tickets may have instructions printed on at least one surface instructing the recipient to activate the ticket by performing a predetermined action. The action may include, for instance, accessing an activation page on an Internet web page, performing an electronic email, performing a telephonic or facsimile communication, delivering of a payment, physically appearing at a predetermined location, and the like.  
      Additionally, at least a portion of the event identification information may be printed on the ticket and/or included in the electronic ticket document. The ticket may also be imprinted with a variety of logos, advertisements, solicitations, maps, photographs, comments, instructions, web site addresses, coupons, event sponsor identification information, and the like, that may be associated with the event and/or a party affiliated with the event. A time and/or date of printing of the ticket may additionally be included on the ticket.  
      In an alternative exemplary embodiment, when the tickets have been requested in batch mode, as described above, the tickets generated corresponding to the batch-mode request may be set to an inactive state. For example, the batch-requested tickets may be generated in an inactive state, and may require an action to be performed by the ticket requester and/or holder to place the ticket in an active state. The activation mechanism of the batch mode generated tickets may allow, for example, a plurality of tickets to be requested, generated, and distributed to a plurality of prospective ticket holders in an inactive state. The distribution may be included in a mass-mailing solicitation, as an incentive to individuals purchasing particular goods and/or services, and the like. The tickets may thereafter be activated by willing individuals by performing the predetermined activity.  
      A stored value corresponding to a total number of tickets generated may be adjusted at step  218 . The adjustment may include updating of a running total of tickets requested and/or printed, for example, by incrementing a counter storing the number of tickets requested and/or printed.  
      Information associated with the ticket may be stored at step  220 . The information stored may include all information associated with the ticket, such as the event identification information, the event round participant position value, the time and date of receipt of the request, the time and date of generation of the ticket, the unique ticket number associated with the ticket, and the selected ticket winning position number associated with the ticket. The information storage of step  220  may include placing the information into a database and/or similar data management application and storage in one or more of the internal storage devices  116 ,  146  and/or external storage devices  118 ,  148 . As will be appreciated by one skilled in the art, the information may additionally be encrypted and/or compressed in association with the storage.  
      The process described above, including steps  202 - 220  may be repeated a plurality of times, until the maximum number of allowable event tickets generated has been reached and/or while the game status is open, as shown in  FIG. 2 . The process may be interrupted at any time via an instruction entered by the event administrator and/or a qualified agent of the event administrator.  
      Referring to  FIG. 4 , the event winning position number may be determined upon conclusion of the event at step  402 . The event winning position number may be based upon a position occupied by one or more individuals participating in the event. In an exemplary embodiment, the event winning number may be associated with a seat number of a single, final remaining participant of a card game tournament, such as a poker tournament. Alternatively, the event winning number may be associated with a position of a final remaining participant in one or more rounds of the event.  
      The event winning position number may also be based on information in addition to the position occupied by a last-remaining participant of the round of the event. In an alternative embodiment, the event winning position number may be determined based upon final positions of a plurality of individuals participating in the event. For example, the event winning position number may include a number of digits each corresponding to positions of the last three individuals in the event. Other alternative schemes are possible, for example, the event winning number may be determined by an arithmetic operation performed using positions associated with any number of remaining individuals in the event. For instance, in the case of a card tournament event, the seat numbers associated with the final three remaining participants in the event, and/or in one or more rounds of the event, may be added or multiplied to determine the event winning position number. Various other permutations are possible in keeping with the present application.  
      Upon conclusion of at least one round of the event and determination of the winning position number, a ticket may be received via presentation by a ticket holder, at step  404 . The presentation may be performed manually by the ticket holder, for example at a location of entity  102  and/or of the event. Alternatively, the presentation may be performed via postal mail, electronic mail, facsimile communication, or any other suitable mechanism.  
      The ticket may be verified for authenticity at step  406 , for example, by scanning the ticket to read the unique ticket number by utilizing a scanning device associated with computer system  112 ,  142 , or by manual entry of the unique ticket number by the event administrator or authorized agent. The read unique ticket number may be checked against the unique ticket numbers stored at step  220 . When the ticket is determined to be invalid, a notice is provided to the ticket holder at step  420 , and the process ends at step  422 . When the received ticket is determined to be valid, the ticket winning position number printed on the ticket may be read, and the read ticket winning number may be compared to the event winning position number at step  408 . When the read ticket winning position number matches the event winning position number, the ticket may be judged a winning ticket and redeemable for a predetermined prize, and the prize may be awarded to the ticket holder at step  410 . When the read ticket winning position number does not match the event winning position number, a notice may be presented to the ticket holder at step  420 , and the process may end at step  422 .  
      The prize awarded may be associated with a total prize pool including one or more of the buy-in amounts contributed by event participants, quantities paid in exchange for the requested tickets, amounts contributed by event sponsors and/or promoters, and the like. The prize attributable may additionally be adjusted in accordance with a total number of tickets requested and/or generated, and/or by any percentage designation associated with the ticket, as described above.  
      The unique ticket number of each read ticket may be stored at step  412 . The information stored may include all information associated with the ticket and the presentation of the ticket, such as the unique ticket number associated with the ticket, the selected ticket winning position number associated with the ticket, the event winning position number, the time and date of presentation of the ticket, and the amount of any prize associated with the event and/or ticket. The information storage may include placing the information into a database and/or similar data management application and storage in one or more of the internal storage devices  116 ,  146  and/or external storage devices  118 ,  148 . As will be appreciated by one skilled in the art, the information may additionally be encrypted and/or compressed in association with the storage.  
      The stored read ticket information may be utilized to provide statistical reports and distributions of winning tickets. Additionally, the stored matching ticket information may be compared with the number of tickets requested and/or printed to determine, for example, a quantity of outstanding matching tickets, a quantity of outstanding non-matching tickets, and the like.  
      As described above, in an exemplary embodiment, utilization and/or performance of the methods of the present application may include one or more software applications, and the one or more software applications may include graphical interfaces, as illustrated in  FIGS. 5-9 . The exemplary graphical interfaces shown in FIGS.  5 - 9  may, for instance, relate to windows displayed on a screen of a computer device. Any or all of the interfaces shown may be presented together on a single screen, or independently on one or more screens. As will be understood by one skilled in the art, the graphical interfaces shown may be generated by software applications written in any suitable programming language, and may be run independently or in conjunction with a variety of suitable operating systems and other software applications.  
      Various inputs and/or settings as described above may be entered, deleted, and/or modified by a user of the software application via manipulation of objects contained in the graphical interfaces. The objects of the interfaces may include, for example, text boxes, buttons, sliders, icons, and other graphical items allowing the user to interact with and/or instruct operation of the software application. The exemplary information displayed on  FIGS. 5-9  is solely illustrative, and any other information, values, labels, and/or text strings may be presented on one or more of the graphical interfaces.  
      As shown in  FIG. 5 , an exemplary window of the graphical interface may include, for example, an event name box  502 , an event reference code box  504 , an event start date  506 , an event end date/time  508 ,  510 , a seat range  512 , an event entry fee  514 , an event winning seat add-on percentage  516 , and a house take percentage  518 . Additionally, a message text box  520 , a currency selection  522 , and a promoted status checkbox  524  may be included.  
      As shown in  FIG. 6 , an exemplary window of the graphical interface may include information associated with generation and/or issuance of tickets, for example, an event name  602 , and event code  604 , an event status selector  606 , an event status display  608 , a date/time of automatic close of event  610 , a “new event” button  612 , a “delete event” button  614 , and an “event statistics” button  616 . Additionally, the exemplary window may include a button for modification of a company logo  618 , a button for modification of an administrator password  620 , a show ID/seat numbers checkbox  622 , a “print setup” button  624 , an “un-issue last ticket block” button  626 , and a “done” button  628 .  
      As shown in  FIG. 7 , an exemplary window of the graphical interface may include information associated with generation of a block of tickets, including a player name prefix text box  702 , a number of tickets textbox  704 , and a “start numbering from” textbox  706 . Additionally, the exemplary window may include a “create” button  708  and an “exit” button  710 .  
      As shown in  FIG. 8 , an exemplary window of the graphical interface may include information associated with generation of tickets. Event identification information  802  may be presented, including event title, start/end dates and times, total players, total fee, prize pool, seats at final table (“SAFT”), number of winning tickets, and win amount. Buttons associated with ticket administration actions  804  may be included, for example buttons associated with administration (“Admin”), print block, create block, report, about, validate, and exit functions. Participant and/or individual information may be presented in at least one table  810 , and may include an identification number (“ID”), seat number, player identification text string, issue date/time, and printed status information.  
      As shown in  FIG. 9 , an exemplary window of the graphical interface may include information associated with validation of a ticket number. A portion of the information presented may include information substantially similar to that in included in the exemplary window shown in  FIG. 8 . When, for example, a validate function is accessed via activation of the “validate” button, an additional graphical interface window  902  may be presented, and the additional graphical interface window  902  may include a ticket number text box  904 , an additional “validate” button  906 , and a cancel button  908 . Participant and/or individual information may additionally be presented in a table  910 , and the table  910  may include player identification numbers, ticket identification numbers, player identification text strings, and additional information.  
      As will be understood by one skilled in the art, each of the exemplary graphical interface windows as shown in  FIGS. 5-9  illustrate only one of a plurality of possible configurations, and any suitable placement and presentation of information may be utilized.  
      It should be understood that the present application is not limited to the precise exemplary embodiments described herein and that various changes and modifications may be effected by one skilled in the art without departing from the spirit or scope of the application. For example, elements and/or features of different illustrative embodiments may be combined with each other and/or substituted for each other within the scope of the present disclosure and the appended claims. In addition, improvements and modifications which become apparent to persons of ordinary skill in the art after reading the present disclosure, the drawings, and the appended claims are deemed within the spirit and scope of the present application.