FR3044789A1 - Procede d'autorisation d'une transaction - Google Patents

Procede d'autorisation d'une transaction Download PDF

Info

Publication number
FR3044789A1
FR3044789A1 FR1562020A FR1562020A FR3044789A1 FR 3044789 A1 FR3044789 A1 FR 3044789A1 FR 1562020 A FR1562020 A FR 1562020A FR 1562020 A FR1562020 A FR 1562020A FR 3044789 A1 FR3044789 A1 FR 3044789A1
Authority
FR
France
Prior art keywords
transaction
terminal
control
user
data
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.)
Withdrawn
Application number
FR1562020A
Other languages
English (en)
Inventor
Ghislain Moncomble
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 FR1562020A priority Critical patent/FR3044789A1/fr
Publication of FR3044789A1 publication Critical patent/FR3044789A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224Transactions dependent on location of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Abstract

L'invention concerne un procédé d'autorisation d'une transaction entre un utilisateur et un tiers, la transaction étant initiée par l'utilisateur à partir d'un terminal utilisé pour la transaction et contrôlée par l'envoi d'une donnée de contrôle vers un terminal de contrôle associé à l'utilisateur, le procédé étant tel que des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur sont mémorisées au préalable et en ce qu'il comporte, à la réception d'une demande d'autorisation d'une transaction comportant un identifiant de l'utilisateur et une donnée de localisation du terminal utilisé pour la transaction, des étapes de localisation, à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés, d'au moins un terminal de contrôle situé à proximité du terminal utilisé pour la transaction; de sélection d'au moins un terminal parmi les terminaux de contrôle localisés ; d'envoi, vers le terminal de contrôle sélectionné, d'une donnée de contrôle comportant au moins une instruction de validation de la transaction ; et d'autorisation de la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle est correctement exécutée.

Description

PROCÉDÉ D’AUTORISATION D’UNE TRANSACTION Domaine technique
La présente invention se rapporte au domaine de la sécurisation des achats à distance et concerne plus particulièrement un procédé d’autorisation pour l’utilisation d’un moyen de paiement.
Art antérieur
Depuis plusieurs années, on observe un développement considérable des paiements en ligne pour l’achat de biens ou de services sur Internet. Ces transactions sont le plus souvent réalisées en saisissant un numéro de carte bancaire depuis un ordinateur personnel, une tablette ou un smartphone. Parallèlement, on constate une forte augmentation de la fraude, faisant de la sécurisation des paiements en ligne un enjeu particulièrement important. Par exemple, lorsqu’un utilisateur saisit ses références bancaires pour effectuer un achat en ligne, il court le risque que ses coordonnées bancaires soient interceptées par un tiers et utilisées frauduleusement pour effectuer des achats. Différentes solutions ont été proposées pour prévenir ces fraudes. En particulier, certaines techniques visent à vérifier que la personne qui réalise l’achat est bien le titulaire du moyen de paiement utilisé. Pour cela, des procédés tels que celui décrit dans le brevet européen EP 0745961 B1 proposent de prévenir un utilisateur lorsque ses coordonnées bancaires sont utilisées pour un paiement et lui donnent l’opportunité de s’y opposer. Une telle méthode consiste généralement à envoyer un message à l’utilisateur sur un autre terminal préalablement renseigné, comme par exemple sur un téléphone mobile de l’utilisateur. Le message indique la nature et le montant de la transaction. En ne répondant pas à ce message, l’utilisateur peut s’opposer à la transaction. De nombreux établissements bancaires offrent de tels services et proposent à leurs clients de renseigner un numéro de téléphone mobile ou une adresse de courrier électronique afin d’être notifiés lorsque leur carte de crédit est utilisée pour un paiement sur Internet. De cette façon, un fraudeur ne peut pas utiliser un numéro de carte volé car il ne peut pas répondre au message de validation.
Cette technique présente toutefois un inconvénient lorsqu’un utilisateur souhaite effectuer un achat en ligne alors qu’il n’a pas son terminal avec lui. Par exemple, lorsqu’un utilisateur a laissé son téléphone mobile à son domicile et souhaite effectuer un achat sur son lieu de travail, il ne peut pas recevoir le message d’autorisation. Dans de telles circonstances, il ne peut pas effectuer l’achat.
Il existe donc un besoin pour une solution offrant un niveau de sécurité satisfaisant qui ne présente pas les inconvénients de l’art antérieur. L’invention vient améliorer la situation. Résumé de l’invention A cet effet, l’invention concerne un procédé d'autorisation d'une transaction entre un utilisateur et un tiers, la transaction étant initiée par l'utilisateur à partir d'un terminal utilisé pour la transaction et contrôlée par l'envoi d'une donnée de contrôle vers un second terminal associé à l'utilisateur, dit terminal de contrôle.
Le procédé est remarquable en ce que des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur sont mémorisées au préalable et en ce qu'il comporte, à la réception d'une demande d'autorisation d'une transaction comportant une donnée de localisation du terminal utilisé pour la transaction, les étapes suivantes : - Localisation, à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés, d'au moins un terminal de contrôle situé à proximité du terminal utilisé pour la transaction, - Sélection d’au moins un terminal parmi les terminaux de contrôle localisés, - Envoi, vers le au moins un terminal de contrôle sélectionné, d'une donnée de contrôle comportant au moins une instruction de validation de la transaction, et - Autorisation de la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle est correctement exécutée.
Un utilisateur peut ainsi associer une pluralité de terminaux de contrôle à son compte bancaire. Par exemple, il peut associer le téléphone d’un conjoint, une tablette dont il dispose à domicile, un téléphone fixe sur son lieu de travail ou un ordinateur personnel. Lorsqu’une demande d’autorisation d’une transaction, comme par exemple une demande d’autorisation d’un paiement, est reçue, le procédé détermine parmi les terminaux associés, les terminaux qui sont à proximité du terminal utilisé pour réaliser le paiement, c'est-à-dire proche de l’utilisateur. Par exemple, si l’utilisateur effectue un paiement à partir d’un ordinateur personnel à son domicile, les terminaux déterminés pourront être le téléphone mobile de l’utilisateur, la tablette et le téléphone de son conjoint. Cette disposition permet de s’assurer qu’un message de validation ne sera pas envoyé sur le lieu de travail de l’utilisateur s’il effectue un achat depuis son domicile. Le procédé propose ensuite qu’un message comprenant une donnée de contrôle permettant de valider le paiement soit envoyée sur au moins un de ces terminaux. La donnée de contrôle peut ainsi être envoyée vers le téléphone mobile de l’utilisateur, sur la tablette ou encore sur le téléphone du conjoint. Différentes données de contrôle peuvent aussi être envoyées vers différents terminaux. Le procédé rend ainsi plus difficile l’interception d’une donnée de validation. Une donnée de contrôle comprend au moins une instruction permettant, lorsqu’elle est exécutée par l’utilisateur, de valider le paiement. Lorsque le procédé constate, en recevant par exemple un message de confirmation, que les instructions de validation ont été correctement exécutées, le paiement est autorisé.
Le procédé permet ainsi d’éviter que le message de validation soit envoyé sur un terminal qui n’est pas à proximité de l’utilisateur, de façon à ce que l’utilisateur puisse effectuer des achats lorsqu’il n’a pas son téléphone mobile avec lui.
Selon une réalisation particulière, une instruction de validation du paiement correspond à une ou plusieurs actions qu’un utilisateur doit effectuer pour valider le paiement. Une telle instruction peut par exemple consister pour l’utilisateur à envoyer un SMS vers un numéro de téléphone particulier à partir d’un terminal de contrôle distinct de celui sur lequel les instructions ont été reçues et distinct de celui utilisé pour réaliser le paiement.
Ainsi, la donnée permettant de valider le paiement n’est plus envoyée sur un unique terminal, elle est donc plus difficile à intercepter pour un fraudeur. Le procédé permet ainsi de renforcer la sécurité des paiements.
Selon une réalisation particulière, le procédé est tel que le au moins un terminal de contrôle sélectionné est choisi aléatoirement parmi le au moins un terminal localisé.
Le terminal sur lequel sont envoyées les instructions de validation de la transaction est choisi au hasard parmi les terminaux localisés. Ainsi, il n’est pas possible de déterminer à l’avance le ou les terminaux dont il faut disposer pour valider la transaction. Le procédé contribue ainsi à renforcer la sécurité de la transaction.
Selon un mode particulier de réalisation, le procédé est tel que l’autorisation de la transaction n’est accordée que lorsqu’au moins deux terminaux de contrôles distincts sont localisés à proximité du terminal utilisé pour la transaction.
De cette façon, dans le cas où un fraudeur s’empare par exemple d’un sac à main contenant un téléphone mobile et une carte de crédit, il ne pourra pas effectuer de paiement depuis son domicile car seul un terminal sera localisé à proximité du terminal sur lequel il effectue le paiement.
Selon un mode de réalisation particulier, le procédé est tel que des données de contrôle distinctes sont transmises vers les au moins deux terminaux de contrôle localisés.
Des instructions de validation distinctes sont émises à destination d’au moins deux terminaux localisés. Ainsi, les terminaux de contrôle ne reçoivent pas les mêmes instructions de validation et un fraudeur disposant uniquement d’un terminal et d’une carte de crédit ne pourra pas effectuer de paiement, car une partie des instructions aura été transmise sur un autre terminal auquel il n’a pas accès.
Selon une réalisation particulière, le procédé est tel que l’autorisation de la transaction n’est accordée que lorsqu’un nombre minimum de terminaux de contrôle distincts sont localisés à proximité du terminal utilisé pour la transaction, le nombre minimum de terminaux requis étant définit selon le montant de la transaction.
La sécurité offerte par le procédé est ainsi proportionnelle au montant de la transaction à autoriser. Plus le montant de la transaction est important, plus le nombre de terminaux nécessaires à proximité du terminal utilisé pour effectuer un achat est important.
Selon un mode particulier de réalisation, le procédé est tel que les données mémorisées relatives à un terminal de contrôle comprennent des capacités de communication disponibles sur ledit terminal de contrôle, la donnée de contrôle étant transmise selon au moins un mode de communication disponible.
Pour chacun des terminaux de contrôle associés à un utilisateur, des moyens de communications sont mémorisés. Le procédé peut ainsi mémoriser différentes applications de communication disponibles sur un téléphone mobile ou une tablette et envoyer les instructions de validation selon un de ces moyens de communication. Par exemple, les instructions de validation peuvent être envoyées via la messagerie d’une application d’un réseau social, par SMS, ou par tout autre service de communication disponible sur un terminal. Le fait que la donnée de validation puisse être transmise via différents services de communication rend plus difficile sont interception, car l’accès à ces services peut être protégé par un mot de passe. Cette disposition permet ainsi de renforcer la sécurité du paiement.
Selon un mode de réalisation particulier, le au moins un mode de communication utilisé pour transmettre la donnée de contrôle est déterminé aléatoirement.
Le mode de communication sur lequel sont envoyées les instructions de validation du paiement est choisi au hasard parmi les modes de communication disponibles sur le terminal. Ainsi, il n’est pas possible de déterminer à l’avance un moyen de communication dont il faut disposer pour valider le paiement. Le procédé contribue ainsi à renforcer la sécurité du paiement.
Selon un mode de réalisation particulier, le procédé est tel que au moins deux terminaux de contrôle distincts T1 et T2 sont choisis aléatoirement parmi les terminaux localisés, des données de contrôle comprenant des instructions de validation étant transmises vers l'un T1 de ces deux terminaux, et le second terminal T2 servant pour valider les instructions transmises à T1, les terminaux T1 et T2 étant distincts du terminal utilisé pour initier la transaction.
Les instructions de validations sont émises à destination d’un premier terminal T1 localisé. Ces instructions comprennent une indication selon laquelle des actions particulières décrites dans les instructions doivent être réalisées par l’utilisateur ou une personne autorisée par l’utilisateur sur le second terminal T2. Ainsi, un fraudeur disposant uniquement d’un terminal T1 et d’une carte de crédit ne pourra pas effectuer de paiement, car les instructions devront être saisies sur un autre terminal T2 désigné dans des instructions qu'il a reçu par le terminal T1. Le fraudeur n’a pas accès à cet autre terminal T2.
Selon un autre aspect, l’invention concerne un dispositif d'autorisation d'une transaction entre un utilisateur et un tiers, la transaction étant initiée par l'utilisateur à partir d'un terminal utilisé pour la transaction et contrôlée par l'envoi d'une donnée de contrôle vers un terminal de contrôle associé à l'utilisateur, le dispositif étant remarquable en ce qu’il comprend : - Une mémoire adaptée pour mémoriser de façon persistante des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur - Un module de communication adapté pour recevoir une demande d'autorisation d’une transaction comportant une donnée de localisation du terminal utilisé pour la transaction, - Un module de localisation, adapté pour localiser au moins un terminal de contrôle situé à proximité du terminal utilisé pour la transaction à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés à l’utilisateur, - Un processeur configuré pour sélectionner au moins terminal parmi les au moins un terminaux de contrôle localisés, - Le module de communication étant en outre adapté pour envoyer, vers le terminal sélectionné, une donnée de contrôle comportant au moins une instruction de validation de la transaction, et - Un module d’autorisation configuré pour autoriser la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle sélectionné est correctement exécutée. L’invention se rapporte encore à un serveur comportant un dispositif d’autorisation tel que décrit ci-dessus.
Le dispositif et le serveur présentent des avantages analogues à ceux du procédé précédemment présenté.
Dans un mode particulier de réalisation, les différentes étapes du procédé selon l’invention sont déterminées par des instructions de programmes d’ordinateurs.
En conséquence, l’invention vise aussi un programme d’ordinateur comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé tel que décrit ci-dessus, lorsque le programme est exécuté par un processeur.
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 support d'enregistrement lisible par un processeur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, une mémoire flash, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d'informations peut être 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. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être 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é en question.
Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé d’autorisation.
Liste des figures D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation préférés décrits en référence aux figures parmi lesquelles :
La figure 1 illustre une architecture adaptée pour la mise en œuvre de l’invention selon un mode de réalisation particulier,
La figure 2 illustre les principales étapes du procédé d’autorisation selon un mode de réalisation particulier de l’invention, et La figure 3 illustre l’architecture d’un dispositif adapté pour mettre en œuvre l’invention selon un mode particulier de réalisation.
Description détaillée
La figure 1 illustre une architecture adaptée pour la mise en œuvre de l’invention selon un mode de réalisation particulier. La figure représente le domicile 100 d’un utilisateur équipé d’un ordinateur personnel 101, par exemple un ordinateur de type PC, d’un téléphone 103 et d’une tablette 102. Les ordinateurs 101, téléphone 103 et tablette 102 sont connectés au réseau Internet 109 par l’intermédiaire d’une connexion Wifi, Ethernet ou encore par l’intermédiaire d’un réseau de données cellulaires.
La figure 1 illustre également le lieu de travail 104 de l’utilisateur. Sur son lieu de travail, l’utilisateur dispose également d’un ordinateur personnel 105 connecté au réseau Internet 109 par l’intermédiaire d’un réseau d’entreprise, et d’un téléphone professionnel 106 également connecté au réseau Internet 109 par l’intermédiaire d’une connexion de données cellulaires. L’utilisateur dispose en outre d’un téléphone mobile personnel 110 qu’il emporte avec lui à son domicile ou à son lieu de travail. Il s’agit par exemple d’un smartphone doté d’une connexion de données cellulaires lui permettant d’accéder au réseau Internet 109.
La figure 1 montre également un serveur 107 adapté pour mettre en œuvre le procédé d’autorisation selon un mode particulier de réalisation de l’invention, ainsi qu’un serveur 108 hébergeant un site Internet marchand sur lequel l’utilisateur peut effectuer des achats depuis l’un quelconque des terminaux décrits précédemment.
Le serveur 107 est un ordinateur comprenant une unité de traitement dotée d’un processeur, une mémoire comme par exemple une mémoire RAM et une interface de communication lui permettant d’échanger des données avec d’autres serveurs et des terminaux connectés au réseau Internet, et en particulier avec le site marchand 108 et les terminaux 101, 102, 103, 105,106 et 110 précités. Le serveur 107 comprend également une mémoire persistante, comme par exemple une base de données 111 indexée et configurée pour stocker des données en relation avec un identifiant d’utilisateur et pour permettre la récupération de données stockées à partir du même identifiant. Il s’agit par exemple d’une base de données relationnelle classique, ou d’un autre moyen de stockage adapté, comme un système de fichiers.
Cette architecture permet à l’utilisateur d’effectuer des achats sur le site marchand 108 depuis l’un des terminaux, par exemple depuis l’ordinateur 101 ou l’ordinateur 105. L’exemple décrit ci-après concerne un paiement d’un particulier vers un site marchand, mais l’invention peut également s’appliquer à toute sorte de transaction, comme par exemple des transactions entre particuliers ou entre marchands. L’invention est décrite en relation avec un paiement lors d’un achat mais peut s’appliquer pour l’accès à tout service pour lequel un accès frauduleux serait préjudiciable à l’utilisateur et ou au marchand, comme par exemple l’accès à un service de messagerie ou à un système d’information d’une entreprise.
Les principales étapes du procédé d’autorisation vont maintenant être décrites en référence à la figure 2.
Lors d’une première étape 200, des données relatives aux terminaux 101, 102, 103, 105, 106 et 110 sont mémorisées dans la base de données 111 du serveur 107. Il s’agit de terminaux de contrôle sélectionnés par l’utilisateur. Pour chaque terminal, ces données comprennent un identifiant du terminal, comme par exemple un numéro de carte SIM, une adresse MAC ou n’importe quel autre identifiant adapté pour identifier de manière unique un terminal. Ces données peuvent comprendre également des capacités de communication disponibles sur le terminal, comme par exemple des comptes et identifiants permettant de contacter l’utilisateur par des moyens de communication disponibles sur le terminal, comme des applications de courrier électronique, de réseaux sociaux, de messagerie instantanée, ou encore de communication vocale. De telles informations peuvent concerner non seulement des terminaux de l’utilisateur, mais aussi des terminaux de personnes proches avec lesquelles il est susceptibles de coopérer lors des transactions d’achats, comme par exemple des terminaux de collègues de travail ou de membres de la famille de l’utilisateur. Les informations mémorisées comportent en outre une donnée représentative de la localisation des différents terminaux. Selon un mode de réalisation particulier, la localisation des terminaux est mémorisée en relation avec des plages horaires de présence de ces terminaux sur certains lieux. Par exemple, l’utilisateur peut déclarer la présence du terminal mobile 110 à son domicile 100 le week-end et entre 18h et 9h durant la semaine, et la présence de ce même terminal sur son lieu de travail 104 le reste du temps. Le serveur peut ainsi déterminer la localisation probable des différents terminaux selon l’heure à laquelle la demande de d’autorisation de paiement est effectuée. Selon une réalisation particulière, le serveur peut émettre une requête à destination des terminaux pour obtenir une information de localisation précise, obtenue à partir par exemple de modules GPS (Global Positionning System) intégrés aux terminaux ou par identification de points d’accès Wifi. Le serveur dispose ainsi des moyens pour localiser l’ensemble des terminaux d’un utilisateur, et de manière avantageuse, selon l’heure à laquelle une transaction est initiée.
Les informations mémorisées par le serveur 107 peuvent comprendre aussi des renseignements associés à l’utilisateur ou à des personnes proches susceptibles de coopérer pour valider la transaction. Il peut s’agir de l’âge, du sexe, d’une empreinte vocale adaptée pour identifier la voix de l’utilisateur ou d’un proche dans un flux audio, d’une donnée caractéristique d’une empreinte digitale ou encore un ensemble de photographies à partir desquelles des caractéristiques morphologiques du visage de l’utilisateur ou d’un proche peuvent être établies. Ces informations donnent les moyens au serveur d’identifier le titulaire du moyen de paiement utilisé pour la transaction ou, selon les informations renseignées, une personne qui lui est proche.
Les données ainsi collectées sont mémorisées dans la base de données 111 du serveur 107.
Cette étape est réalisée de préférence au préalable à la transaction, par exemple au travers d’une interface dédiée du serveur 107 accessible depuis le réseau Internet ou lors d’un rendez-vous dans une agence bancaire.
Lorsque l’utilisateur effectue un achat sur le site marchand 108 à partir de l’ordinateur 101 de son domicile, le serveur 107 reçoit, à l’étape 201, une demande d'autorisation pour la transaction. La demande comporte un identifiant de l'utilisateur et une donnée de localisation du terminal utilisé pour le paiement. Cette demande provient par exemple du site marchand hébergé par le serveur 108 sur lequel l’utilisateur effectue un achat. La demande d’autorisation peut également provenir d’un serveur de transactions bancaires ou de n’importe quel autre serveur habilité pour valider une utilisation de données confidentielles. À la réception de la demande, le terminal 101 utilisé par l’utilisateur pour initier le paiement est identifié à partir par exemple de son adresse IP (Internet Protocol), d’un numéro MSISDN (Mobile Station International Subscriber Directory Number) associé au terminal mobile ou à la carte SIM, d’un numéro IMEI (International Mobile Equipment Identity) ou encore d’une adresse MAC (Medium Access Layer). Cette information peut être déterminée de manière implicite à partir des informations de routage du message au travers du réseau de communication ou être renseignée par le terminal dans un champ du message de demande prévu à cet effet.
Selon une réalisation particulière, la demande comporte un identifiant de l’utilisateur permettant d’exécuter une requête dans la base de données du serveur 107 et extraire les données associées à l’utilisateur. L’identifiant est par exemple un code client ou un identifiant bancaire renseigné de manière explicite par l’utilisateur. Il peut également s’agir d’un identifiant renseigné par l’opérateur réseau, ce dernier disposant généralement d’une table permettant d’associer un accès internet à un compte utilisateur. La demande peut également comporter une donnée de localisation du terminal, comme par exemple des coordonnées GPS, une adresse ou un identifiant de lieu. Cette donnée permet notamment d’identifier les terminaux de contrôle proches du lieu depuis lequel l’utilisateur effectue l’achat, en fonction des informations relatives aux terminaux de contrôle mémorisées à l’étape 200.
Lors d’une étape 202, le serveur 107 détermine un ensemble de terminaux dont la localisation est proche du terminal utilisé par l’utilisateur pour effectuer le paiement. Pour cela, un module de localisation du serveur 107 exécute un programme d’ordinateur grâce à une unité de traitement, le programme d’ordinateur étant configuré pour extraire de la demande d’autorisation une donnée de localisation du terminal utilisé par l’utilisateur pour effectuer la transaction. Puis, dans un second temps, le module de localisation du serveur 107 exécute une requête dans la base de données 111 pour extraire les terminaux de contrôle associés à l’utilisateur. Il peut s’agir par exemple d’une requête SQL (Structured Query Language) adaptée pour sélectionner dans la base de données 111 les enregistrements relatifs aux terminaux de contrôle de l’utilisateur. Le module de localisation du serveur 107 peut alors comparer la donnée de localisation du terminal utilisé pour effectuer la transaction avec les données de localisation associées aux terminaux de contrôle de l’utilisateur de façon à déterminer un sous-ensemble de terminaux dont la localisation est proche de celle du terminal utilisé pour effectuer la transaction.
Par exemple, lorsque l’utilisateur effectue un achat le samedi depuis son domicile à l’aide de l’ordinateur 101, le serveur 107 peut déterminer un sous ensemble de terminaux de contrôle comportant les terminaux 103, 102 et 110 car ils sont géographiquement proches du terminal 101. Selon un autre exemple, si l’utilisateur effectue un achat à midi en semaine depuis son poste de travail 105, le serveur peut sélectionner les terminaux 110 et 106. Ainsi, selon le terminal utilisé pour effectuer l’achat et l’horaire à laquelle l’achat est effectué, l’ensemble de terminaux de contrôle déterminé par le serveur sera différent.
Selon une réalisation particulière, la transaction n’est autorisée que lorsqu’au moins deux terminaux de contrôle sont localisés à proximité du terminal utilisé pour initier la transaction. Cette disposition permet d’éviter qu’un individu qui s’emparerait du téléphone mobile et de la carte bancaire d’une personne puisse utiliser ce moyen de paiement pour effectuer des achats. Pour mettre en œuvre une telle disposition, le serveur peut transmettre un message vers l’utilisateur lui indiquant que son identité n’est pas suffisamment établie pour autoriser l’achat. Dans une telle situation, le serveur refuse l’autorisation sans exécuter les étapes suivantes. Selon un mode particulier de réalisation, un nombre minimum de terminaux de contrôle localisés à proximité est nécessaire pour autoriser un achat, ce nombre dépendant par exemple du montant de la transaction. Par exemple, lorsque le montant de la transaction dépasse un certain seuil, le nombre de terminaux devant être à proximité du terminal sur lequel est effectué l’achat doit être de 3 ou plus. À l’étape 203, le serveur 107 sélectionne un sous ensemble de terminaux de contrôle parmi les terminaux localisés à l’étape 202. Le serveur peut effectuer cette sélection selon différents critères. Selon un premier mode de réalisation, la sélection est réalisée aléatoirement. Le serveur peut ainsi sélectionner un nombre prédéfini de terminaux de façon aléatoire parmi les terminaux localisés à l’étape précédente. Selon un autre mode de réalisation particulier, le nombre de terminaux sélectionné est également défini de manière aléatoire. La sélection peut également être réalisée de manière à ce qu’elle soit toujours composée de terminaux différents d’un achat sur l’autre. Selon une réalisation particulière, l’utilisateur peut s’opposer à la sélection d’un terminal de contrôle particulier. Par exemple, lorsque l’achat est effectué depuis son domicile 100, l’utilisateur peut exclure la tablette 102. La tablette ne sera alors pas comprise dans l’ensemble de terminaux de contrôle déterminé par le serveur. Un telle disposition permet à l’utilisateur de garder confidentiels certains achats en évitant qu’une demande d’autorisation soit envoyée sur un terminal partagé par la famille par exemple. L’étape 204 concerne l’envoi d’une donnée de contrôle comportant au moins une instruction de validation du paiement vers au moins un terminal sélectionné à l’issu de l’étape 203. Le serveur 107 utilise les données mémorisées à l’étape 200 pour générer une ou plusieurs données de contrôle. Une donnée de contrôle comprend une ou plusieurs instructions qui doivent être exécutées par l’utilisateur pour valider la transaction. De telles instructions comprennent l’identification d’un ou plusieurs terminaux sur lesquels doivent être effectuées une ou plusieurs actions pour valider le paiement. Selon une réalisation particulière, les instructions comprennent en outre l’identification d’un moyen de communication devant être utilisé pour effectuer l’action. Par exemple, lorsqu’un utilisateur effectue un paiement en ligne depuis son domicile 100 à partir de l’ordinateur 101, une donnée de contrôle est envoyée sur la tablette 102. Cette donnée est envoyée selon l’un des moyens de communication disponibles sur le terminal, la disponibilité ayant été mémorisée par le serveur 107 à l’étape 200. Cette donnée comprend par exemple des instructions détaillant des actions à réaliser sur le terminal103 pour valider le paiement. Les actions à réaliser peuvent être par exemple et de façon non exhaustive :
Passer un appel téléphonique depuis le terminal 103 vers un numéro de téléphone fourni dans les instructions,
Passer un appel téléphonique depuis le terminal 103 vers un numéro de téléphone fournit dans les instructions et composer ou prononcer un code fourni dans les instructions, une date de naissance ou tout autre information mémorisée à l’étape 200,
Envoyer un message particulier au travers d’une application de messagerie instantanée d’un réseau social disponible sur le terminal 103, Présenter une empreinte digitale de l’utilisateur, d’un proche ou d’un collègue sur un capteur d’empreinte digitales du terminal 103, Établir une communication vidéo vers un numéro particulier à partir d’une application de communication audiovisuelle disponible sur le terminal 103, afin que le visage de l’utilisateur ou celui d’un proche, selon les instructions de contrôle envoyées à l’étape 204, puisse être identifié par comparaison avec des photos mémorisées à l’étape 200, ou encore par exemple
Saisir sur le terminal utilisé pour le paiement un code dont différentes parties ont été transmises séparément vers différents terminaux de contrôle sélectionnés.
Le but étant de vérifier l’identité de l’utilisateur en comparant une information qu’il fournit avec des données personnelles ou d’usage mémorisées à l’étape 200.
En variante, de telles instructions peuvent être envoyées vers plusieurs terminaux et concerner des actions à réaliser en combinaison sur plusieurs terminaux.
Enfin, lors d’une étape 205, le serveur autorise la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle est correctement exécutée. Pour cela, le serveur est informé de l’exécution des instructions envoyées. Par exemple, le serveur constate que les instructions ont été exécutées par la réception d’un message en provenance d’un terminal sur lequel doit être réalisée une action, le message contenant une indication selon laquelle l’action a été correctement exécutée. Selon les instructions envoyées, le message de confirmation peut provenir d’un serveur en charge de vérifier la réalisation des instructions. Par exemple, lorsque l’instruction indique qu’un appel doit être passé vers un numéro de téléphone particulier, un serveur vocal peut envoyer un message vers le serveur 107 pour confirmer la bonne exécution de l’instruction. Selon un autre exemple, lorsqu’une instruction de validation consiste à émettre un message instantané vers un contact particulier, le serveur de messagerie instantanée peut émettre un message de confirmation vers le serveur 107. La confirmation peut également être obtenue par le serveur 107 lui-même lorsqu’il s’agit par exemple de renseigner un code dont différentes parties ont été communiquées dans des instructions envoyées sur des terminaux distincts. L’étape 205 peut ainsi être mise en œuvre par un module de contrôle d’autorisation du serveur 107. Un tel module peut comporter une unité de traitement dotée d’un processeur et d’une mémoire, la mémoire comprenant un programme d’ordinateur configuré pour analyser des messages reçus par une interface réseau du serveur, lorsque le programme est exécuté par le processeur. Un tel programme peut comporter des instructions pour analyser un message reçu, en extraire une indication selon laquelle une action a été réalisée sur un terminal, comparer cette indication avec les instructions de contrôle envoyées à l’utilisateur, et décider en cas d’incohérence entre l’indication reçue et les instructions envoyées, ou bien en cas de non réponse d’une telle indication, que la transaction doit être annulée. A l’inverse, lorsque l’indication obtenue concorde avec les instructions de validation envoyées, la transaction peut être autorisée.
La figure 3 illustre, selon un mode particulier de réalisation de l’invention, un dispositif 300 mettant en œuvre le procédé d’autorisation.
Le dispositif comprend un espace de stockage 301, par exemple une mémoire MEM, une unité de traitement 302 équipée par exemple d’un processeur PROC. L’unité de traitement peut être pilotée par un programme 303, par exemple un programme d’ordinateur PGR, mettant en œuvre le procédé d’autorisation tel que décrit dans l’invention en référence aux figures 1 et 2, et notamment les étapes de mémorisation des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur, de réception d'une demande d'autorisation d'une transaction comportant un identifiant de l'utilisateur et une donnée de localisation du terminal utilisé pour le paiement, de localisation, à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés, d'au moins un terminal de contrôle situé à proximité du terminal utilisé pour le paiement, de sélection d’au moins un terminal parmi les terminaux de contrôle localisés, d’envoi vers le terminal de contrôle sélectionné, d'une donnée de contrôle comportant au moins une instruction de validation du paiement, et d’autorisation du paiement lorsque la au moins une instruction de validation envoyée au terminal de contrôle est correctement exécutée. À l’initialisation, les instructions du programme d’ordinateur 303 sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) avant d’être exécutées par le processeur de l’unité de traitement 302. Le processeur de l’unité de traitement 302 met en œuvre les étapes du procédé d’autorisation selon les instructions du programme d’ordinateur 303.
Pour cela, le dispositif comprend, outre la mémoire 301, des moyens de communication 305, comme par exemple une interface réseau COM, permettant au dispositif de se connecter à un réseau de télécommunication et d’échanger des données avec d’autres dispositifs, et en particulier de recevoir une demande d'autorisation d'une transaction comportant un identifiant de l'utilisateur et une donnée de localisation du terminal utilisé pour le paiement, et d’envoyer vers le terminal de contrôle sélectionné, une donnée de contrôle comportant au moins une instruction de validation du paiement. Une telle interface réseau peut être par exemple une interface de type Ethernet ou Wifi, ou tout autre type d’interface, comme par exemple une liaison haut débit de type fibre optique ou ADSL.
Le dispositif comprend une mémoire 306, comme par exemple une base de données DB permettant de mémoriser des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur.
Le dispositif comprend aussi un module de localisation 304 adapté pour localiser au moins un terminal de contrôle situé à proximité du terminal utilisé pour le paiement à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés à l’identifiant de l’utilisateur. Le module de localisation 304 peut être mis en œuvre par des instructions mémorisées dans la mémoire 301 et exécutées par le processeur 302. De telles instructions permettent, lorsqu’elles sont exécutées par le processeur 302, de déterminer des distances entre les terminaux et en particulier de déterminer un ensemble de terminaux proches d’un terminal particulier.
Le dispositif comporte enfin un module d’autorisation configuré pour autoriser le paiement lorsque la au moins une instruction de validation envoyée au terminal de contrôle sélectionné est correctement exécutée. Le module d’autorisation 307 peut être mis en œuvre par des instructions mémorisées dans la mémoire 301 et exécutées par le processeur 302. De telles instructions permettent, lorsqu’elles sont exécutées par le processeur 302, de contrôler la bonne exécution des instructions de validation transmises au terminal, en analysant par exemple le contenu d’un ou plusieurs messages de réponse émis par le terminal et reçu par le dispositif. Le module d’autorisation peut alors effectuer une comparaison entre les données résultant de l’exécution des instructions et un résultat attendu pour déterminer si les instructions ont été exécutées de manière correcte et autoriser le paiement.

Claims (11)

  1. REVENDICATIONS
    1. Procédé d'autorisation d'une transaction entre un utilisateur et un tiers, la transaction étant initiée par l'utilisateur à partir d'un terminal utilisé pour la transaction et contrôlée par l'envoi d'une donnée de contrôle vers un second terminal associé à l'utilisateur, dit terminal de contrôle, le procédé étant caractérisé en ce que des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur sont mémorisées (200) au préalable et en ce qu'il comporte, à la réception (201) d'une demande d'autorisation d'une transaction comportant un identifiant de l'utilisateur et une donnée de localisation du terminal utilisé pour la transaction, les étapes suivantes : - Localisation (202), à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés, d'au moins un terminal de contrôle situé à proximité du terminal utilisé pour la transaction, - Sélection (203) d’au moins un terminal parmi les terminaux de contrôle localisés, - Envoi (204), vers le au moins un terminal de contrôle sélectionné, d'une donnée de contrôle comportant au moins une instruction de validation de la transaction, et - Autorisation (205) de la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle est correctement exécutée.
  2. 2. Procédé selon la revendication 1 caractérisé en ce que le au moins un terminal de contrôle sélectionné est choisi aléatoirement parmi le au moins un terminal localisé.
  3. 3. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l’autorisation de la transaction n’est accordée que lorsqu’au moins deux terminaux de contrôles distincts sont localisés à proximité du terminal utilisé pour la transaction.
  4. 4. Procédé selon la revendication 3 caractérisé en ce que des données de contrôle distinctes sont transmises vers les au moins deux terminaux de contrôle localisés.
  5. 5. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l’autorisation de la transaction n’est accordée que lorsqu’un nombre minimum de terminaux de contrôles distincts sont localisés à proximité du terminal utilisé pour la transaction, le nombre minimum étant défini selon le montant de la transaction.
  6. 6. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que les données mémorisées relatives à un terminal de contrôle comprennent des capacités de communication disponibles sur ledit terminal de contrôle, la donnée de contrôle étant transmise selon au moins un mode de communication disponible.
  7. 7. Procédé selon la revendication 6 caractérisé en ce que le au moins un mode de communication utilisé pour transmettre la donnée de contrôle est déterminé aléatoirement.
  8. 8. Dispositif d'autorisation d'une transaction entre un utilisateur et un tiers, la transaction étant initiée par l'utilisateur à partir d'un terminal utilisé pour la transaction et contrôlée par l'envoi d'une donnée de contrôle vers un terminal de contrôle associé à l'utilisateur, le dispositif étant caractérisé en ce qu’il comprend : - Une mémoire (306) adaptée pour mémoriser des données relatives à au moins deux terminaux de contrôle associés à l'utilisateur - Un module de communication (305) adapté pour recevoir une demande d'autorisation d’une transaction comportant une donnée de localisation du terminal utilisé pour la transaction, - Un module de localisation (304) , adapté pour localiser au moins un terminal de contrôle situé à proximité du terminal utilisé pour la transaction à partir de la donnée de localisation et des données relatives aux terminaux de contrôles associés à l’utilisateur, - Un processeur (302) configuré pour sélectionner au moins terminal parmi les au moins un terminaux de contrôle localisés, - Le module de communication (305) étant en outre adapté pour envoyer, vers le terminal sélectionné, une donnée de contrôle comportant au moins une instruction de validation de la transaction, et - Un module d’autorisation (307) configuré pour autoriser la transaction lorsque la au moins une instruction de validation envoyée au terminal de contrôle sélectionné est correctement exécutée.
  9. 9. Serveur caractérisé en ce qu’il comporte un dispositif d’autorisation selon la revendication 8.
  10. 10. Programme d'ordinateur caractérisé en ce qu’il comporte les instructions pour l'exécution du procédé d d’autorisation selon l'une quelconque des revendications 1 à 7.
  11. 11.Support d'informations lisible par un processeur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d’autorisation selon l'une quelconque des revendications 1 à 7.
FR1562020A 2015-12-08 2015-12-08 Procede d'autorisation d'une transaction Withdrawn FR3044789A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1562020A FR3044789A1 (fr) 2015-12-08 2015-12-08 Procede d'autorisation d'une transaction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1562020A FR3044789A1 (fr) 2015-12-08 2015-12-08 Procede d'autorisation d'une transaction

Publications (1)

Publication Number Publication Date
FR3044789A1 true FR3044789A1 (fr) 2017-06-09

Family

ID=55862879

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1562020A Withdrawn FR3044789A1 (fr) 2015-12-08 2015-12-08 Procede d'autorisation d'une transaction

Country Status (1)

Country Link
FR (1) FR3044789A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020128203A1 (fr) 2018-12-21 2020-06-25 Orange Procédé et système de sécurisation d'opérations, et poste utilisateur associé

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130332358A1 (en) * 2012-06-12 2013-12-12 Ebay, Inc. Fraud detection system
EP2916520A1 (fr) * 2014-03-07 2015-09-09 AOL, Inc. Système et procédé pour authentification basée sur un emplacement

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130332358A1 (en) * 2012-06-12 2013-12-12 Ebay, Inc. Fraud detection system
EP2916520A1 (fr) * 2014-03-07 2015-09-09 AOL, Inc. Système et procédé pour authentification basée sur un emplacement

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020128203A1 (fr) 2018-12-21 2020-06-25 Orange Procédé et système de sécurisation d'opérations, et poste utilisateur associé
FR3090934A1 (fr) 2018-12-21 2020-06-26 Orange Procédé et système de sécurisation d’opérations, et poste utilisateur associé

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
EP3113099A1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
US11416859B2 (en) Methods of authenticating a user for data exchange
FR2973618A1 (fr) Authentification forte par presentation du numero
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR3043819A1 (fr) Procede d'aide a l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
FR3110984A1 (fr) Partage sécurisé d'informations de justificatif d'identité
FR3052283A1 (fr) Procede de fourniture de donnees relatives a une transaction de paiement, dispositif et programme correspondant
FR3044789A1 (fr) Procede d'autorisation d'une transaction
FR3047622B1 (fr) Procede de controle d'un parametre indicatif d'un niveau de confiance associe a un compte utilisateur d'un service en ligne
WO2021064323A1 (fr) Terminal, dispositif de personnalisation de requetes de services et procedes permettant un service personnalise
EP3394812A1 (fr) Procédé d'authentification
FR3052895A1 (fr) Procede d'envoi d'une information de securite
FR3093225A1 (fr) Procédé de gestion d’accès d’un utilisateur à un service vocal, dispositif, système et programmes correspondants
EP2897095B1 (fr) Procédé de sécurisation d'une transaction réalisée par carte bancaire
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
FR3023640A1 (fr) Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
FR3007870A1 (fr) Verification de la validite d'une transaction par localisation d'un terminal.
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
EP3146745B1 (fr) Authentification ubiquitaire
FR3029318A1 (fr) Procede et dispositif pour securiser les operations bancaires electroniques
FR3121764A1 (fr) Méthode de contrôle d’accès à un bien ou service distribué par un réseau de communication de données
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3060172A1 (fr) Procede de transaction relative a un vehicule .

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20170609

ST Notification of lapse

Effective date: 20170831