WO2003008058A1

WO2003008058A1 - Method for drawing lots and determining a possible winning amount in an electronic lottery

Info

Publication number: WO2003008058A1
Application number: PCT/NO2002/000265
Authority: WO
Inventors: Martin Wardenaer
Original assignee: Martin Wardenaer
Priority date: 2001-07-16
Filing date: 2002-07-15
Publication date: 2003-01-30
Also published as: NO313308B1; NO20013520D0; EP1420863A1; NO20013520A

Abstract

The present invention discloses a method for drawing lots and calculation of a possible prize in an electronic lottery in a central server. In a storage device of the server, a number of counters are stored, used to determine if wins occur for lottery ticket requests. The requests are queued and executed in the same order as they arrived the server. The counters are incremented for each request, and each counter is then compared with a respective winning number. A win occurs when a counter is equal to its associated winning number, and the winning value is proportional to the winning number of that counter, wherein the proportional ratio is a constant stored in said storage device. The winning number may be constant, or may be calculated again each time the counter reaches its associated winning number. The winning value may also be constant, or vary in a corresponding way. At each winning occurrence, the respective counter is reset to an initial value, or the respective winning counter is set to a value larger than the respective counter. The method may, e.g., be used in an electronic lottery where the lottery tickets are ordered from a cellular phone, e.g. by transmitting a short message to a certain telephone number.

Description

METHOD FOR DRAWING LOTS AND DETERMINING A POSSIBLE WINNING AMOUNT IN AN ELECTRONIC LOTTERY

Field of the invention

The present invention is related to electronic lottery, in particular a method for drawing lots and determining a possible winning in a electronic lottery.

Background of the invention

In a conventional lottery, a participant buys a lottery ticket from a commission agent, and may check the result either immediately, if the lottery is predrawn, or at a later time if the lots are drawn after the selling period.

The market of public lottery and money games is now going through a changeover period where electronic media in a greater degree are utilised in connection with drawing, sale and distribution of lots.

However, in most countries, both electronic and conventional lotteries have to satisfy governmental demands to be approved as public lotteries or available for more than a certain number of persons. Such demands could be a completely random drawing, a minimum share of the pool has to return to the players as winnings, and/or that the game organizer has to provide an economical guarantee for the prizes .

The International Patent Application WO 01/03786 Al discloses an example of technological infrastructure for an electronic lottery. In this system, a wireless communication terminal for transmitting a request for a lottery ticket to a central server is utilised. The request is transmitted, e.g. via a short message, through a cellular network to a processor issuing lottery tickets, and decides if the tickets give prizes based on predefined criterions . The publication does not specify how the drawing of the electronic lots is executed.

The main disadvantage of most lottery systems is that the issuer has to generate, store and possibly distribute a list containing the predrawn winning tickets. This represents a security problem as intruders may get access to this list, and thereby be able to abuse the lottery by choosing, faking or generating a winning ticket.

Another disadvantage of this type of predrawings is that sale and distribution of lottery tickets in traditional lotteries take place simultaneously through geographical, or other in other ways, separated points of sale. Thus, it may be difficult to coordinate the lottery winnings in a model where the lottery tickets are generated and issued "on site", as two or more equal winning tickets may be issued simultaneously.

Still another disadvantage with conventional lotteries is that there is a risk of drawing too many prizes at an early stage of the lottery, before the lottery organizer/issuer has had enough income from ticket sales to be able to pay out the prizes. Therefore, it is in general demanded that the lottery organizer must guarantee for a relatively large amount before the lottery can be launched. In addition, if it is revealed that the winning tickets are already sold out, the ticket sale may be considerably reduced.

Summary of the invention

The object of the present invention is to provide a method solving at least the problems described above. The method is defined by the independent claim 1 of the enclosed set of claims.

In particular, the present invention discloses a specific method for implementing certain drawing criterions, in other words a method for executing lottery drawing and subsequent winning calculation of an electronic lottery within a central server.

The basis of the method of the present invention is an infrastructure wherein the individual lottery participants communicate with the same ticket issuing device (i.e. the central server) , allowing a serial execution of ticket requests .

In the server, there is a number of counters being used to determine whether a winning occurs for a certain ticket request. The requests are queued and executed in the same order as received by the server. The counters are all incremented for each incoming request. Then, each counter is compared with an associated winning frequency. A winning ticket will occur when the a counter is equal to its associated winning frequency, and the prize is then equal to an amount being proportional with the winning frequency for this counter. The winning frequency, from now on referred to as the winning number, may be constant or may be calculated again after each time it is equal to its associated counter.

According to one embodiment of the present invention, the respective counter is reset to an initial value when winnings occur. Alternatively, only the winning number is reset, assumed that it is larger than the associated counter. The point of both the versions of the embodiment is to always have a numerical distance between the current value of the counters and their associated winning numbers. The purpose is that a counter and its associated winning number at given intervals are equal to each other and consequently trigger a prize to be paid out. As all the counters increase by one, this could be implemented either by setting a counter after an associated winning pay-out to a value below the respective winning number, or by setting the winning number to a value over the respective counter. The method could, for instance, be utilized in an electronic lottery where the lottery tickets are ordered by a user from a cellular phone by, e.g., transmitting a short message to a certain telephone number. The operator of the cellular network must provide required authorisation and billing, and forward the request to the server executing the drawing. The server returns the result of the drawing to the operator, which in turn takes care of the transfer of the winning amount (if any) to the user's account, and informs the user about the result in a short message transmitted to the user.

Brief description of the drawings

Figure 1 is a block diagram showing a schematic view of one embodiment of the present invention,

Figure 2 is a flow chart of an example embodiment of the method according to the present invention,

Figure 3 is a graphical representation of the winning model of the example embodiment of figure 2,

Figure 4 illustrates how the present invention may be utilised in the context of a cellular network operator, a user and a bank.

Preferred embodiments of the present invention

The present invention is related to a method for drawing lots and calculation of winnings in an electronic lottery implemented in a central computer or server.

The drawings are initiated by external requests. The requests may be originated from devices or users from external participants, like e.g. a cellular network operator. The cellular network operator may have received an order for a ticket in the lottery from a subscriber in a short message (e.g. SMS or MMS) . The order from the subscriber may also have been received in other ways, e.g. through a WAP interface, on a WAP page, or similar. One could also imagine the possibility of subscribing tickets so that a ticket request from a certain user occurs automatically at fixed points of time. In any case, the lottery organizer and the cellular network operator must in advance have agreed upon aspects related to billing, winning pay-out, verification of participants, technical aspects etc.

Information identifying the ticket buyers (telephone number, bank account etc.) is not passed on to the electronic drawing module of the lottery, making it impossible to affect the drawings based on such data.

The drawings are executed sequentially, that is consecutive in correlation with incoming requests. The requests are placed in a queue, and thereupon executed in the order received by the server.

In the lottery server, there is a set of counters including one or more counters. For each request, these counters are increased by one unit (e.g. the integer 1). The counters are compared with their associated winning numbers, and the counter (s) being equal to its/their respective winning numbers will give a winning that is proportional to said counter's associated winning number. The total winning value of the ticket is calculated by adding the winnings of all counters that lead to a prize. When a counter leads to a prize, it is reset to an initial value.

According to a preferred embodiment of the present invention, the winning number for one of the counters is replaced with a new winning number when the former is reached by said counter. The new winning number is randomly selected from, e.g., a predefined set of integers. A prize for this counter will again occur the next time the new winning number is reached, i.e. after a certain number of requests after reaching the first-mentioned counter.

Figure 2 is a flow chart showing an example embodiment of the present invention, where the set of counters includes three different counters with three respective winning numbers, among which two are constant and one is variable, i.e. it is changed each time it is reached by its associated counter.

Upon an incoming request for a lottery ticket, all counters are increased by one unit. Then the counters are compared with their associated winning numbers. If one or more counter/winning number pair is equal, then winnings occur corresponding to the sum of the winning value (s) that apply/applies to the counter (s) being equal to its/their winning number. The counter (s) that gave a prize (s) is then set to, e.g., zero, and a new winning number may be calculated and stored. The winning amount of a counter is always proportional to its associated winning number. The proportional ratio between the winning number and winning amount for each counter is defined prior to the start-up, and stored as constants in a storage device.

When all counters have been checked against their associated winning numbers, and a possible winning amount has been calculated, a message informing about the result is transmitted to the ticket buyer. If the ticket resulted in prize, the buyer will also be informed about the winning amount, e.g. together with a unique winning code so that the prize is possible to identify and verify by/against the rightful winner. According to the preferred embodiment of the invention, the prize is transferred immediately to the winner's bank account, through the underlying system of the operator .

Figure 3 shows the winning frequency of each of the counters in an example embodiment of the invention, represented by winning lines, in addition to the combined winning frequency. Notice that the winning markers of winning line 3, representing the variable winning number, are examples only, as the actual winning frequency/prize amounts are determined by the server during the lottery.

According to a preferred embodiment of the present invention, the program itself is compiled in the server at the beginning of the lottery to a closed module where all parameters of the lottery (drawing algorithms, winning values etc.) are hard coded directly in the program, and no variables being used during run time are communicated to or are made available to users or systems outside the server module. In other words, there are no "soft" system variables that are changeable during runtime (not even for attendants with valid password and physical access to the machine in which the lottery runs) .

Figure 4 shows how the present invention may be utilised in the context of a cellular network operator, a user and a bank. The player (user, participant) enters a code word for participating in the lottery according to a predefined syntax, and sends it as a short message to an access number for the lottery 1. The message is transmitted via the cellular network operator to the game server of the lottery.

Then, a response is returned informing the player about the forthcoming transaction, and asking the player to confirm the ticket purchase 2. The response is transmitted through a platform of the cellular network operator.

The confirmation of the ticket purchase is transmitted to a so-called mCommerce platform providing billing of the ticket purchase and also paying out any prizes that may occur (3) . The platform registers the means of payment, and in collaboration with the bank, verifies certain data such as the age of the player, the PIN code and the player's solvency. If the verification is positive, the player's account is debited for ticket purchase, and then a request for a drawing is transmitted to the game server.

The server then executes the drawing according to the present invention. If the drawing gives a prize, a message is sent to the mCommerce platform, instructing it to transfer the winning amount to the player's account. Thereafter, a short message is transmitted to the player's terminal containing information regarding the result of the drawing (win/loss, winning amount and verification code if a winning occur etc.), possibly together with other relevant information concerning the lottery.

One of the advantages of the present invention is that it eliminates the need for generating, storing and/or distributing lists of winning tickets before the lottery is started, which considerably reduces the risk for unauthorized access and abuse of the lottery. The reason for this is the serial execution of ticket purchases, which in turn is made possible because all the terminals from which lottery tickets are ordered communicates with the same ticket-issuing central, and the ticket-issuing central generates a ticket and calculates a winning amount (if any) at the moment a ticket request is executed. Whether a win occurs for a certain ticket request is dependent on which number in the sequence of incoming requests that the request arrives to the server.

Another advantage of the present invention is that the winning occurrences are spaced out in time throughout the lottery, for thereby preventing a cluster of winning occurrences early in the lottery, before the lottery organizer can afford the pay out of the prizes.

The last-mentioned advantage also reduces the need for the organizer to provide security for the winning amounts prior to start-up. In the example embodiment discussed above, the lottery organizer is always guaranteed having earned the winning amount at the time of pay-out, because the winning amount and winning frequency are balanced. The system of the winning lines in figure 3 is so constructed that each ticket purchase contributes to the winning pot with a certain share of the ticket price to each of the winning lines. This can be illustrated by an example: In a lottery having two winning lines, 1 NOK for each sold lottery ticket is placed in the winning pot of winning line 1, and 3 NOK is placed in the winning pot of line 2. The winning frequency of winning line 1 has a winning occurrence for each 10th lot, while winning line 2 has a winning occurrence for each 100th lot. Then, the winning pot of line 1 will at the time of pay out always have accumulated 10 NOK, and the winning pot of line 2 will at the time of pay out have accumulated 300 NOK. These amounts will be covered by a ticket price of minimum 4 NOK. Alternatively, the winning lines may be shifted in proportion to each other (e.g. by initially setting the counter for line 1 to 5 and the counter of line 2 to zero) , to avoid concurrent winnings at each 100th issued ticket and fewer numbers of pay-outs .

The above description has only included examples of the present invention, and must not be considered as limiting. A variety of other modifications and utilizations may be used within the scope of the invention as defined by the independent claim in the enclosed set of claims.

Claims

P a t e n t c l a i m s

1. A method of drawing lots and calculating a possible winning amount in an electronic lottery in a server wherein drawings are initiated by requests received by the server, c h a r a c t e r i z e d i n

I. incrementing a number of counters stored in a storage device in the server on response to a request received by the server,

II. comparing said counters with respective winning numbers stored in said storage device,

III. if at least one of said counters is equal to its/their respective winning number (s), executing the following steps:

a. summing the winning amount (s) associated with the counter (s) being equal to its/their respective winning numbers, where each winning amount is defined by its respective winning number multiplied by a constant stored in said storage device associated with the respective counter,

b. resetting the counter (s) being equal to its/their respective winning number (s) to an initial value, and/or increasing the respective winning number (s) to a value larger than its/their respective counter (s) so that for each counter, a numerical distance to its winning number corresponding to a winning frequency for this counter is created,

IV. determining that the request gives a winning when at least one of the counters in step II was equal to its/their respective winning number and/or that the sum of the winning amounts calculated in step III. a is larger than zero; the winning, if any, is equal to the sum of the winning amounts calculated in step III. a.

2. A method according to claim 1, c h a r a c t e r i z e d i n that step III after sub step b further includes the following step:

c. for each of a number of the counter (s) being equal to its/their respective winning number, generating a new random winning number selected from a predefined set of numbers.

3. Method according to any of the preceding claims, c h a r a c t e r i z e d i n that said requests are queued and executed by said server in the same order that they arrive the server.

4. Method according to any of the preceding claims, c h a r a c t e r i z e d i n that said initial value is zero .

5. Method according to any of the preceding claims, c h a r a c t e r i z e d i n that the value of said counters and winning number are consecutively stored in said storage device and are used for subsequent requests.

6. Method according to any of the preceding claims, c h a r a c t e r i z e d i n that said request is originated from a user by a terminal through a telecommunication network able to communicate with said server.

7. Method according to claim 6, c h a r a c t e r i z e d i n that if the request does not result in a prize, a message is returned to said user informing that no prize is obtained.

8. Method according to claim 6, c h a r a c t e r i z e d i n that if the request results in a prize, a message is returned to said user informing that a prize equal to the sum of the winning amounts calculated in step III. a is obtained.

9. Method according to one of the claims 6 - 8, c h a r a c t e r i z e d i n that said user is invoiced for the drawing by debiting an account of said user.

10. Method according to one of the claims 8 or 9, c h a r a c t e r i z e d i n that said prize is transferred to an account of said user.