REFERENCES CITES, U.S. PATENT DOCUMENTS
6,869,358 March, 2005 Yacenda 463/17
6,736,324 May, 2004 Behm, et al. 235/487
6,607,439 August, 2003 Schneier, et al. 463/17
6,572,107 June, 2003 Walker, et al. 273/139
US 2003/0045340 A1 March, 2003 Roberts, et al. 463/17
REFERNCES CITED, OTHER PUBLICATIONS Generating two-dimensional barcodes, http://www.idautomation.com/java/dmservlet.html
UW grad eases Internet use on cellphones, Imprint newspaper, University of Waterloo, Jun. 1 8, 2004,
http://imprint.uwaterloo.ca/story.php?f=2&t=5236&i=&v=f&story=5236
Semacode Corporation, URL barcodes for ubiquitous computing, http://semacode.org
BACKGROUND OF THE INVENTION Instant lottery games are very popular games of chance. A wide variety of games are available to meet the demands and desires of users. The games balance the excitement of playing a scratch-off type of game with meeting the legal obligations of the controlling authority. It is not uncommon for a single lottery ticket to have mutiple games or for games to have dozens of scratch-off spots.
Although instant lottery tickets do not act like casino games, many lottery games attempt to simulate them. For example, poker hands might be uncovered when the user scratches off spots to reveal the cards. In the casino game of poker, the outcome of a poker hand depends upon choices the user makes, as well as luck and the response of other players. When an individual instant lottery ticket is produced, it has a fixed outcome. The user is free to scratch off spots in any order, but the outcome is always the same.
Instant lottery tickets offer the convienence of purchase, whereas the ability to play casino-style games requires the user to be present in a casino, or via some kind of electronic connection as permitted by law.
The success of instant lottery tickets depends in part to frequent changes in the gaming experience. In its simplest form, an instant lottery ticket can have a single box which is scratched off to reveal the value of the card. However, this type of game is usually reserved for store and product promotions. People are attracted to certain types of instant games, which explain one reason why there are so many forms of instant lottery tickets.
It is advantageous to separate the instant lottery ticket value and purchase from the game used to reveal the winning amount, if any. Once a person visits a lottery agent and purchases an instant ticket of some denomination, the outcome of the purchase is fixed. If you provide the purchaser with the ability to customize the gaming experience, the enjoyment of the game is increased, promoting the purchase of additional lottery tickets. Also, the need to stock dozens of different instant tickets of the same denomination is diminished.
Cellphones afford an excellent gaming platform because of their wide use throughout the world. Camera phones are also common and two-dimensional barcode software exists to read internet url's by taking a picture of the barcode. If this technology is extended to import instant lottery ticket information into a cell phone, the cell phone platform becomes a complete gaming solution.
BRIEF SUMMARY OF THE INVENTION The invention describes a method where an instant lottery ticket contains a hidden area containing the ticket outcome. This gaming payload contains enough information such that a hand-held, or other such electronic device can act as the user interface to enhance the gaming experience. Once the ticket payload is revealed, often by scratching the cover obscuring the information, it can be used to play a variety of games. The payload can be in human readable format, but does not necessarily allow the user to determine the outcome of the ticket.
To play the instant lottery game, the payload information is input into the electronic gaming device. The gaming device can be of many forms, including a personal computer, hand-held casino game device, or cellular phone. The input means to load the gaming device with the gaming payload depends upon the type of gaming device used. Methods include manual keyboard entry, entry via a one-dimensional or two-dimensional barcode scanner, magnetic strip, or via a camera to acquire an image of the payload information.
The gaming device is configured by the user with certain game parameters. For example, the user might configure their gaming device to play video poker with random play for 10 hands. Although the final outcome is fixed, the gaming device will deal poker hands so the final winnings will match the fixed outcome.
To play the game, the device's user interface is used to interact with the user. The limitation of a gaming device depends upon its input and display capabilities. Although no user input is required, the gaming device usually has at least one input, such as a button, and sufficient display for the gaming experience. In the preferred embodiment of the invention, the gaming device is a cellular phone with a graphical display. This allows many different games to be played, such as emulating a slot machine, or traditional casino games such as roulette and poker.
BRIEF DESCRIPTION OF THE DRAWINGS The objectives and features of the invention will become more readily apparent from the following detailed description taken in conjunction with the accompanying drawing in which:
FIG. 1 is a plain view of an instant lottery ticket according to one presently preferred embodiment of this invention;
FIG. 2 shows a block diagram depicting how the instant lottery ticket payload can be encrypted;
FIG. 3 shows a block diagram depicting how the instant lottery ticket payload is decrypted by the gaming device;
FIG. 4 shows a block diagram depicting the gaming device;
FIG. 5 shows a flow chart describing the behavior of the gaming device when it emulates a simple slot machine;
DETAILED DESCRIPTION OF THE INVENTION Those of ordinary skill in the art will realize that the following description of the present invention is illustrative only and not in any way limiting. Other embodiments of the invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. The various features of the invention will now be described with respect to the figures, in which like parts are identified with the same reference characters.
FIG. 1 is a view of an instant lottery ticket 105. In most respects the design of ticket 105 can be as varied as any instant ticket marketed by lotteries today. The ticket contains a payload portion 110 and a validation portion 115. In terms of todays instant tickets, payload 110 contains the actual scratch-off regions that comprise the game. In this invention, payload 110 contains sufficient information about the game in order for an electronic game to be played on an electronic gaming device. The outcome of the instant lottery ticket, i.e. the winning value of the ticket, if any, is encoded in the payload. The result of the electronic game will always match the value of ticket 105. Payload 110 is protected from being read, either visually or electronically. In the preferred embodiment of the invention, payload 110 is covered by an opaque, removable scratch-off layer as found on currently instant lottery tickets. To enable validation and redemption, a validation portion 115 contains information intended only for the lottery controlling authority. The use and encoding of the validation portion 115 is the same as used by current instant lottery tickets. Some lottery authorities can combine payload 110 and validation portion 115 into a single scratch-off area, similar to how they are often used today.
Payload 110 contains numerous fields to describe the particulars of the instant lottery ticket 105. Payload fields include information about the issuing authority, ticket denomination, type of instant game, expiration date, outcome of the ticket, winning increment, game restrictions, and checksum information. The issuing authority id allows the ticket to list who issued the ticket and can be used by the electronic gaming device to follow certain rules defined by the controlling authority. The payload can also include the ticket denomination which can prove useful when determining the outcome of bets as the game progresses. The payload can also include the expiration date to remind users when and if the instant lottery ticket will or has expired. The payload contains the outcome of the ticket and represents the value of the ticket, if any, when the ticket is redeemed. A winning increment can also be specified in the payload to specify the minimum amount which can be won at any step while the game progresses. The payload can also specify gaming restrictions which the electronic gaming device must adhere to. The gaming restrictions can include, but are not limited to, which games can be used to play the instant lottery game, or how many individual games or bets comprise the entire game.
In the preferred embodiment of the invention, payload 110 is encrypted on the instant lottery ticket so the winning amount cannot be determiend unless read by an approved gaming device. FIG. 2 shows a block diagram to describe how the payload information is encrypted. Procedure 205 shows how an unencrypted lottery payload is transformed into an encrypted lottery payload. Generator 225 is responsible for computing the payload information for an individual instant lottery ticket. Generator 225 is identical to the step performed by existing instant lottery ticket fabrication. The Lottery authority 210 generates a private key and a public key using public-key encryption technology. The private key is a secret key retained by the lottery authority and encypts the payload by encryptor 230. Encryptor 230 can perform any suitable encryption technology, but in the preferred invention the RSA algorithm is used for encryption and decryption. The encrypted payload is passed to lottery printer 235 to generate the actual instant lottery ticket. In the preferred embodiment of the invention, the lottery agency id and checksum information is stored in an unencrypted format. This allows the gaming device to determine what authority issued the instant lottery ticket, and to verify the payload information has not been corrupted. The lottery authority 210 makes their public key available to approved gaming device manufacturers 220. Device manufacturer 220 generates a private key and a public key using public-key encryption technology. Encryptor 240 is used to encrypt the lottery authority public key using the gaming device private key. This encrypted key is stored inside gaming device 245. Gaming device 245 can be any suitable hardware or software device, but in the preferred embodiment of the invention, gaming device 245 is a software application that runs on a cellular telephone. The encrypted lottery authority key is stored in the gaming device in encrypted format. It is only decrypted during the process of decrypting payload 110. The encrypted lottery authority key can be permanently stored on the gaming device, or loaded on demand when an unknown instant lottery ticket is used by the device.
FIG. 3 shows the decryption step of the invention to recover the unencrypted payload. Procedure 305 describes how the encrypted payload is converted into its unencrypted format. The gaming device public key is stored inside gaming device 245. The encrypted gaming device key is also stored inside gaming device 245. Decryptor 310 is used to recover the lottery authority public key from its encrypted version. In the preferred embodiment of the invention, the lottery authority public key is stored in temporary memory and is deleted as soon as possible. In the preferred embodiment of the invention, decryption uses the RSA algorithm. Lottery payload reader 315 is used to read the payload information from the lottery ticket. The reader can work in a variety of the ways, including, but not limited to, one and two dimensional barcode reading, and optical character recognition. Decryptor 320 will decrypt the payload extracted by reader 315 using the lottery authority public key produced by decryptor 310. The unencrypted payload produced by Decryptor 320 can be read to determine the winning value of the ticket as well as configuration and limitations for the gaming device. In the preferred embodiment of the invention, the payload is stored in temporary memory and is slightly encrypted to make it more difficult to be monitored by electronic and software debugging devices.
FIG. 4 shows a block diagram of the components that comprise the gaming device 405 (also referred to as gaming device 245 in earlier figures) according to the invention. The gaming device 405 has a reader 425 (also referred to as reader 315 in earlier figures) which causes the encrypted payload information to be input to gaming device 405. Possible devices for reader 425 include, but it not limited to, a keyboard or keypad, one and two dimensional barcode scanners, magnetic strip or an electronic camera. In the preferred embodiment of the invention, an electronic camera is used to input an image of the encrypted payload into gaming device 405. Existing barcode software will extract the encrypted payload from a picture of a two-dimensional barcode. Reader 425 includes the ability to convert the encrypted payload into an internal electronic representation as well as compute an unencrypted version of the payload. The unencrypted payload is made available to control 410. Control 410 coordinates the activities of gaming device 405 to play an electronic lottery game. Configuration 420 contains user-defined information about the desired game or games to be played, as well as options specific to a particular game. For example, if gaming device 405 is configured to play a simple slot machine, the probabaility of frequent payouts (also referred to as a loose machine) can be set, as well as the number of pulls allowed to play the entire game. The user interacts with the gaming device with input 430. Input 430 is not a mandatory element because the gaming device can be configured to automatically play a game when the payload is accepted by reader 425. In the preferred configuration, the input device is the keypad and associated buttons on a cellular phone. The status of the game is shown on display 435. Some kind of display is required and must at a minimum show the final results of the game (i.e. the fixed outcome of the ticket). In the preferred configuration, the display is the screen of a cell phone capable of displaying a graphical representation of the game. Gaming logic 415 is responsible for generating the outcome after each step of the game. Gaming logic 415 understands the rules for at least one game, but typically can play numerous games. The type of game played depends upon information found in payload 110 or stored in configuration 420.
FIG. 5 shows a flow chart illustrating a method 500 according to the invention of playing a simple game. This flow chart is illustrative and not in any way limiting. The process begins with step 501. In step 501, the gaming device initializes itself with the current game setup configuration and decodes the encrypted payload. In step 505, the gaming device waits for user input. In the case of a slot machine, and in the preferred embodiment of the invention, the software waits for the user to enter a key on the cell phone keypad. In step 510 a check is made to see if the user wants to continue playing, or to restart the game. If the user restarts the game, control continues with step 501 and the gaming device is reinitialized. When the user instructs the gaming device to continue, control continues with step 515. In step 515, a single iteration of the game is played. The outcome from the step is computed using the gaming configuration and limitations imposed by the payload. When all iterations of the game are run, the outcome of the game will match the winning value of the ticket. In step 520 information about the current iteration, as well as the totals for the game are displayed. In the preferred embodiment of the invention, step 520 also contains a graphical element to enhance the enjoyment of playing the game. In step 525, the gaming device checks to see if there are additional iterations of the game. If there are more iterations, control passes to step 505. If the game is finished, control is passed to step 530 and the final results are shown. In the preferred embodiment of the invention, graphics play a heavy role in step 530 to congratulate the user for winning the game, or encouraging the user to play a new game.
A further understanding of the invention may be attained by reference to the following C# program. The self-contained program demonstrates the process of running a game using information from a payload and user configuration. The program emulates a simple slot machine with random payout after each step. When the game is complete the payout equals the value encoded in the payload.
Using System;
namespace Sim
{
// ********* *
// * *
// * Enum *
// * *
// ********* *
// List is not limiting; it is illustrative of possible gaming types
public enum eGameType
{
eNone = 0, // No game. Return ticket outcome immediately
eSLineSlot = 1, // Simple, Single, pay-line slot machine
eMLineSlot = 2, // Multi pay-line slot machine
eVideoPoker = 3, // Classic video poker, including payouts
};
// ************ *
// * *
// * Payload *
// * *
// ************ *
// Sample payload represents a classical instant lottery game where
// money is won. Payload can be extended to cover non-monetary
// prizes as well.
public struct PayLoad
{
public uint authority; // Issuing authority id
public float denomination; // Ticket denomination
public uint gametype; // Type of game
public DateTime expires; // Expiration date of game
public float outcome; // Outcome of ticket
public float increment; // Winning increment.
public uint restrictions; // Gaming restrictions
public uint checksum; // Checksum
};
// ****************** *
// * *
// * Configuration *
// * *
// ****************** *
// User configuration parameters
public struct Configuration
{
public uint attempts; // Number of gaming attempts;
public eGameType gametype; // Type of game
public float gametightness; // Tightness of game, (0-1).
// Higher the number, lower
// the payout
};
// *********** *
// * *
// * Reader *
// * *
// *********** *
// Read the payload from the ticket by the input means available
// to the device. In this program, the Reader generates a fixed
// payload
public class Reader
{
public Reader ( )
{
payload_.authority = 0;
payload_.denomination = 5.0F;
payload_.gametype = (uint) eGameType.eSLineSlot;
payload_.expires = new DateTime (DateTime.Now.Year + 1,
DateTime.Now.Month,
DateTime.Now.Day) ;
payload_.outcome = 10.0F; // A winning ticket
payload_.increment = 0.50F;
payload_.restrictions = 0;
payload_.checksum = 0;
}
public PayLoad payload
{
get { return payload_; }
}
private PayLoad payload_;
};
// ***************** *
// * *
// * DeviceConfig *
// * *
// ***************** *
// Device has local configuration parameters which the user can
// alter. In this program the device configuration is fixed.
public class DeviceConfig
{
public DeviceConfig ( )
{
config_.attempts = 10;
config_.gametype = eGameType.eSLineSlot;
config_.gametightness = 0.50F;
}
public Configuration configuration
{
get { return config_; }
}
private Configuration config_;
};
// ************ *
// * *
// * Display *
// * *
// ************ *
// Display device. In this program, the console is used
public class Display
{
public void display (int iteration, uint total, float winning,
float balance)
{
Console.WriteLine
(“iteration {0} of {1}: Winning = {2} Total Won = {3}”,
iteration, total, winning, balance);
}
};
// ************* *
// * *
// * Controls *
// * *
// ************* *
// Controls device. In this program, no controls are used.
public class Controls
{
// Wait for a user control to be activated and return the status
public uint wait ( )
{
return 0;
}
};
// ********* *
// * *
// * Game *
// * *
// ********* *
class Game
{
public Game (PayLoad payload, Configuration configuration)
{
this.payload = payload;
this.configuration = configuration;
remaining = this.configuration.attempts;
balance = 0.0F;
}
// Perform a single gaming iteration. Returns the winning amount,
// if any, during the iteration
public float iteration ( )
{
float winning = 0.0F;
if (remaining == 0)
return winning;
// Remaining winnings to distribute
float todistribute = (payload.outcome − balance);
if (todistribute < 0.0F)
{
// This is possible if the game has a “cost” associated with
// each round. For this program, the cost is zero so a
// negative value represents a serious error
balance = payload.outcome;
todistribute = 0.0F;
}
// Number of “increments” that can be awarded to the user.
int inc = (int) Math.Floor (todistribute / payload.increment);
if (remaining > 1)
{
// Use a random number to determine the win for this round.
// The looseness is a (0-1) value to multiply the random
// number by.
Random random = new Random ( );
float r = random.Next (1, 1000) / 1000.0F;
// Compute the number of increments to payout. In this
// program, the payout is reduced by the number of iterations
// remaining. This could also use a lookup table to weight the
// probability of a payout as the game proceeeds. The
// probability function should also take into account the
// dynamics of the game you are emulating.
int npayout = (int) Math.Floor
(inc * configuration.gametightness * r / remaining);
winning = payload.increment * npayout;
}
else
{
// On the last iteration, return any remaining balance. This
// simplifies the math. An alternate way is to modify the
// random number to return a number that becomes 1.0 on the
// last iteration.
winning = todistribute;
}
remaining−−;
balance += winning;
return winning;
}
// Remaining iterations
public uint Remaining
{
get { return remaining; }
}
public float Balance
{
get { return balance; }
}
// Gaming constants and parameters
private PayLoad payload; // Ticket payload
private Configuration configuration; // Device configuration
// Gaming variables
private uint remaining; // Gaming attempts remaining
private float balance; // Balance
/// <summary>
/// Play a game
/// </summary>
[STAThread]
static void Main(string[] args)
{
Reader reader = new Reader ( );
Display display = new Display ( );
Controls controls = new Controls ( );
DeviceConfig config = new DeviceConfig ( );
Game game = new Game (reader.payload, config.configuration);
int iteration = 0;
while (game.Remaining > 0)
{
controls.wait ( );
float winning = game.iteration ( );
iteration++;
display.display (iteration, config.configuration.attempts,
winning, game.Balance);
}
}
}
}
