US20130029759A1

US20130029759A1 - Global Pool Betting

Info

Publication number: US20130029759A1
Application number: US13/193,521
Authority: US
Inventors: James Sene
Original assignee: INTERNATIONAL MOBILE SPORTSBOOK CO SL
Current assignee: SOLOMO 365 Sarl; SOLOMO365 SARL
Priority date: 2011-07-28
Filing date: 2011-07-28
Publication date: 2013-01-31

Abstract

In some implementations of global pool betting, bets can be received at multiple regional servers, each serving a different geographical region. Bets can be initiated, and subsequently transmitted to a regional server, as text messages (e.g., short message service (SMS) messages) at the regional server. A regional server can process the bets and add bet amounts to a regional betting pool accordingly. The bets can be collected at the regional server over a configured period of time. When the configured period of time has elapsed, the regional server can transmit information defining the regional betting pool to global server where the regional betting pool can be added to a global betting pool containing bets from other regional betting pools.

Description

TECHNICAL FIELD

The disclosure generally relates to electronic betting systems.

BACKGROUND

Electronic betting systems are ubiquitous in today's networked world. Internet gambling is readily accessible to anyone with an internet connection. Internet gambling systems can provide users of the internet gambling system an opportunity to place bets on card games, sporting events, and many other types of events.
The popularity of gambling is world-wide. However, the ability for users to participate in gambling events is sometimes limited by the technology available to users. For example, some users may not have access to the internet and, therefore, cannot participate in internet-based gambling.
Electronic betting systems sometimes employ betting pools for each gambling event. For example, a gambling event can provide users an opportunity to bet on a sporting event. Bets placed by multiple individuals can be combined into a betting pool, which is then used to pay off any winning bets that make up a portion of the pool. For example, as more bets are added to the betting pool more money can be won by users who place winning bets. However, the quantity of users who can participate in a gambling event and, therefore, the size of the betting pool, can be limited based on, among other things, geographical or locale characteristics. For example, electronic infrastructure, currency conversion rates and language barriers may limit contributors to a betting pool to a particular geographic region.

SUMMARY

In some implementations of global pool betting, bets can be received at multiple regional servers, each serving a different geographical region. Bets can be initiated, and subsequently transmitted to a regional server, as text messages (e.g., short message service (SMS) messages) at the regional server. A regional server can process the bets and add bet amounts to a regional betting pool accordingly. The bets can be collected at the regional server over a configured period of time. When the configured period of time has elapsed, the regional server can transmit information defining the regional betting pool to global server where the regional betting pool can be added to a global betting pool containing bets from other regional betting pools. For example, the information defining the regional betting pool can include the funds available in the regional betting pool. Thus, the regional server can electronically transfer the funds in the regional betting pool to the global server so the funds can be added to the global betting pool. The regional server can receive a portion of a global betting pool from the global server. For example, the regional server can receive an electronic funds transfer of a portion of the funds in the global betting pool that corresponds to an amount won by users of the regional server. The regional server can then distribute the received portion to winning users and send notifications to individual users indicating their respective win or loss status.
In some implementations, funds are not transferred between the regional server and the global server. For example, the regional server can transmit information indicating the amount of funds in the regional betting pool without actually performing an electronic funds transfer. Likewise, winnings from the global betting pool may not be actually transferred to the regional server. For example, if the regional pool funds for a game were not transferred to the global server, the global server may not need to transfer funds to the regional server to cover the bets of the winning users. The global server can merely transmit information to the regional server indicating the outcome of the game to the regional server and the regional server can distribute winnings to users out of the regional betting pool funds retained at the regional server.
In some implementations, regional betting pools can be received from regional servers at a global server and the global server can add the regional betting pools to a global betting pool. The global server can determine an outcome of a game associated with the global betting pool and transmit portions of the global betting pool to the regional servers based on the outcome of the game.
Particular implementations may provide one or more potential advantages. For example, because bets can be made using a communication channel other than over the Internet (e.g., via SMS messaging), a user need not access to the Internet to participate in electronic gambling. Moreover, because individual bets can be pooled (e.g., on a global basis), a user may have an opportunity to win more money by participating in a global betting pool.
Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and potential advantages will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example of a global betting system.

FIG. 2 illustrates an example hierarchy of components of the global betting system.

FIG. 3 is a flow diagram of an example process for handling bets at a regional server.

FIG. 4 is flow diagram of an example process for handling bets at a global server.

FIG. 5 is a block diagram of an example system architecture implementing the features and processes of FIGS. 1-4.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG. 1 illustrates an example of a global betting system. In some implementations, the global betting system of FIG. 1 can be configured to process bets placed by users at a regional or local level and combine the bets with bets places by users at other regions or locales. For example, regions 100, 120 140 and 150 (illustrated by dashed boxes) can represent different countries, regions or locales where pooled betting is made available by the global betting system described herein.
In some implementations, each region 100, 120, 140 and 150 can include regional subsidiaries 102, 122, 142, 162 and 180. In some implementations, regional subsidiaries can provide hardware and software necessary to provide users access to electronic gaming and gambling. For example, the regional subsidiaries 102, 122, 142, 162 and 180 can represent servers running software that allow users to place bets on various types of games. Each of the regional subsidiaries can be configured to provide regional games 104, 124, 144, 164 on which a user can bet. For example, the games can correspond to real life sporting events (e.g., football, baseball, cricket, etc.). The regional subsidiary (e.g., server) can be configured to present the games to users, receive bets from users and process the bets by debiting user's accounts and adding bet amounts to a regional betting pool.
Users can place bets with the regional subsidiaries in a variety of ways. In some implementations, bets can be placed from a mobile device (e.g., a mobile phone, smart phone, laptop, etc.). The bet can be placed from the mobile device using an internet connection or using short message service (SMS) messaging, for example. In general, essentially any suitable messaging protocol can be used depending on network and subscriber equipment capabilities and requirements—for example, MMS (Multimedia Message Service,) EMS (Extended Message Service), J-Phone's SkyMail, NTT Docomo's Short Mail, or the like.
In some implementations, a user can employ mobile phone 106, 126, 146 or 166 to place a bet to local regional subsidiary 102, 122, 142 or 162, respectively. In some implementations, the user can use mobile phone 106, 126, 146 or 166 to send an SMS message to the local regional subsidiary. The SMS message can be formatted to provide bet information for placing a bet on a game. For example, the SMS message can include a game identifier, an amount of currency to be bet, a user identifier, a mobile device identifier and/or an identifier for a banking account from which the amount of currency should be debited from. In some implementations, a game 104, 124, 144, 164 can correspond to a sporting event. For example, game 104 can correspond to a football (i.e., soccer) match where two teams are competing against each other. In some implementations, the SMS message can contain an identifier identifying a team that the betting user thinks might win the match. In some implementations, the betting user can indicate a tie between competing teams by including identifiers for both teams in the SMS message.
In some implementations, a betting user can format (i.e., compose) the SMS message on mobile phone 106, 126, 146 or 166 and send the SMS message to local regional subsidiary 102, 122, 142 or 162, respectively. For example, mobile phone 106 can transmit the SMS message to transmitter tower 108 (e.g., cell phone tower). Transmitter tower 108 can receive the SMS message and transmit the SMS message to gateway 110 for transmission through network 112 (e.g., Internet, wide area network, virtual private network, local area network, etc.) to local regional subsidiary 102.
In some implementations, a user can place a bet with a subsidiary through computing device 132 (e.g., a laptop, tablet, or other computing device). For example, a user can use computing device 132 to format and transmit an SMS bet message as described above. A user can use computing device 132 (or 152) to format a bet message (e.g., an SMS message, e-mail, etc.) and transmit the message through internet service provider (ISP) 134 (or 154). ISP 134 (or 154) can receive the bet message and transmit the bet message to regional subsidiary 122 (or 142) through network 112. In some implementations, the bet message generated on and transmitted from computing device 132 (or 152) can contain the same information as described above for the SMS bet message.
In some implementations, a subsidiary can provide a global game that users from different regions can bet on. For example, local regional subsidiaries usually can provide games for local or regional users to bet on. The local games are associated with local or regional betting pools that contain the bets placed by local or regional users. However, in some implementations, a game provided by a regional subsidiary can be configured to allow users from other regions to bet on the game. In some implementations, a game that is configured to allow users to place bets from other regions is called a “global game” and the betting pool associated with the global game is a “global betting pool.” For example, subsidiary 180 in region 160 can provide a global game 182 that allows users in regions 100, 120 and 140 to bet on global game 182. The bets received for global game 108 can be collected into a global betting pool at subsidiary 180.
In some implementations, a user can place a bet on a global game through local regional subsidiary 102, 122, 142 or 162. For example, local regional subsidiary 102, 122, 142 and/or 162 may serve as a gateway to global game 182 at subsidiary 180. Each local subsidiary can receive bets for global game 182 from users in the same locale or region as the respective local regional subsidiaries 102, 122, 142 and 162, using the bet placing methodology described above (SMS, e-mail, mobile phone, computing device, etc.). However, for global game 182, each local regional subsidiary 102, 122, 142 and 162 can serve as an intermediary for collecting local bets, pooling local bets and performing accounting operations (e.g., crediting or debiting user accounts). Once the local regional subsidiary 102, 122, 142 or 162 processes the bets locally, the local regional subsidiary 102, 122, 142 or 162 can transmit the local regional betting pool generated at the local regional subsidiary 102, 122, 142 or 162 to subsidiary 180 so that the regional betting pool can be added to a global betting pool corresponding to global game 182. For example, the regional betting pool generated at subsidiary 102 can be transmitted from subsidiary 102 to subsidiary 180 through network 112. Transmission of the regional betting pool can include transmitting data that defines the regional betting pool. Transmission of the regional betting pool can include performing an electronic funds transfer of the funds in the regional betting pool. For example, the funds for the regional betting pool can be electronically transferred from subsidiary 102 to subsidiary 180. Once received, subsidiary 180 can add the regional betting pool to a global betting pool corresponding to global game 182.
In some implementations, once global game 182 is finished (e.g., a winner of the contest, sporting event, etc., is determined), subsidiary 180 can determine portions of the global betting pool to transmit back to the respective local subsidiaries 102, 122, 142 and/or 162. For example, local subsidiary 102 will receive a portion of the global betting pool based on the number and amount of winning bets places at local subsidiary 102. For example, the portion of the betting pool can be transferred from subsidiary 180 to subsidiary 102 by electronic funds transfer. Once local regional subsidiary 102 receives the portion of the global betting pool, subsidiary 102 can determine which betting users are winners and which a losers. Subsidiary 102 can electronically credit the accounts of the winners from the portion of the global betting pool. Subsidiary 102 can transmit notifications to all betting users to notify the users of their win or loss status with respect to global game 182. For example, the notifications can be transmitted according to the method used (e.g., SMS, e-mail, etc.) by the betting user for placing the bet on global game 182.
FIG. 2 illustrates an example hierarchy of components of the global betting system 200. In some implementations, a user device (e.g., user devices 202-218) can communicate with mobile operators or ISPs (e.g., mobile operator/ISP 220-224) in order to place bets at a regional subsidiary (e.g., regional subsidiary 230-240). Bets placed by users of devices 202-218 can be aggregated into country betting pools 250, 252 and/or global betting pool 260.
In some implementations, user devices 202-240 can include mobile devices, such as laptop computers, handheld computers, mobile phones, smartphones, or any other mobile computing device. In some implementations, user devices 202-240 can include desktop computers, workstations, etc. A user of user devices 202-240 can generate bet messages using user devices 202-240. For example, user devices 202-240 can be used to generate SMS messages, e-mail messages or any other type of message that can be formatted to include bet information. In some implementations, bet information sent in a bet message can include information that identifies the user placing the bet, the amount of the bet, an account for debiting the bet amount, a game (e.g., a particular football match) associated with the bet and a predicted game result (winner, loser, tie, etc.).
In some implementations, the bet message can be transmitted from the user device to a mobile operator or ISP. For example, if the user device is a mobile phone with SMS capability, the bet message can be an SMS message sent to a mobile operator (e.g., a mobile phone service provider). If the user device is a laptop computer, the bet message can be an e-mail sent to an ISP for transmission to a regional subsidiary operator. For example, user device 202 can generate a bet message and transmit the bet message to mobile operator/ISP 220. Mobile operator/ISP 220 can then transmit the bet message to regional subsidiary 230, 232, 234. For example, the regional subsidiary 230, 232, or 234 can be identified based on an identifier (e.g., a telephone number) associated with a particular game offered by the regional subsidiary. For example, a user of a mobile device can send a SMS message to a telephone number associated with a particular game to place a bet on the particular game.
In some implementations, bet messages transmitted to a regional subsidiary (e.g., regional subsidiary 230-234) are processed at the receiving regional subsidiary. For example, when a bet message (e.g., SMS, e-mail, etc.) is received, the bet message can be parsed to determine the parameters of the bet. The parameters of the bet can identify the user placing the bet, a user account for debiting a bet amount, information identifying a result of the game, and an amount (e.g., the amount of money or currency) to be bet on the game, among other things.
Once the bet parameters are parsed from the bet message, the regional subsidiary can generate a regional betting pool based on the received bet parameters. For example, the regional subsidiary can perform accounting operations to debit a user's bank account, or other account, for the amount of currency specified in the received bet message. The regional subsidiary can then add the bet amount to a regional betting pool associated with the game identified in the bet message. The betting pool can be associated with metadata identifying users who have placed bets, the predictions (e.g., game outcomes, winners, losers, ties, etc.) made by the betting users, and the amount of currency wagered on each game.
In some implementations, the game is a regional game that is only available to users who place bets within a particular region. For example, a region can correspond to a geographical area (e.g., a country). A region can correspond to a portion of a country. A region can correspond to coverage areas of a particular ISP or mobile operator. A region can correspond to an area associated with a set of telephone numbers, IP addresses or any other criteria that can be used to divide a geographical area among various regional subsidiaries. A regional subsidiary processes bets placed by users and user devices within the geographic region associated with the regional subsidiary.
In some implementations, a country or a global game can be created that allows users from different regions to place bets on the same game. In some implementations, the global game can be associated with a global betting pool that includes bets placed by users from various and different regions. For example, with a country game/pool (e.g., country game 250, 252) or global game/pool 260, the regional subsidiaries still process the user's bets as described above. The regional subsidiaries perform operations to collect the bet messages and perform accounting operations to debit user's accounts and generate local or regional betting pools. However, the local or regional betting pools are associated with the global game, not a regional game.
In some implementations, once the bets for the global game are collected and processed at a regional subsidiary (e.g., regional subsidiary 230), the regional betting pool for the global game generated at subsidiary 230 can be transmitted to the host of the country game (250, 252) or global game 260. For example, the host of a country game can be any of the regional subsidiaries that exist within the geographic area of the country. Referring to FIG. 2, any of the regional subsidiaries 230, 232 or 234 can host a country wide game because they are within the geographical region of the country represented by country 250. Similarly, the host of a global game can be any regional subsidiary 230-240, as each of the subsidiaries is within the global geographical region. In some implementations, country games 250, 252 and/or global game 260 can be hosted on specialized computing devices that are not associated with a regional subsidiary 230-240. For example, the global pool betting system 200 can include a computing device that is configured to only provide global games and to only manage global betting pools.
In some implementations, the regional betting pool for the global game is transmitted from a regional subsidiary to the global game host along with metadata associated with the regional betting pool. For example, the metadata can include user information identifying users who have placed bets at the regional subsidiary for the global game. The metadata can include the bet parameters (e.g., winners, losers, tie, game identifier, amount of money bet, etc.). The funds associated with the regional betting pool can be transmitted to the global game host from the regional subsidiary through an electronic funds transfer.
In some implementations, the identity of the betting users is not transmitted to the global game host to protect the anonymity of the betting users. For example, since the regional subsidiary performs all of the accounting (e.g., debiting and crediting user accounts) there is no need for the global game host to know the identity of the betting users so user identification information may not be transmitted. Instead, the regional subsidiary can generate anonymous identifiers associated with each bet so that the global game host will have enough information to determine an amount of money to transmit back to the regional subsidiary when the game is over. For example, the global game host may only need to know that three betting users from regional subsidiary 232 won $500 each so that the global game host can allocate $1500 to regional subsidiary 232 from the global betting pool. In this example, the global game host does not need the identification of the particular winning users, the global game host just needs to know how much of the global pool to transmit back to regional subsidiary 232 so that regional subsidiary 232 can distribute the winnings to the appropriate winning users.
In some implementations, currency bet on a global game at a regional subsidiary is converted into a common currency associated with the global game. For example, the global betting pool includes bets from various locales associated with regional subsidiaries 230-240. For example, regional subsidiary 230 can be located in Germany and bets placed by users with regional subsidiary 230 can be made in euro currency amounts. Regional subsidiary 238 can be located in the United States and bets placed by users with regional subsidiary 238 can be made in U.S. dollar amounts. In some implementations, when a global game is provided for users to bet on, currency from regional subsidiary 230 and/or currency from regional subsidiary 238 are converted to a common currency associated with the global game. For example, the common currency can be the currency of the geographic region of the global game host. The common currency can be a virtual (e.g., made up) currency used for accounting purposes.
In some implementations, a constant exchange rate is used throughout the duration of the global game. For example, an exchange rate for currencies can be set at the beginning of the global game and the exchange rate will not change during the game. Thus, a user who places a bet when betting on the global game first opens will not experience a different exchange rate that someone who places a bet on the game at a different time.
In some implementations, currency conversion is performed at the global game host device. For example, regional betting pool funds received at the host device can be converted into the global game common currency by the global game host once the regional betting pool funds are received. The global betting pool associated with the global game can be maintained in the common currency. For example, the regional betting pool funds can be added to the global betting pool funds once the regional betting pool is converted to the common currency. In some implementations, the global game host can convert the portion of the global betting pool (e.g., the winnings) to be sent to the regional subsidiaries from the common currency to the currency of the regional subsidiaries before transmitting the subsidiary's portion. In some implementations, the global game host can set the conversion rates to be used throughout the global game.
In some implementations, once the global game is finished, the host of the global game can transmit a portion of the global betting pool to the regional subsidiaries associated with winning bets. For example, the global game host can determine, based on the metadata received from the regional subsidiaries, which regional subsidiaries are associated with winning bets and the amount of currency that must be transmitted to the regional subsidiaries to pay the winning bets.
In some implementations, regional subsidiaries (e.g., regional subsidiaries 230-240) can receive a portion of the global betting pool. For example, regional subsidiaries can receive a portion of the global betting pool funds by electronic funds transfer. When the portion of the global betting pool is received, the regional subsidiary can determine which users have bet on the game and which betting users placed winning bets. For example, the regional subsidiary can analyze metadata collected and generated when the user's bets were originally placed to determine which users won and which users lost their bets. In some implementations, if a user won its bet, the regional subsidiary will credit the user's account with the proceeds of the bet from the portion of the global betting pool. For example, the regional subsidiary can electronically credit the winnings to the same account from which the regional subsidiary debited the bet amount.
In some implementations, once the results of the global game are determined, betting users can be notified of the results of the global game. For example, a betting user can be notified by sending the user a message using the same method (e.g., SMS, e-mail) that the user used to place the bet in the first place.
FIG. 3 is a flow diagram of an example process 300 for handling bets at a regional server. At step 302, bets are received at a regional subsidiary server indicating a bet on a global game. For example, a bet message can be received by a regional subsidiary server. The bet message can include information identifying a bet to be placed on a global game. The information can include identification of a user placing the bet, a user account containing money for betting, a global game identifier, an identification of the user's predicted outcome of the game. The regional subsidiary server can use the information to process the bet, including electronically debiting the user's account for the amount bet, and adding the amount bet to the regional betting pool for the global game, as described in detail above.
At step 304, bets are added to a regional betting pool. In some implementations, a regional subsidiary server can maintain a regional betting pool for a global game. The regional betting pool can contain information (e.g., regional betting pool metadata) associated with the bets placed with the regional subsidiary by users within a region controlled by the regional subsidiary. For example, the regional betting pool can include an accounting of the money bet on the global game and also information describing the users who placed bets and the outcomes of the game predicted by the betting users. The regional betting pool can include funds corresponding to an amount bet by users on a game. For example, the users who correctly predict the outcome of the global game will get a share of the global betting pool.
At step 306, a determination is made that a configured time interval has elapsed. In some implementations, a regional subsidiary will collect bets for a configured period of time. For example, users may only be allowed to bet on a game for a specified period of time before the start of the game. After the specified or configured period of time has elapsed, betting on the game can be closed and the regional betting pool can be transmitted to the global game host to be added to the global betting pool.
At step 308, the regional betting pool is transmitted to a global game server. In some implementations, the regional betting pool for the global game is transmitted from a regional subsidiary to the global game server after the regional subsidiary has converted the regional betting pool into the common currency set by the global game server. In some implementations, the regional betting pool is not converted into the common currency before transmission to the global game server. In some implementations, the regional betting pool is transmitted with metadata contains information describing the bets placed on the global game at the regional subsidiary, as described above. In some implementations, an electronic funds transfer is performed to transfer funds from the regional betting pool to the global betting pool.
At step 310, a portion of a global betting pool is received from the global game server. For example, after the global game has ended (e.g., the sporting event associated with the game has ended) the global game server can distribute portions of the global betting pool to the regional subsidiaries for distribution to the betting users associated with each regional subsidiary. The distribution of the funds corresponding to the portion of the global betting pool can be performed by electronic funds transfer.
At step 312, the portion of the global betting pool is distributed to winning users. For example, once the portion of the global betting pool is received by the regional subsidiary at step 310, the regional subsidiary can distribute the portion of the global betting pool to users who correctly predicted the outcome of the global game. In some implementations, the regional subsidiary can distribute the portion of the global betting pool to users based on the metadata associated with the regional betting pool for the global game, as described above. For example, the regional subsidiary can credit winnings to the same account from which the user's bet was debited. Alternatively, the regional subsidiary can credit winnings to accounts other than the account from which the user's bet was debited. For example, winnings can be credited to a prepaid credit card, telephone calling cards, or other types of accounts.
At step 314, notifications are sent to users indicating the outcome of the global game. For example, a notification can be sent to the user using the same communication method (e.g., SMS, e-mail, etc.) used for transmitting the bet message. The notification can be sent to the user using any other communication method associated with the user. For example, if the user has registered an e-mail address with a regional subsidiary but has placed a bet using SMS, the user can be notified of the outcome of the game using SMS or e-mail. The notification can include information indicating whether the user won or lost the user's bet, the outcome of the global game and/or the amount of money won or lost. The notification can include advertisements for future betting events that the user might be interested in.
FIG. 4 is flow diagram of an example process 400 for handling bets at a global server hosting a global game and a global betting pool. At step 402, regional betting pools for a global game are received from regional subsidiaries. For example, multiple regional subsidiaries can collect bets for the global game hosted at the global server. The regional subsidiaries will receive the bets from betting users and process the bets to generate regional betting pools, as described above. The regional betting pools can include funds corresponding to the amounts bet by users. The regional subsidiaries can transmit their respective regional pools for the global game to the global server to be aggregated with regional betting pools from other regional subsidiaries. In some implementations, when each regional betting pool is received, the global server can convert the regional currency of the regional betting pool into a common currency for the global betting pool.
In some implementations, metadata for the regional betting pool is received with the regional betting pool at step 402. For example, the metadata for the regional betting pool can contain information describing the bets placed by betting users at the regional subsidiary. The metadata can be used to determine the distribution of winnings from the global betting pool once the global game has concluded.
At step 404, regional betting pool bets are added to a global betting pool for the global game. For example, once the regional betting pool is converted to the common currency, the regional betting pool can be added to the global betting pool having the same common currency. In some implementations, steps 402 and 404 can be performed in parallel.
At step 408, the outcome of the global game is determined. For example, the global game can be associated with a sporting event (e.g., a football game, baseball game, etc.). Once the sporting event is over and the winner, loser, score, etc. of the sporting event are determined, the outcome of the sporting event can be compared to predictions made by betting users, as described in the metadata received from the regional subsidiaries along with the regional betting pools. Based on the comparison, the amount or portion of the global betting pool to be transmitted to each regional subsidiary can be determined.
At step 410, winnings from the global betting pool are transmitted to the regional subsidiaries. For example, the amount or portion of the global betting pool determined at step 408 for each regional subsidiary can be transmitted to the respective regional subsidiary for distribution to betting users, as described above. In some implementations, the portion of the global betting pool to be transmitted to a particular regional subsidiary is converted to the currency of the particular regional subsidiary before the portion of the global betting pool is transmitted.
In some implementations, funds are not transferred between the regional server and the global server. For example, the regional server can transmit information indicating the amount of funds in the regional betting pool without actually performing an funds transfer. In some implementations, a regional server will not transfer the funds (or may delay transferring the funds) of a regional betting pool to the global betting pool if the funds in the regional betting pool are less than a configured amount (e.g., 20000
). Likewise, winnings from the global betting pool may not be actually transferred to the regional server. For example, if the regional pool funds for a game were not transferred to the global server, the global server may not need to transfer funds to the regional server to cover the bets of the winning users. The global server can merely transmit information to the regional server indicating the outcome of the game to the regional server and the regional server can distribute winnings to users out of the regional betting pool funds retained at the regional server.

Example System Architecture

FIG. 5 is a block diagram of an example system architecture implementing the features and processes of FIGS. 1-4. The architecture 500 can be implemented on any electronic device that runs software applications derived from compiled instructions, including without limitation personal computers, servers, smart phones, media players, electronic tablets, game consoles, email devices, etc. In some implementations, the architecture 500 can include one or more processors 502, one or more input devices 504, one or more display devices 506, one or more network interfaces 508 and one or more computer-readable mediums 510. Each of these components can be coupled by bus 512.
Display device 506 can be any known display technology, including but not limited to display devices using Liquid Crystal Display (LCD) or Light Emitting Diode (LED) technology. Processor(s) 502 can use any known processor technology, including but are not limited to graphics processors and multi-core processors. Input device 504 can be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, and touch-sensitive pad or display. Bus 512 can be any known internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, NuBus, USB, Serial ATA or FireWire. Computer-readable medium 510 can be any medium that participates in providing instructions to processor(s) 502 for execution, including without limitation, non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.) or volatile media (e.g., SDRAM, ROM, etc.).
Computer-readable medium 510 can include various instructions 514 for implementing an operating system (e.g., Mac OS®, Windows®, Linux). The operating system can be multi-user, multiprocessing, multitasking, multithreading, real-time and the like. The operating system performs basic tasks, including but not limited to: recognizing input from input device 504; sending output to display device 506; keeping track of files and directories on computer-readable medium 510; controlling peripheral devices (e.g., disk drives, printers, etc.) which can be controlled directly or through an I/O controller; and managing traffic on bus 512. Network communications instructions 516 can establish and maintain network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, etc.).
A graphics processing system 518 can include instructions that provide graphics and image processing capabilities. For example, the graphics processing system 518 can implement the processes described with reference to FIGS. 1-4.
Application(s) 520 can be an application that uses or implements the processes described in reference to FIGS. 1-4. The processes can also be implemented in operating system 514.
The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language (e.g., Objective-C, Java), including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors or cores, of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.
The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.
The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
One or more features or steps of the disclosed embodiments can be implemented using an API. An API can define on or more parameters that are passed between a calling application and other software code (e.g., an operating system, library routine, function) that provides a service, that provides data, or that performs an operation or a computation.
The API can be implemented as one or more calls in program code that send or receive one or more parameters through a parameter list or other structure based on a call convention defined in an API specification document. A parameter can be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or another call. API calls and parameters can be implemented in any programming language. The programming language can define the vocabulary and calling convention that a programmer will employ to access functions supporting the API.
In some implementations, an API call can report to an application the capabilities of a device running the application, such as input capability, output capability, processing capability, power capability, communications capability, etc.
A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

Claims

1. A method comprising:

receiving bet messages at a regional server;

parsing the received bet messages to determine bets placed by users, the bet messages specifying outcome predictions for a global game on a global server and bet amounts;

transferring funds corresponding to the bet amounts from accounts associated with the users to a local betting pool on the regional server and associated with the global game; and

transmitting information describing the local betting pool to the global server.

2. The method of claim 1, wherein transmitting the information to the global server includes transmitting the local betting pool funds to the global server.

3. The method of claim 2, wherein the local betting pool is associated with a first currency, wherein the global betting pool is associated with a second currency, and further comprising:

converting the local betting pool funds to the second currency before transmitting the local betting pool funds to the global server.

4. The method of claim 1, further comprising:

generating metadata for the local betting pool based on the bet messages.

5. The method of claim 1, further comprising:

parsing the bet messages to determine a account associated with the user; and

debiting the account based on the bet amount.

6. The method of claim 2, further comprising:

determining a time interval for receiving bets for the global game; and

transmitting the local betting pool funds to the global server when the time interval has elapsed.

7. The method of claim 5, further comprising:

receiving a portion of global betting pool funds from the global server and metadata identifying the outcome of the global game;

determining that the user has correctly predicted the outcome of the global game based on the global game metadata;

crediting the account of the user from the portion of the global betting pool funds based on the bet amount.

8. A method comprising:

receiving, from a plurality of regional servers, local betting pool funds associated with a global game on a global server;

combining, at the global server, the local betting pool funds into a global betting pool associated with the global game;

determining a portion of the global betting pool funds to distribute to a particular one of the regional servers based on the outcome of the global game; and

transmitting the portion of the global betting pool funds the particular regional server.

9. The method of claim 8, wherein at least one of the local betting pools is associated with a first currency, the global betting pool is associated with a second currency, and further comprising:

converting funds associated with the at least one local betting pool into the second currency.

10. The method of claim 9, further comprising:

converting the portion of the global betting pool funds into the first currency before transmitting the portion of the global betting pool funds to the particular regional server.

11. The method of claim 9, further comprising:

receiving metadata describing bets corresponding to the local betting pools associated with the global game;

determining the portion of the global betting pool funds to distribute to the particular regional server based on metadata associated with a local betting pool received from the particular regional server.

12. A system comprising:

one or more processors; and

a computer-readable medium including one or more sequences of instructions which, when executed by the one or more processors, causes:

receiving bet messages at a regional server;

parsing the received bet messages to determine bets placed by users, the bet messages specifying outcome predictions for a global game on a global server and a bet amounts;

13. The system of claim 12, wherein transmitting the information to the global server includes transmitting the local betting pool funds to the global server.

14. The system of claim 13, wherein the local betting pool is associated with a first currency, wherein the global betting pool is associated with a second currency, and wherein the instructions cause:

15. The system of claim 12, wherein the instructions cause:

generating metadata for the local betting pool based on the bet messages.

16. The system of claim 12, wherein the instructions cause:

parsing the bet messages to determine a account associated with the user; and

debiting the account based on the bet amount.

17. The system of claim 13, wherein the instructions cause:

determining a time interval for receiving bets for the global game; and

18. The system of claim 16, wherein the instructions cause:

19. A system comprising:

one or more processors; and

a computer-readable storage medium including one or more sequences of instructions which, when executed by the one or more processors, causes:

20. The system of claim 19, wherein at least one of the local betting pools is associated with a first currency, the global betting pool is associated with a second currency, and wherein the instructions cause:

21. The system of claim 20, wherein the instructions cause:

22. The system of claim 20, wherein the instructions cause: