US20030054879A1 - System and method for securing electronic games - Google Patents

System and method for securing electronic games Download PDF

Info

Publication number
US20030054879A1
US20030054879A1 US10/246,099 US24609902A US2003054879A1 US 20030054879 A1 US20030054879 A1 US 20030054879A1 US 24609902 A US24609902 A US 24609902A US 2003054879 A1 US2003054879 A1 US 2003054879A1
Authority
US
United States
Prior art keywords
signal
encoded
player
game server
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/246,099
Inventor
Bruce Schneier
Jay Walker
James Jorasch
Geoffrey Gelman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Walker Digital LLC
Original Assignee
Walker Digital LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/775,588 external-priority patent/US6099408A/en
Application filed by Walker Digital LLC filed Critical Walker Digital LLC
Priority to US10/246,099 priority Critical patent/US20030054879A1/en
Assigned to WALKER DIGITAL, LLC reassignment WALKER DIGITAL, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCHNEIER, BRUCE, JORASCH, JAMES A., GELMAN, GEOFFREY M., WALKER, JAY S.
Assigned to JSW INVESTMENTS, LLC reassignment JSW INVESTMENTS, LLC SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WALKER DIGITAL, LLC
Publication of US20030054879A1 publication Critical patent/US20030054879A1/en
Assigned to WALKER DIGITAL, LLC reassignment WALKER DIGITAL, LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: JSW INVESTMENTS, LLC
Assigned to WALKER DIGITAL, LLC reassignment WALKER DIGITAL, LLC RELEASE OF SECURITY INTEREST Assignors: JSW INVESTMENTS, LLC
Priority to US11/934,856 priority patent/US7524245B2/en
Priority to US12/430,686 priority patent/US8608558B2/en
Priority to US14/108,637 priority patent/US20140106873A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3241Security aspects of a gaming system, e.g. detecting cheating, device integrity, surveillance
    • A63F13/12
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3202Hardware aspects of a gaming system, e.g. components, construction, architecture thereof
    • G07F17/3223Architectural aspects of a gaming system, e.g. internal configuration, master/slave, wireless communication
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3225Data transfer within a gaming system, e.g. data sent between gaming machines and users
    • G07F17/3232Data transfer within a gaming system, e.g. data sent between gaming machines and users wherein the operator is informed
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/335Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/71Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/401Secure communication, e.g. using encryption or authentication
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/532Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing using secure communication, e.g. by encryption, authentication

Definitions

  • the present invention relates to electronic games, and particularly to methods and devices for securing and ensuring the randomness of electronic or online games.
  • FIG. 1 is a block diagram of an electronic game system in accordance with some embodiments of the present invention.
  • FIG. 2 is a block diagram showing some embodiments of a game server.
  • FIGS. 2A and 2B are block diagrams showing exemplary database configurations.
  • FIG. 3 is a block diagram showing some embodiments of a player terminal.
  • FIG. 4 is a flow chart illustrating an exemplary process by which a player transmits a selection to a game server.
  • FIG. 5 is a flow chart showing an exemplary process by which a player generates and encodes a random number.
  • FIG. 6 is a flow chart illustrating an exemplary process by which a game server generates and encodes a random number.
  • FIG. 7A is a flow chart illustrating an exemplary process of exchanging decoding keys between a player terminal and a game server.
  • FIG. 7B is a flow diagram illustrating an exemplary exchange of encoded random numbers and decoding keys between a player terminal and a game server.
  • FIG. 8 is a flow chart illustrating an exemplary process of generating a game result based on a combination of a first random number and a second random number.
  • FIG. 9 is a flow chart illustrating an exemplary process of generating and transmitting a random number without encoding it.
  • FIG. 10A is a flow chart illustrating an exemplary process of transmitting a decoding key from a player terminal to a game server and decoding a random number.
  • FIG. 10B is a flow diagram illustrating the process of transmitting an encoded random number from a player terminal to a game server, transmitting an unencoded random number from the game server to the player terminal, and transmitting a decoding key from the player terminal to the game server.
  • FIGS. 11 through 13A are flow charts illustrating various exemplary procedures for exchanging random numbers in which a player terminal generates a hash value of a random number.
  • FIG. 13B is a flow diagram illustrating an exemplary exchange of hash values of random numbers, and subsequently the random numbers themselves, between a player terminal and a game server.
  • FIG. 14 is a flow chart illustrating an exemplary procedure for simultaneously exchanging random numbers between a player terminal and a game server.
  • FIG. 15 is a flow chart illustrating an exemplary procedure for encoding and decoding a player communication using a symmetric key.
  • FIG. 16 is a flow chart illustrating an exemplary procedure for encoding and decoding a player communication using asymmetric keys.
  • FIG. 17 is a flow chart illustrating an exemplary procedure for providing authentication and message integrity.
  • FIG. 18 is a flow chart illustrating another exemplary procedure for providing authentication and message integrity.
  • FIG. 19A is a flow chart illustrating an exemplary process for generating multiple decoding keys.
  • FIG. 19B is a flow diagram indicating the generation of multiple numbers by a game server.
  • FIG. 1 illustrates the basic system components of one or more embodiments of the present invention.
  • the system comprises game server 200 and multiple player terminals 300 , each with an associated player modem 350 .
  • Game server 200 preferably is in communication with the player terminal modems 350 via an Internet connection using a network 110 , such as a Public Switched Telephone Network (“PSTN”).
  • PSTN Public Switched Telephone Network
  • communication may take place via dedicated data lines, cellular, Personal Communication Systems (“PCS”), microwave, satellite networks, or any other form of data communications path.
  • PCS Personal Communication Systems
  • game server 200 and/or one or more player terminals 300 may be in communication with a third party 295 .
  • Receiving and/or transmitting of various types of information may take place via the optional third party 295 , as described in detail below.
  • Any number of gaming devices and/or optional third parties may be in communication with the server 200 .
  • the number of each depicted in FIG. 1 is solely for purposes of illustration.
  • FIG. 2 illustrates the basic hardware and data structures of game server 200 in accordance with one or more embodiments of the present invention.
  • Game server 200 includes central processor (“CPU”) 205 , cryptographic processor 210 , random access memory (“RAM”) 215 , read-only memory (“ROM”) 220 , random number generator 225 , payment processor 230 , clock 235 , operating system 240 (typically residing in memory as software), network interface 245 , and data storage device 250 . These elements are connected appropriately, for example, by a standard system bus, so as to allow communications among them.
  • Game server 200 is preferably capable of high volume transaction processing, performing a significant number of mathematical calculations and processing communications and database searches.
  • game server 200 comprises a conventional personal computer or computer workstation with sufficient memory and processing capability to perform the disclosed functionality.
  • a processor such as the 1.8 GHZ Pentium® 4, commonly manufactured by Intel Inc., may be used for CPU 205 .
  • game server 200 operates as a Web server, both transmitting and receiving communications to and from player terminals 300 .
  • Cryptographic processor 210 supports the encoding and decoding of communications with players, as well as the authentication of players.
  • An MC68HC16 microcontroller commonly manufactured by Motorola Inc., may be used for cryptographic processor 210 .
  • This microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHZ configuration and requires less than one second to perform a 512-bit private key operation.
  • Other exemplary commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHZ Roadrunner 284 .
  • cryptographic processor 210 may be configured as part of CPU 205 .
  • encoding and decoding refer to any method of disguising and revealing a message or signal, respectively. These methods include the use of key-based algorithms, codes, steganography, substitution ciphers, transposition ciphers, one-time pads, hash functions, and so on, including various combinations of any such techniques. For a more complete list of encoding and decoding techniques, see Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C , (2 nd ed., John Wiley & Sons, Inc., 1996).
  • Cryptographic processor, 210 may support any of these techniques.
  • a conventional random number generating processor may be used for random number generator 225 .
  • the HEMT integrated circuit manufactured by Fujitsu for example, is capable of generating over one billion random numbers per second. Alternatively, random number generator 225 may be incorporated into CPU 205 .
  • Payment processor 230 supports the transfer and exchange of payments, charges, or debits. Functions performed by payment processor 230 include the preparation of on-line account statements, order-taking, credit card payment authorization, credit card settlement, automated sales tax calculations, digital receipt generation, account-based purchase tracking, and payment aggregation for low-priced services. Processing of credit card transactions by payment processor 230 may be supported with commercially available software, such as the Secure Webserver manufactured by Open Market, Inc. This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters where card verification and processing is handled. Their Integrated Commerce Service provides back-office services necessary to run Web-based businesses. Payment processor 230 preferably comprises a microprocessor (such as the Intel Pentium® 4), but alternatively may be configured as part of CPU 205 .
  • a microprocessor such as the Intel Pentium® 4
  • Data storage device 250 may include hard disk, magnetic, or optical storage units, as well as CD-ROM drives or flash memory.
  • Data storage device 250 contains databases used in the processing of transactions in the present invention, including player database 255 , player selection data database 260 , game result database 265 , player random number database 270 , player decoding key database 275 , audit database 280 , payment database 285 , player account database 290 , game server random number database 292 , game server encoding key database 294 , game server decoding key database 296 , and combination protocol database 298 .
  • database software such as Oracle9iTM, manufactured by Oracle Corporation, is used to create and manage these databases.
  • FIG. 2A provides a structural diagram of an exemplary player selection data database 260 .
  • selection data database 260 maintains data on selections made by a player, and includes fields for saving player ID number 261 , tracking number 262 , game selected 263 , amount of wager 264 , time of wager 266 , type of wager 267 , and a game result 268 .
  • FIG. 2B illustrates another example of a database, this time, the game result database 265 .
  • game result database 265 tracks the results associated with each set of player selection data and includes fields for the player ID number 261 , selection data tracking number 262 , game result 268 , result value 269 , time of result 271 , and status of payment 272 .
  • Player database 255 maintains data on players, and includes fields such as name, address, credit card number, phone number, ID number, social security number, electronic mail address, past system usage, public/private key information, and game preferences. This information is preferably obtained when the player first registers with the system. Player database 255 also contains the tracking number of each player selection data and player random number generated by a player.
  • Player random number database 270 stores all player random numbers. This database is indexed by player ID and contains fields such as player ID number, corresponding selection data tracking number, tracking number of a corresponding player decoding key, a player random number, and the time at which the player random number was received by game server 200 .
  • Player decoding key database 275 facilitates the decoding of the player random number, storing the keys necessary to decode communications from a player. For messages encrypted using a public key encryption system such as RSA, Data Security Inc.'s player public keys will be stored in player decoding key database 275 . In a symmetric key cryptographic system such as Data Encryption System (“DES”), symmetric keys are stored. Both symmetric and public keys are long strings of binary digits, and are explained more fully below with respect to cryptographic authentication embodiments.
  • DES Data Encryption System
  • Audit database 280 stores transactional information relating to a player and, in one or more embodiments, includes the time and date of each player log in, and the number of games played.
  • Payment database 285 tracks all payments made by the players with fields such as player name, player ID number, amount of payment, and corresponding player selection data and a game result. This database may also store credit card numbers of players or bank account information.
  • Player account database 290 may be established if the player wants to keep a balance of funds at game server 200 for future transactions. Player account database 290 acts as a checking account, with winnings deposited and losing wagers subtracted. Alternatively, this account may be a pointer to account data stored at the player's bank, storing only the name of the bank and the player's bank account number.
  • Game server random number database 292 tracks all game server random numbers generated by game server 200 and, in one or more embodiments, includes fields such as corresponding player selection data tracking number, player name, player ID number, the time that game server random number was generated, and the time that the game server random number was transmitted to the player.
  • Game server encoding key database 294 stores all encoding keys used by game server 200 to encode the game server random number.
  • Game server decoding key database 296 stores all decoding keys transmitted to player terminal 300 to decode the game server random numbers.
  • combination protocol database 298 stores the protocols used to combine a player random number with a game server random number to form a result value.
  • network interface 245 is the gateway to communicate with players through respective player terminals 300 .
  • Conventional internal or external modems may serve as network interface 245 .
  • Network interface 245 preferably supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a T1 or T3 line if more bandwidth is required.
  • network interface 245 is connected to the Internet and/or a commercial on-line service such as America Online, CompuServe, or Prodigy, allowing players access to game server 200 from a wide range of electronic connections.
  • Several commercial electronic mail servers include the above functionality. For example, NCD Software manufactures “Post.
  • network interface 245 may be configured as a voice-mail interface, web site, electronic Bulletin Board System (“BBS”), or electronic-mail address.
  • BBS Bulletin Board System
  • controllers perform the primary processing functions and contain, at a minimum, RAM, ROM, and a general processor.
  • Each of these controllers is attached to a WAN hub which serves as the primary communication link with the other controllers and terminals.
  • the WAN hub may have minimal processing capability itself, serving primarily as a communications router.
  • FIG. 3 illustrates the basic hardware and data structures of a player terminal in accordance with a preferred embodiment of the invention.
  • Player terminal 300 preferably includes central processor (CPU) 305 , cryptographic processor 310 , RAM 315 , ROM 320 , random number generator 325 , video driver 327 , video monitor 330 , clock 335 , communication port 340 , input device 345 , modem 350 , and data storage device 360 .
  • Biometric device 355 may be added for increased security, as described below with respect to cryptographic authentication embodiments.
  • a processor such as the 1.8 GHZ Pentium® 4 described above may be used for CPU 305 .
  • a conventional random number generating processor such as the HEMT integrated circuit described above may be used for random number generator 325 .
  • random number generator 325 may be incorporated into CPU 305 .
  • Clock 335 is a standard chip-based clock which can serve to time stamp transactions between player terminal 300 and game server 200 .
  • player terminal 300 is a conventional personal computer having an input device, such as a keyboard, mouse, or conventional voice recognition software package. Player terminal 300 would thus interface with game server 200 via modem 350 .
  • player terminal 300 may be a voice-mail system, or other electronic or voice communications system. Devices such as fax machines or pagers are also suitable terminal devices.
  • Modem 350 may not require high-speed data transfer if most player selection data and player random numbers are text-based and not too long.
  • cryptographic processor 310 the MC68HC16 microcontroller described above may be used.
  • the structure of biometric device 355 will be described in conjunction with the cryptographic authentication embodiment.
  • Data storage device 360 preferably comprises a conventional magnetic-based hard disk storage unit such as those manufactured by Seagate.
  • Selection data database 365 records all selection data generated by a player, tracking games selected, type of bet, amount of wager, etc.
  • Audit database 370 stores communications between player terminal 300 and game server 200 .
  • Encoding key database 375 stores keys used in the process of encoding communications transmitted to game server 200 .
  • Combination protocol database 380 stores the protocols used by game server 200 to combine a player random number and a game server random number.
  • Game result database 385 stores all of the players' results, including amounts won or lost.
  • Player random number database 390 stores each random number generated by a player.
  • Game server random number database 395 stores all game server random numbers received from game server 200 . This database may also store the corresponding decoding keys in the event that a game server random number is encoded.
  • Player terminal 300 communications are preferably software driven. There are many commercial software applications that can enable the communications required by player terminal 300 , the primary functionality being message creation and transmission. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address.
  • game server 200 is configured as a Web server
  • conventional communications software such as the Internet ExplorerTM Web browser from Microsoft Corporation may also be used. The player may use the Internet ExplorerTM browser to transmit and receive random numbers and selections.
  • communications between player terminal 300 and game server 200 take place via one or more electronic networks, preferably with game server 200 acting as a Web server.
  • FIG. 4 illustrates a process by which a player transmits a player selection to a game server.
  • a player logs on to game server 200 using player modem 350 of player terminal 300 , establishing a communication link at step 400 .
  • the player selects the game that he wants to play by selecting from a list of possible games. The player may, for example, select a potential game from a list on a Web page by clicking on the appropriate icon or graphic.
  • Games preferably include casino games such as blackjack, craps, roulette, baccarat, slot machines, lottery, poker, video poker, and sports betting, but may include any game in which a first party (e.g., a server) generates a random number that must be trusted by a second party (e.g., player), including raffles and prize drawings.
  • a first party e.g., a server
  • a second party e.g., player
  • the player selects a type of wager at step 420 .
  • the type of wager is directly related to the game selected.
  • the type of wager for a roulette game might be, for example, a bet on “even”, or a single number bet, such as “18 black.”
  • the type of wager would indicate the number of simultaneous hands the player intends to play.
  • the player selects the amount of each wager. For example, the player might bet one hundred dollars on the next blackjack hand, or may bet five dollars on the next pull of a slot machine. The player may elect to use funds from player account database 290 or may transmit payment information such as a credit card number along with the total amount wagered.
  • the player attaches his name or a unique player ID number to his selections, allowing game server 200 to authenticate the identity of the player. This ID number is preferably received from game server 200 when the player registers with the service or is chosen by the player and then registered with game server 200 by phone. As shown in FIG.
  • game server 200 maintains a database of player ID numbers in player database 255 and issues (or allows) only unique numbers. If less security is required, the player's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, procedures such as those described below with respect to cryptographic authentication embodiments may be implemented.
  • step 450 all of the data provided by the player is combined to form “selection data” which is transmitted to game server 200 .
  • Game server 200 then receives the player selection data and adds a tracking number before storing it in selection data database 260 .
  • players may also transmit the selection data via electronic-mail, voice-mail, or facsimile transmissions.
  • voice-mail the player calls game server 200 and leaves selection data in audio form. Selection data is then transcribed into digital text at game server 200 by a conventional audio-to-text transcriber, not shown.
  • game server 200 supports a plurality of transmission methods, allowing for a wide variety of formats of selection data.
  • the selection data need not include each of a type of game, a type of wager, and the amount of a wager.
  • a type of wager and/or an amount to wager may be stored at the game server as player preferences, for example, in player database 255 .
  • the player may only need to indicate a type of game in the selection data, and the game server may look up the player's preferences for type of wager and/or amount of wager in player database 255 based on the type of game.
  • some types of games may be offered that do not require the player to make a wager at all.
  • the type of game preferred by the player may be associated with the player as a preference, for example, in player database 255 . Accordingly, in one or more embodiments of the present invention, the player selection data may not include a type of game, a type of wager and/or a wager amount.
  • FIG. 5 illustrates a process by which a player generates and encodes a random number for use by the game server 200 .
  • the player generates a player random number either by selecting a number himself or prompting random number generator 225 of player terminal 300 to produce the number.
  • Random number generator 225 may incorporate external factors, such as the time between keystrokes of the player, or the current position of a computer mouse.
  • player terminal 300 stores the player random number in player random number database 390 .
  • cryptographic processor 310 encodes the player random number using an encoding key from encoding key database 375 .
  • encoding key database 375 preferably contains either a large number of unique keys or generates new encoding keys in real-time.
  • Various methods for encoding numbers are known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C , (2 nd ed., John Wiley & Sons, Inc., 1996).
  • a number transmitted by one party to another for use in a combination protocol need not be a random number, but may be any number that cannot be predicted (or cannot be predicted easily) by the other party.
  • the data transmitted for use in a combination protocol may be any signal, data, or information that is unlikely to be predicted by the other party.
  • Such signals may include, without limitation, one or more numbers, random numbers, letters, alphanumeric characters, audio signals, video signals, algorithms, or any combination of such information. Any such signals may be selected by the party directly (e.g., a process for selecting a signal need not include any randomness).
  • a process for selecting a signal need not include any randomness.
  • the player appends his player ID number and the tracking number (see FIG. 2A) to the corresponding selection data so that game server 200 knows to which wager the player random number should apply. This information is then transmitted to game server 200 using player modem 350 at step 530 .
  • game server 200 extracts the player ID number from the message containing the encoded player random number and looks up the player's identity in player database 255 . If further authentication is desired, the protocols of the authentication embodiments discussed below may be employed.
  • FIG. 6 illustrates a procedure used by game server 200 to generate and encode a game server random number.
  • random number generator 225 of game server 200 After authenticating a player, random number generator 225 of game server 200 generates a game server random number at step 600 .
  • the game server random number is stored in game server random number database 292 .
  • cryptographic processor 210 of game server 200 encodes the game server random number. As with the encoding of the player random number, cryptographic processor 210 preferably has access to a large supply of unique encoding keys or an algorithm to produce them.
  • game server 200 transmits encoded game server random number to player terminal 300 . It should be noted that there are a number of hardware options for the receipt of the encoded game server random number at player terminal 300 .
  • the system remains secure because the random numbers have been generated and exchanged for future verification, but have not yet been decoded. As such, both parties know that the random numbers have been generated independently, ensuring a fair game result.
  • FIG. 7A illustrates a procedure for exchanging decoding keys between the player terminal 300 and game server 200 .
  • game server 200 (for the first time) transmits game server decoding key to player terminal 300 .
  • the game server decoding key must be unique for each random number generated.
  • the player terminal 300 transmits a unique player decoding key to game server 200 . In this embodiment, this exchange of decoding keys need not take place simultaneously since both parties are already in possession of each other's encoded random number.
  • game server 200 uses the player decoding key to decode the player random number.
  • game server 200 now has both a player random number and a game server random number in decoded form and can use these numbers to generate a game result.
  • the player need only decode the encoded game server random number in the event of a dispute, as described below.
  • FIG. 7B illustrates, in flow diagram form, the process described in FIGS. 5 through 7A.
  • the player terminal 300 ultimately transmits to the game server 200 both an encoded player random number, E p (M p ) ( 750 ) and a player decoding key D p ( 760 ).
  • the game server transmits to the player terminal both an encoded game server random number E 1 (M 1 ) ( 740 ) and a game server decoding key D 1 ( 730 ).
  • FIG. 8 illustrates a procedure for the game server 200 to generate a game result.
  • game server 200 generates a game result based on the game server random number and the decoded player random number using the combination protocol from combination protocol database 298 (FIG. 2).
  • the combination protocol is retrieved from combination protocol database 298 .
  • the combination protocol is preferably known to both the player terminal 300 and game server 200 , is unique to the particular game selected, and may be published for anyone to read.
  • the combination protocol is preferably a series of mathematical steps which transform the player random number and the game server random number into a distinct “result value.”
  • an appropriate combination protocol for a roulette game may be one that provides a result value that is, for example, an integer between 0 and 37, inclusive (e.g., thirty-eight distinct values). Each result value can then be mapped to an outcome on a roulette wheel, such as such as “1”, “2”, or “00”.
  • the combination protocol developed for a roulette game may indicate that the player random number and the game server random number are first multiplied together, with the resulting number squared. This result is then added to the number 5.
  • the result value in this example is an integer between 0 and 37, inclusive.
  • the possible result values e.g., the thirty-eight integers between 0 and 37, inclusive
  • the result value corresponds to the result of the spin of a roulette wheel.
  • the result value is then compared to the type of wager in the player selection data in database 260 to determine a game result. For example, in the roulette example, a player making a bet on “fifteen-red” (see FIG. 2A) would lose the wager if the result value were any number other than “fifteen-red.” The game result for a loss might be “lose one dollar” for a one dollar wager.
  • the game result is then transmitted to player terminal 300 .
  • Payment processor 230 of game server 200 then decrements player account 290 by one dollar, or charges the player's credit card one dollar (step 830 ), then stores the game result in game result database 265 , indexed by the player ID number (step 840 ).
  • the game result is time stamped by clock 235 of game server 200 before being stored, or is cryptographically chained to previously stored game results.
  • the corresponding player selection data stored in selection data database 260 is then updated to indicate that a result has been reached in step 850 (see e.g. the “result” column in FIG. 2). The player may now begin the cycle again by selecting another set of player selection data.
  • a player may be confident that the random numbers were generated independently of one another.
  • game server 200 For game server 200 to cheat, it would have to decode the player random number before generating the game server random number.
  • game server 200 could select a game server random number to obtain a desired result value and, hence, game result.
  • Obtaining the player random number before generating the game server random number requires game server 200 to decode the encoded player random number, which cannot be accomplished practically before receiving the player decoding key.
  • the player suspects that game server 200 has cheated by not properly incorporating the player random number he can decode the game server random number using the game server decoding key and apply the combination protocol from the combination protocol database 380 at the player terminal 300 to both random numbers, thus verifying the game result.
  • player terminal 300 and game server 200 exchange random numbers.
  • both parties transmit an encoded random number to the other party.
  • only one of the parties needs to encode its random number.
  • the party transmitting its random number without encoding the random number preferably waits until it has received the coded random number from the other party before transmitting its random number.
  • player terminal 300 has already generated a player random number, encoded it, and transmitted it to game server 200 in a manner similar to that described for the mutual encoding embodiments.
  • game server 200 generates a game server random number and, at step 910 , stores it in game server random number database 292 .
  • game server 200 transmits the game server random number to player terminal 300 . Since no encoding takes place, however, game server 200 does not transmit a game server decoding key.
  • player terminal 300 After receiving the game server random number, player terminal 300 transmits a player decoding key to game server 200 at step 1000 .
  • game server 200 uses the player decoding key to decode the encoded player random number.
  • each party is in possession of the other party's respective random number. The random numbers are then combined as described above to generate a game result.
  • player terminal 300 generates and transmits encoded player random number before game server 200 generates and transmits the game server random number. Then, after receiving the game server random number, player terminal 300 transmits the decoding key for the game server 200 to decode the encoded player random number.
  • game server 200 and player terminal 300 switch procedures. Specifically, game server 200 generates and transmits an encoded game server random number before player terminal 300 generates and transmits the player random number. Then, after receiving the player random number, the game server 200 transmits the decoding key for the player terminal to decode the game server random number should the player so choose.
  • FIG. 10B illustrates, in flow diagram form, one or more embodiments in which only one random number needs to be encoded.
  • the player terminal 300 transmits to the game server 200 , both the encoded player random number, E p (M p ) ( 1030 ), and the player decoding key, D p ( 1040 ).
  • the game server 200 transmits to the player terminal 300 only the game server random number M 1 ( 1020 ).
  • both the player and the game server 200 may be confident that the player random number and the game server random number were developed independently.
  • neither player terminal 300 nor game server 200 encodes their respective random numbers. Instead, player terminal 300 generates a player random number, hashes it, sends the hash value to game server 200 , and then receives the game server random number. The player terminal then transmits the player random number to game server 200 , where it is hashed and then compared to the hash value previously received to determine whether it is the number originally generated by player terminal 300 . Operation of this embodiment is illustrated in the flow diagrams of FIGS. 11 - 13 A.
  • player terminal 300 has already transmitted player selection data to game server 200 as described above.
  • player terminal 300 then generates a player random number as previously described.
  • the player random number is stored in player random number database 390 of player terminal 300 .
  • Cryptographic processor 310 then hashes the player random number at step 1120 , generating a hash value.
  • This hash value represents a one-way transformation of the original player random number. While it is computationally simple to generate the hash value from the player random number, it is computationally unfeasible to re-create the player random number from the hash value alone.
  • player terminal 300 transmits the hash value to game server 200 .
  • game server 200 then generates a game server random number at step 1200 .
  • This number cannot be based on the player random number since, in this embodiment, game server 200 only possesses the hash value of the player random number.
  • game server 200 stores the game server random number in game server random number database 292 , then, at step 1220 , transmits the game server random number to the player terminal.
  • player terminal 300 receives and stores the game server random number at step 1300 .
  • player terminal 300 then sends the unhashed player random number to game server 200 .
  • cryptographic processor of the game server 200 hashes the player random number, comparing the resulting hash value to the hash value received from player terminal 300 . If the hash values match, then game server 200 is assured that player terminal 300 has not submitted an altered player random number. With both random numbers now in its possession, game server 200 then proceeds to generate a game result as described above.
  • FIG. 13B illustrates, in flow diagram form, various hash value embodiments.
  • the player terminal 300 transmits both the hashed player random number, Hash(M p ) ( 13 A 30 ), and the player random number, M p ( 13 A 40 ), to the game server 200 .
  • the game server 200 transmits to the player terminal 300 the hashed game server random number, Hash(M 1 ) ( 13 A 20 ), and the game server random number, M 1 ( 13 A 10 ).
  • the player terminal 300 In one or more embodiments employing a hash value operation, the player terminal 300 generates and transmits a hash value of its random number as described above. However, in one or more alternative embodiments, the hash value of a random number may be generated by game server 200 , in which case the corresponding procedures of the game server 200 and player terminal 300 are switched.
  • the various embodiments providing for a hash value described above might not allow a player to determine whether a game server has generated only one random number.
  • the game server may discover two or more numbers with identical hash values, and transmit the hash value to the player terminal. When the game server later receives the player number, the game server may determine which of the two or more numbers with identical hash values to use in the combination protocol (e.g., the number that will provide a result value and/or game result most favorable to the game server). The game server then transmits the chosen number to the player terminal. Since the chosen number hashes to the hash value sent earlier to the player terminal, the player may not suspect that he has been cheated.
  • a high quality hash algorithm makes it computationally infeasible, given only a particular value, V, to generate any number, N, that hashes to V.
  • One criterion of a good hash function is that the hash value be of a particular minimum length. For example, if a hash value is a binary sequence of length 10, then the game server would need hash at most 2 10 +1, or 1025, different numbers before finding two numbers with identical hash values. For most hashing algorithms, a modern computer could very quickly run the algorithm 1025 times, thereby rendering the algorithm ineffective. Therefore, hash values preferably should be of such length that it would be computationally infeasible to test enough numbers so as to find two numbers whose hash values are identical.
  • player terminal 300 and game server 200 simultaneously exchange random numbers, eliminating the need for any coding or hashing to ensure the independence of the generation of the random numbers.
  • FIG. 14 illustrates a procedure for this embodiment.
  • player terminal 300 has already transmitted player selection data as described above.
  • player terminal 300 generates a player random number, then stores it in player random number database 390 at step 1410 .
  • game server 200 generates a game server random number and, at step 1430 , stores it in game server random number database 292 .
  • the player random number and the game server random number are simultaneously posted to an electronic bulletin board. In one or more embodiments, this is accomplished by setting a time at which the random numbers are to be posted. For example, both parties agree to post the random numbers at 3:00 PM, and incorporate this time into their respective communication software.
  • the communications software (not shown separately) automatically posts the random numbers.
  • the operating system of the electronic bulletin board may be configured to void any random number not posted within a desired period of time (e.g., one thousandth of a second, one tenth of a second) from the agreed-upon posting time. This time requirement is preferably so small as to make the reverse calculations using a combination protocol computationally infeasible.
  • neither party's number is readable by the other party until after each party has posted its number, for example, to an electronic bulletin board. Therefore, even if the player posts his number first, for example, the game server cannot view the number, and cannot use the player number to generate a desired game server number. Accordingly, the above-described time period for posting may be unnecessary to deter cheating. Of course, a time requirement for posting may be still be preferred in order to ensure a reasonable rate of play for various games.
  • the game server and the player terminal may be required to post their respective numbers at any time between 3:00 PM and 3:01 PM.
  • the parties' numbers may be made accessible as soon as both parties have posted, or at any time thereafter. In some embodiments, the game server and the player terminal are thus able to receive the other party's posted number at substantially the same time. Of course, the parties need not actually access each other's posted number at the same time.
  • a game result may be generated, according to various embodiments of the present invention described herein.
  • Various methods and systems described herein may be applied to games that are primarily based on chance, such as roulette or craps, and also to games that may be based primarily on player skill but also have an element of randomness.
  • ScrabbleTM is a widely-played board game whose object is to assemble letters into words in such a way as to accumulate more points than your opponent.
  • a good ScrabbleTM player typically has a large vocabulary and an ability to spot patterns in a random arrangement of letters.
  • ScrabbleTM is played in competitions, and there are clear gradations in skill levels. However, there is some randomness in ScrabbleTM.
  • a player receives letters to complete a group or “hand” of letters from which he can form words; the player typically selects or receives the letters at random. Accordingly, various processes and systems described herein could be used to assure a player (and/or a game server) that the process of letter selection is fair.
  • each available outcome may be mapped to a respective result value, in a manner similar to that described above with respect to a game of roulette.
  • the available letters may be arranged in a predefined order (e.g., alphabetical, by point value), or may be sequenced at random. The position of a letter in the sequence may then correspond to a particular result value.
  • a player and a game server might each select a random integer in the range of 1 to the number of available letters, inclusively.
  • the player number and the game server number are added, and the result taken modulo the number of letters remaining. One is added to that result to obtain a result value.
  • the result value is then used to select the letter with the position in the sequence that corresponds to the result value. For example, a result value of 8 would select the eighth letter in the sequence of available letters.
  • Bridge is a card game in which two teams of two compete to either obtain a predicted number of card tricks, or to prevent the other team from doing so.
  • the conduct of the auction and the play phases of the game may require tremendous skill.
  • the initial dealing of the hands, as in various other card games involves chance, as cards are typically shuffled before being dealt. Accordingly, various methods and systems described herein may apply to the dealing of cards in a bridge game.
  • the cards start out in a predetermined order.
  • Each team then submits a random integer in the range of 1 to 52.
  • the integers are added, the result taken modulo 52, and then one is added to determine a result value.
  • the result value indicates the position of the card in the initial ordering with which the first card in the initial ordering should be swapped.
  • each team submits another random integer in the range of 1 to 52.
  • the integers are added, the result taken modulo 52, and then one is added.
  • the resulting number indicates the position of the card in the current ordering with which the second card in the current ordering should be swapped.
  • the process continues for a total of 52 times, so that for each possible card position, a card in that position is swapped with another random card. That way, once each team has submitted 52 random integers in the range of 1 to 52, inclusively, the deck has been shuffled, and play can proceed.
  • players receive 25 random letters, one at a time, and must place the letters within the five by five grid.
  • a player's point total is based on the number of rows and columns in which the player has spelled a word, and the length of the longest word in each row and column.
  • a skilled player may have a large vocabulary and a good feel for where letters are most likely to occur in words.
  • there is an element of chance in the game in that a player cannot know in advance what letters he is to receive.
  • the methods of this invention can be used to assure a player that he receives letters fairly, and doesn't purposely receive, for example, letters that would make it impossible for him to complete any words.
  • the player terminal and the game server might each generate random numbers in the range of 1 to 26.
  • the combination protocol then adds the numbers, takes the result modulo 26, and adds one.
  • the result value is then used to select the letter with the corresponding position in the alphabet.
  • Various embodiments described herein relate to protocols in which one player interacts with game server 200 .
  • Multiple players could easily be handled by treating each player individually, with players receiving individual game results.
  • Five roulette players, for example, could each submit player selection data and receive a game result based on a different result value.
  • players could combine their player random numbers and receive a game result based on a single communal result value.
  • game server 200 may more closely parallel a physical casino in which a group of players face wins or losses based on the same spin of the wheel.
  • each player generates selection data describing the type of wager that they want to make.
  • Game server 200 then generates a game server random number and encodes it using cryptographic processor 210 .
  • Each player terminal 300 generates a player random number and encodes it with its respective cryptographic processor 310 .
  • Each player terminal 300 then transmits its encoded player random number to game server 200 .
  • game server 200 Once game server 200 has collected all encoded player random numbers, it transmits the encoded game server random number to each player terminal 300 . After receiving the encoded game server random number, each player terminal 300 transmits its player decoding key to game server 200 .
  • Game server 200 decodes each encoded player random number and uses them to generate a game result using the combination protocol from combination protocol database 298 , which may store different protocols for various numbers of players, up to the maximum number of players allowed in a game.
  • the game result is transmitted to each player terminal 300 .
  • Players can verify the result value by exchanging decoded player random numbers with each other and comparing them with the game server random number after decoding it with a game server decoding key.
  • each player terminal 300 generates player selection data and a player random number.
  • the first player encodes his player random number and transmits it to the second player.
  • the second player concatenates his random number with the encoded random number from the first player, and encodes both numbers before sending them to the third player. This process continues for each of the players.
  • the last player sends the combined player random number to game server 200 .
  • Game server 200 creates a game server random number, encodes it, then transmits it to each player.
  • each player terminal 300 sends its player decoding key to game server 200 .
  • Cryptographic processor 210 of game server 200 decodes the combined player random number using these decoding keys, forms a result value, and produces a game result for each player.
  • Outcomes for gambling games are determined by either a single event or a multiple event.
  • Roulette and slots are good examples of single event games as a single outcome determines the game result.
  • One spin of the roulette wheel completely resolves all bets placed on that spin.
  • the result of a slot machine wager requires a single handle pull to determine whether the player wins or loses.
  • a result value is easily compared to player selection data to determine a game result.
  • a game result may be based on multiple result values.
  • Blackjack is one example of a multiple event game. Whether a player wins a hand depends on the player's cards and the dealer's cards. Accordingly, in one or more embodiments of the invention, a result value represents the complete sequence of fifty-two cards. Once the card sequence is defined based on the player random number and the game server random number, the cards can be dealt.
  • player terminal 300 After generating an encoded player random number and transmitting it to game server 200 , player terminal 300 receives the encoded game server random number. Player terminal 300 then transmits a decoding key to game server 200 which generates the result value representing the complete sequence of cards in the deck. Before sending a game server decoding key to player terminal 300 , game server 200 sends the player card values representing a hand of cards dealt from the sequence of cards generated by the result value. If he desires, the player then elects to draw additional cards for his blackjack hand, again, from the defined sequence of cards. Once the hand is selected, game server 200 transmits a game server decoding key to player terminal 300 . It is important that the player not receive this key before making his selection to draw additional cards, since decoding the game server encoded random number would allow the payer to know the complete sequence of cards.
  • Another method for handling multiple event games is to generate a result value for each event (e.g., each card dealt, each hand dealt).
  • a result value for each event e.g., each card dealt, each hand dealt.
  • the player after making his bet (by establishing player selection data) the player generates a series of player random numbers, exchanging them with game server 200 for each card required in the hand.
  • the game result might therefore require seven or eight result values, each one created according to one or more of the various described procedures of the present invention.
  • a single result value may correspond to one or more events.
  • one result value may be used to determine only a corresponding single card, or a single result of a slot machine spin.
  • one result value may also correspond to a series, set, or sequence of events, such as a plurality of cards (e.g., a deal of cards, a hand of cards, or a deck of cards).
  • a particular game, system, or application need not use all determined result values in any one way. Accordingly, a particular game, system, or application may use a first result value to determine a single event and a second result value to determine multiple events.
  • any particular determined result value may be used to determine a corresponding single event or corresponding multiple events, as considered practicable for the particular game, system or application.
  • authentication of authorship of the player selection data and player random number involves checking an attached ID or name and comparing it with those stored in player database 255 .
  • cryptographic protocols are added to the authentication process. These protocols enhance the ability to authenticate the sender of a message and serve to verify the integrity of the communication itself, proving that it has not been altered during transmission. Encryption can also prevent eavesdroppers from learning the contents of the communication. Such techniques shall be referred to generally as cryptographic assurance methods and include the use of both symmetric and asymmetric keys as well as digital signatures and hash algorithms.
  • FIG. 15 illustrates a symmetric key embodiment in which player terminal 300 and game server 200 share a key.
  • both encryption and decryption of the player selection data and player random number are performed with the same key.
  • This encryption may be implemented with an algorithm such as DES (U.S. Government standard, specified in FIPS PUB 46 ), or with any of several algorithms known in the art such as AES, IDEA, Blowfish, RC4, RC2, SAFER, etc.
  • a player encrypts his communication with his assigned symmetric key at step 1500 , using cryptographic processor 310 of player terminal 300 .
  • the key may be stored in encoding key database 375 or otherwise stored or memorized by the player.
  • the player communication is then transmitted to cryptographic processor 210 of game server 200 at step 1510 .
  • Cryptographic processor 210 extracts the player ID from the player communication (step 1520 ), looks up the symmetric key of the player in player database 255 (step 1530 ), and decrypts the player communication with this key (step 1540 ).
  • Game server encoding key database 294 contains algorithms and keys for encrypting, decrypting, and/or authenticating communications.
  • the cryptographic processor 210 determines if the resulting communication is intelligible. If so, then the communication must have been encrypted by the same key, authenticating that the player must have indeed been the author of the message. It will be understood that these cryptographic techniques are employed to protect the security of the communications, in addition to the appropriate random number encryption technique described above.
  • FIG. 16 illustrates an asymmetric key protocol in which a player communication is encrypted with a private key and decrypted with a public key.
  • Two such algorithms for asymmetric key protocols are the RSA algorithm and the Digital Signature Algorithm (“DSA”).
  • DSA Digital Signature Algorithm
  • player terminal 300 encrypts the player communication with the player's private key using cryptographic processor 310 .
  • Player terminal, 300 then transmits the player communication to game server 200 at step 1610 .
  • Cryptographic processor 210 at game server 200 then extracts the player ID at step 1620 , looks up the players associated public key in player database 255 at step 1630 , and decrypts the communication with this public key at step 1640 .
  • game server 200 has authenticated the player at step 1650 .
  • unauthorized players obtaining the player communication before it is received by game server 200 are not able to undetectably alter it since they do not know the private key of the player.
  • Unauthorized players might, however, be able to read the message if they managed to obtain the public key of the player.
  • Communication secrecy is obtained if the player encrypts the player communication with his public key, requiring the unauthorized player to know the player's private key to view the player communication.
  • FIG. 17 shows a cryptographic technique using digital signatures to provide authentication and message integrity.
  • One such algorithm is DSA.
  • each player has an associated public and private key. The player signs his communication with his private key at step 1700 with cryptographic processor 310 and transmits it to game server 200 at step 1710 .
  • cryptographic processor 210 extracts the player ID at step 1720 and looks up the player's public key at step 1730 , verifying the signature using the communication and the public key of the player at step 1740 . If the communication is intelligible, then game server 200 accepts the communication as authentic at step 1750 .
  • FIG. 18 there is illustrated a cryptographic technique using message authentication codes for verifying the authenticity and integrity of a player communication.
  • player terminal 300 and game server 200 share a symmetric key, which the player includes in a hash of the communication at step 1800 .
  • a one-way function is applied to the digital representation of the communication. Any of the MAC algorithms, such as RIPEMAC, IBC-Hash, CBC-MAC, or the like, may be applied in this application.
  • cryptographic processor 210 of game server 200 extracts player ID from the player communication at step 1820 .
  • cryptographic processor 210 looks up the player's symmetric key at step 1830 and hashes the communication with the symmetric key at step 1840 , comparing the resulting hash value with the hash value attached to the communication. If the values match at step 1850 , the integrity of the communication is verified along with the authenticity of the player.
  • biometric device 355 such as a fingerprint reader, voice recognition system, retinal scanner, or the like help to solve this problem.
  • a biometric device incorporates a physical attribute of the player into a communication, which is then compared with the value stored in player database 255 at game server 200 .
  • Fingerprint verification may be executed before the creation of a communication, during the generation of a communication in response to prompts from game server 200 , at some predetermined or random time, or continuously by incorporating the scanning lens into player terminal 300 and requiring the player to maintain a finger on the scanning lens at all times for continuous verification while the communication is generated.
  • An example of such a biometric device is the FingerLocTM AF-S2TM fingerprint identification system available from AuthenTec, Inc.
  • the AF-S2TM utilizes a sensor matrix, consisting of 16,384 individual elements arranged in a 128 by 128 grid. When a player places his finger on the grid, an electromagnetic signal is generated by a ring surrounding the grid. The resulting electromagnetic field varies according to the ridges and valleys of the player's fingerprint. Each element of the grid then acts as an antenna, picking up the local electromagnetic signal. The elements can distinguish fine variations in the electromagnetic field, and use these variations to generate a digital fingerprint image. The digitized image is then stored in memory. Each live-scan fingerprint is compared against the previously enrolled/stored template, stored in data storage device 360 . If the prints do not match, the cryptographic algorithms executed by cryptographic processor 310 may prevent the player from generating a communication.
  • the player's voice is used to verify his identity.
  • This embodiment has the advantage of not requiring the use of any specialized hardware since it can be implemented over a standard phone connection.
  • the player's identity is verified at game server 200 .
  • the process of obtaining a voice-print and subsequently using it to verify a person's identity is well-known in the art, and therefore need not be described in detail.
  • Conventional speaker identification software samples the player's voice. This sample is stored at game server 200 in player database 255 . Each time the player wants to transmit a communication to game server 200 , he is required to call game server 200 and speak into the phone at the prompt for a voice sample.
  • the player is provided a password which is incorporated into the digital signature appended to his communication. Any communication received without an appropriate voice match password is not accepted.
  • the voice-print may also be stored in a database within data storage device 360 of player terminal 300 , to verify the player's identity locally prior to allowing his communication to be created.
  • the present invention allows for the anonymity of players. Such anonymity is accomplished by eliminating all references to the names of the players for all communications.
  • a player for example, would include his ID in the player selection data, rather than his name, preventing eavesdroppers from discovering the player's identity.
  • the ID numbers are preferably encrypted with the public key of game server 200 .
  • the player may communicate with game server 200 through conventional anonymous remailers found on the Internet.
  • a flat fee is charged for every set of player selection data submitted.
  • flat fees would cover any number of sets of player selection data over a given period of time, allowing players to subscribe to the service much as they would subscribe to a newspaper.
  • advertisers pay to have messages listed along with the Web pages for the player selection data, supplementing the costs of operating the system.
  • the combination protocol may transform the player random number and the game server random number into multiple result values.
  • the multiple result values could represent ten different spins of a roulette wheel, five different rolls of the dice in craps, or twelve different cards drawn in video poker.
  • the player terminal and the game server would have to generate fewer random numbers, and would have to perform fewer encryption and decryption operations, thus speeding up the play of the game.
  • the combination protocol may transform the player random number and the game server random number into multiple result values corresponding to multiple spins.
  • there are 38*38, or 1444 possible sequences of two outcomes (e.g., “1” and “9”; “24” and “24”; or “00” and “12”). Therefore, in one exemplary combination protocol, the player random number and the game server random number might each be a number between 1 and 1444, inclusive.
  • the two random numbers are then added, modulo 1444, to yield a number between 0 and 1443, inclusive. This number is then divided by 38 in order to yield a quotient and a remainder.
  • Both the quotient and the remainder will be numbers between 0 and 37, inclusively.
  • the quotient may thus serve as a first result value, and the remainder may serve as a second result value.
  • Each result value may be mapped to respective individual outcomes, each individual outcome representing, for example, one spin of a roulette wheel.
  • the player in some embodiments of the present invention in which more than one result value is obtained from a game server number and a player number, the player must place wagers on all result values to be obtained from a combination protocol before obtaining a decoding key from the game server. Otherwise, the player would be able to predict future result values by using the combination protocol applied to the player random number and the game server random number. The player could then make wagers only when future result values would be favorable to the player.
  • the player, the player terminal, and/or the game server may establish rules for placing wagers on the multiple result values to be obtained from a combination protocol (and/or on the corresponding game results).
  • rules could be stored, for example, in player database 255 .
  • a rule might specify, for example, that if the player wins on a first result value, he is to double his wager for the next result value.
  • Another rule might specify that a player is to continue placing wagers on successive result values until his net loss exceeds ten tokens.
  • the game server may attempt to cheat by generating two or more game server numbers, such that each can be encoded to yield the same result.
  • the game server can determine which of the two or more game server numbers to use in the combination protocol in order to achieve a desired game result. For example, after the game server receives the player decoding key, the game server can decode an encoded player random number. Alternatively, an unencoded player random number may have been received. Based on the player random number, the game server then transmits to the player terminal the game server decoding key corresponding to the chosen random number. The game server then uses the combination protocol, the player random number, and the chosen game server random number to generate the game result.
  • a game server may use the following procedure to generate multiple numbers whose encoded values are identical.
  • the game server generates multiple pairs of keys, E K and D K , representing keys in an asymmetric key algorithm.
  • E K is used in combination with an encryption algorithm to generate an encoded version of a number, M K .
  • the encoded number is denoted E K (M K ).
  • E K (M K ) M K can be determined by employing the key D K in a decrypting algorithm.
  • D K (E K (M K )) M K .
  • the game server initially transmits to the player terminal E 1 (M 1 ), (step 1956 ).
  • the game server receives from the player the encoded player random number
  • the game server receives from the player the player decoding key, which allows the game server to view the player random number (step 1962 ).
  • the game server may test the combination protocol on the player's number in combination with each of M 1 , M 2 , . . . M n .
  • the game server then chooses a number, M K , from the set of M 1 , M 2 , . . . M n , that yields the result value that is most desirable for the game server.
  • the game server transmits the corresponding decoding key, D K , to the player terminal.
  • the game server generates the game result based on the player random number and the chosen game server number.
  • FIG. 19B illustrates various embodiments of the present invention in flow diagram form.
  • game server 190 initially generates three game server decoding keys: D 1 , D 2 , and D 3 ( 1970 , 1972 , and 1974 , respectively).
  • Game server 190 ultimately transmits to the player terminal 300 an encoded version of a game server number, E 1 (M 1 ) ( 1976 ), and only one of the three game server decoding keys: D 2 ( 1972 ).
  • the player terminal transmits to the game server the encoded player random number, E p (M p ) ( 1978 ), and a single decoding key D p ( 1980 ).
  • the game server when the game server, for example, transmits E 1 (M 1 ) to the player terminal, the game server may also be required to transmit the encoding key, E 1 , to the player terminal, before the game server can know the player random number (e.g., before receiving an unencoded player random number, or before receiving a decoding key for an encoded player number received by the game server).
  • the game server may be required to transmit the encoding key, E 1 , to the player terminal before transmitting the encoded game server number, after transmitting the encoded game server number, or along with the encoded game server number.
  • the game server later transmits to the player terminal a decoding key, say D 2 , that does not correspond to the encoding key, E 1 , then the player will be able to determine whether he has been cheated.
  • the player may, for example, encode a test number, M, with encoding key E 1 , and then decode the result with decoding key D 2 .
  • the decoded result will not be the same as the original number, M.
  • D 2 (E 1 (M)) does not equal M. Therefore, by having the game server transmit the encoding key E 1 to the player terminal before the game server knows the player random number, the game server will be motivated to transmit the proper decoding key, D 1 , to the player terminal.
  • One or more embodiments of the present invention require any random numbers generated to be combined in some fashion with at least one known character, before encoding the combination. For example, suppose the game server generates a random number, 1297. The character sequence “bluesky” is then appended to the end of the number, yielding the combination, “1297bluesky”. The full character sequence, “1297bluesky”, is then encoded with key E 1 and sent to the player terminal. Now suppose the game server receives the player's encoded number and decoding key, and decides to use a number other than 1297 in the combination protocol. So the game server might attempt to use a decoding key, D 2 , that does not match the encoding key, E 1 .
  • D 2 (E 1 (1297bluesky)) is unlikely to yield a character sequence ending in “bluesky”. That is, D 2 (E 1 (1297bluesky)) does not equal “xxxxbluesky”, where “xxxx” represents any set of characters. If the game server sends to the player terminal the decoding key, D 2 , and the player decodes the game server's first transmission, E 1 (1297bluesky), and finds that the result does not end with “bluesky”, then the player will realize he has been cheated. To cheat, the game server must determine a new decoding key that does yield a result of the form “xxxxbluesky”. However, such a task may be computationally unfeasible.
  • any set of one or more characters may be used in combination with a random number
  • certain character sequences may be particularly convenient to use in combination with random numbers.
  • Some of these character sequences may include, without limitation, a player's name, a player's casino card number, a date, or a time. If, for example, it is always a player's name that is appended to the game server random number, then the player does not have to find out at the beginning of a gaming session what appended character sequence to look for.
  • the set of signals that can be transmitted between the game server and the player terminal is limited.
  • the set of signals may be limited to only one signal (e.g., “5”), to a plurality of signals (e.g., “5” and “10”), to a range of signals (e.g., 2 to 12), to particular types of signals (e.g., numbers, random numbers, alphanumeric characters, audio signals, video signals, algorithms), and may be limited by any combination of such limitations. Many other types of limitations will be known to those of skill in the art.
  • the player and the game server may be involved in a game of craps.
  • the game server and the player need only exchange integer random numbers in the range of 1 to 36, inclusively (or in the range 2 to 12, inclusive, to represent just the sum of the die faces).
  • the game server and the player terminal employ an encoding algorithm that is capable of handling inputs greater than 36. Therefore, if a game server encodes the number 24, for example, with the encoding key E 1 , but later decodes the result with a decoding key, D 2 , then the resulting number is most likely to be out of the range 1 to 36. For example, D 2 (E 1 (24)) might equal 153982. Therefore, the game server would be forced to search for a new decoding key that yielded a result between 1 and 36, a task that may be computationally unfeasible.
  • a third party may be involved as an intermediary between the player terminal and the game server.
  • each party submits its number, unencoded, to a third party.
  • the third party transmits them to the player terminal and to the game server.
  • the player terminal and the game server may first encode their numbers before transmitting them to the third party.
  • the third party may then transmit the encoded numbers to the player terminal and to the game server.
  • the player terminal and the game server may then send decoding keys to the third party.
  • a decoding key may be transmitted to the third party before the encoded random number is transmitted to the third party, or may be transmitted to the third party along with the encoded random number. After receiving the decoding keys, the third party may then transmit the decoding keys to the player terminal and to the game server.
  • the above example describes mutual encoding of numbers, those having ordinary skill in the art will understand that a third party may similarly be involved as an intermediary in various processes involving single encoding, hash values, etc.
  • the third party first transmits to the player terminal and to the game server an encoding key.
  • the player terminal and the game server may or may not receive the same encoding key.
  • the player terminal uses the encoding key it received from the third party to encode its random number, and may then transmit its encoded number to the game server, either directly or through the third party.
  • the game server uses the encoding key it received from the third party to encode its random number, and may then transmit its encoded number to the player terminal, either directly or through the third party.
  • the third party may then transmit decoding keys to the player terminal and to the game server.
  • the player terminal and the game server may or may not receive the same decoding key.
  • Each party is then able to decode the other's random number, and to generate a game result using the combination protocol.
  • the game server is not able to cheat by choosing which of several possible decoding keys to use. Instead, the game server must use the decoding key supplied by the third party.
  • the player terminal and the game server each transmit their respective numbers, unencoded, to the third party.
  • the third party uses its own encoding key(s) to encode either or both of the numbers.
  • the third party then transmits the player's number (whether unencoded or encoded) to the game server, and the game server's number (whether unencoded or encoded) to the player. If the player's number is encoded by the third party, the third party also transmits the decoding key for the player's number to the game server. Similarly, if the game server's number is encoded by the third party, the third party also transmits the decoding key for the game server's number to the player terminal. The third party may transmit a decoding key after transmitting an encoded number, before transmitting the encoded number, or along with the encoded number.
  • various embodiments of the present invention provide for requiring one or both of the parties to transmit its encoding key to the other party along with its encoded random number, in order to prevent cheating in which once the other party's number is known, a party can determine which of two or more generated numbers to use in the combination protocol in order to achieve a desired game result, and may transmit the corresponding decoding key.
  • one or both parties may be required to send their encoding and/or decoding keys to a third party before knowing the other party's number.
  • the game server may be required to send its decoding key to the third party before receiving a decoded player number.
  • the game server may alternatively send the decoding key after receiving an encoded player number, but before receiving the player decoding key (i.e., before it can decode the player number).
  • one or both of the parties may also provide a decoding key to the other party.
  • the player may check with the third party and verify that the decoding key received from the game server was the same decoding key that was received by the third party before the game server knew the decoded player number.
  • the player and the game server may receive each other's decoding keys directly from the third party. The player and game server are thus prevented from choosing amongst multiple decoding keys to send to the other party.
  • a third party or intermediary may comprise one or more third parties or intermediaries. Where more than one third party is being used, each may function independently of any others. For example, to exchange numbers, a player terminal may transmit the player random number to one third party, who transmits the number to the game server. The game server may transmit the game server random number to another third party, who transmits the number to the player terminal. In some embodiments involving multiple third parties, the player terminal and/or game server may transmit to, and/or receive information from, more than one third party. For example, a player terminal may transmit the player number to one third party, who transmits the number to the game server.
  • the player terminal may also transmit a player decoding key to another third party, who transmits the decoding key to the game server.
  • Various embodiments of the present invention are described herein as involving an exchange of numbers between two parties, for example, a game server and a player terminal.
  • a player terminal and a game server could just as easily exchange many different types of information, including, without limitation, numbers, letters, symbols, pictures, audio signals, video signals, algorithms, or any combination thereof.
  • a particular game of chance may have two possible outcomes, denoted “outcome 1” and “outcome 2”.
  • the player terminal and the game server each provide either the letter “a” or the letter “b”. According to an exemplary combination protocol, if both the letters are the same, then outcome 1 occurs. If both letters are different, then outcome 2 occurs.
  • one party generates a random number
  • the other party generates a function or algorithm.
  • the function or algorithm provided by a player is applied to the random number provided by a game server to generate the result value and the game result.
  • the game server generates a number, 4.
  • the player terminal generates an algorithm that says:
  • both the game server and the player terminal generate algorithms.
  • two or more algorithms may be combined in a combination protocol in a number of ways.
  • the combination protocol specifies an input to the game server algorithm.
  • the input may be a number, such as 14923.
  • the game server algorithm then operates on the input to produce an output.
  • An exemplary output of the game server algorithm might be the number 2094.
  • the output of the game server algorithm is then used as an input (or as one of multiple inputs) to the player algorithm.
  • the player algorithm then operates on the output of the game server algorithm to produce its own output, which is the result value.
  • the player algorithm could have been run before the game server algorithm (e.g., the combination protocol could have specified a first input for the player algorithm, and the output of the player algorithm could have been an input for the game server algorithm).
  • the combination protocol rather than having the combination protocol specify the input to the first algorithm, the player terminal or the game server might specify the input to the first algorithm.
  • the game server and the player terminal specify multiple algorithms. The algorithms may then be chained together in any order, with the output of one serving as the input for the next.
  • many other ways of combining algorithms are possible.
  • a function or an algorithm may be represented for the purposes of transmission between the game server and the player terminal.
  • x represents the input to the function.
  • the input x may be generated randomly (e.g., by the game server).
  • the output of the player algorithm is represented by f(x), and the right side of the exemplary formula shows how to generate f(x) through the operations of multiplication, modulo division, and addition.
  • a function or algorithm is represented by computer program code.
  • the code may be in any language, such as C, Java, Basic, or Fortran.
  • the code may be written in compiled or uncompiled form.
  • a function or algorithm is represented by a table of inputs and corresponding outputs.
  • the set of inputs might be listed as: 1, 2, 3, 4, and 5.
  • the respective outputs might be listed as: 4, 2, 5, 3, 1.
  • Outputs may be listed in the table, for example, adjacent to their corresponding inputs.
  • Various embodiments described herein with respect to the exchange of numbers may also apply to an exchange involving at least one algorithm or function.
  • a function or algorithm e.g., in the form of text
  • the representation may be encoded.
  • the encoded function or algorithm is then given to the other party, and the other party's encoded number, function or algorithm is received.
  • one or more decoding keys may also be exchanged.
  • a full description or representation of an algorithm need not be transmitted to the opposite party. Instead, only particular features or elements of an algorithm need be transmitted, where the rest of the algorithm is understood by both parties.
  • an algorithm may have a fixed structure or template, but may require one or more elements be defined so that the algorithm may generate an output.
  • the player terminal and/or game server may generate numbers randomly
  • the player terminal and/or game server may generate algorithms randomly.
  • a exemplary base algorithm may have a fixed structure with an undefined multiplier, as described above. The multiplier may be determined randomly, thereby generating the algorithm at random.
  • a player terminal and/or a game server has multiple possible algorithms stored, for example, in a memory. The game server and/or the player may then choose one of the pre-existing algorithms at random, and transmit the algorithm to the other party.
  • the player and/or the game server represent a function as a table. All possible inputs are listed, for example, in one column of the table. All possible outputs are then ordered at random, and preferably located in an adjacent column of the table. Accordingly, any input may be referenced in the first column, and will yield a random output listed adjacently in the second column. Outputs may or may not be listed multiple times, depending on the desired probability of occurrence of the output.
  • a function has five possible inputs: 1, 2, 3, 4, or 5, and five possible outputs, also: 1, 2, 3, 4, or 5.
  • the game server lists the possible inputs in order: 1, 2, 3, 4, and 5, in a column.
  • the game server selects a random arrangement of the outputs, here: 3, 5, 2, 1, 4. Then, the outputs are preferably listed in a column adjacent to the inputs. Thus, an input of 1 would yield an output of 3, an input of 2 would yield an output of 5, and so on.
  • the party may want to ascertain a level of fairness of the combination protocol itself. For example, a combination protocol being used in a game, although known to both parties, may have been generated by one party. Accordingly, the other party might want to verify that the combination protocol is fair. If a party is able to determine that a combination protocol meets some criterion for fairness, that party may be more willing to engage in a game.
  • One or more embodiments of the present invention provide for determining a level of fairness of a combination protocol.
  • One possible criterion for a fair combination protocol is that it does not allow either the player or the game server to unilaterally change the probability of occurrence of a particular result value. For example, suppose the game server wished for a result value of 200. With a fair combination protocol, the game server should not be able to choose a game server number such that the result value of 200 is any more likely than if the game server had chosen the game server number at random.
  • An exemplary fair combination protocol would receive a player number and a game server number, each an integer between 1 and 1000, inclusively. The protocol would then add the two integers, take the result modulo 1000, and add 1.
  • the result value would be an integer between 1 and 1000.
  • the game server and the player terminal each chose their respective numbers at random, with each integer between 1 and 1000, inclusively, being equally likely.
  • the player number will be denoted x p
  • the square brackets denote a discrete function, one that is defined only over the set of integers.
  • the probability mass function for x g is the same as that for x p .
  • the probability mass function for the sum of the player number and game server number is obtained by taking the convolution of the individual probability mass functions.
  • the symbol “*” denotes convolution.
  • the game server chooses the game server random number in such a way that some game server random numbers are more likely to occur than others. Perhaps the game server is attempting to unduly influence the result value.
  • the player terminal chooses its number at random.
  • the player terminal and the game server each generate a number that is an integer between 1 and 500, inclusively;
  • the game server might choose the number 499. Now, no matter what the player terminal chooses, the result value cannot be 1000. This is because the player terminal is restricted to choosing numbers in the range 1 to 500. Choosing the maximum number in the range would only give a result value of 999, one short of 1000. Furthermore, no matter what the player terminal chooses, the result value cannot be a number less than 500. So by purposely choosing a particular number, the game server can assure that certain result values cannot occur. Perhaps the result value of 1000 corresponds to a high paying symbol combination in a game of slots. The player is then denied the opportunity to achieve this payout.
  • a typical combination protocol may be more complicated than those analyzed above. As such, the fairness of the protocol may not necessarily be determinable through a simple analysis.
  • One way for, say, a player terminal to verify the fairness of a combination protocol algorithm would be to run the algorithm using all possible combinations of inputs (i.e. all possible combinations of player and game server numbers). The player terminal could check that given a particular game server random number, all possible result values might still occur. The player terminal might further verify that a for a particular result value, rv 0 , and any two game server numbers x g1 and x g2 , the chances of rv 0 occurring given x g1 are the same as the chances of rv 0 occurring given x g2 . This may assume that the player himself generates the player number at random, with all numbers equally favored probabilistically.
  • Another method of verifying that a combination protocol algorithm is fair would be for a player to run the algorithm many times with a random player number and a fixed game server number. The player would then check to see whether or not particular result values were unduly favored or disfavored. If, for example, a player ran the combination protocol many times with a fixed game server number and a random player number, and found that a particular result value never occurred, then the player might determine that the combination protocol is unfair.
  • This method of verification may be used right after the completion of a game, such as a spin at a slot machine. Perhaps the player has lost the game and is suspicious that he has been cheated due to an unfair combination protocol. So the player tests the game server random number from the game with numerous possible player numbers. The test should show the player what might have happened had the player chosen a different player number in the game. If it turns out that no player number would have resulted in a favorable result value for the player, then the player has confirmed the unfairness of the combination protocol.
  • One or more embodiments of the present invention provide for evaluating the fairness of a combination protocol by determining a set of at least one generated game outcome as described above and determining a relative frequency which a particular game outcome occurs in the set of at least one generated game outcome.
  • a probability of that particular game outcome occurring in a fair game e.g., a game in which one of the parties cannot inappropriately influence the outcome and/or the random process used to determine an outcome
  • a level of fairness of the combination protocol can be determined based on the probability of the outcome occurring in a fair game and the relative frequency of representation. For example, the probability and the relative frequency of representation can be compared.
  • the level of fairness may depend on the difference. Any difference, for example, may be compared to a predetermined allowable difference. It will be understood that the probability and the relative frequency need not be exactly the same, but may vary by an allowable margin.
  • Various levels of fairness may correspond to how much the relative frequency and the probability vary. For example, a slight difference may correspond to a fairness of “Very Fair”, and a larger difference may correspond to a fairness level of “Unfair.”
  • a player is to test a combination protocol for fairness using a fixed number (e.g., a game server number) and each of a set of one or more possible player numbers.
  • a fixed number e.g., a game server number
  • a given set may be compared with one or more various criteria, to determine whether the set of player numbers, if tested, would provide the predetermined degree of confidence that the combination protocol is fair.
  • An evaluation of the fairness of a combination protocol preferably includes a sufficient number of tests so that the failure of the appearance of the predetermined game outcome the predetermined number of times would most likely indicate the unfairness of the combination protocol. Otherwise, the failure to generate certain result values and/or outcomes during analysis of a combination protocol might be explained by the lack of a sufficient number of tests of the combination protocol, and not necessarily by the unfairness of the combination protocol itself.
  • one criterion for selecting a set of player numbers to test with may be that the number of elements in the set of player numbers is not less than some threshold or predetermined minimum number of elements.
  • Another criterion for the set of player numbers tested might by that the number of elements in the set of player numbers is not less than a predetermined minimum percentage (e.g., 10%, 100%) of the number of all allowed player numbers. Again, this criterion might help to ensure that the failure of a test to generate a particular result value and/or outcome tests is most likely due to the unfairness of the combination protocol, and not to the lack of a sufficient number of tests conducted.
  • a predetermined minimum percentage e.g. 10%, 100%
  • Another possible criterion for the set of player numbers tested might be that the number of elements in the set of player numbers is sufficient such that, if each player number tested leads to a corresponding game outcome, then the number of elements in the set of player numbers will ensure, with a predetermined probability, at least a predetermined number of occurrences of a particular game outcome.
  • Various embodiments of the present invention are directed to systems and methods for ensuring the randomness of random numbers.
  • One or more embodiments of the present invention provide for authenticating the results of electronic games in a manner that substantially obviates one or more of various limitations and disadvantages of the related art.
  • Various embodiments of the present invention provide, in an electronic game system, hardware and procedures to ensure that random numbers used to generate game results are truly random, independently-generated numbers.
  • an electronic game system comprises a game server and one or more player terminals.
  • the game server includes a random number generator and a first transmitting device for transmitting a first random number to the one or more player terminals.
  • the one or more player terminals includes a random number generator and a second transmitting device for transmitting a second random number to the game server.
  • the system also includes one or more of various hardware and/or procedures for ensuring that the first random number is generated independently of the second random number.
  • One or more embodiments of the present invention provide for a method for controlling an electronic game played in a system that includes a game server and one or more player terminals.
  • the method includes the steps of generating a first random number at the game server; generating a second random number at the player terminal; encoding the first random number at the game server; encoding the second random number at the player terminal; transmitting a player encoded number from the player terminal to the game server; transmitting a player decoding key from the player terminal to the game server; and decoding the player encoded number at the game server to obtain the second random number.
  • a result value is generated based on the first random number and the second random number.
  • Some embodiments of the present invention provide for producing a game result based on the result value.
  • Some embodiments of the present invention are directed to various systems and procedures of a game server separate from a player terminal, as well as various combinations of such systems and/or procedures. Some embodiments of the present invention are directed to various systems and procedures of a player terminal separate from a game server, as well as various combinations of such systems and/or procedures. As discussed above, other embodiments may provide for one or more systems and/or procedures of a game server in various combinations with one or more systems and/or procedures of a player terminal.
  • One or more embodiments of the present invention provide for various hardware and/or procedures for encoding, hashing, encrypting, decoding, dehashing, and decrypting the first and second random numbers. Moreover, one or more embodiments of the systems and procedures of the present invention provide for authenticating players. One or more embodiments of the present invention provide for creating audit records of game data.

Abstract

A game server is provided, the game server comprising a processor and a storage device coupled to the processor. The storage device stores instructions adapted to be executed by the processor to perform a method comprising: generating a first signal; transmitting an encoded first signal; receiving a second signal; and transmitting a decoding key after receiving the second signal.

Description

  • This application is a continuation-in-part application of U.S. patent application Ser. No. 09/895,648, filed Jun. 29, 2001; which is a continuation of U.S. patent application Ser. No. 09/488,608; which is a continuation of U.S. patent application Ser. No. 08/775,588; the contents of each of which are incorporated by reference herein for all purposes.[0001]
  • FIELD OF INVENTION
  • The present invention relates to electronic games, and particularly to methods and devices for securing and ensuring the randomness of electronic or online games. [0002]
  • BACKGROUND OF THE INVENTION
  • Various forms of electronic games of chance have been available for many years. The way these games are played, however, is changing dramatically with the use of digital computers operating on electronic networks such as the Internet. Players can now connect to a remote server and wager electronically. [0003]
  • Rather than traveling to a casino, a player can log into an electronic game and wager from the comforts of his own home. While this remote playing has many advantages, it raises several security issues. For example, when playing card games at a casino, a player can observe the dealer shuffle and deal the cards and thus has some confidence that the outcome was generated randomly. In an electronic casino, the shuffling process is typically digitally generated, driven by random number generators which the player cannot see. The player cannot know whether the random number generated is truly random or was selected by the casino to give it an advantage. [0004]
  • Electronic game providers have tried to increase players' confidence in the legitimacy of games by assuring players that gaming software has not been tampered with. For example, an electronic game provider may allow an independent third party to perform an audit of the software. This is a time-consuming and expensive process, however. With complex software running into the hundreds of thousands of lines of code, it is very difficult to find a few lines of code that alter the randomness of the outcomes. [0005]
  • Some electronic lottery systems have subscribed to methods for securing communications between remote player terminals and a central controller. U.S. Pat. No. 4,652,998 to Koza, for example, describes cryptographic methods for securing these communications. In games dependent on the use of random numbers, however, simply securing the transmission of a fraudulent random number does not solve the problems inherent in the prior art. [0006]
  • Although there are many patents which describe the generation of random numbers, such as U.S. Pat. No. 3,548,174 to Knuth, they describe only methods for improving the statistical performance of random number generators.[0007]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and together with the general description given above and the detailed description given below, serve to explain the principles of the invention. [0008]
  • FIG. 1 is a block diagram of an electronic game system in accordance with some embodiments of the present invention. [0009]
  • FIG. 2 is a block diagram showing some embodiments of a game server. [0010]
  • FIGS. 2A and 2B are block diagrams showing exemplary database configurations. [0011]
  • FIG. 3 is a block diagram showing some embodiments of a player terminal. [0012]
  • FIG. 4 is a flow chart illustrating an exemplary process by which a player transmits a selection to a game server. [0013]
  • FIG. 5 is a flow chart showing an exemplary process by which a player generates and encodes a random number. [0014]
  • FIG. 6 is a flow chart illustrating an exemplary process by which a game server generates and encodes a random number. [0015]
  • FIG. 7A is a flow chart illustrating an exemplary process of exchanging decoding keys between a player terminal and a game server. [0016]
  • FIG. 7B is a flow diagram illustrating an exemplary exchange of encoded random numbers and decoding keys between a player terminal and a game server. [0017]
  • FIG. 8 is a flow chart illustrating an exemplary process of generating a game result based on a combination of a first random number and a second random number. [0018]
  • FIG. 9 is a flow chart illustrating an exemplary process of generating and transmitting a random number without encoding it. [0019]
  • FIG. 10A is a flow chart illustrating an exemplary process of transmitting a decoding key from a player terminal to a game server and decoding a random number. [0020]
  • FIG. 10B is a flow diagram illustrating the process of transmitting an encoded random number from a player terminal to a game server, transmitting an unencoded random number from the game server to the player terminal, and transmitting a decoding key from the player terminal to the game server. [0021]
  • FIGS. 11 through 13A are flow charts illustrating various exemplary procedures for exchanging random numbers in which a player terminal generates a hash value of a random number. [0022]
  • FIG. 13B is a flow diagram illustrating an exemplary exchange of hash values of random numbers, and subsequently the random numbers themselves, between a player terminal and a game server. [0023]
  • FIG. 14 is a flow chart illustrating an exemplary procedure for simultaneously exchanging random numbers between a player terminal and a game server. [0024]
  • FIG. 15 is a flow chart illustrating an exemplary procedure for encoding and decoding a player communication using a symmetric key. [0025]
  • FIG. 16 is a flow chart illustrating an exemplary procedure for encoding and decoding a player communication using asymmetric keys. [0026]
  • FIG. 17 is a flow chart illustrating an exemplary procedure for providing authentication and message integrity. [0027]
  • FIG. 18 is a flow chart illustrating another exemplary procedure for providing authentication and message integrity. [0028]
  • FIG. 19A is a flow chart illustrating an exemplary process for generating multiple decoding keys. [0029]
  • FIG. 19B is a flow diagram indicating the generation of multiple numbers by a game server.[0030]
  • DETAILED DESCRIPTION OF THE INVENTION
  • FIG. 1 illustrates the basic system components of one or more embodiments of the present invention. Generally, the system comprises [0031] game server 200 and multiple player terminals 300, each with an associated player modem 350. Game server 200 preferably is in communication with the player terminal modems 350 via an Internet connection using a network 110, such as a Public Switched Telephone Network (“PSTN”). Alternatively, communication may take place via dedicated data lines, cellular, Personal Communication Systems (“PCS”), microwave, satellite networks, or any other form of data communications path.
  • Optionally, [0032] game server 200 and/or one or more player terminals 300 may be in communication with a third party 295. Receiving and/or transmitting of various types of information may take place via the optional third party 295, as described in detail below.
  • Any number of gaming devices and/or optional third parties may be in communication with the [0033] server 200. The number of each depicted in FIG. 1 is solely for purposes of illustration.
  • FIG. 2 illustrates the basic hardware and data structures of [0034] game server 200 in accordance with one or more embodiments of the present invention. Game server 200 includes central processor (“CPU”) 205, cryptographic processor 210, random access memory (“RAM”) 215, read-only memory (“ROM”) 220, random number generator 225, payment processor 230, clock 235, operating system 240 (typically residing in memory as software), network interface 245, and data storage device 250. These elements are connected appropriately, for example, by a standard system bus, so as to allow communications among them.
  • [0035] Game server 200 is preferably capable of high volume transaction processing, performing a significant number of mathematical calculations and processing communications and database searches. In one or more embodiments, game server 200 comprises a conventional personal computer or computer workstation with sufficient memory and processing capability to perform the disclosed functionality. A processor such as the 1.8 GHZ Pentium® 4, commonly manufactured by Intel Inc., may be used for CPU 205. In other embodiments, game server 200 operates as a Web server, both transmitting and receiving communications to and from player terminals 300.
  • [0036] Cryptographic processor 210 supports the encoding and decoding of communications with players, as well as the authentication of players. An MC68HC16 microcontroller, commonly manufactured by Motorola Inc., may be used for cryptographic processor 210. This microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHZ configuration and requires less than one second to perform a 512-bit private key operation. Other exemplary commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHZ Roadrunner 284. Alternatively, cryptographic processor 210 may be configured as part of CPU 205.
  • As used herein, encoding and decoding refer to any method of disguising and revealing a message or signal, respectively. These methods include the use of key-based algorithms, codes, steganography, substitution ciphers, transposition ciphers, one-time pads, hash functions, and so on, including various combinations of any such techniques. For a more complete list of encoding and decoding techniques, see Bruce Schneier, [0037] Applied Cryptography: Protocols, Algorithms, and Source Code in C, (2nd ed., John Wiley & Sons, Inc., 1996). Cryptographic processor, 210, may support any of these techniques. A conventional random number generating processor may be used for random number generator 225. The HEMT integrated circuit manufactured by Fujitsu, for example, is capable of generating over one billion random numbers per second. Alternatively, random number generator 225 may be incorporated into CPU 205.
  • [0038] Payment processor 230 supports the transfer and exchange of payments, charges, or debits. Functions performed by payment processor 230 include the preparation of on-line account statements, order-taking, credit card payment authorization, credit card settlement, automated sales tax calculations, digital receipt generation, account-based purchase tracking, and payment aggregation for low-priced services. Processing of credit card transactions by payment processor 230 may be supported with commercially available software, such as the Secure Webserver manufactured by Open Market, Inc. This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters where card verification and processing is handled. Their Integrated Commerce Service provides back-office services necessary to run Web-based businesses. Payment processor 230 preferably comprises a microprocessor (such as the Intel Pentium® 4), but alternatively may be configured as part of CPU 205.
  • [0039] Data storage device 250 may include hard disk, magnetic, or optical storage units, as well as CD-ROM drives or flash memory. Data storage device 250 contains databases used in the processing of transactions in the present invention, including player database 255, player selection data database 260, game result database 265, player random number database 270, player decoding key database 275, audit database 280, payment database 285, player account database 290, game server random number database 292, game server encoding key database 294, game server decoding key database 296, and combination protocol database 298. In a preferred embodiment, database software such as Oracle9i™, manufactured by Oracle Corporation, is used to create and manage these databases.
  • For illustration purposes, FIG. 2A provides a structural diagram of an exemplary player [0040] selection data database 260. As shown, selection data database 260 maintains data on selections made by a player, and includes fields for saving player ID number 261, tracking number 262, game selected 263, amount of wager 264, time of wager 266, type of wager 267, and a game result 268.
  • FIG. 2B illustrates another example of a database, this time, the [0041] game result database 265. As shown, game result database 265 tracks the results associated with each set of player selection data and includes fields for the player ID number 261, selection data tracking number 262, game result 268, result value 269, time of result 271, and status of payment 272.
  • The meaning of the information in these various fields will become more clear in the following descriptions. The other databases are organized in a similar manner, thus separate figures of each are not necessary. [0042] Player database 255 maintains data on players, and includes fields such as name, address, credit card number, phone number, ID number, social security number, electronic mail address, past system usage, public/private key information, and game preferences. This information is preferably obtained when the player first registers with the system. Player database 255 also contains the tracking number of each player selection data and player random number generated by a player.
  • Player [0043] random number database 270 stores all player random numbers. This database is indexed by player ID and contains fields such as player ID number, corresponding selection data tracking number, tracking number of a corresponding player decoding key, a player random number, and the time at which the player random number was received by game server 200.
  • Player decoding [0044] key database 275 facilitates the decoding of the player random number, storing the keys necessary to decode communications from a player. For messages encrypted using a public key encryption system such as RSA, Data Security Inc.'s player public keys will be stored in player decoding key database 275. In a symmetric key cryptographic system such as Data Encryption System (“DES”), symmetric keys are stored. Both symmetric and public keys are long strings of binary digits, and are explained more fully below with respect to cryptographic authentication embodiments.
  • [0045] Audit database 280 stores transactional information relating to a player and, in one or more embodiments, includes the time and date of each player log in, and the number of games played.
  • [0046] Payment database 285 tracks all payments made by the players with fields such as player name, player ID number, amount of payment, and corresponding player selection data and a game result. This database may also store credit card numbers of players or bank account information.
  • [0047] Player account database 290 may be established if the player wants to keep a balance of funds at game server 200 for future transactions. Player account database 290 acts as a checking account, with winnings deposited and losing wagers subtracted. Alternatively, this account may be a pointer to account data stored at the player's bank, storing only the name of the bank and the player's bank account number.
  • Game server [0048] random number database 292 tracks all game server random numbers generated by game server 200 and, in one or more embodiments, includes fields such as corresponding player selection data tracking number, player name, player ID number, the time that game server random number was generated, and the time that the game server random number was transmitted to the player.
  • Game server encoding [0049] key database 294 stores all encoding keys used by game server 200 to encode the game server random number.
  • Game server decoding [0050] key database 296 stores all decoding keys transmitted to player terminal 300 to decode the game server random numbers.
  • Finally, [0051] combination protocol database 298 stores the protocols used to combine a player random number with a game server random number to form a result value.
  • Referring again to FIG. 2, [0052] network interface 245 is the gateway to communicate with players through respective player terminals 300. Conventional internal or external modems may serve as network interface 245. Network interface 245 preferably supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a T1 or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected to the Internet and/or a commercial on-line service such as America Online, CompuServe, or Prodigy, allowing players access to game server 200 from a wide range of electronic connections. Several commercial electronic mail servers include the above functionality. For example, NCD Software manufactures “Post. Office,” a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet. This product is platform independent and utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video, and audio. This product also supports multiple languages. Alternatively, network interface 245 may be configured as a voice-mail interface, web site, electronic Bulletin Board System (“BBS”), or electronic-mail address.
  • While the above embodiment describes a single computer acting as [0053] game server 200, those skilled in the art will realize that the functionality can be distributed over a plurality of computers, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain, at a minimum, RAM, ROM, and a general processor. Each of these controllers is attached to a WAN hub which serves as the primary communication link with the other controllers and terminals. The WAN hub may have minimal processing capability itself, serving primarily as a communications router. Those skilled in the art will appreciate that an almost unlimited number of controllers may be supported.
  • FIG. 3 illustrates the basic hardware and data structures of a player terminal in accordance with a preferred embodiment of the invention. [0054] Player terminal 300 preferably includes central processor (CPU) 305, cryptographic processor 310, RAM 315, ROM 320, random number generator 325, video driver 327, video monitor 330, clock 335, communication port 340, input device 345, modem 350, and data storage device 360. Biometric device 355 may be added for increased security, as described below with respect to cryptographic authentication embodiments. A processor such as the 1.8 GHZ Pentium® 4 described above may be used for CPU 305. A conventional random number generating processor such as the HEMT integrated circuit described above may be used for random number generator 325. Alternatively, random number generator 325 may be incorporated into CPU 305. Clock 335 is a standard chip-based clock which can serve to time stamp transactions between player terminal 300 and game server 200.
  • In an exemplary embodiment, [0055] player terminal 300 is a conventional personal computer having an input device, such as a keyboard, mouse, or conventional voice recognition software package. Player terminal 300 would thus interface with game server 200 via modem 350. Alternatively, player terminal 300 may be a voice-mail system, or other electronic or voice communications system. Devices such as fax machines or pagers are also suitable terminal devices.
  • [0056] Modem 350 may not require high-speed data transfer if most player selection data and player random numbers are text-based and not too long. For cryptographic processor 310, the MC68HC16 microcontroller described above may be used. The structure of biometric device 355 will be described in conjunction with the cryptographic authentication embodiment.
  • [0057] Data storage device 360 preferably comprises a conventional magnetic-based hard disk storage unit such as those manufactured by Seagate. Selection data database 365 records all selection data generated by a player, tracking games selected, type of bet, amount of wager, etc. Audit database 370 stores communications between player terminal 300 and game server 200. Encoding key database 375 stores keys used in the process of encoding communications transmitted to game server 200. Combination protocol database 380 stores the protocols used by game server 200 to combine a player random number and a game server random number. Game result database 385 stores all of the players' results, including amounts won or lost. Player random number database 390 stores each random number generated by a player. Game server random number database 395 stores all game server random numbers received from game server 200. This database may also store the corresponding decoding keys in the event that a game server random number is encoded.
  • [0058] Player terminal 300 communications are preferably software driven. There are many commercial software applications that can enable the communications required by player terminal 300, the primary functionality being message creation and transmission. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address. When game server 200 is configured as a Web server, conventional communications software, such as the Internet Explorer™ Web browser from Microsoft Corporation may also be used. The player may use the Internet Explorer™ browser to transmit and receive random numbers and selections.
  • Having described the system and component architecture, we will now consider various embodiments of the present invention to ensure the integrity of electronic games. [0059]
  • As discussed, in one or more embodiments of the present invention, communications between [0060] player terminal 300 and game server 200 take place via one or more electronic networks, preferably with game server 200 acting as a Web server.
  • FIG. 4 illustrates a process by which a player transmits a player selection to a game server. Initially, a player logs on to [0061] game server 200 using player modem 350 of player terminal 300, establishing a communication link at step 400. At step 410, the player selects the game that he wants to play by selecting from a list of possible games. The player may, for example, select a potential game from a list on a Web page by clicking on the appropriate icon or graphic. Games preferably include casino games such as blackjack, craps, roulette, baccarat, slot machines, lottery, poker, video poker, and sports betting, but may include any game in which a first party (e.g., a server) generates a random number that must be trusted by a second party (e.g., player), including raffles and prize drawings.
  • There are many types of games having a random component that are not typically considered casino games or “games of chance.” For example, many board games, such as Scrabble™ or Monopoly™, as well as card games, such as Bridge or Hearts, may typically be considered “games of skill” or non-casino games. Many such games, however, have an element of randomness, such as a dice roll, a selection of letters, a shuffled deck of cards, and/or a deal of cards. Thus, any game in which one party generates a random number that must be trusted by another party may be provided for in accordance with various embodiments of the present invention. [0062]
  • After the game is selected, the player selects a type of wager at [0063] step 420. The type of wager is directly related to the game selected. The type of wager for a roulette game might be, for example, a bet on “even”, or a single number bet, such as “18 black.” For a game like blackjack, the type of wager would indicate the number of simultaneous hands the player intends to play.
  • At [0064] step 430, the player then selects the amount of each wager. For example, the player might bet one hundred dollars on the next blackjack hand, or may bet five dollars on the next pull of a slot machine. The player may elect to use funds from player account database 290 or may transmit payment information such as a credit card number along with the total amount wagered. At step 440, the player attaches his name or a unique player ID number to his selections, allowing game server 200 to authenticate the identity of the player. This ID number is preferably received from game server 200 when the player registers with the service or is chosen by the player and then registered with game server 200 by phone. As shown in FIG. 2A, game server 200 maintains a database of player ID numbers in player database 255 and issues (or allows) only unique numbers. If less security is required, the player's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, procedures such as those described below with respect to cryptographic authentication embodiments may be implemented.
  • At [0065] step 450, all of the data provided by the player is combined to form “selection data” which is transmitted to game server 200. Game server 200 then receives the player selection data and adds a tracking number before storing it in selection data database 260.
  • Instead of a World Wide Web-based interface, players may also transmit the selection data via electronic-mail, voice-mail, or facsimile transmissions. With voice-mail, the player calls [0066] game server 200 and leaves selection data in audio form. Selection data is then transcribed into digital text at game server 200 by a conventional audio-to-text transcriber, not shown. As described, game server 200 supports a plurality of transmission methods, allowing for a wide variety of formats of selection data.
  • The selection data need not include each of a type of game, a type of wager, and the amount of a wager. In some embodiments, a type of wager and/or an amount to wager may be stored at the game server as player preferences, for example, in [0067] player database 255. For example, the player may only need to indicate a type of game in the selection data, and the game server may look up the player's preferences for type of wager and/or amount of wager in player database 255 based on the type of game. Of course, some types of games may be offered that do not require the player to make a wager at all. In some embodiments, the type of game preferred by the player may be associated with the player as a preference, for example, in player database 255. Accordingly, in one or more embodiments of the present invention, the player selection data may not include a type of game, a type of wager and/or a wager amount.
  • FIG. 5 illustrates a process by which a player generates and encodes a random number for use by the [0068] game server 200. At step 500, the player generates a player random number either by selecting a number himself or prompting random number generator 225 of player terminal 300 to produce the number. Although this number is preferably random, the system works equally well with any number that cannot be predicted by game server 200. Random number generator 225 may incorporate external factors, such as the time between keystrokes of the player, or the current position of a computer mouse. At step 510, player terminal 300 stores the player random number in player random number database 390. At step 520, cryptographic processor 310 encodes the player random number using an encoding key from encoding key database 375. Because each player random number preferably uses a unique encoding key, encoding key database 375 preferably contains either a large number of unique keys or generates new encoding keys in real-time. Various methods for encoding numbers are known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, (2nd ed., John Wiley & Sons, Inc., 1996).
  • As noted above, a number transmitted by one party to another for use in a combination protocol need not be a random number, but may be any number that cannot be predicted (or cannot be predicted easily) by the other party. It will also be understood that the data transmitted for use in a combination protocol may be any signal, data, or information that is unlikely to be predicted by the other party. Such signals may include, without limitation, one or more numbers, random numbers, letters, alphanumeric characters, audio signals, video signals, algorithms, or any combination of such information. Any such signals may be selected by the party directly (e.g., a process for selecting a signal need not include any randomness). Although various embodiments are described herein as relating to random numbers, it will be understood that the various embodiments may employ any of the signals described herein. [0069]
  • Along with an encoded player random number, the player appends his player ID number and the tracking number (see FIG. 2A) to the corresponding selection data so that [0070] game server 200 knows to which wager the player random number should apply. This information is then transmitted to game server 200 using player modem 350 at step 530. In order to authenticate the player's identity, game server 200 extracts the player ID number from the message containing the encoded player random number and looks up the player's identity in player database 255. If further authentication is desired, the protocols of the authentication embodiments discussed below may be employed.
  • FIG. 6 illustrates a procedure used by [0071] game server 200 to generate and encode a game server random number. After authenticating a player, random number generator 225 of game server 200 generates a game server random number at step 600. At step 610, the game server random number is stored in game server random number database 292. At step 620, cryptographic processor 210 of game server 200 encodes the game server random number. As with the encoding of the player random number, cryptographic processor 210 preferably has access to a large supply of unique encoding keys or an algorithm to produce them. At step 630, game server 200 then transmits encoded game server random number to player terminal 300. It should be noted that there are a number of hardware options for the receipt of the encoded game server random number at player terminal 300.
  • In this embodiment, the system remains secure because the random numbers have been generated and exchanged for future verification, but have not yet been decoded. As such, both parties know that the random numbers have been generated independently, ensuring a fair game result. [0072]
  • FIG. 7A illustrates a procedure for exchanging decoding keys between the [0073] player terminal 300 and game server 200. At step 700, game server 200 (for the first time) transmits game server decoding key to player terminal 300. Like the encoding key used to encode the game server random number, the game server decoding key must be unique for each random number generated. At step 710, the player terminal 300 transmits a unique player decoding key to game server 200. In this embodiment, this exchange of decoding keys need not take place simultaneously since both parties are already in possession of each other's encoded random number. At step 720, game server 200 uses the player decoding key to decode the player random number. At this point, game server 200 now has both a player random number and a game server random number in decoded form and can use these numbers to generate a game result. The player need only decode the encoded game server random number in the event of a dispute, as described below.
  • FIG. 7B illustrates, in flow diagram form, the process described in FIGS. 5 through 7A. As illustrated, the [0074] player terminal 300 ultimately transmits to the game server 200 both an encoded player random number, Ep(Mp) (750) and a player decoding key Dp (760). The game server transmits to the player terminal both an encoded game server random number E1(M1) (740) and a game server decoding key D1 (730).
  • FIG. 8 illustrates a procedure for the [0075] game server 200 to generate a game result. As shown, game server 200 generates a game result based on the game server random number and the decoded player random number using the combination protocol from combination protocol database 298 (FIG. 2). At step 800, the combination protocol is retrieved from combination protocol database 298. The combination protocol is preferably known to both the player terminal 300 and game server 200, is unique to the particular game selected, and may be published for anyone to read. The combination protocol is preferably a series of mathematical steps which transform the player random number and the game server random number into a distinct “result value.”
  • For example, a single game of roulette may have thirty-eight possible outcomes, each outcome corresponding respectively to one of the thirty-eight positions on a roulette wheel. Therefore, an appropriate combination protocol for a roulette game may be one that provides a result value that is, for example, an integer between 0 and 37, inclusive (e.g., thirty-eight distinct values). Each result value can then be mapped to an outcome on a roulette wheel, such as such as “1”, “2”, or “00”. In one example, the combination protocol developed for a roulette game may indicate that the player random number and the game server random number are first multiplied together, with the resulting number squared. This result is then added to the number 5. The remainder, after dividing this resulting number by 38, is the “result value.” The result value in this example, therefore, is an integer between 0 and 37, inclusive. For the roulette game, the possible result values (e.g., the thirty-eight integers between 0 and 37, inclusive) are mapped with the set of thirty-eight possible outcomes for the spin of a roulette wheel. Thus, the result value corresponds to the result of the spin of a roulette wheel. [0076]
  • At [0077] step 810, the result value is then compared to the type of wager in the player selection data in database 260 to determine a game result. For example, in the roulette example, a player making a bet on “fifteen-red” (see FIG. 2A) would lose the wager if the result value were any number other than “fifteen-red.” The game result for a loss might be “lose one dollar” for a one dollar wager. At step 820, the game result is then transmitted to player terminal 300. Payment processor 230 of game server 200 then decrements player account 290 by one dollar, or charges the player's credit card one dollar (step 830), then stores the game result in game result database 265, indexed by the player ID number (step 840). For an improved audit trail, in one or more embodiments the game result is time stamped by clock 235 of game server 200 before being stored, or is cryptographically chained to previously stored game results. The corresponding player selection data stored in selection data database 260 is then updated to indicate that a result has been reached in step 850 (see e.g. the “result” column in FIG. 2). The player may now begin the cycle again by selecting another set of player selection data.
  • Using one or more of the methods described above, a player may be confident that the random numbers were generated independently of one another. For [0078] game server 200 to cheat, it would have to decode the player random number before generating the game server random number. With knowledge of the player random number, game server 200 could select a game server random number to obtain a desired result value and, hence, game result. Obtaining the player random number before generating the game server random number, however, requires game server 200 to decode the encoded player random number, which cannot be accomplished practically before receiving the player decoding key. If the player suspects that game server 200 has cheated by not properly incorporating the player random number, he can decode the game server random number using the game server decoding key and apply the combination protocol from the combination protocol database 380 at the player terminal 300 to both random numbers, thus verifying the game result.
  • In some embodiments of the present invention, [0079] player terminal 300 and game server 200 exchange random numbers. In some embodiments both parties transmit an encoded random number to the other party. In some embodiments, however, only one of the parties needs to encode its random number. The party transmitting its random number without encoding the random number preferably waits until it has received the coded random number from the other party before transmitting its random number. Such embodiments will now be discussed with reference to FIGS. 9 and 10A-10B.
  • Referring to FIG. 9, [0080] player terminal 300 has already generated a player random number, encoded it, and transmitted it to game server 200 in a manner similar to that described for the mutual encoding embodiments. At step 900, game server 200 generates a game server random number and, at step 910, stores it in game server random number database 292. At step 920, game server 200 transmits the game server random number to player terminal 300. Since no encoding takes place, however, game server 200 does not transmit a game server decoding key.
  • As shown in FIG. 10A, after receiving the game server random number, [0081] player terminal 300 transmits a player decoding key to game server 200 at step 1000. At step 1010, game server 200 uses the player decoding key to decode the encoded player random number. At this point, each party is in possession of the other party's respective random number. The random numbers are then combined as described above to generate a game result.
  • In some embodiments, [0082] player terminal 300 generates and transmits encoded player random number before game server 200 generates and transmits the game server random number. Then, after receiving the game server random number, player terminal 300 transmits the decoding key for the game server 200 to decode the encoded player random number. In one or more alternative embodiments, game server 200 and player terminal 300 switch procedures. Specifically, game server 200 generates and transmits an encoded game server random number before player terminal 300 generates and transmits the player random number. Then, after receiving the player random number, the game server 200 transmits the decoding key for the player terminal to decode the game server random number should the player so choose.
  • FIG. 10B illustrates, in flow diagram form, one or more embodiments in which only one random number needs to be encoded. In FIG. [0083] 10B, the player terminal 300 transmits to the game server 200, both the encoded player random number, Ep(Mp) (1030), and the player decoding key, Dp (1040). The game server 200 transmits to the player terminal 300 only the game server random number M1 (1020).
  • Again, in these embodiments, both the player and the [0084] game server 200 may be confident that the player random number and the game server random number were developed independently.
  • In one or more embodiments of the present invention, neither [0085] player terminal 300 nor game server 200 encodes their respective random numbers. Instead, player terminal 300 generates a player random number, hashes it, sends the hash value to game server 200, and then receives the game server random number. The player terminal then transmits the player random number to game server 200, where it is hashed and then compared to the hash value previously received to determine whether it is the number originally generated by player terminal 300. Operation of this embodiment is illustrated in the flow diagrams of FIGS. 11-13A.
  • Referring to FIG. 11, [0086] player terminal 300 has already transmitted player selection data to game server 200 as described above. At step 1100, player terminal 300 then generates a player random number as previously described. At step 1110, the player random number is stored in player random number database 390 of player terminal 300. Cryptographic processor 310 then hashes the player random number at step 1120, generating a hash value. This hash value represents a one-way transformation of the original player random number. While it is computationally simple to generate the hash value from the player random number, it is computationally unfeasible to re-create the player random number from the hash value alone. At step 1130, player terminal 300 transmits the hash value to game server 200.
  • As shown in FIG. 12, [0087] game server 200 then generates a game server random number at step 1200. This number cannot be based on the player random number since, in this embodiment, game server 200 only possesses the hash value of the player random number. At step 1210, game server 200 stores the game server random number in game server random number database 292, then, at step 1220, transmits the game server random number to the player terminal.
  • Referring to FIG. 13A, [0088] player terminal 300 receives and stores the game server random number at step 1300. At step 1310, player terminal 300 then sends the unhashed player random number to game server 200. At step 1320, cryptographic processor of the game server 200 hashes the player random number, comparing the resulting hash value to the hash value received from player terminal 300. If the hash values match, then game server 200 is assured that player terminal 300 has not submitted an altered player random number. With both random numbers now in its possession, game server 200 then proceeds to generate a game result as described above.
  • FIG. 13B illustrates, in flow diagram form, various hash value embodiments. In FIG. 13B, the [0089] player terminal 300 transmits both the hashed player random number, Hash(Mp) (13A30), and the player random number, Mp (13A40), to the game server 200. The game server 200 transmits to the player terminal 300 the hashed game server random number, Hash(M1) (13A20), and the game server random number, M1 (13A10).
  • In one or more embodiments employing a hash value operation, the [0090] player terminal 300 generates and transmits a hash value of its random number as described above. However, in one or more alternative embodiments, the hash value of a random number may be generated by game server 200, in which case the corresponding procedures of the game server 200 and player terminal 300 are switched.
  • The various embodiments providing for a hash value described above might not allow a player to determine whether a game server has generated only one random number. The game server, for example, may discover two or more numbers with identical hash values, and transmit the hash value to the player terminal. When the game server later receives the player number, the game server may determine which of the two or more numbers with identical hash values to use in the combination protocol (e.g., the number that will provide a result value and/or game result most favorable to the game server). The game server then transmits the chosen number to the player terminal. Since the chosen number hashes to the hash value sent earlier to the player terminal, the player may not suspect that he has been cheated. [0091]
  • To make the above-described method of cheating more difficult, high quality hash algorithms may be required. As will be understood by those having ordinary skill in the art, a high quality hash algorithm makes it computationally infeasible, given only a particular value, V, to generate any number, N, that hashes to V. One criterion of a good hash function is that the hash value be of a particular minimum length. For example, if a hash value is a binary sequence of length 10, then the game server would need hash at most 2[0092] 10+1, or 1025, different numbers before finding two numbers with identical hash values. For most hashing algorithms, a modern computer could very quickly run the algorithm 1025 times, thereby rendering the algorithm ineffective. Therefore, hash values preferably should be of such length that it would be computationally infeasible to test enough numbers so as to find two numbers whose hash values are identical.
  • In one or more embodiments, [0093] player terminal 300 and game server 200 simultaneously exchange random numbers, eliminating the need for any coding or hashing to ensure the independence of the generation of the random numbers.
  • FIG. 14 illustrates a procedure for this embodiment. In FIG. 14, [0094] player terminal 300 has already transmitted player selection data as described above. At step 1400, player terminal 300 generates a player random number, then stores it in player random number database 390 at step 1410. At step 1420, game server 200 generates a game server random number and, at step 1430, stores it in game server random number database 292. At step 1440, the player random number and the game server random number are simultaneously posted to an electronic bulletin board. In one or more embodiments, this is accomplished by setting a time at which the random numbers are to be posted. For example, both parties agree to post the random numbers at 3:00 PM, and incorporate this time into their respective communication software. At 3:00 PM, the communications software (not shown separately) automatically posts the random numbers. To deter cheating, the operating system of the electronic bulletin board may be configured to void any random number not posted within a desired period of time (e.g., one thousandth of a second, one tenth of a second) from the agreed-upon posting time. This time requirement is preferably so small as to make the reverse calculations using a combination protocol computationally infeasible.
  • In one or more embodiments, neither party's number is readable by the other party until after each party has posted its number, for example, to an electronic bulletin board. Therefore, even if the player posts his number first, for example, the game server cannot view the number, and cannot use the player number to generate a desired game server number. Accordingly, the above-described time period for posting may be unnecessary to deter cheating. Of course, a time requirement for posting may be still be preferred in order to ensure a reasonable rate of play for various games. For example, the game server and the player terminal may be required to post their respective numbers at any time between 3:00 PM and 3:01 PM. The parties' numbers may be made accessible as soon as both parties have posted, or at any time thereafter. In some embodiments, the game server and the player terminal are thus able to receive the other party's posted number at substantially the same time. Of course, the parties need not actually access each other's posted number at the same time. [0095]
  • Once the player random number and the game server random number have been posted, a game result may be generated, according to various embodiments of the present invention described herein. [0096]
  • Various methods and systems described herein may be applied to games that are primarily based on chance, such as roulette or craps, and also to games that may be based primarily on player skill but also have an element of randomness. For example, Scrabble™ is a widely-played board game whose object is to assemble letters into words in such a way as to accumulate more points than your opponent. A good Scrabble™ player typically has a large vocabulary and an ability to spot patterns in a random arrangement of letters. Scrabble™ is played in competitions, and there are clear gradations in skill levels. However, there is some randomness in Scrabble™. For example, a player receives letters to complete a group or “hand” of letters from which he can form words; the player typically selects or receives the letters at random. Accordingly, various processes and systems described herein could be used to assure a player (and/or a game server) that the process of letter selection is fair. [0097]
  • For example, in one or more embodiments, each available outcome (e.g., letter selection in Scrabble™) may be mapped to a respective result value, in a manner similar to that described above with respect to a game of roulette. For example, the available letters may be arranged in a predefined order (e.g., alphabetical, by point value), or may be sequenced at random. The position of a letter in the sequence may then correspond to a particular result value. A player and a game server might each select a random integer in the range of 1 to the number of available letters, inclusively. According to an exemplary combination protocol, the player number and the game server number are added, and the result taken modulo the number of letters remaining. One is added to that result to obtain a result value. The result value is then used to select the letter with the position in the sequence that corresponds to the result value. For example, a result value of 8 would select the eighth letter in the sequence of available letters. [0098]
  • Bridge is a card game in which two teams of two compete to either obtain a predicted number of card tricks, or to prevent the other team from doing so. In Bridge, the conduct of the auction and the play phases of the game may require tremendous skill. However, the initial dealing of the hands, as in various other card games, involves chance, as cards are typically shuffled before being dealt. Accordingly, various methods and systems described herein may apply to the dealing of cards in a bridge game. [0099]
  • In one or more embodiments of the present invention, the cards start out in a predetermined order. Each team then submits a random integer in the range of 1 to 52. The integers are added, the result taken modulo 52, and then one is added to determine a result value. The result value indicates the position of the card in the initial ordering with which the first card in the initial ordering should be swapped. Then each team submits another random integer in the range of 1 to 52. The integers are added, the result taken modulo 52, and then one is added. The resulting number indicates the position of the card in the current ordering with which the second card in the current ordering should be swapped. The process continues for a total of 52 times, so that for each possible card position, a card in that position is swapped with another random card. That way, once each team has submitted 52 random integers in the range of 1 to 52, inclusively, the deck has been shuffled, and play can proceed. [0100]
  • Another game involving predominant skill, but some randomness, is a word game involving the placement of letters into a five by five grid. In this game, players receive 25 random letters, one at a time, and must place the letters within the five by five grid. At the end of the game, a player's point total is based on the number of rows and columns in which the player has spelled a word, and the length of the longest word in each row and column. A skilled player may have a large vocabulary and a good feel for where letters are most likely to occur in words. However, there is an element of chance in the game in that a player cannot know in advance what letters he is to receive. Therefore, the methods of this invention can be used to assure a player that he receives letters fairly, and doesn't purposely receive, for example, letters that would make it impossible for him to complete any words. In one or more embodiments, the player terminal and the game server might each generate random numbers in the range of 1 to 26. The combination protocol then adds the numbers, takes the result modulo 26, and adds one. The result value is then used to select the letter with the corresponding position in the alphabet. [0101]
  • Various embodiments described herein relate to protocols in which one player interacts with [0102] game server 200. Multiple players could easily be handled by treating each player individually, with players receiving individual game results. Five roulette players, for example, could each submit player selection data and receive a game result based on a different result value. Alternatively, players could combine their player random numbers and receive a game result based on a single communal result value. In this way, game server 200 may more closely parallel a physical casino in which a group of players face wins or losses based on the same spin of the wheel.
  • In various embodiments involving multiple players, each player generates selection data describing the type of wager that they want to make. [0103] Game server 200 then generates a game server random number and encodes it using cryptographic processor 210. Each player terminal 300 generates a player random number and encodes it with its respective cryptographic processor 310. Each player terminal 300 then transmits its encoded player random number to game server 200. Once game server 200 has collected all encoded player random numbers, it transmits the encoded game server random number to each player terminal 300. After receiving the encoded game server random number, each player terminal 300 transmits its player decoding key to game server 200. Game server 200 decodes each encoded player random number and uses them to generate a game result using the combination protocol from combination protocol database 298, which may store different protocols for various numbers of players, up to the maximum number of players allowed in a game. The game result is transmitted to each player terminal 300. Players can verify the result value by exchanging decoded player random numbers with each other and comparing them with the game server random number after decoding it with a game server decoding key.
  • In one or more embodiments, each [0104] player terminal 300 generates player selection data and a player random number. The first player encodes his player random number and transmits it to the second player. The second player concatenates his random number with the encoded random number from the first player, and encodes both numbers before sending them to the third player. This process continues for each of the players. The last player sends the combined player random number to game server 200. Game server 200 creates a game server random number, encodes it, then transmits it to each player. After receiving the game server encoded random number, each player terminal 300 sends its player decoding key to game server 200. Cryptographic processor 210 of game server 200 decodes the combined player random number using these decoding keys, forms a result value, and produces a game result for each player.
  • As will be understood by those having ordinary skill in the art, instead of, or in addition to, the mutual encoding described above, hash algorithms, single encoding, and simultaneous exchange procedures consistent with those described above may be used to facilitate the interaction of multiple players. [0105]
  • Outcomes for gambling games are determined by either a single event or a multiple event. Roulette and slots are good examples of single event games as a single outcome determines the game result. One spin of the roulette wheel completely resolves all bets placed on that spin. The result of a slot machine wager requires a single handle pull to determine whether the player wins or loses. In these single event games, a result value is easily compared to player selection data to determine a game result. [0106]
  • In multiple event games, however, a game result may be based on multiple result values. Blackjack is one example of a multiple event game. Whether a player wins a hand depends on the player's cards and the dealer's cards. Accordingly, in one or more embodiments of the invention, a result value represents the complete sequence of fifty-two cards. Once the card sequence is defined based on the player random number and the game server random number, the cards can be dealt. [0107]
  • For example, after generating an encoded player random number and transmitting it to [0108] game server 200, player terminal 300 receives the encoded game server random number. Player terminal 300 then transmits a decoding key to game server 200 which generates the result value representing the complete sequence of cards in the deck. Before sending a game server decoding key to player terminal 300, game server 200 sends the player card values representing a hand of cards dealt from the sequence of cards generated by the result value. If he desires, the player then elects to draw additional cards for his blackjack hand, again, from the defined sequence of cards. Once the hand is selected, game server 200 transmits a game server decoding key to player terminal 300. It is important that the player not receive this key before making his selection to draw additional cards, since decoding the game server encoded random number would allow the payer to know the complete sequence of cards.
  • Another method for handling multiple event games, such as blackjack games, is to generate a result value for each event (e.g., each card dealt, each hand dealt). In a blackjack example, after making his bet (by establishing player selection data) the player generates a series of player random numbers, exchanging them with [0109] game server 200 for each card required in the hand. The game result might therefore require seven or eight result values, each one created according to one or more of the various described procedures of the present invention.
  • Accordingly, it will be understood by those having ordinary skill in the art that a single result value may correspond to one or more events. For example, as described herein, one result value may be used to determine only a corresponding single card, or a single result of a slot machine spin. As also described herein, one result value may also correspond to a series, set, or sequence of events, such as a plurality of cards (e.g., a deal of cards, a hand of cards, or a deck of cards). A particular game, system, or application need not use all determined result values in any one way. Accordingly, a particular game, system, or application may use a first result value to determine a single event and a second result value to determine multiple events. Specifically, it will be understood that any particular determined result value may be used to determine a corresponding single event or corresponding multiple events, as considered practicable for the particular game, system or application. [0110]
  • In certain embodiments of the present invention, authentication of authorship of the player selection data and player random number involves checking an attached ID or name and comparing it with those stored in [0111] player database 255. In an alternative embodiment, cryptographic protocols are added to the authentication process. These protocols enhance the ability to authenticate the sender of a message and serve to verify the integrity of the communication itself, proving that it has not been altered during transmission. Encryption can also prevent eavesdroppers from learning the contents of the communication. Such techniques shall be referred to generally as cryptographic assurance methods and include the use of both symmetric and asymmetric keys as well as digital signatures and hash algorithms.
  • The practice of using cryptographic protocols to ensure the authenticity of senders as well as the integrity of communications is well known in the art and need not be described here in detail. Any conventional cryptographic protocols such as those described in Bruce Schneier, [0112] Applied Cryptography: Protocols, Algorithms, and Source Code in C, (2nd ed., John Wiley & Sons, Inc., 1996), could be used in accordance with the present invention and would be executed by cryptographic processor 210.
  • FIG. 15 illustrates a symmetric key embodiment in which [0113] player terminal 300 and game server 200 share a key. Thus, both encryption and decryption of the player selection data and player random number (also referred to separately or together as a player communication) are performed with the same key. This encryption may be implemented with an algorithm such as DES (U.S. Government standard, specified in FIPS PUB 46), or with any of several algorithms known in the art such as AES, IDEA, Blowfish, RC4, RC2, SAFER, etc.
  • Initially, a player encrypts his communication with his assigned symmetric key at [0114] step 1500, using cryptographic processor 310 of player terminal 300. The key may be stored in encoding key database 375 or otherwise stored or memorized by the player. The player communication is then transmitted to cryptographic processor 210 of game server 200 at step 1510. Cryptographic processor 210 extracts the player ID from the player communication (step 1520), looks up the symmetric key of the player in player database 255 (step 1530), and decrypts the player communication with this key (step 1540). Game server encoding key database 294 contains algorithms and keys for encrypting, decrypting, and/or authenticating communications. At step 1550, the cryptographic processor 210 determines if the resulting communication is intelligible. If so, then the communication must have been encrypted by the same key, authenticating that the player must have indeed been the author of the message. It will be understood that these cryptographic techniques are employed to protect the security of the communications, in addition to the appropriate random number encryption technique described above.
  • This procedure makes it difficult for an unauthorized player to represent himself as a legitimate player. Without cryptographic procedures, an unauthorized player who obtained a sample communication from a legitimate player might be able to extract the player ID and then attach this ID number to unauthorized communications. When player communications are encrypted with a symmetric key, however, an unauthorized player obtaining a sample player communication only discovers the player's ID number, not the symmetric key. Without this key, the unauthorized player cannot create a player communication that will fool [0115] game server 200, since he cannot encrypt his communication in the same way that the authorized player could. The symmetric key protocol also ensures that the player communication has not been tampered with during transmission, since alteration of the communication requires knowledge of the symmetric key. An encrypted player communication also provides the player with more anonymity.
  • FIG. 16 illustrates an asymmetric key protocol in which a player communication is encrypted with a private key and decrypted with a public key. Two such algorithms for asymmetric key protocols are the RSA algorithm and the Digital Signature Algorithm (“DSA”). At [0116] step 1600, player terminal 300 encrypts the player communication with the player's private key using cryptographic processor 310. Player terminal, 300 then transmits the player communication to game server 200 at step 1610. Cryptographic processor 210 at game server 200 then extracts the player ID at step 1620, looks up the players associated public key in player database 255 at step 1630, and decrypts the communication with this public key at step 1640. As before, if the player communication is intelligible then game server 200 has authenticated the player at step 1650. Again, unauthorized players obtaining the player communication before it is received by game server 200 are not able to undetectably alter it since they do not know the private key of the player. Unauthorized players might, however, be able to read the message if they managed to obtain the public key of the player. Communication secrecy is obtained if the player encrypts the player communication with his public key, requiring the unauthorized player to know the player's private key to view the player communication.
  • FIG. 17 shows a cryptographic technique using digital signatures to provide authentication and message integrity. One such algorithm is DSA. As in the asymmetric protocol described above, each player has an associated public and private key. The player signs his communication with his private key at [0117] step 1700 with cryptographic processor 310 and transmits it to game server 200 at step 1710. At game server 200, cryptographic processor 210 extracts the player ID at step 1720 and looks up the player's public key at step 1730, verifying the signature using the communication and the public key of the player at step 1740. If the communication is intelligible, then game server 200 accepts the communication as authentic at step 1750.
  • Referring now to FIG. 18, there is illustrated a cryptographic technique using message authentication codes for verifying the authenticity and integrity of a player communication. In the hash protocol of the present invention, [0118] player terminal 300 and game server 200 share a symmetric key, which the player includes in a hash of the communication at step 1800. In the hash protocol, a one-way function is applied to the digital representation of the communication. Any of the MAC algorithms, such as RIPEMAC, IBC-Hash, CBC-MAC, or the like, may be applied in this application. After transmitting the communication to game server 200 at step 1810, cryptographic processor 210 of game server 200 extracts player ID from the player communication at step 1820. Then cryptographic processor 210 looks up the player's symmetric key at step 1830 and hashes the communication with the symmetric key at step 1840, comparing the resulting hash value with the hash value attached to the communication. If the values match at step 1850, the integrity of the communication is verified along with the authenticity of the player.
  • Although cryptographic techniques can provide greater confidence in the authenticity of player communications, they are useless if the players' cryptographic keys are compromised. An unauthorized player who obtains the symmetric key of another player is indistinguishable from that player in the eyes of [0119] game server 200. There is no way to know whether the player was the true author of the communication, or an unauthorized player with the right cryptographic keys. In one or more embodiments, biometric device 355 (FIG. 3) such as a fingerprint reader, voice recognition system, retinal scanner, or the like help to solve this problem. A biometric device incorporates a physical attribute of the player into a communication, which is then compared with the value stored in player database 255 at game server 200.
  • Fingerprint verification, for example, may be executed before the creation of a communication, during the generation of a communication in response to prompts from [0120] game server 200, at some predetermined or random time, or continuously by incorporating the scanning lens into player terminal 300 and requiring the player to maintain a finger on the scanning lens at all times for continuous verification while the communication is generated.
  • An example of such a biometric device is the FingerLoc™ AF-S2™ fingerprint identification system available from AuthenTec, Inc. The AF-S2™ utilizes a sensor matrix, consisting of 16,384 individual elements arranged in a 128 by 128 grid. When a player places his finger on the grid, an electromagnetic signal is generated by a ring surrounding the grid. The resulting electromagnetic field varies according to the ridges and valleys of the player's fingerprint. Each element of the grid then acts as an antenna, picking up the local electromagnetic signal. The elements can distinguish fine variations in the electromagnetic field, and use these variations to generate a digital fingerprint image. The digitized image is then stored in memory. Each live-scan fingerprint is compared against the previously enrolled/stored template, stored in [0121] data storage device 360. If the prints do not match, the cryptographic algorithms executed by cryptographic processor 310 may prevent the player from generating a communication.
  • In a voice verification embodiment, the player's voice is used to verify his identity. This embodiment has the advantage of not requiring the use of any specialized hardware since it can be implemented over a standard phone connection. The player's identity is verified at [0122] game server 200. The process of obtaining a voice-print and subsequently using it to verify a person's identity is well-known in the art, and therefore need not be described in detail. Conventional speaker identification software samples the player's voice. This sample is stored at game server 200 in player database 255. Each time the player wants to transmit a communication to game server 200, he is required to call game server 200 and speak into the phone at the prompt for a voice sample. If this sample matches that stored in player database 255, the player is provided a password which is incorporated into the digital signature appended to his communication. Any communication received without an appropriate voice match password is not accepted. The voice-print may also be stored in a database within data storage device 360 of player terminal 300, to verify the player's identity locally prior to allowing his communication to be created.
  • As mentioned previously, the present invention allows for the anonymity of players. Such anonymity is accomplished by eliminating all references to the names of the players for all communications. A player, for example, would include his ID in the player selection data, rather than his name, preventing eavesdroppers from discovering the player's identity. To prevent detection of a players ID stored in [0123] player database 255, the ID numbers are preferably encrypted with the public key of game server 200.
  • As an additional protection of identity, the player may communicate with [0124] game server 200 through conventional anonymous remailers found on the Internet.
  • While the invention can be implemented without provisions for payment features, there are many methods by which the providers of the foregoing systems could derive a revenue stream. In one or more embodiments, a flat fee is charged for every set of player selection data submitted. In other embodiments, flat fees would cover any number of sets of player selection data over a given period of time, allowing players to subscribe to the service much as they would subscribe to a newspaper. In another embodiment, advertisers pay to have messages listed along with the Web pages for the player selection data, supplementing the costs of operating the system. [0125]
  • In some embodiments of the present invention, the combination protocol may transform the player random number and the game server random number into multiple result values. For example, the multiple result values could represent ten different spins of a roulette wheel, five different rolls of the dice in craps, or twelve different cards drawn in video poker. With multiple result values being generated based on a single pair of random numbers, the player terminal and the game server would have to generate fewer random numbers, and would have to perform fewer encryption and decryption operations, thus speeding up the play of the game. [0126]
  • In a roulette game, for example, the combination protocol may transform the player random number and the game server random number into multiple result values corresponding to multiple spins. In two typical games of roulette, there are 38*38, or 1444, possible sequences of two outcomes (e.g., “1” and “9”; “24” and “24”; or “00” and “12”). Therefore, in one exemplary combination protocol, the player random number and the game server random number might each be a number between 1 and 1444, inclusive. According to the combination protocol, the two random numbers are then added, modulo 1444, to yield a number between 0 and 1443, inclusive. This number is then divided by 38 in order to yield a quotient and a remainder. Both the quotient and the remainder will be numbers between 0 and 37, inclusively. The quotient may thus serve as a first result value, and the remainder may serve as a second result value. Each result value may be mapped to respective individual outcomes, each individual outcome representing, for example, one spin of a roulette wheel. [0127]
  • Although the exemplary combination protocol was described above with respect to two result values for a roulette game, other combination protocols useful for transforming a player random number and a game server random number into one or more result values will be obvious to those having ordinary skill in the art. Similarly, combination protocols useful for various different types of games will be obvious to those having ordinary skill in the art. [0128]
  • In some embodiments of the present invention in which more than one result value is obtained from a game server number and a player number, the player must place wagers on all result values to be obtained from a combination protocol before obtaining a decoding key from the game server. Otherwise, the player would be able to predict future result values by using the combination protocol applied to the player random number and the game server random number. The player could then make wagers only when future result values would be favorable to the player. [0129]
  • In some embodiments, the player, the player terminal, and/or the game server may establish rules for placing wagers on the multiple result values to be obtained from a combination protocol (and/or on the corresponding game results). Such rules could be stored, for example, in [0130] player database 255. A rule might specify, for example, that if the player wins on a first result value, he is to double his wager for the next result value. Another rule might specify that a player is to continue placing wagers on successive result values until his net loss exceeds ten tokens. Once rules for placing wagers have been established, and the player has committed to following such rules, then it no longer matters whether or not the player can anticipate future result values through the use of the game server decoding key. Even if the player knows that future result values will be unfavorable, he is still bound to follow the specified rules for placing wagers.
  • Even if a first party may be confident that a second party has generated its random number independently of the first party's number, the first party may not be sure that the other party has generated only one number. [0131]
  • For example, the game server may attempt to cheat by generating two or more game server numbers, such that each can be encoded to yield the same result. Once the game server knows the player random number, the game server can determine which of the two or more game server numbers to use in the combination protocol in order to achieve a desired game result. For example, after the game server receives the player decoding key, the game server can decode an encoded player random number. Alternatively, an unencoded player random number may have been received. Based on the player random number, the game server then transmits to the player terminal the game server decoding key corresponding to the chosen random number. The game server then uses the combination protocol, the player random number, and the chosen game server random number to generate the game result. [0132]
  • For example, a game server may use the following procedure to generate multiple numbers whose encoded values are identical. First, the game server generates multiple pairs of keys, E[0133] K and DK, representing keys in an asymmetric key algorithm. In each pair, EK is used in combination with an encryption algorithm to generate an encoded version of a number, MK. The encoded number is denoted EK(MK). Given EK(MK), MK can be determined by employing the key DK in a decrypting algorithm. Thus, DK(EK(MK))=MK.
  • At [0134] step 1952 in FIG. 19A, the game server generates multiple decoding keys. The generation of the game server encoding keys is not always necessary. Once the game server has generated the multiple pairs of keys, the game server, at step 1954, chooses a number, M1. The number M1 may be generated randomly or may be chosen by the game server in any other fashion. The game server then generates M2 according to the following formula: M2=D2(E1(M1)). Similarly, M3=D3(E1(M1)), and MK=DK(E1(M1)).
  • The game server initially transmits to the player terminal E[0135] 1(M1), (step 1956). At step 1958, the game server receives from the player the encoded player random number, and at step 1960, the game server receives from the player the player decoding key, which allows the game server to view the player random number (step 1962). At step 1964, the game server may test the combination protocol on the player's number in combination with each of M1, M2, . . . Mn. The game server then chooses a number, MK, from the set of M1, M2, . . . Mn, that yields the result value that is most desirable for the game server. At step 1966, the game server then transmits the corresponding decoding key, DK, to the player terminal. Finally, at step 1968, the game server generates the game result based on the player random number and the chosen game server number.
  • Note that in the above procedure, M[0136] 1 need not be chosen. Rather, E1(M1) may be chosen, and M1 may be derived by M1=D1(E1(M1)). Also note that the encrypting keys, E1 . . . En, need not necessarily ever be generated.
  • FIG. 19B illustrates various embodiments of the present invention in flow diagram form. In FIG. 19B, game server [0137] 190 initially generates three game server decoding keys: D1, D2, and D3 (1970, 1972, and 1974, respectively). Game server 190 ultimately transmits to the player terminal 300 an encoded version of a game server number, E1(M1) (1976), and only one of the three game server decoding keys: D2 (1972). The player terminal transmits to the game server the encoded player random number, Ep(Mp) (1978), and a single decoding key Dp (1980).
  • The exemplary attempt to cheat described above may be overcome in various ways. According to some embodiments of the present invention, when the game server, for example, transmits E[0138] 1(M1) to the player terminal, the game server may also be required to transmit the encoding key, E1, to the player terminal, before the game server can know the player random number (e.g., before receiving an unencoded player random number, or before receiving a decoding key for an encoded player number received by the game server). For example, the game server may be required to transmit the encoding key, E1, to the player terminal before transmitting the encoded game server number, after transmitting the encoded game server number, or along with the encoded game server number.
  • If the game server later transmits to the player terminal a decoding key, say D[0139] 2, that does not correspond to the encoding key, E1, then the player will be able to determine whether he has been cheated. To determine whether the encoding key E1 corresponds to the decoding key D2, the player may, for example, encode a test number, M, with encoding key E1, and then decode the result with decoding key D2. In this example, the decoded result will not be the same as the original number, M. In other words, D2(E1(M)) does not equal M. Therefore, by having the game server transmit the encoding key E1 to the player terminal before the game server knows the player random number, the game server will be motivated to transmit the proper decoding key, D1, to the player terminal.
  • One or more embodiments of the present invention require any random numbers generated to be combined in some fashion with at least one known character, before encoding the combination. For example, suppose the game server generates a random number, 1297. The character sequence “bluesky” is then appended to the end of the number, yielding the combination, “1297bluesky”. The full character sequence, “1297bluesky”, is then encoded with key E[0140] 1 and sent to the player terminal. Now suppose the game server receives the player's encoded number and decoding key, and decides to use a number other than 1297 in the combination protocol. So the game server might attempt to use a decoding key, D2, that does not match the encoding key, E1. D2(E1(1297bluesky)), however, is unlikely to yield a character sequence ending in “bluesky”. That is, D2(E1(1297bluesky)) does not equal “xxxxbluesky”, where “xxxx” represents any set of characters. If the game server sends to the player terminal the decoding key, D2, and the player decodes the game server's first transmission, E1(1297bluesky), and finds that the result does not end with “bluesky”, then the player will realize he has been cheated. To cheat, the game server must determine a new decoding key that does yield a result of the form “xxxxbluesky”. However, such a task may be computationally unfeasible.
  • Of course, in the above example, “bluesky” could be appended to the front end of the number. In some embodiments, at least one character is appended to one end of the number and at least one character is appended to the other end of the number. [0141]
  • Although any set of one or more characters may be used in combination with a random number, certain character sequences may be particularly convenient to use in combination with random numbers. Some of these character sequences may include, without limitation, a player's name, a player's casino card number, a date, or a time. If, for example, it is always a player's name that is appended to the game server random number, then the player does not have to find out at the beginning of a gaming session what appended character sequence to look for. [0142]
  • In one or more embodiments of the present invention, the set of signals that can be transmitted between the game server and the player terminal is limited. The set of signals may be limited to only one signal (e.g., “5”), to a plurality of signals (e.g., “5” and “10”), to a range of signals (e.g., 2 to 12), to particular types of signals (e.g., numbers, random numbers, alphanumeric characters, audio signals, video signals, algorithms), and may be limited by any combination of such limitations. Many other types of limitations will be known to those of skill in the art. [0143]
  • In one example, the player and the game server may be involved in a game of craps. To represent every possible roll of two dice, the game server and the player need only exchange integer random numbers in the range of 1 to 36, inclusively (or in the range 2 to 12, inclusive, to represent just the sum of the die faces). At the same time, the game server and the player terminal employ an encoding algorithm that is capable of handling inputs greater than 36. Therefore, if a game server encodes the number 24, for example, with the encoding key E[0144] 1, but later decodes the result with a decoding key, D2, then the resulting number is most likely to be out of the range 1 to 36. For example, D2(E1(24)) might equal 153982. Therefore, the game server would be forced to search for a new decoding key that yielded a result between 1 and 36, a task that may be computationally unfeasible.
  • Those having ordinary skill in the art will understand that the various techniques described herein for circumventing or discouraging cheating (e.g., cheating in which one party derives more than one number that may be encoded to derive the same value), may be applied alternatively, or in any combination. For example, the range of random numbers may be restricted to a range, and the [0145] game server 200 may be required to transmit an encoding key to player terminal 300. Further, while such embodiments are often described herein as useful for preventing cheating by a game server 200, those having ordinary skill in the art will understand that corresponding techniques may be used, alternatively or in addition, by a game server (or by any party) to prevent cheating by a player (or by any other party).
  • In various embodiments of the present invention, a third party may be involved as an intermediary between the player terminal and the game server. For example, in one or more embodiments of the present invention each party submits its number, unencoded, to a third party. Once the third party receives both numbers, the third party transmits them to the player terminal and to the game server. As an extra measure of security, the player terminal and the game server may first encode their numbers before transmitting them to the third party. The third party may then transmit the encoded numbers to the player terminal and to the game server. The player terminal and the game server may then send decoding keys to the third party. Of course, a decoding key may be transmitted to the third party before the encoded random number is transmitted to the third party, or may be transmitted to the third party along with the encoded random number. After receiving the decoding keys, the third party may then transmit the decoding keys to the player terminal and to the game server. Although, the above example describes mutual encoding of numbers, those having ordinary skill in the art will understand that a third party may similarly be involved as an intermediary in various processes involving single encoding, hash values, etc. [0146]
  • In one or more embodiments of the present invention, the third party first transmits to the player terminal and to the game server an encoding key. The player terminal and the game server may or may not receive the same encoding key. The player terminal uses the encoding key it received from the third party to encode its random number, and may then transmit its encoded number to the game server, either directly or through the third party. Similarly, the game server uses the encoding key it received from the third party to encode its random number, and may then transmit its encoded number to the player terminal, either directly or through the third party. The third party may then transmit decoding keys to the player terminal and to the game server. The player terminal and the game server may or may not receive the same decoding key. Each party is then able to decode the other's random number, and to generate a game result using the combination protocol. Advantageously, the game server is not able to cheat by choosing which of several possible decoding keys to use. Instead, the game server must use the decoding key supplied by the third party. [0147]
  • In one or more embodiments, the player terminal and the game server each transmit their respective numbers, unencoded, to the third party. The third party then uses its own encoding key(s) to encode either or both of the numbers. The third party then transmits the player's number (whether unencoded or encoded) to the game server, and the game server's number (whether unencoded or encoded) to the player. If the player's number is encoded by the third party, the third party also transmits the decoding key for the player's number to the game server. Similarly, if the game server's number is encoded by the third party, the third party also transmits the decoding key for the game server's number to the player terminal. The third party may transmit a decoding key after transmitting an encoded number, before transmitting the encoded number, or along with the encoded number. [0148]
  • As described above, various embodiments of the present invention provide for requiring one or both of the parties to transmit its encoding key to the other party along with its encoded random number, in order to prevent cheating in which once the other party's number is known, a party can determine which of two or more generated numbers to use in the combination protocol in order to achieve a desired game result, and may transmit the corresponding decoding key. [0149]
  • In order to circumvent such cheating, according to one or more embodiments of the present invention, one or both parties may be required to send their encoding and/or decoding keys to a third party before knowing the other party's number. For example, the game server may be required to send its decoding key to the third party before receiving a decoded player number. Of course, the game server may alternatively send the decoding key after receiving an encoded player number, but before receiving the player decoding key (i.e., before it can decode the player number). As described herein with respect to various embodiments, one or both of the parties may also provide a decoding key to the other party. By providing encoding keys and/or decoding keys to the third party, however, if the player questions the decoding key received from the game server, for example, then the player may check with the third party and verify that the decoding key received from the game server was the same decoding key that was received by the third party before the game server knew the decoded player number. In some embodiments, the player and the game server may receive each other's decoding keys directly from the third party. The player and game server are thus prevented from choosing amongst multiple decoding keys to send to the other party. [0150]
  • A third party or intermediary, as described herein, may comprise one or more third parties or intermediaries. Where more than one third party is being used, each may function independently of any others. For example, to exchange numbers, a player terminal may transmit the player random number to one third party, who transmits the number to the game server. The game server may transmit the game server random number to another third party, who transmits the number to the player terminal. In some embodiments involving multiple third parties, the player terminal and/or game server may transmit to, and/or receive information from, more than one third party. For example, a player terminal may transmit the player number to one third party, who transmits the number to the game server. The player terminal may also transmit a player decoding key to another third party, who transmits the decoding key to the game server. Various embodiments of the present invention are described herein as involving an exchange of numbers between two parties, for example, a game server and a player terminal. However, a player terminal and a game server could just as easily exchange many different types of information, including, without limitation, numbers, letters, symbols, pictures, audio signals, video signals, algorithms, or any combination thereof. For example, a particular game of chance may have two possible outcomes, denoted “outcome 1” and “outcome 2”. The player terminal and the game server each provide either the letter “a” or the letter “b”. According to an exemplary combination protocol, if both the letters are the same, then outcome 1 occurs. If both letters are different, then outcome 2 occurs. [0151]
  • In one or more embodiments of the present invention, one party generates a random number, and the other party generates a function or algorithm. In an exemplary combination protocol, the function or algorithm provided by a player is applied to the random number provided by a game server to generate the result value and the game result. For example, the game server generates a number, 4. The player terminal generates an algorithm that says: [0152]
  • 1) Multiply the game server's number by 3 to generate the number x1 [0153]
  • 2) Take x1 modulo 5 to generate the number x2 [0154]
  • 3) Add 1 to x2 to generate the result value [0155]
  • Applying the player algorithm to the game server number, 4, yields: x1=4*3=12; x2=12 modulo 5=2; and a result value of 1+2=3. With the above exemplary algorithm, any integer generated by the game server in the range 1 to 5, inclusively, is mapped to the same range in a one-to-one fashion. That is, if the game server generates the number 1, then the result value will be 4. If the game server generates the number 2, the result value will be 2. If the game server generates the [0156] numbers 3, 4, or 5, then the result values will be 5, 3, or 1, respectively. Thus, assuming valid result values must fall in the range of 1 to 5, the above algorithm is fair in that it allows any result value in the valid range of result values to occur. Furthermore, if the game server number is generated randomly such that each integer between 1 and 5, inclusively, is equally likely to occur, then all result values will also be equally likely to occur.
  • In one or more embodiments of the present invention, both the game server and the player terminal generate algorithms. As will be understood by those having ordinary skill in the art, two or more algorithms may be combined in a combination protocol in a number of ways. For example, in one or more embodiments, the combination protocol specifies an input to the game server algorithm. The input may be a number, such as 14923. The game server algorithm then operates on the input to produce an output. An exemplary output of the game server algorithm might be the number 2094. According to the exemplary combination protocol, the output of the game server algorithm is then used as an input (or as one of multiple inputs) to the player algorithm. The player algorithm then operates on the output of the game server algorithm to produce its own output, which is the result value. [0157]
  • In the above example, as will be understood by those having ordinary skill in the art, the player algorithm could have been run before the game server algorithm (e.g., the combination protocol could have specified a first input for the player algorithm, and the output of the player algorithm could have been an input for the game server algorithm). In some embodiments, rather than having the combination protocol specify the input to the first algorithm, the player terminal or the game server might specify the input to the first algorithm. In some embodiments, the game server and the player terminal specify multiple algorithms. The algorithms may then be chained together in any order, with the output of one serving as the input for the next. Of course, as is well-known in the art, many other ways of combining algorithms are possible. [0158]
  • There are a number of ways in which a function or an algorithm may be represented for the purposes of transmission between the game server and the player terminal. As is well-known, a function may be represented by a set of numerals, letters, and/or symbols composing a mathematical formula. For example, f(x)=(3x mod 5)+1. In this example, x represents the input to the function. The input x may be generated randomly (e.g., by the game server). The output of the player algorithm is represented by f(x), and the right side of the exemplary formula shows how to generate f(x) through the operations of multiplication, modulo division, and addition. [0159]
  • In one or more embodiments, a function or algorithm is represented by computer program code. The code may be in any language, such as C, Java, Basic, or Fortran. The code may be written in compiled or uncompiled form. An exemplary line of code might read, “result_value=(3*input) % 5+1;”. This line of code, written in C, multiplies the “input” variable by 3, takes the result modulo 5, and then adds one to generate the “result_value”. There are many other well-known ways of representing a function or an algorithm using computer program code. [0160]
  • In one or more embodiments, a function or algorithm is represented by a table of inputs and corresponding outputs. For example, the set of inputs might be listed as: 1, 2, 3, 4, and 5. The respective outputs might be listed as: 4, 2, 5, 3, 1. Outputs may be listed in the table, for example, adjacent to their corresponding inputs. [0161]
  • Various embodiments described herein with respect to the exchange of numbers may also apply to an exchange involving at least one algorithm or function. According to one or more embodiments of the present invention, once a function or algorithm has been represented (e.g., in the form of text), then the representation may be encoded. The encoded function or algorithm is then given to the other party, and the other party's encoded number, function or algorithm is received. According to some embodiments, one or more decoding keys may also be exchanged. [0162]
  • In one or more embodiments of the present invention, a full description or representation of an algorithm need not be transmitted to the opposite party. Instead, only particular features or elements of an algorithm need be transmitted, where the rest of the algorithm is understood by both parties. For example, an algorithm may have a fixed structure or template, but may require one or more elements be defined so that the algorithm may generate an output. In one example, an algorithm known to both parties is described by f(x)=(??x mod 5)+1, where “??” represents a multiplier value that must be defined. So, the player terminal, for example, might transmit to the game server the number, 3, whereby the game server understands that the player terminal is describing the function f(x)=(3x mod 5)+1. [0163]
  • Just as, in some described embodiments, the player terminal and/or game server may generate numbers randomly, in one or more embodiments the player terminal and/or game server may generate algorithms randomly. For example, a exemplary base algorithm may have a fixed structure with an undefined multiplier, as described above. The multiplier may be determined randomly, thereby generating the algorithm at random. [0164]
  • In one or more embodiments, a player terminal and/or a game server has multiple possible algorithms stored, for example, in a memory. The game server and/or the player may then choose one of the pre-existing algorithms at random, and transmit the algorithm to the other party. [0165]
  • In one or more embodiments of the present invention, the player and/or the game server represent a function as a table. All possible inputs are listed, for example, in one column of the table. All possible outputs are then ordered at random, and preferably located in an adjacent column of the table. Accordingly, any input may be referenced in the first column, and will yield a random output listed adjacently in the second column. Outputs may or may not be listed multiple times, depending on the desired probability of occurrence of the output. As an example, a function has five possible inputs: 1, 2, 3, 4, or 5, and five possible outputs, also: 1, 2, 3, 4, or 5. To create a random function, the game server lists the possible inputs in order: 1, 2, 3, 4, and 5, in a column. The game server then selects a random arrangement of the outputs, here: 3, 5, 2, 1, 4. Then, the outputs are preferably listed in a column adjacent to the inputs. Thus, an input of 1 would yield an output of 3, an input of 2 would yield an output of 5, and so on. [0166]
  • There are many other well-known methods for generating algorithms randomly; others will be apparent to those having ordinary skill in the art. [0167]
  • Even if a party is confident that two numbers being used in a combination protocol are generated independently of one another, the party may want to ascertain a level of fairness of the combination protocol itself. For example, a combination protocol being used in a game, although known to both parties, may have been generated by one party. Accordingly, the other party might want to verify that the combination protocol is fair. If a party is able to determine that a combination protocol meets some criterion for fairness, that party may be more willing to engage in a game. [0168]
  • One or more embodiments of the present invention provide for determining a level of fairness of a combination protocol. One possible criterion for a fair combination protocol is that it does not allow either the player or the game server to unilaterally change the probability of occurrence of a particular result value. For example, suppose the game server wished for a result value of 200. With a fair combination protocol, the game server should not be able to choose a game server number such that the result value of 200 is any more likely than if the game server had chosen the game server number at random. An exemplary fair combination protocol would receive a player number and a game server number, each an integer between 1 and 1000, inclusively. The protocol would then add the two integers, take the result modulo 1000, and add 1. Therefore, the result value would be an integer between 1 and 1000. Suppose that, using this combination protocol, the game server and the player terminal each chose their respective numbers at random, with each integer between 1 and 1000, inclusively, being equally likely. The player number will be denoted x[0169] p, and the game server random number xg. The probability mass function for xp is then given by p[xp]=1/1000u[xp−1]u[−xp+1000]. Note that the square brackets denote a discrete function, one that is defined only over the set of integers. Also, u[n] is the unit step function, defined to be zero for n<0, and 1 for n>=0. The probability mass function for xg is the same as that for xp. The sum of the player and the game server's random numbers will be denoted y, where y=xp+xg. The probability mass function for the sum of the player number and game server number is obtained by taking the convolution of the individual probability mass functions. Thus, p [ y ] = p [ x p ] * p [ x g ] = k = - 1 / 1000 u [ k - 1 ] u [ - k + 1000 ] 1 / 1000 u [ y - k - 1 ] u [ - ( y - k ) + 1000 ] = ( y - 1 ) ( 10 - 6 ) u [ y - 1 ] u [ - y + 1001 ] + ( - y + 2001 ) ( 10 - 6 ) u [ y - 1002 ] u [ - y + 2000 ]
    Figure US20030054879A1-20030320-M00001
  • Here, the symbol “*” denotes convolution. Now let z=y modulo 1000. The probability mass function for z can be obtained by adding the probability mass function for y in the range 0<=y<=999, the probability mass function for y in the [0170] range 1000<=y<=1999 shifted to the left by 1000, and the probability mass function for y in the range 2000<=y<=2999 shifted to the left by 2000. Thus, p [ z ] = ( ( z - 1 ) ( 10 - 6 ) u [ z - 1 ] u [ - z + 1001 ] + ( - z + 2001 ) ( 10 - 6 ) u [ z - 1002 ] u [ - z + 2000 ] + ( z + 1000 - 1 ) ( 10 - 6 ) u [ z + 1000 - 1 ] u [ - ( z + 1000 ) + 1001 ] + ( - ( z + 1000 ) + 2001 ) ( 10 - 6 ) u [ ( z + 1000 ) - 1002 ] u [ - ( z + 1000 ) + 2000 ] + ( z + 2000 - 1 ) ( 10 - 6 ) u [ z + 2000 - 1 ] u [ - ( z + 2000 ) + 1001 ] + ( - ( z + 2000 ) + 2001 ) ( 10 - 6 ) u [ ( z + 2000 ) - 1002 ] u [ - ( z + 2000 ) + 2000 ] ) u [ z ] u [ - z + 999 ] = ( ( z - 1 ) ( 10 - 6 ) u [ z - 1 ] u [ - z + 1001 ] + ( - z + 2001 ) ( 10 - 6 ) u [ z - 1002 ] u [ - z + 2000 ] + ( z + 999 ) ( 10 - 6 ) u [ z + 999 ] u [ - z + 1 ] + ( - z + 1001 ) ( 10 - 6 ) u [ z - 2 ) u [ - z + 1000 ] + ( z + 1999 ) ( 10 - 6 ) u [ z + 1999 ] u [ - z - 999 ] + ( - z + 1 ) ( 10 - 6 ) u [ z + 998 ] u [ - z ] ) u [ z ] u [ - z + 999 ] = ( z - 1 ) ( 10 - 6 ) u [ z - 1 ] u [ - z + 999 ] + ( z + 999 ) ( 10 - 6 ) ( δ [ z ] + δ [ z - 1 ] ) + ( - z = 1001 ) ( 10 - 6 ) u [ z - 2 ] u [ - z + 999 ] + ( - z + 1 ) ( 10 - 6 ) ( δ [ z ] ) = ( 10 - 6 ) ( ( ( z - 1 ) + ( - z + 1001 ) ) u [ z - 2 ] u [ - z + 999 ] + ( z + 999 ) ( δ [ z ] + δ [ z - 1 ] ) + ( - z + 1 ) ( δ [ z ] ) ) = ( 10 - 6 ) ( 1000 u [ z - 2 ] u [ - z + 999 ] + 999 δ [ z ] + 1000 δ [ z - 1 ] ) + δ [ z ] ) ) = 1 / 1000 u [ z ] u [ - z + 999 ]
    Figure US20030054879A1-20030320-M00002
  • Where δ[n] is the unit impulse function, defined to be 1 for n=0 and 0 everywhere else. Finally, 1 is added to z to complete the combination protocol, yielding:[0171]
  • p[result value]=1/1000u[result value−1]u[−result value+1000]
  • As is evident, if the player terminal chooses an integer in the range 1 to 1000, with each integer occurring with equal likelihood, and the game server does the same, then each result value will occur with equal likelihood. [0172]
  • In this next example, the game server chooses the game server random number in such a way that some game server random numbers are more likely to occur than others. Perhaps the game server is attempting to unduly influence the result value. In this example, the game server will choose the number 1 with probability a[0173] 1, the number 2 with probability a2, and so on. Note that a1+a2+a3+ . . . +a1000=1, since the game server is required to choose an integer between 1 and 1000, inclusively. Furthermore, all a's are between zero and 1, inclusively, since they represent probabilities. If, for instance, a2=1, then the game server will choose the number 2 with certainty, and there is actually no randomness at all in the game server's choice. Now, the probability mass function for the game server random number can be written: p [ x g ] = a 1 δ [ x g - 1 ] + a 2 δ [ x g - 2 ] + + a 1000 δ [ x g - 1000 ] = k = 1 1000 a k δ [ x g - k ]
    Figure US20030054879A1-20030320-M00003
  • Meanwhile, the player terminal chooses its number at random. Thus, the probability mass function for the player number remains: p[x[0174] p]=1/1000u[xp−1]u[−xp+1000]. The combination protocol now proceeds by taking y=xp+xg. Once again p [ y ] = p [ x p ] * p [ x g ] = p [ x p ] * k = 1 1000 a k δ [ x g - k ] = k = 1 1000 p [ x p ] * a k δ [ x g - k ] = k = 1 1000 ( 1 / 1000 u [ x p - 1 ] u [ - x p + 1000 ] ) * a k δ [ x g - k ] = 1 / 1000 k = 1 1000 a k u [ y - k - 1 ] u [ - ( y - k ) + 1000 ] = 1 / 1000 k = 1 1000 a k u [ y - k - 1 ] u [ - y + k + 1000 ] Once again , let z = y modulo 1000. Now , p [ z ] = 1 / 1000 k = 1 1000 ( a k u [ z - k - 1 ] u [ - z + k + 1000 ] + a k u [ ( z + 1000 ) - k - 1 ] u [ - ( z + 1000 ) + k + 1000 ] + a k u [ ( z + 2000 ) - k - 1 ] u [ - ( z + 2000 ) + k + 1000 ] ) u [ z ] u [ - z + 999 ] = 1 / 1000 k = 1 1000 ( a k u [ z - k - 1 ] u [ - z + k + 1000 ] + a k u [ z - k + 999 ] u [ - z + k ] + a k u [ z - k + 1999 ] u [ - z + k - 1000 ] ) u [ z ] u [ - z + 999 ] = 1 / 1000 k = 1 .1000 ( a k u [ z - k + 1999 ] u [ - z + k + 1000 ] ) u [ z ] u [ - z + 999 ] = 1 / 1000 k = 1 1000 a k u [ z ] u [ - z + 999 ] = 1 / 1000 u [ z ] u [ - z + 999 ] k = 1 1000 a k = 1 / 1000 u [ z ] u [ - z + 999 ]
    Figure US20030054879A1-20030320-M00004
  • Finally, 1 is added to z to complete the combination protocol, yielding:[0175]
  • p[result value]=1/1000u[result value−1]u[−result value+1000]
  • Once again, it is evident that all result values are equally likely to occur. This, despite the fact that the game server was attempting to influence the result value by more heavily favoring some potential game server numbers over others. However, since the player terminal did not favor one particular player number over another, all result values were still equally likely to occur. Note that the above analysis requires that the game server number and the player number be generated independently. If the numbers are not generated independently, than both may have uniform probability mass functions over the closed interval 1 to 1000, and yet their sum might be deterministic. For example, the game server may generate it's number randomly, and then the player terminal may generate its number according to the rule: x[0176] p=1001−xg. Then the sum of the player number and the game server number will always be 1001.
  • The above analysis has shown that, according to at least one criterion, the analyzed combination protocol is fair. That is, one party cannot change the probability of the occurrence of any result value, so long as the other party generates his number at random and according to a uniform probability mass function over a particular interval. The analysis could easily be extended to show that any combination protocol that [0177]
  • 1) Adds a player and game server random number, each restricted to a designated continuous interval, to generate a number y; [0178]
  • 2) Takes y modulo the length of the interval to generate a number z; and [0179]
  • 3) And adds a constant to obtain the result value such that the result value is certain to fall within the designated interval; is a fair protocol according to the at least one criterion. [0180]
  • An example of an unfair combination protocol might be the following: [0181]
  • 1) The player terminal and the game server each generate a number that is an integer between 1 and 500, inclusively; and [0182]
  • 2) The combination protocol adds the numbers together to get the result value. The result value is to fall within the range 2 to 1000. [0183]
  • With the above protocol, the game server might choose the number 499. Now, no matter what the player terminal chooses, the result value cannot be 1000. This is because the player terminal is restricted to choosing numbers in the range 1 to 500. Choosing the maximum number in the range would only give a result value of 999, one short of 1000. Furthermore, no matter what the player terminal chooses, the result value cannot be a number less than 500. So by purposely choosing a particular number, the game server can assure that certain result values cannot occur. Perhaps the result value of 1000 corresponds to a high paying symbol combination in a game of slots. The player is then denied the opportunity to achieve this payout. [0184]
  • A typical combination protocol may be more complicated than those analyzed above. As such, the fairness of the protocol may not necessarily be determinable through a simple analysis. One way for, say, a player terminal to verify the fairness of a combination protocol algorithm would be to run the algorithm using all possible combinations of inputs (i.e. all possible combinations of player and game server numbers). The player terminal could check that given a particular game server random number, all possible result values might still occur. The player terminal might further verify that a for a particular result value, rv[0185] 0, and any two game server numbers xg1 and xg2, the chances of rv0 occurring given xg1 are the same as the chances of rv0 occurring given xg2. This may assume that the player himself generates the player number at random, with all numbers equally favored probabilistically.
  • Another method of verifying that a combination protocol algorithm is fair would be for a player to run the algorithm many times with a random player number and a fixed game server number. The player would then check to see whether or not particular result values were unduly favored or disfavored. If, for example, a player ran the combination protocol many times with a fixed game server number and a random player number, and found that a particular result value never occurred, then the player might determine that the combination protocol is unfair. This method of verification may be used right after the completion of a game, such as a spin at a slot machine. Perhaps the player has lost the game and is suspicious that he has been cheated due to an unfair combination protocol. So the player tests the game server random number from the game with numerous possible player numbers. The test should show the player what might have happened had the player chosen a different player number in the game. If it turns out that no player number would have resulted in a favorable result value for the player, then the player has confirmed the unfairness of the combination protocol. [0186]
  • One or more embodiments of the present invention provide for evaluating the fairness of a combination protocol by determining a set of at least one generated game outcome as described above and determining a relative frequency which a particular game outcome occurs in the set of at least one generated game outcome. A probability of that particular game outcome occurring in a fair game (e.g., a game in which one of the parties cannot inappropriately influence the outcome and/or the random process used to determine an outcome) may also be determined. Then, a level of fairness of the combination protocol can be determined based on the probability of the outcome occurring in a fair game and the relative frequency of representation. For example, the probability and the relative frequency of representation can be compared. If there is a difference between the relative frequency in the generated outcomes and the probability of the outcome occurring in a “pure” game, the level of fairness may depend on the difference. Any difference, for example, may be compared to a predetermined allowable difference. It will be understood that the probability and the relative frequency need not be exactly the same, but may vary by an allowable margin. [0187]
  • Various levels of fairness may correspond to how much the relative frequency and the probability vary. For example, a slight difference may correspond to a fairness of “Very Fair”, and a larger difference may correspond to a fairness level of “Unfair.”[0188]
  • For example, a player is to test a combination protocol for fairness using a fixed number (e.g., a game server number) and each of a set of one or more possible player numbers. To determine a set of possible player numbers to use, a given set may be compared with one or more various criteria, to determine whether the set of player numbers, if tested, would provide the predetermined degree of confidence that the combination protocol is fair. [0189]
  • An evaluation of the fairness of a combination protocol preferably includes a sufficient number of tests so that the failure of the appearance of the predetermined game outcome the predetermined number of times would most likely indicate the unfairness of the combination protocol. Otherwise, the failure to generate certain result values and/or outcomes during analysis of a combination protocol might be explained by the lack of a sufficient number of tests of the combination protocol, and not necessarily by the unfairness of the combination protocol itself. [0190]
  • Accordingly, one criterion for selecting a set of player numbers to test with may be that the number of elements in the set of player numbers is not less than some threshold or predetermined minimum number of elements. [0191]
  • Similarly, another criterion for the set of player numbers tested might by that the number of elements in the set of player numbers is not less than a predetermined minimum percentage (e.g., 10%, 100%) of the number of all allowed player numbers. Again, this criterion might help to ensure that the failure of a test to generate a particular result value and/or outcome tests is most likely due to the unfairness of the combination protocol, and not to the lack of a sufficient number of tests conducted. [0192]
  • Another possible criterion for the set of player numbers tested might be that the number of elements in the set of player numbers is sufficient such that, if each player number tested leads to a corresponding game outcome, then the number of elements in the set of player numbers will ensure, with a predetermined probability, at least a predetermined number of occurrences of a particular game outcome. [0193]
  • Further criteria might require that the player numbers in the set of player numbers tested must all be distinct, and/or that each of the player numbers must be selected at random from among all allowed player numbers. [0194]
  • Many other such criteria for the set of player numbers to be tested will be obvious to those having ordinary skill in the art. [0195]
  • Although several methods of verifying the fairness of a combination protocol have been described, many other methods are possible. Methods for verifying the fairness of a combination protocol may also be used to verify the fairness of a player or game server algorithm in embodiments where the player and the game server exchange algorithms rather than numbers. [0196]
  • Various embodiments of the present invention are directed to systems and methods for ensuring the randomness of random numbers. One or more embodiments of the present invention provide for authenticating the results of electronic games in a manner that substantially obviates one or more of various limitations and disadvantages of the related art. Various embodiments of the present invention provide, in an electronic game system, hardware and procedures to ensure that random numbers used to generate game results are truly random, independently-generated numbers. [0197]
  • In accordance with one or more embodiments of the present invention, an electronic game system comprises a game server and one or more player terminals. The game server includes a random number generator and a first transmitting device for transmitting a first random number to the one or more player terminals. The one or more player terminals includes a random number generator and a second transmitting device for transmitting a second random number to the game server. The system also includes one or more of various hardware and/or procedures for ensuring that the first random number is generated independently of the second random number. [0198]
  • One or more embodiments of the present invention provide for a method for controlling an electronic game played in a system that includes a game server and one or more player terminals. The method includes the steps of generating a first random number at the game server; generating a second random number at the player terminal; encoding the first random number at the game server; encoding the second random number at the player terminal; transmitting a player encoded number from the player terminal to the game server; transmitting a player decoding key from the player terminal to the game server; and decoding the player encoded number at the game server to obtain the second random number. [0199]
  • According to various embodiments of the present invention, a result value is generated based on the first random number and the second random number. Some embodiments of the present invention provide for producing a game result based on the result value. [0200]
  • Some embodiments of the present invention are directed to various systems and procedures of a game server separate from a player terminal, as well as various combinations of such systems and/or procedures. Some embodiments of the present invention are directed to various systems and procedures of a player terminal separate from a game server, as well as various combinations of such systems and/or procedures. As discussed above, other embodiments may provide for one or more systems and/or procedures of a game server in various combinations with one or more systems and/or procedures of a player terminal. [0201]
  • One or more embodiments of the present invention provide for various hardware and/or procedures for encoding, hashing, encrypting, decoding, dehashing, and decrypting the first and second random numbers. Moreover, one or more embodiments of the systems and procedures of the present invention provide for authenticating players. One or more embodiments of the present invention provide for creating audit records of game data. [0202]
  • While there has been illustrated and described what are at present considered to be preferred embodiments and methods of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the invention. [0203]
  • Respective objects and advantages of various embodiments of the invention will be obvious from the description, or may be learned by practice of the invention. It is to be understood that descriptions provided herein are exemplary and explanatory only, and are not restrictive of the invention, as claimed. [0204]
  • In addition, many modifications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention not be limited to the particular embodiments and methods disclosed herein, but that the invention include all embodiments failing within the scope of the appended claims. [0205]

Claims (89)

What is claimed is:
1. A game server, comprising:
a processor; and
a storage device coupled to the processor and storing instructions adapted to be executed by the processor to perform a method comprising:
generating a first signal;
transmitting an encoded first signal;
receiving a second signal; and
transmitting a decoding key after receiving the second signal, the decoding key enabling a player terminal to determine the first signal.
2. The game server of claim 1, in which the first signal comprises a number.
3. The game server of claim 1, in which the first signal comprises a random number.
4. The game server of claim 1, in which the first signal comprises a letter.
5. The game server of claim 1, in which the first signal comprises a word.
6. The game server of claim 1, in which the first signal comprises an audio signal.
7. The game server of claim 1, in which the first signal comprises an video signal.
8. The game server of claim 1, in which the first signal comprises an algorithm.
9. The game server of claim 1, further comprising:
a communication port coupled to said processor and adapted to communicate with at least one player terminal.
10. A medium storing instructions adapted to be executed by a processor to perform a method, the method comprising:
generating a first signal;
transmitting an encoded first signal;
receiving a second signal; and
transmitting a decoding key after receiving the second signal, the decoding key enabling a player terminal to determine the first signal.
11. A method comprising:
determining a first signal;
receiving an encoding key from a third party;
encoding the first signal based on the encoding key to generate an encoded first signal;
transmitting the encoded first signal to a player terminal;
receiving a second signal from the player terminal; and
transmitting a decoding key to the player terminal after receiving the second signal.
12. The method of claim 11, in which the encoding key is generated by the third party.
13. A method comprising:
receiving an encoded first signal from a player terminal, in which the encoded first signal comprises a first signal that is encoded;
generating a second signal;
receiving an encoding key from a third party;
encoding the second signal to generate an encoded second signal;
transmitting the encoded second signal to the player terminal;
receiving a decoding key from the player terminal after transmitting the second signal; and
determining the first signal based on the encoded first signal and the decoding key.
14. A method comprising:
receiving an encoded first signal from a player terminal, in which the encoded first signal comprises a first signal that is encoded;
receiving a decoding key from the player terminal;
determining the first signal based on the encoded first signal and the decoding key;
transmitting a request for verification of the first signal to a third party,
the request including the decoding key; and
receiving from the third party an indication of whether the first signal is verified.
15. The method of claim 14, further comprising:
determining a second signal; and
transmitting the second signal to the player terminal.
16. The method of claim 15, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the second signal.
17. The method of claim 14, further comprising:
determining a second signal;
encoding the second signal to generate an encoded second signal; and
transmitting the encoded second signal to the player terminal.
18. The method of claim 17, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the encoded second signal.
19. The method of claim 14, in which receiving from the third party an indication of whether the first signal is verified comprises:
receiving from the third party an indication of whether the decoding key corresponds to an encoding key that is associated with the player terminal.
20. The method of claim 19, in which the encoding key is generated by the third party.
21. A method comprising:
receiving an encoded first signal from a player terminal, in which the encoded first signal comprises a first signal that is encoded;
receiving a decoding key from the player terminal;
determining the first signal based on the encoded first signal and the decoding key;
transmitting a request for verification of the first signal to a third party,
the request including the encoded first signal, and
the request including the first signal; and
receiving from the third party an indication of whether the first signal is verified.
22. The method of claim 21, further comprising:
determining a second signal; and
transmitting the second signal to the player terminal.
23. The method of claim 22, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the second signal.
24. The method of claim 21, further comprising:
determining a second signal;
encoding the second signal to generate an encoded second signal; and
transmitting the encoded second signal to the player terminal.
25. The method of claim 24, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the encoded second signal.
26. The method of claim 21, in which receiving from the third party an indication of whether the first signal is verified comprises:
receiving a fraud signal from the third party.
27. The method of claim 21, further comprising:
receiving an encoding key from the third party.
28. The method of claim 27, in which the encoding key is generated by the third party.
29. A method comprising:
receiving a first encoded first signal from a player terminal, in which the first encoded first signal comprises a first signal that is encoded;
receiving a decoding key;
determining the first signal based on the first encoded first signal and the decoding key;
transmitting a request for an encoding key to a third party;
receiving the encoding key from the third party; and
determining whether the encoding key corresponds to the decoding key.
30. The method of claim 29, in which the encoding key is generated by the third party.
31. The method of claim 29, in which the encoding key is associated with the player terminal.
32. The method of claim 29, in which determining whether the encoding key corresponds to the decoding key comprises:
determining whether the encoding key and the decoding key define inverse functions.
33. The method of claim 29, in which determining whether the encoding key corresponds to the decoding key comprises:
encoding the first signal based on the encoding key to generate a second encoded first signal; and
determining whether the second encoded first signal is equal to the first encoded first signal.
34. The method of claim 29, further comprising:
transmitting a fraud signal to the player terminal if the encoding key does not correspond to the decoding key.
35. The method of claim 29, further comprising:
determining a second signal; and
transmitting the second signal to the player terminal.
36. The method of claim 29, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the second signal.
37. The method of claim 29, further comprising:
determining a second signal;
encoding the second signal to generate an encoded second signal; and
transmitting the encoded second signal to the player terminal.
38. The method of claim 37, in which receiving the decoding key comprises:
receiving the decoding key from the player terminal after transmitting the encoded second signal.
39. A method comprising:
receiving an encoded first signal from a player terminal, in which the encoded first signal comprises a first signal that is encoded;
generating a second signal;
transmitting the second signal to the player terminal;
receiving a decoding key from the player terminal after transmitting the second signal;
determining the first signal based on the encoded first signal and the decoding key; and
before transmitting the second signal, receiving an encoding key from the player terminal.
40. A method comprising:
generating a first signal;
determining an encoding key;
generating an encoded first signal based on the first signal and the encoding key;
transmitting the encoded first signal to a player terminal;
determining a second signal that is associated with the player terminal; and
before determining the second signal, transmitting the encoding key to the player terminal.
41. The method of claim 40, further comprising:
transmitting a decoding key to the player terminal after receiving the second signal.
42. The method of claim 40, in which determining the encoding key comprises:
receiving the encoding key from a third party.
43. The method of claim 40, in which determining the second signal comprises:
receiving the second signal from the player terminal.
44. The method of claim 40, in which determining the second signal comprises:
receiving an encoded second signal from the player terminal, in which the encoded second signal comprises the second signal in an encoded format; and
receiving a decoding key from the player terminal.
45. A method comprising:
generating a first signal;
determining at least one character;
combining the first signal and the at least one character to generate a combination of the first signal and the at least one character;
encoding the combination to generate an encoded combination;
transmitting the encoded combination to a player terminal;
receiving a second signal from the player terminal; and
transmitting a decoding key to the player terminal after receiving the second signal.
46. The method of claim 45, in which combining comprises:
appending the at least one character to an end of the first signal.
47. The method of claim 45, in which combining comprises:
appending a first character to a first end of the first signal; and
appending a second character to a second end of the first signal.
48. A method comprising:
receiving an encoded combination from a player terminal,
in which the encoded combination comprises a combination that is encoded, and
in which the combination comprises a first signal and at least one character;
generating a second signal;
transmitting the second signal to the player terminal;
receiving a decoding key from the player terminal after transmitting the second signal; and
determining the at least one character based on the encoded combination and the decoding key.
49. The method of claim 48, further comprising:
determining whether the at least one character matches a predetermined at least one character.
50. The method of claim 49, further comprising:
receiving an indication of the predetermined at least one character from the player terminal.
51. The method of claim 49, further comprising:
selecting the predetermined at least one character; and
transmitting an indication of the predetermined at least one character to the player terminal.
52. The method of claim 48, in which the at least one character comprises a letter.
53. The method of claim 48, in which the at least one character comprises a number.
54. The method of claim 48, in which the at least one character comprises a word.
55. A medium storing instructions adapted to be executed by a processor to perform a method, the method comprising:
generating a first signal;
encoding the first signal to generate an encoded first signal;
transmitting the encoded first signal to a game server;
receiving a second signal from the game server; and
transmitting a decoding key to the game server after receiving the second signal, the decoding key enabling the game server to determine the first signal based on the encoded first signal and the decoding key.
56. A player terminal, comprising:
a processor; and
a computer readable medium storing a program, the program being operative to instruct the processor to perform a method comprising:
receiving an encoded first signal, in which the encoded first signal comprises a first signal that is encoded;
generating a second signal;
transmitting the second signal;
receiving a decoding key after transmitting the second signal; and
determining the first signal based on the encoded first signal and the decoding key.
57. The player terminal of claim 56, further comprising:
a communication port coupled to the processor and adapted to communicate with at least one game server.
58. A medium storing instructions adapted to be executed by a processor to perform a method, the method comprising:
receiving an encoded first signal from a game server, in which the encoded first signal comprises a first signal that is encoded;
generating a second signal;
transmitting the second signal to the game server;
receiving a decoding key from the game server after transmitting the second signal; and
determining the first signal based on the encoded first signal and the decoding key.
59. A method comprising:
transmitting an encoding key to a game server;
receiving a request for verification from a player terminal,
the request including a decoding key;
determining whether the encoding key corresponds to the decoding key; and
transmitting to the player terminal an indication of whether the encoding key corresponds to the decoding key.
60. The method of claim 59, further comprising:
generating the encoding key.
61. The method of claim 59, in which the decoding key is associated with the game server.
62. The method of claim 59, in which determining comprises:
determining whether the encoding key and the decoding key define inverse functions.
63. The method of claim 59, in which determining comprises:
determining a first number;
encoding the first number based on the encoding key to generate an encoded first number;
decoding the encoded first number based on the decoding key to generate a second number; and
determining whether the second number is equal to the first number.
64. The method of claim 59, in which transmitting to the player terminal the indication of whether the encoding key corresponds to the decoding key comprises:
transmitting a fraud signal to the player terminal if the encoding key does not correspond to the decoding key.
65. The method of claim 59, further comprising:
transmitting the encoding key to the player terminal.
66. The method of claim 59, further comprising:
transmitting a fraud signal to the game server if the encoding key does not correspond to the decoding key.
67. A method comprising:
transmitting an encoding key to a game server;
receiving an encoded first signal from a player terminal, in which the encoded first signal comprises a first signal that is encoded;
receiving a second signal;
encoding the second signal based on the encoding key to generate an encoded second signal;
determining whether the encoded second signal is equal to the encoded first signal; and
transmitting to the player terminal an indication of whether the encoded second signal is equal to the encoded first signal.
68. The method of claim 67, further comprising:
generating the encoding key.
69. The method of claim 67, in which transmitting to the player terminal the indication of whether the encoded second signal is equal to the encoded first signal comprises:
transmitting a fraud signal to the player terminal if the encoded second signal is not equal to the encoded first signal.
70. The method of claim 67, further comprising:
transmitting the encoding key to the player terminal.
71. The method of claim 67, in which receiving the second signal comprises:
receiving the second signal from the game server.
72. The method of claim 67, in which receiving the second signal comprises:
receiving the second signal from the player terminal.
73. The method of claim 67, further comprising:
transmitting a fraud signal to the game server if the encoded second signal is not equal to the encoded first signal.
74. A method comprising:
determining at least one potential game outcome,
in which the at least one potential game outcome corresponds to a game;
determining a combination protocol for generating a game outcome,
in which the combination protocol is associated with the game,
in which the combination protocol has an associated first input, and
in which the combination protocol has an associated second input;
determining at least one first number;
determining a second number;
generating, for each at least one first number, a respective game outcome based on:
the first number,
the second number, and
the combination protocol,
thereby determining a set of at least one generated game outcome; and
determining whether each at least one potential game outcome is represented in the set of the at least one generated game outcome.
75. The method of claim 74, in which generating comprises:
generating, for each at least one first number, a respective result value based on:
the first number,
the second number, and
the combination protocol,
thereby determining a set of at least one result value.
76. The method of claim 75, further comprising:
determining, for each result value of the set of at least one result value, a respective game outcome that corresponds to the result value, thereby determining the set of at least one generated game outcome.
77. The method of claim 74, further comprising:
receiving an indication of a table associating result values and respective outcomes; and
in which generating comprises:
generating, for each at least one first number, the respective game outcome based on:
the first number,
the second number,
the table, and
the combination protocol.
78. The method of claim 77, in which the table is a payout table.
79. The method of claim 74, in which determining the set of potential game outcomes comprises:
determining a payout table that is associated with the game.
80. The method of claim 74, further comprising:
determining a criterion that is associated with the first input;
determining a set of inputs that satisfy the criterion; and
in which determining the at least one first number comprises:
selecting the at least one first number from the set of inputs that satisfy the criterion.
81. The method of claim 74, in which determining the at least one first number comprises:
determining a set of the at least one first number, the set having a number of elements that is not less than a predetermined minimum number of elements.
82. The method of claim 74, further comprising:
determining a criterion that is associated with the first input;
determining a number of inputs that satisfy the criterion; and
in which determining the at least one first number comprises:
determining a set of the at least one first number, the set having a number of elements that is not less than a predetermined minimum percentage of the number of inputs that satisfy the criterion.
83. The method of claim 74, in which determining the combination protocol comprises:
receiving an indication of the combination protocol from a game server.
84. The method of claim 74, in which determining the combination protocol comprises:
selecting the combination protocol from a plurality of combination protocols.
85. The method of claim 74, in which determining the second number comprises:
receiving the second number from a game server.
86. The method of claim 74, in which determining the second number comprises:
receiving the second number from a player terminal.
87. A method comprising:
determining a combination protocol for generating a game outcome,
in which the combination protocol is associated with a game,
in which the combination protocol has an associated first input, and
in which the combination protocol has an associated second input;
determining a first criterion that is associated with the first input;
determining at least one first number that satisfies the first criterion;
determining a second number;
generating, for each at least one first number, a respective game outcome based on:
the first number,
the second number, and
the combination protocol,
thereby determining a set of at least one generated game outcome; and
determining a potential game outcome,
in which the potential game outcome is associated with the game;
determining a probability of occurrence of the potential game outcome;
determining a relative frequency of representation of the potential game outcome in the set of at least one generated game outcome; and
determining a level of fairness of the combination protocol based on the probability of occurrence and the relative frequency of representation.
88. The method of claim 87, in which determining the level of fairness comprises:
comparing the probability of occurrence and the relative frequency of representation.
89. The method of claim 87, in which determining the level of fairness comprises:
determining a difference between the probability of occurrence and the relative frequency of representation; and
determining whether the difference is greater than a predetermined difference.
US10/246,099 1996-12-31 2002-09-17 System and method for securing electronic games Abandoned US20030054879A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US10/246,099 US20030054879A1 (en) 1996-12-31 2002-09-17 System and method for securing electronic games
US11/934,856 US7524245B2 (en) 1996-12-31 2007-11-05 System and method for securing electronic games
US12/430,686 US8608558B2 (en) 1996-12-31 2009-04-27 System and method for securing electronic games
US14/108,637 US20140106873A1 (en) 1996-12-31 2013-12-17 System and method for securing electronic games

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US08/775,588 US6099408A (en) 1996-12-31 1996-12-31 Method and apparatus for securing electronic games
US09/488,608 US6264557B1 (en) 1996-12-31 2000-01-20 Method and apparatus for securing electronic games
US09/895,648 US6450885B2 (en) 1996-12-31 2001-06-29 Method and apparatus for securing electronic games
US10/246,099 US20030054879A1 (en) 1996-12-31 2002-09-17 System and method for securing electronic games

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/895,648 Continuation-In-Part US6450885B2 (en) 1996-12-31 2001-06-29 Method and apparatus for securing electronic games

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/934,856 Continuation US7524245B2 (en) 1996-12-31 2007-11-05 System and method for securing electronic games

Publications (1)

Publication Number Publication Date
US20030054879A1 true US20030054879A1 (en) 2003-03-20

Family

ID=27413813

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/246,099 Abandoned US20030054879A1 (en) 1996-12-31 2002-09-17 System and method for securing electronic games
US11/934,856 Expired - Fee Related US7524245B2 (en) 1996-12-31 2007-11-05 System and method for securing electronic games
US12/430,686 Expired - Fee Related US8608558B2 (en) 1996-12-31 2009-04-27 System and method for securing electronic games
US14/108,637 Abandoned US20140106873A1 (en) 1996-12-31 2013-12-17 System and method for securing electronic games

Family Applications After (3)

Application Number Title Priority Date Filing Date
US11/934,856 Expired - Fee Related US7524245B2 (en) 1996-12-31 2007-11-05 System and method for securing electronic games
US12/430,686 Expired - Fee Related US8608558B2 (en) 1996-12-31 2009-04-27 System and method for securing electronic games
US14/108,637 Abandoned US20140106873A1 (en) 1996-12-31 2013-12-17 System and method for securing electronic games

Country Status (1)

Country Link
US (4) US20030054879A1 (en)

Cited By (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030187619A1 (en) * 2000-06-01 2003-10-02 Jong-Sung Lee Total system for preventing information outflow from inside
US20040044627A1 (en) * 1999-11-30 2004-03-04 Russell David C. Methods, systems and apparatuses for secure transactions
US20040198489A1 (en) * 2000-06-23 2004-10-07 Kaminkow Joseph E. Gaming device having touch activated alternating or changing symbol
DE10336355A1 (en) * 2003-08-08 2005-03-10 Universal Gaming Concepts Inc A method for preventing manipulation of the game result by a casino or a slot machine
US20050081040A1 (en) * 2003-05-30 2005-04-14 Johnson Barry W. In-circuit security system and methods for controlling access to and use of sensitive data
US20050221883A1 (en) * 2004-03-31 2005-10-06 Multimedia Games, Inc. Apparatus, method, and program product for conducting a bingo game to produce card game-type results
US20060019749A1 (en) * 2004-07-01 2006-01-26 Virtgame Corp. Secure server-based gaming platform
US20060205484A1 (en) * 2005-03-10 2006-09-14 Nicastro Neil D System and method for inducing wagering in a poker-type game
US20070032286A1 (en) * 2005-08-04 2007-02-08 Igt Methods and apparatus for auctioning an item via a gaming device
US20070050838A1 (en) * 2005-08-25 2007-03-01 Derek Liu Multi-protocol game engine
US20080076532A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US20080076496A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US20080076557A1 (en) * 2003-06-24 2008-03-27 Dave Anderson Methods And Systems For Establishing Games With Automation Using Verbal Communication
US20080085772A1 (en) * 2006-09-27 2008-04-10 Igt Server based gaming system having system triggered loyalty award sequences
US20080102920A1 (en) * 2006-11-01 2008-05-01 Igt Gaming system and method of operating a gaming system having a bonus participation bidding sequence
US20080244695A1 (en) * 2000-06-01 2008-10-02 Jong-Sung Lee Total system for preventing information outflow from inside
US20080268957A1 (en) * 2004-09-10 2008-10-30 Nguyen Binh T Apparatus and methods for wireless gaming communications
US20090036202A1 (en) * 2007-07-30 2009-02-05 Igt Gaming system and method for providing an additional gaming currency
US20090088240A1 (en) * 1994-12-19 2009-04-02 Legal Igaming, Inc. System and method for connecting gaming devices to a network for remote play
WO2009137589A1 (en) * 2008-05-07 2009-11-12 Lightning Poker, Inc. Interactive gaming device
US20100064371A1 (en) * 2008-09-11 2010-03-11 Mostovych Andrew N Method and apparatus for prevention of tampering, unauthorized use, and unauthorized extraction of information from microdevices
US7695363B2 (en) 2000-06-23 2010-04-13 Igt Gaming device having multiple display interfaces
US7699699B2 (en) 2000-06-23 2010-04-20 Igt Gaming device having multiple selectable display interfaces based on player's wagers
US7780523B2 (en) 2005-09-09 2010-08-24 Igt Server based gaming system having multiple progressive awards
US20100273552A1 (en) * 2009-04-24 2010-10-28 Mwstory Co., Ltd. Method for Authentication of Game Executing Authority Recording Medium for Storing Authentication Program of Game Executing Authority, and Server for Storing Authentication Program of Game Executing Authority
US20100285865A1 (en) * 2009-05-11 2010-11-11 Enzminger Joseph R Method, apparatus, and program product for distributing random number generation on a gaming network
US7905778B2 (en) 2005-09-09 2011-03-15 Igt Server based gaming system having multiple progressive awards
US7963847B2 (en) 2004-08-19 2011-06-21 Igt Gaming system having multiple gaming machines which provide bonus awards
US8021230B2 (en) 2004-08-19 2011-09-20 Igt Gaming system having multiple gaming machines which provide bonus awards
US8128491B2 (en) 2005-09-09 2012-03-06 Igt Server based gaming system having multiple progressive awards
US20120071244A1 (en) * 2007-03-01 2012-03-22 Sony Computer Entertainment Europe Limited Entertainment device and method
US8216065B2 (en) 2005-09-09 2012-07-10 Igt Gaming system having multiple adjacently arranged gaming machines which each provide a component for a multi-component game
US8251791B2 (en) 2004-08-19 2012-08-28 Igt Gaming system having multiple gaming machines which provide bonus awards
US8398081B1 (en) * 2007-07-20 2013-03-19 Daniel Girolmo Combination dice and board game and associated method
US20130143667A1 (en) * 2011-12-01 2013-06-06 Nintendo Co., Ltd. Game system, game apparatus, storage medium and game controlling method
US8512130B2 (en) 2006-07-27 2013-08-20 Igt Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award
US8529347B2 (en) 2001-10-17 2013-09-10 Aristocrat Technologies Australia Pty Limited Gaming system customer service techniques
US20140141862A1 (en) * 2012-10-11 2014-05-22 Scientific Games International, Inc. System and Method for Implementing Play of Internet-Based Games
US20140274336A1 (en) * 2013-03-13 2014-09-18 Game Play Network, Inc. d/b/a/ Oddz System and Method of Securing Reveals of Outcomes of Real World Wagers
US8900053B2 (en) 2007-08-10 2014-12-02 Igt Gaming system and method for providing different bonus awards based on different types of triggered events
EP2814009A1 (en) * 2013-06-11 2014-12-17 Real Time Winning System Inc. Real-time betting, drawing and winning system and method thereof
US9002974B1 (en) * 2007-10-16 2015-04-07 Sprint Communications Company L.P. Script server for efficiently providing multimedia services in a multimedia system
US9039516B2 (en) 2009-07-30 2015-05-26 Igt Concurrent play on multiple gaming machines
US9142097B2 (en) 2007-10-26 2015-09-22 Igt Gaming system and method for providing play of local first game and remote second game
US9251649B2 (en) 2002-10-09 2016-02-02 Zynga Inc. System and method for connecting gaming devices to a network for remote play
US9468843B2 (en) 2012-09-28 2016-10-18 Everi Games Inc. Wagering game, gaming machine, networked gaming system and method with a player selection symbol replacement game
US9875618B2 (en) 2014-07-24 2018-01-23 Igt Gaming system and method employing multi-directional interaction between multiple concurrently played games
US9972171B2 (en) 2015-09-24 2018-05-15 Igt Gaming system and method for providing a triggering event based on a collection of units from different games
US20190184290A1 (en) * 2017-12-15 2019-06-20 Gree, Inc. Non-transitory computer-readable storage medium, terminal device, and information processing system
CN110309479A (en) * 2019-07-09 2019-10-08 西安点告网络科技有限公司 Attribute information acquiring method and device
CN111185011A (en) * 2019-12-13 2020-05-22 杭州复杂美科技有限公司 Method, apparatus and storage medium for applying random number under block chain game
US20210362062A1 (en) * 2006-11-15 2021-11-25 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US11798376B2 (en) 2021-12-16 2023-10-24 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers using reserve wagering

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001041025A2 (en) * 1999-12-06 2001-06-07 Ods Properties, Inc. Systems and methods for interactive wagering
GB2443264A (en) * 2006-10-27 2008-04-30 Ntnu Technology Transfer As Integrity checking method for a device in a computer network, which controls access to data; e.g. to prevent cheating in online game
WO2010107902A2 (en) * 2009-03-18 2010-09-23 Szrek2Solutions, Llc Secure provisioning of random numbers to remote clients
EP2337297B1 (en) * 2009-12-15 2013-02-20 Nxp B.V. Communication pad for a communication terminal
US8414391B2 (en) * 2010-03-22 2013-04-09 Igt Communication methods for networked gaming systems
AU2011226860B2 (en) * 2010-09-28 2014-08-28 Aristocrat Technologies Australia Pty Limited A gaming system, a method of gaming and a game outcome prediction controller
US8834253B2 (en) * 2011-08-10 2014-09-16 Elia Rocco Tarantino Gaming devices having player assigned random number generators and time share feature
US9501897B2 (en) * 2012-03-14 2016-11-22 Integrated Systems Design, Inc. Method and apparatus for enabling customized electronic game feautures by authorized personnel
US8968085B2 (en) * 2012-03-14 2015-03-03 Integrated Systems Design, Inc. Networked gaming system and method
US9208302B2 (en) * 2012-09-28 2015-12-08 Intel Corporation Multi-factor authentication using biometric data
TWI468211B (en) * 2012-10-25 2015-01-11 Univ Chien Hsin Sci & Tech Improve the user's trusted verification method
CN104079525B (en) * 2013-03-25 2015-11-11 腾讯科技(深圳)有限公司 A kind ofly prevent plug-in method and server
US10373426B2 (en) * 2015-09-23 2019-08-06 Spur Trail Investments, Inc. System and method for provably fair gaming

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4218582A (en) * 1977-10-06 1980-08-19 The Board Of Trustees Of The Leland Stanford Junior University Public key cryptographic apparatus and method
US4759064A (en) * 1985-10-07 1988-07-19 Chaum David L Blind unanticipated signature systems
US5269521A (en) * 1990-08-22 1993-12-14 Rossides Michael T Expected value payment method and system for reducing the expected per unit costs of paying and/or receiving a given amount of a commodity
US5326104A (en) * 1992-02-07 1994-07-05 Igt Secure automated electronic casino gaming system
US5356144A (en) * 1992-07-21 1994-10-18 Fitzpatrick James R Hand-held lottery number generating device
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5643086A (en) * 1995-06-29 1997-07-01 Silicon Gaming, Inc. Electronic casino gaming apparatus with improved play capacity, authentication and security
US5707286A (en) * 1994-12-19 1998-01-13 Mikohn Gaming Corporation Universal gaming engine
US6099408A (en) * 1996-12-31 2000-08-08 Walker Digital, Llc Method and apparatus for securing electronic games
US6428413B1 (en) * 1994-12-19 2002-08-06 Rolf Carlson Universal game engine for a game network and method therefor

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US557518A (en) * 1896-03-31 Carbon-holder for arc-lamps
US3548174A (en) 1966-08-10 1970-12-15 Burroughs Corp Random number generator
US4339134A (en) 1977-07-05 1982-07-13 Rockwell International Corporation Electronic card game
US4200770A (en) 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US4652998A (en) 1984-01-04 1987-03-24 Bally Manufacturing Corporation Video gaming system with pool prize structures
CA1245361A (en) * 1984-06-27 1988-11-22 Kerry E. Thacher Tournament data system
GB8621333D0 (en) 1986-09-04 1986-10-15 Manitoba Telephone System Key management system
US4998199A (en) 1987-10-02 1991-03-05 Namco Ltd. Game machine system with machine grouping feature
DE69128981T2 (en) 1990-06-01 1998-08-06 Toshiba Kawasaki Kk Secret transmission method and secret transmission device
US5112058A (en) 1990-11-08 1992-05-12 Lowell Sandeen Game card
AU3058292A (en) 1991-10-30 1993-06-07 Computer Based Controls, Inc. Financial document dispensing apparatus and method
US5324035A (en) 1991-12-02 1994-06-28 Infinational Technologies, Inc. Video gaming system with fixed pool of winning plays and global pool access
DE4142964C2 (en) 1991-12-24 2003-05-08 Gao Ges Automation Org Data exchange system with verification of the device for authentication status
US5251165A (en) 1992-04-09 1993-10-05 James Iii J Colin Two phase random number generator
US5242163A (en) 1992-08-27 1993-09-07 D.D. Stud Inc. Casino game system
US5377271A (en) 1992-10-09 1994-12-27 Travelers Express Company, Inc. Apparatus for dispensing money orders
FR2697653B1 (en) 1992-11-04 1995-01-20 Info Telecom Electronic game of chance device.
US6048269A (en) * 1993-01-22 2000-04-11 Mgm Grand, Inc. Coinless slot machine system and method
DE4317380C1 (en) 1993-05-25 1994-08-18 Siemens Ag Method for authentication between two electronic devices
DE671730T1 (en) 1993-07-28 1997-06-26 Sega Enterprises Kk DATA RECORDER AND ELECTRONIC DEVICE USING THE SAME.
US5397133A (en) 1993-09-30 1995-03-14 At&T Corp. System for playing card games remotely
US5398932A (en) 1993-12-21 1995-03-21 Video Lottery Technologies, Inc. Video lottery system with improved site controller and validation unit
FR2718312B1 (en) 1994-03-29 1996-06-07 Rola Nevoux Method for the combined authentication of a telecommunications terminal and a user module.
US5511784A (en) 1994-05-09 1996-04-30 Video Lottery Technologies, Inc. Method and apparatus for directly generating a random final outcome of a game
US5654746A (en) * 1994-12-01 1997-08-05 Scientific-Atlanta, Inc. Secure authorization and control method and apparatus for a game delivery service
US5674128A (en) * 1995-02-21 1997-10-07 Oneida Indian Nation Cashless computerized video game system and method
US5605504A (en) 1995-04-28 1997-02-25 Huang; Sming Electronic wagering machine
US5564701A (en) 1995-04-28 1996-10-15 Dettor; Michael K. Casino oriented gaming apparatus and method incorporating randomly generated numbers
US5970143A (en) * 1995-11-22 1999-10-19 Walker Asset Management Lp Remote-auditing of computer generated outcomes, authenticated billing and access control, and software metering system using cryptographic and other protocols
US5772509A (en) 1996-03-25 1998-06-30 Casino Data Systems Interactive gaming device
US5779545A (en) * 1996-09-10 1998-07-14 International Game Technology Central random number generation for gaming system
JP2002085852A (en) 2000-09-21 2002-03-26 Sega Corp Network game method and its system
US6949022B1 (en) * 2000-11-22 2005-09-27 Trilogy Development Group, Inc. Distributed secrets for validation of gaming transactions

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4218582A (en) * 1977-10-06 1980-08-19 The Board Of Trustees Of The Leland Stanford Junior University Public key cryptographic apparatus and method
US4759064A (en) * 1985-10-07 1988-07-19 Chaum David L Blind unanticipated signature systems
US5269521A (en) * 1990-08-22 1993-12-14 Rossides Michael T Expected value payment method and system for reducing the expected per unit costs of paying and/or receiving a given amount of a commodity
US5326104A (en) * 1992-02-07 1994-07-05 Igt Secure automated electronic casino gaming system
US5356144A (en) * 1992-07-21 1994-10-18 Fitzpatrick James R Hand-held lottery number generating device
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5707286A (en) * 1994-12-19 1998-01-13 Mikohn Gaming Corporation Universal gaming engine
US6428413B1 (en) * 1994-12-19 2002-08-06 Rolf Carlson Universal game engine for a game network and method therefor
US6986055B2 (en) * 1994-12-19 2006-01-10 Legal Igaming, Inc. Method for generating random numbers
US5643086A (en) * 1995-06-29 1997-07-01 Silicon Gaming, Inc. Electronic casino gaming apparatus with improved play capacity, authentication and security
US6099408A (en) * 1996-12-31 2000-08-08 Walker Digital, Llc Method and apparatus for securing electronic games

Cited By (153)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090088240A1 (en) * 1994-12-19 2009-04-02 Legal Igaming, Inc. System and method for connecting gaming devices to a network for remote play
US8959154B2 (en) 1994-12-19 2015-02-17 Zynga Inc. System and method for connecting gaming devices to a network for remote play
US9092932B2 (en) * 1994-12-19 2015-07-28 Zynga Inc. System and method for connecting gaming devices to a network for remote play
US20080319915A1 (en) * 1999-11-30 2008-12-25 Russell David C Biometric identification device and methods for secure transactions
US10332114B2 (en) 1999-11-30 2019-06-25 Apple Inc. Methods, systems and apparatuses for secure transactions
US9659297B2 (en) 1999-11-30 2017-05-23 Apple Inc. Biometric identification device
US20040044627A1 (en) * 1999-11-30 2004-03-04 Russell David C. Methods, systems and apparatuses for secure transactions
US8566250B2 (en) 1999-11-30 2013-10-22 Privaris, Inc. Biometric identification device and methods for secure transactions
US20030187619A1 (en) * 2000-06-01 2003-10-02 Jong-Sung Lee Total system for preventing information outflow from inside
US20080244695A1 (en) * 2000-06-01 2008-10-02 Jong-Sung Lee Total system for preventing information outflow from inside
US7370198B2 (en) * 2000-06-01 2008-05-06 Waterwall Systems Co., Ltd. Total system for preventing information outflow from inside
US7699699B2 (en) 2000-06-23 2010-04-20 Igt Gaming device having multiple selectable display interfaces based on player's wagers
US7695363B2 (en) 2000-06-23 2010-04-13 Igt Gaming device having multiple display interfaces
US8221218B2 (en) 2000-06-23 2012-07-17 Igt Gaming device having multiple selectable display interfaces based on player's wagers
US20040198489A1 (en) * 2000-06-23 2004-10-07 Kaminkow Joseph E. Gaming device having touch activated alternating or changing symbol
US9886819B2 (en) 2001-10-17 2018-02-06 Aristocrat Technologies Australia Pty Limited Gaming system customer service techniques
US8529347B2 (en) 2001-10-17 2013-09-10 Aristocrat Technologies Australia Pty Limited Gaming system customer service techniques
US9251649B2 (en) 2002-10-09 2016-02-02 Zynga Inc. System and method for connecting gaming devices to a network for remote play
US9923884B2 (en) 2003-05-30 2018-03-20 Apple Inc. In-circuit security system and methods for controlling access to and use of sensitive data
US7587611B2 (en) * 2003-05-30 2009-09-08 Privaris, Inc. In-circuit security system and methods for controlling access to and use of sensitive data
US8495382B2 (en) 2003-05-30 2013-07-23 Privaris, Inc. In-circuit security system and methods for controlling access to and use of sensitive data
US20050081040A1 (en) * 2003-05-30 2005-04-14 Johnson Barry W. In-circuit security system and methods for controlling access to and use of sensitive data
US9124930B2 (en) 2003-05-30 2015-09-01 Apple Inc. In-circuit security system and methods for controlling access to and use of sensitive data
US9089772B2 (en) * 2003-06-24 2015-07-28 At&T Intellectual Property I, L.P. Methods and systems for establishing games with automation using verbal communication
US10071310B2 (en) 2003-06-24 2018-09-11 At&T Intellectual Property I, L.P. Methods and systems for establishing games with automation using verbal communication
US20080076557A1 (en) * 2003-06-24 2008-03-27 Dave Anderson Methods And Systems For Establishing Games With Automation Using Verbal Communication
DE10336355A1 (en) * 2003-08-08 2005-03-10 Universal Gaming Concepts Inc A method for preventing manipulation of the game result by a casino or a slot machine
US20050221883A1 (en) * 2004-03-31 2005-10-06 Multimedia Games, Inc. Apparatus, method, and program product for conducting a bingo game to produce card game-type results
US20060019749A1 (en) * 2004-07-01 2006-01-26 Virtgame Corp. Secure server-based gaming platform
US8814648B2 (en) 2004-08-19 2014-08-26 Igt Gaming system having multiple gaming machines which provide bonus awards
US8251791B2 (en) 2004-08-19 2012-08-28 Igt Gaming system having multiple gaming machines which provide bonus awards
US8021230B2 (en) 2004-08-19 2011-09-20 Igt Gaming system having multiple gaming machines which provide bonus awards
US9600968B2 (en) 2004-08-19 2017-03-21 Igt Gaming system having multiple gaming machines which provide bonus awards
US7963847B2 (en) 2004-08-19 2011-06-21 Igt Gaming system having multiple gaming machines which provide bonus awards
US9824534B2 (en) 2004-09-10 2017-11-21 Igt Apparatus and methods for wireless gaming communications
US8632403B2 (en) * 2004-09-10 2014-01-21 Igt Apparatus and methods for wireless gaming communications
US20080268957A1 (en) * 2004-09-10 2008-10-30 Nguyen Binh T Apparatus and methods for wireless gaming communications
US20060205484A1 (en) * 2005-03-10 2006-09-14 Nicastro Neil D System and method for inducing wagering in a poker-type game
WO2006098867A2 (en) * 2005-03-10 2006-09-21 Nicastro Neil D System and method for inducing wagering in a poker-type game
WO2006098867A3 (en) * 2005-03-10 2009-04-16 Neil D Nicastro System and method for inducing wagering in a poker-type game
US8167709B2 (en) 2005-08-04 2012-05-01 Igt Methods and apparatus for auctioning an item via a gaming device
US20070032286A1 (en) * 2005-08-04 2007-02-08 Igt Methods and apparatus for auctioning an item via a gaming device
US7905777B2 (en) 2005-08-04 2011-03-15 Igt Methods and apparatus for auctioning an item via a gaming device
US20110124404A1 (en) * 2005-08-04 2011-05-26 Igt Methods and apparatus for auctioning an item via a gaming device
US8632394B2 (en) 2005-08-04 2014-01-21 Igt Methods and apparatus for auctioning an item via a gaming device
US20070050838A1 (en) * 2005-08-25 2007-03-01 Derek Liu Multi-protocol game engine
US8128491B2 (en) 2005-09-09 2012-03-06 Igt Server based gaming system having multiple progressive awards
US7841939B2 (en) 2005-09-09 2010-11-30 Igt Server based gaming system having multiple progressive awards
US8137188B2 (en) 2005-09-09 2012-03-20 Igt Server based gaming system having multiple progressive awards
US7905778B2 (en) 2005-09-09 2011-03-15 Igt Server based gaming system having multiple progressive awards
US7780523B2 (en) 2005-09-09 2010-08-24 Igt Server based gaming system having multiple progressive awards
US8216065B2 (en) 2005-09-09 2012-07-10 Igt Gaming system having multiple adjacently arranged gaming machines which each provide a component for a multi-component game
US8512121B2 (en) 2005-09-09 2013-08-20 Igt Gaming system having multiple adjacently arranged gaming machines which each provide a component for a multi-component game
US9269228B2 (en) 2006-07-27 2016-02-23 Igt Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award
US9898891B2 (en) 2006-07-27 2018-02-20 Igt Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award
US8512130B2 (en) 2006-07-27 2013-08-20 Igt Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award
US8221226B2 (en) 2006-09-27 2012-07-17 Igt Server based gaming system having system triggered loyalty award sequences
US8616959B2 (en) 2006-09-27 2013-12-31 Igt Server based gaming system having system triggered loyalty award sequences
US7862430B2 (en) 2006-09-27 2011-01-04 Igt Server based gaming system having system triggered loyalty award sequences
US8262469B2 (en) 2006-09-27 2012-09-11 Igt Server based gaming system having system triggered loyalty award sequences
US7674180B2 (en) 2006-09-27 2010-03-09 Igt Server based gaming system having system triggered loyalty award sequences
US8206212B2 (en) 2006-09-27 2012-06-26 Igt Server based gaming system having system triggered loyalty award sequences
US20080076532A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US8012009B2 (en) 2006-09-27 2011-09-06 Igt Server based gaming system having system triggered loyalty award sequences
US8500542B2 (en) 2006-09-27 2013-08-06 Igt Server based gaming system having system triggered loyalty award sequences
US20080076576A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US8210930B2 (en) 2006-09-27 2012-07-03 Igt Server based gaming system having system triggered loyalty award sequences
US20080076496A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US20080085772A1 (en) * 2006-09-27 2008-04-10 Igt Server based gaming system having system triggered loyalty award sequences
US20080076531A1 (en) * 2006-09-27 2008-03-27 Igt Server based gaming system having system triggered loyalty award sequences
US7993199B2 (en) 2006-09-27 2011-08-09 Igt Server based gaming system having system triggered loyalty award sequences
US20080102920A1 (en) * 2006-11-01 2008-05-01 Igt Gaming system and method of operating a gaming system having a bonus participation bidding sequence
US7857699B2 (en) 2006-11-01 2010-12-28 Igt Gaming system and method of operating a gaming system having a bonus participation bidding sequence
US20210362062A1 (en) * 2006-11-15 2021-11-25 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US11794113B2 (en) * 2006-11-15 2023-10-24 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US8632408B2 (en) * 2007-03-01 2014-01-21 Sony Computer Entertainment Europe Limited Entertainment device and method
US20120071244A1 (en) * 2007-03-01 2012-03-22 Sony Computer Entertainment Europe Limited Entertainment device and method
US8398081B1 (en) * 2007-07-20 2013-03-19 Daniel Girolmo Combination dice and board game and associated method
US20090036202A1 (en) * 2007-07-30 2009-02-05 Igt Gaming system and method for providing an additional gaming currency
US9396606B2 (en) 2007-07-30 2016-07-19 Igt Gaming system and method for providing an additional gaming currency
US11062561B2 (en) 2007-07-30 2021-07-13 Igt Gaming system and method for providing an additional gaming currency
US7985133B2 (en) 2007-07-30 2011-07-26 Igt Gaming system and method for providing an additional gaming currency
US9569930B2 (en) 2007-07-30 2017-02-14 Igt Gaming system and method for providing an additional gaming currency
US8216062B2 (en) 2007-07-30 2012-07-10 Igt Gaming system and method for providing an additional gaming currency
US8900053B2 (en) 2007-08-10 2014-12-02 Igt Gaming system and method for providing different bonus awards based on different types of triggered events
US9978213B2 (en) 2007-08-10 2018-05-22 Igt Gaming system and method for providing different bonus awards based on different types of triggered events
US10867477B2 (en) 2007-08-10 2020-12-15 Igt Gaming system and method for providing different bonus awards based on different types of triggered events
US9002974B1 (en) * 2007-10-16 2015-04-07 Sprint Communications Company L.P. Script server for efficiently providing multimedia services in a multimedia system
US9591046B1 (en) * 2007-10-16 2017-03-07 Sprint Communications Company L.P. Efficiently providing multimedia services
US9269223B2 (en) 2007-10-26 2016-02-23 Igt Gaming system and method for providing play of local first game and remote second game
US9142097B2 (en) 2007-10-26 2015-09-22 Igt Gaming system and method for providing play of local first game and remote second game
WO2009137589A1 (en) * 2008-05-07 2009-11-12 Lightning Poker, Inc. Interactive gaming device
US20090280883A1 (en) * 2008-05-07 2009-11-12 Haveson Brian D Interactive gaming device
US20100064371A1 (en) * 2008-09-11 2010-03-11 Mostovych Andrew N Method and apparatus for prevention of tampering, unauthorized use, and unauthorized extraction of information from microdevices
US8332661B2 (en) 2008-09-11 2012-12-11 Mostovych Andrew N Method and apparatus for prevention of tampering, unauthorized use, and unauthorized extraction of information from microdevices
US20100273552A1 (en) * 2009-04-24 2010-10-28 Mwstory Co., Ltd. Method for Authentication of Game Executing Authority Recording Medium for Storing Authentication Program of Game Executing Authority, and Server for Storing Authentication Program of Game Executing Authority
US20100285865A1 (en) * 2009-05-11 2010-11-11 Enzminger Joseph R Method, apparatus, and program product for distributing random number generation on a gaming network
US8100755B2 (en) * 2009-05-11 2012-01-24 Multimedia Games, Inc. Method, apparatus, and program product for distributing random number generation on a gaming network
US20120122579A1 (en) * 2009-05-11 2012-05-17 Enzminger Joseph R Method, apparatus, and program product for distributing random number generation on a gaming network
US8662994B2 (en) * 2009-05-11 2014-03-04 Multimedia Games, Inc. Method, apparatus, and program product for distributing random number generation on a gaming network
US9039516B2 (en) 2009-07-30 2015-05-26 Igt Concurrent play on multiple gaming machines
US9108112B2 (en) * 2011-12-01 2015-08-18 Nintendo Co., Ltd. Game system, game apparatus, storage medium, and game controlling method for game play using a plurality of game apparatuses
US20130143667A1 (en) * 2011-12-01 2013-06-06 Nintendo Co., Ltd. Game system, game apparatus, storage medium and game controlling method
US9468843B2 (en) 2012-09-28 2016-10-18 Everi Games Inc. Wagering game, gaming machine, networked gaming system and method with a player selection symbol replacement game
US20140141862A1 (en) * 2012-10-11 2014-05-22 Scientific Games International, Inc. System and Method for Implementing Play of Internet-Based Games
US9558623B2 (en) 2013-03-13 2017-01-31 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through geolocation reveals
US9786127B2 (en) 2013-03-13 2017-10-10 Game Play Network, Inc. Systems and methods for interactive games
US9305428B2 (en) 2013-03-13 2016-04-05 Game Play Network, Inc. System and method of timing wagers in an integrated wagering and interactive media platform
US9317999B2 (en) 2013-03-13 2016-04-19 Game Play Network, Inc. System and method of managing user accounts to track outcomes of real world wagers revealed to users
US9317997B2 (en) 2013-03-13 2016-04-19 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through allocated reveal payouts
US9317998B2 (en) 2013-03-13 2016-04-19 Game Play Network, Inc. System and method of selecting real-world wagers on behalf of users in an integrated wagering and interactive media platform
US8992312B2 (en) 2013-03-13 2015-03-31 Game Play Network, Inc. System and method of providing an integrated wagering and interactive media platform
US9406195B2 (en) * 2013-03-13 2016-08-02 Game Play Network, Inc. System and method of securing reveals of outcomes of real world wagers
US9443383B2 (en) 2013-03-13 2016-09-13 Game Play Network, Inc. System and method of determining a reveal specification in an integrated wagering and interactive media platform
US8961300B2 (en) 2013-03-13 2015-02-24 Game Play Network, Inc. System and method of providing wagering opportunities based on promotional content
US9489798B2 (en) 2013-03-13 2016-11-08 Game Play Network, Inc. System and method of providing wagering opportunities based on invitations
US9536385B2 (en) 2013-03-13 2017-01-03 Game Play Network, Inc. System and method of timing wagers in an integrated wagering and interactive media platform
US9552694B2 (en) 2013-03-13 2017-01-24 Game Play Network, Inc. System and method of providing wagering opportunities based on gameplay
US9552696B2 (en) 2013-03-13 2017-01-24 Game Play Network, Inc. System and method of providing an integrated wagering and interactive media platform
US8986096B2 (en) 2013-03-13 2015-03-24 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through strategic reveals
US20140274336A1 (en) * 2013-03-13 2014-09-18 Game Play Network, Inc. d/b/a/ Oddz System and Method of Securing Reveals of Outcomes of Real World Wagers
US9576426B2 (en) 2013-03-13 2017-02-21 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through skill based actions
US8961301B2 (en) 2013-03-13 2015-02-24 Game Play Network, Inc. System and method of timing wagers in an integrated wagering and interactive media platform
US9224262B2 (en) 2013-03-13 2015-12-29 Game Play Network, Inc. System and method of selecting interactive media used to reveal outcomes of real world wagers
US9619967B2 (en) 2013-03-13 2017-04-11 Game Play Network, Inc. System and method of revealing the outcomes of wagers through physiological condition-based reveals
US9214063B2 (en) 2013-03-13 2015-12-15 Game Play Network Inc. System and method of revealing the outcomes of real world wagers through escalating reveals
US9728037B2 (en) 2013-03-13 2017-08-08 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through reveals and unreveals
US9767651B2 (en) 2013-03-13 2017-09-19 Game Play Network, Inc. System and method of revealing real world wager outcomes based on user interactions with interactive media
US9299218B2 (en) 2013-03-13 2016-03-29 Game Play Network, Inc. System and method of revealing real world wager outcomes based on user interactions with interactive media
US8968104B2 (en) 2013-03-13 2015-03-03 Game Play Network, Inc. System and method of providing wagering opportunities based on multiplayer interactions
US8992311B2 (en) 2013-03-13 2015-03-31 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through guaranteed reveals and partner promotions
US8968082B2 (en) 2013-03-13 2015-03-03 Game Play Network, Inc. System and method of managing user accounts to track outcomes of real world wagers revealed to users
US9092939B2 (en) 2013-03-13 2015-07-28 Game Play Network, Inc. System and method of providing wagering opportunities based on invitations
US9092940B2 (en) 2013-03-13 2015-07-28 Game Play Network, Inc. System and method of selecting parameters for real world wagers placed on behalf of users in an integrated wagering and interactive media platform
US9922498B2 (en) 2013-03-13 2018-03-20 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through geolocation reveals
US9070253B2 (en) 2013-03-13 2015-06-30 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through single or multiple reveals
US8974284B2 (en) 2013-03-13 2015-03-10 Game Play Network, Inc. System and method of providing wagering opportunities based on external triggers
US9997023B2 (en) 2013-03-13 2018-06-12 Game Play Network, Inc. System and method of managing user accounts to track outcomes of real world wagers revealed to users
US9076295B2 (en) 2013-03-13 2015-07-07 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through geolocation reveals
US10186115B2 (en) 2013-03-13 2019-01-22 Game Play Network, Inc. System and method of revealing real world wager outcomes based on user interactions with interactive media
US10304283B2 (en) 2013-03-13 2019-05-28 Game Play Network, Inc. System and method of timing wagers in an integrated wagering and interactive media platform
US9070252B2 (en) 2013-03-13 2015-06-30 Game Play Network, Inc. System and method of revealing sponsored and other items through mock reveals
US9076294B2 (en) 2013-03-13 2015-07-07 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers through timed reveals and reveal decay
US10373438B2 (en) 2013-03-13 2019-08-06 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers based on a geolocation of a user
EP2814009A1 (en) * 2013-06-11 2014-12-17 Real Time Winning System Inc. Real-time betting, drawing and winning system and method thereof
US9875618B2 (en) 2014-07-24 2018-01-23 Igt Gaming system and method employing multi-directional interaction between multiple concurrently played games
US9972171B2 (en) 2015-09-24 2018-05-15 Igt Gaming system and method for providing a triggering event based on a collection of units from different games
US20190184290A1 (en) * 2017-12-15 2019-06-20 Gree, Inc. Non-transitory computer-readable storage medium, terminal device, and information processing system
US11097191B2 (en) * 2017-12-15 2021-08-24 Gree, Inc. Non-transitory computer-readable storage medium, terminal device, and information processing system
US11517823B2 (en) 2017-12-15 2022-12-06 Gree, Inc. Non-transitory computer-readable storage medium, terminal device, and information processing system
CN110309479A (en) * 2019-07-09 2019-10-08 西安点告网络科技有限公司 Attribute information acquiring method and device
CN111185011A (en) * 2019-12-13 2020-05-22 杭州复杂美科技有限公司 Method, apparatus and storage medium for applying random number under block chain game
US11798376B2 (en) 2021-12-16 2023-10-24 Game Play Network, Inc. System and method of revealing the outcomes of real world wagers using reserve wagering

Also Published As

Publication number Publication date
US20080064494A1 (en) 2008-03-13
US7524245B2 (en) 2009-04-28
US20140106873A1 (en) 2014-04-17
US8608558B2 (en) 2013-12-17
US20090227367A1 (en) 2009-09-10

Similar Documents

Publication Publication Date Title
US8608558B2 (en) System and method for securing electronic games
US6450885B2 (en) Method and apparatus for securing electronic games
US11582209B2 (en) Trusted communications between untrusting parties
EP1016049B2 (en) Apparatus and process for verifying honest gaming transactions over a communications network
US6934846B2 (en) Method of generating unpredictable and auditable random numbers
WO2006052507A2 (en) Online gaming interaction protocol ensuring random events
AU777376B2 (en) Method and apparatus for securing electronic games
AuYoung et al. Cryptographic Blackjack

Legal Events

Date Code Title Description
AS Assignment

Owner name: WALKER DIGITAL, LLC, CONNECTICUT

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHNEIER, BRUCE;WALKER, JAY S.;JORASCH, JAMES A.;AND OTHERS;REEL/FRAME:013478/0586;SIGNING DATES FROM 20020930 TO 20021011

AS Assignment

Owner name: JSW INVESTMENTS, LLC, CONNECTICUT

Free format text: SECURITY INTEREST;ASSIGNOR:WALKER DIGITAL, LLC;REEL/FRAME:013740/0219

Effective date: 20021226

AS Assignment

Owner name: WALKER DIGITAL, LLC, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JSW INVESTMENTS, LLC;REEL/FRAME:017783/0080

Effective date: 20050527

AS Assignment

Owner name: WALKER DIGITAL, LLC, CONNECTICUT

Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:JSW INVESTMENTS, LLC;REEL/FRAME:018668/0615

Effective date: 20050527

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION