WO2011077464A1

WO2011077464A1 - Generic auditable random generator

Info

Publication number: WO2011077464A1
Application number: PCT/IS2010/050013
Authority: WO
Inventors: Jonas Thor Jonasson
Original assignee: Betware A Islandi Hf
Priority date: 2009-12-21
Filing date: 2010-12-21
Publication date: 2011-06-30

Abstract

The present invention discloses a secure system to maintain and audit on-line games. A generic method for to communicate with a session free random number generator and still support audit requirements is described. Game rules are determined by the gaming server (platform) and registered with the audit function (authority). As the RNG is generic, no changes need to be done in the RNG when new game rules (new games) are added to the gaming platform. At the end of each accounting period, audit data are sent to the audit authority to verify that no manipulation has occurred in game playing.

Description

Generic Auditable Random Generator

Field of invention

The present invention relates to a secure system to maintain and audit on-line games. Background of the invention

The Internet is now a common network for performing electronic commerce, banking and electronic mail transactions as well as being widely used for academic purposes, providing information and gaming and betting activities. This is now possible due to the modern communication networks such as the Internet, Wide Area Networks (WANs) and Local Area Networks (LANs).

The traditional gaming and betting systems have been based on direct interaction in a common physical location, such as casinos, bingo halls, sports betting halls and buying physical lottery tickets. The Internet, however, offers a solution for those who cannot visit the physical locations for some reason, such as people living in remote areas far away from traditional gaming and betting facilities, to play anywhere at a time of their choice.

In order to prevent cheating, fraud or any manipulation of on-line games, by either the players or the game provider, several solutions have been used . The present invention provides a new solution to audit on-line games where randomised content is used as part of creating and facilitating the game.

Summary of the invention

The present invention describes the design of Generic Auditable Random Generator hereafter referred to as GARG. First, an auditable, generic, multipurpose random number generator interface is disclosed and thereafter several embodiments of possible usages of this generator will be further disclosed herein.

It is an object of the present invention to provide a generic method for to communicate with a random number generator (RNG) and still support audit requirements. Game rules are determined by the gaming server (platform) and registered with the audit function (authority). This allows the RNG to be abstracted from the gaming platform and the game logic. As the RNG generator is generic, no changes need to be done in the RNG when new game rules (new games) are added to the gaming platform . At the end of each accounting period, audit data are sent to the audit authority to verify that no manipulation has occurred in game playing. The only requirements from the RNG are therefore that it generates a random number, serial number and logs each action. The RNG then sends a random number to the GARG algorithm, which shuffles and secures the game date before sending it to the game platform.

Random numbers are frequently used for major gaming related decision making in computer software and therefore often need to be auditable to be verifiable by third party auditors, such as internal Security and external State Auditors. The problem solved by the present invention relates to a design of a generic method for computer software to communicate with random number generator and still support audit requirements. This is done without creating application specific logic into the random number generator.

The present invention provides a method, a system and a computer program to facilitate games in an on-line gaming network in a secure manner, so that the network can not be manipulated by administrators, suppliers, employees or players. The system and the method of the present invention relate to games where random number generators are used as part of the game. To prevent hackers to manipulate the game, the game criteria are sent to a random number generator in a restricted security domain such as a "Black box" and "shuffled" therein. The whole content is secured before it is sent up to a gaming platform, which further sends the game criteria to the player terminal. One example of a game is ticket lottery game, where the player opens a window/scraped cover of a hidden area . Then the ticket information is sent back to a "Black box" and the content of the selected area is decrypted and the ticket information is sent back to the gaming platform . The gaming platform then reveals the results to the player and the player selects the next window to be revealed . The same process of decryption in the "Black Box" is repeated for each window selected by the player. When the player has selected the pre-determined number of windows to be revealed to him the game is over and based on the selection of windows it is determined if the player has won or lost. It is also possible according to the present invention that the player selects all the windows he is allowed to select and then the gaming terminal sends the whole ticket content behind all the selected windows/areas to the black box for decryption. The present invention applies to other games such as card games etc.

In a first aspect of the present invention a method is presented for facilitating a game based on random numbers in a electronic game network, the method comprising the steps of: a) based on a request, the gaming platform (GP) requests randomized content from a generic auditable random number generator (GARG),

b) the GARG secures the randomized content and sends secured randomized content to the GP,

c) the game selects at least a portion of the secured randomized content from the GP to be revealed,

d) the GP sends the secured randomized content to the GARG for revealing, wherein after the GARG returns revealed randomized content to the GP,

e) the GP displays the revealed randomized content to the game,

f) steps c) - e) are repeated as many times as required by the game, the method is characterized in that the GARG generates randomized content according to game logic and shuffles the randomized content before sending it back to the GP, and in that log audit data are sent separately from the GP and the GARG to an audit server at the end of an accounting period for internal and external fraud detection.

In a second aspect of the present invention a computer program or suite of computer programs is provided, so arranged such that when executed on a processor said program of suite of programs cause(s) said processor to perform the method disclosed above. Furthermore, a computer readable data storage medium storing the computer program or at least one of the suites of computer programs mentioned above is provided.

In a third aspect of the present invention a system is provided for facilitating a game based on random numbers in a electronic game network, the network utilizing at least one player terminal, a gaming platform, a random number generator, a limited access area, data storage means and a cpu means, the system comprising performing the steps of: a) requesting randomized content from a generic auditable random number generator (GARG), based on a request, the gaming platform (GP)

b) securing the randomized content in the GARG and sending secured randomized content to the GP,

c) selection og at least a portion of the secured randomized content by the player, d) sending the secured randomized content from the GP to the GARG for revealing,

wherein after the GARG returns revealed randomized content to the GP,

e) displaying the revealed randomized content to the player,

f) steps c) - e) are repeated as many times as required by the game,

The system is characterized in that the GARG generates randomized content according to game logic and shuffles the randomized content before sending it back to the GP, and in that log audit data are sent separately from the GP and the GARG to an audit server at the end of an accounting period for internal and external fraud detection.

In an embodiment of the present invention a method is presented for facilitating an electronic game network in a gaming platform for generating session free auditable random content from a random number generator. The method comprises the steps of 1) requesting random numbers for a game, based on random number criteria for the game and 2) generating the randomized content for a game and securing the random numbers. In response to a initiation of a game, the following steps are performed : a) sending the secured randomized content to the gaming platform and b) revealing randomized content to the player by decrypting the randomized content. Steps a) and b) are then repeated as many times as required by the game. The method is characterized in that log audit data are sent separately from the gaming platform and the random number generator to a audit server at the end of an accounting period for internal and external fraud detection.

In a an embodiment of the present invention a system is provided for facilitating an electronic game network. The network utilizes at least one player terminal, a gaming platform, a random number generator, a limited access area, data storage means and a cpu means, for generating session free auditable random content from a random number generator. The system comprises a gaming platform which requests random numbers for a game from the random number generator, based on random number criteria for the game decided by the gaming platform and a random number generator, which generates the randomized content for a game and secures the random numbers or randomized content. In response to a initiation of a game, the following steps are performed : a) the random number generator sends the secured randomized content to the gaming platform and b) the gaming platform reveals randomized content to the player at the player terminal Then steps a) and b) are repeated as many times as required by the game. The system is characterized in that log audit data are sent separately from the gaming platform and the random number generator to an audit server at the end of an accounting period for internal and external fraud detection.

In an embodiment of the present invention the gaming platform and the random number generator are located in separate limited access areas. Furthermore, the audit server is located in the third limited access area.

In an embodiment of the present invention the random number criteria for the game is determined by the game played and the random number generator returns encrypted and randomized criteria for the game back to the gaming platform . Furthermore, the game rules determine the criteria for the game. In a further embodiment the game rules are registered in the audit server.

In an embodiment of the present invention the audit server compares the log audit data from the random number generator with the log audit data from the gaming platform using the game rules for each game.

In an embodiment of the present invention the gaming platform and the random number generator are located in separate limited access areas. Furthermore, the audit server is located in the third limited access area .

In an embodiment of the present invention the random number generator is generic and no changes need have to be made in the random number generator when a new game is played.

Definitions

This section describes the interface of the session free random number generator. The design goal for this interface is to design a generic interface/method that can be used to implement various types of games or other software that require session free auditable random numbers that need to be auditable for internal and external cheat/fraud detection.

In an embodiment of the present invention the audit server compares the log audit data from the random number generator with the log audit data from the gaming platform using the game rules for each game. In an embodiment of the present invention the game can be session free. The term "session-free" in the present context refers to a method of playing a an on-line game, where the limited access area does not require a database as the content of the probability game is secured as it is generated in the limited access area and then revealed as the game is played. This means that the system does not require a large data storage means within the limited access area to store ticket information.

The term "limited access area" or restricted security domain may be interpreted as meaning that only certain persons have access to the storage means/server. It may, e.g ., be a secure enclosed system; a so-called "black box" and/or it may comprise a locked compartment. The random number generator may be located in the limited access area. The storage means for the gaming platform and the audit server may also be positioned in the same limited access area (e.g . the same "black box" or the same locked compartment) in each case. In a preferred embodiment of the present invention the "black box" unit may comprise the following components:

A locked box,

A random number generator, and

Storage means

The "black box" can further be described as an environment hosting data storage means, processors and generators and the "black box" may provide a physical barrier which only authorized administrators and auditors have access to.

In the present context the term "player" refers to a person being logged onto a communication network, like the Internet. The player or user is connected to the network through a client, preferably a PC, and from there places orders for tickets. In the present context the player, user or client may be referred to as the game.

In the present context the term "secure" refers to making data or content, such as randomised content, not visible for the player, hacker or the game provider. This can be obtained by means such as encrypting the data or content.

Generate random numbers based on random number criteria. The calling software specifies the criteria for random number generation to instruct the random generator what kind of random is being requested.

Input: Accounting period , random number criteria, audit data

Output: Serial number, random number(s) Accounting period is a free format field to indicate the accounting period for the transaction.

Accounting period is decided by the calling software. This field can example be used for 24/7 support where transaction each belongs to specific accounting period controlled by the calling software. This could for example represent the business date.

A random number criterion is used to instruct the RNG what kind of random number is required . This can be extended to complex structures defining the criteria for random number generation but in its basic form consists of the following parameters:

• Min - the minimum value for the random

• Max - the maximum value for the random

• How many - how many random numbers with this range is required

• Repeats allowed - flag if the same number can repeat

The audit data (input) is a contract between the software using the random for decision making (like a game) and the third party auditors. It is containing all necessary information to audit the decisions taken based on the random number generated. GARG will log the audit data to the accounting period specified. Audit data can either be archived and later export to auditors, or sent real-time directly to auditors. This is typically user information, game action, rules and everything required by the game auditors to verify that the game outcome was correctly selected based on rules, actions and random number generated .

Serial number (output) - Each request to GARG will be responded with a unique serial id .

Shuffle Elements and Secure - Shuffle and secure is another GARG function that accepts an array of data as input parameter. It will shuffle the elements of the array and secure, such as encrypting the whole array after the shuffle so it only can be decrypted by GARG.

Input: Accounting period, Array of elements, Audit data

Output: Serial number, secure result of shuffle

Encrypted result of the shuffle (output) - After the whole array has been shuffled it is secured by GARG. The encrypted value is returned to the calling party. This is a blob of data undeterminable for calling party. The encrypted output will then be used as input for the function defined in next section.

The reveal element will accept an encrypted array from "Shuffle Elements and Encrypt" function. It will decrypt the encrypted array and reveal the content of the elements selected by the element location parameter.

Input: Accounting period, encrypted array, element locations, [public key], audit data

Output: Serial number, revealed elements content

Encrypted array (input) - This encrypted blob contains the array previously shuffled and secured with "Shuffle Elements and Secure" method.

The method and the system of the present invention is outlined in figure 1. When a client (player) buys a game (1) a game request is sent from the GP (GAME) to the GARG (RNG) for randomized content. The GARG or the RNG sends a report (3) an audit service (AUDIT). The GP sends a report (4) of games played and winnings to the audit service. Examples and Drawings

The examples describe some possible, non-limiting, usage of GARG to implement various types of games that can be auditable by third party using the GARG method.

Example 1 - Games that use weighted distribution

In this example, the usage applies to games that use a weighted distribution table to select the prize for the player. Here, the game uses a simple weighted distribution table (see table 1) to select what prize the player should win. This can and is used for various applications like PET Server based games.

Table 1

ure 2 shows a sequence description for the embodiment shown in Example 1.

1. A player request to play a game

2. Game initializes the weighted random distribution table and calculate checksum of it

3. Request a random GARG.GetRandomNumber

a . Random criteria : Min=0, max=totalWeight,count= l

b. Sample audit data : < userid> ; < price> ; <checksum of distribution table>

4. GARG generates a random number based on random criteria, serial and logs audit data

5. Game selects the prize based on random from distribution table

6. Game remote logs the prize selected to GARG

7. GARG generates serial and logs audit data

8. Game Stores the prize

9. Game returns the game play (generated by algorithm or selected from file) to client

10. Client plays the game play

11. Client notifies the game that the play has ended

12. Game payout the prize

13. Prize won if any is sent to client

Example 2 - Game using predefined board array (Card games)

Games using predefined board array are for example card games or any game where the board elements are known but need to be shuffled before play. In this example, a simple card game which needs to deal cards to the calling client, shows the implementation of the present invention. These kind of games are different in that sense from example 1, in that the user can affect the outcome of these games.

Figure 3 shows a sequence description for the embodiment shown in Example 2.

1. Client request to play a game

2. Game initiates default deck as an array with 52 elements representing card deck 3. Game calls GARG.ShuffleAndSecure

a. Accounting period: Business day (YYYYMMDD for example)

b. Array of elements: array with 52 elements each representing a card in a deck c. Audit data: <gameid> <userid>; <price>; <checksum of game rules >

4. GARG shuffles the array and logs audit data. Returns encrypted blob representing the shuffled array

5. Game request to deal the initial cards for the game

6. GARG decrypts the blob and returns the elements that should be revealed from the deck

7. Revealed elements are returned to the game

8. Initial cards dealt are sent to the client

9. Client ask to be hit with another card

10. Reveal element request is send to GARG to deal next card

11. GARG decrypts the blob and returns the elements that should be revealed from the deck

12. Revealed card returned to game (save result)

13. Revealed card sent to client

14. Client stays not wanting more cards

15. Game request to deal house cards (if required by game rules)

16. GARG reveals the requested house cards

17. House cards sent to the game

18. Winner selection is performed based on game rules

19. Remote log winner selection results

20. GARG logs the prize audit data

21. Payout the prize

22. Show game results to player

Example 3 - Find the prize games

The key idea with the game in this example, "Find the prize (FTP)", is that every play is a potential winner. This means that in every play the player has a chance to win a prize.

Find the prize is a game which uses a combination of the two methods described previously. When a play is bought the game server (and subsystems) creates a board with a prize included on the board . This board is hidden both from the player and the game server implementation to prevent cheating by being able to see where the prize is located on the board. Player is then allowed to reveal configured number of items on the board to try to find the prize. If the player reveals combination of items that represents a prize he will win that prize. If player is not able to reveal combination that represents a prize he/she looses the play and the remaining board items are reveled to show the player where the prize combination was located .

Figure 4 is an overview drawing of the system architecture for "Find the prize" games. This architecture can be reused for other game type implementations. The definitions here below are specific for the FTP game, but also disclose the general concept of the present invention of how the GARG is implemented to abstract the gaming system from the random number generator. The only requirements from the RNG are that a random number is provided, generating a serial number and logging this action. Then the GARG shuffles and selects/ reveals randomized content. One of the major advantages of the method and system of the present invention, outlined in example 3, is also that the individual components generate individual logs and are audited by a separate authority.

FTP Game server logic - The game server logic is the actual game implementation. The game logic implementation is based on Instant Game Framework (IGF) implemented by Betware that provides various support for implementing instant games. This game logic implements all the business and play rules for the game as it is specified in game specification. The internals of the FTP game server is described in detail later in this document.

FTP Game configuration - Find the prize game uses three different configuration files that are used to change the attributes for the FTP game instance. These are : deployment descriptor, board definitions and winner selection rules. In addition to this the FTP game uses a prize table for the game instance from BGP. The game configuration is available for the audit process to be able to audit the game plays according to the rules and attributes defined in these files.

FTP Deployment descriptor - The deployment descriptor for the FTP game is based on a standard deployment descriptor for games based on a Instant Game framework. The IGF uses this file to deploy a instance of the game. Sample file and detailed description can be found later in this document.

FTP Board definitions - The board definition file is contains all possible board combinations that can occur in the game. This file is usually generated based on probability calculation when designing the game prize probability. Sample and detailed description can be found later in this document.

FTP Winner selection rules - The pattern file contains rules used by the winner selection process to determine if the play is a winner or not. These rules are defined per game instance. Sample and detailed description can be found later in this document.

Betware Gaming Platform (BGP) - Is the transactions system provides services used by the game to store information about the game play in database. BGP is responsible for data integrity and transaction handling. It handles registered games, opening and closing of games, prize tables, storage of game play and money transfers in and out. It also connects to the GARG (described later) to retrieve random numbers and other services required to implement FTP game using secure auditable method.

BGP Database - Transactional database used to store data from BGP. Game implementations do not have direct access to the database, all data inserts, updates and selects for the game implementation go through the BGP to the database.

Figure 5 shows a sequence description for the embodiment shown in Example 3.

1.

2. Client request to play a game

3. Game initializes the board definition weighed distribution table

4. Game charges the player for the play

5. Game request a random with range from 0 - total weight of board distribution table 6. GARG generates random number and logs audit data

7. GARG returns the random number to the game

8. Board is selected from board file based on random number returned from GARG

9. Game request a shuffle and secure of the board selected

10. GARG shuffles and secures the board and logs audit data

11. GARG returns a blob with shuffled board secured only readable by GARG

12. Game waits for user action

13. User makes a selection from the board and request the element to be revealed

14. Reveal element request is sent to GARG based on user selection (with secured blob)

15. GARG extracts data from the secured blob and reveals the elements selected

16. GARG returns the revealed elements to game

17. Game shows the reveled elements to the client

18. Game performs winner selection to verify if winning combination was reveled

19. Game calls GARG. RemoteLog with results of the winner selection

20. GARG logs the winner selection result

21. Prize is paid out if any

22. Game results are sent to client

FTP deployment descriptor - The FTP deployment descriptor is standard configuration file for all games based on Instant Game Framework (IGF) implemented by Betware. It contains both common attributes for all instant games and also game type specific properties. IGF uses this file to deploy the actual game instance.

FTP board definition file - The FTP board definition file defines all possible combinations of board for a find the prize game. This file is usually generated based on probability calculation for the game instance to adjust the probabilities to acceptable level both for the player and the game operator. Below is a sample probability calculation form and how that maps to a board definition file. Note these are only sample values. Sample: probability calculation

FTP pattern definition file - The pattern definition file defines rules for the winner selection process. FTP Game Logic is very flexible and various types of winner selection rules can be implemented as plug-ins to the actual winner selection process. The winner selection uses these rules when performing winner selection for the play. Currently only one rule is implemented PM = Pattern Matching meaning that it looks for items on the revealed board matching the parameters for the rule implementation. Other rules can be easily implemented if required. This file maps a specific pattern to a prize category. If the winner selection finds a pattern matching the revealed board elements the user wins the prize category specified for this pattern definition. The actual prize is then looked up in the prize table in BGP based on this prize category to do the payout of the actual prize amount.

Audit Process

Game play - The game play for the FTP game is described in the sequence diagram in Section 3. Here we summaries the audit data sent from the game to the external random generator through GARG. The game has actually four main functions that need to be audited .

StartPlay - StartPlay is called by the game client when the player wants to start a new play. This function accepts amount as a input parameter if multiple amounts are allowed per play. It sends the total weight of the boards defined in the board file to the random generator as the upper limit for random number generation. The returned random number will be used to randomly and select board from the board file in an auditable way. Player is charged for play.

ShuffleAndSecure - When a board has been randomly selected based on the result from "startPlay" request it is sent to GARG to be shuffled and secured. This is done to shuffle element locations on the board the player is revealing elements from. revealElement - When elements have been shuffled and secured then the player is allowed to start to reveal elements from the board. Each element location that should be revealed is sent to the GARG to reveal the actual content of the element. GARG will respond with the content of the element revealed . This process will be repeated until the player has revealed all elements he/she is allowed to reveal or finds a prize on the board. endplay - When user has revealed all elements he/she is allowed to reveal the play is over. Winner selection is performed and prize is paid out if the player found a prize on the board . The prize is paid out and request is sent to the GARG to reveal the remaining elements of the board to show the player where the prizes where located on the board, if he/she didn't find any or if the board contains multiple prizes.

BGP Export

BGP needs to export data to the audit process so plays can verified with the plays replayed by the audit process according to the audit data received in the RNG Export. The following exports are made :

• Export of prize table - Prize tables are handled by BGP. These prize tables need to be

exported to the Audit process to verify prize amounts for the plays being audited . Here below is a proposal of file format for the prize table. • Export of game play(s) - BGP is also responsible to export plays to audit process with a specific file format. This format has not been finalized yet but will contain similar information as described as audit data in the section here above with the addition of serial and random numbers generated by the External RNG.

• RNG Export - Export audit data, random numbers and serials. RNG is responsible to log all audit data received from the game. This data needs to be exported to the audit process. Format of this file is not finalized but could be as following :

Audit process implementation

Information exported from BGP and RNG and the three configuration files for the game the audit process can be implemented as shown in figure 6.

Example 4 - Multiplayer games like poker

In this example, a multiplayer poker game ( Texas hold'em) is shown. In some cases it is required by auditors that the hands for each player is not visible for the game until after the round has been played . This is to eliminate the risk of internal fraud such as limiting operators/hackers to see player cards on the game server, until after the round has been played.

Figure 7 shows a sequence description for the embodiment shown in Example 4.

1. Client # 1 request to play a game and send its public key (optionally encrypted)

2. Game wait for more players to start the hand

3. Client #2 request to play a game and send its public key(optionally encrypted)

4. Game prepares a deck of cards (array of 52 cards), charge blinds

5. Game calls GARG.ShuffleAndSecure with array of cards

a . Audit data : <gameid>, [< userid>, <bet > , < blind amount>]*

6. GARG shuffles and secures the deck, logs audit data

7. Encrypted shuffled deck is returned to the game

8. Game calls GARG. RevealElements (0,1, Public key for Client# l) Client # 1 pocket cards a . 0, 1 = reveal two first elements in the encrypted deck

9. GARG reveals the two elements and encrypts the values with public key from client # 1

10. Revealed element values encrypted with client # 1 public key returned to game

11. Game returns these unreadable values to client # 1 that can decrypt them with his private key

12. Game calls GARG. RevealElements (2,3, Public key for Client#l) Client # 1 pocket cards a . 2,3 = reveal next two cards from the encrypted deck

13. GARG reveals the two elements and encrypts the values with public key from client #2

14. Revealed element values encrypted with client #2 public key returned to game

15. Game returns these unreadable values to client #2 that can decrypt them with his private key

16. Client # 1 makes his move by checking, raising or folding the hand

17. Client #2 makes his move by checking, raising or folding the hand

18. Game calls RevealElements(4,5,6) to deal the flop, client actions as audit data a . Audit data : <gameid >,[< userid>, < bet| check|fold>, < betamount>]*

19. GARG reveals the element requested and logs the audit data

20. Reveled cards returned to game, not need for encryption as flop is visible for everybody

21. Flop cards send to both client # 1 and client #2

22. Client # 1 makes his move by checking, raising or folding the hand

23. Client #2 makes his move by checking, raising or folding the hand

24. Game calls RevealElements(7) to deal the turn, client actions as audit data

a . Audit data : <gameid>, [< userid>, <bet| check|fold>, <betamount>]*

25. GARG reveals the element requested and logs the audit data

26. Reveled turn is card returned to game, no need for encryption. Turn is visible for everybody

27. Turn card send to both client #1 and client #2

28. Client # 1 makes his move by checking, raising or folding the hand

29. Client #2 makes his move by checking, raising or folding the hand

30. Game calls RevealElements(8) to deal the river, client actions as audit data

a . Audit data : <gameid >,[< userid>, < bet| check|fold>, < betamount>]*

31. GARG reveals the element requested and logs the audit data

32. Reveled river is card returned to game, no need for encryption. River is visible for

everybody

33. River card revealed send to both client # 1 and client #2

34. Client # 1 makes his final moves by checking, raising or folding the hand

35. Client #2 makes his final moves by checking, raising or folding the hand

36. Game request players initial hands that were previously revealed encrypted to clients

a . Call RevealElements(0,l,2,3) to reveal player cards to game

b. Audit data : <gameid>, [< userid>, < bet| check|fold >, < betamount>]*

37. GARG Reveals players initial pocket cards to game

38. Players initial pocket cards sent unencrypted to the game

39. Game performs a winner selection and payout of prize

40. Winner selection result is remote logged to GARG

41. Hand result sent to client# l and client#2

If either of the client folds before the hand is complete the flow will jump to 39. If required to use "dead" cards or deal one for each client it does not change the flow, only the indexes of the elements being revealed.

Claims

1. A method for facilitating a game based on random numbers in a electronic game network, the method comprising the steps of:

a) based on a request, the gaming platform (GP) requests randomized content from a generic auditable random number generator (GARG),

d) the GP sends the secured randomized content to the GARG for revealing, wherein after the GARG returns revealed randomized content to the GP, and

e) steps c) - d) are repeated as many times as required by the game, characterized in that the GARG generates randomized content according to game logic and shuffles the randomized content before sending it back to the GP, and in that log audit data are sent separately from the GP and the GARG to an audit server at the end of an accounting period for internal and external fraud detection.

2. The method according to claim 1, wherein the requests is based on the game logic stored in the GP and wherein the game logic determines what content is randomized by the GARG.

3. The method according to claim 1, wherein the gaming platform and the GARG are located in separate limited access areas.

4. The method according to claim 1, wherein the audit server is located in the third limited access area .

5. The method according to claim 1, wherein the random number criteria for the game is

determined by the game played and the GARG returns secured and randomized content based on random criteria for the game back to the GP.

6. The method according to claim 1, wherein the game rules/logic are registered in the audit server.

7. The method according to claim 1, wherein the audit server compares the log audit data from the GARG with the log audit data from the GP using the game rules for each game.

8. A computer program or suite of computer programs so arranged such that when executed on a processor said program of suite of programs cause(s) said processor to perform the method of any of the preceding claims.

9. A computer readable data storage medium storing the computer program or at least one of the suites of computer programs of claim 8.

10. A system for facilitating a game based on random numbers in a electronic game network, the network utilizing at least one player terminal, a gaming platform, a random number generator, a limited access area, data storage means and a cpu means, the system comprising : a) requesting randomized content from a generic auditable random number generator (GARG), based on a request, the gaming platform (GP)

wherein after the GARG returns revealed randomized content to the GP, and e) steps c) - d) are repeated as many times as required by the game, characterized in that the GARG generates randomized content according to game logic and shuffles the randomized content before sending it back to the GP, and in that log audit data are sent separately from the GP and the GARG to an audit server at the end of an accounting period for internal and external fraud detection.

11. The system according to claim 10, wherein the gaming platform and the random number generator are located in separate limited access areas.

12. The system according to claim 10, wherein the audit server is located in the third limited

access area.

13. The system according to claim 10, wherein the random number generator is generic and no changes are required in the random number generator when a new game is implemented or played .