Titre de l'invention : Traitement d'un service de tickets électroniques

Domaine Technique

[0001] L’invention se situe dans le domaine des transactions bancaires et porte plus particulièrement sur la génération et la gestion de tickets électroniques représentatifs de transactions bancaires traitées par un terminal en coopération avec un dispositif électronique tel qu’une carte bancaire par exemple.

Technique antérieure

[0002] Une carte bancaire est une carte à puce destinée à traiter des transactions bancaires, telles que des transactions de paiement, des transactions de transfert, ou toutes autres transactions financières appropriées. Il peut s’agir par exemple de cartes de crédit ou de cartes de débit.

[0003] Pour ce faire, une carte bancaire comprend au moins une application bancaire (application de paiement par exemple, de type VISA™ ou autre) exécutable par une puce électronique intégrée dans la carte. Cette puce électronique est configurée pour coopérer avec des terminaux externes (ou lecteurs), tels que des terminaux de paiement ou des distributeurs automatiques de billets (DAB), pour réaliser diverses fonctions.

[0004] Une carte bancaire est traditionnellement conçue pour coopérer avec un terminal externe au moyen de contacts externes accessibles à la surface de la carte. Un terminal externe peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d’établir une communication par contact avec la puce électronique. Plus récemment, les cartes bancaires sans contact ont connu un essor important en raison du gain en rapidité et en simplicité liées aux transactions sans contact. Pour ce faire, les cartes sans contact embarquent une antenne radiofréquence permettant la transmission et la réception de signaux RF avec un terminal externe.

[0005] EMV (pour « Europay MasterCard Visa ») est le protocole standardisé utilisé aujourd’hui majoritairement dans le monde pour sécuriser les transactions bancaires effectuées par les cartes bancaires. [0006] De façon connue, il est courant lors d’une transaction bancaire, de type EMV par exemple, qu’un ticket (appelé aussi « facturette » ou « reçu ») soit produit pour indiquer aux parties prenantes (utilisateur de la carte, utilisateur du terminal) des données de transaction telles que le montant, la date ou encore le résultat de la transaction (réussie, échouée). Ce ticket est obtenu par impression sur un support matériel, généralement en papier.

[0007] De plus en plus de commerçants utilisent à présent la solution du ticket électronique, appelé aussi e-ticket ou billet électronique. Il s’agit d’un ticket dématérialisé qui remplace le ticket traditionnel papier par des informations numériques représentatives d’une transaction. Lors d’une transaction EMV par exemple, le ticket électronique est généré par le terminal de paiement puis envoyé par email au porteur de la carte bancaire. Cette solution est plus écologique et permet de réduire les coûts liés à la production de tickets traditionnels, tout en permettant une meilleure gestion des tickets par l’utilisateur qui n’a plus besoin de stocker les tickets physiques.

[0008] Toutefois, l’utilisation des tickets électroniques présentent certaines contraintes. Pour recevoir un ticket électronique lors d’une transaction de paiement par exemple, le porteur de la carte bancaire doit généralement fournir son adresse email. Cette opération est lente, peut engendrer des risques de saisie et n’est pas toujours souhaitable pour les utilisateurs qui sont souvent réticents à divulguer leur adresse email, à une enseigne commerciale par exemple. De manière générale, les utilisateurs souhaitent protéger leur identité numérique et se prémunir des risques de spams commerciaux. En outre, si le porteur de la carte n’a pas de carte de fidélité auprès de l’enseigne commerçante concernée, il doit fournir son adresse email à chaque transaction, ce qui est fastidieux, ralentit le traitement des transactions et augmente encore plus les risques d’erreur.

[0009] Les contraintes et problèmes énoncés ci-dessus sont d’autant plus importants que, à l’avenir, de plus en plus de commerçants seront amenés à utiliser exclusivement les tickets électroniques, abandonnant ainsi définitivement la solution des tickets traditionnels. [0010] Par ailleurs, la solution des tickets électroniques n’est pas limitée aux cartes bancaires mais peut être utilisée plus généralement avec d’autres moyens de paiement, tels que les smartphones, tablettes ou tous autres dispositifs électroniques destinés à implémenter une application pour interagir avec un terminal externe afin de traiter une transaction, de type EMV ou autre. L’essor des solutions de paiement mobiles ou mPOS pour « mobile Point of Sale » a pour conséquence que les commerçants n’ont souvent plus d’imprimante à disposition pour produire des tickets traditionnels.

[0011] Un besoin existe donc aujourd’hui pour une solution permettant une gestion efficace des tickets électroniques, qui garantit la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.

[0012] Un besoin existe notamment pour une gestion améliorée des tickets électroniques liés aux transactions de type EMV.

Exposé de l’invention

[0013] A cet effet, la présente invention vise un premier procédé de traitement mis en œuvre par un terminal pour traiter une transaction bancaire en coopération avec un dispositif électronique, ledit procédé comprenant :

- réception, en provenance du dispositif électronique, de premières données comprenant un identifiant d’utilisateur (IDUR) identifiant un utilisateur associé au dispositif électronique ;

- transmission, au dispositif électronique, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;

- réception, en provenance du dispositif électronique, d’un cryptogramme généré à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et

- transmission, à un serveur de gestion, d’une requête de génération de ticket électronique comprenant le cryptogramme, les données d’entrée et des données de transaction caractérisant la transaction, pour requérir la génération par le serveur de gestion d’un ticket électronique représentatif de la transaction à partir des données transmises par le terminal. [0014] L’invention permet une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.

[0015] Le dispositif électronique peut être par exemple une carte à puce ou carte bancaire, de type EMV ou autre.

[0016] Selon un mode de réalisation particulier, les premières données transmises par le dispositif électronique comprennent une adresse du serveur de gestion, le terminal utilisant ladite adresse pour transmettre la requête de génération de ticket électronique audit serveur de gestion.

[0017] Selon un mode de réalisation particulier, les deuxièmes données, transmises au dispositif électronique, comprennent en outre au moins l’un parmi :

a) un identifiant de marchand identifiant une entité marchande associée au terminal ;

b) une donnée de localisation spécifiant une position de ladite entité marchande ;

c) des données de transaction caractérisant la transaction ; dans lequel chacune desdites données a), b) et c) qui est effectivement transmise au dispositif électronique est utilisée en tant que donnée d’entrée par le dispositif électronique pour générer le cryptogramme.

[0018] Selon un mode de réalisation particulier, le cryptogramme est un code MAC.

[0019] Selon un mode de réalisation particulier, en l’absence d’une réponse positive à la requête de génération de ticket, le terminal transmet au dispositif électronique une commande de stockage requérant le stockage, dans une mémoire locale du dispositif électronique, de données d’historique comprenant le cryptogramme, les données d’entrée et les données de transaction pour permettre une transmission d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure.

[0020] Selon un mode de réalisation particulier, le premier procédé de traitement comprend en outre : - réception, en provenance du dispositif électronique, de données d’historique stockées dans une mémoire locale du dispositif électronique et associées à au moins une transaction antérieure ; et

- transmission, au serveur de gestion, en accompagnement de la requête de génération de ticket électronique, des données d’historique pour requérir en outre la génération d’au moins un ticket électronique supplémentaire à partir desdites données d’historique.

[0021] Selon un mode de réalisation particulier, les données d’historique comprennent, en association avec chaque transaction antérieure : un cryptogramme antérieur, des données d’entrée antérieures et des données de transaction antérieures caractérisant ladite au moins une transaction antérieure, ledit cryptogramme antérieur ayant été généré par ledit dispositif électronique à partir de la clé de chiffrement et des données d’entrée antérieures associées.

[0022] Selon un mode de réalisation particulier, le premier procédé de traitement comprend en outre :

- réception d’une réponse positive du serveur de gestion à ladite requête de génération de ticket électronique ; et

- sur détection de la réponse positive, transmission au dispositif électronique d’une commande de suppression pour commander la suppression dans la mémoire locale du dispositif électronique desdites données d’historique.

[0023] L’invention vise également un procédé de gestion mis en œuvre par un

serveur de gestion coopérant avec un terminal destiné à traiter une transaction bancaire, ledit procédé comprenant les étapes suivantes :

- réception, en provenance du terminal, d’un premier cryptogramme, de données d’entrée, de données de transaction caractérisant la transaction ainsi que d’une requête de génération de ticket électronique,

dans lequel le premier cryptogramme a été généré par un dispositif électronique à partir des données d’entrées qui comprennent un identifiant d’utilisateur identifiant un utilisateur et un identifiant de terminal identifiant le terminal ;

- génération d’un deuxième cryptogramme à partir d’une clé de déchiffrement et des données d’entrées ; - vérification de la validité de la requête de génération de ticket électronique, à partir d’une comparaison du premier cryptogramme avec le deuxième cryptogramme ; et

- si ladite requête est valide, génération d’un ticket électronique représentatif de la transaction, à partir au moins des données d’entrée et des données de transaction reçues.

[0024] Comme déjà indiqué, le dispositif électronique peut être par exemple une carte à puce ou carte bancaire, de type EMV ou autre.

[0025] Selon un mode de réalisation particulier, le ticket électronique comprend au moins l’une parmi les données suivantes :

a) les données de transaction caractérisant la transaction ; b) l’identifiant de terminal ;

c) l’identifiant d’utilisateur ;

d) un identifiant de marchand identifiant une entité marchande associée au terminal ;

e) une donnée de localisation spécifiant une position de ladite entité marchande ;

f) un message prédéfini associé à ladite entité marchande ; et

g) un identifiant de type PAN, partiel ou complet, associé au dispositif électronique.

[0026] Selon un mode de réalisation particulier, le serveur de gestion reçoit le

cryptogramme, les données d’entrée, les données de transaction ainsi que la requête de génération de ticket électronique en provenance du terminal via un premier canal de communication ;

le procédé comprend en outre :

- envoi du ticket électronique audit utilisateur via un deuxième canal de

communication différent du premier canal de communication.

[0027] L’invention vise également un deuxième procédé de traitement mis en œuvre par un système comprenant un terminal et un dispositif électronique coopérant ensemble pour traiter une transaction bancaire, dans lequel le terminal réalise les étapes d’un premier procédé de traitement tel que défini ci-avant,

dans lequel le dispositif électronique réalise les étapes suivantes :

- transmission, au terminal, de premières données comprenant un identifiant d’utilisateur identifiant un utilisateur associé au dispositif électronique ;

- réception, en provenance du terminal, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;

- génération d’un cryptogramme à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et

- transmission, au terminal, du cryptogramme et des données d’entrée pour permettre la transmission par le terminal d’une requête de génération de ticket électronique à un serveur de gestion.

[0028] Selon un mode de réalisation particulier, le dispositif électronique génère en outre le cryptogramme à partir de la valeur courante d’un compteur, la valeur dudit compteur étant incrémenté par le dispositif électronique à chaque nouvelle transaction ;

dans lequel le dispositif électronique transmet en outre, en tant que données d’entrée, la valeur courante du compteur au terminal.

[0029] Selon une variante, le dispositif électronique génère le cryptogramme à partir d’une valeur aléatoire qui est générée par le dispositif électronique à chaque nouvelle transaction ;

dans lequel le dispositif électronique transmet en outre, en tant que données d’entrée, la valeur aléatoire au terminal.

[0030] Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend en outre :

- détermination, par le dispositif électronique, d’un identifiant de marchand identifiant une entité marchande associée au terminal ; et

- vérification, par le dispositif électronique, de si l’identifiant de marchand correspond à un marchand prédéfini ;

dans lequel ladite transmission, par le dispositif électronique, du cryptogramme au terminal n’est réalisée que si l’entité marchande ne correspond pas à un marchand prédéfini. [0031] Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend en outre :

- détermination, par le dispositif électronique, d’un identifiant de marchand identifiant une entité marchande associée au terminal ; et

- vérification, par le dispositif électronique, de si l’identifiant de marchand correspond à un marchand prédéfini ;

- dans lequel ledit stockage en local, par le dispositif électronique, des données d’historique est réalisé si l’entité marchande ne correspond pas à un marchand prédéfini.

[0032] Selon un mode de réalisation particulier, le deuxième procédé comprend : en réponse à une commande de stockage reçue en provenance du terminal, stockage dans une mémoire locale du dispositif électronique, du cryptogramme, des données d’entrée et des données de transaction pour permettre la transmission, par un terminal, d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure.

[0033] Dans un mode particulier de réalisation, les différentes étapes du premier procédé de traitement, du procédé de gestion et du deuxième procédé de traitement sont déterminées par des instructions de programmes d’ordinateurs.

[0034] En conséquence, l’invention vise également un programme d’ordinateur adapté pour la mise en oeuvre du premier procédé de traitement, du procédé de gestion et du deuxième procédé de traitement tels que définis dans ce document. Plus précisément, l’invention vise au moins un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un dispositif électronique tel qu’une carte à puce, dans un terminal, dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du premier procédé de traitement, du procédé de gestion ou du deuxième procédé de traitement tels que définis dans ce document.

[0035] L’invention vise aussi des supports d’enregistrement (ou supports d'informations) lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur correspondant à chacun des procédé définis ci-avant. [0036] A noter que les programmes d’ordinateur mentionnés dans le présent exposé peuvent 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.

[0037] De plus, les supports d’enregistrement mentionnés dans ce document peuvent ê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 une disquette (floppy dise) ou un disque dur.

[0038] D'autre part, les supports d’enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

[0039] Alternativement, les supports d’enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

[0040] L’invention vise également un terminal pour mettre en œuvre le premier procédé de traitement tel que défini dans le présent document.

[0041] L’invention vise également un serveur de gestion pour mettre en œuvre le procédé de gestion tel que défini dans ce document.

[0042] L’invention vise également un système pour mettre en œuvre le deuxième procédé de traitement tel que défini dans ce document. Ce système comprend ainsi un dispositif électronique, tel qu’une carte à puce ou carte bancaire par exemple (de type EMV ou autre), coopérant avec le terminal de l’invention.

[0043] A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le premier procédé de traitement, le procédé de gestion et le deuxième procédé s’appliquent respectivement de façon analogue au terminal, au serveur de gestion et au système de l’invention. [0044] Dans les modes de réalisation décrits dans ce document, l'invention est mise en œuvre au moyen de composants logiciels et / ou matériels. Dans cette optique, sauf indication contraire, 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.

[0045] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné.

[0046] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, etc.

[0047] De manière générale, le terminal, le serveur de gestion et le système de l’invention peuvent chacun comprendre un module respectif configuré pour réaliser chaque opération ou étape décrite dans ce document en relation avec les procédés correspondants de l’invention.

Brève description des dessins

[0048] D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:

[0049] [Fig. 1] La figure 1 représente schématiquement, sous la forme d’un diagramme, un exemple de traitement d’une transaction selon le protocole EMV.

[0050] [Fig. 2] La figure 2 représente schématiquement un environnement comprenant une carte à puce, un terminal et un serveur de gestion, conformément à un mode de réalisation particulier de l’invention. [0051] [Fig. 3] La figure 3 représente schématiquement des modules fonctionnels mis en œuvre par un terminal selon un mode de réalisation particulier de l’invention.

[0052] [Fig. 4] La figure 4 représente schématiquement des modules fonctionnels mis en œuvre par un serveur de gestion selon un mode de réalisation particulier de l’invention.

[0053] [Fig. 5] La figure 5 représente schématiquement des modules fonctionnels mis en œuvre par une carte à puce selon un mode de réalisation particulier de l’invention.

[0054] [Fig. 6] La figure 6 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.

[0055] [Fig. 7] La figure 7 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.

[0056] [Fig. 8] La figure 8 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.

[0057] [Fig. 9] La figure 9 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.

Description des modes de réalisation

[0058] La présente invention se propose de permettre une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.

[0059] Pour ce faire, l’invention propose une solution faisant appel à un tiers de confiance prenant la forme d’un serveur de gestion. Selon différentes modes de réalisation de l’invention, lors d’une transaction avec un dispositif électronique (tel qu’une carte à puce par exemple), un terminal est configuré pour transmettre des données au serveur de gestion de sorte que ce dernier puisse générer de façon fiable et sécurisée un ticket électronique à destination des parties intéressées. Ce serveur de gestion peut en outre réaliser diverses opérations pour gérer ces tickets électroniques.

[0060] L’invention propose notamment, selon différents modes de réalisation, un procédé de traitement mis en oeuvre par un terminal pour traiter une transaction bancaire en coopération avec un dispositif électronique, ledit procédé comprenant :

- réception, en provenance du dispositif électronique, de premières données comprenant un identifiant d’utilisateur identifiant un utilisateur associé au dispositif électronique ;

- transmission, au dispositif électronique, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;

- réception, en provenance du dispositif électronique, d’un cryptogramme généré à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et

- transmission, à un serveur de gestion, d’une requête de génération de ticket électronique comprenant le cryptogramme, les données d’entrée et des données de transaction caractérisant la transaction, pour requérir la génération par le serveur de gestion d’un ticket électronique représentatif de la transaction, à partir des données transmises par le terminal.

[0061] Corrélativement, l’invention vise un procédé de gestion mis en œuvre par un serveur de gestion coopérant avec un terminal destiné à traiter une transaction bancaire, ledit procédé comprenant les étapes suivantes :

- réception, en provenance du terminal, d’un premier cryptogramme, de données d’entrée, de données de transaction caractérisant la transaction ainsi que d’une requête de génération de ticket électronique,

- dans lequel le premier cryptogramme a été généré par un dispositif électronique à partir des données d’entrées qui comprennent un identifiant d’utilisateur identifiant un utilisateur et un identifiant de terminal identifiant le terminal ; - génération d’un deuxième cryptogramme à partir d’une clé de déchiffrement et des données d’entrées ;

- vérification de la validité de la requête de génération de ticket électronique, à partir d’une comparaison du premier cryptogramme avec le deuxième cryptogramme ; et

- si ladite requête est valide, génération d’un ticket électronique représentatif de la transaction, à partir au moins des données d’entrée et des données de transaction reçues.

[0062] En outre, l’invention vise notamment le serveur de gestion et le terminal correspondant aux procédés définis ci-dessus, ainsi qu’un système comprenant le terminal et le dispositif électronique et les programmes d’ordinateurs correspondants aux procédés de l’invention.

[0063] D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.

[0064] Dans le présent exposé, des exemples de mise en œuvre de l’invention sont décrits dans le cadre d’une carte à puce de type EMV, configurée pour traiter des transactions EMV. A noter que d’autres modes de réalisation sont toutefois possibles. En particulier, l’invention ne s’applique pas exclusivement aux cartes à puce mais peut s’appliquer plus généralement à des dispositifs électroniques quelconques configurés pour traiter des transactions en coopération avec un terminal externe, selon le standard EMV ou selon tous autres protocoles appropriés. L’invention peut s’appliquer notamment aux smartphones, tablettes ou tous autres dispositifs électroniques implémentant une application pour traiter une transaction, de type EMV par exemple, en coopération avec un terminal externe.

[0065] Le protocole EMV, bien connu de l’homme du métier, a été conçu pour diminuer les risques de fraudes lors d’une transaction bancaire (transaction de paiement, par exemple) en permettant notamment l’authentification à la fois de la carte à puce et de son porteur. Les principes du protocole EMV sont rappelés ci- dessous. [0066] La figure 1 représente un exemple de mise en œuvre d’une transaction de paiement conforme au protocole EMV, à l’aide d’une carte à puce EMV 100. Certains aspects d’une transaction EMV ont été omis par souci de simplicité.

[0067] Lors d’une première phase destinée à authentifier la carte à puce 100 utilisée, le terminal 110 et la carte 100 s’échangent un certain nombre de messages dont un message RESET (RST) en S2 puis une réponse ATR en S4 (en mode avec contact). Le terminal 110 tente de choisir l’application appropriée sur la carte à puce 100. Pour ce faire, le terminal 110 envoie (S5a) à la carte à puce 100 une commande SELECT FILE afin de demander à la carte à puce les applications que cette dernière est capable d’exécuter. Cette commande SELECT FILE contient en paramètre l’identifiant d’application (AID pour « Application Identifier ») du PSE pour « Payment System Environment » (ou PPSE pour « Proximity Payment System Environment », en mode sans contact). En réponse, le terminal 110 envoie en S5b une commande APPLICATIONS qui contient une liste des différentes applications que la carte est capable d’exécuter. Le terminal 110 répond en envoyant en S6 une commande SELECT APPLICATION pour sélectionner une application dans la carte à puce 100 qui va traiter la transaction EMV. Pour ce faire, cette commande SELECT APPLICATION contient l’identifiant AID de l’application sélectionnée.

[0068] Le terminal 110 envoie ensuite en S7 à la carte à puce 100 une commande GET PROCESSING OPTIONS (GPO) qui déclenche une phase S8 de lecture de données, dites RECORDS, présentes en mémoire dans la carte à puce 100. Ces données sont dites statiques dans le sens où elles ne varient pas d'une transaction à une autre. Pour ce faire, le terminal 100 envoie des requêtes READ RECORD auxquelles la carte à puce 100 répond en fournissant des données statiques dans des réponses RECORD.

[0069] La carte 100 et le terminal 110 peuvent ensuite procéder à une phase optionnelle (non représentée) d’authentification du porteur de la carte, au cours le code confidentiel PIN du porteur est vérifié. Toutefois, si le mode sans vérification de code PIN est sélectionné, aucune vérification de code PIN n’est réalisé.

[0070] Le protocole EMV initie une phase de vérification de la transaction au cours de laquelle le terminal 110 envoie (S9) à la carte puce 100 une première commande GAC (pour « GENERATE AC ») notée aussi GAC1. Cette commande GAC1 bien connue de l’homme du métier comprend des informations sur la transaction en cours telles que le montant de la transaction, la devise utilisée, le type de transaction, etc. La carte EMV 100 réalise (S9) alors une vérification de la transaction selon des critères de vérification prédéfinis puis envoie (S11), en réponse au GAC1 , un cryptogramme.

[0071] Divers modes de réalisation sont envisageables. On suppose dans cet exemple que la carte à puce 100 envoie en S11 un cryptogramme ARQC (pour (« Autorisation Request Cryptogram ») indiquant qu’elle souhaite poursuivre la transaction en ligne avec l’émetteur 120 de la carte 100. La demande ou non de poursuivre la transaction en ligne dépend du paramétrage de la carte. Le cryptogramme ARQC est transmis (S12) par le terminal 110 à l’émetteur 120 qui peut ainsi réaliser (S13) un certain nombre de vérifications afin de s’assurer que la transaction est valide. L’émetteur 120 envoie (S 14) ensuite, en réponse au message ARCQ reçu, un cryptogramme ARPC (pour « Autorisation Response Cryptogram ») indiquant la décision de l’émetteur 120. Ce message ARPC est transmis (S16) par le terminal 110 à la carte 100 dans une deuxième commande GAC, notée GAC2, bien connue de l’homme du métier.

[0072] A noter que la carte à puce 100 peut également traiter la transaction en mode hors ligne, c’est-à-dire sans faire intervenir l’émetteur 120 pour vérifier la transaction.

[0073] La carte 100 détermine si elle accepte ou non la transaction à partir de la réponse ARPC. La carte 100 renvoie ainsi en S18 un cryptogramme TC ou ACC indiquant respectivement qu’elle accepte ou refuse la transaction.

[0074] A noter par ailleurs que, dans ce document, la notion de transaction bancaire doit être entendue au sens large et comprend par exemple, dans le domaine bancaire, une transaction de paiement, une transaction de débit, une transaction de transfert, ou toutes autres transactions financières pouvant faire l’objet de la gestion d’un ticket électronique conformément à l’invention. Dans les modes de réalisation décrits ci-après, la carte à puce de l’invention traite ainsi des transactions de paiement, bien que d’autres types de transaction soient possibles. [0075] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

[0076] La figure 2 représente, de manière schématique, un environnement comprenant un terminal T1 , une carte bancaire DV1 et un serveur de gestion SV1 , conformément à un mode de réalisation particulier de l’invention.

[0077] Le terminal T1 et la carte bancaire DV1 , formant ensemble un système SY1 , sont configurés pour coopérer ensemble pour traiter une transaction bancaire notée TR1 . On suppose dans cet exemple que la transaction TR1 est une transaction de paiement de type EMV, d’autres exemples étant toutefois possibles.

[0078] Plus particulièrement, on suppose que l’utilisateur U R utilise sa carte bancaire DV1 pour réaliser la transaction de paiement TR1 auprès d’une entité tierce, à savoir l’entité marchande (ou enseigne commerçante) MD dans cet exemple.

[0079] En plus d’interagir avec la carte bancaire DV1 conformément au standard EMV, le terminal T1 coopère également avec le serveur de gestion SV1 , ce dernier étant configuré pour générer et gérer un ticket électronique, noté TK1 , représentatif de la transaction TR1 .

[0080] Le terminal T1 comprend un processeur 2, une première mémoire non volatile MR1 , une deuxième mémoire non volatile MR2, une première interface de communication INT1 et une deuxième interface de communication INT2. Le terminal T1 prend ici la forme d’un terminal de paiement bien que d’autres modes de réalisation soient possibles.

[0081] Plus précisément, la mémoire MR1 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal T1 , et sur lequel est enregistré un programme d’ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG1 comporte des instructions pour l’exécution des étapes d’un procédé de traitement selon un mode de réalisation particulier qui sera décrit ultérieurement. [0082] La mémoire MR2 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un identifiant de terminal IDT 1 qui identifie le terminal T1 et, éventuellement, au moins l’un parmi un identifiant de marchand IDMD qui identifie l’entité marchande MD et une donnée de localisation LOC spécifiant une position de cette entité marchande MD. L’usage et l’intérêt de ces données seront décrits plus en détail ultérieurement.

[0083] Selon un exemple particulier, les mémoires MR1 et MR2 forment une seule et même mémoire.

[0084] La première interface de communication INT 1 permet au terminal T 1 de communiquer avec le serveur de gestion SV1. Pour ce faire, la première interface de communication INT1 établit une liaison de communication L1 avec le serveur de gestion SV1. Cette liaison L1 peut être filaire ou sans fil, et peut être de toutes natures appropriées.

[0085] De même, la deuxième interface de communication INT2 permet au terminal T1 de communiquer avec la carte bancaire DV1. Pour ce faire, la deuxième interface de communication INT2 établit une liaison de communication L2 avec la carte bancaire DV1. Cette liaison L2 peut être une liaison par contact ou une liaison sans contact, selon les moyens de communication dont dispose la carte bancaire DV1 et le cas d’usage.

[0086] Les liaisons L1 et L2 permettent d’échanger des données entre le terminal T1 et le serveur de gestion SV1 d’une part, et entre le terminal T1 et la carte à puce DV1 d’autre part. Ces données seront décrites plus en détail ultérieurement.

[0087] Par ailleurs, la carte bancaire DV1 est dans cet exemple une carte à puce EMV configurée pour traiter des transactions selon le standard EMV en coopération avec des terminaux externes tels que le terminal T1. La carte bancaire DV1 comprend un processeur 4, une interface de communication INT5, une première mémoire MR5 et une deuxième mémoire MR6. Ces composants sont compris dans une puce électronique (non représentée) de la carte DV1 , ou plus particulièrement dans un élément sécurisé de la carte à puce DV1.

[0088] La mémoire MR5 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par la carte bancaire DV1 , et sur lequel est enregistré un programme d’ordinateur PG3 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG3 comporte des instructions pour l’exécution de certaines étapes d’un procédé de traitement selon un mode de réalisation particulier qui sera décrit ultérieurement.

[0089] La mémoire MR6 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un identifiant d’utilisateur IDUR correspondant à l’utilisateur U R ainsi qu’une clé de chiffrement (ou clé cryptographique) K1. La mémoire MR6 peut éventuellement stocker d’autres données telles que notamment des données d’historique DH ou un compteur CT1. L’usage et l’intérêt de ces données seront décrits ultérieurement.

[0090] Selon un exemple particulier, les mémoires MR5 et MR6 forment une seule et même mémoire.

[0091] L’interface de communication INT5 permet au terminal T1 de communiquer avec terminal T1 , et plus particulièrement avec son interface de communication INT2. La carte à puce DV1 peut par exemple comprendre des contacts externes (de type ISO 7816 par exemple) situés à la surface du corps de la carte. Dans ce cas, la liaison L2 est une liaison par contact. Le terminal T1 peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d’établir une communication par contact avec la carte bancaire DV1. Selon un autre exemple, la carte à puce DV1 comprend une antenne (non représentée). Dans ce cas, la carte bancaire DV1 peut établir une liaison L2 sans contact avec le terminal T 1.

[0092] D’autre part, le serveur de gestion SV1 comprend un processeur 10, une première interface de communication INT10, une deuxième interface de communication INT 11 , une première mémoire MR10 et une deuxième mémoire MR11.

[0093] La mémoire MR10 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le serveur SV1 , et sur lequel est enregistré un programme d’ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG2 comporte des instructions pour l’exécution des étapes d’un procédé de gestion selon un mode de réalisation particulier qui sera décrit ultérieurement.

[0094] La mémoire MR11 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un cryptogramme MC1 généré par la carte à puce DV1 , des données d’entrée DM1 utilisées par la carte à puce DV1 pour générer le cryptogramme MC1 , des données de transaction DTR1 représentatives de la transaction TR1 et la clé de chiffrement K1. L’usage et l’intérêt de ces données seront décrits ultérieurement.

[0095] Selon un exemple particulier, les mémoires MR10 et MR11 forment une seule et même mémoire.

[0096] La première interface de communication INT10 permet au serveur de gestion SV1 de communiquer avec le terminal T 1. Pour ce faire, la première interface de communication INT10 établit une liaison de communication L1 avec le terminal T1 , et plus particulièrement avec son interface de communication INT1. Comme déjà indiqué, cette liaison L1 peut être filaire ou sans fil, et peut être de toutes natures appropriées.

[0097] La deuxième interface de communication INT11 permet au serveur de gestion SV1 de transmettre à l’utilisateur UR un ticket électronique TK1 généré par le serveur de gestion SV1 , ce ticket électronique étant représentatif de la transaction TR1. Ce ticket électronique TR1 constitue un ticket (ou reçu) numérique comportant diverses informations relatives à la transaction TR1 telles que par exemple la date, le montant, l’identifiant du terminal, le résultat de la transaction, etc. La transmission de ce ticket TK1 peut se faire via toutes liaisons L3 appropriées, notamment par l’envoi d’un email ou d’un SMS.

[0098] Par ailleurs, comme représenté en figure 3 selon un mode de réalisation particulier, le processeur 2 du terminal T1 piloté par le programme d’ordinateur PG1 met ici en œuvre un certain nombre de modules, à savoir : un premier module de réception MD2, un premier module de transmission MD4, un second module de réception MD6, un second module de transmission MD8, et éventuellement un module de gestion de stockage MD10.

[0099] Plus précisément, le premier module de réception MD2 est configuré pour recevoir, en provenance de la carte bancaire DV1 , des premières données DT1 comprenant un identifiant d’utilisateur IDUR identifiant l’utilisateur UR associé à la carte bancaire DV1.

[0100] Le premier module de transmission MD4 est configuré pour transmettre, à la carte bancaire DV1 , des deuxièmes données DT2 comprenant au moins un identifiant de terminal IDT1 identifiant le terminal T1. Ces deuxièmes données DT2 peuvent comprendre d’autres données comme expliqué ultérieurement, telles que notamment des données de transaction DTR1 caractérisant la transaction TR1.

[0101] Le deuxième module de réception MD6 est configuré pour recevoir, en provenance de la carte bancaire DV1 , un cryptogramme MC1 généré à partir d’une clé de chiffrement K1 et à partir de données d’entrée DM1 comprenant au moins l’identifiant IDT1 du terminal T1 et l’identifiant d’utilisateur IDUR. Les données d’entrée DM1 peuvent comprendre d’autres données, comme décrit ultérieurement, telles que les données de transaction DTR1 mentionnées ci- avant. Le deuxième module de réception MD6 peut en outre transmettre à la carte bancaires DV1 les données d’entrée DM1 et d’autres données selon le cas d’usage, comme décrit ci-après.

[0102] Le second module de transmission MD8 est configuré pour transmettre, au serveur de gestion SV1 , une requête de génération de ticket électronique RQ1. Cette requête RQ1 comprend au moins le cryptogramme MC1 , les données d’entrée DM1 et des données de transaction DTR2 caractérisant la transaction TR1 , et vise à déclencher la génération par le serveur de gestion DV1 d’un ticket électronique TK1 représentatif de la transaction TR1 , à partir des données transmises par le terminal T1.

[0103] Le cas échéant, le module de gestion de stockage MD10 permet de gérer le stockage de données d’historique DH dans la mémoire MR6 de la carte bancaire DV1. Pour ce faire, le module de gestion de de stockage MD10 peut envoyer à la carte bancaire DV1 des commandes CMD4 ou CMD5 comme décrit plus en détail ultérieurement.

[0104] Par ailleurs, comme représenté en figure 4 selon un mode de réalisation particulier, le processeur 10 du serveur SV1 piloté par le programme d’ordinateur PG2 met ici en œuvre un certain nombre de modules, à savoir : un module de réception MD20, un premier module de génération MD22, un module de vérification MD24, un second module de génération MD26, et éventuellement un module de traitement MD28.

[0105] Plus précisément, le module de réception MD20 est configuré pour recevoir, en provenance du terminal T1 , le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2 caractérisant la transaction TR1 ainsi que la requête de génération de ticket électronique RQ1. Comme déjà indiqué, le cryptogramme MC1 est préalablement généré par la carte à puce DV1 à partir des données d’entrées DM1 qui comprennent au moins l’identifiant d’utilisateur IDUR et l’identifiant de terminal IDT1.

[0106] Le premier module de génération MD22 est configuré pour générer un deuxième cryptogramme MC2 à partir d’une clé de déchiffrement et des données d’entrées DM1. Dans cet exemple la clé de déchiffrement est identique à la clé de chiffrement K1 utilisée par la carte bancaire DV1 pour générer le cryptogramme MC1.

[0107] Le module de vérification MD24 est configuré pour vérifier la validité de la requête de génération de ticket électronique RQ1 , et ce à partir d’une comparaison du premier cryptogramme MC1 reçu du terminal T1 avec le deuxième cryptogramme MC2 généré par le premier module de génération MD22.

[0108] Le second module de génération MD28 est configuré pour générer, si la requête RQ1 est valide, un ticket électronique TK1 représentatif de la transaction TR1 , à partir au moins des données d’entrée DM1 et / ou des données de transaction DTR2 reçues.

[0109] Le cas échéant, le module de traitement MD28 est configuré réaliser des traitements complémentaires tels que transmettre le ticket électronique TK1 à l’utilisateur UR et / ou à l’entité marchande MD, comme décrit par la suite.

[0110] Par ailleurs, comme représenté en figure 5 selon un mode de réalisation particulier, le processeur 4 de la carte bancaire DV1 piloté par le programme d’ordinateur PG3 met ici en œuvre un certain nombre de modules, à savoir : un premier module de transmission MD40, un module de réception MD42, un module de génération MD44, un second module de transmission MD46 et un module de stockage MD48.

[0111] Plus précisément, le premier module de transmission MD40 est configuré pour transmettre, au terminal T1 , les premières données DT1 comprenant au moins l’identifiant d’utilisateur IDUR identifiant l’utilisateur UR associé à la carte bancaire DV1.

[0112] Le module de réception MD42 est configuré pour recevoir, en provenance du terminal T1 , les deuxièmes données DT2 comprenant au moins l’identifiant de terminal IDT1 identifiant le terminal T1. Comme décrit plus en détail ultérieurement, les deuxièmes données peuvent comprendre d’autres données telles que les données de transaction DTR1 déjà mentionnées ci-avant.

[0113] Le module de génération MD44 est configuré pour générer le cryptogramme MC1 à partir de la clé de chiffrement K1 et des données d’entrée DM1 comprenant l’identifiant de terminal IDT1 et l’identifiant d’utilisateur IDUR (comme déjà indiqué).

[0114] Le second module de transmission MD46 est configuré pour transmettre, au terminal T1 , le cryptogramme MC1 et les données d’entrée DM1 pour permettre la transmission par le terminal T1 de la requête de génération de ticket électronique RQ1 au serveur de gestion SV1.

[0115] Le cas échéant, le module de stockage MD48 est configuré pour gérer le stockage, en local dans la mémoire MR6 de la carte bancaire DV1 , du cryptogramme MC1 ou encore de données d’historique DH, comme expliqué ci- après.

[0116] La configuration et le fonctionnement des modules MD2-MD10 du terminal T1 (figure 2), des modules MD20-MD28 du serveur de gestion SV1 (figure 3) et des modules MD40-MD48 de la carte bancaire DV1 (figure 4) apparaîtront plus précisément dans les exemples de réalisation décrits ci-après. On comprend que ces modules ne représentent qu’un exemple de mise en œuvre non limitatif de l’invention.

[0117] En variante, deux modules du terminal T1 , du serveur de gestion SV1 ou encore de la carte bancaire DV1 peuvent être mis en œuvre au sein d’un seul et même module, selon la configuration choisie. Ainsi, les premier et second modules de réception MD2, MD8 peuvent former un seul et même module du terminal T1 , l’identifiant d’utilisateur IDUR pouvant par exemple être transmis seulement dans les données d’entrée DM1. Il en va de même pour les premier et second modules de transmission MD40, MD46 de la carte bancaire DV1 , par exemple.

[0118] De manière générale, le terminal T1 , le serveur SV1 et la carte bancaire DV1 mettent chacun en œuvre un module respectif pour réaliser chaque opération ou étape d’un procédé correspondant de l’invention.

[0119] Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 6. Plus précisément, le terminal T1 et la carte bancaire DV1 mettent chacun en œuvre un procédé de traitement de l’invention en exécutant les instructions des programmes d’ordinateur PG1 et PG3, respectivement. De même, le serveur de gestion SV1 met en œuvre un procédé de gestion en exécutant les instructions du programme d’ordinateur PG2.

[0120] On suppose qu’une transaction EMV notée TR1 est initiée entre le terminal externe T1 et la carte bancaire CD1. Cette transaction TR1 fait appel à une coopération entre terminal T1 et la bancaire CD1 qui échangent ensemble des commandes ou messages conformément au standard EMV, comme déjà décrit dans un exemple particulier en figure 1.

[0121] Comme déjà indiqué, la transaction TR1 est une transaction de paiement EMV dans cet exemple. Plus particulièrement, on suppose que l’utilisateur U R utilise sa carte bancaire EMV DV1 pour réaliser la transaction de paiement TR1 auprès de l’enseigne commerçante MD. Pour ce faire, l’utilisateur U R insère sa carte bancaire DV1 dans le terminal T1 (transaction par contact) ou présente sa carte bancaire DV1 à proximité du terminal (transaction en sans contact).

[0122] Au cours d’une étape C4 de transmission, la carte bancaire C4 envoie au terminal T1 une commande CMD1 comportant une donnée DX1 indiquant que la carte bancaire DV1 supporte un service de tickets électroniques. Diverses manières de fournir cette donnée DX1 sont possibles. Selon un premier exemple, la commande CMD1 est une réponse de la carte bancaire DV1 à une commande SELECT APPLICATION envoyée préalablement par le terminal T1 conformément au standard EMV comme déjà décrit en référence à l’étape S6 de la figure 1.

[0123] Selon un deuxième exemple, la donnée DX1 peut être transmise dans la commande CMD1 sous la forme d’au moins un bit RFU (pour « Reserved for Future Use »), sous réserve qu’un tel bit RFU soit prévu par le standard EMV pour la commande CMD1 en question.

[0124] Selon un troisième exemple, la donnée DX1 est transmise dans une commande SELECT qui est envoyée par la carte bancaire DV1 au terminal T1 en réponse à une commande SELECT, comme déjà décrit en référence à l’étape S5b de la figure 1. Conformément au standard EMV, la commande SELECT est une réponse structurée selon le format TLV (pour « Tag-Length-Value ») et donc qui accepte d’être étendue avec des objets de données (dits « data objects » en anglais) supplémentaires. Selon ce troisième exemple, la commande SELECT comprend ainsi un tel objet supplémentaire de type TLV qui comprend la donnée DX1. Cet objet supplémentaire comporte un tag (qui identifie de manière unique l’objet), une longueur et une valeur.

[0125] Selon un quatrième exemple, cette donnée DX1 peut être transmise par la carte bancaire DV1 suite à la commande GET PROCESSING OPTIONS (GPO) envoyée par le terminal T1 , par exemple dans des données RECORD lues par le terminal T1 dans la carte bancaire DV1 lors d’une phase de lecture S8 de RECORDS déjà décrite en référence à la figure 1.

[0126] Le terminal T1 reçoit la commande CMD1 lors d’une étape B4 de réception.

Le terminal T1 détermine ainsi, à partir de la donnée DX1 , que la carte bancaire DV1 supporte un service de ticket électronique et en déduit que le procédé de l’invention peut être poursuivi comme expliqué ci-après.

[0127] Dans l’exemple considéré ici, lors de cette phase S8 de lecture, le terminal T1 envoie (B6) ainsi une requête RC1 que la carte bancaire DV1 reçoit lors d’une étape C6 de réception. En réponse à cette requête RC1 , la carte bancaire DV1 transmet (C8) au terminal T1 , en tant que RECORDS, des premières données DT1 comprenant au moins un identifiant d’utilisateur IDUR identifiant l’utilisateur U R associé à la carte bancaire DV1. Ces premières données DT1 peuvent éventuellement comprendre d’autres données telles qu’une adresse AD1 , correspondant au serveur SV1 , dont l’usage sera décrit ultérieurement.

[0128] Selon un exemple particulier, l’identifiant d’utilisateur IDUR est différent d’un identifiant de type PAN (pour « Primary Account Number ») associé à la carte bancaire DV1 . De manière avantageuse, cela permet de limiter la diffusion du PAN qui constitue une donnée sensible.

[0129] Le terminal T1 reçoit les premières données DT1 en B8. Le procédé se poursuit avec une phase S20 facultative d’authentification de l’utilisateur UR. Au cours de cette phase S20, le terminal T1 et la carte bancaire DV1 coopèrent par exemple ensemble pour vérifier le code personnel, dit code PIN, du porteur UR de la carte bancaire DV1 . Comme déjà décrit en référence à la figure 1 , d’autres modes de réalisation sont toutefois possibles dans lesquels le code PIN n’est pas vérifié, notamment lors d’une transaction de paiement sans contact.

[0130] Toujours en référence à la figure 6, le traitement de la transaction TR1 se poursuit avec une phase de vérification de la transaction, au cours de laquelle le terminal T1 réalise (B12) une analyse de risque (dite « Terminal Risk Management »), conformément au protocole EMV.

[0131] Après cette analyse B12, le terminal T1 transmet (B14) à la carte bancaire DV1 des deuxièmes données DT2 comprenant au moins un identifiant de terminal IDT1 identifiant le terminal T1. Ces deuxièmes données DT2 peuvent éventuellement comprendre d’autres données, telles qu’un identifiant IDMD identifiant l’entité marchande MD et / ou des données de localisation LOC spécifiant une position de cette entité marchande MD. Cette donnée LOC indique par exemple la position géographique de l’enseigne commerçante MD où se trouve le terminal T 1 .

[0132] Ces deuxièmes données DT2 peuvent par exemple être envoyées par le terminal T1 dans la commande GAC1 ou dans la commande GAC2, ces commandes étant toutes deux prévues dans le protocole EMV comme déjà décrit en référence respectivement aux étapes S9 et S16 de la figure 1.

[0133] La carte bancaire DV1 reçoit les deuxièmes données DT2 en C14 (figure 6) puis procède à une étape C16 de génération au cours de laquelle elle génère un cryptogramme MC1 à partir d’une clé de chiffrement K1 et de données d’entrée DM1 comprenant au moins l’identifiant de terminal IDT1 et l’identifiant d’utilisateur IDUR. Dans l’exemple considéré ici, le cryptogramme est un code MAC (pour « Message Authentification Code »). Comme décrit par la suite, ce code MC1 a pour objet de sécuriser le service de ticket électronique.

[0134] Les données d’entrées DM1 prises en compte par la carte bancaire DV1 pour générer le cryptogramme MC1 peuvent comprendre des données supplémentaires, notamment d’autres données également fournies par le terminal T1 dans les deuxièmes données DT2.

[0135] Dans le cas où le terminal T1 transmet en B14, dans les deuxièmes données DT2, l’identifiant de marchand IDMD et éventuellement la donnée de localisation LOC (déjà mentionnée) qui spécifie une position de l’entité marchande MD, alors la carte bancaire DV1 peut prendre en compte, en tant que données d’entrée DM1 , l’identifiant de marchand IDMD et éventuellement la donnée de localisation LOC dans la génération C16 du cryptogramme MC1.

[0136] Selon un exemple particulier, les deuxièmes données DT2 transmises en B14 par le terminal T1 comprennent également des données de transaction DTR1 représentatives de la transaction TR1 en cours. Dans ce cas, ces données de transaction DTR1 peuvent également être incluses dans les données d’entrée DM1 utilisées par la carte bancaire DV1 pour générer le cryptogramme MC1. Ces données DTR1 peuvent comprendre par exemple au moins l’un parmi : la date et / ou l’heure de la transaction TR1 , le montant de la transaction TR1 et la devise utilisée.

[0137] Selon un exemple particulier, chacune des données IDMD, LOC et DTR1 qui sont effectivement transmises à la carte bancaire DV1 dans les deuxièmes données DT2 sont utilisées en tant que données d’entrée DM1 par la carte bancaire DV1 pour générer le cryptogramme MC1 en C16. La prise en compte de ces données additionnelles permet de sécuriser d’avantage le procédé de l’invention.

[0138] Selon un exemple particulier, chacune des données transmises par le terminal T1 dans les deuxièmes données DT2 en B14 peut avoir été demandée au préalable par la carte bancaire DV1 , lors de la phase S8 de lecture, dans une liste CDOL (pour « Card Risk Management Data Object List ») conformément au protocole EMV. Ainsi, la carte bancaire DV1 peut demander dans la liste CDOL transmise en tant que RECORD en S8 que le terminal T1 lui transmette l’identifiant de terminal IDT1 , et éventuellement au moins l’une des données supplémentaires mentionnées ci-avant (IDMD, LOC et DTR1). L’envoi des deuxièmes données DT2 (B14) par le terminal T1 se fait alors en réponse à cette demande préalable de la carte bancaire DV1.

[0139] Selon un exemple particulier, la carte bancaire DV1 prend également en compte, en tant que données d’entrées CT1 , la valeur courante d’un compteur CT1 qui est incrémenté par la carte bancaire DV1 à chaque nouvelle transaction. Comme déjà indiqué, ce compteur CT 1 est stocké localement dans la mémoire MR6 (figure 2) de la carte bancaire DV1. L’utilisation d’un tel compteur CT1 permet de s’assurer que la valeur du cryptogramme généré en C16 (figure 6) varie à chaque transaction, améliorant ainsi encore d’avantage la sécurité du procédé de l’invention.

[0140] Selon une variante de réalisation, CT1 est une valeur aléatoire qui est générée par la carte bancaire DV1 à chaque nouvelle transaction. Comme indiqué ci-dessus, L’utilisation d’une telle valeur aléatoire permet de s’assurer que la valeur du cryptogramme généré en C16 (figure 6) varie à chaque transaction, améliorant ainsi encore d’avantage la sécurité du procédé de l’invention.

[0141] La carte bancaire DV1 transmet (C18) ensuite au terminal T1 une commande CMD2 comportant le cryptogramme MC1 ainsi que les données d’entrée DM1 pour permettre au terminal T1 de transmettre par la suite une requête de génération de ticket électronique au serveur de gestion SV1 , comme expliqué ci- après.

[0142] Selon un exemple particulier, cette commande CMD2 est envoyée par la carte bancaire DV1 en réponse à la commande GAC1 ou à la commande GAC2 qui ont déjà été décrites précédemment en référence respectivement aux étapes S9 et S16 de la figure 1. Cette commande CMD2 peut être envoyée au stade de la réponse TC ou AAC déjà décrite précédemment en référence à l’étape S18 de la figure 1. [0143] Selon un exemple particulier, la carte bancaire DV1 génère également une signature électronique pour valider la transaction TR1 en cours. Dans ce cas, cette signature électronique est également transmise (C18) au terminal T1 dans la commande CMD2. Cette signature électronique peut être générée par la carte bancaire DV1 à partir d’une clé de chiffrement autre que K1.

[0144] Comme déjà mentionné, la carte bancaire DV1 peut également contenir dans sa mémoire locale MR6 des données d’historique DH, notée ici DHO, associées à au moins une transaction TRO antérieure traitée par ladite carte DV1. Ces données d’historique DHO sont par exemple stockées localement dans la carte bancaire DV1 (dans MR6) lorsqu’il n’est pas possible de déclencher la génération d’un ticket électronique correspondant, comme expliqué ultérieurement. Ces données d’historique DHO peuvent comprendre, en association avec au moins une transaction antérieure TRO, un cryptogramme antérieur MCO, des données antérieures MDO et des données de transaction antérieures DTRO caractérisant ladite transaction antérieure TRO, le cryptogramme antérieur MCO ayant été généré par la carte bancaire DV1 à partir de la clé de chiffrement K1 et des données d’entrée antérieures DM0 (de façon identique à ce qui est décrit ci-avant en référence à l’étape C16).

[0145] Selon un exemple particulier, la carte bancaire DV1 transmet également en C18 les données d’historique DHO au terminal T1 (dans la commande CMD2 par exemple) afin de requérir la génération d’un ticket électronique d’au moins une transaction antérieure TRO.

[0146] Toujours en référence à la figure 6, le terminal T1 reçoit la commande CMD2 en B18 puis transmet au serveur de gestion SV1 une requête de génération de ticket électronique RQ1 comprenant au moins le cryptogramme MC1 , les données d’entrée DM1 et des données de transaction DTR2 caractérisant la transaction TR1 , pour requérir la génération par le serveur de gestion SV1 d’un ticket électronique représentatif de la transaction à partir des données transmises par le terminal T1.

[0147] Les données de transaction DTR2 peuvent comprendre tout ou partie des données de transaction DTR1. Dans un exemple particulier, les données de transaction DTR1 et DTR2 sont identiques. La nature et le nombre des données de transaction TR2 (date / heure, montant, devise...) que le terminal T2 choisit de fournir au serveur SV1 peuvent être adaptés selon le cas.

[0148] Dans le cas particulier où la carte bancaire DV1 a précédemment transmis, au terminal T1 , dans les premières données DT1 (étape C8, figure 6) une adresse AD1 correspondant au serveur de gestion SV1 , le terminal T1 peut utiliser cette adresse AD1 pour envoyer la requête RQ1 à destination du serveur de gestion SV1. Cette adresse AD1 peut être une adresse URL ou toute autre information permettant au terminal T1 de se connecter avec le serveur SV1.

[0149] Selon un exemple particulier, le terminal T1 inclus dans sa requête de génération de ticket électronique RQ1 un message MSG1 que le serveur de gestion SV1 doit prendre en compte pour générer un ticket électronique. Il est ainsi possible de personnaliser le ticket électronique en fonction de l’enseigne commerçante MD associée au terminal T 1.

[0150] Dans le cas particulier où le terminal T1 a également reçu en B18 (figure 6) les données d’historique DH0 stockées localement dans la carte bancaire DV1 , il peut aussi transmettre en B20, au serveur de gestion DV1 , en accompagnement de la requête RQ1 , les données d’historique DH0 pour requérir en outre la génération d’au moins un ticket électronique supplémentaire à partir de ces données d’historique DH0. Il est ainsi possible d’obtenir un ou des tickets électroniques relatifs à au moins une transaction antérieure TR0 dans le cas où il n’a pas été possible de les obtenir plus tôt, par exemple lors d’un traitement hors ligne d’une transaction EMV ou en raison d’un problème de connexion des terminaux qui ont traité les transaction antérieures avec un serveur de gestion.

[0151] Dans le cas particulier où le terminal T1 reçoit en B18 (figure 6) une signature électronique générer par la carte bancaire DV1 , celle-ci est également transmise en B20 au serveur de gestion DV1 avec la requête RQ1. Cette signature électronique permet au serveur de gestion DV de vérifier ultérieurement que la transaction TR1 est valide, comme expliqué ci-après.

[0152] Dans l’exemple considéré en figure 6, la requête RQ1 transmise par le terminal T1 en B20 comprend ainsi une concaténation du cryptogramme MC1 , des données d’entrée DM1 , des données de transaction DTR2 et éventuellement d’au moins l’une des données supplémentaires mentionnées ci-avant (MSG1 , DHO, SG1).

[0153] Le serveur de gestion SV1 reçoit la requête RQ1 et toutes les données associées en A20 (figure 6).

[0154] Au cours d’une étape A22 de génération, le serveur SV1 génère un deuxième cryptogramme MC2 à partir de la clé de déchiffrement K1 (identique dans cet exemple à la clé de chiffrement utilisé en C16 par la carte bancaire DV1 ) et à partir des données d’entrée DM1 reçues en A20 (figure 6). Pour ce faire, il procède de la même manière que la carte bancaire DV1 pour générer le cryptogramme MC1 en C16. Dans l’exemple considéré ici, le cryptogramme MC2 est donc un code MAC.

[0155] Le serveur de gestion SV1 vérifie (A24) ensuite la validité de la requête de génération de ticket électronique RQ1 , à partir d’une comparaison du premier cryptogramme MC1 reçu en A20 avec le deuxième cryptogramme MC2 calculé en A22. Grâce à cette vérification de cryptogramme, il est possible de sécuriser le processus de gestion de tickets électroniques dans la mesure où une demande de ticket électronique n’est acceptée que si le cryptogramme MC1 est valide.

[0156] Si les cryptogrammes MC1 et MC2 coïncident (MC1 = MC2), alors le procédé se poursuit à l'étape A28 de génération. Dans le cas contraire, le serveur de gestion DV1 bloque la génération d’un ticket électronique et transmet (A26) éventuellement un message négatif MSG2 indiquant que la requête RQ1 est refusée.

[0157] Au cours de l’étape A28 de génération, le serveur de gestion SV1 génère alors un ticket électronique TK1 représentatif de la transaction TR1 , et ce à partir au moins des données d’entrées DM1 et des données de transaction DTR2 reçues. Ce ticket électronique TK1 , appelé aussi e-ticket ou billet électronique, constitue un ticket dématérialisé qui remplace un ticket traditionnel par des informations numériques représentatives de la transaction TR1.

[0158] Le format du ticket électronique TK1 et la nature des informations qu’il contient peuvent varier selon le cas. Le ticket électronique TK1 comprend par exemple des données de type texte et / ou des données de type image. Le ticket électronique TK1 peut prendre la forme d’un fichier par exemple.

[0159] Selon un exemple particulier, le ticket électronique TK1 comprend au moins l’une parmi les données suivantes :

- les données de transaction DTR2 caractérisant la transaction TR1 ;

- l’identifiant de terminal IDT1 associé au terminal T1 ;

- l’identifiant d’utilisateur IDUR associé à l’utilisateur UR ;

- l’identifiant de marchand IDMD associé à l’enseigne commerçante MD ;

- la donnée de localisation LOC spécifiant une position de l’entité marchande MD ;

- le message prédéfini MSG1 associé à l’enseigne commerçante MD ; et

- un identifiant de type PAN, partiel ou complet, associé à la carte bancaire DV1.

[0160] Les données de transaction DTR2 peuvent comprendre au moins l’un parmi : la date et / ou heure de la transaction TR1 , le montant de la transaction TR1 , la devise utilisée, et le résultat de la transaction (réussie ou échouée). Le serveur de gestion DV1 peut éventuellement vérifier la validité de la signature électronique SG1 générée par la carte bancaire (lorsqu’une telle signature est effectivement générée et transmise au serveur de gestion SV1) et déduire de cette vérification le résultat de la transaction TR1.

[0161] Dans le cas particulier où le serveur de gestion SV a reçu les données d’historique DH0 relatives à au moins une transaction antérieure TR0 (comme déjà indiqué), il peut également générer un ticket électronique TKO pour chaque transaction antérieure TRO spécifiée dans ces données d’historique DHO. Cela permet à l’utilisateur U R d’obtenir un ticket électronique pour des transactions antérieures traitées en mode hors ligne par exemple, et donc où la connexion avec un serveur en charge de la gestion des tickets électroniques n’était pas possible.

[0162] Par la suite, le serveur de gestion SV1 peut réaliser toutes opérations de gestion appropriées en relation avec le ticket électronique TK1 ainsi généré (et, le cas échéant, avec le ou les tickets électroniques TKO des transactions antérieures).

[0163] Selon un exemple particulier, le serveur de gestion SV1 envoie (A30) par la suite le ticket électronique TK1 à l’utilisateur U R via la liaison de communication L3 (figure 2). Le serveur SV1 envoie par exemple le ticket électronique TK1 via un email ou un SMS. De la même manière, le serveur SV1 peut également transmettre à l’utilisateur UR le ou les éventuels tickets électroniques additionnels qu’il a générés, le cas échéant, en lien avec au moins une transaction antérieure TRO. Le serveur de gestion SV1 détermine à quelle adresse AD2 le ou les tickets électroniques doivent être envoyés à partir de l’identifiant d’utilisateur IDUR. Cette adresse AD2 peut être par exemple une adresse email ou un numéro de téléphone. Le serveur de gestion SV1 peut ainsi stocker dans sa mémoire une table associant pour une pluralité d’utilisateurs une adresse associée vers laquelle les tickets électroniques doivent être transmis.

[0164] Selon un exemple particulier, le serveur de gestion SV1 reçoit en A20 (figure

6), en provenance du terminal T1 , la requête de génération de ticket électronique RQ1 , le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2 et toutes autres éventuelles données associées via un premier canal de communication (L1). La transmission A30 du ticket électronique TK comme indiqué ci-avant peut alors être réalisée via un deuxième canal de communication différent du premier canal de communication. Par exemple, le serveur SV1 communique (A20) avec le terminal T1 via un réseau de télécommunication, et envoie (A30) le ticket électronique TK1 via un SMS, un email ou autre.

[0165] De manière alternative ou cumulative, le serveur de gestion SV1 peut également envoyer le ticket électronique TK1 à l’entité marchande MD de façon analogue à l’étape A30 d’envoi. Pour ce faire, le serveur SV1 peut envoyer le ticket électronique TK1 au terminal T1 (via la liaison L1 par exemple).

[0166] Selon un exemple particulier, le serveur de gestion SV1 transmet (A32) au terminal T 1 un message positif MSG3 indiquant que la requête de génération de ticket électronique RQ1 est acceptée. Le terminal T1 reçoit cette réponse positive MSG3 en B32. [0167] Selon un exemple particulier, sur réception de la réponse positive MSG3 du serveur de gestion SV1 à la requête RQ1 , le terminal T1 envoie (B34) en outre à la carte bancaire DV1 une commande de suppression CMD4 pour commander la suppression dans la mémoire locale MR6 de la carte bancaire DV1 des données d’historique DHO. Le terminal T1 peut éventuellement déclencher l’envoi B34 de la commande de suppression CMD4 si le message positif MSG3 inclus une information indiquant que les données d’historique DHO ont été prises en charge avec succès par le serveur de gestion DV1.

[0168] La carte bancaire DV1 reçoit la commande de suppression CMD4 lors d’une étape C34 de réception. Sur détection de cette commande CMD4, la carte bancaire DV1 supprime dans sa mémoire locale MR6 les données d’historique DHO.

[0169] L’invention permet une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.

[0170] Cette solution est écologique et permet de réduire les coûts liés à la production de tickets traditionnels, tout en permettant une meilleure gestion des tickets par l’utilisateur qui n’a plus besoin de stocker les tickets physiques.

[0171] Plus particulièrement, le serveur de gestion de l’invention, agissant en tant que tiers de confiance, est capable de prendre en charge une requête de génération de ticket électronique fournie par un terminal coopérant lors d’une transaction avec une carte bancaire (ou plus généralement avec un dispositif électronique). Le serveur de gestion peut vérifier la validité de la demande et déterminer à partir d’un identifiant d’utilisateur reçu depuis le terminal, vers quelle adresse le ou les tickets électroniques générés doivent être transmis. Il est ainsi possible d’éviter les erreurs de saisie, d’accélérer le traitement des transactions, tout en garantissant la sécurité du processus ainsi que la confidentialité des consommateurs vis-à-vis des enseignes commerçantes.

[0172] Par ailleurs, dans le mode de réalisation décrit en référence à la figure 6, le terminal T1 est capable de déclencher la génération d’un ticket électronique dans la mesure où une connexion (liaison L1 , figure 1) peut être établie entre le terminal T1 et le serveur de gestion SV1. En revanche, on peut envisager que dans certains cas le terminal T 1 ne sera pas en mesure de communiquer avec le serveur de gestion SV1 , par exemple dans le cas d’une transaction en mode hors ligne ou en raison d’un problème d’accès au réseau de communication ou encore d’une panne du serveur de gestion SV1.

[0173] Par ailleurs, le serveur de gestion SV1 peut décider de refuser de traiter la requête de génération de ticket électronique TK1 pour diverses raisons (problème technique, ressources insuffisantes...).

[0174] On décrit à présent en référence à la figure 7 un mode de réalisation particulier de l’invention dans lequel la requête de génération de ticket électronique RQ1 (figure 6) transmise par le terminal T1 n’est pas traitée avec succès par le serveur de gestion SV1.

[0175] Suite à l’envoi B20 (figure 6) de la requête RQ1 , le terminal vérifie (B40) s’il détecte la réception depuis le serveur de gestion SV1 d’une réponse positive. Comme indiqué ci-avant, la requête de génération de ticket électronique RQ1 peut ne pas être traitée avec succès par le serveur de gestion SV1 pour diverses raisons.

[0176] En l’absence d’une réponse positive MSG3 à la requête de génération de ticket (i.e. en cas d’absence de réponse du serveur de gestion SV1 ou d’une réponse négative MSG2), par exemple dans un délai prédéfini, le terminal T1 transmet (B42) à la carte bancaire DV1 une commande de stockage CMD5 requérant le stockage, dans une mémoire locale de ladite carte (i.e. MR6 dans cet exemple), de données d’historique notées DH1 pour permettre une transmission d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure. Cette requête ultérieure pourra faire intervenir le terminal T1 et / ou le serveur de gestion SV1 ou de quelconques autres terminaux et serveur de gestion prévus à cet effet. A cette fin, les données d’historique DH1 , associées à la transaction TR1 , comprennent au moins le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2, et toutes éventuelles autres informations pertinentes.

[0177] La carte bancaire DV1 reçoit cette commande de stockage CMD5 lors d’une étape C42 de réception. La carte bancaire DV1 procède alors à l’enregistrement (C44) localement dans sa mémoire MR6 des données d’historique DH1 associées à la transaction TR1.

[0178] La carte bancaire DV1 peut ainsi stocker localement les données d’historique nécessaires à la génération ultérieure d’un ticket électronique. La génération de ce e-ticket est ainsi différée jusqu’à ce qu’une requête ultérieure de ticket électronique soit acceptée et traitée par un serveur de gestion lors d’une transaction ultérieure. Cette variante permet de ne pas perdre les données permettant de créer un ticket électronique lorsqu’un problème empêche d’obtenir immédiatement un tel ticket électronique depuis le serveur de gestion concerné.

[0179] Selon un exemple particulier, la carte bancaire DV1 vérifie si elle dispose d’un espace mémoire suffisant (dans sa mémoire MR6) avant l’étape C44 d’enregistrement. Elle ne procède ainsi à cet enregistrement C44 que si elle dispose d’un espace mémoire suffisant.

[0180] On décrit à présent en référence à la figure 8 un mode de réalisation particulier de l’invention dans lequel la carte bancaire DV1 bloque dans certains cas la transmission du cryptogramme MC1 permettant au terminal T1 de demander au serveur de gestion SV1 la création d’un ticket électronique.

[0181] Plus précisément, comme déjà décrit en référence à la figure 6, on suppose que la carte bancaire DV1 reçoit en C14 notamment l’identifiant de marchand IDMD dans les deuxièmes données DT2 transmises par le terminal T 1.

[0182] Après avoir déterminé (C14) l’identifiant de marchand IDMD associé à l’entité marchande MD, la carte bancaire DV1 vérifie (C50) si cet identifiant correspond à un marchand prédéfini. Pour ce faire, la carte bancaire DV1 compare par exemple l’identifiant de marchand IDMD avec une liste d’au moins un identifiant de marchand prédéfini. Si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini, le procédé se poursuit à l’étape C52 de blocage. Sinon, le procédé se poursuit avec les étapes C16 puis C18, comme déjà décrit ci-avant en référence à la figure 6.

[0183] A l’étape C52 (figure 8), la carte bancaire DV1 bloque la génération (C16) du cryptogramme MC1. Par voie de conséquence, la carte bancaire DV1 ne transmet pas en C18 le cryptogramme MC1 et les données associées au terminal T1 comme décrit ci-avant en référence à la figure 6. En revanche, la carte bancaire DV1 peut envoyer au terminal T 1 une indication de refus de ticket électronique.

[0184] Autrement dit, la carte bancaire DV1 vérifie (C50) si l’identifiant de marchand IDMD correspond à un marchand prédéfini et ne transmet en C18 (figure 6) le cryptogramme MC1 au terminal T1 que si l’entité marchande MD ne correspond pas à un marchand prédéfini.

[0185] Il est ainsi possible de mettre en œuvre un mécanisme de masquage pour éviter la génération d’un ticket électronique lorsque ce service n’est pas souhaité par l’utilisateur UR pour des raisons de sécurité ou confidentialité liées au marchand MD.

[0186] On décrit à présent en référence à la figure 9 un mode de réalisation particulier de l’invention dans lequel la carte bancaire DV1 bloque dans certains cas le stockage dans sa mémoire locale de données visant à générer ultérieurement un ticket électronique.

[0187] Plus précisément, comme déjà décrit en référence à la figure 6, on suppose que la carte bancaire DV1 reçoit en C14 notamment l’identifiant de marchand IDMD dans les deuxièmes données DT2 transmises par le terminal T1.

[0188] Après avoir déterminé (C14) l’identifiant de marchand IDMD associé à l’entité marchande MD, on suppose également que la carte bancaire DV1 reçoit une commande CMD5 de stockage comme déjà décrit ci-avant en référence à la figure 7.

[0189] Au cours d’une étape C60, la carte bancaire DV1 vérifie si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini. Pour ce faire, la carte bancaire DV1 compare par exemple l’identifiant de marchand IDMD avec une liste d’au moins un identifiant de marchand prédéfini. Si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini, le procédé se poursuit à l’étape C62 de blocage. Sinon, le procédé se poursuit à l’étape C44 au cours de laquelle la carte bancaire DV1 enregistre localement les données d’historique DH1 , comme déjà décrit ci-avant en référence à la figure 7.

[0190] A l’étape C62 (figure 9), la carte bancaire DV1 bloque l’enregistrement dans sa mémoire locale MR6 des données d’historique DH1. La carte bancaire DV1 peut envoyer au terminal T1 une indication de refus de stockage des données d’historique DH1 .

[0191] Autrement dit, la carte bancaire DV1 vérifie (C60) si l’identifiant de marchand IDMD correspond à un marchand prédéfini et ne procède au stockage en C44 (figure 7) des données d’historique DH1 dans sa mémoire locale MR6 que si l’entité marchande MD ne correspond pas à un marchand prédéfini.

[0192] Il est ainsi possible de mettre en œuvre un mécanisme de masquage pour éviter le stockage localement dans la carte bancaire DV1 de données d’historique permettant la génération ultérieure d’un ticket électronique associé à la transaction concernée. Un tel blocage est par exemple réalisé lorsque le service d’e-ticket n’est pas souhaité par l’utilisateur UR pour des raisons de sécurité ou confidentialité liées au marchand MD.

[0193] Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.