Related Applications

[001] This application claims priority from Australian provisional patent application no. 2021902229 filed on 20 July 2021, the contents of which are incorporated by reference.

Technical Field

[002] The invention relates to a method and a system for multi-user emulated transactions. In particular, the invention relates to a method and a system for multi-user transactions in which users may emulate the transactions of other users, and to a method and a system to efficiency process such multi-user transactions.

Background

[003] Transactions occur in a wide range of industries including finance, banking, retail and gambling. Such transactions may occur between any two or more parties such as human users, entities or machines, and may range from simple transactions right through to complex transactions including multiple transactions.

[004] One such example of a transaction may occur during online betting or gambling platforms that enables a user to place bets on an event, such as a sporting event. The transaction data associated with the user, such as the betting market (i.e the event in relation to which the bet was placed, such as a horse race), stakes, odds and winnings are typically maintained proprietary and associated with the user account.

[005] Similar proprietary information surrounding user or system data is also common in other platform-based environments, in particular, transactional based systems such as those in banking, financial services and commerce, in which data relating to user or system transactions is not shared with or available for use by other users or systems. [006] In some transactional environments it may be desirable for a subsequent transaction to be based on a prior transaction so that the subsequent transaction may follow or “emulate” the prior transaction. In the context of gambling this may be referred to as a “shadow bet” in which a subsequent user may make a betting transaction based on the betting transaction of the prior user. This presents a data or information control problem in relation to how the prior transaction data and subsequent transaction data are shared between the users.

[007] WO2009128847A1 discloses a method and apparatus of authorising and managing wagering agent accounts that includes a content controller configured to present the wagering game information having an option for a first player account to shadow bet on a second player account, and includes a control setting to make the shadow bet invisible to the second player account. The wagering agency module is configured to place a shadow bet by performing any one or more of emulating betting by the second player account, betting a fraction of wagers placed by the second player account, betting on trends of games played by the second player account over, and betting that theoretical holds are exceeded or closed in on over a time period by the second player account.

[008] A problem with such a method and apparatus of authorising and managing wagering agent accounts relates to data or proprietary information sharing, in particular, between the second player account and the first player account who is making the bet and the account information control and privacy of the second user.

[009] A further problem relates to such a method and apparatus being suitable to perform and efficiently process more complex and computationally demanding transactions such as in situations where the wager transactions placed by the second player account are complex and include multiple wager transactions.

[0010] The invention disclosed herein seeks to overcome one or more of the above identified problems or at least provide a useful alternative. Summary

[0011] In accordance with a first aspect there is provided, a method for multi-user transactions in which a second user initiates a second transaction to emulate a first transaction of a first user, the method including the steps of: Receiving a first transaction input associated with a first user to initiate the first transaction based on at least one transactable feature; Creating first transaction data representing the first transaction; Processing the first transaction data to generate first emulation data including first sharable data and associated first hidden data not available to the second user; Making available the first sharable data to the second user, the first sharable data including a first transaction representation; Receiving a second transaction input associated with the second user based on the first sharable data to initiate the second transaction in accordance with the first emulation data such that the second transaction emulates at least in part the first transaction whilst the hidden data remains not available to the second user; and Creating second transaction data representing the second transaction.

[0012] In an aspect, the step of creating the second transaction data representing the second transaction includes generating transaction chain representation data to include a core representation of the first transaction and the second transaction so as to enable a third transaction to emulate the second transaction and first transaction based on the transaction chain representation data associated with the second transaction data.

[0013] In yet another aspect, the at least one transactable feature is a prior transaction, and wherein the first emulation data includes first transaction chain representation data including a first core representation of the prior transaction.

[0014] In yet another aspect, the first hidden data of the first emulation data includes the first transaction chain representation data including the first core representation of the prior transaction.

[0015] In yet another aspect, the step of creating the second transaction data representing the second transaction includes generating second transaction chain representation data to include a second core representation of the prior transaction, the first transaction and the second transaction so as to enable the third transaction to emulate the second transaction, the first transaction and the prior transaction based on the second transaction chain representation data associated with the second transaction data.

[0016] In yet another aspect, the first and second core representations each include at least one transactable feature and one or more associated transaction metrics.

[0017] In yet another aspect, the step of creating the second core representation of the prior transaction, the first transaction and the second transaction includes determining a consolidated array including a single record of the least one transactable feature and one or more associated transaction metrics.

[0018] In yet another example, the transaction chain representation data may be or includes market composition data.

[0019] In yet another aspect, the first transaction representation includes a visual representation or indicator of the first transaction to represent the first transaction to the second user.

[0020] In yet another aspect, the first transaction representation includes one or more of a graphical element or alpha numerical element.

[0021] In yet another aspect, the first transaction representation includes a first code to provide a visual representation of the first transaction including at least one alpha- numerical element.

[0022] In yet another aspect, the first hidden data includes data to identify the at least one transactable feature.

[0023] In yet another aspect, the at least one transactable feature includes one or more of an event, a good or a service on which the first transaction is based.

[0024] In yet another aspect, the at least one transactable feature includes a prior transaction.

[0025] In yet another aspect, the prior transaction includes one or more still prior transactions. [0026] In yet another aspect, wherein the step of processing the first transaction data to generate first emulation data includes: Processing the first transaction data to identify duplicate ones of the at least one transactable feature and determining the first emulation data to include first composite transaction data representative of a composition of the duplicate ones of the at least one transactable feature.

[0027] In yet another aspect, the first transaction includes a plurality of the transactable features, and wherein the step of processing the first transaction to generate first emulation data includes:_Determining the first emulation data to include first composite transaction data representative of a composite of the plurality of the transactable features.

[0028] In yet another aspect, the first transaction representation of the first sharable data includes a first transaction representation to the second user.

[0029] In yet another aspect, the step of initiating the first transaction based on at least one transactable feature includes: Determining if the at least one transactable feature includes one or more prior transactions; and Executing one or more further prior transactions upon executing the first transaction.

[0030] In yet another aspect, the method further includes the steps of: Processing the second transaction to generate second emulation data including second sharable data and second hidden data; Making available the second sharable data to a third user, the second sharable data includes a second transaction representation; Receive a third transaction input associated with the third user based on the second sharable data and initiate the third transaction in accordance with the second emulation data such that the third transaction emulates at least in part the second transaction whilst the second hidden data remains not available to the third user; and Create third transaction data representing the third transaction.

[0031] In yet another aspect, the second transaction representation is a visual representation or indicator of the second transaction.

[0032] In yet another aspect, the second transaction representation includes a second code to represent the second transaction to the second user. [0033] In yet another aspect, the method is configured to enable the display of a transaction representation including the first sharable data and the second sharable data each including respective first and second transaction representations.

[0034] In yet another aspect, the third user is able to initiate the third transaction based on both of the first sharable data and second sharable data such that the third transactions emulate both of the first and second transactions.

[0035] In accordance with a second aspect there is provided, a system for multi-user transactions in which a second user initiates a second transaction to emulate a first transaction of a first user, the system being configurable by software to: Receive a first transaction input associated with a first user to initiate a first transaction based on at least one transactable feature; Create first transaction data representing the first transaction; Process the first transaction to generate first emulation data including first sharable data and first hidden data not available to the second user; Make available the first sharable data to a second user, the first sharable data includes a first transaction representation; Receive a second transaction input associated with the second user based on the first sharable data and initiate the second transaction in accordance with the first emulation data such that the second transaction emulates at least in part the first transaction whilst the hidden data remains not available to the second user; and Creating second transaction data representing the second transaction.

[0036] In accordance with a third aspect there is provided, a method of creating a composition data structure for multi-user transactions to enable a later user to emulate a prior transaction of a prior user in which the prior transaction includes prior transaction data representing a plurality of prior transactions across a plurality of markets; creating a composition data structure associated with the prior transaction data; processing the prior transaction data to at least identify each of the plurality of markets and add non-duplicate ones of the plurality of markets to the composition data structure; storing the composition data structure such that the later user is able to select a sharable data element associated with the composition data structure to enable the later user to emulate the prior transaction whilst one or more hidden data elements associated with the composition data structure are concealed from the later user. [0037] In accordance with a fourth aspect there is provided, a method for multi-user transactions in which a second user initiates a second transaction to emulate a first transaction of a first user, the method including the steps of: Receiving a second transaction input associated with the second user to initiate the second transaction based on first emulation data associated with the first transaction; Extracting, from the first emulation data, transaction chain representation data including a core representation of the first transaction; Processing the second transaction based on the core representation of the first transaction and the second transaction input; Creating second emulation data representing the second transaction including generating the transaction chain representation data to include a further core representation of the second transaction so as to enable a third transaction to emulate the first and second transactions based on the transaction chain representation data associated by the second emulation data.

[0038] In an aspect, the first emulation data includes first sharable data including a first transaction representation and first hidden data including the transaction chain representation data.

[0039] In another aspect, the second emulation data includes second sharable data including a second transaction representation and second hidden data including the updated transaction chain representation data.

[0040] In yet another aspect, the core and further core representations of the transaction chain representation include at least one of an alpha numerical string and code.

[0041] In accordance with a fifth aspect there is provided, a method for multi-user transactions in which a user initiates a transaction to emulate one or more prior transactions associated with one or more other users to at least partly emulate one or more prior transactions, the method including the steps of: Receiving a transaction input associated with the first user to initiate the transaction based on emulation data associated one or more prior transactions, the emulation data including shareable data having at least one transaction representation viewable by the user and associated hidden data not viewable by the user including transaction chain representation data including a core representation of the one or more prior transactions; Extracting, from the emulation data, the transaction chain representation data including a core representation of the one or more prior transactions; Processing the transaction based on the core representation of the one or more prior transactions and the transaction input; Generating further emulation data representing the transaction including generating further transaction chain representation data to include a further core representation of the transaction so as to enable a further transaction to emulate the transaction and the one or more prior transactions based on the further transaction chain representation data associated with the further emulation data.

[0042] In an aspect, generating the further transaction chain representation data to include the further core representation of the transaction includes: processing the core representation of the one or more prior transactions to determine a prior set of transactable features and associated prior metrics; processing the transaction to determine present transactable features and present associated metrics; generating the further core representation to include a consolidated record of the prior set of transactable features and the present transactable features, and associated prior and present associated metrics.

[0043] In another aspect, the consolidation includes determining duplicate records of the prior set of transactable features and present transactable features, and creating a single record of transactable features having determined composite metrics based on the associated prior and present associated metrics.

[0044] In yet another aspect, the transaction chain representation data is provided in the form an array associated with the transaction representation, and wherein the transaction representation is a string viewable by the user to represent the one or more prior transactions to the user.

[0045] In accordance with a sixth aspect there is provided, a method for the emulation of one or more prior transactions, the method including the steps of: Initiating a transaction based at least in part on emulation data associated with the one or more prior transactions; Extracting, from the emulation data, the transaction chain representation data including a core representation of the one or more prior transactions; Processing the transaction based on the core representation of the one or more prior transactions and the transaction input; Generating further emulation data representing the transaction including generating further transaction chain representation data to include a further core representation of the transaction so as to enable a further transaction to emulate the transaction and the one or more prior transactions based on the transaction chain representation data associated with the further emulation data.

[0046] In an aspect, the emulation data includes sharable data including a transaction representation and hidden data including the transaction chain representation data hidden from a user initiating the transaction.

[0047] In yet another aspect, the transaction chain representation data is provided in the form an array associated with the transaction representation, and wherein the transaction representation is a string viewable by the user to represent the one or more prior transactions to the user.

[0048] In yet another aspect, the core representation includes one or more transactable features and one or more associated metrics, and wherein generating the further core representation of the transaction includes determining duplicate ones of the one or more transactable features between the transaction and the one or more prior transaction and determining a consolidated array including a single record of the one or more transactable features and associated consolidated one or more metrics.

[0049] In yet another aspect, generating the further transaction chain representation data to include the further core representation of the transaction includes: processing the core representation of the one or more prior transactions to determine a prior set of transactable features and associated prior metrics; processing the transaction to determine present transactable features and present associated metrics; generating the further core representation to include a consolidated record of the prior set of transactable features and the present transactable features, and associated prior and present associated metrics.

[0050] In yet another aspect, generating the further transaction chain representation data to include the further core representation of the transaction includes: Processing the emulation data and the transaction to identify duplicate ones of one or more transactable features, and generating the further core representation including a single record of each of the one or more transactable features with an associated composite of transaction metrics associated with each single record. [0051] In yet another aspect, the core representation includes one or more transactable features and associated transaction metrics.

[0052] In accordance with a seventh aspect there is provided, a computer system for the emulation of one or more prior transactions, the computer system being configurable by software to: Initiate a transaction based at least in part on emulation data associated with the one or more prior transactions; Extract, from the emulation data, transaction chain representation data including a core representation of the one or more prior transactions; Process the transaction based on the core representation of the one or more prior transactions and a transaction input; Generating further emulation data representing the transaction including generating further transaction chain representation data to include a further core representation of the transaction so as to enable a further transaction to emulate the transaction and the one or more prior transactions based on the transaction chain representation data associated with the further emulation data.

[0053] In accordance with an eighth aspect there is provided, a computer readable medium configured to operate the methods and system disclosed above and herein.

Brief Description of the Figures

[0054] The invention is described, by way of non-limiting example only, by reference to the accompanying figures, in which;

[0055] Figure l is a block diagram illustrating an example of the system;

[0056] Figure 2 is a graphic representation illustrating an example transaction in which a second or further user emulates a transaction of a first or prior user in which at least some of the transaction data is hidden or not available to the second or further user;

[0057] Figure 3 is a flow chart illustrating a first example method for multi-user transactions in which a second user initiates a second transaction to emulate a first transaction of a first user; [0058] Figure 4 is a screen capture illustrating a first transaction of a first user, being a $100 bet on the Storm to win;

[0059] Figure 5 is a screen capture illustrating a first user creating first emulation data based on a first transaction;

[0060] Figure 6A is a flow chart illustrating a method of determining market composition data associated with a prior transaction;

[0061] Figure 6B is a flow chart illustrating in more detail the method of determining market composition data associated with a simple transaction, with no embedded prior transactions;

[0062] Figure 7 is a screen capture illustrating shared data of emulation data to enable a further user to emulate a transaction of a previous user;

[0063] Figure 8 is a screen capture of illustrating a further user initiating a further transaction based on a prior transaction of a prior user;

[0064] Figure 9 is a flow chart illustrating a subroutine that executes a transaction that emulates a prior transaction;

[0065] Figure 10 is a screen shot illustrating an administration view of the system;

[0066] Figure 11 is a flow chart illustrating a generalised method for executing an emulated transaction;

[0067] Figure 12 is a graphic representation illustrating a furthermore complex example transaction between multiple users;

[0068] Figure 13 is a screen capture illustrating a transaction by a user;

[0069] Figure 14 is a screen capture illustrating a further transaction by the user including a prior transaction of a prior user; [0070] Figure 15 is a screen capture illustrating the deployment of emulation data including the transaction and the further transaction by the user including the prior transaction of the prior user;

[0071] Figure 16 is an example of shareable data of the emulation data providing a descriptive transaction representation;

[0072] Figure 17 is a flow chart illustrating in more detail the method of determining composition data associated with a more complex transaction including multiple embedded transactions;

[0073] Figure 18 is a screen shot illustrating shared data of emulated data associated with a plurality of users;

[0074] Figure 19 is a screen shot illustrating a transaction based on a prior transaction of a prior user;

[0075] Figure 20 is a flow chart illustrating a method of emulating a prior transaction that includes multiple transactable features, in this case markets, within the transaction;

[0076] Figure 21 is a screen capture illustrating hidden data associated with emulation data on which a further transaction is based;

[0077] Figure 22 is an explanatory block diagram illustrating a multi-user and multi transaction execution showing software function calls through a chain of transactions;

[0078] Figure 23 is an explanatory block diagram illustrating multi-user and multi transaction execution in which transaction chain representation data associated with each set of emulated data allows a single software function call to execute all of the chain of transactions shown in Figure 22; and

[0079] Figure 24 is a flow chart illustrating a method for multi-user transactions in which a user initiates a transaction to emulate one or more prior transactions that include the transaction chain representation data. Detailed Description

[0080] Referring to Figure 1 there is disclosed a system 10 for facilitating multiuser transactions between a plurality of users. The system 10 may include a server system 12 including one or more of a Webserver 12a, an application server 12b and database server 12c. The server system 12 may interface or be in communication with a plurality of user devices 14, that may include mobile phones 14a and other computer devices 14b as well as informational sources 15, over the Internet 16, or other suitable network. An administrator system or interface 13 may also be utilised.

[0081] The information sources 15 may be other online data sources or other servers or the like that provide information such as, but not limited to, live market data regarding sporting or other related events on which a transaction such as a bet may be placed. The application server 12b may include one or more processors 18 and memory 20 configured to execute software and perform the various actions and routines as described herein. The database server 12c may include a database 22 in which user data and transactional data may be stored and retrieved. The system 10 thereby providing a platform that is accessible and operative by the plurality of users. It is noted that the system 10 may take various forms and configurations, and is not limited to the example form disclosed herein.

[0082] In the example methods disclosed herein the system 10 may be utilised to facilitate multi-user transactions between a plurality of users in some of the plurality of users are able to emulate transactions of others of the plurality of users whilst some or all of the details of the transactions remain selectively hidden. In the examples provided herein the multi-user transactions may involve a market having one or more transactable features one which a transaction may be based such as an object, outcome, entity, event, race game or the like. In the context of betting, the transactable feature being an event, game, or a race on which a bet is placed.

[0083] However, such a system and methods may find use in any transactional environment, including financial transactions, auctions or other commerce, in which a second user may wish to emulate a transaction or set of transactions of the first or prior user, where some or all of the transactional information of the first user may be hidden from the second user. For example, a financial trader may wish to emulate the transaction of another financial trader and the latter wishes to maintain proprietary rights over the nature of their trades.

[0084] This is achieved by selectively creating and determining emulation data including shareable data and hidden data associated with the transaction information that allows the second user to select and execute an emulated transaction, based at least in part on the shared data but maintaining hidden data that only the first user may view unless the first user choses to also share this data. The hidden data keeps proprietary information hidden and keeps information such as specific details of transactable features (e.g. the selected horse in a horse race) hidden from the second user who is emulating the transaction of the first user. This allows a user sharing emulated data to keep some information proprietary which is valuable to the user.

[0085] In some examples, as further detailed below, each transaction that occurs creates emulation data for the transaction that includes transaction chain representation data. The transaction chain representation data is a summary or core representation of the transaction and any prior transactions on which the transaction is based. A consolidated array of transaction chain representation data is created and associated with each emulatable transaction. The array of transaction chain representation data includes a composite of embedded transactions including a consolidated array of transactable features with associated composite metrics that take into account the chain of prior transactions that relates to each of the transactable features. A specific example of the transaction chain representation data is betting market composition data further detailed below.

[0086] Accordingly, each set of emulation data of each transaction carries with it a core representation of prior and related transactions that allows an entire chain of transactions to be carried out based on the transaction chain representation data - without the system 10 needing to call data from the chain of original transactions so represented. This provides a substantial saving is computation resources. [0087] As such, when a further transaction is based on the emulation data, the transaction chain representation data may be added to the transaction chain representation data of the further transaction. Thereby each new transaction and its associated emulation data carries an updated transaction chain representation data with core information to enable a chain of prior and embedded transactions to be followed and executed based on this core information, without needing to refer to or call any data from the emulated chain of prior and embedded transactions themselves. An explanatory example of such an implementation is provided below with reference to Figure 22 to 24.

[0088] In the example of a betting transaction, as further detailed below, this allows a first user to share emulation data in the form of a tip for a first transaction or first bet of the first user with the second user and the second user may view shared data of the emulation data associated with the tip which may include, for example, an identifier, creator, tip descriptor with odds etc. and the second user may execute a second transaction to emulate this tip and the emulated data may facilitate a second transaction based on the shared data and hidden data of the first transaction which allows the second user to emulate the transaction of the first user without all of the transaction information being shared.

[0089] In particular, the transaction or bet information of the first user may have data the first user may wish to not share such as the specific transaction feature such as an event or sport which allows the first user to maintain confidentiality around aspects of the transaction. For example, if a bet involved horse racing, the first user could keep the details of the specific horses bet upon hidden and thereby maintain some proprietary rights around their know-how and selections. The first user is then able to derive a value, that may be a financial return, when the second user initiates the second transaction based on the first transaction of the first user without revealing the first user’s proprietary rights.

[0090] The above-described system and methods detailed below may find use in circumstance in which it may be beneficial for a user to disclose their transaction data to other users. For example, a professional gambler may agree - for a certain fee or other benefit - to share with another gambler the details of a bet they have placed, to allow that other gambler to place the same bet. However, such a disclosure causes the original transactor to no longer be the sole owner of that information - it has been shared with others who may then share it further. There is currently no known practical and verifiable mechanism that would allow the original transactor to maintain the proprietary rights to their transaction details, while also allowing other transactors to emulate and extract benefit themselves from that information.

First Example - Simple Transaction

[0091] Referring to Figures 2 and 3, there is disclosed a first example method 100 for multi-user transactions in which a second user 102 initiates a second transaction to emulate a first transaction of a first user 101. As shown in Figure 2, the first user 101 may have made a first transaction in relation to a transactable feature 103 such as making a bet on a sporting event. The first user 101 may then chose to share emulation data in some form with a second user, or other users, that enables the second user to emulate at least in part the first transaction.

[0092] The emulation data is determined by the system 10 and includes shared data that provides the second user with a representation of the first transaction and hidden data or unsharred data that remains only known to the first user, which may include, for example, the specific transactable feature 103 such as the horse being backed in a race, may be hidden from the first user 101.

[0093] Turning to the operation of the system 10 in more detail, and referring to Figure 3, a method 100 for multi-user transactions in which the second or follower user initiates the second transaction to emulate the first transaction of the first or prior user, may include, at step 110 the system 10 being configured to receive a first transactable feature input by the first user and generate the first transaction data based on the first transactable feature input by the first user.

[0094] The first transactable feature input by the first user may include a bet or a wager placed on an event or multiple events. The first transaction data may be stored as a data record on the database. The first transaction data may include a user identifier, a transaction identifier and first transaction information relating to the type and nature of the transaction such as, but not limited to, a Bet ID, a Market ID, odds and a stake.

[0095] At method step 112, the system 10 may be configured to generate emulation data based on the first transaction data. The first emulation data may include first sharable data and first hidden transaction data not visible to the second user. In the present examples, the generation of the emulation data may be triggered by the first user sharing the transaction such as deploying a “tip” as further described below with reference to Figures 4 to 11.

[0096] The tip, for example, having shared data such as an emulation or tip identifier, descriptor and associated hidden data that may include the transaction chain representation data providing the transaction composition, such as the specific markets and any underlying transactions, to enable to emulation of the second transaction and data to allow association with the specific transactable feature such as an event, sporting team or the like. The transaction descriptor may in some examples include a unique determined data element, such as a code, that enables a user to quickly understand that nature of the first transaction. Other examples could include a graphical representation such as an icon. The transaction chain representation data, referred to in the context of this example as transaction or market composition data may be determined by a subroutine as shown in Figures 6 A and 6B as is further detailed below.

[0097] At step 114, the system 10 may be configured to make available the sharable data to the second user and at step 116, the shared data of the first emulation data may be selected by the second user and the second user may initiate a second transaction based on the emulation data which ultimately enables the second transaction to emulate the first transaction. In some examples, the processing of the second transaction may require both of the shared and hidden data of the first emulation data. However, of course, the second user may only view and has access to the shared data. The act of executing the second transaction does not reveal to the second user the details of the first transaction that is being emulated: those particular details of the second transaction also remain hidden from the second user. [0098] The second user may then wish to deploy the second emulation data based on the second transaction which would allow a third or other further user to perform another or third transaction based on the second transaction in which the aspects of the second transaction and first transaction are hidden or not shared. The second shared data of the second emulation data may be selected by the third user and includes a second transaction representation, in this example a descriptor or code, that enables a user to quickly understand that nature of the second transaction.

[0099] A third user may be able to initiate a third transaction based on the second transaction and the first transaction and, if they wish, also a direct transaction based on a transactable feature. Accordingly, the generation of the emulation data becomes more complex as is further detailed in the second example below and in a complex multi-user scenario transactions may involve chains of transactions that themselves include embedded transactions.

[00100] However, before considering a more complex example, an example of an emulated transaction in relation to a betting transaction as executed by the system 10 is provided below with reference to Figures 4 to 11. Starting at Figure 4, a first user initiates a first transaction, that may be a bet, by selecting a transactable feature 150 which in this example includes a betting market. The betting market represents an event or game of a sporting team, and the first user may place a bet as input to initiate the first transaction. In this example, the first user has been given a name “Ebony Brown” for explanatory purposes. Ebony places a normal bet of $100 bet on the Storm to win at odds of $1.75.

[00101] The first user, Ebony, may keep this first transaction confidential or may decide to make the first transaction available to be emulated by another user. The first user may choose to “deploy” the first transaction, which then creates the emulation data. In this example, the emulation data is provided as a “tip” 160 as shown in Figure 5 and includes Ebony deploying a new tip based on this betting market so that other users can emulate her betting behavior. She adds her bet on the Storm team to her draft tip then deploys it. The emulation data includes shared data and hidden data, and the hidden data includes associated composition data - being the substance or core of the first underlying transaction or transactions - that in this example is betting market composition data and may be referred to more broadly as transaction chain representation data.

[00102] Referring to Figure 6 A, the composition data subroutine 200 includes a method or routine to be able to calculate a composition of betting markets in the case of one or multiple markets (i.e. multiple transactable features) of a transaction that is deployed for emulation, and may be used to provide the transaction chain representation data in the form of an array. In this example, there is only a single betting market and therefore the full routine is not required. However, it is nevertheless described here and further described below with reference to the more complex second example.

[00103] The subroutine 200 processes transactions to be deployed as emulation data, in this example tips, to create the betting market composition data type and this data type accounts for any overlap or duplication - if any - between the bets contained in a tip. In the case of Ebony’s tip, which only contains a single betting market, and with reference to Figure 6B, the subroutine creates the simplest possible result - a betting market composition containing a single market. The sequence of steps 1 to 5 are outlined specific to this first example to facilitate better understanding, with explanatory text provided.

[00104] Turning to the subroutine in Figure 6B in more detail, at step 210, the method incudes creating a data structure of a new betting market composition which forms the hidden data of the emulated data, such as the specific market information. At step 220, the subroutine iterates over the draft tip containing the first transaction or transactions. For each of those first transactions, at step 230 the method determines if there is a prior or embedded transaction associated with it.

[00105] If the first transaction is itself a direct bet on a market such as a game, then at step 240 the method determines if the market is included in the betting market composition and if not at step 250 the market is added to the betting market composition. If the market is already included in the betting market composition, then at step 270, the betting market composition is recalculated by combining the pre existing and new stakes for that market. The subroutine then returns to step 210. If there are further transactions in the tip, the process is repeated until all transactions have been processed, otherwise the market composition is saved at step 260 and the process terminates.

[00106] It is noted that creation of the transaction chain representation data which in this example is provided in the form of the betting market composition data at the time of creating the emulatable data (i.e. the tip) provides significant computer processing advantages. Further insight into the advantage gained from the creation of the betting market composition data is described below with reference to Figures 22, 23 and 24. In method 700, as later shown in Figure 24, the betting market composition, referred to in method 700 more broadly as “transaction chain representation data”, is determined at the time of emulatable data (i.e. tip) creation and associated with that tip. Accordingly, when a betting transaction is made on the tip - all prior transactions are already accounted for in the betting market composition meaning that iteration over chains of past transactions is not required.

[00107] At step 280, if the first transaction is itself based on a prior or embedded transaction, referred to here as a “Shadow Bet”, then at step 280, the method includes retrieving the composition data associated with the prior or embedded transaction to determine if there are further markets that need to be added to the composition data. If there are further markets at step 294 the method compares the further markets with the current market composition. If the market is not already included, then at step 292 the betting market is included in the composition data and if the market does already exist then the betting market composition is recalculated at step 296 by combining the pre existing and new metrics or “stakes” for that market as per the market composition formula FI shown on the bottom of Figure 6 A.

[00108] Referring to Figure 7, the sharable data deployed by the first user may be displayed as a transaction that may be emulated to enable a second or other further user to emulate the transaction of the first user. In this example, once deployed, other users can see Ebony’s tip among tips deployed by other users. Only some general information, being the shared data about the expert’s tip is presented - the market itself remains concealed as the hidden data. [00109] In more detail, in this example, the sharable data is shown in Figure 7 as a tip 170 in which the sharable data includes a unique identifier (“Tip Id”), the owner and creator of the prior transactions or tip (“Creator”), a tip description (“Description”), the number of markets or transactions embedded in the tip (“Markets”), the start time of the earliest event in the tip (“Start”), the combined live odds for the betting markets in the tip (“Live Odds”), the smallest or minimum stake a second user can place on the tip (“Min. Tip”), and an indicator of whether the current user has already previously emulated the first user’ s tip (“Backed”). The descriptor enables a second user to quickly view and understand the broad nature of the underlying transactions. For example, at tip 170 other users can see that Ebony Brown has deployed a tip that is based on a single transaction (a single betting market), on which she placed a stake of $100 at odds of $1.75 at the time her original transaction was executed. Other users have until 11:12 pm before the event on Ebony’s tip is based commences (and the tip expires). Other users can also see that the live odds to emulate Ebony have since shortened to $1.45 and that a minimum stake of $1.00 is required. The current user has not previously emulated Ebony’s transaction (since “Backed” is empty).

[00110] Referring to Figure 8 Arthur Grey is a second user who wishes to emulate Ebony Brown’s betting behaviour. He initiates a second transaction 190 of $1000 based on a first transaction or transactions by Ebony Brown - as encapsulated by Ebony Brown’s tip.

[00111] To execute Arthur’s transaction, the system 10 executes the transaction using the emulated data and the hidden data via a further subroutine 300. The further subroutine 300 is shown in Figure 9 as relevant to this example, and in a general form in Figure 11 to also include the hidden bets stake formula. In this example, shown in Figure 9, the subroutine 300 results in a hidden bet of $1000 being placed on the Storm on Arthur’s behalf. The processing steps 1 to 4 are outlined in Figure 11 for further context.

[00112] In more detail, at step 310 in Figure 9, the subroutine iterates over each of the markets in the hidden market composition (in this case a single market being the Storm to win). At step 320 the stake for the hidden transactable item or market is calculated using the hidden bet formula F2 shown in Figure 11. The hidden transaction or bet is then executed at step 340 for the market (i.e. bet placed on the Storm to win). The subroutine returns to step 310 and if the market composition contains more markets the process is repeated until all markets have been processed, otherwise it terminates (as is the case in this example). Once Arthur’s bet has resulted, the concealed market details of Ebony’s tip may remain concealed, or they may be selectively revealed as shown in a site administrator view 192 as shown in Figure 10. This view shows the second transaction data for Arthur and an example of the transaction representation, in this example, the description code.

[00113] A more complex second example is now described with reference to Figures 12 to 21.

Second Example - Complex Transaction (Multiple Markets)

[00114] In this example users may create transactions in relation to multiple transactable features which in this example may include multiple markets. As shown in Figure 12 a user 401 may initiate a transaction based on a transaction of a prior user 402 in which the multiple transactable features of the transaction of the prior user 402 remain hidden from the user. The hidden data may include a transactable feature 404 in the form of a direct bet such as on a football game and another transactable feature 406 in the form of a bet on a further prior user who in turn has made a further prior transaction 408 on a horse race.

[00115] However, importantly, the user 401 will only see sharable data of the prior user that enables the user 401 to execute a single transaction which then emulates the entire chain of transactions associated with the prior user 402 which are defined by the hidden data of the emulation data. All the while the specific transactable features that in this example include the specific football game and the further prior user’s transaction on a horse race remain hidden from the user 401.

[00116] Turning now to a specific example, referring to Figures 13 and 14, another user, Jimmy Tan. It is again noted that fictitious names are used here for explanatory purposes only. [00117] The user, Jimmy Tan, places a normal bet 410 of $50 bet on the Rabbitohs to win at odds of $1.85 as shown in Figure 13 and an emulated bet 412, referred herein as a “shadow bet” of $50 on the tip of a prior user, Arthur Grey, at odds of $1.53 as shown in Figure 14. A shadow bet is a betting transaction based on the sharable data of the emulated data that allows a user to emulate the transactions, in this case betting transactions, of another prior user.

[00118] Unbeknown to the user, Jimmy, the transaction which in this example includes an emulated or shadow bet on Arthur’s tip also contains a bet on the Rabbitohs to win. This means that there is an overlap or duplicate of transactable features. In this example, a market overlap between Jimmy’s normal bet and his emulated or shadow bet is managed within the system 10 to ensure that the relative proportions between all of the markets Jimmy has included in his tip are preserved. This means that when Jimmy’s emulation data or tip is transacted upon by another further user it properly reflects Jimmy’s own transaction or betting pattern and the transaction or betting patterns underlying Jimmy’s bets, in this example, being that of Arthur’s deployed tip.

[00119] The user, Jimmy, may then elect to share his transactions and deploy a new tip based on these betting markets so that other punters can emulate his betting behavior. He adds his bet on the Rabbitohs and his bet on Arthur Grey to his draft tip 414 then deploys it as shown in Figure 15, which generates emulated data including shareable data and hidden data that includes market composition data.

[00120] As with the earlier example, the sharable data of Jimmy’s tip includes a “Tip ID”, “Creator”, “Description”, “Markets”, “Start Time”, “Live Odds”, “Min. Stake” and “Backed” indicator. Jimmy’s tip 420 as displayed by the system is at Figure 18. The description in this example includes an alpha-numerical code i.e. JT (@ $1.64 x $100} with the prior user or tip creator’s initials, odds attained by the creator and the creator’s total stake. This code allows other users to understand the key aspects of the prior transaction or transactions without disclosing the underlying market details.

[00121] To better understand the data that underpins Jimmy’s emulation data or tip, it is useful to first examine Arthur’s emulation data or tip - which is the basis of Jimmy’s emulated transaction or shadow bet. Before deploying his tip, Arthur placed two normal bets (which are not emulated or shadow bets) based on two separate betting markets as shown in Table 1 below, being:

[00122]

Table 1: Markets / Transactable Features

[00123] Once executed, Arthur’s betting transactions may be saved as an array shown in Table 2:

Table 2: Bets / Metrics

[00124] Then, when Arthur deployed his tip based on these bets, the tip was saved in the system as emulation data including a description of the tip object, as shown in Table 3 plus a list of the markets in that tip (i.e. the betting market composition) as shown in Table 4. The information in Table 3 may be used for sharable data and the information in Table 4 may remain hidden. It is noted that Table 4 provides an example array of transaction chain representation data, provided in this example in the form of betting market composition data, as further detailed below with reference to Figures 22 to 24.

Table 3: Tips

Table 4: Tip Markets (betting market composition array)

[00125] This emulation data, namely the sharable data, is presented to other later users, without disclosing the exact details of the underlying markets, that is transactable features, contained within the sharable data or tip as shown in Figure 16. [00126] The tip is now another market that may be transacted upon by other users. In other words, the system 10 may generate further new transactable features that themselves include other transactable features.

[00127] As shown in Figure 16, other users can see that Arthur’s tip is based on two markets that he himself backed for a total stake of $200, at combined odds of $1.55. The specifics of the two markets are maintained as hidden data and only the creating user, in this case Arthur, knows that the two markets he backed were for the Rabbitohs team and the Dragons team to each win - and the individual odds and stakes for those bets.

[00128] Returning to the user, Jimmy, and his tip that is the subject of this example. Before creating it, Jimmy placed one normal bet and one emulated or shadow bet. His normal bet with its $50 stake was based on one market as shown in Table 5, being:

Table 5: Markets

[00129] And his emulated or shadow bet with its $50 stake was based on Arthur’s tip, as described above, the tip is as shown in Table 6 below.

Table 6: Tips

[00130] Once executed, Jimmy’s normal bet (Bet Id 124) and Shadow Bet (Bet Id 125) may be saved as shown in Table 7:

Table 7: Bets — Market and Metrics Array

[00131] The Market Id for the emulated or shadow bet transaction corresponds to the Tip Id of Arthur’s tip. This allows the system to keep track of the links between bets and tips and their underlying markets. This data is used later to deploy Jimmy’s tip.

[00132] The execution of Jimmy’s shadow bet also requires the system 10 to unpack the underlying or embedded transactions, in this example Arthur’s tip. The system 10 iterates over each market in Arthur’s tip and executes hidden transactions or bets on Jimmy’s behalf in accordance with the subroutine as shown in Figure 11 and further described below. It is noted that preferred methods shown in Figures 23 and 24, avoids this “unpacking” the underlying or embedded transactions by creating transaction chain emulation data which includes creating a consolidated array when emulation data (i.e. a tip) is created which includes a core representation of the markets and metrics.

[00133] Jimmy’s stake on Arthur’s tip is $50, so the stakes of the hidden bets must sum to $50. A hidden bet is placed on each market in Arthur’s tip in the same proportions used by Arthur, with each stake calculated according to the Hidden Bet Stake Formula “F2” as shown in Figure 11. First a hidden bet is placed on the Rabbitohs to win, with the stake calculated as:

Arabbitohs ^— $50 X ($50 / $200) — $12.50

[00134] Then a hidden bet is placed on the Dragons to win, with the stake calculated as:

Adragons ⁼ $50 x ($150 / $200) ⁼ $37.50

[00135] The two hidden bets may be recorded in the system as shown in Table 8:

[00136] Recall that Jimmy’s emulation data or tip is comprised of a normal bet on the Rabbitohs to win, plus an emulated or shadow bet on Arthur, which itself comprises of a bet on the Rabbitohs to win and a bet on the Dragons to win. This overlap is rationalized in the system to create Jimmy’s tip with a market composition having the two unique betting markets in the correct proportions as shown in Figure 17 which again shows the market composition subroutine 200 as previously described in relation to Figure 6A in relation to the first example. Like numerals are used to denote like steps. In Figure 17, the sequence of steps 1 to 12 are outlined specific to this second example to facilitate better understanding, with explanatory text provided.

[00137] Jimmy’s emulation data, in this example the tip transaction, is saved in the system as a description of the tip object, plus a list of the (now rationalized) markets in that tip (i.e. the betting market composition) as shown in Tables 9 and 10:

Table 9: Tips

Table 10: Tip Markets (betting market composition)

[00138] Once deployed, other users can see Jimmy’s tip 420 among tips deployed by other users as shown in Figure 18. Only general information about the emulation data is presented such as the creator and description, while the underlying markets remain concealed as part of the hidden data.

[00139] A still further user, Ivory White, decides to initiate still a further transaction 422 based on Jimmy’s deployed tip for $3000 as shown in Figure 19. Within the system 10, the subroutine previously described at Figure 11 executes hidden transactions. Two hidden bets totaling to $3000 are placed Ivory’s behalf as shown in Figure 20.

[00140] Accordingly, the still further user, Ivory, has emulated a prior user, Jimmy’s, betting behavior without ever seeing Jimmy’s original bets or the hidden bets placed on her behalf as shown in Figure 20 which again shows subroutine 300 and includes explanatory notes showing the specific processing steps 1 to 7 specific to the still further user’s, Ivory’s, transaction. Once Ivory’s bet has resulted, the concealed market details of Jimmy’s tip may remain concealed, or they may be revealed such as via an administrator panel as shown in Figure 21.

Example Computation Implementation & Technical Effect

[00141] As discussed above, as each new transaction is made, each new transaction may be based on one or more prior transactions that may include direct transactions with the markets, and also prior nested or embedded transactions. As such, when the new transaction is initiated - the system 10 is required to extract data about the prior transactions to determine how to execute the presently executed transaction.

[00142] The creation of transaction chain representation data, an example of which is detailed above being the betting market composition data created at method step 210 as shown in Figure 6A, and the timing of the creation of this data, is critical to achieving the real-time execution of transactions in practical applications. Present known methods in software development cannot efficiently process the complex nested prior transactions described herein in real-time. However, with the aid of the transaction chain representation data, the prior transactions can be understood and emulated by the system 10, without the complex and time-consuming processing normally required, allowing for real-time execution.

[00143] Figures 22 and 23 demonstrate the impact on the volume of processing required by the system 10, firstly without the aid of the transaction chain representation data as shown in Figure 22, then with the aid of the transaction chain representation data as shown in Figure 23. The preferred method, whose output is represented by Figure 23, is further detailed in relation to Figure 24, in which each transaction ultimately carries with it the transaction chain representation data that allows a much- simplified computational implementation without needing to process any data from the chain of nested transactions themselves, albeit requiring a small additional step to compile the transaction chain representation data proactively, ahead of any other user emulating the transaction chain. This is further explained below.

[00144] During the normal operation of a computer application, code is executed. That code performs tasks that access and transform data. Generally, code is organised as “functions” or “methods” that comprise discrete pieces of code that perform certain operations. These functions can be executed or “called” from other code to perform those operations repeatedly as required.

[00145] A special type of function, known as a recursive function, is one that calls itself when it is executing. That is, once the function is called initially by external code, it can then be called again by its own internal code. This is a powerful tool for solving large and complex problems that require repetitive action. However, executing recursive functions can quickly consume available memory and processing resources, as the operation starts to “balloon” and cause lag. In real-time applications this lag needs to be overcome with additional computing power, or a whole new approach.

[00146] The methods described herein to emulate the transactions of other users may be implemented in code using a recursive function. To emulate a transaction, its composition must first be understood. Recursion lends itself to processing or “unpacking” transaction histories with deeply nested layers, in what can be thought of as a “reactive top-down approach”.

[00147] When the function is first called, it knows nothing yet about the transaction data’s underlying composition, so it “reacts” by drilling down into its component parts and, subsequently, the component parts of those component parts and so on, until all the layers that make up that transaction are understood and resolved. This reactive approach seems a logical choice since the contents of an emulatable transaction is unknowable until it is created.

[00148] For simple transactions, made up of very few underlying parts this approach works. However, as the underlying structure of the prior nested transactions becomes more convoluted, with many more parts, the reactive approach balloons out and real-time processing becomes difficult.

[00149] Consider the example in Figure 22, where User A chooses to emulate a transaction of User B, and User B’s transaction itself emulates the transactions of other Users, working through a series of steps from function calls 1 to 9. Note here that transaction metrics such as the odds and stakes have been omitted for simplicity. After the function is initially called to ascertain the composition of User B’s tip, the function is called recursively a further eight times to unpack the underlying transaction details including transactable features that make up User B’s emulatable transaction, referred to in this example as a “tip”. Here, the unpacking involves the function iterating over data stored in a relational database, with each layer being a record linked to the next by a unique identifier. Each record must be found and examined in turn. It takes a lot of processing to establish that User B’s emulatable transaction or tip has its origins in six other transactions, in this case bets, across two different transactable features, in this case markets being four bets on ‘Race 2 #5’ and two on ‘Race 3 #8’ - as outlined in Table 11.

Table 11 - Output from unpacking User B’s tip by calling a recursive function.

[00150] However, in practical applications, a User’s tip may comprise of many, many more parts - be it other Users’ tips or real markets (i.e. a direct bet on a transactional feature as opposed to a bet on another user’ s tip). Adding the omitted stake and odds back in, which need to be recalculated as each layer is unpacked, also adds to the overall processing required. At scale, this ballooning cannot be processed in real time. A closer look at the output in Table 11 also reveals that function calls 7, 8 and 9 repeat the work already done by calls 4, 5, and 6 in determining the composition of Player D’s tip. This represents an extremely inefficient use of finite computing resources.

[00151] To overcome these problems, a new methodology was created that resolves the complexity of the emulated transactions in real-time, without needing enormous computing resources. This new method can be thought of as a “proactive bottom -up approach”. Rather than deferring the work required to determine the underlying transactional elements such as markets that make up a given emulatable transaction i.e. tip, as per the reactive approach described above, a small amount of additional work is done proactively when a tip is created.

[00152] This extra step embeds or includes the underlying details of an emulatable transaction or tip into the emulatable transaction or tip itself- as transaction chain representation data - so that minimal unpacking is required when a further transaction is based on that emulatable transaction or tip (i.e. the tip is backed). This has a negligible impact on the time required to create the emulatable transaction or tip but has a large positive impact on processing speed when a tip is backed by another User. This is because all of the processing required to determine the underlying transaction core data i.e. markets within a tip has been done in a distributed, bottom-up, manner beforehand as shown in Table 12). _

Table 12. Additional processing done at time of tip creation, well before User B’s tip is backed by User A.

[00153] Referring again to the earlier example in Figure 22, where nine function calls were required to unpack the underlying markets in User B’s tips. Employing transaction chain representation data, only one function call needs to be made when User A backs User B’s tip. The other work has already been done proactively, which allows for real-time processing at scale. The total volume of processing has also been reduced because the processing to unpack User D’ s tip does not need to be repeated. As can be seen in Figure 23, method 600 includes only minimal processing to ascertain the underlying transactable features and associated metrics i.e. markets of User B’s tip using the proactive bottom-up approach. The transaction chain representation data may be stored in an array associated with each emulatable transaction or tip.

[00154] As aforesaid, a specific example of transaction chain representation data creation is provided in the form of betting market composition data created through the execution of methods described above including step 210 in Figures 6 A and 6B.

[00155] Referring now to Figure 24 there is shown a method 700 of processing a transaction to at least partly emulate one or more prior transactions. The transaction may be a bet placed by a user, such as User A as shown in Figure 23, and the one or more prior transactions may have been bets placed by one or more prior users such as User B, etc. The prior transactions may be represented by emulatable data sets (also referred to herein as “tips”) that allows the user to follow and emulate the transaction pattern (i.e. betting pattern) of one or more prior users.

[00156] The method 700 includes, at 710, receiving a transaction input to initiate the transaction based on emulation data (i.e. a tip) associated with the one or more prior transactions. The emulation data may include shared data and hidden data. As detailed above, the shared data may include a transaction representation to allow a user to understand the nature of the emulatable data - but without disclosing some transactional elements such as the specific transactable feature (i.e. specific market features). The hidden data may include transaction chain representation data. In some examples, the transaction chain representation data may be or includes market composition data such as that described above in relation to Figures 6A and 6B.

[00157] At step 720, the method may further include extracting, from the emulation data, transaction chain representation data including a core representation of the one or more prior transactions. As shown in Table 11 above, this core representation may be of the form, for example [‘Event 2 #5’ (x 4) and ‘Event 3 #8’ (x 2)] - which is the transaction chain representation data associated with the emulation data of User B. It is noted that the above format is for explanatory purposes and, of course, another format may be used.

[00158] At step 730, the method includes processing the transaction based on the core representation of the one or more prior transactions and the transaction input. This may include the user, such as User A shown in Figure 23, placing a “bet” on an emulatable transaction of User B which includes “odds” and a monetary amount applied to the core representation extracted.

[00159] At step 740, the method includes generating further emulation data representing the transaction including updating the transaction chain representation data to include a further core representation of the transaction so as to enable a further transaction to emulate the transaction and the one or more prior transactions based on the transaction chain representation data associated with the further emulation data. The core representation includes an array of the consolidated transactable features and the associated metrics so that only a single entry is recorded and stored for each of the transactable features.

[00160] Accordingly, as each new transaction is created the core representations of prior transactions are included or embedded into the transaction chain representation data, as shown in Table 12 and rationalised to remove duplicates so that only a single entry is recorded and stored for each of the transactable features. As such, each set of emulation data associated with each transaction carries with it or has associated transaction chain representation data - which allows the entire history of transactions on which the transaction is based to be executed based on only the transaction chain representation data stored within the same consolidated array. This greatly reduces the number of computational operations required, as shown in Figure 23, and thereby seeks to provide a technical advantage in relation to computation efficiency.

Advantages

[00161] Advantageously, there has been described a method and a system for multi-user transactions in which another user initiates a transaction to emulate a prior transaction of a prior user. The prior user may create emulation data, also referred to herein as a tip, that provides shared information about the prior transaction to the user to enable to user to emulate the prior transactions of the prior user. The emulation data may also include or have associated hidden data containing the specific nature of the prior transaction such as the specific transactable features selected by the prior user. This allows these specific transactable features to remain confidential or at least not be shared with the further user and allows the prior user to maintain some proprietary rights to the specific transactable features.

[00162] Further, each transaction created by the method and system may itself become a new transactable feature that may become subject of a further transaction by a further user, therefore building chains of transactions that are processed via a hidden layer so as to provide the correct type and sequence of underlying transactions that make up the transaction being executed. Furthermore still, the sharable data of the emulation data may include a transaction representation in a form that allows a user making a transaction to readily understand the nature of the transaction without seeing the specific underlying transactable features such as markets.

[00163] Further advantageously, the emulation data created at the time a user wishes to make their transaction emulatable (e.g. sharing a “tip”) contains transaction chain representation data, that may be in the form of market composition data, that includes a core representation of the transaction itself and any prior transactions. The core representation includes a consolidated array of transactable features and associated composite metrics. As such, each set of emulation data associated with each transaction carries with it or has associated transaction chain representation data - which allows the entire history of transactions on which the transaction is based to be executed based on the transaction chain representation data. This greatly reduces the number of computational operations required when a transaction is being emulated and thereby seeks to provide a technical advantage in relation to computation efficiency. The transaction chain representation data may be hidden data to hide the detail of the transaction and its history.

[00164] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[00165] The reference in this specification to any known matter or any prior publication is not, and should not be taken to be, an acknowledgment or admission or suggestion that the known matter or prior art publication forms part of the common general knowledge in the field to which this specification relates.

[00166] While specific examples of the invention have been described, it will be understood that the invention extends to alternative combinations of the features disclosed or evident from the disclosure provided herein.

[00167] Many and various modifications will be apparent to those skilled in the art without departing from the scope of the invention disclosed or evident from the disclosure provided herein.