Note: Descriptions are shown in the official language in which they were submitted.
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
1
Description
Titre de l'invention : Système d'applications de service pour terminaux de
paiement
Domaine technique
La présente invention concerne le domaine des applications de service pour
terminaux de paiement.
Technique antérieure
Un terminal de paiement (ou terminal de paiement virtuel) est un dispositif
informatique permettant à un professionnel de gérer le paiement électronique
d'un bien ou d'un service par un client. Le paiement s'effectue typiquement à
l'aide d'une carte bancaire, smartphone ou tout autre support embarquant un
moyen de paiement. La carte, son porteur et la transaction sont authentifiés
et
validés par le terminal de paiement auprès d'un service bancaire, après
présentation de la carte au terminal, ou saisie manuelle des informations
relatives
à l'identification du porteur (numéro de carte, date d'expiration, identifiant
du
porteur, etc.). Le terminal de paiement peut être constitué d'un dispositif
informatique dédié, être constitué d'un dispositif informatique généraliste,
comme
par exemple un téléphone mobile, une tablette informatique, un ordinateur
personnel doté d'un moyen de lecture d'une carte à puce, d'une carte à piste
magnétique, sans contact et de manière générale de lecture d'une information
sur un support permettant l'identification d'un client au service bancaire (y
compris code barre ou QR code), ou d'une application permettant l'accès au
service de paiement (exemple : navigateur internet) et connecté à un réseau
informatique. Le dispositif informatique dispose d'une application de service
dédiée à la gestion des transactions.
Le contexte actuel du paiement est marqué par l'apparition de nouveaux moyens
de paiement comme, par exemple, les solutions de paiement utilisant des objets
connectés comme les téléphones intelligents (smartphones en anglais) dotés de
capacités de paiement. On peut citer les solutions Apple Pay (marque déposée),
Android Pay (marque déposée), des solutions de portefeuille électroniques
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
2
internationaux, régionaux ou affinitaires comme AliPay (marque déposée),
WeChat Pay (marque déposée), Paypal (marque déposée), BlueCode (marque
déposée), Paylib (marque déposée), etc.
De nombreuses marques de paiement se développent également comme, par
exemple, VISA (marque déposée), VISA Electron (marque déposée), Mastercard
(marque déposée), Maestro (marque déposée), Union Pay (marque déposée),
Discover (marque déposée), American Express (marque déposée), Cartes
bancaires (marque déposée), MultiBanco (marque déposée), Giromat (marque
déposée), Giropay (marque déposée), etc.
Les services autour du paiement se développent également, comme l'offre de
paiement en plusieurs fois, le paiement en devise (DCC), le paiement différé,
etc.
Les services annexes à la transaction proprement dite se développent aussi,
comme l'offre d'assurances sur le bien ou le service acheté, les extensions de
garantie, la prise en charge du pourboire. Ces services annexes peuvent
également concerner la relation client, comme par exemple les programmes de
fidélité, l'offre de coupons de réductions, la collecte d'avis client ou
autres.
D'autres services encore peuvent concerner la connaissance du consommateur
et de son comportement. Les possibilités de services autour du paiement ne
cessent de s'accroitre chaque jour.
Pour pouvoir être offerts à ses clients de façon plus simple, intuitive et
ergonomique, ces services doivent être intégrés à l'application de gestion du
terminal du paiement par le professionnel. Pour ce faire, il est nécessaire de
faire
appel à des intégrateurs ou directement au fabricant du terminal de paiement
pour développer une application spécifique correspondant aux besoins du
professionnel. Ces développements sont longs, coûteux, et doivent ensuite être
maintenus par un professionnel. Ce coût, ces délais et le manque de
flexibilité
sont un obstacle à l'adoption rapide par les professionnels des services
disponibles ou à venir.
Exposé de l'invention
La présente invention a pour but de résoudre les inconvénients précités en
proposant une plateforme de services pouvant être intégrés à une solution de
paiement ou d'interaction client. La plateforme offre également un outil de
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
3
programmation graphique de solutions de paiement qui permet à un utilisateur
de la plateforme de définir les solutions de paiement en intégrant les
services
souhaités et en les paramétrant. Cet outil de programmation graphique peut
être
utilisé sans nécessiter de connaissance informatique. L'outil de programmation
graphique permet de générer au moins deux logiciels, par exemple à base de
scripts, l'un destiné à être exécuté sur le terminal de paiement et à
collaborer
avec l'autre sur un serveur de la plateforme de services pour fournir une
solution
de paiement.
Ainsi, un professionnel peut facilement et rapidement définir la solution de
paiement adaptée à ses besoins. Cette solution peut être déployée rapidement.
Elle peut également être modifiée à tout moment par le professionnel de façon
à
suivre les évolutions de ses besoins.
Brève description des dessins
[Fig 1] La figure 1 illustre l'architecture d'un système de services pour
terminaux
de paiement selon un exemple de réalisation de l'invention.
[Fig 2] La figure 2 illustre un exemple d'interface de programmation des
applications de services pour terminaux de paiement.
[Fig 3] La figure 3 illustre un service tel qu'il apparait dans la fenêtre
d'édition
selon un exemple de réalisation de l'invention.
[Fig 4] La figure 4 illustre le déploiement de l'application de service selon
un mode
de réalisation de l'invention.
[Fig 5] La figure 5 illustre le déroulement d'un service, ici le service de
paiement,
selon un exemple de réalisation de l'invention.
[Fig 6] La figure 6 illustre les principales étapes de l'exécution d'une
application
de service dans un mode de réalisation de l'invention.
[Fig 7] La figure 7 illustre l'architecture logicielle du terminal de paiement
dans un
exemple de réalisation de l'invention.
[Fig 8] La figure 8 illustre l'architecture logicielle de la plateforme
serveur dans un
exemple de réalisation de l'invention.
[Fig 9] La figure 9 est un bloc-diagramme schématique d'un dispositif de
traitement de l'information pour la mise en oeuvre d'un terminal de paiement
ou
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
4
d'un serveur pouvant implémenter la plateforme de service pour terminaux de
paiement selon plusieurs modes de réalisation de l'invention.
Description détaillée
La Figure 1 illustre l'architecture d'un système de services pour terminaux de
paiement selon un exemple de réalisation de l'invention.
Le système comprend une plateforme de service 103. Cette plateforme de
service comprend un premier module d'exécution 105 qui permet l'opération des
services de paiement à un terminal de paiement 101. La plateforme de service
103 comprend également un module de programmation des services de
paiement 104 auquel un utilisateur, c'est-à-dire une personne opérant un
terminal
de paiement 101 peut se connecter depuis un dispositif de traitement de
l'information 102. Ce dispositif peut typiquement être constitué d'un
ordinateur
personnel, d'une tablette, ou de tout terminal pouvant se connecter à un
réseau
de communication de données du type Internet. Le dispositif de traitement de
l'information dispose typiquement d'un client Internet, tel qu'un navigateur
web,
permettant à l'utilisateur d'interagir avec le module de programmation des
services de paiement 104.
La plateforme de service 103 est décrite ici de manière logique. Elle peut
être
constituée d'un ou de plusieurs serveurs interagissant pour fournir le service
décrit. De même, seuls les aspects essentiels à la définition puis à
l'exécution
des applications de service de paiement sont décrites. La plateforme comprend
également des services annexes comme, par exemple, l'authentification et la
gestion des utilisateurs qui ne sont pas décrits en détail.
Le module de programmation des services de paiement 104 permet à l'utilisateur
de programmer de façon simple, intuitive et rapide, un service de paiement sur
la base de services de base offerts par la plateforme de service 103. Selon un
exemple de réalisation de l'invention, le module de programmation des services
de paiement offre une programmation graphique par agencement de services
élémentaires, leur connexion et la définition de leurs paramètres. Ainsi, un
utilisateur peut facilement concevoir une application complète pour un
terminal
de paiement. Cette application complète, une fois définie, est constituée de
deux
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
modules logiciels destinés l'un à s'exécuter sur le terminal de paiement 101
et
l'autre sur le module d'exécution 105. Les deux modules logiciels
interagissent
alors pour exécuter ensemble l'application. Dans certains modes de
réalisation,
l'application implique plus de deux modules logiciels s'exécutant sur
différents
5 dispositifs informatiques et interagissant entre eux.
Au moins certains des services élémentaires constituant l'application pour
terminal de paiement peuvent faire appel à un ou plusieurs services externes
106
à 109. Ces services externes comprennent par exemple des fournisseurs de
services de paiement (PSP pour Payment Service Provider en anglais), des
services de courrier électronique, des services de messagerie par message
texte
court (SMS pour Short Message Service en anglais), des services de collecte et
d'analyse d'avis clients, des services d'animation commerciale (programme de
fidélité, de gestion de coupons...), des services d'identification du client
(ex:
gestion de tokens) ou autres.
Ainsi, un utilisateur opérant un terminal de paiement peut utiliser la
plateforme
pour définir une application complète pour terminal de paiement. Cette
définition
ne nécessite pas de connaissance particulière en programmation, elle est
rapide
et aisée à utiliser. Une fois l'application définie, la plateforme génère tous
les
modules logiciels devant s'exécuter sur le terminal de paiement. La plateforme
génère également un second module logiciel qui s'exécute sur la plateforme
elle-
même. Les modules logiciels destinés au terminal de paiement ou, de manière
plus générale, tout dispositif informatique, sont déployés sur ceuxci. Lors de
l'utilisation du terminal de paiement, le module logiciel déployé sur le
terminal
s'exécute, se connecte à la plateforme et coopère avec le module logiciel
s'exécutant sur la plateforme pour fournir les services composant
l'application.
Certains de ses services peuvent utiliser des services externes qui
interagissent
avec la plateforme de service.
L'utilisateur peut donc, à tout moment, définir ou modifier son application de
paiement pour s'adapter à l'évolution de ses besoins et offrir le niveau de
service
souhaité à ses clients. De nouveaux services apparaissant sur le marché
peuvent
être offerts rapidement par intégration à la plateforme de service. Dès cette
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
6
intégration faite, les utilisateurs peuvent les intégrer à leur application
pour
terminal de paiement.
La Figure 2 illustre un exemple d'interface de programmation des applications
de
services pour terminaux de paiement.
L'application de programmation graphique permettant la programmation des
applications de service fonctionne sur un mode client-serveur entre le client
102
utilisé par l'utilisateur et le module de programmation 104 sur la plateforme
de
service. L'exemple ici décrit est basé sur l'utilisation d'un navigateur web
standard sur le client 102 interagissant avec un module de programmation 104
développé sous la forme d'un service web sur la plateforme. Toute autre
implémentation est bien sûr envisageable comme un client natif interagissant
avec une application native côté serveur par exemple.
Dans cet exemple, l'interface de programmation comprend une fenêtre principale
201 qui comprend deux sous-fenêtres.
.. Une première sous-fenêtre 202 comprend une liste des services élémentaires
203 disponibles. Avantageusement cette liste peut être ordonnée par type de
services. Avantageusement, la liste peut être hiérarchisée et permettre de
n'afficher que les services d'une même catégorie à un instant donné pour
faciliter
l'identification du service recherché, si le nombre total de services est
grand.
Une seconde sous-fenêtre 204 permet l'édition de l'application de service pour
terminaux de paiement. Dans cette fenêtre d'édition 204, l'utilisateur peut
agencer des services 205 sélectionnés dans la liste des services 202.
Typiquement, l'utilisateur peut sélectionner un service dans la liste des
services
202 et le glisser-déposer dans la fenêtre d'édition 204. Le service 205, une
fois
déposé dans la fenêtre d'édition expose au moins un point d'entrée et au moins
un point de sortie, ainsi que d'éventuels points de branchement (hooks en
anglais). L'utilisateur peut alors connectés les points d'entrée et de sortie
des
différents services pour constituer son application. Les services 205 exposent
également, si nécessaire, un ensemble de paramètres permettant à l'utilisateur
de personnaliser le service selon ses besoins.
L'interface comprend également, non représenté sur la figure, les contrôles
permettant la sauvegarde d'une application ainsi que la génération et le
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
7
déploiement des modules logiciels générés sur le terminal de paiement et sur
la
plateforme. Avantageusement, le déploiement du module logiciel destiné au
terminal de paiement peut être fait sur un ensemble de terminaux de paiement,
par exemple dans le cas d'un magasin comportant un ensemble de terminaux de
paiement ou dans le cas d'une chaine de magasins.
La Figure 3 illustre un service 301 tel qu'il apparait dans la fenêtre
d'édition 204
selon un exemple de réalisation de l'invention.
Le service comprend au moins un point d'entrée 304 et au moins un point de
sortie 305. Selon le service, plusieurs points de sortie (ex: point de sortie
n 1 =
transaction validée, point de sortie n 2 = transaction en erreur, point de
sortie n 3
= transaction annulée par le client) peuvent être présents. Ce sont ces points
d'entrée et de sortie qui permettent de connecter les différents services
entre eux
pour constituer l'application. Cette connexion est avantageusement faite en
tirant
une connexion entre deux points à la souris.
Un ou plusieurs points de branchement 306 peuvent être présents. Ces points
de branchement permettent d'interrompre le déroulement du service à un
moment donné pour déclencher le déroulement d'un ou de plusieurs autres
services connectés à ce point de branchement. Lorsque ces services se
terminent, le service interrompu est repris.
Dans l'exemple de réalisation, le service comprend une zone d'identification
302.
Cette zone d'identification peut comprendre le nom du service, un identifiant
du
service ainsi qu'une description longue du service. Avantageusement, un bouton
dans cette zone permet d'ouvrir une page d'aide qui donne des détails sur le
fonctionnement du service à l'utilisateur.
Une zone de paramétrage du service 303 est présente si le service peut être
paramétré. Cette zone de paramétrage comprend typiquement des contrôles,
comme des menus déroulants, des cases à cocher à sélection multiple ou
exclusive, des champs numériques ou textuels etc... L'utilisateur peut alors
facilement paramétrer chaque service en fonction de ses besoins.
Par exemple, un service de paiement pourra permettre à l'utilisateur de
choisir le
type de carte acceptée parmi les cartes à puce avec contact, sans contact, les
cartes magnétiques et saisie manuelle, etc. Il peut également permettre de
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
8
choisir les solutions acceptées parmi, par exemple, les solutions VISA,
Mastercard, American Express, Discover, JOB.... Les types de paiement
acceptés peuvent également être paramétrés parmi différents types (exemple :
débit, crédit, remboursement...). Des paramètres par défaut peuvent également
être paramétrés. Des points de branchement peuvent être offerts pour permettre
d'insérer des services autres à certains moments de l'exécution d'un service
(e.g.
le paiement) paiement comme, par exemple, avant l'insertion de la carte, après
l'insertion de la carte, avant la sélection de l'application et après la
sélection de
l'autorisation.
Par exemple, si l'utilisateur souhaite apporter la possibilité à ses clients
de payer
en utilisant leur propre devise en lieu et place de la devise par défaut de
l'utilisateur, un service de conversion de devise peut être branché sur le
point de
branchement intervenant après l'insertion de la carte. Ainsi, après
l'insertion de
la carte, le client se verra proposer la sélection d'une devise, par exemple
le dollar
américain, au lieu de la devise par défaut du commerçant, par exemple l'euro.
Le
client peut alors lire sur le terminal le montant net qui lui sera prélevé sur
son
compte bancaire dans sa devise et incluant les frais éventuels comme le taux
de
change et la commission de change.
La Figure 4 illustre le déploiement de l'application de service selon un mode
de
réalisation de l'invention.
Une fois l'application de service 401 définie par l'utilisateur en utilisant
le module
de programmation 104 à l'aide de l'interface 201, plusieurs modules logiciels
tels
que 402 et 403 sont générés. Le module logiciel 402 est destiné à s'exécuter
sur
le terminal de paiement 404 (ou autre dispositif informatique) sous le
contrôle
d'un orchestre de service 406. Le module logiciel 403 est destiné à s'exécuter
sur le serveur (ou autre dispositif informatique) au sein du module
d'exécution
des service 405, correspondant au module illustré dans la Figure 1 sous la
référence 105. Le module logiciel 403 s'exécute sous le contrôle d'un
orchestre
de service 407.
Dans un mode de réalisation, les modules logiciel 402 et 403 sont composés
d'un
ensemble de ressources comprenant des scripts, des fichiers (ex : images,
fichier
de configuration...), et d'un flux de travail (workflow en anglais) qui
définit
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
9
l'ordonnancement des services. Chaque script est paramétré en fonction des
paramètres définis par l'utilisateur. Chaque service utilisé se traduit donc
par un
premier script s'exécutant sur le terminal de paiement (ou autre dispositif
informatique) et un second script s'exécutant sur la plateforme (ou autre
dispositif
informatique). Au moins un dispositif informatique est obligatoire. Ces
scripts
coopèrent au travers de la connexion 408 entre les dispositifs informatiques.
Le
script peut également coopérer avec des services externes comme expliqué en
rapport avec la Figure 1. Ainsi, l'utilisateur du terminal de paiement utilise
une
application qui lui semble exécutée sur ledit terminal mais qui met en oeuvre
finalement des modules logiciels locaux au terminal, d'autres sur la
plateforme
de service et potentiellement des services externes.
Les orchestres de service 406 et 407, s'exécutant respectivement sur les
dispositifs informatiques, sont en charge de l'exécution des différents
scripts
composant les différents services en accord avec le flux de travail défini.
Ces
orchestres de service, exécutent également les scripts avec les paramètres
correspondant à la programmation de l'application faite dans le module de
programmation 104.
Les scripts qui s'exécutent sur les dispositifs informatiques peuvent être
programmés dans le même langage de script où alors dans des langages
différents selon les modes de réalisations de l'invention. Ce choix dépend des
choix logiciels, en termes de système d'exploitation et d'environnement
logiciel
faits pour le terminal de paiement et pour la plateforme. Ces langages de
script
comprennent, par exemple, Javascript, Lua, Python, Kotlin, Groovy ou autres.
Dans certains modes de réalisation, de véritables exécutables peuvent être
compilés en lieu et place des scripts.
La Figure 5 illustre le déroulement d'un service, ici le service de paiement,
selon
un exemple de réalisation de l'invention.
Le terminal initie l'exécution du service par le bloc de traitement 501. Lors
de ce
traitement, il est d'abord vérifié que le montant et la devise sont fournis au
démarrage du service et que les valeurs sont correctes. Par exemple, le
montant
doit être supérieur à un euro et la devise doit être l'euro. Ensuite, le bloc
de
traitement 501 demande l'insertion de la carte au client. La carte est alors
lue et
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
la devise par défaut de la carte est extraite. Si un service externe est
connecté
au point de branchement après insertion de la carte , alors ce service est
déclenché. Le code PIN du client est ensuite vérifié. En cas de succès de la
vérification du code PIN du client, une requête en autorisation 502 est
transmise
5 au script correspondant qui s'exécute sur la plateforme.
Ce script s'exécutant sur la plateforme effectue un bloc de traitement 503. Ce
bloc de traitement se charge de sélectionner la banque devant traiter le
paiement.
Pour ce faire, le script s'exécutant sur la plateforme doit faire appel à
d'autres
services disponibles sur cette plateforme. Par exemple, la plateforme comporte
10 une base de données contenant la référence des banques avec lesquelles le
commerçant a signé un contrat d'acquisition. Cette base de données contient
également les informations techniques de connexion aux banques, telles que les
adresses IP principale et secondaire et les identifiants de connexion.
Avantageusement, les contrats d'acquisition peuvent être modélisés afin de
pouvoir évaluer quelle banque est la plus compétitive pour un type de
transaction
donné. Par exemple, un paiement international VISA peut être moins cher
auprès d'une banque alors qu'un paiement Mastercard sera moins cher
auprès d'une autre banque.
En fonction de toutes ces informations, le module de traitement 503 choisit
une
banque et lui transmets la requête en paiement 504. La banque choisie, traite
alors la requête lors d'un traitement 505. A l'issue de ce traitement, le
paiement
est validé ou refusé. La banque transmet ce résultat lors d'une réponse 506 à
destination de la plateforme. La plateforme, lors d'un traitement 507
retransmet
la réponse 508 au terminal de paiement.
La Figure 6 illustre les principales étapes de l'exécution d'une application
de
service dans un mode de réalisation de l'invention.
Dans une étape 601, une transaction est lancée.
Dans une étape 602, l'orchestre de services du terminal de paiement lance le
premier script composant l'application. L'orchestre de services de terminal
est en
charge du lancement successif des services au fur et à mesure de leur
exécution
sur le terminal de paiement ou le dispositif informatique.
Lors d'une étape 603, l'application s'exécute.
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
11
Lors d'une étape 604, lorsqu'un des services nécessite une connexion à la
plateforme, cette connexion est initiée par le service. Pour ce faire, une
authentification forte oeut être utilisée pour authentifier le terminal de
paiement
auprès de la plateforme. Avantageusement, cette authentification utilise un
système cryptographique (ex: clés asymétriques) géré au sein d'un module
matériel sécurisé. Ce module matériel sécurisé est composé d'une partie
physique et d'une partie logicielle dont le rôle est de protéger les clés et
les
opérations cryptographiques. Toute tentative d'intrusion logique ou physique
d'un
module matériel sécurisé peut mener à l'effacement immédiat des clés
cryptographiques qu'il contient. Un tel module matériel sécurisé est
fonctionnellement très proche d'une carte à puce tout en disposant d'une
capacité de traitement plus importante.
Lors de l'étape 605, le contexte applicatif, c'est-à-dire, typiquement, la
liste des
données capturées et/ou générées par l'application, est transférée au serveur.
Lors de l'étape 607, l'orchestre de services de la plateforme identifie le
script
serveur correspondant à l'application de service sur la base de
l'identification du
terminal de paiement et le lance avec les paramètres associés.
Lors de l'étape 608, l'application s'exécute par orchestration des différents
scripts
de service sur le terminal de paiement et sur la plateforme. Au besoin, les
scripts
s'exécutant sur la plateforme font appel aux services externes comme décrit en
relation avec la Figure 5.
Lors de l'étape 609, symétrique de l'étape 604, une connexion au client est
initiée
par le serveur.
Lors de l'étape 610, symétrique de l'étape 605, le contexte applicatif serveur
est
transféré au client.
Les étapes 602 à 610 peuvent s'exécuter un nombre quelconque de fois en
fonction des besoins de l'application.
Lors de l'étape 606, à la fin de l'application, le script client initie la fin
d'exécution.
La plateforme est notifiée de la fin d'exécution et peut alors libérer les
ressources
utilisées par le script sur la plateforme.
Dans un mode de réalisation, un même orchestre de services est déployé sur le
client et le, ou les, serveur. L'application est alors vue comme un ensemble
d'un
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
12
ou plusieurs modules logiciels s'exécutant sur un ou plusieurs dispositifs
informatiques et collaborant entre eux en fonction des besoins de
l'application.
Le passage du contrôle d'un dispositif à l'autre se fait comme illustré par la
figure
6 entre le client et le serveur. La transaction peut alors être initiée
indifféremment
par l'un ou l'autre de ces modules logiciels.
Dans un premier exemple, une enseigne de magasin pourrait déployer une
instance de l'orchestre de services sur chacun des terminaux de paiement, une
instance de l'orchestre de service sur un serveur au sein de chaque magasin et
une instance sur un serveur central distant. L'application serait alors
constituée
de l'ensemble des modules logiciels exécutés sur chacune de ces instances de
l'orchestre de services.
Dans un second exemple, une instance de l'orchestre de service serait déployée
sur chaque terminal de paiement, un seul de ces terminaux serait connecté à
internet. L'instance déployée sur le terminal de paiement connecté à internet
agirait alors en proxy pour les autres instances. Plusieurs terminaux
collaborent
alors à la réalisation de la transaction.
Dans un troisième exemple, un magasin dispose d'un écran doté d'un moyen de
lecture NFC, d'un terminal de paiement disposant de tous les moyens de valider
un paiement qui communique avec un serveur distant. Ces trois dispositifs sont
dotés d'une instance de l'orchestre de services et collaborent pour réaliser
la
transaction.
La Figure 7 illustre l'architecture logicielle du terminal de paiement dans un
exemple de réalisation de l'invention.
Dans l'exemple de réalisation de l'invention ici décrit, le terminal de
paiement
fonctionne sous le contrôle du système d'exploitation Android de Google
(marques déposée). Ce système d'exploitation 700 permet de faire fonctionner
un ensemble de modules logiciels nécessaires au fonctionnement des
applications de service selon l'exemple de réalisation de l'invention. Ces
modules
sont implémentés sous la forme d'une ou plusieurs applications Android selon
les modes de réalisation.
Le module central est l'orchestre de services 704. C'est ce module qui charge
les
différents scripts constituant l'application de service, qui permet de les
exécuter
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
13
et de les ordonnancer. Pour ce faire, l'orchestre de services 704 comporte un
moteur d'exécution du langage de script choisi :
= Le terminal est amené à traiter des scripts qu'il est le seul à pouvoir
exécuter car ils font appel à des ressources uniquement disponibles dans
le terminal (ex: communication avec le lecteur de carte à puce).
= A l'inverse, d'autres scripts ne peuvent être exécutés que par le serveur
(ex : connexion à un service tiers hébergé à l'extérieur de l'environnement
du serveur et non accessible par le terminal.
= Dans certains cas, certains scripts peuvent s'exécuter indifféremment sur
le terminal ou le serveur.
Une transaction se compose donc de 3 éléments majeurs :
- Un workflow qui décrit l'enchainement des scripts et leur portée (i.e.
exécution exclusive par le terminal, le serveur ou indifférenciée)
- Un ensemble de scripts (clients et serveur)
- Un contexte contenant l'ensemble des données capturées ou
générées pendant une transaction.
Les scripts sont disponibles dans les 2 environnements (i.e. terminal et
serveur)
avant le démarrage d'une transaction afin de réduire le délai de démarrage de
la
transaction. Cependant, il est aussi possible que le terminal télécharge les
scripts
.. et le workflow au démarrage d'une transaction.
L'orchestre de services est responsable du transfert du contexte du terminal
vers
le serveur (et vice versa) lors du passage de relais . Les applications de
service partagent un certain nombre de fonctionnalités communes mises à
disposition soit par le terminal, soit par le serveur. Elles doivent toutes
accéder
au lecteur de carte de paiement intégré au terminal, communiquer avec la
plateforme de service, gérer l'interface du terminal ou encore gérer des
opérations de cryptographie dans le cadre de leur authentification auprès de
la
plateforme par exemple. Ces fonctionnalités communes sont fournies par un
ensemble de modules logiciels typiquement rassemblés en une ou plusieurs
applications Android, ou services serveur .
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
14
Un module d'interface homme machine (IHM) 702 offre les fonctions de gestion
de l'écran du terminal de paiement ainsi que du clavier. Ce module permet les
interactions avec le client utilisateur du terminal.
Un module de sécurité 705 gère les opérations de cryptographie liées au
fonctionnement des services. Ces opérations comprennent les authentifications
auprès de la plateforme et si nécessaire auprès de services tiers. Ce module
de
sécurité peut interagir avec un microcontrôleur sécurisé 708 présent dans le
terminal et agissant comme un élément de sécurité (secure element en anglais),
c'est-à-dire un composant matériel chargé des opérations cryptographiques
proprement dites et du stockage des clés, ce composant étant dotés de
fonctionnalités de sécurité visant à le rendre inviolable.
Le module d'intégration lecteur de carte 703 offre les interactions avec le ou
les
lecteurs de carte présents dans le terminal de paiement. Ces lecteurs peuvent
être filaires ou sans fil.
Le module d'interface plateforme 706 offre les communications avec la
plateforme. C'est typiquement le module qui va permettre à un script client de
communiquer avec le script serveur correspondant et via ce script serveur avec
d'éventuels services tiers.
Un module de mise-à-jour 701 permet de mettre les workflows, les scripts et
les
différents modules à jour lorsque de nouvelles versions sont disponibles.
Un module de communication 707 gère les communications entre ces différents
modules et l'extérieur du terminal de paiement et notamment le lecteur de
carte
et la plateforme de service. C'est ce module qui établit les tunnels de
communication sécurisé, par exemple avec la plateforme.
La Figure 8 illustre l'architecture logicielle de la plateforme serveur dans
un
exemple de réalisation de l'invention. Cette figure n'illustre pas le module
de
programmation 104 mais uniquement l'architecture utile à l'exécution des
applications de service.
Le coeur 800 de la plateforme est constitué d'un ensemble de modules. Ces
modules centraux comprennent l'orchestre de service 803 qui gère le
chargement, l'exécution et l'ordonnancement des scripts serveur de
l'application
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
de service. C'est le pendant côté serveur de l'orchestre de service 704 sur le
terminal.
De manière similaire à l'architecture du terminal, les scripts s'exécutant sur
la
plateforme peuvent utiliser un ensemble de services à leur disposition sous la
5 forme de modules logiciels accessibles.
Ces services comprennent un module d'authentification 801 qui gère les
authentifications. Ce module coopère typiquement avec un module matériel
sécurisé 809 (HSM pour Hardware Secure Module en anglais). Ce module
d'authentification va gérer les opérations cryptographiques pour le compte de
10 tous les modules qui le nécessitent.
Les modules 801 et 802 permettent sont le point d'accès au module 809. Ils se
chargent de préparer et optimiser les opérations déléguées au module 809 (ex:
conversion des données du format XML ou JSON en un format unique binaire
adapté au HSM).
15 Un module 804 de surveillance, permet de surveiller l'exécution des
scripts et
l'utilisation des différents modules et des scripts en cours d'exécution pour
détecter de possibles anomalies pouvant provenir de dysfonctionnements ou
d'éventuelles attaques de la plateforme.
D'autres modules sont également présents, non représentés, comme par
exemple un module d'enregistrement des opérations techniques et métiers
effectuées (log en anglais), un module éventuel de traduction de protocole si
nécessaire pour interagir avec certains services tiers, un module de mise à
jour
des composants logiciels. Cette liste n'est pas exhaustive.
Ces services s'appuient également sur une base de données 808 qui contient,
entre autres :
- Les caractéristiques des services tiers (adresse IP, token
d'authentification...)
- Les configurations de chaque banque autorisée pour chaque terminal (ex:
numéro du contrat commerçant, devises autorisées, montants plafonds...)
- La liste des services autorisés pour chaque terminal
- Le workflow actif (et les scripts associés) pour chaque terminal
- Etc.
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
16
La plateforme coopère dans son fonctionnement avec des entités externes. Elle
est donc dotée de services gérant la communication avec ces entités externes.
Un module 805 gère les communications de la plateforme avec les commerçants.
C'est ce module qui gère la communication avec les terminaux de paiement 810
dans le cadre de l'exécution des applications de service. C'est aussi ce
module
qui gère l'administration par un commerçant de son service à partir d'un
terminal
d'administration 811.
Un module 806 gère les communications de la plateforme avec les services
tiers.
Ces services sont typiquement sollicités par les scripts exécutés par le
service
d'orchestration de la plateforme lors de l'exécution des applications de
service.
On peut citer parmi ces services tiers, un service 812 de gestion des
courriers
électroniques, des services bancaires 813 comme les services de paiement, les
services électroniques marchands. Parmi ces services, on trouve aussi des
services tel que l'extranet 814 d'un commerçant. En effet, certaines
applications
de services peuvent nécessiter des données propres au commerçant, par
exemple pour appliquer des règles telles que l'attribution d'une promotion
selon
des critères propres au commerçant, ou encore la proposition d'un
questionnaire
aux clients ayant dépensés au moins 100 euros dans le mois.
La plateforme comporte également un module 807 qui donne un accès au gérant
de la plateforme pour son administration.
Dans l'exemple de réalisation, ces différents modules sont implémentés sous la
forme de services dans une architecture orientée service (SOA pour Service
Oriented Architecture en anglais). Tous ces services communiquent, par
exemple, par le biais d'un service de messages (message broker en anglais).
Dans un exemple de réalisation, le système d'exploitation est Linux,
l'hyperviseur
gérant la virtualisation des serveurs est Proxmox en développement et VMWare
en production, les services sont gérés par Kubernetes/Docker, le service de
messages est ActiveMQ, les services sont développés en Java/Spring, Node.js
et/ou C/C++, la base de données peut être Cassandra, MongoDB ou
ElasticSearch.
Ainsi, le système proposé permet à un commerçant de définir rapidement une
application de service (aussi appelé workflow ) pour ses terminaux de
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
17
paiement, de la déployer sans délai. Ensuite, cette application peut être
modifiée
à tout moment. De nouveaux services apparaissant sur le marché peuvent être
intégrés à la plateforme et rendu disponibles aux commerçants qui peuvent
alors
l'intégrer à leur application de paiement. Tout ceci peut être fait sans
devoir
supporter les coûts est les délais afférents aux développements d'applications
de
service propriétaires.
La figure 9 est un bloc-diagramme schématique d'un dispositif de traitement de
l'information 900 pour la mise en oeuvre d'un ou plusieurs modes de
réalisation
de l'invention. Le dispositif 900 de traitement de l'information peut être un
périphérique tel qu'un micro-ordinateur, un poste de travail ou un terminal
mobile
de télécommunication. Le dispositif 900 comporte un bus de communication
connecté à:
- une unité centrale de traitement 901, tel qu'un microprocesseur, notée
CPU ;
- une mémoire à accès aléatoire 902, notée RAM, pour mémoriser le code
exécutable du procédé de réalisation de l'invention ainsi que les registres
adaptés à enregistrer des variables et des paramètres nécessaires pour la mise
en oeuvre du procédé selon des modes de réalisation de l'invention ; la
capacité
de mémoire du dispositif peut être complétée par une mémoire RAM optionnelle
connectée à un port d'extension, par exemple ;
- une mémoire morte 903, notée ROM, pour stocker des programmes
informatiques pour la mise en oeuvre des modes de réalisation de l'invention ;
- une interface réseau 904 est normalement connectée à un réseau de
communication sur lequel des données numériques à traiter sont transmis ou
reçus. L'interface réseau 904 peut être une seule interface réseau, ou
composée
d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans
fil,
interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets
de
données sont envoyés sur l'interface réseau pour la transmission ou sont lues
à
partir de l'interface de réseau pour la réception sous le contrôle de
l'application
logiciel exécuté dans le processeur 901 ;
- une interface utilisateur 905 pour recevoir des entrées d'un utilisateur ou
pour
afficher des informations à un utilisateur ;
- un dispositif de stockage 906 tel que décrit dans l'invention et noté HD
;
CA 03143068 2021-12-13
WO 2020/254761 PCT/FR2020/051051
18
- un module d'entrée/sortie 907 pour la réception / l'envoi de données depuis
/
vers des périphériques externes tels que disque dur, support de stockage
amovible ou autres.
Le code exécutable peut être stocké dans une mémoire morte 903, sur le
dispositif de stockage 906 ou sur un support amovible numérique tel que par
exemple un disque. Selon une variante, le code exécutable des programmes peut
être reçu au moyen d'un réseau de communication, via l'interface réseau 904,
afin d'être stocké dans l'un des moyens de stockage du dispositif de
communication 900, tel que le dispositif de stockage 906, avant d'être
exécuté.
L'unité centrale de traitement 901 est adaptée pour commander et diriger
l'exécution des instructions ou des portions de code logiciel du programme ou
des programmes selon l'un des modes de réalisation de l'invention,
instructions
qui sont stockées dans l'un des moyens de stockage précités. Après la mise
sous
tension, le CPU 901 est capable d'exécuter des instructions de la mémoire RAM
principale 902, relatives à une application logicielle. Un tel logiciel,
lorsqu'il est
exécuté par le processeur 901, provoque l'exécution des procédés décrits.
Dans ce mode de réalisation, l'appareil est un appareil programmable qui
utilise
un logiciel pour mettre en oeuvre l'invention. Toutefois, à titre subsidiaire,
la
présente invention peut être mise en oeuvre dans le matériel (par exemple,
sous
la forme d'un circuit intégré spécifique ou ASIC).
Naturellement, pour satisfaire des besoins spécifiques, une personne
compétente dans le domaine de l'invention pourra appliquer des modifications
dans la description précédente.
Bien que la présente invention ait été décrite ci-dessus en référence à des
modes
de réalisation spécifiques, la présente invention n'est pas limitée aux modes
de
réalisation spécifiques, et les modifications qui se trouvent dans le champ
d'application de la présente invention seront évidentes pour une personne
versée
dans l'art.
