BETTING SYSTEM

Abstract

A pool betting system is disclosed, which allows betting to take place before an event, as in a traditional pool, and also provides for a secondary market in bets during the event. For example, players may bet on the highest scoring batsman in a game of cricket. Bets are placed and the pool is closed before play begins, but during the game players can change their position by buying and selling bets from other players. This allows in-play participation without adversely affecting the interests of non-participating players.

Claims

1. A pool betting system comprising at least one user terminal for allowing placement of bets, at least one display device for displaying information about bets, and a system control server configured to communicate with the or each user terminal and the or each display device, the system control server including an event control input and being adapted to: initialize an event pool including a plurality of possible event outcomes, an event starting criterion and an event ending criterion; monitor the event control input to determine whether the event starting criterion and the event ending criterion has been met; while the event starting criterion has not been met: accept and record bets from user terminals, each bet including information identifying the user, an amount, and a chosen outcome selected from the plurality of possible outcomes; maintain totals of the amount bet against each possible event outcome; transmit the totals of the amount bet against each possible event outcome to the display device(s); and while the event starting criterion has been met and the event ending criterion has not been met: accept bids to buy bets from user terminals, each bid including information identifying the user, an amount, a chosen outcome selected from the plurality of possible outcomes, and a bid price; accept offers to sell bets from user terminals, each offer including information identifying the user, an amount, a chosen outcome selected from the plurality of possible outcomes, and an offer price; maintain records of pending bids and offers; match offers and bids, and execute transfers of bets to fulfil matched bids and offers by updating the record of bets to transfer ownership of bets from the offering user to the bidding user; transmit the bid/offer price and amount of at least some pending bids and offers to the display device(s).

2. A pool betting system as claimed in claim 1, in which the user terminal(s), display device(s) and server communicate with each other over a packet switched network.

3. A pool betting system as claimed in claim 1, in which at least one display device is a projector.

4. A pool betting system as claimed in claim 1, in which at least one user terminal includes a payment acceptance device.

5. A pool betting system as claimed in claim 4, in which the payment acceptance device is a bill acceptor and/or a coin acceptor.

6. A pool betting system as claimed in claim 4, in which the payment acceptance device is a card reader.

7. A pool betting system as claimed in claim 6, in which the card reader is an NFC (near field communication) card reader.

8. A pool betting system as claimed in claim 1, in which at least one user terminal includes a payment dispensing device.

9. A pool betting system as claimed in claim 8, in which the payment dispensing device is a bill dispenser and/or a coin dispenser.

10. A pool betting system as claimed in claim 8, in which the payment dispensing device is a card reader.

11. A pool betting system as claimed in claim 10, in which the card reader is an NFC (near field communication) card reader.

12. A pool betting system as claimed in claim 1, in which at least one user terminal is a mobile telephone.

13. A pool betting system as claimed in claim 1, in which the server is further adapted to maintain a record of the highest-price pending bid, the lowest-price pending offer, the aggregate amount of all pending offers at the price of the lowest-price pending offer, and the aggregate amount of all pending bids at the price of the highest-price pending bid.

14. A pool betting system as claimed in claim 1, in which a bid/offer matching process is executed each time a bid is accepted from a user terminal, the matching process comprising the steps of: a. comparing the accepted bid to pending offers, and determining whether the accepted bid price is greater than or equal to the lowest-price pending offer; b. if the accepted bid price is greater than or equal to the lowest-price pending offer, then executing a transfer at the price of the lowest-price pending offer; c. otherwise, recording the accepted bid as a pending bid.

15. A pool betting system as claimed in claim 14, in which the process of matching bids/offers, when the accepted bid price is greater than or equal to the lowest-price pending offer, further comprises the steps of: a. comparing the amount of the accepted bid with the total aggregate amount of pending offers at the price of the lowest-price pending offer; b. if the total aggregate amount is greater than or equal to the amount of the accepted bid, executing a transfer at the price of the lowest-price pending offer and the amount of the accepted bid; c. otherwise, executing a transfer at the price of the lowest-price pending offer and the amount of the total aggregate amount of pending offers at the price of the lowest-price pending offer, reducing the amount of the accepted bid by the amount of the transaction, and repeating the matching process treating the reduced-amount bid as a new accepted bid.

16. A pool betting system as claimed in claim 15, in which executing a transaction at a transaction price and a transaction amount comprises the steps of: a. updating the record of bets to transfer ownership of bets from one or more originators of pending offers to the originating user of the accepted bid; b. updating the record of pending offers to reduce the amount of or remove altogether the executed pending offer(s); c. initiating a payment from the originating user of the accepted bid to the originating user(s) of the executed pending offer(s).

17. A pool betting system as claimed in claim 1, in which a bid/offer matching process is executed each time an offer is accepted from a user terminal, the matching process comprising the steps of: a. comparing the accepted offer to pending bids, and determining whether the accepted offer price is less than or equal to the highest-price pending bid; b. if the accepted offer price is less than or equal to the highest-price pending bid, then executing a transfer at the price of the highest-price pending bid; c. otherwise, recording the accepted offer as a pending offer.

18. A pool betting system as claimed in claim 17, in which the process of matching bids/offers, when the accepted offer price is less than or equal to the highest-price pending bid, further comprises the steps of: a. comparing the amount of the accepted offer with the total aggregate amount of pending bids at the price of the highest-price pending bid; b. if the total aggregate amount is greater than or equal to the amount of the accepted offer, executing a transfer at the price of the highest-price pending bid and the amount of the accepted offer; c. otherwise, executing a transfer at the price of the highest-price pending bid and the amount of the total aggregate amount of pending bids at the price of the highest-price pending bid, reducing the amount of the accepted offer by the amount of the transaction, and repeating the matching process treating the reduced-amount offer as a new accepted offer.

19. A pool betting system as claimed in claim 18, in which executing a transaction at a transaction price and a transaction amount comprises the steps of: a. updating the record of bets to transfer ownership of bets from the originating user of the accepted offer to the originating user(s) of one or more pending bids; b. updating the record of pending bids to reduce the amount of or remove altogether the executed pending bid(s); c. initiating a payment from the originating user(s) of the executed bids to the originating user of the accepted offer.

Description

DESCRIPTION OF THE DRAWINGS

[0071] For a better understanding of the present invention, and to show more clearly how it may be carried into effect, preferred embodiments will now be described with reference to the accompanying drawings, in which:

[0072] FIG. 1 shows a schematic of a system according to the invention,

[0073] FIG. 2 shows an example of information displayed on the display device in an embodiment of the system of the invention;

[0074] FIG. 3 is a flowchart illustrating the matching process for received bids;

[0075] FIG. 4 is a flowchart illustrating the matching process for received offers; and

[0076] FIG. 5 is a schematic of a database structure suitable for storing active bids and active offers.

DESCRIPTION OF A PREFERRED EMBODIMENT

[0077] Referring firstly to FIG. 1, a general schematic of a system according to the invention is shown. The system includes user terminals 1, 2, which in this example are shown in the form of a desktop PC 1 and a mobile telephone 2. Other types of user terminals, for example special-purpose public access kiosks, may also be provided. The user terminals 1, 2 communicate with system control server 3. Arrows A and B show the flow of information in the form of bets placed before the event begins, and of bids and offers made during the event, from the user terminals 1, 2 to the system control server 3. It is understood that communications may in fact be bi-directional, not least to acknowledge messages received by the system control server 3. Arrow C shows the flow of information from the system control server 3 to the display device 4, which in this case is a projector. A projector or other large-format display is preferred, for displaying information in, for example, a sports stadium.

[0078] With reference to FIG. 2, an example display on a large-format display screen forming part of the betting system of the invention is indicated at 10. At the top of the display, a description 12 of the pool is displayed. In this example, the event is a game of cricket and the pool is for the top two run scorers in proportion of runs scored. The outcomes which are available for betting are therefore names of batsmen on both teams.

[0079] A list of outcomes (in this case names of batsmen) is displayed at a position 14 just below the pool description 12. Before the event (game of cricket) begins, players can place bets on their preferred batsman or batsmen, and their stake will be added to the pool. The amount bet against each individual outcome is displayed alongside the list of outcomes, indicated at 14b in the Figure.

[0080] The total pool size (i.e. the aggregate of all stakes paid in) is also displayed, indicated at 16. Before the event, as players place their stakes on preferred outcomes, the amounts bet against each outcome and the total pool size will be continually updated. When the event begins, these figures are ‘frozen’ since no further bets can be placed. At the conclusion of the event when the outcome is known, the total pool (in the example $10000) will be divided amongst winning players in proportion to the number of runs scored by the top two players. For example, if the top run scorers are Batsman A and Batsman C, scoring 20 and 15 runs respectively, then $5714 will be divided among the players who bet on Batsman A, and $4286 will be divided among the players who bet on Batsman C. It will be noted that in the case of Batsman A, who was always expected to perform well and attracted a large number of bets, the payout is only a little more than the stake originally placed. In the case of Batsman C, who was not thought to be a likely top-run-scorer, the payout is around 8.5 times the stake.

[0081] The operation of the pool before the event begins and after the event ends is in all material respects the same as a conventional pool betting system. Indeed, a player can choose to place a bet before the game begins, not participate in the ‘in play’ market, and therefore use the system in a conventional way. Such a player will not be prejudiced by the operation of the ‘in game’ market, and in fact may benefit from a lower ‘take’ removed from his winnings by the bookmaker, since the bookmaker has an alternative source of income in running the ‘in play’ market and can therefore charge a more competitive basic fee.

[0082] In the lower part of the example display screen in FIG. 2, information about the operation of the ‘in play’ market is displayed. In particular, the three best (i.e. highest price) pending bids 18a and the three best (i.e. lowest price) pending offers 18b are listed. The price is listed in terms of a multiplier of the original stake 20a, 20b, and the size of the bid/offer (i.e. the size of the stake of the original bet which is offered for transfer) is also displayed at 22a, 22b. In this example, it appears that players are of the opinion that batsmen B, C and D are performing badly, or at least are unlikely to be in the top two run scorers, since the best price bid for bets against those players is less than the original stake. On the other hand, players are prepared to pay 1.1 or 1.2 times the original stake for bets on batsman A.

[0083] FIG. 3 is a flow chart illustrating the matching process for accepted bids in detail. At step (a), an Input Bid (IB) is received/accepted into the server. The bid will specify an outcome (in this case batsman B), a bid price and a bid size/amount. At step (b) a comparison is carried out between the Input Bid price and the Best Active Offer Price (BAOP). The BAOP is the price of the lowest-priced pending offer. If the IB price is at least as much as the BAOP, then the process proceeds to step (d). Otherwise, step (c) is the next step.

[0084] In step (c) (when the IB price is less than the BAOP), the IB is recorded in the database as an active/pending bid. The Aggregate Active Bid Size (AABS) is also updated to take account of the new active/pending bid. The process then proceeds to the final step (f).

[0085] In step (d) (when the IB price is at least the BAOP), a comparison is carried out between the Aggregate Active Offer Size (AAOS) at the BAOP. If the AAOS at BAOP is at least the IB size, then the process proceeds to step (e). Otherwise, the next step is step (g).

[0086] In step (e) (when the AAOS at BAOP is at least the IB size), a transfer is executed. The transfer is from the Best Active Offer originator(s) to the IB originator. The transfer is executed at price BAOP and at the size specified in the Input Bid. The list of active/pending offers in the database is updated to remove the offer (or update the amount if only part of the offer has been exhausted) which has been matched and executed. The AAOS is also updated and the process then proceeds to step (f).

[0087] In step (g) (when the AAOS at BAOP is less than the IB size), a transfer is executed at BAOP, but the size/amount of bets transferred is smaller—the size is determined by AAOS at BAOP. All active/pending offers at BAOP are exhausted by transferring the bets/interests from the BAOP originator(s) to the originator of the IB. The database of active/pending offers is updated to remove the exhausted offers. The IB has now been partially executed, in that a transaction has taken place at less than the IB size. A new bid is then generated, at a size equal to the original IB size less the size executed, and this new bid is passed back into the system at step (a), the recursive process iterating and treating the new bid as the IB.

[0088] Step (f) is the final stage of the process. The process will always reach step (f), possibly after several recursions and either via step (c) or step (e). In step (f) the display is updated to show the currently pending bids and offers in the system.

[0089] Note that the words ‘pending’ and ‘active’ are used interchangeably to mean bids or offers which have been submitted but not yet matched and executed. ‘Interest’ and ‘bet’ are words used to describe the ‘betting ticket’ which a player has bought at the start of the game, and which can be bought and sold on the secondary market. The ‘size’ or ‘amount’ of a bet is the size of the stake originally paid, and the ‘price’ is the price of the transfer on the secondary market, which can be conveniently expressed as a multiplier of the original stake. When a bid or offer is ‘received’ or ‘accepted’ it means that a bid or offer is validly received by the server and entered into the matching process.

[0090] FIG. 4 is a flow chart showing an equivalent process for a received/accepted Input Offer (IO), which is received by the server in step (a). The Input Offer relates to a particular outcome (in this example Batsman A) and has a price and a size. In step (b) the IO price is compared with the Best (i.e. highest) Active Bid Price (BABP). If the IO price is less than or equal to the BABP, then the process proceeds to step (d). If the IO price is greater than the BABP, then step (c) is the next step.

[0091] In step (c) (when the IO price is greater than the BABP), no transaction can be immediately executed, and so the IO is added to the list of pending offers in the database and the Aggregate Active Offer Size (AAOS) is updated to reflect the IO price. The process then proceeds to the final step (f).

[0092] In step (d) (when the IO price is at least as low as the BABP), a comparison is made between the Aggregate Active Bid Size (AABS) at BABP, and the IO size. If the AABS at BABP is at least as much as the IO size, then the IO can be executed in full in step (e) of the process. Otherwise, the IO is executed in part at step (g).

[0093] In step (e), a transfer is executed to exhaust the IO in full. The transfer is at price BABP, the size is the IO size, and the transfer is from the originator(s) of the Best Active Bids to the IO originator. The database of active bids is updated to remove or reduce the partially and fully executed and exhausted active bids, and the record of the AABS is also updated. The process then proceeds to final step (f).

[0094] In step (g), a transfer is executed to partially exhaust the IO. The price of the transfer is BABP and the size is AABS. The database is updated to remove or reduce the partially and fully executed and exhausted active bids, and the record of the AABS is also updated. A new offer is then generated which is the same as the IO, but with the size reduced by the size of the executed transfer. The new offer is fed back into step (a) of the process where it is treated as an Input Offer.

[0095] The process may recurse several times, but will always eventually reach either step (c) or step (e), and will then reach final step (f). In step (f) the display is updated to reflect the up-to-date values in the database.

[0096] FIG. 5 illustrates a data structure which is ideal for recording pending bids and offers. In this case, a structure for pending bids is shown, but the features of an analogous structure for pending offers will easily be appreciated.

[0097] All of the bids at a particular price are stored in a linked list. The linked list at each price is in the order in which the bids were originally received. Therefore the bid at the head of the list is the bid at that particular price which has been in the system for the longest time. Any new bids will be appended to the tail of the list, assuming that the new bid is at the same price of at least one existing bid in the system. If the new bid is at a new (distinct) price, a new linked list will be created. A record of each distinct price includes a pointer to the head of the list at that price, and a pointer to the best (i.e. highest) bid price is maintained at all times.

[0098] This structure is an efficient way of storing the bids, since the operations required in the running of the system are adding a new bid, which is simply appended to the tail of the appropriate list, finding the best active offer price, which simply involves following the BAOP pointer, and finding the earliest bid at a particular price, which is simply a case of following the pointer from the required price to the head of the list.

[0099] The betting system provides for a new concept in the field of pool betting, allowing participation in pool betting ‘in play’ for the first time.