Brevet FR2885754A1 — publié le 20061117

Ce document décrit une méthode réalisée par un dispositif pour détecter et identifier une population de dispositifs bluetooth et leur envoyer des informations adaptées au profil de chaque client. Bluetooth [1] est une technologie sans fil qui est devenue une norme IEEE. Bluetooth rend possible la définition et la création de réseaux PAN ( Personal Area Network ou Aire de Réseau Personnel ). La technologie Bluetooth [1] établit les caractéristiques techniques pour l'interconnexion des dispositifs qui sont conformes à la dite spécification et qui se trouvent dans la zone de couverture. Par contre, la norme Bluetooth [1] n'a pas pour but décrire l'utilisation des capacités des terminaux pour la délivrance d'informations adéquates au profil de chaque dispositif. Ce document décrit un type de PAN qui est adapté à l'échange d'informations depuis un dispositif de référence qui envoie les données vers des dispositifs qui sont dans sa zone de couverture selon un profil déterminé par les identificateurs propres à la technologie bluetooth [1]. Les types d'informations qui peuvent être échangées incluent les; identificateurs de chaque dispositif, la classe de dispositif et les types de services que le dispositif peut gérer. Deux types d'identificateurs sont échangés après la découverte d'un nouveau dispositif: 25. L'adresse du dispositif, un champ de 48-bit ( bluetooth device address , BD_ADDR) qui est unique pour chaque dispositif et qui ne peut pas être modifié par l'utilisateur du dispositif. É Le nom du dispositif bluetooth ( bluetooth device name ) qui est an identificateur choisi et inséré dans la mémoire par l'utilisateur du dispositif. Le nom du dispositif est une chaîne de caractères qui est inscrite dans le champ LMP_name_res comme réponse à une demande du type LMP_name_req , suivant la spécification bluetooth [1]. 1 Ce document à pour but de définir une méthode et le dispositif qui l'implémente, dorénavant dénommé Dispostif Hôte (DH). Le DH communique à son tour avec des dispositifs bluetooth qui se trouvent dans sa zone de couverture, dorénavant dénommés Dispositifs Clients (DC). Le DC est tout dispositif bluetooth qui est découvert par le DH, reconnu par le DH ( tiusted ) ou qui demande une liaison avec le DH. Les éléments du DH sont détaillés dans la Figure 1. Le DH inclut un dispositif bluetooth qu'interface avec un module de gestion de liaison, dorénavant dénommé GL. Le module GL interface à son tour avec un serveur de contenus, dorénavant dénommé SC, et avec un module de gestion du catalogue des clients, dorénavant dénommé GCC. Le GCC interface avec une base de données associée qui contient les informations échangées pour établir la connexion et les profils des clients. Les éléments du DH ont les fonctions suivantes: GL: le module GL lit les identificateurs des DCs découverts et présentés par le module bluetooth du DH et les types de service disponibles sur chaque DC. A partir de ces informations le module GL gère les procédures à implementer pour la délivrance des informations de retour aux DCs. GCC: le module GCC récupère les identificateurs et les types dei service acceptables par chaque DC livré par le module GL et cherche le profil correspondant pour le DC. A partir du profil et des capacités du DC, le module GL déclenche la procédure adéquate pour la communication avec le DC. Le profil inclut les droits d'accès de chaque DC à l'information du serveur de contenus, la validité ou l'obsolescence des droits d'accès, la validité ou obsolescence des contenus pour chaque client et le code nécessaire au DC pour y accéder. SC: le module SC est en charge de stocker et de livrer les contenus adéquats pour chaque DC. 1 La méthode décrite ici est applicable aux dispositifs qui implementent les versions 1.1, 1.2, 2.0 ou successives de la norme bluetooth [1]. Les interfaces entre les éléments du DH ainsi que l'opération de ces éléments peuvent être automatisées ou réalisées manuellement par des opérateurs. La méthode décrite ici peut être implementée dans ces deux cas de figure. La méthode se déroule en deux phases. Pendant la première phase, le DH recherche les DC qui sont dans la zone de couverture du DH. Pour ce faire, le DH peut utiliser le Generic Access Profile de bluetooth [1] qui garantit l'interoperabilité de tout dispositif bluetooth pendant la phase de découverte et de notification de présence du dispositif, voir Figure 2. Alternativement le DC peut également chercher la présence d'un DH à sa portée. Les deux procédures donnent les identificateurs de chaque dispositif, voir Figure 3. Dans cette phase il est possible d'envoyer des messages texte en utilisant le champ bluetooth device name [1]. Cette capacité texte est utilisée dans la méthode pour envoyer dIas informations vers l'utilisateur du DC (y compris le nom du serveur de contenus) et récupérer les identificateurs du DC. Cette capacité est aussi utilisée pour envoyer le iode d'accès pour mettre en ouvre la phase 2. Dans cette phase le DH acquiert aussi le ED_ADDR du DC et vice-versa. Cette information est utilisée pour l'authentification des terminaux. La deuxième phase consiste à établir une liaison de type ACL sur L2CAP [1] ou une liaison synchrone sur SCO/eSCO [1]. Pour établir cette liaison selon la norme bluetooth, les dispositifs vont implementer la procédure pairing/bonding [1] avec le code qui a été communiqué par le DH pendant la phase 1, voir Figure 4. Cette liaison peut être initiée par le DH ou par le DC, mais il est toujours nécessaire d'utiliser le code delivré par l'identificateur du DH. La Figure 5 montre la procédure quand la liaison est initiée par le DC. Si la procédure pairing/bonding [1] n'est pas sollicitée par le DC la liaison peut être établie directement. Le DH peut aussi faire une émission ASB/PSEi [1] sur les DC qui sont dans la zone de couverture du DH. 1 Après réception du BD_ADDR du DC par le DH, le BD_ADDR est delivré par le module GL au module GCC qui vérifie l'authentification du DC en fonction de son profile stocké dans la base de données associée. Avec ce profil, le module GL récupère les informations adéquates à partir du module SC et les envoie au DC. Le module GCC inscrit le DC dans un registre qui contient tous les DC connectés. Ce registre est valable pendant la durée de la connexion et contient aussi l'heure et la date de connexion et le type d'information delivrée. Le module GCC note et trace la validité temporelle des informations disponibles dans le module SC par rapport aux informations livrées aux DC. Une connexion ACL, SCO ou eSCO sera libérée après livraison des informations aux DC. Il est possible de définir un profil ouvert qui aura accès à des informations générales et disponibles pour tous les clients. Par simplicité, le code de base pour implementer la procédure pairing/bonding [1] pour l'accès de un DC quelconque est 0 (zéro, avec un seul chiffre). II est possible de définir des groupes de DC qui auront accès à des informations particulières et réservées à ce groupe. L'appartenance à ce groupe esi déterminée en lisant le BD_ADDR du DC. Pour ces groupes il est possible d'établir ur profil trusted [1] qui n'a pas besoin du processus pairing/bonding [1] après une première connexion avec le DH. Il est possible de définir des groupes d'utilisateurs des DC qui auront accès à des informations particulières et réservées à ce groupe. L'appartenance à ce groupe est déterminée en lisant le BD_ADDR du DC après avoir présenté un code diffèrent de 0 (zéro) pendant la procédure pairing/bonding [1]. Dans cette méthode, Il est possible de réaliser la première phase sans effectuer la seconde. Revendications 1) Méthode pour la détection des dispositifs bluetooth dans la zone ce couverture d'un dispositif hôte (DH) et la délivrance d'informations vers de disposilifs en utilisant le champ "bluetooth device name" du DH échangé entre le DH et un dispositif client (DC) lors de la détection de la présence du dispositif dans la zone de couverture. 2) Méthode selon la revendication 1 caractérisée en ce que le message du dispositif hôte inséré dans le champ "bluetooth device name" contient des informations (y compris le nom du serveur de contenus) adressées à un dispositif quelconque situé dans la zone de couverture du dispositif hôte et qui a été détecté par le dispositif hôte. 3) Méthode selon la revendication 1 caractérisée en ce que le message du dispositif hôte inséré dans le champ "bluetooth device name" contient des irformations (y compris le nom du serveur de contenus) adressées à un dispositif quelconque situé dans la zone de couverture du dispositif hôte et qui a été détecté par le dispositif client. 4) Méthode selon la revendication 1 caractérisée en ce que le message du dispositif hôte inséré dans le champ "bluetooth device name" contient l'indication du code à utiliser pour réussir le processus de "pairing/bonding". 5) Méthode selon les revendications 1, 2, 3 et 4 caractérisée en ce que le code pour accès général d'un quelconque dispositif bluetooth aux informations du dispositif hôte est le 0 (zéro). 6) Méthode selon les revendications 1, 2, 3 et 4 caractérisée en ce que le code pour accès restreint de un quelconque dispositif bluetooth aux informations du dispositif hôte est un numéro avec 1, 2, 3 ou 4 chiffres, mais distinct de 0 (zéro). 7) Méthode selon les revendications 1, 2, 3 et 4 caractérisée en ce qu'après la procédure pairing/bonding a été complétée, l'accès aux informations disponibles dans le dispositif hôte sera réalisé avec une liaison ACL, SCO ou eSCO selon les profils des informations à fournir et selon les services qui peuvent étre implementés par chaque dispositif [1]. 1 8) Méthode selon les revendications 1, 2 et 3 caractérisée en ce que le dispositif hôte réalise des émissions ASB/PSB [1] sur les DC qui sont dans la zone de couverture du DH, selon les profils des informations à fournir et selon les services qui peuvent être implementés par chaque dispositif [1]. 9) Méthode selon les revendications 1 à 8 caractérisée en ce que l'aocès aux informations disponibles dans le dispositif hôte sera accordé à un dispositif client selon le profil correspondant à son identificateur BD_ADDR et/ou à son identificateur bluetooth device name . 10) Dispositif hôte qui réalise les fonctions des revendications 1 à 9 e1 caractérisé en ce qu'il contient les éléments suivants pour effectuer la dite méthode: É Module de Gestion de Liaison (GL). Lit les identificateurs des DC détectes et présentés par l'unité bluetooth du DH et les types de service disponibles sur chaque DC. A partir de ces informations le module GL gère les procédures à implementer pour la délivrance d'informations en retour vers les DC. É Module de Gestion du Catalogue de Clients (GCC). Récupère les identificateurs et les types de service acceptables par chaque DC qui sont delivrés par e module GL et cherche le profil correspondant pour le DC. A partir du profil et des capacités du DC, le module GL déclenche la procédure adéquate pour la communication avec le DC. Le profil inclut les droits d'accès de chaque DC à l'information du serveur de contenus, la validité ou l'obsolescence des droits d'accès, la validité ou l'obsolescence des contenus pour chaque client et le code nécessaire au DC pour y accéder. É Module Serveur de Contenus (SC). Le module SC sert à stocker e. : à livrer les contenus adéquats pour chaque DC. 11) Dispositif hôte selon la revendication 10 caractérisé en ce que quelques-unes ou toutes les fonctions décrites peuvent être réalisées par un systèm^: automatique ou manuellement par un opérateur qui interface avec les modules du dispositif hôte décrits et montrés dans la Figure 1. 25 30 Références [1] Spécification du Système Bluetooth, https://www. bluetooth. org/spec