FR3125152A1 - Procédé de contrôle d’une transaction sans contact et objet communicant correspondant - Google Patents

Procédé de contrôle d’une transaction sans contact et objet communicant correspondant Download PDF

Info

Publication number
FR3125152A1
FR3125152A1 FR2107284A FR2107284A FR3125152A1 FR 3125152 A1 FR3125152 A1 FR 3125152A1 FR 2107284 A FR2107284 A FR 2107284A FR 2107284 A FR2107284 A FR 2107284A FR 3125152 A1 FR3125152 A1 FR 3125152A1
Authority
FR
France
Prior art keywords
transaction
communicating object
data
request
communication device
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
FR2107284A
Other languages
English (en)
Inventor
Emmanuel Le Huerou
François Toutain
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 FR2107284A priority Critical patent/FR3125152A1/fr
Priority to EP22741348.1A priority patent/EP4367620A1/fr
Priority to PCT/FR2022/051183 priority patent/WO2023281178A1/fr
Publication of FR3125152A1 publication Critical patent/FR3125152A1/fr
Withdrawn 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/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
    • 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/308—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using the Internet of Things
    • 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/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable devices
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F13/00—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs
    • G07F13/02—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs by volume
    • G07F13/025—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs by volume wherein the volume is determined during delivery
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F15/00—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity
    • G07F15/003—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity for electricity
    • G07F15/005—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity for electricity dispensed for the electrical charging of vehicles
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/10—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property
    • G07F17/12—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property comprising lockable containers, e.g. for accepting clothes to be cleaned
    • G07F17/13—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property comprising lockable containers, e.g. for accepting clothes to be cleaned the containers being a postal pick-up locker
    • 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
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé de contrôle d’une transaction sans contact et objet communicant correspondant L’invention concerne un procédé de contrôle d’une transaction sans contact entre un objet communicant (OC) et un dispositif de communication (DC), au cours duquel l’objet communicant reçoit (S1) en provenance du dispositif de communication une requête contenant des données relatives à la transaction, le procédé étant caractérisé en ce que l’objet communicant exécute de manière autonome ce qui suit : - extraire (S2) de ladite requête reçue des informations (DAT1) relatives à la transaction, - comparer (S3) les informations extraites à des données de contexte d’utilisation (DCU) de l’objet communicant qui ont été déterminées par l’objet, - activer (S5) l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation Figure pour l’abrégé : Figure 3

Description

Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
Domaine de l'invention
L'invention concerne les communications sans contact, c’est-à-dire sans fil, pour la transmission de données entre un objet communicant et un dispositif de communication. Plus précisément, l'invention porte sur les transactions mises en œuvre lors de ces communications sans contact, telles que notamment les transactions de type bancaire, accès à un moyen de transport ou à un lieu sécurisé, commande de bien(s) ou de service(s), etc… et la façon dont un objet communicant, tel que par exemple un véhicule connecté, un smartphone (« téléphone intelligent »), une montre connectée, contrôle ces transactions sans contact avec un dispositif de communication, typiquement un lecteur, un point de paiement, un portillon d’accès, etc.
Art antérieur
Il est possible actuellement de mettre en œuvre une transaction à l’aide d’un objet communicant ou connecté. Dans le cas par exemple où la transaction est un paiement d’un bien ou d’un service, un utilisateur qui a réalisé un achat peut payer celui-ci en utilisant un objet connecté, tel qu’une carte bancaire, un smartphone (« téléphone intelligent »), une montre connectée, etc. A cet effet, l’utilisateur connaît le contexte de son achat (l’objet de son achat, le lieu de l’achat, le commerçant, etc.). Ainsi, lorsque le commerçant présente à l’utilisateur un terminal de paiement électronique (TPE) sur lequel est affiché le prix correspondant à cet achat et quelquefois l’objet de cet achat, l’utilisateur vérifie ces informations et, si elles lui conviennent, approche son objet connecté du TPE pour autoriser la transaction si celle-ci est sans contact. Dans le cas où la transaction sans contact n’est pas possible, l’utilisateur est obligé de saisir un code sur le TPE pour autoriser la transaction.
Dans le cas où la transaction est l’accès à un local sécurisé ou à un moyen de transport (métro par exemple) via un portillon d’accès, l’utilisateur connait le lieu et les conditions de cet accès. Ainsi, lorsque l’utilisateur s’approche d’une borne ou d’un portillon, il lui suffit d’approcher son objet connecté (badge d’accès, carte de transport, smartphone, etc.) pour valider l’accès.
On voit par ailleurs apparaître depuis quelques années des objets connectés plus sophistiqués, tels que par exemple des véhicules connectés. Ces véhicules connectés sont dotés :
- de moyens de communication sans fil courte ou moyenne portée tel que par exemple Bluetooth, LTE (« Long Term Evolution » en anglais), WiFi DSRC (« Dedicated Short Range Communication » en anglais), C-V2X (« Cellular Vehicle To Everything » en anglais), etc.
- de moyens de transaction, tels que par exemple une carte eSIM (« Embedded Subscriber Identification Module » en anglais) installée dans le véhicule, un porte-monnaie électronique (« e-wallet » en anglais) embarqué dans l’infrastructure informatique du véhicule et dans lequel a/ont été préchargée(s) une ou plusieurs unités de monnaie numérique (« tokens » en anglais) de carte bancaire, etc.
Grâce à une telle technologie, des transactions sans contact peuvent être mises en œuvre dans le véhicule connecté pour accéder à des biens ou des services qui incluent par exemple le stationnement dans un parking, le paiement d’un péage autoroutier, l’utilisation d’une station-service (essence ou recharge électrique, lavage, …), une opération de maintenance ou d’entretien, la délivrance d’une commande à un service de type drive-in (fastfood, click & collect…).
Un inconvénient de l’utilisation d’un tel véhicule connecté est que l’utilisateur est obligé, comme dans les cas d’usage précédents, de vérifier toutes les informations relatives à la transaction, lesquelles s’affichent par exemple sur une console du tableau de bord, avant d’autoriser la transaction, en cliquant sur un bouton « valider » affiché sur la console, ou avant de refuser la transaction, en cliquant sur un bouton « annuler» affiché sur la console.
Bien qu’un tel véhicule connecté facilite la mise en œuvre des transactions d’un utilisateur qui se trouve à son bord, l’utilisateur est quand même obligé d’intervenir lors de la transaction pour la vérifier et la valider.
Objet et résumé de l'invention
Un des buts de l'invention est de remédier à des inconvénients de l'état de la technique précité en permettant à un objet connecté de contrôler la mise en œuvre d’une transaction sans contact avec un dispositif de communication de manière complètement autonome et sécurisée, sans qu’un utilisateur de l’objet n’ait besoin d’intervenir sur l’objet connecté ou de le manipuler.
A cet effet, un objet de la présente invention concerne un procédé de contrôle d’une transaction sans contact entre un objet communicant et un dispositif de communication, au cours duquel l’objet communicant reçoit en provenance du dispositif de communication une requête contenant des données relatives à la transaction.
Un tel procédé est remarquable en ce que l’objet communicant exécute de manière autonome ce qui suit :
- extraire de la requête reçue des informations relatives à la transaction,
- comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
- activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
L’invention permet avantageusement à un objet connecté, apte à communiquer sans contact avec un dispositif de communication dans le cadre de la mise en œuvre d’une transaction, d’être pourvu d’un mécanisme décisionnel permettant de vérifier :
- si une requête contenant des données relatives à la transaction, reçue en provenance du dispositif de communication, est légitime ou non,
- et, dans le cas où cette requête est considérée légitime par l’objet, de répondre favorablement à cette requête afin de mettre en œuvre la transaction.
Un avantage de l’invention est qu’une telle vérification est exécutée de façon complètement autonome par l’objet communicant, tel que par exemple un véhicule connecté, une montre connectée, une carte connectée, c’est-à-dire sans aucune intervention ou manipulation humaine par rapport à l’objet. Ainsi, grâce à l’invention, l’objet connecté décide de sa propre initiative s’il est autorisé à effectuer une transaction sans contact à bon escient avec le dispositif de communication, une telle transaction étant par exemple un paiement, la livraison d’un bien ou d’un service, l’accès à une consigne, un moyen de transport, etc.
Un tel mécanisme décisionnel installé dans l’objet communicant permet par ailleurs d’éviter ou de limiter le développement et le déploiement dans le réseau d’outils de traitement préventifs destinés à vérifier la légitimité d’une requête, ces outils étant complexes techniquement et coûteux.
Selon un mode de réalisation particulier, en l’absence d’une concordance entre les informations relatives à la transaction et les données de contexte d’utilisation, l’objet communicant active l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction, ou ne répond pas à la requête.
Grâce à ce mode de réalisation, l’objet communicant est apte à traiter de manière autonome la réception de toute requête contenant des données relatives à une transaction qui ne serait pas destinée à cet objet communicant mais à un autre objet communicant ou bien qui serait destinée à l’objet communicant de manière frauduleuse ou par erreur. A cet effet, l’objet communicant peut envoyer une réponse à la requête refusant la transaction, ce qui met fin à la communication entre l’objet communicant et le dispositif de communication. A titre d’alternative, l’objet communicant peut ignorer cette requête et ne pas y répondre, dans un souci d’économie des ressources de la batterie de l’objet communicant et/ou de la bande passante du réseau de communication sans fil entre l’objet communicant et le dispositif de communication.
Selon un autre mode de réalisation particulier, au cours de la comparaison des informations extraites avec les données de contexte d’utilisation, au moins une donnée complémentaire relative à la transaction est déterminée, ladite au moins une donnée complémentaire étant ajoutée dans la réponse à la requête autorisant la transaction.
Grâce à ce mode de réalisation, l’objet communicant est en mesure :
- de générer de manière autonome une ou plusieurs données complémentaires relatives à la transaction, telles que par exemple un identifiant associé à l’utilisateur de l’objet au moment de la transaction, l’identité de cet utilisateur, le lieu de la transaction, etc…, et
- de communiquer astucieusement cette/ces donnée(s) complémentaire(s) dans la réponse à la requête autorisant la transaction.
La réponse à la requête autorisant la transaction est ainsi avantageusement enrichie de données utiles que le dispositif de communication pourra transmettre au gestionnaire de la transaction ou de l’objet communicant ou encore au fournisseur du bien ou du service, pour un traitement/archivage/traçage des transactions qui ont été effectuées par un utilisateur de l’objet communicant particulier.
Selon un autre mode de réalisation particulier, lorsque la transaction est un paiement et que l’objet communicant comprend au moins deux moyens de paiement associés respectivement à deux utilisateurs différents, la au moins une donnée complémentaire est un identifiant du moyen de paiement associé à l’utilisateur de l’objet au moment de la transaction.
Grâce à ce mode de réalisation, dans le cas où l’objet communicant est apte à mettre en œuvre un paiement pour plusieurs utilisateurs potentiels différents, l’objet communicant est avantageusement capable de déduire de manière autonome et automatiquement le moyen de paiement de l’utilisateur réellement concerné par ce paiement.
Selon un autre mode de réalisation particulier, la comparaison des informations extraites avec les données de contexte d’utilisation comprend ce qui suit :
- générer un score de fiabilité de la comparaison,
- comparer le score généré à un seuil,
- en fonction du résultat de la comparaison :
  • activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction,
  • activer l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction ou ne pas répondre à la requête.
Un tel mode de réalisation constitue un mécanisme décisionnel très simple à implémenter et donc adapté à la préservation des ressources en calculs de l’objet communicant qui sont généralement peu élevées. Ce score est alors comparé à un seuil de référence, par exemple 0.5, qui caractérise une situation de transaction par exemple valide au-dessus de ce seuil et une situation de transaction invalide en-dessous de ce seuil (l’inverse est également possible selon la convention de comparaison établie). Si le score attribué est supérieur (ou supérieur ou égal) à ce seuil de référence, l’objet communicant envoie une réponse à la requête autorisant la transaction. Si le score attribué est inférieur (ou inférieur ou égal) à ce seuil de référence, l’objet communicant ne répond pas à la requête ou envoie une réponse à la requête refusant la transaction.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation de l’objet communicant sont représentatives d’un environnement dans lequel se trouve l’objet communicant ou contiennent au moins une donnée de fonctionnement d’une transaction de l’objet communicant.
De telles données de contexte d’utilisation déterminées en toute autonomie par l’objet communicant sont particulièrement précises et fiables étant donné qu’elles sont liées à l’environnement même dans lequel se trouve l’objet communicant et/ou qu’elles sont basées sur des données de fonctionnement de cet objet.
Selon un autre mode de réalisation particulier, la au moins une donnée de fonctionnement de l’objet communicant est un paramètre de fonctionnement courant relevé par l’objet communicant ou un élément d’un historique des communications effectuées par l’objet communicant.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant sont contenues dans un message reçu par l’objet communicant en provenance du dispositif de communication ou d’un dispositif d’émission de message situé dans ledit environnement.
De telles données de contexte d’utilisation constituent des données pertinentes complémentaires qui peuvent avantageusement être utilisées dans l’étape de comparaison précitée, en sus des données de contexte d’utilisation obtenues dans le mode de réalisation précédent. Il peut s’agir par exemple du nom du fournisseur du bien ou du service faisant l’objet de la transaction, du type de bien ou de service, d’un lieu où se trouve le bien ou le service.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant contiennent une donnée issue d’au moins un capteur appartenant à l’objet communicant.
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, au procédé de contrôle d’une transaction sans contact défini ci-dessus.
L'invention concerne également un objet communicant ayant des capacités de contrôle d’une transaction sans contact avec un dispositif de communication, l’objet communicant comprenant un processeur qui est configuré pour recevoir en provenance du dispositif de communication une requête contenant des données relatives à la transaction.
Un tel objet communicant est remarquable en ce que le processeur de l’objet communicant exécute de manière autonome ce qui suit :
- extraire de la requête reçue des informations relatives à la transaction,
- comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
- activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
L'invention concerne également un système de contrôle d’une transaction sans contact.
Un tel système est remarquable en ce qu’il comprend :
- un objet communicant mettant en œuvre le procédé de contrôle de transaction sans contact précité,
- un dispositif de communication sans contact qui est configuré pour envoyer à l’objet communicant une requête contenant des données relatives à la transaction.
L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle d’une transaction sans contact selon l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur.
De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire de l’objet communicant mettant en œuvre le procédé de contrôle d’une transaction sans contact selon l’invention.
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 également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
Le support d'enregistrement 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, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile, un disque dur ou un SSD.
D'autre part, le support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par un exemple un réseau de type Internet.
Alternativement, le support d'enregistrement 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é de contrôle d’une transaction sans contact précité.
Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation particuliers de l'invention, donnés à titre d’exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La représente un système de contrôle de transaction sans contact selon un premier mode de réalisation de l'invention,
La représente un système de contrôle de transaction sans contact selon un deuxième mode de réalisation de l'invention,
La représente un système de de contrôle de transaction sans contact selon un troisième mode de réalisation de l'invention,
La représente un objet communicant dans un mode de réalisation de l’invention,
La représente les principales actions mises en œuvre dans le procédé de contrôle de transaction sans contact, selon un mode de réalisation particulier de l’invention,
La représente un mode de réalisation d’une étape de détermination de la légitimité de la transaction ou non, mise en œuvre dans le procédé de contrôle de transaction sans contact selon l’invention.
Description détaillé e d’un mode de réalisation de l’invention
La représente un système de contrôle d’une transaction sans contact selon un premier mode de réalisation de l'invention.
Un tel système comprend :
- un objet connecté ou communicant OC1associé à un utilisateur UT,
- un dispositif DF1de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DC1configuré pour communiquer avec l’objet OC1pour la mise en œuvre d’une transaction sans contact relative à la fourniture d’un bien ou d’un service par le dispositif DF1.
On appelle objet communicant ou connecté tout objet configuré pour capter des données et pour communiquer avec d’autres objets ou avec des infrastructures dédiées selon la technologie IoT (« Internet of Things » en anglais).
Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC1, de façon complètement autonome, comme cela sera décrit plus loin dans la description.
Dans l’exemple de la , l’objet communicant OC1est par exemple un véhicule, ici une voiture électrique connectée. A ce titre, la voiture OC1est dotée nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un capteur qui détecte le niveau de la charge de la batterie, un capteur de vitesse, un dispositif de géolocalisation de type GPS (« Global Positioning System » en anglais), un capteur d’empreinte digitale, etc…
Selon l’invention, la voiture connectée OC1est dotée :
- d'un module MCO de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
- d’un module MT de transaction sans contact, par exemple une carte eSIM (« Embedded Subscriber Identification Module » en anglais) installée dans la voiture, un porte-monnaie électronique (« e-wallet » en anglais) embarqué dans l’infrastructure informatique de la voiture et dans lequel a/ont été préchargée(s) une ou plusieurs unités de monnaie numérique (« tokens » en anglais) de carte bancaire, etc.
Dans l’exemple de la , le dispositif DF1de fourniture de bien ou de service est une borne de recharge parmi d’autres disponibles d’une station de recharge pour véhicules électriques. Dans l’exemple représenté, la borne de recharge porte le numéro 3.
Dans l’exemple de la , le dispositif de communication DC1est un serveur de paiement ou un TPE qui peut être compris dans la borne de recharge DF1ou encore dissocié de celle-ci.
Dans ce contexte de transaction sans contact de l’invention, la voiture électrique connecté OC1commence par s’appairer avec la borne de recharge DF1, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un paiement correspondant à la recharge effectuée. Cette transaction sans contact est contrôlée par la voiture connectée OC1, à partir du moment où l’utilisateur UT a relié le connecteur de charge de la borne DF1à la batterie de la voiture connectée OC1. Si la voiture connectée OC1estime que la transaction sans contact est valide/légitime, la transaction sans contact débute, puis prend fin une fois que l’utilisateur a remis en place le connecteur de charge sur la borne.
Bien entendu, cet exemple n‘a rien d’exhaustif. En particulier, le dispositif DF1de fourniture de bien ou de service varie en fonction du contexte d’utilisation de la voiture connectée OC1. A cet effet, le dispositif de fourniture de bien ou de service DF1pourrait être alternativement :
- une pompe à essence,
- un guichet de vente de nourriture à emporter,
- un parcmètre,
- une barrière de péage,
- etc.
La représente un système de contrôle d’une transaction sans contact selon un deuxième mode de réalisation de l'invention. Ce deuxième mode de réalisation utilise des éléments communs à ceux de la . Pour cette raison, ces éléments sont désignés avec les mêmes références.
Un tel système comprend :
- un objet connecté ou communicant OC2associé à un utilisateur UT,
- un dispositif DF2de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DC2configuré pour communiquer avec l’objet OC2pour la mise en œuvre d’une transaction relative à la fourniture d’un bien ou d’un service par le dispositif DF2.
Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC2, de façon complètement autonome comme cela sera décrit plus loin dans la description.
Dans l’exemple de la , l’objet communicant OC2est un objet porté par l’utilisateur UT, tel que par exemple une montre connectée. Il pourrait bien sûr s’agir d’une tablette, d’un badge, d’un bracelet, de lunettes, etc.
A ce titre, la montre OC2est dotée nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un appareil photo, un accéléromètre, un dispositif de géolocalisation de type GPS, un capteur d’empreinte numérique, etc.
Selon l’invention, la montre connectée OC2est dotée :
- du module de communication MCO précité,
- d’un module MT de transaction sans contact, par exemple un porte-monnaie électronique embarqué dans la montre connectée OC3, dans lequel a/ont été préchargé(s) un ou plusieurs tickets de transport numériques (« tokens » en anglais), un identifiant particulier IDGT associé au porte-monnaie électronique, etc.
Dans l’exemple de la , le dispositif DF2de fourniture de bien ou de service est un portillon d’accès à un moyen de transport, tel que par exemple le métro, le train, le tramway, etc. Il peut être aussi une borne disposée dans un bus ou un tramway, à proximité d’un quai dans une gare, etc.
Dans l’exemple de la , le dispositif de communication DC2est un serveur de contrôle d’accès qui peut être compris dans le portillon DF2ou encore dissocié de celui-ci.
Dans ce contexte de transaction sans contact de l’invention, la montre connectée OC2commence par s’appairer avec le portillon DF2, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un accès au moyen de transport. Cette transaction sans contact est contrôlée par la montre connectée OC2, à partir du moment où l’utilisateur UT est à quelques centimètres du portillon DF2. Si la montre connectée OC2estime que la transaction sans contact est valide/légitime, la transaction sans contact débute avec le serveur DC2, ce qui entraîne l’ouverture du portillon DF2pour laisser passer l’utilisateur UT, puis prend fin une fois que l’utilisateur UT a passé ce portillon. Un tel contrôle d’accès met par exemple en œuvre une décrémentation d’un ou de plusieurs tickets de transport numériques préchargé(s) dans le porte-monnaie électronique de la montre connectée OC2. Selon un autre exemple, un tel contrôle d’accès met par exemple en œuvre une vérification de l’identifiant particulier IDGT associé au porte-monnaie électronique de la montre connectée OC2dans un but de valider automatiquement l’accès au moyen de transport sur la base de cet identifiant particulier.
La représente un système de contrôle d’une transaction sans contact selon un troisième mode de réalisation de l'invention. Ce troisième mode de réalisation utilise des éléments communs à ceux des figures 1A et 1B. Pour cette raison, ces éléments sont désignés avec les mêmes références.
Un tel système comprend :
- un objet connecté ou communicant OC3associé à un utilisateur UT,
- un dispositif DF3de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DC3configuré pour communiquer avec l’objet OC3pour la mise en œuvre d’une transaction relative à la fourniture d’un bien ou d’un service par le dispositif DF3.
Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC3, de façon complètement autonome, comme cela sera décrit plus loin dans la description.
Dans l’exemple de la , l’objet communicant OC3est un objet porté par l’utilisateur UT, tel que par exemple un smartphone. Il pourrait bien sûr s’agir en variante d’une tablette, d’un badge, d’un bracelet, etc.
A ce titre, le smartphone OC3est doté nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un appareil photo, un accéléromètre, un dispositif de géolocalisation de type GPS, un capteur biométrique, etc.
Selon l’invention, le smartphone OC3est doté :
- du module de communication MCO précité,
- d’un module MT de transaction sans contact, par exemple une mémoire stockant un identifiant de retrait d’une commande d’un bien ou un service qu’a effectuée au préalable l’utilisateur UT.
Dans l’exemple de la , le dispositif DF3de fourniture du bien ou du service commandé par l’utilisateur UT est une boîte de retrait automatique de colis. Dans l’exemple représenté, cette boîte comprend sept casiers référencés A à G.
Dans l’exemple de la , le dispositif de communication DC3est un serveur de commande d’ouverture/fermeture des casiers. Le serveur DC3peut être compris dans la boîte de retrait DF3ou encore dissocié de celle-ci.
Dans ce contexte de transaction sans contact de l’invention, le smartphone OC3commence par s’appairer avec la boîte de retrait DF3, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un retrait d’un colis COL. Cette transaction sans contact est contrôlée par le smartphone OC3, à partir du moment où l’utilisateur UT est à quelques centimètres de la boîte de retrait DF3. Si le smartphone OC3estime que la transaction sans contact avec le serveur DC3est valide/légitime, la transaction sans contact débute avec le serveur DC3, ce qui entraîne l’ouverture d’un des casiers qui contient le colis COL, le casier E dans l’exemple représenté. La transaction sans contact prend fin une fois que l’utilisateur UT a retiré le colis COL du casier E et que ce dernier a été refermé. Un tel contrôle d’accès met par exemple en œuvre une vérification que l’identifiant de retrait stocké dans la mémoire du smartphone OC3correspond bien à l’identifiant du colis COL en attente de retrait dans le casier E, dans le but de provoquer l’ouverture automatique de ce casier, sans que l’utilisateur UT n’ait besoin de manipuler son smartphone OC3.
Description d’un mode de réalisation de l’objet communicant OC
La présente la structure simplifiée de l’objet communicant OC, tel que par exemple l’objet OC1, OC2ou OC3des figures 1A à 1C, lequel objet communicant est adapté pour mettre en œuvre le procédé de contrôle d’une transaction sans contact qui va être décrit ci-dessous.
Comme déjà expliqué plus haut, un tel objet communicant comprend classiquement:
- un module de communication MCO adapté pour communiquer, via un réseau RCMP de données sans fil courte ou moyenne portée, tel que par exemple Bluetooth, NFC, LTE, WiFi, DSRC, C-V2X, etc.,
- un ou plusieurs capteurs/détecteurs CAP1, CAP2,…, CAPS(S≥1).
L’objet communicant OC comprend en outre selon l’invention:
- un module de communication MCO’ adapté pour communiquer via un réseau RLP de données longue portée (3G, 4G, 5G, etc.),
- un module REC de réception de messages de diffusion MSG, par exemple de type beacon ou de type V2X (« Vehicle-to-Everything » en anglais) quand l’objet communicant OC est plus particulièrement un véhicule, ces messages de diffusion étant reçus en provenance de différents dispositifs et/ou infrastructures que l’objet communicant rencontre sur son trajet,
- un module de transaction MT tel que par exemple une carte SIM, eSIM, e-wallet, une mémoire dédiée à la transaction sans contact, etc,
- un module d’analyse ANA configuré pour analyser des données de transaction DAT1 contenues dans les requêtes de transaction que l’objet communicant OC reçoit en provenance d’un dispositif de communication DC, tel que par exemple le dispositif de communication DC1, DC2ou DC3des figures 1A à 1C,
- un module DET configuré pour déterminer au moins une donnée de transaction complémentaire DAT2 en plus de celle(s) déjà contenue(s) dans les requêtes de transaction reçues,
- un module d’accès ACC à une mémoire MEM1qui contient des données/informations DCU de contexte d’utilisation de l’objet communicant OC, dont des exemples seront donnés plus loin dans la description.
Sur la , la mémoire MEM1n’est pas contenue dans l’objet communicant OC afin de préserver les ressources mémoire de celui-ci. A cet effet, la mémoire MEM1est déportée dans un réseau de communication, un nuage (« cloud » en anglais), etc. et est rendue accessible par l’objet communicant OC, au moyen du module ACC dédié à cet effet. En variante, la mémoire MEM1ou une partie de celle-ci pourrait être intégrée à l’objet communicant OC.
Bien que sur la , le module DET de détermination d’au moins une donnée de transaction complémentaire DAT2 soit intégré à l’objet communicant OC, le module DET pourrait être dissocié de cet objet pour préserver les ressources en calculs de ce dernier.
Selon un mode particulier de réalisation de l'invention, les actions exécutées par l’objet communicant OC, dans le cadre de la mise en œuvre du procédé de contrôle d’une transaction sans contact conformément à la présente invention, sont mises en œuvre par des instructions d’un programme d'ordinateur PG. Pour cela, l’objet communicant OC a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UTR, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM2. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les actions exécutées par l’objet communicant OC, lorsque le programme est exécuté par le processeur PROC, selon l'un quelconque des modes particuliers de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UTR met notamment en œuvre les actions de recueil des données issues du et/ou des capteurs CAP1, CAP2,…, CAPS, les actions de réception du et/ou des messages MSG, les actions de réception de requêtes de transaction, les actions d’analyse de ces requêtes, les actions de détermination d’au moins une donnée de transaction complémentaire, les actions d’envoi ou de non envoi d’une réponse à ces requêtes de transaction.
Description d’un mode de réalisation d’un procédé de contrôle de transaction sans contact
On décrit maintenant, en relation avec la , le déroulement d’un procédé de contrôle d’une transaction sans contact exécuté par un objet communicant OC, tel que par exemple l’objet OC1, OC2ou OC3des figures 1A à 1C, selon un mode de réalisation de l’invention. Une telle transaction sans contact est établie lors d’une communication sans contact entre l’objet communicant OC et le dispositif de communication DC précité, tel que par exemple le dispositif de communication DC1, DC2ou DC3des figures 1A à 1C. L’objet de la transaction sans contact est par exemple un bien ou un service fourni par un dispositif DF de fourniture de bien ou de service à l’utilisateur UT de l’objet communicant OC, tel que par exemple le dispositif de fourniture de bien ou de service DF1, DF2ou DF3des figures 1A à 1C.
Conformément à l’invention, l’objet communicant OC est configuré de telle manière qu’il exécute de manière autonome les différentes actions qui vont être décrites ci-dessous pour contrôler une transaction sans contact avec le dispositif de communication DC, comme si c’était l’utilisateur UT lui-même qui mettait en œuvre un tel contrôle, à savoir vérifier la légitimité de la transaction, comme l’utilisateur le fait habituellement en vérifiant par exemple que l’objet de la transaction est celui qu’il souhaite, que le prix de l’objet, quand celui-ci est payant, est bien le bon, le lieu de la transaction, etc…, et valider la transaction ou non en fonction de cette vérification.
En préalable au déroulement du procédé de contrôle de transaction sans contact décrit ci-dessous, on considère que l’utilisateur UT et son objet communicant OC se sont rapprochés du dispositif DF de fourniture de bien ou de service et que l’établissement d’un canal de communication de façon sécurisée a été réalisé pour mettre en œuvre la transaction sans contact entre l’objet communicant OC et le dispositif de communication DC. L’établissement d’un tel canal de communication ou appairage est classique et ne sera pas décrit plus avant. Dans un mode de réalisation particulier, l’établissement d’un tel canal de communication est exécuté de manière autonome par l’objet communicant OC comme décrit dans le document FR2106702 incorporé à titre de référence à la présente description.
Le procédé de contrôle d’une transaction sans contact se déroule alors comme suit :
En S1, l’objet communicant OC reçoit, en provenance du dispositif de communication DC, une requête REQ_TR contenant des données DAT1 relatives à une transaction. Une telle requête peut être reçue par le module de communication MCO ou MCO’ de la .
Dans le contexte d’utilisation de la , la requête REQ_TR est par exemple une requête de paiement. Il peut s’agir d’une requête par exemple de type SEPA RTP (« Single Euro Payments Area Request to Pay » en anglais), de type Paypal : https://developer.paypal.com/docs/integration/paypal-plus/mexico-brazil/create-a-payment-request/, etc., pour laquelle les données DAT1 correspondent par exemple :
- au montant de la transaction, ici le prix de la recharge en électricité,
- au type de bien ou de service concerné par la transaction, ici « recharge batterie », - à un identifiant du dispositif DC de fourniture de bien ou de service, ici borne de recharge n°3,
- à la localisation de la transaction, ici les données de géolocalisation de la station de recharge,
- à une quantité ou un volume en lien avec le bien ou le service faisant l’objet de la transaction, ici, la quantité d’électricité consommée pour recharger la batterie de la voiture électrique connectée OC1.
Dans le contexte d’utilisation de la , la requête REQ_TR est par exemple une requête d’identification de l’accès au moyen de transport. Une telle requête est par exemple de type Internet. Elle contient des données DAT1 correspondant par exemple :
- à un identifiant du portillon DF2: par exemple cette identifiant peut commencer par la lettre « M » pour indiquer qu’il s’agit du portillon d’un métro, par la lettre « B » pour indiquer qu’il s’agit de la borne d’accès d’un bus, etc.,
- la catégorie du moyen de transport correspondant au dispositif DF2: bus, métro, train, tramway, etc,
- le prix d’un ou de plusieurs tickets de transport,
- l’identifiant particulier IDGT d’accès gratuit aux transports qui est associé au module de transaction MT de la montre connectée OC2,
- etc.
Dans le contexte d’utilisation de la , la requête REQ_TR est par exemple une requête d’accès à la boîte DF3de retrait de colis. Une telle requête est par exemple de type Internet. Elle contient des données DAT1 correspondant par exemple :
- à un identifiant de retrait, tel que par exemple un code de livraison, la lettre « G » du casier qui contient le colis COL,…
- à un identifiant ou un nom de l’enseigne de la boutique d’où provient le colis COL,
- au prix de la commande,
- à la quantité d’articles livrés,
- au lieu où se situe la boîte de retrait de colis,
- etc.
Le procédé de contrôle de la transaction sans contact se poursuit en S2, où l’objet communicant OC extrait les données DAT1 de la requête REQ_TR reçue.
En S3, le module d’analyse ANA de la met en œuvre une analyse de ces données DAT1. A cet effet, les données DAT1 sont comparées à des données de contexte d’utilisation DCU de l’objet communicant OC.
Les données/informations de contexte d’utilisation DCU sont des données/informations collectées par l’objet communicant OC lors de son déplacement en direction du dispositif DF de fourniture d’un bien ou d’un service, mais aussi préalablement à ce déplacement.
Dans un mode de réalisation, les données/informations de contexte d’utilisation DCU :
- sont des données/informations INF1 représentatives d’un environnement dans lequel se trouve l’objet communicant OC : il peut s’agir par exemple d’une ou plusieurs informations véhiculées dans un message MSG reçu par le module de réception REC de la , en provenance du dispositif de communication DC ou d’un dispositif d’émission de message situé dans l’environnement de l’objet communicant OC, ou encore d’une ou de plusieurs donnée issues d’au moins un des capteurs CAP1à CAPSde la ; et/ou
- contiennent au moins une donnée INF2 de fonctionnement de l’objet communicant OC, telle que par exemple un paramètre de fonctionnement courant relevé par l’objet communicant OC, et/ou
- contiennent au moins un élément INF3 d’un historique des transactions déjà effectuées par l’objet communicant OC, et/ou,
- contiennent un ou des éléments INF4 d’une liste des types de fraudes connues, et/ou
- contiennent un ou des éléments INF5 d’une liste noire de fraudeurs LNF,
- etc.
Au cours ou à l’issue de cette comparaison S3, une ou plusieurs données DAT2 de transaction complémentaires sont déterminées ou identifiées en S4 à l’aide du module DET de la . Une telle détermination peut être réalisée en local par l’objet communicant OC ou de manière déportée.
Dans le contexte d’utilisation de la , les données/informations INF1 représentatives d’un environnement dans lequel se trouve la voiture électrique connectée OC1sont reçues par la voiture OC1, via le module de réception REC de la . Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DC1ou par la borne de recherche DF1, selon le contexte de communication envisagé. Le message MSG peut également être diffusé par toute infrastructure adaptée telle que la station de recharge qui gère l’ensemble des bornes de recharge, un restaurant, un centre routier, une collectivité territoriale, etc…
Un tel message MSG est par exemple de type beacon, V2X, UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc...
Typiquement, cette information INF1 désigne par exemple :
- le nom de la station de recharge où se trouve la borne de recharge DF1, le numéro de cette borne, etc…
- le type de carburant, par exemple « électricité », associé à la borne de recharge DF1,
- etc.
Les données/informations INF1 peuvent également correspondre à une interprétation faite par la voiture électrique connectée OC1des données issues de ses différents capteurs CAP1à CAPS, typiquement le niveau de la recharge en électricité de sa batterie, les dimensions ou le type de la voiture OC1,le ou les occupants de la voiture OC1(biométrie), etc. Les données/informations INF1 peuvent également correspondre par exemple à une enseigne ou un logo de la station de recharge qui ont été reconnus après analyse d’une image ou d’une vidéo capturée par un des capteurs CAP1, CAP2,…, CAPSde la voiture OC1, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que par exemple la position géographique de la station de recharge, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 correspondent également dans ce contexte d’utilisation aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) de la voiture OC1qui sont mesurées par un des capteurs CAP1, CAP2,…, CAPSde la voiture OC1, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la , les données/informations INF2 de fonctionnement de la voiture connectée OC1correspondent aux paramètres liés à l’infrastructure de la voiture OC1et remontés via un multiplex ou un bus de données installé dans la voiture. Il s’agit par exemple de la vitesse courante, de l’ouverture/fermeture de la trappe à carburant/recharge électrique, de la diminution/élévation du niveau de carburant/de la batterie, de l’ouverture/fermeture d’une portière, etc…
Dans le contexte d’utilisation de la , l’élément INF3 d’un historique des transactions déjà effectuées par la voiture OC1est typiquement une information relative à des paiements précédemment effectués par la voiture OC1.
Dans le contexte d’utilisation de la , les données complémentaires de transaction DAT2 sont par exemple l’identité de la personne qui conduit la voiture OC1, le kilométrage effectué, la localisation de la voiture OC1au moment du paiement. Dans le cas où la voiture connectée OC1est partagée par plusieurs personnes ou plusieurs sociétés et contient de ce fait plusieurs modules de transaction MT, ici modules de paiement, les données complémentaires DAT2 correspondent à un identifiant du module de paiement associé à la personne identifiée au préalable par un capteur biométrique de la voiture OC1. Ainsi, l’étape de détermination S4 permet avantageusement de sélectionner automatiquement le module de transaction MT associé à l’utilisateur UT effectif de l’objet communicant OC lorsque plusieurs utilisateurs sont potentiellement aptes à utiliser cet objet.
Dans le contexte d’utilisation de la , les données/informations INF1 représentatives d’un environnement dans lequel se trouve la montre connectée OC2sont reçues via le module de réception REC de la . Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DC2ou par le portillon DF2 selon le contexte de communication envisagé. Le message MSG peut également être diffusé par un émetteur placé en gare ou en station, dans le métro, dans le bus, etc. Typiquement les données/informations INF1 désignent par exemple le nom d’une station ou d’un arrêt de bus/tramway, l’identifiant d’une ligne de transport, des informations de géolocalisation de la montre connectée OC2dans la gare ou la station, le type de moyen de transport emprunté, par exemple « métro», associé au portillon DF2, etc. Un tel message MSG est par exemple de type beacon, UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc...
Les données/informations INF1 peuvent également correspondre à une interprétation faite par la montre connectée OC2des données issues de ses différents capteurs CAP1à CAPS. Elles correspondent par exemple au nom de la station ou de la gare, à un identifiant de la ligne de transport empruntée par l’utilisateur UT, etc. qui ont été reconnus après analyse d’une image ou d’une vidéo capturée par un des capteurs CAP1, CAP2,…, CAPSde la montre OC2, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que la position géographique de la station ou de la gare, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 peuvent également correspondre, dans ce contexte d’utilisation :
- à une vitesse mesurée par un des capteurs CAP1, CAP2,…, CAPSde la montre OC2, typiquement un accéléromètre,
- aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) de la montre OC2qui sont mesurées par un des capteurs CAP1, CAP2,…, CAPSde la montre OC2, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la , les données/informations INF2 de fonctionnement de la montre connectée OC2correspondent par exemple à la date et l’heure courante.
Dans le contexte d’utilisation de la , l’élément INF3 d’un historique des transactions déjà effectuées par la montre connectée OC2est typiquement une information relative à des trajets en transport en commun précédemment effectués par l’utilisateur UT.
Dans le contexte d’utilisation de la , les données complémentaires de transaction DAT2 sont par exemple l’identité de l’utilisateur UT qui porte la montre connectée OC2, la localisation de la montre connectée OC2au moment du passage du portillon DF2par l’utilisateur UT, le nombre de tickets numériques restants, etc. Dans le cas où la montre connectée OC2est partagée par différents utilisateurs et contient de ce fait plusieurs modules de transaction, ici des cartes de transport numériques intégrées à la montre OC2, les données complémentaires DAT2 correspondent à un identifiant de la carte de transport associée à la personne identifiée au préalable, par exemple à l’aide d’un capteur biométrique de la montre connectée OC2.
Dans le contexte d’utilisation de la , les données/informations INF1 représentatives d’un environnement dans lequel se trouve le smartphone OC3sont reçues via le module de réception REC de la . Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DC3ou par la boîte de retrait DF3selon le contexte de communication envisagé. Le message MSG peut également être diffusé par un émetteur placé à proximité de la boîte de retrait DF3. Typiquement les données/informations INF1 désignent par exemple le nom ou un identifiant de la boîte de retrait DF3,un lieu dans lequel se trouve la boîte de retrait DF3, la localisation du smartphone OC3par rapport à la boîte de retrait DF3, etc. Un tel message MSG est par exemple de type beacon, « notification push», UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc...
Les données/informations INF1 peuvent également correspondre à une interprétation faite par le smartphone OC3des données issues de ses différents capteurs CAP1à CAPS. Elles correspondent par exemple au nom ou à un identifiant de la boîte de retrait DF3qui ont été identifiés après analyse d’une image ou d’une vidéo capturée par un des capteurs CAP1, CAP2,…, CAPSdu smartphone OC3, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que la position géographique de la boîte de retrait DF3, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 peuvent également correspondre, dans ce contexte d’utilisation :
- à une vitesse mesurée par un des capteurs CAP1, CAP2,…, CAPSdu smartphone OC3, typiquement un accéléromètre,
- aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) du smartphone OC3qui sont mesurées par un des capteurs CAP1, CAP2,…, CAPSde la montre OC3, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la , les données/informations INF2 de fonctionnement du smartphone OC3correspondent par exemple à la date et l’heure courante, au mode de fonctionnement courant du smartphone OC3(allumé, éteint, mode avion, en veille, etc.).
Dans le contexte d’utilisation de la , l’élément INF3 d’un historique des transactions déjà effectuées par le smartphone OC3est typiquement une information relative aux différentes commandes de bien ou de service qui ont été effectuées précédemment par l’utilisateur UT avec le smartphone OC3.
Dans le contexte d’utilisation de la , les données complémentaires de transaction DAT2 sont par exemple l’identité de l’utilisateur UT qui utilise le smartphone OC3, des données d’un profil de cet utilisateur UT (historique de navigation, répertoire, etc.) chargées dans le smartphone OC3lors de l’allumage du smartphone OC3par l’utilisateur UT, la localisation du smartphone OC3au moment où l’utilisateur UT s’est approché de la boîte de retrait DF3, un logo de l’enseigne de livraison du colis COL, l’opérateur de télécommunications en lien avec la carte eSIM MT, etc. Dans le cas où le smartphone OC3est partagé par différents utilisateurs et contient de ce fait plusieurs modules de transaction MT intégrés au smartphone OC3, ici carte eSIM, e-wallet, etc., les données complémentaires DAT2 correspondent à un identifiant de la carte eSIM, du e-wallet ou autre associé(e) à la personne identifiée au préalable, par exemple à l’aide d’un capteur biométrique du smartphone OC3.
Dans le cas où une concordance existe entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC (O sur la ), l’objet communicant OC identifie la transaction comme valide/légitime. A cet effet, il active en S5 l’envoi au dispositif de communication DC, via son module de communication MCO ou MCO’, d’une réponse REP_TR_AUT à la requête REQ_TR, ladite réponse REP_TR_AUT autorisant la transaction entre l’objet communicant OC et le dispositif de communication DC.
Dans un mode de réalisation particulier, la réponse REP_TR_AUT peut être enrichie par au moins une donnée DAT2 qui a été déterminée en S4. Ainsi la et/ou les donnée(s) DAT2 pourra/pourront être transmise(s) par le dispositif de communication DC aussi bien au gestionnaire de la transaction qu’au gestionnaire de l’objet communicant (ex : gestionnaire d’une flotte de véhicules, banque, etc., dans le cas où l’objet communicant OC est une voiture connectée OC1, régie de transport en commun dans le cas où l’objet communicant OC est une montre connectée OC2, opérateur de télécommunications ou enseigne de livraison, dans le cas où l’objet communicant OC est un smartphone OC3), ou encore au fournisseur du bien ou du service faisant l’objet de la transaction (station-service, site Internet marchand, etc.). Cette/ces donnée(s) DAT2 pourra/pourront ainsi être avantageusement exploitée(s) à des fins de traitement/archivage/traçage des transactions qui ont été effectuées par un utilisateur UT de l’objet communicant OC donné, à un instant donné.
Dans le cas où une concordance n’existe pas entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC (N sur la ), l’objet communicant OC identifie la transaction comme invalide/illégitime. A cet effet, il active en S6 l’envoi au dispositif de communication DC, via son module de communication MCO ou MCO’, d’une réponse REP_TR_REF à la requête REQ_TR, ladite réponse REP_TR_REF désignant un refus de la transaction entre l’objet communicant OC et le dispositif de communication DC. A titre d’alternative, l’objet communicant OC n’envoie aucune réponse à la requête REQ_TR et le procédé de transaction prend fin au bout d’un délai fixé au préalable, dont la durée dépend de l’implémentation effectuée.
Les étapes du procédé de contrôle d’une transaction sans contact qui viennent d’être décrites ci-dessus permettent avantageusement à tout objet connecté de vérifier si une transaction (paiement, accès, retrait de commande, etc.) avec un dispositif de communication (serveur de paiement, serveur ou portillon de contrôle d’accès, commande d’ouverture/fermeture d’une boîte de retrait de colis, d’une consigne automatique, etc…) est valide/légitime ou non, et ceci de façon complètement autonome et sécurisée.
On va maintenant décrire, en référence à la , un mode de réalisation de la comparaison mise en œuvre au cours de l’étape S3 de la pour caractériser la concordance ou la non concordance entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC. Une telle comparaison est mise en œuvre à l’aide d’un outil de traitement informatique, de type intelligence artificielle.
La comparaison S3 comprend à cet effet une sous-étape S30 au cours de laquelle des informations de contexte d’utilisation de référence ICURefsont combinées.
Ces informations de contexte d’utilisation de référence ICURefpeuvent prendre différentes formes. Il peut s’agir par exemple :
- d’informations caractérisant une situation de transaction sans contact d’un objet communicant comme étant valide/légitime et qui a été apprise au préalable, par exemple à l’aide d’un réseau de neurones, et/ou
- de règles écrites à priori selon lesquelles les données DAT1 et/ou les données de contexte d’utilisation DCU vont être combinées d’une manière particulière, à l’aide par exemple d’un système expert, et/ou
- d’une mise en commun de situations de transaction sans contact détectées au préalable pour ce qui concerne l’objet communicant OC, dans un contexte de transaction sans contact similaire ou identique (ex : cas où l’objet communicant OC est partagé par d’autres utilisateurs que l’utilisateur UT),
- etc.
A l’issue de la sous-étape S30 est obtenu un score de fiabilité présentant une valeur V.
En S31, les données DAT1 et les données de contexte d’utilisation DCU sont combinées.
En S32, un score de fiabilité SC est attribué au résultat de cette combinaison.
En S33, le score SC est comparé à la valeur V obtenue en S30 qui est considérée en tant que valeur de référence.
Selon un mode de réalisation, 0≤V≤1. D’autres valeurs d’encadrement sont bien entendu possibles en fonction de l’implémentation du procédé de contrôle de transaction sans contact. Une convention établit par exemple que V=0,6 et qu’au-delà de cette valeur de référence V, l’objet communicant OC se trouve dans une situation de transaction valide/légitime.
Si SC>V (ou SC≥V selon la convention établie) (O sur la ), l’étape S5 d’activation de réception des requêtes d’appairage est déclenchée. Si SC≤V (ou SC<V selon la convention établie) (N sur la ), l’étape S6 de cessation du procédé de contrôle de transaction ou d’envoi d’une réponse REP_TR_REF refusant la transaction est mise en œuvre.
Dans un mode de réalisation particulier, selon la valeur du score SC, et en particulier si la valeur du score SC est très proche de la valeur de référence V, en dessous ou au-dessus, des données complémentaires peuvent être utilisées pour affiner la comparaison S3, telles que par exemple les données d’une base externe de fraudes connues (pour détecter une situation de transaction à risque), des données fournies par l’utilisateur UT s’il est présent au moment de la mise en œuvre de la comparaison S3, des données correspondant à la sélection d’un module de transaction MT spécifique (par exemple un module de transaction bénéficiant d’une assurance particulière, un module de transaction ayant un identifiant particulier IDGT qui autorise la gratuité des transports en commun, etc.).
Dans le contexte de transaction de la , où l’objet communicant OC est une voiture électrique connectée OC1qui souhaite payer de manière autonome la recharge de sa batterie, les informations de contexte d’utilisation DCU déterminées sont par exemple :
- la vitesse de la voiture OC1est nulle,
- le moteur de la voiture OC1est coupé,
- le niveau de la batterie est faible,
- la catégorie «borne de recharge» est identifiée dans un message MSG.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le montant du paiement de la recharge.
Ces informations sont comparées en S3 à une situation d’apprentissage qui a été modélisée avec des informations de contexte d’utilisation de référence ICURefdu même type ou d’un type similaire aux informations de contexte d’utilisation DCU et aux données DAT1 et qui a déjà été évaluée au préalable dans un contexte d’utilisation identique ou similaire:
- pour la voiture OC1, ou
- pour une autre voiture ou tout autre type de véhicule appartenant par exemple à une flotte de véhicules à laquelle appartient la voiture OC1.
Ainsi, si en S31, toutes les informations de contexte d’utilisation DCU et les données de transaction DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- la vitesse de la voiture OC1est nulle,
- le moteur de la voiture OC1est coupé,
- le niveau du réservoir d’essence est faible,
- la catégorie «parking» est identifiée dans un message MSG,
et que les données DAT1 sont par exemple la date et l’heure de la journée, ainsi que le montant du paiement d’une baguette de pain,
alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1.
Dans le contexte d’utilisation de la , où l’objet communicant OC est une montre connectée OC2, les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom de l’arrêt de bus,
- des données de géolocalisation de la montre connectée par rapport à cet arrêt,
- l’identifiant de la ligne qui est indiqué par exemple sur le bus qui s’approche,
- une vitesse de la montre connectée qui décroit,
- etc.
Les données DAT1 sont par exemple un identifiant d’un portillon qui commence par la lettre « B » pour indiquer que le moyen de transport emprunté est un bus,
- la catégorie du moyen de transport emprunté : « bus »,
- le prix de l’accès à ce bus.
Ces informations sont comparées à une situation d’apprentissage qui a été modélisée avec des informations de contexte d’utilisation de référence ICURefdu même type ou d’un type similaire aux informations de contexte d’utilisation DCU et qui a déjà été évaluée au préalable dans un contexte d’utilisation d’un moyen de transport identique ou similaire et représentatif des habitudes de déplacement en transport en commun de l’utilisateur UT ou d’un autre utilisateur qui partage la montre connectée OC2avec l’utilisateur UT.
Ainsi, si en S31, toutes les informations de contexte d’utilisation DCU et les données de transaction DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom d’une station de métro diffusé dans un message MSG,
- des données de géolocalisation de la montre connectée par rapport à un arrêt de bus,
- l’identifiant d’un bus qui ne passe pas par l’arrêt de bus correspondant aux données de géolocalisation,
- une vitesse de la montre connectée qui décroit,
- etc.
et que les données DAT1 sont par exemple la date et l’heure de la journée, ainsi que le montant d’un billet de train,
alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1.
Dans le contexte d’utilisation de la où l’objet communicant OC est un smartphone OC3, les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom ou un identifiant de la boîte de retrait DF3diffusé dans un message MSG,
- un logo de l’enseigne de livraison du colis COL,
- des données de l’historique de navigation du smartphone OC3 montrant que l’utilisateur UT a commandé un bien ou un service particulier à une date donnée.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le prix de la commande à retirer et un nombre d’articles correspondant à la commande qui est égal à 3.
Cette ou ces information(s) est/sont comparée(s) à une situation d’apprentissage qui a été modélisée avec une ou des informations de contexte d’utilisation de référence ICURefdu même type ou d’un type similaire aux informations de contexte d’utilisation DCU et qui a déjà été évaluée au préalable dans un contexte d’utilisation identique ou similaire qui définit les lieux de retrait de colis où l’utilisateur UT se rend le plus souvent, une cinématique de commande connue de l’utilisateur UT ou d’un autre utilisateur partageant le smartphone OC3avec l’utilisateur UT, etc.
Ainsi, si en S31, toutes les informations de contexte d’utilisation DCU et les données DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom ou un identifiant de la boîte de retrait DF3diffusé dans un message MSG,
- un logo d’une enseigne de livraison du colis COL qui n’est pas habilitée pour livrer dans la boîte de retrait DF3correspondant à l’identifiant ou au nom précité,
- des données de l’historique de navigation du smartphone OC3montrant que l’utilisateur UT a effectué la commande d’un unique article.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le prix de la commande à retirer qui correspond à un nombre d’articles égal à 3,
alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1.

Claims (13)

  1. Procédé de contrôle d’une transaction sans contact entre un objet communicant (OC) et un dispositif de communication (DC), au cours duquel l’objet communicant reçoit (S1) en provenance du dispositif de communication une requête contenant des données relatives à la transaction, le procédé étant caractérisé en ce que l’objet communicant exécute de manière autonome ce qui suit :
    - extraire (S2) de ladite requête reçue des informations (DAT1) relatives à la transaction,
    - comparer (S3) les informations extraites à des données de contexte d’utilisation (DCU) de l’objet communicant qui ont été déterminées par l’objet,
    - activer (S5) l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
  2. Procédé de contrôle d’une transaction selon la revendication 1, dans lequel en l’absence d’une concordance entre les informations relatives à la transaction et les données de contexte d’utilisation, l’objet communicant active (S6) l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction, ou ne répond pas à la requête.
  3. Procédé de contrôle d’une transaction selon la revendication 1 ou la revendication 2, dans lequel au cours de la comparaison des informations extraites avec lesdites données de contexte d’utilisation, au moins une donnée complémentaire (DAT2) relative à la transaction est déterminée (S4), ladite au moins une donnée complémentaire étant ajoutée dans la réponse à la requête autorisant la transaction.
  4. Procédé de contrôle d’une transaction selon la revendication 3, dans lequel lorsque la transaction est un paiement et que l’objet communicant comprend au moins deux moyens de paiement associés respectivement à deux utilisateurs différents, la au moins une donnée complémentaire est un identifiant du moyen de paiement associé à l’utilisateur de l’objet au moment de la transaction.
  5. Procédé de contrôle d’une transaction selon la revendication 1 ou la revendication 2, dans lequel la comparaison des informations extraites avec lesdites données de contexte d’utilisation comprend ce qui suit :
    - générer (S32) un score de fiabilité de la comparaison,
    - comparer (S33) le score généré à un seuil (V),
    - en fonction du résultat de la comparaison :
    • activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction,
    • activer l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction ou ne pas répondre à la requête.
  6. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation de l’objet communicant sont représentatives d’un environnement dans lequel se trouve l’objet communicant ou contiennent au moins une donnée de fonctionnement de l’objet communicant.
  7. Procédé de contrôle d’une transaction selon la revendication 6, dans lequel la au moins une donnée de fonctionnement de l’objet communicant est un paramètre de fonctionnement courant relevé par l’objet communicant ou un élément d’un historique des transactions effectuées par l’objet communicant.
  8. Procédé de contrôle d’une transaction selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant sont contenues dans un message reçu par l’objet communicant en provenance du dispositif de communication ou d’un dispositif d’émission de message situé dans ledit environnement.
  9. Procédé de contrôle d’une transaction selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant contiennent une donnée issue d’au moins un capteur appartenant à l’objet communicant.
  10. Objet communicant (OC) ayant des capacités de contrôle d’une transaction sans contact avec un dispositif de communication, ledit objet communicant comprenant un processeur (PROC) qui est configuré pour recevoir en provenance du dispositif de communication une requête contenant des données relatives à la transaction, caractérisé en ce que le processeur de l’objet communicant exécute de manière autonome ce qui suit :
    - extraire de la requête reçue des informations relatives à la transaction,
    - comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
    - activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
  11. Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé de communication sans contact selon l’une quelconque des revendications 1 à 9, lorsqu'il est exécuté sur un ordinateur.
  12. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 11.
  13. Système de contrôle d’une transaction sans contact, caractérisé en ce qu’il comprend :
    - un objet communicant selon la revendication 10,
    - un dispositif de communication sans contact qui est configuré pour envoyer à l’objet communicant une requête contenant des données relatives à la transaction.
FR2107284A 2021-07-06 2021-07-06 Procédé de contrôle d’une transaction sans contact et objet communicant correspondant Withdrawn FR3125152A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2107284A FR3125152A1 (fr) 2021-07-06 2021-07-06 Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
EP22741348.1A EP4367620A1 (fr) 2021-07-06 2022-06-17 Procédé de controle d'une transaction sans contact et objet communicant correspondant
PCT/FR2022/051183 WO2023281178A1 (fr) 2021-07-06 2022-06-17 Procédé de controle d'une transaction sans contact et objet communicant correspondant

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2107284A FR3125152A1 (fr) 2021-07-06 2021-07-06 Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
FR2107284 2021-07-06

Publications (1)

Publication Number Publication Date
FR3125152A1 true FR3125152A1 (fr) 2023-01-13

Family

ID=77180251

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2107284A Withdrawn FR3125152A1 (fr) 2021-07-06 2021-07-06 Procédé de contrôle d’une transaction sans contact et objet communicant correspondant

Country Status (3)

Country Link
EP (1) EP4367620A1 (fr)
FR (1) FR3125152A1 (fr)
WO (1) WO2023281178A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2106702A5 (fr) 1970-09-21 1972-05-05 Inst Francais Du Petrole
US20140095385A1 (en) * 2012-09-28 2014-04-03 Alex Ainslie Selecting merchants for automatic payments
US20190007385A1 (en) * 2017-06-29 2019-01-03 Motorola Mobility Llc Sending verification password responsive to mobile device proximity
US10803440B1 (en) * 2016-02-16 2020-10-13 State Farm Mutual Automobile Insurance Company Connected car as a payment device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2106702A5 (fr) 1970-09-21 1972-05-05 Inst Francais Du Petrole
US20140095385A1 (en) * 2012-09-28 2014-04-03 Alex Ainslie Selecting merchants for automatic payments
US10803440B1 (en) * 2016-02-16 2020-10-13 State Farm Mutual Automobile Insurance Company Connected car as a payment device
US20190007385A1 (en) * 2017-06-29 2019-01-03 Motorola Mobility Llc Sending verification password responsive to mobile device proximity

Also Published As

Publication number Publication date
EP4367620A1 (fr) 2024-05-15
WO2023281178A1 (fr) 2023-01-12

Similar Documents

Publication Publication Date Title
EP2537286B1 (fr) Procédé d&#39;authentification biométrique, système d&#39;authentification et programme correspondant
WO2018055156A1 (fr) Système d&#39;acheminement d&#39;objets, mettant en oeuvre un système de diffusion ciblée d&#39;informations
EP3196815A1 (fr) Procede de detection de passagers, de gestion et d&#39;optimisation de leurs transports partages
EP2929496A2 (fr) Gestion securisee d&#39;une transaction de prestation de service
WO2014102047A1 (fr) Procédé de lutte contre la fraude, et système correspondant
WO2018073104A1 (fr) Système d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, procédant à un contrôle du contenu par imagerie lors du transfert de l&#39;emballage entre individus
WO2009056757A2 (fr) Système de transport public urbain
FR3125152A1 (fr) Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
EP3220328B1 (fr) Système d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, utilisant un signal de prise en responsabilité de l&#39;emballage par un individu
FR3052895B1 (fr) Procede d&#39;envoi d&#39;une information de securite
EP4360339A1 (fr) Procédé de communication sans contact entre un objet communicant et un dispositif de communication
WO2017157718A1 (fr) Système d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, utilisant un signal de prise en responsabilité de l&#39;emballage par un individu
EP3067709A1 (fr) Procédé et dispositif de suivi d&#39;individus dans un lieu équipé de moyens répartis de détection
EP4199547A1 (fr) Traitement de données perfectionné pour un covoiturage efficace
WO2023209302A1 (fr) Procédé et dispositif de contrôles numériques de la livraison d&#39;un objet d&#39;un premier véhicule à un deuxième véhicule
FR3049096A1 (fr) Procede de gestion de transport d’un objet
EP1214686A1 (fr) Dispositif electronique portatif avec afficheur et moyens de chargement de messages pour ce dernier
BE1023888B1 (fr) Inspection de frontière avec des caméras aériennes
FR3123482A1 (fr) Procédé et dispositif d’obtention d’une empreinte carbone de livraison d’un colis
EP4091150A1 (fr) Procede et systeme pour incorporer des positions geographiques de vehicules disponibles a la reservation dans une carte numerique
EP4437479A1 (fr) Procédé d&#39;établissement d&#39;une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)
FR3129756A1 (fr) Procédé et dispositif de contrôle de livraison d’un objet d’un premier véhicule à un deuxième véhicule
EP4254286A1 (fr) Système d&#39;acheminement d&#39;objets contenus dans des boîtes sur lesquelles sont prévus des moyens d&#39;identification du destinataire
WO2020144362A1 (fr) Dispositif electronique portable d&#39;acces a un espace, systeme et procedes associes
FR3136623A1 (fr) Procédé de communication entre un objet communicant et un dispositif de communication

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20230113

ST Notification of lapse

Effective date: 20240306