U.S. Pat. No. 11,738,274

Corresponding reference numerals are used to refer to corresponding elements throughout the drawings.

DETAILED DESCRIPTION

FIG.1shows a highly schematic block diagram of a distributed computer system in which a multiplayer gaming experience is delivered. The computer system is shown to comprise a gameplay system100, a first player device102a, a second player device102b, and account provider system104and a remote game server (RGS or “Remote Game Server”)106. Two player devices are shown for simplicity, but the gameplay system100can serve any number of player devices, and two or more than two player devices may participate in a given multiplayer game session.

The gameplay system100is implemented at the hardware level as one or more computer devices, such as servers (e.g. one or more virtual servers running on one or more physical machines). The account provider system104and the game server106are “third-party” systems (from the perspective of the gameplay system100) that are operated and maintained independently of the gameplay system100. Accordingly, the account provider system104and/or the game server106may be disposed separately or remotely from the gameplay system100. The gameplay system100implements a “multiplayer wrapper”101that provides a multiplayer interface to a single player game hosted on the game server106. The wrapper101is shown to comprise a validation component110, a session instigation component112(also referred to herein as the Core), a game agent114and a streaming component116.

The functions performed by the various systems and components ofFIG.1are summarized below.

In the following examples, it is assumed the first player device102acauses a multiplayer game session to be instigated, which the second player device102bsubsequently joins. However, in other examples, the second player device102bmay be the device that causes the multiplayer game session to be instigated, which the first player device102asubsequently joins. The validation component110authenticates the player devices102a,102bwishing to establish or join the game session.

The validation component110receives a session instigation request from the first player device102a, and authenticates the first player device102awith the account provider system104in response. The first player device102ais authenticated against a first player account105aindicated in the session instigation request that is maintained by the account provider system104. The first player device102aprovides a game launch token that allows it to be authenticated against the correct player account105a. The game launch token gets sent to the gameplay system100from a portal of the account provider system104during the game launch procedure. This token is then sent to the first player account105afor validation and to obtain a more durable transaction token. In other examples, the

In response to successful authentication of the first player device102a, a multiplayer game session is instigated between (initially) the first player device102aand the gameplay system100.

Server-side, a new single-player game session is created between the gameplay system100and the RGS106, with the game agent114as the sole player. To establish the single player game session, the session instigation component112transmits a session account token to the gameplay server. The session account token is uniquely associated with a single shared session account115assigned to the multiplayer game session. From the perspective of the RGS106, this appears no different than a regular player account that would normally support a single player game. The RGS106validates the session account token against the shared session account115.

In the present example, the game is implemented as a web application delivered by the gameplay system106. Assuming the shared account token is valid, the RGS106returns a unique game resource identifier (such a URL or URI) for the single player game session to the shared session account115. At the gameplay system100, a new game client instance108is created for the multiplayer game session, and the game resource indicator is passed to the new game client instance108via the game agent114. Thereafter, the single player game is delivered to the game client instance108as in the same way as it would be delivered to a game client running on a player device in a conventional setup. Following these initial set up steps, communication between the gameplay system100and the RGS106occurs via the game client instance108.

Following the instigation of the multiplayer game session, the validation component110adds the second player device102bto the multiplayer session in response to a join request from the second player device102b. In the same manner as the first player device102a, the validation component110authenticates the second player device102bwith the account provider system104against a second player account105bindicated in the join request. Assuming successful authentication, the second player device102is added to the multiplayer game session. Note, this is invisible to the RGS106, and does not require any further interaction with the gameplay server106or the shared session account115at this point.

The validation component110is also responsible for validating game instructions received from each player device102a,102bwithin the multiplayer game session. A game instruction received from one of the player devices102a,102bis validated against the same player account105a,105bas used to authenticate that player device.

The game agent114is responsible for collating valid game instructions and instigating a game action within the single player game based on the valid game instructions it has collated.

For example, certain choices within the game might only be permitted when a player has sufficient game resources available to them. Such resources might, for example, include (virtual) items that the player has collected within a game or otherwise obtained, or resources required to, for example, obtain some item with a game or place a bet in the context of a betting game. The examples below consider a single player betting game (such as “slot betting”), in which a single player places a bet of a certain amount, with a win/lose outcome then determined at the RGS106. In such contexts, player accounts may be referred to as “wallets”. In this example, a game parameter provided to the game server106, as an input to the game client108, indicates the bet amount. As will be appreciated, this is merely one example use case. The system architecture described herein is highly flexible, and can support a range of games, game instructions and game actions. Robust validation of game instructions with the account provider system104is crucial in circumstances where game resources carry financial liability or have significant real-world value. However, the described system can be deployed in any circumstances where game instructions need to be validated against a player account.

In a conventional, single-player setup, a single player game session would be created between the game server106and a single player device. The single player device would be authenticated against a single player wallet held in the account provider system104. When a bet instruction is subsequently received from the single player device, this would be validated against the single player wallet and accepted if the player wallet has sufficient funds to cover the bet. Following a successful “win” outcome, the player account would be debited by the game server106with the player's winnings.

The described system mirrors this interaction flow as closely as possible. The difference is that the game agent114assumes the role of player, and the shared wallet115replaces the player wallet. Prior to game play, bets are received from each player device102a,102band validated against their respective player wallets105a,105b. Assuming each player has sufficient funds, their bet is temporarily transferred to the shared wallet115. The game agent114determines the total bet amount (one example of a shared game parameter) and, at a suitable point in time (e.g. upon expiration of a timer, or when bets have been received from all players), the game agent114places a bet for the total amount. Preferably a light-weight application programming interface (API)109is exposed by the game client108for this purpose. The total bet is relayed from the game client108to the game server106, which in turn validates the total bet against the shared wallet115(recall that, by this point, the required funds have been transferred from the player wallets105a,105bto the shared wallet115). If the outcome is successful, the winnings are transferred to the shared session account115, as a single total sum—it is the responsibility of the game play system110to divide these between the players in proportion to the respective bets, and transfer the correct proportions to the player wallets105a,105b.

Beyond slot games, more generally the gameplay system100can provide a multiplayer interface to any single player game (or, to put it another way, any “one-on-one” player-to-machine form of game mechanic). The RGS106does not know (and does not need to know) how to manage and adapt transactions within this game to a set of players, and continues to provide a one-on-one game modality.

Whilst slot games are considered by way of example, the same principles can be applied to any single player game in which multiple players share resources that are accumulated temporarily in the shared session account115.

The game client108generates a graphical user interface (GUI)111, as it would if it were running on a regular player device. However, the GUI is not rendered on a physical display. Instead, it is captured at the gameplay system100by the streaming component116, and transmitted to each player device102a,102bin a real-time video stream. This allows game visuals, such as a slot machine “animation”, to be communicated to the player devices102a,102bfor displaying thereat.

From a technical perspective, the gameplay system100provides a wrapper102of single play games such as traditional online slot games that allows players to share a common multiplayer game session. The game agent114transmits a shared game parameter (e.g. places a pooled bet) triggered by defined user instruction within the game and then streams the gameplay session to the participants and viewers.

From the perspective of the account provider system104, the gameplay system100functions as a multiplayer slot game, with an add on that allows bets to be pooled inside the shared wallet115. In the described implementations, funds never leave the account provider system104and are not held in the gameplay system100.

From the perspective of the RGS106, the gameplay system100sends through the collective actions or events of “change bet value to pooled value”, “spin” (the game action) and “read” (to determine the outcome) that are decided by the interactions of players with the game.

In the examples described below, the shared wallet115is maintained in the account provider system104, in essentially the same way as a player account.

In an alternative implementation, the shared wallet115is maintained in the gameplay system100. Even in this case, it is not necessary to move funds into the gameplay system100. The concept of a pooled sum is still used, but “actual” funds are not moved from the player wallets105a,105bto the shared wallet115. This assumes the single player game can be instigated in a “free play” mode that, in normal circumstances, would not include real funds at all. In the scenario where the gameplay system100holds the pooled wallet115, free play game can be used, taking advantage of the in-game calculations.

The shared or “pooled” wallet115aims to keep the protocol between the RGS106and the shared wallet115of players intact.

When the shared wallet115is held in the account provider system104, ahead of connecting an integration layer of the account provider system104with the gameplay system100, some number (n) of accounts are set up in the account provider system104with a balance of 0. These are not real player accounts, in the sense that they are not intended for use as regular player accounts. Instead, the accounts are used as generic game launch tokens that can be mapped back to the gameplay system100(the “pooled wallets”).

When a session is created and starts in the gameplay system100, a “start game session” command is sent to the account provider system104notifying it that a game session has started on the gameplay system100with a unique game identifier (GameId X). At this stage, no information is provided that this is a wrapper on a particular game content unit (ContentUnit A).

From the perspective of the game server106, the model of operation of the gameplay system100relies on the ability to control, through an automatic system, a third-party Game Client108.

Players will join a multiplayer session on the gameplay system100, opt in to participate per game round and place their bet. After all players have locked their stakes in, a spin on the game will be made (either through their actions, voting system or automatic decision).

A game client user interface (UI)111is launched on a server of the gameplay system100. The gameplay system100casts a video of this game through streaming technologies into client software, running on the player devices102a,102b. The spin needs to be performed at the game client108level—the UI with the provider game—as the game is streaming from that video. If bet actions were instead sent straight to the RGS106, the provider game client would not show any game animations.

A wallet transaction solution records each player's contribution per round, then places an automatic bet with the pooled value through the automatic system that controls the content provider game client. In implementations in which the shared wallet115sits in the licensee system104, the account provider system100provides the gameplay system100with a sufficiently large number (e.g. 1000+) game access tokens with their balances initially set to zero. This may reduce the risk that the tokens are compromised).

This method relies on the operator of the account provider system104setting up their system with some empty balance accounts and, on gameplay, to have the ability to increase the balance of these accounts per game round ahead of any bet placed. This is somewhat unusual for casino games but can be implemented in existing systems using bonus calls.

In other implementations, this dependency on the account provider system104is removed, further simplifying the integration process from the perspective of the operator of the account provider system104. In such implementations, the concept of accounts for the automatic system can be moved into the gameplay system100. Instead of creating accounts, the gameplay system100will be able to just generate launch tokens for the game with a conceptual balance of 0. The interaction between the RGS106and the shared wallet115is unchanged.

Returning to the creation of a multiplayer game session, in some implementations, when the gameplay system100instantiates a new multiplayer session it will launch a game instance with one or more configuration parameters. These may include one or more of pooled currency, landscape mode, language, bet limits (minBet/maxBet/maxWin/coin sizes).

After the game instance is launched, the system100may send may one or more commands to the game server106or game instance108. These may for example include mute/unmute/volume change commands. This may alter the volume of any sound effects associated with the game that are then subsequently streamed to the player devices102. In case the game has a pop-up display before starting, the system100may send a dismiss window command. This may for example prevent the pop-up display being streamed to the player devices102.

Subsequently, the gameplay system100will read the pooled wallet115balance through a read balance command.

Once players have joined the game and placed their bets, a change stake command and spin command are placed. The updated pooled wallet balance should have been sent through by this point.

The gameplay system100will wait for a “ready” event from game client108before sending an action through (spin/select bonus/change stake). This is needed in case the game client108has some animations that the gameplay system100needs to wait for before sending through further commands.

Game client108will send results of a spin to the gameplay system100. This may occur before the eventual win animation is ready, for example by receipt of a separate message at the game agent114. The game client108may also send an updated pooled wallet115balance in the case of a loss as well as a win.

In case of bonus rounds, the system100should have the ability to read and select multi options.

On bet placement, the credit pooled amount and debit pooled amount commands can be placed either at the end of the timer as a total amount, or incremental, after every successful real bet. To reduce traffic and potential reconciliation scenarios, the former may be chosen. This may be an example of the system100receiving a plurality of game instructions from the first and/or second player devices102, and accumulating or collating the game instructions before transmitting the shared parameter.

In one example, a secure token is needed to launch the game client108. With the secure token, the RGS106knows to authenticate that the game is launched in the context of a wallet105of the account provider system104(or in the context of a pooled wallet115).

FIG.2Aillustrates a series of operations associated with the gameplay system100described herein. Particularly,FIG.2Aillustrates the process of establishing a multiplayer game session using a first player device102a.

Initially, first player device102a, which is operated by player P1, initiates a new session with the gameplay system100in step S2001. This may comprise generating a session instigation request which is transmitted to the gameplay system100. The first player device102amay comprise front end software or access a front end provided by the system100. The system100, for example validation component110, authenticates the first player device102aagainst the account provider system104in step S2002.

Assuming the authentication is successful, in step S2003the system100obtains a game launch token from a shared session account115. In step S2004, the system100launches a first game, Game A, on the game server A106, using the game launch token. In step S2005, the game server106authenticates the game launch token against the shared session account115. In response to successful authentication, the game server106provides the system100with a unique game resource identifier such as a URL or URI in step S2006. One or more of steps S2003,2004and S2006be carried out by the session instigation component112.

In step S2007, the game client108A is launched using the game resource identifier.FIG.2Aillustrates that the system100may comprise a plurality of game clients108A,108B connected to a game server106. In Step S2008, Game A is streamed to the first player device102a.

FIG.2Billustrates another series of operations associated with the gameplay system100described herein.

In a step S2101, a second player device102b, which may be operated by a second player P2joins an existing session previously initiated by the first player device102a. This may comprise generating a session join request which is transmitted to the gameplay system100. Subsequently, in step S2102, the second player device102bis authenticated against the account provider system104. Subsequently, in step S2103, Game A is streamed to the second player device102b. Notably, no interaction with the game server106or the shared session account115is required to add the second player device102binto the existing session.

FIG.2Cillustrates another series of operations associated with the gameplay system100described herein.

In a step S2201, the system100receives a first game instruction from the first player device102a. For example, the first game instruction may be an instruction to place a bet having a value, such as 4 EUR. In step S2202, the system100(e.g. validation component110) validates the game instruction, for example by checking sufficient funds are available in the account105aof first player102a. This may involve sending a validation message to the account provider system104, and receiving a validation response indicating that the instruction is valid. This may also cause the account105ato be updated, for example based on the value of the bet.

In a step S2203, the system100receives a second game instruction from the second player device102b. For example, the second game instruction may be an instruction to place a bet having a value, such as 6 EUR. In step S2204, the system100(e.g. validation component110) validates the game instruction, for example by checking sufficient funds are available in the account105aof first player102a. This may involve sending a validation message to the account provider system104, and receiving a validation response indicating that the instruction is valid. This may also cause the account105bto be update, for example based on the value of the bet.

Subsequently, in step S2205, a shared game parameter is determined, for example by summing the two values of the game instructions placed by the two players102. In this example, the shared game parameter may be 10 EUR. This shared game parameter is used to increment the shared session account115. In step S2206, the shared game parameter is transmitted to the game server106. For example, a bet corresponding to the pooled value of 10 EUR is placed.

Subsequently, the game server106then updates the shared session account, for example by debiting it to place the bet in step S2207. If the outcome of the bet (i.e. the game result) is a win, the game server106may further update the shared session account to reflect the win in a step S2208.

In step S2209, the game server106may send an event to the game client104, indicating the game result. In the example, the event reflects that the result is a win, and includes the value of the win.

In response, the system100may calculate the winnings associated with each player device102. This may for example involve dividing the winnings based on the proportion of the shared game parameter contributed by each player. In steps S2210and S2211update the player accounts in the account provider system104.

Furthermore, in step S2212the game result is communicated to the player devices102, for example by streaming the game.

FIG.3A-3Cshow similar operations to those discussed in relation toFIG.2A-2C, in more detail. Corresponding steps have labels corresponding to those shown inFIG.2A-C, incremented by 1000. Accordingly, only the differences will be discussed in detail.

FIG.3Aincludes a step S3001of the first player device102alogging into the account provider system104(for example a lobby thereof), navigating to a view showing a plurality of multiplayer game sessions, and launching the multiplayer session therefrom. This is another example of front end functionality that may generate a session instigation request. Similarly,FIG.3Bincludes step S3101in which a second player device102blogs into the account provider system and joins the multiplayer session therefrom. This is another example of front end functionality that may generate a session join request.

FIG.3Cillustrates in more detail some of the actions that may be taken by the game client108. Furthermore,FIG.3Cincludes a step3201aof initiating a timer for the receipt of game instructions from connected player devices102. When the timer expires (53201b), no further game instructions may be received for inclusion in the shared game parameter.FIG.3Cfurthermore illustrates the receipt of validation responses subsequent to each validation message (S3202and S3204). In addition,FIG.3Calso includes a step S3209aof removing the winnings from the shared session account before updating the plater accounts in the account provider system104.

FIG.4shows a more detailed architecture diagram of the system100. The components shown inFIG.4are summarized in Table 1.

TABLE 1Architectural components.ComponentDescriptionFrontend GameMobile and Desktop interface for playing Shared Play by players P. ThePlay UI 117system 100 may include a gameplay API gateway 117aBE Core 118Main component managing games, rounds, shared bets/wins. This mayinclude a transaction database 118aBE Audit 119Reports for operators and finance departmentBE Game AgentManaging game client instance of provider’s game. FIG. 4 illustrates that114the system 100 may include a plurality of game clients 108a, 108b, 108xplayed by the game agent 114. FIG. 4 also illustrates that the a pluralityof game clients 108a, 108b may be provided by a single game server106a.Streaming 116Video streamingWallet Adapter 120Integration layer with operators. This may form part of validationcomponent 110 described above. FIG. 4 illustrates that the system 100may interface with a plurality of account provider systems 104a, 104bBackoffice 121Back office system, accounts management, replays, rounds history,accessible by administrator users A, for example via a backoffice API121a using a front end 121b.Players 122Service that deals only with player P information, logging, profiles,actions, avatars, followersMessages 123Handles chat messages between players P

FIG.5Ais a component diagram which illustrates that shared session accounts115a,bcan form part of respective account provider systems104a,104b.FIG.5Aalso illustrates there need not be a 1-to-1 relationship between account providers104and game servers106. For example, game server106amay access accounts115aand115bon different account provider systems104a,b.

FIG.5Bis a component diagram which illustrates an example in which the shared session account115forms part of the gameplay system100. In this example, the gameplay system100may comprise an adaptor124configured to update the shared session account based on data received from the game servers106. In some examples, the data is received from an aggregator125, which

Returning now toFIG.1, streaming of the game will now be discussed in more detail. For every game running, there is an associated Agent instance114that runs within the gameplay system100, whose functions include: running the game itself; allowing a backend Core118to externally control the game; capturing and streaming the game to the players; and receiving money updates from the game.

Agents may be spawned per game as separate processes, for example on a server machine. During their initialization, a browser instance (the game client108in this implementation) is spawned. The browser is caused to load a GameWrapper, which is a web page with an iframe and a JS bundle. Then, a page with the target game is loaded into the iframe.

Each new GameWrapper instance may connect and report itself back to a websocket server in the Core118, so that it can be centrally managed further on. Any communication between these two services takes place via websocket events, including a stream initialization protocol for every ‘viewer’ (player receiving the video stream), as well as the exchange of game events.

Streaming is described in more detail below.

A game may be implemented as a content unit. The system100can run a game as any kind of a website/web app that it is possible to run and render in a browser and, preferably, exposes controls via some kind of a standardized window.postMessage API (or, less preferably, via emulating user input if such as API is not available).

It is possible to pass different game configurations to the game agent114as needed to support different types of game.

Calls to the game agent114may be wrapped in some kind of translation library to support multiple kinds of event APIs and select the proper event API based on what game is being run.

Games can both accept events and generate them—the former is allowed as a way to control the game—e.g to set the bet value, spin a machine etc. while the latter is a way for the system100to receive information about the state of the game—e.g. the value of the spin result.

Both directions of event flows are accomplished with a combination of iframe's window.postMessages and websocket events.

To execute a control event upon the game, a websocket event is sent to the appropriate Agent114websocket client for a specific game. The event is parsed on the Agent114side, and an appropriate window.postMessage is executed.

Whenever a significant event is generated in the game, the game generates a window.postMessage event that the system100catches with a callback. That event is parsed and an appropriate websocket event back is passed back to the Core118.

A live game may be streamed as video to the players P and viewers in real time. To achieve this, for every new game, the Core118spawns a separate Game Agent114instance (this could be a separate process running on a single same machine, or a new machine might be created for a cluster of games). To make screen captures possible while running on server side, the browser is run in a virtual frame buffer, with a screen capture plugin (such as Puppeteer). During its initialization, system100opens a browser session with Puppeteer, then makes it load a special webpage called GameWrapper which contains an iframe. The target game is loaded into the iframe, and the Core118takes over the control of the game.

A streaming server is set up, and a screen capture is initialized in the browser of the whole window. The GameWrapper connects to the Core118websocket server, relaying connection requests to the appropriate GameWrapper websocket client instance. References for both the connection and the stream are stored so that they can be reused when handling every new incoming request to receive a stream. After everything is up and running, the Game Agent acknowledges the Core that it's ready to be used.

Then, whenever a new client connects, a new webRTC connection is established between the GameWrapper code instance and the player's browser (running a UserInterface). Details of the protocol may be found at the following URL, the content of which are incorporated herein by reference: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#signaling_transaction_flow.

WebRTC (Web Real-Time Communication) allows audio and video communication to work inside web pages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps.

WebRTC is one of the most commonly used protocols for streaming media. It was selected for streaming the view of the game to the players due to its sub-second latency, allowing players to interact with the game in real time. Due to its introduced delay, an RTMP stream is noticeably slower, thus less preferable solution in this use case.

In one example, the gameplay system100described herein further includes a selectable bet sizing algorithm, which aims at matching total player pooled bet to the highest possible fixed game provider's bet size.

The system's multiplayer interface provides a selection of bet increments calculated based on the minimum individual bet that the game is able to accept all the way to the maximum individual bet that is allowed per multiplayer room. The latter is calculated based on either the maximum pooled bet or based on the maximum exposure set by the operator. Maximum exposure divided by the theoretical win configured by the game provider for any particular game instance and the total number of seats in the room results in the maximum pooled bet. Depending on which value is provided by the operator (the maximum exposure or the maximum pooled bet), the system100limits the bet increment selection in the interface to avoid the casino operator being exposed to winning payouts above the configured values in case a win takes place.

To be able to run the algorithm, the system100must know the bet increments that the game is able to accept and process during the game round in order to reach the game round result. This array of increments is communicated by the game provider and is set in the system100on game configuration.

Upon the players choosing their individual bets from the bet selection provided by the multiplayer interface, the system100validates each individual bet against that player's wallet. Upon the successful validation, the system100calculates the total pooled bet from all committed players for the particular game round. The pooled value is then compared to the closest maximum increment from the array configured on the game.

If a difference between the total pooled bet and the closest maximum bet increment supported by the game is detected, it is a subject for return to the players. To do so, the algorithm keeps track of the proportions of each individual bet with respect to the total pooled amount in its system and applies them when calculating the individual returns to players. As a rule, the players with lower bets get lower returns, and the players with the higher bets—get higher returns, which all are driven by the proportions stored on in the system for the period of the game cycle.

The system performs the validation of each individual bet and the calculations of accepted and returned amounts prior to submitting the group bet into the game (e.g. before sending it to the game server, as discussed in relation to step S2206ofFIG.2Cabove). The players get communications in the interface of the original amount they committed to, the accepted bet, and the returned amount that is put back into their respective balances.

The game round is initiated only after all checks have been performed and the players are charged the validated bet amounts. Upon the game returning a spin result, the system100proceeds with the algorithm of splitting the result between all committed and validated players, for example as discussed in relation for steps S2210and S2211above.

Accordingly, the methods described herein may comprise selecting parameters of the first game instruction and/or second game instruction from a predetermined list of values. The methods may also comprise validating the shared game parameter before transmission to the game server. If a value of the shared game parameter exceeds a predetermined threshold value (e.g. the maximum bet increment), the predetermined threshold value may be used as the shared game parameter. The difference between the predetermined threshold value and the shared game parameter may then be returned to the wallets of the player devices.

It will be appreciated that the examples described above are illustrative rather than exhaustive. A player device can take various forms, including a mobile device, personal computer, wearable device etc. Code, software and the like may be embodied as program instructions stored in memory and executed on one or more computer processors (e.g. CPUs). A computer system comprises computing hardware which may be configured to execute any of the steps or functions taught herein. The term computing hardware encompasses any form/combination of hardware configured to execute steps or functions taught herein. Such computing hardware may comprise one or more processors, which may be programmable or non-programmable, or a combination of programmable and non-programmable hardware may be used. Examples of suitable programmable processors include general purpose processors based on an instruction set architecture, such as CPUs, GPUs/accelerator processors etc. Such general-purpose processors typically execute computer readable instructions held in memory coupled to the processor and carry out the relevant steps in accordance with those instructions. Other forms of programmable processors include field programmable gate arrays (FPGAs) having a circuit configuration programmable through circuit description code. Examples of non-programmable processors include application specific integrated circuits (ASICs). Code, instructions etc. may be stored as appropriate on transitory or non-transitory media (examples of the latter including solid state, magnetic and optical storage device(s) and the like).