20070218981 | Casino no-ticket in cashless methods allowing the redemption of large prizes | September, 2007 | Brunet De |
20100069132 | STORAGE MEDIUM STORING PUZZLE GAME PROGRAM, PUZZLE GAME APPARATUS, AND PUZZLE GAME CONTROL METHOD | March, 2010 | Fujita |
20080280662 | System for evaluating game play data generated by a digital games based learning game | November, 2008 | Matwin et al. |
20020028709 | Computer-aided board game system played by means of a wireless remote terminal | March, 2002 | Finer et al. |
20090209314 | METHODS AND SYSTEMS FOR LICENSE SHARING AMONG GAMING TERMINALS | August, 2009 | Rybak |
20070225055 | PLAYING CARD IDENTIFICATION SYSTEM & METHOD | September, 2007 | Weisman |
20060025223 | Gaming information center | February, 2006 | Lewis |
20080171584 | Cognitive Fitness | July, 2008 | Roberts et al. |
20060046825 | Lottery game based on letter puzzles | March, 2006 | Bozeman et al. |
20080020850 | Ultra-low mass composite personal defense baton | January, 2008 | Stethem |
20100093433 | GAMING SYSTEM AND GAMING SYSTEM PROCESSOR MODULE | April, 2010 | Tomicic et al. |
This application claims the benefit of the priority of U.S. application No. 60/824,768 which was filed on 6 Sep. 2006 and which is hereby incorporated herein by reference.
The present invention relates generally to methods and systems for playing and/or facilitating lottery games and playing and/or facilitating other suitable games of chance. Particular embodiments of the invention provide methods and systems for playing and/or facilitating lottery games over a cellular telephone network using a cellular telephone handset or similar wireless handheld device.
Many people enjoy playing games of chance, such as lotteries, keno and the like. In many jurisdictions, lotteries and other games of chance are heavily regulated. Such regulation can complicate the process of playing the game and decrease player enjoyment. For example, a player may be required to go to their lottery store each time that they want to purchase a lottery ticket and to show age verification information, identification or the like that demonstrates that the player is legally allowed to play the game under the application legislation.
There is a general desire to make it easier and/or more enjoyable for players to take part in lotteries and/or other games of chance.
In drawings which depict non-limiting embodiments of the invention:
FIG. 1 is a schematic flowchart of a method for registering to play a lottery and for purchasing lottery tickets according to a particular embodiment of the invention;
FIG. 2 is a schematic flowchart of a registration process according to a particular embodiment of the invention suitable for use with the method of FIG. 1;
FIG. 3 is a schematic flowchart of a mobile lottery ticket purchase process according to a particular embodiment of the invention suitable for use with the method of FIG. 1; and
FIG. 4 is a generalized block diagram for an example system capable of implementing the methods shown in FIGS. 1-3.
Throughout the following description, specific details are set forth in order to provide a more thorough understanding of the invention. However, the invention may be practiced without these particulars. In other instances, well known elements have not been shown or described in detail to avoid unnecessarily obscuring the invention. Accordingly, the specification and drawings are to be regarded in an illustrative, rather than a restrictive, sense.
Particular aspects of the invention provide methods for conducting and/or playing a lottery over a cellular telephone network. In one embodiment, a lottery conducting method comprises receiving a ticket purchase request from a lottery player at an application server via a cellular telephone network. The ticket purchase request may include identification of a lottery game and an indicator of one or more numbers to play in the lottery game. The method also comprises sending a confirmation message from the application server to a cellular handset of the lottery player via the cellular telephone network. The confirmation message may include information which identifies the lottery game and information which indicates the numbers played in the lottery game. Once the lottery draw is conducted, if the numbers played in the lottery game include winning numbers, the method comprises sending a winning message from the application server to the cellular handset of the lottery player via the cellular telephone network. The winning message may include an indication of an amount that the lottery player won and an indication of the winning numbers.
FIG. 1 is a generalized flowchart of an overall method 100 for playing a lottery game according to a particular embodiment of the invention. Method 100 includes a registration process 110 (a particular example of which is schematically depicted in FIG. 2), a mobile lottery ticket purchase process 115 (a particular example of which is schematically depicted in FIG. 3) and a mobile lottery feedback process 120 (a particular example of which is also schematically depicted in FIG. 3).
FIG. 2 is a schematic flowchart of a lottery game registration process 110 according to a particular embodiment of the invention. Registration process 110 includes a first registration path 200 for users of prepaid gaming accounts, which may be referred to herein as prepaid cards. Registration process 110 includes a second registration path 250 for internet users (including users who access the internet from cellular handsets). For prepaid gaming account registration (path 200), players purchase a prepaid gaming account (which may be in the form of a prepaid gaming card) at a lotto retail outlet (block 210) and register by sending a registration request SMS to an application server (block 220). The block 220 registration request SMS may be sent from the player's cellular handset to the application server. A SMS (Short Message Service) message is an example of a text-based protocol for sending text messages over cellular networks. Other text-based cellular protocols or more complex cellular protocols may be used to send the block 220 registration request message. In one particular embodiment, the block 220 registration request message comprises: a command code (e.g. a textual command code) indicating that the particular message is a registration request message; an account ID; and a PIN or other password. The account ID and the password may be particular to the prepaid card. In other embodiments, a command code is not required.
Once the application server receives the block 220 registration request message from a player, the application server parses the block 220 registration request message to discover that the message contains the registration command code. Assuming that the block 220 registration request message was constructed in the correct syntax, then the application server proceeds to parse the account ID and password from the registration request. Some cellular networks or cellular handset manufacturers place header text and/or footer text on outgoing SMS messages. These headers and/or footers are often delimited by special characters. For example, headers may be delimited by round brackets and footers may be delimited by angular brackets. Some cellular networks forward outgoing messages on behalf of a sender and when forwarding such messages include the sender's telephone number as a part of the message. Such telephone numbers may also be delimited by special characters. It may be desirable for the application server to look for special characters or perform some other technique to remove headers, footers and/or other superfluous message information (e.g. sender phone number) prior to parsing the remainder of the block 220 registration request message.
Once the account ID and password are parsed from the block 220 registration request message, the application server validates the player's account ID and password with a lottery server (block 230). Method 110 then reaches block 240 which involves an inquiry as to whether the account ID and password supplied in block 220 are valid. If the account ID and password are valid (block 245), the application server will activate the account and send the player a registration confirmation message (e.g. by return SMS or by return message according to the same protocol on which the block 220 registration request was sent). The block 245 registration confirmation message is sent from the application server to the player's cellular handset. On the other hand, if the account ID and/or password is invalid (block 247), the application server will send the player a registration rejection message (e.g. by return SMS or by return message according to the same protocol on which the block 220 registration request was sent) which outlines the error and possibly provides a customer service number to call.
For online registration (path 250), players access a lottery registration website (block 255), where they complete an online registration form (block 260) with information which may include age verification, geographic location verification, email address, cellular phone number, payment method or the like. Such age verification and the like is not explicitly shown in prepaid card registration path 200, as such verification preferably takes place at the point of purchase of the prepaid gaming account. As a part of block 260, the player submits the form and the corresponding verification information to the lottery server. Once the lottery server receives the registration form and verifies the information provided, the lottery server will send a registration confirmation request message to the player via the application server and/or the SMS gateway (block 265). Preferably, the player then replies to the registration confirmation request message via registration confirmation message (block 270) to complete the registration process. The block 270 registration confirmation message may include a command code indicating that the particular message is a registration confirmation message. The block 270 registration confirmation message may also include an account ID and a PIN or other password. The application server may parse the command code and any other information from the block 270 registration confirmation message in manner similar to that discussed above for the block 220 registration request. As discussed above, SMS represents one particular text-based cellular protocol. Other cellular protocols may be used in place of SMS messaging for blocks 265 and 270.
Once the block 270 registration confirmation message is appropriately parsed (if required), the application server may forward the player's block 270 confirmation message to the lottery server. Method 110 then proceeds to block 240. Assuming the registration is valid (block 245), the application server activates the account with the lottery server and sends a registration confirmation message (e.g. by SMS or email) to the player. If there is an error in the player's block 270 confirmation message (block 247), the lottery server may send a registration rejection message (e.g. by SMS or email) to the player with an identification of the error and possibly with a customer service number to call.
FIG. 3 is a schematic depiction of a method 300 for playing/conducting a lottery game. Method 300 includes a method 115 for purchasing lottery numbers and a method 120 for receiving lottery feedback. Purchasing method 115 process includes a first mobile lottery ticket purchase path 310 for basic phone users and a second mobile lottery ticket purchase path 350 for the users of so called “smart phones”.
In block 320, a player with a basic text phone may send a ticket purchase request message (e.g. via SMS) to the lottery server via the SMS gateway and the application server with text commands indicating the particulars of their purchase (e.g. a “Game Type” code, a quantity of tickets and selected lottery numbers). The application server parses the block 320 ticket purchase request in a manner similar to that discussed above for the block 220 registration request. As discussed above, SMS represents one particular text-based cellular protocol. Other text-based cellular protocols may be used in place of SMS messaging to implement the block 320 ticket purchase. For a player with a smart phone, the player may launch a gaming application and submit their game and number selection (ticket purchase request) to the application server via the gaming application (block 360).
Once the player selects their numbers (makes a ticket purchase request), method 300 proceeds to block 370 which involves an inquiry into whether the player's purchase selection is valid. The block 370 inquiry may involve the application server validating the player's purchase selection with the lottery server. If the player's purchase selection is valid (block 375), a ticket ID and a transaction ID will be issued by the lottery server and the application server will send the player a confirmation message with the particulars of their purchase (e.g. game type, picked numbers, cost, ticket ID and transaction ID, purchase date and draw date). This block 375 confirmation message may be sent via return SMS or other cellular messaging protocol (i.e. from the application server to the player's cellular handset) or by other form of return message (e.g. if the user has a smart phone running a gaming application). If the ticket purchase request sent by player was invalid (block 380), the application server will then send the player a message (e.g. by SMS, other text-based cellular protocol or other form of cellular phone message) outlining the applicable error and possibly providing a customer service number to call.
The lottery draw occurs in block 385. After the block 385 lottery draw, method 300 proceeds to lottery feedback method 120. Lottery feedback method 120 determines whether particular players are winners in block 387. Players with winning tickets receive a winning message (e.g. by SMS, other text-based cellular protocol or other form of cellular phone message) with an amount and numbers won from the lottery server via the application server and the SMS gateway (block 390). Players without a winning ticket but subscribed to an optional auto-notification service may receive a message (block 395) with how many of their numbers were matching (e.g. by SMS, other text-based cellular protocol or other form of cellular phone message) and an invitation to play again prior to the next draw date. Although not explicitly shown in FIG. 3, winners may also receive an invitation to play again prior to the next draw date.
FIG. 4 is a generalized block diagram which schematically depicts an example implementation of a system 400 suitable for carrying out the methods of FIGS. 1-3. As shown in FIGS. 2-4, players with basic text message phones 410A, 410B, 410C may send SMS message(s) to, and receive SMS message(s) from, a lottery operator's system 420 (and more particularly, lottery server 425) via cellular telephone network 430, SMS gateway 435 and application server 440. A player with smart a phone 412 may launch a gaming application and may send communication(s) to, and receive communication(s) from, lottery operator's system 420 via cellular telephone network 430, secure TCP network 445 and application server 440. In some embodiments, players with smart phones 412 may also send SMS messages to and/or receive SMS messages from lottery operator's system 420 via cellular telephone network 430, SMS gateway 435 and application server 440. As discussed above, SMS messaging represents only one possible text-based cellular messaging protocol and other text-based cellular protocols may be used in the place of SMS messaging.
Certain implementations of the invention comprise computer processors which execute software instructions which cause the processors to perform various method of the invention. For example, one or more processors in a secure mobile lottery system may implement data processing steps in the methods described herein by executing software instructions retrieved from a program memory accessible to the processors. The invention may also be provided in the form of a program product. The program product may comprise any medium which carries a set of computer-readable instructions which, when executed by a data processor, cause the data processor to execute a method of the invention. Program products according to the invention may be in any of a wide variety of forms. The program product may comprise, for example, physical media such as magnetic data storage media including floppy diskettes, hard disk drives, optical data storage media including CD ROMs, DVDs, electronic data storage media including ROMs, flash RAM, or the like. The instructions may be present on the program product in encrypted and/or compressed formats.
Where a component (e.g. a software module, processor, assembly, device, circuit, etc.) is referred to above, unless otherwise indicated, reference to that component (including a reference to a “means”) should be interpreted as including as equivalents of that component any component which performs the function of the described component (i.e. that is functionally equivalent), including components which are not structurally equivalent to the disclosed structure which performs the function in the illustrated exemplary embodiments of the invention.
As will be apparent to those skilled in the art in the light of the foregoing disclosure, many alterations, additions and/or modifications are possible in the practice of this invention without departing from the spirit or scope thereof. For example: