Wager recording method and system

Abstract

A method and system for accepting individual or group candidate wager sets is provided. A plurality of selections for candidate wagers may be received and stored. A unique identifier may be associated with the plurality of selections and used to retrieve the selections when a wager is placed.

Description

CROSS-REFERENCE AND PRIORITY CLAIM

This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Application 60/850,869, “Wager Recording Method and System, filed Oct. 10, 2006. The entire contents of that provisional application is incorporated herein by reference thereto.

BACKGROUND

Conventional lottery systems are designed with the expectation that a single person will obtain one or more wagers. Groups of people, for example families, coworkers, etc., commonly pool their money to buy lottery tickets or other forms of wagers. These groups may be formal or informal depending on the jurisdictions' rules or a particular group. Families or coworkers that desire to pool their money to buy a set of lottery tickets or buy sets of lottery tickets on a recurring basis have difficulty keeping track of times that games are played, monetary amounts contributed, and player participating. Furthermore, when wagers in a lottery game are successful, the task of distribution and notification of the members is time-consuming and can become complex of amounts contributed vary or if multiple games in different lottery game types are involved. As funds contributed and the number of players and groups increases, the complexity can be cumbersome and may even result in disputes between players. Groups are far more likely than individuals to buy large numbers of tickets and to make complicated multi-entry wagers such as lottery wheels. This makes entering, tracking, and changing their wagers more complex. Another disadvantage of group wagering is verification of purchasing of wagers and validation of wagers for collecting winnings. Typically one person buys wagers for a group and buys tickets. There is no confirmation provided to the members of the group that tickets are actually purchased and winners are not necessarily informed when winning numbers actually occur.

Players and groups may want to place complex wagers in lotteries. For example, one type of exotic bet type may be a full systems bet, where the total number of selected values exceeds the number required to win and all possible permutations are wagered. Another example exotic bet is a reduced systems bets, where the total number of selected values exceeds the number required to win but only certain combinations of selections will actually be wagered according to some pre-determined algorithm. Another example exotic bet is a wheel bet, where certain numbers are “keyed” or fixed with all the other numbers of the picks may vary around those keyed bets. A limited wheel bet, otherwise known as a wild card bet, may be another type of exotic bet, where some values are selected and one or more values are automatically generated and comprise all or some of the possible values of that selection.

Another problem is that lottery systems are typically limited in the types of wagers that may be placed at a terminal. Typically entries have to be purchased one at a time or in small groups. This often precludes more exotic bets, such as wheels, which if manually performed, would take an exorbitant amount of time for a player or a lottery agent or retailer to administer. This may deter players from entering these types of bets, which may in turn reduce the number of lottery entries and thus lottery system revenue. Moreover, if a retailer or other administrator had to manually accept these exotic bets, which could be a large number of wagers at a time, it would expend a great amount of time. Wait times at a lottery retailer would increase and may deter players from participating in the lottery.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a illustrates a diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention.

FIG. 1b illustrates an alternative diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention.

FIG. 1c illustrates another alternative diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention.

FIG. 2 illustrates an example data structure for registration, retrieval, and wager acceptance, according to an example embodiment of the present invention.

FIG. 3a illustrates a flowchart of an example procedure of a registration, retrieval, and wager acceptance system for shared wagers in a lottery game, according to an example embodiment of the present invention.

FIG. 3b illustrates a flowchart of an example procedure for creating a new account with a registration system, according to an example embodiment of the present invention.

FIG. 3c illustrates a flowchart of an example procedure for creating a candidate wager set, according to an example embodiment of the present invention.

FIG. 3d illustrates a flowchart of an example procedure for accepting a candidate wager set, according to an example embodiment of the present invention.

FIG. 3e illustrates a flowchart of an example procedure for validating entries and notifying groups of results of a wager, as well as distributing possible winnings, according to an example embodiment of the present invention.

FIG. 4a illustrates an example web page screen viewed by a player registering a candidate wager set, according to an example embodiment of the present invention.

FIG. 4b illustrates an example account management screen viewable by a player, according to an example embodiment of the present invention.

FIG. 4c illustrates an example user account creation screen, according to an example embodiment of the present invention.

FIG. 4d illustrates an example group search screen, according to an example embodiment of the present invention.

FIG. 4e illustrates an example group account creation screen, according to an example embodiment of the present invention.

FIG. 4f illustrates an example candidate wager set creation screen, according to an example embodiment of the present invention.

FIG. 4g illustrates an example candidate wager creation screen, according to an example embodiment of the present invention.

FIG. 4h illustrates an example report creation screen, according to an example embodiment of the present invention.

FIG. 5 illustrates an example playslip that a user may receive and print upon registration of a candidate wager set, according to an example embodiment of the present invention.

FIG. 6 illustrates an example screen or a potential ticket, receipt, or other proof of purchase that may be provided to a user after a wager acceptance system has accepted a wager set, according to an example embodiment of the present invention.

DETAILED DESCRIPTION

Some example embodiments of the present invention include systems and methods for facilitating the processing of wagers, e.g., lottery entries, from groups of players who buy tickets in common. A registration system enables group representatives to choose drawn numbers, coordinate payment by group members, and purchase wagers, e.g., lottery tickets on behalf of the group. In some embodiments, group members may be automatically informed of actions taken by the group representative, e.g., by e-mail or instant messaging. Some embodiments may also include provision for group members to approve, opt-in, or opt-out of wagers made on behalf of the group. To facilitate the purchase of larger groups of wagers on behalf of the group, the registration system may save candidate wagers, e.g., selections made by the group representative on behalf of the group. The group representative may then be provided with the ability to retrieve the saved candidate wagers, e.g., a playslip including an identifier or an electronic token, which can be tendered when the wagers for the group are purchased. The electronic token or playslip can then be presented when the wagers are purchased on behalf of the group, and used to retrieve the saved candidate wagers from the registration system. Purchase of wagers and wager results may be reported to group members automatically, e.g., by email or instant messaging.

Other example embodiments of the present invention include systems and methods for saving and retrieving candidate wagers or selections for a single player. These systems are particularly suitable for players making large number of wagers using exotic bet systems such as wheels, full systems bet, and the like. Automatic tools for the generation of multiple related wagers may be incorporated in the system to aid in the selection process.

An example embodiment of the present invention may include a method of managing wagers for a game by a group of players that share wagers involving receiving a plurality of selections for shared candidate wagers for the group, associating a first unique identifier with the plurality of shared selections, receiving the first unique identifier as part of a request to purchase a plurality of wagers on behalf of the group, retrieving the selections for the shared candidate wagers using the first unique identifier, and accepting wagers on behalf of the group, the wagers being placed using the retrieved selections. In addition, example embodiments of the present invention may implement methods that involve receiving a plurality of sets of shared candidate wagers for the group, associating a respective unique identifier with each of the plurality of sets of shared candidate wagers, determining the users within the group of a plurality of users that are participating in the plurality of shared, receiving a set of wager preferences for a user, adding the user to the group based on the set of wager preferences, and creating a hash of the plurality of selections for shared candidate wagers for the group.

Example embodiments of the present invention may also implement editing or modifying candidate wager sets or candidate wagers, such as modifying the plurality of shared candidate wagers in accordance with input provided by members of the group, storing information identifying the group of players that share wagers in a group registration system, receiving a signal from a first player in the group that the first player opts-in to a shared candidate wager, responsive to the signal, including the first player in the shared candidate wager and omitting a second player in the group from the shared candidate wager from whom an opt-in has not been received, receiving a signal from a first player in the group that the first player opts out of a shared candidate wager, responsive to the signal, omitting the first player from the shared candidate wager and including a second player in the group in the shared candidate wager from whom an opt-out has not been received, and storing the set of candidate wagers for the group in a registration system.

Example embodiments of the present invention may also involve interaction with or between a registration system and a wager acceptance system, such as providing to a user in the group the first unique identifier, receiving the playslip at a retailer, reading the indicia from the playslip, verifying that the user presenting the playslip to the retailer is qualified to make wagers on behalf of the group, verifying the user's age, verifying the user is from an allowed geographic region, receiving a tender of funds on behalf of the group for the purchase of the wagers, acknowledging receipt of the funds for the wagers, and producing a receipt for the funds which indicates the wagers for which the funds were tendered.

Example embodiments of the present invention may also involve notification of users, validation of wagers, and winnings distribution, such as notifying the plurality of users of the group that the wagers have accepted, determining a game outcome, determining whether the wagers are winning wagers, responsive to a determination that at least one of the wagers is a winning wager, distributing the winnings to at least one member of the group, distributing winnings directly to all the member of the group, notifying the group members if any winnings have been distributed, automatically funding a set of wagers with the winnings from previous wagers, distributing tax information to the members of the group, notifying the members of the group of a plurality of users that new candidate wager sets may be entered, notifying the members of the group of a plurality of users indicating that new wager sets may be entered when a trigger event occurs, automatically registering a pre-determined candidate wager set for the group of a plurality of users when a trigger event occurs, and automatically generating the plurality of selections based on an indication of the type of bet desired.

The selections may be entry numbers for a future draw lottery game, and the wagers may be entries in the future draw lottery game. The first unique identifier may be an identifier for the group. The first unique identifier may be provided as an indicia printed on a playslip or in electronic form. Funds may be received directly from the players in a group or individually provided by users of the plurality of users of the group in differing amounts. The proportion of winnings provided to individual users may be proportional to funds contributed by the users or the proportion provided to individual users may be in a proportion agreed to by the group. The plurality of selections may form at least one of a wheel bet, full systems bet, reduced systems bet, limited wheel bet, or a wild card bet.

Another example embodiment of the present invention may involve a method for facilitating play of a lottery game by receiving a player selection for a lottery game entry, storing the player selection in association with a unique identifier, providing the unique identifier to the player, and responsive to a player request to purchase an entry in the lottery game, receiving the unique identifier, retrieving the player selection using the received unique identifier, and entering the player in the lottery game using the retrieved player selection. The unique identifier is provided to the player as a printed indicia on a lottery playslip or the unique identifier is provided to the player in electronic form. The method may also involve automatically generating a plurality of players selections based on player input, storing the plurality of player selections automatically chosen for the player based on player input, retrieving the plurality of player selections using the received unique identifier, and making a plurality of entries in the lottery game for the player using the retrieved player selections. The plurality of automatically generating selections form may be at least one of a wheel bet, a full system bet, a limited wheel bet.

Another example embodiment of the present invention may involve a system for registering wager sets for a group, involving a storage device, wherein a user, group, and wager information are stored, a processor for calculating the proper wagers and determining winnings, and an input device for providing the user and wager information.

Another example embodiment of the present invention may involve a method for facilitating play of a wagering game by a group sharing wagers involving storing contact information for a group of players who share wagers, receiving a wager on behalf of the group, and providing automatic notification to each player in the group of the wager made on behalf of the group. The wagering game may be a future draw lottery game. The contact information may include an email address, and the automatic notification may include an email. The example method of facilitating may also involve determining an outcome for the wagering game and providing automatic notification to each player in the group of the outcome of the wager made on behalf of the group.

Another example embodiment of the present invention may involve a system for facilitating the play of a wagering game by groups who share wagers involving a registration server including a tangible computer readable medium storing information identifying the members of a group that shares wagers, a set of selections for candidate wagers for the group, and an identifier uniquely associated with at least one of the group and the set of selections, a wagering system configured to receive the identifier as part of a request to purchase a set of wagers on behalf of the group and responsive the receipt of the identifier, to cause a set of wagers using the set of selections to be entered on behalf of the group. The wagering game may be a future draw lottery game, the set of selections are entry numbers for the future draw lottery game, and the wagering system comprises a lottery terminal in communication with a lottery server. The identifier may be printed on lottery playslip. The registration server may be part of the lottery server. The registration server may be in network communication with the lottery server.

FIG. 1a illustrates a diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention. A group representative 108, who may also be a player, may coordinate with players 106 and 107 to play a lottery game. For purposes of the example two players 106 and 107 are illustrated, but a group may ordinarily have n number of players, limited only by storage space or other limitations set by a registration system or a wager acceptance system. The members of the group may want to have a shared set of wagers in which the winnings are distributed among the group. The group representative 108 may access a terminal 100, which could be a webpage on a computer, a PDA, a wireless cell phone, a kiosk in a store, or any other input device that can allow the group representative 108 to input the group representative's 108 and players' 106 and 107 identification information and wager preferences. Through a communication medium 103, e.g. a modem, DSL, cable, ethernet, wireless, etc., the user and candidate wager information and wager information may be stored in a database 105, such as on a server. The players 106 and 107 may either reimburse the group representative 108 or provide their share of the funds prior to payment by the group representative 108. Alternatively, if the registration system allowed recordation of monetary account withdrawal or payment information, the group representative 108 may be reimbursed directly by accounts held within the system or transmitted to accounts external to the registration system.

Information may be provided to the group representative 108, such as a unique registration identifier, in the form of an electronic or paper playslip. The group representative 108 may then provide 110 the unique identifier to a lottery retailer 109. The lottery retailer may input the unique registration identifier information into a wager acceptance system terminal 102. The wager acceptance system may retrieve group and shared candidate wager information, collectively the candidate wager set, from the database 105 of the registration system. The information may be transmitted over a communication medium 104, such as that of communication medium 103. Funds may be provided to the retailer 109 by the group representative 108. Alternatively, if monetary account information was stored in a database, the wager acceptance system may automatically deduct funds from the players' 106 and 107 individual account, either an internal pre-paid account within the system, wherein the system could directly credit or debit money, or outside the system, as will be described later. The retailer may check that the proper amount of funds corresponding to the candidate wager has been paid and enter the candidate wager set into the wager acceptance system.

Once the candidate wager set has been submitted, the wager acceptance system may check the candidate wager set information for errors and accept the candidate wager set. The database 105 may communicate 122 the candidate wager set information to a lottery game system 124 for final acceptance and registration of the candidate wager set into the game. When the candidate wager set has been submitted and paid for, the candidate wager set is sent back to the database to be stored as the wager set. In other example embodiments, the database 105, and the information stored in the registration system and/or the wager acceptance system, may be integrated with the lottery game system.

The group representative 108 may be provided with a paper receipt printed from the terminal and/or an electronic receipt may be transmitted to the group representative or other group user contact information, depending on the level of access that a system may have to group personal information.

After the candidate wager set has been paid for and accepted by the wager acceptance system, the candidate wager set may thereafter be saved in the registration system as a wager set, wherein the wager set is a purchased entry. An instance of the candidate wager set may also be stored, and recurring candidate wager sets may have several instances or possibly links to the same data or subsets of data. For example, in a recurring candidate wager set where much of the information was the same, e.g. users, wagers, lottery game played, amount wagered, etc., only a small subset of data would have to be stored, for example, the date of the drawing. Rather than duplicating the information requiring an enormous amount of storage space, the system may simply provide links to the data and store only the changed information, e.g. the date of the drawing.

The registration system and wager acceptance system may have direct access to the lottery game system in order to obtain the results of drawings. Validation of the wager set may occur either by the retailer 109 by checking through the wager acceptance system terminal 102, automatically by the registration system's database 105, which may notify the individual members of groups of the results, or later when the group representative checks the results 108 at a terminal 100. The wager acceptance system terminal 102 may have direct access through a communication medium 123 to the lottery game system 124. Winnings may be automatically proportioned and distributed and deposited directly into individual player accounts or winnings may be distributed to the group representative 108 with notifications sent to the other players 106 and 107 that payment was made to the group representative 108.

FIG. 1b illustrates an alternative diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention. A group representative 108 may coordinate between players 106 and 107 to submit shared wagers among the group. The group representative may enter the group and candidate wager information into a terminal 100, similar in capability to that of FIG. 1a. This may be a conventional lottery terminal, such as an Altura terminal available from GTECH corporation of West Greenwich, R.I., which has been modified to accept and process group wagers. Upon transmission of the information over a communication medium 103 to be stored in a database 111, the registration system may automatically communicate with the wager acceptance system. This particular configuration bypasses the need for a retailer 109 of FIG. 1a. The wager acceptance system automatically receives the wager set from the database 111. The wager acceptance system transmits the candidate wager set over a communication medium 125 to the lottery game server 124 to submit the entry. Upon submission, the registration system saves the candidate wager set as a wager, and optionally keeps the candidate wager set for future use. The wager acceptance system may notify the group representative 108 that the wager is accepted. If possible, the group representative 108 may immediately be notified of the results of the wager set and distribution of winnings funds may occur, similar to the methods described in FIG. 1a. An electronic or paper receipt may be provided to the group representative 108, or all the group members if it is an electronic format, such as a blackberry message, text message on a phone, recording on a phone call, etc. The wager set may be later validated and the prize distributed to the users or redeemed by the group representative alone.

FIG. 1c illustrates another alternative diagram of an example configuration of an example registration and wager acceptance system, according to an example embodiment of the present invention. A group of players 113, 114, and 115 may desire to form a group to submit a shared wager set in a lottery game. Rather than acting as representatives for each other, a group may be created by any of the players and the other players may join the created group. Each player 113, 114, and 115 may access their own terminal 116, 117, and 118 respectively. Each terminal 116, 117, and 118 may transmit information through a communication medium 119, 120, and 121, respectively. The terminals 116, 117, and 118 may have access to a database 112 of the registration system. The database 112, may be directly accessible by both a registration system, wager acceptance system and the database 112 may also draw information from the registration system and wager acceptance system as well as through a communication medium 126 from lottery game servers 127.

Because each player 113, 114, 115 has his own terminal to edit information, the systems may provide notifications more frequently to the players 113, 114, 115. Moreover, it prevents the need for deciding upon a group representative and reduces the need to take time to coordinate wagering preferences by the individual players. At any of a number points in a group recordation, a wager set registration, wager acceptance, lottery game wager submission, or lottery game validation of results, etc. a user in a group may receive notifications from the various systems involved. For example, after the creation of the group, the creation of candidate wager sets, registration of the candidate wager sets in a registration system, acceptance of candidate wager sets in the registration system, submission of the candidate wager sets to the lottery game system, validation of the wagers, and winnings distribution, notifications may be sent to the individual players 113, 114, 115.

Each player 113, 114, 115 having a personal terminal 116, 117, and 118, respectively, also allows players to opt-in or opt-out of candidate wager sets more easily. Rather than having to communicate with the group representative 108 about changes, the players 113, 114, 115 may simply make their edits at a pre-determined time. For example, there may be a specified range of time to make edits, a deadline, or the players may be notified by the registration system of appropriate times to edit their candidate wager set preferences, e.g. whether they are opting-in or opting-out, the amount they want to contribute, etc.

It may be appreciated that interaction between players, databases, registration systems, wager acceptance systems, and retailers described in FIGS. 1a, 1b, and 1c may altered by combining various aspects of the three figures. For example, in an alternative configuration, players 113, 114, and 115 may be able to access their own terminals, 116, 117, and 118, respectively, as illustrated in FIG. 1c. However, the players 113, 114, and 115 may provide a unique registration identifier to a retailer 109, rather than directly submitting a wager set to the wager acceptance system, as illustrated in FIG. 1a. The functional modules of the database, registration system, wager acceptance system, or other systems of the example embodiments may be located on a central server or may be distributed across one or more server computers, or on various terminals, or integrated with each other as appropriate.

Although each of the embodiments of FIGS. 1a, 1b, and 1c have been described for a group shared wager set, the example embodiments of the present invention may also be used for individual user registration and submission and acceptance of candidate wager sets. For example, the group representative may choose to register a candidate wager set and submit the candidate wager set for entry into a lottery game system.

FIG. 2 illustrates example data modules for registration, retrieval, and wager acceptance, according to an example embodiment of the present invention. It may be appreciated that the data modules and instructions to register and interact between the systems may be stored in a computer readable medium or storage, for example memory, a database, disk, tape, flash memory, or other media.

Players may initially want to register their own personal user 203 data. User 203 data may include a unique user identifier, contact information (e.g. name, e-mail address, phone number, mailing address, etc.), payment information (e.g. a bank account, a credit card, online payment accounts, etc.), wager set history, groups, and other data. A user's wager set history may contain past candidate wager sets or wager sets that were actually entered into a lottery game system 205, past winnings, and groups associated with those wager sets. Wager set history may also contain the individual wager 204 data for each wager set 205. Users may be members of multiple groups. Users may also have group preferences, triggers that may allow a user to join other groups with other users that may not necessarily know each other but that have the same wagering preferences.

For example, users may not personally know enough people that may want to participate in a shared wager set, or a group may want additional users in the group to increase the wager set wager amount total. The group or user may set group preferences that are triggers where if a user meets the group preference criteria, that user may be invited to be added to join the group. Or, conversely, if a group were to meet the user's criteria, the user may request to join the group. Or, the matching and joining may be automatic up to a certain user group preference that can be set to where a user automatically joins a pre-determined number of groups, or contributes a maximum number of funds, or any other number of variables of group preferences.

Group preferences may also be triggers that allow a user to automatically drop out of a group. For example, a user may be a member of a group of 10 users that has a recurring wager set of 10 automatic quick pick wagers costing $10 per person for a wager set valued at $100 for the group. If all the users in a group agree that everyone in a group should bet fifty dollars per person per wager set, whereas the funds contributed in prior wager sets was twenty dollars per person per wager set, a person may automatically be opted-out of the wager set or removed from the group completely, depending on the user's group preference triggers. If enough users' group preferences automatically opted them out of a candidate wager set, other users' group preferences may trigger, wherein their preferences required a minimum candidate wager set number of users. In such an instance, the candidate wager set would be de-activated for that drawing.

Groups 202 may contain one to n number of users and contain either links to the stored user data files, the user identifier, or the user name. The group may have a unique group identifier. A group may be recognized more easily by a group descriptor. Groups may also be comprised of multiple subgroups. For example, users in some groups may drop out and the remaining users of the groups may wish to consolidate into a larger group. Those groups may choose to keep their group information (e.g. group descriptor, preferences, user list in case they want to split off from the larger group, etc.) and thus the consolidated group may have links to the smaller subgroups. Alternatively, the registration system can be configured to automatically pull the user information and group preferences and actually consolidate the group information while deleting the smaller groups.

A group's wager history may be stored as well as wager preferences. Wager preferences of a group may contain the information needed for recurring shared wagers. For example, a wager preference may involve a frequency preference, e.g. weekly wagers, biweekly wagers, monthly, etc. A wager preference may determine the maximum or minimum wager amount total allowed in the candidate wager set. Another example variable of a wager preference may be the maximum or minimum number of users allowed in a group. For example, a group may prefer to have ten users paying thirty dollars each rather than 300 users only contributing a dollar because if they were to win, the winning pot would be divided into 300 versus only ten in the former scenario. Thus, the group wager preference for maximum number of players may be ten users. Another wager preference may be a pot threshold before the group's automatic wager submissions occur. For example, the group may determine that only pots with a payout of $100 million are worth creating wager sets and sharing a plurality of wagers.

A group may also have notification preferences. Rather than having groups automatically submit shared wagers, the group users may instead be notified that users in the group have opted-in to a wager, or that there is interest in submitting a shared wager set. Other members of the group may then be on notice of a deadline to decide whether they will opt-in (or opt-out depending on the default setting). The notification preferences may mirror the wager preferences except that while wager preferences may be automatic triggers, notification preferences may only be notices or reminders sent to the individual users. Users may have the ability to opt-in or opt-out of a wager, and the user may be automatically entered and have to opt-out, or not entered and be required to opt-in. The system may help facilitate the process by sending notifications to remind the user of his options.

Once groups and users have been registered candidate wager sets 205 may be created. A wager set 205 data module may contain a group 202 and a plurality of wagers 204. The group and plurality of wagers may be stored in the wager set, or the data may be linked to the stored wagers, or the wager set may store the group identifier and the wager identifier list. Each wager set may contain a winnings distribution method, which contains the information on how any winnings may be distributed. Examples could be direct cash payment to the group representative, automatic funds payments to the group, etc. While some distribution methods may be proportional to the funds contributed, other distribution methods may vary. A group may decide that certain occasions allow for winnings to be distributed unevenly. For example, a group may set a rule that all users that have a birthday on the week of the particular wager set drawing may get double their normal share even though those users may contribute an equal amount as all the other users of the group. Or, as another example, a family may have all the winnings go to the grandparents if the winnings are less than a pre-determined monetary amount.

Wager sets 205 may also contain the wager amount total, e.g. the cumulative amount of funds contributed to be entered, as well as the wager amount contributed, the actual funds earmarked for the particular candidate wager set. The wager amount per entry may also be stored. The total value of the wagers should not exceed the wager amount contributed in the wager set. Otherwise, the group representative would not be able to pay for the lottery game entry.

Wager sets 205 contain at least one wager 204. A wager 204 is equivalent to a single lottery pick or entry. A wager 204 may have a wager identifier and the wager 204 may also have a wager set identifier in order to link back to the wager 205 set that the wager 204 is a part of. It may be possible that the same candidate wager 204 may be utilized in multiple candidate wager sets 205. For example, a user may want to play certain numbers with five different groups of which he is a member. Rather than creating the same exact candidate wager 204 entries five times, the user may save the candidate wager and apply it to five different candidate wager sets 205. In this example, the wager 204 may store a link to several candidate wager sets 205.

A wager 204 data module may have data about a game type. For example, many states have multiple types of games with different rules and different jackpots. The game type may contain the information allowed for that particular game. For example, one game may have 5 picks with a sixth pick being a special type of pick. The possible picks may vary in the number range. For example, a user may be able to pick between the numbers 1 through 47 in one game, whereas in another game the numbers may range from 1 to 60. This type of information about the game may be stored as part of the game type information.

Wagers may also be associated with a bet type, which may explain how the numbers were picked. For example, a wager may have the numbers picked through a quick pick, meaning that the numbers are picked by a random number generator. As another example, a wager may be a saved bet type, meaning that some numbers are always played by the group or individual user, such as numbers relating to birthdays or lucky numbers. The particular wager may then always be used by the group in every wager set. Another bet type may be manual, meaning it may not have been automatically generated but was manually picked either by a single user or by the choices of multiple users of the group. Another bet type may be an exotic bet type.

There are many types of complex betting methods that may not ordinarily be allowed as direct entries in the lottery game itself, but when used may generate number groups that may be acceptable by the lottery game rules. Players desiring to enter these types of numbers would have to enter them manually, which would be very inconvenient. For example, suppose a hypothetical lottery game only allowed 3 numbers to be drawn but a group wanted to collectively pick 5 numbers. Using a full systems bet, every permutation of those numbers could be used to generate the wagers. For example, if the 5 numbers were 4, 15, 17, 29, and 30, a full systems bet would generate the following list of 9 wagers:

4, 15, 17 4, 17, 29
4, 15, 30 4, 17, 30
4, 15, 29 15, 17, 29
4, 29, 30 15, 17, 30
17, 29, 30

A user may also enter a wheel bet. For example, in the previous example, if the numbers 4 and 15 were keyed, the only possible wager combinations would be “4, 15, 17”, “4, 15, 29”, and “4, 15, 30”. In these examples, the assumption is that numbers may not be repeated.

Exotic bet types may also be matched and mixed with other bet types. For example, a full systems bet may be combined with the numbers of two saved bets to create a wager list of all the permutations containing the numbers of the wagers of saved bets. By allowing exotic bets, the example embodiment facilitates the creation of the wager lists and allows a player or group to enter wagers which perhaps may not normally be accepted by a retailer terminal.

Exotic bets may be entered as a shorthand, macro, using complex formulas or functions, or entered manually. Once a candidate wager set has been saved, it would be simple to use saved candidate wager sets as a template for future alternative candidate wager sets. Due to the ability to enter exotic bets easily, this system may be utilized by both individual users who desire to enter exotic bets as well as groups who wish to share complex bets.

The wager 204 module may also have a betting function that allows users to create exotic bet types of their own. Or, a user may be able to alter a pre-existing bet type and apply a betting function to it. For example, an example lottery game may allow 5 draw numbers and a last special pick number. A user may create a betting function using a wheel bet for the first three numbers using seven numbers, a wheel bet for the second two numbers using 5 other numbers, and a random number generator for the special pick number.

The wager 204 may also have a list of numbers picked and the entry generated. The entry generated may be the actual numbers for each entry. As explained above, lottery systems may not allow numbers to be picked beyond the capability of an entry. The numbers picked may be all the possible numbers that a user may want to use, and those numbers picked would be applied by the bet type or the betting function to create multiple wager 204 entries. Thus, a single candidate wager entry may generate multiple candidate sub-entries all derived from the same original numbers picked. This information may be stored or linked to each wager 204 data module to allow a user to determine how the entry generated values were derived.

In order to validate candidate wagers, access may be given to the lottery game system which could access the wager set 205 and determine if any of the plurality of wagers 204 contained winning entries. Results could be returned to either a retailer, user directly, registration system, etc. Alternatively, each lottery game system may send the draw numbers and that information may be stored as a lottery game 206 data module in a database accessible by a registration system or wager acceptance system. The lottery game 206 would store the game and any associated information of that game, such as the rules, past winners, past drawings, etc. Each lottery game may have draw information, such as the day, the drawn numbers, and links to winning groups (e.g. storing the groups themselves, pointers or links, or group identifier lists).

A wager acceptance system 201 and registration system 200 may be provided on the same servers or accessible from the same terminals. Alternatively, they may be distributed across servers. It may be appreciated that access to different data modules may vary between different configurations of the example embodiments of the present invention. For example, in the most open configuration the wager acceptance system 201 may be able to access all the data modules of the registration system 200. In particular, when a wager acceptance system is provided a wager set identifier, the wager acceptance may be able to retrieve the wager set 205 from the registration system and its corresponding group 202 and plurality of wagers 204. The registration system may be able to access lottery game 206 information immediately to determine if the picked numbers were a winning entry and wait for the wager acceptance system to determine that the wager set was accepted before distributing winning funds to the groups.

In an alternative configuration, the wager acceptance system and registration system may have limited access to the data modules in the other system. A closed or semi-closed configuration may be used in order to protect the data as well as the privacy of the groups and users. For example, the wager acceptance system 201 may be blinded to any group information other than the group identifier as found in the wager set 205; the registration system may be blinded to the lottery game 206; and for privacy purposes the lottery game system may be blinded to any information in the registration system and the wager acceptance system. The lottery game system may simply receive the entries picked to verify the results. It communicates to the wager acceptance system 201 the winning entries. The wager acceptance system 201 determines the wager sets 205 that have winning entries and communicates those group identifiers and winning results to the registration system 200. The registration system 200 in accesses group 202 data using the group identifier and transmits the winning information, notifications, and associated funds to user accounts. With this configuration there may be more communication relaying between the systems, but data dissemination can be protected and controlled easier and may allay fears of users that their privacy may be violated.

It may be appreciated that the variables or information stored or linked to the data modules of FIG. 2 such as a stored group 202, user 203, wager set 205, etc. are not limited to the variables listed. For example, a lottery game 206 data module may have a list of group identifiers 202 so that if there are promotions for the first lottery game or a newly created second lottery game that is similar to the first lottery game, the lottery game module may contact the groups about those opportunities. The variables listed in the example data modules may be linked or stored in another data module in alternative example embodiments of the present invention. For example, a wager set 205 may contain the winnings distribution method in FIG. 2, but in an alternative example embodiment, the group 202 may contain the data for the winnings distribution methods of the wager sets.

It may also be appreciated that the storage and accessibility of the various data modules may be altered depending on the design of the interface, storage capability, speed of the database, etc. Information in data modules may be accessed by having redundant data modules, though this may be a waste of storage space. For example, a data module of a group 202 has multiple associated users 203. The data module for the group 202 may thus store the user 203 information within the group's 202 data module. Alternatively, data modules may access other data modules by unique identifiers or data modules may store links to other related data modules. For example, a group 202 may store a list of links or pointers to users 203. Or, as another example, a group 202 may access the database by retrieving the users 203 with the corresponding unique user identifier.

FIG. 3a illustrates a flowchart of an example procedure of a registration, retrieval, and wager acceptance system for shared wagers in a lottery game, according to an example embodiment of the present invention. In 3000, if a user or player already has an account with the registration system, the user may be notified that a new drawing is upcoming. Alternatively, in 3001, the user may have settings that trigger an automatic wager and the user may be notified of such an action. The users of the group may be given a pre-determined amount of time to opt-in or opt-out of a wager before it is entered into the wager acceptance system. If a user does not have an account with the system the user may choose to create an account. If a user has an account and is not a member of a group the user may create the group and be the primary administrator of the group. Alternatively, the user may choose to join a group for a one-time shared wager. In this example, the group information may be stored solely for the purpose of playing a single wager set, and once the prize is redeemed or the drawing is completed the information is deleted. Users that do not play lottery games often may be uncomfortable with having all their information stored on a system. The one-time wager set option allows those users the opportunity to place exotic bets without necessarily having to subscribe with the registration system.

In 3002 a user may access the registration system, possibly in response to a reminder in 3000 or 3001. In 3003, the user is asked whether the user has an existing account or whether the user wants to submit a one-time wager. If yes, in 3005, the user enters the account or proceeds directly to input the wager set, as illustrated in an example procedure described in FIG. 3c. If no, in 3004, the user proceeds to input new account information for the user or the group in order to initiate a shared wager set, as illustrated in an example procedure described in FIG. 3b. Once a candidate wager set is created from at least one candidate wager entry, the candidate wager set may be registered in 3005. In 3006, the user may receive a receipt of registration and possibly a unique registration identifier or indicia in order to quickly access the wager set in the future. In 3007, after the candidate wager set is registered and the user is satisfied that the wager information is correct, the user may submit the candidate wager set to a wager acceptance system, e.g. using the wager set entry itself, a unique registration identifier, an indicia that corresponds to the wager set, etc. The wager acceptance procedure is illustrated in an example procedure described in FIG. 3d.

In some configurations of the example embodiments the wager acceptance system may be integrated by the lottery games themselves, such that acceptance by the wager acceptance system automatically enter the wagers into the lottery game and the candidate wager set is considered the approved wager set for the lottery game. In alternative example embodiments, the wager acceptance system may be part of the registration system, a retailer, or some other third party that may serve as an intermediary to verify wagers, wherein the wager acceptance system would submit the entries to the lottery system. As described above, such a system may be implemented to provide more barriers between the lottery game and the user or group data to protect user or group privacy.

After a candidate wager set has been accepted, in 3020, the user may optionally receive an electronic or paper receipt, ticket or other proof of entry. In 3008, once a drawing has occurred the winning wagers are validated. If a wager set contains winning numbers, a user or group representative may optionally tender an electronic or paper receipt, ticket or other proof of entry in 3022. In 3009, a group or user may automatically collect winnings, as illustrated in an example procedure described in FIG. 3e. In 3010, the lottery game procedure ends but may send out various notifications to the groups of the shared wager sets. For example, groups may be notified that there were no winning wager entries in the wager set. Groups may also be notified of upcoming drawings.

Depending on group preferences, winnings may trigger an automatic wager by reinvesting the winnings. For example, a group may be created because multiple users desire to increase the chance to win and split a large jackpot. While the proportion of a large jackpot, such as 100 million dollars, may be worthwhile to be distributed among 10 people, if a wager set winnings were only valued at 20 dollars, an equally proportioned payout would result in each user only receiving two dollars per user. The group may have a preference that automatically reinvests the winnings into a new wager set if the winnings were below a certain threshold. The group may be notified in 3001 and the lottery game procedure may be repeated for this new re-invested wager set. Users within the group may decide to opt-out and receive their proportion of the payout.

On the terminal or server end, a registration system, wager acceptance system, or some other monitoring system may, in 3011, respond to a trigger by automatically initiating the registration of a candidate wager set or notifying the user to submit a candidate wager set. In 3012, a registration system may be initiated. The registration system may respond to user or group inquiries, such as whether an account exists, providing a lost password, providing group lists to join, etc. In 3013, if a user is creating a new a the registration system may verify user information (e.g. checking account information, verifying valid e-mail addresses, etc.) and store the data in a database, as illustrated in an example procedure described in FIG. 3b. In 3014, after a user creates a candidate wager set, as illustrated in an example procedure described in FIG. 3c, the registration system may receive and store the candidate wager set data in a database. In 3015, a unique registration identifier may be provided to the user as a printed indicia, electronic token, e-mail, or paper slip, etc., for example, e.g. in the form of an indicia, bar code, symbol, string of characters, hash value, a combination thereof, etc. In 3016, the candidate wager set data may be accessed, in some instances using the unique registration identifier, and returned to either the user or a retailer. The candidate wager set data may be accepted by a wager acceptance system and submitted for entry into a lottery game, as illustrated in an example procedure described in FIG. 3d. The submission may be performed by submitting the playslip at a conventional lottery terminal, submitting an electronic token or making an electronic entry in jurisdictions where electronic entry is allowed, or by activating an entry button in the play system.

After acceptance in a lottery game system, the user may optionally be provided an electronic or paper receipt, ticket or other proof of entry in 3021. When the user optionally tenders a ticket, the ticket may be validated in 3023. In 3017, any one of several systems may automatically validate and distribute winnings, as illustrated in an example procedure described in FIG. 3e. In 3018, after the lottery game procedure has been completed, users or groups may be notified of upcoming games and may also receive reports of past activity. If the user or group had indicated that they only wanted to participate in a one-time shared wager set, the group data may be deleted. The candidate wager set data as well as the actual wager set data may be deleted. In some embodiments, only the contact information and other privacy information may be deleted, while other data, such as wagers amounts and numbers picked, may be stored for historical reports.

FIG. 3b illustrates a flowchart of an example procedure for creating a new account with a registration system, according to an example embodiment of the present invention. In 3100, a new account creation may be initiated. In 3101, if a new user account is being created, a unique user identifier is created and may be linked to and/or possibly stored with a user data module for the player. If not, in 3114, if a new group account is being created, then a unique group identifier is created and may be linked to and/or possibly stored with a new group data module. If neither a user nor group account is desired then the procedure may be canceled and ended in 3121.

After a new user data module is created a user's contact information may be submitted and verified in 3103. For example, a user may provide an e-mail address and an e-mail from the system may be transmitted to the user's e-mail address requiring the user to verify that the e-mail account exists and is active. In 3104, if a user wanted an advanced account, such as for future accounts or to have easy access to deposit funds, the user can continue to add further data. If not, the user may either proceed to look for a group in 3109 or create a new group account in 3114.

If the user wanted an advanced account, in 3106 the user may add monetary accounts. In 3105, the account could be internal to the lottery game system, wherein the user may contribute funds from outside sources. The internal account would be a pre-paid account that would facilitate quicker purchases. If the user did want an internal account, in 3106, the user may add external bank information, credit cards, prepaid account, etc. that would be used to purchase entries and deposit winnings. In 3107, a user would also create a password and finalize any other information. For example, a player's age of birth may be verified and if a player is under the allowed age, that player may be denied the ability to create an account. Other personal information may be submitted, for example, a mailing address, other preferences, etc. In 3108, the user data module may be stored in a database.

A user may either join an existing group or create a group. In 3110, a user may input group preferences in order to search for existing groups to join. If the user already has a unique group identifier or the name of a group to join, the user may use this in the search criteria. In 3111, a group list is generated for the user to pick from. In 3112, a user may request to join the group. If the user already knew the other group members and was provided a password, the user may enter the password to join. If the user searched for a random group to join, the group may allow any new users; on the other hand, some groups may screen new users (e.g. they may want to check past wagering history which may be allowed to be reviewed depending on the system). In these locked groups, a user may have to request a password in order to join the group. In 3113, the data relating to the user may be stored with the group, either as a link, the data itself, or a user identifier.

If a new group account was created, in 3115 a unique group identifier would be generated. In 3116, the group creator may decide whether the group would be for a one-time use or for recurring wagers. If the group were for recurring wagers, in 3117 a group descriptor would be created for easy searching, otherwise only a group unique identifier would be necessary to be provided to the users and other group members. In 3118, wager preferences, as described in the above example in FIG. 2, may be entered. In 3119, notification preferences, as described in the above example in FIG. 2 may be input. After group creation is completed, the account creation process ends in 3121.

FIG. 3c illustrates a flowchart of an example procedure for creating a candidate wager set, according to an example embodiment of the present invention. In 3200 the creation of a candidate wager set is initiated. In 3201, the candidate wager set may already be associated with the group that is creating the new shared candidate wager set. If not, the user may choose to associate the candidate wager set to be shared with one or more groups, or used singly for himself. In 3202, wager set information, such as a wager name, the desired amount wagered, or other miscellaneous information, may be added to a wager set data module. Candidate wagers may then be added to the candidate wager list, for example, if the candidate wager set did not have enough candidate wagers and was under budget for the desired wager amount total. In 3203, if more candidate wagers were desired to be added to the candidate wager list, in 3204 a candidate wager may be created. In the new candidate wager, in 3205, the lottery game may be picked. In 3206, numbers may be picked: In some situations the amount of numbers picked may exceed the amount allowed in a single lottery entry. In 3207, if the user is using an exotic bet, the user may pick a bet type or betting function in 3208 to generate numbers in 3209. The new list of candidate wager entries may be added to the candidate wager list in 3210. If an exotic bet type is not performed, the single wager entry may be entered into the candidate wager list is 3210. When there are no more candidate wager entries to add to the candidate wager list, users may have an optional opportunity to opt-out or opt-in, depending on the default setting, to specific entries or the candidate wager set. In 3212, the candidate wager set may be saved and registered with the registration system. Upon registration, the user may be provided with a receipt of the candidate wager set registration, which may include information, such as the unique registration identifier, group identifier, wagers, etc. In 3213, the candidate wager set creation procedure completes.

FIG. 3d illustrates an example flowchart of an example procedure for accepting a candidate wager set, according to an example embodiment of the present invention. In 3300, the wager acceptance procedure may be performed after the candidate wager set has been registered. In 3301, a unique registration identifier may be submitted. In a configuration where a terminal has access to both the registration system and the wager acceptance system this may be performed automatically for the user. In another example configuration, a user may have to access different screens or different terminals and input the unique registration identifier. In yet another example, the user may bring the unique registration identifier to a retailer. The retailer may then submit the unique registration identifier on behalf of the user. In some instances, to prevent errors and make the wager acceptance process quicker, indicia, such as a bar code, may be provided on the registration receipt.

In 3302, the wager set information is retrieved using the unique registration identifier. Information regarding the wager set wager amount would allow the retailer to collect the correct amount of money in 3303. In 3304, the retailer or user may submit the candidate wagers of the candidate wager set to the wager acceptance system. In 3305, if the candidate wagers are not accepted, the retailer or user may attempt to resolve the errors in 3306. The user may re-access the registration system and try to edit the group's shared candidate wager set information. In 3307, if the wager errors can not be resolved, in 3308, the retailer may initiate a separation of the candidate wager set, wherein the candidate wagers that are acceptable are kept with the original wager set, and the registration system is informed to create a new second candidate wager set with the candidate wagers containing errors, to allow the user to resolve the errors later. In another embodiment, the second candidate wager set is automatically sent to a system administrator to try to resolve. In 3309, the user is refunded the value of the wager amount of the second candidate wager set containing the errors. In 3314, if there are no candidate wagers left in the original candidate wager set that could be accepted, the wager acceptance procedure ends in 3310.

If the originals could be accepted in 3305, the errors could all be resolved in 3307, or if there are remaining wagers in the original error set that did not have errors in 3314, the accepted wagers are optionally hashed and the user may be provided a hash receipt in 3311. In 3312, the user may be provided an electronic or paper receipt or pay slip containing information, such as the hash receipt in 3311, information containing the wagers approved, drawing information, group members, etc. In 3313, the user may have the opportunity to notify the other members of the group, and this may be performed over e-mail, phone recording, notification on blackmail, RSS feed, etc. In 3310, the wager acceptance procedure ends.

FIG. 3e illustrates a flowchart of an example procedure for validating entries and notifying groups of results of a wager, as well as distributing possible winnings, according to an example embodiment of the present invention. A lottery game system, retailer, or user may initiate a verification of the wagers in a wager set. In 3601, the wagers are submitted after a drawing has been completed and the wager entry numbers are compared to the drawing numbers. The system automatically checks for the winning number 3602. If the wager is a winner, in 3604, the amount won is added to a tally. If the wager is not a winner, in 3603, there is a check to see if the wager list is empty. While the wager list is not empty, the procedure in 3602 is repeated. In 3605, after the wager list is empty and all wager entries have been compared to the lottery game drawing, the system will have a tally of total winnings for the wager set.

Other variations of the validation process may be allowed. For example, the users themselves can sort through their wager list to determine if they won and bring their wagers into be validated. For another example, the system may notify a group's users of the validated wagers that are winning entries.

There may be several methods for prize redemption. In 3605, the system checks whether the group has the ability to have automatic distribution, e.g. if money account information was provided. If yes, in 3607, the money is automatically proportioned and provided to the users. In some configurations, the money may have to first be sent to the registration system which would have the group data to determine how the distribution preferences were set. In other instances, the group may have designated a group administrator to receive the money by validating the entries or having a retailer validate the entries of the wager set. The group administrator would thereafter distribute the funds. If there is no automatic distribution, in 3606 the users are notified that they have winnings and how to claim their money. In 3608, the validation and distribution procedure ends.

FIG. 4a illustrates an example web page screen viewed by a player registering a wager set, according to an example embodiment of the present invention. FIG. 4a may be the main page of a lottery game website, an offline application, a terminal in a lottery kiosk, etc. An introductory title 4000 indicates that the page is related to group wagering and complex bets. If a user has an account in the system, the user may enter his login and password 4002. On the other hand, if the user must create a new account, the user may click on a button or html link for “Create Account” 4003.

There may be static information on the introductory page that a user may search through, such as a Participating Lottery Game List 4001. The Participating Lottery Game List 4001 may allow the user to view all the potential lottery games that the system which would allow the user to create shared wager sets. Some lottery games may participate fully, for example, allowing for registration of groups, acceptance of group wagers, notification of users, distributing payouts and maneuvering funds in user accounts. Other systems may be partial participants, allowing registration of groups and acceptance of group wagers, but may only distribute a payout to a single player who would have to distribute the money to the group on his own. The Participating Lottery Game List 4001 may also display that list to the user. While the registration system and wager acceptance systems may be utilized by groups to share wager sets, the systems may also be utilized for single users. It may also be possible that some participating lottery games may only allow group bets, and some that don't allow the shared wagers. The Participating Lottery Game List 4001 may also advertise these various types of lottery games to the users.

Other static information, such as a list of the Most Popular Lottery Games 4001 may be displayed, providing the lottery game information, such as the lottery game's name, current jackpot, and next drawing.

FIG. 4b illustrates an example account management screen viewable by a player, according to an example embodiment of the present invention. Upon logging in or creating an account, the system may display account management links or buttons. A reference to the user's or account's name 4100 may be displayed so that the viewer of the page knows that he has accessed the correct account. The user may have the option of editing 4103 existing information. For example, user profile info, group info, active (meaning that the drawings have not occurred yet) wager sets, and active wagers. A user may also access links to join groups 4104 or create a new group 4105. The user may also access reporting information 4101, manage group subscriptions 4102, and view past wagers in a wager history report 4104. The user may manage funds 4106, such as changing or adding credit cards, registering an internal account, or verifying bank account direct deposits and withdrawals. The user may obtain a transaction report 4108 of the monetary accounts. The account management page may also display the current amount 4107 that the user has in the system. The user may also manage wagers 4109, in particular creating a new wager set, creating a new wager, saving a wager set, or saving wagers. The saved wagers may be recurring wager sets but may also be useful for non-recurring wager sets that are used on a more infrequent basis.

FIG. 4c illustrates an example user account creation screen, according to an example embodiment of the present invention. A user may provide a username 4200 or login name and a password 4203. Some text boxes may have indicia, such as a different color, that are required by the user to fill in such as the username and password 4201 and 4202 in this example. However, in other systems, the username and password may not necessarily be required if there are other methods for the user to access his account. Other text boxes may be provided for the user to save data in the user data module, such as a date of birth 4204, e-mail 4205, a phone number 4206, and mailing address 4208. If the user input a date of birth that was not allowed to play the lottery the user may be denied the ability to create an account. The e-mail address 4205 may have a text box 4207 that requires input in this example embodiment only because the groups utilize a username and e-mail address to register the users into the group. In other example embodiments the phone number 4206 may be the required contact info. A user may choose to add 4210 to the add money account 4209, wherein the user may choose from a credit card, an internal account that the user would register for, or a bank account. A user may also join a group 4211 or create a new group 4212. As the user creates groups in the screen the list of groups joined may be listed in a group's added list 4213. A user may also choose to save personal wager sets 4214 in which to place complex bets rather than joining a group to enter a shared wager set. When the user has completed inputting the various features of the user account, an input may be provided to save 4214 the information in a user data module in a database.

FIG. 4d illustrates an example group search screen, according to an example embodiment of the present invention. This screen may be accessible when a user wants to join a group, either one randomly, according to certain criteria, or one that the user received an invitation. If a user was searching randomly or according to certain criteria, the user may choose to fill in as many as the variables provided, such as the lottery game played 4300, the size of the group 4301 between a minimum 4302 and maximum 4303 number of players, the jackpot minimum 4304, the geographic region 4305, and activity level 4306. The activity level 4306 may indicate the frequency in which the group submits entries into lottery games. For example, some groups play on every draw while others may rarely submit entries. Other variables may be added to the group search screen to provide additional narrowing criteria.

If a user was intending to join a specific group or received an invitation to join a group, the user may enter either a unique group identifier 4307 or a group name 4308. A group name 4308 may not be unique but the user would be able to search for the desired group in the search list generated 4311. When a user has input the search criteria, a user may save 4309 the search. Saved searches may be accessed later in a search history 4316 drop down box. The user can activate a search button 4310 which would result in the display of a search list 4311. The number of groups found 4315 may also be displayed. The list can be sorted 4312 by the variables previously submitted by the user. If the user does not find a group to join, the user may be prompted to create a group 4314.

FIG. 4e illustrates an example group account creation screen, according to an example embodiment of the present invention. A group account data module may be able to store a group name 4400, password for the group 4401, and a user list 4402. The user list 4402 may contain the names and e-mail addresses of the users, though other identifiers may be allowed. A group may add users 4406, a search for users 4405 may allow a group to find and invite users that fit the criteria of the group, or a checkbox accepting new users 4403 may keep the group open to allowing users to find the group. A settings button 4404 may allow the group to provide preferences such as wager preferences, notification preferences, distribution preferences, or other group preferences. A group may want to only be associated with one recurring 4407 wager set. In such a case, the group may want to be registered only so long as the wager set is being played.

An expanded window 4408 may provide information on the duration of the group and the frequency the group would submit its associated wager sets for acceptance. For example, the group may be created for a one time entry. On the other hand, a group may have a start date 4409, end date 4410, frequency of wagers 4411, no end date 4412, or a specified number of wagers 4413 before the wagers do not recur. A group can also choose the method of initiating new wagers, either by a notification to the users to join each candidate wager 4414 or an automatic wager set submission 4415 with the ability for users to opt-out if they choose. After the information has been provided, the group information may be saved 4416 in a group data module in a database.

FIG. 4f illustrates an example candidate wager set creation screen, according to an example embodiment of the present invention. A text box may be provided for a wager set name 4500. A group identifier may already encoded 4501 if the candidate wager set is being created by a group. The candidate wager set may be associated with multiple other groups 4502. A candidate wager set may have multiple candidate wagers, shown in a candidate wager list 4503, where more candidate wagers may be created or added 4506. The total value 4504 of the wager amount of the candidate wager set is displayed. Users may have the opportunity to opt-in or opt-out. A user list may show the various players 4507 and 4508 and those players may opt-in 4509 or opt-out 4510 of the lottery game. Users may provide the amount they would like to contribute to the wager set 4510 as well as the distribution 4511 if there are winnings. For example, a player that contributes a significant amount may receive a higher proportion than the money contributed, such as 50% 4512, whereas most other members of the group may be distributed the winnings in proportion 4513 to their contribution. For example, a player that contributes 25% of the wager amount would receive a proportion of 25% of the winnings. If there is not enough contribution from the players a Funds Needed box 4514 would indicate the difference in the wager set total value 4504 and the sum of the contributions 4510. A candidate wager set may be saved 4516 in a wager set data module and a receipt may be printed 4511 containing a unique registration identifier or some indicia.

FIG. 4g illustrates an example candidate wager creation screen, according to an example embodiment of the present invention. A wager set list may be listed may be considered as a standalone wager 4600 or may be a variable wager that is used in multiple wager sets. A wager may have a specific game 4601 type, have a specific bet type used, bet function 4603, numbers picked 4604, and the date of the drawing 4605. Users maybe have the option to design a bet 4606 or betting function 4607. Users may add additional numbers picked from an add number button 4608. A generate 4609 button may be activated to generate entry numbers 4610 from the numbers picked 4604, bet type 4602, and betting function 4603. When the numbers and entries are generated the wager may be saved 4611.

FIG. 4h illustrates an example report creation screen, according to an example embodiment of the present invention. The report creation screen can contain historical information, such as past wagers 4700 and amounts won 4701 for those wagers. Information and reporting may also be displayed on a group level 4702 such as the total amount earned 4703. These and other results may be displayed to a user in various graphs, charts and tables depending on the variables requested.

FIG. 5 illustrates an example playslip that a user may receive and print upon registration of a candidate wager set, according to an example embodiment of the present invention. In indicia 500, such as a bar code, may be printed. The bar code may contain the actual candidate wager set information, the information needed to retrieve the wager set information, or the encoded unique registration identifier of the candidate wager set. In another example embodiment, the unique registration identifier may be provided or some other indicia, such as a symbol, may be utilized. The unique identifier 501 and the candidate wagers 502 may be displayed. However, in other example embodiments, that information may not be provided unless requested by the user. This may be because in typical shared candidate wager sets, the list of candidate wagers may be extremely long and may not fit onto a single pay slip.

FIG. 6 illustrates an example screen or a potential ticket, receipt, or other proof of purchase that may be provided to a user after a wager acceptance system has accepted a wager set, according to an example embodiment of the present invention. The screen may verify the wager set accepted 600, the amount wagered 601, the lottery game(s) played 603, and the entries submitted 603. The wager set symbol accepted 600 may be a transaction id, a unique receipt identifier, a symbol, or other indicia. The user may also be provided a separate bar code 605, with which the user or retailer may use to validate a wager set entry. The user, either the player or the retailer depending on the configuration of the system, may indicate whether or not to notify the rest of the group 604 that the wager set has been accepted and submitted for entry into the lottery game systems. This screen may appear on the location of the submission, but if notification of group members is in effect or if the notification button 604 is activated, the same information on the screen may appear in e-mail messages to the group, sent to a cell phone as a recording, e-mailed to a blackberry, or a link to a webpage that may be retrieved may also be sent.

Although the example embodiments have been described with reference to lottery games, it will be appreciated that example embodiments of the present invention may also be applicable to other wagering games, for example, horse racing, sports betting, online casino games, etc.

It will be appreciated that all of the disclosed methods, games, and procedures described herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer-readable medium, including RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be configured to be executed by a processor, which when executing the series of computer instructions performs or facilitates the performance of all or part of the disclosed methods, games, and procedures.

Several example embodiments of the present invention are specifically illustrated and described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.

Claims

1. A method of managing wagers for a game by a group of players that share wagers, comprising:

receiving a plurality of selections for shared candidate wagers for the group;

associating a first unique identifier with the plurality of shared selections;

receiving the first unique identifier as part of a request to purchase a plurality of wagers on behalf of the group;

retrieving the selections for the shared candidate wagers using the first unique identifier;

accepting wagers on behalf of the group, the wagers being placed using the retrieved selections.

2. The method of managing of claim 1, wherein the selections are entry numbers for a future draw lottery game, and wherein the wagers are entries in the future draw lottery game.

3. (canceled)

4. The method of managing of claim 1, further comprising:

receiving a plurality of sets of shared candidate wagers for the group;

associating a respective unique identifier with each of the plurality of sets of shared candidate wagers.

5. The method of managing of claim 1, further comprising:

determining the users within the group of a plurality of users that are participating in the plurality of selections of shared candidate wagers.

6-9. (canceled)

10. The method of managing of claim 1, further comprising:

receiving a signal from a first player in the group that the first player opts-in to a shared candidate wager;

responsive to the signal, including the first player in the shared candidate wager;

omitting a second player in the group from the shared candidate wager from whom an opt-in has not been received.

11. The method of managing of claim 1, further comprising:

receiving a signal from a first player in the group that the first player opts out of a shared candidate wager;

responsive to the signal, omitting the first player from the shared candidate wager;

including a second player in the group in the shared candidate wager from whom an opt-out has not been received.

12-16. (canceled)

17. The method of managing of claim 1, further comprising:

providing to a user in the group the first unique identifier, wherein the first unique identifier is provided as an indicia printed on a playslip;

receiving the playslip at a retailer;

reading the indicia from the playslip; and

verifying that the user presenting the playslip to the retailer is qualified to make wagers on behalf of the group.

18-24. (canceled)

25. The method of managing of claim 1, further comprising:

notifying the plurality of users of the group that the wagers have accepted.

26-27. (canceled)

28. The method of managing of claim 1, further comprising:

distributing winnings directly to all the member of the group.

29-35. (canceled)

36. The method of managing of claim 1, further comprising:

automatically registering a pre-determined candidate wager set for the group of a plurality of users when a trigger event occurs.

37. The method of managing of claim 1, receiving the plurality of selections from a group representative.

38-39. (canceled)

40. A method for facilitating play of a lottery game:

receiving a player selection for a lottery game entry;

storing the player selection in association with a unique identifier;

providing the unique identifier to the player; and

responsive to a player request to purchase an entry in the lottery game, receiving the unique identifier, retrieving the player selection using the received unique identifier, and entering the player in the lottery game using the retrieved player selection.

41. The method for facilitating of claim 40, wherein the unique identifier is provided to the player as a printed indicia on a lottery playslip.

42. The method for facilitating of claim 40, wherein the unique identifier is provided to the player in electronic form.

43. The method for facilitating of claim 40, further comprising:

automatically generating a plurality of players selections based on player input;

storing the plurality of player selections automatically chosen for the player based on player input;

retrieving the plurality of player selections using the received unique identifier;

making a plurality of entries in the lottery game for the player using the retrieved player selections.

44. The method of facilitating of claim 43, wherein the plurality of automatically generating selections form at least one of a wheel bet, a full system bet, a limited wheel bet.

45. (canceled)

46. A method for facilitating play of a wagering game by a group sharing wagers, comprising:

storing contact information for a group of players who share wagers;

receiving a wager on behalf of the group; and

providing automatic notification to each player in the group of the wager made on behalf of the group.

47. The method of facilitating of claim 46, wherein the wagering game is a future draw lottery game.

48. The method of facilitating of claim 46, wherein the contact information includes an email address, and the automatic notification includes an email.

49. The method of facilitating of claim 46, further comprising:

determining an outcome for the wagering game; and

providing automatic notification to each player in the group of the outcome of the wager made on behalf of the group.

50. A system for facilitating the play of a wagering game by groups who share wagers comprising:

a registration server including a tangible computer readable medium storing information identifying the members of a group that shares wagers, a set of selections for candidate wagers for the group, and an identifier uniquely associated with at least one of the group and the set of selections; and

a wagering system configured to receive the identifier as part of a request to purchase a set of wagers on behalf of the group and responsive the receipt of the identifier, to cause a set of wagers using the set of selections to be entered on behalf of the group.

51. The system of claim 50, wherein the wagering game is a future draw lottery game, the set of selections are entry numbers for the future draw lottery game, and the wagering system comprises a lottery terminal in communication with a lottery server.

52. The system of claim 51, wherein the identifier is printed on lottery playslip.

53. The system of claim 50, wherein the registration server is part of the lottery server.

54. The system of claim 50, wherein the registration server is in network communication with the lottery server.

55-56. (canceled)