U.S. Pat. No. 12,268,970

DETAILED DESCRIPTION OF THE INVENTION

Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention. The words “a” and “an”, as used in the claims and in the corresponding portions of the specification, mean “at least one.”

The term “draw game” refers to any type of game where wagers are placed on an outcome sometime in the future. Thus, a draw game could be a game of roulette, dice, or a Lotto-style ping pong ball drawing.

A “video fragment” is a short (e.g., two seconds) video and audio sequence that is a portion of a “video take.” A “video take” is a portion of a scene wherein the same scene is recorded (filmed) multiple times. A video take is analogous to “takes” when filming a movie where the dialogue, movement, and interaction of the actors and background scenery will generally be the same but will differ in subtle or significant ways from each other. With this disclosure, a pseudorandomly selected series of video fragments are dynamically stitched together to create various video takes with a plurality of video takes comprising a “scene.” The term “Video Store” is used for brevity to mean the database where the video fragments are arranged and saved for dynamic stitching into takes and scenes. In some embodiments, the video store can also be used to save generated video takes and scenes. A video “ruleset” is a set of instructions for a given croupier “group” (e.g., an arrangement of different video fragments or takes of the same croupier) such that the resultant video stream will appear coherent (e.g., the same croupier appearing throughout the draw game, the appearance of time passing in a normal manner) to a player.

The terms “Random Number Generator” or “RNG” are used for brevity to include all forms of random number generation. For example, “True Random Number Generator” or “TRNG,” “Pseudo Random Number Generator” or “pRNG” (e.g., Mersenne Twister algorithms, “Linear Congruential Generators” or “LCGs”), etc. could all be referred to as RNGs in this disclosure.

The terms “WebSocket” and “socket” are used interchangeably throughout this specification and associated claims to refer to an Internet communications protocol providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. Also, the terms “source device” and “apparatus” are also used interchangeably herein. Finally, the term “video” is often used for brevity throughout this disclosure to mean both video and the associated audio embedded in a video fragment, take, or scene.

Reference will now be made in detail to examples of the present invention, one or more embodiments of which are illustrated in the figures. Each example is provided by way of explanation of the invention, and not as a limitation of the invention. For instance, features illustrated or described with respect to one embodiment may be used with another embodiment to yield still a further embodiment. It is intended that the present application encompass these and other modifications and variations as come within the scope and spirit of the invention.

Preferred embodiments of the present invention may be implemented as methods, of which examples have been provided. The acts performed as part of the methods may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though such acts are shown as being sequentially performed in illustrative embodiments.

FIGS.1A through1D, taken together, provide detailed specific embodiments of the disclosed casino game stream system.FIG.1Ais an overall representative example100block diagram of a casino game stream system illustrating the high-level functionality of both its video generation and wager processing subsystems.FIG.1Bis an exemplary block diagram115of the casino game stream system's video generation subsystem. And,FIGS.1C and1Dprovide illustrative block diagrams of the casino game stream system's wager processing subsystem.

As shown inFIGS.1A through1D, the disclosed casino game stream system is illustrated as a conceptual matrix. The three columns (101through103) in the matrix denote the three entities interacting with the system (i.e., the player101, the Operator102, and the Game Provider103) with the four rows in the matrix denoting the four phases (i.e., phase zero104through phase three107) processed by the system for each game. If a particular block diagram function appears entirely within a matrix cell, its functionality is limited to that cell entity and phase—e.g., inFIG.1Bthe Game Selection118function is exclusive to the Player101during phase zero104. If a particular block diagram function straddles cells, its functionality is shared between the two cells—e.g., inFIG.1Bthe Bet Management System (BMS)119function is exclusive to the Game Provider103during phases zero104and one105.

Of the four phases, phase zero104is optional since it is only needed when player101initially logs on for a session. There are typically three entities interacting with the casino game stream system. The player101entity refers to both the human player as well as the “player's device” that is used by the player to connect to the casino game stream system. The optional demarcation between Operator102and Game Provider103entities is included since the Game Provider103typically provides the actual draw game system and the appropriate video streams as a “white label” product to the Operator102. The Operator102is the player-facing brand casino or online site (e.g., MGM, Caesars, Paddy Power) that is typically licensed in a given jurisdiction to accept wagers and establish digital wallets to hold the player's funds. Thus, two entities typically provide casino game stream services to the player101primarily due to licensing, brand recognition, and liability limitations. Of course, under some circumstances, it may be desirable for one, three, or more entities to offer casino game stream services; those arrangements would still be compatible with this disclosure.

Starting with theFIG.1Aoverall representative example100block diagram, during phase zero104player101logs into the casino game stream system108automatically initiating first sector authentication within the Operator102subsystem. Once first sector authentication is successfully completed, player101is presented with a welcome screen typically showing a virtual lobby where any of a plurality of games can be selected by the player101(e.g.,FIG.2A). When player101(FIG.1A) selects a particular game, a second sector authentication is automatically initiated by the Game Provider103subsystem. Immediately upon completing the second sector authentication process, the casino game stream system will proceed to phase one.

During the phase one105preamble109, a pseudorandom series of video fragments are assembled into a scene offering various takes of a croupier waiting to spin a money, dice, or roulette wheel. This seamlessly assembled preamble scene is streamed to the players101throughout the phase one105wagering period. If the player101selected a game that is in progress, the player101will not be able to make a wager until the previous game is completed and a new game begins. During this waiting period, the player's101video stream will typically display the game in progress with a video overlay instructing the player101to please wait for the next game (e.g.,FIG.2B). This waiting period is necessary since players wager on the same game—i.e., the same game is typically broadcast to a plurality of players101(FIG.1A). When a new game begins, during this phase one wagering period, a player101can make a wager on the pending drawing (e.g.,FIG.2C).

At phase two106(FIG.1A), the “No More Bets” period110begins. As its name implies, the casino game stream system shuts down all wagering for the pending drawing at the start of this period, streaming messaging that the time for wagering for the pending drawing has ended (e.g.,FIG.2D). While the “No More Bets” messaging is streaming, after a predefined short delay (e.g., two seconds), the Bet Management System (BMS) performs a connection check for all players101(FIG.1A) who have pending active wagers. If a player101remains connected, the BMS will debit the wagered funds from the player's101wallet and log the wager for the pending drawing. Conversely, if a player101is disconnected from the casino game stream system when the BMS is performing the connection check the pending wager is essentially voided. Also, during this time period, Game Provider103executes a call to a RNG to determine the winning results for the pending drawing. Once the RNG drawing results are completed, a pseudorandom series of video fragments are assembled into a scene that shows the winning drawing results.

At this point, the casino game stream system enters the final phase (phase three107) for the game, showing the drawing results111(FIGS.2E and2F). During this period, any player101(FIG.1A) with a winning wager will have their winnings automatically deposited in their wallet. Finally, the winning draw results scene is streamed to all active players101with winning players101receiving winning notifications.

Therefore, the casino game stream system100can operate in four modal phases (104through107) across three different entities (101through103). By providing different functionalities with each phase, the system ensures security by not determining the pending drawing result until the “No More Bets” (phase two106) begins. Additionally, by verifying each player's101connection status before honoring their wager and debiting their wallet, the system100also ensures wager integrity.

FIG.1Bprovides an exemplary matrix block diagram115overview of a general embodiment of a casino game stream system's video streaming subsystem. Phase zero104starts with a player101logging into the casino game stream system116. Once the player101completes the login process, she will be presented with a Welcome Screen117, which is typically illustrated as a virtual lobby where the player101can select118any one of a plurality of games on offer. As shown in matrix block diagram115, the initial player login and welcome screen are controlled by the Operator102.

When the player selects a game, the Bet Management System (BMS)119conducts a second sector authentication process and, upon completion of that process, coordinates with the Video Controller/Scheduler120to determine if the player's101selected game is ongoing, if so the player101will be presented with a “Please Wait” video stream (e.g.,FIG.2B) transmitted to the player's (FIG.1B) device121. After completion of the previous game or if no game was currently in process, the player101will be presented with a Preamble Video Stream125transmitted to the player's101device121. The Preamble Video Stream125is a pseudorandom arrangement of video fragments organized into a series of takes comprising a scene featuring the same croupier that will be shown conducting the drawing in the future.

The Preamble Video Stream125video fragments are pseudorandomly arranged with input from a Random Number Generator (RNG)124. The RNG124passes at least one seed number to the Video Controller/Scheduler120, which arranges the video fragments from the Video Store Database123into the Preamble Video Stream125. The Video Controller/Scheduler120ensures the Preamble Video Stream125is arranged within the ruleset for the given croupier grouping.

The video fragments saved in the Video Store Database123are arranged by the three game phases (105thru107) such that pseudorandomly selecting video fragments from a given phase storage will result in a coherent and chronologically correct appearing scene for that phase. There are typically a plurality of takes representing the same video fragment allowing for pseudorandom selection of video fragments for a scene, thereby ensuring variance.

Optionally and preferably, the assembled video stream is embodied as a dynamic m3u8 (Moving picture experts group layer 3 Unicode 8 characters) file. The m3u8 file format has the advantage of being a single-entry playlist file pointing to a stream in each player's channel. This allows the casino game stream system to present the Preamble Video Stream125and the No More Bets Video Stream127to the player101before the winning draw has been determined.

During phase one105the player101has the option to make a Wager122. If the player101makes a Wager122, the wager is transmitted to the BMS119which records it in a pending status in the Wager Database (seeFIG.1C, callout156). Optionally and preferably, the BMS119(FIG.1B) will also instruct the Video Controller/Scheduler120to insert a wager-accepted message or image into the player's101Preamble Video Stream125. Again, the dynamic capabilities of the preferred m3u8 file format allow for player101specific video streams that can be modified after an action by a player101—e.g., placing a Wager122.

Phase two106commences after a predetermined time period expires or some other event occurs (e.g., a minimum or maximum number of wagers has been submitted). At the start of phase two106, the RNG124passes at least one seed number to the Video Controller/Scheduler120, which arranges the video fragments from the Video Store Database123into the No More Bets Video Stream scene126, which is transmitted to the player's device127. The No More Bets Video Stream scene126is a pseudorandom arrangement of video fragments organized in a scene featuring the same croupier from the Preamble Video Stream scene125. Also, during phase two106, the actual drawing occurs with all pending wagers finalized.

Finally, phase three,107, begins with the Video Controller/Scheduler120using the RNG124draw number (and possibly other RNG124numbers) to generate the Draw Results Video Stream scene128, which graphically reveals the draw results to the player's device129. The Draw Results Video Stream scene128will include the actual drawing results generated from the pseudorandom arrangement of video fragments organized into a drawing results scene featuring the same croupier as before. Once again, the dynamic capabilities of the preferred m3u8 file format allow for player101specific video streams that can individually reveal if a player101is a winner or not.

FIGS.1C and1D, taken together, provide an exemplary matrix block diagram overview of a general embodiment of a casino game stream system wager processing subsystem150and170.FIG.1Cillustrates wager processing subsystem functionality for phases zero104and one105.FIG.1Dillustrates wager processing subsystem functionality for phases two106and three107.

FIG.1Cbegins with the player101logging151into the Player Account Management (PAM) function152, controlled by the Operator102. When the login request151is received by the PAM152, the PAM152typically queries its Player Database153to authenticate the player101to the first sector (Operator subsystem102). This first sector authentication process typically involves the player101entering a player name and associated password. The entered player name and password are verified against a Player Database153—the password is preferably stored in the Player Database153as a cryptographic hash, not in cleartext. Upon successful first sector authentication, the player is shown a welcome screen typically illustrated as a virtual lobby where any of a plurality of games can be selected by the player101utilizing the Game Selection function155. When the player101selects a particular game, the Game Provider103subsystem automatically initiates a second sector authentication process.

The first sector authentication process can be thought of as the player's101device authenticating to the Operator102server. The second sector authentication is the Operator102server authenticating with the Game Provider103server to provide a player101unique, bidirectional communications channel that persists as long as the player's101login session persists. The purpose of the second sector authentication process is to allow the Game Provider103server to send and receive player101unique data such that multiple draw game sessions can be supported without the Game Provider103server necessarily gaining specific knowledge of the player's101identity or direct access to the player's101digital wallet. Thus, the first and second sector authentication processes essentially provide a conceptual firewall between the Operator102and Game Provider103servers, protecting the players'101data and funds as well as ensuring that the Operator102cannot impact pending drawing results nor gain draw results before the actual drawing is concluded.

Returning toFIG.1C, when the second sector authentication process is initiated, the Operator102server generates a secure token embodying the player's101Identification Data (ID) and session (connection) ID. The Game Provider103Bet Management System (BMS)154receives the information in this secure token and then sends it back to the Operator102server Wallet Database157for account verification. The Wallet Database157responds with possibly a new token (player101ID and session ID for the wallet) or an acknowledgment over the original session ID with the BMS154recording one or both sets of player and session IDs in its Wager Database156. These one or two player/session ID channels are then used by the Operator102and Game Provider103servers for all bidirectional communications (e.g., video streams, player101wagers, draw game results) as long as the player's101login session persists.

Optionally, the various player101session communications channels are encrypted, preferably using asymmetrical (public/private) encryption to encrypt a shared symmetrical encryption key (e.g., X.509 certificates and Transport Layer Security or “TLS”). Thereby further ensuring the transmitted data's confidentiality, security, and integrity. Optionally, a WebSocket protocol is established on top of the HTTP (Hyper Text Transfer Protocol) communications layer for player101session communications channels with each WebSocket linked directly to a player101. Preferably, an HTTPS (Hyper Text Transfer Protocol Secure) communications layer could be established for player101session communications channels between BMS154and Wallet Database157. Thus, the player and session IDs are linked to given WebSocket(s), allowing the BMS154to store WebSockets IDs in its Wager Database156to support sessions. This simplifies real-time communication by maintaining an active link between the Operator102and Game Provider103servers, allowing the Game Provider103to quickly send updates like game results, wager outcomes, or status changes while the Operator102can instantly report game actions or player interactions back to the platform—e.g., wagering.

After the dual sector authentication is completed for the player101, the BMS154optionally initiates a second request to the Wallet Database157using the appropriate player101channel to retrieve the player's101wallet balance. Alternatively, the BMS154can query the Wallet Database157after a wager is made to determine if a player101has sufficient funds to cover the wager or if a player's desired wager is within her credit limit. The second option has the advantage of the Game Provider103subsystem never gaining knowledge of the player's101wallet balance with the disadvantage of a more complex wager protocol. Regardless of the BMS154query to the Wallet Database157protocol, when the player101makes a wager the Wager function158interacts with the BMS154to register the wager, logging the pending wager in the Wager Database156.

At this point, phases zero and one are completed, and the casino game stream system progresses to phase two159. Phases two and three are illustrated170inFIG.1D. Phase two begins171with a “No More Bets” mode initiated, with the “No More Bets” notification streamed to the players101. When the “No More Bets” video stream is broadcast to the players101, the BMS154′ enters a short delay period172(e.g., two seconds) before looping through each player101logged into the casino game stream system to ensure each connected channel remains active. In one particular embodiment, the BMS154′ tests for an active connection by pinging each player's device173and waiting for an acknowledgment from each device. As the BMS154′ tests174each player101for an active connection, any player101link that has dropped will have any pending wager deleted175. Thus, if a player101lost their connection at that point, their wager is not honored/placed. The BMS154′ will not transact with the wallet; the wager is essentially voided. By not immediately debiting a player's wallet when a wager is made by the player, the BMS154′ effectively allows a player to change or withdraw their wager on the upcoming draw game so long as preamble phase one persists.

Conversely, if a player101is still connected, the BMS154′ transacts with the Wallet Database181, making the wagering request to debit the player's101balance based on the wager placed176. The completed wager is then logged into the Wager Database177.

Once all pending wagers are verified and consummated, the BMS154′ initiates a call to a RNG178to determine the outcome of the pending drawing179. The RNG178selects the winning draw179with the same RNG178draw results arranging the pseudorandom selection of the appropriate video fragments into the drawing results scene. After the drawing results are known179, the Wager Database177is queried180such that all placed wagers are set to winning or losing status. Since the BMS154′ does not make the call to the RNG178to determine the pending draw winner179until the casino game stream system enters phase two106(i.e., “No More Bets”), the potential for illicit wagering (where the outcome is known before the results are publicly announced) is significantly reduced if not eliminated.

After all the winning wagers are determined the casino game stream system enters phase three107. In this phase the winning player's101wallets are credited182with the appropriate funds in the Wallet Database181. At the same time, the draw game results are streamed to each player101still connected to the system, with winning players101preferably receiving special notifications183.

In a scenario where a player's101wager was successfully placed in the BMS154′ with the player's101wallet debited181and the consummated wager logged into the Wager Database177, but the player101is disconnected before the results are announced, their wager will not be impacted. If a player101wins their wager, the BMS154′ will continue to operate and settle the wager on the player's101behalf with any winnings automatically credited to the player's101wallet in the background.

FIGS.2Athru2F, taken together, illustrate examples of one general embodiment of this invention providing a casino game stream system.FIGS.2Athru2F are arranged in chronological order starting with the welcome screen, progressing through wagering and “No More Bets,” and culminating with the draw game results.

Starting withFIG.2A, this initial welcome screen (phase zero) is an illustrative example of what would be streamed to the player after logging in. After the player selects a game to play, the casino game stream system will progress to phase one.

If the player's selected game is in progress, the player will not be able to wager on the current game with the player's video stream displaying some type of “Please Wait” message, as shown inFIG.2B. Typically, this “Please Wait” message will be embodied as an overlay with the current game displayed in the background of the video stream. Allowing the player to see the current game without the ability to wager on the game has the advantages of both reducing potential boredom during the waiting period as well as subtly informing players that they are participating in a large draw game with other people wagering on the same game results. Once the extant game concludes and a new game commences, the player will now be able to wager on the new and subsequent games. During this phase one wagering period, the player can typically make wagers by clicking on different portions of the video stream, as shown inFIG.2C.

Moving onto the phase two “No More Bets” period, the player is notified that the “No More Bets” period has commenced typically with an overlay over the video stream, as shown inFIG.2D. Finally, phase three reveals the draw game results in the video stream with winning players typically receiving notification during this period. Examples of phase three draw game result video streams are shown inFIGS.2E and2F.

Thus, the disclosed casino game stream system provides video streams of human croupiers conducting draw games seemingly in real time. By progressing chronologically through the various phases of each draw game, a natural rhythm develops. Additionally, the disclosed casino game stream system features a scheduler function that ensures subsequent games include a “memory horizon” of previous games such that each new game essentially picks up where the other game left off. For example, if a spinning money wheel is used in a draw game, the starting position for a new game wheel spin will be where the previous game ended.

With this disclosure the Game Provider103controls the combining of the video streams with the live wagering.FIG.3Aillustrates an exemplary matrix block diagram overview300of how the Video Controller/Scheduler120′ interacts with the BMS154″ within the Game Provider system103. The two columns (120′ and254″) in the matrix represent the Video Controller/Scheduler120′ and the BMS154″. The four rows in the matrix denote the four phases. As before, if a particular block diagram function appears entirely within a matrix cell, its functionality is limited to that cell entity and phase—e.g., the Stream Game Preamble function305is exclusive to the Video Controller/Scheduler120′ during phase one105.

FIG.3Astarts immediately after the player has been authenticated by the two sectors302in phase zero104. After authentication, the Video Controller/Scheduler120′ progresses to phase one and checks to determine if the game selected by the player is presently ongoing303. If so, the Video Controller/Scheduler120′ constructs a “Please Wait” video stream and transmits it to the player's device304. If not or when the ongoing game is concluded, the Video Controller/Scheduler120′ constructs a preamble stream305where the player can wager306on the upcoming draw. After the time period for wagering expires and the system progresses to phase two106, the Video Controller/Scheduler120′ constructs the “No More Bets” video stream and transmits that stream to the player307. At this point, the BMS154″ determines the Winning Draw308and transmits the results to the Video Controller/Scheduler120′. The Video Controller/Scheduler120′ accepts the draw results data and constructs the phase three107Draw Results309video stream.

FIG.3Billustrates a detailed exemplary matrix block diagram320of the Video Controller/Scheduler120″ interacting with the Game Provider system103. The matrix's two columns (120″ and321) represent the Video Controller/Scheduler120″ and the rest of the Game Provider system321. The three rows in the matrix denote phases one through three—phase zero was omitted since the Video Controller/Scheduler120″ is not utilized in phase zero. As before, if a particular block diagram function appears entirely within a matrix cell, its functionality is limited to that cell entity and phase.

The detailed exemplary matrix block diagram320of the Video Controller/Scheduler120″ begins when the casino game stream system exits phase zero322after the player is fully authenticated to the system and begins phase one105. Initially, the system determines if the game the player selected is in progress or starting anew323. If the game is in progress, the Video Controller/Scheduler120″ generates a “Please Wait” overlay324and inserts it on top of the current game, thus streaming the current game with the “Please Wait” overlay (e.g.,FIG.2B) to the player's device325(FIG.3B). During this “Please Wait” period the player's wagering buttons for the current game will be disabled such that the player will be unable to make a wager.

After the previous game concludes or if the game the player selected was not ongoing323, the Video Controller/Scheduler120″ will begin constructing the preamble scene to be streamed for the next game327. This process is initiated by the Video Controller/Scheduler120″ referencing the Starting Parameters326, Scheduling Rules Database328, and the Least Recently Used (LRU) algorithm339for the upcoming game. The Starting Parameters326, Scheduling Rules Database, and LRU algorithm339partially cull the set of video fragments available to the Video Controller/Scheduler120″ to provide a more realistic and logically coherent (i.e., reasonable scene structure given the structure of the previous game) preamble scene.

For example, the croupier selected for a given game can be a function of a virtual “shift” where each croupier may appear in a series of game drawings and then be replaced by another croupier after their series “shift” ends. With this example, the croupier's virtual “shift” may be based on Chronological Time329, where no croupier can appear in video feeds for longer than forty consecutive minutes or may be a function of a fixed number of draw games (e.g., seven). Thus, in these examples, the pool of available croupier video fragments would potentially be restricted to the constructer or controller327to accommodate the virtual “shift” concept. In another example, the same croupier cannot simultaneously appear in two games. In another example, the scene may include a window appearing to show the outside world where the outside world's appearance would change to reflect the real world Chronological Time329. In all of these examples, Chronological Time329can be employed to create a more realistic and logically coherent scene appearance.

Preferably, the Starting Parameters326should also allow the acceptance of a feedback loop from the previous game (338and338′). This feedback loop (338and338′) effectively extends the Video Controller/Scheduler120″ “memory horizon” to previous games such that each new game essentially picks up where the other game left off. For example, if a draw game features a spinning wheel, the starting position for a new game wheel spin will appear where the previous game wheel spin ended. Since the outcomes of previous draw games were determined by a RNG and not preordained, this game-to-game “memory horizon” requires the feedback loop from the previous game (338and338′) to inform the Starting Parameters326of the correct configurations and, consequently, the correct video fragments to select for the start of the next scene by culling the video fragments showing non-correct starting configurations.

Optionally and preferably, the Least Recently Used (LRU) algorithm339also has a “memory horizon” of previous games with a feedback loop (338and338′) informing it of the exact video fragments that were used in the previous game(s). This enables the LRU339to prevent the repetition of video scenes players have already seen or similarly appearing scenes. Thus, the optional LRU algorithm339enhances the player experience by ensuring more diverse and engaging content from game to game.

Notice that the “memory horizon” enables the Starting Parameters326to primarily select video fragments from the previous game or scene (e.g., the starting position of a wheel for the upcoming draw game must be identical to the previous game wheel ending position) while the LRU339eliminates video fragments from the previous game or scene. Therefore, it is possible that the specified video fragments for the Starting Parameters326and LRU339functions will conflict. For example, assume the ending position for a previous game/scene culminated with a wheel position of the number “13;” then the Starting Parameters326would specify video fragments with a starting wheel position of “13” while the LRU339would cull video fragments with a starting wheel position of “13.” Thus, each scene constructor (327,334, and336) will preferably include rulesets to establish a hierarchy of which video fragments should be culled in the case of conflict for a pending scene to remain logically coherent—e.g., in the previous example, the Starting Parameters326selection of the video fragments associated with wheel starting position “13” would overrule the LRU339attempt to cull the same video fragments.

Once the Starting Parameters326, Scheduling Rules Database328, and LRU algorithm339restrictions for the upcoming game are established, the Video Controller/Scheduler120″ constructs the preamble scene327(e.g.,FIG.2C) for the upcoming game using the set of video fragments still available from the Video Store Database331(FIG.3B) with variance in the scene ensured by the RNG330. The RNG330provides scene variance by pseudorandomly selecting a series of video fragments in chronological order from the pool of video fragments available in the Video Store Database331after the Starting Parameters326, Scheduling Rules Database328, and LRU algorithm339restrictions were applied. When construction327of the scene is completed, the resulting preamble scene is streamed to the active players' devices332. Optionally, the preamble scene can be embodied as a dynamic m3u8 single-entry playlist file, which allows the video stream of the scene to begin before the end of the scene is constructed. This option has the advantage of variable-length scenes.

When the phase one105stream is completed, the casino game stream system enters phase two106by constructing the “No More Bets” scene334(e.g.,FIG.2D) with the phase one ending state, Scheduling Rules Database328(FIG.3B), and/or LRU algorithm339optionally restricting the pool of video fragments available from the Video Store Database331to an approved set for phase two. Again, the RNG330ensures variance for the “No More Bets” scene by pseudorandomly selecting video fragments available from the restricted set of video fragments in the Video Store Database331. When construction of the “No More Bets” scene is completed334, the resulting scene is streamed to the active players' devices335.

Finally, when the phase two106stream is completed, the casino game stream system enters phase three107by constructing the scene revealing the draw game results or draw game outcome third phase scene336(e.g.,FIGS.2E and2F) with the phase two ending state and/or the Scheduling Rules Database328(FIG.3B) optionally restricting the pool of video fragments available from the Video Store Database331. However, when constructing the drawn game results, the Video Controller/Scheduler120″ must first communicate with the BMS333to ascertain the winning draw game outcome or draw results. When the winning results are known, the set of available video fragments is again restricted, with the RNG330providing variance by pseudorandomly selecting video fragments available from the set of video fragments from the Video Store Database331. When construction of the winning outcome or draw results scene is completed336, the resulting scene is streamed to the active players' devices337with the concluding parameters relayed338to the Starting Parameters function326for the next game.

FIG.3Cillustrates an exemplary swim lane block diagram350of the Video Controller/Scheduler351implemented with an optional player feedback loop that allows the players101to control visual portions of the preamble, “No More Bets,” and/or draw results scenes. The swim lanes columns (101thru103) represent the player101, Operator102, and Game Provider103. No phase division rows are illustrated inFIG.3Csince the player feedback loop option can be implemented in phases one, two, or three or all of the phases one through three. Similar to before, if a particular block diagram function appears entirely within a swim lane, its functionality is limited to that swim lane. The optional player feedback loop disclosure is limited to the phase one preamble scene for simplicity of discussion, but it should be understood that it could also apply to phases two, three, or all three phases.

When the Video Controller/Scheduler351begins constructing the preamble scene to be streamed for the next game the Starting Parameters326, Scheduling Rules Database328, and the LRU algorithm339for the upcoming game are typically utilized to restrict the pool of video fragments in the Video Store Database331. With the addition of the optional player feedback loop functionality357, the pool of potential video fragments may be expanded to include additional video fragments (e.g., Player's Choice Video Store Database358) that can be effectively selected by the players impacting the appearance of a video scene327but not impacting the draw game's outcome. Alternatively, the additional video fragments under the control of the optional player feedback loop can be added to the Video Store Database331, eliminating the construction of the Player's Choice Video Store Database358at the possible cost of greater complexity in the constructor327logic.

For example, in one embodiment, each individual player (353thru356) can select which croupier spins a virtual wheel for the upcoming draw. In this example embodiment, additional video fragments can be made available from the Player's Choice Video Store Database358(e.g., video takes where the pool of available croupiers are all seated on a couch with the chosen croupier standing up and leaving the couch area when the time has come to finalize the drawing) that supplement the standard video fragments in the Video Store Database331to provide the extra video takes needed to accommodate the player feedback loop. As before, the optional additional player feedback loop video fragment selection would utilize the RNG330to ensure variance when constructing player feedback loop scenes327. The additional player feedback loop video fragments added to the preamble scene would not impact the drawing results but would allow players101to possibly feel some control over the game's outcome (e.g., a player101selects their “lucky” croupier). Notice that in this example embodiment, the different individual players (353thru356) can experience different appearing video streams332(e.g., different croupiers) while sharing the same drawing result.

In another example, all of the players (353thru356) connected for a particular game can vote on specific player feedback loop options. The option receiving the most votes becomes the video stream332that all players will see. This example embodiment differs from the previous exemplary embodiment in that all of the players101will see the same player feedback loop variable video stream332, whereas, with the previous embodiment, each player would have viewed their own customized video stream.

This first exemplary embodiment has the advantage of customizable video streams to each player's desire with the disadvantages of higher technical complexity and possibly a greater sense of isolation for the player. The second exemplary embodiment is inherently technically simpler and has the potential advantage of customizable video streams determined by popular vote where the players can feel they are participating in a group.

Optionally, the second exemplary embodiment can include a group chat capability via a chat platform where each player (353thru356) can type comments that the other players (353thru356) will see—e.g., discuss which croupier or wheel is “lucky.” This chat option would possibly demonstrate to each player that he or she is participating in a “live” event, generating a feeling of comradery. Additionally, the chat option may also have the benefit of extending the phase one preamble time period in a natural manner since the players would be reading and responding to chats rather than simply waiting for a drawing to occur. The extended phase one preamble time period also potentially increases the opportunity for extended wagering.

Since the optional player feedback loop feature creates dynamic selections of video fragments based on human players' choices, it is possible that the resulting player feedback loop video scenes/streams will vary in duration depending on players' selections. By embodying player feedback loop video streams as a dynamic m3u8 single-entry playlist file, the duration of the player feedback loop video scenes/streams can vary even after a stream has started, allowing for player-induced delays.

FIGS.4A and4B, taken together, show different embodiments of this disclosure, providing two exemplary illustrations of dual sector authentication.FIG.4Aillustrates an exemplary swim lane block diagram400highlighting the primary embodiment of the casino game stream system's unique dual sector player authentication.FIG.4Billustrates an alternative exemplary swim lane block diagram400′ embodiment of the casino game stream system dual sector player authentication. The swim lanes columns (101thru103) represent the player101, Operator102, and Game Provider103. No phase division rows are illustrated inFIGS.4A and4Bsince the dual sector player authentication process is initiated and completed in phase zero. Similar to before, if a particular block diagram function appears entirely within a swim lane, its functionality is limited to that swim lane. If a block diagram function straddles a swim lane (e.g., firewall403′ ofFIG.4A) its functionality is shared between the two swim lanes.

Generally, the first401and second402dual sector player authentication functionality enables the isolation or “siloing” of information in one portion of the casino game stream system from the other. Specifically, this isolation or “siloing” limits potential liabilities and legal requirements for the Operator102and Game Provider103while at the same time enhancing security for the overall casino game stream system.

The Operator102portion performs first sector authentication409with the players101, allowing each player (403thru406) access to the casino game stream system. The information407required for first sector authentication401includes player login credentials, player identification (ID), player wallet funding/withdrawal, and player wallet account management—e.g., Office of Foreign Assets Control (OFAC), Know Your Customer (KYC), etc. This first sector authentication409allows the player101to log in, manage accounts, and select a draw game for a potential wager. With first sector authentication401, all player identifiable information and associated legal requirements are confined to Operator102, isolating Game Provider103from this information and consequently reducing the potential liability and legal regulations of Game Provider103.

Second sector authentication402allows the Game Provider103to connect with the Operator102to enable the players101to view the streamed video scenes, wager on a pending drawing, and collect any winnings from a successful drawing wager. The second sector authentication process410transparently interfaces each player101with the Game Provider103via the Operator102system without revealing any personal information about the player101—i.e., any personal player information is effectively redacted from the Game Provider103. Personal information is also interchangeably referred to herein as Personally Identifiable Information (PII).

When the second sector authentication process is initiated, the Operator102server generates a secure token embodying the players'101Identification Data (ID) and session (connection) ID. The Game Provider103receives the information in this secure token and then sends it back to the Operator102server for account verification. The Operator102server responds with possibly a new token (player101ID and session ID for the wallet) or an acknowledgment over the original session ID. These one or two player/session ID channels are then used by the Operator102and Game Provider103servers for all bidirectional communications (e.g., video streams, player101wagers, draw game results) as long as the player's101login session persists. Thus, each player (403thru406) can view their respective video streams and make wagers without the Game Provider103knowing anything about the specific player's identity or bank accounts.

By establishing player (403thru406) unique channels where specific information about each player is unknown to the Game Provider103, the casino game stream system400isolates or siloes the information and associated functionality of the Operator102and Game Provider103portions. Thus, the Operator102responsibilities are limited to player authentication, player management, and player wallet management407with the Game Provider102responsibilities limited to video scene/stream creation, wager management, and drawing results408. This underlying architecture greatly enhances the security of the casino game stream system400, effectively creating separate sandboxes or silos for the Operator102and the Game Provider103. With the preferred embodiment400ofFIG.4A, this isolation is further enhanced by providing optional firewalls (403″ thru406″) between the Operator102and Game Provider103as well as firewalls (403′ thru406′) between the Operator102system and the players101. The preferred embodiment400ofFIG.4Aillustrates the player (403thru406) unique channels passed through the Operator's102portion of the casino game stream system connecting to the Game Provider portion103without any processing or monitoring by the Operator's102portion.

As illustrated inFIG.4B, an alternative embodiment400′ shows each player (403thru406) directly connecting (413thru416) to the Game Provider103through a firewall420without any Operator102passthrough. With this embodiment, the original session ID received by the Game Provider103from the Operator102, also contains Universal Resource Locator (URL) credentials that allow each player's (403thru406) device to hyperlink and connect directly to the Game Provider103with the Game Provider103establishing an Internet URL socket compliant with the URL credentials contained in the secure token ID. Thus, with this alternative embodiment400′, a direct link between the player's (403thru406) device and the Game Provider103can be established with each player's (403thru406) device URL credentials functioning as the direct player (403thru406) authentication credentials to the Game Provider103.

Optionally, and preferably for either embodiment (400and401′) the player (403thru406) unique channels can be encrypted end-to-end, preferably using asymmetrical (public/private) encryption to encrypt a shared symmetrical encryption key (e.g., X.509 certificates and TLS). Thereby further ensuring the transmitted data's confidentiality, security, and integrity.

In the immortal words of polymath John von Neuman, “Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.” The casino game stream system Game Provider103portion is highly dependent on its RNG to ensure variance in its video scenes/streams as well as to determine the outcome of its drawings. However, the Game Provider103portion preferred RNG core is a Mersenne Twister pRNG algorithm, which is a deterministic pseudorandom number generator.

A Mersenne Twister Pseudorandom Number Generator (pRNG) algorithm is preferred because of its relative simplicity, ease of implementation, well-known acceptable pseudorandom output over a period of 219937, and forensic audit capabilities given its starting seed(s). The Mersenne Twister algorithm is based on a matrix linear recurrence over a finite binary field producing a pseudorandom output that would pass most tests for randomization over the period of 219937cycles. The matrix linear recurrence of the Mersenne Twister algorithm is dependent on its starting seeds (numerical inputs) and will output a sequence of random appearing numbers based on the starting seeds for the entire period of 219937cycles. Thus, in theory, the Mersenne Twister algorithm output could be predicted by an adversary if its starting seeds were known.

The casino game stream system preferably overcomes this theoretical security complication of the Mersenne Twister algorithm505(FIG.5) principally by periodically reseeding its starting seed and cryptographically hashing (e.g., Secure Hash Algorithm One or “SHA-1”) and combining506multiple outputs of the 32-bit Mersenne Twister algorithm. The cryptographic hashing506of the Mersenne Twister algorithm505output partially obfuscates the algorithm's internal state from any adversarial observer. Additionally, an 8:1 Input-to-Output (I/O) ratio506further obfuscates the algorithm's output—i.e., every five pseudorandom 32-bit integers outputted by the RNG502require forty 32-bit hashed pseudorandom output integers from the Mersenne Twister algorithm505.

For example,FIG.5illustrates500several embodiments utilizing the Mersenne Twister pRNG algorithm505as the core component for the Game Provider103RNG502, which provides inputs to the BMS517and the three phases (105thru107) of scene construction algorithms (511thru513) streaming video to the players (514thru516). All embodiments cryptographically hash and apply an 8:1 I/O ratio506to all integer outputs from the Mersenne Twister pRNG algorithm505. The differences between the various embodiments illustrated inFIG.5are primarily in reseeding the Mersenne Twister pRNG algorithm505.

In a preferred embodiment, the RNG502Mersenne Twister pRNG algorithm505is seeded in real time503(e.g., once every minute) using the operating system Java SecureRandom504function to reseed the Mersenne Twister pRNG algorithm505periodically. The Java SecureRandom504function is preferred for this periodic reseeding process since it complies with the statistical random number generator tests specified in FIPS140-2(Federal Information Processing Standards of the US), Security Requirements for Cryptographic Modules, section 4.9.1. Optionally, a portion (e.g., milliseconds) of the actual Real Time Clock503can also be combined (e.g., Exclusive-OR or “X-OR”) with the Java SecureRandom504output to potentially introduce more entropy into the Mersenne Twister pRNG algorithm505reseeding process.

In an alternative embodiment, the RNG502Mersenne Twister pRNG algorithm505is reseeded periodically using the Java SecureRandom504output in synchronization with game video scene construction. With this alternative embodiment, whenever the construction of a specific scene begins or completes (e.g., phase three107draw results scene513is completed) the event sends a signal (507and507′) to the Java SecureRandom504function, causing it to reseed the Mersenne Twister pRNG algorithm505. This alternative embodiment has the advantage of possibly ensuring that each game is generated with the same Mersenne Twister pRNG algorithm505seed while also ensuring that all games have different Mersenne Twister pRNG algorithm505seeds.

In another alternative embodiment, the RNG502Mersenne Twister pRNG algorithm505is reseeded periodically with a Cryptographic Hash508(e.g., SHA-1) of the previous game video stream(s). Optionally, the previous game video stream(s) can be combined with a Real Time Clock time tag to produce a Cryptographic Hash508reseed that is a function of both time and the previous game video stream(s). In still another alternative embodiment, the Cryptographic Hash508output can be encrypted509with a secret key510with the resulting ciphertext used to reseed the Mersenne Twister pRNG algorithm505. This last alternative embodiment has the advantage that no one (even an insider to the Game Provider103system) could predict each reseed so long as the encryption key510remains unknown.

Thus, the Java SecureRandom504, Cryptographic Hash508, and Encryption509modules all function as different types of seed generators periodically supplying the preferred Mersenne Twister pRNG algorithm505with new starting seeds consequentially altering its deterministic output pattern whenever a new seed is generated. Of course, as is apparent to one skilled in the art, these various disclosed embodiments can be combined to create other embodiments not explicitly disclosed above. Also, a Linear Congruential Generator (LCG) pRNG algorithm could be utilized instead of the preferred Mersenne Twister pRNG algorithm505producing similar results, though typically with a much shorter period and less entropy. Additionally, a hardware True Random Number Generator (TRNG) could be used instead of or for reseeding the Mersenne Twister pRNG algorithm505with the advantage of a true source of informational entropy and the disadvantages of higher costs and increased complexity.

The Video Controller/Scheduler120described above is also interchangeably referred to herein as a “controller.” Various embodiments of the present invention use the BMS (game computer module, also, interchangeably referred to herein as a “game computer”) for performing respective functions discussed above. The controller and the game computer module are in electronic communication with each other to perform their respective functions.

It should be appreciated by those skilled in the art in view of this description that various modifications and variations may be made present invention without departing from the scope and spirit of the present invention. It is intended that the present invention include such modifications and variations as come within the scope of the appended claims.