WO2022058676A1

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

Info

Publication number: WO2022058676A1
Application number: PCT/FR2021/051574
Authority: WO
Inventors: Olivier HUGUENIN; Eric MEYNIEUX
Original assignee: Fdj Gaming Solutions France
Priority date: 2020-09-16
Filing date: 2021-09-14
Publication date: 2022-03-24
Also published as: FR3114033A1; CA3191378A1; EP4213953A1; US20230377414A1

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

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 :

[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.