Titre : Procédé d’établissement d’une transaction entre un objet communicant et un module de contrôle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)

Domaine de l'invention

L'invention se rapporte de manière générale au domaine des technologies utilisées pour la mise en œuvre de transactions telles que par exemple des transactions bancaires effectuées dans le cadre de services de paiement qui utilisent des terminaux de paiement avec ou sans contact, des transactions de contrôle d’accès effectuées dans le cadre de services d’accès, par exemple d’accès à un moyen de transport ou à un lieu sécurisé, qui utilisent des terminaux de contrôle d’accès avec ou sans contact, etc. De tels terminaux sont configurés pour accepter un moyen d’accès au service mettant en œuvre une transaction. Dans le cadre d’une transaction bancaire par exemple, un tel moyen d’accès peut communiquer, par exemple par contact, avec le terminal de paiement, ledit moyen d’accès étant typiquement une carte bancaire à puce, ou peut communiquer sans contact avec le terminal de paiement, ledit moyen d’accès étant alors typiquement une carte bancaire sans contact, par exemple de type NFC (de l’anglais « Near Field Communication »), un téléphone mobile muni d’un dispositif NFC, etc. De manière analogue, dans le cadre d’une transaction de contrôle d’accès, un tel moyen d’accès, peut communiquer par exemple par contact avec le terminal de contrôle d’accès, ledit moyen d’accès étant typiquement un badge ou une carte à puce, ou peut communiquer sans contact avec le terminal de contrôle d’accès, ledit moyen d’accès étant alors typiquement une carte ou un badge de type NFC, un téléphone mobile muni d’un dispositif NFC, etc.

Plus précisément, l'invention porte sur l’appairage entre un terminal de communication du type précité et un objet communicant doté d’un moyen d’accès à un service de transaction du type précité, un tel objet communicant étant par exemple un véhicule connecté, un smartphone (« téléphone intelligent »), une montre connectée, etc.

Art antérieur Actuellement, pour payer un bien ou un service à l’aide d’un objet communicant du type précité, il est nécessaire de se rapprocher physiquement d’un lecteur de moyens de paiement associé au terminal de paiement, de manière à ce que le lecteur puisse lire le moyen de paiement utilisé, qu’il soit sans contact ou non.

Ainsi, lorsque l’objet communicant est par exemple un smartphone utilisé en tant que moyen de paiement, l’utilisateur du smartphone qui souhaite interagir avec un terminal de paiement accessible du fournisseur du bien ou du service à payer est systématiquement obligé de faire certaines actions pour rapprocher son smartphone du lecteur du terminal de paiement. De telles actions se compliquent lorsque l’utilisateur est un occupant d’un véhicule, par exemple le conducteur, l’utilisateur étant obligé :

- soit de sortir du véhicule, lorsque par exemple le terminal de paiement est intégré à un automate de pompe à essence par exemple,

- soit de baisser la vitre de son véhicule pour interagir avec un terminal de paiement électronique (TPE) qui est disposé ou manipulé pour être accessible à l’utilisateur conducteur (par exemple, une borne de paiement de péage autoroutier ; un TPE marchand fixé au comptoir ou tendu par le préposé lors du paiement d’un bien ou d’un service en drive-in (cinéma en plein air, vente à emporter, etc.).

De telles interactions avec les terminaux de paiement présentent les inconvénients suivants :

- un manque d’ergonomie, puisqu'il est parfois nécessaire de sortir du véhicule pour présenter son moyen de paiement, ou de manœuvrer le véhicule de façon assez précise pour pouvoir atteindre ensuite le TPE (faute de quoi il faut pouvoir ouvrir la portière pour sortir et accéder difficilement au TPE),

- un manque de sécurité, car un automate de paiement disposé dans un espace public peut être observé pour intercepter un code secret par exemple, et peut être plus facilement piraté par une personne malintentionnée pour intercepter des secrets échangés lors de la transaction.

Dans le cas d’un service de contrôle d’accès, ce manque d’ergonomie et de sécurité est également constaté. En effet, dans le cas par exemple de l’accès à un bus ou à un tramway, il est parfois difficile, notamment en cas d’affluence ou pour une personne à mobilité réduite, d’accéder au lecteur du terminal de contrôle d’accès, généralement installé dans le bus ou le tramway, pour présenter sa carte de transport et ainsi valider son trajet. Et comme il s’agit de transports publics, le piratage précité peut également être mis en œuvre de manière similaire à un service de paiement.

Par ailleurs, compte tenu du fait que les terminaux de communication utilisés pour la mise en œuvre d’une transaction du type précité sont matériels et intègrent ou sont associés à un lecteur de moyens d’accès à un service de transaction, ces terminaux représentent des coûts importants pour les fournisseurs de bien(s) ou de service(s) en termes d’investissement, de maintenance, de renouvellement, de pannes, de dégradations, etc.

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 communicant ou connecté d’effectuer une transaction à l’aide d’un moyen d’accès au service dans lequel la transaction est mise en œuvre, en l’absence de tout terminal physique de contrôle de la transaction, tel qu’un terminal de paiement du type TPE, un dispositif matériel de contrôle d’accès associé à une borne ou à un portillon d’accès à un moyen de transport ou à un lieu sécurisé ou non, etc.

A cet effet, un objet de la présente invention concerne un procédé d’établissement d’une transaction à l’aide d’un objet communicant pour la mise en œuvre d’une fourniture d’un bien ou d’un service à un utilisateur, au cours duquel l’objet communicant reçoit une requête contenant des données relatives à la transaction en provenance d’un dispositif de fourniture du bien ou du service ou d’un module de contrôle de la transaction associé au dispositif.

Un tel procédé est remarquable en ce que l’objet communicant met en œuvre ce qui suit :

- recevoir en provenance du module ou du dispositif, un message requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de la transaction est associé à l’objet communicant,

- un lecteur étant associé à l’objet communicant, lire des données d’identification d’un moyen d’accès audit service, à l’aide du lecteur,

- transmettre les données d’identification lues au module logiciel de contrôle de ladite transaction pour valider la transaction. L’invention propose avantageusement de réaliser une communication entre un lecteur associé à l’objet communicant et un module de contrôle de transaction associé au fournisseur du bien ou du service, ce qui permet au fournisseur du bien ou du service de se passer d’un terminal physique muni d’un lecteur et configuré pour accepter un moyen d’accès au service mettant en œuvre une transaction, ce qui est beaucoup moins coûteux pour ce fournisseur. Ainsi, par exemple, lors d’une transaction de type bancaire, l’invention permet de reconstituer à la volée un terminal de paiement du type TPE pour lequel la partie logicielle qui traite le paiement est associée au dispositif de fourniture du bien ou du service (ex : une pompe à essence, un guichet de vente à emporter, etc.) et la partie qui traite la lecture d’un moyen de paiement avec ou sans contact est associée à l’objet communicant. Selon un autre exemple, dans le cas d’une transaction de type contrôle d’accès, il est possible de reconstituer à la volée une borne d’accès pour laquelle la partie logicielle qui traite l’autorisation d’accès est associée au dispositif de fourniture du bien ou du service (ex : un bus, un portillon d’accès à une bibliothèque, une barrière d’accès à un parking, etc.), et la partie qui traite la lecture d’un moyen d’accès avec ou sans contact est associée à l’objet communicant.

Par ailleurs, la transaction est beaucoup plus facile à mettre en œuvre pour l’utilisateur que dans l’art antérieur, puisqu’il n’est plus nécessaire que l’utilisateur se déplace vers le lecteur pour mettre en œuvre la transaction, étant donné que ce lecteur est associé à l’objet communicant dont l’utilisateur est doté.

Selon un mode de réalisation particulier, avant l’étape de lecture, le procédé met en œuvre une étape d’authentification mutuelle entre le lecteur associé à l’objet communicant et le module de contrôle de la transaction.

Une telle authentification mutuelle revient à réaliser avantageusement, à chaque transaction, un appairage dynamique entre le lecteur côté objet communicant et le module logiciel de contrôle de transaction instancié côté fournisseur de bien(s) ou de service(s). La transaction est ainsi beaucoup plus flexible pour l’utilisateur que dans l’art antérieur, puisque l’objet communicant dont il dispose est associé à un lecteur générique qui est configuré pour lire différents types de moyens d’accès à un service de mise en œuvre d’une transaction, tels que des cartes de paiement, des cartes de transport, etc. et qui est apte à fonctionner indépendamment du type de fournisseur de bien(s) ou de service(s) (une station-service, une enseigne de vente à emporter, un parking privatif, etc.), grâce à cet appairage dynamique avec un module de contrôle de la transaction associé au dispositif de fourniture du bien ou du service et non avec ce dispositif lui-même.

Selon un autre mode de réalisation particulier, le procédé d’établissement d’une transaction selon l’invention comprend ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de ladite étape d’authentification :

- recevoir, en provenance du module de contrôle de la transaction, un identifiant dudit module,

- vérifier la validité de l’identifiant,

- l’identifiant étant valide, transmettre un identifiant du lecteur au module de contrôle de transaction,

- l’identifiant dudit lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, authentifier mutuellement le lecteur et le module de contrôle de la transaction.

Dans ce mode de réalisation, c’est le module de contrôle de la transaction côté fournisseur du bien ou du service qui est à l’initiative de l’appairage avec le lecteur associé à l’objet communicant.

Selon un autre mode de réalisation particulier, le procédé d’établissement d’une transaction selon l’invention comprenant ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de l’étape d’authentification :

- transmettre au module de contrôle de la transaction un identifiant du lecteur,

- l’identifiant du lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, recevoir, en provenance du module, un message contenant un identifiant du module,

- vérifier la validité de l’identifiant du module,

- l’identifiant du module étant valide, authentifier mutuellement le lecteur et le module de contrôle de la transaction.

Dans ce mode de réalisation, c’est le lecteur côté objet communicant qui est à l’initiative de l’appairage avec le module de contrôle de la transaction côté fournisseur du bien ou du service.

Selon un autre mode de réalisation particulier, l’identifiant du lecteur ainsi que l’identifiant du module de contrôle de la transaction sont transmis à l’aide d’un mécanisme de chiffrement. Un tel mode de réalisation permet d’optimiser la sécurité de l’appairage entre le lecteur côté objet communicant et le module de contrôle de la transaction côté fournisseur du bien ou du service.

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é d’établissement d’une transaction défini ci-dessus.

L'invention concerne également un objet communicant pour l’établissement d’une transaction mettant en œuvre une fourniture d’un bien ou d’un service à un utilisateur, ledit objet communicant comprenant un processeur qui est configuré pour recevoir une requête contenant des données relatives à la transaction en provenance d’un dispositif de fourniture du bien ou du service ou d’un module de contrôle de la transaction associé audit dispositif.

Un tel objet communicant est remarquable en ce que le processeur de l’objet communicant met en œuvre ce qui suit :

- recevoir en provenance du module ou du dispositif, un message requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de la transaction est associé à l’objet communicant,

- un lecteur étant associé à l’objet communicant, lire des données d’identification d’un moyen d’accès au service, à l’aide du lecteur,

- transmettre les données d’identification lues au module logiciel de contrôle de la transaction pour valider la transaction.

L'invention concerne également un système d’établissement d’une transaction. Un tel système est remarquable en ce qu’il comprend :

- un objet communicant mettant en œuvre le procédé d’établissement d’une transaction précité,

- un module de contrôle de la transaction qui est associé à un dispositif de fourniture de bien(s) ou de service(s).

L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’établissement d’une transaction 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é d’établissement d’une transaction 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 (« Read Only Memory » en anglais), par exemple un CD ROM (« Compact Disc Read-Only Memory » en anglais) 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 (« Solid State-Drive » en anglais). 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é d’établissement d’une transaction 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.

Brève description des dessins

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 figure 1 représente un exemple d’architecture dans laquelle le procédé d’établissement d’une transaction selon l’invention est mis en œuvre,

La figure 2 représente un objet communicant dans un mode de réalisation de l’invention,

La figure 3 représente les principales actions mises en œuvre dans le procédé d’établissement d’une transaction, selon un mode de réalisation particulier de l’invention,

La figure 4A représente un mode de réalisation d’une étape d’authentification mise en œuvre dans le procédé d’établissement d’une transaction selon l’invention, La figure 4B représente un autre mode de réalisation d’une étape d’authentification mise en œuvre dans le procédé d’établissement d’une transaction selon l’invention, La figure 5A représente un système d’établissement d’une transaction selon un premier mode de réalisation de l'invention,

La figure 5B représente un système d’établissement d’une transaction selon un deuxième mode de réalisation de l'invention,

La figure 5C représente un système d’établissement d’une transaction selon un troisième mode de réalisation de l'invention.

Description détaillée de modes de réalisation de l’invention

En référence à la figure 1 , est décrit un exemple d’architecture dans laquelle le procédé d’établissement d’une transaction selon l’invention est mis en œuvre. Selon cette architecture, un système d’établissement d’une transaction comprend :

- un objet connecté ou communicant OC associé à un utilisateur UT,

- un environnement EVF de fourniture de bien(s) ou de service(s) à l’utilisateur UT. On appelle objet communicant ou connecté OC 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 loT (« Internet of Things » en anglais).

Conformément à l’invention, un tel objet communicant OC comprend un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE (« Long Term Evolution » en anglais), WiFi, DSRC

(« Dedicated Short Flange Communication » en anglais), C-V2X (« Cellular Vehicle To Everything » en anglais), etc.

De façon particulièrement avantageuse, l’objet communicant OC est associé à un lecteur LECT qui est configuré pour lire des données d’identification d’un moyen MAST d’accès à un service de mise en œuvre de la transaction. Le moyen d’accès MAST peut-être un support physique porté par l’utilisateur UT (ex : carte bancaire, badge de transport, étiquette de livraison de colis, etc.) ou un support logiciel intégré à l’objet communicant OC (ex : carte de paiement dématérialisée, carte de transport dématérialisée, porte-monnaie électronique, etc.). Le lecteur LECT est par ailleurs configuré pour communiquer avec le module de communication COMo.

L’environnement EVF de fourniture de bien(s) ou de service(s) comprend quant à lui, de manière correspondante à l’objet communicant OC, un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.

L’environnement EVF comprend en outre :

- un dispositif DF de fourniture d’un bien ou d’un service à l’utilisateur UT,

- un module MET d’enregistrement et de traitement de la transaction pour la fourniture de bien(s) ou de service(s),

- un module MCT de contrôle de la transaction associé au dispositif DF de fourniture de bien(s) ou de service(s).

Le module MCT de contrôle de la transaction est associé au dispositif DF de fourniture de bien(s) ou de service(s) et/ou au module MET d’enregistrement et de traitement de la transaction, en ce sens qu’il peut être soit intégré au dispositif DF de fourniture de bien(s) ou de service(s) ou au module MET d’enregistrement et de traitement de la transaction, soit situé dans un environnement de virtualisation mis à disposition du fournisseur du bien ou du service par un opérateur de télécommunications, selon par exemple la technologie MEC (« Mobile Edge Computing » en anglais).

Le module MCT de contrôle de la transaction, le dispositif DF de fourniture de bien(s) ou de service(s), le module MET d’enregistrement et de traitement de la transaction, sont configurés pour communiquer entre eux.

Le module MCT de contrôle de la transaction est par ailleurs configuré pour communiquer, à l’aide de tout type de communication adapté et via le module MET d’enregistrement et de traitement de la transaction, avec un environnement EGT de gestion de la transaction qui, dans l’exemple représenté, est symbolisé par un serveur SERV de gestion de la transaction. Bien entendu, il peut s’agir de plusieurs serveurs en réseau en fonction du type de transaction mise en œuvre. Description d’un mode de réalisation de l’objet communicant OC

La figure 2 présente la structure simplifiée de l’objet communicant OC configuré pour mettre en œuvre le procédé d’établissement d’une transaction qui va être décrit ci- dessous.

Un tel objet communicant comprend selon l’invention :

- un module de communication COMo 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.,

- une interface utilisateur IU configurée pour recevoir des informations en provenance de l’utilisateur UT ou restituer des informations à l’utilisateur sous forme textuelle, visuelle et/ou sonore : il peut s’agir par exemple d’un écran d’affichage, d’un clavier et/ou d’un haut-parleur intégré à l’objet communicant OC,

- un lecteur LECT du type précité qui comporte :

-- une partie matérielle HARD, telle que par exemple une ouverture apte à recevoir un moyen d’accès MAST, ainsi qu’éventuellement un clavier ou une interface avec le clavier de l’interface utilisateur IU, ou encore une surface de communication sans contact, par exemple de type NFC,

-- une partie logicielle SOFT apte à communiquer avec :

- un module d’authentification AUT qui est configuré pour authentifier le module MCT de contrôle de la transaction de l’environnement EVF de fourniture de bien(s) ou de service(s) avec lequel l’objet communicant OC souhaite mettre en œuvre la transaction,

- un module ACC d’accès à une mémoire MEMi qui contient des données d’identification de moyens d’accès MAST à un service de mise en œuvre de la transaction, dans le cas où de tels moyens sont envisagés sous forme numérique ou dématérialisée.

A titre d’exemples non exhaustifs, la partie logicielle SOFT du lecteur LECT peut être :

- un élément sécurisé (« Secure Element » en anglais) : cet élément sécurisé peut se présenter par exemple sous la forme d’une eSIM (« Embedded Subscriber Identification Module » en anglais) qui est fournie par un opérateur de télécommunications ou le fabricant de l’objet communicant OC ; - une application sécurisée par exemple du type SAM (« Secured Applications for Mobile » en anglais) proposé par la GSM Association (« Global System for Mobile Communications » en anglais).

Le lecteur LECT est associé à l’objet communicant OC en ce sens que la partie HARD du lecteur LECT peut être intégrée à l’objet communicant OC ou être une partie autonome qui est reliée à l’objet communicant OC par tout moyen de connexion adapté, filaire ou sans fil.

Sur la figure 2, la mémoire MEMi n’est pas obligatoirement contenue dans l’objet communicant OC afin de préserver les ressources mémoire de celui-ci. A cet effet, la mémoire MEMi peut être déportée dans un réseau de communication sécurisé, un nuage (« cloud » en anglais) sécurisé, etc. et est rendue accessible par l’objet communicant OC, au moyen du module ACC dédié à cet effet. En variante, la mémoire MEMi ou une partie de celle-ci pourrait être intégrée à l’objet communicant OC.

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é d’établissement d’une transaction 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 communication sans contact via le module COMo, les actions de lecture de données d’identification du moyen d’accès MAST via le lecteur LECT, les actions d’authentification à l’aide du module d’authentification AUT. Description d’un mode de réalisation d’un procédé d’établissement d’une transaction

On décrit maintenant, en relation avec la figure 3, le déroulement d’un procédé d’établissement d’une transaction exécuté par un objet communicant OC tel qu’illustré en figure 2.

Une telle transaction est établie lors d’une communication préalable sans contact entre l’objet communicant OC et le dispositif DF de fourniture de bien(s) ou de service(s) précité. L’objet de la transaction est par exemple un bien ou un service fourni par le dispositif DF de fourniture de bien(s) ou de service(s) à l’utilisateur UT de l’objet communicant OC.

En préalable au déroulement du procédé d’établissement d’une transaction 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(s) ou de service(s) et que l’établissement d’un canal de communication de façon sécurisée a été réalisé en S0 pour mettre en œuvre la transaction entre l’objet communicant OC et l’environnement EVF de fourniture de bien(s) ou de service(s). L’établissement d’un tel canal de communication sécurisée est mis en œuvre à l’aide des modules de communication COMret COMo illustrés à la figure 1 . 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é d’établissement d’une transaction se déroule alors comme suit.

Dans l’environnement EVF, le module MCT de contrôle de la transaction et/ou le module MET d’enregistrement et de traitement de la transaction vérifient en S1 que le dispositif DF de fourniture de bien(s) ou de service(s) est opérationnel.

En S2, le module de contrôle de la transaction MCT ou le dispositif DF de fourniture de bien(s) ou de service(s) envoie à l’objet communicant OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si l’objet communicant OC contient un lecteur LECT.

L’objet communicant OC reçoit la requête REQ_LECT en S3.

L’objet communicant OC contenant un tel lecteur LECT, une authentification mutuelle est alors exécutée en S4, via le module d’authentification AUT de la figure 2, entre le module MCT de contrôle de la transaction et le lecteur LECT. Une telle étape S4 est mise en œuvre en fonction de la nature plus ou moins sécurisée de la transaction.

Elle est donc optionnelle. Dans le cas d’une transaction du type paiement, l’étape S4 est obligatoire. Pour d’autres types de transaction, par exemple l’accès à un local non sécurisé, l’étape S4 peut être optionnelle.

En S5, le module MCT de contrôle de la transaction ou le dispositif DF de fourniture de bien(s) ou de service(s) envoie alors à l’objet communicant OC, via le canal sécurisé établi en S0, une requête REQ_TR contenant des données DAT relatives à une transaction. Il peut s’agir d’un message demandant à l’utilisateur UT de présenter son moyen d’accès MAST au lecteur LECT et/ou d’un message contenant le type de bien et/ou de service, sa valeur, son montant, etc.

L’objet communicant OC reçoit la requête REQ_TR en S6.

En S7, l’interface utilisateur IU est alors activée pour informer l’utilisateur UT sur le contenu des données DAT et demander à l’utilisateur UT d’interagir avec le lecteur LECT, via un moyen d’accès MAST disponible.

Au cours de cette interaction, le lecteur LECT lit en S8 des données d’identification IDMAST du moyen d’accès MAST.

Une telle lecture est mise en œuvre par exemple suite à une communication sans contact, par exemple NFC, entre le moyen d’accès MAST et le lecteur LECT.

Dans un autre exemple, une telle lecture est mise en œuvre suite à l’introduction du moyen d’accès MAST dans une ouverture dédiée du lecteur LECT et à la saisie éventuelle par l’utilisateur UT d’un mot de passe MP au moyen du clavier de l’interface utilisateur IU ou du clavier intégré à la partie matérielle HARD du lecteur LECT.

Selon encore un autre exemple, dans le cas où le moyen d’accès MAST est numérique ou dématérialisé, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à ce moyen d’accès MAST, dans la mémoire MEMi de l’objet communicant OC.

En S9, l’objet communicant OC envoie au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une réponse REP_TR à la requête REQ_TR, ladite réponse REP_TR contenant les données d’identification IDMAST du moyen d’accès MAST. En S10, le module MCT de contrôle de la transaction reçoit la réponse REP TR et la transaction est alors validée de manière classique sur la base des données d’identification IDMAST du moyen d’accès MAST qui ont été reçues, et en liaison avec l’environnement EGT de gestion de la transaction, via le module MET d’enregistrement et de traitement de la transaction.

Grâce au procédé d’établissement d’une transaction qui vient d’être décrit ci-dessus, l’invention permet, lorsqu’un utilisateur UT, disposant d’un objet communicant OC, est dans une situation de transaction avec un environnement de fourniture de bien(s) ou de service(s) EVF, de générer un assemblage d’un lecteur LECT du moyen d’accès MAST, associé à l’objet communicant OC, avec un module MCT de contrôle de la transaction qui est disponible dans l’environnement EVF de fourniture de bien(s) ou de service(s). Un tel assemblage a pour effet de reconstituer un terminal de transaction complet qui permet de réaliser la transaction.

De façon particulièrement avantageuse, un tel lecteur LECT peut servir à constituer une multitude de terminaux de transaction au gré des transactions réalisées par l’utilisateur auprès de différents fournisseurs de bien(s) ou de service(s). De façon symétrique, le module MCT de contrôle de la transaction qui est instancié dans un environnement EVF de fourniture de bien(s) ou de service(s) donné peut s’assembler avec une multitude de lecteurs LECT présentés par différents utilisateurs UT. La connexion d’un module MCT de contrôle de la transaction avec différents lecteurs LECT peut être simultanée pour permettre l’exécution de transactions en parallèle, ce qui n’est pas forcément le cas s’agissant de la connexion d’un lecteur LECT avec différents modules MCT de contrôle de transaction en simultané.

On décrit maintenant, en référence à la figure 4A, l’étape d’authentification mutuelle S4 précitée, selon un premier mode de réalisation de l’invention.

Dans l’exemple illustré, l’authentification est requise à l’initiative du module MCT de contrôle de la transaction. L’étape d’authentification S4 se déroule alors comme suit : En S40, le module MCT de contrôle de la transaction envoie au lecteur LECT, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT1 qui comprend un identifiant IDMCïdu module MCT.

L’étape d’envoi S40 peut être exécutée, par exemple suite à la réception d’un message de confirmation en provenance du lecteur LECT indiquant que l’objet communicant OC dispose d’un tel lecteur LECT. Selon un autre mode de réalisation, la requête REQ AUT1 pourrait être transmise simultanément à la requête REQ LECT envoyé en S2 (figure 3) demandant si l’objet communicant OC contient un lecteur LECT.

L’objet communicant OC reçoit la requête REQ_AUT1 en S41 .

En S42, le lecteur LECT vérifie si l’identifiant IDMCT reçu est valide. Si l’identifiant IDMCT reçu n’est pas valide, l’authentification échoue.

Si l’identifiant IDMCT reçu est valide, en S43, le lecteur LECT envoie à son tour au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT2 qui comprend un identifiant IDLECïdu lecteur LECT.

Le module MCT reçoit la requête REQ_AUT2 en S44.

En S45, le module MCT vérifie si l’identifiant IDiECT reçu est valide. Si l’identifiant lÜLECT reçu n’est pas valide, l’authentification échoue.

Si l’identifiant IDiECT reçu est valide, en S46, l’authentification mutuelle entre le module MCT et le lecteur LECT est établie, ce qui permet de constituer un terminal de transaction réparti entre l’environnement de fourniture de bien(s) ou de service(s) et l’objet communicant OC.

Lorsque le niveau de sécurité de la transaction est bas, lors de l’étape S42 de vérification de l’identifiant IDMCT, le lecteur LECT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés par exemple dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier. De manière correspondante, lors de l’étape S45 de vérification de l’identifiant IDLECT, le module MCT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s).

Lorsque le niveau de sécurité de la transaction est élevé, l’étape d’authentification mutuelle S4 utilise un mécanisme de chiffrement.

A cet effet :

- au cours de l’étape d’envoi S40 précitée, l’identifiant IDMCT du module MCT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERTMCT ; - au cours de l’étape d’envoi S43 précitée, l’identifiant IDLECïdu lecteur LECT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERTLECT.

De manière connue en soi, les certificats numériques CERÏMCTet CERTLECT sont délivrés par une autorité tierce de confiance et stockés respectivement dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s) et dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.

On décrit maintenant, en référence à la figure 4B, l’étape d’authentification mutuelle S4 précitée, selon un deuxième mode de réalisation de l’invention.

Dans l’exemple illustré, l’authentification est requise à l’initiative du lecteur LECT de l’objet communicant OC. L’étape d’authentification S4 se déroule alors comme suit : En S40’, le lecteur LECT de l’objet communicant OC envoie au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUTT qui comprend un identifiant IDLECïdu lecteur LECT. L’étape d’envoi S40’ peut être exécutée par exemple suite à la réception S3 de la requête REQ_LECT demandant si l’objet communicant OC contient un lecteur LECT ou simultanément à l’envoi au module MCT d’un message de confirmation indiquant que l’objet communicant OC dispose bien d’un lecteur LECT.

Le module MCT reçoit la requête REQ_AUTT en S4T.

En S42’, le module MCT vérifie si l’identifiant lÜLECT reçu est valide. Si l’identifiant lÜLECT reçu n’est pas valide, l’authentification échoue.

Si l’identifiant lÜLECT reçu est valide, en S43’, le module MCT envoie à son tour au lecteur LECT, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT2’ qui comprend un identifiant lÜMCTdu module MCT.

Le lecteur LECT reçoit la requête REQ_AUT2’ en S44’.

En S45’, le lecteur LECT vérifie si l’identifiant lÜMCT reçu est valide. Si l’identifiant lÜMCT reçu n’est pas valide, l’authentification échoue.

Si l’identifiant lÜMCT reçu est valide, en S46’, l’authentification mutuelle entre le module MCT et le lecteur LECT est établie, ce qui permet de constituer un terminal de transaction réparti entre l’environnement EVF de fourniture de bien(s) ou de service(s) et l’objet communicant OC. Lorsque le niveau de sécurité de la transaction est bas, lors de l’étape S42’ de vérification de l’identifiant IDLECT, le module MCT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s). De manière correspondante, lors de l’étape S45’ de vérification de l’identifiant IDMCT, le lecteur LECT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés par exemple dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.

Lorsque le niveau de sécurité de la transaction est élevé, l’étape d’authentification mutuelle S4 utilise un mécanisme de chiffrement.

A cet effet :

- au cours de l’étape d’envoi S40’ précitée, l’identifiant IDLECT du lecteur LECT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERT’LECT ;

- au cours de l’étape d’envoi S43’ précitée, l’identifiant IDMCT du module MCT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERT’MCT.

De manière connue en soi, les certificats numériques CERT’LECT et CERT’MCT sont délivrés par une autorité tierce de confiance et stockés respectivement dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s) et dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.

Description détaillée d’exemples d’applications de l’invention

On décrit maintenant en référence aux figures 5A à 5C, ensemble la figure 3, trois modes de réalisation différents de mise en œuvre du procédé d’établissement d’une transaction tel que décrit ci-dessus.

La figure 5A représente un système d’établissement d’une transaction selon un premier mode de réalisation, pour lequel la transaction est de type bancaire. Dans cet exemple, l’objet communicant OC est par exemple un véhicule, ici une voiture électrique connectée. A ce titre, la voiture OC est 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 OC est dotée :

- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,

- d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’une carte de paiement MAST qu’elle soit physique ou dématérialisée.

Le lecteur LECT est embarqué dans le véhicule connecté OC. Sa partie matérielle HARD est partie intégrante de l'habitacle (zone matérialisée sur la planche de bord par exemple), ou ajoutée au véhicule (équipement en seconde monte). La partie HARD peut être aussi un équipement indépendant apporté par l’utilisateur UT et appairé avec le système d’information du véhicule. La partie logicielle SOFT est quant à elle mise en œuvre au sein de l'infrastructure de traitement informatique déployée dans le véhicule (système d'exploitation automobile et applications déployées sur celui-ci). Cette infrastructure offre les performances et la sécurité compatibles avec la norme de sécurité de l'industrie des cartes de paiement PCI DSS (« Payment Card Industry Data Security Standard » en anglais).

Le lecteur LECT peut exploiter l’interface utilisateur IU du système d’information du véhicule, par exemple utiliser l’écran de console intégré au tableau de bord, ainsi que les moyens de saisie offerts à l’utilisateur (écran tactile, molette pour interagir avec l’écran, commande vocale, etc...).

Dans l’exemple de la figure 5A, le dispositif DF de fourniture de bien(s) ou de service(s) 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.

Bien entendu, cet exemple n‘a rien d’exhaustif. En particulier, le dispositif DF de fourniture de bien(s) ou de service(s) varie en fonction du contexte d’utilisation de la voiture connectée OC. A cet effet, le dispositif de fourniture de bien(s) ou de service(s) DF pourrait être alternativement :

- une pompe à essence,

- un guichet de vente de nourriture à emporter, - un parcmètre,

- une barrière de péage,

- etc.

La borne de recharge DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :

- un système de caisse MET,

- un kernel de paiement MCT.

La borne de recharge DF est également dotée d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.

Le système de caisse MET est configuré pour enregistrer les transactions et initier une opération de paiement vers le kernel de paiement MCT.

Le kernel de paiement MCT est relié au système de caisse MET et doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec le serveur BF de la banque du fournisseur de bien(s) ou de service(s), ici le gestionnaire de la station de rechargement. Ce serveur BF est ici une partie du serveur de gestion de transaction SERV, le serveur BF étant en communication avec le serveur RC du réseau de cartes bancaires qui lui-même communique avec le serveur BU de la banque de l’utilisateur UT.

Ce composant kernel peut être mis en œuvre de façon virtualisée, sous forme logicielle, hébergé par un opérateur de cloud ou télécom dans un environnement matériel et logiciel compatible avec la norme PCI DSS précitée.

Typiquement, le kernel de paiement est du type EMV (« Europay, Mastercard and Visa » en anglais).

Dans ce contexte de l’établissement de la transaction de l’invention, la voiture électrique connectée OC commence par s’appairer en S0 avec la borne de recharge DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici un paiement correspondant à la recharge effectuée.

Le signal d’appairage réussi est alors transmis au système de caisse MET et au kernel de paiement MCT.

Le kernel de paiement MCT et/ou le système de caisse MET vérifient en S1 que la borne de recharge DF est opérationnelle. En S2, le kernel de paiement MCT ou la borne de recharge DF envoie à la voiture connectée OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si la voiture connectée OC contient un lecteur LECT.

La voiture connectée OC reçoit la requête REQ LECT en S3.

La voiture connectée OC contenant un tel lecteur LECT, une authentification mutuelle est alors exécutée en S4 entre le kernel de paiement MCT et le lecteur LECT, de manière à émuler un terminal de paiement de type TPE.

L’étape S4 peut être suivie d’une étape de pré-autorisation requise par le terminal de paiement ainsi émulé. A cet effet, en S5, le kernel de paiement MCT ou la borne de recharge DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son moyen de paiement MAST, soit à l’aide d’un message sonore DAT délivré sur un haut-parleur dans la voiture, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran de la console.

La voiture connectée OC reçoit la requête REQ_TR en S6.

En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter sa carte de paiement MAST au lecteur LECT.

Le lecteur LECT lit alors en S8 des données d’identification IDMAST de la carte de paiement MAST.

Dans le cas où la carte de paiement MAST est une carte à puce sans contact, par exemple de type NFC, l’utilisateur UT approche en S8 sa carte de la surface NFC du lecteur LECT. Afin d’augmenter le niveau de sécurité de la transaction, il peut être demandé à l’utilisateur UT de saisir un code secret MP sur le clavier de la console de la voiture OC.

Dans le cas où la carte de paiement à puce MAST n’est pas sans contact, l’utilisateur UT insère cette dernière dans une ouverture dédiée du lecteur LECT et saisit son code secret MP sur le clavier de la console.

Dans le cas où la carte de paiement MAST est virtualisée, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à la carte de paiement virtualisée MAST, dans la mémoire MEMi de la voiture connectée OC. S’il existe plusieurs cartes virtualisées en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT de la carte virtualisée à utiliser pour la transaction. En S9, la voiture connectée OC transmet au kernel de paiement MCT, via le canal sécurisé établi en S0, les données d’identification IDMAST. Le kernel de paiement réalise la demande de pré-autorisation auprès du serveur BU de la banque de l’utilisateur UT. Cette demande est traitée de façon classique, c’est- à-dire que la demande est acheminée du serveur BF de la banque de la station- service, via le serveur RC de réseau de cartes bancaires, jusqu'au serveur BU de la banque de l’utilisateur UT.

Dans le cas où l’autorisation est validée, le kernel de paiement MCT transmet un signal à la borne de recharge DF pour l'autoriser à fournir de l’électricité à la voiture connectée OC.

Une fois que le plein est effectué, le kernel de paiement MCT ou la borne de recharge DF communique le montant DAT à débiter à la voiture connectée OC, via le canal sécurisé établi en S0.

Le kernel de paiement MCT réalise le débit en S10 via les serveurs BU, RC et BF, puis transmet au lecteur LECT les informations de fin de transaction, pour affichage sur l'écran de la voiture connectée OC ou pour écoute via le ou les haut-parleurs de la voiture connectée OC.

La figure 5B représente un système d’établissement d’une transaction selon un deuxième mode de réalisation de l'invention, pour lequel la transaction est un contrôle d’accès à un local sécurisé ou non, un moyen de transport, etc. Ce deuxième mode de réalisation utilise des éléments communs à ceux de la figure 5A. Pour cette raison, ces éléments sont désignés avec les mêmes références.

Dans cet exemple, l’objet communicant OC est par exemple 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 OC est 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 OC est dotée :

- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,

- d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’un badge de transport MAST qu’il soit physique ou dématérialisé. Le lecteur LECT est associé à la montre connectée OC. Sa partie matérielle HARD est partie intégrante du boîtier de la montre OC ou reliée à ce dernier. La partie logicielle SOFT est quant à elle mise en œuvre au sein du système d’exploitation de la montre OC.

Le lecteur LECT peut exploiter l’interface utilisateur IU de la montre (clavier, écran, haut-parleur, haptique (vibrations)).

Dans l’exemple de la figure 5B, le dispositif DF de fourniture de bien(s) ou de service(s) 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.

Le portillon DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :

- un système MET d’enregistrement et de traitement de la transaction,

- un serveur de contrôle d’accès MCT.

Le portillon DF est également doté d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C- V2X, etc.

Le système MET d’enregistrement et de traitement de la transaction est configuré pour enregistrer les transactions et initier une opération d’accès vers le serveur de contrôle d’accès MCT.

Le serveur de contrôle d’accès MCT est relié au système MET d’enregistrement et de traitement de la transaction et est doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec un serveur SERV de gestion de la transaction qui est détenu par exemple par une régie de transport.

Dans ce contexte de l’établissement de la transaction de l’invention, la montre connectée OC commence par s’appairer en S0 avec le portillon DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici un accès à un transport en commun.

Le signal d’appairage réussi est alors transmis au système MET d’enregistrement et de traitement de la transaction et au serveur MCT de contrôle d’accès. Le serveur MCT de contrôle d’accès et/ou le système MET d’enregistrement et de traitement de la transaction vérifient en S1 que le portillon DF est opérationnel.

En S2, le serveur MCT de contrôle d’accès ou le portillon DF envoie à la montre connectée OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si la montre connectée OC contient un lecteur LECT.

La montre connectée OC reçoit la requête REQ LECT en S3.

La montre connectée OC contenant un tel lecteur LECT, une authentification mutuelle conforme à l’invention est alors exécutée en S4 entre le serveur MCT de contrôle d’accès et le lecteur LECT, de manière à émuler un terminal de contrôle d’accès.

En S5, le serveur MCT de contrôle d’accès ou le portillon DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son badge de transport MAST, soit à l’aide d’un message sonore DAT délivré sur le haut-parleur de la montre OC, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran de la montre. En complément ou alternativement, les données DAT peuvent contenir le type de la transaction, par exemple un identifiant de la ligne de transport et/ou un nombre de tickets à valider.

La montre connectée OC reçoit la requête REQ_TR en S6.

En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter son badge de transport MAST au lecteur LECT.

Le lecteur LECT lit alors en S8 des données d’identification IDMAST du badge de transport MAST.

Dans le cas où le badge de transport MAST est une carte à puce sans contact, par exemple de type NFC, l’utilisateur UT approche en S8 son badge de la surface NFC du lecteur LECT. Afin d’augmenter le niveau de sécurité de la transaction, il peut être demandé à l’utilisateur UT de saisir un code secret MP sur le clavier de la montre connectée OC.

Dans le cas où le badge de transport MAST est dématérialisé, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, au badge MAST, dans la mémoire MEMi de la montre OC. S’il existe plusieurs badges de transport en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT du badge à utiliser pour accéder au moyen de transport. En S9, la montre OC transmet au serveur MCT de contrôle d’accès, via le canal sécurisé établi en S0, l’identifiant IDiwxsTdu badge MAST.

En S10, le serveur de contrôle d’accès MCT décrémente un ou plusieurs tickets de transport numériques préchargé(s) dans le badge de transport MAST ou dans la mémoire MEMi de la montre connectée OC lorsque le badge MAST est sous forme dématérialisée. En variante, dans le cas d’un abonnement au moyen de transport, le serveur de contrôle d’accès MCT vérifie en S10 auprès du serveur de gestion SERV que l’identifiant IDiwxsTdu badge MAST est bien valide. Dans ce cas, le serveur de contrôle d’accès MCT commande l’ouverture du portillon DF pour laisser passer l’utilisateur UT, puis en commande la fermeture au bout d’une durée prédéterminée. La transaction est alors enregistrée dans le système MET d’enregistrement de la transaction qui communique les informations de cette transaction au serveur SERV. Le serveur de contrôle d’accès MCT transmet au lecteur LECT les informations de fin de transaction, par exemple le nombre de tickets utilisés, pour affichage sur l'écran de la montre connectée OC ou pour écoute via le ou les haut-parleurs de la montre connectée OC.

La figure 5C représente un système d’établissement d’une transaction selon un troisième mode de réalisation de l'invention, pour lequel la transaction est une commande de l’ouverture/fermeture d’un casier d’une boîte, borne ou armoire de retrait automatique de colis. Ce troisième mode de réalisation utilise des éléments communs à ceux des figures 5A et 5B. Pour cette raison, ces éléments sont désignés avec les mêmes références.

Dans cet exemple, l’objet communicant OC est par exemple 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 OC est 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, le smartphone OC est doté :

- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc., - d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’une étiquette MAST de retrait d’un colis COL, telles que par exemple un code-barres ou un QR (« Quick Response » en anglais) code qui a été préalablement transmis au smartphone OC par l’enseigne qui a vendu la marchandise contenue dans le colis ou par le transporteur qui a acheminé le colis. Alternativement, l’étiquette MAST pourrait être une étiquette physique à la disposition de l’utilisateur UT et portant le code-barres ou le QR code précité.

La partie matérielle HARD du lecteur LECT est partie intégrante du smartphone OC. En variante, la partie matérielle HARD peut être un équipement que l’utilisateur UT connecte au préalable au smartphone OC, par une liaison filaire ou une connexion sans fil. La partie logicielle SOFT du lecteur LECT est quant à elle mise en œuvre au sein du système d’exploitation du smartphone OC.

Le lecteur LECT peut exploiter l’interface utilisateur IU du smartphone OC (clavier, écran, haut-parleur).

Dans l’exemple de la figure 5C, le dispositif DF de fourniture de bien(s) ou de service(s) 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.

La boîte de retrait DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :

- un système MET d’enregistrement et de traitement de la transaction,

- un serveur MCT de commande d’ouverture/fermeture d’un casier.

La boîte de retrait DF est également dotée d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.

Le système MET d’enregistrement de la transaction est configuré pour enregistrer les transactions, ici les retraits de colis, et initier une opération de retrait de colis vers le serveur MCT de commande de l’ouverture/fermeture d’un casier.

Le serveur MCT de commande de l’ouverture/fermeture d’un casier est relié au système MET d’enregistrement et de traitement de la transaction et doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec un serveur SERV de gestion de la transaction qui comprend un serveur de gestion SEN appartenant à l’enseigne qui a vendu la marchandise contenue dans le colis COL, lequel serveur SEN communique avec un serveur de gestion STR appartenant au transporteur ayant acheminé le colis jusqu’à la boîte de retrait DF.

Dans ce contexte de l’établissement de la transaction de l’invention, à l’approche de l’utilisateur UT de la boîte de retrait DF, le smartphone OC commence par s’appairer en S0 avec la boîte de retrait DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici une commande d’ouverture/fermeture d’un casier. Le signal d’appairage réussi est alors transmis au système MET d’enregistrement et de traitement de la transaction et au serveur MCT de commande de l’ouverture/fermeture du casier E contenant le colis COL à retirer.

Le serveur MCT de commande de l’ouverture/fermeture de casier et/ou le système MET d’enregistrement et de traitement de la transaction vérifient en S1 que la boîte de retrait DF est opérationnelle.

En S2, le serveur MCT de commande de l’ouverture/fermeture de casier ou la boîte de retrait DF envoie au smartphone OC, via le canal sécurisé établi en S0, une requête REQ_LECT demandant si le smartphone OC contient un lecteur LECT.

Le smartphone OC reçoit en S3 la requête REQ_LECT

Le smartphone OC contenant un tel lecteur LECT, une authentification mutuelle conforme à l’invention est alors exécutée en S4 entre le serveur MCT et le lecteur LECT, de manière à émuler un terminal de commande d’ouverture ou de fermeture de casier.

En S5 le serveur MCT ou la boîte de retrait DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son étiquette de retrait MAST, soit à l’aide d’un message sonore DAT délivré sur le haut-parleur du smartphone OC, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran du smartphone. En complément ou alternativement, les données DAT peuvent contenir un identifiant, un logo ou un nom de l’enseigne de la boutique d’où provient le colis COL, le prix de la commande, un identifiant du casier qui contient le colis COL, etc.

En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter son étiquette de retrait MAST au lecteur LECT.

Le lecteur LECT lit alors en S8 des données d’identification IDMAST de l’étiquette MAST, ici le code-barres ou le QR code. Dans le cas où l’étiquette MAST est un support physique, par exemple une feuille de papier, un autocollant ou autres, l’utilisateur UT approche en S8 l’étiquette MAST de la surface du lecteur LECT qui est adapté pour lire de tels codes.

Dans le cas où l’étiquette MAST a été transmise au smartphone OC, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à l’étiquette MAST, dans la mémoire MEMi du smartphone OC. S’il existe plusieurs étiquettes stockées en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT de l’étiquette MAST à lire.

En S9, le smartphone OC transmet au serveur MCT, via le canal sécurisé établi en S0, l’identifiant IDiwxsTde l’étiquette MAST.

En S10, le serveur MCT vérifie auprès du serveur STR du transporteur que l’identifiant IDiwxsTde l’étiquette MAST est bien valide. Cet identifiant étant valide, le serveur MCT commande l’ouverture d’un des casiers qui contient le colis COL, le casier E dans l’exemple représenté, puis une fois le casier E vidé, en commande la fermeture au bout d’une durée prédéterminée. La transaction est alors enregistrée dans le système MET d’enregistrement et de traitement de la transaction qui communique les informations de cette transaction aux serveurs SEN et STR. Le serveur de contrôle d’accès MCT transmet au lecteur LECT les informations de fin de transaction, par exemple le nombre de colis retirés, pour affichage sur l'écran du smartphone OC ou pour écoute via le ou les haut-parleurs du smartphone OC.