ES2604609T3

ES2604609T3 - Control de dispositivos usando servicios en la nube y mecanismos de tubo agnósticos a los dispositivos

Info

Publication number: ES2604609T3
Application number: ES14709002.1T
Authority: ES
Inventors: Ehab Sobhy
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2013-02-18
Filing date: 2014-02-13
Publication date: 2017-03-07
Anticipated expiration: 2034-02-13
Also published as: US20170201586A1; US9288102B2; CN105075188B; US20160134706A1; EP2957076B1; WO2014127075A1; US9667727B2; US20140237092A1; EP2957076A1; CN105075188A

Abstract

Un entorno para controlar una pluralidad de dispositivos objetivos, que se compone de: una pluralidad de mecanismos de tubo asociados con los respectivos dispositivos objetivos; un sistema de servicio, que incluye: una pluralidad de módulos de servicio configurados para proporcionar una pluralidad de servicios respectivos, los servicios, a su vez, se usan en el control de una pluralidad de dispositivos objetivos; un módulo de interfaz de dispositivo controlado configurado para permitir que los dispositivos objetivos puedan interactuar con los servicios a través de la pluralidad de mecanismos de tubo que están asociados con los respectivos dispositivos objetivos, incorporando cada mecanismo de tubo una funcionalidad agnóstica al dispositivo que posibilita que el mecanismo de tubo pueda interactuar con múltiples tipos de dispositivos objetivos y un módulo de interfaz de dispositivo de usuario configurado para permitir a una pluralidad de dispositivos de usuario interactuar con los servicios, a través de aplicaciones, para configurar los servicios; el sistema de servicio que es accesible al mecanismo de tubo a través de una red de área extensa.

Description

5

10

15

20

25

30

35

40

45

50

DESCRIPCION

Control de dispositivos usando servicios en la nube y mecanismos de tubo agnosticos a los dispositivos Antecedentes

Algunos fabricantes de dispositivos han intentado hacer sus dispositivos mas “inteligentes” incorporando modulos de procesamiento en los dispositivos. Por ejemplo, un fabricante de automoviles de alta gama puede producir un sistema de control que es accionado por uno o mas modulos de procesamiento. Cada modulo de procesamiento puede ejecutar una o mas aplicaciones. Un usuario puede interactuar con esas aplicaciones a traves de un dispositivo de monitor de a bordo, como un monitor LCD o similar. El usuario puede tambien programar las aplicaciones a traves de esta forma de interaccion.

Algunos fabricantes de dispositivos tambien proporcionan dispositivos que tienen la capacidad de interactuar con funcionalidades remotas. Por ejemplo, un sistema de control de un automovil puede acoplar sus modulos de procesamiento con un servidor remoto. Las aplicaciones que se ejecutan en el sistema de control pueden intercambiar datos con esta funcionalidad remota con propositos varios, por ejemplo, para recibir mapas, contenido multimedia, etc.

Las anteriores estrategias de control proveen a los consumidores de dispositivos mas versatiles y complejos. Sin embargo, por razones que se especifican aquf, estas estrategias tambien tienen inconvenientes en potencia.

El documento US2008/080552 A1 describe un sistema para asignar recursos de hardware a clientes remotos. El documento US2005/076125A1 describe una interconexion que acopla al iniciador y recursos de red objetivos.

Compendio

Se describe aquf un entorno que incluye un sistema de servicio que alberga uno o mas servicios. El servicio provee logica que controla la operacion de una pluralidad de dispositivos objetivos. Esta estrategia elimina la necesidad de proporcionar a los dispositivos objetivos de inteligencia “incorporada” local. En otras palabras, en una implementacion, los dispositivos objetivos pueden producirse como equipamiento “pasivo” que carece de (o tengan dependencia limitada en) logica de control local.

Segun una realizacion, los servicios se acoplan a los dispositivos objetivos a traves de mecanismos de tubo respectivos. Los mecanismos de tubo manejan el flujo de datos desde los dispositivos objetivos al sistema de servicio, y el flujo de instrucciones de control desde el sistema de servicio a los dispositivos objetivos. En una implementacion, los mecanismos de tubo se construyen de una forma agnostica (independiente del) al dispositivo. Esto significa que cualquier mecanismo de tubo es capaz de interactuar con multiples tipos de dispositivos objetivos, sin considerar la funcionalidad nativa proporcionada por los dispositivos objetivos.

Segun otra realizacion el mecanismo de tubo agnostico al dispositivo puede ser suministrado a los fabricantes de dispositivos. Los fabricantes de dispositivos pueden entonces incorporar los mecanismos de tubo en sus respectivos dispositivos objetivos. Alternativamente, o ademas, los mecanismos de tubo pueden ser suministrados a los usuarios finales de los dispositivos objetivos. Los usuarios finales pueden entonces acoplar los mecanismos de tubo a los dispositivos objetivos de forma desmontable. En una implementacion, cada mecanismo de tubo puede estar pre- programado para interactuar con el sistema de servicio, por ejemplo, almacenando la direccion del sistema de servicio en su almacen de datos. Cada mecanismo de tubo puede tambien incluir una funcionalidad que lo habilite para interactuar con el sistema de servicio de una forma segura; por ejemplo, la interaccion puede utilizar el protocolo de Seguridad de la Capa de Transporte (TLS), y/o algun otro mecanismo o protocolo de seguridad.

Segun otra realizacion un usuario puede interactuar con un servicio a traves de una aplicacion que se ejecute en cualquier dispositivo de usuario, como un telefono inteligente, un dispositivo tableta, un ordenador personal, etc. A traves de este canal, el usuario puede configurar el servicio para controlar el dispositivo objetivo del usuario de la forma deseada.

Segun otra realizacion el sistema de servicio puede proveer funcionalidad de configuracion que permita a un usuario establecer un nexo entre una cuenta de usuario, un dispositivo objetivo particular, y el mecanismo de tubo asociado con el dispositivo objetivo.

Las anteriores estrategias de control se pueden manifestar en varios tipos de sistemas, componentes, metodos, medios de almacenamiento lefbles por ordenador, estructuras de datos, artfculos de fabricantes, y demas.

Este compendio se provee para presentar una seleccion de conceptos de una forma simplificada; estos conceptos son descritos mas a fondo abajo en la Descripcion Detallada. La invencion se define segun las reivindicaciones independientes.

5

10

15

20

25

30

35

40

45

50

Breve descripcion de los dibujos

Fig. 1 muestra un entorno ilustrativo en el que un sistema de servicio interactua con una pluralidad de dispositivos objetivos a traves de una pluralidad de mecanismos de tubo, con el proposito de controlar los dispositivos objetivos.

Fig. 2 provee un resumen de alto nivel de dos estrategias para proveer mecanismos de tubo a destinatarios (fabricantes de dispositivos y usuarios finales, respectivamente).

Fig. 3-5 muestran tres opciones diferentes para acoplar un mecanismo de tubo a un dispositivo objetivo.

Fig. 6 muestra una implementacion de un mecanismo de tubo.

Fig. 7 muestra una implementacion de funcionalidad de computacion que puede ser usada para proveer al sistema de servicio, o a un usuario de dispositivo de interaccion con el sistema de servicio.

Fig. 8 es un procedimiento que describe una estrategia para controlar dispositivos objetivos que usan el entorno de la Fig. 1.

Fig. 9 es un procedimiento que describe un modo de establecer una asociacion que conecte un dispositivo objetivo, un mecanismo de tubo, y una cuenta de usuario.

Fig. 10 es un procedimiento que describe un modo de proveer una aplicacion a una entidad, para usar por la entidad en la interaccion con un servicio.

Fig. 11 es un procedimiento que describe un modo de manejar la comunicacion en la cual los datos fluyen desde el dispositivo objetivo al sistema de servicio.

Fig. 12 es un procedimiento que describe un modo de manejar la comunicacion en la cual un usuario interactua con el sistema de servicio.

Los mismos numeros se usan a traves de la descripcion y figuras para hacer referencia a componentes y caracterfsticas similares. Los numeros de la serie 100 se refieren a caracterfsticas encontradas originalmente en la Fig. 1, los numeros de la serie 200 se refieren a caracterfsticas encontradas originalmente en la Fig. 2, los numeros de la serie 300 se refieren a caracterfsticas encontradas originalmente en la Fig. 3, etcetera.

Descripcion detallada

Esta descripcion esta organizada como sigue. La Seccion A describe un entorno ilustrativo para controlar dispositivos objetivos usando un sistema de servicio y mecanismos de tubo agnosticos a los dispositivos. La Seccion B describe metodos ilustrativos que explican la operacion de la funcionalidad de la Seccion A

Como un asunto preliminar, algunas de las figuras describen conceptos en el contexto de uno o mas componentes estructurales, referidos de forma distinta como funcionalidad, modulos, caracterfsticas, elementos, etc. Los diferentes componentes mostrados en las figuras pueden ser implementados de cualquier manera por cualquier mecanismo ffsico y tangible, por ejemplo, por software, hardware (por ejemplo, funcionalidad logica implementada en chip), firmware, etc., y/o cualquier combinacion de los mismos. En un caso, la separacion ilustrada de varios componentes en las figuras en unidades diferentes puede reflejar el uso de los diferentes componentes ffsicos y tangibles correspondientes en una implementacion real. Aternativamente, o ademas, cualquier componente unico ilustrado en las figuras puede ser implementado por multitud de componentes ffsicos reales. Alternativamente, o ademas, la representacion de cualesquiera dos o mas componentes separados en las figuras pueden reflejar diferentes funciones realizadas por un unico componente ffsico real. Las Figs. 1-7, que seran descritas por turnos, proveen detalles adicionales sobre una implementacion ffsica ilustrativa de las funciones mostradas en las figuras.

Otras figuras describen los conceptos en forma de diagramas de flujo. De esta forma, ciertas operaciones se describen como la composicion de bloques diferentes realizadas en un orden concreto. Tales representaciones son ilustrativas y no limitantes. Ciertos bloques descritos aquf pueden ser agrupados juntos y realizados en una unica operacion, ciertos bloques pueden ser separados en bloques con multiples componentes, y ciertos bloques pueden ser realizados en un orden que difiera de aquel ilustrado aquf (incluyendo una forma paralela de realizar los bloques). Los bloques mostrados en los diagramas de flujo pueden implementarse de cualquier manera por cualquier mecanismo ffsico y tangible, por ejemplo, por software, hardware (por ejemplo, funcionalidad logica implementada en chip), firmware, etc., y/o cualquier combinacion de los mismos.

En cuanto a terminologfa, la frase “configurado para” incluye cualquier forma en que cualquier tipo de funcionalidad ffsica y tangible puede ser construida para realizar una operacion identificada. La funcionalidad puede ser configurada para realizar una operacion usando, por ejemplo, software, hardware (por ejemplo, funcionalidad logica implementada en chip), firmware, etc., y/o cualquier combinacion de los mismos.

El termino “logico” induye cualquier funcionalidad ffsica y tangible para realizar una tarea. Por ejemplo, cada operacion ilustrada en los diagramas de flujo se corresponde con un componente logico para realizar esa operacion.

3

5

10

15

20

25

30

35

40

45

50

55

Una operacion puede ser realizada usando, por ejemplo, software, hardware (por ejemplo, funcionalidad logica implementada en chip), firmware, etc., y/o cualquier combinacion de los mismos. Cuando se implementa con un sistema informatico, un componente logico representa un componente electrico que es una parte fisica del sistema informatico, como quiera que se haya implementado.

La siguiente explicacion puede identificar una o mas caracterfsticas como “opcional”. Este tipo de declaracion no debe interpretarse como una indicacion exhaustiva de caracterfsticas que pueden ser consideradas opcionales; esto es, otras caracterfsticas pueden ser consideradas como opcionales, aunque no se identifiquen expresamente en el texto. Finalmente, los terminos “ejemplar” o “ilustrativo” se refieren a una implementacion entre muchas implementaciones potenciales.

A Entorno ilustrativo

La Fig. 1 muestra un entorno ilustrativo 100 en el que un sistema de servicio 102 interactua con una pluralidad de dispositivos objetivos 104 (D1, D2, ... Dn) a traves de una pluralidad de mecanismos de tubo 106 respectivos (P1, P2, ... Pn). Una pluralidad de usuarios pueden tambien interactuar con el sistema de servicio 102 usando una pluralidad de dispositivos de usuario 108 (U1, U2, ... Un) que ejecutan aplicaciones 110 (A1, A2, ... An). Los usuarios pueden controlar los dispositivos objetivos 104 a traves de estos canales. Por ejemplo, un usuario puede interactuar con una aplicacion para programar un servicio albergado en el sistema de servicio 102. Basandose en esa programacion, el servicio puede tener el efecto de controlar el dispositivo objetivo. El servicio puede tambien recibir datos desde el dispositivo objetivo. Generalmente, los dispositivos 104 son referidos como dispositivos “objetivos” para indicar que ellos representan el objetivo de control, y para distinguir estos dispositivos objetivos 104 de los dispositivos de usuario 108.

Cada mecanismo de tubo cumple con un rol agnostico al control de pasar informacion entre un dispositivo objetivo y el sistema de servicio 102. Se dice que el mecanismo de tubo es agnostico al control porque no esta configurado para realizar ninguna funcion(es) de control particular(es), o para interpretar la informacion que pasa traves de el respecto a cualquier regimen de control particular. Por el contrario, puede ser usado en el contexto de cualquier tipo de regimen de control.

Ademas, cada mecanismo de tubo se construye de una forma agnostica al dispositivo. Esto significa que cada mecanismo de tubo tiene la capacidad de interactuar con diferentes tipos de dispositivos objetivos 104, independientemente de la funcionalidad nativa provista por los dispositivos objetivos 104. En un caso, el entorno 100 consigue este resultado albergando un grupo de mecanismos de tubo 106 identicamente construidos. Esto es, en este caso, cada mecanismo de tubo tiene el mismo hardware y programacion que los otros mecanismos de tubo. En otro caso, el entorno 100 proporciona diferentes clases de mecanismos de tubo 106. Cada clase puede diferir de las otras alojando un tipo diferente de comunicacion, como comunicacion movil, comunicacion por satelite, comunicacion WIFI, comunicacion a traves de conexion con cable, etc.

El entorno 100 ofrece uno o mas beneficios potenciales. Primero, el entorno 100 delega la “inteligencia” asociada con la tarea de control al sistema de servicio 102, en vez de a cada dispositivo objetivo individual. Como resultado, el entorno 100 da a los fabricantes de dispositivos la libertad de producir dispositivos objetivos 104 que sean -en diversos grados- considerados “tontos” o "pasivos". Un dispositivo pasivo se refiere a un dispositivo que carece de inteligencia implementada en el procesador y/u otras facetas de control implementado localmente. El entorno 100 tambien permite a los fabricantes de dispositivos eliminar o reducir mecanismos de entrada/salida que son tfpicamente usados por dispositivos inteligentes, por ejemplo, para programar e interactuar con estos dispositivos. Estos aspectos, a su vez, pueden reducir la complejidad y coste del proceso de fabricacion.

Segundo, el entorno 100 provee un marco de trabajo uniforme y estandar para controlar diferentes tipos de dispositivos objetivos 104. Este aspecto, a su vez, puede beneficiar a los fabricantes de dispositivos tanto como a los usuarios finales reduciendo la complejidad y coste asociado con la tarea de controlar multiples dispositivos objetivos 104. Por ejemplo, el entorno 100 libera a un usuario final de la responsabilidad de aprender diferentes protocolos de control asociados con diferentes dispositivos objetivos. El entorno 100 tambien ofrece al usuario final un mecanismo mas conveniente para programar cada dispositivo objetivo (que sera descrito mas adelante), comparado a interactuar con el mecanismo de entrada/salida asociado con el dispositivo objetivo en sf.

Las ventajas anteriores se citan a modo de ejemplo, no de limitacion. Otras implementaciones del entorno 100 pueden ofrecer ventajas tecnicas adicionales.

Saltando hacia adelante momentaneamente en la secuencia de figuras, considere el resumen conceptual de alto nivel provisto en la Fig. 2. Esa figura muestra dos estrategias que puede ser usadas para proporcionar mecanismos de tubo 106 a los fabricantes de dispositivos (en el caso de la opcion A) y usuarios finales (en el caso de la opcion B). En ambas opciones, una entidad (o entidades) que provee los mecanismos de tubo es referida como un proveedor de tubo 202. En un caso, el proveedor de tubo 202 se corresponde con la misma entidad que provee y administra el sistema de servicio 102. En otro caso, el proveedor de tubo 202 y la entidad que alberga el sistema de servicio 102 son dos entidades diferentes respectivamente. Esto es, en esta realizacion, una primera empresa puede producir los mecanismos de tubo, mientras que una segunda empresa puede operar el sistema de servicio 102.

5

10

15

20

25

30

35

40

45

50

55

60

En la opcion A el proveedor de tubo 202 puede proveer los mecanismos de tubo 106 a fabricantes de dispositivos 204. (Aqm, el termino “fabricante de dispositivos” incluye fabricantes que producen dispositivos objetivos desde “cero” basandose en materia prima, ademas de fabricantes que montan dispositivos objetivos desde componentes pre-construidos mas pequenos, ademas de fabricantes que realizan una combinacion de estas actividades.) Los fabricantes de dispositivos 204 pueden anadir los mecanismos de tubo 106 a los dispositivos objetivos 104 como parte del proceso de fabricacion de los dispositivos objetivos 104. Los fabricantes de dispositivos 204 pueden usar diferentes estrategias para conseguir este resultado. En un caso, los fabricantes de dispositivos pueden incorporar los mecanismos de tubo como componentes fijos de los dispositivos objetivos. En otro caso, los fabricantes de dispositivos pueden anadir los mecanismos de tubo como componentes separables de los dispositivos objetivos. En ambos casos, los fabricantes de dispositivos ofrecen dispositivos objetivos 104 a usuarios finales que incluyen los mecanismos de tubo 106 ya instalados en ellos.

En la opcion B, el proveedor de tubo 202 puede proveer los mecanismos de tubo 106 a usuarios finales 206. Los usuarios finales 206 pueden entonces anadir los mecanismos de tubo 106 a los dispositivos objetivo 104. Por ejemplo, los fabricantes de dispositivos 204 pueden producir un tipo de dispositivo objetivo que tenga una ranura u otro tipo de interfaz de acoplamiento que aloje la posterior fijacion del mecanismo de tubo. Un usuario final puede adquirir ese dispositivo objetivo, y entonces, opcionalmente, adquirir despues un mecanismo de tubo para usar en conjunto con el dispositivo objetivo. El usuario final puede entonces acoplar el mecanismo de tubo al dispositivo objetivo a traves de la interfaz que se provee en el dispositivo objetivo. Alternativamente, el usuario final puede quitar un mecanismo de tubo existente que este en ese momento acoplado al dispositivo objetivo y reemplazarlo con una version actualizada o mejorada del mecanismo de tubo.

Las dos estrategias identificadas arriba se citan a modo de ejemplo, no de limitacion. Aun otras estrategias se pueden usar para suministrar mecanismos de tubo 106 a entidades para usar en conjunto con los dispositivos objetivos 104.

En cualquiera de los casos anteriores, la entidad que alberga el sistema de servicio 102 (“la entidad albergadora”) puede pedir al receptor de un mecanismo de tubo que acepte los terminos de un acuerdo de licencia para usar el mecanismo de tubo. Por ejemplo, el receptor puede equivaler a un fabricante de dispositivos o a un usuario final. En un enfoque, la entidad que alberga puede pedir al receptor pagar una unica tasa para usar el mecanismo de tubo. Este tipo de licencia puede ser la opcion mas apropiada para un fabricante de dispositivos. En otro caso, la entidad que alberga puede pedir al receptor pagar una tasa periodica (por ejemplo, una tasa mensual) para usar el mecanismo de tubo. En otro caso, la entidad que alberga puede pedir al receptor pagar una tasa basada en el uso para usar el mecanismo de tubo. Por ejemplo, la entidad albergadora puede monitorizar la cantidad de datos que pasa a traves del mecanismo de tubo (en direccion de subida y/o de bajada), y entonces calcular una tasa mensual basada en esa cantidad.

En otro enfoque, la entidad albergadora puede permitir que los receptores usen los mecanismos de tubo 106 sin pagar una tasa. En este caso, la entidad albergadora puede proveer anuncios a los usuarios finales que visitan el sistema de servicio 102 por cualquier razon, por ejemplo, para obtener nuevas aplicaciones, o para configurar servicios. La entidad albergadora puede recaudar tasas de anuncios de los anunciantes. Ademas, o alternativamente, la entidad albergadora puede usar los anuncios para dirigir el trafico online a otros productos y servicios que ofrezca. Todavfa son posibles otros enfoques por los cuales la entidad albergadora puede monetizar el uso de los mecanismos de tubo 106, aun si no fabrica o distribuye el mecanismo de tubo 106 ella misma.

Volviendo a la Fig. 1, los componentes de esta figura se describiran ahora en detalle. Empezando con los dispositivos objetivos 104, estos dispositivos pueden representar cualquier tipo de funcionalidad. Por ejemplo, un subconjunto de los dispositivos objetivos 104 puede corresponderse a electrodomesticos u otro equipamiento provisto en los hogares. Esos dispositivos objetivos incluyen mecanismos de iluminacion, cerraduras, abridores de puertas de garaje, persianas automatizadas, equipo de seguridad, calefactores, unidades de aire acondicionado, humidificadores, equipamiento de lavandena (secadoras, lavadoras, etc.), equipamiento de cocina (frigonficos, cocinas, homos, extractores, batidoras, cafeteras, etc.), equipamiento de cuarto de bano (secadores de pelo, cepillos electricos, equipamiento de afeitado, etc.), equipamiento multimedia (televisores, equipamiento de reproduccion de musica, etc.), equipamiento reproductor de juegos, juguetes, equipamiento de riego, equipamiento relacionado con la piscina, y demas. Otros dispositivos objetivos se corresponden a equipamiento provisto en un vefnculo de cualquier tipo. Otros dispositivos objetivos se corresponden a equipamiento provisto en un entorno empresarial de cualquier tipo, incluyendo un entorno de almacen, un entorno de fabricacion, un entorno de atencion sanitaria (por ejemplo, un hospital), un entorno relacionado con un gobierno de cualquier tipo, un entorno relacionado con la educacion de cualquier tipo, y demas. Los dispositivos objetivos 104 pueden incluir aun otros tipos de equipamiento para el uso en cualquier entorno.

Como se anoto anteriormente, en algunos casos, los dispositivos objetivos 104 pueden incluir equipamiento “ pasivo” que carece de mecanismos de control implementado en procesador local u otras facetas de logica de control local. Los mecanismos de control implementados en procesador incluyen, por ejemplo, microprocesadores, circuitos integrados espedficos a una aplicacion, y demas. Un simple interruptor de luz es un ejemplo de dispositivo pasivo. Una cerradura de puerta es otro ejemplo de un dispositivo pasivo. En otros casos, los dispositivos objetivos 104 pueden incluir equipamiento que tenga alguna logica de control local. Un sistema de seguridad es un ejemplo de

5

10

15

20

25

30

35

40

45

50

55

dispositivo que puede usar alguna logica de control local. En estos casos, el sistema de servicio 102 provee servicios que suplementan la inteligencia local de los dispositivos objetivos.

Como se describira en mayor detalle mas adelante en conexion con la Fig. 4, cada mecanismo de tubo puede incluir un mecanismo de interfaz de dispositivo para interactuar con un dispositivo objetivo, y un mecanismo de interfaz de servicio para interactuar con el sistema de servicio 102. Cada mecanismo de tubo puede tambien incluir un modulo de procesamiento, junto a un almacen de datos.

Los mecanismos de tubo 106 pueden interactuar con el sistema de servicio 102 a traves de cualquier mecanismo de comunicacion 112, como una red de area extensa (por ejemplo, Internet), una red de area local, una conexion punto a punto, y demas, o cualquier combinacion de los mismos. Mas especfficamente, cada mecanismo de tubo puede conectarse con el mecanismo de comunicacion 112 de diferentes maneras. Sin limitacion, un mecanismo de tubo puede conectarse con el mecanismo de comunicacion 112 a traves de conexion(es) inalambricas (por ejemplo, comunicaciones moviles de cualquier tipo, comunicacion WiFi, comunicacion por satelite, etc.) y/o conexion(es) con cable (por ejemplo, una conexion de banda ancha de cualquier tipo, una conexion por lfnea conmutada, etc.).

Los dispositivos de usuario 108 se pueden corresponder con diferentes tipos de unidades de computacion, incluyendo, pero no estando limitados a, ordenadores personales, puestos de trabajo informatico , ordenadores portatiles, ordenadores de tipo tableta, dispositivos asistentes digitales personales, telefonos moviles de cualquier tipo (por ejemplo, telefonos inteligentes), telefonos no moviles de cualquier tipo, dispositivos lectores de libros electronicos, dispositivos receptores de television, consolas de videojuegos, dispositivos de videojuegos portatiles, y demas. Las aplicaciones 110 pueden corresponderse con logica implementada en software que puede descargarse del sistema de servicio 102 (y/u otro sitio) y almacenarse en almacenes de datos provistos por los dispositivos de usuario 108. Aternativamente, o ademas, las aplicaciones 110 pueden corresponderse con logica implementada en hardware provisto por los dispositivos de usuario 108.

Los dispositivos de usuario 108 pueden interactuar con el sistema de servicio 102 a traves de cualquier mecanismo de comunicacion 114, como una red de area extensa (por ejemplo, Internet), una red de area local, una conexion punto a punto, y demas, o cualquier combinacion de los mismos. Mas especfficamente, los dispositivos de usuario 108 pueden conectarse al mecanismo de comunicacion 114 usando cualquiera de las tecnicas descritas anteriormente con respecto al mecanismo de comunicacion 112. (Notese que el mecanismo de comunicacion 114 puede representar la misma red que el mecanismo de comunicacion 112; estos mecanismos se muestran como distintos en la Fig. 1 meramente para facilitar la ilustracion y explicacion).

El sistema de servicio 102 se puede corresponder con cualquier funcionalidad de computacion que sea accesible a traves de los mecanismos de comunicacion (112, 114). Por ejemplo, el sistema de servicio 102 puede corresponderse con uno o mas servidores en conjuncion con uno o mas almacenes de datos. Esto es, hablando coloquialmente, el sistema de servicio 102 puede ser implementado por recursos de computacion en la nube que son accesibles a traves de Internet u otra red de area extensa. Los componentes del sistema de servicio 102 pueden ser previstos en un unico sitio, o distribuidos en multiples sitios.

El sistema de servicio 102 alberga una coleccion de modulos de servicio 116 (S1, S2, ... Sn). Cada modulo de servicio, a su vez, provee un servicio que controla la forma en que una clase de dispositivos objetivos opera. Por ejemplo, un primer servicio puede proveer logica de planificacion que enciende y apaga un tipo de mecanismo de iluminacion en distintos momentos durante el dfa. Un segundo servicio puede encender y apagar un sistema de riego en distintos momentos durante el dfa. Un tercer servicio puede controlar un tipo de horno, por ejemplo, encendiendolo y apagandolo en ciertos momentos durante el dfa, y configurando la temperature de coccion a un valor especffico mientras esta en modo “encendido”. Otros muchos ejemplos son posibles.

En general, algunos servicios pueden controlar dispositivos objetivos proporcionando decisiones binarias de tipo encendido/apagado. Ademas, o alternativamente, otros servicios pueden controlar dispositivos objetivos configurando valores dentro de un intervalo continuo de valores o dentro de un conjunto discreto de valores (como en el ejemplo del horno mencionado anteriormente). Otros servicios pueden proveer ademas otros tipos de instrucciones de control a los dispositivos objetivos 104.

Algunos servicios pueden proporcionar su control sin tener en consideracion el estado operativo de los dispositivos objetivos afectados. Este puede ser el caso, por ejemplo, de servicios que controlan interruptores de luz simples. Otros servicios pueden tener en cuenta el estado de los dispositivos objetivos. Por ejemplo, considerese un servicio que controla un termostato. Ese servicio puede recibir una lectura de un sensor de temperatura, que refleja la temperatura actual en una habitacion. En respuesta a esta lectura, el servicio puede aumentar o reducir la temperatura, o mantener la temperatura en su valor actual.

Algunos servicios pueden tambien recibir informacion de fuentes externas, entendiendo por fuentes otras diferentes a los dispositivos objetivos 104. Por ejemplo, un servicio que controla un sistema de riego puede recibir informacion de una pagina web que proporcione informacion meteorologica. El servicio puede tener en cuenta esa informacion cuando controle el sistema de riego, por ejemplo, reduciendo la cantidad de agua que se aplica a un cesped cuando se espera lluvia en un dfa en particular.

5

10

15

20

25

30

35

40

45

50

55

Aunque no se ha enumerado especfficamente en la figura, el sistema de servicio 102 tambien puede proporcionar una o mas interfaces que permitan a las aplicaciones 110 interactuar con cada modulo de servicio. Por ejemplo, cada interfaz puede implementarse como una interfaz de programacion de aplicacion (API) o similar.

Un usuario puede usar una aplicacion, que se ejecuta en el dispositivo de usuario, para configurar un servicio de una forma en particular. Por ejemplo, un usuario puede interactuar con una aplicacion de seguridad para identificar las circunstancias en las cuales el sistema de seguridad del hogar del usuario generara una alarma. El servicio asociado puede entonces interactuar con el sistema de seguridad del hogar basandose en la informacion de configuracion proporcionada por el usuario. Como se anoto anteriormente, un usuario puede encontrar que este metodo para controlar un dispositivo es mas eficiente y facil de usar, comparado con interactuar directamente con logica de control local proporcionada por el dispositivo en si.

Mas especfficamente, un primer flujo de comunicacion puede manejar el intercambio de informacion entre el mecanismo de tubo 106 y los modulos de servicio 116. Un segundo flujo de comunicacion puede manejar el intercambio de informacion entre los dispositivos de usuario 108 y los modulos de servicio 116. La Fig. 1 muestra un ejemplo del primer y segundo flujo de comunicacion en lfneas discontinuas. En el segundo flujo de comunicacion, un usuario usa una aplicacion A2 en un dispositivo de usuario U2 para configurar un servicio S1. En el primer flujo de comunicacion, el servicio S1 envfa instrucciones de control al dispositivo D2 a traves de un tubo P2. Un modulo de interfaz de dispositivo controlado (CDIM) 118, un modulo controlador de dispositivo 120, y un modulo de interfaz de dispositivo de usuario (UDIM) 122 implementan aspectos de los arriba descritos primero y segundo flujos de comunicacion.

Mas especfficamente, el CDIM 118 puede proporcionar diferentes mecanismos para implementar diferentes protocolos de transferencia de mensajes. Por ejemplo, considerese un primer caso en el cual un mecanismo de tubo interactua con el sistema de servicio 102 conectado de forma continua. El CDIM 118 puede alojar este modo pasando las instrucciones inmediatamente al mecanismo de tubo tan pronto como estas instrucciones se reciben de los modulos de servicio 116, y pasando datos inmediatamente a los modulos de servicio 116 tan pronto como esos datos se reciben del mecanismo de tubo.

Considerese un segundo caso en el que un mecanismo de tubo interactua con el sistema de servicio 102 conectado de forma intermitentemente. Por ejemplo, el mecanismo de tubo puede conectar con el sistema de servicio 102 cada n segundos o minutos, o de una forma accionada por evento (por ejemplo, cuando ocurre un evento que garantiza la interaccion entre el mecanismo de tubo y el sistema de servicio 102). El CDIM 118 puede alojar este tipo de mecanismo de tubo usando un mecanismo de puesta en cola para almacenar instrucciones que han de ser pasadas al mecanismo de tubo. Cuando llega el momento de establecer una conexion con el mecanismo de tubo, el CDIM 118 puede transferir cualesquiera instrucciones pendientes que sean proporcionadas en su cola al mecanismo de tubo.

El CDIM 118 puede usar una tecnica basada en tirar y/o en empujar para interactuar con el mecanismo de tubo. En una tecnica basada en empujar, el CDIM 118 inicia la transferencia de las instrucciones de control al mecanismo de tubo. En una tecnica basada en tirar, el CDIM 118 depende del mecanismo de tubo para tirar de las instrucciones desde el sistema de servicio 102. De manera similar, en una tecnica basada en empujar, el CDIM 118 depende del mecanismo de tubo para empujar datos al sistema de servicio 102. En una tecnica basada en tirar, el CDIM 118 tira activamente de los datos desde el mecanismo de tubo. Aun asf, son posibles otras estrategias de transferencia.

El modulo accionador del dispositivo 120 proporciona mecanismos de accionamiento que permiten a los modulos de servicio 116 controlar diferentes tipos de dispositivos objetivos 104. Por ejemplo, el modulo accionador de dispositivo 120 puede usar un primer tipo de mecanismo accionador para convertir instrucciones de control en una forma apropiada para ser usadas en el control de un mecanismo de iluminacion relativamente simple. El modulo accionador de dispositivo 120 puede usar un segundo tipo de mecanismo accionador para convertir instrucciones de control en una forma apropiada para ser usadas en el control de un interruptor de luz mas versatil y complejo, por ejemplo, un interruptor de luz que incorpora una funcion de regulacion de flujo luminoso ademas de la funcion de encendido-apagado. Desde una perspectiva de alto nivel, el modulo accionador de dispositivo 120 permite a cada servicio ser construido de una forma agnostica al dispositivo, por ejemplo, sin tener en cuenta la naturaleza particular de la funcionalidad nativa provista por los dispositivos objetivos 104.

El UDIM 122 permite a un usuario reenviar informacion a los modulos de servicio 116, y permite a los modulos de servicio 116 enviar informacion al usuario. El UDIM 122 puede alojar multiples modos de interconexion de la misma forma que el CDIM 118, por ejemplo, acomodando conectividad continua e intermitente.

Un modulo de gestion de sistema 124 controla diferentes aspectos del sistema de servicio 102. El modulo de gestion de sistema 124 puede realizar esta funcion basandose en informacion almacenada en el almacen de datos 126. Segun una funcion de gestion, el modulo de gestion de sistema 124 puede establecer una asociacion entre un dispositivo objetivo en particular, su mecanismo de tubo, y una cuenta de usuario. Por ejemplo, la cuenta de usuario puede estar asociada con un usuario que posee o esta autorizado de otro modo a controlar el dispositivo objetivo en consideracion.

5

10

15

20

25

30

35

40

45

50

55

60

El modulo de gestion de sistema 124 puede usar diferentes protocolos para establecer la asociacion anteriormente descrita. En un protocolo no limitante, un usuario que desee registrar un nuevo dispositivo objetivo puede acceder al modulo de gestion de sistema 124 a traves de un dispositivo de usuario, por ejemplo, iniciando sesion en un sitio web asociado con el modulo de gestion de sistema 124. A traves de esa conexion, el usuario puede: (1) identificarse a si mismo o a si misma; (2) identificar el tipo de dispositivo objetivo que esta siendo registrado; y/o (3) identificar el mecanismo de tubo que esta acoplado al dispositivo objetivo. Un usuario puede tambien conectar el mecanismo de tubo del dispositivo objetivo al sistema de servicio 102. A traves de esa conexion, el mecanismo de tubo puede proporcionar informacion de identificacion adicional al sistema de servicio 102 sobre el mismo y/o el dispositivo objetivo. Por ejemplo, el mecanismo de tubo puede transmitir uno o mas codigos de identificacion, un certificado digital y/u otra informadon que ayude a autenticar la identidad del mecanismo de tubo y/o el dispositivo objetivo. Basandose en esta informacion recogida, el modulo de gestion de sistema 124 puede establecer una conexion que relacione el dispositivo objetivo, el mecanismo d tubo, y la cuenta de usuario asociada con el usuario. El modulo de gestion de sistema 124 puede almacenar la informacion recogida en el almacen de datos 126. A partir de ahf se le permite al usuario controlar su dispositivo objetivo a traves del sistema de servicio 102.

Por ejemplo, considerese el caso particular en el que un mecanismo de tubo es una parte permanente de un nuevo dispositivo objetivo. Un fabricante de dispositivos puede transmitir un codigo asociado con el nuevo dispositivo objetivo en documentos que acompanen la venta del nuevo dispositivo objetivo, o fijando el codigo al nuevo dispositivo objetivo en si mismo de cualquier manera. En este caso, puede ser suficiente para el usuario con proporcionar un unico codigo asociado con el dispositivo objetivo, pues este codigo tambien identifica implfcitamente el mecanismo de tubo que esta asociado con el dispositivo objetivo. En otro caso, el mecanismo de tubo puede ser un componente independiente que puede ser conectado a cualquier dispositivo objetivo. En este caso, el usuario puede proporcionar dos codigos durante el proceso de registro, un primer codigo asociado con el mecanismo de tubo y un segundo codigo asociado con el dispositivo objetivo.

El modulo de gestion de sistema 124 puede tambien configurar una conexion segura con el mecanismo de tubo usando cualquier mecanismo de seguridad, como, pero no limitado a, el protocolo de Seguridad de la Capa de Transporte (TLS) (o el protocolo predecesor, Capa de Puertos Seguros (SSL)). En este protocolo, el modulo de gestion de sistema 124 y el mecanismo de tubo intercambian informacion de seguridad para establecer una conexion segura. Los datos y las instrucciones pueden a partir de ahf ser transmitidos entre el sistema de servicio 102 y el mecanismo de tubo de una forma segura.

Finalmente, el sistema de servicio 102 puede proporcionar un mercado de aplicaciones 128. O un sistema separado (no mostrado) puede proveer el mercado de aplicaciones 128. El mercado de aplicaciones 128 ofrece una coleccion de aplicaciones que proporcionan diferentes funciones de control asociadas con diferentes tipos de dispositivos objetivos. Por ejemplo, un usuario que posee una cafetera puede buscar en el mercado de aplicaciones 129 una aplicacion que este disenada para controlar este tipo de dispositivo. El usuario puede entonces descargar esta aplicacion y usarla para controlar su cafetera. Algunas cafeteras pueden ser mas complejas que otras. Por tanto, el usuario puede buscar una aplicacion que se adapte acertadamente al tipo de cafetera que el o ella posea.

Las Figs. 3-6 muestran tres formas diferentes en que se puede acoplar un mecanismo de tubo a un dispositivo. Empezando con la Fig. 3, un dispositivo objetivo 302 incluye cualquier funcionalidad de dispositivo nativa 304 y un mecanismo de interfaz de tubo 306. La funcionalidad de dispositivo nativa 304 representa cualquier funcion realizada por el dispositivo objetivo 302. El mecanismo de interfaz de tubo 306 proporciona cualquier mecanismo por el cual la funcionalidad de dispositivo nativa 304 pueda interactuar con un mecanismo de tubo 308. Por ejemplo, en un caso no limitante, el mecanismo de interfaz de tubo 306 puede corresponderse con un rele que este conectado a varios interruptores proporcionados por la funcionalidad de dispositivo nativa 304. El rele, a su vez, esta controlado por el mecanismo de tubo 308.

En algunos casos, el dispositivo objetivo 302 puede ya proporconar el mecanismo de interfaz de tubo 306 como parte de su diseno pre-existente (“legado”). En otros casos, un fabricante de dispositivos puede modificar su diseno legado para proporcionar el mecanismo de interfaz de tubo 306, de manera que el dispositivo objetivo 302 pueda interactuar satisfactoriamente con el mecanismo de tubo 308.

En la Fig. 3, el mecanismo de tubo 308 y el dispositivo objetivo 302 son componentes separados. El mecanismo de tubo 308 puede conectarse de manera separable al dispositivo objetivo 302 en cualquier etapa, por ejemplo, durante el ensamblado del dispositivo objetivo 302 en el lugar de fabricacon, o en el lugar del usuario final. El mecanismo de tubo 308 puede acoplarse al mecanismo de interfaz de tubo 306 usando cualquier estrategia de conexion, generalmente senalada en la Fig. 3 como una conexion 310. Por ejemplo, la conexion 310 puede representar un enchufe tipo clavija que recibe un mecanismo de tubo tipo chip. O la conexion 310 puede representar una conexion tipo cableada o una conexion inalambrica, y demas.

La Fig. 4 muestra un dispositivo objetivo 402 que tiene funcionalidad nativa 404, un mecanismo de interfaz de tubo 406, y un mecanismo de tubo 408. Estos modulos pueden realizar las mismas funciones que los componentes con el mismo nombre de la Fig. 3. Pero en el caso de la Fig. 4, el mecanismo de tubo 408 se corresponde con un componente incorporado del dispositivo objetivo 402, en vez de un componente facilmente separable que se considere separado del dispositivo objetivo 402. Por ejemplo, el mecanismo de tubo 408 puede representar un chip

5

10

15

20

25

30

35

40

45

50

55

60

que este conectado directamente a un substrato provisto en el dispositivo objetivo 402 (como, en dispositivos objetivos mas complejos, una placa de circuito impreso, etc.).

La Fig. 5 muestra un interruptor controlado por servicio 502 que incorpora un mecanismo de tubo 504, un interruptor de corriente 506, y un mecanismo de interfaz de corriente 508. El interruptor de corriente 506 esta acoplado a una fuente de corriente 510, como un enchufe de pared de corriente alterna. El interruptor de corriente 506 recibe instrucciones de control del sistema de servicio 102. Esas instrucciones causan que el interruptor de corriente 506 conmute la corriente entre encendida y apagada. Cuando esta en un estado “encendido”, el interruptor de corriente 506 dirige corriente desde la fuente de corriente 510 al mecanismo de interfaz de corriente 508; cuando esta en un estado “apagado”, el interruptor de corriente 506 corta la corriente al mecanismo de interfaz de corriente 508.

Un dispositivo objetivo separado 512 puede incluir cualquier funcionalidad de dispositivo nativa 514 y un mecanismo de interfaz de corriente 516. El mecanismo de interfaz de corriente 516 del dispositivo objetivo 512 puede ser acoplado al mecanismo de interfaz de corriente 508 del interruptor controlado por servicio 502. En este estado de acoplamiento, el interruptor de corriente 506 puede controlar eficazmente la aplicacion de corriente al dispositivo objetivo 512, basandose en las instrucciones de control recibidas por el mecanismo de tubo 504. En una implementacion particular, el interruptor controlado por servicio 502 se compone de una pequena unidad que tiene una clavija o enchufe macho que puede insertarse en un enchufe de corriente alterna. El interruptor controlado por servicio 502 proporciona una clavija hembra (asociada con el mecanismo de interfaz de corriente 508) para emparejarse con una clavija (asociado con el mecanismo de interfaz de corriente 516) del dispositivo objetivo 512 (o viceversa).

Expresado mas ampliamente, la Fig. 5 es un ejemplo de una clase de dispositivos de control que puede controlar un dispositivo objetivo separado de cualquier manera. En otro caso, por ejemplo, el dispositivo de control puede proporcionar una salida de multiples valores (o continua o discreta) basandose en las instrucciones de control recibidas por el mecanismo de tubo. Este tipo de dispositivo de control puede controlar cualquier tipo de dispositivo objetivo que acepte una senal de entrada multiples valores, tal como un termostato.

La Fig. 6 muestra una implementacion de un mecanismo de tubo 602. El mecanismo de tubo 602 incluye un mecanismo de interfaz de dispositivo 604 para interactuar con un dispositivo objetivo 606, y un mecanismo de interfaz de servicio 608 para interactuar con el sistema de servicio 102. El mecanismo de interfaz de dispositivo 604 puede ser implementado de cualquier manera, como con pines de interfaz provistos por un chip, un miembro de conexion macho o hembra, un rele, etc. El mecanismo de interfaz de servicio 608 puede igualmente implementarse de diferentes maneras dependiendo de la forma en que el mecanismo de tubo 602 este conectado al mecanismo de comunicacion 112. Por ejemplo, el mecanismo de interfaz de servicio 608 puede proporcionar logica basada en celdas para proporcionar comunicacion movil, logica WiFi para proporcionar comunicacion WiFi, y demas. O el mecanismo de interfaz de servicio 608 puede incluir logica para establecer una conexion directa de cualquier tipo.

Mas especfficamente, en una primera realizacion, pueden ser provistas diferentes clases de mecanismos de tubo que incluyan diferentes tipos de mecanismos de interfaz de servicio. Los diferentes tipos de mecanismos de interfaz de servicio pueden manejar diferentes tipos de comunicaciones (por ejemplo, movil, WiFi, etc.) y/o diferentes estrategias de transferencia (por ejemplo, continua, intermitente, etc.). Un fabricante de dispositivos o usuario final puede elegir la clase apropiada de mecanismo de tubo para usar con un tipo particular de dispositivo objetivo que ha de ser controlado. En una segunda implementacion, se puede proporcionar un unico tipo de mecanismo de tubo que ofrezca un mecanismo de interfaz de servicio multi-modo 608, donde cada modo ofrece un tipo diferente de comunicacion y/o una estrategia de transferencia diferente. Un fabricante de dispositivos o usuario final puede entonces seleccionar el modo apropiado para usar con un dispositivo objetivo en particular que sera controlado. Por ejemplo, un fabricante de dispositivos puede configurar el mecanismo de tubo para proporcionar comunicacion WiFi intermitente con el sistema de servicio 102.

El mecanismo de tubo 602 puede tambien incluir un modulo de proceso 610 que controle su operacion. El modulo de proceso 610 se puede corresponder con uno o mas microprocesadores y/o circuiterfa logica directamente conectada. Por ejemplo, el modulo de procesamiento 610 puede incluir logica de transferencia que controle la transferencia de instrucciones desde el mecanismo de interfaz de servicio 608 al mecanismo de interfaz de dispositivo 604, y el flujo de datos desde el mecanismo de interfaz de dispositivo 604 al mecanismo de interfaz de servicio 608. El modulo de procesamiento 610 puede tambien incluir logica de seguridad para establecer una conexion segura con el sistema de servicio 102. Aparte de estos tipos de funciones relacionadas con la comunicacion, en una implementacion, el modulo de procesamiento 610 permanece agnostico al significado de la informacion que fluye a traves del mecanismo de tubo 602. Esto es, en este caso, el modulo de procesamiento 610 no esta adaptado para un dispositivo objetivo en particular o cualquier funcion de control en particular.

El modulo de procesamiento 610 puede realizar sus tareas basandose en la informacion almacenada en el almacen de datos 612. Por ejemplo, el almacen de datos 612 puede almacenar una direccion 614 asociada con el sistema de servicio 102, como una direccion URL. Esta informacion permite al mecanismo de tubo 602 conectarse al sistema de servicio 102. Aunque no se muestra, el almacen de datos 612 puede tambien almacenar cualquier tipo de informacion de identificacion, como uno o mas codigos de identificacion, informacion relacionada con la seguridad, certificados, etc. La informacion de identificacion puede identificar al mecanismo de tubo 602. Y si el mecanismo de

5

10

15

20

25

30

35

40

45

50

55

tubo 602 es un componente fijo de un dispositivo objetivo, la informacion de identificacion tambien identifica implfcitamente al dispositivo objetivo. El mecanismo de tubo 602 puede adjuntar parte de su informacion de identificacion como una cabecera a los datos que dirige al sistema de servicio 102. Esto permitira al sistema de servicio 102 identificar el origen de los datos. El modulo de procesamiento 610 puede tambien recibir cualquier identificacion y/o informacion relacionada con la seguridad de cualquier origen, como el modulo de gestion de sistema 124, y entonces almacenar esta informacion en su almacen de datos 612.

El mecanismo de tubo 602 puede incorporar opcionalmente otras funciones y entradas asociadas. Por ejemplo, el mecanismo de tubo 602 puede incluir un boton “conectar” o similar. Un usuario final puede activar este boton para ordenar al mecanismo de tubo 602 que se conecte al sistema de servicio 102 a traves del mecanismo de comunicacion 112.

La Fig. 7 describe de manera ilustrativa funcionalidades de computacion 700 que pueden ser usadas para implementar cualquier aspecto de cualquier dispositivo de usuario, o cualquier aspecto de cualquier servidor provisto por el sistema de servicio 102.

La funcionalidad de computacion 700 puede incluir memoria volatil y no-volatil, como RAM 702 y ROM 704, asf como uno o mas dispositivos de procesamiento 706 (por ejemplo, una o mas CPU, y/o uno o mas GPU, etc.). La funcionalidad de computacion 700 tambien incluye opcionalmente varios dispositivos de medios 708, como modulo de disco duro, modulo de disco optico, y demas. La funcionalidad de computacion 700 puede realizar varias operaciones identificadas anteriormente cuando el(los) dispositivo(s) de procesamiento 706 ejecutan instrucciones que se mantienen en memoria (por ejemplo, RAM 702, ROM 704, o en otro sitio).

Mas generalmente, las instrucciones y otra informacion pueden ser almacenadas en cualquier medio lefble por un ordenador 710, incluyendo, pero no estando limitado, a dispositivos de almacenamiento de memoria estatica, dispositivos de almacenamiento magnetico, dispositivos de almacenamiento optico, etc. El termino medio lefble por un ordenador tambien incluye multiples dispositivos de almacenamiento. En muchos casos, los medios lefbles por un ordenador 710 representan algun tipo de entidad ffsica y tangible. El termino medio lefble por un ordenador tambien incluye senales propagadas, por ejemplo, transmitidas o recibidas a traves de un conducto ffsico y/o aire u otro medio inalambrico, etc. Sin embargo, los terminos especfficos “medio de almacenamiento lefble por un ordenador” y “dispositivo de medios lefble por un ordenador” excluyen expresamente senales propagadas per se, mientras que incluyen todas las otras formas de medios lefbles por un ordenador.

La funcionalidad de computacion 700 tambien incluye un modulo de entrada/salida 712 para recibir varias entradas (a traves de dispositivos de entrada 714), y para proporcionar varias salidas (a traves de dispositivos de salida). los dispositivos de entrada ilustrativos incluyen un dispositivo de teclado, un dispositivo de entrada de raton, un dispositivo de entrada de pantalla tactil, un dispositivo de entrada de gestos, un mecanismo de reconocimiento de voz, un mecanismo de entrada de proyeccion de pared o de mesa, etc. Un mecanismo de salida en particular puede incluir un dispositivo de presentacion 716 y una interfaz de usuario grafico (GUI) 718 asociada. La funcionalidad de computacion 700 tambien puede incluir una o mas interfaces de red 720 para intercambiar datos con otros dispositivos a traves de uno o mas conductos de comunicacion 722. Uno o mas buses de comunicacion 724 acoplan comunicativamente los componentes descritos anteriormente.

El(los) conducto(s) de comunicacion 722 pueden ser implementados de cualquier forma, por ejemplo, con una red de area local, una red de area extensa (por ejemplo, Internet), etc., o cualquier combinacion de ellas. El(los) conducto(s) de comunicacion 722 puede(n) incluir cualquier combinacion de conexiones directas, conexiones inalambricas, enrutadores, funcionalidad de puerta de enlace, servidores de nombres, etc., controlados por cualquier protocolo o combinacion de protocolos.

Alternativamente, o ademas, cualquiera de las funciones proporcionadas por la funcionalidad de computacion 700 puede ser realizada, al menos en parte, por uno o mas componentes de logica hardware. Por ejemplo, sin limitacion, la funcionalidad de computacion puede ser implementada usando uno o mas de: Matrices de Puertas Programables en Campo (FPGA ); Circuitos Integrados para Aplicaciones Especfficas (ASIC ); Productos estandar para una aplicacion especffica (ASSP ); sistemas Sistema-en-chip (SOC ); Circuitos Complejos de Logica Programable (CPLD), etc.

B. Procesos ilustrativos

Las Figs. 8-12 muestran procedimientos que explican una forma de operacion del entorno 100 de la Fig. 1. Como se han descrito ya los principios subyacentes a la operacion del entorno 100 en la Seccion A ciertas operaciones seran abordadas en modo resumen en esta seccion.

Empezando con la Fig. 8, esta figura muestra un procedimiento ilustrativo 800 para proporcionar el entorno 100. En el bloque 802, esta previsto el sistema de servicio 102. Por ejemplo, el sistema de servicio 102 puede ser implementado como un recurso de computacion en la nube, o de alguna otra forma. En el bloque 804, una pluralidad de mecanismos de tubo 106 agnosticos al servicio son proporcionados para usar en asociacion con los respectivos dispositivos objetivos 104. La Fig. 2 describe dos estrategias para lograr esta tarea. En el bloque 806, el sistema de

5

10

15

20

25

30

35

40

45

50

55

servicio 102 se usa para controlar los dispositivos objetivos 104 a traves del mecanismo de tubo 106. Las operaciones de la Fig. 8 pueden ser realizadas por una o mas entidades. Por ejemplo, en un caso representativo, una primera entidad puede realizar los bloques 802 y 806, mientras que una segunda entidad puede realizar el bloque 804.

La Fig. 9 muestra un procedimiento ilustrativo 900 para asociar un dispositivo y un mecanismo de tubo con un usuario. En el bloque 902, el sistema de servicio 102 puede recibir una peticion de registro que identifica uno o mas de: (1) una entidad (por ejemplo, un usuario) que posee, o esta autorizado de otro modo a controlar, un dispositivo objetivo; (2) el dispositivo objetivo; y/o (3) el mecanismo de tubo asociado con el dispositivo objetivo. Por ejemplo, un usuario puede realizar esta tarea usando un dispositivo de usuario para iniciar sesion en un sitio web asociado con el modulo de gestion de sistema 124. El usuario puede identificarse a si mismo (por ejemplo, proporcionando una ID de usuario y una contrasena), y entonces proporcionar un codigo asociado con el mecanismo de tubo y/o un codigo asociado con el dispositivo objetivo. En el bloque 904, el sistema de servicio 102 puede recibir una comunicacion del mecanismo de tubo en consideracion. La comunicacion puede proporcionar informacion de identificacion adicional sobre el mecanismo de tubo y/o el dispositivo objetivo. En el bloque 906, el sistema de servicio 102 puede usar la informacion recogida en los bloques 902 y 904 para establecer un nexo entre el usuario, un dispositivo objetivo, y el mecanismo de tubo que esta acoplado al dispositivo objetivo. La Fig. 9 muestra que el bloque 902 precede al bloque 904, pero el bloque 904 puede alternativamente seguir al bloque 902.

La Fig. 10 muestra un procedimiento 1000 para descargar una aplicacion desde el sistema de servicio 102 a un dispositivo de usuario. En el bloque 1002, el sistema de servicio 102 recibe una peticion desde un usuario para una aplicacion. En el bloque 1004, el sistema de servicio 102 proporciona la aplicacion solicitada.

La Fig. 11 muestra un procedimiento 1100 para cargar datos desde el mecanismo de tubo al sistema de servicio 102. En el bloque 1102, el sistema de servicio 102 recibe una comunicacion del mecanismo de tubo asociado con un dispositivo. Esta comunicacion se puede recibir a traves de cualquier protocolo de transferencia, por ejemplo usando un protocolo de conexion continuo o un protocolo de puesta en cola intermitente. En el bloque 1104, el sistema de servicio 102 procesa la comunicacion usando un modulo de servicio apropiado. En el bloque 1106, el sistema de servicio 102 puede realizar cualquier accion(es) de post-procesado, como notificar a un usuario sobre los datos que se han recibido, controlar el dispositivo objetivo basandose en los datos, y demas. Para realizar una accion de control, el sistema de servicio 102 puede usar cualquier protocolo de conexon para reenviar instrucciones al mecanismo de tubo, como un protocolo de conexon continuo o un protocolo de conexion intermitente.

La Fig. 12 muestra un procedimiento 1200 que proporciona instrucciones de configuracion desde una entidad al sistema de servicio 102. En el bloque 1202, el sistema de servicio 102 recibe instrucciones de configuracion desde una entidad, como un usuario. El usuario puede introducir esas instrucciones interactuando con una aplicacion que se ejecuta en un dispositivo de usuario. En el bloque 1204, el sistema de servicio 102 procesa las instrucciones usando un modulo de servicio apropiado. En el bloque 1206, el sistema de servicio 102 puede proporcionar cualquier accion(es) de post-procesado, como controlar un dispositivo objetivo asociado con el usuario, etc. Como se declaro anteriormente, el sistema de servicio 102 puede usar cualquier protocolo de conexion para reenviar instrucciones al mecanismo de tubo asociado con el dispositivo objetivo, como un protocolo de conexion continuo o un protocolo de conexon intermitente.

Por ultimo, la funcionalidad aquf descrita puede emplear varios mecanismos para asegurar la privacidad de los datos de usuario mantenidos por la funcionalidad, si hay alguno. Por ejemplo, la funcionalidad puede permitir al usuario apuntarse expresamente (y entonces expresamente salirse de) en la provision de la funcionalidad. La funcionalidad puede tambien proporcionar mecanismos de seguridad adecuados para asegurar la privacidad de los datos de usuario (como mecanismos de desinfeccion de datos, mecanismos de criptograffa, mecanismos de proteccion de contrasenas, etc.).

Ademas, la descripcion puede haber descrito varios conceptos en el contexto de retos o problemas ilustrativos. Esta forma de explicacion no constituye una admision de que otros han apreciado y/o articulado los retos o problemas en la forma especificada aquf. Ademas, el tema de discusion reivindicado no esta limitado a implementaciones que resuelvan cualquiera o todos los retos/problemas anotados.

Aunque el tema de discusion se ha descrito en un lenguaje especffico a caracterfsticas estructurales y/o actos metodologicos, se debe entender que el tema de discusion definido en las reivindicaciones anexas no esta necesariamente limitado a las caracterfsticas especfficas o actos descritos anteriormente. Mas bien, las caracterfsticas y actos especfficos descritos anteriormente son descritos como formas ejemplares de implementar las reivindicaciones.

Claims

5

10

15

20

25

30

35

40

45

1. Un entorno para controlar una pluralidad de dispositivos objetivos, que se compone de:

una pluralidad de mecanismos de tubo asociados con los respectivos dispositivos objetivos; un sistema de servicio, que incluye:

una pluralidad de modulos de servicio configurados para proporcionar una pluralidad de servicios respectivos, los servicios, a su vez, se usan en el control de una pluralidad de dispositivos objetivos;

un modulo de interfaz de dispositivo controlado configurado para permitir que los dispositivos objetivos puedan interactuar con los servicios a traves de la pluralidad de mecanismos de tubo que estan asociados con los respectivos dispositivos objetivos, incorporando cada mecanismo de tubo una funcionalidad agnostica al dispositivo que posibilita que el mecanismo de tubo pueda interactuar con multiples tipos de dispositivos objetivos y

un modulo de interfaz de dispositivo de usuario configurado para permitir a una pluralidad de dispositivos de usuario interactuar con los servicios, a traves de aplicaciones, para configurar los servicios;

el sistema de servicio que es accesible al mecanismo de tubo a traves de una red de area extensa.
2. El entorno de la reivindicadon 1, donde los dispositivos objetivos son dispositivos pasivos sin mecanismos de control implementados en local.
3. El entorno de la reivindicacion 1, ademas incluye un modulo de gestion de sistema configurado para establecer una pluralidad de asociaciones, cada asociacion conecta con un dispositivo objetivo particular, un mecanismo de tubo particular que se acopla con el dispositivo objetivo, y una entidad particular que esta autorizada para controlar el dispositivo objetivo.
4. El entorno de la reivindicacion 1, donde cada mecanismo de tubo se compone de:

un mecanismo de interfaz de dispositivo configurado para:

recibir datos de un dispositivo objetivo asocado con el mecanismo de tubo;

proporcionar instrucciones de control al dispositivo objetivo, que causan que el dispositivo objetivo reaiice una fundon;

un mecanismo de interfaz de servicio configurado para comunicarse con el sistema de servicio, teniendo el sistema de servicio al menos un servicio que esta configurado para:

recibir los datos desde el dispositivo objetivo; y proporcionar instrucciones de control al dispositivo objetivo;

un modulo de procesamiento configurado para controlar la operacion del mecanismo de tubo; y

un almacen de datos para almacenar datos a usar en la operacion de control del mecanismo de tubo,

el mecanismo de tubo se configura de una forma agnostica al dispositivo, habilitando al mecanismo de tubo para interactuar con multiples tipos de dispositivos objetivos.
5. El entorno de la reivindicacion 4, donde el mecanismo de tubo y el dispositivo objetivo son componentes separados respectivamente acoplados juntos de una forma separable .
6. El entorno de la reivindicacion 4, donde el mecanismo de tubo representa un componente incorporado en el dispositivo objetivo.
7. El entorno de la reivindicacion 4, donde el dispositivo objetivo se corresponde con un dispositivo de control que incluye el mecanismo de tubo, donde el dispositivo de control controla otro dispositivo objetivo basado en las instrucciones de control proporcionadas por el mecanismo de tubo.
8. Un metodo para interactuar con una pluralidad de dispositivos objetivos, que comprende:

la provision de un sistema de servicio implementada por uno o mas servidores, proporcionado el sistema de servicio una pluralidad de modulos de servicio, proporcionando cada modulo de servicio un servicio;

la recepcion de instrucciones de configuracion desde usuarios a traves de dispositivos de usuario que ejecutan aplicaciones, para configurar los modulos de servicio; y

el uso del sistema de servicio para controlar una pluralidad de dispositivos objetivos a traves de una pluralidad de mecanismos de tubo que estan acoplados con los dispositivos objetivos, siendo el sistema de 5 servicio accesible al mecanismo de tubo a traves de una red de area extensa (112).

incorporando cada mecanismo de tubo una funcionalidad agnostica al dispositivo que habilita al mecanismo de tubo para interactuar con multiples tipos de dispositivos objetivos.
9. El metodo de la reivindicacion 8, donde los mecanismos de tubo son proporcionados a uno o mas fabricantes de dispositivos para incorporarlos en dispositivos objetivos.

10 10. El metodo de la reivindicacion 8, donde los mecanismos de tubo son proporcionados a los usuarios finales para

conectarlos a los dispositivos objetivos.