FR3051276A1 - Procedes de mise en oeuvre d'une transaction via un terminal mobile - Google Patents

Abstract

La présente invention concerne un procédé de mise en œuvre 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), et transmission au terminal mobile (1) ; (c) Transcription optique du jeton en un signal optique ; (d) Affichage dudit signal optique par un écran (10) du terminal (1) de sorte à être capté par des moyens d'acquisition optique (31) d'un équipement de paiement (3) ; (e) Transcription inverse du signal optique 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.

Description

Procédés de mise en œuvre d’une transaction via un terminal mobile

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 œuvre 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 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 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.

On connaît é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 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 possession d’un terminal mobile récent et coûteux. 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 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 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, et transmission au terminal ; (c) Transcription optique du jeton en un signal optique ; (d) Affichage dudit signal optique par un écran du terminal de sorte à être capté par des moyens d’acquisition optique d’un équipement de paiement ; (e) Transcription inverse du signal optique par un module de traitement de l’équipement en le jeton de paiement ; (f) Vérification du jeton par le module de traitement, et autorisation de la transaction en fonction du résultat de la vérification.

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 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 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 ; • 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 ; • l’étape (b) est mise en œuvre 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 œuvre seulement si ledit compteur présente une valeur non nulle, l’étape (b) comprenant le cas échéant le décrément dudit compteur ; • 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é 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 imprimante.

Selon un deuxième aspect, l’invention concerne un équipement de paiement, comprenant un module de traitement de données et des moyens d’acquisition optique, caractérisé en ce que le module de traitement de données est configuré pour mettre en œuvre, suite à l’initiation d’une transaction depuis un terminal mobile comprenant un écran : - Un module de réception d’une transcription optique d’un jeton de paiement associé au terminal en un signal optique affiché par l’écran et capté par les moyens d’acquisition optique ; - Un module de transcription inverse du signal optique 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.

Selon un troisième aspect, l’invention concerne un système de mise en œuvre 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 de données associées au terminal stockées dans une base de données du serveur.

Selon un quatrième et un cinquième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de l’invention de mise en œuvre 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 œuvre d’une transaction via un terminal mobile.

PRESENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention 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 œuvre du procédé selon l’invention ; - 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 œuvre 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é du procédé selon l’invention.

DESCRIPTION DETAILLEE

Architecture

En référence aux dessins et en particulier à la figure 1, l’invention concerne un procédé de mise en œuvre d’une transaction via un terminal 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 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 opérateurs, chacun possédant son propre serveur 2, de sorte à permettre la mise en œuvre 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 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 présente un écran basique 10 pour que le présent procédé puisse être mis en œuvre. L’écran 10 n’a pas besoin d’être en couleur ou d’avoir une résolution élevée, il peut être très pixellisé et à simples cristaux liquides (écran des premières générations de téléphones mobiles).

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 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 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 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 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 d’acquisition optique 31.

Les moyens d’acquisition optique 31 consistent notamment en une caméra adaptée pour prendre des images d’un objet placé en face. La caméra peut être binaire (noir et blanc), et c’est même avantageux.

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 œuvre de la transaction. Il comprend des moyens de traitement de données tel qu’un processeur et 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 droit de mettre en œuvre 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 œuvre de 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 consommé (sous forme d’un jeton, lequel sera décrit plus loin) à chaque fois que la mise en œuvre de la transaction est requise.

En référence à la figure 2, les tickets peuvent être acquis avant la mise en œuvre du présent procédé, d’une pluralité de façon. Par exemple, il 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.

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 œuvre du procédé

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 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 (« 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. La requête peut également être envoyée par une application si le réseau 21 est plus récent.

Dans la suite de la présente description, on prendra l’exemple de l’appel. Ainsi, à l’issue de l’étape (a), une communication téléphonique entre le terminal 1 et le serveur 2 sont établies.

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

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 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 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 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, 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). Le jeton est alors transmis au terminal mobile 1. A ce stade, le procédé comprend une étape (c) de transcription optique du jeton (chiffré) par le terminal 1 en un signal optique. En d’autres termes, le terminal 1 va convertir les données binaires du jeton en un signal représentatif d’un objet visuel, avantageusement un code QR, c’est-à-dire un code matriciel en noir et blanc qui peut être affiché sur n’importe quel écran même très sommaire. Alternativement, Le signal optique peut être une séquence de flashs de l’écran, ce qui peut être utilisé même pour des terminaux endommagés.

Ce signal optique peut alors être affiché dans une étape (d) par l’écran 10 du terminal 1 de sorte à être capté par les moyens d’acquisition optique 31 de l’équipement de paiement 3. Il suffit par exemple que l’utilisateur place son téléphone en face des moyens 31. Cette utilisation du son rend possible la mise en œuvre du procédé avec n’importe quel terminal disposant seulement de la fonction « téléphoner » et d’un écran basique. Nulle fonction NFC, écran haute définition, etc. n’est requise. De même il suffit que le réseau 21 soit basique (et autorise les données). L’étape (e) subséquente consiste en la transcription inverse du signal optique par un module de traitement 30 de l’équipement 3 en le jeton de paiement, par exemple par déchiffrement du code QR.

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é) 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).

Ensuite, un deuxième déchiffrement est mis en œuvre 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 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. 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 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 générer le jeton que lorsque l’utilisateur est prêt et en position (terminal 1 orienté vers les moyens d’acquisition optique 31), de sorte à permettre une fenêtre de validité du jeton la plus courte possible.

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é é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 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 la suppression dudit jeton vérifié de la liste de jetons autorisés.

Facturation et gestion des jetons utilisés 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.

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

Plateforme et système

Selon un deuxième aspect, l’invention concerne en particulier l’équipement de paiement 3 utilisé pour la mise en œuvre 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 d’acquisition optique 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 œuvre, suite à l’initiation d’une transaction depuis un terminal mobile 1 comprenant un écran 10 : - Un module de réception d’une transcription optique d’un jeton de paiement associé au terminal 1 en un signal optique affiché par l’écran 30 et capté par les moyens d’acquisition optique 31 ; - Un module de transcription inverse du signal optique en le jeton de paiement ; - Un module de vérification du jeton (comprenant le cas échéant le 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 œuvre de transaction. Il comprend au moins un équipement de paiement 3 tel que 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. .Le système peut également comprendre le ou les terminaux 1 configurés pour mettre en œuvre une transcription optique du jeton en un signal optique.

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 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 œuvre 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 trouve ce produit programme d’ordinateur.

Claims (18)

1. REVENDICATIONS

   1. Procédé de mise en œuvre 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), et transmission au terminal mobile (1 ) ; (c) Transcription optique du jeton en un signal optique ; (d) Affichage dudit signal optique par un écran (10) du terminal (1) de sorte à être capté par des moyens d’acquisition optique (31) d’un équipement de paiement (3) ; (e) Transcription inverse du signal optique 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. 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. 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 déchiffrement préalable du jeton par le module de traitement (30) avec une clé privée de l’équipement de paiement (3).
4. 4. Procédé selon la revendication 3, dans lequel l’étape (b) 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. 5. Procédé selon la revendication 4, dans lequel 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 (30) de sorte à choisir la clé publique pour le déchiffrement du jeton.
6. 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. 7. Procédé selon la revendication 6, dans lequel l’étape (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. 8. Procédé selon la revendication 7, dans lequel l’étape (b) est mise en œuvre suite à l’appui sur une touche prédéterminée du terminal (1) pendant ladite conversation téléphonique.
9. 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 données du serveur (2) sont représentatives d’un compteur de jetons restants, l’étape (b) étant mise en œuvre seulement si ledit compteur présente une valeur non nulle, l’étape (b) comprenant le cas échéant le décrément dudit compteur.
10. 10. Procédé selon l’une des revendications 1 à 9, dans 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. 11. Procédé selon l’une des revendications 1 à 10, dans 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. 12. Procédé selon l’une des revendications 1 à 11, dans 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. 13. Procédé selon la revendication 12, dans lequel l’élément mécanique (32) est choisi parmi une barrière mobile et une imprimante.
14. 14. Procédé selon l’une des revendications 1 à 13, dans lequel ledit signal optique est un code QR.
15. 15. Equipement de paiement (3), comprenant un module de traitement de données (30) et des moyens d’acquisition optique (31), caractérisé en ce que le module de traitement de données (30) est configuré pour mettre en œuvre, suite à l’initiation d’une transaction depuis un terminal mobile (1) comprenant un écran (10) : - Un module de réception d’une transcription optique d’un jeton de paiement associé au terminal (1) en un signal optique affiche par l’écran (30) et capté par les moyens d’acquisition optique (31 ) ; - Un module de transcription inverse du signal optique 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.
16. 16. Système de mise en œuvre de transaction comprenant au moins un équipement de paiement (3) selon la revendication 15 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 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).
17. 17. Produit programme d’ordinateur comprenant 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 à 15 lorsque ledit programme est exécuté sur un ordinateur.
18. 18. 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 à 15.