L'invention concerne le domaine du paiement au moyen de terminaux mobiles. Plus précisément, l'invention concerne un procédé pour l'exécution d'une transaction entre un premier et un deuxième terminal mobile par l'intermédiaire d'un serveur de paiement accédé à travers un réseau de télécommunications.

L'invention trouve une application particulièrement intéressante dans des applications de paiement sur mobile (le terme habituellement utilisé pour ces applications est le terme anglais « mobile banking »), qui permettent à des utilisateurs de payer des biens, des factures, au moyen de leur téléphone mobile.

On connaît le service « Orange Money », offert par Orange qui permet à des populations non bancarisées d'effectuer des opérations financières au moyen de leur terminal mobile. Des utilisateurs de terminaux mobiles qui souscrivent à ce service se voient attribuer un compte associé, sur lequel ils peuvent effectuer différentes opérations. Les comptes sont gérés par un opérateur de réseau mobile, à travers un serveur de paiement du réseau. Différentes options de services, accessibles depuis le terminal mobile, sont ainsi offertes ; par exemple le paiement marchand qui permet d'acheter un bien chez un marchand également abonné au service, ou le transfert d'argent de compte à compte entre deux abonnés au service. L'interface de ce service est offerte par le réseau, via le canal « USSD » (de l'anglais « Unstructured Supplementary Service Data »), fonctionnalité de base du standard « GSM » (pour « Global System for Mobile communications »). Lors de l'exécution d'une transaction, des instructions de paiement sont transmises des terminaux mobiles au serveur de paiement qui débite et/ou crédite les comptes associés aux utilisateurs des terminaux mobiles.

Cependant, pour que des transactions bancaires soient mises en œuvre, il est impératif que les acteurs du paiement disposent d'un accès au réseau mobile lors de la transaction de manière à transmettre les informations de la transaction au serveur de paiement. L'accès au réseau ne peut cependant être garanti en continu dans des zones géographiques étendues où les infrastructures ne sont pas présentes partout et/ou sont parfois indisponibles. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.

A cette fin l'invention propose un procédé d'exécution d'une transaction entre un premier et un deuxième terminal mobile dans un réseau de communication mobile, le procédé comprenant les étapes suivantes, mises en œuvre par le premier terminal lorsque le premier et le deuxième terminal sont hors couverture du réseau de communication : - envoi, en communication pair à pair au deuxième terminal, d'une requête de transaction courante, ladite requête comprenant un identifiant unique de transaction et des informations relatives à la transaction courante,

- réception, en communication pair à pair, en provenance du deuxième terminal mobile, d'un premier contrat électronique pour la transaction courante, ledit premier contrat constituant une preuve que la transaction a été validée par un utilisateur du deuxième terminal,

- génération d'un deuxième contrat électronique pour la transaction courante, ledit deuxième contrat constituant une preuve que la transaction a été validée par un utilisateur du premier terminal,

- envoi au deuxième terminal en communication pair à pair du deuxième contrat électronique.

Le procédé selon l'invention permet ainsi d'exécuter des transactions de paiement dans le cadre d'un service de paiement proposé par le réseau de communication, même lorsque les terminaux mobiles ne sont pas sous couverture réseau. Plus précisément, deux contrats sont générés : un premier et un deuxième contrat. Le premier contrat qui constitue une preuve que la transaction a été exécutée et validée par l'utilisateur du premier terminal est généré sur le premier terminal et envoyé au moyen d'une communication pair à pair au deuxième terminal mobile. Le deuxième contrat, qui constitue une preuve que la transaction a été exécutée et validée par l'utilisateur du deuxième terminal est généré sur le deuxième terminal et envoyé au moyen d'une communication pair à pair au premier terminal mobile. Ainsi, le premier terminal mobile, respectivement le deuxième terminal mobile, détient deux contrats qui ont trait à la même transaction et qui prouvent que les utilisateurs des deux terminaux mobiles ont chacun approuvé la transaction. Ces deux contrats sont destinés à être transmis à un serveur de paiement du réseau par l'un ou l'autre ou les deux terminaux, dès que l'un ou l'autre ou les deux terminaux est sous couverture réseau. Les étapes du procédé décrit précédemment sont mises en œuvre sur le terminal d'un utilisateur créditeur lors de l'exécution de la transaction hors ligne. Le procédé décrit ici permet de compléter avantageusement des solutions de paiement mobile. En particulier, des transactions peuvent être exécutées lorsque les terminaux sont hors couverture réseau, ce qui n'est pas inhabituel dans des pays très étendu où les infrastructures réseau ne sont pas présentes partout et/ou sont parfois indisponibles.

L'invention concerne également un procédé d'exécution d'une transaction entre un premier et un deuxième terminal mobile dans un réseau de communication mobile, le procédé comprenant les étapes suivantes, mises en œuvre par le deuxième terminal lorsque le premier et le deuxième terminal sont hors couverture du réseau de communication : - réception, en communication pair à pair, en provenance du premier terminal, d'une requête de transaction courante, ladite requête comprenant un identifiant unique de transaction et des informations relatives à la transaction courante,

- génération d'un premier contrat électronique pour la transaction courante, ledit premier contrat constituant une preuve que la transaction a été validée par un utilisateur du deuxième terminal,

- envoi au premier terminal en communication pair à pair, du premier contrat électronique pour la transaction courante,

- réception, en communication pair à pair, en provenance du premier terminal, d'un deuxième contrat, ledit deuxième contrat constituant une preuve que la transaction a été validée par un utilisateur du premier terminal.

Les étapes du procédé décrites ici sont celles qui sont mises en œuvre sur le terminal d'un utilisateur débiteur lors de l'exécution de la transaction hors ligne.

Avantageusement, le procédé décrit précédemment comprend une étape d' authentification de l'utilisateur du deuxième terminal, l'étape de génération du premier contrat n'étant exécutée que si authentification est positive.

Il y a ainsi authentification de l'utilisateur lors d'une transaction au cours de laquelle le compte de l'utilisateur du deuxième terminal est destiné à être débité au profit du compte associé à l'utilisateur du premier terminal.

Dans un exemple de réalisation, le procédé décrit précédemment comprend une étape de génération d'un aléa, ledit aléa étant ajouté au premier contrat lors de la génération dudit premier contrat.

La génération de l'aléa est destinée à éviter des attaques par rejeu de contrats. En effet, le serveur de paiement mémorise tous les contrats qu'il reçoit et qu'il compense. L'aléa permet de détecter que des contrats ont déjà été traités.

Selon un exemple de réalisation des procédés décrits précédemment, l'un au moins des deux terminaux est sous couverture du réseau de communication, le procédé comprenant les étapes suivantes, mises en œuvre par le au moins un terminal mobile :

- envoi d'une requête de compensation à un serveur de paiement, ladite requête de compensation comprenant le premier et le deuxième contrat associés à la transaction courante,

- réception en provenance du serveur, d'un message d'acquittement destiné à informer le terminal que la transaction courante a été exécutée,

- suppression du premier et du deuxième contrat.

Le procédé de l'invention permet à l'un des terminaux mobiles, après exécution d'une transaction hors ligne entre le premier et le deuxième terminal, de compenser réellement la transaction auprès du serveur de paiement, dès que celui-ci est sous couverture réseau. En effet, les comptes associés aux utilisateurs des premier et deuxième terminaux sont gérés par le serveur de paiement et la compensation de transactions exécutées hors ligne est réalisée en premier lieu, avant tout autre transaction en temps réel avec le serveur.

Avantageusement, le procédé décrit ci-dessus comprend une étape de réception, en provenance du serveur de paiement, d'un message de mise à jour de données de configuration initiales, comprenant au moins une nouvelle valeur de donnée initiale de configuration de service,

- une étape de mise à jour de la donnée initiale de configuration de service.

La mise à jour de données de configuration initiale par le serveur de paiement permet d'éviter des incohérences entre les valeurs des données de configuration initiale de service stockées et utilisées par les terminaux lors de l'exécution des transactions hors ligne et les valeurs des données stockées et gérées par le serveur de paiement. Par exemple des variations du solde d'un compte peuvent être répercutées sur un plafond de paiement autorisé utilisé lors de transactions hors ligne.

L'invention concerne aussi un procédé de compensation d'une transaction de paiement exécutée entre un premier et un deuxième terminal d'un réseau de communication, ledit réseau comprenant un serveur de paiement, dans lequel l'un au moins des deux terminaux est sous couverture du réseau de communication, le procédé comprenant les étapes suivantes, mises en œuvre par le serveur de paiement :

- réception d'une requête de compensation, en provenance dudit au moins un terminal mobile, ladite requête comprenant un premier et un deuxième contrat associés à une transaction courante exécutée entre le premier et le deuxième terminal mobile hors couverture du réseau de communication,

- compensation de la transaction à partir des premier et deuxième contrats,

- envoi au terminal mobile d'un message d'acquittement destiné à informer le terminal que la transaction courante a été exécutée.

L'invention porte aussi sur un terminal utilisateur d'un réseau de communication, ledit terminal étant adapté pour exécuter une transaction avec un deuxième terminal utilisateur lorsque les terminaux sont hors couverture du réseau de communication, ledit terminal comprenant :

- des moyens d'envoi et de réception, agencés pour envoyer et recevoir en communication pair à pair avec le deuxième terminal, une requête de transaction courante, ladite requête comprenant un identifiant unique de transaction et des informations relatives à la transaction courante, - des moyens de génération, agencés pour générer un premier contrat, ledit premier contrat constituant une preuve que la transaction courante a été validée par un utilisateur du terminal,

- des moyens d'envoi et de réception de contrats, agencés pour envoyer au deuxième terminal en communication pari à pair le premier contrat, et pour recevoir en provenance du deuxième terminal en communication pair à pair, un deuxième contrat électronique, ledit deuxième contrat constituant une preuve que la transaction a été validée par un utilisateur du deuxième terminal.

L'invention concerne aussi un serveur de paiement d'un réseau de communication, apte à exécuter une transaction entre un premier et un deuxième terminal du réseau de communication, l'un au moins des deux terminaux étant sous couverture du réseau de communication, ledit serveur comprenant :

- des moyens de réception, en provenance dudit au moins un terminal mobile, d'une requête de compensation, ladite requête comprenant un premier et un deuxième contrat associés à une transaction courante exécutée entre le premier et le deuxième terminal mobile hors couverture du réseau de communication,

- des moyens de compensation de la transaction, agencés pour exécuter la transaction sur le serveur à partir des premier et deuxième contrats,

- des moyens d'envoi, agencés pour envoyer au terminal un message d'acquittement destiné à informer le terminal que la transaction courante a été exécutée.

L'invention concerne également un programme d'ordinateur destiné à être installé dans une mémoire d'un terminal utilisateur, comprenant des instructions pour la mise en œuvre des étapes du procédé d'exécution d'une transaction selon l'invention, lorsque le programme est exécuté par un processeur du dispositif utilisateur.

L'invention porte aussi sur un support de données sur lequel est enregistré le programme décrit précédemment.

L'invention concerne aussi un programme d'ordinateur destiné à être installé dans une mémoire d'un serveur de paiement, comprenant des instructions pour la mise en œuvre des étapes du procédé d'exécution d'une transaction, lorsque le programme est exécuté par un processeur du serveur de paiement.

L'invention concerne aussi un support de données sur lequel est enregistré le programme décrit précédemment.

L'invention concerne également un système d'exécution de transactions, comprenant un serveur de paiement selon l'invention et au moins deux terminaux utilisateur selon l'invention. D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels :

- la figure 1A présente les étapes d'un procédé d'exécution d'une transaction entre un premier terminal et un deuxième terminal, lorsque les terminaux sont hors couverture réseau, selon un exemple de réalisation ;

- la figure 1B présente les étapes d'un procédé de compensation d'une transaction exécutées hors ligne, lorsque l'un des terminaux passe sous couverture réseau, selon un exemple de réalisation de l'invention ;

- la figure 2 est une représentation schématique d'un serveur de paiement, selon un exemple de réalisation de l'invention ;

- la figure 3 est une représentation schématique d'un terminal mobile, selon un exemple de réalisation de l'invention.

Les étapes d'un procédé de mise en œuvre d'une transaction entre un premier et un deuxième terminal, selon un exemple de réalisation de l'invention, vont maintenant être décrites en relation avec les figures 1A et 1B.

Un premier utilisateur (non représenté sur la figure 1) est équipé d'un terminal mobile 10 muni d'un élément de sécurité 101. Un deuxième utilisateur (non représenté sur la figure 1A) est équipé d'un terminal mobile 11 muni d'un élément de sécurité 111. Un élément de sécurité 101, 111, d'un terminal mobile 10, 11 constitue un environnement sécurisé. Un environnement sécurisé est un environnement dans lequel des applications sont stockées et exécutées de manière sécurisée et des données sont stockées de manière sécurisée. Les éléments de sécurité 101, 111 sont par exemple des cartes d'identité d'abonné, ou cartes « SIM » (de l'anglais « Subscriber Identity Module »), insérées dans les terminaux mobiles 10, 11, ou des cartes « UICC » (pour « Uni versai Integrated Circuit Card »), ou des composants « TPM » (de l'anglais « Trusted Platform Module »). Le terminal mobile du premier utilisateur est appelé par la suite premier terminal 10. Le terminal du deuxième utilisateur est appelé par la suite deuxième terminal 11.

Les utilisateurs des premier et deuxième terminaux 10, 11 ont souscrit à un service de paiement en ligne auprès d'un opérateur d'un réseau de communication (non représenté sur les figures). Les premier et deuxième terminaux mobiles 10 et 11 sont adaptés pour communiquer avec un serveur de paiement 20 accessible à travers le réseau de communication. Le serveur de paiement 20 gère des comptes qui ont été attribués aux utilisateurs dans le cadre de leur abonnement au service de paiement. Lorsqu'une transaction est exécutée entre le premier et le deuxième terminal mobile 10, 11, les comptes associés sont crédités/débités selon la transaction. Le réseau de communication est par exemple un réseau téléphonique de type « GSM » (de l' anglais « Global System for Mobile communications »), ou un réseau de données de type Internet accessible depuis les premier et deuxième terminaux mobiles 10, 11 , au moyen de protocoles de communication, par exemple à travers un réseau WiFi.

L'exécution d'une transaction entre le premier et le deuxième terminal mobile 10, 11 se déroule en deux phases : une première phase d'exécution pendant laquelle le premier et le deuxième terminal 10, 11 n'ont pas accès au réseau de communication. Les terminaux 10, 11 sont dits hors ligne, ou hors couverture réseau. Lorsqu'ils sont hors ligne, les terminaux n'ont donc pas accès au serveur de paiement 20 du réseau. Bien que hors ligne, les deux terminaux sont cependant aptes à exécuter une transaction en communication pair à pair, par exemple en Bluetooth ou en « NFC » (de l' anglais « Near Field Communication »). La phase d'exécution de la transaction lorsque les premier et deuxième terminaux 10, 11 , sont hors ligne est décrite en relation avec la figure 1A.

Au cours d'une deuxième phase, appelée phase de compensation et de mise à jour, au moins un terminal mobile parmi le premier et le deuxième terminal 10, 11 est sous couverture du réseau de communication et peut accéder au serveur de paiement 20. Dans ce cas, le serveur de paiement 20 est apte à répercuter sur les comptes des utilisateurs des terminaux mobiles 10, 11 , qu'il gère, les transactions qui ont été exécutées hors ligne. La phase de compensation et de mise à jour est décrite en relation avec la figure 1B.

On suppose que les premier et deuxième terminaux mobiles 10, 11 hébergent une application de paiement qui comprend des instructions de code pour mettre en œuvre l'exécution d'une transaction de paiement entre terminaux mobiles et la compensation. L' application de paiement, accessible par les utilisateurs depuis une interface utilisateur du terminal mobile 10, 11 , comprend des instructions qui sont exécutées par les éléments de sécurité 101 , 111.

Dans une phase préalable de configuration, non représentée sur la figure 1A, il a été distribué aux utilisateurs des premier et deuxième terminaux 10, 11 , des données de sécurité destinées à sécuriser des échanges de données entre le premier et le deuxième terminal 10, 11 et/ou entre les terminaux mobiles 10, 11 et le serveur de paiement 20. Dans un exemple de réalisation, les données de sécurité ont été délivrées dans le cadre d'une infrastructure à clés publiques. Ainsi, une Autorité de Certification du réseau (non représentée sur la figure 1A) a généré et distribué des couples de clé privée/clé publique et des certificats de clé publique aux utilisateurs des terminaux mobiles 10, 11. Un premier couple de clés privée/publique Ksioi/Κριοι et un certificat Cioi de la clé publique ont été générés pour l'utilisateur du premier terminal mobile 10. La clé privée Ksioi a été installée dans l'élément de sécurité 101 du premier terminal mobile 10. La clé privée Ksioi n'est jamais extraite ni transmise hors de l'élément de sécurité 101. De même, un deuxième couple de clés privée/publique Ksin/Kpin et un certificat Cm de la clé publique ont été générés pour l'utilisateur du deuxième terminal mobile 11. La clé privée Ksm a été installée dans l'élément de sécurité 111. Les certificats Cioi et Cm sont par exemple des certificats conformes à la recommandation X.509v2 et comprennent de manière classique un identifiant des utilisateurs à qui les certificats ont été délivrés. Dans un exemple de réalisation, l'identifiant des utilisateurs est un numéro « MSISDN » (de l'anglais « Mobile Station ISDN Number »), correspondant au numéro de téléphone sur lequel ils peuvent être joints sur leur terminal mobile 10, 11. Dans un autre exemple de réalisation, l'identifiant des utilisateurs est une adresse e-mail. En tout état de cause, on suppose que l'identifiant des utilisateurs précisé dans les certificats permet au serveur de paiement 20 d'établir un lien entre un utilisateur et le compte qu'il gère pour l'utilisateur.

Les utilisateurs des premier et deuxième terminaux 10, 11 peuvent être engagés dans différents types de transactions. Dans l'exemple décrit ici, l'utilisateur du premier terminal 10 est un marchand, qui propose des biens à la vente, et l'utilisateur du deuxième terminal 11 est un particulier qui souhaite acheter un bien proposé par le marchand.

On suppose que dans une phase d'exécution antérieure de l'application de paiement (non représentée sur la figure 1A), des données de configuration initiale de service ont été initialisées par le serveur de paiement 20 sur les terminaux mobiles 10, 11, lorsque les terminaux étaient sous couverture réseau. Les données de configuration initiale du service ont été initialisées conformément à des règles de configuration définies au niveau du serveur de paiement 20 pour les utilisateurs abonnés. Par exemple, le serveur de paiement 20 a mis à jour un plafond de paiement autorisé sur le deuxième terminal 11, plus précisément sur l'élément de sécurité 111. Le plafond de paiement autorisé correspond à un crédit maximal dont l'utilisateur du deuxième terminal mobile 11 dispose pour l'exécution de transactions hors ligne, c'est-à-dire de transactions exécutées lorsque le deuxième terminal mobile 11 n'est pas sous couverture du réseau de communication et n'est donc pas apte à communiquer avec le serveur de paiement 20 pour exécuter une transaction en temps réel. On comprend que le plafond de paiement autorisé est une donnée de configuration qui concerne exclusivement les utilisateurs susceptibles d'être débiteurs lors de l'exécution de transactions de paiement. D'autres exemples de données de configuration initiale de service sont un nombre maximal de transactions qui peuvent être exécutées hors ligne, un montant maximum d'une transaction, etc. La donnée de configuration initiale de service correspondant au nombre maximal de transactions est par exemple initialisée sur le premier terminal mobile 10. Les données de configuration initiale de service sont des données sensibles, qui ne doivent pas pouvoir être modifiées par les utilisateurs, ou par un programme malveillant. Dans l'exemple de réalisation décrit ici, les données de configuration initiale de service sont mémorisées dans les éléments de sécurité 101, 111 des terminaux mobiles 10, 11. Dans un autre exemple de réalisation, les données de configuration initiale de services sont mémorisées de manière sécurisée dans les terminaux mobiles 10, 11. Elles sont par exemple mémorisées chiffrées.

Dans une étape initiale E0, l'utilisateur du premier terminal mobile 10 et l'utilisateur du deuxième terminal mobile 11, en présence l'un de l'autre, souhaitent exécuter une transaction. L'utilisateur du deuxième terminal 11 souhaite acheter un bien à l'utilisateur du premier terminal 10 en contrepartie d'une somme d'argent. Il doit donc transmettre la somme au destinataire pour finaliser la transaction. Cependant, les premier et deuxième terminaux mobiles 10, 11, sont hors couverture réseau. Le serveur de paiement 20 n'est donc pas accessible via le réseau pour exécuter la transaction.

Dans de premières étapes de lancement El, Ε , l'utilisateur du premier terminal 10 et l'utilisateur du deuxième terminal 11 lancent sur leur terminal respectif l'application de paiement. Un menu comprenant les différentes options de l'application est transmis à une interface utilisateur des premier et deuxième terminaux 10, 11. Dans l'exemple décrit ici, l'interface utilisateur est un écran et les options de service sont affichées sur l'écran des terminaux mobiles, 10,11. Dans un autre exemple de réalisation, les options sont énoncées sur un haut-parleur des terminaux mobiles 10, 11.

Dans une étape E2 de sélection et de saisie, l'utilisateur du premier terminal 11 choisit un type de transaction à effectuer, par exemple « vente ». Un numéro unique de transaction, propre à la transaction courante est généré par l'élément de sécurité 101 et l'utilisateur du premier terminal 10 saisit des informations nécessaires à la transaction, telles que le montant de la transaction courante. On suppose que le deuxième terminal mobile 11 reste en attente d'une sollicitation du premier terminal 10. Dans une variante de réalisation, l'utilisateur du deuxième terminal mobile 11 choisit le type de transaction, par exemple « achat » sur son interface utilisateur et saisit les informations de transaction.

Dans une étape E3 de négociation et d'authentification mutuelle, le premier et le deuxième terminal mobile 10, 11, initient en communication pair à pair la négociation d'une clé de session destinée à protéger les échanges entre les deux terminaux 10, 11. La communication pair à pair est par exemple réalisée au moyen d'une communication en champ proche, par exemple en NFC, ou en BlueTooth. Dans un autre exemple de réalisation, la communication pair à pair est mise en œuvre de manière centralisée, par l'intermédiaire d'une borne de type WiFi, ou d'un équipement d'un réseau local. La négociation de la clé de session utilise par exemple le protocole « IKEv2 » (de l'anglais « Internet Key Exchange, version 2 »). De manière connue, le protocole IKEv2 inclut, en début de négociation une authentification mutuelle des tiers qui communiquent, qui peut utiliser des clés publiques. Plus précisément, authentification se déroule entre l'élément de sécurité 101 du premier terminal 10 et l'élément de sécurité 111 du deuxième terminal 11. Le protocole IKEv2 utilise les certificats Cioi et Cm et les clés privées et publiques Ks ₁₀ i/Kp ₁₀ i, Ks _m /Kp _m . L' authentification mutuelle a pour but de s' assurer que les éléments de sécurité 101 et 111 ont été délivrés par le même opérateur de réseau, ou par des opérateurs qui se font confiance, et que les éléments de sécurité 101 , 111 , sont connus du même serveur de paiement 20. Par ailleurs, le protocole IKEv2 permet d'établir un canal sécurisé entre les deux éléments de sécurité 101 , 111 au moyen de la clé de session négociée. La clé de session ainsi négociée est destinée à sécuriser des échanges de données entre les deux terminaux mobiles 101 , 111. L'utilisation du protocole IKEv2 permet ainsi aux utilisateurs des terminaux mobiles 10, 11 de s'authentifier mutuellement, par le biais des données comprises dans les certificats qui leur ont été délivrés, sans divulguer leur identité à un quelconque acteur externe. D' autre part, il permet d'établir un canal sécurisé entre les deux éléments de sécurité 101 , 111 , de manière à protéger les échanges relatifs à la transaction courante. Ainsi, l' anonymat des utilisateurs et la confidentialité des données sont garantis.

Dans une étape E4 d'envoi d'une requête de transaction, mise en œuvre une fois la clé de session calculée, le premier terminal mobile 10 envoie une requête de transaction au deuxième terminal mobile 11 en communication pair à pair. La requête de transaction comprend l'identifiant unique de la transaction généré précédemment et des informations relatives à la transaction en cours, telles que le type de la transaction, ici vente, le montant de la transaction, un identifiant de l'utilisateur du premier terminal 10, par exemple le numéro MSISDN associé au premier terminal mobile 10 et stocké dans l'élément de sécurité 101. L'envoi de la requête est fait de manière sécurisée, chiffré au moyen de la clé de session calculée précédemment. La requête de transaction est reçue par le deuxième terminal mobile 11 au cours d'une étape E5 de réception.

Dans une étape E6 d'affichage, consécutive à l'étape E5 de réception de la requête de transaction par le deuxième terminal mobile 11 , les informations de la transaction courante sont affichées sur l'écran du deuxième terminal mobile 11. L' affichage des informations de transaction constitue un récapitulatif de la transaction pour l'utilisateur du deuxième terminal mobile 11.

Dans une étape E7 d' authentification, exécutée si l'utilisateur du deuxième terminal 11 est d'accord avec les informations de transaction affichée au cours de l'étape précédente, l'élément de sécurité 111 du deuxième terminal mobile 11 authentifie l'utilisateur afin de valider la transaction courante. En effet, dans le cadre de la transaction courante, l'utilisateur du deuxième terminal mobile 11 est débiteur. Il est donc nécessaire de s'assurer de sa légitimité. A cette fin, l'utilisateur saisit un code « PIN » de service (de l'anglais « Personal Identification Number »). Si authentification basée sur la saisie classique du code PIN échoue (branche « nok » sur la figure 1A), alors le procédé s'arrête.

Si authentification réussie (branche « ok » sur la figure 1A), alors dans une étape E8 de vérification, l'élément de sécurité 111 du deuxième terminal mobile 11 vérifie que les données relatives à la transaction courante sont conformes aux données de configuration initiale de service initialisées dans l'élément de sécurité 111 pour les transactions mises en œuvre par le deuxième terminal mobile 11. Ainsi, il est vérifié que le montant de la transaction courante n'excède pas le plafond autorisé. Le plafond autorisé garantit que l'utilisateur du deuxième terminal mobile 11 ne s'engage pas dans des transactions au cours desquelles il dépenserait plus que ce qu'il a sur son compte.

Si les vérifications faites au cours de l'étape E8 sont positives (branche « ok » sur le figure 1A), alors dans une étape E9 de mise à jour, le plafond autorisé est mis à jour par l'élément de sécurité 111. Le plafond autorisé est ainsi décrémenté du montant de la transaction courante pour l'exécution de transactions suivantes. Si les vérifications faites au cours de l'étape E8 sont négatives (branche « nok » sur la figure 1A), alors le procédé s'arrête. En effet, cela signifie que le montant de la transaction dépasse le plafond autorisé. La transaction n'est donc pas autorisée.

Dans une étape E10 de génération de preuve, l'élément de sécurité 111 du deuxième terminal mobile 11 génère un message prouvant que la transaction a été validée par l'utilisateur du deuxième terminal mobile 11 et autorisée par l'élément de sécurité 111. Le message de preuve comprend l'identifiant unique de transaction, un identifiant de l'utilisateur du deuxième terminal mobile 11, et les informations relatives à la transaction. L'identifiant de l'utilisateur du deuxième terminal mobile 11 est par exemple le numéro MSISDN associé au deuxième terminal mobile 11 et stocké dans l'élément de sécurité 111. Le message de preuve est signé au moyen de la clé secrète Ks _m du deuxième terminal mobile 11. Ce message constitue un premier contrat, prouvant que la transaction a été validée par l'utilisateur du deuxième terminal mobile 11. Dans un autre exemple de réalisation, le message de preuve comprend en outre un aléa, généré par l'élément de sécurité 111. L'aléa est destiné à éviter un rejeu de ce message de preuve auprès du serveur de paiement 20.

Dans une étape El i d'envoi, le premier contrat, généré au cours de l'étape E10 par l'élément de sécurité 111 du deuxième terminal mobile 11 est transmis en communication pair à pair au premier terminal mobile 10. Il est reçu par l'élément de sécurité 101 du premier terminal mobile 10 au cours d'une étape E12 de réception. Il est mémorisé dans une mémoire dédiée (non représentée sur la figure 1A) destinée à mémoriser des contrats relatifs à des transactions exécutées hors ligne.

Dans une deuxième étape E13 d' affichage, les informations de la transaction courante sont affichées sur l'écran du premier terminal mobile 10. L' affichage des informations de transaction constituent un récapitulatif de la transaction pour l'utilisateur du premier terminal mobile 11.

Dans une étape E14 validation, l'utilisateur du premier terminal mobile 10 valide la transaction. L'utilisateur du premier terminal mobile 10 étant le bénéficiaire de la transaction courante, il n'est pas nécessaire que celui-ci s'authentifie pour valider la transaction. On suppose cependant qu'il s'est authentifié précédemment, par exemple lors du lancement de l' application de paiement, ou lors de l'allumage du premier terminal 10.

Dans une étape E15 de vérification, exécutée dans le cas où des données de configuration initiale de service ont été initialisées dans l'élément de sécurité 101 , l'élément de sécurité 101 du premier terminal mobile 10 vérifie que les données relatives à la transaction courante sont conformes aux données de configuration. Par exemple, il est vérifié que le nombre de transactions hors ligne exécutées par le premier terminal mobile 10 n'excède pas un nombre maximal de transactions donné. Dans un autre exemple de réalisation, il est vérifié que le montant de la transaction courante n'excède pas une valeur maximale donnée. Si des vérifications sont faites au cours de l'étape E15 de vérification et si elles sont négatives (branche « nok » sur la figure 1A), alors le procédé s'arrête.

Si les vérifications faites au cours de l'étape E14 de vérification sont positives (branche « ok » sur la figure 1A), alors dans une étape E16 de génération d'une preuve, l'élément de sécurité 101 du premier terminal mobile 10 génère un message prouvant que la transaction a été validée par l'utilisateur du premier terminal mobile 10 et autorisée par l'élément de sécurité 101. Le message de preuve comprend l'identifiant unique de transaction, l'identifiant de l'utilisateur du premier terminal mobile 10 et les informations relatives à la transaction. Dans un exemple de réalisation, l'identifiant de l'utilisateur du deuxième terminal mobile 11 est extrait du premier contrat reçu au cours de l'étape E12 et ajouté au message de preuve. Le message de preuve est signé au moyen de la clé secrète Ks ₁₀ i du premier terminal mobile 10. Ce message constitue un deuxième contrat électronique, prouvant que la transaction a été validée par l'utilisateur du premier terminal mobile 10. Le deuxième contrat est envoyé en communication pair à pair à l'élément de sécurité 111 du deuxième terminal mobile 11 dans une étape E17 d'envoi. Il est mémorisé en association avec le premier contrat électronique reçu au cours de l'étape E12 dans la mémoire dédiée. Le deuxième contrat électronique est reçu par l'élément de sécurité 111 du deuxième terminal mobile 11 au cours d'une étape El 8 de réception et mémorisé en association avec le premier contrat dans une mémoire (non représentée sur la figure 1A) dédiée destinée à mémoriser des contrats relatifs à des transactions exécutées hors ligne.

L'exécution d'une transaction hors ligne est décrite ici entre un marchand, utilisateur du premier terminal mobile 10 et un acheteur, utilisateur du deuxième terminal mobile 11. Dans un autre exemple de réalisation, l'utilisateur du premier terminal 10 et l'utilisateur du deuxième terminal 11 sont tous deux des particuliers. Une transaction peut alors consister en un transfert d'argent du compte de l'utilisateur du premier terminal 10 au compte de l'utilisateur du deuxième terminal 11. Dans un autre exemple de réalisation, l'utilisateur du premier terminal 10 est un particulier et l'utilisateur du deuxième terminal 11 est un responsable d'un point de vente et un exemple de transaction est un retrait ou un dépôt d'argent de l'utilisateur du premier terminal 10 auprès du point de vente. En tout état de cause, lorsque des terminaux mobiles sont engagés dans une transaction, un des terminaux mobiles appartient à un utilisateur débiteur et l'autre à un utilisateur créditeur. La transaction implique alors le débit du compte de l'utilisateur débiteur au profit du compte de l'utilisateur créditeur.

L'identifiant unique de transaction généré au cours de l'étape E2 de sélection et de saisie est généré par exemple à partir d'un numéro de série de l'élément de sécurité 101 et d'une estampille temporelle. D'autres méthodes de génération d'identifiant unique existent et ne sont pas détaillées ici.

Dans l'exemple de réalisation décrit ici, on suppose que lorsqu'une transaction est exécutée hors ligne alors les premier et deuxième contrats transmis entre les premier et deuxième terminaux mobiles 10, 11, sont correctement reçus. Dans un exemple de réalisation, non représenté sur la figure 1A, on suppose que l'un des terminaux parmi le premier et le deuxième terminal 10, 11 ne reçoit pas le contrat envoyé par l'autre terminal. Par exemple, le deuxième terminal 11 ne reçoit pas le deuxième contrat envoyé par le premier terminal 10 au cours de l'étape E17 d'envoi. Dans un exemple de réalisation, le deuxième terminal mobile 11 arme une temporisation au cours de l'étape El i d'envoi pendant laquelle il envoie le premier contrat. Si à l'expiration de cette temporisation, le deuxième terminal mobile 11 n'a pas reçu le deuxième contrat du premier terminal mobile 10, alors il envoie au premier terminal 10 la requête de transaction qu'il a reçue au cours de l'étape E5 de réception. Si au bout d'un nombre prédéfini de tentatives, le deuxième terminal mobile 11 n'a toujours pas reçu le deuxième contrat, alors le contrat est annulé. Par exemple, le premier contrat qui avait été mémorisé par le deuxième terminal mobile 11 est effacé. Le deuxième terminal mobile 10 peut informer le premier terminal mobile 12 de cette annulation. De même, le premier terminal 10 peut armer une deuxième temporisation au cours de l'étape E4 d'envoi de la requête de transaction. Si, à l'expiration de la deuxième temporisation, il n'a pas reçu du deuxième terminal mobile 11 le premier contrat, alors il réémet la requête de transaction. Si au bout d'un nombre donné de tentatives, il n'a toujours pas reçu le premier contrat, alors la transaction est annulée. Il peut effacer les données relatives à la transaction courante et informer le deuxième terminal 12.

Par ailleurs, si le contrat est annulé, car le premier ou le deuxième contrat n'est pas reçu par le premier terminal mobile 11 ou le deuxième terminal mobile 10, alors le montant du plafond autorisé qui avait été décrémenté par l'élément de sécurité 111 du deuxième terminal mobile 11 au cours de l'étape E15 de mise à jour est incrémenté du montant de la transaction courante annulée. Ainsi, le montant du plafond autorisé mémorisé dans l'élément de sécurité 111 du deuxième terminal 11 est représentatif des transactions réellement exécutées.

La phase de compensation d'une transaction et de mise à jour va maintenant être décrite en relation avec la figure 1B.

On suppose qu'au moins un terminal mobile 12 parmi le premier et le deuxième terminal 10, 11, de la figure 1A est sous couverture réseau et qu'au moins une transaction a été exécutée lorsque les premier et deuxième terminaux 10, 11, étaient hors ligne, c'est-à-dire hors couverture réseau. Le terminal mobile 12, équipé d'un module de sécurité 121, désigne ainsi l'un des terminaux mobiles parmi le premier et/ou le deuxième terminal mobile 10, 11, équipé de son élément de sécurité 101, 111, qui est passé sous couverture réseau.

Dans une étape initiale E20 de lancement, l'utilisateur du terminal mobile 12 qui souhaite exécuter une nouvelle transaction avec le serveur de paiement 20, commande l'exécution de l'application de paiement au moyen de l'interface utilisateur de son terminal.

Avant de permettre à l'utilisateur d'exécuter la nouvelle transaction avec le serveur de paiement 20, l'application de paiement vérifie dans une étape E21 de vérification si des transactions ont été exécutées lorsque le terminal 12 était hors ligne. Afin de vérifier si des transactions ont été exécutées hors ligne, il est vérifié la présence de contrats dans la mémoire dédiée. La présence de contrats dans cette mémoire indique qu'au moins une transaction a été exécutée hors ligne.

Si aucune transaction n'a été exécutée hors ligne (branche « nok » sur la figure 1B), alors l'application de paiement exécute la nouvelle transaction conformément à son fonctionnement classique. L'exécution de l'application est supposée connue dans ce cas et n'est pas décrite ici.

Si des transactions ont été exécutées hors ligne (branche « ok » sur la figure 1B), conformément à la phase d'exécution d'une transaction décrite en relation avec la figure 1A, alors il est procédé à une compensation des transactions qui ont été exécutées hors ligne et pour lesquelles des contrats électroniques ont été mémorisés dans une mémoire dédiée du terminal 12. Il est procédé également à une mise à jour des données de configuration initiale de service si nécessaire.

La compensation d'une transaction exécutée hors ligne entre un premier et un deuxième terminal mobile consiste à transmettre au serveur de paiement 20 les données relatives à cette transaction de manière à ce que le serveur 20 l'exécute et crédite/débite les comptes associés aux utilisateurs qui ont participé à la transaction.

On suppose qu'au moins une transaction nécessite d'être compensée et donc que la mémoire dédiée comprend au moins deux contrats, lesdits contrats étant associés à la même transaction, appelée transaction courante et identifiée par un numéro de transaction unique.

Dans une étape suivante E22 de négociation et d'authentification mutuelle, le terminal mobile 12 et le serveur de paiement 20 initient la négociation d'une clé de session destinée à protéger les échanges entre le terminal 12 et le serveur de paiement 20. La négociation de la clé de session utilise par exemple le protocole « IKEv2 » (de l'anglais « Internet Key Exchange, version 2 »). De manière connue, le protocole IKEv2 inclut, en début de négociation une authentification mutuelle des tiers qui communiquent, en l'espèce le terminal mobile 12 et le serveur de paiement 20. Ainsi, la sécurité des échanges entre le terminal mobile 12 et le serveur de paiement 20 est garantie de bout en bout.

Dans une étape E23 d'envoi d'une requête, le terminal 12 envoie une requête de compensation au serveur de paiement 20. La requête de compensation est destinée à informer le serveur de paiement 20 qu'au moins une transaction impliquant le terminal mobile 12 a été exécutée hors ligne et nécessite d'être compensée, c'est-à-dire exécutée au niveau du serveur de paiement 20. Dans un exemple de réalisation, la requête de compensation comprend le premier et le deuxième contrat associés à la transaction courante. La requête de compensation est reçue par le serveur de paiement dans une étape E24 de réception.

Dans une étape E25 de contrôle, le serveur de paiement 20 vérifie l'intégrité des contrats associés à la transaction courante. Pour ce faire, il vérifie la signature des premier et deuxième contrats au moyen des clés publiques associées aux utilisateurs abonnés dont des identifiants figurent dans les contrats. Si l'intégrité de l'un des contrats n'est pas vérifiée (branche « nok » sur la figure 1B), le procédé s'arrête.

Si l'intégrité des contrats est vérifiée (branche « ok » sur le figure 1B), alors dans une étape E26 d'exécution de la transaction, la transaction est exécutée par le serveur 20. Pour ce faire, les comptes associés aux utilisateurs concernés par la transaction et dont les identifiants figurent dans au moins le premier contrat sont crédités/débités conformément aux informations de transaction qui figurent dans les contrats. A noter que la transaction n'est exécutée que si le serveur de paiement dispose des deux contrats, c'est-à-dire des contrats générés par chacun des terminaux impliqués dans la transaction courante.

Dans une étape optionnelle (non représentée sur la figure 2), des vérifications sur la cohérence entre le premier et le deuxième contrat sont mises en œuvre. Par exemple, il est vérifié que l'identifiant unique de transaction qui figure dans les contrats est identique, que le montant à débiter sur un compte d'utilisateur et qui figure dans l'un des contrats est identique au montant à créditer qui figure dans le deuxième contrat, etc.

Dans une étape suivante E27 d'envoi d'une mise à jour de données de configuration initiale de service, le serveur de paiement 20 envoie au terminal 12 les données de configuration initiale de service mises à jour en fonction de règles de configuration définies au niveau du serveur de paiement 20 pour le compte associé à l'utilisateur du terminal mobile 12. Les données de configuration initiale de service comprennent par exemple une nouvelle valeur de plafond autorisé. Celui-ci peut dépendre du solde du compte après exécution de la transaction courante. Les données de configuration initiale de service peuvent comprendre également un nouveau nombre maximal de transactions hors ligne autorisé, un nouveau montant maximum par transaction, etc. Ces données de configuration initiale ont par exemple été mises à jour par l'utilisateur sur le serveur de paiement lors de l'exécution d'une fonction de gestion de son compte, non décrite ici. Les données de configuration initiale sont reçues par le terminal 12 au cours d'une étape E28 de réception.

Dans une étape E29 de mise à jour des données de configuration initiale, le terminal 12 met à jour les données de configuration initiale de service conformément à ce qu'il a reçu du serveur de paiement 20 au cours de l'étape E28.

Dans une étape E30 d'archivage, le serveur de paiement 20 archive les contrats reçus au cours de l'étape E24 de réception. Il est important de conserver les contrats reçus afin de pallier d'éventuelles contestations.

A ce stade, la transaction effectuée hors ligne a été compensée par le serveur de paiement 20 c'est-à-dire qu'elle a été réellement exécutée par le serveur.

Dans une étape E31 d'envoi acquittement, le serveur de paiement 20 envoie au terminal 12 un acquittement destiné à informer le terminal 12 que la transaction a été compensée. L'acquittement comprend l'identifiant unique de la transaction. L'acquittement est reçu par le terminal 12 dans une étape E32.

Dans une étape E33 de suppression de contrats, le terminal mobile 12 efface de sa mémoire dédiée les premier et deuxième contrats associés à l'identifiant unique de transaction. Dans un exemple de réalisation où l'acquittement n'est pas reçu par le terminal 12 au bout d'un temps donné, le terminal 12 renvoie la requête de compensation au serveur de paiement 20.

Les étapes décrites ici ne sont qu'un exemple de réalisation d'une compensation de transaction par le serveur de paiement 20. L'invention n'est pas limitée à ce mode de réalisation. Ainsi, dans un autre exemple de réalisation, plusieurs transactions exécutées hors ligne par le terminal 12 sont compensées. Dans ce cas, le terminal 12 envoie dans la requête de compensation l'ensemble des contrats relatifs aux transactions à compenser.

Dans une variante de réalisation, une requête de compensation comprend les contrats relatifs à une transaction et le terminal 12 envoie autant de requêtes de compensation au serveur de paiement 20 qu'il y a eu de transactions exécutées hors ligne.

Dans un autre exemple de réalisation, le serveur de paiement 20 est informé dans un premier temps par le terminal 12 que des transactions ont été exécutées hors ligne. Le serveur de paiement 20 envoie alors au terminal 12 une requête de collecte afin d'obtenir du terminal 12 les contrats relatifs à une ou plusieurs transactions.

Il est important de noter que l'exécution d'une nouvelle transaction directement avec le serveur de paiement 20, c'est-à-dire lorsque le terminal mobile 12 est en ligne, est impossible tant que toutes les transactions exécutées hors ligne et mémorisées dans la mémoire dédiée du terminal 12 n'ont pas été compensées par le serveur de paiement 20. Cette contrainte est nécessaire afin d'éviter des incohérences entre des données de configuration initiale de service utilisées lors de transactions exécutées hors ligne, par exemple le plafond de dépense autorisé et les valeurs courantes de ces données, gérées par le serveur de paiement 20.

On a supposé que l'un des terminaux impliqués dans la transaction hors ligne passait sous couverture réseau et transmettait les contrats relatifs à la transaction exécutée hors ligne au serveur de paiement 20. On comprend que lorsque le deuxième terminal mobile impliqué dans la transaction exécutée hors ligne passe sous couverture réseau, alors il transmet également au serveur de paiement 20 les contrats relatifs à la même transaction. Le serveur de paiement vérifie que la transaction a déjà été compensée. Il utilise à cette fin l'identifiant unique de transaction. Il met éventuellement à jour des données de configuration initiales sur le deuxième terminal mobile et envoie ensuite un acquittement au deuxième terminal mobile de manière à lui signaler que la transaction exécutée hors ligne a été compensée.

Dans l'exemple décrit précédemment, c'est l'utilisateur du terminal mobile 12 qui lance l'exécution de l'application de paiement lorsque le terminal mobile 12 est sous couverture réseau et déclenche ainsi la compensation des transactions exécutées hors ligne avant l'exécution de toute autre transaction. L'invention n'est pas limitée à ce cas de figure et dans un autre exemple de réalisation, le terminal mobile 12 informe l'élément de sécurité 121 d'un changement de statut de localisation représentatif du passage du terminal mobile 12 d'une première zone hors couverture réseau vers une deuxième zone sous couverture réseau. Pour ce faire, le module de sécurité s'abonne préalablement à un événement de statut de localisation appelé « location status event » et défini dans des spécifications 3GPP et ETSI. Les modalités d' abonnement à un tel événement sont supposées connues et ne sont pas détaillées ici. Dans ce cas, le déclenchement de la compensation des transactions exécutées hors ligne peut être automatique. Un serveur de paiement 20, selon un exemple de réalisation de l'invention, va maintenant être décrit en relation avec la figure 2.

Le serveur de paiement 20 est un équipement informatique, tel un serveur informatique, adapté pour être placé dans un réseau de communication et pour rendre un service de paiement à des utilisateurs qui se sont abonnés.

Le serveur de paiement 20 comprend :

- un microprocesseur 200, ou « CPU » (de l'anglais « Central Processing Unit »), destiné à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ;

- un ensemble de mémoires, dont une mémoire volatile 201, ou « RAM » (pour « Random Access Memory ») utilisée pour exécuter des instructions de code, stocker des variables, etc., une mémoire de stockage 202 de type « ROM » ou « EEPROM » (de l'anglais « Read Only Memory » et « « Electronically-Erasable Programmable Read-Only Memory »). La mémoire de stockage 202 est agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de compensation d'une transaction tel que décrit précédemment. La mémoire de stockage 202 est également agencée pour mémoriser dans une base de données d'abonnés toutes les informations d'abonnement, tels que des identifiants d'abonnés, des données de configuration initiale de service pour les abonnés, des valeurs courantes du compte, telles que le solde, des informations sur les transactions passées par l'abonné, etc. ;

- des moyens de réception 203, adaptées pour communiquer avec les terminaux d'utilisateur à travers le réseau de communication et pour recevoir, en provenance d'un terminal mobile une requête de compensation. Par exemple, le serveur de paiement 20 est accessible à travers le réseau Internet. Dans un autre exemple de réalisation, il est accessible à travers la voix radio, par exemple à travers le canal USSD du réseau GSM. La requête de compensation comprend un premier et un deuxième contrat associés à une transaction courante exécutée entre un premier et un deuxième terminal mobile lorsque les terminaux étaient hors couverture du réseau de communication. Les moyens de réception 203 sont agencés pour mettre en œuvre l'étape E24 de réception du procédé de compensation tel que décrit précédemment ;

- des moyens d'envoi 204, adaptés pour communiquer avec les terminaux mobiles à travers le réseau de communication et pour envoyer à un terminal un message d'acquittement destiné à informer le terminal que la transaction courante a été exécutée sur le serveur. Par exemple, le serveur de paiement 20 est accessible à travers le réseau Internet. Dans un autre exemple de réalisation, il est accessible à travers la voix radio, à travers le canal USSD. Les moyens d'envoi 204 sont agencés pour mettre en œuvre l'étape E32 d'envoi d'un message d'acquittement du procédé de compensation tel que décrit précédemment ;

Le serveur de paiement 20 comprend également :

- des moyens de compensation 205, agencés pour exécuter une transaction suite à la réception d'une requête de compensation reçue d'un premier terminal mobile. Les moyens de compensation 204 utilisent les premier et deuxième contrats reçus dans la requête et qui sont associés à une transaction courante exécutée entre le premier et le deuxième terminal mobile lorsqu'ils étaient hors couverture du réseau de communication. Les moyens de compensation

204 sont agencés pour mettre en œuvre l'étape E26 du procédé de compensation tel que décrit précédemment ;

Les moyens de réception 203, les moyens d'envoi 204 et les moyens de compensation

205 comprennent des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de compensation d'une transaction exécutée par deux terminaux mobiles lorsque les terminaux étaient hors couverture du réseau de communication. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, un disque dur, une disquette, ou bien un support de transmission, ou un réseau.

Un terminal mobile 12, selon un exemple de réalisation de l'invention, va maintenant être décrit en relation avec la figure 3.

Le terminal mobile 12 est adapté pour communiquer à travers un réseau de communication et pour communiquer avec un autre terminal mobile en pair à pair de manière directe, par exemple en NFC, en Bluetooth, ou en pair à pair de manière centralisée, par exemple à travers une borne WiFi ou/et à travers un réseau local. Le terminal décrit ici est agencé pour participer à l'exécution de transactions hors ligne en tant que tiers débiteur et/ou tiers créditeur. Il est également agencé pour communiquer à travers le réseau de communication avec le serveur de paiement, dans le cadre du procédé de compensation d'une transaction exécutée hors ligne. Le terminal mobile 12 comprend :

- une unité de traitement 120, ou CPU,

- un ensemble de mémoire, dont une mémoire volatile 121 de type RAM, utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 122 de type ROM ou EEPROM. La mémoire de stockage 122 est agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre certaines des étapes du procédé d'exécution d'une transaction tel que décrit précédemment et exécutées lorsque le terminal mobile est hors couverture du réseau de communication. L'application est également agencée pour mettre en œuvre certaines des étapes du procédé de compensation tel que décrit précédemment, lorsque le terminal est sous couverture réseau et communique avec le serveur de paiement. Dans un exemple de réalisation, la mémoire de stockage 122 comprend une zone sécurisée dédiée, destinée à mémoriser de manière sécurisée des contrats générés ou reçus après exécution d'une transaction en pair à pair avec l'autre terminal mobile,

- un ensemble d'interfaces, comprenant un écran 123-1 , adapté pour afficher des messages à l'attention de l'utilisateur du terminal, par exemple les options de l'application de paiement, les informations de la transaction courante, etc., un clavier 123-2, adapté pour permettre la saisie par l'utilisateur d'informations complémentaires sur la transaction, d'un code d' authentification, d'un code de validation d'une transaction,

- un module sécurisé 124, qui comporte un processeur, une mémoire RAM, une ou plusieurs mémoires de type ROM ou EEPROM dans lesquelles sont enregistrés des programmes pouvant être exécutés par le micro-processeur. Dans un exemple de réalisation décrit ici, le module de sécurité 124 est une carte SIM qui comprend une mémoire dans laquelle sont définies des zones sécurisées. Une première zone sécurisée est agencée pour mémoriser une application comprenant des instructions de code pour mettre en œuvre certaines des étapes du procédé d'exécution d'une transaction tel que décrit précédemment et certaines étapes du procédé de compensation tel que décrit précédemment. Une deuxième zone sécurisée est agencée pour mémoriser des données de sécurité telles que la clé secrète Ksioi/Ksm du couple clé secrète/clé publique générée par l'Autorité de Certification pour l'utilisateur du terminal, un code PIN de service destiné à authentifier l'utilisateur pour la validation d'une transaction, des données de configuration initiale de service utilisées dans le cadre de l'exécution d'une transaction hors ligne. Dans un exemple de réalisation, une troisième zone sécurisée est dédiée à la mémorisation des contrats générés ou reçus de l'autre terminal mobile dans le cadre de l'exécution d'une transaction hors ligne.

- un module 125 de communication pair à pair, agencé pour dialoguer et exécuter une transaction avec un autre terminal mobile lorsque les terminaux sont hors couverture réseau. Le terminal mobile 12 comprend également :

- des moyens, qui couplés au module 125 de communication pair à pair constituent des moyens 126 d'envoi et de réception d'une requête de transaction, agencés pour envoyer une requête de transaction courante à un autre terminal, la requête comprenant un identifiant unique de transaction et des informations relatives à la transaction courante, et pour recevoir la requête de transaction en pair à pair et en provenance de l'autre terminal. Les moyens 126 d'envoi et de réception d'une requête de transaction sont agencés pour mettre en œuvre l'étape E4 d'envoi d'une requête de transaction et E5 de réception d'une requête de transaction,

- des moyens, qui couplés au module 125 de communication pair à pair constituent des moyens 127 de réception et d'envoi d'un contrat, agencés pour recevoir en pair à pair et en provenance de l'autre terminal un premier contrat électronique pour la transaction courante, le premier contrat constituant une preuve que la transaction a été validée par un utilisateur du terminal, et pour envoyer en pair à pair à l'autre terminal un deuxième contrat,

- des moyens 128 de génération de contrat, agencés pour générer le deuxième contrat électronique pour la transaction courante, le deuxième contrat constituant une preuve que la transaction a été validée par un utilisateur de l'autre terminal,

- des moyens 129 d'authentification, agencés pour authentifier l'utilisateur du terminal afin de valider la transaction courante. Les moyens 129 d'authentification sont agencés pour mettre en œuvre l'étape E7 d'authentification du procédé d'exécution d'une transaction tel que décrit précédemment,

- des moyens 130 de génération d'un aléa, agencés pour générer un aléa destiné à être intégré dans un contrat électronique de manière à éviter des attaques par rejeu.

- des moyens 131 d'envoi d'une requête de compensation, agencés pour envoyer au serveur de paiement une requête de compensation relative à une transaction exécutée hors ligne avec l'autre terminal mobile. Les moyens 131 sont agencés pour mettre en œuvre l'étape E23 d'envoi d'une requête de compensation du procédé de compensation décrit précédemment,

- des moyens 132 de réception d'un message d'acquittement, destiné à informer le terminal que la transaction courante a été compensée par le serveur. Les moyens de réception 132 sont agencés pour mettre en œuvre l'étape E32 du procédé de compensation tel que décrit précédemment,

- des moyens de mémorisation 133, agencés pour mémoriser les premier et deuxième contrats, en association avec un numéro unique de transaction, dans une zone sécurisée dédiée du terminal mobile,

- des moyens de suppression 134, agencés pour supprimer les premier et deuxième contrats de la zone sécurisée dédiée, une fois que la transaction a été compensée par le serveur de paiement. Les moyens de suppression 134 sont agencés pour mettre en œuvre l'étape E33 de suppression des premier et deuxième contrats,

- des moyens 135 de réception d'un message de mise à jour de données de configuration initiale de service, agencés pour recevoir en provenance du serveur de paiement un message de mise à jour de données de configuration initiale de service comprenant au moins une nouvelle valeur de donnée initiale de service. Les moyens 135 de réception d'un message de mise à jour de données de configuration initiale de service sont agencés pour mettre en œuvre l'étape E28 de réception d'un message de mise à jour de données de configuration de service du procédé de compensation d'une transaction tel que décrit précédemment,

- des moyens 136 de mise à jour de la donnée de configuration initiale de service, agencés pour mettre à jour sur le terminal la donnée de configuration initiale de service à partir de la nouvelle valeur reçue du serveur de paiement. Les moyens 136 sont agencés pour mettre en œuvre l'étape E29 de mise à jour de la donnée de configuration initiale de service du procédé de compensation précédemment décrit.

Les moyens 126 d'envoi et de réception d'une requête de transaction, les moyens 127 de réception et d'envoi d'un contrat, les moyens 128 de génération de contrat, les moyens 129 d' authentification, les moyens 130 de génération d'un aléa, les moyens 131 d'envoi d'une requête de compensation, les moyens 132 de réception d'un message d'acquittement, les moyens de mémorisation 133, les moyens de suppression 134, les moyens 135 de réception d'un message de mise à jour de données de configuration initiale de service, les moyens 136 de mise à jour de la donnée de configuration initiale de service sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes des procédés d'exécution d'une transaction lorsque le terminal est hors couverture réseau, et les étapes du procédé de compensation lorsque le terminal est sous couverture réseau, tels que décrits précédemment.

Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, un disque dur, une disquette, ou bien un support de transmission, ou un réseau. L'invention concerne également un système d'exécution de transactions qui comprend un serveur de paiement 20 tel que décrit précédemment et au moins deux terminaux mobiles 12 tels que décrits précédemment.