PROCEDE ET PLATEFORME DE COMMUNICATION HOMOGENE ENTRE OBJETS ET

SERVICES CONNECTÉS

DOMAINE TECHNIQUE

L'invention se situe dans le domaine des communications bidirectionnelles entre une pluralité de sources et une pluralité de destinataires, et concerne plus spécifiquement un procédé de communication entre une pluralité d'objets ou de services connectés ayant chacun un langage construit propre et étant susceptibles d'être source ou destinataire d'informations échangées via une plateforme intelligente de communication comportant une pluralité d'unités distribuées de traitement de l'information communiquant via au moins une unité bidirectionnelle d'échange en langage naturel et comprenant chacune au moins une unité logicielle et/ou matérielle d'adaptation de média et de protocole, au moins une unité logicielle et/ou matérielle de conversion de langage, et au moins une interface logicielle et/ou matérielle bidirectionnelle agencée entre l'unité bidirectionnelle d'échange en langage naturel et l'unité de traitement de l'information.

L'invention concerne également une plateforme intelligente de communication entre une pluralité d'objets ou services connectés ayant chacun un langage construit propre et étant susceptible d'être source et/ou destinataire d'informations comportant une pluralité d'unités distribuées de traitement de l'information communiquant via au moins une unité bidirectionnelle d'échange en langage naturel et comprenant chacune au moins une unité logicielle et/ou matérielle d'adaptation de média et de protocole, au moins une unité logicielle et/ou matérielle de conversion de langage, et au moins une unité logicielle et/ou matérielle d'interface bidirectionnelle agencée entre l'unité bidirectionnelle d'échange en langage naturel et ladite unité de traitement de l'information,

L'invention concerne également un système de communication entre une pluralité d'objets ou de services connectés comportant une telle plateforme intelligente. L'invention concerne également un programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour mettre en œuvre le procédé selon l'invention lorsqu'il est exécuté par ordinateur. ÉTAT DE LA TECHNIQUE ANTÉRIEURE

De plus en plus, les objets communicants, ou objets connectés, et les services numériques sont utilisés com me support à de nom breux services dans la plupa rt des domaines d'activité personnelle, de la vie professionnelle et aussi de l'environnement public, par exemple, da ns le domaine de la santé, de l'assistance aux humains, de la maison connectée, de la ville intelligente, de la sécurité, de l'agriculture, des véhicules autonomes, de la gestion de l'énergie, les robots industriels et de services, etc.. Ces objets connectés échangent des informations par l'intermédiaire d'interfaces numériques issues du monde des télécommunications et du monde de l'Internet (web). A cet effet, plusieurs recommandations et plusieurs standards existent, élaborés totalement ou partiellement, par divers organismes tels que l'European Télécommunications Standards I nstitute (ETSI), le World Wide Web Consortium (W3C), l'Open I nterconnect Consortium (OIC), la Allseen Alliance, le TeleManagement Forum (TM F), OASIS, etc. Ces différentes recommandations et standards ont notamment pour but :

de permettre un certain niveau d'interopérabilité entre les infrastructures, les objets connectés et les services qui les mettent en œuvre ;

de limiter les efforts et les coûts de développements, de déploiement et de maintenance de ces objets et services ;

de simplifier la mise en œuvre pour les utilisateurs, en particulier lorsque ceux- ci utilisent les objets et services en nombre important, par exemple en limitant la quantité d'applications nécessaires pour gérer ces objets et services.

Cependant, l'abondance et la diversité des objets connectés, des services numériques, des normes et protocoles de communication, provoquent une multiplicité de types de commandes, de paramètres, d'unités, de conventions, de présentations, etc.... de sorte que, pratiquement, chaque objet possède son propre langage de communication avec l'extérieur. Faire face à cette abondance en développant autant d'adaptation ad-hoc qu'il y a d'objets ou de familles d'objets, comme cela se fait au sein des "hubs numériques", est une solution complexe, coûteuse et peu adaptée à l'explosion présente et à venir du nombre d'objets connectés et de services numériques. Par ailleurs, les solutions préconisées à cet effet ne tiennent pas compte des problèmes de communication entre les différents "hubs numériques". En outre, la multiplicité des besoins, des usages, des éditeurs de logiciel, des constructeurs d'objets connectés, des fournisseurs de services numérique en lignes, et des organismes de standardisation conduit à une multitude d'options peu propices à des échanges simples entre les différents composants de ces services (objets, services locaux, services web, etc.), entre les objets eux-mêmes et les utilisateurs de ces services (humains, animaux, robots, autres services, etc.).

Enfin, les architectures de communication traditionnelles fonctionnent en silo de sorte que les applications et les mécanismes impliqués dans les échanges entre humains sont différents de ceux mis en œuvre dans les échanges entre humains d'une part et objets connectés et services numériques d'autre part, ainsi qu'entre objets connectés. Dans le cas des échanges entre humains, le système de communication des architectures de communication traditionnelles s'attache à transmettre l'information en langage naturel (voix, vidéo, texte) sans la déformer. En outre, les échanges entre humains et objets connectés ou services numériques sont essentiellement réalisés à partir d'interfaces graphiques (GUI pour graphical user interface) ou en ligne (CLI pour command-line interface) qui guident les échanges et les restreignent aux possibilités des objets et services impliqués. Pour leur part, les échanges entre objets connectés impliquant ou non des services numériques sont réalisés à partir d'interfaces spécialisées conçues spécifiquement pour les langages informatiques (API), spécifiques à chaque objet et service, et interconnectés au moyen de plateformes parfois appelées "hubs numériques"

Par ailleurs, outre les obstacles dus au foisonnement des modes et des formats de communication des objets connectés et des services numériques, les architectures de communication traditionnelles rencontrent un problème de convergence qui provient du décalage des modes d'échanges entre humains, objets connectés et services numériques. En effet, bien que les d'interfaces utilisateur mises en œuvre dans les terminaux modernes de type "Smartphones" et tablettes facilitent les échanges entre le monde des humains et le monde du numérique au moyen de graphismes relativement aisés d'utilisation, ces interfaces sont conçues seulement pour canaliser l'expression des utilisateurs vers les capacités restreintes de leurs interlocuteurs numériques (objets et services connectés), leur demandant d'apprendre un 'langage' pour chacun des objets connectés ou des services numériques qu'ils souhaitent utiliser. Ces restrictions dans l'expression humaine constituent un obstacle significatif à la convergence homme/machine. En effet, dans les technologies actuelles les modes de commandes des objets connectés sont précis et fermés et utilisent une liste de commandes avec un lexique, une syntaxe et des paramètres figés, spécifiques à chaque objet ou famille d'objets. De ce fait, les utilisateurs humains de ces objets et services communicants doivent passer par des interfaces utilisateur en ligne (CLI - Command Line Interface) ou graphiques (GUI - Graphical User Interface) qui restreignent leur choix et qui les guident vers un nombre réduit d'options.

Les technologies de traitement numérique du langage naturel (Natural Language Processing - NLP) connues permettent déjà d'utiliser certains équipements ou services à partir du langage naturel, le plus souvent oral. Par exemple Siri© de Apple© ou Cortana© de Microsoft© proposent un service d'assistant virtuel permettant d'effectuer des opérations telles que la recherche d'informations sur Internet ou la réservation de billets de transport en utilisant des commandes vocales ; Nuance Communication© commercialise également des produits et services de support téléphonique à la clientèle à partir d'agents virtuels simulant des opérateurs humains ; Alexa© de Amazon© propose un service d'interface vocale pour des services tiers. Cependant, ces technologies constituent un ajout d'une interface complémentaire aux services que l'on peut appeler NLI (Natural Language Interface) par analogie aux interfaces graphiques (GUI) et en ligne de commande (CLI). En outre, bien qu'elles permettent de simplifier l'accès aux différents services qui les utilisent, ces technologies demandent des développements spécifiques à chaque service et fonction supportés et introduisent de nouvelles rigidités dans les usages, telle que l'utilisation de phrases clés par exemples. En plus, elles ne permettent pas de pallier le problème du foisonnement d'objets connectés et des services numérique utilisant des langages et des protocoles de communications différents.

EXPOSÉ DE L'INVENTION

Un but de l'invention est de pallier les inconvénients de l'art antérieur décrits ci-dessus.

Un autre but de l'invention est d'unifier les échanges que peuvent avoir les humains, les objets connectés et les services numériques entre eux (par exemple entre objets connectés, entre humains et objets, etc.) autour d'un langage naturel commun. D'autres utilisateurs peuvent également être concernés, en particulier les animaux et les robots.

Dans la suite de la description, on désignera par langage naturel cible (CNL - Core Natural Langage), le langage naturel commun utilisé, et par langage construit, un langage numérique composé de commandes, paramètres, codages des informations, conventions implicites ou explicites, etc. couplé à un ou plusieurs protocoles de communication permettant de communiquer avec un ou plusieurs objets connectés. Ces langages construits peuvent varier en fonction des objets et des applications.

Le langage naturel cible peut par exemple être une langue largement répandue telle que l'anglais, mais d'autres langages naturels sont également possibles. I l est choisi soit par configuration ou tout autre mode (vote, négociation...).

Ces buts sont atteints au moyen d'un procédé de communication entre une pluralité d'objets ou de services connectés ayant chacun un langage construit propre et étant susceptibles d'être source ou destinataire d'informations échangées via une plateforme intelligente de communication comportant une pluralité d'unités distribuées de traitement de l'information communiquant via au moins une unité bidirectionnelle d'échange en langage naturel et comprenant chacune au moins une unité logicielle et/ou matérielle d'adaptation de média et de protocole, au moins une unité logicielle et/ou matérielle de conversion de langage, et au moins une interface logicielle et/ou matérielle bidirectionnelle agencée entre l'unité bidirectionnelle d'échange en langage naturel et l'unité de traitement de l'information. Le procédé selon l'invention comporte les étapes suivantes :

• du côté émission,

-intercepter par l'unité logicielle et/ou matérielle d'adaptation de média et de protocole les informations en langage construit envoyées par l'objet ou le service connecté agissant en tant que source,

-convertir automatiquement lesdites informations reçues en langage construit propre à l'objet ou au service connecté émetteur vers un langage naturel cible préalablement sélectionné parmi une pluralité de langages naturels au moyen l'unité logicielle et/ou matérielle de conversion de langage,

-transmettre lesdites informations converties en langage naturel cible à l'interface logicielle et/ou matérielle bidirectionnelle qui les envoie à l'objet ou au service connecté destinataire via l'unité bidirectionnelle d'échange en langage naturel, et,

• du côté réception,

-recevoir les informations en langage naturel cible issues de l'objet ou du service connecté émetteur via l'unité bidirectionnelle d'échange en langage naturel à travers l'interface logicielle et/ou matérielle bidirectionnelle, puis,

-convertir automatiquement les informations reçues en langage naturel cible vers le langage construit utilisé par l'objet ou le service connecté destinataire au moyen de l'unité logicielle et/ou matérielle de conversion de langage, puis,

-fournir les informations en langage construit à l'objet ou au service connecté destinataire via l'unité logicielle et/ou matérielle d'adaptation de média et de protocole.

Le procédé selon l'invention comporte en outre une étape d'analyse des informations échangées en langage naturel cible et une étape de résolution des ambiguïtés et des incohérences relevées au moyen d'une unité logicielle et/ou matérielle de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées.

Ladite étape de résolution des ambiguïtés et des incohérences consiste à vérifier si les informations échangées en langage naturel cible entre les objets ou les services connectés nécessitent une résolution d'ambiguïté lexicale, syntactique ou sémantique, un complément d'information ou encore une confirmation implicite ou explicite, ainsi que la mise en œuvre éventuelle de ces résolutions d'ambiguïté, une demande d'informations et confirmations.

Le procédé selon l'invention comporte en outre une étape de conversion d'un langage naturel utilisé par une source ou par un destinataire vers le langage naturel cible sélectionné, au moyen d'une unité logicielle et/ou matérielle bidirectionnelle d'alignement des langages

Dans un mode particulier de mise en œuvre du procédé selon l'invention, au moins un ensemble d'objets ou de services connectés est relié à la plateforme intelligente via au moins une passerelle connectée ayant un langage construit propre et étant susceptible d'être source ou destinataire d'informations, ladite passerelle étant reliée à au moins une unité distribuée de traitement de l'information par l'unité logicielle et/ou matérielle d'adaptation de média et de protocole et est destinée à assurer au moins l'une des fonctions suivantes:

-adaptation des protocoles réseaux des objets ou des services connectés à très bas débit, très basse consommation électrique et longue distance,

-adaptation des protocoles réseaux des objets ou des services connectés à faible portée,

-gestion centralisée d'un parc d'objets ou de services connectés partageant des similarités matérielles et/ou fonctionnelles,

-regroupement et traitements intermédiaires des données dans un environnement maîtrisé et sécurisé ;

-exposition d'une interface de programmation privée ou publique documentée et stable API (Application Programming Interface) pour le pilotage des objets ou des services connectés.

Le procédé selon l'invention comporte en outre une procédure d'apprentissage du langage naturel cible utilisé de manière à améliorer les performances de conversion entre les langages construits propre aux objets, aux services connectés et à la passerelle connectée d'une part, et le langage naturel cible d'autre part, ainsi que des procédures de résolution d'ambiguïtés et d'incohérences des messages échangés en langage naturel cible. Préférentiellement, ladite procédure d'apprentissage est exécutée automatiquement, en tâche de fond, sans interférer directement avec les étapes de conversion et de résolutions d'ambiguïté et comporte les étapes suivantes :

-classer les informations échangées en langage naturel cible en fonction des différents objets, services connectés ou passerelles connectées,

-analyser les contenus des informations échangées en langage naturel cible,

-enrichir progressivement au moins une base d'information utilisée par les unités logicielles et/ou matérielles de conversion de langage Dans le procédé selon l'invention, les services d'échange d'information en langage naturel sont soit des services de SMS (Short Message Service), soit des services MMS (Multimedia Message Service), soit des services de courriels, soit des services de messagerie instantanée, soit des forums de discussion, soit des réseaux sociaux publics ou professionnels, ou encore des services de communication dédiés.

Le procédé selon l'invention est mis en œuvre via une plateforme intelligente de communication dans laquelle l'unité logicielle et/ou matérielle d'adaptation de média et de protocole est configurée pour intercepter les informations envoyées par un objet ou un service connecté en un langage construit propre à cet objet ou ce service connecté agissant en tant que source , et d'autre part pour fournir les informations échangées en un langage construit propre à un objet ou à un service connecté lorsque cet objet ou ce service est destinataire desdites informations,

-l'unité logicielle et/ou matérielle de conversion de langage est configurée, d'une part, pour convertir automatiquement lesdites informations reçues en langage construit propre à l'objet ou au service connecté émetteur vers un langage naturel cible préalablement sélectionné parmi une pluralité de langages naturels, et d'autre part, pour convertir automatiquement les informations échangées en langage naturel cible destinées à un objet ou à un service connecté destinataire desdites informations vers le langage construit utilisé par cet objet ou par ce service connecté destinataire, -l'unité logicielle et/ou matérielle d'interface bidirectionnelle est configurée, d'une part, pour transmettre les informations en langage naturel cible à l'unité bidirectionnelle d'échange en langage naturel pour qu'elle les envoie à l'objet ou au service connecté destinataire, et d'autre part, pour recevoir les informations en langage naturel cible émises par les objets et les services connectés émetteurs à travers l'unité bidirectionnelle d'échange en langage naturel.

Ladite plateforme comporte en outre en outre au moins une unité logicielle et/ou matérielle de contrôle et de résolution d'ambiguïté et de pertinence et une unité logicielle et/ou matérielle bidirectionnelle d'alignement des langages, Γ unité logicielle et/ou matérielle de contrôle et de résolution d'ambiguïté et de pertinence étant apte à vérifier si les informations échangées en langage naturel cible entre les objets ou les services connectés nécessitent une résolution d'ambiguïté lexicale, syntactique ou sémantique, un complément d'information ou encore une confirmation implicite ou explicite, ainsi que la mise en œuvre éventuelle de ces résolutions d'ambiguïté, demandes d'information et confirmations, tandis que l'unité logicielle et/ou matérielle bidirectionnelle d'alignement des langages est chargée de la conversion d'un langage naturel utilisé par une source ou par un destinataire vers un langage naturel cible préalablement sélectionné.

La plateforme selon l'invention est intégrée dans un système de de communication entre une pluralité d'objets ou de services connectés ayant chacun un langage construit propre et étant susceptibles d'être source ou destinataire d'informations échangées via ladite plateforme intelligente. Ce comporte en outre une passerelle connectée agencées entre une partie desdits objets ou services connectés destinée à assurer au moins l'une des fonctions suivantes :

-adaptation des protocoles réseaux des objets ou services connectés à très bas débit, très basse consommation électrique et longue distance,

-adaptation des protocoles réseaux des objets ou services connectés à faible portée,

-gestion centralisée d'un parc d'objets ou services connectés partageant des similarités matérielles et/ou fonctionnelles, -regroupement et traitements intermédiaires des données dans un environnement maîtrisé et sécurisé ;

-exposition d'une interface de programmation privée ou publique documentée et stable API (Application Programming Interface).

Ladite passerelle connectée a un langage construit propre, est reliée à au moins une unité distribuée de traitement de l'information par l'unité logicielle et/ou matérielle d'adaptation de média et de protocole, et est susceptible d'être source ou destinataire des informations échangées. BRÈVE DESCRIPTION DES DESSINS

D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles :

-la figure 1 est un schéma général illustrant une plateforme de communication selon l'invention,

-la figure 2 représente schématiquement une architecture de la plateforme de la figure 1 montrant les différentes couches de traitement des informations échangées entre une source et un destinataire via la plateforme de la figure 1,

-la figure 3 illustre schématiquement un environnement technique des éléments composant la plateforme de la figure 1,

-la figure 4 représente schématiquement et partiellement les unités de la plateforme 1 permettant de réaliser des échanges d'informations entre un humain et un objet connecté,

-la figure 5 représente schématiquement et partiellement les unités de la plateforme 1 permettant de réaliser des échanges d'informations entre deux objets connectés,

-les figures 6 et 7 représentent respectivement des schémas fonctionnels illustrant de façon détaillée les étapes de traitement des informations échangées entre un humain et un objet connecté via la plateforme selon l'invention, -les figures 8 et 9 représentent des schémas fonctionnels illustrant de façon détaillée les étapes de traitement des informations échangées entre deux objets connectés via la plateforme selon l'invention,

-les figures 10A et 10B illustrent respectivement les étapes essentielles des traitements appliqués à un message transmis par une source distante à un destinataire, et les étapes essentielles des traitements appliqués à un message en langage naturel cible transmis par le destinataire en réponse au message reçu de ladite source distante,

-la figure 11 est un organigramme détaillé illustrant l'alignement du langage naturel de la source distante sur un langage naturel cible sélectionné,

-la figure 12 est un organigramme détaillé de l'étape d'alignement des unités utilisées par la source distante sur celles utilisées par le destinataire,

-la figure 13 est un organigramme détaillé de l'étape d'alignement des références de date, d'heure et de durée utilisées par la source distante sur celles utilisées par un objet connecté ou un service numérique,

-la figure 14 est un organigramme détaillé de l'étape d'alignement des références de date, d'heure et de durée utilisées par un destinataire, émetteur d'un message en langage naturel cible, sur celles utilisées par la source distante de la figure 10,

-la figure 15 est un organigramme détaillé de l'étape d'alignement des unités utilisées par le destinataire, émetteur d'un message en langage naturel cible, sur celles utilisées par la source distante de la figure 10,

-la figure 16 est un organigramme détaillé de l'étape d'alignement du langage naturel cible du destinataire, émetteur vers le langage naturel de la source distante de la figure 10,

-la figure 17 représente une vue détaillée d'une unité de résolution d'ambiguïté et de pertinence de la plateforme selon l'invention,

-la figure 18 représente un organigramme des étapes de contrôle d'ambiguïté et de pertinence d'un message en langage naturel cible d'un utilisateur distant au moyen de l'unité de la figure 17, -la figure 19 représente un organigramme des étapes de transformation des informations en langage naturel cible vers un langage construit utilisé par un objet connecté ou un service numérique,

-la figure 20 représente un organigramme des étapes de transformation des informations en langage construit (format numérique de pilotage des objets connectés ou format numérique de pilotage des services numériques) en langage naturel cible,

-la figure 21 illustre schématiquement les étapes d'un échange relatif à une demande d'assistance entre deux objets communicants,

-la figure 22 illustre schématiquement un système de communication entre une pluralité d'objets ou de services connectés destiné à mettre en œuvre le procédé selon l'invention.

EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS

La figure 1 représente une vue générale montrant des sources et des destinataires de différentes natures susceptibles de communiquer via une plateforme 1 selon l'invention. Ces sources et ces destinataires peuvent être soit des humains 2 munis d'un dispositif de communication tel que par exemple un ordinateur, une tablette 4, ou un Smartphone, soit des robots connectés 6, ou encore des animaux 7 munis de boîtiers électroniques comportant des moyens de connexion à la plateforme 1 et permettant de transmettre aux animaux des informations représentant des consignes, ou de recevoir de ces animaux informations relatives à leur comportement par exemple. Les humains peuvent s'exprimer en langage naturel en parlant dans un microphone avec transcription automatique en texte 8, ou par texte saisi au moyen d'un clavier classique 10 ou d'un clavier en Braille 12 reliés à un dispositif de communication. Ils peuvent également s'exprimer au moyen d'un transcripteur de langage de signes 14 ou par détection d'activité cérébrale 16.

Les objets connectés peuvent être de différentes natures, tels que par exemple des robots industriels, des robots de service, des capteurs miniaturisés associés à des habits 17 tels que par exemple des combinaisons à usage professionnel, des capteurs et actionneurs localisés dans des locaux d'habitation 34, des véhicules 36, des usines et bureaux 31, dans le domaine public 32, etc. Les sources et les destinataires peuvent en outre être des services numériques fournis par des serveurs distants 30.

Dans la suite de la description, le terme « langage naturel » désignera un langage naturellement utilisé par les êtres humains tel que l'anglais, le français, le chinois mandarin, etc., et « langage naturel cible » désignera un langage naturel sélectionné parmi plusieurs langages naturels en fonction de sa zone d'utilisation, de son étendue d'utilisation ou encore de la facilité de son apprentissage automatique. Il peut être modifié par configuration, élection ou tout autre moyen pour tenir compte des spécificités des sources et des destinataires et de l'application envisagée.

On désignera par langage construit un langage formel comportant un ensemble de symboles qui servent à en construire les différentes structures. Il est défini par une grammaire formelle, telle que les grammaires algébriques et les langages informatiques, et est susceptible d'être analysé par des automates. Un exemple type de langage construit sont les interfaces de programmation applicative (APIs - Application Programming Interface) constituées d'un ensemble de classes, de fonctions, de paramètres, de conventions de codage, etc. par lesquelles les objets connectés et les services numériques offrent des services à d'autres applications logicielles.

La figure 2 représente une architecture en couches de la plateforme 1 selon l'invention. Cette architecture comporte une première couche de contrôle 40 qui regroupe des unités qui assurent les fonctions classiques de contrôle d'accès à la plateforme 1, en particulier, les fonctions centralisées d'authentification et d'autorisation d'accès pour les utilisateurs de toute nature, de comptage pour des raisons de statistiques, de facturation, d'annuaires, et de sécurité, et une deuxième couche regroupant des unités de gestion 42 qui assurent les fonctions centralisées de supervision des communications, de sélection d'un langage naturel cible, de mises à jour des logiciels de traitement des données échangées via la plateforme 1, de calculs statistiques, de gestion de la disponibilité et des améliorations. Les unités de contrôle 40 et de gestion 42 sont par exemple des applications logicielles téléchargées à partir de serveurs locaux ou distants contrôlés par le gestionnaire de la plateforme 1. Les fonctions décrites ci-dessus peuvent résider au sein de la couche de contrôle 40 ou à l'extérieur de cette couche et être interfacées avec elle. La couche de contrôle 40 assure également la fonction de traitement des exceptions en cas d'échec d'une procédure de résolution d'ambiguïtés constatées au cours des échanges d'informations via la plateforme 1 ou en cas d'échec d'une transaction, par exemple, en cas de refus répétés par un objet connecté de fournir une information ou d'exécuter une commande.

L'architecture de la figure 2 comprend une unité bidirectionnelle d'échange en langage naturel 50 connectée aux dispositifs de communication associés à chaque source et à chaque destinataire enregistrés sur la plateforme 1, et un ensemble d'unités de traitement comprenant une unité logicielle et/ou matérielle d'adaptation de média et de protocole 52, une unité logicielle et/ou matérielle de conversion de langage 54, une unité logicielle et/ou matérielle de contrôle et de résolution d'ambiguïté et de pertinence 56, une unité logicielle et/ou matérielle bidirectionnelle 58 de conversion d'un langage naturel utilisé par une source ou par un destinataire en un langage naturel cible sélectionné, et d'alignement des unités de valeurs physiques et des unités de temps contenus dans les informations échangées, et une interface bidirectionnelle 60 qui réalise l'adaptation entre l'unité bidirectionnelle d'échange en langage naturel 50 et chaque unité bidirectionnelle 58 de conversion d'un langage naturel.

Les unités logicielle et/ou matérielle d'adaptation de média et de protocole 52-60, peuvent être implémentées de façon répartie sur les terminaux de communication et de traitement de données (serveurs, ordinateurs, tablettes, Smartphones, boîtiers, ...) utilisés par chaque source et par chaque destinataire connecté à la plateforme 1, ou encore implémentées au sein d'une ou plusieurs plateformes locales ou centralisées, ou encore partiellement implémentées sur les terminaux, des plateformes locales et des plateformes centralisées.

Pour des raisons de clarté, dans la suite de la description, des références identiques désigneront les éléments qui assurent des fonctions identiques dans les différentes implémentations et applications de l'invention. Les différentes unités de l'architecture de la figure 2 seront désignées par les acronymes suivants :

• CTRL (Control layer, en anglais), pour la couche de contrôle 40,

• MNGT (Management module, en anglais) pour la couche regroupant des unités de gestion 42 qui assurent les fonctions centralisées de supervision des communications, de sélection d'un langage naturel cible commun aux humains, aux objets connectés et aux services numériques, de mises à jour des logiciels de traitement des données échangées via la plateforme 1, de calculs statistiques, de gestion de la disponibilité et des améliorations...),

· NLXS 50 (Natural Langage eXchange Services, en anglais) pour les unités bidirectionnelles d'échange en langage naturel,

• MPA-x 52 (Media and Protocol Adaptor, en anglais) pour les unités d'adaptation de média et de protocole, x indiquant le type de source ou de destinataire auquel est associée l'unité MPA, x = H pour les humains, x = 0 pour les Objet connectés, et x = S pour les services numériques),

• NLAC 54 (Natural Langage to API Converter, en anglais) pour les unités de conversion de langage,

• LARC 56 (Langage Ambiguity and Relevance Controller en anglais) pour les unités logicielles et/ou matérielles de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées,

• LUTA 58 (Langage, Units and Time Alignment, en anglais) pour les unités, logicielles et/ou matérielles, bidirectionnelles de conversion d'un langage naturel utilisé par une source ou par un destinataire dans le langage naturel cible sélectionné

· IF_NLX 60 (Interface with the Natural Language eXchange services, en anglais), pour les interfaces bidirectionnelles.

Comme cela est illustré par la figure 3, les différentes unités de la plateforme de la figure 1 peuvent accéder à des ressources fournies par des serveurs distants tels que par exemple une base linguistique 70, un service de traduction 72 ou un service d'annuaire 74. Les différentes unités se connectent automatiquement en cas de besoin à ces serveurs distants 70, 72 74 via une unité de description 76 de l'objet connecté ou du service numérique pour obtenir :

• des éléments de description de l'objet connecté ou du service numérique dont elles ont la charge : identité, description, capacités, paramètres, unités, syntaxe, API, etc.

• des ressources extérieures de type "base linguistique" telles que services de traduction, bases d'ontologies et listes de synonymes, hyponymes, hyperonymes, corpus de langage naturel et bases de données diverses pour accomplir ou parfaire leurs fonctions respectives,

· d'autres services, par exemple des services d'annuaire, de traduction en ligne et des bases de données diverses peuvent également être utilisés.

La figure 4 représente schématiquement la répartition des unités composant l'architecture de la plateforme 1 du côté d'une source 2, un être humain, muni d'un premier ensemble terminal de communication et de traitement de données 82 (un ordinateur, une tablette ou un Smartphone par exemple) et du côté d'un destinataire 6, une station météo par exemple, équipée de fonctions de communication et de traitement de données 86 et complétée par des fonctions hébergées par une plateforme centrale 85.

L'ensemble terminal de communication et de traitement de données pour l'utilisateur humain 82 comporte une interface 88 de type clavier, écran, microphone, écouteur, caméra, etc. vers l'utilisateur, une unité MPA 52 d'adaptation de média et de protocole, une interface IF_NLX 60 pour communiquer en langage naturel via le module NLXS 50 et un émetteur/récepteur vers le réseau de transit 84.

L'ensemble de communication et de traitement de données pour l'objet connecté 86 comporte les dispositifs nécessaires pour échanger et traiter les messages en langage construit sur le réseau de rattachement.

La plateforme centrale 85 comporte un émetteur/récepteur 87 vers le réseau de rattachement de l'objet connecté, une unité MPA 52 d'adaptation de média et de protocole, une unité NLAC 54 de conversion de langage, une unité LARC 56 de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées, une unité LUTA 58 de conversion d'un langage naturel utilisé par la source en langage naturel cible, une interface IF_NLX 60 pour communiquer en langage naturel via le module NLXS 50 et un émetteur/récepteur vers le réseau de transit 84.

La figure 5 représente schématiquement la répartition des unités composant l'architecture de la plateforme 1 du côté d'une source 2, une chaudière connectée équipée de fonctions de communication et de traitement de données 82 et complétée par des fonctions hébergées par une plateforme centrale 85, et du côté d'un destinataire 6, une station météo par exemple, équipée de fonctions de communication et de traitement de données 86 et complétée par des fonctions hébergées par une plateforme centrale 85.

Les fonctions de communication et de traitement de données 82 et 86 comportent les dispositifs nécessaires pour échanger et traiter les messages en langage construit sur le réseau de rattachement.

En fonctionnement, les unités bidirectionnelles d'échange en langage naturel NLXS 50 assurent les échanges des informations en langage naturel entre les différents interlocuteurs humains, robots, objets ou plateformes de services numériques. Ces unités comportent des moyens de communication connus, tels que des services de SMS (Short Message Service) ou MMS (Multimedia Message Service), des services de courriels, des services de messagerie instantanée ou toute autre application adaptée pour échanger des informations en langage naturel.

Les unités d'adaptation de média et de protocole MPA-x 52 tels que par exemple, un adaptateur radio LPWAN (low power wide area network) avec ses protocoles de transport (COAP, MQTT...), une interface wifi ou une interface Ethernet avec ses drivers logiciels et ses protocoles de transport (HTTP, TLS, ...) font le lien entre les utilisateurs (humains, objets ou services) connectés à la plateforme 1 et les unités NLAC 54. Dans le cas d'utilisateurs humains, ces unités MPA-H 52 prennent en charge des échanges écrits (textes), vocaux ou de tout autre type selon la nature de l'interaction (par exemple le langage des signes). Dans le cas des objets communicants et des services numériques, les unités MPA-0 52 implémentent le protocole de commande numérique des objets (API, pour Application Programming Interface) et l'adaptation éventuelle au média avec lequel les objets sont connectés. Ces MPA-0 52 sont par exemple des fonctions logicielles qui implémentent en général le côté 'client' de l'interface avec l'objet connecté, celui-ci étant considéré comme un serveur (de données) dans une architecture client/serveur par exemple de type REST (representational state transfer).

Les unités de conversion de langage NLAC 54 assurent la transformation entre, d'un côté, les informations en langage naturel cible, et de l'autre côté, les informations au format numérique de pilotage des objets connectés ou au format des données échangées avec des services numériques. Des informations complémentaires telles que images, sons, fichiers, indicateurs d'émotions ou de prosodie par exemple, peuvent optionnellement être adjoints aux informations en langage naturel.

Les unités de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées LARC 56 sont installées dans les récepteurs des sources 2 et des destinataires 6 et sont configurées pour analyser les informations reçues depuis les unités bidirectionnelles LUTA 58 d'une part et depuis unités de conversion de langage NLAC 54 afin de déterminer le niveau d'ambiguïté des messages échangés en langage naturel cible et de s'assurer que les unités NLAC 54 seront capables d'effectuer correctement la conversion de langage souhaitée. Dans le cas où les unités LARC 56 jugent que le niveau d'ambiguïté ou d'incohérence est trop élevé, elles effectuent une procédure de résolution d'ambiguïté, par exemple en demandant à la source du message de répéter la requête ou encore en lui demandant de la reformuler différemment. En cas d'échecs répétés de cette procédure, les unités LARC 56 signalent l'abandon de l'échange à la source des informations ainsi qu'aux unités de contrôle 40 et aux unités de gestion 42.

Les unités bidirectionnelles LUTA 58 de conversion d'un langage naturel utilisé par une source ou par un destinataire 6 en un langage naturel cible sélectionné sont configurées pour convertir, lorsque cela est nécessaire, le langage des messages de manière à utiliser le langage naturel de l'utilisateur humain ou un langage naturel cible sélectionné pour communiquer avec des objets et des services numériques. Ces unités bidirectionnelles LUTA 58 effectuent également la conversion des unités (par exemple degré Celsius/degré Fahrenheit ou encore centimètres/pouces, etc.), des dates et de l'heure (en particulier les fuseaux horaires et le changement de jour). Les interfaces bidirectionnelles IF_NLX 60 réalisent l'adaptation entre les unités NLXS 50 et les unités LUTA 58. En particulier, ils choisissent le média le plus adapté parmi les unités NLXS 50 lorsqu'il y en a plusieurs (par exemple un service SMS plutôt qu'un service courriel) et assurent l'émission et la réception des messages numériques vers et depuis ces différents média. Les interfaces IF_NLX 60 sont par exemple des fonctions standard telles que client courriel (google©, outlook©, yahoo©...), client chat de microsoft skype©, google hangout©, client sms/mms, etc.

Les unités NLAC 54, LARC 56 et LUTA 58 peuvent optionnellement se connecter automatiquement aux serveurs distants 70-74 pour obtenir, en temps réel ou en différé, des ressources extérieures telles que des services de traduction, des bases d'ontologies et des listes de synonymes, hyponymes, hyperonymes, corpus de langage naturel et des bases de données diverses.

La figure 6 décrit en détail les traitements successifs de la requête de la figure 5 par les différentes unités de l'architecture de la plateforme 1.

A l'étape 200, la requête formulée par la source 2 est interceptée par l'unité MPA-H d'adaptation de média et de protocole 52 affectée à la source 2.

Dans l'exemple de la figure 6, le langage de la requête interceptée est un langage naturel humain. Dans ce cas, à l'étape 200, l'unité MPA-H 52 transmet la requête interceptée « Quelle température fait-il maintenant ? » à l'interfaces bidirectionnelles IF-NLX 60 sans modifications.

A l'étape 202, l'interface bidirectionnelle IF-NLX 60 transmet la requête à l'unité bidirectionnelle d'échange en langage naturel NLXS 50. La transmission est réalisée par exemple au moyen d'un service de courriel vers l'adresse courriel my_weatherstation@messagerie.com, « messagerie » étant le nom du service de messagerie électronique utilisé par la station météorologique.

Notons que l'unité NLXS 50 peut également utiliser un service SMS, un service de messagerie instantanée ou toute autre application qui permet d'échanger des informations numériques en langage naturel et en temps réel ou en temps très peu différé. Dans l'exemple de la figure 6, l'unité NLXS 50 est un service courriel public auprès duquel la station météo 6 est préalablement enregistrée avec l'adresse courriel my_weatherstation@messagerie.com.

L'unité NLXS 50 reçoit la requête de l'interface bidirectionnelle IF-NLX 60 sur le client courriel my_weatherstation@messagerie.com et transmet ladite requête à l'interface bidirectionnelle IF-NLX 60 implémentée du côté de la station météo 6 à l'étape 204.

A l'étape 206, l'interface bidirectionnelle IF-NLX 60 implémentée du côté de la station météo 6 reçoit la requête sur le client courriel my_weatherstation@messagerie.com et transmet ladite requête à l'unité bidirectionnelle LUTA 58 implémentée du côté de la station météo 6.

A l'étape 208, à l'unité bidirectionnelle LUTA 58 reçoit la requête « Quelle température fait-il aujourd'hui ? » et effectue la conversion du langage naturel utilisé, le français dans ce cas, au langage naturel cible sélectionné, qui est par exemple l'anglais dans ce cas, puis transmet la requête convertie en anglais (par exemple « how warm is it today ? ») à l'unité de contrôle LARC 56 implémentée du côté de la station météo 6.

A l'étape 210, ladite unité de contrôle LARC 56 reçoit la requête, l'analyse et, en cas d'ambiguïté, exécute une procédure de résolution d'ambiguïté et de pertinence des informations échangées. En cas de non ambiguïté, l'unité de contrôle LARC 56 transmet la requête en langage naturel cible, l'anglais, à l'unité de conversion de langage NLAC 54 installée du côté de la station météo 6.

A l'étape 212, l'unité NLAC 54 convertit la requête en langage naturel cible « How warm is it today ? » en langage construit en utilisant la commande « getmeasure » de l'API associée à la station météo 6 : http://my_weatherstation.com/api/getmeasure,access_token-[TO KEN]&device_id-

[DEVICEID]&type-Temperature. ». L'unité NLAC 54 transmet ensuite la commande de mesure de température à l'unité MPA-0 d'adaptation de média et de protocole 52 implémentée côté station météo 6. A l'étape 214, ladite unité MPA-0 52 d'adaptation de média et de protocole transmet la requête à la station météo 6 sur le média et le protocole utilisé pour joindre la station météo 6.

La figure 7 illustre la réponse de la station météo 6 à la requête de la source 2.

A la réception de la commande de mesure de température, la station météo 6 effectue la mesure demandée et génère le message {" status" :"ok", "body" :[{ "beg_time " .-123456500, "value" : [69.8]}]}, puis transmet ce message, à l'étape 300, à l'unité MPA-0 50.

A l'étape 302, l'unité MPA-0 50 reçoit le message de la station météo 6 effectue une adaptation au média (radio, Ethernet, etc.) et aux protocoles de transport (http, tls, mqtt, coap...) et le transmet à l'unité NLAC 54 installée du côté de la station météo 6.

A l'étape 304, ladite unité NLAC 54 reçoit le message en langage construit transmis par l'unité MPA-0 50, le convertit automatiquement en langage naturel cible, l'anglais dans cet exemple, « the current température is 69.8°F », et transmet le message en langage naturel cible à l'unité de contrôle LARC 56 installée du côté de la station météo 6.

A l'étape 306, l'unité de contrôle LARC 56 reçoit le message en langage naturel cible «the current température is 69.8°F», et le transmet sans traitement à l'unité bidirectionnelle LUTA 58 installée du côté de la station météo 6.

A l'étape 308 l'unité bidirectionnelle LUTA 58 reçoit le message en langage naturel cible «the current température is 69.8°F» et effectue la conversion du langage naturel cible en langage naturel de la source 2, le français dans ce cas, puis effectue une conversion de l'unité de mesure de degrés Fahrenheit en degrés Celsius pour obtenir le message en langage naturel utilisateur « la température est 21 degrés Celsius », et transmet ensuite ce message à l'interface bidirectionnelle IF-NLX 60 coopérant avec la station météo 6. A l'étape 310, l'interface bidirectionnelle IF-NLX 60 envoie le message en langage naturel utilisateur vers le client dont l'adresse courriel est alice@aliceaddress.com.

A l'étape 312, l'unité NLXS 50 reçoit le message de l'interface bidirectionnelle IF-NLX 60 et le retransmet vers le client courriel à l'adresse source@sourceaddress.com.

A l'étape 314, l'interface bidirectionnelle IF-NLX 60 en charge de la source 2 transmet le contenu du message en langage naturel utilisateur « la température est 21 degrés Celsius » à l'unité MPA-H d'adaptation de média et de protocole 52 installée dans le terminal de la source 2.

A l'étape 316, l'unité MPA-H 52 délivre le message en langage naturel utilisateur « la température est 21 degrés Celsius » à la source 2, soit par un message vocal, soit par un affichage sur l'écran du terminal de la source 2.

La figure 8 représente les étapes des traitements appliqués à une requête envoyée par une chaudière connectée à la station météo. La chaudière peut par exemple être programmée pour requérir des informations à la station météo 6 à intervalles réguliers afin d'effectuer un réglage automatique de ses paramètres de fonctionnement en adaptant sa puissance à la température mesurée.

La chaudière et la station météo échangent les messages au moyen de leurs ensembles de communication et de traitement de données respectifs 85 représentés à la figure 5. A l'étape 402, la chaudière 400 transmet à l'unité d'adaptation de média et de protocole MPA-0 52 une requête dans le langage construit et en utilisant le média et les protocoles qu'elle implémente : « GET : http://xxxx/api/gettemperature? ».

A l'étape 404, l'unité MPA-0 52 transmet la requête dans le langage construit de la chaudière à l'unité de conversion de langage NLAC 54 en charge de la chaudière et qui la convertit automatiquement, à l'étape 406, en un message en langage naturel cible préalablement sélectionné, l'anglais par exemple : « what is the température now ? », puis transmet la requête en langage naturel cible à l'unité LARC 56 de contrôle et de résolution d'ambiguïté et de pertinence. A l'étape 408, l'unité LARC 56 transmet le message en langage naturel cible « what is the température now ? » sans modification à l'unité LUTA 58 de conversion de langage naturel en charge de la chaudière 400.

A l'étape 410, l'unité LUTA 58 transmet le message en langage naturel cible « what is the température now ? » sans modification à l'interfaces bidirectionnelle IF-NLX 60 en charge de la chaudière 400.

A l'étape 412, l'interface bidirectionnelle IF-NLX 60 transmet le message en langage naturel cible à l'unité NLXS 50 pour être remis au client courriel d'adresse my_weatherstation@messagerie.com, « messagerie » étant le nom du service de messagerie utilisée par la station météo.

A l'étape 414, l'unité NLXS 50 d'échange en langage naturel reçoit le message en langage naturel cible et le transmet à l'interface bidirectionnelle IF-NLX 60 en charge de la station météo 6.

L'interface bidirectionnelle IF-NLX 60 reçoit le message sur le client courriel my_weatherstation@messagerie.com et le transmet, à l'étape 416, à l'unité LUTA 58 installée côté station météo 60.

A l'étape 418, l'unité LUTA 58 transmet le message en langage naturel cible « what is the température now ? » sans modification à l'unité LARC 56 en charge de la station météo 6.

A l'étape 420, ladite unité LARC 56 effectue une analyse d'ambiguïté du message reçu en langage naturel cible.

Si l'unité LARC 56 juge que le message reçu n'est pas ambigu et est cohérent avec le rôle et les capacités de l'objet dont elle est chargée, elle le transmet sans modification à l'unité NLAC 54 de la station météo 6.

A l'étape 422, l'unité NLAC 54 de la station météo 6 effectue une conversion du message reçu en langage naturel cible « what is the température now ? » vers le langage construit de la station météo, en l'occurrence une commande

« getmeasure » : GET: http://my_weatherstation.com/api/getmeasure,access_token-

[TOKEN]&device_id-[DEVICEID]&type-Temperature » et transmet le message obtenu à l'unité d'adaptation de média et de protocole MPA-0 52 en charge de la station météo 6. A l'étape 424, l'unité MPA-0 52 transfère la commande en langage construit à la station météo 6 en utilisant les protocoles et le média utilisés par la station météo 6.

A la réception de cette commande, la station météo 6 génère une réponse à la requête.

La figure 9 représente les étapes des traitements appliqués à la réponse à envoyer par la station météo 6 à la chaudière.

A l'étape 500, la station météo envoie la température mesurée par la réponse à la commande « getmeasure », exprimée en langage construit de l'API qui lui est associée, à son unité MPA-0 52, en utilisant les protocoles et le média utilisés par la station météo 6.

A l'étape 502, l'unité MPA-0 52 transmet le message reçu en langage construit de la station météo à l'unité de conversion de langage NLAC 54 en charge de la station météo 6.

A l'étape 504, l'unité NLAC 54 convertit automatiquement le message en langage construit en un texte en anglais qui est le langage naturel cible préalablement sélectionné : « the current température is 69.8°F », et transmet la réponse, en anglais, à l'unité LARC 56 en charge de la station météo 6.

A l'étape 506, l'unité LARC 56 en charge de la station météo 6 transmet le message en langage naturel cible « the current température is 69.8°F » sans modification à l'unité LUTA 58.

A l'étape 508, l'unité bidirectionnelle LUTA 58 reçoit le message en langage naturel cible «the current température is 69.8°F», conserve le message en anglais puisque c'est la langue naturelle utilisée par la chaudière, puis effectue, si cela est nécessaire, une conversion de l'unité de mesure de degrés Fahrenheit en degrés Celsius pour obtenir le message en langage naturel cible « the current température is 21°C », et transmet ensuite ce message à l'interface bidirectionnelle IF-NLX 60 en charge de la station météo 6.

A l'étape 510, l'interface bidirectionnelle IF-NLX 60 de la station météo 6 transmet ce message en langage naturel cible à l'unité NLXS 50 d'échange en langage naturel pour remise à l'adresse courriel heather@heatheraddress.com (adresse courriel attribuée à la chaudière)

A l'étape 512, l'unité NLXS 50 reçoit le message en langage naturel cible et le retransmet à l'interface bidirectionnelle IF-NLX 60 en charge de la chaudière. Celle-ci le transmet, à l'étape 514, à l'unité LUTA 58 en charge de la chaudière.

A l'étape 516, l'unité LUTA 58 transmet le message en langage naturel cible « the current température is 21°C » sans modification à l'unité LARC 56.

A l'étape 518, ladite unité LARC 56 effectue une analyse d'ambiguïté du message reçu.

Si l'unité LARC 56 juge que le message reçu en langage naturel cible n'est pas ambigu et est cohérent, elle le transmet sans modification à l'unité NLAC 54 en charge de la chaudière.

A l'étape 520, l'unité NLAC 54 en charge de la chaudière 400 convertit la réponse en langage naturel cible « the current température is 21°C » vers le langage construit de la chaudière, en l'occurrence la réponse à la commande 'gettemperature' : {"status" : "ok", "body" :[{ "beg_time " .-123456500, "value" : [21.0]}]}, et transmet la réponse convertie à l'unité d'adaptation de média et de protocole MPA-0 52 en charge de la chaudière.

A l'étape 522, l'unité MPA-0 52 transmet ce message à la chaudière en utilisant les protocoles et le média utilisés par la chaudière 400.

La figure 10A illustre les étapes essentielles des traitements appliqués par l'unité LUTA 58 à un message transmis en langage naturel par une source distante à un destinataire via l'unité IF-NLX 60 en charge de la source.

A l'étape 598, le message de la source distante est transmis en langage naturel à l'unité LUTA 58 via l'unité IF-NLX 60.

A l'étape 600 l'unité LUTA 58 convertit le langage naturel de la source distante au langage naturel cible sélectionné.

A l'étape 602 l'unité LUTA 58 aligne les unités utilisées par la source distante sur celles utilisées par le destinataire. A l'étape 604 l'unité LUTA 58 aligne les références de date, d'heure et de durée utilisées par la source distante sur celles utilisées par le destinataire.

A l'étape 606, l'unité LUTA 58 transmet le message traité par les étapes 598-604 vers l'unité LARC 56 du destinataire.

La figure 10B illustre les étapes essentielles des traitements appliqués par l'unité LUTA 58 au message en langage naturel cible transmis par une source locale vers un destinataire.

A l'étape 610 le message en langage naturel cible est transmis à l'unité LUTA 58 via l'unité LARC 56 en charge de l'objet connecté local.

A l'étape 612, l'unité LUTA 58 aligne les références de date, d'heure et de durée utilisées dans le message sur celles utilisées par le correspondant distant.

A l'étape 614, l'unité LUTA 58 aligne les unités utilisées dans le message sur celles utilisées par le correspondant distant.

A l'étape 616, l'unité LUTA 58 convertit le message en langage naturel cible au langage naturel utilisé par le correspondant distant.

A l'étape 620 l'unité LUTA 58 transmet le message en langage naturel utilisé par le correspondant distant vers l'unité IF-NLX 60.

La figure 11 est un organigramme détaillé de l'étape 600 de conversion du langage naturel de la source distante au langage naturel cible sélectionné.

A la réception du message en langage naturel transmis par la source distante, à l'étape 700, l'unité LUTA 58 du destinataire examine le texte du message pour déterminer le langage naturel de la source distante.

Si le langage naturel de la source distante est reconnu, à l'étape 702, l'unité LUTA 58 du destinataire vérifie si le langage reconnu est le même que le langage naturel cible sélectionné préalablement.

Si le langage naturel de la source distante est le même que le langage naturel cible sélectionné, le traitement de la figure 10A se poursuit à partir de l'étape 602. Sinon, à l'étape 704, l'unité LUTA 58 en charge du destinataire 6 vérifie s'il est possible de convertir localement, automatiquement, le message en langage naturel de la source distante au langage naturel cible.

Si une telle conversion automatique est possible localement, à l'étape 706, l'unité LUTA 58 en charge du destinataire effectue la conversion. Le traitement de la figure 10A se poursuit alors à partir de l'étape 602.

Sinon, à l'étape 708, l'unité LUTA 58 du destinataire vérifie si la conversion peut être déléguée à un serveur de traduction distant.

Si une conversion automatique du langage naturel de la source distante vers le langage naturel cible peut être déléguée à un serveur de traduction distant, à l'étape 710, le serveur de traduction distant effectue la conversion. Le traitement de la figure 10A se poursuit alors à partir de l'étape 602

Sinon, à l'étape 712, l'unité LUTA 58 en charge du destinataire 6 génère un message d'échec et transmet ce message à la source distante, à l'unité de contrôle 40, et à l'unité de gestion 42.

Si à l'issue du test de l'étape 700 le langage naturel de la source distante n'est pas reconnu par l'unité LUTA 58 en charge du destinataire, à l'étape 714, l'unité LUTA 58 vérifie si le langage naturel de la source distante est indiqué dans le dossier d'inscription de celle-ci sur la plateforme 1.

Si oui, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702.

Sinon, à l'étape 716, l'unité LUTA 58 en charge du destinataire 6 vérifie si le langage naturel de la source distante est indiqué dans un annuaire extérieur.

Si oui, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702.

Sinon, à l'étape 718, l'unité LUTA 58 en charge du destinataire 6 vérifie si le langage naturel de la source distante 2 a pu être appris par examen des messages précédents.

Si oui, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702. Sinon, à l'étape 712, l'unité LUTA 58 en charge du destinataire génère un message d'échec et transmet ce message à la source distante, à l'unité de contrôle 40, et à l'unité de gestion 42.

La figure 12 est un organigramme détaillé de l'étape 602 de la figure 10 d'alignement des unités utilisées par la source distante sur celles utilisées par le destinataire.

A l'étape 720, l'unité LUTA 58 en charge du destinataire vérifie si les unités de longueur, de surface et de volume présentes dans le message reçu de l'utilisateur distant sont identiques aux unités utilisées par l'utilisateur local destinataire du message.

Sinon, A l'étape 722, l'unité LUTA 58 en charge du destinataire transforme les unités de longueur, de surface et de volume du message reçu en unités de longueur utilisées par l'utilisateur local destinataire du message.

Si oui, A l'étape 724, l'unité LUTA 58 en charge du destinataire vérifie si les unités de masse et de poids sont identiques aux unités utilisées par l'utilisateur local destinataire du message.

Si les unités de masse et de poids ne sont pas alignées, à l'étape 726, l'unité LUTA 58 en charge du destinataire transforme les unités de masse et de poids du message reçu en unités utilisées par l'utilisateur local destinataire du message.

Si les unités de masse et de poids sont alignées, à l'étape 728, l'unité

LUTA 58 en charge du destinataire vérifie si les unités de température sont identiques aux unités utilisées par l'utilisateur local récepteur du message.

Si les unités de température ne sont pas alignées avec celles de l'utilisateur local récepteur du message, à l'étape 730, l'unité LUTA 58 en charge du destinataire transforme les unités de température du message reçu en unités de température utilisées par l'utilisateur local récepteur du message.

Si les unités de température sont alignées, à l'étape 732, l'unité LUTA 58 en charge du destinataire vérifie si les unités de date, d'heure et de durée sont identiques aux unités utilisées par l'utilisateur local récepteur du message. Si les unités de date, d'heure et de durée ne sont pas alignées, à l'étape 734, l'unité LUTA 58 en charge du destinataire transforme les unités de date, d'heure et de durée en unités utilisées par l'utilisateur local récepteur du message.

Si les unités de date, d'heure et de durée sont alignées, à l'étape 736, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 604 de la figure 10A.

La figure 13 est un organigramme détaillé de l'étape 604 d'alignement des références de date, d'heure et de durée utilisées par la source distante sur celles utilisées par un objet connecté ou un service numérique.

A l'étape 740, l'unité LUTA 58 en charge du destinataire 6 vérifie si les références de date utilisées par l'objet connecté ou le service numérique fournissant le message sont identiques aux références utilisées par l'utilisateur local récepteur du message.

Sinon, A l'étape 742, l'unité LUTA 58 en charge du destinataire transforme les références de date reçues en références de date utilisées par l'utilisateur local récepteur du message.

A l'étape 744, l'unité LUTA 58 en charge du destinataire vérifie si les références d'heure utilisées par l'objet connecté ou le service numérique sont alignées avec celle de l'utilisateur local récepteur du message.

Sinon, à l'étape 746, l'unité LUTA 58 en charge du destinataire transforme les références d'heures reçues en références d'heures utilisées par l'utilisateur local récepteur du message.

Si oui, à l'étape 748, l'unité LUTA 58 en charge du destinataire vérifie si les références de durée sont identiques aux références utilisées par l'utilisateur local récepteur du message.

Sinon, à l'étape 750, l'unité LUTA 58 en charge du destinataire transforme les références de durée du message reçu en références de durée utilisée par l'utilisateur local récepteur du message. A l'étape 752, l'unité LUTA 58 en charge du destinataire transmet le message à l'unité LARC 56 installée dans le récepteur du destinataire du message pour analyser l'ambiguïté des informations reçues.

La figure 14 est un organigramme détaillé de l'étape 612 d'alignement des références de date, d'heure et de durée utilisées par une source locale émettrice d'un message en langage naturel cible sur celles utilisées par le destinataire.

A l'étape 760, l'unité LUTA 58 en charge de la source vérifie si les références de dates utilisées par l'utilisateur destinataire du message reçu sont identiques aux références utilisées par la source locale.

Sinon, à l'étape 762, l'unité LUTA 58 en charge de la source transforme les références de date du message en références de date utilisées par le destinataire.

Si oui, à l'étape 764, l'unité LUTA 58 en charge de la source vérifie si les références d'heures sont identiques aux références d'heures utilisées par la source distante.

Sinon, à l'étape 766, l'unité LUTA 58 en charge de la source transforme les références d'heures du message en références d'heures utilisées par le destinataire.

Si oui, à l'étape 768, l'unité LUTA 58 en charge de la source vérifie si les références de durée du message sont identiques aux références de durée utilisée par le destinataire.

Sinon, à l'étape 770, l'unité LUTA 58 en charge de la source transforme les références de durée du message en références de durée utilisée par le destinataire.

Si oui, à l'étape 772, l'unité LUTA 58 en charge de la source transmet le message en langage naturel cible issu du destinataire vers la fonction permettant d'effectuer l'alignement vers les unités préférées du destinataire.

La figure 15 est un organigramme détaillé de l'étape 614 d'alignement des unités utilisées par une source locale, émetteur d'un message en langage naturel cible, sur celles utilisées par le destinataire.

A l'étape 780, l'unité LUTA 58 en charge de la source locale vérifie si les unités de longueur, de surface et de volume sont identiques aux unités utilisées par le destinataire du message. Sinon, à l'étape 782, l'unité LUTA 58 en charge de la source locale transforme les unités de longueur, de surface et de volume du message en unité de longueur utilisé par l'utilisateur destinataire.

Si oui, à l'étape 784, l'unité LUTA 58 en charge de la source locale vérifie si les unités de masse et de poids sont identiques aux unités utilisées par l'utilisateur destinataire du message.

Sinon, à l'étape 786, l'unité LUTA 58 en charge de la source locale transforme les unités de masse et de poids du message en unités utilisées l'utilisateur destinataire du message.

Si oui, à l'étape 788, l'unité LUTA 58 en charge de la source locale vérifie si les unités de température sont identiques à celles utilisées par l'utilisateur destinataire du message.

Sinon, à l'étape 790, l'unité LUTA 58 en charge de la source locale transforme les unités de température du message en unités utilisées par le destinataire 6.

Si oui, à l'étape 792, l'unité LUTA 58 en charge de la source locale vérifie si les unités de date, d'heure et de durée sont identiques à celles utilisées par l'utilisateur destinataire du message.

Sinon, à l'étape 794, l'unité LUTA 58 en charge de la source locale transforme les unités de date, d'heure et de durée du message en unités utilisées par l'utilisateur destinataire du message.

Si oui, à l'étape 796, l'unité LUTA 58 en charge de la source locale transmet le message reçu en langage naturel cible vers la fonction permettant d'effectuer l'alignement vers le langage naturel de l'utilisateur distant.

La figure 16 est un organigramme détaillé de l'étape 616 d'alignement par une source du langage naturel cible vers le langage naturel de l'utilisateur distant.

A l'étape 800, l'unité LUTA 58 en charge de la source locale vérifie si le langage naturel de l'utilisateur distant est indiqué dans son dossier d'inscription sur la plateforme 1.

Si oui, à l'étape 802, l'unité LUTA 58 en charge de la source locale vérifie si le langage naturel de l'utilisateur distant indiqué est identique au langage naturel cible. Sinon, à l'étape 804, l'unité LUTA 58 en charge de la source locale vérifie si une conversion automatique locale en langage de l'utilisateur distant est possible.

Si oui, à l'étape 806, l'unité LUTA 58 en charge de la source locale effectue la traduction automatique locale du langage naturel cible vers langage de l'utilisateur distant et transmet, à l'étape 808, le message en langage naturel l'utilisateur distant au module IF-NLX 60 de cet utilisateur distant.

Si le langage naturel de l'utilisateur distant n'est pas indiqué dans son dossier d'inscription sur la plateforme 1, à l'étape 814, l'unité LUTA 58 en charge de la source locale vérifie si le langage naturel de cet utilisateur distant est indiqué dans un annuaire extérieur.

Si oui, la procédure d'alignement du langage naturel cible vers le langage naturel de l'utilisateur distant se poursuit à partir de l'étape 802.

Sinon, l'unité LUTA 58 en charge de la source locale transmet, à l'étape 816, le message en langage naturel cible au module IF-NLX 60 en charge de la source locale pour transmission à l'utilisateur distant.

Les messages en un langage naturel cible échangés entre les interfaces bidirectionnelles IF-NLX 60 implémentées respectivement du côté d'une source et du côté d'un destinataire peuvent comporter des ambiguïtés grammaticales ou syntaxiques. Ces messages sont transmis aux unités de contrôle et de résolution d'ambiguïté et de pertinence LARC 56 respectivement depuis les unités bidirectionnelles LUTA 58 et depuis les unités de conversion de langage NLAC 54 installées respectivement du côté des sources et du côté des destinataires afin de déterminer le niveau d'ambiguïté des messages échangés et de s'assurer que les unités NLAC 54 seront capables d'effectuer correctement la conversion de langage souhaitée.

La figure 17 représente une vue détaillée d'une unité de résolution d'ambiguïté et de pertinence LARC 56. Celle-ci comporte un bloc d'émission 820 un bloc de résolution 822 et un bloc de réception 824.

Le bloc d'émission 820 comporte un premier multiplexeur 826 destiné à conserver une copie des messages émis par l'utilisateur local et un deuxième multiplexeur 828 destiné à transmettre des messages à l'utilisateur distant à travers le module LUTA 58.

Le bloc de résolution 822 comporte un module de résolution d'ambiguïté grammaticale 830, un module de résolution d'incohérence 832, un module de réponse aux messages de résolution 834, et un module d'assistance aux utilisateurs 836.

Le bloc de réception 824 comporte un module d'analyse grammaticale de message 840, un module d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842, un module d'interception des messages de demandes d'assistance des utilisateurs 844, et un module d'analyse de cohérence de messages 846.

La figure 18 représente un organigramme des étapes de contrôle, pa r l'unité LARC 56, d'ambiguïté et de pertinence d'un message en langage naturel cible provenant d'un utilisateur distant, et reçu à partir d'une unité bidirectionnelle LUTA 58 en charge du destinataire.

A l'étape 850, le module d'analyse grammaticale de message 840 de l'unité LARC 56 en charge du destinataire vérifie si le message reçu est suffisamment conforme à la grammaire (lexique, syntaxe, etc.) du langage naturel cible.

Si le message reçu n'est pas suffisamment conforme, à l'étape 852, le module 840 transmet le message au module de résolution d'ambiguïté grammaticale 830 qui élabore un message de demande résolution d'ambiguïté grammaticale en langage naturel cible et le transmet vers l'utilisateur distant à travers l'unité bidirectionnelle LUTA 58 en charge du destinataire.

Si le message reçu est suffisamment conforme, à l'étape 854, le module d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842 vérifie si le message reçu est un message de demande résolution des ambiguïtés grammaticales, des confirmations ou des incohérences.

Si oui, à l'étape 856, le module 842 transmet le message au module de réponse aux messages de résolution 834 qui élabore un message de réponse à la demande de résolution d'ambiguïté grammaticale en langage naturel cible et le transmet à l'utilisateur distant à travers l'unité LUTA 58.

Sinon, à l'étape 858, un module d'interception des messages de demandes d'assistance des utilisateurs 844 vérifie si le message est une demande d'assistance de la part de l'utilisateur distant.

Si le message est une demande d'assistance de la part de l'utilisateur distant, à l'étape 860, le module 844 transmet le message au module d'assistance aux utilisateurs 836 qui élabore un message de réponse à la demande d'assistance en langage naturel cible et le transmet à l'utilisateur distant à travers l'unité LUTA 58.

Sinon, à l'étape 862, le module d'analyse de cohérence de messages 846 vérifie si le message reçu est cohérent par rapport à la nature et aux capacités de l'utilisateur local, objet ou service connecté.

Si le message est suffisamment cohérent, il est transmis à l'unité NLAC 54 de conversion de langage.

Sinon, à l'étape 864, le module 846 transmet le message au module de résolution des incohérences 832 qui élabore un message de demande de résolution des confirmations et des incohérences et transmet le message à l'utilisateur distant à travers le module LUTA 58.

Les messages en langage naturel échangés entre une source 2 et un destinataire 6 transitent via les unités de conversion de langage NLAC 54 qui sont chargées d'effectuer la transformation entre d'un côté les informations en langage naturel cible vers un langage construit utilisé par un objet connecté ou un service numérique et de l'autre les messages en langage construit (format numérique de pilotage des objets connectés ou format numérique de pilotage des services numériques) en langage naturel cible.

Les figures 19 et 20 illustrent les étapes pour effectuer ces transformations respectivement dans le premier cas et dans le deuxième cas.

En référence à la figure 19, à la réception d'un message en langage naturel cible transmis à un objet connecté ou à un service numérique par un utilisateur distant, l'unité NLAC 54 en charge de l'objet connecté ou du service numérique mémorise le message reçu à l'étape 870 pour améliorer l'élaboration de l'éventuelle réponse en langage naturel cible.

A l'étape 872, le langage naturel utilisé dans le message mémorisé est converti vers le langage construit de l'objet ou du service connecté. Une vérification de cette conversion est opérée à l'étape 874.

Si la conversion est jugée réussie, à l'étape 876, l'unité NLAC 54 transmet le message en langage construit de l'objet ou du service connecté vers le module MPA-0 52 d'adaptation de média et de protocole implémentée en charge de l'objet connecté ou du service numérique.

Sinon, à l'étape 878, l'unité NLAC 54 transmet un message d'erreur circonstancié à l'utilisateur distant en langage naturel cible à travers le module LARC 56, et aux unités de contrôle CTRL 40 et de gestion 42.

En référence à la figure 20, à la réception d'un message en langage construit transmis par un objet connecté ou un service numérique, à l'étape 880, l'unité NLAC 54 en charge de l'utilisateur distant vérifie si le message reçu est un message d'erreur ou non.

Si oui, à l'étape 882, ladite unité NLAC 54 émet un message d'erreur circonstancié à l'utilisateur distant en langage naturel cible à travers l'unité LARC 56, et aux unités de contrôle CTRL 40 et de gestion 42.

Sinon, à l'étape 884, l'unité NLAC 54 convertit le message reçu en langage construit vers le langage naturel cible. Une vérification de cette conversion est effectuée à l'étape 886.

Si la conversion est jugée réussie, à l'étape 888 le module NLAC 54 transmet le message en langage naturel cible vers l'utilisateur destinataire à travers le module LARC 56.

Sinon, à l'étape 882, l'unité NLAC 54 transmet un message d'erreur circonstancié en langage naturel cible à l'utilisateur distant à travers le module LARC 56 ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42. Notons que la résolution des ambiguïtés est opérée selon une stratégie de qui dépend du niveau de problème. Ainsi, elle peut consister à demander à l'utilisateur distant de :

• Répéter le message ;

• Reformuler le message ;

• Confirmer le message en lui indiquant ce qui a été compris ;

• Reformuler le message en lui indiquant quel(s) mot(s) n'est (ne sont) pas compris ;

• Reformuler le message en lui recommandant de le simplifier ;

• Reformuler le message en lui indiquant qu'il y a un risque d'interprétation multiple ;

• Reformuler le message en lui indiquant quel(s) mot(s) ou concept(s) ne s'applique (ent) pas à l'objet communicant ou au service numérique ;

• Etc.

Pour chacune des stratégies ci-dessus, les unités de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées sont configurées pour utiliser des expressions en langage naturel suffisamment diverses pour ne pas lasser un utilisateur humain. Ces expressions seront également suffisamment simples pour être comprises à la fois par un utilisateur distant de type humain ainsi que par les modules d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842 équipant les unités LARC des objets et services connectés.

La stratégie de résolution des ambiguïtés peut évoluer soit si la précédente stratégie n'a pas apporté de solution satisfaisante soit pour éviter de lasser un utilisateur distant humain

Après un nombre donné (éventuellement variable) de tentatives infructueuses, la fonction de résolution des ambiguïtés pourra déclarer l'abandon de la transaction en le signalant à l'utilisateur distant ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42.

Tout ou partie des données (étapes, messages, stratégies, etc.) utilisées et générées par la fonction de résolution des ambiguïtés sont mémorisées pour être utilisées ultérieurement, en particulier par la fonction de gestion des améliorations de l'unité de gestion 42.

Notons que la réponse aux messages de résolution des ambiguïtés, des confirmations et des incohérences est activée par la fonction d'interception des messages de résolution d'ambiguïté, des confirmations et des incohérences du bloc de réception, par exemple lors de la réception d'une demande de répétition, de confirmation, etc. Elle possède également une copie du message initial qui a été émis depuis le bloc d'émission et dont on cherche à éliminer les ambiguïtés ou les incohérences. En fonction de la stratégie de résolution choisie par les fonctions de résolution des incohérences, des confirmations ou des ambiguïtés distantes, la fonction de réponse consistera, par exemple, à :

• Répéter le message ;

• Reformuler le message ;

• Préciser le message en fonction des indications données par la fonction de résolution distance ;

• Confirmer simplement le message ;

• Confirmer la compréhension qu'à la fonction distante du message ;

• Abandonner la transaction ;

• Etc.

La fonction de réponse aux messages de résolution peut évoluer soit si elle constate que l'attitude précédente n'a pas apporté de solution satisfaisante soit encore pour éviter de lasser un utilisateur distant humain.

Après un nombre donné (éventuellement variable) de tentatives infructueuses, la fonction de réponse aux messages de résolution pourra déclarer l'abandon de la transaction en le signalant à l'utilisateur distant ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42.

Tout ou partie des données (étapes, messages, attitudes, etc.) utilisées et générées par la fonction de réponse aux messages de résolution sont mémorisées pour être utilisées ultérieurement, en particulier par la fonction de gestion des améliorations de l'unité de gestion 42. Assistance aux utilisateurs.

La fonction d'assistance aux utilisateurs est activée par la fonction d'interception des messages de demande d'assistance du bloc de réception. Ces demandes d'assistance peuvent être de diverses natures, par exemple :

• Des informations sur la nature, l'identité et la capacité de l'objet communicant ou du service numérique ;

• Des informations sur l'état opérationnel (ON/OFF) ou l'état administratif (activé/désactivé) de l'objet ou du service ;

• La liste des actions que l'objet ou le service peut entreprendre ou des informations qu'il peut fournir ;

• Des exemples de phrases en langage naturel pour communiquer avec cet objet ou ce service ;

• Des conseils pour résoudre les problèmes les plus fréquents ;

• La conduite à tenir en cas de situation d'urgence ;

• Etc.

L'interface d'assistance aux utilisateurs 836 reçoit et traite les demandes d'assistance selon leur nature. Elle y répond en langage naturel en y joignant éventuellement des données complémentaires (fichiers de documentation détaillées, liens Web vers des didacticiels, etc.).

La figure 21 illustre schématiquement un échange lié à une demande d'assistance entre deux objets communicants, une chaudière et une station météo. Dans cet exemple, le langage naturel cible sélectionné est l'anglais.

Comme illustré par cette figure, les échanges se font entre les blocs de réception 824 équipant les unités LARC 56 respectives de chaque objet connecté.

A titre d'exemple, la chaudière envoie à la station météo le message en langage naturel cible « Can you tell me what are your capacities? ».

A la réception de ce message via son unité LARC 56, la station météo génère, par exemple, automatiquement le message en langage naturel cible « l'm able to measure the current température and humidity » et le renvoie à la chaudière via l'unité LARC 56 de cette dernière.

Notons que tout ou partie des données reçues et générées par les interfaces d'assistance aux utilisateurs 836 sont mémorisées pour être utilisées ultérieurement, en particulier par l'unité de gestion 42.

L'invention prend ainsi en considération les contraintes liées à l'environnement de chaque type de communication et exploite le fait que le langage naturel est le plus adapté à véhiculer des informations riches (données pures, données contextuelles, émotions, etc.) au prix d'une certaine ambiguïté. Les objets connectés et les services numériques sont configurés pour accepter les variations lexicales et syntaxiques des messages, et pour échanger entre supporter une tolérance à l'ambiguïté de façon à simplifier et à élargir leur capacité de communication.

L'invention tire ainsi avantage de la relative simplicité des objets communicants et des services numériques pour déplacer la contrainte depuis les humains vers les objets et services au moyen des traitements numériques du langage naturel (NLP - Natural Langage Processing) dans la mesure où ces objets et services communicants effectuent le plus souvent un nombre limité de tâches simples (ou en tout cas suffisamment spécialisées pour être exprimées simplement). Ceci est mis à profit par l'invention pour réaliser des fonctions de compréhension du langage naturel restreintes aux missions dévolues à ces objets et services. On réalise ainsi le déplacement de la contrainte depuis les personnes humaines (qui doivent s'adapter aux langages artificiels des objets et services) vers les objets et services (qui doivent s'adapter au langage naturel des humains).

Il est possible d'implémenter l'invention à partir d'un nombre différent de modules, certains d'entre eux pouvant être optionnels ; par ailleurs différents regroupements peuvent être réalisés pour des questions pratiques ou technologiques, sans changer la nature de l'invention. Il peut être également envisagé de modifier l'ordre de certains des modules sans modifier significativement la portée de l'invention.

La figure 22 représente schématiquement un mode de réalisation de l'architecture d'un système de communication entre une pluralité d'objets ou de services connectés 4, 6, 30 ayant chacun un langage construit propre et étant susceptibles d'être source ou destinataire d'informations échangées via une plateforme intelligente 1. .

Ce système comporte une passerelle connectée 900 reliée, d'une part, à un réseau 902 dédié aux objets connectés 4, 6, 30, et d'autre part, aux unités distribuées de traitement de l'information 85 par l'intermédiaire des unité logicielle et/ou matérielle d'adaptation de média et de protocole 52. La passerelle connectée 900 a un langage construit propre et est susceptible d'être source ou destinataire des informations échangées et est destinée à assurer au moins l'une des fonctions suivantes :

-adaptation des protocoles réseaux des objets ou services connectés à très bas débit, très basse consommation électrique et longue distance,

-adaptation des protocoles réseaux des objets ou services connectés à faible portée,

-gestion centralisée d'un parc d'objets ou services connectés partageant des similarités matérielles et/ou fonctionnelles,

-regroupement et traitements intermédiaires des données dans un environnement maîtrisé et sécurisé ;

-exposition d'une interface de programmation privée ou publique documentée et stable API (Application Programming Interface).

Dans cette architecture, les unités d'adaptation de média et de protocole 52 implémentent les protocoles de communication supportés par la passerelle 900, et les unités de conversion de langage 54 supportent alors les langages construits propres à la passerelle 900 et assurent la conversion de ces langages propres de/vers le langage naturel cible utilisé au sein de la plate-forme 1.