FR 3029721 A1 20160610 FR 1462118 A 20141209 1 DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine de la monétique. Plus précisément, elle concerne un précédé de mise en oeuvre d'une transaction par téléphone mobile. ETAT DE L'ART Que ce soit en véhicule personnel ou en transports en commun, se déplacer nécessite le paiement à intervalles régulier de petites sommes forfaitaires : en véhicule personnel il s'agit le plus souvent de péages ou de parkings, et en transports en commun il s'agit de tickets. Dans un cas comme dans l'autre, des guichets et aujourd'hui des bornes automatiques permettent de réaliser la transaction et de percevoir 15 ces sommes. Les bornes automatiques sont généralement des automates pouvant recevoir des pièces de monnaie, des billets ou des cartes bancaires. Alternativement ou en complément, les bornes peuvent accepter des cartes d'abonnement (en particulier des cartes sans contact NFC) qui déclenchent 20 un paiement par exemple mensuel pour un utilisateur associé, de sorte à affranchir ce dernier de payer à chaque fois qu'il prend le transport. Ce paiement « dématérialisé » simplifie et accélère la transaction, ce qui est important au vu du nombre important d'usagers quotidiens des moyens de transports concernés. 25 On connait également des moyens de paiement via terminal mobile de type smartphone, qui permettent le paiement dématérialisé en évitant la nécessité de posséder une carte dédiée. Connectés à internet, ces smartphones établissent une communication sans fil avec la borne (ou alternativement affichent un code-barre de type QR code que la borne peut 30 lire) de sorte à authentifier l'utilisateur et déclencher un paiement en ligne. Les méthodes de paiement par smartphone apportent satisfaction mais ne sont pas encore accessibles à tous puisqu'elles nécessitent la 3029721 2 possession d'un terminal mobile récent et couteux. De nombreux utilisateurs disposent en effet toujours d'un simple terminal de type GSM sans accès à internet et avec un écran basique. De plus les méthodes de paiement par smartphone ne sont pas possibles si la qualité du réseau est 5 insuffisante, et restent par conséquent complètement impossibles dans certaines régions du monde. Il serait par conséquent souhaitable de disposer d'une méthode de paiement dématérialisé qui s'affranchisse des difficultés ci-dessus et permette un paiement dématérialisé qui soit facile, sécurisé, et sans 10 contraintes techniques. PRESENTATION DE L'INVENTION La présente invention se rapporte ainsi selon un premier aspect à un procédé de mise en oeuvre d'une transaction via un terminal mobile connecté à un réseau opérateur, caractérisé en ce qu'il comprend des étapes de : (a) Emission depuis le terminal à destination d'un serveur du réseau opérateur d'une requête contenant des informations d'identification du terminal ; (b) Génération par le serveur d'un jeton de paiement en fonction de données associées au terminal stockées dans une base de données du serveur ; (c) Transcription sonore du jeton par le serveur en un signal sonore transmis au terminal ; (d) Emission dudit signal sonore par un haut-parleur du terminal de sorte à être capté par des moyens de captation sonore d'un équipement de paiement ; (e) Transcription inverse du signal sonore par un module de traitement de l'équipement en le jeton de paiement ; 3029721 3 (f) Vérification du jeton par le module de traitement, et autorisation de la transaction en fonction du résultat de la vérification. 5 Selon d'autres caractéristiques avantageuses et non limitatives : - l'étape (b) comprend l'horodatage du jeton par le serveur, l'étape (f) comprenant la comparaison dudit horodatage avec l'heure actuelle ; - l'étape (b) comprend le chiffrement du jeton par le serveur avec une clé publique de l'équipement de paiement, l'étape (f) comprenant le 10 déchiffrement préalable du jeton par le module de traitement avec une clé privée de l'équipement de paiement ; - l'étape (b) comprend en outre le chiffrement du jeton par le serveur avec une clé privée de l'opérateur, l'étape (f) comprenant le déchiffrement préalable du jeton par le module de traitement avec une clé publique de 15 l'opérateur ; - l'étape (b) comprend le préfixage du jeton chiffré avec un identifiant de l'opérateur, l'étape (f) comprenant l'extraction dudit identifiant de l'opérateur par le module de traitement de sorte à choisir la clé publique pour le déchiffrement du jeton ; 20 - lesdites informations d'identification du terminal comprennent un numéro de téléphone du terminal ; - l'étape (a) consiste en la composition d'un numéro de téléphone du serveur de sorte à établir une communication téléphonique entre le terminal et le serveur ; 25 - l'étape (b) est mise en oeuvre suite à l'appui sur une touche prédéterminée du terminal (1) pendant ladite conversation téléphonique ; - les données associées au terminal stockées dans la base de données du serveur sont représentatives d'un compteur de jetons restants, l'étape (b) étant mise en oeuvre seulement si ledit compteur présente une valeur 30 non nulle, l'étape (b) comprenant le cas échéant le décrément dudit compteur ; 3029721 4 - l'étape (f) comprend la comparaison du jeton avec une liste de jetons expirés, le procédé comprenant une étape (g) d'ajout dudit jeton vérifié à ladite liste de jetons expirés ; - l'équipement est connecté au serveur via le réseau internet, le procédé 5 comprenant une étape (h) d'émission d'un compte-rendu de transaction à destination du serveur ; - l'étape (f) comprend l'activation d'un élément mécanique de l'équipement si la transaction est autorisée ; - l'élément mécanique est choisi parmi une barrière mobile et une 10 imprimante. Selon un deuxième aspect, l'invention concerne un équipement de paiement, comprenant un module de traitement de données et des moyens de captation sonore, caractérisé en ce que le module de traitement de 15 données est configuré pour mettre en oeuvre, suite à l'initiation d'une transaction depuis un terminal mobile comprenant un haut-parleur : - Un module de réception d'une transcription sonore d'un jeton de paiement associé au terminal en un signal sonore émis par le haut- parleur et capté par les moyens de captation sonore ; 20 - Un module de transcription inverse du signal sonore en le jeton de paiement ; - Un module de vérification du jeton, et d'autorisation de la transaction en fonction du résultat de la vérification. 25 Selon un troisième aspect, l'invention concerne un système de mise en oeuvre de transaction comprenant au moins un équipement de paiement selon le deuxième aspect de l'invention et au moins un serveur du réseau opérateur, le serveur étant configuré pour générer un jeton de paiement, sur requête contenant des informations d'identification d'un terminal, en fonction 30 de données associées au terminal stockées dans une base de données du serveur, et mettre en oeuvre une transcription sonore du jeton en un signal sonore transmis au terminal. 3029721 5 Selon un quatrième et un cinquième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour 5 l'exécution d'un procédé selon le premier aspect de l'invention de mise en oeuvre d'une transaction via un terminal mobile ; et un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon le premier aspect de mise en oeuvre d'une transaction via un 10 terminal mobile. PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention 15 apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma d'une architecture de réseau pour la mise en oeuvre du procédé selon l'invention ; 20 - la figure 2 illustre le crédit d'un compteur de jetons de paiement par un utilisateur ; - la figure 3 représente la mise en oeuvre d'un mode de réalisation préféré du procédé selon l'invention ; - la figure 4 illustre une étape finale d'un mode de réalisation préféré 25 du procédé selon l'invention. DESCRIPTION DETAILLEE Architecture 30 En référence aux dessins et en particulier à la figure 1, l'invention concerne un procédé de mise en oeuvre d'une transaction via un terminal 3029721 6 mobile 1 connecté à un réseau opérateur 21. Le réseau opérateur 21 peut être n'importe quel réseau de téléphonie mobile, en particulier un réseau d'ancienne génération (2G) de type GSM (« Global System for Mobile Communications ») ou EDGE (« Enhanced Data Rates for GSM 5 Evolution »), même s'il est tout à fait possible que ce soit un réseau plus récent et plus puissant de type 3G ou 4G. Le réseau opérateur 21 comprend au moins un serveur 2 de l'opérateur de téléphonie mobile et est connecté au réseau internet 20. On comprendra qu'il peut y avoir plusieurs réseaux 21 de divers 10 opérateurs, chacun possédant son propre serveur 2, de sorte à permettre la mise en oeuvre du procédé quel que soit l'opérateur de l'utilisateur. De façon similaire au réseau opérateur 21, le terminal mobile 1 peut être n'importe quel terminal apte à se connecter au réseau 21, y compris des anciens téléphones portables ne disposant pas de fonctionnalités 15 complexes (par opposition aux smartphones) ou des terminaux partiellement cassés. En particulier, il suffit que le terminal 1 permette une conversation téléphonique (et donc qu'il comprenne un haut-parleur 10) pour que le présent procédé puisse être mis en oeuvre, et il n'est par exemple pas nécessaire qu'il dispose d'une connexion à internet, d'une 20 connectivité Wi-Fi, ni même d'un écran. Le présent procédé vise à permettre une transaction entre l'utilisateur du terminal 1 et un équipement de paiement 3. Par transaction, on entend transmission d'informations suffisantes pour prouver informatiquement un 25 paiement de la part de l'utilisateur, de sorte à débloquer un service au niveau de l'équipement 3. En particulier, ce dernier comprend un élément mécanique 32, qui est activé lorsque la transaction est autorisée. L'équipement 3 peut ainsi être par exemple un terminal de paiement de type POS (l'élément mécanique 32 est alors une imprimante qui imprime un 30 reçu), un valideur (l'élément mécanique 32 est une barrière mobile empêchant de rentrer aux utilisateurs non-autorisés), etc. Par valideur, on entend un dispositif permettant de vérifier qu'un utilisateur a bien payé un 3029721 7 accès à une prestation (parking, cinéma, bibliothèque, parc, etc.), notamment un mode de transport (portique de métro, péage, etc.). Dans la suite de la présente description, on prendra l'exemple du péage, l'élément 32 étant ainsi la barrière du péage qui s'ouvre quand l'utilisateur a payé son 5 accès. Dans tous les cas, il suffit que le présent équipement 3 comprenne un module de traitement de données 30 tel qu'un processeur, éventuellement un module de stockage de données tel qu'une mémoire (exemple d'un disque dur), et des moyens de captation sonore 31. 10 Les moyens de captation sonore 31 consistent au moins en un microphone capable d'acquérir un son, éventuellement placé dans une enceinte adaptée pour favoriser la réception du son (en termes d'intensité et de clarté). 15 Le système comprend en outre un serveur 2 du réseau opérateur 21 (capable de communiquer avec le terminal 1), le serveur étant avantageusement également connecté au réseau internet 20. Le serveur 2 est ici l'élément principal dans la mise en oeuvre de la transaction. Il comprend des moyens de traitement de données tel qu'un processeur et 20 des moyens de stockage de données tels qu'une mémoire. Le serveur 2 stocke ainsi une base de données relatives aux abonnés de l'opérateur, chaque utilisateur étant identifié via son terminal 1 (en particulier le numéro de téléphone de ce terminal, mais alternativement une adresse MAC, IMEI, etc.). Ces données permettent de déterminer si l'utilisateur du terminal a le 25 droit de mettre en oeuvre la transaction. Elles peuvent être représentatives d'un solde en une monnaie, ou bien d'un compteur de « jetons restants », appelés également « tickets ». Les tickets représentent un bon prépayé pour la transaction. Ils sont particulièrement utiles si le terminal 1 est utilisé pour mettre en oeuvre de 30 façon récurrente une transaction d'un prix constant, telle que le paiement du péage ou d'un accès dans les transports en commun. Un ticket est 3029721 8 consommé (sous forme d'un jeton, lequel sera décrit plus loin) à chaque fois que la mise en oeuvre de la transaction est requise. En référence à la figure 2, les tickets peuvent être acquis avant la mise en oeuvre du présent procédé, d'une pluralité de façon. Par exemple, il 5 peut acheter des tickets sur internet depuis un ordinateur, depuis son téléphone en composant un numéro de l'opérateur (les tickets sont alors facturés avec sa facture d'abonnement téléphonique), en boutique via des cartes prépayées (une zone à gratter dévoile un code, saisi sur le téléphone), etc. 10 Chacune des actions ci-dessus incrémente son compteur de jetons restants (ou crédite son solde d'un montant prédéterminé si les données sont sous cette forme) au niveau du serveur 2 de l'opérateur. Mise en oeuvre du procédé 15 En référence à la figure 3, le présent procédé commence par une étape (a) d'émission depuis le terminal 1 à destination d'un serveur 2 du réseau opérateur 21 d'une requête contenant des informations d'identification du terminal 1. Comme expliqué, ces dernières sont 20 typiquement le numéro de téléphone du terminal 1, mais d'autres possibilités existent (adresse MAC, IMEI, etc.). La requête peut prendre une pluralité de formes, mais de façon préférée elle consiste en un appel téléphonique à un numéro de téléphone du serveur 2. On citera également l'envoi d'un message de type SMS 25 (« Short Message Service ») à un tel numéro de téléphone du serveur 2. Ces deux techniques fonctionnent pour n'importe quel type de réseau opérateur 21 et de terminal 1, y compris les plus anciens, et permettent automatiquement de véhiculer le numéro de téléphone du terminal 1. Dans la suite de la présente description, on prendra l'exemple de 30 l'appel. Ainsi, à l'issue de l'étape (a), une communication téléphonique entre le terminal 1 et le serveur 2 sont établies. 3029721 9 Suit alors une deuxième étape (b) de génération par le serveur 2 d'un jeton de paiement en fonction de données associées au terminal 1 stockées dans une base de données du serveur 2. Il est à noter que cette étape (b) peut être déclenchée suite à l'appui 5 sur une touche prédéterminée du terminal 1 pendant ladite conversation téléphonique. En particulier comme l'on voit sur la figure 3, le serveur 2 peut répondre au terminal 1 (par exemple via un message vocal préenregistré) en lui indiquant une touche à presser pour continuer le procédé. Cela à de multiples avantages : cela permet d'accuser bonne réception de la 10 demande de transaction, d'instaurer une validation supplémentaire (l'utilisateur peut avoir composé le numéro par erreur. S'il n'appuie pas sur la touche, le procédé ne sera jamais poursuivi), et de permettre à l'utilisateur de choisir avec précision le moment de déclenchement de l'étape (b). On verra pourquoi un peu plus loin. 15 Par « jeton » on entend un élément informatique sécurisé représentatif d'un ticket, i.e. un code unique compréhensible de l'équipement 3 comme la preuve de la capacité de l'utilisateur à mettre en oeuvre la transaction. Plus précisément, le jeton n'est généré que si lesdites données associées au terminal 1 stockées dans une base de données sont 20 représentatives d'un solde suffisant ou d'un compteur de jetons restant non nul. Lesdites données sont alors modifiées, par exemple en décrémentant le compteur. Alternativement, dans le cas d'un abonnement où l'utilisateur peut utiliser l'équipement 3 à volonté, par exemple une carte de métro ou un badge de péage, il suffit que les données soit représentatives de la 25 possession de cet abonnement (les données ne sont pas modifiées suite à la génération du jeton dans ce cas). Une telle génération est connue de l'homme du métier. On comprendra qu'elle comprend par exemple la génération d'un code unique (et éventuellement son horodatage, i.e. l'adjonction d'un code représentatif 30 de l'heure de génération), et son chiffrement pour des raisons de sécurité. En particulier, l'étape (b) peut comprendre un premier chiffrement du jeton par le serveur 2 avec une clé publique de l'équipement de paiement 3, 3029721 10 et/ou un deuxième chiffrement du jeton par le serveur 2 avec une clé privée de l'opérateur. Dans le cas de ce deuxième chiffrement, il est souhaitable de préfixer le jeton chiffré avec un identifiant de l'opérateur pour permettre son déchiffrement ultérieur (on verra comment plus loin). 5 A ce stade, le procédé comprend une étape (c) de transcription sonore du jeton (chiffré) par le serveur 2 en un signal sonore transmis au terminal 1. En d'autres termes, le serveur 2 va convertir les données binaires du jeton en un signal représentatif d'un son, par exemple en utilisant les fréquences vocales (Code DTMF, « dual-tone multi-frequency », 10 qui associe à chaque caractère hexadécimal (i.e. chaque groupe de quatre bits) un couple de fréquences audibles qui sont jouées simultanément). Ces fréquences peuvent être reconnues par des dispositifs électroniques et sont couramment utilisées pour réaliser des serveurs vocaux. Ce signal sonore peut alors être émis dans une étape (d) par un 15 haut-parleur 10 du terminal 1 de sorte à être capté par les moyens de captation sonore 31 de l'équipement de paiement 3. Il suffit par exemple que l'utilisateur tende son téléphone au niveau du péage. Cette utilisation du son rend possible la mise en oeuvre du procédé avec n'importe quel terminal disposant seulement de la fonction « téléphoner ». Nulle fonction 20 NFC, internet, écran haute définition, etc. n'est requise. De même il suffit que le réseau 21 soit basique (et autorise la voix). On comprendra qu'il est également possible pour des questions d'efficacité, si le réseau 21 autorise les données internet, de transmettre le signal sonore sous forme d'un fichier son par exemple de type mp3. 25 Cette technique sonore est connue, on citera par exemple la demande W02011/010052 qui l'utilise dans un autre cadre (ouvrir un verrou). L'étape (e) subséquente consiste en la transcription inverse du signal sonore par un module de traitement 30 de l'équipement 3 en le jeton de 30 paiement, par exemple par reconnaissance des fréquences. 3029721 11 Le jeton est alors vérifié, c'est-à-dire traité en vue de dernier sa validité, par le module de traitement 30 dans l'étape (f). Pour cela, il est déchiffré si nécessaire. L'extraction de l'identifiant de l'opérateur (qui a été est préfixé) 5 permet de choisir une clé publique de l'opérateur (parmi une pluralité de clés publiques associées à divers opérateurs) pour un premier déchiffrement du jeton avec cette clé publique de l'opérateur (ce premier déchiffrement est l'opération inverse du deuxième chiffrement avec la clé privée de l'opérateur). 10 Ensuite, un deuxième déchiffrement est mis en oeuvre avec une clé privée de l'équipement 3 (ce deuxième déchiffrement est l'opération inverse du premier chiffrement avec la clé publique de l'équipement 3). Il s'agit ici du meilleur moyen de sécurisation car cette clé privée de l'équipement 3 ne peut être connue par un tiers qui intercepterait le jeton est tenterait de 15 l'utiliser frauduleusement. Une fois que le jeton est complètement déchiffré, son code est vérifié, par exemple en utilisant un algorithme vérifiant une propriété mathématique. De façon préférée, le jeton est « auto-portant », c'est-à-dire qu'il contient toutes les informations nécessaires à sa validation. 20 Alternativement ou en complément, le jeton peut être comparé avec une liste de jetons expirés, i.e. déjà utilisés (et doit en être absent pour que sa validité soit confirmée). Si le jeton a été horodaté, l'étape (f) comprend également la comparaison de l'horodatage avec l'heure actuelle. En effet, il est 25 souhaitable de définir une durée d'expiration des jetons générés et joués (par exemple une minute), de sorte à prévenir encore davantage un emploi frauduleux des jetons (cas de quelqu'un qui enregistrerait le son joué pour le rejouer ultérieurement). Ce mode de réalisation rend très l'utile le fait que l'étape (b) soit conditionné à l'appui sur une touche. Cela permet de ne 30 générer le jeton que lorsque l'utilisateur est prêt et en position (terminal 1 orienté vers les moyens de captation 31), de sorte à permettre une fenêtre de validité du jeton la plus courte possible. 3029721 12 Si le jeton est vérifié, alors la transaction est autorisée. Cela entraîne le cas échéant une réaction de la part de l'équipement 3, en particulier un actionnement de l'élément 32. Dans le cas d'un péage, la barrière mobile du péage est levée et l'utilisateur peut avancer. Un ticket peut être imprimé 5 également. Si le module de traitement de données 30 utilise une liste de jetons expirés, alors le procédé comprend une étape (g) d'ajout dudit jeton vérifié à ladite liste de jetons expirés. On note que le module de traitement de données 30 peut alternativement utiliser une liste de jetons autorisés : lors 10 de la vérification, le module 30 vérifie que le jeton est conforme et qu'il est bien présent dans cette liste, l'étape (g) consiste alors en lasuppression dudit jeton vérifié de la liste de jetons autorisés. Facturation et gestion des jetons utilisés 15 A ce stade, l'équipement de paiement 3 a autorisé la transaction, mais son paiement n'a à proprement parler pas encore été effectué. En effet, c'est l'opérateur du réseau 21 qui a reçu le paiement, et ce dernier doit gérer un transfert vers le propriétaire de l'équipement 3. 20 Pour cela, le procédé comprend avantageusement une étape (h), illustrée par la figure 4, d'émission d'un compte-rendu de transaction à destination du serveur 2. Ceci est possible si l'équipement 3 est connecté au serveur 2 via le réseau internet 20. Cette étape (h) n'est pas nécessairement dans la foulée du reste du 25 procédé, et peut par exemple être mise en oeuvre de façon périodique, par exemple tous les soirs, de sorte à transmettre l'ensemble des compte-rendu de transaction de la journée. Cette étape a deux objectifs : indiquer au serveur 2 quels jetons ont effectivement été consommés (le serveur 2 tient avantageusement sa 30 propre liste de jetons autorisés, et les jetons effectivement consommés en seront supprimés), et facturer l'opérateur téléphonique de sorte à obtenir le paiement des transactions conduites. 3029721 13 Plateforme et système 5 Selon un deuxième aspect, l'invention concerne en particulier l'équipement de paiement 3 utilisé pour la mise en oeuvre du présent procédé. Comme expliqué précédemment, l'équipement de paiement 3 comprend un module de traitement de données 30 et des moyens de 10 captation sonore 31 (et le cas échéant un élément mécanique 32). Son module de traitement de données 30 est configuré pour mettre en oeuvre, suite à l'initiation d'une transaction depuis un terminal mobile 1 comprenant un haut-parleur 10 : - Un module de réception d'une transcription sonore d'un jeton de 15 paiement associé au terminal 1 en un signal sonore émis par le haut- parleur 30 et capté par les moyens de captation sonore 31 ; - Un module de transcription inverse du signal sonore en le jeton de paiement ; - Un module de vérification du jeton (comprenant le cas échéant le 20 déchiffrement du jeton), et d'autorisation de la transaction en fonction du résultat de la vérification. Selon un troisième aspect, est proposé le système de mise en oeuvre de transaction. Il comprend au moins un équipement de paiement 3 tel que 25 décrit, et au moins un serveur 2 du réseau opérateur 21. Comme expliqué, le serveur 2 est configuré pour générer un jeton de paiement, sur requête contenant des informations d'identification d'un terminal 1, en fonction de données associées au terminal 1 stockées dans une base de données du serveur 2, et mettre en oeuvre une transcription 30 sonore du jeton en un signal sonore transmis au terminal 1. Le système peut également comprendre le ou les terminaux 1 3029721 14 Produit programme d'ordinateur Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour 5 l'exécution (sur des moyens de traitement en particulier du serveur 2, mais également de l'équipement 3, i.e. le module 30) d'un procédé de mise en oeuvre d'une transaction via un terminal mobile 1 selon le premier aspect de l'invention, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple une mémoire de l'équipement 3) sur lequel on 10 trouve ce produit programme d'ordinateur. REVENDICATIONS1. Procédé de mise en oeuvre d'une transaction via un terminal mobile (1) connecté à un réseau opérateur (21), caractérisé en ce qu'il comprend des étapes de : (a) Emission depuis le terminal (1) à destination d'un serveur (2) du réseau opérateur (21) d'une requête contenant des informations d'identification du terminal (1) ; (b) Génération par le serveur (2) d'un jeton de paiement en fonction de données associées au terminal (1) stockées dans une base de données du serveur (2) ; (c) Transcription sonore du jeton par le serveur (2) en un signal sonore transmis au terminal (1) ; (d) Emission dudit signal sonore par un haut-parleur (10) du terminal (1) de sorte à être capté par des moyens de captation sonore (31) d'un équipement de paiement (3) ; (e) Transcription inverse du signal sonore par un module de traitement (30) de l'équipement (3) en le jeton de paiement ; (f) Vérification du jeton par le module de traitement (30), et autorisation de la transaction en fonction du résultat de la vérification. 2. Procédé selon la revendication 1, dans lequel l'étape (b) comprend l'horodatage du jeton par le serveur (2), l'étape (f) comprenant la comparaison dudit horodatage avec l'heure actuelle. 3. Procédé selon l'une des revendications 1 et 2, dans lequel l'étape (b) comprend le chiffrement du jeton par le serveur (2) avec une clé publique de l'équipement de paiement (3), l'étape (f) comprenant le 3029721 16 déchiffrement préalable du jeton par le module de traitement (30) avec une clé privée de l'équipement de paiement (3). 4. Procédé selon la revendication 3, dans lequel l'étape (b) 5 comprend en outre le chiffrement du jeton par le serveur (2) avec une clé privée de l'opérateur, l'étape (f) comprenant le déchiffrement préalable du jeton par le module de traitement (30) avec une clé publique de l'opérateur. 5. Procédé selon la revendication 4, dans lequel l'étape (b) 10 comprend le préfixage du jeton chiffré avec un identifiant de l'opérateur, l'étape (f) comprenant l'extraction dudit identifiant de l'opérateur par le module de traitement (30) de sorte à choisir la clé publique pour le déchiffrement du jeton. 15 6. Procédé selon l'une des revendications 1 à 5, dans laquelle lesdites informations d'identification du terminal (1) comprennent un numéro de téléphone du terminal (1). 7. Procédé selon la revendication 6, dans lequel l'étape 20 (a) consiste en la composition d'un numéro de téléphone du serveur (2) de sorte à établir une communication téléphonique entre le terminal (1) et le serveur (2). 8. Procédé selon la revendication 7, dans lequel l'étape (b) 25 est mise en oeuvre suite à l'appui sur une touche prédéterminée du terminal (1) pendant ladite conversation téléphonique. 9. Procédé selon l'une des revendications 1 à 8, dans lequel les données associées au terminal (1) stockées dans la base de 30 données du serveur (2) sont représentatives d'un compteur de jetons restants, l'étape (b) étant mise en oeuvre seulement si ledit compteur 3029721 17 présente une valeur non nulle, l'étape (b) comprenant le cas échéant le décrément dudit compteur. 10. Procédé selon l'une des revendications 1 à 9, dans 5 lequel l'étape (f) comprend la comparaison du jeton avec une liste de jetons expirés, le procédé comprenant une étape (g) d'ajout dudit jeton vérifié à ladite liste de jetons expirés. 11. Procédé selon l'une des revendications 1 à 10, dans 10 lequel l'équipement (3) est connecté au serveur (2) via le réseau internet (20), le procédé comprenant une étape (h) d'émission d'un compte-rendu de transaction à destination du serveur (2) 12. Procédé selon l'une des revendications 1 à 11, dans 15 lequel l'étape (f) comprend l'activation d'un élément mécanique (32) de l'équipement (3) si la transaction est autorisée. 13. Procédé selon la revendication 12, dans lequel l'élément mécanique (32) est choisi parmi une barrière mobile et une 20 imprimante. 14. Equipement de paiement (3), comprenant un module de traitement de données (30) et des moyens de captation sonore (31), caractérisé en ce que le module de traitement de données (30) est 25 configuré pour mettre en oeuvre, suite à l'initiation d'une transaction depuis un terminal mobile (1) comprenant un haut-parleur (10) : Un module de réception d'une transcription sonore d'un jeton de paiement associé au terminal (1) en un signal sonore émis par le haut-parleur (30) et capté par les moyens de captation sonore (31) ; 30 Un module de transcription inverse du signal sonore en le jeton de paiement ; 3029721 18 - Un module de vérification du jeton, et d'autorisation de la transaction en fonction du résultat de la vérification. 5 15. Système de mise en oeuvre de transaction comprenant au moins un équipement de paiement (3) selon la revendication 14 et au moins un serveur (2) du réseau opérateur (21), le serveur (2) étant configuré pour générer un jeton de paiement, sur requête contenant des 10 informations d'identification d'un terminal (1), en fonction de données associées au terminal (1) stockées dans une base de données du serveur (2), et mettre en oeuvre une transcription sonore du jeton en un signal sonore transmis au terminal (1). 15 16. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de mise en oeuvre d'une transaction via un terminal mobile (1) selon l'une des revendications 1 à 13 lorsque ledit programme est exécuté sur un ordinateur.. 20 17. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé de mise en oeuvre d'une transaction via un terminal mobile (1) selon l'une des revendications 1 à 13. 25