A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Users may operate cellular telephones for numerous purposes. For example, users may contact one another, play games, access the internet, etc. Messaging and file upload and download between the user and a system and between numerous users is commonly found. The internet is one network that allows these activities. However, to use the internet as the conduit via which to perform these activities is costly. To reduce cost, many cellular telephones use Short Message Service (SMS) text messaging, such as that described in Simon Buckingham, What is SMS?, http://www.gsmworld.com/technology/sms/intro.shtml (2000), rather than the internet. Indeed, in many countries, the cellular telephones that provide for SMS text messaging far outnumber the cellular telephones that provide internet service. Consequently, to reduce cost, and to provide accessibility to as many cellular telephone users as possible, there is a great desirability to provide a way to use SMS text messaging for mobile applications wherever possible.
BRIEF DESCRIPTION OF THE DRAWINGS
Gaming systems are in widespread use and continue to grow in popularity. For example, the use of point-of-sale terminals has expanded from traditional retail environments to a wide variety of non-traditional environments. Indeed, in some markets consumers can purchase lottery tickets via the internet from the comfort of their own home.
FIG. 1 a is a flowchart that illustrates an example procedure in which lottery game data may be sent to an application server, according to an example embodiment of the present invention.
FIG. 1 b is a flowchart that illustrates an example procedure in which lottery game data may be sent to a remote terminal, according to an embodiment of the present invention.
FIG. 2 is a block diagram that illustrates the components of an example wireless network, according to an example embodiment of the present invention.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS
FIG. 3 is a flowchart that illustrates an example procedure in which players may collaborate to play a lottery game, according to an example embodiment of the present invention.
SMS text messaging support for mobile lottery game systems, where a user may purchase, via a cellular telephone or any remote terminal of a wireless network, an electronic lottery ticket for a future drawing or other lottery games, such as instant win games, e.g., simulated scratch-off games; highly graphical user interactive games; and any other kind of lottery game, is not provided. Accordingly, there is a need in the art for SMS text messaging support for mobile lottery games in a wireless network.
Embodiments of the present invention generally relate to mobile lottery games. More particularly, embodiments relate to the use of Short Message Service (SMS) text messaging to transmit data relating to lottery games over a wireless network.
To reduce cost and also to make mobile lottery games available to a multitude of cellular telephone users whose cellular telephones provide support for SMS text messaging, but not for internet, embodiments of the present invention provide for lottery games data to be transmitted over a wireless network as SMS text messages. A gaming SMS text message is an SMS text message representation of lottery game data. Lottery game data is data of a lottery game provider system, such as a lottery game request, the actual lottery game, or other lottery game data as will be described.
FIGS. 1 a and 1 b are flowcharts that illustrate an example procedure in which a user may obtain a lottery game from a data center, according to an example embodiment of the present invention. In FIG. 1 a, a remote terminal receives player input data in 1. The data may include, for example, a lottery game request. The data may identify the particular game a player desires, for example a lottery ticket, in particular an electronic representation of a lottery ticket. The data may include, for example, a series of numbers for a lottery ticket drawing, and/or the date of the drawing in which the user wishes to enter. Other data may include player or phone identification data, security information or codes, geographic information, etc. The request may be sent, e.g., over a wireless network, ultimately for submission to an application server in the data center. The application server processes lottery game transactions to provide lottery games to remote terminals. Once the request is submitted, in FIG. 1 b, the application server, using the reverse process, may return a requested lottery game toward the remote terminal. The requested lottery game may be, for example, an electronic representation of a lottery ticket and/or a lottery entry confirmation. The described process may be used for all data transfer between the application server and the remote terminals.
In an embodiment of the present invention, players may purchase lottery tickets for a future drawing. In FIG. 1 a
, players purchase tickets, in 1
, e.g., by inputting requests for tickets into their cellular telephones, or any other wireless network remote terminals. In 100
, the remote terminal may export data, e.g., the requests, security information, player or account code information, etc. The data may originate in 100
, for example, as a Java transaction object. In 110
, the requests may be converted into SMS text messages. At 125
, the requests may be transmitted, e.g., over the wireless network towards the game-provider
s data center. The requests may be submitted to the data center in 130
. In 135
, multiple requests, for example from many players using many remote terminals, may be aggregated and routed to, for example, particular application servers. After the data center receives the SMS text messages, in 140
, the SMS text messages may be converted to, for example, Java transaction objects. In 160
, an application server may receive the Java transaction objects and decipher them as lottery game requests. The application server may then, for example, retrieve the correct games (i.e. the tickets for the requested drawing). In FIG. 1 b
, the application server may export data, e.g., the games, in 101
. The data may originate as Java transaction objects, for example. In 111
, the data may be converted into corresponding SMS text messages. In 136
, multiple messages, for example from a number of application servers, may be aggregated and routed, for example to a number of remote terminals. In 131
, the data may be exported from the data center. In 126
, the SMS text messages may be transmitted over the wireless network toward the requesting remote terminals. To complete the process, in 141
, the SMS text messages may be converted into, for example, Java transaction objects. In 161
, the messages, already converted into Java transaction objects, may imported into the remote terminals, for example to, display the games on the remote terminals' user interface display. Alternatively, the games may be displayed by any other data output means, such as a printout. Alternatively, the games may also be stored for future play, e.g., as an animated graphical game which may be displayed on a user's cell phone.
According to an embodiment of the present invention, messages, whether those in the form of requests or other data sent by the remote terminals toward the data center, or those in the form of games or other data sent by the data center toward the remote terminals, originate as Java transaction objects and are converted to SMS text messages for transmission over the wireless network. A number of translators may be employed to implement this conversion. More particularly, three translators may be employed.
In FIG. 1 a, when transmitted from the remote terminal toward the application server, the data may originate, in 100, as a Java transaction object and may undergo a series of conversions before transmittal, in 125, over the wireless network. In 110, translators may convert the message first from a Java transaction object to a binary message, then, in 115, to an ASCII text message, and finally, in 120, to an SMS text message. Once in an SMS text message format, in 125, the message may be sent over the wireless network toward its intended destination, e.g., the application server. Once sent over the wireless network, the reverse process may take place in 140, 145, and 150, wherein the message is reconverted to a Java transaction object for use at the intended destination, i.e. the application server.
Similarly, in FIG. 1 b, data may be transmitted from the application server toward the remote terminal. In 101, the data may originate, e.g., as a Java transaction object. The data may undergo a series of conversions. In 111, translators may convert the message first from a Java transaction object to a binary message, then, in 116, to an ASCII text message, and finally, in 121, to an SMS text message. In 126, the converted data may be transmitted over the wireless network. The data may be sent as an SMS message over the wireless network toward its intended destination, e.g., the remote terminal. Once sent over the wireless network, the reverse process may take place in 141, 146, and 151, wherein the message is reconverted to a Java transaction object for use at the intended destination, e.g., the remote terminal.
Consequently, two sets of translators (e.g., 6 translators total) may be provided, one set for messages transmitted between the wireless network and the remote terminals, and a second set for messages transmitted between the wireless network and the data center. The remote terminals and the data center may each contain their own set of translators, or external translators may be provided to perform the necessary translations.
Various communication protocols may be employed for transmitting game data between a remote terminal and an application server. Similarly, various messaging protocols, by which a translator translates game data between a Java transaction object and an SMS text message, may be employed. The discussed embodiment that employs a messaging protocol, whereby translators translate between a Java transaction object and a binary message, between a binary message and an ASCII text message, and between an ASCII text message and an SMS text message, is only one example protocol. Those skilled in the art can appreciate that other translators, that employ other messaging protocols for converting game data between a Java transaction object and an SMS text message, may be employed.
The above-described data transmission process may be repeated numerous times depending on the type of games the players play. For example, players may request quick pick tickets, wherein the game provider pre-selects the lottery ticket numbers, in which case after receiving the lottery games, the players need not send new data to the data center. Alternatively, players may choose to manually pick the lottery ticket numbers. In this instance, in FIG. 1 a, the players may input their lottery ticket numbers into their remote terminals, in 1, and the inputted numbers may be transmitted toward the data center, in 125-130, as SMS text messages. Subsequent to the lottery drawing, the data center may transmit toward the remote terminals follow-up win-loss notices, SMS text messages that indicate to the remote terminals whether the players have won or lost the lottery games. The winnings may vary according to drawing. For example, one lottery-drawing's grand prize may be one million dollars, while another lottery-drawing's grand prize may be two hundred thousand dollars. Each drawing may have a number of win levels, for example, a grand prize of one million dollars and a second prize of two hundred thousand dollars. The follow-up win-loss notices may indicate a win type, e.g., grand prize winner or second prize winner, and it may indicate a win amount, e.g., one million dollars or two hundred thousand dollars.
In an alternative embodiment, the remote terminals may locally store the inputted numbers, wait for SMS text messages from the data center indicating the winning numbers, match the winning numbers, and if the two number sets match, transmit SMS text messages toward the data center indicating a win. The remote terminals may also indicate the type of win, e.g., grand prize or second prize.
In an alternative embodiment of the present invention, players may play lottery games having highly enriched graphics. The highly enriched graphics games may take the form of interactive games that give the players the illusion that they are playing games of skill. However, even these games may be games of chance, the game outcome independent of player skill. These games may depend on a future event. Alternatively, the data center may encode the transmitted lottery games with predetermined outcomes. The players are not initially made aware of the predetermined outcomes. Once the games are played, the players learn of their games' outcomes. The outcomes may be based on an algorithm that randomly assigns winning and losing outcomes. In contrast with the embodiment involving lottery tickets, in this embodiment, players are not credited with a win until the players actively play their games and win.
In an alternative embodiment, the games may take the form of instant win games. For example, a scratch-off lottery game, wherein a card has a number of concealed game results, may be simulated on a display. The players learn the game's outcome by uncovering the concealed predetermined lottery game results. The outcome may be based on an algorithm that randomly assigns winning and losing outcomes. Players may be credited with a win after the players actively play their games and win.
After the data intended for the application server is sent, in 125, over the wireless network, an aggregator may, in 135, collect the data, identify the requesting terminal from which the data was sent, and, if more than one application server is provided, route the message to the corresponding application server. Similarly, in FIG. 1 b, before sending the message from the application server over the wireless network, the aggregator may, in 136, route the message to the intended requesting terminal.
FIG. 2 is a block diagram that illustrates an example embodiment of the physical architecture of the present invention. The diagram illustrates the components of an example wireless network. A player may input data into cell phone 200. The input data or other cell phone game data may be converted by translators 202, shown here by way of example as external to cell phone 200, into SMS text messages. The SMS text messages may be sent via wireless network 205 toward data center 210. Translators 207, shown here by way of example as external to data center 210, may translate the SMS text messages into, for example, Java transaction objects. Within data center 210, aggregator 215 may be provided to collect cell phone game data of numerous cell phones and route the data to an appropriate application server 235. Additionally, aggregator 215 may route application server data to the correct cell phones 200. To implement routing of data to an appropriate application server 235, routers 220 may be provided. A single or multiple firewalls 225 may be provided to protect application server 235 from corrupt data. Switches 230 may be provided to facilitate input to and output from application server 235.
Data center 210 may facilitate the play of many different types of games. Therefore, data center 210 may provide for many application servers 235, wherein each application server 235 contains and provides only some of the lottery games provided by data center 210.
Since many players may each request a single or multiple games, aggregator 215 may be provided. The aggregator 215 may be configured to collect each of the game requests (or other terminal data), route each request to the corresponding application server 235, receive the SMS text message representing the game (or other game data), and route it to the corresponding cell phone 200. Aggregator 215 may be provided within data center 210. Alternatively, external aggregators may be provided.
According to an embodiment of the present invention, data center 210 may keep an account for each lottery game player or, alternatively, for each cell phone 200. Alternatively, a separate entity for account holding may be provided, wherein data center 210 and the separate entity are communicatively in contact. Any number of schematics may be employed with numerous entities in contact with each other to facilitate the use of the present invention.
To record debits and credits of a player
s account, application server 235
may be connected to account records 240
. When a player purchases a lottery game, application server 235
may indicate the purchase to account records 240
to record a debit. When a player wins a lottery game, application server 235
may indicate the win to account records 240
to record a credit. In an alternative embodiment, aggregator 215
may directly route account records data to account records 240
to process a credit or a debit, bypassing application server 235
. The amounts debited and credited may vary depending upon the games the players play.
In an embodiment of the present invention, as illustrated in FIG. 2
, data center 210
may be in contact with a player
s bank 245
, or other financial entity, for funds transfers according to a player
s account in account records 240
. Funds transfers may take place at predetermined time intervals, such as weekly, monthly, etc. Alternatively, funds transfers may take place transactionally, wherein, for example, funds are transferred from the player
s bank 245
immediately upon a lottery game purchase.
FIG. 3 is a flowchart that illustrates an example procedure in which many players who use individual cell phones 200 may contact one another to collaboratively play a lottery game, according to an embodiment of the present invention. By way of example, the flowchart illustrates this procedure with respect to a lottery drawing game.
In 300, players enter input into their cell phones indicating a desire for collaborative play. In 305, one or all of the collaborating cell phones 200 may request from data center 210, via an SMS text message, the purchase of the lottery drawing game and may indicate the cell phones 200 contributing to the lottery game. Each cell phone 200 may contribute to the game equally or with varying percentages. In 310, the extent of the contribution of each cell phone 200 may be indicated to data center 210. Alternatively, a player chosen share distribution may be indicated. Alternatively, an indication of collaboration may be indicated, so that debits and credits are equally distributed among the participating cell phones' accounts. These indications of collaboration, contribution percentages, and/or share allocations may be transmitted toward data center 210 when the game is purchased. In an alternative embodiment, the indications may be transmitted subsequent to game play.
In 315, the lottery drawing may be conducted. In 320, data center 210, for example, may determine whether cell phones 200 won or lost. In 325, if cell phones 200 lost, data center 210 may transmit a notice of loss toward cell phones 200. If cell phones 200 won, in 326, data center 210 may determine the win type and/or win amount. Then in 331, data center 210 may transmit a notice of win, win type, and/or win amount toward cell phones 200.
In accordance with computations in 330
, respectively, account records 240
may allocate a portion of the debits and credits pertaining to the collaboratively purchased lottery game, in 335
, respectively, to each of the contributing cell phones 200
. The computations in 330
, respectively, may be in accordance with the equal or varying contributing percentages. Alternatively, the collaborating players may indicate the percentages of each collaborating player
s share in the debits and credits. The indicated percentages need not equate with the players' contributing percentages. The amount allocated may be in accordance with the indicated percentages, rather than the contributing percentages.
In 345, each cell phone 200's balance may be computed based upon each cell phone 200's debits and credits. At some point in time, in 350, funds transfers between each cell phone 200's bank and application server 210 may be implemented, based upon each cell phone 200's balance.
Data center 210 may itself provide the cell phones 200 with messaging capabilities to transmit messages over the wireless network. Alternatively, data center 210 may collaboratively coordinate its functionalities with those of one or many cellular-telephone-providers' functionalities, for example, to provide the cell phones 200 with the messaging capabilities. Any of numerous implementations of physical network architectures as known in the art may be employed. Numerous networks, each with various assigned functions may be interconnected to achieve the described system or method. Data center 210 may employ a number of aggregators, routers, firewalls, switches, and application servers. Alternatively, some of these components may be externally provided. Any communication protocol as known in the art, such as GPRS, SMSC, TCP/IP and RMI, may be used to transmit data within the network.
Those skilled in the art can appreciate from the foregoing description that the present invention can be implemented in a variety of forms. Therefore, while the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, specification, and following claims.