FR3105513A1 - Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur. - Google Patents

Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur. Download PDF

Info

Publication number
FR3105513A1
FR3105513A1 FR1914842A FR1914842A FR3105513A1 FR 3105513 A1 FR3105513 A1 FR 3105513A1 FR 1914842 A FR1914842 A FR 1914842A FR 1914842 A FR1914842 A FR 1914842A FR 3105513 A1 FR3105513 A1 FR 3105513A1
Authority
FR
France
Prior art keywords
user
delegated
identifier
access
holder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1914842A
Other languages
English (en)
Inventor
Fabrice Jeanne
Baptiste François HEMERY
Sandrine LE CALVEZ
Romain TRINQUART
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1914842A priority Critical patent/FR3105513A1/fr
Priority to US17/786,492 priority patent/US20230009823A1/en
Priority to PCT/FR2020/052177 priority patent/WO2021123527A1/fr
Priority to EP20821056.7A priority patent/EP4078495A1/fr
Publication of FR3105513A1 publication Critical patent/FR3105513A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L’invention concerne un procédé et un dispositif de gestion d’une autorisation d’accès à service de paiement fourni à un utilisateur, dit utilisateur titulaire. Une requête d’initialisation d’au moins une autorisation d’accès est reçue en provenance d’un terminal dudit utilisateur titulaire. Une telle autorisation d’accès est destinée à permettre à au moins un utilisateur délégataire d’accéder audit compte dudit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire. Des données temporaires d’accès au compte associées audit utilisateur délégataire sont générées, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public. Les données temporaires sont transmises vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur. Figure pour l’abrégé : FIG.2A

Description

Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.
1. Domaine de l'invention
L’invention se situe dans le domaine des technologies utilisées pour la mise en œuvre de services de paiement, et notamment de services de monnaie numérique, de paiement mobile, de paiement prépayé, par carte ou non. L’invention concerne plus particulièrement la gestion d’autorisation d’accès d’un tiers à un tel système de paiement associé à un utilisateur titulaire, pour réaliser des transactions de paiement.
2. Art Antérieur
Il existe aujourd’hui différents types de services de paiement permettant à des utilisateurs de réaliser des transactions via un service de paiement auprès duquel ils se sont authentifiés au préalable, par exemple via la création d’un compte auprès du service de paiement.
De tels services de paiement sont par exemple et de manière non limitative:
  • Un service de paiement mobile,
  • Un service de paiement par carte,
  • Un service de monnaie numérique,
  • Un service de paiement par compte prépayé,
  • Un système de service de paiement en ligne et/ou de transferts d’argent.
De tels services de paiement peuvent être associés à un compte bancaire de l’utilisateur, ou bien basés sur un compte prépayé, ou bien associé à un moyen de paiement associé à un compte bancaire de l’utilisateur (par exemple une carte, ou un compte d’un fournisseur de services, par exemple un opérateur de communications mobiles).
Dans la plupart de ces services de paiement, les fournisseurs de ces services de paiement imposent, qu’avant la réalisation d’une transaction de paiement ordonnée par l’utilisateur authentifié auprès du service de paiement, le solde du compte de l’utilisateur auprès du service de paiement ne soit pas négatif ou bien qu’un moyen de paiement associé à un compte bancaire de l’utilisateur soit associé au compte du service de paiement de l’utilisateur. Autrement dit, l’utilisateur doit soit transférer de l’argent vers son compte du service de paiement ou bien associer un moyen de paiement associé à un compte bancaire, pour pouvoir réaliser une transaction de paiement via le compte du service de paiement.
Les types de services de paiements cités ci-dessus permettent de réaliser des transactions de paiement ponctuelles. Toutefois, le mode de fonctionnement de ces services de paiement n’est pas adapté à la mise en place d’autres services de type prélèvement, caution, crédit, … car il n’est pas possible d’anticiper un solde d’un compte d’un utilisateur d’un tel service de paiement, à une échéance fixe dans le futur. En effet, le compte pourrait ne plus être approvisionné, voire clôturé.
L’utilisation de ce type de services de paiement par des utilisateurs pose donc un problème de confiance des tiers vis-à-vis de ces utilisateurs …. Il est également à noter que pour répondre à des contraintes réglementaires en vigueur, l’identité d’un utilisateur associée à un compte d’un service de paiement est unique. De plus, pour des raisons de sécurité évidentes, il est déconseillé de transférer l’identifiant d’un compte d’un service de paiement ou les données d’authentification d’un utilisateur auprès du service de paiement à des tiers pour leur permettre de réaliser des transactions via ce compte
Il existe donc un besoin d’améliorer la technique pour offrir plus de services aux utilisateurs de ce type de services de paiement.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique. Elle concerne à cet effet un procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur, dit utilisateur titulaire. Le procédé est mis en œuvre par un processeur d’un dispositif de gestion, et :
  • La réception, en provenance d’un terminal dudit utilisateur titulaire, d’une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
  • La génération de données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
  • La transmission vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur desdites données temporaires.
L’invention permet ainsi à un utilisateur titulaire d’attribuer à un ou plusieurs utilisateurs délégataires une autorisation d’accès à un service de paiement qui lui est fourni. L’utilisateur titulaire du service de paiement est un utilisateur possédant des données d’authentification lui permettant de s’authentifier auprès du fournisseur de service de paiement et d’accéder au service de paiement. Par exemple, le service de paiement peut être un service de paiement mobile basé sur un compte prépayé, ou bien un service de paiement en ligne associé à un moyen de paiement de l’utilisateur titulaire, par exemple une carte bancaire, ou associé à un compte authentifié auprès d’un fournisseur de service, par exemple un opérateur de réseau de communications.
L’invention permet d’élargir aux utilisateurs de services de paiement, notamment mobile ou en ligne, et à leur entourage, la gamme de services offerts par ce type de services de paiement tout en garantissant des contraintes d’identification requises vis-à-vis de la réglementation en vigueur, un contrôle des transactions réalisées et un niveau de sécurité accru.
Grâce à l’invention, l’utilisateur titulaire peut déléguer des droits d’accès au service de paiement auprès duquel il est authentifié pour permettre à des utilisateurs délégataires de réaliser des transactions de paiement. La sécurité des données d’authentification de l’utilisateur titulaire est garantie car celui-ci ne fournit pas son identifiant et code secret à des tiers. Un utilisateur délégataire d’une autorisation d’accès au service de paiement de l’utilisateur titulaire dispose de données d’accès (identifiant et code) temporaires générés et fournis par le dispositif de gestion et associées à cet utilisateur délégataire.
Les données d’accès temporaires sont transmises à l’utilisateur délégataire, ou à un autre utilisateur bénéficiaire, dans le cas où l’utilisateur délégataire n’est pas le donneur d’ordre des transactions de paiement à réaliser via le service de paiement fourni à l’utilisateur titulaire.
Lorsque le service de paiement fonctionne en association avec un compte créé pour l’utilisateur titulaire, par exemple un compte prépayé, le procédé d’accès défini ci-dessus permet de déléguer des droits d’accès au compte de l’utilisateur titulaire.
Selon un mode particulier de réalisation de l'invention, la requête comprend en outre une indication d’un type d’autorisation d’accès et au moins un paramètre associé audit type d’autorisation d’accès. Selon ce mode particulier de réalisation de l’invention, l’utilisateur titulaire donne accès à un service de paiement qui lui est fourni ou à son compte pour un type d’autorisation donné. Par exemple, l’accès peut être donné pour un type de transaction seulement, tel qu’une autorisation de prélèvement, une caution solidaire, …
De plus, le type d’autorisation est associé à des paramètres permettant au dispositif de gestion ou à un serveur de contrôler l’utilisation du service de paiement ou du compte faite par l’utilisateur délégataire. Par exemple, de tels paramètres sont le montant autorisé, la périodicité d’un paiement, une durée de validité de l’autorisation, ….
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend en outre, préalablement à la transmission desdites données temporaires:
  • L’envoi au terminal de l’utilisateur titulaire, d’une demande de confirmation de la requête d’initialisation,
  • La réception, en provenance du terminal de l’utilisateur titulaire, d’un message de confirmation comprenant un code confidentiel dudit utilisateur titulaire d’accès audit service de paiement.
Selon ce mode particulier de réalisation de l’invention, la création de l’autorisation d’accès est confirmée par l’utilisateur titulaire par l’envoi de son code confidentiel. Le dispositif de gestion peut ainsi vérifier l’authenticité de la requête d’initialisation d’une autorisation d’accès reçue.
Selon un autre mode particulier de réalisation de l'invention, la génération des données temporaires comprend:
  • L’encodage dudit identifiant de l’utilisateur titulaire à l’aide d’une clé de chiffrement propre au dispositif de gestion pour former ledit identifiant public associé à l’utilisateur délégataire,
  • L’encodage dudit code confidentiel de l’utilisateur titulaire à l’aide de ladite clé de chiffrement pour former ledit code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire,
  • La mémorisation dudit identifiant public associé à l’utilisateur délégataire et d’un index de clé identifiant ladite clé de chiffrement.
Selon ce mode particulier de réalisation de l’invention, l’identifiant public est généré à partir de l’identifiant de l’utilisateur titulaire et d’une clé de chiffrement. Cette même clé est également utilisée pour générer le code confidentiel associé à l’identifiant public généré. Avantageusement, le code confidentiel généré n’est pas mémorisé par le dispositif de gestion. Ce code confidentiel est transmis à l’utilisateur délégataire. Lors de l’accès au service de paiement de l’utilisateur titulaire par l’utilisateur délégataire ou un autre utilisateur bénéficiaire, le dispositif de gestion ou un serveur pourra décoder un code confidentiel reçu, à l’aide de la clé de chiffrement et vérifier si l’utilisateur délégataire ou l’autre utilisateur est bien autorisé à accéder au service de paiement de l’utilisateur titulaire.
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend au préalable:
  • La réception, en provenance d’un terminal dudit utilisateur délégataire, d’une requête d’initialisation d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire, la requête comprenant l’identifiant dudit utilisateur délégataire, l’identifiant dudit utilisateur titulaire et un montant de transaction de paiement,
  • L’envoi au terminal de l’utilisateur titulaire, d’un message informant l’utilisateur titulaire de la requête d’initialisation d’une autorisation d’accès envoyée par le terminal de l’utilisateur délégataire, le message comprenant l’identifiant dudit utilisateur délégataire, et un montant de transaction de paiement.
Selon ce mode particulier de réalisation de l’invention, c’est l’utilisateur délégataire qui est à l’origine de la requête d’initialisation d’autorisation d’accès.
Par exemple, ce mode particulier de réalisation de l’invention est intéressant dans le cas où l’utilisateur délégataire souhaite que l’utilisateur titulaire se porte caution pour lui. En variante, l’utilisateur délégataire peut demander à plusieurs premiers utilisateurs de se porter caution pour lui. Dans ce cas, l’utilisateur délégataire envoie autant de requête d’initialisation d’une autorisation d’accès que d’utilisateurs auquel il souhaite demander de se porter caution pour lui.
Selon un autre mode particulier de réalisation de l'invention, lorsque le dispositif de gestion reçoit au moins une autre requête d’initialisation d’au moins une autorisation d’accès, en provenance d’un terminal d’un autre utilisateur titulaire, et destinée à permettre audit utilisateur délégataire d’accéder audit service de paiement dudit autre utilisateur titulaire, ladite requête comprenant au moins l’identifiant dudit utilisateur délégataire et un identifiant dudit autre utilisateur titulaire, le procédé comprend en outre:
  • La mémorisation d’un compte agrégé comprenant, pour chaque utilisateur titulaire, l’identifiant public généré à partir de l’identifiant dudit utilisateur titulaire et associé audit utilisateur délégataire, l’index de clé utilisée pour générer le code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire à partir du code confidentiel de l’utilisateur titulaire.
Ce mode particulier de réalisation de l’invention permet de créer un compte agrégé pour l’utilisateur délégataire à partir de plusieurs services de paiement ou comptes d’utilisateurs titulaires qui lui ont autorisé l’accès au service de paiement qui leur ait respectivement fourni.
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend en outre:
  • La réception, en provenance d’un terminal d’un utilisateur bénéficiaire, d’une demande d’exécution de paiement comprenant l’identifiant public associé à l’utilisateur délégataire, le code confidentiel associé audit identifiant public et un montant de paiement,
  • le décodage de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire, à partir de l’index de clé mémorisé, de l’identifiant public associé à l’utilisateur délégataire, et du code confidentiel associé audit identifiant public associé à l’utilisateur délégataire,
  • la transmission d’un ordre d’exécution de paiement du montant à l’utilisateur bénéficiaire, via le service de paiement fourni à l’utilisateur titulaire à partir de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire décodés.
L’invention concerne également un dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur titulaire, comprenant une mémoire et un processeur configurés pour:
  • recevoir, en provenance d’un terminal dudit utilisateur titulaire, une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
  • générer des données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
  • transmettre vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur lesdites données temporaires.
Selon un mode particulier de réalisation de l'invention, le dispositif de gestion précité est compris dans un serveur.
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé de gestion peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, telle qu’une mémoire. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de gestion en question.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels:
La figure 1A illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention,
La figure 1B illustre un exemple d'environnement de mise en œuvre de l'invention selon un autre mode particulier de réalisation de l'invention,
La figure 2A illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention,
La figure 2B illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un autre mode particulier de réalisation de l'invention,
La figure 3A illustre d’autres étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention,
La figure 3B illustre d’autres étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un autre mode particulier de réalisation de l'invention,
La figure 4 illustre un exemple d’un dispositif de gestion selon un mode particulier de réalisation de l’invention.
5. Description d'un mode de réalisation de l'invention
L’invention propose un procédé de gestion des autorisations d’accès à un service de paiement fourni à un utilisateur, aussi appelé utilisateur titulaire par la suite, pour permettre à des tiers (utilisateurs délégataires, utilisateurs bénéficiaires) de réaliser des transactions de paiement via le service de paiement fourni à l’utilisateur titulaire.
En particulier, l’invention permet d’élargir la gamme de services offerts aux utilisateurs de système de paiement, et notamment aux systèmes de paiement basé sur un compte prépayé, en garantissant les contraintes d’identification, le contrôle des transactions et un niveau de sécurité équivalent aux mécanismes de transactions bancaires classiques.
Le procédé de gestion décrit ci-dessous offre un mécanisme sécurisé pour mettre en place une délégation de droits d’accès à un service de paiement utilisé par un utilisateur titulaire permettant à des tiers de réaliser des transactions en utilisant le service de paiement fourni à l’utilisateur titulaire tout en respectant certaines contraintes et en utilisant un identifiant et un code secret différent de celui de l’utilisateur titulaire. Le mécanisme est ainsi sécurisé et les transactions réalisées sont traçables. Autrement dit, l’identité du tiers demandant la réalisation de la transaction est authentifiée avant que la transaction soit exécutée.
Lorsque le fonctionnement du service de paiement est basé sur l’utilisation d’un compte authentifié auprès du fournisseur du service de paiement, compte prépayé ou non, le procédé de gestion décrit ci-dessous permet de mettre en place une délégation de droits d’accès au compte de l’utilisateur titulaire.
On décrit ci-après en relation avec la figure 1A un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention.
L’environnement de la figure 1A comprend un terminal TP1 d’un utilisateur titulaire P1. L’utilisateur titulaire P1 possède un accès authentifié auprès d’un fournisseur de service de paiement, par exemple un service de paiement mobile. Dans le mode particulier de réalisation décrit ici, le service de paiement est basé sur l’utilisation d’un compte créé pour chaque utilisateur titulaire auprès du fournisseur de service. Par exemple, un compte prépayé.
Dans un autre mode particulier de réalisation de l’invention, le service de paiement peut fonctionner sans nécessiter la création d’un compte. Dans ce cas, un utilisateur titulaire authentifié du service de paiement associe à ses données d’authentification auprès du service de paiement, un moyen de paiement associé à un compte bancaire ou à un compte d’un autre fournisseur de service (par exemple un opérateur de communications).
L’environnement comprend par exemple un ou des serveur(s) de paiement SB du fournisseur de service de paiement. Notamment, le serveur de paiement SB reçoit et exécute les ordres de paiement et répond aux demandes de consultation de solde de compte.
Lorsque le service de paiement n’est pas associé à un compte, une demande de consultation de solde de compte peut correspondre à une interrogation d’une disponibilité de solde ou d’un plafond autorisé par le moyen de paiement qui a été associé aux données d’authentification de l’utilisateur titulaire auprès du service de paiement.
Selon l’invention, c’est l’utilisateur titulaire, ici P1, qui autorise un tiers à initier une ou des transactions pour son compte en utilisant le service de piement qui est fourni à l’utilisateur titulaire. L’environnement comprend également un utilisateur délégataire D1 muni par exemple d’un terminal TD1. L’utilisateur délégataire D1 ne possède pas obligatoirement de compte authentifié auprès du fournisseur du service de paiement. Selon l’invention, cet utilisateur D1 reçoit, par exemple sur son terminal TD1, des données d’accès provisoires au service de paiement ou au compte de l’utilisateur P1. De telles données provisoires comprennent notamment un alias public et un code secret associé à cet alias public. Lors de la mise en place de la délégation d’accès ou autorisation d’accès, l’utilisateur délégataire D1 reçoit le droit d’initier une ou des transactions via le service de paiement de l’utilisateur titulaire P1.
Selon un mode de réalisation particulier de l’invention, l’environnement comprend également un utilisateur bénéficiaire B1, muni d’un terminal TB1. L’utilisateur bénéficiaire possède des données d’authentification auprès d’un fournisseur de service de paiement, qui peut être identique ou différent du fournisseur de service de paiement auprès duquel l’utilisateur titulaire P1 possède des données d’authentification, et un compte authentifié selon le cas. L’utilisateur bénéficiaire B1 est apte à recevoir un paiement ordonné par l’utilisateur délégataire D1 et payé via le service de paiement fourni à l’utilisateur titulaire P1. Lorsque le service de paiement est associé à un compte authentifié, ce paiement est payé via le compte de l’utilisateur titulaire, sinon via le moyen de paiement associé aux données d’authentification de l’utilisateur titulaire.
Sous certaines conditions, l’utilisateur bénéficiaire B1 peut vérifier la solvabilité du compte de l’utilisateur titulaire P1.
Dans un mode particulier de réalisation de l’invention, l’utilisateur bénéficiaire B1 est identique à l’utilisateur délégataire D1.
L’environnement comprend également un dispositif de gestion SERV, géré par le fournisseur de service de paiement fournissant le service de paiement à l’utilisateur titulaire P1 . Ce serveur SERV réalise la mise en place de l’autorisation d’accès au service de paiement fourni à l’utilisateur titulaire P1 par la génération et la gestion d’alias publics, la génération de codes secrets associés et leur sécurisation et la gestion des contraintes spécifiques fixées pour l’utilisation des alias générés.
Dans un mode particulier de réalisation de l’invention, le dispositif de gestion SERV est compris dans le serveur SB du fournisseur de service de paiement.
Le serveur SERV répond aux requêtes:
  • D’un utilisateur titulaire: pour donner l’autorisation d’accès d’un tiers au service de paiement fourni à l’utilisateur titulaire, en initialisant un (ou des) alias public de l’identifiant personnel de l’utilisateur titulaire diffusable aux utilisateurs délégataires identifiés et un code secret provisoire associé à l’alias public/aux alias publics,
  • D’un utilisateur délégataire: pour demander l’exécution d’une transaction en fournissant l’alias public reçu et le code secret provisoire associé. Le serveur vérifie que les conditions d’utilisations (seuils, montant, date …) sont conformes aux conditions fixées lors de la mise en place de l’autorisation d’accès,
  • D’un utilisateur bénéficiaire: lorsque celui-ci est un utilisateur différent d’un utilisateur délégataire, pour demander l’exécution d’une demande de paiement/transaction à échéance en fournissant l’alias public reçu.
La mise en place d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire P1 peut être réalisée via les terminaux TP1, TD1 et TB1 des différents utilisateurs en jeu, par exemple via une application dédiée fournie par le fournisseur de service de paiement de l’utilisateur titulaire P1. Une telle application comprend notamment, pour le titulaire, un formulaire de déclaration d’un tiers et de saisie d’informations d’identification d’utilisateurs délégataires.
Selon une variante, lors de la saisie pour l’initialisation d’une autorisation d’accès, l’application peut permettre à l’utilisateur titulaire de préciser un type de délégation, tel que prélèvement, caution, carte de paiement…, ainsi que des contraintes spécifiques d’utilisation telles que durée, périodicité, montant maximum alloué…
L’application comprend également, pour le bénéficiaireou le délégataire, un ou des formulaires permettant la saisie d’un alias en lieu et place de l’identification courante (par exemple MSISDN) et du code secret associé à cet alias, ainsi qu’une interface permettant de demander l’exécution d’un ordre de paiement ou une consultation de solde pour vérifier un solde disponible.
Les terminaux TP1, TB1 et TD1 communiquent avec le serveur SERV via un réseau de communication RES.
Selon le mode particulier de réalisation décrit ici, il y a un utilisateur titulaire P1 et un utilisateur délégataire D1. Selon d’autres variantes, l’utilisateur titulaire P1 peut autoriser l’accès à son service de paiement à plusieurs utilisateurs délégataires D1, D2, …
Selon un autre mode particulier de réalisation décrit, un même utilisateur délégataire D1 peut être autorisé par plusieurs utilisateurs titulaires P1, P2, …, PN, à utiliser leur service de paiement. La figure 1B illustre un exemple de mise en œuvre d’un tel mode particulier de réalisation de l’invention. L’environnement de la figure 1B comprend par exemple en plus des éléments déjà présentés en relation avec la figure 1A, un nombre N d’utilisateurs titulaires 1 à N munis respectivement d’un terminal TPi, i allant de 1 à N, N étant un nombre entier supérieur à 1. Selon cet exemple, l’utilisateur délégataire D1 reçoit l’autorisation d’utiliser le service de paiement ou le compte de chacun des utilisateurs titulaires P1,…, PN.
Selon une variante de réalisation, les autorisations reçues par l’utilisateur délégataire D1 sur chacun des comptes des utilisateurs titulaires P1,…, PN sont agrégées en un compte agrégé permettant à un utilisateur bénéficiaire B1, par exemple équipé d’un terminal TB1, de demander l’exécution d’une transaction sur le compte agrégé issu des comptes des utilisateurs titulaires P1,…, PN.
La figure 2A illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention. Le procédé est ici décrit dans le cas où le service de paiement est associé à un compte.
Dans le mode particulier de réalisation de l’invention décrit ici, l’utilisateur titulaire P1 demande la mise en place d’une autorisation de prélèvement au bénéfice de l’utilisateur délégataire D1.
Par exemple, il s’agit d’autoriser un fournisseur de services à demander l’exécution d’un paiement à échéance (facture) sur le compte de l’utilisateur titulaire P1.
Le procédé décrit ci-dessous s’applique bien entendu à d’autres types d’autorisations.
Lors d’une étape E200, l’utilisateur titulaire P1 envoie, via son terminal TP1, une requête d’initialisation d’une autorisation d’accès. Une telle requête comprend notamment un identifiant de l’utilisateur délégataire D1 et l’identifiant de l’utilisateur titulaire P1. Selon la variante décrite ici, l’utilisateur titulaire P1 indique le type d’autorisation demandée, ici autorisation de prélèvement, et définit des paramètres optionnels associés au type d’autorisation. Par exemple, l’utilisateur titulaire P1 indique un montant maximum par demande d’exécution, une périodicité ou autorisation d’une exécution d’un ordre de paiement par unité de temps, une durée de validité de l’autorisation, une somme maximale allouée à l’autorisation, etc….
De préférence, l’identifiant de l’utilisateur délégataire D1 fourni est un identifiant authentifié auprès du fournisseur de service de paiement auprès duquel l’utilisateur titulaire P1 est également authentifié. Autrement dit, l’utilisateur délégataire dispose d’un compte authentifié auprès de cet opérateur.
Sur réception de la requête, lors d’une étape E210, le serveur génère des données temporaires d’accès au compte associées à l’utilisateur délégataire D1. En particulier, le serveur génère un alias ou aussi appelé identifiant public, à partir de l’identifiant de l’utilisateur titulaire P1. Cet alias est associé à l’utilisateur délégataire D1.
Pour cela, le serveur encode au moyen d’une clé propre au serveur, sélectionnée parmi une liste de clés disponibles, l’identifiant authentifié de l’utilisateur titulaire P1 pour produire un alias public selon un format cible fonction du type d’autorisation.
Lors d’une étape E220, le serveur envoie au terminal de l’utilisateur titulaire P1, une demande de confirmation de la requête d’initialisation d’autorisation d’accès.
L’utilisateur titulaire P1 confirme sa requête lors d’une étape E230, par l’envoi au serveur d’un message de confirmation comprenant le code confidentiel (code secret) de l’utilisateur titulaire P1. Ces échanges permettent à l’utilisateur titulaire P1 de signer sa requête d’initialisation d’autorisation d’accès.
Lors d’une étape E240, le serveur génère alors un code secret provisoire associé à l’alias généré lors de l’étape E210. Pour cela, le serveur encode, à l’aide de la clé sélectionnée, le code secret de l’utilisateur titulaire P1 pour produire un nouveau code secret de même taille associé à cet alias sous la forme de 4 digits par exemple.
Par exemple, les données temporaires associées à l’utilisateur délégataire peuvent être de la formesuivante: pour l’alias: un code à 8 chiffres (dans le cas d’un identifiant classique) ou un code à 16 chiffres (dans le cas d’un identifiant correspondant à un identifiant de carte «corporate» - corporative en français-), et pour le code secret temporaire: 4 digits.
Lors d’une étape E250, le serveur enregistre alors les données associées à cette autorisation:
  • identifiant de l’utilisateur titulaire P1
  • alias (identifiant public) temporaire généré,
  • index de la clé utilisée pour l’encodage,
  • les paramètres d’utilisation définis par l’utilisateur titulaire P1.
Pour des contraintes de sécurité, le serveur n’enregistre jamais en clair le code secret de l’utilisateur titulaire P1, ni le code secret temporaire généré mais conserve un moyen de le déchiffrer à la volée lors de l’exécution d’une transaction à partir des données reçues (alias + code secret temporaire associé).
Lors d’une étape E260, le serveur diffuse alors, via le réseau RES, vers l’utilisateur délégataire D1 et l’utilisateur titulaire P1, l’alias généré, correspondant ici pour une autorisation de prélèvement, à une agrégation de l’alias généré et du code secret provisoire.
En variante, l’alias public est envoyé par le serveur, via le réseau RES, à l’utilisateur titulaire P1 qui se charge de le transmettre à l’utilisateur bénéficiaire, via le réseau RES ou tout autre réseau de communication adapté.
Lorsqu’il n’est pas agrégé à l’alias, le code secret temporaire généré est envoyé directement par le serveur par un moyen sécurisé à l‘utilisateur délégataire.
A l’issu des étapes décrites ci-dessus, la mise en place de l’autorisation d’accès au compte de l’utilisateur titulaire P1 se traduit par l’émission d’un ticket d’autorisation (combinaison de l’alias associé à l’utilisateur délégataire D1 et du code secret temporaire), non prélevé sur le compte de l’utilisateur titulaire P1. Autrement dit, la somme est toujours disponible pour l’utilisateur titulaire P1.
On décrit maintenant en relation avec la figure 3A la consommation de ce ticket d’autorisation. Toute demande de consommation de ce ticket est soumise à validation au moment du prélèvement, par exemple vérification du solde disponible, des critères d’utilisation…
L’utilisateur délégataire D1 voulant procéder à un paiement sur le compte de l’utilisateur titulaire P1, lors d’une étape E270, l’utilisateur délégataire D1 saisit ses identifiants sur l’application de son terminal TD1:
  • l’identifiant public (alias) reçu,
  • le code secret provisoire reçu,
  • le montant du paiement.
Lors d’une étape E280, le serveur obtient la clé de chiffrement utilisée à partir de l’index de clé qui a été mémorisé avec l’identifiant public reçu. Il obtient ensuite l’identifiant et le code confidentiel de l’utilisateur titulaire, en décodant l’identifiant public et le code secret provisoire reçus à partir de la clé de chiffrement obtenue.
Lors d’une étape E290, le serveur vérifie les conditions d’utilisation associées à l’alias public: validité, montant, périodicité du paiement, etc…
Si les conditions sont valides, lors d’une étape E291, le serveur transmet un ordre d’exécution de paiement du montant au bénéfice de l’utilisateur délégataire D1, via le compte de l’utilisateur titulaire P1. Pour cela, le serveur SERV transfère la demande de paiement à un serveur de transaction de paiement SB, avec le code secret et l’identifiant décodés de l’utilisateur titulaire P1 et demande l’exécution du paiement au nom de l’utilisateur titulaire P1 du compte.
Lors d’une étape E292, le serveur de transaction de paiement SB transfère la somme du compte de l’utilisateur titulaire P1 vers le compte du titulaire délégataire D1.
Selon un mode particulier de réalisation de l’invention, l’utilisateur titulaire du compte est notifié et reçoit une demande de validation de la transaction (non représentés en figure 3A).
Lorsque les conditions vérifiées à l’étape E290 ne sont pas valides, la transaction, ici un prélèvement, est rejetée. Lors d’une étape E292’, le serveur notifie l’utilisateur délégataire D1 et l’utilisateur titulaire P1.
Selon un mode particulier de réalisation de l’invention, un utilisateur bénéficiaire/délégataire peut vérifier la solvabilité d’un utilisateur titulaire, par exemple avant d’effectuer une demande de prélèvement.
L’utilisateur bénéficiaire saisit les données temporaires reçues comprenant l’alias et le code secret provisoire.
Le serveur reçoit cette demande et procède à l’extraction de l’identifiant de l’utilisateur titulaire et de son code secret.
Le serveur demande une vérification de compte et de solde au nom de l’utilisateur titulaire et transfère le résultat sous une forme OK/KO à l’utilisateur bénéficiaire/délégataire, via le réseau RES.
La figure 2B illustre des étapes du procédé de gestion d’une autorisation d’accès à un compte d’un utilisateur selon un autre mode particulier de réalisation de l'invention. Selon ce mode particulier de réalisation de l’invention, un utilisateur délégataire D1 demande une autorisation d’accès à plusieurs utilisateurs titulaires Pi, i allant de 1 à N. Par exemple, un entrepreneur (utilisateur délégataire D1) demande à des investisseurs (utilisateurs titulaires Pi) de mettre à sa disposition une certaine somme pour l’aider à développer son activité.
Les investisseurs s’engagent à lui fournir tout ou partie de cette somme qui ne sera pas prélevée de leur compte, ni même bloquée, mais la somme apparait comme virtuellement disponible sur le compte de l’entrepreneur auprès du fournisseur de service de paiement.
La mise en place des autorisations sur les comptes des utilisateurs titulaires se fait de manière similaire à celle décrite en relation avec la figure 2A.
Pour chaque utilisateur titulaire Pi, les étapes suivantes E180i et E190i sont mises en œuvre.
Lors de l’étape E180i, le terminal TD1 de l’utilisateur délégataire D1 envoie au serveur SERV une requête d’initialisation d’une autorisation d’accès au compte de l’utilisateur titulaire Pi, la requête comprenant l’identifiant de l’utilisateur délégataire D1, l’identifiant de l’utilisateur titulaire Pi et un montant de transaction de paiement.
Lors de l’étape E190i, le serveur SERV envoie au terminal de l’utilisateur titulaire Pi, un message informant l’utilisateur titulaire Pi de la requête envoyée par l’utilisateur délégataire D1 en indiquant l’identifiant de l’utilisateur délégataire D1, et le montant de transaction de paiement.
Si l’utilisateur titulaire Pi accepte la demande d’autorisation d’accès à son compte, il est procédé aux étapes E200i, E210i, E220i, E230i, E240i et E250i. Ces étapes sont identiques aux étapes E200, E210, E220, E230, E240 et E250 décrites en relation avec la figure 2A.
Lors d’une étape E300, le serveur SERV crée un compte agrégé pour l’utilisateur délégataire D1 à partir des alias générés à partir de chaque utilisateur titulaire Pi, et des codes confidentiels temporaires associés. Ce compte agrégé comprend alors un nouvel alias correspondant à la concaténation des alias de chaque utilisateur titulaire Pi et un code secret provisoire généré à partir des codes confidentiels temporaires associés. Ce compte agrégé comprend également une concaténation d’index de clés et des règles de répartition pour l’exécution d’un paiement via le compte agrégé.
Lors d’une étape E310, le serveur mémorise les données temporaires du compte agrégé pour chaque type de délégation demandé par l’utilisateur délégataire D1.
Par exemple, dans le mode particulier de réalisation décrit ici, une autorisation de consultation et une autorisation de paiement ont été demandées. Le serveur SERV initie donc les deux types d’autorisation avec les données temporaires du compte agrégé.
Puis, le serveur SERV diffuse les données temporaires.
Pour une autorisation de consultation, lors d’une étape E320, le serveur SERV transmet au terminal de l’utilisateur délégataire D1, une concaténation du nouvel alias et code secret provisoire du compte agrégé. Le terminal de l’utilisateur délégataire D1 transmet ces données, lors d’une étape E330, à l’utilisateur bénéficiaire B1, via le réseau RES ou tout autre réseau adapté.
Pour une autorisation de paiement, lors d’une étape E340, le serveur SERV transmet au terminal de l’utilisateur délégataire D1 le nouvel alias du compte agrégé. Il transmet ensuite, lors d’une étape E341, via un moyen sécurisé, le code secret provisoire du compte agrégé au terminal de l’utilisateur délégataire D1.
On décrit maintenant en relation avec la figure 3B, les étapes d’utilisation des autorisations d’accès mises en place dans l’exemple de réalisation décrit en relation avec la figure 2B. Ici, deux utilisations sont possibles: caution ou dépôt de garantie et réserve de trésorerie.
Pour la caution ou dépôt de garantie, sur demande d’un fournisseur de service (utilisateur bénéficiaire B1), l’entrepreneur (utilisateur délégataire D1) va apporter une garantie sur la base de la caution pour la fourniture/l’utilisation d’un bien ou d’un service. Pour cela, lors de la phase d’initialisation décrite en relation avec la figure 3A, le fournisseur de service reçoit un code d’autorisation de prélèvement (alias et code secret provisoire) sur le compte agrégé lui permettant de vérifier le statut des comptes cautionnaires ou d’exécuter un paiement selon les conditions prévues.
Pour la réserve de trésorerie, l’entrepreneur utilise le compte de l’entreprise pour son activité et s’il dépasse le plafond disponible sur son propre compte, il a la possibilité d’utiliser la réserve d’argent mise à sa disposition par les cautionnaires (utilisateurs titulaires Pi). Le système répartit alors la demande d’utilisation de la réserve sur un ou plusieurs cautionnaires.
Si un cautionnaire refuse, la somme demandée est répartie sur les autres cautionnaires. Si un compte cautionnaire n’est pas suffisamment alimenté, la demande est rejetée pour ce compte et la somme demandée est répartie sur les autres cautionnaires. Si tous les cautionnaires acceptent, l’argent est transféré directement depuis les comptes des cautionnaires vers le compte du bénéficiaire. L’argent n’est pas directement versé sur le compte de l’entrepreneur.
On décrit ci-après les étapes mises en œuvre lors de ces deux cas d’usages.
Selon un premier exemple C1, le bénéficiaire B1 souhaite consulter le solde du compte agrégé. Pour cela, lors d’une étape E350, il transmet au serveur SERV via son terminal TB1 une demande de statut de caution en indiquant l’alias public et le code secret provisoire qui lui ont été communiqués. Lors d’une étape E351, le serveur SERV extrait à partir de l’alias et du code secret provisoire, les index de clés utilisés pour générer les codes confidentiels provisoires et les identifiants publics de chaque utilisateur titulaire Pi.
Puis, pour chaque utilisateur titulaire Pi, lors d’une étape E352i, le serveur SERV décode l’identifiant de l’utilisateur titulaire Pi et son code secret et lors d’une étape E353i, le serveur vérifie auprès d’un serveur SB du fournisseur de service de paiement le solde du compte de l’utilisateur titulaire Pi. Lors d’une étape E354i, le serveur SERV renvoie au terminal de l’utilisateur bénéficiaire B1 le statut de la caution pour chaque utilisateur titulaire Pi.
En variante, le serveur SERV agrège les statuts des cautions de tous les utilisateurs titulaires interrogés et fournit à l’utilisateur bénéficiaire B1, le statut global de la caution fournie par l’utilisateur délégataire D1, par exemple en vérifiant que la somme totale disponible sur tous les comptes des utilisateurs titulaires est supérieure ou égale au montant requis dans la demande initiale transmise lors de l’étape E350.
Selon un deuxième exemple C2, l’utilisateur délégataire D1 souhaite utiliser sa réserve de trésorerie pour réaliser un paiement au bénéfice de l’utilisateur bénéficiaire B1. Pour cela, lors d’une étape E360, l’utilisateur délégataire D1 transmet au serveur SERV via son terminal TD1 une demande de paiement en indiquant l’alias public et le code secret provisoire qui lui ont été communiqués, ainsi que le montant du paiement. Lors d’une étape E361, le serveur SERV extrait à partir de l’alias et du code secret provisoire, les index de clés utilisés pour générer les codes confidentiels provisoires et les identifiants publics de chaque utilisateur titulaire Pi.
Puis, pour chaque utilisateur titulaire Pi, lors d’une étape E362i, le serveur SERV décode l’identifiant de l’utilisateur titulaire Pi et son code secret et lors d’une étape E363i, le serveur vérifie que les conditions relatives à l’autorisation de délégation mises en place sont valides. Si c’est le cas, lors d’une étape E364i, le serveur SERV transmet au serveur SB un ordre d’exécution du paiement pour une partie du montant requis par l’utilisateur délégataire D1. Lors d’une étape E365i, le serveur SB déclenche l’exécution du paiement du compte de l’utilisateur titulaire Pi vers le compte du bénéficiaire B1.
Selon un troisième exemple C3, l’utilisateur bénéficiaire B1 souhaite appliquer la caution qui lui a été fournie et demander la réalisation du paiement de la caution. Pour cela, lors d’une étape E370, l’utilisateur bénéficiaire B1 transmet au serveur SERV via son terminal TB1 une demande de paiement en indiquant l’alias public et le code secret provisoire qui lui ont été communiqués, ainsi que le montant du paiement. Le serveur procède ensuite comme pour l’exemple C2 décrit ci-dessus.
Lors de l’étape E365i, le serveur SB déclenche l’exécution du paiement du compte de l’utilisateur titulaire Pi vers le compte du bénéficiaire B1.
La figure 4 illustre un exemple d’un dispositif de gestion SERV selon un mode particulier de réalisation de l’invention. Selon ce mode particulier de réalisation de l'invention, le dispositif de gestion SERV a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de gestion d’une autorisation qui décrit ci-dessus, lorsque le programme est exécuté par le processeur PROC.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de gestion d’une autorisation selon l'un quelconque de modes particuliers de réalisation décrits en relation avec les figures 2A, 2B, 3A, 3B selon les instructions du programme d'ordinateur PG.
Le dispositif de gestion SERV comprend également un module de communication COM permettant au dispositif de gestion d’établir des communications, via un réseau de communications, par exemple un réseau de données fixes ou mobiles.
Selon un mode particulier de réalisation de l’invention, le dispositif de gestion SERV est compris dans un serveur, par exemple un serveur d’un fournisseur de service de paiement.

Claims (10)

  1. Procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur, dit utilisateur titulaire, le procédé étant mis en œuvre par un processeur d’un dispositif de gestion, le procédé comprenant:
    - La réception, en provenance d’un terminal dudit utilisateur titulaire, d’une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
    - La génération de données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
    - La transmission vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur desdites données temporaires.
  2. Procédé de gestion selon la revendication 1, dans lequel la requête comprend en outre une indication d’un type d’autorisation d’accès et au moins un paramètre associé audit type d’autorisation d’accès.
  3. Procédé de gestion selon la revendication 1 ou 2, comprenant en outre, préalablement à la transmission desdites données temporaires:
    - L’envoi au terminal de l’utilisateur titulaire, d’une demande de confirmation de la requête d’initialisation,
    - La réception, en provenance du terminal de l’utilisateur titulaire, d’un message de confirmation comprenant un code confidentiel dudit utilisateur titulaire d’accès audit service de paiement.
  4. Procédé de gestion selon la revendication 3, dans lequel la génération des données temporaires comprend:
    - L’encodage dudit identifiant de l’utilisateur titulaire à l’aide d’une clé de chiffrement propre au dispositif de gestion pour former ledit identifiant public associé à l’utilisateur délégataire,
    - L’encodage dudit code confidentiel de l’utilisateur titulaire à l’aide de ladite clé de chiffrement pour former ledit code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire,
    - La mémorisation dudit identifiant public associé à l’utilisateur délégataire et d’un index de clé identifiant ladite clé de chiffrement.
  5. Procédé de gestion selon l’une quelconque des revendications 1 à 4, comprenant au préalable:
    - La réception, en provenance d’un terminal dudit utilisateur délégataire, d’une requête d’initialisation d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire, la requête comprenant l’identifiant dudit utilisateur délégataire, l’identifiant dudit utilisateur titulaire et un montant de transaction de paiement,
    - L’envoi au terminal de l’utilisateur titulaire, d’un message informant l’utilisateur titulaire de la requête d’initialisation d’une autorisation d’accès envoyée par le terminal de l’utilisateur délégataire, le message comprenant l’identifiant dudit utilisateur délégataire, et un montant de transaction de paiement.
  6. Procédé de gestion selon l’une quelconque des revendications 4 ou 5, dans lequel lorsque le dispositif de gestion reçoit au moins une autre requête d’initialisation d’au moins une autorisation d’accès, en provenance d’un terminal d’un autre utilisateur titulaire, et destinée à permettre audit utilisateur délégataire d’accéder audit service de paiement dudit autre utilisateur titulaire, ladite requête comprenant au moins l’identifiant dudit utilisateur délégataire et un identifiant dudit autre utilisateur titulaire, le procédé comprend en outre:
    - La mémorisation d’un compte agrégé comprenant, pour chaque utilisateur titulaire, l’identifiant public généré à partir de l’identifiant dudit utilisateur titulaire et associé audit utilisateur délégataire, l’index de clé utilisée pour générer le code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire à partir du code confidentiel de l’utilisateur titulaire.
  7. Procédé de gestion selon l’une quelconque des revendications 2 à 6, comprenant en outre:
    - La réception, en provenance d’un terminal d’un utilisateur bénéficiaire, d’une demande d’exécution de paiement comprenant l’identifiant public associé à l’utilisateur délégataire, le code confidentiel associé audit identifiant public et un montant de paiement,
    - le décodage de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire, à partir de l’index de clé mémorisé, de l’identifiant public associé à l’utilisateur délégataire, et du code confidentiel associé audit identifiant public associé à l’utilisateur délégataire,
    - la transmission d’un ordre d’exécution de paiement du montant à l’utilisateur bénéficiaire, via le service de paiement fourni à l’utilisateur titulaire à partir de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire décodés.
  8. Dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur titulaire, comprenant une mémoire et un processeur configurés pour:
    - recevoir, en provenance d’un terminal dudit utilisateur titulaire, une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
    - générer des données temporaires d’accès au compte associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
    - transmettre vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur lesdites données temporaires.
  9. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion d’autorisation d’accès selon l'une quelconque des revendications 1 à 7, lorsque le programme est exécuté par un processeur.
  10. Support d’enregistrement lisible par ordinateur comportant un programme d’ordinateur selon la revendication 9.
FR1914842A 2019-12-19 2019-12-19 Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur. Pending FR3105513A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1914842A FR3105513A1 (fr) 2019-12-19 2019-12-19 Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.
US17/786,492 US20230009823A1 (en) 2019-12-19 2020-11-26 Method and device for managing access authorization to a payment service provided to a user
PCT/FR2020/052177 WO2021123527A1 (fr) 2019-12-19 2020-11-26 Procede et dispositif de gestion d'une autorisation d'acces a un service de paiement fourni a un utilisateur
EP20821056.7A EP4078495A1 (fr) 2019-12-19 2020-11-26 Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1914842A FR3105513A1 (fr) 2019-12-19 2019-12-19 Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.
FR1914842 2019-12-19

Publications (1)

Publication Number Publication Date
FR3105513A1 true FR3105513A1 (fr) 2021-06-25

Family

ID=70613949

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1914842A Pending FR3105513A1 (fr) 2019-12-19 2019-12-19 Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.

Country Status (4)

Country Link
US (1) US20230009823A1 (fr)
EP (1) EP4078495A1 (fr)
FR (1) FR3105513A1 (fr)
WO (1) WO2021123527A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020174048A1 (en) * 2000-07-24 2002-11-21 Sanjeev Dheer Method and apparatus for delegating authority
EP2208336A1 (fr) * 2007-08-27 2010-07-21 NEC Europe Ltd. Procédé et système pour délégation de ressources
US9466051B1 (en) * 2013-02-06 2016-10-11 Amazon Technologies, Inc. Funding access in a distributed electronic environment

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040015702A1 (en) * 2002-03-01 2004-01-22 Dwayne Mercredi User login delegation
US8769642B1 (en) * 2011-05-31 2014-07-01 Amazon Technologies, Inc. Techniques for delegation of access privileges
US20120330784A1 (en) * 2011-06-22 2012-12-27 Broadcom Corporation Mobile Device for Transaction Payment Delegation
US10909518B2 (en) * 2013-03-07 2021-02-02 Paypal, Inc. Delegation payment with picture
US10510072B2 (en) * 2014-09-29 2019-12-17 The Toronto-Dominion Bank Systems and methods for administering mobile applications using pre-loaded tokens
US11257085B1 (en) * 2015-12-11 2022-02-22 Wells Fargo Bank, N.A Systems and methods for authentication device-assisted transactions
US11551200B1 (en) * 2019-09-18 2023-01-10 Wells Fargo Bank, N.A. Systems and methods for activating a transaction card

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020174048A1 (en) * 2000-07-24 2002-11-21 Sanjeev Dheer Method and apparatus for delegating authority
EP2208336A1 (fr) * 2007-08-27 2010-07-21 NEC Europe Ltd. Procédé et système pour délégation de ressources
US9466051B1 (en) * 2013-02-06 2016-10-11 Amazon Technologies, Inc. Funding access in a distributed electronic environment

Also Published As

Publication number Publication date
WO2021123527A1 (fr) 2021-06-24
EP4078495A1 (fr) 2022-10-26
US20230009823A1 (en) 2023-01-12

Similar Documents

Publication Publication Date Title
CN111316278B (zh) 安全身份和档案管理系统
EP2477165B1 (fr) Carte à puce à applications multiples, et système et procédé de gestion d'applications multiples de carte à puce
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
WO2017184160A1 (fr) Autorisation d'emploi de clés cryptographiques
JP2017027621A (ja) 安全に補充可能な電子ウォレット
US20120130900A1 (en) System and Method for Trading Unused Digital Rights
DK2582115T3 (en) Qualified electronic signature system, associated method and mobile phone to qualified, electronic signature
JP2008524751A (ja) 消費者インターネット認証サービス
US20100223188A1 (en) Online Payment System and Method
EP0616714B1 (fr) Systeme de traitement d'informations utilisant un ensemble de cartes a memoire
US20180152429A1 (en) Systems and methods for publicly verifiable authorization
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
US20170132618A1 (en) Mobile card service method utilizing hce, and mobile terminal applying same
WO2007125252A1 (fr) Procede et systeme de gestion d'un paiement electronique
FR3037754A1 (fr) Gestion securisee de jetons electroniques dans un telephone mobile
FR3105513A1 (fr) Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.
EP1299837A1 (fr) Procede de distribution commerciale en ligne de biens numeriques par l'intermediaire d'un reseau de communication et dispositif electronique d'achat de biens numeriques distribues par ce procede
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
US11954672B1 (en) Systems and methods for cryptocurrency pool management
FR2980890A1 (fr) Procede et systeme de paiement, application a la location automatisee de vehicules.
WO2022269179A1 (fr) Procede et dispositif de paiement par chaines de blocs
KR20240001416A (ko) 블록체인 기반의 nft를 이용한 음원 플랫폼의 서버에서 수행되는 서비스 제공 방법
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210625

RX Complete rejection

Effective date: 20220411