ES2681629T3 - Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT) - Google Patents

Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT) Download PDF

Info

Publication number
ES2681629T3
ES2681629T3 ES15753810.9T ES15753810T ES2681629T3 ES 2681629 T3 ES2681629 T3 ES 2681629T3 ES 15753810 T ES15753810 T ES 15753810T ES 2681629 T3 ES2681629 T3 ES 2681629T3
Authority
ES
Spain
Prior art keywords
event
iot
iot device
dictionary
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15753810.9T
Other languages
English (en)
Inventor
Binita Gupta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2681629T3 publication Critical patent/ES2681629T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B13/00—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion
    • G05B13/02—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric
    • G05B13/0265—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric the criterion being a learning criterion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Automation & Control Theory (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Telephonic Communication Services (AREA)
  • Selective Calling Equipment (AREA)
  • Machine Translation (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un procedimiento para generar automáticamente un diccionario de eventos en una red de Internet de las cosas, IoT, que comprende: recibir (910) una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT; determinar (920) un estado del primer dispositivo de IoT antes y después del primer evento; caracterizado por: comparar (930) los estados del primer dispositivo de IoT; determinar (940) un tipo de cambio de estado del primer evento basado en la comparación; determinar (950) si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos; crear (960) una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos; y almacenar (970), en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica para todos los dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT)
REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS
[0001] La presente solicitud de patente reivindica el beneficio de la Solicitud Provisional de Estados Unidos n.° 62/035,580, titulada "AUTOMATICALLY GENERATING A MACHINE-TO-MACHINE (M2M) EVENTS DICTIONARY IN A DISTRIBUTED INTERNET OF THINGS (IOT) NETWORK [GENERACIÓN AUTOMÁTICA DE UN DICCIONARIO DE EVENTOS DE MÁQUINA A MÁQUINA (M2M) EN UNA RED DISTRIBUIDA DE INTERNET DE LAS COSAS (IoT)]", presentada el 11 de agosto de 2014, asignada al cesionario del presente documento.
CAMPO TÉCNICO
[0002] La divulgación se relaciona con la generación automática de un diccionario de eventos de máquina a máquina (M2M) en una red distribuida de Internet de las cosas (IoT).
ANTECEDENTES
[0003] Internet es un sistema global de ordenadores y redes informáticas interconectados que usan un conjunto de protocolos de Internet estándar (por ejemplo, el Protocolo de control de transmisión (TCP) y el Protocolo de Internet (IP)) para comunicarse entre sí. Internet de las cosas (IoT) se basa en la idea de que los objetos cotidianos, no solo los ordenadores y las redes informáticas, pueden ser legibles, reconocibles, localizables, direccionables y controlables a través de una red de comunicaciones IoT (por ejemplo, un sistema ad-hoc o Internet).
[0004] Varias tendencias del mercado están impulsando el desarrollo de dispositivos de IoT. Por ejemplo, el aumento de los costos de la energía está impulsando las inversiones estratégicas de los gobiernos en redes inteligentes y el soporte para el consumo futuro, como los vehículos eléctricos y las estaciones de carga públicas. El aumento de los costos de atención médica y el envejecimiento de la población están impulsando el desarrollo de los servicios de fitness y de atención médica a distancia/conectados. Una revolución tecnológica en el hogar impulsa el desarrollo de nuevos servicios "inteligentes", incluida la consolidación por parte de proveedores de servicios que comercializan juegos "N" (por ejemplo, datos, voz, vídeo, seguridad, administración de energía, etc.) y la expansión de redes domésticas. Los edificios se vuelven más inteligentes y más convenientes como medio para reducir los costos operativos de las instalaciones de la empresa.
[0005] Hay una serie de aplicaciones clave para IoT. Por ejemplo, en el área de redes inteligentes y administración de energía, las empresas de servicios públicos pueden optimizar el suministro de energía a hogares y empresas, mientras que los clientes pueden administrar mejor el uso de energía. En el área de la domótica de viviendas y edificios, las casas y edificios inteligentes pueden tener control centralizado sobre prácticamente cualquier dispositivo o sistema en el hogar u oficina, desde electrodomésticos hasta sistemas de seguridad de vehículos eléctricos enchufables (PEV). En el campo del seguimiento de activos, las empresas, los hospitales, las fábricas y otras grandes organizaciones pueden rastrear con precisión las ubicaciones de equipos de alto valor, pacientes, vehículos, etc. En el área de la salud y el bienestar, los médicos pueden controlar remotamente la salud de los pacientes mientras que las personas pueden seguir el progreso de las rutinas de fitness.
[0006] Zheng Hu et al. "Representation and self-configuration of physical entities in extended Smart Grid perimeter [Representación y auto-configuración de las entidades físicas en un perímetro ampliado de red inteligente]" divulga un marco y un conjunto de mecanismos para la identificación, auto-configuración y representación de una amplia gama de entidades relevantes de energía en dominios relevantes.
[0007] Konstantinos Kotis et al. "Semantic Interoperability on the Web of Things: The Semantic Smart Gateway Framework [Interoperabilidad Semántica en la Red de las Cosas: El Marco de Pasarela Inteligente Semántica]" presenta una propuesta sobre interoperabilidad semántica para entidades inteligentes interconectadas y semánticamente coordinadas en una red de las cosas. Más específicamente, el documento presenta un escenario de caso de uso y requisitos relacionados con el registro semántico, la coordinación y la recuperación de entidades inteligentes. Motivado por estos, el documento acentúa la necesidad de, y enfatiza, un marco de pasarelas inteligentes semánticas (SSGF) en la red semántica de las cosas (SWoT), proponiendo un aprendizaje ontológico y un procedimiento de alineación ontológica, respectivamente.
SUMARIO
[0008] Lo siguiente presenta un sumario simplificado relacionado con uno o más aspectos y/o modos de realización divulgados en el presente documento. Como tal, el siguiente sumario no debe considerarse una descripción general extensa relacionada con todos los aspectos y/o modos de realización contemplados, ni debe considerarse el siguiente sumario para identificar elementos clave o críticos relacionados con todos los aspectos y/o modos de
5
10
15
20
25
30
35
40
45
50
55
60
65
realización contemplados ni para delinear el alcance asociado con cualquier aspecto y/o modo de realización particular. Por consiguiente, el siguiente sumario tiene el único propósito de presentar ciertos conceptos relacionados con uno o más aspectos y/o modos de realización relacionados con los mecanismos divulgados en el presente documento de una forma simplificada para preceder a la descripción detallada presentada a continuación.
[0009] La divulgación se relaciona con la generación automática de un diccionario de eventos en una red de IoT. Un procedimiento para generar automáticamente un diccionario de eventos en una red de IoT incluye recibir una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT, determinar un estado del primer dispositivo de IoT antes y después del primer evento, comparar los estados del primer dispositivo de IoT, determinar un tipo de cambio de estado del primer evento basándose en la comparación, determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos, crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común a los dispositivos de IoT de un mismo tipo y/o clase como el primer dispositivo de IoT, y almacenar, en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica.
[0010] Un aparato para generar automáticamente un diccionario de eventos en una red de IoT incluye un transceptor configurado para recibir una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT y al menos un procesador configurado para: determinar un estado del primer dispositivo de IoT antes y después del primer evento, comparar los estados del primer dispositivo de IoT, determinar un tipo de cambio de estado del primer evento basado en la comparación de los estados del primer dispositivo de IoT, determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos y crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común para los dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT, y una memoria configurada para almacenar, en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica.
[0011] Un aparato para generar automáticamente un diccionario de eventos en una red de IoT incluye medios para recibir una notificación de un evento desde un dispositivo de IoT en la red de IoT, medios para determinar un estado del dispositivo de IoT antes y después del evento, medios para comparar los estados del dispositivo de IoT, medios para determinar un tipo de cambio de estado del evento basado en una comparación de los estados del dispositivo de IoT, medios para determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos, medios para crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común para dispositivos de IoT de un mismo tipo y/o clase que el dispositivo de IoT, y medios para almacenar, en el diccionario de eventos, una asignación de una descripción de evento del evento a la entrada genérica.
[0012] Un medio no transitorio legible por ordenador para generar automáticamente un diccionario de eventos en una red de IoT incluye al menos una instrucción para recibir una notificación de un evento desde un dispositivo de IoT en la red de IoT, al menos una instrucción para determinar el estado del dispositivo de IoT antes y después del evento, al menos una instrucción para comparar los estados del dispositivo de IoT, al menos una instrucción para determinar un tipo de cambio de estado del evento basado en una comparación de los estados del dispositivo de IoT, al menos una instrucción para determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos, al menos una instrucción para crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común para dispositivos de IoT de un mismo tipo y/o clase que el dispositivo de IoT, y al menos una instrucción para almacenar, en el diccionario de eventos, una asignación de una descripción de evento del evento a la entrada genérica.
[0013] Otros objetos y ventajas asociados con los aspectos y modos de realización divulgados en el presente documento serán evidentes para los expertos en la materia basándose en los dibujos y descripción detallada adjuntos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0014] Una apreciación más completa de los aspectos de la divulgación y muchas de las ventajas intrínsecas de los mismos se obtendrá inmediatamente cuando se comprendan mejor haciendo referencia a la siguiente descripción detallada cuando se considera en relación con los dibujos adjuntos que se presentan solamente para ilustrar, y no para limitar, la divulgación, y en los que:
La FIG. 1A ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica de
acuerdo con un aspecto de la divulgación.
La FIG. 1B ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica de
acuerdo con un aspecto de la divulgación.
5
10
15
20
25
30
35
40
45
50
55
60
65
La FIG. 1C ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica de acuerdo con un aspecto de la divulgación.
La FIG. ID ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica de acuerdo con un aspecto de la divulgación.
La FIG. IE ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica de acuerdo con un aspecto de la divulgación.
La FIG. 2A ilustra un dispositivo a modo de ejemplo de Internet de las cosas (IoT) de acuerdo con aspectos de la divulgación.
La FIG. 2B ilustra un dispositivo de IoT pasivo a modo de ejemplo de acuerdo con aspectos de la divulgación.
La FIG. 3 ilustra un dispositivo de comunicación que incluye lógica configurada para llevar a cabo la funcionalidad de acuerdo con un aspecto de la divulgación.
La FIG. 4 ilustra un servidor a modo de ejemplo de acuerdo con diversos aspectos de la divulgación.
La FIG. 5 ilustra una red de comunicación inalámbrica que puede soportar servicios detectables de punto a punto (P2P), de acuerdo con un aspecto de la divulgación.
La FIG. 6 ilustra un entorno a modo de ejemplo en el que los servicios de P2P detectables pueden usarse para establecer un bus distribuido basado en proximidad a través del cual se pueden comunicar varios dispositivos, de acuerdo con un aspecto de la divulgación.
La FIG. 7 ilustra una secuencia de mensajes a modo de ejemplo en la cual los servicios P2P detectables pueden usarse para establecer un bus distribuido basado en proximidad sobre el cual se pueden comunicar varios dispositivos, de acuerdo con un aspecto de la divulgación.
La FIG. 8 ilustra una red proximal de IoT 800 a modo de ejemplo de acuerdo con al menos un aspecto de la divulgación.
La FIG. 9 ilustra un flujo a modo de ejemplo para generar automáticamente un diccionario de eventos para un protocolo de comunicación entre dispositivos.
La FIG. 10 ilustra un diagrama de bloques a modo de ejemplo que puede corresponder a un dispositivo que usa servicios P2P detectables para comunicarse a través de un bus distribuido basado en proximidad, de acuerdo con un aspecto de la divulgación.
La FIG. 11 es un diagrama de bloques simplificado de varios aspectos de muestra de un aparato configurado para soportar la comunicación como se enseña en el presente documento.
DESCRIPCIÓN DETALLADA
[0015] Se divulgan procedimientos y sistemas para la generación automática de un diccionario de eventos en una red de Internet de las cosas (IoT). Un aspecto recibe una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT, determina un estado del primer dispositivo de IoT antes y después del primer evento, compara los estados del primer dispositivo de IoT, determina un tipo de cambio de estado del primer evento basado en la comparación ,determina si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos, crea una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común para dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT, y almacena, en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica.
[0016] Los y otros aspectos se divulgan en la siguiente descripción y dibujos relacionados para mostrar ejemplos específicos relativos a modos de realización a modo de ejemplo. Los modos de realización alternativos serán evidentes para los expertos en la materia pertinente tras leer esta divulgación, y pueden construirse y practicarse sin apartarse del alcance o el espíritu de la divulgación. Además, los elementos bien conocidos no se describirán en detalle o pueden omitirse para no ocultar los detalles relevantes de los aspectos y los modos de realización divulgados en el presente documento.
[0017] La expresión "a modo de ejemplo" se usa en el presente documento para significar "que sirve de ejemplo, caso o ilustración". No debe considerarse necesariamente que cualquier modo de realización descrito en el presente documento como "a modo de ejemplo" sea preferido o ventajoso con respecto a otros modos de realización.
5
10
15
20
25
30
35
40
45
50
55
60
65
Asimismo, el término "modo de realización" no requiere que todos los modos de realización incluyan la característica, ventaja o modo de funcionamiento analizados.
[0018] La terminología utilizada en el presente documento describe solamente modos de realización particulares y se debe interpretar que limita cualquiera de los modos de realización divulgados en el presente documento. Como se usa en el presente documento, las formas en singular "un", "una", "el" y "la" están destinadas a incluir también las formas en plural, a menos que el contexto indique claramente lo contrario. Deberá entenderse, además, que los términos "comprende", "que comprende", "incluye" y/o "que incluye", cuando se usen en el presente documento, especifican la presencia de características, valores enteros, pasos, operaciones, elementos y/o componentes indicados, pero no excluyen la presencia o la incorporación de una o más características, valores enteros, etapas, operaciones, elementos, componentes diferentes y/o grupos de los mismos.
[0019] Además, muchos aspectos se describen en términos de secuencias de acciones que realizarán, por ejemplo, unos elementos de un dispositivo informático. Debe reconocerse que varias acciones descritas en el presente documento pueden llevarse a cabo mediante circuitos específicos (por ejemplo, un circuito integrado de aplicación específica (ASIC)), mediante instrucciones de programa ejecutadas por uno o más procesadores, o mediante una combinación de ambos. Adicionalmente, puede considerarse que estas secuencias de acciones descritas en el presente documento se realizan por completo en cualquier forma de medio de almacenamiento legible por ordenador que tenga almacenado en el mismo un conjunto correspondiente de instrucciones de ordenador que, tras su ejecución, harían que un procesador asociado realizara la funcionalidad descrita en el presente documento. Por lo tanto, los diversos aspectos de la divulgación pueden realizarse de un número de formas diferentes, todas las cuales se han contemplado dentro del alcance de la materia objeto reivindicada. Además, para cada uno de los aspectos descritos en el presente documento, la forma correspondiente de cualquiera de dichos aspectos puede describirse en el presente documento como, por ejemplo, "lógica configurada para" llevar a cabo la acción descrita.
[0020] Tal como se utiliza en el presente documento, el término "dispositivo de Internet de las cosas" (o "dispositivo de IoT") puede referirse a cualquier objeto (por ejemplo, un aparato, un sensor, etc.) que tiene una interfaz direccionable (por ejemplo, una dirección de protocolo de Internet (IP), un identificador de Bluetooth (ID), un ID de comunicación de campo cercano (NFC), etc.) y puede transmitir información a uno o más dispositivos a través de una conexión alámbrica o inalámbrica. Un dispositivo de IoT puede tener una interfaz de comunicación pasiva, tal como un código de respuesta rápida (QR), una etiqueta de identificación por radiofrecuencia (RFID), una etiqueta NFC, o similares, o una interfaz de comunicación activa, tal como un módem, una transceptor, un transmisor- receptor, o similares. Un dispositivo de IoT puede tener un conjunto particular de atributos (por ejemplo, una situación o estado del dispositivo, como si el dispositivo de IoT está encendido o apagado, abierto o cerrado, inactivo o activo, disponible para la ejecución de tareas u ocupado, etc., una función de enfriamiento o calentamiento, una función de supervisión o grabación ambiental, una función de emisión de luz, una función de emisión de sonido, etc.) que puede ser incorporada y/o controlada/supervisada por una unidad de procesamiento central (CPU), un microprocesador, ASIC, o similar, y configurada para la conexión a una red de IoT, como una red local ad-hoc o Internet. Por ejemplo, los dispositivos de IoT pueden incluir, pero no están limitados a, refrigeradores, tostadoras, hornos, microondas, congeladores, lavavajillas, platos, herramientas de mano, lavadoras de ropa, secadoras de ropa, hornos, aires acondicionados, termostatos, televisores, lámparas, aspiradoras, aspersores, contadores de electricidad, contadores de gas, etc., siempre que los dispositivos estén equipados con una interfaz de comunicaciones direccionable para comunicarse con la red de IoT. Los dispositivos de IoT también pueden incluir teléfonos celulares, ordenadores de escritorio, ordenadores portátiles, tablets, asistentes digitales personales (PDA), etc. En consecuencia, la red de IoT puede estar compuesta por una combinación de dispositivos accesibles por Internet "heredados" (por ejemplo, ordenadores portátiles u ordenadores de escritorio, teléfonos celulares, etc.) además de dispositivos que típicamente no tienen conectividad a Internet (p. ej., lavavajillas, etc.).
[0021] La FIG. 1A ilustra una arquitectura de sistema de alto nivel de un sistema de comunicación inalámbrica 100A de acuerdo con un aspecto de la divulgación. El sistema de comunicación inalámbrica 100A contiene una pluralidad de dispositivos de IoT 110-118, que incluyen un televisor 110, una unidad de aire acondicionado exterior 112, un termostato 114, un refrigerador 116 y una lavadora y secadora 118.
[0022] Haciendo referencia a la FIG. 1A, los dispositivos de IoT 110-118 están configurados para comunicarse con una red de acceso (por ejemplo, un punto de acceso 125) por una interfaz o capa de comunicaciones físicas, mostrada en la FIG. 1A como interfaz aérea 108 y una conexión alámbrica directa 109. La interfaz aérea 108 puede cumplir con un protocolo de Internet inalámbrico (IP), como IEEE 802.11. Aunque la FIG. 1A ilustra dispositivos de IoT 110-118 que se comunican a través de la interfaz aérea 108 y el dispositivo de IoT 118 que se comunica a través de la conexión alámbrica directa 109, cada dispositivo de IoT puede comunicarse a través de una conexión alámbrica o inalámbrica, o ambas.
[0023] Internet 175 incluye varios agentes de enrutamiento y agentes de procesamiento (no mostrados en la FIG. 1A por razones de comodidad). Internet 175 es un sistema global de ordenadores y redes informáticas interconectados que usa un conjunto de protocolos de Internet estándar (por ejemplo, el Protocolo de control de transmisión (TCP) y el IP) para comunicarse entre dispositivos/redes dispares. tCp/IP proporciona conectividad de extremo a extremo que especifica cómo deben formatearse, direccionarse, transmitirse, enrutarse y recibirse los datos en el destino.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0024] En la FIG. 1A, un ordenador 120, como un ordenador de escritorio o personal (PC), se muestra como conexión directa a Internet 175 (p. ej., a través de una conexión a Ethernet o Wi-Fi o red 802.11). El ordenador 120 puede tener una conexión alámbrica a Internet 175, tal como una conexión directa a un módem o router, que, en un ejemplo, puede corresponder al punto de acceso 125 en sí (por ejemplo, para un router Wi-Fi con conectividad alámbrica e inalámbrica). De forma alternativa, en lugar de estar conectado al punto de acceso 125 y a Internet 175 a través de una conexión alámbrica, el ordenador 120 puede estar conectado al punto de acceso 125 por la interfaz aérea 108 u otra interfaz inalámbrica, y acceder a Internet 175 por la interfaz aérea 108. Aunque se ilustra como un ordenador de escritorio, el ordenador 120 puede ser un ordenador portátil, una tablet, una PDA, un teléfono inteligente o similar. El ordenador 120 puede ser un dispositivo de IoT y/o contener funcionalidad para administrar una red/grupo de IoT, tal como la red/grupo de dispositivos de IoT 110-118.
[0025] El punto de acceso 125 puede estar conectado a Internet 175 a través de, por ejemplo, un sistema de comunicaciones ópticas, tal como FiOS, un módem alámbrico, un módem de línea de abonado digital (DSL), o similares. El punto de acceso 125 puede comunicarse con los dispositivos de IoT 110-120 e Internet 175 utilizando los protocolos de Internet estándar (por ejemplo, TCP/IP).
[0026] Haciendo referencia a la FIG. 1A, se muestra un servidor de IoT 170 como conectado a Internet 175. El servidor de IoT 170 puede implementarse como una pluralidad de servidores estructuralmente independientes, o de forma alternativa puede corresponder a un único servidor. En un aspecto, el servidor de IoT 170 es opcional (como se indica mediante la línea de puntos), y el grupo de dispositivos de IoT 110-120 puede ser una red punto a punto (P2P). En tal caso, los dispositivos de IoT 110-120 pueden comunicarse entre sí directamente a través de la interfaz aérea 108 y/o la conexión alámbrica directa 109. De forma alternativa, o adicional, algunos o todos los dispositivos de IoT 110-120 pueden configurarse con una interfaz de comunicación independiente de la interfaz aérea 108 y la conexión alámbrica directa 109. Por ejemplo, si la interfaz aérea 108 corresponde a una interfaz Wi-Fi, uno o más de los dispositivos de IoT 110-120 pueden tener interfaces Bluetooth o NFC para comunicarse directamente entre sí u otros dispositivos habilitados para Bluetooth o NFC.
[0027] En una red de punto a punto, los esquemas de descubrimiento de servicios pueden multidifundir la presencia de nodos, sus capacidades, y la pertenencia al grupo. Los dispositivos de punto a punto pueden establecer asociaciones e interacciones posteriores basándose en esta información.
[0028] De acuerdo con un aspecto de la divulgación, la FIG. 1B ilustra una arquitectura de alto nivel de otro sistema de comunicación inalámbrica 100B que contiene una pluralidad de dispositivos de IoT. En general, el sistema de comunicación inalámbrica 100B mostrado en la FIG. 1b puede incluir diversos componentes que son iguales y/o sustancialmente similares al sistema de comunicación inalámbrica 100A que se muestra en la FIG. 1A, que se describió con mayor detalle anteriormente (por ejemplo, diversos dispositivos de IoT 110-120, incluyendo la televisión 110, la unidad de aire acondicionado exterior 112, el termostato 114, el refrigerador 116, y la lavadora y secadora 118, que están configurados para comunicarse con el punto de acceso 125 por la interfaz aérea 108 y/o la conexión directa 109, el ordenador 120 que se conecta directamente a Internet 175 y/o se conecta a Internet 175 a través del punto de acceso 125, y el servidor de IoT 170 accesible a través de Internet 175, etc.). Como tal, por brevedad y facilidad de descripción, varios detalles relacionados con ciertos componentes en el sistema de comunicación inalámbrica 100B mostrado en la FIG. 1B pueden omitirse en el presente documento en la medida en que los mismos o similares detalles ya se hayan proporcionado anteriormente en relación con el sistema de comunicación inalámbrica 100A ilustrado en la FIG. 1A.
[0029] Haciendo referencia a la FIG. 1B, el sistema de comunicación inalámbrica 100B puede incluir un dispositivo supervisor 130, que de forma alternativa puede denominarse administrador de IoT 130 o dispositivo de administrador de IoT 130. Como tal, cuando la siguiente descripción utiliza el término "dispositivo supervisor" 130, los expertos en la materia apreciarán que cualquier referencia a un administrador de IoT, propietario de grupo o terminología similar puede referirse al dispositivo supervisor 130 u otro componente físico o lógico que proporciona la misma o sustancialmente similar funcionalidad.
[0030] En un modo de realización, el dispositivo supervisor de 130 en general puede observar, supervisar, controlar, o de otra manera gestionar los diversos otros componentes en el sistema de comunicación inalámbrica 100B. Por ejemplo, el dispositivo supervisor 130 puede comunicarse con una red de acceso (por ejemplo, punto de acceso 125) a través de la interfaz aérea 108 y/o una conexión alámbrica directa 109 para supervisar o gestionar atributos, actividades u otros estados asociados con los diversos dispositivos de IoT 110 -120 en el sistema de comunicación inalámbrica 100B. El dispositivo supervisor 130 puede tener una conexión alámbrica o inalámbrica a Internet 175 y opcionalmente al servidor de IoT 170 (mostrado como una línea de puntos). El dispositivo supervisor 130 puede obtener información de Internet 175 y/o del servidor de IoT 170 que se puede usar para supervisar o gestionar adicionalmente atributos, actividades u otros estados asociados con los diversos dispositivos de IoT 110-120. El dispositivo supervisor 130 puede ser un dispositivo independiente o uno de los dispositivos de IoT 110-120, tal como el ordenador 120. El dispositivo supervisor 130 puede ser un dispositivo físico o una aplicación de software que se ejecuta en un dispositivo físico. El dispositivo supervisor 130 puede incluir una interfaz de usuario que puede emitir información relacionada con los atributos, actividades u otros estados asociados con los dispositivos de IoT 110-120
5
10
15
20
25
30
35
40
45
50
55
60
65
y recibir información de entrada para controlar o gestionar de otra forma los atributos, actividades u otros estados asociados con ello. Por consiguiente, el dispositivo supervisor 130 puede incluir en general diversos componentes y soportar diversas interfaces de comunicación alámbricas e inalámbricas para observar, supervisar, controlar o gestionar de otro modo los diversos componentes en el sistema de comunicación inalámbrica 100B.
[0031] El sistema de comunicación inalámbrica 100B mostrado en la FIG. 1B puede incluir uno o más dispositivos de IoT pasivos 105 (en contraste con los dispositivos de IoT activos 110-120) que pueden acoplarse o hacerse parte del sistema de comunicación inalámbrica 100B. En general, los dispositivos de IoT pasivos 105 pueden incluir dispositivos con código de barras, dispositivos Bluetooth, dispositivos de radiofrecuencia (RF), dispositivos etiquetados con RFID, dispositivos de infrarrojos (IR), dispositivos etiquetados con NFC o cualquier otro dispositivo adecuado que pueda proporcionar su identificador y atributos a otro dispositivo cuando se le consulta por una interfaz de corto alcance. Los dispositivos Active IoT pueden detectar, almacenar, comunicar, actuar respecto a, o similares, cambios en los atributos de los dispositivos de IoT pasivos.
[0032] Por ejemplo, los dispositivos de IoT pasivos 105 pueden incluir una taza de café y un recipiente de zumo de naranja que tienen cada uno una etiqueta RFID o código de barras. Un dispositivo de IoT de armario y el dispositivo de IoT de refrigerador 116 pueden tener cada uno un escáner o lector apropiado que pueda leer la etiqueta de RFID o código de barras para detectar cuándo se han agregado o eliminado los dispositivos de IoT pasivos 105 de taza de café y/o de recipiente de zumo de naranja. En respuesta al dispositivo de IoT de armario que detecta la eliminación del dispositivo de IoT pasivo 105 de taza de café y al dispositivo de IoT de refrigerador 116 que detecta la eliminación del dispositivo de IoT pasivo de recipiente de zumo de naranja, el dispositivo supervisor 130 puede recibir una o más señales relacionadas con las actividades detectadas en el dispositivo de IoT del armario y el dispositivo de IoT de refrigerador 116. El dispositivo supervisor 130 puede deducir entonces que un usuario está bebiendo zumo de naranja de la taza de café y/o le gusta beber zumo de naranja de una taza de café.
[0033] Aunque lo anterior describe los dispositivos de IoT pasivos 105 como que tienen alguna forma de interfaz de comunicación de etiqueta de RFID o código de barras, los dispositivos de IoT pasivos 105 pueden incluir uno o más dispositivos u otros objetos físicos que no tienen tales capacidades de comunicación. Por ejemplo, ciertos dispositivos de IoT pueden tener mecanismos de lectura o escáner apropiados que pueden detectar formas, tamaños, colores y/u otras características observables asociadas con los dispositivos de IoT pasivos 105 para identificar los dispositivos de IoT pasivos 105. De esta manera, cualquier objeto físico adecuado puede comunicar su identidad y atributos y formar parte del sistema de comunicación inalámbrica 100B y ser observado, supervisado, controlado o gestionado de otro modo con el dispositivo supervisor 130. Además, los dispositivos de IoT pasivos 105 pueden estar conectados o de otra forma formar parte del sistema de comunicación inalámbrica 100A mostrado en la FIG. 1A y observados, supervisados, controlados o gestionados de otra manera sustancialmente similar.
[0034] De acuerdo con otro aspecto de la divulgación, la FIG. 1C ilustra una arquitectura de alto nivel de otro sistema de comunicación inalámbrica 100C que contiene una pluralidad de dispositivos de IoT 110-118. En general, el sistema de comunicación inalámbrica 100C mostrado en la FIG. 1C puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicación inalámbrica 100A y 100B que se muestran en las FIGs. 1A y 1B, respectivamente, que se han descrito con mayor detalle anteriormente. Como tal, por brevedad y facilidad de descripción, varios detalles relacionados con ciertos componentes en el sistema de comunicación inalámbrica 100C que se muestran en la FIG. 1C pueden omitirse en el presente documento en la medida en que los mismos o similares detalles ya se hayan proporcionado anteriormente en relación con los sistemas de comunicación inalámbrica 100A y 100B ilustrados en las FIGs. 1A y 1B, respectivamente.
[0035] El sistema de comunicación inalámbrica 100C mostrado en la FIG. 1C ilustra comunicaciones de punto a punto a modo de ejemplo entre los dispositivos de IoT 110-118 y el dispositivo supervisor 130. Como se muestra en la FIG. 1C, el dispositivo supervisor 130 se comunica con cada uno de los dispositivos de IoT 110-118 a través de una interfaz de supervisor IoT. Además, los dispositivos de IoT 110 y 114, los dispositivos de IoT 112, 114, y 116, y los dispositivos de IoT 116 y 118, se comunican directamente entre sí.
[0036] Los dispositivos de IoT 110-118 conforman un grupo de dispositivos de IoT 160. El grupo de dispositivos de IoT 160 es un grupo de dispositivos de IoT conectados localmente, tales como los dispositivos de IoT conectados a la red doméstica de un usuario. Aunque no se muestra, múltiples grupos de dispositivos de IoT pueden conectarse y/o comunicarse entre sí a través de un IoT SuperAgent 140 conectado a Internet 175. En un nivel alto, el dispositivo supervisor 130 gestiona las comunicaciones dentro del grupo, mientras que el IoT SuperAgent 140 puede gestionar las comunicaciones entre grupos. Aunque se muestran como dispositivos independientes, el dispositivo supervisor 130 e IoT SuperAgent 140 pueden ser, o residir en, el mismo dispositivo (por ejemplo, un dispositivo independiente o un dispositivo de IoT, tal como el ordenador 120 en la FIG. 1A). De forma alternativa, IoT SuperAgent 140 puede corresponder a o incluir la funcionalidad del punto de acceso 125. Como otra alternativa más, IoT SuperAgent 140 puede corresponder o incluir la funcionalidad de un servidor de IoT, como el servidor de IoT 170. IoT SuperAgent 140 puede encapsular la funcionalidad de pasarela 145.
[0037] Cada dispositivo de IoT 110-118 puede tratar el dispositivo supervisor de 130 como un igual y transmitir actualizaciones de atributo/esquema para el dispositivo supervisor de 130. Cuando un dispositivo de IoT necesita
5
10
15
20
25
30
35
40
45
50
55
60
65
comunicarse con otro dispositivo de loT, puede solicitar el puntero a ese dispositivo de loT desde el dispositivo supervisor 130 y luego comunicarse con el dispositivo de IoT de destino como un compañero. Los dispositivos de IoT 110-118 se comunican entre sí a través de una red de comunicación de punto a punto utilizando un protocolo de mensajería común (CMP). Siempre que dos dispositivos de IoT estén habilitados para CMP y conectados a través de un transporte de comunicación común, pueden comunicarse entre sí. En la pila de protocolos, la capa de CMP 154 está debajo de la capa de aplicación 152 y encima de la capa de transporte 156 y la capa física 158.
[0038] De acuerdo con otro aspecto de la divulgación, la FIG. ID ilustra una arquitectura de alto nivel de otro sistema de comunicación inalámbrica 100D que contiene una pluralidad de dispositivos de IoT 110-120. En general, el sistema de comunicación inalámbrica 100D mostrado en la FIG. ID puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicación inalámbrica 100A-C que se muestran en las FIGs. 1A-C, respectivamente, que se describieron con mayor detalle anteriormente. Como tal, por brevedad y facilidad de descripción, varios detalles relacionados con ciertos componentes en el sistema de comunicación inalámbrica 100D mostrado en la FIG. ID pueden omitirse en el presente documento en la medida en que los mismos o similares detalles ya se hayan proporcionado anteriormente en relación con los sistemas de comunicación inalámbrica 100A-C ilustrados en las FIGs. 1A-C, respectivamente.
[0039] Internet 175 es un "recurso" que puede ser regulado mediante el concepto de IoT. Sin embargo, Internet 175 es solo un ejemplo de un recurso que está regulado, y cualquier recurso podría regularse utilizando el concepto de IoT. Otros recursos que pueden regularse incluyen, pero no se limitan a, electricidad, gas, almacenamiento, seguridad, y similares. Un dispositivo de IoT puede estar conectado al recurso y, por lo tanto, regularlo, o el recurso podría estar regulado a través de Internet 175. La FIG. ID ilustra varios recursos 180, tales como gas natural, gasolina, agua caliente y electricidad, en los que los recursos 180 se pueden regular además de y/o a través de Internet 175.
[0040] Los dispositivos de IoT pueden comunicarse entre sí para regular su uso de un recurso 180. Por ejemplo, los dispositivos de IoT como una tostadora, un ordenador y un secador de pelo pueden comunicarse entre sí a través de una interfaz de comunicación Bluetooth para regular su uso de electricidad (el recurso 180). Como otro ejemplo, los dispositivos de IoT como un ordenador de escritorio, un teléfono y una tablet pueden comunicarse a través de una interfaz de comunicación Wi-Fi para regular su acceso a Internet 175 (el recurso 180). Como otro ejemplo más, dispositivos de IoT como una estufa, una secadora de ropa y un calentador de agua pueden comunicarse a través de una interfaz de comunicación Wi-Fi para regular su uso de gas. De forma alternativa o adicional, cada dispositivo de IoT puede estar conectado a un servidor de IoT, tal como el servidor de IoT 170, que tiene lógica para regular su uso del recurso 180 basándose en la información recibida de los dispositivos de IoT.
[0041] De acuerdo con otro aspecto de la divulgación, la FIG. IE ilustra una arquitectura de alto nivel de otro sistema de comunicación inalámbrica 100E que contiene una pluralidad de dispositivos de IoT. En general, el sistema de comunicación inalámbrica 100E mostrado en la FIG. IE puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicación inalámbrica 100A-D que se muestran en las FIGs. 1A-D, respectivamente, que se describieron con mayor detalle anteriormente. Como tal, por brevedad y facilidad de descripción, varios detalles relacionados con ciertos componentes en el sistema de comunicación inalámbrica 100E mostrado en la FIG. IE puede omitirse en el presente documento en la medida en que los mismos o similares detalles ya se hayan proporcionado anteriormente en relación con los sistemas de comunicación inalámbrica 100A-D ilustrados en las FIGs. 1A-D, respectivamente.
[0042] El sistema de comunicación inalámbrica 100E incluye dos grupos de dispositivos de IoT 160A y 160B. Múltiples grupos de dispositivos de IoT pueden conectarse y/o comunicarse entre sí a través de un IoT SuperAgent conectado a Internet 175. En un nivel alto, un IoT SuperAgent puede gestionar las comunicaciones entre grupos entre los grupos de dispositivos de IoT. Por ejemplo, en la FIG. IE, el grupo de dispositivos de IoT 160A incluye dispositivos de IoT 116A, 122A y 124A y un IoT SuperAgent 140A, mientras que el grupo de dispositivos de IoT 160b incluye los dispositivos de IoT 116B, 122B y 124B y un IoT SuperAgent 140B. Como tal, los IoT SuperAgents 140A y 140B pueden conectarse a Internet 175 y comunicarse entre sí a través de Internet 175 y/o comunicarse entre sí directamente para facilitar la comunicación entre los grupos de dispositivos de IoT 160A y 160B. Además, aunque la FIG. IE ilustra dos grupos de dispositivos de IoT 160A y 160B que se comunican entre sí a través de IoT SuperAgents 140A y 140B; los expertos en la materia apreciarán que cualquier número de grupos de dispositivos de IoT puede comunicarse adecuadamente entre sí usando IoT SuperAgents.
[0043] La FIG. 2A ilustra un ejemplo de alto nivel de un dispositivo de IoT 200A de acuerdo con aspectos de la divulgación. El dispositivo de IoT 200A puede corresponder a cualquiera de los dispositivos de IoT 110-120, y puede corresponder adicionalmente al dispositivo supervisor 130 y/o la pasarela 145 cuando la funcionalidad del dispositivo supervisor 130 y la pasarela 145 están incorporados en un dispositivo de IoT (por ejemplo, ordenador 120). Si bien las apariencias externas y/o los componentes internos pueden diferir significativamente entre los dispositivos de IoT, la mayoría de los dispositivos de IoT tendrán algún tipo de interfaz de usuario, que puede comprender una pantalla y un medio para la entrada de usuario. Los dispositivos de IoT sin una interfaz de usuario se pueden comunicar de forma remota a través de una red alámbrica o inalámbrica, tal como la interfaz aérea 108 en las FIGs. 1A-B.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0044] Como se muestra en la FIG. 2A, en una configuración de ejemplo para el dispositivo de loT 200A, una carcasa externa del dispositivo de IoT 200A puede configurarse con una pantalla 226, un botón de encendido 222 y dos botones de control 224A y 224B, entre otros componentes, como se conoce en la técnica. La pantalla 226 puede ser una pantalla táctil, en cuyo caso los botones de control 224A y 224B pueden no ser necesarios. Aunque no se muestra explícitamente como parte del dispositivo de IoT 200A, el dispositivo de IoT 200A puede incluir una o más antenas externas y/o una o más antenas integradas que están incorporadas en la carcasa externa, incluidas, entre otras, antenas Wi-Fi, antenas celulares, antenas del sistema de posición satelital (SPS) (por ejemplo, antenas del sistema de posicionamiento global (GPS)), etc.
[0045] Mientras que los componentes internos de los dispositivos de IoT, tales como el dispositivo de IoT 200A, pueden estar configurados con diferentes configuraciones de hardware, una configuración básica de alto nivel para los componentes internos de hardware se muestra como plataforma 202 en la FIG. 2A. La plataforma 202 puede recibir y ejecutar aplicaciones de software, datos y/o comandos transmitidos a través de una interfaz de red, tal como la interfaz aérea 108 en las FIGs. 1A-B y/o una interfaz alámbrica. La plataforma 202 también puede ejecutar de forma independiente aplicaciones almacenadas localmente. La plataforma 202 puede incluir uno o más transceptores 206 configurados para comunicación alámbrica y/o inalámbrica (por ejemplo, un transceptor de Wi-Fi, un transceptor de Bluetooth, un transceptor celular, un transceptor de satélite, un receptor de GPS o SPS, etc.) acoplados operativamente a uno o más procesadores 208, tales como un microcontrolador, un microprocesador, un circuito integrado específico de la aplicación, un procesador de señal digital (DSP), un circuito lógico programable u otro dispositivo de procesamiento de datos, que en general se denominará procesador 208. El procesador 208 puede ejecutar instrucciones de programación de aplicaciones dentro de una memoria 212 del dispositivo de IoT 200A. La memoria 212 puede incluir una o más de memoria de solo lectura (ROM), memoria de acceso aleatorio (RAM), ROM programable borrable eléctricamente (EEPROM), tarjetas de memoria flash, o cualquier memoria común a plataformas informáticas. Una o más interfaces de entrada/salida (E/S) 214 pueden configurarse para permitir que el procesador 208 se comunique y controle desde varios dispositivos de E/S tales como la pantalla 226, el botón de encendido 222, los botones de control 224A y 224B como se ilustra, y cualquier otro dispositivo, tal como sensores, actuadores, relés, válvulas, conmutadores y similares asociados con el dispositivo de IoT 200A.
[0046] En consecuencia, un aspecto de la divulgación puede incluir un dispositivo de IoT (por ejemplo, un dispositivo de IoT 200A) que incluye la capacidad de realizar las funciones descritas en el presente documento. Como apreciarán los expertos en la materia, los diversos elementos lógicos pueden realizarse en elementos discretos, módulos de software ejecutados en un procesador (por ejemplo, el procesador 208) o cualquier combinación de software y hardware para conseguir la funcionalidad divulgada en el presente documento. Por ejemplo, el transceptor 206, el procesador 208, la memoria 212 y la interfaz de E/S 214 se pueden usar cooperativamente para cargar, almacenar y ejecutar las diversas funciones divulgadas en el presente documento y así la lógica para realizar estas funciones se puede distribuir a través de diversos elementos. De forma alternativa, la funcionalidad podría incorporarse a un componente discreto. Por lo tanto, las características del dispositivo de IoT 200A en la FIG. 2A deben considerarse meramente ilustrativas y la divulgación no está limitada a las características o disposición ilustradas.
[0047] Por ejemplo, cuando el dispositivo de IoT 200A corresponde a un dispositivo supervisor, tal como el dispositivo supervisor de 130, configurado para generar automáticamente un diccionario de eventos en una red de IoT, el dispositivo de IoT 200A puede incluir también un módulo 210 de monitor de eventos y generador de diccionario (EMDG) configurado para realizar, u ocasionar el funcionamiento de, la funcionalidad descrita en el presente documento. El módulo EMDG 210 puede ser un módulo de hardware, un módulo de software ejecutable por el procesador 208, o una combinación de hardware y software. En un modo de realización de ejemplo, el transceptor 206 puede recibir una notificación de un evento desde un dispositivo de IoT en la red de IoT, y el procesador 208/módulo EMDG 210, junto con el transceptor 206, puede determinar un estado del dispositivo de IoT antes y después del evento. El procesador 208/módulo EMDG 210 también puede comparar los estados del dispositivo de IoT, determinar un tipo de cambio de estado del evento basándose en la comparación y determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos. El procesador 208/módulo EMDG 210, junto con la memoria 212, puede crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común a dispositivos de IoT del mismo tipo y/o clase que el dispositivo de IoT, y la memoria 212 puede almacenar, en el diccionario de eventos, una asignación de una descripción de evento del evento a la entrada genérica.
[0048] La FIG. 2B ilustra un ejemplo de alto nivel de un dispositivo de IoT pasivo 200B de acuerdo con aspectos de la divulgación. En general, el dispositivo de IoT pasivo 200B mostrado en la FIG. 2B puede incluir diversos componentes que son iguales y/o sustancialmente similares al dispositivo de IoT 200A que se muestra en la FIG. 2A, que se ha descrito con mayor detalle anteriormente. Como tal, por brevedad y facilidad de descripción, varios detalles relacionados con ciertos componentes en el dispositivo de IoT pasivo 200B mostrado en la FIG. 2B puede omitirse en el presente documento en la medida en que los mismos o similares detalles ya se hayan proporcionado anteriormente en relación con el dispositivo de IoT 200A ilustrado en la FIG. 2A.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0049] El dispositivo de loT pasivo 200B que se muestra en la FIG. 2B en general puede diferir del dispositivo de loT 200A que se muestra en la FIG. 2A en que el dispositivo de IoT pasivo 200B puede no tener un procesador, memoria interna, o ciertos otros componentes. En cambio, en un modo de realización, el dispositivo de IoT pasivo 200B puede incluir solo una interfaz de E/S 214 u otro mecanismo adecuado que permita observar, supervisar, controlar, gestionar o conocer de otro modo el dispositivo de IoT pasivo 200B dentro de una red de IoT controlada. Por ejemplo, en un modo de realización, la interfaz I/O 214 asociada con el dispositivo de IoT pasivo 200B puede incluir un código de barras, interfaz Bluetooth, interfaz de radiofrecuencia (RF), etiqueta RFID, interfaz IR, interfaz NFC o cualquier otro interfaz de E/S adecuado que pueda proporcionar un identificador y atributos asociados con el dispositivo de IoT pasivo 200B a otro dispositivo cuando se consulta a través de una interfaz de corto alcance (por ejemplo, un dispositivo de IoT activo, como el dispositivo de IoT 200A, que puede detectar, almacenar, comunicar, actuar respecto a, o procesar de otro modo la información relacionada con los atributos asociados con el dispositivo de IoT pasivo 200B).
[0050] Aunque lo anterior describe el dispositivo de IoT pasivo 200B como tener alguna forma de RF, código de barras, u otra interfaz de I/O 214, el dispositivo de IoT pasivo 200B puede comprender un dispositivo u otro objeto físico que no tenga tal interfaz de E/S 214. Por ejemplo, ciertos dispositivos de IoT pueden tener mecanismos apropiados de escáner o lector que pueden detectar formas, tamaños, colores y/u otras características observables asociadas con el dispositivo de IoT pasivo 200B para identificar el dispositivo de IoT pasivo 200B. De esta manera, cualquier objeto físico adecuado puede comunicar su identidad y atributos y ser observado, supervisado, controlado o gestionado de otro modo dentro de una red de IoT controlada.
[0051] La FIG. 3 ilustra un dispositivo de comunicación 300 que incluye la lógica configurada para realizar la funcionalidad. El dispositivo de comunicación 300 puede corresponder a cualquiera de los dispositivos de comunicación mencionados anteriormente, incluyendo, pero sin limitarse a, los dispositivos de IoT 110-120, el dispositivo de IoT 200A, cualquier componente acoplado a Internet 175 (por ejemplo, el servidor de IoT 170), etc. Por lo tanto, el dispositivo de comunicación 300 puede corresponder a cualquier dispositivo electrónico que esté configurado para comunicarse con (o facilitar la comunicación con) una o más entidades diferentes a través de los sistemas de comunicación inalámbrica 100A-D de las FIGs. 1A-D.
[0052] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye una lógica configurada para recibir y/o transmitir la información 305. En un ejemplo, si el dispositivo de comunicación 300 corresponde a un dispositivo de comunicación inalámbrica (por ejemplo, dispositivo de IoT 200A y/o dispositivo de IoT pasivo 200B), la lógica configurada para recibir y/o transmitir información 305 puede incluir una interfaz de comunicaciones inalámbricas (por ejemplo, Bluetooth, Wi-Fi, Wi-Fi Direct, Evolución a Largo Plazo (LTE) Directa, etc.) como un transceptor inalámbrico y hardware asociado (por ejemplo, una antena de RF, un MODEM, un modulador y/o desmodulador, etc.). En otro ejemplo, la lógica configurada para recibir y/o transmitir información 305 puede corresponder a una interfaz de comunicaciones alámbricas (por ejemplo, una conexión en serie, una conexión USB o Firewire, una conexión a Ethernet a través de la cual pueda accederse a Internet 175, etc.). Por lo tanto, si el dispositivo de comunicación 300 corresponde a algún tipo de servidor basado en red (por ejemplo, el servidor de IoT 170), la lógica configurada para recibir y/o transmitir información 305 puede corresponder a una tarjeta Ethernet, en un ejemplo, que conecta el servidor basado en red a otras entidades de comunicación a través de un protocolo de Ethernet. En otro ejemplo, la lógica configurada para recibir y/o transmitir la información 305 puede incluir hardware sensorial o de medición por el cual el dispositivo de comunicación 300 pueda supervisar su entorno local (por ejemplo, un acelerómetro, un sensor de temperatura, un sensor de luz, una antena para supervisar señales RF locales, etc.). La lógica configurada para recibir y/o transmitir la información 305 puede incluir también software que, cuando se ejecute, permita al hardware asociado de la lógica configurada recibir y/o transmitir la información 305 para realizar su(s) función(es) de recepción y/o transmisión. Sin embargo, la lógica configurada para recibir y/o transmitir la información 305 no corresponde solamente al software, y la lógica configurada para recibir y/o transmitir la información 305 depende al menos parcialmente del hardware para lograr su funcionalidad.
[0053] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además una lógica configurada para procesar la información 310. En un ejemplo, la lógica configurada para procesar la información 310 puede incluir al menos un procesador. Implementaciones de ejemplo del tipo de procesamiento que pueden realizarse mediante la lógica configurada para procesar la información 310 incluyen, pero no se limitan a, realizar determinaciones, establecer conexiones, realizar selecciones entre opciones de información diferentes, realizar evaluaciones relativas a datos, interactuar con sensores acoplados al dispositivo de comunicación 300 para realizar operaciones de medición, convertir información de un formato a otro (por ejemplo, entre protocolos diferentes tales como.wmv a.avi, etc.), etc. El procesador incluido en la lógica configurada para procesar información 310 puede corresponder a un procesador de propósito general, un DSP, un ASIC, un conjunto de puertas programables en campo (FPGA) u otro dispositivo lógico programable, lógica de puerta o transistor discreta, componentes de hardware discretos, o cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador pero, de forma alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también puede implementarse como una combinación de dispositivos informáticos (por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP o cualquier otra configuración de este tipo). La lógica configurada para procesar la
5
10
15
20
25
30
35
40
45
50
55
60
65
información 310 puede incluir también software que, cuando se ejecute, permita al hardware asociado de la lógica configurada procesar la información 310 realice su(s) función(es) de procesamiento. Sin embargo, la lógica configurada para procesar la información 310 no corresponde solamente al software, y la lógica configurada para procesar la información 310 depende al menos parcialmente del hardware para lograr su funcionalidad.
[0054] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además la lógica configurada para almacenar la información 315. En un ejemplo, la lógica configurada para almacenar la información 315 puede incluir al menos una memoria no transitoria y un hardware asociado (por ejemplo, un controlador de memoria, etc.). Por ejemplo, la memoria no transitoria incluida en la lógica configurada para almacenar información 315 puede corresponder a RAM, memoria flash, ROM, ROM borrable programable (EPROM), EEPROM, registros, disco duro, un disco extraíble, un CD-ROM, o cualquier otra forma de medio de almacenamiento conocido en la técnica. La lógica configurada para almacenar la información 315 puede incluir también software que, cuando se ejecute, permita al hardware asociado de la lógica configurada almacenar la información 315 para realizar su(s) función(es) de almacenamiento. Sin embargo, la lógica configurada para almacenar información 315 no corresponde solamente al software, y la lógica configurada para almacenar la información 315 depende al menos parcialmente del hardware para lograr su funcionalidad.
[0055] Cuando el dispositivo de comunicación 300 corresponde a un dispositivo supervisor, tal como el dispositivo supervisor de 130, configurado para generar automáticamente un diccionario de eventos en una red de IoT, la lógica configurada para recibir y/o transmitir información 305 puede recibir una notificación de un evento desde un dispositivo de IoT en la red de IoT, y la lógica configurada para procesar información 310, junto con la lógica configurada para recibir y/o transmitir información 305, puede determinar un estado del dispositivo de IoT antes y después del evento. La lógica configurada para procesar información 310 también puede comparar los estados del dispositivo de IoT, determinar un tipo de cambio de estado del evento basándose en la comparación y determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos. La lógica configurada para procesar información 310, junto con la lógica configurada para almacenar información 315, puede crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común a los dispositivos de IoT del mismo tipo y/o clase que el dispositivo de IoT, y la lógica configurada para almacenar información 315 puede almacenar, en el diccionario de eventos, una asignación de una descripción de evento del evento a la entrada genérica.
[0056] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además una lógica configurada para presentar la información 320. En un ejemplo, la lógica configurada para presentar información 320 puede incluir al menos un dispositivo de salida y un hardware asociado. Por ejemplo, el dispositivo de salida puede incluir un dispositivo de salida de vídeo (por ejemplo, una pantalla de visualización, un puerto que pueda llevar información de vídeo, como USB, HDMI, etc.), un dispositivo de salida de audio (por ejemplo, altavoces, un puerto que pueda llevar información de audio, tal como una toma de micrófono, un USB, un HDMI, etc.), un dispositivo de vibración y/o cualquier otro dispositivo mediante el cual la información pueda formatearse para enviarse o enviarse realmente por un usuario u operador del dispositivo de comunicación 300. Por ejemplo, si el dispositivo de comunicación 300 se corresponde con el dispositivo de IoT 200A como se muestra en la FIG. 2A y/o el dispositivo de IoT pasivo 200B como se muestra en la FIG. 2B, la lógica configurada para presentar información 320 puede incluir la pantalla 226. En otro ejemplo, la lógica configurada para presentar la información 320 puede omitirse para ciertos dispositivos de comunicación, tales como los dispositivos de comunicación de red que no tengan un usuario local (por ejemplo, conmutadores de red o routers, servidores remotos, etc.). La lógica configurada para presentar la información 320 puede incluir también software que, cuando se ejecute, permita al hardware asociado de la lógica configurada presentar la información 320 realizar su(s) función(es) de presentación. Sin embargo, la lógica configurada para presentar la información 320 no corresponde solamente al software y la lógica configurada para presentar la información 320 depende al menos parcialmente del hardware para lograr su funcionalidad.
[0057] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además opcionalmente una lógica configurada para recibir la entrada de usuario local 325. En un ejemplo, la lógica configurada para recibir la entrada de usuario local 325 puede incluir al menos un dispositivo de entrada de usuario y un hardware asociado. Por ejemplo, el dispositivo de entrada de usuario puede incluir botones, una pantalla táctil, un teclado, una cámara, un dispositivo de entrada de audio (por ejemplo, un micrófono o un puerto que puede llevar información de audio, tal como un conector de micrófono, etc.), y/o cualquier otro dispositivo mediante el cual se pueda recibir información de un usuario u operador del dispositivo de comunicación 300. Por ejemplo, si el dispositivo de comunicación 300 se corresponde con el dispositivo de IoT 200A como se muestra en la FIG. 2A y/o el dispositivo de IoT pasivo 200B como se muestra en la FIG. 2B, la lógica configurada para recibir la entrada de usuario local 325 puede incluir los botones de encendido 222, los botones de control 224A y 224B, y la pantalla 226 (si es una pantalla táctil), etc. En un ejemplo adicional, la lógica configurada para recibir la entrada de usuario local 325 puede omitirse para ciertos dispositivos de comunicación, como dispositivos de comunicación de red que no tienen un usuario local (por ejemplo, routers o conmutadores de red, servidores remotos, etc.). La lógica configurada para recibir la entrada de usuario local 325 puede incluir también software que, cuando se ejecute, permita al hardware asociado de la lógica configurada recibir la entrada de usuario local 325 para realizar su(s) función(es) de recepción de entrada. Sin embargo, la lógica configurada para recibir la entrada de usuario local 325 no corresponde solamente al software y
5
10
15
20
25
30
35
40
45
50
55
60
65
la lógica configurada para recibir la entrada de usuario local 325 depende al menos parcialmente del hardware para lograr su funcionalidad.
[0058] Haciendo referencia a la FIG. 3, mientras que las lógicas configuradas de 305 a 325 se muestran como bloques independientes o distintos en la FIG. 3, se apreciará que el hardware y/o el software mediante los cuales la lógica configurada respectiva realiza su funcionalidad pueden superponerse parcialmente. Por ejemplo, cualquier software usado para facilitar la funcionalidad de las lógicas configuradas de 305 a 325 puede almacenarse en la memoria no transitoria asociada con la lógica configurada para almacenar la información 315, de tal manera que las lógicas configuradas de 305 a 325 realizan cada una su funcionalidad (es decir, en este caso, la ejecución de software) basándose parcialmente en el funcionamiento del software almacenado por la lógica configurada para almacenar la información 315. Asimismo, el hardware que está directamente asociado con una de las lógicas configuradas puede prestarse a o ser usado por otras lógicas configuradas de vez en cuando. Por ejemplo, el procesador de la lógica configurada para procesar la información 310 puede formatear datos en un formato apropiado antes de transmitirse mediante la lógica configurada para recibir y/o transmitir la información 305, de tal manera que la lógica configurada para recibir y/o transmitir la información 305 realice su funcionalidad (es decir, en este caso, la transmisión de datos) basándose parcialmente en el funcionamiento del hardware (es decir, el procesador) asociado con la lógica configurada para procesar la información 310.
[0059] En general, a menos que se indique lo contrario de forma explícita, la frase "lógica configurada para" tal como se utiliza en toda esta divulgación está destinada a invocar un aspecto que se implementa al menos parcialmente con hardware, y no se pretende asignar a las implementaciones de solo software que son independientes del hardware. Igualmente, se apreciará que la lógica configurada o la "lógica configurada para" en los diversos bloques no está limitada a puertas o elementos lógicos específicos, sino que se refieren en general a la capacidad de realizar la funcionalidad descrita en el presente documento (ya sea a través de hardware o de una combinación de hardware y software). Por lo tanto, las lógicas configuradas o la "lógica configurada para" como se ilustra en los diversos bloques no se implementan necesariamente como puertas lógicas o elementos lógicos a pesar de compartir la palabra "lógica". Otras interacciones o cooperación entre la lógica en los diversos bloques resultarán evidentes para un experto en la materia a partir de una revisión de los aspectos descritos a continuación con más detalle.
[0060] Los diversos modos de realización también pueden implementarse en cualquiera de una variedad de dispositivos de servidor disponibles comercialmente, tales como el servidor 400 ilustrado en la FIG. 4. En un ejemplo, el servidor 400 puede corresponder a una configuración de ejemplo del dispositivo supervisor 130 o el servidor de IoT 170 descrito anteriormente. En la FIG. 4, el servidor 400 incluye un procesador 401 conectado a la memoria volátil 402 y una memoria no volátil de gran capacidad, tal como un disco duro 403. El servidor 400 también puede incluir una unidad de disco flexible, una unidad de disco compacto (CD) o de disco DVD 406 acoplada al procesador 401. El servidor 400 también puede incluir puertos de acceso a la red 404 acoplados al procesador 401 para establecer conexiones de datos con una red 407, tal como una red de área local acoplada a otros ordenadores y servidores del sistema de radiodifusión o a Internet.
[0061] Cuando el servidor 400 está configurado para generar automáticamente un diccionario de eventos para un protocolo de comunicación entre dispositivos en una red de IoT, el servidor 400 también puede incluir un módulo EMDG 410 configurado para realizar, o hacer que funcione, la funcionalidad descrita en el presente documento. El módulo EMDG 410 puede ser un módulo de hardware, un módulo de software ejecutable o una combinación de hardware y software. En un modo de realización a modo de ejemplo, los puertos de acceso a la red 404 pueden recibir una notificación de un evento desde un dispositivo de IoT en la red de IoT, y el procesador 401/módulo EMDG 410, junto con los puertos de acceso a la red 404, puede determinar un estado del dispositivo de IoT antes y después del evento. El procesador 401/módulo EMDG 410 también puede comparar los estados del dispositivo de IoT, determinar un tipo de cambio de estado del evento basándose en la comparación y determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos. El procesador 401/módulo EMDG 410, junto con la unidad de disco 403, puede crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos, en el que el tipo de cambio de estado asociado con la entrada genérica es común a dispositivos de IoT del mismo tipo y/o clase que el dispositivo de IoT, y la unidad de disco 403 puede almacenar, en el diccionario de eventos, una asignación de una descripción de evento del evento a la entrada genérica.
[0062] En el contexto de la FIG. 3, se apreciará que el servidor 400 de la FIG. 4 ilustra una implementación de ejemplo del dispositivo de comunicación 300, donde la lógica configurada para recibir y/o transmitir información 305 corresponde a los puertos de acceso de red 404 utilizados por el servidor 400 para comunicarse con la red 407, la lógica configurada para procesar información 310 corresponde al procesador 401 y, donde el módulo EMDG 410 es un módulo de hardware, el módulo EMDG 410, y la lógica configurada para almacenar información 315 corresponde a cualquier combinación de la memoria volátil 402, el disco de disco 403, la unidad de disco 406, y, donde el módulo EMDG 410 es un módulo de software ejecutable, el módulo EMDG 410. La lógica opcional configurada para presentar información 320 y la lógica opcional configurada para recibir la entrada de usuario local 325 no se muestran explícitamente en la FIG. 4 y pueden o no estar incluidas en la misma. Por lo tanto, la FIG. 4 ayuda a demostrar que el dispositivo de comunicación 300 puede implementarse como un servidor, además de una implementación del dispositivo de IoT como en la FIG. 2A.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0063] En general, el equipo de usuario (UE) como teléfonos, tablets, ordenadores portátiles y de escritorio, ciertos vehículos, etc., pueden estar configurados para conectarse entre sí de forma local (por ejemplo, Bluetooth, Wi-Fi local, etc.) o de forma remota (p. ej., a través de redes celulares, a través de Internet, etc.). Además, ciertos UE también pueden soportar comunicaciones punto a punto (P2P) basadas en proximidad utilizando ciertas tecnologías de redes inalámbricas (por ejemplo, Wi-Fi, Bluetooth, Wi-Fi Direct, etc.) que permiten a los dispositivos realizar una conexión de uno a uno o conectarse simultáneamente a un grupo que incluye varios dispositivos para comunicarse directamente entre sí. Con ese fin, la FIG. 5 ilustra una red de comunicación inalámbrica a modo de ejemplo, o WAN, 500 que puede soportar servicios P2P detectables. Por ejemplo, en un modo de realización, la red de comunicación inalámbrica 500 puede comprender una red LTE u otra WAN adecuada que incluye varias estaciones base 510 y otras entidades de red. Por simplicidad, solo tres estaciones base 510a, 510b y 510c, un controlador de red 530, y un servidor de Protocolo de Configuración Dinámica de Host (DHCP) 540 se muestran en la FIG. 5. Una estación base 510 puede ser una entidad que se comunica con los dispositivos 520 y también se puede denominar un Nodo B, un Nodo B evolucionado (eNB), un punto de acceso, etc. Cada estación base 510 puede proporcionar cobertura de comunicación para un área geográfica particular área y puede soportar comunicaciones para los dispositivos 520 ubicados dentro del área de cobertura. Para mejorar la capacidad de la red, el área de cobertura total de una estación base 510 puede dividirse en múltiples áreas más pequeñas (por ejemplo, tres), en las que cada área más pequeña puede ser servida por una estación base 510 respectiva. En 3GPp, el término "célula" puede referirse a un área de cobertura de una estación base 510 y/o un subsistema de estación base 510 que presta servicio a esta área de cobertura, dependiendo del contexto en el que se usa el término. En 3GPP2, el término "sector" o "sector de célula" puede referirse a un área de cobertura de una estación base 510 y/o una estación base 510 que da servicio a esta área de cobertura. Para mayor claridad, el concepto 3GPP de "célula" se puede usar en la descripción del presente documento.
[0064] Una estación base 510 puede proporcionar cobertura de comunicación para una macro-célula, una pico- célula, una femto-célula, y/o otros tipos de células. Una macro-célula puede cubrir un área geográfica relativamente grande (por ejemplo, varios kilómetros de radio) y puede permitir un acceso sin restricciones a los dispositivos 520 con suscripción al servicio. Una pico-célula puede cubrir un área geográfica relativamente pequeña y puede permitir un acceso sin restricciones mediante los dispositivos 520 con suscripción al servicio. Una femto-célula puede cubrir un área geográfica relativamente pequeña (por ejemplo, una casa) y puede permitir el acceso restringido mediante los dispositivos 520 que tienen asociación con la femto-célula (por ejemplo, los dispositivos 520 en un grupo cerrado de abonados (CSG)). En el ejemplo mostrado en la FIG. 5, la red de comunicación inalámbrica 500 incluye las macro-estaciones base 510a, 510b y 510c para macro-células; la red de comunicación inalámbrica 500 también puede incluir las pico-estaciones 510 para pico-células y/o las estaciones base domésticas 510 para femto-células (no mostradas en la FIG. 5).
[0065] El controlador de red 530 puede acoplarse a un conjunto de estaciones base 510 y puede proporcionar coordinación y control para estas estaciones base 510. El controlador de red 530 puede ser una única entidad de red o una colección de entidades de red que pueden comunicarse con las estaciones base a través de una red de retorno. Las estaciones base 510 también pueden comunicarse entre sí, por ejemplo, directa o indirectamente a través de una red de retorno inalámbrica o alámbrica. El servidor DHCP 540 puede soportar la comunicación P2P, como se describe a continuación. El servidor DHCP 540 puede ser parte de la red de comunicación inalámbrica 500, externa a la red de comunicación inalámbrica 500, ejecutada a través de la conexión compartida a Internet (ICS), o cualquier combinación adecuada de las mismas. El servidor DHCP 540 puede ser una entidad independiente (por ejemplo, como se muestra en la FIG. 5) o puede ser parte de una estación base 510, un controlador de red 530, o alguna otra entidad. En cualquier caso, el servidor DHCP 540 puede ser alcanzable por los dispositivos 520 que desean comunicarse de punto a punto.
[0066] Los dispositivos 520 pueden estar dispersos a lo largo de la red de comunicación inalámbrica 500, y cada dispositivo 520 puede ser estacionario o móvil. Un dispositivo 520 también puede denominarse un nodo, un equipo de usuario (UE), una estación, una estación móvil, un terminal, un terminal de acceso, una unidad de abonado, etc. Un dispositivo 520 puede ser un teléfono celular, un asistente digital personal asistente (PDA), un módem inalámbrico, un dispositivo de comunicación inalámbrica, un dispositivo de mano, un ordenador portátil, un teléfono inalámbrico, una estación de bucle local inalámbrico (WLL), un teléfono inteligente, una netbook, un smartbook, una tablet, etc. Un dispositivo 520 puede comunicarse con las estaciones base 510 en la red de comunicaciones inalámbricas 500 y puede comunicarse adicionalmente de punto a punto con otros dispositivos 520. Por ejemplo, como se muestra en la FIG. 5, los dispositivos 520a y 520b pueden comunicarse de punto a punto, los dispositivos 520c y 520d pueden comunicarse de punto a punto, los dispositivos 520e y 520f pueden comunicarse de punto a punto, y los dispositivos 520g, 520h, y 520i pueden comunicarse de punto a punto, mientras que los dispositivos restantes 520 pueden comunicarse con las estaciones base 510. Como se muestra además en la FIG. 5, los dispositivos 520a, 520d, 520f y 520h también pueden comunicarse con las estaciones base 510, por ejemplo, cuando no están en comunicación P2P o posiblemente concurren con comunicación P2P.
[0067] En la descripción en el presente documento, la comunicación WAN puede referirse a la comunicación entre un dispositivo 520 y una estación base 510 en la red de comunicación inalámbrica 500, por ejemplo, para una llamada con una entidad remota tal como otro dispositivo 520. Un dispositivo WAN es un dispositivo 520 que está
5
10
15
20
25
30
35
40
45
50
55
60
65
interesado o involucrado en la comunicación WAN. La comunicación P2P se refiere a la comunicación directa entre dos o más dispositivos 520, sin pasar por ninguna estación base 510. Un dispositivo P2P es un dispositivo 520 que está interesado o involucrado en la comunicación P2P, por ejemplo, un dispositivo 520 que tiene datos de tráfico para otro dispositivo 520 próximo al dispositivo P2P. Se puede considerar que dos dispositivos están próximos uno del otro, por ejemplo, si cada dispositivo 520 puede detectar el otro dispositivo 520. En general, un dispositivo 520 puede comunicarse con otro dispositivo 520 directamente para la comunicación P2P o a través de al menos una estación base 510 para la comunicación WAN.
[0068] En un modo de realización, la comunicación directa entre los dispositivos 520 pueden organizarse en grupos P2P. Más particularmente, un grupo P2P en general se refiere a un grupo de dos o más dispositivos 520 interesados o comprometidos en la comunicación P2P y un enlace P2P se refiere a un enlace de comunicación para un grupo P2P. Además, en un modo de realización, un grupo P2P puede incluir un dispositivo 520 designado como propietario de un grupo P2P (o un servidor P2P) y uno o más dispositivos 520 designados clientes P2P que son atendidos por el propietario del grupo P2P. El propietario del grupo P2P puede realizar ciertas funciones de gestión tales como el intercambio de señalización con una WAN, la coordinación de la transmisión de datos entre el propietario del grupo P2P y clientes P2P, etc. Por ejemplo, como se muestra en la FIG. 5, un primer grupo P2P incluye dispositivos 520a y 520b bajo la cobertura de la estación base 510a, un segundo grupo P2P incluye dispositivos 520c y 520d bajo la cobertura de la estación base 510b, un tercer grupo P2P incluye dispositivos 520e y 520f bajo la cobertura de diferentes las estaciones base 510b y 510c, y un cuarto grupo P2P incluye los dispositivos 520g, 520h y 520i bajo la cobertura de la estación base 510c. Los dispositivos 520a, 520d, 520f y 520h pueden ser propietarios de grupos P2P para sus respectivos grupos P2P y los dispositivos 520b, 520c, 520e, 520g y 520i pueden ser clientes P2P en sus respectivos grupos P2P. Los otros dispositivos 520 en la FIG. 5 pueden estar involucrados en la comunicación WAN.
[0069] En un modo de realización, la comunicación P2P puede ocurrir solo dentro de un grupo P2P y puede ocurrir además solo entre el propietario del grupo P2P y los clientes P2P asociados con la misma. Por ejemplo, si dos clientes P2P dentro del mismo grupo P2P (por ejemplo, los dispositivos 520g y 520i) desean intercambiar información, uno de los clientes P2P puede enviar la información al propietario del grupo P2P (p. ej., el dispositivo 520h) y el propietario del grupo P2P puede retransmitir transmisiones al otro cliente P2P. En un modo de realización, un dispositivo 520 particular puede pertenecer a múltiples grupos P2P y puede comportarse como un propietario de grupo P2P o un cliente P2P en cada grupo P2P. Además, en un modo de realización, un cliente P2P particular puede pertenecer a un solo grupo P2P o pertenecer a múltiples grupos P2P y comunicarse con los dispositivos 520 en cualquiera de los múltiples grupos P2P en cualquier momento particular. En general, la comunicación puede facilitarse a través de transmisiones en el enlace descendente y el enlace ascendente. Para la comunicación WAN, el enlace descendente (o enlace directo) se refiere al enlace de comunicación desde las estaciones base 510 a los dispositivos 520, y el enlace ascendente (o enlace inverso) se refiere al enlace de comunicación desde los dispositivos 520 a las estaciones base 510. Para la comunicación P2P, el enlace descendente P2P se refiere al enlace de comunicación de los propietarios del grupo P2P a los clientes P2P y el enlace ascendente P2P se refiere al enlace de comunicación de los clientes P2P a los propietarios del grupo P2P. En ciertos modos de realización, en lugar de usar tecnologías WAN para comunicar P2P, dos o más dispositivos pueden formar grupos P2P más pequeños y comunicar P2P en una red de área local inalámbrica (WLAN) utilizando tecnologías tales como Wi-Fi, Bluetooth o Wi-Fi Direct. Por ejemplo, la comunicación P2P usando Wi-Fi, Bluetooth, Wi-Fi Direct u otras tecnologías WLAN puede permitir la comunicación P2P entre dos o más teléfonos móviles, consolas de videojuegos, ordenadores portátiles u otras entidades de comunicación adecuadas.
[0070] De acuerdo con un aspecto de la divulgación, la FIG. 6 ilustra un entorno a modo de ejemplo 600 en el que se pueden usar servicios P2P detectables para establecer un bus distribuido basado en proximidad 625 a través del cual se pueden comunicar varios dispositivos 610, 630, 640. Por ejemplo, en un modo de realización, las comunicaciones entre aplicaciones y similares, en una única plataforma pueden facilitarse utilizando un marco de protocolo de comunicación entre procesos (IPC) por el bus distribuido 625, que puede comprender un bus de software utilizado para permitir las comunicaciones de aplicación a aplicación en un entorno informático en red donde las aplicaciones se registran con el bus distribuido 625 para ofrecer servicios a otras aplicaciones y otras aplicaciones consultan al bus distribuido 625 para obtener información sobre las aplicaciones registradas. Tal protocolo puede proporcionar notificaciones asíncronas y llamadas a procedimientos remotos (RPC) en las que los mensajes de señal (por ejemplo, notificaciones) pueden ser de punto a punto o de radiodifusión, los mensajes de llamada de procedimiento (por ejemplo, RPC) pueden ser síncronos o asíncronos, y el bus distribuidos 625 (por ejemplo, un proceso de bus "daemon") puede manejar el enrutamiento de mensajes entre los diversos dispositivos 610, 630, 640.
[0071] En un modo de realización, el bus distribuido 625 puede estar soportado por una variedad de protocolos de transporte (por ejemplo, Bluetooth, TCP/IP, Wi-Fi, CDmA, GPRS, UMTS, etc.). Por ejemplo, de acuerdo con un aspecto, un primer dispositivo 610 puede incluir un nodo de bus distribuido 612 y uno o más puntos finales locales 614, en el que el nodo de bus distribuido 612 puede facilitar las comunicaciones entre los puntos finales locales 614 asociados con el primer dispositivo 610 y los puntos finales locales 634 y 644 asociados con un segundo dispositivo 630 y un tercer dispositivo 640 a través del bus distribuido 625 (por ejemplo, a través de los nodos de bus distribuidos 632 y 642 en el segundo dispositivo 630 y el tercer dispositivo 640). Como se describirá con más detalle a continuación con referencia a la FIG. 7, el bus distribuido 625 puede soportar topologías de red simétricas de
5
10
15
20
25
30
35
40
45
50
55
60
65
dispositivos múltiples y puede proporcionar un funcionamiento robusto en presencia de interrupciones del dispositivo. Como tal, el bus distribuido 625, que en general puede ser independiente de cualquier protocolo de transporte subyacente (por ejemplo, Bluetooth, TCP/IP, Wi-Fi, etc.) puede permitir varias opciones de seguridad, desde no segura (por ejemplo, abierta) a segura (por ejemplo, autentificada y cifrada), en el que las opciones de seguridad pueden usarse mientras se facilitan conexiones espontáneas entre el primer dispositivo 610, el segundo dispositivo 630 y el tercer dispositivo 640 sin intervención cuando los diversos dispositivos 610, 630, 640 entran en rango o proximidad entre sí.
[0072] De acuerdo con un aspecto de la divulgación, la FIG. 7 ilustra una secuencia de mensajes a modo de ejemplo 700 en la que se pueden usar servicios P2P detectables para establecer un bus distribuido basado en proximidad por el cual un primer dispositivo ("Dispositivo A") 710 y un segundo dispositivo ("Dispositivo B") 730 pueden comunicarse. En general, el Dispositivo A 710 puede solicitar comunicarse con el Dispositivo B 730, en el que el Dispositivo A 710 puede incluir un punto final local 714 (por ejemplo, una aplicación, servicio, etc. local), que puede solicitar una comunicación, además de un nodo de bus 712 que puede ayudar a facilitar tales comunicaciones. Además, el Dispositivo B 730 puede incluir un de punto final local 734 con el que el punto final local 714 puede intentar comunicarse, además de un nodo de bus 732 que puede ayudar a facilitar las comunicaciones entre el punto final local 714 en el Dispositivo A 710 y el punto final local 734 en el Dispositivo B 730.
[0073] En un modo de realización, los nodos de bus 712 y 732 pueden realizar un mecanismo de descubrimiento adecuado en el paso de secuencia de mensajes 754. Por ejemplo, se pueden usar mecanismos para descubrir conexiones compatibles con Bluetooth, TCP/IP, UNIX o similares. En el paso de secuencia de mensajes 756, el punto final local 734 en el Dispositivo B 730 puede solicitar conectarse a una entidad, servicio, punto final, etc., disponible a través del nodo de bus 732. En un modo de realización, la solicitud puede incluir un proceso de solicitud y respuesta entre el punto final local 734 y el nodo de bus 732. En el paso de secuencia de mensajes 758, se puede formar un bus de mensajes distribuidos para conectar el nodo de bus 732 al nodo de bus 712 y de ese modo establecer una conexión P2P entre el Dispositivo A 710 y el Dispositivo B 730. En un modo de realización, las comunicaciones al/desde el bus distribuido entre los nodos de bus 712 y 732 pueden facilitarse utilizando un protocolo P2P basado en proximidad adecuado (por ejemplo, el marco de software AllJoyn™ diseñado para permitir la interoperabilidad entre productos conectados y aplicaciones de software de diferentes fabricantes para crear dinámicamente redes proximales y facilitar la comunicación proximal P2P). De forma alternativa, en un modo de realización, un servidor (no mostrado) puede facilitar la conexión entre los nodos de bus 712 y 732. Además, en un modo de realización, se puede usar un mecanismo de autentificación adecuado antes de formar la conexión entre los nodos de bus 712 y 732 (por ejemplo, autentificación SASL en la que un cliente puede enviar un comando de autentificación para iniciar una conversación de autentificación). Además, durante el paso de secuencia de mensajes 758, los nodos de bus 712 y 732 pueden intercambiar información sobre otros puntos finales disponibles (por ejemplo, puntos finales locales 644 en el Dispositivo C 640 en la FIG. 6). En tales modos de realización, cada punto final local que mantiene un nodo de bus puede publicitarse a otros nodos de bus, en el que el anuncio puede incluir nombres de punto final, tipos de transporte, parámetros de conexión u otra información adecuada únicos.
[0074] En un modo de realización, en el paso de secuencia de mensajes 760, el nodo de bus 712 y el nodo de bus 732 puede utilizar la información obtenida asociada con los puntos finales locales 734 y 714, respectivamente, para crear puntos finales virtuales que pueden representar los puntos finales reales obtenidos disponibles a través de varios nodos de bus. En un modo de realización, el enrutamiento de mensajes en el nodo de bus 712 puede usar puntos finales reales y virtuales para entregar mensajes. Además, puede haber un punto final virtual local para cada punto final que existe en los dispositivos remotos (por ejemplo, el Dispositivo A 710). Además, tales puntos finales virtuales pueden multiplexar y/o desmultiplexar mensajes enviados a través del bus distribuido (por ejemplo, una conexión entre el nodo de bus 712 y el nodo de bus 732). En un aspecto, los puntos finales virtuales pueden recibir mensajes del nodo de bus local 712 o 732, al igual que los puntos finales reales, y pueden reenviar mensajes a través del bus distribuido. Como tal, los puntos finales virtuales pueden reenviar mensajes a los nodos de bus locales 712 y 732 desde la conexión de bus distribuido multiplexado de punto final. Además, en un modo de realización, los puntos finales virtuales que corresponden a puntos finales virtuales en un dispositivo remoto pueden reconectarse en cualquier momento para acomodar las topologías deseadas de tipos de transporte específicos. En tal aspecto, los puntos finales virtuales basados en UNIX pueden considerarse locales y, como tales, pueden no considerarse candidatos para la reconexión. Además, los puntos finales virtuales basados en TCP se pueden optimizar para un enrutamiento de un salto (por ejemplo, cada nodo de bus 712 y 732 se puede conectar directamente entre sí). Aún más, los puntos finales virtuales basados en Bluetooth pueden optimizarse para una sola piconet (por ejemplo, un principal y n secundarios) en la que el principal basado en Bluetooth puede ser el mismo nodo de bus que un nodo principal local.
[0075] En el paso de secuencia de mensajes 762, el nodo de bus 712 y el nodo de bus 732 puede intercambiar información de estado de bus para fusionar casos de bus y permitir la comunicación a través del bus distribuido. Por ejemplo, en un modo de realización, la información del estado del bus puede incluir una asignación de nombre de punto final, reglas de coincidencia, grupo de encaminamiento u otra información adecuada bien conocidos y únicos. En un modo de realización, la información de estado se puede comunicar entre el nodo de bus 712 y las instancias del nodo de bus 732 usando una interfaz con los puntos finales locales 714 y 734 comunicándose con el uso de un nombre local basado en un bus distribuido. En otro aspecto, el nodo de bus 712 y el nodo de bus 732 pueden
5
10
15
20
25
30
35
40
45
50
55
60
65
mantener un controlador de bus local responsable de proporcionar retroalimentación al bus distribuido, en el que el controlador de bus puede traducir procedimientos globales, argumentos, señales y otra información a los estándares asociados con el bus distribuido. En el paso de secuencia de mensajes 764, el nodo de bus 712 y el nodo de bus 732 pueden comunicar (por ejemplo, radiodifusión) señales para informar a los respectivos puntos finales locales 714 y 734 sobre cualquier cambio introducido durante las conexiones de nodo de bus, tal como se describió anteriormente. En un modo de realización, los nombres globales y/o traducidos nuevos y/o eliminados se pueden indicar con señales modificadas por el propietario del nombre. Además, los nombres globales que pueden perderse localmente (p. ej., debido a colisiones de nombres) pueden indicarse con el nombre de señales perdidas. Aún más, los nombres globales que se transfieren debido a colisiones de nombre pueden indicarse con señales de propietario cambiadas y los nombres únicos que desaparecen si y/o cuando el nodo de bus 712 y el nodo de bus 732 se desconectan pueden indicarse con las señales de cambio de propietario de nombre.
[0076] Tal como se usa anteriormente, pueden usarse nombres bien conocidos para describir de forma única los puntos finales locales 714 y 734. En un modo de realización, cuando se producen comunicaciones entre el Dispositivo A 710 y el Dispositivo B 730, se pueden usar diferentes tipos de nombres bien conocidos. Por ejemplo, un nombre local de dispositivo puede existir solo en el nodo de bus 712 asociado con el Dispositivo A 710 al cual el nodo de bus 712 se conecta directamente. En otro ejemplo, puede existir un nombre global en todos los nodos de bus conocidos 712 y 732, donde solo puede existir un propietario del nombre en todos los segmentos de bus. En otras palabras, cuando el nodo de bus 712 y el nodo de bus 732 se unen y se produce cualquier colisión, uno de los propietarios puede perder el nombre global. En otro ejemplo más, un nombre traducido puede usarse cuando un cliente está conectado a otros nodos de bus asociados con un bus virtual. En tal aspecto, el nombre traducido puede incluir un extremo anexo (por ejemplo, un punto final local 714 con el nombre bien conocido "org.foo" conectado al bus distribuido con el Identificador único global "1234" puede verse como "G1234. org.foo").
[0077] En el paso de secuencia de mensajes 766, el nodo de bus 712 y el nodo de bus 732 puede comunicar (por ejemplo, radiodifundir) señales para informar a otros nodos de bus sobre los cambios hasta las topologías de bus de punto final. Después de eso, el tráfico desde el punto final local 714 puede moverse a través de puntos finales virtuales para alcanzar el punto final local previsto 734 en el Dispositivo B 730. Además, durante el funcionamiento, las comunicaciones entre el punto final local 714 y el punto final local 734 pueden usar grupos de enrutamiento. En un aspecto, los grupos de enrutamiento pueden permitir que los puntos finales reciban señales, llamadas a procedimientos u otra información adecuada de un subconjunto de puntos finales. Como tal, un nombre de enrutamiento puede ser determinado por una aplicación conectada a un nodo de bus 712 o 732. Por ejemplo, una aplicación P2P puede usar un nombre de grupo de enrutamiento único y bien conocido integrado en la aplicación. Además, los nodos de bus 712 y 732 pueden soportar el registro y/o el des-registro de los puntos finales locales 714 y 734 con grupos de enrutamiento. En un modo de realización, los grupos de enrutamiento pueden no tener persistencia más allá de una instancia de bus actual. En otro aspecto, las aplicaciones pueden registrarse para sus grupos de enrutamiento preferidos cada vez que se conectan al bus distribuido. Aún más, los grupos de enrutamiento pueden estar abiertos (por ejemplo, cualquier punto final puede unirse) o cerrados (por ejemplo, solo el creador del grupo puede modificar el grupo). Además, un nodo de bus 712 o 732 puede enviar señales para notificar a otros nodos de bus remoto incorporaciones, eliminaciones u otros cambios a los puntos finales del grupo de enrutamiento. En tales modos de realización, el nodo de bus 712 o 732 puede enviar una señal de cambio de grupo de enrutamiento a otros miembros del grupo siempre que se agregue y/o elimine un miembro del grupo. Además, el nodo de bus 712 o 732 puede enviar una señal de cambio de grupo de enrutamiento a puntos finales que se desconectan del bus distribuido sin antes eliminarse del grupo de enrutamiento.
[0078] En un futuro próximo, el creciente desarrollo de las tecnologías de IoT dará lugar a numerosos dispositivos de IoT alrededor de un usuario en casa, en vehículos, en el trabajo, y muchos otros lugares. A medida que IoT crezca, será cada vez más importante soportar un mecanismo mediante el cual diferentes dispositivos de IoT puedan interoperar y realizar acciones mediante el envío/recepción de eventos de máquina a máquina (M2M) mutuamente entendidos. Tradicionalmente, esto requiere que el fabricante del dispositivo (o colectivamente un conjunto de fabricantes para una clase de dispositivo determinada) defina un diccionario de eventos y lo publique a través de algunos medios accesibles globalmente, por ejemplo, una base de datos global del diccionario de eventos M2M. Sin embargo, esto requiere una gran cantidad de colaboración entre las diferentes partes de IoT involucradas, y requiere una infraestructura accesible a nivel mundial para las interacciones de M2M, lo cual no es una solución deseable.
[0079] En consecuencia, la divulgación proporciona un mecanismo para generar automáticamente un diccionario de eventos M2M en una red distribuida de IoT sin colaboración previa entre diferentes proveedores de IoT. A continuación, dicho diccionario se puede distribuir a los dispositivos de IoT para permitirles comprender los eventos M2M y tomar medidas basadas en esos eventos.
[0080] Una red de IoT dada puede incluir múltiples dispositivos de IoT de diferentes proveedores que proporcionan una funcionalidad similar. Por ejemplo, una red de IoT doméstica puede incluir sensores de ventana de dos proveedores diferentes. Estos dispositivos de IoT pueden implementar la misma interfaz de servicio P2P, como una interfaz de sensor de ventana, para la interoperabilidad. Sin embargo, los dispositivos de IoT pueden definir eventos/transiciones de estado similares usando diferentes descripciones textuales que tienen el mismo significado
5
10
15
20
25
30
35
40
45
50
55
60
65
para el usuario final. Por ejemplo, los dos sensores de ventana pueden tener eventos de "ventana cerrada" y "ventana bloqueada", respectivamente, cuando sus ventanas asociadas están cerradas.
[0081] Si hay otro dispositivo de IoT interesado en tomar acciones basadas en eventos radiodifundidos, tiene que ser capaz de interpretar que los dos eventos con diferentes descripciones son en realidad el mismo tipo de evento. Continuando con el ejemplo de sensores de ventana, puede haber una regla que indique que un sistema HVAC debe activarse cuando detecta un evento que indica que la ventana está cerrada. En consecuencia, es deseable generar un diccionario común de eventos m2m que pueda asignar múltiples eventos similares a un único evento. Por ejemplo, los eventos "ventana cerrada" y "ventana bloqueada" se asignarían a un único evento genérico.
[0082] Los dispositivos de IoT en una red de IoT dada en general toman medidas solo basándose en los eventos M2M radiodifundidos por otros dispositivos de IoT en esa red. Como tal, estos dispositivos de IoT solo necesitan el diccionario de eventos para eventos de otros dispositivos de IoT en esa red, en lugar de un diccionario de eventos para el universo global de dispositivos de IoT. Por lo tanto, siempre que se pueda generar un diccionario de eventos M2M localizado, los dispositivos de IoT en la red de IoT dada pueden tomar medidas basadas en ese diccionario.
[0083] Cada red de IoT puede generar su propio diccionario de eventos M2M localizado, que aborda el tema de la generación de un diccionario de eventos M2M de una manera distribuida. Esto evita requerir cualquier infraestructura centralizada para mantener/compartir diccionarios de eventos M2M.
[0084] Para generar automáticamente el diccionario de eventos M2M, un componente de monitor de eventos y generador de diccionario (EMDG), tal como el módulo EMDG 210/410, se puede instalar en una red de IoT distribuida que controla todos los eventos radiodifundidos de los dispositivos de IoT en esa red de IoT. El componente EMDG se puede instalar en la pasarela de la red de IoT, como el supervisor 130, IoT SuperAgent 140 o la pasarela 145. En un aspecto, los eventos pueden radiodifundirse para que sean recibidos por este componente. En un aspecto alternativo, si los eventos se comparten usando un modelo de publicación/suscripción, este componente se suscribirá a todos los dispositivos de IoT que radiodifunden eventos. El componente EMDG puede descubrir los radiodifusores de eventos (por ejemplo, los eventos de radiodifusión de dispositivos de IoT) basándose en los anuncios de descubrimiento de los dispositivos de IoT.
[0085] El componente EMDG también puede ser consciente de la clase/tipo de dispositivo para los distintos dispositivos de IoT en la red. Por ejemplo, sabría que un sensor de ventana X y un sensor de ventana Y pertenecen a la misma clase/tipo de dispositivo. Esta información también se puede aprender de los anuncios de descubrimiento de los dispositivos de IoT.
[0086] El componente EMDG supervisa el estado de un dispositivo de IoT antes y después de un evento radiodifundido. Puede comparar los estados anterior y posterior y correlacionar el evento con un cambio de estado o cambios en un valor del sistema. Refiriéndonos nuevamente al ejemplo de sensores de ventana, el componente EMDG puede comparar el estado del primer sensor de ventana antes y después del evento "ventana cerrada" y el estado del segundo sensor de ventana antes y después del evento "ventana bloqueada". Basándose en el cambio de estado, el componente EMDG puede asignar estos dos eventos a un solo evento M2M genérico en la entrada del diccionario de eventos M2M para esa clase/tipo de dispositivo de IoT.
[0087] Siguiendo con el ejemplo de sensor de ventana, después de recibir el evento de "ventana cerrada" desde el primer sensor de ventana, el componente EMDG puede comparar el estado del primer sensor de ventana antes del evento de "ventana cerrada" (por ejemplo, "abierta") con el estado del primer sensor de ventana después de que ocurrió el evento "ventana cerrada" (por ejemplo, "cerrada"), y puede asignar el evento al cambio en el estado de la ventana de "abierto" a "cerrado". El componente EMDG puede crear una entrada de evento genérico/común para esa clase/tipo de dispositivo y el cambio de estado detectado, y asignarle una enumeración y descripción de texto, como la secuencia "1: la ventana está cerrada ahora".
[0088] El componente EMDG también puede mantener una asignación del evento genérico para el cambio de estado real. Por ejemplo, la cadena "1: la ventana está cerrada ahora" se asignaría al cambio de estado de "abierta" a "cerrada". Es decir, el componente EMDG crea una entrada genérica que describe el cambio de estado que ocurre alrededor del evento detectado, y luego asigna esa entrada genérica al evento específico recibido del sensor de ventana.
[0089] Cuando se recibe un evento de "ventana cerrada" del segundo sensor de ventana, el componente EMDG asignará ese evento para el evento genérico/común creado previamente, es decir, "1: ventana está cerrada ahora", para esa clase/tipo de dispositivo basándose en el cambio de estado observado que coincide con el cambio de estado para el evento genérico. El componente EMDG mantiene una asignación de eventos genéricos/comunes a los eventos reales de dispositivo radiodifundido, es decir, "1: la ventana está cerrada ahora" se asigna a los eventos "ventana cerrada" y "ventana bloqueada". Por lo tanto, el componente EMDG puede crear un diccionario de eventos M2M genérico/común para la clase de dispositivo de sensor de ventana, como "1: la ventana está cerrada ahora" y "2: la ventana está abierta ahora".
5
10
15
20
25
30
35
40
45
50
55
60
65
[0090] En referencia al componente EMDG que supervisa el estado de los dispositivos de loT en mayor detalle, el componente EMDG puede sondear periódicamente dispositivos para obtener su información de estado actual. Después de detectar un evento, el componente EMDG puede sondear el dispositivo de IoT nuevamente para obtener el estado del dispositivo de IoT después del evento. Algunos dispositivos de IoT también pueden ofrecer un servicio mediante el cual registran el estado de su sistema antes y después de los eventos. Tal servicio puede ser activado por el componente EMDG, de modo que el componente EmdG pueda recuperar estados de dispositivo de antes y después al recibir un evento desde un dispositivo de IoT determinado.
[0091] El componente EMDG aprende acerca de eventos y genera entradas de diccionario de eventos genéricos a medida que los eventos son radiodifundidos por los dispositivos de IoT en la red de IoT. Este proceso de autoaprendizaje podría llevar algo de tiempo. Para agilizar esta fase de autoaprendizaje, cada dispositivo de IoT puede diseñarse para tener un modo especial, como un "Modo de radiodifusión de eventos", en el cual un dispositivo de IoT radiodifundirá todos los eventos que soporta y simulará cambios de estado para esos eventos. Esto agilizará el aspecto de autoaprendizaje/generación automática para eventos M2M. Este modo se puede activar justo después de que un dispositivo de IoT se haya incorporado a la red como parte del proceso de incorporación.
[0092] El diccionario de eventos M2M puede ser utilizado para la domótica. Específicamente, las reglas de domótica se pueden definir basándose en el diccionario de eventos M2M genéricos. Esto es más deseable desde la perspectiva de la experiencia del usuario, ya que el usuario no necesita adaptar las reglas de domótica para diferentes proveedores. El componente EMDG puede enviar el diccionario de eventos M2M genéricos generado y, opcionalmente, la asignación real de eventos de dispositivo de IoT, a los otros nodos en la red de IoT. Por ejemplo, el componente EMDG puede enviar el diccionario de eventos M2M a la aplicación de control que proporciona la interfaz de usuario para definir las reglas de domótica, así como a los dispositivos de IoT interesados en tomar medidas basadas en eventos radiodifundidos. Estos dispositivos de IoT pueden programarse para tomar medidas basadas en el diccionario de M2M genéricos a partir de las reglas de domótica. Cuando se reciben los eventos reales radiodifundidos, se asignan a los eventos M2M genéricos para tomar la acción deseada.
[0093] El mecanismo descrito es auto-aprendizaje. Cuando se agrega un nuevo dispositivo de IoT a la red de IoT, el componente EMDG asigna eventos radiodifundidos desde el nuevo dispositivo de IoT a una entrada de diccionario de eventos M2M genéricos ya definida o genera un nuevo conjunto de entradas de diccionario de eventos M2M genéricos para esa clase de dispositivo. Como se describió anteriormente, la asignación de eventos desde el nuevo dispositivo de IoT se realiza basándose en los cambios de estado observados antes y después del evento.
[0094] A continuación se describirán estos y otros aspectos de la divulgación con referencia a la FIG. 8. La FIG. 8 ilustra una red proximal de IoT 800 a modo de ejemplo de acuerdo con al menos un aspecto de la divulgación. La red de IoT 800 incluye un agente de pasarela 802, un EMDG 804 (que puede corresponder al módulo EMDG 210/410), una aplicación de control 806 y cuatro dispositivos de IoT 810. El agente de pasarela 802 se puede instalar en el dispositivo supervisor 130, el SuperAgent 140 o la pasarela 145, por ejemplo. En la FIG. 8, los números de referencia en un círculo indican el orden de las operaciones.
[0095] En la operación 1, los dispositivos 3 y 4, identificados por el número de referencia 810, radiodifunden las notificaciones de evento que son detectadas por el EMDG 804. Como se analizó anteriormente, los dispositivos 3 y 4 pueden radiodifundir los eventos, en cuyo caso el EMDG 804 intercepta las radiodifusiones, o el EMDG 804 puede suscribirse a los eventos publicados por cada dispositivo 810 en la red de IoT 800. En la operación 2, el EMDG 804 recupera y compara los estados de los dispositivos 3 y 4 antes y después de los eventos radiodifundidos. Como se mencionó anteriormente, el EMDG obtiene la información de estado del dispositivo del dispositivo antes y después del evento. En la operación 3, el EMDG 804 crea una asignación de eventos M2M genéricos basándose en los estados del dispositivo antes y después.
[0096] En la operación 4, el EMDG 804 envía el diccionario de eventos M2M genéricos a la aplicación de control 806, que puede instalarse en el teléfono inteligente o dispositivo supervisor 130 del usuario, por ejemplo. También en la operación 4, el EMDG 804 envía el diccionario de eventos M2M genéricos a otros dispositivos 810 en la red de IoT 800, tales como los dispositivos 1 y 2, identificados por el número de referencia 810. Además, la aplicación de control 806 y los dispositivos 810 pueden obtener el diccionario de eventos M2M genéricos del EMDG 804, por ejemplo, obteniendo el diccionario de eventos M2M genéricos al iniciarse.
[0097] En la operación 5, el usuario puede definir reglas de domótica (HA) basándose en el diccionario de eventos M2M genéricos utilizando la aplicación de control 806. Dado que las reglas de domótica se definen utilizando el diccionario de eventos M2M genéricos, solo es necesario mostrar al usuario eventos genéricos y no diferentes tipos de eventos similares de múltiples proveedores. Esto simplifica enormemente la experiencia del usuario para crear reglas de domótica.
[0098] En la operación 6, la aplicación de control 806 propaga las reglas de domótica a otros dispositivos 810 en la red de IoT 800, como los dispositivos 1 y 2. Aunque la FIG. 8 ilustra las reglas de domótica que se propagan a solo dos dispositivos, se apreciará que las reglas pueden propagarse a cualquier número de dispositivos 810 en la red 800, incluyendo todos los dispositivos 810.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0099] En la operación 7, el dispositivo 4 de nuevo radiodifunde un evento. En la operación 8, el dispositivo 2 detecta el evento. En la operación 9, el dispositivo 2 determina que el evento recibido se asigna a un evento genérico en el diccionario de eventos M2M generado. A continuación, el dispositivo 2 ejecuta una o más reglas de domótica definidas para el evento genérico asociado en el diccionario de eventos M2M.
[0100] La FIG. 9 ilustra un flujo a modo de ejemplo para generar automáticamente un diccionario de eventos para un protocolo de comunicación entre dispositivos, tal como un protocolo M2M, en una red de IoT. El flujo ilustrado en la FIG. 9 puede ser realizado por el EMDG 804 en la FIG. 8. En 910, el EMDG 804 recibe una notificación de un evento radiodifundido por un dispositivo de IoT en la red de IoT, tal como uno de los dispositivos de IoT 810 en la FIG. 8. La notificación puede recibirse como una radiodifusión o como un evento de suscripción, por ejemplo.
[0101] En 920, el EMDG 804 determina un estado del dispositivo de IoT antes del evento y un estado del dispositivo de IoT después del evento. El EMDG 804 puede sondear periódicamente el dispositivo de IoT, recuperando así el estado del dispositivo de IoT antes del evento. Inmediatamente después de un evento, el EMDG 804 puede recuperar el estado del dispositivo de IoT independientemente del sondeo periódico. En 930, el EMDG 804 compara el estado del dispositivo de IoT antes del evento con el estado del dispositivo de IoT después del evento.
[0102] En 940, el EMDG 804 determina un tipo de cambio de estado del evento basándose en la comparación en 920. La determinación en 940 puede incluir sondear el dispositivo de IoT para conocer el estado del dispositivo de IoT antes del evento y sondear el dispositivo de IoT para conocer el estado del dispositivo de IoT después del evento.
[0103] En 950, el EMDG 804 determina si hay una entrada en el diccionario de eventos para un tipo de cambio de estado que coincida con el tipo de cambio de estado del evento. Si el EMDG 804 determina que hay una entrada en el diccionario de eventos para el tipo de cambio de estado que coincida con el tipo de cambio de estado del evento, el EMDG 804 no necesita hacer nada y el flujo vuelve al principio.
[0104] Sin embargo, si el EMDG 804 determina que no hay una entrada en el diccionario de eventos para un tipo de cambio de estado que coincida con el tipo de cambio de estado del evento, entonces en 960, el EMDG 804 crea una entrada genérica en el diccionario de eventos para el tipo de cambio de estado del evento. La entrada genérica puede incluir una enumeración y una descripción de texto del tipo de cambio de estado asociado con la entrada genérica. El tipo de cambio de estado asociado con la entrada genérica es común para los dispositivos de IoT del mismo tipo y/o clase que el dispositivo de IoT. En 970, el EMDG 804 almacena una asignación de una descripción de evento del evento con la entrada genérica.
[0105] En un aspecto, el EMDG 804 puede determinar el tipo de dispositivo de IoT. En este caso, determinar si hay una entrada genérica en el diccionario de eventos (950) puede incluir determinar si hay una entrada genérica en el diccionario de eventos para un tipo de dispositivo de IoT que coincida con el tipo del dispositivo de IoT y una tipo de cambio de estado que coincida con el tipo de cambio de estado del evento, y la creación de la entrada genérica en el diccionario de eventos (960) puede incluir la creación de la entrada genérica en el diccionario de eventos basándose en que no haya una entrada genérica en el diccionario de eventos para un tipo de dispositivo de IoT que coincida con el tipo del dispositivo de IoT y un tipo de cambio de estado que coincida con el tipo de cambio de estado del evento.
[0106] Aunque no se ilustra en la FIG. 9, el EMDG 804 puede detectar un segundo evento de un segundo dispositivo de IoT (similar a 910), determinar un estado del segundo dispositivo de IoT antes del segundo evento y un estado del segundo dispositivo de IoT después del segundo evento (similar a 920), comparar el estado del segundo dispositivo de IoT antes del segundo evento con el estado del segundo dispositivo de IoT después del segundo evento (similar a 930), detectar un tipo de cambio de estado del segundo evento basándose en la comparación (similar a 940), asignar el segundo evento a la entrada genérica basándose en que el segundo evento es de un mismo tipo de cambio de estado que el cambio de estado del evento y un mismo tipo y/o clase que el dispositivo de IoT, y almacenar una asignación de una descripción de evento del segundo evento recibido del segundo dispositivo de IoT con la entrada genérica. La descripción de evento del segundo evento recibido del segundo dispositivo de IoT puede ser diferente de una descripción de evento del evento recibido del dispositivo de IoT. La entrada genérica puede describir un cambio de estado genérico común al dispositivo de IoT y el segundo dispositivo de IoT y almacenar descripciones de eventos para eventos recibidos del dispositivo de IoT y el segundo dispositivo de IoT.
[0107] En un aspecto, aunque no se ilustra en la FIG. 9, el EMDG 804 puede transmitir el diccionario de eventos a otros dispositivos de IoT en la red de IoT. El EMDG 804 también puede definir reglas de domótica basadas en eventos genéricos definidos en el diccionario de eventos mediante una aplicación de control, y distribuir las reglas de domótica a otros dispositivos de IoT en la red de IoT. Un tercer dispositivo de IoT en la red de IoT puede recibir una notificación de evento del primer o segundo dispositivo de IoT en la red de IoT, asignar el evento recibido a una entrada genérica en el diccionario de eventos y ejecutar las reglas de domótica definidas para la entrada genérica en el diccionario de eventos.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0108] De acuerdo con un aspecto de la divulgación, la FIG. 10 ilustra un dispositivo de comunicaciones a modo de ejemplo 1000 que puede corresponder a uno o más dispositivos que pueden generar automáticamente un diccionario de eventos para un protocolo de comunicación entre dispositivos en una red de IoT, como se describe en el presente documento (por ejemplo, el agente de pasarela 802 en la FIG. 8, u otro dispositivo que incorpora EMDG 804). En particular, como se muestra en la FIG. 10, el dispositivo de comunicaciones 1000 puede comprender un receptor 1002 que puede recibir una señal de, por ejemplo, una antena de recepción (no mostrada), realizar acciones típicas en la señal recibida (por ejemplo, filtrado, amplificación, conversión descendente, etc.) y digitalizar la señal acondicionada para obtener muestras. El receptor 1002 puede comprender un desmodulador 1004 que pueda desmodular los símbolos recibidos y proporcionarlos a un procesador 1006 para la estimación de canal. El procesador 1006 puede ser un procesador dedicado a analizar la información recibida por el receptor 1002 y/o a generar información para su transmisión mediante un modulador 1018 y un transmisor 1020, un procesador que controle uno o más componentes del dispositivo de comunicaciones 1000 y/o un procesador que analice información recibida por el receptor 1002, genere información para la transmisión mediante el transmisor 1020 y controle uno o más componentes del dispositivo de comunicaciones 1000.
[0109] El dispositivo de comunicaciones 1000 puede comprender adicionalmente una memoria 1008 que esté acoplada de forma operativa al procesador 1006 y que pueda almacenar datos que vayan a transmitirse, datos recibidos, información relativa a los canales disponibles, datos asociados con la señal analizada y/o la intensidad de interferencia, información relativa a un canal asignado, intensidad, velocidad o similar, y cualquier otra información adecuada para estimar un canal y comunicarse a través del canal. La memoria 1008 puede almacenar adicionalmente protocolos y/o algoritmos asociados con la estimación y/o el uso de un canal (por ejemplo, basados en el rendimiento, basados en la capacidad, etc.).
[0110] Se apreciará que la memoria 1008 puede ser memoria volátil o memoria no volátil, o puede incluir tanto memoria volátil como no volátil. A modo de ilustración, y no de limitación, la memoria no volátil puede incluir memoria de solo lectura (ROM), ROM programable (PROM), ROM eléctricamente programable (EPROM), PROM eléctricamente borrable (EEPROM) o memoria flash. La memoria volátil puede incluir memoria de acceso aleatorio (RAM), que actúa como memoria caché externa. A modo de ilustración y no de limitación, la memoria RAM está disponible de muchas formas, tales como RAM síncrona (SRAM), RAM dinámica (DRAM), DRAM síncrona (SDRAM), SDRAM de doble velocidad de transferencia de datos (DDR SDRAM), SDRAM mejorada (ESDRAM), DRAM de enlace síncrono (SLDRAM) y RAM de Rambus directo (DRRAM). La memoria 1008 de los presentes sistemas y procedimientos puede comprender, sin estar limitada a, estos y otros tipos adecuados de memoria.
[0111] En un modo de realización, la memoria 1008 puede almacenar un módulo EMDG 1010. El módulo EMDG 1010 puede ser un módulo de software ejecutable por el procesador 1006. De forma alternativa, el módulo EMDG 1010 puede ser un componente de hardware del procesador 1006, o acoplado a él. Como otra alternativa más, el módulo EMDG 1010 puede ser una combinación de hardware y software. El módulo EMDG 1010 puede corresponder al EMDG 804 en la FIG. 8.
[0112] El dispositivo de comunicaciones 1000 puede incluir además el módulo de bus distribuido 1030 para facilitar el establecimiento de conexiones con otros dispositivos, como el dispositivo de comunicaciones 1000. El módulo de bus distribuido 1030 puede comprender además un módulo de nodo de bus 1032 para ayudar al módulo de bus distribuido 1030 a gestionar las comunicaciones entre múltiples dispositivos. En un aspecto, un módulo de nodo de bus 1032 puede incluir además el módulo de denominación de objeto 1034 para ayudar al módulo de nodo de bus 1032 a comunicarse con las aplicaciones de punto final asociadas con otros dispositivos. Además, el módulo de bus distribuido 1030 puede incluir el módulo de punto final 1036 para ayudar a los puntos finales locales a comunicarse con otros puntos finales locales y/o puntos finales accesibles en otros dispositivos a través de un bus distribuido establecido. En otro aspecto, el módulo de bus distribuido 1030 puede facilitar las comunicaciones entre dispositivos y/o internas a los dispositivos por múltiples transportes disponibles (por ejemplo, Bluetooth, tomas de dominio UNIX, TCP/IP, Wi-Fi, etc.).
[0113] Adicionalmente, en un modo de realización, el dispositivo de comunicaciones 1000 puede incluir una interfaz de usuario 1040, que puede incluir uno o más mecanismos de entrada 1042 para generar entradas en el dispositivo de comunicaciones 1000, y uno o más mecanismos de salida 1044 para generar información para el consumo del usuario del dispositivo de comunicaciones 1000. Por ejemplo, el mecanismo de entrada 1042 puede incluir un mecanismo tal como una tecla o teclado, un ratón, una pantalla táctil, un micrófono, etc. Además, por ejemplo, el mecanismo de salida 1044 puede incluir una pantalla, un altavoz, un mecanismo de respuesta háptica, un transceptor de red de área personal (PAN), etc. En los aspectos ilustrados, el mecanismo de salida 1044 puede incluir un altavoz operable para presentar contenido multimedia en forma de audio, una pantalla operable para presentar contenido multimedia en un formato de imagen o vídeo y/o metadatos temporizados en una forma textual o visual, u otros mecanismos de salida adecuados. Sin embargo, en un modo de realización, donde el dispositivo de comunicaciones 1000 es un dispositivo sin terminal, el dispositivo de comunicaciones 1000 puede no incluir ciertos mecanismos de entrada 1042 y/o mecanismos de salida 1044 porque los dispositivos sin terminal en general se refieren a sistemas o dispositivos informáticos que han sido configurados para operar sin un monitor, teclado y/o ratón.
5
10
15
20
25
30
35
40
45
50
55
60
65
[0114] Donde el dispositivo de comunicaciones 1000 está configurado para generar automáticamente un diccionario de eventos para un protocolo de comunicación entre dispositivos en una red de IoT, como se describe en el presente documento, el receptor 1002, el procesador 1006, la memoria 1008, el módulo EMDG 1010, el transmisor 1020 y el módulo de bus distribuido 1030 puede cooperativamente realizar la funcionalidad descrita en el presente documento. Por ejemplo, tras recibir el receptor 1002 una notificación de un evento radiodifundido por un dispositivo de IoT en la red de IoT, el módulo EMDG 1010 puede, cuando es ejecutado por el procesador 1006, hacer que el procesador 1006 determine un estado del dispositivo de IoT antes del evento y un estado del dispositivo de IoT después del evento, compare el estado del dispositivo de IoT antes del evento con el estado del dispositivo de IoT después del evento, determine un tipo de cambio de estado del evento basándose en la comparación, determine si hay una entrada en el diccionario de eventos para un tipo de cambio de estado que coincida con el tipo de cambio de estado del evento, y cree una entrada genérica en el diccionario de eventos para el tipo de cambio de estado del evento si no hay una entrada en el diccionario de eventos para un tipo de cambio de estado que coincida con el tipo de cambio de estado del evento. La memoria 1008 puede entonces almacenar una asignación de una descripción de evento del evento con la entrada genérica. De forma alternativa, cuando el módulo EMDG 1010 es un módulo de hardware, el módulo EMDG 1010 puede realizar la funcionalidad descrita anteriormente como realizada por el procesador 1006.
[0115] La FIG. 11 ilustra un ejemplo de aparato 1100 representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 1102 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el receptor 1002 en la FIG. 10, como se analiza en el presente documento. Un módulo para determinar 1104 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, como se analiza en el presente documento. Un módulo para comparar 1106 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, como se analiza en el presente documento. Un módulo para determinar 1108 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, como se analiza en el presente documento. Un módulo para determinar 1110 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, como se analiza en el presente documento. Un módulo para crear 1112 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, junto con un sistema de almacenamiento, tal como la memoria 1008 en la FIG. 10, como se analiza en el presente documento. Un módulo para almacenar 1114 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el procesador 1006 y/o el módulo EMDG 1010 en la FIG. 10, junto con un sistema de almacenamiento, tal como la memoria 1008 en la FIG. 10, como se analiza en el presente documento.
[0116] La funcionalidad de los módulos de la FIG. 11 puede implementarse de diversas maneras coherentes con las enseñanzas del presente documento. En algunos diseños, la funcionalidad de estos módulos se puede implementar como uno o más componentes eléctricos. En algunos diseños, la funcionalidad de estos bloques se puede implementar como un sistema de procesamiento que incluye uno o más componentes de procesador. En algunos diseños, la funcionalidad de estos módulos se puede implementar usando, por ejemplo, al menos una parte de uno o más circuitos integrados (por ejemplo, un ASIC). Como se ha analizado en el presente documento, un circuito integrado puede incluir un procesador, software, otros componentes relacionados, o alguna combinación de los mismos. Por lo tanto, la funcionalidad de diferentes módulos puede implementarse, por ejemplo, como subconjuntos diferentes de un circuito integrado, como subconjuntos diferentes de un conjunto de módulos de software, o una combinación de los mismos. Además, se apreciará que un subconjunto dado (por ejemplo, de un circuito integrado y/o de un conjunto de módulos de software) puede proporcionar al menos una parte de la funcionalidad para más de un módulo.
[0117] Además, los componentes y funciones representados por la FIG. 11, así como otros componentes y funciones descritos en el presente documento, pueden implementarse usando cualquier medio adecuado. Dichos medios también pueden implementarse, al menos en parte, usando la estructura correspondiente tal como se explica en el presente documento. Por ejemplo, los componentes descritos anteriormente junto con los componentes del "módulo para" de la FIG. 11 también pueden corresponder a la funcionalidad de "medios para" designada de manera similar. Así pues, en algunos aspectos, uno o más de dichos medios pueden implementarse utilizando uno o más de los componentes de procesador, circuitos integrados u otra estructura adecuada como se explica en el presente documento.
[0118] Los expertos en la materia apreciarán que la información y las señales pueden representarse usando cualquiera de entre una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos y los elementos que puedan haber sido mencionados a lo largo de la descripción anterior pueden representarse mediante voltajes, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos o cualquier combinación de los mismos.
[0119] Además, los expertos en la materia apreciarán que los diversos bloques lógicos, módulos, circuitos y pasos de algoritmo ilustrativos descritos en relación con los aspectos divulgados en el presente documento pueden
5
10
15
20
25
30
35
40
45
50
55
implementarse como hardware electrónico, software informático o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito diversos componentes, bloques, módulos, circuitos y pasos ilustrativos, en general, en lo que respecta a su funcionalidad. Si dicha funcionalidad se implementa como hardware o software depende de la aplicación particular y de las restricciones de diseño impuestas al sistema global. Los expertos en la materia pueden implementar la funcionalidad descrita de diversas maneras para cada aplicación particular, pero tales decisiones de implementación no deben interpretarse como apartadas del alcance de la presente divulgación.
[0120] Los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los aspectos divulgados en el presente documento pueden implementarse o realizarse con un procesador de propósito general, un procesador de señales digitales (DSP), un circuito integrado específico de la aplicación (ASIC), una matriz de puertas programables in situ (FPGA) u otro dispositivo de lógica programable, lógica de transistor o de puertas discretas, componentes de hardware discretos o cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador pero, de forma alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también puede implementarse como una combinación de dispositivos informáticos (por ejemplo, una combinación de un dSp y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de dSp o cualquier otra configuración de este tipo).
[0121] Los procedimientos, las secuencias y/o los algoritmos descritos en relación con los aspectos divulgados en el presente documento pueden realizarse directamente en hardware, en un módulo de software ejecutado por un procesador o en una combinación de los dos. Un módulo de software puede residir en una RAM, una memoria flash, una ROM, una EPROM, una EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o en cualquier otra forma de medio de almacenamiento conocida en la técnica. Un medio de almacenamiento a modo de ejemplo está acoplado al procesador de tal manera que el procesador puede leer información del medio de almacenamiento y escribir información en el mismo. De forma alternativa, el medio de almacenamiento puede estar integrado en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un dispositivo de IoT. De forma alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.
[0122] En uno o más aspectos a modo de ejemplo, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de estos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir a través de, un medio legible por ordenador, como una o más instrucciones o códigos. Los medios legibles por ordenador incluyen tanto medios de almacenamiento informático como medios de comunicación, incluido cualquier medio que facilita la transferencia de un programa informático de un lugar a otro. Un medio de almacenamiento puede ser cualquier medio disponible al que pueda accederse mediante un ordenador. A modo de ejemplo y no de limitación, dichos medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otros dispositivos de almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda usarse para transportar o almacenar un código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador. Además, cualquier conexión recibe debidamente la denominación de medio legible por ordenador. Por ejemplo, si el software se transmite desde un sitio web, servidor u otra fuente remota, usando un cable coaxial, un cable de fibra óptica, un par trenzado, una DSL o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas, se incluyen en la definición de medio. La palabra disco, como se usa en el presente documento, incluye CD, disco láser, disco óptico, DVD, disquete y disco Blu-ray donde los discos usualmente reproducen datos magnética y/u ópticamente con láser. Las combinaciones de los anteriores deberían incluirse también dentro del alcance de los medios legibles por ordenador.
[0123] Aunque la divulgación anterior representa unos aspectos ilustrativos de la divulgación, debe observarse que pueden realizarse diversos cambios y modificaciones en el presente documento sin apartarse del alcance de la divulgación definido en las reivindicaciones adjuntas. Las funciones, los pasos y/o las acciones de las reivindicaciones de procedimiento de acuerdo con los aspectos de la divulgación descritos en el presente documento no tienen que llevarse a cabo en un orden particular. Además, aunque los elementos de la divulgación pueden describirse o reivindicarse en singular, se contempla el plural a no ser que se indique explícitamente la limitación al singular.

Claims (12)

10
15
20
25
2.
30
3.
35
40 4.
5.
45
50
55
60
6.
REIVINDICACIONES
Un procedimiento para generar automáticamente un diccionario de eventos en una red de Internet de las cosas, IoT, que comprende:
recibir (910) una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT; determinar (920) un estado del primer dispositivo de IoT antes y después del primer evento; caracterizado por:
comparar (930) los estados del primer dispositivo de IoT;
determinar (940) un tipo de cambio de estado del primer evento basado en la comparación;
determinar (950) si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos;
crear (960) una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos; y
almacenar (970), en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica para todos los dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT.
El procedimiento según la reivindicación 1,
en el que determinar el estado del primer dispositivo de IoT antes del primer evento incluye sondear periódicamente el primer dispositivo de IoT para recuperar el estado del primer dispositivo de IoT antes del primer evento, y
en el que determinar el estado del primer dispositivo de IoT después del primer evento incluye recuperar el estado del primer dispositivo de IoT después del primer evento.
El procedimiento según la reivindicación 1, que comprende además:
determinar un tipo del primer dispositivo de IoT, en el que la creación comprende la creación de la entrada genérica en el diccionario de eventos para un tipo de dispositivo de IoT que coincida con el tipo del primer dispositivo de IoT y un tipo de cambio de estado que coincida con el tipo de cambio de estado del primer evento.
El procedimiento según la reivindicación 1, en el que la entrada genérica comprende una enumeración y una descripción de texto del tipo de cambio de estado asociado con la entrada genérica.
El procedimiento según la reivindicación 1, que comprende además:
recibir una segunda notificación de un segundo evento mediante un segundo dispositivo de IoT en la red de IoT;
determinar un estado del segundo dispositivo de IoT antes y después del segundo evento; comparar los estados del segundo dispositivo de IoT;
determinar un tipo de cambio de estado del segundo evento basándose en la comparación;
asignar el segundo evento a la entrada genérica basándose en el segundo evento siendo un mismo tipo de cambio de estado que el cambio de estado del primer evento y un mismo tipo y/o clase que el primer dispositivo de IoT; y
almacenar una asignación de una descripción de evento del segundo evento recibido desde el segundo dispositivo de IoT a la entrada genérica.
El procedimiento según la reivindicación 5, en el que la descripción de evento del segundo evento es diferente de la descripción de evento del primer evento.
El procedimiento según la reivindicación 5, en el que la entrada genérica describe un cambio de estado genérico que es común para el primer dispositivo de IoT y el segundo dispositivo de IoT, y además en el que
5
10
15
20
25
30
35
40
45
50
55
60
65
la entrada genérica incluye descripciones de eventos para eventos recibidos del primer dispositivo de loT y del segundo dispositivo de IoT.
8. El procedimiento según la reivindicación 1, que comprende además: transmitir el diccionario de eventos a otros dispositivos de IoT en la red de IoT.
9. El procedimiento según la reivindicación 8, que comprende además:
definir las reglas de domótica basadas en eventos genéricos definidos en el diccionario de eventos; y distribuir las reglas de domótica a los otros dispositivos de IoT en la red de IoT.
10. El procedimiento según la reivindicación 9, en el que un tercer dispositivo de IoT en la red de IoT recibe una notificación de evento del primer o el segundo dispositivo de IoT en la red de IoT, asigna la información del evento en la notificación de evento recibido a la entrada genérica en el diccionario de eventos, y ejecuta las reglas de domótica definidas para la entrada genérica en el diccionario de eventos.
11. Un aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas, IoT, que comprende:
medios para recibir una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT;
medios para determinar un estado del primer dispositivo de IoT antes y después del primer evento; caracterizado por:
medios para comparar los estados del primer dispositivo de IoT;
medios para determinar un tipo de cambio de estado del primer evento basándose en una comparación de los estados del primer dispositivo de IoT;
medios para determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos;
medios para crear una entrada genérica basándose en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos; y
medios para almacenar, en el diccionario de eventos, una asignación de una descripción de evento del primer evento en la entrada genérica para todos los dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT.
12. Un aparato según la reivindicación 11 para generar automáticamente un diccionario de eventos en una red de Internet de las cosas, IoT, en la que:
el medio para recibir es un transceptor configurado para recibir una notificación de un primer evento desde un primer dispositivo de IoT en la red de IoT; y caracterizado por:
al menos un procesador configurado para funcionar como:
los medios para determinar un estado del primer dispositivo de IoT antes y después del primer evento; los medios para comparar los estados del primer dispositivo de IoT;
los medios para determinar un tipo de cambio de estado del primer evento basándose en la comparación de los estados del primer dispositivo de IoT;
los medios para determinar si el tipo de cambio de estado del primer evento está presente en el diccionario de eventos; y
los medios para crear una entrada genérica basada en el tipo de cambio de estado del primer evento que no está presente en el diccionario de eventos; y
el medio para almacenar es una memoria configurada para almacenar, en el diccionario de eventos, una asignación de una descripción de evento del primer evento a la entrada genérica para todos los dispositivos de IoT de un mismo tipo y/o clase que el primer dispositivo de IoT.
13. El aparato según la reivindicación 12,
en el que el al menos un procesador que está configurado para determinar el estado del primer dispositivo de loT antes del primer evento incluye el al menos un procesador que está configurado para sondear periódicamente el primer dispositivo de IoT para recuperar el estado del primer dispositivo de IoT antes del 5 primer evento, y
en el que el al menos un procesador que está configurado para determinar el estado del primer dispositivo de IoT después del primer evento incluye que el al menos un procesador esté configurado para recuperar el estado del primer dispositivo de IoT después del primer evento.
10 14. El aparato según la reivindicación 12, en el que el al menos un procesador está configurado además para
determinar un tipo del primer dispositivo de IoT, en el que el al menos un procesador que esté configurado para crear comprende el al menos un procesador que está configurado para crear la entrada genérica en el diccionario de eventos para un tipo de dispositivo de IoT que coincida con el tipo del primer dispositivo de IoT y un tipo de cambio de estado que coincida con el tipo de cambio de estado del primer evento.
15
15. Un medio legible por ordenador no transitorio para generar automáticamente un diccionario de eventos en una red Internet de las cosas, IoT, que comprende instrucciones que, cuando son ejecutadas por un ordenador, realizan el procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 10.
20
ES15753810.9T 2014-08-11 2015-08-07 Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT) Active ES2681629T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462035580P 2014-08-11 2014-08-11
US201462035580P 2014-08-11
US14/820,370 US10001759B2 (en) 2014-08-11 2015-08-06 Method and apparatus for automatically generating an events dictionary in an internet of things (IOT) network
US201514820370 2015-08-06
PCT/US2015/044340 WO2016025336A1 (en) 2014-08-11 2015-08-07 Method and apparatus for automatically generating an events dictionary in an internet of things (iot) network

Publications (1)

Publication Number Publication Date
ES2681629T3 true ES2681629T3 (es) 2018-09-14

Family

ID=55267365

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15753810.9T Active ES2681629T3 (es) 2014-08-11 2015-08-07 Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT)

Country Status (10)

Country Link
US (1) US10001759B2 (es)
EP (1) EP3180902B1 (es)
JP (1) JP6640833B2 (es)
KR (1) KR102552789B1 (es)
CN (1) CN106576220B (es)
AU (1) AU2015301975B2 (es)
BR (1) BR112017002283B1 (es)
ES (1) ES2681629T3 (es)
HU (1) HUE039764T2 (es)
WO (1) WO2016025336A1 (es)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150074195A1 (en) * 2013-09-09 2015-03-12 Qualcomm Incorporated Increasing power savings through intelligent synchronizing of data
FR3031209A1 (fr) * 2014-12-24 2016-07-01 Orange Gestion d'entites electroniques pour la creation d'un fil d'actualites
US20160197769A1 (en) * 2015-01-06 2016-07-07 Kiban Labs, Inc. System and method for filtering events at an iot hub
US10816944B2 (en) 2015-01-06 2020-10-27 Afero, Inc. System and method for using data collected from internet-of-things (IoT) sensors to disable IoT-enabled home devices
US9774497B2 (en) 2015-01-06 2017-09-26 Afero, Inc. System and method for implementing internet of things (IOT) remote control applications
US9860681B2 (en) 2015-01-06 2018-01-02 Afero, Inc. System and method for selecting a cell carrier to connect an IOT hub
US9774507B2 (en) 2015-01-06 2017-09-26 Afero, Inc. System and method for collecting and utilizing user behavior data within an IoT system
US9729340B2 (en) 2015-01-06 2017-08-08 Afero, Inc. System and method for notifying a user of conditions associated with an internet-of-things (IoT) hub
US9933768B2 (en) 2015-01-06 2018-04-03 Afero, Inc. System and method for implementing internet of things (IOT) remote control applications
US10547503B2 (en) * 2015-07-30 2020-01-28 Cisco Technology, Inc. Network connected device usage profile management
US11720571B2 (en) * 2015-08-17 2023-08-08 Comcast Cable Communications, Llc Unified description scheme for controlling and operating network connected devices
US10742739B2 (en) 2015-08-18 2020-08-11 Comcast Cable Communications, Llc Platform for controlling and operating network connected devices
US9537914B1 (en) * 2015-12-01 2017-01-03 International Business Machines Corporation Vehicle domain multi-level parallel buffering and context-based streaming data pre-processing system
GB2559310B (en) * 2016-03-11 2021-10-06 Tridonic Gmbh & Co Kg Building technology device communication system with IoT-network devices
US10270875B1 (en) * 2016-09-19 2019-04-23 Amazon Technologies, Inc. Dynamic grouping of device representations
US10270738B1 (en) * 2016-09-19 2019-04-23 Amazon Technologies, Inc. Aggregated group state for a group of device representations
US10887174B2 (en) * 2016-09-19 2021-01-05 Amazon Technologies, Inc. Group command management for device groups
US10320583B2 (en) * 2016-10-07 2019-06-11 Verizon Patent And Licensing Inc. System and method for facilitating interoperability across internet of things (IOT) domains
FR3058540A1 (fr) * 2016-11-10 2018-05-11 Orange Procede de gestion d'autorisation dans une communaute d'objets connectes
US10057880B2 (en) * 2016-12-11 2018-08-21 Qualcomm Incorporated Smart notifications between devices
US10394578B2 (en) 2017-01-20 2019-08-27 International Business Machines Corporation Internet of things device state and instruction execution
US20180212791A1 (en) * 2017-01-25 2018-07-26 Sears Brands, L.L.C. Contextual application interactions with connected devices
US10555258B2 (en) * 2017-03-13 2020-02-04 At&T Intellectual Property I, L.P. User-centric ecosystem for heterogeneous connected devices
US10594585B2 (en) 2017-03-20 2020-03-17 Comcast Cable Communications, Llc Methods and systems for polling devices
US11294786B2 (en) 2017-03-31 2022-04-05 Commvault Systems, Inc. Management of internet of things devices
US11221939B2 (en) 2017-03-31 2022-01-11 Commvault Systems, Inc. Managing data from internet of things devices in a vehicle
US10552294B2 (en) * 2017-03-31 2020-02-04 Commvault Systems, Inc. Management of internet of things devices
KR101965779B1 (ko) * 2017-04-27 2019-04-24 (주)빅데이터연구소 스마트 홈 시스템 및 이의 제어 방법
US10635108B2 (en) * 2017-07-03 2020-04-28 Baidu Usa Llc Centralized scheduling system using global store for operating autonomous driving vehicles
JP2019028599A (ja) * 2017-07-27 2019-02-21 キヤノン株式会社 情報処理システムおよび制御方法
EP3451626B1 (en) * 2017-08-31 2021-11-17 FIMER S.p.A. Method and system for data stream processing
CN111052710B (zh) * 2017-09-06 2023-11-07 康维达无线有限责任公司 用于物联网可配置事件和动作排序框架的装置和方法
US10587482B2 (en) * 2017-09-18 2020-03-10 International Business Machines Corporation Discovery of IoT devices
US10644961B2 (en) 2018-01-12 2020-05-05 Intel Corporation Self-adjusting data processing system
US10728340B2 (en) * 2018-03-29 2020-07-28 Servicenow, Inc. Internet of things (IOT) platform for device configuration management and support
TWI678092B (zh) * 2018-04-27 2019-11-21 奇邑科技股份有限公司 長距離全雙工無線通訊方法與通訊系統
WO2019216874A1 (en) 2018-05-07 2019-11-14 Google Llc Methods, systems, and apparatus for providing composite graphical assistant interfaces for controlling connected devices
CN109040171A (zh) * 2018-06-14 2018-12-18 厦门理工学院 一种事件响应系统、方法、设备以及存储介质
CN109104495A (zh) * 2018-09-16 2018-12-28 安徽三实软件科技有限公司 一种房屋智能管家应用系统及其使用方法
US10839411B2 (en) * 2018-12-21 2020-11-17 Noodle Technology Inc. Validation in a decentralized network
KR102156281B1 (ko) * 2019-01-04 2020-09-15 고려대학교 세종산학협력단 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)의 정의
US11341463B2 (en) 2019-11-25 2022-05-24 International Business Machines Corporation Blockchain ledger entry upon maintenance of asset and anomaly detection correction
US11449811B2 (en) 2019-11-25 2022-09-20 International Business Machines Corporation Digital twin article recommendation consultation
US11291077B2 (en) * 2019-11-25 2022-03-29 International Business Machines Corporation Internet of things sensor major and minor event blockchain decisioning
US11954701B2 (en) 2020-03-23 2024-04-09 Visa International Service Association Real-time merchandising system
WO2021201398A1 (ko) * 2020-04-03 2021-10-07 삼성전자 주식회사 Iot 장치들의 인스트럭션 공유 방법 및 전자 장치
KR20220083221A (ko) 2020-12-11 2022-06-20 삼성전자주식회사 IoT 환경의 허브 장치 및 로컬 네트워크 기반 이벤트 처리 방법
US11442692B1 (en) 2021-03-16 2022-09-13 International Business Machines Corporation Acoustic workflow system distribution
US11915708B2 (en) 2021-03-18 2024-02-27 Samsung Electronics Co., Ltd. Methods and systems for invoking a user-intended internet of things (IoT) device from a plurality of IoT devices
US12177082B2 (en) * 2021-03-22 2024-12-24 Apple Inc. Techniques for reacting to device event state changes that are shared over a network of user devices
TWI820985B (zh) * 2022-10-28 2023-11-01 犀動智能科技股份有限公司 物聯網設備整合控制系統及物聯網設備整合控制方法
US12363059B2 (en) * 2023-07-31 2025-07-15 Cariad Se Messaging system for computing devices
WO2025258709A1 (ko) * 2024-06-12 2025-12-18 엘지전자 주식회사 홈 네트워크 시스템에서 그룹을 설정하는 장치 및 방법

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044502A (ja) * 2001-07-30 2003-02-14 Nippon Telegr & Teleph Corp <Ntt> オントロジー対応情報生成装置、方法、プログラム、記憶媒体
US20070061406A1 (en) 2003-05-30 2007-03-15 Seung-Myun Baek Home network system
JP2005310031A (ja) * 2004-04-26 2005-11-04 Nippon Telegr & Teleph Corp <Ntt> 通信装置における入力イベント制御装置及び通信装置間の遠隔制御装置並びに制御装置プログラム
GB0411528D0 (en) 2004-05-24 2004-06-23 Koninkl Philips Electronics Nv Device abstraction layer for local networking system
US7480746B2 (en) 2005-09-06 2009-01-20 Home Xperience, Inc. Extensible universal home automation integration framework and user interface
BR112012022204B1 (pt) * 2010-03-01 2022-04-19 IOT Holdings, Inc Gateway entre máquinas
CN102238573A (zh) * 2010-04-30 2011-11-09 中兴通讯股份有限公司 一种m2m业务的架构及实现m2m业务的方法
US20130054863A1 (en) * 2011-08-30 2013-02-28 Allure Energy, Inc. Resource Manager, System And Method For Communicating Resource Management Information For Smart Energy And Media Resources
US8671099B2 (en) * 2011-12-28 2014-03-11 International Business Machines Corporation Clustering devices in an internet of things (‘IoT’)
CN102651020B (zh) * 2012-03-31 2014-01-15 中国科学院软件研究所 一种海量传感器数据存储与查询方法
KR101392868B1 (ko) * 2012-07-11 2014-05-09 전자부품연구원 사물 인터넷 서비스 제공방법
WO2014035432A2 (en) 2012-08-31 2014-03-06 Nest Labs, Inc. Dynamic distributed-sensor network for forecasting external events
CN102915346B (zh) * 2012-09-26 2015-07-01 中国科学院软件研究所 面向物联网智能感知的数据索引建立与查询方法
KR101558236B1 (ko) * 2012-10-16 2015-10-12 전자부품연구원 ＩｏＴ 브라우징 방법 및 장치
US9769034B2 (en) * 2012-12-14 2017-09-19 Futurewei Technologies, Inc. Method and apparatus for policy based routing in information centric networking based home networks
US10015293B2 (en) * 2013-02-08 2018-07-03 Iot Holdings, Inc. Method and apparatus for incorporating an internet of things (IoT) service interface protocol layer in a node
US10057173B2 (en) * 2013-05-28 2018-08-21 Convida Wireless, Llc Load balancing in the Internet of things
US9600571B2 (en) * 2013-07-11 2017-03-21 Neura, Inc. Interoperability mechanisms for internet of things integration platform
US9774709B2 (en) * 2013-11-18 2017-09-26 Cable Television Laboratories, Inc. Service discovery
US20150381737A1 (en) * 2014-06-30 2015-12-31 Davra Networks Limited Gateway device and a gateway system for an internet-of-things environment

Also Published As

Publication number Publication date
AU2015301975B2 (en) 2018-11-29
CN106576220B (zh) 2020-01-03
CN106576220A (zh) 2017-04-19
KR102552789B1 (ko) 2023-07-06
BR112017002283B1 (pt) 2023-05-02
AU2015301975A1 (en) 2017-02-02
BR112017002283A2 (pt) 2018-02-06
HUE039764T2 (hu) 2019-02-28
US10001759B2 (en) 2018-06-19
EP3180902B1 (en) 2018-05-16
US20160041534A1 (en) 2016-02-11
KR20170041743A (ko) 2017-04-17
JP2017531357A (ja) 2017-10-19
EP3180902A1 (en) 2017-06-21
JP6640833B2 (ja) 2020-02-05
WO2016025336A1 (en) 2016-02-18

Similar Documents

Publication Publication Date Title
ES2681629T3 (es) Procedimiento y aparato para generar automáticamente un diccionario de eventos en una red de Internet de las cosas (IoT)
ES2843574T3 (es) Activación de comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas
US9628691B2 (en) Method and apparatus for identifying a physical IoT device
EP3175641B1 (en) On-boarding a device to a secure local network
EP3047616B1 (en) A user interactive application enabled gateway
US9979606B2 (en) Behavioral analysis to automate direct and indirect local monitoring of internet of things device health
US9954679B2 (en) Using end-user federated login to detect a breach in a key exchange encrypted channel
JP6622716B2 (ja) ユーザプリファレンスまたはデバイス構成を設定するための方法および装置
JP6453338B2 (ja) データのインテリジェント同期による省電力化の向上
US20150071052A1 (en) Reconfiguring a headless wireless device
US20150256385A1 (en) System and method for providing a human readable representation of an event and a human readable action in response to that event
WO2016070106A1 (en) Dynamic mobile ad hoc internet of things (iot) gateway
CN106464692B (zh) 确定对接收授权的设备的信任级别
HK1232713B (zh) 用於自動生成物聯網(iot)網絡中的事件字典的方法和裝置
HK1232713A1 (en) Method and apparatus for automatically generating an events dictionary in an internet of things (iot) network