FR3052004B1 - Procede d'echange de donnees entre un objet connecte et un serveur central. - Google Patents

Abstract

Selon l'invention, l'information est échangée entre l'objet connecté et le serveur central au moyen d'une requête DNS auprès d'un serveur de noms de domaine spécifique au domaine auquel appartient le serveur central. Ce serveur de nom est adapté pour interprété l'information utile transmise dans la requête et éventuellement répondre en introduisant dans la réponse à la requête DNS l'information en retour. L'échange d'information via une requête DNS selon l'invention est possible avec un point d'accès ouvert ou protégé par une authentification HTTP.

Description

PROCEDE D’ECHANGE DE DONNEES ENTRE UN OBJET CONNECTE ET UN SERVEUR CENTRAL

La présente invention concerne un procédé d’échange de données entre un objet connecté et un serveur central. Plus particulièrement, le procédé concerne un procédé d’échange utilisant un point d’accès Wi-Li.

On entend dans ce document par objet connecté tout dispositif de traitement de l’information comprenant un moyen de connexion à un réseau de communication de données. Un tel objet connecté est typiquement mobile, c’est-à-dire susceptible de se connecter au réseau de communication à partir de diverses positions géographiques. Bien que non strictement requis par l’invention, celle-ci prend tout son sens dans le contexte d’objets connectés mobiles.

Un tel objet connecté peut se connecter au réseau de communication selon toute technologie de connexion allant de technologies filaires comme Ethernet à l’ensemble des technologies sans fil, c’est-à-dire utilisant une technologie de connexion radio telle que Bluetooth, Zigbee, Wi-Li, WiMAX ou autres. Nous nous intéressons dans ce document plus particulièrement aux objets connectés utilisant la technologie Wi-Li, c’est-à-dire utilisant l’un des standards de la famille IEEE 802-11.

La Figure 1 illustre une connexion Wi-Fi entre un objet connecté et un serveur central. Un objet connecté 1.1 établit une connexion selon le protocole Wi-Fi avec un point d’accès Wi-Fi 1.2. Le point d’accès Wi-Fi est connecté au réseau 1.3 de communication d’un fournisseur d’accès Internet, aussi appelé opérateur, qui opère le point d’accès 1.2. Le réseau 1.3 de l’opérateur est lui-même connecté à Internet 1.4, réseau auquel les serveurs 1.5 sont eux-aussi connectés. Les connexions entre le point d’accès 1.2 et le réseau de l’opérateur, ainsi qu’entre ce dernier et Internet peut utiliser tout type de technologie. Il s’agit généralement de connexions filaires à haut débit du type Ethernet ou fibre optique.

Pour que l’objet connecté 1.1 puisse communiquer avec un serveur 1.5 il doit tout d’abord se connecter au point d’accès 1.2. Cette connexion s’effectue selon l’une des normes IEEE 802-11 et se passe selon le schéma suivant. L’objet connecté compatible Wi-Fi scanne son environnement radio et détecte le point d’accès. Il s’ensuit une phase d’échange au niveau MAC (Media Access Control en anglais) pour établir une communication avec le point d’accès. L’objet connecté reçoit alors une fois cette première connexion établie, une configuration IP (Internet Protocol en anglais), typiquement selon le protocole DHCP (Dynamic Host Configuration Protocol en anglais). Cette configuration contient une adresse IP, un masque de sous-réseau, l’adresse d’une passerelle pour permettre le routage de paquets IP, ainsi que l’adresse d’un serveur de nom, DNS (Domain Name Serveur en anglais) pour la résolution des noms plus d’éventuels paramètres supplémentaires. L’objet connecté configure alors son interface IP avec les paramètres reçus. Dès lors, il peut communiquer avec tout appareil connecté au réseau en utilisant tout type de protocole basé sur IP, comme par exemple établir une connexion Web en utilisant le protocole HTTP (Hyper Text Transfer Protocol en anglais).

La connexion au niveau MAC entre l’objet connecté et le point d’accès peut être soumise à différents modes d’authentification.

Selon un premier mode d’authentification dit ouvert, aucune authentification n’est requise. Dans ce cas tout dispositif de traitement de l’information compatible Wi-Fi est autorisé à se connecter au point d’accès. Un objet connecté peut ainsi utiliser une point d’accès ouvert sans devoir posséder d’information d’authentification particulière.

Selon un second mode d’authentification dit chiffré, la connexion est soumise à un protocole d’authentification, typiquement sur la base d’un nom de connexion (login en anglais) et d’un mot de passe. L’objet doit alors posséder ce nom de connexion et ce mot de passe pour établir la connexion avec le point d’accès. La communication entre l’objet connecté et le point d’accès est alors chiffrée à l’aide de ces informations. Plusieurs protocoles d’authentification et de chiffrement peuvent être mis en œuvre possédant divers niveaux de sécurité. On peut citer, par exemple, des protocoles tels que WEP (Wired Equivalent Privacy en anglais), WPA (Wi-Fi Protected Access en anglais) ou encore WPA2, une variante du protocole précédent. Ce mode d’authentification nécessite donc une inscription auprès de l’opérateur et l’obtention d’un nom de connexion et d’un mot de passe pour pouvoir se connecter au point d’accès. L’authentification est alors gérée par l’opérateur typiquement en utilisant un serveur d’authentification tel qu’un serveur RADIUS (Remote Authentication Dial-in User Service en anglais).

Un troisième mode d’authentification dit HTTP est décrit dans le document intitulé « Best Current Practices for Wireless Internet Service Provider (WISP) Roaming » disponible auprès du consortium « Wi-Fi Alliance » en charge de tester et de valider la compatibilité des appareils Wi-Fi et de promouvoir cette technologie. Ce document décrit une méthode d’accès universel UAM (Universal Access Method en anglais), basée sur un navigateur Internet (browser en anglais), à un point d’accès Wi-Fi. Selon cette méthode la connexion au niveau MAC est ouverte, c’est-à-dire que l’objet connecté peut toujours se connecter au point d’accès. Mais une fois connecté, il ne peut pas accéder à des services sur Internet car les ports de communication sont bloqués. H doit alors utiliser un navigateur Web pour envoyer une requête HTTP sur un serveur quelconque. Cette requête est alors interceptée par le point d’accès et une redirection est opérée vers une page Web d’authentification invitant le navigateur à communiquer un nom de connexion et un mot de passe. Une fois Γauthentification validée, les ports sont débloqués et l’accès au réseau de communication est alors possible. Ce mode d’authentification est très courant pour les accès publics, notamment dans les gares, les aéroports, les cafés et restaurants, les hôtels etc.

Un objet connecté souhaitant échanger des informations avec un serveur central est donc obligé de mettre en œuvre une procédure relativement lourde de connexion TCP/IP avec ce serveur. Sauf à négocier une inscription auprès d’opérateurs fournissant un accès Wi-Fi, seuls les points d’accès ouverts peuvent être utilisés. Ces points d’accès ouverts sont rares car des obligations légales de traçabilité tendent à les faire disparaître au profit d’accès sécurisés par une authentification.

La présente invention a pour but de résoudre les inconvénients précités. Selon l'invention, l’information est échangée entre l’objet connecté et le serveur central au moyen d’une requête en résolution de nom (DNS) auprès d’un serveur de noms de domaine spécifique au domaine auquel appartient le serveur central. Ce serveur de nom est adapté pour interprété l’information utile transmise dans la requête et éventuellement répondre en introduisant dans la réponse à la requête DNS l’information en retour. L’échange d’information via une requête DNS selon l’invention est possible avec un point d’accès ouvert ou protégé par une authentification HTTP. Seuls les points d’accès protégés par une authentification chiffrée ne peuvent être utilisés sauf à posséder les crédits d’authentification nécessaires. L’invention concerne un procédé d’échange d’information spécifique entre un objet connecté et un serveur central comprenant les étapes suivantes par ledit objet connecté disposant d’une interface Wi-Li : - une étape de détection d’un point d’accès Wi-Li dans l’environnement radio de l’objet connecté ; - une étape d’envoi d’une requête de connexion au niveau MAC au point d’accès détecté ; caractérisé en ce que, en cas de succès de la connexion au niveau MAC, le procédé comporte en outre : - une étape d’envoi d’une requête DNS pour la résolution d’un nom de domaine intégrant un sous-domaine dédié, ledit sous-domaine dédié étant géré par un serveur DNS dédié sur ledit serveur central, ladite requête DNS contenant Tinformation spécifique à transmettre.

Selon un mode particulier de réalisation, le procédé comporte en outre : - une étape de réception d’une réponse DNS émise par ledit serveur central et contenant une information en réponse à Tinformation spécifique transmise dans la requête DNS.

Selon un mode particulier de réalisation, Tinformation en réponse est transmise dans le champ « RDATA » d’un enregistrement de ressource de la réponse DNS.

Selon un mode particulier de réalisation, l’information spécifique est codée sous la forme d’une séquence de labels concaténée au sous-domaine dédié.

Selon un mode particulier de réalisation, l’information spécifique est répartie et transmise via une pluralité de requêtes DNS. L’invention concerne également un procédé d’échange d’information spécifique entre un objet connecté et un serveur central comprenant les étapes suivantes par ledit serveur central : - une étape de réception d’une requête DNS pour la résolution d’un nom de domaine dédié par un serveur DNS dédié et adapté ; - une étape d’extraction d’une information spécifique contenue dans ladite requête DNS par le serveur DNS dédié et adapté ; - une étape de transmission de ladite information spécifique à un service dédié aux objets connectés.

Selon un mode particulier de réalisation, le procédé comprend en outre : - une étape de transmission d’une réponse DNS à la requête DNS intégrant une information en réponse à l’information spécifique reçue.

Procédé d’échange d’information spécifique caractérisé en ce que selon un mode particulier de réalisation, l’information en réponse est transmise dans le champ « RDATA » d’un enregistrement de ressource de la réponse DNS.

Selon un mode particulier de réalisation, l’information spécifique extraite est codée sous la forme d’une séquence de labels concaténée au sous-domaine dédié. L’invention concerne également un objet connecté adapté pour la mise en œuvre du procédé selon l’invention. L’invention concerne également un programme d’ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l’invention lorsque ledit programme est exécuté sur un ordinateur. L’invention concerne également un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’invention.

Dans un mode particulier de réalisation, des étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en œuvre des étapes du procédé tel que mentionné ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d’un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en œuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après en relation avec les dessins annexés, donnés à titre d'exemples non limitatifs : la Figure 1 illustre une connexion Wi-Li entre un objet connecté et un serveur central ; la Figure 2 illustre la hiérarchie des noms de domaine ; la Figure 3 illustre un exemple de réalisation de l’échange de données selon l’invention entre un objet connecté et un serveur central ; la Figure 4 est un bloc-diagramme schématique d'un dispositif de traitement de l’information pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention.

Une adresse Internet est attribuée à chaque interface réseau connectant un dispositif de traitement de l’information au réseau Internet quelque soit la technologie de connexion utilisée. Deux formats d’adresses coexistent, les adresses selon le protocole IPv4 constituées de quatre octets, par exemple « 192.168.10.5 » et les adresses selon le protocole IPv6 constituées de 16 octets. Ces adresses sont utilisées par tous les protocoles basés sur IP pour la communication de machine à machine. Toutefois, elles ne sont pas facilement mémorisables et manipulables par un humain. C’est pourquoi les humains font référence aux machines à l’aide de noms de domaine.

Un service appelé résolution de nom de domaine ou DNS permet de traduire un nom de domaine en adresse IP et à l’inverse de traduire une adresse IP en nom de domaine. Ce service est décrit dans la requête pour commentaire (RFC pour Request For Comment en anglais) numéro 1035.

Les noms de domaine sont organisés de manière hiérarchiques et prennent la forme d’un nombre quelconque de sous-domaines séparés par des points. Par exemple, le domaine « www.apple.com » se décompose hiérarchiquement en « com » qui est le domaine principal, « apple » qui désigne le sous-domaine de plus haut niveau et « www » qui désigne le sous-domaine de niveau inférieur. Ce nom de domaine désigne un service commercial, domaine « com », appartenant à la société Apple (marque déposée), sous-domaine « apple », et désigne le service Web de cette société, sous-domaine « www ». De manière similaire, le domaine « ftp.dept-physique.univ-rennes.edu » désigne le service de transfert de fichier, sous-domaine « ftp », du département de physique, sous domaine « dept-physique », de l’université de Rennes, sous-domaine « univ-rennes », cette dernière étant une entité éducative, domaine « edu ». Une requête à un serveur de nom de domaine appelé serveur DNS permet d’obtenir l’adresse IP correspondant à un domaine. Par exemple, lorsque l’on tape le domaine « www.apple.com » dans un navigateur Web, ce dernier commence par effectuer une requête DNS auprès d’un serveur DNS dont il dispose de l’adresse IP dans sa configuration pour obtenir l’adresse IP du service web d’Apple. Ce n’est qu’ensuite qu’il est en mesure d’adresser une requête HTTP à ce dernier en utilisant cette adresse IP.

La Figure 2 illustre la hiérarchie des noms de domaine. Par exemple, à partir d’une racine 2.1, tous les domaines de plus haut niveau, tels que « com », « fr », « edu », « gov » etc. sont des fils de la racine. Par exemple, le nœud 2.2 représente le domaine « com ». Les sous-domaines du domaine « com » apparaissent comme nœuds fils du nœud « com » 2.2. Le nœud 2.3 représente, par exemple, le sous-domaine « apple » et le nœud fils 2.4, le sous-domaine « www ». L’intégralité des noms de domaines Internet peut ainsi être représentée sous la forme d’un immense arbre. L’organisation du service de résolution de nom, ou service DNS, reflète cette structure hiérarchique en arbre des noms de domaine. H existe des serveurs DNS dit racine auxquels sont adressées les requêtes en résolution d’un nom de domaine. Il existe également des serveurs DNS en charge de différents sous arbres de l’arbre des noms de domaine. Ainsi, une réquête visant la résolution du nom de domaine « www.apple.com » sera dirigée vers un serveur DNS racine correspondant au nœud racine 2.1. Ce serveur racine va extraire le domaine de plus haut niveau « com » et relayer la requête vers un serveur de nom en charge du domaine « com » correspondant au nœud 2.2 de l’arbre. A nouveau ce serveur va extraire le sous-domaine de plus haut niveau « apple » et va relayer la requête vers le serveur de nom de la société Apple, correspondant au nœud 2.3 de l’arbre. Ce dernier, en charge des adresses des ordinateurs de la société, pourra répondre à la requête en donnant l’adresse IP correspondant au sous-domaine « www ». La réponse sera alors transmise via les différents serveurs DNS jusqu’à l’origine de la requête. Un système de mémoire cache est géré sur chaque serveur DNS de manière à mémoriser les dernières requêtes et leurs réponses. Ainsi une nouvelle requête pour un domaine dont la réponse est mémorisée dans le cache pourra être résolue sans relayer la requête à l’ensemble des sous-serveurs concernés, la réponse sera ainsi beaucoup plus rapide. Pour assurer qu’un changement d’adresse soit tout de même pris en compte, les informations ainsi mémorisées dans la mémoire cache des serveurs DNS sont assorties à une durée de vie limitée appelée TTL (Time To Live en anglais). Cette durée de vie est définie par le serveur DNS de plus bas niveau. Par exemple, le serveur DNS de la société Apple pourra fixer une durée de vie d’une journée pour les informations de nom relatives à son sous-domaine.

Nous avons vu que les points d’accès Wi-Fi implémentant un mode d’authentification HTTP ont leurs ports de communication fermés. Leur ouverture étant soumise au succès d’une procédure d’authentification via une page WEB d’authentification. Les inventeurs ont toutefois remarqué que le port dédié au service de résolution d’adresse, précisément le port 53 dédié au DNS est ouvert. En effet, la redirection vers la page WEB d’authentification requiert généralement la résolution du nom de domaine hébergeant ladite page. Il est donc possible pour un objet connecté d’émettre une requête DNS, une fois la connexion au point d’accès au niveau MAC établie, sans nécessairement s’authentifier via la page WEB d’authentification. Cette observation est à la base de l’invention.

Selon un premier aspect de l’invention, le serveur central destinataire de l’échange avec l’objet connecté implémente un serveur DNS dédié à la communication avec les objets connectés. Ce serveur gère un sous-domaine spécifique, appelons le « service-oc » pour service objets connectés, et s’inscrit pour cette gestion auprès d’un serveur DNS tiers auquel il se rattache. Par exemple, si l’accès à internet dudit serveur central est géré par un fournisseur d’accès « fai », le sous-domaine géré par le serveur DNS du service objets connectés pourrait être le sous-domaine « service-oc.fai.com ». Ainsi toute requête DNS pour un sous-domaine du sous-domaine « service-oc.fai.com » sera relayé par les serveurs DNS pour être résolu, in fine, par le serveur DNS dédié implémenté sur le serveur central destinataire de l’échange. Un tel sous-domaine prends la forme «XXX.service-oc.fai.com» où «XXX» peut être une chaîne nulle où un nombre quelconque de labels de sous-domaines séparés par des points. La chaîne de sous domaine « XXX » aura donc typiquement la forme : « labell.label2.....labelN », chaque label ayant au plus 63 caractères et étant limitée à des caractères en ASCII sur 7 bits, une chaîne complète de nom de domaine ne pouvant excéder 255 caractères.

Avantageusement, si la quantité d’information spécifique à transmettre excède la capacité d’un nom de domaine, elle peut être transmise sous la forme d’une pluralité de requêtes DNS. L’information spécifique est alors répartie dans l’ensemble de ces requêtes DNS comme décrit précédemment.

Un objet connecté souhaitant communiquer une information spécifique au serveur central peut donc coder cette information dans une chaîne de sous-domaine du type « labell.label2.....labelN », concaténer cette chaîne contenant l’information à transmettre au sous domaine du service objets connectés « service-oc.fai.com » et transmettre une requête DNS demandant la résolution du sous-domaine résultant de cette concaténation. Une information spécifique est comprise comme une information non relative au fonctionnement standard du service de résolution de noms. Cette information est spécifique dans le sens où elle est relative au service lié à l’objet connecté et à sa fonction.

Le serveur DNS dédié implémenté sur le serveur central destinataire de l’échange est un serveur DNS standard sauf en ce qu’il est adapté pour extraire la chaîne de sous-domaine lorsqu’il reçoit une requête en résolution pour un sous-domaine. Cette chaîne est alors transmise au service destinataire sur le serveur central. Dans certains modes de réalisation, l’information peut être transmise pour un traitement effectif par un autre serveur connecté au serveur central. On considère alors que l’échange d’information intervient entre l’objet connecté et le serveur hébergeant le serveur DNS dédié indépendamment du traitement de l’information transmise ultérieurement. Ainsi, un objet connecté peut transmettre une information sous la forme d’une requête DNS au serveur central. Cette requête ne nécessite pas l’établissement d’une connexion entre l’objet connecté et le serveur central. De plus, il est possible d’utiliser les point d’accès ouverts et les points d’accès protégés par un mode d’authentification HTTP pour transmettre l’information. Seuls les points d’accès protégés par un mode d’authentification chiffré qui nécessite la connaissance d’une clé de chiffrement pour l’établissement de la connexion au niveau MAC entre l’objet connecté et le point d’accès ne peuvent pas être utilisés sauf à connaître des informations de connexion et donc avoir été enregistré au préalable auprès de l’opérateur du point d’accès.

Les messages échangés selon le protocole de résolution de noms tel que défini dans la RLC 1035 contiennent des enregistrements de ressources appelées RRs (pour Ressource Record en anglais). Ces RRs sont contenus tant dans les requêtes DNS que dans les réponses. Ces RRs contiennent un champ de données (RDATA) et une longueur de champ (RDLENGTH) qui permettent de d’encoder dans un message DSN toute information complémentaire utile. Un message DNS peut comporter jusqu’à 3 RRs dont un RR additionnel pour transmettre des informations additionnelles.

Dans certains mode de réalisation de l’invention, lorsqu’une transmission d’information en réponse est requise du serveur central vers l’objet connecté ayant fait la requête, cette information peut être encodée dans ce RR additionnel, par exemple.

Cette information est alors transmise par retour du serveur central à l’objet connecté sous forme de réponse DNS envoyée par le serveur DNS dédié et adapté au service objets connectés. Cette réponse est relayée par l’ensemble de la chaîne des serveurs DNS jusqu’à atteindre l’objet connecté.

La durée de vie de la réponse est fixée par le champ TTL du RR. Cette durée de vie est avantageusement fixée à 0 pour interdire aux différents serveur DNS de mémoriser la réponse dans leur cache. En effet, une mémorisation dans le cache d’un serveur DNS intermédiaire entre l’objet connecté et le serveur central a pour effet qu’une nouvelle requête avec le même nom de sous-domaine n’atteindra pas le serveur central et qu’il y sera répondu la réponse mémorisée dans le cache. Dans le cas où l’information transmise par l’objet connecté change à chaque requête, ceci n’est pas gênant car le sous-domaine généré par la requête sera nouveau lors de chaque requête. Donc, cette nouvelle requête atteindra toujours le serveur central. Dans les applications où l’information échangée peut être identique entre deux transmission, une telle mise en cache peut empêcher la requête d’atteindre le serveur central. Dans ce cas, l’échange entre l’objet connecté et le serveur central ne peut être garanti que si la durée de vie est mise à 0.

La Figure 3 illustre un exemple de réalisation de l’échange de données selon l’invention entre un objet connecté et un serveur central.

Lors de l’étape 3.1, l’objet connecté scanne son environnement radio pour détecter un point d’accès. Quand il trouve un point d’accès, il commence le processus de connexion au niveau MAC avec le point d’accès par l’envoi d’une requête de connexion lors d’une étape 3.2. Cette requête contient typiquement une requête pour des paramètres de connexion IP selon le protocole DHCP. Cette tentative de connexion peut réussir ou échouer. Lors de l’étape 3.3, un test sur le succès de la connexion est effectué. Si la connexion a échouée, le processus se termine par l’étape finale 3.4. En cas de succès, la connexion est établie. Le succès de la connexion dépend typiquement, comme nous l’avons vu, du mode d’authentification implémenté par le point d’accès. Typiquement, si le point d’accès est ouvert ou protégé par un mode d’authentification HTTP, la connexion au niveau MAC réussit. Dans le cas où le point d’accès est protégé par un mode d’authentification chiffré, la requête en connexion doit contenir un secret partagé nécessaire à l’établissement de la connexion chiffrée entre l’objet connecté et le point d’accès. Dans ce cas, sauf à ce que l’objet connecté connaisse ce secret, la connexion échoue.

Une fois la connexion établie, l’objet connecté a reçu une configuration IP du point d’accès et a configuré son interface Wi-Fi à l’aide des paramètres reçus. Un dialogue au niveau IP peut donc être initié entre l’objet connecté et le point d’accès. Dans le cas d’un point d’accès ouvert, l’accès selon tout protocole à des destination au-delà du point d’accès est possible. Dans le cas d’un point d’accès protégé par un mode d’authentification HTTP, les ports de communication du point d’accès sont fermés aux communications issues de l’objet connecté en attente d’une authentification réussie via une page Web. Seul le port 53 dédié au service de résolution de nom est ouvert.

Dans tous les cas, l’objet connecté émet une requête DNS, étape 3.5, contenant l’information à transmettre comme vu plus haut concaténée au sous-domaine correspondant au service objets connectés. Cette requête est alors relayée jusqu’au serveur DNS dédié et adapté sur le serveur central destinataire de l’échange. Ce serveur extrait l’information transmise pour son utilisation par le serveur.

Dans le cas où une réponse est nécessaire, cette réponse est élaborée par le serveur central et transmise au serveur DNS dédié et adapté pour transmission intégrée dans la réponse du serveur DNS à la requête reçue. Cette étape de réponse est optionnelle, selon l’application elle peut ne pas être nécessaire. Cette réponse à la requête DNS est alors relayée par les serveurs DNS intermédiaire pour être finalement réceptionnée par l’objet connecté lors de l’étape 3.6. La phase d’échange se termine alors par l’étape finale 3.7.

Ainsi, un échange, éventuellement bidirectionnel, d’information est implémenté entre un objet connecté et un serveur central. Cet échange est rapide car il ne nécessite pas l’établissement d’une connexion entre l’objet et le serveur. Il est possible de tirer parti des points d’accès ouvert et de ceux protégés par un mode de protection HTTP.

La Figure 4 est un bloc-diagramme schématique d'un dispositif de traitement de l’information 4.0 pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 4.0 de traitement de l’information peut être un périphérique tel qu'un micro-ordinateur, un poste de travail ou d'un terminal mobile de télécommunication. Le dispositif 4.0 comporte un bus de communication connecté à: - une unité centrale de traitement 4.1, tel qu'un microprocesseur, notée CPU ; - une mémoire à accès aléatoire 4.2, notée RAM, pour mémoriser le code exécutable du procédé de réalisation de l'invention ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation de l'invention, la capacité de mémoire de celui-ci peut être complété par une mémoire RAM optionnelle connectée à un port d'extension, par exemple ; - une mémoire morte 4.3, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des modes de réalisation de l'invention ; - une interface réseau 4.4 est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmis ou reçus. L'interface réseau 4.4 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur 4.1 ; - une interface utilisateur 4.5 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ; - un support de stockage optionnel 4.6 noté HD ; - un module d’entrée/sortie 4.7 pour la réception / l'envoi de données depuis / vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.

Le code exécutable peut être stocké dans une mémoire morte 4.3, sur le support de stockage 4.6 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 4.4, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 4.0, tel que le support de stockage 4.6, avant d'être exécuté.

L'unité centrale de traitement 4.1 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation de l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 4.1 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 4.2, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple. Un tel logiciel, lorsqu'il est exécuté par le processeur 4.1, provoque les étapes des organigrammes présentés dans la figure 3 pour être exécutées.

Dans ce mode de réalisation, l'appareil est un appareil programmable qui utilise un logiciel pour mettre en œuvre l'invention. Toutefois, à titre subsidiaire, la présente invention peut être mise en œuvre dans le matériel (par exemple, sous la forme d'un circuit intégré spécifique ou AS IC).

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l’invention pourra appliquer des modifications dans la description précédente.

Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n'est pas limitée aux modes de réalisation spécifiques, et les modifications qui se trouvent dans le champ d'application de la présente invention seront évidentes pour une personne versée dans l'art.

Claims (12)

1. REVENDICATIONS

   1. Procédé d’échange d’information spécifique entre un objet connecté (1.1) et un serveur central (1.5) comprenant les étapes suivantes exécutées par ledit objet connecté disposant d’une interface Wi-Fi (4.4) : - une étape de détection (3.1) d’un point d’accès Wi-Fi (1.2) dans l’environnement radio de l’objet connecté (1.1); - une étape d’envoi (3.2) d’une requête de connexion au niveau MAC au point d’accès détecté (1.2) ; caractérisé en ce que, en cas de succès de la connexion au niveau MAC, le procédé comporte en outre : - une étape d’envoi (3.5) d’une requête DNS pour la résolution d’un nom de domaine intégrant un sous-domaine dédié, ledit sous-domaine dédié étant géré par un serveur DNS dédié sur ledit serveur central (1.5), ladite requête DNS contenant l’information spécifique à transmettre, ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine, l’information spécifique (XXX) étant codée sous la tonne d’une séquence de labels (label l,...,labeIN) concaténée au sous-domaine dédié.
2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite information spécifique est relative à un service lié à l'objet connecté et à une fonction dudit objet.
3. 3. Procédé d’échange d’information spécifique selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu’il comporte en outre : -- une étape de réception (3,6) d’une réponse DNS émise par ledit serveur central (1.5) et contenant une information en réponse à l’information spécifique transmise dans la requête DNS.
4. 4. Procédé d’échange d’information spécifique selon la revendication 3 caractérisé en ce que l’information en réponse est transmise dans le champ « RD ATA » d’un enregistrement de ressource de la réponse DNS.
5. 5. Procédé d’échange d’information spécifique selon l’une des revendications 1 à 4, caractérisé en ce que l’information spécifique est répartie et transmise via une pluralité de requêtes DNS.
6. 6. Procédé d’échange d’information spécifique entre un objet connecté (1.1) et un serveur central (1.5) comprenant les étapes suivantes exécutées par ledit serveur central : - une étape de réception d’une requête DNS pour la résolution d’un nom de domaine dédié par un serveur DNS dédié et adapté ; - une étape d’extraction d’une information spécifique contenue dans ladite requête DNS par le serveur DNS dédié et adapté ; caractérisé en ce qu'il comprend en outre : - une étape de transmission de ladite information spécifique à un service dédié aux objets connectés (1.1), ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine, et l’information spécifique extraite (XXX) étant codée sous la forme d’une séquence de labels (labell,...,labelN) concaténée au sous-domaine dédié.
7. 7. Procédé selon la revendication 6, caractérisé en ce que ladite information spécifique est relative à un service lié à l'objet connecté et à une fonction dudit objet.
8. 8. Procédé d’échange d’information spécifique selon l'une quelconque des revendications 6 et 7, caractérisé en ce qu’il comprend en outre : - une étape de transmission d’une réponse DNS à la requête DNS intégrant une information en réponse à l’information spécifique reçue.
9. 9. Procédé d’échange d’information spécifique selon la revendication 8, caractérisé en ce que l’information en réponse est transmise dans le champ « RDATA » d’un enregistrement de ressource de la réponse DNS.
10. 10. Objet connecté (1.1; 4.0) adapté pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 5.
11. 11. Programme d’ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l’une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté sur un ordinateur (4.0).
12. 12. Moyen de stockage d'informations (4.3; 4.6), amovible ou non, partiellement ou totalement lisible par un ordinateur (4.0) ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’une quelconque des revendications 1 à 4.