FR3107417A1 - Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs. - Google Patents

Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs. Download PDF

Info

Publication number
FR3107417A1
FR3107417A1 FR2001661A FR2001661A FR3107417A1 FR 3107417 A1 FR3107417 A1 FR 3107417A1 FR 2001661 A FR2001661 A FR 2001661A FR 2001661 A FR2001661 A FR 2001661A FR 3107417 A1 FR3107417 A1 FR 3107417A1
Authority
FR
France
Prior art keywords
function
terminal
identifier
request
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR2001661A
Other languages
English (en)
Inventor
Emmanuel Bertin
Julien HATIN
Baptiste HEMERY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR2001661A priority Critical patent/FR3107417A1/fr
Priority to US17/800,707 priority patent/US20230177214A1/en
Priority to PCT/FR2021/050276 priority patent/WO2021165612A1/fr
Priority to EP21710027.0A priority patent/EP4107905A1/fr
Publication of FR3107417A1 publication Critical patent/FR3107417A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de contrôle d’accès à une fonction d’une application mis en œuvre par un dispositif de contrôle d’accès à une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend : - une étape de réception, en provenance d’un premier terminal, d’une première requête d’accès à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal ; - une étape d’émission d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre. Figure pour l'abrégé : Figure 3

Description

Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
1. Domaine de l'invention
L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais «blockchain»).
2. Art Antérieur
De façon traditionnelle, les chaînes de blocs gèrent des crypto-monnaies (monnaie émise de pair à pair sans intervention d’une banque centrale). On peut citer par exemple la monnaie électronique décentralisée Bitcoin créée en 2009. Cependant, de nouveaux types de chaînes de blocs ont émergé proposant un champ d’applications plus large. C’est par exemple le cas d’Ethereum qui permet l’enregistrement d’applications décentralisées appelées DApps (Decentralized Applications en anglais). Concrètement, chaque application décentralisée présente au sein de la chaîne de blocs est composée d’un code binaire et d’une interface exposant des méthodes pouvant être appelées, par exemple par un tiers ou par d’autres applications. Une DApps dispose également d’une zone de données privée qu’elle va pouvoir modifier en fonction des traitements effectués.
Le modèle économique d’une telle chaîne de blocs est essentiellement axé sur l’acte de déploiement de l’application. Il faut «payer» pour déployer l’application, c’est-à-dire rétribuer les personnes qui valident l’application et qui créent le bloc associé à la validation au niveau de la chaîne de blocs. De plus, les personnes qui souhaitent utiliser l’application, par exemple via l’envoi d’une demande de réalisation d’une tâche particulière, doivent également payer à chaque utilisation en fonction d’un algorithme prédéterminé.
Force est de constater qu’il n’est actuellement pas possible, lorsqu’un tiers souhaite utiliser une application décentralisée, d’adapter et de personnaliser la rétribution du fournisseur de l’application en fonction de son utilisation. En effet, ces méthodes de rémunération restent très simples et ne permettent pas à un fournisseur d’établir des règles d’utilisation de ses applications décentralisées avec des coûts associés.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique et propose un procédé de contrôle d’accès à une fonction d’une application mis en œuvre par un dispositif de contrôle d’accès à une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend:
- une étape de réception, en provenance d’un premier terminal, d’une première requête d’accès à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal;
- une étape d’émission d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre.
Ainsi, l’invention propose d’utiliser une chaîne de blocs pour gérer l’accès à une application inscrite dans une chaîne de blocs et plus précisément à sa ou ses fonctions. La présente demande est présentée dans le contexte d’une «chaîne de blocs» en anglais «blockchain» mais l’expression «chaîne de blocs» est à comprendre comme couvrant tout type de DLT (en anglais Distributed Ledger Technology) apte à héberger des applications décentralisées connues sous le nom de DApp (Decentralized Applications en anglais) dont les chaînes de blocs à proprement parler constituent un élément particulier.
Comme indiqué dans le document (https://fr.wikipedia.org/wiki/Blockchain), on rappelle que la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système. Les chaînes de blocs sont notamment caractérisées en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée (c’est-à-dire enregistrée ou sauvegardée) dans une chaîne de blocs le reste pour toujours.
D’un point de vue pratique, l’invention offre un nouveau mécanisme dans lequel, lorsqu’une requête d’accès à une fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, le dispositif exécutant le procédé de contrôle d’accès renvoie alors une réponse avec un paramètre d’accès associé à la fonction, comme par exemple une option tarifaire et un identifiant d’une deuxième fonction, telle qu’une fonction de paiement associée à l’option.
Avantageusement, ce mode de réalisation permet de préciser à un utilisateur les conditions d’accès et d’utilisation d’une fonction inscrite dans une chaîne de blocs.
On entend par fonction une portion de code informatique représentant un sous-programme informatique, qui effectue une tâche ou un calcul particulier. L’identifiant de la fonction est par exemple le nom donné par le programmeur lors de sa création ou la signature de la fonction incluant des paramètres.
On entend par identifiant d’un terminal, une suite de caractères qui permet d’identifier de manière unique le terminal tel qu’une adresse MAC, une adresse IP, un numéro de série (ex: un IMEI) ou une clé cryptographique. Alternativement, l’identifiant du terminal peut également être un identifiant de l’utilisateur renseigné par celui-ci via une interface utilisateur du terminal telle qu’une interface graphique ou vocale, et permettant d’identifier de manière unique l’utilisateur du terminal. L’identifiant peut par exemple être une adresse de messagerie, un numéro de carte d’identité, un numéro d’abonné, etc.
Selon un mode de réalisation particulier de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie d’une première étape de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Cette publication dans la chaîne de blocs est réalisée pour stocker et partager des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif.
Selon un mode de réalisation particulier de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance d’au moins un second terminal, d’une requête d’exécution de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal;
- d’une étape d’exécution de ladite au moins une seconde fonction;
- d’une deuxième étape de publication dans la chaîne de blocs, dite publication de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’exécuter la deuxième fonction comme par exemple une fonction de paiement permettant l’utilisation de la première fonction. Une publication dans la chaîne de blocs est également réalisée pour stocker et partager le résultat de l’exécution de la deuxième fonction. Les informations publiées peuvent par exemple être le statut d’un paiement, des informations liées à la requête d’exécution de la seconde fonction telles que l’identifiant du terminal et/ou de l’utilisateur ou bien toute autre information associée à l’exécution de la seconde fonction.
Selon une première variante de ce mode particulier de réalisation de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie d’une deuxième étape d’émission d’une réponse à la requête d’exécution comportant au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’avoir de l’information sur l’exécution de la seconde fonction et son résultat. Dans le cas où la deuxième fonction est une fonction de paiement, l’utilisateur aura ainsi par exemple l’information sur le statut du paiement (accepté, refusé ou en attente) ou son numéro de transaction.
Selon une deuxième variante de ce mode particulier de réalisation de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie :
- d’une troisième étape de réception, en provenance de ladite application, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction;
- d’une étape d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement;
- d’une troisième étape d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu via les données de ladite publication de paiement;
- d’une troisième étape de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et de l’identifiant dudit premier terminal.
Avantageusement, ce mode de réalisation permet de vérifier que l’utilisateur a bien le droit d’accéder à la première fonction. L’application va alors vérifier que la deuxième fonction a bien été exécutée par le terminal de l’utilisateur et que le résultat est bien conforme à ce qui est attendu. Par exemple, l’application va vérifier qu’un paiement a bien été effectué par l’utilisateur (exécution de la deuxième fonction) et que le paiement a été validé (résultat conforme) avant de donner l’accès à la première fonction.
Procédé de contrôle de l’exécution d’une fonction d’une application mis en œuvre par un dispositif de contrôle de l’exécution d’une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend:
- une étape de réception, en provenance d’un terminal, d’une première requête d’exécution d’au moins une première fonction d’une application inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit terminal;
- une étape d’émission d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs.
Avantageusement, ce mode de réalisation permet, lorsqu’une première requête d’exécution à une première fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, de renvoyer une réponse avec un identifiant d’une seconde fonction comme par exemple une fonction qui va permettre de donner de l’information complémentaire à l’utilisateur sur la première fonction.
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie d’une première étape de publication dans la chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Cette publication dans la chaîne de blocs est réalisée à la suite de l’étape d’émission de la réponse à la requête d’exécution pour stocker et partager des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif.
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance dudit terminal, d’une deuxième requête d’exécution de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal;
- d’une deuxième étape d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction;
- d’une troisième étape de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal;
- d’une étape d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu;
- d’une deuxième étape de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Avantageusement, ce mode de réalisation permet, lorsqu’une deuxième requête d’exécution à une première fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, d’émettre une requête de demande d’autorisation d’utilisation et d’obtenir en retour un paramètre d’accès à la première fonction pour le terminal utilisateur. L’exécution de la fonction est alors fonction du paramètre d’accès.
Une publication dans la chaîne de blocs est également réalisée pour stocker et partager des informations liées aux étapes de réception, d’émission et d’exécution telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple le paramètre d’accès, ou encore le résultat d’un traitement réalisé par le dispositif.
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie d’une troisième étape d’émission d’une réponse à la deuxième requête d’exécution comprenant au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’avoir de l’information sur l’exécution de la première fonction et de son résultat.
L’invention concerne également un dispositif de contrôle d’accès à une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant:
- un module de réception d’une première requête d’accès, en provenance d’un premier terminal, à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal;
- un module d’émission d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre;
- un module de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle d’accès à une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre:
- un deuxième module de réception d’une requête d’exécution, en provenance d’au moins un second terminal, de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal;
- un module d’exécution de ladite au moins une seconde fonction;
- un deuxième module de publication dans la chaîne de blocs, d’une publication dite de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle d’accès à une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre:
- un troisième module de réception, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête étant en provenance de ladite application et comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction;
- un module d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement;
- un troisième module d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu dans les données de ladite publication de paiement;
- un troisième module de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et dudit identifiant dudit premier terminal.
L’invention concerne également un dispositif de contrôle de l’exécution d’une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant:
- un module de réception d’une première requête d’exécution, en provenance d’un terminal, d’au moins une première fonction d’une application inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit terminal;
- un module d’émission d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs;
- un module de publication, dans une chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre:
- un deuxième module de réception d’une deuxième requête d’exécution, en provenance dudit terminal, de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal;
- un deuxième module d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction;
- un troisième module de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal;
- un module d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu;
- un deuxième module de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. 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 pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre de l’un ou l’autre des procédés définis ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant 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 un disque dur. 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. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
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.
Ces dispositifs de contrôle d’accès à une fonction d’une application, de contrôle de l’exécution d’une fonction d’une application et ces programmes d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec les procédés de contrôle d’accès à une fonction d’une application et de contrôle de l’exécution d’une fonction d’une application.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels:
La figure 1 représente l’architecture matérielle d’un dispositif de contrôle d’accès à une fonction selon un mode particulier de réalisation;
La figure 2 représente l’architecture matérielle d’un dispositif de contrôle de l’exécution d’une fonction selon un mode particulier de réalisation;
La figure 3 représente sous forme d’organigramme les principales étapes d’un procédé de contrôle d’accès à une fonction et les principales étapes d’un procédé de contrôle de l’exécution d’une fonction conformes aux modes de réalisation de l’invention.
5. Description d'un mode de réalisation de l'invention
La figure 1 représente l’architecture matérielle d’un dispositif de contrôle d’accès DCA à une fonction conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC1, une mémoire vive MV1, une mémoire morte MEM1 et une mémoire flash non volatile MF1. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC1 et sur lequel est enregistré ici un programme d’ordinateur PG1 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle d’accès à une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC1.
A l'initialisation, les instructions de code du programme d'ordinateur PG1 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé de contrôle d’accès à une fonction selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la figure 3, selon les instructions du programme d'ordinateur PG1.
Le dispositif DCA comprend également des modules de communication COM11 et COM12 configurés pour établir des communications avec par exemple un réseau IP et/ou circuit. Le module de communication COM11 est utilisé pour recevoir des requêtes d’accès à une première fonction en provenance d’un terminal et le module COM12 pour émettre une réponse comprenant des paramètres d’accès et un identifiant d’une deuxième fonction associés à la première fonction. Le dispositif DCA comprend de plus un module OBT1 apte à publier dans la chaîne de blocs des données liées aux étapes de réception et d’émission du procédé de contrôle d’accès à une fonction.
Selon un mode particulier de réalisation de l’invention, les modules COM11 et COM12 peuvent être un seul et même module (COM1) de communication.
Selon un mode particulier de réalisation de l’invention, le module COM1 est également apte à recevoir des requêtes d’exécution de la deuxième fonction et le module OBT1 apte à publier dans la chaîne de blocs des données liées à l’étape de réception d’une requête d’exécution et à son exécution. La deuxième fonction pouvant être exécutée par le dispositif DCA et son processeur PROC1 ou via un module dédié (non représenté ici).
Selon un mode particulier de réalisation de l’invention, le module COM1 peut aussi être utilisé pour émettre une réponse à la requête d’exécution avec des données concernant le résultat de l’exécution de la deuxième fonction.
Selon un mode particulier de réalisation de l’invention, le module COM1 peut de plus recevoir des requêtes de demande d’autorisation concernant l’utilisation de la première fonction et émettre une réponse comprenant un deuxième paramètre d’accès en fonction d’une publication obtenue depuis la chaîne de blocs via le module OBT1. Le module OBT1 peut de plus publier dans la chaîne de blocs des données telles que le second paramètre, un identifiant du terminal ou toute autre donnée relative aux données reçues et émises par le module COM1.
A noter que dans le mode de réalisation décrit ci-dessus, les requêtes reçues et émises par le dispositif DCA sont prises en charge par le module COM1. Alternativement le dispositif DCA peut comprendre plusieurs modules de communication permettant la réception et/ou l’émission des requêtes.
De même, dans le mode de réalisation décrit ci-dessus, le module OBT1 gère l’ensemble des publications réalisées au niveau de la chaîne de blocs. Alternativement, le dispositif DCA peut comprendre plusieurs modules de publication permettant la publication et/ou l’obtention des publications au niveau de la chaîne de blocs.
La figure 2 représente l’architecture matérielle d’un dispositif de contrôle DCE de l’exécution d’une fonction conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC2, une mémoire vive MV2, une mémoire morte MEM2 et une mémoire flash non volatile MF2. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC2 et sur lequel est enregistré ici un programme d’ordinateur PG2 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle de l’exécution d’une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC2.
A l'initialisation, les instructions de code du programme d'ordinateur PG2 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC2. Le processeur PROC2 de l'unité de traitement UT2 met notamment en œuvre les étapes du procédé de contrôle de l’exécution d’une fonction selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la figure 3, selon les instructions du programme d'ordinateur PG2.
Le dispositif DCE comprend également des modules de communication COM21 et COM22 configuré pour établir des communications avec par exemple un réseau IP et/ou circuit. Le module de communication COM21 est utilisé pour recevoir des requêtes d’exécution d’une première fonction en provenance d’un terminal et le module COM22 émettre une réponse comprenant un identifiant d’une deuxième fonction inscrite dans une chaîne de blocs. A noter que la réponse peut également comprendre des paramètres réseaux.
Le dispositif DCE comprend de plus un module OBT2 apte à publier dans la chaîne de blocs des données liées aux étapes de réception et d’émission du procédé de contrôle de l’exécution d’une fonction.
Selon un mode particulier de réalisation de l’invention, les modules COM21 et COM22 peuvent être un seul et même module (COM2) de communication.
Selon un mode particulier de réalisation de l’invention, le module COM2 est également apte à émettre une requête d’autorisation d’utilisation de la première fonction par le terminal et à recevoir une réponse comprenant un paramètre d’accès à la première fonction. Le module OBT2 peut aussi être utilisé pour publier dans la chaîne de blocs des données liées à l’étape d’envoi de la requête d’autorisation d’utilisation et à son exécution en fonction d’un paramètre d’accès reçu en réponse à la requête d’autorisation d’utilisation. La première fonction pouvant être exécutée par le dispositif DCE et son processeur PROC2 ou via un module dédié (non représenté ici).
Selon un mode particulier de réalisation de l’invention, le module COM2 peut également émettre, à destination du terminal, une réponse à la requête d’exécution, la réponse pouvant comprendre une donnée associée au résultat de l’exécution de la première fonction. Le module OBT2 peut de plus publier dans la chaîne de blocs des données telles que le résultat de l’exécution de la première fonction, un identifiant du terminal ou toute autre donnée relative aux données reçues et émises par le module COM2.
A noter que dans le mode de réalisation décrit ci-dessus, les requêtes reçues et émises par le dispositif DCE sont prises en charge par le module COM2. Alternativement le dispositif DCE peut comprendre plusieurs modules de communication permettant la réception et/ou l’émission des requêtes.
De même, dans le mode de réalisation décrit ci-dessus, le module OBT2 gère l’ensemble des publications réalisées au niveau de la chaîne de blocs. Alternativement, le dispositif DCE peut comprendre plusieurs modules de publication permettant la publication et/ou l’obtention des publications au niveau de la chaîne de blocs.
En référence à la figure 3, nous allons maintenant décrire:
  • les principales étapes E21, E22, E25, E26, E33 et E34 d’un procédé de contrôle d’accès à une fonction d’une application;
  • les principales étapes E11, E12, E31, E32, E35, E37, E38 et E39 d’un procédé de contrôle de l’exécution d’une fonction d’une application.
La figure 3 est constituée d’un terminal TRM comme par exemple un terminal mobile ou un ordinateur apte à émettre et recevoir des requêtes vers et depuis une chaîne de blocs et des dispositifs DCE et DCA inscrits à une chaîne de blocs et aptes à exécuter des fonctions décentralisées ou DApps au sens de la technologie des chaînes de blocs. Ces applications se présentent sous la forme d’un code exécutable. Dans le cas décrit à l’appui de la figure 3 le dispositif DCE exécute une DApps comprenant une fonction F1 et le dispositif DCA exécute une DApps comprenant les fonctions F2 et F3.
Au cours d’une première étape E10, le terminal TRM envoie une requête d’exécution de la fonction F1 de la DApps au dispositif DCE. La requête comprend par exemple l’identifiant du terminal émetteur et l’identifiant de la fonction F1. La requête peut aussi comprendre d’autres données comme des jetons, des clés cryptographiques permettant par exemple au dispositif DCE d’authentifier le terminal TRM ou un identifiant de l’utilisateur qu’il a préalablement renseigné au niveau du terminal TRM via par exemple une interface utilisateur dédiée telle qu’une interface vocale ou graphique. Bien évidement il est supposé que le terminal TRM et son utilisateur sont déjà connus et enregistrés au sein de la chaîne de blocs.
A la réception de la requête (E11) le dispositif DCE va traiter la demande et générer une réponse comprenant un identifiant d’une seconde fonction F2. Le dispositif DCE va ensuite envoyer cette réponse (E12) au terminal TRM. Concrètement, le dispositif DCE réalise une redirection vers une fonction F2 d’une DApps exécutée par le dispositif DCA. Le dispositif DCE peut également publier dans la chaîne de blocs des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif.
Une fois la réponse (E13) à sa première requête reçue, le terminal TRM va générer une requête d’exécution de la fonction F2 à destination du dispositif DCA. La requête est envoyée à l’étape E20 avec par exemple les mêmes données que la première requête envoyée par le terminal TRM à l’étape E10. La requête est alors reçue, à l’étape E21, par le dispositif DCA qui va exécuter la fonction F2. Le résultat de la fonction F2 est par exemple une liste de couples de données dont la première donnée de chaque couple est un identifiant ou une chaîne de caractère indiquant une option tarifaire (ID_PA) associé à l’exécution de la fonction F1 et la deuxième donnée, un identifiant d’une troisième fonction (ID_F3) associée à l’option tarifaire. Le résultat de l’exécution de la fonction F2 est ensuite envoyé par le dispositif DCA (E22) puis reçu par le terminal TRM à l’étape E23.
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, les informations d’exécution de la fonction F2, ou encore le résultat de la fonction F2. Cette publication est appelée «publication tarifaire».
Alternativement, à l’étape E21, le dispositif DCA peut ne pas avoir besoin d’exécuter la fonction F2. C’est par exemple le cas si la liste est statique, c’est-à-dire que les options tarifaires restent inchangées pendant un laps de temps assez long (ex: 1 semaine, 1 mois, 1 an, etc.).
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être associée à l’exécution d’une fonction, par exemple F1, ou à plusieurs fonctions (F11, F12,…, F1n).
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être fonction de l’identifiant du terminal. C’est par exemple le cas lorsqu’un prix à l’exécution de la fonction F1 est négocié par une entreprise pour ses salariés.
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être associée à un délai de validité.
L’utilisateur du terminal TRM va ensuite choisir une option tarifaire dans la liste en fonction de ses besoins. L’option tarifaire choisie va permettre de préciser le cadre d’exécution de la fonction F1 pour le terminal TRM et son utilisateur. Les options tarifaires peuvent par exemple déterminer:
- un prix en fonction d’un quota d’exécution de la fonction F1;
- un prix en fonction d’une plage horaire pendant laquelle il est possible d’exécuter la fonction F1;
- un abonnement c’est-à-dire une utilisation illimitée de la fonction F1 pour une durée déterminée.
- un prix en fonction d’une donnée extérieur à la chaine de bloc telle qu’un coût énergétique ou des données émises par un Oracle. On rappelle qu’un Oracle est un service autorisé à entrer une donnée dans la chaîne de blocs à la demande d’un utilisateur.
Dans le cas d’une plage horaire, le coût d’utilisation peut par exemple varier en fonction de la durée de la plage horaire ou en fonction de son heure de début. L’utilisateur peut par exemple payer moins cher pour une plage horaire débutant la nuit. Cela permet d’inciter les utilisateurs de la fonction F1 à demander son exécution pendant une période donnée pour tenir compte de la charge du serveur. Ainsi, il est possible de lisser dans le temps les exécutions et par conséquent d’optimiser les architectures matérielles (mémoire, processeurs, etc.) des serveurs.
Une fois l’option choisie par l’utilisateur (E24), le terminal va envoyer une requête d’exécution de la fonction F3 au dispositif DCA. La Fonction F3 est par exemple une fonction de paiement associée à l’option tarifaire choisie. Le dispositif DCA va alors exécuter (E25) la fonction F3 et procéder au paiement grâce aux paramètres de paiement (PAY_PARA) reçus précédemment. Alternativement, dans le cas où le paiement est fait à priori, le dispositif peut vérifier que le paiement a bien eu lieu grâce aux paramètres de paiement (PAY_PARA) reçus précédemment. Ces paramètres peuvent être des informations bancaires, des informations liées à une preuve d’achat ou des informations liées au compte de l’utilisateur de la chaîne de blocs permettant d’effectuer ou d’attester un paiement. Le processus de paiement peut être réalisé en dehors de la chaîne de blocs ou bien en son sein. Dans le cas où le paiement est fait en dehors de la chaîne de blocs, le dispositif DCA va par exemple obtenir une preuve d’achat auprès d’un tiers pour déterminer si le paiement a bien été réalisé.
Alternativement, le processus de paiement peut correspondre à une mise sous séquestre d’une somme en prévision de l’exécution de la fonction F1 par le terminal utilisateur. La somme est alors débloquée au moment de l’exécution de la fonction F1 avec pour conséquence la réalisation du paiement.
Selon un mode particulier de réalisation de l’invention, le dispositif DCA peut envoyer une réponse (E26) au terminal TRM comprenant le résultat du paiement ou son acceptation (PAY_RESULT). Le résultat est par exemple un statut concernant l’acte de paiement (paiement effectué ou refusé ou en attente) ou bien toute autre donnée relative à l’acte de paiement (date, statut, numéro de transaction, établissement financier, etc.).
Selon un mode particulier de réalisation de l’invention, le dispositif DCA peut obtenir depuis la chaîne de blocs, via les données de la publication dite tarifaire, la date à laquelle le dispositif DCA a envoyé au terminal TRM les options tarifaires de la fonction F1 (E22). Ainsi, dans le cas où l’option tarifaire choisie par le terminal TRM est associée à une durée de validité (par exemple 2 jours), le dispositif DCA peut vérifier que l’offre est toujours valide avant d’exécuter la fonction F3. Cette vérification est classiquement effectuée en comparant la date de réception de la requête E25 avec celle de la requête E22 à laquelle on ajoute la durée de validité. Si la date de la requête E25 est antérieure alors l’option tarifaire est toujours valide et le dispositif DCA peut exécuter la fonction F3. Dans le cas contraire un message d’erreur est envoyé au terminal TRM, par exemple lors de l’étape E26.
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E25) et d’émission (E26) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, les informations d’exécution de la fonction F3, ou encore le résultat de la fonction F3. Cette publication est appelée «publication de paiement».
A l’étape E30 le terminal TRM émet une deuxième fois la requête de demande d’exécution de la fonction F1 à destination du dispositif DCE. La requête peut être enrichie par rapport à celle émise à l’étape E10 de données supplémentaires telles qu’un numéro de transaction de paiement ou une valeur de compteur. A la réception de la requête par le dispositif DCE (E31), celui-ci va vérifier si cette requête de demande d’exécution de la fonction F1 par le terminal TRM n’est pas la première. Pour cela le dispositif DCE peut consulter son historique de requêtes reçues et émises afin de déterminer si la requête en question est la première. Le dispositif peut aussi se baser sur des paramètres de la requête tels que le numéro de transaction de paiement ou la valeur du compteur. Dans le cas d’une valeur de compteur, c’est le terminal TRM qui va venir l’incrémenter lors d’une nouvelle émission de la requête de demande d’exécution de la fonction F1.
Dans le cas où la requête ne serait pas la première, le dispositif DCE va à l’étape E32 émettre une demande d’autorisation d’utilisation de la fonction F1 par le terminal TRM à destination du dispositif DCA. Cette requête comprend par exemple l’identifiant du terminal TRM (ID_TRM) et l’identifiant de la fonction F1 (ID_F1). Le dispositif DCA va alors obtenir, par exemple depuis une mémoire privée, le statut du paiement (résultat de l’exécution de la fonction F3 ou une preuve d’achat) et en déduire un paramètre d’accès à la fonction F1 (PARAC) pour le terminal TRM.
Le paramètre d’accès peut également être fonction d’autres données telles que la date ou l’heure si l’offre tarifaire choisie par l’utilisateur est fonction d’une plage horaire mais aussi d’une valeur d’un compteur indiquant le nombre d’exécutions déjà effectuées de la fonction F1 si l’offre tarifaire choisie par l’utilisateur est fonction d’un nombre d’exécutions.
Alternativement, le dispositif DCA peut obtenir le statut du paiement depuis la chaîne de blocs. L’obtention de ce statut peut se faire via les données de la publication dite de paiement et la récupération d’un paramètre dédié ou bien en reprenant les informations concernant l’exécution de la fonction de paiement.
Le paramètre PARAC peut par exemple être un booléen qui indique, lorsqu’il est par exemple positionné à 1 que le terminal TRM a l’autorisation d’exécuter la fonction F1. Alternativement, le paramètre PARAC peut être une chaîne de caractère ou tout autre ensemble de données permettant de fournir un statut sur l’autorisation d’exécuter la fonction F1 par le terminal TRM. Ainsi le paramètre PARAC peut par exemple être un couple booléen/chaîne de caractère dans lequel le booléen donne l’information sur l’autorisation d’exécuter la fonction F1 par le terminal TRM et la chaîne de caractère représente un libellé tel qu’un code d’erreur dans le cas où l’autorisation serait refusée.
A l’étape E34, le dispositif DCA va retourner une réponse au dispositif DCE comprenant le paramètre d’accès PARAC, l’identifiant du terminal TRM (ID_TRM) et l’identifiant de la fonction F1 (ID_F1).
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E33) et d’émission (E34) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, le paramètre d’accès PARAC, ou encore le résultat d’un traitement réalisé par le dispositif.
Lorsque le dispositif DCE reçoit la réponse (E35), celui-ci va tester (E37) le paramètre PARAC. Si le paramètre PARAC indique que l’exécution de la fonction F1 par le terminal TRM n’est pas autorisée, alors le dispositif DCE envoie le paramètre PARAC au terminal TRM. Le terminal TRM a ainsi l’information que l’exécution n’est pas possible et la raison pour laquelle l’exécution ne peut pas être réalisée. Inversement, si le paramètre PARAC indique que l’exécution de la fonction F1 par le terminal TRM est autorisée, alors le dispositif va exécuter la fonction F1 (E38) et envoyer le résultat de l’exécution au terminal TRM (E39).
Le dispositif DCE peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E31 et E35) et d’émission (E32, E36, E39) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, le paramètre d’accès PARAC, les informations d’exécution de la fonction F1 ou encore le résultat de l’exécution de la fonction F1.
Selon un mode particulier de réalisation de l’invention, la fonction F1 peut être exécutée en dehors de la chaîne de blocs. Dans ce cas le dispositif DCE va envoyer la demande d’exécution à un serveur externe via une interface dédiée de la chaîne de blocs.
Selon un mode particulier de réalisation de l’invention, les dispositifs DCE et DCA peuvent être une seule et même machine informatique exécutant plusieurs DApps mettant en œuvre les fonctions F1, F2 et F3.
Selon un mode particulier de réalisation de l’invention (non décrit ici), si l’exécution de la fonction F1 échoue, par exemple suite à une indisponibilité (problème de mémoire, problème de charge du serveur/ordinateur, ou autre), alors une requête est émise depuis le dispositif DCE à destination du dispositif DCA comprenant un paramètre indiquant que l’exécution de la fonction F1 a échoué, l’identifiant du terminal TRM et l’identifiant de la fonction F1. Le dispositif DCA pourra alors effectuer par exemple un remboursement partiel ou total de la somme précédemment payée à l’étape E25.
Selon un mode particulier de réalisation de l’invention, l’utilisateur peut, via son terminal TRM et avant l’étape E10, consulter un annuaire de fonctions afin de choisir la fonction F1 à exécuter. L’annuaire peut par exemple être représenté au niveau du terminal sous forme d’une liste de fonctions ou d’un tableau de fonctions avec par exemple une description, le nom du développeur et une note pour chaque fonction, la note étant par exemple le résultat d’une moyenne des notes données par les utilisateurs pondérée par le taux de disponibilité de la fonction. L’annuaire peut par exemple être récupéré en réponse suite à une requête envoyée par le terminal TRM à destination d’une DApps inscrite dans une chaîne de blocs.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.

Claims (9)

  1. Procédé de contrôle d’accès à une fonction d’une application mis en œuvre par un dispositif de contrôle d’accès à une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend:
    - une étape de réception (E21), en provenance d’un premier terminal, d’une première requête d’accès à au moins une première fonction (F1) de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction (ID_F1) et au moins un identifiant dudit premier terminal (ID_TRM);
    - une étape d’émission (E22) d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès (ID_PA) à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction (ID_F3) inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre.
  2. Procédé de contrôle d’accès selon la revendication 1, dans lequel l’étape d’émission est suivie d’une étape de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
  3. Procédé de contrôle d’accès selon la revendication 1, dans lequel l’étape d’émission est suivie:
    - d’une deuxième étape de réception (E25), en provenance d’au moins un second terminal (TRM), d’une requête d’exécution de ladite au moins une seconde fonction (F3), ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal (ID_TRM);
    - d’une étape d’exécution de ladite au moins une seconde fonction (F3);
    - d’une étape de publication dans la chaîne de blocs, dite publication de paiement, dudit identifiant dudit premier terminal (ID_TRM), d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction (PAY_RESULT).
  4. Procédé de contrôle d’accès selon la revendication 3, dans lequel l’étape de publication est suivie d’une deuxième étape d’émission (E26) d’une réponse à la requête d’exécution comportant au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction (PAY_RESULT).
  5. Procédé de contrôle d’accès selon la revendication 3, dans lequel l’étape de publication est suivie :
    - d’une troisième étape de réception (E33), en provenance de ladite application, d’une requête d’autorisation d’utilisation par ledit premier terminal (TRM) de ladite au moins une première fonction (F1), ladite requête d’autorisation comprenant au moins ledit identifiant dudit premier terminal (ID_TRM) et au moins ledit premier identifiant de ladite au moins une première fonction (ID_F1);
    - d’une étape d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement;
    - d’une troisième étape d’émission (E34) d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès (PARAC) à ladite au moins une première fonction (F1), ledit second paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction (F3) obtenu via les données de ladite publication de paiement;
    - d’une deuxième étape de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès (PARAC) et de l’identifiant dudit premier terminal (ID_TRM).
  6. Dispositif de contrôle d’accès à une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant:
    - un module de réception (COM11) d’une première requête d’accès, en provenance d’un premier terminal, à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal;
    - un module d’émission (COM12) d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre;
    - un module de publication (OBT1) dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
  7. Dispositif de contrôle d’accès selon la revendication 6 caractérisé en ce qu’il comporte en outre:
    - un deuxième module de réception d’une requête d’exécution, en provenance d’au moins un second terminal, de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal;
    - un module d’exécution de ladite au moins une seconde fonction;
    - un deuxième module de publication dans la chaîne de blocs, d’une publication dite de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
  8. Dispositif de contrôle d’accès selon la revendication 7 caractérisé en ce qu’il comporte en outre:
    - un troisième module de réception, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête étant en provenance de ladite application et comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction;
    - un module d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement;
    - un troisième module d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu dans les données de ladite publication de paiement;
    - un troisième module de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et dudit identifiant dudit premier terminal.
  9. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle d’accès à une fonction selon l’une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par un processeur.
FR2001661A 2020-02-19 2020-02-19 Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs. Withdrawn FR3107417A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR2001661A FR3107417A1 (fr) 2020-02-19 2020-02-19 Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
US17/800,707 US20230177214A1 (en) 2020-02-19 2021-02-17 Method and device for controlling access to a function of an application registered in a blockchain
PCT/FR2021/050276 WO2021165612A1 (fr) 2020-02-19 2021-02-17 Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs
EP21710027.0A EP4107905A1 (fr) 2020-02-19 2021-02-17 Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2001661A FR3107417A1 (fr) 2020-02-19 2020-02-19 Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
FR2001661 2020-02-19

Publications (1)

Publication Number Publication Date
FR3107417A1 true FR3107417A1 (fr) 2021-08-20

Family

ID=72470405

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2001661A Withdrawn FR3107417A1 (fr) 2020-02-19 2020-02-19 Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.

Country Status (4)

Country Link
US (1) US20230177214A1 (fr)
EP (1) EP4107905A1 (fr)
FR (1) FR3107417A1 (fr)
WO (1) WO2021165612A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200020440A1 (en) * 2018-07-12 2020-01-16 Appley Health, Inc. Computer-assist method using distributed ledger technology for operating and managing an enterprise

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11544708B2 (en) * 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain
US10693716B2 (en) * 2018-05-29 2020-06-23 At&T Mobility Ii Llc Blockchain based device management
US20200042982A1 (en) * 2018-08-06 2020-02-06 Factom Digital Contracts in Blockchain Environments
SG11202102264QA (en) * 2018-09-11 2021-04-29 Visa Int Service Ass System, method, and computer program product for fraud management with a shared hash map
BR112021008817A2 (pt) * 2018-11-13 2021-08-10 Banqu, Inc. formas de definição e gerenciamento em uma rede confiável de registros distribuídos
MX2019004667A (es) * 2018-11-27 2019-08-21 Alibaba Group Holding Ltd Plataforma de funcion como servicio (faas) en redes de cadena de bloques.
US11263315B2 (en) * 2018-12-03 2022-03-01 Ebay Inc. System level function based access control for smart contract execution on a blockchain
US11030297B2 (en) * 2019-01-04 2021-06-08 Comcast Cable Communications, Llc Systems and methods for device and user authorization

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200020440A1 (en) * 2018-07-12 2020-01-16 Appley Health, Inc. Computer-assist method using distributed ledger technology for operating and managing an enterprise

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KNIRSCH FABIAN ET AL: "Privacy-preserving blockchain-based electric vehicle charging with dynamic tariff decisions", COMPUTER SCIENCE - RESEARCH AND DEVELOPMENT, SPRINGER BERLIN HEIDELBERG, BERLIN/HEIDELBERG, vol. 33, no. 1, 4 September 2017 (2017-09-04), pages 71 - 79, XP036392932, ISSN: 1865-2034, [retrieved on 20170904], DOI: 10.1007/S00450-017-0348-5 *
LIU HAIQING ET AL: "Electric Vehicle Power Trading Mechanism Based on Blockchain and Smart Contract in V2G Network", IEEE ACCESS, vol. 7, 8 November 2019 (2019-11-08), pages 160546 - 160558, XP011754204, DOI: 10.1109/ACCESS.2019.2951057 *

Also Published As

Publication number Publication date
EP4107905A1 (fr) 2022-12-28
WO2021165612A1 (fr) 2021-08-26
US20230177214A1 (en) 2023-06-08

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
FR2751104A1 (fr) Procede de controle de transactions securisees independantes utilisant un dispositif physique unique
EP1299838A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
WO2018154082A1 (fr) Système et procédé de traitement d'une transaction bancaire
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
FR3103990A1 (fr) Procédés et applications de contrôle d’accès distribué à un réseau de télécommunications
EP1164529A1 (fr) Système et procédé de couponnage électronique
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
FR3107417A1 (fr) Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
EP3926566A1 (fr) Validation d'une transaction relative a une offre d'un bien ou d'un service à un utilisateur
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
WO2022269179A1 (fr) Procede et dispositif de paiement par chaines de blocs
CA3143068A1 (fr) Systeme d'applications de service pour terminaux de paiement
EP3948627A1 (fr) Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede
EP1503563A1 (fr) Procédé de sécurisation de requetes d'accès à des services, terminal et module logiciel pour mettre en oeuvre le procédé
FR3093225A1 (fr) Procédé de gestion d’accès d’un utilisateur à un service vocal, dispositif, système et programmes correspondants
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT
FR2811452A1 (fr) Systeme et procede de gestion de transaction de micropaiement, dispositifs client, marchand et intermediaire financier
FR2881006A1 (fr) Systeme de communication pour jeu mobile
WO2023001846A1 (fr) Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs
FR3091767A1 (fr) Autorisation du chargement d’une application dans un élément de sécurité.
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210820

ST Notification of lapse

Effective date: 20221005