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

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.

Il 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 W02004070492 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 W02004070492, 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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éfere à 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éfere 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 51 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éfere à 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 oeuvre 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 B1, 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 LOCI 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 (15)

1. REVENDICATIONS1. Procédé de vérification de la validité d'une transaction, comportant les étapes, mises en oeuvre 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.
2. 2. 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.
3. 3. 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.
4. 4. 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.
5. 5. 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. 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.
7. 7. 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 leterminal pour la vérification de cohérence entre le lieu courant et les localisations précédentes du terminal
8. 8. 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.
9. 9. 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. 10
10. 10. 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. 11. Procédé selon la revendication 10, dans lequel la cohérence est vérifiée si le lieu courant se 15 situe autour de l'une desdites moyennes, dans un rayon correspondant audit seuil prédéterminé
12. 12. Procédé selon l'une des revendications précédentes, dans lequel les données de localisations précédentes stockées dans la base sont mémorisées à l'initiative de 20 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.
13. 13. Procédé selon l'une des revendications précédentes, dans lequel l'action en réponse à la 25 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.
14. 14. Programme informatique, comportant des instructions pour la mise en oeuvre du procédé 30 selon l'une des revendications 1 à 13, lorsque ce programme est exécuté par un processeur.
15. 15. 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 35 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.