MXPA06009479A - Metodo para suministrar contenido a un dispositivo - Google Patents

Abstract

Se describe un método para entregar actualizaciones de contenido para interfaces de usuario a dispositivos;los datos de contenido comprenden metadatos que determinan la forma en que se entregan las actualizaciones a los datos de contenido, por ejemplo, ubicaciones de las actualizaciones, la frecuencia a la que se tiene acceso a las actualizaciones, etc;los metadatos también pueden ubicar un recurso de datos adicional, tal como una base de datos, que almacena la ubicación de las actualizaciones de datos de contenido.

Description

MÉTODO PARA SUMINISTRAR CONTENIDO A UN DISPOSITIVO CAMPO DE LA INVENCIÓN La presente invención se refiere a un método para suministrar contenido a un dispositivo, y en particular a un método para suministrar contenido a dispositivos móviles utilizando una red de comunicaciones móviles.

ANTECEDENTES DE LA INVENCIÓN Una de las áreas en crecimiento para los operadores de redes móviles y proveedores de contenido es el aprovisionamiento de tonos, fondos de papel tapiz, y otro contenido de multimedia para teléfonos y dispositivos móviles. Existe una tensión entre las necesidades de los operadores de red móvil y los fabricantes de dispositivos para conservar el control sobre algunos aspectos de las interfaces de usuario de los dispositivos para propósitos de marcado y las necesidades de los usuarios para personalizar y modificar la apariencia de sus dispositivos y que se ajusten a sus propias necesidades. El software sofisticado que se requiere para proveer la flexibilidad y personalización deseadas también está en tensión con la potencia de procesamiento y la capacidad de almacenamiento de datos limitadas de los dispositivos móviles típicos. La presente invención busca mitigar estos problemas.

SUMARIO DE LA INVENCIÓN De acuerdo con un primer aspecto de la presente invención, se provee un método para recibir datos de contenido para una interfaz de usuario a un dispositivo, el método comprende los pasos para que: el dispositivo reciba datos de contenido para una interfaz de usuario desde una interfaz de comunicaciones; el dispositivo procese los datos de contenido recibidos para formar una interfaz de usuario para el dispositivo; en donde los datos de contenido comprenden metadatos y el método comprende el paso adicional donde el dispositivo tiene acceso a las actualizaciones de los datos de contenido a través de la interfaz de comunicaciones de acuerdo con los metadatos de los datos de contenido. De acuerdo con un segundo aspecto de la presente invención, se provee una portadora de datos que comprende un código ejecutable por computadora para realizar el método antes descrito. De acuerdo con un tercer aspecto de la presente invención, se provee un dispositivo que comprende: una interfaz de usuario; un medio de pantalla para desplegar la interfaz de usuario; una interfaz de comunicaciones para recibir los datos de contenido para uso en la interfaz de usuario y medios de procesamiento para procesar los datos de contenido recibidos para formar la interfaz de usuario, en donde los datos de contenido comprenden metadatos y el dispositivo está configurado para tener acceso a las actualizaciones de los datos de contenido a través de la interfaz de comunicaciones, de acuerdo con los metadatos de los datos de contenido.

BREVE DESCRIPCIÓN DE LAS FIGURAS La figura 1 muestra una representación esquemática de un sistema que incorpora la presente invención; La figura 2 muestra con mayor detalle la estructura y operación del servidor 100; La figura 3 muestra una representación esquemática del software para los dispositivos móviles; La figura 4 muestra una representación esquemática del conjunto de herramientas de contenido 200; y La figura 5 muestra una representación esquemática de un dispositivo que comprende una interfaz de usuario de acuerdo con una modalidad de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Ahora se describirá la invención a manera de ilustración únicamente y con respecto a las figuras anexas, en donde la figura 1 muestra una representación esquemática de un sistema que incorpora la presente invención. El sistema comprende el servidor 100, el conjunto de herramientas de contenido 200, los dispositivos móviles 300, los sistemas de soporte operativo (OSS) 700, las alimentaciones de contenido 500 y las fuentes de interfaz de usuario (Ul) 600. En uso, el servidor 100 comunica datos de contenido y datos ÜI a los dispositivos móviles 300, 301, ..., cada uno de los cuales comprende el paquete de software 400. El servidor 100 se conecta en interfaz con OSS 700, en donde los OSS son aquellos convencionalmente utilizados para operar redes móviles, por ejemplo, facturación, administración de cuentas, etc. El servidor 100 además se conecta en interfaz con el conjunto de herramientas de contenido 200: el conjunto de herramientas de contenido recibe los datos de las fuentes Ul 600, 601, ..., y empaqueta los datos Ul para que el servidor pueda transmitir los datos Ul empaquetados a los paquetes de software 400 comprendidos dentro de los dispositivos móviles 300. El servidor recibe los datos de una pluralidad de alimentaciones de contenido, y estos datos son procesados y empaquetados para que puedan ser enviados a los paquetes de software 400 o para que los dispositivos móviles 300 puedan tener acceso a los datos utilizando el paquete de software 400. El sistema se puede contemplar como dividido en tres dominios separados: el dominio de operador 50 comprende los sistemas y equipo operados por el operador de red móvil (MNO) ; el dominio de usuario 60 comprende una pluralidad de dispositivos móviles y el dominio de terceros 70 comprende las alimentaciones de contenido y las alimentaciones Ul que pueden ser controladas u operadas por un número de diferentes entidades. La figura 2 muestra con mayor detalle la estructura y operación del servidor 100. El servidor 100 comprende el componente editorial 110 y el componente de servidor de contenido 150. El componente editorial comprende la base de datos 111, la cola de importaciones 112, la interfaz del conjunto de herramientas de contenido 113, la interfaz de usuario 114 y el catálogo 115. En operación, el componente editorial recibe contenido del conjunto de herramientas de contenido en la interfaz del conjunto de herramientas de contenido. El contenido es presentado en la forma de un paquete 210A, 20B, ..., (ver a continuación) que comprende uno o más Trigs y uno o más Triglets. Un Trig es una interfaz de usuario para un dispositivo móvil, tal como un teléfono móvil y un Triglet es un archivo de datos que se puede utilizar para extender o alterar un Trig. Si un paquete comprende más de una interfaz Trig, entonces una de las interfaces Trig puede ser una interfaz Trig maestra desde la cual se deriven otras interfaces Trig. La interfaz de usuario del componente editorial 114 se puede utilizar para importar un paquete a la base de datos 111, y este procedimiento ocasiona que las referencias a cada Trig y Triglet se carguen a la cola de importaciones 114, la cual puede comprender referencias a una pluralidad de paquetes 210a, 210b,... . El contenido del paquete se puede examinar utilizando la interfaz de usuario y el contenido del paquete se puede pasar al catálogo. El MNO puede tener varios dominios editoriales, por ejemplo uno para cada servidor objetivo en un número de países o regiones. Cada dominio es tratado de manera aislada de otros dominios y tiene su propio esquema editorial que describe la forma en que se van a publicar los objetos en los servidores de contenido tanto en ambientes en vivo como en ambientes de inmigración. El componente editorial GUI provee varias vistas diferentes para cada dominio, permitiendo a los operadores gestionar completamente la publicación del contenido. El catálogo comprende referencias a las interfaces Trig almacenadas en el catálogo y los canales de actualización y canales de alimentación utilizados para transferir contenido a los diversos dominios. Para cada dominio, el operador utiliza el componente editorial GUI para establecer la estructura de dominio y asignar las interfaces Trig a partir del catálogo a cada nodo de dominio. Para ayudar al operador en la selección de las interfaces Trig de manera eficiente, se provee un filtro en el catálogo de manera que solo se muestran las secciones relevantes. Una interfaz Trig se puede asignar a varios nodos dentro de un dominio. En cada caso, el empaque de la interfaz Trig en el servidor objetivo puede requerir ser diferente, por ejemplo, un archivo SIS o CAB, dependiendo de los equipos a los que tendrán acceso las interfaces Trig. El empaque se puede controlar utilizando el componente editorial GUI . Los canales de actualización pueden ser referenciados por las interfaces Trig para controlar la entrega del contenido. Un canal de actualización comprende un URL, el cual es un vínculo a un recurso en el dominio asociado que comprende un paquete de actualización de archivo Triglet. El URL se puede registrar a intervalos predefinidos y la función http GET se puede utilizar para tener acceso al paquete (se apreciará fácilmente que se pueden utilizar otros esquemas de transporte, por ejemplo SyncML o SMS o difusión celular para actualizaciones pequeñas) . El paquete de actualización del archivo Triglet describe la forma en que se puede modificar la interfaz Trig, por ejemplo, reemplazando una o más imágenes o archivos de texto empleados por la interfaz Trig. El componente editorial GUI permite a un operador definir y controlar los canales de actualización que existen para un dominio, los URL asociados con cada archivo Triglet en el canal de actualización y la asociación de los archivos Triglet con los canales de actualización para un dominio. Debido a que cada archivo Triglet está asociado con un canal de actualización, un operador puede ingresar la fecha y hora en que se debería publicar la actualización, permitiendo que se establezca un programa. Se tiene acceso a una alimentación de contenido por medio del registro de un URL, recuperando el paquete actualizado y aplicándolo a la interfaz Trig. Sin embargo, debido a la diferente naturaleza de las actualizaciones de los archivos Triglet manualmente construidos y del contenido automáticamente generado, los canales de actualización y las alimentaciones de contenido se gestionan por separado. Una vez más, se pueden utilizar otros esquemas de transporte tal como SyncML o OMA-DM (Gestión de Dispositivo de Alianza Móvil Abierta) . El componente editorial GUI permite al operador definir cuáles alimentaciones de contenido deberían estar disponibles dentro de cada dominio y un identificador de ubicación específica de plataforma, por ejemplo, un URL, al que se debería anexar el contenido. El operador define las alimentaciones de contenido utilizando una pantalla separada dentro del componente editorial GUI. Toda la información del esquema editorial de dominio en esta etapa se conserva en la base de datos. Si se va a modificar un Dominio en directo existente, el componente editorial opera en una copia de la estructura de dominio en directo, y define los cambios que se van a realizar al dominio, por ejemplo, la remoción o adición de interfaces Trig. Las interfaces Trig o archivos Triglet individuales asignados al esquema editorial hacen referencia a los paquetes de los cuales fueron importados originalmente. Esto permite al componente editorial compilarlos más adelante (ver a continuación) . En una modalidad alternativa, se puede tener acceso al paquete de actualización en una forma diferente. Se puede proveer una interfaz a la base de datos 111 para que la interfaz pueda ser registrada por el dispositivo para así solicitar una actualización de contenido. La base de datos mantiene una entrada para la ubicación del paquete de actualización de contenido relevante, la cual es devuelta posteriormente al dispositivo. El dispositivo puede entonces tener acceso al paquete de actualización de contenido registrando el URL apropiado. Este enfoque alternativo simplifica en gran medida la gestión y operación de las alimentaciones de contenido, debido a que ya no es necesario identificar la ubicación de las actualizaciones cuando se emite por primera vez el contenido a las terminales y provee un grado de automatización al sistema. Las actualizaciones de contenido se pueden colocar (y volver a colocar) conforme a lo requerido, sin tener que notificar los cambios a todos los dispositivos, siempre y cuando se actualice la base de datos . El operador puede seleccionar diferentes vistas en el Dominio bajo desarrollo, por ejemplo, la estructura original (es decir, la que está actualmente en directo) , una estructura final propuesta (sección aprobada y/o pendiente) , con o sin cambios marcados, los cambios únicamente y las secciones rechazadas. El componente editorial GUI evita que un esquema de dominio sea publicado si éste contiene interfaces Trig o archivos Triglet que hagan referencia a los canales de actualización o alimentaciones de contenido que no hayan sido asignadas todavía al dominio. Una vez que está listo para prueba un esquema editorial, éste es publicado al servidor de inmigración del dominio para prueba. La solicitud editorial es procesada por el servidor y comprende compilar todas las Interfaces Trig y archivos Triglet no compilados (tanto aprobados como pendientes) y exportar todos los cambios propuestos, tanto pendientes como aprobados, al Servidor de Inmigración (esto incluye nuevas interfaces Trig, actualizaciones de las interfaces Trig existentes, archivos Triglet con vencimiento para publicación (de acuerdo con una fecha de prueba) y la remoción de interfaces Trig, archivos Triglet y nodos. Si hay fallas en la etapa de compilación, no se publicará sección alguna. La sección infractora se debe rechazar o corregir para permitir que continúe la publicación. Una vez en el servidor de inmigración del MNO, el Dominio se puede probar utilizando dispositivos móviles. Cada sección que pasa su prueba se puede marcar como "Aprobada" utilizando el componente editorial GUI. Las secciones que no pasan las pruebas se pueden marcar como "Rechazadas". Las interfaces Trig/archivos Triglet corregidos se pueden importar al componente editorial, volver a entregar al Dominio y después publicar en el servidor de inmigración, tal como se describió anteriormente. Este procesamiento continúa hasta que se aprueban todas las secciones y el Dominio queda listo para publicación al ambiente en directo. Adicionalmente, para el área de inmigración de un dominio, es posible simular el paso del tiempo de manera que se puedan probar las actualizaciones programadas. Algunos MNO pueden no requerir la capacidad del servidor de Inmigración y, por lo tanto, todas las secciones que se van a publicar se pueden marcar como aprobadas cuando se establezca el esquema de dominio y, por lo tanto, el operador puede continuar directamente a la publicación en directo. El componente editorial GUI provee vistas de cada uno de los dominios, tanto para las áreas en directo como las áreas de inmigración. Desde esta vista, es posible iniciar y detener la publicación automática de alimentaciones de contenido y la publicación programada de archivos Triglet en cada canal de actualización. Una vez completada la prueba, el dominio se puede publicar al área en directo del servidor, utilizando un procedimiento similar a aquel descrito anteriormente, excepto que solo se publican los cambios de dominio marcados como aprobados. Cuando se establece un esquema editorial, se pueden establecer las fechas y horas de publicación de las interfaces Trig y los archivos Triglet. Al momento de solicitar que un dominio esté listo para publicación, el componente editorial se asegura que todas las interfaces Trig y los archivos Triglet estén compilados, incluso si la fecha u hora de publicación asociada con la sección es en el futuro. Secciones con fecha a futuro permanecen en la base de datos del componente editorial hasta que están listas para ser despachadas al área de dominio objetivo. Un procedimiento de publicación programada puede registrar cada área de Dominio objetivo a intervalos configurados y despacha cualesquiera secciones programadas que hayan vencido para publicación al Dominio apropiado objetivo a través de la API de despacho. Las alimentaciones de contenido son actualizadas a intervalos regulares con contenido dinámico que se extrae de fuentes externas, por ejemplo, extracción de la web, alimentaciones de noticias RSS, etc. El contenido dinámico puede ser texto simple de retransmisión de noticias (encabezados y URL) pero también podría incluir objetos más complejos del tipo que podría ser reemplazado utilizando la caja de herramientas de contenido. El procedimiento de la alimentación de contenido formatea este contenido en un archivo de actualización y después lo pasa de regreso al Control de Alimentación. El Control de Alimentación recurre al procedimiento de la interfaz Trig de Compilación el cual pasa la plantilla del Paquete Triglet asociado con la Alimentación de Contenido y el archivo de actualización al compilador. El compilador extrae los recursos en el paquete Triglet y regresa un archivo Triglet compilado al Control de Alimentación, el cual es después publicado (ver arriba) . Para cada interfaz Trig o archivo Triglet que se va a compilar, el compilador requiere la siguiente información: el paquete original en el cual se importó o creó el Trig/Triglet; la lista de paquetes de actualización de Trig/Triglet; el tipo de archivos que se van a crear; y un mapa URL para los canales de actualización y las alimentaciones de contenido. El compilador utiliza el mapa URL para actualizar los URL referenciados por los canales de actualización (y alimentaciones de contenido) dentro de las interfaces Trig y archivos Triglet individuales dentro de cada paquete. Se puede utilizar una API de despacho para despachar contenido a los servidores del MNO. Se ha impuesto un modelo FTP de referencia para dar servicio a la API y transferir archivos a un servidor de contenido; sin embargo, el mecanismo API permite a un integrador ejecutar su propio mecanismo de despacho de contenido, por ejemplo, utilizando la salida del componente editorial como entrada a la API de su propio sistema de gestión de contenido, agregando lógica personalizada en caso de ser necesario. El componente editorial soporta funcionalidad OSS convencional accesible a través del componente editorial GUI y a través de una API estándar industrial (JMX) la cual permite que SI utilice herramientas de integración estándar para integrar el componente editorial en el ambiente OSS del MNO. Esto incluye el registro de eventos importantes del componente editorial y todas las secciones importadas/publicadas, un rastro de auditoria para cualesquiera cambios observados con guiones externos, mantener Registros de Error/Advertencia, alertas de sistema, reporte de revisión de salud, etc. Todos los datos relacionados con el componente editorial se almacenan dentro de una base de datos, tal como Oracle, y la funcionalidad de respaldo y restablecimiento es soportada por los procedimientos de base de datos estándar, integrados con el ambiente OSS. Para operación, el componente editorial requiere un ambiente J2EE operativo y un caso instalado de una base de datos, tal como Oracle. La instalación del componente editorial puede ser validada por medio de un procedimiento que indique que el procedimiento de instalación fue exitoso y que todos los componentes se han activado correctamente. El componente del servidor de contenido 150 es una ejecución estándar de un servidor Web y, debido a ello, se entiende bien el modelo de escalación. Las capacidades de un servidor se pueden clasificar utilizando un número "SPECweb99" que indique el número de sesiones simultáneas que el servidor web puede manejar bajo condiciones de referencia. El rango de números SPECweb99 publicado va desde 404 a 21,000 con los servidores web comerciales típicos que tienen números SPECweb99 en el orden de 5,000. Un escenario de despliegue típico de 1 millón de suscriptores con contenido de actualización cada hora, requiere un servidor de web con una clasificación SPECweb99 de únicamente 1,112. Un despliegue exitoso conducirá a un uso incrementado del servicio el cual puede ser provisto por servidores adicionales de habilitación para crear una infraestructura que se pueda escalar y que tenga una alta capacidad de recuperación a las fallas. Se puede entablar una conexión con el servidor desde un dispositivo móvil a través de una puerta WAP. En este caso, la sesión del servidor web existe entre la puerta WAP y el servidor Web, en lugar del teléfono móvil y el servidor web. Cuando se realiza una petición de un archivo a través de la puerta WAP, la sesión con el servidor web dura únicamente lo que le toma transferir el archivo del servidor de web a la puerta WAP, es decir, la sesión es extremadamente corta debido a que el ancho de banda de conexión será muy alto y la latencia extremadamente baja. Alternativamente, se puede establecer una conexión directa entre el teléfono móvil y el servidor web. En este caso, el servidor web necesitará mantener la sesión abierta todo el tiempo que dure la descarga de los datos al teléfono. Existen dos tipos de contenido que son entregados por el componente de servidor de contenido: interfaces Trig, típicamente del orden de 100KB y archivos Triglet de actualización regular, los cuales típicamente son del orden de 1KB. El tráfico creado por las descargas de la interfaz Trig es muy similar al tráfico generado por descargas de contenido existentes. Y, por lo tanto, se entienden bien los problemas relacionados. Las descargas de las actualizaciones de archivos Triglet regulares son una función nueva en un modelo de tráfico del MNO pero debido al tamaño pequeño de las actualizaciones, el cual típicamente se ajusta dentro de un paquete de datos, es posible mostrar que el tráfico puede seguir siendo manejado por servidores web típicos. En el caso de una descarga de un archivo Triglet, típicamente solo se requiere un paquete de datos para transferir 1KB. Asumiendo una latencia en circuito a través de una red GPRS de 2 segundos, el servidor de red necesitará mantener abierta una sesión típica durante aproximadamente 4 segundos. Para el escenario de 1 millón de suscriptores que tienen una interfaz Trig en su teléfono con contenido que se actualiza cada hora, esto implica 278 bits por segundo en el servidor web y 1,112 sesiones simultáneas. Tal como se mencionó anteriormente, este número está bien dentro de la capacidad de servidores de web típicos. La figura 3 muestra una representación esquemática del software 400 para los dispositivos móviles 300, el cual comprende un suministrador de lenguaje de marcado 410, un gestor de actualizaciones 420, un agente de comunicación de red 425, un gestor de recursos 430, un sistema de archivos virtuales 435, un gestor de actor 440, una pluralidad de actores 445a, 445, ..., un suministrador Ul nativo 450, un gestor de soporte 460, un gestor de interfaces Trig 465, y un analizador sintáctico de lenguaje marcado 470. El software puede operar utilizando TrigML, la cual es una aplicación XML y el suministrador de lenguaje de marcado 410 suministra el código TrigXML para despliegue en el dispositivo móvil 300. TrigML se describe en nuestra solicitud copendiente GB0403709.9, presentada el 19 de febrero de 2004, cuyo contenido se incorpora en la presente invención por referencia. El suministrador de lenguaje de marcado también utiliza el Analizador Sintáctico TrigML para analizar sintácticamente recursos TrigML, desplegar contenido en la pantalla del dispositivo y controlar el reemplazo y visualización del contenido en el equipo. El suministrador Ul nativo se utiliza para desplegar componentes Ul que se pueden desplegar sin el uso de trigML, y para desplegar mensajes de error. El software 400 es aprovisionado e instalado en una forma específica en un dispositivo. De manera similar, las actualizaciones de software son manejadas en un dispositivo de manera específica. El software se puede aprovisionar en un formato más limitado, tal como una aplicación auto-contenida que suministra su contenido integrado únicamente: es decir, el software es aprovisionado con una interfaz Trig integrada pero no se pueden agregar interfaces Trig más adelante. La interfaz Trig suministrada se puede actualizar en el aire. El gestor de recursos provee una abstracción del almacenamiento persistente en el dispositivo, es decir, el almacenamiento de los archivos como archivos reales, o como registros en una base de datos. El gestor de recursos presenta una interfaz de sistema de archivo al suministrador de lenguaje de marcado y al gestor de actualizaciones. Este es responsable de manejar la lógica de trayectoria del archivo, distinguir entre archivos de recursos reales y atributos de actor, mapear trayectorias relacionadas con la interfaz Trig sobre trayectorias absolutas, conectarse en interfaz con el gestor de interfaz Trig y proveer un interfaz de modificación al gestor de actualizaciones . El Gestor de Actualizaciones maneja la recepción y aplicación de Trigs y Triglets (interfaces y archivos) . El Gestor de Actualizaciones presenta una interfaz al Suministrador y al Gestor de la interfaz Trig y es responsable de: la iniciación de las actualizaciones manuales cuando así lo ordena el Suministrador; controlar y ejecutar el canal de actualización automática cuando así está configurado por el gestor de la interfaz Trig; indicar el progreso de una actualización manual y recuperar una Actualización después de la pérdida inesperada de la conexión de red y/o potencia del dispositivo. El formato de paquete de actualización se puede definir como una serialización binaria de un esquema XML. El Gestor de Soporte provee una interfaz para otros componentes para reportar la ocurrencia de un evento o error. Dependiendo de la severidad del error, el Gestor de Soporte registrará el evento y/o hará aparecer un mensaje de error. El Gestor de Actores 440 busca el conjunto de actores 445 presente en el software. Este es utilizado por: el suministrador cuando el contenido está enviando eventos a un actor; actores que quieren notificar que un valor de atributo ha cambiado y actores que desean emitir un evento (ver a continuación) . El software 400 es aprovisionado a los dispositivos móviles en un método específico de dispositivo. Una o más interfaces Trig se pueden aprovisionar como parte de la instalación, por ejemplo, se pueden almacenar como un paquete actualizado no comprimido. Al momento del inicio, el paquete se puede expandir e instalar en el sistema de archivo. Los Actores 445 son componentes que publican valores de atributo y manejan y emiten eventos. Los actores se comunican con el Suministrador de manera sincrónica. Si un actor necesita un comportamiento asincrono, entonces es responsabilidad del actor gestionar y comunicarse con un hilo externo al hilo principal del Suministrador. Los atributos de Actor se pueden leer como referencias de archivo. Los atributos son uno de cuatro tipos: un solo valor simple; un vector de valores simples; una sola estructura de campos, cada campo con un valor simple; o un vector de estructuras. Los atributos pueden ser referenciados por una expresión que utiliza una anotación objeto. elemento similar a muchos lenguajes de programación orientados al objeto. <image res="signallevels/{protocol . signalstrength} "/> Cuando se necesita como un archivo, se accesa a un atributo a través de la carpeta /attrs . <text res="/attr/networ /name"> Un Actor puede manejar mensajes enviando a éste un evento con el elemento <throw> (<lanzar>) . Los eventos emitidos por los actores se pueden entregar al árbol de contenido como eventos de contenido: estos pueden ser dirigidos en una Id de elemento o "parte superior". La conexión en interfaz con un actor queda definida por el archivo de Definición de Interfaz de Actor. Este es un documento XML que define los atributos, tipos, nombres de campo, eventos de entrada y parámetros, y eventos de salida. El conjunto de actores se puede configurar, al momento de su construcción, para el software. El Apéndice B proporciona una lista ejemplar de algunos actores que se pueden utilizar, junto con las funciones o variables asociadas. Las actualizaciones comprenden una nueva interfaz Trig (una Ul nueva o de reemplazo) o un archivo Triglet (una modificación a una interfaz Trig existente) y se pueden apreciar como modificaciones al sistema de archivo del software. El Gestor de Actualizaciones para determinar lo que se tiene que cambiar en el sistema de archivo leyendo un paquete. Los paquetes de actualización se pueden descargar en el aire por medio del software 400 utilizando http, u otros mecanismos de transporte convenientes, envueltos en un formato de paquete de dispositivo específico o pre-aprovisionados con la instalación del software mismo. Las actualizaciones se pueden activar a través de un número de medios, los cuales incluyen: • Que el software revise el procesamiento de Actualización interrumpido al momento del inicio • Que el software revise los Paquetes de Actualización preinstalados al momento del inicio • Automáticamente conforme a lo configurado por un Canal de Actualización • La iniciación del usuario • Que el dispositivo reciba una SMS especial. Las actualizaciones enviadas OTA pueden ser traídas utilizando solicitudes HTTP-GET iniciadas por el software. La solicitud GET es dirigida al URL asociado con la Actualización. El cuerpo de la respuesta http es un archivo binario que porta datos en un formato de Paquete de Actualización. La recepción de datos es entregada en un hilo separado al hilo del Suministrador. Para actualizaciones de fondo (automáticamente iniciadas) , esto permite al usuario seguir navegando en la Ul . Para actualizaciones en primer plano (manualmente iniciadas) , esto permite al hilo del Suministrador desplegar una barra de avance y escuchar una instrucción de cancelación. Las interfaces Trig pueden definir Canales de Actualización, las cuales comprenden un URL a partir del cual tratar de obtener las actualizaciones y un número de propiedades asociadas: actualización automática o manual; un esquema de temporización y estrategia de reintento en el caso de una falla. El software solo puede iniciar una actualización automática cuando está corriendo. Al momento del inicio, si ha vencido un evento de actualización, el software esperará un intervalo de tiempo antes de comenzar la actualización. Esto es posponer cualesquiera demoras de inicio incurridas por la iniciación de una Actualización inmediatamente, y por lo tanto, proporcionará al usuario un inicio más rápido. Los canales de actualización se pueden definir en una ubicación bien conocida dentro de la interfaz Trig, por ejemplo la carpeta de config/channels de una interfaz Trig en archivos que contienen etiquetas <channel>. El algoritmo empleado para desempacar e instalar una actualización es específico del dispositivo. Sin embargo, es importante que el algoritmo sea seguro contra la interrupción inesperada (por ejemplo, pérdida de potencia) , para que no se llegue a un estado de corrupción o que no sea posible recuperar en el sistema de archivo.

Esto se puede lograr utilizando dos hilos (un hilo de red y un hilo del suministrador) con el objetivo de tener el mayor procesamiento posible ejecutado por el hilo de red para interrumpir el hilo del suministrador lo más poco posible. Hay otros modos de falla a considerar: si no se puede iniciar un HTTP-GET, o se encuentra con un código de respuesta de error HTTP, entonces este intento en una Actualización se abandona y se utiliza la estrategia de reintento para comenzar un nuevo intento de actualización en una fecha posterior. Cuando una respuesta HTTP es interrumpida por la pérdida de señal de red, cualesquiera archivos temporales son eliminados y la estrategia de reintento se utiliza para reiniciar el intento de Actualización en una fecha posterior. Si un encabezado de actualización indica que el tamaño de carga útil de actualización puede ser demasiado grande para que se ajuste en el dispositivo, si la actualización requiere una versión incompatible del software o si la Actualización ya reside en el dispositivo, entonces el archivo de datos de encabezado se elimina y el intento de Actualización y cualesquiera reintentos posteriores se cancelan. El formato de contenido es común en todas las plataformas que ejecutan el software. El Compilador de Contenido es una herramienta de escritura de contenido para transformar una recopilación de recursos sin procesar (texto, TrigML, imágenes PNG, definiciones de secuencias de texto) en un Paquete de Actualización sobre el aire que puede ser escrito en el sistema de archivo de dispositivo. Es deseable que el costo del re-marcado de las Ul y de la producción de una corriente continua de actualizaciones sea mínimo. Esto es habilitado mediante el aprovisionamiento de un flujo eficiente de información a partir del procesamiento creativo a través de la transmisión de datos a los usuarios. Un depósito, al que se denomina un paquete, se utiliza para las Ul, las actualizaciones de las Ul y las plantillas para la participación de terceros. Los paquetes contienen toda la información necesaria para que un tercero produzca, pruebe y entregue Ul y actualizaciones marcadas. La figura 4 muestra una representación esquemática del conjunto de herramientas de contenido 200, el cual comprende el ambiente de escritura 220, el ambiente de prueba y simulación 230 y el ambiente de mantenimiento 240. El procedimiento del paquete comprende cinco etapas de procesamiento: 1) El ambiente de escritura 220 provee los medios para diseñar la plantilla para una o más Ul y la estrategia de actualización para las Ul basadas en esa plantilla. 2) El ambiente de mantenimiento 240 provee una producción rápida de Ul y actualizaciones en un ambiente guiado y bien controlado que puede ser asignado a proveedores de contenido. 3) El ambiente de mantenimiento 240, la funcionalidad "pre-flight" permite que el administrador de despliegue revise y sintonice las Ul y actualizaciones que reciben de terceros. 4) El componente editorial 110 provee gestión de Ul y actualizaciones en el punto de despliegue, incluyendo el montaje de nuevas versiones. 5) El componente editorial 110 habilita la generación automática de actualizaciones de las alimentaciones de contenido de mantenimiento. En un proyecto típico, los paquetes son creados dentro del ambiente de escritura 220 para que: un proveedor de contenido cree Ul remarcadas a partir de una plantilla, incorporando la misma "sensación" pero una "apariencia" diferente; un proveedor de contenido cree actualizaciones de una plantilla, que provean una variación periódica o seleccionada por el usuario para el contenido de la Ul; o una agencia de publicidad cree actualizaciones de una plantilla que promuevan nuevos servicios sobre una base periódica. Para todos estos casos de uso, el ambiente de mantenimiento 240 se utiliza para importar el paquete, remarcar y reconfigurar el contenido y crear un nuevo paquete para entrega al componente editorial 110. En el diseño de la plantilla de la Ul, se deberán contemplar los siguientes puntos: cuál parte de la Ul se puede remarcar; cuáles características de la Ul necesitan ser reconfiguradas al momento del remarcado o remotamente; cuál parte del contenido de la Ul se puede actualizar; y si la Ul es remarcada, entonces saber si el usuario puede seleccionar las alimentaciones de contenido en uso. El ambiente de escritura 220 permite definir estas estrategias, y habilita el ambiente de mantenimiento 240 como el ejecutador de cada caso de cada estrategia. El formato del paquete es un formato binario opaco que almacena toda esta información como objetos serializados . El paquete puede comprender un número de recursos, tal como imágenes, texto, URL, canales de actualización, archivos de tonos, fondos de papel tapiz, aplicaciones nativas, etc. Cada recurso contiene información de autorización respecto a cómo visualizar, editar o eliminar el recurso. Cada recurso además contiene meta información tal como documentación e instrucciones que son relevantes para ese recurso. Cada herramienta de paquete asume una función relevante o requiere que los usuarios se registren como una función particular. La figura 5 muestra una representación esquemática de un dispositivo 800 que comprende una interfaz de usuario de acuerdo con una modalidad de la presente invención. El dispositivo comprende una pantalla 810 que despliega la interfaz de usuario 815 y los medios de la interfaz de usuario 820, que permiten al usuario interactuar con la interfaz de usuario 815. Un procesador 830 ejecuta el software que está almacenado dentro de uno o más medios de almacenamiento 840 y se puede proveer una o más interfaces de comunicación inalámbrica 850 para permitir la comunicación con otros dispositivos y/o redes de comunicación. Se puede recibir una o más baterías 860 para energizar el dispositivo, el cual también puede comprender interfaces para recibir energía eléctrica y/o cables de comunicación. La naturaleza de estos componentes y las interfaces dependerá de la naturaleza del dispositivo. Se entenderá que dicha interfaz de usuario se puede ejecutar dentro de un móvil o equipo de teléfono celular, pero también aplica a otros dispositivos portátiles tal como cámaras digitales, organizadores digitales personales, reproductores de música digitales, navegadores GPS, consolas de juegos portátiles, etc. Además, también aplica a otros dispositivos que comprenden una interfaz de usuario, tal como una computadora portátil o de escritorio. Los medios de interfaz de usuario pueden comprender una pluralidad de botones, tal como un teclado numérico o alfanumérico, o una pantalla de tacto o similar. Uno o más dispositivos de almacenamiento pueden comprender una forma de memoria no volátil, tal como una tarjeta de memoria, de manera que los datos almacenados no se pierdan en caso de una pérdida de energía. Los medios de almacenamiento ROM se pueden aprovisionar para almacenar datos que no necesitan actualización o cambio. Se puede proveer cierta memoria RAM para el almacenamiento temporal ya que los tiempos de respuesta más rápidos soportan el almacenamiento en memoria caché de datos a los que se recurre con frecuencia. El dispositivo también puede aceptar tarjetas de memoria removibles de usuario y, opcionalmente, se pueden utilizar unidades de disco duro como un medio de almacenamiento. El medio de almacenamiento utilizado se determinará haciendo un balance de los diferentes requerimientos de tamaño de dispositivo, el consumo de energía, el volumen de almacenamiento requerido, etc. Dicho dispositivo se puede ejecutar junto con virtualmente cualquier red de comunicación inalámbrica, por ejemplo, redes de telefonía móvil digital de segunda generación (es decir, GSM, D-AMPS) denominadas redes 2.5G (es decir, GPRS, HSCSD, EDGE) , WCDMA de tercera generación o redes CDMA-2000 y mejoras a, y derivados de éstas y redes similares. Dentro de edificios y recintos, también se pueden utilizar otras tecnologías tal como Bluetooth, IrDa o LAN inalámbrica (ya sea basadas en sistemas ópticos o de radio) . Se puede suministrar conectividad USB y/o mampara cortafuegos para la sincronización de los datos con otros dispositivos y/o para la carga de la batería. El software de cómputo para ejecutar los métodos y/o para configurar un dispositivo, tal como se describió anteriormente, se puede proveer en portadoras de datos tal como discos flexibles, CD-ROMS, DVD, tarjetas de memoria no volátil, etc. Esta solicitud reclama el beneficio de la Solicitud de Patente UK número 0403709.9, presentada el 19 de febrero de 2004, cuyo contenido se incorpora en la presente invención por referencia.

APÉNDICE A

Claims (14)

NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES

1.- Un método para recibir datos de contenido para una interfaz de usuario a un dispositivo, el método comprende los pasos para que: el dispositivo reciba datos de contenido para una interfaz de usuario desde una interfaz de comunicaciones; el dispositivo procese los datos de contenido recibidos para formar una interfaz de usuario para el dispositivo; en donde los datos de contenido comprenden metadatos y el método comprende el paso adicional donde el dispositivo tiene acceso a las actualizaciones de datos de contenido a través de la interfaz de comunicaciones de acuerdo con los metadatos de los datos de contenido.

2. - El método de conformidad con la reivindicación 1, caracterizado porque los metadatos comprenden una dirección para actualizaciones de datos de contenido y el dispositivo tiene acceso a las actualizaciones de datos de contenido ubicadas en la dirección.

3.- El método de conformidad con la reivindicación 1, caracterizado porque los metadatos comprenden una primera dirección y el dispositivo interroga a la primera dirección para obtener una segunda dirección, el dispositivo tiene acceso a las actualizaciones de datos de contenido ubicadas en la segunda dirección.

4. - El método de conformidad con la reivindicación 3, caracterizado porque la primera dirección ubica una base de datos, la base de datos comprende direcciones para una pluralidad de actualizaciones de datos de contenido.

5. - El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque los metadatos comprenden datos que determinan la frecuencia a la que el dispositivo tiene acceso a las actualizaciones de datos de contenido.

6.- El método de conformidad con cualquiera de las reivindicaciones 1 a 5, caracterizado porque los metadatos comprenden datos que definen eventos que ocasionan que el dispositivo tenga acceso al contenido de las actualizaciones de datos.

7. - El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque las actualizaciones de datos de contenido accesadas por el dispositivo son recibidas a través de la interfaz de comunicaciones, procesadas por el dispositivo y empleadas para actualizar la interfaz de usuario del dispositivo.

8. - Una portadora de datos que comprende un código ejecutable por computadora para ejecutar el método de cualquiera de las reivindicaciones 1 a 7.

9.- Un dispositivo que comprende: una interfaz de usuario; un medio de despliegue para desplegar la interfaz de usuario; una interfaz de comunicaciones para recibir datos de contenido para uso en la interfaz de usuario y medios de procesamiento para procesar los datos de contenido recibido para formar la interfaz de usuario, en donde los datos de contenido comprenden metadatos y el dispositivo está configurado para tener acceso a las actualizaciones de datos de contenido a través de la interfaz de comunicaciones, de acuerdo con los metadatos de los datos de contenido.

10.- El dispositivo de conformidad con la reivindicación 9, caracterizado porque el dispositivo está configurado para tener acceso a las actualizaciones de datos de contenido en una dirección comprendida dentro de los metadatos.

11.- El dispositivo de conformidad con la reivindicación 9, caracterizado porque el dispositivo está configurado para inquirir una dirección comprendida dentro de los metadatos, en donde el resultado de la pregunta es una segunda dirección que identifica una actualización de datos de contenido.

12.- El dispositivo de conformidad con cualquiera de las reivindicaciones 9-11, caracterizado porque los metadatos comprenden datos que configuran el dispositivo para tener acceso a las actualizaciones de datos de contenido a una frecuencia predeterminada.

13.- El dispositivo de conformidad con cualquiera de las reivindicaciones 9-11, caracterizado porque los metadatos comprenden datos que configuran el dispositivo para tener acceso a las actualizaciones de datos en respuesta a eventos predefinidos.

14.- El dispositivo de conformidad con cualquiera de las reivindicaciones 9-13, caracterizado porque el dispositivo además está configurado para recibir actualizaciones de datos de contenido a través de la interfaz de comunicaciones; procesar las actualizaciones de datos de contenido y actualizar la interfaz de usuario del dispositivo, por consiguiente.