US20090258691A1

US20090258691A1 - Mobile gaming system

Info

Publication number: US20090258691A1
Application number: US12/099,901
Authority: US
Inventors: Deepa Jagannatha; Deepak Gonsalves; Dinesh Doshi
Original assignee: w2bi Inc
Current assignee: w2bi Inc
Priority date: 2008-04-09
Filing date: 2008-04-09
Publication date: 2009-10-15

Abstract

A system and method for providing lottery like games over a wireless network. The system and method permit a user of a mobile wireless device to play a lottery game electronically with the feel of a real game. Once a user is registered onto the system they can utilize an identification code to authorize the downloading of lottery games from a server to their mobile device. A financial account enables the user to electronically pay for the lottery games. Notification of the results of the lottery games can be made by e-mail, SMS or an IVR call.

Description

FIELD OF THE INVENTION

The current invention relates to a mobile gaming system on wireless networks and a method associated therewith. More particularly the present invention relates to lottery gaming on wireless communication devices and methods of implementing these games.

BACKGROUND OF THE INVENTION

There are many ways of playing lottery games. The most popular is purchasing a lottery ticket from a vendor at a local store or other establishment. The results of the lottery can be tracked by the purchaser, after the actual lottery, by watch in TV, listing to the radio or seeing the results posted at the establishments which sell the lottery tickets.
This conventional method of playing lottery games is burdensome to today's highly mobile individual. This method requires the individual to go out of their way to find a vendor or establishment that sells lottery tickets. The purchaser must normally wait in line to make his or her purchase of one or more tickets. In addition, if an individual is resting at home or is at work and decides to play the lottery he or she must complete the task at hand and travel to a location which sells lottery tickets, stand in line and purchase the lottery tickets.
The reduction in size of the personal computer has resulted in handheld Personal Digital Assistants (PDA) and cellular telephone with the capability to download games and other types of software. These devices have enabled a user to download many popular games such as solitaire, poker, video slots and other lottery games. At first these games were embedded in the devices by the Original Equipment Manufacturer (OEM). Later the games could be purchased as software and loaded into personal computers. From these PCs they could be downloaded through a cable connection to the PDAs. Eventually wireless communications replaced hard wire connections and the games could be wirelessly downloaded into the handheld devices and cell phones.
There are currently many different handheld devices and cellular phones which employ many different platforms on which these devices operate. At this time there are no standards between the platforms and therefore the games must be specifically designed for the individual platforms. This is very costly. The different platforms may not allow a game designed for a certain platform to operate correctly on another platform. In addition, if an individual decides to utilize a different PDA or cellular phone then they must repurchase all the games they had is their previous PDA or cell phone. This becomes prohibitively expensive and may sway the individual's decision to purchase the game in the first place.
There are also differences between some devices and the resources available for the devices such as Windows® for PCs and OSX® for Apple computers. The games must include software which is compatible with these different operating systems. These differences further add to the incompatibility between different handheld devices and games which can be downloaded onto these devices.
When cellular phones are employed as a platform there are a further set of game distribution challenges. The cellular phone companies normally employ different transmission standards for their wireless networks which are only compatible with phones specifically designed to operate with these standards. Therefore, to be compatible with the different cell phones the games must be designed to operate with each of these different standards.

SUMMARY OF THE INVENTION

The disclosed embodiments provide a system and method for providing lottery like games over a wireless network. The system and method permit a user of a mobile wireless device to play a lottery game electronically with the feel of a real game. Once a user is registered onto the system they can utilize an identification code to authorize the downloading of lottery games from a server to their mobile device. A financial account enables the user to electronically pay for the lottery games. Notification of the results of the lottery games can be made by e-mail, SMS or an IVR call.
Accordingly, it is an objective of the instant invention to provide a system for playing lottery like games over a wireless network utilizing a mobile wireless device which the user currently owns.
It is a further objective of the instant invention to provide a system for playing lottery like games over a wireless network wherein a proprietary mobile device is not required for playing mobile lottery games or different games that are available over the wireless network.
It is another objective of the instant invention to allow the user the easiest mode of playing the lottery game that the user is familiar with.
It is yet another objective of the instant invention to provide a system for playing lottery like games over a wireless network utilizing an application based system.
It is a still further objective of the invention to provide a system for playing lottery games over a wireless network utilizing an interactive voice response system.
It is still yet another objective of the instant invention to provide a system for playing lottery like games over a wireless network utilizing a WAP (Wireless Application Protocols) browser to allow a mobile phone to access the Internet.
Other objects and advantages of this invention will become apparent from the following description taken in conjunction with any accompanying drawings wherein are set forth, by way of illustration and example, certain embodiments of this invention. Any drawings contained herein constitute a part of this specification and include exemplary embodiments of the present invention and illustrate various objects and features thereof.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an overall view of the architecture for a mobile gaming system;

FIG. 2 is a diagram of a the architecture for a client application gaming system;

FIG. 3 is a diagram of the architecture for a gaming server application gaming system;

FIG. 4 is a diagram of a model view controller;

FIG. 5 is a registration form on a website;

FIG. 6 is a flowchart for a application based gaming system;

FIG. 7 is a flowchart for an IVR based gaming system;

FIG. 8 is a flowchart for a WAP based gaming system; and

FIG. 9 is a flowchart for a SMS based gaming system.

DETAILED DESCRIPTION OF THE INVENTION

A presently preferred embodiment of the instant invention is an application based mobile lottery gaming system. This system permits the player or user to have a GUI (graphic user interface) based interface with a mobile device to play games and contact a server. The mobile device can be, but are not limited to, a PDA (personal digital assistant) with a wireless connection, a laptop computer with a wireless connection or a cell (mobile) phone. The GUI interface permits the user/player to establish a more secured, easy to learn and interruptible connection with a server. An example of a mobile lottery gaming system is illustrated in FIG. 1. A mobile device 11 communicates with an access network 13. The access network communicates over the Internet 15 to an application server 17. A middle tier 19 communicates with the Internet 15 and a gaming server 21. The gaming server communicates with a database 23.
The following process is a detailed description of how Application based mobile gaming operates, note FIG. 6. The gaming application is launched 10 on a mobile device which allows the user to register. The registration process 12 allows the user establish an account with a server. The user can them login using their passcode and/or selected image 14. If the incorrect passcode and/or image is entered 16 the user is instructed to enter this information again. After a number of unsuccessful login attempts, for example 5, the user is sent to the end of the program and not permitted to play the game 18. If the user wants to continue they must repeat the registration process 12 again. Once the user has logged in they can choose the game they wish to play for the gaming application menu 20. For example the user may wish to play a PICK 3 Lottery game. Next at 22 the user will provide the arguments or select the number they wish to play on the keypad of the mobile device or other data entering device. For example the user may enter “02”, “34” and “45” on the keypad. The transaction is confirmed at step 24. Depending on the game which is selected there will either be an immediate draw of the winning numbers 26 or a date will be given on which the winning numbers are to be drawn 28. If the drawing is at a later date the user can check back on their mobile device for the winning number or can check other sources such as the television, a lottery terminal, the newspaper, etc. The gaming application is then ended at 30.
The architecture for application based lottery gaming is designed to accommodate various application modules. The preferred embodiment is divided into two models. A Client Application model and a Gaming Server model.
The Application model architecture is designed as a stack of protocols. FIG. 2 is an example of the Client Application model architecture. There are four layers in this model. Each layer has a set of functions to perform.
The application layer 32 consists of multiple game applications 34, 36, 38, etc. The applications are connected to the lower layers via two way communication for their function. Each of these game applications will be implemented based on a Model-View-Controller (MVC) paradigm. The MVC diagram is illustrated in FIG. 4.
The MVC performs the following tasks. The model 40 holds the data for the application. The view 42 is responsible to display the data to the user. The controller 44 registers and receives events 48 from the application router. The events are the information which is displayed on the user's mobile device. The view updates its display of data to the user. As indicated by the solid or broken arrows, there is either a direct or indirect association between the elements of the MVC. The applications in the application layer define the type of lower layer services that the application wishes to employ, such as security services (NULL encryption or Default Encryption), Message Encoding (ComML or comma delimited) and transport mechanism (TCP/IP or SMS). An instance of each of these services will be created upon request.
The security layer 50 consists of essentially 3 components; Cryptographic Services 52, an Application Router 54 and Message Encoding Services 56.
Cryptographic services 52. The Security Services comprise a group of security modules which provide the required security during a data communication. It includes the most commonly used cryptographic services.
Application router 54. The application router receives data from both the application layer 32 and the transport layer 58. An application registers for events from the application router 54. An application will send a message via the application router. The application router will then invoke the Message Encoder module for appropriate encoding, such as ComML. It then invokes the appropriate security module for encrypting the ComML message. The encrypted payload is then passed on to the transport layer 58.
Message encoding services 56. The application encoder facilitates encoding and decoding of messages which are invoked by the application router. In a preferred embodiment the encoder supports ComML encoding. Alternative encoding schemes can also be supported in this framework.
The Transport layer 58 utilizes a transport engine 60 for communication between the client application and the gaming server using TCP/IP or SMS protocols.
The Network interface layer 62 uses the underlying Air Interface technology for the mobile device to communicate with the gaming server. It can be either a GPRS network or a 1xEV-DO network.
A Game Server Model will now be described, FIG. 3. The game server architecture is designed as a stack of protocols. There are four layers in the game server model. Each layer has a set of functions to perform.
The application layer 64 consists of multiple application services, each serving a specific application or game 66, 68, 70, etc. Each application service communicates with a backend gaming system 72 designed for a specific game, which is part of the business layer. Below is an example of the communication markup language used between the client and the gaming server.


<!- -Root or Element- ->
<!ELEMENT ComML (ComHdr, ComBody)>
<!ELEMENT ComHdr (ProtoVersion, SessionID, Source, Destination, MsgSeq,
Auth)>
<!ELEMENT ComBody ((Alert \| Get \| Put \| Results)+, Final?)>
<- - Header Definitions - ->
<!- - Protocol Version. The protocol version supported by the communication
parties- - >
<!ELEMENT ProtoVersion (#PCDATA)>
<!Session ID. Each session can comprise multiple client/server interactions. They
will be represented by this unique Session ID- ->
<!ELEMENT SessionID (#PCDATA)>
<!- - Message Sequence Number- ->
<!ELEMENT MsgSeq (#PCDATA)>
<!- - The Source of the Message Originator. In case of the Client, it will contain
the MEID or ESN. In case of the Server, it will contain the AppServer ID. Each Application
Server instance will contain a unique ID.- ->
<!ELEMENT Source (#PCDATA)>
<!- - The Destination of the Message- ->
<!ELEMENT Destination (#PCDATA)>
<!- - Authentication Credentials used- ->
<!ELEMENT Auth (Data)>
<!- - End of Header Definitions- ->
<!- - Body Definitions- ->
<!- - Alerts are sent by the Server to the client upon registration by the Client.
Alerts will contain a CommandID, Application Target, Application Source, Optional Credentials
and ItemList- ->
<!ELEMENT Alert ((CmdID, AppTarget, AppSource, Cred?, Item+))>
<!- - Get Command can be used either by the Client or the Server. Get will
contain a CommandID, Optional Credentials and ItemList- ->
<!ELEMENT Get ((CmdID, AppTarget, AppSource, Cred?, Item+))>
<! - - Put Command can be used either by the Client of the Server. Put will
contain a CommandID, Optional Credentials and ItemList - ->
<!ELEMENT Put ((CmdID, AppTarget, AppSource, Cred?, Item+))>
<! - - Results will contain the execution result of Get and Put Command. The
CmdID MUST match that of the command it relates to.
Results will contain a CommandID, optional Credentials and ItemList- ->
<!ELEMENT Results ((CmdID, AppTarget, AppSource, Status, Cred?, Item+))>
<! - - The Final Node denotes the Final Transaction for this session. Any new
communication MUST begin as a new session- ->
<!ELEMENT Final (EMPTY)>
<! - - End of Body Definitions- ->
<! - - 2nd Level Definitions for Hdr - ->
<! - - Application Target. Used by the Application Router - ->
<!ELEMENT AppTarget (AppID, AppName?)>
<!- - Application Source. Used by the Application Router - ->
<!ELEMENT App Source (AppID, AppName?)>
<! - - A Unique Application ID is used to distinguish each Application - ->
<!ELEMENT AppID (#PCDATA)>
<! - -Optional Application Name - ->
<!ELEMENT AppName (#PCDATA)>
<! - - Data represents the actual Data for an element - ->
<!ELEMENT Data (#PCDATA)>
<! - - Item element type - ->
<!ELEMENT Item (Meta?, Data)>
<!- - Contains the Status Code - ->
<!ELEMENT Status (#PCDATA)>
<! - - End of 2nd Level Definitions - ->

The business layer 74 consists of entities which contain the business logic of various games and applications. The application layer will interact with the business layer modules to provide a comprehensive service to the clients.
The security layer 76 contains the same components as the security layer 50 of the client application model, see paragraph [0031] for a detailed description of these components.
The transport layer 78 contains the same components as the transport layer 58 of the client application model, see paragraph [0035] for a detailed description of these components.
The network layer 80 contains the same components as the network layer 62 of the client application model, see paragraph [0036] for a detailed description of these components.
A detailed description of the above applications will now be described. The user registers on the gaming server registration website for the first time. During registration the user will be asked to select a Passcode or Password that will be used for all future transactions. FIG. 5 is an example of a registration form template. The user will enter their name at 82. The user will then enter their mobile device identification number, for example their cell phone number, at 84. They can enter any other mobile identification number which the system can recognize. Next the user will enter their credit card number at 86. Next the expiration date of the credit card will be entered at 88. The user will next enter his/her date of birth at 90. The user will then select a passcode or password at 92. An image to be associated with their passcode/password can then be selected at 94. An agreement stating the rules and conditions of the game can then be presented to the user. If the user agrees to these conditions they will check the “Verify Agreement” box 96. The agreement is optional and may not be employed. If the user is satisfied with all the information they entered, they will then click on the “Accept” button 98. If they need to change some of the information they will click the “Reject” button 100 and enter new information. As part of the registration process the client and the server will follow the Asymmetric key encryption procedure of Passcode/Password verification. The server will send the encrypted XML configuration file to the client immediately after successful registration. This method will remove the need for the client application to communicate with the server each time the user logs in. The user will enter the Passcode/Password. The server will receive the Passcode/Password and encrypt it using the Asymmetric encryption algorithm. The server will then send the digitally signed XML configuration file with all the information including its Public Key, Digital signature and he encrypted Passcode/Password to the client. The client will store this information in their mobile device. Every time the user logs in, the client application prompts for a Passcode/Password. The Passcode/Password verification will happen at the client side since the XML configuration (encryption details) file is already present in the client's device.
The client application can be deployed in the following ways. The user can receive a SMS with a HTTP/WAP link. With a HTTP link the user can directly click on the link and download the application to the mobile device and install the application. With a WAP link the user can open a WAP browser and download the application and install it. The user can also insert a smart card into the mobile device with the client application loaded into it.
After the client application has been installed the user can launch the application to start playing the games. In the application menu on the client device the user can choose from the different games which are available. Once the user chooses the game from the menu the user then logs in by using his/her Passcode/Password each time before playing. Once the user starts playing the lottery game every state of the game will be stored in the client application and them communicated to the server. The communication language used for this communication was described in the application layer description above.
During the registration process the mode of payment which the user wishes to employ will be stored along with all relevant details into the database. The user's credit card will be charged based on the number of lottery games that are played. If the user does not provide the correct details for payment the application will nor allow the user to launch the game. The criteria for validation will be done by a 3rd party system verifying the authenticity of the credit card payment mode.
Confirmation of transactions. For every transaction made the user will be notified with following details. Transaction ID, date of transaction, transaction amount and date of lottery draw for games where the winner is not announced immediately.
All the winners will be notified utilizing the following modes of communication. E-mail, SMS, an IVR (interactive voice response).
The following steps illustrate the process for application based gaming.
Step 1. The user will register on the gaming server website for the first time, see FIG. 5.
Step 2. The user will provide all the required information. USER NAME, MOBILE NUMBER, CREDIT CARD NUMBER, EXPIRY DATE, DATE OF BIRTH, IMAGE and PASSCODE/PASSWORD.
Step 3. After successful registration the user will login using the registered Passcode/Password.
Step 4. After successful login the application will provide a list of games supported from which the user can select one form the menu.
Step 5. The user can start playing the game using the mobile device keypad or stylus.
Step 6. Once the game is complete the user will receive a notification of the transaction.
Step 7. The user will receive a confirmation of the results via e-mail, SMS or an IVR call.
Another embodiment of the present invention is IVR based mobile lottery gaming. IVR (interactive voice response) is a general term for mobile phone-based voice value-added services. By dialing a designated number, mobile phone users are able to listen to or send information or even participate in interactive activities like lottery games. The following process explains the details of how IVR can be used to play mobile lottery games. FIG. 7 is a flowchart illustrating this process.
An IVR number is called from a mobile device which allows the user to register 102. The registration process 104 allows the user establish an account with a server. The user can them login using their passcode and/or selected image 106. If the incorrect passcode and/or image is entered 108 the user is instructed to enter this information again. After a number of unsuccessful login attempts, for example 5, the user is sent to the end of the program and not permitted to play the game 110. If the user wants to continue they must repeat the registration process 104 again. Once the user has logged in they can choose the game they wish to play from the IVR menu 112. For example the user may wish to play a PICK 3 Lottery game. Next at 114 the user will provide the arguments or select the numbers they wish to play on the keypad of the mobile device or other data entering device. For example the user may enter “02”, “34” and “45” on the keypad. The transaction is confirmed at step 116. Depending on the game which is selected there will either be an immediate draw of the winning numbers 118 or a date will be given on which the winning numbers are to be drawn 120. If the drawing is at a later date the user can check back on their mobile device for the winning number or can check other sources such as the television, a lottery terminal, the newspaper, etc. The gaming application is then ended at 122.
A detailed description of the IVR based gaming process is as follows. The user registers of the gaming server registration website for the first time. During registration the user will be asked to select a Passcode/Password that will be used for all future transactions. FIG. 5 illustrates the registration website. The following details are required to be provided by the user for registration. User name, mobile device number, credit card number, expiry date, date of birth and passcode/password.
After successful registration the user can start playing the lottery game. The user will call the toll free IVR number for playing the lottery games. For example, when the user calls the toll free number (1-800-555-5555) the user will be connected to the IVR server. The user will be greeted by voice prompts. The user will follow the voice prompts and enter the required details accordingly. The IVR will prompt the user to choose the game from the available menu. The prompts can be as follows: 1—PICK 3; 2—PICK 6; 3—LOTTOPLUS; 4—KENOPLUS; 5—SCRATCH & WIN; etc. If the user selects 1 the game will be PICK 3. Every time the user wants to play the Passcode/Password must be entered. The Passcode/Password will be received by the IVR in the form of DTMF signals or Voice recognition.
To start the game the user provides the relevant inputs for the game selected and completes the game. For example, if the user wants to play PICK 3, the user will pick three numbers as inputs to the game. The user then enters the three numbers or says the three numbers (IVR with voice recognition) after the prompts. During the registration process the mode of payment that the user wishes to use will be stored along with all relevant details into the database. The user's credit card will be charged based on the number of lottery games that are played. If the user does not provide the correct details for payment the application will not permit the user to play the game. The criteria for validation will be done by a 3rd party system verifying the authenticity of the credit card payment mode. For every transaction made the user will be notified with the following details: Transaction ID, date of transaction, transaction amount and date of lottery draw (for games where the winner is not announced immediately). All of the winners will be notified in the following modes of communication: e-mail, SMS, an IVR call, etc.
The following steps illustrate IVR based gaming.
Step 1. The user calls the IVR to register for mobile lottery gaming.
Step 2. IVR provides all the details about the mobile lottery gaming and information required from the user to register like name, mobile number, credit card number, expiry date, age and passcode/password.
Step 3. After successful registration the user logs in using the registered Passcode/Password.
Step 4. After successful login the IVR system will provide the list of games supported from which the user can select on to play.
Step 5. Based on the lottery game selected, the user can provide the arguments of numbers as described in FIG. 7. The user should enter the arguments or numbers from the mobile device keypad and the IVR receives the arguments through DTMF signals. The user and the IVR can also exchange information by interactive voice recognition and response.
Step 6. Once the entry is recorded in the server the user will receive a notification of the transaction.
Another embodiment of the present invention is WAP based lottery gaming. WAP is more than just browser software for a phone. It is a complete suite of protocols that tries to provide its capabilities on a multitude of data-based wireless protocols. The WAP browser provides media to access the Internet on the mobile device by taking into account the limited resources available in the mobile device. The following process explains the details of how WAP based lottery gaming can be used to play mobile lottery games. FIG. 8 is a flowchart illustrating this process.
A WAP browser is launched from the mobile device 124. The registration process 126 allows the user establish an account with a server. The user can them login using their passcode and/or selected image 128. If the incorrect passcode and/or image is entered 130 the user is instructed to enter this information again. After a number of unsuccessful login attempts, for example 5, the user is sent to the end of the program and not permitted to play the game 132. If the user wants to continue they must repeat the registration process 126 again. Once the user has logged in they can choose the game they wish to play from the WAP menu 134. For example the user may wish to play a PICK 3 Lottery game. Next at 136 the user will provide the arguments or select the numbers they wish to play on the keypad of the mobile device or other data entering device. For example the user may enter “02”, “34” and “45” on the keypad. The transaction is confirmed at step 138. Depending on the game which is selected there will either be an immediate draw of the winning numbers 140 or a date will be given on which the winning numbers are to be drawn 142. If the drawing is at a later date the user can check back on their mobile device for the winning number or can check other sources such as the television, a lottery terminal, the newspaper, etc. The gaming application is then ended at 144.
A detailed description of WAP based lottery gaming is as follows. The user registers of the gaming server registration website for the first time. During registration the user will be asked to select a Passcode/Password that will be used for all future transactions. FIG. 5 is an example of the registration website. The user will be required to provide the following details. The user's name, the mobile device number, a credit card number, the expiry date of the credit card, the user's date of birth and a passcode/password. After successful registration the user will login to the gaming server with the unique Passcode/Password before playing the game. The user will start playing the lottery game through the WAP browser on the mobile device. All the states of the game will be stored in the server until the user logs off the game. During the registration process the mode of payment that the user wishes to utilize will be stored along with all relevant details into the database. The user's credit card will be charged based on the number of lottery games which are played. If the user does not provide the correct details for payment the application will not permit the user to play the game. The criteria for validation will be done by a 3rd party system reifying the authenticity of the credit card payment mode. For every transaction made the user will be notified with the following details: transaction ID, date of transaction, transaction amount and date of lottery draw (for games where the winner is not announced immediately). Once the payment transaction is complete the user will be immediately notified. The winners will be notified by e-mail, SMS, an IVR call, etc.
The following steps illustrate WAP based gaming.
Step 1. The user launches the WAP browser to register for the mobile lottery gaming.
Step 2. The user enters all the information required from the user to register.
Step 3. After successful registration the user logs in using the registered Passcode/Password.
Step 4. After successful login the system will provide a list of the games supported from which the user can select a game to play.
Step 5. Based on the lottery game the user can enter the arguments or numbers in the browser as described above.
Step 6. Once the entry is recorded in the server the user will receive a notification of the transaction.
Another embodiment of the present invention is SMS based lottery gaming. Short Message Service (SMS) is a communication protocol allowing the interchange of short text messages between mobile telephony devices. The following process illustrates how mobile phone users can use SMS to play lottery games on the mobile devices. FIG. 9 is a flowchart illustrating SMS based gaming.
A SMS is sent from the mobile device to register 146. The registration process 148 allows the user establish an account. The user can them login using their passcode and/or selected image 150. If the incorrect passcode and/or image is entered 152 the user is instructed to enter this information again. After a number of unsuccessful login attempts, for example 5, the user is sent to the end of the program and not permitted to play the game 154. If the user wants to continue they must repeat the registration process 148 again. Once the user has logged in they can choose the game they wish to play from the menu at 150. For example the user may wish to play a PICK 3 Lottery game. Next at 150 the user will provide the arguments or select the numbers they wish to play on the keypad of the mobile device or other data entering device. For example the user may enter “02”, “34” and “45” on the keypad. The transaction is confirmed at step 156. Depending on the game which is selected there will either be an immediate draw of the winning numbers 158 or a date will be given on which the winning numbers are to be drawn 160. If the drawing is at a later date the user can check back on their mobile device for the winning number or can check other sources such as the television, a lottery terminal, the newspaper, etc. The gaming application is then ended at 162.
A detailed description of SMS based gaming is as follows. The user will register of the gaming server registration website for the first time. During registration the user will be asked to select a Passcode/Password that will be used for all future transactions. FIG. 5 illustrates a registration website. The user will be asked to provide the following details. The user's name, the mobile device number, a credit card number, the expiry date of the credit card, the user's date of birth and a passcode/password. The user will send a SMS to the server with the required details for a game. The user's passcode/password, the name of the game and the arguments or selected numbers. For example, if the user wants to play a PICK 3 game, the user will select three numbers and send a SMS in the following text format: “PWD PICK3 23 45 12”. During the registration process the mode of payment that the user wishes to utilize will be stored along with all the relevant details into the database. The user's credit card will be charged based on the number of lottery games that are played. If the user does not provide the correct details for payment the application will not permit the user to play the game. The criteria for validation will be done by a 3rd party system verifying the authenticity of the credit card payment mode. For every transaction made the user will be notified with the following details. The transaction ID, the date of transaction, the transaction amount, and the date of the lottery draw (for games where the winner is not announced immediately). The winners will be notified by an e-mail, a SMS an IVR call, etc.
The following steps illustrate SMS based gaming.
Step 1. The user sends a SMS to the SMSC gateway register for mobile lottery gaming.
Step 2. The user registers using a credit card number and PIN number.
Step 3. After successful registration the user sends a SMS to the SMSC gateway in the following format “PASSCODE/PASSWORD”, “Name of the Game” and “Arguments to the game”.
Step 4. Once the entry is recorded in the server the user will receive a notification of the transaction as a SMS confirmation.
Step 5. If the lottery game provides immediate results, like a scratch and win game the user will be notified immediately. In the case of a delayed drawing, the user will be notified of the drawing date.
All patents and publications mentioned in this specification are indicative of the levels of those skilled in the art to which the invention pertains. All patents and publications are herein incorporated by reference to the same extent as if each individual publication was specifically and individually indicated to be incorporated by reference.
It is to be understood that while a certain form of the invention is illustrated, it is not to be limited to the specific form or arrangement herein described and shown. It will be apparent to those skilled in the art that various changes may be made without departing from the scope of the invention and the invention is not to be considered limited to what is shown and described in the specification and any drawings/figures included herein.
One skilled in the art will readily appreciate that the present invention is well adapted to carry out the objectives and obtain the ends and advantages mentioned, as well as those inherent therein. The embodiments, methods, procedures and techniques described herein are presently representative of the preferred embodiments, are intended to be exemplary and are not intended as limitations on the scope. Changes therein and other uses will occur to those skilled in the art which are encompassed within the spirit of the invention and are defined by the scope of the appended claims. Although the invention has been described in connection with specific preferred embodiments, it should be understood that the invention as claimed should not be unduly limited to such specific embodiments. Indeed, various modifications of the described modes for carrying out the invention which are obvious to those skilled in the art are intended to be within the scope of the following claims.

Claims

1. A system for distributing a game comprising:

a mobile device including means for communicating with a game server;

said game server including a memory for storing information to identify said mobile terminal;

an encrypted file stored on said mobile device, said encrypted file containing information which identifies said mobile device to said game server;

an application layer containing a number of games applications to be played;

a security layer consisting of an application router, a cryptographic service and a message encoding service; a transport layer permitting communication between a client application and said game server; and a network layer permitting communication between said mobile device and said game server.

2. The system of claim 1 wherein said application layer utilizes a model-view-controller to communicate data between an event and a display on said mobile device.

3. The system of claim 1 wherein said transport layer utilizes a transport engine for communication between said security layer and a network on said network layer.

4. The system of claim 1 wherein said transport layer utilizes TCP/IP protocols for communication between an application of said mobile device and said game server.

5. The system of claim 1 wherein a business layer communicates between a backend gaming system and said game applications, said business layer further contains authentication services to provide date to said game applications.

6. A method of providing electronic lottery games comprising:

transmitting user identification information over a wireless network from a mobile device to a server to establish an account;

transmitting information over a wireless network from a mobile device to said server to access said account;

transmitting a choice of lottery games from said server to said mobile device wherein said user can choose at least one of said games;

selecting one of said games;

transmitting payment for said at least one game from said mobile device to said server;

transmitting data from said mobile device to said server, said data including arguments for said selected game; and

notifying said user of the results of said at least one game.

7. The method of providing electronic lottery games of claim 6 wherein said server provides a plurality of games from which said user can choose to play.

8. The method of claim 6 wherein a business layer communicates between a backend gaming system and game applications.

9. The method of claims 6 wherein an interactive voice response system is utilized to communicate between said mobile device and said server to transmit information and play said games.

10. The method of claim 6 wherein a WAP is utilized to communicate between said mobile device and said server to transmit information and to play said games.

11. The method of claim 6 wherein a short message service is utilized to communicate between said mobile device and said server to play said games.