Brevet FR2881006A1 — publié le 20060721

Domaine de l'invention La présente invention concerne un système de communication permettant en particulier une mise en oeuvre de jeux pour terminal de communication mobile et plus précisément de jeux de chance de type loterie. Présentation de l'Art antérieur La grande popularisation des terminaux de communication tels que les téléphones mobiles a contraint les fournisseurs de service à faire 15 un effort pour développer et offrir de nouvelles applications embarquées sur ces terminaux. Ils fournissent, de plus en plus, à la fois ladite application embarquée sur le terminal mobile et le service associé sur le serveur. Cette offre est rendue complexe lorsqu'il s'agit de proposer des 20 applications qui présentent l'infrastructure d'un jeu de type loterie en association avec un jeu électronique à distance. En effet, dans un univers de jeu d'argent, les échanges entre le joueur et le service associé sur le serveur nécessitent un système avec un maximum de sécurité financière et technique. On connaît par le document FR 2 830 353 un dispositif de mise en oeuvre sécurisée de jeux de type loterie utilisant un téléphone mobile. Ce système prévoit une carte à puce prépayée comprenant des paramètres de jeu nécessitant un pari où sont inscrits un identifiant et une signature. Un utilisateur qui souhaite effectuer un pari, insère la carte dans son téléphone mobile et transmet un message qui contient les paramètres de son pari accompagné de l'identifiant et de la signature de la carte au centre de gestion. Si le centre de gestion retrouve dans ses moyens de stockage l'identifiant et la signature de la carte, il conclut que l'utilisateur a une carte valide et authentifie le pari. Cependant, ce type de système ne prévoit qu'un nombre limité d'échanges entre le serveur et le joueur. Il se limite ainsi à des jeux de 5 où l'interactivité et la participation active des joueurs sont minimales. L'invention a notamment pour objectif de pallier les inconvénients de l'art antérieur. Un premier but de la présente invention est de proposer un 10 système de communication dédié plus particulièrement aux jeux qui implique une participation très active des utilisateurs tout en préservant leur anonymat lors d'une session de jeu telle qu'une session de jeu de type loterie. Un second but de la présente invention est de proposer un système de communication dédié plus particulièrement aux jeux permettant d'assurer la confidentialité et la sécurisation des échanges entre un terminal de communication et un serveur de gestion de données. Un autre but de la présente invention est de proposer un système de communication dédié plus particulièrement aux jeux qui permet une maîtrise des risques financiers et techniques pour l'administrateur du serveur. Il est également désirable d'offrir une expérience de jeu riche transposant une mécanique de jeu d'arcade dans un univers de jeu d'argent et proposant une interactivité nouvelle permettant à l'utilisateur de construire sa partie en fonction de ses choix, de cumuler des gains pour arriver à un total de gains sujet immédiatement à rétribution. Un dernier but de la préserte invention est de proposer un système de communication dédié plus particulièrement aux jeux qui permet à l'utilisateur de jouer sur son terminal de communication connecté au réseau et de profiter d'une expérience multimédia même sur un réseau de données à bat débit. Résumé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite sont atteints à l'aide d'un système de communication comprenant un serveur de gestion de données connecté au moins à un terminal de communication, au moins un support présentant un code d'activation, ledit code d'activation étant associé à des données présentes dans des moyens de stockage dudit serveur de gestion de données caractérisé en ce que en réponse audit code d'activation reçu dudit terminal de communication, ledit serveur de gestion de données (300) comprend des moyens aptes à ouvrir au moins un compte auquel est associé un code correspondant audit code d'activation reçu et des moyens aptes à transmettre au moins audit terminal de communication les données associées audit code d'activation. Avantageusement, le serveur de gestion de données envoie, en outre, au terminal de communication, un identifiant dédié aux données transmises auquel est associé au moins un code correspondant au code d'activation reçu. De préférence, les données associées à un code d'activation incluent des applications définissant des jeux et/ou des attributs d'une entité de jeu et plus particulièrement des applications définissant un jeu de chance comportant plusieurs niveaux de jeu. Avantageusement, le système de communication selon l'invention comprend un terminal mobile présentant au moins des moyens de saisie 25 pour entrer des informations de jeu et les envoyer au serveur de gestion de données. De son côté, le serveur de gestion de données comporte pour chacun des niveaux de jeu au moins - des moyens pour générer plusieurs ensembles d'événements 30 différents, chaque ensemble comprenant au moins un événement associé à un résultat gagnant; - des moyens pour initialiser suite à une information de jeu reçu de l'utilisateur le niveau de jeu; des moyens pour enregistrer sur le compte ouvert au moins les informations de jeux définissant le choix d'un événement parmi les événements d'un ensemble particulier d'événements généré lors de l'initialisation et/ou le résultat associé aux informations de jeu choisies 5 par le terminal de communication, le résultat d'un niveau de jeu étant dépendant des résultats des autres niveaux. Brève description des figures 10 L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description qui va suivre donnée à titre d'exemple non limitatif et grâce aux dessins annexés parmi lesquels: - La figure 1 illustre le schéma cinématique de fonctionnement du 15 système de communication selon l'invention; - La figure 2 illustre l'interface permettant le téléchargement de données par l'utilisateur d'un terminal de communication; - La figure 3 illustre le schéma synoptique d'une partie jouée par l'utilisateur d'un terminal de communication; - La figure 4 illustre un diagramme des séquences d'échanges de données entre l'utilisateur d'un terminal de communication et le serveur de gestion de données. Description détaillée de l'invention 25 En se référant à la figure 1, le système de communication comprend au moins un terminal de communication 200, un serveur de gestion de données 300 et un ticket 1.00 De préférence chaque ticket 100 a la forme d'une carte. 30 Alternativement, il peut avoir la forme d'un quelconque objet approprié. Quand le ticket 100 est imprimé, il est imprimé avec un code d'activation 101 inscrit dessus. s De préférence, des moyens pour cacher le code d'activation 101 de la vue des éventuels acheteurs sont présents sur le ticket 100. La zone masquée est susceptible d'être découverte par grattage ou tout autre moyen connu, le code d'activation 101 pouvant par la suite être 5 visible par l'acheteur du ticket. Selon l'invention, cette information inscrite sur le ticket 100 est un code 101 comportant une série de caractères alpha numériques. Des variantes de réalisation de l'invention permettent d'envisager tout autre type de codage. Par exemple, on peut citer des codes d'activation incluant des symboles et des lettres ou un code adapté à une forme lisible par une machine, par exemple, un code bar. Chaque code d'activation 101 est lié à des données particulières que l'utilisateur souhaite acquérir. Plus particulièrement, dans l'illustration qui est faite de 15 l'invention, le ticket 100 est un ticket de jeu et les données téléchargeables qui y sont liées peuvent inclure, mais ne sont pas limitées, à des applications définissant un jeu, des attributs d'une entité de jeu, une extension de jeu déjà présent dans le terminal de communication 200 ou des codes pour débloquer des niveaux de jeu ou 20 créditer des caractères dans des jeux déjà présents dans le terminal de communication 200. De préférence, le ticket 100 cornporte au moins une indication visible du contenu des données et/ou une indication du prix de vente, indication qui correspondra, comme cela sera décrit plus loin, à la somme déposée sur un compte particulier créé par le serveur de gestion de données 301. Avantageusement, le ticket 100 est prépayé auprès d'un vendeur ce qui évite toute transaction financière entre le serveur de gestion de données 300 et l'utilisateur. L'affectation d'un ticket 100 à un utilisateur 30 est ainsi totalement anonyme. Selon l'invention, chaque code d'activation est unique et le ticket est privatif. Plus précisément, il est associé à un unique terminal de communication 200 comme décrit plus loin. E Dans un mode de réalisation préféré de l'invention, les terminaux sont des terminaux de communication capables de communications sans fil avec un réseau de communication. De préférence, le système utilise un téléphone portable 200 5 comme terminal de communication. Des variantes de réalisation concernent l'utilisation d'ordinateurs personnels ou d'assistants personnels comme terminaux de communication. Le terminal de communication 200 comprend au moins une 10 mémoire pour stocker les données qui vont être transmises par le serveur, un écran de visualisation 230, des moyens de saisie permettant entre autre à l'utilisateur de faire des requêtes au serveur de gestion de données et un processeur. Pour valider un ticket, un utilisateur avec son terminal de 15 communication 200 se connecte grâce à un réseau de communication au serveur de gestion de données. Une fois que la communication est établie, l'utilisateur peut saisir grâce aux moyens de saisie de son terminal de communication, le code d'activation en sa possession et le transmettre au serveur de gestion de 20 données comme décrit plus loin en référence à la figure 2. Le terme de réseau doit être compris dans le sens le plus général. Par exemple, le réseau peut être Internet ou un réseau de communication de téléphonie mobile. La présente invention s'applique, bien que non exclusivement, 25 aux téléphones mobiles suivant la norme de transmission GPRS . D'autre part, dans un mode de réalisation préféré de l'invention, la liaison entre le serveur 300 et le terminal 200 est de préférence une liaison WAP. La nature des liaisons peut faire l'objet de nombreuses variantes 30 de réalisation. Par exemple, on peut considérer l'utilisation de liaisons serveur/terminal telle qu'Internet, les messages de type SMS, les liaisons vocales. Le serveur de gestion de données 300 est configuré de manière à ce que, en réponse au code d'activation 101 reçu d'un terminal de communication 200, il enregistre alors le code d'activation 101, il crée un compte lié à ce code d'activation et il envoie au terminal de communication 200 les données liées à ce code d'activation pour un futur téléchargement et un identifiant lié à ces données. Le serveur de gestion de données 300 se présente sous la forme d'un serveur comprenant au moins un module d'interface avec un réseau de communication, des moyens de mémorisation telle qu'une base de données interfacée par une application serveur qui gère entre autres, le suivi des comptes et répond aux requêtes des utilisateurs. Les moyens de mémorisation stockent un certain nombre d'informations comme, par exemple, une liste de codes d'activations de tickets ou les données qui peuvent être interprétées par le terminal de communication. Avantageusement mais de manière non limitative, l'application serveur est réalisée par une servlet java traitant les requêtes http. Le serveur de gestion de données 300 peut être une unité unique ou peutêtre distribué physiquement. Dans un mode de réalisation préféré de l'invention, le serveur de gestion de données 300 est configuré pour transmettre, après avoir reçu d'un terminal de communication 200 un code d'activation 101 d'un ticket 100, le contenu des données associées avec ce code d'activation à ce terminal seulement si ce code d'activation est valide c'est-à-dire que les données qui lui sont associées n'ont pas déjà été transmises à un autre terminal. Cette vérification permet d'éviter que le ticket soit utilisé plusieurs fois sur des terminaux différents. Selon l'invention, le code d'activation peut quand même être 30 réutilisé dans le cas où les données sont rechargées par le même terminal de communication 200. Après vérification de la validité du code, le serveur de gestion de données peut créer le compte associé à un code correspondant au code d'activation et envoyer les données que le terminal de communication souhaite télécharger et l'identifiant associé. Le serveur associe dans la base de données cet identifiant à au moins un code d'activation et le cornpte associé. D'autres éléments à associer peuvent être envisagés dans des variantes de réalisation de l'invention. Ils ne sont pas limités aux exemples cités précédemment. Un compte est activé sur le serveur 300 sur requête reçue de l'utilisateur lorsqu'il saisit pour la première fois le code d'activation 10 associé aux données qu'il souhaite acquérir. Selon l'invention, le compte est défini comme l'ensemble des informations relatives à un ticket auquel sont associés un code d'activation unique et, de manière non exhaustive, un solde et les résultats des exécutions des données téléchargées. La création du compte autorise alors le téléchargement des données choisies sur le terminal de communication 200. Une fois que le téléchargement est effectué, l'utilisateur peut exécuter les données sur son terminal de communication 200. Lors de la première exécution, et à chaque nouvelle session, les données, sous réserve d'indication d'un code d'activation valide, reçoivent un identifiant unique qui sera transmis au terminal de communication et servira lors de chacune de ses requêtes les concernant au serveur de gestion de données. Un exemple de réalisation de l'invention concerne le 25 téléchargement d'une application de feu. Le serveur 300 associe alors dans la base de données l'identifiant de l'application à un certain nombre d'éléments. On peut citer comme exemples non limitatifs, le code d'activation et le compte de jeu créé, les choix de l'utilisateur lors des parties, ses 30 requêtes, les tirages effectués et/ou les résultats en découlant. Par ailleurs, le serveur notifie ces deux derniers éléments aux joueurs comme décrit plus loin en relation avec la figure 4. Selon l'invention, à la première exécution de l'application, le joueur dispose d'un solde de compte égal à une mise potentielle initiale de jeu définie par la valeur de vente du ticket. L'utilisateur peut alors débuter une session. Une session est définie ici comme une période qui débute à l'entrée d'un code d'activation et la création d'un cornpte et qui se termine soit quand le solde du compte est nul soit quand l'utilisateur efface l'application de son terminal de communication. Dans une session, plusieurs parties sont possibles. Une partie est 10 définie comme l'ensemble des événements se déroulant entre le moment ou l'utilisateur sélectionne dans un menu de l'application téléchargée décrit ci-dessous en référence avec la figure 3 l'option jouer et l'affichage du résultat qui se définit comme le gain ou la perte enregistrée à l'issue d'une partie. En cas de gain à l'issue de la première partie, le joueur peut décider de l'encaisser ou de le réinvestir pour recommencer une nouvelle partie. Selon l'invention, dès que le solde de son compte atteint 0, le compte est clôturé. D'autre part, l'unicité du code d''activation est assurée. En effet, les codes dont les gains ont été retirés ou dont le solde est épuisé sont marqués et conservées dans la base de données. Ils ne permettent plus de télécharger l'application ni d'initialiser une nouvelle partie. Le système de communication comprend un module de paiement des gains à l'utilisateur. Il peut se présenter sous différentes formes connues telles qu'un module faisane partie du serveur de gestion de données, une banque ou un vendeur de ticket. La figure 2 illustre un moyen possible de validation d'un ticket et de téléchargement des données associées au code d'activation du ticket. Selon l'invention, quand l'utilisateur décide de télécharger les données, il se connecte via le réseau de communication à une interface de type HTML. De préférence, cette interface est hébergée sur le serveur de gestion de données de l'éditeur 302 l'éditeur 302 définissant l'administrateur du système ou l'opérateur de données (voir figurel). Elle permet à l'utilisateur de saisir son code d'activation, de valider ce code et une fois que le code est activé de sélectionner les données auquel il souhaite accéder afin de les télécharger. Pour un premier téléchargement sur le terminal de communication, le joueur doit disposer d'un accès au réseau de données permettant la connexion au serveur. L'utilisateur saisit le code d'activation présent sur le ticket dans le formulaire html 402 prévu à cet effet sur la page d'accueil du site 401. De préférence, le code se compose de 8 caractères alphanumériques. Lors de chaque session de l'utilisateur, trois essais d'entrée du code d'activation sont autorisés. En cas d'erreur lors de la troisième saisie, le joueur qui a été identifié par l'identifiant de son terminal ne peut plus accéder au téléchargement de l'application ou des données pendant un délai d'une heure. Dans le cas où le code est valide, un menu 403 propose une liste de choix prédéfinis de manière conviviale de données auxquelles on peut accéder. Tel qu'illustré sur la page 4-03, une liste de jeux peut être proposée. L'utilisateur fait son choix et se voit proposer un nouveau menu 404 lié au jeu sélectionné. Différentes possibilités illustrées, mais non limitatives, lui sont 30 offertes comme la possibilité de télécharger le jeu, d'obtenir plus d'informations sur le jeu ou d'accéder au règlement du jeu ainsi qu'une option pour retourner à la page du sii_e où se trouve la liste des jeux en vue de choisir un autre jeu si le premier sélectionné ne lui convient pas. ] 1 Selon l'invention, pour effectuer le téléchargement des données choisies, le joueur clique sur le lien provoquant le téléchargement d'un fichier descripteur contenant la signature électronique du fournisseur et un lien vers l'archive contenant les informations et les ressources de l'application ou données choisies par l'utilisateur. De préférence, les fichiers sont des fichiers rédigés en langage Java. Le terminal télécharge l'archive et vérifie son intégrité avec la valeur de hachage inscrite dans le fichier descripteur. Des variantes de réalisation de l'invention considèrent le cas d'autres moyens de téléchargements bien connus de l'homme de l'art. D'autre part, des variantes de réalisation de l'invention considèrent d'autres cas de téléchargements. En particulier, une variante de réalisation concerne le cas d'un 15 utilisateur qui, après avoir récupéré son solde, utilise un nouveau ticket. Le nouveau code est alors associé sur le serveur à l'identifiant assigné lors de la première session. Une autre variante de réalisation concerne le cas où l'utilisateur a son solde de compte épuisé. Quand il utilise un nouveau ticket, le 20 nouveau code d'activation est alors associé sur le serveur à l'identifiant assigné lors de la première session. Une autre variante de réalisation concerne un utilisateur qui aurait désinstallée les données de son terminal et qui souhaite les remettre. Dans ce cas, quand il utilise un nouveau ticket, un nouveau compte et un nouvel identifiant leurs sont assignés. Dans l'exemple illustré figure 2, l'application de jeu téléchargée contient toutes les données et ressources notamment tous les graphiques nécessaires à n'importe quelle future partie de jeu. Une fois que le téléchargement est effectué, le joueur peut 30 installer et exécuter les données sur son terminal de communication. En se référant maintenant à la figure 3, on considère le téléchargement de données correspondant à une application de jeu définie pour le système de communication tel que décrit précédemment. Cette application est initialisée ou réinitialisée sur le terminal de communication lors de son téléchargement par l'utilisateur. Si l'utilisateur dispose d'un solde suffisant sur son compte, il peut miser une somme débitée sur le compte associé au code d'activation du ticket et démarrer une partie en sélectionnant l'option jouer du menu 220 qui lui est présenté sur l'écran du terminal de communication. D'autres options (E2) non limitatives représentées dans le menu 220 peuvent proposer à l'utilisateur, par exemple, de l'aide concernant l'application téléchargée, de quitter l'application téléchargée, ou le solde du compte créé lors du téléchargement. Après avoir sélectionner jouer (El), l'utilisateur accède à un 15 premier niveau de l'application. Selon l'invention, l'application comprend une pluralité de niveaux. Chaque niveau est défini comme un environnement graphique présentant un univers d'événements, chaque événement possible d'un niveau étant défini comme une sortie prédéterminée. Chaque sortie prédéterminée correspond à une sélection possible de l'événement définie comme un choix. Dans un mode de réalisation préféré de l'invention, chaque niveau comprend au moins une sortie gagnante incluant un résultat gagnant et une sortie perdante incluant un résultat perdant. Avantageusement, chaque niveau est associé à au moins un gain. Selon l'invention, un résultat gagnant inclut un gain de toute forme connue tandis qu'un résultat perdant est associé, de façon non limitative à une perte définie comme un gain nul ou l'arrêt d'une partie. De préférence, les gains sont sous forme monétaire. La valeur de gain obtenue à un niveau donné est liée, comme cela sera détaillé plus loin, aux gains potentiels des niveaux suivants. Dans un exemple de réalisation de l'invention, les différents niveaux de l'application correspondent à une arborescence d'un labyrinthe. Chaque niveau peut ainsi comprendre, dans un exemple non limitatif, un ensemble de sorties illustrées soit par une architecture de chemins à suivre soit par des éléments dits gagnants à sélectionner afin d'accéder au niveau suivant et/ou d'obtenir des gains éventuels. Tel que l'illustre la figure 3, l'utilisateur se trouvant sur un premier niveau sélectionne une sortie possible et valide son choix. Cette 10 requête de choix est transmise au serveur de gestion de données via un réseau de communication (E3). Cette requête comprend un certain nombre de champs décrits plus loin en relation avec la figure 4. Le serveur de gestion de données 300 confronte le choix du joueur avec l'ensemble des choix valides qu'il a déjà déterminés automatiquement et aléatoirement lors de l'initialisation ou la réinitialisation du niveau de jeu. Une variante de réalisation de l'invention permet d'envisager que les choix valides du jeu proviennent d'un module extérieur au serveur de 20 gestion de données. Le serveur de gestion de données 300 renvoie le résultat de la confrontation au terminal de communication via le réseau de communication (E4). Deux possibilités s'offrent au niveau du jeu. Soit le résultat dans 25 le tableau de lots, tableau qui sera illustré ci dessous, donne accès au niveau suivant (E5) et le serveur de gestion de données 300 permet d'accéder au niveau suivant. Soit le résultat dans le tableau est l'arrêt de la partie et le résultat final est indiqué au joueur (ES). Le solde de l'utilisateur est alors augmenté en cas de gain ou 30 inchangé en cas de perte (gain nul) et enregistré dans la base de données du serveur (E7). Selon l'invention, chaque niveau de jeu a au moins un choix lui permettant d'accéder au niveau suivant. Pourtant, il n'est pas indispensable d'avoir réalisé un gain pour y accéder. Certains scénarios perdants (gain nul) permettent tout de même de progresser dans le jeu jusqu'au niveau final par requêtes au serveur sauf si le tableau de lot détermine l'arrêt de la partie. Lorsque l'utilisateur accède et visualise sur son écran la représentation d'un second niveau associé à un premier niveau particulier, il fait son choix parmi les sorties prédéterminées et l'information est transmise au serveur 300 via le réseau de communication. Les étapes qui suivent sont identiques aux étapes E5, E6 et E7.Cette démarche est valable pour chaque niveau de jeu jusqu'au niveau final. Selon l'invention, l'utilisateur a également la possibilité de suspendre momentanément sa partie sur simple requête au serveur de gestion de données 300 qui enregistre alors le dernier niveau validé. D'autre part, le nombre de niveaux n'est pas limité et la nature des événements présents à chaque niveau peut faire l'objet de nombreuses variantes de réalisation. La mécanique décrite ci dessus est associée avec un tableau de lot progressif déjà cité permettant de cumuler ses gains à chaque choix 20 gagnant. Selon l'invention, les choix effectués par l'utilisateur à chaque niveau de jeu dépendent les uns des autres. Plus précisément, le résultat enregistré à un niveau de jeu va dépendre des résultats obtenus dans les autres niveaux. Dans un mode de réalisation préféré de l'invention, le résultat d'un niveau de jeu dépendra du résultat obtenu au niveau précédent. D'autre part, pour chaque choix enregistré, le résultat obtenu à chaque niveau est conservé sur le compte de l'utilisateur. Ce qui permet d'éviter de perdre le total de ses gains. L'invention propose en fait une addition de chances permettant un cumul des gains obtenu à chacun des niveaux afin d'atteindre un gain positif éventuel. Le tableau 1 illustre un exemple non limitatif de tableau de lot progressif pour un utilisateur qui a atteint un niveau 2. Le serveur de gestion de données établit pour le second niveau de jeu un tableau de lot qui représente la probabilité des résultats selon le choix fait au premier niveau et plus précisément son résultat. Si l'utilisateur a gagné un euro au niveau 1, la probabilité 5 d'obtenir un gain de cinq euros au niveau deux est de une chance sur dix pour l'utilisateur. Si l'utilisateur a gagné un euro au niveau 1 et perdu au niveau 2, le serveur l'informe de l'arrête de la partie et de son solde qui s'élève alors à un euro. Tableau 1 probabilité 1/10 1/10 8/10 Gain 5 3 0 Pour chaque choix effectué à chaque niveau, la décision de l'utilisateur est archivée par le serveur 300 dans la base de données sur le compte crée en association avec le code d'activation d'un ticket. Sont également enregistrées, de manière non exhaustive, les informations concernant le dernier niveau validé, les tirages et les requêtes reçues depuis le début de la partie. Les différentes décisions aboutissent à un résultat final. Ce résultatfinal est la somme des différents gains cumulés à chaque niveau et enregistrés sur le compte dans la base de données du serveur 300. Selon l'invention, l'utilisateur Peut demander le paiement de ses gains sur un point de vente, à l'aide du ticket de jeu comportant le numéro identifiant. Ce faisant, il n'a pas à déclarer son identité. Le vendeur règle alors une somme d'argent à l'utilisateur par tout moyen approprié, par exemple en liquide, conformément aux informations de gains présentent sur le moyen de présentation. Simultanément, le vendeur récupère le ticket de jeu et envoie l'information du paiement au serveur de gestion de données 300. Le compte est alors clôturé et le code d'activation désactivé. En se référant maintenant à la figure 4, les échanges d'informations principaux entre l'utilisateur 210 et le serveur de gestion de données 300 dans le cadre d'une session d'un utilisateur sont représentés. La définition d'une session dans le cadre de l'invention a été explicitée en relation avec la figure 1. Avantageusement, toutes les sessions sont conservées indéfiniment dans la base de données du serveur de gestion de données. De préférence, les échanges de données utilisateur/serveur sont assurés par un protocole de transmission de données sur le réseau (http) et ces données sont codées en caractères ASCII. D'autres protocoles bien connus de l'homme de l'art peuvent être utilisés pour les échanges de données. Par exemple, une variante de réalisation de l'invention prévoit pour protéger la confidentialité des échanges entre l'utilisateur 210 et le serveur 300 l'usage du protocole sécurisé https. Dans un mode de réalisation préféré de l'invention, chaque requête de l'utilisateur 210 indique: l'identifiant unique de l'application téléchargée, le code d'activation du ticket en cours d'utilisation et l'action demandée. La nature et le nombre de ces indications peuvent faire l'objet de nombreuses variantes de réalisation. D'autre part, on peut citer comme exemples non limitatifs, des requêtes d'utilisateur visant à utiliser un nouveau ticket, à initialiser des 25 niveaux de jeu ou à enregistrer les choix effectués 210 à ces niveaux. Selon la figure 4, la première requête est à l'initiative de l'utilisateur 210. Il demande, par la requête R1, l'initiation d'une partie. Le serveur de gestion de données 300 vérifie la validité du code d'activation du ticket et le solde du compte correspondant dans sa base 30 de données (L1). Le serveur 300 envoie le résultat de la vérification (L2) à l'utilisateur 210. Si le ticket est invalide, il en informe l'utilisateur 210. Si le ticket est valide et le solde suffisant, il informe le terminal du solde actuel du compte associé au code d'activation du ticket et du niveau de démarrage de la partie. Par exemple, le niveau 1 sera indiqué s'il s'agit d'une nouvelle partie. Dans un autre exemple, le niveau N sera indiqué si une partie a été interrompue au cours du niveau N lors de la partie précédente. Le serveur 300 permet ainsi à l'utilisateur 210 de reprendre une partie interrompue précédemment, après le dernier niveau validé. En R2, l'utilisateur 210 demande ainsi l'initialisation du niveau N. 10 Le serveur 300 génère alors aléatoirement les sorties du niveau N (L3) et leurs caractères (gagnant ou perdant), et les envoie à l'utilisateur 210 (L4). Dans un mode de réalisation préféré de l'invention, les données générées correspondent à une nouvelle arborescence d'un jeu de 15 labyrinthe. En R3, à chaque niveau, l'utilisateur 210 fait un choix entre les sorties prédéterminées qui lui sont proposées. Suivant l'illustration qui a été faite de l'invention à la figure 3, l'utilisateur doit choisir entre plusieurs sorties qui, suivant le niveau de jeu atteint, prennent la forme d'un passage à sélectionner parmi plusieurs passages ou encore la forme d'éléments gagnants à sélectionner. Pour un tableau de lots donné, défini par l'utilisateur, une large variété de configurations de sorties prédéterminées associées à chaque 25 niveau et générées par le serveur peuvent être envisagées. D'autre part, le nombre et la nature des niveaux et des sorties peuvent faire l'objet de nombreuses variantes de réalisation. Ils ne sont pas limités aux illustrations données sur les figures annexées. L'utilisateur envoie ensuite, au serveur 300, le choix effectué (R4) entre les différentes sorties. Cette requête R4 valide le niveau N. Le choix de l'utilisateur est verrouillé et stocké définitivement dans la base de données. Toute requête ultérieure indiquant un choix différent sera ignorée. L'application serveur n'autorise aucun accès direct aux données et interdit toute modification d'un choix dès qu'il est validé. Les informations de la base de données serveur feront foi en cas de litige. Une variante de réalisation prévoit que l'utilisateur 210 envoie le 5 choix effectué et demande à consulter les gains éventuels. Le serveur de gestion 300 compare le choix de sortie de l'utilisateur au caractère gagnant ou perdant de cette sortie (L5) Il informe ensuite l'utilisateur 210 si son choix est gagnant et lui envoie le cas échéant le montant du gain. Si son choix est perdant, il lui envoie les données de sorties gagnantes pour le niveau N (L6). L'utilisateur 210 en déduit alors le nouvel état de la partie. Si la partie est terminée, c'est-à-dire qu'il a validé le dernier niveau possible, il met à jour le solde du compte sinon il décide ou non d'accéder au niveau suivant par une nouvelle requête R2. Une large variété d'échanges de données utilisateur/serveur de gestion de données peut être envisagées. D'autre part, le nombre et la nature des requêtes peuvent faire "objet de nombreuses variantes de réalisation. Elles ne sont pas limitées aux illustrations données sur les figures annexées. En particulier, on peut prévoir que l'utilisateur demande le solde du compte si son choix n'est pas gagnant ou encore qu'il envoie une requête pour arrêter momentanément la partie et valider le dernier niveau joué. Pour l'opérateur ou l'administrateur du serveur de gestion de données 300, il est prévu une interface et plus particulièrement une interface web permettant d'interroger la base de données du serveur en consultant les parties, les tirages et les gains associés à un code d'activation particulier. En saisissant lui-même un code particulier, l'opérateur peut vérifier tous les éléments et événements associées à un compte et plus précisément il peut vérifier la chronologie des parties et du solde associés à chaque compte et donc à chaque code d'activation. Une variante de réalisation de l'invention prévoit de présenter dans l'interface des données statistiques sur l'usage des données téléchargées et sur leurs taux de distribution. Bien entendu, la présente invention n'est pas limitée aux modes de réalisation particuliers qui viennent d'être décrits mais s'étend à toute variante conforme à son esprit. En particulier la présente invention n'est pas limitée aux dessins annexés. Les références spécifiques illustrées dans les paragraphes précédents sont des exemples non limitatifs de l'invention. REVENDICATIONS 1. Système de communication comprenant un serveur de gestion de données (300) connecté au moins à un terminal de communication (200), au moins un support (100) présentant un code d'activation, ledit code d'activation étant associé à des données présentes dans des moyens de stockage dudit serveur de gestion de données (300), caractérisé en ce que en réponse audit code d'activation reçu dudit terminal de communication, ledit serveur de gestion de données (300) comprend des moyens aptes à ouvrir au moins un compte auquel est associé un code correspondant audit code d'activation reçu et des moyens aptes à transmettre au moins audit terminal de communication les données associées audit code d'activation. 2. Système selon l'une des revendications précédentes caractérisé en ce que le serveur de gestion de données (300) comprend des moyens aptes à envoyer, en outre, au terminal de communication, un identifiant dédié aux données transmises auquel est associé au moins un code correspondant au code d'activation reçu. 3. Système selon l'une des revendications précédentes caractérisé en ce que le compte ouvert_ correspond à un code d'activation unique. 4. Système selon l'une des revendications précédentes caractérisé en ce que le code d'activation est unique. 5. Système selon l'une des revendications précédentes caractérisé en ce que le code d'activation est une série alphas numériques. 6. Système selon l'une des revendications précédentes caractérisé en ce que le support où est inscrit le code d'activation est un ticket qui comporte, en outre, des moyens de masquage dudit code d'activation. 7. Système selon l'une des revendications précédentes caractérisé en ce que le terminal de communication est un téléphone portable. 8. Système selon l'une des revendications précédentes caractérisé en ce que le compte ouvert est associé au moins à un solde, solde dont la valeur initiale est définie par la valeur de paiement dudit support. 9. Système selon l'une des revendications précédentes caractérisé en ce que les données associées à un code d'activation incluent des applications définissant des jeux et/ou des attributs d'une entité de jeu. 10. Système selon l'une des revendications précédentes caractérisé en ce que les données associées à un code d'activation incluent une application définissant un jeu comportant plusieurs niveaux de jeu. 11. Système selon les revendications 11 et 12 précédentes caractérisé en ce que en outre, le terminal mobile comporte au moins -des moyens de saisie pour entrer des informations de jeu et les envoyer au serveur de gestion de données; et le serveur de gestion de données comporte au moins pour chacun des niveaux de jeu 2:2 - des moyens pour générer plusieurs ensembles d'événements différents, chaque ensemble comprenant au moins un événement associé à un résultat gagnant; - des moyens pour initialiser suite à une information de jeu reçue de l'utilisateur le niveau de jeu; des moyens pour enregistrer sur le compte ouvert au moins les informations de jeux définissant le choix d'un événement parmi les événements d'un ensemble particulier d'événements généré lors de l'initialisation et/ou le résultat associé aux informations de jeu choisies par le terminal de communication, le résultat d'un niveau de jeu étant dépendant des résultats des autres niveaux. 12.Système selon la revendication précédente caractérisé en ce le résultat d'un niveau de jeu autre que le premier niveau de jeu est dépendant des résultats de niveaux précédents. 13.Système selon l'une des revendications 11 à 12 précédentes caractérisé en ce les résultats des niveaux de jeu sont dépendants de la mise initiale du jeu. 14.Système selon l'une des revendications 11 à 13 précédentes caractérisé en ce que le serveur de gestion de données comporte en outre des moyens pour cumuler les différents résultats des différents niveaux sur le solde du compte ouvert. 15. Procédé de communication à l'aide d'un serveur de gestion de données (300) connecté au moins à un terminal de communication (200) et d' au moins un support (100) présentant un code d'activation, ledit code d'activation étant associé à des données présentes dans des moyens de stockage dudit serveur de gestion de données 2.3 (300), caractérisé en ce que ledit serveur de gestion de données (300) , en réponse audit code d'activation reçu dudit terminal de communication, ouvre au moins un compte auquel est associé un code correspondant audit code d'activation reçu et transmet audit terminal de communication les données associées audit code d'activation. 16. Procédé selon la revendication 15 précédente caractérisé en ce que le serveur de gestion de données (300) ouvre au moins un compte auquel est associé un code correspondant audit code d'activation reçu et transmet audit terminal de communication les données associées audit code d'activation si ces données n'ont pas été transmises auparavant à un autre terminal de communication particulier. 17. Procédé selon l'une des revendications 15 à 16 précédentes caractérisé en ce que le serveur de gestion de données (300) ouvre au moins un compte auquel est associé un code correspondant audit code d'activation reçu avant de transmettre audit terminal de communication les données associées audit code d'activation. 18. Procédé selon l'une des revendications 15 à 17 précédentes caractérisé en ce que le serveur de gestion de données (300) envoie, en outre, au terminal de communication, un identifiant dédié aux données transmises auquel est associé au moins un code correspondant au code d'activation reçu. 19. Procédé selon l'une des revendications 15 à 18 précédentes caractérisé en ce que le compte ouvert correspond à un code d'activation unique. 20. Procédé selon l'une des revendications 15 à 19 précédentes caractérisé en ce que le code d'activation est unique. 21. Procédé selon l'une des revendications 15 à 20 précédentes caractérisé en ce que le code d'activation est une série alphas numériques. 22. Procédé selon l'une des revendications 15 à 21 précédentes caractérisé en ce que le support où est inscrit le code d'activation est un ticket qui comporte, en outre, des moyens de masquage dudit code d'activation. 23. Procédé selon l'une des revendications 15 à 22 précédentes en ce que le terminal de communication est un téléphone portable. 24.Procédé selon l'une des revendications 15 à 23 précédentes caractérisé en ce que le compte ouvert comprend au moins un solde, solde dont la valeur initiale est définie par la valeur de paiement dudit support. 25. Procédé selon l'une des revendications 15 à 24 précédentes caractérisé en ce que les données associées à un code d'activation incluent des applications définissant des jeux et/ou des attributs d'une entité de jeu. 26. Procédé selon l'une des revendications 15 à 25 précédentes caractérisé en ce que les données associées à un code d'activation incluent une application définissant un jeu de chance comportant plusieurs niveaux de jeu. 27. Procédé selon l'une des revendications 15 à 26 précédentes caractérisé en ce que le terminal mobile saisit des informations de jeu et les envoie au serveur de gestion de données; le serveur de gestion de données, pour chacun des niveaux de jeu, - génère plusieurs ensembles d'événements différents, chaque ensemble comprenant au moins un événement associé à un résultat gagnant; - initialise suite à une information de jeu reçue de l'utilisateur le niveau de jeu; - enregistre sur le compte ouvert au moins les informations de jeux définissant le choix d'un événement parmi les événements d'un ensemble particulier d'événements généré lors de l'initialisation et/ou le résultat associé aux informations de jeu choisies par le terminal de communication, le résultat d'un niveau de jeu étant dépendant des résultats des autres niveaux. 28.Procédé selon l'une des revendications 15 à 27 précédentes caractérisé en ce le résultat d'un niveau de jeu autre que le premier niveau de jeu esi: dépendant des résultats niveaux précédents. 29.Procédé selon l'une des revendications 15 à 28 précédentes caractérisé en ce les résultats des niveaux de jeu sont dépendants de la mise initiale du jeu. 30.Procédé selon l'une des revendications 15 à 29 précédentes caractérisé en ce que le serveur de gestion de données cumule les différents résultats des différents niveaux sur le solde du compte ouvert. 31. Serveur de gestion de données pour la mise en oeuvre du système de communication selon l'une des revendications 1 à 14. 32. Support pour la mise en oeuvre du système de communication selon l'une des revendications 1 à 14.