Method, device and computer program for managing winnings and tracking in a multi-game computer system

Abstract

The invention relates to the management of game winnings in a computer system comprising several independent game modules and a winnings management module separate from the game modules, the winnings management module being configured to obtain winning information relating to participation in a game of a first type and eligibility information for a game of a second type, the obtained winning and eligibility information being received from a first game module, as a function of an identifier of a ticket, obtain winning information relating to participation in the game of the second type in connection with the identifier of the ticket, the winning information relating to participation in the game of the second type being obtained from a second game module linked to the game of the second type, and estimate a winning linked to the identifier of the ticket as a function of the obtained winning information. Abbreviated figure: figure 2

Description

Title of the invention: Method, device and computer program for managing winnings and tracking in a multi-game computer system

[0001] The invention relates to the field of game management in multi-game computer systems, in particular to the management of winnings and the monitoring of operations carried out during the life cycle of a game ticket. The invention applies in particular to games with an additional part and in particular to phygital games comprising participation in physical games such as scratch or lottery games followed by additional digital games such as raffle games or instant games.

[0002] It is observed that the implementation of phygital games accessible to a player using a ticket (physical, for example a scratch card or a lottery ticket or receipt, or virtual also called "e-ticket") generally requires the establishment of a communication link between a game engine responsible for managing a main game (main game engine) and a game engine responsible for managing an additional game (additional game engine). Participation in the additional game is then initiated by the main game engine but processed by the additional game engine. Thus, in particular, when the games implemented allow winnings to be won, the winnings of the main game are determined in the main game engine, for example predetermined winnings, while the winnings of the additional game are determined in the additional game engine, for example randomly.In many existing systems, the additional game engine is therefore configured to exchange data with the main game engine, for example to receive data relating to participation in the additional game and to transmit any winnings associated with this participation in the additional game, so that the main game engine can update a status of the ticket, calculate the total winnings associated with the ticket and allow the player to receive the winnings at the point of sale.

[0003] While these systems are generally satisfactory, they require interactions (or adhesions) between the game engines which constitute an obstacle to the development of phygital games and generate additional costs. Indeed, the development of an additional game, also called an add-on, in addition to a main game, involves a modification of the two engines to allow the establishment of a communication link between the two. In addition to additional development costs, the establishment of communication links between game modules can be the cause of supply problems (for example if the module suppliers are different), integration difficulties when several actors must intervene, a complication of the test phases and an increase in operational risk.

[0004] There is therefore a need to simplify the management of winnings and the monitoring of operations carried out during the life cycle of a ticket in multi-game systems, in particular for phygital games.

[0005] The present invention aims in particular to solve these problems. Statement of the invention

[0006] To this end, the invention proposes an autonomous module for managing winnings and tracking tickets (real or virtual) that can interface with independent game modules (also called "game engines") for the purpose of coordinating their use with regard to a game ticket, making it possible in particular to identify additional games, to calculate winnings from several games and to monitor operations carried out during the life cycle of a ticket.

[0007] A method is thus proposed for managing game winnings in a computer system comprising a plurality of independent game modules and a winnings management module separate from the game modules, the method being implemented in the winnings management module and comprising: • obtaining winning information relating to participation in a game of a first type and eligibility information for a game of a second type, the game of the second type being different from the game of the first type, the winning and eligibility information obtained being received from a first game module linked to the game of the first type and being obtained based on at least one identifier of a ticket; • obtaining winning information relating to participation in the game of the second type in connection with the ticket identifier, the winning information relating to participation in the game of the second type being obtained from a second game module linked to the game of the second type; and • estimation of a gain linked to the ticket identifier based on the gain information obtained.

[0008] The method according to the invention thus makes it possible to simplify the development of game modules and to avoid any direct interaction between them. The management of the winnings associated with the first game and the second game is centralized at the level of the winnings management module.

[0009] According to particular embodiments, the method further comprises a transmission to the second game module of a request to register a participation in the second game, the registration request being associated with the identifier of the ticket.

[0010] Still according to particular embodiments, the method further comprises a transmission of the estimated gain, an instruction to pay the estimated gain and a modification of a status associated with the ticket.

[0011] Still according to particular embodiments, obtaining winning information comprises an interrogation of a data structure received prior to participation in the game at the origin of the winning considered.

[0012] Still according to particular embodiments, obtaining winning information comprises transmitting a request comprising the ticket identifier to a game module and receiving the winning information considered.

[0013] Still according to particular embodiments, the method further comprises a determination of a status associated with the ticket.

[0014] Still according to particular embodiments, the estimation of a gain linked to the identifier of the ticket as a function of the gain information obtained is carried out according to the status associated with the ticket.

[0015] Still according to particular embodiments, the ticket is a physical ticket, in particular a scratch ticket, or a virtual ticket.

[0016] A computer program, implementing all or part of the method described above, installed on pre-existing equipment, is in itself advantageous, since it allows easy and rapid access and selection of an event likely to interest a user.

[0017] Thus, the present invention also relates to a computer program comprising instructions for implementing the method described above, when this program is executed by a processor.

[0018] This program may use any programming language (for example, an object language or other) and be in the form of interpretable source code, partially compiled code or fully compiled code.

[0019] Another aspect relates to a non-transitory storage medium for a computer-executable program, comprising a data set representing one or more programs, said one or more programs comprising instructions for, upon execution of said one or more programs by a computer comprising a processing unit operatively coupled to memory means and to an input / output interface module, to execute all or part of the method described above. Brief description of the drawings

[0020] Other characteristics, details and advantages of the invention will appear on reading the detailed description below. This is purely illustrative and must be read in conjunction with the appended drawings, in which: Fig.l

[0021] [Fig.l] illustrates an example environment in which the invention can be implemented according to particular embodiments; Fig. 2

[0022] [Fig.2] illustrates an example of logical architecture of a multi-game computer system according to particular embodiments of the invention; Fig. 3

[0023] [Fig.3] illustrates a first example of a time diagram of steps of the method of the invention according to a first particular embodiment; Fig. 4

[0024] [Fig.4] illustrates a second example of a time diagram of steps of the method of the invention according to a second particular embodiment; Fig. 5

[0025] [Fig.5] illustrates an example of steps implemented in a payment and traceability module according to a particular embodiment; and Fig. 6

[0026] [Fig.6] illustrates an example of a device that can be used to implement, at least partially, embodiments of the invention, in particular steps described with reference to Figures 3 to 5. Detailed description

[0027] According to particular embodiments of the invention, a module for managing winnings and tracking operations linked to a ticket (real or virtual) is implemented to interface different independent game modules. The module for managing winnings and tracking operations also makes it possible to offer a player, on instruction from a first game module, to participate in one or more other games, different from the first. A ticket is here a pre-printed or partially pre-printed document, which may include a predetermined identifier, or a document created (or edited) when registering participation in a game, to which an identifier is assigned.

[0028] [Fig.l] illustrates an example of an environment in which the invention can be implemented according to particular embodiments. As shown, a user can purchase a game ticket 100, for example at a point of sale also called POS (acronym for point of sale in English terminology). It can be, for example, a scratch card game ticket or a lottery ticket on which the player must select numbers. The ticket can be real or virtual. It typically includes a unique identifier. This identifier is used to know whether the player has won or not and to determine a status. By way of illustration, a ticket can be in a payable, already paid or blocked state, for example if it has been declared stolen. According to In particular embodiments, a ticket identifier comprises an identifier of the game with which the ticket is associated, the game identifier being encoded or not.

[0029] To find out if he has won, a player can go to a point of sale provided with a terminal 105 connected to a server 110 of the manager of the game in question, via a communication network 115. The terminal 105 comprises input means such as a keyboard or reading means such as a scanner or an RFID reader to obtain the identifier of a ticket. It also comprises means for sending requests to the server 110, in particular requests comprising ticket identifiers. Thus, after having obtained the identifier of a ticket, the terminal 105 can send a request to the server 110, comprising the identifier, to know the amount of the win and the status of the ticket. In response, the terminal receives the winnings and status information.If applicable, the point of sale can then pay the winnings to the player (noting that only amounts below a predetermined threshold are paid by the point of sale in cash, larger amounts are usually settled by the game manager by check or bank transfer).

[0030] Alternatively, a player may use a personal device, for example a smartphone 120, a tablet 125 or a personal computer (not shown) to know the amount of winnings and the status of a ticket (a payment of winnings is generally always made at a point of sale). For these purposes, he may use a specific application or a web interface.

[0031] This specific application or this web interface can also be used to offer the player the opportunity to participate in a second game. Indeed, after having transmitted a result of participation in a first game linked to the ticket in question, or simultaneously, the server 110 can transmit an indication according to which a possibility is offered to the player, holder of the ticket in question, to participate in a second game, also called an add-on. This can be, for example, a “double or quits” type game or a “second chance” type game if the player lost during his participation in the first game. The player can then register his participation in this second game using the specific application or the web interface. Such a possibility can also be offered to a player at a point of sale.According to particular embodiments, the recording of a player's participation in a second game is carried out automatically, for example when a player consults his ticket on the specific application or the web interface.

[0032] [Fig. 2] illustrates an example of a logical architecture of a multi-game computer system according to particular embodiments of the invention. This architecture can be implemented, for example, in the server 110 illustrated in [Fig. 1]. According to other embodiments, it is implemented in a distributed system comprising several servers.

[0033] As illustrated, the multi-game computer system 200 comprises a point of sale interface 205, denoted LTW (acronym for lottery widgets in English terminology), and a user interface 210, denoted TTA (acronym for ticket tracker application in English terminology). A point of sale or POS can thus connect to the computer system 200 via the interface 205 and a personal device denoted PD (acronym for personal device in English terminology), such as a smartphone or a tablet, can connect to the computer system 200 via the interface 210.

[0034] The interfaces 205 and 210 are connected to a payment and traceability module 215, denoted TTP (acronym for ticket tracking and payment in English terminology), itself connected to separate game modules 220-1 to 220-n, denoted GE (acronym for game engine in English terminology). Furthermore, the interface 205 is connected to the game modules 220-1 to 220-n to manage a player's participation in the corresponding game.

[0035] It is already observed that all payment and status information obtained by a point of sale is obtained via the payment and traceability module 215 and not directly (the direct link between the interface 205 and the game modules 220-1 to 220-n is not used to directly communicate winnings or status information to a terminal of a point of sale). It is also observed that the game modules are independent and do not exchange data directly with each other, in particular data relating to winnings or to monitoring of operations executed by the game modules.

[0036] The interface 205 makes it possible in particular to query the module 215 to find out the status of a ticket and a winning amount for one or more games. This information can thus be given to a player going to a point of sale with his ticket whose identifier is used to determine the status and the winning amount. The interface 205 also makes it possible to request the module 215 to change the status of a ticket, for example after payment of the winnings. The interface 205 can also be used to inform a point of sale of the possibility for a player to participate in a second game, following participation in a first game, and to record the player's participation in this second game.

[0037] Similarly, the interface 210 makes it possible to query the module 215 to find out the status of a ticket and a winning amount for one or more games. This information can thus be displayed on a player's personal device using a specific application or via a web interface after entering the ticket identifier (by the user or by reading the ticket). The interface 210 can also be used to inform the player of the possibility of participating in a second game, following participation in a first game, and to record his participation in this second game.

[0038] The purpose of module 215 is in particular the management of gains resulting from participations to games, in particular the management of winnings resulting from participation in games linked, directly or indirectly, to the same ticket. According to particular embodiments and / or types of games, for example for scratch-type games, each game module concerned sends a list of winners, for example identified by ticket identifiers, and the associated winning amounts to the module 215. The latter can then determine, in response to a request from a point of sale or a player's personal device, from a ticket identifier, whether a player has won or not and, if applicable, the winning amount. According to other embodiments and / or other types of games, for example raffle games, the module 215 sends a request comprising a ticket identifier to a game module which responds with a ticket status and / or a game result which may include a winning amount.

[0039] The module 215 also has the purpose of monitoring operations carried out during the life cycle of a ticket, in connection with participation in games linked to the same ticket. It can in particular, based on information received from a first game module, propose participation in a game managed by a second game module different from the first, and register a player in the second game, for example by using an identifier of a ticket corresponding to the first game. The module 215 can thus store a game history associated with each ticket. This history can in particular be consulted by the manager of the multi-game system, for example for monitoring, auditing or marketing purposes.

[0040] The game modules 220-1 to 220-n advantageously do not include payment functions, the latter being remote or decentralized in the module 215. In addition to the usual game functions, they therefore include an interface, preferably standardized, with the module 215.

[0041] [Fig.3] illustrates a first example of a time diagram of steps of the method of the invention according to a particular embodiment, between the user interface (TTA) or the point of sale interface (LTW), the payment and traceability module (TTP) and two game modules (GE1 and GE2).

[0042] It is observed that if the payment and traceability module (TTP) is here accessed via the user interface (TTA) or the point of sale interface (LTW), it can be accessed via other interfaces.

[0043] According to this example, it is considered that a player can buy a ticket giving him the right to play an instant game (game 1), for example a scratch game, implemented, here, in the game module GE1, and if he has lost, to play a second chance game (game 2), for example a lottery game implemented, here, in the game module GE2.

[0044] When issuing tickets, the corresponding game module (GE1) determines the number of winning tickets and the associated winnings. The winnings or the list of winning tickets and the associated winnings, depending on the game, are transmitted to the payment and traceability module (TTP). In addition, information that a player having a ticket to play this game is also entitled to play the second game (game 2), if applicable with the conditions of participation in the second game, for example only if the player has lost, is transmitted to the payment and traceability module (TTP). This list and this information (for example an identifier of the second game) are stored here by the payment and traceability module (TTP).

[0045] When a player purchases a ticket and participates in the game, he queries the multi-game system, from a personal device or a point of sale, to find out if he has won. For this purpose, a query including the ticket identifier is transmitted to the payment and traceability module (TTP) via the user interface (TTA) or the point of sale interface (LTW). In response to receiving the query, the payment and traceability module (TTP) determines whether the ticket is a winner or not and, if so, obtains the amount of the win. In addition, it determines the status of the ticket to check the player's rights, for example whether he has the right to be paid a win and play a second game, i.e., for example, whether the ticket is in a payable state. It also determines, based on the information received from the game module, that the player has the opportunity to play the second game and, if he is not already registered, offers him to participate.

[0046] If the player agrees to participate, he notifies the payment and traceability module (TTP) via the user interface (TTA) or the point of sale interface (LTW) with, if applicable, game information, for example a combination of numbers played in the lottery. The payment and traceability module (TTP) then registers the player with the corresponding game module (GE2).

[0047] After the draw, the game module (GE2) determines the winning ticket(s) and the associated winnings, depending on the game, and transmits the list of winning tickets and the associated winnings or the winnings to the payment and traceability module (TTP). The latter can then alert the winners via their personal device. It is observed here that the lists associated with the first and second games can be independent lists or can be combined in the same list. Similarly, these lists can include information relating to all the tickets or can only include information relating to winning tickets, the tickets not present in the list then being considered as losing tickets.

[0048] Following receipt of result information, a player can request payment of winnings. This request is sent to the payment and traceability module (TTP) via the point-of-sale interface (LTW). Upon receipt of this request, the payment and traceability module (TTP) checks the status of the ticket using its identifier. The status can be checked with each of the game modules associated with the games in which the player participated or with the payment and traceability module (TTP) itself, the latter then synthesizing the status associated with the ticket in each of the game modules associated with the games in which the player participated.

[0049] If the ticket is not in a payable state, the player is alerted. If, on the contrary, the ticket is in a payable state, the payment and traceability module (TTP) calculates the amount of winnings due by querying the relevant lists, here the list linked to the game covered by the ticket (game 1) and the list linked to the game covered by the game covered by the ticket (game 2) if the player participated in the latter. The payment and traceability module (TTP) then modifies the status of the ticket which becomes already paid and informs the point of sale of the amount of winnings to be paid (so that the player is paid). The modification of the status is carried out in the payment and traceability module (TTP) and / or in each of the game modules associated with the games in which the player participated.

[0050] The payment and traceability module (TTP) thus centralizes the payment of winnings relating to several participations in games, here a main game and a secondary game.

[0051] [Fig.4] illustrates a second example of a time diagram of steps of the method of the invention according to a second particular embodiment, again between the user interface (TTA) or the point of sale interface (LTW), the payment and traceability module (TTP) and two game modules (GE1 and GE2).

[0052] According to this example, it is considered that a player can buy a ticket giving him the right to play a lottery type game (game 1), implemented, here, in the game module GE1, and if he has won, to play a double or quits type game (game 2) implemented, here, in the game module GE2. Thus, unlike the second game in [Fig.3] which is a deferred participation game, the second game in [Fig.4] is an immediate participation game.

[0053] As illustrated, each lottery ticket played is recorded in the corresponding game module (GE1). At the end of the game, a draw is made and the game module identifies the winning ticket(s), from their identifier, and the amount of the associated winnings. The list of winning tickets and the associated winnings is transmitted to the payment and traceability module (TTP). In addition, information according to which a player having a ticket to play this game also has the right to play the second game (game 2), where applicable with the conditions of participation in the second game, for example only if the player has won, is transmitted to the payment and traceability module (TTP). This list and this information (for example an identifier of the second game) are here stored by the payment and traceability module (TTP). According to particular embodiments, the latter can then alert the winners via their personal device.

[0054] After the winnings of a lottery game have been determined, a player can request the amount of his winnings. For this purpose, a request including the ticket identifier is transmitted to the payment and traceability module (TTP) via the user interface (TTA) or the point of sale interface (LTW). In response to receiving the request, the payment and traceability module (TTP) determines whether the ticket is a winner or not and, if applicable, obtains the amount of the winnings. In addition, it determines the status of the ticket to check the player's rights, for example, whether he is entitled to be paid a winnings and play a second game, i.e., for example, whether the ticket is in a payable state. It also determines, based on the information received from the gaming module, that the player has the opportunity to play the second game and, if he is not already registered, offers him to participate in it.

[0055] If the player agrees to participate, he notifies the payment and traceability module (TTP) via the user interface (TTA) or the point of sale interface (LTW). The payment and traceability module (TTP) then sends a participation request to the corresponding game module (GE2).

[0056] After the draw, the game module (GE2) can indicate to the payment and traceability module (TTP) whether the player has won or lost. It can also indicate it directly to the player, for example depending on the game (e.g. instant entry game or deferred entry game). If it has received the result, the payment and traceability module (TTP) memorizes it, calculates the amount of winnings due by querying the list linked to the game targeted by the ticket (game 1), by applying the result of the second game and preferably informs the player.

[0057] The player can then request payment of these winnings. This request is sent to the payment and traceability module (TTP) via the point of sale interface (LTW). Upon receipt of this request, the payment and traceability module (TTP) checks the status of the ticket using its identifier. If the ticket is not in a payable state, the player is alerted. If, on the contrary, the ticket is in a payable state, the payment and traceability module (TTP) calculates, if necessary, the amount of winnings due by querying the list linked to the game targeted by the ticket (game 1), by applying the result of the second game if the player participated in the latter. The payment and traceability module (TTP) then modifies the status of the ticket which becomes already paid and informs the point of sale of the amount of winnings to be paid (so that the player is paid).Again, the status change is made in the payment and traceability module (TTP) and / or in each of the game modules associated with the games in which the player participated.

[0058] According to particular embodiments, the rules of games and calculation of winnings, specific to each game, are managed autonomously by the game modules while the payment of winnings is managed centrally by the payment and traceability module which also coordinates participation in the different games according to the rules specific to each game.

[0059] A ticket status is here managed by the main game module associated with the ticket in question and, preferably, by each game module associated with the games in which the ticket holder has participated. This status is, for example, in a payable state when the winnings have been determined, in a blocked state if, for example, the ticket has been declared stolen or in a pending state when winnings have not yet been calculated. The ticket status is preferably updated by the game module itself according to standard rules.

[0060] Furthermore, a winning status is managed by the payment and traceability module for each ticket associated with one or more winnings. The winning status is managed by the payment and traceability module according to its own payment rules.

[0061] As soon as a player connects to the payment and traceability module, for example to know a win associated with a ticket, for example via a user interface or via a point of sale interface, the module of the game with which the ticket is associated is queried, using the ticket identifier, to determine the status of the ticket for this game and a possible eligibility to participate in a second game. If, in response, the payment and traceability module is informed of an eligibility to participate in a second game, it can query the game module associated with the latter, using the same ticket identifier to determine a possible participation in this second game and, if applicable, the status of the ticket for this second game and a possible eligibility to participate in a third game.Thus, step by step, the payment and traceability module can determine the participation of the ticket holder in different games and the status of the ticket for these different games. The winnings are preferably transmitted to the payment and traceability module upon participation in the game (immediate participation game) or when the winnings are determined (deferred participation game). The payment and traceability module thus only stores winnings linked to ticket identifiers and determines the operations linked to the same ticket by querying the relevant game modules.

[0062] [Fig.5] illustrates an example of steps implemented in a payment and traceability module according to a particular embodiment.

[0063] As illustrated, a first step involves receiving a request to obtain the status of a ticket and / or to pay out a winnings corresponding to participation in the game associated with this ticket (step 500). This request here includes a ticket identifier. As described previously, this identifier is unique.

[0064] In a following step, a request comprising the identifier received from the ticket is sent to the game module corresponding to the game associated with the ticket to obtain a status of the ticket, where appropriate a gain linked to participation in this game (the gain may be zero) and information on eligibility for a second game (step 505). In response, the payment and traceability module receives the requested information.

[0065] As described previously and according to particular embodiments, all or some of the requested information is directly obtained in the payment and traceability module, this information having been previously received from the game module concerned or having been previously determined within the payment and traceability module. payment and traceability. In particular, winnings can be obtained through the payment and traceability module as soon as they are calculated by game modules.

[0066] In a subsequent step, it is determined whether the ticket is eligible for participation in a second game (step 510). If the ticket is not eligible for participation in a second game, the amount of winnings associated with the ticket in question is calculated as corresponding to the (possible) winnings obtained during participation in the first game (step 515).

[0067] On the contrary, if the ticket is eligible for participation in a second game, a test is performed to determine whether the player is already registered to participate in the second game, i.e. whether the ticket is registered for participation in the second game (step 520). According to certain embodiments, this test is performed by querying the relevant game module. Alternatively, this information can be stored in the payment and traceability module when a player accepts participation in a second game and thus be obtained directly.

[0068] If the player is not already registered to participate in the second game, he is offered to participate therein (step 525). If he agrees to participate therein, corresponding information can be stored in the payment and traceability module and a request is transmitted to the corresponding game module to register the player, for example if it is a lottery game, or to play, for example if it is an instant draw (step 530). It is observed here that the information necessary for participation in the second game is transmitted to the game module associated with the latter. This can be, for example, a bet amount or a winning amount linked to the first game.

[0069] If the player is registered to participate in the second game (step 520 or 530), a request comprising the identifier of the ticket in question is transmitted to the corresponding game module to obtain the status, for this game, of the ticket which led to this participation, where applicable the result or the gain linked to this participation and possible information on eligibility for a third game (step 535). In response, the payment and traceability module receives the requested information.

[0070] As described previously and according to particular embodiments, all or some of the requested information is directly obtained in the payment and traceability module, this information having been previously received from the game module concerned or having been previously determined within the payment and traceability module. Again, winnings can be obtained by the payment and traceability module as soon as they are calculated by game modules.

[0071] If the ticket is eligible for participation in other games, the previous steps (steps 510 to 535) are repeated for each additional game.

[0072] In a next step the winnings resulting from the player's participation in different games, for example the first and second games, in connection with a single ticket, are determined by the payment and traceability module based on information received from the game modules (step 515). If the player requests payment of all or part of the winnings, the payment and traceability module checks the possibility of such payment according to the winning status associated with the ticket in question and to specific winnings payment rules managed by the payment and traceability module.

[0073] The independence of the management of the game rules and the winnings management rules thus facilitates the development and implementation of the game modules. However, according to certain implementations, information on eligibility for additional games may be stored in the payment and traceability module. Tables 1 and 2 given in the appendix thus illustrate particular examples of implementation of the invention.

[0074] Table 1 in the appendix illustrates a first example of ticket lists allowing the management of gains and the monitoring of operations carried out during the life cycle of a ticket. Each line corresponds to a ticket identified by its identifier, the first line corresponding to the default values. The table summarizes the gains obtained and the operations carried out during the life cycle of tickets. The default values ​​line can be used when a ticket is not identified in the list or to define the default values ​​when adding a line corresponding to a ticket to the list.

[0075] According to the illustrated example, the first column corresponds to the identifier of the tickets, the second column corresponds to the amount of winnings associated with the ticket considered in the first game, or main game (i.e. the game associated with the ticket considered), the third column corresponds to the identifier of a second game, the fourth column indicates the conditions under which the possibility of participating in the second game is offered or not to the user, the fifth column indicates the choice of the holder of the ticket considered to participate or not in the second game (if the possibility is not offered to him, a corresponding value is, preferably, added automatically), the sixth column corresponds to the amount of winnings associated with participation in the second game, or additional game, and the seventh column indicates the status of the ticket.

[0076] According to a particular embodiment, the ticket identifier comprises the identifier of the game with which the ticket is associated. According to the illustrated example, the first three digits of the ticket identifier correspond to the game identifier, here 425.

[0077] It is observed here that when the possibility of playing a second game is not offered to a player the identifier of the second game, in the third column, corresponds to a predetermined value providing such an indication, for example the value zero.

[0078] The conditions for participation in the second game are, for example, winning the first game, losing the first game, winning a win in the first game of an amount greater than a predetermined threshold, winning a win in the first game of an amount below a predetermined threshold, etc.

[0079] It is observed that the winnings obtained following participation in the second game may be winnings of a given amount (predetermined or calculated) or may correspond to an operation to be applied to the winnings of the first game, for example canceling the winnings of the first game if the player loses or multiplying the winnings of the first game by a given factor if the player wins.

[0080] The list shown in Table 1 is for example created when receiving information from the game module of the first game and subsequently completed, in particular when a player decides to participate in a second game, when receiving information from the game module of the second game, when receiving a request for payment of winnings, etc.

[0081] According to the illustrated example, representing a list of winnings and operations carried out in connection with a game having the identifier 425, the tickets linked to the game having the identifier 425 offer, by default, the opportunity to their holder to participate in a second game, having the identifier 423, provided that the player has lost in the first game. By default, the tickets are in a payable state. By way of illustration, the ticket having the identifier 42512923 is a winning ticket in the first game, the winning being 10. This ticket being a winner, it does not offer the possibility to its holder to participate in the second game.

[0082] Still for illustration purposes, it is considered that the ticket with identifier 42531199 is not in the list of winning tickets provided by the game module corresponding to game 1. Consequently, it is considered a losing ticket. However, when the holder of this ticket connects to the payment and traceability module, he is offered to participate in the second game (due to the default values ​​offering the possibility of participating in the second game if the holder lost in the first game). If the holder decides to participate in the second game, a line is preferably created in the list. The gain associated with the first game is set to zero while that associated with the second game is updated at the end of the second game.

[0083] Still for illustration purposes, the ticket with the identifier 42532689 is a winning ticket in the first game, the gain being 20. This ticket is here associated with a second game with the identifier 112 (this choice being made by the game module associated with the first game). To participate in this second game, the ticket must be a winner in the first game. As indicated in the fifth column, the ticket holder decided to participate in the second game and won. The ticket here allows its holder to win twice the gain in the first game, i.e. 40.

[0084] Thus, the values ​​present in the list are representative of the gains and operations carried out during the ticket life cycle.

[0085] It is observed here that if the examples given previously are limited to a game main and a secondary game, the invention can be implemented with a main game and several secondary games, the number of secondary games can be predetermined or linked to results obtained in previous games.

[0086] Table 2 in the appendix illustrates a second example of ticket lists allowing the management of winnings and the tracking of operations carried out during the life cycle of tickets associated with a given game, these operations being relative to this game or to another. Each line corresponds to a ticket identified by its identifier, the first line corresponding to the default values. Again, the default values ​​line can be used when a ticket is not identified in the list or to define the default values ​​when adding a line corresponding to a ticket to the list.

[0087] According to the illustrated example, the first column corresponds to the identifier of the tickets, the second column corresponds to the amount of winnings associated with the ticket in question and with the game with which the list in question is associated, the third column corresponds to the identifier of a following game, the fourth column indicates the conditions under which the possibility of participating in the following game is offered or not to the user, the fifth column indicates the choice of the holder of the ticket in question to participate or not in the following game (if the possibility is not offered to him, a corresponding value is, preferably, added automatically) and the sixth column indicates the status of the ticket. It is observed here that the sixth column can only be used if the game associated with the list in question is directly linked to the tickets whose identifiers are listed.

[0088] Several lists can be associated with the same ticket, depending on the number of games in which the holder of the ticket in question has participated (there are as many lists as there are games in which the player has participated). All these lists are consulted to calculate the winnings associated with a ticket.

[0089] As an illustration, the ticket with the identifier 13232681 is a ticket that lost in the first game. This ticket is here associated with a second game with the identifier 107. To participate in this second game, the ticket must lose in the first game. The holder was thus offered to play the second game, however, as indicated in the fifth column, the ticket holder decided not to participate in the second game.

[0090] [Fig.6] illustrates an example of a device that can be used to implement, at least partially, embodiments of the invention, in particular steps described with reference to Figures 3 to 5.

[0091] The device 600 is for example a server, a computer or a terminal.

[0092] The device 600 preferably comprises a communication bus 602 to which are related:

[0093] a central processing unit or microprocessor 604 (CPU, acronym for Central Processing Unit in Anglo-Saxon terminology);

[0094] a 606 read-only memory (ROM, acronym for Read Only Memory in terminology Anglo-Saxon) which may include the operating system and programs such as "Prog";

[0095] a random access memory or cache memory 608 (RAM, acronym for Random Access Memory in English terminology) comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs; and

[0096] a communication interface 626 connected to a distributed communication network 628, for example a wireless communication network and / or a local communication network, the interface being capable of transmitting and receiving data, in particular to and from a user's device.

[0097] Optionally, the device 600 may also have the following elements:

[0098] a hard disk 620 which may contain the aforementioned “Prog” programs and data processed or to be processed according to the invention;

[0099] a keyboard 622 and a mouse 624 or any other pointing device such as an optical pen, a touch screen or a remote control allowing the user to interact with the programs according to the invention;

[0100] a reader 610 of removable storage media 612 such as a memory card or a disk, for example a DVD disk; and

[0101] a graphics card 614 connected to a screen 616.

[0102] The communication bus allows communication and interoperability between the different elements included in the device 600 or connected to it. The representation of the bus is not limiting and, in particular, the central unit is capable of communicating instructions to any element of the device 600 directly or via another element of the device 600.

[0103] The executable code of each program allowing the programmable device to implement the processes according to the invention can be stored, for example, in the hard disk 620 or in read-only memory 606.

[0104] According to a variant, the executable code of the programs may be received via the communication network 628, via the interface 626, to be stored in a manner identical to that described previously.

[0105] More generally, the program(s) may be loaded into one of the storage means of the device 600 before being executed.

[0106] The central unit 604 will control and direct the execution of the instructions or portions of software code of the program(s) according to the invention, instructions which are stored in the hard disk 620 or in the read-only memory 606 or in the other aforementioned storage elements. When the power is switched on, the program(s) which are stored in a non-volatile memory, for example the hard disk 620 or the read-only memory 606, are transferred into the read-only memory 608 which then contains the code executable of the program(s) according to the invention, as well as registers for storing the variables and parameters necessary for implementing the invention.

[0107] Depending on the embodiment selected, certain acts, actions, events, or functions of each of the methods described herein may be performed or occur in a different order than they were described, or may be added, merged, or not performed or not occur, as the case may be. In addition, in some embodiments, certain acts, actions, or events are performed or occur concurrently and not successively.

[0108] Although described through a number of detailed exemplary embodiments, the proposed method and the equipment for implementing the method include various variations, modifications and improvements which will be apparent to those skilled in the art, it being understood that these various variations, modifications and improvements are part of the scope of the invention, as defined by the claims which follow. In addition, different aspects and features described above may be implemented together, or separately, or substituted for each other, and all of the different combinations and sub-combinations of the aspects and features are part of the scope of the invention. Furthermore, some systems and equipment described above may not incorporate all of the modules and functions described for the preferred embodiments.

[0109] [Tables] ID ticket amount winning game 1 ID 2nd game conditions 2nd game player choice amount winning game 2 default status 0 423 lost - - payable 42583198 15 423 lost - - payable 42512923 10 423 lost - - paid 42532681 20 112 won 0(no) - blocked 42532689 20 112 won 1 (yes) x 2 payable

[0110] [T ables 2] Ticket ID Amount Winning Game Next Game ID Next Game Conditions Player Choice Default Status 0 107 Lost - Payable 13283198 5 107 Lost - Payable 13212923 30 218 Won 1 (Yes) Blocked 13232681 0 107 Lost 0(No) Payable

Claims

Claims

1. Method for managing game winnings in a computer system comprising a plurality of independent game modules and a winnings management module separate from the game modules, the method being implemented in the winnings management module and comprising: • obtaining winning information relating to participation in a game of a first type and eligibility information for a game of a second type, the game of the second type being different from the game of the first type, the obtained winning and eligibility information being received from a first game module linked to the game of the first type and being obtained as a function of at least one identifier of a ticket;• obtaining winning information relating to participation in the game of the second type in connection with the ticket identifier, the winning information relating to participation in the game of the second type being obtained from a second game module linked to the game of the second type and being independent of said winning information relating to said game of said first type; and • estimating a winning linked to the ticket identifier as a function of the winning information obtained relating to said game of said first type and to said game of said second type.;

2. The method of claim 1, further comprising transmitting to the second game module a request to register a participation in the second game, the registration request being associated with the ticket identifier.

3. The method of claim 1 or claim 2, further comprising transmitting the estimated win, instructing payment of the estimated win, and modifying a status associated with the ticket.

4. Method according to any one of claims 1 to 3, according to which obtaining winning information comprises an interrogation of a data structure received prior to participation in the game at the origin of the winning considered.

5. A method according to any one of claims 1 to 3, wherein obtaining winning information comprises transmitting a request comprising the ticket identifier to a gaming module and receipt of the gain information considered.

6. A method according to any one of claims 1 to 5 further comprising determining a status associated with the ticket.

7. The method of claim 6, wherein the estimation of a gain linked to the ticket identifier based on the obtained gain information is performed according to the status associated with the ticket.

8. Method according to any one of claims 1 to 7, wherein the ticket is a physical ticket, in particular a scratch ticket, or a virtual ticket.

9. Computer program comprising instructions for implementing each of the steps of the method according to one of claims 1 to 8, when this program is executed by a processor.

10. Device comprising a processing unit configured to execute each of the steps of the method according to one of claims 1 to 8.

Images