Brevet FR3095066A1 — publié le 20201016

Description Titre de l'invention : Contrôle parental mis en oeuvre dans un système de traitement d'une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur [OOO1 j La présente invention concerne un contrôle parental mis en oeuvre dans un système de traitement d'une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur. Elle trouve une application générale dans le commerce électronique et plus particulièrement dans les services de paiement destinés aux mineurs/ adolescents afin de favoriser leur autonomie, et leur éducation financière. On connaît déjà des plateformes de commerce électronique qui permettent à un parent (décideur) de valider une demande d'achat émanant d'un adolescent (utilisateur) sur la base des détails associés à la demande d'achat. Par exemple, dans le document WO 2017/027533 Al (GREENLIGHT ME, INC.) l'adolescent saisit les détails d'un article qu'il souhaite acheter. La plateforme notifie le parent de l'achat souhaité et attend son approbation avant d'autoriser la transaction. Une telle plateforme de commerce électronique offre un contrôle parental organisé autour de notifications envoyées systématiquement au décideur à chaque demande d'achat de l'utilisateur. La mise en oeuvre du contrôle parental est relativement lourde car elle exige ici l'approbation de l'achat par le décideur sur la base d'une demande très détaillée de l'achat selon : la date, le montant, et la nature de l'achat. De plus, le contrôle parental ne garantit pas techniquement le fait qu'une fois la demande d'achat approuvée par le décideur, l'utilisateur va effectivement acheter le bien considéré. La présente invention remédie à ces inconvénients. L'invention porte sur un procédé de contrôle parental mis en oeuvre dans un système de traitement d'une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur. Selon une définition générale de l'invention, le système de traitement comprend : -un module de traitement dorsal apte : -à recevoir en provenance du décideur une liste de transactions de paiement interdites/autorisées au détriment/profit de l'utilisateur de la carte de paiement, chaque transaction de paiement comprenant un code d'activité du commerçant lié à la transaction de paiement ; et -à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire ; -un module de traitement frontal propre : 2 -en réponse à une demande de transaction de paiement de l'utilisateur auprès d'un terminal de paiement d'un commerçant à l'aide de la carte de paiement de l'utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire, ladite requête de paiement comprenant au moins le code d'activité du commerçant lié à la transaction de paiement ; -le module de traitement bancaire étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/ autorisées pour l'utilisateur de la carte de paiement ; -à recevoir la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat ; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et -en cas de comparaison positive à interdire en temps réel le paiement pour l'utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement. Grâce à l'invention, la mise en oeuvre du contrôle parental est souple et peu contraignante par rapport à l'art antérieur. En effet, la liste des transactions interdites/ autorisées est créée au préalable par « catégories d'achat » en amont de l'achat par le décideur. Il en résulte que l'achat est autorisé ou rejeté sans attendre l'approbation effective du décideur. De plus le décideur maîtrise les achats de l'utilisateur par catégorie d'achats », en amont de l'achat, et sans contrainte de l'utilisateur sur le décideur. Enfin, le contrôle parental fondé sur les codes d'activité des commerçants garantit techniquement que l'autorisation de l'achat porte bien sur une catégorie d'achats autorisée par le décideur. De façon surprenante, le Demandeur a observé que la garantie technique du contrôle parental s'appuie sur des règles préalablement établies par le décideur et qui sont corrélées avec l'identification du type de commerce interrogé par le moyen de paiement lors de l'achat. En effet, lors de l'achat, le code d'activité appelé MCC (Merchant Category code) du commerce est comparé selon l'invention, à une liste permettant d'établir la/les catégorie(s) de biens ou services proposés par le commerce, cette catégorie étant alors elle-même comparée à une liste de catégories autorisées/interdites créée en amont par le décideur, et permettant de refuser/accepter le paiement par ce médium de paiement spécifique (de type carte bancaire, mobile, ...). Selon un mode de réalisation de l'invention, le code d'activité du commerçant est basé sur le MCC (Merchant Category code). L'invention porte aussi sur un système de traitement pour la mise en oeuvre du procédé de contrôle d'une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur conforme à l'invention, le système de traitement 3 comprenant : -un module de traitement dorsal apte : -à recevoir en provenance du décideur une liste de transactions de paiement interdites/ autorisées au détriment/profit de l'utilisateur de la carte de paiement, chaque transaction de paiement comprenant un code d'activité du commerçant lié à la transaction de paiement ; et -à envoyer en temps réel la liste de transactions de paiement interdites/autorisées ainsi créée à un module de traitement bancaire ; -un module de traitement frontal propre : -en réponse à une demande de transaction de paiement de l'utilisateur auprès d'un terminal de paiement d'un commerçant à l'aide de la carte de paiement de l'utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire, ladite requête de paiement comprenant au moins le code d'activité du commerçant lié à la transaction de paiement ; -le module de traitement bancaire étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/ autorisées pour l'utilisateur de la carte de paiement ; -à recevoir la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat ; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites ; et -en cas de comparaison positive à interdire en temps réel le paiement pour l'utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement. En pratique, le module de traitement dorsal et le module de traitement bancaire comprennent des serveurs en architecture REDIS. Selon un mode de réalisation de l'invention, le module de traitement dorsal comprend en outre un gestionnaire de queues utilisé avec le serveur REDIS pour recevoir les demandes d'autorisation/interdiction afin de les ordonnancer. les stocker dans une base de données , puis de les envoyer de manière ordonnée par un moteur vers le module de traitement bancaire via un réseau de communication. L'invention porte en outre sur un programme d'ordinateur comprenant des instructions qui conduisent le système de traitement conforme à l'invention, à exécuter les étapes du procédé selon l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels : [fig.1] décrit schématiquement les étapes principales du contrôle parental conforme à l'invention ; [fig.2] décrit en détail les composants du système de traitement côté décideur ; [fig.3] représente schématiquement une liste d'autorisations /interdictions d'un décideur ; et [fig.4] représente schématiquement une liste complémentaire d'autorisations/interdictions d'un décideur. En référence aux [fig.1] et [Fig 2], on a représenté un système de traitement d'une transaction bancaire associée à une carte de paiement CARD détenue par un utilisateur UTI assujetti à un décideur DEC. Le contrôle parental s'articule autour d'une plateforrne logicielle permettant la gestion de l'utilisation d'un moyen de paiement CARD au profit d'un utilisateur (par exemple un enfant) assujetti à un décideur (par exemple un parent). En pratique, le décideur DEC contrôle/autorise/approuve l'utilisation monétaire au profit de l'utilisateur UTI à différents niveaux. Le premier niveau de contrôle consiste en l'activation ou non d'un moyen de paiement CARD en ligne. Le second niveau de contrôle consiste en l'établissement de règles d'utilisation du moyen de paiement CARD. Un troisième niveau de contrôle consiste en ce que le décideur DEC autorise ou non le déverrouillage d'une quantité d'argent sécurisée (cagnotte) depuis la platcforme, et non utilisable sauf autorisation spécifique du décideur, le bénéficiaire étant alors soumis à r approbation du décideur quant au but de l'achat auquel la somme sécurisée est destinée. Les règles d'utilisation du moyen de paiement CARD peuvent être les suivantes : [0002] 1) -la fixation d'un seuil de dépenses sur un délai donné ; [0003] 2) -Minima et maxima de retrait ; [0004] 3) -catégories d'achats/commerces validées ou non (interdites/ autorisées) par le décideur. De façon surprenante, le Demandeur a observé que les règles préalablement établies par le décideur peuvent être corrélées avec l'identification du type de commerce interrogé par le moyen de paiement lors de l'achat. Comme on le décrira plus en détail ci-après lors de l'achat, le MCC (Merchant Category code) du commerce à payer est comparé à une liste permettant d'établir la/les catégorie(s) de biens ou services proposés par le commerce, cette catégorie étant alors elle-même comparée à une liste de catégorie autorisée/interdite créée en amont par le décideur, et permettant de refuser/accepter le paiement par ce médium de paiement spécifique (de type carte bancaire, mobile, ...). En pratique, la catégorie de marchands MCC est un code composé de 4 caractères numériques. Il permet de répertorier un service, secteur d'activité ou produit d'un commerçant. À partir de ce code, la nature des produits vendus par le marchand peut être rattachée à une classe de produits qui peut faire l'objet d'une autorisation particulière ou non. Le contrôle parental est ici associé à un service de paiement principalement tourné vers les mineurs, dans lequel des blocages par défaut de certains codes MCC et d'autres, laissés au choix de chaque décideur (parent) parce qu'il ne s'agit pas de se substituer au parent mais davantage de l'outiller cc qui permet de fournir des éléments de réassurance aux parents, les cartes émises au nom et mises entre les mains des utilisateurs (enfants) ne pouvant être utilisées que chez des commerçants référencés au préalable. En pratique, les MCC bloqués par défaut sur toutes les Cartes CARD émises et en circulation sont les suivants : 5813 (Alcool et bars) 5921 (Vins & Liqueur) 5933 (Prêteur sur gage) 5993 (Boutiques de cigares) 7273 (Dating) 7800, 7801, 7802 (Loteries & Casino) 7995 (Paris en ligne), [3300- 3499] : 3351, 3352, 3353, 3354, 3355, 3357, 3359, 3360,3361, 3362, 3364, 3366, 3368, 3370, 3374, 3376, 3380, 3381, 3385, 3386, 3387, 3388, 3389, 3390, 3391, 3393, 3394, 3395,3396, 3398, 3400, 3405, 3409, 3412 (Loueurs de voiture). En revanche, les codes MCC faisant l'objet d'une autorisation particulière (laissée à la main de chaque décideur sont illustrés en référence aux [fig.3] et [Fig. 4], Ces MCC organisés par « famille » peuvent être bloqués BLO et débloqués DEBC par bloc CAT individualisés en CATI à CAT9. Le décideur DEC déplace le curseur CURS de chaque bloc CAT de la position bloquée BLO à la position débloquée DEBC et vice versa selon sa volonté à l'égard de l'utilisateur. A titre d'exemple non limitatif, les blocs CAT correspondent à : CATI Mode : 5611, 5621, 5631, 5641, 5651, 5655, 5661, 5681, 5691, 5697, 5698, 5699, 7631, 5094, 5137, 5139, 5931, 5941,5944,5948, 5949, 7296 ; CAT2 Cosmétique : 5977,7230; CAT3 Hi-Tech :5732, 5734,4812, 5072, 5045, 5044, 5065, 5251, 5946, 7622,7379, 7372; CAT4 Numérique Jeux: 5816 Culture: 5815, 5818,4899, Applications (Google & Apple store): 5817 Crédits téléphone/internet: 4813,4814,4816; CAT5 Loisirs (cinéma, sports, salles de jeux) : 7832, 7911,7922, 7929, 7932, 7933, 7941, 7991, 7992, 7993, 7994, 7996, 7997, 7998,7999, 7032, 7033, 7829, 7833,7841 ; et CAT6 Restaurants & Fast-food : 5811,5812, 5814 CAT7 Voyage (compagnies aériennes, hôtel) : [3000 ; 3299], [3500-3999] 6 CAT8 Mobilité (VTC, Vélib', Cityscoot) : 4121, 7311 CAT9 Carburant : 5541, 5542 On fait à nouveau référence aux figures 1 et 2. D'une manière structurelle, la plateforme logicielle comporte une architecture à deux branches, l'une côté décideur (dorsal) matérialisé par un module de traitement dorsal MOD DEC et l'autre côté bancaire (frontal) matérialisé par un serveur bancaire MAR BANK, et un module de traitement frontal MOD MAR. Une telle architecture permet le contrôle ou la limitation de mouvements monétaires/bancaires au profit de l'utilisateur à partir d'un établissement virtuel bancaire intermédiaire spécifique MARK BANK à la plateforme vers une entité tierce de type commerce, e-commerce et autres MAR. De manière fonctionnelle, le module bancaire (frontal) MAR BANK et le module dorsal MOD DEC comprennent chacun des serveurs de données de type REDIS, contenant les différentes configurations d'autorisations/interdictions émanant du décideur. Ces serveurs de données SER_DEC et les serveurs bancaires ont la particularité d'être en miroir, c'est-à-dire que les données contenues dans le serveur dorsal SER_DEC sont stockées à l'identique et en temps réel dans le serveur frontal MAR BANK. Afin d'assurer la consistance des données, ainsi qu'un fonctionnement en temps réel avec la prise en compte de multiples demandes de modification simultanées émanant des décideurs, un gestionnaire de queues de type BULL est utilisé avec le serveur dorsal SER DEC (système de gestion de base de données clef-valeur scalable) pour recevoir les demandes d'autorisation/interdiction, les ordonnancer. les stocker dans une base de données BDD, puis de les envoyer de manière ordonnée via un moteur ENG DEC vers le module bancaire frontal MAR_BANK via un réseau de communication RES. Une telle gestion permet d'éviter de bloquer la plateforme dans des transactions synchrones, qui baisseraient les performances de la plateforme, mais aussi d'éviter toute perte de données durant des transactions multiples. En référence aux figures 1 et 2, on va maintenant illustrer les étapes de fonctionnement du contrôle parental conformes à l'invention. Selon l'étape El (figure 1) ou selon l'étape Si (ligure 2), le module de traitement dorsal MOD_DEC (en pratique un serveur SER_DEC, figure 2) reçoit en provenance du décideur DEC une liste d'interdictions/autorisations de transaction de paiement au détriment/profit de l'utilisateur UTI de la carte de paiement CARD. L'interdiction/autorisation de transaction de paiement comprend au moins un code d'activité du commerçant MCC lié à la transaction de paiement. Le serveur dorsal SER_DEC reçoit les choix effectués par le décideur et crée en correspondance une liste de transactions de paiement interdites/autorisées par le décideur 7 au détriment/profit de l'utilisateur UTI de la carte CARD accompagnées des codes d'activité associés MCC, et Selon l'étape S3 (figure 2) le serveur dorsal SER DEC envoie en temps réel via le moteur ENG DEC et le réseau de communication RES la liste de transactions de paiement interdites/autorisées ainsi créée à un serveur bancaire (frontal) MARK BANK. Selon l'étape E2 (figure 1), en réponse à une demande de transaction de paiement de l'utilisateur UTI auprès d'un terminal de paiement MOD-MAR d'un commerçant MAR à l'aide de la carte de paiement de l'utilisateur CARD, le module de traitement frontal MOD MAR du terminal va émettre (selon l'étape E3, figure 1) une requête de paiement à destination du serveur bancaire MAR BANK. La requête de paiement comprend au moins le code d'activité du commerçant lié à la transaction de paiement. Le module de traitement bancaire MAR BANK stocke dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l'utilisateur de la carte de paiement accompagnées des codes d'activité associés. Selon l'étape E4, le module de traitement bancaire MAR BANK reçoit la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat. Selon l'étape E5, le code ainsi extrait est comparé à ceux de la liste des transactions de paiement interdites/autorisées. Selon l'étape E6, en cas de comparaison positive, le paiement est refusé pour l'utilisateur de la carte de paiement sinon en cas de comparaison négative, le paiement est autorisé. Par exemple, si X est un code MCC bloqué par le décideur (parent) dans sa tour de Contrôle parental (Figures 3 et 4) ; P le moyen de paiement de l'utilisateur (enfant) ; et V, le terminal de paiement/vente à distance composé de plusieurs MCC sur lequel l'utilisateur (enfant) essaie d'effectuer une opération alors : Si (V contient X ; P 0) et l'opération de paiement est rejetée ; Si (V X ; P : OK) et l'opération de paiement est autorisée (si les autres plafonds sont respectés, i.e. plafond de dépenses quotidiennes) Le système de contrôle et de gestion des autorisations et permissions de la platetbrme offre la possibilité au décideur (par exemple, parent) de définir des règles d'achats, basées sur la catégorie et le domaine d'activité d'un marchand. Comme déjà décrit, la particularité technique du contrôle parental réside ici dans le fait que ces restrictions sont construites en se basant sur les codes MCC (Merchant Category Code). Il s'agit d'un code utilisé lors d'une « transaction de paiement ou de retrait réalisée avec une carte bancaire pour indiquer le type d'activité du commerçant 8 à l'origine d'une opération. Le dispositif de contrôle parental permet à un parent d'activer/désactiver en temps réel des catégories/types de marchands en fonction de ses souhaits. La gestion des autorisations est effectuée en créant et en affectant aux utilisateurs (enfant) des listes noires (Blacklists) qui recensent l'ensemble des codes MCC qui sont interdits pour l'utilisateur (par exemple, enfant) par le décideur (par exemple, parent) dans ce cas d'espèce. Par défaut, tous les comptes utilisateurs enfants ont une Blacklist qui leur est affectée et qui interdit un ensemble de « types d'activités » non accepté pour la clientèle mineure (Alcool et bars - Vins & Liqueur - Prêteur sur gage - Boutiques de cigares - Dating - Loteries & Casino - Paris en ligne, Voyages). Cette liste de MCC est bloquée pour tous les utilisateurs. Le décideur peut procéder à la configuration de la carte de l'enfant en autorisant/interdisant des catégories d'activités particulières. Cela entraîne la création d'une blacklist personnalisée aux autorisations particulières (en plus des restrictions communes par défaut) qui sera affectée particulièrement à la carte de son enfant. La gestion des autorisations de paiement par MCC passe plusieurs étapes débutant par la catégorisation des MCC par types de domaines pertinents afin de faciliter la compréhension par le prescripteur (par exemple, parent). Par exemple, les catégories identifiées et disponibles sont : Mode CATI, Cosmétique CAT2, Numérique CAT3, Loisirs CAT4, Restaurants CAT5, Fast-food CAT6, Voyage CAT7, Mobilité CAT8, Carburant, CAT9. Ces catégories peuvent être constituées de sous-catégories. C'est par exemple le cas de la catégorie Numérique qui comporte les sous-catégories suivantes : Jeux, Culture, Applications (Google & Apple store), Crédits téléphone/ intemet. Cela donne la possibilité au parent de disposer d'un niveau de granularité plus avancé dans la gestion des autorisations. Le parent a accès, au niveau de son interface utilisateur « cockpit », à un ensemble d'options qu'il peut activer/désactiver afin de permettre les achats dans ces types de commerce spécifiques. Cet écran est visible dans l'interface applicative décrite en référence aux [fig.3] et [Fig 4]. Lorsque le parent apporte des modifications au niveau des autorisations, celles-ci sont automatiquement, et de manière instantanée, sauvegardées et prises en compte au niveau de la configuration de la carte de paiement. Cela se fait par la création instantanée d'une nouvelle blacklist pour l'enfant (s'il n'en a pas déjà une). Cette nouvelle blacklist (et/ou la version mise à jour par le changement 9 d'un paramètre) est sauvegardée dans la base de données BDD puis mise à disposition du prestataire bancaire MAR BANK afin que ce dernier puisse prendre en compte les nouveaux éléments de paramétrage spécifique de la carte. [Revendication 1] [Revendication 2] [Revendication 3] REVENDICATIONSProcédé de contrôle parental mis en oeuvre dans un système de traitement d'une transaction associée à une carte de paiement (CARD) détenue par un utilisateur (UTI) assujetti à un décideur (DEC), caractérisé en ce que le système de traitement comprend : -un module de traitement dorsal (MOD DEC) apte : -à recevoir en provenance du décideur (DEC) une liste de transactions de paiement interdites/autorisées au détriment/profit de l'utilisateur (UTI) de la carte de paiement, chaque transaction de paiement comprenant un code d'activité du commerçant lié à la transaction de paiement ; et -à envoyer en temps réel la liste de transactions de paiement interdites/ autorisées ainsi créée à un module de traitement bancaire (MOD_BANK). -un module de traitement frontal (MOD_MAR) propre : -en réponse à une demande de trmsaction de paiement de l'utilisateur auprès d'un terminal de paiement d'un commerçant à l'aide de la carte de paiement de l'utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire (MOD_BANK), ladite requête de paiement comprenant au moins le code d'activité du commerçant lié à la transaction de paiement ; -le module de traitement bancaire (MOD_BANK) étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l'utilisateur de la carte de paiement ; -à recevoir la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat ; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et -en cas de comparaison positive à interdire en temps réel le paiement pour l'utilisateur de la carte de paiement sinon ; -en cas de comparaison négative à autoriser le paiement. Procédé selon la revendication I. caractérisé en ce que le code d'activité du commerçant est basé sur le MCC (Merchant Category code). Système de traitement pour la mise en oeuvre du procédé de contrôle d'une transaction associée à une carte de paiement (CARD) détenue par un utilisateur (UTI) assujetti à un décideur (DEC) selon l'une des revendications 1 à 2, caractérisé en ce que le système de traitement 11 comprend : -un module de traitement dorsal (MOD_DEC) apte : -à recevoir en provenance du décideur (DEC) une liste de transactions de paiement interdites/autorisées au détriment/profit de l'utilisateur (UTI) de la carte de paiement, chaque transaction de paiement comprenant un code d'activité du commerçant lié à la transaction dc paiement ; et -à envoyer en temps réel la liste de transactions de paiement interdites/ autorisées ainsi créée à un module de traitement bancaire (MOD BANK). -un module de traitement frontal (MOD MAR) propre : -en réponse à une demande de transaction de paiement de l'utilisateur auprès d'un terminal de paiement d'un commerçant à l'aide de la carte de paiement de l'utilisateur ; à émettre une requête de paiement à destination du module de traitement bancaire (MOD BANK), ladite requête de paiement comprenant au moins le code d'activité du commerçant lié à la transaction de paiement ; -le module dc traitement bancaire (MOD BANK) étant propre, -à stocker dynamiquement en mémoire la liste des transactions de paiement interdites/autorisées pour l'utilisateur dc la carte de paiement ; -à recevoir la requête de paiement afin d'en extraire instantanément le code d'activité du commerçant lié à l'achat ; -à comparer ledit code ainsi extrait à la liste des transactions de paiement interdites/autorisées ; et -en cas de comparaison positive à interdire en temps réel le paiement pour l'utilisateur de la carte de paiement sinon -en cas de comparaison négative à autoriser le paiement. [Revendication 4] Système de traitement selon la revendication 3, caractérisé en ce que le module de traitement dorsal (MOD_DEC) et le module de traitement bancaire (MOD_BANK) comprennent des serveurs en architecture REDIS. [Revendication 5] Système de traitement selon la revendication 3, caractérisé en ce que le module de traitement dorsal (MOD_DEC) comprend en outre un gestionnaire de queues utilisé avec le serveur REDIS (RED_DEC) pour recevoir les demandes d'autorisation/interdiction afin de les ordonnancer. les stocker dans une base de données (BDD). puis de les envoyer de manière ordonnée par un moteur (ENG DEC) vers le module de traitement bancaire (MAR_BANK) via un réseau de commu- 12 nication (RES). [Revendication 6] Programme d'ordinateur comprenant des instructions qui conduisent le système dc traitement selon l'une des revendications 3 à 5, à exécuter les étapes du procédé selon l'une des revendications 1 ou2.