FR2927211A1 - Procede de traitement de donnees de consommation d'une ressource telle que du courant electrique - Google Patents

Abstract

Dans le procédé de traitement de données de consommation d'une ressource:- un premier serveur (18) commande un enregistrement sous forme linéarisée des données de consommation d'une ressource ; et- un deuxième serveur (20) commande une obtention des données à partir du premier serveur et leur délinéarisation.

Description

-1- L'invention concerne la consommation d'une ressource telle qu'une ressource énergétique et en particulier la diffusion des informations concernant cette consommation. Il est connu de fournir à l'occupant d'une installation des informations sur la consommation par l'installation d'un ressource telle que du courant électrique. Pour cela, des relevés périodiques sont effectués sur un compteur de l'installation puis rassemblés dans un dispositif au sein de l'installation. Régulièrement, ces relevés ainsi groupés sont envoyés à un premier serveur par exemple détenu par un premier prestataire. Les données sont stockées dans ce serveur dans des fichier plats qui sont délinéarisés toute les 24 heures par le serveur pour que les données soient organisées. Une fois cette opération passée, un deuxième serveur, par exemple d'un autre prestataire autorisé, peut consulter ces fichiers. Il en extrait les données, les traite et peut ainsi informer le client sur sa consommation. Mais dans une telle organisation, le deuxième serveur doit attendre au moins 24 heures pour pouvoir accéder aux données de sorte que les informations fournies au client ont toujours au moins 24 heures de retard. Or de nombreux clients souhaitent mieux maîtriser la quantité de courant qu'ils consomment. Et la réception des informations avec un tel retard ne leur permet pas d'effectuer un contrôle étroit à ce sujet. En particulier, si ces informations révèlent qu'une quantité de courant très élevée a été consommée sur la période correspondante, il s'avère souvent difficile d'en retrouver les causes exactes.

Un but de l'invention est de permettre à l'occupant d'une installation de mieux contrôler sa consommation de la ressource. A cet effet, on prévoit selon l'invention un procédé de traitement de données de consommation d'une ressource dans lequel : - un premier serveur commande un enregistrement sous forme linéarisée de données de consommation d'une ressource ; et - un deuxième serveur commande une obtention des données à partir du premier serveur et leur délinéarisation. Ainsi, le deuxième serveur peut aller chercher aussi fréquemment qu'on le souhaite les données les plus récentes sur le premier serveur pour les délinéariser lui-même. Il est donc beaucoup moins dépendant du premier. Les données délinéarisées par le deuxième serveur peuvent alors être exploitées sans délai pour fournir des informations récentes au client. Le prestataire associé à ce serveur peut donc informer l'occupant de sa consommation avec un retard particulièrement réduit, par exemple de quelques heures seulement. Dès lors, si l'occupant constate une élévation de sa consommation, il peut sans difficulté identifier quelles en sont les causes, voire agir sur ces causes si elles -2- persistent afin de réduire la consommation en cours. Effectuant ce contrôle avec un retard réduit, l'occupant peut donc mieux maîtriser sa consommation de la ressource. Le procédé selon l'invention pourra présenter en outre au moins l'une quelconque des caractéristiques suivantes : - la ressource est une ressource énergétique telle que du courant électrique ; - le deuxième serveur commande une obtention d'une liste de clients, comprenant par exemple pour le ou chaque client une adresse d'un fichier associé au client et comprenant les données ; - on commande une exécution des étapes d'obtention et de délinéarisation périodiquement, par exemple avec une période inférieure à 12 heures et de préférence inférieure à 1 heure ; - le deuxième serveur commande une transmission de certaines au moins des données délinéarisées à une base de données distincte du deuxième serveur ; et - on commande une transmission d'au moins une partie des données et/ou d'un résultat d'un traitement des données à destination d'une personne concernée par la consommation, et ce par exemple périodiquement et notamment avec une période inférieure à 12 heures et de préférence inférieure à 6 heures. De préférence, on commande un affichage des données et/ou du résultat dans un widget.

Ainsi, le widget est facilement accessible à l'occupant sur l'écran d'un ordinateur ou d'un appareil numérique de poche tel qu'un téléphone ou un assistant personnel. Cet accès peut se faire depuis l'installation ou à distance de celle-ci grâce à un réseau de télécommunication tel qu'Internet. Le widget est apte à afficher des données reçues à tout instant par le réseau de télécommunication. Le fournisseur de la ressource peut donc informer l'occupant de sa consommation avec un retard particulièrement réduit. De préférence, on commande une diffusion des données et/ou du résultat de sorte que la diffusion a lieu au moyen d'un objet sans écran apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore. Ainsi, ici encore, le fournisseur de la ressource peut informer l'occupant de sa consommation avec un retard particulièrement réduit. De préférence, on commande une transmission des données et/ou du résultat à un appareil de poche, via un réseau de télécommunication, et un affichage des données sur l'appareil. Ainsi, l'appareil de poche tel qu'un téléphone ou un assistant personnel est facilement accessible depuis l'installation ou à distance de celle-ci grâce à un réseau de télécommunication tel qu'Internet. Il est apte à afficher des données reçues à tout instant -3- par le réseau de télécommunication. Le fournisseur de la ressource peut donc informer l'occupant de sa consommation avec un retard particulièrement réduit. On prévoit également selon l'invention un procédé de traitement de données de consommation d'une ressource dans lequel un serveur commande une obtention à partir d'un autre serveur de données de consommation d'une ressource sous forme linéarisée, et leur délinéarisation. On prévoit également selon l'invention un serveur qui comprend des moyens pour commander une obtention à partir d'un autre serveur de données de consommation d'une ressource sous forme linéarisée, et leur délinéarisation.

On prévoit en outre selon l'invention un système comprenant un serveur selon l'invention et de préférence au moins l'un des éléments suivants : -l'autre serveur; et - une base de données apte à enregistrer certaines au moins des données délinéarisées.

On prévoit enfin selon l'invention un programme comprenant des instructions pour commander une exécution d'un procédé selon l'invention, un support d'enregistrement comprenant un tel programme et une mise à disposition d'un tel programme en vue de son téléchargement.

D'autres caractéristiques et avantages de l'invention apparaîtront encore dans la description suivante d'un mode préféré de réalisation donné à titre d'exemple non limitatif en référence aux dessins annexés sur lesquels : - la figure 1 est un schéma d'ensemble d'un système selon l'invention ; - la figure 2 est un organigramme illustrant différentes étapes de collecte de données de consommation dans le procédé mis en oeuvre par le système de la figure 1 ; - la figure 3 est un organigramme illustrant différentes étapes de traitement des données, mises en oeuvre par le procédé selon l'invention dans le système de la figure 1 ; - la figure 4 illustre un écran sur lequel les données traitées sont présentées ; et - les figures 5 à 8 sont des vues analogues à la figure 3 illustrant d'autres séries d'étapes pour le traitement des données dans le procédé selon l'invention.

On a illustré à la figure 1 un mode de réalisation du système selon l'invention. Ce système permet le traitement de données relatives à la consommation d'une ressource au sein d'une installation 4. Cette ressource est ici consommée par l'installation 4 directement à partir d'un réseau de distribution 5. Ce réseau est typiquement un réseau -4- régional ou national alimentant plusieurs milliers d'installations telles que l'installation 4, voire bien davantage. La ressource est en l'espèce une ressource énergétique. Mais il pourrait s'agir d'une ressource d'une autre nature telle qu'un fluide comme de l'eau. Le réseau serait ainsi un réseau d'alimentation en eau courante. Il pourrait aussi s'agir d'un réseau de télécommunication, la ressource étant par exemple un temps de connexion ou de communication ou encore une quantité de données transitant sur le réseau en provenance de l'installation 4 ou à destination de celle-ci. Cette installation est en l'espèce une habitation. Mais il pourrait s'agir alternativement de locaux professionnels tels que des bureaux ou une usine. A l'installation 4 est associé un identifiant d'abonné ou de client du réseau 5. Dans le présent exemple, le courant électrique constituant la ressource est consommé par l'installation 4 directement à partir du réseau 5. Cette ressource est consommée par les différents appareillages présents au sein de l'installation 4, par exemple des appareils électroménagers (lave-linge, lave-vaisselle, télévision, ordinateur, appareils de chauffage, réfrigérateur, etc.). Comme on va le voir, ce système permet à l'occupant de l'installation 4 de connaître le détail de sa consommation électrique peu de temps après que cette consommation a eu lieu.

Collecte des données

Le système comprend un capteur électrique 6 qui constitue un premier module du système. Ce capteur se trouve dans l'installation 4 et est raccordé sur un port de téléinformation du compteur d'électricité électronique 8 du client. Ce premier module 6, connu en lui-même, est apte à relever périodiquement la valeur d'un index de consommation sur le compteur 8. Cet index est directement dépendant de la quantité de courant électrique consommée. Le système comprend un deuxième module formé par un transmetteur 10. Ce transmetteur est apte à communiquer par une liaison sans fil avec le premier module 6 pour obtenir les valeurs d'index relevées par ce dernier. Le transmetteur 10 est raccordé, par exemple au moyen d'une liaison filaire, à une passerelle résidentielle 12 de l'installation 4. Cette passerelle est en communication avec un réseau de télécommunication qui est en l'espèce le réseau Internet 14. Cette passerelle est ici une passerelle ADSL. En l'absence d'une liaison à haut débit vers Internet, le procédé selon l'invention peut être mis en oeuvre au moyen d'une ligne téléphonique classique. Le -5- deuxième module 10 peut ainsi transmettre au réseau 14 les valeurs d'index obtenues par le premier module 6 sur le compteur 8. Le système comprend également un troisième module 16 constitué par un afficheur. Cet afficheur est formé par un boîtier muni d'un écran et apte lui aussi à communiquer avec le transmetteur 10, par exemple au moyen d'une liaison sans fil. L'afficheur 16 peut être manipulé et porté dans l'installation 4 par un occupant de celle-ci. Il permet à ce dernier de prendre connaissance de données relatives à la consommation de l'installation sur le réseau électrique. Les premier, deuxième et troisième modules sont tous trois présents au sein de l'installation 4. Ils comprennent chacun des moyens électroniques classiques leur permettant d'avoir le fonctionnement indiqué ici et notamment une unité centrale, des moyens de communication avec les autres éléments du système, le cas échéant des moyens d'affichage, etc. Nous allons maintenant présenter avec leurs fonctions les composants du système qui se trouvent hors de l'installation 4 et typiquement à grande distance de celle-ci. Si leur communication avec l'installation 4 est rendue nécessaire, cette communication se fait dans le présent exemple par l'intermédiaire du réseau de télécommunication 14. Dans le présent exemple, le premier module 6 lit une valeur instantanée de l'index sur le compteur électronique et l'envoie au deuxième module 10 toutes les dix minutes.

Cette période pourrait plus généralement être comprise entre une minute et deux heures. Le deuxième module 10 stocke les index ainsi collectés et les regroupe dans un fichier plat. Les index y sont ainsi sous forme linéarisée et donc inorganisée. Le module 10 envoie périodiquement le fichier ainsi constitué à un dispositif 18 qui est en l'espèce un ordinateur tel qu'un serveur. Nous désignerons ce serveur par le terme serveur frontal dans la présente description. Ce serveur est apte à communiquer avec l'installation 4 au moyen du réseau 14. Le rôle de ce serveur est en l'espèce de collecter les index qu'il reçoit du deuxième module 10. Dans le présent exemple, la transmission par le module 10 au serveur frontal 18 se fait toutes les trois heures mais on pourrait prévoir qu'elle se fait avec une période inférieure à une heure, et par exemple de l'ordre de quelques minutes, ou bien avec une période plus longue, par exemple de dix ou quinze heures. Il est toutefois avantageux que cette période soit aussi courte que possible. Le serveur frontal reçoit de la sorte les fichiers de nombreuses installations 4, par exemple de plusieurs milliers de ces installations. Le serveur frontal 18 enregistre ces données nouvellement obtenues avec celles dont il dispose déjà en raison des réceptions précédentes dans un fichier 38 illustré à la figure 2. Il ne conserve en l'espèce que les données relatives aux 15 derniers jours -6- glissants mais on pourrait choisir une durée différente (par exemple entre un jour et un mois). Le système comprend en outre un dispositif de traitement qui est en l'espèce un ordinateur tel qu'un serveur 20 lui aussi relié aux autres éléments du système via le réseau 14. Ce serveur a pour fonction d'obtenir du serveur frontal 18 les index collectés par ce dernier et de les traiter. Le système comprend également une base de données 22 qui enregistre les index préalablement traités par le serveur 20 puis envoyés ainsi traités par ce dernier à la base via le réseau 14.

Nous allons maintenant à ce stade, en référence à la figure 2, illustrer en détail le déroulement de ces différentes étapes. Les étapes qui vont être présentées sont mises en oeuvre par le serveur de traitement 20. Dans une première étape 24, le serveur 20 se connecte à la base de données 22. Si la connexion s'avère impossible à établir, le serveur abandonne l'exécution de cette étape et émet une alarme selon des procédures prédéterminées relatives à une situation d'erreur dans le système. Si la connexion a pu avoir lieu, il passe à l'étape 26. Au cours de celle-ci, le serveur 20 obtient de la base de données 22 une liste 28 des clients 4 ayant souscrit à l'un des services associés au procédé. Cette liste a été illustrée en partie à la figure 2 et comprend différentes lignes associées aux clients respectifs, une par client. Dans une première colonne 30, la liste comprend une adresse URL d'un fichier de stockage 38 à récupérer, l'adresse débutant par les termes http://... . Dans une deuxième colonne 32, la liste comprend le dernier timbre horaire d'index stocké. On rappelle qu'un timbre horaire ou "timestamp" est un marqueur de temps informatique correspondant au nombre de secondes écoulées depuis le 1 er janvier 1970, s'agissant en l'espèce d'un timestamp Unix. Par exemple, la valeur 1197116587 correspond à la date du 08/12/2007 à 12 heures 23 minutes 07 secondes. Dans une troisième colonne 34 intitulée "idb", la liste comprend l'identifiant des éléments domestiques du système, c'est-à-dire en l'espèce des modules 6, 10 et 16 de l'installation 4. Cet identifiant est constitué par une suite de caractères alphanumériques. Les étapes suivantes qui vont être présentées en référence à la figure 2 concernent à chaque fois un client particulier. Ces étapes sont exécutées pour ce client, puis le procédé recommence pour le client suivant de la liste 28. Au cours d'une étape 36, le serveur de traitement 20 consulte sur le serveur frontal 18 le fichier 38 de stockage des index du client associé à l'installation 4. Ce fichier est stocké en mode lecture seule sur le serveur frontal 18 au format http. Le serveur de -7- traitement 20 atteint ce fichier grâce à l'adresse figurant dans la colonne 30. Si la connexion au serveur frontal s'avère impossible ou si le fichier est introuvable, le serveur 20 abandonne l'exécution de cette étape pour ce client et émet une alarme conformément aux procédures d'erreur.

Dans une étape suivante 40, le serveur de traitement 20 procède à l'extraction complète du contenu 42 de ce fichier. Si le fichier s'avère illisible, le serveur de traitement abandonne l'exécution de cette étape et émet une alarme. Au cours de l'étape suivante 44, le serveur 20 procède à la délinéarisation des données formant ce contenu. Il exécute à cette fin une fonction "unserialize" sur ce contenu. Il s'agit d'une fonction standard en langage PHP. Ainsi, tandis que le fichier plat 38 avait un contenu inorganisé, l'étape 44 permet au serveur de traitement 20 de procéder à une organisation des données qu'il contient. Ces données sont ainsi devenues accessibles et lisibles par le serveur de traitement. Ces données couvrent les 15 derniers jours glissants. Le serveur sélectionne donc les données dont il ne disposait pas encore pour mettre à jour et compléter un tableau 46 relatif aux index. Le tableau 46 est lui aussi tout entier associé au client en question. Chaque ligne correspond à une valeur d'index. Dans une première colonne 48, est indiqué le timbre horaire et dans une deuxième colonne 50 est indiquée la valeur de l'index correspondant à ce timbre horaire. La plupart des données du tableau y étaient déjà présentes en raison des itération précédentes du procédé. L'itération dont il est question ici permet de compléter le tableau avec les données des trois dernières heures voire avec d'autres données qui viendraient à manquer. Si l'opération d'organisation échoue, le serveur abandonne l'exécution de cette étape pour ce client et émet une alarme. Dans une étape suivante 52, le serveur de traitement 20 se connecte à la base de données 22 et accède à la table des index associée au client en question. Le serveur 20 procède à l'insertion dans cette table des couples timbre horaire et index qui viennent d'être organisés et pour lesquels le timbre horaire est supérieur à celui indiqué dans la colonne 32 en référence à l'étape 26. Ainsi, il n'insère par les couples qui sont déjà présents dans la base 22. Si cette étape d'insertion échoue, elle est abandonnée et le serveur de traitement signale une erreur. Dans une étape suivante 54, le serveur de traitement 20 passe au client suivant de la liste 28 et reprend à partir de l'étape 36 la même succession d'étapes pour ce client suivant. La base de données 22 peut être une base de données d'un type quelconque et peut être gérée au moyen d'un programme quelconque. En l'espèce, la base est gérée au moyen du programme connu sous le nom "MySQL". -8- En ce qui concerne les étapes 24 à 54 illustrées à la figure 2, elles sont exécutées pour l'ensemble des clients de la liste 28 toutes les trente minutes dans le présent exemple. Ici encore, cette période pourrait varier entre quelques minutes et plusieurs heures, par exemple une à cinq heures. Mais il est à nouveau avantageux que cette période soit aussi courte que possible. On rappelle que, dans cet exemple, les index sont relevés toutes les 10 minutes par le module 6 puis une fois regroupés transmis toutes les 3 heures par le module 10 au serveur frontal 20. Le serveur de traitement 20 consulte les fichiers 38 toutes les trente minutes et exécute avec la même période les étapes de la figure 2. Les données sont donc mises à jour dans la base 22 avec un retard de seulement trois heures trente environ. Nous allons exposer dans la suite comment ces données sont transmises et présentées au client. La suite du traitement étant très rapide, il s'ensuit que les données sont présentées au client avec un retard de trois heures quarante au maximum. En d'autres termes, le client a connaissance de ses données de consommation trois heures quarante seulement après la consommation concernée.

Nous allons maintenant exposer comment les données sont traitées et transmises au client pour son information. Dans le présent exemple, plusieurs modes de traitement et de présentation sont prévus et se cumulent afin de permettre au client de prendre connaissance de différentes façons de ses données de consommation. Affichaqe sur un widqet

Nous allons tout d'abord exposer comment les données sont traitées puis présentées en vue d'apparaître dans un "widget". On sait qu'un widget est un outil 25 informatique et graphique qui permet d'obtenir des informations. Comme illustré à la figure 4, c'est un objet interactif 110 comprenant un composant graphique apparaissant sur un écran 112 d'un ordinateur ou d'un autre appareil numérique, par exemple sous la forme d'une page web de petit format par rapport à l'écran et ne remplissant donc pas l'intégralité de ce dernier. De nombreux environnements et systèmes d'exploitation 30 permettent le développement et la présentation de widgets. C'est le cas par exemple de celui connu sous l'appellation Netvibes. Le procédé selon l'invention permet au client de visualiser dans un widget sous la forme graphique, par exemple sous forme de diagrammes ou de courbes, certaines de ses données de consommation ou des résultats d'un traitement de ces données. En l'espèce, trois courbes sont présentées : 35 - la courbe des dernières 24 heures réalisée à partir des dernières données d'index collectées ;20 -9- - la courbe des sept derniers jours jusqu'à la veille de la date de consultation à minuit et enfin - la courbe des trente derniers jours également jusqu'à la veille de la consultation à minuit. Ces courbes sont présentées sous la forme de diagrammes à barres dans le présent exemple. Le client de l'installation 4 accède à ce service par exemple au moyen d'un ordinateur 64 qui peut être connecté au réseau 14. Cela peut avoir lieu depuis l'installation 4 via la passerelle 12. On présente à la figure 3 les différentes étapes permettant l'affichage de la courbe correspondant à la consommation de courant électrique sur le réseau de distribution pour l'installation 4. Ces étapes sont mises en oeuvre par un dispositif 60 qui est en l'espèce un ordinateur tel qu'un serveur. Lui aussi est connecté au réseau 14. Nous désignerons ici ce serveur par le terme serveur d'application. Dans une première étape 62, l'ordinateur 64 sur ordre du client se connecte via le réseau 14 au serveur d'application 60, lequel se connecte à la base de données 22 via le réseau 14. Un couple identifiant-mot de passe est envoyé par l'ordinateur au serveur d'application 60, puis à la base de données 22 via le réseau 14. Cet envoi se fait ici de façon transparente pour le client, une inscription préalable à ce service ayant permis de mettre en place cette procédure. Lors d'une étape suivante 64, le serveur 60 vérifie la validité de ce couple identifiant - mot de passe en les comparant à un identifiant et un mot de passe enregistrés au préalable. Si ce couple ne correspond pas à un couple valide ou si la connexion du serveur 60 à la base de données s'avère impossible, le serveur 60 émet, à destination de l'ordinateur 64, un message d'erreur à la place de l'image prévue correspondant au widget.

A l'étape suivante 66, le serveur d'application 60 obtient auprès de la base de données 22 le dernier timbre horaire enregistré pour le client 4. Lors d'une étape suivante 68, il désigne par deuxième date ou "date_2" la date indiquée par ce dernier timbre horaire, et par première date ou "date_1" cette date diminuée de 24 heures. En d'autres termes, le serveur 60 fixe deux dates : la plus récente, la deuxième, correspondant au timbre horaire et la plus ancienne, la première, précédant la deuxième de 24 heures. Ainsi, la première date est par exemple le 09/10/07 à 12 h 15 et la deuxième date est le 10/10/07 à 12 h 15. Dans une étape ultérieure 70, le serveur d'application 60 obtient auprès de la base de données 22 toutes les valeurs d'index de la période comprise entre ces deux dates.

Ces valeurs sont communiquées sous la forme d'un tableau 72 illustré à la figure 3. Chaque colonne correspond à une date, la colonne la plus à gauche étant la date_1 et la -10- colonne la plus à droite la date_2. Les colonnes entre ces deux dates correspondent aux dates intermédiaires. Dans le présent exemple, sachant que le premier module 6 obtient la valeur d'index sur le compteur 8 toutes les dix minutes, les dates successives sont espacées les unes des autres de dix minutes.

En l'espèce, on prend en compte les circonstances de la fourniture du courant. Ici, il s'agit de la notion d'horosaisonnalité de l'index, c'est-à-dire en fonction du contrat souscrit par le client 4, l'heure à laquelle a eu lieu la consommation de la ressource. En effet, dans le présent exemple, le courant électrique n'est pas facturé au même tarif horaire suivant l'heure de sa consommation. On distingue en l'espèce trois types de tarifs en fonction de trois types d'horaires : un tarif de base qui correspond à la première ligne du tableau 72, un tarif heures pleines qui correspond à la deuxième ligne et un tarif heures creuses qui correspond à la troisième ligne. Chaque index appartient à un et un seul de ces trois tarifs. Sur le tableau 72, on voit ainsi que l'index de la première date a une valeur de 10 et correspond à des heures pleines. En l'espèce, le client a eu le choix de souscrire un contrat dans lequel la facturation se fait ou bien de façon uniforme avec le tarif de base, ou bien d'une façon qui tient compte des heures creuses et pleines. C'est ce dernier cas qui est retenu dans la suite de sorte que les valeurs d'index pour le tarif de base sont toujours à 0. Dans une étape ultérieure 74, le serveur d'application 60 obtient auprès de la base de données 22 une valeur maximale de chaque index avant la première date. En l'espèce, il obtient une valeur maximale pour chacune des horosaisonnalités, c'est-à-dire chacun des tarifs possibles (ici au nombre de trois). Il opère une sélection de ces valeurs maximales 80 dans un tableau 76 de la base 22. Si aucune valeur maximale ne peut être déterminée, par exemple si tous les index sont à 0, la valeur maximale est alors mise à 0.

Au cours d'une étape ultérieure 82, le serveur 60 procède au découpage en plusieurs tranches horaires successives de la période définie par les deux dates. En l'espèce, ces tranches correspondent chacune à une heure. Il regroupe ainsi les index qui se trouvent au sein d'une même tranche horaire. Ce traitement conduit à la réalisation du tableau 89. On distingue ainsi dans une première colonne 84 le numéro des tranches ainsi découpées, dans une deuxième colonne 86 les timbres horaires correspondant à la tranche, puis dans les colonnes suivantes les tarifs respectifs avec les valeurs d'index pour chaque timbre horaire. On observe que chaque tranche de la colonne 84 recouvre plusieurs timbres horaires, c'est-à- dire plusieurs lignes des autres colonnes. En l'espèce, ces lignes sont logiquement au nombre de six pour chaque tranche, les index étant relevés toutes les dix minutes. La première tranche concerne ainsi les relevés d'index ayant eu lieu le 9 octobre 2007 de 12 h 15 à 13 h 05 inclus. -11-Au cours d'une étape ultérieure 88, le serveur d'application 60 détermine la valeur maximale de l'index dans chaque tranche pour chaque tarif. Sur le tableau 89, ces valeurs ont été entourées. On observe ainsi que, pour la première tranche, la valeur maximale de l'index en heures pleines est de 13 et la valeur maximale de l'index en heures creuses est de 30. Pour le tarif de base, tous les index étant à 0, la valeur maximale est à 0. En effet, si tous les index sont à 0 pour un certain tarif dans une tranche, la valeur maximale correspondante est prise à 0. Lors d'une étape ultérieure 90, le serveur 60 procède à la concaténation du tableau 89 afin de ne retenir pour chaque tranche que les valeurs maximales d'index. Il ajoute au tableau ainsi concaténé les valeurs maximales d'index obtenues précédemment pour la période antérieure à la première date. On obtient ainsi un tableau 92 dans lequel la première ligne correspond aux valeurs maximales des index avant la première date et les lignes suivantes correspondent aux tranches successives. Pour chaque ligne, une valeur d'index est indiquée pour le tarif de base, une valeur pour le tarif heures pleines et une valeur pour le tarif heures creuses. Dans une étape ultérieure 94, le serveur 60 remplace chaque valeur d'index nulle, s'il en existe, par la valeur de la tranche précédente. Ainsi, sur le tableau 92, l'index était à 0 pour la tranche 3 en heures creuses alors qu'il était à une valeur de 33 pour la tranche 2 au même tarif horaire. Il s'ensuit qu'aucune consommation de courant électrique n'a eu lieu pendant la tranche 3 pour ce tarif. L'index reste en fait inchangé et est donc mis à la valeur 33. A l'étape suivante 96, le serveur 60 procède au calcul des valeurs de consommation pour chaque tranche et pour chaque tarif horaire. En l'espèce, la consommation pour chaque tranche n est égale à la valeur de l'index pour cette tranche diminuée de la valeur de l'index pour la tranche précédente n-1. On obtient ainsi un tableau 97 listant les valeurs des consommations de courant en kWh pour les différents tarifs horaires indiqués en colonne et pour chaque tranche indiquée en ligne. A l'étape ultérieure 98, le serveur 60 effectue le calcul de la consommation maximale entre les deux dates définissant la période considérée et ce pour chaque tarif horaire. Le calcul de cette valeur maximale de consommation va permettre d'adapter l'échelle de l'axe des ordonnées de la représentation graphique afin de rendre celle-ci la plus claire possible pour sa consultation par le client. Par exemple, on choisira cette échelle pour interrompre l'axe des ordonnées à cette valeur maximale ou bien juste au-dessus.

Enfin, dans une étape 100, le serveur 60 procède à la génération de l'image en représentant dans un diagramme 102 chaque tranche par une barre verticale. En outre, -12- pour prendre en compte les différents tarifs horaires, chaque barre est au besoin subdivisée en différentes fractions empilées correspondant aux consommations pour les différents tarifs horaires. Sur le diagramme 102, 24 barres ont donc été affichées successivement, l'axe des abscisses présentant le temps divisé en 24 heures et l'axe des ordonnées présentant la valeur de la consommation en courant électrique. La plupart des barres telles que la barre 104 sont représentées avec une seule couleur ou d'une seule façon car elles renvoient à un seul tarif horaire tandis que d'autres barres telles que les barres 106 correspondent à des tranches au cours desquelles le tarif horaire a changé de sorte que leur consommation est fragmentée en deux parties visualisées de façon différente. Le client pourra ainsi visualiser la quantité de courant consommée pour chaque tarif au cours de cette heure. Ce diagramme est affiché dans le widget 110, lui même affiché sur l'écran 112 de l'ordinateur 64.

On a illustré à la figure 5 les étapes mises en oeuvre par le système pour la génération dans le widget d'une courbe correspondant cette fois à la consommation hebdomadaire, c'est-à-dire sur les sept derniers jours jusqu'à la veille minuit par rapport au jour de la consultation. Les étapes mises en oeuvre sont identiques ou similaires à celles de la figure 3. On ne présentera dans la suite que les étapes qui varient. Ainsi, cette fois à l'étape 68, la date_1 est choisie pour être antérieure d'une semaine à la deuxième date, date_2, égale à minuit de la veille. Le tableau 76 est inchangé par rapport à celui de la figure 3. Au cours de l'étape 82, le découpage de la période se fait cette fois par tranches journalières et non plus par tranches horaires. Il aboutit ainsi au tableau 110 analogue au tableau 89. La première tranche couvre l'intervalle de temps compris entre la date du 3/10/07 à 12 h 15 et le 4/10/07 à 12 h 05. La deuxième tranche couvre l'intervalle de temps compris entre le 4/10/07 à 12 h 15 et le 5/10/07 à 12 h 05. Le tableau 92 est similaire à celui de la figure 3. Il en est de même pour le tableau suivant. A l'étape 96, pour le calcul des consommations par tranches, on aboutit à un tableau 98 similaire à celui de la figure 3, chaque tranche étant toutefois ici une tranche journalière. Le diagramme 112 qui est obtenu se présente de la même façon que le diagramme 102. Toutefois, chaque barre représente ici la consommation d'une journée de la semaine considérée. Chaque barre peut se trouver subdivisée en différentes parties successives empilées l'une au-dessus de l'autre, ces différentes parties renvoyant à des consommations obéissant à différents tarifs horaires. -13-On peut prévoir que les courbes de consommation, plutôt qu'être envoyées sur un ordinateur 64, sont envoyées sur un appareil numérique portable de poche tel qu'un téléphone mobile 120 ou un assistant personnel de type PDA. Cet envoi peut se faire via un réseau de téléphonie mobile au moyen d'au moins une antenne 22, ce réseau communiquant avec le réseau 14. L'appareil 120 étant un appareil de poche, le client associé à l'installation 4 peut être informé de sa consommation de courant électrique même s'il se trouve en un lieu éloigné de cette installation. Cette information peut se faire sur requête du client envoyée à partir de ce téléphone ou bien à dates régulières, le serveur 60 transmettant au client sur son appareil 120 de façon spontanée les courbes précitées. Cet envoi pourra se faire par exemple au moyen de la technologie de téléphonie mobile de troisième génération appelée UMTS (Universal Mobile Telecommunications System). On pourra prévoir une communication des données au moyen d'une page web autre qu'un widget.

Diffusion par un objet communicant

Un autre aspect du procédé selon l'invention va être présenté en référence à la figure 6. Cette fois, les informations de consommation sont communiquées au client 4 par l'intermédiaire d'un objet 122. Il s'agit d'un objet communicant d'un type connu en soi. Cet objet a par exemple l'allure d'un personnage ou d'un animal. Il est sans écran. Il comprend des moyens le rendant apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et donc en l'espèce à partir du réseau 14 et par l'intermédiaire de la passerelle 12. Il peut en particulier se connecter directement à cette passerelle au moyen d'une liaison sans fil. Ayant reçu ces informations sous la forme d'un message, il est apte à les diffuser sous forme sonore au moyen d'un haut-parleur. Il peut également adresser à son environnement immédiat des signaux lumineux. Il peut en outre disposer de parties mobiles permettant de simuler des gestes. Un tel objet est par exemple connu sous la désignation de "Nabaztag" en ayant la forme d'un lapin stylisé capable d'agiter les oreilles. Naturellement, le procédé peut être mis en oeuvre au moyen d'objets communicants autres que celui de ce dernier exemple. Dans cet aspect de l'invention, le système prépare un jeu de messages vocaux et l'adresse à l'objet communicant 122. Pour cela le fabricant de ce type d'objet met à disposition une ou plusieurs interfaces de programmation permettant d'en exploiter les fonctionnalités. Ces interfaces sont connues en elles-mêmes et ne seront pas décrites plus en détail. On peut prévoir par exemple deux types de messages. Il peut s'agir d'un -14- message journalier constitué par une annonce vocale par l'objet du récapitulatif de la consommation électrique de la veille, par exemple de minuit à minuit. Il peut également s'agir d'un message hebdomadaire constitué par l'annonce verbale par l'objet 122 du comparatif de consommation électrique de la semaine passée (par exemple les sept jours précédents) avec la consommation électrique de la semaine précédente (de sept à quatorze jours précédents). Pour l'envoi du message journalier, les étapes mises en oeuvre sont illustrées à la figure 6. A l'étape 124, le serveur d'application 60 se connecte à la base de données 22. Si cette connexion est impossible, le serveur émet un message d'erreur à destination des opérateurs du système. Lors de l'étape ultérieure 126, le serveur 60 récupère depuis la base la liste 128 des clients ayant souscrit au service de messagerie journalier par ce type d'objet ainsi que les données les concernant. Ces données sont regroupées dans les différentes colonnes du tableau 128. On trouve ainsi dans la première colonne 130 l'identifiant de l'objet 122, dans la deuxième colonne 132 l'heure souhaitée pour l'annonce vocale, et dans la colonne 134 les jours souhaités pour cette annonce vocale. L'heure et les jours auront été choisis précédemment par le client 4 concerné. On observe ainsi que le client associé à l'objet de la première ligne souhaite une annonce vocale à 10 h tous les jours du lundi au dimanche. Le client associé à l'objet de la deuxième ligne souhaite une annonce vocale à 21 h le samedi et le dimanche seulement. Le client associé à la troisième ligne souhaite une annonce vocale à 7 h du lundi au vendredi seulement. Sachant qu'un même client 4 peut détenir plusieurs objets 122, plusieurs lignes du tableau 128 pourront concerner un même client 4.

Lors d'une étape ultérieure 136, le serveur 60 vérifie une ligne du tableau 128 si le jour et l'heure actuels correspondent au jour et à l'heure configurés pour l'annonce. Dans la négative, ce qui sera le cas le plus fréquent, le serveur 60 passe à la ligne suivante et procède à la même vérification. Une fois que le tableau 128 a été ainsi parcouru intégralement, le serveur repasse à la première ligne du tableau. L'étape ultérieure 138 ne concerne donc que le cas où il a été constaté que la date et l'heure actuelles correspondent à celles configurées pour l'annonce. Au cours de cette étape suivante 138, le serveur 60 détermine les deux dates limites entre lesquelles les index seront récupérés. Il associe ainsi à la date_2 la date du jour courant à minuit et à la première date la date_2 moins 24 heures. La première date précède donc de 24 heures la deuxième. Dans le présent exemple, la date_1 correspond donc au 9 octobre 2007 à minuit et la date_2 au 10 octobre 2007 à minuit. -15-Au cours de l'étape ultérieure 140, le serveur 60 obtient de la base 22 les valeurs d'index maximales de chaque tarif horaire pour l'intervalle de temps entre ces deux dates. Ainsi, on voit sur le tableau 142 que la valeur d'index maximale est à 0 pour le tarif de base, à 38 pour le tarif heures pleines et à 47 pour le tarif heures creuses. Cette obtention des valeurs maximales se fait de la même façon que lors de l'étape 74 de la figure 3. A l'étape ultérieure 144, le serveur 60 obtient de la base de données 22 la valeur maximale des index pour chaque tarif horaire avant la première date. Ici, dans la table 146 consultée à cette fin, le maximum pour le tarif heures pleines est à 14 et le maximum pour le tarif heures creuses à 18, le maximum étant à 0 pour le tarif de base.

Au cours de l'étape ultérieure 148, le serveur 60 procède au calcul d'une valeur de consommation pour chaque tarif. Pour cela, pour chaque tarif, il soustrait à la valeur maximale d'index de la période la valeur maximale d'index avant la période. Ainsi, sur le tableau 150, l'index reste à 0 pour le tarif de base. Le maximum 14 du tableau 146 est ôté du maximum 38 du tableau 142 pour donner une valeur de consommation à 24 kWh pour le tarif heures pleines. De même, on obtient une valeur de consommation à 29 kWh pour le tarif heures creuses. Au cours de l'étape ultérieure 152, le serveur 60 procède à la formation du message sonore à envoyer à l'objet communicant en effectuant notamment la somme des consommations pour les trois tarifs, ce qui correspond ici à 53 kWh. Le message préparé est ici "Hier, vous avez consommé 53 kWh". Au cours d'une étape ultérieure 154, le serveur d'application 60 envoie via le réseau 14 ce message à un serveur 158 gérant la communication avec les objets communicant 122 et dédié à ceux-ci. Ce serveur est en général commandé par le fabricant de ces objets. L'envoi a lieu avec les données d'identification de l'objet 122 du client. Cet envoi prend ici la forme d'une requête de type http. Au cours d'une étape ultérieure 156, et en pratique immédiatement après le serveur 158 adresse, via le réseau 14, une réponse au serveur 60 lui indiquant que cet envoi a été convenablement reçu par le serveur. Si, au contraire, aucun accusé réception n'est reçu par le serveur 60 ou si un message indiquant une réception erronée est reçu, le serveur d'application génère un message d'erreur à destination des opérateurs du système. Le message convenablement reçu par le serveur 158 est ensuite diffusé par ce dernier via le réseau 14 jusqu'à l'installation 4. Arrivant à la passerelle 12, il est envoyé jusqu'à l'objet 122 pour être diffusé sous forme sonore au sein de l'installation 4 à destination de ses occupants. -16- Au cours d'une étape ultérieure 158, le serveur d'application 60 enregistre la date d'envoi de ce message. Enfin, au cours de l'étape 160, le serveur 60 retourne à l'étape 136 et exécute cette dernière en passant à la ligne suivante du tableau 128.

On a illustré à la figure 7 les étapes de la mise en oeuvre du procédé dans le cas où l'annonce effectuée par l'objet communicant 122 correspond à la consommation hebdomadaire. Les étapes sont analogues et seules celles qui diffèrent de celle de la figure 6 seront énoncées. Ainsi, cette fois, au cours de l'étape 162 qui fait suite à l'étape 124, le serveur d'application 60 récupère dans la base de données 22 la liste 123 des clients ayant souscrit au service de message hebdomadaire plutôt que la liste 128 de ceux ayant souscrit au service de message journalier. La table 163 comprend donc, après la première colonne 164 consacrée à l'identifiant de l'objet communicant, une deuxième colonne 166 relative à l'heure prévue pour la diffusion du message et une troisième colonne 168 indiquant le jour souhaité pour la diffusion du message. Ainsi, en ce qui concerne la première ligne, il est prévu que le message soit envoyé à l'objet 122 de l'installation 4 chaque lundi à 10 h. L'étape 136 est inchangée par rapport à celle de la figure 6. Au cours de l'étape 170 qui lui fait suite, le serveur d'application 60 détermine les trois dates entre lesquelles les données seront récupérées, à savoir les première, deuxième et troisième dates. La troisième date est celle du jour courant à minuit. La deuxième date précède la troisième de sept jours et la première date précède la deuxième de sept jours. Ainsi, dans le présent exemple, la date_1 est fixée au 1er octobre 2007 à minuit, la date_2 est fixée au 8 octobre 2007 à minuit et la date_3 est fixée au 15 octobre 2007 à minuit.

Au cours d'une étape ultérieure 172, le serveur 60 obtient les index maximum pour chaque période séparée par deux successives de ces dates et pour chaque tarif horaire. S'il n'y a pas de valeur maximale d'index, celle-ci est mise à 0. Ainsi, on observe, sur le tableau 174, que pour la période comprise entre la première date incluse et la deuxième date incluse, la valeur est à 0 pour l'index maximal du tarif de base, à 22 pour l'index maximal du tarif heures pleines et à 47 pour l'index maximal du tarif heures creuses. Pour la période suivante comprise entre la date_2 (exclue) et la date_3 (incluse), ces valeurs sont respectivement à 0, 38 et 59. Au cours d'une étape ultérieure 176, le serveur d'application 60 détermine la valeur maximale des index avant la première date pour chaque tarif horaire. Comme indiqué sur 35 le tableau 178, ces valeurs sont respectivement à 0, 14 et 18. -17- Au cours d'une étape ultérieure 180, le serveur 60 calcule la consommation pour chaque tarif horaire pour chacune des deux périodes d'une semaine en soustrayant au maximum de la période en question celui de la période précédente. Ainsi, pour la consommation lors de la première période définie par les première et deuxième dates, la consommation au tarif heures pleines s'obtient en ôtant 14 de 22, ce qui donne 8. Au tarif heures creuses, elle s'obtient en ôtant 18 de 47, ce qui donne 29. De même, pour la deuxième période (entre les dates 2 et 3), la consommation au tarif heures pleines s'obtient en ôtant 22 de 38, ce qui donne 16. Au tarif heures creuses, elle s'obtient en ôtant 47 de 59, ce qui donne 12. Pour les deux périodes, la consommation est nulle pour le tarif de base. Au cours d'une étape ultérieure 182, le serveur 60 procède à la formation du message sonore à envoyer à l'objet communicant en comparant les deux valeurs des sommes des consommations. Ce message sera par exemple du type "Cette semaine, vous avez consommé 9 kWh de moins que la semaine précédente". Il ne s'agit que d'un exemple. On pourrait naturellement prévoir un message plus complet ou plus étoffé donnant le détail de chaque consommation pour chaque période. Les quatre étapes suivantes 154, 156, 158 et 160 sont les mêmes que celles de la figure 6.

Envoi d'un messaqe d'alerte

On peut également prévoir que le système est configuré pour l'envoi d'un message d'alerte au client de l'installation 4 lorsque la consommation d'une période prédéterminée dépasse un seuil préalablement choisi par ce client. Il peut s'agir par exemple de la consommation d'une journée. A cette fin, le procédé dont les étapes sont illustrées à la figure 8 est exécuté de façon périodique, par exemple toutes les 20 minutes. En l'espèce, il s'agit d'envoyer un message d'alerte par SMS (Short Message Service). Au cours d'une étape 200, le serveur d'application 60 se connecte à la base de données 22.

Au cours d'une étape 202, il obtient la liste des clients ayant souscrit à ce service d'alerte ainsi que les données les concernant. Il obtient ainsi un tableau 204 présentant dans des colonnes successives 206 l'identité du client, 208 son numéro de téléphone, 210 le seuil de consommation qui, une fois qu'il est franchi, doit servir à déclencher une alerte, et 212 la date d'envoi du dernier message.

Les étapes suivantes sont mises en oeuvre par le serveur 60 pour chaque ligne du tableau 204. On va donc supposer dans la suite qu'on traite la première ligne. -18- Au cours de l'étape 214, le serveur identifie le dernier timbre horaire enregistré pour ce client. Il détermine ensuite à l'étape 216 les deux dates limites entre lesquelles les index devront être obtenus, à savoir les première et deuxième dates. La deuxième date est celle du dernier timbre horaire enregistré et la première date est celle la plus proche de l'heure de minuit du jour correspondant à la deuxième date comme illustré sur le diagramme 217. Au cours d'une étape ultérieure 218, le serveur 60 obtient les valeurs d'index maximales pour chaque tarif horaire de la période 219 délimitée par les dates 1 et 2. Sur le tableau 220, on voit que ces maxima pour les tarifs de base, heures pleines et heures creuses sont respectivement de 0, 38 et 47 kWh. Lors de l'étape suivante 222, le serveur 60 détermine les valeurs maximales des index pour chaque tarif horaire avant la première date. Ces valeurs maximales sont ici identifiées respectivement à 0, 14 et 18 kWh pour les trois tarifs. A l'étape suivante 224, le serveur effectue le calcul de la consommation pour la période considérée pour chaque tarif horaire. Pour cela, il soustrait le maximum précédant la première date du maximum concernant la période. Ainsi, pour le tarif heures pleines, il soustrait 14 de 38, ce qui donne une consommation de 24 kWh. De même, pour le tarif heures creuses, il soustrait 18 de 47 pour obtenir une consommation de 29 kWh. La consommation au tarif de base est ici nulle.

A l'étape suivante 226, le serveur 60 effectue la somme de la consommation pour les trois tarifs qui est ici de 53 kWh, puis procède à la comparaison de ce total avec le seuil fixé. A l'étape suivante 228, si le seuil est dépassé et si la date du dernier envoi est antérieure à la première date, alors le serveur 60 prépare le message à envoyer. Dans le cas contraire, il revient à l'étape 214 et reprend le tableau 204 au client suivant. Si un message a été préparé, le serveur 60, à l'étape 230, envoie le message à un serveur 232 dédié à l'expédition de ce type de message, avec le numéro de téléphone du client. Un tel serveur 232 dédié à la gestion et à l'envoi des messages de type SMS est connu en lui-même et relié au réseau 14. C'est par l'intermédiaire de ce dernier que le serveur 60 lui adresse le message à expédier. Lors d'une étape ultérieure 234, le serveur 232 expédie au serveur d'application 60, via le réseau 14, un accusé de bonne réception du message au serveur. Si cet accusé de bonne réception n'est pas reçu par le serveur 60, ce dernier signale une erreur aux opérateurs du système.

Le serveur 232 procède par ailleurs à l'envoi du message à destination de l'appareil numérique de poche 120 du client 14. Ce message est envoyé au moyen d'une antenne -19- 122 d'un réseau de téléphonie mobile relié au réseau Internet. Comme précédemment, l'appareil 120 est un appareil de poche pouvant être consulté par son possesseur dans un endroit quelconque, et notamment à distance de l'installation 4. A l'étape 236, le serveur d'envoi 60 enregistre dans le tableau 204 de la base de données 22 la date d'envoi du message afin de mettre à jour la ligne correspondante du client. Durant l'étape 238, le serveur 60 retourne à l'étape 214 et aborde la ligne suivante du tableau 204. Cet enchaînement d'étapes est effectué par exemple toutes les 20 minutes par le serveur 60 mais cette période pourrait être choisie à une valeur quelconque entre une minute et deux heures par exemple. Dans le présent exemple, si le seuil est dépassé plus d'une fois dans la journée, le message n'est pas envoyé à chaque exécution des étapes de la figure 8.

Le ou les procédés qui viennent d'être présentés sont mis en oeuvre par les serveurs et/ou les appareils et dispositifs dont il a été question. Ceux-ci, notamment les serveurs, comprennent à cette fin des moyens pour cette mise en oeuvre tels que unité centrale, horloge, mémoire, organes d'envoi et de réception de données sur le réseau 14, etc.. L'exécution du ou des procédés est commandée par les instructions d'un programme enregistré dans ces serveurs, appareils et/ou dispositifs selon les étapes mises en oeuvre. Ces programmes pourront être aussi enregistrés sur un support d'enregistrement classique tel qu'un DVD. On prévoit en outre la mise à disposition de ces programmes sur internet en vue de leur téléchargement, par exemple le téléchargement d'une version de mise à jour, ce téléchargement pouvant être en accès restreint pour être réservé à des personnes autorisées. Ainsi, comme on le voit, les données de consommation, après avoir été collectées et traitées, peuvent être communiquées à la personne physique correspondant à l'installation 4 sous diverses formes, qu'il s'agisse de widgets apparaissant sur l'ordinateur 64 ou sur l'appareil 120, de messages sonores diffusés par l'objet 122 ou de messages d'alerte envoyés à l'appareil 120. Le procédé permet de s'approcher d'assez près d'une véritable situation de synchronisme entre la réalité qui est mesurée (à savoir les index sur le compteur) et les informations effectivement disponibles dans la base de données 22 puis envoyées au client associé à l'installation 4. Naturellement, ce synchronisme n'est qu'approché et n'est pas atteint dans la mesure où on doit tenir compte de : - la fréquence du relevé des index au niveau du compteur électronique 8 du client ; -20- - la fréquence de collecte de ces données par le deuxième module 10 pour leur envoi au serveur frontal 18 ; - la fréquence de récupération des données par le serveur de traitement 20 ; et enfin - la fréquence d'exécution des étapes des figures 3 et 5 à 8 selon les cas.

Toutefois, en cumulant ces différentes fréquences, qui sont dans le présent exemple fixées respectivement à 10 minutes (relevé d'index), 3 heures (fréquence de collecte), 30 minutes (récupération à partir du serveur frontal), on obtient selon le mode de communication au client un retard situé entre 3 heures 40 minutes et 4 heures. La personne responsable de l'installation 4 est donc par exemple informée avec un retard raisonnable et relativement bref que le seuil de consommation a été franchi. Bien entendu, on pourra apporter à l'invention de nombreuses modifications sans sortir du cadre de celle-ci. Certaines au moins des données communiquées et/ou affichées pourraient comprendre des montants de quantité de ressource facturée, par exemple en euros, plutôt que des indications de quantité consommées en unités, par exemple en kWh. Indépendamment des autres caractéristiques du procédé, on pourra prévoir de commander l'affichage des données de consommation d'une ressource de sorte qu'il génère au moins une zone graphique constituée de parties associées à des conditions respectives différentes de fourniture de la ressource, par exemple des conditions tarifaires.

Claims (15)

REVENDICATIONS

1. Procédé de traitement de données de consommation d'une ressource caractérisé en ce que: - un premier serveur (18) commande un enregistrement sous forme linéarisée de données de consommation d'une ressource ; et - un deuxième serveur (20) commande une obtention des données à partir du premier serveur et leur délinéarisation.

2. Procédé selon la revendication précédente dans lequel la ressource est une ressource énergétique telle que du courant électrique.

3. Procédé selon l'une quelconque des revendications précédentes dans lequel le deuxième serveur (20) commande une obtention d'une liste de clients (28), comprenant par exemple pour le ou chaque client une adresse d'un fichier (38) associé au client et comprenant les données.

4. Procédé selon l'une quelconque des revendications précédentes dans lequel on commande une exécution des étapes d'obtention et de délinéarisation périodiquement, par exemple avec une période inférieure à 12 heures et de préférence inférieure à 1 heure.

5. Procédé selon l'une quelconque des revendications précédentes dans lequel le deuxième serveur (20) commande une transmission de certaines au moins des données délinéarisées à une base de données (22) distincte du deuxième serveur.

6. Procédé selon l'une quelconque des revendications précédentes dans lequel on commande une transmission d'au moins une partie des données et/ou d'un résultat d'un traitement des données à destination d'une personne concernée par la consommation, et ce par exemple périodiquement et notamment avec une période inférieure à 12 heures et de préférence inférieure à 6 heures.

7. Procédé selon l'une quelconque des revendications précédentes dans lequel on commande un affichage des données et/ou du résultat dans un widget (110).

8. Procédé selon l'une quelconque des revendications précédentes dans lequel on commande une diffusion des données et/ou du résultat de sorte que la diffusion a lieu au moyen d'un objet (122) sans écran apte, sans l'intermédiaire d'un ordinateur, à recevoir des informations par Internet et à les diffuser sous forme sonore.

9. Procédé selon l'une quelconque des revendications précédentes dans lequel qu'on commande une transmission des données et/ou du résultat à un appareil de poche (120), via un réseau de télécommunication (14), et un affichage des données sur l'appareil.-22-

10. Procédé de traitement de données de consommation d'une ressource caractérisé en ce qu'un serveur (20) commande une obtention à partir d'un autre serveur (18) de données de consommation d'une ressource sous forme linéarisée, et leur délinéarisation.

11. Serveur (20) caractérisé en ce qu'il comprend des moyens pour commander une obtention à partir d'un autre serveur (18) de données de consommation d'une ressource sous forme linéarisée, et leur délinéarisation.

12. Système comprenant un serveur (20) selon la revendication précédente et de préférence au moins l'un des éléments suivants : - l'autre serveur (18) énoncé à la revendication précédente ; et - une base de données (22) apte à enregistrer certaines au moins des données délinéarisées.

13. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 15 10 lorsque le programme est exécuté sur un ordinateur.

14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme selon la revendication précédente.

15. Procédé dans lequel on effectue une étape de mise à disposition d'un programme selon la revendication 13 sur un réseau de télécommunication en vue de son 20 téléchargement.