FR 3024811 A1 20160212 FR 1457689 A 20140807 1 DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine de la domotique. Plus précisément, elle concerne un procédé de contrôle à distance de périphériques domestiques. ETAT DE L'ART A l'heure du tout numérique, de plus en plus d'objets « intelligents » connectables à internet sont disponibles, ces objets allant des consoles de jeu à l'électroménager en passant par les radiateurs, les alarmes ou encore les volets roulants. La domotique, qui est l'ensemble des techniques permettant le contrôle et l'automatisation (c'est-à-dire l'utilisation nécessitant de moins en moins d'intervention humaine) de ces objets au sein d'une habitation, se voit profondément transformée. Jusqu'à présent, la diversité des objets, des marques et des protocoles de communication a fait que le contrôle des différents équipements de la maison posait des problèmes de compatibilité et nécessitait une pluralité de boitiers et autres connecteurs divers, à moins de penser l'installation dès la construction du bâtiment. Le document FR2979508 a proposé un système de gestion d'équipements domestiques (ou « périphériques ») qui permette l'intégration de n'importe quel équipement de façon totalement transparente pour l'utilisateur, et qui offre une grande variété de services aussi bien pour la surveillance des équipements que pour leur automatisation et leur contrôle à distance dans des scénarii complexes. Ce système rend techniquement possibles des scénarii impliquant n'importe quels équipements communicant entre eux via un équipement de gestion adapté tel qu'un boitier d'accès à internet (Integrated Access Device, IAD, communément appelé « box ») d'un foyer ou un smartphone, et apporte entière satisfaction. Toutefois, de tels scénarii sont aujourd'hui 3024811 2 peu nombreux et limités. Il est en effet très facile de surveiller ou de contrôler à distance un ou plusieurs périphériques (par exemple via un smartphone), mais le développement de scénarii originaux et complexes reste hors de portée de l'utilisateur néophyte, et peut aujourd'hui être 5 accompli uniquement par des développeurs informatiques professionnels. Il serait ainsi souhaitable de disposer d'une solution simple, conviviale et autonome permettant à des clients ou des partenaires de créer des scénarii domotiques utilisables sur un IAD et permettant de partager ces mêmes scénarii entre des utilisateurs disposant des mêmes 10 périphériques. PRESENTATION DE L'INVENTION Selon un premier aspect, la présente invention se rapporte donc à un 15 procédé de contrôle à distance d'au moins un périphérique connecté à un boitier d'accès internet, le boitier d'accès internet étant relié au réseau internet via un réseau opérateur, le procédé comprenant la mise en oeuvre d'étapes de : (a) Expression en langage naturel sur une interface utilisateur d'un 20 équipement connecté au réseau internet d'un scénario d'utilisation du périphérique ; (b) Analyse sémantique dudit scénario par un serveur de traitement de scénarii du réseau opérateur de sorte à identifier une partie de condition du scénario et une partie de conséquence du scénario, la 25 partie de conséquence étant définie sous la forme d'un n-uplet de paramètres dont au moins : - un type de périphérique, - une action associée au type de périphérique dans une première base de connaissance accessible par ledit boitier 30 d'accès à internet ; (c) Détermination par le serveur de traitement de scénarii du périphérique désigné dans le scénario à partir d'une seconde base 3024811 3 de connaissances stockée sur ledit boitier d'accès à internet en fonction d'au moins le type de périphérique identifié ; (d) Génération par le serveur de traitement de scénarii d'un fichier d'instructions de contrôle du périphérique en fonction d'au moins 5 l'action identifiée, en vue d'une exécution de sorte à contrôler le périphérique conformément audit scénario d'utilisation dudit périphérique. Selon d'autres caractéristiques avantageuses et non limitatives : 10 - le procédé comprend en outre la mise en oeuvre d'étapes de : (e) Compilation par un serveur de gestion de périphériques également disposé au sein du réseau opérateur dudit fichier d'instructions de contrôle en un fichier binaire ; (f) Instanciation dudit fichier binaire sur le boitier d'accès à Internet en 15 vue d'une exécution de sorte à contrôler le périphérique conformément audit scénario d'utilisation dudit périphérique ; - le procédé comprend une étape (g) d'exécution du fichier binaire par le boitier d'accès à Internet de sorte à contrôler le périphérique conformément audit scénario d'utilisation dudit périphérique ; 20 - la première base de connaissance est contrôlée par le serveur de traitement de scénarii et est commune à tous les boitiers d'accès à Internet du réseau opérateur, alors que la seconde base de connaissance est spécifique du boitier d'accès à Internet d'un foyer ; - la seconde base de connaissance est mise à jour via une interface 25 utilisateur d'un équipement en cas d'identification d'un n-uplet de paramètres incompatible avec la seconde base de connaissances ; - l'étape d'expression du scénario comprend la saisie d'une chaîne de caractère par l'usager et/ou la sélection d'au moins un des paramètres du nuplet dans une liste de possibilités ; 30 - les étapes (a) et (b) sont mises en oeuvre simultanément et dynamiquement, ladite liste de possibilités étant mise à jour à chaque fois qu'un paramètre du n-uplet est sélectionné par l'usager ou identifié par 3024811 4 analyse sémantique, de telle sorte que la liste de possibilités comprenne seulement des possibilités de paramètres associés avec les paramètres déjà identifiés ou sélectionnés dans la première ou la seconde base de connaissance ; 5 - le n-uplet de paramètres de la partie de conséquence comprend en outre au moins un paramètre supplémentaire caractérisant le périphérique, chaque périphérique connecté au boitier d'accès internet étant associé à au moins un paramètre supplémentaire dans la seconde base de connaissances ; 10 - au moins deux périphériques connectés au boitier d'accès internet correspondent dans la seconde base de connaissances au type de périphérique identifié, la détermination du périphérique désigné dans le scénario à l'étape (c) étant également en fonction dudit paramètre supplémentaire identifié ; 15 - au moins deux périphériques connectés au boitier d'accès internet correspondent dans la seconde base de connaissances aux paramètres identifiés, l'étape (c) comprenant en outre la sélection du périphérique parmi lesdits périphériques correspondant aux paramètres identifiés ; - au moins un périphérique est désigné dans la partie de condition du 20 scénario, la partie de condition étant également définie sous la forme d'un n-uplet de paramètres dont au moins : - un type de périphérique - une action associée au type de périphérique dans la première base de connaissance ; 25 l'étape (c) comprenant également la détermination par le serveur de traitement de scénarii dudit périphérique désigné dans la partie de condition du scénario. - le fichier d'instructions de contrôle est en langage de balisage de type XML (eXtensible Markup Language). 30 3024811 5 Selon un deuxième aspect, l'invention concerne un serveur de traitement de scénarii disposé au sein d'un réseau opérateur relié au réseau internet, configuré pour mettre en oeuvre : - Un module de réception d'un scénario d'utilisation d'un périphérique 5 connecté à un boitier d'accès à internet exprimé préalablement en langage naturel sur une interface utilisateur d'un équipement connecté au réseau internet ; - Un module d'analyse sémantique dudit scénario de sorte à identifier une partie de condition du scénario et une partie de conséquence du 10 scénario, la partie de conséquence étant définie sous la forme d'un n-uplet de paramètres dont au moins : o un type de périphérique o une action associée au type de périphérique dans une première base de connaissance accessible par ledit boitier 15 d'accès à internet ; - un module de détermination du périphérique désigné dans le scénario à partir d'une seconde base de connaissances stockée sur ledit boitier d'accès à internet en fonction d'au moins le type de périphérique identifié, 20 - un module de génération d'un fichier d'instructions de contrôle du périphérique en fonction d'au moins l'action identifiée, en vue d'une exécution de sorte à contrôler le périphérique conformément audit scénario d'utilisation dudit périphérique. 25 Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé le premier aspect de contrôle à distance d'au moins un périphérique connecté à un boitier d'accès internet ; et des moyens de stockage lisibles par un équipement informatique sur lesquels 30 un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon le premier aspect de contrôle à distance d'au moins un périphérique connecté à un boitier d'accès internet. 3024811 6 PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention 5 apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma du système selon l'invention ; - la figure 2 représente un exemple de saisie en langage naturel ; 10 - la figure 3 est un schéma illustrant la mise en oeuvre d'un mode de réalisation d'un procédé selon l'invention. DESCRIPTION DETAILLEE 15 Architecture En référence aux dessins et notamment à la figure 1, l'invention concerne un procédé de contrôle à distance d'au moins un périphérique 1. Comme expliqué précédemment, on entend par le terme périphérique tout 20 objet domestique connectable, que ces objets soient complexes, par exemple des téléviseurs ou des appareils photo, ou très simples, en particulier des interrupteurs. Le terme périphérique recouvre également tout capteur d'une grandeur physique que l'on pourrait trouver directement dans le foyer ou intégré dans un objet, par exemple un capteur de température. 25 Chaque périphérique 1 est connecté à un boitier d'accès internet 2 (la « box », appelée comme expliqué un IAD) et chaque boitier d'accès internet 2 est relié au réseau internet 21 via un réseau opérateur 20, souvent appelé « backbone ». Sur la figure 1, les espaces 10a et 10b représentent deux « foyers », chacun ayant respectivement sa box 2a, 2b et 30 ses périphériques 1a.X, 1 b.X. Il est à noter que le terme « boitier d'accès internet » n'est pas limité aux box, et peut par exemple comprendre les téléphones portables 3024811 7 disposant d'une connectivité internet, s'il dispose des connectivités nécessaires (voir plus loin). On notera par ailleurs qu'il n'est pas obligatoire que le boitier d'accès internet 2 soit constitué d'une seule entité physique. En effet, dans le cas 5 d'une box, on peut par exemple séparer le modem (c'est à dire la partie qui permet de convertir un signal numérique en un signal analogique pour l'ADSL, en d'autres termes la première couche OSI) du reste du boitier d'accès internet 2 (c'est à dire les couches OSI autres que la première, la QoS haut niveau, des services (VOIP, LAN...) ou encore de la 10 connectique), les deux entités étant par exemple connectées via un câble ethernet, le Wifi, ou des boitiers CPL. On comprendra ainsi que le terme « boitier d'accès internet » englobe les deux entités, et tout périphérique 1 connecté à l'un ou l'autre sera considéré dans la présente description comme connecté à un boitier 15 d'accès internet 2. Cette connexion entre le boitier d'accès internet 2 et les périphériques 1 peut être réalisée de diverses façons et dépend principalement de la connectivité physique dont dispose chaque périphérique 1. En particulier, un périphérique 1 peut être connecté directement au boitier d'accès internet 2 s'il dispose d'une connectivité 20 présente nativement sur le boitier d'accès internet 2 (par exemple une connexion ethernet, usb, HDMI, ou Wifi). En l'absence de connectivité directe, il est possible d'utiliser une extension matérielle offrant la connectivité physique manquante. Cette extension, communément appelée un « dongle » (ou clé-connecteur en 25 français) se branche sur un des ports du boitier d'accès internet 2 (par exemple un port usb). On peut citer comme exemple de dongle une clé avec un port IrDA (infrarouge): elle offre au boitier d'accès internet 2 une connexion avec tout périphérique 1 qui disposerait d'une telle connectivité via les rayonnements infrarouge, par exemple une télécommande. Un seul 30 dongle est en effet le plus souvent suffisant par type de connectivité. On remarque qu'un dongle offre le plus souvent une connectivité filaire (il consiste alors en un simple adaptateur), mais qu'il peut être comme dans le 3024811 8 cas de la clé IrDA un émetteur/récepteur d'une connectivité sans fil. On peut grâce aux dongles gérer dans un seul environnement des objets de différents fabricants qui ont toutes les chances de disposer de connectivités différentes. 5 Un modem 3G/4G peut être utilisé comme un dongle assez particulier. En effet, un périphérique 1 possédant une connectivité mobile (via un réseau de type 3G, 4G, etc.) est déjà capable de se connecter à internet sans passer par une box 2. Il est à noter que la connectivité mobile via le modem 3G/4G peut être en utilisée en backup de la liaison Wifi. 10 Le modem 3G/4G peut en outre être lui-même utilisé comme un périphérique présentant des fonctionnalités qui pourraient être offertes aux autres périphériques 1 présentant une connectivité mobile dans la maison 10. Une de ces fonctionnalités pourrait être par exemple la possibilité d'envoi de SMS, éventuellement via la box 2. Ainsi, on peut imaginer 15 comme périphérique 1 un dispositif d'alerte que les personnes âgées peuvent porter autour du cou, et en cas d'appui du bouton, outre l'alerte des secours, le système selon l'invention déclencherait l'envoi de SMS à des numéros préenregistrés. 20 Serveurs de gestion de périphériques et de traitement de scenarii Le système comprend comme on le voit sur la figure 1 un serveur de gestion de périphériques 4 disposé dans le réseau opérateur 20. Ce serveur de gestion de périphériques 4 est en particulier un (ou 25 plusieurs) équipements disposant d'espaces de stockage de données et de moyens de traitement. Par « serveur de gestion », on comprendra qu'on peut désigner un ensemble de serveurs de l'opérateur du réseau 20. De façon préférée, le serveur 4 (ou un équipement différent du réseau opérateur 20 mais connecté au serveur 4) stocke une base de 30 données de périphériques 1. Chaque périphérique 1 connecté à un boitier d'accès à internet 2 de l'opérateur du réseau 20 comprend une 3024811 9 représentation 1' (appelée « objet virtuel ») dans cette base de données (voir figure 1), et est référencé par un identifiant unique. Chaque périphérique peut ainsi être associé à un ensemble de données informatiques comprenant : 5 - un identifiant du type du périphérique (i.e. un modèle d'équipement), qui peut être partie de l'identifiant unique ; - au moins un attribut du périphérique 1, chaque attribut identifiant un élément contrôlable du périphérique 1 ; - une adresse, notamment l'adresse MAC, du boitier d'accès internet 2 10 auquel le périphérique 1 est connecté. Une telle structure de représentation des périphériques 1 et ses avantages sont illustrés dans le document FR2979508. D'autres données informatiques pouvant être associées à chaque périphérique 1 y sont 15 proposées. On comprendra toutefois que le présent procédé n'est pas limité à une structure de données et que l'homme du métier pourra utiliser des modèles connus. Le système comprend en outre comme on le voit sur la figure 1 un 20 serveur de traitement de scénarii 5 également disposé dans le réseau opérateur 20. Ce serveur de traitement de scénarii 5 est en particulier un (ou plusieurs) équipements disposant d'espaces de stockage de données et de moyens de traitement. Ce serveur 5 peut être par ailleurs le même équipement que le serveur de gestion de périphériques 4. 25 Saisie d'un scénario Dans une première étape (a) du présent procédé, un utilisateur exprime sur une interface utilisateur d'un équipement 3 connecté au réseau 30 internet 21 un scénario d'utilisation du périphérique 1. Cette étape peut comprendre une authentification de l'utilisateur de sorte à identifier quel est son boitier 2 (et donc quels sont ses périphériques 1). On comprendra que 3024811 10 l'équipement 3 peut être disposé dans le réseau local du boitier 2, ou connecté de façon distante. L'expression peut être faite de nombreuse façons, et consiste en particulier en la saisie d'une chaîne de caractères par l'utilisateur (on 5 comprendra qu'elle peut être faite au clavier, mais également via une reconnaissance vocale, voire une reconnaissance de caractères) et/ou la sélection de paramètres dans une liste de possibilités (dite saisie prédictive, voir plus loin). L'expression du scénario est en langage naturel, prenant la forme d'une phrase éventuellement complexe, et plus ou moins 10 grammaticalement exacte. Par exemple : « Je veux allumer la climatisation de mon salon quand quelqu'un est présent dans mon salon pendant 10 minutes » ou encore « ALLUMER CLIM DU SALON SI EST OCCUPE +10 MIN » Ces deux phrases définissent le même scénario impliquant au moins 15 deux périphériques 1 : - un climatiseur, - un détecteur de présence. Une pièce est évoquée : le salon. Le scénario peut se résumer sous la forme d'une requête conditionnelle : si une présence est détectée par un 20 détecteur de présence (associé au salon) pendant une durée consécutive de 10 minutes, alors une requête d'allumage doit être envoyée au climatiseur. Analyse du scénario 25 Le présent procédé vise à permettre de créer le plus facilement possible tout scénario domotique constitué de briques logiques de la forme « si [événement/état(s)] alors [action(s)] ». En référence à la figure 2, la première partie (« si... ») est une partie 30 de condition P1. Elle peut être très simple (« S'il est 18h »), ou être plus complexe et elle-même impliquer un ou plusieurs périphériques 1. Plusieurs 3024811 11 combinaisons sont possibles et on peut même utiliser des opérateurs logiques comme ET et OU. La deuxième partie (« alors... ») est une partie de conséquence P2. Elle correspond à l'action souhaitée sur le périphérique 1 si la condition est 5 vérifiée. Chaque partie peut être un n-uplet de dimension quelconque. L'identification des deux parties P1, P2 est obtenue par analyse sémantique (mise en oeuvre par le serveur de traitement de scénarii 5), en repérant des mots caractéristiques (par exemple « si », « quand », « lorsque » pour la partie de condition P1, « alors », « je veux », etc. pour la 10 partie de conséquence P2). A l'intérieur de la partie de conséquence (et le cas échéant à l'intérieur de la partie de condition si elle implique un périphérique), un nuplet de paramètres définissant la partie est identifié. Il contient au moins : - un type de périphérique, 15 - une action associée au type de périphérique dans une première base de connaissance accessible par (éventuellement en étant stockée sur) ledit boitier d'accès à internet 2, avec lequel le serveur 5 interagit. Par « type de périphérique », on entend comme déjà expliqué la 20 dénomination d'une classe de périphérique, comme « lampe » dans l'exemple représenté. L'action est quant à elle typiquement un verbe, et désigne tout type d'acte que le périphérique 1 pourrait réaliser. Dans notre exemple, l'action est « allumer ». La première base de connaissances est une ontologie générale 25 partagée entre tous les foyers qui définit ce qui est possible et ce qui ne l'est pas. Elle représente une base de connaissance globale indépendamment du foyer - et théorique. Elle peut contenir une partie fixe de connaissance « une lampe peut s'allumer », « un smartphone a un seul propriétaire » ou « des volets roulants ne peuvent pas être contrôlés à 30 distance » et une partie variable « un ordinateur peut avoir de 0 à 25 ports USB » de façon générale on comprend qu'elle associe au moins à chaque 3024811 12 type de périphérique au moins une action réalisable, et si possible leur liste exhaustive. Avantageusement, cette base de connaissance est une ontologie intelligente (qui ne traite pas forcément que des objets mais des concepts, 5 par exemple « les objets qui peuvent s'allumer peuvent clignoter et donc faire des notifications ») et non pas une simple liste, car elle ne se contente pas de lister et de figer les possibilités mais de laisser une marge de manoeuvre pour pouvoir jouer avec cette base ; les relations non précisées ne sont pas considérées comme impossibles mais au contraire comme 10 potentiellement possibles (ce n'est pas parce qu'une porte ne peut théoriquement pas s'allumer que cela est impossible). Cette ontologie est soit livrée par défaut dans le boitier d'accès à internet 2, soit constituée via le réseau opérateur 20, soit hébergée sur un serveur (en particulier le serveur 5). Dans tous les cas elle est gérée à distance par l'un des serveurs 15 4 et 5 et mise à jour en fonction des nouveaux périphériques 1 ou fonctionnalités offertes. Il est à noter que le système peut ainsi apprendre que certains objets ont certaines fonctionnalités. Par exemple, toutes les caméras de sécurité ne peuvent pas faire de lumière, mais si un utilisateur entre « allumer 20 lumière caméra », vu que cela n'est pas indiqué comme impossible dans l'ontologie globale, il va être notifié au serveur 4 que cette caméra est capable de s'allumer et le système va apprendre cette possibilité (après avoir testé qu'il peut bien la contrôler). Cette caméra devenant alors un objet allumable, elle devient du même coup un objet capable de faire des 25 notifications d'après l'ontologie générale à la prochaine mise à jour. Une seconde base de connaissances est stockée sur ledit boitier d'accès à internet 2, cette dernière est une autre ontologie, qui est cette fois spécifique du boitier d'accès à Internet 2 du foyer. 30 Elle est complétée au fil du temps par l'utilisateur via l'interface. Elle est intrinsèque au foyer où le système est installé. De façon préférée, elle est initiée via la saisie préalable d'une description du foyer « j'ai 4 pièces 3024811 13 dans la maison, la pièce 3 s'appelle la cuisine et il y a 2 lampes dedans, etc.». Ainsi et grâce à l'intelligence des deux ontologies, le boitier 2 va comprendre qu'il est par exemple possible d'allumer une lampe dans la 5 cuisine. Afin d'utiliser ces informations, le n-uplet de paramètres de la partie de conséquence P2 peut comprendre en outre au moins un paramètre supplémentaire caractérisant le périphérique 1. Par paramètre supplémentaire, on entend toute information 10 additionnelle permettant de distinguer un périphérique d'un autre. Ce peut être un paramètre de localisation, par exemple « du salon » dans l'exemple de la figure 2, mais également tout attribut tel qu'une couleur, une taille, une disposition du périphérique, etc. Chaque périphérique 1 connecté au boitier d'accès internet 2 peut 15 être ainsi associé à au moins un paramètre supplémentaire dans la seconde base de connaissances. Il est à noter qu'un périphérique 1 peut n'être associé à aucun paramètre supplémentaire. Par exemple, si l'utilisateur possède une seule télévision chez lui, il n'a pas besoin d'en préciser la taille, la localisation ou autre pour l'identifier. 20 Grâce à la seconde base de connaissance, les moyens de traitement de données dudit serveur de traitement de scénarii 5 déterminent le périphérique 1 désigné dans le scénario en fonction des paramètres (autre que l'action) identifiés. 25 Le type de périphérique identifié peut suffire : si j'ai une seule télévision, il n'y aura pas d'ambiguïté, et saisir « allumer la télévision » suffira. Dès lors qu'il y a deux périphériques du même type (deux lampes) dans la seconde base de connaissance, une ambiguïté doit être résolue. La 30 détermination du périphérique 1 désigné dans le scénario à l'étape (c) peut alors également utiliser ledit paramètre supplémentaire identifié. Ainsi, le fait 3024811 14 de rajouter « du salon » permet de distinguer la lampe de l'exemple de celle « de la cuisine ». Toutefois, même en utilisant plusieurs paramètres supplémentaires, une ambigüité peut subsister : l'utilisateur peut avoir deux grandes lampes 5 dans le salon. De façon préférée, l'étape (c) comprend alors la sélection du périphérique 1 parmi lesdits périphériques correspondant aux paramètres identifiés. En d'autres termes, l'interface 3 propose une liste des périphériques (désignés par un identifiant absolu, par exemple leur nom/adresse IP/adresse MAC) entre lesquels l'ambigüité subsiste, et va le 10 cas échéant modifier la deuxième base de connaissances pour éviter que l'ambigüité ne se reproduise. Il s'agit d'un exemple de mise en oeuvre d'un mode bidirectionnel pour lequel on verra d'autres avantages plus loin. La saisie prédictive évoquée avant désigne un mode de réalisation 15 dynamique dans lequel les étapes (a) et (b) sont mises en oeuvre simultanément et dynamiquement, via une échange en temps réel entre l'équipement 3 et le serveur 5. Plus précisément, l'interface met à jour et propose ladite liste de possibilités à chaque fois qu'un paramètre du n-uplet est sélectionné par l'usager ou identifié par analyse sémantique, de telle 20 sorte que la liste de possibilités comprenne seulement des possibilités de paramètres associés avec les paramètres déjà identifiés ou sélectionnés dans la première ou la seconde base de connaissance Ainsi, au moment où l'utilisateur va indiquer le mot « allumer », le système va aller chercher en arrière-plan dans la première base de 25 connaissance tous les objets qu'il est possible d'allumer dans toute la maison, que ce soit une lampe, une télévision ou un climatiseur et va les proposer à l'utilisateur sous forme d'une liste de types de périphériques. Ensuite, si le choix de l'utilisateur se porte sur le mot lampe, alors le système va aller chercher, en arrière-plan cette fois-ci, les pièces où se 30 trouvent des lampes et va les proposer à l'utilisateur sous forme d'une liste de paramètres supplémentaires. 3024811 15 Une fois la saisie terminée (en d'autres termes toutes les ambiguïtés ont été résolues), la version textuelle du scénario définit des « données descriptives du scénario » qui vont permettre aux moyens de traitement de données du serveur de traitement de scénarii 5 de générer dans une étape 5 (d) un fichier d'instructions de contrôle du périphérique 1 en fonction d'au moins l'action identifiée (voir plus loin). Il est à noter que la version textuelle du scénario est facilement exportable. Si l'on copie-colle ce texte dans un autre foyer, le serveur 5 vérifiera à son tour la cohérence du scénario en fonction de la propre 10 ontologie de ce foyer et procédera aux ajustements (une « lampe du salon » restera une « lampe du salon » même si elle fonctionne différemment mais il faudra peut-être préciser laquelle s'il y en a plusieurs). Mode bidirectionnel 15 Dans le mode bidirectionnel, le moteur permet de proposer des possibilités à l'utilisateur mais est aussi capable d'apprendre au fur et à mesure des scénarii proposés par l'utilisateur et de mettre à jour la deuxième base de connaissance en conséquence. 20 Par exemple, si après avoir tapé « allumer », l'utilisateur entre « chauffe-eau » alors que celui-ci n'était pas proposé par la frappe prédictive (parce que la deuxième base de connaissances du boitier d'accès à internet 2 ne connait pas le chauffe-eau), cette base va apprendre qu'il y a un chauffe-eau (qui peut s'allumer) : l'interface va proposer à l'utilisateur de 25 l'appairer puis il sera fonctionnel. De même, si toutes les lampes sont dans le salon et que l'utilisateur demande d'allumer une lampe de la cuisine, l'interface demandera s'il y a une nouvelle lampe ou si une lampe a été déplacée. L'appairage des périphériques 1 se faisant via la même interface, l'ajout de la nouvelle 30 lampe se fait dans la continuité du processus. De la même façon, le système étant capable d'agir sur les objets connectés, si plusieurs objets peuvent correspondre, par exemple s'il y a plusieurs lampes dans le salon 3024811 16 et qu'on cherche laquelle (ou lesquelles) doit être allumée, il sera capable de les allumer à tour de rôle pour que l'utilisateur puisse facilement indiquer lesquelles sont concernées par son scénario sans avoir à se souvenir de leurs nom/IP/adresse MAC, etc. 5 Un autre avantage de ce mode bidirectionnel est que les scénarii sont créés par l'utilisateur et vérifiés au fur et à mesure de leur écriture (si quelque chose n'est pas possible, on vérifie auprès de l'utilisateur s'il s'agit d'une erreur ou de quelque chose de nouveau à ajouter dans l'ontologie du foyer). Aussi, si un périphérique 1 disparait et que le scenario en devient 10 inexécutable, alors on notifie l'utilisateur de cette modification pour modifier le scenario. Génération d'un fichier d'instructions de commande 15 Les données descriptives d'un scénario d'utilisation du périphérique 1 sont inexploitables en l'état par une machine, et doivent être traitées. Ce traitement consiste comme expliqué en une génération par des moyens de traitement de données du serveur de traitement de scénarii 5 d'un fichier d'instructions de contrôle du périphérique 1 à partir des données 20 descriptives du scénario d'utilisation dudit périphérique 1 (en particulier le paramètre d'action). Le fichier d'instructions de contrôle est avantageusement en langage du type XML (eXtensible Markup Language), notamment « .hez ». A ce stade, le fichier d'instructions consiste en une simple traduction 25 en un langage structuré des données descriptives du scénario, en particulier grâce à des outils sémantiques, et n'est toujours pas exploitable. Un traitement ultérieur en vue d'une exécution de sorte à contrôler le périphérique 1 conformément audit scénario d'utilisation dudit périphérique 1 est requis. 30 De façon préférée, pour cela le fichier d'instructions de contrôle est transmis au serveur de gestion de périphériques 4 évoqué précédemment, comme représenté par la figure 3. 3024811 17 Alternativement, on comprendra que le serveur de traitement de scénarii 5 et/ou le boitier 2 peut assurer seul la fin du traitement. Traitement par le serveur de gestion 5 Comme expliqué précédemment, le serveur de gestion 4 est un équipement centralisé disposé au sein du réseau opérateur 20, disposant le cas échéant des listes de périphériques des clients. Dans un mode de réalisation préféré, le serveur 4 va recevoir le fichier d'instruction, contenant 10 potentiellement des erreurs, et va générer un fichier proche du langage machine qui va pouvoir être utilisé par un boitier 2 pour le contrôle à distance des périphériques 1. Ce traitement se fait dans une boîte noire aux yeux de l'équipement 3, et de façon sécurisée puisque l'on est à l'intérieur du réseau opérateur 20. Cela permet une standardisation des scénarii, qui 15 peuvent ainsi mettre en jeu n'importe quel type de périphérique 1 dont le serveur 4 aurait connaissance, et ce de façon universelle et transposable. De plus, les traitements mis en oeuvre par le serveur 4 n'entrainent aucune charge sur les équipements 3 ou les boitiers 2, pour le plus grand confort des utilisateurs. 20 Le serveur 4 réalise ainsi dans une étape (e) la compilation (si elle est possible) dudit fichier d'instructions de contrôle en un fichier binaire. Par fichier « binaire », on entend un fichier compilé, directement utilisable par opposition à des fichiers textuel interprétables par un être humain (dont le fichier d'instructions). Il est à noter que le fichier binaire peut être un code 25 exécutable et/ou un « bytecode » (en français, « code octal »), c'est-à-dire un code intermédiaire entre les instructions machine et le code source, il n'est pas directement exécutable. Dans le cas où le fichier d'instructions est en « .hez », le fichier binaire peut être en « .bhez » (binary hez). 30 Avant la compilation, le serveur 4 vérifie la syntaxe dudit fichier d'instructions de contrôle (des algorithmes de vérification de syntaxe vis-à- vis de règles de syntaxe prédéterminées sont bien connus de l'homme du 3024811 18 métier), et la compilation n'est mise en oeuvre que si la syntaxe est valide. Dans le cas contraire, un message d'erreur est renvoyé à l'équipement 3, en demandant à l'utilisateur de corriger le scénario qu'il a saisi. Si la syntaxe est correcte, une étape de « linking » est mise en 5 oeuvre lors de la compilation. En effet, il est nécessaire de mettre en concordance les périphériques connus du serveur 4, et ceux mentionnés par l'utilisateur. Par exemple la « climatisation du salon » peut référer à un certain nombre d'appareils, lesquels ne sont naturellement pas commandés de la même façon. 10 L'étape (e) comprend ainsi avantageusement la désignation par son identifiant de type dans le fichier binaire de chaque périphérique 1 cité dans le fichier d'instructions de contrôle. Par exemple, par recoupement, le serveur 4 identifie que la « climatisation du salon » est l'équipement de type « AA » (cette référence renvoyant à un modèle). 15 L'identification du type des périphériques cités permet de simplifier la compilation en permettant l'utilisation de fichiers binaires de référence stockés sur le serveur 4, et chacun associés à un type de périphérique. Ces fichiers de référence sont des « squelettes » qu'il suffit de compléter et d'agencer pour obtenir le fichier binaire du scénario. Le serveur 4 peut à ce 20 moment vérifier que le linking est valide, en d'autres termes qu'il n'y a pas de conflit ou de paramètre manquant. Instanciation et mise à disposition 25 Le fichier binaire ainsi généré est alors utilisable par le boitier d'accès à internet 2, vers lequel il est « poussé », en d'autres termes directement transféré via le réseau opérateur 20. Alternativement, il peut être envoyé et stocké sur un serveur de partage de scénarii 6 (qui peut être en particulier le même serveur que le 30 serveur 5, voire le serveur 4, ou un serveur du réseau internet 21). Il peut ainsi être proposé à d'autres utilisateurs qui souhaiteraient exactement le même service (et disposeraient des mêmes périphériques 1). 3024811 19 Par exemple, en référence à la figure 1, l'utilisateur qui crée le scénario (via l'équipement 3) peut être celui de la box 2a (s'il s'identifie en tant que tel, ou si par exemple il est dans le réseau local de cette box 2a). Le fichier binaire généré peut être poussé sur la box 2a, mais également mis à disposition 5 sur le serveur de partage 6, et éventuellement récupéré par l'utilisateur d'une autre box, en l'espèce la box 2b. Dans tous les cas, le fichier binaire est instancié dans une étape (f) sur le boitier d'accès à Internet qui l'a téléchargé, en vue d'une exécution de sorte à contrôler le périphérique 1 conformément audit scénario d'utilisation 10 dudit périphérique 1. Par instanciation, on entend installation du fichier binaire (en respectant les contraintes et la topologie du réseau) sur le boitier 2. Le procédé comprend le cas échéant une étape (g) d'exécution du fichier binaire par le boitier d'accès à Internet 2, i.e. sa mise en oeuvre en 15 tâche de fond par un moteur d'exécution dédié implémenté sur le boitier 2, de sorte à contrôler le périphérique 1 conformément audit scénario d'utilisation dudit périphérique 1. Le scénario est alors automatiquement activé si les circonstances de son déclenchement sont réunies (10 minutes de présence dans notre 20 exemple). Il est à noter que quand un utilisateur veut télécharger un scénario depuis le serveur 6, il y a avantageusement une étape de vérification par le boitier 2: - Le boitier 2 analyse les périphériques 1 du foyer (de l'utilisateur 25 téléchargeur), - Le boitier 2 renvoie les informations sur ces périphériques au serveur 6 ; - Celui-ci analyse, au vu des périphériques 1 du foyer, les scénarii envisageables (i.e. les configurations similaires), et ne propose que 30 ces derniers à l'utilisateur. Serveur et système 3024811 20 Selon un deuxième aspect, l'invention concerne le serveur de traitement de scénarii 5 utilisé dans le procédé décrit précédemment. Ce serveur de traitement de scénarii 5 est disposé dans le réseau 5 opérateur 20 et est relié aux boitiers 2. Il comprend des moyens de stockage (pour l'éventuel stockage des bases de connaissance) et des moyens de traitement de données configurés pour mettre en oeuvre : - Un module de réception d'un scénario d'utilisation du périphérique 1 exprimé préalablement en langage naturel sur une interface 10 utilisateur d'un équipement 3 connecté au réseau internet 21 ; - Un module d'analyse sémantique dudit scénario de sorte à identifier une partie de condition P1 du scénario et une partie de conséquence P2 du scénario, la partie de conséquence P2 étant définie sous la forme d'un n-uplet de paramètres dont au moins : 15 o un type de périphérique o une action associée au type de périphérique dans une première base de connaissance accessible par ledit boitier d'accès à internet 2 ; - un module de détermination du périphérique 1 désigné dans le 20 scénario à partir d'une seconde base de connaissances stockée sur ledit boitier d'accès à internet 2 en fonction d'au moins le type de périphérique identifié, - un module de génération d'un fichier d'instructions de contrôle du périphérique 1 en fonction d'au moins l'action identifiée, en vue d'une 25 exécution de sorte à contrôler le périphérique 1 conformément audit scénario d'utilisation dudit périphérique 1. Dans un autre aspect, le serveur de traitement 5 forme avec le serveur de gestion de périphériques 4 un système complet de gestion de 30 périphériques domestiques. REVENDICATIONS1. Procédé de contrôle à distance d'au moins un périphérique (1) connecté à un boitier d'accès internet (2), le boitier d'accès internet (2) étant relié au réseau internet (21) via un réseau opérateur (20), le procédé comprenant la mise en oeuvre d'étapes de : (a) Expression en langage naturel sur une interface utilisateur d'un équipement (3) connecté au réseau internet (21) d'un scénario d'utilisation du périphérique (1); (b) Analyse sémantique dudit scénario par un serveur de traitement de scénarii (5) disposé au sein du réseau opérateur (20) de sorte à identifier une partie de condition (P1) du scénario et une partie de conséquence (P2) du scénario, la partie de conséquence (P2) étant définie sous la forme d'un n-uplet de paramètres dont au moins : - un type de périphérique - une action associée au type de périphérique dans une première base de connaissance accessible par ledit boitier d'accès à internet (2) ; (c) Détermination par le serveur de traitement de scénarii (5) du périphérique (1) désigné dans le scénario à partir d'une seconde base de connaissances stockée sur ledit boitier d'accès à internet (2) en fonction d'au moins le type de périphérique identifié, (d) Génération par le serveur de traitement de scénarii (5) d'un fichier d'instructions de contrôle du périphérique (1) en fonction d'au moins l'action identifiée, en vue d'une exécution de sorte à contrôler le périphérique (1) conformément audit scénario d'utilisation dudit périphérique (1). 2. Procédé selon la revendication 1, comprenant en outre la mise en oeuvre d'étapes de : 3024811 22 (e) Compilation par un serveur de gestion de périphériques (4) également disposé au sein du réseau opérateur (20) dudit fichier d'instructions de contrôle en un fichier binaire ; (f) Instanciation dudit fichier binaire sur le boitier d'accès à Internet (2) 5 en vue d'une exécution de sorte à contrôler le périphérique (1) conformément audit scénario d'utilisation dudit périphérique (1). 3. Procédé selon la revendication 2, comprenant une étape (g) d'exécution du fichier binaire par le boitier d'accès à Internet (2) 10 de sorte à contrôler le périphérique (1) conformément audit scénario d'utilisation dudit périphérique (1). 4. Procédé selon l'une des revendications 1 à 3, dans lequel la première base de connaissance est contrôlée par le serveur de 15 traitement de scénarii (5) et est commune à tous les boitiers d'accès à Internet (2) du réseau opérateur (20), alors que la seconde base de connaissance est spécifique du boitier d'accès à Internet (2) d'un foyer. 5. Procédé selon la revendication 4, dans lequel la 20 seconde base de connaissance est mise à jour via une interface utilisateur d'un équipement (3) en cas d'identification d'un n-uplet de paramètres incompatible avec la seconde base de connaissances. 6. Procédé selon l'une des revendications 1 à 5, dans 25 lequel l'étape d'expression du scénario comprend la saisie d'une chaîne de caractère par l'usager et/ou la sélection d'au moins un des paramètres du nuplet dans une liste de possibilités. 7. Procédé selon la revendication 6, dans lequel les 30 étapes (a) et (b) sont mises en oeuvre simultanément et dynamiquement, ladite liste de possibilités étant mise à jour à chaque fois qu'un paramètre du n-uplet est sélectionné par l'usager ou identifié par analyse sémantique, 3024811 23 de telle sorte que la liste de possibilités comprenne seulement des possibilités de paramètres associés avec les paramètres déjà identifiés ou sélectionnés dans la première ou la seconde base de connaissance. 5 8. Procédé selon l'une des revendications 1 à 7, dans lequel le n-uplet de paramètres de la partie de conséquence (P2) comprend en outre au moins un paramètre supplémentaire caractérisant le périphérique (1), chaque périphérique (1) connecté au boitier d'accès internet (2) étant associé à au moins un paramètre supplémentaire dans la 10 seconde base de connaissances. 9. Procédé selon la revendication 8, dans lequel au moins deux périphériques (1) connectés au boitier d'accès internet (2) correspondent dans la seconde base de connaissances au type de 15 périphérique identifié, la détermination du périphérique (1) désigné dans le scénario à l'étape (c) étant également en fonction dudit paramètre supplémentaire identifié. 10. Procédé selon l'une des revendications 1 à 9, dans 20 lequel au moins deux périphériques (1) connectés au boitier d'accès internet (2) correspondent dans la seconde base de connaissances aux paramètres identifiés, l'étape (c) comprenant en outre la sélection du périphérique (1) parmi lesdits périphériques correspondant aux paramètres identifiés. 25 11. Procédé selon l'une des revendications 1 à 10, dans lequel au moins un périphérique (1) est désigné dans la partie de condition (P1) du scénario, la partie de condition (P1) étant également définie sous la forme d'un n-uplet de paramètres dont au moins : 30 - un type de périphérique - une action associée au type de périphérique dans la première base de connaissance ; 3024811 24 l'étape (c) comprenant également la détermination par le serveur de traitement de scénarii (5) dudit périphérique (1) désigné dans la partie de condition (P1) du scénario. 5 12. Procédé selon l'une des revendications 1 à 11, dans lequel le fichier d'instructions de contrôle est en langage de balisage de type XML (eXtensible Markup Language). 13. Serveur de traitement de scénarii (5) disposé au sein 10 d'un réseau opérateur (20) relié au réseau internet (21), configuré pour mettre en oeuvre : - Un module de réception d'un scénario d'utilisation d'un périphérique (1) connecté à un boitier d'accès à internet (2), exprimé préalablement en langage naturel sur une interface utilisateur d'un 15 équipement (3) connecté au réseau internet (21) ; - Un module d'analyse sémantique dudit scénario de sorte à identifier une partie de condition (P1) du scénario et une partie de conséquence (P2) du scénario, la partie de conséquence (P2) étant définie sous la forme d'un n-uplet de paramètres dont au moins : 20 o un type de périphérique o une action associée au type de périphérique dans une première base de connaissance accessible par ledit boitier d'accès à internet (2) ; - un module de détermination du périphérique (1) désigné dans le 25 scénario à partir d'une seconde base de connaissances stockée sur ledit boitier d'accès à internet (2) en fonction d'au moins le type de périphérique identifié, - un module de génération d'un fichier d'instructions de contrôle du périphérique (1) en fonction d'au moins l'action identifiée, en vue 30 d'une exécution de sorte à contrôler le périphérique (1) conformément audit scénario d'utilisation dudit périphérique (1). 3024811 25 14. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 12 de contrôle à distance d'au moins un périphérique (1) connecté à un boitier d'accès internet (2). 5 15. Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 12 de contrôle à distance d'au moins un périphérique (1) 10 connecté à un boitier d'accès internet (2).