EP4213953A1 - Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux - Google Patents

Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux

Info

Publication number
EP4213953A1
EP4213953A1 EP21785951.1A EP21785951A EP4213953A1 EP 4213953 A1 EP4213953 A1 EP 4213953A1 EP 21785951 A EP21785951 A EP 21785951A EP 4213953 A1 EP4213953 A1 EP 4213953A1
Authority
EP
European Patent Office
Prior art keywords
game
ticket
module
winnings
participation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21785951.1A
Other languages
German (de)
English (en)
Inventor
Olivier HUGUENIN
Eric MEYNIEUX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FDJ Gaming Solutions France
Original Assignee
FDJ Gaming Solutions France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by FDJ Gaming Solutions France filed Critical FDJ Gaming Solutions France
Publication of EP4213953A1 publication Critical patent/EP4213953A1/fr
Pending legal-status Critical Current

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F3/00—Board games; Raffle games
    • A63F3/08—Raffle games that can be played by a fairly large number of people
    • A63F3/081—Raffle games that can be played by a fairly large number of people electric
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3244—Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3225—Data transfer within a gaming system, e.g. data sent between gaming machines and users
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326—Game play aspects of gaming systems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326—Game play aspects of gaming systems
    • G07F17/3267—Game outcomes which determine the course of the subsequent game, e.g. double or quits, free games, higher payouts, different new games
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3286—Type of games
    • G07F17/329—Regular and instant lottery, e.g. electronic scratch cards
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/42—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for ticket printing or like apparatus, e.g. apparatus for dispensing of printed paper tickets or payment cards
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F3/00—Board games; Raffle games
    • A63F3/06—Lottos or bingo games; Systems, apparatus or devices for checking such games
    • A63F3/065—Tickets or accessories for use therewith

Definitions

  • 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.
  • the additional game engine is therefore configured to exchange data with the main game engine, for example to receive data relating to a participation in the additional game and to transmit any winnings associated with this participation to the additional game, so that the main game engine can update a status of the ticket, calculate the total win associated with the ticket and allow the player to receive the win at the point of sale.
  • the present invention aims in particular to solve these problems.
  • the invention proposes an autonomous module for managing winnings and tracing tickets (real or virtual) that can interface with independent game modules (also called “game engines") for the purposes of coordinate 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.
  • independent game modules also called “game engines”
  • 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.
  • the method further comprises a transmission to the second game module of a request for recording a participation in the second game, the recording request being associated with the identifier of the ticket .
  • 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.
  • obtaining winning information includes querying a data structure received prior to participation in the game at the origin of the considered winning.
  • obtaining winning information comprises transmitting a request comprising the identifier of the ticket to a game module and receiving the considered winning information.
  • the method further comprises a determination of a status associated with the ticket.
  • the estimation of a gain linked to the identifier of the ticket according to the gain information obtained is carried out according to the status associated with the ticket.
  • the ticket is a ticket with a physical medium, in particular a scratch ticket, or a virtual ticket.
  • a computer program implementing all or part of the method described above, installed on pre-existing equipment, is in itself advantageous, since it makes it possible to easily and quickly access and select an event likely to interest a user.
  • 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.
  • This program can 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.
  • Another aspect relates to a non-transitory storage medium for a computer-executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, when executing said or more programs by a computer comprising a processing unit coupled operationally to memory means and to an input/output interface module, to execute all or part of the method described above.
  • FIG. 1 illustrates an example of an environment in which the invention can be implemented according to particular embodiments
  • FIG. 2 illustrates an example of logical architecture of a multi-game computer system according to particular embodiments of the invention
  • 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 illustrates a second example of a time diagram of steps of the method of the invention according to a second particular embodiment
  • FIG. 5 illustrates an example of steps implemented in a payment and traceability module according to a particular embodiment
  • FIG. 6 illustrates an example of a device that can be used to implement, at least partially, embodiments of the invention, in particular the steps described with reference to Figures 3 to 5.
  • a module for managing gains and monitoring operations linked to a ticket is implemented to interface different independent game modules.
  • the winnings management and transaction monitoring module also makes it possible to offer a player, on the instructions of 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) during the recording of a participation in a game, to which an identifier is assigned.
  • FIG. 1 illustrates an example of an environment in which the invention can be implemented according to particular embodiments.
  • a user can buy a game ticket 100, for example at a point of sale also called POS (acronym for point of sale in English terminology).
  • POS point of sale
  • the ticket can be, for example, a ticket for a scratch game 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 if the player has won or not and to determine a status.
  • a ticket can be in a payable, already paid or blocked state, for example if it has been declared stolen.
  • a ticket identifier comprises an identifier of the game with which the ticket is associated, the identifier of the game being coded or not.
  • 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 includes means for sending requests to the server 110, in particular requests comprising ticket identifiers.
  • the terminal 105 can send a request to the server 110, including the identifier, to know the amount of the gain and the status of the ticket.
  • the terminal receives the earnings and status information. If necessary, the point of sale can then pay the winnings to the player (it being noted that only amounts below a predetermined threshold are paid by the point of sale in cash, larger amounts being generally settled by the game manager by check or bank transfer).
  • a player can 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 made usually always at a point of sale).
  • 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 made usually always at a point of sale).
  • a specific application or a web interface can also be used to offer the player to participate in a second game. Indeed, after having transmitted a result of a participation in a first game linked to the ticket in question, or simultaneously, the server 110 can transmit an indication that a possibility is offered to the player, holder of the ticket in question, to participate in a second game, also called an add-on.
  • the player may be, for example, a "double or quits" type game or a "second chance” type game if the player has lost during his participation in the first game.
  • the player can then record 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.
  • the recording of the participation of a player in a second game is carried out automatically, for example when a player consults his ticket on the specific application or the web interface.
  • FIG. 2 illustrates an example of the 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. According to other embodiments, it is implemented in a distributed system comprising several servers.
  • the multi-game computer system 200 comprises a point of sale interface 205, denoted LTW (lottery widgets acronym in English terminology), and a user interface 210, denoted TTA (ticket tracker application acronym in Anglo-Saxon 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 (abbreviation for personal device in Anglo-Saxon terminology), such as a smartphone or a tablet, can connect to the computer system 200 via interface 210.
  • PD abbreviation for personal device in Anglo-Saxon terminology
  • 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 distinct game modules 220-1 to 220-n, noted GE (abbreviation for game engine in Anglo-Saxon terminology). Furthermore, the interface 205 is linked to the game modules 220-1 to 220-n to manage a player's participation in the corresponding game.
  • TTP payment and traceability module
  • GE abbreviation for game engine in Anglo-Saxon terminology
  • the interface 205 makes it possible in particular to interrogate the module 215 to find out the status of a ticket and an amount of winnings 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 amount of winnings.
  • 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.
  • the interface 210 makes it possible to interrogate the module 215 to find out the status of a ticket and an amount of winnings 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 register his participation in this second game.
  • the module 215 has in particular for its object the management of winnings resulting from participation in games, in particular the management of winnings resulting from participation in games linked, directly or indirectly, to the same ticket.
  • each game module concerned addresses a list of winners, for example identified by ticket identifiers, and the amounts of winnings associated with the module 215. The latter can then determine, in response to a request from a point of sale or a personal device of a player, from a ticket identifier, whether a player has won or not and, if applicable, the amount of winnings.
  • 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 that may include an amount of winnings.
  • the module 215 also aims to monitor operations carried out during the life cycle of a ticket, in connection with participation in games linked to the same ticket. He can in particular, from 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 memorize 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.
  • 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 module 215.
  • 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).
  • TTA user interface
  • LW point-of-sale interface
  • TTP payment and traceability module
  • GE1 and GE2 game modules
  • TTP payment and traceability module
  • 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 module of game 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.
  • game 1 for example a scratch game, implemented here in the module of game GE1
  • game 2 for example a lottery game implemented, here, in the game module GE2.
  • the corresponding game module (GE1) determines the number of winning tickets and the associated winnings.
  • the winnings or the list of winning tickets and associated winnings, depending on the game, are transmitted to the payment and traceability module (TTP).
  • information that 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 for 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 here stored by the payment and traceability module (TTP).
  • a player buys a ticket and takes part in the game, he interrogates the multi-game system, from a personal device or from a point of sale, to find out whether he has won.
  • a request comprising the identifier of the ticket is transmitted to the payment and traceability module (TTP) via the user interface (TTA) or the point of sale interface (LTW).
  • TTP payment and traceability module
  • the payment and traceability module (TTP) determines whether the ticket is a winner or not and, if so, obtains the amount of the win.
  • the ticket determines the status of the ticket to verify the rights of the player, for example if he is entitled to be paid a win and play a second game, i.e., for example, if the ticket is in payable condition. It also determines, based on the information received from the game module, that the player has the possibility of playing the second game and, if he is not already registered, offers him to participate in it.
  • TTP payment and traceability module
  • TTA user interface
  • LW point-of-sale interface
  • GE2 game module
  • the games module determines the winnings or the winning tickets 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 module and traceability (TTP). The latter can then alert the winners via their personal device.
  • the lists associated with the first and the second set can be independent lists or can be combined in the same list. Similarly, these lists may include information relating to all of the tickets or may only include information relating to winning tickets, tickets not present in the list then being considered as losing tickets.
  • a player can request the 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 has participated or with the payment and traceability module (TTP) itself, the latter then summarizing the status associated with the ticket in each of the payment modules. game associated with the games in which the player has participated.
  • the payment and traceability module (TTP) calculates the amount of winnings due by querying the lists concerned, here the list linked to the game targeted by the ticket (game 1) and the list linked to the game targeted by the game covered by the ticket (game 2) if the player participated in the latter.
  • the payment and traceability module (TTP) 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 has participated.
  • the payment and traceability module (TTP) thus centralizes the payment of winnings relating to several participations in games, here a little main and a secondary game.
  • 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).
  • TTA user interface
  • LTW point of sale interface
  • TTP payment and traceability module
  • GE1 and GE2 game modules
  • the second game in FIG. 4 is an immediate participation game.
  • each lottery ticket played is recorded in the corresponding game module (GE1).
  • GE1 game module
  • the game module identifies the winning ticket(s), based on their identifier, and the amount of the associated winnings.
  • the list of winning tickets and associated winnings is transmitted to the payment and traceability module (TTP).
  • information that 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 for 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.
  • a player can request the amount of his winnings.
  • 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).
  • TTP payment and traceability module
  • the payment and traceability module (TTP) determines whether the ticket is a winner or not and, if so, obtains the amount of the win.
  • the status of the ticket to verify the rights of the player, for example if he is entitled to be paid a win and play a second game, i.e., for example, if the ticket is in payable condition. It also determines, based on the information received from the game module, that the player has the possibility of playing the second game and, if he is not already registered, offers him to participate.
  • TTP payment and traceability module
  • TTA user interface
  • LW point-of-sale interface
  • GE2 game module
  • the games module (GE2) can indicate to the payment and traceability module (TTP) whether the player has won or lost. He can also indicate it directly to the player, for example depending on the game (e.g. instant participation game or deferred participation game). If he 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 covered by the ticket (game 1), by applying the result of the second game and preferably informs the player.
  • TTP payment and traceability module
  • 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).
  • TTP payment and traceability module
  • 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 covered 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) 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 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 has participated.
  • the game rules and the calculation of the winnings, specific to each game are managed independently by the game modules, while the payment of the winnings is managed centrally by the module of payment and traceability which also coordinates participation in the various games according to the rules specific to each game.
  • a ticket status is here managed by the module of the main game 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 the winnings have not yet been calculated.
  • the ticket status is preferably updated by the game module itself according to standard rules.
  • 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.
  • the game module with which is associated the ticket is interrogated, using the ticket identifier, to determine the status of the ticket for this game and possible eligibility to participate in a second game.
  • the payment and traceability module can determine the participation of the ticket holder in different games and the status of the ticket for this s 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 memorizes winnings linked to ticket identifiers and determines the operations linked to the same ticket by interrogating the game modules concerned.
  • FIG. 5 illustrates an example of steps implemented in a payment and traceability module according to a particular embodiment.
  • a first step has as its object the receipt of a request to obtain a status for a ticket and/or to pay a prize 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.
  • 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, if necessary a gain linked to participation in this game (the win which may be zero) and eligibility information for a second game (step 505).
  • the payment and traceability module receives the requested information.
  • step 510 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 considered ticket is calculated as corresponding to the (possible) winnings obtained during participation in the first game (step 515).
  • a test is carried out to determine if the player is already registered to participate in the second game, that is to say if the ticket is registered for a participation in the second game (step 520).
  • this test is carried out by interrogating the game module concerned.
  • 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.
  • step 525 If the player is not already registered to participate in the second game, he is offered to participate (step 525). If he agrees to participate, 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 game lottery, 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. It can be, for example, an amount of a bet or a winning amount linked to the first game.
  • 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 having led to this participation, if applicable the result or the gain linked to this participation and any information on eligibility for a third game (step 535).
  • the payment and traceability module receives the requested information.
  • all or some of the information requested is obtained directly in the payment and traceability module, this information having been previously received from the game module concerned or having been previously determined within of 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.
  • step 510 to 535) are repeated for each additional game.
  • step 510 to 535 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 from the information received. 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 a payment according to the winning status associated with the ticket in question and to specific winnings payment rules managed by the module. payment and traceability.
  • Table 1 in the appendix illustrates a first example of lists of tickets 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.
  • 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 (that is to say the game associated to the ticket considered)
  • the third column corresponds to the identifier of a second game
  • the fourth column indicates the conditions according to which the possibility of participating in the second game is offered or not to the user
  • the fifth column indicates the choice of 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
  • the seventh column indicates the status of the ticket.
  • the ticket identifier comprises the identifier of the game with which the ticket is associated.
  • the first three digits of the ticket identifier correspond to the game identifier, here 425. 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 zero value.
  • the conditions of participation in the second game are, for example, to win the first game, to lose the first game, to win a prize in the first game of an amount greater than a predetermined threshold, to win a prize in the first game of an amount lower than a predetermined threshold, etc.
  • 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.
  • the list represented in table 1 is for example created when information is received from the game module of the first game and completed subsequently, in particular when a player decides to participate in a second game, during the receiving information from the game module of the second game, when receiving a request for payment of winnings, etc.
  • the tickets linked to the game having the identifier 425 offer, by default, the opportunity for their holder to participate to a second game, having the identifier 423, provided that the player has lost in the first game.
  • the tickets are in a payable state.
  • the ticket with the identifier 42512923 is a winning ticket in the first game, the gain being 10. This ticket being a winner, it does not offer its holder the possibility of participating in the second game.
  • the ticket having the identifier 42531199 is not in the list of winning tickets provided by the game module corresponding to game 1. Consequently, it is considered as a ticket losing.
  • 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 ).
  • 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.
  • the ticket having the identifier 42532689 is a winning ticket in the first game, the gain being 20.
  • This ticket is here associated with a second game having 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, that is to say 40.
  • the values present in the list are representative of the earnings and of the operations carried out during the life cycle of tickets.
  • Table 2 in the appendix illustrates a second example of lists of tickets allowing the management of winnings and the monitoring of operations carried out during the life cycle of tickets associated with a given game, these operations relating to this game or to another.
  • Each line corresponds to a ticket identified by its identifier, the first line corresponding to the default values.
  • 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.
  • 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 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 according to 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 it, a corresponding value is preferably added automatically)
  • 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 considered is directly linked to the tickets whose identifiers are listed.
  • the ticket having the identifier 13232681 is a losing ticket in the first game.
  • This ticket is here associated with a second game having the identifier 107. To participate in this second game, the ticket must be a loser. in the first game. The ticket 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.
  • Figure 6 illustrates an example of a device that can be used to implement, at least partially, embodiments of the invention, in particular the steps described with reference to Figures 3 to 5.
  • the device 600 is for example a server, a computer or a terminal.
  • the device 600 preferably comprises a communication bus 602 to which are connected:
  • a central processing unit or microprocessor 604 (CPU, acronym for Central Processing Unit in English terminology);
  • a read only memory 606 (ROM, acronym for Read Only Memory in Anglo-Saxon terminology) which may include the operating system and programs such as "Prog";
  • RAM Random Access Memory
  • cache memory 608 comprising registers suitable for recording variables and parameters created and modified during the execution of the aforementioned programs
  • 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 from a user's device.
  • a distributed communication network 628 for example a wireless communication network and/or a local communication network
  • the device 600 can also have the following elements:
  • a hard disk 620 which may include the aforementioned "Prog" programs and data processed or to be processed according to the invention
  • a keyboard 622 and a mouse 624 or any other pointing device such as a light pen, a touch screen or a remote control allowing the user to interact with the programs according to the invention
  • a reader 610 of removable storage medium 612 such as a memory card or a disc, for example a DVD disc; and [0101] a graphics card 614 connected to a screen 616.
  • 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.
  • 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 ROM 606.
  • the executable code of the programs can be received via the communication network 628, via the interface 626, to be stored in the same way as described previously.
  • the program(s) can be loaded into one of the storage means of the device 600 before being executed.
  • 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 ROM 606 or else in the other aforementioned storage elements.
  • the program or programs which are stored in a non-volatile memory for example the hard disk 620 or the ROM 606, are transferred to the random access memory 608 which then contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Pinball Game Machines (AREA)

Abstract

L'invention concerne la gestion de gains de jeux dans un système informatique comprenant plusieurs modules de jeux indépendants et un module de gestion de gains distinct des modules de jeux, le module de gestion de gains étant configuré pour - obtenir une information de gain relatif à une participation à un jeu d'un premier type et une information d'éligibilité à un jeu d'un second type, les informations obtenues de gain et d'éligibilité étant reçues d'un premier module de jeu, en fonction d'un identifiant d'un ticket, - obtenir une information de gain relatif à une participation au jeu du second type en lien avec l'identifiant du ticket, l'information de gain relatif à la participation au jeu du second type étant obtenue d'un second module de jeu lié au jeu du second type, et - estimer un gain lié à l'identifiant du ticket en fonction des informations de gains obtenues.

Description

Description
PROCEDE, DISPOSITIF ET PROGRAMME D’ORDINATEUR DE GESTION DE GAINS ET DE SUIVI DANS UN SYSTEME INFORMATIQUE MULTI-JEUX
[0001] L’ invention se rapporte au domaine de la gestion des jeux dans les systèmes informatiques multi-jeux, notamment à la gestion des gains et au suivi d’opérations effectuées durant le cycle de vie d’un ticket de jeu. L’invention s’applique notamment aux jeux à partie additionnelle et en particulier aux jeux phygitaux comprenant une participation à des jeux physiques tels que des jeux de grattage ou de loterie suivis de jeux additionnels digitaux tels que des jeux de raffle ou des jeux instantanés.
[0002] Il est observé que la mise en oeuvre de jeux phygitaux accessibles à un joueur à l’aide d’un ticket (à support physique, par un exemple un ticket à gratter ou un ticket ou reçu de loterie, ou virtuel aussi appelé « e-ticket » ) nécessite généralement l’établissement d’un lien de communication entre un moteur de jeu en charge de la gestion d’un jeu principal (moteur de jeu principal) et un moteur de jeu en charge de la gestion d’un jeu additionnel (moteur de jeu additionnel). La participation au jeu additionnel est alors initiée par le moteur de jeu principal mais traitée par le moteur de jeu additionnel. Ainsi, notamment, lorsque les jeux mis en oeuvre permettent de remporter des gains, le gain du jeu principal est déterminé dans le moteur de jeu principal, il s’agit par exemple de gains prédéterminés, alors que le gain du jeu additionnel est déterminé dans le moteur de jeu additionnel, par exemple de façon aléatoire. Dans de nombreux systèmes existants, le moteur de jeu additionnel est donc configuré pour échanger des données avec le moteur de jeu principal, par exemple pour recevoir des données relatives à une participation au jeu additionnel et pour transmettre d’éventuels gains associés à cette participation au jeu additionnel, afin que le moteur de jeu principal puisse mettre à jour un statut du ticket, calculer le gain total associé au ticket et permettre au joueur de recevoir le gain en point de vente.
[0003] Alors que ces systèmes donnent globalement satisfaction, ils nécessitent des interactions (ou adhérences) entre les moteurs de jeu qui constituent un frein au développement de jeux phygitaux et engendrent des coûts supplémentaires. En effet, le développement d’un jeu additionnel, aussi appelé add-on, en complément d’un jeu principal, implique une modification des deux moteurs pour permettre l’établissement d’un lien de communication entre les deux. Outre des coûts de développement supplémentaires, l’établissement de liens de communication entre des modules de jeux peut être à l’origine de problèmes d’approvisionnement (par exemple si les fournisseurs de modules sont différents), de difficultés d’intégration lorsque plusieurs acteurs doivent intervenir, d’une complexification des phases de test et d’augmentation du risque opérationnel.
[0004] Il existe donc un besoin de simplification de la gestion des gains et du suivi des opérations effectuées durant le cycle de vie d’un ticket dans des systèmes multi-jeux, en particulier pour des jeux phygitaux.
[0005] La présente invention vise notamment à résoudre ces problèmes.
Exposé de l’invention
[0006] A cet effet, l’invention propose un module autonome de gestion de gains et de traçage de tickets (réels ou virtuels) pouvant s’interfacer avec des modules de jeux (aussi appelés « moteurs de jeux ») indépendants aux fins de coordonner leur utilisation au regard d’un ticket de jeu, permettant notamment d’identifier des jeux additionnels, de calculer des gains issus de plusieurs jeux et de suivre des opérations effectuées durant le cycle de vie d’un ticket.
[0007] Il est ainsi proposé un procédé de gestion de gains de jeux dans un système informatique comprenant une pluralité de modules de jeux indépendants et un module de gestion de gains distinct des modules de jeux, le procédé étant mis en oeuvre dans le module de gestion de gains et comprenant :
• obtention d’une information de gain relatif à une participation à un jeu d’un premier type et d’une information d’éligibilité à un jeu d’un second type, le jeu du second type étant différent du jeu du premier type, les informations obtenues de gain et d’éligibilité étant reçues d’un premier module de jeu lié au jeu du premier type et étant obtenues en fonction d’au moins un identifiant d’un ticket ;
• obtention d’une information de gain relatif à une participation au jeu du second type en lien avec l’identifiant du ticket, l’information de gain relatif à la participation au jeu du second type étant obtenue d’un second module de jeu lié au jeu du second type ; et
• estimation d’un gain lié à l’identifiant du ticket en fonction des informations de gains obtenues.
[0008] Le procédé selon l’invention permet ainsi de simplifier le développement de modules de jeux et d’éviter toute interaction directe entre ces derniers. La gestion des gains associés au premier jeu et au second jeu est centralisée au niveau du module de gestion de gains. [0009] Selon des modes de réalisation particuliers, le procédé comprend en outre une transmission au second module de jeu d’une requête d’enregistrement d’une participation au second jeu, la requête d’enregistrement étant associée à l’identifiant du ticket.
[0010] Toujours selon des modes de réalisation particuliers, le procédé comprend en outre une transmission du gain estimée, une instruction de paiement du gain estimé et une modification d’un statut associé au ticket.
[0011] Toujours selon des modes de réalisation particuliers, l’obtention d’une information de gain comprend une interrogation d’une structure de données reçues préalablement à la participation au jeu à l’origine du gain considéré.
[0012] Toujours selon des modes de réalisation particuliers, l’obtention d’une information de gain comprend une transmission d’une requête comprenant l’identifiant du ticket à un module de jeu et la réception de l’information de gain considérée.
[0013] Toujours selon des modes de réalisation particuliers, le procédé comprend en outre une détermination d’un statut associé au ticket.
[0014] Toujours selon des modes de réalisation particuliers, l’estimation d’un gain lié à l’identifiant du ticket en fonction des informations de gains obtenues est effectuée selon le statut associé au ticket.
[0015] Toujours selon des modes de réalisation particuliers, le ticket est un ticket à support physique, notamment un ticket à gratter, ou un ticket virtuel.
[0016] Un programme informatique, mettant en oeuvre tout ou partie du procédé décrit ci- dessus, installé sur un équipement préexistant, est en lui-même avantageux, dès lors qu’il permet d’accéder et sélectionner facilement et rapidement un événement susceptible d’intéresser un utilisateur.
[0017] Ainsi, la présente invention vise également un programme informatique comportant des instructions pour la mise en oeuvre du procédé précédemment décrit, lorsque ce programme est exécuté par un processeur.
[0018] Ce programme peut utiliser n’importe quel langage de programmation (par exemple, un langage objet ou autre) et être sous la forme d’un code source interprétable, d’un code partiellement compilé ou d’un code totalement compilé.
[0019] Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoires et à un module d’interface entrées/sorties, pour exécuter tout ou partie du procédé décrit ci-dessus.
Brève description des dessins
[0020] D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés, dans lesquels :
Fig. 1
[0021] [Fig. 1] illustre un exemple d’environnement dans lequel l’invention peut être mise en oeuvre selon des modes de réalisation particuliers ;
Fig. 2
[0022] [Fig. 2] illustre un exemple d’architecture logique d’un système informatique multi- jeux selon des modes de réalisation particuliers de l’invention ;
Fig. 3
[0023] [Fig. 3] illustre un premier exemple d’un diagramme temporel d’étapes du procédé de l’invention selon un premier mode de réalisation particulier ;
Fig. 4
[0024] [Fig. 4] illustre un second exemple d’un diagramme temporel d’étapes du procédé de l’invention selon un second mode de réalisation particulier ;
Fig. 5
[0025] [Fig. 5] illustre un exemple d’étapes mises en oeuvre dans un module de paiement et de traçabilité selon un mode de réalisation particulier ; et
Fig. 6
[0026] [Fig. 6] illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, des modes de réalisation de l’invention, notamment des étapes décrites en référence aux figures 3 à 5.
Description détaillée
[0027] Selon des modes de réalisation particuliers de l’invention, un module de gestion de gains et de suivi d’opérations liés à un ticket (réel ou virtuel) est mis en oeuvre pour interfacer différents modules de jeux indépendants. Le module de gestion de gains et de suivi d’opération permet également de proposer à un joueur, sur instruction d’un premier module de jeu, de participer à un ou plusieurs autres jeux, différent du premier. Un ticket est ici un document pré-imprimé ou partiellement pré-imprimé, pouvant comprendre un identifiant prédéterminé, ou un document créé (ou édité) lors de l’enregistrement d’une participation à un jeu, auquel est attribué un identifiant.
[0028] La figure 1 illustre un exemple d’environnement dans lequel l’invention peut être mise en oeuvre selon des modes de réalisation particuliers. Comme représenté, un utilisateur peut acheter un ticket de jeu 100, par exemple à un point de vente aussi appelé POS (acronyme de point of sale en terminologie anglo-saxonne). Il peut s’agir, par exemple, d’un ticket d’un jeu de grattage ou d’un ticket de loterie sur lequel le joueur doit sélectionner des numéros. Le ticket peut être réel ou virtuel. Il comprend typiquement un identifiant unique. Cet identifiant est utilisé pour savoir si le joueur a gagné ou non et pour déterminer un statut. A titre d’illustration, un ticket peut être dans un état payable, déjà payé ou bloqué, par exemple s’il a été déclaré volé. Selon des modes de réalisation particuliers, un identifiant de ticket comprend un identifiant du jeu auquel est associé le ticket, l’identifiant du jeu étant codé ou non.
[0029] Pour savoir s’il a gagné, un joueur peut se rendre à un point de vente pourvu d’un terminal 105 connecté à un serveur 110 du gestionnaire du jeu considéré, via un réseau de communication 115. Le terminal 105 comprend des moyens de saisie tels qu’un clavier ou des moyens de lecture tel qu’un scanner ou un lecteur RFID pour obtenir l’identifiant d’un ticket. Il comprend également des moyens pour adresser des requêtes au serveur 110, notamment des requêtes comprenant des identifiants de tickets. Ainsi, après avoir obtenu l’identifiant d’un ticket, le terminal 105 peut adresser une requête au serveur 110, comprenant l’identifiant, pour connaître le montant du gain et le statut du ticket. En réponse, le terminal reçoit les informations de gains et de statut. Le cas échéant, le point de vente peut alors payer les gains au joueur (étant observé que seuls les montants inférieurs à un seuil prédéterminé sont payés par le point de vente en espèces, les montants plus importants étant généralement réglés par le gestionnaire du jeu par chèque ou virement bancaire).
[0030] Alternativement, un joueur peut utiliser un dispositif personnel, par exemple un smartphone 120, une tablette 125 ou un ordinateur personnel (non représenté) pour connaître le montant des gains et le statut d’un ticket (un paiement de gains se fait généralement toujours dans un point de vente). A ces fins, il peut utiliser une application spécifique ou une interface web. [0031] Cette application spécifique ou cette interface web peut également être utilisée pour proposer au joueur de participer à un second jeu. En effet, après avoir transmis un résultat d’une participation à un premier jeu lié au ticket considéré, ou simultanément, le serveur 110 peut transmettre une indication selon laquelle une possibilité est offerte au joueur, possesseur du ticket considéré, de participer à un second jeu, aussi appelé add-on. Il peut s’agir, par exemple, d’un jeu de type « quitte ou double » ou d’un jeu de type « seconde chance » si le joueur a perdu lors de sa participation au premier jeu. Le joueur peut alors enregistrer sa participation à ce second jeu à l’aide de l’application spécifique ou de l’interface web. Une telle possibilité peut également être offerte à un joueur à un point de vente. Selon des modes de réalisation particuliers, l’enregistrement de la participation d’un joueur à un second jeu est effectué automatiquement, par exemple lorsqu’un joueur consulte son ticket sur l’application spécifique ou l’interface web.
[0032] La figure 2 illustre un exemple d’architecture logique d’un système informatique multi-jeux selon des modes de réalisation particuliers de l’invention. Cette architecture peut être mise en oeuvre, par exemple, dans le serveur 110 illustré sur la figure 1 . Selon d’autres modes de réalisation, elle est mise en oeuvre dans un système distribué comprenant plusieurs serveurs.
[0033] Comme illustré, le système informatique multi-jeux 200 comprend une interface point de vente 205, notée LTW (sigle de lottery widgets en terminologie anglo-saxonne), et une interface utilisateur 210, notée TTA (sigle de ticket tracker application en terminologie anglo-saxonne). Un point de vente ou POS peut ainsi se connecter au système informatique 200 via l’interface 205 et un dispositif personnel noté PD (sigle de personal device en terminologie anglo-saxonne), tel qu’un smartphone ou une tablette, peut se connecter au système informatique 200 via l’interface 210.
[0034] Les interfaces 205 et 210 sont reliées à un module de paiement et de traçabilité 215, noté TTP (sigle de ticket tracking and payment en terminologie anglo-saxonne), lui- même relié à des modules de jeux distincts 220-1 à 220-n, notés GE (sigle de game engine en terminologie anglo-saxonne). Par ailleurs, l’interface 205 est reliée aux modules de jeux 220-1 à 220-n pour gérer une participation d’un joueur au jeu correspondant.
[0035] Il est d’ores et déjà observé que toutes les informations de paiement et de statut obtenues par un point de vente sont obtenues via le module de paiement et de traçabilité 215 et non directement (le lien direct entre l’interface 205 et les modules de jeux 220-1 à 220-n n’est pas utilisé pour communiquer directement des informations de gains ou de statut à un terminal d’un point de vente). Il est également observé que les modules de jeux sont indépendants et n’échangent pas de données directement entre eux, notamment des données relatives à des gains ou à un suivi d’opérations exécutées par les modules de jeux.
[0036] L’ interface 205 permet notamment d’interroger le module 215 pour connaître le statut d’un ticket et un montant de gains pour un ou plusieurs jeux. Ces informations peuvent ainsi être données à un joueur se rendant dans un point de vente avec son ticket dont l’identifiant est utilisé pour déterminer le statut et le montant des gains. L’interface 205 permet également de demander au module 215 le changement de statut d’un ticket, par exemple après paiement des gains. L’interface 205 peut en outre être utilisée pour informer un point de vente de la possibilité pour un joueur de participer à un second jeu, suite à la participation à un premier jeu, et pour enregistrer la participation du joueur à ce second jeu.
[0037] De façon similaire, l’interface 210 permet d’interroger le module 215 pour connaître le statut d’un ticket et un montant de gains pour un ou plusieurs jeux. Ces informations peuvent ainsi être affichées sur un dispositif personnel d’un joueur à l’aide d’une application spécifique ou via une interface web après saisie de l’identifiant du ticket (par l’utilisateur ou par lecture du ticket). L’interface 210 peut aussi être utilisée pour informer le joueur de la possibilité de participer à un second jeu, suite à la participation à un premier jeu, et pour enregistrer sa participation à ce second jeu.
[0038] Le module 215 a notamment pour objet la gestion de gains résultant de participations à des jeux, notamment la gestion de gains résultant de participations à des jeux liés, directement ou indirectement, à un même ticket. Selon des modes de réalisation particuliers et/ou des types de jeux, par exemple pour des jeux de type grattage, chaque module de jeux concerné adresse une liste de gagnants, par exemple identifiés par des identifiants de tickets, et les montants de gains associés au module 215. Ce dernier peut alors déterminer, en réponse à une requête issue d’un point de vente ou d’un dispositif personnel d’un joueur, à partir d’un identifiant de ticket, si un joueur a gagné ou non et, le cas échéant, le montant des gains. Selon d’autres modes de réalisation et/ou d’autres types de jeux, par exemple des jeux de tirage au sort, le module 215 adresse une requête comprenant un identifiant de ticket à un module de jeu qui répond avec un statut de ticket et/ou un résultat de jeu pouvant comprendre un montant de gains.
[0039] Le module 215 a également pour objet le suivi d’opérations effectuées durant le cycle de vie d’un ticket, en lien avec la participation à des jeux liés à un même ticket. Il peut notamment, à partir d’une information reçue d’un premier module de jeu, proposer une participation à un jeu géré par second module de jeu différent du premier, et enregistrer un joueur au second jeu, par exemple en utilisant un identifiant d’un ticket correspondant au premier jeu. Le module 215 peut ainsi mémoriser un historique de jeu associé à chaque ticket. Cet historique peut notamment être consulté par le gestionnaire du système multi- jeux, par exemple à des fins de surveillance, d’audit ou de marketing.
[0040] Les modules de jeux 220-1 à 220-n ne comprennent avantageusement pas de fonctions de paiement, ces dernières étant déportées ou décentralisées dans le module 215. Outre les fonctions usuelles de jeux, ils comprennent donc une interface, de préférence standardisée, avec le module 215.
[0041] La figure 3 illustre un premier exemple d’un diagramme temporel d’étapes du procédé de l’invention selon un mode de réalisation particulier, entre l’interface utilisateur (TTA) ou l’interface point de vente (LTW), le module de paiement et de traçabilité (TTP) et deux modules de jeux (GE1 et GE2).
[0042] Il est observé que si le module de paiement et de traçabilité (TTP) est ici accédé via l’interface utilisateur (TTA) ou l’interface point de vente (LTW), il peut être accédé via d’autres interfaces.
[0043] Selon cet exemple, il est considéré qu’un joueur peut acheter un ticket lui donnant le droit de jouer à un jeu instantané (jeu 1 ), par exemple un jeu de grattage, mis en oeuvre, ici, dans le module de jeu GE1 , et s’il a perdu, de jouer à un jeu de seconde chance (jeu 2), par exemple un jeu de loterie mis en oeuvre, ici, dans le module de jeu GE2.
[0044] Lors de l’émission de tickets, le module de jeux correspondant (GE1 ) détermine le nombre de tickets gagnants et les gains associés. Le gain ou la liste des tickets gagnants et des gains associés, selon le jeu, est transmis au module de paiement et de traçabilité (TTP). En outre, une information selon laquelle un joueur ayant un ticket pour jouer à ce jeu a en outre le droit de jouer au second jeu (jeu 2), le cas échéant avec les conditions de participation au second jeu, par exemple uniquement si le joueur a perdu, est transmise au module de paiement et de traçabilité (TTP). Cette liste et cette information (par exemple un identifiant du second jeu) sont ici stockées par le module de paiement et de traçabilité (TTP).
[0045] Lorsqu’un joueur achète un ticket et participe au jeu, il interroge le système multi- jeu, à partir d’un dispositif personnel ou d’un point de vente, pour savoir s’il a gagné. A ces fins, une requête comprenant l’identifiant du ticket est transmise au module de paiement et de traçabilité (TTP) via l’interface utilisateur (TTA) ou l’interface point de vente (LTW). En réponse à la réception de la requête, le module de paiement et de traçabilité (TTP) détermine si le ticket est gagnant ou non et, le cas échéant, obtient le montant du gain. En outre, il détermine le statut du ticket pour vérifier les droits du joueur, par exemple s’il a le droit de se faire payer un gain et jouer à un second jeu, c’est-à-dire, par exemple, si le ticket est dans un état payable. Il détermine également, à partir des informations reçues du module de jeux, que le joueur a la possibilité de jouer au second jeu et, s’il n’est pas déjà inscrit, lui propose d’y participer.
[0046] Si le joueur accepte d’y participer, il le notifie au module de paiement et de traçabilité (TTP) via l’interface utilisateur (TTA) ou l’interface point de vente (LTW) avec, le cas échéant, des informations de jeux, par exemple une combinaison de nombres joués à la loterie. Le module de paiement et de traçabilité (TTP) enregistre alors le joueur auprès du module de jeu correspondant (GE2).
[0047] Après tirage au sort, le module de jeux (GE2) détermine le gain ou les tickets gagnants et les gains associés, selon le jeu, et transmet la liste des tickets gagnants et des gains associés ou le gain au module de paiement et de traçabilité (TTP). Ce dernier peut alors alerter les gagnants via leur dispositif personnel. Il est observé ici que les listes associées au premier et au second jeux peuvent être des listes indépendantes ou peuvent être combinée dans une même liste. De même, ces listes peuvent comprendre des informations relatives à l’ensemble des tickets ou peuvent ne comprendre que des informations relatives à des tickets gagnants, les tickets non présents dans la liste étant alors considérés comme des tickets perdants.
[0048] Suite à la réception d’une information de résultat, un joueur peut demander le paiement de gains. Cette requête est adressée au module de paiement et de traçabilité (TTP) via l’interface point de vente (LTW). A la réception de cette requête, le module de paiement et de traçabilité (TTP) vérifie le statut du ticket à l’aide de son identifiant. Le statut peut être vérifié auprès de chacun des modules de jeu associés aux jeux auxquels a participé le joueur ou auprès du module de paiement et de traçabilité (TTP) lui-même, ce dernier synthétisant alors le statut associé au ticket dans chacun des modules de jeu associés aux jeux auxquels a participé le joueur.
[0049] Si le ticket n’est pas dans un état payable, le joueur est alerté. Si, au contraire, le ticket est dans un état payable, le module de paiement et de traçabilité (TTP) calcule le montant des gains dû en interrogeant les listes concernées, ici la liste liée au jeu visé par le ticket (jeu 1 ) et la liste liée au jeu visé par le jeu visé par le ticket (jeu 2) si le joueur a participé à ce dernier. Le module de paiement et de traçabilité (TTP) modifie alors le statut du ticket qui devient déjà payé et informe le point de vente du montant des gains à payer (afin que le joueur soit payé). La modification du statut est effectuée dans le module de paiement et de traçabilité (TTP) et/ou dans chacun des modules de jeu associés aux jeux auxquels a participé le joueur. [0050] Le module de paiement et de traçabilité (TTP) centralise ainsi le paiement des gains relatifs à plusieurs participations à des jeux, ici un peu principal et un jeu secondaire.
[0051] La figure 4 illustre un second exemple d’un diagramme temporel d’étapes du procédé de l’invention selon un second mode de réalisation particulier, à nouveau entre l’interface utilisateur (TTA) ou l’interface point de vente (LTW), le module de paiement et de traçabilité (TTP) et deux modules de jeux (GE1 et GE2).
[0052] Selon cet exemple, il est considéré qu’un joueur peut acheter un ticket lui donnant le droit de jouer à un jeu de type loterie (jeu 1 ), mis en oeuvre, ici, dans le module de jeu GE1 , et s’il a gagné, de jouer à un jeu de type quitte ou double (jeu 2) mis en oeuvre, ici, dans le module de jeu GE2. Ainsi, contrairement au second jeu de la figure 3 qui est jeu à participation différée, le second jeu de la figure 4 est un jeu à participation immédiate.
[0053] Comme illustré, chaque ticket de loterie joué est enregistré dans le module de jeu correspondant (GE1 ). A la clôture du jeu, un tirage au sort est effectué et le module de jeu identifie le ou les tickets gagnants, à partir de leur identifiant, et le montant des gains associés. La liste des tickets gagnants et des gains associés est transmise au module de paiement et de traçabilité (TTP). En outre, une information selon laquelle un joueur ayant un ticket pour jouer à ce jeu a en outre le droit de jouer au second jeu (jeu 2), le cas échéant avec les conditions de participation au second jeu, par exemple uniquement si le joueur a gagné, est transmise au module de paiement et de traçabilité (TTP). Cette liste et cette information (par exemple un identifiant du second jeu) sont ici stockées par le module de paiement et de traçabilité (TTP). Selon des modes de réalisation particuliers, ce dernier peut alors alerter les gagnants via leur dispositif personnel.
[0054] Après que les gains d’un jeu de loterie aient été déterminés, un joueur peut demander le montant de son gain. A ces fins, une requête comprenant l’identifiant du ticket est transmise au module de paiement et de traçabilité (TTP) via l’interface utilisateur (TTA) ou l’interface point de vente (LTW). En réponse à la réception de la requête, le module de paiement et de traçabilité (TTP) détermine si le ticket est gagnant ou non et, le cas échéant, obtient le montant du gain. En outre, il détermine le statut du ticket pour vérifier les droits du joueur, par exemple s’il a le droit de se faire payer un gain et jouer à un second jeu, c’est-à-dire, par exemple, si le ticket est dans un état payable. Il détermine également, à partir des informations reçues du module de jeux, que le joueur a la possibilité de jouer au second jeu et, s’il n’est pas déjà inscrit, lui propose d’y participer.
[0055] Si le joueur accepte d’y participer, il le notifie au module de paiement et de traçabilité (TTP) via l’interface utilisateur (TTA) ou l’interface point de vente (LTW). Le module de paiement et de traçabilité (TTP) adresse alors une requête de participation au module de jeu correspondant (GE2).
[0056] Après tirage au sort, le module de jeux (GE2) peut indiquer au module de paiement et de traçabilité (TTP) si le joueur a gagné ou perdu. Il peut également l’indiquer directement au joueur, par exemple selon le jeu (e.g. jeu à participation instantanée ou jeu à participation différée). S’il a reçu le résultat, le module de paiement et de traçabilité (TTP) le mémorise, calcule le montant des gains dû en interrogeant la liste liée au jeu visé par le ticket (jeu 1 ), en appliquant le résultat du second jeu et en informe, de préférence, le joueur.
[0057] Le joueur peut alors demander le paiement de ces gains. Cette requête est adressée au module de paiement et de traçabilité (TTP) via l’interface point de vente (LTW). A la réception cette requête, le module de paiement et de traçabilité (TTP) vérifie le statut du ticket à l’aide de son identifiant. Si le ticket n’est pas dans un état payable, le joueur est alerté. Si, au contraire, le ticket est dans un état payable, le module de paiement et de traçabilité (TTP) calcule, si nécessaire, le montant des gains dû en interrogeant la liste liée au jeu visé par le ticket (jeu 1 ), en appliquant le résultat du second jeu si le joueur a participé à ce dernier. Le module de paiement et de traçabilité (TTP) modifie alors le statut du ticket qui devient déjà payé et informe le point de vente du montant des gains à payer (afin que le joueur soit payé). A nouveau, la modification du statut est effectuée dans le module de paiement et de traçabilité (TTP) et/ou dans chacun des modules de jeu associés aux jeux auxquels a participé le joueur.
[0058] Selon des modes de réalisation particuliers, les règles de jeux et de calcul des gains, propres à chaque jeu, sont gérées de façon autonome par les modules de jeu alors que le paiement des gains est géré de façon centralisée par le module de paiement et de traçabilité qui coordonne en outre les participations aux différents jeux selon les règles propres à chaque jeu.
[0059] Un statut de ticket est ici géré par le module du jeu principal associé au ticket considéré et, de préférence, par chaque module de jeu associé aux jeux auxquels le titulaire du ticket a participé. Ce statut est, par exemple, dans un état payable lorsque les gains ont été déterminés, dans un état bloqué si, par exemple, le ticket a été déclaré volé ou dans un état en attente lorsque les gains n’ont pas encore été calculés. Le statut de ticket est, de préférence, mis à jour par le module de jeu lui-même selon des règles standard.
[0060] Par ailleurs, un statut de gain est géré par le module de paiement et de traçabilité pour chaque ticket associé à un ou plusieurs gains. Le statut de gain est géré par le module de paiement et de traçabilité selon des règles de paiement qui lui sont propres. [0061] Dès qu’un joueur se connecte au module de paiement et de traçabilité, par exemple pour connaître un gain associé à un ticket, par exemple via une interface utilisateur ou via une interface point de vente, le module du jeu auquel est associé le ticket est interrogé, en utilisant l’identifiant du ticket, pour déterminer le statut du ticket pour ce jeu et une éventuelle éligibilité pour participer à un second jeu. Si, en réponse, le module de paiement et de traçabilité est informé d’une éligibilité pour participer à un second jeu, il peut interroger le module de jeu associé à ce dernier, en utilisant le même identifiant de ticket pour déterminer une éventuelle participation à ce second jeu et, le cas échéant, le statut du ticket pour ce second jeu et une éventuelle éligibilité pour participer à un troisième jeu. Ainsi, de proche en proche, le module de paiement et de traçabilité peut déterminer la participation du titulaire du ticket à différents jeux et le statut du ticket pour ces différents jeux. Les gains sont de préférence transmis au module de paiement et de traçabilité dès la participation au jeu (jeu à participation immédiate) ou lorsque les gains sont déterminés (jeu à participation différée). Le module de paiement et de traçabilité ne mémorise ainsi que des gains en lien avec des identifiants de tickets et détermine les opérations liées à un même ticket en interrogeant les modules de jeux concernés.
[0062] La figure 5 illustre un exemple d’étapes mises en oeuvre dans un module de paiement et de traçabilité selon un mode de réalisation particulier.
[0063] Comme illustré, une première étape a pour objet la réception d’une requête d’obtention d’un statut d’un ticket et/ou de paiement d’un gain correspondant à une participation au jeu associé à ce ticket (étape 500). Cette requête comprend ici un identifiant du ticket. Comme décrit précédemment, cet identifiant est unique.
[0064] Dans une étape suivante, une requête comprenant l’identifiant reçu du ticket est adressée au module de jeu correspondant au jeu associé au ticket pour obtenir un statut du ticket, le cas échéant un gain lié à une participation à ce jeu (le gain pouvant être nul) et une information d’éligibilité à un second jeu (étape 505). En réponse, le module de paiement et de traçabilité reçoit les informations demandées.
[0065] Comme décrit précédemment et selon des modes de réalisation particuliers, toutes ou certaines des informations demandées sont directement obtenues dans le module de paiement et de traçabilité, ces informations ayant été préalablement reçues du module de jeu concerné ou ayant été préalablement déterminées au sein du module de paiement et de traçabilité. En particulier, des gains peuvent être obtenus par le module de paiement et de traçabilité dès qu’ils sont calculés par des modules de jeux. [0066] Dans une étape suivante, il est déterminé si le ticket est éligible pour une participation à un second jeu (étape 510). Si le ticket n’est pas éligible pour une participation à un second jeu, le montant des gains associés au ticket considéré est calculé comme correspondant aux gains (éventuels) obtenus lors de la participation au premier jeu (étape 515).
[0067] Au contraire, si le ticket est éligible pour une participation à un second jeu, un test est effectué pour déterminer si le joueur est déjà inscrit pour participer au second jeu, c’est- à-dire si le ticket est enregistré pour une participation au second jeu (étape 520). Selon certains modes de réalisation, ce test est effectué en interrogeant le module de jeu concerné. Alternativement, cette information peut être mémorisée dans le module de paiement et de traçabilité lorsqu’un joueur accepte la participation à un second jeu et ainsi être obtenue directement.
[0068] Si le joueur n’est pas déjà inscrit pour participer au second jeu, il lui est proposé d’y participer (étape 525). S’il accepte d’y participer, une information correspondante peut être mémorisée dans le module de paiement et de traçabilité et une requête est transmise au module de jeu correspondant pour enregistrer le joueur, par exemple s’il s’agit d’un jeu de loterie, ou pour jouer, par exemple s’il s’agit d’un tirage au sort instantané (étape 530). Il est observé ici que les informations nécessaires à la participation au second jeu sont transmises au module de jeu associé à ce dernier. Il peut s’agir, par exemple, d’un montant d’une mise ou d’un montant de gain lié au premier jeu.
[0069] Si le joueur est enregistré pour participer au second jeu (étape 520 ou 530), une requête comprenant l’identifiant du ticket considéré est transmise au module de jeu correspondant pour obtenir le statut, pour ce jeu, du ticket ayant conduit à cette participation, le cas échéant le résultat ou le gain lié à cette participation et une éventuelle information d’éligibilité à un troisième jeu (étape 535). En réponse, le module de paiement et de traçabilité reçoit les informations demandées.
[0070] Comme décrit précédemment et selon des modes de réalisation particuliers, toutes ou certaines des informations demandées sont directement obtenues dans le module de paiement et de traçabilité, ces informations ayant été préalablement reçues du module de jeu concerné ou ayant été préalablement déterminées au sein du module de paiement et de traçabilité. A nouveau, des gains peuvent être obtenus par le module de paiement et de traçabilité dès qu’ils sont calculés par des modules de jeux.
[0071] Si le ticket est éligible à une participation à d’autres jeux, les étapes précédentes (étapes 510 à 535) sont répétées pour chaque jeu additionnel. [0072] Dans une étape suivante les gains résultant de la participation du joueur à différents jeux, par exemple au premier et au second jeux, en lien avec un unique ticket, sont déterminés par le module de paiement et de traçabilité à partir des informations reçues des modules de jeu (étape 515). Si le joueur demande le paiement de tout ou partie des gains, le module de paiement et de traçabilité vérifie la possibilité d’un tel paiement selon le statut de gain associé au ticket considéré et à des règles particulières de paiement de gains gérées par le module de paiement et de traçabilité.
[0073] L’indépendance de la gestion des règles de jeux et des règles de gestion des gains facilite ainsi le développement et la mise en oeuvre des modules de jeux. Cependant, selon certaines implémentations, des informations d’éligibilité à des jeux additionnels peuvent être mémorisées dans le module de paiement et de traçabilité. Les tableaux 1 et 2 donnés en annexe illustrent ainsi des exemples particuliers de mise en oeuvre de l’invention.
[0074] Le tableau 1 en annexe illustre un premier exemple de listes de tickets permettant la gestion de gains et le suivi d’opérations effectuées durant le cycle de vie d’un ticket. Chaque ligne correspond à un ticket identifié par son identifiant, la première ligne correspondant aux valeurs par défaut. Le tableau synthétise les gains obtenus et les opérations effectuées durant le cycle de vie de tickets. La ligne de valeurs par défaut peut être utilisée lorsqu’un ticket n’est pas identifié dans la liste ou pour définir les valeurs par défaut lors de l’ajout dans la liste d’une ligne correspondant à un ticket.
[0075] Selon l’exemple illustré, la première colonne correspond à l’identifiant des tickets, la seconde colonne correspond au montant des gains associés au ticket considéré au premier jeu, ou jeu principal (c’est-à-dire le jeu associé au ticket considéré), la troisième colonne correspond à l’identifiant d’un second jeu, la quatrième colonne indique les conditions selon lesquelles la possibilité de participer au second jeu est proposée ou non à l’utilisateur, la cinquième colonne indique le choix du titulaire du ticket considéré de participer ou non au second jeu (si la possibilité ne lui est pas proposée, une valeur correspondante est, de préférence, ajoutée automatiquement), la sixième colonne correspond au montant des gains associés à une participation au second jeu, ou jeu additionnel, et la septième colonne indique le statut du ticket.
[0076] Selon un mode de réalisation particulier, l’identifiant du ticket comprend l’identifiant du jeu auquel est associé le ticket. Selon l’exemple illustré, les trois premiers chiffres de l’identifiant du ticket correspondent à l’identifiant du jeu, ici 425. [0077] Il est observé ici que lorsque la possibilité de jouer à un second jeu n’est pas proposée à un joueur l’identifiant du second jeu, dans la troisième colonne, correspond à une valeur prédéterminée fournissant une telle indication, par exemple la valeur zéro.
[0078] Les conditions de participation au second jeu sont, par exemple, de gagner au premier jeu, de perdre au premier jeu, de gagner un gain au premier jeu d’un montant supérieur à un seuil prédéterminé, de gagner un gain au premier jeu d’un montant inférieur à un seuil prédéterminé, etc.
[0079] Il est observé que les gains obtenus suite à une participation au second jeu peuvent être des gains d’un montant donné (prédéterminé ou calculé) ou peuvent correspondre à une opération devant être appliquée aux gains du premier jeu, par exemple annuler les gains du premier jeu si le joueur perd ou multiplier les gains du premier jeu par un facteur donné si le joueur gagne.
[0080] La liste représentée dans le tableau 1 est par exemple créée lors de la réception d’informations du module de jeu du premier jeu et complétée par la suite, notamment lorsqu’un joueur décide de participer à un second jeu, lors de la réception d’informations du module de jeu du second jeu, lors de la réception d’une demande de paiement de gains, etc.
[0081] Selon l’exemple illustré, représentant une liste des gains et des opérations effectuées en lien avec un jeu ayant pour identifiant 425, les tickets liés au jeu ayant pour identifiant 425 offrent, par défaut, l’opportunité à leur titulaire de participer à un second jeu, ayant pour identifiant 423, sous réserve que le joueur ait perdu au premier jeu. Par défaut, les tickets sont dans un état payable. A titre d’illustration, le ticket ayant l’identifiant 42512923 est un ticket gagnant au premier jeu, le gain étant de 10. Ce ticket étant gagnant, il n’offre pas la possibilité à son titulaire de participer au second jeu.
[0082] Toujours à titre d’illustration, il est considéré que le ticket ayant pour identifiant 42531199 n’est pas dans la liste des tickets gagnants fournie par le module de jeu correspondant au jeu 1. Par conséquent, il est considéré comme un ticket perdant. Cependant, lorsque le titulaire de ce ticket se connecte au module de paiement et de traçabilité, il lui est proposé de participer au second jeu (en raison des valeurs par défaut offrant la possibilité de participer au second jeu si le titulaire à perdu au premier jeu). Si le titulaire décide de participer au second jeu, une ligne est de préférence créée dans la liste. Le gain associé au premier jeu est mis à la valeur zéro tandis que celui associé au second jeu est mis à jour à l’issue du second jeu. [0083] Toujours à titre d’illustration, le ticket ayant l’identifiant 42532689 est un ticket gagnant au premier jeu, le gain étant de 20. Ce ticket est ici associé à un second jeu ayant pour identifiant 112 (ce choix étant fait par le module de jeu associé au premier jeu). Pour participer à ce second jeu, le ticket doit être gagnant au premier jeu. Comme indiqué dans la cinquième colonne, le titulaire du ticket a décidé de participer au second jeu et a gagné. Le ticket permet ici à son titulaire de gagner deux fois le gain au premier jeu, c’est-à-dire 40.
[0084] Ainsi, les valeurs présentes dans la liste sont représentatives des gains et des opérations effectuées durant le cycle de vie de tickets.
[0085] Il est observé ici que si les exemples donnés précédemment se limitent à un jeu principal et un jeu secondaire, l’invention peut être mise en oeuvre avec un jeu principal et plusieurs jeux secondaires, le nombre de jeux secondaires pouvant être prédéterminé ou lié à des résultats obtenus à des jeux précédents.
[0086] Le tableau 2 en annexe illustre un second exemple de listes de tickets permettant la gestion de gains et le suivi d’opérations effectuées durant le cycle de vie de tickets associés à un jeu donné, ces opérations étant relatives à ce jeu ou à un autre. Chaque ligne correspond à un ticket identifié par son identifiant, la première ligne correspondant aux valeurs par défaut. A nouveau, la ligne de valeurs par défaut peut être utilisée lorsqu’un ticket n’est pas identifié dans la liste ou pour définir les valeurs par défaut lors de l’ajout dans la liste d’une ligne correspondant à un ticket.
[0087] Selon l’exemple illustré, la première colonne correspond à l’identifiant des tickets, la seconde colonne correspond au montant des gains associés au ticket considéré et au jeu auquel est associée la liste considérée, la troisième colonne correspond à l’identifiant d’un jeu suivant, la quatrième colonne indique les conditions selon lesquelles la possibilité de participer au jeu suivant est proposée ou non à l’utilisateur, la cinquième colonne indique le choix du titulaire du ticket considéré de participer ou non au jeu suivant (si la possibilité ne lui est pas proposée, une valeur correspondante est, de préférence, ajoutée automatiquement) et la sixième colonne indique le statut du ticket. Il est observé ici que la sixième colonne peut n’être utilisée que si le jeu associé à la liste considérée est directement lié aux tickets dont les identifiants sont listés.
[0088] Plusieurs listes peuvent être associées à un même ticket, selon le nombre de jeux auxquels a participé le titulaire du ticket considéré (il y a autant de listes que de jeux auxquels a participé le joueur). Toutes ces listes sont consultées pour calculer les gains associés à un ticket. [0089] A titre d’illustration, le ticket ayant l’identifiant 13232681 est un ticket perdant au premier jeu. Ce ticket est ici associé à un second jeu ayant pour identifiant 107. Pour participer à ce second jeu, le ticket doit être perdant au premier jeu. Il a ainsi été proposé au titulaire de jouer au second jeu cependant, comme indiqué dans la cinquième colonne, le titulaire du ticket a décidé de ne pas participer au second jeu.
[0090] La figure 6 illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, des modes de réalisation de l’invention, notamment des étapes décrites en référence aux figures 3 à 5.
[0091] Le dispositif 600 est par exemple un serveur, un ordinateur ou un terminal.
[0092] Le dispositif 600 comporte de préférence un bus de communication 602 auquel sont reliées :
[0093] une unité centrale de traitement ou microprocesseur 604 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;
[0094] une mémoire morte 606 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter le système d’exploitation et des programmes tels que "Prog" ;
[0095] une mémoire vive ou mémoire cache 608 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et
[0096] une interface de communication 626 reliée à un réseau de communication distribué 628, par exemple un réseau de communication sans fil et/ou un réseau de communication local, l'interface étant apte à transmettre et à recevoir des données, notamment vers et depuis un dispositif d’un utilisateur.
[0097] Optionnellement, le dispositif 600 peut également disposer des éléments suivants :
[0098] un disque dur 620 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l’invention ;
[0099] un clavier 622 et une souris 624 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l’utilisateur d’interagir avec les programmes selon l'invention ;
[0100] un lecteur 610 de support amovible de stockage 612 tel qu’une carte mémoire ou un disque, par exemple un disque DVD ; et [0101] une carte graphique 614 reliée à un écran 616.
[0102] Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600.
[0103] Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention peut être stocké, par exemple, dans le disque dur 620 ou en mémoire morte 606.
[0104] Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 628, via l'interface 626, pour être stocké de façon identique à celle décrite précédemment.
[0105] De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés.
[0106] L'unité centrale 604 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 620 ou dans la mémoire morte 606 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 620 ou la mémoire morte 606, sont transférés dans la mémoire vive 608 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.
[0107] En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.
[0108] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé proposé et l’équipement pour la mise en oeuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en oeuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.
[0109] [Tableau 1]
[0110] [Tableau 2]

Claims

Revendications
[Revendication 1] Procédé de gestion de gains de jeux dans un système informatique comprenant une pluralité de modules de jeux indépendants et un module de gestion de gains distinct des modules de jeux, le procédé étant mis en oeuvre dans le module de gestion de gains et comprenant :
• obtention d’une information de gain relatif à une participation à un jeu d’un premier type et d’une information d’éligibilité à un jeu d’un second type, le jeu du second type étant différent du jeu du premier type, les informations obtenues de gain et d’éligibilité étant reçues d’un premier module de jeu lié au jeu du premier type et étant obtenues en fonction d’au moins un identifiant d’un ticket ;
• obtention d’une information de gain relatif à une participation au jeu du second type en lien avec l’identifiant du ticket, l’information de gain relatif à la participation au jeu du second type étant obtenue d’un second module de jeu lié au jeu du second type ; et
• estimation d’un gain lié à l’identifiant du ticket en fonction des informations de gains obtenues.
[Revendication 2] Procédé selon la revendication 1 , comprenant en outre une transmission au second module de jeu d’une requête d’enregistrement d’une participation au second jeu, la requête d’enregistrement étant associée à l’identifiant du ticket.
[Revendication 3] Procédé selon la revendication 1 ou la revendication 2, comprenant en outre une transmission du gain estimée, une instruction de paiement du gain estimé et une modification d’un statut associé au ticket.
[Revendication 4] Procédé selon l’une quelconque des revendications 1 à 3, selon lequel l’obtention d’une information de gain comprend une interrogation d’une structure de données reçues préalablement à la participation au jeu à l’origine du gain considéré.
[Revendication 5] Procédé selon l’une quelconque des revendications 1 à 3, selon lequel l’obtention d’une information de gain comprend une transmission d’une requête comprenant l’identifiant du ticket à un module de jeu et la réception de l’information de gain considérée.
[Revendication 6] Procédé selon l’une quelconque des revendications 1 à 5 comprenant en outre une détermination d’un statut associé au ticket.
[Revendication 7] Procédé selon la revendication 6, selon lequel l’estimation d’un gain lié à l’identifiant du ticket en fonction des informations de gains obtenues est effectuée selon le statut associé au ticket.
[Revendication 8] Procédé selon l’une quelconque des revendications 1 à 7 selon lequel le ticket est un ticket à support physique, notamment un ticket à gratter, ou un ticket virtuel.
[Revendication 9] Programme d’ordinateur comprenant des instructions pour la mise en oeuvre de chacune des étapes du procédé selon l’une des revendications 1 à 8, lorsque ce programme est exécuté par un processeur.
[Revendication 10] Dispositif comprenant une unité de traitement configurée pour exécuter chacune des étapes du procédé selon l’une des revendications 1 à 8.
EP21785951.1A 2020-09-16 2021-09-14 Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux Pending EP4213953A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2009367A FR3114033A1 (fr) 2020-09-16 2020-09-16 Procédé, dispositif et programme d’ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux
PCT/FR2021/051574 WO2022058676A1 (fr) 2020-09-16 2021-09-14 Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux

Publications (1)

Publication Number Publication Date
EP4213953A1 true EP4213953A1 (fr) 2023-07-26

Family

ID=73401804

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21785951.1A Pending EP4213953A1 (fr) 2020-09-16 2021-09-14 Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux

Country Status (5)

Country Link
US (1) US20230377414A1 (fr)
EP (1) EP4213953A1 (fr)
CA (1) CA3191378A1 (fr)
FR (1) FR3114033A1 (fr)
WO (1) WO2022058676A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106204872A (zh) * 2015-05-27 2016-12-07 国际游戏公司 游戏系统、游戏券和实现游戏的方法
US10304282B2 (en) * 2016-01-28 2019-05-28 Playtech Software Limited Autonomously operating computerized gaming platforms and method of operating thereof

Also Published As

Publication number Publication date
WO2022058676A1 (fr) 2022-03-24
US20230377414A1 (en) 2023-11-23
FR3114033A1 (fr) 2022-03-18
CA3191378A1 (fr) 2022-03-24

Similar Documents

Publication Publication Date Title
US10832520B2 (en) Fungible object award interleaved wagering system
US20090143128A1 (en) Providing centralized services to game operators
KR101511928B1 (ko) 맵-기반 게임에 관련해서 소프트웨어 오브젝트를 제공 및 처리하기 위한 시스템 및 방법
AU2003274441B2 (en) System and method for jackpot wagering
US20190051118A1 (en) Skill-based progressive pool combined proposition wagering system
US10540849B2 (en) Alternate payment mechanism interleaved skill wagering gaming system
AU2013311319A1 (en) Pool wagering apparatus, methods and systems
US10380846B2 (en) Market based interleaved wagering system
US10431042B2 (en) Recommendation module interleaved wagering system
RU2643430C2 (ru) Система и способ осуществления ставок в режиме реального времени, предусматривающие джекпот
US20190051112A1 (en) Transparent prize combined proposition wagering system
US8235822B2 (en) Transmitting content in wagering networks
EP4213953A1 (fr) Procédé, dispositif et programme d'ordinateur de gestion de gains et de suivi dans un système informatique multi-jeux
FR3137301A1 (fr) Système de jeux digitaux liés
WO2024003513A1 (fr) Système de jeux digitaux liés
FR3131415A1 (fr) Procédé, dispositif et programme d’ordinateur de gestion de gains de jeux digitaux d’argent et de hasard multi-joueurs
WO2024003512A1 (fr) Procédé, dispositif et programme d'ordinateur de mise en oeuvre de jeux digitaux liés
FR3137477A1 (fr) Procédé, dispositif et programme d’ordinateur de mise en œuvre de jeux digitaux liés
WO2023067274A1 (fr) Procédé, dispositif et programme d'ordinateur d'adaptation contextuelle de jeux phygitaux
US11823530B2 (en) Transaction sequences including a linked deal within an initial deal
WO2023126597A1 (fr) Procédé, dispositif et programme d'ordinateur d'établissement de profils de comportements d'usagers procédé, dispositif et programme d'ordinateur d'établissement de profils de comportements d'usagers
US20210082228A1 (en) Collecting and levelling up predictions as collectible cards
KR20030041374A (ko) 게임기의 당첨내역과 적립금을 확인할 수 있는 인터넷용게임 시스템 및 그 방법

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230310

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230728

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20240408

RIC1 Information provided on ipc code assigned before grant

Ipc: A63F 3/06 20060101ALN20240322BHEP

Ipc: G07F 17/42 20060101ALI20240322BHEP

Ipc: G07F 17/32 20060101ALI20240322BHEP

Ipc: A63F 3/08 20060101AFI20240322BHEP

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MEYNIEUX, ERIC

Inventor name: HUGUENIN, OLIVIER