FR3080478A1 - Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre - Google Patents

Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre Download PDF

Info

Publication number
FR3080478A1
FR3080478A1 FR1853535A FR1853535A FR3080478A1 FR 3080478 A1 FR3080478 A1 FR 3080478A1 FR 1853535 A FR1853535 A FR 1853535A FR 1853535 A FR1853535 A FR 1853535A FR 3080478 A1 FR3080478 A1 FR 3080478A1
Authority
FR
France
Prior art keywords
terminal
light
transaction
modulated
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1853535A
Other languages
English (en)
Other versions
FR3080478B1 (fr
Inventor
Sylvain Leroux
Micheline Perrufel
Christophe Cutullic
Olivier Bouchet
Philippe Dussaume
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1853535A priority Critical patent/FR3080478B1/fr
Publication of FR3080478A1 publication Critical patent/FR3080478A1/fr
Application granted granted Critical
Publication of FR3080478B1 publication Critical patent/FR3080478B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices

Abstract

L'invention concerne la transmission de données relatives à une transaction bancaire entre un terminal de fournisseur (T1) et un terminal de client (T2), les terminaux étant équipés chacun de : - un émetteur de lumière (E1, E2), - un capteur de lumière (C1, C2 ; CC), et - une interface homme machine (IHM1, IHM2) pour une visualisation et saisie par un utilisateur d'informations relatives à la transaction. En particulier, chaque terminal comporte un module logiciel pour piloter l'émetteur de lumière du terminal en vue d'une transmission d'un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse pour coder des données relatives à la transaction bancaire, et réciproquement interpréter un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire. Ainsi, on peut prévoir une transmission d'un premier flux du terminal du fournisseur au terminal du client, modulé pour coder au moins un montant de transaction, et sur réception du premier flux par le capteur du terminal du client, une animation de l'interface homme machine du terminal du client pour une validation, ainsi qu'une transmission d'un deuxième flux du terminal du client au terminal du fournisseur, modulé pour coder au moins des données de validation du client.

Description

Paiement sans contact perfectionné, utilisant un terminal de type smartphone ou autre
La présente invention concerne notamment un procédé sécurisé de paiement bancaire, à partir de dispositifs mobiles.
On entend ici par « dispositif mobile » un terminal mobile communiquant via un réseau, par exemple le téléphone mobile d’un utilisateur passant une transaction financière.
Les paiements par un dispositif mobile concernent toutes les transactions financières effectuées depuis ce dispositif mobile et débitées :
sur un compte bancaire, sur la facture d’un opérateur du réseau auquel est connecté ce dispositif mobile ou sur un compte prépayé (« porte-monnaie électronique »), qui peut être alimenté avec un dépôt auprès d'un agent ou d'un commerçant.
On connaît globalement trois grandes catégories de paiement par dispositif mobile (dit « paiement mobile » ci-après) :
les paiements à distance comme le paiement par dispositif mobile sur les sites de commerce électronique par exemple, les paiements de proximité devant une borne ou un terminal de paiement, ou les transferts de sommes d’argent de mobile à mobile.
Chaque catégorie de service peut utiliser des technologies spécifiques selon les usages. Les technologies suivantes sont par exemple utilisées pour le paiement mobile :
serveur vocal interactif, la confirmation par SMS ou « 3D-Secure », l’Internet mobile, parNFC, par QR code, ou encore par Bluetooth, la technologie de transmission de données par ultrasons dite NSDT (pour «Near sound data transfer »).
Actuellement, lors de règlement en boutique ou d’une prestation de service, l’opération se réalise majoritairement avec une carte bancaire et un code de sécurité à quatre chiffres. Cette opération est toujours réalisée avec un Terminal de Paiement (TPE) acheté ou loué par le commerçant. Cela implique ainsi la saisie du code précité par le payeur, dans un environnement possiblement non sécurisé.
Lors d’un paiement en ligne, outre l’affichage d’une page sécurisée (par exemple HTTPS), il est souvent associé l’envoi d’un code unique sur le mobile du client via SMS (dans la technologie 3DSecure). Il existe aussi de nombreux services bancaires générant des numéros de cartes de crédit virtuelles, qui peuvent être utilisés pour un unique achat sur un site internet. Cette réalisation est plus sécurisée mais nécessite de nombreuses étapes et alourdit le procédé de paiement.
Le paiement sans contact n’est pas encore massivement utilisé et rencontre encore quelques réticences de la part des utilisateurs.
En effet, pour ce qui concerne la technologie sans contact et NFC notamment, en France typiquement, environ dix millions d’utilisateurs sont équipés d’un dispositif mobile compatible avec une communication en champ proche ou « NFC » et plus de trente millions d’utilisateurs sont porteurs d’une carte bancaire sans contact. Il existe environ 300 000 terminaux de paiement seulement à disposition des commerçants (ou « TPE ») compatibles avec la technologie NFC sur 1,5 millions de terminaux.
Fa portée radiofréquence du NFC est de l’ordre du mètre, et ce de façon non directive, ce qui peut justifier la réticence des utilisateurs payeurs à l’emploi de cette technique.
Par ailleurs et plus généralement, les technologies existantes pour les paiements sans contact sont souvent liées à un matériel spécifique, avec souvent une technologie propriétaire, sans garantie de présence d’un terminal de paiement selon cette technologie auprès de tous les commerçants.
Fa présente invention vient améliorer la situation.
Elle propose à cet effet un procédé pour transmettre des données relatives à une transaction bancaire entre un terminal de fournisseur et un terminal de client. Ees terminaux sont équipés chacun de :
- un émetteur de lumière,
- un capteur de lumière, et
- une interface homme machine pour une visualisation et saisie par un utilisateur d’informations relatives à la transaction.
En particulier, chaque terminal comporte un module logiciel au moins pour :
- piloter l’émetteur de lumière du terminal en vue d’une transmission d’un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse pour coder des données relatives à la transaction bancaire, et
- interpréter un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire.
Le procédé comporte alors au moins :
- Une transmission d’un premier flux du terminal du fournisseur au terminal du client, le premier flux étant modulé pour coder au moins un montant de transaction,
- Sur réception du premier flux par le capteur du terminal du client, une animation de l’interface homme machine du terminal du client pour une demande de validation du montant de transaction par le client via l’interface homme machine du terminal du client,
- En cas de validation par le client, une transmission d’un deuxième flux du terminal du client au terminal du fournisseur, le deuxième flux étant modulé pour coder au moins des données de validation du client.
On entend par « transmission d’un flux » ici la transmission d’un flux lumineux en espace libre, en particulier sans utilisation nécessaire d'un support optique quelconque tel qu’une fibre optique entre les deux terminaux.
Grâce à ces dispositions, les communications entre les deux terminaux (du client et du fournisseur) sont bien apparentes, puisqu’une lumière peut être produite par l’émetteur de lumière précité, ce qui permet à un utilisateur de constater visuellement la transmission effective des données de transaction. En effet, la modulation de lumière, en amplitude, peut être obtenue à partir d’une diode clignotante (blanche par exemple), ou d’un écran à photodiodes clignotant. La modulation en fréquence peut être obtenue par changement de couleur des photodiodes de l’écran (ou par illumination sélective d’une diode de couleur choisie parmi plusieurs diodes produisant ensemble une lumière blanche).
En outre, comme les deux terminaux sont face-à-face préférentiellement à une courte distance l’un de l’autre, le terminal recevant les données forme écran à la lumière émise par l’autre terminal, ce qui empêche des terminaux tiers de recevoir aussi ces données de transaction. Ainsi, la confidentialité est assurée par ce moyen de communication par voie optique. De plus, contrairement aux flux électromagnétiques utilisés dans les modes sans contact de la technique antérieure tel que NFC, la trajectoire des flux lumineux est reconnaissable par les utilisateurs. Il leur est possible de détecter dans cette trajectoire la présence d'un appareil ou d'un équipement électronique étranger à la transaction. Dans une telle situation suspecte, il leur est également possible d'interrompre immédiatement le flux lumineux en détournant l'un des terminaux, ou en y interposant un objet ou une main, par exemple.
En outre, les terminaux peuvent être de type Smartphone, tablette, ou équivalent de sorte qu’il n’est pas nécessaire de prévoir un matériel spécifique pour ce type de communication, comme on le verra dans les exemples de réalisation présentés ci-après.
En effet, dans une réalisation, le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont alors naturellement équipés d’un module de prise de vue comportant :
- une diode électroluminescente pour produire un flash photographique, et
- une matrice de photorécepteurs pour recevoir des données d’image.
Ainsi, le module logiciel précité pilote la diode électroluminescente en tant qu’émetteur de lumière en vue d’une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs.
En variante, le terminal du client et/ou le terminal du fournisseur étant encore de type parmi un smartphone, une tablette, un ordinateur ou équivalent, ils sont naturellement équipés d’un écran d’affichage à diodes photoémettrices et d’un module de prise de vue comportant une matrice de photorécepteurs pour recevoir des données d’image.
Ainsi, dans cette réalisation encore, le module logiciel peut piloter l’écran d’affichage en tant qu’émetteur de lumière en vue d’une transmission de flux lumineux modulé en amplitude et interpréter un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs. Une telle réalisation est présentée sur la figure 2 commentée plus loin.
Par ailleurs, les données de la transaction, elles-mêmes, peuvent respecter des protocoles standards dans le domaine des transactions bancaires et prendre une forme générale d’une succession de bits à « zéro » ou « un ». Toutefois, il convient de coder ces valeurs binaires successives par une modulation de la lumière émise. Dans une forme de réalisation pertinente notamment dans le cas où l’émetteur de lumière est une diode électroluminescente utilisée habituellement comme flash d’appareil photographique, il est choisi que la lumière émise soit produite sous forme d’impulsions lumineuses qui se suivent dans le temps.
Ainsi, dans une première forme de réalisation, les données relatives à la transaction bancaire étant codées en binaire sur une succession de bits à « 0 » ou « 1 », les flux lumineux modulés en amplitude comportent chacun une succession d’impulsions lumineuses, et en particulier :
- une impulsion lumineuse dans la succession correspond à une valeur binaire de « 1 »,
- tandis que l’émetteur de lumière est inactif pour transmettre une ou plusieurs valeurs binaires de « 0 » entre deux impulsions lumineuses.
Ainsi, une pulsion lumineuse correspond à une valeur de « un », tandis qu’un « trou » sans lumière entre deux impulsions correspond à un « zéro ». Une telle réalisation est illustrée sur la figure 3A commentée plus loin.
Dans une réalisation alternative, les données relatives à la transaction bancaire étant codées en valeurs binaires, les flux lumineux modulés en amplitude comportent chacun une succession d’impulsions lumineuses. En particulier dans cette réalisation, ce sont les positions temporelles de chaque impulsion dans la succession qui sont définies en fonction des valeurs binaires par une modulation de position d’impulsion. Une telle réalisation est illustrée sur la figure 3B qui sera commentée plus loin.
On peut alternativement réaliser un codage par modulation de fréquence d’une succession binaire en prévoyant typiquement que les « 0 » et « 1 » sont codés par deux couleurs différentes, ou encore, par deux suites de couleurs différentes pour plus de robustesse dans le codage. Par exemple un premier intervalle de temps pendant lequel l’émetteur de lumière émet à une première couleur A peut indiquer le début d'un bit, et s'il est suivi d'un intervalle avec une deuxième couleur B alors le bit est un « 0 », et s'il est suivi d'un intervalle avec une troisième couleur C alors le bit est un « 1 », et on revient à la couleur A pour indiquer le bit suivant.
Dans l’un ou l’autre des modes de réalisation ci-dessus, on peut choisir avantageusement qu’une succession d’impulsions puisse comporter alors une succession d’occurrences avec une impulsion lumineuse ou une absence d’impulsion lumineuse, et en particulier les occurrences de cette succession sont espacées d’un pas temporel inférieur à une milliseconde.
En effet, d’après les tests réalisés sur des smartphones classiques, les performances en termes de réponse du capteur de lumière et de fréquence de clignotement de la diode peuvent permettre un pas temporel inférieur à 1 ms, voire inférieur à 0,1 ms, soit 10kHz en fréquence d’opération de la diode, ce qui est largement assez et suffisamment rapide pour communiquer 20 à 100 octets (ce qui représente habituellement la taille classique des données d’une transaction bancaire (pour un achat en boutique typiquement) à transmettre).
Dans une forme de réalisation possible, l’un au moins des terminaux parmi le terminal du fournisseur et le terminal du client comporte en outre une interface via un réseau de communication avec un serveur bancaire distant en vue d’obtenir du serveur une autorisation de la transaction. Les données de validation du client comportent alors des données d’authentification du client, en vue d’une demande d’autorisation de transaction transmise au serveur bancaire avec les données d’authentification du client via le réseau de communication.
Cette réalisation peut être avantageuse par exemple pour des paiements d’un montant supérieur à un seuil nécessitant une vérification par un serveur bancaire. Néanmoins, il peut être prévu des réalisations dans lesquelles aucun des terminaux n'a besoin d'être en communication avec un serveur bancaire:
notamment lorsque les montants des transactions sont inférieurs à un seuil (comme en communication viaNFC, aucune vérification n'étant faite par le terminal du fournisseur auprès du serveur bancaire), et dans une application de porte-monnaie électronique où le terminal stocke un montant disponible pour des transactions et qui est décrémenté d’un montant de transaction après chaque transaction : le deuxième flux du terminal comprend alors dans cette réalisation, en plus des données de validation, des données représentatives du montant en monnaie électronique.
La présente invention vise aussi un système pour la mise en œuvre du procédé ci-avant, comportant alors un terminal de client et un terminal de fournisseur, les terminaux étant équipés chacun de:
- un émetteur de lumière,
- un capteur de lumière, et
- une interface homme machine pour une visualisation et saisie par un utilisateur d’informations relatives à la transaction.
En particulier, chaque terminal comporte un module logiciel au moins pour :
- piloter l’émetteur de lumière du terminal en vue d’une transmission d’un flux lumineux, modulé en amplitude lumineuse pour coder des données relatives à la transaction bancaire, et
- interpréter un flux lumineux, modulé en amplitude lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire.
Un exemple de réalisation d’un tel système est illustré sur la figure 1 commentée plus loin et faisant apparaître les deux terminaux précités.
La présente invention vise aussi un terminal d’un client, d’un système du type ci-avant et comportant en particulier un module logiciel pour la mise en œuvre du procédé au sens de l’invention.
La présente invention vise aussi un terminal d’un fournisseur, d’un système du type ci-avant et comportant en particulier un module logiciel pour la mise en œuvre du procédé au sens de l’invention.
La présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé au sens de l’invention, lorsque ces instructions sont exécutées par un processeur. Ces instructions peuvent alors être réparties entre le terminal du client et le terminal du fournisseur, comme on le verra en référence à la figure 4 commentée plus loin, et qui présente les principale étapes algorithmique de ce programme informatique.
D’ailleurs, d’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description d’exemples de réalisation donnés ci-après et à l’examen des dessins annexés sur lesquels :
la figure 1 illustre un système à deux terminaux échangeant des données par transmission optique pour une transaction bancaire, la figure 2 illustre une variante de réalisation où l’écran d’affichage d’un terminal est utilisé comme source de lumière, alors qu’une diode électroluminescente (utilisée habituellement en tant que flash) est prévue comme source de lumière dans le mode de réalisation de la figure 1, la figure 3A montre un premier exemple de codage des données de transaction par une succession d’impulsions lumineuses, la figure 3B montre un deuxième exemple de codage des données de transaction par une succession d’impulsions lumineuses, la figure 4 illustre les différentes étapes du procédé au sens de l’invention, et
La figure 5 montre un exemple de pile protocolaire pouvant être utilisée pour la mise en œuvre du procédé proposé.
L’invention propose une transmission de données de transaction pour un paiement bancaire, par flux lumineux échangés entre deux terminaux.
En référence à la figure 1 en particulier, un fournisseur (de produit, de prestation, de service, ou autre ; par exemple un commerçant ou autre) dispose d’un terminal Tl, de type smartphone, tablette, ordinateur (portable ou non), ou équivalent. Un terminal de ce type est équipé typiquement d’une caméra intégrée pour des prises de vues, avec par exemple une diode électroluminescente El pour opérer un flash et un capteur Cl à matrice de photorécepteurs pour acquérir les données d’image. De même, un client du fournisseur souhaitant lui effectuer un paiement par transaction bancaire peut disposer aussi d’un terminal T2 comportant de mêmes équipements ou similaires (une diode E2 et un capteur C2).
Ainsi, de façon avantageuse, la mise en œuvre de l’invention ne nécessite pas un matériel spécifique : des terminaux préexistants, par exemple mobiles, peuvent être utilisés moyennant une programmation particulière de l’unité de traitement que comporte ces terminaux pour mettre en œuvre les étapes du procédé selon l’invention.
Néanmoins, il s’agit d’un exemple de réalisation et alternativement, il est possible de prévoir un dispositif spécifique intégrant un capteur et une diode ou autre moyen d’illumination, se connectant par exemple sur un port USB d’un équipement de type ordinateur par exemple (un « dongle USB » typiquement).
L’unité de traitement que comporte chacun des terminaux Tl et T2 comprend typiquement :
une mémoire (MEM1, respectivement MEM2) stockant des données temporaires ou non, et en particulier des données d’instructions d’un programme informatique au sens de l’invention ; ces données d’instructions peuvent être réparties alors entre les deux terminaux pour mettre en œuvre des étapes spécifiques pour le terminal du fournisseur d’une part, et des étapes spécifiques pour le terminal du client d’autre part, et un processeur (PROC1, respectivement PROC2) coopérant avec la mémoire précitée pour y lire les données d’instructions et exécuter ainsi des étapes du procédé.
En particulier, l’unité de traitement que comporte le terminal Tl du fournisseur comprend en outre une interface COM, reliée au processeur PROC1, pour communiquer avec notamment un serveur bancaire distant SER, via un réseau de communication RES (filaire ou radiofréquence).
Ainsi, il est possible de n’utiliser que deux smartphones, tablettes ou autres (pour le client et le fournisseur) afin de réaliser une transaction financière. Cette opération se réalise dans un mode opérationnel pair-à-pair pour transférer les données bancaires sécurisées entre les deux terminaux. Cette solution peut remplacer ainsi l’usage des terminaux de paiement classique (dits « TPE »).
L’invention propose de réaliser une communication optique sans fil bilatérale sécurisée, utilisable par exemple pour effectuer un paiement en boutique ou autre, avec une utilisation judicieuse des fonctions optiques d’un smartphone, d’une tablette ou d’un ordinateur de type « laptop » par exemple.
Il est considéré ici un cas classique où les données relatives à la transaction bancaire sont constituées d’une succession de valeurs binaires à « zéro » ou « un », comme illustré sur la partie supérieure de la figure 3A. Dans une forme de réalisation, la diode électroluminescente El ou E2 de l’un des terminaux Tl et T2 peut alors « clignoter » et transmettre ainsi un flux lumineux défini par une succession d’occurrences tl, t2, t3, t4, t5, t6 régulièrement espacées dans le temps et où, pour chaque occurrence :
- la diode E allumée pour transmettre une impulsion lumineuse si la valeur binaire correspondante à transmettre est « un » ;
- ou la diode E éteinte si la valeur binaire correspondante à transmettre est « zéro », comme illustré sur la partie du bas de la figure 3A.
Bien entendu, il s’agit d’un exemple de réalisation et, dans un autre exemple de réalisation illustré sur la figure 3B, on peut prévoir une succession d’occurrences tl, t’ 1, t2, t’2, t3, t’3, t4, f 4, t5, t’5, t6, t’6 ..., avec ici un codage sur la position d’une impulsion lumineuse à émettre parmi une occurrence fi ou une occurrence tfi. Par exemple :
si la valeur binaire est « un », l’impulsion lumineuse est émise à la première occurrence fi, et si la valeur binaire est « zéro », l’impulsion lumineuse est émise à la deuxième occurrence tfi qui suit la première occurrence fi.
Bien entendu, d’autres réalisations sont encore possibles : par exemple un codage sur deux niveaux d’amplitude lumineuse (un niveau bas pour les « zéro » et un niveau « haut » pour les « un » par exemple), ou autres.
Le type de données relatives à la transaction, elles-mêmes, typiquement sous la forme d’un train binaire (valeurs à « zéro » et « un »), ne diffère pas particulièrement par rapport à celui des données de transaction habituellement échangées avec un TPE classique (sans contact ou par lecture directe d’une carte bancaire).
En revanche, le programme informatique précité, exécuté par les processeurs PROC1 et PROC2, et formant ce qui est appelé ici « un module logiciel » permet de piloter la diode électroluminescente et le capteur de chaque terminal pour l’échange des données relatives à la transaction entre les deux terminaux Tl et T2. Cela se traduit par exemple par une utilisation particulière des fonctions optiques des terminaux Tl et T2 et de couches physiques ou de bas niveau (PHY - MAC) dans le protocole applicatif des terminaux. La figure 5 illustre les différentes couches habituelles d’une pile protocolaire d’un terminal, avec typiquement :
- en couches (« layers ») 6 et 7, des couches d’applications de communication,
- en couche 5, une couche de session (l’application au sens de l’invention étant alors susceptible d’utiliser le « middleware » existant),
- en couches 3 et 4 des couches de transport et réseau,
- en couches 1 et 2, des couches physique (PHY) et de liaison de données (MAC), avec ici en particulier la possibilité de contrôler « l’optique » des terminaux pour la transmission de données par moyens optiques en espace libre, c’est-à-dire sans fil ou autre guide d'onde (en émission et en réception).
Les paquets contenant les données de transaction peuvent se baser ainsi sur les recommandations ou standards existants (par exemple la certification EMV, les recommandations EAL4+ - « Paiement sur mobile » ou RFC 2404 pour les aspects de cryptage des données), sans modification nécessaire. Les paquets de valeurs binaires précitées peuvent être alors encapsulés dans des trames de communications optiques sans fil, à l’instar du protocole NFC par exemple.
Le terminal du fournisseur Tl, communiquant avec ce type de trame et selon la pile protocole illustrée sur la figure 5, est capable ainsi de communiquer dans un exemple de réalisation, à la fois avec le terminal du client T2 et avec le serveur bancaire SER comme illustré dans l’exemple de réalisation commenté maintenant en référence à la figure 4.
A l’étape SI de la figure 4, le fournisseur lance l’application au sens de l’invention sur son terminal Tl, pour une demande de validation d’un paiement au terminal T2 d’un client.
Le terminal du fournisseur Tl exécute en tant que première étape SI une animation de l’interface homme machine IHM1 du terminal Tl, pour que le fournisseur saisisse les premières données de la transaction (notamment par exemple le prix de la transaction, et éventuellement une référence du fournisseur).
Ensuite, à l’étape S2, le terminal Tl transmet sous la forme d’impulsions lumineuses le montant de la transaction avec une demande de validation de son montant, au terminal T2 du client. De la même manière, sur réception de ce type de message, le terminal T2 lance l’application au sens de l’invention, de paiement par impulsions lumineuses, et la première étape S3 du lancement de cette application sur le terminal du client T2, consiste à animer une interface homme machine IHM2 du terminal T2 afin que le client puisse valider ou non (confirmer ou infirmer le paiement, avec éventuellement la saisie d’un code PIN). Si le client valide la transaction via l’interface IHM2, le terminal T2 transmet au terminal Tl à l’étape S4 une validation de la transaction avec une authentification du terminal T2 du client.
Sur réception de cette authentification, le terminal Tl transmet au serveur bancaire SER à l’étape S5, une demande de validation/enregistrement de la transaction avec :
les données du client (identité, authentification), les données de la transaction (montant, date, etc.), les données du fournisseur (identité, notamment).
Le serveur SER après validation/enregistrement, transmet au terminal Tl du fournisseur un message de validation de la transaction à l’étape S6, ce qui provoque sur le terminal Tl :
- une animation de l’interface homme-machine IHM1 pour afficher au fournisseur, à l’étape S7, l’information de validation de la transaction par le serveur,
- ainsi qu’un envoi à l’étape S8 d’un message de validation de la transaction au terminal du client T2. A l’étape S9, sur réception de ce message sur le terminal T2, l’interface IHM2 peut s’animer pour signifier au client que la transaction a bien été enregistrée pour son paiement.
On peut relever ici que les étapes S5 et 6 sont optionnelles. Par exemple, le terminal du fournisseur Tl peut stocker toutes les données de transaction et les transmettre ultérieurement au serveur bancaire pour leur enregistrement. Alternativement, elles peuvent être exécutées par le terminal du client T2, par exemple en extrayant toutes les données nécessaires à l’identification et l’authentification du client utilisateur du terminal T2 auprès du serveur. Par ailleurs, les données du fournisseur peuvent être transmises à l’étape S2 au terminal T2 pour qu’elles soient enregistrées auprès du serveur bancaire. Par ailleurs, l’étape S8 de transmission d’un message d’enregistrement de transaction auprès du serveur bancaire peut être menée directement depuis le ou un serveur bancaire (par exemple du serveur bancaire du client) vers le terminal du client T2, par communication via des réseaux radiofréquences classiques, en recevant ce message par exemple sous la forme d’un SMS (à la manière du 3dsecure mais après transaction).
En particulier, les étapes S2, S4 au moins, d’interactions entre les deux terminaux par voie optique, peuvent être effectuées en disposant les deux terminaux Tl et T2 dos à dos, comme illustré sur la figure 1, à quelques centimètres l’un de l’autre. Dans ce cas, l’un des terminaux forme écran pour d’autres terminaux au signal lumineux qu’il reçoit. Ainsi, la communication optique ne peut être reçue que par le terminal formant cet écran. Par ailleurs, les utilisateurs en portant leur terminal, voient l’éclairement provoqué par la transmission des données et se rassurent ainsi quant à l’effectivité de la communication des données de transaction.
Par ailleurs, on a illustré sur la figure 2 une variante de la réalisation consistant à disposer les terminaux Tl et T2 différemment et non plus dos à dos. En particulier ici, le terminal du fournisseur Tl (ou même le terminal T2 du client) dispose classiquement, dans son interface homme machine IHM sur sa face avant, d’un écran d’affichage ECR et cet écran ECR remplace au moins pour une étape (par exemple l’étape S2), la diode électroluminescente (El ou E2).
Ainsi, dans un exemple de réalisation, le terminal du fournisseur Tl, lorsqu’il présente le montant de la transaction à l’étape S2, peut animer l’écran d’affichage ECR pour afficher le prix de la transaction, comme illustré sur la figure 2. Cet affichage (ou un affichage complémentaire tel qu’une barre lumineuse s’affichant au-dessus du montant), avec par exemple une lumière blanche suffisamment intense, peut clignoter en respectant un train d’impulsions définies pour communiquer ce montant de transaction, avec par exemple des données du fournisseur, afin que ces données soient reçues par le terminal T2 du client donnant alors dos au terminal Tl. Dans ce cas, un capteur de lumière CC du terminal Tl, qui est habituellement utilisé en mode « selfie » ou «webcam », peut s’animer pour recevoir les impulsions lumineuses correspondant aux données de validation du terminal T2 à l’étape S4.
On comprendra ainsi que cette forme de réalisation peut être avantageuse si le terminal Tl du fournisseur (par exemple un PC classique, portable ou non, équipé d’une webcam par exemple) n’est 5 pas équipé d’un appareil de prise de vue habituellement présent sur les Smartphones et tablettes.
Bien entendu, le terminal du client Tl peut utiliser aussi son écran d’affichage comme moyen d’éclairage pour la transmission des données de transaction, si nécessaire.
Plus généralement, la présente invention n’est pas limitée aux formes de réalisation décrites ci-avant à 10 titre d’exemple ; elle s’étend à d’autres variantes.
Ainsi, on comprendra par exemple que les formes de modulation de lumière présentées sur les figures 3A et 3B admettent d’autres variantes encore.
Les étapes successives de paiement bancaire présentées en référence à la figure 4 admettent aussi des variantes qui peuvent dépendre du type de transaction souhaitée (en fonction d’un montant plafond par 15 exemple, avec en cas de dépassement, la demande de saisie d’un code d’identification).

Claims (11)

  1. REVENDICATIONS
    1. Procédé pour transmettre des données relatives à une transaction bancaire entre un terminal de fournisseur (Tl) et un terminal de client (T2), les terminaux étant équipés chacun de :
    - un émetteur de lumière (El, E2),
    - un capteur de lumière (Cl, C2 ; CC), et
    - une interface homme machine (IHM1, IHM2) pour une visualisation et saisie par un utilisateur d’informations relatives à la transaction,
    Dans lequel chaque terminal comporte un module logiciel au moins pour :
    - piloter l’émetteur de lumière du terminal en vue d’une transmission d’un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse pour coder des données relatives à la transaction bancaire, et
    - interpréter un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire,
    Le procédé comportant au moins :
    - Une transmission d’un premier flux (S2) du terminal du fournisseur au terminal du client, le premier flux étant modulé pour coder au moins un montant de transaction,
    - Sur réception du premier flux par le capteur du terminal du client, une animation de l’interface homme machine du terminal du client pour une demande de validation (S3) du montant de transaction par le client via l’interface homme machine du terminal du client (IHM2),
    - En cas de validation par le client, une transmission (S4) d’un deuxième flux du terminal du client au terminal du fournisseur, le deuxième flux étant modulé pour coder au moins des données de validation du client.
  2. 2. Procédé selon la revendication 1, dans lequel le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont équipés d’un module de prise de vue comportant :
    - une diode électroluminescente pour produire un flash photographique, et
    - une matrice de photorécepteurs pour recevoir des données d’image, et le module logiciel pilote ladite diode électroluminescente en tant qu’émetteur de lumière en vue d’une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs.
  3. 3. Procédé selon la revendication 1, dans lequel le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont équipés d’un écran d’affichage à diodes photoémettrices et d’un module de prise de vue comportant une matrice de photorécepteurs pour recevoir des données d’image, et le module logiciel pilote l’écran d’affichage en tant qu’émetteur de lumière en vue d’une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs.
  4. 4. Procédé selon l'une des revendications précédentes, dans lequel les données relatives à la transaction bancaire sont codées en binaire sur une succession de bits à « 0 » ou « 1 » et les flux lumineux modulés en amplitude comportent chacun une succession d’impulsions lumineuses, une impulsion lumineuse dans ladite succession correspondant à une valeur binaire de « 1 », tandis que l’émetteur de lumière est inactif pour transmettre une ou plusieurs valeurs binaires de « 0 » entre deux impulsions.
  5. 5. Procédé selon l'une des revendications 1 à 3, dans lequel les données relatives à la transaction bancaire sont codées en valeurs binaires et les flux lumineux modulés en amplitude comportent chacun une succession d’impulsions lumineuses,
    Et dans lequel les positions temporelles de chaque impulsion dans la succession sont définies en fonction des valeurs binaires par une modulation de position d’impulsion.
  6. 6. Procédé selon l'une des revendications 4 et 5, dans lequel une succession d’impulsions comporte une succession d’occurrences avec une impulsion lumineuse ou une absence d’impulsion lumineuse, et les occurrences sont espacées d’un pas temporel inférieur à une milliseconde.
  7. 7. Procédé selon l'une des revendications précédentes, dans lequel l’un au moins des terminaux parmi le terminal du fournisseur (Tl) et le terminal du client (T2) comporte en outre une interface (COM) via un réseau de communication (RES) avec un serveur bancaire distant (SER) en vue d’obtenir du serveur une autorisation de la transaction, et dans lequel les données de validation du client comportent des données d’authentification du client, en vue d’une demande d’autorisation de transaction (S5) transmise au serveur bancaire avec les données d’authentification du client via le réseau de communication.
  8. 8. Système pour la mise en œuvre du procédé selon l’une des revendications précédentes, comportant un terminal de client et un terminal de fournisseur, les terminaux étant équipés chacun de:
    - un émetteur de lumière (El, E2),
    - un capteur de lumière (Cl, C2 ; CC), et
    - une interface homme machine (IHM1, IHM2) pour une visualisation et saisie par un utilisateur d’informations relatives à la transaction,
    Dans lequel chaque terminal comporte un module logiciel au moins pour :
    - piloter l’émetteur de lumière du terminal en vue d’une transmission d’un flux lumineux, modulé en 5 amplitude lumineuse pour coder des données relatives à la transaction bancaire, et
    - interpréter un flux lumineux, modulé en amplitude lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire.
  9. 9. Terminal d’un client, d’un système selon la revendication 8, comportant un module logiciel pour la 10 mise en œuvre du procédé selon l’une des revendications 1 à 7.
  10. 10. Terminal d’un fournisseur, d’un système selon la revendication 8, comportant un module logiciel pour la mise en œuvre du procédé selon l’une des revendications 1 à 7.
  11. 15 11. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 7, lorsque lesdites instructions sont exécutées par un processeur.
FR1853535A 2018-04-23 2018-04-23 Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre Active FR3080478B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1853535A FR3080478B1 (fr) 2018-04-23 2018-04-23 Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1853535A FR3080478B1 (fr) 2018-04-23 2018-04-23 Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre
FR1853535 2018-04-23

Publications (2)

Publication Number Publication Date
FR3080478A1 true FR3080478A1 (fr) 2019-10-25
FR3080478B1 FR3080478B1 (fr) 2020-05-08

Family

ID=62455745

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1853535A Active FR3080478B1 (fr) 2018-04-23 2018-04-23 Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre

Country Status (1)

Country Link
FR (1) FR3080478B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4634845A (en) * 1984-12-24 1987-01-06 Ncr Corporation Portable personal terminal for use in a system for handling transactions
US20040069853A1 (en) * 2001-02-15 2004-04-15 Dov Aharonson Smart card having an optical communication circuit and a method for use thereof
CN104166910B (zh) * 2014-04-30 2016-07-06 深圳光启智能光子技术有限公司 基于光子钱包的光子支付方法和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4634845A (en) * 1984-12-24 1987-01-06 Ncr Corporation Portable personal terminal for use in a system for handling transactions
US20040069853A1 (en) * 2001-02-15 2004-04-15 Dov Aharonson Smart card having an optical communication circuit and a method for use thereof
CN104166910B (zh) * 2014-04-30 2016-07-06 深圳光启智能光子技术有限公司 基于光子钱包的光子支付方法和系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LE NAM TUAN ET AL: "A survey of design and implementation for optical camera communication", SIGNAL PROCESSING. IMAGE COMMUNICATION, ELSEVIER SCIENCE PUBLISHERS, AMSTERDAM, NL, vol. 53, 3 February 2017 (2017-02-03), pages 95 - 109, XP029940897, ISSN: 0923-5965, DOI: 10.1016/J.IMAGE.2017.02.001 *
MARIAM M GALAL ET AL: "Smartphones for Payments and Withdrawals Utilizing Embedded LED Flashlight for High Speed Data Transmission", COMPUTATIONAL INTELLIGENCE, COMMUNICATION SYSTEMS AND NETWORKS (CICSYN), 2013 FIFTH INTERNATIONAL CONFERENCE ON, IEEE, 5 June 2013 (2013-06-05), pages 63 - 66, XP032446632, ISBN: 978-1-4799-0587-4, DOI: 10.1109/CICSYN.2013.23 *

Also Published As

Publication number Publication date
FR3080478B1 (fr) 2020-05-08

Similar Documents

Publication Publication Date Title
CA2971635C (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP1771827A1 (fr) Procede et systeme de paiement electronique universel
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR2972830A1 (fr) Systeme de controle de validation de titres de transport
EP3163487A1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
EP3252692A1 (fr) Procédé de fourniture de données relatives à une transaction de paiement, dispositif et programme correspondant
EP3349160A1 (fr) Procédé de transmission de données, dispositif et programme correspondant
FR2944177A1 (fr) Methode et systeme de transaction de proximite sans contact
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
FR3080478A1 (fr) Paiement sans contact perfectionne, utilisant un terminal de type smartphone ou autre
FR3047583A1 (fr) Methode de transmission securisee d'informations d'authentification entre des applications logicielles dans un terminal informatique
CA2945878A1 (fr) Dispositif de traitement de donnees en provenance de carte a memoire sans contact, methode et programme d'ordinateur correspondant
WO2020254761A1 (fr) Système d'applications de service pour terminaux de paiement
EP3542335A1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
FR3076008A1 (fr) Systeme d'authentification d'acces a formats d'entree multiples comprenant une borne d'authentification mobile et configurable, methode et logiciel associes
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
EP1225549B1 (fr) Terminal et procédé de paiement électronique.
FR3051276B1 (fr) Procedes de mise en oeuvre d'une transaction via un terminal mobile
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
EP2696320A1 (fr) Procédé de vérification d'authenticité, serveur, système et programme d'ordinateur correspondants
FR3128344A1 (fr) Méthode pour la mise à disposition immédiate d’un jeton non fongible à partir d’un fichier numérique d’un terminal mobile connecté à un service de chaine de blocs
FR2992806A1 (fr) Systeme de transmission securisee de donnees numeriques
EP3570238A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
FR2867293A1 (fr) Procede et systeme de micropaiement
OA18272A (en) Methods of implementing a transaction via a mobile terminal.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191025

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7