WO2018132869A1

WO2018132869A1 - Systems and methods for structured randomised betting on golf

Info

Publication number: WO2018132869A1
Application number: PCT/AU2018/050027
Authority: WO
Inventors: David Dicesare; Craig Roberts
Original assignee: Cold Tap Pty Ltd
Priority date: 2017-01-17
Filing date: 2018-01-17
Publication date: 2018-07-26

Abstract

The present invention is directed to systems and methods for enabling structured randomised betting on a golf event by a plurality of bettors. The system of the invention is able to be implemented by a server comprising a bet processor/controller, a bet validator, a database, and a plurality bettor interfaces, the bet processor/controller and bet validator operatively interacting with the bettor interfaces to execute steps in conjunction with the database. The steps executed by the system, or in the method, provide for a structured randomised distribution of players to be assigned to electronic tickets and for the electronic tickets to be allocated to bettors. The invention particularly provides means for validating a betting action using a bet validator, and bettor data packets which are encoded or updated in response to betting actions.

Description

SYSTEMS AND METHODS FOR STRUCTURED RANDOMISED BETTING ON GOLF

FIELD OF INVENTION

The present invention relates to the field of betting technologies, and more particularly electronic betting transactions for betting on golf events.

BACKGROUND OF THE INVENTION

Betting on golf is often considered to be challenging. This can be understood in light of the many complicating factors which can influence the result of golf events, for example: the field of golf players may be very large (e.g. 150 or more players); numerous strokes, and what may be considered a comfortable lead, can be lost by a player in a matter of minutes; the length of golf events (e.g. tournaments can span up to four days); knowledge of whether some players are "in form" or have personal experience with the golf course hosting the golf event.

U nlike other sporting events such as tennis or football, where successful individuals or individual teams that exhibit consistency in their play may be considered to be relatively "safe" bets, the winners of golf tournaments are commonly outside the better ranked players (i.e. outside those players ranked 1-10). For example, the Official World Golf Ranking ('OGWR') of players winning PGA tour events in the 2015-2016 season ranged from 607 to 1; across these 42 PGA tournaments only 13 events were won by a top 10 player (pre-tournament ranking) and the average winner's rank was approximately 112. Another factor particularly affecting betting on golf compared with most other sports (e.g. tennis and football), is that other sports are generally played on the same size, or broadly the same size, playing surface (e.g. a tennis court or football pitch/field). Furthermore, as there are usually many players in any golf event, in golf it is possible for the

smallest margin (i.e. one stroke) to separate all players in a golf event (e.g. all the second to last placing players may finish just one stroke behind a winning player).

Consequently, it can be problematic for bookmakers or betting agencies to construct bet types and develop products to encourage bettors to participate in betting due to the perceived complexities in making bets on golf events. While fixed odds for a player winning a golf event may be correlated to that player's international ranking, such odds may not sufficiently take into account that player's recent history or experience with and knowledge of the course hosting the golf event. Bet types which permit flexible betting choices such as those commonly used in betting on horse racing (e.g. a quinella or boxed trifecta) may decrease a bettor's exposure to variable results, however, such bets types generally focus on the 'top place-getters', and this is less suitable for golf events where there is generally little interest in (and in many cases no individual) second or third placing players.

Additionally, from a practical perspective, if a system or method is to provide a useful solution to the aforementioned issues of complexity and variability in betting on golf, it should operate in a secure and effective manner. In particular, it is considered important for data processed by a system or method to be structured in a way which preserves the integrity and security of the betting solution adopted.

Existing arrangements of the types described above are not entirely satisfactory, and there is accordingly a need to address these and other limitations of the state of the art, or at least provide a useful alternative. SUMMARY OF THE INVENTION

The present invention in its various aspects arises from recognition that a betting system or method can be organised to assign players to bettors in a randomised fashion to facilitate electronic betting transactions on golf, and more particularly a structured random distribution of players using defined payer groups can promote bettor engagement and interest in betting on golf. Such facilitation of electronic betting selections relies upon offering tickets that can assist with, amongst other things, mitigating a bettor's perceived difficulty with betting on a golf event.

Such a system can also be organised to permit a degree of flexibility in betting such that bettors may be allocated a structured random distribution of players as well as players which have been specifically selected by the bettor. Player swaps as between bettors may also be permitted by the system, as well as a range of other betting actions chosen by the bettor. Furthermore, the system the subject of the present invention provides for regulated processing of betting actions by using data structures which permit secure and efficient processing of betting actions. The system enhances a bettor's real-time engagement with a golf event, and engagement with other bettors using the system, to improve the bettor experience and make the prospect of betting more attractive. The present invention in a first aspect provides a system for enabling structured randomised betting on a golf event by a plurality of bettors, including:

a server accessible by bettor devices via an electronic communications network, the server comprising:

a bet processor/controller,

a database,

and a plurality bettor interfaces,

the bet processor/controller operatively interacting with the bettor interfaces to execute steps in conjunction with the database,

the server configured to execute the steps of:

receiving and recording on the database input from the plurality of bettor interfaces that the plurality of bettors want to bet on the golf event;

receiving data from the database including a plurality of ranked players

participating in the golf event and the number of tickets to be generated;

distributing a plurality of ranked players into groups;

randomly assigning players from a plurality of the groups to the tickets on a group- by-group basis;

wherein the players are uniquely assigned such that no one player is able to be assigned to more than one ticket;

allocating at least one ticket to each of the plurality of bettors;

transmitting to each of the plurality of bettor interfaces the ticket(s) assigned to each bettor;

receiving data that designates the winning player(s) of the golf event;

communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s).

The present invention in a second aspect provides a system for enabling structured randomised betting on a golf event by a plurality of bettors, comprising:

a bet processor/controller,

a database,

and a plurality bettor interfaces, the bet processor/controller operatively interacting with the bettor interfaces to execute steps in conjunction with the database,

the server configured to execute the steps of:

receiving data from the database including a plurality of ranked players

participating in the golf event;

forming a plurality of player lists, each player list including the plurality of ranked players;

the server is further configured to separately operate on each player list as follows: receiving and recording on the database input from the plurality of bettor interfaces that the plurality of bettors want to bet on the golf event;

receiving the number of tickets to be generated per player list; distributing a plurality of ranked players into groups;

randomly assigning players from a plurality of the groups to the tickets on a group-by-group basis;

allocating at least one of the tickets to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event;

In a third aspect of the present invention, there is provided a system for enabling structured randomised betting on a golf event by a plurality of bettors, including:

a bet processor/controller,

a bet validator,

a database,

and a plurality bettor interfaces,

the bet processor/controller and bet validator operatively interacting with the bettor interfaces to execute steps in conjunction with the database, the server configured to execute the steps of:

receiving data from the database including a plurality of ranked players participating in the golf event and the number of tickets to be generated;

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

transmitting to each of the plurality of bettor interfaces the ticket(s) allocated to each bettor;

receiving data that designates the winning player(s) of the golf event;

communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s);

wherein the server is further configured to execute the steps of:

engaging the bet validator to cause a bettor data packet to be encoded or updated in response to each proposed betting action communicated to the bet validator via the bettor interface;

validating the betting action; and

communicating to a bettor via that bettor's bettor interface whether the betting action is validated by the bet validator.

In a fourth aspect of the present invention, there is provided a method of enabling structured randomised betting on a golf event by a plurality of bettors, the method including the steps of:

receiving and recording on a database input from a plurality of bettor interfaces that the plurality of bettors want to bet on the golf event;

receiving data from the database including a plurality of ranked players

participating in the golf event and a number of tickets to be generated;

distributing a plurality of ranked players into groups; randomly assigning players from a plurality of the groups to the tickets on a group- by-group basis;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event;

In a fifth aspect of the present invention, there is provided a method of enabling structured randomised betting on a golf event by a plurality of bettors, the method including the steps of:

receiving data from the database including a plurality of ranked players

participating in the golf event and a number of tickets to be generated;

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event;

wherein the method further includes the steps of:

engaging the bet validator to cause a bettor data packet to be encoded or updated in response to each proposed betting action communicated to the bet validator via the bettor interface; validating the betting action; and

In a sixth aspect of the present invention, there is provided a non-transitory computer- readable storage medium comprising instructions that, responsive to execution by a computer, cause the computer to implement a method or system of structured randomised betting on a golf event by a plurality of bettors, including carrying out the steps of:

receiving data from the database including a plurality of ranked players participating in the golf event and a number of tickets to be generated;

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event;

In a seventh aspect of the present invention, there is provided a non-transitory computer- readable storage medium comprising instructions that, responsive to execution by a computer, cause the computer to implement a method or system of structured randomised betting on a golf event by a plurality of bettors, including carrying out the steps of:

receiving data from the database including a plurality of ranked players participating in the golf event and a number of tickets to be generated; distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event;

wherein the instructions further cause the computer to implement a method or system including the further steps of:

validating the betting action; and

The following description of preferments is relevant to each of the abovementioned aspects of the present invention.

Preferably, each group contains the same number of ranked players; however, it may be that a dynamic group size for some groups is used in order to manage player selections by bettors yet retain the random structured distribution of unselected players (see below under the heading 'Player Selections' and corresponding description in the implementation of the invention). Preferably, the number of players in each non-dynamic group (from any one player list) is equal to the number of tickets to be generated (from that one list). In the following text, references to a group should be understood as referring to a non-dynamic group unless the context indicates otherwise.

Preferably, each ticket is randomly assigned one player from each and every group such that each of the tickets is randomly assigned a number of players equal to the number of the plurality of groups. Alternatively, some of the tickets may be randomly assigned one player from each and every group and some other tickets may be randomly assigned one player from one or more groups (but not from each group) and also be assigned one or more players via non-random means, such as via bettor selection of players. The process of bettor selection of players will be described in more detail below, and in particular under the heading 'Player Selections'.

It is preferred that the server is configured to only generate the number of tickets corresponding to the number of bettors so as to maximise the nu mber of players allocated to each bettor; However, in alternative configurations of the system, for example, some tickets may be generated but remain unallocated to any bettor, some bettors may be allocated more than one ticket, or a less than complete batch of tickets may be generated (e.g. just one ticket) in a manner which preserves the intention of the structured

randomised distribution of the current invention.

Preferably, each of the tickets is assigned the same total number of players. In other preferred arrangements, some tickets may be assigned more players than other bettors; this is particularly preferred where the system is configured to allocate to bettors players in the golf event that are not distributed to one of the groups.

Preferably, the player groups are configured such that each group contains n consecutively ranked players, and the first group contains players ranked 1 to n, the second group contains the players ranked n+1 to 2*n, the third group contains the players ranked 2*n + 1 to 3*/i, and so on such that the m ^h group contains the players ranked [n*(m-l) + 1] to m*n. The ranking of a player for the purposes of assigning to a bettor may, but need not correspond to a player's OWR or other publicly known ranking metric, the ranking could also be correlated to fixed odds for a player winning the tournament provided by independent betting agencies; the ranking may be understood as an 'effective ranking' which simply operates to establish a ranking based order of the players. This 'effective ranking' will apply where, for example, not all top ranked players are participating in the golf event. The ranking may also not be fixed (i.e. it may be dynamic) such that the ranking of players may evolve during the process of player assignment to tickets; this is particularly preferred in the context of handling player selections (see below) in order to preserve a structured randomised distribution of unselected players across the tickets.

Preferably, the system is configured to assign to a batch of tickets all players participating in the golf event. A complete set of tickets generated by the system (i.e. containing all participating players to be assigned across all tickets) is herein referred to as a batch of tickets. In alternative configurations, the system of the invention may operate to assign to the batch of tickets only a subset of the participating of players (e.g. those players remaining after the 'cut'). Preferably, the number of assignable participating players, or the number of players in a subset, is able to be evenly divided by the number of tickets to be generated by the system. The number of tickets to be generated may be a pre-determined number determined by the operator of the subject betting system, or it may vary depending on the number of bettors which decide to enter into betting on the golf event; an upper and/or lower bound of the total number of tickets may be set to promote the operation of the betting system in a manner consistent with the objectives of the invention. The preferred methods of setting of this and other parameters of the system are described in more detail later in the specification.

Preferably, each player in the golf event is assigned to at least one ticket. Alternatively, some players participating in the golf event may be not be assigned to any ticket. This latter scenario may arise when, for example, there is imperfect divisibility of the total number of participating players by the number of players in each group and the remainder players are not assigned to the batch of tickets.

Where the number of participating players, or the number of players in a subset of such players, is not evenly divided by number of tickets to be generated, the highest ranked remainder players may be removed from the list of players to be assigned. Preferably, the groups are populated by the lowest ranked players first (e.g. ranked 1 to, say, 154), so that the remainder players are those players having the highest ranking (e.g. ranked 155 and 156, where there is a total of 156 players participating in the golf event).

Alternatively, where the number of bettors n, does not evenly divide the total number of assignable players, the group with the highest ranked players is supplemented by the m remainder players (itself consisting of players ranked higher than those in said group) so as to form a supplemented group of highest ranked players containing n+m players, the players in said supplemented group being able to be randomly assigned to the tickets. According to a further preferred configuration of the system, the remainder players are randomly assigned to the tickets. It is further preferred that not more than one of the remainder players are assigned to any one ticket. Alternatively, more than one of remainder players may be assigned to one ticket where it is desirable for all players to be assigned.

Further preferred mechanisms for handling remainder players, and implementation details, are described later in the specification.

Where there are a plurality of player lists which number more than the remainder players, the server is able to be configured such that each and every player in the golf event is assigned to at least one bettor across all ticket batches generated cross all players lists in accordance with the method of the second aspect of the invention as described above. Preferably, the server is configured to execute the step of transmitting the tickets allocated to each bettor by issuing an electronic ticket to each bettor's bettor interface.

The server is preferably configured to execute the step of shuffling the players which are assigned to each ticket, such that observable effects of ordering of the players by ranking during operation of the method are further hidden from the bettor. In this arrangement, the shuffling may take place during the process of assigning players to tickets; or alternatively, the shuffling may be executed after players have been assigned to the tickets, and before the server has transmitted the tickets to a bettor interface. Where the server transmits an electronic ticket to each bettor's bettor interface, the electronic ticket preferably includes a shuffled list of assigned players having little visually apparent ranking based order.

The server is further configured further to execute the steps of:

transmitting to the one or more bettor interface(s) an option for one or more bettor(s) to select one or more player(s);

receiving and recording the one or more player(s) selected by the one or more bettor(s);

assigning the selected player(s) to a ticket in accordance with the selections made by the one or more bettor(s);

assigning the remaining unselected players in accordance with the structured randomised distribution of the subject invention.

The server may be configured to execute steps of:

transmitting to one or more bettor interface(s) a plurality of selectable tickets, each selectable ticket including players which are assigned in accordance with the structured randomised method of the subject invention;

receiving from one or more bettor(s) a selection of the one more selectable ticket(s);

transmitting to the corresponding one or more bettor interface(s) the selected ticket(s).

Preferred mechanisms to enable the selection of players or selectable tickets, and implementation details are described later in the specification.

The server is preferably configured to receive information updates about the progress of the golf event in real-time, for example information regarding, the current leader board (the leader board may consist of a plurality of the current leading players in the golf event). The server is preferably further configured to communicate to the bettor interfaces said information updates in real-time.

Preferably, the bettor interfaces are configured to display the leading players by highlighting or otherwise indicating said leading players on bettor devices in real-time to enable a bettor to distinguish the leading player(s) from the non-leading player(s).

Preferred implementations of the system permit a bettor to swap one or more players on a ticket allocated to them; this swap may be made during the progress of a particular golf event in real-time. A swap of players may comprise, for example: a swap between two bettors of two allocated players; or a swap between two bettors of two tickets. Preferably, the swapping of players preserves aspects of the structured randomised distribution of players amongst bettors: for example, a first bettor may only be able to swap a player with a second bettor if the swapped players belong to the same group of players. Provision of such a mechanism for modifying allocated players increases the attractiveness of betting as it permits a bettor to enjoy a degree of control over the players allocated to them, yet still maintain a relatively even spread of ranked players across any particular ticket batch. The swapping mechanism may be particularly attractive due to the capacity for swaps to be undertaken after the golf event has begun, and where bettors have engaged with the golf event and wish to swap players based on their observed progress of the golf event.

The database preferably includes, inter alia, player details including ranking, received bet data, player selection or swap data (if the system configuration permits), and bettor account details.

The database may further include historical information regarding players, media such as audio/visual recordings of the players, or statistics relating to player performance in past golf events. The server is preferably configured to execute the further step of settling the processed bet, after the golf event has concluded, in the account(s) of the winning bettor(s).

The received bets stored in the database preferably include data fields such as: a bettor ID, an event ID, a player list ID, a bettor selection ID, and a betting amount.

The server may communicate betting summary data to the bettor devices, including indications to confirm and finalise a betting action. A betting action may be an initial bet to enter into betting on the golf event, or it may be subsequent bets in relation to player selections or player/ticket swaps. Bettors may be offered a single initial stake to enter (or buy into) betting on a golf event, or a plurality of initial stakes. Betting may be arranged such that bettors that are distributed players from a first player list have an equal initial buy in of, for example $10, whereas bettors that are distributed players from a second player list have an equal initial buy in of, for example $20. Preferably, all bettors being allocated players from a particular player list, have an equal initial buy in stake. The total staked by an individual bettor may differ from other bettors depending on whether preferred player selections are made, or whether a bettor chooses to swap one or more players or tickets, etc.

A unique web session identification (ID) number may be used in a bettor device web session in response to a betting action. The server uses this unique identifier to read the bettor records contained with its server database and identify the bettor. The bettor record is checked to ensure that he or she is registered in the server, is qualified to place bets on the server and that his or her cash balance representing residual funds remaining from deposits after betting actions and less withdrawals, is equal to or higher than the minimum acceptable bet amount.

The bet amount for a particular betting action is predetermined, and preferably set to ensure that a betting agency managing the betting system receives sufficient commercial benefit from the bet.

The server upon receipt of the confirmed betting action, checks the bettor records again to determine that all of the following conditions are met: the betting stake amount meets the parameters of the betting action; the bettor's web unique session identifier is still linked to the bettor record; and the bettor's account balance is equal to or greater than the minimum stake amount for the bet. The server places the bet if all of these conditions are met. An embodiment of the present invention involves the server recording each bet placed by the bettor including the selection, the stake and related data in an electronic

database against the bettor's unique identifier (ID) in the server. The results from each recorded bet in the server may be stored on the server in electronic database records against the related bettor's unique identifier. The server may display the most relevant and appealing betting statistics for each bettor on a bettor device.

The structured mechanisms implemented to facilitate electronic betting transactions are advantageous for the various parties involved. A structured randomised betting system creates an incentive for bettors to participate in a betting enterprise which has the appeal of eliminating some of the difficult aspects of betting on golf. The system also provides the opportunity for pools of bettors (assigned players from a single list of players) to participate in a betting scenario where each bettor in the pool has a broadly even chance of winning (especially where each ticket has an equal number of players), and/or where at least one of the bettors in the pool will hold a ticket with the player that wins the golf event (where each participating player is assigned to at least one bettor). This may be attractive for pools of bettors to engage in the standardised betting system as they can interact as a group with the golf event as it evolves in real-time knowing that one of them will be the eventual winner and that each of them (for a substantial duration of the golf event at least) has a reasonably even chance of winning. Player or whole ticket swaps between bettors (particularly where it is controlled to preserve the structure in the player distribution) further enhances the opportunity for bettor engagement with the system. The betting system comprising the present invention preferably further permits one or more bettors on a golf event to send messages to one or more other bettors on the same golf event through the bettor interface. This function provides increased connection means between the bettors, and is especially effective when each of the bettors has a reasonably even chance of winning. Bettors who are known to each other and/or linked by a preexisting social network are particularly likely to be interested in such means of

communication due to the ability for bettors to share the real-time experience of betting on the golf event via a single interactive system as the event unfolds.

The server is preferably configured to execute steps enabling bettors that select players to be charged a betting premium over and above the fee applicable to tickets in which all players are allocated in the structured randomised manner set out above and in which no player selections are made; similarly, bettors that choose one selectable ticket of a batch of tickets including players allocated in the structured randomised manner set out above, may be charged a betting premium.

Preferably, the system is configured such that those bettors wanting to select a player or ticket are provided a time based window in order to submit their player selections. When the time-based window closes, for example a number of hours or days before the start of the golf event, the selected players (or all players on a selectable ticket) are not able to be allocated to another bettor (unless by way of a later swap), and the remaining unselected players are assigned to the tickets in accordance with the structured randomised distribution of the invention described above.

The server is preferably configured further to execute steps of adding players selected by a bettor to those players allocated to said bettor in the previously set out structured randomised manner such that the total number of players allocated to said bettor equals the number of players allocated to other bettors not selecting players.

The following description of preferments relates particularly to the third, fifth and seventh aspects of the present invention.

It is preferred that the bettor data packet includes, in relation to the bettor proposi ng the betting action : a bettor ID corresponding to the bettor; and a bettor I D for each of the plurality of bettor.

I n at least one preferred form of the invention, the bettor data packet further includes, in relation to the bettor proposing the betting action, one or more of the following: a web session ID connected to the proposed betting action; the players on the ticket(s) allocated to the bettor; a counter for the number of betting actions the bettor has proposed and/or achieved; a betting amount sta ked by the bettor in the tournament; the number of holes which have been played in the tournament; a flagging device to indicate when a bettor data packet includes unauthorised data.

Preferably, the bettor ID may be linked to a bettor's web session I D, created during the process of registration of a bettor, or separately created by the bet validator) .

Preferably a link is established between the bettor ID of the bettor proposing the betting action which caused the data packet to be encoded, and the bettor IDs of each member of the pool of bettors to which that particular bettor belongs. The pool of bettors preferably consists of the bettors who have collectively been issued a complete set of tickets listing all players in the golf event.

The web session ID may be encoded during registration of the bettor and/or when a bettor logs in.

The counter for the number of betting actions a particular bettor has proposed and/or achieved may count the number of betting actions either before or during the course of a golf event. The betting actions may include ticket swaps, player swaps, a betting stake change in relation to an entire ticket, a betting stake change in relation to a particular player (if allowed), or player selections (only available before the golf event begins);

the number of holes which have been played in the golf event is preferably that number of holes when the bettor data packet is being processed, and the remaining number of holes to be played before the conclusion of the golf event is preferably that number of holes when the bettor data packet is being processed.

The flagging device preferably indicates when a bettor data packet includes any

unauthorised data such as:

where the maximum number of linked bettor IDs has been reached, that number being the number of bettors in the bettor pool of the particular bettor; where a player has been wrongly assigned to a bettor's ticket (i.e. due to incorrect assignment by the be processor/controller resulting, for example, in the ticket having two group 1 players);

where a ticket has been assigned more than the acceptable number of players for any one ticket; or

the bet stake is above or below a designated minimum or maximum amount; where the counter has exceeded the maximum number of betting actions; The bet validator is preferably operated by, or in parallel with, the bet

processor/controller. The bet validator is preferably part of the system engine. The bet validator preferably encodes bettor data packets which contain data related to a particular bettor and/or that bettor's betting actions, during the course of the golf event, or in the lead up to the golf event. The bet validator preferably enables more regulated processing or control of bets, betting arrangements and betting conditions.

Preferably, the bet validator is able to communicate with bettor interfaces. Preferably the bettor data packets are formed or updated each time a bettor seeks to place or modify a bet, or modify betting arrangements and conditions (each action is herein referred to as a "betting action").

Preferably, the bet validator is able to process bettor data packets to validate betting actions and enable more regulated processing or control of betting actions. The bet validator preferably processes bettor data packets to validate one or more of the following: that each bettor data packet corresponding to an individual bettor includes that bettor's bettor ID and/or links that bettor I D to the bettor IDs for each bettor in the pool of bettors to which that bettor belongs (without linking to any other bettor IDs for bettors outside of the pool);

the number of betting actions proposed by a bettor is not more than a designated number which is set by an operator of the system; or

whether any proposed betting action meets the requirements for structured

randomised betting set by the system (e.g. a change in the betting stake of one bettor, or a change the betting stakes of a plurality of bettors; single or multiple player swaps).

The requirements for structured randomised betting include preserving a relatively equal distribution of ranked players amongst the tickets so that each ticket has a reasonably equal likelihood of having the winning player.

Preferably, the bettor data packets are recorded on the database and accessible by the bet validator.

Preferably, the bet validator acts to regulate betting actions and communication with bettor interfaces.

I n a preferred form, the bet validator operates in parallel with the bet processor/controller. Alternatively, the bet validator is combined with the bet processor/controller to form bet processor/controller/validator (a "BPCV") a so that each of the processes undertaken by the validator described herein is undertaken by the BPCV.

Where the bet validator operates in parallel with the bet processor/controller, the usual bet processing tasks such as determining the number of players per group, distributing players into groups and assigning players to tickets, a re undertaken by the bet

processor/controller; and the bet validator processes the bettor data packets, validates the actions of the bettors and ensuring this meets the requirements of the system for enabling structured randomised betting, and performs other operations as described herein. Where the bet validator is combined with the bet processor/controller, the BPCV may process betting related actions including the usual bet processing tasks such as

determining the number of players per group, distributing players into groups and assigning players to tickets, as well as encoding the bettor data packets, validating the actions of the bettors and ensuring this meet the requirements of the system for enabling structured randomised betting.

Preferably, the validation of bettor data packets prevents unauthorised betting actions of bettors, and in particular transmissions of the unauthorised betting actions of one bettor to the bettor interfaces of other bettors.

Preferably, personal data is stripped from the data encoded in the bettor data packets (including the Bettor IDs) processed by the bet processor/controller and/or bet validator. Combinations of the steps referred to above are to be understood as falling within the scope of the disclosure of this specification. BRIEF DESCRIPTION OF THE DRAWINGS

FIG 1 is a schematic diagram of hardware components of a betting system according to a preferred embodiment of the present invention.

FIG 2 is a schematic diagram of an alternative architecture of the betting system depicted in FIG 1.

FIG 3A is a package diagram depicting dependencies between packages of the server model at the logical level.

FIG 3B is a schematic diagram of a generic hardware architecture - at the physical level - that can be generally used to implement hardware components of FIG 1.

FIG 4 is a process flowchart of steps involved in preliminary registration of and access by bettors to the server of FIG 1.

FIG 5 is a first process flowchart of steps involved depicting betting activity of respective components of the server of FIG 1.

FIG 5A is a second process flowchart of steps involved depicting betting activity of respective components of the server of FIG 1.

FIG 5B is a process flowchart of steps involved depicting operation of a bet validator.

FIG 5C is a schematic representation of the data contained in a bettor data packet.

FIG 6 is a simplified schematic of the operation of the ranking, structured random distribution of players into groups and assignment of players to tickets in accordance with a preferred implementation of the invention in a specific golf event scenario, where shuffling of players within a ticket is performed as part of the player assignment process.

FIG 7 is a simplified schematic of the operation of the ranking, structured random distribution of players into groups and assignment of players to tickets, where shuffling of players within a ticket is performed after the process of assigning players to tickets.

FIGS 8 to 11 are collectively a series of schematic representations of bettor interface screens relating to specific scenarios outlined in the description. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Server overview

FIG 1 depicts hardware components - that is, at the physical level - of a server 1 as described herein. The server 1, contains the bet processor, which records and settle bets. As an example, the server 1 may be a server machine running a Microsoft Windows™ operating server, connected to a back office database 2, for example a SQL relational database server.

An alternate configuration is shown in FIG 2, in which the server 1 sends bet

requests and receives acknowledgement and settlement data from the bet

processor which resides on an external server 6 with its own database 7. As an example, database 7 may be hosted by an external betting agency, and is accessed by the server 1 over a secure Internet connection.

The server 1 is connected to the Internet 3. The server is accessed over the I nternet 3 by a plurality of bettor devices 4, for example personal computers, mobile phones, tablets or other wearable mobile devices running web browser software such as Google Chrome™ or Apple Safari™ and using fixed or mobile broadband, wireless hotspots, satellite or dial-up connections through respective Internet Service Providers 5.

Access to the server 1 is restricted by, for example, a firewall and other known network security measures. The server 1 includes a web server, for example the Microsoft I IS™ web server, to serve web page requests. Betting is permitted through betting actions screens for betting actions displayed on a web page.

Server model

A server model of the server 1 is illustrated in connection with the package diagram of FIG 3A, which presents components at the logical level. Bettor packages 100, etc use bettor interface packages 200 which are displayed on a bettor device 4.

The bettor interface packages 200 depend upon the system engine package 300, which includes a bet processor/controller package 310 and a bet validator package 320. The system engine package 300 depends on a data layer package 400, including a data access package 410 and a services agents package 420.

As depicted, each of the three primary packages (namely, the bettor interface package 200, system engine package 300 and data layer package 400) depends upon a service package 500. The service package 500 has a security package 510 and a communications package 520. As will become apparent from the description which follows, the system engine package 300 encodes the business logic which is described in further detail below.

These terms are contracted herein for economy and convenience by omitting reference to 'package'.

Physical hardware - server and bettor devices

As is now described for completeness, embodiments described and depicted herein rely upon various computing platforms used to implement the client-server architecture described particularly in connection with FIG 1, arranged to interoperate via the Internet 3. I mplementation is dependent upon development and deployment of interoperating computer programs able to be executed within respective selected computing platforms and their accompanying operating systems.

FIG 3B depicts an architecture of a computer system 1000 in schematic form,

representative of a generic computing platform suitable for implementing the described system. This architecture abstracts the physical-layer hardware details, which are differently implemented across manifestations of the server 1 and bettor devices 4.

The computer system 1000 includes in its principal components a storage 1020, a memory 1030 and a processor 1040, each of which is interconnected via a system bus 1050. The system bus 1050 is linked to an input/output bus 1060, which interfaces with a display 1070, input 1080, and a network interface controller 1090. The network interface controller 1090 is configured to permit intercommunications with a network external of the computer system 1000.

The storage 1020 provides a non-volatile data storage medium for storing application data and executable code, and is typically flash memory, or other data storage device such as a magnetic hard disk drive. The memory 1030 is a random-access memory used to load executable code and application data from storage 1020.

The processor 1040 executes instructions of a computer program loaded from memory 1030 by performing the basic arithmetic, logical, control and input/output (I/O) operations specified by the instructions. The processor 1040 includes at least a central processing unit, and may be supported by ancillary processing units for performing specialist functions - such as dedicated graphics processing.

The display 1070 provides a visual window to a bettor, who can interact via input 1080. The input 1080 in the example of a personal computer or workstation includes a keyboard and mouse. Alternatively, in the case of a tablet or smartphone the input 1080 includes a touchscreen layered over the display 1070, and responsive to input gestures.

The network interface controller 1090 provides a port for the computer system 1000 to communicate by transmitting data to and receiving data from a network (not shown, though will be the Internet 3), and implements electronic circuitry required to

communicate using a specific physical layer and data link layer standard.

The network interface controller 1090 is configured to interoperate using wired standards such as Ethernet or Token Ring, or wireless standards such as provided by the IEEE 802.11 Wi-Fi standard, or ITU-R 4G cellular standard. This provides a base for a full network protocol stack, which permits large-scale network communications through routable protocols, such as Internet Protocol (IP) over the Internet 3. Connection to the Internet is typically mediated via a firewall server or proxy server.

The client-software architecture implements a particular software design and architecture, distributed amongst both server 1 and bettor devices 4. Processing is conducted cooperatively as required though principally at the server 1, with some minimal processing executed at the bettor devices 4, and local data caching and synchronisation with the server 1.

An application at the bettor device 4 includes, a presentation layer, or bettor interface, an application layer, and a data layer is implemented by computer programs installed and executing are deployed.

Software implemented at the server 1 includes one or more server programs executing by the server 1 within the server operating system. These server programs implement domain logic, which encodes how data can be created, displayed, stored, and changed, as contrasts with the remainder of the software comprising application logic which is primarily concerned with lower-level details of managing a database or displaying the bettor interface, system infrastructure, or generally connecting various parts of the program. Software implemented at the bettor devices 4 vary according to computing platforms, but may be implemented as stand-alone apps (for smartphone or tablets, which tend to rely upon a touchscreen for input) under mobile operating systems or stand-alone applications (for laptops or personal computers) under desktop operating systems. Regardless of the computing platform, dedicated web browsers can be used to implement a web application via scripting executed by the web browser, under both mobile or desktop operating systems.

Selection of suitable channels for delivery of client software, and favoured environments and frameworks for development is informed by technical requirements and developer skill set. Regardless, client software is designed to present a bettor interface and application logic, as described in further detail below.

Bettor registration and access

FIG 4 depicts via a process flowchart the operation of the server 1 described above, as regards to preliminary registration requirements. This process will be broadly familiar in some aspects, and is described for completeness.

The user (i.e. bettor) connects to a site hosted by the server 1 via the Internet 3 (FIG 4, step si) described in connection with FIG 1. If the bettor is already registered then they will proceed to a login screen (FIG 4, step s4) at which they will enter their account username and password, and if authenticated, the bettor can proceed to select a betting action (FIG 4, step s5).

If the bettor is not already registered, he is required to register (FIG 4, step s2) where he provides personal details so as to uniquely identify himself. Details can include typical credentials such as first name, surname, address, phone number, date of birth and email address. When registering, bettors also provide a unique identification code or alias and password, which is used to login in the future. Registered bettors have full access to all account facilities provided by the system.

Background verification can be performed as required (e.g. date of birth, address details), and at a minimum bettor eligibility is performed as regards to age, and address for betting jurisdiction requirements. A bettor account is created (FIG 4 step s3) as part of registering the bettor, should these details supplied be deemed satisfactory, and a unique server identifier accorded the bettor. Following account creation, the bettor is effectively logged in, and proceeds to selecting a betting action (FIG 4, step s5).

Betting server -functional overview

FIG 5 is a flowchart depicting functional steps in broad overview principally tra nsacted at or connected with the server 1, as will become more apparent from the following description and accompanying pseudocode fragments.

The following description relates to the allocation to bettors of a single list of players. It will be appreciated that bettors may be allocated players in multiple list scenarios.

I n FIG 5, each of the bettors 100 (e.g. first bettor 110, second bettor 120) places a bet in step s6 via their respective bettor interface (e.g. 210, 220, ...) on their bettor device 4. The server 1 uses the bettor's unique identifier in their web session details and checks the bettor record of the bettor (e.g. 110, 120) to determine whether they are able to enter the golf event using their bettor interface 200 via step s6. In step s7, the bet

processor/controller 310 receives data from the server 1 in relation to: i) all bettors who have entered the golf event; and ii) the players participating in the golf event. The bet processor/ controller 310 receives bettors until the number of bettors reaches an upper bound number of allocatable tickets. For illustrative purposes (see FIG 6), the upper bound is chosen to be 14.

I n step s7, the bet processor/processor 310 receives the ranked players into groups. The bet processor/controller 310 then processes the players in order of ranking. For illustrative purposes, the number of players in the golf event is 154 (a multiple of the upper bound of allocatable tickets). Players are ranked in accordance with their odds from favourite (ranked 1) to outsider (154). Players could alternatively be ranked by reference to their OGWR.

I n step s8, the bet processor/controller 310 then sets the number of players in each group to be equal to the number of the tickets to be generated for the list of players in the golf event. The number of players per group is therefore determined by the server to be 14, and the number of groups is determined to be 11. The players are then distributed in a consecutive sequence by rank order such that the first group contains the players ranked 1 to 14, the second group contains the players ranked 15 to 28, and so on. Since the total number of ranked players is 154, and this is evenly divided by the number of players per group/tickets (i.e. 154 /14 = 11), there are no remainder players i n this scenario.

I n step s8A, the bet processor/controller 310 optionally permits player selections to be made by the bettors. Where player selections are implemented, this will involve resetting the ranking of players and player groups, and the use of a dynamic ranking and dynamic group structures described in detail below under the heading entitled 'Player Selections'. I n step s9, the bet processor/controller 310 assigns the players in a structured randomised manner wherein one (and only one) player from each group may be randomly assigned to each ticket; this process continues until all 14 tickets have been assigned 11 players (i.e. one player from each of the 11 groups). As part of the assignment process, the bet processor shuffles the players assigned to each ticket such that the players are assigned to the tickets in no particular order, aside from the requirement that the assignments are performed on a group-by-group basis.

The lower and upper bounds for the number of tickets (and the preferred ranges for same) which determine the numbers of players in each group (and preferred ranges for the numbers for groups), are preferably chosen such that:

- There are at least 5 times as many players as there are tickets (i.e. each ticket has 5 or more players).

- Networks of bettors participate together as much as possible (i.e. tickets are allocated to as many members of the network as possible) so long as the

advantages of a multiple-player structured randomised ticket are generally maintained.

U pper bound for number of bettors is preferably the highest number above 10 which evenly divides the total number of players to be assigned)

Where there are remainder players, in step s9A, the bet processor/controller 310

optionally assigns remainder players not already assigned to tickets. How the betting system manages remainder players is described in detail below under the heading entitled 'Remainder Players'.

I n step s9, the bet processor/controller 310 allocates the tickets to the bettors such that each bettor receives a ticket.

The offering of selectable tickets (i.e. tickets generated during the process in step s9 but not yet allocated to any bettor) is optionally made during step slOA.

In step slO, the bet processor/controller 310, via the server 1, transmits to each of the bettor's bettor interface 200 the ticket(s) allocated to them. Players on a ticket allocated to a bettor are thereby able to be viewed by each bettor via their respective betting interface 200 on their bettor device 4.

A representation of the distribution of players into groups is provided in FIG 6, wherein players are indicated by their rank for display purposes (when the assigned players are transmitted to each bettor via their bettor interface the names of the players are transmitted, not simply their ranking).

Before the result of the golf event is determined, in step slOA, the system preferably permits bettors to swap individual or collections of players (e.g. all players on one ticket) allocated to them with the player(s) allocated to another bettor. How the betting system permits the swapping of players will be described in detail below under the heading entitled 'Swapping Players'.

The system receives real world input from the golf event, including the winning player(s) in step sll. Then, in step sl2, the server communicates to each bettor, via their respective betting interfaces, whether or not one of the players allocated to them was the winning player(s).

The results of the processed bets can be transmitted from the bet processor/controller 310, and settled in a further step (not depicted in the Figures) with the proceeds of processed bets into respective accounts of the bettors 100. The results of settlement can be viewed by a bettor 100 on his bettor device 4.

As described below in further detail, the server 1 validates an account of a bettor 100 to ensure that the account of the bettor 100 contains sufficient funds. Should this validation be met, the bettor may enter the golf event.

More specifically, the bet processor/controller 310 is able to obtain the funds for effecting a betting action by:

• checking the account of the bettor 100 for sufficient funds

• subtracting the amount on the matched credit note from the funds required to

process the betting action. Setting basic parameters and architecture

TABLE 1 below provides a pseudocode fragment relevant to steps s6 to sl2 in FIG 5, namely setting the basic parameters for an embodiment of the betting system invention as described herein.

TABLE 1

' The number of tickets per batch set to a default value of 14

SET Total Tickets per Batch to 14 ' The number of ticket batches to produce set to a default value of 1

SET Total Ticket Batches to 1

' A unique Player Rank is assigned to each Player Name - default value is 1 - this value will be ' the player rank value that is displayed and will not change from the original value

SET Player Rank to 1

' The Modified Player Rank is assigned to each Player Name - the initial value will be the same ' as the Player Rank. In the event that Player Selections are made the Players that have been ' selected will be removed from the total list of players and the remaining players will be

' re-ranked from first to last player in the list excluding the already selected Players with a new

' Modified Player Rank.

SET Modified Player Rank to 1 ' A counter to determine from a Group of Players which is equal to the Total Tickets per ' Batch how many of the tickets have had one or more players from this Group of Players ' assigned - it is not the cumulative number of the total players from the Group of Players ' that have been assigned but essentially a flag to record when any player from the Group ' of Players have been assigned on a single ticket.

SET Group Total Players Assigned Count to 0

' The tickets to be assigned a player in a given round or cycle after taking into consideration ' the Player Selections that have been made from the Group of Players for the round. The ' default value is the Total Tickets per Batch count.

SET Tickets to be Assigned Player in this Cycle Count to Total Tickets per Batch

' For the allocation of players from a ticket this will be the starting Modified Player Ra nk that is ' used for the allocation of players in a round of ticket distribution

SET Modified Group Start Value to 1

' For the allocation of players from a ticket this will be the final Modified Player Rank that is ' used for the allocation of players in a round of ticket distribution - in a given round where ' players are assigned the Group of Players to be assigned to tickets will be between the ' Group Start Value and the Group End Value and will include players within and including ' these values based on their Modified Player Rank

SET Modified Group End Value to Total Tickets per Batch ' The number of rows to be generated for each ticket

SET Total Ticket Rows to 0

' Tracks the number of batches of tickets to be produced

INITIALISE Batch Counter to 0

' The number of Players left over after Players have been assigned evenly to the tickets in a Batch

SET Total Remainder Players to 0

' The total number of players to be assigned

SET Player Count to 0

' The total number of ticket batches the user wants produced (use default value of 1 if no entry) INPUT the Total Ticket Batches

' The total number of tickets to be assigned in a single batch (use default value of 14 if no entry) INPUT the Total Tickets per Batch ' Read the player details into an array (note these need to be listed in rank order from 1st ranked player to last ranked player - 1st player input = 1, 2nd player input = 2, 3rd player input = 3, etc)

DO WHILE Player Name exists

GET Player Rank

SET Modified Player Rank to Player Rank

GET Player Name

SET Player Used Flag to FALSE

ADD 1 to Player Rank and 1 to Player Count

END DO

The above pseudocode sets out parameters for the betting system. The pseudocode is not limited to a specific number of player lists, nor the number of tickets to be assigned in a single batch, nor is it limited to the total number of ticket batches, though it does prescribe default values where no value is input by the user of the system (1, 14, and 1, respectively for the abovementioned parameters). The default value for the total number of tickets per batch is set to 14, though other values may clearly be allowed by the user of the system. The pseudocode in TABLE 1 sets up a 'Modified Player Rank' which will only be

implemented if one or more player selections are made (see below under the heading

Player Selections) and is to assist with ticket allocation and help the groups of players to be evenly distributed amongst the ticket. This will in effect change the players making up the groups of players to be assigned to tickets. It is noted that the 'modified player rank' value is reset to the original Player Rank in the case where no Player Selections are made.

A counter of is also introduced together with the 'Rounds' of players to be assigned, a

'Group of Players' count, and a 'Group Start Value' and the 'Group End Value'. These tools are used during the assignment of players to tickets to ensure that in each round when players are assigned from a group of players, every ticket, excluding those already assigned a player from the group, is assigned a player.

The pseudocode in TABLE 1 further sets up the process of inserting player details (e.g. name, ranking data) into an array on the database 2 for access by the server 1.

TABLE 2 below provides a pseudocode fragment relevant to step s8 and s9 in FIG 5, namely setting up the architecture to distribute the players including how many players are assigned to each ticket.

TABLE 2

' Determine the Total Ticket Rows and Total Remainder Players - the Total Remainder Players ' can never be greater than the number of Total Tickets per Batch.

Total Ticket Rows (quotient) EQUALS Player Count DIVIDED BY Total Tickets per Batch

Total Remainder Players EQUALS Player Count MOD Total Tickets per Batch

' Determine how many players will be assigned in the tickets (this may be less than the Player ' Count and it is also possible that there would be no Total Remainder Players for this value ' when it is DIVIDED BY Total Tickets per Batch).

Total Maximum Assigned Ticket Spots EQUALS Total Ticket Rows TIMES Total Tickets per ' Batch; and the Total Maximum Assigned Ticket Spots EQUALS the number of Ticket Spots to ' be filled by players.

'For the Total Remainder Players, once these players have been identified they either may not 'be assigned to any ticket, or alternatively there are a number of options from which one may be 'selected to assign these remainder players; in two instances the options include the assignment 'of multiple players to one Ticket Spot. In that case, the number of assigned players is greater 'than the Total Maximum Assigned Ticket Spots, the latter being a value which determines the 'dimension of the Ticket Spots to be filled and which dimension remains the same whether or 'not remainder players are assigned to the tickets.

' For the total number of ticket batches write out the ticket details

DO UNTIL Total Ticket Batches generated

ADD 1 to Batch Counter

PRINT Batch Counter

' Reset the Player Count for the ticket

SET Player Count to 0

' When creating a new batch of Tickets ensure Player Used Flag for every player set to

' FALSE DO WHILE Player Name exists

SET Player Used Flag to FALSE

SET Modified Player Rank to Player Rank

END DO

The pseudocode in TABLE 2 sets up a series of rows which in number are the same as the number of groups to which the players are distributed, which is to say the number of rows is a quotient equalling the player count divided by the total number of tickets. Also, a method of defining the remainder players is disclosed, wherein the total number of remainder players cannot be larger than the number of tickets per batch. The remainder players will be understood as being those highest ranked players which are insufficient in number to form a group of players. A mathematical modulo definition is utilised to characterise the remainder players such that the total remainder players equal the player count modulo (MOD) the total tickets per batch.

The above pseudocode also introduces the "Batch Counter", which operates together with the mechanism of setting "Player Used" flags, used in a repeating fashion to ensure that each time a new batch of tickets are generated, the flag values are reset. These operations assist the system to perform 'player list-by-player list' processing of the players. By comparison, the first time that the "Player Used" flag appears in TABLE 1 above is to set the default value for the first batch of tickets.

The person skilled in the art will understand that the pseudocode operates on ticket batches, on a batch-by-batch basis, where each complete batch of tickets includes all assignable players in a player list (i.e. all participating players in the golf tournament that are to be assigned to any ticket).

For the purposes of clarity, in this specification, players are described as being 'assigned' to tickets, and tickets are 'allocated' to bettors. By extension, players may also be 'allocated' to bettors when a ticket naming players has been allocated to a bettor. Grouping and assigning players

TABLE 3 below provides a pseudocode fragment relevant to steps s8 and s9 in FIG 5, namely determining the number of players per group, distributing the players into groups and assigning players to tickets.

TABLE 3 ' Process each batch of tickets ensuring each player is assigned once and only once ' excluding the Total Remainder Players - Remainder Players handled in Last Group of ' Players Batch options

DO UNTIL all Total Maximum Assigned Ticket Spots assigned ' Reset the Ticket Tracker at the beginning of processing each Group of Players Batch

SET Ticket Tracker to 1

' A counter for the round number for the current group of players batch being actioned SET Round Number for the current Group of Players Batch to 0

' Write out the player names based on the assignment of the original Player Ranks and ' the creation of Groups of Players based on these Player Ranks. The Total Players in a ' group is equal to the Total Tickets per Batch . As per the default value of 14 Tickets ' per Batch the groups would be Group 1 is players ranked 1 to 14, Group 2 is players ' ranked 15 to 28, Group 3 is players ranked 29 to 42,..., Group 11 is players ranked

' 141 to 154. Note that the Modified Player Rank will be handled dynamically

' within the player distribution.

FOR each Group of Players Batch (which is equal to the Total Tickets Per Batch and is batches of players in Player Rank order)

' Add 1 to the round number

ADD 1 to Round Number for the current Group of Players Batch

' Assign the player details in the Group of Players Batch to the Ticket Spots IF NOT Last Group of Players Batch THEN

SET Ticket Tracker to 1

' Determine for a Group of Players range how many players need to be assigned ' to Tickets - the intent is that each ticket will have at least one player from that

' group however due to the possibility that Player Selections may be made by a ' Bettor from that Group of Players the actual allocation of players will be based ' on the Modified Player Rank for the players. This may mean that for the purposes ' of player allocation that a Player that was in a higher numbered group moves to ' the lower numbered group to replace one or more Player Selections that have

' been made from the Group of Players based on their original Player Rank.

' For each round/cycle it is necessary to ensure that every ticket has at least ' one player assigned except when one player from the Group of Players already has ' been assigned.

SET Group Total Players Assigned Count to 0

DO UNTIL all Tickets in the Ticket Batch are Checked

DO UNTI L al l Players in Group of Players Batch are Checked

IF Player Exists from Group of Players on Ticket THEN

' If a player from the group exists then only count once per ticket

ADD 1 to Group Total Players Assigned Count

EXIT DO END IF END DO END DO

SET Tickets to be assigned in this Cycle Count EQUALS Total Tickets per Batch

MINUS Group Total Players Assigned Count

' If all of the players from the Group of Players based on their original Player Rank ' have been assigned to each ticket (i.e. one player from the Group of Players

' assigned to each ticket in the Ticket Batch) then there wil l be no players ' assigned for that group and it will be necessary to move to the next group

IF Tickets to be assigned in this Cycle Count NOT 0 Then

' The number of tickets to be assigned a player in this cycle are now known so it is ' necessary to assign players based on the Modified Player Ranks so only

' players that have not been selected already are assigned to Ticket Spots.

SET Modified Group End Value EQUALS Modified Group Start Value PLUS Group Total Players Assigned Count

' Cycle between the Modified Group Start Value and the Modified Group End Value ' (the gap shall never exceed the Total Tickets per Batch) and then based on the ' Modified Player Rank values which fall inclusively between these ranges randomly ' select a player to assign to a ticket

DO UNTIL Tickets to be assigned in this Cycle Count is Complete

' For any Player Selections the Player Used Flag = TRUE has been set when the ' Player Selection was made by the Bettor earlier so no action will happen for ' these players as they have already been assigned to a ticket

DO UNTI L Player Used Flag = TRUE

Randomly identify the Random Current Group Player from a value that is between the Modified Group Start Value and Modified Group End Value inclusive based on the Modified Player Ranks

' Only assign the Player if they have not already been assigned otherwise look ' for the next player in the Group of Players Batch to be assigned (players only ' used once

IF Player Used Flag = FALSE THEN

' Within the ticket find a vacant spot to add the Player Rank and Player Name - ' this ensures that player details are randomly assigned to spots within a ticket SET Vacant Ticket Spot = FALSE ' Checking for a vacant spot on a single ticket

DO UNTI L Vacant Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 and the Total Ticket Rows ' Check if the Ticket Spot is blank and if so

IF Ticket Spot IS BLANK THEN

' Search through every Ticket Spot for the current ticket. If the Ticket ' already has one or more players assigned from the current Group of ' Players or from a previous Group of Players that have already been ' assigned then the Players Current and Previous Rounds Count is

' incremented by 1. Once all ticket spots on the ticket are reviewed a ' comparison is done against what round of group of players is being ' assigned and if this value is equal or greater to the current round then ' a player selection from the current Group of Players will not be

' assigned to this ticket. Also if the Player Rank value is between the ' first and last value of the Modified Player Rank ranges within the current ' Group of Players then a player will not be assigned to that ticket from the ' current group.

' For example if for an individual ticket a player as demonstrated by the ' standard 14 * 11 (156 player) game where a bettor has made

' Player Selections for Players Ranked 1, 2, 20 and 60 the following ' would happen:

' * Group/Round 1 (Modified Player Rank 1 to 14) - No players assigned ' for reason player from group 1 player rank range already assigned. ' * Group/Round 2 (Modified Player Rank 15 to 28) - No players assigned ' for reason player from group 2 player rank range already assigned. ' * Group/Round 3 (Modified Player Rank 29 to 42) - No players assigned ' as three players from previous rounds range already selected (1, 2 and ' 20) and total players of 3 equals group number of 3 (if we added more ' players, result would be unequal distribution of players across tickets). ' * Group/Round 4 (Modified Player Rank 43 to 56) - One new player ' assigned to ticket as three players from previous rounds range already ' selected (1, 2 and 20) and total players of 3 less than group number of 4 ' * Group/Round 5 (Modified Player Rank 57 to 70) - No players assigned ' for reason player from group 5 player rank range already assigned. ' Note: this check occurs for all batches excluding the last batch

' because once we get to the final Ticket Spot for the Ticket and a

' Player Selection has been made for this Player it should already be ' taken and the Player Selections should be full

SET Player Selection from Batch on Ticket to FALSE

' Check every ticket spot for the current Ticket and identify whenever ' a player has been assigned from the current or previous round

DO UNTIL Last Ticket Row of current Ticket

INPUT Player Rank from current Ticket Spot

IF Player Rank greater than ZERO (ticket spot not blank) THEN

IF Player Rank from Ticket EQUAL TO OR LESS THAN the

Modified Player Rank from the Last Player in the current Group of Players Batch THEN

ADD 1 to Players Current and Previous Rounds Count

' If Player Rank is from the current round then another

' player from this round cannot be assigned.

IF Player Rank from Ticket is a Modified Player Rank value

Between the First and Last Player in the current Group of

Players Batch THEN

SET Player Selection from Batch on Ticket to TRUE

END IF END IF END IF END DO

' As per the earlier count to determine how many players are on the ticket ' that are from the current and previous rounds of groups of players,

' if this figure is greater than the round number for the current group

' of players then the player should not be assigned a player

' from the current round - this is a secondary check

IF Players Current and Previous Rounds Count is EQUAL TO OR

GREATER THAN the Round Number for the current Group of Players

Batch THEN

' Player cannot be assigned for this ticket

SET Player Selection from Batch on Ticket to TRUE

END IF

' Only write out the player information if another Player from the Group ' of Players Batch does not exist on the ticket and then move to next ticket IF Player Selection from Batch on Ticket is FALSE THEN

GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

PRINT Player Rank and Player Name

SET Player Used Flag to TRUE

SET Vacant Ticket Spot to TRUE

' Next assigned player to be added to next ticket in batch

ADD 1 to Ticket Tracker

ADD l to Player Count

ELSE

' If Player Selection from Batch on Ticket is TRUE then do not write ' details on ticket and go to the next ticket and look for a vacant spot ADD l to Ticket Tracker

SET Vacant Ticket Spot to FALSE

END IF ELSE

' If Player Used Flag = TRUE then do nothing and exit loop so can assign ' next player

END IF END DO

END IF END DO END DO

' Set up the Modified Group Start Value for the next cycle of players to be assigned

SET Modified Group Start Value EQUALS Modified End Value PLUS 1

END IF

ELSE - Move to processing of Remainder Players

The pseudocode above sets up the mechanisms for the server to group and assign the ranked players to a ticket in a structured randomised manner, ensuring that each player is assigned once and only once (within one list of players), such that players are assigned randomly within tickets and that all tickets are the same number of players (subject to optional remainder player assignment choices set out below). The process cycles through the players to be assigned by checking whether ticket spots are vacant, and only assigns a player to a ticket where a vacant ticket spot remains on that ticket. It will be understood that the total number of ticket spots equals the total number of groups into which players in a player list is divided, multiplied by the number of tickets to be generated in that ticket batch.

The process assigns players on a group-by-group basis, whereby a single player from the group being actioned is assigned to each ticket in the ticket batch in order from the first to the last ticket ensuring that only one player from each group is assigned to a ticket (subject to optional players selections and remainder player assignment, set out below). This process is repeated until the players from all groups of players have been assigned to the ticket spots.

The process further uses a Ticket Tracker and a Player Count and Flags to keep track of the order in which players have been assigned to tickets, and which players have been assigned. The process ensures the structured randomised assignment of players to the tickets, which in turn creates a more even spread of players across the bettors (NB. some players may be removed by bettor selection). It also ensures that players are randomly assigned to the available ticket spots within each single ticket to create the appearance that the player details within a single ticket have been assigned in a completely random manner.

Where player selections are made, the pseudocode is able to adopt a 'dynamic' ranking of the players in response to player selections being made. This permits changes to the number of players from each group that are randomly assigned to a ticket and handles scenarios where individual bettors select more than one player from a particular group. 10 The pseudocode in TABLE 3 develops the 'Modified Player Rankings' mechanism which adjusts the rankings of players after Player Selections are made. This resetting of player rankings ensures that players are not assigned to a bettor's ticket from a particular group currently being processed if that bettor's ticket already has a player from that group. It also ensures that if the number of players that a bettor has selected from current and previous groups is greater than the group round currently being processed, that bettor's ticket cannot be assigned a player from the group which the system is currently assigning to tickets. In summary this ensures that if on a ticket a bettor has selected players 1, 2 and 3 (and only these players) then the next player assigned to that bettor's ticket would not occur until the fourth group round of processing, and that bettor's ticket would not be assigned any players during the processing of group rounds one, two and three due to that bettors three group one selections.

There are other ways of handling player distribution and assignment (as there are other ways of setting up the basic parameters or system architecture) which will be known to the person skilled in the art, for example the process could be undertaken on a ticket by ticket basis whereby single tickets are produced one at a time rather than a batch of tickets for all of the players to be assigned. Alternative methods of achieving a randomised distribution of players in accordance with the objectives of the present invention are intended to fall within the scope of the invention.

The remainder players are not assigned in this pseudocode procedure, as that process is optional and is set out in further detail below. Player Selections

TABLE 4 below provides a pseudocode fragment relevant to OPTIONAL step s8A in FIG 5, namely the assignment of player selections by the bet processor/controller. TABLE 4

' For the Ticket Batch an option is chosen in relation to how Player Selections are made. ' Whatever option is chosen this will be applicable to all Player Selections in the Ticket Batch. ' The Bettor chooses to select between 1 and 3 Players from the playing field - it is

' possible that multiple or all Bettors for a single batch of tickets may choose players.

PRINT "Enter Player Selection Options for the Ticket Batch from the available choices" PRINT "- Choice 1 - No players to be selected"

PRINT "- Choice 2 - Bettors make 0 to 3 selections in ticket order - i.e. all selections are made for a Bettor before the next Bettor makes their choice"

PRINT "- Choice 3 - Bettors make 0 to 3 selections in a draft - i.e. all round 1 selections made for all Bettors first then all round 2 selections made for all Bettors, etc"

PRINT "- Choice 4 - Bettors make a single selection from each of Group 1, 2 and 3 of the Player Batches - i.e. all selections are made for Bettor from Groups before the next Bettor makes their choices"

I NPUT Player Selection Options from choices

SELECT CASE Player Selection Options

' Choice 1 - No players to be selected for the ticket - default value

CASE IS No players to be selected - Total Bettors = 0

' No further action

' Choice 2 - Entire Pool Selection Option - For the Bettors in the Batch a Ticket

' Buyer will be able to select between 1 to 3 players. The Bettor will make all their ' player selections (maximum of 3) before the next Bettor wil l make a selection. This

' will happen until all Bettors for the Batch have made their player selections.

CASE IS Bettors make Player Selections for all their selections in Bettor

Order

DO UNTIL Total Bettors have made Player Selections for all Tickets

PRINT "Does the Bettor want to make their own Player Selections" INPUT Bettor Players Choice (YES or NO)

' Only get Player Selections from the Bettor if they want to choose own players IF Bettor Players Choice is Player Selection to be made THEN

PRINT "Enter Number of Player Selections to be made"

INPUT Bettor chooses Number of Player Selections (0 to 3)

SET Number of Player Selections to input value

DO UNTIL Number of Player Selections al l made (Maximum of 3) for Bettor

SET Valid Player Selection = FALSE

DO UNTIL Valid Player Selection for current selection = TRUE

PRINT "Enter your player selection"

INPUT Bettor Player Selection

IF Player Used Flag = TRUE Then

PRINT "This player has been selected - make another selection"

ELSE SET Player Used Flag to TRUE for Player Selection

SET Valid Player Selection to TRUE

' The default value will remain as the Random Selected Player if no choice SELECT CASE Number of the Player Selection

CASE IS First Choice Player Selection

SET Player Selection # 1 to Bettors chosen Player Rank and

Player Name

CASE IS Second Choice Player Selection

SET Player Selection # 2 to Bettors chosen Player Rank and

Player Name

CASE IS Third Choice Player Selection

SET Player Selection # 3 to Bettors chosen Player Rank and

Player Name

END CASE END IF END DO END DO

END IF END DO ' Choice 3 - Draft Player Selection Option - For the Bettors in the Batch a Ticket

' Buyer will be able to select between 1 to 3 players. The Bettors in the Ticket Batch ' take it in turn making their selections choosing one player at a time until all selections are ' made. Every Ticket in the Ticket Batch goes in the draft however a Bettor may

' choose to pass on a selection.

CASE IS Bettors make Player Selections as per a Draft Order

' Determine the draft order for all Bettors in the Batch who are making a selection DO UNTIL Total Bettors Draft Order is finalised

DO UNTIL Draft Order Option Used

Randomly select a number between 1 and the Total Bettors for the batch SET Draft Order #

IF Draft Order # has been used THEN

' Do nothing - need to make another selection

ELSE

SET Bettor Draft Order for Bettor to Draft Order #

' Exit the loop and determine the Draft Order for the next Bettor

EXIT DO END IF END DO

' As part of the draft players can make selections from all available players

FOR Counter = First Draft Round to Third Draft Round (Maximum)

DO UNTIL Total Bettors have made Player Selections in Bettor Draft

Order

DO UNTIL Player Selection made for Bettor

PRINT "Enter your player selection or 'PASS' if no selection for round" INPUT Bettor Player Selection SET Valid Player Selection = FALSE

DO UNTIL Valid Player Selection for Bettor Player Selection is TRUE

IF Bettor Player Selection NOT "PASS" Then

IF Player Used Flag = TRUE Then

PRINT "This player has been selected - make another selection"

ELSE

SET Player Used Flag to TRUE for Player Selection SET Valid Player Selection to TRUE

' The default value will remain as the Random Selected Player that ' will be randomly generated after all Bettor Player Selections

' are made

SELECT CASE Draft Round Number

CASE IS First Draft Round Player Selection

SET Player Selection # 1 to Bettor Selected Player Name and Rank from first round of draft

CASE IS Second Draft Round Player Selection

SET Player Selection # 2 to Bettor Selected Player Name and Rank from second round of draft

CASE IS Third Draft Round Player Selection

SET Player Selection # 3 to Bettor Selected Player Name and Rank from third round of draft

END CASE ELSE

' No player to be selected so EXIT the loop

EXIT DO

END IF END DO END IF END DO END DO NEXT FOR

' Choice 4 - The Bettor makes a single selection from each of Batches 1 to 3 of their ' Group of Players Batch or chooses not to select a player. A Group of Player Batch is ' equal to the Total Tickets per Batch and they are grouped by ranking so if Total Tickets

' per Batch is 14 then 14 then Group 1 is players ranked 1 to 14, Group 2 is players ranked ' 15 to 28 and Group 3 is players ranked 29 to 42, etc

CASE IS Bettors select ZERO or ONE Player from Batches 1 to 3 of the Group of

Players Batch

DO UNTIL Bettors have made Player Selections from each Group of Players

from Batches 1 to 3 for all Tickets

PRINT "Does the Bettor want to make their own Player Selections"

INPUT Bettor Players Choice (YES or NO)

' The Bettor shall select a single player from the Group of Players Batch 1-3 DO UNTI L Individual Bettor has selected from the first three Group of

Players Batches in Batch Order (Group 1, Group 2, Group 3)

SET Valid Player Selection = FALSE

DO UNTIL Valid Player Selection for current selection = TRUE

PRINT Display Group of Players Batch for Current Batch (1, 2 or 3)

PRINT "Enter your player selection from group or 'PASS' if no selection for round"

INPUT Bettor Player Selection from Current Batch (1, 2 or 3) IF Bettor Player Selection NOT "PASS" Then

IF Player Used Flag = TRUE Then

PRINT "This player has been selected - make another selection from the group"

ELSE SET Player Used Flag to TRUE for Player Selection SET Valid Player Selection to TRUE

SELECT CASE Group of Players Batch # (1, 2 or 3)

CASE IS First Group of Players Batch Selection

SET Player Selection # 1 to selected Player Rank and Player Name CASE IS Second Group of Players Batch Selection

SET Player Selection # 2 to selected Player Rank and Player Name CASE IS Third Group of Players Batch Selection

SET Player Selection # 3 to selected Player Rank and Player Name END CASE END IF ELSE

' No player to be selected so EXIT the loop

EXIT DO END IF END DO END DO END IF END DO

END CASE

' Cycle through each of the single Tickets in the Total Tickets per Batch and for each single ' ticket locate vacant Ticket Spots and then within the ticket randomly allot the details for the ' zero to three Player Selections that have been made by the Bettor. Ticket information ' is stored and assigned within Bettor order - i.e. Ticket # 1 = Bettor # 1, Ticket #

' 2 = Bettor # 2, etc.

SET Ticket Tracker to 1

DO UNTIL Player Selections for all Bettors for the Ticket Batch are assigned

DO UNTIL all Player Selections for individual Bettor are assigned (Review all 3

Player Selection slots - Player Selection # 1, Player Selection # 2, Player Selection # 3) IF Player Selection NOT made for the Current Player Selection being reviewed THEN ' Do nothing when a player is not chosen for a given Player Selection - go to the next

' player

ELSE

SET Vacant Ticket Spot = FALSE

DO UNTI L Vacant Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 a nd the Total Ticket Rows ' Check if the Ticket Spot on the Ticket is blank and if so print out the player details ' then move to the next column so it is ready to assign the next player IF Ticket Spot IS BLANK THEN

GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

PRINT Player Rank and Player Name based on Player Selection

SET Vacant Ticket Spot to TRUE

' Next player selection to be added to next ticket in batch

ADD 1 to Player Count

END IF END DO END IF END DO

' Once the three Player Selections have been assigned to the ticket go to the next ticket ADD l to Ticket Tracker

END DO

' Tracks the column to print the player details into set to a default value of 1

SET Ticket Tracker to 1

' Write out the headings for each Ticket Batch in a new column

DO UNTIL Total Tickets per Batch maximum value reached

PRINT Ticket Number

ADD l to Ticket Tracker

END DO ' After Player Selections are made the players are re-ranked for the purposes of grouping ' and allocation. The original Player Rank value is retained and this is the value displayed ' on the tickets. A new Modified Player Rank is also assigned to the players for which a ' Player Selection has not been made. The purpose of this reassignment of modified

' player rankings is to ensure that when Players are removed from the available pool ' of players in a Group of Players Batch that the total players in a Group of Players Batch ' is still equal to the number of tickets. If this does not happen then it is possible that a ' ticket would not be assigned a player from each Group of Players Batch which would ' lessen the value of some tickets and may mean that some tickets may have vacant ticket ' spots.

SET Modified Player Count to 1

DO WHILE Player Name exists

IF Player Used Flag is FALSE THEN

SET Modified Player Rank to Modified Player Count

ADD 1 to Modified Player Count

ELSE

' Players with a rank of 99999 are not assigned - this value must be greater than the ' number of total players so there is no chance of the Player being used again SET Modified Player Rank to 99999

END IF END DO

I n summary, the pseudocode in TABLE 4 describes a number of choices for enabling player selections by the bettor (note for Choice 1 that no players are selected).

For Choice 2, bettors make 0 to 3 selections in ticket order (i.e. all selections are made by one bettor, otherwise known as the 'Bettor', before the next bettor makes their selection(s)). Higher numbers of selections may be permitted, however it is not preferable that any individual bettor selects too great a number of players as this would remove the benefits of a structured randomised distribution of players previously set out in this patent specification.

For Choice 3, bettors make 0 to 3 selections in a draft (i.e. all round 1 selections are made for all bettors first, then all round 2 selections are made for all bettors, and finally all round 3 selections are made for all bettors). Higher numbers of selections may be permitted. For Choice 4, bettors make a single selection from each of Groups 1, 2 and 3 of the Player Batches (i.e. all selections are made by the bettors from Group 1, before selections from Group 2 are made; and all selections are made by the bettors from Group 2 before selections from Group 3 are made). Higher numbers of selections may be permitted (e.g. cyclical selections made by all bettors from all Groups).

It is optionally preferred that the additional randomisation is provided with respect to determining the order of bettors making player selections (not set out in the pseudocode); for example in Choice 2, the bettor holding the first ticket is not guaranteed to make their selection(s) first (where there are 14 bettors making players selections, he or she only has a 1 in 14 chance of being the first bettor to make a selection); similarly in Choice 3 the order of bettors making selections within any particular draft may be randomly determined.

There are other ways of handling player selections, and what is set out above should not be understood as an exhaustive range of options. For example, player selections may be limited to players having a particular ranking (e.g. the highest 100 ranked players); or bettors may be able to nominate a number of preferred player selections but only be allocated one (or more than one) of said players, depending on the nominated preferred player selections submitted by other bettors: for example, a player selection could only be authorised where all other bettors nominate selected players from the same group.

Remainder Players

TABLE 5 below provides a pseudocode fragment relevant to OPTIONAL step s9A in FIG 5, namely assigning the Remainder Players.

TABLE 5

' Process the Last Group of Players Batch which also includes Remainder Players SET Last Group of Players Batch EQUAL (Last) Group of Players Batch plus any

Total Remainder Players

SET Ticket Tracker to 1 PRINT "Select how the 'last group of players batch' is to be handled:"

PRINT "- Choice 1 - Final group of players which includes any remainder players are randomly assigned until ticket spots are full - excess players are not assigned"

PRINT "- Choice 2 - Any remainder players are assigned to existing ticket spots so some ticket spots have two players in them"

PRINT "- Choice 3 - When the final ticket spot on all tickets is left this is updated to state Other Players' to include the final player and any remainder players"

GET Last Group of Players Batch Handling Option SELECT CASE Last Group of Players Batch Handling Option

' Choice 1 - The final group of players which includes remainder players are ' randomly assigned to the final ticket spots until all ticket spots are full - there will ' be excess players equal to the Total Remainder Players who are not assigned to ' a ticket

CASE IS assign Last Group of Players Batch and not assign Remainder Players DO UNTI L Player Count EQUALS Total Maximum Assigned Ticket Spots DO UNTIL Player Used Flag = TRUE

Randomly identify the Random Current Group Player from the Last Group of Players Batch

IF Player Used Flag = FALSE THEN

SET Vacant Ticket Spot = FALSE

DO UNTIL Vacant Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 and the Total Ticket Rows IF Ticket Spot IS BLANK THEN

GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

PRINT Player Rank and Player Name

SET Player Used Flag to TRUE

SET Vacant Ticket Spot to TRUE

ADD 1 to Ticket Tracker ADD 1 to Player Count

END IF END DO END IF END DO END DO

' Choice 2 - The final group of players which includes remainder players are

' randomly assigned to the final ticket spots until al l ticket spots are full - there will

' be excess players equal to the Total Remainder Players and these excess

' players will be randomly assigned to Ticket Spots so some Ticket Spots have two

' players listed in them

CASE IS assign Last Group of Players Batch and excess Remainder Players

DO UNTIL all players in Last Group of Players assigned Ticket Spots

(includes assignment of Remainder Players)

IF Player Count EQUAL TO OR LESS THAN Total Maximum Assigned

Ticket Spots

DO UNTI L Player Used Flag = TRUE

IF Player Used Flag = FALSE THEN

SET Vacant Ticket Spot = FALSE

DO UNTIL Vacant Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 and the Total Ticket Rows

IF Ticket Spot IS BLANK THEN

GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

PRINT Player Rank and Player Name

SET Player Used Flag to TRUE

SET Vacant Ticket Spot to TRUE ADD l to Ticket Tracker

ADD 1 to Player Count

END IF END DO END IF

END DO ELSE

' Some players to be assigned two spots - random selection from all ' Ticket Spots

DO UNTIL Player Used Flag = TRUE

Randomly identify the Random Current Group Player from the Last

Group of Players Batch

IF Player Used Flag = FALSE THEN

SET One Player Only in Ticket Spot = FALSE

DO UNTIL One Player Only in Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 and the Total Ticket Rows

Randomly select a Ticket Spot Column between 1 and the Total Tickets per Batch value

GET Ticket Spot information

IF MORE THAN 1 Player Rank and Player Name assigned to Ticket Spot THEN

DO Nothing

ELSE GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

CONCATENATE existing Ticket Spot Player Rank and Player Name details to current Player Rank and Player Name PRINT combined Player Rank and Player Name

SET Player Used Flag to TRUE

SET One Player Only in Ticket Spot to TRUE ADD l to Player Count

END IF END DO END IF END DO END IF END DO

' Choice 3 - The final group of players which includes remainder players are ' randomly assigned to the final ticket spots until all ticket spots except one is ' taken. For the final ticket spot a value of "Other Players" will be used and this ' covers the last player to be assigned and any remainder players.

CASE IS assign Last Group of Players Batch and for the Final Ticket Spot excess Remainder Players assign to an Other group

DO UNTIL Player Count EUQALS Total Maximum Assigned Ticket Spots

(Last Ticket Spot value equals Other)

' Locate the remaining ticket spots to assign the Last Group of Players (this ' should be one blank spot per ticket)

SET Locate Final Ticket Spot = FALSE

DO UNTI L Locate Final Ticket Spot = TRUE

Randomly select a Ticket Spot Row between 1 and the Total Ticket Rows Randomly select a Ticket Spot Column between 1 and the Total Tickets per Batch value

GET Ticket Spot information

IF Ticket Spot IS BLANK Then

GO TO Ticket Spot (Ticket Spot Row and Ticket Tracker)

IF Player Count LESS THAN Total Maximum Assigned Ticket Spots

PRINT combined Player Rank and Player Name

ELSE

' Last Ticket Spot on the Batch of Tickets equals Remaining Players PRINT "Other Players"

END IF

SET One Player Only in Ticket Spot to TRUE

ADD 1 to Player Count

END IF END DO END DO END CASE END IF NEXT FOR END DO END DO

In summary, the pseudocode in TABLE 5 describes three choices for handling remainder players.

Choice 1 establishes a supplemented Final Group of players which includes the highest ranked players forming a complete group plus any remainder players; players in this supplemented Final Group of players are randomly assigned until ticket spots are full. Some players in this Final Group will not be assigned.

Choice 2 assigns all players, including any remainder players, by assigning said remainder players to existing ticket spots so that some ticket spots have two players and a maximum of two players in them.

Choice 3 uses an Other Players' option for the last Ticket Spot, whereby the last ticket spot across all tickets is updated to state Other Players' and said last ticket spot is assigned all as yet unassigned players.

The different choices of handling remainder players set out herein can be illustrated using an example and a results table (see TABLE 6, below):

• The total number of tickets is 4 and there are 2 remainder players;

· The players comprising the highest ranked group of players plus the two remainder players are Adam, Bert, Fred, John, Leon and Mike, in order of rank from lowest (say, 100) to highest (say, 105);

• Say that said six players are, for sake of argument, randomly assigned to the tickets in the following order - Bert, Leon, Adam, Mike, Fred, John.

TABLE 6

In summary, choices 2 and 3 ensure all players are assigned, including the remainder players. The assignment of the remainder players continues to be random such that ticket 3 is assigned John in choice 2 (and not a lower ticket number, i.e. ticket 2). For choice 3, ticket 2 is assigned the Other Players' to further make clear the random distribution of the players (i.e. the system need not assign the Other Players' to the highest ticket number, i.e. ticket 4). In the pseudocode in the TABLES 1-5 above there are structures set up to randomly select a Ticket Spot Row and randomly select a Ticket Spot Column when assigning the Other Players' for choice 3.

It will be understood by the person skilled in the art that there are other ways of handling remainder players, and what is set out in the above three choices should not be considered to be an exhaustive set of options. For example, a straightforward mechanism would be to simply remove the remainder players from the player list at an early stage so that they do not undergo the processes of assignment to a ticket or allocation to a bettor.

Swapping players or tickets

In some preferred form of the invention, the system permits bettors to swap the players which have been allocated to them with other bettors. Preferably, the server is configured to permit, either before the commencement of or during the course of the golf event, one or more bettors to swap one or more players with another one or more bettors. Under particularly preferred swapping conditions, the system permits a bettor to swap players One-for-one' with another bettor so long as the players swapped come from the same group (e.g. the swapped players are each ranked 15-28). Alternatively, bettors may swap a plurality of players or an entire ticket.

Other operations - relating to betting arrangements or conditions

The operations performed by the system are not limited to the examples provided above, and may include any of the following: individual bettor driven proposals to change the bettor's individual, or an entire pool of bettors', betting stake; player swaps between bettors which are not swaps of players within the one group but are nevertheless consistent with an equal player distribution amongst the tickets so that each ticket has a reasonably equal likelihood of being the winning ticket or is otherwise validated (e.g. proposed new distribution of players is acceptable to the entire bettor pool). Other operations - not relating to betting arrangements or conditions

Other operations able to be performed by the server of the system, such as the highlighting of allocated players on the bettor interface in real-time to indicate how players are performing in the golf event, or providing a messaging mechanism between bettors allocated players from a particular ticket batch/list of players, etc., are not described in further detail as is understood that the person skilled in the art would know how to implement such operations.

Bet Validator

FIG 5A is a second processflowchart, which includes a bet validator, depictingfunctional steps in broad overview principally transacted at or connectedwiththeserverl. FIG 5A shares a number of functional steps in common with FIG 5, including most of steps s6 to sl2, and the disclosure in relation to these steps is referred to and relevant to the operation of the functional steps of FIG 5A, subject to the additional oversight/validating operations of the bet validator as described in this specification.

Optional steps s8A and s9A in FIG 5 are not shown in FIG 5A, though may be included in the functionality of a system or method of the present invention in accordance with the preference of the system or method designer or operator. Optional step slOA is incorporated into the operations of the bet validator as will become clear.

In step s6A, the bet validator 320 initially encodes into a bettor data packet a bettor's action to enter a golf event. The bettor data packet will include, inter alia, a bettor ID, a web session ID, links to bettor IDs for the pool of bettors to which a particular bettor belongs, or the stake a bettor.

In step slOA, the bet validator 320 encodes additional data into bettor data packets in response to further betting actions, including, inter alia, a counting device to count the number of betting actions taken by a bettor, a flagging device to indicate to the system operator if the bettor packet includes unauthorised data (see schematic representation in FIG 5C of the data in a data packet 600).

The bet validator 320 receives data relating to betting actions including bet placements or modifications, or modifications to betting conditions or arrangements, from the bettor interface 200 or the bet processor/controller 310, then processes bettor data packets corresponding to these requests to validate or invalidate betting actions and enable more regulated processing of bets, betting arrangements and conditions.

The bet validator 320 updates bettor data packets with data relating to the betting actions (including if a betting action is rejected by the bet validator 320), and also communicates with the bettor interface 200 by, for example, updating the players on the bettor's electronic ticket, displaying notifications in response to betting actions, etc. in step slOA. The bet validator 320 preferably processes bettor data packets to validate, inter alia:

that each bettor data packet corresponding to an individual bet includes the bettor IDs of the bettor and/or links the bettor ID of that bettor to the bettor IDs of each bettor in the pool of bettors to which that particular bettor belongs (without linking to any other bettor IDs for bettors outside of the pool);

- that the right players are assigned to a bettor's ticket;

the number of betting actions proposed by a bettor is less than a designated number (i.e. 5) set by the operator of the system;

or whether any betting action meets the requirements for structured randomised betting set by the system as set out in the sections above including those labelled "Player Swaps or Ticket Swaps" or "Other Operations". In other words, the bet validator assesses whether the betting action preserves the relative equal distribution of ranked players amongst the tickets so that each ticket has a reasonably equal likelihood of having the winning player. The exception to this 'equality preserving' rule is that the bettors as a collective group may decide that a modification is acceptable (e.g. a unanimous or majority vote decides that a modification to the initial betting stake is acceptable), even if the system does not.

Once the bet validator has assessed whether the betting action is acceptable, the bet validator notifies the relevant parties (i.e. betting action proposer, affected bettors, or the system operator/administrator) accordingly.

Other examples of betting actions which the bet validator 320 may validate include:

where there is a single player swap between bettors, and each player is from the same group;

multiple player swaps such as where 2 players for bettor A from each of group 1 and group 4, may be acceptable to swap with 2 players for bettor B from each of group 2 and group 3;

where the bettor proposes a change to betting arrangements which will apply to all bettors, and all bettors agree to this, then the modification is able to be validated

(subject to overriding betting system requirements); an increase minimum bet stake, only if all bettors in a pool agree.

Whether or not a betting action is validated may depend on the stage of the golf event when the betting action is processed. For example, swapping players from within group 1 at the end of the penultimate day, where some players proposed to be swapped are near the top of the leader board and others are near the bottom, would not be acceptable; however, swapping two group 1 players who were tied at the top of the leader board may be permitted right up to the final hole.

As an additional means to ensure that the structured randomised nature of the betting system proposed by the present invention is preserved, it may be that all betting actions (after the initial placement of the bet and receipt of a ticket) must be processed by the bet validator 320 so that they are voted on and agreed to by all (or a majority) of the bettors in the betting pool, whether or not their ticket is directly altered (i.e. by changing their bet or altering the players listed on their ticket).

The bet validator 320 provides a balance between encouraging the proposal of

modifications to bets, betting arrangements or conditions which are within the

requirements of the system for enabling structured randomised betting (to provide increased engagement with the betting system amongst all bettors), and discouraging the proposal of modifications to bets, betting arra ngements or conditions which are incompatible with the requirements of the system for enabling structured randomised betting (and the exposure of bettors to system incompatible proposals).

The above is a description of how a preferred from bet validator 320 as depicted FIG 5A operates. It will be apparent to the reader that the bet validator 320 of FIG 5A operates in parallel with the steps undertaken by the bet processor/controller 310 of FIG 5. It should be understood that the bet validator 320 may be combined with the be

processor/controller 310 (e.g. as depicted in FIG 5) so that the bet

processor/controller/validator (i.e. the BPCV) performs all of the operations of the be processor 310 described herein as well as all of the bet validator 320 described herein. A preferred form of the processing undertaken by the bet validator 320 is depicted in the sequence diagram FIG 5B. The bet validator first encodes a bettor data packet in response to a bettor action (this includes encoding by updating an existing bettor data packet in response to a second, third, etc. betting action). Where there is

unauthorised or irregular data in the bettor packet (e.g. the bettor I D is not linked to all other bettor I Ds in the relevant betting pool), this is flagged by the bet validator

320 to the operator of the betting system. The bet validator processes a data packet to validate or reject the proposed betting action, and depending on the result, communicates with the bettor making the proposal via that bettor's bettor interface and/or other bettors via their respective bettor interfaces and/or the system operator via a system operator interface (not shown).

Figure 5C is a schematic representation of a data packet 600 encoded in response to a betting action proposal made by a particular bettor to increase his betting stake on the final day of the golf event because he has a player listed on his ticket that he expects to win the golf event. This proposal is referred to as "Betting Scenario A". The data packet includes the following data : the particular bettor's bettor ID and the linked bettor IDs (i.e. the bettor I Ds corresponding to all other members of the pool in which the particular bettor is a member); a web session I D corresponding to the particular bettor having logged into the system prior to performing the betting action; the particular bettors current stake; details of the bet proposal (e.g. to increase his stake and/or the stake of all other bettors in the pool); the number of holes played in the golf event (since the golf event is close to finishing, this increases the likelihood the bet validator does not validate the proposal); a bet action counter and flagging device to notify the system operator (in this case, the bettor has already made three similar proposals to other bettors prior to the start of the final day's play - which meets the designated maximum number of such modifications set by the operator in this Betting Scenario A). Were this data packet 600 to be processed by the bet

validator 320, the system operator would be notified due to the unauthorised number of similar proposals in the data packet counter. The system operator would then

respond to the bettor, via the bet validator, to advise that the bettor is not able to undertake this betting action in this golf event.

Manifold advantages are obtained in the application of bettor data packages and a bet validator, as part of the system or method of the present invention. In particular, the data relevant to ensuring the integrity of the system or method of the invention is grouped together in a single structure (i.e. a data package) which may be easily and efficiently processed by a bet validator or BPCV. The improved integrity is considered particularly relevant in the context that one bettor's betting actions may influence betting outcome and/or the bettor engagement with other bettors. The bet validator also provides an additional layer of security to the bettor and betting system/method operator beyond that provided by a processor/controller acting in a conventional sense, as the bettor packages act to 'double-check' that only validated bets, betting arrangements conditions are processed and communicated to bettors.

I n relation to the steps performed by the bet validator, it is understood that the person skilled in the art would be able to implement the operations of the validator and integrate this with other steps referred to above in relation to the bet processor/controller, by having regard to and applying the syntax and semantics of the pseudocode provided in TABLES 1-5.

Operation on player lists

As may be seen in FIG 6, the above-described implementation of the system may operate on a player list comprising 154 players where 14 tickets are to be generated. I n the scenario illustrated in FIG 6, players are distributed into 11 groups (Group 1 having players ranked 1-14, and so on). As mentioned previously, players are referred to by their only ranking in FIG 6 (and FIG 7). Players are then assigned to tickets in a structured randomised manner as set out above in which there is a shuffling of players within each ticket as part of the assignment process (i.e. assignment of players to vacant ticket spots in random manner) so that there is no apparent order to the players in any ticket. The tickets are then allocated to the bettors. The winning player is ranked 99 and the winning bettor therefore holds ticket C.

As may be seen in FIG 7, which illustrates a similar scenario to that in FIG 6, the system again operates on a player list having 154 players where 14 tickets are to be generated. Likewise, players are distributed into 11 groups (Group 1 having players ranked 1-14, and so on). Players are then assigned to tickets in a structured randomised manner so that each ticket is assigned one and only one player from each group; there is then a separate shuffling step where players within each ticket are shuffled so that there is no apparent order to the players in any ticket. Once more, the tickets are then allocated to the bettors. The winning player is ranked 99 and the winning bettor therefore holds ticket C. Bettor experience

FIG 8 depicts a betting interface screen for a first bettor 110. The server 1 uses betting data relating to the first bettor 110 ('Bettor A') and the golf event to show players allocated to the bettor, and other data regarding the bettor and golf event, which have been transmitted to the bettor's bettor device 4 via the bettor interface 210 using an electronic ticket.

FIG 9 depicts a betting interface screen, as a modified version of the screen of FIG 8, which, by highlighting a player, indicates that the player (Jason Day) is currently (i.e. in real-time) leading in the golf event and that player is one of the first bettor's allocated players.

FIG 10 depicts a betting interface screen, as a modified version of the screen of FIG 8, which includes a notification comprising a request made by a second bettor 120 ('Bettor B') to swap a player with the first bettor 110.

FIG 11 depicts a betting interface screen, as a modified version of FIG 8, which includes a notification comprising an indication to a bettor that his betting action has been rejected by the system operator. This interface depicts what a bettor would see in Betting Scenario A described above.

INTERPRETATION

It will be appreciated by those skilled in the art that many modifications and variations may be made to the embodiments described herein without departing from the spirit or scope of the invention. More particularly, the implementations described above with reference to the pseudocode in TABLES 1-5, include operations and/or other parameters may be removed and/or added to the coding which underpins the system yet still fall within the scope of the invention. For example, the system need not be able to process multiple batches of tickets, neither does it need to shuffle the assigned players within a ticket (either as part of the player to ticket assignment process, or as a post assignment but pre- allocation process), nor does the system need to include the extra coding regarding a dynamic ranking framework to permit processing of player selections yet retain the structured randomised distribution when assigning the unselected players. Similarly, where player selections or remainder player processing is adopted in the system, the choices set out in the coding for handling player selection/remainder players are only suggested implementations, and alternatives are intended to fall within the scope of the invention. Throughout the specification the word "comprise" and its derivatives are intended to have an inclusive rather than exclusive meaning unless the contrary is expressly stated or the context requires otherwise. That is, the word "comprise" and its derivatives will be taken to indicate the inclusion of not only the listed components, steps or features that it directly references, but also other components, steps or features not specifically listed, unless the contrary is expressly stated or the context requires otherwise.

In the specification, the terms "low" or "high" or their derivatives, when used in the context of referring to a player ranking, should be understood as follows: a "low" ranking player is considered on that ranking metric to be a better golfer than a "high" ranking player. An algorithm or computer implementable method is here, and generally, considered to be a self-consistent sequence of acts or operations leading to a desired result. These include physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored,

transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as, values, elements, terms, numbers or the like.

Unless specifically stated otherwise, use of terms throughout the specification such as "computing", "calculating", "determining", "resolving" or the like, refer to the action and/or processes of a computer or computing system, or similar numerical calculating apparatus, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such data storage, transmission or display devices. It should be understood, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

I n the present specification, terms such as "component", "means", "device" and "member" may refer to singular or plural items and are terms intended to refer to a set of properties, functions or characteristics performed by one or more items having one or more parts. It is envisaged that where a "component", "means", "device" or "member" or similar term is described as being a unitary object, then a functionally equivalent object having multiple components is considered to fall within the scope of the term, and similarly, where a "component", "means", "device" or "member" is described as having multiple items, a functionally equivalent but unitary object is also considered to fall within the scope of the term, unless the contrary is expressly stated or the context requires otherwise.

The mere disclosure of a method step or system component or operation in the

specification should not be construed as being essential to the invention claimed herein, expect where it is either expressly stated to be so, or expressly recited in a claim.

The terms in the claims have the broadest scope of meaning they would have been given by a person of ordinary skill in the art as of the relevant date.

The terms "a" and "an" mean "one or more", unless expressly specified otherwise.

Neither the title nor the abstract of the present application is to be taken as limiting in any way the scope of the claimed invention.

Where the preamble of a claim recites a purpose, benefit or possible use of the claimed invention, it does not limit the claimed invention to having only that purpose, benefit of possible use.

Claims

1 . A system for enabling structured randomised betting on a golf event by a plurality of bettors, including:

a bet processor/controller,

a bet validator,

a database,

and a plurality bettor interfaces,

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event; communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s); wherein the server is further configured to execute the steps of:

engaging the bet validator to cause a bettor data packet to be encoded or updated in response to a betting action communicated to the bet validator via the bettor interface;

validating the betting action; and communicating to a bettor via that bettor's bettor interface whether the betting action is validated by the bet validator.

2. The system of claim 1 , wherein each bettor data packet includes, in relation to the bettor proposing the betting action:

a. a bettor ID corresponding to the bettor;

b. a bettor ID for each of the plurality of bettors;

3. The system of claim 2, wherein each bettor data packet further includes, in

relation to the bettor proposing the betting action, one or more of the following: a. a web session ID connected to the proposed betting action;

b. the players on the ticket(s) allocated to the bettor;

c. a counter for the number of betting actions the bettor has proposed

and/or achieved;

d. a betting amount staked by the bettor in the golf event;

e. the number of holes which have been played in the golf event;

f. a flagging device to indicate when a bettor data packet includes

unauthorised data.

4. The system according to any one of the preceding claims, wherein each ticket is randomly assigned one player from each and every group such that each of the tickets is randomly assigned a number of players equal to the number of the plurality of groups.

5. The system according to any one of the preceding claims, wherein the server is configured to generate the number of tickets corresponding to the number of bettors so as to maximise the number of players allocated to each bettor.

6. The system according to any one of the preceding claims, wherein the server is configured to execute the step of transmitting the tickets allocated to each bettor by issuing an electronic ticket to each bettor's bettor interface.

7. The system according to any one of the preceding claims, wherein the server is configured to execute the step of shuffling the players which are assigned to each ticket, such that observable effects of ordering of the players by ranking during operation of the method are further hidden from the bettor.

8. The system according to any one of the preceding claims, wherein the server is further configured to execute the steps of:

transmitting to the one or more bettor interface(s) an option for one or more bettor(s) to select one or more player(s); receiving and recording the one or more player(s) selected by the one or more bettor(s);

assigning the remaining unselected players in accordance with the structured randomised distribution of claim 1 .

9. The system according to any one of the preceding claims, wherein the server is configured to receive information updates about the progress of the golf event in real-time.

10. The system according to claim 9, wherein the server is further configured to

communicate to the bettor interfaces said information updates in real-time.

1 1 . The system according to claim 10, wherein the bettor interfaces are configured to display players leading the golf event by highlighting or otherwise indicating said leading players on bettor devices in real-time to enable a bettor to distinguish the leading player(s) from the non-leading player(s).

12. The system according to any one of the preceding claims, wherein the system permits a bettor to swap one or more players on a ticket allocated to them.

13. The system according to claim 1 2, wherein the swap may be made during the progress of a particular golf event in real-time.

14. The system according to claim 12 or claim 13, wherein the swapping of players preserves the structured randomised distribution of players amongst bettors.

15. The system according to claim 14, wherein a first bettor may only be able to swap a player with a second bettor if the swapped players belong to the same group of players.

16. A system for enabling structured randomised betting on a golf event by a plurality of bettors, including:

a bet processor/controller,

a bet validator,

a database,

and a plurality bettor interfaces,

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event; communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s);

17. A method of enabling structured randomised betting on a golf event by a

plurality of bettors, the method including the steps of:

receiving and recording on a database input from a plurality of bettor interfaces that the plurality of bettors want to bet on the golf event; receiving data from the database including a plurality of ranked players participating in the golf event and a number of tickets to be generated;

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event; communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s). wherein the method includes the further steps of:

validating the betting action; and

18. The method of claim 17, wherein each bettor data packet includes, in relation to the bettor proposing the betting action:

a. a bettor ID corresponding to the bettor;

b. a bettor ID for each of the plurality of bettors;

19. The method of claim 18, wherein each bettor data packet further includes, in relation to the bettor proposing the betting action, one or more of the following: a. a web session ID connected to the proposed betting action;

b. the players on the ticket(s) allocated to the bettor;

c. a counter for the number of betting actions the bettor has proposed

and/or achieved;

d. a betting amount staked by the bettor in the golf event;

e. the number of holes which have been played in the golf event;

f. a flagging device to indicate when a bettor data packet includes

unauthorised data.

20. The method according to any one of the preceding claims, wherein each ticket is randomly assigned one player from each and every group such that each of the tickets is randomly assigned a number of players equal to the number of the plurality of groups.

21 . The method according to any one of the preceding claims, wherein the method includes the step of generating the number of tickets corresponding to the number of bettors so as to maximise the number of players allocated to each bettor.

22. The method according to any one of the preceding claims, wherein the includes the step of transmitting the tickets allocated to each bettor by issuing an electronic ticket to each bettor's bettor interface.

23. The method according to any one of the preceding claims, wherein includes the step of shuffling the players which are assigned to each ticket, such that observable effects of ordering of the players by ranking during operation of the method are further hidden from the bettor.

24. The method according to any one of the preceding claims, wherein the method includes the further steps of:

assigning the remaining unselected players in accordance with the structured randomised distribution of claim 17.

25. The method according to any one of the preceding claims, wherein the method includes the further step of receiving information updates about the progress of the golf event in real-time.

26. The method according to claim 25, wherein the method includes the further step of communicating to the bettor interfaces said information updates in real-time.

27. The method according to claim 26, wherein the bettor interfaces are configured to display players leading the golf event by highlighting or otherwise indicating said leading players on bettor devices in real-time to enable a bettor to distinguish the leading player(s) from the non-leading player(s).

28. The method according to any one of the preceding claims, wherein the method permits a bettor to swap one or more players on a ticket allocated to them.

29. The method according to claim 28, wherein the swap may be made during the progress of a particular golf event in real-time.

30. The method according to claim 28 or claim 29, wherein the swapping of players preserves the structured randomised distribution of players amongst bettors.

31 . The method according to claim 30, wherein a first bettor may only be able to

swap a player with a second bettor if the swapped players belong to the same group of players.

32. A method of enabling structured randomised betting on a golf event by a

plurality of bettors, the method including the steps of: receiving and recording on a database input from a plurality of bettor interfaces that the plurality of bettors want to bet on the golf event; receiving data from the database including a plurality of ranked players participating in the golf event and a number of tickets to be generated;

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

receiving data that designates the winning player(s) of the golf event; communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s).

33. A non-transitory computer-readable storage medium comprising instructions that, responsive to execution by a computer, cause the computer to implement a method or system of structured randomised betting on a golf event by a plurality of bettors, including carrying out the steps of:

distributing a plurality of ranked players into groups;

allocating at least one ticket to each of the plurality of bettors;

validating the betting action; and

34. The non-transitory computer-readable storage medium of claim 33, wherein

each bettor data packet includes, in relation to the bettor proposing the betting action:

a. a bettor ID corresponding to the bettor;

b. a bettor ID for each of the plurality of bettors;

35. The non-transitory computer-readable storage medium of claim 34, wherein

each bettor data packet further includes, in relation to the bettor proposing the betting action, one or more of the following:

a. a web session ID connected to the proposed betting action;

b. the players on the ticket(s) allocated to the bettor;

c. a counter for the number of betting actions the bettor has proposed

and/or achieved;

d. a betting amount staked by the bettor in the golf event;

e. the number of holes which have been played in the golf event;

f. a flagging device to indicate when a bettor data packet includes

unauthorised data.

36. A non-transitory computer-readable storage medium comprising instructions that, responsive to execution by a computer, cause the computer to implement a method or system of structured randomised betting on a golf event by a plurality of bettors, including carrying out the steps of: receiving and recording on a database input from a plurality of bettor interfaces that the plurality of bettors want to bet on the golf event; receiving data from the database including a plurality of ranked players participating in the golf event and a number of tickets to be generated; distributing a plurality of ranked players into groups; randomly assigning players from a plurality of the groups to the tickets on a group-by-group basis; wherein the players are uniquely assigned such that no one player is able to be assigned to more than one ticket; allocating at least one ticket to each of the plurality of bettors;

transmitting to each of the plurality of bettor interfaces the ticket(s) assigned to each bettor; receiving data that designates the winning player(s) of the golf event; communicating to a bettor via that bettor's bettor interface that they have been allocated a ticket with the winning player(s).