WO2002049730A1

WO2002049730A1 - Financial data driven racing game

Info

Publication number: WO2002049730A1
Application number: PCT/US2001/050430
Authority: WO
Inventors: Paul A. Adao E. Silva B.C.; Robert I. Howard
Original assignee: Gfe Global Financing Limited
Priority date: 2000-12-20
Filing date: 2001-12-20
Publication date: 2002-06-27
Also published as: AU2002231284A1

Abstract

A method and system for operating a simulated racing game based on financial data. According to one embodiment, players are presented with stocks. Each player may select and bet on a stock. The simulated race includes a display of racers, each associated with a player. The finish position of a player's racer is based on financial data associated with the stock selected by that player. Payout may be based on odds assigned to each stock and the amount bet. In one embodiment, the system providing the simulated race includes a system server and one or more client servers. The client servers are configured to gather players' bets, simulate the race and apprise player of odds and winnings. The system server provides the financial data, either current or historical, to the client servers and calculates odds and winnings.

Description

FINANCIAL DATA DRIVEN RACING GAME CROSS REFERENCE TO RELATED APPLICATIONS

[001] The present application claims the benefit of U.S. Provisional Patent

Application Serial No. 60/257,086, filed on December 20, 2000, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

[002] The present invention relates generally to gaming systems and, more specifically, to games driven by real world financial data.

2. Description of Related Art

[003] Although the worldwide gaming industry is significant, approaching several billion dollars in annual revenue, casinos and other gaming facilities operators are perpetually concerned with preventing player boredom. It is understood in the industry that players of games quickly become bored playing the same games. In the gaming industry vernacular, over time games become "stale" and attract fewer players. Fewer players results in less revenue for the facility operator. Accordingly, there exists a need for new games that are capable of generating increased player interest.

3. Summary of the Invention

[004] The present invention satisfies the need for new games by providing methods and systems for operating simulated racing games based on financial data. According to one embodiment, each player of the simulated race may select and bet on any of a number of stocks. The simulated race includes a display of racers, each associated with a player. The finish position of a player's racer is based on financial data associated with the stock selected by that player. Payout may be based on odds assigned to each stock and the amount bet. In one embodiment, the system providing the simulated race includes a system server and one or more client servers. The client servers are configured to gather players' bets, simulate the race and apprise players of odds and winnings. The system server provides the financial data, either current or historical, to the client servers and calculates odds and winnings.

BRIEF DESCRIPTION OF THE DRAWINGS [005] The following drawing figures are submitted with, and form a part of, this application.

[006] Figure la is a schematic block diagram illustrating the components of a system according to one embodiment of the present invention.

[007] Figure lb is an illustration of the player interface and display according to one embodiment of the present invention.

[008] Figures 2 and 2a-c are flow charts of the operation of the main client system according to one embodiment of the present invention.

[009] Figures 3 and 3a-d are flow charts illustrating the operation of the bedding subsystem according to one embodiment of the present invention.

[0010] Figures 4 and 4a-c are flow charts illustrating the operation of the main racing- phase routine of one embodiment of the present invention.

[0011] Figures 5 and 5a-d are flow charts illustrating the operation of the post-race phase according to one embodiment of the present invention.

[0012] Figures 6 and 6a-c are flow charts illustrating the operation of the system server according to one embodiment of the present invention. [0013] Figures 7a-e are flow charts illustrating the response to client request handlers according to one embodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0014] Certain exemplary embodiments of the present invention will now be described with reference to the foregoing figures.

[0015] 1. Simulated Racing Driven by Real-Time or Historical Financial Data

[0016] The system of the present embodiment is one in which a simulated race (e.g. horses, dogs, cars, etc.) is driven not solely by pseudo-random or stochastic algorithms but by real world financial data. This data may be obtained in real-time or represent historical financial data. The present embodiment of the invention includes a client/server system, as illustrated in figure la, with clients that are Web browsers and custom, point of sale terminals. The system also implements coordinated, para-mutuel betting among all connected clients. On-site systems at casinos or betting parlors are also possible. As illustrated in Figure la, the system server and client each comprise multiple software components or servers providing the functionality described herein.

[0017] The game is based on players betting on stocks (or other securities, hereinafter stocks), from a finite set of, e.g., 5-10 or 20 stocks. Bets can include any of the individual (win, place, show) type bets of a horse race and even combination bets such as trifacta bets. Betting is then closed and the performance of the stocks is calculated over some predetermined period of time, such as within the range of 15 seconds to 2 minutes, preferably over 30 seconds. Characters, such as horses, then are displayed racing over a fixed course. The finish positions (and in certain embodiments, the interim positions) of the characters is based on how well the stocks performed during the time period. While this can be based on gross increase, the positions should be based on percentage gains or least losses. The characters are then shown racing across the course (See Figure lb), with the winner based on stock price performance over the period of time. Payout can be based on odds dependent on the popularity of the choice as in a horse race. The "house" can take a percentage cost of success.

[0018] 2. The System Client

[0019] The client portion of the system is responsible for the simulation of the race, gathering the user's bets and apprising the user of the changing status of odds and their individual winnings. Other than in gathering bets, all information can be obtained from the server portion by sending requests and waiting for responses. Conceptually, the client software can be logically divided into three sequential phases: 1. Betting Phase; 2. Racing

Phase; and 3. Post-Race Phase.

[0020] Figures la and lb shows the user interface of the initial client implementation in each of these three phases of play. A "core" system performs setup tasks such as memory allocation, server connection, event handler setup, etc. and advances the simulation through the three phases on a timed basis. It should be understood that one preferred implementation requires the presence of an event dispatch/handler mechanism. These are intrinsic to many modem windowing libraries or can easily be built.

[0021] 2.1 Core System

[0022] 2.1.1 The Main Routine [0023] Figures 2 and 2a-c illustrate the flow of the main client system. First, the main routine sends a connection request that incorporates encrypted client identification data. Step

202. When the server responds, the connection is established and the client installs three event handlers:

[0024] 1. Change system state in response to "set system state" message;

[0025] 2. Update the system clock when server sends update; and

[0026] 3. Store the encrypted stock price data when received from server. Step

204.

[0027] Next, the application sends a request to the server for the current "official" time. Step 2.06. Requests to the server can be accompanied by the encrypted ID of the application instance that is validated on receipt before any response is sent. All instances advantageously have their clocks synchronized in order to insure that cooperating players cannot cheat by transmitting race results from an instance with an earlier clock to one with a later clock.

[0028] Storage is preferably allocated, for each racer, sufficient to hold one stock value for each second that the race will last. Step 208. Then, a request is sent to the server for the stock data for the next race. Step 210.

[0029] Finally, the scoreboard display is created. Step 212. The scoreboard can display current odds, time till the next race, amount bet worldwide, final odds and racer positions, depending on which state, Betting, Racing or Post-Race, the system is in.

[0030] 2.1.2 Set System State [0031] Figure 2a shows the handler that responds to the message that the system's state needs to change. This function is triggered by each of three subsystems (Betting (B),

Racing (R) and Post-Race (P)) in turn, to advance the system to the next phase. The calling phase is identified in the message and a decision is made as to which phase to invoke next.

Step 214. If the Post-race phase is the caller, or at system startup, the race number is incremented. Step 216. In all three cases, the appropriate phase implementation function is called.

[0032] 2.1.3 Synch System Time

[0033] Figure 2b illustrates the client's method of synchronizing to server time.

[0034] Triggered on the receipt of the time synchronization packet, previously requested from the server, the routine simply updates the client's clock to reflect the same time as the server's. Step 218. The method is essentially identical to that used in the standard Internet time synchronization protocol.

[0035] 2.1.4 Store Next Race Data

[0036] Figure 2c shows the system's response to the arrival of race data. This routine is triggered on receipt of the next race's encrypted stock data from the server. The data, comprising a set of prices for each racer, is stored to disk in its encrypted form. Step 220.

Lastly "Set System State" (2.1.2) is invoked to advance the client to the betting phase of the simulation. Step 222.

[0037] 2.2 Betting Subsystem [0038] The betting phase involves both betting itself and the display of sufficient information to guide the betting process. The software collects bets from the user, forwards them to the server and obtains updated odds on a regular basis.

[0039] 2.2.1 The Main Routine

[0040] Figure 3 outlines the flow of the main betting-phase routine that is invoked in

Figure 2a. First, betting "panels" are created (displayed) to represent different types of bets.

Step 302. In a horseracing scenario, three panels would be created to represent "Win,"

"Place" and "Show". Each panel has display areas and buttons sufficient to allow the user to increase or reduce the bet on any number of racers in any category.

[0041] This routine also preferably installs the following four event handlers that will respond to all user interaction with the betting phase of the simulation:

[0042] 1. Handle the user's interaction with a betting panel;

[0043] 2. Request ongoing odds update from the server;

[0044] 3. Handle receipt of server odds update; and

[0045] 4. Countdown till race start and apprise user. Step 304.

[0046] 2..2.2 Respond to User Bet

[0047] F Fiigure 3 a shows the functionality of the betting handler. This component is invoked whenever the user increases or decreases any bet by pressing the panels' buttons. First, whether the bet will increase or decrease is determined. Step 306. Depending on the answer, the bet for the specific type and racer is incremented or decremented. Steps 308, 310. The display for that racer (e.g., horse) is updated to show the new value (Step 312) and a packet is sent to the server apprising it of the change. Step 314. [0048] 2.2.3 Request Odds Update

[0049] Figure 3b shows a request for odds update. In pari-mutuel betting, the type used in most racing, odds are calculated based on the betting of the patrons, not on the relative merits of the racers. This requires continuous update of the odds during the betting phase. The system periodically, (e.g., every 10 seconds) invokes this handler and sends an encrypted request to the server for the latest odds calculations. Step 316.

[0050] 2.2.4 Update Odds Display

[0051] Figure 3 c shows what happens when the odds are received from the server.

The routine updates the scoreboard display with the latest odds for each racer, and optionally, with the monetary value of all bets on that racer. Step 318.

[0052] 2.2.5 Handle Race Countdown

[0053] Once each selected period of time, preferably less than 2 or even 5 seconds, and advantageously once each second, the countdown routine is invoked. As seen in Figure

3d the function first decrements the time-till-race counter that it maintains (Step 320) and updates the scoreboard so the user knows when to hurry their betting. Step 322. A check is performed to determine whether the countdown has expired. Step 324. If it has, the betting panels are destroyed. Step 326.

[0054] Finally, the Set System State handler (S) (see 2.1.2) is invoked so that the race can begin.

[0055] 2.3 Racing Subsystem

[0056] The racing phase displays the race simulation to the user. It initializes the animation mechanisms and translates each financial data point, previously stored, into the relative speeds of the racers. This can be displayed on a user's computer screen or on a large display at a betting parlor. In other embodiments of the invention, the race simulation can be mechanical.

[0057] 2.3.1 The Main Routine

[0058] Figure 4 outlines the flow of the main racing-phase routine that is invoked in

Figure 2a. First, a display that will represent the racetrack is created. Step 402. This view displays a moving background and all of the racing characters, such as horses, during the course of the race. Next, the sprites that will represent the racers are created. Step 404. It should be understood that though the present embodiment of the invention uses sprite-based animation, any form of graphic display (e.g. full 3D rendering, streaming video, etc.) could be substituted. Next, the sprites are instructed to load their animation frames from bitmaps stored on the client's disk (Step 406) and their initial positions, within the race view, are set.

Step 408. Lastly, three event handlers are installed to conduct the race itself:

[0059] 1. Advance the sprites' frame index and redisplay them;

[0060] 2. Update the sprites' positions based on the next price point; and

[0061] 3. Scroll the background and offset the sprites accordingly. Step 410.

[0062] 2.3.2 Advance Sprites' Frame Pointers

[0063] Figure 4a illustrates the process that drives the sprites animation. In horseracing, for example, this would animate the legs and the jockeys' bouncing. In a car race, this would animate the cars' wheels. The routine is advantageously invoked every 0.2 seconds or less, preferably every 0.05 seconds or more often and first advances each sprite's frame pointer. Step 412. If the frame index has passed the last frame (Step 414), it is reset to the first frame. Step 416. The sprites' images are then bitblt'd to memory, overlaying the background bitmap. Step 418. Finally, the areas of the race view that need update are bitblt'd from memory to the racing view. Step 420.

[0064] 2.3.3 Update Sprites' Positions

[0065] Figure 4b outlines the procedure for moving the racers based on the stored financial data. This routine is invoked at least once every 5 seconds, preferably at least once every second, based on the resolution of the data stream available. Since this is a gaming system, looks are very important. The greatest loss and greatest gain of the stock (in the current period) are calculated and are scaled, arbitrarily or otherwise, into a positive range of pixels. Each racer's position is advanced by the number of pixels obtained from scaling its price's percentage change into that range. Step 422.

[0066] The process then determines if the last stored data point has been represented.

Step 424. If it has, the Set System State handler (S) (see 2.1.2) is invoked so that the post- , race phase can begin. If not, the system sets the sprite position positions. Step 426.

[0067] 2.3.4 Scroll Race Background

[0068] Once preferably every 0.05 seconds the process described by Figure 4c is invoked. The position of each of the sprites is offset to the left (Step 428) by the same number of pixels that the background bitmap's origin is. Step 430. That is all that is needed, as 2.3.3 will account for the redisplay.

[0069] 2.4 Post-Race Subsystem

[0070] After the racing simulation ends, the post-race phase displays the final odds, shows the user any winnings they may have accrued and gives them sufficient time to view their results. It is during this phase that we request the next set of financial data from the server, ensuring that it will be available by the time the next race starts.

[0071] 2.4.1 The Main Routine

[0072] Figure 5 outlines the flow of the main post-race-phase routine that is invoked in Figure 2a. First, the system installs the four handlers that will control the phase's action:

[0073] 1. Update the display with final odds and winnings;

[0074] 2. Re-synchronize client time to server time;

[0075] 3. Store the next race's data values; and

[0076] 4. Count down till next betting phase begins. Step 502.

[0077] Next, the system requests final odds and the user's winnings/losses from the server (Step 504) and requests another time synch packet. Step 506. Finally, the request is made for the next set of race data values. Step 508.

[0078] 2.4.2 Respond to Final Odds & Winnings

[0079] Figure 5a describes the response to receipt of final odds and winnings from the server. The scoreboard is updated to reflect the odds that were calculated after all bets were received and the individual user's winnings as calculated from those odds and their bets.

Step 510.

[0080] 2.4.3 Synch System Time

[0081] Figure 5b illustrates the client's method of synchronizing to server time.

Triggered on the receipt of the time synchronization packet, previously requested from the server, the routine updates the client's clock to reflect the same time as the servers. Step 512.

[0082] 2.4.4 Store Race Data [0083] Figure 5c shows the system's response to the arrival of race data. This routine is triggered on receipt of the next race's encrypted stock data from the server. The data, comprising a set of prices for each racer (i.e., stock) is stored to disk in its encrypted form. Step 514.

[0084] 2.4.5 Countdown Till Next Race

[0085] Figure 5d shows the handler that is triggered once every second. A stored counter is used to delay the start of the next betting period for whatever time seems appropriate. The function decrements the counter (Step 516) and then checks if it has reached zero. Step 518. If it has, the race view is destroyed. Step 520. Finally, the Set System State handler (S) (see 2.1.2) is invoked so that the next betting phase can begin. [0086] 3. The System Server

[0087] The server of the system is very similar in design (but not functionality) to many Internet servers (e.g. Web Servers). A connection manager process receives requests from qualified clients and spawns a separate process for each of them. These "child" processes service the requests of the clients that they are connected to. In the instant embodiment, a second primary process manages the connection to the broker's real time data feed. If, in other embodiments of the invention, historical data for the simulation can be chosen, the same design can be employed, with the second primary process accessing data from fixed storage rather than over the Internet. [0088] 3.1 Core System

[0089] 3.1.1 The Main Routine [0090] At startup (in this embodiment of the invention), the server begins by initializing its real-time feed from the chosen broker. The nature of these connections varies from provider to provider. In this implementation, the server registers with the broker's server and waits for packets on a particular port. Step 602. Next, the server spawns two processes. The first waits on the real-time data feed's port for financial data packets from the provider. Step 604. The second waits on the port that is used by the clients to communicate with their server and services requests for client connections. Step 606. [0091 ] 3.1.2 Store Financial Data Process

[0092] Figure 6a shows the response to received packets of financial data. The system periodically checks for received stock data. Steps 608, 610. The system encrypts and stores the received data until sufficient data has been stored to handle the next race. The information is encrjφted once before it is stored. Step 612. This removes the overhead of communicating through a Secure Socket Layer (SSL), which re-encrypts the data each time it is requested. The system continues the process until it determines that the last data point has been received. Step 614.

[0093] 3.1.3 Service Connection Requests Process

[0094] Figure 6b shows the Server's response to a client request for connection.

Initially, the system waits for a client request. Step 616. When a connection request is received, the server consults its database of authorized clients. If the client doesn't have authorization (as determined in Steps 618, 620), it waits for the next request. If it does have authorization, the server spawns a separate process (see 3.1.4) to handle that client. Step 622. Then, it returns to waiting for the next connection request. Step 616. [0095] 3.1.4 Service Client Requests

[0096] Figure 6c illustrates the functionality of the process that is spawned to service each client's connection. The process establishes five event handlers, corresponding to each of the five possible client requests:

[0097] 1. Request for time synchronization;

[0098] 2. Request for current odds;

[0099] 3. Request for race financial data;

[00100] 4. Request to register a user's bet; and

[00101] 5. Request for final odds and user's winnings.

[00102] W When the connected client's request is received, the system determines the handler associated with the request and invokes the associated request handler. Step 624. [00103] 3.2 The Client Request Handlers

[00104] The client request handlers will now be described with reference to Figures

7a-e.

[00105] 3.2.1 Service Time Synch Request

[00106] Figure 7a shows the server's response to a time synchronization request. The server sends a time synchronization packet to the client. Step 702. The formats of the packet, and the nature of the algorithms on either end, are simply an implementation of the standard Internet Network Time Protocol (NTP) whose specifications are laid out in RFCl 119 and RFCl 129, incorporated herein by reference. [00107] 3.2.2 Service Odds Request [00108] In response to a client request for the current odds, the handler detailed in figure 7b is triggered. The function simply retrieves the current odds from storage and sends them to the connected client. Step 704.

[00109] 3.2.3 Service Race Data Request

[00110] Figure 7c shows the response to a client's request for the data that will drive the next race. In response, the routine transmits the previously encrypted race data to the client. Step 706.

[00111] 3.2.4 Service Bet

[00112] When a request to register a client's bet is received, the response, detailed in

Figure 7d is triggered. First, details of the bet (e.g. client ID, bet category, bet amount, racer) are stored. Step 708. Next, the handler updates the betting totals store. Step 710. Next, the odds are calculated based on the current totals for each racer. Step 712. The total bets from all clients for a given category (e.g., "Win") are divided by the total bets from all clients for each horse.

[00113] This gives the payout odds for each. Finally, the current odds store is updated with the freshly calculated ones.

[00114] 3.2.5 Service Final Odds & Winnings Request

[00115] The response to a client request for final odds and user winnings is detailed in

Figure 7e. As illustrated by the arrow between Figures 7d and 7e, the final odds are retrieved from the current odds store and transmitted to the client in encrypted form. To calculate the client's winnings, the individual client's bets are retrieved and multiplied by the associated odds, after the house's "take" has been reserved. Step 714. The resulting winnings are encrypted and sent to the client. Step 716.

[00116] In the foregoing description, the method and the system of the present invention have been described with reference to specific embodiments. It is to be understood and expected that variations in the principles of the method and the system herein disclosed may be made by one of ordinary skill in the art and it is intended that such modifications, changes, and substitutions are to be included within the scope of the present invention as set forth in the appended claims. The specification and the drawings are accordingly to be regarded in an illustrative, rather than in a restrictive sense.

[00117] For example, although the foregoing embodiment has been described in connection with a simulated horse race, it is within the scope of the invention to use financial data in simulating other types of racing. In one such embodiment, the system is used to simulate a ski race, in which the progression of each skier down a mountain is based upon the decrease (or increase) in a stock's performance.

[00118] Furthermore, although the foregoing embodiment has been described in connection with the performance of stocks, it is within the scope of the invention to use other financial data. As noted above, as used herein, stocks refers to any security or other financial instrument, including equities, debt instruments, interest rates, foreign exchange currency rates, commodity contracts, futures and the like. Furthermore, progression of racers may be based on any measured variable associated with such stocks, including, for example, volatility, the aggregate of the stock's volatility in each of multiple time periods comprising the race (e.g., aggregate of the trading ranges in each minute of a race lasting several minutes), total volatility over the course of a period corresponding to a race (e.g., absolute price change over a several minute period), price (either increase or decrease), trading volume, trading volume as compared to the stock's average volume, and the like. [00119] Additionally, it is within the scope of the present invention to present each player associated with a race with the same or a different group of stocks from which the player selects.

[00120] Furthermore, although the present invention is directed to simulated racing games whose outcome is based on financial data, it is within the scope of the present invention to use other information or factors, in addition to financial data, as the basis for determining the outcome of the simulated race. Such information and factors may include pseudo-random and/or stochastic algorithms. In one such embodiment, the pseudo-random and/or stochastic algorithm includes randomly assigning a multiple to be applied to the financial data.

Claims

What is claimed is:

1. A method of operating a simulated racing game, the method comprising: presenting multiple players stocks; associating each player with a stock; and determining one or more winners of the simulated race based on data pertaining to the selected stocks.

2. The method of claim 1 wherein the stocks include a stock from the following group: equities, debt instruments, interest rates, foreign exchange currency rates, commodity contracts, and futures contracts.

3. The method of claim 1 wherein the data includes data from the following group: volatility, the aggregate of the stock's volatility in each of multiple time periods comprising the race, total volatility over the course of a period corresponding to the race, absolute change in price, relative change in price, trading volume, and trading volume as compared to a stock's average volume.

4. The method of claim 1 wherein the determining the winner is further based on a pseudo-random algorithm.

5. The method of claim 1 wherein associating players with stocks comprises receiving players selections of stocks.

6. The method of claim 1 wherein the determining the winner is further based on a stochastic algorithm.

7. The method of claim 1 wherein the simulated race is from the following group of races: car, horse, ski, boat, and dog.

8. The method of claim 1 further including: receiving bets from players; and paying winnings based on the bets and financial data.

9. The method of claim 1 further comprising associating each player with a racer in the race and displaying the racers progress throughout the race.

10. The method of claim 9 wherein each racer is a sprite and displaying the racers includes advancing the sprites based on the financial data.

11. The metliod of claim 10 wherein advancing the sprites includes advancing each sprite a number of pixels based on the financial data for the stock associated with each sprite.

12. A system for operating a simulated race, the system comprising: one or more client systems, the client systems configured to: receive financial data of multiple stocks; associate each of multiple players with one of the stocks; and display race results based on the stock financial data.

13. The system of claim 12 further comprising one or more system servers configured to provide the financial data to the client systems.

14. The system of claim 12, wherein the client systems are further configured to: display racers in the simulated race, wherein each player is associated with a racer; and determine finish positions of racers in the race based on the financial data pertaining to the stock associated with the player associated with the racer.

15. The system of claim 12 wherein the client systems are configured to further display odds of winning.

16. The system of claim 15 further comprising one or more system servers configured to provide odds of winning to the client systems.

17. The system of claim 12 wherein the stocks include a stock from the following group: equities, debt instruments, interest rates, foreign exchange currency rates, commodity contracts, and futures contracts.

18. The system of claim 12 wherein the client systems are further configured to accept bets from the players and determine payouts based on the financial data.