FR 3046869 A1 20170721 FR 1650385 A 20160118 1 Procédé de réalisation d'un virement bancaire Domaine technique L'invention se rapporte à un procédé de réalisation d'un virement d'unités de valeur entre entités d'un système informatique. Un virement peut concerner un paiement relatif à un achat, un don, etc. Une unité peut être de l'argent, des points tels que des points de fidélité, etc. Les entités en question gèrent les unités de valeur et peuvent opérer des transferts d'unité entre elles. Ces entités appartiennent généralement à des établissements financiers, tout particulièrement des banques. Etat de la technique L'échange d'unités de valeur, plus précisément d'argent, entre comptes utilisateurs repose actuellement principalement sur trois moyens simples et connus : l'argent liquide, le chèque ou le virement. Le chèque a deux inconvénients majeurs : - l'argent n'est pas immédiatement disponible, - le chèque peut ne pas être provisionné. Le virement est peu utilisé en France. Il est de surcroît peu pratique, du fait de la nécessité de saisir les éléments d'information du relevé d'identité bancaire du compte de l'utilisateur sur lequel une opération bancaire doit être réalisée, ce qui est fastidieux. Il doit également saisir le montant du virement et bien souvent l'objet, voire aussi une référence du virement. Parallèlement à cela, des opérateurs de télécommunication proposent des services financiers qui permettent d'effectuer des transferts d'argent entre particuliers via des dispositifs de communication, typiquement des smartphones. Les techniques utilisées reposent sur des éléments de signalisation des réseaux 3046869 2 mobiles. Le fonctionnement général revient en fait à transférer de l'argent d'un premier compte lié à un premier numéro de téléphone vers un deuxième compte lié à un deuxième numéro de téléphone. Les comptes sont gérés par une seule et même entité, à savoir l'opérateur. Or un besoin actuel est de réaliser un 5 virement entre entités différentes. De plus, le transfert d'argent met oeuvre à la fois le numéro de téléphone du donneur et du receveur. Or, pour des raisons de confidentialité, le donneur ou le receveur peut très bien ne pas souhaiter communiquer son numéro de téléphone. 10 L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L'invention A cet effet, selon un aspect fonctionnel, l'invention se rapporte à un procédé de réalisation d'un virement d'unités de valeur entre une première entité 15 et une deuxième entité gérant des comptes utilisateurs incluant des unités de valeurs respectives, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs dont un premier dispositif et un deuxième dispositif, caractérisé en ce qu'il comprend les étapes suivantes, dans le deuxième dispositif, lors de la réalisation d'un virement: 20 a. une étape d'obtention de premières données, dite de transaction issues du premier dispositif; b. une étape de transmission à destination de la première entité d'une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction et une 25 deuxième donnée préalablement obtenue auprès de la deuxième entité. L'invention met en oeuvre deux dispositifs appartenant à des utilisateurs et deux entités gestionnaires de comptes utilisateurs. Dans ce système, le deuxième dispositif reçoit des données de transaction de la part du premier 3046869 3 dispositif. L'utilisateur du deuxième dispositif n'a donc pas à saisir de données relatives à la transaction. Ensuite, la première entité transmet une demande de virement à la deuxième entité que si elle reçoit depuis le deuxième dispositif les données de transaction, et une donnée autre, à savoir la donnée obtenue auprès 5 de la deuxième entité. Le procédé de l'invention offre donc la possibilité de réaliser des virements entre entités de façon simple en particulier pour l'utilisateur du deuxième dispositif car ce dernier n'a pas de saisie de données liées à la transaction ; et de façon sécurisée grâce à l'utilisation de la donnée obtenue 10 auprès de la deuxième entité, ci-après désignée par le terme « jeton ». A noter que l'étape de transmission à destination de la première entité d'une commande de réalisation de la transaction peut s'effectuer directement ou indirectement. Dans ce dernier cas, la commande peut être reçue par le premier dispositif et transmis à la première entité. 15 Selon un mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec le précédent, les données de transaction reçues incluent une adresse, et en ce que la commande est transmise à cette adresse. Ce mode évite au deuxième dispositif une étape d'envoi d'une requête d'obtention de l'adresse qui ajouter une étape 20 supplémentaire dans le procédé. L'adresse en question est indifféremment l'adresse de la première entité ou d'une entité intermédiaire. Selon encore un autre mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec les précédent, la réception des données par le deuxième dispositif 25 déclenche l'étape de transmission d'une commande d'obtention de la deuxième donnée auprès de la deuxième entité. Ce mode permet d'automatiser l'étape d'obtention de la deuxième donnée, à savoir le jeton, et donc de rendre transparent les étapes correspondantes. Selon un autre mode de mise en oeuvre particulier de l'invention, qui 30 pourra être mis en oeuvre alternativement ou cumulativement avec les 3046869 4 précédents, l'étape d'obtention des premières données comprend une étape de lecture d'un code affiché sur un écran du premier dispositif. Ce mode évite tant pour l'émetteur que pour le récepteur du code de divulguer leurs numéros de téléphone respectifs. En effet, le deuxième dispositif photographie le code affiché 5 sur l'écran sans avoir besoin de fournir son numéro de téléphone au deuxième dispositif. Ensuite, le code lu peut être transmis vers la première entité pour l'obtention du code défini ci-dessus. selon un autre aspect fonctionnel, l'invention se rapporte à un procédé de réalisation d'un virement d'unités entre une première entité et une deuxième 10 entité gérant des comptes utilisateurs respectifs incluant des unités de valeurs respectives, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs dont un premier dispositif et un deuxième dispositif, caractérisé en ce qu'il comprend les étapes sur la première entité : a. une étape de réception d'une commande d'obtention de données 15 de transaction relatives à un virement à réaliser ; b. une étape de fourniture de premières données, dites de transaction, à destination du premier dispositif ; c. une étape de réception d'une commande de réalisation du virement, la commande incluant tout ou partie des données de 20 transaction et d'une deuxième donnée préalablement obtenue par le deuxième dispositif auprès de la deuxième entité ; d. une étape de transmission à la deuxième entité de tout ou partie des données de transaction reçues, et de la deuxième donnée pour vérification ; 25 e. une étape de réalisation du virement en fonction de la vérification. Selon un premier aspect matériel, l'invention se rapporte à un dispositif, dit second dispositif, comprenant un module de communication pour communiquer avec une première entité et une deuxième entité gérant des comptes utilisateurs incluant des unités de valeurs respectives, un module de 3046869 5 commande apte à commander un virement d'unités entre entités, caractérisé en ce qu'il comprend: a. un module d'obtention de premières données, dite de transaction, issues d'un premier dispositif, 5 b. un module de commande apte à transmettre à destination de la première entité une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction et d'une deuxième donnée préalablement obtenue auprès de la deuxième entité. 10 Selon un deuxième aspect matériel, l'invention se rapporte à une entité, dite première entité, apte à communiquer avec une deuxième entité pour la réalisation d'un virement d'unités de valeur entre comptes utilisateurs incluant des unités de valeurs respectives gérés par les entités respectivement, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs 15 dont un premier dispositif et un deuxième dispositif, caractérisé en ce qu'il comprend c. un premier module de réception apte à recevoir une commande d'obtention de données de transaction relatives à un virement à réaliser issue du premier dispositif ; 20 d. un module de fourniture de premières données, dites de transaction, à destination du premier dispositif ; e. un deuxième module de réception apte à recevoir une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction et d'une deuxième donnée 25 préalablement obtenue par le deuxième dispositif auprès de la deuxième entité ; Selon un troisième aspect matériel, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre sur le deuxième dispositif tel que défini ci-dessus, le programme comprenant des instructions de code qui, 3046869 6 lorsque le programme est exécuté par un processeur, réalise les étapes exécutées sur le deuxième dispositif. Selon un troisième aspect matériel, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre sur une entité telle que 5 définie ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes exécutées sur la première entité. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux figures annexées sur 10 lesquels : La figure 1 représente un système informatique sur lequel est illustré un exemple de réalisation de l'invention. Sur cette figure apparaissent également les étapes d'un mode de réalisation du procédé de l'invention. La figure 2 est une vue schématique des différents circuits inclus dans 15 le premier dispositif et le deuxième dispositif. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système SYS comprenant deux dispositifs de traitement de données, à savoir un premier dispositif DA et un deuxième dispositif DB appartenant respectivement à deux utilisateurs, à savoir un premier 20 utilisateur UTA et un deuxième utilisateur UTB ; l'ensemble comprenant le deuxième dispositif DB et le deuxième utilisateur UTB est référencé UTDB. Le système SYS comprend aussi deux entités BA et BB représentatives de gestionnaires de comptes d'unités de valeurs, typiquement des gestionnaires de comptes bancaires à savoir des banques ; ces entités disposent de ressources 25 physiques et logicielles aptes à réaliser des virements bancaires entre comptes bancaires CA et CB, en particulier entre les comptes bancaires CA et CB des utilisateurs UTA et UTB, respectivement. 3046869 7 Les entités BA et BB sont en général des systèmes informatiques respectifs incluant plusieurs serveurs reliés entre eux pour la réalisation de virements bancaires lors d'une transaction bancaire. Pour simplifier l'exposé, les deux entités BA et BB seront illustrées au moyen de deux serveurs, 5 respectivement. De façon connue en soi, les dispositifs et les serveurs ont l'architecture matérielle d'un ordinateur c'est-à-dire comportant des ressources pour le traitement de données à savoir au moins un processeur, une mémoire morte, une mémoire vive et des moyens de communication. 10 La figure 2 est une vue de l'architecture des deux dispositifs. Pour simplifier l'exposé, seuls certains circuits décrits ci-dessous sont représentés sur la figure. Les dispositifs DA et DB incluent respectivement des processeurs CPUA et CPUB, des mémoires mortes MEMA et MEMB, des entrées sorties I/OA et I/OB 15 pour communiquer avec un réseau RES1 tel que le réseau internet sans se limiter à celui-ci. Ce réseau servira dans notre exemple de réalisation à la communication lors des étapes ET1,ET2,ET3,ET5,ET7,ET8 et ET9 qui seront décrites ci-dessous. Dans notre exemple, les mémoires mortes incluent des programmes 20 d'ordinateur respectifs comportant des instructions pour l'exécution d'étapes du procédé en référence à la figure 1. Dans notre exemple, le processeur CPUA du premier dispositif DA est relié à un module de restitution RST pour la restitution d'un code numérique tel qu'un code barre comme ce sera expliqué ci-dessous; le module de restitution 25 est un écran. L'invention ne se limite pas à ce type de module de restitution mais s'étant à tous autres moyens de restitution tels qu'un émetteur de son apte émettre un signal représentatif d'un code. Le processeur CPUB du dispositif DB est apte à communiquer avec un module de traitement TRT connecté à un module de réception de signaux CPT 3046869 8 tels que des moyens de prise de vue ; le module de réception est par exemple un appareil photo. La figure 1 illustre un mode de réalisation du procédé de l'invention. Ce mode comprend plusieurs étapes référencées ETn. Sur cette figure, une étape 5 ETn mettant en oeuvre un échange de données est symbolisée par une flèche ayant une origine et une extrémité, l'origine étant associée à l'émetteur d'un message, l'extrémité étant associée au destinataire du message. Aussi, les étapes ne mettant pas en oeuvre une communication mais un traitement interne sont référencées dans le dispositif concerné par le traitement ; ces étapes sont 10 les étapes ET4 et ET6. Dans ce mode, un utilisateur particulier (qui pourrait aussi être un commerçant) UTA souhaite recevoir de l'argent d'un utilisateur particulier UTB. Lors d'une première étape ET1, l'utilisateur UTA requiert auprès de sa banque BA, par l'envoi d'une commande, ou auprès d'un intermédiaire de la 15 banque, la création des données dites de transaction liées à un virement à réaliser. Les données de transaction contiennent des données qui vont permettent ultérieurement au serveur de la banque BA de reconnaître le virement, en cas de réception d'une demande de validation d'un virement. Les 20 données de transaction contiennent donc au moins une information NUM identifiant le virement en cours. Les données peuvent comprendre d'autres informations comme une adresse de type URL (sigle de Uniform Resource Locator) dans le cas où l'émetteur de la demande de validation ne connaît pas l'adresse du serveur BA. Soulignons ici que, comme ci-dessus, cette adresse URL 25 peut être l'adresse du serveur BA ou d'un autre serveur par exemple celui d'un intermédiaire de la banque. Rappelons qu'une adresse URL est un format de nommage universel pour désigner une ressource sur Internet. Cette adresse est une chaîne de caractères ASCII incluant des informations utiles permettant à un logiciel d'accéder à une ressource sur le réseau RES1 à savoir le réseau Internet. 3046869 9 Dans notre exemple, les données de transaction comprennent également un montant KE (K désignant une valeur quelconque), un nom désignant l'utilisateur UTA, l'objet OBJ de la transaction, optionnellement d'autres renseignements comme un sponsor si il s'agit d'un don, etc. 5 Lors d'une deuxième étape ET2, le premier serveur BA, ou un intermédiaire du serveur BA, répond en fournissant au dispositif DA les données de transaction DT (URL, NUM, KE, A, OBJ, DAT) comprenant l'adresse de type URL, un numéro de transaction NUM, le montant KE, le nom désignant A, l'objet OBJ de la transaction, une date de péremption DAT de la transaction, date au- 10 delà de laquelle la transaction ne pourra pas se réaliser. Dans notre exemple, l'ensemble des données de transaction DT sont encodées au moyen d'un code barre, désigné par l'expression « QR Code » dans la suite de la description. Toute technologie de QR code peut être employée, comme par exemple les codes conformes à la norme ISO/CEI 18004:2006, les 15 codes Datamatrix, les codes Aztec, ou tout autres codes équivalents. Rappelons ici qu'un code-barres, ou code à barres, est la représentation d'une donnée numérique ou alphanumérique sous forme d'un symbole constitué de barres et d'espaces dont l'épaisseur varie en fonction de la symbologie utilisée et des données ainsi codées. Il existe des milliers de codes-barres différents ; 20 ceux-ci sont destinés à une lecture automatisée par un capteur électronique, le lecteur de code-barres. Le code QR (sigle anglo-saxon de Quick Response) quant à lui est un type de code-barres en deux dimensions (ou code matriciel datamatrix) constitué de modules noirs disposés dans un carré à fond blanc. L'agencement de ces points définit l'information que contient le code. 25 Lors d'une troisième étape ET3, après réception de l'ensemble de données, le premier dispositif DA met le QR code à la disposition de l'utilisateur UTB; cette mise à disposition peut être diverse, par exemple : - par envoi d'un email à l'utilisateur UTB sur un dispositif de l'utilisateur UTB autre que le deuxième dispositif DB, un ordinateur par exemple, 3046869 10 - par envoi d'un email transmis au dispositif DB lui-même, - par affichage du QR code sur un écran accessible à l'utilisateur UTB, - par impression sur un support papier accessible à l'utilisateur UTB ou envoyé par courrier papier à l'utilisateur UTB, 5 - etc. Sur la figure 1, l'extrémité de la flèche représentative de la troisième étape ET3 pointe sur l'ensemble UTDB signifiant que la mise à disposition est faite indifféremment pour le deuxième dispositif DB ou pour l'utilisateur UTB. Cet ensemble peut inclure d'autres dispositifs tels que l'ordinateur visé ci-dessus en 10 référence au premier exemple de mise à disposition décrit ci-dessus. Lors d'une quatrième étape ET4, quel que soit le mode de la mise à disposition du QR code à l'utilisateur UTB, le QR code reçu est analysé par le deuxième dispositif DB. Comme indiqué précédemment, la réception du QR code peut se faire 15 de plusieurs manières, notamment par capture ou par envoi d'un email. Si le mode choisi est la capture, le deuxième dispositif DB capture l'image du QR code. Le deuxième dispositif DB peut être par exemple un smartphone doté d'un appareil photo ; le QR code capturé est ensuite analysé. Si le mode choisi est l'email, le QR code est reçu directement sur le 20 deuxième dispositif DB à l'étape ET4 ; il n'y a pas dans ce cas de phase de capture graphique proprement dite, mais seulement une phase d'analyse du contenu. La capacité d'analyser le contenu d'un QR code peut être de base dans le deuxième dispositif DB ou bien apportée par une application informatique 25 dédiée installée en mémoire du dispositif DB. Accessoirement, l'application présente sur le deuxième dispositif DB affiche des informations relatives à la transaction en cours. Par exemple, sont 3046869 11 affichés le montant KE de la transaction, le nom de l'utilisateur UTA, l'objet OBJ de la transaction et éventuellement d'autres informations liées à la transaction. Cet affichage permet à l'utilisateur UTB d'être informé des détails de la transaction en cours. 5 A ce stade, l'utilisateur UTB peut valider les données affichées. Selon une variante, le procédé ne nécessite pas de validation au niveau du deuxième dispositif DB. Lors d'une cinquième étape ET5, suite à l'analyse du QR code, et éventuellement suite à la validation faite par l'utilisateur UTB, le deuxième 10 dispositif DB se connecte au serveur BB pour requérir une donnée appelée « jeton» (token en anglais) dans le présent texte. Ce jeton TK va permettre la poursuite de la réalisation du virement. Cette phase de connexion entre le deuxième dispositif DB et le deuxième serveur BB peut être réalisée par une requête de type http (sigle 15 anglo-saxon de HyperText Transfer Protocol) ou HTTPS (sigle anglo-saxon de HyperText Transfer Protocol Secure). Aussi, de préférence, avant une communication avec le deuxième serveur BB, l'utilisateur UTB s'authentifie-t-il auprès du serveur BB. Le mode d'authentification est quelconque. Un mode sera décrit dans la suite de la 20 description sans se limiter à celui-ci. Dans la requête transmise au serveur BB, le deuxième dispositif DB transmet les données de transaction DT contenues dans le QR code ou seulement une partie de ces données. Dans notre exemple, l'ensemble des données de transaction DT sont transmises au serveur BB accompagnées par 25 exemple d'un identifiant lié au dispositif DB, et donc indirectement à l'utilisateur UTB. Optionnellement, de manière à sécuriser cette cinquième étape ET5, en plus de l'authentification déjà réalisée, le deuxième serveur BB peut requérir une saisie d'un code personnel (exemple 4 chiffres) et/ou d'un mot de passe par le 3046869 12 deuxième dispositif DB. Cette sécurité supplémentaire peut se justifier par exemple au regard du montant KE, du bénéficiaire UTA ou de l'objet OBJ de la transaction affiché sur l'écran du smartphone. Lors d'une sixième étape ET6, le deuxième serveur BB génère un jeton 5 TK et l'associe avec les données de transaction DT en cours; le deuxième serveur BB conserve cette association (TK / DT) en mémoire. Le jeton TK créé est une référence unique créée pour le virement en cours. De préférence ce jeton TK, ou plus généralement l'association créée, a une durée de vie limitée dans le temps. 10 Lors d'une septième étape ET7, le deuxième serveur BB renvoi le jeton TK au dispositif DB; de préférence l'envoi de ce jeton TK est sécurisé ; le protocole HTTP(S) peut être utilisé à cette fin. Lors d'une huitième étape ET8, le deuxième dispositif DB se connecte ensuite au serveur BA grâce à l'URL encodée dans le QR code. Sont transmises 15 tout ou partie des données de transaction DT contenues dans le QR Code. Le deuxième dispositif DB transmet aussi simultanément, ou indépendamment dans un message séparé, le jeton TK. Cette phase de connexion est typiquement réalisée par une requête HTTP (ou HTTPS). Rappelons que L'URL est l'adresse fournie par le premier serveur BA et 20 que cette adresse URL peut être l'adresse du serveur BA ou celle d'un autre serveur par exemple celui d'un intermédiaire de la banque. Lors d'une neuvième étape ET9, les deux serveurs BA et BB entrent ensuite en communication et interagissent pour valider le virement. Lors de cette intéraction, le jeton TK et les données de transaction DT sont transmis du 25 serveur BA au serveur BB; permettant au serveur BB de vérifier que le jeton TK est bien celui qui a été émis à l'étape E7 et que l'association reçue existe : pour cela le deuxième serveur BB vérifie que les données de transaction DT associées à ce jeton TK sont correctes, en particulier qu'elles sont conformes aux valeurs des données DT validées par l'utilisateur UTB sur le deuxième dispositif DB lors 3046869 13 de l'étape ET4 et reçues du dispositif DB lors de l'étape ET6; par exemple le deuxième serveur BB vérifie dans les données de transaction DT, le nom du bénéficiaire A, le montant KE et l'objet OBJ de la transaction. Le serveur BB vérifie aussi, dans le cas où une durée de vie a été 5 définie, si celle-ci a expirée. Dans l'affirmative, le virement n'est pas validé. Dans la négative, le procédé se poursuit. Si la vérification s'avère positive, le transfert d'argent est validé. Selon le cas d'usage, le premier dispositif DA peut être notifié ; A cet instant, si l'objet de la transaction est la vente d'un bien, le marchand peut remettre l'objet 10 acheté ; si l'objet de la transaction est un don, le deuxième serveur BB peut procéder au don. La sécurité de la vérification repose sur le fait que le jeton TK est une référence à usage unique composée d'une chaîne d'octets et générée par le deuxième serveur BB pour la transaction. Dans notre exemple, ce jeton TK n'est 15 connu que du serveur BB. En outre, si un tiers malveillant voulait associer ce jeton TK à d'autres données de transaction (fausses) lors de la remontée de l'étape ET8, la vérification par le deuxième serveur BB à l'étape ET9 invaliderait une telle fraude : le deuxième serveur BB indiquerait que l'association ne correspond pas à l'association mémorisée par le deuxième serveur BB à l'étape 20 ET6. A l'étape ET8, rappelons que le deuxième dispositif DB se connecte au serveur BA grâce à l'URL encodée dans le QR code et que sont transmises tout ou partie des données de transaction DT contenues dans le QR Code. Selon une variante, la transmission de tout ou partie des données de transaction DT 25 contenues dans le QR Code et du jeton TK peut s'effectuer vers le premier serveur BA au moyen d'un second QR code. Dans cette variante, le second QR code est une concaténation de tout ou partie des données de transaction DT contenues dans le premier QR Code et du jeton TK; ce second code est généré par exemple par le deuxième serveur BB et transmis au dispositif DB; ou généré 30 par le deuxième dispositif DB lui-même (également par concaténation de 3046869 14 données DT et du jeton TK), ou tout autre dispositif connecté au deuxième dispositif DB. Ensuite, le deuxième dispositif DB affiche sur son écran ce second QR code qui est lu par un lecteur de QR codes, par exemple un lecteur installé sur le premier dispositif DA de l'utilisateur UTA ; le premier dispositif DA transfert 5 ensuite ce second QR code au serveur BA. Dans cette configuration, l'étape de transmission à destination de la première entité d'une commande de réalisation de la transaction s'effectue indirectement ; la commande étant reçue par le premier dispositif DA et transmise ensuite au premier serveur BA. Selon un mode de réalisation préféré, le deuxième serveur BB est un 10 serveur de transaction appartenant à un opérateur de télécommunication gérant une pluralité d'abonnements dont l'abonnement du dispositif DB. Rappelons qu'un abonnement souscrit auprès d'un opérateur permet notamment l'utilisation du réseau de télécommunication géré par cet opérateur. Dans cette configuration, l'opérateur, à réception de la requête HTTP reçue du dispositif DB 15 via le réseau, identifie l'abonnement concerné lié au dispositif DB, ou plus précisément lié à un module de sécurité présent dans le deuxième dispositif DB tel qu'une carte SIM (sigle de Subscriber Identity Module). L'opérateur apporte ainsi une garantie supplémentaire de par sa connaissance de l'utilisateur à l'origine de la requête lors de l'étape ET5, en garantissant une authentification 20 sûre. En définitive, l'émission du jeton TK à destination du deuxième dispositif DB ne sera transmise qu'après authentification. Selon un autre mode de réalisation, le deuxième serveur BB est un serveur de transaction qui n'est pas géré par un opérateur de télécommunication. Dans cet autre mode, la requête HTTP (ou HTTPS) de l'étape 25 ET5 est transmise à un serveur de l'opérateur de télécommunication, capable de garantir l'identité de l'utilisateur à l'origine de la requête. La requête HTTP (ou HTTPS) est ensuite traitée par le serveur de l'opérateur pour lui adjoindre un paramètre garantissant l'origine de la requête, typiquement par ajout d'un élément identifiant l'utilisateur UTB. Cette requête ainsi complétée (voire mise 30 sous une autre forme que HTTP) est ensuite transmise par le serveur de l'opérateur au deuxième serveur BB. 3046869 15 Selon un autre mode de réalisation, l'authentification réalisée à l'étape ET5 peut être basée sur une utilisation particulière du code personnel ou du mot de passe. Dans cet autre mode, un programme installé dans une mémoire du dispositif DB utilise un mécanisme cryptographique pour chiffrer les données à 5 transmettre vers le deuxième serveur BB. Le programme est par exemple une fonction de chiffrement de type AES fonctionnant avec une clé de 256 bits (ou de 128 bits). La fonction de chiffrement AES utilise une clé intermédiaire de 256 bits (ou 128, nous choisirons 256 bits dans la suite) stockée dans ce même logiciel chiffreur. Cette clé intermédiaire est connue du serveur BB qui connaît 10 également le code personnel du client. Cette clé intermédiaire est généralement installée au préalable sur le deuxième dispositif DB. Ce mode de réalisation avec chiffrement du code personnel comprend les étapes suivantes : 15 Le client B saisit son code personnel. Le code personnel est ensuite combiné avec la dé intermédiaire par la fonction de chiffrement ; l'opération mathématique suivante est réalisée entre la clé intermédiaire et le code personnel : [clé intermédiaire de 256 bits] Xor [code personnel reformaté sur 256 20 bits] Xor étant la fonction "ou exclusif". Cette opération donne pour résultat une clé de chiffrement. Ensuite, l'ensemble incluant les données principales du QR Code et l'identifiant client sont chiffrés par la fonction de chiffrement AES dans le 25 deuxième dispositif DB avec la clé de chiffrement. Ainsi chiffrés, le tout est ensuite envoyé au serveur BB accompagnés de l'identifiant client UTB. 3046869 16 Le deuxième serveur BB retrouve ensuite la clé de chiffrement du client avec l'identifiant du client UTB. Il déchiffre les données chiffrées reçues à savoir l'ensemble {[les données principales du QR Code] et l'identifiant client} 5 chiffré avec la dé de chiffrement. Si le déchiffrement donne {[données principales du QR Code] + identifiant client} et que les [données principales du QR Code] sont compréhensibles, le deuxième serveur BB génère et envoie le jeton TK demandé au dispositif DB. 10 Cet autre mode apporte une sécurité supplémentaire, car, pour valider la transaction au niveau du serveur BB et obtenir un jeton TK, il faut à la fois nécessairement : - que le deuxième dispositif DB dispose de la clé intermédiaire dans son logiciel AES 15 - connaître le code personnel de l'utilisateur UTB. Ainsi, la divulgation malencontreuse de l'identifiant client UTB et de son code personnel ne suffira à un tiers malveillant pour obtenir un jeton TK. Il faudra que le tiers malveillant dispose également de la clé intermédiaire dans son dispositif. 20 Précisons ici que le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction 25 ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un 3046869 17 ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). 5 REVENDICATIONS1. Procédé de réalisation d'un virement d'unités de valeurs (TB) entre une première entité (BA) et une deuxième entité (BB) gérant des comptes utilisateurs incluant des unités de valeurs respectives, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs dont un premier dispositif (DA) et un deuxième dispositif (DB), caractérisé en ce qu'il comprend les étapes suivantes, dans le deuxième dispositif (DB), lors de la réalisation d'un virement: a. une étape d'obtention (ET3,ET4) de premières données (DT), dite de transaction issue du premier dispositif (DA); b. une étape de transmission (ET8) à destination de la première entité (BA) d'une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction (DT) et une deuxième donnée (TK) préalablement obtenue auprès de la deuxième entité (BB). 2. Procédé de réalisation d'un virement d'unités selon la revendication 1, caractérisé en ce que les données de transaction (DT) reçues incluent une adresse (URL), et en ce que la commande est transmise à cette adresse (URL). 3. Procédé de réalisation d'un virement d'unités selon la revendication 2, caractérisé en ce que l'adresse (URL) est l'adresse de la première entité (BA). 4. Procédé de réalisation d'un virement d'unités selon la revendication 1, caractérisé en ce que la réception des données par le deuxième dispositif (DB) déclenche l'étape de transmission d'une commande d'obtention de la deuxième donnée (TK) auprès de la deuxième entité (BB). 5. Procédé de réalisation d'un virement d'unités selon la revendication 1, caractérisé en ce que l'étape d'obtention comprend une étape de lecture d'un code (QR ou autres) affiché sur un écran du premier dispositif. 3046869 19 6. Procédé de réalisation d'un virement d'unités entre une première entité (BA) et une deuxième entité (BB) gérant des comptes utilisateurs respectifs incluant des unités de valeurs respectives, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs dont 5 un premier dispositif (DA) et un deuxième dispositif (DB), caractérisé en ce qu'il comprend les étapes sur la première entité (BA): a. une étape de réception (ET1) d'une commande d'obtention de données de transaction relatives à un virement à réaliser b. une étape de fourniture (ET2) de premières données (DT), dites 10 de transaction, à destination du premier dispositif (DA) ; c. une étape de réception (ET8) d'une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction (DT) et d'une deuxième donnée (TK) préalablement obtenue par le deuxième dispositif (DB) auprès de la deuxième 15 entité (BB); d. une étape de transmission (ET9) à la deuxième entité (BB) de tout ou partie des données de transaction (DT) reçues, et de la deuxième donnée (TK) pour vérification ; e. une étape de réalisation du virement en fonction de la vérification. 20 7. Dispositif (DB), dit second dispositif, comprenant un module de communication pour communiquer avec une première entité (BA) et une deuxième entité (BB) gérant des comptes utilisateurs incluant des unités de valeurs respectives, un module de commande apte à commander un virement d'unités (TB) entre entités, caractérisé en ce qu'il comprend: 25 a. un module d'obtention de premières données (DT), dite de transaction, issues d'un premier dispositif, b. un module de commande apte à transmettre à destination de la première entité (BA) une commande de réalisation du virement, la 3046869 20 commande incluant tout ou partie des données de transaction DT et d'une deuxième donnée (TK) préalablement obtenue auprès de la deuxième entité (BB). 8. Entité (BA), dite première entité, apte à communiquer avec une deuxième 5 entité (BB) pour la réalisation d'un virement d'unités de valeur entre comptes utilisateurs incluant des unités de valeurs respectives gérés par les entités respectivement, des opérations sur les unités de valeurs pouvant être commandées par des dispositifs dont un premier dispositif (DA) et un deuxième dispositif (DB), caractérisé en ce qu'il comprend 10 a. un premier module de réception apte à recevoir une commande d'obtention de données de transaction relatives à un virement à réaliser issue du premier dispositif (DA) b. un module de fourniture de premières données (DT), dites de transaction, à destination du premier dispositif (DA) ; 15 c. un deuxième module de réception apte à recevoir une commande de réalisation du virement, la commande incluant tout ou partie des données de transaction (DT) et d'une deuxième donnée (TK) préalablement obtenue par le deuxième dispositif (DB) auprès de la deuxième entité (BB); 20 9. Programme d'ordinateur apte à être mis en oeuvre sur un dispositif (DB) tel que défini dans la revendication 7, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes définies dans la revendication 1. 10. Programme d'ordinateur apte à être mis en oeuvre sur une entité (BA) 25 telle que définie dans la revendication 8, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes telles que définies dans la revendication 6.