MXPA00010917A - Metodo y sistema para el comando y control de dispositivo a dispositivo dentro de una red - Google Patents
Metodo y sistema para el comando y control de dispositivo a dispositivo dentro de una redInfo
- Publication number
- MXPA00010917A MXPA00010917A MXPA/A/2000/010917A MXPA00010917A MXPA00010917A MX PA00010917 A MXPA00010917 A MX PA00010917A MX PA00010917 A MXPA00010917 A MX PA00010917A MX PA00010917 A MXPA00010917 A MX PA00010917A
- Authority
- MX
- Mexico
- Prior art keywords
- data
- devices
- control
- interface
- network
- Prior art date
Links
- 230000001276 controlling effect Effects 0.000 claims abstract description 36
- 238000004891 communication Methods 0.000 claims description 31
- 238000000034 method Methods 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 17
- 230000000875 corresponding Effects 0.000 claims description 14
- 238000010586 diagram Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 9
- 230000003993 interaction Effects 0.000 description 7
- 230000003111 delayed Effects 0.000 description 5
- 238000007906 compression Methods 0.000 description 4
- 239000011800 void material Substances 0.000 description 4
- 235000002723 Dioscorea alata Nutrition 0.000 description 3
- 235000007056 Dioscorea composita Nutrition 0.000 description 3
- 235000009723 Dioscorea convolvulacea Nutrition 0.000 description 3
- 235000005362 Dioscorea floribunda Nutrition 0.000 description 3
- 235000004868 Dioscorea macrostachya Nutrition 0.000 description 3
- 235000005361 Dioscorea nummularia Nutrition 0.000 description 3
- 235000005360 Dioscorea spiculiflora Nutrition 0.000 description 3
- 240000005760 Dioscorea villosa Species 0.000 description 3
- 235000006350 apichu Nutrition 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 235000004879 dioscorea Nutrition 0.000 description 3
- 230000004301 light adaptation Effects 0.000 description 3
- 230000002093 peripheral Effects 0.000 description 3
- KRTSDMXIXPKRQR-AATRIKPKSA-N Monocrotophos Chemical compound CNC(=O)\C=C(/C)OP(=O)(OC)OC KRTSDMXIXPKRQR-AATRIKPKSA-N 0.000 description 2
- 101700005059 bed-3 Proteins 0.000 description 2
- 230000000295 complement Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 238000002372 labelling Methods 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006011 modification reaction Methods 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 230000002730 additional Effects 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000007374 clinical diagnostic method Methods 0.000 description 1
- 235000013305 food Nutrition 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000000717 retained Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 230000003068 static Effects 0.000 description 1
- 238000009423 ventilation Methods 0.000 description 1
- 238000005406 washing Methods 0.000 description 1
- 230000003245 working Effects 0.000 description 1
Abstract
Un método y un sistema para comandar y controlar entre una pluralidad de dispositivos a través de una red por medio de:conectar un primer dispositivo a la red;conectar un segundo dispositivo a la red, en donde el segundo dispositivo almacene datos de descripción de la interfaz de aplicación en un formato estructurado para comandar y controlar el segundo dispositivo por medio de otros dispositivos de la red;Proporcionar los datos de descripción de la interfaz de aplicación al primer dispositivo sobre la red;y enviar datos de comando y control desde el primer dispositivo hacia el segundo dispositivo sobre la red, utilizando los datos de descripción de la interfaz de aplicación para controlar la operación del segundo dispositivo.
Description
MÉTODO ? SISTEMA PARA EL COMANDO Y CONTROL DE DISPOSITIVO A DISPOSITIVO DENTRO DE UNA RED
Campo Técnico
La presente invención se refiere al campo de los sistemas de red y más particularmente, a una red de casa que tiene múltiples dispositivos conectados a ésta.
Antecedentes En el Arte
Una red incluye generalmente un enlace de comunicación y varios dispositivos con una capacidad de comunicación, conectados al enlace de comunicación. Los dispositivos incluyen a computadoras, dispositivos periféricos, enrutadores, dispositivos de almacenamiento y aparatos con procesadores e interfaces de comunicación. Un ejemplo de una red es una red de casa para uso doméstico, en la cual varios dispositivos están interconectados. Una casa usual puede contener varios dispositivos, incluyendo computadoras personales y dispositivos del hogar que son encontrados tipicamente en una casa. El término "dispositivo" como tal, incluye tipicamente a dispositivos lógicos y otras unidades que
Ref. 12 589
tienen la funcionalidad y la capacidad de intercambiar datos y pueden no solamente incluir todos los dispositivos del hogar, sino que también a computadoras universales. Dispositivos domésticos incluyen a dispositivos electrónicos tales como sistemas de seguridad, equipo de cine en casa, televisores, videograbadoras, equipos estéreo y servicios directos de radiodifusión por satélite ó (DBSS) , también conocidos como servicios de satélite digital (DSS), sistemas de regado, sistemas de iluminación, hornos de microondas, lavaplatos, hornos/estufas, lavadoras/secadoras y un sistema de procesamiento dentro de un automóvil. En general, los dispositivos domésticos son utilizados para efectuar tareas que mejoran el estilo de vida del propietario de una casa y el nivel de vida. Por ejemplo, un lavaplatos efectúa la tarea de lavar platos sucios y libera al propietario de la casa de tener que lavar los platos a mano. Una videograbadora puede grabar un programa de televisión para permitir que el propietario de una casa, vea un programa particular a una hora posterior. Los sistemas de seguridad protegen los valores del propietario de una casa y pueden reducir el temor del propietario de infiltraciones no deseadas a su domicilio.
Dispositivos domésticos, tales como un equipo de cine en casa, son controlados frecuentemente utilizando una sola unidad de control común, llámese un dispositivo de control remoto. Esta sola unidad de control común permite que el propietario controle y comande varios dispositivos domésticos diferentes, utilizando una sola interfaz. Consecuentemente, los fabricantes han desarrollado unidades de control para controlar y comandar dispositivos domésticos desde una sola interfaz. Una desventaja asociada con la utilización de una unidad de control remoto para comandar y controlar dispositivos domésticos, es que ésta proporciona una lógica estática y de comandos para controlar y comandar a cada dispositivo doméstico. Por lo tanto, una unidad de control remoto particular puede solamente controlar y comandar aquellos dispositivos domésticos para los cuales, éste incluya la lógica de comando y de control necesaria . En sistemas de red convencionales, un uso de proporciona comandos utilizando una unidad de control remoto ó un panel de control de dispositivo. Una vez que el usuario termina, no existe una unidad controladora ó dispositivo en la red que pueda proporcionar comandos para una operación automática. Por ejemplo, una red de casa puede incluir una unidad de sincronización y una
videograbadora sin un sintonizador dentro de ésta. Después de que el usuario programa la videograbadora para una grabación retardada en tiempo, es necesario un mecanismo para que la videograbadora localice automáticamente después al sintonizador sobre la red y controle al sintonizador para proporcionar la información de video para que asi, grabe la videograbadora . Como tal, después de que un usuario controla y comanda inicialmente a un primer grupo de dispositivos, los sistemas convencionales no proporcionan un mecanismo para que el primer grupo de dispositivos se comunique automáticamente con un segundo grupo de dispositivos dentro de la red, cuando sea necesario, con el objetivo de realizar tareas sin que el usuario tenga que comandar y controlar directamente al segundo grupo de dispositivos. Consiguientemente, existe la necesidad de un método y un sistema que proporcione el control y comando dinámico y central de dispositivos dentro de una red de casa. También existe la necesidad de un método y sistema tales, que proporcionen una capacidad para que un usuario controle y comande inicialmente un primer conjunto de dispositivos para comunicarse entre si y para que el primer conjunto de dispositivos se comunique automáticamente con un segundo conjunto de dispositivos
¿*& -
dentro de una red, como sea necesario, con el objetivo de realizar tareas sin el control y comando directo del usuario sobre el segundo conjunto de dispositivos. También existe la necesidad de un método y un sistema tales, que proporcionen la capacidad para que varios dispositivos de red comanden y controlen automáticamente a otros dispositivos de red diferentes.
Breve Compendio de la Invención
La presente invención satisface estas necesidades. En una modalidad, la presente invención proporciona un método y un sistema para comandar y controlar una pluralidad de dispositivos a través de una red por medio de: conectar un primer dispositivo a la red; conectar un segundo dispositivo a la red, en donde el segundo dispositivo almacene los datos de descripción de la interfaz de aplicación en un formato estructurado para comandar y controlar al segundo dispositivo por medio de otros dispositivos de red; proporcionar los datos de descripción de la interfaz de aplicación al primer dispositivo desde el primer dispositivo, hacia el segundo dispositivo sobre la red, utilizando los datos de descripción de la interfaz de aplicación para controlar la operación del segundo dispositivo.
Por lo menos, una porción de los datos de descripción de la interfaz de aplicación puede ser transferida para ser utilizada por el primer dispositivo, ó el primer dispositivo puede hacer una petición a los datos de descripción de la interfaz de aplicación dentro de otros dispositivos a través de la red. Adicionalmente, los datos de descripción de la interfaz de aplicación pueden ser almacenados dentro de una base de datos para ser accesados por el primer dispositivo. Los datos de descripción de la interfaz de aplicación pueden incluir la información de la llamada de procedimiento remoto para el primer dispositivo doméstico, para que controle la operación del segundo dispositivo doméstico. En añadidura, los datos de descripción de la interfaz de aplicación pueden incluir capacidades de datos para identificar las capacidades del segundo dispositivo. El formato estructurado para los datos de descripción de interfaz de la aplicación puede incluir al formato XML. Preferentemente, una pluralidad de dispositivos está conectada a la red y cada dispositivo contiene datos de descripción de la interfaz de aplicación en un formato estructurado, para comandar y controlar al dispositivo por medio de uno ó más dispositivos diferentes conectados a la red. En este caso, los datos
de descripción de la interfaz de aplicación de dos ó más de la pluralidad de los dispositivos pueden ser provistos al primer dispositivo a través de la red, de tal manera que el primer dispositivo puede enviar datos de comandos y de control desde el primer dispositivo, hasta dos ó más dispositivos que estén sobre la red, utilizando los datos de descripción de la interfaz de aplicación correspondientes a cada uno de los dos ó más dispositivos, para controlar su operación. En otro aspecto, la presente invención proporciona un métod'o y sistema para efectuar un servicio a través de una red de casa por medio de: conectar un dispositivo cliente a la red de casa, en donde el dispositivo cliente es capaz de desplegar datos de interfaz del usuario; conectar un primer dispositivo doméstico a la red, en donde el primer dispositivo doméstico contiene datos de interfaz del usuario en un formato seleccionado que define una interfaz del usuario, para que el usuario comande y controle al menos al primer dispositivo doméstico; conectar un segundo dispositivo doméstico a la red, en donde el segundo dispositivo doméstico contiene datos de descripción de la interfaz de aplicación en un formato estructurado, para comandar y controlar dispositivos en el segundo dispositivo doméstico; recibir los datos de interfaz del
fe-
usuario del primer dispositivo doméstico en el dispositivo cliente; desplegar la interfaz del usuario definida por los datos de interfaz del usuario del primer dispositivo doméstico sobre el dispositivo cliente; aceptar una entrada de usuario a partir de un usuario, en respuesta a la interacción del usuario con la interfaz del usuario desplegada sobre el dispositivo cliente; y enviar datos de comando y control desde el dispositivo cliente, hacia el primer dispositivo doméstico, en base a la entrada del usuario, para provocar que los primero y segundo dispositivos domésticos se comuniquen entre si, utilizando los datos de descripción de la mterfaz de aplicación, para efectuar el servicio. Como tal, el usuario puede seleccionar a los primer y segundo dispositivos domésticos desde la interfaz del usuario desplegada sobre el dispositivo cliente. Adicionalmente, el primer dispositivo doméstico puede controlar al segundo dispositivo doméstico por medio de enviar información de control y comandos al segundo dispositivo doméstico, utilizando los datos de descripción de la interfaz de aplicación, basándose en la entrada del usuario hacia el primer dispositivo doméstico a través de dispositivo cliente. Los datos de descripción de la interfaz de aplicación pueden incluir
datos de capacidades para el segundo dispositivo doméstico y el primer dispositivo doméstico puede hacer una petición a los datos de capacidades dentro de los datos de descripción de la interfaz de aplicación del segundo dispositivo doméstico y actualizar los datos de la interfaz del usuario dentro del primer dispositivo doméstico, para permitir comandar y controlar al segundo dispositivo doméstico por medio de un usuario, a través de una interfaz del usuario del primer dispositivo doméstico desplegada sobre el dispositivo cliente. Dos ó más dispositivos domésticos pueden ser conectados a la red, cada dispositivo doméstico almacenando datos de descripción de la interfaz de aplicación en un formato estructurado para comandar y controlar al dispositivo doméstico por medio de uno ó más dispositivos domésticos diferentes, conectados a la red. Los datos de descripción de la interfaz de aplicación que están dentro de cada uno de los dos ó más dispositivos domésticos, pueden incluir datos de capacidades para el dispositivo doméstico respectivo. En éste caso, el primer dispositivo doméstico puede hacer una petición a los datos de capacidades dentro de los datos de la interfaz de aplicación de los dos ó más dispositivos domésticos, y actualizar los datos de la mterfaz del usuario dentro del primer dispositivo
doméstico, para permitir el comando y control de dos ó más dispositivos domésticos por medio del usuario, a través de la interfaz del usuario del primer dispositivo doméstico desplegado en el dispositivo cliente.
Breve Descripción de los Dibujos
Estos y otros aspectos, características y ventajas de la presente invención, serán mejormente entendidos con respecto a la siguiente descripción, reivindicaciones anexas y dibujos adjuntos en donde: la Fig. 1 muestra un diagrama de bloques en una modalidad de una red de conformidad con un aspecto de la presente invención; la Fig. 2 su muestra un diagrama de bloques de la Fig. 1, en un escenario ejemplificativo de control y comunicación del dispositivo; la Fig. 3 muestra diagrama de bloques de un sistema de red de casa ejemplificativo de conformidad con la presente invención, el cual incluye una pluralidad de dispositivos cliente y servidores; la Fig. 4 muestra un diagrama de bloques de unas modalidades ejemplificativas del dispositivo cliente y el dispositivo servidor de la Fig. 3;
la Fig. 5 muestra modalidades ejemplificativas de dispositivos cliente; la Fig. 6 muestra modalidades ejemplificativas de dispositivos servidores; la Fig. 7 muestra un diagrama de bloques de dos dispositivos servidores en red ejemplificativos, capaces de comunicarse y controlarse entre si; la Fig. 8 muestra diagrama de bloques de una arquitectura ejemplificativa de un modelo de audio/video (A/V) que incluye ejemplos de un dispositivo servidor fuente, un dispositivo servidor aceptor y un dispositivo cliente dentro de una red; la Fig. 9 muestra otro ejemplo del modelo de audio/video (A/V) ; la Fig. 10 muestra una tabla de datos de capacidades ej emplificativa para un dispositivo de red; la Fig. 11 muestra una tabla de datos de atributos ejemplificativa para un dispositivo de red; la Fig. 12 muestra una configuración ejemplificativa de bloques de construcción para generar mensajes de comandos entre los dispositivos en red; la Fig. 13 muestra otra configuración ejemplificativa de los bloques de construcción de la Fig. 12, para generar mensajes de comando;
la Fig. 1. muestra tres ejemplos de la interacción entre dispositivos cliente y servidores en red; la Fig. 15 muestra un diagrama de bloques ejemplificativo de las definiciones de extensiones API de interfaces de dispositivo en red; la Fig. 16 muestra una arquitectura ejemplificativa del una aplicación del dispositivo servidor que acceso al documento de red descripción de la interfaz de otro dispositivo servidor; la Fig. 17 muestra otro ejemplo del arquitectura de control entre dispositivos, entre un dispositivo servidor controlador y un dispositivo servidor controlador; la Fig. 18 muestra una modalidad de un protocolo
X L que proporciona una capa de programa intermedio común y estándar para la Web, en una pila de comunicación en el nivel API entre los dispositivos en red; la Fig. 19 muestra otra modalidad de la arquitectura de comando y control de dispositivo servidor a dispositivo servidor; la Fig. 20 muestra la relación que existe entre una librería de interfaz de dispositivo y una base de
datos de definición de electrónica de consumo para dispositivos domésticos; la Fig. 21 muestra una forma jerárquica de una modalidad de una definición de interfaz de dispositivo; la Fig. 22 muestra un ejemplo de capas en la definición de interfaz del dispositivo de la Fig. 21; la Fig. 23 muestra un proceso de transmisión de interpretación de comandos entre un dispositivo emisor y uno receptor; y la Fig. 24 muestra una tabla de ejemplo de una lista parcial de tipos y formatos de paquete para proporcionar servicios de traducción, de conformidad con un aspecto de la presente invención.
Descripción Detallada de la Invención
En un aspecto, la presente invención proporciona una comunicación entre dispositivos dentro de una red, tal como una red de casa. Mientras que los dispositivos domésticos se han hecho cada vez más inteligentes y pueden compartir información, la comunicación entre dispositivos permite que un usuario interconecte dispositivos dentro de una red, para tomar ventaja de las capacidades de compartir información de aquellos dispositivos. Como tal, la comunicación entre
dispositivos juega un papel crucial en permitir que un usuario tenga la capacidad de utilizar amplia y flexiblemente los dispositivos en red. Refiriéndonos a la Fig. 1, en una modalidad de la presente invención, una red 10 incluye por lo menos un dispositivo cliente 12 y por lo menos un dispositivo servidor 14 interconectados a través de un enlace de comunicación 16. El enlace de comunicación 16 puede incluir un bus serial 1394 que proporcione una capa física (medio) para enviar y recibir datos entre los diferentes dispositivos domésticos conectados. El bus serial 1394 soporta tanto a trenes de audio/video (A/V) multiplexados en tiempo, como comunicaciones en protocolo de Internet (IP) estándar. En ciertas modalidades, una red de casa utiliza una capa de red IP como la capa de comunicación para la red de casa. Sin embargo, pueden ser utilizados otros protocolos de comunicación para proporcionar la comunicación de la red de casa. Cada dispositivo cliente 12 puede comunicarse con uno ó más dispositivos servidores 14 dentro de la red 10. Además, cada dispositivo servidor 14 puede comunicarse con uno ó más dispositivos servidores 14 y uno ó más dispositivos clientes 12, dentro de la red 10. Cada dispositivo cliente 12 puede incluir una interfaz
de comunicación que incluya a dispositivos de entrada tales como un ratón y un teclado para recibir entradas del usuario y una pantalla para proporcionar una interfaz del usuario de control para que un usuario interactúe con los dispositivos en red. La mterfaz del usuario puede incluir una pantalla de interfaz gráfica de usuario (GUI) 18 para proporcionar información al usuario. Refiriéndonos a la Fig. 2, como ha sido definido aqui, cada dispositivo servidor 14 proporciona un servicio al usuario, excepto la interfaz del usuario de control, y cada dispositivo cliente 12 proporciona una interfaz del usuario de control para la interacción del usuario con la red 10. Como tal, solamente los dispositivos cliente 12 interactúan directamente con los usuarios, y los dispositivos servidores 14 interactúan solamente con dispositivos cliente 12 y otros dispositivos servidores 14. Servicios ejemplificativos pueden incluir servicios de despliegue y de fuente/aceptor MPEG. La Fig. 3 muestra un diagrama de bloques de una red de casa 10 de ejemplo, que incluye una pluralidad de dispositivos clientes 12 y una pluralidad de dispositivos servidores 14. Cada dispositivo servidor 14 puede incluir al equipo fisico como un recurso dentro de la red, para proporcionar servicios son usuario. Además,
cada dispositivo servidor 14 puede almacenar un programa de control de servidor ó de servicio 20 para controlar al equipo fisico del servidor e incluir una descripción de interfaz del usuario 22 de objeto de control gráfico (GCO) para la interfaz del usuario con el programa de control de servidor 20, como se muestra en la Fig. 4. Para tener control entre un dispositivo cliente controlador 12 y un dispositivo servidor controlado 14, el dispositivo cliente 12 accesa al objeto de control gráfico 22 del dispositivo servidor 14 por medio de transferir, por ejemplo, el objeto de control gráfico 22 desde el dispositivo servidor 14 hasta el dispositivo cliente 12, sobre la red. El dispositivo cliente 12 utiliza entonces el objeto de control gráfico 22 transferido para crear una interfaz del usuario de control GUI 18, para que el usuario se comunique con el programa de control 20 del dispositivo servidor 14, desde el dispositivo cliente 12 que está en la red. El usuario proporciona el comando y el control para, por lo menos, el programa de control 20 del dispositivo servidor 14, desde el dispositivo cliente 12. Al almacenar el objeto de control gráfico 22 de cada dispositivo servidor 14 dentro del dispositivo servidor mismo, puede reducir los requerimientos de procesamiento y almacenamiento de los dispositivos
clientes 12, en redes con muchos dispositivos servidores 14. Además, al almacenar los objetos de control gráfico 22 en los dispositivos servidores 14, puede permitir que cada dispositivo servidor 14 proporcione su propio diseño y detalle de la interfaz gráfica del usuario, y permita la modificación ó actualización de los objetos de control gráfico 22, sin hacer ninguna modificación a los dispositivos clientes 12. Refiriéndonos a la Fig. 4, para proporcionar el comando y control entre el dispositivo cliente 12 y el dispositivo servidor 14, en una modalidad, el dispositivo cliente 12 puede incluir un reproductor 24 para desplegar una interfaz gráfica del usuario 18 utilizando un objeto de control gráfico 22 almacenado en el dispositivo cliente 12 ó transferido hacia el dispositivo cliente 12 sobre la red en el que se encuentra un dispositivo servidor 14 deseado. Por ejemplo, en una fase inicial de selección de dispositivo, el dispositivo cliente 12 puede traer al objeto de control gráfico 22 de al menos, un dispositivo servidor 14 que está sobre la red y el reproductor 24 despliega una interfaz de control del usuario 18 utilizando al objeto de control gráfico 22 para controlar al dispositivo servidor 14. Preferentemente, la interfaz de control del usuario 18 es personalizada
iiiür • --T'
para el dispositivo servidor 14 y puede incluir un conjunto de comandos incorporados para controlar al dispositivo servidor 14. En añadidura, las ínterfaces gráficas del usuario 18 de varios dispositivos servidores 14 pueden incluir características en común tales como: (1) un tipo de modelo de objeto de control gráfico común para que el reproductor 24 del dispositivo cliente despliegue las interfaces gráficas del usuario 18, (2) protocolos comunes de comunicación para transferir los objetos de control gráfico 22 desde varios dispositivos servidores 14 hacia el dispositivo cliente 12, y (3) protocolos comunes de comunicación para la interacción que exista entre la interfaz gráfica del usuario procedente del dispositivo cliente 12, hacia el programa de control 20 del dispositivo servidor correspondiente 14, en donde el dispositivo cliente 12 no requiera un conocimiento incorporado de un dispositivo servidor 14 en particular, que esté siendo controlado. Refiriéndonos todavia a la Fig. 4, un dispositivo servidor 14 puede incluir uno ó más programas de control de servidor 20 para controlar al equipo fisico del servidor para que asi, proporcione un servicio. La interfaz de control del usuario 18 procedente del objeto de control gráfico 22 del
dispositivo servidor 14, proporciona una interfaz para los programas de control del dispositivo servidor 20. El dispositivo servidor 14 puede también incluir unos datos de estado de control 26 que indican el estado de control del dispositivo servidor 14 y del equipo fisico del dispositivo servidor, al proporcionar un servicio ya requerido . Por ejemplo, los datos de estado de control 26 pueden incluir el estado de la información de control de la interfaz de control del usuario 18 para el dispositivo servidor 14, tal como la configuración de un temporizador para una acción de grabación en un dispositivo servidor de videograbadora . Los datos de estado de control 26 son almacenados en el dispositivo servidor 14 controlado y desplegados a un usuario a través de la interfaz de control del usuario 18 de dispositivo servidor 14 en el dispositivo cliente 12 controlador, para que el usuario controle el dispositivo servidor 14. Preferentemente, el dispositivo cliente 12 controlador para desplegar a la interfaz de control del usuario 18 del dispositivo servidor 14, no requiere ningún conocimiento de los datos de estado de control 26 para el dispositivo servidor 14 controlado. Cada dispositivo servidor 14 puede ser controlado por uno ó más dispositivos cliente 12. Asi,
los datos de estado de control 26 almacenados en el dispositivo servidor 14 incluyen al estado de la información que se encuentra en la interfaz de control del usuario 18 del dispositivo servidor 14, en cada uno de los dispositivos clientes 12 controladores. Por ejemplo, cuando los usuario controla un dispositivo servidor 14 utilizando un primer dispositivo cliente 12, la información que se encuentra en la interfaz de control del usuario 18 del dispositivo servidor 14 en el primer dispositivo cliente 12, es almacenada por el dispositivo servidor 14 dentro de los datos de estado de control 26 del dispositivo servidor 14, hasta la conclusión del control del usuario. Alternativamente, mientras que el usuario está interactuando con la interfaz de control del usuario 18 del dispositivo servidor 14, en el primer dispositivo cliente 12, los datos de estado de control 26 del dispositivo servidor 14 son actualizados con la información que se encuentra en la interfaz de control del usuario 18 del dispositivo servidor 14 en el primer dispositivo cliente 12, y hasta la conclusión del control del usuario, los datos de estado de control 26 son retenidos en el dispositivo servidor 14. Cuando el usuario controla al dispositivo servidor 14 utilizando un segundo dispositivo cliente 12, los datos de estado
de control 6 se hacen disponibles para el usuario, a través de la interfaz de control del usuario 18 del dispositivo servidor 14 en el segundo dispositivo cliente 12, para un control adicional. El usuario también puede utilizar al primer dispositivo cliente 12 en un momento posterior, para controlar al dispositivo servidor 14, hasta que los datos de estado de control 26 se hagan disponibles para el usuario a través de la interfaz de control del usuario 18 del dispositivo servidor 14 en el primer dispositivo cliente 12, para un control adicional. El dispositivo servidor 14 también puede incluir un reloj 28, ó mantener el horario actual, para permitir una acción de retardo de tiempo, basada en el ingreso del horario ó del reloj de un usuario, como se describirá más adelante. Un dispositivo cliente 12 y un dispositivo servidor 14 pueden ser agrupados físicamente entre sí, como una sola unidad, tal como un DTV (televisor digital). En este caso, el dispositivo servidor 14 incluye un programa de control 20 para controlar al equipo físico del servidor y el dispositivo cliente 12 proporciona una interfaz de control del usuario para el programa de control de servidor 20, para comandar y controlar a, por lo menos, el equipo físico del servidor. La Fig. 5 muestra ejemplos de dispositivos
clientes 12 que pueden incluir: (1) un PDA (asistente personal digital) (C Remoto) para desplegar una interfaz gráfica del usuario, (2) un DTV (STB, caja de adaptación multimedios) para desplegar una interfaz gráfica del usuario e incluir un servidor aceptor que comprenda a un servidor de destino de trazo de programa de audio y/ó video, y (3) una computadora personal para desplegar una interfaz gráfica del usuario e incluir por lo menos un dispositivo servidor para proporcionar múltiples servicios. El equipo físico y los ejecutables dentro de un dispositivo cliente de TV digital ó de computadora personal pueden también ser controlados por medio de otros dispositivos cliente. La Fig. 6 muestra dispositivos servidores 14 de ejemplo, incluyendo: (1) una tarjeta inteligente DVDP como un dispositivo servidor fuente, (2) un Amplificador de Audio como un dispositivo servidor aceptor, (3) una Videograbadora Digital en la forma de un dispositivo servidor, ya sea, aceptor ó fuente, y (4) un Servidor de Gestión para gestionar los dispositivos servidores remotos. El Servidor de Gestión puede estar incluido dentro de un DBS-STB, un STB de televisión por cable, ó un ATSC STB, por ejemplo. Dichos dispositivos incluyen a un Servidor de Gestión para controlar localmente ó gestionar los trabajos internos del STB. Adicionalmente, pueden ser
utilizados servidores externos accesados a través de una red externa, por medio de dispositivos cliente locales para servicios tales como Video sobre Demanda, Televisión Mejorada y comercio por Internet, por ejemplo. Refiriéndonos a la Fig. 7, la comunicación y el control entre los dispositivos servidores 14 es realizado por medio de los programas de control 20 de los dispositivos servidores 14, que comunican los datos de comandos y de control entre estos. Un dispositivo servidor 14 puede controlar a uno ó más dispositivos servidores 14 diferentes, que se encuentren sobre una red. Así, un dispositivo servidor 14 puede ser controlado por medio de uno ó más dispositivos servidores 14, y por uno ó más dispositivos clientes 12. Adicionalmente, un usuario puede utilizar un dispositivo cliente 12 para comandar y controlar a un primer conjunto de dispositivos servidores 14, y el primer conjunto de dispositivos servidores 14 pueden comandar y controlar automáticamente a un segundo conjunto de dispositivos servidores 14, sin la necesidad de involucrar al usuario, como sea necesario, para efectuar servicios para el usuario. Por ejemplo, para una operación de retardo de tiempo automática, el usuario puede "ingresar al
sistema" en el dispositivo cliente 12 para controlar un primer conjunto de dispositivos servidores 14 y especificar los servicios deseados. El usuario entonces "sale del sistema" del dispositivo cliente 12. El primer conjunto de dispositivos servidores 14 efectúa la comunicación y el control entre sí mismos y en un momento posterior, uno ó más de los dispositivos servidores 14 que se encuentra en el primer conjunto, controla automáticamente un segundo conjunto de dispositivos servidores 14, como sea necesario, para proporcionar colectivamente los servicios deseados, sin que se involucre al usuario. La Fig. 7 muestra modalidades ejemplificativas de los dispositivos servidores 14, capaces de comunicarse y controlarse entre sí. Cada dispositivo servidor 14 incluye un programa de control 20, un reloj 28 y los datos de estado de control 26, descritos arriba. Cada dispositivo servidor 14 puede incluir también un objeto de control gráfico 22 para que el dispositivo servidor 14 esté controlado directamente por medio de un dispositivo cliente 12. Sin embargo, un objeto de control gráfico 22 no necesita ser incluido dentro de un dispositivo servidor 14 que no sea controlado directamente por el dispositivo cliente 12 y solamente se comunique con otros dispositivos servidores
14. Cada dispositivo servidor 14 también incluye una interfaz de lenguaje de comandos (CL) 30 y una librería de comandos. La librería de comandos incluye los comandos que utiliza el dispositivo servidor 14 para enviar y recibir información para así, proporcionar su servicio. Sin embargo, no es necesario un lenguaje de comando para el control del usuario, como se muestra en la Fig. 4 y como se ha descrito arriba. La Fig. 8 muestra un ejemplo de un modelo de audio/video (A/V) ejemplificativo que incluye un dispositivo servidor 14 fuente, un dispositivo servidor 14 aceptor y un dispositivo cliente 12 dentro de la red. El dispositivo servidor 14 fuente incluye un programa de control 20 para controlar el equipo físico fuente de tren de datos 32 del dispositivo servidor 14 fuente, y el dispositivo servidor 14 aceptor incluye un programa de control 20 para controlar al equipo físico aceptor de tren de datos 34 del dispositivo servidor 14 aceptor. En una operación de ejemplo, un usuario utiliza al dispositivo cliente 12 para controlar al dispositivo servidor 14 fuente, para iniciar al equipo físico fuente de tren de datos 32, y para controlar al dispositivo servidor 14 aceptor, para que inicie al equipo físico aceptor de tren de datos 34. Hasta la inicialización de la transferencia de datos, desde el equipo físico fuente
de tren de datos 32, hasta el equipo físico aceptor de tren de datos 34, el usuario puede abandonar al dispositivo cliente 12. Alternativamente, el usuario puede programar la inicialización de la transferencia de datos a un momento posterior y puede abandonar al dispositivo cliente 12. de aquí en adelante, el equipo físico fuente de tren de datos 32 del dispositivo servidor 14 fuente y el equipo físico aceptor de tren de datos 34 del dispositivo servidor 14 aceptor, inician automáticamente la transferencia de datos al momento programado por el usuario. Por ejemplo, el equipo físico fuente de tren de datos 32 puede incluir un Dispositivo de Acceso a Sintonizador, tal como una Radiodifusión Directa Vía Satélite (DBS). Una transmisión DBS es una alternativa de canales múltiples a la televisión por cable y proporciona programación de televisión de tipo cable directamente desde los satélites en antenas parabólicas pequeñas (de 45 a 90 cm) . En la radiodifusión directa por satélite, varias señales de televisión análogas estándar son comprimidas digitalmente en un solo transponedor de satélite, permitiendo así hasta 200 ó más canales que pueden recibirse con una antena parabólica enfocada a una posición fija en el cielo. El equipo físico aceptor de tren de datos 34 puede incluir
una Videograbadora Digital (DVCR) que comprenda una videograbadora digital que sea capaz de decodificar señales de video digitales comprimidas al reproducirse. El usuario proporciona datos de comando y control que incluyen a datos de eventos "de grabación de tiempo retardado" para la videograbadora digital y unos datos del evento "de selección del programa de tiempo retardado" para el Dispositivo de Acceso a Sintonizador. Después del retardo de tiempo, el Dispositivo de Acceso a Sintonizador selecciona al programa deseado y proporciona datos del programa a la videograbadora digital, la cual recibe y graba los datos del programa sin ninguna acción adicional de control por parte del usuario . La Fig. 9 muestra otro ejemplo de un modelo de audio/video (A/V) que incluye por lo menos, un dispositivo servidor 14 fuente SERVER1, un dispositivo servidor 14 aceptor SERVER2 y un dispositivo cliente 12 sobre la red 10. El dispositivo cliente 12 incluye un gestionador de sesión 36 con una interfaz del usuario para desplegar información de selección para que un usuario seleccione y controle los dispositivos servidores 14 SERVER1, ?ERVER2 y a otros dispositivos servidores 14, tales como SERVER3 y SERVER4 (no mostrados). La información de selección puede incluir
símbolos en icono designados como Serví, Serv2, Serv3 y Serv4 en el gestionador de sesión 36, para que un usuario seleccione los dispositivos servidores 14 SERVER1, ?ERVER2, SERVER3 y SERVER4 , respectivamente. El dispositivo servidor 14 fuente SERVER1 puede incluir una videograbadora digital y el dispositivo servidor 14 aceptor SERVER2 puede incluir una televisión digital. En una operación de ejemplo, hasta la selección de los dispositivos servidores 14 SERVER1 y SERVER2, el dispositivo cliente 12 transfiere el objeto de control gráfico 22 de cada dispositivo servidor 14 hacia el dispositivo cliente y despliega una interfaz de control del usuario 18 correspondiente para cada uno de los dispositivos servidores 14 SERVER1 y SERVER2. El usuario puede interactuar con la mterfaz de control del usuario 18 de cada dispositivo servidor 14 para proporcionar comandos y control para el dispositivo servidor 14 correspondiente, para proporcionar servicio. Cada uno de los dispositivos servidores 14 puede proporcionar un solo servicio ó en combinación con otros dispositivos servidores 14. El gestionador de sesión 36 transfiere los datos de estado de control 26 de entre las interfaces gráficas del usuario 18 de los dispositivos servidores 14 dentro del dispositivo cliente 12, como sea necesario, para que los dispositivos servidores 14
correspondientes efectúen un servicio. Basándose en la información de comando y control del usuario, dos ó más dispositivos servidores 14 pueden comunicar la información de comando y control entre si mismos, para proporcionar un servicio requerido por el usuario. El gestionador de sesión 36 puede incluir un agente de soporte lógico que funcione para tener acceso y desplegar los servicios disponibles de la red de casa, proporcionados por varios dispositivos servidores 14 dentro de la red. El agente de soporte lógico puede coincidir adicionalmente las capacidades de varios dispositivos servidores 14 dentro de la red 10 y desplegar la información de selección para solamente aquellos dispositivos servidores 14 que tengan capacidades compatibles. Además, el gestionador de sesión 36 puede hacer coincidir las selecciones hechas en la interfaz de control del usuario 18 de un dispositivo servidor 14, con las selecciones de la interfaz de control del usuario 18 de otro dispositivo servidor 14 para ayudar al usuario proporcionar información de comando y control significantes a los dispositivos servidores 14. En otra operación de ejemplo, el gestionador de sesión 36 ejecuta al agente de soporte lógico que busca en la red y descubre a los dispositivos servidores 14
conectados a la red. El agente de soporte lógico también accesa a los datos de capacidades almacenados en cada dispositivo servidor 14, para determinar las capacidades de los dispositivos servidores 14 y proporciona información acerca de aquellas capacidades de usuario. El gestionador de sesión 36 despliega entonces los iconos de selección Serví, Serv2, Serv3 y Serv4 para permitir que el usuario seleccione entre los cuatro iconos de selección. Después de que el usuario selecciona al dispositivo servidor SERVER1 por medio de hacer clic en el icono de selección Serví, el gestionador de sesión 36 determina que los dispositivos servidores SERVER3 y SERVER4 no son compatibles en sus capacidades con el dispositivo servidor SERVERl. Así, el gestionador de sesión 36 deshabilita los iconos de selección Serv3 y Serv4 para los dispositivos servidores SERVER3 y SERVER4, respectivamente. El usuario puede entonces hacer clic sobre el icono Serv2 para comandar y controlar al dispositivo servidor SERVER2. Mientras que el usuario interactúa con la interfaz de control del usuario 18 de un dispositivo servidor seleccionado 14, la entrada de información de control y comando realizada por el usuario en cada interfaz de control del usuario 18, proporciona información de capacidades adicionales, las cuales
afectan a las selecciones futuras hechas por el usuario de dispositivos servidores. Por ejemplo, si un dispositivo servidor 14 de videograbadora es seleccionado, la acción adicional realizada por el gestionador de sesión 36 en habilitar ó deshabilitar iconos de selección para otros dispositivos servidores 14, es afectada por la decisión de un usuario para reproducir ó grabar. Cada dispositivo servidor 14 que se encuentre sobre la red, tiene una ó más capacidades de servicio, como las que se ha discutido arriba a manera de ejemplo, con referencia a los dispositivos servidores de la Fig. 9. Cada capacidad de servicio incluye realizar la acción de fuente ó aceptor de la información. Por ejemplo, una televisor tiene la capacidad aceptora de recibir trenes de audio y video, un dispositivo de videograbadora puede ser fuente (transmitir y ser aceptor (recibir) señales de video y audio y una computadora personal puede ser capaz de transmitir y recibir datos, audio y video. Cada capacidad de ser fuente tiene una capacidad de ser aceptor complementaria y compatible. Similarmente, cada capacidad de ser aceptor tiene una capacidad de ser fuente complementaria y compatible. Por ejemplo, la capacidad de salida de video de dispositivo está complementada por la capacidad de entrada de video de
otro dispositivo. Ya que cada dispositivo 14 puede ser fuente ó aceptor para varios servicios diferentes sobre la red, cada dispositivo 14 almacena una tabla de datos de capacidades (Tabla 1 de Capacidades) , como se muestra por el ejemplo de la Fig. 10. La primera columna de la Tabla 10 identifica las capacidades de servicio de un dispositivo 14, y la segunda columna identifica si es que el dispositivo 14 es fuente ó aceptor para un servicio correspondiente en la primera columna. Al utilizar la Tabla 1 de datos de capacidades, pueden implementarse nuevos servicios, a la vez de mantener la compatibilidad con dispositivos más antiguos. Por ejemplo, si es desarrollado un nuevo servicio que sea compatible con un servicio más antiguo, ambos servicios nuevos y antiguos pueden ser ingresados en la Tabla 1 de datos de capacidades, para que un dispositivo implemente al nuevo servicio, con lo que el dispositivo que implementa permanece compatible con los dispositivos más antiguos que utilicen al servicio antiguo. En una implementación, un Gestionador de
Dispositivos conduce una operación de coincidencia ó comparación de servicios de dispositivo fuente y aceptor. Por ejemplo, el Gestionador de Dispositivos puede ser implementado como un agente de soporte lógico para comparar las capacidades ó propiedades de varios
dispositivos 14 y localizar dispositivos 14 con capacidades que coincidan. Por ejemplo, en un caso en donde el servicio sea una tren de medios procedente de un primer dispositivo 14 a lo largo de una red, hacia un segundo dispositivo 14, el Gestionador de Dispositivos compara las capacidades de los primer y segundo dispositivos 14 para ayudar al usuario a hacer una selección más acertada del segundo dispositivo 14, el cual será compatible con las capacidades del primer dispositivo 14. La siguiente es una lista de ejemplo de capacidades de servicio para una modalidad de un dispositivo servidor 14:
Stream_format_v¡deo_dv Stream_format_v¡deo_mpeg2tpt Stream_format_v¡deo_dsstpt Stream_format_video_mpeg2pes Stream_format_video_mpeg210801-tpt
Cada dispositivo 14 puede almacenar adicionalmente una tabla de datos de atributos (Tabla 2 de Atributos) incluyendo a atributos pertinentes del dispositivo, mostrados como ejemplo en la Fig. 11. Un nombre y un valor definen a cada atributo que se encuentre dentro de la Tabla 2, aunque las longitudes de caracteres mostradas en la Tabla 2 no son requeridas. Los datos de atributo están disponibles para otros
dispositivos 14 que se encuentren sobre la red 10, para facilitar la interoperabilidad y para almacenar información de dispositivos. Por ejemplo, una Hoja de Dispositivos como la que será descrita más adelante, utiliza a la Tabla 2 de Atributos para almacenar el nombre del dispositivo. Pueden añadirse otros campos a la Tabla 2 de datos de atributos cuando sea necesario.
En el modelo de control de dispositivo de usuario a cliente descrito arriba, los datos de atributos pueden ser desplegados en la página de la interfaz gráfica del usuario del dispositivo servidor 14, en el dispositivo cliente 12. Alternativamente, puede ser utilizada una página de inicio de información de dispositivo de segundo nivel, para desplegar dichos datos de atributos. Adicionalmente, los datos de atributos en forma de texto ó en un archivo XML (Lenguaje de Etiguetado Extensible) pueden ser accesados por medio de un agente de soporte lógico. Para el modelo de control de dispositivo a dispositivo, los datos de atributos para el dispositivo controlado son almacenados en la interfaz de aplicación de la interfaz del dispositivo . El campo de atributo de Ubicación del Dispositivo ( Devi ceLoca tion ) en la Tabla 2 de Atributos es utilizado para almacenar la ubicación ó el grupo de
cada dispositivo 14. El campo de atributo Devi ceType especifica el tipo de dispositivo, tal como una Videograbadora, un DVD, un Televisor Digital, una Cámara de Video, una Computadora Personal, un Sistema de Seguridad, etc., para el dispositivo 14 en particular. El campo de atributos de Tipo de Dispositivo es utilizado para seleccionar un icono de dispositivo por defecto, para representar el dispositivo dentro de la Página Dispositivos, si es que el dispositivo mismo no suministra uno. La Tabla 2 de Atributos puede incluir múltiples entradas para campos de atributos Fuente por Defecto y Aceptor por Defecto. Cada entrada de estas representa un dispositivo 14 fuente ó aceptor por defecto diferente para cada uno de los tipos de datos manejados por el dispositivo 14. Preferentemente, los datos de capacidades y atributos están empaquetados en datos estructurados, utilizando un lenguaje jerárquico. Esto proporciona un método común para retirar los datos de capacidades y atributos que son utilizados para otros propósitos tales como transferencia de objeto de control gráfico y control de dispositivo servidor a dispositivo servidor. Como un ejemplo, los datos de atributos pueden incluir al siguiente formato de datos estructurados:
<DEVICEATTRIBUTES> <ATTRIBUTE name=Dev¡ce apufacturer value="Samsung lnc."> <ATTRIBUTE pame=Manufacturer URL value=www.samsung.com:>
Como un ejemplo, los datos de capacidades pueden incluir al siguiente formato estructurado: <DEVICECAPAB1LITI ES> <CAPABIL!TY type=MPEG2 value=Source> <CAPABILITY type= PEG2 value=Sink> <CAPABILIT? type=MPEG3 value=Source> <CAPABILITY t pe=MPEG3 value=S¡nk> </DEVICECAPABILITIES>
Un lenguaje de interfaz de aplicación es utilizado para permitir que diferentes dispositivos servidores 14 efectúen el control de dispositivo a dispositivo, incluyendo al control de dispositivo servidor a dispositivo servidor. El lenguaje de interfaz de aplicación incluye lenguajes de comando y puede ser descrito utilizando XML, como será detallado más adelante. El programa de control 20 de un dispositivo servidor 14 controla remotamente al programa de control
de otro dispositivo servidor 14 que se encuentre sobre la red, sin utilizar las interfaces gráficas del usuario 18 ó sin involucrar al usuario. Un ejemplo de control de dispositivo a dispositivo es una operación automática. Un usuario proporciona inicialmente un control a través de un dispositivo cliente 12 para un servicio deseado, y subsecuentemente dos ó más dispositivos servidores 14 se comunican y controlan automáticamente entre sí, sin la interacción adicional del usuario para proporcionar el servicio. Refiriéndonos -a las Figs. 12 y 13, es utilizado preferentemente un lenguaje de interfaz de aplicación estándar, para permitir la interoperabilidad entre varios programas de control 20, en varios dispositivos servidores 14. En otra modalidad, el lenguaje de interfaz de aplicación estándar incluye los siguientes bloques de construcción: (1) especificación funcional de servicio 40 tal como los servicios de base de datos de funciones de servicio, (2) un bloque en donde sean compuestos los elementos de un mensaje 42, (3) formato estándar en la industria 44, (4) compresión de mensajes 46, y (5) construcción de cadenas de mensajes 48 para egresar datos de mensajes estructurados. La Fig. 12 muestra una configuración de ejemplo de la construcción de bloques para efectuar la función
de generar mensajes de comando. Cada elemento de mensaje es compuesto a partir de la especificación funcional del servicio y es estandarizado por medio de seleccionar una etiqueta en forma comprimida, estándar en la industria ( Hex) , para el elemento de mensaje. Es ensamblado un grupo de tales elementos de mensaje, para crear una cadena de comandos completa. Los lenguajes de comandos existentes tales como CAL y AV/C, operan como se muestra en la Fig. 12. Sin embargo, dichos mecanismos de lenguaje de comandos especifican mensajes y operación del sistema en código binario ó hexadecimal sobre dispositivos físicos en la interfaz física y están basados en especificaciones del equipo físico. Consiguientemente, dichos lenguajes de comandos pueden ser menos deseables para una capa de red basada en mecanismos de control en donde la especificación del sistema de control incluye nombrar, localizar, descubrir capacidades de dispositivo, lenguaje de comunicación y mensajes de comandos en el nivel de soporte lógico del nivel de la aplicación, en donde un programa de aplicación de soporte lógico 20 dentro del dispositivo controlador 14, localiza y controla a otro programa de aplicación de soporte lógico 20, dentro de un dispositivo controlado 14 que se encuentre sobre una red 10. Dicho mecanismo de control es sobre todo apropiado
para dispositivos tales como aparatos digitales, incluyendo a aparatos (por ejemplo, una videograbadora digital), así como dispositivos de propósitos múltiples y aplicaciones múltiples, tales como las computadoras. La Fig. 13 muestra una configuración preferida de ejemplo de los bloques de construcción de la Fig. 12, para efectuar la función de generación de los mensajes de comando. En la Fig. 13, las posiciones de formato estándar en la industria 44 y la compresión de mensajes 46 son diferentes que en la Fig. 12. Son seleccionadas un número de formas estándar textuales a partir del servicio de especificación funcional 40, para formar un mensaje completo. Después, el mensaje puede ser comprimido por medio de una capa inferior de la pila del protocolo. La Fig. 13 representa un método para efectuar servicios, ó comando y control de dispositivos para aparatos electrónicos de consumo (CE) . La composición del mensaje puede ser definida por la sintaxis estándar en el formato XML y la compresión puede ser efectuada por medio de otra capa de protocolo, tal como HTTP. Es utilizado un lenguaje de interfaz de comando en el nivel de interfaz del soporte lógico de aplicación 20, en lugar de niveles menores de equipo físico. Como tal, la pila del protocolo de la red es gobernada por medio de comandos en el lenguaje mencionado y cada uno de los
dispositivos controladores 14 puede ser visto como un componente integrado a la red, para la transmisión de mensajes entre sí. Refiriéndonos a la Fig. 14, se muestran tres diferentes instancias de la interacción entre los dispositivos clientes 12 y los dispositivos servidores 14. En la primera instancia "A", un usuario humano se comunica con una aplicación de servicio remoto "S" y recibe respuesta en los formatos HTML (Lenguaje de Etiquetado Hipertexto) ó XML. Está incluido un servidor secundario con el navegador para aceptar envíos de mensajes de comandos asincronos basados en XML, por ejemplo, en una videograbadora digital, el servidor secundario 14 puede aceptar mensajes de comandos tales como "FALLO EN VIDEOGRABADORA: CÁSETE AVERIADO." Puede ser utilizado un agente de soporte lógico que incluya un navegador para desplegar los mensajes de comando a un usuario que esté en la interfaz gráfica del usuario del navegador, para captar la atención posterior del usuario y controlar la videograbadora digital. Preferentemente, un dispositivo cliente 12 basado en XML incluye la capacidad de servidor HTTP1.1 para responder a un comando iniciado en cualquier otro lado, para el comando y control de dispositivo servidor a dispositivo servidor.
En la segunda distancia "B", el usuario es reemplazado por un programa de control de cliente de soporte lógico 50. El programa de control de cliente de soporte lógico 50 genera envíos de comandos basados en XML hacía la aplicación de servicio "S" y recibe de vuelta envíos de comandos XML. Así, en la tercera instancia "C", el programa de control de cliente de soporte lógico 50 es reemplazado por una aplicación, tal como un programa de control de dispositivo servidor 20, en donde los comandos y respuestas son intercambiados entre dos aplicaciones de servicio 20. A este respecto, la instancia "B" es un caso especial de la instancia "C" con un servicio nulo. Un lenguaje de interfaz de aplicación basado en XML es utilizado para controlar entre un primer dispositivo servidor 14 y un segundo dispositivo servidor 14 (de dispositivo a dispositivo ó de servicio a servicio) para dispositivos ó servicios que estén habilitados en la red mundial (WEB) ó habilitados en Internet. El lenguaje de interfaz de aplicación está basado en la norma de la Web, la capa de programa intermedio. En una modalidad, el control de dispositivo a dispositivo incluye controlar remotamente al programa de control 20 ó Aplicación, en un dispositivo servidor 14 a partir de otro dispositivo servidor 14, que esté en
á¡S=*« -«*--
la red 10. Así pues, las interfaces (API) para dichas Aplicaciones 20, se hacen disponibles sobre la red utilizando extensiones API (interfaz de programa de aplicación) . Preferentemente las extensiones API utilizan un formato estándar, tal como una interfaz basada en XML, para proporcionar una interoperabilidad total. Refiriéndonos ahora a la Fig. 15, se muestran unas definiciones en diagrama de bloque de extensiones API para una primera Aplica ción A, designada como un Servi ci o A y una segunda Apli ca ción B, designada como Servi cio B, comunicándose sobre la red 10. Por ejemplo, el Servi cio A puede ser el programa de control para un primer dispositivo servidor A dentro de la red y el Servi cio B puede ser el programa de control para un segundo dispositivo servidor B dentro de la red. El dispositivo servidor B envía comandos al dispositivo servidor A. Para este ejemplo, los primer y segundo dispositivos de servicio A y B puede incluir dispositivos de electrónica de consumo (CE) . Refiriéndonos a las extensiones API para el Servicio A, el primer bloque de arriba 52, proporciona una definición integral de la base datos de los objetos de electrónica de consumo y métodos que utilizan palabras en Inglés para describir dispositivos
electrónicos de consumo. La definición integral ó base de datos puede también estar en C, XML ó en otros formatos capaces de representar objetos y sus métodos respectivos. La definición integral ó base datos que utiliza XML, es llamada definición XCE. El segundo bloque 54 proporciona un formato para la representación de una interfaz del programa de aplicación (API) en formato XML para todos los dispositivos 14, designada como una definición de tipo de datos de interfaz INTERFACE.DTD. Un agente de -soporte lógico, designado como Herramien ta A, utiliza un subconjunto de la definición XCE para el Servi cio A, y utiliza la interfaz del tipo de datos INTERFACE . DTD para el Servi cio A, para crear un documento en formato XML, INTERFACE-A. XML. El documento INTERFACE-A.XML describe los objetos y métodos soportados por el Servi cio A, de acuerdo con la definición de tipo de documento INTERFACE . DTD para el Servi cio A. Otras definiciones de tipo de datos pueden también ser utilizadas para crear al documento INTERFACE-A.XML. La Herramien ta A de soporte lógico también crea una tabla de verificación 56 para convertir de mensajes XML del Servi cio B sobre la interfaz de red, a definiciones API para el Servi cio A, programadas en C
por ejemplo, y compiladas para ejecutarse binariamente. Preferentemente, la tabla de verificación 56 es creada al momento de la compilación, en donde durante el momento de correr, los mensajes (comandos) del método en forma XML entrantes, procedentes del Servi ci o B, son convertidos al formato API creado por el código C de aplicación compilado para el Servi cio A. La tabla de verificación 56 proporciona una traducción al momento de correr de las llamadas del método del objeto XML del Servi cio B en llamadas en el lenguaje nativo del dispositivo para el Servi ci o A . La tabla de verificación 56 es compilada con el programa de control de dispositivo 20, pudiendo ejecutarse localmente sobre el dispositivo servidor A para el Servi cio A . El documento INTERFACE-A. XML puede ser utilizado por el Servi cio A para verificaciones de validez, si es que encuentra un error en un mensaje recibido. El documento INTERFACE-A. XML puede también ser utilizado por una Aplicación extraña, tal como el Servi cio B, para determinar el formato del mensaje en el Servi cio A, antes de comunicarse con el Servi cio A. Adicionalmente, si el mensaje procedente del Servi cio B hacia el Servi cio A provoca un error, el Servi cio B puede accesar al documento INTERFACE-A. XML para diagnosticar el error.
^¡¿¿^¡^?&^ t^^^^^^t
Refiriéndonos a las extensiones API del Servi cio B, el primer bloque 58 proporciona una definición integral ó base de datos de objetos CE, tales como la definición XCE para el Servicio A anterior. El siguiente bloque 60 proporciona una definición de lenguaje para hacer llamadas (comandos) del método en forma XML para servicios ó dispositivos API remotos, tales como la interfaz API para el Servi cio A . La definición de lenguaje es una llamada de Petición de Método de definición de tipo documento CALL.DTD, la cual describe la interacción con los objetos que encuentran sobre la red. Un agente de soporte lógico, designado como Herramien ta B, utiliza por lo menos un subconjunto de los objetos y métodos dentro de la definición XCE para el Servi cio B y el documento CALL.DTD para generar una tabla de verificación 62, para convertir comandos desde el código de programa C compilado para el Servi cio B, en peticiones de método en formato XML. Como tal, la tabla de verificación 62 proporciona una conversión entre un método invocado por el Servi cio B (por ejemplo, "REPRODUCIR") y el documento ó mensaje XML que transporta la llamada de método a lo largo de la interfaz de red hacia el Servi cio A, por ejemplo. El subconjunto de la definición XCE utilizado por la
Herramien ta B de soporte lógico, depende del alcance y la naturaleza del uso de la red. Por ejemplo, el subconjunto puede ser seleccionado para proporcionar un uso global ó restringido de todos los servicios disponibles en una red de casa. Consiguientemente, las extensiones API proporcionan una comunicación entre varios dispositivos que se encuentran sobre la red, utilizando XML. En el ejemplo anterior, el código de programa 20 para el Servi cio B genera llamadas de método para una interfaz API, y las llamadas API son convertidas a formato XML para cumplir con la norma XML en la Web/Internet, para comunicaciones entre dispositivos. Las llamadas del método XML (mensajes) son enviadas al Servi cio A sobre la red, y el Servi cio A reconvierte las llamadas del método XML procedentes de la interfaz de red, a definiciones API de código de programa para el Servi cio A. Ésta conversión y reconversión proporciona compatibilidad con la Web/Internet para diversos dispositivos que se encuentren en la red, con interfaces API de código de programa que pudieran requerir, de otra manera, de compatibilidad binaria entre los diferentes dispositivos. Ejemplos de bloques de interfaz XML que utilizan los diagramas de bloque de la Fig. 15, son mostrados enseguida.
interface.dtd reglas para describir una interfaz de objeto en x l
c !ELEMEHT paramater #PCDATA> < IATTLIST paramater Type CDATA «REQUIRED
<!Et-5M£ÍNT method («PCDATA, (parameter)-. ) > <!EI,EMENT method (SPCDATA, (method)+)> mterface.h ejemplo de interfaz de objeto en c
/* objeto */ typedel struct Stream { int id; > ; /* métodos */ void StreamPlay (int id, int speed) ; void StresmStop (int id} ; interface.xml el mismo objeto en xml , utilizando las reglas de mterface.dtd
<object>Stream < et od>?lay <parameLer type="int">id</parameter > <parameter type»" int">epeed</parameters /method> <method>Stop <parameter type-"?nt">id</parameter> c/mti od-<object> cali.dtd reglas para describir una llamada de función en c, en xml
< ! ELEMENT parameter #PC ATA> <iATTLIST parameter valué CDATA JíREQUIRED
á*j^^^jg
< IELEMENT raet od (#PCDATA, (pararaeter) +) > <1ELEMENT object (#PCDATA> > <!ELEMBNT cali (object,method) >
controller. c comando controlador de ejemplo , en c
StreamPlay (OxOlae, bOO)
cali . xml el mismo comando en xml, utilizando cali. dtd
<!-- ejei-plo para reproducir un tren — > <call <object>Strcam</object> <method>Play</raet.od-' pararaeter val e="500">speed</parameter> </call>
Adicionalmente, lo anterior muestra ejemplos de las definiciones de interfaz INTERFACE . DTD y CALL.DTD, utilizadas para crear el documento de descripción de servicios disponibles, INTERFACE. XML, descrito arriba. La definición CALL.DTD incluye un conjunto de reglas para generar mensajes de llamada de método ó de llamada
de función, tales como mensajes de Llamada del Procedimiento Remoto XML (RPC) ó XMLRPC. La definición CALL.DTD describe una interfaz de salida de un servicio controlador 1 . En una red de casa, por ejemplo, INTERFACE.XML representa los servicios disponibles sobre la red de casa. Los servicios disponibles son un subconjunto de los servicios completos encontrados en el espacio CE. En un escenario de Grabación con una Tecla (OTR) , el usuario tiene el control de un Dispositivo de Acceso a Sintonizador, tal como una Caja de Adaptación Multimedios Via Satélite (STB) . El usuario controla al sintonizador utilizando una Guia de Programación Electrónica (EPG) tal como una representación de la interfaz gráfica del usuario de los listados de programas. La grabación OTR proporciona al usuario un servicio que incluye la selección de un programa a futuro de una guia de programación electrónica, para grabar sin que el usuario accese a la interfaz gráfica del usuario de la videograbadora, para programar la videograbadora en una Grabación Retardada en Tiempo. La grabación OTR automatiza el control de la videograbadora. Enseguida se encuentra un ejemplo de la lista de control de acciones en OTR. XML: (1) StreamOpen = reproducir la salida del tren de programas
seleccionado a la red, procedente de una caja de adaptación multimedios de satélite; para la grabación OTR este control es local al dispositivo STB; (2) StorageOpen = abrir un dispositivo de almacenamiento; y (3) StorageRecord = Enviar el Comando de Grabación a través de la red, hacia la videograbadora.
cali.dtd reglas para describir una llamada d? función c en xml
<!ELEMENT parameter #PCDATA> «IATTLIST parameter val é #REQOIRED
< !ELEMENT Riethod (iíPCDATA, (parameter) +) > < I ELEMCNT object ((.PCD?TA)> <1ELEMENT cali (ob ect.method) > interface.dtd ejemplo para desc b r una interfaz de objeto en xml
< I ELEMENT parameter #PCDATA> < 'ATTLIST parameter valué (ÍREQUIRED
< I ELEMENT method (ttPCBATA, (parameter) +) > < ! ELEMENT object (tfPCDATA, method+) > interface xml este documento describe varios servicios CE ofrecidos -a un su?conjunto de todo el espacio CE.
<?xml vers?on-M1.0"?-> <'D0CTYPE interface SYSTEM ".nterface.dtd"> <object>Stream emethod>Open <parameter <parameter </mothod> method>Close •sparameter type="?nt">?d</parameter> </met od </object>
«objectsControl «meLhod»Set <parameter type="int">id</parameter> <parameter type-"int"»level«/parameter> </method> «/object» «objec >Storage <method>Open «parameter type="int">id</parameter> «parameter type="int"»channel«/parameter; </method> <method>Record «parameter type="int">id«/parameter> «/aiethcd» <method>Play «parameter -ype-^infaidc/parameter» «parameter </method> <method>Stop «parameter type="int">id</parameter» «/method> «method»close «parameter type=*int"»id</para?r?-ter> «/method» «/object» «object»Display <method»Open «parameter t.ypc-'inc"»id«/paramcter> «parameter type-"int">channel</parame er» «/method» «me-hod>Render «parameter type="int">id«/paramefcer» «/method» <method»Blan). «parameter type="int,,»id«/parameter> «/method» <method»Control «parameter type="int"»id«/parameter» «pararaeter type="int">cid«/parameter> «parameter type»"int"»level«/parameter» «/roethod» <method»Close «parameter type-"in ">id«/parameter» «/method» «/object»
otr.xml una representación xml de una representación c de grabación de una tecla
Strea Open (100,2);/* reproducir un tren (impulsado por alimentación via satélite) */ StorageOpen (24,2);/* abrir un servicio de almacenamiento */ StorageRecord 124);/* grabar el tren */
«?xml versión*"!.0p?» «ICODTYPE interface SYSTEM "cali.dtd"» «cali» «object»Stream«/object» «method»Open«/method» «parameter value="100"»id«/parameter» «parameter value-"2"»channel«/pararaeter> «/cali» «cali» «object»Storage«/object> «method»Open«/method» «parameter value="100"»id«/parameter» cparameter valué-"2"»channel«/parameter» «/cali» «cali» «ob ect»Storage«/obect» «me hod»Record«/method» «parameter valué*"100"»id«/parameter» «/cali»
Como ha sido discutido arriba con relación a la Fig. 15, un primer dispositivo B puede accesar al documento INTERFACE . XML de un segundo dispositivo A, para determinar las capacidades del dispositivo y los detalles de la interfaz API del segundo dispositivo A y determinar los detalles de funcionalidad y comando soportados por el segundo dispositivo A. En particular, el primer dispositivo B puede determinar un traslapamiento y consiguientemente, métodos utilizables soportados por el primer dispositivo B y el segundo
dispositivo A. La Fig. 16 muestra un ejemplo en donde un primer dispositivo servidor B que incluye una Apli cación B, accesa al documento INTERFACE-A. XML de un segundo dispositivo servidor A, incluyendo una Aplicación A . El primer dispositivo servidor B incluye un documento INTERFACE-B . XML para compararse con aquel del documento INTERFACE-A. XML en el segundo dispositivo servidor A. En un escenario, el primer dispositivo servidor B desea controlar al segundo dispositivo servidor A que se encuentran la red. El documento INTERFACE-A. XML del segundo dispositivo A es transferido desde el segundo dispositivo servidor A, hacia el primer dispositivo servidor B y usado por la Aplicación B para consultar las capacidades y los métodos de la interfaz API del segundo dispositivo servidor A. Esto permite que el primer dispositivo servidor B controle al segundo dispositivo servidor A, utilizando llamadas de procedimiento remoto XML, XMLPCR. En otro escenario, el primer dispositivo servidor B efectúa los pasos anteriores después de intentar comunicarse con el segundo dispositivo servidor A por lo menos una vez, y ha fallado en establecer la comunicación. Aún, en otro escenario el primer dispositivo servidor B cuestiona al documento INTERFACE-A. XML que se encuentra en el segundo dispositivo servidor A remotamente, sin transferir el
documento INTERFACE-A. XML hacia el primer dispositivo servidor B. Hasta examinar el contenido del documento INTERFACE-A.XML, el primer dispositivo servidor B puede crear comandos para enviarlos al segundo dispositivo A en formato XML, como ha sido descrito anteriormente. Generalmente el primer dispositivo servidor A puede interpretar, por lo menos, una porción del contenido del documento INTERFACE-A. XML que se traslapa con un subconjunto de la definición XCE utilizada por los primero y segundo dispositivos servidores B y A, como ha sido descrito anteriormente. Si el primer dispositivo servidor B no es capaz de interpretar una porción del contenido del documento INTERFACE-A. XML, entonces el primer dispositivo servidor B puede ignorar esta porción, ó retirar una aplicación para ayudarlo a interpretar esta porción, por medio de traducción, como será descrito más adelante. Refiriéndonos a la Fig. 17, se muestra otro control de dispositivo a dispositivo ó entre dispositivos, entre un dispositivo servidor controlador 14 y un dispositivo servidor 14 controlado. El dispositivo servidor 14 incluye una aplicación controladora E y el dispositivo 14 controlado incluye un ejecutable de aplicación C. El dispositivo 14 controlado
incluye adicionalmente al documento INTERFACE-A. XML, la descripción de interfaz de aplicación A de la aplicación C. La aplicación E accesa a la descripción de interfaz de aplicación A dentro del dispositivo 14 controlado, para consultar las capacidades y los métodos de interfaz API del dispositivo servidor 14 controlado. La aplicación E comanda y controla entonces a la aplicación C, utilizando llamadas de procedimiento remoto XML para controlar al equipo fisico ó al servicio D del dispositivo 14 controlado. Un dispositivo planificador puede ser el caso de un dispositivo 14 controlado, manejado por horas del dia, tal como el controlador de Grabación Retardada en Tiempo de una videograbadora. En un primer ejemplo, la aplicación E accesa a la descripción de interfaz de aplicación A, por medio de consultar remotamente sobre la red. En un segundo ejemplo, la aplicación E accesa a la descripción de interfaz de aplicación A, por medio de transferir una copia de la descripción de interfaz de aplicación A desde el dispositivo 14 controlado, hacia el dispositivo 14 controlador. Entonces, la aplicación E consulta localmente a la descripción de interfaz A. En un tercer ejemplo, la descripción de interfaz de aplicación A transferida a un dispositivo de librerías 64, el cual proporciona espacio de librerías para descripciones de
interfaz, y la aplicación E consultan remotamente a la descripción de interfaz A dentro de la librería. El dispositivo de librerías 64 almacena las direcciones (URL) de las aplicaciones asociadas disponibles, para la acción y las respuestas de control directo. Refiriéndonos a la Fig. 18, el protocolo XML proporciona una capa de programa intermedio como un estándar para la Web, en una pila de comunicación 66, en el nivel API entre las aplicaciones 20 de varios dispositivos 14 que se encuentren en la red. Dentro de cada dispositivo 14, las aplicaciones que están en la parte superior de la pila de comunicación, envían y reciben mensajes de comunicación sobre la red y se comunican con capas de soporte lógico en la pila del dispositivo que controla localmente al equipo fisico del dispositivo ó al soporte lógico de servicio, para el dispositivo. Una primera interfaz API de capa XML, designada como SALIDA de Capa XML 68 es utilizada para enviar mensajes y una segunda interfaz API de capa XML, designada como ENTRADA de Capa XML 70, es utilizada para recibir mensajes. La definición XCE y la definición XML de una llamada de método, llámese la definición del tipo documento CALL.DTD descrita anteriormente, son utilizadas para crear a la SALIDA de Capa XML 68.
Adicionalmente, la definición XCE y la definición XML para una de método, llámese la definición del tipo documento INTERFACE . DTD descrita anteriormente, son utilizadas para crear a la ENTRADA de Capa XML 70. Por ejemplo, una aplicación controladora utiliza a la SALIDA de Capa XML 68 y una aplicación controlada utiliza a la ENTRADA de Capa XML 70. Refiriéndonos a la Fig. 19, se muestra otra modalidad de la arquitectura de comando y control de dispositivo servidor a dispositivo servidor. Es utilizada una arquitectura de control basada en XML para el control de dispositivo a dispositivo (servicio a servicio) , para dispositivos ó servicios habilitados en la Web ó la Internet. Un primer dispositivo A puede controlar remotamente una aplicación 20 en un segundo dispositivo B sobre la red utilizando mensajes del comando XML. La interfaz de cada dispositivo incluye las interfaces para las aplicaciones dentro del dispositivo y están descritas en formato XML. Dichas interfaces pueden ser extendidas y disponibles en la capa del programa intermedio, para retirarse e interpretarse por medio de otros dispositivos que se encuentren sobre la red, como será descrito más adelante. Cada uno de los dispositivos servidores A y B incluyen al equipo fisico y al soporte lógico para
controlar otros dispositivos que se encuentren sobre la red, y para ser controlados por otros dispositivos servidores que se encuentren sobre la red. En la Fig. 19 el dispositivo de red de casa A es un dispositivo controlador ó módulo, y el dispositivo de red de casa B es un dispositivo controlado ó módulo. Cada uno de los dispositivos A y B incluyen una interfaz XML de Dispositivo 72 que comprende a un documento de interfaz INTERFACE.XML y una definición del tipo documento INTERFACE.DTD. El documento INTERFACE . XML incluye una descripción de objetos, métodos y parámetros soportados por el dispositivo 14 correspondiente. El documento INTERFACE. DTD puede ser utilizado para verificaciones de validez especificas para la interfaz XML del dispositivo, como ha sido descrito anteriormente. Cada uno de los dispositivos A y B también incluye un analizador sintáctico XML 74, comprendiendo el código de programa para analizar y validar los mensajes XML, tal como la interfaz XML y los comandos XMLRPC. El analizador sintáctico XML 74 es similar a la ENTRADA de Capa XML 70 descrita anteriormente con referencia a la Fig. 18. Además, cada uno de los dispositivos A y B incluye un codificador y decodificador (codee) XMLRPC 76 para codificar los nombres de método y parámetros de una llamada saliente
en un mensaje XMLRPC y para decodificar un mensaje XMLRPC entrante después de que es analizado, para retirar el nombre del método y los parámetros de ahí. La arquitectura de control de dispositivo a dispositivo permite, consiguientemente, el uso de diferentes formatos XMLRPC, sin cambiar otro aspecto de la arquitectura de control de dispositivo a dispositivo. Un Capturador de interfaz que comprende un código de programa, es utilizado por medio de cada uno de los dispositivos A y B para capturar la interfaz del dispositivo de otro dispositivo, directamente desde el otro dispositivo ó desde una Libreria de Interfaces de red en casa 80. Cuando un dispositivo 14 es un dispositivo controlador, un código de programa de aplicación controladora 82 dentro del dispositivo controlador 14, efectúa el comando y el control de otros dispositivos 14 que se encuentren sobre la red, por medio de soporte lógico y equipo físico de supervisión dentro del dispositivo controlador 14, tal como un analizador sintáctico XML 74, el capturador de interfaz 78 y el codee XMLRPC 76. Cuando un dispositivo 14 es un dispositivo controlado, un código de programa de aplicación controlada 84 dentro del dispositivo controlado 14, supervisa al soporte lógico y al equipo físico dentro de dispositivo 14, para que el dispositivo
14 sea controlado por otros dispositivos 14. Un servidor Web de Dispositivo de Red en Casa 86 dentro de cada uno de los dispositivos A y B, es utilizado por medio de la aplicación controlada 84, para convertir la información en mensajes XMLRPC (por ejemplo, nombre de método, nombre de parámetros y tipo) a la interfaz nativa del dispositivo (por ejemplo, nombre del método nativo, nombre de parámetros y tipo) . Dicha tabla 88 no es utilizada cuando los nombres de los métodos y parámetros en mensajes XML y la interfaz nativa del dispositivo, son los mismos. Cada uno de los dispositivos A y B incluye adicionalmente uno ó más Manejadores 90, en donde cada Manejador 90 incluye un apuntador desde adentro de la aplicación controlada 84, hacia una implementación nativa de una funcionalidad específica del dispositivo. En la mayoría de los dispositivos, las implementaciones nativas de funcionalidad de dispositivo incluyen un código diario al momento de correr. El código binario puede ser generado a partir de lenguajes de niveles mas altos al momento de la compilación, incluyendo a C y Java, por ejemplo. Asi pues, los fabricantes de aparatos electrónicos de consumo pueden añadir más Manejadores 90 para funciones nuevas, sin afectar a los Manejadores existentes y sus implementaciones de función. Un
servicio de equipo físico 92 dentro de cada uno de los dispositivos A y B incluye unas implementaciones nativas de funciones de dispositivo. Cada uno de los dispositivos A y B también incluye una Interfaz Nativa 94 que comprende a la interfaz API de la implementación nativa de las funciones del dispositivo. Adicionalmente, Un Intermediario de Petición del Objeto de Red, tal como un Intermediario de Petición de Objeto de Red de Casa 79 (HNORB) y una Librería de Interfaces 80 proporcionan una capa de programa intermedio 98 para la red de casa 10. Como se muestra la Fig. 19, la capa de programa intermedio 98 puede estar localizada en un tercer dispositivo 96, ó en una central de control separada. El Intermediario de Petición de Objeto de Red de Casa 79 incluye un agente de soporte lógico para utilizarse por dispositivo 14, para descubrir la existencia de otros dispositivos 14 conectados a la red 10. El agente de soporte lógico del intermediario de petición de objeto de red de casa organiza los nombres de dispositivo en una estructura de árbol jerárquica de nombres, organiza las interfaces de dispositivo en la Libreria de Interfaces y proporciona interfaces de dispositivo para un dispositivo que requiera información de interfaz.
La capa de programa intermedio, que comprende al Intermediario de Petición de Objeto de Red de Casa 79 y a la Librería de Interfaces 80, puede ser conectada directamente a Internet, de tal manera que los dispositivos domésticos seleccionados puedan ser accesados por fuera de una red de casa local 10. La capa de programa intermedio 98, dentro de una red de casa local, puede ser conectada a la capa de programa intermedio 98, en otras redes de casa locales sobre Internet, para proporcionar una red integrada que comprenda a dos redes de casa 10. En este caso, los usuarios autorizados con la encriptación del tren apropiada, pueden accesar a un cambiador de videodiscos digitales (DVD) en la casa primaria del usuario, desde un televisor en la casa secundaria del usuario, para reproducir el video y verlo en el televisor. Para usar la Librería de Interfaces 80, por lo menos un Intermediario de Petición de Objeto de Red de Casa y una Librería de Interfaces (conjunto HNORB&IL) deben de estar corriendo en la red de casa local 10. Mas de un conjunto HNORB&IL pueden también estar disponibles. Por ejemplo, un módem de cable, varios televisores digitales y una central de casa pueden tener todos estos sus propios agentes de soporte lógico del conjunto HNORBSIL. Para localizar al conjunto HNORB&IL,
un dispositivo 14 envia un mensaje de radiodifusión sobre la red local de casa. El primer conjunto HNORB&IL que responda al dispositivo 14, es utilizado por el dispositivo 14. Una vez que es localizado el conjunto HNORBSIL, el dispositivo 14 y el conjunto HNORB&IL pueden establecer una conexión de Protocolo de Control de Transmisión (TCP) de punto a punto ó de Protocolo de Datagrama de Usuario (UDP) para registrarse, la petición de la interfaz del dispositivo servidor 14, así como de los servicios de verificación de dispositivo. Si no está disponible un protocolo UDP, puede ser utilizado un protocolo TCP para conexiones con un ancho de banda amplio, tal como una conexión IEEE 1394. También pueden utilizarse XMLRPC basado en HTTP, para las comunicaciones HNORBíIL del dispositivo. Por ejemplo, un dispositivo 14 puede llamar remotamente a un método de "registro" del Intermediario de Petición de Objeto de Red de Casa, para pasar la interfaz del dispositivo como uno ó más parámetros, ó, una llamada XMLRPC puede retirar una interfaz del dispositivo parcial ó completa a partir de la librería de interfaces, como una respuesta XMLRPC del valor de regreso. Como ha sido mencionado anteriormente, más de un conjunto HNORB&IL puede correr simultáneamente en una red de casa 10, en donde cada conjunto HNORB&IL reconoce
a su conjunto de dispositivos disponibles y un conjunto HNORB&IL puede comunicarse con otros conjuntos HNORBSIL para localizar a los dispositivos 14 que no se puedan localizar. Múltiples conjuntos HNORBSIL que se encuentren sobre una red de casa local 10, pueden localizarse automáticamente entre si, por medio de utilizar mensajes de radiodifusión, tales como UDP o TCP. En este caso, múltiples intermediarios de petición de objeto de red de casa constituyen a un intermediario de petición de objeto distribuido, mientras que múltiples Librerías de Interfaz constituyen a una librería de interfaz distribuida. Para proporcionar una tolerancia a fallas, si es que uno de los conjuntos HNORBSIL debiera terminar inesperadamente, todos los dispositivos registrados con este conjunto HNORBSIL son notificados y dichos dispositivos pueden registrarse automáticamente con otros conjuntos HNORBSIL disponibles . Cada interfaz de dispositivo tiene un nombre lógico único y consistente asociado. Otros dispositivos pueden utilizar al nombre lógico, único y consistente, para reconocer y tener acceso al dispositivo, aun después de que ha cambiado la ubicación o la dirección real de red del dispositivo El rastreo de los nombres lógicos y de las direcciones de dispositivo reales, es
manejado mediante un agente de soporte lógico para el servicio de nombres en el Intermediario de Petición de Objeto de Red de Casa Preferentemente, se utiliza un método de nombramiento estandarizado Mas preferentemente, es utilizada una estructura de nombramiento jerárquica para organizar los nombres de dispositivos en un árbol jerárquico. Esta estructura jerárquica puede ser expresada utilizando "/", similar a un sistema de archivos. La estructura puede ser generada por medio de diferentes métodos, tales como por medio de diferentes tipos de servicio como casa/MPEG2/TV, o mediante diferentes ubicaciones, tal como casa/sala/VCR. Pueden coexistir varios arboles de nombramiento para mejorar el desempeño y la eficiencia. En el comando y control de ejemplo, entre el dispositivo servidor A controlador y el dispositivo servidor B controlador de la Fig. 19, la capa de programa intermedio 98 se encuentra en el tercer dispositivo 96, o puede ser una central separada. Los bloques en gris muestran a los elementos de dispositivo utilizados para el proceso de comando y control especifico, ilustrado en la Fig. 19. En un escenario de operación de ejemplo, después de que los dispositivos A y B se han hecho disponibles y accesibles a través de la red, cada dispositivo se registra/presenta a si mismo y
su mterfaz XML a la capa de programa intermedio 98 del Intermediario de Petición de Objeto de Red de Casa central y de la Librería de Interfaces. Si no esta disponible una capa de programa intermedio 98 del Intermediario de Petición de Objeto de Red de Casa central y de la Librería de Interfaces, entonces cada dispositivo emite (radiodifunde) un mensaje sobre la red de casa local, para anunciarse a si mismo. La aplicación 82 controladora del dispositivo A intenta consultar todas o parte de las interfaces de dispositivo del dispositivo B controlado. Si no esta disponible una Librería de Interfaces 80, el dispositivo controlador A puede hacer una petición y capturar la interfaz del dispositivo, del dispositivo controlado B, directamente desde el dispositivo controlador B, por medio de enviar primero una petición al dispositivo B sobre la red. Sin embargo, si esta disponible una
Librería de Interfaces 80, el dispositivo controlador A puede pedir todas o parte de las interfaces de dispositivo del dispositivo controlado B a partir de la
Librería de Interfaces 80. El agente de soporte lógico de intermediario de petición de objeto de red de casa, o tiene la interfaz del dispositivo XML del dispositivo B, a partir de la estructura de la Librería de Interfaces 80, y la envía de nuevo al dispositivo controlador A.
Una vez que el dispositivo controlador A recibe a la interfaz del dispositivo XML del dispositivo controlado B, la aplicación controladora del dispositivo A utiliza al analizador sintáctico XML 74 del dispositivo A, para que analice e interprete la interfaz de dispositivo del dispositivo B. El codee (codificador/decodificador) XMLRPC 76 del dispositivo A genera entonces los mensajes de comando XMLRPC deseados, utilizando los resultados del analizador. Los mensajes de comando XMLRPC son enviados al dispositivo controlado B sobre la red. Hasta recibir los mensajes de comando XMLRPC, la aplicación controlada 84 del dispositivo B, utiliza al analizador sintáctico XML 74 del dispositivo B, para analizar e interpretar los mensajes de comando XML recibidos. El codee XMLRPC 76 del dispositivo B decodifica entonces los resultados del analizador para obtener la información de llamada de método en el mensaje de comando, incluyendo al nombre y los parámetros de método para que el dispositivo B funcione para efectuar los servicios requeridos. La aplicación controlada 84 del dispositivo B utiliza entonces la Tabla de Verificación XML Nativa 88 y los Manejadores 90 dentro del dispositivo B, para accesar y lanzar las implementaciones de función nativas del dispositivo B, a través de la interfaz nativa del
dispositivo B. Sí una función genera cualquier respuesta ó valores de regreso, dichas respuestas ó valores de regreso son codificados en mensajes XML ó XMLRPC y son enviados al dispositivo controlador A. Adicionalmente, la capa de programa intermedio del intermediario de petición de objeto de red de casa y la librería de interfaces, pueden proporcionarle al dispositivo controlador A, una referencia para el dispositivo controlado B, en donde el dispositivo A puede generar llamadas remotas a las funciones nativas del dispositivo B, solamente como llamadas para la función nativa del dispositivo local A. Preferentemente, es utilizado un formato XMLRPC estándar, de tal manera que todos los dispositivos puedan interpretar y decodificar las llamadas RPC sobre la red. Puesto que la interfaz del dispositivo de un dispositivo controlado 14, puede ser consultada y examinada por medio del dispositivo controlador 14, será preferentemente utilizado un formato XMLRPC simplificado, con la suficiente información de interfaz del dispositivo para mejorar la eficiencia. El siguiente ejemplo muestra a dos posibles formatos de llamadas XMLRPC para operaciones de Llamada de una Tecla (OTR) y Grabación Retardada en Tiempo (TDR) .
EJEMPLO I: Llamada XML, formato de ejmplo, incluyendo información detallada de etiquetas e ¡nterfaz 1. Ejemplo de llamada OTR: <?xml version="1.0"?> <call> <object>DVCR1.record</object> <method>timeDelayedRecod<.method> <parameters> <parameter> <name>channel</name> <value><int>4< int></value> </parameter> <parameter> <name>recordT¡me<.pame> <value><time>2: 10:30</ time></ value> </parameter> </parameters> </call> Ejemplo de llamada DTR: <?xml vers?on="1.0"?> <call> <object>DVCR1.record<. object> <method>opeTouchRecod</method> <parametcrs> <parameter> <name>channel</name> <value><channetName>NBC</channelName></va iue> </parameter> <parameter> <pame>startTime</name> <value><datetime.iso8601>19990401T19:05:35</ datetime.iso8601></value> </parameter> <parameter> <name>recordTime</pame> <value><time>2:00:00</time></value> </parameter> </parameters> </call>
EJEMPLO II: Llamada XML RPC, formato de ejemplo con información reducida de interfaz y
1. Ejemplo de llamada OTR: etiquetado. <?xml version="1.0"?> <call> <object>DV CR1.record</ object> <method>timeDelayedRecod</method> <parameter value="4">channel</parameter> <parameter value="2:10:30"> recordTime </parameter> </call> 2. Ejemplo de llamada DTR: <?xml version="1.0"?> <call> <object>DVCR1.record</object> <method>oneTouchRecod</method> <pararpeter value="NBC">channel</parameter <parameter value="19990401T19:05:35">startTime</parameter> <paramoter value="2:00:00">recordTime</parameter> </call>
Refiriéndonos a la Fig. 20, las interfaces de dispositivo para dispositivos domésticos 14, están basadas en una base de datos estructurada estándar en la industria 100, utilizando un vocabulario estandarizado. Los datos de interfaz para las nuevas interfaces y el vocabulario, pueden ser añadidos a la base datos 100. Una definición integral ó base de datos de objetos CE, métodos y parámetros que utilizan palabras en Inglés para describir a todos los dispositivos CE, es llamada base de datos CE 102. La definición integral ó base datos puede estar en C, XML u otros formatos capaces de representar objetos, así como sus métodos y parámetros
respectivos. La definición integral ó base datos que utiliza vocabulario XML estandarizado, es llamada definición XCE ó base datos 104. Las aplicaciones controladoras y controladas 82, 84 son programadas utilizando un subconjunto de interfaces estándar de la base de datos XCE, basada en XML 104. Cada interfaz de dispositivo es almacenada con dichas aplicaciones 82, 84, en formato XML. A pesar de que la base de datos XCE 104 no necesita estar en XML, dicha interfaz del subconjunto producida al momento de la compilación se encuentra en XML, en una modalidad de la invención, como ha sido descrito anteriormente con referencia a la Fig. 15. En la Fig. 20, en aparatos incrustados 14 la información designada como información del Fabricante 'Manuf a cturer ' , es incorporada a los aparatos 14 al momento de la fabricación y la información designada como Red de Casa ' Home Network ' es parte de los aspectos operacionales al momento de correr del aparato, dentro de la red. Las interfaces XML de dispositivo 72 designadas como 1 . . . N, para N dispositivos 14, son ramificaciones de los datos en una base de datos XCE estandarizada 104. Una Libreria de Interfaces de Red de Casa 106 (HNIL) proporciona una colección de las interfaces de dispositivo, de dispositivos disponibles
14, conectados a la red de casa. La Librería de Interfaces de Red de Casa 106 es un subconjunto de la totalidad de la base de datos XCE 104. En la Fig. 16, una interfaz del dispositivo fue transferida desde un dispositivo A, hasta un dispositivo B para una Apli ca ción B dentro del dispositivo B, para examinar el contenido de la interfaz para el dispositivo A. Como ha sido detallado arriba, una interfaz del dispositivo incluye una descripción de objetos, métodos, parámetros soportados por el dispositivo, y es referida como INTERFACE-A. XML para el dispositivo A, por ejemplo. Una mterfaz XML del dispositivo 72 es una interfaz de dispositivo en un formato XML. El contenido de la base de datos XCE 104 es una estructura orientada a servicios que proporciona interfaces de dispositivo Refiriéndonos a la Fig. 20, la base de datos XCE 104 también incluye una Definición de Tipo de Documento de Interfaz XCE estandarizada (DTD) para dispositivos CE, la cual proporciona un conjunto estandarizado de reglas para utilizar XML, para representar dispositivos CE 14. La definición DTD o sus subconjuntos pueden ser utilizados para verificaciones de validez. Un agente de soporte lógico designado como Herramienta del Fabricante 108, filtra y utiliza un subconjunto de la definición XCE 104 para un dispositivo CE especifico y utiliza a la
definición DTD de la interfaz XCE estandarizada, para generar una interfaz de dispositivo XML 72 del dispositivo CE, por ejemplo, INTERFACE . XML e INTERFACE.DTD. El documento INTERFACE. XML incluye una descripción de objetos, métodos y parámetros soportados por un dispositivo especifico, de acuerdo con el documento DTD de la interfaz XCE estandarizada. El documento INTERFACE . DTD es un subconjunto del documento DTD de interfaz XCE estandarizado y puede ser utilizado para verificar la validez de la interfaz XML del dispositivo. Otras definiciones de tipo documento también pueden ser utilizadas para crear al documento INTERFACE.XML. Las interfaces XML 72 de los dispositivos CE, incluyendo al documento de interfaz XML y al documento DTD, son almacenadas en una librería accesible universalmente, tal como la Libreria de Interfaces de Red de Casa 106. Un agente de soporte lógico 110 recolecta las interfaces de dispositivo 72 de todos los dispositivos 14 accesibles sobre la red y los coloca en una Librería de Interfaces 106 estructurada y que puede buscarse, junto con la información del nombre/dirección del dispositivo. La Libreria de Interfaces 106 es un subconjunto de la base de datos XCE 104 y el proceso para generar la Librería de Interfaces 106 es similar a
reconstruir una parte ó toda la base de datos XCE 104. La Librería de Interfaces 106 puede funcionar como una colección de interfaces de dispositivo 72 de todos los dispositivos 14 que se encuentran en la red de casa, ó como una memoria escondida ó temporal, dependiendo de la disponibilidad del espacio de almacenamiento, en donde solamente las interfaces de dispositivo 72 utilizadas más recientemente son almacenadas en esta. En casos en donde un dispositivo 14 actualice su interfaz de dispositivo 72 debido a un evento, tal como el cambio de un disco en un reproductor de DVD, una parte de la interfaz del dispositivo 72 es actualizada basándose en un servicio de evento. Refiriéndonos a la Fig. 21, la definición de interfaz del dispositivo 72 de cada dispositivo 14, tiene preferentemente una forma jerárquica. Esto es causado porque en un dispositivo doméstico 14, la definición de interfaz del dispositivo 72 puede ser muy extensa. Típicamente, una ó pocas funciones tales como una sola función para la Grabación de una Tecla, son accesadas en un solo momento y consiguientemente, solo una pequeña porción de la interfaz del dispositivo 72 es utilizada. En lugar de reproducir la interfaz del dispositivo 72 completa, es más eficiente reproducir solamente una porción de la interfaz del dispositivo 72.
Por medio utilizar la interfaz XML de dispositivo jerárquica, un dispositivo controlador 14 puede hacer una petición parcial de la interfaz del dispositivo 72 de un dispositivo controlador 14, por medio de especificar las categorías de función deseadas ó funciones dentro de una petición para la interfaz del dispositivo XML, procedente del dispositivo controlado 14 ó desde la capa de programa intermedio 98 de Intermediario de Petición de Objeto de Red de Casa y Librería de Interfaces. En este último caso, la capa de programa intermedio 98 de Intermediario de Petición de Objeto de Red de Casa y Librería de Interfaces envía de vuelta la porción deseada de la interfaz de dispositivo 72. Refiriéndonos a la Fig. 21, la estructura jerárquica de interfaz de dispositivo puede incluir cuatro capas, incluyendo a: (1) una primera capa 112 para la interfaz XML de cada red de casa, que enlista los dispositivos actualmente disponibles, (2) una segunda capa 114 para las interfaces XML generales de cada dispositivo, que enlista las categorías de las funciones, (3) una tercera capa 116 para las interfaces XML específicas de cada categoría de función para un dispositivo y (4) una cuarta capa 118 para las interfaces XML específicas de cada función dentro de una
categoría de funciones. Dentro de la red de casa, solamente son utilizadas las tres capas inferiores 114,116 y 118, y por fuera de la red de casa es utilizada la primer capa 112. La Fig. 22 muestra a las capas 112, 114, 116,
118 y los ejemplos de interfaz correspondientes. La interfaz de cada capa está enlazada a la capa superior ó inferior (si está disponible) a través de enlaces tales como Xl ink ó XPom ter, los cuales proporcionan un enlace de dos vías. El enlace Xlink incluye un paquete para una funcionalidad de hiperenlace que tiene dos partes: (1) un componente XLink que permite enlaces en documentos XML para que sean reconocidos como tales, y (2) un componente XPom ter que permite que los enlaces se localicen en las subpartes precisas dentro de un documento XML. Así pues, el enlace XLink gobierna cómo los enlaces son insertados dentro de los documentos XML, en donde el enlace puede apuntar a datos tales como un archivo GIF. Adicionalmente, XPoin ter gobierna un identificador de fragmentos que puede ir hacia una dirección URL cuando se enlaza a un documento XML, desde cualquier parte (por ejemplo, desde un archivo HTML). En un modelo de comando y control típico para que un dispositivo servidor 14 controle a otro dispositivo servidor 14, de acuerdo con la presente
invención, un primer dispositivo 14 intenta consultar la interfaz del dispositivo de un segundo dispositivo 14 en la segunda capa de interfaces 114. Después de seleccionar las categorías de funciones (FC), el primer dispositivo 14 consulta la capa de interfaz 116 de una categoría de función específicamente del segundo dispositivo 14, tal como una Categoría de Grabación. Adicionalmente, el primer dispositivo 14 puede consultar la capa de interfaz 118 de una función específica, tal como OTR ó DTR, para hacer llamadas a dichas funciones. La estructura jerárquica ó de árbol hace más eficiente en contra de una función de interfaz y ahora amplitud de banda sobre la red. Un ejemplo de estructura de archivos de interfaz y capas puede ser:
Primera capa 112 - HNI.xml Segunda capa 114 VCRLxml Tercera capa 116 - VCR_1RecordCategory.xml Cuarta capa 118 - VCR_1RecordCategoryJDTR.xml
Similarmente, la Librería de Interfaces 106 de red de casa es preferentemente jerárquica y puede estar estructurada en una gran variedad de formas, tal como por medio de diferentes tipos de servicio de dispositivos ó por diferentes ubicaciones, tal como habitaciones. Dicha estructura jerárquica es la interfaz
de una red de casa local 10 para otras redes de casa ó la Internet. Se muestra enseguida un ejemplo de definición jerárquica de interfaz del dispositivo 72 que puede ser implementada en sintaxis XML.
consumer (document_file, doc) + dacumept_file<server_home.dtd, server_auto.dtd> +-.-_doc (services_home, server_auto, server_sap?supg_web__site, avc_commands, cal_comraand5, , ? + serv?ces_home (xml_utility, -client, server_av, laghting, coms, hvac, utility, secupty, appliances, convenience, , ) + xml utility (download_DTD_file, , ) +, client (acknowledge, atten ion, error, post._mesf.age,
sound, stop_echedule, stop_all, ,) + eound (alarm, ring, buzz,,) + server_av (controls^gen, eource, sink) + controls_gen (ping, process_infor, setup,,) + process_info (?/w_id, h/w__id) +, h/ _id (ser_no, manuf, model, class, , ? + s/w_id (ser_no, exe_name, versión,,) + setup (clock,,) + clock (hours, minutes, eeconds) + source (service_id, media, race, protocol, strea??__form_.L, controls_av, , ) •]g + sink (serv?ce_id, media, rate, protocol, etream_format, controls_av, , } + service_id (url, , ) * media {tpt_stream, rara, diak, tape,,) + disk (ñame, number, , ) + rate<value> + protocol (61883/1394, UDP/IP/Etherne , , í + 61883/1394 (?ssch_ch_no) + stream_format {video, audio, , ) * video ídv, mpeg2 pt, dsstpt, mpeg2pes, mpegiiíoui-cpt, ) ? C audio (m?eg3 , ac 3 , idi , , ) +controls_av (Clow_control, tune, timer_record, u?_control, , ) + timer_record (tune, flo_control) + flow control (play, stop, goto, record, , ) + play (t?me_par ms) + record (time_params) + time_parame (no , start, duration, end,,)
+ tune (aend_epg, channel,,) + channel (number, id, time_params, , ) + ui_control (display, acsus ic) + -display (brightness, contrast, cslsr/tint,
^ horiz_size, vert_size, , ) + acoustic (volumn, base, treble, balance, fade,)
+ lighting (sensors, lights, send_cpg) + sensors (living_room, sky, , ) +----lights (rooms_up, rooms_don, yard, , ) + rooms_up (bedl, bed2, bed3, bed4, , ) + bedl (lamp, dimmer, , ) + dimraer<valuc> + rooms down (farn ly, kitchen, livipg, dinipg, sobo, garage, , ) + yard (frsnt., backí 5 + comms (homehub, incercom, telco, )
+ homehub (send_device_list, sen?_con£?gura ?on, send_snmp_mib, , ? +. intercom í) + telco O + hvac |controls_gen, contrsls havc, ,) + controls_hvac (a/c, heat, temp, humidity, ) + temp (low, high, hysteresis, , ) + utility (meters, energy_mgm , , ) + meteré (water, gas, electric,,) + aterrvalue>, gas<value>, electric<value> + security (ßensors, send_epg, alarm, , ) + sensors (peripheral, motion, , ) +-_.--peripheral (rooms_?.p, rnotns_down, , ) + motiop (rosm_down, yard, , ) + appliances (microwave, range, oven, fridge, freezer, coffee, toaeter, washer, drycr, water_heater, , ) + microwave (send_epg, controls,,) + fridge (temp, , ) + water_heater (temp) + convenience (window, curtain_open, door/gate, pool/epa, bath, fountain, lift, jacuzzi,,) +. curtain_open<value> + server_auto (message, server_auto_ford_explorer_98, , ) + 3erver_auto_ford_explorer_98 (ntileage, maintenance, , ) + mileage <data> *. maintenance <data> -r server samsung_web_s?te (message, service, help,,,) + ave csptmands<, , , command_string, , , + service_id url,,) +cal__commands<, , , command_string, , , > + service . d (url, , í
Dicha definición de interfaz de dispositivo jerárquica 72 puede incluir los siguientes campos: Nombre 'document file ' , proporciona el nombre del archivo de la definición de tipo de documento {DTD) que puede ser utilizado por un analizador sintáctico XML 74 para la verificación de legalidad y corrección de la base de datos XCE 104 ó parte de la versión XML de la base de datos XCE 104. Pueden haber varios archivos DTD para diferentes partes de la estructura XCE, en donde dichas definiciones DTD sean diferentes de las
definiciones de tipo de docujasftto, para la comunicación
Nombre ' doc ' , proporciona el nombre del nivel más alto el área de cobertura de las capacidades, atributos, comunicación e interfaz de control. ' Servi ces_home ' , proporciona un área para la automatización de la casa, electrónica de consumo, utilidad, etc. 'Server_auto ' , para un automóvil que esté en la cochera y muestra la interfaz de mensajes disponible para uno ó más tipos de automóvil. Por ejemplo,
' server_a u to_ford_expl orer_98 ' es la interfaz para un automóvil en particular. Esto permite el acceso a interfaces de kilometraje y mantenimiento del automóvil y puede también ser utilizada para el acceso remoto por medio de un fabricante de automóvil ó taller, para una verificación directa y diagnósticos remotos, por ejemplo . ' serve r_samsung_websi te ' , proporciona comunicación con una página WEB de un fabricante fuera de casa. Incluye la interfaz para mensajes, servicio, ayuda, etc. ' AVC_commands ' y ' CAL_commands ' , se proporciona para dispositivos patrimoniales capaces de interpretar lenguajes AV/C y CAL, por ejemplo. Esta porción de la
estructura identifica comandos en dichos lenguajes, en donde los comandos son etiquetados y transportados en XML. Así, el contenido no son objetos XCE (Web) y aplicaciones del convertidor de protocolo pueden ser utilizadas para hacer interfaz con el soporte lógico de aplicación CAL ó AV/C original. En la descripción anterior, ' Servi ces_home ' proporciona la estructura principal, incluyendo a aparatos electrónicos de consumo de audio/video. Una ramificación de la estructura es expandida en detalle para un ejemplo particular de una interfaz de control de aceptor de servicios de video y destino del tren (por ejemplo, una videograbadora digital (DVCR)). Las interfaces de control dentro de una red de casa típica pueden incluir: ' xml_utili ty ' , proporciona detalles para soportar funciones de red de utilidad, tal como descargar un archivo DTD, un archivo de interfaz, un archivo de programa actualizado, etc. 'client', describe los detalles de interfaz de un dispositivo cliente 12, incluyendo a un navegador Web. Por ejemplo, ' a cknowledgmen t ' indica la aceptación del controlador de reconocer un mensaje ó comando enviado .
' server_av ' , proporciona interfaces de control y capacidad para todos los servicios de audio y video disponibles, incluyendo STB, DVCR, DTV, DVD, AUDIO, etc.
' ligh tíng ' , proporciona una interfaz para un controlador de automatización de iluminación para casa, e incluye sensores, focos, etc. 'comías ', proporciona interfaces de control para dispositivos de comunicaciones, típicamente para propósitos de utilidad ó para la gestión remota de configuración de dispositivos ó parámetros para recuperar configuraciones. ' hva c ' , proporciona interfaces para el control remoto del un sistema de calefacción, ventilación y aire acondicionado (HVAC) y puede ser utilizado para controlar dicho sistema desde afuera de la casa por medio de la compañía de servicio, por ejemplo, para apagar el sistema HVAC durante períodos pico de carga en el día. Adicionalmente, dicha interfaz puede ser utilizada para controlar al sistema HVAC desde adentro de la casa, por medio de un aparato para que el controlador basado en el dispositivo proporcione un mecanismo de control más sofisticado que el control del termostato . 'utility', proporciona una interfaz para leer medidores de utilidad para la casa, por ejemplo.
' securi ty ' , proporciona una interfaz para sensores de seguridad y configuraciones de alarmas. Así, al utilizar la interfaz, las aplicaciones que corren en un dispositivo de red de casa pueden tener acceso a dispositivos de sensor y detectores alrededor de la casa, para monitorear y controlar estos dispositivos. ' appliances ' , proporciona interfaces para aparatos domésticos de cocina, de utilidad y generales, incluyendo por ejemplo, a proporcionar un control remoto ó configuraciones de monitoreo de temperatura u otros controles y parámetros procedentes de un dispositivo controlador. En un escenario, un aparato de microondas puede explorar información de código de barras en el paquete de un articulo de comida para un tipo de sistema de horno de microondas dado. Dicha integración de aparatos que utilicen el comando y control de dispositivo a dispositivo, proporciona muchos escenarios de control para proporcionar servicios tales como poner en pausa automáticamente una maquina lava platos y poner en silencio un televisor, cuando un teléfono es contestado en la cocina ó en la sala. ' convenience ' , proporciona interfaces para que los dispositivos proporcionen servicios de conveniencia tales como interfaces para controladores de cortinas, ventanas, persianas ó tinas de hidromasaje, por ejemplo.
En la descripción anterior, 'server_av' es parte de la estructura para las interfaces de control de aparatos de audio/video, que ofrezcan un servicio de tren de audio/video y está subdividido en capacidades ' con trols_gen ' , ' source ' (fuente) y ' sink ' (aceptor). ' con trols_gen ' , proporciona una interfaz para atributos de fabricantes de dispositivos e interfaces de utilidad general, tal como hacer una prueba con un buscador de paquetes de Internet (pii.gr) de la presencia del dispositivo. Adicionalmente, también pueden ser incluidos atributos incorporados en la fabricación tales como la información de identificación y versión del soporte lógico y del equipo físico. Un dispositivo que suministre esta interfaz regresa datos que proporcionan el nombre ó identificación del soporte lógico, sin efectuar ninguna acción de control. También puede ser incluida una interfaz para establecer el reloj de la hora del dia. ' sink ' proporciona una interfaz para los dispositivos de servicios de tren de medios. La estructura es organizada en base al servicio ofrecido (es decir, grabación y reproducción de trenes de video) en lugar de nombres de dispositivo particulares tales como VCR. Por ejemplo, un Sintonizador y un reproductor de DVD son ambos fuentes de trenes de programa de video
para la red con formatos de programa de video y pueden ser controlados, tal como ser iniciados y detenidos. Las diferencias en el control de dispositivos particulares son localizadas por las capas inferiores de la estructura de la definición. ' source ' proporciona una interfaz similar a la interfaz ' sink ' . Como ha sido referido anteriormente, ' servi ce_id ' ó ' appl i ca t? on_in terfa ce_id ' incluye el nombre, dirección ó dirección Web, ó ubicación URL de uno ó más dispositivos 14. Puesto que la base de datos XCE 104 comprende la totalidad de las interfaces acordadas, un agente de soporte lógico de Protocolo Dinámico de Configuración del Anfitrión (DHCP) se ejecuta típicamente para asignar una dirección y un nombre por defecto para cada dispositivo, y la dirección y el nombre por defecto son añadidos a la interfaz de servicio ó dispositivo. El agente de soporte lógico 110 recolecta entonces las interfaces de dispositivo 72 que incluyen al subconjunto de definiciones 'XCE parcial de dispositivo1 de todos los dispositivos conectados localmente a la red de casa, para generar un XCE parcial de red. Pueden añadirse interfaces adicionales externas relevantes a la estructura para un control externo. Por ejemplo ' service_id ' puede ser un nombre/dirección
dentro de una estructura recibida o en una Librería de Interfaces 106 de red que incluya entradas procedentes del agente de soporte lógico de conformidad con las interfaces de dispositivo de los dispositivos conectados a la red. Por lo tanto, un usuario puede buscar un servicio dentro de la base de datos y accesar a una aplicación cuya interfaz incluya una ramificación de datos en particular de la librería, utilizando dicho nombre/dirección. Asi, la red puede incluir múltiples servicios idénticos distinguidos por la información de nombre/dirección. 'media ' , proporciona una interfaz para el tipo de medios que incluye, por ejemplo, al tren de transporte procedente de un sintonizador, memoria RAM procedente de una memoria DRAM de computadora personal, disco para un CD o DVD, y cinta Los medios pueden ser nombrados e identificados y un dispositivo controlador puede buscar la base de datos XCE para identificar los medios provistos actualmente sobre la red. Cuando se proporciona un nuevo medio tal como un disco de video digital DVD sobre la red, aquella porción de la interfaz del dispositivo 72 identifica al material de programa sobre el disco que esta siendo acordemente cambiado. Asi, la interfaz del dispositivo 72 completa no necesita ser transferida y solamente la porción relevante
transmitida hacia la base de datos XCE. Al recibir una señal de atención, el agente de soporte lógico de la librería 110 puede capturar la nueva actualización y colocarla en el lugar apropiado dentro de la Librería de Interfaces 106. La adición de medios en disco es similar a añadir un servicio a la red ó conectar otro aparato a la red. ' ra te ' , proporciona un valor para la razón de tren de datos de una interfaz del dispositivo, tal como 6 Mbits/seg ó 19.2 Mbits/seg, por ejemplo. 'protocol ' , identifica al protocolo utilizado para dicho tren de datos. Sí se proporciona más de un protocolo, por ejemplo 61883/1394 ó UDP/IP, entonces puede seleccionarse un protocolo deseado. ' stream_forma t ' , proporciona un formato de paquetes y/ó una norma de compresión para la división de audio y video en tren digital. Sí se proporciona más un formato, puede seleccionarse un formato deseado a través del mensaje de interfaz. Una aplicación controladora 82 puede examinar los formatos disponibles para determinar si existen formatos que sean compatibles. ' con trols_av ' , proporciona la interfaz principal de control para un aparato de medios A/V. ' Flow_con trol ' , proporciona controles de tren de datos tales como PLAY, STOP, GOTO, RECORD, etc., como
métodos de un dispositivo particular. Los métodos no cambian para un aparato incrustado, excepto por el soporte lógico de una PC, por ejemplo. Los controles pueden incluir parámetros de tiempo para operaciones retardadas. ' Tuning ' , proporciona una interfaz para el control de la sincronización. Un dispositivo controlador 14 puede enviar una petición a las interfaces un dispositivo controlado 14, para que envíe de vuelta la estructura de datos de la Guía de Programación Electrónica (EPG) descrita arriba. ' Ul con trol ' , proporciona una interfaz de control para una aplicación controlada 84, para controlar ajustes en el despliegue de la pantalla, tal como brillantez y contraste, asi como para audio, tal como volumen y bajos. ' Time_record ' , proporciona en interfaz para los datos de configuración de una aplicación controlada 82, para implementar grabación retardada en tiempo. Puede ser utilizada la información de sincronización de canal directa y la información de control de flujo ( tijpe_aparams) . La descripción anterior puede aplicar igualmente para dispositivos clientes 12. Puede ser utilizada una definición ó base de datos XCE de sintaxis alternativa
para el espacio CE. La base de datos XCE de sintaxis alternativa incluye descripciones de servicio completo que incluyen a la automatización de la casa, de aparatos y del automóvil, por ejemplo. En casos en donde un objeto de servicio proporcione flexibilidad y parámetros para controlar, es utilizado un método de control para controlar al objeto como sea deseado. Se muestran enseguida unos comandos de ejemplo en los lenguajes de comando AV/C y CAL incluyendo a cadenas de datos binarias y hexadecimales .
consumer (docutnent_fi .R, doc) + document_£ ile<server_horae . dtd, server_auto . dtd>
-. doc (avc commapds, cal commands, services_home , scrvcr_auto , server_samsung »eb_site, eerver_auto_f ord_explorer_98 , , ) + avc_co mands< ... command_string... > + cal_commands<. - . command_ctring...> + services_home (elient, av, lighting, comms, hvac, utility, security, appliance, convenience, , ) + xml_utility (download_DTD_£ iles, , ) + client (actaiowledge, attention, error, post_meeBage, sound, stop_schßdule, stop_all,,) + sound (alarm, ring, buzz,,) + server_av (source, sink) •i oource (aarvicß_id, media, rate, protocol, stream_for at, con rols_gen, controls_av, , ) . sink (service id, media, rate, protocol, stream_£orma , controls , , )
-serv?ce_id íurl, ,) -media (tpt_stream, ram, disk, tape,,) + disk (ñame, number, , ) -rate<value> -protocol (61883/1394. UDP/IP/Etheraet, , ) + 61883/1394 (isoch_ch_no) -stream_format (video, audio,,) + video (dv, m?eg2tpt, dsstpt. mpeg2pes, m?egl080i-tpt,) + audio (mpeg3( ac-3 , idi, , ) controle_gen (ping, process_info, setup, , ) controls av (flow control, tune, timer_recor , ui control, , ) +--— rocess_info (s/w_id, /w_id) + h/w_id (ser_no, manuf, model, class, , ) -t s/w_id (ser no, exe ñame, versión, , ) T setup (clock, , ) +_.--clock (hours, minutes, seconds) + time_record (tune, flow_con rol) + flow_control (play, stop, goto, + play ( time_paramB ) * record ( time_params ) _, tune (send_epg, chanpel,,) + channel (puber, id, time_parame, , ) + time_params {now, start, duration, end, , ) + ui_control (display, acoustic) + dieplay (brightness, contrast, colsr/tint, horiz_sÍ2e. vert_size,,) -acoustic (volume, base. treble, balance, f de, ) -lighting (screen, light, send_epg) + ßensors (living_room, sky, , ) lights (rooms_up, rooms_down, yard,,) + rooms_u? (bedl, bed2, bed3, bed4, , } + rooms_down ( amil , kichen, 1iving, dining, soho, garage, ,) + yard (Eront, back) + bedl (lap, dimmer, , ) + d3.mmer<valué> -comme (netmají, incercon, telco,) -t- netman (send_device_l 6t, send_configura ion,
send snmp mib, , ) + intercom () + telco 0 + hvac (controls_gen, controls_hvac, , ) + controls hvac (a/c, heat, temp, humidity, ) •. temp llo , high, hysteresis, , ) + utility (meters, energy gmt. , ) x meters (water, gas, electric,.) + ater<value>, gas<value>, electric-value. + security (sensors, send_epg, alram, , ) + sensors (peripheral, motion,,) 4...--peripheral (rooms_up, rooms_down, , ¡ + motion (rooms_down, yard,,) * applia-ices (microwave, range, over, fridge,
€reezer, coffee, toaster, washer, dryer, water-heater, , ) + microwave (send_epg, controls, , ) + fridge (temp, , ) + water-heater (temp) + convenience (window, curtain_open, door/gate, pool/spa, bath, fountain, lift, , ) 4 curtain_open <value> + server_auto (raessage, mileage, maintenance, , ) + mileage<date> maintenace<data>
En otro aspecto , la presente invención proporciona el uso de implementaciones de lenguaj e de comando existentes para el comando y control de di spositivo a disposit ivo dentro de una red .
Dispositivos pueden incluir obj etos internos y de interfaces API , las cuales al momento de correr, crean cadenas binarias de acuerdo con mecanismos de transporte existentes . En este caso, con el obj etivo de proporcionar llamadas del procedimiento remotas XML
(XMLRPC ) desde un dispos itivo 14 hacia otro dispos itivo
14 dentro de la red, la implementación de interfaz de aplicación saliente es reemplazada con llamadas a la interfaz API de servicio XML. Así, la implementación original es equivalente a un contenedor para la interfaz API de servicio. La Fig. 18 también muestra aplicaciones creadas utilizando otros lenguajes de comando tales como CAL ó AV/C en lineas punteadas, con sus implementaciones de interfaz reemplazadas con un contenedor dentro de la interfaz API de servicio XCE/XML. Ejemplos para cambiar de lenguaje de comando CAL al formato XMLRPC, se muestran enseguida. implementación existente: void DeviceCALCommand (int command) { /* créate CAL formatted byte string to represent this o-)]ect/method and output to the wire */ CreatCALFormattedBytestringlcommand) ;/* diferente para cada protocolo */ SendCALByestring() ; /* diferente para cada protocolo
conteniendo la llamada API de Servivio XML void DeviceCALCommand (int command) { { reemplazar la implemetacón CAL con llamadas al Servicio API XML */ CreateXMLMessage (coramand) ; /* siempre el mismo */ sendXMMessaqe () ; /* siempre el mismo */
Refiriéndonos a la Fig. 23, en otro aspecto, la presente invención proporciona una traducción de lenguaje de control y protocolo de comando estándar para la comunicación entre dispositivos, entre dispositivos dispares en una red. Para que diferentes dispositivos compartan información, la información debe encontrarse en un formato que pueda ser interpretado por un dispositivo que lo requiera. Así, para que un dispositivo 120 controle a otro dispositivo 22, los dos dispositivos deben usar un lenguaje común, con el objetivo de interpretar los comandos del otro. La presente invención proporciona un formato de identificación común para protocolos de datos y comandos . En una modalidad, se proporciona un método de presentación ó empaquetado de datos y protocolo de comandos común, en donde un dispositivo receptor 122 puede determinar el formato nativo de los datos transmitidos. Sí el dispositivo receptor 122 puede interpretar ese formato nativo, entonces éste podrá aceptar directamente los datos. De otra manera, el dispositivo receptor 122 puede hacer una petición a un dispositivo ó aplicación traductora 124, para traducir los datos en un formato deseado, el cual pueda interpretar al dispositivo solicitante 122. El
dispositivo traductor 124 o aplicación, determina el formato nativo de los datos originales, traduce los datos en el formato deseado y envía los datos traducidos al dispositivo solicitante 122. El dispositivo solicitante 122 procesa entonces los datos, como los datos que habían sido provistos originalmente en el formato de lenguaje nativo del dispositivo solicitante por medio del dispositivo emisor 120 El dispositivo solicitante 122 también puede enviar una respuesta de vuelta al dispositivo emisor 120 en el formato nativo del dispositivo solicitante, o enviar una respuesta por medio de un servidor poderhabiente (proxy) a través del dispositivo traductor 124 o aplicación, para traducirla en el formato nativo del dispositivo emisor 120. El método de traducción puede ser utilizado para información, incluyendo al protocolo de comando, los archivos de datos y los trenes de audio/video. Para dispositivos que no utilicen el formato común descrito arriba, la presente invención proporciona la traducción de datos, incluyendo a protocolos de comando hacia y desde tales dispositivos no compatibles. Por ejemplo, cuando un dispositivo no compatible 120 envía datos a un dispositivo compatible 122, el dispositivo compatible 122 puede traducir los datos en base a la determinación del formato nativo de los datos.
Por ejemplo, el dispositivo compatible 122 puede examinar los datos en patrones binarios particulares dentro de los datos. Cuando un dispositivo compatible envía datos a un dispositivo no compatible conocido, el dispositivo compatible puede traducir los datos antes de la transmisión, basándose en la determinación del formato nativo del dispositivo no compatible. Una implementación de ejemplo puede ser una red de casa que soporte a protocolos IP y HTTP. La red de casa puede estar conectada a la Internet para obtener aplicaciones y servicios de varios tipos deseados de funcionalidad. Como tal, el método en formato común puede ser convertido a compatible con los protocolos de Internet y con el procedimiento de operación sobre la Internet y la red de casa. Un ejemplo de proporcionar un formato de datos común es utilizar XML para crear un paquete de datos que se transmita sobre la red de casa. Los datos pueden incluir al protocolo de comandos, trenes de audio ó video, gráficas ó aplicaciones. Los datos son 'contenidos' con un encabezado estándar que identifique al formato nativo de los datos y el contenido del paquete, en forma XML. El encabezado permite la identificación única del tipo de datos, la porción de datos del código XML, en donde los datos pueden ser
traducidos si es necesario y provistos a las aplicaciones apropiadas en su recepción. Según la normatividad de la Web, el proceso de críticas es efectuado por navegadores que utilizan extensiones de nombre del archivo, para identificar el tipo y contenido de una transmisión de archivos. Los marcadores pueden entonces lanzar módulos pl ug-in apropiados para procesar el archivo. En la red de casa, se utiliza XML para notificar las transmisiones de datos que proporcionan a todas las transmisiones de la red en casa, sobre el protocolo de Internet (IP) con un método de identificación común, como el que ha sido descrito anteriormente . Alternativamente, puede proporcionarse una capa de soporte lógico dentro de la pila de protocolo de la red de casa, para identificar únicamente al contenido de todas las transmisiones de datos que pasen sobre la red de casa. La capa de soporte lógico puede ser utilizada en lugar de XML. El formato común y los principios de identificación de la presente invención, aplican igualmente en cualquier modalidad que utilice XML ó la capa de soporte lógico, como método de identificación. En la Fig. 23, a la recepción de una transmisión de paquete de datos, el dispositivo receptor 122 examina el encabezado de identidad XML del paquete de datos,
para determinar el formato de los datos que se encuentran dentro de este. Si los datos se encuentran en un formato reconocible por el dispositivo 122, la información del encabezado de identidad XML es desechada y el dispositivo procesa directamente los datos. De otra manera, el dispositivo 122 convierte al paquete XML recibido en un paquete de petición de traducción XML y lo envía junto con los datos hacia el dispositivo servidor de traducción 124. El dispositivo servidor de traducción 124 traduce los datos y los convierte en un paquete de respuesta de traducción XML El servidor traductor 124 transmite entonces el paquete de respuesta, de vuelta al dispositivo solicitante 122 En caso de un error de traducción, el servidor de traducción 124 puede proporcionar una condición de error de respuesta de traducción al dispositivo solicitante 122. Al recibir los datos traducidos, el dispositivo solicitante 122 procesa los datos traducidos en el paquete de respuesta.
Un ej emplo de un paquete de datos XML puede ser : <IDENTITY type=format=AV/c> datos en paquete </IDENTITY>
Un ej emplo de paquete de pet ición de traducción puede ser : <TRANSLATION REQUEST TYPE=Command for mat=CAL> <IDENTITY type=Command format=AV/c>...datos en paquete.. ,</IDENTITY> </TRANSLATION REQUEST>
Un ej emplo de un paquete de petición de traducción puede ser : <TRANSLATION RESPONSE type=Command format=CAL>...datos en paquete... </TRANSLATION RESP0NSE>
Un ej emplo de un paquete de condición de error de respuesta de traducción puede ser : <TRANSLATION RESPONSE type=Command format=CAL>... datos en paquete... <ERROR Condit¡on=Unrecognized Command>La traducción no puedo haber sido efectuada</ERROR> < TRANSLATION RESPONSE>
Adicionalmente , la Tabla 3 de la Fig . 24 incluye una lista parcial de tipos y formatos de paquetes .
•.. .Js.
Para proporcionar servicios de traducción, un servidor traductor 124 está identificado dentro de la red durante la configuración de la red de una manera similar a los servidores DHCP. El servidor de traducción 124 radiodifunde su dirección IP a todos los dispositivos que se encuentren en la red, por un periodo de tiempo después de que la red es configurada. Todos los dispositivos 120, 122 compatibles con los servicios de traducción, almacenan la dirección IP del servidor de traducción 124, mientras que este se radiodifunde sobre la red, durante la inicialización de la red. Alternativamente, el dispositivo solicitante 122 puede emitir una petición de traducción sobre la red de casa. Todos los servidores de traducción 124 dentro de la red que reciban la petición de traducción, pueden responder a la petición de traducción por medio de enviar una respuesta de traducción al dispositivo solicitante 122. El dispositivo solicitante 122 selecciona entonces un servidor de traducción 124 entre los servidores de traducción que contestan. En un ejemplo, el dispositivo solicitante 122 selecciona al primer servidor de traducción 124 que responda a la petición de traducción. En otro ejemplo, los servidores de traducción 124 pueden negociar entre sí mismos y/ó con el dispositivo solicitante 122, para seleccionar un
servidor de traducción 124 que satisfaga la petición de traducción . En otra modalidad de la invención, son utilizados múltiples servidores de traducción para satisfacer todas las peticiones de traducción. Por ejemplo, un solo servidor de traducción 124 puede no tener la capacidad de traducir todas las peticiones. En dichos casos, es necesario identificar la dirección de cada servidor de traducción 124 y el tipo de servicio de traducción que cada servidor de traducción 124 puede proporcionar. Cada dispositivo 120, 122 puede almacenar una lista de todas las direcciones IP de los servidores de traducción y una lista correspondiente de los tipos de servicios de traducción que cada servidor de traducción 124 proporcione y opcionalmente la aplicación de traducción asociada. Para propósitos de eficiencia, si un dispositivo emisor 120 desea envía datos a un dispositivo receptor 122, el cual se conoce que utiliza un formato nativo diferente al dispositivo emisor 120, el dispositivo emisor 120 puede enviar los datos al dispositivo receptor 122 mediante proxy, a través de un servidor de traducción 124. El dispositivo emisor 120 transmite un comando dispositivo traductor 124, similar al comando de petición de traducción e incluir la dirección del
dispositivo receptor 122, como el destinatario de los datos traducidos. En casos en donde un dispositivo receptor 122 requiera de la traducción de un tren de datos, el dispositivo emisor 120 puede enrutar al tren de datos directamente al servidor de traducción 124 y el servidor de traducción 124 su vez, transmite los datos traducidos al dispositivo receptor 122, como ha sido descrito anteriormente. Alternativamente, el dispositivo emisor 120 puede enviar el tren de datos al dispositivo receptor 122 y el dispositivo receptor 122 enruta entonces el tren de datos hacia el servidor de traducción 124 para traducir y regresar los datos traducidos de vuelta al dispositivo receptor 122. En la presente descripción, el mecanismo de control está basado en el Protocolo de Transferencia de Hiper Texto (HTTP 1.1) el cual proporciona un protocolo de nivel de aplicación para sistemas de información distribuidos, colaborativos de hipermedios. HTTP es un protocolo genérico, sin estado, orientado a objetos con un amplio uso en muchas tareas. Una característica de HTTP es la marcación y negociación de la representación de los datos, permitiendo que sean construidos independientemente sistemas de los datos que se transfieran. Preferentemente, el protocolo de red
utilizado por servicios y aplicaciones sobre la red de casa es el Protocolo de Internet (IP). Sin embargo, pueden ser utilizados otros protocolos. A pesar de que la invención ha sido descrita en detalle considerable con respecto a las versiones preferidas de ésta, son posibles otras versiones.
Consiguientemente, las reivindicaciones anexas no deben ser limitadas a las descripciones de las versiones preferidas contenidas aquí. Se hace constar que, con lo relativo a esta fecha, el mejor método conocido por la solicitada, para llevar a cabo la presente invención, es el que resulta claro a partir de la presente, descubriéndose la invención . Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes .
Claims (1)
- REIVINDICACIONES Un método para el comando y control entre una pluralidad de dispositivos a través de una red, el método caracterizado porque comprende: (a) conectar un primer dispositivo a la red; (b) conectar un segundo dispositivo la red, el segundo dispositivo almacenando datos de descripción de interfaz de aplicación en un formato estructural para comandar y controlar al segundo dispositivo por medio de, al menos, otro dispositivo conectado a te) proporcionar dichos datos de descripción de la interfaz de aplicación al primer dispositivo que se encuentra sobre la red; y (d¡ enviar datos de comando y control desde el primer dispositivo hasta el segundo dispositivo que se encuentra sobre la red, utilizando dichos datos de descripción de la interfaz de aplicación para controlar la operación del segundo dispositivo. El método de conformidad con la reivindicación 1, caracterizado porque el paso (c) incluye localizar a los datos de descripción de la interfaz de aplicación a través de la red y proporcionar dichos datos de descripción de la interfaz de aplicación al primer dispositivo, a través de la red. El método de conformidad con la reivindicación 1, caracterizado porque: (i) el paso (b) incluye conectar dos ó más dispositivos a la red, cada dispositivo almacenando datos de descripción de la interfaz de aplicación en el formato estructurado para comandar y controlar el dispositivo por medio de uno ó más dispositivos conectados a la red; (ii) el paso (c) incluye proporcionar los datos de descripción de la interfaz de aplicación de una pluralidad de dispositivos al primer dispositivo, a través de la red; y (iii) el paso (d) incluye enviar datos de comando y control desde el primer dispositivo hasta la pluralidad de dispositivos que se encuentra sobre la red, utilizando los datos de descripción de la interfaz de aplicación correspondientes a cada uno de la pluralidad de dispositivos, para controlar la operación de la pluralidad de dispositivos. El método de conformidad con la reivindicación 3, caracterizado porque el paso (ii) incluye localizar los datos de descripción de la interfaz de aplicación a través de la red y proporcionar dichos datos de descripción de la interfaz de aplicación al primer dispositivo, a través de la re . El método de conformidad con la reivindicación 3, caracterizado porque el paso (ii) incluye adicionalmente proporcionar los datos de interfaz de aplicación de una pluralidad de dispositivos a, por lo menos, el primer dispositivo y en donde el paso (iii) incluye enviar datos de control comando desde por lo menos el primer dispositivo, hasta una pluralidad de dispositivos conectados a la red, utilizando los datos de descripción de la interfaz de aplicación, correspondientes a cada uno de la pluralidad de dispositivos, para controlar la operación de, al menos, la pluralidad de dispositivos. El método de conformidad con la reivindicación 1, caracterizado porque el paso (c) incluye transferir por lo menos una porción de los datos de descripción de la interfaz de aplicación hacia el primer dispositivo domestico, a través de la red. El método de conformidad con la reivindicación 1, caracterizado porque el paso (c) incluye que el primer dispositivo consulte los datos de descripción de la mterfaz de aplicación dentro del segundo dispositivo, a través de la red. El método de conformidad con la reivindicación 1, caracterizado porque el paso (c) incluye que el primer dispositivo consulte la descripción de la interfaz de aplicación desde un dispositivo de base de datos, conectado a la red. El método de conformidad con la reivindicación 1, caracterizado porque los datos de descripción de la interfaz de aplicación incluyen la información de llamada de procedimiento remoto, para que el primer dispositivo domestico controle la operación del segundo dispositivo domestico. El método de conformidad con la reivindicación 1, caracterizado porque los datos de descripción de la interfaz de aplicación incluyen unos datos de capacidad para identificar las capacidades del segundo dispositivo. El método de conformidad con la reivindicación 1, caracterizado porque los dispositivos no son capaces de desplegar interfaces el usuario. El método de conformidad con la reivindicación 1, caracterizado porque el formato estructurado incluye al formato XML. Un sistema de red para comandar y controlar dispositivos, caracterizado porque comprende: (a) una capa física, en donde la capa física proporciona un medio de comunicación que puede ser utilizado por dispositivos, para que se comuniquen entre si; (b) por lo menos un dispositivo controlado que contenga datos de descripción de la interfaz de aplicación en un formato estructurado, para comandar y controlar al dispositivo controlado por medio de, al menos, un dispositivo diferente; y (c) por lo menos un dispositivo controlador que incluya medios de aplicación de control para obtener los datos de descripción de la interfaz de aplicación y enviar datos de control y comando al dispositivo controlado, utilizando dichos datos de descripción de la interfaz de aplicación, para controlar la operación del dispositivo controlado . 14. El sistema de red de conformidad con la reivindicación 13, caracterizado porque comprende una pluralidad de dispositivos controlados, cada dispositivo controlado almacenando datos de descripción de la interfaz de aplicación en el formato estructurado, para comandar y controlar- a cada uno de los dispositivos controlados por medio de, al menos, el dispositivo controlador, en donde los medios de control de aplicación obtienen selectivamente los datos de descripción de la interfaz de aplicación de uno ó más dispositivos controlados, para enviar datos de comando y control a uno ó más de los dispositivos controlados, utilizando los datos de descripción de la interfaz de aplicación, para controlar la operación de uno ó más dispositivos controlados. 15. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los medios de control de aplicación obtienen los datos de descripción de la interfaz de aplicación por medio de transferir, al menos, una porción de los datos de descripción de la interfaz de aplicación hacia el dispositivo controlador, para generar y enviar datos de control y comando hacia el dispositivo controlado . 16. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los medios de control de aplicación obtienen los datos de descripción de la interfaz de aplicación, por medio de consultar los datos de descripción de la interfaz de aplicación dentro del dispositivo controlado . 17. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los medios de control de aplicación obtienen los datos de descripción de la interfaz de aplicación por medio de consultar los datos de aplicación de la interfaz de aplicación, desde un dispositivo de base de datos. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los datos de descripción de la interfaz de aplicación incluyen información de llamada de procedimiento remoto, para que el dispositivo controlador controle la operación del dispositivo controlado. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los datos de descripción de la interfaz de aplicación incluyen datos de capacidades para identificar las capacidades del dispositivo controlado. El sistema de red de conformidad con la reivindicación 13, caracterizado porque los dispositivos controladores y controlados no son capaces de desplegar interfaces del usuario. El sistema de red de conformidad con la reivindicación 13, caracterizado porque el formato estructurado incluye al formato XML. El sistema de red de conformidad con la reivindicación 13, caracterizado porque comprende adicionalmente una pluralidad de dispositivos controladores, cada dispositivo controlador incluyendo unos medios de control de aplicación para obtener los datos de descripción de la interfaz de aplicación de uno ó más dispositivos controladores, para enviar información de comando y control hacia uno ó más dispositivos controlados, utilizando los datos de descripción de la interfaz de aplicación, para controlar la operación de uno ó más dispositivos controlados. Un método para efectuar un servicio a través de una red de casa, el método caracterizado porque comprende los pasos de: (a) conectar un dispositivo cliente a ia red de casa, en donde el dispositivo cliente es capaz de desplegar datos de interfaz del usuario; (b) conectar un primer dispositivo doméstico a la red de casa, el primer dispositivo doméstico almacenando datos de interfaz del usuario en un formato seleccionado que defina una mterfaz del usuario para que el usuario comande y controle, por lo menos, al primer dispositivo doméstico por medio de la red; (c) conectar un segundo dispositivo doméstico a la red de casa, el segundo dispositivo doméstico almacenando datos de descripción de la interfaz de aplicación en un formato estructurado, para el comando y control de dispositivo del segundo dispositivo doméstico, por medio de uno ó más dispositivos domésticos conectados a la red; (d) recibir los datos de interfaz del usuario del primer dispositivo doméstico en el dispositivo cliente, a través de la red de casa; (e) desplegar la interfaz del usuario definida por los datos de la interfaz del usuario del primer dispositivo doméstico, sobre el dispositivo cliente; (f) aceptar entradas del usuario de un usuario, en respuesta a que el usuario interactúe con la interfaz del usuario desplegada sobre el dispositivo cliente; y (g) enviar datos de control y comando desde el dispositivo cliente hasta el primer dispositivo doméstico, basándose en la entrada del usuario, para provocar que los primero y segundo dispositivos domésticos se comuniquen entre sí, utilizando los datos de descripción de la interfaz de aplicación para efectuar el servicio. El método de conformidad con la reivindicación 23, caracterizado porque el paso (f) incluye adicionalmente aceptar la entrada del usuario para seleccionar al segundo dispositivo domestico desde la interfaz del usuario que esta siendo desplegada sobre el dispositivo cliente. El método de conformidad con la reivindicación 24, caracterizado porque incluye adicionalmente el paso de que el primer dispositivo domestico controle al segundo dispositivo domestico por medio de enviar información de control y comando hacia el segundo dispositivo domestico, utilizando los datos de descripción de la interfaz de aplicación, basándose en entrada del usuario al primer dispositivo domestico a través del dispositivo cliente. El método de conformidad con la reivindicación 26, caracterizado porque comprende adicionalmente el paso de proporcionar los datos de descripción de la interfaz de aplicación al primer dispositivo domestico a través de la red El método de conformidad con la reivindicación 23, caracterizado porque los datos de descripción de la interfaz de aplicación, incluyen datos de las capacidades del segundo dispositivo doméstico y porque comprende adicionalmente los pasos de: (i) consultar los datos de capacidades dentro de los datos de descripción de la interfaz de aplicación del segundo dispositivo doméstico, y (ii) actualizar los datos de la interfaz del usuario dentro del primer dispositivo doméstico, utilizando los datos de capacidades para permitir el comando y control del segundo dispositivo doméstico mediante un usuario, a través de la interfaz del usuario del primer dispositivo doméstico desplegado sobre el dispositivo cliente. El método de conformidad con la reivindicación 23, caracterizado porque comprende adicionalmente conectar dos ó más dispositivos a la red, cada dispositivo doméstico almacenando datos de descripción de la interfaz de aplicación en un formato estructurado para comandar y controlar al dispositivo doméstico por medio de uno ó más dispositivos domésticos conectados a la red. El método de conformidad con la reivindicación 28, caracterizado porque los datos de la interfaz de aplicación dentro de cada uno de los dos o mas dispositivos domésticos, incluyen datos de capacidades para el dispositivo domestico respectivo y porque comprende adicionalmente los pasos de: (i) consultar los datos de capacidades dentro de los datos de la interfaz de aplicación de los dos o mas dispositivos domésticos, y (11) actualizar los datos de la interfaz del usuario dentro del primer dispositivo domestico, utilizando los datos de capacidades para permitir el comando y control de dos o mas dispositivos domésticos por medio de un usuario, a través de la interfaz del usuario del primer dispositivo domestico desplegado sobre el dispositivo cliente. 30. El método de conformidad con la reivindicación 28, caracterizado porque incluye adicionalmente el paso de proporcionar las descripciones de la interfaz de aplicación de una pluralidad de los dos o mas dispositivos domésticos, al primer dispositivo domestico a través de la red. 31. El método de conformidad con la reivindicación 30, caracterizado porque incluye adicionalmente el paso de: enviar datos de control y comando desde el primer dispositivo domestico hasta la pluralidad de dispositivos domésticos a través de la red, utilizando los -datos de descripción de la interfaz de aplicación correspondientes a cada uno de la pluralidad de dispositivos domésticos, para controlar la operación de la pluralidad de los dispositivos domésticos. 32. El método de conformidad con la reivindicación 30, caracterizado porque incluye adicionalmente el paso de: localizar las descripciones de la interfaz de aplicación sobre la red, y proporcionar dichas descripciones de la interfaz de aplicación al primer dispositivo doméstico, a través de la red. 33. El método de conformidad con la reivindicación 30, caracterizado porque incluye adicionalmente los pasos de proporcionar los datos de descripción de la interfaz de aplicación de un dispositivo doméstico de la pluralidad de dispositivos domésticos, a otro dispositivo doméstico de la pluralidad de los dispositivos domésticos. 34. El método de conformidad con la reivindicación 33, caracterizado porque incluye adicionalmente enviar datos de comando y control desde un dispositivo doméstico hasta otro dispositivo doméstico a través de la red, utilizando la descripción de la interfaz de aplicación correspondiente al otro dispositivo doméstico, para controlar la operación del otro dispositivo doméstico. 35. El método de conformidad con la reivindicación 23, caracterizado porque la descripción de la interfaz de aplicación incluye la información de llamada de procedimiento remoto para que el primer dispositivo doméstico controle la operación del segundo dispositivo doméstico. 36. El método de conformidad con la reivindicación 35, caracterizado porque la descripción de la interfaz de aplicación incluye los datos de capacidades para identificar las capacidades del segundo dispositivo . 37. El método de conformidad con la reivindicación 23, caracterizado porque el formato seleccionado incluye al formato HTML. 38. El método de conformidad con la reivindicación 23, caracterizado porque el formato estructurado incluye al formato XML. 39. Un sistema de red para comandar y controlar dispositivos, caracterizado porque comprende: (a) una capa física, en donde la capa física proporciona un medio de comunicación que puede ser utiM-zado por dispositivos para comunicarse entre sí; (b) un primer dispositivo servidor que almacene datos de la interfaz del usuario en un formato seleccionado que defina una interfaz del usuario para el comando y control del usuario mediante un usuario de, por lo menos, el primer dispositivo; (c) un segundo dispositivo servidor que almacene datos de descripción de la interfaz de aplicación en un formato estructurado para el comando y control de dispositivos del segundo dispositivo servidor por medio de uno ó más dispositivos; (d) un dispositivo cliente capaz de desplegar datos de la interfaz del usuario, el dispositivo cliente incluyendo un controlador de interfaz del usuario para desplegar la interfaz del usuario del primer dispositivo servidor sobre el dispositivo cliente, para aceptar entradas de un usuario y para enviar datos de comando y control hacia el primer dispositivo servidor basándose en la entrada del usuario, para provocar que los primero y segundo dispositivos servidores se comuniquen entre sí, utilizando los datos de descripción de la interfaz de aplicación para efectuar un servicio requerido por el usuario. 40. El sistema de red de conformidad con la reivindicación 39, caracterizado porque el controlador de la interfaz del usuario acepta entradas del usuario para seleccionar al segundo dispositivo servidor desde una interfaz del usuario, que esté siendo desplegada sobre el dispositivo cliente. 41. El sistema de red de conformidad con la reivindicación 40, caracterizado porque el primer dispositivo servidor incluye unos medios de control de aplicación para controlar al segundo dispositivo servidor, por medio de enviar información de control y comando al segundo dispositivo servidor, utilizando los datos de descripción de la interfaz de aplicación, basándose en la entrada del usuario, al primer dispositivo servidor a través del dispositivo cliente. El sistema de red de conformidad con la reivindicación 41, caracterizado porque los medios de control de aplicación obtienen los datos de descripción de la interfaz de aplicación a partir del segundo dispositivo servidor. El sistema de red de conformidad con la reivindicación 40, caracterizado porque los medios de control de aplicación obtienen los datos de descripción de la interfaz de aplicación a partir de una base de datos. El sistema de red de conformidad con la reivindicación 39, caracterizado porque los datos de descripción de la interfaz de aplicación incluyen a datos de capacidades para el segundo dispositivo servidor, y en donde los medios 'de control de aplicación obtienen los datos de capacidades a partir de los datos de descripción de la interfaz de aplicación y asi, actualice los datos de la interfaz del usuario dentro del primer dispositivo doméstico, utilizando los datos de capacidades para permitir el comando y control del segundo dispositivo servidor por medio de un usuario, a través de la interfaz del usuario del primer dispositivo servidor desplegado sobre el dispositivo cliente. *aSt -&•*"--- El sistema de red de conformidad con la reivindicación 39, caracterizado porque comprende adicionalmente dos ó más dispositivos servidores, cada uno almacenando datos de descripción de la interfaz de aplicación en un formato estructurado para comandar y controlar a los dos ó más dispositivo servidores, por medio de uno ó más dispositivos . El sistema de red de conformidad con la reivindicación 45, caracterizado porque los datos de la interfaz de aplicación dentro de cada uno de los dos ó más dispositivos servidores, incluyen datos de capacidades para el dispositivo servidor respectivo, y en donde los medios de control de aplicación obtienen los datos de capacidades a partir de los datos de la interfaz de aplicación de los dos ó más dispositivos servidores y así, actualice la interfaz del usuario dentro del primer dispositivo servidor utilizando los datos de capacidades para permitir el comando y control de dos ó más dispositivos servidores por medio de un usuario, a través de la interfaz del usuario del primer dispositivo servidor desplegado sobre el dispositivo cliente. 47. El sistema de red de conformidad con la reivindicación 45, caracterizado porque los medios de control de aplicación envían datos de control y comando hacía los dos ó más dispositivos servidores, utilizando los datos de descripción de la interfaz de aplicación correspondientes para cada uno de los dos ó más dispositivos servidores, para controlar la operación de los dos ó más dispositivos servidores. 48. El sistema de red de conformidad con la reivindicación 39, caracterizado porque los datos de descripción de la mterfaz de aplicación incluyen la información de llamada de procedimiento remoto para que el primer dispositivo servidor controle la operación del segundo dispositivo servidor. 49. El sistema de red de conformidad con la reivindicación 39, caracterizado porque el formato seleccionado incluye al formato HTML. 50. El sistema de red de conformidad con la reivindicación 39, caracterizado porque el formato seleccionado incluye al formato XML.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US60/084,578 | 1998-05-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| MXPA00010917A true MXPA00010917A (es) | 2001-07-31 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU758868B2 (en) | Method and apparatus for universally accessible command and control information in a network | |
| US7043532B1 (en) | Method and apparatus for universally accessible command and control information in a network | |
| KR100316632B1 (ko) | 홈 네트웍을 위한 프로그래밍 툴 | |
| EP1394986B1 (en) | Service gateway for controlling audio/video devices in a local network | |
| MXPA00010917A (es) | Metodo y sistema para el comando y control de dispositivo a dispositivo dentro de una red | |
| MXPA00010914A (es) | Metodo y aparato para informacion de comando y control universalmente accesible dentro de una red | |
| MXPA00010915A (es) | Metodo y aparato para el comando y control de usuario y dispositivo dentro de una red |