FR3050054A1 - - Google Patents

Abstract

Des systèmes transactionnels en ligne, des méthodes et des produits-programme informatiques pour le traitement de méthodes de paiement électronique alternatives (AMOP) lors de transactions en ligne. Un dispositif de stockage de mémoire de masse héberge une base de données qui stocke des données pour transformer une ou plusieurs formes de paiement virtuelles en données liées à un ou à plusieurs AMOP. Chacune de l'une ou de plusieurs formes de paiement virtuelles stockées dans la base de données est compatible avec un système existant d'un commerçant. En réponse à la réception de données qui sont liées à un AMOP, dans le cadre d'une transaction en ligne avec le commerçant, les données AMOP sont transformées pour créer une forme de paiement virtuelle compatible avec le système existant du commerçant. La forme de paiement virtuelle est ensuite transmise au système existant du commerçant pour traitement et les données utilisées pour transformation de la forme de paiement virtuelle en données AMOP sont stockées dans la base de données.

Description

SYSTÈME TRANSACTIONNEL EN LIGNE DÉDIÉ AU TRAITEMENT DE MÉTHODES ALTERNATIVES DE PAIEMENT ÉLECTRONIQUE

DOMAINE TECHNIQUE

[1] La présente invention concerne des systèmes transactionnels de traitement en ligne et plus particulièrement des systèmes, des méthodes et des produits-programmes informatiques dédiés au traitement de méthodes alternatives de paiement électronique dans le cadre de transactions en ligne.

CONTEXTE

[2] La transaction en ligne typique implique une communication entre plusieurs parties qui fonctionnent indépendamment. Par exemple, lorsqu'un consommateur initie une transaction en ligne avec un commerçant se rapportant à un produit ou un service, le client fournit habituellement au commerçant des informations relatives à une carte de crédit. Par la suite, le commerçant traite les informations relatives à la carte de crédit et les communique à sa banque qui est acquérante. La banque acquérante contacte ensuite la banque émettrice de la carte de crédit du consommateur et demande le paiement approprié en provenance du compte du consommateur. Après réception du paiement de la banque émettrice, la banque acquérante verse le paiement au commerçant en contrepartie du produit ou du service.

[3] Dans le passé, les cartes de crédit ont été utilisées comme forme de paiement principale dans les transactions en ligne ; pour cette raison, les acteurs impliqués dans ces transactions, incluant des commerçants, ont généralement conçu leurs infrastructures autour du format de la carte de crédit. Il en résulte que les systèmes mis en place par ces acteurs pour traiter les transactions en ligne ont été régulièrement conçus pour traiter principalement des paiements effectués par carte de crédit, et très peu d'autres formes de paiement ont ainsi été utilisées. Cependant, l'environnement des transactions en ligne est en train de changer, car beaucoup de fournisseurs de paiement offrent désormais des moyens alternatifs de paiement électronique (Alternative Methods of Payments, ou AMOP) qui proposent aux consommateurs des options supplémentaires pour finaliser leurs achats.

[4] Il est donc nécessaire d'améliorer les systèmes transactionnels en ligne, les méthodes et les produits-programmes informatiques pour permettre aux systèmes existants de traiter les AMOP. RÉSUMÉ [5] Dans un mode de réalisation, un système transactionnel en ligne pour le traitement d'un AMOP inclut un dispositif de stockage de mémoire de masse qui héberge une base de données. La base de données est configurée afin de stocker des données pour la transformation d'une ou de plusieurs formes de paiement virtuelles en données liées à un ou plusieurs AMOP. Chacune, de l'une ou plusieurs formes de paiement virtuelles, est compatible avec un système existant d'un commerçant. Le système transactionnel en ligne inclut aussi un ou plusieurs processeurs et une mémoire couplée à un ou à plusieurs processeurs. La mémoire conserve des instructions, qui lorsqu'elles sont exécutées par un ou plusieurs processeurs, amènent le système transactionnel en ligne, en réponse à la réception de données liées à un AMOP dans le cadre d'une transaction en ligne avec le commerçant, à transformer les données AMOP pour créer une forme de paiement virtuelle qui est compatible avec le système existant du commerçant. Les instructions, lors de leur exécution, amènent par ailleurs le système transactionnel en ligne à transmettre la forme de paiement virtuelle au système existant du commerçant pour traitement et, après que la forme de paiement virtuelle a été créée, à conserver les données pour transformer la forme de paiement virtuelle en données liées à ΓΑΜΟΡ dans la base de données.

[6] Dans un autre mode de réalisation, une méthode pour le traitement d'un AMOP dans un système transactionnel de traitement inclut la réception, dans le cadre d'une transaction en ligne avec un commerçant, de données liées à ΓΑΜΟΡ et, en réponse à la réception des données liées à ΓΑΜΟΡ, la transformation des données liées à ΓΑΜΟΡ pour créer une forme de paiement virtuelle qui est compatible avec un système existant du commerçant. La méthode inclut par ailleurs la transmission de la forme de paiement virtuelle au système existant du commerçant pour traitement et, après la création de la forme de paiement virtuelle, le stockage des données pour la transformation de la forme de paiement virtuelle en données liées à ΓΑΜΟΡ dans une base de données hébergée sur un dispositif de stockage de mémoire de masse.

[7] Dans un autre mode de réalisation, un produit - programme informatique inclut un support non transitoire lisible par ordinateur et des instructions stockées sur le support non transitoire lisible par ordinateur. Lors de leur exécution par un ou plusieurs processeurs d'un système transactionnel de traitement en ligne, les instructions amènent le système transactionnel de traitement en ligne, en réponse à la réception de données liées à un AMOP dans le cadre d'une transaction en ligne avec un commerçant, à transformer les données liées à ΓΑΜΟΡ pour créer une forme de paiement virtuelle qui est compatible avec un système existant du commerçant. Les instructions, lors de leur exécution, amènent par ailleurs le système transactionnel de traitement en ligne à transmettre la forme de paiement virtuelle au système existant du commerçant pour traitement et, après la création de la forme de paiement virtuelle, à stocker les données pour la transformation de la forme de paiement virtuelle en données liées à ΓΑΜΟΡ dans une base de données abritée sur un dispositif de stockage de mémoire de masse.

BRÈVE DESCRIPTION DES DESSINS

[8] Les modes de réalisation de la présente invention seront mieux compris et seront plus amplement appréciés avec la lecture de la description détaillée associée aux dessins qui suit.

[9] FIG. 1 est une vue schématique d'un environnement d'exploitation exemplaire qui inclut une pluralité de systèmes informatiques qui peuvent être engagés dans une transaction en ligne.

[10] FIG. 2 est une vue schématique d'un système informatique exemplaire de la FIG. 1.

[11] FIG. 3 et une vue schématique d'une architecture de traitement exemplaire qui peut être mis en œuvre par un ou plusieurs des systèmes informatiques de la FIG.I.

[12] FIG. 4 est un organigramme d'un processus exemplaire pour la création d'une forme de paiement virtuelle qui peut être effectué par l'architecture de traitement de la FIG. 3.

[13] FIG. 5 et un organigramme d'un processus exemplaire pour la transformation d'une forme de paiement virtuelle en données liées à un AMOP qui peut être effectué par l'architecture de traitement de la FIG. 3.

DESCRIPTION DÉTAILLÉE

[14] Un ou plusieurs des modes de réalisation décrits dans les présentes visent des systèmes transactionnels de traitement en ligne permettant à des systèmes existants de commerçants de traiter les AMOP de façon sécurisée et sans que le commerçant ne dépense du temps et des ressources considérables pour mettre à jour ses systèmes existants afin de les rendre compatibles avec chaque AMOP accepté. De cette façon, les modes de réalisation décrits dans les présentes peuvent améliorer le fonctionnement des systèmes existants du commerçant en améliorant leurs capacités sans augmenter la demande sur les ressources des systèmes existants (par ex., la mémoire, les processeurs).

[15] Notamment, quand un client initie une transaction en ligne avec un commerçant et choisit d'utiliser un AMOP pour le paiement, les données liées à ΓΑΜΟΡ pour la transaction en ligne peuvent être générées et transmises aux systèmes existants du commerçant pour traitement. L'AMOP sélectionné, ou plus spécifiquement les données liées à ΓΑΜΟΡ peuvent cependant ne pas être compatibles avec les systèmes existants du commerçant. En d'autres termes, les systèmes existants du commerçant qui peuvent n'avoir été conçus que pour comprendre et traiter des formes de paiement traditionnelles (par ex., les cartes de crédit), peuvent ne pas comprendre ou ne pas être capables de traiter les données liées à l’AMOP pour la transaction en ligne. Par conséquent, si les systèmes existants du commerçant recevaient les données liées à ΓΑΜΟΡ, il en résulterait une erreur de traitement.

[16] Donc, avant que les systèmes existants du commerçant ne reçoivent les informations de paiement pour la transaction en ligne, un système peut intercepter et transformer les données liées à ΓΑΜΟΡ pour créer une forme de paiement virtuelle qui est compatible avec les systèmes existants du commerçant. De cette façon, la forme de paiement virtuelle, que les systèmes existants du commerçant sont capables de comprendre, peut être transmise aux systèmes existants du commerçant et peut être traitée sans erreur. Il en résulte une amélioration de la fonctionnalité des systèmes existants du commerçant en leur permettant de traiter ΓΑΜΟΡ sélectionné par l'intermédiaire de la forme de paiement virtuelle et de faire en sorte qu'il n'y ait pas de demande substantielle sur les ressources du système existant, car la transformation peut survenir avant et en dehors des systèmes existants recevant la forme de paiement virtuelle.

[17] De plus, les données peuvent être stockées dans une base de données pour vérification et/ou transformation d'une forme de paiement virtuelle en données liées à un AMOP qui peuvent être identiques ou différentes des données liées à ΓΑΜΟΡ générées initialement pour la transaction en ligne. De cette façon, quand un commerçant essaie de collecter un paiement en contrepartie de la forme de paiement virtuelle pour la transaction en ligne, la forme de paiement virtuelle peut être transformée en données liées à ΓΑΜΟΡ, sur la base des données stockées, et peut être par la suite transmise pour la collecte du paiement à un acquéreur approprié, tel qu'une banque. Ces caractéristiques et d'autres sont décrites de façon plus détaillée ci-dessous.

[18] FIG. 1 fournit un environnement d'exploitation exemplaire 10 qui peut inclure un ou plusieurs systèmes existants du commerçant 11, un système de virtualisation 16, un système AMOP 18, un système d'une banque acquérante 20 et/ou un système d'une banque émettrice 22. Chacun de ces systèmes peut communiquer avec les autres par l'intermédiaire d'un réseau 24 qui peut inclure l'Internet. De plus, deux ou plusieurs de ces systèmes quels qu'ils soient, peuvent être intégrés les uns aux autres pour former un seul système.

[19] Les systèmes existants du commerçant 11 peuvent inclure tout système d'un commerçant, tel qu’un agent de voyage ou une compagnie aérienne, qui est configuré pour faciliter les opérations commerciales du commerçant. Dans un mode de réalisation, les systèmes existants du commerçant 11 peuvent inclure un système pour les opérations internes 12 et/ou un système pour la gestion des clients 14. Le système des opérations internes 12 peut être fourni par le commerçant lui-même et peut être configuré pour effectuer une ou plusieurs opérations d’appui du commerçant. Par exemple, le système interne d'opérations 12 peut être configuré pour accomplir des fonctions telles que la conservation d'enregistrements internes, la comptabilisation, la facturation, etc. De plus, le système d'opérations internes 12 peut être configuré pour commencer les opérations liées à des paiements avec le système AMOP 18 et/ou le système de la banque acquérante 20, telles que les captures, les remboursements, les règlements et/ou les rapprochements.

[20] Le système de gestion des clients 14, qui peut être fourni séparément par un tiers et/ou peut être intégré avec le système d'opérations internes 12, peut être configuré pour apporter des fonctions qui permettent aux clients d'interagir avec le commerçant et de lui acheter des produits ou des services. Dans un exemple, le système de gestion des clients 14 peut inclure un système frontal, tel qu'une interface utilisateur au moyen de laquelle les clients peuvent initier des transactions en ligne, ou une interface de programmation d'applications pour interagir avec d'autres systèmes dans l'environnement d'exploitation 10. De plus, le système de gestion de clientèle 14 peut inclure un système de réservation qui conserve une ou plusieurs réservations ou des enregistrements d'achat. Par exemple, si le commerçant est une compagnie aérienne, un hôtel, une agence de location de voitures, etc. le système de réservation du système de gestion de clientèle 14 peut alors générer et conserver des enregistrements de nom de passager (Passenger Name Record, ou PNR) pour chaque réservation ou achat effectué avec le commerçant. Chaque PNR peut inclure les informations relatives à la réservation ou à l'achat (telles qu'un itinéraire de voyage pour un ou plusieurs passagers d'une compagnie aérienne), des tarifs ou des frais utilisés pour tarifer la réservation ou l'achat, et un élément de forme de paiement (Form of Payment, ou FOP) qui indique la forme de paiement spécifique, telles que les informations de carte de crédit qui ont été utilisées pour faire la réservation ou l'achat. Le système de gestion de clientèle 14 peut par ailleurs inclure un système de billetterie pour l'émission de billets électroniques et un système d’inventaire pour suivre l’inventaire disponible du commerçant (par ex., les places assises restantes sur chaque segment de vol à une date donnée). Dans le cas spécifique d'une compagnie aérienne commerçante, le système de gestion de clientèle 14 peut inclure en supplément un système de contrôle de départ (Departure Control System, ou DCS) qui gère les opérations aéroportuaires de la compagnie aérienne le jour du voyage (par ex., l'enregistrement des passagers et l’impression des cartes d’enregistrement).

[21] Le système AMOP 18 peut être configuré pour permettre aux clients d’utiliser les AMOP pour des transactions en ligne. En général, les AMOP permettent aux clients de contourner ou de supplémenter des formes de paiement traditionnelles (par ex., des cartes de crédit) lors de transactions en ligne avec des alternatives telles que des points de fidélité, des devises numériques ou bitcoins, PAYPAL, APPLE PA Y, etc. Les clients peuvent vouloir utiliser des AMOP pour diverses raisons : préférence personnelle, fidélité, meilleurs avantages et/ou une sécurité en ligne accrue. En général, le système AMOP 18 peut être implémenté par un fournisseur d'AMOP particulier tel que PAYPAL, VISA, MASTERCARD, etc. Le système AMOP 18 peut alternativement appartenir à un tiers impliqué dans la vente de produits ou de services d'un ou de plusieurs commerçants et qui a incorporé l'usage des AMOP dans son système, tel que le système de distribution global (Global Distribution System, ou GDS), un fournisseur de solution de règlements et de facturation et/ou d'autres portails d'accès permettant de rechercher et d'acheter des produits ou des services provenant d’un ou de plusieurs commerçants.

[22] Les systèmes existants du commerçant 11 peuvent avoir été conçus spécifiquement pour être capables de comprendre et de traiter uniquement les formes de paiement traditionnelles. Par conséquent, si les systèmes existants 11 devaient recevoir des données liées à un AMOP, en provenance du système AMOP 18 par exemple, comme paiement pour une transaction en ligne, les systèmes existants 11 pourraient être incapables de traiter les données liées à ΓΑΜΟΡ et de finaliser la transaction. Notamment, aucun des systèmes existants 11 ne serait capable de comprendre comment collecter et/ou comptabiliser des paiements sur la base des données liées à ΓΑΜΟΡ.

[23] Afin d'apporter des fonctionnalités supplémentaires de traitement des AMÔP aux systèmes existants 11, une solution pourrait consister à refondre complètement chaque système existant 11 pour qu'il puisse comprendre certains AMOP. Cette solution, cependant, serait très complexe et demanderait un temps considérable de la part de spécialistes pour reprogrammer chacun des systèmes existants 11. Notamment la reprogrammation d'un système existant 11 pour gérer un nouvel AMOP peut affecter les fonctions de chacun des systèmes existants 11, telles que la comptabilisation des recettes, la facturation, la conservation d'enregistrements, la gestion de l'inventaire, etc. De plus, de telles refontes complexes de système nécessiteraient d'être effectuées pour chaque AMOP additionnel que l'on souhaite ajouter aux systèmes existants 11, ce qui finirait par épuiser les ressources physiques des systèmes existants (par ex., chaque nouvel AMOP peut nécessiter de la mémoire et/ou le traitement d'une bande passante).

[24] Le système de virtualisation 16 de l'environnement d'exploitation 10 évite ces problèmes. Plus particulièrement, le système de virtualisation 16 peut être configuré comme un portail ou un pare-feu entre le système AMOP 18 et les systèmes existants 11 et peut être configuré pour transformer les données liées à un AMOP dans le cadre d'une transaction en ligne en forme de paiement virtualisée, telle qu'une carte de crédit virtuelle, compatible avec les systèmes existants 11. Une fois générée, la forme de paiement devenue virtuelle (et compatible) peut être transmise aux systèmes existants 11 qui sont maintenant capables de comprendre et de traiter le paiement fourni pour la transaction en ligne. Parce que chacun des systèmes existants 11 est configuré pour traiter la forme de paiement virtualisée, une virtualisation ou une conversion ultérieure de la forme de paiement virtualisée n'est peut-être pas nécessaire lorsqu'elle est communiquée entre systèmes existants 11. En d'autres termes, les mêmes messages qui ont été communiqués entre les systèmes existants 11 et qui ont été construits autour des formes de paiement traditionnelles peuvent continuer à être utilisés. Par exemple, les systèmes existants 11 dans l'industrie du voyage peuvent continuer à communiquer par l'intermédiaire de fichiers traditionnels HOT (les Hand OffTapts sont des rapports de vente envoyés à des systèmes de comptabilisation des recettes d'une compagnie aérienne), des fichiers RET (données de vente envoyées par les agents de voyages), des fichiers de publication de PNR (images de PNR publiées pour des tiers, tels que des compagnies aériennes, des systèmes de comptabilité, et les douanes) et des fichiers AIR (notifications des émissions de billets envoyées au centre de gestion [back-office] de la compagnie aérienne).

[25] Le système de virtualisation 16 peut aussi être configuré pour retransformer la forme de paiement rendue virtuelle en données liées à un AMOP dans le cadre d'opérations de paiement demandées par les systèmes existants 11, telles que des captures, des remboursements, des règlements, etc. En particulier, après que les systèmes existants 11 ont reçu et/ou traité la forme de paiement virtuelle, les systèmes existants 11 peuvent tenter une opération liée à un paiement, telle que la collecte d'un paiement, en envoyant un fichier de capture incluant la forme de paiement virtuelle au système AMOP 18 ou au système de la banque acquérante 20. Cependant, avant que les données ne soient reçues par le système AMOP 18 ou par le système de la banque acquérante 20, les données peuvent être reçues par le système de virtualisation 16 qui peut ensuite retransformer la forme de paiement virtuelle au format de données AMOP. Par la suite, le système de virtualisation 16 peut transmettre les données liées à ΓΑΜΟΡ au système AMOP 18 ou au système de la banque acquérante 20 qui, contrairement aux systèmes existants 11, peuvent être capables de comprendre et de traiter les données liées à ΓΑΜΟΡ. De cette façon, le système de virtualisation 16 permet à la logique de traitement de ΓΑΜΟΡ de se concentrer sur le système AMOP 18, le système de la banque acquérante 20 et/ou le système de la banque émettrice 22 plutôt que sur les systèmes existants 11 réduisant ainsi la demande sur les ressources physiques des systèmes existants 11.

[26] Dans certains modes de réalisation, le système de virtualisation 16 peut être configuré pour gérer toutes ou une partie des opérations liées aux paiements sans avoir à retransformer la forme de paiement virtuelle au format de données AMOP. En particulier, plus le système de virtualisation 16 est configuré pour se charger de telles opérations liées à des paiements, moins la transformation peut être nécessaire. Par exemple, si le système de virtualisation 16 est configuré pour initier une opération liée à un paiement sur la base des données reçues liées à un AMOP, le système de virtualisation peut ne pas avoir besoin de retransformer une forme de paiement virtuelle en données liées à un AMOP afin de faciliter l'opération liée à un paiement. En d'autres termes, le système de virtualisation 16 peut être configuré pour transformer les données liées à ΓΑΜΟΡ reçues du système AMOP 18 en forme de paiement virtuelle pour utilisation par les systèmes existmits 11 ; il peut aussi être configuré pour initier une ou plusieurs des opérations liées aux paiements ci-dessus sur la base de données liées à l'AMOP reçues.

[27] Quel que soit le cas, après réception des données liées à l'AMOP par le système AMOP 18 ou le système de la banque acquérante 20, le système récepteur peut communiquer possibilité par l'intermédiaire d'un ou de plusieurs systèmes additionnels avec le système de la banque émettrice 22 du client et demander un paiement à partir du compte du client (par ex., le système de la banque acquérante 20 peut demander un paiement par l'intermédiaire du système AMOP 18). Alternativement, le système AMOP 18 ou le système de la banque acquérante 20 peuvent avoir des fonds disponibles, prépayés par le client. Quel que soit le cas, une fois que le paiement pour la transaction en ligne est localisé par le système AMOP 18 ou par le système de la banque acquérante 20, le commerçant peut être payé.

[28] Faisant maintenant référence à la FIG. 2, les systèmes existants 11, le système de virtualisation 16, le système AMOP 18, le système de la banque acquérante 20 et/ou le système de la banque émettrice 22 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs systèmes ou dispositifs informatiques tels que le système informatique exemplaire 26. Le système informatique 26 peut inclure un processeur 28, une mémoire 30, un dispositif de stockage de mémoire de masse 32, une interface entrée/sortie (I/O) 34, et une interface homme-machine (HMI) 36. Le système informatique 26 peut aussi être couplé de façon fonctionnelle avec une ou plusieurs ressources externes 38 par l'intermédiaire du réseau 24 ou de l'interface I/O 34. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être utilisée avec le système informatique 26.

[29] Le processeur 28 peut inclure un ou plusieurs dispositifs sélectionnés : des microprocesseurs, des microcontrôleurs, des processeurs de signal numérique, des microordinateurs, des unités centrales de traitement, des réseaux de portes programmables (gâte arrays), des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d’instructions de fonctionnement enregistrées dans la mémoire 30. La mémoire 30 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, mais de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory), ou tout autre dispositif capable de stocker des informations. Le dispositif de stockage de mémoire de masse 32 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile, ou tout autre dispositif capable de stocker des informations.

[30] Le processeur 28 peut fonctionner sous le contrôle d'un système d'exploitation 40 qui réside dans la mémoire 30. Le système d'exploitation 40 peut gérer les ressources de l'ordinateur de sorte que le programme codé de l'ordinateur intégré sous forme d'une ou de plusieurs applications logicielles, telles que l'application 42 qui réside dans la mémoire 30, puisse faire exécuter des instructions par le processeur 28. Dans un autre mode de réalisation alternatif, le processeur 28 peut exécuter l'application 42 directement et dans ce cas le système d'exploitation 40 peut être omis. Une ou plusieurs structures de données 44 peuvent aussi résider dans la mémoire 30, et peuvent être utilisées par le processeur 28, le système d'exploitation 40 ou l'application 42 pour stocker ou manipuler des données.

[31 ] L'interface I/O 34 peut fournir une interface machine qui se couple de façon fonctionnelle au processeur 28 ou à d'autres dispositifs et systèmes, tels que le réseau 24 ou une ou plusieurs ressources externes 38. L'application 42 peut ainsi collaborer avec le réseau 24 et/ou les ressources externes 38 en communiquant par l'intermédiaire de l'interface I/O 34 pour fournir les divers éléments, fonctions, applications, processus ou modules comprenant les modes de réalisation de l'invention. Le serveur d'application 42 peut aussi avoir un programme codé qui est exécuté par une ou plusieurs ressources externes 38, ou autrement repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externe à l'ordinateur 26. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement à l'ordinateur 26, distribuées à des ordinateurs multiples et à d'autres ressources externes 38, ou apportées par des ressources informatiques (matérielles et logicielles) qui sont fournies en tant que services sur le réseau 24, par exemple un service d'informatique en nuage (cloud computing).

[32] Le HMI peut 36 peut être couplé de façon fonctionnelle aux processeurs 28 de l'ordinateur 26 de façon connue pour permettre à un utilisateur d'interagir directement avec l'ordinateur 26. Le HMI 36 peut inclure un affichage vidéo ou une unité d'affichage alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 36 peut aussi inclure des dispositifs de saisie et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des entrées de l'utilisateur et de les transmettre au processeur 28.

[33] Une base de données 46 peut résider sur le dispositif de stockage de mémoire de masse 32 et peut être utilisée pour collecter et organiser les données utilisées par les divers systèmes et modules décrits dans les présentes. La base de données 46 peut inclure les données et les structures de données qui les supportent pour stocker et organiser les données. En particulier, la base de données 46 peut être organisée en fonction de toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, ou des combinaisons de celles-là. Un système de gestion de base de données, sous forme d'une application logicielle qui s'exécute sous forme d'instructions sur le processeur 28, peut être utilisé pour accéder à l'information ou aux données stockées dans les fichiers de la base de données 46 en réponse à une interrogation, dans lequel l'interrogation peut être déterminée de façon dynamique et peut être exécutée par le système d'exploitation 40, d'autres applications 42 ou un ou plusieurs modules. Dans un mode de réalisation de l'invention, la base de données 46 peut comprendre une base de données de conversion 56 et/ou une base de données de paiements effectués 58 (FIG. 3), qui sont abordées respectivement de façon plus détaillée ci-après.

[34] FIG. 3 représente une architecture de traitement exemplaire 50 qui peut être fournie par un ou plusieurs des systèmes de l'environnement d'exploitation 10 ou tout autre système approprié. L'architecture de traitement 50 peut inclure un virtualiseur 54, une base de données de conversion 56 et/ou une base de données des paiements effectués 58. Lors du fonctionnement, l'architecture de traitement 50 et plus particulièrement le virtualiseur 54 peuvent recevoir des données liées à un AMOP 52, par exemple à partir du système AMOP 18 de l'environnement d'exploitation 10, et transformer les données liées à l'AMOP 52 en forme de paiement virtuelle 60 compatible avec les systèmes existants 11 de l'environnement d'exploitation 10. L'architecture de traitement 50 peut aussi effectuer ce processus de virtualisation de façon inverse (c.-à-d., retransformer la forme de paiement virtuelle en données liées à ΓΑΜΟΡ 52). La base de données de conversion 56 peut être configurée pour stocker des données pour la vérification et/ou la transformation de la forme de paiement virtuelle 60 en données liées à ΓΑΜΟΡ 52, et la base de données des paiements effectués 58 peut être configurée pour indiquer les formes de paiement virtuelles qui ont été utilisées et ne doivent plus être traitées ou validées par le virtualiseur 54. L'architecture de traitement 50 peut par ailleurs être configurée pour fonctionner à la fois en mode en ligne (par ex., avec une connexion Internet active) et en mode hors ligne (par ex., sans connexion Internet active).

[35] FIG. 4 représente un processus exemplaire 100 qui peut être effectué par l'architecture de traitement 50. Dans le bloc 102, les données liées à un AMOP peuvent être reçues, par le virtualiseur 54 par exemple, dans le cadre d'une transaction en ligne avec un commerçant. En particulier, les données liées à ΓΑΜΟΡ peuvent être reçues par le système AMOP 18 après qu'un client initie une transaction en ligne avec le commerçant pour un produit ou un service, et choisit d'utiliser un AMOP associé avec le système AMOP 18, pour le paiement. Les données liées à ΓΑΜΟΡ 52 peuvent inclure un jeton AMOP qui est généré par le système AMOP 18 et est destiné à « être utilisé par un commerçant et/ou un système de banque acquérante 20 pour demander un paiement pour une transaction en ligne, un identifiant ou un code spécifique à ΓΑΜΟΡ sélectionné ou au système AMOP 18, et un identifiant d'enregistrement de paiement (Payment Record Identifier, ou PRI) généré par le système AMOP 18 pour la transaction en ligne. La base de données liées à ΓΑΜΟΡ 52, ou plus particulièrement le Jeton AMOP, peut aussi inclure un identifiant d'utilisateur et/ou un numéro de compte pour le client initiateur qui est lié à ΓΑΜΟΡ sélectionné, un mot de passe pour le client initiateur qui est lié à ΓΑΜΟΡ sélectionné et/ou un montant de paiement qui peut avoir une valeur monétaire ou une valeur en unités spécifiques à ΓΑΜΟΡ sélectionné (par ex. des points), approuvée pour être échangée contre le jeton AMOP. Les données liées à ΓΑΜΟΡ 52, ou plus particulièrement le jeton AMOP, peuvent aussi inclure une date d'expiration au-delà de laquelle le jeton AMOP ne sera plus utilisable ou honoré par le système AMOP 18.

[36] Dans le bloc 104, une forme de paiement virtuelle 60 compatible avec les systèmes existants 11 du commerçant peut être créée pour la transaction en ligne, par exemple par le virtualiseur 54 et/ou sur la base des données liées à ΓΑΜΟΡ 52. Le virtualiseur 54, en particulier, peut être configuré pour transformer ou changer les données liées à ΓΑΜΟΡ 52 afin de créer la forme de paiement virtuelle 60, par exemple en additionnant de nouveaux nombres ou caractères à un ou plusieurs éléments inclus dans les données liées à ΓΑΜΟΡ 52 et en altérant ainsi fondamentalement les éléments dans les données liées à ΓΑΜΟΡ 52 pour obtenir une forme de paiement différente qui est compatible avec les systèmes existants 11. Dans un mode de réalisation, la forme de paiement virtuelle 60 peut être une carte de crédit virtuelle qui peut être une des quelques formes de paiement que les systèmes existants 11 sont capables de reconnaître comme étant valides et à même de pouvoir les traiter. Dans ce cas, les systèmes existants 11 peuvent traiter la carte de crédit virtuelle comme s'il s'agissait d'une véritable carte de crédit délivrée au client par une banque.

[37] Les cartes de crédit incluent typiquement des caractéristiques qui permettent l'identification de la banque émettrice de la carte de crédit, l'identification d'un compte client auprès de la banque émettrice et/ou favorise la sécurité. Dans un exemple, la carte de crédit peut inclure un numéro de carte de crédit qui comprend un numéro d'identification de la banque (Bank Identification Number, ou BIN) pouvant identifier la banque émettrice de la carte de crédit, un numéro de compte principal (Primary Account Number, ou PAN), qui peut identifier le compte client auprès de la banque émettrice, et un numéro de vérification qui peut être utilisé pour vérifier l'exactitude du numéro de la carte de crédit en utilisant un algorithme de vérification tel que l'algorithme Luhn. L'algorithme Luhn en particulier, également connu sous le nom d'algorithme « modulus dix », est une simple formule d'addition et de vérification qui peut être utilisée pour valider le reste de du numéro de carte de crédit par rapport au numéro de vérification, [38] Les cartes de crédit peuvent aussi inclure une date d'expiration au-delà de laquelle la banque émettrice n'honorera plus ou n'acceptera plus la carte de crédit pour une transaction en ligne, et une valeur de vérification de carte (Gard Vérification Value, ou CW) qui peut être calculée sur la base du numéro de carte de crédit et d'un algorithme privé et/ou des données privées. Le CW peut servir de mesure de sécurité additionnelle pour la carte de crédit, par exemple, pour des transactions en ligne lorsque la carte de crédit n'est pas physiquement présente. Parce que les systèmes existants 11 peuvent avoir été configurés spécifiquement pour ne reconnaître et ne traiter que les cartes de crédit ayant un numéro de carte de crédit propre, une date d'expiration, et un CW, la carte de crédit virtuelle peut avoir besoin d'être générée de sorte qu'elle inclut également chacune de ces caractéristiques.

[39] Dans certains modes de réalisation, le virtualiseur 54 peut transformer les données liées à ΓΑΜΟΡ 52 pour créer un numéro de carte pour la carte de crédit virtuelle en combinant et/ou en ajoutant des nombres ou des caractères aux éléments dans les données liées à l'AMOP 52. Plus particulièrement, le numéro de la carte de crédit virtuelle peut Inclure une partie qui comprend une séquence de chiffres spécifiques à l'AMOP sélectionné et une partie qui comprend une séquence de chiffres spécifiques à la transaction en ligne et/ou à la forme de paiement virtuelle. Par conséquent, pour former le numéro de la carte de crédit virtuelle, le virtualiseur 54 peut être configuré pour déterminer la séquence de chiffres spécifiques à l'AMOP sur la base de l'identifiant ou du code qui est inclus dans les données liées à l’AMOP 52, pour déterminer la séquence de chiffres spécifiques à la transaction en ligne et/ou à la forme de paiement virtuelle 60 et pour ajouter la séquence de chiffres spécifiques à l'AMOP sélectionné à la séquence de chiffres spécifiques à la transaction en ligne et/ou à la forme de paiement virtuelle 60. En d'autres termes, la séquence de chiffres spécifiques à l'AMOP peut être utilisée par la partie ΒΓΝ du numéro de la carte de crédit virtuelle et la séquence de chiffres spécifiques à la transaction en ligne et/ou à la forme de paiement virtuelle 60 peut être utilisée pour la partie PAN du numéro de la carte de crédit virtuelle.

[40] Dans un exemple, la séquence de chiffres spécifiques à l'AMOP sélectionné peut inclure l'identifiant ou le code spécifique à l'AMOP sélectionné dans les données liées à l'AMOP 52. La séquence de chiffres spécifique à la transaction en ligne et/ou à la forme de paiement virtuelle 60 peut être un nombre unique généré par le virtualiseur 54, par exemple de façon séquentielle ou par l'intermédiaire d'un générateur de nombre aléatoire implémenté par un ordinateur qui peut être un véritable générateur de nombre aléatoire ou un pseudo générateur de nombre aléatoire pour servir le processus de virtualisation. Alternativement, la séquence de chiffres spécifiques à la transaction en ligne et/ou à la forme de paiement virtuelle 60 peut être un identifiant de transaction (ID de transaction associé à la transaction en ligne qui peut être déjà une séquence de chiffres uniques. L'ID de transaction peut être le PRI inclus dans les données liées à l'AMOP 52 ou peut être généré par le virtualiseur 54 pour chaque transaction en ligne dans laquelle le virtualiseur 54 est impliqué.

[41 ] Dans certains modes de réalisation, les séquences de chiffres décrites ci-dessus peuvent former seulement une partie du numéro de la carte de crédit virtuelle. Pour calculer la partie restante du numéro de la carte de crédit virtuelle, le virtualiseur 54 peut être configuré pour calculer une unité de vérification qui satisfait un algorithme de vérification, tel que l'algorithme Luhn, relatif à la partie du numéro de carte de crédit virtuelle déterminé ci-dessus, c'est-à-dire, les séquences de chiffres ajoutées). Le virtualiseur 54 peut par ailleurs être configurés pour ajouter par la suite l'unité de vérification déterminée à la partie du numéro de carte de crédit déterminé ci-dessus, ou plus particulièrement,.à la fin de la partie PAN déterminée qui est opposée à la partie BIN déterminée, pour former le numéro de carte de crédit virtuelle.

[42] Dans un autre mode de réalisation, le virtualiseur 54 peut transformer les données liées à ΓΑΜΟΡ 52 en un numéro de carte de crédit virtuelle, en utilisant pour ce faire des données non publiques et un algorithme non public préprogrammé. Par exemple, le virtualiseur 54 peut générer, en utilisant l'algorithme non public préprogrammé, le numéro de la carte de crédit virtuelle sur la base de l'ID de Tutilisateur et/ou du numéro de compte contenus dans le jeton AMOP des données liées à ΓΑΜΟΡ 52, un MD5-comme une valeur de hachage (hash value) du mot de passe contenu dans le jeton AMOP des données liées à ΓΑΜΟΡ 52, une clé secrète, une valeur aléatoire basée sur un horodatage au millième de seconde et/ou une séquence de numéro privé.

[43] Dans encore un autre mode de réalisation, le virtualiseur 54 peut transformer les valeurs relatives à l'AMOP 52 en un numéro de carte de crédit virtuelle en basant le numéro de carte de crédit virtuelle sur des données qui ne sont pas incluses dans les données liées à l'AMOP 52, et en associant par la suite les données liées à l'AMOP 52 avec le numéro de carte de crédit virtuelle dans la base de données de conversion 56. De cette façon, la sécurité de l'architecture de traitement 50 peut être améliorée, puisqu'il ne sera pas possible de dériver les données liées à l'AMOP 52 seules en numéro de carte de crédit virtuelle. Par exemple, le virtualiseur 54 peut être configuré pour générer une séquence de chiffres à utiliser comme partie ΒΓΝ du numéro de carte de crédit virtuelle. La séquence de chiffres peut être spécifique à l'AMOP sélectionné, identifié dans les données liées à l'AMOP 52 et peut être générée de façon séquentielle ou en utilisant un générateur de nombres aléatoires implémenté par un ordinateur qui peut être un générateur de nombres aléatoires vrais ou de nombres pseudo aléatoires, pour chaque AMOP accepté. Par la suite, le virtualiseur 54 peut être configuré pour générer une partie restante du numéro de carte de crédit virtuelle (par ex., la partie PAN et l'unité binaire de vérification), de sorte que l'algorithme de vérification, tel que l'algorithme Luhn, soit satisfait. La séquence de chiffres générée pour la partie PAN et l'unité binaire peuvent être uniques par rapport à d'autres numéros de la carte de crédit virtuelle en incluant la même partie BTN afin de distinguer chaque client ou chaque transaction en ligne qui utilise un même AMOP. Similaire à la partie BIN, la partie PAN peut être générée de façon séquentielle en utilisant un générateur de nombres aléatoires implémenté par un ordinateur.

[44] Un CW et une date d'expiration peuvent aussi être générés ou associés à la carte de crédit virtuelle générée pour la transaction en ligne. Plus particulièrement, le virtualiseur 54 peut être configuré pour associer une date d'expiration avec la carte de crédit virtuelle qui est équivalente à la date d'expiration incluse dans le jeton AMOP. Si aucune date d'expiration n'est incluse dans le jeton AMOP, alors une date d'expiration par défaut suffisamment longue pour permettre à la carte de crédit virtuelle d'être utilisée pour une transaction (par ex., une heure) peut être induite. Pour générer le CW de la carte de crédit virtuelle, le virtualiseur 54 peut être configuré pour générer une séquence de chiffres courte, telle qu'un nombre à trois ou quatre chiffres, pour le besoin. En particulier, le virtualiseur 54 peut inclure et/ou être configuré pour générer, avant la réception des données liées à ΓΑΜΟΡ 52, une séquence de chiffres aléatoires non publique, qui peut être générée en utilisant un générateur de nombres aléatoires implémenté par un ordinateur qui peut être un générateur de nombres aléatoires vrai ou pseudo aléatoires. Pour chaque nouvelle carte de crédit virtuelle, le virtualiseur 54 peut être configuré pour extraire de façon séquentielle trois ou chiffres ou plus actuellement non utilisés comme CW pour la carte de crédit virtuelle (c.-à-d., les chiffres qui ne sont pas actuellement utilisés avec une autre carte de crédit virtuelle) à partir de la séquence prégénérée. Par exemple, si les chiffres actuellement inutilisés de la séquence prégénérée sont « 345386 » en séquence, alors le virtualiseur 54 peut d'abord extraire « 345 » comme CW pour la prochaine nouvelle carte de crédit virtuelle et par la suite extraire « 386 » comme CW pour une nouvelle carte de crédit virtuelle suivante. Pour assurer que la séquence prégénérée ne soit pas à court de chiffres actuellement inutilisés pour les cartes de crédit virtuelles à venir, la séquence de chiffres peut être d'une longueur telle qu'une ou plusieurs cartes de crédit virtuelles viendront à expiration avant d'avoir pu arriver à épuisement de la séquence de chiffres. En d'autres termes, la séquence prégénérée peut être d'une telle longueur qu'il faudrait plus de temps pour en venir à bout qu'il n'en faudrait pour atteindre la date d'expiration générée et associée à une ou plusieurs des cartes de crédit virtuelles. De cette manière, des chiffres actuellement inutilisés peuvent toujours être disponibles pour générer un CW. La longueur appropriée pour la séquence prégénérée peut être déterminée sur la base de données empiriques.

[45] Dans le bloc 106, les données pour la transformation et/ou la vérification de la forme de paiement virtuelle peuvent être conservées, par exemple par le virtualiseur 54, dans la base de données de conversion 56. Plus particulièrement, la base de données de conversion 56 peut être configurée pour stocker des données pour la vérification et la transformation de chacune des formes de paiement virtuelles 60 en données AMOP ; lesquelles peuvent être semblables ou différentes des données liées à ΓΑΜΟΡ 52 initialement reçues qui ont suscité la création de la forme de paiement virtuelle 60. Chacune d'une ou de plusieurs formes de paiement virtuelles 60 peut être compatible avec les systèmes existants 11. En d'autres termes, une fois que la forme de paiement virtuelle 60 a été générée, les données pour la retransformer en données AMOP peuvent être stockées dans la base de données de conversion 56.

[46] Dans un mode de réalisation, pour chaque forme de paiement virtuelle 60 créée par le virtualiseur 54, les données peuvent être stockées dans la base de données de conversion 56 qui définit la forme de paiement virtuelle 60 et la relie à toutes ou à une partie des données AMOP 52 à partir desquelles ou pour lesquelles la forme de paiement virtuelle a été créée. Plus particulièrement, chaque forme de paiement virtuelle 60 peut être reliée au Jeton AMOP inclus dans les données AMOP 52, à un ID de transaction associé à la forme de paiement virtuelle 60, tel que le PRI inclus dans le jeton AMOP, ou à une séquence de chiffres uniques générée par le virtualiseur 54 et/ou au type d'AMOP associé au jeton AMOP, tel que le code ^écifique de ΓΑΜΟΡ sélectionné inclus dans les données AMOP 52 ou généré par le virtualiseur 54. Si la forme de paiement virtuelle 60 est une carte de crédit virtuelle dans laquelle le numéro de la carte de crédit virtuelle inclut un code spécifique à ΓΑΜΟΡ sélectionné, alors le rattachement du type d'AMOP peut se produire du fait de la conservation des données définissant la forme de paiement virtuelle 60 dans la base de données de conversion 56. Sinon, le code spécifique à ΓΑΜΟΡ sélectionné peut être conservé séparément et rattaché à la forme de paiement virtuelle 60 dans la base de données de conversion 56.

[47] Dans un autre mode de réalisation, les données stockées dans la base de données de conversion 56 ne peuvent relier chaque forme de paiement virtuelle 60 qu'avec des données variables non personnelles qui sont nécessaires pour recoder la forme de paiement virtuelle 60 en données AMOP. Par exemple lorsque la forme de paiement virtuelle 60 est générée sur la base d'éléments de données non publiques et sur la base d’un algorithme préprogrammé non public décrit ci-dessus, la forme de paiement virtuelle 60 peut être rattachée dans la base de données de conversion 56 aux données variables non personnelles qui sont uniques à la génération de la forme de paiement virtuelle 60, telles que la valeur aléatoire générée sur la base de l'horodatage. D'autres données non personnelles, telles que la clé secrète et la séquence de nombres privés, peuvent être compilées pour former une partie de l'algorithme lui-même, et des données personnelles, telles que l'ID de l'utilisateur et/ou le mot de passe des données AMOP 52, peuvent ne pas avoir besoin d'être conservés systématiquement. De cette manière, si la base de données de conversion était endommagée, toutes les données extraites de la base de données de conversion 56 seraient inutilisables pour déterminer l'ID de l'utilisateur, le numéro de compte et/ou le mot de passe des données AMOP 52 sans avoir connaissance de l'algorithme préprogrammé non public et d'autres éléments de données non publiques. En conséquence, la sécurité du système dans son ensemble peut être améliorée.

[48] Dans le bloc 108, une fois la forme de paiement virtuelle 60 générée, elle peut être transmise aux systèmes existants 11 pour traitement. Par exemple, les systèmes existants 11 peuvent valider la forme de paiement virtuelle 60 en vérifiant que toutes les informations nécessaires de la forme de paiement virtuelle 60 sont présentes. Dans le cas d'une carte de crédit virtuelle, les systèmes existants 11 peuvent aussi confirmer que l'unité binaire de vérification du numéro de la carte de crédit virtuelle satisfait un algorithme de vérification, tel que l'algorithme Luhn et/ou que le CW du numéro de la carte de crédit virtuelle est valide. De plus, ou alternativement, les systèmes existants 11 peuvent effectuer des fonctions de conservation d'enregistrements, des fonctions de facturation et/ou toute autre fonction appropriée sur la base de la forme de paiement virtuelle 60. Par exemple, dans le cas d'une transaction en ligne impliquant une compagnie aérienne commerçante, le système de gestion des clients 14 peut recevoir la forme de paiement virtuelle 60 en provenance du virtualiseur 54, stocker la forme de paiement virtuelle 60 dans l'élément FOP d'un PNR associé à la confirmation d'une réservation créée dans la transaction en ligne et, par la suite, envoyer le PNR au système des opérations internes 12 pour une utilisation dans d'autres processus. Les systèmes existants 11 peuvent aussi initier une opération liée à un paiement avec le système AMOP 18 et/ou avec le système de la banque acquérante 20 de l'environnement d'exploitation 10 sur la base de la forme de paiement virtuelle 60, telle qu'une opération de capture, de remboursement, de règlement ou de rapprochement.

[49] FIG. 5 illustre un processus 200 qui peut être effectué par l'architecture de traitement 50. Dans le bloc 202, la forme de paiement virtuelle 60 peut être reçue, en provenance du virtualiseur 54 et des systèmes existants 11. Par exemple, les systèmes existants 11 peuvent essayer de transmettre la forme de paiement virtuelle 60 au système AMOP 18 ou au système d'une banque acquérante 20 dans le cadre d'une opération liée à un paiement. Lorsque les systèmes existants 11 transmettent la forme de paiement virtuelle 60 au système AMOP 18 ou au système de la banque acquérante 20, le virtualiseur 54 peut intercepter la communication et déterminer si elle inclut une forme de paiement virtuelle 60. Dans l'affirmative, le virtualiseur 54 peut alors, dans le bloc 204, déterminer si la forme de paiement virtuelle est vérifiable sur la base des données conservées au bloc 106 du processus 100.

[50] Par exemple, la vérification de la forme de paiement virtuelle 60 peut inclure de contrôler ou de vérifier que la forme de paiement virtuelle 60 est stockée dans la base de données de conversion 56, qu'elle n'a pas expiré et qu'elle n'est pas signalée comme ayant été utilisée du fait qu'elle est conservée dans la base de données des paiements effectués 58. Dans le cas d'une forme de paiement virtuelle 60 qui inclut un numéro virtuel de carte de crédit, une VCC (virtual crédit card) et/ou une date d'expiration, le virtualiseur 54 peut par exemple être configuré pour examiner ou vérifier que le numéro de carte de crédit virtuelle de la forme de paiement virtuelle 60 est associé à la VCC et/ou à la date d'expiration de la forme de paiement virtuelle 60 dans la base de données de conversion 56.

[51] Si la forme de paiement virtuelle 60 fournie ne peut être vérifiée (branche «NON » du bloc 204) alors dans le bloc 206, la demande d’opération liée au paiement peut être rejetée et le virtualiseur 54 peut être configuré pour transmettre un message aux systèmes existants 11 pour les informer du rejet de la demande. Alternativement, si la forme de paiement virtuelle 60 est vérifiée (branche « OUI » du bloc 204), alors la forme de paiement virtuelle 60, au bloc 208, peut être transformée en données AMOP sur la base des données conservées au bloc 106 du processus 100. Plus particulièrement, le virtualiseur 54 peut retransformer la forme de paiement virtuelle 60 en données AMOP 52 qui ont suscité la création de la forme de paiement virtuelle 60 sur la base des données stockées dans la base de données de conversion 56 pour la forme de paiement virtuelle 60.

[52] Alternativement, pendant la transformation de la forme de paiement virtuelle 60 en données AMOP, le virtualiseur 54 peut être configuré pour ajouter des informations supplémentaires aux données AMOP qui en résultent, ce qui peut fonctionner pour abaisser les taux d'interchange, déplacer les responsabilités, etc. Par exemple, certain systèmes AMOP 18 et certains systèmes des banques acquérantes 20 peuvent exiger que les données détaillant un achat ou une réservation (par ex., les informations détaillées du vol) ou des données indiquant que le payeur a été authentifié, soient incluses dans les données AMOP qui lui sont transmises.

[53] Dans certains modes de réalisation, certaines méthodes de traitement peuvent être implémentées dans l'architecture de traitement 50 et plus particulièrement dans le virtualiseur 54 pour accélérer le processus de virtualisation dans les deux directions, ce qui, par conséquent, peut permettre un traitement plus rapide des transactions en ligne. La méthode de traitement particulière utilisée peut dépendre du format du message portant les données AMOP 52 et/ou la forme de paiement virtuelle 60. Par exemple, l'architecture de traitement 50 peut être configurée pour utiliser une expression régulière pour le traitement binaire ou pour des messages aux formats simples. De plus ou alternativement, l'architecture de traitement 50 peut être configurée pour utiliser le langage extensible de transformation de feuilles de style (Extensible Style Sheet Language Transformations, ou XSLT) à partir d'une définition de schéma XML (XSD) pour des messages structurés, tels que les messages sous format de langage balisable extensible (Extensible Markup Language, ou XML), ou sous le format d’échanges de données informatisées pour le commerce, l'administration et les transports (Electronic Data Interchange for Administration, Commerce and Transport, ou EDIFACT). De plus ou alternativement, l'architecture de traitement 50 peut être configurée pour prendre en charge le langage JavaScript Objection Notation (JSON), et si aucune norme n'existe pour une structure JSON, un entrepôt de gestion de données (Management Data Warehouse, ou MDW) compatible avec l'utilisation d’un XSD pour définir et valider un message JSON, peut alors être implémenté.

[54] Dans le bloc 210, après que la forme de paiement virtuelle a été transformée en données AMOP, les données AMOP peuvent être transmises par exemple par le virtualiseur 54, aux unités appropriées pour effectuer l'opération liée au paiement demandée par les systèmes existants 11. Par exemple, une fois que la forme de paiement virtuelle 60 a été transformée, les données ΑΜΟΡ qui en résultent peuvent être transmises à un acquéreur, tel que le système AMOP 18, ou au système de la banque acquérante 20, à des fins de collecte des paiements sur la base des données AMOP.

[55] Comme précédemment expliqué, dans certains modes de réalisation, le virtuallseur 54 peut être configuré pour gérer toutes ou une partie des opérations liées aux paiements. Dans ce cas, plutôt que d’attendre une réponse pour une opération liée à un paiement incluant la forme de paiement virtuelle 60 de la part des systèmes existants 11 et, par la suite, transformer la forme de paiement virtuelle 60 en données AMOP, le virtualiseur 54 peut être configuré pour envoyer lui-même une demande liée à un paiement sur la base des données AMOP 52 reçues à l’origine. En d’autres termes, le virtualiseur 54 peut être configuré pour transformer les données AMOP 52 reçues en forme de paiement virtuelle 60 pour utilisation par les systèmes existants 11 et peut aussi être configuré pour initier une ou plusieurs des opérations liées à des paiements décrites ci-dessus sans avoir à retransformer la forme de paiement virtuelle 60 en format de données AMOP.

[56] Dans le bloc 212, comme mesure de sécurité additionnelle, une fois la transaction en ligne impliquant une forme de paiement virtuelle 60 finalisée et/ou le paiement reçu par le commerçant, ou la date d’expiration associée à la forme de paiement virtuelle 60 échue, la forme de paiement virtuelle 60 peut être désactivée pour une période donnée ou indéfinie afin qu’elle soit inutilisable dans des transactions futures. Plus particulièrement, la forme de paiement virtuelle 60 peut être stockée dans la base de données de paiements effectués 58, ou alternativement elle peut être signalée comme ayant été utilisée dans la base de données de conversion 56, De cette manière, si une autre demande pour une opération liée à un paiement incluant la forme de paiement virtuelle 60 est reçue dans un contexte frauduleux ou par inadvertance par le virtualiseur 54, le virtualiseur 54 peut être configuré pour interroger une des bases de données afin de déterminer si la forme de paiement virtuelle 60 a déjà été utilisée dans une autre transaction ou a expiré. Le cas échéant, le virtualiseur 54 peut rejeter la transformation de la forme de paiement virtuelle 60 en données AMOP et peut transmettre un message correspondant au demandeur.

[57] Par ailleurs, parce que l’architecture de traitement 50 peut être configurée de sorte que toute forme de paiement virtuelle donnée 60 qui est générée par le virtualiseur 54 ne peut être utilisée que pour une seule transaction, soit sur une période donnée, soit sur une période indéterminée, les formes de paiement virtuelles 60 générées par le virtualiseur 54 peuvent être hors de la portée de certaines normes de sécurité des données. Ainsi, par exemple, le conseil des normes de sécurité sur les données de l’industrie des cartes de paiement (PCI Security Standards Council) a assemblé des normes de sécurité des données (Data Security Standards, ou DSS) qui incluent plusieurs procédures que les commerçants doivent suivre lors du traitement des cartes de crédit, telles que des cartes de crédit physiques à usage multiple, ces dites procédures ayant été adoptées ou utilisées par plusieurs états pour créer leurs propres lois. La mise en oeuvre de ces procédures peut entraîner des coûts additionnels pour le commerçant et un temps de traitement additionnel pour l’architecture de traitement 50 et pour les systèmes existants 11. Les cartes de crédit virtuelles à usage unique ne tombent cependant pas sous le coup des DSS. Par conséquent, l’utilisation des formes de paiement virtuelles à usage unique 60, telles que la carte de crédit virtuelle, par l’architecture de traitement 50 et les systèmes existants du commerçant 11, peuvent réduire les coûts pour le commerçant et réduire la complexité générale et le temps de traitement, car la forme de paiement virtuelle 60 peut être transmise au système existant 11 qui peut la traiter sans implémenter des procédures additionnelles ou des processus impliquant la forme de paiement virtuelle 60 dans le but d’être en conformité avec de telles normes de sécurité des données.

[58] En général, les sous-programmes exécutés pour mettre en œuvre les modes de réalisation de l’invention, qu’ils soient implémentés dans le cadre d’un système d’exploitation ou d’une application spécifique, d’un composant, d’un programme, d’un objet, d’un module ou d’une séquence d’instructions, ou même un sous-ensemble des présents, peuvent être désignés dans les présentes comme « programme codé informatique » ou simplement «programme codé ». Le programme codé comprend typiquement des instructions lisibles par ordinateur qui résident à des moments divers dans des dispositifs divers de mémoire et de stockage dans un ordinateur et qui lorsqu’elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, provoquent l’exécution par l’ordinateur d’opérations et/ou d’éléments propres aux aspects variés des modes de réalisation de l’invention. Les instructions d’un programme informatique lisibles par ordinateur pour effectuer les opérations des modes de réalisation de l’invention peuvent par exemple être : le langage d’assemblage ou un code source, ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation.

[59] Divers programmes codés décrits dans les présentes peuvent être identifiés selon l’application au sein de laquelle ils sont implémentés dans des modes de réalisation de l’invention spécifiques. Cependant, on remarquera que toute nomenclature d’un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l’invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, des procédures, des méthodes, des modules, des objets, et ainsi de suite, ainsi que les façons variées d’affecter les fonctionnalités d’un programme parmi diverses couches de logiciels qui résident dans un ordinateur typique (par exemple, les systèmes d’exploitation, les bibliothèques, les interfaces d’application de programme [API], les applications, les petites applications [applets], etc.), on remarquera que les modes de réalisation de l’invention ne sont pas limités à l’organisation spécifique ni à l’affectation spécifique de fonctionnalités de programme décrites dans les présentes.

[60] Le programme codé mis en oeuvre dans toute appiication/module décrit dans les présentes peut être distribué individuellement ou collectivement en tant que produit-programme dans une variété de formes. En particulier, le programme codé peut être distribué en utilisant un support de stockage lisible par ordinateur disposant d’instructions de programme lisibles par ordinateur en amenant un processeur à exécuter des aspects des modes de réalisation de l’invention.

[61 ] Les supports de stockage de données lisibles par ordinateur qui sont intrinsèquement non transitoires peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, implémentés dans toute méthode ou technologie de stockage de données, telles que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme ou autres données. Les supports de stockage lisibles par ordinateur peuvent par ailleurs inclure la mémoire aléatoire (RAM), la mémoire morte (ROM), la mémoire à lecture exclusivement programmable et effaçable (EPROM)), une mémoire flash, ou toute technologie de support solide de mémoire, CD-ROM (disque compact portable doté d’une mémoire à lecture seule), ou tout autre stockage optique, bandes d’enregistrement magnétique, mémoire à disque magnétique, ou tout autre support pouvant être utilisé pour stocker l’information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant à travers un support de transmission tel qu’un guide d’ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d’appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par l’intermédiaire d’un réseau.

[62] Les instructions de programme lisibles par ordinateur et stockées dans un support lisible par ordinateur peuvent être utilisées pour commander un ordinateur, d’autres types d’appareils programmables de traitement ou d’autres dispositifs pour fonctionner d’une façon particulière, de sorte que les Instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies par un ou plusieurs processeurs installés sur un ordinateur à usage général, un ordinateur à usage spécial, ou tout autre appareil programmable de traitement de données pour produire une machine telle que les instructions qui s’exécutent par l’intermédiaire d’un ou de plusieurs processeurs provoquent une série de calculs devant être effectués pour implémenter les fonctions, actions et/opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs, [63] Dans certains modes alternatifs de réalisation les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs peuvent être recommandés, traités par série, et/ou traités i tout en restant conformes avec les modes de réalisation de l’invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l’invention.

[64] La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n’est pas destinée à limiter les modes de réalisation de l’invention. Les formes singulières des articles indéfinis « un », « une », « le » et « la » tels qu’ils sont utilisés dans les présentes sous-entendent également les formes plurielles, sauf si le contexte indique clairement qu’il en est autrement. On comprendra par ailleurs que les formes verbales du verbe « comprendre », « comprend » et/ou « comprenant », lorsqu’elles sont utilisées dans cette spécification, précisent la présence de caractéristiques, de nombres entiers, d’étapes, d’opérations, d’éléments, et/ou de composants, mais n’excluent pas la présence ou l’ajout d’un ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes, en cela. De plus, dans la mesure où les verbes « inclure », « ayant », « a », « disposant de », « avec », « compris de » ou des variantes de ceux-là, sont utilisés dans la description détaillée et les revendications, ces termes sont censés être inclusifs de façon semblable au verbe « comprendre ».

[65] Bien que l’invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n’est pas de l’intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l’étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L’invention sous un angle plus large n’est donc pas limitée aux détails spécifiques, aux méthodes et aux appareils représentatifs, et aux exemples illustrateurs montrés et décrits. Par conséquent, il est possible de s’éloigner de ces détails sans s’éloigner de l’esprit et de la portée du concept inventif général du demandeur.

Claims (14)

1. REVENDICATIONS

   1. Une méthode pour le traitement de moyens alternatifs de paiement éleqtronique, AMOP, dans un système transactionnel de traitement en ligne, la méthode comprenant : la réception par un ou plusieurs processeurs, de premières données AMOP, en relation avec une transaction en ligne impliquant un commerçant ; et à la réception des premières données AMOP : la transformation, par un ou plusieurs processeurs, des premières données AMOP pour créer une forme de paiement virtuelle compatible avec le système existant du commerçant ; la transmission, par un ou plusieurs processeurs, de la forme de paiement virtuelle au système existant pour traitement, et après la création de la forme de paiement virtuelle, la conservation, par un ou plusieurs processeurs, des données de transformation pour la transformation de la forme de paiement virtuelle en secondes données AMOP dans une base de données abritée sur un dispositif de stockage de mémoire de masse.
2. 2. La méthode selon la revendication 1, dans laquelle la forme de paiement virtuelle comprend une carte de crédit virtuelle qui inclut un numéro de carte de crédit, une première partie d’un numéro de carte de crédit comprenant une première séquence de chiffres spécifiques à ΓΑΜΟΡ, et une seconde partie du numéro de carte de crédit comprenant une seconde séquence de chiffres spécifiques à la transaction en ligne.
3. 3. La méthode selon la revendication 2, dans laquelle les premières données AMOP incluent un identifiant spécifique à l’AMOP, et qui transforme les premières données AMOP pour créer une forme de paiement virtuelle compatible avec le système existant du commerçant, comprend : la détermination de la première séquence de chiffres sur la base de l’identifiant spécifique à l’AMOP inclus dans les premières données AMOP ; la détermination d’une seconde séquence de chiffres spécifique à la transaction en ligne ; le rattachement de la seconde séquence de chiffres à la première séquence de chiffres pour former une partie du numéro de carte de crédit ; le calcul d’un chiffre de vérification qui satisfait un algorithme de vérification relatif à la partie du numéro de carte de crédit ; et le rattachement du chiffre de vérification à la partie du numéro de carte de crédit pour former le numéro de la carte de crédit.
4. 4. La méthode selon la revendication 3, dans laquelle la première séquence de chiffres comprend l’identifiant spécifique à ΓΑΜΟΡ inclus dans les premières données AMOP, et la seconde séquence de chiffres spécifique à la transaction en ligne est déterminée en utilisant un générateur de nombres aléatoires.
5. 5. La méthode selon les revendications 2 ou 3, dans laquelle la carte de crédit virtuelle comprend une valeur de vérification de la carte, et transformant les premières données AMOP pour créer une forme de paiement virtuelle compatible avec le système existant du commerçant, comprend : la génération grâce à un générateur de nombres aléatoires avant la réception des premières données liées à ΓΑΜΟΡ, d’une troisième séquence de chiffres ; et l’extraction, comme valeur de vérification de la carte, de trois ou plusieurs chiffres actuellement non utilisés à partir de la troisième séquence de chiffres dans la séquence.
6. 6. La méthode selon la revendication 1, comprenant par ailleurs : la réception d’une forme de paiement virtuelle en provenance du système existant ; la vérification de la forme de paiement virtuelle sur la base des données de transformation stockées dans la base de données ; en réponse à la vérification de la forme de paiement virtuelle, la transformation de la forme de paiement virtuelle en secondes données AMOP sur la base des données de transformation ; et la transmission des secondes données AMOP à un acquéreur pour la collecte du paiement sur la base des secondes données.
7. 7. La méthode selon la revendication 6, dans laquelle la forme de paiement virtuelle inclut une carte de crédit virtuelle qui inclut un numéro de carte de crédit et une valeur de vérification de carte ; la vérification de la forme de paiement virtuelle sur la base des données de transformation stockées dans la base de données comprend : la vérification que le numéro de carte de crédit est associé à la valeur de vérification de la carte dans les données de transformation.
8. 8. La méthode selon l'une quelconque des revendications 1 à 7, comprenant par ailleurs : la désactivation de la forme de paiement virtuelle pour la rendre inutilisable pour une autre transaction en ligne.
9. 9. La méthode selon l'une quelconque des revendications 1 à 8, dans laquelle le commerçant est une compagnie aérienne, la transaction en ligne comprend une confirmation de réservation de vol et la transmission de la forme de paiement virtuelle au système existant permettant au système existant de générer un enregistrement de nom de passager pour la confirmation de la réservation de voyage qui inclut un élément de paiement indiquant la forme virtuelle du paiement.
10. 10. La méthode selon la revendication 1, dans laquelle la forme de paiement virtuelle comprend une carte de crédit virtuelle, la carte de crédit virtuelle est transmise au système existant sans traitement ultérieur de la forme de paiement virtuelle pour satisfaire une norme de sécurité des données portant sur les cartes de crédit physiques à usage multiple.
11. 11. Un système transactionnel en ligne pour le traitement de moyens de paiement alternatifs, AMOP, le système transactionnel en ligne comprenant : un dispositif de stockage de mémoire de masse qui héberge une base de données configurée pour stocker les données de transformation relatives à la transformation d'une forme de paiement virtuelle en premières données AMOP, dans lequel la forme de paiement virtuelle est compatible avec le système existant du commerçant ; un ou plusieurs processeurs ; et une mémoire couplée à un ou plusieurs processeurs, dans laquelle la mémoire stocke les instructions qui, lors de leur exécution par un ou plusieurs processeurs, amènent le système transactionnel en ligne à : en réponse à la réception de secondes données AMOP dans le cadre d'une transaction en ligne avec un commerçant : transformer les secondes données AMOP pour créer une forme de paiement virtuelle compatible avec le système existant ; transmettre la forme de paiement virtuelle au système existant pour traitement, et après la création de la forme de paiement virtuelle, conserver les données de transformation pour transformer la forme de paiement virtuelle en premières données AMOP dans la base de données.
12. 12. Le système selon la revendication 11, dans lequel l'exécution des instructions par un ou plusieurs processeurs amène par ailleurs le système transactionnel en ligne à mettre en œuvre la méthode selon l’une quelconque des revendications 2 à 10.
13. 13. Un produit programme d'ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur comprenant des moyens de programme lisibles par ordinateur pour, en réponse à la réception des premières données liées au moyen de paiement électronique alternatif, AMOP, dans le cadre d'une transaction en ligne avec un commerçant, mettre en œuvre l'étape suivante : des moyens de programmation lisibles par ordinateur pour effectuer l'étape de transformation des premières données AMOP afin de créer une forme de paiement virtuelle compatible avec un système existant du commerçant ; des moyens de programmation lisibles par ordinateur pour effectuer l'étape de trmismission de la forme de paiement virtuelle au système existant pour traitement, et des moyens de programmation lisibles par ordinateur pour effectuer l'étape de conservation des données de transformation après la création de la forme de paiement virtuelle, sous forme de secondes données AMOP dans une base de données hébergée sur un dispositif de stockage de mémoire de masse, lorsque ledit programme fonctionne sur un ordinateur.
14. 14. Le produit programme d'ordinateur selon la revendication 13 comprenant un code de programme enregistré sur un support lisible par ordinateur pour exécuter les étapes du procédé selon les revendications 2-10 lorsque ledit programme fonctionne sur un ordinateur.