CA3143068A1 - Systeme d'applications de service pour terminaux de paiement - Google Patents
Systeme d'applications de service pour terminaux de paiement Download PDFInfo
- Publication number
- CA3143068A1 CA3143068A1 CA3143068A CA3143068A CA3143068A1 CA 3143068 A1 CA3143068 A1 CA 3143068A1 CA 3143068 A CA3143068 A CA 3143068A CA 3143068 A CA3143068 A CA 3143068A CA 3143068 A1 CA3143068 A1 CA 3143068A1
- Authority
- CA
- Canada
- Prior art keywords
- service
- payment
- platform
- software module
- terminal
- 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.)
- Pending
Links
- 238000013515 script Methods 0.000 claims abstract description 45
- ZYXYTGQFPZEUFX-UHFFFAOYSA-N benzpyrimoxan Chemical compound O1C(OCCC1)C=1C(=NC=NC=1)OCC1=CC=C(C=C1)C(F)(F)F ZYXYTGQFPZEUFX-UHFFFAOYSA-N 0.000 claims description 18
- 238000004891 communication Methods 0.000 claims description 15
- 238000000034 method Methods 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 2
- 238000012545 processing Methods 0.000 description 16
- 238000003780 insertion Methods 0.000 description 4
- 230000037431 insertion Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000004888 barrier function Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- 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/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- 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
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0633—Workflow analysis
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/006—Details of the software used for the vending machines
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Stored Programmes (AREA)
Abstract
L'invention concerne une plateforme de services pouvant être intégrés à une solution de paiement. La plateforme offre également un outil de programmation graphique de solutions de paiement qui permet à un utilisateur de la plateforme de définir une solution 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 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.
Description
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
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
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
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
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
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
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 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
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 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 à 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
Au moins certains des services élémentaires constituant l'application pour terminal de paiement peuvent faire appel à un ou plusieurs services externes à 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
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 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
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 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
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
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
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
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
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 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
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 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.
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.
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
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
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
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
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 .
= 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 .
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 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).
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 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.
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.
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
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
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
;
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
;
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.
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.
Claims (19)
1. Plateforme de service pour terminaux de paiement caractérisée en ce qu'elle comprend :
- des moyens (104) de programmation graphique d'une application de service à partir d'un ensemble de services élémentaires accessibles depuis un terminal distant ;
- des moyens de générer à partir d'une application de service, un module logiciel client destiné à s'exécuter sur un terminal de paiement et un module logiciel serveur destiné à s'exécuter sur la plateforme de service ;
- des moyens de transmission du module logiciel client sur le terminal de paiement ; et - des moyens d'exécuter le module logiciel serveur, le module logiciel serveur lorsqu'il est exécuté coopérant avec le module logiciel client exécuter sur le terminal de paiement pour réaliser l'application de service.
- des moyens (104) de programmation graphique d'une application de service à partir d'un ensemble de services élémentaires accessibles depuis un terminal distant ;
- des moyens de générer à partir d'une application de service, un module logiciel client destiné à s'exécuter sur un terminal de paiement et un module logiciel serveur destiné à s'exécuter sur la plateforme de service ;
- des moyens de transmission du module logiciel client sur le terminal de paiement ; et - des moyens d'exécuter le module logiciel serveur, le module logiciel serveur lorsqu'il est exécuté coopérant avec le module logiciel client exécuter sur le terminal de paiement pour réaliser l'application de service.
2. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce que le module logiciel client est composé d'un ensemble d'au moins un script client.
3. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce que :
- le module logiciel serveur est composé d'un ensemble d'au moins un script serveur ; et - elle comporte un module orchestre de service pour ordonnancer et exécuter l'ensemble des scripts serveur.
- le module logiciel serveur est composé d'un ensemble d'au moins un script serveur ; et - elle comporte un module orchestre de service pour ordonnancer et exécuter l'ensemble des scripts serveur.
4. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre des moyens (806)de communiquer avec des services externes accessible depuis le module logiciel serveur.
5. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre des moyens (807) d'administration de la plateforme de service.
6. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre un module (805) de gestion des communications avec le terminal de paiement et le terminal distant.
7. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre un module matériel sécurisé
(809).
(809).
8. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre une base de données (808).
9. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce que les moyens de programmation graphique comprennent une liste de services élémentaires pouvant être sélectionnés.
10. Plateforme de service pour terminaux de paiement selon la revendication 9, caractérisée en ce que chaque service élémentaire est représenté par un objet graphique comportant au moins une entrée et au moins une sortie, une sortie d'un objet graphique pouvant être connectée à une entrée d'un autre objet graphique.
11. Plateforme de service pour terminaux de paiement selon la revendication 10, caractérisée en ce que au moins un objet graphique comprend en outre un point de branchement, le point de branchement pouvant être connecté à une entrée d'un autre objet graphique et une sortie d'un autre objet graphique pouvant être connecté au point de branchement.
12. Plateforme de service pour terminaux de paiement selon la revendication 10, caractérisée en ce qu'au moins un objet graphique comporte au moins un contrôle permettant de définir un paramètre du service élémentaire représenté.
13. Terminal de paiement caractérisé en ce qu'il comprend :
- des moyens de connexion à une plateforme de service pour terminaux de paiement selon l'une des revendications 1 à 12 ; et - des moyens d'exécuter un module logiciel client transmis par la plateforme.
- des moyens de connexion à une plateforme de service pour terminaux de paiement selon l'une des revendications 1 à 12 ; et - des moyens d'exécuter un module logiciel client transmis par la plateforme.
14. Terminal de paiement selon la revendication 13, caractérisée en ce que le module logiciel client est composé d'un ensemble d'au moins un script client.
15. Terminal de paiement selon la revendication 14, caractérisée en ce qu'il comporte un module orchestre de service pour ordonnancer et exécuter l'ensemble des scripts client.
16. Système d'application de service pour terminaux de paiement caractérisé
en ce qu'il comporte :
- une plateforme de service pour terminaux de paiement selon l'une des revendications 1 à 12 ; et - au moins un terminal de paiement selon l'une des revendications 13 à 15.
en ce qu'il comporte :
- une plateforme de service pour terminaux de paiement selon l'une des revendications 1 à 12 ; et - au moins un terminal de paiement selon l'une des revendications 13 à 15.
17. Procédé d'exécution d'une application de service au sein d'un système d'application de service pour terminaux de paiement selon la revendication 16, caractérisé en ce qu'il comprend :
- une étape de lancement d'un module logiciel client par le terminal de paiement ;
- une étape de connexion du terminal de paiement à la plateforme de service pour terminaux de paiement ;
- une étape de lancement d'un module logiciel serveur sur la plateforme de service pour terminaux de paiement ;
- une étape d'exécution du module logiciel client et du module logiciel serveur, le module logiciel client et le module logiciel serveur coopérant pour réaliser l'application de service.
- une étape de lancement d'un module logiciel client par le terminal de paiement ;
- une étape de connexion du terminal de paiement à la plateforme de service pour terminaux de paiement ;
- une étape de lancement d'un module logiciel serveur sur la plateforme de service pour terminaux de paiement ;
- une étape d'exécution du module logiciel client et du module logiciel serveur, le module logiciel client et le module logiciel serveur coopérant pour réaliser l'application de service.
18. Procédé selon la revendication 17, caractérisé en ce qu'il comporte en outre une étape de terminaison de l'application par le module logiciel client.
19. Procédé selon la revendication 17, caractérisé en ce qu'il comporte en outre une étape de coopération du module logiciel serveur avec au moins un service externe à la plateforme de service pour terminaux de paiement.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FRFR1906735 | 2019-06-21 | ||
| FR1906735A FR3097672A1 (fr) | 2019-06-21 | 2019-06-21 | Système d’applications de service pour terminaux de paiement |
| PCT/FR2020/051051 WO2020254761A1 (fr) | 2019-06-21 | 2020-06-17 | Système d'applications de service pour terminaux de paiement |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA3143068A1 true CA3143068A1 (fr) | 2020-12-24 |
Family
ID=68501710
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA3143068A Pending CA3143068A1 (fr) | 2019-06-21 | 2020-06-17 | Systeme d'applications de service pour terminaux de paiement |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20220366393A1 (fr) |
| EP (1) | EP3987390A1 (fr) |
| AU (1) | AU2020296966A1 (fr) |
| BR (1) | BR112021025579A2 (fr) |
| CA (1) | CA3143068A1 (fr) |
| FR (1) | FR3097672A1 (fr) |
| WO (1) | WO2020254761A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11748155B1 (en) | 2022-04-20 | 2023-09-05 | Snowflake Inc. | Declarative engine for workloads |
Family Cites Families (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7716096B2 (en) * | 1996-11-27 | 2010-05-11 | Diebold Self-Service Systems A Division Of Diebold, Incorporated | Application service provider and automated transaction machine system and method |
| JP3489962B2 (ja) * | 1997-04-23 | 2004-01-26 | 沖電気工業株式会社 | プログラム開発装置および並列リアルタイム処理装置 |
| US6808111B2 (en) * | 1998-08-06 | 2004-10-26 | Visa International Service Association | Terminal software architecture for use with smart cards |
| ATE282231T1 (de) * | 2000-04-11 | 2004-11-15 | Visa Int Service Ass | Integriertes verfahren zur herstellung von chipkarten |
| US20020032655A1 (en) * | 2000-09-14 | 2002-03-14 | Thierry Antonin | System and method for providing financial services terminals with a document driven interface |
| US6973640B2 (en) * | 2000-10-04 | 2005-12-06 | Bea Systems, Inc. | System and method for computer code generation |
| US6889375B1 (en) * | 2000-11-17 | 2005-05-03 | Cisco Technology, Inc. | Method and system for application development |
| US20030037310A1 (en) * | 2001-08-18 | 2003-02-20 | David Ge | Visual programming tool and execution environment for developing computer software applications |
| WO2004095352A1 (fr) * | 2003-04-22 | 2004-11-04 | Visa International Service Association | Mise a niveau de carte a puce pour terminaux a carte a pistes magnetiques existantes |
| WO2006017496A2 (fr) * | 2004-08-03 | 2006-02-16 | Ebay Inc. | Procede et systeme de conception d'un processus de reglement de differends |
| US7565640B2 (en) * | 2004-10-01 | 2009-07-21 | Microsoft Corporation | Framework for seamlessly authoring and editing workflows at design and runtime |
| US7613671B2 (en) * | 2005-02-15 | 2009-11-03 | Fair Isaac Corporation | Approach for re-using business rules |
| US20060218228A1 (en) * | 2005-03-24 | 2006-09-28 | Security First Technologies Corp | Client platform architecture |
| US20060218061A1 (en) * | 2005-03-25 | 2006-09-28 | Security First Technologies Corp. | Integrated financial services platform |
| US20070061777A1 (en) * | 2005-09-09 | 2007-03-15 | Source Technologies, Llc | System, method, and computer program product for graphically generating a program for controlling the operation of a kiosk |
| GB0519519D0 (en) * | 2005-09-24 | 2005-11-02 | Eastman Kodak Co | Payment terminals |
| US20140089120A1 (en) * | 2005-10-06 | 2014-03-27 | C-Sam, Inc. | Aggregating multiple transaction protocols for transacting between a plurality of distinct payment acquiring devices and a transaction acquirer |
| US8589868B2 (en) * | 2005-12-22 | 2013-11-19 | Ncr Corporation | Creating a terminal application |
| US7658323B2 (en) * | 2006-05-24 | 2010-02-09 | Sun Microsystems, Inc. | Point-of-service (POS) and POS application compatability |
| US20080028057A1 (en) * | 2006-07-26 | 2008-01-31 | International Business Machines Corporation | System and method to facilitate design and operation of event-driven, embedded solutions |
| WO2008084466A1 (fr) * | 2007-01-09 | 2008-07-17 | On Track Innovations Ltd. | Procédé et appareil de contrôle à grande échelle de dispositifs à cartes à microprocesseur |
| US8341595B2 (en) * | 2007-05-30 | 2012-12-25 | Roam Data Inc | System and method for developing rich internet applications for remote computing devices |
| US20090119640A1 (en) * | 2007-11-07 | 2009-05-07 | Microsoft Corporation | Graphical application for building distributed applications |
| WO2010033944A2 (fr) * | 2008-09-22 | 2010-03-25 | Visa International Service Association | Gestion sans fil d’une application de paiement installée dans un dispositif mobile |
| US20100145854A1 (en) * | 2008-12-08 | 2010-06-10 | Motorola, Inc. | System and method to enable a secure environment for trusted and untrusted processes to share the same hardware |
| US8386288B2 (en) * | 2009-01-27 | 2013-02-26 | Direct Response Medicine, Llc | Workflow management system and method with workflow package exchange between drop-box application programs |
| US20100228683A1 (en) * | 2009-03-06 | 2010-09-09 | TxVia, Inc. | Issuing systems, acquiring systems, and payment networks/systems development |
| US10454693B2 (en) * | 2009-09-30 | 2019-10-22 | Visa International Service Association | Mobile payment application architecture |
| GB2481191A (en) * | 2010-02-25 | 2011-12-21 | Sita Information Networking Computing Ireland Ltd | Graphical development tool for software application development |
| US8744820B2 (en) * | 2011-02-24 | 2014-06-03 | Verizon Patent And Licensing Inc. | Integration of workflows from various systems |
| US10223674B2 (en) * | 2011-05-11 | 2019-03-05 | Riavera Corp. | Customized transaction flow for multiple transaction types using encoded image representation of transaction information |
| US20120291006A1 (en) * | 2011-05-12 | 2012-11-15 | Google Inc. | Development Architecture for Cloud-Based Applications |
| US8412631B2 (en) * | 2011-05-13 | 2013-04-02 | American Express Travel Related Services Company, Inc. | Cloud enabled payment processing system and method |
| EP2751682A4 (fr) * | 2011-08-29 | 2015-01-07 | Fiberlink Comm Corp | Plateforme permettant le déploiement et la distribution de modules jusqu'à des extrémités |
| US20130246345A1 (en) * | 2011-09-13 | 2013-09-19 | Wappwolf, Inc. | Systems and methods for online workflow implementation |
| BR112014008941A2 (pt) * | 2011-10-12 | 2017-05-02 | C-Sam Inc | plataforma que habilita transações móveis seguras de múltiplas camadas |
| US8904239B2 (en) * | 2012-02-17 | 2014-12-02 | American Express Travel Related Services Company, Inc. | System and method for automated test configuration and evaluation |
| CA3126471A1 (fr) * | 2012-10-17 | 2014-04-17 | Royal Bank Of Canada | Virtualisation et traitement securise de donnees |
| GB2508015A (en) * | 2012-11-19 | 2014-05-21 | Mastercard International Inc | Method and apparatus for secure card transactions |
| DK3011442T3 (da) * | 2013-06-18 | 2021-01-04 | Ciambella Ltd | Fremgangsmåde og anordning til generering af et brugerdefineret softwareudviklingskit (sdk) |
| ITGE20130075A1 (it) * | 2013-07-30 | 2015-01-31 | Paybay Networks Srl | Sistema per la distribuzione di applicazioni software su terminali di pagamento pos |
| US10504075B2 (en) * | 2014-03-10 | 2019-12-10 | Aliaswire, Inc. | Methods, systems, and devices to dynamically customize electronic bill presentment and payment workflows |
| US9582254B2 (en) * | 2014-05-22 | 2017-02-28 | Oracle International Corporation | Generating runtime components |
| US10216281B2 (en) * | 2014-11-02 | 2019-02-26 | Clover Network, Inc. | Systems and methods for adjusting point-of-sale interfaces |
| CA2929803C (fr) * | 2015-05-12 | 2021-10-12 | The Toronto-Dominion Bank | Systemes et methodes d'acces a des ressources informatiques dans un environnement ouvert |
| US9851953B2 (en) * | 2015-06-29 | 2017-12-26 | Oracle International Corporation | Cloud based editor for generation of interpreted artifacts for mobile runtime |
| US10685352B2 (en) * | 2015-11-09 | 2020-06-16 | Paypal, Inc. | System, method, and medium for an integration platform to interface with third party channels |
| US10664812B2 (en) * | 2015-11-13 | 2020-05-26 | Paypal, Inc. | Software development kits for point-of-sale device and mobile device interactive frameworks |
| EP3182357A1 (fr) * | 2015-12-18 | 2017-06-21 | Mastercard International Incorporated | Système et procédé destinés à fournir des instructions à un dispositif de paiement |
| US20190050776A1 (en) * | 2016-02-26 | 2019-02-14 | Entit Software Llc | Differences in hierarchical levels of information technology workflows |
| US10331416B2 (en) * | 2016-04-28 | 2019-06-25 | Microsoft Technology Licensing, Llc | Application with embedded workflow designer |
| US11651343B2 (en) * | 2016-07-06 | 2023-05-16 | PowerPay, LLC | Systems and method for payment transaction processing with payment application driver |
| US10692055B2 (en) * | 2016-07-29 | 2020-06-23 | Square, Inc. | Reprogrammable point-of-sale transaction flows |
| US20200193408A1 (en) * | 2016-11-15 | 2020-06-18 | Promisepay Pty. Ltd. | Electronic payment processing |
| CN106897066B (zh) * | 2017-02-24 | 2019-10-29 | 百富计算机技术（深圳）有限公司 | 基于pos支付终端的网络应用运行方法及装置 |
| EP3631718A4 (fr) * | 2017-06-02 | 2020-12-16 | Bluefin Payment Systems, LLC | Systèmes et procédés de gestion d'un terminal de paiement par l'intermédiaire d'un navigateur web |
| US20190114598A1 (en) * | 2017-10-18 | 2019-04-18 | Mastercard International Incorporated | Payment network as a platform |
| US11544238B2 (en) * | 2017-11-30 | 2023-01-03 | Ncr Corporation | Custom data aggregation and integration processing |
-
2019
- 2019-06-21 FR FR1906735A patent/FR3097672A1/fr active Pending
-
2020
- 2020-06-17 CA CA3143068A patent/CA3143068A1/fr active Pending
- 2020-06-17 US US17/621,337 patent/US20220366393A1/en active Pending
- 2020-06-17 WO PCT/FR2020/051051 patent/WO2020254761A1/fr unknown
- 2020-06-17 AU AU2020296966A patent/AU2020296966A1/en active Pending
- 2020-06-17 EP EP20785770.7A patent/EP3987390A1/fr active Pending
- 2020-06-17 BR BR112021025579A patent/BR112021025579A2/pt unknown
Also Published As
| Publication number | Publication date |
|---|---|
| BR112021025579A2 (pt) | 2022-03-08 |
| AU2020296966A1 (en) | 2022-01-27 |
| FR3097672A1 (fr) | 2020-12-25 |
| US20220366393A1 (en) | 2022-11-17 |
| EP3987390A1 (fr) | 2022-04-27 |
| WO2020254761A1 (fr) | 2020-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3243176B1 (fr) | Procédé de traitement d'une transaction à partir d'un terminal de communication | |
| EP3113099B1 (fr) | Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants | |
| US20150039517A1 (en) | Cloud entertainment platform | |
| EP1771827A1 (fr) | Procede et systeme de paiement electronique universel | |
| WO2015023172A2 (fr) | Systemes et procedes de paiement mobile interpersonnel instantane (p2p) | |
| EP3039628A2 (fr) | Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants | |
| CA3143068A1 (fr) | Systeme d'applications de service pour terminaux de paiement | |
| EP3485451B1 (fr) | Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant | |
| WO2019016470A1 (fr) | Procédé et système de gestion d'un paiement par porte-monnaie électronique | |
| EP3382628A1 (fr) | Procédé de traitement de données par un terminal de paiement, terminal de paiement et programme correspondant | |
| EP3132403A1 (fr) | Dispositif de traitement de données en provenance de carte à mémoire sans contact, méthode et programme d'ordinateur correspondant | |
| EP3132404B1 (fr) | Module d'émulation d'au moins une carte de paiement, procédé, dispositif de paiement, produit programme d'ordinateur et medium de stockage correspondants | |
| WO2020128240A1 (fr) | Traitement d'un service de tickets electroniques | |
| EP3349161B1 (fr) | Procédé de traitement d'une transaction de paiement, borne de paiement et programme correspondant | |
| FR3023640A1 (fr) | Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants. | |
| FR2962830A1 (fr) | Serveur, terminal et procede de transaction securisee | |
| FR2812101A1 (fr) | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant | |
| EP2833262B1 (fr) | Procédé d'installation d'une application sur un élément sécurisé | |
| WO2022029102A1 (fr) | Méthode de paiement partagé entre débiteurs | |
| FR2992806A1 (fr) | Systeme de transmission securisee de donnees numeriques | |
| EP3223219A1 (fr) | Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux | |
| EP3337122A1 (fr) | Procédé et système pour effectuer des transactions sécurisées notamment dans l'internet des objets | |
| FR3031609A1 (fr) | Procede de traitement d'une transaction a partir d'un terminal de communication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20240605 |