ES2340866T3 - Metodo y sistema para optimizar el paso de metadatos. - Google Patents
Metodo y sistema para optimizar el paso de metadatos. Download PDFInfo
- Publication number
- ES2340866T3 ES2340866T3 ES06113366T ES06113366T ES2340866T3 ES 2340866 T3 ES2340866 T3 ES 2340866T3 ES 06113366 T ES06113366 T ES 06113366T ES 06113366 T ES06113366 T ES 06113366T ES 2340866 T3 ES2340866 T3 ES 2340866T3
- Authority
- ES
- Spain
- Prior art keywords
- metadata
- content
- service
- application
- processing element
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
- H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
- H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
- H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Library & Information Science (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Telephonic Communication Services (AREA)
Abstract
Un método para optimizar el suministro de contenidos en un elemento de procesamiento (150, 510, 410) en una arquitectura de suministro dinámico de contenidos, comprendiendo el método los pasos de: recibir una envoltura de contenido y de metadatos (614, 610, 620) en el elemento de procesamiento; comprobar la envoltura de contenido y de metadatos para determinar si la envoltura de contenido y de metadatos comprende metadatos para dicho elemento de procesamiento; si dicha envoltura de contenido y de metadatos contiene metadatos para dicho elemento de procesamiento, extraer y almacenar en antememoria dichos metadatos; si dicha envoltura de contenido y de metadatos no contiene metadatos para dicho elemento de procesamiento, recuperar metadatos para un proveedor de contenidos, asociado con el contenido incluido en dicha envoltura de contenido y de metadatos, desde una antememoria en el elemento de procesamiento; y aplicar dichos metadatos extraídos o recuperados a dicha envoltura de contenido y de metadatos.
Description
Método y sistema para optimizar el paso de
metadatos.
El presente método y sistema se refiere a
suministro dinámico de contenidos en un entorno móvil y, en
particular, a una arquitectura genérica de suministro dinámico de
contenidos en la que aplicaciones y proveedores de contenidos
pueden ser añadidos sin cambiar la arquitectura.
Los usuarios de dispositivos móviles o equipo de
usuario móvil están haciéndose cada vez más sofisticados en
términos de la funcionalidad que exigen de sus dispositivos móviles
y del modo en el que acceden a datos desde los dispositivos
móviles.
El suministro dinámico de contenidos permite que
los usuarios tengan información o datos enviados a ellos más bien
que tener que ir y buscar los datos. Ejemplos de datos podrían
incluir cotizaciones de Bolsa, actualizaciones meteorológicas,
actualizaciones de tráfico, imagen de fondo dinámica, anuncios,
aplicaciones u otros datos deseables para un usuario.
Las tecnologías actuales para dispositivos
móviles, tal como el protocolo de aplicación inalámbrica (WAP:
wireless application protocol), tienen la capacidad de enviar
contenido; sin embargo, WAP requiere que sitios Web sean reescritos
para satisfacer el protocolo de aplicación inalámbrica (WAP) y
proveer a los usuarios de un sitio uniforme que no cambie para
acomodar las capacidades de un usuario para ver un sitio.
El documento US 1494430 enseña un receptor que
recibe contenido por un canal y metadatos asociados por otro canal.
El receptor almacena temporalmente los metadatos y después los
sincroniza con el contenido con el que están asociados.
Otras alternativas incluyen servicio de envío
basado en SMS (Short Message Service = Servicio de Mensajes Cortos)
y radiodifusión o radiodifusión celular. En el caso de
radiodifusión, el suministro no puede ser adaptado a las
necesidades de un usuario particular o a las capacidades de un
dispositivo particular. Por tanto, estos sistemas no tienen
inteligencia asociada con ellos. Una solución mejor es necesaria
para dispositivos móviles.
El presente sistema y método provee
preferiblemente un sistema y arquitectura de suministro dinámico de
contenidos que permite que aplicaciones genéricas y proveedores de
contenidos sean añadidos al sistema sin la necesidad de modificar
la arquitectura. Específicamente, el presente sistema y método
permite que un dispositivo móvil se haga una plataforma de
aplicación dinámica en la que aplicaciones pueden ser añadidas y
contenido ser provisto al dispositivo móvil, donde la arquitectura
del sistema de suministro dinámico de contenidos no limita el tipo
de aplicación que puede ser instalada en el dispositivo ni el tipo
de contenido que recibe el dispositivo.
En un aspecto de la presente solicitud,
metadatos son provistos y asociados preferiblemente con el contenido
para añadir inteligencia al contenido para diversos elementos de
procesamiento dentro de la arquitectura de suministro dinámico de
contenidos. Esta arquitectura incluye componentes lógicos que
proveen la provisión de contenidos, la provisión de servicios
incluyendo proxies de servicio de envío, una red inalámbrica, el
cliente de servicio de envío y aplicaciones de cliente.
En un aspecto adicional de la presente
solicitud, metadatos son provistos preferiblemente en un modelo
"envuelto" en capas para enviar metadatos de contenido. El
contenido es envuelto con metadatos que pueden ser usados para
procesamiento en cada elemento dentro de un marco de servicio de
envío. Los metadatos para cada elemento sucesivo son dispuestos en
capas, permitiendo de tal modo que el elemento de procesamiento
extraiga solo los metadatos para ese elemento. Por ejemplo, un
paquete de contenido que incluye metadatos dirigidos a un proxy de
servicio de envío y una aplicación de cliente puede incluir el
contenido con un primer nivel de metadatos para la aplicación de
cliente, y una segunda capa de metadatos para el proxy de servicio
de envío. De tal modo, cuando la envoltura llega al proxy de
servicio de envío, los metadatos para el proxy de servicio de envío
son extraídos y aplicados al contenido, y el contenido
y los metadatos modificados para la aplicación de cliente son pasados a un elemento de procesamiento adicional.
y los metadatos modificados para la aplicación de cliente son pasados a un elemento de procesamiento adicional.
En otro aspecto de la presente solicitud, los
metadatos puede ser divididos en metadatos estáticos (también
denominados en esto como metadatos de canal) y metadatos dinámicos
(también denominados en esto como metadatos de contenido). Los
metadatos estáticos son establecidos preferiblemente en el momento
tanto de la aplicación como del proveedor de contenidos. Sin
embargo, los metadatos de canal pueden ser establecidos en un
momento posterior. Los metadatos de canal especifican reglas de
procesamiento que son específicas para el tipo de contenido que
está siendo suministrado y las exigencias de aplicación para tipo de
contenido.
Los metadatos dinámicos están asociados
inversamente con el contenido específico que es pasado.
En otro aspecto de la presente solicitud, un
modelo de registro enchufable es presentado preferiblemente dentro
del marco de servicio de envío. Un cliente de servicio de envío
genérico y un proxy de servicio de envío son identificados,
teniendo cada uno diversos bloques o módulos de procesamiento que
permiten que estos elementos procesen tanto contenido como
metadatos. Estos bloques pueden ser dirigidos para procesar el
contenido que es pasado, los metadatos que son pasados o tanto el
contenido como los metadatos que son pasados.
El registro enchufable provee además
preferiblemente el paso de manifiestos de servicio y manifiestos de
aplicación para permitir el establecimiento de metadatos de canal
entre un proveedor de contenidos y una aplicación. Específicamente,
los manifiestos de servicio pueden ser usados para registrar un
proveedor de contenidos en el marco de servicio de envío, y un
manifiesto de aplicación puede ser usado para registrar una
aplicación en el marco de servicio de envío.
En otro aspecto de la presente solicitud, es
provisto preferiblemente un método para enviar contenido sindicado
que permite el manejo de datos basado en su prioridad y basado en
factores de red que incluyen el coste de emitir datos, el tipo de
red conectada o las preferencias de usuarios. Un modelo mixto
opcional de envío/extracción para contenido sindicado tiene en
cuenta un proxy de servicio de envío para enviar contenido cuando
las conexiones de red se hacen favorables o para que un cliente
extraiga contenido cuando las condiciones de red se hacen
favorables o cuando el usuario necesita el contenido.
Para acomodar diversos dispositivos móviles, un
aspecto adicional de la presente solicitud provee preferiblemente
lo necesario para fragmentación de contenido para contenido,
incluyendo fragmentación de contenido no lineal. La fragmentación
de contenido no lineal incluye aumentar el contenido con metadatos
que permiten que los datos sean recompuestos una vez que han sido
pasados al cliente.
Estos y otros aspectos serán identificados con
más detalle con respecto a los dibujos.
Por tanto, la presente solicitud proporciona
preferiblemente un método según la reivindicación1 para optimizar
el suministro de contenidos en un elemento de procesamiento en una
arquitectura de suministro dinámico de contenidos, comprendiendo el
método los pasos de: recibir una envoltura de contenido y de
metadatos en el elemento de procesamiento; comprobar la envoltura
de contenido y de metadatos para determinar si la envoltura de
contenido y de metadatos incluye metadatos para dicho elemento de
procesamiento; si dicha envoltura de contenido contiene metadatos
para dicho elemento de procesamiento, extraer y almacenar en
antememoria dichos metadatos; si dicha envoltura de contenido no
contiene metadatos para dicho elemento de procesamiento, recuperar
metadatos para un proveedor de contenidos asociado con el contenido
procedente de una antememoria en el elemento de procesamiento; y
aplicar dichos metadatos extraídos o recuperados a dicha envoltura
de contenido y de metadatos.
La presente solicitud proporciona además un
elemento de procesamiento en una arquitectura de suministro dinámico
de contenidos según la reivindicación 6, comprendiendo dicho
elemento de procesamiento: medios de comunicación, estando dichos
medios de comunicación adaptados para recibir una envoltura de
contenido y de metadatos desde un proveedor de contenidos o un
elemento anterior de procesamiento en dicha arquitectura de
suministro dinámico de contenidos y adaptados además para pasar una
envoltura modificada de contenido a un elemento subsiguiente de
procesamiento en dicha arquitectura de suministro dinámico de
contenidos; un extractor de metadatos adaptado para extraer
metadatos dirigidos al elemento de procesamiento desde la envoltura
de contenido y de metadatos; una antememoria adaptada para
almacenar metadatos extraídos por el extractor de metadatos; y un
procesador adaptado para aplicar metadatos a la envoltura de
contenido y de metadatos una vez que han sido extraídos metadatos
para el elemento de procesamiento, en el que dicho extractor de
metadatos de contenido está adaptado además para recuperar
metadatos desde dicha antememoria si no existen metadatos para el
elemento de procesamiento en la envoltura de contenido.
La presente solicitud también proporciona un
producto de programa de ordenador según la reivindicación 12.
Realizaciones adicionales son expuestas en las
reivindicaciones dependientes.
\vskip1.000000\baselineskip
La presente solicitud será mejor comprendida con
referencia a los dibujos, en los que:
la Figura 1 es un esquema de bloques de una
arquitectura básica para un sistema de suministro dinámico de
contenidos;
la Figura 2 es un esquema de bloques que muestra
arquitecturas alternativas del sistema de suministro dinámico de
contenidos de la Figura 1;
la Figura 3 es el esquema de bloques de la
Figura 1 que muestra el flujo de contenido y metadatos;
la Figura 4 es un esquema de bloques que muestra
un proxy de servicio de envío que puede ser usado en asociación con
el presente sistema y método;
la Figura 5 es un esquema de bloques que muestra
un cliente de servicio de envío que puede ser usado en asociación
con el presente sistema y método;
la Figura 6 es un esquema de bloques que muestra
un modelo de envoltura multicapa de contenido y metadatos;
la Figura 7 es el esquema de bloques de la
Figura 6, mostrando metadatos dinámicos de pasos de procesamiento
para cada envoltura;
la Figura 8 es el esquema de bloques de la
Figura 6, mostrando adicionalmente procesamiento que usa metadatos
estáticos y dinámicos;
la Figura 9 es un esquema de bloques que muestra
un proceso de registro para una aplicación a un solo cliente de
servicio de envío compartido;
la Figura 10 es un esquema de bloques que
muestra un proceso de registro de una aplicación a un contenedor de
servicio de envío que gestiona un grupo de clientes de servicio de
envío;
la Figura 11 es un esquema de bloques que
muestra una aplicación que registra a un procesador de
contenido y oyente por conector (socket listener);
la Figura 12 es un esquema de bloques que
muestra un proveedor de contenidos que registra en un solo proxy de
servicio de envío compartido;
la Figura 13 es un esquema de bloques que
muestra un proveedor de contenidos que registra en un contenedor de
servicio de envío que gestiona un grupo de proxies de servicio de
envío;
la Figura 14 es un diagrama de flujo que muestra
mensajes de registro entre un proveedor de contenidos y una
aplicación de cliente;
la Figura 15 es un esquema de bloques que
muestra la interacción durante el registro entre un cliente de
servicio de envío y un proxy de servicio de envío;
la Figura 16 es un esquema de bloques que
muestra la interacción durante el registro entre un proxy de
servicio de envío y un proveedor de contenidos;
la Figura 17 es un diagrama de flujo que muestra
el flujo de contenido y metadatos entre un proveedor de contenidos
y elementos de procesamiento;
la Figura 18 es un esquema de bloques que
muestra una aplicación de transformada ejemplar para contenido;
la Figura 19 es un esquema de bloques de un
modelo de sindicación de contenido;
la Figura 20 es un esquema de bloques de un
proceso de fragmentación lineal;
la Figura 21 es un esquema de bloques de un
proceso de fragmentación no lineal; y
la Figura 22 es un esquema de bloques de un
dispositivo móvil ejemplar que podría ser usado en asociación con
el presente método y sistema.
Ahora se hace referencia a la Figura 1. Se
ilustra un sistema genérico de servicio de envío para suministrar
contenido dinámico a una aplicación de cliente. El sistema de la
Figura 1 es un sistema simplificado y muestra componentes lógicos
que necesitan estar en una arquitectura de suministro dinámico de
contenidos; sin embargo, un experto en la técnica apreciará que
otros componentes podrían existir o que diversos componentes podrían
ser agrupados entre sí.
La arquitectura 100 incluye un proveedor 110 de
contenidos. El proveedor 110 de contenidos está dispuesto para
proporcionar contenido dinámico a usuarios que están suscritos al
proveedor 110 de contenidos. Ejemplos pueden incluir, por ejemplo,
un sitio Web que vende libros. Un usuario puede registrarse en el
proveedor 110 de contenidos para obtener una lista de libros
publicados recientemente dentro de géneros específicos. Otros
ejemplos podrían incluir sitios de noticias que podrían proporcionar
titulares a usuarios sobre una base periódica, sitios de tráfico
que podrían proporcionar información de tráfico actualizada a
usuarios durante ciertos períodos del día, sitios de mercado
bursátil que podrían proporcionar cotizaciones de bolsa actualizadas
o tipos de cambio de divisas a usuarios, entre otros.
Como se describirá con más detalle después, el
proveedor 110 de contenidos se registra en un proveedor 120 de
servicios para permitir que clientes del proveedor de servicios
reciban contenido desde el proveedor 110 de contenidos. El
proveedor 120 de servicios incluye un proxy 122 de servicio de envío
que actúa como un proxy para un cliente o una aplicación de cliente
y proporciona un destino para que el proveedor 110 de contenidos
envíe contenido.
El proveedor 120 de servicios comunica por la
red inalámbrica 130 con un cliente 140 de servicio de envío que
está situado en un dispositivo móvil. El cliente 140 de servicio de
envío será descrito con más detalle después. El cliente 140 de
servicio de envío recibe el contenido que está siendo suministrado
desde el proveedor 110 de contenidos y puede comunicar el contenido
con una aplicación 150 de cliente que finalmente consume el
contenido.
Dentro de la presente memoria descriptiva, la
referencia al proveedor 110 de contenidos, proveedor 120 de
servicios, proxy 122 de servicio de envío, red inalámbrica 130,
cliente 140 de servicio de envío o aplicación 150 de cliente es una
referencia de vuelta a la arquitectura de la Figura 1.
Refiriéndose a la Figura 2, los expertos en la
técnica apreciarán que los componentes de la Figura 1 son
simplemente componentes lógicos y no son necesariamente componentes
físicos distintos. La Figura 1 ilustra una arquitectura genérica en
la que existen un proveedor 110 de contenidos, un proxy 122 de
servicio de envío, un cliente 140 de servicio de envío y una
aplicación 150 de cliente. Alternativas son ilustradas en la Figura
2.
Específicamente, una primera arquitectura
alternativa 210 incluye proveedores múltiples 110 de contenidos que
comunican con un proxy 122 de servicio de envío. Como en la
arquitectura de la Figura 1, el proxy 122 de servicio de envío
comunica por la red inalámbrica 130 con un cliente 140 de servicio
de envío. Además, aplicaciones múltiples 150 de cliente existen en
la arquitectura 210. Por tanto, este es un sistema
N-1-1-N que tiene
proveedores múltiples 110 de contenidos y aplicaciones múltiples 150
de cliente.
La arquitectura 220 de la Figura 2 incluye un
proveedor 110 de contenidos que comunica con, y registrado en, el
proxy 122 de servicio de envío. Además, el proxy 122 de servicio de
envío comunica por la red inalámbrica 130 con clientes múltiples
140 de servicio de envío. Cada cliente 140 de servicio de envío
comunica con una aplicación 150 de cliente. Por tanto, la
arquitectura 220 agrupa los componentes lógicos de una aplicación
150 de cliente y un cliente 140 de servicio de envío y es un sistema
N(1-1)-1-1.
La arquitectura 230 de la Figura 2 tiene proxies
múltiples 122 de servicio de envío, comunicando cada uno con un
proveedor 110 de contenidos. Cada combinación 232 de proxy de
servicio de envío y proveedor de contenidos comunica por la red
inalámbrica 130 con un cliente genérico 140 de servicio que, a su
vez, comunica con la aplicación 150 de cliente. Este es un sistema
1-1-N(1-1).
En la arquitectura 240 de la Figura 2, un
agrupamiento 232 de proveedores 110 de contenidos y proxies 122 de
servicio de envío comunica por la red inalámbrica 130 con una
combinación de clientes genéricos 140 de servicio de envío y
aplicaciones 150 de cliente. Por tanto, este es un sistema
N(1-1)-N(1-1).
Como será apreciado por los expertos en la
técnica, otras alternativas son posibles. Lo anterior muestra
diversos componentes lógicos que pueden estar en componentes
físicos separados o agrupados entre sí. Por ejemplo, un cliente de
servicio de envío puede estar incrustado en una aplicación, clientes
compartidos comunes pueden ser usados por aplicaciones múltiples u
otras alternativas.
Ahora se hace referencia a la Figura 3. Para
añadir inteligencia a un sistema, contenido es asociado con
metadatos. En este caso, metadatos son definidos como datos que
pueden ser usados por un elemento de procesamiento para manipular
el contenido. Como será apreciado, un sistema genérico de servicio
de envío necesita metadatos para permitir que diversos proveedores
de contenidos y aplicaciones existan dentro del sistema. Los
metadatos pueden estar en diversas formas, incluyendo parámetros o
reglas de procesamiento, o un manipulador, código o referencia de
procesamiento provisto directamente o un enlace a un manipulador,
código o reglas de procesamiento en otra
posición.
posición.
Como puede verse en la Figura 3, contenido pasa
desde el proveedor 110 de contenidos a la aplicación 150 de cliente
y es ilustrado por la flecha 310. Metadatos, que proporcionan
instrucciones a diversos componentes dentro de la arquitectura 100,
también pueden pasar entre componentes dentro de la arquitectura
100, usualmente junto con el contenido. Por ejemplo, la flecha 320
ilustra metadatos que se originan en el proveedor de contenidos y
son transparentes al sistema de suministro hasta que llegan a una
aplicación 150 de cliente.
La flecha 330 muestra metadatos creados por el
proveedor 110 de contenidos y que están destinados al cliente 140
de servicio de envío, y por tanto solo fluyen al cliente genérico
140 de servicio de envío.
La flecha 340 ilustra metadatos generados por el
proveedor 120 de servicios y destinados al cliente 140 de servicio
de envío, y por tanto son asociados primero con el contenido en el
proxy 122 de servicio de envío y quitados del contenido en el
cliente genérico 140 de servicio de envío. Ejemplos de donde podría
ocurrir esto incluyen acuerdos entre un usuario y un proveedor de
servicios con respecto a un plan de facturación y al nivel de
servicio a ser provisto, donde el proveedor de servicios puede usar
los metadatos para limitar los servicios disponibles o proporcionar
servicios realzados.
El flujo de metadatos y el papel de los
metadatos son descritos con más detalle después.
Ahora se hace referencia a la Figura 4. La
Figura 4 ilustra un proxy ejemplar detallado 410 de servicio de
envío que puede ser usado en asociación con el presente sistema y
método. Como será apreciado por los expertos en la técnica, el
proxy 410 de servicio de envío podría ser igual que el proxy 122 de
servicio de envío de las Figuras 1 y 2.
El proxy 410 de servicio de envío de la Figura 4
incluye diversos elementos que permiten que el proxy 410 de
servicio de envío funcione en un entorno de servicio de envío
genérico. Esto facilita la flexibilidad puesto que el proxy de
servicio de envío no está limitado a la interacción con proveedores
de contenidos o clientes de servicio de envío específicos sino que
en cambio puede ser adaptada a un entorno dinámico. Los elementos
descritos a continuación para el proxy 410 de servicio de envío
están preferiblemente dentro del proxy 410 de servicio de envío
pero los elementos no son exhaustivos y otros elementos son
posibles. Además, ciertos elementos pueden ser omitidos del proxy
410 de servicio de envío, con los elementos restantes capaces
todavía de realizar servicios de envío genéricos.
El proxy 410 de servicio de envío incluye
proveedores 412 de contenidos (PC_{1}, PC_{2},.., PC_{N})
registrados en él. Los proveedores 412 de contenidos se registran en
una interfaz 420 de proveedor de servicios (SPI) de registro de
proveedores de contenidos. Como se describe con más detalle después,
en este registro es deseable que el proveedor 412 de contenidos
incluya cierta información para el canal que es establecido,
denominada en esto como metadatos de canal. Los proveedores 412 de
contenidos pueden ser iguales que los proveedores 110 de contenidos
de la Figura 1.
El proxy 410 de servicio de envío incluye además
un bloque 430 de administración de servicios para administrar el
servicio de proxy de envío.
El proxy 410 de servicio de envío incluye
diversos módulos para ocuparse tanto del contenido como de los
metadatos asociados con ese contenido. Un primer módulo es la cola
440 de intercambio y suministro de mensajes que es un subsistema
que consume mensajes procedentes del proveedor 412 de contenidos y
gestiona la cola de suministro de contenidos. Como será apreciado
por los expertos en la técnica, no todo el contenido para todas las
aplicaciones de cliente puede sr suministrado a la vez y una cola
de suministro necesita ser establecida para suministrar el
contenido a su debido tiempo. Por ejemplo, un dispositivo puede
estar fuera de cobertura y el contenido puede precisar ser
almacenado.
El proxy 410 de servicio de envío incluye además
un bloque 442 de gestión de control de flujo. El bloque 442 de
gestión de control de flujo tiene en cuenta el control del flujo de
contenido. Por ejemplo, una estación móvil con espacio limitado
solo puede ser capaz de recibir una cierta cantidad de información.
En este caso, el dispositivo móvil, a través de un cliente 140 de
servicio de envío como se ilustra en la Figura 1, puede pedir al
proxy 410 de servicio de envío que detenga el flujo de datos al
cliente 140 de servicio de envío. El bloque 442 de gestión de
control se ocupa de esto.
Alternativamente, el dispositivo móvil puede
estar fuera de línea. El bloque 442 de gestión de control de flujo
para e inicia el flujo de datos al cliente 140 de servicio de envío
cuando contenido no puede ser suministrado como es recibido por el
proxy 410 de servicio de envío.
Un componente más del proxy 410 de servicio de
envío es el bloque 444 de agentes de servicio de envío. Los agentes
444 de servicio de envío son responsables de enviar datos a
clientes.
Como será apreciado por los expertos en la
técnica, los bloques 440, 442 y 444 tratan de mensajería solamente
y no están relacionados con metadatos. En otras palabras, los
bloques manejan el contenido de los mensajes pero no cualesquier
metadatos asociados con el contenido.
Un componente más de proxy 410 de servicio de
envío es el bloque 450 de extractor y antememoria de metadatos de
contenido. El bloque 450 de extractor y antememoria de metadatos de
contenido funciona sobre metadatos de contenido envueltos.
Específicamente, en el modelo de envoltura de sistema de metadatos,
que es descrito con más detalle después, cada componente lógico
dentro del sistema puede tener metadatos asociados con el
procesamiento de contenido. Estos metadatos permiten que el
componente lógico realice acciones sobre el contenido. Así, cada
componente lógico necesita ser capaz de extraer los metadatos que
están asociados con él.
El bloque 450 de extractor y antememoria de
metadatos de contenido es responsable de extraer metadatos que
están asociados con el proxy 410 de servicio de envío y para
almacenar en antememoria estos metadatos. La función de
almacenamiento en antememoria permite la optimización eliminando la
necesidad de pasar metadatos idénticos en envolturas de contenido
subsiguientes procedentes del mismo proveedor de contenidos. La
extracción y el almacenamiento en antememoria de metadatos son
descritos a continuación.
El bloque 452 de almacenamiento de mensajes de
recuperación aplazada es usado cuando no es eficaz para suministrar
contenido, o partes de él, a una aplicación de cliente. El bloque
452 de almacenamiento de mensajes de recuperación aplazada puede
ser usado para almacenar contenido que no es suministrado al cliente
hasta que es eficaz enviar el contenido o hasta que el contenido es
extraído por el cliente. El almacenamiento de mensajes de
recuperación aplazada también podrían ser usado para almacenar en
antememoria contenido auxiliar que opcionalmente podría ser enviado
a, o extraído por, el cliente dependiendo de la navegación de
aplicación de cliente a través de contenido ya suministrado.
El propósito del bloque 452 de almacenamiento de
mensajes de recuperación aplazada es mejor explicado después con
referencia a las Figuras 19 y 21. A modo de ejemplo, el bloque 452
de almacenamiento de mensajes de recuperación aplazada puede ser
usado en el caso donde un usuario ha solicitado información de
posición, tal como un restaurante próximo a la posición del
usuario. El proveedor de contenidos o el proveedor de servicios
puede tener un modelo de proporcionar información donde los
anunciantes pueden pagar para añadir su información a solicitudes de
búsqueda. Así, el usuario que está solicitando información de
restaurantes para una posición también puede tener información
sobre almacenes, campos de golf, gimnasios u otros servicios
próximos a su posición atendida para su solicitud. Un proveedor de
contenidos envuelve la información de restaurantes solicitada con la
información adicional y la pasa al proxy 410 de servicio de
envío.
Basado en los metadatos provistos, el proxy 410
de servicio de envío puede crear un paquete de contenido para
enviar al cliente. El paquete de contenido podría incluir la
información solicitada por el cliente así como un resumen o sumario
de información relacionada en la que el usuario puede estar
interesado. El sumario es enviado al usuario pero el bloque 452 de
almacenamiento de mensajes de recuperación aplazada almacena los
datos reales que fueron recibidos desde el proveedor 110 de
contenidos. Así, si en el futuro el usuario desea obtener más
información detallada sobre información dentro del resumen, esta
información ya está almacenada en el proxy 410 de servicio de
envío.
Un uso alternativo para el bloque 452 de
almacenamiento de mensajes de recuperación aplazada es en el caso
donde un usuario no puede aceptar todo el contenido de una vez. Por
ejemplo, si no es factible o económico enviar todo el contenido al
dispositivo, parte del contenido puede ser almacenada hasta un
momento posterior, cuando puede ser extraído por el cliente o
enviado cuando se cumplen reglas predefinidas. Estas reglas pueden
ser especificadas por las condiciones de servicio o red siendo
satisfechas ciertas condiciones de servicio o red. Esto es descrito
con más detalle con referencia a la Figura 19 más adelante.
El planificador 454 de servicio de envío
planifica ranuras de suministro para clientes. Como se describió
antes, en algunas situaciones puede no ser eficiente enviar todo el
contenido de una vez. El planificador 454 de servicio de envío
puede determinar que enviará alguna información inmediatamente y el
resto según un plan predefinido. Asimismo, el planificador 454 de
servicio de envío puede usar la naturaleza del contenido para
determinar cuando el contenido debería ser enviado. Específicamente,
los metadatos pueden indicar que algún contenido es de alta
prioridad o tiene una terminación que está limitada en el tiempo, y
este contenido puede ser enviado inmediatamente, mientras que
contenido que se ha indicado que tiene una prioridad baja o sin
terminación puede ser enviado posteriormente cuando las condiciones
para pasar datos sean más favorables.
Como será apreciado por los expertos en la
técnica, los bloques 450, 452 y 454 se ocupan tanto del contenido
del mensaje como de los metadatos que están asociados con el
mensaje.
El bloque 460 de suscripciones y reglas rastrea
aplicaciones que están registradas para recibir un servicio y
supervisa las reglas sobre cómo manejar contenido particular que es
suministrado.
Contenido es suministrado típicamente basado en
una suscripción por el cliente o en nombre del cliente. Por
ejemplo, si quieren un servicio particular, el usuario puede
solicitar suscripciones activamente. Las suscripciones puede ser
efectuadas en nombre de un usuario, por ejemplo, si el usuario ha
firmado un acuerdo con su proveedor 120 de servicios para recibir
un beneficio para un servicio. Esto podría incluir el caso donde un
usuario recibe un precio preferido siempre que el usuario esté de
acuerdo en recibir un cierto de número de anuncios cada día. En
este caso, el proveedor 120 de servicios puede efectuar la
suscripción al proveedor de anuncios en nombre del cliente.
Cuando una aplicación es suprimida en un
dispositivo móvil o cuando la aplicación elimina el registro de una
suscripción, el bloque 460 de suscripciones y reglas puede borrar la
suscripción de ese usuario.
El bloque 462 de dependencias de contenido es
usado por el proxy 410 de servicio de envío para anunciar servicios
que un usuario de dispositivo móvil puede utilizar. Así, si un
usuario de dispositivo móvil no tiene una pantalla o anchura de
banda o memoria suficiente para el servicio, el bloque 462 de
dependencias de contenido podría bloquear el anuncio de ese
servicio al usuario.
El bloque 464 de fragmentación de contenido es
usado para fragmentar contenido. Por ejemplo, esto podría ser usado
si el dispositivo móvil es incapaz de recibir todo el contenido de
una vez. El bloque 464 de fragmentación de contenido es usado para
separar el contenido en diversos componentes. Puede ser usado en
asociación con el almacenamiento 452 de mensajes de recuperación
aplazada para almacenar contenido fragmentado que no ha sido
suministrado todavía.
El bloque 466 de terminación y sustitución de
contenido es usado con dos fines. Primero, este bloque puede ser
usado para supervisar suscripciones. Cada suscripción tiene un
tiempo de terminación y cuando este tiempo de terminación se
cumple, la suscripción puede ser terminada.
Asimismo, el bloque 466 de terminación y
sustitución de contenido puede ser usado para supervisar
información. Cierto contenido tendrá límites de tiempo en la
validez de la información. Por ejemplo, una aplicación de tráfico
usada para supervisar el tráfico de hora punta dependerá mucho de la
hora. Si, por alguna razón, el proxy 410 de servicio de envío es
incapaz de suministrar el contenido inmediatamente a un dispositivo
móvil, el contenido es almacenado en el almacenamiento 480 de
contenido para suministro futuro. Sin embargo, si el contenido no
es suministrado dentro de un cierto período especificado de tiempo,
entonces podría terminar y no ser suministrado en absoluto.
De modo similar, la sustitución de contenido se
ocupa de una situación donde la información está siendo actualizada.
Por ejemplo, una aplicación de cliente que está recibiendo
cotizaciones de bolsa puede desear solamente la última cotización
de bolsa. Así, si el proxy 410 de servicio de envío es incapaz de
suministrar la cotización de bolsa al cliente 140 de servicio de
envío y una cotización subsiguiente de bolsa es recibida desde un
proveedor 110 de contenidos, metadatos dentro de la cotización
subsiguiente de bolsa pueden indicar que debería ser usada para
sustituir a la cotización anterior de bolsa. La sustitución de
información almacenada, más bien que añadir toda la información a
una cola de suministro, libera espacio dentro del almacenamiento 480
de contenido.
El depósito 40 de metadatos de canal es usado
para almacenar metadatos de canal, lo que es descrito con más
detalle después.
Lo anterior describe un proxy ejemplar 410 de
servicio de envío que puede ser usado con el método y los sistemas
en esto. Los bloques y elementos del proxy 410 de servicio de envío
permiten que el proxy 410 de servicio de envío sea usado en un
sistema genérico de suministro dinámico de contenidos donde el tipo
de contenido y el manejo del contenido en una aplicación pueden
variar y no están predeterminados.
Ahora se hace referencia a la Figura 5. La
Figura 5 ilustra un cliente 510 de servicio de envío que puede ser
usado en asociación con el sistema y los métodos en esto. El cliente
510 de servicio de envío puede ser igual que el cliente 140 de
servicio de envío de las Figuras 1 y 2.
Como será apreciado por los expertos en la
técnica, un cliente 510 de servicio de envío que ha de ser usado en
un sistema genérico en el que el contenido y el procesamiento del
contenido no están predeterminados, debería incluir bloques o
módulos que puedan ser usados para acomodar tanto el contenido como
los metadatos asociados con el contenido. Los bloques definidos con
respecto a la Figura 5 no pretenden ser exhaustivos, y otros bloques
también podrían existir dentro de un cliente 510 de servicio de
envío. Además, los bloques dentro del cliente 510 de servicio de
envío pueden, en algunos casos, ser omitidos sin limitar la
funcionalidad de los otros bloques dentro del cliente 510 de
servicio de envío.
Un cliente 510 de servicio de envío da servicio
a aplicaciones y una o más aplicaciones 512 (A_{1}, A_{2},..,
A_{N}) pueden registrarse en el cliente 510 de servicio de envío.
El registro de aplicación usa una interfaz 514 de proveedor de
aplicaciones como la interfaz para registro y la interfaz 514 de
proveedor de aplicaciones puede ser usada además para extraer
metadatos de canal para la aplicación, como se describe con más
detalle después.
El cliente 510 de servicio de envío incluye la
administración 520 de cliente usada para administrar el cliente 510
de servicio de envío.
Como con el servidor 410 de servicio de envío de
la Figura 4, el cliente 510 de servicio de envío incluye diversos
bloques que se ocupan de mensajería, diversos bloques que se ocupan
de metadatos y diversos bloques que se ocupan tanto de mensajería
como de metadatos.
Las colas 540 de aplicaciones e intermediarios
de mensajes manejan mensajes procedentes del proxy 410 de servicio
de envío para suministro a aplicaciones 512. Una cola de
aplicaciones es una cola de mensajes para aplicaciones 512.
El bloque 542 de gestión de control de flujo es
usado para notificar al proxy 410 de servicio de envío de la Figura
4 que deje de enviar contenido o que reanude el envío de contenido.
Por ejemplo, esto puede ser usado cuando el cliente 510 de servicio
de envío tiene una cantidad limitada de memoria que puede aceptar
contenido enviado. En este caso, antes de que el contenido de
servicio de envío sea consumido, el cliente 510 de servicio de
envío necesita detener el flujo de contenido desde el proxy 410 de
servicio de envío. Una vez que el contenido ha sido consumido, el
bloque 542 de gestión de control de flujo puede ser usado para
iniciar el flujo de datos nuevamente.
Los agentes 544 de servicio de envío dentro del
cliente 510 de servicio de envío son usados para recibir información
desde el proxy 410 de servicio de envío de la Figura 4.
Como será apreciado por los expertos en la
técnica, las colas 540 de aplicaciones e intermediarios de mensajes,
el bloque 542 de gestión de control de flujo y los agentes 544 de
servicio de envío se ocupan exclusivamente de mensajería y no de
metadatos.
El bloque 550 de extractor y antememoria de
metadatos de contenido es usado para extraer metadatos dinámicos
destinados al cliente 510 de servicio de envío. Como se indicó antes
con referencia al proxy 410 de servicio de envío de la Figura 4,
cualesquiera de los elementos de procesamiento en la arquitectura de
suministro dinámico de contenidos podrían tener metadatos
destinados para ellos y es necesario extraer estos metadatos. Así,
los metadatos destinados al cliente 510 de servicio de envío son
extraídos por el bloque 550 de extractor y antememoria de metadatos
de
contenido.
contenido.
Además, el bloque 550 de extractor y antememoria
de metadatos de contenido está adaptado preferiblemente a almacenar
metadatos en antememoria. Los metadatos para el cliente 510 de
servicio de envío que no cambian entre un primer paquete de
contenido y un segundo paquete de contenido no necesitan ser
pasados, ahorrando tiempo de procesamiento en el cliente 510 de
servicio de envío al no precisar la extracción de estos metadatos,
y ahorrando además recursos de red al no precisar que metadatos para
el cliente 510 de servicio de envío sean pasados por la red
inalámbrica 130.
El gestor 552 de recuperación aplazada es usado
para analizar fragmentos de contenido que son recibidos y poner el
contenido junto en el modo correcto. Como se describe con más
detalle después, los datos pueden ser lineales o no lineales. Si
los datos son no lineales, entonces son necesarios metadatos para
reconstituirlos, y esto es efectuado por el gestor 552 de
recuperación aplazada. El gestor 552 de recuperación aplazada
también está adaptado para analizar un resumen de información
disponible en el almacenamiento 452 de recuperación aplazada del
proxy 410 de servicio de envío y acciona al intermediario 554 de
extracción de contenido (descrito después) para recuperar esta
información cuando es requerida por el usuario. Esto incluye
recuperación predictiva cuando la navegación de contenido entra en
un cierto ramal del gráfico de estructura de contenido o cuando las
condiciones de coste o anchura de banda son satisfechas.
El intermediario 554 de extracción de contenido
es usado en un modelo de envío/extracción donde el cliente 510 de
servicio de envío también es capaz de extraer contenido en ciertas
situaciones. Tales situaciones son descritas después con más
detalle con referencia a la Figura 19.
Como será apreciado por los expertos en la
técnica, el bloque 550 de extractor y antememoria de metadatos de
contenido, el gestor 552 de recuperación aplazada y el intermediario
554 de extracción de contenido se ocupan tanto de contenido de
mensajería como de metadatos.
El bloque 560 de gestión de suscripciones es
igual que el bloque 460 de suscripciones y reglas de la Figura 4.
Específicamente, el bloque 560 de gestión de suscripciones es usado
para gestionar suscripciones. Si una aplicación elimina el registro
o es suprimida de un dispositivo móvil, entonces el bloque 560 de
gestión de suscripciones termina la suscripción. El bloque 560 de
gestión de suscripciones también puede volver a suscribir en nombre
de una aplicación de cliente cuando termina el canal de
suscripción.
El bloque 562 de notificación de actualización
trabaja con aplicaciones de cliente y es usado para notificar a las
aplicaciones que contenido nuevo está esperándolas. Esto puede ser
efectuado de tres modos:
- a.
- Un primer modo en el que el bloque 562 de notificación de actualización puede notificar a una aplicación 512 es que el cliente 510 de servicio de envío envíe el contenido de la aplicación 512 directamente.
- b.
- Un segundo modo en el que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 de contenido nuevo es almacenar el contenido en el almacenamiento 580 de contenido y notifica opcionalmente a las aplicaciones 512 que contenido está esperando. En este caso, la notificación es opcional. Específicamente, si una aplicación 512 conoce que la información destinada para ella está almacenada dentro de un bloque específico de memoria, una opción para la aplicación que descubre que tiene datos nuevos es sondear periódicamente la posición de memoria para ver si ha habido algo escrito en ella. Alternativamente, el bloque 562 de notificación de actualización puede enviar un mensaje a la aplicación 512 indicando que tiene datos nuevos y posiblemente la posición en la que los datos están almacenados.
- c.
- Un tercer modo en el que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 de contenido nuevo es almacenar el contenido internamente y notificar a la aplicación. Entonces, la aplicación puede pedir al cliente de servicio de envío que recupere el contenido.
El bloque 564 de dependencias de contenido es
igual que el bloque 462 de dependencias de contenido de la Figura
4, y puede determinar si anunciar el servicio al dispositivo
móvil.
El bloque 566 de terminación y sustitución de
contenido es igual que el bloque 466 de terminación y sustitución
de contenido de la Figura 4. Así, la terminación de contenido y la
sustitución de contenido pueden ser manejadas en el cliente 510 de
servicio de envío además de en el servidor de servicio de envío o
proxy de servicio de envío.
El depósito 570 de metadatos de canal es usado
para almacenar metadatos de canal para la aplicación 512.
El módulo 575 de procesamiento de actualización
de antecedentes es usado para realizar actualizaciones cuando una
aplicación 512 no está disponible. Por ejemplo, la actualización de
antecedentes permite la sustitución de datos por datos más nuevos
dentro del almacenamiento de aplicación. Después, cuando un usuario
inicia la aplicación, los datos exhibidos por la aplicación con
correctos y actualizados.
El módulo 575 de procesamiento de actualización
de antecedentes usa reglas de procesamiento que traducen contenido
a un formato aceptable para una aplicación. Puede ejecutar y
procesar contenido en el almacenamiento 580 de contenido.
A modo de ejemplo, una lista de tareas que es
actualizada para un contratista durante la noche podría tener
tareas enviadas a ella. La aplicación de tarea no es iniciada
durante este tiempo, y el módulo 575 de procesamiento de
actualización de antecedentes puede ser usado para actualizar el
contenido para la aplicación de tarea. Esto podría ser efectuado
con código para manejar un archivo de "extensible
mark-up language (XML)", y podría existir en el
dispositivo en un archivo denominado "handler.exe". El
bloque575 de procesamiento de actualización de antecedentes en el
cliente 510 de servicio de envío puede ejecutar "handler.exe",
pasando el documento de XML que tiene un parámetro. Entonces, el
manejador (handler) construye la tarea en el formato interno de
aplicación.
Una vez que el bloque 575 de procesamiento de
actualización de antecedentes del cliente 510 de servicio de envío
construye la tarea en el formato interno de aplicación, entonces
puede leer la tarea en la lista de tareas desde el almacenamiento
580 de contenido y adjuntar la tarea nueva a la lista. Después,
puede almacenar lo modificado de vuelta en el almacenamiento 580 de
contenido para cuando la aplicación de tarea conecte inmediatamente
después con el cliente 510 de servicio de envío.
Por tanto, la Figura 5 ilustra un cliente 510 de
servicio de envío que puede ser usado en un sistema genérico de
suministro dinámico de contenido, donde el contenido y el
procesamiento del contenido son dinámicos y no predeterminados. Los
bloques descritos anteriormente con referencia al cliente 510 de
servicio de envío de la Figura 5 son usados para acomodar la
naturaleza dinámica del sistema.
Como se indicó antes con referencia a la Figura
3, el contenido está asociado con metadatos para proporcionar
inteligencia para el procesamiento del contenido. De acuerdo con el
presente método y sistema, los metadatos pueden ser divididos en
dos tipos de metadatos. Específicamente, metadatos estáticos (de
canal) y metadatos dinámicos (de contenido).
Debido a las posibilidades ilimitadas de tipos
de proveedores de contenidos y aplicaciones, los metadatos son
críticos para construir sistemas genéricos. El único modo de manejar
el tipo específico de contenido es mediante metadatos.
Los metadatos estáticos son metadatos que
proporcionan reglas sobre como procesar tipos específicos de
contenido. Los metadatos estáticos pueden ser separados en diversos
niveles de abstracción e incluyen, por ejemplo, información
estructural sobre el propio contenido. Por ejemplo, un documento de
sindicación sencilla en tiempo real (RSS: Real-time
Simple Syndication) podría ser suministrado con una estructura de
RSS 2.0XSD, y todo el contenido procedente de ese proveedor de
contenidos será suministrado con esta estructura.
Un nivel adicional de abstracción para metadatos
estáticos incluye la provisión de reglas de procesamiento para
subtipo de contenido. Esto podría ser específico de aplicación. Así,
por ejemplo, una aplicación de noticias financieras indica que
datos deberían ser extraídos de una corriente RSS de noticias
financieras, almacenados en una posición predefinida, y que la
aplicación debería ser notificada sobre la llegada de la
información. La aplicación siempre exige que el contenido destinado
para ella sea manejado de este modo.
Los metadatos estáticos (también denominados en
esto como metadatos de canal) permanecen iguales durante toda la
suscripción entre la aplicación y el proveedor de contenidos y, así,
los metadatos estáticos pueden ser establecidos una vez para cada
elemento dentro de la arquitectura y para cada canal de suministro
de contenido. En una realización, esto se efectúa en el momento de
registro de la aplicación o del proveedor de contenidos.
Los metadatos dinámicos son metadatos que están
asociados con un fragmento particular de contenido. Por ejemplo,
información de terminación asociada con un fragmento particular de
datos o información y reglas de sustitución asociadas con un
fragmento particular de datos (o sea, el documento K sustituye al
documento L).
Como se indicó antes con referencia a las
Figuras 4 y 5, cada entidad de procesamiento puede recibir tanto
metadatos estáticos como dinámicos que están dirigidos a esa entidad
de procesamiento. Así, el proxy 410 de servicio de envío usa el
bloque 450 de extractor y antememoria de metadatos de contenido para
extraer los metadatos dinámicos, y el módulo 466 de terminación y
sustitución de contenido es usado para sustituir contenido no
suministrado por contenido más nuevo recibido en el proxy 410 de
servicio de envío.
Ahora se hace referencia a la Figura 6. La
Figura 6 ilustra un modelo de envoltura multicapa para metadatos de
contenido.
Un proxy 410 de servicio de envío recibe una
envoltura 610 de servicio de envío que incluye metadatos de
procesamiento de contenido para el servidor proxy 612 y una
envoltura 614 de cliente de servicio de envío. El proxy 410 de
servicio de envío extrae metadatos 612 de procesamiento de contenido
y usa estos metadatos para procesar la envoltura 614 de cliente de
servicio de envío. Los metadatos 612 dictan al proxy de servicio de
envío que hacer con la envoltura 614 de cliente de servicio de
envío.
La envoltura 614 de cliente de servicio de envío
es pasada al cliente 510 de servicio de envío donde es dividida en
una envoltura 620 de contenido y metadatos 622 de procesamiento de
contenido. Los metadatos 622 de procesamiento de contenido son
usados por el cliente 510 de servicio de envío para procesar la
envoltura 620 de contenido. Por ejemplo, esto puede ser usado para
ordenar al cliente 510 de servicio de envío que realice la
sustitución de la envoltura 620 de contenido suministrada
previamente por la última envoltura si la aplicación 150 de cliente
está interesada solamente en la última versión del contenido.
La envoltura 620 de contenido es pasada a la
aplicación 150 de cliente. La envoltura 620 de contenido incluye
metadatos 630 de procesamiento de contenido para la aplicación y la
carga útil 632 de contenido que ha de ser utilizada por la
aplicación 150 de cliente.
\newpage
Como será apreciado por los expertos en la
técnica, el anidamiento (encajadura) de envolturas de acuerdo con
la Figura 6 provee lo necesario para un entorno dinámico rico en el
que el procesamiento puede ocurrir en cualquier elemento de
procesamiento de la arquitectura y en el que el proveedor 110 de
contenidos puede especificar cómo ha de ser tratado el contenido
específico. Eh una realización, los metadatos dirigidos a un
elemento lógico particular son opacos a otros elementos de
procesamiento.
Alternativamente, el proveedor 120 de servicios
también puede añadir metadatos en el proxy 410 de servicio de envío
para procesamiento en el cliente 510 de servicio de envío o en la
aplicación 150 de cliente.
Refiriéndose a la Figura 7, esta figura muestra
el modelo de envoltura de la Figura 6 y los pasos que cada elemento
de procesamiento toma con una envoltura. Como se ilustra en la
Figura 7, el proxy 410 de servicio de envío extrae primero los
metadatos desde la envoltura 610 de servicio de envío. Esto se
efectúa en el paso 710.
En el paso 712, el proxy 410 de servicio de
envío usa los metadatos para procesar la envoltura 614 de cliente
de servicio de envío. En el paso 714, el proxy 410 de servicio de
envío suministra la envoltura 614 de cliente de servicio de envío
al cliente 510 de servicio de envío.
De modo similar, en el paso 720, el cliente 510
de servicio de envío extrae los metadatos 622 de procesamiento de
contenido de la envoltura 614 de cliente de servicio de envío. En el
paso 722, el cliente 510 de servicio de envío usa los metadatos 622
de procesamiento de contenido en la envoltura 620 de contenido. En
el paso 724, el cliente 510 de servicio de envío suministra la
envoltura 620 de contenido a la aplicación 150 de cliente.
En el paso 730, la aplicación 150 de cliente
extrae los metadatos 630 de procesamiento de contenido y en el paso
732 usa los metadatos 630 de procesamiento de contenido en la carga
útil 632 de contenido.
Refiriéndose a la Figura 8, esta figura muestra
el método como se ilustra en la Figura 7 con el paso adicional del
uso de metadatos estáticos o de canal. Específicamente, después de
que los metadatos han sido extraídos en el paso 710 de la envoltura
610 de servicio de envío, el proxy 410 de servicio de envío usa a
continuación los metadatos estáticos de canal para procesar la
envoltura de cliente de servicio de envío en el paso 810. En el
paso 712, el proxy 410 de servicio de envío procesa a continuación
los metadatos dinámicos 612 de procesamiento de contenido. A
continuación, el proxy 410 de servicio de envío suministra la
envoltura 614 de cliente de servicio de envío en el paso 714.
De modo similar, el cliente 510 de servicio de
envío extrae los metadatos 622 de procesamiento de contenido en el
paso 720. Después, en el paso 722, el cliente 510 de servicio de
envío usa los metadatos dinámicos de contenido en los metadatos 622
de procesamiento de contenido antes de suministrar la envoltura 620
de contenido a la aplicación 150 de cliente en el paso 724.
En el paso 730, la aplicación 150 de cliente
extrae primero los metadatos 630 de procesamiento de contenido.
Después, en el paso 830, usa los metadatos de canal en la carga útil
632 de contenido. Después, en el paso 732, la aplicación 150 de
cliente usa los metadatos 630 de procesamiento de contenido en la
carga útil 632 de contenido.
Como será apreciado por los expertos en la
técnica, el modelo anterior tiene en cuenta los metadatos estáticos
a ser aplicados para el canal junto con los metadatos dinámicos que
están asociados con el contenido particular que es enviado.
Ahora se hace referencia a la Figura 9. Como
será apreciado en la Figura 5, el cliente 510 de servicio de envío
puede servir a aplicaciones objetivo múltiples 512 en un dispositivo
móvil. Un mecanismo eficiente de registro de tiempo ejecución es
necesario donde aplicaciones pueden registrarse en el marco de
suministro dinámico de contenido sin interrumpir el servicio para
otras aplicaciones.
Refiriéndose a la Figura 9, el cliente 510 de
servicio de envío incluye tres aplicaciones, específicamente las
aplicaciones 910, 912 y 914 que ya están registradas en el cliente
de servicio de envío. Como se apreciará, el modelo enchufable es
importante porque dispositivos nuevos pueden permitir que tipos
ilimitados de aplicaciones sean instalados en el dispositivo.
Además, las aplicaciones pueden ser instaladas dinámicamente,
produciendo un dispositivo móvil que resulta una plataforma de
aplicaciones. Como el dispositivo puede ser una plataforma de
aplicaciones, debe ser capaz de incorporar dinámicamente
aplicaciones nuevas.
Como se ve en la Figura 9, la aplicación 916
quiere registrarse en el cliente 510 de servicio de envío. La
aplicación 916 incluye un manifiesto 918 de aplicación que, en una
realización preferida, proporciona los metadatos de canal para la
aplicación. Específicamente, el manifiesto 918 de aplicación
proporciona información al cliente 510 de servicio de envío, y
finalmente al proxy 410 de servicio de envío y al proveedor 110 de
contenido de la Figura 1 con los metadatos estáticos para la
aplicación. Esta puede incluir, pero no está limitada a, que tipo
de contenido espera la aplicación, como será suministrado el
contenido, si la aplicación necesita notificación u otra
información de canal que sería evidente para los expertos en la
técnica teniendo en cuenta el presente sistema y método.
Por tanto, la aplicación 916 se registra en el
cliente 510 de servicio de envío, proporcionando el manifiesto 918
de aplicación para establecer un canal a un proveedor de contenidos
para dar servicio a la aplicación 916.
Refiriéndose a la Figura 10, un modelo
alternativo podría ser el modelo descrito con respecto a la
arquitectura 220 de la Figura 2. Específicamente, en el modelo de
la Figura 10, una aplicación 150 de cliente está emparejada con un
cliente 140 de servicio de envío. Cada uno de los pares de
aplicación 150 de cliente/cliente 140 de servicio de envío es
coordinado con un contenedor 1010 de servicio de envío.
Cuando la aplicación 1020 desea registrase en el
contenedor 1010 de servicio de envío, un cliente 140 es creado o,
si ya existe, es usado por el contenedor 1010 de servicio de envío.
Además, en el registro, la aplicación 1020 proporciona un
manifiesto 1030 de aplicación al contenedor 1010 de servicio de
envío, proporcionando de tal modo metadatos de canal (metadatos
estáticos) para la aplicación 1020.
En la Figura 11 se muestra una ilustración
alternativa de la Figura 10. Específicamente, un contenedor 1110 de
servicio de envió gestiona/mantiene un grupo de clientes de servicio
de envío. Cuando una aplicación se registra en el contenedor,
obtiene un cliente dedicado 510 de servicio de envío que en el caso
sencillo podría ser representado por un par de un oyente 1130 por
conector y un manejador de contenido. El cliente de servicio de
envío es devuelto al grupo cuando la aplicación elimina el registro
del contenedor (y el servicio de suministro de contenido) o es
suprimido del dispositivo.
El contenedor 1110 de servicio de envío incluye
conectores 1120 para comunicación. Además, el contenedor 1110 de
servicio de envío incluye oyentes 1130 por conectores y procesadores
1140 de contenidos asignados a conectores particulares.
Como se ve en la Figura 11, diversos pares de
procesador de contenido y oyente por conector son usados para
aplicaciones 150 registradas previamente.
Cuando una aplicación nueva 1150 desea
registrarse en el contenedor 1110 de servicio de envío, un
procesador 1140 de contenido y un oyente 1130 de conector nuevos
son asignados a la aplicación 1050 de servicio.
Por tanto, lo anterior provee lo necesario para
un marco genérico de servicio de envío en el que una aplicación 150
de cliente que es nueva puede ser implementada y registrada en un
cliente 510 de servicio de envío o contenedor 10101 o 1110 de
servicio de envío, permitiendo de tal modo que el dispositivo
resulte una plataforma de aplicaciones capaz de incorporar
dinámicamente aplicaciones nuevas. El paso de un manifiesto 1030 o
918 de las Figuras 9 y 10 anteriores tiene en cuenta el
establecimiento de metadatos de canal, permitiendo de tal modo que
el contenido sea procesado según las exigencias de aplicación.
Refiriéndose a la Figura 12, los proveedores 110
de contenidos necesitan de modo similar registrarse en el proxy 410
de servicio de envío. Como se ve en la Figura 12, el proxy 410 de
servicio de envío incluye tres proveedores de contenidos, es decir
1210, 1212 y 1214, ya registrados en el proxy 410 de servicio de
envío. El proveedor 1216 de contenidos desea registrarse en el
proxy 410 de servicio de envío.
De modo similar que el manifiesto 918 de
aplicación ilustrado en la Figura 9, provisto por una aplicación
916 cuando se registra en el cliente 510 de servicio de envío, el
proveedor 1216 de contenidos incluye un manifiesto 1218 de servicio
que es pasado al proxy 410 de servicio de envío cuando el proveedor
1216 de contenidos se registra. El manifiesto 1218 de servicio
incluye información referente al tipo de información que
proporcionará el proveedor de contenidos, con cuanta frecuencia
proporciona esta información, el formato de la información y
cualquier otra información que sea útil para el servicio o para
anuncio del servicio. Otra información es posible.
Así, el proxy 410 de servicio de envío usa el
manifiesto 1218 de servicio para establece metadatos de canal
(estáticos) para el proveedor 1216 de contenidos.
Refiriéndose a la Figura 13, una realización
alternativa, representada por la arquitectura 230 de la Figura 2,
es tener un contenedor de servicio de envío con un número de
emparejamientos de proxy 122 de servicio de envío y proveedor 110
de contenidos. Como en la Figura 12, diversas aplicaciones ya
podrían estar registradas en el contenedor 1310 de servicio de
envío y, en el ejemplo de la Figura 13, las aplicaciones 1312, 1314
y 1316 ya están registradas en los proxies de servicio de envío
1313, 1315 y 1317 respectivamente.
Una aplicación nueva 1320 desea registrarse en
el contenedor 1310 de servicio de envío. Así, el contenedor 1310 de
servicio de envío crea un proxy nuevo (no mostrado) o usa un proxy
existente (no mostrado) con el que asocia al proveedor 1320 de
contenidos. Además, el proveedor 1320 de contenidos proporciona el
manifiesto 1322 de servicio para describir el contenido que el
proveedor 1320 de contenidos estará proporcionando, permitiendo de
tal modo el establecimiento de metadatos de canal.
Como será apreciado por los expertos en la
técnica, las realizaciones de las Figuras 9 y 10 muestran dos
opciones para clientes de servicio de envío, con aplicaciones
compartidas o con clientes dedicados de servicio de envío por
aplicación. Un experto en la técnica comprenderá que otras
realizaciones son posibles. De modo similar, con respecto a las
Figuras 12 y 13, se muestra un proxy de servicio de envío con
proveedores múltiples de contenidos registrados en él o se muestra
un proxy dedicado de servicio de envío para cada proveedor de
contenidos, y materializado en un contenedor de servicio de
envío.
Con referencia a la Figura 14, se muestra la
mensajería entre un proveedor 110 de contenidos y una aplicación
150 de cliente. El proveedor 110 de contenidos proporciona un
mensaje de registro al proxy 410 de servicio de envío. Este mensaje
puede incluir el manifiesto de servicio que puede ser usado para
proporcionar metadatos de canal al proxy 410 de servicio de envío.
Esto se efectúa en el paso 1410.
El proveedor 110 de contenidos puede también, o
alternativamente, proporcionar metadatos de canal en un mensaje
subsiguiente, como es ilustrado por el paso 1412.
Después, el proxy 410 de servicio de envío añade
un servicio a una lista de servicios disponibles (el catálogo de
servicio) en el paso 1414.
En el ejemplo de la Figura 14, un paso opcional
es que el proxy 410 de servicio de envío notifique al cliente 510
de servicio de envío el nuevo servicio disponible en el paso 1416 y
está notificación puede ser propagada a una aplicación 110 de
cliente en el paso 1418.
Como será apreciado por los expertos en la
técnica, los pasos 1416 y 1418 son opcionales, y otras alternativas
incluyen que la aplicación 150 de cliente extraiga el catálogo de
servicios periódicamente desde el proxy 410 de servicio de envío
para ver servicios nuevos.
Cuando un usuario o proveedor de servicios para
la aplicación 150 de cliente decide que la aplicación 150 de
cliente debería suscribirse a un servicio, envía un mensaje de
suscripción en el paso 1420. El mensaje de suscripción es pasado
además al proxy 410 de servicio de envío en el paso 1422.
Una vez que el proxy 410 de servicio de envío
recibe el mensaje de suscripción en el paso 1422, dos opciones
están disponibles. Una primera opción es enviar un mensaje 1424 al
proveedor 110 de contenidos para una suscripción y después recibir
una envoltura de mensaje que incluye metadatos de vuelta en el paso
1426. Los metadatos podrían ser específicos de dispositivo o de
tipo de dispositivo.
Alternativamente, el proxy 410 de servicio de
envío puede recibir el mensaje de suscripción en el paso 1422 e
inmediatamente, basado en información ya provista por el proveedor
110 de contenidos y almacenada en el proxy 410 de servicio de
envío, responder en el paso 1430 al cliente 510 de servicio de
envío. Esta respuesta es propagada a la aplicación 150 de cliente
en el paso 1432. Como se apreciará, la respuesta puede incluir
metadatos de canal específicos para el proveedor 110 de
contenidos.
La diferencia en modelos puede depender de quién
está personalizando los datos para la aplicación. Como se
apreciará, el proveedor 110 de contenidos proporciona la mejor
personalización de contenido comparado con otros elementos de
procesamiento. Sin embargo, el proveedor 120 de servicios, a través
del proxy 410 de servicio de envío, también puede proveer lo
necesario para la personalización de contenido.
Además, como se apreciará, la estructura del
contenido podría depender de los datos que la aplicación necesita.
Por ejemplo, en una aplicación financiera, la aplicación puede
querer tanto cotizaciones de bolsa como cambios de divisas. El XML
(Extensible Mark-up Language) siguiente puede ser
usado:
\vskip1.000000\baselineskip
Si el usuario solo quisiera cotizaciones de
bolsa y no cambio de divisas, la estructura podría cambiar a:
-
101
Los metadatos pueden proporcionar información a
la aplicación sobre la estructura de los datos que son pasados.
Así, existen dos modelos. Metadatos estáticos
pueden ser provistos al proxy 410 de servicio de envío y al cliente
510 de servicio de envío durante el registro o después.
Alternativamente, los metadatos para el proxy 410 de servicio de
envío y el cliente 510 de servicio de envío pueden ser
aprovisionados previamente, o sea, la información es almacenada en
un cliente de servicio de envío o un proxy de servicio de envío
hasta que una aplicación se registra en un cliente.
Ahora se hace referencia a la Figura 15. La
Figura 15 muestra pasos lógicos que ocurren en el registro de una
aplicación en un cliente 510 de servicio de envío.
Una vez que una aplicación se registra en el
cliente 510 de servicio de envío, un primer paso 1510 es emparejar
la aplicación registrada con el tipo de contenido requerido por la
aplicación. Este es conocido por el manifiesto 918 de aplicación
como se ilustra en la Figura 9.
Un segundo paso 1520 es establecer el entorno
para la aplicación. Estos incluyen, pero no están limitados a,
opciones de almacenamiento y suministro para la aplicación. Por
ejemplo, una aplicación puede limitar las transmisiones a una
cantidad predeterminada de datos. El cliente 510 de servicio de
envío en un suceso de control de flujo, o si la aplicación o el
cliente ha perdido el contacto, puede requerir el almacenamiento en
antememoria de los datos para la aplicación y, opcionalmente,
notificar a la aplicación que hay datos esperando.
Un tercer paso 1530 es notificar al proxy 410 de
servicio de envío los ajustes de aplicación. Por ejemplo, esto
incluye almacenamiento disponible para la aplicación o el cliente
510 de servicio de envío. Como se apreciará, el proxy 410 de
servicio de envío no debería enviar más datos que los que puede
almacenar el cliente 510 de servicio de envío. Así los ajustes de
aplicación podrían incluir un límite superior de los datos que son
pasados. Refiriéndose a las Figuras 4 y 5, esto podría invocar al
bloque 464 de fragmentación de contenido para fragmentar el
contenido si es mayor que el que la aplicación puede procesar.
Asimismo, si los datos no son lineales, el bloque 462 de
dependencias de contenido puede ser requerido para crear metadatos
para el bloque 564 de dependencias el contenido de la Figura 5 para
permitir que el bloque 564 de dependencias de contenido reconstituya
los datos.
Refiriéndose nuevamente a la Figura 15, el paso
1530 también puede indicar preferencia sobre el suministro de
datos. Por ejemplo, la aplicación puede preferir ciertos tipos de
datos respecto a otros y estos tipos de datos pueden obtener
prioridad. Así, el paso 1530 puede ser usado para establecer un plan
de suministro donde los datos de tipo "A" son suministrados
inmediatamente mientras que los datos de tipo "B" pueden ser
suministrados en un tiempo aplazado.
Ahora se hace referencia a la Figura 16. Cuando
un proveedor 110 de contenidos se registra en un proxy 410 de
servicio de envío, diversos pasos son efectuados. Un primer paso
1610 incluye analizar los ajustes necesarios de cliente para
almacenamiento y suministro de contenido. Por ejemplo, esto puede
ser usado para anuncio de servicio a fin de identificar clientes
510 de servicio de envío en dispositivos capaces de consumir
contenido procedente del proveedor 110 de contenidos.
Un segundo paso 1620 permite que el proxy 410 de
servicio de envío establezca el entorno, incluyendo almacenamiento
de proxy, opciones de suministro, opciones de transformación, entre
otros.
En el paso 1630, el proxy 410 de servicio de
envío puede comprobar si la aplicación ya está registrada para
obtener contenido desde un proveedor 110 de contenidos. Si este es
el caso, la aplicación está dispuesta a recibir contenido y puede
ser enviada una notificación desde el proxy 410 de servicio de envío
al proveedor 110 de contenidos de que el canal de suministro está
establecido y la aplicación está dispuesta para contenido.
Por ejemplo, el paso 1630 puede ocurrir si una
aplicación es preinstalada en un dispositivo antes de que el
proveedor 110 de contenidos esté en línea. Así, la aplicación está
esperando que el proveedor 110 de contenidos resulte disponible o
la aplicación es de tipo genérico (por ejemplo, un explorador o
Visor de RSS (RDF Site Summary: Resource Description Framework Site
Summary = sumario de sitios de marco de descripción de recursos)) y
es capaz de consumir información procedente de proveedores múltiples
de contenidos. En un ajuste alternativo, si el proveedor 110 de
contenidos ya está disponible antes de que la aplicación sea
instalada, el paso 1530 de notificación en la Figura 15 pude ser
usado para iniciar que el contenido empiece a fluir desde el
proveedor 110 de contenidos a una aplicación 150 de cliente.
Como se apreciará con referencia a la Figura 16,
los ajustes de cliente pueden incluir cierta información tal como
el tamaño de almacenamiento disponible usado para la división de
contenido, el tamaño de cola usado para control de flujo,
planificación de suministro que incluye un intervalo de servicio de
envío, si el cliente está recuperando información desde el proxy,
creando un modo de envío falso, opciones de personalización tal
como el tamaño de pantalla de un dispositivo móvil, entre otros.
Como se apreciará además, los catálogos de
servicios pueden variar para clientes diferentes. Por ejemplo,
ciertos clientes pueden ser capaces de utilizar más datos, tener un
tamaño diferente de pantalla u otras condiciones que hacen al
cliente más adecuado para un proveedor 110 de contenidos que un
dispositivo que no puede manejar esta cantidad de información,
tiene un tamaño menor de pantalla, etc. Así, el proxy 410 de
servicio de envío puede crear un catálogo de servicios para
aplicaciones específicas de cliente basado en el conocimiento de
esas aplicaciones de cliente, y solo los dispositivos con esa
aplicación 150 de cliente instalada pueden recibir información
referente al proveedor de contenidos.
Como se apreciará además, en algunos casos la
aplicación puede ser instalada basada en un proveedor de servicios
y un proveedor de contenidos sin la intervención de usuario. Por
ejemplo, si el proveedor 110 de contenidos se registra en el proxy
410 de servicio de envío, un usuario de un dispositivo móvil puede
tener una obligación contractual de aceptar una cierta aplicación.
Así, el proxy 410 de servicio de envío podría notificar al cliente
510 de servicio de envío que está dispuesto al instalar una
aplicación y enviar la aplicación al cliente 510 de servicio de
envío. Por ejemplo, esto podría incluir un usuario que ha acordado
recibir un cierto número de anuncios cada mes para obtener un
precio preferido en su plan móvil. El proveedor 110 de contenidos
podría ser un proveedor de anuncios y el proxy 410 de servicio de
envío puede, por tanto, enviar un anuncio que exhibe la aplicación
al cliente 510 de servicio de envío, que podría ser servida por un
instalador de aplicación registrado en el cliente 510 de servicio
de envío, teniendo de tal modo que el proveedor 110 de contenidos y
el proveedor 120 de servicios accionan completamente el proceso.
Por tanto, lo anterior provee lo necesario para
un modelo de registro enchufable en un marco de servicio de envío
donde cada aplicación o proveedor de contenidos se registra y
proporciona un manifiesto de aplicación o un manifiesto de servicio
respectivamente. El manifiesto de aplicación o el manifiesto de
servicio es usado para establecer metadatos de canal en el proxy
410 de servicio de envío y el cliente 510 de servicio de envío
durante el registro o posteriormente. Después, cuando una aplicación
150 se registra y un proveedor 110 de contenidos ser registra,
contenido puede empezar a fluir entre la aplicación 150 y el
proveedor 110 de contenidos.
Con referencia a las Figuras 4 y 5, los
metadatos de canal son almacenados en un depósito 470 o 570 de
metadatos de canal. Sin embargo, también es ventajoso almacenar
metadatos dinámicos en los diversos elementos de procesamiento
dentro de la arquitectura 100 si los metadatos dinámicos son
repetidos. Como se apreciará, esto ahorrará procesamiento en el
proxy 410 de servicio de envío puesto que el extractor actual 450 de
metadatos no necesita extraer los mismos metadatos repetidamente.
Además, el procesamiento por diversos módulos, tal como el modulo
466 o 566 de terminación y sustitución de contenido, no necesita
ser actualizado para cada fragmento de contenido que es pasado.
Como el proxy 410 de servicio de envío podría estar trabajando con
un gran número de clientes 510 de servicio de envío, este ahorro de
procesamiento para cada mensaje de contenido podría ser
significativo. Además, anchura de banda podría ser ahorrada no
teniendo que pasar los metadatos por una línea fija entre el
proveedor 110 de contenidos y el proxy 410 de servicio de envío o
por el aire entre el proxy 410 de servicio de envío y el cliente
510 de servicio de envío.
Ahora se hace referencia a la Figura 17. La
Figura 17 ilustra un ejemplo de flujo de tiempo de ejecución donde
su última versión de metadatos es almacenada por el elemento de
procesamiento.
Como se ve en la Figura 17, el proveedor 110 de
contenidos proporciona una envoltura de contenido que incluye el
contenido [C_{1}+M(p,c,a)_{1}]. Esto significa que
una primera carga útil de contenido está siendo enviada junto con
metadatos que incluyen metadatos de proxy, metadatos de cliente y
metadatos de aplicación. Esto es enviado en el paso 1710.
En el paso 1712, el proxy 410 de servicio de
envío usa los metadatos de proxy como es ilustrado por la frase
"usar M(p)_{1}". Además, en el paso 1714, el
contenido más los metadatos que incluyen los metadatos de cliente y
los metadatos de aplicación son pasados al cliente 510 de servicio
de envío.
En el paso 1716, el cliente 510 de servicio de
envío usa los metadatos de cliente y además, en el paso 1718, pasa
la carga útil de contenido a la aplicación 150 de cliente. En el
paso 1720, la aplicación 150 de cliente usa los metadatos de
aplicación y además consume la carga útil de contenido.
Como se ve en el paso 1722, una segunda carga
útil de contenido, designada por C_{2}, tiene los mismos metadatos
que la primera carga útil de contenido. Como cada elemento de
procesamiento, es decir el proxy 410 de servicio de envío, el
cliente 510 de servicio de envío y la aplicación 150 de cliente,
almacenó en antememoria los metadatos para el proveedor 110 de
contenidos, los metadatos no necesitan ser pasados otra vez sino en
cambio ya residen en el elemento de procesamiento.
Después, en el paso 1724, el proxy 410 de
servicio de envío usa metadatos que fueron almacenados previamente
en antememoria para el proxy 410 de servicio de envío. De modo
similar, en los pasos 1726 y 1728, el cliente 510 de servicio de
envío usa los metadatos de cliente y la aplicación 150 de cliente
usa los metadatos de aplicación, respectivamente. En los pasos 1725
y 1727, contenido es pasado sin metadatos.
Como se ilustra en el paso 1740, el contenido
puede tener metadatos nuevos para el cliente 510 de servicio de
envío y la aplicación 150 de cliente pero puede mantener los
metadatos antiguos para el proxy 410 de servicio de envío. En este
caso, los metadatos que son pasados en el paso 1740 incluyen solo
metadatos de cliente y metadatos de aplicación. En el paso 1742, el
proxy 410 de servicio de envío usa los metadatos de proxy
almacenados en antememoria y, en el paso 1744, pasa la carga útil
de contenido junto con los metadatos de cliente y los metadatos de
aplicación nuevos.
En el paso 1746, el cliente 510 de servicio de
envío usa los nuevos metadatos de cliente que fueron pasados a él
y, en el paso 1748, pasa además la carga útil de contenido y los
metadatos de aplicación.
En el paso 1750, la aplicación de cliente usa
los nuevos metadatos de aplicación y consume además la carga útil
de contenido.
Como será apreciado por un experto en la
técnica, podrían existir diversas configuraciones referentes a que
metadatos han cambiado y que metadatos permanecen iguales, y solo
los metadatos que han cambiado son pasados al elemento de
procesamiento que los necesita. Como será apreciado por los expertos
en la técnica, el elemento de procesamiento, si no recibe metadatos
nuevos, vuelve a los metadatos almacenados en antememoria que ha
almacenado y usa estos en la carga útil de contenido.
En una realización alternativa adicional,
cambios incrementales también pueden ser efectuados en metadatos.
Por ejemplo, en el paso 1760, una nueva carga útil de contenido
junto con una versión de incremento de metadatos pueden ser pasadas
para servir al proxy 410. El incremento de los metadatos de proxy
puede incluir una diferencia entre los metadatos de proxy pasados
anteriormente y los metadatos actuales con los que el contenido
debería ser procesado. El proxy 410 de servicio de envío compone
los metadatos sumando los metadatos anteriores con el incremento y
usando después estos para procesar la carga útil de contenido en el
paso 1762. Después, como no ha habido cambio, en el paso 1764, la
carga útil de contenido es enviada por sí misma y, en el paso 1766,
el cliente 510 de servicio de envío usa los metadatos de cliente
almacenados previamente en antememoria.
Después, en el paso 1768, el cliente de servicio
de envío pasa la carga útil de contenido a la aplicación 150 de
cliente que usa los metadatos de posición almacenados previamente en
antememoria en la carga útil de contenido, en el paso 1770, y
después consume la carga útil de contenido.
Un ejemplo de donde pueden usarse datos
incrementales es una situación en la que un proveedor de contenidos
comunica al proxy que, de los campos existentes dentro de la carga
útil de contenido, 30 deberían ser extraídas para enviar a la
aplicación 150 de cliente. En una transacción subsiguiente, dos
campos adicionales que son importantes para ese fragmento de carga
útil de contenido pueden ser considerados necesarios para ser
pasados a la aplicación 150 de cliente por el proveedor 110 de
contenidos. Por tanto, el proveedor de contenidos podría, usando un
cambio incremental, ordenar al proxy de servicio de envío que
extraiga los dos campos adicionales y los añada a los 30 campos que
fueron extraídos previamente. Teniendo solo que pasar el incremento,
o sea los dos campos adicionales, es reducido el tiempo de
procesamiento para extraer los metadatos en el proxy 410 de
servicio de envío, optimizando de tal modo el proceso.
Como se apreciará adicionalmente, los metadatos
pueden venir en diversas formas. Podrían ser compilados tal como
código nativo o código interpretado tal como Java o C#. Los
metadatos también pueden ser un archivo de datos/propiedades que
indica usar ciertas propiedades. En otra realización alternativa,
pueden ser contenido binario, por ejemplo una transformación tal
como una transformación XSLT (Extensible Style-Sheet
Language Transformation = transformación de lenguaje extensible de
hojas de estilo) o un documento en XML (Extensible Markup
Language).
Lo anterior puede ser usado para que diversas
aplicaciones proporcionen inteligencia para contenido que es
transferido a una aplicación específica de cliente. También puede
proveer lo necesario para proveedores ricos de contenidos que
pueden proporcionar contenido para diversas aplicaciones basado
simplemente en los metadatos que proporcionan con sus datos. Esto
puede ser ilustrado a modo de ejemplo en la Figura 18.
Por ejemplo, un proveedor 110 de contenidos
podría ser un librero en línea. Una aplicación puede registrarse en
el librero en línea para indicar al librero en línea que quiere ser
informado de publicaciones nuevas de un género específico. Esto
podría ocurrir sobre una base diaria, semanal o mensual.
El proveedor 110 de contenidos, por ejemplo,
enviará semanalmente una envoltura 1810 de contenido, que tiene una
lista 1812 de libros, al proxy 410 de servicio de envío. También
puede enviar metadatos 1814 de transformada que puede ser por
ejemplo, un enlace de URL (Uniform Resource Locator = localizador
uniforme de recursos) para transformar el contenido específico
basado en la aplicación que lo recibe.
En una realización, la lista 1812 de libros
podría incluir numerosos libros, descripciones de cada libro que
incluyen el autor y una sinopsis del libro. Por ejemplo, el archivo
puede tener un tamaño de 100 KB.
El proxy 410 de servicio de envío puede recibir
este archivo grande y puede comprender, basado en la aplicación de
cliente que es servida, que es necesario efectuar una transformación
en el archivo de contenido grande para adaptarse mejor al cliente
que solo puede ser capaz de recibir, por ejemplo, 10 kilobytes (KB)
de información. La transformación que es pasada como metadatos de
proxy puede, por tanto, ser aplicada a la lista de libros para
reducir la lista de libros a un documento modificado 1820 de 10 KB.
Por ejemplo, esto puede ser efectuado eliminando la sinopsis,
clasificando los libros e incluyendo solo los 50 superiores u otras
transformaciones como serían evidentes para los expertos en la
técnica.
Una vez que la transformación es completa,
entonces el documento modificado 1820 es enviado al cliente 510 de
servicio de envío.
Además, el almacenamiento 452 de mensajes de
recuperación aplazada, como se ve en la Figura 4, puede ser usado
para almacenar el contenido extra que fue quitado en el proceso de
transformación.
La ventaja de lo anterior es que el librero
puede tener un sitio y enviar una lista a todos sus clientes. Como
diversos clientes no serán clientes con dispositivos inalámbricos
móviles, el archivo de 100 KB puede ser apropiado para estos
clientes. Proporcionando también los metadatos de transformación, el
librero puede tener una lista que envía a todos. Como será
apreciado por los expertos en la técnica, la mayoría de las
tecnologías web actuales necesitan un sitio Web separado para un
cliente móvil, y esto es superado por la solución anterior.
Lo anterior también se presta a un modelo de
sindicación y ahora se hace referencia a la Figura 19.
Como será apreciado por los expertos en la
técnica, un dispositivo móvil puede no desear recibir grandes
cantidades de datos cuando las condiciones de red no son óptimas
para la recepción de grandes cantidades de datos. Además, los
operadores de red pueden desear evitar el envío de grandes
cantidades de datos durante los períodos de pico de uso de anchura
de banda para extender el tráfico de red más uniformemente en el
tiempo. Esto puede ser efectuado usando un modelo de
envío/extracción como se ilustra en la Figura 19.
Como se describió con referencia a la Figura 4
anterior, puede proporcionarse contenido que incluye más información
que la que el usuario necesita actualmente. Por ejemplo, si el
usuario solicita información de posición para restaurantes dentro
de su área, un proveedor de servicios puede desear añadir publicidad
tal como otros servicios disponibles en el área. Sin embargo, el
proveedor de servicios puede no desear enviar este contenido
adicional inmediatamente al usuario sino en cambio proporcionar un
manual tal como un titular o un índice que muestra el contenido
adicional.
En otras situaciones, el contenido puede ser
demasiado grande para enviar al usuario y el usuario puede recibir
solo la primera parte del contenido y el resto del contenido es
almacenado en un almacenamiento 452 de mensajes de recuperación
aplazada.
Después, el contenido almacenado puede ser
pasado al cliente 510 de servicio de envío por el proxy 410 de
servicio de envío o cuando es solicitado por el cliente 510 de
servicio de envío.
El cliente 510 de servicio de envío incluye un
monitor 1910 de estatus de red que puede supervisar el estatus de
la red. El cliente 510 de servicio de envío puede desear recibir
solo datos extra en ciertas condiciones. Por ejemplo, en un
dispositivo móvil híbrido que tiene una opción WiFi y una opción
celular, es más barato proporcionar datos en la conexión WiFi y,
por tanto, el monitor 1910 de estatus de red podría esperar hasta
que el cliente 510 de servicio de envío es conectado a una red WiFi
antes de obtener el contenido aplazado. Alternativamente, el
monitor de estatus de red podría comprobar si el cliente está
desplazándose en una red extrajera o está conectado a la red
nacional para minimizar los costes de itinerancia. El monitor de
estatus de red también puede comprobar para ver si un canal
dedicado de datos está establecido para el dispositivo. Un experto
en la técnica comprenderá que el monitor 1910 de estatus de red
también podría comprobar diversas otras condiciones previas en la
red antes de solicitar que datos aplazados sean pasados al cliente
510 de servicio de envío.
Una red inalámbrica 130 también podría
proporcionar información a cualquiera o ambos del cliente 510 de
servicio de envío y del proxy 410 de servicio de envío referente a
los costes del suministro de datos. Como será apreciado por los
expertos en la técnica, diversos períodos de pico ocurren para el
suministro de contenido. En el caso de información de tráfico, los
períodos de pico pueden estar al principio y al final de la jornada
de trabajo cuando la gente está llegando a, o saliendo de, el
trabajo. Para cotizaciones de bolsa, el período de pico puede ser
durante el tiempo que la bolsa está abierta. Existirán otros
períodos de pico. Para promediar el tráfico de datos, puede ser
deseable que la red cobre precios diferentes basados en el uso
actual de datos en la red. Así, durante períodos de pico puede
cobrarse un precio mayor que durante un período no de pico tal como
en medio de la noche. Por tanto, la red inalámbrica 130 proporciona
notificaciones de coste de suministro a un gestor 552 de
recuperación aplazada en un cliente 510 de servicio de envío y a un
planificador 454 de servicio de envío en el proxy 410 de servicio
de envío.
En una realización, los datos procedentes del
proveedor 110 de contenidos y pasados al proxy 410 de servicio de
envío pueden ser clasificados basados en su importancia para el
cliente. Cierta información puede ser designada mediante metadatos
para ser suministrada inmediatamente. Otra información puede ser
designada para ser suministrada cuando el coste de red es menor que
un primer valor (por ejemplo, 10 \upbar{c} por megabyte) y otros
datos pueden ser designados para ser suministrados cuando los
costes de red caen por debajo de un segundo valor (por ejemplo, 5
\upbar{c} por megabyte). Así, el planificador 454 de servicio de
envío considera los datos que están almacenados en el
almacenamiento 452 de mensajes de recuperación aplazada y ordena al
agente 444 de servicio de envío que pase datos aplazados al agente
554 de servicio de envío en el cliente 510 de servicio de envío.
Alternativamente, el gestor 552 de recuperación
aplazada también podría supervisar las condiciones de red como son
enviadas desde la red inalámbrica 130 y si la velocidad de datos es
menor que una cierta velocidad, puede pedir al intermediario 554 de
extracción de contenido que extraiga contenido desde el
almacenamiento 452 de mensajes de recuperación aplazada.
Alternativamente, el gestor 552 de recuperación
aplazada podría ver que el estatus de red es favorable para extraer
cantidades mayores de datos, tal como si el dispositivo móvil ha
conectado con una red WiFi, y pedir al intermediario 554 de
extracción de contenido que extraiga los datos desde el
almacenamiento 452 de mensajes de recuperación aplazada.
Como se apreciará además, un usuario siempre
puede solicitar que el contenido sea extraído. Así, la solicitud
1940 de usuario también podría ser usada para activar el
intermediario 554 de extracción de contenido para extraer los datos
desde el almacenamiento 452 de mensajes de recuperación
aplazada.
Las reglas almacenadas en el planificador 454 de
servicio de envío y el gestor 552 de recuperación aplazada podrían
ser metadatos estáticos basados en una clasificación de contenido.
Las reglas también podrían estar basadas en metadatos dinámicos
para los datos particulares que han sido pasados. En este caso, el
proveedor 110 de contenidos ha clasificado los datos.
Ahora se hace referencia a la Figura 20. Como
será apreciado por los expertos en la técnica, los datos pueden
tener una de dos formas, lineal o no lineal. Por ejemplo, los datos
lineales podrían ser series o hileras de contenido que circula de
una forma lineal. Inversamente, los datos no lineales son datos que
no se relacionan linealmente entre sí y pueden incluir dependencias
complejas con mapas o enlaces de contenido.
Para contenido lineal, la fragmentación implica
simplemente la separación de los datos en diversos componentes
basada en la progresión lineal. Los datos son divididos en segmentos
y los segmentos son suministrados al cliente 510 de servicio de
envío. Como se indica en la Figura 20, el procesador 2010 de
fragmentación interacciona con el contenido 2012 y decide que el
contenido puede ser analizado con progresión lineal. A continuación,
el procesador 2010 de fragmentación divide los datos en segmentos
2014, 2016 y 2018 en el ejemplo de la Figura 20 y, como se ilustra
en la Figura 20, pasa el primer segmento 2014 mientras que aplaza el
paso de los segmentos segundo y tercero 2016 y 2018
respectivamente.
El módulo 2030 de gestión de cursor se mantiene
al tanto de que segmento ha sido suministrado y suministra el
segmento siguiente en orden.
Refiriéndose a la Figura 21, el contenido no
lineal necesita ser dividido de un modo más inteligente. Además, en
el otro extremo son necesarios metadatos para reconstituir los
segmentos.
Un procesador 2110 de fragmentación analiza el
contenido basado en un análisis basado en metadatos. Estos podrían
incluir mantener ciertos segmentos o elementos de datos juntos si es
requerido lógicamente. El procesador 2110 de fragmentación analiza
el contenido 2112 y divide el contenido en segmentos basado en
reglas lógicas. Cada segmento incluye el contenido más metadatos
que incluyen, por ejemplo, dependencias, mapas y reglas de
navegación para cada segmento.
Una vez dividido, un primer segmento 2114 es
enviado al cliente 510 de servicio de envío y el paso del resto de
los segmentos 2116 y 2118 es aplazado como se ilustra en la Figura
21. El bloque 2130 de navegación de segmentos se ocupa de qué
segmento enviar a continuación. Como será apreciado por los expertos
en la técnica, el primer segmento 2114 incluye una porción de datos
y una porción de metadatos. La porción de metadatos del segmento
2114 es una capa de metadatos que es añadida por el procesador 2110
de fragmentación para indicar al módulo 564 de dependencias de
contenido como reconstituir el contenido. La porción de datos del
primer segmento 2114 puede incluir tanto contenido como metadatos
asociados con el canal o con el contenido.
El bloque 2130 de navegación de segmentos está
adaptado para procesar como un usuario se desplaza a través de los
datos. Por ejemplo, si los datos están en un formato de árbol y el
usuario baja por la primera rama del árbol, el bloque 2130 de
navegación de segmentos puede pasar al cliente 510 de servicio de
envío otras ramas en el árbol que pueden ser alcanzadas desde el
elemento al que ha navegado el usuario.
Por ejemplo, un árbol podría incluir una base de
datos de empleados que tiene los nombres de empleados junto con una
estructura para la corporación. Basado en la Figura 21, si el
usuario navega al interior de un departamento específico de la
organización, el bloque 2130 de navegación de segmentación podría
hacer seguir los fragmentos de grupos para grupos dentro de ese
departamento. Después, si el usuario navega al interior de un grupo
específico dentro del departamento, entonces el bloque 2130 de
navegación de segmentación podría pasar fragmentos de información
sobre los empleados dentro de ese grupo.
Por tanto, lo anterior requiere que los datos
sean divididos en componentes lógicos. Identificadores son asignados
a todos los tipos y contenido, y es creada información estructural
que pasa la información con el manual.
Por tanto, lo anterior proporciona una
arquitectura para suministro dinámico de contenido que puede ser
usada con sistemas genéricos donde aplicaciones y contenido pueden
ser añadidos sin cambiar la estructura del sistema. El contenido
puede ser adaptado para ajustar con la aplicación que lo recibe, y
ser fragmentado según lo anterior.
Como se apreciará, el cliente de servicio de
envío y las aplicaciones de cliente puede residir en cualquier
dispositivo móvil. Un dispositivo móvil ejemplar es descrito a
continuación con referencia a la Figura 22. Esta no pretende ser
limitativa sino que es provista con fines ilustrativos.
La Figura 22 es un esquema de bloques que
ilustra una estación móvil apta para ser usada con realizaciones
preferidas del aparato y método de la presente solicitud. La
estación móvil 2200 es preferiblemente un dispositivo de
comunicación inalámbrica bidireccional que tiene al menos
capacidades de comunicación de voz y datos. La estación móvil 2200
tiene preferiblemente la capacidad de comunicar con otros sistemas
de ordenador por Internet. Dependiendo de la funcionalidad exacta
provista, el dispositivo inalámbrico puede ser denominado como un
dispositivo de mensajería de datos, un buscapersonas bidireccional,
un dispositivo de correo electrónico (e-mail)
inalámbrico, un teléfono celular con capacidades de mensajería de
datos, un aparato inalámbrico de Internet o un dispositivo de
comunicación de datos, como ejemplos.
Donde la estación móvil 2200 está habilitada
para comunicación bidireccional, incorporará un subsistema 2211 de
comunicación, incluyendo tanto un receptor 2212 como un transmisor
2214, así como componentes asociados tal como una o más,
preferiblemente incrustados o internos, elementos 2216 y 2218 de
antena, osciladores locales (OLs) 2213 y un módulo de procesamiento
tal como un procesador de señales digitales (PSD) 2220. Como será
evidente para los expertos en el campo de las comunicaciones, el
diseño particular del subsistema 2211 de comunicación dependerá de
la red de comunicación en la que el dispositivo está destinado a
funcionar.
Las exigencias de acceso a red también variarán
dependiendo del tipo de red 2219. En algunas redes de Acceso
Múltiple por División de Código (CDMA: Code Division Multiple
Access), el acceso a red está asociado con un abonado o usuario de
la estación móvil 2200. Una estación móvil de CDMA puede necesitar
una tarjeta de módulo separable de identidad de usuario (RUIM:
removable user identity module) o de módulo de identidad de abonado
(SIM: subscriber identity module) para funcionar en una red de CDMA.
La interfaz 2244 de SIM/RUIM es normalmente similar a una ranura
para tarjeta dentro de la cual una tarjeta de SIM/RUIM puede ser
insertada y expulsada como un disquete o tarjeta de PCMCIA
(Personal Computer Memory Card International Association). La
tarjeta de SIM/RUIM puede tener aproximadamente 64K de memoria y
contener muchas configuraciones 2251 de clave, y otra información
2253 tal como identificación, e información relacionada con el
abonado.
Cuando los procedimientos necesarios de registro
o activación de red han sido completados, la estación móvil 2200
puede emitir y recibir señales de comunicación por la red 2219. Como
se ilustra en la Figura 22, la red 2219 puede constar de estaciones
base múltiples que comunican con el dispositivo móvil. Por ejemplo,
en un sistema híbrido CDMA 1x EVDO (Code Division Multiple Access
1x Evolution Data Optimized), una estación base CDMA y una estación
base EVDO comunican con la estación móvil y la estación móvil está
conectada con ambas simultáneamente. Las estaciones base EVDO y
CDMA 1x usan ranuras diferentes de buscapersonas para comunicar con
el dispositivo móvil.
Las señales recibidas por la antena 2216 a
través de la red 2219 de comunicación son introducidas en el
receptor 2212 que puede realizar tales funciones comunes de
receptor como amplificación de señal, reducción de frecuencia,
filtración, selección de canal, etc., y en el sistema ejemplar
mostrado en la Figura 22, conversión analógica a digital (A/D). La
conversión A/D de una señal recibida permite que funciones de
comunicación más complejas tales como desmodulación y
descodificación sean realizadas en el procesador de señales
digitales (PSD) 2220. De una manera similar, las señales a ser
transmitidas son procesadas, incluyendo modulación y codificación
por ejemplo, por el procesador de señales digitales (PSD) 2220 e
introducidas en el transmisor 2214 para conversión digital a
analógica (D/A), aumento de frecuencia, filtración, amplificación y
transmisión por la red 2219 de comunicación por vía de la antena
2218. El procesador de señales digitales (PSD) 2220 no solo procesas
señales de comunicación sino que también provee lo necesario para
el control del receptor y del transmisor. Por ejemplo, las
ganancias aplicadas a las señales de comunicación en el receptor
2212 y el transmisor 2214 pueden ser controladas adaptablemente
mediante algoritmos de control automático de ganancia implementados
en el procesador de señales digitales (PSD) 2220.
La estación móvil 2200 incluye preferiblemente
un microprocesador 2238 que controla el funcionamiento global del
dispositivo. Las funciones de comunicación, incluyendo al menos
comunicaciones de voz y datos, son realizadas a través del
subsistema 2211 de comunicación. El microprocesador 2238 también
interacciona con subsistemas adicionales del dispositivo tales las
pantalla 2222, la memoria flash 2224, la memoria de acceso aleatorio
(RAM) 2226, los subsistemas 2228 de entrada/salida auxiliar (I/O:
imput/output), el puerto 2230 en serie, dos o más teclados o
teclados numéricos 2232, el altavoz 2234, el micrófono 2236, otro
subsistema 2240 de comunicaciones tal como un subsistema de
comunicaciones de corto alcance y cualesquier otros subsistemas del
dispositivo designados generalmente como 2242. El puerto 2230 en
serie podría incluir un puerto USB (Universal Serial Bus) u otro
puerto conocido por los expertos en la técnica.
Algunos de los subsistemas mostrados en la
Figura 22 realizan funciones relacionadas con la comunicación
mientras que otros subsistemas pueden proporcionar funciones
"residentes" o en el dispositivo. Notablemente, algunos
subsistemas, tales como el teclado 2232 y la pantalla 2222 por
ejemplo, pueden ser usados tanto para funciones relacionadas con la
comunicación, tal como introducir un mensaje de texto para
transmisión por una red de comunicación, como funciones residentes
en el dispositivo tal como una calculadora o una lista de
tareas.
El software de sistema operativo usado por el
microprocesador 2238 es almacenado preferiblemente en un
almacenamiento persistente tal como la memoria flash 2224, que en
cambio puede ser una memoria de solo lectura (ROM) o elemento de
almacenamiento similar (no mostrado). Los expertos en la técnica
apreciarán que el sistema operativo, aplicaciones específicas de
dispositivo o partes de ellas pueden ser cargadas temporalmente en
una memoria volátil tal como la memoria de acceso aleatorio (RAM)
2226. Las señales de comunicación recibidas también pueden ser
almacenadas en la RAM 2226.
Como se muestra, la memoria flash 2224 puede ser
separada en áreas diferentes tanto para programas 2258 de ordenador
como para almacenamiento 2250, 2252, 2254 y 2256 de datos de
programas. Estos tipos de almacenamiento diferentes indican que
cada programa puede asignar una porción de memoria flash 2224 para
sus propias exigencias de almacenamiento de datos. Además de sus
funciones de sistema operativo, el microprocesador 2238 permite
preferiblemente la ejecución de aplicaciones de software en la
estación móvil. Un conjunto predeterminado de aplicaciones que
controlan operaciones básicas, incluyendo al menos aplicaciones de
comunicación de voz y datos por ejemplo, serán instaladas
normalmente en la estación móvil 2200 durante la fabricación. Otras
aplicaciones podrían ser instaladas posteriormente o
dinámicamente.
Una aplicación preferida de software puede ser
una aplicación de gestor de información personal (PIM: personal
information manager) que tiene la capacidad de organizar y gestionar
elementos de datos relativos al usuario de la estación móvil tales
como, pero no limitados a, correo electrónico, eventos de
calendario, correos de voz, compromisos y elementos de tareas.
Naturalmente, uno o más almacenamientos de memoria estarían
disponibles en la estación móvil para facilitar el almacenamiento
de elementos de datos de gestor de información personal (PIM). Tal
aplicación de PIM tendría preferiblemente la capacidad de emitir y
recibir elementos de datos por vía de la red inalámbrica 2219. En
una realización preferida, los elementos de datos de gestor de
información personal (PIM) son integrados ininterrumpidamente,
sincronizados y actualizados, por vía de la red inalámbrica 2219,
con los elementos de datos correspondientes de usuario de estación
móvil almacenados en, o asociados con, un sistema de ordenador
principal. Aplicaciones adicionales también pueden ser cargadas en
la estación móvil 2200 a través de la red 2219, un subsistema 2228
de entrada/salida (I/O) auxiliar, el puerto 2230 en serie, el
subsistema 2240 de comunicaciones de corto alcance o cualquier otro
subsistema adecuado 2242, e instaladas por un usuario en la RAM
2226 o, preferiblemente, en un almacenamiento no volátil (no
mostrado) para ejecución por el microprocesador 2238. Tal
flexibilidad en la instalación de aplicaciones aumenta la
funcionalidad del dispositivo y puede proporcionar funciones
realzadas en el dispositivo, funciones relacionadas con la
comunicación o ambas. Por ejemplo, las aplicaciones de comunicación
segura (protegida) pueden permitir que funciones de comercio
electrónico y otras transacciones financieras tales sean realizadas
usando la estación móvil 2200.
En un modo de comunicación de datos, una señal
recibida tal como un mensaje de texto o una descarga de página Web
será procesada por el subsistema 2211 de comunicación e introducido
en el microprocesador 2238 que, preferiblemente, procesa además la
señal recibida para salida a la pantalla 2222 o, alternativamente, a
un dispositivo 2228 de entrada/salida (I/O) auxiliar. Un cliente
2260 de servicio de envío, que podría ser equivalente a los clientes
140 y 510 de servicio de envío, también podría procesar la
entrada.
Un usuario de estación móvil 2200 también puede
componer elementos de datos, tales como mensajes de correo
electrónico por ejemplo, usando el teclado 2232, que es
preferiblemente un teclado alfanumérico completo o un teclado
numérico de tipo telefónico, en conjunción con la pantalla 2222 y
posiblemente con un dispositivo 2228 de entrada/salida (I/O)
auxiliar. Después, tales elementos compuestos pueden ser
transmitidos por una red de comunicación a través del subsistema
2211 de comunicación.
Para comunicaciones de voz, el funcionamiento
global de la estación móvil 2200 es similar excepto en que las
señales recibidas serían extraídas preferiblemente a un altavoz 2234
y las señales para transmisión serían generadas por un micrófono
2236. Subsistemas alternativos de entrada/salida (I/O) de voz o
audio, tal como un subsistema de grabación de mensajes de voz,
también pueden ser implementados en la estación móvil 2200. Aunque
la salida de señal de voz o audio es efectuada preferiblemente de
modo principal a través del altavoz 2234, la pantalla 2222 también
puede ser usada para proporcionar una indicación de la identidad de
un corresponsal que llama, la duración de una llamada de voz u otra
información relacionada con la llamada de voz por ejemplo.
En la Figura 22, el puerto 2230 en serie sería
implementado normalmente en una estación móvil de tipo asistente
digital personal para la que la sincronización con un ordenador de
sobremesa de usuario (no mostrado) puede ser deseable, pero es un
componente opcional de dispositivo. Tal puerto 2230 permitiría a un
usuario disponer preferencias a través de un dispositivo externo o
aplicación de software y extendería las capacidades de la estación
móvil 2200 proveyendo descargas de información o software a la
estación móvil 2200 de otra manera que a través de una red de
comunicación inalámbrica. Por ejemplo, el trayecto alternativo de
descarga puede ser usado para cargar una clave de cifrado en el
dispositivo a través de una conexión directa, y por tanto fiable y
de confianza, para permitir de tal modo la comunicación segura
(protegida) del dispositivo. Como será apreciado por los expertos
en la técnica, el puerto 2230 en serie puede ser usado además para
conectar el dispositivo móvil a un ordenador para actuar como
un
módem.
módem.
Otros subsistemas 2240 de comunicaciones, tal
como un subsistema de comunicaciones de corto alcance, es un
componente opcional adicional que puede proveer comunicación entre
la estación móvil 2200 y sistemas o dispositivos diferentes que no
precisan ser necesariamente dispositivos similares. Por ejemplo, el
subsistema 2240 puede incluir un dispositivo de infrarrojos y
circuitos y componentes asociados o un módulo de comunicación
Bluetooth^{TM} para proveer comunicación con sistemas y
dispositivos habilitados de modo similar.
Las realizaciones descritas en esto son ejemplos
de estructuras, sistemas o métodos que tienen elementos
correspondientes a elementos de las técnicas de esta solicitud.
Esta descripción escrita puede permitir a los expertos en la
técnica fabricar y usar realizaciones que tienen elementos
alternativos que corresponden igualmente a los elementos de las
técnicas de esta solicitud. El alcance propuesto de las técnicas de
esta solicitud incluye así otras estructuras, sistemas o métodos
que no son diferentes que las técnicas de esta solicitud como se
describen en esto, e incluye además otras estructuras, sistemas o
métodos con diferencias insustanciales respecto a las técnicas de
esta solicitud como se describen en esto.
Claims (12)
1. Un método para optimizar el suministro de
contenidos en un elemento de procesamiento (150, 510, 410) en una
arquitectura de suministro dinámico de contenidos, comprendiendo el
método los pasos de:
- recibir una envoltura de contenido y de metadatos (614, 610, 620) en el elemento de procesamiento;
- comprobar la envoltura de contenido y de metadatos para determinar si la envoltura de contenido y de metadatos comprende metadatos para dicho elemento de procesamiento;
- si dicha envoltura de contenido y de metadatos contiene metadatos para dicho elemento de procesamiento, extraer y almacenar en antememoria dichos metadatos;
- si dicha envoltura de contenido y de metadatos no contiene metadatos para dicho elemento de procesamiento, recuperar metadatos para un proveedor de contenidos, asociado con el contenido incluido en dicha envoltura de contenido y de metadatos, desde una antememoria en el elemento de procesamiento; y
- aplicar dichos metadatos extraídos o recuperados a dicha envoltura de contenido y de metadatos.
\vskip1.000000\baselineskip
2. El método de la reivindicación 1, en el que
dicho paso de comprobar comprueba además si la envoltura de
contenido y de metadatos comprende metadatos incrementales para
dicho elemento de procesamiento y, si es sí, el método comprende
además:
- recuperar metadatos para un proveedor de contenidos desde la antememoria;
- combinar los metadatos recuperados desde la antememoria con los metadatos incrementales que forman metadatos combinados; y
- realizar dicho paso de aplicar con dichos metadatos combinados.
\vskip1.000000\baselineskip
3. El método de la reivindicación 1 o la
reivindicación 2, en el que el elemento de procesamiento es un proxy
de servicio de envío, un cliente de servicio de envío o una
aplicación de cliente.
4. El método de una cualquiera de las
reivindicaciones 1 a 3, en el que la envoltura de contenido y de
metadatos contiene metadatos para uno o más elementos de
procesamiento de dicha arquitectura de suministro de contenidos.
5. El método de una cualquiera de las
reivindicaciones 1 a 3, en el que la envoltura de contenido y de
metadatos no contiene metadatos.
6. Un elemento de procesamiento para uso en una
arquitectura de suministro dinámico de contenidos (150, 140, 120),
comprendiendo dicho elemento de procesamiento:
- medios de comunicación, estando dichos medios de comunicación adaptados para recibir una envoltura de contenido y de metadatos desde un proveedor de contenidos o un elemento de procesamiento anterior en dicha arquitectura de suministro dinámico de contenidos y adaptados además para pasar una envoltura modificada de contenido y de metadatos a un elemento de procesamiento subsiguiente en dicha arquitectura de suministro dinámico de contenidos;
- un extractor de metadatos adaptado para extraer metadatos dirigidos al elemento de procesamiento desde dicha envoltura de contenido y de metadatos si dicha envoltura de contenido y de metadatos contiene metadatos para dicho elemento de procesamiento, estando una antememoria adaptada para almacenar los metadatos extraídos por el extractor de metadatos;
- en el que dicho extractor de metadatos está adaptado además para recuperar metadatos desde dicha antememoria si no existen metadatos para el elemento de procesamiento en dicha envoltura de contenido y de metadatos;
- un procesador adaptado para aplicar dichos metadatos extraídos o recuperados a dicha envoltura de contenido y de metadatos una vez que los metadatos para el elemento de procesamiento han sido extraídos o recuperados.
\vskip1.000000\baselineskip
7. El elemento de procesamiento de la
reivindicación 6, en el que dicho extractor de metadatos está
adaptado además para extraer metadatos incrementales dirigidos al
elemento de procesamiento.
8. El elemento de procesamiento de la
reivindicación 7, en el que el extractor de metadatos está adaptado
para combinar los metadatos incrementales extraídos con metadatos
recuperados desde la antememoria.
9. El elemento de procesamiento de una
cualquiera de las reivindicaciones 6 a 8, en el que el elemento de
procesamiento es un proxy de servicio de envío, un cliente de
servicio de envío o una aplicación de cliente.
10. El elemento de procesamiento de una
cualquiera de las reivindicaciones 6 a 9, en el que la envoltura de
contenido y de metadatos contiene metadatos para uno o más elementos
de procesamiento de dicha arquitectura de suministro dinámico de
contenido.
11. El elemento de procesamiento de una
cualquiera de las reivindicaciones 6 a 10, en el que la envoltura
de contenido y de metadatos no contiene metadatos.
12. Un producto de programa de ordenador para
optimizar el suministro de contenido en un elemento de procesamiento
en una arquitectura de suministro dinámico de contenido,
comprendiendo el producto de programa de ordenador un soporte
legible por ordenador que materializa los medios de código de
programa ejecutables por un dispositivo, sistema o aparato
computador para implementar el método de una cualquiera de las
reivindicaciones
1 a 5.
1 a 5.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06113366A EP1853026B1 (en) | 2006-05-02 | 2006-05-02 | Method and system for optimizing metadata passing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2340866T3 true ES2340866T3 (es) | 2010-06-10 |
Family
ID=36889064
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06113366T Active ES2340866T3 (es) | 2006-05-02 | 2006-05-02 | Metodo y sistema para optimizar el paso de metadatos. |
Country Status (12)
| Country | Link |
|---|---|
| EP (2) | EP2166730B1 (es) |
| JP (2) | JP4594350B2 (es) |
| KR (1) | KR100891911B1 (es) |
| CN (2) | CN101110839B (es) |
| AT (1) | ATE459183T1 (es) |
| AU (1) | AU2007201900B2 (es) |
| BR (1) | BRPI0702255A2 (es) |
| CA (1) | CA2581955C (es) |
| DE (1) | DE602006012454D1 (es) |
| ES (1) | ES2340866T3 (es) |
| HK (1) | HK1110718A1 (es) |
| MX (1) | MX2007005142A (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1586045A1 (en) | 2002-12-27 | 2005-10-19 | Nielsen Media Research, Inc. | Methods and apparatus for transcoding metadata |
| KR101297519B1 (ko) | 2008-08-08 | 2013-08-16 | 삼성전자주식회사 | Ｄｃｄ 서비스에서 사용자 콘텐트 제출 방법 및 시스템 |
| US8621520B2 (en) * | 2009-05-19 | 2013-12-31 | Qualcomm Incorporated | Delivery of selective content to client applications by mobile broadcast device with content filtering capability |
| US9380356B2 (en) | 2011-04-12 | 2016-06-28 | The Nielsen Company (Us), Llc | Methods and apparatus to generate a tag for media content |
| AU2015252031B2 (en) * | 2011-06-21 | 2017-10-26 | The Nielsen Company (Us), Llc | Monitoring streaming media content |
| US9209978B2 (en) | 2012-05-15 | 2015-12-08 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| US9210208B2 (en) | 2011-06-21 | 2015-12-08 | The Nielsen Company (Us), Llc | Monitoring streaming media content |
| US9313544B2 (en) | 2013-02-14 | 2016-04-12 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
| US9762965B2 (en) | 2015-05-29 | 2017-09-12 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08328980A (ja) * | 1995-05-31 | 1996-12-13 | Hitachi Ltd | 情報通信装置および情報通信方法 |
| JP2001134518A (ja) * | 1999-11-02 | 2001-05-18 | Nec Corp | データ通信装置およびデータ通信システム |
| EP1119135A3 (en) | 2000-01-13 | 2001-09-12 | Agilent Technologies Inc. a Delaware Corporation | Apparatus and method for a push service |
| US6574214B1 (en) | 2000-05-25 | 2003-06-03 | Nortel Networks Limited | Reduced overhead tunneling techniques in a communications network having mobile foreign agents |
| JP3676204B2 (ja) * | 2000-07-18 | 2005-07-27 | 新キャタピラー三菱株式会社 | 建設機械における音声アタッチメント制御方法 |
| US6309078B1 (en) * | 2000-12-08 | 2001-10-30 | Axon Instruments, Inc. | Wavelength-selective mirror selector |
| US20030018978A1 (en) * | 2001-03-02 | 2003-01-23 | Singal Sanjay S. | Transfer file format and system and method for distributing media content |
| JP2004533738A (ja) * | 2001-03-02 | 2004-11-04 | カセンナ インコーポレイテッド | ネットワークにわたって低レイテンシで効率的にビデオコンテンツを配給するためのメタデータイネーブル型プッシュ−プルモデル |
| JP2003283422A (ja) * | 2002-03-26 | 2003-10-03 | Nec Corp | データ送受信システム、携帯端末、コンテンツサーバ、無線基地局装置、及び、データ送受信方法 |
| KR20030085674A (ko) * | 2002-04-30 | 2003-11-07 | (주)한넷웨어 | 무선망 환경에서 주기적인 푸시 정보를 전송하는 시스템및 방식 |
| JP2004260532A (ja) | 2003-02-26 | 2004-09-16 | Hitachi Ltd | ネットワークプロセッサ |
| KR100513290B1 (ko) * | 2003-06-30 | 2005-09-09 | 삼성전자주식회사 | 멀티미디어 컨텐츠와 세그먼트 메타데이터간의 시간 동기화를 위한 시스템 및 방법 |
| US20050100042A1 (en) * | 2003-11-12 | 2005-05-12 | Illikkal Rameshkumar G. | Method and system to pre-fetch a protocol control block for network packet processing |
| US8856346B2 (en) * | 2004-01-15 | 2014-10-07 | Unwired Planet, Llc | Stateful push notifications |
| JP4497353B2 (ja) * | 2004-04-01 | 2010-07-07 | ソニー・エリクソン・モバイルコミュニケーションズ株式会社 | 携帯端末装置及びコンテンツ記録方法 |
-
2006
- 2006-05-02 AT AT06113366T patent/ATE459183T1/de not_active IP Right Cessation
- 2006-05-02 EP EP10150346.4A patent/EP2166730B1/en active Active
- 2006-05-02 DE DE602006012454T patent/DE602006012454D1/de active Active
- 2006-05-02 ES ES06113366T patent/ES2340866T3/es active Active
- 2006-05-02 EP EP06113366A patent/EP1853026B1/en active Active
-
2007
- 2007-03-16 CA CA2581955A patent/CA2581955C/en active Active
- 2007-04-19 BR BRPI0702255-7A patent/BRPI0702255A2/pt not_active IP Right Cessation
- 2007-04-23 JP JP2007113550A patent/JP4594350B2/ja active Active
- 2007-04-27 MX MX2007005142A patent/MX2007005142A/es active IP Right Grant
- 2007-04-30 CN CN2007101023640A patent/CN101110839B/zh active Active
- 2007-04-30 KR KR1020070041807A patent/KR100891911B1/ko active IP Right Grant
- 2007-04-30 AU AU2007201900A patent/AU2007201900B2/en active Active
- 2007-04-30 CN CN201010603986.3A patent/CN102014140B/zh active Active
-
2008
- 2008-05-06 HK HK08105066.0A patent/HK1110718A1/xx unknown
-
2010
- 2010-09-16 JP JP2010208647A patent/JP5183707B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| BRPI0702255A2 (pt) | 2008-12-02 |
| EP1853026A1 (en) | 2007-11-07 |
| JP2011044156A (ja) | 2011-03-03 |
| KR20070107591A (ko) | 2007-11-07 |
| EP1853026B1 (en) | 2010-02-24 |
| KR100891911B1 (ko) | 2009-04-06 |
| CA2581955A1 (en) | 2007-11-02 |
| CA2581955C (en) | 2012-11-13 |
| JP5183707B2 (ja) | 2013-04-17 |
| DE602006012454D1 (de) | 2010-04-08 |
| JP2007299395A (ja) | 2007-11-15 |
| CN102014140B (zh) | 2015-08-19 |
| CN102014140A (zh) | 2011-04-13 |
| HK1110718A1 (en) | 2008-07-18 |
| JP4594350B2 (ja) | 2010-12-08 |
| CN101110839A (zh) | 2008-01-23 |
| EP2166730A1 (en) | 2010-03-24 |
| AU2007201900B2 (en) | 2009-02-12 |
| MX2007005142A (es) | 2008-12-02 |
| ATE459183T1 (de) | 2010-03-15 |
| AU2007201900A1 (en) | 2007-11-22 |
| EP2166730B1 (en) | 2014-09-24 |
| CN101110839B (zh) | 2011-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2340866T3 (es) | Metodo y sistema para optimizar el paso de metadatos. | |
| US8024452B2 (en) | Dynamic syndicated content delivery system and method | |
| AU2007201902B2 (en) | Dynamic syndicated content delivery system and method | |
| CA2581947C (en) | Push framework for delivery of dynamic mobile content | |
| US7644139B2 (en) | Method and system for optimizing metadata passing in a push content processing protocol | |
| US20070260674A1 (en) | Push framework for delivery of dynamic mobile content | |
| US8019892B2 (en) | Multi-layered enveloped method and system for push content metadata | |
| US20120042004A1 (en) | Plug in registration method and apparatus for push content delivery | |
| AU2007201901B2 (en) | Plug in registration method and apparatus for push content delivery | |
| US20070276863A1 (en) | Plug in registration method and apparatus for push content delivery | |
| US20070260637A1 (en) | System and method for fragmentation of mobile content | |
| ES2309903T3 (es) | Metodo y sistema de envolturas multicapas para metadatos de contenidos de empuje. | |
| AU2007201895B2 (en) | System and method for fragmentation of mobile content | |
| CA2643043A1 (en) | Method and system for optimizing delivery of mobile content using differential metadata updates |