EP3014542A1 - Verification de la validite d'une transaction par localisation d'un terminal - Google Patents

Verification de la validite d'une transaction par localisation d'un terminal

Info

Publication number
EP3014542A1
EP3014542A1 EP14742264.6A EP14742264A EP3014542A1 EP 3014542 A1 EP3014542 A1 EP 3014542A1 EP 14742264 A EP14742264 A EP 14742264A EP 3014542 A1 EP3014542 A1 EP 3014542A1
Authority
EP
European Patent Office
Prior art keywords
terminal
transaction
current location
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.)
Ceased
Application number
EP14742264.6A
Other languages
German (de)
English (en)
Inventor
Olivier MASSIERE
Matthieu Verdier
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
Publication of EP3014542A1 publication Critical patent/EP3014542A1/fr
Ceased 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • 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/405—Establishing or using transaction specific rules

Definitions

  • the present invention relates to verification of the validity of a transaction. It may be for example a bank transaction during a payment by credit card, a payment terminal requesting authorization of the transaction from a server entity that verifies the validity of this transaction.
  • the authentic holder of the credit card may not have his mobile terminal at the time of the transaction, which generates a false alert leading to a negative verification of the validity of the transaction.
  • the present invention improves the situation.
  • a requested transaction request at a current location for a user of a mobile terminal, the request comprising a data function of an identifier of the terminal, depending on the identifier of the terminal, consulting a database storing data of previous locations of the terminal,
  • server entity means one or more server devices operatively connected to one another, typically via a network, but capable of being arranged in different locations.
  • the present invention provides to rely on a history of previous locations of the mobile terminal, to check consistency with the location of the current transaction. Therefore, the transaction is not necessarily rejected if the authentic user (for example of a bank card) does not have his mobile terminal on him. In addition, if both the bank card and the mobile terminal have been stolen by the same person, taking into account a history of previous locations makes it possible to check compatibility between the current location of the transaction (possibly by a user). malicious) and previous locations (for example, usual locations of the authentic user of the map). In case of non-correspondence, typically, it may be determined that the holder of the bank card for the current transaction is not located at a location already listed for the mobile terminal, which may lead to a rejection of the request. transaction.
  • the transaction request can be issued from a second terminal (for example a payment terminal reading a bank card, or a personal computer of the cardholder issuing a payment order, or others).
  • the transaction request includes a datum of the current location, corresponding to a geographical position of the second terminal. This provision can be implemented at the second terminal (for example the aforementioned payment terminal), advantageously, to insert in the transaction request the current location of the current transaction.
  • the server entity obtains a current geolocation data from the mobile terminal. For this purpose, it can be expected to generate an event via the cellular network (call, or SMS message notification) to create a current location data.
  • the server may, for example, request the operator of the cellular network used by the mobile terminal to generate an event (incoming telephone call on the mobile terminal, or notification of an SMS message) creating a location data item, which enables the mobile terminal to server entity to obtain the data of the current location.
  • the server entity can send a notification to the terminal to receive, in response, the current geolocation data.
  • the aforementioned notification invites the user of the terminal to enter an identification code personal, this code, once received from the terminal, being checked with the server entity.
  • the database may store a plurality of previous location data sets of a respective plurality of terminals, and, with the server entity connected to said database, the server entity transmits to the database. the identifier of the mobile terminal and in return obtains the data set of previous locations of this mobile terminal.
  • the terminal can store in memory the aforementioned database, and, from the identifier of the terminal, the server entity contacts the terminal for the consistency check between the current location and previous locations of the terminal.
  • the terminal can itself compare the current location transmitted by the server entity to a previous location history already stored in the terminal, and transmit the result of this comparison to the server entity to decide to a verified consistency or not of this current location.
  • the consistency is checked if the current location corresponds to at least one of said previous locations of the mobile terminal.
  • the data of previous locations comprise one or more means of previous locations.
  • each average can be estimated on a group of locations spaced geographically from a difference below a predetermined threshold.
  • the coherence can be verified if the current location is around one of the aforementioned means, in a radius corresponding for example to the predetermined threshold.
  • the previous location data can be obtained from location information given at the initiative of the user, for example to a social network server (for example checkins on Facebook® or other social networks). Such an embodiment ensures confidentiality at the location of the user's terminal, these locations are not obtained without his knowledge.
  • the previous location data stored in the database can be stored at the initiative of the user, by means of a notification sent by the server entity, for example by a message of the type SMS on the mobile terminal, after a validated transaction and asking the user if he accepts that this location is stored for subsequent transactions. These locations stored at the initiative of the user are stored as usual (without special risk), which then determines the level of risk associated with a future transaction.
  • the action in response to the transaction request may, by way of example, include one of at least one rejection of the transaction, a favorable sequence to give to the transaction (it being understood that other subsequent controls such as that of the bank card itself or the user's bank account), or the issuing of a notification inviting the user to give personal information (for example to enter a personal code on its mobile terminal or to enter a code received on its mobile terminal in an SMS message on the payment terminal (process known as "3DSecure"), or to enter a biometric fingerprint, or to present a piece of identification, or other).
  • a favorable sequence to give to the transaction it being understood that other subsequent controls such as that of the bank card itself or the user's bank account
  • the issuing of a notification inviting the user to give personal information for example to enter a personal code on its mobile terminal or to enter a code received on its mobile terminal in an SMS message on the payment terminal (process known as "3DSecure"), or to enter a biometric fingerprint, or to present a piece of identification, or other).
  • the present invention also aims at such an application in the form of a computer program, comprising instructions for implementing the method described above. before, when this program is executed by a processor, for example a processor that includes the aforementioned server entity.
  • the invention further aims at the server entity for verifying the validity of a transaction, comprising:
  • a communication interface for receiving a requested transaction request at a current location for a user of a mobile terminal, the request comprising a data function of an identifier of the terminal,
  • a verification module cooperating with the communication interface for:
  • the abovementioned verification module may comprise software elements (typically the computer program in the sense of the invention) and hardware elements such as for example a processor with which a working memory is associated, as will be seen later with reference to FIG. FIG. 3 schematically representing, by way of example, a server entity within the meaning of the invention.
  • FIG. 1 illustrates a system including in particular an ES server entity for the implementation of the invention
  • - Figure 2 illustrates the main steps of the method in the sense of the present invention, in an exemplary embodiment
  • Figure 3 schematically illustrates elements of the invention.
  • a server entity in the sense of the present invention in an exemplary embodiment
  • Figure 4 illustrates a location position processing, in a particular embodiment.
  • a payment terminal TER2 (the "second terminal” above), able to read a bank card CB and thus require a transaction, a transaction request message then being transmitted via a network RES to an ES server entity, for verification of the validity of the transaction.
  • the server entity ES refers to a database DB of previous locations of a mobile terminal TER of the US user who is the authorized holder of the bank card CB.
  • the server entity only refers to a history of previous locations, without any need for the presence of the TER terminal at the time of the transaction.
  • the server entity ES interprets that the current holder of the bank card CB is positioned at a location that does not correspond to the habits of its authentic holder, which can be concluded by a rejection of the transaction, or by an additional verification requested to the holder of the credit card.
  • the authentic user of the bank card is usually located by his mobile terminal in the Paris region, while the location of the current transaction is located on Marseille (without any occurrence in the history of previous locations do not mentioned Marseilles as previous location), it can be interpreted that the credit card is located in Marseille, which can generate from the ES server entity an additional verification routine (for example by asking the user to enter a code particular personal identification on his mobile terminal, or others).
  • FIG. 2 shows the main steps of such a method, which begins at step S1 by a request REQ that the payment terminal TER2 issues and typically includes a current location LOC of this terminal TER2.
  • the request further includes an identifier of its authentic user ID-US.
  • This request REQ is sent to the server entity ES which thus finds, from the identifier of the user, an identifier ID-TER of its mobile terminal TER, in step S2.
  • the process may continue with any additional verification, such as for example the entry of an additional personal identifier. in step S7.
  • the server entity ES refers to the database DB, at step S3 to obtain the history of the previous locations of the TER terminal.
  • the database DB previous locations can be stored in a memory that can access the ES server entity, as shown in Figure 1. In this regard, this memory can be directly integrated with the server entity.
  • the server entity ES itself, can be in the form of one or more server devices connected to each other and each typically having a processor and a working memory, as well as a communication interface, for receiving queries, process them and send an answer.
  • the database DB is stored in a memory that includes one of these server devices.
  • the database of the previous locations DB can be stored in a memory of the terminal itself, as explained later in one embodiment.
  • the server entity determines whether the current location LOC is compatible with the previous locations.
  • the current localization LOC can be included in the request REQ, as indicated previously with reference to the step S1.
  • the current location can be determined by a simple interrogation of the terminal TER, at the same time. step S5.
  • the location of the terminal can be obtained spontaneously by a triangulation technique on several base stations.
  • the location of the terminal can usually be obtained in a simple manner and can be exploited directly when the terminal is directly requested by the network RES, for example by sending a notification by SMS short messages, or by telephone call. (at step S5 of Figure 2). It can be taken advantage of the notification of an SMS message for the user to enter a personal code on his mobile terminal, to overcome the case for example where the bank card was stolen at the same time as the mobile terminal of the user .
  • the technique for transmitting notification to the mobile terminal can be considered intrusive if it is to build the history of the previous locations, and it may be preferable to obtain successive information of TER terminal location, by simple choice its user (information given by the user on a social network for example, or after acceptance of the given user to the server entity to store a current location data after validation of a transaction).
  • the history of the previous locations can be generated (for example over a chosen period of one year or six months) and then stored in the database DB.
  • the database DB can be stored at a memory of the server entity ES, as explained above, or be stored at the mobile terminal itself, if typically it is desired to maintain confidentiality on the movements of the user of the mobile terminal.
  • the comparison between the current location of the transaction and the history of the previous locations can be performed with the mobile terminal, itself, while the compatibility check decision, which follows this comparison, can be taken from the server entity ES that receives from the mobile terminal positive or negative information on the aforementioned comparison.
  • the entity server may decide to perform in step S7 additional security before validating the transaction (for example asking the user to enter an additional personal code on the payment terminal TER2, or to request the user to enter a personal code specific to banking transactions on his mobile terminal TER).
  • FIG. 3 shows an exemplary structure of an ES server entity.
  • This typically comprises a communication interface INT, able to cooperate with a processor PROC with which is associated a working memory MEM.
  • the server entity can cooperate directly with a mass storage memory hosting the database of the histories of the previous locations of one or more mobile terminals, this memory being addressable from an ID-TER mobile terminal identifier for retrieving the history of the previous locations of this mobile terminal.
  • this DB database is stored at the mobile terminal directly, this addressing feature according to an identifier becomes unnecessary.
  • the comparison between the current location LOC and one of the preceding locations can lead to a positive consistency check between the location of the current transaction and the history of the previous locations.
  • this information does not mean that the place of the current transaction should be invalidated.
  • a user living in the Paris region can move and be in a neighborhood of the Paris region in which it has never been previously located.
  • FIG. 4 shows such an embodiment in which an average point A is established between several previous locations A1, A2, A3, A4 and which are not separated by more than a predetermined threshold SP.
  • a second average represented by the point B of FIG. 4 can be identified, grouping several previous locations B 1, B 2, B 3 which are not separated by more than the aforementioned predetermined threshold SP.
  • a time criterion may correspond to positions having been occupied over the same relatively short observation period (for example 15 days or one month).
  • transaction encompasses any type of transaction, including authentication during an access control, for example a website or any computer application.
  • an embodiment has been described above in which it is carried out simple average of the various previous locations of the mobile terminal.
  • sophisticated models can be provided, for example with a weighted average estimate as a function of the time elapsed since a location time stamp.

Landscapes

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

Abstract

La présente invention concerne une vérification de la validité d'une transaction, comportant les étapes, mises en œuvre auprès d'une entité serveur (ES): - recevoir une requête de transaction sollicitée en un lieu courant pour un utilisateur (US) d'un terminal mobile (TER), la requête comportant une donnée fonction d'un identifiant du terminal, en fonction de l'identifiant du terminal, consulter une base de données (DB) stockant des données de localisations précédentes du terminal, vérifier une cohérence entre le lieu courant et lesdites localisations précédentes du terminal, et déterminer une action en réponse à la requête de transaction, en fonction de la vérification de cohérence.

Description

Vérification de la validité d'une transaction par localisation d'un terminal
La présente invention concerne la vérification de la validité d'une transaction. II peut s'agir par exemple d'une transaction bancaire lors d'un paiement par carte bancaire, un terminal de paiement sollicitant l'autorisation de la transaction auprès d'une entité serveur qui vérifie la validité de cette transaction.
Il peut être avantageux, dans un contexte où le porteur de la carte bancaire est aussi utilisateur d'un terminal mobile, de vérifier si le terminal mobile est bien localisé au même lieu de la transaction par carte bancaire en cours. Il est en effet connu du document WO2004070492 une réalisation dans laquelle un indice de confiance accrue est accordé à une transaction si l'initiateur de la transaction est bien localisé, grâce à son terminal mobile, dans le lieu de la transaction en cours. Toutefois, dans un contexte où le porteur de la carte n'en serait pas l'authentique utilisateur habilité, il est fréquent que la carte ait été dérobée à cet utilisateur habilité, tout comme le terminal mobile de l'utilisateur habilité ait été dérobé de la même manière, par la même personne.
Ainsi, quand bien même la localisation du terminal mobile est repérée en même temps que la transaction par carte bancaire dans le document WO2004070492, il n'est donné dans ce document aucun moyen de se prémunir contre l'éventualité d'un vol à la fois de la carte bancaire et du terminal mobile.
Par ailleurs, le titulaire authentique de la carte bancaire peut ne pas disposer de son terminal mobile au moment de la transaction, ce qui génère une fausse alerte menant à une vérification négative de la validité de la transaction.
La présente invention vient améliorer la situation.
Elle propose à cet effet un procédé de vérification de la validité d'une transaction, comportant les étapes, mises en œuvre auprès d'une entité serveur :
recevoir une requête de transaction sollicitée en un lieu courant pour un utilisateur d'un terminal mobile, la requête comportant une donnée fonction d'un identifiant du terminal, en fonction de l'identifiant du terminal, consulter une base de données stockant des données de localisations précédentes du terminal,
- obtenir une donnée du lieu courant et vérifier une cohérence entre le lieu courant et lesdites localisations précédentes du terminal, et déterminer une action en réponse à la requête de transaction, en fonction de la vérification de cohérence.
On entend ici par « entité serveur » un ou plusieurs dispositifs serveurs connectés opérationnellement entre eux, typiquement via un réseau, mais susceptibles d'être disposés dans des lieux différents.
Ainsi, la présente invention prévoit de se fonder sur un historique des localisations précédentes du terminal mobile, pour vérifier une cohérence avec le lieu de la transaction en cours. Par conséquent, la transaction n'est pas nécessairement rejetée si l'utilisateur authentique (par exemple d'une carte bancaire) ne dispose pas de son terminal mobile sur lui. En outre, si à la fois la carte bancaire et le terminal mobile ont été dérobés par une même personne, la prise en compte d'un historique de localisations précédentes permet de vérifier une compatibilité entre le lieu courant de la transaction (possiblement par un utilisateur malveillant) et des localisations antérieures (par exemple des localisations habituelles de l'utilisateur authentique de la carte). En cas de non-correspondance, typiquement, il peut être déterminé que le porteur de la carte bancaire pour la transaction en cours n'est pas situé à une localisation déjà répertoriée pour le terminal mobile, ce qui peut mener à un rejet de la requête de transaction. Dans une forme de réalisation, la requête de transaction peut être émise depuis un second terminal (par exemple un terminal de paiement lisant une carte bancaire, ou encore un ordinateur personnel du porteur de la carte émettant un ordre de paiement, ou autres). Avantageusement, dans cette forme de réalisation, la requête de transaction comporte une donnée du lieu courant, correspondant à une position géographique du second terminal. Cette disposition peut être mise en œuvre au niveau du second terminal (par exemple le terminal de paiement précité), de façon avantageuse, pour insérer dans la requête de transaction le lieu courant de la transaction en cours.
Dans une variante de cette forme de réalisation, pour déterminer le lieu courant en vue de ladite vérification de cohérence, l'entité serveur obtient une donnée de géolocalisation courante du terminal mobile. A cet effet, il peut être prévu de générer un événement via le réseau cellulaire (appel, ou notification de message SMS) pour créer une donnée de localisation courante. Le serveur peut par exemple solliciter l'opérateur du réseau cellulaire qu'utilise le terminal mobile pour générer un événement (appel téléphonique entrant sur le terminal mobile, ou notification d'un message SMS) créant une donnée de localisation, ce qui permet à l'entité serveur d'obtenir la donnée du lieu courant. Ainsi, dans cette variante, l'entité serveur peut émettre une notification à destination du terminal pour recevoir, en réponse, la donnée de géolocalisation courante.
Dans cette variante, pour s'assurer en outre que l'utilisateur du terminal mobile correspond bien au porteur de la carte bancaire par exemple, il peut être avantageux de prévoir la notification précitée invite l'utilisateur du terminal à saisir un code d'identification personnel, ce code, une fois reçu du terminal, étant vérifié auprès de l'entité serveur.
Dans une réalisation particulière, la base de données peut stocker une pluralité de jeux de données de localisations précédentes d'une pluralité respective de terminaux, et, l'entité serveur étant connectée à ladite base de données, l'entité serveur transmet à la base l'identifiant du terminal mobile et obtient en retour le jeu de données de localisations précédentes de ce terminal mobile. Une telle réalisation est avantageuse pour offrir un service de vérification de validité de transactions pour une pluralité d'utilisateurs de terminaux mobiles.
Toutefois, dans une variante de cette réalisation particulière, le terminal peut stocker en mémoire la base de données précitée, et, à partir de l'identifiant du terminal, l'entité serveur contacte le terminal pour la vérification de cohérence entre le lieu courant et les localisations précédentes du terminal. Dans un exemple de réalisation, le terminal peut comparer lui-même la localisation courante que lui transmet l'entité serveur à un historique de localisations précédentes stocké déjà dans le terminal, et transmettre le résultat de cette comparaison à l'entité serveur pour décider d'une cohérence vérifiée ou non de cette localisation courante.
Dans une forme de réalisation possible, la cohérence est vérifiée si le lieu courant correspond à l'une au moins desdites localisations précédentes du terminal mobile.
Dans une variante à cette forme de réalisation possible, les données de localisations précédentes comportent une ou plusieurs moyennes de localisations précédentes. En particulier, chaque moyenne peut être estimée sur un groupe de localisations espacées géographiquement d'un écart inférieur à un seuil prédéterminé.
Ainsi, la cohérence peut être vérifiée si le lieu courant se situe autour de l'une des moyennes précitées, dans un rayon correspondant par exemple au seuil prédéterminé.
Dans une forme de réalisation avantageuse, les données de localisations précédentes peuvent être obtenues à partir d'informations de localisation données à l'initiative de l'utilisateur, par exemple à un serveur de réseau social (par exemple les checkins sur Facebook® ou d'autres réseaux sociaux). Une telle réalisation permet d'assurer une confidentialité au niveau des localisations du terminal de l'utilisateur, ces localisations n'étant pas obtenues à son insu. Dans un autre exemple de réalisation, les données de localisations précédentes stockées dans la base peuvent être mémorisées à l'initiative de l'utilisateur, à l'aide d'une notification émise par l'entité serveur, par exemple par un message de type SMS sur le terminal mobile, après une transaction validée et demandant à l'utilisateur s'il accepte que cette localisation soit mémorisée pour des transactions ultérieures. Ces localisations mémorisées à l'initiative de l'utilisateur sont stockées comme étant habituelles (sans risque particulier), ce qui permet de déterminer ensuite le niveau de risque associé à une transaction future.
Par ailleurs, l'action en réponse à la requête de transaction peut, à titre d'exemple, comporter un élément parmi au moins un rejet de la transaction, une suite favorable à donner à la transaction (étant entendu que d'autres contrôles ultérieurs sont possibles comme par exemple celui de la carte bancaire elle-même ou du compte bancaire de l'utilisateur), ou encore l'émission d'une notification invitant l'utilisateur à donner une information personnelle (par exemple pour saisir un code personnel sur son terminal mobile ou pour saisir un code reçu sur son terminal mobile dans un message SMS sur le terminal de paiement (procédé dit « 3DSecure » ), ou pour saisir une empreinte biométrique, ou pour présenter une pièce d'identité, ou autres).
Les vérifications étant mises en œuvre par l'entité serveur au moyen d'une application informatique de vérification, la présente invention vise aussi une telle application sous la forme d'un programme informatique, comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur, par exemple un processeur que comporte l'entité serveur précitée.
À ce titre, l'invention vise en outre l'entité serveur de vérification de la validité d'une transaction, comportant :
- une interface de communication pour recevoir une requête de transaction sollicitée en un lieu courant pour un utilisateur d'un terminal mobile, la requête comportant une donnée fonction d'un identifiant du terminal,
un module de vérification coopérant avec l'interface de communication pour :
• consulter, en fonction de l'identifiant du terminal, une base de données stockant des données de localisations précédentes du terminal, et obtenir une donnée du lieu courant pour vérifier une cohérence entre le lieu courant et lesdites localisations précédentes du terminal, et • déterminer une action en réponse à la requête de transaction, en fonction de la vérification de cohérence.
Le module de vérification précité peut comporter des éléments software (typiquement le programme informatique au sens de l'invention) et des éléments hardware tels que par exemple un processeur auquel est associée une mémoire de travail, comme on le verra plus loin en référence à la figure 3 représentant schématiquement et à titre d'exemple une entité serveur au sens de l'invention.
En outre, l'algorithme général du programme informatique au sens de l'invention peut être illustré par l'organigramme de la figure 2, commentée ci-après. D'ailleurs, d'autres avantages et caractéristiques de la présente invention apparaîtront à la lecture de la description détaillée ci-après, donnée à titre d'exemple non limitatif, et à l'examen des dessins annexés et sur lesquels : la figure 1 illustre un système comportant notamment une entité serveur ES pour la mise en œuvre de l'invention, - la figure 2 illustre les principales étapes du procédé au sens de la présente invention, dans un exemple de réalisation, la figure 3 illustre schématiquement des éléments d'une entité serveur au sens de la présente invention, dans un exemple de réalisation, et la figure 4 illustre un traitement de positions de localisations, dans un exemple de réalisation particulier.
On se réfère tout d'abord à la figure 1 sur laquelle on a représenté un terminal de paiement TER2 (le « second terminal» précité), capable de lire une carte bancaire CB et de requérir ainsi une transaction, un message de requête de transaction étant alors émis via un réseau RES à destination d'une entité serveur ES, pour vérification de la validité de la transaction. Au sens de l'invention, l'entité serveur ES se réfère à une base de données DB de localisations antérieures d'un terminal mobile TER de l'utilisateur US qui est titulaire habilité de la carte bancaire CB. Ainsi, même si le terminal mobile TER n'accompagne pas l'utilisateur US, l'entité serveur ne se réfère qu'à un historique de localisations précédentes, sans aucune nécessité de la présence du terminal TER au moment de la transaction. Par ailleurs, il est vérifié en particulier une compatibilité entre, d'une part, un historique des localisations précédentes du terminal mobile TER (et donc de son utilisateur US), et, d'autre part, un lieu de la transaction en cours avec le terminal de paiement TER2. Ainsi, s'il est constaté une incompatibilité entre le lieu de la transaction courante et l'historique des localisations précédentes (par exemple si le lieu de la transaction courante ne correspond à aucune des localisations antérieures), l'entité serveur ES interprète que le porteur actuel de la carte bancaire CB est positionné en un lieu qui ne correspond pas aux habitudes de son titulaire authentique, ce qui peut se conclure par un rejet de la transaction, ou encore par une vérification supplémentaire demandée au porteur de la carte bancaire. Par exemple, si l'utilisateur authentique de la carte bancaire est localisé habituellement par son terminal mobile en région parisienne, alors que le lieu de la transaction en cours est repéré sur Marseille (sans qu'aucune occurrence dans l'historique des localisations précédentes ne mentionne Marseille comme localisation précédente), il peut être interprété que la carte bancaire se situe indûment à Marseille, ce qui peut générer auprès de l'entité serveur ES une routine de vérification supplémentaire (par exemple en demandant à l'utilisateur de saisir un code d'identification personnelle particulier sur son terminal mobile, ou autres).
On a représenté sur la figure 2 les principales étapes d'un tel procédé, lequel commence à l'étape SI par une requête REQ qu'émet le terminal de paiement TER2 et comportant typiquement une localisation courante LOC de ce terminal TER2. Par lecture de la carte bancaire CB, la requête comporte en outre un identifiant de son utilisateur authentique ID-US. Cette requête REQ est envoyée à l'entité serveur ES qui retrouve ainsi, à partir de l'identifiant de l'utilisateur, un identifiant ID-TER de son terminal mobile TER, à l'étape S2.
Si l'utilisateur de la carte bancaire n'est pas titulaire d'un terminal mobile (flèche KO en sortie du test S2), le procédé peut se poursuivre par une vérification supplémentaire quelconque, comme par exemple la saisie d'un identifiant personnel supplémentaire à l'étape S7. En revanche, si le terminal TER est identifié par l'entité serveur ES à l'étape S2 (flèche OK en sortie du test), l'entité serveur ES se réfère à la base de données DB, à l'étape S3 pour obtenir l'historique des localisations précédentes du terminal TER. La base de données DB des localisations précédentes peut être stockée auprès d'une mémoire à laquelle peut accéder l'entité serveur ES, comme représenté sur la figure 1. À cet égard, cette mémoire peut être directement intégrée auprès de l'entité serveur. L'entité serveur ES, elle-même, peut se présenter sous la forme d'un ou plusieurs dispositifs serveurs connectés entre eux et comportant chacun, typiquement, un processeur et une mémoire de travail, ainsi qu'une interface de communication, pour recevoir les requêtes, les traiter et envoyer une réponse. Ainsi, dans une forme de réalisation possible, la base de données DB est stockée dans une mémoire que comporte l'un de ces dispositifs serveurs.
Toutefois, dans une variante possible, la base de données des localisations précédentes DB peut être stockée dans une mémoire du terminal lui-même, comme exposé ultérieurement dans un mode de réalisation. À l'étape S4, l'entité serveur détermine si la localisation courante LOC est compatible avec les localisations précédentes. La localisation courante LOC peut être comprise dans la requête REQ, comme indiqué précédemment en référence à l'étape SI. Néanmoins, dans une variante possible où la transaction peut être requise depuis un autre terminal qu'un terminal de paiement, par exemple un ordinateur du titulaire de la carte bancaire, la localisation courante peut être déterminée par une simple interrogation du terminal TER, à l'étape S5.
Il convient de noter ici que la localisation du terminal peut être obtenue spontanément par une technique de triangulation sur plusieurs stations de base. Toutefois, la localisation du terminal peut être obtenue habituellement de façon simple et peut être exploitée directement lorsque le terminal est directement sollicité par le réseau RES, par exemple par l'émission d'une notification par messages courts dits SMS, ou encore par appel téléphonique (à l'étape S5 de la figure 2). Il peut être profité de la notification d'un message SMS pour que l'utilisateur renseigne un code personnel sur son terminal mobile, pour surmonter le cas par exemple où la carte bancaire a été dérobée en même temps que le terminal mobile de l'utilisateur. Néanmoins, la technique visant à émettre notification au terminal mobile peut être jugée intrusive s'il s'agit de constituer l'historique des localisations précédentes, et il peut être préférable d'obtenir des informations successives de localisation du terminal TER, par simple choix de son utilisateur (information donnée par l'utilisateur sur un réseau social par exemple, ou après acceptation de l'utilisateur donnée à l'entité serveur de stocker une donnée de localisation courante après validation d'une transaction). C'est ainsi que l'historique des localisations précédentes peut être généré (par exemple sur une durée choisie d'un an ou de six mois) et stocké ensuite dans la base de données DB.
La base de données DB peut être stockée auprès d'une mémoire de l'entité serveur ES, comme expliqué précédemment, ou encore être stockée auprès du terminal mobile lui-même, si typiquement il est souhaité conserver une confidentialité sur les déplacements de l'utilisateur du terminal mobile. Dans ce cas, la comparaison entre la localisation courante de la transaction et l'historique des localisations précédentes peut s'effectuer auprès du terminal mobile, lui-même, tandis que la décision de vérification de compatibilité, qui fait suite à cette comparaison, peut être prise auprès de l'entité serveur ES qui reçoit du terminal mobile une information positive ou négative sur la comparaison précitée.
Selon l'un quelconque des modes de réalisation précédents, en cas de vérification de cohérence négative entre la localisation courante et les localisations antérieures de la base de données DB à l'étape S4 (flèche KO en sortie du test S4), l'entité serveur peut décider d'effectuer à l'étape S7 une sécurité supplémentaire avant de valider la transaction (par exemple demander à l'utilisateur de saisir un code personnel supplémentaire sur le terminal de paiement TER2, ou encore de demander à l'utilisateur de saisir un code personnel propre aux transactions bancaires sur son terminal mobile TER).
En revanche, si la localisation courante est cohérente avec l'historique des localisations précédentes (flèche OK en sortie du test S4), la localisation courante est alors validée pour la transaction à l'étape S6. Toutefois, à l'étape S8, d'autres vérifications habituellement mises en œuvre sont aussi implémentées ici (par exemple la validité de la carte bancaire elle-même, ou encore l'approvisionnement d'un compte bancaire correspondant, etc.). À l'issue de ces vérifications, si bien entendu elles sont toutes positives, il peut être donné une suite favorable à la transaction à l'étape S9. On a représenté sur la figure 3 un exemple de structure d'une entité serveur ES. Celle-ci comporte typiquement une interface de communication INT, apte à coopérer avec un processeur PROC auquel est associée une mémoire de travail MEM. Dans cet exemple de réalisation représentée sur la figure 3, l'entité serveur peut coopérer directement avec une mémoire de stockage de masse hébergeant la base de données des historiques des localisations précédentes d'un ou plusieurs terminaux mobiles, cette mémoire étant adressable à partir d'un identifiant de terminal mobile ID- TER pour récupérer l'historique des localisations précédentes de ce terminal mobile.
Bien entendu, dans la réalisation où cette base de données DB est stockée auprès du terminal mobile directement, cette caractéristique d'adressage en fonction d'un identifiant devient inutile.
Bien entendu, la comparaison entre la localisation courante LOC et l'une des localisations précédentes, si elle est positive, peut mener à une vérification positive de cohérence entre la localisation de la transaction en cours et l'historique des localisations précédentes. Toutefois, si la localisation de la transaction en cours ne correspond à aucune des localisations précédentes, cette information ne signifie pas pour autant que le lieu de la transaction en cours devrait être invalidé. En effet, comme indiqué précédemment, un utilisateur vivant en région parisienne peut se déplacer et se situer dans un quartier de la région parisienne dans lequel il n'a jamais été localisé précédemment. Dans ce cas, il est préférable d'allouer un seuil correspondant à un rayon autour d'une localisation précédente, où préférablement autour d'une moyenne de plusieurs localisations précédentes, pour déterminer si manifestement la localisation de la transaction en cours se situe dans une région connue de l'historique des localisations précédentes, ou si cette localisation courante est manifestement étrangère à cet historique. On a représenté sur la figure 4 une telle réalisation dans laquelle il est établi un point moyen A entre plusieurs localisations précédentes Al, A2, A3, A4 et qui ne sont pas écartées de plus d'un seuil prédéterminé SP. De la même manière, il peut être identifié une deuxième moyenne représentée par le point B de la figure 4, regroupant plusieurs localisations précédentes B l, B2, B3 qui ne sont pas écartées de plus que le seuil prédéterminé précité SP. Par ailleurs, en cas de difficulté à constituer des groupes pour lesquels l'écart entre les positions n'est pas supérieur à ce seuil SP, il est possible d'ajouter un critère temporel pour constituer ces groupes. Par exemple, ces groupes peuvent correspondre à des positions ayant été occupées sur une même période d'observation relativement courte (par exemple 15 jours ou un mois). Une fois les groupes constitués et les points moyens A, B obtenus, il peut être décidé comme critère de vérification de cohérence que si une localisation de transaction en cours LOC1 se situe dans un rayon correspondant au seuil prédéterminé SP autour de l'une de ces moyennes A, alors la localisation de la transaction en cours peut être validée. En revanche, si une localisation de transaction courante LOC2 ne se situe dans un rayon SP d'aucune des moyennes A, ou B, alors la localisation de la transaction en cours n'est pas validée (correspondant à la flèche KO en sortie du test S4 de la figure 2).
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes.
Ainsi, on a décrit ci-avant l'exemple d'une transaction utilisant une carte bancaire CB. Toutefois, la présente invention s'applique de manière générale à toute transaction faisant intervenir la présence d'un utilisateur de terminal mobile au lieu de cette transaction et au moment de la vérification de cette transaction. Plus généralement, le terme « transaction » englobe tout type de transaction, notamment une authentification lors d'un contrôle d'accès, par exemple à un site Internet ou à une application informatique quelconque. Par ailleurs, on a décrit ci-avant un exemple de réalisation dans lequel il est effectué moyenne simple des différentes localisations précédentes du terminal mobile. Bien entendu, il peut être prévu des modèles sophistiqués, avec par exemple une estimation de moyenne pondérée en fonction du temps écoulé depuis une horodate de localisation.

Claims

REVENDICATIONS
Procédé de vérification de la validité d'une transaction, comportant les étapes, mises en œuvre auprès d'une entité serveur :
recevoir une requête de transaction sollicitée en un lieu courant pour un utilisateur d'un terminal mobile, la requête comportant une donnée fonction d'un identifiant du terminal, en fonction de l'identifiant du terminal, consulter une base de données stockant des données de localisations précédentes du terminal,
obtenir une donnée du lieu courant et vérifier une cohérence entre le lieu courant et lesdites localisations précédentes du terminal, et
déterminer une action en réponse à la requête de transaction, en fonction de la vérification de cohérence,
procédé dans lequel les données de localisations précédentes stockées dans la base sont mémorisées à l'initiative de l'utilisateur, à l'aide d'une notification émise par l'entité serveur après une transaction validée et demandant à l'utilisateur d'accepter une mémorisation d'une localisation courante pour des transactions ultérieures.
Procédé selon la revendication 1 , dans lequel la requête de transaction est émise depuis un second terminal et comporte une donnée dudit lieu courant, correspondant à une position géographique du second terminal.
Procédé selon la revendication 1, dans lequel, pour déterminer le lieu courant en vue de ladite vérification de cohérence, l'entité serveur obtient une donnée de géolocalisation courante du terminal mobile.
Procédé selon la revendication 3, dans lequel l'entité serveur émet une notification à destination du terminal pour recevoir, en réponse, la donnée de géolocalisation courante.
Procédé selon la revendication 4, dans lequel ladite notification invite l'utilisateur du terminal à saisir un code d'identification personnel, ledit code reçu du terminal étant vérifié auprès de l'entité serveur.
6. Procédé selon l'une des revendications précédentes, dans lequel la base de données stocke une pluralité de jeux de données de localisations précédentes d'une pluralité respective de terminaux, et, l'entité serveur étant connectée à ladite base de données, l'entité serveur transmet à la base l'identifiant du terminal mobile et obtient en retour le jeu de données de localisations précédentes de ce terminal mobile.
Procédé selon l'une des revendications 1 à 5, dans lequel le terminal stocke en mémoire ladite base de données, et, à partir de l'identifiant du terminal, l'entité serveur contacte le terminal pour la vérification de cohérence entre le lieu courant et les localisations précédentes du terminal.
Procédé selon l'une des revendications précédentes, dans lequel la cohérence est vérifiée si le lieu courant correspond à l'une au moins desdites localisations précédentes du terminal mobile.
Procédé selon la revendication 8, dans lequel lesdites données de localisations précédentes comportent une ou plusieurs moyennes de localisations précédentes.
Procédé selon la revendication 9, dans lequel chaque moyenne est estimée sur un groupe de localisations espacées géographiquement d'un écart inférieur à un seuil prédéterminé.
11. Procédé selon la revendication 10, dans lequel la cohérence est vérifiée si le lieu courant se situe autour de l'une desdites moyennes, dans un rayon correspondant audit seuil prédéterminé.
12. Procédé selon l'une des revendications précédentes, dans lequel l'action en réponse à la requête de transaction comporte un élément parmi au moins un rejet de la transaction, une suite favorable à donner à la transaction, l'émission d'une notification invitant l'utilisateur à donner une information personnelle.
13. Programme informatique, comportant des instructions pour la mise en œuvre du procédé selon l'une des revendications 1 à 12, lorsque ce programme est exécuté par un processeur.
14. Entité serveur de vérification de la validité d'une transaction, comportant :
une interface de communication pour recevoir une requête de transaction sollicitée en un lieu courant pour un utilisateur d'un terminal mobile, la requête comportant une donnée fonction d'un identifiant du terminal,
un module de vérification coopérant avec l'interface de communication pour : • consulter, en fonction de l'identifiant du terminal, une base de données stockant des données de localisations précédentes du terminal, et obtenir une donnée du lieu courant pour vérifier une cohérence entre le lieu courant et lesdites localisations précédentes du terminal, et
• déterminer une action en réponse à la requête de transaction, en fonction de la vérification de cohérence,
les données de localisations précédentes stockées dans la base étant mémorisées à l'initiative de l'utilisateur, à l'aide d'une notification émise par l'entité serveur après une transaction validée et demandant à l'utilisateur d'accepter une mémorisation d'une localisation courante pour des transactions ultérieures.
15. Terminal mobile de vérification de la validité d'une transaction mise en œuvre auprès d'une entité serveur, la transaction correspondant à une requête de transaction sollicitée en un lieu courant pour un utilisateur dudit terminal mobile, la requête comportant une donnée fonction d'un identifiant du terminal, la requête étant fonction d'une cohérence entre une donnée du lieu courant et des données de localisations précédentes du terminal stockées dans une base de données, le terminal comprenant :
une interface de communication pour recevoir une notification émise par l'entité serveur après une transaction validée, la notification demandant à l'utilisateur d'accepter une mémorisation d'une localisation courante pour des transactions ultérieures, et pour émettre en réponse à la notification reçue une donnée d'acceptation de mémorisation de la localisation courante,
une interface d'entrée pour recevoir à l'initiative de l'utilisateur une donnée d'acceptation de mémorisation de la localisation courante.
EP14742264.6A 2013-06-27 2014-06-24 Verification de la validite d'une transaction par localisation d'un terminal Ceased EP3014542A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1356178A FR3007870A1 (fr) 2013-06-27 2013-06-27 Verification de la validite d'une transaction par localisation d'un terminal.
PCT/FR2014/051565 WO2014207364A1 (fr) 2013-06-27 2014-06-24 Verification de la validite d'une transaction par localisation d'un terminal

Publications (1)

Publication Number Publication Date
EP3014542A1 true EP3014542A1 (fr) 2016-05-04

Family

ID=49998311

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14742264.6A Ceased EP3014542A1 (fr) 2013-06-27 2014-06-24 Verification de la validite d'une transaction par localisation d'un terminal

Country Status (4)

Country Link
US (1) US20160371676A1 (fr)
EP (1) EP3014542A1 (fr)
FR (1) FR3007870A1 (fr)
WO (1) WO2014207364A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018024980A1 (fr) 2016-08-01 2018-02-08 Orange Procédé de mise en œuvre d'une transaction depuis un moyen de transaction électronique

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10872330B2 (en) * 2014-08-28 2020-12-22 Retailmenot, Inc. Enhancing probabilistic signals indicative of unauthorized access to stored value cards by routing the cards to geographically distinct users

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110238517A1 (en) * 2010-03-23 2011-09-29 Harsha Ramalingam User Profile and Geolocation for Efficient Transactions

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7503489B2 (en) * 2005-04-26 2009-03-17 Bpriv, Llc Method and system for monitoring electronic purchases and cash-withdrawals
EP2225743A4 (fr) * 2007-12-21 2012-01-04 Telecomm Systems Inc Validation de transaction de portefeuille électronique de dispositif sans fil
US8295898B2 (en) * 2008-07-22 2012-10-23 Bank Of America Corporation Location based authentication of mobile device transactions
US8200251B2 (en) * 2010-01-15 2012-06-12 Apple Inc. Determining a location of a mobile device using a location database
US20140095385A1 (en) * 2012-09-28 2014-04-03 Alex Ainslie Selecting merchants for automatic payments

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110238517A1 (en) * 2010-03-23 2011-09-29 Harsha Ramalingam User Profile and Geolocation for Efficient Transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2014207364A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018024980A1 (fr) 2016-08-01 2018-02-08 Orange Procédé de mise en œuvre d'une transaction depuis un moyen de transaction électronique

Also Published As

Publication number Publication date
US20160371676A1 (en) 2016-12-22
FR3007870A1 (fr) 2015-01-02
WO2014207364A1 (fr) 2014-12-31

Similar Documents

Publication Publication Date Title
EP3100171B1 (fr) Authentification de client à l'aide de données de relations sociales
US20160197904A1 (en) Account association systems and methods
US20090234764A1 (en) Systems and methods for biometric authentication of monetary fund transfer
FR2864289A1 (fr) Controle d'acces biometrique utilisant un terminal de telephonie mobile
CN107729727B (zh) 一种帐号的实名认证方法及装置
EP3168769A1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
FR2987150A1 (fr) Securisation d'une transmission de donnees.
FR2956941A1 (fr) Procede d'authentification biometrique, systeme d'authentification, programme et terminal correspondants.
WO2020064890A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
WO2014207364A1 (fr) Verification de la validite d'une transaction par localisation d'un terminal
EP3262553B1 (fr) Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
EP3729307B1 (fr) Procédés et dispositifs pour l'enrôlement et l'authentification d'un utilisateur auprès d'un service
WO2021122186A1 (fr) Procédé et dispositif de contrôle d'accès anonyme à une plateforme collaborative d'anonymisation
EP2529330B1 (fr) Procédé de fourniture d'un code dynamique par l'intermédiaire d'un téléphone
EP2897095B1 (fr) Procédé de sécurisation d'une transaction réalisée par carte bancaire
FR3025631A1 (fr) Selection securisee d'une application dans une carte a puce ou equivalent
FR3044789A1 (fr) Procede d'autorisation d'une transaction
WO2015165827A1 (fr) Procédé et dispositif d'authentification d'un utilisateur pour l'accès à des ressources distantes
FR2985341A1 (fr) Procede et systeme de securisation d'un paiement realise a l'aide d'une carte de paiement
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
FR3060172A1 (fr) Procede de transaction relative a un vehicule .
WO2016062749A1 (fr) Evaluation d'un niveau de confiance dans la recolte d'informations par un terminal de communication par rapport des empreintes
FR3026528A1 (fr) Procede de protection d'un terminal mobile contre des attaques
FR2985339A1 (fr) Procede et systeme de controle de l'acces par un utilisateur a des moyens formant serveur notamment bancaire
FR2985340A1 (fr) Procede et systeme de securisation d'un paiement realise a l'aide d'une carte de paiement notamment bancaire

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151221

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: VERDIER, MATTHIEU

Inventor name: MASSIERE, OLIVIER

17Q First examination report despatched

Effective date: 20171214

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20190201