ES2843574T3 - Activación de comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas - Google Patents

Abstract

Un procedimiento para activar comandos basados en notificaciones de eventos, que comprende: identificar (1146, 1342), en un dispositivo de control (1120, 1320), una notificación de eventos soportada en un dispositivo de origen (1110, 1310); identificar, en el dispositivo de control (1120, 1320), uno o más comandos soportados en un dispositivo objetivo (1130, 1330); mostrar en el dispositivo de control uno o más comandos para que los seleccione un usuario; definir (1148, 1346), en el dispositivo de control, un activador que vincula la notificación de eventos soportada en el dispositivo de origen a un comando seleccionado por el usuario de uno o más comandos soportados en el dispositivo objetivo, en el que el activador definido hace que el dispositivo objetivo ejecute el comando identificado en respuesta al dispositivo de origen que radiodifunde la notificación del evento identificado; el procedimiento caracterizado por comprender además transmitir (1150), desde el dispositivo de control (1120) al dispositivo de origen (1110), el activador que vincula la notificación de eventos soportada en el dispositivo de origen (1110) con el comando soportado en el dispositivo objetivo (1130), en el que el activador transmitido hace que el dispositivo de origen (1110) invoque directamente el comando en el dispositivo objetivo (1130), sin comunicarse con el dispositivo de control, cuando el dispositivo de origen radiodifunde (1152) la notificación del evento identificado.

Description

DESCRIPCIÓN

Activación de comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas

CAMPO TÉCNICO

[0001] Varios modos de realización descritos en el presente documento se refieren en general a la activación de comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas desde un dispositivo de origen.

ANTECEDENTES

[0002] Internet es un sistema global de ordenadores y redes informáticas interconectados que usan una familia 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í. Un ejemplo de una red se divulga en el documento WO 2009/079036 que analiza un administrador de sensores para redes cableadas e inalámbricas. Internet de las cosas (IoT) se basa en la idea de que los objetos cotidianos, no solo los ordenadores y redes informáticas, pueden ser legibles, reconocibles, localizables, direccionables y controlables por medio de una red de comunicaciones IoT (por ejemplo, un sistema ad hoc o Internet).

[0003] Varias tendencias de mercado están impulsando el desarrollo de dispositivos IoT. Por ejemplo, el aumento de los costes energéticos está impulsando las inversiones estratégicas de los gobiernos en redes inteligentes y en el soporte para el consumo futuro, tales como vehículos eléctricos y estaciones de carga públicas. El aumento de los costes de atención médica y el envejecimiento de la población están impulsando el desarrollo de servicios de preparación física y de atención médica remotos/conectados. Una revolución tecnológica en el hogar está impulsando el desarrollo de nuevos servicios "inteligentes", incluida la consolidación por parte de proveedores de servicios que ofrecen ’N' play (por ejemplo, datos, voz, vídeo, seguridad, administración de energía, etc.) y la ampliación de redes domésticas. Los edificios se están volviendo más inteligentes y más prácticos como medio para reducir los costes operativos de las instalaciones empresariales.

[0004] 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, al tiempo que los clientes pueden administrar mejor el uso de energía. En el área de la automatización de viviendas y edificios, las viviendas y edificios inteligentes pueden tener un control centralizado sobre prácticamente cualquier dispositivo o sistema en la vivienda 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 supervisar de forma remota la salud de los pacientes, mientras que las personas pueden seguir el progreso de rutinas de entrenamiento.

[0005] En consecuencia, en un futuro cercano, 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 y espacios personales. En ese contexto, muchos usuarios pueden interactuar con diferentes dispositivos dentro de entornos particulares de formas interrelacionadas. Sin embargo, las soluciones existentes tienden a quedarse cortas en cuanto a proporcionar mecanismos para vincular notificaciones de eventos y comandos de control que soportan dispositivos heterogéneos para automatizar actividades comunes o rutinarias que pueden estar relacionadas lógicamente. Por ejemplo, durante el invierno, muchas personas bajan la temperatura del termostato del hogar durante la noche para ahorrar en costos de calefacción y luego aumentan la temperatura al despertarse por la mañana. Como tal, una solución que pudiera aumentar automáticamente la temperatura en el termostato en respuesta a una notificación de eventos que indica que un usuario acaba de despertarse (por ejemplo, un despertador sonando) eliminaría la necesidad de que el usuario aumente manualmente la temperatura por la mañana y además elimina o reduce sustancialmente la necesidad de configurar el termostato para aumentar la temperatura de acuerdo con un programa. Aunque existen ciertas soluciones que soportan notificaciones de eventos y comandos de control (por ejemplo, la implementación de un servicio de Internet de las cosas descrito en el documento EP 2563 092), las soluciones existentes tienden a carecer de mecanismos que permitan a los usuarios vincular o encadenar notificaciones de eventos y comandos de control de manera que ciertos eventos o comandos de control se invocan cuando ocurren uno o más eventos desencadenantes específicos. El documento US 2007/0124424 divulga un programa y un dispositivo para vincular operaciones entre múltiples dispositivos conectados.

BREVE EXPLICACIÓN

[0006] La presente divulgación está dirigida a procedimientos, dispositivos y medios de almacenamiento, cuyas características se exponen en el conjunto de reivindicaciones adjunto. Lo siguiente presenta una breve explicación simplificada relacionada con uno o más aspectos y/o modos de realización divulgados en el presente documento.

De este modo, la siguiente breve explicación no se debe considerar una visión general extensa en relación con todos los aspectos y/o modos de realización contemplados, ni se debe considerar la siguiente breve explicación para identificar elementos clave o esenciales en relación con todos los aspectos y/o modos de realización contemplados ni para delimitar el alcance asociado con cualquier aspecto y/o modo de realización particular. En consecuencia, la siguiente breve explicación tiene el único propósito de presentar determinados conceptos en relación con uno o más aspectos y/o modos de realización en relación con los mecanismos divulgados en el presente documento de una forma simplificada para preceder a la descripción detallada presentada a continuación.

[0007] De acuerdo con un aspecto a modo de ejemplo, la siguiente descripción se refiere en general a varios mecanismos que pueden usarse para activar comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas desde un dispositivo de origen. Más particularmente, debido a que el creciente desarrollo de las tecnologías de Internet de las cosas (IoT) hará que numerosos dispositivos de IoT rodeen a un usuario en el hogar, en los vehículos, en el trabajo y en muchas otras ubicaciones y espacios personales en un futuro próximo, muchos usuarios interactuarán con diferentes dispositivos dentro de entornos particulares de formas interrelacionadas. Por consiguiente, varios mecanismos descritos con más detalle en el presente documento pueden permitir a los usuarios vincular notificaciones de eventos y comandos de control que soportan dispositivos heterogéneos para automatizar actividades comunes, rutinarias o relacionadas lógicamente de otro modo. Por ejemplo, en varios modos de realización, cuando una notificación de eventos radiodifundida desde un dispositivo de origen llega a un dispositivo de control (por ejemplo, un teléfono inteligente u otro dispositivo adecuado), se le puede presentar al usuario una opción para vincular la notificación de eventos a comandos que pueden activarse en un dispositivo objetivo y, por lo tanto, controlar el dispositivo objetivo. Como tal, en respuesta a que el usuario seleccione la opción para vincular la notificación del evento a un comando en uno o más de otros dispositivos, se le puede mostrar al usuario uno o más dispositivos objetivo controlables que soportan comandos que se pueden vincular a la notificación del evento y al el usuario puede a continuación seleccionar o definir de otro modo los comandos particulares para activarse automáticamente en los dispositivos objetivo controlables cuando la notificación del evento vuelva a ocurrir en el futuro. Por ejemplo, en un caso de uso, el dispositivo de control puede almacenar la definición de activación de modo que el dispositivo de control pueda llamar automáticamente o invocar de otro modo el comando en los dispositivos objetivo controlables en respuesta a que el dispositivo de origen radiodifunda la notificación del evento vinculado nuevamente en el futuro. En otro caso de uso, el dispositivo de control puede enviar la definición de activación y el comando vinculado a la notificación del evento al dispositivo de origen que radiodifundió originalmente la notificación del evento, en el que el dispositivo de origen puede invocar el comando vinculado en los dispositivos objetivo controlables al radiodifundir nuevamente la notificación de eventos en el futuro. En otro caso de uso más, el dispositivo de control puede configurar un oyente en los dispositivos objetivo controlables de manera que los dispositivos objetivo controlables puedan escuchar la notificación del evento desde el dispositivo de origen de radiodifusión y a continuación invocar el comando vinculado en respuesta al oyente configurado local que detecta el notificación de eventos radiodifundida desde el dispositivo de origen.

[0008] De acuerdo con otro aspecto a modo de ejemplo, un procedimiento para activar comandos basados en notificaciones de eventos puede comprender identificar, en un dispositivo de control, una notificación de eventos soportada en un primer dispositivo, identificar, en el dispositivo de control, un comando soportado en un segundo dispositivo, y definir, en el dispositivo de control, un activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador definido hace que el segundo dispositivo ejecute el comando identificado en respuesta al primer dispositivo que radiodifunde la notificación de eventos identificado. Además, en varios modos de realización, el procedimiento puede comprender además almacenar el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo en el dispositivo de control, detectar una radiodifusión desde el primer dispositivo que incluye la notificación de eventos identificado en el dispositivo de control, y transmitir, desde el dispositivo de control al segundo dispositivo, un mensaje que hace que el segundo dispositivo ejecute el comando asociado con el activador almacenado en respuesta a la detección de la radiodifusión que incluye la notificación del evento identificado. En modos de realización alternativos (o adicionales), el procedimiento puede comprender además transmitir, desde el dispositivo de control al primer dispositivo, el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador transmitido hace que el primer dispositivo invoque el comando en el segundo dispositivo cuando el primer dispositivo radiodifunde la notificación del evento identificado y/o configurar, mediante el dispositivo de control, un oyente asociado con el activador definido en el segundo dispositivo, en el que el oyente configurado hace que el segundo dispositivo escuche la notificación del evento identificado y ejecute el comando identificado en respuesta a la detección de que el primer dispositivo radiodifundió la notificación del evento vinculada al comando identificado. Además, en varios modos de realización, definir el activador que vincula la notificación de eventos en el primer dispositivo al comando en el segundo dispositivo puede comprender además desactivar uno o más activadores existentes que vinculan la notificación de eventos identificados a uno o más comandos que entran en conflicto con el comando. en el segundo dispositivo.

[0009] De acuerdo con otro aspecto a modo de ejemplo, un dispositivo de control para activar comandos basados en notificaciones de eventos puede comprender medios para identificar una notificación de eventos soportada en un primer dispositivo, medios para identificar un comando soportado en un segundo dispositivo y medios para definir un activador que vincule el notificación de eventos soportada en el primer dispositivo al comando soportado en el segundo dispositivo, en el que el activador definido hace que el segundo dispositivo ejecute el comando identificado en respuesta al primer dispositivo que radiodifunde la notificación de eventos identificado. Además, en varios modos de realización, el dispositivo de control puede comprender además medios para almacenar el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, medios para detectar una radiodifusión desde el primer dispositivo que incluye la notificación del evento identificado, y medios para transmitir, al segundo dispositivo, un mensaje que hace que el segundo dispositivo ejecute el comando asociado con el activador almacenado en respuesta a la detección de la radiodifusión que incluye la notificación del evento identificado. En modos de realización alternativos (o adicionales), el dispositivo de control puede comprender además medios para transmitir, al primer dispositivo, el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador transmitido hace que el primer dispositivo invoque el comando en el segundo dispositivo cuando el primer dispositivo radiodifunde la notificación del evento identificado y/o medios para configurar un oyente asociado con el activador definido en el segundo dispositivo, en el que el oyente configurado hace que el segundo dispositivo escuche la notificación de eventos identificada y ejecute el comando identificado en respuesta a la detección de que el primer dispositivo radiodifundió la notificación de eventos vinculada al comando identificado. Además, en varios modos de realización, los medios para definir el activador que vincula la notificación de eventos en el primer dispositivo con el comando en el segundo dispositivo pueden desactivar uno o más activadores existentes que vinculan la notificación de eventos identificados a un comando que entra en conflicto con el comando soportado. en el segundo dispositivo.

[0010] De acuerdo con otro aspecto a modo de ejemplo, un aparato puede comprender uno o más procesadores configurados para identificar una notificación de eventos soportada en un primer dispositivo, identificar un comando soportado en un segundo dispositivo y definir un activador que vincule la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador definido hace que el segundo dispositivo ejecute el comando identificado en respuesta al primer dispositivo que radiodifunde la notificación del evento identificado. Además, en varios modos de realización, el aparato puede comprender además una memoria configurada para almacenar el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo y un transceptor configurado para recibir una radiodifusión desde el primer dispositivo que incluye la notificación del evento identificado y transmite, al segundo dispositivo, un mensaje que hace que el segundo dispositivo ejecute el comando asociado con el activador almacenado en respuesta a la recepción de la radiodifusión que incluye la notificación del evento identificado. En modos de realización alternativos (o adicionales), el transceptor puede configurarse para transmitir, al primer dispositivo, el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador transmitido hace que el primer dispositivo invoque el comando en el segundo dispositivo cuando el primer dispositivo radiodifunde la notificación del evento identificado y/o para comunicarse con el segundo dispositivo para configurar un oyente asociado con el activador definido en el segundo dispositivo, en el que el oyente configurado hace que el segundo dispositivo escuche la notificación del evento identificado y ejecute el comando identificado en respuesta a la detección de que el primer dispositivo radiodifundió la notificación del evento vinculada al comando identificado. Además, en varios modos de realización, el uno o más procesadores pueden configurarse además para desactivar uno o más activadores existentes que enlazan la notificación de eventos identificado con un comando que entra en conflicto con el comando soportado en el segundo dispositivo.

[0011] De acuerdo con otro aspecto a modo de ejemplo, un medio de almacenamiento legible por ordenador puede tener instrucciones ejecutables por ordenador grabadas en él, en el que la ejecución de las instrucciones ejecutables por ordenador en un ordenador puede hacer que el ordenador identifique una notificación de eventos soportada en un primer dispositivo, identifique un comando soportado en un segundo dispositivo, y defina un activador que vincule la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador definido hace que el segundo dispositivo ejecute el comando identificado en respuesta al primer dispositivo que radiodifunde la notificación de eventos identificados. Además, en varios modos de realización, la ejecución de las instrucciones ejecutables por ordenador en el ordenador puede hacer que el ordenador almacene el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, detecte una radiodifusión desde el primer dispositivo que incluye la notificación del evento identificado, y transmita, al segundo dispositivo, un mensaje que hace que el segundo dispositivo ejecute el comando asociado con el activador almacenado en respuesta a la detección de la radiodifusión que incluye la notificación del evento identificado. En modos de realización alternativos (o adicionales), las instrucciones ejecutables por ordenador pueden hacer que el ordenador transmita, al primer dispositivo, el activador que vincula la notificación de eventos soportada en el primer dispositivo con el comando soportado en el segundo dispositivo, en el que el activador transmitido hace que el primer dispositivo invoque el comando en el segundo dispositivo cuando el primer dispositivo radiodifunde la notificación del evento identificado, configurar un oyente asociado con el activador definido en el segundo dispositivo, en el que el oyente configurado hace que el segundo dispositivo escuche el evento identificado notificación y ejecute el comando identificado en respuesta a la detección de que el primer dispositivo radiodifundió la notificación de eventos vinculada al comando identificado, y/o desactivar uno o más activadores existentes que vinculan la notificación de eventos identificado a un comando que entra en conflicto con el comando soportado en el segundo dispositivo

[0012] Otros objetos y ventajas asociados a los aspectos y modos de realización divulgados en el presente documento serán evidentes para los expertos en la técnica basándose en los dibujos y descripción detallada adjuntos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0013] Una apreciación más completa de los diversos aspectos y modos de realización descritos en el presente documento y de muchas de las ventajas intrínsecas de los mismos se obtendrá fácilmente cuando se llegue a entender mejor los mismos al hacer referencia a la siguiente descripción detallada cuando se considere en relación con los dibujos adjuntos, que se presentan solamente como ilustración, y no como limitación, de la invención, y en los que:

Las FIGS. 1A-1E ilustran arquitecturas de sistemas de alto nivel a modo de ejemplo de sistemas de comunicaciones inalámbricas en las que las notificaciones de eventos emitidas desde dispositivos de origen pueden usarse para activar comandos en dispositivos objetivo, de acuerdo con varios aspectos.

La FIG. 2A ilustra un dispositivo de Internet de las cosas (IoT) a modo de ejemplo y la FIG. 2B ilustra un dispositivo IoT pasivo a modo de ejemplo, de acuerdo con diversos aspectos.

La FIG. 3 ilustra un dispositivo de comunicación que incluye lógica configurada para llevar a cabo la funcionalidad, de acuerdo con diversos aspectos.

La FIG. 4 ilustra un servidor a modo de ejemplo, de acuerdo con diversos aspectos.

La FIG. 5 ilustra una red de comunicación inalámbrica que puede soportar servicios de dispositivo a dispositivo (D2D) (o de igual a igual (P2P) detectables) que pueden habilitar la comunicación D2D directa, de acuerdo con varios aspectos.

La FIG. 6 ilustra un entorno a modo de ejemplo en el que los servicios de D2D detectables pueden usarse para establecer un bus distribuido basado en proximidad a través del cual se pueden comunicar varios dispositivos usando tecnología D2D, de acuerdo con varios aspectos.

La FIG. 7 ilustra una secuencia de mensajes a modo de ejemplo en la cual los servicios D2D detectables pueden usarse para establecer un bus distribuido basado en proximidad sobre el cual se pueden comunicar varios dispositivos usando tecnología D2D, de acuerdo con varios aspectos.

La FIG. 8A ilustra un ejemplo de bus distribuido basado en proximidad que puede formarse entre dos dispositivos principales para soportar la comunicación D2D entre los dispositivos principales, mientras que la FIG. 8B ilustra un bus distribuido basado en proximidad a modo de ejemplo en el que uno o más dispositivos integrados pueden conectarse a un dispositivo principal para conectarse al bus distribuido basado en proximidad, de acuerdo con varios aspectos.

La FIG. 9 y la FIG. 10 ilustran respectivamente un flujo de llamadas y un procedimiento a modo de ejemplo en los que un dispositivo de control puede activar comandos en un dispositivo objetivo en respuesta a la detección de una notificación de eventos radiodifundida desde un dispositivo de origen, de acuerdo con varios aspectos.

La FIG. 11 y la FIG. 12 ilustran respectivamente un flujo de llamadas y un procedimiento a modo de ejemplo en los que un dispositivo de control puede configurar un dispositivo de origen para activar un comando en un dispositivo objetivo en respuesta a la detección de una notificación de eventos radiodifundida desde el dispositivo de origen, de acuerdo con varios aspectos.

La FIG. 13 y la FIG. 14 ilustran respectivamente un flujo de llamadas y un procedimiento a modo de ejemplo en los que un dispositivo de control puede configurar un dispositivo objetivo para escuchar una notificación de eventos emitida desde un dispositivo de origen y activar un comando en respuesta a la detección de la notificación de eventos, de acuerdo con varios aspectos.

Las FIGS. 15 y 16 ilustran interfaces de usuario a modo de ejemplo que un dispositivo de control puede mostrar para configurar comandos de activación en un dispositivo objetivo en respuesta a notificaciones de eventos emitidas desde un dispositivo de origen, de acuerdo con varios aspectos.

La FIG. 17 ilustra un dispositivo de comunicaciones a modo de ejemplo que puede usarse en conexión con cualquiera de los diversos aspectos y modos de realización descritos en el presente documento.

La FIG. 18 ilustra un entorno de red doméstica conectada a modo de ejemplo en el que se puede utilizar cualquiera de los diversos aspectos y modos de realización descritos en el presente documento.

DESCRIPCIÓN DETALLADA

[0014] Diversos aspectos y modos de realización se divulgan en la siguiente descripción y dibujos relacionados para mostrar ejemplos específicos relativos a aspectos y modos de realización a modo de ejemplo. Los aspectos y modos de realización alternativos serán evidentes para los expertos en la técnica pertinente tras leer esta divulgación, y pueden construirse y practicarse sin apartarse del alcance de las reivindicaciones adjuntas. 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.

[0015] El término "a modo de ejemplo" se usa en el presente documento en el sentido de "que sirve de ejemplo, caso o ilustración". No se ha de interpretar necesariamente que cualquier modo de realización descrito en el presente documento como "a modo de ejemplo" sea preferente o ventajoso con respecto a otros modos de realización. Asimismo, el término "modos de realización" no requiere que todos los modos de realización incluyan la característica, ventaja o modo de funcionamiento analizados.

[0016] 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" pretenden incluir también las formas en plural, a menos que el contexto lo indique claramente de otro modo. Se deberá entender, 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, pasos, operaciones, elementos, componentes diferentes y/o grupos de los mismos.

[0017] Además, muchos aspectos se describen en términos de secuencias de acciones que se van a realizar, por ejemplo, por elementos de un dispositivo informático. Debe reconocerse que diversas acciones descritas en el presente documento pueden llevarse a cabo mediante circuitos específicos (por ejemplo, un circuito integrado específico de la aplicación (ASIC)), mediante instrucciones de programa ejecutadas por uno o más procesadores, o mediante una combinación de ambas cosas. Adicionalmente, se puede considerar que esta secuencia de acciones descrita en el presente documento se incorpora por completo en cualquier forma de medio de almacenamiento legible por ordenador que tenga almacenado en el mismo un conjunto correspondiente de instrucciones informáticas que, tras su ejecución, harán que un procesador asociado realice la funcionalidad descrita en el presente documento. Por tanto, los diversos aspectos descritos en el presente documento pueden realizarse de varias formas diferentes, todas ellas contempladas dentro del alcance del tema reivindicado. Además, para cada uno de los aspectos descritos en el presente documento, la forma correspondiente de cualquiera de dichos aspectos se puede describir en el presente documento como, por ejemplo, "lógica configurada para" realizar la acción descrita.

[0018] 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 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 IoT puede tener un conjunto particular de atributos (por ejemplo, un estado o condición de dispositivo, por ejemplo si el dispositivo 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 registro ambiental, una función de emisión de luz, una función de emisión de sonido, etc.) que puede estar incorporado en y/o ser controlado/supervisado por una unidad de procesamiento central (CPU), un microprocesador, ASIC, o similar, y estar configurado para la conexión a una red IoT, tal como una red ad hoc local o Internet. Por ejemplo, los dispositivos IoT pueden incluir, pero no se limitan a, refrigeradores, tostadoras, hornos, microondas, congeladores, lavavajillas, vajilla, herramientas de mano, lavadoras de ropa, secadoras de ropa, estufas, acondicionadores de aire, 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 IoT. Los dispositivos IoT también pueden incluir teléfonos celulares, ordenadores de escritorio, ordenadores portátiles, tablets electrónicas, asistentes digitales personales (PDA), etc. En consecuencia, la red IoT puede comprender 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 (por ejemplo, lavavajillas, etc.).

[0019] La FIG. 1A ilustra una arquitectura de sistema de alto nivel de un sistema de comunicaciones inalámbricas 100A de acuerdo con varios aspectos. El sistema de comunicaciones inalámbricas 100A contiene una pluralidad de dispositivos IoT, que incluyen un televisor 110, una unidad de aire acondicionado exterior 112, un termostato 114, un refrigerador 116 y una lavadora y secadora 118.

[0020] En referencia a la FIG. 1A, los dispositivos IoT 110-118 están configurados para comunicarse con una red de acceso (por ejemplo, un punto de acceso 125) a través de una capa o interfaz física de comunicaciones, mostrada en la FIG. 1a como la interfaz aérea 108 y una conexión alámbrica directa 109. La interfaz aérea 108 puede cumplir con un protocolo de Internet (IP) inalámbrico, tal como IEEE 802.11. Aunque la FIG. 1A ilustra dispositivos IoT 110-118 que se comunican a través de la interfaz aérea 108 y el dispositivo IoT 118 que se comunica a través de la conexión alámbrica directa 109, cada dispositivo IoT puede comunicarse a través de una conexión alámbrica o inalámbrica, o de ambos tipos.

[0021] La red Internet 175 incluye una pluralidad de agentes de encaminamiento y de agentes de procesamiento (no mostrados en la FIG. 1A por razones prácticas). La red Internet 175 es un sistema global de ordenadores y redes informáticas interconectados que usa una familia de protocolos de Internet estándar (por ejemplo, el protocolo de control de transmisión (TCP) e IP) para la comunicación entre dispositivos/redes diferentes. TCP/IP proporciona conectividad de extremo a extremo que especifica cómo deben formatearse, direccionarse, transmitirse, encaminarse y recibirse datos en destino.

[0022] En la FIG. 1A, un ordenador 120, tal como un ordenador personal (PC) o de escritorio, se muestra con conexión directa a Internet 175 (por ejemplo, a través de una conexión Ethernet o una red basada en wifi o en la especificación 802.11). El ordenador 120 puede tener una conexión alámbrica a la red Internet 175, tal como una conexión directa a un módem o router, que, en un ejemplo, puede corresponder al propio punto de acceso 125 (por ejemplo, para un router wifi 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 a través de la interfaz aérea 108 u otra interfaz inalámbrica, y acceder a la red Internet 175 a través de la interfaz aérea 108. Aunque se ilustra como un ordenador de escritorio, el ordenador 120 puede ser un ordenador portátil, una tablet electrónica, un PDA, un teléfono inteligente o similar. El ordenador 120 puede ser un dispositivo IoT y/o contener funcionalidad para administrar una red/grupo IoT, tal como la red/grupo de dispositivos IoT 110-118.

[0023] El punto de acceso 125 puede estar conectado a Internet 175 por medio de, por ejemplo, un sistema de comunicación óptica, tal como FiOS, un módem por cable, un módem de línea de abonado digital (DSL), o similares. El punto de acceso 125 puede comunicarse con dispositivos IoT 110-120 y con la red Internet 175 usando los protocolos de Internet estándar (por ejemplo, TCP/IP).

[0024] En referencia a la FIG. 1A, un servidor IoT 170 se muestra conectado a la red Internet 175. El servidor 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 IoT 170 es opcional (como se indica mediante la línea discontinua), y el grupo de dispositivos IoT 110-120 puede ser una red de igual a igual (P2P). En tal caso, los dispositivos 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 utilizando la tecnología de comunicación de dispositivo a dispositivo (D2D) apropiada. De forma alternativa, o adicional, algunos o todos los dispositivos 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 wifi, uno o más de los dispositivos IoT 110-120 pueden tener interfaces Bluetooth o NFC para comunicarse directamente entre sí o con otros dispositivos habilitados para Bluetooth o NFC.

[0025] En una red de igual a igual, los esquemas de descubrimiento de servicios pueden multidifundir la presencia de nodos, sus capacidades y la pertenencia a grupos. Los dispositivos de igual a igual pueden establecer asociaciones e interacciones posteriores basándose en esta información.

[0026] De acuerdo con varios aspectos, la FIG. 1B ilustra una arquitectura de alto nivel de otro sistema de comunicaciones inalámbricas 100B que contiene una pluralidad de dispositivos IoT. En general, el sistema de comunicaciones inalámbricas 100B mostrado en la FIG. 1B puede incluir diversos componentes que son iguales y/o sustancialmente similares al sistema de comunicaciones inalámbricas 100A mostrado en la FIG. 1A, descrito con más detalle anteriormente (por ejemplo, diversos dispositivos IoT, incluido un televisor 110, una unidad de aire acondicionado exterior 112, un termostato 114, un refrigerador 116 y una lavadora y secadora 118, que están configurados para comunicarse con un punto de acceso 125 a través de una interfaz aérea 108 y/o una conexión alámbrica directa 109, un 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 un servidor IoT 170 accesible a través de Internet 175, etc.). De este modo, por brevedad y facilidad de descripción, diversos detalles relacionados con determinados componentes en el sistema de comunicaciones inalámbricas 100B mostrado en la FIG. 1B pueden omitirse en el presente documento en la medida en que los mismos detalles, u otros similares, ya se hayan proporcionado anteriormente en relación con el sistema de comunicaciones inalámbricas 100A ilustrado en la FIG. 1A.

[0027] En referencia a la FIG. 1B, el sistema de comunicaciones inalámbricas 100B puede incluir un dispositivo supervisor 130 que, de forma alternativa puede denominarse administrador de IoT 130 o dispositivo administrador de IoT 130. De este modo, cuando la siguiente descripción usa el término "dispositivo supervisor" 130, los expertos en la técnica 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 funcionalidad u otra sustancialmente similar.

[0028] En varios modos de realización, el dispositivo supervisor 130 puede, en general, observar, supervisar, controlar o administrar de otro modo los otros diversos componentes del sistema de comunicaciones inalámbricas 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 administrar atributos, actividades u otros estados asociados a los diversos dispositivos IoT 110-120 del sistema de comunicaciones inalámbricas 100B. El dispositivo supervisor 130 puede tener una conexión alámbrica o inalámbrica a Internet 175 y, opcionalmente, al servidor IoT 170 (mostrada como una línea discontinua). El dispositivo supervisor 130 puede obtener información de Internet 175 y/o del servidor IoT 170 que se puede usar para supervisar o administrar adicionalmente atributos, actividades u otros estados asociados a los diversos dispositivos IoT 110-120. El dispositivo supervisor 130 puede ser un dispositivo independiente o uno de los dispositivos 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 proporcionar información relacionada con los atributos supervisados, actividades u otros estados asociados a los dispositivos IoT 110-120 y recibir información de entrada para controlar o administrar de otro modo los atributos, actividades u otros estados asociados a los mismos. 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 administrar de otro modo los diversos componentes del sistema de comunicaciones inalámbricas 100B.

[0029] El sistema de comunicaciones inalámbricas 100B mostrado en la FIG. 1B puede incluir uno o más dispositivos IoT pasivos 105 (a diferencia de los dispositivos IoT activos 110-120) que pueden acoplarse a o ser parte de otro modo del sistema de comunicaciones inalámbricas 100B. En general, los dispositivos 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 a través de una interfaz de corto alcance. Los dispositivos IoT activos pueden detectar, almacenar, comunicar, actuar respecto a, y/o similares, cambios en los atributos de dispositivos IoT pasivos.

[0030] Por ejemplo, los dispositivos IoT pasivos 105 pueden incluir una taza de café y un envase de zumo de naranja que tienen cada uno una etiqueta RFID o código de barras. Un dispositivo IoT de armario y un dispositivo 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 IoT pasivos 105 de taza de café y/o de envase de zumo de naranja. En respuesta a que el dispositivo IoT de armario detecte la eliminación del dispositivo IoT pasivo 105 de taza de café y que el dispositivo IoT de refrigerador 116 detecte la eliminación del dispositivo IoT pasivo de envase de zumo de naranja, el dispositivo supervisor 130 puede recibir una o más señales relacionadas con las actividades detectadas en el dispositivo IoT de armario y el dispositivo IoT de refrigerador 116. El dispositivo supervisor 130 puede deducir entonces que un usuario está bebiendo zumo de naranja en la taza de café y/o le gusta beber zumo de naranja en una taza de café.

[0031] Aunque lo que antecede describe que los dispositivos IoT pasivos 105 tienen alguna forma de interfaz de comunicación de etiqueta RFID o código de barras, los dispositivos IoT pasivos 105 pueden incluir uno o más dispositivos u otros objetos físicos que no tengan dichas capacidades de comunicación. Por ejemplo, determinados dispositivos IoT pueden tener mecanismos de lectura o escáner apropiados que pueden detectar formas, tamaños, colores y/u otras características observables asociadas a los dispositivos IoT pasivos 105 para identificar los dispositivos 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 administrado de otro modo con el dispositivo supervisor 130. Además, los dispositivos IoT pasivos 105 se pueden acoplar a o formar parte de otro modo del sistema de comunicaciones inalámbricas 100A de la FIG. 1A y observarse, supervisarse, controlarse o administrarse de otro modo de manera sustancialmente similar.

[0032] De acuerdo con varios aspectos, la FIG. 1C ilustra una arquitectura de alto nivel de otro sistema de comunicaciones inalámbricas 100C que contiene una pluralidad de dispositivos IoT. En general, el sistema de comunicaciones inalámbricas 100C mostrado en la FIG. 1C puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicaciones inalámbricas 100A y 100B mostrados en las FIGS.

1A y 1B, respectivamente, descritos con más detalle anteriormente. De este modo, por brevedad y facilidad de descripción, diversos detalles relacionados con determinados componentes del sistema de comunicaciones inalámbricas 100C mostrado en la FIG. 1C pueden omitirse en el presente documento en la medida en que los mismos detalles, u otros similares, ya se hayan proporcionado anteriormente en relación con los sistemas de comunicaciones inalámbricas 100A y 100B ilustrados en las FIGS. 1A y 1B, respectivamente.

[0033] El sistema de comunicaciones 100C mostrado en la FIG. 1C ilustra comunicaciones de igual a igual a modo de ejemplo entre los dispositivos 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 IoT 110-118 a través de una interfaz de supervisor IoT. Además, los dispositivos IoT 110 y 114, los dispositivos IoT 112, 114 y 116, y los dispositivos IoT 116 y 118 se comunican directamente entre sí.

[0034] Los dispositivos IoT 110-118 conforman un grupo IoT 160. Un grupo de dispositivos IoT 160 es un grupo de dispositivos IoT conectados localmente, tales como los dispositivos IoT conectados a la red doméstica de un usuario. Aunque no se muestra, múltiples grupos de dispositivos IoT pueden conectarse y/o comunicarse entre sí a través de un superagente IoT 140 conectado a Internet 175. A un alto nivel, el dispositivo supervisor 130 administra las comunicaciones dentro de un grupo, mientras que el superagente IoT 140 puede administrar las comunicaciones entre grupos. Aunque se muestran como dispositivos independientes, el dispositivo supervisor 130 y el superagente IoT 140 pueden ser, o residir en, el mismo dispositivo (por ejemplo, un dispositivo independiente o un dispositivo IoT, tal como el ordenador 120 en la FIG. 1A). De forma alternativa, el superagente IoT 140 puede corresponder a o incluir la funcionalidad del punto de acceso 125. Como otra alternativa más, el superagente IoT 140 puede corresponder a o incluir la funcionalidad de un servidor IoT, tal como el servidor IoT 170. El superagente IoT 140 puede encapsular funcionalidad de pasarela 145.

[0035] Cada dispositivo IoT 110-118 puede tratar el dispositivo supervisor 130 como un igual y transmitir actualizaciones de atributo/esquema al dispositivo supervisor 130. Cuando un dispositivo IoT necesita comunicarse con otro dispositivo IoT, puede solicitar el puntero a ese dispositivo IoT desde el dispositivo supervisor 130 y, a continuación, comunicarse con el dispositivo IoT objetivo como un igual. Los dispositivos IoT 110-118 se comunican entre sí a través de una red de comunicación de igual a igual usando un protocolo de mensajería común (CMP). Siempre que dos dispositivos 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 CMP154 está debajo de la capa de aplicación 152 y encima de la capa de transporte 156 y la capa física 158.

[0036] De acuerdo con varios aspectos, la FIG. ID ilustra una arquitectura de alto nivel de otro sistema de comunicaciones inalámbricas 100D que contiene una pluralidad de dispositivos IoT. En general, el sistema de comunicaciones inalámbricas 100D mostrado en la FIG. ID puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicaciones inalámbricas 100A-100C mostrados en las FIGS.

1A-1C, respectivamente, descritos con más detalle anteriormente. De este modo, por brevedad y facilidad de descripción, diversos detalles relacionados con determinados componentes en el sistema de comunicaciones inalámbricas 100D mostrado en la FIG. ID pueden omitirse en el presente documento en la medida en que los mismos detalles, u otros similares, ya se hayan proporcionado anteriormente en relación con los sistemas de comunicaciones inalámbricas 100A-100C ilustrados en las FIGS. 1A-1C, respectivamente.

[0037] la red Internet 175 es un "recurso" que puede regularse usando el concepto de IoT. Sin embargo, la red Internet 175 es solo un ejemplo de un recurso que está regulado, y cualquier recurso podría regularse usando el concepto de IoT. Otros recursos que pueden regularse incluyen, pero no se limitan a, electricidad, gas, almacenamiento, seguridad y similares. Un dispositivo IoT puede estar conectado al recurso y, por lo tanto, regularlo, o el recurso podría regularse a través de Internet 175. La FIG. ID ilustra varios recursos 180, tales como gas natural, gasolina, agua caliente y electricidad, donde los recursos 180 se pueden regular además de y/o a través de Internet 175.

[0038] Los dispositivos IoT pueden comunicarse entre sí para regular el uso que hacen de un recurso 180. Por ejemplo, dispositivos IoT tales 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, dispositivos IoT tales como un ordenador de escritorio, un teléfono y una tablet electrónica pueden comunicarse a través de una interfaz de comunicación wifi para regular su acceso a Internet 175 (el recurso 180). Como otro ejemplo más, dispositivos IoT tales como una estufa, una secadora de ropa y un calentador de agua pueden comunicarse a través de una interfaz de comunicación wifi para regular su uso de gas. De forma alternativa o adicional, cada dispositivo IoT puede estar conectado a un servidor IoT, tal como el servidor IoT 170, que tiene lógica para regular su uso del recurso 180 basándose en la información recibida desde los dispositivos IoT.

[0039] De acuerdo con varios aspectos, la FIG. IE ilustra una arquitectura de alto nivel de otro sistema de comunicaciones inalámbricas 100E que contiene una pluralidad de dispositivos IoT. En general, el sistema de comunicaciones inalámbricas 100E mostrado en la FIG. IE puede incluir diversos componentes que son iguales y/o sustancialmente similares a los sistemas de comunicaciones inalámbricas 100A-100D mostrados en las FIGS.

1A-1D, respectivamente, descritos con más detalle anteriormente. De este modo, por brevedad y facilidad de descripción, diversos detalles relacionados con determinados componentes en el sistema de comunicaciones inalámbricas 100E mostrado en la FIG. IE pueden omitirse en el presente documento en la medida en que los mismos detalles, u otros similares, ya se hayan proporcionado anteriormente en relación con los sistemas de comunicaciones inalámbricas 100A-100D ilustrados en las FIGS. 1A-1D, respectivamente.

[0040] El sistema de comunicación 100E incluye dos grupos de dispositivos IoT 160A y 160B. Múltiples grupos de dispositivos IoT pueden conectarse y/o comunicarse entre sí por medio de un superagente IoT conectado a Internet 175. En un alto nivel, un superagente IoT puede administrar las comunicaciones entre grupos entre los grupos de dispositivos IoT. Por ejemplo, en la FIG. IE, el grupo de dispositivos IoT 160A incluye dispositivos IoT 116A, 122A y 124A y un superagente IoT 140A, mientras que el grupo de dispositivos IoT 160B incluye dispositivos IoT 116B, 122B y 124B y un superagente IoT 140B. De este modo, los superagentes IoT 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 IoT 160A y 160B. Además, aunque la FIG. IE ilustra dos grupos de dispositivos IoT 160A y 160B que se comunican entre sí por medio de los superagente IoT 140A y 140B, los expertos en la técnica apreciarán que cualquier número de grupos de dispositivos IoT puede comunicarse adecuadamente entre sí usando superagentes IoT.

[0041] La FIG. 2A ilustra un ejemplo de alto nivel de un dispositivo IoT 200A de acuerdo con varios aspectos. Si bien las apariencias externas y/o los componentes internos pueden diferir significativamente entre los dispositivos IoT, la mayoría de dispositivos IoT tendrán algún tipo de interfaz de usuario, que puede comprender un dispositivo de visualización y medios para la entrada de datos de usuario. Los dispositivos 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-1B.

[0042] Como se muestra en la FIG. 2A, en una configuración de ejemplo para el dispositivo IoT 200A, una carcasa externa del dispositivo IoT 200A puede configurarse con un dispositivo de visualización 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. El dispositivo de visualización 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 IoT 200A, el dispositivo 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, que incluyen, pero sin limitarse a, antenas wifi, antenas celulares, antenas del sistema de posición por satélite (SPS) (por ejemplo, antenas del sistema de posicionamiento global (GPS)), etc.

[0043] Si bien los componentes internos de los dispositivos IoT, tales como el dispositivo IoT 200A, pueden realizarse con diferentes configuraciones de hardware, una configuración básica de alto nivel para los componentes de hardware internos se muestra como la 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 wifi, un transceptor Bluetooth, un transceptor celular, un transceptor de satélite, un receptor de GPS o SPS, etc.) acoplados de forma operativa 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ñales digitales (DSP), un circuito de lógica programable u otro dispositivo de procesamiento de datos, que se denominarán genéricamente procesador 208. El procesador 208 puede ejecutar instrucciones de programación de aplicaciones en una memoria 212 del dispositivo IoT. La memoria 212 puede incluir una o más de entre una memoria de solo lectura (ROM), una 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 con y controle desde varios dispositivos de E/S tales como el dispositivo de visualización 226, el botón de encendido 222, los botones de control 224A y 224B ilustrados y cualquier otro dispositivo, tal como sensores, accionadores, relés, válvulas, conmutadores, y similares, asociados al dispositivo IoT 200A.

[0044] En consecuencia, varios aspectos pueden incluir un dispositivo IoT (por ejemplo, un dispositivo IoT 200A) que incluye la capacidad de realizar las funciones descritas en el presente documento. Como apreciarán los expertos en la técnica, 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 de forma cooperativa para cargar, almacenar y ejecutar las diversas funciones divulgadas en el presente documento y, por tanto, la lógica para realizar estas funciones se puede distribuir a través de diversos elementos. De forma alternativa, la funcionalidad se podría incorporar en un componente discreto. Por lo tanto, las características del dispositivo IoT 200A en la FIG.

2A se han de considerar meramente ilustrativas y el dispositivo IoT 200A no se limita a las características o disposición ilustradas en la FIG. 2A.

[0045] La FIG. 2B ilustra un ejemplo de alto nivel de un dispositivo IoT pasivo 200B de acuerdo con varios aspectos. En general, el dispositivo IoT pasivo 200B mostrado en la FIG. 2B puede incluir diversos componentes que son iguales y/o sustancialmente similares al dispositivo IoT 200A mostrado en la FIG. 2A, descrito con más detalle anteriormente. De este modo, por brevedad y facilidad de descripción, diversos detalles relacionados con determinados componentes del dispositivo IoT pasivo 200B mostrado en la FIG. 2B pueden omitirse en el presente documento en la medida en que los mismos detalles, u otros similares, ya se hayan proporcionado anteriormente en relación con el dispositivo IoT 200A ilustrado en la FIG. 2A.

[0046] El dispositivo IoT pasivo 200B mostrado en la FIG. 2B puede diferir, en general, del dispositivo IoT 200A mostrado en la FIG. 2A en que el dispositivo IoT pasivo 200B puede no tener un procesador, memoria interna u otros componentes determinados. En cambio, en varios modos de realización, el dispositivo IoT pasivo 200B puede incluir solo una interfaz de E/S 214 u otro mecanismo adecuado que permita observar, supervisar, controlar, administrar o conocer de otro modo el dispositivo IoT pasivo 200B dentro de una red IoT controlada. Por ejemplo, en varios modos de realización, la interfaz de E/S 214 asociada al dispositivo IoT pasivo 200B puede incluir un código de barras, una interfaz Bluetooth, una interfaz de radiofrecuencia (RF), una etiqueta RFID, una interfaz de IR, una interfaz NFC o cualquier otra interfaz de E/S adecuada que pueda proporcionar un identificador y atributos asociados al dispositivo IoT pasivo 200B a otro dispositivo cuando se consulta a través de una interfaz de corto alcance (por ejemplo, un dispositivo IoT activo, tal como el dispositivo IoT 200A, que puede detectar, almacenar, comunicar, actuar respecto a, o procesar de otro modo información relacionada con los atributos asociados al dispositivo IoT pasivo 200B).

[0047] Aunque lo que antecede describe que el dispositivo IoT pasivo 200B tiene alguna forma de RF, código de barras u otra interfaz de E/S 214, el dispositivo IoT pasivo 200B puede comprender un dispositivo u otro objeto físico que no tenga tal interfaz de E/S 214. Por ejemplo, determinados dispositivos IoT pueden tener mecanismos de escáner o lector apropiados que pueden detectar formas, tamaños, colores y/u otras características observables asociadas al dispositivo IoT pasivo 200B para identificar el dispositivo IoT pasivo 200B. De esta manera, cualquier objeto físico adecuado puede comunicar su identidad y atributos y ser observado, supervisado, controlado o administrado de otro modo dentro de una red IoT controlada.

[0048] La FIG. 3 ilustra un dispositivo de comunicación 300 que incluye lógica configurada para llevar a cabo una 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) otra u otras entidades a través de los sistemas de comunicaciones inalámbricas 100A-B de las FIGS. 1A-B.

[0049] En referencia a la FIG. 3, el dispositivo de comunicación 300 incluye lógica configurada para recibir y/o transmitir información 305. En un ejemplo, si el dispositivo de comunicación 300 corresponde a un dispositivo de comunicaciones inalámbricas (por ejemplo, el dispositivo IoT 200A y/o el dispositivo 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, wifi, wifi Direct, Evolución a Largo Plazo (LTE) Directa, etc.) tal como un transceptor inalámbrico y hardware asociado (por ejemplo, una antena de RF, un módem, 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 serie, una conexión USB o Firewire, una conexión 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, la aplicación 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 por medio de un protocolo Ethernet. En un ejemplo adicional, la lógica configurada para recibir y/o transmitir información 305 puede incluir hardware sensorial o de medición mediante 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 de RF locales, etc.). La lógica configurada para recibir y/o transmitir información 305 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la lógica configurada para recibir y/o transmitir información 305 realizar sus una o más funciones de recepción y/o transmisión. Sin embargo, la lógica configurada para recibir y/o transmitir información 305 no corresponde solamente al software, y la lógica configurada para recibir y/o transmitir información 305 depende, al menos parcialmente, del hardware para lograr su funcionalidad.

[0050] Haciendo referencia a la FIG. 3, el dispositivo de comunicación 300 incluye, además, lógica configurada para procesar información 310. En un ejemplo, la lógica configurada para procesar información 310 puede incluir al menos un procesador. Implementaciones de ejemplo del tipo de procesamiento que puede realizarse mediante la lógica configurada para procesar información 310 incluyen, pero no se limitan a, realizar determinaciones, establecer conexiones, realizar selecciones entre diferentes opciones de información, 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 diferentes protocolos, tales como de .wmv a .avi, etc.), etc. Por ejemplo, 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, una matriz de puertas programables in situ (FPGA) u otro dispositivo de lógica programable, lógica de puertas o transistores 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, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar 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 información 310 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la lógica configurada para procesar información 310 realizar sus una o más funciones de procesamiento. Sin embargo, la lógica configurada para procesar información 310 no corresponde solamente al software, y la lógica configurada para procesar información 310 depende, al menos en parte, del hardware para lograr su funcionalidad.

[0051] En referencia a la FIG. 3, el dispositivo de comunicación 300 incluye, además, lógica configurada para almacenar información 315. En un ejemplo, la lógica configurada para almacenar información 315 puede incluir al menos una memoria no transitoria y 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, un 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 información 315 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la lógica configurada para almacenar información 315 realizar sus una o más funciones 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 información 315 depende, al menos en parte, del hardware para lograr su funcionalidad.

[0052] En referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además, opcionalmente, lógica configurada para presentar información 320. En un ejemplo, la lógica configurada para presentar información 320 puede incluir al menos un dispositivo de salida y 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 transportar información de vídeo tal como USB, HDMI, etc.), un dispositivo de salida de audio (por ejemplo, altavoces, un puerto que pueda transportar información de audio, tal como un conector de micrófono, USB, HDMI, etc.), un dispositivo de vibración y/o cualquier otro dispositivo por el cual se pueda dar formato a la información para su emisión o esta pueda emitirse realmente por un usuario u operador del dispositivo de comunicación 300. Por ejemplo, si el dispositivo de comunicación 300 corresponde al dispositivo IoT 200A mostrado en la FIG. 2A y/o al dispositivo IoT pasivo 200B mostrado en la FIG. 2B, la lógica configurada para presentar información 320 puede incluir el dispositivo de visualización 226. En otro ejemplo, la lógica configurada para presentar información 320 puede omitirse en determinados dispositivos de comunicación, tales como dispositivos de comunicación en red que no tengan un usuario local (por ejemplo, conmutadores o routers, servidores remotos, etc.). La lógica configurada para presentar información 320 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la lógica configurada para presentar información 320 realizar sus una o más funciones de presentación. Sin embargo, la lógica configurada para presentar información 320 no corresponde solamente al software y la lógica configurada para presentar información 320 depende, al menos en parte, del hardware para lograr su funcionalidad.

[0053] En referencia a la FIG. 3, el dispositivo de comunicación 300 incluye además, opcionalmente, lógica configurada para recibir datos de entrada de usuario local 325. En un ejemplo, la lógica configurada para recibir datos de entrada de usuario local 325 puede incluir al menos un dispositivo de entrada de usuario y 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 pueda transportar 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 desde un usuario u operador del dispositivo de comunicación 300. Por ejemplo, si el dispositivo de comunicación 300 corresponde al dispositivo IoT 200A mostrado en la FIG. 2A y/o al dispositivo IoT pasivo 200B mostrado en la FIG. 2B, la lógica configurada para recibir datos de entrada de usuario local 325 puede incluir los botones 222, 224A y 224B, el dispositivo de visualización 226 (por ejemplo, una pantalla táctil), etc. En otro ejemplo, la lógica configurada para recibir datos de entrada de usuario local 325 puede omitirse en determinados dispositivos de comunicación, tales como dispositivos de comunicación de red que no tienen un usuario local (por ejemplo, conmutadores o routers de red, servidores remotos, etc.). La lógica configurada para recibir datos de entrada de usuario local 325 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la lógica configurada para recibir datos de entrada de usuario local 325 realizar sus una o más funciones de recepción de entrada. Sin embargo, la lógica configurada para recibir datos de entrada de usuario local 325 no corresponde solamente al software, y la lógica configurada para recibir datos de entrada de usuario local 325 depende, al menos en parte, del hardware para lograr su funcionalidad.

[0054] Haciendo referencia a la FIG. 3, mientras que las lógicas configuradas 305 a 325 se muestran como bloques independientes o distintos en la FIG. 3, se apreciará que el hardware y/o software mediante los cuales la respectiva lógica configurada realiza su funcionalidad pueden superponerse en parte. Por ejemplo, cualquier software usado para facilitar la funcionalidad de las lógicas configuradas 305 a 325 puede almacenarse en la memoria no transitoria asociada a la lógica configurada para almacenar información 315, de modo que las lógicas configuradas 305 a 325 realizan, cada una, su funcionalidad (es decir, en este caso, la ejecución de software) basándose, en parte, en el funcionamiento del software almacenado por la lógica configurada para almacenar información 315. Asimismo, el hardware que está directamente asociado a una de las lógicas configuradas puede, en ocasiones, prestarse a, o usarse por, otras lógicas configuradas. Por ejemplo, el procesador de la lógica configurada para procesar información 310 puede formatear datos en un formato adecuado antes de transmitirse mediante la lógica configurada para recibir y/o transmitir información 305, de modo que la lógica configurada para recibir y/o transmitir información 305 realiza su funcionalidad (es decir, en este caso, la transmisión de datos) basándose, en parte, en el funcionamiento del hardware (es decir, el procesador) asociado a la lógica configurada para procesar información 310.

[0055] En general, a menos que se indique lo contrario de forma explícita, la expresión "lógica configurada para" como se usa en el presente documento pretende referirse a una lógica que se implementa, al menos parcialmente, con hardware, y no pretende asociarse a implementaciones de solo software que son independientes del hardware. Asimismo, se apreciará que la lógica configurada o "lógica configurada para" en los diversos bloques no está limitada a puertas o elementos lógicos específicos, sino que se refiere, en general, a la capacidad de realizar la funcionalidad descrita en el presente documento (ya sea por medio de hardware o de una combinación de hardware y software). Por tanto, la lógica configurada o "lógica configurada para", como se ilustra en los diversos bloques, no se implementa 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 técnica a partir de la revisión de los aspectos descritos a continuación con más detalle.

[0056] Los diversos modos de realización se pueden implementar 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 servidor IoT 170 descrito anteriormente. En la FIG. 4, el servidor 400 incluye un procesador 401 acoplado a una memoria volátil 402 y a una memoria no volátil de gran capacidad, tal como una unidad de disco 403. El servidor 400 también puede incluir una unidad de disco flexible, una unidad de disco compacto (CD) o disco DVD 406 acoplada al procesador 401. El servidor 400 también puede incluir puertos de acceso a 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 de sistema de radiodifusión o a Internet. En 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, con lo que la lógica configurada para transmitir y/o recibir información 305 corresponde a los puntos de acceso a red 404 usados por el servidor 400 para comunicarse con la red 407, la lógica configurada para procesar información 310 corresponde al procesador 401, y la configuración lógica para almacenar información 315 corresponde a cualquier combinación de la memoria volátil 402, la unidad de disco magnético 403 y/o la unidad de disco óptico 406. La lógica opcional configurada para presentar información 320 y la lógica opcional configurada para recibir datos de entrada de usuario local 325 no se muestran explícitamente en la FIG. 4 y pueden o no estar incluidas en la misma. Por 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 IoT como en la FIG. 2A.

[0057] En general, como se señaló anteriormente, las tecnologías y los servicios basados en IP se han vuelto más maduros, reduciendo el costo y aumentando la disponibilidad de IP, lo cual ha permitido que la conectividad a Internet se agregue a cada vez más tipos de objetos electrónicos cotidianos. Como tal, IoT se basa en la idea de que los objetos electrónicos cotidianos, no solo los ordenadores y las redes informáticas, pueden ser legibles, reconocibles, localizables, direccionables y controlables a través de Internet. En general, con el desarrollo y la creciente prevalencia de IoT, numerosos dispositivos de IoT heterogéneos próximos y otros objetos físicos que tienen diferentes tipos y realizan diferentes actividades (por ejemplo, luces, impresoras, refrigeradores, acondicionadores de aire, etc.) pueden interactuar entre sí. de muchas formas diferentes y se pueden utilizar de muchas formas diferentes. Como tal, debido a la cantidad potencialmente grande de dispositivos de IoT heterogéneos y otros objetos físicos que pueden estar en uso dentro de una red de IoT controlada, en general se necesitan interfaces de comunicación fiables y bien definidas para conectar los diversos dispositivos de IoT heterogéneos de manera que los diversos dispositivos de IoT heterogéneos se pueden configurar, administrar y comunicarse de manera adecuada entre sí para intercambiar información, entre otras cosas. Por consiguiente, la siguiente descripción proporcionada en relación con las FIGS. 5-8 describe en general un marco de comunicación a modo de ejemplo que puede soportar servicios de dispositivo a dispositivo (D2D) o de igual a igual (P2P) que pueden permitir la comunicación D2D directa entre dispositivos heterogéneos en un entorno de programación distribuida como se describe en el presente documento.

[0058] En general, el equipo de usuario (UE) (por ejemplo, teléfonos, tablets, ordenadores portátiles y de escritorio, vehículos, etc., pueden estar configurados para conectarse entre sí de forma local (por ejemplo, Bluetooth, wifi local, etc.) o de forma remota (por ejemplo, a través de redes celulares, a través de Internet, etc.) o de acuerdo con combinaciones adecuadas de los mismos. Además, ciertos UE también pueden soportar comunicaciones D2D basadas en proximidad utilizando ciertas tecnologías de redes inalámbricas (por ejemplo, wifi, Bluetooth, wifi Direct, etc.) que soportan conexiones uno a uno o conexiones 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 o WAN 500 a modo de ejemplo que puede soportar servicios D2D detectables que pueden permitir la comunicación D2D directa, en el que la red 500 de comunicación inalámbrica 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 Dispositivo Principal (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 un subsistema de 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.

[0059] Una estación base 510 puede proporcionar cobertura de comunicación para una macrocélula, una picocélula, una femtocélula, y/u otros tipos de células. Una macrocé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 picocé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 femtocé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 femtocélula (por ejemplo, los dispositivos 520 en un grupo cerrado de abonados (CSG)). En el ejemplo mostrado en la FIG. 5, la red inalámbrica 500 incluye macroestaciones base 510a, 510b y 510c para macrocélulas. La red inalámbrica 500 también puede incluir picoestaciones base 510 para picocélulas y/o estaciones base femto/domésticas 510 para femtocélulas (no mostradas en la FIG. 5).

[0060] 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 también se pueden comunicar entre sí (por ejemplo, directa o indirectamente por medio de una red de retorno inalámbrica o alámbrica). El servidor DHCP 540 puede soportar la comunicación D2D, como se describe a continuación. El servidor DHCP 540 puede ser parte de la red inalámbrica 500, externa a la red 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, 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 directamente.

[0061] Los dispositivos 520 pueden estar dispersos a lo largo de la red de 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 inalámbrica 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 también en la FIG. 5, los dispositivos 520a, 520d, 520f y 520h también pueden comunicarse con las estaciones base 500 (por ejemplo, cuando no están en comunicación D2D o posiblemente concurrentes con comunicación D2D).

[0062] 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 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á interesado o involucrado en la comunicación WAN. En general, los términos comunicación "igual a igual" o "P2P" y comunicación "dispositivo a dispositivo" o "D2D" como se usan en el presente documento se refieren a la comunicación directa entre dos o más dispositivos 520, sin pasar por ninguna estación base. 510. Para simplificar, la descripción proporcionada en el presente documento utiliza el término "dispositivo a dispositivo" o "D2D" para referirse a dicha comunicación directa, aunque los expertos en la técnica apreciarán que los términos "igual a igual", "P2P", "dispositivo a dispositivo" y "D2D" pueden ser intercambiables en los diversos aspectos y modos de realización descritos en el presente documento.

[0063] De acuerdo con varios modos de realización, un dispositivo D2D es un dispositivo 520 que está interesado o involucrado en la comunicación D2D (por ejemplo, un dispositivo 520 que tiene datos de tráfico para otro dispositivo 520 próximo al dispositivo D2D). 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 D2D o a través de al menos una estación base 510 para la comunicación WAN.

[0064] En varios modos de realización, la comunicación directa entre los dispositivos D2D 520 puede organizarse en grupos D2D. Más particularmente, un grupo D2D en general se refiere a un grupo de dos o más dispositivos 520 interesados o comprometidos en la comunicación D2D y un enlace D2D se refiere a un enlace de comunicación para un grupo D2D. Además, en varios modos de realización, un grupo D2D puede incluir un dispositivo 520 designado como propietario de un grupo D2D (o un servidor D2D) y uno o más dispositivos 520 designados clientes D2D que son atendidos por el propietario del grupo D2D. El propietario del grupo D2D puede realizar determinadas funciones de administración, como intercambiar señalización con una WAN, coordinar la transmisión de datos entre el propietario del grupo D2D y los clientes D2D, etc. Por ejemplo, como se muestra en la FIG. 5, un primer grupo D2D incluye los dispositivos 520a y 520b bajo la cobertura de la estación base 510a, un segundo grupo D2D incluye los dispositivos 520c y 520d bajo la cobertura de la estación base 510b, un tercer grupo D2D incluye los dispositivos 520e y 520f bajo la cobertura de diferentes estaciones base 510b y 510c, y un cuarto grupo D2D incluye 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 D2D para sus respectivos grupos D2D y los dispositivos 520b, 520c, 520e, 520g y 520i pueden ser clientes D2D en sus respectivos grupos D2D. Los otros dispositivos 520 en la FIG. 5 pueden participar en la comunicación de WAN.

[0065] En varios modos de realización, la comunicación D2D puede ocurrir solo dentro de un grupo D2D y puede ocurrir además solo entre el propietario del grupo D2D y los clientes D2D asociados con la misma. Por ejemplo, si dos clientes D2D dentro del mismo grupo D2D (por ejemplo, los dispositivos 520g y 520i) desean intercambiar información, uno de los clientes D2D puede enviar la información al propietario del grupo D2D (por ejemplo., el dispositivo 520h) y el propietario del grupo D2D puede retransmitir transmisiones al otro cliente D2D. En varios modos de realización, un dispositivo 520 particular puede pertenecer a múltiples grupos D2D y puede comportarse como un propietario de grupo D2D o un cliente D2D en cada grupo D2D. Además, en varios modos de realización, un cliente D2D particular puede pertenecer a un solo grupo D2D o pertenecer a múltiples grupos D2D y comunicarse con los dispositivos D2D 520 en cualquiera de los múltiples grupos D2D 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 D2D, el enlace descendente D2D se refiere al enlace de comunicación de los propietarios del grupo D2D a los clientes D2D y el enlace ascendente D2D se refiere al enlace de comunicación de los clientes D2D a los propietarios del grupo D2D. En varios modos de realización, en lugar de usar tecnologías WAN para comunicar D2D, dos o más dispositivos pueden formar grupos D2D más pequeños y comunicar D2D en una red de área local inalámbrica (WLAN) utilizando tecnologías tales como wifi, Bluetooth o wifi Direct. Por ejemplo, la comunicación D2D usando wifi, Bluetooth, wifi Direct u otras tecnologías WLAN puede permitir la comunicación D2D entre dos o más teléfonos móviles, consolas de videojuegos, ordenadores portátiles u otras entidades de comunicación adecuadas.

[0066] De acuerdo con varios aspectos, la FIG. 6 ilustra un entorno a modo de ejemplo 600 en el que se pueden usar servicios D2D detectables para establecer un bus distribuido basado en proximidad 640 a través del cual se pueden comunicar varios dispositivos 610, 620, 630 utilizando tecnología D2D. Por ejemplo, en varios modos 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 640, 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 640 para ofrecer servicios a otras aplicaciones y otras aplicaciones consultan al bus distribuido 640 para obtener información sobre las aplicaciones registradas. Dicho protocolo puede proporcionar notificaciones asincrónicas 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 la distribución el bus 640 puede manejar el enrutamiento de mensajes entre los diversos dispositivos 610, 620, 630 (por ejemplo, a través de uno o más routers de bus o "daemons" u otros procesos adecuados que pueden proporcionar adjuntos al bus distribuido 640).

[0067] En varios modos de realización, el bus distribuido 640 puede estar soportado por una variedad de protocolos de transporte (por ejemplo, Bluetooth, TCP/IP, wifi, CDMA, GPRS, UMTS, etc.). Por ejemplo, de acuerdo con varios aspectos, 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 624 y 634 asociados con un segundo dispositivo 620 y un tercer dispositivo 630 a través del bus distribuido 640 (por ejemplo, a través de los nodos de bus distribuidos 622 y 632 en el segundo dispositivo 620 y el tercer dispositivo 630). Como se describirá con mayor detalle a continuación con referencia a la FIG. 7, el bus distribuido 640 puede soportar topologías de red simétricas de dispositivos múltiples y puede proporcionar un funcionamiento robusto en presencia de interrupciones del dispositivo. Como tal, el bus distribuido virtual 640, que en general puede ser independiente de cualquier protocolo de transporte subyacente (por ejemplo, Bluetooth, TCP/IP, wifi, 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 620 y el tercer dispositivo 630 sin intervención cuando los diversos dispositivos 610, 620, 630 entran en rango o proximidad entre sí.

[0068] De acuerdo con varios aspectos, la FIG. 7 ilustra un flujo de señalización a modo de ejemplo 700 en la que se pueden usar servicios D2D detectables para establecer un bus distribuido basado en proximidad por el cual un primer dispositivo ("Dispositivo A") 710 y un segundo dispositivo ("Dispositivo B") 720 pueden comunicarse utilizando tecnología D2D. Por ejemplo, en el flujo de señalización 700 mostrado en la FIG. 7, el Dispositivo A 710 puede solicitar comunicarse con el Dispositivo B 720, 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 720 puede incluir un de punto final local 724 con el que el punto final local 714 puede intentar comunicarse, además de un nodo de bus 722 que puede ayudar a facilitar las comunicaciones entre el punto final local 714 en el Dispositivo A 710 y el punto final local 724 en el Dispositivo B 720.

[0069] En varios modos de realización, los nodos de bus 712 y 722 pueden realizar un mecanismo de descubrimiento adecuado en 754. Por ejemplo, se pueden usar mecanismos para descubrir conexiones soportadas con Bluetooth, TCP/IP, UNIX o similares. En 756, el punto final local 714 en el Dispositivo A 710 puede solicitar conectarse a una entidad, servicio, punto final, etc., disponible a través del nodo de bus 712. En varios modos de realización, la petición puede incluir un proceso de petición y respuesta entre el punto final local 714 y el nodo de bus 712. En 758, se puede formar un bus de mensajes distribuidos para conectar el nodo de bus 712 al nodo de bus 722 y de ese modo establecer una conexión D2D entre el Dispositivo A 710 y el Dispositivo B 720. En varios modos de realización, las comunicaciones para formar el bus distribuido entre los nodos de bus 712 y 722 pueden facilitarse utilizando un protocolo D2D 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 D2D). De forma alternativa, en varios modos de realización, un servidor (no mostrado) puede facilitar la conexión entre los nodos de bus 712 y 722. Además, en varios modos 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 722 (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, en 758, los nodos de bus 712 y 722 pueden intercambiar información sobre otros puntos finales disponibles (por ejemplo, puntos finales locales 634 en el Dispositivo C 630 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.

[0070] En varios modos de realización, en el nodo de bus 760, el nodo de bus 712 y el nodo de bus 722 puede utilizar la información obtenida asociada con los puntos finales locales 724 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 varios modos 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 722). En varios modos de realización, los puntos finales virtuales pueden recibir mensajes del nodo de bus local 712 o 722, al igual que los puntos finales reales, y pueden reenviar mensajes a través del bus distribuido. Como tales, los puntos finales virtuales pueden reenviar mensajes a los nodos de bus locales 712 y 722 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 adaptase a las topologías deseadas de tipos de transporte específicos. En tales modos de realización, 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 722 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.

[0071] En varios modos de realización, el nodo de bus 712 y el nodo de bus 722 pueden intercambiar información de estado de bus en 762 para fusionar casos de bus y permitir la comunicación a través del bus distribuido. Por ejemplo, en varios modos 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 varios modos de realización, la información de estado se puede comunicar entre las instancias de nodo de bus 712 y las instancias del nodo de bus 722 usando una interfaz con los puntos finales locales 714 y 724 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 722 pueden 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. El nodo de bus 712 y el nodo de bus 722 pueden comunicar (por ejemplo, radiodifusión) señales en 764 para informar a los respectivos puntos finales locales 714 y 724 sobre cualquier cambio introducido durante las conexiones de nodo de bus, tal como se describió anteriormente. En varios modos 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 (por ejemplo., 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 722 se desconectan pueden indicarse con las señales de cambio de propietario de nombre.

[0072] Tal como se ha usado anteriormente, pueden usarse nombres bien conocidos para describir de forma única los puntos finales locales 714 y 724. En varios modos de realización, cuando se producen comunicaciones entre el Dispositivo A 710 y el Dispositivo B 720, 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 722, 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 722 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 tales modos de realización, 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").

[0073] En varios modos de realización, el nodo de bus 712 y el nodo de bus 722 puede comunicar (por ejemplo, radiodifundir) señales en 766 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 724 en el Dispositivo B 720. Además, durante el funcionamiento, las comunicaciones entre el punto final local 714 y el punto final local 724 pueden usar grupos de enrutamiento. En varios modos de realización, 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 722. Por ejemplo, una aplicación D2D 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 722 pueden soportar el registro y/o el desregistro de los puntos finales locales 714 y 724 con grupos de enrutamiento. En varios modos 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 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 722 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 722 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 722 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.

[0074] De acuerdo con varios aspectos, la FIG. 8A ilustra un ejemplo de bus distribuido basado en proximidad que puede formarse entre un primer dispositivo principal 810 y un segundo dispositivo principal 830 para permitir la comunicación D2D entre el primer dispositivo principal 810 y el segundo dispositivo principal 830. Más particularmente, como se describió anteriormente con respecto a la FIG. 6, la estructura básica del bus distribuido basado en proximidad puede comprender múltiples segmentos de bus que residen en dispositivos principales físicos separados. Por consiguiente, en la FIG. 8A, cada segmento del bus distribuido basado en proximidad puede estar ubicado en uno de los dispositivos principales 810, 830, donde cada uno de los dispositivos principales 810, 830 ejecuta un router de bus local (o "daemon") que puede implementar los segmentos de bus ubicados en el dispositivo principal respectivo 810, 830. Por ejemplo, en la FIG. 8A, cada dispositivo principal 810, 830 incluye una burbuja etiquetada como "D" para representar el router de bus que implementa los segmentos de bus ubicados en el respectivo dispositivo principal 810, 830. Además, uno o más de los dispositivos principales 810, 830 pueden tener varias conexiones de bus, donde cada conexión de bus se conecta al router de bus local. Por ejemplo, en la FIG. 8A, las conexiones de bus en los dispositivos principales 810, 830 se ilustran como hexágonos y cada uno corresponde a un servicio (S) o un cliente (C) que puede solicitar un servicio.

[0075] Sin embargo, en ciertos casos, los dispositivos integrados pueden carecer de recursos suficientes para ejecutar un router de bus local. Por consiguiente, la FIG. 8B ilustra un bus distribuido basado en proximidad a modo de ejemplo en el que uno o más dispositivos integrados 820, 825 se pueden conectar a un dispositivo principal (por ejemplo, el dispositivo principal 830) para conectarse al bus distribuido basado en proximidad y así participar en la comunicación D2D (por ejemplo con el dispositivo principal 830 o con otros dispositivos principales 810 y/o dispositivos integrados 825 que están conectados al bus distribuido basado en proximidad a través del dispositivo principal 830). Como tal, los dispositivos integrados 820, 825 en general pueden "tomar prestado" el router de bus que se ejecuta en el dispositivo principal 830, por lo que la FIG. 8B muestra una disposición en la que los dispositivos integrados 820, 825 están físicamente separados del dispositivo principal 830 que ejecuta el router de bus prestado que administra el segmento de bus distribuido en el que residen los dispositivos integrados 820, 825. En general, la conexión entre los dispositivos integrados 820, 825 y el dispositivo principal 830 se puede realizar de acuerdo con el protocolo de control de transmisión (TCP) y el tráfico de red que fluye entre los dispositivos integrados 820, 825 y el dispositivo principal 830 puede comprender mensajes que implementan procedimientos de bus, señales de bus y propiedades que fluyen a través de sesiones respectivas de una manera similar a la descrita con más detalle anteriormente con respecto a las FIGS. 6 y 7.

[0076] Más particularmente, los dispositivos integrados 820, 825 pueden conectarse al dispositivo principal 830 de acuerdo con un proceso de descubrimiento y conexión que puede ser conceptualmente similar al proceso de descubrimiento y conexión entre clientes y servicios, en el que el dispositivo principal 830 puede anunciar un nombre conocido (por ejemplo., "org.alljoyn.BusNode") que indica la capacidad o voluntad de alojar los dispositivos integrados 820, 825. En un caso de uso, los dispositivos integrados 820, 825 pueden simplemente conectarse al "primer" dispositivo principal que anuncia el nombre conocido. Sin embargo, si los dispositivos integrados 820, 825 simplemente se conectan al primer dispositivo principal que anuncia el nombre conocido, es posible que los dispositivos integrados 820, 825 no tengan ningún conocimiento sobre el tipo asociado con el dispositivo principal (por ejemplo, si el dispositivo principal 830 es un dispositivo móvil, un descodificador, un punto de acceso, etc.), y que los dispositivos integrados 820, 825 no tengan ningún conocimiento sobre el estado de carga en el dispositivo principal. En consecuencia, en otros casos de uso, los dispositivos integrados 820, 825 pueden conectarse de forma adaptativa al dispositivo principal 830 basándose en la información que los dispositivos principales 810, 830 proporcionan al anunciar la capacidad o voluntad de albergar otros dispositivos (por ejemplo, dispositivos integrados 820, 825), que pueden unirse al bus distribuido basado en proximidad de acuerdo con las propiedades asociadas con los dispositivos principales 810, 830 (por ejemplo, tipo, estado de carga, etc.) y/o requisitos asociados con los dispositivos integrados 820, 825 (por ejemplo, un tabla de clasificación que expresa una preferencia por conectarse a un dispositivo principal del mismo fabricante).

[0077] En un futuro próximo, con el creciente desarrollo de las tecnologías de IoT que llevan a numerosos dispositivos de loT que rodean a un usuario en el hogar, en los vehículos, en el trabajo y en muchas otras ubicaciones y espacios personales, muchos usuarios interactuarán con diferentes dispositivos dentro de entornos particulares de formas interrelacionadas. Por consiguiente, varios mecanismos descritos con más detalle en el presente documento pueden permitir a los usuarios vincular notificaciones de eventos y comandos de control que soportan dispositivos heterogéneos para automatizar actividades comunes o rutinarias que pueden estar relacionadas lógicamente. Por ejemplo, en varios modos de realización, cuando una notificación de eventos radiodifundida desde un dispositivo de origen llega a un dispositivo de control (por ejemplo, un teléfono inteligente u otro dispositivo adecuado), el usuario puede tener la opción de vincular la notificación de eventos a comandos que pueden activarse para controlar un dispositivo objetivo. Como tal, en respuesta a que el usuario seleccione la opción para vincular la notificación del evento, se le puede mostrar al usuario uno o más dispositivos objetivo controlables y el usuario puede definir uno o más comandos para que se activen automáticamente en los dispositivos objetivo controlables cuando se produzca la notificación del evento de nuevo en el futuro. Por ejemplo, como se describirá con más detalle a continuación con referencia a la FIG. 9 y la FIG. 10, el dispositivo de control puede almacenar la definición de activación y llamar automáticamente o invocar de otro modo el comando en los dispositivos objetivo controlables en respuesta a la detección posterior de que el dispositivo de origen emitió la notificación del evento vinculado. En otro ejemplo, como se describirá con más detalle a continuación con referencia a la FIG. 11 y la FIG. 12, el dispositivo de control puede enviar la definición de activación y el comando vinculado al dispositivo de origen de radiodifusión, que a continuación puede invocar el comando vinculado en los dispositivos objetivo controlables cuando se radiodifunda la notificación del evento en el futuro. En otro ejemplo más, como se describirá con más detalle a continuación con referencia a la FIG. 13 y la FIG. 14, el dispositivo de control puede configurar un oyente en los dispositivos objetivo controlables de manera que los dispositivos objetivo controlables puedan escuchar la notificación del evento desde el dispositivo de origen de radiodifusión y a continuación invocar localmente el comando vinculado en respuesta al oyente configurado que detecta la notificación del evento radiodifundida desde el dispositivo de origen.

[0078] Más particularmente, de acuerdo con varios aspectos, la FIG. 9 ilustra un ejemplo de flujo de llamadas 900 en el que un dispositivo de control 920 puede activar comandos en un dispositivo objetivo 930 en respuesta a la detección de una notificación de eventos radiodifundida desde un dispositivo de origen 910. En particular, el dispositivo de control 920 (por ejemplo, un teléfono inteligente u otro dispositivo adecuado) puede configurarse para supervisar una red de IoT u otra red inalámbrica adecuada en 942, donde cada uno del dispositivo de origen 910, el dispositivo de control 920 y el dispositivo objetivo 930 puede soportar un protocolo D2D basado en proximidad adecuado que puede permitir que el dispositivo de origen 910, el dispositivo de control 920 y el dispositivo objetivo 930 se involucren en comunicación directa a través de un bus distribuido basado en proximidad (por ejemplo, el marco de software AlIJoyn™ descrito en más detalle anteriormente con respecto a las FIGS. 6-8). Como tal, en respuesta a que el dispositivo de origen 910 radiodifunda una notificación de eventos particular en 944, el dispositivo de control 920 puede detectar la notificación de eventos radiodifundida en 946 y mostrar una interfaz de usuario que se puede usar para vincular la notificación de eventos detectado con un comando para activar en el dispositivo objetivo 930 y de ese modo controlar el dispositivo objetivo 930. Por ejemplo, en varios modos de realización, el dispositivo de origen 910 puede comprender un reloj de alarma y el dispositivo objetivo 930 puede comprender una unidad de aire acondicionado. Como tal, el dispositivo de origen 910 puede emitir una notificación de eventos de "despertador con repetición" en 944, y en respuesta a la detección de la notificación de "despertador con repetición", el dispositivo de control 920 puede mostrar la interfaz de usuario para permitir al usuario vincular el evento de "repetición del despertador" a un comando en uno o más dispositivos objetivo controlables 930 (por ejemplo, la unidad de aire acondicionado). Por ejemplo, la FIG. 15 ilustra una interfaz de usuario 1510 a modo de ejemplo que el dispositivo de control 920 puede mostrar en respuesta a la detección de la notificación de eventos de repetición del despertador, en la que la interfaz de usuario 1510 puede permitir al usuario definir un comando de activación para enlazar con la notificación del evento de repetición de alarma del reloj, y la interfaz de usuario 1510 puede proporcionar además al usuario una alternativa para descartar la notificación del evento de repetición del despertador sin definir un comando de activación para enlazarlo.

[0079] En varios modos de realización, en respuesta a que el usuario seleccione la opción para definir un comando de activación para enlazar con la notificación del evento de repetición del despertador (por ejemplo, desde la interfaz de usuario 1510), el dispositivo de control 920 puede mostrar un panel de control de dispositivos que muestra o dispositivos objetivo más controlables que se pueden vincular a la notificación de eventos de repetición del despertador. Por ejemplo, la FIG. 15 ilustra además un panel de control de dispositivos 1520 a modo de ejemplo que puede mostrarse en el dispositivo de control 920 en respuesta a que el usuario seleccione la opción de comando de activación de la interfaz de usuario 1510, en el que el panel de control de dispositivos 1520 puede mostrar que la notificación de eventos de repetición del despertador puede estar vinculado a los comandos de una radio, una máquina de café, un calentador y luces, además de la unidad de aire acondicionado y el despertador que radiodifundía la notificación del evento de repetición. Como tal, en respuesta a que el usuario seleccione la unidad de aire acondicionado desde el panel de control de dispositivos 1520, el dispositivo de control 920 puede mostrar un panel de control específico del dispositivo asociado con la unidad de aire acondicionado. Por ejemplo, la FIG. 15 ilustra además un panel de control 1530 específico del dispositivo a modo de ejemplo que el dispositivo 920 de control puede mostrar en respuesta al usuario que selecciona la unidad de aire acondicionado desde el panel de control 1520 del dispositivo, en el que el panel de control 1530 específico del dispositivo puede permitir que el usuario active un comando que vincula el evento de repetición del despertador con una velocidad del ventilador, temperatura y estado de encendido/apagado particulares en el dispositivo 930 objetivo (es decir, la unidad de aire acondicionado). Por consiguiente, volviendo a la FIG. 9, el dispositivo de control 820 puede recibir la(s) entrada(s) del usuario que definen el comando para enlazar con la notificación de eventos radiodifundida en 948, que el dispositivo de origen 910 puede almacenar entonces de manera que el comando definido en 948 pueda activarse automáticamente en el dispositivo objetivo 930 en respuesta al dispositivo de origen 910 que radiodifunde la notificación de eventos nuevamente en el futuro. Además, en varios modos de realización, el dispositivo de control 920 puede mostrar opcionalmente una pantalla de desactivación en respuesta a la determinación de que el comando vinculado a la notificación de eventos radiodifundida entra en conflicto con una o más definiciones de activación que se configuraron previamente. Por ejemplo, la FIG. 15 ilustra además una pantalla de desactivación a modo de ejemplo 1540 que puede mostrarse para resolver desencadenantes de eventos conflictivos (por ejemplo, una definición de activación anterior puede haber vinculado el evento de repetición del despertador a un comando particular en el calentador y la pantalla de desactivación 1540 puede mostrarse para indicar al usuario que desactive la definición de activación anterior porque lo más probable es que el usuario no desee que la unidad de aire acondicionado y el calentador se enciendan en respuesta a la misma notificación de eventos). Por consiguiente, refiriéndose de nuevo a la FIG. 9, el dispositivo de control 920 puede almacenar la definición de activación vinculada al evento de repetición del despertador después de que el usuario haya definido adecuadamente el comando para activar en el dispositivo objetivo 830 (y resuelto cualquier activación de evento conflictivo, si aplica). En varios modos de realización, el dispositivo de control 920 puede continuar supervisando la red en 950, en el que el dispositivo de origen 910 puede radiodifundir nuevamente la notificación de eventos en 952 de manera que el dispositivo de control detecte la notificación de eventos en 954 y a continuación active el comando previamente definido en el dispositivo objetivo 930 en 956.

[0080] De acuerdo con varios aspectos, la FIG. 10 ilustra un procedimiento a modo de ejemplo 1000 en el que un dispositivo de control puede activar comandos en un dispositivo objetivo en respuesta a la detección de una notificación de eventos radiodifundida desde un dispositivo de origen, que en general puede ser similar a las funciones realizadas en el dispositivo de control 920 mostrado en la FIG. 9. En particular, en el bloque 1010, el dispositivo de control puede supervisar una red inalámbrica local y posteriormente detectar una notificación de eventos que el dispositivo de origen radiodifunde usando un protocolo D2D basado en proximidad adecuado en el bloque 1020. En respuesta a ello, el dispositivo de control puede determinar si la notificación de eventos es una notificación de eventos nueva (es decir, no observada previamente) en el bloque 1030, en cuyo caso el dispositivo de control puede mostrar una interfaz de usuario en el bloque 1040 para solicitar al usuario que descarte la notificación de eventos o definir un comando para activar en un dispositivo objetivo, lo cual puede estar vinculado a la notificación de eventos emitida desde el dispositivo de origen. Por consiguiente, en el bloque 1040, el dispositivo de control puede recibir una o más entradas de usuario, ya sea descartando la notificación del evento o definiendo un comando de activación antes de reanudar la supervisión del bloque de red local 1070. Sin embargo, en el último caso en el que las entradas recibidas en el dispositivo de control definen un activador de comandos, el dispositivo de control puede almacenar el activador de comandos antes de reanudar la supervisión de la red local de modo que el comando pueda activarse automáticamente en el dispositivo objetivo en respuesta al dispositivo de origen que radiodifunde la notificación del evento nuevamente en el futuro. Por ejemplo, en el bloque 1030, el dispositivo de control determinaría que la notificación de eventos emitida desde el dispositivo de origen se observó previamente y, por lo tanto, no es nueva. Por consiguiente, en el bloque 1050, el dispositivo de control puede determinar si se ha definido un activador de comando existente con respecto a la notificación del evento. Más particularmente, si el usuario descartó previamente la notificación del evento, el dispositivo de control puede reanudar la supervisión de la red local en el bloque 1070 sin tomar ninguna acción adicional. Sin embargo, si el usuario definió previamente un activador de comandos, el dispositivo de control puede comunicarse con el dispositivo objetivo usando tecnología D2D e invocar el comando en el dispositivo objetivo en el bloque 1060 antes de continuar supervisando la red local en el bloque 1070.

[0081] De acuerdo con varios aspectos, la FIG. 11 ilustra otro ejemplo de flujo de llamadas 1100 en el que el dispositivo de control 1120 puede usarse para activar comandos en el dispositivo objetivo 1130 en respuesta a notificaciones de eventos radiodifundidas desde el dispositivo de origen 1110. En particular, el flujo de llamadas 1100 mostrado en la FIG. 11 puede ser en general similar al flujo de llamadas 900 mostrado en la FIG. 9 y descrito con más detalle anteriormente, en el que el dispositivo de control 1120 puede supervisar una red de IoT u otra red inalámbrica adecuada en 1142, visualizar la interfaz de usuario 1510 mostrada en la FIG. 15 en respuesta a la detección de una notificación de eventos radiodifundida desde el dispositivo de origen 1110 en 1144, 1146, y mostrar además las interfaces de usuario 1520, 1530, 1540 mostradas en la FIG. 15 para permitir que el usuario defina un comando de activación para enlazar con la notificación del evento en 1148. Sin embargo, el flujo de llamadas 1100 mostrado en la FIG. 11 puede diferir del flujo de llamadas 900 en la FIG. 9 en que, en 1150, el dispositivo de control 1120 puede transmitir un paquete de comandos al dispositivo de origen de radiodifusión 1110 después de que el usuario haya definido adecuadamente el comando para activar en el dispositivo objetivo 1130 basándose en la notificación de eventos radiodifundida desde el dispositivo de origen 1110. Como tal, en 1150, el dispositivo de control 1120 en general puede enviar la definición de activación y el comando vinculado al dispositivo de origen de radiodifusión 1110, que a continuación puede invocar el comando vinculado en el dispositivo objetivo controlable 1130 cuando el dispositivo de origen 1110 radiodifunde la notificación de eventos nuevamente en el futuro en 1152, 1154. Por ejemplo, en el caso de uso a modo de ejemplo descrito anteriormente, el dispositivo de origen 1110 puede ser un reloj de alarma, el dispositivo objetivo 1130 puede ser una unidad de aire acondicionado, y la definición de activación puede comprender encender la unidad de aire acondicionado y configurar la unidad de aire acondicionado a una velocidad y temperatura del ventilador en particular en respuesta al despertador que radiodifunde una notificación de eventos de repetición. Por consiguiente, en ese caso de uso a modo de ejemplo, el paquete de comandos transmitido desde el dispositivo de control 1120 al dispositivo de origen 1110 puede tener el siguiente formato a modo de ejemplo:

Tabla 1: Paquete de comandos a modo de ejemplo

[0082] Por consiguiente, como se muestra en la FIG. 11, el dispositivo de control 1120 puede transmitir el paquete de comandos que puede tener el formato anterior u otro formato adecuado al dispositivo de origen 1110 de manera que el dispositivo de origen 1110 pueda activar el comando definido en el paquete de comandos en el dispositivo objetivo 1130 en respuesta a la radiodifusión de la notificación del evento nuevamente en el futuro.

[0083] De acuerdo con varios aspectos, la FIG. 12 ilustra un procedimiento 1200 a modo de ejemplo en el que un dispositivo de control puede configurar un dispositivo de origen para activar un comando en un dispositivo objetivo en respuesta a la detección de una notificación de eventos radiodifundida desde el dispositivo de origen, que en general puede ser similar a las funciones realizadas en el dispositivo de control 1120 mostrado en la FIG.

11. En particular, en el bloque 1210, el dispositivo de control puede supervisar una red inalámbrica local y posteriormente detectar una notificación de eventos que el dispositivo de origen radiodifunde usando un protocolo D2D basado en proximidad adecuado en el bloque 1220. En respuesta a ello, el dispositivo de control puede determinar si la notificación de eventos es una notificación de eventos nueva (es decir, no observada previamente) en el bloque 1230, en cuyo caso el dispositivo de control puede mostrar una interfaz de usuario en el bloque 1240 para solicitar al usuario que descarte la notificación de eventos o definir un comando para activar en un dispositivo objetivo, lo cual puede estar vinculado a la notificación de eventos emitida desde el dispositivo de origen. Por consiguiente, en el bloque 1240, el dispositivo de control puede recibir una o más entradas de usuario, ya sea descartando la notificación de eventos o definiendo un comando para activar en el dispositivo objetivo y para enlazar con la notificación de eventos detectada en el bloque 1220. Por consiguiente, en respuesta a la determinación en el bloque 1250 de que las entradas recibidas en el dispositivo de control definieron un activador de comandos, el dispositivo de control puede transmitir un paquete de comandos al dispositivo de origen de radiodifusión en el bloque 1260. En cada caso mencionado en el presente documento, el dispositivo de control puede a continuación reanudar la supervisión de la red local en el bloque 1270 y no puede realizar ninguna acción adicional en respuesta a la detección de la misma notificación de eventos nuevamente en el futuro. En cambio, debido a que el dispositivo de control forzó la definición de activación y el comando vinculado al dispositivo de origen de radiodifusión en el bloque 1260, el dispositivo de origen puede invocar posteriormente el comando vinculado en el dispositivo objetivo controlable siempre que el dispositivo de origen radiodifunda la notificación del evento nuevamente en el futuro. Como tal, si el dispositivo de control determina que la notificación del evento se detecta nuevamente en el bloque 1230, el dispositivo de control puede simplemente reanudar la supervisión de la red local en el bloque 1270 sin tomar ninguna otra acción porque el dispositivo de origen ya estaba provisto con el comando vinculado a la notificación de eventos.

[0084] De acuerdo con varios aspectos, la FIG. 13 ilustra otro flujo de llamadas 1300 a modo de ejemplo que puede usarse para activar comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas desde un dispositivo de origen, en el que el flujo de llamadas 1300 mostrado en la FIG. 13 puede usarse en un contexto donde el dispositivo de control 1320 puede configurar un oyente en el dispositivo objetivo 1330 que hace que el dispositivo objetivo 1330 escuche ciertas notificaciones de eventos emitidas desde el dispositivo de origen 1310 e invoque ciertos comandos locales que pueden estar vinculados a las notificaciones de eventos en respuesta a la detección del oyente de que el dispositivo de origen 1310 radiodifundió las notificaciones de eventos. En particular, en 1342, el dispositivo de control 1320 puede aprender inicialmente las radiodifusiones de notificación de eventos que están soportadas en el dispositivo de origen 1310, y en 1344, el dispositivo de control 1320 puede aprender además uno o los comandos que están soportados en el dispositivo objetivo 1330. Por consiguiente, en varios modos de realización, el dispositivo de control 1320 puede ejecutar una aplicación apropiada que permite a un usuario registrar oyentes de radiodifusión en dispositivos controlables dentro de un entorno de red particular. Por ejemplo, refiriéndose a la FIG. 16, el dispositivo de control 1320 puede mostrar una interfaz de usuario 1610 que muestra uno o más dispositivos en el entorno de red que soportan las radiodifusiones de notificaciones de eventos en respuesta al usuario que inicia la aplicación que permite al usuario registrar los oyentes de radiodifusión (por ejemplo, la interfaz de usuario 1610 puede incluir botones que corresponden a una radio, una máquina de café, un calentador, una unidad de aire acondicionado, un despertador, luces, etc. que pueden radiodifundir ciertas notificaciones de eventos).

[0085] En consecuencia, en respuesta al usuario que selecciona el dispositivo de origen 1310 de los dispositivos de radiodifusión mostrados en la interfaz de usuario 1610, el dispositivo de control 1320 puede mostrar otra interfaz de usuario 1620 que muestra las radiodifusiones de notificación de eventos específicos que el dispositivo de origen 1310 ha aprendido que son soportadas en el dispositivo de origen 1310 (por ejemplo, en respuesta al usuario que selecciona el reloj de alarma de la interfaz de usuario 1610, el dispositivo de control 1320 puede mostrar la interfaz de usuario 1620 para mostrar que el reloj de alarma soporta radiodifusiones que se relacionan con un evento de "conjunto de alarma", un evento de "timbre de alarma", evento de "repetición de alarma", un evento de "alarma apagada", etc.). En varios modos de realización, el usuario puede seleccionar una radiodifusión de notificación de eventos particular que el dispositivo de origen 1310 soporta desde la interfaz de usuario 1620, lo cual puede hacer que el dispositivo de control 1320 muestre otra interfaz de usuario 1630 que muestre comandos que están vinculados a la radiodifusión de notificación de eventos seleccionada y proporcione una opción para vincular aún más la radiodifusión de notificación de eventos seleccionada a un comando particular en un dispositivo controlable dentro del entorno de red. Por ejemplo, el usuario puede seleccionar una opción "Agregar evento" de la interfaz de usuario 1630 y el dispositivo de control 1320 puede mostrar una interfaz de usuario 1640 que muestra los dispositivos controlables en el entorno de red que se pueden configurar para registrar oyentes asociados con la radiodifusión de notificación de eventos que se seleccionó de la interfaz de usuario 1620 (por ejemplo, la interfaz de usuario 1640 puede incluir botones que corresponden a la radio, cafetera, calentador, unidad de aire acondicionado, despertador, luces, etc.).

[0086] En varios modos de realización, en respuesta a que el usuario seleccione el dispositivo objetivo 1330 entre los dispositivos controlables mostrados en la interfaz de usuario 1640, el dispositivo de control 1320 puede mostrar otra interfaz de usuario 1650 que muestra que los procedimientos o comandos específicos que el dispositivo de origen 1310 ha aprendido son soportados en el dispositivo objetivo 1330 (por ejemplo, en respuesta a que el usuario seleccione la unidad de aire acondicionado de la interfaz de usuario 1640, el dispositivo de control 1320 puede mostrar la interfaz de usuario 1650 para mostrar que la unidad de aire acondicionado soporta procedimientos o comandos que se pueden usar para encender o apagar la unidad de aire acondicionado, configurar la velocidad del ventilador en la unidad de aire acondicionado, configurar la temperatura en la unidad de aire acondicionado, etc.). Como tal, en respuesta a que el usuario seleccione un procedimiento o comando particular de la interfaz de usuario 1650, el dispositivo de control 1320 puede mostrar nuevamente la interfaz de usuario 1630 que muestra comandos que están vinculados a la radiodifusión de notificación de eventos seleccionada, en el que la interfaz de usuario 1630 puede ahora rellenarse con el procedimiento o comando que se seleccionó de la interfaz de usuario 1650 para confirmar que el procedimiento o comando seleccionado se ha vinculado a la radiodifusión de notificación de eventos seleccionada desde la interfaz de usuario 1620. Refiriéndose a la FIG. 13, el dispositivo de control 1320 puede haber recibido la definición de activación de comandos en 1346. En varios modos de realización, en 1348, el dispositivo de control 1320 puede configurar o registrar de otro modo al oyente en el dispositivo objetivo 1330 en respuesta a que el usuario haya vinculado adecuadamente el procedimiento o comando soportado en el dispositivo objetivo 1330 con la radiodifusión de notificación de eventos soportada en el dispositivo de origen 1310. Como tal, el dispositivo objetivo 1330 puede ejecutar el oyente configurado en 1352, lo cual en general puede hacer que el dispositivo objetivo 1330 escuche la radiodifusión de notificación de eventos desde el dispositivo de origen 1310 (por ejemplo, la radiodifusión de notificación de eventos seleccionada desde la interfaz de usuario 1620). En consecuencia, en respuesta a que el dispositivo de origen 1310 radiodifunda la notificación de eventos en 1350, el dispositivo objetivo 1330 puede detectar la notificación de eventos a través del detector de eventos configurado y ejecutar el procedimiento o comando vinculado al mismo en 1354 (por ejemplo, el procedimiento o comando seleccionado del interfaz de usuario 1650) sin más intervención a través del dispositivo de control 1320.

[0087] De acuerdo con varios aspectos, la FIG. 14 ilustra un procedimiento a modo de ejemplo 1400 en el que un dispositivo de control puede configurar un dispositivo objetivo para escuchar una notificación de eventos radiodifundida desde un dispositivo de origen y activar un comando en respuesta a la detección de la notificación de eventos, que en general puede ser similar a las funciones realizadas en el dispositivo de control 1320 mostrado en la FIG. 13. En particular, en el bloque 1410, el dispositivo de control puede aprender inicialmente las radiodifusiones de notificación de eventos que están soportadas en el dispositivo de origen, y en el bloque 1420, el dispositivo de control puede aprender además uno o los comandos que están soportados en el dispositivo objetivo. En consecuencia, en varios modos de realización, el dispositivo de control puede ejecutar una aplicación apropiada que permite a un usuario definir y registrar oyentes de radiodifusión en dispositivos controlables dentro de un entorno de red particular, donde el bloque 1430 puede comprender recibir una o más de tales definiciones de activación de comandos (por ejemplo, como se ha descrito con más detalle anteriormente con respecto a la FIG. 13 y la FIG. 16). En varios modos de realización, en respuesta a recibir una o más definiciones de activación de comandos en el bloque 1430, el dispositivo de control puede crear un detector de eventos que vincule uno o más procedimientos o comandos soportados en el dispositivo objetivo con una o más notificaciones de eventos soportadas en el dispositivo de origen, en el que el dispositivo de control puede configurar el detector de eventos en el dispositivo objetivo en el bloque 1440. Como tal, el dispositivo objetivo puede ejecutar el oyente configurado, lo cual en general puede hacer que el dispositivo objetivo escuche la radiodifusión de notificación de eventos desde el dispositivo de origen (por ejemplo, la notificación de eventos definida en el oyente configurado) e invoque el procedimiento o comando vinculado al mismo en respuesta a la detección de la notificación del evento sin más intervención a través del dispositivo de control.

[0088] De acuerdo con varios aspectos, la FIG. 17 ilustra un dispositivo de comunicaciones 1700 a modo de ejemplo que puede usarse en conexión con cualquiera de los diversos aspectos y modos de realización descritos en el presente documento a través de la comunicación a través de un bus distribuido basado en proximidad que usa servicios D2D detectables. Por consiguiente, en el contexto de los diversos aspectos y modos de realización descritos anteriormente que se refieren a procedimientos para activar comandos en un dispositivo objetivo de acuerdo con notificaciones de eventos radiodifundidas desde un dispositivo de origen, el dispositivo de comunicación 1700 mostrado en la FIG. 17 puede corresponder al dispositivo de origen 910, 1110, 1310, el dispositivo de control 920, 1120, 1320 y/o el dispositivo objetivo 930, 1130, 1330 respectivamente mostrados en la FIG. 9, la FIG. 11 y la FIG. 13.

[0089] En varios modos de realización, como se muestra en la FIG. 17, el dispositivo de comunicaciones 1700 puede comprender un receptor 1702 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 1202 puede comprender un desmodulador 1704 que pueda desmodular los símbolos recibidos y proporcionarlos a un procesador 1706 para la estimación de canal. El procesador 1706 puede dedicarse a analizar la información recibida por el receptor 1702 y/o generar información para su transmisión mediante un transmisor 1720, controlar uno o más componentes del dispositivo de comunicaciones 1700 y/o cualquier combinación adecuada de los mismos.

[0090] En varios modos de realización, el dispositivo de comunicaciones 1700 puede incluir además una memoria 1708 acoplada de manera operativa al procesador 1706, en el que la memoria 1708 puede almacenar datos recibidos, datos que van a transmitirse, información relacionada con canales disponibles, datos asociados a señales analizadas y/o intensidades de interferencia, información relacionada con un canal asignado, potencia, velocidad o similares, y cualquier otra información adecuada para la estimación de un canal y las comunicaciones a través del canal. En varios modos de realización, la memoria 1708 puede incluir una o más aplicaciones de punto final local 1710, que pueden buscar comunicarse con aplicaciones de punto final, servicios, etc., en el dispositivo de comunicaciones 1700 y/u otros dispositivos de comunicación (no mostrados) a través de un módulo de bus distribuido 1730. La memoria 1708 puede almacenar adicionalmente protocolos y/o algoritmos asociados a la estimación y/o el uso de un canal (por ejemplo, basados en el rendimiento, basados en la capacidad, etc.).

[0091] Los expertos en la técnica apreciarán que la memoria 1708 y/u otros almacenes de datos descritos en el presente documento pueden ser memoria volátil o memoria no volátil, o pueden incluir tanto memoria volátil como memoria 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 (PRo M), 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 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 datos (SDRAM DDR), SDRAM mejorada (Es DrAM), DRAM de enlace síncrono (SLDRAM) y RAM de Rambus directo (DRRAM). La memoria 1708 de los presentes sistemas y procedimientos puede comprender, sin estar limitada a, estos y otros tipos adecuados de memoria.

[0092] En varios modos de realización, el módulo de bus distribuido 1730 asociado con el dispositivo de comunicaciones 1700 puede facilitar además el establecimiento de conexiones con otros dispositivos. El módulo de bus distribuido 1730 puede comprender además un módulo de nodo de bus 1732 para ayudar al módulo de bus distribuido 1730 a administrar las comunicaciones entre múltiples dispositivos. En varios modos de realización, el módulo de nodo de bus 1732 puede incluir además un módulo de denominación de objeto 1734 para ayudar al módulo de nodo de bus 1732 a comunicarse con las aplicaciones de punto final asociadas con otros dispositivos. Además, el módulo de bus distribuido 1730 puede incluir un módulo de punto final 1736 para ayudar a las aplicaciones de punto final locales 1710 a comunicarse con otros puntos finales locales y/o aplicaciones de punto final accesibles en otros dispositivos a través de un bus distribuido establecido. En otro aspecto, el módulo de bus distribuido 1730 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, wifi, etc.). En consecuencia, en varios modos de realización, el módulo de bus distribuido 1730 y las aplicaciones de punto final 1710 pueden usarse para establecer y/o unirse a un bus distribuido basado en proximidad a través del cual el dispositivo de comunicación 1700 puede comunicarse con otros dispositivos de comunicación en las proximidades del mismo usando comunicación directa de dispositivo a dispositivo (D2D).

[0093] Adicionalmente, en varios modos de realización, el dispositivo de comunicaciones 1700 puede incluir una interfaz de usuario 1740, que puede incluir uno o más mecanismos de entrada 1742 para generar entradas en el dispositivo de comunicaciones 1700, y uno o más mecanismos de salida 1744 para generar información para el consumo del usuario del dispositivo de comunicaciones 1700. Por ejemplo, los mecanismos de entrada 1742 pueden incluir un mecanismo tal como una tecla o teclado, un ratón, una pantalla táctil, un micrófono, etc. Además, por ejemplo, los mecanismos de salida 1744 pueden incluir una pantalla, un altavoz, un mecanismo de respuesta háptica, un transceptor de red de área personal (PAN), etc. En los aspectos ilustrados, los mecanismos de salida 1744 pueden 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 varios modos de realización, un dispositivo de comunicaciones sin terminal 1700 puede no incluir ciertos mecanismos de entrada 1742 y/o mecanismos de salida 1744 porque los dispositivos sin terminal en general se refieren a sistemas o dispositivos informáticos que han sido configurados para funcionar sin un monitor, teclado y/o ratón.

[0094] Además, en varios modos de realización, el dispositivo de comunicaciones 1700 puede incluir uno o más sensores 1750 que pueden obtener diversas medidas relacionadas con un entorno local asociado con el dispositivo de comunicaciones 1700. Por ejemplo, en varios modos de realización, los sensores 1750 pueden incluir un acelerómetro, giroscopio u otros sensores adecuados que pueden obtener medidas que se relacionan con el movimiento infligido en el dispositivo de comunicaciones 1700. En otro ejemplo, los sensores 1750 pueden incluir hardware, circuitos u otros dispositivos adecuados que puedan obtener mediciones relacionadas con la temperatura interna y/o ambiental, el consumo de energía, las señales de radio locales, la iluminación y/u otras variables medioambientales locales y/o ambientales.

[0095] De acuerdo con varios aspectos, la FIG. 18 ilustra un entorno de red doméstica conectada a modo de ejemplo 1800 en el que se puede utilizar cualquiera de los diversos procedimientos para activar comandos en un dispositivo objetivo en respuesta a notificaciones de eventos radiodifundidas desde un dispositivo de origen, en el que el entorno 1800 de red doméstica conectada a modo de ejemplo puede incluir varios dispositivos IoT que pueden configurarse para interactuar entre sí de diversas formas para llevar a cabo los diversos procedimientos para activar comandos en un dispositivo objetivo como se describe con más detalle anteriormente. Por ejemplo, en el ejemplo mostrado en la FIG. 18, el entorno de red doméstica conectada 1800 incluye un teléfono inteligente 1870, altavoces exteriores 1812, 1814, un reloj despertador 1816, altavoces de dormitorio 1818, un termostato 1820, una lavadora 1822, un reloj de pared 1824, una cafetera 1826, un altavoz de suelo de sala de estar 1828, un sistema de audio de estantería 1830, altavoces de cine en casa 1832, 1834, un pomo de puerta 1836, un refrigerador 1850, un televisor 1852, un teléfono inteligente 1870 y un router inalámbrico o pasarela doméstica 1872. Además, como se muestra en la FIG. 18, los diversos dispositivos IoT en el entorno 1800 de red doméstica pueden configurarse para funcionar en una o más de las diversas funciones descritas con más detalle anteriormente (por ejemplo, el dispositivo de control, el dispositivo de origen, el dispositivo objetivo, etc.). En consecuencia, en varios modos de realización, el teléfono inteligente 1870, el router inalámbrico o la pasarela doméstica 1872 u otro dispositivo adecuado en el entorno 1800 pueden funcionar como el dispositivo de control que puede activar comandos en uno o más dispositivos objetivo en respuesta a la detección de una notificación de eventos radiodifundida desde uno o más dispositivos de origen. Por ejemplo, en un modo de realización, el teléfono inteligente 1870 puede supervisar el entorno local 1800 y detectar una notificación de eventos que emite el despertador 1816 usando un protocolo D2D basado en proximidad adecuado, y en respuesta a ello, el teléfono inteligente 1870 puede comunicarse con uno o más dispositivos objetivo que utilizan tecnología D2D para invocar un activador de comandos previamente definido (por ejemplo, subir la temperatura en el termostato 1820, encender la máquina de café 1826, etc.). En otro ejemplo, el teléfono inteligente 1870 puede transmitir un paquete de comandos al reloj de alarma 1816 cuando el activador de comandos se define inicialmente, de modo que el reloj de alarma 1816 puede invocar posteriormente el comando vinculado en el dispositivo o dispositivos objetivo controlables siempre que radiodifunda la misma notificación de eventos de nuevo en el futuro. En otro ejemplo más, el teléfono inteligente 1870 puede aprender notificaciones de eventos y comandos que son soportadas con los diversos dispositivos IoT en el entorno 1800, de modo que un usuario puede definir y registrar oyentes de radiodifusión en uno o más de los dispositivos IoT en el entorno de red 1800. Como tal, en respuesta a recibir una o más definiciones de activación de comandos del usuario, el teléfono inteligente 1870 puede crear un detector de eventos que vincule uno o más procedimientos o comandos soportados en un dispositivo objetivo particular con una o más notificaciones de eventos soportadas en un dispositivo de origen particular y configurar el oyente de eventos en el dispositivo objetivo, por lo que el dispositivo objetivo puede ejecutar el oyente configurado e invocar el procedimiento o comando vinculado al mismo en respuesta a la detección de la notificación de eventos desde el dispositivo de origen sin más intervención a través del teléfono inteligente 1870.

[0096] Los expertos en la técnica apreciarán que la información y las señales pueden representarse usando cualquiera de 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 chips de información que se puedan haber mencionado a lo largo de la descripción anterior se pueden representar por tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos, o cualquier combinación de los mismos.

[0097] Además, los expertos en la técnica 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 se pueden implementar como hardware electrónico, software informático o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito en general diversos componentes, bloques, módulos, circuitos y pasos ilustrativos en lo que respecta a su funcionalidad. Que dicha funcionalidad se implemente 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 técnica pueden implementar la funcionalidad descrita de diversas maneras para cada aplicación particular, pero dichas decisiones de implementación no deben interpretarse como una desviación del alcance de los diversos aspectos y modos de realización descritos en el presente documento.

[0098] Los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los aspectos divulgados en el presente documento se pueden implementar o realizar 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 por campo (FPGA) u otro dispositivo de lógica programable, lógica de transistores o de puertas discretas, componentes de hardware discretos o con 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, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar 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).

[0099] Los procedimientos, secuencias y/o algoritmos descritos en relación con los aspectos divulgados en el presente documento se pueden realizar 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 modo que el procesador pueda leer información de, y escribir información en, el medio de almacenamiento. 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 IoT. De forma alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.

[0100] En uno o más aspectos a modo de ejemplo, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador como una o más instrucciones o código. Los medios legibles por ordenador incluyen tanto medios de almacenamiento informático como medios de comunicación incluyendo 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 se pueda acceder 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, de almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para llevar o almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Además, cualquier conexión recibe apropiadamente 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 lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.

[0101] Si bien que la divulgación anterior muestra aspectos y modos de realización ilustrativos, los expertos en la técnica apreciarán que se pueden realizar diversos cambios y modificaciones en el presente documento sin apartarse del alcance de la divulgación como se define mediante las reivindicaciones adjuntas. No es necesario que las funciones, pasos y/o acciones de las reivindicaciones de procedimiento de acuerdo con los aspectos y modos de realización descritos en el presente documento se realicen en ningún orden particular. Además, aunque los elementos se pueden describir anteriormente o reivindicar en singular, se contempla el plural a menos que se indique explícitamente la limitación al singular.

Claims (11)

REIVINDICACIONES

1. Un procedimiento para activar comandos basados en notificaciones de eventos, que comprende:

identificar (1146, 1342), en un dispositivo de control (1120, 1320), una notificación de eventos soportada en un dispositivo de origen (1110, 1310);

identificar, en el dispositivo de control (1120, 1320), uno o más comandos soportados en un dispositivo objetivo (1130, 1330);

mostrar en el dispositivo de control uno o más comandos para que los seleccione un usuario; definir (1148, 1346), en el dispositivo de control, un activador que vincula la notificación de eventos soportada en el dispositivo de origen a un comando seleccionado por el usuario de uno o más comandos soportados en el dispositivo objetivo, en el que el activador definido hace que el dispositivo objetivo ejecute el comando identificado en respuesta al dispositivo de origen que radiodifunde la notificación del evento identificado;

el procedimiento caracterizado por comprender además transmitir (1150), desde el dispositivo de control (1120) al dispositivo de origen (1110), el activador que vincula la notificación de eventos soportada en el dispositivo de origen (1110) con el comando soportado en el dispositivo objetivo (1130), en el que el activador transmitido hace que el dispositivo de origen (1110) invoque directamente el comando en el dispositivo objetivo (1130), sin comunicarse con el dispositivo de control, cuando el dispositivo de origen radiodifunde (1152) la notificación del evento identificado.

2. El procedimiento según la reivindicación 1, que comprende además:

configurar (1348), mediante el dispositivo de control (1320), un oyente asociado con el activador definido en el dispositivo objetivo (1330), en el que el oyente configurado hace que el dispositivo objetivo escuche la notificación del evento identificado y ejecute (1354) el comando en respuesta a la detección (1352) de que el dispositivo de origen radiodifundió (1350) la notificación de eventos vinculada al comando identificado.

3. El procedimiento según la reivindicación 1, que comprende además:

definir, en el dispositivo de control (1120, 1320), un activador objetivo que vincula la notificación de eventos soportada en el dispositivo de origen (910, 1110, 1310) a un comando objetivo soportado en un tercer dispositivo, donde el activador objetivo hace que el tercer dispositivo ejecute el comando objetivo en respuesta al dispositivo de origen (910, 1110, 1310) que radiodifunde la notificación del evento identificado.

4. El procedimiento mencionado en la reivindicación 1, en el que definir el activador comprende además: desactivar uno o más activadores existentes que vinculan la notificación del evento identificado con uno o más comandos que entran en conflicto con el comando soportado en el dispositivo objetivo.

5. El procedimiento mencionado en la reivindicación 1, en el que:

el dispositivo de control (920, 1120, 1320), el dispositivo de origen (910, 1110, 1310) y el dispositivo objetivo (930, 1130, 1330) se comunican de forma inalámbrica utilizando un protocolo de dispositivo a dispositivo basado en proximidad; o

el dispositivo de origen (910, 1110, 1310) y el dispositivo objetivo (930, 1130, 1330) comprenden dispositivos de Internet de las cosas.

6. Un dispositivo de control (920, 1120, 1320) para activar comandos basados en notificaciones de eventos, que comprende:

medios para identificar una notificación de eventos soportada en un dispositivo de origen; medios para identificar uno o más comandos soportados en un dispositivo objetivo;

medios para visualizar en el dispositivo de control, uno o más comandos para la selección por parte de un usuario;

medios para definir un activador que vincule la notificación de eventos soportada en el dispositivo de origen con un comando seleccionado por el usuario de uno o más comandos soportados en el dispositivo objetivo, en el que el activador definido hace que el dispositivo objetivo ejecute el comando identificado en respuesta al dispositivo de origen que radiodifunde la notificación del evento identificado;

el dispositivo de control caracterizado por comprender además medios para transmitir (1150), desde el dispositivo de control (1120) al dispositivo de origen (1110), el activador que vincula la notificación de eventos soportada en el dispositivo de origen (1110) al comando soportado en el dispositivo objetivo (1130), en el que el activador transmitido hace que el dispositivo de origen (1110) invoque directamente el comando en el dispositivo objetivo (1130), sin comunicarse con el dispositivo de control, cuando el dispositivo de origen radiodifunde (1152) la notificación del evento identificado.

7. El dispositivo de control mencionado en la reivindicación 6, que comprende además:

medios para configurar un oyente asociado con el activador definido en el dispositivo objetivo, en el que el oyente configurado hace que el dispositivo objetivo escuche la notificación del evento identificado y ejecute el comando identificado en respuesta a la detección de que el dispositivo de origen radiodifundió la notificación de eventos vinculada al comando identificado.

8. El dispositivo de control mencionado en la reivindicación 6, que comprende además:

medios para definir un segundo activador que vincula la notificación de eventos soportada en el dispositivo de origen con un segundo comando soportado en un tercer dispositivo, en el que el segundo activador hace que el tercer dispositivo ejecute el segundo comando en respuesta a que el dispositivo de origen radiodifunda la notificación de eventos identificado.

9. El dispositivo de control mencionado en la reivindicación 6, en el que los medios para definir el activador comprenden además:

medios para desactivar uno o más activadores existentes que enlazan la notificación del evento identificado con un comando que entra en conflicto con el comando soportado en el dispositivo objetivo; o

medios para comunicarse de forma inalámbrica con el dispositivo de origen y el dispositivo objetivo utilizando un protocolo de dispositivo a dispositivo basado en la proximidad.

10. El dispositivo de control de cualquiera de las reivindicaciones 6 a 9, que comprende:

uno o más procesadores (1706), en el que dichos uno o más procesadores están configurados para proporcionar:

los medios para identificar una notificación de eventos;

los medios para identificar un comando; y

los medios para definir un activador.

11. Un medio de almacenamiento no transitorio legible por ordenador que tiene instrucciones ejecutables por ordenador grabadas en el mismo, en el que la ejecución de las instrucciones ejecutables por ordenador en un ordenador hace que el ordenador realice un procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 5.