FR3143820A1 - Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés - Google Patents

Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés Download PDF

Info

Publication number
FR3143820A1
FR3143820A1 FR2213903A FR2213903A FR3143820A1 FR 3143820 A1 FR3143820 A1 FR 3143820A1 FR 2213903 A FR2213903 A FR 2213903A FR 2213903 A FR2213903 A FR 2213903A FR 3143820 A1 FR3143820 A1 FR 3143820A1
Authority
FR
France
Prior art keywords
data
crn1
obj2
work
communication
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.)
Pending
Application number
FR2213903A
Other languages
English (en)
Inventor
Apostolos KOUNTOURIS
Philippe Surbayrole
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 FR2213903A priority Critical patent/FR3143820A1/fr
Publication of FR3143820A1 publication Critical patent/FR3143820A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H04W4/185—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals by embedding added-value information into content, e.g. geo-tagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés L’invention concerne un procédé de communication mis en œuvre par un dispositif de communication mobile (CRN1) et comportant, pour au moins un objet communicant (OBJ1) positionné dans une zone géographique donnée et lorsque le dispositif de communication est localisé dans un voisinage dudit au moins un objet communicant, des étapes de :- réception (E20), en provenance dudit au moins un objet communicant, d’une donnée d’information (DATA_OBJ2) propre audit au moins un objet communicant,- détermination (E40) d’une donnée d’interaction (DATA_CRN1_OBJ2) comportant une date (t_CRN1_OBJ2) et une localisation (loc_CTN1_OBJ2) de réception de la donnée d’information ainsi qu’un identifiant (id_OBJ2) dudit au moins un objet communicant,- transmission (E50) de ladite donnée d’interaction vers un dispositif de centralisation (CPU). Figure pour l’abrégé : Fig. 4

Description

Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés
La présente demande appartient au domaine général des systèmes de communication. Elle concerne plus particulièrement un procédé de communication mis en œuvre dans un réseau de communication auquel appartiennent des objets communicants, un procédé de traitement de données obtenues lors de la mise en œuvre dudit procédé de communication, ainsi que des dispositifs de communication et de centralisation respectivement configurés pour mettre en œuvre lesdits procédés de communication et de traitement de données. L’invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le domaine de l’« Internet des objets » (« Internet of Things » ou « IoT » dans la littérature anglo-saxonne).
De façon connue, les objets communicants (encore couramment appelés « objets connectés) sont des dispositifs matériels et/ou logiciels connectés à un réseau de communication, tel que par exemple au réseau public Internet dans le cadre de l’IoT, et peuvent par ce biais communiquer avec d’autres systèmes pour obtenir et/ou fournir de l’information.
De manière générale, chaque objet apte à réaliser une fonction (exemple : un capteur de température réalise la fonction de mesure d’une température), et donc potentiellement chaque objet de la vie courante, est susceptible de devenir un objet communicant dès lors qu’il est équipé des moyens matériels et/ou logiciels lui permettant de communiquer, au sein d’un réseau de communication, des données d’information qui lui sont propres (i.e. données contenant au moins des informations relatives à la fonction réalisée par l’objet en question).
A titre d’exemple, il peut s’agir d’un téléphone, plus particulièrement d’un téléphone intelligent (smartphone), d’une imprimante, d’un écran, d’un capteur, d’un microphone, d’une application logicielle, etc. En outre, aucune limitation n’est attachée à l’interface de communication (filaire ou non) ainsi qu’au protocole de communication (Wi-Fi, Bluetooth, 3G, 4G, 5G, Ethernet, etc.) utilisés par ces objets.
La représente schématiquement un exemple de réalisation, conforme à l’état de la technique, d’un système IoT configuré pour réaliser des communications entre des objets communicants et un dispositif de centralisation. Plus particulièrement, dans cet exemple, et à des fins illustratives seulement, le système comporte trois objets communicants OBJ1_0, OBJ2_0, OBJ3_0. Ces objets OBJ1_0, OBJ2_0, OBJ3_0 sont déployés dans une zone géographique donnée, comme par exemple une usine, une exploitation agricole, un quartier d’une ville, une habitation personnelle, etc. Ils sont en outre connectés au réseau Internet ainsi que configurés pour communiquer, via ledit réseau Internet (plus particulièrement, d’un point de vue matérielle, via une passerelle Internet, encore appelée « Gateway » en anglais), avec un dispositif de centralisation CPU_0 intégré audit système de communication. Ledit dispositif de centralisation CPU appartient typiquement à un système informatique en nuage (« Cloud » en anglais).
Les échanges de données entre les objets OBJ1_0, OBJ2_0, OBJ3_0 et le dispositif de centralisation CPU_0 s’effectuent classiquement dans les deux sens, i.e. suivant une voie montante UL (objet communicant vers dispositif de centralisation) ainsi qu’une voie descendante DL (dispositif de centralisation vers objet communicant), comme représenté à titre illustratif sur la . En particulier, suivant la voie montante UP, les objets OBJ1_0, OBJ2_0, OBJ3_0 transmettent au dispositif de centralisation CPU_0 des données d’information telles que mentionnées ci-avant.
Actuellement, le déploiement massif d’objets communicants, pour offrir toujours davantage de services et/ou procéder à des analyses sur la base des données d’information remontées par ces objets communicants, pose un certain nombre de problèmes.
En particulier, un objet communicant peut rencontrer des difficultés pour communiquer avec un dispositif de centralisation. Cela peut être due, par exemple, à une localisation contraignante (exemple : objet communicant éloigné et/ou situé dans un endroit). Un autre problème susceptible de se poser est celui de la surcharge du réseau du fait de la quantité très importante de données d’information communiquées (cette quantité tendant à augmenter avec le temps étant donné l’utilisation d’un nombre toujours plus important d’objets communicants).
Des solutions ont dès lors été proposées pour essayer de pallier ces types de problèmes, dont notamment la mise en œuvre d’un réseau d’un type particulier appelé réseau collaboratif de proximité. En pratique, il s’agit de faire appel à la contribution d’utilisateurs en possession de dispositifs de communication, comme par exemple des smartphones, afin de jouer le rôle d’intermédiaire entre les objets communicants et le dispositif de centralisation, et ainsi contribuer à la remontée des données d’information vers cette dernière.
Ces solutions sont toutefois loin d’être satisfaisantes dans la mesure où elles se basent sur le volontariat des utilisateurs en possession desdits dispositifs de communication.
La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette de favoriser et faciliter la mise en œuvre d’un réseau collaboratif de proximité entre des objets communicants et un dispositif de centralisation.
A cet effet, et selon un premier aspect, l’invention concerne un procédé de communication mis en œuvre par un dispositif de communication mobile et comportant, pour au moins un objet communicant positionné dans une zone géographique donnée et lorsque le dispositif de communication est localisé dans un voisinage dudit au moins un objet communicant, des étapes de :
- réception, en provenance dudit au moins un objet communicant, d’une donnée d’information propre audit au moins un objet communicant,
- détermination d’une donnée d’interaction comportant une date et une localisation de réception de la donnée d’information ainsi qu’un identifiant dudit au moins un objet communicant,
- transmission de ladite donnée d’interaction vers un dispositif de centralisation.
Le procédé de communication selon l’invention permet donc à un dispositif de communication de déterminer des données d’interaction représentatives du travail effectué pour obtenir (collecter, récupérer) une ou plusieurs données d’information auprès d’un ou plusieurs objets communicants.
Plus particulièrement, la spécificité des données d’interaction déterminées par le dispositif de communication, via la mise en œuvre du procédé de communication, offre la possibilité de vérifier/attester/certifier le travail effectué par le dispositif de communication pour collecter lesdites données d’information, comme cela est détaillé ci-après. Il en résulte la possibilité de créer une preuve du travail effectué par le dispositif de communication.
Par « spécificité des données d’interaction », on fait référence ici notamment à leurs contenus en termes de dates et de localisations. Ce contenu est en effet représentatif d’une trajectoire « physique » suivie par le dispositif de communication dans le temps et dans l’espace pour effectuer la collecte des données d’information. C’est donc cette trajectoire physique qui forme la brique à partir de laquelle il devient possible de déterminer une preuve de travail, le travail étant ici une fonction de la distance parcourue et du temps consacré à la collecte des données d’information.
Il importe en outre de noter que, en effectuant ce travail de collecte de données d’information auprès d’objets communicants, le dispositif de communication participe à la création d’un réseau collaboratif de proximité pour faciliter la remontée de données d’information vers le dispositif de centralisation. Ce réseau collaboratif de proximité est donc un réseau « physique » (dispositif de communication, utilisateur, objets communicants, dispositif de centralisation), et non virtuel.
Dès lors, l’invention permet avantageusement de créer une incitation pour un utilisateur en possession du dispositif de communication à participer à la collecte de données d’information d’objets communicants, et donc in fine de contribuer à la création dudit réseau collaboratif. En effet, dès lors que le travail de cet utilisateur peut être vérifié et certifié, cela lui offre la possibilité de recevoir une rétribution.
La preuve de travail présente encore d’autres avantages. En effet, dans la mesure où sa détermination est fondamentalement liée à la réalisation d’un travail, cela permet d’éviter une surcharge du réseau de communication sous-tendant la réception et la transmission des différentes données, du fait d’un trop grand nombre de données transmises. En outre, comme la preuve de travail résulte d’une vérification du travail effectué, cela contribue à rendre extrêmement coûteuses les tentatives de falsification des données transmises au dispositif de centralisation.
Dans des modes particuliers de mise en œuvre, le procédé de communication peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.
Dans des modes particuliers de mise en œuvre, ledit procédé étant mis en œuvre pour une pluralité d’objets communicants positionnés dans la zone.
Dans des modes particuliers de mise en œuvre, l’étape de transmission est mise en œuvre après chaque détermination d’une donnée d’interaction ou bien après que le nombre de données d’interaction déterminées est supérieur à un seuil donné.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte, pour au moins un objet communicant, une étape de déplacement du dispositif de communication au sein de la zone et permettant audit dispositif de communication d’être positionné dans le voisinage dudit au moins un objet communicant, ladite étape de déplacement étant réalisée :
- indépendamment de la position dudit au moins un objet communicant dans la zone, ou
- pour satisfaire un critère d’intérêt à obtenir la donnée d’information dudit au moins un objet communicant.
Dans des modes particuliers de mise en œuvre, le procédé comporte également une étape de réception, en provenance dudit au moins un objet communicant, d’un jeton cryptographique, la donnée d’interaction étant déterminée de sorte à comporter également ledit jeton.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre une étape de réception, en provenance du dispositif de centralisation, d’une donnée de preuve de travail caractérisant une quantité de travail effectuée par le dispositif de communication pour obtenir et transmettre au moins une partie de ladite au moins une donnée d’information et de ladite au moins une donnée d’interaction.
Comme détaillé ci-après dans le cadre de la mise en œuvre d’un procédé de traitement de données selon l’invention, la quantité de travail porte plus spécifiquement sur des données appartenant à ladite au moins une donnée d’information et ladite au moins une donnée d’interaction et qui satisfont un critère de conformité de travail, dites « données conformes ». Il s’agit en effet d’être en mesure d’écarter, parmi ladite au moins une donnée d’information et ladite au moins une donnée d’interaction, d’éventuelles données erronées ou suspicieuses.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre des étapes de :
- transmission de la donnée de preuve de travail à un dispositif de rétribution,
- obtention d’une rétribution, par exemple sous forme de cryptomonnaie, ladite rétribution étant fonction de ladite donnée de preuve de travail.
Selon un deuxième aspect, l’invention concerne un procédé de traitement de données mis en œuvre par un dispositif de centralisation, ledit procédé comportant, pour au moins un dispositif de communication mobile, des étapes de :
- réception, en provenance dudit au moins un dispositif de communication mobile, d’au moins une donnée d’information et d’au moins une donnée d’interaction obtenues et transmises conformément à un procédé de communication selon l’invention,
- identification, parmi les données reçues, de données satisfaisant un critère de conformité de travail, dites « données conformes »,
- détermination d’une donnée de preuve de travail caractérisant une quantité de travail effectuée par ledit au moins un dispositif de communication pour obtenir et transmettre une partie P desdites données conformes.
Le procédé de traitement de données selon l’invention correspond à la génération effective d’une preuve de travail pour au moins un dispositif de communication. Ce procédé de traitement hérite donc des avantages déjà décrits ci-avant en référence au procédé de communication.
La génération effective de la preuve de travail permet donc de convertir la trajectoire physique effectuée par le dispositif de communication en une donnée représentative du travail réalisé lors du suivi de cette trajectoire physique. D’une certaine manière, le procédé de traitement de données permet de passer d’un espace « physique » (décrit en termes de temps et d’espace) à un espace virtuel numérique comportant des données de preuve de travail déterminées sur la base de données collectées dans ledit espace physique.
Dans des modes particuliers de mise en œuvre, le procédé de traitement de données peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.
Dans des modes particuliers de mise en œuvre, la partie P comporte la totalité des données conformes, ou bien, le procédé comporte en outre une étape de détermination des données de la partie P dites « données sélectives », la partie P étant strictement incluse dans l’ensemble des données conformes, de sorte que :
- la durée pour obtenir lesdites données sélectives satisfait une première contrainte, ladite durée étant fonction des dates associées aux données sélectives, et/ou
- la surface géographique parcourue pour obtenir lesdites données sélectives satisfait une deuxième contrainte, ladite surface géographique étant fonction des localisations associées aux données sélectives.
Dans des modes particuliers de mise en œuvre, ledit procédé étant mis en œuvre pour une pluralité de dispositifs de communication.
Dans des modes particuliers de mise en œuvre, lorsque le dispositif de centralisation a reçu, en provenance de plusieurs dispositifs de communication, une pluralité de données d’interaction associées à un même objet communicant, le critère de conformité de travail comporte une condition consistant à vérifier si lesdites données d’interaction reçues sont compatibles entre elles dans le temps et dans l’espace en fonction de leurs dates et localisations respectives.
Dans des modes particuliers de mise en œuvre, le critère de conformité comporte également une condition consistant à vérifier que le cardinal de ladite pluralité de données d’interaction associées à un même objet communicant est supérieur à un seuil donné.
Dans des modes particuliers de mise en œuvre, lorsqu’une donnée d’interaction comporte un jeton cryptographique conformément à l’invention, le critère de conformité de travail comporte une condition consistant à vérifier que le dispositif de centralisation est apte à déchiffrer ledit jeton cryptographique.
Dans des modes particuliers de mise en œuvre, la quantité de travail est fonction d’au moins un paramètre parmi :
- la durée T pour obtenir les données de la partie P, ladite durée T étant fonction des dates associées aux données de la partie P,
- la surface géographique S parcourue pour obtenir les données de la partie P, ladite surface géographique S étant fonction des localisations associées aux données de la partie P,
- le nombre N d’objets communicants à partir desquels ont été obtenues les données de la partie P.
Dans des modes particuliers de mise en œuvre, la quantité de travail s’exprime en unités de travail et comporte un premier terme QdT1 défini par :
QdT1 = min(E(T/Tu), E(S/Su), E(N/Nu)),
expression dans laquelle E désigne la fonction partie entière, et Tu, Su, Nu correspondent respectivement à une durée donnée, une surface géographique donnée, et un nombre donné d’objets communicants, le vecteur [Tu, Su, Nu] représentant une unité de travail.
Dans des modes particuliers de mise en œuvre, la quantité de travail comporte un deuxième terme QdT2, ajouté au premier terme QdT1, défini par :
QdT2 = max((T mod Tu)/Tu, (S mod Su)/Su, (N mod Nu)/Nu),
expression dans laquelle mod désigne la fonction modulo.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre une étape de transmission de la donnée de preuve de travail audit au moins un dispositif de communication ou bien à un dispositif de rétribution, de sorte que le dispositif de communication obtienne une rétribution, par exemple sous forme de cryptomonnaie, ladite rétribution étant fonction de ladite donnée de preuve de travail.
Dans des modes particuliers de mise en œuvre du procédé de communication ou du procédé de traitement de données, la donnée de preuve de travail comporte un jeton cryptographique.
Dans des modes particuliers de mise en œuvre, le jeton cryptographique contenu dans la donnée de preuve de travail a une durée de validité limitée.
Selon un troisième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de communication selon l’invention ou d’un procédé de traitement de données selon l’invention lorsque ledit programme d’ordinateur est exécuté par un ordinateur.
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.
Selon un quatrième aspect, l’invention concerne un support d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention.
Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur.
D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un cinquième aspect, l’invention concerne un dispositif de communication comportant des moyens configurés pour mettre en œuvre un procédé de communication selon l’invention.
Selon un sixième aspect, l’invention concerne un dispositif de centralisation comportant des moyens configurés pour mettre en œuvre un procédé de traitement de données selon l’invention
Selon un septième aspect, l’invention concerne un système de communication comportant au moins un dispositif de communication selon l’invention ainsi qu’un dispositif de centralisation selon l’invention.
Dans des modes particuliers de réalisation, ledit système de communication comporte en outre au moins un objet communicant.
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la représente schématiquement un exemple de réalisation, conforme à l’état de la technique, d’un système IoT configuré pour réaliser des communications entre des objets communicants et un dispositif de centralisation ;
la représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système de communication selon l’invention ;
la représente schématiquement un exemple d’architecture matérielle d’un dispositif de communication appartenant au système de communication de la ;
la est un diagramme représentant un mode particulier de mise en œuvre d’un procédé de communication selon l’invention, tel qu’exécuté par un dispositif de communication conforme à la ;
la représente schématiquement un exemple de trajet réalisé par le dispositif de communication de la lors de la mise en œuvre du procédé de communication de la ;
la représente schématiquement un exemple d’architecture matérielle d’un dispositif de centralisation appartenant au système de communication de la ;
la est un diagramme représentant un mode particulier de mise en œuvre du procédé de traitement de données selon l’invention, tel qu’exécuté par le dispositif de centralisation de la ;
la illustre schématiquement un exemple de mise en œuvre d’une étape d’identification de données conformes lors de l’exécution du procédé de traitement de données de la ;
la est un diagramme représentant des étapes mises en œuvre par le dispositif de centralisation de la et par le dispositif de communication de la , pour qu’un travail effectué par ledit dispositif de communication dans le cadre du procédé de communication de la permette l’obtention d’une rétribution.

Description de modes de réalisation
La représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système de communication SYS selon l’invention.
Tel qu’illustré par la , le système SYS comporte une pluralité d’objets communicants. Plus particulièrement, dans le mode présent de réalisation, le système SYS comporte six objets communicants OBJ1, OBJ2, OBJ3, OBJ4, OBJ5, OBJ6 positionnés dans une zone géographique donnée.
Pour la suite de la description, on considère de manière nullement limitative que tous les objets communicants sont de même nature et correspondent à des capteurs configurés pour relever une consommation d’eau. Ces capteurs sont de conception connue en soi, et sont par ailleurs, dans cet exemple, agencés fixement en différents endroits d’un quartier d’une ville (exemples : canalisation(s) d’une habitation individuelle, canalisation(s) d’une entreprise, etc.) formant ladite zone géographique. La mise en place desdits capteurs a notamment pour objectif de suivre la consommation d’eau des habitants dudit quartier ainsi que des entreprises et salariés qui y travaillent.
Il importe toutefois de noter que le fait de considérer de tels capteurs de consommation d’eau ne constitue qu’une variante d’implémentation de l’invention. Ainsi, et d’une manière générale, aucune limitation n’est attachée à la nature dudit objet communicant dès lors que ce dernier est un objet apte à réaliser une fonction, la mise en œuvre de cette fonction lui permettant d’obtenir/acquérir/collecter des données d’information qui lui sont propres, i.e. des données qui caractérisent la fonction dudit objet communicant (dans le cas présent mode de réalisation, la fonction en question correspond à un relevé de consommation d’eau, et les données d’information en question correspondent à des relevés de consommation d’eau). En d’autres termes, dans le cadre de la présente invention, la notion d’objet communicant couvre tout objet de la vie courante, capteur, actionneur, etc., celui-ci pouvant être fixe ou mobile.
En outre, bien qu’il soit considéré ici que les objets communicants sont tous de nature identique (capteur) et réalise une même fonction (relevé de consommation d’eau), l’invention s’étend également au cas où au moins deux objets communicants sont de natures respectives distinctes et/ou réalisent des fonctions respectives distinctes. Cette généralisation implique également que l’invention n’est en rien limitée par le fait de considérer un quartier d’une ville en tant que zone géographique d’implantation des objets communicants, toute autre zone pouvant être envisagée (usine, exploitation agricole, etc.).
Le présent mode de réalisation est également décrit en considérant la présence de six objets communicants. Il convient toutefois de noter que le nombre d’objets communicants de constitue pas une limitation de l’invention, et rien n’exclut d’envisager un nombre d’objets communicants inférieur ou supérieur à six. En outre, l’invention peut également être mise en œuvre en considérant un unique objet communicant, l’homme du métier étant en mesure d’adapter la description qui suit à une telle configuration.
De manière similaire à ce qui a été décrit en référence à la , les objets communicants OBJi (i étant un indice entier compris ici entre 1 et 6) sont connectés à un réseau de communication. Ledit réseau de communication est par exemple ici un réseau cellulaire 5G. Toutefois cette hypothèse n’est pas limitative et l’invention s’applique à d’autres réseaux de communication, comme par exemple au réseau public Internet, à un réseau cellulaire autre que 5G, à un réseau Wi-Fi, à un réseau local ou propriétaire, etc. En outre, aucune limitation n’est attachée à la manière dont les objets OBJi sont connectés à ce réseau de communication : ils peuvent l’être par le biais d’une liaison filaire ou sans fil, d’un réseau d’accès mobile ou fixe, etc.
Cette connexion au réseau cellulaire 5G permet aux objets OBJi d’être connectés avec un dispositif de centralisation CPU appartenant au système SYS. Ledit dispositif de centralisation CPU forme également une entité d’un système informatique en nuage NET (« Cloud » en anglais) auquel il est donc possible d’avoir accès via le réseau public Internet. Aucune limitation n’est attachée à la nature dudit dispositif de centralisation CPU (exemple : serveur), dès lors que ce dernier est au moins équipé de moyens matériels et logiciels lui permettant de mettre en œuvre des étapes d’un procédé de traitement de données, comme cela est décrit plus en détail ultérieurement.
Le réseau de communication 5G permet à chaque objet communicant OBJi d’échanger des données, aussi bien en voie montante que descendante, avec le dispositif de centralisation CPU. A cet effet, chaque objet OBJi (respectivement le dispositif de centralisation CPU) comporte des moyens de communication configurés pour permettre de tels échanges de données sur le réseau de communication 5G, en s’appuyant notamment sur une interface de communication adaptée (exemple : carte réseau). Ces aspects sont bien connus de l’homme du métier si bien qu’ils ne sont pas davantage détaillés ici.
Outre les objets communicants OBJi ainsi que le dispositif de centralisation CPU, le système de communication SYS comporte également une pluralité de dispositifs de communication mobiles. Plus particulièrement, dans le présent mode de réalisation et tel qu’illustré par la , le système SYS comporte quatre dispositif de communications CNR1, CRN2, CRN3, CRN4.
Suivant des considérations similaires à celles évoquées ci-avant, aucune limitation n’est attachée au nombre de dispositif de communication pouvant appartenir au système SYS. Ce nombre peut donc être supérieur ou inférieur à quatre. Il est également possible d’envisager un unique dispositif de communication.
Chaque dispositif de communication CRNj (j étant un indice entier compris ici entre 1 et 4) est un dispositif de communication mobile. Par « mobile », on fait référence au fait qu’un dispositif de communication a la possibilité d’être déplacé dans l’espace, et en particulier au sein de la zone géographique dans laquelle sont situés les objets communicants OBJi, de sorte à être positionné dans leurs voisinages respectifs. Autrement dit, le fait de considérer un dispositif de communication CRNj comme mobile n’implique pas que celui-ci est nécessairement toujours en mouvement, mais permet d’envisager, suivant des exemples plus spécifiques de réalisation de l’invention, qu’il puisse demeurer statique dans l’espace.
Pour la suite de la description, on considère de manière nullement limitative que les dispositifs de communication CRNj sont des terminaux mobiles détenus par des utilisateurs respectifs, plus particulièrement, dans le présent mode de réalisation, des téléphones intelligents (smartphones). Lesdits utilisateurs sont par exemple des habitants de la zone géographique, des travailleurs dans une entreprise implantée dans la zone géographique, ou bien encore toute autre personne munie d’un téléphone intelligent est amené à se déplacer au sein de ladite zone géographique.
Le fait de considérer un téléphone intelligent en tant que dispositif de communication CRNj ne constitue qu’une variante d’implémentation de l’invention, et rien n’exclut d’envisager encore d’autres variantes, comme par exemple une tablette numérique, un ordinateur portable, un assistant personnel, etc. En particulier, l’invention n’est pas limitée par le fait qu’un dispositif de communication CRNj est la propriété d’un utilisateur, de sorte que son déplacement est lié à celui dudit utilisateur. Ainsi, rien n’exclut d’envisager qu’un dispositif de communication CRNj est autonome dans ses déplacements. En définitive, et de manière générale, aucune limitation n’est attachée à la nature d’un dispositif de communication CRNj.
Dans le cadre de la présente invention, la présence desdits dispositifs de communication CRNj a pour but de permettre la mise en place d’un réseau collaboratif de proximité entre les objets communicants OBJi et le dispositif de centralisation CPU, de sorte à tirer profit de la mobilité de ces derniers et ainsi faciliter la remontée vers ledit dispositif de centralisation CPU des relevés de consommation d’eau effectués par lesdits objets communicants OBJi. En ce sens, lesdits dispositifs de communication CRNj peuvent être vus comme des nœuds d’un tel réseau collaboratif, et sont dès lors dénommés par la suite « nœuds collaboratifs CRNj ».
Ainsi, chaque nœud collaboratif CRNj est configuré pour réaliser des traitements visant à collecter un ou plusieurs relevés de consommation d’eau auprès d’un ou plusieurs objets communicants OBJi, ainsi qu’à transmettre, vers le dispositif de centralisation CPU, des données comportant notamment le ou les relevés collectés, en mettant en œuvre un procédé de communication selon l’invention.
La représente schématiquement un exemple d’architecture matérielle d’un nœud collaboratif CRNj du système SYS de la .
Tel qu’illustré par la , un nœud collaboratif CRNj dispose de l’architecture matérielle d’un ordinateur. Ainsi, un nœud collaboratif CRNj comporte, notamment, un processeur 1_j, une mémoire vive 2_j, une mémoire morte 3_j et une mémoire non volatile 4_j. Il dispose en outre de moyens de communication 5_j.
La mémoire morte 3_j du nœud collaboratif CRNj constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 1_j et sur lequel est enregistré un programme d’ordinateur PROG_j conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de communication. Le programme PROG_j définit des modules fonctionnels du nœud collaboratif CRNj, qui s’appuient ou commandent les éléments matériels 1_j à 5_j du nœud collaboratif CRNj cités précédemment. Ces modules fonctionnels sont illustrés sur la à titre nullement limitatif, et sont décrits plus en détails ci-après en référence à des modes particuliers de mise en œuvre du procédé de communication.
Les moyens de communication 5_j permettent à un nœud collaboratif CRNj d’échanger (émission/réception) des données avec un ou plusieurs objets communicants. Plus particulièrement, un tel échange de données entre un nœud collaboratif CRNj et un objet communicant OBJi peut être mis en œuvre lorsque ces deux entités sont proches l’une de l’autre, ou, dit encore autrement, lorsque le nœud collaboratif CRNj est localisé dans un voisinage dudit objet communicant OBJi.
A cet effet, les moyens de communication 5_j s'appuient sur une interface de communication de courte portée configurée pour permettre ledit échange de données. Aucune limitation n'est attachée à la nature de cette interface, qui peut être filaire ou non filaire, de sorte à permettre l'échange de données selon tout protocole de communication de courte portée connu. Par exemple, le protocole utilisé peut être le protocole BLE (acronyme de l’expression anglosaxonne « Bluetooth Low Energy »). Selon un autre exemple, l’échange de données peut être mis en œuvre par rétrodiffusion ambiante.
Il découle donc de ces dispositions que les moyens de communication équipant chaque objet communicant OBJi, outre le fait d’être adaptés à une communication mobile de type 5G avec le dispositif de centralisation CPU, sont également adaptés à une communication de courte portée avec un nœud collaboratif CRNj.
On comprend par ailleurs que les notions de « voisinage » et de « courte portée » dépendent de l’interface et du protocole de communication considéré pour des échanges de données entre objets communicants OBJi et nœuds collaboratifs CRNj. A titre d’exemple, dans le cas d’une utilisation de la technologie BLE, le voisinage d’un objet communicant OBJi fait référence à une zone centrée sur ledit objet OBJi et s’étendant sur une distance de l’ordre de la centaine de mètres.
Les moyens de communication 5_j permettent également à un nœud collaboratif CRNj d’échanger (émission/réception) des données avec le dispositif de centralisation CPU. Dans le présent mode de réalisation, les échanges entre un nœud collaboratif CRNj et le dispositif de centralisation CPU s’effectuent au moyen du réseau cellulaire 5G. Il ne s’agit toutefois là que d’un exemple d’implémentation, et rien n’exclut d’envisager d’autres interfaces/protocoles de communication.
Il est à noter que le système SYS tel qu’illustré par la représente une configuration figée de l’ensemble des entités formant ce système SYS. Par « figée », on fait référence au fait que la est une représentation à un instant donné des liens de communication possibles entre les objets communicants OBJi et les nœuds collaboratifs CRNj, du fait de la mobilité de ces derniers au sein de la zone géographique. Aussi, en ledit instant donné, et tel que cela est représenté par la :
- le nœud CRN1 est situé dans un voisinage des (et donc apte à communiquer avec les) objets communicants OBJ1 et OBJ2 ;
- le nœud CRN2 est situé dans un voisinage des (et donc apte à communiquer avec les) objets communicants OBJ2 et OBJ3 ;
- le nœud CRN3 est situé dans un voisinage des (et donc apte à communiquer avec les) objets communicants OBJ4 et OBJ5 ;
- le nœud CRN4 est situé dans un voisinage des (et donc apte à communiquer avec les) objets communicants OBJ5 et OBJ6.
La configuration de la est donc une configuration destinée à évoluer dans le temps en raison de la mobilité des nœuds collaboratifs CRNj. Il est à noter que cette configuration pourrait également évoluer si par exemple un nœud collaboratif reste fixe et qu’un objet communicant se déplace dans le voisinage dudit nœud collaboratif ; on rappelle néanmoins qu’il est supposé, dans le présent mode de réalisation, que les objets communicants sont fixes et que seuls les nœuds collaboratifs ont la faculté de se déplacer dans la zone géographique.
Dans le cadre de la présente invention, un déplacement d’un nœud collaboratif CRNj dans la zone géographique peut s’effectuer de différentes manières. Par exemple, un tel déplacement est réalisé indépendamment des positions respectives des objets communicants OBJi dans la zone géographique. Dit encore autrement, dans cet exemple, les positions respectives des objets communicants OBJi ne conditionnent pas le déplacement d’un nœud collaboratif CRNj, ce dernier n’étant pas incité à dévier de sa trajectoire initiale pour se rendre dans le voisinage d’un objet communicant spécifique. A titre illustratif, un utilisateur en possession d’un nœud collaboratif CRNj peut se déplacer au sein de la zone pour aller de son domicile à son lieu de travail, et ne modifie pas son trajet habituel, de sorte que sa présence dans le voisinage d’un objet communicant est fortuite.
Selon un exemple alternatif, un déplacement d’un nœud collaboratif CRNj dans la zone géographique est réalisé pour satisfaire un critère d’intérêt à obtenir le relevé de consommation d’eau acquis par un ou plusieurs objets communicants OBJi donnés. Dit encore autrement, le critère d’intérêt en question est un critère visant à créer une incitation au déplacement d’un nœud collaboratif CRNj au sein de la zone pour se rendre spécifiquement dans les voisinages des objets communicants OBJi en question et ainsi obtenir/collecter leurs relevés de consommation d’eau respectifs.
Aucune limitation n’est associée à la nature d’un tel critère d’intérêt. A titre illustratif, un ou plusieurs objets communicants OBJi peuvent être localisés dans des endroits peu accessibles de la zone (localisation excentrée, en hauteur, peu desservie en transports en commun, etc.), de sorte que se rendre dans leurs voisinages demande un effort particulier de déplacement. Dès lors, s’il est envisagé de rétribuer (par exemple financièrement) un nœud collaboratif CRNj pour sa participation à un réseau collaboratif de collecte des relevés de consommation d’eau, comme cela est décrit plus en détail ultérieurement, le critère d’intérêt peut par exemple consister à valoriser davantage l’effort (le travail) effectué par ce nœud CRNj pour se rendre dans le voisinage d’un objet communicant OBJi difficilement accessible.
La connaissance d’un critère d’intérêt attaché à un objet communicant OBJi, par un nœud collaboratif CRNj, peut par exemple venir d’une requête spécifique transmise par le dispositif de centralisation CPU à un ou plusieurs différents nœuds collaboratifs présents dans la zone géographique. Alternativement, un nœud collaboratif CRNj peut per exemple obtenir la connaissance d’un critère d’intérêt en interrogeant une base de données dédiée.
La est un diagramme représentant un mode particulier de mise en œuvre du procédé de communication selon l’invention, tel qu’exécuté par un nœud collaboratif CRNj de la .
Pour la description du mode de mise en œuvre de la , on considère plus particulièrement, et de manière nullement limitative, que le nœud collaboratif concerné est le nœud CRN1 qui est un smartphone en possession d’un utilisateur. Ce smartphone est équipé d’une application logicielle dédiée au relevé de consommation d’eau des objets communicants OBJi, l’utilisateur ayant installé cette application logicielle pour participer à un réseau collaboratif d’aide à la réalisation de ces relevés.
On suppose également que cet utilisateur a pour intention de quitter son domicile pour se rendre en vélo sur son lieu de travail. Le trajet habituel domicile-travail de cet utilisateur est tel que le nœud collaboratif CRN1 est destiné à être localisé, au cours dudit trajet, dans les voisinages des objets communicants OBJ2, OBJ4 et OBJ5.
Il est également supposé que :
- l’objet communicant OBJ3 est associé à un critère d’intérêt pour obtenir le relevé de consommation d’eau qu’il mesure. Cela est dû, dans le cas présent, au fait que cet objet OBJ3 est positionné dans un lieu situé en hauteur (i.e. en extrémité d’une voie de circulation pentue),
- l’utilisateur du nœud collaboratif CRN1 décide d’effectuer son trajet domicile-travail en déviant de son trajet habituel, de sorte à effectuer le relevé de consommation d’eau mesuré par l’objet communicant OBJ3.
Tel qu’illustré par la , le procédé de communication comporte une étape E10 de déplacement. Cette étape E10 correspond à la mise en mouvement initiale du nœud collaboratif CRN1 du fait que l’utilisateur quitte son domicile, de sorte que ce dernier se situe, à un instant ultérieur à son départ, dans le voisinage de l’objet communicant OBJ2 (le signe « MOV » est utilisé dans la pour faire référence à l’étape E10).
Dès lors, le procédé de communication comporte une étape E20 de réception, en provenance de l’objet OBJ2, du relevé de consommation d’eau DATA_OBJ2 mesuré par ledit objet OBJ2. Cette étape E20 est mise en œuvre par un module de réception MOD_CRN1_RX équipant le nœud collaboratif CRN1 et intégré aux moyens de communication 5_1.
La réception du relevé DATA_OBJ2 peut par exemple faire suite à l’envoi d’une requête d’obtention de relevé émise par le nœud CRN1. Une telle requête peut par exemple être émise de manière périodique, suivant un pas de temps donné.
Selon un autre exemple, la réception du relevé DATA_OBJ2 peut faire suite à l’émission dudit relevé par l’objet OBJ2 sans qu’aucune requête ne soit transmise par le nœud CRN1. Une telle émission par l’objet OBJ2 peut par exemple être mise en œuvre de manière périodique, suivant un pas de temps donné.
D’une manière générale, aucune limitation n’est attachée à la manière dont un relevé est obtenu par un objet communicant.
Dans le présent mode de mise en œuvre, le procédé de communication comporte en outre une étape E30 de réception, en provenance de l’objet OBJ2, d’un jeton cryptographique vt_CRN1_OBJ2. Cette étape E30 est également mise en œuvre par le module de réception MOD_CRN1_RX.
Ledit jeton cryptographique vt_CRN1_OBJ2 est configuré de sorte que l’objet communicant OBJ2 et le dispositif de centralisation CPU sont les seules entités du système SYS aptes à déchiffrer ledit jeton vt_CRN1_OBJ2 (i.e. l’objet OBJ2 et le dispositif CPU sont les seuls à partager la connaissance de la méthode cryptographique sous-jacente utilisée).
Aucune limitation n’est attachée à la nature dudit jeton cryptographique, et tout méthode cryptographique connue de l’homme du métier permettant de générer/déchiffrer un tel jeton peut être utilisée. A titre d’exemple, la génération du jeton cryptographique peut être réalisée par l’objet OBJ2 en utilisant une fonction de hashage ainsi qu’une clé partagée avec le seul dispositif de centralisation CPU.
Le fait d’utiliser un tel jeton cryptographique vt_CRN1_OBJ2, ainsi relayé par le nœud collaboratif CRN1, permet d’enrichir l’ensemble de données destinées à être collectées par le nœud CRN1, étant entendu que cet enrichissement s’effectue de manière transparente vis-à-vis dudit nœud CRN1. En outre, ce jeton permet de fournir une preuve infalsifiable du travail effectué par le nœud collaboratif CRN1 pour obtenir et transmettre vers le dispositif de centralisation CPU les données propres à l’objet OBJ2, ce qui est particulièrement avantageux lorsqu’il y a lieu d’établir la preuve du travail en question, comme cela est décrit plus en détail ultérieurement.
Une fois le relevé DATA_OBJ2 de l’objet OBJ2 ainsi que le jeton vt_CRN1_OBJ2 reçus, le procédé de communication comporte une étape E40 de détermination d’une donnée d’interaction DATA_CRN1_OBJ2. Ladite étape E40 est mise en œuvre par un module de détermination MOD_CRN1_DET équipant le nœud collaboratif CRN1.
Dans le présent mode de mise en œuvre, ladite donnée d’interaction DATA_CRN1_OBJ2 comporte :
- une date t_CRN1_OBJ2 et une localisation loc_CRN1_OBJ2 de réception du relevé DATA_OBJ2. L’obtention de ladite date t_CRN1_OBJ2 et de ladite localisation loc_CRN1_OBJ2 s’effectue en utilisant des moyens connus en soi de datation (exemple : référence de temps fournie par le réseau cellulaire) et des moyens connus en soi de localisation (exemple : GPS, triangulation via le réseau cellulaire, positionnement par Wi-Fi, etc.) ;
- un identifiant id_OBJ2 de l’objet communicant OBJ2. Ledit identifiant id_OBJ2 est par exemple transmis au nœud CRN1 en même temps que le relevé DATA_OBJ2 (exemple : message encapsulant l’identifiant et le relevé) ;
- le jeton cryptographique vt_CRN1_OBJ2.
Par la suite, le procédé de communication comporte une étape E50 de transmission du relevé DATA_OBJ2 ainsi que de la donnée d’interaction DATA_CRN1_OBJ2 vers le dispositif de centralisation. Ladite étape E50 est mise en œuvre par un module d’émission MOD_ CRN1_TX équipant le nœud collaboratif CRN1 et intégré aux moyens de communication 5_1.
L’utilisateur du nœud CRN1 poursuit alors son déplacement, de sorte que les étapes E10, E20, E30, E40 et E50 sont itérées pour chacun des objets communicants OBJ3, OBJ4 et OBJ5. Dans ce mode particulier de mise en œuvre du procédé de communication, les données associées aux objets communicants OBJ4 et OBJ5 sont acquises à la même date et en la même localisation. Cela est dû au fait que ces objets OBJ4 et OBJ5 sont relativement proches l’un de l’autre au regard du trajet suivi par le nœud CRN1.
Ainsi, à l’issue de la mise en œuvre du procédé de communication par le nœud CRN1, seuls les objets OBJ1 et OBJ6 n’ont pas été en communication avec ce dernier. Les différentes données d’interaction DATA_CRN1_OBJ2, DATA_CRN1_OBJ3, DATA_CRN1_OBJ4, DATA_CRN1_OBJ5 permettent de définir la trajectoire utilisée par le nœud CRN1 au cours du procédé de communication. Cette trajectoire est caractérisée à la fois en espace et en temps, du fait des dates t_CRN1_OBJ2, t_CRN1_OBJ3, t_CRN1_OBJ4, t_CRN1_OBJ5 et des localisations loc_CRN1_OBJ2, loc_CRN1_OBJ3, loc_CRN1_OBJ4, loc_CRN1_OBJ5 contenues dans les données d’interaction.
Une telle trajectoire est représentée schématiquement à titre nullement limitatif par la . Dans cette , la zone géographique est représentée de manière schématique sous la forme d’un plan Z_GEO. Comme cela peut être observé, le trajet TRAJ_CRN1_NEW suivie par le nœud CRN1 (trait continue), pour relier son point de départ P_INI à son point de fin P_FIN, diffère du trajet TRAJ_CRN1_OLD traditionnellement suivi par ce dernier (traits pointillés). Cela est dû à l’effort supplémentaire de l’utilisateur du nœud CRN1 pour se rendre dans le voisinage de l’objet communicant OBJ_3.
Le procédé de communication a été décrit en considérant une étape E30 de réception d’un jeton cryptographique. Il importe toutefois de noter qu’une telle étape E30 est optionnelle. En particulier, rien n’exclut d’envisager des modes de mise en œuvre dans lesquels aucun objet communicant OBJi ne transmet de jeton cryptographique, ou bien dans lesquels seule une partie desdits objets communicants OBJi transmettent leurs jetons cryptographiques respectifs.
Le procédé de communication a également été décrit en considérant que l’étape de transmission E50 est mise en œuvre après chaque détermination d’une donnée d’interaction. Ces dispositions ne sont toutefois pas limitatives de l’invention, et rien n’exclut d’envisager d’autres modes de mise en œuvre dans lesquels l’étape de transmission E50 est mise en œuvre après que le nombre de données d’interaction déterminées est supérieur à un seuil donné.
Il résulte de ce qui précède que les nœuds CRNj peuvent, du fait de leur mobilité, remonter des données (relevés de consommation d’eau et données d’interaction) vers le dispositif de centralisation CPU. Cette remontée de données peut se faire à la volée, ou bien, alternativement, en différé (auquel cas les données destinées à être transmises par un nœud CRNj sont mémorisées localement, par exemple dans mémoire non volatile 4_j).
Le dispositif de centralisation CPU, quant à lui, est configuré pour réaliser des traitements visant à vérifier que les données qu’il reçoit en provenance d’un ou plusieurs nœuds collaboratifs CRNj correspondent un travail réellement effectué, en mettant en œuvre un procédé de traitement de données selon l’invention.
La représente schématiquement un exemple d’architecture matérielle du dispositif de centralisation CPU du système SYS de la .
Tel qu’illustré par la , le dispositif de centralisation CPU dispose de l’architecture matérielle d’un ordinateur. Ainsi, dispositif de centralisation CPU comporte, notamment, un processeur 1_CPU, une mémoire vive 2_CPU, une mémoire morte 3_CPU et une mémoire non volatile 4_CPU. Il dispose en outre de moyens de communication 5_CPU.
La mémoire morte 3_CPU du dispositif de centralisation CPU constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 1_CPU et sur lequel est enregistré un programme d’ordinateur PROG_CPU conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de traitement de données. Le programme PROG_CPU définit des modules fonctionnels du dispositif de centralisation CPU, qui s’appuient ou commandent les éléments matériels 1_CPU à 5_CPU du dispositif de centralisation CPU cités précédemment. Ces modules fonctionnels sont illustrés sur la à titre nullement limitatif, et sont décrits plus en détails ci-après en référence à des modes particuliers de mise en œuvre du procédé de traitement de données.
Les moyens de communication 5_CPU permettent au dispositif de centralisation CPU d’échanger (émission/réception) des données avec un ou plusieurs objets communicants OBJi, ainsi qu’avec un ou plusieurs nœuds collaboratifs CRNj. Les interfaces de communication et protocoles de communication permettant de réaliser ces échanges sont tels que décrits précédemment.
La est un diagramme représentant un mode particulier de mise en œuvre du procédé de traitement de données selon l’invention, tel qu’exécuté par le dispositif de centralisation de la .
Pour la description du mode de mise en œuvre de la , on considère plus particulièrement, et de manière nullement limitative, que le dispositif de centralisation CPU a déjà reçu, préalablement à la mise du présent mode de mise en œuvre, des données (relevés de consommation d’eau et données d’interaction) associées à l’objet communication OBJ2 en provenance du nœud collaboratif CRN3.
On considère en outre que le présent mode de mise en œuvre est initié suite à la transmission, par le nœud collaboratif CRN1, du relevé de consommation DATA_OBJ2 et de la donnée d’interaction DATA_CRN1_OBJ2 (voir la description faite en référence aux figures 4 et 5). Ces hypothèses sont faites uniquement à des fins de simplification de la description dudit mode de mise en œuvre.
Dans le mode de mise en œuvre de la , le procédé de traitement de données comporte dans un premier temps une étape F10 de réception, en provenance, du nœud collaboratif CRN1 du relevé de consommation DATA_OBJ2 et de la donnée d’interaction DATA_CRN1_OBJ2. Cette étape F10 est mise en œuvre par un module de réception MOD_CPU_RX équipant le dispositif de centralisation CPU et intégré aux moyens de communication 5_CPU.
Une fois le relevé de consommation DATA_OBJ2 et la donnée d’interaction DATA_CRN1_OBJ2 reçus, le procédé de traitement de données comporte une étape F20 d’identification, parmi les données reçues, de données satisfaisant un critère de conformité de travail, dites « données conformes ». Ladite étape F20 est mise en œuvre par un module d’identification MOD_CPU_ID équipant le dispositif de centralisation CPU (le signe « DATA CONF » est utilisé dans la pour faire référence à l’étape F20).
Dans le présent mode de mise en œuvre, le critère de conformité de travail comporte une condition consistant à vérifier si les données d’interaction DATA_CRN1_OBJ2, DATA_CRN3_OBJ2 qu’il a reçues et qui associées au même objet communicant OBJ2 sont compatibles entre elles dans le temps et dans l’espace en fonction de leurs dates et localisations respectives.
Par « compatibles entre elles dans le temps» (respectivement « compatibles entre elles dans l’espace »), on fait référence, dans le présent mode de mise en œuvre, au fait que les dates t_CRN1_OBJ2 et t_CRN3_OBJ2 (respectivement les localisations loc_CRN1_OBJ2 et loc_CRN3_OBJ2) sont sensiblement égales. Concrètement, cela revient à considérer que l’écart entre les dates t_CRN1_OBJ2 et t_CRN3_OBJ2 (respectivement entre les localisations loc_CRN1_OBJ2 et loc_CRN3_OBJ2) ne dépasse pas un seuil donné.
A titre purement illustratif, ce seuil peut être de 5 secondes en ce qui concerne les dates et de 10 mètres en ce qui concerne les localisations.
Il convient de noter que, dans le présent mode de mise en œuvre, il est considéré deux seuils, à savoir un seuil pour chaque paramètre (date, localisation). Cela étant, on peut bien entendu ne considérer qu’un seul seuil portant sur un paramètre hybride résultant d’une multiplication entre date et localisation (i.e. dans l’exemple considéré ici, on détermine la différence entre t_CRN1_OBJ2 x loc_CRN1_OBJ2 et t_CRN3_OBJ2 x loc_CRN3_OBJ2, et on compare cette différence avec le seuil en question).
De tels seuils de temps et d’espace permettent donc de définir une tolérance vis-à-vis des interactions remontées vers le dispositif de centralisation CPU par différents nœuds collaboratifs pour un même objet communicant. On comprend en effet que si deux données d’interaction remontées par deux nœuds distincts pour un même objet communicant présentent d’une part des dates sensiblement égales et d’autre part des localisations très différentes, il est alors raisonnable de considérer que ces données sont problématiques et qu’elles ne peuvent pas être considérées comme conformes. De telles situations peuvent par exemple se présenter en cas de bugs, ou bien, en cas de tentatives de fraude (exemple : usurpation d’identité d’un nœud collaboratif).
Selon un autre exemple de mise en œuvre, illustré par la à titre nullement limitatif, pour vérifier que les données d’interaction DATA_CRN1_OBJ2, DATA_CRN3_OBJ2 sont compatibles entre elles dans le temps et dans l’espace, il est tenu compte, pour chaque paramètre (date, localisation) d’une tolérance, par exemple liée à la mesure dudit paramètre. Cette tolérance permet donc de définir, pour chaque date t_CRN1_OBJ2, t_CRN3_OBJ2 (respectivement pour chaque localisation loc_CRN1_OBJ2, loc_CRN3_OBJ2) un intervalle, dit « intervalle temporel d’occurrence I_CRN1_OBJ2, I_CRN3_OBJ2 » (respectivement un cercle, dit « cercle géographique d’occurrence C_CRN1_OBJ2, C_CRN3_OBJ2 »). Dès lors, si lesdits intervalles I_CRN1_OBJ2, I_CRN3_OBJ2 (respectivement lesdits cercles C_CRN1_OBJ2, C_CRN3_OBJ2) présentent une intersection non vide, il est possible d’en conclure que les données d’interaction DATA_CRN1_OBJ2, DATA_CRN3_OBJ2 sont compatibles entre elles, et forment ainsi des données conformes (comme cela est le cas dans l’exemple illustré par la du fait des parties hachurées).
Il importe de noter que la mise en œuvre de l’étape F20 n’est pas limitée par les exemples détaillés ci-avant, d’autres variantes pouvant encore être envisagées. Ainsi, en alternative ou en combinaison avec les exemples précédents, rien n’exclut (pour identifier des données conformes) de comparer avec un seuil la différence entre deux relevés de consommation d’eau associés à un même objet communicant et effectués à des dates proches l’une de l’autre. Procéder de cette manière permet de vérifier que deux relevés de consommation d’eau sont concordants lorsqu’ils sont effectués en des dates proches les unes des autres.
En outre, lorsque le dispositif de centralisation CPU a reçu une pluralité de données d’interaction associées à un même objet communicant, il peut également être envisagé que le critère de conformité comporte une condition consistant à vérifier que le cardinal de ladite pluralité de données d’interaction est supérieur à un seuil donné. Procéder de cette manière permet de créer un compteur du nombre de fois où un objet communicant OBJi communique son relevé à des nœuds collaboratifs CRNj. La vérification de la conformité d’une donnée est alors conditionnée par le fait que le compteur dépasse ledit seuil, ce qui permet par exemple de disqualifier des situations singulières dans lesquelles très peu de données associées à un objet communicant sont remontées au dispositif de centralisation CPU, alors même que ledit objet communicant est placé dans un endroit où il est attendu qu’un nombre important de nœuds s’y déplacent.
D’une manière générale, les exemples de mise en œuvre décrit ci-avant en référence à l’étape F20 permettent d’identifier des données conformes en croisant différentes données remontées par différents nœuds collaboratifs pour un même objet communicant. Procéder de cette manière permet avantageusement de tirer parti de la présence de plusieurs nœuds collaboratifs au sein de la zone géographique. Dit encore autrement, le réseau collaboratif découlant de la présence de ces nœuds dans la zone géographique fournit un outil efficace pour vérifier la conformité de données remontées par ces nœuds.
Il importe de noter que les exemples précédents ont été essentiellement décrits sur la base des hypothèses mentionnées ci-avant pour l’exécution du procédé de traitement de données, à savoir notamment que les différentes étapes s’appuient sur des données remontées par les seuls nœuds CRN1 et CRN3 en rapport avec l’objet communicant OBJ2. Toutefois, le procédé de traitement de données n’est bien entendu pas limité par de telles hypothèses, et s’applique en définitive indépendamment du nombre de nœuds collaboratifs et du nombre de données remontées.
En particulier, l’étape F20 peut consister à croiser des données remontées par des nœuds collaboratifs qui couvrent une fenêtre temporelle de taille donnée, à la manière d’une mémoire tampon.
Indépendamment du nombre de données remontées par un ou plusieurs nœuds collaboratifs vers le dispositif de centralisation CPU, le critère de conformité peut également être vérifié sans qu’il soit nécessaire de procéder à un croisement entre plusieurs trajectoires de nœuds collaboratifs. Par exemple, l’étape F20 peut être mise en œuvre de sorte que, lorsqu’une donnée d’interaction comporte un jeton cryptographique (par exemple le jeton vt_CRN1_OBJ2), le critère de conformité de travail comporte une condition consistant à vérifier que le dispositif de centralisation CPU est apte à déchiffrer ledit jeton cryptographique. Autrement dit, dans cet exemple, la présence du jeton cryptographique permet de fournir une garantie quant à la conformité de données remontées par un nœud collaboratif. Une telle mise en œuvre est donc avantageuse en ce qu’elle lève la contrainte d’avoir accès aux données fournies par différents nœuds collaboratifs pour identifier des données conformes.
Selon un autre exemple alternatif, il peut être considéré qu’un nœud collaboratif est un nœud collaboratif de confiance. Autrement dit, dans ce cas, toute donnée remontée par ce nœud collaboratif de confiance est automatiquement identifiée comme conforme. Le dispositif de centralisation CPU peut par exemple avoir la connaissance d’une liste de nœuds collaboratifs considérés comme étant de confiance.
Suivant encore d’autres aspects de mise en œuvre, l’identification de données conformes selon l’étape F20 peut par exemple être exécutée à chaque réception de nouvelles données en provenance d’un nœud collaboratif (cette approche est celle mise en œuvre dans la description de la ). De cette manière, le dispositif de centralisation peut surveiller en temps réel la conformité des données qui lui sont remontées.
A l’inverse, et selon un autre exemple, l’étape F20 peut être exécutée en différée, par exemple périodiquement selon un pas de temps déterminé.
En définitive, au regard de ce qui précède, on comprend qu’aucune limitation n’est attachée à la manière dont il est possible d’identifier des données conformes en utilisant un critère de conformité.
De retour à la , on considère à titre illustratif que les données DATA_OBJ2 et DATA_CRN1_OBJ2 remontées par le nœud collaboratif CRN1 au dispositif de centralisation CPU ont été identifiées comme conformes suite à l’exécution de l’étape F20. Dès lors, le procédé de traitement de données comporte une étape F30 de détermination d’une donnée de preuve de travail PDT_CRN1 caractérisant une quantité de travail effectuée par ledit nœud collaboratif CRN1 pour obtenir et transmettre le relevé de consommation DATA_OBJ2 et la donnée d’interaction DATA_CRN1_OBJ2. Ladite étape F30 est mise en œuvre par un module de détermination MOD_CPU_DET équipant le dispositif de centralisation.
Dans son principe général, l’étape F30 vise à certifier, via la détermination de la donnée PDT_CRN1, que le nœud collaboratif CRN1 a bien effectué un travail valide. Autrement dit, il s’agit de générer une preuve de ce travail valide, cette preuve pouvant faire l’objet de traitements ultérieurs, par exemple dans le cadre d’une rétribution financière de l’utilisateur du nœud CRN1 comme détaillé ultérieurement.
En tout état de cause, pour valider (certifier) le travail effectué par le nœud CRN1, il convient d’être en mesure de quantifier ce travail, ou, dit encore autrement, de lui associer une métrique de mesure. A cet effet, dans le présent mode de mise en œuvre, la quantité de travail est fonction de trois paramètres, à savoir :
- la durée T pour obtenir les données DATA_OBJ2 et DATA_CRN1_OBJ2, ladite durée T étant fonction de la date t_CRN1_OBJ2. En pratique, dans l’exemple considéré ici pour illustrer le procédé de traitement de données, ladite date t_CRN1_OBJ2 permet d’évaluer le temps mis par l’utilisateur du nœud CRN1 pour récupérer lesdites données, à partir du moment où il entame son trajet domicile-travail. On comprend toutefois que si plusieurs données conformes respectivement associées à plusieurs objets communicants sont considérées, alors ladite durée T correspond par exemple à la durée totale nécessaire à la collecte de ces données conformes. Par exemple, en référence à la , la durée T peut par exemple correspondre à la durée nécessaire à la collecte des données des objets OBJ2, OBJ3, OBJ4, et OBJ6 ;
- la surface géographique S parcourue pour obtenir les données DATA_OBJ2 et DATA_CRN1_OBJ2, ladite surface géographique S étant fonction de la localisation loc_CRN1_OBJ2 ;
- le nombre N d’objets communicants à partir desquels ont été obtenues les données DATA_OBJ2 et DATA_CRN1_OBJ2. En pratique N est égal à 1 dans l’exemple considéré ici pour illustrer le procédé de traitement de données.
Plus particulièrement, la quantité de travail s’exprime en unités de travail, une unité de travail s’exprimant sous la forme d’un vecteur [Tu, Su, Nu], où Tu, Su, Nu correspondent respectivement à une durée donnée, une surface géographique donnée. En outre, dans cet exemple, la quantité de travail est égale à la somme d’un premier terme QdT1 et d’un deuxième terme QdT2. Le premier terme QdT1 défini par :
QdT1 = min(E(T/Tu), E(S/Su), E(N/Nu)),
expression dans laquelle E désigne la fonction partie entière, et min la fonction minimum. Le deuxième terme QdT2, quant à lui, est défini par :
QdT2 = max((T mod Tu)/Tu, (S mod Su)/Su, (N mod Nu)/Nu),
expression dans laquelle mod désigne la fonction modulo et max la fonction maximum.
Ainsi, dans le présent mode de mise en œuvre, l’unité de travail est définie de manière générique sur la base de critères propres au fonctionnement du réseau collaboratif. Plus spécifiquement, l’unité de travail est définie en tant que nombre Nu d’objets communicants « vus » dans une fenêtre temporelle Tu et une surface Su. A titre purement illustratif, le vecteur [Tu, Su, Nu] peut être égal à [7 jours, 2 km2, 10]. En outre, cette manière de définir la quantité de travail (= QdT1 + QdT2) permet de prendre en compte une partie décimale, ce qui permet de réaliser des calculs précis.
Le fait de considérer une quantité de travail égale à la somme de QdT1 et QdT2 ne constitue cependant qu’une variante d’implémentation de l’invention, et rien n’exclut d’envisager d’autres variantes. A titre d’exemple, il est possible de ne prendre en compte que le seul premier terme QdT1 (i.e. la quantité de travail est une quantité entière, ne comportant pas de partie décimale).
En outre, si les paramètres T, S et N ont été précédemment considérés de manière séparée pour définir une métrique de la quantité de travail, rien n’exclut d’envisager un ou plusieurs paramètres hybrides résultant d’une combinaison desdits paramètres T, S et N. Par exemple, les paramètres T et S peuvent être combinés par multiplication. De cette manière, on définit un vecteur d’unité de travail [Tu x Su, Nu].
Il a par ailleurs été considéré jusqu’à présent que la quantité de travail s’exprime en fonction des trois paramètres T, S et N (qu’ils soient combinés ou non). Toutefois, rien n’exclut bien entendu d’envisager une définition moins restrictive de la quantité de travail, comme par exemple une quantité de travail qui est fonction d’un seul ou bien de seulement deux paramètres parmi lesdits trois paramètres.
Alternativement, la quantité de travail effectuée par un nœud collaboratif CRNj pour obtenir et transmettre des données au dispositif de centralisation CPU peut être définie indépendamment dates et localisations contenues dans lesdites données. Par exemple, il peut être considéré que la quantité de travail est une donnée fixe pour chaque objet communicant OBJi auprès duquel le nœud collaboratif CRNj obtient des données. Dit encore autrement, dans ce cas, la quantité de travail dépend uniquement du nombre d’objets communicants à partir desquels sont obtenus des données, sans que ne soit pas pris en compte le temps nécessaire (respectivement la surface à couvrir nécessaire) pour réaliser cette obtention.
En définitive, et de manière générale, aucune limitation n’est attachée à la manière dont une quantité de travail est définie dans le cadre de la présente invention.
La donnée de preuve de travail PDT_CRN1 ainsi déterminée suite à l’exécution de l’étape F30 est donc porteuse d’une information caractérisant la quantité de travail effectué par le nœud CRN1 pour obtenir et transmettre les données DATA_OBJ2 et DATA_CRN1_OBJ2 (cette information correspond par exemple à une valeur numérique indicative de ladite quantité de travail, par exemple égale à QdT1 + QdT2). Dès lors, et comme mentionné auparavant, un des intérêts liés à la détermination de ladite donnée PDT_CRN1 est de pouvoir utiliser cette dernière en tant que certificat (attestation) reconnue d’un travail effectivement fourni pour le nœud CRN1.
Une telle utilisation est illustrée à titre nullement limitatif par la . Plus particulièrement, la est un diagramme représentant des étapes mises en œuvre par le dispositif de centralisation CPU et par le nœud collaboratif CRN1, après que la donnée de preuve de travail PDT_CRN1 ait été déterminée (étape F30 du procédé de traitement de données).
Plus particulièrement, dans cet exemple d’utilisation, l’utilisateur en possession du nœud collaboratif CRN1 souhaite obtenir une rétribution financière eu égard au travail qu’il a fourni pour obtenir et transmettre les données DATA_OBJ2 et DATA_CRN1_OBJ2 au dispositif de centralisation CPU.
Aussi, et tel qu’illustré par la , le procédé de traitement de données exécuté par le dispositif de centralisation CPU comporte une étape F40 de transmission de la donnée de preuve de travail PDT_CRN1 au nœud collaboratif CRN1. Ladite étape F40 est mise en œuvre par un module de transmission MOD_CPU_TX équipant le dispositif de centralisation CPU et intégré aux moyens de communication 5_CPU.
Cette étape F40 de transmission est par exemple mise en œuvre sur réception d’une requête envoyée par le nœud collaboratif CRN1 pour obtenir une donnée de preuve de travail.
Selon un autre exemple, la transmission d’une donnée de preuve de travail à un nœud collaboratif est mise en œuvre de manière itérative, par exemple à chaque fois qu’une donnée de preuve de travail a été déterminée, ou bien encore par exemple de manière périodique selon un pas de temps déterminé.
Dès lors, le procédé de communication exécuté par le nœud CRN1 comporte une étape E60 de réception de la donnée de preuve de travail PDT_CRN1, puis une étape E70 de transmission de cette donnée PDT_CRN1 à un dispositif de rétribution D_PAY.
Plus particulièrement, on considère ici de manière nullement limitative que le dispositif de rétribution D_PAY est configurée pour fournir une rétribution sous forme de cryptomonnaie (exemple : Bitcoin) au nœud CRN1, ladite rétribution étant fonction de ladite donnée de preuve de travail PDT_CRN1.
Bien entendu, le fait de considérer une rétribution sous forme de cryptomonnaie ne constitue qu’une variante d’implémentation de l’invention, et toute autre forme de rétribution, même non financière (par exemple sous la forme d’un service), peut être envisagée.
Comme illustré par la , le procédé de communication exécuté par le nœud CRN1 comporte alors une étape E80 d’obtention de ladite rétribution fournie par le système de rétribution D_PAY (le signe « OBT RETRIB » est utilisé dans la pour faire référence à ladite étape E60).
Il est à noter que l’exemple de mise en œuvre de la a été décrit en considérant que c’est le nœud CRN1 qui transmet au dispositif de rétribution D_PAY la donnée de preuve de travail PDT_CRN1. Il peut donc être avantageux que ledit nœud CRN1 soit vu comme une entité de confiance par le dispositif de rétribution D_PAY, de sorte que la donnée PDT_CRN soit admise par ce dernier. Une manière de créer un tel lien de confiance peut par exemple consister en ce que la donnée de preuve de travail PDT_CRN1, outre une information concernant la quantité de travail effectuée, comporte également un jeton cryptographique (l’insertion du jeton dans la donnée PDT_CRN1 étant par exemple effectuée lors de l’étape F30) que seuls le dispositif de centralisation CPU et le dispositif de rétribution D_PAY sont aptes à déchiffrer. Un tel jeton cryptographique peut par exemple avoir une durée de validité limitée (i.e., le jeton est associé à une date de péremption au-delà de laquelle la donnée de preuve de travail PDT_CRN1 n’est plus considérée comme valide).
Toutefois, rien n’exclut d’envisager, suivant d’autres exemples de mise en œuvre, que le dispositif de centralisation CPU communique cette donnée PDT_CRN1 directement au dispositif de rétribution D_PAY. Cela peut notamment être le cas lorsque le dispositif de centralisation CPU est vu comme une entité de confiance par le dispositif de rétribution D_PAY. Là encore, un tel lien de confiance peut être par exemple mis en œuvre au moyen d’un jeton cryptographique dont la durée de validité peut éventuellement être limitée.
Il importe de noter que la procédé de traitements de données a été essentiellement décrit jusqu’à présent en considérant, à des fins de simplification de la description, la seule transmission des données DATA_OBJ2 et DATA_CRN1_OBJ2 par le seul nœud collaboratif CRN1 vers le dispositif de centralisation CPU. Par conséquent, et comme ces données avaient été déterminées conformes, la détermination de la donnée de preuve de travail PDT_CRN1 était réalisée sur la base de ces seuls données jugées conformes.
Cela étant, et comme déjà évoqué auparavant, rien n’exclut d’envisager qu’une pluralité de données associées à différents objets communicants OBJj sont transmises, ces données pouvant provenir d’un ou plusieurs nœuds collaboratifs CRNj (le traitement de ces données pouvant s’effectuer, côté dispositif de centralisation CPU, en temps réel ou bien de manière différée). Aussi, l’invention couvre également des modes de mise en œuvre plus généraux que ceux décrits précédemment, dans lesquels, lorsque l’étape F20 d’identification permet d’identifier une pluralité de données conformes associées à plusieurs objets communicants, la détermination (étape F30) d’une donnée de preuve de travail est effectuée sur une partie P desdites données identifiées comme conformes.
La notion de « partie » d’un ensemble, dans le cadre de la présente invention, n’est pas restrictive d’un point de vue ensembliste. Par exemple, la partie P peut comporter la totalité des données identifiées comme conformes lors de l’étape F20.
Selon un autre exemple, la partie P peut être strictement incluse dans l’ensemble des données identifiées comme conformes lors de l’étape F20. Dès lors, dans cet exemple, pour définir la partie P, le procédé de traitement comporte en outre une étape de détermination des données de la partie P dites « données sélectives ». Aucune limitation n’est attachée à la manière dont est mise en œuvre cette étape de détermination des données sélectives. A titre illustratif, les données sélectives sont déterminées de sorte que :
- la durée pour obtenir lesdites données sélectives satisfait une première contrainte, ladite durée étant fonction des dates associées aux données sélectives. Une telle première contrainte correspond par exemple à une contrainte de majoration par un premier seuil donné de la durée nécessaire à l’obtention desdites données sélectives ; et/ou
- la surface géographique parcourue pour obtenir lesdites données sélectives satisfait une deuxième contrainte, ladite surface géographique étant fonction des localisations associées aux données sélectives. Une telle deuxième contrainte correspond par exemple à une contrainte de minoration par un deuxième seuil donné de la surface à parcourir pour obtenir lesdites données sélectives.
Par ailleurs, l’invention a également été décrite jusqu’à présent en considérant que les objets communicants OBJi sont intégrés au système de communication SYS. Toutefois, ces dispositions ne sont pas limitatives de l’invention, et rien n’exclut d’envisager des modes de réalisation dans lesquels le système de communication SYS intègre uniquement le dispositif de centralisation CPU et les nœuds collaboratifs CRNj.

Claims (15)

  1. Procédé de communication mis en œuvre par un dispositif de communication mobile (CRN1) et comportant, pour au moins un objet communicant (OBJ1) positionné dans une zone géographique donnée et lorsque le dispositif de communication est localisé dans un voisinage dudit au moins un objet communicant, des étapes de :
    - réception (E20), en provenance dudit au moins un objet communicant, d’une donnée d’information (DATA_OBJ2) propre audit au moins un objet communicant,
    - détermination (E40) d’une donnée d’interaction (DATA_CRN1_OBJ2) comportant une date (t_CRN1_OBJ2) et une localisation (loc_CTN1_OBJ2) de réception de la donnée d’information ainsi qu’un identifiant (id_OBJ2) dudit au moins un objet communicant,
    - transmission (E50) de ladite donnée d’interaction vers un dispositif de centralisation (CPU).
  2. Procédé selon la revendication 1, ledit procédé étant mis en œuvre pour une pluralité d’objets communicants (OBJ1, OBJ2, OBJ3, OBJ4, OBJ5, OBJ6) positionnés dans la zone.
  3. Procédé selon l’une quelconque des revendications 1 à 2, ledit procédé comportant, pour au moins un objet communicant, une étape de déplacement (E10) du dispositif de communication au sein de la zone et permettant audit dispositif de communication d’être positionné dans le voisinage dudit au moins un objet communicant, ladite étape de déplacement étant réalisée :
    - indépendamment de la position dudit au moins un objet communicant dans la zone, ou
    - pour satisfaire un critère d’intérêt à obtenir la donnée d’information dudit au moins un objet communicant.
  4. Procédé selon l’une quelconque des revendications 1 à 3, ledit procédé comportant également, pour au moins un objet communicant, une étape (E30) de réception, en provenance dudit au moins un objet communicant, d’un jeton cryptographique (vt_CRN1_OBJ2), la donnée d’interaction étant déterminée de sorte à comporter également ledit jeton.
  5. Procédé selon l’une quelconque des revendications 1 à 4, ledit procédé comportant en outre une étape de réception (E60), en provenance du dispositif de centralisation, d’une donnée de preuve de travail (PDT_CRN1) caractérisant une quantité de travail effectuée par le dispositif de communication pour obtenir et transmettre au moins une partie de ladite au moins une donnée d’information et de ladite au moins une donnée d’interaction.
  6. Procédé selon la revendication 5, ledit procédé comportant en outre des étapes de :
    - transmission (E70) de la donnée de preuve de travail à un dispositif de rétribution (D_PAY),
    - obtention (E80) d’une rétribution, par exemple sous forme de cryptomonnaie, ladite rétribution étant fonction de ladite donnée de preuve de travail.
  7. Procédé de traitement de données mis en œuvre par un dispositif de centralisation (CPU), ledit procédé comportant, pour au moins un dispositif de communication mobile (CRN1), des étapes de :
    - réception (F10), en provenance dudit au moins un dispositif de communication mobile, d’au moins une donnée d’information (DATA_OBJ2) et d’au moins une donnée d’interaction (DATA_CRN1_oBJ2) obtenues et transmises conformément à un procédé de communication selon l’une quelconque des revendications 1 à 6,
    - identification (F20), parmi les données reçues, de données satisfaisant un critère de conformité de travail, dites « données conformes »,
    - détermination (F30) d’une donnée de preuve de travail (PDT_CRN1) caractérisant une quantité de travail effectuée par ledit au moins un dispositif de communication pour obtenir et transmettre une partie P desdites données conformes.
  8. Procédé selon la revendication 7, dans lequel, lorsque le dispositif de centralisation a reçu, en provenance de plusieurs dispositifs de communication, une pluralité de données d’interaction associées à un même objet communicant, le critère de conformité de travail comporte une condition consistant à vérifier si lesdites données d’interaction reçues sont compatibles entre elles dans le temps et dans l’espace en fonction de leurs dates et localisations respectives.
  9. Procédé selon l’une quelconque des 7 à 8, dans lequel, lorsqu’une donnée d’interaction comporte un jeton cryptographique (vt_CRN1_OBJ2) conformément à la revendication 4, le critère de conformité de travail comporte une condition consistant à vérifier que le dispositif de centralisation est apte à déchiffrer ledit jeton cryptographique.
  10. Procédé selon l’une quelconque des revendications 7 à 9, dans lequel la quantité de travail est fonction d’au moins un paramètre parmi :
    - la durée T pour obtenir les données de la partie P, ladite durée T étant fonction des dates associées aux données de la partie P,
    - la surface géographique S parcourue pour obtenir les données de la partie P, ladite surface géographique S étant fonction des localisations associées aux données de la partie P,
    - le nombre N d’objets communicants à partir desquels ont été obtenues les données de la partie P.
  11. Procédé selon l’une quelconque des revendications 7 à 10, ledit procédé comportant en outre une étape de transmission (F40) de la donnée de preuve de travail audit au moins un dispositif de communication ou bien à un dispositif de rétribution (D_PAY), de sorte que le dispositif de communication obtienne une rétribution, par exemple sous forme de cryptomonnaie, ladite rétribution étant fonction de ladite donnée de preuve de travail.
  12. Programme d’ordinateur (PROG_j, PROG_CPU) comportant des instructions pour la mise en œuvre d’étapes de :
    - un procédé de communication selon l’une quelconque des revendications 1 à 6, ou
    - un procédé de traitement de données selon l’une quelconque des revendications 7 à 11,
    lorsque ledit programme est exécuté par un ordinateur.
  13. Dispositif de communication (CRN1) comportant des moyens configurés pour mettre en œuvre un procédé de communication selon l’une quelconque des revendications 1 à 6.
  14. Dispositif de centralisation (CPU) comportant des moyens configurés pour mettre en œuvre un procédé de traitement de données selon l’une quelconque des revendications 7 à 11.
  15. Système de communication (SYS) comportant au moins un dispositif de communication selon la revendication 13 ainsi qu’un dispositif de centralisation selon la revendication 14.
FR2213903A 2022-12-20 2022-12-20 Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés Pending FR3143820A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2213903A FR3143820A1 (fr) 2022-12-20 2022-12-20 Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2213903 2022-12-20
FR2213903A FR3143820A1 (fr) 2022-12-20 2022-12-20 Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés

Publications (1)

Publication Number Publication Date
FR3143820A1 true FR3143820A1 (fr) 2024-06-21

Family

ID=86468728

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2213903A Pending FR3143820A1 (fr) 2022-12-20 2022-12-20 Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés

Country Status (1)

Country Link
FR (1) FR3143820A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3116983A1 (fr) * 2020-12-02 2022-06-03 Orange Mise en œuvre d’une voie descendante dans un réseau collaboratif

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3116983A1 (fr) * 2020-12-02 2022-06-03 Orange Mise en œuvre d’une voie descendante dans un réseau collaboratif

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CHEN HONGLONG ET AL: "A Secure Credit-Based Incentive Mechanism for Message Forwarding in Noncooperative DTNs", IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, IEEE, USA, vol. 65, no. 8, 1 August 2016 (2016-08-01), pages 6377 - 6388, XP011619464, ISSN: 0018-9545, [retrieved on 20160811], DOI: 10.1109/TVT.2015.2477164 *
JUN ZHOU ET AL: "TIS: A threshold incentive scheme for secure and reliable data forwarding in vehicular Delay Tolerant Networks", GLOBAL COMMUNICATIONS CONFERENCE (GLOBECOM), 2012 IEEE, IEEE, 3 December 2012 (2012-12-03), pages 985 - 990, XP032374798, ISBN: 978-1-4673-0920-2, DOI: 10.1109/GLOCOM.2012.6503241 *

Similar Documents

Publication Publication Date Title
EP1650996A1 (fr) Serveur de gestion pour la détermination de cartographies de qualité de service perçue au sein d'un réseau de communication mobile
EP3891959A1 (fr) Passerelle pour communiquer par réseau radio avec au moins un noeud et par un réseau filaire, par le biais d'une blockchain
EP3891678A1 (fr) Dispositif pour communiquer dans un reseau de passerelles heterogenes par reseau radio avec au moins un noeud et par un reseau longue distance, avec au moins un destinataire
FR3143820A1 (fr) Procédés de communication et de traitement de données pour la mise en œuvre d’un réseau collaboratif, dispositifs et système associés
EP3622688B1 (fr) Singularisation de trames à émettre par un objet connecté et blocage de trames réémises sur un réseau de communication sans-fil basse consommation
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
WO2018193201A1 (fr) Procédés pour le partage de données de localisation entre un dispositif source d'un utilisateur et un dispositif destinataire d'un tiers, serveur, dispositif source d'un utilisateur, dispositif destinataire d'un tiers et programme d'ordinateur correspondants
FR3054396B1 (fr) Systeme et procede de mesure d'audience centree-utilisateur, par capture et analyse d'images affichees par un terminal associe a au moins un paneliste.
EP3785403B1 (fr) Procédé d'élaboration de données d'utilisation de relais utilisés au cours d'une communication entre deux appareils, de recherche desdites données, et appareils associés
FR3052003B1 (fr) Systeme et procede de mesure d’audience, et audimetre individuel portable correspondant.
WO2023099318A1 (fr) Procede d'obtention d'une valeur d'une variable representative d'un deplacement d'un terminal mobile, dispositif et programme d'ordinateur correspondant
FR3051585B1 (fr) Procede et systeme de transmission d'une alerte geolocalisee a un utilisateur muni d'un terminal mobile de communication
WO2015107175A1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d'ordinateur correspondants
WO2023099319A1 (fr) Procédé de détermination d'un déplacement d'un terminal mobile, dispositif et programme d'ordinateur correspondant
EP2806386A1 (fr) Procédé et systeme pour signaler automatiquement un évènement à partir de fichiers reçus sur un serveur informatique
WO2024002868A1 (fr) Procédés de fourniture et de collecte, station de base, dispositif de collecte et d'analyse de données et système
EP4391485A1 (fr) Procédé et dispositif de traitement d'un message reçu par un client électronique d'un agent conversationnel
FR3112265A1 (fr) Procédé de notification d’un équipement de gestion d’évènements de la survenue d’au moins un évènement relatif à un premier terminal de communication, et dispositifs associés
FR3128603A1 (fr) Procédé d’établissement d’un jeton de certification d’une instanciation d’une grappe de nœuds.
FR2965138A1 (fr) Procede, programme d'ordinateur et dispositif de contole de communication entre un terminal mobile et au moins un autre terminal selon leur position relative
FR3117723A1 (fr) Géolocalisation d’équipements communicants dans un réseau collaboratif
FR3134491A1 (fr) Procédé d’activation d’un protocole de sécurité sur un terminal mobile, produit programme d’ordinateur et dispositifs correspondants
WO2011023904A1 (fr) Procede de diffusion d'un contenu dans un reseau de telecommunications de maniere geolocalisee
FR3115647A1 (fr) Dispositif et procédé de traitement d’un message et d’émission de message LPWAN
FR3042362A1 (fr) Moyens de gestion d'acces a des donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240621